Compartilhar via

Confiabilidade no Azure Cosmos DB for MongoDB vCore

  • Artigo

APLICA-SE AO: MongoDB vCore

Este artigo contém informações detalhadas sobre resiliência regional com zonas de disponibilidade e recuperação de desastre entre regiões e continuidade de negócios no Azure Cosmos DB for MongoDB vCore.

Para ter uma visão geral arquitetônica da confiabilidade no Azure, confira Confiabilidade do Azure.

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas duas zonas restantes.

As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões de disponibilidade.

Para obter suporte à zona de disponibilidade, você precisa habilitar a HA (alta disponibilidade).

A HA evita o tempo de inatividade no banco de dados, mantendo réplicas em espera de cada fragmento em um cluster. Se um fragmento falhar, o núcleo virtual do Azure Cosmos DB for MongoDB alterna as conexões de entrada do fragmento que falhou para sua réplica em espera.

Quando a HA está habilitada em uma região que dá suporte a zonas de disponibilidade, os fragmentos de réplica de HA são provisionados em uma zona de disponibilidade diferente dos fragmentos primários. As réplicas de Alta Disponibilidade não recebem solicitações de clientes a menos que seu fragmento principal falhe.

Se a HA está desabilitada, cada fragmento tem um LRS (armazenamento com redundância local) próprio com três réplicas síncronas mantidas pelo serviço do Armazenamento do Microsoft Azure. Se houver uma única falha na réplica, o serviço de Armazenamento do Microsoft Azure detectará a falha, e recria de forma transparente os dados relevantes. Para saber mais sobre a durabilidade do armazenamento LRS, confira Resumo das opções de redundância. No entanto, no caso de uma falha na região, você corre o risco de tempo de inatividade extenso e possível perda de dados.

Criar um recurso com zonas de disponibilidade habilitadas

Para habilitar as zonas de disponibilidade, você precisa habilitar a HA (alta disponibilidade) ao criar um cluster ou na seção Escala de um cluster existente no portal do Azure.

Recuperação de desastre entre regiões e continuidade dos negócios

A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.

Quando o assunto é DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.

O Azure Cosmos DB for MongoDB vCore não fornece failover automático interno ou recuperação de desastre. Planejar a alta disponibilidade é uma etapa crítica à medida que sua solução é dimensionada.

Recuperação de desastre na geografia de região única

Para maximizar o tempo de atividade, planeje com antecedência para manter a continuidade dos negócios e prepare-se para a recuperação de desastres com o Azure Cosmos DB for MongoDB vCore.

Embora os serviços do Azure sejam projetados para maximizar o tempo de atividade, podem ocorrer interrupções de serviço não planejadas. Um plano de recuperação de desastres garante que você tenha uma estratégia em vigor para lidar com interrupções de serviço regionais.

O Azure Cosmos DB for MongoDB vCore faz backups automáticos dos seus dados em intervalos regulares. Os backups automáticos são feitos sem afetar o desempenho ou a disponibilidade das operações do banco de dados. Todos os backups são executados automaticamente em segundo plano e armazenados separadamente dos dados de origem em um serviço de armazenamento. Esses backups automáticos são úteis em cenários quando você exclui ou modifica recursos acidentalmente e, posteriormente, exige as versões originais.

Os backups automáticos são mantidos em vários intervalos com base em se o cluster está ativo ou excluído recentemente.

Período de retenção
Clusters ativos 35 dias
Clusters excluídos 7 dias

Projetando para a alta disponibilidade

A HA (alta disponibilidade) deve ser habilitada para clusters críticos do Azure Cosmos DB for MongoDB vCore que executam cargas de trabalho de produção. Em um cluster habilitado para HA, cada fragmento serve como primário junto com um fragmento de standby ativo provisionado em outra zona de disponibilidade. Por padrão, a replicação entre o fragmento primário e o secundário é síncrona. Qualquer modificação no banco de dados é mantida nos fragmentos primário e secundário (standby ativo) antes que uma resposta do banco de dados seja recebida.

O serviço mantém verificações de integridade e pulsações para cada fragmento primário e secundário do cluster. Se um fragmento primário ficar indisponível devido a uma interrupção regional ou de zona, o fragmento secundário será promovido automaticamente para se tornar o novo primário e um fragmento secundário subsequente será criado para o novo primário. Além disso, se um fragmento secundário ficar indisponível, o serviço criará automaticamente um novo fragmento secundário com uma cópia completa dos dados do primário.

Se o serviço disparar um failover do fragmento primário para o secundário, as conexões serão perfeitamente roteadas sob as coberturas para o novo fragmento primário.

A replicação síncrona entre os fragmentos primário e secundário garante que não haverá perda de dados se houver um failover.

Próximas etapas