Partilhar via

Migrar uma instância de cluster de failover Always On do SQL Server para a solução VMware do Azure

  • Artigo

Neste artigo, você aprenderá a migrar uma instância de cluster de failover do SQL Server para a solução VMware do Azure. Atualmente, o serviço Azure VMware Solution não suporta o Modo Vinculado Híbrido VMware para conectar um vCenter Server local a um em execução na Solução VMware do 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 do Azure.

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

O diagrama mostra a arquitetura do SQL Server Failover for Azure VMware Solution.

Nota

Este procedimento requer um desligamento completo do cluster. Como o serviço SQL Server não estará disponível durante a migração, planeje adequadamente o período de tempo de inatividade.

Os Microsoft SQL Servers 2019 e 2022 foram testados com o 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 seguindo as práticas recomendadas e as recomendações da Microsoft e da VMware. A infraestrutura de origem local era o VMware vSphere 7.0 Update 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ó no cluster.
  • Revise 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 de cluster.
  • Remova todas as VMs de nó de cluster de quaisquer grupos e regras do Distributed Resource Scheduler (DRS) dos quais façam parte.
  • O VMware HCX deve ser configurado entre seu datacenter local e a nuvem privada da Solução VMware do Azure que executa as cargas de trabalho migradas. Para obter mais informações sobre como instalar o VMware HCX, consulte a documentação da Solução VMware do Azure.
  • Certifique-se de que todos os segmentos de rede em uso pelo SQL Server e as cargas de trabalho que o usam sejam estendidos para sua nuvem privada da Solução VMware do Azure. Para verificar esta etapa, consulte Configurar a extensão de rede VMware HCX.

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

Com o VMware HCX sobre VPN, devido à sua largura de banda limitada, normalmente é adequado para cargas de trabalho que podem suportar períodos mais longos de inatividade (como ambientes que não são de produção).

Para qualquer uma das seguintes instâncias, a conectividade da Rota Expressa é recomendada para uma migração:

  • Ambientes de produção
  • Cargas de trabalho com grandes tamanhos de banco de dados
  • Cenários em que há necessidade de minimizar o tempo de inatividade, a conectividade da Rota Expressa é 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 com a nuvem do Azure. A migração de instâncias de cluster de failover do SQL Server Always On para a solução VMware do Azure requer um tempo de inatividade total do banco de dados e de todos os nós de cluster, no entanto, você deve planejar a migração a ser executada fora do horário de pico com uma janela de alteração aprovada.

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

Cenário Tempo de inatividade esperado Notas
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 é recomendado confirmar nenhum dado crítico durante ele.
Grupo de Disponibilidade Sempre Ativo do SQL Server Baixo A réplica primária estará sempre disponível durante a migração da primeira réplica secundária e a réplica secundária se tornará a principal 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 usando o VMware HCX Cold Migration. 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:

  • Testemunho de disco
  • Testemunho de partilha de ficheiros
  • Testemunha de cloud

Se o cluster usar testemunha de disco, o disco deverá ser migrado com o armazenamento compartilhado do cluster usando o cluster de failover de migração.

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

  • Extensão do Datacenter: mantenha a testemunha de compartilhamento de arquivos no local. Suas cargas de trabalho são distribuídas pelo datacenter e pela Solução VMware do Azure, portanto, a conectividade entre ambos deve estar sempre disponível. Em qualquer caso, leve em consideração as restrições de largura de banda e planeje de acordo.
  • Saída do datacenter: para esse 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 fazer a reversão.
    • Implante uma nova testemunha de compartilhamento de arquivos em sua nuvem privada da Solução VMware do Azure.
    • Implante uma testemunha de nuvem em execução no Armazenamento de Blob do Azure na mesma região da nuvem privada da Solução VMware do Azure.
  • Recuperação de desastres e continuidade de negócios: para um cenário de recuperação de desastres, a melhor e mais confiável opção é criar uma Testemunha de Nuvem em execução no Armazenamento do Azure.
  • Modernização de aplicativos: para este caso de uso, a melhor opção é implantar um Cloud Witness.

Para obter mais informações sobre configuração e 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 Blob do Azure, consulte Implantar uma testemunha de nuvem para uma documentação de cluster de failover para obter detalhes.

Migrar 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 são suportados com este procedimento.

  1. A partir do desligamento do vSphere Client, 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 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 vSphere Client, edite as configurações do segundo nó do cluster.

    • Remova todos os discos compartilhados da configuração da máquina virtual.
    • Verifique se a caixa de seleção Excluir arquivos do armazenamento de dados não está marcada, 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 de plug-in HCX. Em Serviços, selecione Migração>de migração.

    • Selecione a máquina virtual do segundo nó.
    • Defina o cluster vSphere na nuvem privada remota, ele hospeda a VM ou VMs do SQL Server migradas, como o Contêiner de Computação.
    • Selecione o vSAN Datastore como armazenamento remoto.
    • Selecione uma pasta se quiser colocar as máquinas virtuais em uma pasta específica. Não é obrigatório, mas é recomendado separar as diferentes cargas de trabalho na nuvem privada da Solução VMware do Azure.
    • Mantenha o mesmo formato da fonte.
    • Selecione Migração fria como Perfil de migração.
    • Em Opções Estendidas, selecione Migrar Atributos Personalizados.
    • Verifique se os segmentos de rede local têm o segmento estendido remoto correto no Azure.
    • Selecione Validar e certifique-se de que todas as verificações são concluídas com o status de aprovação. O erro mais comum é aquele relacionado à configuração de armazenamento. Verifique novamente se não há controladores SCSI com configuração de compartilhamento físico.
    • Selecione Ir e a migração será iniciada.

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

  8. Acesse o Azure VMware Solution vSphere Client e edite as primeiras configurações de nó e volte 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 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.
    • Certifique-se de que toda a configuração de armazenamento seja a mesma registrada antes da migração.

  10. Ligue a primeira máquina virtual de nó.

  11. Acesse a primeira VM de nó com o VMware Remote Console.

    • Verifique a configuração da rede da máquina virtual e certifique-se de que ela possa acessar os 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. Ligue a máquina virtual do segundo nó.

  13. Acesse a VM do segundo nó a partir do VMware Remote Console.

    • Verifique se o Windows Server pode acessar o armazenamento.
    • No Gerenciador de Cluster de Failover, verifique se 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 do recurso de cluster do SQL Server. Confirme se todas as bases 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 de cluster migrado.

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

Mais informações