Полное тестирование СХД Huawei OceanStor Dorado 18000 V6
Вычислительные комплексы Вычислительные комплексы

Сколько серверов нужно, чтобы выжать максимум из новой СХД? Насколько выгоден Dorado 18000 V6 с финансовой точки зрения? Зачем к тестам подключался специалист 3-й линии поддержки?

Главная>Вычислительные комплексы>Не СХД, а болид «Формулы-1»: тестируем Huawei OceanStor Dorado 18000 V6
Вычислительные комплексы Обзор

Не СХД, а болид «Формулы-1»: тестируем Huawei OceanStor Dorado 18000 V6

Дата публикации:
24.02.2022
Посетителей:
468
Просмотров:
447
Время просмотра:
2.3

Авторы

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

 

Сколько серверов нужно, чтобы выжать максимум из новой СХД?


Насколько выгоден Dorado 18000 V6 с финансовой точки зрения?


Зачем к тестам подключался специалист 3-й линии поддержки?

 

 

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

 

Компактная и мощная, как ручка-граната Джеймса Бонда, система хранения данных 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.

Продвинутая технология дедупликации и компрессии Dorado V6 по уровню хранения ставит нашего испытуемого на одну ступень с лидерами отрасли по данному показателю.

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


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

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

Квалификация

 

Кроме 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, разумеется, проверили в самом начале.

 

Полтысячи страниц IBM AIX Performance Management Guide не дали подсказки, и дело дошло до третьей линии поддержки IBM. Пришлось собрать «тонну» логов perfpmr и провести целую серию повторных испытаний с разными комбинациями параметров.

«Ложечка» таки нашлась. Чтобы 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, реализован файловый доступ. При первой возможности постараемся их протестировать.

Уведомления об обновлении тем – в вашей почте

«С точки зрения инфраструктуры мы находимся в переходном периоде»

Почему «МультиКарта» продолжает использовать ПО, созданное в 2000-х? Можно ли считать Open Source двигателем ИТ-индустрии? В каком случае контейнеризация не имеет смысла?

Архив без пыльных полок, или Способы организации архива предприятия

С древних времен человечеству приходилось решать проблему хранения информации накопленных многими поколениями знаний, культурных, технических, научных и прочих ценностей. Решение проблемы тесно связывалось с применением технологий ...

Комплексный подход к защите данных. Все по делу, никаких смузи!

Почти все наши заказчики, внедрившие себе системы резервного копирования (СРК), думают, что на этом все их проблемы решены.

Современный SSD — расходный материал

Иногда приходится сталкиваться с тем, что к крутящимся жестким дискам (HDD) относятся как к расходному материалу. Отчасти это верно, так как механический износ со временем приводит к их поломке. Но само перемагничивание диска при записи данных может происходить нескончаемое число раз.

Вызовы обслуживания Инфраструктуры 3.0

Что лежит в основе новых инфраструктурных трендов? Задачи, которые ставит перед компаниями Инфраструктура 3.0. Как и с помощью чего их решать?

Построение многоуровневых систем хранения данных: роль Networked Storage Controller

Опыт работы компании «Инфосистемы Джет», подтверждая общие тенденции в области программных и аппаратных средств хранения информации, свидетельствует о том, что традиционные системы хранения данных (СХД) уже не могут в полном объеме удовлетворять ...

Что делать, если СХД болит

Сказать, что сегодня объем корпоративных данных растет, значит, не сказать ничего.

Практика применения решений HDS

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

Шлюзы как средство интеграции баз данных. Практический подход

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

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня