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 Installation Diagrams

On this page

Overview

The following diagrams show example Ops Manager deployments.

Non-Durable, 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.

Durable Production Install

The basic deployment provides durability in case of failure by keeping a redundant copy of the application data and snapshots. However, the basic deployment does not provide high availability and cannot accept writes to the backing databases in the event that a replica set memeber is lost. See Durable, Highly Available Install with Multiple Backup Databases for a deployment that can continue to accept writes with the loss of a member.

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 Blockstore database hardware. The Backup Daemon automatically creates and maintains the head databases. These databases 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 Blockstore database, as this will reduce Backup’s performance.

Server 3 hosts replica set members for the Backup Blockstore and Ops Manager Application databases. 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 Blockstore 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.

Durable, Highly Available Install with Multiple Backup Databases

The following is a highly available deployment that you can scale out to add additional Backup Databases.

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 Blockstore 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. They 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 Blockstore 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 Blockstore databases. They must satisfy the combined hardware and software requirements for the databases.

To deploy 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.