Failover e failback
O Azure Site Recovery oferece a flexibilidade de fazer failover para o Azure em caso de desastre e failback para os computadores locais após o término do evento.
Agora você deseja fazer um failover completo do restante do ambiente protegido para o Azure. Faça um failover completo depois de executar com êxito uma análise 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ê explorará as diferenças entre failover e failback. Você também aprenderá a criar uma política de failback automaticamente depois de configurar uma política de replicação para o Azure.
Failover e failback
Um failover é o processo que ocorre quando é tomada a decisão de invocar o plano de BCDR para a empresa. O failover ocorre quando o ambiente dinâmico atual que é protegido com o Site Recovery é 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.
Um failback é o inverso de um failover. O ambiente dinâmico anterior (que agora é o ambiente de réplica porque ocorreu um failover) retoma sua função original e torna-se o ambiente dinâmico novamente. Depois que o failover ocorre na primeira instância, uma fase de nova proteção precisa ocorrer. Nesta fase, você coloca o ambiente original novamente em sincronia com o novo ambiente dinâmico. Esse processo permite que o failover e o failback ocorram sem nenhuma perda de dados. A fase de nova proteção provavelmente será um processo demorado, pois você precisará estabelecer que o ambiente dinâmico antigo funcione corretamente após o desastre.
Os quatro estágios de ações de failover e failback são:
- Fazer failover para o Azure: Se o site primário local ficar inativo, será tomada a decisão de fazer failover para o Azure (ou para o site secundário), o que cria máquinas virtuais com base nos dados com réplica primária.
- Proteger novamente as máquinas virtuais do Azure: Depois que o failover ocorrer, as máquinas virtuais do Azure precisarão ser protegidas novamente, para que possam replicar as alterações mais uma vez para o ambiente local após a prevenção do desastre. As máquinas virtuais são desligadas para garantir a consistência dos dados.
- Fazer failback para o local: Quando o site local está em funcionamento novamente, é possível fazer failover mais uma vez para esse ambiente. Em seguida, ele se tornará o ambiente dinâmico novamente. Não é possível fazer failback para servidores físicos. Todos os sistemas precisam fazer failback para máquinas virtuais.
- Proteger novamente as máquinas virtuais locais: A nova proteção das máquinas virtuais locais ocorre para que elas iniciem a replicação para o Azure após o failback bem-sucedido.
Políticas de failback
Quando você cria uma política de replicação local para copiar os computadores 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:
- Pode apenas fazer a nova replicação para o servidor de configuração local.
- O objetivo de ponto de recuperação é definido como 15 minutos.
- A retenção do ponto de recuperação é definida como 24 horas.
- Os instantâneos consistentes com o aplicativo são definidos como intervalos de uma hora.
A execução do failback interrompe as VMs do Azure. Depois que a replicação for concluída, inicie a VM local para assumir as cargas de trabalho. O serviço será interrompido; portanto, agende o failback em um horário que não afete os negócios.
Planos de continuidade dos negócios e recuperação de desastres
Os planos de BCDR do Site Recovery permitem a personalização e o sequenciamento de failover e de failback de máquinas virtuais e dos aplicativos executados nelas. Os computadores são agrupados e as ações de recuperação podem ser automatizadas com o uso de scripts durante o failover ou o failback. Você também poderá adicionar mais etapas manuais para ações, se necessário. Se você testar o plano de BCDR antes que um desastre ocorra, poderá ter mais confiança de um resultado positivo. Você precisará colocar a infraestrutura em funcionamento novamente na localização secundária com rapidez para atender ao objetivo de tempo de recuperação da empresa.
Failovers flexíveis
Com a capacidade de ser flexível com failovers, o Site Recovery pode executar failovers sob demanda para fins de teste. O isolamento desses testes significa que os serviços não serão interrompidos. Essa flexibilidade também permite que um failover seja executado durante uma interrupção planejada do serviço dinâmico. A interrupção não removerá os usuários do sistema, pois eles serão automaticamente alternados para o ambiente replicado. A flexibilidade também funciona da outra maneira. O failback sob demanda pode ocorrer como parte de um teste planejado ou como parte de um cenário de recuperação de desastre totalmente invocado.