Atualização sem interrupção do sistema operacional do cluster

A atualização sem interrupção do SO do cluster permite que um administrador atualize o sistema operacional de nós de cluster das cargas de trabalho do Hyper-V ou do Servidor de Arquivos de Escalabilidade Horizontal sem a necessidade de interrompê-los. Usando esse recurso, as penalidades de tempo de inatividade em SLAs (Contratos de Nível de Serviço) podem ser evitadas.

A atualização sem interrupção do SO do cluster oferece os seguintes benefícios:

• Os clusters de failover que executam cargas de trabalho de máquina virtual do Hyper-V e SOFS (Servidor de Arquivos de Escalabilidade Horizontal) podem ser atualizados de uma versão do Windows Server, a partir do Windows Server 2012 R2, para uma versão mais recente do Windows Server. Por exemplo, você pode atualizar o Windows Server 2016 (em execução em todos os nós de cluster do cluster) para o Windows Server 2019 (em execução em todos os nós no cluster) sem tempo de inatividade.

• Isso não requer hardware adicional. Em clusters pequenos, você pode adicionar outros nós de cluster temporariamente para melhorar a disponibilidade do cluster durante o processo de atualização sem interrupção do SO do cluster.

• O cluster não precisa ser interrompido nem reiniciado.

• Um novo cluster não é necessário. O cluster existente está atualizado. Além disso, os objetos de cluster existentes armazenados no Active Directory são usados.

• O processo de atualização é reversível até a etapa final, quando todos os nós de cluster estão executando a versão mais recente do Windows Server e o cmdlet do PowerShell Update-ClusterFunctionalLevel é executado.

• O cluster permite operações de aplicação de patch e manutenção durante a execução no modo de SO misto.

• Isso viabiliza a automação por meio do PowerShell e do WMI.

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

  Get-Cluster | Select ClusterFunctionalLevel
  

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

  Valor	Nível funcional
  8	Windows Server 2012 R2
  9	Windows Server 2016
  10	Windows Server 2019

Este guia descreve as várias fases do processo de atualização sem interrupção do SO do cluster, as etapas de instalação, as limitações de recursos e as perguntas frequentes e aplicáveis aos seguintes cenários de atualização sem interrupção do SO do cluster no Windows Server:

• Clusters do Hyper-V
• Clusters do Servidor de Arquivos de Escalabilidade Horizontal

Não há suporte para o seguinte cenário:

• Atualização sem interrupção do SO do cluster para clusters convidados usando o disco rígido virtual (arquivo .vhdx) como armazenamento compartilhado.

A atualização sem interrupção do SO do cluster é totalmente compatível com o SCVMM (System Center Virtual Machine Manager). Se você estiver usando o SCVMM, confira Executar uma atualização sem interrupção de um cluster de host do Hyper-V para o Windows Server 2016 no VMM para obter diretrizes sobre como atualizar os clusters e automatizar as etapas descritas neste documento.

Requisitos

Conclua os seguintes requisitos antes de iniciar o processo de atualização sem interrupção do SO do cluster:

• Comece com um Cluster de Failover executando o Windows Server 2012 R2 ou mais recente. Você pode atualizar para a próxima versão, por exemplo, do Windows Server 2016 para o Windows Server 2019.
• Verifique se os nós do Hyper-V têm CPUs compatíveis com a SLAT (Tabela de Endereços de Segundo Nível) usando um dos métodos a seguir: – Examine o artigo Você é Compatível com a SLAT? Dica 01 do SDK do WP8, que descreve dois métodos para verificar se uma CPU aceita SLATs – Baixe a ferramenta Coreinfo v3.31 para determinar se uma CPU aceita SLAT.

Estados de transição de cluster durante a atualização sem interrupção do SO do cluster

Esta seção descreve os vários estados de transição do cluster do Windows Server que está sendo atualizado para a próxima versão do Windows Server usando a atualização sem interrupção do SO do cluster.

Para manter as cargas de trabalho do cluster em execução durante o processo de atualização sem interrupção do SO do cluster, mover uma carga de trabalho do cluster de um nó que executa uma versão mais antiga do Windows Server para um nó que executa uma versão mais recente do Windows Server funciona usando um modo de compatibilidade. Esse modo de compatibilidade faz com que os nós que executam a versão mais recente do Windows Server sejam exibidos como se estivessem executando a mesma versão mais antiga do Windows Server. Por exemplo, ao atualizar um cluster do Windows Server 2016 para o Windows Server 2019, os nós do Windows Server 2019 operam em um modo de compatibilidade do Windows Server 2016 como medida temporária. Um novo modo de cluster conceitual, chamado modo de SO misto, permite que nós de versões diferentes existam no mesmo cluster (confira a Figura 1).

Figura 1: transições de estado do sistema operacional do cluster

Um cluster do Windows Server entra no modo de SO misto quando um nó que executa uma versão mais recente do Windows Server é adicionado ao cluster. O processo é totalmente reversível neste ponto – os nós mais recentes do Windows Server podem ser removidos do cluster e os nós que executam a versão existente do Windows Server podem ser adicionados ao cluster nesse modo. O processo não é reversível depois que o cmdlet do PowerShell Update-ClusterFunctionalLevel é executado no cluster. Para que esse cmdlet tenha êxito, todos os nós devem executar a versão mais recente do Windows Server e todos os nós devem estar online.

Estados de transição de um cluster de quatro nós ao executar a atualização sem interrupção do SO

Esta seção ilustra e descreve os quatro estágios diferentes de um cluster com armazenamento compartilhado, cujos nós são atualizados do Windows Server 2012 R2 para o Windows Server 2016. O processo é o mesmo para as versões posteriores do Windows Server.

O "Estágio 1" é o estado inicial – começamos com um cluster do Windows Server 2012 R2.

Figura 2: Estado Inicial: Cluster de Failover do Windows Server 2012 R2 (Estágio 1)

No "Estágio 2", dois nós foram pausados, esvaziados, removidos, reformatados e instalados com o Windows Server 2016.

Figura 3: Estado Intermediário: modo de SO misto: cluster de failover do Windows Server 2012 R2 e do Windows Server 2016 (Estágio 2)

No "Estágio 3", todos os nós no cluster foram atualizados para o Windows Server 2016 e o cluster está pronto para ser atualizado com o cmdlet Update-ClusterFunctionalLevel do PowerShell.

Figura 4: Estado Intermediário: todos os nós atualizados para o Windows Server 2016, prontos para Update-ClusterFunctionalLevel (Estágio 3)

Depois que o cmdlet Update-ClusterFunctionalLevel é executado, o cluster entra no "Estágio 4", em que os novos recursos de cluster do Windows Server 2016 podem ser usados.

Figura 5: Estado Final: Cluster de Failover do Windows Server 2016 (Estágio 4)

Processo de atualização sem interrupção do SO do cluster

Esta seção descreve o fluxo de trabalho para executar a atualização sem interrupção do SO do cluster.

Figura 6: fluxo de trabalho do processo de atualização sem interrupção do SO do cluster

A atualização sem interrupção do SO do cluster inclui as etapas abaixo para atualizar do Windows Server 2012 R2 para Windows Server 2016. No entanto, o processo é o mesmo para as versões posteriores do Windows Server.

1. Prepare o cluster para a atualização do sistema operacional da seguinte maneira:

   1. A atualização sem interrupção do SO do cluster exige a remoção de um nó por vez do cluster. Verifique se você tem capacidade suficiente no cluster para manter os SLAs de HA, quando um dos nós de cluster for removido do cluster para uma atualização do sistema operacional. Em outras palavras, você precisa da funcionalidade de fazer failover nas cargas de trabalho para outro nó, quando um nó é removido do cluster durante o processo de atualização sem interrupção do SO do cluster? O cluster tem a capacidade de executar as cargas de trabalho necessárias, quando um nó é removido do cluster para a atualização sem interrupção do SO do cluster?

   2. Para cargas de trabalho do Hyper-V, verifique se todos os hosts do Hyper-V do Windows Server aceitam a CPU para SLAT (Tabela de Endereços de Segundo Nível). Somente os computadores compatíveis com a SLAT podem usar a função do Hyper-V no Windows Server 2016 e mais recentes.

   3. Verifique se todos os backups de carga de trabalho foram concluídos e faça o backup do cluster. Interrompa as operações de backup ao adicionar nós ao cluster.

   4. Verifique se todos os nós de cluster estão online/em pleno funcionamento usando o cmdlet Get-ClusterNode (confira a Figura 7).

      Figura 7: como determinar o status do nó usando o cmdlet Get-ClusterNode

   5. Se você estiver executando a CAU (Atualização com Suporte a Cluster), verifique se a CAU está em execução no momento usando a interface do usuário de Atualização com Suporte a Cluster ou o cmdlet Get-CauRun (confira a Figura 8). Pare a CAU usando o cmdlet Disable-CauClusterRole (confira a Figura 9) para impedir que os nós sejam pausados e esvaziados pela CAU durante o processo de atualização sem interrupção do SO do cluster.

      Figura 8: como usar o cmdlet Get-CauRun para determinar se a Atualização com Suporte a Cluster está em execução no cluster

      Figura 9: como desabilitar a função de Atualização com Suporte a Cluster usando o cmdlet Disable-CauClusterRole

2. Para cada nó no cluster, faça o seguinte:

   1. Usando a interface do usuário do Gerenciador de Clusters, selecione um nó e use a opção de menu Pausar | Esvaziar para esvaziar o nó (confira a Figura 10) ou use o cmdlet Suspend-ClusterNode (confira a Figura 11).

      Figura 10: como esvaziar funções de um nó usando o Gerenciador de Clusters de Failover

      Figura 11: como esvaziar funções de um nó usando o cmdlet Suspend-ClusterNode

   2. Usando a interface do usuário do Gerenciador de Clusters, Remova o nó pausado do cluster ou use o cmdlet Remove-ClusterNode.

      Figura 12: remover um nó do cluster usando o cmdlet Remove-ClusterNode

   3. Reformate a unidade do sistema e execute uma "instalação limpa do sistema operacional" do Windows Server 2016 no nó usando a opção de instalação Personalizar: instalar somente o Windows (avançado) (confira a Figura 13) no setup.exe. Evite selecionar a opção Atualizar: instalar o Windows e manter arquivos, configurações e aplicativos, pois a atualização sem interrupção do SO do cluster não incentiva a atualização in-loco.

      Figura 13: opções de instalação disponíveis para Windows Server 2016

   4. Adicione o nó ao domínio apropriado do Active Directory.

   5. Adicione os usuários apropriados ao grupo de Administradores.

   6. Usando a interface do usuário do Gerenciador do Servidor ou o cmdlet do PowerShell Install-WindowsFeature, instale as funções de servidor necessárias, como o Hyper-V.

      Install-WindowsFeature -Name Hyper-V
      

   7. Usando a interface do usuário do Gerenciador do Servidor ou o cmdlet do PowerShell Install-WindowsFeature, instale o recurso Clustering de Failover.

      Install-WindowsFeature -Name Failover-Clustering
      

   8. Instale todos os recursos adicionais necessários para as cargas de trabalho do cluster.

   9. Verifique as configurações de conectividade de rede e armazenamento usando a interface do usuário do Gerenciador de Clusters de Failover.

   10. Se o Firewall do Windows for usado, verifique se as configurações do Firewall estão corretas para o cluster. Por exemplo, os clusters habilitados para CAU (Atualização com Suporte a Cluster) podem exigir a configuração do Firewall.

   11. Para cargas de trabalho do Hyper-V, use a interface do usuário do Gerenciador de Hyper-V para iniciar a caixa de diálogo Gerenciador de Comutadores Virtuais (confira a Figura 14).

       Verifique se o nome dos Comutadores Virtuais usados são idênticos para todos os nós de host do Hyper-V no cluster.

       Figura 14: Gerenciador de Comutadores Virtuais

   12. Em um nó do Windows Server 2016 (não use um nó do Windows Server 2012 R2), use o Gerenciador de Clusters de Failover (confira a Figura 15) para se conectar ao cluster.

       Figura 15: como adicionar um nó ao cluster usando o Gerenciador de Clusters de Failover

   13. Use a interface do usuário do Gerenciador de Clusters de Failover ou o cmdlet Add-ClusterNode (confira a Figura 16) para adicionar o nó ao cluster.

       Figura 16: como adicionar um nó ao cluster usando o cmdlet Add-ClusterNode

       Observação

       Quando o primeiro nó do Windows Server 2016 ingressa no cluster, o cluster entra no modo de "SO Misto" e os recursos principais do cluster são movidos para o nó do Windows Server 2016. Um cluster de modo de "SO misto" é um cluster totalmente funcional em que os novos nós são executados em um modo de compatibilidade com os nós antigos. O modo de "SO misto" é um modo transitório para o cluster. Não se destina a ser permanente e espera-se que os clientes atualizem todos os nós do cluster em quatro semanas.

   14. Depois que o nó do Windows Server 2016 for adicionado ao cluster, você poderá (opcionalmente) mover parte da carga de trabalho do cluster para o nó recém-adicionado, para reequilibrar a carga de trabalho no cluster da seguinte maneira:

       Figura 17: como mover uma carga de trabalho do cluster (função de VM do cluster) usando o cmdlet Move-ClusterVirtualMachineRole

       1. Use a Migração Dinâmica do Gerenciador de Clusters de Failover para máquinas virtuais ou o cmdlet Move-ClusterVirtualMachineRole (confira a Figura 17) para executar uma migração dinâmica das máquinas virtuais.

          Move-ClusterVirtualMachineRole -Name VM1 -Node robhind-host3
          

       2. Use Mover no Gerenciador de Clusters de Failover ou o cmdlet Move-ClusterGroup para outras cargas de trabalho do cluster.

3. Quando cada nó tiver sido atualizado para o Windows Server 2016 e adicionado novamente ao cluster ou quando os nós remanescentes dos Windows Server 2012 R2 forem removidos, faça o seguinte:

   Importante

   • Depois de atualizar o nível funcional do cluster, você não poderá voltar para o nível funcional do Windows Server 2012 R2 e os nós do Windows Server 2012 R2 não poderão ser adicionados ao cluster.
   • Até que o cmdlet Update-ClusterFunctionalLevel seja executado, o processo será totalmente reversível, os nós do Windows Server 2012 R2 poderão ser adicionados a esse cluster e os nós do Windows Server 2016 poderão ser removidos.
   • Algumas operações de cluster, como o esvaziamento de nós, podem levar um nó a ficar isolado por um curto período. Esse comportamento pode ocorrer quando a operação Update-ClusterFunctionalLevel não foi executada.
   • Depois que o cmdlet Update-ClusterFunctionalLevel for executado, novos recursos estarão disponíveis.

   1. Usando a interface do usuário do Gerenciador de Clusters de Failover ou o cmdlet Get-ClusterGroup, verifique se todas as funções de cluster estão em execução no cluster como esperado. No exemplo a seguir, o Armazenamento Disponível não está sendo usado, em vez disso, o CSV é usado. Portanto, o Armazenamento Disponível exibe o status Offline (confira a Figura 18).

      Figura 18: como verificar se todos os grupos de cluster (funções de cluster) estão em execução usando o cmdlet Get-ClusterGroup

   2. Verifique se todos os nós de cluster estão online e em execução usando o cmdlet Get-ClusterNode.

   3. Execute o cmdlet Update-ClusterFunctionalLevel – nenhum erro deve ser retornado (confira a Figura 19).

      Figura 19: como atualizar o nível funcional de um cluster usando o PowerShell

   4. Depois que o cmdlet Update-ClusterFunctionalLevel for executado, novos recursos estarão disponíveis.

4. Retome as atualizações e os backups normais do cluster:

   1. Se você estava executando a CAU anteriormente, reinicie-a usando a interface do usuário da CAU ou use o cmdlet Enable-CauClusterRole (confira a Figura 20).

      Figure 20: habilitar a função de Atualização com Suporte a Cluster usando o cmdlet Enable-CauClusterRole

   2. Retome as operações de backup.

5. Habilite e use os recursos do Windows Server 2016 nas Máquinas Virtuais do Hyper-V.

   1. Depois que o cluster tiver sido atualizado para o nível funcional do Windows Server 2016, muitas cargas de trabalho, como as VMs do Hyper-V, terão novos recursos. Para obter uma lista de novos recursos do Hyper-V. Confira Migrar e atualizar máquinas virtuais

   2. Em cada nó de host do Hyper-V no cluster, use o cmdlet Get-VMHostSupportedVersion para exibir as versões de configuração da VM do Hyper-V compatíveis com o host.

      Figura 21: como exibir as versões de configuração da VM do Hyper-V com suporte do host

   3. Em cada nó de host do Hyper-V no cluster, as versões de configuração da VM do Hyper-V podem ser atualizadas agendando uma breve janela de manutenção com os usuários, fazendo backup, desativando máquinas virtuais e executando o cmdlet Update-VMVersion (confira a Figura 22). Isso atualizará a versão da máquina virtual e habilitará novos recursos do Hyper-V, eliminando a necessidade de atualizações futuras do IC (Componente de Integração) do Hyper-V. Esse cmdlet pode ser executado no nó do Hyper-V que está hospedando a VM ou o parâmetro -ComputerName pode ser usado para atualizar a versão da VM remotamente. Neste exemplo, aqui atualizamos a versão de configuração da VM1 de 5.0 para 7.0, para aproveitar muitos novos recursos do Hyper-V associados a essa versão de configuração de VM, como Pontos de Verificação de Produção (Backups Consistentes de Aplicativo) e arquivo de configuração de VM binária.

      Figura 22: como atualizar uma versão da VM usando o cmdlet Update-VMVersion PowerShell

6. Os pools de armazenamento podem ser atualizados usando o cmdlet do PowerShell Update-StoragePool. Essa é uma operação online.

Embora nosso objetivo seja os cenários de Nuvem Privada, especificamente os clusters do Hyper-V e do Servidor de Arquivos de Escalabilidade Horizontal, que podem ser atualizados sem tempo de inatividade, o processo de Atualização sem Interrupção do SO do cluster pode ser usado para qualquer função de cluster.

Restrições/limitações

• Esse recurso funciona apenas para as versões do Windows Server a partir do Windows Server 2012 R2. Esse recurso não pode atualizar as versões anteriores do Windows Server, como Windows Server 2008, Windows Server 2008 R2 ou Windows Server 2012.
• Cada nó do Windows Server 2016 deve ser reformatado/somente novas instalações. Os tipos de instalação in-loco ou de atualização são desencorajados.
• Um nó que executa a versão mais recente do Windows Server deve ser usado para adicionar os novos nós ao cluster.
• Ao gerenciar um cluster de modo de SO misto, sempre execute as tarefas de gerenciamento de um nó de nível superior que está executando o Windows Server 2016. Os nós do Windows Server de nível inferior não podem usar as ferramentas de gerenciamento ou interface do usuário nas versões mais recentes do Windows Server.
• Incentivamos os clientes a passar pelo processo de atualização de cluster rapidamente, pois alguns recursos de cluster não são otimizados para o modo de SO misto.
• Evite criar ou redimensionar o armazenamento nos nós mais recentes do Windows Server, enquanto o cluster estiver em execução no modo de SO misto devido a possíveis incompatibilidades no failover de um nó mais recente do Windows Server para os nós de nível inferior do Windows Server.

Perguntas frequentes

Por quanto tempo o cluster de failover pode ser executado no modo de SO misto? Incentivamos os clientes a concluir a atualização em quatro semanas. Atualizamos os clusters do Hyper-V e do Servidor de Arquivos de Escalabilidade Horizontal sem tempo de inatividade em menos de quatro horas no total.

Você vai portar esse recurso novamente para o Windows Server 2012, Windows Server 2008 R2 ou Windows Server 2008? Não planejamos portar esse recurso novamente para as versões anteriores. A atualização sem interrupção do SO do cluster é nossa visão para atualizar os clusters do Windows Server.

Os nós que executam a versão mais antiga do Windows Server precisam ter todas as atualizações de software instaladas, para iniciar o processo de atualização sem interrupção do SO do cluster? Sim, antes de iniciar o processo de atualização sem interrupção do SO do cluster, verifique se todos os nós de cluster receberam as atualizações de software mais recentes.

Posso executar o cmdlet Update-ClusterFunctionalLevel enquanto os nós estão Desativados ou Em Pausa? Não. Todos os nós de cluster devem estar ativados e em associação ativa para que o cmdlet Update-ClusterFunctionalLevel funcione.

A atualização sem interrupção do SO do cluster funciona para qualquer carga de trabalho do cluster? Funciona para SQL Server? Sim, a atualização sem interrupção do SO do cluster funciona para qualquer carga de trabalho do cluster. No entanto, não há tempo de inatividade apenas para clusters do Hyper-V e do Servidor de Arquivos de Escalabilidade Horizontal. A maioria das outras cargas de trabalho incorre em algum tempo de inatividade (normalmente alguns minutos), quando elas fazem failover, e o failover é necessário pelo menos uma vez durante o processo de atualização sem interrupção do SO do cluster.

Posso automatizar esse processo usando o PowerShell? Sim, criamos a atualização sem interrupção do SO do cluster para ser automatizada usando o PowerShell.

Para um cluster grande que tem capacidade de failover extra, posso atualizar vários nós simultaneamente? Sim. Quando um nó for removido do cluster para atualizar o SO, o cluster terá um nó a menos para failover. Portanto, terá uma capacidade de failover reduzida. Para clusters grandes com capacidade suficiente de carga de trabalho e failover, vários nós podem ser atualizados simultaneamente. Você pode adicionar temporariamente os nós de cluster ao cluster para fornecer uma carga de trabalho aprimorada e a capacidade de failover durante o processo de atualização sem interrupção do SO do cluster.

E se eu descobrir um problema no meu cluster depois que o Update-ClusterFunctionalLevel foi executado? Se você fez o backup do banco de dados do cluster com um backup de Estado do Sistema, antes de executar o Update-ClusterFunctionalLevel, deve ser possível executar uma restauração autoritativa em um nó que executa a versão anterior do Windows Server e restaurar o banco de dados e a configuração do cluster original.

Posso usar a atualização in-loco para cada nó, em vez de usar a instalação do SO limpo, reformatando a unidade do sistema? Não incentivamos o uso da atualização in-loco do Windows Server, mas estamos cientes de que ela funciona em alguns casos nos quais os drivers padrão são usados. Leia cuidadosamente todas as mensagens de aviso exibidas durante a atualização in-loco de um nó de cluster.

Se eu estiver usando a replicação do Hyper-V para uma VM do Hyper-V no meu cluster do Hyper-V, a replicação permanecerá intacta durante e após o processo de atualização sem interrupção do SO do cluster? Sim, a réplica do Hyper-V permanece intacta durante e após o processo de atualização sem interrupção do SO do cluster.

Posso usar o SCVMM (System Center Virtual Machine Manager) para automatizar o processo de atualização sem interrupção do SO do cluster? Sim, você pode automatizar o processo de atualização sem interrupção do SO do cluster usando o VMM no System Center.