Docs Menu
Docs Home
/
MongoDB Ops Manager
/

Example Deployment Architectures

On this page

  • Considerations
  • Test Install on a Single Host
  • Production Installs

The following examples illustrate some possible MongoDB and Ops Manager deployments.

Backups no longer require head databases. For more information, see Backup Daemon Service.

For a test deployment, you can deploy all of the Ops Manager components to a single host, as described in Install a Simple Test Ops Manager Installation.

The minimal deployment is suitable for development or testing, and hosts the application and backup daemon, as well as associated databases on a single server.

Note

If you would like to test backup services, use the Ops Manager Application to configure them. When configuring Ops Manager, you can specify the backup settings.

The application database stores snapshots of deployment state in backup cursors.

This deployment provides redundancy for the Ops Manager Application Database and Snapshot Storage in the event of host failure. The deployment runs the database in a MongoDB replica set with three data-bearing members with copies of the data.

Important

This deployment provides high availability for the Ops Manager Application. Ops Manager uses a w:2 write concern, and can tolerate the loss of one data-bearing node from the Ops Manager Application Database. To make the deployment more durable, enable journaling.

A typical deployment uses replica sets for the application database and snapshot store.
click to enlarge

Note

All hosts must satisfy the combined hardware and software requirements for both the systems specified in the System Requirements column.

Host
System Requirements
Purpose

1

  • Ops Manager Application

  • Ops Manager Application database

Serves the Ops Manager Application database primary and the snapshot store secondary.

2

  • Ops Manager Application

  • snapshot store

Serves the snapshot store primary and the Ops Manager Application database secondary.

3

  • Ops Manager Application database

  • snapshot store

Hosts the Ops Manager Application Database and snapshot store secondary replica set members.

Replica sets provide data redundancy and are strongly recommended, but are not required for Ops Manager.

For an example tutorial on installing the minimally viable Ops Manager installation, see Install a Simple Test Deployment on RHEL.

This Ops Manager deployment runs multiple instances behind a load balancer to provide high availability for Ops Manager. This deployment scales out to add an additional snapshot store.

A highly available deployment uses horizontal scaling of the application database and snapshot store for backups, as well as multiple backup daemons.
click to enlarge

The deployment includes:

  • two hosts that serve the Ops Manager Application and the Ops Manager Application Database

  • four hosts that serve Ops Manager Application with Backup enabled and Backup Databases

  • additional hosts to serve the remaining members of each replica set

Deploy an HTTP Load Balancer to balance the HTTP traffic for the Ops Manager Application. Ops Manager does not supply an HTTP Load Balancer. You must provision, deploy, and configure it yourself. A load balancer placed before of the Ops Manager Application hosts must not return cached content.

All of the software services need to be able to communicate with the Ops Manager Application Databases and the snapshot stores. Configure your firewalls to allow traffic between these hosts on the appropriate ports.

Note

All hosts must satisfy the combined hardware and software requirements for both the systems specified in the System Requirements column.

Host
System Requirements
Purpose

1 & 2

  • Ops Manager Application

  • Ops Manager Application Database

Serves the primary and secondary for the Ops Manager Application database.

3, 4, 5 & 6

  • Ops Manager Application

  • snapshot store

Serves the primary and secondary for the two snapshot stores.

Only the Backup Daemon needs to communicate with the head databases. As such, their net.bindIp value is 127.0.0.1 to prevent external communication. net.bindIp specifies the IP address that mongod and mongos listens to for connections coming from applications.

7 & 8

  • Ops Manager Application database

  • snapshot store

Serve the remaining replica set members for the Ops Manager Application Database and the two snapshot stores.

To learn how to install Ops Manager with high availability, see Configure a Highly Available Ops Manager Application.

Back

Architecture