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.

Configure a Highly Available Ops Manager Application

Overview

The Ops Manager Application provides high availability through use of multiple Ops Manager Application servers behind a load balancer and through use of a replica set to host the Ops Manager Application Database.

Multiple Ops Manager Application Servers

The Ops Manager Application’s components are stateless between requests. Any Ops Manager Application server can handle requests as long as all the servers read from the same backing MongoDB instance. If one Ops Manager Application becomes unavailable, another fills requests.

To take advantage of this for high availability, configure a load balancer to balance between the pool of Ops Manager Application servers. Use the load balancer of your choice. Configure each application server’s conf-mms.properties file to point the mms.centralUrl and mms.backupCentralUrl properties to the load balancer. For more information, see Ops Manager Configuration Files.

The mms.remoteIp.header property should reflect the HTTP header set by the load balancer that contains the original client’s IP address, i.e. X-Forwarded-For. The load balancer then manages the Ops Manager HTTP Service and Backup HTTP Service each application server provides.

The Ops Manager Application uses the client’s IP address for auditing, logging, and white listing for the API.

Replica Set for the Backing Instance

Deploy a replica set rather than a standalone as the backing MongoDB instance that hosts the Ops Manager Application Database. Replica sets have automatic failover if the primary becomes unavailable.

If the replica set has members in multiple facilities, ensure that a single facility has enough votes to elect a primary if needed. Choose the facility that hosts the core application systems. Place a majority of voting members and all the members that can become primary in this facility. Otherwise, network partitions could prevent the set from being able to form a majority. For details on how replica sets elect primaries, see Replica Set Elections.

You can create backups of the replica set using file system snapshots. File system snapshots use system-level tools to create copies of the device that holds replica set’s data files.

The gen.key File

Ops Manager requires an identical gen.key file be stored on each server hosting an Ops Manager Application or Backup Daemon. The gen.key is a binary file of 24 random bytes. Ops Manager uses the file to encrypt data at rest in the databases and to encrypt credentials via the credentials tool.

You can create the gen.key ahead of time and distribute it to each server, or you can let the Ops Manager Application create the file for you. If you choose the latter, you must start one Ops Manager Application and copy the generated gen.key to the other servers before starting the other Ops Manager Applications. An Ops Manager Application will create a gen.key upon initial startup if no gen.key exists.

If you choose to create the gen.key ahead of time, before starting any of the Ops Manager Applications, you can use the OpenSSL rand command. For example:

openssl rand 24 > /etc/mongodb-mms/gen.key

The gen.key file is located in /etc/mongodb-mms/ for installations from a package manager and in ${HOME}/.mongodb-mms/ for installations from an archive.

Prerequisites

Deploy the replica set that hosts the Ops Manager Application Database. To deploy a replica set, see Deploy a Replica Set in the MongoDB manual.

Procedure

The following procedure assumes you will let one of the Ops Manager Applications create the gen.key. If you instead create your own gen.key, distribute it to the servers before starting any of the Ops Manager Applications.

To configure multiple Ops Manager Applications with load balancing:

1

Configure a load balancer with the pool of Ops Manager Application servers.

This configuration depends on the general configuration of your load balancer and environment.

2

Update each Ops Manager Application server with the load balanced URL.

On each server, edit the conf-mms.properties file to configure the mms.centralUrl and mms.backupCentralUrl properties to point to the load balancer URL.

The conf-mms.properties file is located in the <install_dir>/conf/ directory. See Ops Manager Configuration Files for more information.

3

Update each Ops Manager Application server with the replication hosts information.

On each server, edit the conf-mms.properties file to set the mongo.mongoUri property to the connection string of the Ops Manager Application Database. You must specify at least 3 hosts in the mongo.mongoUri connection string. For example:

mongo.mongoUri=mongodb://<mms0.example.net>:<27017>,<mms1.example.net>:<27017>,<mms2.example.net>:<27017>/?maxPoolSize=100
4

Start one of the Ops Manager Applications.

For example, if you installed the Ops Manager Application with an rpm or deb package, issue the following:

service mongodb-mms start
5

Copy the gen.key file.

The gen.key file is located in /etc/mongodb-mms/ for installations from a package manager and in ${HOME}/.mongodb-mms/ for installations from an archive.

Copy the gen.key file from the running Ops Manager Application’s server to the appropriate directory on the other Ops Manager Application servers.

6

Start the remaining Ops Manager Applications.

Additional Information

For information on making Ops Manager Backup highly available, see Configure a Highly Available Ops Manager Backup Service.