Disponibilidade (confiabilidade) e recuperação de desastre (DR) no Azure Cosmos DB for MongoDB vCore: Bastidores
APLICA-SE AO: 
MongoDB vCore
Este artigo aborda os internos de alta disponibilidade (HA) e recuperação de desastres entre regiões (DR) do Azure Cosmos DB for MongoDB vCore, delineando o design e os recursos desses recursos. Ele fornece insights para um planejamento eficaz de estratégia entre regiões e regiões para garantir a confiabilidade e a continuidade dos negócios.
Anatomia do cluster vCore do Azure Cosmos DB for MongoDB
Um cluster vCore do Azure Cosmos DB for MongoDB consiste em um ou mais fragmentos físicos (nós). Cada fragmento físico inclui um nó de computação dedicado e um armazenamento SSD premium remoto. Os recursos de computação e armazenamento de um fragmento físico são exclusivos para um único banco de dados e não compartilhados entre clusters ou bancos de dados.
Em clusters com vários fragmentos, cada fragmento tem uma configuração de computação e armazenamento idêntica. Independentemente do número de fragmentos, todos os recursos de cluster são hospedados na mesma região do Azure.
O Azure Cosmos DB for MongoDB vCore usa LRS (armazenamento com redundância local), garantindo que todos os dados sejam replicados de forma síncrona três vezes dentro do local físico do cluster. O Armazenamento do Microsoft Azure gerencia essas réplicas de forma transparente, verifica a integridade dos dados usando CRCs (verificações de redundância cíclica) e repara qualquer corrupção detectada usando dados redundantes. Além disso, as somas de verificação são aplicadas ao tráfego de rede para evitar a corrupção de dados durante o armazenamento e a recuperação.
Figure 1. Componentes do cluster vCore do Azure Cosmos DB for MongoDB.
Se o aplicativo se conecta a um único cluster fragmentado ou multisshard, ele usa uma única cadeia de conexão e um ponto de extremidade. Essa abstração simplifica as operações de banco de dados distribuído, tornando tão simples se conectar a uma configuração de vários fragmentos quanto a um banco de dados MongoDB autônomo.
ALTA disponibilidade (HA) na região
Para cargas de trabalho de produção, é altamente recomendável habilitar a alta disponibilidade (HA) na região para atender aos padrões de confiabilidade modernos. Embora a HA possa ser desabilitada para desenvolvimento ou clusters experimentais para reduzir custos, é essencial para manter a disponibilidade do banco de dados em produção.
A HA pode ser alternada durante o provisionamento de cluster ou a qualquer momento após a criação do cluster. Ele está disponível em todas as regiões do Azure que dão suporte ao Azure Cosmos DB for MongoDB vCore, independentemente de recursos regionais específicos.
Quando a HA está habilitada, cada fragmento físico primário no cluster é emparelhado com um fragmento em espera. O fragmento em espera espelha a configuração de computação e armazenamento de seu equivalente primário. Isso resulta em seis réplicas de dados por fragmento— três no fragmento primário e três em espera. Em regiões com AZs (zonas de disponibilidade), fragmentos primários e em espera são implantados em zonas separadas.
Os dados são replicados de forma síncrona entre cada fragmento primário e em espera. As gravações são reconhecidas somente após serem confirmadas com êxito em ambos os fragmentos, garantindo uma consistência forte dentro do cluster de HA. Em outras palavras, um fragmento físico em espera é uma réplica completa sempre atualizada de seu fragmento físico primário, fornecendo consistência forte dentro do cluster altamente disponível.
Figura 2. Cluster vCore do Azure Cosmos DB for MongoDB com e sem HA (alta disponibilidade) na região habilitado.
No caso de uma falha de fragmento primário, o serviço executa automaticamente um failover para seu fragmento em espera. Durante o failover, todas as solicitações de leitura e gravação são redirecionadas para o fragmento em espera, que se torna o novo primário. As operações de gravação em andamento durante o failover são repetidas dentro do serviço para garantir a continuidade. Um fragmento de substituição é criado para restabelecer a replicação síncrona, tornando-se o novo em espera.
Replicação entre regiões: recuperação de desastre regional (DR)
Embora raras, interrupções regionais podem interromper o acesso ao banco de dados. A replicação entre regiões fornece uma estratégia robusta de recuperação de desastre (DR), garantindo o acesso aos seus dados mesmo durante interrupções em larga escala.
Com a replicação entre regiões, você pode criar um cluster de réplica em uma região diferente do Azure. Cada fragmento no cluster de réplica replica de forma assíncrona os dados de seu equivalente no cluster primário. Esse modelo de replicação garante uma consistência eventual minimizando o impacto no desempenho no cluster primário.
A replicação assíncrona evita a necessidade de cada operação de gravação ser entregue imediatamente e confirmada por réplicas antes que uma confirmação de "gravação concluída" seja enviada de volta ao aplicativo. No entanto, isso significa que algumas gravações concluídas no cluster primário ainda podem não ser replicadas para o cluster de réplica, resultando em retardo de replicação. A extensão do atraso de replicação depende da intensidade das operações de gravação no cluster primário e da carga geral nos clusters primário e de réplica.
Nesta configuração:
- O cluster primário na Região A manipula todas as leituras e gravações.
- O cluster de réplica na Região B dá suporte ao acesso somente leitura, permitindo operações de leitura de alto desempenho mais próximas de aplicativos ou usuários nessa região.
Os aplicativos podem executar consultas OLTP no cluster primário na região A e operações de leitura intensas, como consultas OLAP/reporting, podem ser apontadas para o cluster de réplica na região B.
Os aplicativos podem usar uma cadeia de conexão de leitura e gravação global dinâmica, que sempre aponta para o cluster aberto para gravações. Durante uma interrupção regional, o cluster de réplica na Região B pode ser promovido para aceitar gravações. A cadeia de conexão global é atualizada automaticamente para apontar para o cluster promovido, garantindo operações de gravação ininterruptas.
Figura 3. Recuperação de desastre regional (DR) com um cluster vCore do Azure Cosmos DB for MongoDB com replicação entre regiões habilitada. O cluster na região B é promovido para se tornar o novo cluster de leitura/gravação. O cluster na região A se torna um cluster de réplica.
Resumo da disponibilidade na região e dos recursos de DR entre regiões
A tabela a seguir resume as principais considerações para habilitar e gerenciar a alta disponibilidade na região e a estratégia de recuperação de desastre entre regiões.
| Cenário | Recurso do Azure Cosmos DB for MongoDB vCore | Sem perda de dados | Proteção contra interrupções em toda a região | Failover automático | Nenhuma alteração de cadeia de conexão |
|---|---|---|---|---|---|
| Falha de fragmento físico | Alta disponibilidade (HA) na região | ✔️ | ❌ | ✔️ | ✔️ |
| Interrupção regional | Cluster de réplica entre regiões | ❌ | ✔️ | ❌ | ✔️† |
† Ao usar a cadeia de conexão de leitura/gravação global.