1 ноября 2026, 18:07Виталий Лещенко

Hyper-V. Часть 9: Собираем отказоустойчивый кластер

В прошлой части мы переносили машины между одиночными хостами — но каждый перенос запускал администратор, а если хост просто сгорел, машины на нём остановились до ручного вмешательства. Отказоустойчивый кластер решает эту задачу: несколько хостов следят друг за другом, и машины упавшего узла сами запускаются на оставшихся. Разберём, что кластер даёт и чего не даёт, какое хранилище ему нужно, как устроены общие тома и кворум, как собрать кластер из PowerShell и как добавить в него машины.

Что даёт кластер

Одиночный хост — единая точка отказа: сгорел блок питания — встали все его машины. Отказоустойчивый кластер (Failover Cluster) объединяет несколько серверов-узлов, которые следят друг за другом через сетевые сообщения heartbeat. Когда узел пропадает, его машины автоматически запускаются на оставшихся (обзор Failover Clustering).

Это не живая миграция: машины упавшего узла перезагружаются, простой равен времени их загрузки, а всё, что было в памяти, теряется. Зато плановые работы — обновления, замена железа — проходят без простоя: узел освобождается живой миграцией и только потом выключается.

Кластер Hyper-V на Windows Server 2025 — до 64 узлов и до 8000 работающих машин (лимиты).

          клиенты                       управление
             │                               │
───────┬─────┴───────────────┬── сеть VM ────┴─────┬──────────
       │                     │                     │
   ┌───┴───┐ heartbeat   ┌───┴───┐ heartbeat   ┌───┴───┐
   │  hv1  ├─────────────┤  hv2  ├─────────────┤  hv3  │
   └───┬───┘             └───┬───┘             └───┬───┘
       │                     │                     │
───────┴─── сеть хранения ───┼─────────────────────┴──────────
                             │
                 ┌───────────┴───────────┐
                 │ общее хранилище:      │
                 │ CSV C:\ClusterStorage │
                 └───────────────────────┘

Общее хранилище

Чтобы машина запустилась на другом узле, её файлы должны быть видны всем узлам. Вариантов три:

SAN — внешняя система хранения, к которой все узлы подключены по iSCSI или Fibre Channel. Каждый узел видит один и тот же LUN.
Storage Spaces Direct (S2D) — программно-определяемое хранилище: локальные диски от 2 до 16 серверов собираются в общий пул, данные зеркалируются между узлами по SMB 3. Внешняя СХД не нужна, но нужны редакция Datacenter, сертифицированное железо и быстрая сеть — рекомендуется 10 Гбит/с и выше с RDMA (обзор S2D).
Файловый сервер SMB 3 — машины лежат на общей папке, обычно на кластерном Scale-Out File Server.

Общие тома CSV

Обычная файловая система NTFS не рассчитана на то, что её одновременно смонтируют несколько компьютеров: каждый будет считать себя хозяином метаданных, и том развалится. Поэтому диски кластера Hyper-V превращают в CSV (Cluster Shared Volume, общий том кластера). Все узлы читают и пишут в файлы машин напрямую, а изменения метаданных — создание файлов, изменение размера — проводит один узел-координатор тома. На каждом узле CSV виден по одинаковому пути C:\ClusterStorage\VolumeN (CSV).

Файловая система для CSV зависит от хранилища: тома на SAN форматируют в NTFS — тогда узлы пишут на диск напрямую (Direct I/O), а ReFS на SAN переводит CSV в перенаправленный режим, когда весь ввод-вывод идёт через координатора по сети. Тома S2D, наоборот, форматируют в ReFS (там же).

Кворум

Кластер должен решить, кто из узлов имеет право работать, если сеть между ними разорвалась. Иначе две половины кластера запустят одни и те же машины на одних и тех же дисках — это split brain, и данные будут испорчены. Решение — кворум: у каждого узла есть голос, и работает только та часть, у которой больше половины голосов. Меньшая часть останавливает кластерную службу.

При чётном числе узлов голоса могут поделиться поровну, поэтому добавляют свидетеля (witness) — ещё один голос, который достаётся той половине, что первой до него дотянулась (свидетель кворума):

Диск-свидетель — небольшой общий диск кластера без буквы и без других данных.
Свидетель на общей папке — SMB-папка на сервере вне кластера. Начиная с Windows Server 2019 это может быть папка на машине не из домена. DFS и реплицируемые хранилища не поддерживаются: реплика может «раздвоить» свидетеля (свидетель на общей папке).
Облачный свидетель — blob в учётной записи Azure Storage; узлам нужен исходящий HTTPS (TCP 443) (там же).

Microsoft рекомендует настраивать свидетеля всегда: кластер сам решает, учитывать ли его голос при текущем числе узлов. Свидетель не должен жить на машине этого же кластера — иначе при его падении пропадёт и голос свидетеля.

Подготовка узлов

На каждом будущем узле нужны роль Hyper-V, компонент Failover Clustering, одинаковые виртуальные коммутаторы с одинаковыми именами (машина при переезде ищет коммутатор по имени) и доступ к общему хранилищу. Узлы — в одном домене. Учётной записи, которая создаёт кластер, нужно право создавать объекты компьютеров в OU узлов: кластер заводит в AD собственную учётную запись (CNO, Cluster Name Object), от имени которой работает имя кластера (создание кластера).

$nodes = 'hv1', 'hv2'
Invoke-Command -ComputerName $nodes {
    Install-WindowsFeature -Name Failover-Clustering, Hyper-V -IncludeManagementTools -Restart
}
Invoke-Command -ComputerName $nodes { Get-VMSwitch | Select-Object Name, SwitchType }

Проверка

Перед созданием — проверка. Test-Cluster проверяет железо, сеть, хранилище и настройки узлов и пишет HTML-отчёт; Microsoft поддерживает кластер, только если конфигурация прошла все проверки (Test-Cluster):

Test-Cluster -Node $nodes -Include 'Inventory', 'Network', 'System Configuration', 'Storage', 'Hyper-V Configuration'

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

Создание кластера

Кластер создают с именем и адресом, по которым к нему будут обращаться, и без автоматического захвата дисков, чтобы добавить их осознанно (New-Cluster):

New-Cluster -Name hvclu -Node $nodes -StaticAddress 192.168.1.50 -NoStorage
Get-ClusterAvailableDisk -Cluster hvclu | Add-ClusterDisk
Get-ClusterResource -Cluster hvclu | Where-Object ResourceType -eq 'Physical Disk'
Add-ClusterSharedVolume -Cluster hvclu -Name 'Cluster Disk 1'
Set-ClusterQuorum -Cluster hvclu -FileShareWitness '\\fs1.corp.example.com\hvclu-witness$'

Параметры — в Add-ClusterSharedVolume и Set-ClusterQuorum. Учётной записи компьютера кластера hvclu$ нужно право на запись в папку свидетеля — и в разрешениях общей папки, и в NTFS.

Для S2D вместо добавления дисков SAN включают пул и создают тома сразу в виде CSV:

Enable-ClusterStorageSpacesDirect -CimSession hvclu
New-Volume -CimSession hvclu -StoragePoolFriendlyName 'S2D*' -FriendlyName 'VMs' `
           -FileSystem CSVFS_ReFS -Size 2TB

Сети кластера

Кластер сам находит сети узлов и назначает им роль: 0 — не использовать, 1 — только для кластерного трафика, 3 — для кластера и клиентов.

Get-ClusterNetwork -Cluster hvclu | Format-Table Name, Role, Address, Metric
(Get-ClusterNetwork -Cluster hvclu -Name 'Cluster Network 2').Role = 0    # сеть iSCSI
(Get-ClusterNetwork -Cluster hvclu -Name 'Cluster Network 3').Name = 'LiveMigration'

Сеть iSCSI выключают из кластерного обмена, чтобы heartbeat и миграции не мешали дискам. Живая миграция внутри кластера настраивается не через Add-VMMigrationNetwork из прошлой части, а через сети кластера: по умолчанию она идёт по тем, где нет клиентского трафика. Сети, которые живой миграции использовать нельзя, перечислены в параметре MigrationExcludeNetworks типа ресурса «Virtual Machine» — идентификаторами сетей через точку с запятой, без пробелов (заметка команды Hyper-V):

Get-ClusterResourceType -Cluster hvclu -Name 'Virtual Machine' | Get-ClusterParameter -Name MigrationExcludeNetworks
Get-ClusterNetwork -Cluster hvclu | Format-Table Name, Id

Машины в кластере

Машина становится отказоустойчивой, только когда её добавили в кластер как роль. Файлы её при этом должны лежать на CSV (Add-ClusterVirtualMachineRole):

New-VM -Name app2 -Generation 2 -MemoryStartupBytes 4GB -SwitchName 'LAN' `
       -Path 'C:\ClusterStorage\Volume1' `
       -NewVHDPath 'C:\ClusterStorage\Volume1\app2\app2-os.vhdx' -NewVHDSizeBytes 80GB
Add-ClusterVirtualMachineRole -Cluster hvclu -VMName app2

Машину, созданную на локальном диске узла, сначала переносят на CSV через Move-VMStorage и только потом добавляют в кластер. Переносом в кластере управляет он сам: Move-VM к кластерной машине не применяют — для неё есть Move-ClusterVirtualMachineRole (Move-ClusterVirtualMachineRole):

Move-ClusterVirtualMachineRole -Cluster hvclu -Name app2 -Node hv2 -MigrationType Live
Get-ClusterGroup -Cluster hvclu | Where-Object GroupType -eq 'VirtualMachine' |
    Format-Table Name, OwnerNode, State

-MigrationType Quick вместо Live сохраняет машину на диск и поднимает её на другом узле — короткий простой, зато без копирования памяти по сети. Настройки машины, которые меняют её конфигурацию (диски, адаптеры), у кластерной машины лучше делать через Failover Cluster Manager или с последующим Update-ClusterVirtualMachineConfiguration, чтобы кластер узнал о новой конфигурации (Update-ClusterVirtualMachineConfiguration).

Смотрим руками

Состояние кластера: узлы, тома CSV с их координатором и режимом ввода-вывода, кворум.

Get-ClusterNode -Cluster hvclu | Format-Table Name, State, DrainStatus
Get-ClusterSharedVolumeState -Cluster hvclu | Format-Table Name, Node, StateInfo, FileSystemRedirectedIOReason
Get-ClusterSharedVolume -Cluster hvclu | Format-Table Name, OwnerNode, State
Get-ClusterQuorum -Cluster hvclu | Format-List

StateInfo равный Direct — нормальная работа; FileSystemRedirected или BlockRedirected значат, что узел пишет на том через координатора по сети, и FileSystemRedirectedIOReason объясняет почему. OwnerNode у CSV — его текущий координатор.

Свободное место на томах CSV:

Get-ClusterSharedVolume -Cluster hvclu | ForEach-Object {
    $p = $_.SharedVolumeInfo.Partition
    [pscustomobject]@{ Name = $_.Name; Path = $_.SharedVolumeInfo.FriendlyVolumeName
                       FreeGB = [math]::Round($p.FreeSpace/1GB); SizeGB = [math]::Round($p.Size/1GB) }
}

Источники

Failover Clustering overview — что такое отказоустойчивый кластер;
Plan for Hyper-V scalability — лимиты кластера Hyper-V;
Storage Spaces Direct overview — требования S2D;
Use Cluster Shared Volumes in a failover cluster — CSV, координатор, NTFS и ReFS, перенаправленный режим;
Configure and manage quorum и Deploy a file share witness — кворум и свидетели;
Create a failover cluster — подготовка узлов и права в AD;
Test-Cluster, New-Cluster, Add-ClusterSharedVolume и Set-ClusterQuorum — проверка и сборка кластера;
Add-ClusterVirtualMachineRole, Move-ClusterVirtualMachineRole и Update-ClusterVirtualMachineConfiguration — машины в кластере;
Using PowerShell to configure live migration networks in a Hyper-V cluster — сети живой миграции в кластере.

Кластер Hyper-V — это узлы с одинаковыми коммутаторами, общее хранилище в виде CSV, кворум со свидетелем и машины, добавленные в кластер как роли: упал узел — его машины перезапускаются на соседях.

Дальше — часть 10: обслуживаем кластер Hyper-V. Пауза узла со сливом машин, Cluster-Aware Updating, автобалансировка и правила размещения, поэтапное обновление Windows Server на узлах, кластер без домена и диагностика по журналам.