Настройка 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-инфраструктуру в оговорённые сроки. Свяжитесь с нами для оценки вашего проекта.