Compartilhar via

Continuidade dos negócios e recuperação de desastres

  • Artigo

As cargas de trabalho de aplicativos empresariais e da organização têm requisitos de RTO (objetivo de tempo de recuperação) e RPO (objetivo de ponto de recuperação). O design eficaz de BCDR (continuidade dos negócios e recuperação de desastre) fornece recursos de nível de plataforma que atendem a esses requisitos. Para criar recursos de BCDR, capture os requisitos de DR (recuperação de desastre da plataforma).

Considerações sobre o design

Considere os seguintes fatores ao criar BCDR para cargas de trabalho de aplicativo:

  • 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 PaaS (plataforma como serviço):

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

  • Suporte para implantações de várias regiões para failover, com proximidade de componente para desempenho.

  • Operações do aplicativo 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.
    • Zonas de Disponibilidade em comparação com os conjuntos de disponibilidade, impacto nos domínios de atualização.
    • Porcentagem de cargas de trabalho que podem estar em manutenção simultaneamente.
    • Suporte de Zonas de Disponibilidade para SKUs (unidades de manutenção de ações) de VM (máquina virtual) específicas. Por exemplo, o Amazenamento de Disco Ultra requer o uso de Zonas de Disponibilidade.

  • Backups consistentes para aplicativos e dados:

    • Instantâneos da VM.
    • Cofres dos Serviços de Recuperação do Backup do Azure.
    • Limites de assinatura restringindo o número de cofres de 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:

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

  • Residência de dados:

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

Recomendações sobre design

As práticas de design a seguir dão suporte a BCDR para cargas de trabalho de aplicativo:

  • Use o Azure Site Recovery para cenários de DR de VM do Azure para o 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 internos da plataforma para cargas de trabalho de VM atendem aos requisitos de RPO e RTO baixos. Você pode usar o Site Recovery para executar as análises de recuperação sem afetar as cargas de trabalho de produção. Você também pode usar a Azure Policy para habilitar a replicação e auditar a proteção da VM.

  • Use recursos de DR de PaaS nativos.

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

  • Use os recursos de backup nativo do Azure.

    Os recursos de backup do Backup do Azure e nativos do PaaS eliminam a necessidade de software e infraestrutura de backup de terceiros. Assim como acontece com outros recursos nativos, você pode definir, auditar e impor configurações de backup com a Azure Policy a fim de garantir conformidade com os requisitos da organização.

  • Use várias regiões e locais de emparelhamento para a conectividade do ExpressRoute.

    Uma arquitetura de rede híbrida redundante pode ajudar a garantir a conectividade inter-local ininterrupta se ocorrer uma interrupção que afete uma região do Azure ou local do provedor de emparelhamento.

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

    As redes de produção e de recuperação de desastres que têm endereços IP sobrepostos exigem um processo de failover que pode complicar e atrasar o failover de aplicativos. Quando possível, planeje uma arquitetura de rede de BCDR que forneça conectividade simultânea a todos os sites.