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

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

Что такое гиперконвергенция и как работает

Гиперконвергентная инфраструктура объединяет вычисления, хранение данных и сеть в одном слое управления, на одном и том же наборе серверов. В классической схеме эти три вещи живут отдельно. Серверы виртуализации — сами по себе, СХД — сами по себе, выделенная сеть хранения — тоже отдельно. Конвергентная инфраструктура сводит все это в одну стойку, но оставляет разделение по ролям: тут — узлы вычислений, там — узлы хранения, просто от одного вендора и под единым управлением. Как правило, поставляется в формате готового решения от конкретного производителя, которое позволяет ускорить развертывание инфраструктуры. А вот HCI идет дальше — каждый узел кластера одновременно и обслуживает виртуальные машины, и хранит часть данных через программно-определяемое хранилище.

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

Из чего складывается цена HCI

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

• Меньше серверов, потому что не нужны отдельные узлы под СХД

Действительно так, однако взамен каждый оставшийся сервер должен быть мощнее, ведь ему нужно тащить и виртуальные машины, и нагрузку распределенного хранилища — вычисление контрольных сумм, репликацию, фоновую ребалансировку данных. Для сравнения — в рекомендованной конфигурации гиперконвергентного кластера VMmanager на каждый узел закладывается процессор с 12 ядрами и 24 потоками, 128 ГБ оперативной памяти и отдельный SSD-накопитель под Ceph объемом от терабайта.

• Горизонтальное масштабирование

Еще одно преимущество HCI, однако требует отдельной сети под хранилище. Стабильная работа Ceph в гиперконвергентном режиме предполагает выделенный канал между узлами. Если 10 Гбит/с — это абсолютный минимум для старта, то для комфортной работы в продакшене (особенно с учетом фоновой ребалансировки и восстановления) стандартом де-факто сегодня являются сети 25 Гбит/с (желательно с поддержкой RDMA/RoCE) или больше.

• Совокупная стоимость владения

Это отдельный разговор про полезную емкость. Для дисков виртуальных машин (RBD) используется тройная репликация. Для холодных данных или бэкапов внутри этого же кластера можно использовать пулы с Erasure Coding, что повысит полезную емкость. Хотя современные версии Ceph позволяют хранить RBD в EC-пулах напрямую, на практике для ВМ это применяют редко. Erasure Coding требует от процессора дополнительных вычислений при каждой записи, что замедляет работу.

И еще одно условие, которое стоит учитывать при планировании. Для HCI-кластеров на базе Ceph настоятельно рекомендуется использовать однородные узлы. Хотя сам Ceph умеет работать с разнородным парком, в гиперконвергентной схеме, где ресурсы делятся между ВМ и хранилищем, разнородность дисков и CPU приведет к тому, что скорость будет ограничена наиболее медленным узлом.

Когда HCI — действительно хороший выбор

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

• Филиалы и удаленные офисы

Если у компании сеть филиалов или удаленных офисов, как правило, нет смысла держать отдельного инженера по СХД в каждом из них. HCI позволяет развернуть на каждой площадке единый узел, который одновременно и считает, и хранит данные, а вся инфраструктура управляется централизованно из головного офиса. 

• VDI и типовая виртуализация

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

• Старт с малого и понятный темп роста

Минимальная рабочая конфигурация для отказоустойчивого кластера — три узла: это и минимум для кворума, и минимум для тройной репликации. Если бизнес растет предсказуемо и можно добавлять узлы по одному, гиперконвергентная схема масштабируется пошагово — новый сервер сразу становится и узлом вычислений, и узлом хранения, без отдельной процедуры расширения СХД.

• Желание сократить число систем на обслуживании

Для компании, которым важнее единая точка администрирования, чем теоретический максимум производительности хранилища, и у которой нет задачи держать отдельную команду эксплуатации СХД, — стоит присмотреться к HCI.

Когда разумнее присмотреться к классической схеме

Есть и обратные сценарии, где выделенное хранилище остается более удачным выбором.

• Большие объемы холодных данных

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

• Нагрузки, чувствительные к задержке

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

• Уже работающая классическая инфраструктура с компетентной командой

Если в компании есть SAN, есть инженеры, которые умеют его эксплуатировать, и все это стабильно работает, миграция на HCI ради самой идеи миграции почти никогда не окупается. Стоимость переезда — время, риск, переобучение команды — обычно выше теоретической экономии.

• Разнородный парк серверов

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

Как VMmanager работает с гиперконвергенцией 

Компании, для которых HCI — осознанно подходящий вариант (из сценариев выше), теперь могут развернуть его на VMmanager по понятной, проверенной схеме. Для ознакомления советуем полистать нашу документацию — там описаны требования к реализации и порядок настройки.

Разворачивается это так. 

1. Сначала создается кластер VMmanager с временным файловым хранилищем, в него добавляются серверы — будущие узлы.

2. Дальше на этих же серверах разворачивается Ceph.

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

4. Завершающий шаг — включение отказоустойчивости кластера VMmanager поверх уже работающего Ceph.

За состоянием хранилища можно следить не только командой статуса Ceph, но и через экспорт метрик в формате Prometheus с готовыми дашбордами для Grafana — можно использовать готовые из репозитория Ceph.

Чтобы добавить новый узел, нужно сначала добавить его в кластер VMmanager, затем — в кластер Ceph и дождаться завершения ребалансировки данных. При удалении узла процесс обратный — сначала все виртуальные машины и их диски мигрируют на другие узлы, затем останавливаются и отключаются OSD этого узла, и только после завершения ребалансировки узел отключается от кластеров Ceph и VMmanager.

Какую схему выбрать в самом VMmanager

Если сопоставить это с разбором сценариев выше, выбор внутри VMmanager отражает ту же логику.

Гиперконвергентная схема — Ceph на тех же узлах, что и виртуализация — подходит компаниям из первого блока сценариев: компаниям с удаленными офисами и филиалами, тем, кто хочет сократить число серверов и не готов содержать отдельную SAN-инфраструктуру.

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

То, что VMmanager теперь поддерживает гиперконвергентную схему с Ceph, открывает этот вариант тем, кто понял, что HCI — именно их случай.

Вопросы, которые стоит задать себе на этапе выбора архитектуры

Прежде чем выбирать схему, стоит ответить на несколько вопросов:

• Сколько узлов планируется на старте и через год — три, десять, сто?

• Есть ли в команде человек, готовый работать с Ceph или аналогичным SDS?

• Заложен ли бюджет на отдельную 10-гигабитную (минимум) сеть под трафик хранения?

• Растут ли вычисления и хранение в одном темпе, или нагрузка по данным сильно опережает нагрузку по CPU и памяти?

• Парк серверов однороден, или это разномастный набор того, что покупали в разное время?

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