Можно ли сэкономить на СХД?12.07.2021 15:46

Как мы тестировали VMware vSAN 7

Привет, меня зовут Евгений Литовка, я работаю архитектором решений виртуализации в компании Nubes. Недавно компания VMWare выпустила мажорное обновление до версии 7.x, которое в свою очередь включает новую версию vSAN. Мы решили выяснить насколько эффективны новые решения и можно ли с их помощью снизить издержки на содержание СХД, в том числе за счет увеличения количества гиперконвергентных структур в одном кластере. Я собрал стенд с четырьмя серверами различных конфигураций для тестирования vSAN 7.0. Результаты получились весьма обнадеживающими, подробности — под катом. 

Как я задумывался об альтернативе SAN

Наш опыт работы связан в основном с созданием классических SAN-сетей для крупных ритейлеров. Часто, сдав проект заказчику, позже мы наблюдали, как его бизнес постепенно расширялся, а созданная серверная инфраструктура не успевала масштабироваться под новые задачи. Экстенсивный рост с помощью добавления новых коммутаторов, серверов и систем хранения данных, как правило, приводил к тому, что при развитии инфраструктуры появлялись различные проблемы с производительностью SAN. 

Работая с подобными системами, наши инженеры столкнулись с проблемой производительности танков, переполнения очередей HBA из-за излишней фрагментации пакетов, а также с таким явлением как SAN congestion. Когда мы пытались устранить эти моменты, родилась идея подобрать и протестировать аналогичное решение на базе VMWare vSAN, плюсами которого является более управляемое масштабирование и повышенная производительность. К тому же, очень кстати, на тот момент вышло обновление vSAN 7.0.

Фичи vSAN 7.0 U1

Вот краткий список того, что появилось в очередной версии:

• Файловые службы vSAN теперь поддерживают протокол SMB, включая поддержку Active Directory и Kerberos. Это позволяет, например, организовывать файловые хранилища в Windows-сетях.

• Увеличилось число Agent Manager с 8 до 32 на кластер vSAN — можно сказать данное обновление относиться по большей части к предыдущему пункту, так как данные агенты отвечают за работу vSAN File Services.

• Возможность подключения одного кластера vSAN к другому без необходимости обходных путей с iSCSI Target и vSAN File Services. Так называемый HCI Mesh — позволяет напрямую соединять между собой несколько vSAN кластеров для использования пространства соседа или для хранения какой-либо информации.

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

• Возможность для свидетеля двухузлового кластера следить за несколькими кластерами — упрощение администрирования конфигураций 2 node vSAN.

• Добавлена платформа vSAN Data Persistence, которая ориентирована на организацию сервиса хранения для облачных ресурсов, и заслуживает отдельной статьи. Реализацией этого нововведения занимаются партнеры VMWare.

После того как мы изучили нововведения и тренды на увеличение числа гиперконвергентных инфраструктур, решили попробовать собрать кластер в новой редакции vSAN и сравнить его с классической СХД. Гиперконвергентные технологии сочетают серверы, СХД, сетевые компоненты, резервное копирование и софт для управления ими в одной универсальной «коробке». Такой подход к развитию инфраструктуры позволяет значительно упростить ее обслуживание, быстро масштабировать в случае необходимости и снизить затраты на поддержание работоспособности. 

Как мы собирали тестировочные стенды

Конфигурация стенда vSAN

Специалисты компании собрали 4 сервера в следующей конфигурации: 1U Supermicro 1029U-TN10RT.

В составе:

 Xeon​ Gold 6246, 512GB DDR4, Intel DC P4510 1TB U.2 1TB, Mellanox ConnectX-4 Lx 25GE.

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

Для организации связанности используются:

Пара коммутаторов Cisco Nexus 9000, а именно 93180YC-EX.

Конфигурация стенда классической SAN компоновки

3 сервера в следующей конфигурации: 4U Huawei 2488H.

В составе:

Xeon​ Gold 6254, 2TB DDR4, Qlogic QLE2692 FC HBA 16G, Intel x540 10GE.

Дисковое пространство предоставлено посредством AllFlash массивов.

СХД 1 имеет характеристики:

• ЦП 2шт по 24 ядра

• ОЗУ/КЭШ 2×96ГБ

• Заявленная пиковая производительность 160 000 IOPS при чтении блоком 4KB

• Установлено 12 дисков по 3.84ТБ

СХД 1 имеет характеристики:

• ЦП 2шт по 10 ядер

• ОЗУ/КЭШ 2×256ГБ

• Заявленная пиковая производительность 198 000 IOPS при чтении блоком 4KB

• Установлено 12 дисков по 3.84ТБ

Для организации связанности используются:

Cisco Nexus 9000, Ethernet

DellEmc DS-6620B, SAN

В интернете можно найти любое количество руководств по начальной настройке vSAN, поэтому перейдем сразу к результатам тестов. Кластер был протестирован в конфигурациях FTT1-R1 и FTT1-R5.

ПО для генерации нагрузки на всех конфигурациях HCIBench 2.4.0. HCIBench в приемлемом по удобству, простоте и возможностям графическом web-интерфейсе позволяет сформировать задание на тестирование подсистемы хранения, после запуска которого остается только дождаться результатов его выполнения.

Результаты

R1 (RAID1) хранение информации простым добавлением копии, позволяет оценить пиковую производительность. Если она понадобится в каких-то задачах.

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

FTT1-R1 две дисковые группы

VMware vSAN 7.0.1 16858589, 2 dg/srv

dg1:

cache 1 шт. INTEL SSDPE2KX010T8 932 GB,

capacity 3 шт. INTEL SSDPE2KX010T8 932 GB

dg2:

cache 1 шт.  INTEL SSDPE2KX010T8 932 GB,

capacity 3 шт. INTEL SSDPE2KX010T8 932 GB

Однократный запуск нескольких паттернов HCIBench Easy Run. В этом режиме HCIBench задействует все хосты и сам определяет число ВМ, время выполнения и паттерны.

Итог тестирования данной конфигурации:

• Достигнутые максимумы 756366 IO/s и 4168 MB/s.

FTT1-R1 одна дисковая группа

VMware vSAN 7.0.1 16858589, 1 dg/srv, dg1: cache 1 шт.

INTEL SSDPE2KX010T8 932 GB, capacity 7 шт.

INTEL SSDPE2KX010T8 932 GB

Однократный запуск нескольких паттернов HCIBench Easy Run. В этом режиме HCIBench задействует все хосты и сам определяет число ВМ, время выполнения и паттерны.

Итог тестирования данной конфигурации:

• Достигнутые максимумы 410545 IO/s и 2654 MB/s

Как видно по результатам тестирования увеличение числа дисковых групп дает ощутимый прирост производительности от 57% до 84% в зависимости от сценария тестирования.

FTT1-R5

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

R5 (erasure coding) чаще всего встречаемый вариант в мейнстрим профиле нагрузки. Дает больше места, обеспечивает сохранность данных за счет контрольных сумм, разбросанных по группам отказа (в нашем случае мы защищаемся от выхода из строя машзала ЦОД), но теряем производительность на запись, так как для каждого блока надо рассчитать контрольные суммы. Тут мы хотели увидеть производительность для основного сценария эксплуатации, а также при повышенной плотности хранения данных, что важно для провайдеров.

VMware vSAN 7.0.1 16858589, 1 dg/srv,

dg1:

cache 1 шт. INTEL SSDPE2KX010T8 932 GB

capacity 7 шт. INTEL SSDPE2KX010T8 932 GB

Однократный запуск нескольких паттернов HCIBench Easy Run. В этом режиме HCIBench задействует все хосты и сам определяет число ВМ, время выполнения и паттерны.

Итог тестирования данной конфигурации:

• Достигнутые максимумы 410545 IO/s и 2654 MB/s

Как видно в рамках одной дисковый группы, мы упираемся в производительность подсистемы кэширования. И при переходе на erasure coding в случае 1 группы падения производительности нет. Если использовать такую конфигурацию, то можно повышать плотность хранения данных без влияния на скорость доступа к ним.

FTT1-R5 дедупликация и компрессия

VMware vSAN 7.0.1 16858589, compression, deduplication, 1 dg/srv

dg1:

cache 1 шт. INTEL SSDPE2KX010T8 932 GB,

capacity 7 шт. INTEL SSDPE2KX010T8 932 GB

Однократный запуск нескольких паттернов HCIBench Easy Run. В этом режиме HCIBench задействует все хосты и сам определяет число ВМ, время выполнения и паттерны.

Итог тестирования данной конфигурации:

• Достигнутые максимумы 407678 IO/s, 1629 MB/s

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

FFT1-R5 при заполнении на 50%

VMware vSAN 7.0.1 16858589, compression, deduplication, 1 dg/srv,

dg1:

cache 1 шт. INTEL SSDPE2KX010T8 932 GB,

capacity 7 шт. INTEL SSDPE2KX010T8 932 GB

Однократный запуск нескольких паттернов HCIBench Easy Run. В этом режиме HCIBench задействует все хосты и сам определяет число ВМ, время выполнения и паттерны.

Итог тестирования данной конфигурации:

• Достигнутые максимумы 432362 IO/s, 1688 MB/s

FFT1-R5 при заполнении на 80%

После достижения заполнения 80% мы видим негативное влияние на производительность системы. Подобные проблемы есть у большинства производителей на СХД.

Заполнение дискового пространства на 50% не оказывает сильного влияния на производительность, но в ходе дальнейшего тестирования было установлено что при переходе за границу 80% наблюдается очень сильное падение производительности.

После перехода отметки 80% — 265151 IO/s, 1035 MB/s. Что требует отдельного, более глубокого тестирования и тюнинга стенда, возможно, установки будущих обновлений.

Для классических СХД 1 и СХД 2 мы проводим тестирования в аналогичном R5 профиле.

Тестирование СХД 1

Тест 1

Однократный запуск нескольких паттернов HCIBench с одного хоста двенадцати ВМ по 4 ВМ на каждом из 4 LUN. Каждый из 8 vmdk каждой ВМ предварительно заполнен случайными данными.

Итог тестирования данной конфигурации:

• На указанных паттернах получены максимумы: 270759,92 IO/s, 4575 MB/s

Тест 2

Однократный запуск нескольких паттернов HCIBench с трех хостов двенадцати ВМ по 4 ВМ на каждом из 4 LUN. Каждый из 8 vmdk каждой ВМ предварительно заполнен случайными данными.

Итог тестирования данной конфигурации:

• На указанных паттернах получены максимумы: 278455,59 IO/s, 4844 MB/s. С ростом числа задействованных хостов наблюдается рост (5–15%) эффективности ввода/вывода.

Тестирование СХД 2

Тест 1

Однократный запуск нескольких паттернов HCIBench с одного хоста двенадцати ВМ по 4 ВМ на каждом из 4 LUN. Каждый из 8 vmdk каждой ВМ предварительно заполнен случайными данными.

Итог тестирования данной конфигурации:

• Достигнутые максимумы 139055 IO/s, 3128 MB/s

Тест 2

Однократный запуск нескольких паттернов HCIBench с трех хостов двенадцати ВМ по 4 ВМ на каждом из 4 LUN. Каждый из 8 vmdk каждой ВМ предварительно заполнен случайными данными.

Итог тестирования данной конфигурации:

• Достигнутые максимумы 144954 IO/s, 3709 MB/s

В данном тесте СХД2 отстает в паттернах на чтение от СХД1 на 48–23% и опережает в паттернах записи на 62–131%. В комплексном тесте на чтение/запись показывает схожую производительность. При этом во всех тестах СХД2 показывает существенно меньшие задержки. Что позволяет рассмотреть к применению эту СХД в сценариях чувствительных к задержкам операций ВВ.

Выводы

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

Мы провели сравнение актуальных классических СХД с программными решениями на примере VSAN. Результаты тестирования разных конфигураций показали, что можно реализовать быстрое хранилище данных клиентов, совместив его с серверами вычислительной части и немного сэкономив место в стойках. Таким образом еще и снижаются расходы на прокладку и управление кабельными сетями SAN (если для этого не использовать ISCSI).

В следующий итерации обновления нашего облака мы будем использовать это решение vSAN 7.0, так как кроме повышенной производительности и экономии места, мы получаем финансовые выгоды в рамках VSAN и VCPP (программа для облачных провайдеров от VMWare).

Стоит упомянуть и недостатки применения последней версии СХД, это дополнительные затраты на штат сотрудников, так как требуются квалифицированные специалисты, разбирающиеся в сфере vSAN (или иного SDS-решения). Кроме того, на лицензии для классического enterprise вендором установлены совсем не дружественные цены. Однако вопрос лицензий не так однозначен. Если у вас есть доступ к схеме работы по подписке, то вопрос ценообразования меняется в корне, что позволяет провайдерам предлагать своим клиента весьма производительные диски по приемлемой цене.