Migrar um grupo de disponibilidade Always On do SQL Server para a solução VMware do Azure

Artigo
07/27/2024

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

O Microsoft SQL Server (2019 e 2022) foi testado com o Windows Server (2019 e 2022) Data Center edition com as máquinas virtuais implantadas no ambiente local. O Windows Server e o SQL Server são 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

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

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

Outras considerações sobre o tempo de inatividade sã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 com a nuvem do Azure. Embora as migrações do Grupo de Disponibilidade do SQL Server possam ser executadas com o mínimo de tempo de inatividade da solução, é ideal conduzir a migração fora do horário de pico dentro de uma janela de alteração pré-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

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 quórum para manter a coerência do cluster.

É necessário um número ímpar de elementos de votação, que é alcançado por um número ímpar de nós no cluster ou usando uma testemunha. O Witness pode ser configurado de três maneiras 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 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 para seu cluster migrado dependerá do cenário da Solução VMware do Azure, há várias opções a serem consideradas.

Extensão do Datacenter: mantenha a testemunha de compartilhamento de arquivos no local. Suas cargas de trabalho são distribuídas pelo datacenter e pelo Azure. Portanto, a conectividade entre seu datacenter e o Azure 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 ambas as opções, você pode manter a testemunha de compartilhamento de arquivos local durante a migração, caso precise fazer a reversão durante o processo.
- 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 detalhes sobre como configurar e gerenciar o quorum, consulte a documentação do Clustering de Failover. Para obter informações sobre a implantação da testemunha de nuvem no Armazenamento de Blob do Azure, consulte Gerenciar um quorum de cluster para um cluster de failover.

Migrar o grupo de disponibilidade Always On do SQL Server

Acesse seu Grupo de Disponibilidade Always On com o SQL Server Management Studio usando credenciais de administração.
- Selecione sua réplica principal e abra Propriedades do Grupo de Disponibilidade.
- Altere o Modo de Disponibilidade para Confirmação assíncrona somente para a réplica a ser migrada.
- Altere o Modo de Failover para Manual para cada membro do grupo de disponibilidade.
Acesse o vCenter Server local e prossiga para a área HCX.
Em Serviços, selecione Migração>de migração.
- Selecione uma máquina virtual executando a réplica secundária do banco de dados que será migrado.
- Defina o cluster vSphere na nuvem privada remota, que agora 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. 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 vMotion 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 está relacionado à configuração de armazenamento. Verifique novamente se não há controladores SCSI virtuais com a configuração de compartilhamento físico.
- Selecione Ir para iniciar a migração.
Quando a migração estiver concluída, acesse a réplica migrada e verifique a conectividade com o restante dos membros do 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 Preparação para Failover é esperado, pois a réplica está fora de sincronia com a principal durante a migração.
Edite as Propriedades do Grupo de Disponibilidade novamente e defina o Modo de Disponibilidade novamente como Confirmação síncrona.
- A réplica secundária começa a sincronizar todas as alterações feitas na réplica primária durante a migração. Aguarde até que ele apareça no estado Sincronizado.
No Painel do Grupo de Disponibilidade, no SSMS, selecione Iniciar Assistente de Failover.
Selecione a réplica migrada e selecione Avançar.
Conecte-se à réplica na próxima tela com suas credenciais de administrador de banco de dados.
Revise 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 o modo de exibição do Pesquisador de Objetos no SQL Server Management Studio (SSMS), 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.

Nota

Migre uma réplica de cada vez e verifique se todas as alterações são sincronizadas de volta à réplica após cada migração. Não migre todas as réplicas ao mesmo tempo usando a migração em massa HCX.
Depois que a migração de todas as réplicas for concluída, acesse seu 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 Modo de Failover como Automático em todas as réplicas.