Безудержное веселье, или Как мы тестировали отказоустойчивость Tatlin Unified Gen 214.01.2025 17:46

Привет, Хабр!

На связи команда Jet Infra Team. Недавно к нам в руки попал дисковый массив Tatlin Unified Gen 2, разработанный компанией YADRO и зарегистрированный в реестре Минпромторга. Мы решили посмотреть, на что способна эта «лошадка» и действительно ли она подходит для хранения продуктивных данных нагруженных транзакционных СУБД и сред виртуализации.

Итоги тестов разбили на две части:

• В первой рассказываем, как мы собирали тестовый стенд и проверяли надежность отечественного дискового массива;

• Во второй статье поделимся результатами тестирования функционала и производительности в рамках нашего тестового окружения.

Поехали!

Фото из нашей лаборатории Jet RuLab

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 для последующих модулей.  

Наш же комплекс состоял из следующих компонентов:

Подключение серверов нагрузочного тестирования к дисковому массиву было реализовано через коммутаторы сети хранения данных iSCSI.

Схема демостенда

Также в составе оборудования были два сервера Fplus FPD-13 в следующей конфигурации:

В качестве сети передачи данных использовали два коммутатора 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:

Вывод команды multipath –ll со стороны хоста

Вывод команды dmesg –t со стороны хоста

Извлечение оптического кабеля из порта p50 на контролере SP-0

Статус iSCSI-порта p50 на контролере SP-0

В момент отключения iSCSI-порта p50 sp-0 график отображал небольшую просадку, но массив почти сразу (спустя 3–5 сек.) начал работать в штатном режиме:

График производительности на дисковом массиве при отключении первого порта

Аналогичные результаты мы получили после отключения iSCSI-порта p40 sp-0:

График производительности на дисковом массиве при отключении второго порта

Статус iSCSI-портов p50 и p40 на контролере SP-0

В момент отключения двух портов со стороны дискового массива мы увидели потерю путей и на хосте:

Статус путей со стороны хоста при отключении двух портов

Когда оба порта были снова подключены, статус путей вернулся в исходное работоспособное состояние:

Статус путей со стороны хоста при подключении двух портов

При этом графики остались неизменными — производительность вернулась на исходный уровень:

График производительности со стороны массива при подключении двух портов

Отключение SAS-портов от дисковой полки

Со стороны модуля хранения был физически изъят один SAS-кабель. Отключение SAS-порта (со стороны дисковой полки) привело к значительной деградации производительности, что видно на графиках. Однако ввод и вывод не прервался.

Отключение порта SAS-0

Отключение порта SAS-0

График производительности со стороны массива при отключении порта SAS-0

В момент отключения порта SAS-0 системой не было заведено никаких алертов, при этом в веб-интерфейсе и CLI отображался статус «ОК»:

Отсутствие критичных уведомлений в CLI при отключении порта SAS-0

Тем не менее в системном журнале мы увидели критические сообщения о недоступности SAS-0:

Критические сообщения при отключении порта SAS-0 в веб-интерфейсе

После подключения порта SAS-0 обратно штатная работа дискового массива восстановилась спустя 10 секунд. В прошлом поколении при отключении полки были проблемы с перезагрузкой контроллера, которые решались только после обновления прошивки.

График производительности со стороны массива при подключении порта SAS-0

Отказ двух дисков в полке

Нагрузка была инициирована с помощью Vdbench на логические тома на базе SSD-дисков. Выбор дисков, подлежащих извлечению, осуществлялся в случайном порядке. В первую очередь был извлечен SSD-диск из слота 7 (12:39), после чего производительность немного увеличилась:

Сообщение о неисправности первого диска в веб-интерфейсе

Здесь мы наблюдали достаточно интересную картину, когда при извлечении одного диска у нас начала расти производительность на 3000–4000 iOPS. Почему так произошло? Смотрите в выводах!

График производительности со стороны массива при извлечении первого диска

В момент извлечения второго диска (слот 4, 12:53) мы наблюдали повторный рост производительности:

График производительности со стороны массива при извлечении второго диска

После того как мы установили диски обратно, началась процедура ребилда, во время которой мы наблюдали просадку производительности и увеличение времени отклика.

Производительность в момент после начала процедуры ребилда

Статус извлеченных дисков в веб-интерфейсе

По истечении 30 минут встроенная система мониторинга зафиксировала следующие оповещения:  

Полученные сообщения в системе мониторинга

Отказ контроллера дискового массива

По причине конструктивных особенностей дискового массива у нас не получилось физически извлечь контроллер, поэтому отказ был инициирован из консоли управления (CLI).

Наличие критических уведомлений в CLI при выключении контроллера

При отключении контроллера наблюдалась кратковременная просадка производительности длительностью 5–7 секунд, но ввод-вывод полностью не останавливался. Наоборот, был замечен незначительный рост.

График производительности при отключении контроллера в веб-интерфейсе

После включения контролера массив работал в штатном режиме:

График производительности при включении контроллера в веб-интерфейсе

Нештатное отключение дискового массива от электрической сети

Для выполнения данной проверки на файловой системе NFS, презентованной с дискового массива на хост, была создана директория с файлами. После этого массив был выключен нештатным путем — при помощи отключения кабеля питания контроллеров и дисковых полок.

Проверка консистентности проводилась путем расчета общей хэш-суммы всех файлов до и после перезапуска. До отключения системы от электрической сети мы наблюдали следующую хэш-сумму:

Хэш-сумма до выключения питания дискового массива

После повторного запуска дискового массива мы проверили наличие ошибок в файловой системе со стороны сервера и возможность чтения данных. А также убедились в том, что хэш-суммы до и после нештатного выключения совпадают.

Хэш-сумма после включения питания дискового массива

Потеря RDMA-соединения

Подключение между контроллерами хранения реализовано по интерфейсу RDMA с использованием специальных двухпортовых карт со скоростью передачи данных 100 Гбит/с. В этом тесте при отключении одного из портов мы не заметили как потери, так и прироста по производительности.

Физическое отключение одного RDMA-порта

График производительности при отключении одного RDMA-порта

Наличие критичных уведомлений при отключении одного RDMA-порта

Статус порта rdma0 в веб-интерфейсе

Однако в момент отключения rdma0 встроенная система мониторинга не отобразила данное событие как критичное, только как информационное. При этом второй порт продолжал функционировать в штатном режиме.

Системные события в веб-интерфейсе на дисковом массиве

Отключение блоков питания контроллерного шасси и дисковой полки от электрической сети

Данная проверка выполнялась с помощью физического отключения кабелей от одного из блоков питания. Отключение блоков питания как контроллерного шасси, так и дисковой полки не привело к потере доступа к данным или просадкам производительности. В веб-интерфейсе зафиксированы критичные сообщения об аппаратных ошибках, которые исчезли, когда блоки питания вернулись в исходное состояние.

Отключение кабеля питания из дисковой полки

Отключение кабеля питания из контроллерной полки

Сообщения в CLI об отключении блоков питания

Аварийная индикация на отключение блоков питания в веб-интерфейсе

Первые выводы

По общему впечатлению, дисковый массив прошел успешно все испытания надежности. Значительных недостатков при проведении тестов мы не обнаружили, но есть детали, которые хотим дополнительно отметить.

1. Основное, что заметил внимательный читатель, — это аппаратные ограничения нашего тестового окружения: всего два сервера с двухпортовыми адаптерами 10G и сетевые коммутаторы, которые by design работают на скорости 10G, в то время как массив имеет возможность работать на скорости 25G. Даже 150k IOPS, заданные в рамках данного теста, — это не предел. Но о результатах, полученных в рамках нашего тестового окружения, расскажем во второй части!

   Ограничения производительности связаны именно с тем, что наши сервера и сеть являются узким местом, и максимальную заявленную вендором производительность мы пока не достигли (хотя к ней приблизились).

Максимально возможная производительность

1. При отключении части iSCSI-портов массив продолжал исправно работать на оставшихся интерфейсах без значительной потери производительности — всего она упала на 4–5%. В ходе теста встроенный мультипасинг хостов отработал штатно.

2. При отключении одного из SAS-портов со стороны полки расширения массив потерял четверть путей к дискам. При этом наблюдалась 50-процентная просадка производительности.

3. При извлечении дисков тесты показали, что в первые 30 минут (до начала ребилда) массив продолжает работать в штатном режиме, а вот уже дальше происходит просадка производительности. Обращаем внимание, что повторное использование извлеченных дисков допустимо до начала процедуры ребилда — только в течение 30 минут и только с подтверждения производителя. Это связано с тем, что сам массив помечает диски как «сбойные» и сброс этой метки возможен только через специальную процедуру, проводимую вендором. Использовать эту процедуру в продуктиве крайне не рекомендуется, поэтому, если диск вышел из строя, лучше открыть кейс и заменить его. В период восстановления данных необходимо остановить административные действия, выполняемые на дисковом массиве, включая создание, удаление, маппинг логических томов и т.д. Что касается незначительного (на 3–4k IOPS) роста производительности при отключении дисков, мы обратились к производителю через сервисный кейс. Воспроизвести это поведение в результате тестов не удалось, а в наших — оно более не повторялось. Проведем дополнительный тест во время нагрузочных испытаний, чтобы исключить СХД.

4. При отключении одного из контроллеров наблюдался небольшой прирост производительности (на 3%), связанный с тем, что Vdbench генерирует IOPS равномерно между контроллерами. Однако за счет отсутствия подтверждения записи соседнего контроллера (зеркалирования) снижается время отклика.

5. При отключении электропитания мы не заметили никаких проблем после перезапуска. После отключения одного из RDMA-портов массив продолжал работать в штатном режиме, но есть замечания к уровню критичности отображаемых событий во встроенной системе мониторинга.

Большинство сервисных операций, таких как замена неисправных компонентов, обновление системного ПО и других, могут быть реализованы только при помощи специальной сервисной учетной записи производителя. Это означает, что эксплуатация данного массива полноценно возможна только при наличии вендорской поддержки, квалифицированных инженеров, возможности их удаленного подключения на площадку. Ну и про склад запчастей не говорим — это само собой разумеющееся.

Будем рады любым вашим вопросам :)

P.S. Результаты функциональных и нагрузочных тестов — to be continued!

Авторы:

Игорь Шконда, начальник отдела систем хранения данных «Инфосистемы Джет»

Артур Базирувиха, инженер-проектировщик систем хранения данных «Инфосистемы Джет»

Habrahabr.ru прочитано 928 раз