Navigation
This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.

Example Deployment Topologies

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

Considerations

For best performance on any of these installs, configure each Backup server with two disk partitions: one for the Backup Database or File System Store and one for the head databases.

Test Install on a Single Server

For a test deployment, you can deploy all of the Ops Manager components to a single server, 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, you can configure them using the Ops Manager Application. During configuration, you can specify the head directory. The Backup Daemon service creates the head databases dynamically in that directory. The Backup Daemon service then manages these head databases.

Production Installs

Redundant Metadata and Snapshots

This deployment provides redundancy for the Ops Manager Application Database and Snapshot Storage, in the event of server failure. The deployment keeps a redundant copy of each database by running each as a MongoDB replica set with two data-bearing members and an arbiter.

Important

This deployment does not provide high availability for the Ops Manager Application. Ops Manager uses w:2 write concern, which requests acknowledgement of a write operation from both data-bearing members. The loss of one data-bearing node from the Ops Manager Application Database must be remedied before Ops Manager can resume healthy operation. To make the deployment durable, run each with three data-bearing members and enable journaling.

A typical deployment uses replica sets for the application database and backup blockstore database.

Note

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

Server Meets System Requirements for Purpose
1
  • Ops Manager Application
  • Ops Manager Application database
Hosts the primary Ops Manager Application database and the arbiter for the backup database.
2
  • Ops Manager Application
  • Backup database
Hosts the primary backup database and the arbiter for the Ops Manager Application database.
3
  • Ops Manager Application database
  • Backup database

Hosts replica set members for the Ops Manager Application Database and Backup Database.

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 Basic Production Deployment on RHEL or Amazon Linux.

Highly Available Ops Manager Application and Multiple Backup Databases

This Ops Manager deployment provides high availability for the Ops Manager Application by running multiple instances behind a load balancer. This deployment scales out to add an additional Backup Database.

A highly available deployment uses horizontal scaling of the application database and backup blockstore database, as well as multiple backup daemons.

The deployment includes:

  • two servers that host the Ops Manager Application and the Ops Manager Application Database
  • four servers that host Ops Manager Application with Backup enabled and Backup Databases
  • additional servers to host 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 deploy and configure it yourself. A load balancer placed in front of the Ops Manager Application servers must not return cached content.

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

Note

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

Server Meets System Requirements for Purpose
1 & 2
  • Ops Manager Application
  • Ops Manager Application Database
Hosts the primary and secondary for the Ops Manager Application database.
3, 4, 5 & 6
  • Ops Manager Application
  • Backup Database

Hosts the primary and secondary for the two backup databases.

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
  • Backup database
Host the remaining replica set members for the Ops Manager Application Database and for the two Backup Databases.

For the procedure to install Ops Manager with high availability, see Configure a Highly Available Ops Manager Application.