Migrar o Grupo de Disponibilidade Always On do Microsoft SQL Server para a Solução VMware no Azure

Artigo
05/06/2024

Neste artigo, você aprenderá a migrar um Grupo de Disponibilidade AlwaysOn do SQL Server para a Solução VMware no Azure. Para o VMware HCX, você pode seguir o procedimento de migração VMware vMotion.

O Microsoft SQL Server (2019 e 2022) foi testado com 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 estão 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

Veja a seguir os pré-requisitos para migrar sua instância do SQL Server para a Solução VMware no Azure.

Revise e registre a configuração de armazenamento e rede de cada nó do cluster.
Mantenha backups de todos os bancos de dados do SQL Server.
Faça backup da máquina virtual ou das máquinas virtuais que hospedam o SQL Server.
Remova a máquina virtual de qualquer grupo e regras de DRS (Distributed Resource Scheduler) do VMware vSphere.
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 HCX, consulte 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.

Outras considerações sobre o tempo de inatividade serão discutidas na próxima seçã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. Embora as migrações do Grupo de Disponibilidade do SQL Server possam ser executadas com tempo de inatividade mínimo da solução, é ideal realizar a migração durante horários fora do pico em uma janela de alteração pré-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

Os Grupos de Disponibilidade Always On do Microsoft SQL Server dependem do Cluster de Failover do Windows Server, que requer um mecanismo de votação de quorum para manter a coerência do cluster.

Um número ímpar de elementos de votação é necessário, o que é alcançado por um número ímpar de nós no cluster ou usando uma testemunha. A testemunha pode ser configurada de três maneiras 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 restante do armazenamento compartilhado do cluster usando o procedimento descrito neste documento.

Se o cluster usar uma testemunha de compartilhamento de arquivos em execução local, o tipo de testemunha do cluster migrado dependerá do cenário da Solução VMware no Azure. Há várias opções a serem consideradas.

Extensão do Datacenter: manter a testemunha de compartilhamento de arquivos localmente. Suas cargas de trabalho são distribuídas entre o datacenter e o Azure. Portanto, a conectividade entre o datacenter e o Azure 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 ambas as opções, você pode manter a testemunha de compartilhamento de arquivos local durante a migração, caso precise reverter durante o processo.
- 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 Azure.
Modernização do aplicativo: para esse caso de uso, a melhor opção é implantar uma Testemunha de Nuvem.

Para obter detalhes sobre como configurar e gerenciar o quorum, consulte a documentação do Clustering de Failover. Para obter informações sobre a implantação de testemunha de nuvem no Armazenamento de Blobs do Azure, consulte Gerenciar um quorum de cluster para um Cluster de Failover.

Migrar o grupo de disponibilidade AlwaysOn do SQL Server

Acesse seu Grupo de Disponibilidade AlwaysOn com o SQL Server Management Studio usando credenciais de administração.
- Selecione sua réplica primária e abra Grupo de disponibilidade Propriedades.
- Altere o Modo de Disponibilidade para Confirmação assíncrona somente para que a réplica seja migrada.
- Altere o Modo de Failover para Manual para cada membro do grupo de disponibilidade.
Acesse o vCenter Server local e vá para a área HCX.
Em Serviços, selecione Migração>Migrar.
- Selecione uma máquina virtual executando a réplica secundária do banco de dados que será migrada.
- Defina o cluster vSphere na nuvem privada remota, que agora 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. 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 vMotion como o Perfil de migração.
- Em Opções Estendidas, 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 está relacionado à configuração de armazenamento. Verifique novamente se não há controladores SCSI virtuais com a configuração de compartilhamento físico.
- Escolha Ir para iniciar a migração.
Depois que a migração for concluída, acesse a réplica migrada e verifique a conectividade com o restante dos membros no grupo de disponibilidade.
No SQL Server Management Studio, abra o Painel do Grupo de Disponibilidade e verifique se a réplica aparece como Online.
- O status de Perda de Dados na coluna Prontidão de Failover é esperado, pois a réplica está fora de sincronia com o primário durante a migração.
Novamente edite as propriedades Grupo de disponibilidade Propriedades e definaModo de disponibilidade de volta para Confirmação síncrona.
- A réplica secundária começa a sincronizar novamente todas as alterações feitas na réplica primária durante a migração. Aguarde até que ela apareça no estado sincronizado.
No Painel do Grupo de Disponibilidade, no SSMS, selecione Assistente para Iniciar Failover.
Selecione a réplica migrada e selecione Avançar.
Conecte-se à réplica na próxima tela com suas credenciais de administrador do DB.
Examine as alterações e selecione Concluir para iniciar a operação de failover.
Monitore o progresso do failover na próxima tela, selecione Fechar quando a operação for concluída.
Atualize a exibição do Pesquisador de Objetos no SSMS (SQL Server Management Studio), verifique se a instância migrada agora é a réplica primária.
Repita as etapas 1 a 6 para o restante das réplicas do grupo de disponibilidade.

Observação

Migre uma réplica de cada vez e verifique se todas as alterações são sincronizadas de volta para a réplica após cada migração. Não migre todas as réplicas ao mesmo tempo usando a Migração em Massa do HCX.
Depois que a migração de todas as réplicas for concluída, acesse o grupo de disponibilidade Always On com o SQL Server Management Studio.
- Abra o Painel e verifique se não há perda de dados em nenhuma das réplicas e se todas estão em um estado sincronizado.
- Edite as Propriedades do grupo de disponibilidade e defina o Modo de Failover como Automático em todas as réplicas.