Админ без рук = гиперконвергенция?

На практике же гиперконвергентные решения (когда всё в одном) нужны много для чего. Это миф, достаточно распространённый в сфере серверного железа. Тогда идея была в том, чтобы сделать вычислительную ферму из одинаковых узлов, у каждого из которых есть собственные диски. Исторически сложилось, что первые архитектуры были разработаны Amazon и Google под свои сервисы. Главная задача — минимум усилий на обслуживание одного узла и минимум проблем при масштабировании: просто докупили ещё тысячу-другую таких же серверов и подключили рядом. Всё это объединялось неким системообразующим софтом (гипервизором) и разбивалось уже на виртуальные машины. На практике это единичные случаи, и гораздо чаще речь про меньшее число узлов и немного другую архитектуру.

Минус — разные задачи по-разному потребляют ресурсы, и где-то локальных дисков будет много, где-то мало оперативки и так далее, то есть при разном типе задач будет падать утилизация ресурсов. Но плюс остаётся тем же — невероятная простота масштабирования и управления.

Это и вызвало миф из заголовка. Получалось, что вы платите на 10–15% больше за удобство настройки. Дело в том, что у Циски не было своих СХД, но они хотели полный серверный рынок. Мы долго искали, где же будет применяться технология оптимально, и нашли. И они сделали Cisco Hyperflex — решение с локальными хранилищами на нодах.

Почему и как — сейчас расскажу. А из этого внезапно получилось очень хорошее решение для резервных дата-центров (Disaster Recovery). И покажу тесты кластера.

Где нужно

Гиперконвергенция — это:

1. Перенос дисков в вычислительные узлы.
2. Полноценная интеграция подсистемы хранения данных с подсистемой виртуализации.
3. Перенос/интеграция с сетевой подсистемой.

Такая связка позволяет реализовывать многие фичи СХД на уровне виртуализации и всё из одного окна управления.

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

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

Поэтому сейчас я расскажу про устройство системы и тесты, а потом — про пару сценариев реального применения с данными по экономии.

Тесты

Наш экземпляр состоит из четырёх серверов, в каждом из которых — 10 SSD-дисков на 960 ГБ. Есть выделенный диск для кэширования операций записи и хранения сервисной виртуальной машины. Само решение — четвёртая версия. Первая откровенно сырая (судя по отзывам), вторая сыровата, третья уже достаточно стабильная, а эту можно назвать релизом после окончания бета-тестирования на широкой публике. За время тестирования проблем я не увидел, всё работает как часы.

Изменения в v4

Исправлена куча багов.

Также процесс развёртывания далеко не всегда заканчивался успешно, приходилось перезапускать некоторые шаги, были проблемы с обновлением со старых версий, данные в GUI отображались не всегда корректно (хотя я и сейчас не в восторге от отображения графиков производительности), иногда возникали проблемы на стыке с виртуализацией. Изначально платформа могла работать только с гипервизором VMware ESXi и поддерживала небольшое количество нод.

Сейчас все детские болячки исправлены, HyperFlex умеет и ESXi, и Hyper-V, плюс к этому возможно:

1. Создание растянутого кластера.
2. Создание кластера для офисов без использования Fabric Interconnect, от двух до четырёх нод (покупаем только серверы).
3. Возможность работы с внешними СХД.
4. Поддержка контейнеров и Kubernetes.
5. Создание зон доступности.
6. Интеграция с VMware SRM, если встроенный функционал не устраивает.

Архитектура несильно отличается от решений основных конкурентов, велосипед создавать не стали. Работает это всё на платформе виртуализации VMware или Hyper-V. Аппаратно размещается на серверах собственной разработки Cisco UCS. Есть те, кто ненавидит платформу за относительную сложность первоначальной настройки, множество кнопочек, нетривиальную систему шаблонов и зависимостей, но есть и те, кто познал дзен, проникся идеей и больше не хочет работать с другими серверами.

к. Мы рассмотрим именно решение для VMware, т. решение изначально создавалось под него и имеет больший функционал, Hyper-V допилили по ходу дела, чтобы не отставать от конкурентов и соответствовать ожиданиям рынка.

Есть диски под хранение данных (SSD или HDD — на ваш вкус и потребности), есть один SSD-диск для кэширования. Имеется кластер из серверов, набитых дисками. Параллельно блок данных отправляется на ноды в кластере (количество нод зависит от фактора репликации кластера). При записи данных на датастор происходит сохранение данных на кэширующем слое (выделенный SSD-диск и RAM сервисной ВМ). Записанные данные в фоновом режиме дедуплицируются, сжимаются и записываются на диски хранения. После подтверждения от всех нод об успешной записи подтверждение записи отправляется в гипервизор и далее — в ВМ. При этом на диски хранения всегда пишется большой блок и последовательно, что снижает нагрузку на диски хранения.

Чтение данных происходит напрямую с дисков хранения или из кэша RAM. Дедупликация и компрессия включены постоянно, и отключить их нельзя. Если используется гибридная конфигурация, то чтение также кэшируется на SSD-диске.

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

В нашей конфигурации сервисной ВМ был выделено восемь vCPU и 72 ГБ RAM, что не так уж и мало. За всю логику работы дисковой подсистемы отвечает специальная сервисная ВМ Cisco HyperFlex Data Platform controller, которая создаётся на каждой ноде хранения. Напомню, что сам хост имеет в наличии 28 физических ядер и 512 ГБ RAM.

Общение с гипервизором происходит через специальный модуль IOVisor, который перехватывает операции ввода-вывода, и с помощью агента, позволяющего передавать команды в API гипервизора. Сервисная ВМ имеет доступ к физическим дискам напрямую с помощью проброса SAS-контроллера в ВМ. Агент отвечает за работу с HyperFlex-снепшотами и клонами.

А под капотом это распределённая файловая система, которая позволяет добавить фичи взрослых полноценных СХД: тонкое выделение томов, сжатие и дедупликация, снепшоты по технологии Redirect-on-Write, синхронная/асинхронная репликация. В гипервизор дисковые ресурсы монтируются как NFS- или SMB-шара (зависит от типа гипервизора, угадайте, какой где).

Есть интеграция с vCenter, и большая часть повседневных задач может быть выполнена из него, но датасторы, например, удобнее нарезать из отдельной вебки, если вы уже перешли на быстрый HTML5-интерфейс, или же использовать полноценный Flash-клиент с полной интеграцией. Сервисная ВМ предоставляет доступ к WEB-интерфейсу управления подсистемы HyperFlex. В сервисной вебке можно посмотреть производительность и подробный статус системы.

Это могут быть рэковые или блейд-серверы без встроенных дисков. Существует и другой вид нод в кластере — вычислительные ноды. С точки зрения доступа к данным разницы между типами нод нет, ведь архитектура предполагает абстрагирование от физического расположения данных. На этих серверах можно запускать ВМ, данные которых хранятся на серверах с дисками. Максимальное соотношение вычислительных нод и нод хранения — 2:1.

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

Как итог у нас есть гиперконвергентная платформа со следующими фичами:

• До 64 нод в кластере (до 32 нод хранения).
• Минимальное количество нод в кластере — три (две — для Edge-кластера).
• Механизм избыточности данных: зеркалирование с фактором репликации 2 и 3.
• Metro-кластер.
• Асинхронная репликация ВМ на другой HyperFlex-кластер.
• Оркестрация переключения ВМ в удалённый ЦОД.
• Нативные снепшоты по технологии Redirect-on-Write.
• До 1 ПБ полезного пространства при факторе репликации 3 и без учета дедупликации. Фактор репликации 2 не учитываем, т. к. это не вариант для серьёзного прода.

Ещё один огромный плюс — простота управления и развёртывания. Все сложности настройки серверов UCS берёт на себя специализированная ВМ, подготовленная инженерами Cisco.

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

• 2 x Cisco UCS Fabric Interconnect 6248UP в качестве управляющего кластера и сетевых компонентов (48 портов, работающих в режиме Ethernet 10G/FC 16G).
• Четыре сервера Cisco UCS HXAF240 M4.

Характеристики серверов:

Больше вариантов конфигураций

Кроме выбранного железа, на данный момент доступны следующие опции:

• HXAF240c M5.
• Один или два CPU начиная от Intel Silver 4110 до Intel Platinum I8260Y. Доступно второе поколение.
• 24 слота памяти, планки от 16 GB RDIMM 2600 до 128 GB LRDIMM 2933.
• От 6 до 23 дисков для данных, один кэширующий диск, один системный и один бутовый диск.

Capacity Drives

• HX-SD960G61X-EV 960GB 2.5 Inch Enterprise Value 6G SATA SSD (1X endurance) SAS 960 GB.
• HX-SD38T61X-EV 3.8TB 2.5 inch Enterprise Value 6G SATA SSD (1X endurance) SAS 3.8 TB.
• Caching Drives
• HX-NVMEXPB-I375 375GB 2.5 inch Intel Optane Drive, Extreme Perf & Endurance.
• HX-NVMEHW-H1600* 1.6TB 2.5 inch Ent. Perf. NVMe SSD (3X endurance) NVMe 1.6 TB.
• HX-SD400G12TX-EP 400GB 2.5 inch Ent. Perf. 12G SAS SSD (10X endurance) SAS 400 GB.
• HX-SD800GBENK9** 800GB 2.5 inch Ent. Perf. 12G SAS SED SSD (10X endurance) SAS 800 GB.
• HX-SD16T123X-EP 1.6TB 2.5 inch Enterprise performance 12G SAS SSD (3X endurance).

System / Log Drives

• HX-SD240GM1X-EV 240GB 2.5 inch Enterprise Value 6G SATA SSD (Requires upgrade).

Boot Drives

• HX-M2-240GB 240GB SATA M.2 SSD SATA 240 GB.

Подключение к сети по 40G, 25G или 10G портам Ethernet.

В качестве FI могут быть HX-FI-6332 (40G), HX-FI-6332-16UP (40G), HX-FI-6454 (40G/100G).

Сам тест

Для тестирования дисковой подсистемы я использовал HCIBench 2.2.1. Это бесплатная утилита, позволяющая автоматизировать создание нагрузки из нескольких виртуальных машин. Сама нагрузка генерируется обычным fio.

Наш кластер состоит из четырёх нод, фактор репликации 3, все диски Flash.

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

Результаты тестов следующие:

Полужирным отмечены значения, после которых роста производительности нет, иногда даже видна деградация. Связано с тем, что упираемся в производительность сети/контроллеров/дисков.

• Последовательное чтение 4432 МБ/с.
• Последовательная запись 804 МБ/с.
• При отказе одного контроллера (отказ виртуальной машины или хоста) просадка по производительности — в два раза.
• При отказе диска хранения — просадка на 1/3. Ребилд диска занимает 5% ресурсов каждого контроллера.

На маленьком блоке мы упираемся в производительность контроллера (виртуальная машина), её CPU загружен на 100%, при повышении блока упираемся в пропускную способность портов. 10 Гбит/с недостаточно для раскрытия потенциала AllFlash-системы. К сожалению, проверить работу на 40 Гбит/с не позволяют параметры предоставленного демостенда.

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

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

Реальное использование

Для организации резервного ЦОДа можно использовать два подхода (размещение бэкапа на удалённой площадке не рассматриваем):

1. Active-Passive. Все приложения размещаются в основном ЦОДе. Репликация синхронная или асинхронная. В случае падения основного ЦОДа нам нужно активировать резервный. Делать это можно вручную/скриптами/приложениями оркестрации. Здесь мы получим RPO, соизмеримый с частотой репликации, и RTO зависит от реакции и умений администратора и качества проработки/отладки плана переключения.
2. Active-Active. В этом случае присутствует только синхронная репликация, доступность ЦОДов определяется кворумом/арбитром, размещённом строго на третьей площадке. RPO = 0, а RTO может достигать 0 (если приложение позволяет) или равно времени на отработку отказа ноды в кластере виртуализации. На уровне виртуализации создаётся растянутый (Metro) кластер, требующий Active-Active СХД.

Обычно мы видим у клиентов уже реализованную архитектуру с классической СХД в основном ЦОДе, поэтому проектируем ещё один для репликации. Как я и упоминал, Cisco HyperFlex предлагает асинхронную репликацию и создание растянутого кластера виртуализации. При этом нам не нужна выделенная СХД уровня Midrange и выше с недешёвыми функциями репликации и Active-Active доступа к данным на двух СХД.

Все продуктивные системы располагаются в основном ЦОД, а репликация виртуальных машин выполняется на уровне гипервизора, это позволит не держать ВМ включёнными в резервном ЦОД. Сценарий 1: У нас есть основной и резервный ЦОДы, платформа виртуализации на VMware vSphere. При отказе основного ЦОД мы запускаем системы в резервном ЦОД. Базы данных и специальные приложения реплицируем встроенными средствами и держим ВМ включёнными. Пока действует основной ЦОД, в резервном ЦОД можно запускать тестовые среды и прочие системы, которые можно отключить в случае переключения основного ЦОД. Считаем, что у нас порядка 100 виртуальных машин. С точки зрения оборудования ничего не поменяется. Также возможен вариант, когда у нас используется двухсторонняя репликация.

Для репликации и управления переключением в классической архитектуре можем использовать средства VMware (Replication + SRM) или же сторонние средства, которые будут немного дешевле и иногда удобнее. В случае классической архитектуры поставим в каждый ЦОД гибридную СХД с доступом по FibreChannel, тирингом, дедупликацией и компрессией (но не онлайн), 8 серверов на каждую площадку, по 2 коммутатора FibreChannel и Ethernet 10G.

На рисунке представлена схема.

В случае использования Cisco HyperFlex получается следующая архитектура:

часть ресурсов пойдёт на ВМ контроллера HyperFlex, по CPU и памяти я даже немного перезаложился в конфигурации HyperFlex, чтобы не подыгрывать в сторону Cisco и гарантировать ресурсы для остальных ВМ. Для HyperFlex я использовал сервера с большими ресурсами CPU/RAM, т.к. Зато мы можем отказаться от FibreChannel коммутаторов, и нам не потребуются Ethernet-порты под каждый сервер, локальный траффик коммутируется внутри FI.

В итоге получилась следующая конфигурация для каждого ЦОД:

Для Hyperflex не закладывал лицензии ПО репликации, т. к. у нас это доступно из коробки.

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

Решение на Cisco HyperFlex получилось на 13% дешевле.

В этом сценарии мы проектируем растянутый кластер на VMware. Сценарий 2: создание двух активных ЦОДов.

На каждой СХД закладываем полезную ёмкость для лока. Классическая архитектура состоит из серверов виртуализации, SAN (протокол FC) и двух СХД, которые умеют читать и писать на том, растянутый между ними.

В этом случае используется фактор репликации 2+2. У HyperFlex просто создаём Stretch Cluster с одинаковым количеством нод на обеих площадках.

Получилась следующая конфигурация:

Во всех подсчётах я не учитывал сетевую инфраструктуру, затраты на ЦОД и т. д.: они будут одинаковыми для классической архитектуры и для решения на HyperFlex.

Здесь стоит отметить, что по ресурсам CPU/RAM у меня для Cisco получился перекос, т. По стоимости HyperFlex получился на 5% дороже. в конфигурации заполнял каналы контроллеров памяти равномерно. к. Также это может быть интересно тем, у кого уже есть сервера Cisco UCS и соответствующая инфраструктура под них. Стоимость чуть выше, но не на порядок, что явно указывает, что гиперконвергенция не обязательно «игрушка для богатых», а может конкурировать со стандартным подходом к построению ЦОДа.

Из плюсов получим отсутствие затрат на администрирование SAN и СХД, онлайн-компрессию и дедупликацию, единую точку входа для поддержки (виртуализация, сервера, они же — СХД), экономия места (но не во всех сценариях), упрощение эксплуатации.

Если судить по опыту работы с серверами Cisco UCS, то она мне нравится, на HyperFlex открывать так и не пришлось, всё и так работало. Что касается поддержки, то тут вы получаете её от одного вендора — Cisco. Порой я обращаюсь к ним с вопросами: «А можно ли сделать так, прикрутить это?» или «Я тут что-то наконфигурировал, и оно не хочет работать. Инженеры отвечают оперативно и могут решать не только типовые проблемы, но и сложные пограничные случаи. Помогите!» — они там терпеливо найдут нужный гайд и укажут на правильные действия, отвечать: «Мы решаем только аппаратные проблемы» они не станут.

Ссылки