На рынке данное решение существует давно, и некоторые наши заказчики давно и успешно его используют. Однако, они не публикуют результаты тестов производительности своей инсталляции. Мы решили восполнить этот пробел и рассказать о нашем опыте использования Azure Stack HCI на одном конкретном примере.
Azure Stack HCI — это гиперконвергентное решение, сочетающее в себе несколько продуктов:
С документацией и общими сведениями об Azure Stack HCI можно ознакомиться по ссылке.
Для построения решения требуется аппаратная платформа, рекомендованная Microsoft. Ведущие производители серверного оборудования — HPE, Dell EMC, Fujitsu, Hitachi, Lenovo и др. — разработали свои конфигурации, протестировали их на совместимость и сертифицировали под Azure Stack HCI.
Полный список совместимого оборудования размещен по адресу.
В зависимости от типов используемых дисков, компоненты платформы будут отличаться.
Мы предпочитаем подобные решения строить на базе серверов Fujitsu с предустановленной операционной системой Windows Server 2019 Datacenter. Данный производитель после продажи поддерживает весь программно-аппаратный комплекс как законченное решение, а не только его аппаратную часть. Это важно и для нас, как для партнеров, и для конечного клиента.
На текущий момент, у Fujitsu сертифицированы пять конфигураций для разных типов дисков, моделей серверов и количества нод. Максимальное количество нод для Azure Stack HCI — 16, минимальное — 2, но некоторые конфигурации ограничивают до 4.
Все совместимые конфигурации Fujitsu можно посмотреть здесь.
Для инсталляции мы выбрали максимально-производительную конфигурацию из сертифицированных на данный момент — Fujitsu Primergy с накопителями SSD для хранения данных, и модулями сверхскоростной памяти Intel Optane, подключенными по интерфейсу NVMe в качестве кэша системы. Мы ожидаем получить программно-определяемый All-Flash массив с показателями, сравнимыми с классическим СХД с SSD дисками и NVMe-кэшем.
Подобные конфигурации по типу носителей есть у All-Flash систем хранения данных лидеров отрасли. Мы знаем, какие показатели по IOPS и задержкам можно на практике получить от подобных систем и рассчитываем на аналогичные показатели у Azure Stack HCI на базе выбранной конфигурации Fujitsu.
Архитектура данного решения Fujitsu подробно описана в документе, доступном по ссылке.
Рекомендуем ознакомиться с ним перед инсталляцией.
В документе приведены ограничения архитектуры, типовые схемы подключения, и много другой информации, полезной на этапе внедрения.
В решении Fujitsu используются собственные Ethernet-коммутаторы PSWITCH. Для себя мы отметили следующие преимущества:
Коммутационное оборудование Fujitsu является одним из лидеров отрасли в Японии. Оно недавно стало доступно на российском рынке, но уже регулярно используется в проектах нашими архитекторами и другими партнерами Fujitsu. На данный момент доступно ограниченное количество моделей.
Подробнее узнать про коммутаторы Fujitsu можно на официальном сайте.
Внутри сервера значительную часть места занимают платы памяти Intel Optane.
Intel уделяет много внимания работоспособности в условиях высокой тепловой нагрузки. С одной стороны, для максимально качественного охлаждения используются радиаторы большого размера. С другой, это ограничивает охлаждающий воздушный поток внутри всего сервера.
Это один из ключевых моментов, который учитывается при сертификации конфигурации — необходимо предусмотреть все возможные сценарии, при которых из-за недостаточного охлаждения серверы способны перегреть модуль Optane, или наоборот.
Наши клиенты при переезде серверной комнаты не раз сталкивались с ситуацией, когда система кондиционирования еще не была введена в эксплуатацию. Поэтому мы решили проверить, насколько требовательна данная инсталляция к системе охлаждения и замерить срок работы платформы под нагрузкой вне охлаждаемой серверной.
Тесты проводились при комнатной температуре, но мы не столкнулись ни с тепловыми ограничениями, ни со снижением производительности или появлением ошибок из-за перегрева. На своем опыте убедились, что тестируемые серверы поддерживают заявленную работоспособность при температуре окружающей среды до +45 градусов Цельсия.
Примечание. Этот эксперимент не стоит воспринимать как рекомендацию отказаться от использования специальных серверных помещений с качественной вентиляцией. При выборе поставщика аппаратных решений, обязательно обращайте внимание на максимальный температурный пакет.
Вид спереди:
Вид сзади:
В тесте использовался только один коммутатор. При коммерческой эксплуатации мы всегда рекомендуем резервировать пути доступа, используя не меньше двух коммутаторов. По нашей статистике, самая частая аппаратная неисправность в кластерах — случайный обрыв кабеля или нарушение контакта в разъеме.
В качестве сервера с управляющим ПО использовался Fujitsu RX1330. На него также были возложены функции арбитра и кворум-сервера.
Первый этап состоял из физического монтажа аппаратных компонентов, подключения интерфейсных кабелей и т.д. Далее следовала настройка ПО, т.к. операционная система уже предустановлена. На каждом сервере развернули Storage Space Direct и построили кластер из 2 нод и арбитра.
Затем мы использовали утилиту Fujitsu Infrastructure Manager — это расширение Windows Admin Center, которое тесно интегрируется с серверным оборудованием Fujitsu и содержит все инструменты управления из Azure, такие как:
Расширение позволяет автоматизировать ряд задач, которые также можно выполнить непосредственно в Admin Center.
Собрали Storage Pool, в нем создали Volumes. В этих томах в дальнейшем расположили виртуальные машины, для которых мы провели тесты производительности. И томами, и виртуальными машинами удобно управлять из одного окна.
Через Fujitsu Infrastructure Manager также удобно делать многие вещи по плановому обслуживанию и апдейту микрокода. Статус всего оборудования наглядно отображается, многое можно автоматизировать.
Существуют две версии утилиты Fujitsu Infrastructure Manager — платная и бесплатная:
Для глубокой интеграции Primergy с Microsoft Azure Stack HCI нужен плагин по управлению сервером из Windows Server, который доступен только в платной версии. Поэтому в состав решения «FUJITSU Integrated System PRIMEFLEX for Microsoft Azure Stack HCI» входит именно она.
Чем больше у вас инсталляция, тем ценнее автоматизация, которую дает утилита. В нашем стенде всего 2 ноды и мы могли делать все работы вручную. Если у вас 4 ноды или больше, то ПО значительно сократит ваши усилия на инсталляцию и администрирование. Стоимость утилиты составляет менее 1% от проекта, но значительно ускоряет ввод оборудования в эксплуатацию.
Для Windows Admin Center оркестратор Fujitsu Infrastructure Manager является пакетом расширения:
На этом же скриншоте виден состав дисковой подсистемы сервера: два модуля Optane используются как расширение кэша, и пять SSD-дисков как пул хранения Tier-1.
При построении решения есть несколько нюансов, которые нужно обязательно иметь в виду:
1. Управлять Microsoft Azure Stack HCI можно двумя способами — через Windows Admin Center либо Fujitsu Infrastructure Manager.
Admin Center тоже имеет свои преимущества — развернуть его можно на чем угодно, даже на ноутбуке; есть возможность управления из командной строки. С помощью него администратор может сделать почти все.
Есть еще Cluster Manager — незаменимый инструмент при каких-либо проблемах с кластером.
2. При развертывании Witness (кворум-сервера) важно добавить его в Active Directory и проверить его доступность всем нодам. Требования к данной задаче минимальны, и она может быть размещена на любом базовом сервере.
3. С точки зрения Windows Server, существуют три типа дисковых устройств — NVMe, SSD и HDD. Логика работы следующая: NVMe-устройства — это кэш на чтение/запись, SSD — уровень хранения Tier-1; HDD — уровень хранения Tier-2. Дальше можно настроить политики перемещения данных между пулами. В качестве кэша также могут использоваться модули NVDIMM.
Размер блока для тиринга по умолчанию равен 4К, но может меняться в зависимости от типа файловой системы на виртуальной машине. Это впоследствии будет влиять на производительность.
4. Мы используем NVMe модули в качестве кэш-памяти, поэтому скорость чтения и записи данных будут сильно отличаться — это будет хорошо видно на тестах производительности:
5. Перед созданием кластера необходимо выполнить валидацию и все тесты в Failover Cluster Manager. Отчет нужно сохранить, так как без него не получится открыть сервисное обращение в поддержке Microsoft, если когда-нибудь потребуется.
6. При добавлении новых нод в существующий кластер, ноды будут автоматически добавлены в Storage pool. Через 15 минут начнется автоматическое перестроение кластера, ребилд и балансировка Storage pool. Это может сказаться на производительности на время перестроения.
Теперь перейдем к самому интересному — к нагрузочному тестированию.
Тестируемая конфигурация:
Фактически, это программно-определяемая система хранения данных под управлением Windows Server 2019 Azure Stack HCI.
Запускаем первый тест с 12 виртуальных машин, работающих на обеих нодах. Профиль нагрузки чтение/запись составляет 70:30, block size = 8k. Размер блока выбрали исходя из того, что большинство современных транзакционных баз данных и OLTP-нагрузок используют именно такой размер блока и примерно аналогичное соотношение чтение/запись.
Устоявшаяся производительность кластера составляет 428k IOPS при задержке 0.487 мс. Это действительно достойный результат, который вполне сопоставим с тем, что можно получить на специализированной all-flash СХД от многих производителей.
Независимые тесты с похожим профилем нагрузки приводятся на ресурсе spcresults.org — это тест SPC-1. Разница с нашей конфигурацией заключается только в размере блока — он составляет 4k.
Если существенно упростить методику сравнения результатов, то можно разделить на два полученные там показатели IOPS для all-flash систем хранения и сравнить с полученными нами цифрами при том же времени отклика. Результаты, полученные на нашем кластере из двух серверов среднего уровня, получаются вполне сравнимыми с большинством СХД.
Безусловно, подобное сравнение не очень корректно, т.к. в нашем случае увеличение количества дисков будет влиять на производительность и задержки совсем иначе, чем у специализированной системы хранения. Но, даже принимая во внимание все указанные допущения, можно сказать, что пару лет назад подобные цифры производительности, можно было увидеть только на многоконтроллерной внешней СХД среднего или даже старшего уровня. Сегодня это достижимо на гиперконвергентном решении.
Картина производительности существенно меняется при включении дедупликации и замеров при прежнем block size = 8k. Если просто включить дедупликацию на том же профиле нагрузки, то производительность станет менее 300k IOPS.
Если запустить два профиля нагрузки с блоком 8КБ где один профиль 100% чтение, а другой 100% запись, то ниже — наилучшие цифры, которые нам удалось получить:
Видим прекрасные результаты по чтению, особенно если учесть задержку в 12 мкс. Optane здесь действительно прекрасно отрабатывает как кэш на чтение при упреждающих алгоритмах по предиктивному переносу данных в кэш. Да и сам пул хранения, расположенный на SSD, тоже демонстрирует очень неплохие цифры на чтение.
А вот скорость записи отличается очень сильно. Здесь накладываются несколько серьезных факторов:
Для тех, кто не заинтересован в самостоятельной настройке решения, есть возможность заключить Technical Solution Contract с Fujitsu. В этом случае, технические специалисты вендора развернут все «под ключ» и обеспечат дальнейшую поддержку.
13 апреля 2020 г.