Обзор Lenovo ThinkAgile VX3320 - гиперконвергентное решение для упрощённого развёртывания vSAN в масштабах предприятия

Идеология гиперконвергентных решений с использованием технологий VMware имеет свои преимущества: это и сравнительно невысокая стоимость на старте, и возможность практически бесконечно масштабироваться увеличением количества узлов вплоть до 64 штук на кластер и увеличением количества кластеров под единым управлением, и равномерное распределение ресурсов хранения и вычисления с периодической ребалансировкой для поддержания высокой производительности, и отказоустойчивость по типу N+1 или N+2 (и даже N+3, но только для RAID-1 (Mirroring) политики), и возможность применять все эти преимущества индивидуально для каждой виртуальной машины в зависимости от выдвигаемых требований по защите данных.

С обновлением до версии 7, платформа VMware vSphere получила важный элемент vSphere LifeCycle Control Manager, призванный облегчить поддержку имеющейся инфраструктуры в актуальном состоянии и автоматизировать установку обновлений. Архитектура этого решения предусматривает активное участие производителя оборудования в процессе контроля жизненного цикла, как минимум, вендоры теперь создают собственные репозитории с прошивками для компонентов поставляемых систем, и как максимум - предлагают заказчику заранее сконфигурированные и готовые к старту решения, оптимизированные именно для развёртывания кластера VMware vSAN. Сегодня мы рассмотрим такое решение от компании Lenovo, модель серии ThinkAgile VX.

Поскольку в гиперконвергентных кластерах vSAN взаимодействие между узлами производится через сеть Ethernet, "лучшими практиками" рекомендовано использовать нижеследующую схему с отказоустойчивыми коммутаторами. Как правило, на сеть передачи данных выделяются два высокопроизводительных свитча класса Top-of-Rack (ToR) с SFP+ слотами под медное соединение DAC или оптику. Отдельно - сеть BMC контроллеров (XCC - XClarity Controller для аппаратного мониторинга и консольного доступа к узлам).

Следует отметить, что программно-определяемая сетевая конфигурация vSAN обладает достаточной гибкостью, и позволяет обходиться парой коммутаторов для сети vSAN, vMotion, Management и других применяя разделение сетей на логические VLAN, и более того - уже в процессе эксплуатации можно менять сетевые настройки без остановки сервисов на запущенных виртуальных машинах.

Преимущества заводской конфигурации

Программное обеспечение VMware ESXi имеет ограниченный список поддерживаемого оборудования, и не исключены ситуации, когда в процессе эксплуатации узла, после обновления, какое-либо физическое устройство в сервере перестаёт запускаться вовсе. Наиболее известным таким случаем стало печальное обновление ESXi 6.7 U2 build 13006603, отключившее поддержку «не серверных» NVMe накопителей, которые часто использовались в самосборных конфигурациях и не присутствовали в списке совместимости VMware (HCL). Для того, чтобы восстановить работоспособность серверов, многие системные администраторы вынуждены были переустанавливать операционную систему с откатом на более старую версию, эвакуировать ВМ, и лишь затем менять неработающий накопитель и устанавливать обновление.

Застраховаться от подобных неприятных сюрпризов достаточно просто - необходимо убедиться, что выбираемое оборудование совместимо с продукцией VMware в общем, технологией vSAN в частности и интегрировано в новую систему обновлений vLCM. Крупный производитель серверного оборудования может позволить себе не только выпустить оптимизированную конфигурацию серверов под vSAN, но и учитывать список совместимости VMware на этапе онлайн-конфигурирования узлов виртуализации под свои нужды. Иными словами, предоставить возможность устанавливать только те накопители и те платы расширения, которые протестированы на совместимость с vSAN.

Все эти шаги компания Lenovo применила для серии ThinkAgile VX3320, которая поставляется как специализированный программно-аппаратный комплекс для быстрого развёртывания и простого обслуживания кластеров vSAN. Сохраняя такие преимущества программно-определяемых сред, как возможность конфигурации узлов под свои нужды, - серия Lenovo ThinkAgile VX предлагает решения и для инфраструктур на базе процессоров AMD EPYC, и для кластеров на базе Intel Xeon. Всего в модельном ряду ThinkAgile присутствуют 7 моделей формата от 1U до 4U, в том числе модели с поддержкой GPU и поддержкой 4 процессоров Intel Xeon.

Конструкция вычислительных узлов

К нам на тестирование поступил демонстрационный комплект, состоящий из 4 узлов ThinkAgile VX3320, каждый из которых представляет собой модифицированную версию сервера Lenovo SR630 Gen2 формата 1U и имеет два процессора Intel Xeon Scalable второго поколения.

От обычного сервера модифицированные под vSAN устройства отличаются отсутствием диагностической панели и порта на лицевой панели. Это общая черта для всей серии ThinkAgile, во всём остальном же устройство полностью может быть переконфигурировано под нужды конкретного заказчика.

В нашем случае каждый узел имеет пару 10-гигабитных портов RJ45 на базе контроллера Intel x722 и два 25-гигабитных порта Ethernet SFP+ на плате расширения Mellanox ConnectX-4.

В All-Flash-кластерах vSAN обязательна поддержка 10-гигабитных сетевых адаптеров, но All-Flash-кластер дает и свои преимущества - применение политик хранения данных RAID-5 (Erasure Coding) , RAID-6 (Erasure Coding) (в конфигурациях от 4 или 6 вычислительных узлов соответственно), а также для поддержки технологий дедупликации и компрессии (начиная с vSphere 7 можно использовать только режим компрессии). All-Flash-кластер, подразумевает использование только SSD-накопителей как для слоя ёмкости (Capacity Layer), так и для слоя кэширования данных (Cache Layer).

Для дисковой подсистемы в рассматриваемых серверах отведено 10 отсеков под 2.5-дюймовые накопители высотой 15 мм типа U.2 с шиной PCI Express, 6 из которых подключаются через пару свитч-адаптеров ThinkSystem 1610-4P NVMe, а четыре - напрямую к процессорам. В данном случае следует иметь ввиду, что в отличии от SAS/SATA-накопителей, для подключения которых применялись HBA-контроллеры интерфейсов, для работы накопителей с интерфейсом U.2 (PCI Express с сохранением возможности горячей замены) используются платы-коммутаторы, влияние которых на задержку ввода/вывода минимально, либо же вовсе сведено к нулю.

Сегодня процессоры для подобных плат разрабатывает компания Broadcom, купившая в своё время крупнейшего производителя дисковых контроллеров, компанию LSI. Интересной особенностью All-Flash конструкции является отсутствие модулей BBU (Battery Backup Unit), поскольку задача сохранения локального кэша при обрыве электропитания решается каждым SSD индивидуально, за счёт встроенных конденсаторных батарей.

Наши тестовые серверы были сконфигурированы из расчёта по две дисковые группы на каждый узел. Для Capacity-слоя используются накопители Intel серии P4510 объёмом по 2 ТБ, а для кэширующего слоя - Intel Optane P4800X объёмом 375 ГБ. Первые были подключены через плату-коммутатор, а вторые - напрямую к процессорам. Следует заметить, что наличие двух дисковых групп в узле позволяет повысить отказоустойчивость кластера при поломке накопителя, а так же добиться более высокой скорости при определённых условиях, когда дисковая нагрузка программно распределяется между группами накопителей. В то же время, следует учитывать, что в All-Flash-массивах кэширующий слой работает только на операции записи без дифференцирования на последовательный и случайный доступ.

Для инсталляции операционной системы в каждом сервере установлены два SSD формата M.2 с интерфейсом mSATA ёмкостью 240 Гб. Они объединены в RAID-массив и доступны в UEFI-оболочке консольного администрирования. С завода на серверах уже развёрнут гипервизор VMware ESXi, так что для ввода систему в эксплуатацию достаточно лишь подключить кабели и нажать кнопку Power.

Оценивая качество сборки серверов ThinkAgile VX, хочется сказать, что многие технические решения здесь направлены на облегчение администрирования по месту установки оборудования. Каждую машину можно разобрать голыми руками без использования отвёртки, рычажки, за которые нужно тянуть обозначены синим цветом, а компоненты, которые можно менять «на горячую» - тёмно-оранжевым. К последним относятся SSD, вентиляторы и блоки питания.

Тестовые серверы, поступившие к нам в московский офис тестовой лаборатории HWP, были сконфигурированы следующим образом:

• Два процессора Intel Xeon 6226 (16 ядер, 32 потока, 2.9-3.9 ГГц, 22 Mb кэш)э
• 256 ГБ DDR4-2933
• 6 накопителей Intel P4510 объёмом по 2 ТБ
• 2 накопителя Intel Optane P4800X объёмом 375 ГБ
• 1 контроллер Ethernet 25Gb Mellanox ConnectX-4 (2xSFP+)
• 1 контроллер Intel X722 (2x10GBase-T)
• 2 блока питания мощностью по 1100 Вт.

На холостом ходу энергопотребление каждого сервера составляет от 290 до 320 Вт, а в режиме загрузки - около 430 Вт. Коэффициент реактивной мощности блоков питания при этом находится в пределах 0.92.

С учётом столь высокого энергопотребления, следует иметь ввиду, что в конечном итоге затраты на питание и кондиционирование в гиперконвергентных конфигурациях более низкие по сравнению с традиционными схемами с консолидированными СХД. Экономия достигается за счёт использования общих ресурсов кластера, разделяемых для вычислительных операций и поддержания распределённого хранилища данных. Подробно об этой экономии можно прочитать в исследовании от VMware (ссылка на документ).

Массовая установка с помощью Deployer VX

Сам по себе процесс конфигурирования кластера vSAN относительно нетрудоёмкий, но для облегчения развёртывания большого количества серверов, компания Lenovo разработала инструмент Deployer VX. Это программное обеспечение, поставляемое в виде .ova приложения на базе CentOS 7, предназначено для установки на управляющий хост или даже на ноутбук администратора. Кстати, по умолчанию данное ПО уже развернуто на серверах ThinkAgile VX, которые теперь поставляются с установщиком (см user manual).

При первом запуске Lenovo Deployer VX автоматически находит все узлы Lenovo ThinkAgile VX в сети, включая их BMC контроллеры. Выбрав нужные серверы для объединения в кластер vSAN, пользователь далее проходит простые этапы базового конфигурирования кластера с помощью мастера установки, получая в итоге сконфигурированный кластер со всеми элементами администрирования, с заданными IP-адресами и логинами/паролями.

Точно так же, без необходимости настройки каждого хоста в отдельности, Deployer VX может расширять существующий кластер vSAN путём добавления в него серверов ThinkAgile VX.

Элементы администрирования Lenovo XClarity Integrator и Lenovo XClarity Administrator

Как уже было сказано, начиная с 7 версии ESXi, компания VMware оптимизировала установку патчей и драйверов для оборудования, делегировав эти полномочия производителям оборудования. Для систем Lenovo ThinkAgile и ThinkSystem создан отдельный репозиторий, через который поставляются обновления firmware для компонентов сервера. Установить их можно через дополнительное ПО, а именно - через Lenovo XClarity Integrator, представляющее собой подключаемый модуль, инсталлируемый в виде небольшой виртуальной машины (.ova-шаблон) и подключенный к хосту управления vCenter.

Таким образом, процесс обновления прошивок и драйверов оборудования не выходит за пределы интерфейса управления vSphere Client, что существенно облегчает работу системных администраторов: поиски свежих драйверов на сайте производителя навсегда остались в прошлом.

Одной из функций "интегратора" является взаимодействие с BMC-системами серверов, XClarity Controller, для импортирования данных аппаратного мониторинга и инвентаризации оборудования в общем интерфейсе vSphere Client.

Для реализации возможности принудительной перезагрузки серверов из кластера, например для обновления UEFI материнской платы, используется XClarity Administrator.

Процесс добавления большого количества серверов в систему управления автоматизирован настолько, что установщику не придётся даже вводить логин/пароль при подключении к каждому серверу.

Стоит добавить, что XClarity Administrator поддерживает не только серверы, но и свитчи, компьютеры, СХД и другое оборудование Lenovo.

Интеграция в "контроллер жизненной среды"

По своей сути, "контроллер жизненной среды" - это система обновления, хостов под vSphere, реализующая радикально новый подход к обслуживанию серверного оборудования. Если ранее состояние программного обеспечения контролировалось индивидуально для каждого хоста и в той или иной ситуации могли возникнуть отклонения по версиям используемых драйверов и образов ОС, что неизбежно приводило к путанице, то сегодня за основу принята унификация образа, драйверов и прошивок для кластера vSAN, и этот момент следует раскрыть подробнее.

Как уже было сказано выше, каждый хост Lenovo ThinkAgileVX с завода поставляется с предустановленным ESXi , включающим протестированные драйверы для компонентов сервера. При построении кластера первый вопрос, который задаётся в интерфейсе vCenter - "желаете ли вы импортировать образ сервера с добавляемого хоста, чтобы использовать его для всех узлов в кластере"? Рекомендуется согласиться в случае, если используются однородные узлы, как в нашем тестовом оборудовании. Выбранный образ копируется на хост vCenter, а его настройки применяются ко всем узлам в кластере. В дальнейшем при плановых обновлениях программного обеспечения, vCenter, а точнее vLCM уже ориентируется на этот универсальный образ, используемый в кластере, и каждое обновление каждого хоста vSAN полностью повторяет то же обновление на другом узле vSAN.

Помимо поддержки актуальности софта, vSphere Lifecycle Manager постоянно сверяется со списками совместимости оборудования, но в данном конкретном рассматриваемом случае интегратор или владелец оборудования делегирует вопросы совместимости на компанию Lenovo, поскольку ThinkAgile VX поставляется не как "сервер, совместимый с VMware", а как программно-аппаратный комплекс, технологии VMware в котором являются неотъемлемой его частью.

• Какие-либо варианты несоблюдения идентичности в пределах кластера исключены.
• Ошибки, связанные с введением в эксплуатацию машины с другим образом операционной системы исключены.
• Операции по самостоятельному обновлению драйверов исключены
• Перебои работы сервисов предприятия, связанные с обновлением программного обеспечения, исключены
• Проблемы, при которых оборудование потеряло совместимость после обновления исключены
• Задачи, связанные с ручной сборкой образа и ручной настройкой серверов исключены

Масштабирование

Большинство специалистов уверены, что кластер vSAN нецелесообразно масштабировать ввысь, а правильный путь - либо расширять его добавлением дополнительных серверов в общий кластер, либо создавать в рамках имеющейся или новой инфраструктуры ещё один кластер, но в этом случае потребуется сразу закупать 4 новых узла, что может быть дорого. Как правильно поступить - единого ответа нет, но можно с помощью инструмента VMware vRealize оценить взаимодействие всей вашей инфраструктуры как внутри vSAN, так и за пределами кластера, понять насколько справляются разные элементы, и есть ли бутылочные горлышки.

Вывод и обработка логов из VMware ESXi настраивается через нативный инструмент VMware vRealize Log Insight. Это контрольная панель с понятной визуализацией, позволяющая ориентироваться по логам и метрикам вашей экосистемы VMware. Данные в систему транслируются как из vCenter, так и из Lenovo XClarity Administrator. Процесс настройки почти полностью автоматизирован, и единственное, что потребуется сделать - это проинсталлировать из маркетплейса VMware пакет с описаниями логов для систем Lenovo.

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

Понимание производительности кластера vSAN

С точки зрения дисковой производительности, у кластера vSAN есть ахиллесова пята - огромные накладные потери, связанные с работой виртуальных дисков и синхронизацией между узлами. Масштаб этих потерь представлен на графике ниже, где выведены результаты одного и того же теста на одном и том же узле Lenovo ThinkAgile VX на самом быстром из установленных SSD накопителей, - Intel P4800X семейства Optane под Windows Server 2019. Тесты проводились сначала на голом железе, затем - в виртуальной машине в гипервизоре ESXi 7.0.2, а потом - в кластере с политикой хранения RAID 5 (Erasure Coding).

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

Но хорошая новость состоит в том, что при распараллеливании нагрузок, запросы на «ввод/вывод» дисковой подсистемы обрабатываются асинхронно и попадают в эти создаваемые гипервизором задержки, в результате чего общая скорость кластера выравнивается, а производительность дисковых групп начинает складываться. Если политикой хранения в vSphere Client установлено разделение VMDK-файлов на страйпы (stripes - полоски), то каждая виртуальная машина будет использовать от 1 до 7 SSD (в зависимости от числа страйпов) для каждого виртуального диска, причём части одного VMDK могут располагаться как на одном, так и на разных серверах.

По-настоящему система хранения кластера раскрывает себя при тестировании кумулятивной производительности для N-числа виртуальных машин: обеспечивая плавное распределение нагрузки между узлами, дисковыми группами и SSD-накопителями. С учётом того, что кэширование в All-Flash дисковых группах происходит только при записи, максимальную производительность должны показывать операции произвольного чтения большими блоками.

Для тестирования мы использовали 16 ВМ следующей конфигурации, размещённых в кластере vSAN:

• 8 vCPU
• 8 GB RAM
• 200 Gb Test disk, Thick provision
• Debian 9 (параметры загрузки: noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off tsx=on tsx_async_abort=off mitigations=off)
• VDBench 5.04.06

Мы проведём тестирование для политики хранения RAID-1 и RAID-5 со включенной компрессией и разделением каждого VMDK на 6 страйпов, и начнём с того, что измерим общую задержку дисковой системы.

Сами по себе цифры времени доступа на уровне 1/4 миллисекунды выглядят впечатляюще, и если политикой вашей компании установлено поддержание времени отклика СХД ниже 1 мс, то кластер из четырёх ThinkAgileVX удовлетворяет этому условию даже при многопоточной нагрузке. Хотя, что такое 16 потоков для 4 узлов со 128 физическими ядрами? Начнём плавно увеличивать число потоков до 32 на каждую виртуальную машину (суммарно - 1024 потока на кластер), пока не упрёмся в задержку 1 мс.

Совсем немного кластер не дотягивает до 1 миллиона операций чтения, но цифры итак внушающие уважение. Изменение задержки при чтении имеет параболический характер на графике, что свойственно и аппаратным СХД, и одиночным дисковым накопителям, и что говорит нам об отсутствии какого-то бутылочного горлышка в поведении СХД.

Если говорить о сравнении RAID-5 и RAID-1, то на большей части тестируемого диапазона разницы практически нет, что достигается благодаря нарезке виртуальных дисков на большое количество страйпов (128 на тестовую конфигурацию), а вот в тестах записи картина принципиально другая.

Здесь физическим ограничением выступают интерконнекты между узлами и дополнительные операции, связанные с синхронизацией блоков между узлами в RAID-5. Этот же характер поведения кластера сохраняется и в операциях последовательного доступа

и в операциях случайного доступа крупными блоками по 64 КБ, где предсказуемо достигается рекорд скорости в нашем тесте:

Синтетические тесты показывают, что для кластера vSAN тяжело даются операции записи для виртуальных машин, использующих RAID-5, но действительно ли это такая большая проблема? Далеко не каждое приложение использует исключительно запись в случайном порядке. Чтобы ответить на этот вопрос, мы будем использовать паттерны, снятые специалистами компании Pure Storage для четырех типов нагрузки: VSI (Virtual Storage Infrastructure), VDI (Virtual Desktop Infrastructure), SQL и Oracle Database.

В указанных паттернах дисковые операции производятся крупными блоками, поэтому за основу оценки выбираем общую пропускную способность.

Здесь скорость суммируется для операций чтения и записи, поэтому более лёкгий RAID-1 в полтора раза обгоняет RAID-5, достигая скорости в 3.1 ГБ/с.

В тестах паттернов баз данных SQL и Oracle разрыв сокращается, и в самом сложном сеттинге - Oracle 1024 Threads сокращается до значения, которым можно пренебречь.

Конечно, хранение данных - важная, но не единственная функция vSAN. Мощная вычислительная часть кластера не страдает от накладных расходов, связанных с виртуализацией, и если какому-то приложению нужна максимальная производительность 1 ядра или 32 ядер - оно её получит, что подтверждается бенчмарком Cinebench R23 в тестах рендеринга сложной 3D-сцены. Один узел ThinkAgile VX устанавливает маленький локальный рекорд, и если стоит задача виртуализировать пост-обработку DCC/CG-приложений - вот отличный пример подходящей конфигурации.

Здесь хотелось бы добавить, что в случае нехватки локальных ресурсов и применения политики использования гибридных облаков в компании, для развёртывания дополнительных сервисов может быть использован VMware Cloud Foundation (VCF). Это решение объединяет VMware vSphere 7, VMware vSAN, VMware NSX-T, VMware vRealize Suite и VMware Tanzu (для работы с контейнерами) в единый программный стек с общей системой мониторинга для предоставления облачной инфраструктуры.

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

• 4 vCPU
• 8 ГБ
• 30 ГБ VMDK (Stripe x6)
• Ubuntu Server 20.04
• MariaDB 10.3.30 (База 10М записей, общий объём 2.5 ГБ)
• Sysbench 1.0.18

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

Результаты тестирования показывают, что для баз данных с преобладающими операциями чтения следует выбирать политику хранения RAID-1.

Заключение

Программно-определяемая инфраструктура в целом меняет представление о таких ключевых компонентах IT-части предприятия, как СХД или вычислительный блок. С переходом к модели микросервисов, развитием контейнерной виртуализации, систем IoT и гибридных облаков, от IT-персонала часто требуется поддерживать в актуальном состоянии существующую инфраструктуру, которая была спроектирована под другие задачи предыдущим поколение инженеров. Трудно поверить, но до сих пор такие рядовые операции, как модернизация, вывод из строя или утилизация оборудования, могут сталкиваться с перебоями в работе сервисов, на которые завязаны ключевые потоки данных предприятия. Стоит прибавить к этому стремление к углеродной нейтральности, как становится ясно, что на старом паровозе в 21-й век не уедешь.

Гиперконвергентная модель - одна из наиболее простых на пути к уменьшению расходов на дата-центр предприятия. При кажущейся общей сложности, стоит лишь заручиться поддержкой правильного поставщика оборудования, и ты понимаешь, что многое в области развёртывания, мониторинга и обслуживания уже упрощено и ускорено самой компанией Lenovo, так что IT-служба может больше времени уделить своим основным делам. Конечно, есть вопрос стоимости программного обеспечения, но здесь следует признаться честно, что обслуживание однородной номенклатуры оборудования на единой программной платформе выходит куда дешевле поддержания работы с "зоопарком" устройств: СХД, SAN-коммутаторов и серверов зачастую от разных брендов.

Разумеется, недостатки так же присутствуют, и к ним стоит отнести сравнительно высокие CAPEX: комплект из 4 узлов ThinkAgileVX вместе с лицензионным ПО от VMware может быть гораздо дороже, чем обычные серверы + СХД, и не стоит забывать, что в 1-поточных операциях кластер vSAN ведёт себя "не очень". Но такова жизнь, и идеальное во всех отношениях решение сегодня принципиально невозможно, а рассматривая традиционную схему и гиперконвергентную, следует учитывать не только вопрос "железа" и "софта", но и организационный: например, насколько стабилен рынок специалистов по устанавливаемому оборудованию, легко ли модернизировать/докупить/расширить компоненты в устанавливаемую инфраструктуру? Какова ценовая политика вендоров на запчасти и пакеты сервисной поддержки?

Гиперконвергентная инфраструктура даёт шанс на сохранение монобрендовости в ЦОД-е, да и для государственных компаний при переходе на HCI облегчается сохранение поставщика для серверного парка при повторной закупке оборудования: достаточно указать, что Lenovo ThinkAgile VX приобретается для совместимости с уже установленным Lenovo ThinkAgile VX - и требования законодательства в области конкурсной документации соблюдены.

Михаил Дегтярёв (aka LIKE OFF)
31/08.2021