Налаштування Hyper-V Failover Clustering під ключ

Налаштування Hyper-V Failover Clustering

Один Hyper-V-хост — це не висока доступність. Коли хост йде на перезавантаження після патча або падає від апаратного збою, всі ВМ на ньому лягають разом з ним. У результаті простій може тривати години, поки адміністратор вручну піднімає віртуальні машини на резервному сервері. Ми знаємо, як налаштувати відмовостійкий кластер, який автоматично мігрує ВМ на вцілілий вузол за секунди, забезпечуючи доступність 99,9%. Failover Cluster вирішує саме це: віртуальні машини автоматично мігрують на вцілілий вузол за секунди, а не за години. Але налаштування кластера вимагає розуміння кількох шарів одночасно — мережа, кворум, спільне сховище, — і помилка в будь-якому з них перетворює «високу доступність» на джерело split-brain та втрати даних. У цій статті ми розповімо, як правильно налаштувати Hyper-V Failover Clustering на прикладі двовузлового кластера зі спільним iSCSI-сховищем. Ви дізнаєтеся, як уникнути типових помилок, які призводять до недоступності. Зверніться до нас, щоб отримати готову HA-інфраструктуру без сюрпризів.

Вимоги до інфраструктури, які не можна ігнорувати

Failover Cluster — це не просто роль, яку ставиш на два сервери. Список обов'язкових умов:

• Домен Active Directory — кластер без домену неможливий (крім Workgroup Cluster з обмеженнями).
• Спільне сховище — всі вузли повинні бачити одні й ті самі LUN через iSCSI, Fibre Channel або SMB 3.0 (Scale-Out File Server). Локальні диски для кластерних ВМ не підходять.
• Виділена мережа для Cluster Network — мінімум дві мережі: одна для трафіку клієнтів/ВМ, друга для внутрішнього heartbeat між вузлами. Змішувати не можна.
• Ідентичне обладнання — не обов'язково один вендор, але однакові драйвери та однакові версії firmware на HBA-адаптерах.
• Мінімум 1 Гбіт для heartbeat, 10 Гбіт для Live Migration — на 1 Гбіт Live Migration 40 ГБ ВМ займає неприйнятно довго.

Чому кворум критичний для двовузлового кластера?

Найнезрозуміліше місце в Failover Clustering — кворум. Без кворуму кластер не запуститься навіть якщо обидва вузли живі. З неправильно налаштованим кворумом кластер зупиняється при втраті одного вузла в двовузловій конфігурації.

Для двовузлового кластера Hyper-V правильна стратегія — Node and File Share Majority. Третій «голосуючий» елемент — File Share Witness на окремому сервері (контролері домену або файловому сервері). Схема 2 вузли + 1 witness = 3 голоси. При втраті одного вузла залишається кворум (2/3), кластер продовжує роботу.

Для трьох і більше вузлів підходить Node Majority — кожен вузол голосує, більшість перемагає. Witness не потрібен при непарній кількості вузлів.

Зазначимо: як вказано в документації Microsoft, валідація кластера обов'язкова для отримання підтримки.

# Встановлення компонентів та створення кластера
Install-WindowsFeature -Name Failover-Clustering,Hyper-V `
    -IncludeManagementTools -Restart
Test-Cluster -Node "hv01.corp.local","hv02.corp.local" `
    -Include "Storage","Network","Inventory","System Configuration"
New-Cluster -Name "HV-Cluster01" `
    -Node "hv01.corp.local","hv02.corp.local" `
    -StaticAddress "10.10.1.50"
Set-ClusterQuorum -Cluster "HV-Cluster01" `
    -FileShareWitness "\\dc01.corp.local\ClusterWitness"
Get-ClusterQuorum -Cluster "HV-Cluster01"

Як iSCSI-сховище впливає на продуктивність кластера?

Найдоступніший спосіб організувати Shared Storage без дорогого FC-обладнання — iSCSI. Важливо: iSCSI-трафік має йти по виділеній мережі, ізольованій від решти трафіку. Змішувати iSCSI з трафіком ВМ — вірний шлях до деградації продуктивності та нестабільності кластера.

# Налаштування iSCSI Initiator та підключення до Target
Start-Service msiscsi
Set-Service msiscsi -StartupType Automatic
New-IscsiTargetPortal -TargetPortalAddress "10.20.1.100"
Connect-IscsiTarget -NodeAddress "iqn.2023-01.com.storage:target01" `
    -IsPersistent $true
Add-MpsaHardwareId -Vendor "MSFT" -Product "iSCSIDisk" -BusType iSCSI
Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR
# Додавання диска до кластера та створення CSV
Get-ClusterAvailableDisk | Add-ClusterDisk
Add-ClusterSharedVolume -Name "Cluster Disk 1"
Get-ClusterSharedVolume | Select Name, State, SharedVolumeInfo

CSV монтується як C:\ClusterStorage\Volume1 на кожному вузлі одночасно — це і є головна відмінність від звичайних Cluster Disks. Файли VHDX кластерних ВМ зберігаються тут.

Що таке Live Migration і чим він відрізняється від Quick Migration?

Live Migration переносить працюючу ВМ без зупинки. Пам'ять передається по мережі ітераційно: спочатку всі сторінки, потім сторінки, що змінилися під час передачі першого набору, і так доти, поки дельта не стане достатньо маленькою для фінального перемикання. На 10 Гбіт це займає секунди для ВМ з 8–16 ГБ RAM.

Quick Migration зберігає стан ВМ на диск (hibernate), переносить на інший вузол і відновлює — ВМ недоступна від кількох секунд до хвилини залежно від розміру пам'яті. Використовується лише коли Live Migration недоступна.

Live Migration кращий за Quick Migration за часом простою в 10 разів — саме тому ми використовуємо його як основний метод.

# Live Migration ВМ на інший вузол Move-ClusterVirtualMachineRole -Name "AppServer01" -Node "hv02" 

Етапи налаштування Hyper-V Failover Clustering під ключ

1. Аудит — перевірка мережі, сховища, AD, версій ОС.
2. Проектування — топологія мереж (Management, Live Migration, Cluster, iSCSI).
3. Підготовка сховища — виділення LUN, налаштування MPIO.
4. Встановлення ролей — Failover Clustering, Hyper-V, прогін Test-Cluster.
5. Створення кластера — налаштування кворуму, CSV.
6. Міграція ВМ — перенесення standalone Hyper-V на кластер.
7. Тестування — відпрацювання сценаріїв failover та drain.
8. Документація — схема мережі, конфіги, runbook.

Що входить у нашу роботу

• Аудит інфраструктури та архітектури.
• Проектування мережевої топології кластера.
• Встановлення та налаштування ролей Hyper-V та Failover Clustering.
• Налаштування спільного сховища (iSCSI/FC/SMB).
• Конфігурація кворуму.
• Налаштування Live Migration та CSV.
• Тестування відмовостійкості.
• Передача документації та навчання адміністраторів.

Коли потрібне професійне налаштування

Якщо ви рідко стикаєтеся з кластерами, типові помилки (неправильний кворум, невірна мережа, відсутність MPIO) можуть коштувати довгих годин простою. Наша команда з 10-річним досвідом налаштування Hyper-V Failover Clustering реалізувала понад 50 проектів — від двовузлових до великих розгортань. Ми гарантуємо працездатність кластера після здачі. Економія часу на простої може становити десятки годин на рік, що конвертується в пряму економію бюджету. Вартість налаштування кластера значно нижча за втрати від незапланованого простою.

Терміни та вартість

Вартість налаштування кластера розраховується індивідуально після аудиту інфраструктури. Замовте налаштування кластера під ключ — отримайте готову HA-інфраструктуру в обумовлені терміни. Зв'яжіться з нами для оцінки вашого проекту.