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

On this page

Overview

The following diagrams show example Ops Manager deployments.

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. Ensure you configure the appropriate ulimits for the deployment.

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.

The head databases are dynamically created and maintained by the Backup Daemon. They reside on the disk partition specified in the conf-daemon.properties file.

Production Install with Redundant Metadata and Snapshots

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

This deployment does not provide high availability: the deployment cannot accept writes to a database if a data-bearing replica set member is lost. Ops Manager uses w: 2 write concern, with requires acknowledgement from both data-bearing members in order write to the database.

Important

This deployment does not provide high availability for the Ops Manager application. Specifically, the loss of one data-bearing node from the Ops Manager Application Database must be remedied before the Ops Manager application can resume healthy operation.

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

Server 1 must satisfy the combined hardware and software requirements for the Ops Manager Application hardware and Ops Manager Application Database hardware.

Server 2 must satisfy the combined hardware and software requirements for the Backup Daemon hardware and Backup Database hardware. The Backup Daemon automatically creates and maintains the head databases, which reside on the disk partition specified in the conf-daemon.properties file. Do not place the head databases on the same disk partition as the Backup Database, as this will reduce Backup’s performance.

Server 3 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. Server 3 must satisfy the combined hardware and software requirements for the Ops Manager Application Database hardware and Backup Database hardware.

For an example tutorial on installing the minimally viable Ops Manager installation on RHEL 6+ or Amazon Linux, see Install a Basic Production Deployment on RHEL or Amazon Linux.

Note

Durable Metadata and Snapshots

To make the Ops Manager Application and Backup Databases durable, run each three-member with three data-bearing members and ensure journaling is enabled.

Production Install with a 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 two Backup deployments, and an additional server to host the arbiters for each replica set.

Deploy an HTTP Load Balancer to balance the HTTP traffic for the Ops Manager HTTP Service and Backup service. Ops Manager does not supply an HTTP Load Balancer: you must deploy and configure it yourself.

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.

  • Server 1 and Server 2 must satisfy the combined hardware and software requirements for the Ops Manager Application hardware and Ops Manager Application Database hardware.

  • Server 3, Server 4, Server 5, and Server 6 must satisfy the combined hardware and software requirements for the Backup Daemon hardware and Backup Database hardware.

    The Backup Daemon creates and maintains the head databases, which reside on the disk partition specified in the conf-daemon.properties file. 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.

    For best performance, each Backup server should have 2 partitions. One for the Backup Database, and one for the head databases.

  • Server 7 and Server 8 host secondaries for the Ops Manager Application Database, and for the two Backup Databases. They must satisfy the combined hardware and software requirements for the databases.

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

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.