Привет, SE7EN.
На связи команда Jet Infra Team. Недавно к нам в руки попал дисковый массив Tatlin Unified Gen 2, разработанный компанией YADRO и зарегистрированный в реестре Минпромторга. Мы решили посмотреть, на что способна эта «лошадка» и действительно ли она подходит для хранения продуктивных данных нагруженных транзакционных СУБД и сред виртуализации.
Итоги тестов разбили на две части.
-
В первой рассказываем, как мы собирали тестовый стенд и проверяли надежность отечественного дискового массива;
-
Во второй статье поделимся результатами тестирования функционала и производительности в рамках нашего тестового окружения.
Поехали!
P.S. Коллеги, мы с вами прекрасно понимаем, что для достижения максимальной производительности любого дискового массива, особенно в условиях синтетического тестирования, должны быть соблюдены некоторые технические условия как в окружающей ИТ-инфраструктуре (скорость и количество портов ввода-вывода на серверах, скорость портов на сетевых устройствах, топология подключения), так и в настройках системного и прикладного ПО (настройки MTU, параметры утилиты тестирования, настройки ОС и многое другое).
Тестовое окружение
Демостенд мы развернули в нашей лаборатории импортозамещения Jet RuLab и традиционно разбили тестирование на три параллельных этапа:
-
Функциональный — оценка работоспособности системы хранения данных при штатных режимах эксплуатации;
-
Нагрузочный — оценка производительности с использованием инструментов для создания синтетической нагрузки;
-
Испытания надежности — оценка работоспособности при нештатных режимах эксплуатации.
В этой части статьи мы посмотрим на наше тестовое окружение и сразу рассмотрим тесты на надежность. Результатами функциональных и нагрузочных испытаний поделимся в отдельной статье — там много всего интересного получилось.
Физическая архитектура дискового массива стандартно предусматривает дублирование внутренних аппаратных компонентов и каналов передачи данных для обеспечения отказоустойчивости. Вычислительная подсистема контроллерного шасси 3U представляет собой отказоустойчивый кластер из двух контроллеров хранения, которые работают в режиме Symmetric Active-Active.
Кластер поддерживает удаленный прямой доступ к памяти (RDMA) с использованием дублированного канала RoCE (RDMA over Ethernet) между контроллерами хранения. Каждый контроллер построен на 12-ядерном процессоре Intel® Xeon® Scalable 2-го поколения, может подключаться к внешним сетям хранения данных с помощью карт расширения ввода-вывода с интерфейсами FC и Ethernet, а также представляет собой Unified Storage — одновременно SAN- и NAS-хранилище. Дисковые модули расширения (каждый по 4U) используются для размещения накопителей.
В зависимости от конфигурации в состав дискового массива может входить до шести модулей DBS (дисковая полка расширения). Модуль DBS может вмещать:
-
до 94 накопителей SAS, если он единственный или подключен первым в составе дискового массива.
-
до 96 накопителей SAS для последующих модулей.
Наш же комплекс состоял из следующих компонентов:
|
Аппаратная конфигурация дискового массива . |
1 × контроллерное шасси |
|
Подключение DBS . |
4x SAS (по 2 SAS-подключения на контроллер) . |
|
Оперативная память . |
512 ГБ DDR4 ECC RAM . |
|
Версия ПО . |
2.8.7-135 . |
|
Порты ввода/вывода (тип, скорость передачи данных) . |
4 × 32 Gb/s FC интерфейса |
|
Накопители дискового массива (тип, объем) . |
16 x 7.68 TB SAS SSD 1DWPD 2.5” . |
Подключение серверов нагрузочного тестирования к дисковому массиву было реализовано через коммутаторы сети хранения данных iSCSI.
Также в составе оборудования были два сервера Fplus FPD-13 в следующей конфигурации:
|
Наименование . |
ruLab-FP-srv1 . |
ruLab-FP-srv2 . |
|
Процессор . |
2 x Intel Xeon Silver 4310 12C 2.10GHz . |
2 x Intel Xeon Silver 4310 12C 2.10GHz . |
|
Оперативная память . |
256 GB RAM . |
256 GB RAM . |
|
Встроенные диски (под ОС) . |
2x 960 GB SSD . |
2x 960 GB SSD . |
|
Сетевые интерфейсы . |
1 x 2x10G SFP+ . |
1 x 2x10G SFP+ . |
|
Операционная система . |
Windows Server 2016 . |
Astra Linux 1.7 x86-64 . |
|
ПО мультипасинга . |
Встроенный драйвер Microsoft MPIO . |
Встроенный драйвер DM-Multipath . |
|
Инструмент генерации нагрузки . |
Oracle Vdbench 5.04 . |
Oracle Vdbench 5.04 . |
|
Клиент доступа к серверам и CLI дискового массива . |
Putty, MPutty (v1.8) . |
Putty, MPutty (v1.8) . |
|
Версия прошивки дискового массива . |
2.8.7-135 . |
2.8.7-135 . |
В качестве сети передачи данных использовали два коммутатора Ethernet (топология dual fabric), с помощью которых по протоколу iSCSI серверы получали доступ к логическим томам дискового массива по интерфейсам со скоростью передачи данных 10 Гб/с. На портах коммутаторов, дискового массива и серверах были выставлены значения MTU 9000.
Тестирование надежности
При проведении тестов на отказоустойчивость выполнялась проверка с помощью встроенной системы мониторинга, которая должна была зарегистрировать изменение статуса компонентов дискового массива.
Мы эмулировали фоновую нагрузку с помощью генератора Vdbench порядка 150k IOPS (iorate=150 000):
#host definition
hd=astra1,system=10.31.131.70,vdbench=/root/vdbench,shell=vdbench,user=root,
jvms=5,master=10.31.131.70
###################
#storage_definition on host1
sd=default
#astra1
sd=sd_bench01_0,host=astra1,lun=/dev/dm-0,openflags=o_direct
sd=sd_bench01_1,host=astra1,lun=/dev/dm-1,openflags=o_direct
sd=sd_bench01_2,host=astra1,lun=/dev/dm-2,openflags=o_direct
sd=sd_bench01_3,host=astra1,lun=/dev/dm-3,openflags=o_direct
sd=sd_bench01_4,host=astra1,lun=/dev/dm-4,openflags=o_direct
sd=sd_bench01_5,host=astra1,lun=/dev/dm-5,openflags=o_direct
sd=sd_bench01_6,host=astra1,lun=/dev/dm-6,openflags=o_direct
sd=sd_bench01_7,host=astra1,lun=/dev/dm-7,openflags=o_direct
###################
#workload_definition
wd=wd1,sd=sd*,xfersize=8k,rdpct=70,seekpct=100
###################
#run_definition
rd=rd1,wd=wd*,iorate=max,elapse=21600,interval=10,warmup=30,forthreads=16
Чтобы убедиться в устойчивости «железа» к отказам, было проверено несколько возможных сценариев. Рассказываем, что из этого вышло.
Выключение портов ввода/вывода
Решили физически отключить iSCSI-порты p40 и p50 на контролере SP-0.
Сначала мы получили подобные сообщения со стороны хоста linux1 к устройствам хранения по протоколу iSCSI.
В момент отключения iSCSI-порта p50 sp-0 график отображал небольшую просадку, но массив почти сразу (спустя 3–5 сек.) начал работать в штатном режиме:
Аналогичные результаты мы получили после отключения iSCSI-порта p40 sp-0:
В момент отключения двух портов со стороны дискового массива мы увидели потерю путей и на хосте:
Когда оба порта были снова подключены, статус путей вернулся в исходное работоспособное состояние:
При этом графики остались неизменными — производительность вернулась на исходный уровень:
Отключение SAS-портов от дисковой полки
Со стороны модуля хранения был физически изъят один SAS-кабель. Отключение SAS-порта (со стороны дисковой полки) привело к значительной деградации производительности, что видно на графиках. Однако ввод и вывод не прервался.
В момент отключения порта SAS-0 системой не было заведено никаких алертов, при этом в веб-интерфейсе и CLI отображался статус «ОК»:
Тем не менее в системном журнале мы увидели критические сообщения о недоступности SAS-0:
После подключения порта SAS-0 обратно штатная работа дискового массива восстановилась спустя 10 секунд. В прошлом поколении при отключении полки были проблемы с перезагрузкой контроллера, которые решались только после обновления прошивки.
Отказ двух дисков в полке
Нагрузка была инициирована с помощью Vdbench на логические тома на базе SSD-дисков. Выбор дисков, подлежащих извлечению, осуществлялся в случайном порядке. В первую очередь был извлечен SSD-диск из слота 7 (12:39), после чего производительность немного увеличилась:
Здесь мы наблюдали достаточно интересную картину, когда при извлечении одного диска у нас начала расти производительность на 3000–4000 iOPS. Почему так произошло? Смотрите в выводах!
В момент извлечения второго диска (слот 4, 12:53) мы наблюдали повторный рост производительности:
После того как мы установили диски обратно, началась процедура ребилда, во время которой мы наблюдали просадку производительности и увеличение времени отклика.
По истечении 30 минут встроенная система мониторинга зафиксировала следующие оповещения:
Отказ контроллера дискового массива
По причине конструктивных особенностей дискового массива у нас не получилось физически извлечь контроллер, поэтому отказ был инициирован из консоли управления (CLI).
При отключении контроллера наблюдалась кратковременная просадка производительности длительностью 5–7 секунд, но ввод-вывод полностью не останавливался. Наоборот, был замечен незначительный рост.
После включения контролера массив работал в штатном режиме:
Нештатное отключение дискового массива от электрической сети
Для выполнения данной проверки на файловой системе NFS, презентованной с дискового массива на хост, была создана директория с файлами. После этого массив был выключен нештатным путем — при помощи отключения кабеля питания контроллеров и дисковых полок.
Проверка консистентности проводилась путем расчета общей хэш-суммы всех файлов до и после перезапуска. До отключения системы от электрической сети мы наблюдали следующую хэш-сумму:
После повторного запуска дискового массива мы проверили наличие ошибок в файловой системе со стороны сервера и возможность чтения данных. А также убедились в том, что хэш-суммы до и после нештатного выключения совпадают.
Потеря RDMA-соединения
Подключение между контроллерами хранения реализовано по интерфейсу RDMA с использованием специальных двухпортовых карт со скоростью передачи данных 100 Гбит/с. В этом тесте при отключении одного из портов мы не заметили как потери, так и прироста по производительности.
Однако в момент отключения rdma0 встроенная система мониторинга не отобразила данное событие как критичное, только как информационное. При этом второй порт продолжал функционировать в штатном режиме.
Отключение блоков питания контроллерного шасси и дисковой полки от электрической сети
Данная проверка выполнялась с помощью физического отключения кабелей от одного из блоков питания. Отключение блоков питания как контроллерного шасси, так и дисковой полки не привело к потере доступа к данным или просадкам производительности. В веб-интерфейсе зафиксированы критичные сообщения об аппаратных ошибках, которые исчезли, когда блоки питания вернулись в исходное состояние.
Первые выводы
По общему впечатлению, дисковый массив прошел успешно все испытания надежности. Значительных недостатков при проведении тестов мы не обнаружили, но есть детали, которые хотим дополнительно отметить.
-
Основное, что заметил внимательный читатель, — это аппаратные ограничения нашего тестового окружения: всего два сервера с двухпортовыми адаптерами 10G и сетевые коммутаторы, которые by design работают на скорости 10G, в то время как массив имеет возможность работать на скорости 25G. Даже 150k IOPS, заданные в рамках данного теста, — это не предел. Но о результатах, полученных в рамках нашего тестового окружения, расскажем во второй части.
Ограничения производительности связаны именно с тем, что наши сервера и сеть являются узким местом, и максимальную заявленную вендором производительность мы пока не достигли (хотя к ней приблизились).
-
При отключении части iSCSI-портов массив продолжал исправно работать на оставшихся интерфейсах без значительной потери производительности — всего она упала на 4–5%. В ходе теста встроенный мультипасинг хостов отработал штатно.
-
При отключении одного из SAS-портов со стороны полки расширения массив потерял четверть путей к дискам. При этом наблюдалась 50-процентная просадка производительности.
-
При извлечении дисков тесты показали, что в первые 30 минут (до начала ребилда) массив продолжает работать в штатном режиме, а вот уже дальше происходит просадка производительности. Обращаем внимание, что повторное использование извлеченных дисков допустимо до начала процедуры ребилда — только в течение 30 минут и только с подтверждения производителя. Это связано с тем, что сам массив помечает диски как «сбойные» и сброс этой метки возможен только через специальную процедуру, проводимую вендором. Использовать эту процедуру в продуктиве крайне не рекомендуется, поэтому, если диск вышел из строя, лучше открыть кейс и заменить его. В период восстановления данных необходимо остановить административные действия, выполняемые на дисковом массиве, включая создание, удаление, маппинг логических томов и т.д. Что касается незначительного (на 3-4k IOPS) роста производительности при отключении дисков, мы обратились к производителю через сервисный кейс. Воспроизвести это поведение в результате тестов не удалось, а в наших — оно более не повторялось. Проведем дополнительный тест во время нагрузочных испытаний, чтобы исключить СХД.
-
При отключении одного из контроллеров наблюдался небольшой прирост производительности (на 3%), связанный с тем, что Vdbench генерирует IOPS равномерно между контроллерами. Однако за счет отсутствия подтверждения записи соседнего контроллера (зеркалирования) снижается время отклика.
-
При отключении электропитания мы не заметили никаких проблем после перезапуска. После отключения одного из RDMA-портов массив продолжал работать в штатном режиме, но есть замечания к уровню критичности отображаемых событий во встроенной системе мониторинга.
Большинство сервисных операций, таких как замена неисправных компонентов, обновление системного ПО и других, могут быть реализованы только при помощи специальной сервисной учетной записи производителя. Это означает, что эксплуатация данного массива полноценно возможна только при наличии вендорской поддержки, квалифицированных инженеров, возможности их удаленного подключения на площадку. Ну и про склад запчастей не говорим — это само собой разумеющееся.
Будем рады любым вашим вопросам :.
P.S. Результаты функциональных и нагрузочных тестов — to be continued.
Авторы:
Игорь Шконда, начальник отдела систем хранения данных «Инфосистемы Джет». Артур Базирувиха, инженер-проектировщик систем хранения данных «Инфосистемы Джет.
