Fazer failover e failback usando o Azure Site Recovery
O Azure Site Recovery permite que sua organização tenha flexibilidade, usando um failover manual para uma região secundária do Azure ou um failback para uma máquina virtual de origem. A maneira mais simples de gerenciar esse processo é manualmente no portal do Azure. Você terá outras opções para habilitar a automação se sua empresa desejar automatizar o disparo de um failover. Essas opções incluem tecnologias, como script por meio do PowerShell, ou a configuração de runbooks na Automação do Azure para orquestrar failovers.
Siga estas etapas para executar um failover completo de uma VM protegida para uma região secundária em sua assinatura. Depois que o failover tiver sido concluído com êxito, você fará failback dessa VM.
Nesta unidade, você explorará o failover e o failback, aprenderá como proteger novamente uma VM com failover e monitorará o status da nova proteção.
O que é failover?
Um failover ocorrerá quando uma decisão for tomada a fim de executar um plano de DR para sua organização. O ambiente de produção existente, protegido pelo Site Recovery, será replicado em uma região diferente. O ambiente de destino se tornará o ambiente de produção de fato em que os serviços de produção de sua organização serão executados. Depois que a região de destino estiver ativa, o ambiente de origem não deverá mais ser usado. Você imporá essa condição mantendo as VMs de origem paradas.
Há outra vantagem de desligar as VMs de origem. Usar uma VM desligada resultará em uma perda mínima de dados, pois o Site Recovery aguardará até que todos os dados sejam gravados no disco antes de disparar o failover. Para usar esses dados e ter o menor RPO possível, selecionamos o ponto de recuperação Mais recente (menor RPO).
O que é nova proteção e por que ela é importante?
Quando é feito o failover de uma VM, a replicação que o Site Recovery executa fica inativa. Será necessário habilitar a proteção novamente para começar a proteger a VM com failover. Como a infraestrutura já está em uma região diferente, você poderá iniciar a replicação de volta para a região de origem. A nova proteção permitirá que o Site Recovery comece a replicar seu novo ambiente de destino de volta para o ambiente de origem em que ele foi iniciado.
Você pode usar a flexibilidade de fazer failover de VMs individuais ou usando um plano de recuperação para proteger novamente sua infraestrutura com failover. Será possível proteger novamente cada VM de modo individual ou várias VMs usando um plano de recuperação.
A nova proteção demora entre 45 minutos e duas horas, dependendo do tamanho e do tipo de VM. Ao contrário dos processos do Site Recovery que você pode monitorar observando o progresso do trabalho, você deverá exibir o progresso da nova proteção no nível da VM. Esse requisito se deve ao fato de a fase de sincronização não ser listada como um trabalho de recuperação de site.
A imagem mostra o status do item protegido, com o percentual sincronizado realçado.
O que é failback?
Failback é o inverso de um failover. Failback é onde um failover concluído para uma região secundária foi confirmado, além disso, ele se torna o ambiente de produção. Uma nova proteção foi concluída para um ambiente com failover e o ambiente de origem será a réplica dele. Em um cenário de failback, o Site Recovery fará failover de volta para as VMs de origem.
O processo para concluir um failback é o mesmo que o de um failover, mesmo para reutilizar o plano de recuperação. A seleção do failover em seu plano de recuperação tem de definido como a região de destino e para definido como a região de origem.
Gerenciar failovers
O Site Recovery pode executar failovers sob demanda. Os failovers de teste são isolados, o que significa que não afetam os serviços de produção. Essa flexibilidade permite que você execute um failover sem interromper os usuários desse sistema. A flexibilidade funciona da outra maneira também, permitindo failback sob demanda como parte de um teste planejado ou de um processo de DR totalmente invocado.
Os planos de recuperação do Site Recovery também permitem personalizar e sequenciar o failover e o failback. Os planos permitem agrupar computadores e cargas de trabalho.
A flexibilidade também se aplica à maneira como você dispara o processo de failover. Os failovers manuais são fáceis de serem feitos por meio do portal do Azure. Criar scripts do PowerShell ou usar runbooks na Automação do Azure proporciona a você opções de automação.
Corrigir problemas com um failover
Mesmo que o Site Recovery seja automatizado, alguns erros ainda poderão ocorrer. A lista a seguir mostrará os três problemas mais comuns observados. Para obter uma lista completa de problemas e descobrir como solucioná-los, confira o link na unidade Resumo.
Problemas de cota de recurso do Azure
O Site Recovery deverá criar recursos em regiões diferentes. Se nossa assinatura não puder fazer isso, a replicação falhará. Esse erro também ocorrerá caso nossa assinatura não tenha os limites de cota adequados para criar VMs que correspondam ao tamanho das VMs de origem.
É possível corrigir esse problema entrando em contato com o suporte de cobrança do Azure e solicitando que eles criem VMs do tamanho adequado na região de destino necessária.
Um ou mais discos estão disponíveis para proteção
Esse erro ocorrerá caso tenha concluído a configuração do Site Recovery para suas VMs. E posteriormente incluiu ou inicializou discos adicionais.
Para corrigir esse erro, você pode adicionar a replicação para os discos recém-adicionados ou optar por ignorar o aviso de disco.
Certificados raiz confiáveis
Verifique se os certificados raiz mais recentes estão instalados para permitir que o Site Recovery se comunique com as VMs e as autentique para obter uma replicação com segurança. Será possível ver esse erro caso as VMs não tenham as atualizações mais recentes aplicadas. Antes que o Site Recovery possa habilitar a replicação, será necessário atualizar as VMs do Windows e do Linux.
A correção será diferente para cada sistema operacional. O Windows é tão simples quanto verificar se a atualização automática do Windows está ativada e as atualizações estão aplicadas. Para cada distribuição do Linux, você precisará seguir as diretrizes fornecidas pelo distribuidor.