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 localização geográfica (uma grande área como um continente ou país) ou várias regiões em várias regiões. 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 perto dos usuários.
Ao considerar se uma implantação multirregional é adequada para você, é necessário avaliar a criticidade do seu aplicativo e como isso se corresponde aos diferentes requisitos de RTO/RPO. A resiliência existe em um espectro que vai do tempo de inatividade zero com uma implantação multirregional a agendamentos de backup variados em uma implantação de região única. A desvantagem é o aumento do custo em troca de mais 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 alcançar a recuperação quase instantânea em caso de uma interrupção regional, recomendamos uma arquitetura que consista em um mínimo de 5 nós distribuídos por 3 regiões. Esta arquitetura garante que as operações regulares de manutenção possam ocorrer sem forçar o failover para uma segunda região, enquanto também garante o failover automatizado e a proteção contra perda de dados em um incidente 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 a sua empresa estiver limitada a apenas 2 regiões, você pode usar uma variação da arquitetura de 5 nós e 3 regiões, na qual você tem 5 nós distribuídos entre duas regiões. A região primária possui 2 nós elegíveis, enquanto a região secundária possui 1 nó elegível e 2 nós somente leitura (sem direito a voto).
Em geral, isso não é recomendado se você puder usar regiões 3 porque o operador deve intervir manualmente para fazer o failover se a região majoritária falhar. No entanto, é uma opção para clientes com apenas 2 regiões aprovadas.
Notas e considerações
Esta arquitetura oferece maior proteção contra perda de dados. Se a região minoritária 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 majoritária for perdida, o sistema permanecerá disponível no modo somente leitura até que a maioria dos nós seja colocada em um estado elegível. No entanto, ele pode não oferecer 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. Neste caso, os dados não estarão disponíveis até que a região primária seja recuperada.
Esta arquitetura apresenta 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 somente leitura para nós elegíveis. No entanto, é possível que haja perda de dados. Durante a interrupção, quaisquer novas gravações nos secundários são colocadas em uma coleção especial para recuperação manual. No entanto, todas as gravações no nó primário que não foram replicadas para pelo menos um nó secundário antes da queda do nó primário serão perdidas. Para saber mais, consulte Reconfigurar um conjunto de réplicas durante uma interrupção regional ou use o parâmetro de API acceptDataRisksAndForceReplicaSetReconfig.
Em clusters fragmentados, se o seu processo MongoDB não replicou as migrações de partes, a inconsistência de dados pode 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)
Para volumes de trabalho menos críticos que podem tolerar interrupções, você pode aproveitar uma arquitetura mais menos dispendiosa usando o nó do 1 em cada uma das regiões do 3. 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. Além disso, não haverá a capacidade de executar uma sincronização inicial otimizada no caso de reconstruir um nó.
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 implantações multirregionais
Para aprender a configurar implantações multirregionais e aprender sobre os diferentes tipos de nós que você pode adicionar, consulte Configurar alta disponibilidade e isolamento de carga de trabalho na documentação do Atlas.
Se seu aplicação estiver implantado em um dos seguintes provedores de nuvem, o MongoDB recomenda fortemente que você distribua seus recursos do Atlas para o mesmo provedor e região. Além disso, sugerimos que você mapeie a implantação de seus recursos de aplicação entre regiões para a implantação de seus recursos do Atlas , conforme mostrado abaixo.
Implantação dos recursos do aplicação junto com os recursos do Atlas :
Reduz a latência para operações de banco de dados executadas por seu aplicação.
Permite maior segurança com endpoints privados que conectam seus recursos de nuvem autogerenciados aos recursos do Atlas . Os endpoints privados oferecem o melhor nível de segurança de rede, garantindo que o tráfego só possa ser iniciado a partir da sua conta.
Permite um controle mais granular sobre o armazenamento de dados específicos da região.
Permite que você redirecione o tráfego para regiões saudáveis caso ocorra uma interrupção em outro lugar.
Para saber mais sobre recomendações de aplicação e sistemas do Atlas , consulte:
Considerações
O Azure suporta links privados entre regiões.
Você pode criar um link entre várias regiões sem a necessidade de recursos de rede adicionais que, de outra forma, seriam necessários.
Por exemplo, se seu aplicação estiver implantado em
central-usewest-us-3, e seu Atlas cluster estiver implantado emwest-us-3eeast-us-2, você poderá criar um endpoint privado emcentral-usque se vincula ao link privado emwest-us-3.
Considerações
O uso do Private Service Connect pode aumentar os intervalos de IP necessários para a rede, o que pode ser necessário, pois o GCP não usa roteamento baseado em Porta.
O Private Service Connect é uma ferramenta global, portanto, não há necessidade de criar pares de VPC nas regiões do GCP, como é exigido no Azure ou no AWS.
Para encontrar recomendações para suas implantações na 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