Arquitetura de recuperação de desastres VMware para Azure - Clássico
Este artigo descreve a arquitetura e os processos usados quando você implanta a replicação, o failover e a recuperação de recuperação de desastres de máquinas virtuais (VMs) VMware entre um site VMware local e o Azure usando o serviço Azure Site Recovery - Classic.
Para obter detalhes sobre a arquitetura modernizada, consulte este artigo
Componentes da arquitetura
A tabela e o gráfico a seguir fornecem uma exibição de alto nível dos componentes usados para a recuperação de desastres de VMs/máquinas físicas VMware para o Azure.
| Componente | Requisito | Detalhes |
|---|---|---|
| Azure | Uma assinatura do Azure, conta de Armazenamento do Azure para cache, Managed Disk e rede do Azure. | Os dados replicados de VMs locais são armazenados no armazenamento do Azure. As VMs do Azure são criadas com os dados replicados quando você executa um failover do local para o Azure. As VMs do Azure ligam-se à rede virtual do Azure quando são criadas. |
| Máquina do servidor de configuração | Uma única máquina local. Recomendamos que você o execute como uma VM VMware que pode ser implantada a partir de um modelo OVF baixado. A máquina executa todos os componentes locais do Site Recovery, que incluem o servidor de configuração, o servidor de processo e o servidor de destino mestre. |
Servidor de configuração: coordena as comunicações entre o local e o Azure e gerencia a replicação de dados. Servidor de processo: instalado por padrão no servidor de configuração. Recebe dados de replicação; otimiza-o com cache, compressão e encriptação; e envia-o para o Armazenamento do Azure. O servidor de processo também instala o Azure Site Recovery Mobility Service nas VMs que pretende replicar e realiza a descoberta automática das máquinas no local. À medida que sua implantação cresce, você pode adicionar servidores de processo adicionais e separados para lidar com volumes maiores de tráfego de replicação. Servidor de destino mestre: instalado por padrão no servidor de configuração. Ele lida com dados de replicação durante o failback do Azure. Para implantações grandes, você pode adicionar um servidor de destino mestre separado adicional para failback. |
| Servidores de VMware | As VMs VMware são hospedadas em servidores vSphere ESXi locais. Recomendamos um servidor vCenter para gerenciar os hosts. | Durante a implantação do Site Recovery, você adiciona servidores VMware ao cofre dos Serviços de Recuperação. |
| Máquinas replicadas | O Mobility Service é instalado em cada VM VMware replicada. | Recomendamos que você permita a instalação automática a partir do servidor de processo. Como alternativa, você pode instalar o serviço manualmente ou usar um método de implantação automatizado, como o Configuration Manager. |
Configurar a conectividade de rede de saída
Para que a Recuperação de Site funcione conforme o esperado, você precisa modificar a conectividade de rede de saída para permitir que seu ambiente seja replicado.
Nota
A recuperação de site de máquinas VMware/Physical usando a arquitetura clássica não suporta o uso de um proxy de autenticação para controlar a conectividade de rede. O mesmo é suportado ao usar o architecutre modernizado.
Conectividade de saída para URLs
Se você estiver usando um proxy de firewall baseado em URL para controlar a conectividade de saída, permita o acesso a estas URLs:
| Nome | Comerciais | Administração Pública | Descrição |
|---|---|---|---|
| Armazenamento | *.blob.core.windows.net |
*.blob.core.usgovcloudapi.net |
Permite que os dados sejam escritos da VM para a conta de armazenamento em cache na região de origem. |
| Microsoft Entra ID | login.microsoftonline.com |
login.microsoftonline.us |
Fornece autorização e autenticação para os URLs do serviço Site Recovery. |
| Replicação | *.hypervrecoverymanager.windowsazure.com |
*.hypervrecoverymanager.windowsazure.us |
Permite que a VM comunique com o serviço Site Recovery. |
| Service Bus | *.servicebus.windows.net |
*.servicebus.usgovcloudapi.net |
Permite que a VM escreva dados de monitorização e diagnóstico do Site Recovery. |
Para obter uma lista exaustiva de URLs a serem filtradas para comunicação entre a infraestrutura local do Azure Site Recovery e os serviços do Azure, consulte a seção de requisitos de rede no artigo de pré-requisitos.
Processo de replicação
Quando você habilita a replicação para uma VM, a replicação inicial para o armazenamento do Azure começa, usando a política de replicação especificada. Tenha em atenção o seguinte:
- Para VMs VMware, a replicação é em nível de bloco, quase contínua, usando o agente de serviço de mobilidade em execução na VM.
- Todas as configurações de diretiva de replicação são aplicadas:
- Limite de RPO. Essa configuração não afeta a replicação. Ajuda na monitorização. Um evento é gerado e, opcionalmente, um e-mail enviado, se o RPO atual exceder o limite especificado por você.
- Retenção do ponto de recuperação. Esta configuração especifica até onde você deseja ir quando ocorre uma interrupção. A retenção máxima é de 15 dias no disco gerenciado.
- Snapshots consistentes com aplicativos. O instantâneo consistente com o aplicativo pode ser tirado a cada 1 a 12 horas, dependendo das necessidades do seu aplicativo. Os instantâneos são instantâneos de blob padrão do Azure. O agente de mobilidade em execução em uma VM solicita um instantâneo VSS de acordo com essa configuração e marca esse point-in-time como um ponto consistente do aplicativo no fluxo de replicação.
Nota
Um período de retenção de ponto de recuperação alto pode ter uma implicação no custo de armazenamento, uma vez que mais pontos de recuperação podem precisar ser salvos.
O tráfego é replicado para pontos de extremidade públicos de armazenamento do Azure pela Internet. Como alternativa, você pode usar o Azure ExpressRoute com o emparelhamento da Microsoft. Não há suporte para a replicação de tráfego em uma VPN (rede virtual privada) site a site de um site local para o Azure.
A operação de replicação inicial garante que todos os dados na máquina no momento da habilitação da replicação sejam enviados para o Azure. Após a conclusão da replicação inicial, a replicação das alterações delta para o Azure é iniciada. As alterações controladas de uma máquina são enviadas para o servidor de processo.
A comunicação acontece da seguinte forma:
- As VMs se comunicam com o servidor de configuração local na porta de entrada HTTPS 443, para gerenciamento de replicação.
- O servidor de configuração orquestra a replicação com o Azure pela porta de saída HTTPS 443.
- As VMs enviam dados de replicação para o servidor de processo (em execução na máquina do servidor de configuração) na porta de entrada HTTPS 9443. Esta porta pode ser modificada.
- O servidor de processo recebe dados de replicação, otimiza-os, encripta-os e envia-os para o armazenamento do Azure através da porta de saída 443.
Os logs de dados de replicação são exibidos primeiro em uma conta de armazenamento em cache no Azure. Esses logs são processados e os dados são armazenados em um Disco Gerenciado do Azure (chamado de disco semente do Azure Site Recovery). Os pontos de recuperação são criados neste disco.
Processo de ressincronização
- Às vezes, durante a replicação inicial ou durante a transferência de alterações delta, pode haver problemas de conectividade de rede entre a máquina de origem para o servidor de processamento ou entre o servidor de processo para o Azure. Qualquer um deles pode levar a falhas na transferência de dados para o Azure momentaneamente.
- Para evitar problemas de integridade de dados e minimizar os custos de transferência de dados, o Site Recovery marca uma máquina para ressincronização.
- Uma máquina também pode ser marcada para ressincronização em situações como a seguir para manter a consistência entre a máquina de origem e os dados armazenados no Azure
- Se uma máquina for submetida a desligamento forçado
- Se uma máquina sofrer alterações de configuração, como redimensionamento de disco (modificando o tamanho do disco de 2 TB para 4 TB)
- A ressincronização envia apenas dados delta para o Azure. Transferência de dados entre o local e o Azure minimizada pela computação de somas de verificação de dados entre a máquina de origem e os dados armazenados no Azure.
- Por padrão, a ressincronização é agendada para ser executada automaticamente fora do horário comercial. Se você não quiser esperar pela ressincronização padrão fora do horário de expediente, poderá ressincronizar uma VM manualmente. Para fazer isso, vá para o portal do Azure, selecione a VM >Resynchronize.
- Se a ressincronização padrão falhar fora do horário de expediente e uma intervenção manual for necessária, um erro será gerado na máquina específica no portal do Azure. Você pode resolver o erro e acionar a ressincronização manualmente.
- Após a conclusão da ressincronização, a replicação das alterações delta será retomada.
Gerenciando políticas de replicação
- Você pode personalizar as configurações das políticas de replicação à medida que habilita a replicação.
- Você pode criar uma política de replicação a qualquer momento e, em seguida, aplicá-la quando habilitar a replicação.
Consistência de várias VMs
Se quiser que as VMs sejam replicadas juntas e tenham compartilhado pontos de recuperação consistentes com falhas e consistentes com aplicativos no failover, você poderá reuni-las em um grupo de replicação. A consistência de várias VMs afeta o desempenho da carga de trabalho e só deve ser usada para VMs que executam cargas de trabalho que precisam de consistência em todas as máquinas.
Instantâneos e pontos de recuperação
Os pontos de recuperação são criados a partir de instantâneos de discos de VM tirados em um point-in-time específico. Ao fazer failover de uma VM, você usa um ponto de recuperação para restaurar a VM no local de destino.
Ao fazer failover, geralmente queremos garantir que a VM comece sem corrupção ou perda de dados e que os dados da VM sejam consistentes para o sistema operacional e para aplicativos executados na VM. Isso depende do tipo de instantâneos tirados.
O Site Recovery tira instantâneos da seguinte maneira:
- A Recuperação de Site obtém instantâneos de dados consistentes com falhas por padrão e instantâneos consistentes com aplicativos se você especificar uma frequência para eles.
- Os pontos de recuperação são criados a partir dos snapshots e armazenados de acordo com as configurações de retenção na política de replicação.
Consistência
A tabela a seguir explica diferentes tipos de consistência.
Consistente com a falha
| Descrição | Detalhes | Recomendação |
|---|---|---|
| Um instantâneo consistente com falhas captura dados que estavam no disco quando o instantâneo foi tirado. Não inclui nada na memória. Ele contém o equivalente aos dados no disco que estariam presentes se a VM falhasse ou o cabo de alimentação fosse retirado do servidor no instante em que o instantâneo foi tirado. Uma falha consistente não garante a consistência de dados para o sistema operacional ou para aplicativos na VM. |
O Site Recovery cria pontos de recuperação consistentes com falhas a cada cinco minutos por padrão. Essa configuração não pode ser modificada. |
Hoje, a maioria dos aplicativos pode se recuperar bem de pontos consistentes com falhas. Os pontos de recuperação consistentes com falhas geralmente são suficientes para a replicação de sistemas operacionais e aplicativos como servidores DHCP e servidores de impressão. |
Consistente com a aplicação
| Descrição | Detalhes | Recomendação |
|---|---|---|
| Os pontos de recuperação consistentes com aplicativos são criados a partir de instantâneos consistentes com aplicativos. Um instantâneo consistente com o aplicativo contém todas as informações em um instantâneo consistente com falhas, além de todos os dados na memória e transações em andamento. |
Os instantâneos consistentes com o aplicativo usam o VSS (Serviço de Cópias de Sombra de Volume): 1) O Azure Site Recovery usa o método de backup somente cópia (VSS_BT_COPY) que não altera o tempo de backup do log de transações do Microsoft SQL e o número de sequência 2) Quando um instantâneo é iniciado, o VSS executa uma operação de cópia na gravação (COW) no volume. 3) Antes de executar o COW, o VSS informa a cada aplicativo na máquina que ele precisa liberar seus dados residentes na memória para o disco. 4) O VSS permite que o aplicativo de backup/recuperação de desastres (neste caso, o Site Recovery) leia os dados do snapshot e prossiga. |
Os instantâneos consistentes com o aplicativo são tirados de acordo com a frequência especificada. Essa frequência deve ser sempre menor do que a definida para reter pontos de recuperação. Por exemplo, se você retiver pontos de recuperação usando a configuração padrão de 24 horas, deverá definir a frequência em menos de 24 horas. Eles são mais complexos e levam mais tempo para serem concluídos do que instantâneos consistentes com falhas. Eles afetam o desempenho de aplicativos executados em uma VM habilitada para replicação. |
Processo de ativação pós-falha e de reativação pós-falha
Depois que a replicação é configurada e você executa um drill de recuperação de desastres (failover de teste) para verificar se tudo está funcionando conforme o esperado, você pode executar failover e failback conforme necessário.
Você executa fail para uma única máquina ou cria planos de recuperação para failover de várias VMs ao mesmo tempo. As vantagens de um plano de recuperação em vez de failover de máquina única incluem:
- Você pode modelar dependências do aplicativo incluindo todas as VMs no aplicativo em um único plano de recuperação.
- Você pode adicionar scripts, runbooks do Azure e pausar para ações manuais.
Depois de acionar o failover inicial, você o confirma para começar a acessar a carga de trabalho da VM do Azure.
Quando o site local principal estiver disponível novamente, você poderá se preparar para failback. Para fazer failback, você precisa configurar uma infraestrutura de failback, incluindo:
- Servidor de processo temporário no Azure: para fazer failback do Azure, configure uma VM do Azure para atuar como um servidor de processo para lidar com a replicação do Azure. É possível eliminar esta VM após a conclusão da reativação pós-falha.
- Conexão VPN: para failback, você precisa de uma conexão VPN (ou Rota Expressa) da rede do Azure para o site local.
- Servidor de destino mestre separado: por padrão, o servidor de destino mestre que foi instalado com o servidor de configuração na VM VMware local lida com failback. Se você precisar fazer failback de grandes volumes de tráfego, configure um servidor de destino mestre local separado para essa finalidade.
- Política de reativação pós-falha: para replicar de novo para o site no local, precisa de uma política de reativação pós-falha. Essa política é criada automaticamente quando você cria uma política de replicação local para o Azure.
Depois que os componentes estão no lugar, o failback ocorre em três ações:
- Estágio 1: Reproteja as VMs do Azure para que elas sejam replicadas do Azure de volta para as VMs VMware locais.
- Estágio 2: Execute um failover para o site local.
- Estágio 3: Depois que as cargas de trabalho falharem, reative a replicação para as VMs locais.
Próximos passos
Siga este tutorial para habilitar a replicação do VMware para o Azure.