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

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 Solução VMware no Azure não oferece suporte ao Modo Vinculado Híbrido da VMware para conectar um vCenter Server local a outro em execução no 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 SQL Server está indisponível durante a migração, planeje de acordo com o período de tempo de inatividade.

Microsoft SQL Servers 2019 e 2022 foram testados com Windows Servers 2019 e 2022, data center edition, 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 dos nós do cluster de todos os grupos e regras do DRS (Agendador de Recursos Distribuídos) dos quais façam parte.
  • Configure o VMware HCX entre o datacenter local e o Solução VMware no Azure nuvem privada 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.
  • Verifique se todos os segmentos de rede em uso por SQL Server e cargas de trabalho usando-os são estendidos para sua nuvem privada 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
  • Em cenários nos quais é necessário minimizar o tempo de inatividade, recomenda-se a conectividade do ExpressRoute 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 Always On do SQL Server para a Solução VMware no Azure requer indisponibilidade total do banco de dados e de todos os nós do cluster; no entanto, você deve planejar a execução da migração para horários de menor uso, 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 usando o VMware vMotion. 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 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, obtido por meio de um número ímpar de nós no cluster ou pelo uso de 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 junto com o armazenamento compartilhado do cluster usando o Migrate fail over cluster.

Se o cluster usar uma testemunha de compartilhamento de arquivos executada no ambiente local, o tipo de testemunha para o cluster migrado dependerá do cenário do Solução VMware no Azure:

  • Extensão de data center: Mantenha a testemunha de compartilhamento de arquivos no local. 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 arquivo no local durante a migração, caso seja necessário fazer uma reversão.
    • Implante uma nova testemunha de compartilhamento de arquivos em sua nuvem privada da Solução VMware no Azure.
    • Implante um Cloud Witness hospedado no Armazenamento de Blobs do Azure na mesma região que a nuvem privada do 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 de Cluster 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 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 e armazenamento clusterizados estão sob o controle do primeiro nó. O diagrama mostra a verificação do armazenamento do cluster no Gerenciador de Cluster de Failover do Windows Server.

    • Desligue o cluster.

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

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

  3. Desligue o primeiro nó do cluster.

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

    • Remova todos os discos compartilhados da configuração de máquina virtual.
    • Verifique se a caixa de seleção Excluir arquivos do armazenamento de dados não está selecionada, pois 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 máquina virtual do primeiro nó. Defina o compartilhamento de barramento SCSI de Físico para Nenhum nos controladores SCSI.

  6. No vSphere Client, vá para a área do 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 on-premises têm o segmento remoto estendido correto no Azure.
    • Selecione Validar e verifique se todas as verificações foram concluídas com o status de aprovação. O erro mais comum é o que está relacionado à configuração de armazenamento. Verifique 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 configurações do primeiro nó e redefina o compartilhamento de barramento SCSI como físico no controlador SCSI ou nos controladores SCSI que gerenciam os discos compartilhados.

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

    • 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 a configuração de armazenamento é a mesma registrada antes da migração.

  10. Ligue a máquina virtual do primeiro 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ó a partir do Console Remoto da VMware.

    • Verifique se o Windows Server pode acessar o armazenamento.
    • No Gerenciador de Cluster de Failover, verifique se o status do segundo nó é exibido como 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 o banco de dados ou os bancos de dados ainda podem acessá-los.

Mais informações

  • Last updated on