Production Notes

The Organization Level

At the Organization level, you can implement security controls and create users which work across one or more Projects. Atlas billing occurs at the Organization level.

To efficiently control user access and privileges, you can group users into teams at the Organization level.

The Project Level

Projects offer a security isolation and authorization boundary, so they are typically allocated by application team and application environment. For example, within two application teams there might be six projects: one for each team in the Development, Staging, and Production environments.

You can create project-level Atlas users and roles with appropriate access to the different production and development application environments.

• Users with the Project Read Only role can access project-level monitoring and system health metadata without having access to any collection data or administrative operations.
• Users with the Project Cluster Manager role can scale clusters and perform other administrative operations, but have no data-level access.

Other project-level responsibilities include:

• Implement optional enterprise security features, including:

  • Encryption with customer key management
  • Database auditing
  • LDAP

• Set up network access configuration, including:

  • VPC / VNet Peering
  • Adding IP addresses to an IP access list
• Define appropriate database alerts via the Atlas interface or API and respond to any which require attention.

• Integrate with external monitoring/alerting systems, such as DataDog and New Relic.

  Important

  Effective Wednesday, June 16th, 2021, New Relic no longer supports the plugin-based integration with MongoDB. We do not recommend that you sign up for the plugin-based integration.

  To learn more, see the New Relic Plugin EOL Statement. Consider configuring an alternative monitoring integration before June 16th to maintain visibility into your MongoDB deployments.

Cluster Naming Conventions

Choosing the right naming convention for your Atlas clusters is a good first step towards running a successful production environment. Once you've named a cluster you can't rename it, so it's important to get it right the first time. The following suggestions can make it easier to parse logs and differentiate clusters.

• Use descriptive, lowercase names.
• Avoid special characters.
• Join words with hyphens or underscores. Avoid blank spaces between words.
• Use a convention which makes it clear whether a cluster is for production, staging, or development purposes.

Some examples of good cluster names:

• prod-aws-website
• staging-gcp-internal
• dev-azure-analytics

Single Region and Multi-Region Clusters

High availability and cluster durability depend on a cluster's geographical deployment configuration. Clusters which are deployed within a single region are spread across availability zones within that region, so they can withstand partial region outages without an interruption of read or write availability.

You can optionally choose to spread your clusters across two or more regions for greater resiliency and workload isolation.

The order of regions determines the priority order for the location of the primary node. Therefore, if you wish to direct database write operations to a particular region when that region is available, you should list that region first. The second region on the list should be the second choice for where writes should go if the first region is unavailable.

The following example from the Atlas Create a Cluster UI shows a multi-region cluster with electable nodes in three different regions, arranged by priority from highest to lowest:

If the us-east-1 region becomes unavailable, a new primary will be elected in the us-west-1 region.

Scaling

MongoDB Atlas offers two methods for scaling, vertical and horizontal.

Vertical scaling involves increasing a clusters storage capacity, computing power, and/or IOPS rate. Vertical scaling can be accomplished quickly and is useful for peak usage periods. Vertically scaling from shared clusters (M2 and M5) requires a few minutes of downtime whereas scaling between dedicated clusters (M10 and greater) happens without downtime.

When scaling vertically, M30 and higher clusters are recommended for production environments. You can use the following cluster tiers as production environments for low-traffic applications, but these tiers are recommended for development environments:

• M2 and M5 shared clusters
• M10 and M20 dedicated clusters

Horizontal scaling involves implementing sharding or adding shards in an existing sharded cluster. Horizontal scaling requires careful planning and execution, and is part of a long-term growth strategy for M30+ clusters. You can also reduce the number of shards in a sharded cluster.

Vertical and horizontal sharding can be combined in Atlas. For example, a sharded cluster can be vertically scaled up for a peak period, increasing the storage capacity and computing power of the individual sharded cluster members.

By default, Atlas vertically auto-scales cluster storage up to your configured cluster tier size limit.

You can configure Atlas to automatically scale your cluster tier and cluster storage capacity in response to increased cluster usage, allowing for a rapid, automated response to a need for greater storage computing power.