Partilhar via

Continuidade de negócio e recuperação após desastre

  • Artigo

As cargas de trabalho da organização e dos aplicativos corporativos têm requisitos de RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e RPO (Recovery Point Objetive, objetivo de ponto de recuperação). O projeto eficaz de continuidade de negócios e recuperação de desastres (BCDR) fornece recursos no nível da plataforma que atendem a esses requisitos. Para projetar recursos BCDR, capture os requisitos de recuperação de desastres (DR) da plataforma.

Considerações de design

Considere os seguintes fatores ao projetar o BCDR para cargas de trabalho de aplicativos:

  • Requisitos de disponibilidade de aplicativos e dados:

    • Requisitos de RTO e RPO para cada carga de trabalho.
    • Suporte para padrões de disponibilidade ativo-ativo e ativo-passivo.

  • BCDR como um serviço para serviços de plataforma como serviço (PaaS):

    • Suporte nativo a recursos de DR e alta disponibilidade (HA).
    • Recursos de replicação geográfica e DR para serviços PaaS.

  • Suporte para implantações multirregionais para failover, com proximidade de componentes para desempenho.

  • Operações de aplicativos com funcionalidade reduzida ou desempenho degradado durante uma interrupção.

  • Adequação da carga de trabalho para zonas de disponibilidade ou conjuntos de disponibilidade:

    • Compartilhamento de dados e dependências entre zonas.
    • As zonas de disponibilidade em comparação com os conjuntos de disponibilidade afetam os domínios de atualização.
    • Porcentagem de cargas de trabalho que podem estar sob manutenção simultaneamente.
    • Suporte a zonas de disponibilidade para unidades de manutenção de estoque (SKUs) de máquina virtual (VM) específicas. Por exemplo, o Armazenamento em Disco Ultra do Azure requer o uso de Zonas de Disponibilidade.

  • Backups consistentes para aplicativos e dados:

    • Instantâneos de VM.
    • Cofres dos Serviços de Recuperação de Backup do Azure.
    • Os limites de subscrição restringem o número de cofres dos Serviços de Recuperação e o tamanho de cada cofre.

  • Conectividade de rede se ocorrer um failover:

    • Planejamento de capacidade de largura de banda para o Azure ExpressRoute.
    • Roteamento de tráfego durante uma interrupção regional, zonal ou de rede.

  • Failovers planejados e não planejados:

    • Requisitos de consistência de endereço IP e a necessidade potencial de manter endereços IP após failover e failback.
    • Manutenção dos recursos de DevOps de engenharia.
    • Azure Key Vault DR para chaves de aplicativo, certificados e segredos.

  • Residência de dados:

    • Compreenda as orientações no país/região para residência de dados que especificam se os dados devem ser mantidos dentro das fronteiras nacionais ou regionais. Esta orientação afeta seu design para replicação entre regiões.
    • As regiões do Azure que residem na mesma geografia que o conjunto habilitado podem ajudar com a replicação entre regiões para atender aos requisitos de residência de dados, como requisitos fiscais e de aplicação da lei. Para obter mais informações, consulte Replicação entre regiões do Azure.

Recomendações de design

As seguintes práticas de design oferecem suporte ao BCDR para cargas de trabalho de aplicativos:

  • Utilize o Azure Site Recovery para cenários de DR de VM do Azure para Azure.

    O Site Recovery usa replicação em tempo real e automação de recuperação para replicar cargas de trabalho entre regiões. Os recursos de plataforma integrados para cargas de trabalho de VM atendem aos baixos requisitos de RPO e RTO. Você pode usar o Site Recovery para executar exercícios de recuperação sem afetar as cargas de trabalho de produção. Você também pode usar a Política do Azure para habilitar a replicação e auditar a proteção de VM.

  • Use recursos nativos de PaaS DR.

    Os recursos de PaaS integrados simplificam a automação de projeto e implantação para replicação e failover em arquiteturas de carga de trabalho. As organizações que definem padrões de serviço também podem auditar e impor a configuração do serviço por meio da Política do Azure.

  • Use os recursos de backup nativos do Azure.

    O Backup do Azure e os recursos de backup nativos de PaaS eliminam a necessidade de software e infraestrutura de backup de terceiros. Tal como acontece com outras funcionalidades nativas, pode definir, auditar e impor configurações de cópia de segurança com a Política do Azure para garantir a conformidade com os requisitos da organização.

  • Use várias regiões e locais de emparelhamento para conectividade de Rota Expressa.

    Uma arquitetura de rede híbrida redundante pode ajudar a garantir conectividade ininterrupta entre locais se uma interrupção afetar uma região do Azure ou um local de provedor de emparelhamento.

  • Evite usar intervalos de endereços IP sobrepostos em redes de produção e DR.

    As redes de produção e DR com endereços IP sobrepostos exigem um processo de failover que pode complicar e atrasar o failover do aplicativo. Quando possível, planeje uma arquitetura de rede BCDR que forneça conectividade simultânea a todos os sites.