Confiabilidade no Azure Cosmos DB para MongoDB vCore

APLICA-SE A: MongoDB vCore

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

Para obter uma visão geral da arquitetura da confiabilidade no Azure, consulte Confiabilidade do Azure.

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas 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 é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.

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

Para obter suporte à zona de disponibilidade, você deve habilitar Alta disponibilidade (HA).

A HA evita o tempo de inatividade do banco de dados mantendo réplicas em espera de cada fragmento em um cluster. Se um fragmento cair, o Azure Cosmos DB para MongoDB vCore alternará as conexões de entrada do fragmento com falha para sua réplica em espera.

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

Se o HA estiver desabilitado, cada fragmento terá seu próprio LRS (armazenamento com redundância local) com três réplicas síncronas mantidas pelo serviço de Armazenamento do Azure. Se houver uma única falha de réplica, o serviço de Armazenamento do Azure detetará a falha e recriará os dados relevantes de forma transparente. Para a durabilidade do armazenamento LRS, consulte Resumo das opções de redundância. No entanto, no caso de uma falha de região, você corre o risco de tempo de inatividade extenso e possível perda de dados.

Criar um recurso com zonas de disponibilidade ativadas

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

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

A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Quando se trata de 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 da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.

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

Recuperação de desastres em geografia de uma única região

Para maximizar seu 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 para 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 para MongoDB vCore faz backups automaticamente de seus dados em intervalos regulares. As cópias de segurança automáticas são feitas sem afetar o desempenho ou a disponibilidade das operações da base de dados. Todos os backups são realizados 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 em que você exclui ou modifica recursos acidentalmente e depois requer as versões originais.

Os backups automáticos são mantidos em vários intervalos com base no fato de o cluster estar ativo no momento ou ter sido excluído recentemente.

Criar para elevada disponibilidade

A alta disponibilidade (HA) deve ser habilitada para clusters críticos do Azure Cosmos DB para 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 espera ativa provisionado em outra zona de disponibilidade. A replicação entre o estilhaço primário e o secundário é síncrona por padrão. Qualquer modificação no banco de dados é mantida nos fragmentos primário e secundário (espera ativa) 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 é automaticamente promovido para se tornar o novo primário e um fragmento secundário subsequente é construído 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 acionar um failover do fragmento primário para o secundário, as conexões serão roteadas diretamente 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 haja perda de dados se houver um failover.

Próximos passos

• Leia mais sobre a compatibilidade de recursos com o MongoDB.
• Opções de revisão para migrar do MongoDB para o Azure Cosmos DB para MongoDB vCore
• Comece criando uma conta.