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

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.

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ós de clusters de quaisquer grupos e regras do Distributed Resource Scheduler (DRS) a que pertençam.
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 através de 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 é necessário minimizar o tempo de inatividade, recomenda-se a conectividade com o 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 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 em Clusters 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 obter um número ímpar de nós no cluster ou usando um observador. As testemunhas podem ser configuradas de três formas diferentes:

Testemunho de disco
Testemunha de partilha de ficheiros
Testemunha de Nuvem

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

Se o cluster usar uma testemunha de compartilhamento de arquivos em execução nas instalações, então 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 partilha de ficheiros 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 gestão de quorum, consulte a documentação de Clusters de Failover. Para obter mais informações sobre como implantar uma testemunha de nuvem no Armazenamento de Blob do Azure, consulte a documentação Implantar uma testemunha de nuvem para um cluster de failover.

Migrar cluster de alta disponibilidade

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.

A partir do desligamento do vSphere Client, o segundo nó do cluster.
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ó.
- Desligar o cluster.
- Verifique se todos os serviços de cluster foram interrompidos com êxito sem erros.
Desligue o primeiro nó do cluster.
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.
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.
No vSphere Client, vá para a secção do plug-in HCX. Em Serviços, selecione Migração>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 a Frio 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.
Repita o mesmo processo para o primeiro nó.
Acesse o Azure VMware Solution vSphere Client e edite as definições do primeiro nó, redefina para o barramento SCSI físico, partilhando o controlador SCSI ou os controladores que gerem os discos partilhados.
Altere 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.
Ligue a máquina virtual do primeiro nó.
Acesse a primeira VM do nó cluster com 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 Gestor de Cluster de Failover e verifique os serviços de cluster.
Ative a máquina virtual do segundo nó.
Acesse a VM do segundo nó a partir do VMware Remote Console.
- Verifique se o Windows Server pode acessar o armazenamento.
- No Gerenciador de Clusters de Failover, verifique se o segundo nó aparece com o estado Online.
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.

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

Feedback

Esta página foi útil?

Last updated on 2025-01-08