Continuidade dos negócios e recuperação de desastres para análises em escala de nuvem

Ao projetar a arquitetura de um serviço de nuvem, considere seus requisitos de disponibilidade e como responder a possíveis interrupções no serviço. Um problema pode ser localizado para a instância específica ou para toda a região. Ter planos para ambos é importante. Dependendo seu objetivo de tempo de recuperação e o objetivo de ponto de recuperação, você poderá escolher uma estratégia agressiva para alta disponibilidade e recuperação de desastre.

A alta disponibilidade e a recuperação de desastre às vezes podem ser combinadas. As duas áreas têm estratégias um pouco diferentes, especialmente quando se trata de dados. Para saber mais, confira o Microsoft Azure Well-Architected Framework e seus princípios de confiabilidade.

Em vez de tentar evitar falhas, aceite antecipadamente que as falhas podem e acontecem. Minimize os efeitos de qualquer componente com falha no ciclo de vida. Sua tolerância de custo, objetivo de ponto de recuperação e objetivo de tempo de recuperação determinam o tipo de solução a ser implementada.

Estratégias de backup

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

• Backup e restauração: restaure o aplicativo de banco de dados da última cópia de backup antes do desastre. Essa abordagem é comumente usada após dados corrompidos ou exclusão acidental.

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

• Reposição aquecida (ativo/passivo): crie um serviço hospedado secundário em uma região alternativa. Implante funções para garantir a capacidade mínima. 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): projete o aplicativo para receber a carga de produção em várias regiões. É possível configurar os nuvem em cada região para capacidade maior do que o necessário para fins de recuperação de desastre. Em vez disso, é possível escalar horizontalmente os serviços de nuvem conforme o necessário no momento de um desastre e failover.

  Essa abordagem requer investimento no design de aplicativos, mas tem benefícios. Ele oferece tempo de recuperação baixo e garantido. Há testes contínuos de todos os locais de recuperação e uso eficiente da capacidade. Para aplicativos de banco de dados, essa abordagem inclui um balanceador de carga para dois bancos de dados que são sincronizados com um único ponto de conexão.

Recuperação de desastre e alta disponibilidade para serviços do Azure

As seções a seguir discutem os diferentes serviços do Azure.

Azure Cosmos DB

Para obter uma visão geral de alta disponibilidade com Azure Cosmos DB, consulte Como o Azure Cosmos DB fornece alta disponibilidade.

Fábrica de dados do Azure

As integrações de dados e o produto de dados provavelmente terão repositórios do Azure DevOps vinculados ao Azure Data Factory. É possível implantar pipelines em outro Data Factory com tempo de inatividade mínimo. Para usar o software de controle de versão de código além do repositório GitHub e Azure DevOps, use o SDK do Azure Data Factory para criar pipelines e outros objetos do Azure Data Factory.

Azure Data Lake

O Azure Data Lake Storage Gen2 já dá suporte à replicação de três vezes para oferecer proteção contra falhas de hardware localizadas. Outras opções de replicação, como o ZRS (armazenamento com redundância de zona) ou o GZRS (armazenamento com redundância de zona geográfica), melhoram a alta disponibilidade. O GRS (armazenamento com redundância geográfica) e o RA-GRS (armazenamento com redundância geográfica com acesso de leitura) melhoram a recuperação de desastres. Para alta disponibilidade, se houver uma interrupção de serviço, a carga de trabalho precisará de acesso aos dados mais recentes o mais rápido possível. A carga de trabalho pode alternar para uma instância replicada localmente ou para uma nova região.

Uma conta de armazenamento configurada como RA-GRS ou GRS pode fazer parte de um plano de recuperação de desastres, mas requer a diligência prévia por meio da análise de RPO (objetivo de ponto de recuperação) e de RTO (objetivo de tempo de recuperação) e da revisão de outras opções, como um cenário de carga dupla que copia dados em duas regiões diferentes do Azure.

Cada zona de destino de dados deve ter um objetivo de ponto de recuperação para os produtos de dados associados. Cada zona de destino de dados deve ter uma estratégia de replicação definida para seus casos de uso.

Observação

O failover de conta gerenciado pelo cliente ainda não tem suporte em contas que têm um namespace hierárquico (Azure Data Lake Storage Gen2).

No caso de um desastre que afete a região primária, a Microsoft gerenciará o failover para contas com um namespace hierárquico.

Para saber mais, confira Recuperação de desastre e failover da conta de armazenamento.

Azure Databricks

Para obter uma visão geral de uma arquitetura de recuperação de desastre para clusters do Azure Databricks, consulte Recuperação de desastre regional para clusters de Azure Databricks.

Azure Machine Learning

Para obter uma visão geral de alta disponibilidade com Azure Machine Learning, consulte Failover para continuidade de negócios e recuperação de desastres.

Cofre de Chave do Azure

O Azure Key Vault fornece vários recursos para ajudar você a manter a disponibilidade e evitar a perda de dados. Faça backup dos segredos somente se você tiver uma justificativa comercial crítica. O backup de segredos no cofre de chaves pode introduzir desafios operacionais, como a manutenção de vários conjuntos de logs, permissões e backups quando os segredos expiram ou são girados. Para saber mais, veja Backup do Azure Key Vault.

O Key Vault mantém a disponibilidade em cenários de desastre. Ele faz failover de solicitações para uma região emparelhada sem nenhuma intervenção de um usuário. Para obter mais informações, confira Disponibilidade e redundância do Azure Key Vault. Como alternativa, é possível considerar armazenar segredos e outros artefatos do Key Vault em um cofre secundário com as permissões apropriadas. Esse padrão pode ser adequado para aplicativos que exigem que o cofre esteja na mesma região que o aplicativo.

Banco de Dados SQL do Azure

Para obter uma visão geral da continuidade dos negócios com o Banco de Dados SQL do Azure, consulte Visão geral da continuidade dos negócios com Banco de Dados SQL do Azure.

Azure Synapse Analytics

Para obter uma visão geral da continuidade dos negócios com o Azure Synapse Analytics, consulte Alta disponibilidade para o Azure Synapse Analytics.

Próximas etapas

• Visão geral de governança de dados