Atualize um cluster de failover do Windows Server com uma atualização contínua do sistema operativo do cluster

Aplica-se a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016, ✅ Azure Local 2311.2 and later

Este artigo descreve como instalar manualmente uma atualização de funcionalidade num cluster de failover do Windows Server sem parar cargas de trabalho. O processo atualiza um nó de cada vez em uma atualização contínua e geralmente é chamado de Atualização de Cluster do SO Contínuo.

Pode atualizar o cluster uma versão do sistema operativo de cada vez, por exemplo, de Windows Server 2022 a Windows Server 2025. Para atualizar entre várias versões do sistema operativo, como do Windows Server 2016 para o Windows Server 2025, execute os passos deste artigo para cada versão.

Este artigo aplica-se a clusters que executam máquinas virtuais Hyper-V ou cargas de trabalho Scale-out File Server (SOFS) que atualizam uma versão do sistema operativo, mas não se aplica a clusters que utilizam discos rígidos virtuais (ficheiros .vhdx) como armazenamento partilhado. Se estiver a usar o System Center Virtual Machine Manager (VMM), consulte antes Realize uma atualização escalonada de um cluster de hosts Hyper-V no VMM. Os clientes do Azure Local devem usar o processo de atualização descrito em Sobre atualizações do Azure Local, embora possa usá-lo se nenhum dos métodos de atualização do Azure Local funcionar para si.

Overview

Uma atualização contínua de um cluster para a próxima versão mais recente do Windows Server oferece os seguintes benefícios:

Atualize um cluster que execute máquinas virtuais Hyper-V ou cargas de trabalho Scale-out File Server (SOFS) para a próxima versão mais recente do Windows Server sem tempo de inatividade.
Nenhum novo hardware é necessário, embora você possa optar por adicionar temporariamente nós de cluster a clusters pequenos para melhorar a disponibilidade durante a atualização.
O cluster pode suportar operações de aplicação de patches e manutenção durante a atualização, quando há uma combinação de versões do sistema operacional no cluster.
O processo de atualização é reversível até ao passo final, quando todos os nós do cluster estão a correr a versão mais recente do Windows Server e se atualiza o nível funcional do cluster.
Ele suporta automação via PowerShell e WMI.

Em um nível alto, uma atualização contínua consiste nestas etapas:

Prepare o cluster para a atualização do recurso do sistema operacional.
Desloque as cargas de trabalho do primeiro nó.
Faça a atualização da funcionalidade do Windows Server através de uma atualização ou instalação limpa.
Repita as etapas 2 a 3 para cada outro nó no cluster.
Atualize o nível funcional do cluster e os pools de armazenamento para a nova versão do Windows Server.
Retome a operação normal e atualize as versões de configuração da VM para ativar a nova funcionalidade.

Para obter um diagrama detalhado do processo de atualização contínua, consulte a Figura 1.

Figura 1: Diagrama do processo de atualização contínua

Requisitos e limitações

Preencha os seguintes requisitos antes de iniciar a atualização:

Comece com um Cluster de Failover a correr Windows Server 2012 R2 ou mais recente.
Verifique se os nós Hyper-V têm CPUs que suportem a Tabela de Endereçamento de Segundo Nível (SLAT) usando um dos seguintes métodos:
- Leia o artigo É compatível com SLAT? WP8 SDK Dica 01 que descreve dois métodos para verificar se uma CPU suporta SLATs
- Baixe a ferramenta Coreinfo v3.31 para determinar se uma CPU suporta SLAT.

Aqui estão algumas limitações a ter em conta:

Recomendamos passar pelo processo de atualização do cluster dentro de quatro semanas porque alguns recursos do cluster não são otimizados para clusters que executam duas versões diferentes do sistema operacional.
- Ao gerir um cluster de modo misto de sistema operativo, execute sempre as tarefas de gestão a partir de um nó que execute a versão mais recente do Windows Server. Versões mais antigas do Windows Server muitas vezes não conseguem usar UI ou ferramentas de gestão para gerir versões mais recentes.
- Evite criar ou redimensionar armazenamento em nós mais recentes do Windows Server enquanto o cluster está a correr uma mistura de versões do sistema operativo. Fazer isso pode levar a possíveis incompatibilidades ao fazer failover de um nó mais recente para um Windows Server mais antigo.
Só pode atualizar para a próxima versão mais recente do sistema operativo, por exemplo, do Windows Server 2022 para o Windows Server 2025.
Para atualizar em várias versões, como do Windows Server 2016 para o Windows Server 2025, execute a atualização sequencialmente (primeiro para Windows Server 2019, depois para Windows Server 2022 e, finalmente, para Windows Server 2025), ou migrar para um novo cluster.
Deve atualizar a versão de configuração das VMs antigas antes que possam correr num cluster Windows Server 2022 ou mais recente, independentemente da forma como atualize. Versões de configuração de VM anteriores à 8.0 (correspondentes ao Windows Server 2016) não conseguem correr no Windows Server 2022.
Por exemplo, se as suas VMs foram criadas num sistema Windows Server 2012 R2 e usam a versão 5.0 da configuração da VM, e atualiza o cluster para o Windows Server 2022, deve atualizar a versão da configuração da VM para a 8.0 ou mais recente. Para obter mais informações, consulte Migrar e atualizar máquinas virtuais.

Etapa 1: Preparar o cluster para a atualização

Antes de começar a atualizar os nós, verifique se o cluster está em bom estado e pronto para a atualização:

Verifique se o cluster tem capacidade suficiente para manter acordos de nível de serviço de tempo operacional apropriados, mesmo com um nó removido.
- O cluster tem armazenamento, CPU e recursos de rede suficientes para executar as cargas de trabalho necessárias quando um nó é removido do cluster?
- Existem nós suficientes no cluster para manter a tolerância a falhas necessária com um nó offline? Talvez você queira adicionar temporariamente um nó a um cluster de dois nós para manter a tolerância a falhas durante a atualização.
Para as cargas de trabalho Hyper-V, verifique se todos os hosts Windows Server Hyper-V têm suporte a CPU para Tabela de Endereços de Segundo Nível (SLAT). Apenas máquinas compatíveis com SLAT podem usar a função Hyper-V no Windows Server 2016 e mais recentes.
Instale as atualizações de software mais recentes em todos os nós do cluster.
Verifique se todos os backups de carga de trabalho estão concluídos e considere fazer backup do banco de dados de cluster com um backup do Estado do Sistema.

Verifique se todos os nós do cluster estão ativos usando o cmdlet Get-ClusterNode .

Get-ClusterNode

Aqui está um exemplo de saída:

Name        ID    State
----        --    -----
Node1       1     Up
Node2       2     Up
Node3       3     Up

Pare todas as ferramentas de atualização que estão sendo executadas no cluster. Por exemplo, se estiverem a usar Atualizações Ciente de Clusters, sigam os seguintes passos:
1. Verifique se a Atualização com Suporte a Cluster (CAU) está atualmente em execução, usando a interface de utilizador de Atualização com Suporte de Cluster (CAU) ou o cmdlet Get-CauRun.
```
Get-CauRun
```
  Aqui está um exemplo de saída no cluster chamado "Cluster01":
```
RunNotInProgress
WARNING: No Updating Run is currently in progress on cluster Cluster01.
```
2. Pare a Atualização de Conscientização de Cluster usando o cmdlet Disable-CauClusterRole para impedir que quaisquer nós sejam pausados e drenados automaticamente durante a atualização.
```
Disable-CauClusterRole
```
  Aqui está um exemplo de saída:
```
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"):
```

Etapa 2: Transferir cargas de trabalho de um nó

Execute as seguintes etapas em um dos nós do cluster (repita este processo um de cada vez para cada nó do cluster):

Para drenar o nó no Windows Admin Center, navegue até Gestor de Cluster>Servidores, selecione o nó e depois selecione Pausar. Para usar o Gestor de Cluster de Failover, selecione o nó e, em seguida, selecione Pause>Drain, como mostra a Figura 2. Ou use o cmdlet Suspend-ClusterNode com o -Drain parâmetro, conforme mostrado aqui.

Figura 2: Drenando funções de um nó usando o Gerenciador de Cluster de Failover
```
Suspend-ClusterNode -Name Node1 -Drain
```
Aqui está um exemplo da saída mostrando que o nó do cluster agora está pausado:
```
Name           ID    State
----           --    -----
Node1          1     Paused
```
Se estiveres a usar Hyper-V com switches virtuais ligados a uma equipa LBFO e estiveres a fazer uma atualização no local para o Windows Server 2022 ou mais recente, remove a equipa antes de iniciar a atualização. Após a atualização, você pode vincular os adaptadores de rede a um comutador virtual que usa a tecnologia de comutador SET mais recente.

As equipas LBFO já não são suportadas com Hyper-V no Windows Server 2022 e versões posteriores. Para mais informações sobre funcionalidades removidas, consulte Funcionalidades removidas ou já não foram desenvolvidas em Windows Server.
Esta etapa é opcional, dependendo de estar a realizar uma atualização no local ou uma instalação limpa do sistema operativo. Se vais fazer uma instalação limpa do sistema operativo no nó, primeiro remove (expulsa) o nó pausado do cluster usando Windows Admin Center, Gestor de Clusters de Failover ou o cmdlet Remove-ClusterNode.
```
Remove-ClusterNode -Name Node1
```
Eis um exemplo do resultado:
```
Are you sure you want to evict node Node1?
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):
```

Passo 3: Instalar a nova versão do Windows Server

Efetue uma atualização ou instalação limpa da versão mais recente do Windows Server no nó.
Se atualizou para o Windows Server 2022 ou mais recente e removeu uma equipa LBFO antes de atualizar, crie um novo switch virtual Hyper-V que utilize a mais recente tecnologia Switch Embedded Teaming (SET) para se ligar a múltiplos adaptadores de rede. Podes usar Windows Admin Center, Hyper-V Manager ou o cmdlet PowerShell New-VMSwitch.
Se você executou uma instalação limpa, prepare o nó para ingressar novamente no cluster:
1. Adicione o nó ao domínio de Active Directory Domain Services apropriado. Certifique-se de usar o mesmo nome do computador se o cluster usar Espaços de Armazenamento Direto.
2. Adicione os usuários apropriados ao grupo Administradores local.
3. Instale quaisquer funções e funcionalidades de servidor que precise, como o Hyper-V, o Cluster de Failover e o NetworkATC (disponível no Windows Server 2025). Pode usar Windows Admin Center, Gestor de Servidor ou o cmdlet PowerShell Install-WindowsFeature, como mostrado no exemplo seguinte:
```
Install-WindowsFeature -Name "Hyper-V", "Failover-Clustering", "NetworkATC" -IncludeAllSubFeature -IncludeManagementTools
```
4. Verifique as configurações de conectividade de rede e armazenamento.
5. Se for usado o Windows Firewall, verifique se as definições do firewall estão corretas para o cluster. Por exemplo, a Atualização Compatível com Clusters pode exigir a configuração do firewall.
6. Para cargas de trabalho Hyper-V, cria switches virtuais que correspondam ao resto dos nós do cluster (exceto para a configuração LBFO se estiveres a substituir equipas de adaptadores de rede). Podes usar Windows Admin Center, Hyper-V Manager, ou os cmdlets PowerShell Get-VMSwitch e Add-VMSwitch PowerShell.
7. Se fizeste uma instalação limpa do sistema operativo no nó, liga-te ao nó atualizado e depois usa o Windows Admin Center, o Gestor de Clusters de Failover ou o cmdlet Add-ClusterNode para adicionar o nó atualizado de volta ao cluster. Se tiver executado uma atualização no local, não precisará fazer esta etapa porque o nó ainda faz parte do cluster.
```
Add-ClusterNode -Name clusternode1
```
  Eis um exemplo do resultado:
```
Waiting for notification that node clusternode1 is a fully functional member of the cluster.
```
  Note
  
  Quando o primeiro nó atualizado ingressa no cluster, o cluster entra no modo "Mixed-OS" e os recursos principais do cluster são movidos para o nó mais recente. Um cluster de modo "Mixed-OS" é um cluster totalmente funcional onde os novos nós são executados em um modo de compatibilidade com os nós antigos. O modo "Mixed-OS" é um modo transitório para o cluster e você deve atualizar todos os nós do cluster dentro de quatro semanas.
8. Se realizou uma atualização local, retome o nó usando o Windows Admin Center, o Gerenciador de Cluster de Failover ou o cmdlet Resume-ClusterNode.
```
Resume-ClusterNode -Name clusternode1 -Failback Immediate
```
  Aqui está um exemplo da saída mostrando que o nó do cluster está ativo:
```
Name         State Type
----         ----- ----
clusternode1 Up    Node
```
9. Opcionalmente, reequilibre o cluster movendo cargas de trabalho para o nó recém-adicionado.
- Para mover máquinas virtuais em execução sem tempo de inatividade, use Migração ao Vivo no Windows Admin Center, Gestor de Clusters de Failover ou o cmdlet Move-ClusterVirtualMachineRole.
```
Move-ClusterVirtualMachineRole -Name VM1 -Node node1
```
  Eis um exemplo do resultado:
```
Name      OwnerNode     State
----      ---------     -----
VM1       node1         Online
```
- Para mover outras cargas de trabalho de cluster, use o comando Mover no Gerenciador de Cluster de Failover ou o cmdlet Move-ClusterGroup .

Etapa 4: Repita as etapas 2 a 4 para todos os outros nós no cluster

O processo de atualização é totalmente reversível até que você atualize o nível funcional do cluster na próxima etapa. Para abandonar a atualização, adicione nós que corram a versão original do Windows Server e depois remova quaisquer nós que corram a versão mais recente do sistema operativo.

Etapa 5: Atualizar o nível funcional do cluster e a versão do pool de armazenamento

A atualização do nível funcional do cluster e da versão do pool de armazenamento possibilita o uso de novos recursos. Melhora também algumas operações de cluster, como a transferência de cargas de trabalho de um nó, o que pode levar esse nó a ficar isolado por um curto período de tempo se for executado num cluster de sistemas operativos mistos.

Quando cada nó tiver a versão mais recente do sistema operacional instalada e for adicionada de volta ao cluster ou removida permanentemente, conclua as etapas a seguir para atualizar o nível funcional do cluster e a versão do pool de armazenamento.

Important

Depois de atualizar o nível funcional do cluster e a versão do pool de armazenamento, não pode voltar a um nível funcional anterior ou a uma versão do pool de armazenamento e não pode adicionar nós que corram versões anteriores do Windows Server ao cluster.

Verifique se todas as funções de cluster estão sendo executadas no cluster conforme o esperado. Pode usar Windows Admin Center, Gestor de Clusters de Failover ou o cmdlet Get-ClusterGroup:
```
Get-ClusterGroup
```
Aqui está um exemplo da saída mostrando quatro VMs e o grupo de clusters online:
```
Name                OwnerNode      State
----                ---------      -----
Available Storage   node2          Offline
VM1                 node2          Online
VM2                 node1          Online
VM3                 node1          Online
VM4                 node3          Online
Cluster Group       node1          Online
```
O grupo Armazenamento Disponível não é usado e está offline porque esse cluster usa CSVs (Volumes Compartilhados de Cluster) para armazenamento. O armazenamento disponível estaria on-line se o cluster usasse discos atribuídos a ele a partir de LUNS em uma SAN, mas recomendamos o uso de CSVs.
Verifique se todos os nós do cluster estão online e a funcionar usando Windows Admin Center, Gestor de Clusters de Failover ou o cmdlet Get-ClusterNode.
```
Get-ClusterNode
```
Aqui está um exemplo de saída:
```
Name        ID    State
----        --    -----
node1       1     Up
node2       2     Up
node3       3     Up
```
Veja o nível funcional do cluster em Windows Admin Center navegando até Gestor de Cluster>Settings>Cluster>Properties. Ou use o cmdlet Get-Cluster :
```
Get-Cluster | Select ClusterFunctionalLevel
```
Aqui está um exemplo de saída:
```
ClusterFunctionalLevel
-----------------------
10
```

Selecione o novo nível funcional no Windows Admin Center ou execute o cmdlet Update-ClusterFunctionalLevel - não devem ser retornados erros.

Update-ClusterFunctionalLevel

Eis um exemplo do resultado:

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"):

Confirme se o nível funcional do cluster foi atualizado usando o cmdlet Get-Cluster :
```
Get-Cluster | Select ClusterFunctionalLevel
```
Eis um exemplo do resultado:
```
ClusterFunctionalLevel
-----------------------
11
```
Se estiver a usar pools de armazenamento, pode atualizá-los sem interrupção usando o Windows Admin Center >Cluster Manager>Definições>Storage Spaces and Pools>versão do pool de armazenamento. Ou use o cmdlet Update-StoragePool PowerShell.

Etapa 6: Retomar as operações normais de cluster e ativar a nova funcionalidade

Para retomar as operações normais do cluster e ativar a nova funcionalidade, execute as seguintes etapas:

Se você parou de atualizar as ferramentas, inicie-as novamente. Por exemplo, para iniciar a Atualização com Reconhecimento de Cluster, pode-se usar a ferramenta Atualização com Reconhecimento de Cluster ou o cmdlet Enable-CauClusterRole.
```
Enable-CauClusterRole
```
Eis um exemplo do resultado:
```
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"):
```
Retome todas as operações de backup interrompidas para a atualização.

Para ativar a nova funcionalidade disponível para VMs, atualize a versão de configuração para cada VM. Para uma lista de novas capacidades Hyper-V, veja Migrar e atualizar máquinas virtuais.

Exiba as versões de VM suportadas por cada nó usando o cmdlet Get-VMHostSupportedVersion . Cada nó deve ter as mesmas versões suportadas neste momento.

Get-VMHostSupportedVersion -ComputerName node1

Aqui está um exemplo da saída, mostrando os números de versão da VM e o nome do sistema operacional correspondente:

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

Exiba as VMs em cada nó do cluster usando o cmdlet Get-VM .

Get-VM -ComputerName node1

Eis um exemplo do resultado:

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

Durante uma janela de manutenção agendada, quando você pode colocar as VMs offline, faça backup e atualize todas as VMs mais antigas em cada nó.
Para o fazer no Windows Admin Center, navegue até Gestor de Cluster>Máquinas Virtuais, selecione uma VM e depois selecione Gerir>Atualização versão de configuração.
Ou use o cmdlet Update-VMVersion , conforme mostrado neste exemplo, que atualiza todas as VMs em um nó para a versão mais recente.
```
Update-VMVersion -ComputerName node1 -Name * -WhatIf
```
Eis um exemplo do resultado:
```
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"):
```

Estados de transição do cluster durante a Atualização Progressiva do SO de Cluster

A propriedade pública do cluster ClusterFunctionalLevel indica o estado do cluster nos nós do Windows Server 2016 e posteriores. Essa propriedade pode ser consultada usando o cmdlet PowerShell de um nó de cluster que pertence a um cluster de failover:

Get-Cluster | Select ClusterFunctionalLevel

A tabela a seguir mostra os valores e cada nível funcional correspondente:

Value	Nível funcional
8	Windows Server 2012 R2
9	Windows Server 2016
10	Windows Server 2019
11	Windows Server 2022
12	Windows Server 2025

Perguntas frequentes

Por quanto tempo o cluster de failover pode operar em modo de SO misto?
Incentivamos os clientes a concluir a atualização dentro de quatro semanas. Clusters de servidores de ficheiros Hyper-V e Scale-out podem ser atualizados sem tempo de inatividade em menos de quatro horas no total.
Posso executar o cmdlet Update-ClusterFunctionalLevel enquanto os nós estão desativados ou pausados?
No. Todos os nós de cluster devem estar ligados e em associação ativa para que o cmdlet Update-ClusterFunctionalLevel funcione.
Funciona a Rolling Upgrade do SO de Cluster para todas as cargas de trabalho de cluster? Funciona para o SQL Server?
Sim, a Atualização Contínua do SO do Cluster funciona para qualquer carga de trabalho de cluster. No entanto, é apenas zero tempo de inatividade para clusters de servidores de ficheiros Hyper-V e Scale-out. A maioria das outras cargas de trabalho incorre em algum tempo de inatividade (normalmente alguns minutos) quando fazem failover, e o failover é necessário pelo menos uma vez durante o processo de Atualização Contínua do SO Cluster.
Posso automatizar esse processo usando o PowerShell?
Yes.
Para um cluster grande com capacidade extra de failover, posso atualizar vários nós simultaneamente?
Yes. Quando um nó é removido do cluster para atualizar o sistema operativo, o cluster tem um nó a menos para recuperação de falhas, resultando assim numa capacidade de recuperação de falhas reduzida. Para clusters grandes com carga de trabalho e capacidade de tolerância a falhas suficientes, vários nós podem ser atualizados simultaneamente.
E se eu descobrir um problema no meu cluster depois que Update-ClusterFunctionalLevel tiver sido executado com êxito?
Se já fez backup da base de dados do cluster com uma cópia de segurança do Estado do Sistema antes de executar Update-ClusterFunctionalLevel, deverá conseguir realizar uma restauração Autoritativa num nó a correr a versão anterior do Windows Server e restaurar a base de dados e configuração originais do cluster.
Posso usar a atualização no local para cada nó em vez de usar a instalação limpa do sistema operativo ao reformatar a unidade do sistema?
Yes. No passado, recomendámos que efetuassem uma instalação limpa do sistema operativo em cada nó. No entanto, agora pode-se executar uma atualização no local do nó do cluster se ler e resolver cuidadosamente quaisquer mensagens de aviso.
Se estiver a usar a replicação do Hyper-V para uma VM Hyper-V no cluster Hyper-V, a replicação manter-se-á intacta durante e após o processo de Atualização Contínua do Sistema Operativo do Cluster?
Sim, a réplica do Hyper-V mantém-se intacta durante e após o processo de Rolling Upgrade do Cluster OS.
Posso usar o System Center Virtual Machine Manager (VMM) para automatizar o processo de Rolling Upgrade do Cluster OS? Sim, você pode automatizar o processo de Atualização Contínua do SO do Cluster usando o VMM no System Center.

Comentários

Esta página foi útil?

Last updated on 2026-04-15