Alternância automática e retorno

  • 6 minutos

O Azure Site Recovery oferece a flexibilidade de failover para o Azure se ocorrer um desastre e failover de volta para máquinas locais após o término do evento.

Agora você deseja fazer um failover completo para o restante do ambiente protegido no Azure. Você faz um failover completo depois de executar com êxito uma simulação de failover em uma única máquina virtual de teste. Em seguida, você fará o failback depois que o failover for concluído com êxito.

Nesta unidade, você explora as diferenças entre failover e failback. Você também aprenderá como obter uma política de failback criada automaticamente depois de configurar uma política de replicação para o Azure.

Alternância em caso de falha e retorno após falha

Um failover é o processo que ocorre quando é tomada a decisão de invocar o plano BCDR para o negócio. O failover acontece quando o atual ambiente ativo, protegido através da Recuperação de Sites, é transferido para o ambiente de réplica. Esse ambiente de réplica de destino substitui o ambiente ao vivo e torna-se a infraestrutura principal.

Um failback é o processo inverso de um failover, onde o sistema é restaurado ao seu estado original após uma falha. O ambiente ao vivo anterior (que agora é o ambiente de réplica porque ocorreu um failover) retoma sua função original e se torna o ambiente ao vivo novamente. Após a ocorrência do failover na primeira instância, deve ocorrer uma fase de reproteção. Nesta fase, você coloca o ambiente original de volta em sincronia com o novo ambiente ao vivo. Esse processo permite que o failover e o failback aconteçam sem qualquer perda de dados. É provável que a fase de reproteção seja um processo demorado, porque você precisa estabelecer que o antigo ambiente vivo funciona corretamente após o desastre.

Diagrama mostrando a natureza cíclica do failover e, em seguida, do failback, e como funciona a replicação para reproteger a VM.

Os quatro estágios das ações de failover e failback são:

  • Failover para o Azure: se o site primário local ficar inativo, a decisão de failover para o Azure (ou seu site secundário) será tomada, o que criará máquinas virtuais a partir dos dados replicados primários.
  • Reprotect Azure virtual machines: Depois que o failover ocorre, as máquinas virtuais do Azure devem ser reprotegidas para que possam replicar as alterações de volta para o ambiente local depois que o desastre for evitado. As máquinas virtuais são desligadas para garantir a consistência dos dados.
  • Failback paralocal: Quando o site local estiver de volta e em execução, é possível fazer failover de volta para esse ambiente. Em seguida, torna-se novamente o ambiente ao vivo. Não é possível fazer failback para servidores físicos. Todos os sistemas devem fazer failover para máquinas virtuais.
  • Reprotect on-premises virtual machines: A reproteção das máquinas virtuais locais ocorre para que elas comecem a replicar para o Azure depois que o failback tiver acontecido com êxito.

Políticas de failback

Quando você cria uma política de replicação local para copiar suas máquinas locais para o Azure, uma política de failback associada é criada automaticamente para você. A política tem alguns atributos fixos que não podem ser alterados. Esses atributos são:

  • Só pode replicar de volta para o servidor de configuração local.
  • O objetivo do ponto de recuperação é fixado em 15 minutos.
  • A retenção do ponto de recuperação é fixada em 24 horas.
  • Os instantâneos consistentes com a aplicação são configurados para ocorrer a cada hora.

A execução do failback interrompe as VMs do Azure. Após a conclusão da replicação, inicie a VM local para assumir as cargas de trabalho. O serviço é interrompido, portanto, agende o failback em um momento que não afete seus negócios.

Planos de continuidade de negócios e recuperação de desastres

Os planos BCDR no Site Recovery permitem a personalização e o sequenciamento de failover e failback de máquinas virtuais e dos aplicativos executados nelas. As máquinas são agrupadas e as ações de recuperação podem ser automatizadas com o uso de scripts durante o failover ou failback. Você também pode adicionar mais etapas manuais para ações, se necessário. Se você testar o plano BCDR antes que um desastre aconteça, poderá ter mais confiança em um resultado positivo. Você precisa colocar sua infraestrutura em funcionamento novamente no local secundário rapidamente para atender ao objetivo de tempo de recuperação da empresa.

Failovers flexíveis

Graças à capacidade de gerir failovers com flexibilidade, o Site Recovery pode executar failovers a pedido para fins de teste. Isolar esses testes significa que os serviços ao vivo não são interrompidos. Essa flexibilidade também permite que um failover seja executado durante uma interrupção planejada do serviço ao vivo. A interrupção não interrompe os usuários do sistema porque eles são automaticamente alternados para o ambiente replicado. A flexibilidade também funciona ao contrário. O failback sob demanda pode ser como parte de um teste planejado ou como parte de um cenário de recuperação de desastres totalmente invocado.