Criar um cluster multinuvem com o MongoDB Atlas
Avalie esse Tutorial
Os clusters de várias cloud no MongoDB Atlas agora estão disponíveis ao público em geral! Assim como você pode distribuir seus dados em várias regiões, agora também pode distribuir em vários provedores de cloud. Isso lhe dá muito mais livre e flexibilidade para executar seu aplicativo em qualquer lugar e mover-se em qualquer cloud sem alterar uma única linha de código.
Quer usar o Azure DevOps para integração e implantação contínuas, mas usa o Google Cloud para o vision AI? Possível! Precisa de maior disponibilidade no Canadá, mas apenas uma única região está disponível em seu provedor de nuvem atual? Adicione nós adicionais de outra região canadense em um provedor de nuvem diferente! É para esses tipos de cenário que a multinuvem foi feita!
Neste post, não vou contar por que a multinuvem é útil; existem vários artigos (como este ou aquele) e um stream do Twitch que já fazem um ótimo trabalho nisso! Em vez disso, nesta postagem, gostaria de:
- Mostrar como configurar um cluster multinuvem no MongoDB Atlas.
- Explique o que cada uma das novas opções multinuvem MEAN.
- Reconheça algumas novas considerações que acompanham os recursos multinuvem.
- Responda a algumas perguntas comuns sobre clusters de várias nuvens.
Vamos começar!
Para acompanhar este tutorial, você precisará de:
- Para criar um cluster M10 ou superior (observe que isso não é coberto pelo nível gratuito)
- Selecione a organização e o projeto nos quais você deseja criar um cluster multinuvem. Se você não tiver nenhum dos dois, primeiro crie uma organização e um projeto antes de prosseguir.
- Clique em "Construir um cluster". (Alternativamente, clique em "Criar um novo cluster" no canto superior direito da tela, visível se você tiver pelo menos um outro cluster.)
- Se este for o primeiro cluster do seu projeto, você será solicitado a escolher o tipo de cluster que deseja criar. Selecione "Criar um cluster" para a opção "Clusters dedicados de várias regiões".
- Você será levado à tela "Create a Multi-Region Cluster". Se ainda não estiver na posição ON, alterne a opção "Multi-Cloud, Multi-Region & Workload Isolation":
- Isso expandirá várias outras opções para você configurar. Estas opções determinam o tipo e distribuição de nós em seu cluster:
💡 Qual é a diferença entre clusters "multirregionais" e "multinuvem"?A introdução de capacidades multinuvem no Atlas altera a forma como o Atlas define regiões geográficas para um cluster. Agora, ao fazer referência a um clusterde várias regiões, este pode ser um cluster hospedado em:- mais de uma região dentro de um fornecedor de nuvem, ou
- mais de um provedor de nuvem. (Um cluster que abrange mais de um provedor de nuvem abrange mais de uma região por design.)
- Várias regiões em vários fornecedores de serviços em nuvem.
Como cada fornecedor de serviços em nuvem tem sua própria definição de regiões, os clusters multinuvem também são clusters multirregionais. - Configure seu cluster. Nesta etapa, você escolherá uma combinação de nós Elegíveis, Somente leitura e Analytics que formarão seu cluster.💡 Escolhendo nós para seu cluster multinuvem
- Nós elegíveis: nós candidatos adicionais (via região ou provedor de nuvem) e apenas nós que podem se tornar os primários em caso de falha. Certifique-se de escolher um número ímpar de nós elegíveis totais (mínimo de três); essas distribuições de nósrecomendadas são um bom ponto de partida.
- Nós somente leitura: Ótimo para leituras locais em áreas específicas.
- Nodes de análise: ótimos para isolar cargas de trabalho analíticas de suas cargas de trabalho operacionais principais.
Ainda não consegue tomar uma decisão? Confira as diferenças detalhadas entre os nós Elegível, Somente Leitura e Analítica para obter mais informações!Como exemplo, aqui está minha configuração final (com base na Litoral Oeste, usando uma distribuição de nó elegível 2-2-1 ):
Configurei cinco nós elegíveis nas regiões mais próximas de eu, com uma região do GCP de Playstation 4 como a maior prioridade, pois estou baseado em Las vegas. Como o Azure e o AWS oferecem uma região da Califórnia, as próximas regiões mais próximas disponíveis para eu, as selecionei como as próximas regiões elegíveis. Para acomodar minhas outras áreas de serviço na costa leste, também configurei dois nós somente leitura: um na Virgínia e outro em Illinois. Por fim, para separar minhas queries de relatórios, configurei um nó dedicado como um nó analítico. Escolhi a mesma região do GCP de Las vegas para reduzir a latência e o custo. - Escolha as opções restantes para seu cluster:
- Expanda a seção "Cluster Tier" e selecione a camada "M10" (ou superior, dependendo de suas necessidades).
- Expanda a seção "Configurações adicionais" e selecione "MongoDB 4.4, "que é a versão mais recente a partir deste momento.
- Expanda a seção "Nome do cluster" e escolha um nome de cluster. Este nome não pode ser alterado após a criação do cluster, então escolha cuidadosamente!
- Com todas as opções definidas, clique no botão "Criar cluster". Após uma breve espera, seu cluster multinuvem será criado! Quando estiver pronto, clique no nome do cluster para ver uma visão geral dos nós. Veja como é o meu:
Como você pode ver, a região do GCP de Las vegas foi definida como minha região preferida. Da mesma forma, um dos nós dessa região é definido como meu principal. E, como esperado, os nós read-only e analytics estão definidos para as respectivas regiões que escolhi:
Doce! Você acabou de configurar seu próprio cluster multinuvem. Para testá-lo, você pode continuar na próxima seção, onde trigger manualmente uma eleição e verá seu nó primário restaurado para um provedor de nuvem diferente!. . . . Você acabou de configurar um cluster multinuvem. Se você encontrou este tutorial útil ou apenas deseja compartilhar seu conhecimento recém-adquirido, considere enviar um Tuíte!
Se você estiver criando um cluster multinuvem para garantir maior disponibilidade, talvez esteja se perguntando como testar se ele realmente funcionará se um provedor de nuvem falhar. O Atlas oferece clusters de autorrecuperação, com ferramentas de automação integradas, para garantir que, no caso de uma interrupção do nó primário, seu cluster permaneça on-line enquanto elege um novo nó primário e reinicia um novo nó secundário quando possível. Para testar se um primário está sendo movido para outro provedor de nuvem, siga estas etapas para trigger manualmente uma eleição:
- Na visão geral principal "Clusters" no Atlas, encontre o cluster que você deseja testar. Selecione os três pontos (...) para abrir as opções adicionais do cluster e clique em "Editar configuração":
- Você será direcionado para uma tela de configuração semelhante a quando criou o cluster. Expandir a seção "provedor de serviços em nuvem e região".
- Altere sua região de maior prioridade para uma das regiões de menor prioridade. Por exemplo, minha região de maior prioridade atual é o GCP Las vegas (us-west4). Para alterá-la, arrasto minha região do Azure Califórnia (westus) para o topo, tornando-a a nova região de maior prioridade:
- Clique no botão "Revisar alterações". Você será levado a uma página de resumo onde poderá verificar novamente as alterações que está prestes a fazer:
- Se tudo estiver correto, clique no botão "Aplicar alterações".
- Após uma breve espera para implementar estas alterações, verá que o seu primário foi definido para um nó da sua região e fornecedor de nuvem recém-priorizados. Como você pode ver no meu cluster, meu primary agora está definido como um nó na minha região do Azure (westus):
} No caso de uma interrupção real, o Atlas lida automaticamente com esse processo de failover e eleição para você! Essas etapas estão aqui para que você possa testar um failover manualmente e inspecionar visualmente se seu nó primário foi, de fato, restaurado em um provedor de nuvem diferente.Aqui está! Você criou um cluster de várias nuvens no MongoDB Atlas e até mesmo testou um "failover" manual para um novo fornecedor de nuvem. Agora você pode pegar a connection string do assistente de conexão do seu cluster e usá-la com seu aplicativo.⚡ Exclua seu cluster quando terminar de usá-lo para evitar cobranças adicionais indesejadas. Para excluir um cluster, clique nos três pontos (...) na página de visão geral do cluster do cluster que você deseja excluir e clique em Encerrar. Semelhante ao GitHub, o MongoDB Atlas solicitará que você digite o nome do seu cluster para confirmar que deseja excluí-lo, incluindo todos os dados que estão no cluster!
Esses nós atendem às suas necessidades de disponibilidade, fornecendo nós candidatos adicionais e/ou locais alternativos para seu nó primário. Quando o primário falha, os nós elegíveis reduzem o impacto falhando em um nó alternativo. E quando uma disponibilidade mais ampla é necessária para uma região, para atender a requisitos específicos de soberania de dados, por exemplo, um nó elegível de outro provedor de nuvem e de uma região semelhante pode ajudar a preencher a lacuna.
} Ao configurar nós elegíveis em um cluster multinuvem, tenha em mente o seguinte:
- Os nós elegíveis são os únicos que participam de eleições do conjunto de réplicas.
- Qualquer nó elegível pode se tornar o primário enquanto a maioria dos nós em um conjunto de réplicas permanecer disponível.
- Espalhar seus nós Elegíveis por grandes distâncias pode levar a tempos de eleição mais longos.
Ao selecionar quais provedores de nuvem e regiões hospedarão seus nós elegíveis, observe também a ordem em que eles são colocados. O Atlas prioriza os nós para elegibilidade primária com base em sua ordem na tabela de nós Elegíveis. Isso significa que a primeira linha da tabela de nós elegíveis é definida como a região de prioridade mais alta. O Atlas permite que você saiba disso, pois você verá o emblema "HIGHEST" listado como a prioridade da região.
Se houver vários nós configurados para essa região, eles também terão uma classificação mais alta na elegibilidade primária em relação a qualquer outra região da tabela. As regiões restantes (outras linhas na tabela de nós elegíveis) e seus nós correspondentes são classificados na ordem em que aparecem, com a última linha sendo a região de menor prioridade.
Como exemplo, use esta configuração de nó 2-2-1 :
Quando o Atlas prioriza nós para elegibilidade primária, ele o faz nesta ordem:
Maior prioridade => Nós 1 e 2 na região do Azure California (westus)
Próxima prioridade => Nós 3 e 4 na região do GCP Las Vegas (us-west4)
Baixa prioridade => Nó único na região do AWS N. California (us-west-1)
Para alterar a ordem de prioridade dos seus nós elegíveis, você pode pegar (clicar e segurar as três linhas verticais da linha) a região que deseja mover e arrastá-la para a ordem que preferir.
Se você precisar alterar o provedor de nuvem principal do seu cluster após sua criação, não se preocupe! Você pode fazer isso editando a configuração do cluster por meio da UI do Atlas.
Para otimizar as leituras locais em áreas específicas, use nós somente para leitura. Esses nós têm tags de preferência de leitura distintas que permitem direcionar as queries para as regiões que você especificar. Assim, você pode configurar um nó para cada uma de suas regiões utilizáveis, direcionando as consultas dos usuários para o nó mais próximo a eles. Isso resulta em latência reduzida para todos! 🙌
} Ao configurar nós read-only em um cluster multinuvem, tenha em mente o seguinte:
- Os nós somente leitura não participam das eleições.
- Como eles não participam de eleições, não oferecem alta disponibilidade.
- Os nós read-only não podem se tornar os primary do cluster.
Para adicionar um nó somente para leitura ao seu cluster, clique em " + Adicionar um provedor/região, " e selecione o provedor de nuvem, a região e o número de nós que você gostaria de adicionar. Se você quiser remover um nó somente leitura do cluster, clique no ícone de lixeira à direita de cada linha.
Se você precisar executar cargas de trabalho analíticas e preferir separá-las das cargas de trabalho operacionais principais, use os nós do Analytics. Esses nós são ótimos para operações complexas ou de longa duração, como consultas de relatórios e trabalhos de ETL, que podem ocupar muitos recursos de cluster e competir com seu outro tráfego. O benefício dos nós de analítica é que você pode isolar completamente essas queries.
Os nós de análise têm as mesmas considerações que os nós somente para leitura. Eles também podem ser adicionados e removidos do seu cluster da mesma forma que os outros nós.
A implantação de um número ímpar de nós elegíveis garante eleiçõesconfiáveis. Com isso em mente, exigimos a configuração de um mínimo de três nós elegíveis. Dependendo do seu cenário, esses nós podem ser divididos de diversas maneiras diferentes. Geralmente aconselhamos uma das seguintes opções de distribuição de nós:
Para obter disponibilidadecontínua de leiturae gravação em qualquer provedor de nuvem e interrupção de região, é necessária uma distribuição de nós 2-2-1. Ao distribuir em vários provedores de nuvem, você obtém maiores garantias de disponibilidade. No entanto, como as distribuições de nós 2-2-1 precisam replicar continuamente os dados para cinco nós, em diferentes regiões e provedores de nuvem, essa pode ser a configuração mais cara. Se o custo for uma preocupação, a distribuição de nós 1-1-1 pode ser uma alternativa eficaz.
Nessa configuração, você poderá obter uma disponibilidade de leitura e gravação semelhante (mas não exatamente exata) à distribuição 2-2-1 com três provedores de nuvem. A maior diferença, no entanto, é que quando um provedor de nuvem fica inoperante, você pode encontrar uma latência de gravação mais alta, especialmente se suas gravações tiverem que ser transferidas temporariamente para uma região mais distante.
Com os recursos multinuvem, surgem novas considerações a serem lembradas. Ao começar a criar mais de seus próprios clusters multinuvem, esteja ciente do seguinte:
Quanto maior o número de regiões que você tiver ou quanto maiores as distâncias físicas entre seus nós,maiores serãoos tempos de eleição/atraso de replicação . Você já pode ter experimentado isso se tiver clusters multirregionais, mas pode ser agravado à medida que os nós estão potencialmente mais espalhados com clusters multinuvem.
Se você usar o formato padrão de connection string, a remoção de uma região inteira de um cluster multirregional existente pode resultar em uma nova connection string. Em vez disso, é altamente recomendável usar o formato de lista de sementes DNS para evitar possíveis perdas de serviço para seus aplicativos.
O Atlas não garante que os nomes de host permaneçam consistentes com os tipos de nó durante as alterações de topologia. Por exemplo, em meu cluster chamado "multi-cloud-demo", eu tinha um nó do Analytics chamado
multi-cloud-demo-shard-00-05.opbdn.mongodb.net:27017. Quando ocorre uma alteração de topologia, como alterar minhas regiões selecionadas ou dimensionar o número de nós em meu cluster, o Atlas não garante que o nome de host específico multi-cloud-demo-shard-00-05.opbdn.mongodb.net:27017 ainda se referirá a um nó do Analytics.| Preocupação de gravação | Tags | Descrição |
|---|---|---|
twoRegions | {region: 2} | As operações de gravação devem ser reconhecidas por pelo menos duas regiões em seu cluster. |
threeRegions | {region: 3} | As operações de gravação devem ser reconhecidas por pelo menos três regiões em seu cluster. |
twoProviders | {provider: 2} | As operações de gravação devem ser reconhecidas por pelo menos duas regiões em seu cluster com fornecedores de serviços em nuvem distintos. |
Os clusters existentes podem ser modificados para se tornarem clusters de várias nuvens? Sim. Todos os clusters M10 ou superiores podem ser alterados para um cluster de várias nuvens por meio das definições de configuração do cluster no Atlas.
Posso implementar um cluster fragmentado multinuvem? Sim. Tanto os conjuntos de réplicas multinuvem quanto os clusters fragmentados multinuvem estão disponíveis para implementação no Atlas.
Os clusters multinuvem funcionam da mesma maneira em todas as versões, camadas de cluster e nuvens? Sim. Os clusters multinuvem se comportarão de maneira muito semelhante aos clusters multirregionais de nuvem única, o que significa que também estarão sujeitos às mesmas restrições.
O que acontece com os servidores de configuração em um cluster fragmentado em várias nuvens? Os servidores de configuração se comportarão da mesma forma que para os clusters fragmentados existentes no MongoDB Atlas atualmente. Se um cluster tiver duas regiões elegíveis, haverá dois servidores de configuração na região de maior prioridade e um servidor de configuração na próxima região mais alta. Se um cluster tiver três ou mais regiões elegíveis, haverá um servidor de configuração em cada uma das três regiões de maior prioridade.
Posso usar um sistema de gerenciamento de chaves para encryption at rest com um cluster de várias clouds? Sim. Qualquer KMS que você preferir (Azure Key Vault, AWS KMS ou Google Cloud KMS) pode ser usado, embora apenas um KMS possa estar ativo por vez. Caso contrário, o gerenciamento de chaves para encryption at rest funciona da mesma forma que para clusters de cloud única.
Posso fixar dados em determinados provedores de nuvem para atender aos requisitos de conformidade? Sim Com oGlobal Clusters, você pode fixar dados em zonas ou regiões específicas para atender a quaisquer requisitos de soberania de dados que você possa ter.
Tem uma pergunta que não foi respondida aqui? Vá até nossos MongoDB Community e inicie um tópico! Nossa comunidade de especialistas e funcionários do MongoDB está sempre pronta para ajudar!