Comments 10
Либо у ваc там writeback, либо вы используете негодные инструменты для бенчмарков. С flush'ем какая max latency для одинокой операции на 4k? (Всё остальное более-менее можно из этой одной цифры вывести).
Все вендоры делятся на 4 категории:
- nvme с дикими ценами (max latency < 1ms)
- writeback и срали на данные (max latency < 1ms, цены терпимы)
- writeback/flush (max latency >> 1ms — честные)
- … ну вы что-то странное спрашиваете, у нас такого нет.
Инструмент один, FIO. Достаточно годный для вас инструмент? Профили нагрузок под каждый тест можно найти без всяких проблем, X Ray сам всего лишь инструмент автоматизации и визуализации. А дальше можете эти профили скормить в HCI Bench или вообще самостоятельно построить тестовую платформу. Вам лично не составит это труда, думаю, сделать это 100% самостоятельно.
Для тех же, кто менее продвинут, есть ссылка в тексте на другую мою статью как. Повторю здесь в комментарии: habr.com/ru/company/nutanix/blog/348182
fio хороший инструмент, но его часто используют неправильно.
Когда мы меряемся пи бенмарками, ключевым является время выполнения flush'а. Большинство запускают бенчмарк без flush'а и получают попугаи от кешей разного уровня.
[write]
blocksize=4k
filename=/somefile
rw=randwrite
size=1G
direct=1
buffered=0
fsync=1
ioengine=libaio
iodepth=1Вот это fsync=1 убивает производительность в большинстве случаев. Иногда нет, и такие системы делятся на три категории из комментария выше.
Ключевой же метрикой тут является max latency. При том, что для большинства задач бизнеса достаточно ориентироваться на средние показатели (или какой-то персентиль), реально оценить качество реализации СХД можно по max latency в режиме fsync.
RF3 рекомендуется для продуктивных систем, соответственно минимальный продуктивный кластер состоит из 5 узлов.
RF2 используется в непродуктивных системах (тест, разработка) и в метрокластерах. Поскольку каждое плечо метрокластера имеет RF2, то фактическое количество копий данных равно 4 и соотв можно обойтись без RF3.
C 2 часовым таймаутом вопрос с логикой, которой пользуется система при возвращении потерянной ноды обратно в онлайн менее чем за время таймаута. Если записанные на нее "третьи" копии данных просто продолжат использоваться, то возможно таймаут как раз предусмотрен для того, что бы решить проблему с нодой, если она не требует много времени, и вернуть ее в работу. При этом избежать ребилда всего, что на потерянную ноду было записано. Все же для продуктивного кластера ребилд не лучшее времяпрепровождение.
А с RF3 все равно остается вопрос стоимости в переводе на реальную полезную емкость такого решения. Насколько помню, у HyperFlex 8% дисковой емкости блокируется под хранение метаданных (а кто может обойтись без них?). В таком случае из условных 100TB сырой емкости нам остается 92TB. Рекомендованный RF3 оставляет нам около 30.7 TB. А далее рекомендованная Cisco "cluster storage utilisation" не более 70% от этих оставшихся 30.7TB. В итоге на выходе из условных 100TB "сырых" получаем примерно 21,5TB под полезные данные + снэпшоты. Понятно, что в теории использование дедупа и сжатия может компенсировать нам часть этих потерь. Но есть сомнения, что на реальных первичных данных коэффициент будет хотя бы 3:1.
Возьмем две разные машины с двигателем 1.5 литра, и две с двигателями по 2.0. Будете ли вы считать реальную мощность с литра и сравнивать все машины по лс/литр?
С комплексными ИТ системами примерно та же история. Вам нужна конкретная продуктивная емкость хранения при определенной вычислительной мощности и определенном уровне отказоустойчивости под конкретные задачи и данные. Система 1 делает это за X руб, Система 2 за Y, Система 3 за Z.
При этом система 1 делает это на A дисках, 2 — на B, 3 на С. Какая разница сколько дисков там стоит внутри, если стоимость софта, использующего меньше дисков, превышает стоимость остальных дисков? Какая принципиальная разница какой идет системный оверхед, если итоговые ресурсы полностью удовлетворяют тех требованиям, а в бюджет укладывается?
Если у вас есть сомнения в том, что заявленная итоговая продуктивная емкость системы на конкретно ваших данных не будет соответствовать тех требованиям из-за специфики данных и низких коэффициентов компрессии — проводите пилот, проверяйте и пересчитывайте конфигурации.
И снова — пусть он будет не 3:1, а 2.5 или даже упаси Ньютон 1.5:1.
Система стоит X рублей, ТЗ удовлетворяет, при этом по конкурсу проходит. После того как ТЗ удовлетворено — не имеет смысла обсуждать что там под капотом, остается только сравнивать стоимость.
Да я в общем-то согласен :). Потому и написал, что тут вопрос цены. Ну и не плохо когда вся цепочка продаж и сам заказчик понимает в чем разница между сырой емкостью и полезной.
Зачем нужна гиперконвергенция? Обзор и тесты Cisco HyperFlex