Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs

Orientações para organizações, projetos e clusters do Atlas

Organizações, projetos e clusters são os componentes fundamentais do seu patrimônio empresarial Atlas:

  • No nível da organização , você pode implementar controles de segurança e criar usuários que trabalham em um ou mais projetos.

  • Os projetos oferecem um isolamento de segurança e uma fronteira de autorização mais refinada.

  • Os clusters são seus bancos de dados na nuvem no Atlas.

Utilize a orientação fundamental desta página para projetar o layout de suas organizações, projetos e clusters com base na hierarquia da sua empresa e no número esperado de clusters e projetos. Esta orientação, além de ajudar você a otimizar sua segurança e seu desempenho desde o início, está alinhada às necessidades de faturamento e acesso da sua empresa.

Observação

The MongoDB Atlas Shared Responsibility Model defines the complementary duties of MongoDB and its customers in maintaining a secure and resilient data environment. Under this framework, MongoDB manages the security and operational integrity of the underlying platform, while customers are responsible for the configuration, management, and data policies of their specific deployments. For a detailed breakdown of ownership across security and operational excellence, see Shared Responsibility Model.

Você pode utilizar os seguintes níveis de hierarquia para definir configurações de segurança e administração para sua propriedade do Atlas :

Nível de hierarquia do Atlas
Descrição

(Opcional) Organização Pagadora

One organization can be a paying organization for other organization(s). A paying organization lets you set up cross-organization billing to share a billing subscription across multiple organizations. To learn more about setting up your paying organization when you establish the Atlas subscription, see Manage Billing. In order to enable cross-organization billing, the user performing the action must have an Org Owner or Billing Admin role of both organizations that they wish to link. To learn more, see User Roles.

Organizações pagadoras são comuns em grandes empresas com muitas UNs ou departamentos que operam de forma independente, mas cujos contratos ou faturas pertencem a uma autoridade central.

An organization can contain many projects, and it provides a container to apply shared integration and security settings across those projects and the clusters therein. If you manage multiple Atlas organizations, the Atlas Federation Management Console allows users with an Org Owner role to manage IdPs for SSO, then link them to multiple organizations. An organization often maps to a BU or department within a company. The built-in Atlas Cost Explorer aggregates cloud spend at the organization level and breaks out line items at the project-level and cluster level below it. You can customize further by leveraging the billing API.

Security configuration for the data plane (including database clusters, network security, and other data services) occurs at the project-level. A project often maps to an application and environment (for example: Customer Portal app - Production environment). For each project, based on the selected cloud provider, there is one dedicated VPC or VNet per region in AWS and Azure.

Atlas provisions each cluster within the dedicated VPC/VNet(s) for a project. The security configuration is shared among clusters in the project, except for database user roles and authorization, which you can apply to actions on a cluster, database, and collection level.

Uma imagem mostrando a hierarquia de organização, projeto e cluster.
clique para ampliar

Para implantações multirregionais e multinuvem, considere as seguintes recomendações adicionais para otimizar o desempenho, a segurança e o compliance além das fronteiras geográficas:

  • Implante clusters nas regiões mais próximas dos usuários do seu aplicativo para minimizar a latência.

  • Use VPCs/VNets dedicadas por região em cada projeto para manter o isolamento da rede.

  • Configure private endpoints em cada região em que você implantar clusters para garantir conexões seguras e de baixa latência.

  • Crie projetos separados para diferentes jurisdições regulatórias (por exemplo, projeto compatível com o GDPR da UE, projeto compatível com o SOX dos EUA) para garantir que os requisitos de residência de dados sejam atendidos.

  • Use Global Clusters with zone sharding to automatically route reads and writes to the appropriate geographic region based on shard key values.

  • Marque projetos e clusters com classificação de dados e requisitos de compliance regional para fins de auditoria e governança.

  • Implante clusters com réplicas de leitura em várias regiões para habilitar funcionalidades de failover.

  • Mantenha agendamentos de backup consistentes em todas as regiões dentro do mesmo ambiente de aplicativo.

  • Teste regularmente os procedimentos de recuperação de desastres em todas as regiões para assegurar a continuidade dos negócios.

  • Adote convenções de nomenclatura consistentes entre os provedores de nuvem para facilitar o gerenciamento e o monitoramento.

  • Padronize as configurações de segurança em todos os ambientes de nuvem no mesmo projeto.

  • Considere as características e limitações específicas dos provedores de nuvem ao planejar a replicação de dados entre nuvens e a conectividade de rede.

As seguintes recomendações se aplicam a todos os paradigmas de implantação.

Recomendamos que você use os quatro ambientes a seguir para isolar sua sandbox e testar projetos e clusters dos seus projetos e clusters de aplicativos:

ambiente
Descrição

Desenvolvimento (Dev)

Permita que os desenvolvedores testem livremente novas ideias em um ambiente seguro de sandbox.

Teste (Teste)

Teste componentes ou funções específicas criadas no ambiente de desenvolvimento.

Encenação

Prepare todos os componentes e funções juntos para garantir que todo o aplicação funcione conforme o esperado antes de ser implementado na produção. A preparação é semelhante ao ambiente de teste, mas garante que os novos componentes funcionem bem com os componentes existentes.

Produção (Prod)

O back-end do seu aplicativo que está em operação para os seus usuários finais.

Para fins de desenvolvimento e teste, os desenvolvedores podem usar a Atlas CLI para criar uma implantação local do Atlas. Ao trabalhar localmente em suas máquinas, os desenvolvedores podem reduzir os custos com ambientes externos de desenvolvimento e teste.

Developers can also run Atlas CLI commands with Docker to build, run, and manage local Atlas deployments using containers. Containers are standardized units that contain all of the software needed to run an application. Containerization allows developers to build local Atlas deployments in secure, reliable, and portable test environments. To learn more, see Create a Local Atlas Deployment with Docker.

Geralmente, recomendamos uma organização pagadora gerida centralmente e uma organização para cada UN ou departamento vinculado à organização pagadora. Em seguida, crie um projeto com um cluster para cada um dos seus ambientes inferiores (de desenvolvimento ou teste) e superiores. Você pode criar clusters nesses projetos. Para saber mais, veja as informações a seguir para Hierarquia recomendada.

If you will easily hit the 250 project limit per organization, we recommend creating one organization per environment, such as one each for lower and upper environments, or one each for dev, test, staging, and production. This setup has the benefit of additional isolation. You can also increase the limits. To learn more, see Atlas Service Limits.

As configurações de rede e segurança, como IPs permitidos e chaves de API, são compartilhadas no nível do projeto. Portanto, se você precisar de controles de acesso detalhados para equipes que trabalham em diferentes aplicativos, recomendamos que crie projetos separados para cada aplicativo.

Avalie a seguinte hierarquia, que cria menos organizações do Atlas, caso você tenha equipes e permissões comuns em toda a UN e menos do que o limite aumentável de 250 projetos por organização.

Uma imagem mostrando uma organização pagadora com outras organizações aninhadas abaixo dela.
clique para ampliar

Considere a seguinte hierarquia se sua organização for altamente descentralizada e não houver uma função centralizada para servir como responsável pelo contrato e pela cobrança. Nesta hierarquia, cada UN, departamento ou equipe tem sua própria organização do Atlas. Esta hierarquia é útil se cada uma de suas equipes for bastante independente, não compartilhar pessoas ou permissões dentro da empresa ou quiser comprar créditos por meio do marketplace do provedor de nuvem ou diretamente com o próprio contrato. Nesta hierarquia, não há organização pagante.

Uma imagem mostrando várias organizações sem uma organização pagadora acima delas.
clique para ampliar

Para manter o isolamento entre ambientes, recomendamos que você implante cada cluster dentro de seu próprio projeto, como ilustrado no diagrama a seguir. Isso permite que os administradores mantenham diferentes configurações de projeto entre ambientes e respeitem o princípio do privilégio mínimo, que estabelece que os usuários devem receber apenas o nível mínimo de acesso necessário para suas funções.

Sobretudo em ambientes de produção, recomendamos que você crie projetos separados para cada par de aplicativo e ambiente. Como essas configurações são gerenciadas no nível do projeto, essa abordagem reduz a potencial necessidade de transferir dados manualmente entre clusters de ambiente de produção caso esses requisitos mudem para um determinado aplicativo.

Você pode compartilhar configurações gerais do projeto, como pontos de extremidade privados e CMKs, entre clusters usando ferramentas de automação, como o Terraform, durante a criação do cluster. Além disso, automatizar a criação de clusters pode resultar em economia de custos ao padronizar a criação de ambientes paralelos superiores para produção e inferiores para desenvolvimento, respectivamente.

To learn more, see When to Consider Multiple Clusters Per Project.

Uma imagem mostrando uma implantação por projeto em cada organização.
clique para ampliar

O diagrama seguinte mostra uma organização cujos projetos cada um contém múltiplos Atlas clusters, agrupados por ambiente. A implantação de vários clusters no mesmo projeto simplifica a administração quando um aplicação usa vários clusters de apoio ou a mesma equipe é responsável por vários aplicativos em ambientes. Isso reduz o custo de configuração de recursos como endpoints privados e chaves gerenciadas pelo cliente, pois todos os clusters no mesmo projeto compartilham a mesma configuração de projeto .

No entanto, essa hierarquia de cluster pode violar o princípio do privilégio mínimo.

Implante vários clusters no mesmo projeto somente se ambos os itens a seguir forem verdadeiros:

  • Cada membro da equipe com acesso ao projeto está trabalhando em todos os outros aplicativos e clusters no projeto.

  • Você está criando clusters para ambientes de desenvolvimento e teste. Em ambientes de preparo e produção, recomendamos que os clusters no mesmo projeto pertençam ao mesmo aplicação e sejam administrativos pela mesma equipe.

Uma imagem que mostra implantações agrupadas por ambiente.
clique para ampliar

We recommend that you tag clusters or projects with the following details to enable easy parsing for reporting and integrations:

  • UN ou departamento

  • teamName

  • Nome do aplicativo

  • ambiente

  • Versão

  • Contato por e-mail

  • Criticidade (indica o tier de dados armazenados no cluster, incluindo quaisquer classificações sensíveis, como PII ou PHI)

Para aprender mais sobre a análise de dados de faturamento usando tags, consulte Recursos para dados de faturamento do Atlas.

Em uma implantação dedicada (tamanho de cluster M10+), o Atlas aloca recursos exclusivamente. Recomendamos implantações dedicadas para casos de uso de produção porque elas fornecem maior segurança e desempenho do que os clusters compartilhados.

O guia de tamanho de cluster a seguir usa o "dimensionamento de t-camiseta", uma comparação comum usada no desenvolvimento de software e na infraestrutura para descrever o planejamento de capacidade de maneira simplificada. Use as recomendações de tamanho de roupas de times apenas como pontos de partida aproximados em sua análise de dimensionamento. O dimensionamento de um cluster é um processo iterativo baseado na alteração das necessidades de recursos, nos requisitos de desempenho, nas características do volume de trabalho e nas expectativas de crescimento.

Importante

Essa orientação exclui aplicativos de função crítica, volumes de trabalho de alta memória e volumes de trabalho de alta CPU. Para esses casos de uso, entre em contato com o suporte do MongoDB para obter orientação personalizada.

Você pode estimar os recursos de cluster que seu sistema exige usando o tamanho aproximado dos dados e o volume de trabalho da organização:

  • Armazenamento Total Necessário: 50% do tamanho total dos dados brutos

  • Total de RAM Necessária: 10% do tamanho total dos dados brutos

  • Total de núcleos de CPU necessários: operações de banco de dados de leitura/escrita de pico esperadas por segundo sta 4000

  • Total de IOPS de armazenamento necessário: operações de banco de dados de leitura/escrita de pico esperadas por segundo (IOPS mínima = 5%, IOPS máxima = 95%)

Use o guia de tamanho de cluster a seguir para selecionar uma camada do cluster que garanta o desempenho sem provisionamento excessivo. Esta tabela exibe os recursos padrão de armazenamento e desempenho para cada camada do cluster, bem como se a camada do cluster é adequada ou não para ambientes de preparação e produção.

O guia de tamanho do cluster também inclui valores esperados para o tamanho total de dados de um cluster e IOPS padrão, que podem ser aumentados com configurações adicionais. Observe que as recomendações de armazenamento a seguir são por fragmento, não para todo o cluster. Para aprender mais, consulte Orientações para escalabilidade do Atlas.

Tamanho da coleção
Camada do cluster
Faixa de armazenamento: AWS, Google Cloud e Azure
CPUs (#)
RAM padrão
IOPS padrão
Tamanho médio esperado dos dados
Leituras/gravações de pico esperadas
Ideal para

Pequena

M10 [1]

2 GB a 128 GB

2

2 GB

1000

1 GB a 10 GB

200

Somente para desenvolvimento/teste

Med

M30

8 GB a 512 GB

2

8 GB

3000

20 GB a 50 GB

3000

Prod

grande

M50

8 GB a 4 TB

16

32 GB

3000

360 GB a 420 GB

11000

Prod

X-Large

M80

8 GB a 4 TB

32

128 GB

3000

1200 GB a 1750 GB

39000

Prod

[1] M10 é uma camada de CPU compartilhada. Para setores altamente regulamentados ou dados confidenciais, seu nível inicial mínimo e menor deve ser M30.

Por exemplo, considere uma fintech fictícia, a MongoFinance, que precisa armazenar um total de 400 GB de dados processados. Durante o pico de atividade, os funcionários e clientes da MongoFinance realizam até 3000 operações de leitura ou gravação nos bancos de dados da MongoFinance por segundo. Os requisitos de armazenamento e desempenho da MongoFinance são melhor atendidos por uma camada do cluster grande, ou M50.

Para aprender mais sobre as camadas de cluster e as regiões com suporte, consulte a documentação do Atlas para cada provedor de nuvem:

Dica

Para exemplos de Terraform que impõem nossas recomendações em todos os colunas, consulte um dos seguintes exemplos no Github:

Os exemplos seguintes criam organizações, projetos e clusters utilizando ferramentas Atlas para automação.

Esses exemplos também incluem outras configurações recomendadas, tais como:

  • Cluster tier set to M10 for a dev/test environment. Use the cluster size guide to learn the recommended cluster tier for your application size.

  • Região única, 3-Conjunto de réplicas de nós/Topologia de implantação de fragmento.

  • Our examples use AWS, Azure, and Google Cloud interchangeably. You can use any of these three cloud providers, but you must change the region name to match the cloud provider. To learn about the cloud providers and their regions, see Cloud Providers.

Observação

Antes de criar recursos com o Atlas CLI, você deve:

Execute o seguinte comando em cada UN. Altere os IDs e nomes para seus valores reais:

atlas organizations create ConsumerProducts --ownerId 508bb8f5f11b8e3488a0e99e --apiKeyRole ORG_OWNER --apiKeyDescription consumer-products-key

Para mais opções de configuração e informações sobre este exemplo, consulte Criar organizações no Atlas.

Você pode criar uma organização e vinculá-la à sua organização pagadora, programaticamente, usando a Atlas Administration API. Para isso, envie uma solicitação POST para o ponto de extremidade https://cloud.mongodb.com/api/atlas/v2/orgs e especifique o ID da organização pagadora no campo federationSettingsId. A conta de serviço ou a chave de API solicitante deve ter a função "Proprietário da organização", e a organização solicitante deve ser uma organização pagante.

O exemplo a seguir usa cURL para enviar a solicitação:

curl --location '/api/atlas/v2/orgs?envelope=false&pretty=false' \
--header 'Content-Type: application/vnd.atlas.2023-01-01+json' \
--header 'Accept: application/vnd.atlas.2023-01-01+json' \
--data '{
"name": "<organization name>",
"apiKey": {
"desc": "<organization description>",
"roles": [
"ORG_MEMBER"
]
},
"federationSettingsId": "<ID of org to link to>",
"orgOwnerId": "<organization owners ID>",
"skipDefaultAlertsSettings": false
}'

Para aprender mais sobre a chamada de API precedente, consulte a documentação da API atlas organizations create.

Para obter os IDs de usuário e os IDs da organização, consulte os seguintes comandos:

Execute o comando a seguir para cada par de aplicação e ambientes. Altere os IDs e nomes para usar seus valores:

atlas projects create "Customer Portal - Prod" --tag environment=production --orgId 32b6e34b3d91647abb20e7b8

For more configuration options and info about this example, see atlas projects create.

Para obter os IDs do projeto, consulte o seguinte comando:

Para ambientes de staging e produção, recomendamos que habilite a criptografia com gerenciamento de chaves do cliente ao provisionar seus clusters. Para desenvolvimento e teste, considere omitir a criptografia com gerenciamento de chaves do cliente para reduzir custos, a menos que você esteja em um setor altamente regulamentado ou armazene dados sensíveis. Para aprender mais, consulte Recomendações para organizações, projetos e clusters do Atlas.

Você não pode usar a Atlas CLI para gerenciar a criptografia com o gerenciamento de chaves do cliente . Em vez disso, use os seguintes métodos:

Para criar um cluster de região única para seus ambientes de desenvolvimento e teste, execute o seguinte comando para cada projeto criado. Altere os IDs e nomes para usar seus valores:

Observação

You can also use the clusters Atlas Admin API to create a cluster.

Esse exemplo não permite o dimensionamento automático para controlar os custos em ambientes de desenvolvimento e teste. Para ambientes de teste e produção, deve ser ativado o dimensionamento automático.

atlas clusters create CustomerPortalDev \
--projectId 56fd11f25f23b33ef4c2a331 \
--region EASTERN_US \
--members 3 \
--tier M10 \
--provider GCP \
--mdbVersion 8.0 \
--diskSizeGB 30 \
--tag bu=ConsumerProducts \
--tag teamName=TeamA \
--tag appName=ProductManagementApp \
--tag env=Production \
--tag version=8.0 \
--tag email=marissa@example.com \
--watch

Para configurar um cluster multirregional, crie o seguinte arquivo cluster.json para cada projeto criado. Altere os IDs e nomes para usar os seus valores.

{
"name": "CustomerPortalDev",
"projectId": "56fd11f25f23b33ef4c2a331",
"clusterType": "REPLICASET",
"diskSizeGB": 30,
"mongoDBMajorVersion": "8.0",
"backupEnabled": true,
"replicationSpecs": [
{
"numShards": 1,
"regionConfigs": [
{
"providerName": "GCP",
"regionName": "EASTERN_US",
"members": 3,
"priority": 7,
"autoScaling": {
"compute": {
"enabled": true,
"scaleDownEnabled": true
},
"diskGB": {
"enabled": true
}
}
},
{
"providerName": "GCP",
"regionName": "CENTRAL_US",
"members": 2,
"priority": 5,
"autoScaling": {
"compute": {
"enabled": true,
"scaleDownEnabled": true
},
"diskGB": {
"enabled": true
}
}
},
{
"providerName": "GCP",
"regionName": "WESTERN_US",
"members": 2,
"priority": 4,
"autoScaling": {
"compute": {
"enabled": true,
"scaleDownEnabled": true
},
"diskGB": {
"enabled": true
}
}
}
]
}
],
"tags": [
{ "key": "bu", "value": "ConsumerProducts" },
{ "key": "teamName", "value": "TeamA" },
{ "key": "appName", "value": "ProductManagementApp" },
{ "key": "env", "value": "Production" },
{ "key": "version", "value": "8.0" },
{ "key": "email", "value": "marissa@example.com" }
]
}

Depois de criar o arquivo de configuração anterior, execute o seguinte comando para criar o cluster:

atlas clusters create --file <path to your configuration file>

For more configuration options and info about these examples, see atlas clusters create.

Depois de planejar a hierarquia e o tamanho de suas organizações, projetos e clusters, consulte os recursos sugeridos a seguir ou use a navegação à esquerda para encontrar funcionalidades e melhores práticas para cada pilar do Well-Architected Framework.