Ativação pós-falha e reativação pós-falha
O Azure Site Recovery oferece a flexibilidade de failover para o Azure se ocorrer um desastre e failback para máquinas locais após o término do evento.
Agora quer efetuar uma ativação pós-falha total do resto do ambiente protegido para o Azure. Efetua uma ativação pós-falha total após executar um teste de ativação pós-falha numa única máquina virtual de teste com êxito. Fará então a reativação pós-falha, depois de concluir com êxito a ativação pós-falha.
Nesta unidade, você explora as diferenças entre failover e failback. Também irá aprender a criar uma política de reativação pós-falha automaticamente, após configurar uma política de replicação para o Azure.
Ativação pós-falha e reativação pó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 ambiente ativo atual protegido usando a Recuperação de Site é movido para o ambiente de réplica. Esse ambiente de réplica de destino substitui o ambiente dinâmico e se torna a infraestrutura principal.
Uma reativação pós-falha é o processo inverso de uma ativação pós-falha. O ambiente ativo anterior (que agora é o ambiente de réplica, porque ocorreu uma ativação pós-falha) volta a ter a sua função original e passa novamente a ser o ambiente ativo. Depois de ter ocorrido a ativação pós-falha em primeiro lugar, tem de ocorrer uma fase de nova proteção. Nesta fase, sincroniza novamente o ambiente original com o novo ambiente ativo. Esse processo permite que o failover e o failback aconteçam sem qualquer perda de dados. A fase de nova proteção será provavelmente um processo demorado, uma vez que tem de garantir que o antigo ambiente ativo funciona corretamente após o desastre.
As quatro fases das ações de ativação pós-falha e reativação pós-falha 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.
- Reproteger as máquinas virtuais do Azure: depois que o failover ocorrer, 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 para o local: quando o site local está de volta e em execução, é possível fazer failover de volta para esse ambiente. O ambiente em questão voltará a ser o ambiente ativo. Não pode efetuar a reativação pós-falha em servidores físicos. Todos os sistemas têm de efetuar a reativação pós-falha em máquinas virtuais.
- Reproteger máquinas virtuais locais: 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 reativação pós-falha
Quando cria uma política de reativação pós-falha no local para copiar as suas máquinas no local para o Azure, é criada automaticamente uma política de reativação pós-falha associada. A política tem alguns atributos fixos que não podem ser alterados. Estes atributos são:
- Só pode voltar a replicar para o seu servidor de configuração no local.
- O objetivo de ponto de recuperação está definido como 15 minutos.
- A retenção do ponto de recuperação está definida como 24 horas.
- São captados instantâneos de hora a hora consistentes com as aplicações.
A execução da reativação pós-falha interrompe as VMs do Azure. Após a conclusão da replicação, inicie a sua VM no 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 a utilização de scripts durante a ativação pós-falha ou a reativação pós-falha. 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.
Ativações pós-falha flexíveis
Com a capacidade de ser flexível com failovers, o Site Recovery pode executar failovers sob demanda para fins de teste. Isolar esses testes significa que os serviços ao vivo não são interrompidos. Esta flexibilidade permite também a execução de uma ativação pós-falha durante um período de indisponibilidade previsto do serviço ativo. A interrupção não interrompe os usuários do sistema porque eles são automaticamente alternados para o ambiente replicado. Esta flexibilidade também funciona de forma inversa. A reativação pós-falha a pedido pode fazer parte de um teste planeado ou de um cenário de recuperação após desastre totalmente invocado.