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

Зміни на гірше в ліцензуванні 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 є виправданим, з точки зору продуктивності і відносно невеликого обсягу операційних даних. Окрема мережа для реплікації 2 x 25GbE гарантує скорочення часу простоя.

Малі габарити та низьке енергоспоживання спрощують розміщення та обслуговування такої пари серверів.

Підіб'ємо підсумки

Переваги двонодових бюджетних кластерів Proxmox + StarWind vSAN:

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

А якщо невелика перерва у обслуговуванні,  затримка до 15 хв - не проблема, завжди є додатковий резерв економії – на ліцензіях StarWind VSAN.

Стратегія охолодження ЦОД для епохи AI