Backup e recuperação de desastre para aplicativos do Azure

Recuperação de desastre é o processo de restaurar a funcionalidade do aplicativo após uma perda catastrófica.

Na nuvem, reconhecemos antecipadamente que falhas ocorrerão. Em vez de tentar evitar completamente a falha, a meta é minimizar os efeitos de uma falha em um componente individual. Os testes são uma maneira de minimizar esses efeitos. Automatize testes em seus aplicativos sempre que possível, mas você precisa estar preparado para quando eles falharem. Quando uma falha ocorre, ter estratégias de backup e recuperação se torna importante.

Sua tolerância à funcionalidade reduzida durante um desastre é uma decisão de negócios que varia de um aplicativo para outro. Pode ser aceitável que alguns aplicativos não fiquem disponíveis, ou que fiquem parcialmente disponíveis com funcionalidade reduzida ou processamento atrasado por um período. Para outros aplicativos, qualquer funcionalidade reduzida é inaceitável.

Pontos-chave

  • Crie e teste um plano de recuperação de desastre regularmente usando os principais cenários de falha.
  • Elabore uma estratégia de recuperação de desastre para executar a maioria dos aplicativos com funcionalidade reduzida.
  • Elabore uma estratégia de backup que seja adaptada aos requisitos de negócios e às circunstâncias do aplicativo.
  • Automatize as etapas e os processos de failover e failback.
  • Teste e valide a abordagem de failover e failback com êxito pelo menos uma vez.

Plano de recuperação de desastre

Comece pela criação de um plano de recuperação. O plano é considerado completo após ser totalmente testado. Inclua as pessoas, os processos e os aplicativos necessários para restaurar a funcionalidade dentro do SLA (Contrato de Nível de Serviço) que você definiu para seus clientes.

Considere as seguintes sugestões ao criar e testar seu plano de recuperação de desastre:

  • Inclua o processo para entrar em contato com o suporte e para escalonar problemas. Essas informações ajudarão a evitar tempo de inatividade prolongado enquanto você trabalhar no processo de recuperação pela primeira vez.
  • Avalie o impacto das falhas de aplicativos sobre os negócios.
  • Escolha uma arquitetura de recuperação entre regiões para aplicativos críticos.
  • Identifique um proprietário específico do plano de recuperação de desastres, incluindo automação e testes.
  • Documente o processo, especialmente as etapas manuais.
  • Automatize o processo o máximo possível.
  • Estabeleça uma estratégia de backup para todos os dados de referência e transacionais e teste a restauração dos backups regularmente.
  • Configure alertas para a pilha de serviços do Azure consumidos pelo aplicativo.
  • Treine a equipe de operações para executar o plano.
  • Execute simulações de desastres regulares para validar e aprimorar o plano.

Se estiver usando o Azure Site Recovery para replicar VMs (máquinas virtuais), crie um plano de recuperação totalmente automatizado para fazer o failover de todo o aplicativo.

Testes de preparação operacional

Realize um teste de prontidão operacional para failover para a região secundária e failback para a região primária. Muitos serviços do Azure são compatíveis com failover manual ou failover de teste para exercícios de recuperação de desastre. Em vez disso, você pode simular uma interrupção desligando ou removendo serviços do Azure.

As respostas operacionais automatizadas devem ser testadas com frequência como parte do ciclo de vida normal do aplicativo para garantir a eficácia operacional.

Testes de failover e failback

Teste o failover e o failback para verificar se os serviços dependentes de seu aplicativo voltam a funcionar de maneira sincronizada durante a recuperação de desastre. Alterações nos sistemas e operações podem afetar as funções de failover e fallback, mas o impacto pode não ser detectado até que o sistema principal falhe ou fique sobrecarregado. Teste os recursos de failover antes que eles sejam necessários para solucionar um problema ao vivo. Além disso, certifique-se de que os serviços dependentes passem pelo failover e pelo failback na ordem correta.

Se você estiver usando o Azure Site Recovery para replicar VMs, execute simulações de recuperação de desastre periodicamente testando failovers para validar a estratégia de replicação. Um failover de teste não afeta a replicação da VM em andamento nem o ambiente de produção. Para saber mais, confira Realizar uma análise detalhada da recuperação de desastre para o Azure.

Interrupção de um serviço dependente

Para cada serviço dependente, entenda as implicações da interrupção do serviço e a forma como o aplicativo responderá. Muitos serviços incluem recursos que dão suporte à resiliência e à disponibilidade, portanto, avaliar cada serviço de modo independente provavelmente aprimorará seu plano de recuperação de desastre. Por exemplo, os Hubs de Eventos do Azure dão suporte ao failover para o namespace secundário.

Interrupção de rede

Quando partes da rede do Azure estiverem inacessíveis, talvez você não consiga acessar o aplicativo ou os dados. Nesse caso, recomendamos elaborar a estratégia de recuperação de desastre para executar a maioria dos aplicativos com funcionalidade reduzida.

Se a redução da funcionalidade não for uma opção, as opções restantes serão o tempo de inatividade do aplicativo ou o failover para uma região alternativa.

Em um cenário de funcionalidade reduzida:

  • Se o aplicativo não puder acessar os respectivos dados devido a uma interrupção da rede do Azure, você poderá executar localmente com funcionalidade reduzida do aplicativo usando dados armazenados em cache.
  • Você pode armazenar dados em um local alternativo até que a conectividade seja restaurada.

Automação de recuperação

As etapas necessárias para recuperar ou fazer failover do aplicativo para uma região secundária do Azure em situações de falha devem ser codificadas, preferencialmente de maneira automatizada, para garantir que existam recursos para responder de maneira eficaz a uma interrupção de modo a limitar o impacto. Também deve haver etapas codificadas semelhantes para capturar o processo necessário para fazer failback do aplicativo na região primária quando um problema de disparo de failover é resolvido.

Ao automatizar procedimentos de failover, não deixe de considerar as ferramentas usadas para orquestrar o failover na estratégia de failover. Por exemplo, se executar o failover no Jenkins em execução em uma VM, você terá problemas se essa máquina virtual fizer parte da interrupção. O Azure DevOps Projects também tem o escopo definido em regiões.

Estratégia de backup

Muitas estratégias alternativas estão disponíveis para implementação de computação distribuída entre regiões. Essas estratégias devem ser personalizadas segundo os requisitos específicos de negócios e as circunstâncias do aplicativo. Em um nível elevado, as abordagens podem ser divididas nas seguintes categorias:

  • Reimplantar em caso de desastre: nessa abordagem, o aplicativo é reimplantado do zero no momento do desastre. Reimplantar do zero é adequado para aplicativos não críticos, que não exigem um tempo de recuperação garantido.

  • Warm spare (ativo/passivo): crie um serviço hospedado secundário em uma região alternativa e implante funções para garantir a capacidade mínima. No entanto, as funções não recebem tráfego de produção. Essa abordagem é útil para aplicativos que não foram projetados para distribuir tráfego entre regiões.

  • Reposição quente (ativo/ativo): o aplicativo foi projetado para receber a carga de produção em várias regiões. Os serviços de nuvem em cada região podem ser configurados para capacidade maior do que o necessário para fins de recuperação de desastre. Em vez disso, os serviços de nuvem podem escalar horizontalmente conforme o necessário no momento de um desastre e failover. Essa abordagem exige um grande investimento no design do aplicativo, mas tem benefícios significativos. Isso inclui tempo de recuperação baixo e garantido, testes contínuos de todos os locais de recuperação e uso eficiente da capacidade.

Planejar-se para falhas regionais

O Azure é dividido fisicamente e logicamente em unidades chamadas de regiões. Uma região é composta por um ou mais datacenters próximos uns dos outros. Muitas regiões e serviços também dão suporte a zonas de disponibilidade, que podem ser usadas para fornecer mais resiliência contra interrupções em um só datacenter. Considere usar regiões com zonas de disponibilidade para aprimorar a disponibilidade de sua solução.

Em raras circunstâncias, é possível que instalações em toda uma zona de disponibilidade ou região fiquem inacessíveis, por exemplo, devido a falhas de rede. Ou instalações podem ser inteiramente perdidas, por exemplo, devido a um desastre natural. O Azure tem recursos para criar aplicativos que são distribuídos entre zonas e regiões. Essa distribuição ajuda a minimizar a possibilidade de que uma falha em uma zona ou região afete outras zonas ou regiões.

Próxima etapa

Volte ao artigo principal: Teste