Sistemas do Atlas multirregionais são clusters configurados em mais de uma região. Uma implantação de multirregional pode ter várias regiões dentro da mesma localidade geográfica (uma grande área como um continente ou país) ou várias regiões em várias localidades geográficas. Implementações de múltiplas regiões:
Melhore a proteção no caso de uma interrupção regional redirecionando automaticamente o tráfego para outra região para garantir a disponibilidade contínua e uma experiência de usuário tranquila.
Melhore o desempenho e a disponibilidade de alguns aplicativos localizando os dados mais próximos dos usuários.
Ao considerar se uma implantação de multirregional é ideal para você, você deve avaliar a criticidade de seu aplicação e como isso corresponde a diferentes requisitos de RTO/RPO. A resiliência existe em um intervalo entre zero tempo de inatividade com um sistema de multirregional até agendamentos de backup variáveis em um sistema de uma única região. A compensação é o aumento do custo por maior disponibilidade.
Consulte a seção Confiabilidade para obter mais orientações sobre se uma implantação de multirregional é adequada para seu volume de trabalho.
Observação
Os sistemas de várias regiões estão disponíveis somente para clusters dedicados M10 e maiores.
Estratégias de implantação de várias regiões
O diagrama seguinte mostra exemplos do 2 de uma topologia do 2+2+1 , que é discutido em detalhes abaixo. Ela mostra um único cluster com 5 nós em 3 regiões diferentes: 2 nós em US1, 2 em US2 e 1 em US3.
5-Nó, 3-Região Arquitetura (2+2+1)
Para obter uma recuperação quase instantânea no caso de uma interrupção regional, recomendamos uma arquitetura que consista em um mínimo de 5 nós distribuídos em 3 regiões. Essa arquitetura garante que as operações de manutenção regulares possam ocorrer sem forçar o failover para uma segunda região, ao mesmo tempo em que garante failover automatizado e proteção contra perda de dados em um caso de interrupção regional completa.
O diagrama a seguir mostra detalhes dessa arquitetura:
Notas e considerações
Use endpoints privados para se conectar ao cluster e emparelhamento de VPC entre suas VPCs de servidor de aplicação . O emparelhamento de VPC garante que, se uma conexão de rede for interrompida ou o Atlas nessa região ficar inativo, a camada do aplicação ainda poderá ser roteada para o nó primário, primeiro por meio do emparelhamento de VPC e, em seguida, pelo endpoint privado.
Essa arquitetura tem o custo mais alto devido ao tráfego de rede entre regiões e ter 5 ou mais nós portadores de dados.
Essa arquitetura fornece a mais alta resiliência. Não há interrupções durante as operações do Atlas (como uma atualização automatizada), e seu aplicação pode suportar uma falha regional completa sem interrupção e intervenção manual necessária.
Essa arquitetura tem o custo mais alto devido ao tráfego de rede entre regiões e ter 5 ou mais nós portadores de dados.
5-Nó, 2-Região Arquitetura (2+3)
Se sua empresa estiver limitada a apenas 2 regiões, você poderá usar uma variação na arquitetura 5-Nó, 3-Região, na qual você tem 5 nós distribuídos entre duas regiões. A região primária tem 2 nós elegíveis e a região secundária tem 1 nó elegível e 2 nós read-only (não votantes).
Isso geralmente não é recomendado se você puder usar regiões 3 . No entanto, é uma boa opção para clientes com apenas 2 regiões aprovadas.
Notas e considerações
Essa arquitetura oferece maior proteção contra perda de dados. Se a região minoria for perdida, nenhuma ação do usuário será necessária porque a região majoritária continua sendo um cluster totalmente funcional. Se a região da maioria for perdida, o sistema ainda permanecerá disponível no modo somente leitura até que a maioria dos nós seja trazida para um estado elegível. No entanto, ele pode não fornecer proteção completa contra perda de dados se alguns dados ainda não tiverem sido replicados para um nó secundário após uma falha. Nesse caso, esses dados estarão indisponíveis até que a região primária seja recuperada.
Essa arquitetura vem com algumas ressalvas:
Se a região majoritária for perdida, a região majoritária não será um cluster totalmente funcional; ele não tem um primário e só pode aceitar leituras, mas não escritas.
Como não há uma maioria dos nós votantes, ele não tem um primary e só pode aceitar leituras (não gravações).
Para restaurar o cluster funcional, um administrador precisa reconfigurar os 2 nós read-only em nós elegíveis. No entanto, a perda de dados é possível. Durante a interrupção, quaisquer novas gravações em secundários são colocadas em uma coleção especial para recuperação manual. No entanto, todas as gravações no primário que não foram replicadas em pelo menos um nó secundário antes da queda do primário são perdidas. Para saber mais, consulte Reconfigurar um conjunto de réplicas durante uma interrupção regional ou use o parâmetro acceptDataRisksAndForceReplicaSetReconfig.
Em clusters fragmentados, se o processo do MongoDB não tiver replicado migrações em partes, a inconsistência de dados poderá causar documentos órfãos.
Variação de menor custo
Para reduzir ainda mais os custos, você pode projetar essa arquitetura sem os nós somente leitura 2 . Além das advertências listadas acima, o tamanho dos dados tem um impacto significativo em sua decisão, pois os dados precisam ser sincronizados com secundários sempre que adicionar novos nós ao cluster. Por exemplo, 1 TB de dados médias de 1 hora de recuperação e tempo de sincronização. Recomendamos ter 2 nós somente leitura na região menor porque eles já estão totalmente sincronizados, e a recuperação para um cluster totalmente funcional leva apenas segundos a minutos.
3-Nó, 3-Região Arquitetura (1+1+1)
Se o custo de implantação for um fator mais importante do que a disponibilidade ou a latência, você poderá criar uma arquitetura mais barata usando 1 nó em cada uma das 3 regiões . Você tem um nó elegível em cada uma das regiões, o que significa que, se o nó primary não estiver disponível, seu cluster fará failover para uma nova região para garantir a disponibilidade contínua. No entanto, se a camada do aplicativo na região primária original ainda estiver atendendo às solicitações dos usuários, haverá um aumento da latência à medida que as solicitações forem roteadas para várias regiões.
Observação
Geralmente, não recomendamos esta configuração porque a manutenção regular e planejada dos nós do Atlas causará picos de latência temporários.
Recomendações para sistemas de várias regiões
Para saber como configurar sistemas de multirregional e saber mais sobre os diferentes tipos de nós que você pode adicionar, consulte Configurar isolamento de alta disponibilidade e carga de trabalho na documentação do Atlas .
Para encontrar recomendações para suas implantações de nuvem do Atlas , consulte os seguintes recursos:
Recomendações para organizações, projetos e clusters do Atlas
Eficiência Operacional
Segurança
Reliability
Desempenho
Otimização de custos