Комментарии 12
72 000 об/мин
У вас там турбонагнетатель? На порядок ошиблись :-)
Латенси на запись меньше чем на чтение, да ладно? Хотя, у вас же direct=1 без sync=N, так что тогда почти ожидаемо.
Параметры numjobs и iodepth для профиля FIO нужно выбирать так, чтобы соблюдалось оптимальное соотношение IOPS и задержек.
Параметры надо выбирать примерно такие, какие будут на вашей реальной нагрузке. Или взять какие общеприняты. А самое правильное - вообще прогнать на нескольки вариантах (например, iodepth=1/4/8/16/32/64 numjobs=1/2/4/8/16).
Подбирать же параметры теста чтобы показать цифры получше, скажем так, считается не самой лучшей практикой
72 000 об/мин
Спасибо за внимательность, исправили :)
Параметры надо выбирать примерно такие, какие будут на вашей реальной нагрузке. Или взять какие общеприняты. А самое правильное - вообще прогнать на нескольки вариантах (например, iodepth=1/4/8/16/32/64 numjobs=1/2/4/8/16).
Подбирать же параметры теста чтобы показать цифры получше, скажем так, считается не самой лучшей практикой
Абсолютно верно, при тестирования СХД под конкретную задачу параметры нагрузки должны максимально соответствовать реальным. Но в нашем случае такой задачи не стояло, поэтому взяты рекомендуемые вендором профили нагрузки для тестирования, и тут логично, что они призваны показать хорошие значения производительности СХД.
взяты рекомендуемые вендором профили нагрузки для тестирования
Но оборудование под эти профили, по всей видимости, подобрать забыли, поэтому в табличке "расчетная" псп на FC при последовательном доступе превышает теоретическую псп интерфейсов таргета. Ожидаемо, при тестировании цифры оказались вдвое меньше, а iSCSI на таком конфиге оказался практически на одном уровне с FC (в отличие от таблицы).
Ничего не понятно, но очень интересно.
Для кого предназначена такая СХД?
Какие есть в ней фичи (группы консистентности, снапшоты)
Есть ли альтернативные способы подачи места (NVME over fabrics - tcp/roce - или только NVME over FC)
Какой объем диска на сколько лунах по какому протоколу будет использоваться.
Путь мне для 200Тб места надо группу консистентности на 100 лун по 2Тб + немного под репликационные журналы.
Раскидано оно будет примерно равномерно.
Какие тогда будут задержки на журнальных дисках по iScsi для оптимизации посылки команд на стороне клиента и при отключении оной.
За сколько будет создан снапшотик группы консистентности (без журналов), сможет ли с таким снапшотом СУБД бизнес копию сделать.
Если таких серверов не один, и подключать по iScsi - то сколько всего портов на 25Гб можно будет утилизировать?
Просто пишете платформа поменялась, а что из этого выходит непонятно.
Ну или описать типовое применение для такой СХД, и почему именно такие работы и глубины выбраны
СХД предназначено для широкого спектра задач, вендор позиционирует продукт как «Система для корпоративных приложений, больших данных и аналитики».
Что касается аппаратных и программных возможностей, то они постоянно добавляются и дорабатываются. А если говорить непосредственно про снэпшоты с группами консистентности — да, такая функциональность есть в текущей версии продукта. Мы постарались не перегружать вводные своего тестирования информацией, которую можно почерпнуть у вендора, например, вот из этой общедоступной презентации — https://st.yadro.com/docs/Tatlin/YADRO_TATLIN_UNIFIED_GEN2_Presentation_RUS.pdf
Оставшийся пул Ваших вопросов стоит рассматривать в рамках конкретной задачи сайзинга. В рамках базового тестирования, увы, невозможно охватить и учесть все возможные конфигурации и требования со стороны систем‑потребителей СХД. Надеемся, в будущем у нас будет возможность «похвастаться» конкретными конфигурациями и показателями, которые будут достигнуты на продуктивных внедрениях этой СХД у заказчиков.
Спасибо за информацию.
Про снапшоты и группы консистентности не просто так спросил.
Сферическая производительность в вакууме хорошо, но что будет с ней, если в 12 часов ночи резко попросят создать 12 чнапшотов, на которых бизнесс-копии баз (с активного раздела и раздела только для чтения), и раз это бизнесс копии, то на них злобно начнут перелопачивать данные (до следующих снятий снапшотов), да и в основной базе изменения будут идти потоком.
Понятно, что никто так не может, создание копий разносится по времени. Потому что от такого СХД плохеет. Но вы же стресс тестируете такое, чтобы сказать заказчикам - вот столько снапшотов во столько терабайт одновременно делать стоит, но лучше на вот столько разносить эти процессы.
Полтора миллиона IOPS в презентации (случайное чтение 4k, без записи) хорошо, но интересны же пиковые нагрузки и как все от этого проседает.
на картинке с котёнком и вертолётами котёнок как раз о таком думает, наверное.
А можете привести графики от fio при тесте на отключение контроллера?
А почему диски такие маленькие? Давно на 100+tb появились
Традиционно, первоочередной задачей тестирования систем хранения является достижение высоких показателей производительности. Для этих целей хорошо подходят небольшие SSD-диски. Гонки же в формате «кто больше может хранить» для традиционных СХД остались в прошлом и являются актуальными разве что для архивных систем хранения, но это уже совсем другая история.
Актуальный перечень поддерживаемых дисковых накопителей для системы TATLIN.UNIFIED Gen2 можно посмотреть по ссылке: https://yadro.com/ru/tatlin/unified/gen2/specs
Тестируем СХД Tatlin.Unified Gen2