«Не СХД, а болид “Формулы-1”», — подумал я, когда увидел анонс нового топового массива от Huawei. А еще со скепсисом: «Посмотрим, как этот суперкар покажет себя на трассе». И вот мне посчастливилось «обкатать» Huawei OceanStor Dorado 18000 V6, нагрузив ее синтетическими и прикладными тестами. Делюсь полученными результатами. Заодно получилось пройти незапланированный квест в поисках параметра, который вначале заметно портил картину производительности на AIX. Итак, под кат.

Сила Dorado

Компактная и мощная, как ручка-граната Джеймса Бонда, система хранения данных OceanStor Dorado 18000 V6 уместилась в четырех юнитах без учета дисковых полок. Нам на тесты досталась четырехконтроллерная система с четырьмя дисковыми полками, в которых установлено 60 накопителей 1,92 TB NVMe форм-фактора Palm-Size.

Из такой конфигурации, согласно сайзеру, можно «выжать» до 1,5 млн IOPS на стандартном профиле 70R/30W 8K, 100% random, 0% read Cache Hit.

Одно контроллерное шасси рассчитано на установку четырех контроллеров. Но к дисковым полкам по протоколу 100Gb RDMA можно подключить два шасси, т.е. до восьми контроллеров без использования внешних коммутаторов. А если использовать дополнительные свичи — число контроллеров на одну систему можно увеличить до 32, чтобы получить максимум производительности и емкости. 

Dorado 18000 V6 поддерживает функцию тройного кэширования. Кэш зеркалится между тремя контроллерами. Поскольку у нас на тестах была четырехконтроллерная система, мы протестировали отказ трех контроллеров из четырех: сначала два контроллера одновременно, а затем еще один. В конфигурации на восемь контроллеров система устойчива к отказу до семи контроллеров. 

В обоих случаях, даже если остался доступен один контроллер, пользователи продолжат работать. 

Гонка началась

В качестве тестовой платформы для Dorado 18000 V6 мы использовали сервер AIX с четырьмя портами 16 Gb Fibre Channel, подключенный через SAN на базе двух коммутаторов Brocade GEN5 16 Gb. Для проведения нагрузочного тестирования реального приложения на тестовый LPAR мы реплицировали копию реальной базы данных средствами СУБД Oracle. А синтетические тесты проводили на базе Vdbench.

Результаты «заезда»

Самый первый и важный результат, который удалось получить — это коэффициент эффективности хранения данных 5.2:1. Он получен для одной копии продуктивной базы на 85 ТБ, которую мы разместили на Dorado V6.

Учитывая, что средний коэффициент эффективности для баз данных составляет 3.5:1, продвинутая технология дедупликации и компрессии Dorado V6 по уровню хранения ставит нашего испытуемого на одну ступень с лидерами отрасли по данному показателю. 

Второй важный результат — время закрытия операционного дня. На тестовом сервере была запущена процедура закрытия дня, и на уровне приложения собрана детальная статистика. В связке с Huawei Dorado V6 тестовый сервер показал закрытие операционного дня на 6% быстрее по сравнению с продуктивным сервером, которому были выданы диски со «взрослой» All-Flash СХД уровня High-End от другого производителя. При этом у нашего тестового сервера было в четыре раза меньше процессорных ресурсов, и расчетные операции выполнялись дольше. Но в целом из-за ускорения ввода-вывода процедура завершилась быстрее.

Впечатляющая скорость работы дисков смогла компенсировать меньшее количество вычислительных ресурсов. Действительно, на Huawei Dorado V6 выборки данных и сортировки с использованием дискового пространства выполнялись быстрее до 80%.

Синтетические тесты (Qualification)

Кроме Dorado 18000 V6 NVMe, нам удалось протестировать и младшие модели линейки — Dorado 3000 V6 SAS и Dorado 5000 V6 NVMe. Сводная таблица результатов синтетики ниже:

Пояснения к профилям нагрузки в таблице:

• Random – 65R/35W 8K, 100% random;

• Sequential – 256K, 100% write;

• БД1 Like – смешанный профиль, 40KB random read, 24KB random write (90R/10W);

• БД2 Like — смешанный профиль, 115KB random Read, 72KB random write (70R/30W);

• Vmware Like смешанный профиль, 86KB random read, 11KB random write (46R/54W).

Все тесты выполнялись при включенной дедупликации и компрессии. Дисковый пул был инициализирован в RAID6. Сравнительно более низкие показатели на один лун можно объяснить ограничениями со стороны хоста на длину очереди. При использовании нескольких хостов для доступа к луну с кластерной файловой системой можно получить более высокие показатели производительности. Здесь СХД не является узким местом, что видно из загрузки CPU контроллеров и низкого времени отклика со стороны СХД.

Взойти на пик производительности

Чтобы приблизиться к расчетной производительности СХД, одного тестового сервера нам не хватило. В тестовом LPAR было всего четыре интерфейса по 16 Гбит FC, которые могли обеспечить ввод-вывод со скоростью до 6 ГБ/с в каждом направлении. 

Для увеличения нагрузки мы нашли два дополнительных тестовых сервера Huawei Taishan 2000 (Model 2280) на базе ARM. Один из серверов был оснащен одним двухпортовым адаптером FC 16 Gb, а второй — двумя такими же адаптерами. Итого мы использовали 10 портов FC для подключения серверов к СХД:

• сервер #1, AIX 7.2, 4 x порта FC 16Gb, 16 x LUN 500GB, RAID6;

• сервер #2, CentOS 7.6, 2 x порта FC 16Gb, 16 x LUN 500GB, RAID6;

• сервер #3, CentOS 7.6, 4 x порта FC 16Gb, 16 x LUN 500GB, RAID6.

В результате этого нагрузочного теста получили 1,3 млн IOPS, 9,9 ГБ/с при среднем времени отклика на массиве 0,53 мс, что очень близко к расчетным максимальным значениям из сайзера. По задержкам на массиве и 80% утилизации CPU контроллеров на графиках ниже, можно сделать вывод о запасе производительности для нашей конфигурации порядка 15%. 

Балансировка нагрузки

Встроенная функция балансировки автоматически распределяет нагрузку по всем контроллерам и модулям ввода-вывода. В Dorado V6 лун не требует привязки к контроллеру, а нагрузка даже на один лун автоматически распределяется по всем контроллерам и модулям ввода-вывода. 

Чтобы оценить ее в действии, мы презентовали тестовому серверу четыре луна и поочередно исключали из системы по одному луну. При этом все Front-End интерфейсы и контроллеры СХД были утилизированы равномерно.

Отказы разных компонентов системы

Во время серии тестов на отказоустойчивость мы создали на массив фоновую нагрузку Vdbench порядка 1 ГБ/с. На производительность массива ни отказ одной линии питания, ни отказ одного из адаптеров FC практически не повлияли.

Еще одна интересная функция отказоустойчивости — возможность работы при отказе трех контроллеров из четырех. Архитектурная особенность Dorado 18000 V6 в том, что каждый контроллер внутри шасси имеет подключение ко всем Back-End и Front-End модулям ввода-вывода. 

Таким образом, отказ контроллера или выполнение регламентных процедур по обслуживанию или обновлению СХД, связанных с перезагрузкой контроллеров, не приводит к появлению событий, требующих работы драйвера MPIO на стороне хоста.

На рисунках ниже сравнительная топология Dorado 18000 V6 в состоянии с четырьмя исправными контроллерами и в состоянии с одним исправным контроллером. При этом видно, что количество обслуживаемых Front-End интерфейсов не изменилось. Т.е. с точки зрения хоста все пути активны и доступны. То же относится и к Back-End подключениям полок.

На графиках ниже показаны штатная работа всех контроллеров, показатели при отказе двух контроллеров, и при отказе трех.

Когда диски говорят «нет»

В случае выхода одного или нескольких дисков из строя система начинает реконструкцию пула и выполняет его в фоновом режиме. В Dorado V6 RAID строится на чанках, а резерв емкости для горячей замены распределен по всем дискам. При этом для ребилда Dorado умеет использовать как специальный резерв, так и свободную емкость дискового пула. Мы убедились в доступности данных при одновременном отказе трех дисков для пула с RAID-TP, а также измерили время реконструкции диска в RAID6 под нагрузкой.

Сначала пул из 60 дисков 1,92 TB был инициализирован в RAID6. С помощью Vdbench была создана фоновая нагрузка на СХД — 140 000 IOPS, профиль 65R/35W 8K, 1,1 ГБ/с. Длительность реконструкции одного диска 1,92 TB под такой нагрузкой составила 69 минут. На графике ниже виден скачок задержки при отказе диска.

Затем на тех же 60 дисках 1,92 TB мы настроили пул в конфигурации RAID-TP. При одновременном отказе трех дисков время реконструкции пула без фоновой нагрузки составило 28 минут.

История таинственного параметра

В самом начале тестов возникла интересная ситуация, я бы сказал — аварийная. Подключив к тестовому серверу с ОС AIX 7.1 младшую модель Dorado 5000 V6, мы сразу получили максимально возможный для СХД результат, который соответствовал расчетному максимуму в сайзере.

А вот производительность Dorado 18000 V6 оказалась в несколько раз ниже, чем у Dorado 5000 V6! Но оказалось, что дело было не в СХД. Просто планировщик AIX при быстром росте нагрузки ввода-вывода и увеличении числа потоков начинал шейпить очередь до двух команд на LUN, что приводило к падению производительности почти на порядок! Мы получали около 80 тыс. IOPS вместо ожидаемого миллиона с лишним.

Проверили всё снова — на AIX 7.2 никаких проблем: 18000 V6 работала, как атомные часы. Учитывая, что в связке с Linux и Vmware тоже всё работало отлично — продолжили траблшутинг. Важно было найти решение именно для AIX 7.1, поскольку компания, для которой мы проводили тестирование, не собиралась массово переводить серверы AIX на новую версию OS. Полтысячи страниц IBM AIX Performance Management Guide не дали подсказки. 

Со своей стороны, в Huawei смогли собрать похожий стенд всего за несколько дней и воспроизвели нашу проблему у себя. После чего пришли к выводу, что сама СХД и ODM-драйверы от Huawei здесь не при чем.

Дело дошло до третьей линии поддержки IBM. К расследованию кейса подключился эксперт с опытом разработки драйверов для AIX. Пришлось собрать «тонну» логов perfpmr и провести целую серию повторных испытаний с разными комбинациями параметров, включая: прошивки FC адаптеров, версию драйвера СХД, параметры HBA, параметры LUN, разные механизмы балансировки путей ввода-вывода, разные сервис-паки OS, версию Java, альтернативные бенчмарки, включая xdisk, ndisk, dd. SAN, разумеется, проверили в самом начале.

«Ложечка» таки нашлась. Чтобы AIX 7.1 нормально работал с очень быстрыми «сырыми» дисками, нужно было изменить значение параметра spec_accessupdate. Странно, что этот параметр вообще не упоминается в AIX Performance Management Guide и практически не гуглится, а его описание в контекстном Help-е операционной системы очень краткое. Оказалось, что в AIX 7.1 и AIX 7.2 параметр имеет разные значения по умолчанию:

Purpose: Indicates for devices how timestamp changes are reflected.Values:

• 0 is standards-compliant behavior (default in AIX 7.1)

• 1 indicates access and update times are not changed

• 2 indicates lazy access/update changes (default in AIX 7.2)

Выставив значение параметра spec_accessupdate=2, мы получили стабильную высокую производительность подсистемы дискового ввода-вывода AIX 7.1 во всех последующих тестах. 

ioo -p -o spec_accessupdate=2

Поскольку Oracle ASM работает именно с «сырыми» дисками, правильное значение параметра spec_accessupdate в AIX 7.1 может значительно улучшить производительность дисковых операций СУБД. 

Что на финише?

В кубке конструкторов болид от Huawei, несомненно, борется за лидерство. Линейка Dorado V6 получилась надежной и функциональной. Это линейка СХД нового поколения, у которой совершенно новый неархаический дизайн с учетом ошибок и достижений всех основных конкурентов. Dorado V6 имеет удобный интерфейс — Device Manager стал понятнее и информативнее. Мониторинг производительности можно настроить на свой вкус. Есть интеграция с внешними системами мониторинга по SNMP. Несомненно, Dorado V6 — массив с «человеческим» лицом. Производительность и эффективность хранения данных Dorado V6 на высоте. 

Служба эксплуатации оценила простоту и скорость обновления Dorado V6. В этом помогает комплект утилит Huawei Smart Kit. Там же сбор диагностической информации для службы поддержки вендора. Минорные обновления прошивок Dorado V6 можно выполнять прямо из графической консоли управления Device Manager.

Кроме тестов на отказоустойчивость и производительность мы провели также тестирование катастрофоустойчивости на базе двух Dorado V6. Это целая тема для отдельного рассказа. Доступны как сценарии High-Availability с RPO=0, так и сценарии Disaster Recovery с использованием асинхронной репликации. Метро-кластер в этой линейке максимально простой и функциональный. Плюс правильные снапшоты Redirect-On-Write, плюс группы консистентности для снапшотов и репликации. А также ПО Business Continuity Manager (eReplication Suite) для управления сценариями автоматизированного переключения площадок в случае катастрофы.

У Huawei удобный сайзер eDesigner и конфигуратор SCT. Оценка производительности в сайзере подтвердилась тестами в реальной жизни: фактическая производительность Dorado V6 оказалась даже выше. Для знакомства с интерфейсом имеется симулятор, который можно установить на свой компьютер. А для полноценного функционального тестирования доступен виртуальный апплайнс Huawei OceanStor eStor. Совсем недавно у партнеров появился доступ к порталу eService для анализа производительности СХД support.eservice.huawei.com/#/Welcome. 

Несмотря на то, что на тесте реального приложения у нас было в четыре раза меньше процессорных ресурсов чем на продуктиве – закрытие дня прошло на 6% быстрее. В отдельных случаях это обещает существенную экономию. Во-первых, на уровне оборудования можно сэкономить на лицензиях на CPU Power. А, во-вторых, меньшее число процессоров для выполнения операции с нужным уровнем SLA требует пропорционально меньшего числа лицензий на СУБД или прикладное ПО. Суммарно это может значительно сократить стоимость владения системой. 

P.S. С момента нашего тестирования в программном обеспечении Dorado V6 появились важные обновления функционала. К ним относится поддержка протоколов NVMe over Fabrics: как NVMe over RoCE, так и NVMe over FC. А также в линейке Dorado V6, начиная с модели 5000, реализован файловый доступ. При первой возможности постараемся их протестировать.

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