Servidor físico para arquitetura de recuperação de desastres do Azure – Modernizado
Este artigo descreve a arquitetura modernizada e os processos usados quando você replica, faz failover e recupera servidores físicos Windows e Linux entre um site local e o Azure, usando o serviço Azure Site Recovery .
Para obter informações sobre os requisitos do servidor de configuração nas versões clássicas, consulte Servidor físico para arquitetura de recuperação de desastres do Azure.
Nota
Certifique-se de criar um novo cofre dos Serviços de Recuperação para configurar o dispositivo de replicação ASR. Não use um cofre existente.
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 da máquina física 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 máquinas 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. |
| Dispositivo de replicação do Azure Site Recovery | Este é o bloco de construção básico de toda a infraestrutura local do Azure Site Recovery. Todos os componentes do dispositivo coordenam-se com o dispositivo de replicação. Este serviço supervisiona todas as atividades de recuperação de site de ponta a ponta, incluindo monitoramento da integridade de máquinas protegidas, replicação de dados, atualizações automáticas, etc. |
O aparelho hospeda vários componentes cruciais, como: Servidor proxy: este componente atua como um canal proxy entre o agente de mobilidade e os serviços de Recuperação de Site na nuvem. Ele garante que não seja necessária conectividade adicional com a Internet das cargas de trabalho de produção para gerar pontos de recuperação. Itens descobertos: este componente reúne informações do vCenter e coordena-se com o serviço de gestão do Azure Site Recovery na nuvem. Servidor de reproteção: este componente coordena entre o Azure e as máquinas locais durante as operações de reproteção e failback. Servidor de processo: este componente é usado para armazenamento em cache, compactação de dados antes de serem enviados para o Azure. Saiba mais sobre o dispositivo de replicação e como usar vários dispositivos de replicação. Agente do Serviço de Recuperação: este componente é usado para configurar/registrar com serviços de Recuperação de Site e para monitorar a integridade de todos os componentes. Provedor de recuperação de site: este componente é usado para facilitar a reproteção. Ele identifica entre a reproteção de local alternativo e a reproteção de local original para uma máquina de origem. Serviço de replicação: este componente é usado para replicar dados do local de origem para o Azure. |
| Máquinas replicadas | O Serviço de Mobilidade é instalado em cada servidor físico replicado. | Recomendamos que permita a instalação automática do Serviço de Mobilidade. Como alternativa, você pode instalar o serviço manualmente. |
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
O Site Recovery não suporta o uso de um proxy de autenticação para controlar a conectividade de rede.
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:
| URL | Detalhes |
|---|---|
| portal.azure.com | Navegue para o portal do Azure. |
*.windows.net *.msftauth.net*.msauth.net*.microsoft.com*.live.com *.office.com |
Para iniciar sessão na sua subscrição do Azure. |
*.microsoftonline.com |
Crie aplicativos Microsoft Entra para que o dispositivo se comunique com o Azure Site Recovery. |
| management.azure.com | Crie aplicativos Microsoft Entra para que o dispositivo se comunique com o serviço Azure Site Recovery. |
*.services.visualstudio.com |
Carregue logs de aplicativos usados para monitoramento interno. |
*.vault.azure.net |
Gerencie segredos no Cofre da Chave do Azure. Nota: Certifique-se de que as máquinas a replicar tenham acesso a isso. |
| aka.ms | Permitir o acesso a aka.ms links. Usado para atualizações do dispositivo Azure Site Recovery. |
| download.microsoft.com/download | Permitir downloads do download da Microsoft. |
*.servicebus.windows.net |
Comunicação entre o dispositivo e o serviço Azure Site Recovery. |
*.discoverysrv.windowsazure.com |
Conecte-se à URL do serviço de descoberta do Azure Site Recovery. |
*.hypervrecoverymanager.windowsazure.com |
Conectar-se a URLs de microsserviço do Azure Site Recovery |
*.blob.core.windows.net |
Carregar dados para o armazenamento do Azure, que é usado para criar discos de destino |
*.backup.windowsazure.com |
URL do serviço de proteção – um microsserviço usado pelo Azure Site Recovery para processar e criar discos replicados no Azure |
Processo de replicação
Quando você habilita a replicação para um sistema, 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 máquinas físicas, a replicação é em nível de bloco, quase contínua, usando o agente do serviço de mobilidade em execução no sistema.
- 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.
- 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 máquina física 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 máquinas se comunicam com o dispositivo local na porta de entrada HTTPS 443, para gerenciamento de replicação.
- O dispositivo orquestra a replicação com o Azure pela porta de saída HTTPS 443.
- As máquinas enviam dados de replicação para o servidor de processo 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 asrseeddisk). Os pontos de recuperação são criados neste disco.
Processo de ativação pós-falha e de reativação pós-falha
Depois de configurar a replicação e executar um drill de recuperação de desastres (failover de teste) para verificar se tudo está funcionando conforme o esperado, você pode executar o failover conforme necessário.
Nota
Para servidores físicos, não há suporte para failback
- Você pode executar failover para uma única máquina ou criar um plano de recuperação para fazer failover de vários servidores simultaneamente. As vantagens de um plano de recuperação em vez de failover de máquina única incluem:
- Você pode modelar dependências de aplicativos incluindo todos os servidores 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.
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 sofrer 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 predefinição, a ressincronização está agendada para ser executada automaticamente fora do horário de expediente. Se você não quiser esperar pela ressincronização padrão fora do expediente, poderá ressincronizar um sistema manualmente. Para fazer isso, vá para o portal do Azure, selecione a máquina >física Ressincronizar.
- 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.
Política de replicação
Quando você habilita a replicação de VM do Azure, por padrão, o Site Recovery cria uma nova política de replicação com as configurações padrão resumidas na tabela.
| Definição de política | Detalhes | Predefinição |
|---|---|---|
| Retenção no ponto de recuperação | Especifica por quanto tempo a Recuperação de Site mantém os pontos de recuperação | 1 dia |
| Frequência de snapshot consistente com aplicativos | Com que frequência a Recuperação de Site tira um instantâneo consistente com o aplicativo | Desativado |
Instantâneos e pontos de recuperação
Os pontos de recuperação são criados a partir de instantâneos dos discos da máquina tirados em um ponto específico no tempo. Ao fazer failover de um sistema, você usa um ponto de recuperação para restaurar a máquina física como uma 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 o sistema 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 máquina. |
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 um sistema habilitado para replicação. |
Próximos passos
Siga este tutorial para habilitar a máquina física e a replicação do VMware para o Azure.