Привет, Хабр! Сегодня мы хотим рассказать о том, что представляет из себя платформа 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.
При построении решения есть несколько нюансов, которые нужно обязательно иметь в виду:
Управлять Microsoft Azure Stack HCI можно двумя способами — через Windows Admin Center либо Fujitsu Infrastructure Manager.
Admin Center тоже имеет свои преимущества — развернуть его можно на чем угодно, даже на ноутбуке; есть возможность управления из командной строки. С помощью него администратор может сделать почти все.
Есть еще Cluster Manager — незаменимый инструмент при каких-либо проблемах с кластером.
При развертывании Witness (кворум-сервера) важно добавить его в Active Directory и проверить его доступность всем нодам. Требования к данной задаче минимальны, и она может быть размещена на любом базовом сервере.
С точки зрения Windows Server, существуют три типа дисковых устройств — NVMe, SSD и HDD. Логика работы следующая: NVMe-устройства — это кэш на чтение/запись, SSD — уровень хранения Tier-1; HDD — уровень хранения Tier-2. Дальше можно настроить политики перемещения данных между пулами. В качестве кэша также могут использоваться модули NVDIMM.
Размер блока для тиринга по умолчанию равен 4К, но может меняться в зависимости от типа файловой системы на виртуальной машине. Это впоследствии будет влиять на производительность.
Мы используем NVMe модули в качестве кэш-памяти, поэтому скорость чтения и записи данных будут сильно отличаться — это будет хорошо видно на тестах производительности:
Перед созданием кластера необходимо выполнить валидацию и все тесты в Failover Cluster Manager. Отчет нужно сохранить, так как без него не получится открыть сервисное обращение в поддержке Microsoft, если когда-нибудь потребуется.
При добавлении новых нод в существующий кластер, ноды будут автоматически добавлены в 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. В этом случае, технические специалисты вендора развернут все «под ключ» и обеспечат дальнейшую поддержку.
Это гостевая публикация от ребят из «АльтаСтор». «АльтаСтор» — это системный интегратор, специализирующийся на построении решений для надежного хранения данных. Благодаря накопленной экспертизе в построении кластеров отказоустойчивости и HCI, для каждого клиента подбирается индивидуальное решение, наилучшим образом подходящее для его задач.
Что такое Azure Stack HCI?
Это гиперконвергентное решение, сочетающее в себе несколько продуктов:
- Оборудование от сертифицированного OEM-партнера Microsoft.
- Операционная система Windows Server 2019 Datacenter.
- Программное обеспечение Windows Admin Center.
- Службы Microsoft Azure при необходимости.
На рынке данное решение существует давно, и некоторые наши заказчики давно и успешно его используют. Однако, они не публикуют результаты тестов производительности своей инсталляции. Мы решили восполнить этот пробел и рассказать о нашем опыте использования 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. Для себя мы отметили следующие преимущества:
- Коммутаторы этой серии очень производительные, при невысокой стоимости.
- Коммутаторы достаточно просты в настройке и используют CISCO-like интерфейс. Инженеры не сталкивались с какими-либо затруднениями при инсталляции.
- Нет проприетарных излишеств в администрировании и доступна грамотная документация.
Коммутационное оборудование Fujitsu является одним из лидеров отрасли в Японии. Оно недавно стало доступно на российском рынке, но уже регулярно используется в проектах нашими архитекторами и другими партнерами Fujitsu. На данный момент доступно ограниченное количество моделей.
Подробнее узнать про коммутаторы Fujitsu можно на официальном сайте.
Сервер
Внутри сервера значительную часть места занимают платы памяти Intel Optane.
Intel уделяет много внимания работоспособности в условиях высокой тепловой нагрузки. С одной стороны, для максимально качественного охлаждения используются радиаторы большого размера. С другой, это ограничивает охлаждающий воздушный поток внутри всего сервера.
Это один из ключевых моментов, который учитывается при сертификации конфигурации — необходимо предусмотреть все возможные сценарии, при которых из-за недостаточного охлаждения серверы способны перегреть модуль Optane, или наоборот.
Наши клиенты при переезде серверной комнаты не раз сталкивались с ситуацией, когда система кондиционирования еще не была введена в эксплуатацию. Поэтому мы решили проверить, насколько требовательна данная инсталляция к системе охлаждения и замерить срок работы платформы под нагрузкой вне охлаждаемой серверной.
Тесты проводились при комнатной температуре, но мы не столкнулись ни с тепловыми ограничениями, ни со снижением производительности или появлением ошибок из-за перегрева. На своем опыте убедились, что тестируемые серверы поддерживают заявленную работоспособность при температуре окружающей среды до +45 градусов Цельсия.
Примечание. Этот эксперимент не стоит воспринимать как рекомендацию отказаться от использования специальных серверных помещений с качественной вентиляцией. При выборе поставщика аппаратных решений, обязательно обращайте внимание на максимальный температурный пакет.
Аппаратная платформа в сборе
Вид спереди:
Вид сзади:
В тесте использовался только один коммутатор. При коммерческой эксплуатации мы всегда рекомендуем резервировать пути доступа, используя не меньше двух коммутаторов. По нашей статистике, самая частая аппаратная неисправность в кластерах — случайный обрыв кабеля или нарушение контакта в разъеме.
В качестве сервера с управляющим ПО использовался Fujitsu RX1330. На него также были возложены функции арбитра и кворум-сервера.
Развертывание кластера
Первый этап состоял из физического монтажа аппаратных компонентов, подключения интерфейсных кабелей и т.д. Далее следовала настройка ПО, т.к. операционная система уже предустановлена. На каждом сервере развернули Storage Space Direct и построили кластер из 2 нод и арбитра.
Затем мы использовали утилиту Fujitsu Infrastructure Manager — это расширение Windows Admin Center, которое тесно интегрируется с серверным оборудованием Fujitsu и содержит все инструменты управления из Azure, такие как:
- Azure Site Recovery обеспечивает высокий уровень доступности и аварийное восстановление в качестве службы (DRaaS).
- Azure Monitor — это централизованный узел для мониторинга работы приложений, сети и инфраструктуры с углубленной аналитикой на основе ИИ.
- «Облако-свидетель» позволяет использовать Azure в качестве облегченного средства разбиения связей для установления кворума кластера.
- Служба Azure Backup предназначена для автономной защиты данных, а также для защиты от программ-шантажистов.
- Решение «Управление обновлениями Azure» выполняет оценку обновлений и развертывание обновлений для виртуальных машин Windows, работающих в Azure и в локальной среде.
- Сетевой адаптер Azure предназначен для подключения локальных ресурсов к виртуальным машинам в Azure через VPN-подключение типа «точка — сеть».
- Компонент «Синхронизация файлов Azure» синхронизирует файловый сервер с облаком.
Расширение позволяет автоматизировать ряд задач, которые также можно выполнить непосредственно в Admin Center.
Собрали Storage Pool, в нем создали Volumes. В этих томах в дальнейшем расположили виртуальные машины, для которых мы провели тесты производительности. И томами, и виртуальными машинами удобно управлять из одного окна.
Через Fujitsu Infrastructure Manager также удобно делать многие вещи по плановому обслуживанию и апдейту микрокода. Статус всего оборудования наглядно отображается, многое можно автоматизировать.
Существует две версии утилиты Fujitsu Infrastructure Manager — платная и бесплатная:
- Бесплатная. Доступна для скачивания с сайта производителя, ее вполне достаточно для управления серверами.
- Платная. Требуется для глубокой интеграции оборудования с Microsoft Azure HCI — плагин по управлению серверами из Windows Server доступен только в этой версии.
Для глубокой интеграции 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.
Важные моменты
При построении решения есть несколько нюансов, которые нужно обязательно иметь в виду:
Управлять Microsoft Azure Stack HCI можно двумя способами — через Windows Admin Center либо Fujitsu Infrastructure Manager.
Admin Center тоже имеет свои преимущества — развернуть его можно на чем угодно, даже на ноутбуке; есть возможность управления из командной строки. С помощью него администратор может сделать почти все.
Есть еще Cluster Manager — незаменимый инструмент при каких-либо проблемах с кластером.
При развертывании Witness (кворум-сервера) важно добавить его в Active Directory и проверить его доступность всем нодам. Требования к данной задаче минимальны, и она может быть размещена на любом базовом сервере.
С точки зрения Windows Server, существуют три типа дисковых устройств — NVMe, SSD и HDD. Логика работы следующая: NVMe-устройства — это кэш на чтение/запись, SSD — уровень хранения Tier-1; HDD — уровень хранения Tier-2. Дальше можно настроить политики перемещения данных между пулами. В качестве кэша также могут использоваться модули NVDIMM.
Размер блока для тиринга по умолчанию равен 4К, но может меняться в зависимости от типа файловой системы на виртуальной машине. Это впоследствии будет влиять на производительность.
Мы используем NVMe модули в качестве кэш-памяти, поэтому скорость чтения и записи данных будут сильно отличаться — это будет хорошо видно на тестах производительности:
- При выполнении операции чтения в кластере при обращении к любой из нод информация либо считается из кэша (очень быстро), либо поднимется с SSD (Tier-1, тоже быстро).
- При выполнении операции записи после записи на NVMe модуль одного из серверов, данные будут реплицироваться в кэш другой ноды, и только после этого запись будет подтверждена. Это дает дополнительные задержки.
Перед созданием кластера необходимо выполнить валидацию и все тесты в Failover Cluster Manager. Отчет нужно сохранить, так как без него не получится открыть сервисное обращение в поддержке Microsoft, если когда-нибудь потребуется.
При добавлении новых нод в существующий кластер, ноды будут автоматически добавлены в Storage pool. Через 15 минут начнется автоматическое перестроение кластера, ребилд и балансировка Storage pool. Это может сказаться на производительности на время перестроения.
Тесты производительности
Теперь перейдем к самому интересному — к нагрузочному тестированию.
Тестируемая конфигурация:
- два сервера Fujitsu PRIMERGY RX2540, собранные в кластер;
- в каждом сервере установлено по два модуля storage class memory Intel Optane, используются для расширения кэша на чтение/запись;
- в каждом сервере по пять дисков SSD, используются как пул хранения первого уровня,
- данные на дисках защищены по алгоритму erasure coding (аналог RAID-5).
Фактически, это программно-определяемая система хранения данных под управлением 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, тоже демонстрирует очень неплохие цифры на чтение.
А вот скорость записи отличается очень сильно. Здесь накладываются несколько серьезных факторов:
- Архитектура решения, когда данные, попадающие в кэш одной ноды, копируются по сети в кэш второй ноды.
- Работа механизмов дедупликации: она может неплохо помогать при обработке операций чтения — больше вероятность, что требуемый блок окажется в кэше на модуле Optane. Но она же и отрабатывает в оффлайне на обеих нодах.
В нашем случае это работает эффективно и дает экономию дискового пространства в 45%, но производительность на запись снижается достаточно серьезно по сравнению с предыдущим тестом, где циклов записи было немного — видимо, система успевала отработать такую нагрузку. Здесь же в разы увеличилось время отклика.
- Скорость чтения на SSD не равна скорости записи данных на SSD — это физическая особенность 3D-NAND технологии, а пул хранения у нас собран полностью на 3D-NAND.
Выводы
- Для OLTP-нагрузки данное решение подходит достаточно хорошо – при замерах на работе с блоком 8k производительность оказалась на высоте.
- Дедупликацию можно включить в любой момент, но она существенно снижает производительность. Эффективность дедупликации в наших тестах составила 45% при падении производительности более чем на 25%.
Это дает вам свободу выбора – либо выше производительность хранилища, либо почти в два раза больше емкость. Также многое будет зависеть от профиля нагрузки и возможности сжатия записываемых данных.
- Из-за архитектуры решения при последовательных операциях записи ожидаемо сильно вырастает время отклика.
- Не зря Microsoft требует собирать решение только на базе валидированных конфигураций от OEM-партнеров — это позволяет избежать многих проблем как при первичной инсталляции, так и при дальнейшей работе.
- Работа с аппаратной частью от Fujitsu, как всегда, оставила только положительные впечатления. Это и толковая документация, и много полезных дополнений от Infrastructure Manager — данный пакет ПО действительно значительно упрощает управление системой. Особенно это важно при увеличении количества нод.
- В состав решения PRIMEFLEX от Fujitsu входит набор скриптов, который позволяет ускорить процесс разворачивания решения. Они облегчают запуск и настройку в целом и серверов Fujitsu PRIMERGY в частности.
Для тех, кто не заинтересован в самостоятельной настройке решения, есть возможность заключить Technical Solution Contract с Fujitsu. В этом случае, технические специалисты вендора развернут все «под ключ» и обеспечат дальнейшую поддержку.
