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

Применяется к: ✅ 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 Local клиенты должны использовать процесс обновления, описанный в разделе Об Azure Local обновлениях. Однако, вы можете использовать эту статью, если ни один из методов обновления Azure Local не подходит для вас.

Overview

Последовательное обновление кластера до следующей более новой версии 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 имеют процессоры, поддерживающие вторичную таблицу адресации (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 имеют поддержку ЦП для таблицы адресов Second-Level (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, перейдите к Cluster Manager>Servers, выберите узел, а затем выберите Pause. Чтобы использовать диспетчер отказоустойчивости кластеров, выберите узел и выберите "Приостановить>очистку", как показано на рис. 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 или командлет PowerShell New-VMSwitch.
Если вы выполнили чистую установку, подготовьте узел к повторному присоединению к кластеру:
1. Присоединение узла к соответствующему домену доменные службы Active Directory. Обязательно используйте то же имя компьютера, если кластер использует Локальные дисковые пространства.
2. Добавьте соответствующих пользователей в локальную группу администраторов.
3. Установите все необходимые роли и компоненты сервера, такие как Hyper-V, отказоустойчивая кластеризация и NetworkATC (доступна в Windows Server 2025). Вы можете использовать Windows Admin Center, диспетчер сервера или командлет 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.
```
  Note
  
  Когда первый обновленный узел присоединяется к кластеру, кластер вводит режим Mixed-OS, а основные ресурсы кластера перемещаются на более новый узел. Кластер режима Mixed-OS — это полностью функциональный кластер, в котором новые узлы выполняются в режиме совместимости со старыми узлами. Режим Mixed-OS — это временный режим для кластера, и все узлы кластера следует обновить в течение четырех недель.
8. Если вы выполнили обновление на месте, возобновите узел с помощью командлета Windows Admin Center, диспетчера отказоустойчивого кластера или командлета Resume-ClusterNode.
```
Resume-ClusterNode -Name clusternode1 -Failback Immediate
```
  Ниже приведен пример выходных данных, показывающих, что узел кластера теперь работает:
```
Name         State Type
----         ----- ----
clusternode1 Up    Node
```
9. При необходимости перебалансировать кластер, переместив рабочие нагрузки на только что добавленный узел.
- Чтобы переместить виртуальные машины без простоя, используйте функцию 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. Обновление версии функционального уровня кластера и пула носителей

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

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

Important

После обновления функционального уровня кластера и версии пула носителей вы не сможете вернуться к более ранней версии функционального уровня или пула носителей, и вы не сможете добавлять узлы, работающие с более ранними версиями 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, перейдя к Cluster Manager>Settings>Cluster>Properties. Или используйте командлет Get-Cluster :
```
Get-Cluster | Select ClusterFunctionalLevel
```
Ниже приведен пример выходных данных:
```
ClusterFunctionalLevel
-----------------------
10
```
Выберите новый функциональный уровень в Windows Admin Center или запустите командлет 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 >Cluster Manager>Settings>Хранилища и пулы>Версия пула хранения. Или используйте командлет PowerShell Update-StoragePool.

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

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

Если вы перестали обновлять инструменты, начните обновление снова. Например, чтобы начать обновление с учетом кластера, можно использовать средство Cluster Aware Updating или командлет 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 см. в разделе Migrate и обновление виртуальных машин.
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 перейдите к Cluster Manager>Virtual machine, выберите виртуальную машину и выберите версию конфигурации Manage>Upgrade configuration version.
  Или используйте командлет 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

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

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

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

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

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-08-16