Hyper-V Failover Cluster: нулевой простой для бизнеса

Инженерная компания «ИнжПроект» обратилась к специалистам itfresh.ru с требованием нулевого простоя для критических бизнес-систем. Компания проектирует промышленные объекты, и остановка ERP-системы, файлового сервера или системы документооборота даже на час приводит к срыву сроков проектов и штрафным санкциям от заказчиков.

Текущая инфраструктура: 4 физических сервера с Windows Server, работающие автономно. При отказе одного сервера восстановление занимало от 2 до 8 часов — время на диагностику, замену оборудования, восстановление из бэкапа.

Решение — отказоустойчивый кластер Hyper-V (Failover Cluster) из двух узлов с общим iSCSI-хранилищем. Виртуальные машины автоматически мигрируют между узлами при обслуживании или сбое — пользователи не замечают переключения.

Архитектура проекта:

• Узел 1 (HV01) — Dell PowerEdge R750, 2x Xeon Gold 5318Y, 256 ГБ RAM
• Узел 2 (HV02) — аналогичная конфигурация
• Хранилище — Synology RS3621xs+ с iSCSI, 12x 4TB SAS (RAID 6)
• Сеть — отдельные VLAN для управления, Live Migration, iSCSI, виртуальных машин
• Witness — файловая шара на контроллере домена (File Share Witness)

Роль Hyper-V устанавливается на оба узла кластера. Мы используем Server Core для минимальной поверхности атаки и максимальной производительности.

# Установка Hyper-V на обоих узлах
Install-WindowsFeature Hyper-V -IncludeManagementTools -Restart

# Проверка поддержки виртуализации
Get-VMHost | Select-Object VirtualHardDiskPath,VirtualMachinePath,
    LogicalProcessorCount,MemoryCapacity

# Настройка путей по умолчанию
Set-VMHost -VirtualHardDiskPath "C:\ClusterStorage\Volume1\VHDs" `
           -VirtualMachinePath "C:\ClusterStorage\Volume1\VMs"

Hyper-V поддерживает три типа виртуальных коммутаторов. Для «ИнжПроект» мы создали все три:

# 1. External Switch — связь ВМ с физической сетью
# Привязывается к физическому адаптеру, ВМ получают IP из DHCP
New-VMSwitch -Name "External-Production" `
    -NetAdapterName "Production-NIC" `
    -AllowManagementOS $true `
    -MinimumBandwidthMode Weight

# 2. Internal Switch — связь между ВМ и хостом
# ВМ и хост видят друг друга, но нет выхода в физическую сеть
New-VMSwitch -Name "Internal-Management" `
    -SwitchType Internal

# Назначаем IP хостовому адаптеру
New-NetIPAddress -InterfaceAlias "vEthernet (Internal-Management)" `
    -IPAddress 10.255.0.1 -PrefixLength 24

# 3. Private Switch — изолированная сеть только между ВМ
# Хост не имеет доступа, идеально для тестовых сред
New-VMSwitch -Name "Private-TestLab" `
    -SwitchType Private

# Настройка VLAN-тегирования на External Switch
Set-VMNetworkAdapterVlan -ManagementOS `
    -VMNetworkAdapterName "External-Production" `
    -Access -VlanId 100  # Production VLAN

# SR-IOV для максимальной сетевой производительности (если NIC поддерживает)
New-VMSwitch -Name "External-HighPerf" `
    -NetAdapterName "SRIOV-NIC" `
    -EnableIov $true `
    -AllowManagementOS $false

Для кластера критически важно разделение трафика по отдельным сетевым адаптерам или VLAN:

• Management (VLAN 10) — управление хостами, 1 Гбит/с
• Live Migration (VLAN 20) — миграция ВМ между узлами, 10 Гбит/с
• iSCSI (VLAN 30) — трафик хранилища, 10 Гбит/с (два пути MPIO)
• Production (VLAN 100) — трафик виртуальных машин, 10 Гбит/с

Failover Cluster требует общего хранилища, доступного обоим узлам. Для «ИнжПроект» мы выбрали iSCSI — протокол передачи SCSI-команд через TCP/IP-сеть.

# На обоих узлах кластера:

# 1. Установка iSCSI Initiator и MPIO
Install-WindowsFeature Multipath-IO -Restart
Start-Service MSiSCSI
Set-Service MSiSCSI -StartupType Automatic

# 2. Настройка MPIO для iSCSI
New-MSDSMSupportedHW -VendorId "Synology" -ProductId "iSCSI Storage"
Enable-MSDSMAutomaticClaim -BusType iSCSI
Restart-Computer

# 3. Подключение к iSCSI-хранилищу (два пути для отказоустойчивости)
# Путь 1 — через NIC1
New-IscsiTargetPortal -TargetPortalAddress 10.30.0.100 `
    -TargetPortalPortNumber 3260 `
    -InitiatorPortalAddress 10.30.0.1

# Путь 2 — через NIC2
New-IscsiTargetPortal -TargetPortalAddress 10.30.0.100 `
    -TargetPortalPortNumber 3260 `
    -InitiatorPortalAddress 10.30.0.2

# Подключение к таргету
$target = Get-IscsiTarget
Connect-IscsiTarget -NodeAddress $target.NodeAddress `
    -TargetPortalAddress 10.30.0.100 `
    -InitiatorPortalAddress 10.30.0.1 `
    -IsMultipathEnabled $true -IsPersistent $true

Connect-IscsiTarget -NodeAddress $target.NodeAddress `
    -TargetPortalAddress 10.30.0.100 `
    -InitiatorPortalAddress 10.30.0.2 `
    -IsMultipathEnabled $true -IsPersistent $true

# 4. Проверка MPIO
Get-MSDSMAutomaticClaimSettings
mpclaim -s -d  # Показать MPIO-диски

# 5. Инициализация и форматирование дисков (только на одном узле!)
$disk = Get-Disk | Where-Object { $_.OperationalStatus -eq "Offline" -and $_.Size -gt 10TB }
$disk | Set-Disk -IsOffline $false
$disk | Initialize-Disk -PartitionStyle GPT
$disk | New-Partition -UseMaximumSize -AssignDriveLetter
Get-Partition -DiskNumber $disk.Number |
    Format-Volume -FileSystem ReFS -AllocationUnitSize 65536 `
    -NewFileSystemLabel "ClusterStorage"

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

Альтернатива iSCSI — SMB 3.0 Direct, использующий файловый протокол с поддержкой RDMA. Для организаций с сетевыми адаптерами RoCE или iWARP это может быть более производительным решением.

После подготовки узлов и хранилища создаём кластер. Предварительно обязательно запускаем валидацию — Microsoft не поддерживает кластеры, не прошедшие все тесты.

# 1. Установка компонента Failover Clustering на обоих узлах
Install-WindowsFeature Failover-Clustering -IncludeManagementTools

# 2. Валидация кластера (обязательный шаг!)
Test-Cluster -Node HV01,HV02 -ReportName "C:\ClusterValidation"
# Проверяет: сеть, хранилище, конфигурацию ОС, системные требования
# Все тесты должны пройти со статусом Success или Warning
# Failure = создание кластера не поддерживается Microsoft

# 3. Создание кластера
New-Cluster -Name "HV-Cluster" `
    -Node HV01,HV02 `
    -StaticAddress 10.10.1.50 `
    -NoStorage  # Диски добавим отдельно

# 4. Настройка кворума — File Share Witness
# FSW размещён на контроллере домена (третий голос для 2-узлового кластера)
New-Item -Path "\\DC01\C$\ClusterWitness" -ItemType Directory
New-SmbShare -Name "ClusterWitness$" -Path "C:\ClusterWitness" `
    -FullAccess "COMPANY\HV-Cluster$"

Set-ClusterQuorum -Cluster "HV-Cluster" `
    -FileShareWitness "\\DC01\ClusterWitness$"

# 5. Добавление общих дисков в кластер
Get-ClusterAvailableDisk | Add-ClusterDisk

# 6. Включение Cluster Shared Volumes (CSV)
Add-ClusterSharedVolume -Name "Cluster Disk 1"
# Диск доступен на обоих узлах как C:\ClusterStorage\Volume1

# 7. Настройка Live Migration
Get-ClusterResourceType -Name "Virtual Machine" | 
    Set-ClusterParameter -Name MigrationExcludeNetworks -Value "10.10.1.0/24"  # Не мигрировать через Management

Set-VMHost -VirtualMachineMigrationEnabled $true
Set-VMHost -MaximumVirtualMachineMigrations 2  # Две одновременных миграции
Set-VMHost -VirtualMachineMigrationPerformanceOption SMB  # Используем SMB для миграции

# Разрешаем Live Migration только через выделенную сеть
Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos
Add-VMMigrationNetwork -Subnet "10.20.0.0/24"  # LiveMigration VLAN

Кворум — механизм голосования, определяющий, какой узел продолжает работу при потере связи. В 2-узловом кластере без witness при потере связи между узлами возникает split-brain — оба узла считают себя главными. File Share Witness — третий голос, который разрешает конфликт.

Live Migration — перемещение работающей виртуальной машины между узлами кластера без остановки. Для «ИнжПроект» это основная ценность: плановое обслуживание серверов выполняется без простоя.

# Live Migration — перемещение ВМ между узлами
Move-VM -Name "ERP-Server" -DestinationHost "HV02" `
    -IncludeStorage -DestinationStoragePath "C:\ClusterStorage\Volume1\VMs"

# Quick Migration — для случаев, когда Live Migration невозможна
# (пауза ВМ → перемещение → возобновление, простой 2-5 сек)
Move-ClusterVirtualMachineRole -Name "ERP-Server" `
    -Node "HV02" -MigrationType Quick

# Мониторинг миграции
Get-VM -Name "ERP-Server" | Select-Object Name,State,Status

# Проверка, какие ВМ на каком узле
Get-ClusterGroup | Where-Object { $_.GroupType -eq 'VirtualMachine' } |
    Format-Table Name,OwnerNode,State -AutoSize

Cluster-Aware Updating (CAU) — автоматическое обновление кластера без простоя. CAU последовательно обновляет каждый узел: мигрирует ВМ на соседний узел, устанавливает обновления, перезагружает, возвращает ВМ обратно, переходит к следующему узлу.

# Установка CAU
Install-WindowsFeature RSAT-Clustering-PowerShell
Add-CauClusterRole -ClusterName "HV-Cluster" `
    -DaysOfWeek Sunday `
    -WeeksOfMonth 2 `
    -CauPluginName Microsoft.WindowsUpdatePlugin `
    -MaxRetriesPerNode 3 `
    -MaxFailedNodes 1 `
    -RequireAllNodesOnline `
    -Force

# Ручной запуск обновления кластера
Invoke-CauRun -ClusterName "HV-Cluster" `
    -CauPluginName Microsoft.WindowsUpdatePlugin `
    -MaxRetriesPerNode 3 `
    -RequireAllNodesOnline `
    -EnableFirewallRules `
    -Force

# Мониторинг процесса
Get-CauRun -ClusterName "HV-Cluster" | Format-List *

# Журнал обновлений
Get-CauReport -ClusterName "HV-Cluster" -Last 5 | Format-Table

Настройки Failover для каждой виртуальной машины определяют поведение при сбое узла:

# Настройка failover для критичных ВМ
$vm = Get-ClusterGroup -Name "ERP-Server"
$vm | Set-ClusterParameter -Name AutoFailbackType -Value 1  # Auto failback
$vm | Set-ClusterParameter -Name FailbackWindowStart -Value 2  # 02:00
$vm | Set-ClusterParameter -Name FailbackWindowEnd -Value 5    # до 05:00

# Приоритет восстановления
(Get-ClusterGroup -Name "ERP-Server").Priority = 3000    # Highest
(Get-ClusterGroup -Name "FileServer").Priority = 2000     # High
(Get-ClusterGroup -Name "TestServer").Priority = 1000     # Medium

# Мониторинг состояния ВМ (перезапуск при crash приложения)
Add-ClusterVMMonitoredItem -VirtualMachine "ERP-Server" `
    -Service "MSSQLSERVER"  # Если SQL упадёт — перезапуск ВМ

Failover Cluster защищает от отказа одного узла. Но если выйдет из строя всё оборудование (пожар, затопление серверной) — нужен Hyper-V Replica. Это асинхронная репликация виртуальных машин на удалённый сервер.

# Настройка Hyper-V Replica на целевом сервере (DR-сайт)
# DR-сервер расположен в дата-центре в другом здании

# На реплика-сервере (DR01):
Set-VMReplicationServer -ReplicationEnabled $true `
    -AllowedAuthenticationType Kerberos `
    -DefaultStorageLocation "D:\Replica" `
    -ReplicationAllowedFromAnyServer $false

# Разрешаем репликацию только с нашего кластера
New-VMReplicationAuthorizationEntry `
    -AllowedPrimaryServer "HV-Cluster.company.local" `
    -ReplicaStorageLocation "D:\Replica" `
    -TrustGroup "ProductionCluster"

# Открываем порт брандмауэра
Enable-NetFirewallRule -DisplayName "Hyper-V Replica HTTP Listener (TCP-In)"

# На исходном кластере — включаем репликацию для каждой ВМ
Enable-VMReplication -VMName "ERP-Server" `
    -ReplicaServerName "DR01.company.local" `
    -ReplicaServerPort 80 `
    -AuthenticationType Kerberos `
    -ReplicationFrequencySec 300 `
    -RecoveryHistory 24 `
    -VSSSnapshotFrequencyHour 4 `
    -CompressionEnabled $true

# Запуск начальной репликации (через сеть)
Start-VMInitialReplication -VMName "ERP-Server"

# Для больших ВМ — начальная репликация через внешний носитель
Start-VMInitialReplication -VMName "ERP-Server" `
    -DestinationPath "E:\InitialReplica" `
    -InitialReplicationStartTime "2024-01-20 02:00:00"

# Мониторинг репликации
Get-VMReplication | Format-Table VMName,State,Health,
    LastReplicationTime,ReplicationFrequencySec -AutoSize

# Тестовый failover (не прерывает продакшен)
Start-VMFailover -VMName "ERP-Server" -Prepare  # На primary
Start-VMFailover -VMName "ERP-Server" -AsTest    # На replica
# Проверяем работу тестовой ВМ, затем:
Stop-VMFailover -VMName "ERP-Server"              # Удаляет тестовую ВМ

Hyper-V Replica поддерживает каскадную репликацию (Extended Replication) — с primary на replica, и с replica на третий сервер. Это позволяет иметь две копии ВМ в разных локациях.

Для «ИнжПроект» мы настроили репликацию с интервалом 5 минут для ERP и файлового сервера, и 15 минут для остальных ВМ. RPO (максимальная потеря данных) — 5 минут для критичных систем.

Тюнинг производительности Hyper-V:

# Оптимальные настройки ВМ для максимальной производительности

# 1. Динамическая память — экономия RAM
Set-VMMemory -VMName "ERP-Server" `
    -DynamicMemoryEnabled $true `
    -MinimumBytes 4GB `
    -MaximumBytes 16GB `
    -StartupBytes 8GB `
    -Buffer 20  # 20% буфер сверх потребления

# 2. Virtual Processor — не выделять больше vCPU, чем физических ядер
# Правило: суммарное vCPU всех ВМ <= физические ядра × 8
Set-VMProcessor -VMName "ERP-Server" -Count 8 -Maximum 100 `
    -RelativeWeight 200  # Приоритет CPU выше среднего

# 3. Хранилище — VHDX вместо VHD, фиксированный размер для IOPS
Convert-VHD -Path "C:\VMs\disk.vhd" -DestinationPath "C:\VMs\disk.vhdx"
# Фиксированный VHDX для баз данных (нет фрагментации)
New-VHD -Path "C:\ClusterStorage\Volume1\VHDs\ERP-Data.vhdx" `
    -SizeBytes 500GB -Fixed

# 4. QoS для хранилища — защита критичных ВМ от "шумных соседей"
Set-VMHardDiskDrive -VMName "ERP-Server" -ControllerType SCSI `
    -MinimumIOPS 1000 -MaximumIOPS 10000

# 5. Сетевой QoS
Set-VMNetworkAdapter -VMName "ERP-Server" `
    -MinimumBandwidthWeight 50  # 50% гарантированной полосы

# 6. Integration Services — убедиться, что все включены
Get-VMIntegrationService -VMName "ERP-Server" | Format-Table Name,Enabled
Enable-VMIntegrationService -VMName "ERP-Server" -Name "Guest Service Interface"

System Center Virtual Machine Manager (SCVMM) — единая консоль управления для крупных Hyper-V-инфраструктур. Для «ИнжПроект» с 2 узлами и 15 ВМ мы обошлись встроенными инструментами (Failover Cluster Manager + Hyper-V Manager). SCVMM рекомендуется начиная от 5 узлов и 50+ ВМ — он добавляет шаблоны ВМ, self-service портал, сетевую виртуализацию и интеграцию с Azure.

Результаты проекта «ИнжПроект»:

Кластер работает стабильно более года. За это время произошёл один аппаратный сбой (отказ блока питания на HV01) — виртуальные машины автоматически мигрировали на HV02 за 45 секунд, пользователи не заметили перебоя. Если вашему бизнесу нужна отказоустойчивая виртуализация — обращайтесь к специалистам itfresh.ru.