Cluster global multinuvem do Atlas: sempre disponível, até se o mundo acabar
Avalie esse Artigo
Nos últimos anos, " high availability " tem sido um chavão em TI. Usar essa frase geralmente significa ter seus aplicativos e serviços resilientes a quaisquer interrupções, tanto quanto possível.
Como fornecedores, temos que garantir certos níveis de tempo de atividade por meio de contratos de SLA, pois manter a alta disponibilidade é crucial para nossos clientes. Hoje em dia, o tempo de inatividade, mesmo por um curto período de tempo, é amplamente inaceitável.
MongoDB Atlas, nossa plataforma de dados como serviço, tem a solução certa para você!
Se você ainda não configurou seu cluster gratuito no MongoDB Atlas, agora é um ótimo momento para fazer isso. Você tem todas as instruções nesta publicação no blog.
O MongoDB Atlas oferece uma maneira muito simples e flexível de implantar um banco de dados global na forma de um Global Sharded Cluster. Essencialmente, você pode criar zonas em todo o mundo onde cada uma terá um fragmento, essencialmente um conjunto de réplicas. Isso permite que você leia e grave dados pertencentes a cada região a partir de seus fragmentos locais.
Para melhorar a estabilidade e a sobrecarga de nossa rede, o Atlas fornece um botão "Leituras locais em todas as zonas". Ele direciona o Atlas para associar automaticamente pelo menos um secundário de cada fragmento a uma das outras regiões. Com uma preferência de leituraapropriada, nosso aplicativo agora poderá obter dados de todas as regiões sem a necessidade de consultá-los entre regiões. Consulte nossas tags de conjunto de réplicas do Atlas para entender melhor como direcionar nós locais ou nós de nuvem específicos.
MongoDB 4.4 introduziu outro recurso interessante em torno das preferências de leitura para clusters fragmentados, chamado Hedged Reads. Uma consulta de leitura coberta é executada em dois secundários para cada fragmento e retorna a resposta mais rápida. Isso pode nos permitir obter uma resposta rápida, mesmo que seja atendida por um membro diferente da cloud. Como esse recurso é permitido para preferências de leitura
non-Primary(como nearest), ele deve ser considerado eventualmente consistente. Isso deve ser levado em consideração com suas considerações de consistência.Uma das inovações mais recentes apresentadas pelo serviço Atlas é a capacidade de executar uma implantação em fornecedores de nuvem (AWS, Azure e GCP). Esse recurso agora está disponível também nas configurações de Global Clusters.
Agora podemos ter shards abrangendo várias nuvens e regiões, em um cluster, com uma connection string unificada. Devido à marcação inteligente do conjunto de réplicas e dos hosts, podemos ter serviços funcionando isoladamente em uma única nuvem ou nos beneficiar de sermos independentes da nuvem.
Para saber mais sobre clusters multinuvem, sugerimos que você leia um ótimo blog post, Crie um cluster multinuvem com o MongoDB Atlas, escrito pela minha colega Adrienha Tacke.
Quando você configura um Cluster Global, a forma como ele é configurado altera os recursos de disponibilidade. Ao configurar o cluster, você pode ver imediatamente como sua configuração atende aos requisitos de resiliência, HA e desempenho. É um recurso incrível! Vamos mergulhar no conjunto completo:
| Capacidade | Descrição | Recurso que cobre o assunto |
|---|---|---|
Leituras e gravações de baixa latência em <SHARD REGION> | Ter um Primary em cada região nos permite consultar/gravar dados dentro da região. | Definir uma zona em uma região abrange essa capacidade. |
| Leituras locais em todas as zonas | Se quisermos consultar um nó local para obter dados de outra zona (por exemplo, na América, consultar documentos da Europa), precisaremos permitir que cada outra zona coloque pelo menos um secundário na região local (por exemplo, o fragmento da Europa terá um secundário na região da América). Isso exige que nossas leituras usem um readPreferencebaseado em latência, como nearest ou hedged. Se não tivermos um nó local, precisaremos buscar os dados remotamente. | Pressionar o botão " Permitir leituras locais em todas as zonas " colocará um secundário em cada outra zona. |
| Disponível durante interrupção parcial da região | Caso haja uma interrupção da "zona de disponibilidade" da nuvem em uma região específica, as regiões com mais de uma zona de disponibilidade permitirão que a região ainda funcione normalmente. | Ter a região preferida da zona com vários nós elegíveis abrangendo duas ou mais zonas de disponibilidade do provedor de nuvem para resistir a uma interrupção na zona de disponibilidade. Essas regiões serão marcadas com uma estrela na interface do usuário. Por exemplo: dois nós no AWS N. Virginia onde cada um é, por design, implantado em três zonas de disponibilidade possíveis. |
| Disponível durante a interrupção total da região | Caso haja uma interrupção completa da região de nuvem, precisamos ter a maioria dos nós fora dessa região para manter um primário dentro do | Ter a maioria dos nós "elegíveis" fora da região da zona . Por exemplo: dois nós em N. Virginia, dois nós em N. California e um nó na Irlanda |
| Disponível durante a interrupção total do fornecedor de nuvem | Se um provedor de nuvem inteiro não estiver disponível, as zonas ainda terão a maioria dos nós elegíveis em outros provedores de nuvem e, portanto, as zonas não dependerão de um provedor de nuvem. | Ter nós de várias nuvens em todas as três nuvens permitirá que você resista a uma falha completa do provedor de nuvem. Por exemplo: dois nós no AWS N.Virginia, dois nós no GCP Frankfurt e um nó no Azure London. |
Depois de implantarmos nosso cluster, agora temos um cluster totalmente global entre regiões, entre nuvens e tolerante a falhas com baixas latências de leitura e gravação em todo o mundo. Tudo isso é acessado por meio de uma connection string SRV simples e unificada:
Esse cluster vem com um backup completo e uma opção de restauração pontual, caso algo realmente ruim aconteça (como erros humanos ...).
Acho que nosso aplicativo não tem nada a temer, a não ser seus próprios bugs.
Para mostrar como é fácil manipular essa implantação complexa, eu fiz um YouTub:
Para saber mais sobre como implantar um cluster global entre regiões para cobrir todas as nossas práticas recomendadas de tolerância a falhas, confira o vídeo.
Cobrir a demanda e a escala globais de nossos aplicativos nunca foi tão fácil, mantendo a maior disponibilidade e resiliência possíveis. Clusters globais de várias nuvens permitem que a TI durma bem à noite sabendo que seus dados estão sempre disponíveis, mesmo no apocalipse!
Se tiver dúvidas, acesse o site da nossa comunidade de desenvolvedores, no qual os engenheiros e a comunidade do MongoDB ajudarão você a desenvolver sua próxima grande ideia com o MongoDB.