Кластер «на минималках»

Изменения к худшему в лицензировании Broadcom-VMware заставили небольшие предприятия искать альтернативные средства виртуализации и обеспечения непрерывности – малые компании стремятся к доступности данных серверной инфраструктуры так же, как и большие. Основным вариантом для таких клиентов является виртуальная среда (VE) Proxmox, а приемлемым решением высокой доступности – HA-кластер Proxmox VE/StarWind VSAN, который можно собрать даже из двух серверов. Вклад в нем StarWind VSAN – реализация совместного для нод кластера виртуализированного хранилища данных (shared storage).

Почему StarWind VSAN ?

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

У Microsoft есть собственное гиперконвергентное решение с распределенным хранилищем Windows Storage Spaces Direct (S2D). Оно подходит средним и крупным организациям, требует минимум трех полноценных узлов и покупки дорогостоящей ревизии Windows Server Datacenter на каждый узел. Чем дальше, тем больше Microsoft фокусируется на интегрированных с собственным облаком решениях Azure Stack HCI и гибридных сценариях. Azure Stack HCI работает на ограниченном круге серверов и продается по подписке, в то время как Windows Server имеет традиционное лицензирование.

StarWind VSAN выгодно отличается совместимостью со всеми основными системами виртуализации, не требует больших вложений, обеспечивает простыми средствами совместное хранилище, живую миграцию виртуальных машин и является удачным примером бюджетного решения с нулевым временем простоя (zero-downtime).

Полноценный HA-кластер

Минимальное требование для высокодоступного (HA) кластера Proxmox VE составляет три узла. Кластер Proxmox использует демон Corosync Quorum Device (QDevice), установленный на каждом узле Proxmox, для установки кворума в случае отказа узла. Однако только два из этих узлов должны являться узлами хранения данных. Третий, свидетельский узел может быть бездисковым сервером, на котором работает только демон QDevice.

Решение выглядит так:

Пошаговая процедура настройки кластера подробно описана: https://www.starwindsoftware.com/blog/how-to-build-a-highly-available-minimalist-2-node-proxmox-ve-cluster/.

Можно ли обойтись без StarWind VSAN?

Да. Но двунодовый кластер Proxmox VE без общего хранилища (shared storage) имеет существенные ограничения:

Главное: без общего хранилища невозможна онлайн-миграция, потому что виртуальный диск должен быть доступен обоим узлам одновременно – что, собственно, и обеспечивает StarWind VSAN.

Единственный способ HA в таком кластере – копирование снепшотов между узлами. Репликация ZFS (или LVM-thin) в Proxmox VE не обеспечивает нулевой задержки. Это асинхронная репликация, поэтому при падении основного узла VM запускается на втором из последнего успешно передаваемого снепшота.

Реальная задержка доступности зависит от:

• Графика репликации (главный фактор)
• Размера VM (больше данных – дольше копирование)
• Скорости сети (~80 МБ/с по ссылкам 1 Gbit/s)
• Загрузки узлов
• Выбора типа хранилища (ZFS быстрее LVM)

Минимизировать задержку можно оптимизацией графика репликации в зависимости от типа операций с данными, вынесением репликации на отдельную сеть 10-25 Gbit/s, оптимизацией VM, снижением операционного объема данных, настройкой реакции QDevice на обнаружение отказа.

Решение с асинхронной репликацией подходит для:

• Тестовых сред (где задержка порядка 15 мин вообще не проблема)
• Бюджетных конфигураций
• Онлайн-транзакций с умеренными требованиями к доступности (с оптимизацией и репликацией по сети 10-25 Gbit/s можно выйти на показатели 1-3 мин простоя).

Репликация ZFS/LVM дает задержку доступности от 1 до 15 минут. Это не HA в реальном времени, а восстановление из резервной копии (снепшота). Для сокращения простоя до 1 минуты требуется совместное хранилище (shared storage).

Выбор серверной платформы

Для серверов с умеренной нагрузкой лучше подходит серия процессоров AMD EPYC 4005 на архитектуре Zen 5. У них от 6 ядер (12 потоков) до 16 ядер (32 потоков), двухканальный контроллер памяти с поддержкой до 192 ГБ DDR5-5600, ввод-вывод по 28 линиям PCIe Gen5.

Платформа AMD EPYC 4005 сочетает высокую производительность с энергоэффективностью, имеет больше ядер по сравнению с конкурентами, Intel Xeon начального уровня, имеет большие кэш-логические буферы, отвечающие задачам с низкой задержкой, пригодна для интенсивной обработки данных.

Узлы кластера

ASUS ExpertCenter Pro ER100A B6 - удобный кандидат на роль узлов минималистического двухнодового кластера, с таким наполнением:

• CPU AMD EPYC 4545P, 16 cores, 3GHz

• RAM 128GB (4 x 32GB DDR5 UDIMM ECC)

• 1 x 480GB M.2 NVMe boot SSD

• 2 x 3840GB U.2 NVMe data SSD

• NIC1 2 x 2.5GbE (onboard)

• NIC2 2 x 25GbE

Процессорных ядер и оперативной памяти должно хватить для обслуживания виртуальных машин. Выбор носителей NVMe оправдан с точки зрения производительности и относительно небольшого объема операционных данных. Отдельная сеть для репликации 2x25GbE гарантирует сокращение времени простоя.

Малые габариты и низкое энергопотребление упрощают размещение и обслуживание такой пары серверов.

Подведем итоги

Преимущества двухнодовых бюджетных кластеров Proxmox + StarWind vSAN:

Идеально для SMB.

А если небольшой перерыв в обслуживании, задержка до 15 мин – не проблема, всегда есть дополнительный резерв экономии – на лицензиях StarWind VSAN.