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!
- 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 de "Multi-Region" e "Multi-Cloud"?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 cluster multirregional, 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 o primary 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ós recomendadas são um bom ponto de partida.
- Nós somente leitura: ótimos para leituras locais em áreas específicas.
- Nós de analítica : ótimos para isolar as 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 fornecedores de nuvem e regiões hospedarão seus nós elegíveis, anote também a ordem em que você os coloca. 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 está definida como a região de maior prioridade. O Atlas permite que você saiba isso, pois você verá o selo "mais alto" 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 a disponibilidade contínua de leitura e gravação em qualquer provedor de nuvem e interrupção de região,221 é necessária uma distribuição de nós - -. Ao se distribuir por vários fornecedores de nuvem, você obtém garantias de maior disponibilidade. No entanto, como 221 as distribuições de nó - - 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, então a 111 distribuição de nós - - pode ser uma alternativa eficaz.
Nesta configuração, você poderá obter disponibilidade de leitura e gravação semelhante (mas não exatamente) à distribuição 2-2-1 com três provedores de nuvem. A maior diferença, no entanto, é que, quando um provedor de nuvem fica inativo, você pode encontrar uma latência de escrita mais alta, especialmente se suas escritas tiverem que mudar 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 maiores forem as distâncias físicas entre seus nós,maiores serão seus tempos de eleição / atraso de replicação . Você pode já ter experimentado isso se tiver clusters multirregional , mas isso pode ser agravado à medida que os nós estão potencialmente mais distantes do que os multinuvem .
Se você usar o formato padrão de string de conexão, a remoção de uma região inteira de um cluster multirregional existente pode resultar em uma nova string de conexão. 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ó de analítica 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 serem clusters de multinuvem ? Sim. Todos os clusters M10 ou superior podem ser alterados para um cluster multinuvem por meio das definições de configuração de cluster no Atlas.
Posso implementar um cluster fragmentado ? Sim. Tanto os conjuntos de multinuvem quanto os clusters fragmentados multinuvem estão disponíveis para implementação no Atlas.
Os clusters de multinuvem funcionam da mesma forma em todas as versões, camadas do cluster e nuvens? Sim. Os clusters de várias nuvens se comportarão de forma muito semelhante aos clusters de multirregional de nuvem única, o que significa que eles também estarão sujeitos às mesmas restrições.
O que acontece com os servidores de configuração em um cluster fragmentado ? 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 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 criptografia em descanso com um cluster de multinuvem ? Sim. Qualquer KMS que você preferir (Azure Key Vault, Amazon Web Services KMS ou Google Cloud Platform KMS) pode ser usado, embora apenas um KMS possa estar ativo por vez. Caso contrário, o gerenciamento de chaves para criptografia em descanso funciona da mesma forma que para clusters de nuvem única.
Posso fixar dados em determinados fornecedores de nuvem para atender aos requisitos de conformidade? Sim. Com os clusters globais, você pode fixar dados em zonas ou regiões específicas para atender a quaisquer requisitos de soberania de dados que 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!