Hyper-V. Часть 10: Обслуживаем кластер Hyper-V
Все части серии «Hyper-V»В прошлой части мы собрали кластер и добавили в него машины. Теперь его нужно обслуживать: каждый месяц ставить обновления на узлы, следить, чтобы нагрузка распределялась равномерно, а копии одной службы не оказывались на одном узле, раз в несколько лет переводить кластер на новую Windows Server и разбираться, почему машины внезапно переехали. Этому и посвящена последняя часть серии.
Пауза узла
Перед обновлением или ремонтом узел ставят на паузу со «сливом» ролей: кластер живой миграцией разносит его машины по остальным узлам и не размещает на нём новые (Suspend-ClusterNode):
Suspend-ClusterNode -Cluster hvclu -Name hv1 -Drain -Wait
Get-ClusterNode -Cluster hvclu | Format-Table Name, State, DrainStatus
# обновление, перезагрузка
Resume-ClusterNode -Cluster hvclu -Name hv1 -Failback Immediate
DrainStatus показывает ход слива: InProgress, Completed или Failed — последнее значит, что какую-то машину не удалось перенести, и узел нельзя выключать, пока её не разнесли вручную. -Failback Immediate возвращает на узел машины, которые были на нём до паузы; без него они остаются там, куда их перенесли.
Когда выключают весь кластер, а не один узел, — Stop-Cluster: он останавливает роли и кластерную службу на всех узлах (Stop-Cluster).
Cluster-Aware Updating
Делать это вручную для каждого узла и каждого месячного обновления не нужно: Cluster-Aware Updating (CAU) обходит узлы по очереди — сливает, ставит обновления, перезагружает, возвращает машины. Он работает либо как роль внутри кластера по расписанию (self-updating), либо запускается с внешнего компьютера-координатора (remote-updating) (CAU):
Invoke-CauRun -ClusterName hvclu -CauPluginName Microsoft.WindowsUpdatePlugin -MaxFailedNodes 0 -RequireAllNodesOnline -Force
Add-CauClusterRole -ClusterName hvclu -DaysOfWeek Sunday -WeeksOfMonth 2 -EnableFirewallRules -Force
Get-CauReport -ClusterName hvclu -Last -Detailed
Первая команда — разовый обход с рабочей станции, вторая — роль, которая сама обновляет кластер во второе воскресенье месяца. -MaxFailedNodes 0 останавливает обход на первом узле, который не удалось обновить, а -RequireAllNodesOnline не даёт начать, если какой-то узел уже недоступен: обновлять кластер, в котором и так не хватает узла, опасно. Get-CauReport показывает, что и где поставилось (Invoke-CauRun).
Балансировка
Кластер умеет сам выравнивать нагрузку: оценивает загрузку памяти и процессора узлов и живой миграцией переносит машины с перегруженных. Режим задаёт свойство AutoBalancerMode: 0 — выключено, 1 — при входе узла в кластер (по умолчанию в Windows Server), 2 — при входе узла и каждые 30 минут. Порог задаёт AutoBalancerLevel: 1 — переносить с узла, загруженного больше чем на 80 % (по умолчанию), 2 — больше чем на 70 %, 3 — когда узел загружен на 5 % выше среднего по кластеру (балансировка VM).
(Get-Cluster hvclu) | Format-List AutoBalancerMode, AutoBalancerLevel
(Get-Cluster hvclu).AutoBalancerLevel = 2
Правила размещения
Чтобы две копии одной службы — два контроллера домена, два узла веб-фермы — не оказались на одном узле, у машин задают одинаковое значение AntiAffinityClassNames: кластер будет по возможности разносить их по разным узлам.
$cls = New-Object System.Collections.Specialized.StringCollection; $cls.Add('DC') | Out-Null
(Get-ClusterGroup -Cluster hvclu -Name dc1).AntiAffinityClassNames = $cls
(Get-ClusterGroup -Cluster hvclu -Name dc2).AntiAffinityClassNames = $cls
Get-ClusterGroup -Cluster hvclu | Format-Table Name, OwnerNode, AntiAffinityClassNames
«По возможности» означает, что при нехватке узлов кластер всё-таки запустит обе машины на одном — правило мягкое. Узлы, на которых машине разрешено работать, ограничивают списком предпочтительных и возможных владельцев: Set-ClusterOwnerNode (Set-ClusterOwnerNode).
Set-ClusterOwnerNode -Cluster hvclu -Group dc1 -Owners hv1, hv2
Порядок, в котором машины запускаются после отказа узла, задаёт приоритет группы: (Get-ClusterGroup -Cluster hvclu -Name dc1).Priority = 3000 — высокий (3000), средний (2000, по умолчанию), низкий (1000), без автозапуска (0). Контроллеры домена и базы данных поднимают первыми, тестовые машины — последними или не поднимают вовсе.
Обновление ОС кластера
Кластер переводят на новую версию Windows Server без простоя машин — поэтапным обновлением (Cluster OS Rolling Upgrade). Узлы по одному освобождают, переустанавливают на новую ОС и возвращают в кластер. Пока в кластере есть узлы разных версий, он работает в смешанном режиме; этот этап рекомендуется пройти за четыре недели, а управлять кластером — с нового узла. Шаг — только на одну версию: с 2022 на 2025, а с 2016 на 2025 — через все промежуточные. Процесс обратим до последнего шага — повышения функционального уровня кластера (поэтапное обновление):
Get-Cluster hvclu | Select-Object Name, ClusterFunctionalLevel
Get-ClusterNode -Cluster hvclu | Format-Table Name, MajorVersion, MinorVersion, BuildNumber
Update-ClusterFunctionalLevel -Cluster hvclu
Get-VM -ComputerName hv1, hv2 | Where-Object State -eq 'Off' | Update-VMVersion -Force
Версию конфигурации машин поднимают после функционального уровня: она требует выключения машины и необратима — об этом в части о переносе машин. Последняя строка обновляет только выключенные машины; работающие обновляют по одной в окна обслуживания.
Кластер без домена
Кластер можно собрать и из серверов, не входящих в домен (workgroup cluster): на каждом узле заводят одинаковую локальную учётную запись, узлы вносят друг друга в TrustedHosts и получают общий основной DNS-суффикс, а имя кластера регистрируется только в DNS (кластер рабочей группы):
New-Cluster -Name wgclu -Node hv7, hv8 -StaticAddress 192.168.1.60 -NoStorage -AdministrativeAccessPoint DNS
Машины Hyper-V в таком кластере поддерживаются начиная с Windows Server 2025; файловые серверы и SQL Server FCI — нет. Это вариант для филиала без контроллера домена, но всё, что держится на Kerberos, — делегирование для живой миграции, доступ к общим папкам по доменным учётным записям — в нём придётся заменять сертификатами и локальными учётными записями.
Диагностика
Журнал событий кластера за последний час — первое, куда смотреть после внезапного переезда машин:
Get-WinEvent -ComputerName hv1 -FilterHashtable @{
LogName = 'Microsoft-Windows-FailoverClustering/Operational'; StartTime = (Get-Date).AddHours(-1)
} | Format-Table TimeCreated, Id, Message -Wrap
Критические события кластера попадают и в журнал System с источником Microsoft-Windows-FailoverClustering: например, 1135 — узел исключён из кластера, потому что перестал отвечать на heartbeat, и 1069 — ресурс кластера перешёл в состояние сбоя (события Failover Clustering):
Get-WinEvent -ComputerName hv1 -FilterHashtable @{
LogName = 'System'; ProviderName = 'Microsoft-Windows-FailoverClustering'; StartTime = (Get-Date).AddDays(-1)
} | Format-Table TimeCreated, Id, Message -Wrap
Если журнала мало, Get-ClusterLog собирает подробный журнал кластерной службы со всех узлов в текстовые файлы (Get-ClusterLog):
Get-ClusterLog -Cluster hvclu -TimeSpan 60 -Destination C:\Temp -UseLocalTime
-TimeSpan — сколько минут назад начинать, -UseLocalTime пишет время по часам узла, а не в UTC, чтобы его было проще сопоставить с журналами событий.
Состояние ролей, которые сейчас не работают, — машины, которые кластер не смог запустить:
Get-ClusterGroup -Cluster hvclu | Where-Object State -ne 'Online' | Format-Table Name, OwnerNode, State
Get-ClusterResource -Cluster hvclu | Where-Object State -ne 'Online' | Format-Table Name, ResourceType, OwnerGroup, State
Источники
- Suspend-ClusterNode — пауза узла и слив ролей;
- Cluster-Aware Updating overview и Invoke-CauRun — обновление кластера;
- Virtual machine load balancing — режимы и пороги балансировки;
- Set-ClusterOwnerNode — владельцы группы;
- Cluster operating system rolling upgrade — поэтапное обновление ОС кластера и функциональный уровень;
- Create a workgroup cluster — кластер без домена;
- Troubleshoot cluster issue with Event ID 1135 — событие исключения узла;
- Get-ClusterLog — подробный журнал кластерной службы;
- New-Cluster и Stop-Cluster — точка администрирования только в DNS, остановка кластера.
На этом серия заканчивается. Мы прошли путь от первой машины на одиночном хосте до кластера, который сам обновляется, балансирует нагрузку и перезапускает машины упавшего узла: гипервизор и корневой раздел, VMBus и службы интеграции, диски VHDX и коммутаторы с VLAN, процессор и память, контрольные точки, управление с рабочей станции, живая миграция и общие тома CSV. Полная справка по командам — в документации модулей Hyper-V и FailoverClusters.
Оставить комментарий могут только зарегистрированные пользователи.
Войдите на сайт или зарегистрируйтесь, чтобы оставить комментарий.