Compartilhar via

Migrar uma Instância de Cluster de Failover Always On do SQL Server para a Solução VMware no Azure

  • Artigo

Neste artigo, você aprenderá a migrar uma instância de cluster de failover do SQL Server para a Solução VMware no Azure. Atualmente, o serviço de Solução VMware no Azure não dá suporte ao Linked Mode híbrido do VMware para conectar um vCenter Server local com um em execução na Solução VMware no Azure. Devido a essa restrição, esse processo requer o uso do VMware HCX para a migração. Para obter mais informações sobre como configurar o HCX, consulte Instalar e ativar o VMware HCX na Solução VMware no Azure.

O VMware HCX não dá suporte à migração de máquinas virtuais com controladores SCSI no modo de compartilhamento físico anexado a uma máquina virtual. No entanto, você pode superar essa limitação executando as etapas mostradas neste procedimento e usando a Migração a frio do VMware HCX para mover as diferentes máquinas virtuais que compõem o cluster.

O diagrama mostra a arquitetura de failover do SQL Server para a Solução VMware no Azure.

Observação

Este procedimento requer um desligamento completo do cluster. Como o serviço do SQL Server ficará indisponível durante a migração, planeje de acordo com o período do tempo de inatividade.

O Microsoft SQL Server 2019 e 2022 foram testados na edição Data Center do Windows Server 2019 e 2022, com as máquinas virtuais implantadas no ambiente local. O Windows Server e o SQL Server foram configurados com as melhores práticas e recomendações da Microsoft e da VMware. A infraestrutura de origem local era o VMware vSphere 7.0 Atualização 3 e o VMware vSAN em execução em servidores Dell PowerEdge e dispositivos Intel Optane P4800X SSD NVMe.

Pré-requisitos

  • Revise e registre a configuração de armazenamento e rede de cada nó do cluster.
  • Examine e registre a configuração do WSFC.
  • Mantenha backups de todos os bancos de dados do SQL Server.
  • Faça backup das máquinas virtuais do cluster.
  • Remova todas as VMs de nó de cluster de qualquer grupo e regra do DRS (Agendador de Recursos Distribuídos) dos quais elas fazem parte.
  • O VMware HCX deve ser configurado entre o datacenter local e a nuvem privada da Solução VMware no Azure que executa as cargas de trabalho migradas. Para obter mais informações sobre como configurar o VMware HCX, confira a documentação da Solução VMware no Azure.
  • Garanta que todos os segmentos de rede em uso pelo SQL Server e pelas cargas de trabalho que o usam sejam estendidos para sua nuvem privada da Solução VMware no Azure. Para verificar essa etapa, confira Configurar a extensão de rede do VMware HCX.

A conectividade do VMware HCX via VPN ou do ExpressRoute pode ser usada como a configuração de rede para a migração.

Normalmente, o VMware HCX via VPN, devido à largura de banda limitada, é adequado para cargas de trabalho que podem sustentar tempos mais longos de inatividade (como ambientes de não produção).

Para qualquer uma das seguintes instâncias, a conectividade do ExpressRoute é recomendada para uma migração:

  • Ambientes de produção
  • Cargas de trabalho com tamanhos de banco de dados grandes
  • Cenários em que há a necessidade de minimizar o tempo de inatividade, a conectividade do ExpressRoute é recomendada para a migração.

Considerações sobre tempo de inatividade

O tempo de inatividade durante uma migração depende do tamanho do banco de dados a ser migrado e da velocidade da conexão de rede privada para a nuvem do Azure. A migração das instâncias de cluster de failover do SQL Server Always On para a Solução VMware no Azure requer um tempo de inatividade completo do banco de dados e de todos os nós de cluster. No entanto, você deve planejar que a migração seja executada durante o horário de pico com uma janela de alteração aprovada.

A tabela a seguir indica o tempo de inatividade estimado para a migração de cada topologia do SQL Server.

Cenário Tempo de inatividade esperado Observações
Instância autônoma do SQL Server Baixo A migração é feita com o VMware vMotion e o banco de dados está disponível durante o tempo de migração, mas não é recomendável confirmar dados críticos durante ele.
Grupo de disponibilidade Always On do SQL Server Baixo A réplica primária sempre estará disponível durante a migração da primeira réplica secundária e a réplica secundária se tornará a primária após o failover inicial para o Azure.
Instância de cluster de failover do Always On do SQL Server Alto Todos os nós do cluster são desligados e migrados por meio da Migração a Frio do VMware HCX. A duração do tempo de inatividade depende do tamanho do banco de dados e da velocidade da rede privada para a nuvem do Azure.

Considerações sobre o quorum do Cluster de Failover do Windows Server

O cluster de failover do Windows Server requer um mecanismo de quorum para manter o cluster.

Use um número ímpar de elementos de votação para alcançar por um número ímpar de nós no cluster ou usando uma testemunha. As testemunhas podem ser configuradas de três formas diferentes:

  • Testemunha de disco
  • Testemunha de compartilhamento de arquivos
  • Testemunha da nuvem

Se o cluster usar a testemunha de Disco, o disco deverá ser migrado com o armazenamento compartilhado do cluster usando o cluster de failover Migrar.

Se o cluster usar uma testemunha de compartilhamento deArquivos em execução local, o tipo de testemunha do cluster migrado dependerá do cenário da Solução VMware no Azure:

  • Extensão do datacenter: manter a testemunha de compartilhamento de arquivos localmente. Suas cargas de trabalho são distribuídas entre o datacenter e a Solução VMware no Azure e, portanto, a conectividade entre ambas deve estar sempre disponível. De qualquer forma, leve em consideração as restrições de largura de banda e planeje adequadamente.
  • Saída do datacenter: para este cenário, há duas opções. Em ambos os casos, você pode manter a testemunha de compartilhamento de arquivos local durante a migração, caso precise reverter.
    • Implante uma nova testemunha de compartilhamento de arquivos em sua nuvem privada da Solução VMware no Azure.
    • Implante uma testemunha de nuvem em execução no Armazenamento de Blobs do Azure na mesma região que a nuvem privada da Solução VMware no Azure.
  • Recuperação de desastres e continuidade dos negócios: para um cenário de recuperação de desastre, a melhor e mais confiável opção é criar uma Testemunha de Nuvem em execução no Armazenamento do Microsoft Azure.
  • Modernização do aplicativo: para esse caso de uso, a melhor opção é implantar uma Testemunha de Nuvem.

Para obter mais informações sobre a configuração e o gerenciamento de quorum, consulte a documentação do clustering de failover. Para obter mais informações sobre como implantar uma testemunha de Nuvem no Armazenamento de Blobs do Azure, consulte a documentação Implantar uma testemunha de Nuvem para um cluster de failover para obter os detalhes.

Migrar um cluster de failover

Para fins de ilustração, neste documento, estamos usando um cluster de dois nós com o Windows Server 2019 Datacenter e o SQL Server 2019 Enterprise. O Windows Server 2022 e o SQL Server 2022 também têm suporte com esse procedimento.

  1. Do desligamento do cliente vSphere, o segundo nó do cluster.

  2. Acesse o primeiro nó do cluster e abra o Gerenciador de Cluster de Failover.

    • Verifique se o segundo nó está no estado Offline e se todos os serviços em cluster e o armazenamento estão sob o controle do primeiro nó. O diagrama mostra a verificação de armazenamento de cluster do Gerenciador de Cluster de Failover do Windows Server.

    • Desligue o cluster.

      O diagrama mostra um cluster de desligamento usando o Gerenciador de Cluster de Failover do Windows Server.

    • Verifique se todos os serviços de cluster foram interrompidos com êxito sem erros.

  3. Desligue o primeiro nó do cluster.

  4. No cliente vSphere, edite as configurações do segundo nó do cluster.

    • Remova todos os discos compartilhados da configuração de máquina virtual.
    • Certifique-se de que a caixa de seleção Excluir arquivos do armazenamento de dados não esteja selecionada, pois ela exclui permanentemente o disco do armazenamento de dados. Se isso acontecer, você precisará recuperar o cluster de um backup anterior.
    • Defina o compartilhamento de barramento SCSI de Físico para Nenhum nos controladores SCSI virtuais usados para o armazenamento compartilhado. Normalmente, esses controladores são do tipo VMware paravirtual.

  5. Edite as configurações da primeira máquina virtual do nó. Defina o compartilhamento de barramento SCSI de Físico para Nenhum nos controladores SCSI.

  6. No cliente vSphere, vá para a área de plug-in do HCX. Em Serviços, selecione Migração>Migrar.

    • Selecione a máquina virtual do segundo nó.
    • Defina o cluster vSphere na nuvem privada remota. Ela hospeda as VMs do SQL Server migradas como o Contêiner de Computação.
    • Selecione o Armazenamento de Dados vSAN como o armazenamento remoto.
    • Selecione uma pasta se quiser colocar as máquinas virtuais em uma pasta específica. Não é obrigatório, mas é recomendável separar as cargas de trabalho diferentes na nuvem privada da Solução VMware no Azure.
    • Mantenha Mesmo formato que a origem.
    • Selecione Migração a frio como Perfil de migração.
    • Em Opçõesestendidas, selecione Migrar atributos personalizados.
    • Verifique se os segmentos de rede locais têm o segmento estendido remoto correto no Azure.
    • Selecione Validar e garanta que todas as verificações sejam concluídas com o status de aprovação. O erro mais comum é o que está relacionado à configuração de armazenamento. Verifique novamente se não há controladores SCSI com configuração de compartilhamento físico.
    • Selecione Ir para iniciar a migração.

  7. Repita o mesmo processo para o primeiro nó.

  8. Acesse o cliente vSphere da Solução VMware no Azure e edite as primeiras configurações de nó e defina de volta para o barramento SCSI físico compartilhando o controlador SCSI ou controladores que gerenciam os discos compartilhados.

  9. Edite as configurações do nó 2 no cliente vSphere.

    • Defina o compartilhamento de barramento SCSI de volta para físico no controlador SCSI que gerencia o armazenamento compartilhado.
    • Adicione os discos compartilhados do cluster ao nó como armazenamento extra. Atribua-os ao segundo controlador SCSI.
    • Verifique se toda a configuração de armazenamento é a mesma registrada antes da migração.

  10. Energia na primeira máquina virtual do nó.

  11. Acesse a primeira VM do nó com o Console Remoto do VMware.

    • Verifique a configuração de rede da máquina virtual e certifique-se de que ela possa alcançar recursos locais e do Azure.

    • Abra o Gerenciador de Cluster de Failover e verifique os serviços de cluster.

      O diagrama mostra um resumo do cluster no Gerenciador de Cluster de Failover.

  12. Energia na máquina virtual do segundo nó.

  13. Acesse a VM do segundo nó do Console Remoto do VMware.

    • Verifique se o Windows Server pode alcançar o armazenamento.
    • Na revisão do Gerenciador de Cluster de Failover, o segundo nó aparece como status Online. O diagrama mostra o status de um nó de cluster no Gerenciador de Cluster de Failover.

  14. Usando o SQL Server Management Studio, conecte-se ao nome da rede de recursos de cluster do SQL Server. Confirme se todos os bancos de dados estão online e acessíveis.

O diagrama mostra uma verificação da conexão do SQL Server Management Studio com o banco de dados de instância do cluster migrado.

Verifique a conectividade com o SQL Server de outros sistemas e aplicativos na sua infraestrutura. Verifique se todos os aplicativos que usam os bancos de dados ainda podem acessá-los.

Mais informações