Обновление отказоустойчивого кластера Windows Server с помощью последовательного обновления ОС кластера

2025-04-02
Применяется к: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Azure Local 2311.2 and later

В этой статье описывается, как вручную установить обновление компонентов в отказоустойчивом кластере Windows Server без остановки рабочих нагрузок. Процесс обновляет один узел за раз в последовательном обновлении и часто называется скользящим обновлением кластера ОС.

Вы можете обновить одну версию ОС кластера одновременно, например с Windows Server 2022 до Windows Server 2025. Чтобы обновить несколько версий ОС, таких как Windows Server 2016 до Windows Server 2025, повторите действия, описанные в этой статье.

Эта статья относится к кластерам, работающим на виртуальных машинах Hyper-V или с нагрузками масштабируемого файлового сервера (SOFS), обновляющие одну версию ОС, но не применяется к кластерам, использующим виртуальные жесткие диски (VHDX-файлов) в качестве общей памяти. Если вы используете System Center Virtual Machine Manager (VMM), вместо этого см. статью "Выполнение последовательного обновления кластера узла Hyper-V в VMM". Локальные клиенты Azure должны использовать процесс обновления, описанный в статье "О локальных обновлениях Azure", хотя вы можете использовать эту статью, если для вас нет методов локального обновления Azure.

Обзор

Последовательное обновление кластера до следующей новой версии Windows Server обеспечивает следующие преимущества:

Обновите кластер, в котором работают виртуальные машины Hyper-V или выполняются рабочие нагрузки файлового сервера масштаба (SOFS), до следующей версии Windows Server без простоя.
Новое оборудование не требуется, хотя вы можете временно добавить узлы кластера в небольшие кластеры для повышения доступности во время обновления.
Кластер может поддерживать операции исправления и обслуживания во время обновления, если в кластере есть сочетание версий ОС.
Процесс обновления является обратимым до последнего шага, когда все узлы кластера выполняют более новую версию Windows Server и обновляете функциональный уровень кластера.
Она поддерживает автоматизацию с помощью PowerShell и WMI.

На высоком уровне последовательное обновление состоит из следующих шагов:

Подготовьте кластер для обновления компонентов ОС.
Перенос рабочих нагрузок из первого узла.
Выполните обновление компонентов Windows Server с помощью обновления или очистки установки.
Повторите шаги 2–3 для каждого другого узла в кластере.
Обновите функциональный уровень кластера и пулы носителей до новой версии Windows Server.
Возобновление нормальной работы и обновление версий конфигурации виртуальной машины для включения новых функций.

Подробная схема процесса последовательного обновления см. на рисунке 1.

Рис. 1. Схема процесса последовательного обновления

Требования и ограничения

Перед началом обновления выполните следующие требования:

Начните с отказоустойчивого кластера под управлением Windows Server 2012 R2 или более поздней версии.
Убедитесь, что узлы Hyper-V имеют центральные процессоры, поддерживающие таблицу адресации Second-Level (SLAT), с помощью одного из следующих методов:
- Ознакомьтесь с Совместимы ли вы с SLAT? Совет WP8 SDK 01, который описывает два метода для проверки поддержки SLAT на ЦП.
- Скачайте средство Coreinfo версии 3.31 , чтобы определить, поддерживает ли ЦП SLAT.

Ниже приведены некоторые ограничения, которые следует учитывать:

Мы рекомендуем перейти через процесс обновления кластера в течение четырех недель, так как некоторые функции кластера не оптимизированы для кластеров, которые работают с двумя разными версиями ОС.
- При управлении кластером в режиме смешанной ОС всегда выполняйте задачи управления с узла, на котором запущена более новая версия Windows Server. Старые версии Windows Server часто не могут использовать средства пользовательского интерфейса или управления для управления более новыми версиями.
- Избегайте создания или изменения размера хранилища на новых узлах Windows Server во время работы кластера с несколькими версиями ОС. Это может привести к возможной несовместимости при переключении с более нового узла Windows Server на более старый.
Вы можете обновить только следующую более новую версию ОС, например с Windows Server 2022 до Windows Server 2025.
Для обновления нескольких версий, таких как Windows Server 2016 до Windows Server 2025, выполните обновление последовательно (сначала до Windows Server 2019, а затем до Windows Server 2022 и, наконец, в Windows Server 2025) или перейдите в новый кластер.
Необходимо обновить версию конфигурации старых виртуальных машин, прежде чем они смогут работать в кластере Windows Server 2022 или более поздней версии независимо от способа обновления. Версии конфигурации виртуальных машин старше 8.0 (соответствующие Windows Server 2016), не могут работать в Windows Server 2022.
Например, если виртуальные машины были созданы в системе Windows Server 2012 R2 и используют конфигурацию виртуальной машины версии 5.0, а кластер обновлен до Windows Server 2022, необходимо обновить конфигурацию виртуальной машины до версии 8.0 или более поздней. Дополнительные сведения см. в статье "Миграция и обновление виртуальных машин".

Шаг 1. Подготовка кластера к обновлению

Перед началом обновления узлов убедитесь, что кластер работоспособен и готов к обновлению:

Убедитесь, что кластер имеет достаточную пропускную способность для поддержания соответствующих соглашений об уровне доступности услуг при отключении одного узла.
- Достаточно ли в кластере ресурсов хранилища, ЦП и сетевых ресурсов для выполнения необходимых рабочих нагрузок при удалении одного узла из кластера?
- Достаточно ли узлов в кластере для поддержания требуемой отказоустойчивости с одним узлом в автономном режиме? Может потребоваться временно добавить узел в два кластера узлов для поддержания отказоустойчивости во время обновления.
Для рабочих нагрузок Hyper-V убедитесь, что все узлы Windows Server Hyper-V имеют поддержку ЦП для таблицы адресов второго уровня (SLAT). Только компьютеры с поддержкой SLAT могут использовать роль Hyper-V в Windows Server 2016 и более поздней версии.
Установите последние обновления программного обеспечения на всех узлах кластера.
Убедитесь, что все резервные копии рабочей нагрузки завершены, и рассмотрите возможность резервного копирования базы данных кластера с резервным копированием состояния системы.
Убедитесь, что все узлы кластера работают с помощью командлета Get-ClusterNode .
```
Get-ClusterNode
```
Ниже приведен пример выходных данных:
```
Name        ID    State
----        --    -----
Node1       1     Up
Node2       2     Up
Node3       3     Up
```
Остановите все средства обновления, работающие в кластере. Например, если вы используете обновление с учетом кластера, выполните следующие действия.
1. Проверьте, выполняется ли в настоящее время Cluster Aware Updating (CAU), используя пользовательский интерфейс Cluster-Aware Updating или командлет Get-CauRun.
```
Get-CauRun
```
  Ниже приведен пример выходных данных в кластере с именем Cluster01:
```
RunNotInProgress
WARNING: No Updating Run is currently in progress on cluster Cluster01.
```
2. Остановите процесс обновления с учетом кластеризации, используя командлет Disable-CauClusterRole, чтобы предотвратить автоматическую приостановку и выгрузку узлов во время обновления.
```
Disable-CauClusterRole
```
  Ниже приведен пример выходных данных:
```
Are you sure?
Do you want to disable the Cluster-Aware Updating clustered role on cluster "Cluster01"?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):
```

Шаг 2. Передача рабочих нагрузок с узла

Выполните следующие действия на одном узле в кластере (повторяйте этот процесс одновременно для каждого узла в кластере):

Чтобы осушить узел в Windows Admin Center, перейдите в Диспетчер кластеров>Серверы, выберите узел, а затем выберите Приостановить. Чтобы использовать диспетчер отказоустойчивости кластеров, выберите узел и выберите "Приостановить>очистку", как показано на рис. 2. Или используйте командлет Suspend-ClusterNode с параметром -Drain, как показано здесь.

Рис. 2: Освобождение ролей с узла с использованием диспетчера отказоустойчивого кластера
```
Suspend-ClusterNode -Name Node1 -Drain
```
Ниже приведен пример выходных данных, показывающих, что узел кластера приостановлен:
```
Name           ID    State
----           --    -----
Node1          1     Paused
```
Если вы используете Hyper-V с виртуальными коммутаторами, привязанными к команде LBFO, и выполняете обновление на месте до Windows Server 2022 или более поздней версии, удалите команду перед началом обновления. После обновления можно привязать сетевые адаптеры к виртуальному коммутатору, который использует более новую технологию коммутатора SET.

Команды LBFO больше не поддерживаются с Hyper-V в Windows Server 2022 и более поздней версии. Дополнительные сведения об удаленных функциях см. в разделе "Функции", удаленные или не разработанные в Windows Server.
Если вы собираетесь выполнить чистую установку ОС на узле, сначала удалите (вытесните) приостановленный узел из кластера с помощью Windows Admin Center, диспетчера отказоустойчивых кластеров или командлета Remove-ClusterNode .
```
Remove-ClusterNode -Name Node1
```
Пример результата выглядит следующим образом.
```
Are you sure you want to evict node Node1?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):
```

Шаг 3. Установка новой версии Windows Server

Выполните обновление или чистую установку более новой версии Windows Server на узле.
Если вы обновили до Windows Server 2022 или более поздней версии и удалили команду LBFO перед обновлением, создайте новый виртуальный коммутатор Hyper-V, использующий новую технологию Switch Embedded Teaming (SET) для привязки к нескольким сетевым адаптерам. Вы можете использовать Windows Admin Center, Hyper-V Manager или командлет New-VMSwitch PowerShell.
Если вы выполнили чистую установку, подготовьте узел к повторному присоединению к кластеру:
1. Подключите узел к соответствующему домену службы Active Directory Domain Services. Убедитесь, что вы используете то же имя компьютера, если в кластере используется Storage Spaces Direct.
2. Добавьте соответствующих пользователей в локальную группу администраторов.
3. Установите все необходимые роли и компоненты сервера, такие как Hyper-V, отказоустойчивая кластеризация и NetworkATC (доступно в Windows Server 2025). Можно использовать Windows Admin Center, Server Manager или командлет PowerShell Install-WindowsFeature, как показано в следующем примере:
```
Install-WindowsFeature -Name "Hyper-V", "Failover-Clustering", "NetworkATC" -IncludeAllSubFeature -IncludeManagementTools
```
4. Проверьте параметры подключения к сети и хранилищу.
5. Если используется брандмауэр Windows, проверьте правильность параметров брандмауэра для кластера. Например, для обновления с учетом кластера может потребоваться настройка брандмауэра.
6. Для рабочих нагрузок Hyper-V создайте виртуальные коммутаторы, соответствующие остальным узлам кластера (за исключением конфигурации LBFO, если вы заменяете команды сетевых адаптеров). Вы можете использовать Windows Admin Center, Hyper-V Manager или командлеты PowerShell Get-VMSwitch и Add-VMSwitch.
7. Подключитесь к обновленному узлу, а затем используйте Windows Admin Center, диспетчер отказоустойчивых кластеров или командлет Add-ClusterNode , чтобы добавить обновленный узел обратно в кластер.
```
Add-ClusterNode -Name clusternode1
```
  Пример результата выглядит следующим образом.
```
Waiting for notification that node clusternode1 is a fully functional member of the cluster.
```
  Примечание.
  
  Когда первый обновленный узел присоединяется к кластеру, кластер вводит режим Mixed-OS, а основные ресурсы кластера перемещаются на более новый узел. Кластер режима Mixed-OS — это полностью функциональный кластер, в котором новые узлы выполняются в режиме совместимости со старыми узлами. Режим Mixed-OS — это временный режим для кластера, и все узлы кластера следует обновить в течение четырех недель.
8. При необходимости перебалансировать кластер, переместив рабочие нагрузки на только что добавленный узел.
- Чтобы перемещать работающие виртуальные машины без простоя, используйте Live Migration в Windows Admin Center, Менеджер отказоустойчивого кластера или командлет Move-ClusterVirtualMachineRole.
```
Move-ClusterVirtualMachineRole -Name VM1 -Node node1
```
  Пример результата выглядит следующим образом.
```
Name      OwnerNode     State
----      ---------     -----
VM1       node1         Online
```
- Чтобы переместить другие рабочие нагрузки кластера, используйте команду Move в диспетчере отказоустойчивых кластеров или командлет Move-ClusterGroup.

Шаг 4. Повторите шаги 2–4 для каждого другого узла в кластере

Процесс обновления полностью обратим, пока не обновите функциональный уровень кластера на следующем шаге. Чтобы отказаться от обновления, добавьте узлы, которые запускают исходную версию Windows Server, а затем удалите все узлы, выполняющие более новую версию ОС.

Шаг 5. Обновление версии функционального уровня кластера и пула носителей

Обновление функционального уровня кластера и версии пула носителей позволяет использовать новые функции. Кроме того, эта функция улучшает некоторые операции кластера, такие как перемещение нагрузок с узла, что может привести к изоляции узла на короткий период времени при выполнении в кластере с разнородными операционными системами.

Когда у каждого узла установлена более новая версия ОС и она будет добавлена в кластер или окончательно удалена, выполните следующие действия, чтобы обновить функциональный уровень кластера и версию пула носителей.

Внимание

После обновления функционального уровня кластера и версии пула носителей вы не сможете вернуться к более ранней версии функционального уровня или пула носителей, и вы не сможете добавлять узлы, работающие с более ранними версиями Windows Server в кластер.

Убедитесь, что все роли кластера выполняются в кластере должным образом. Вы можете использовать Windows Admin Center, диспетчер отказоустойчивых кластеров или командлет Get-ClusterGroup :
```
Get-ClusterGroup
```
Ниже приведен пример выходных данных с четырьмя виртуальными машинами и группой кластеров в Сети:
```
Name                OwnerNode      State
----                ---------      -----
Available Storage   node2          Offline
VM1                 node2          Online
VM2                 node1          Online
VM3                 node1          Online
VM4                 node3          Online
Cluster Group       node1          Online
```
Группа доступных хранилищ не используется и находится в автономном режиме, так как этот кластер использует общие тома кластера (CSVS) для хранения. Доступное хранилище будет в режиме онлайн, если кластер использует диски, назначенные ему из LUNs в SAN, но вместо этого рекомендуется использовать CSVs.
Убедитесь, что все узлы кластера находятся в сети и запущены с помощью Windows Admin Center, диспетчера отказоустойчивых кластеров или командлета Get-ClusterNode.
```
Get-ClusterNode
```
Ниже приведен пример выходных данных:
```
Name        ID    State
----        --    -----
node1       1     Up
node2       2     Up
node3       3     Up
```
Просмотрите функциональный уровень кластера в Windows Admin Center, перейдя к Диспетчеру кластера>Параметры>Кластер>Свойства. Или используйте командлет Get-Cluster :
```
Get-Cluster | Select ClusterFunctionalLevel
```
Ниже приведен пример выходных данных:
```
ClusterFunctionalLevel
-----------------------
10
```
Выберите новый функциональный уровень в Центре администрирования Windows или запустите командлет Update-ClusterFunctionalLevel. Ошибки не должны быть возвращены.
```
Update-ClusterFunctionalLevel
```
Пример результата выглядит следующим образом.
```
Updating the Functional level for cluster cluster01.
Warning: You cannot undo this operation. Do you want to continue?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):
```
Убедитесь, что функциональный уровень кластера обновлен с помощью командлета Get-Cluster :
```
Get-Cluster | Select ClusterFunctionalLevel
```
Пример результата выглядит следующим образом.
```
ClusterFunctionalLevel
-----------------------
11
```
Если вы используете пулы носителей, их можно обновить без простоя, используя Кластерный диспетчер Windows Admin Center, Настройки, Хранилища и пулы носителей, Версия пула носителей. Или используйте командлет PowerShell Update-StoragePool.

Шаг 6. Возобновление обычных операций кластера и включение новых функций

Чтобы возобновить обычные операции кластера и включить новые функциональные возможности, выполните следующие действия.

Если вы перестали обновлять инструменты, начните обновление снова. Например, чтобы запустить обновление с учетом кластера, вы можете использовать средство обновления с учетом кластера или командлет Enable-CauClusterRole.
```
Enable-CauClusterRole
```
Пример результата выглядит следующим образом.
```
Are you sure?
Do you want to enable the Cluster-Aware Updating Clustered role on Cluster "cluster01"?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):
```
Возобновление всех операций резервного копирования, остановленных для обновления.
Чтобы включить новые функциональные возможности, доступные для виртуальных машин, обновите версию конфигурации для каждой виртуальной машины. Список новых возможностей Hyper-V см. в разделе "Миграция и обновление виртуальных машин".
1. Просмотр версий виртуальных машин, поддерживаемых каждым узлом с помощью командлета Get-VMHostSupportedVersion . На этом этапе каждый узел должен иметь одинаковые поддерживаемые версии.
```
Get-VMHostSupportedVersion -ComputerName node1
```
  Ниже приведен пример выходных данных с номерами версий виртуальной машины и соответствующим именем операционной системы:
```
Name                                                  Version IsDefault
----                                                  ------- ---------
Microsoft Windows 10 Anniversary Update/Server 2016   8.0     False
Microsoft Windows 10 Creators Update                  8.1     False
Microsoft Windows 10 Fall Creators Update/Server 1709 8.2     False
Microsoft Windows 10 April 2018 Update/Server 1803    8.3     False
Microsoft Windows 10 October 2018 Update/Server 2019  9.0     False
Microsoft Windows 10 May 2019 Update/Server 1903      9.1     False
Microsoft Windows 10 May 2020 Update/Server 2004      9.2     False
Microsoft Windows 10 (Manganese)                      9.3     False
Microsoft Windows Server 2022                         10.0    False
Microsoft Host OS (Cobalt+)                           10.5    False
Microsoft Windows 11 (22H2)                           11.0    False
Microsoft Windows 11 (Copper)                         11.1    False
Microsoft Windows 11 (Zinc)                           11.2    False
Microsoft Windows Server 2025                         12.0    True
```
2. Просмотр виртуальных машин на каждом узле в кластере с помощью командлета Get-VM .
```
Get-VM -ComputerName node1
```
  Пример результата выглядит следующим образом.
```
Name    State   CPUUsage(%) MemoryAssigned(M) Uptime              Status             Version
----    -----   ----------- ----------------- ------              ------             -------
VM1     Running 0           12288             2.20:28:49.6670000  Operating normally 8.0
VM2     Running 0           4096              14.23:13:12.7370000 Operating normally 8.0
VM3     Running 0           1216              2.20:09:38.9450000  Operating normally 8.0
```
3. Во время запланированного периода обслуживания, когда можно отключить виртуальные машины, выполните резервное копирование и обновление всех старых виртуальных машин на каждом узле.
  Чтобы сделать это в Windows Admin Center, перейдите квиртуальным машинам>, выберите виртуальную машину, а затем выберите "Управление>версией конфигурации обновления".
  Или используйте командлет Update-VMVersion , как показано в этом примере, который обновляет все виртуальные машины на одном узле до последней версии.
```
Update-VMVersion -ComputerName node1 -Name * -WhatIf
```
  Пример результата выглядит следующим образом.
```
Confirm
Are you sure you want to perform this action?
Performing a configuration version update of "dc1" will prevent it from being migrated to or imported on previous
versions of Windows. This operation is not reversible.

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):
```

Состояния перехода кластера во время последовательного обновления ОС кластера

Свойство общедоступного кластера ClusterFunctionalLevel указывает состояние кластера на узлах Windows Server 2016 и более поздних версий. Это свойство можно запрашивать с помощью командлета PowerShell из узла кластера, который принадлежит к отказоустойчивому кластеру:

Get-Cluster | Select ClusterFunctionalLevel

В следующей таблице показаны значения и каждый соответствующий функциональный уровень:

Значение	Функциональный уровень
8	Windows Server 2012 R2
9	Windows Server 2016
10	Windows Server 2019
11	Windows Server 2022
12	Windows Server 2025

Часто задаваемые вопросы

Сколько времени может функционировать отказоустойчивый кластер в смешанном режиме ОС?
Мы рекомендуем клиентам завершить обновление в течение четырех недель. кластеры файлового сервера Hyper-V и с горизонтальным масштабированием можно обновлять менее чем за четыре часа, полностью без простоя.
Можно ли запустить командлет Update-ClusterFunctionalLevel , пока узлы отключены или приостановлены?
№ Для успешной работы командлета Update-ClusterFunctionalLevel все узлы кластера должны быть включены и находиться в активном состоянии.
Работает ли кластерное обновление ОС для любой кластерной нагрузки? Работает ли он для SQL Server?
Да, "Cluster OS Rolling Upgrade" подходит для любой рабочей нагрузки кластера. Однако это касается только нулевого времени простоя для кластеров Hyper-V и кластеров масштабируемого файлового сервера. Большинство других рабочих нагрузок переходят в состояние простоя (обычно пару минут) при переключении на резервный сервер, а переключение требуется по крайней мере один раз во время процесса последовательного обновления ОС кластера.
Можно ли автоматизировать этот процесс с помощью PowerShell?
Да.
Для большого кластера с дополнительной резервной мощностью можно обновить несколько узлов одновременно?
Да. Если один узел удаляется из кластера для обновления ОС, в кластере имеется на один узел меньше для обеспечения отказоустойчивости, поэтому его способность к отказоустойчивости уменьшена. Для больших кластеров с достаточной рабочей нагрузкой и возможностью восстановления после отказа несколько узлов могут быть обновлены одновременно.
Что делать, если обнаружена проблема в кластере после успешного запуска Update-ClusterFunctionalLevel ?
Если вы создали резервную копию базы данных кластера с резервной копией состояния системы перед запуском Update-ClusterFunctionalLevel, вы сможете выполнить авторизованное восстановление на узле под управлением предыдущей версии Windows Server и восстановить исходную базу данных кластера и конфигурацию.
Можно ли использовать обновление на месте для каждого узла вместо использования чистой ОС, переформатируя системный диск?
Да. В прошлом мы рекомендуем выполнить чистую установку ОС на каждом узле. Однако теперь вы можете выполнить обновление узла кластера на месте, если тщательно читаете и разрешаете любые предупреждающие сообщения.
Если вы используете репликацию Hyper-V для виртуальной машины Hyper-V в кластере Hyper-V, репликация останется нетронутой во время и после процесса последовательного обновления ОС кластера?
Да, реплика Hyper-V остается нетронутой во время и после процесса последовательного обновления ОС кластера.
Можно ли использовать System Center Virtual Machine Manager (VMM) для автоматизации процесса последовательного обновления ОС кластера? Да, вы можете автоматизировать процесс последовательного обновления ОС кластера с помощью VMM в System Center.