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.

Install a Basic Production Deployment on RHEL or Amazon Linux

Note

For an evaluation tutorial that involves only a single server, see Install a Simple Test Ops Manager Installation.

Overview

For an overview of the Ops Manager components, see Ops Manager Architecture.

This tutorial installs a minimally viable Ops Manager deployment to servers that run either RHEL 6+ or Amazon Linux. The deployment provides full monitoring, automation, and backup functionality.

The deployment uses three servers. On the first, Ops Manager runs without the Backup Daemon enabled. On the second, Ops Manager runs with the Backup Daemon enabled. The Ops Manager Application Database and the Backup Database run as three-member replica sets, each with two data-bearing members and an arbiter spread across the three servers.

The replica sets provide redundancy for your application and backup data in case of failure. The deployment does not provide high availability and cannot continue to accept writes to a backing database that loses a replica set member.

To install Ops Manager using a different configuration or operating system, see Install Ops Manager.

The following diagram shows the deployment.

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

Prerequisites

Hardware Requirements

The servers must meet the Hardware Requirements described on the Ops Manager System Requirements page. When a server hosts multiple components, you must sum the requirements for each component to determine the requirements for the server.

Warning

Failure to configure servers according to the Ops Manager System Requirements, including the requirement to read the MongoDB Production Notes, can lead to production failure.

The size of the Backup Database depends on whether you store snapshots in the Backup Database or on your file system.

Permissions and Networking Requirements

You must have root access on the servers on which you will install Ops Manager.

Firewall rules must allow the following:

  • An ssh port, usually port 22, must provide access to system administrators.
  • Port 8080 of the Ops Manager server, server 1, must allow users to connect to Ops Manager.
  • The three servers must be able to connect with each other on all MongoDB ports.

Procedures

The following procedures prepare the servers, install the databases, and install Ops Manager. Perform the procedures in sequence.

Prepare Each Server

Provision servers that meet the Hardware Requirements described on the Ops Manager System Requirements page.

Then prepare each server as follows:

1

Increase each server’s default ulimit settings.

RHEL and CentOS 6 limit the maximum number of user processes to 1024. This overrides the general user process limit (ulimit -u) setting.

If a /etc/security/limits.d/99-mongodb-nproc.conf user process configuration file does not exist, create it. In this file, add soft and hard nproc (number of processes) entries with values that are larger than the RHEL 1024 user process limit. Use the contents of the /etc/security/limits.d/90-nproc.conf file as a template.

For more information, see UNIX ulimit Settings in the MongoDB manual.

2

Install MongoDB on each server.

First, set up a repository definition by issuing the following command:

echo "[mongodb-org-3.2]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.2/x86_64/
gpgcheck=0
enabled=1" | sudo tee -a /etc/yum.repos.d/mongodb-org-3.2.repo

Second, install MongoDB by issuing the following command:

sudo yum install -y mongodb-org mongodb-org-shell

Install the Ops Manager Application Database

Install the Ops Manager Application Database as a three-member replica set.

Note

Ops Manager cannot deploy its own backing databases. You must install those databases manually.

1

Create a data directory on each server.

The Ops Manager Application Database uses server 1 for the primary, server 2 for the arbiter, and server 3 for the secondary. Create a data directory on each server and set mongod as the directory’s owner. For example:

sudo mkdir -p /data/appdb
sudo chown mongod:mongod /data /data/appdb
2

Start each MongoDB instance.

For each replica set member, start the mongod daemon and specify “mongod” as the user. Start each instance on its own dedicated port number and with the data directory you created in the previous step. Specify the same replica set for all three members.

The following command starts a MongoDB instance as part of a replica set named appdb and specifies the /data/appdb data directory.

sudo -u mongod mongod --port 27017 --dbpath /data/appdb --replSet appdb --logpath /data/appdb/mongodb.log --fork

After you complete this step, you should have mongod instances running on server1, server2, and server3.

3

Connect to the MongoDB instance that will host the database’s primary.

Connect to the MongoDB instance running on server 1, which is the server that hosts the Ops Manager Application Database’s primary. For example, the following command connects on port 27017 to a MongoDB instance running on mongodb1.example.net:

mongo --host mongodb1.example.net --port 27017

Once you are connected, your command prompt changes to >.

4

Initiate the replica set.

Issue the following command, which returns 1 when the replica set successfully initiates:

rs.initiate()

MongoDB returns 1 and creates a replica set with the current member as the initial member. The command prompt displays the current state of the member. When the member becomes primary, prompt displays PRIMARY>.

5

Add the remaining members to the replica set.

Add the mongod instances running on server 3 and server 2 as a secondary and an arbiter, respectively. Add the secondary first. For example, the following two commands add MongoDB instances running on mongodb3.example.net and on mongodb2.example.net:

rs.add('mongodb3.example.net:27017')
rs.addArb('mongodb2.example.net:27017')
6

Verify the replica set configuration.

To verify that the configuration includes the three members, issue rs.conf():

rs.conf()

The method returns output similiar to the following.

{
    "_id" : "appdb",
    "version" : 3,
    "members" : [
        {
            "_id" : 0,
            "host" : "mongodb1.example.net:27017"
        },
        {
            "_id" : 1,
            "host" : "mongodb3.example.net:27017"
        },
        {
            "_id" : 2,
            "host" : "mongodb2.example.net:27017",
            "arbiterOnly" : true
        }
    ]
}

Optionally, connect to the MongoDB instances running on the other two servers and verify that server 3 has the SECONDARY> prompt and server 2 has the ARBITER> prompt.

For more information on deploying replica sets, see Deploy a Replica Set in the MongoDB manual.

Install the Backup Database

Install the Backup Database as a three-member replica set.

1

Create a data directory on each server.

The Backup Database uses server 1 for the arbiter, server 2 for the primary, and server 3 for the secondary. Create a data directory on each server and set mongod as the directory’s owner. For example:

sudo mkdir -p /data /data/blockstore
sudo chown mongod:mongod /data /data/blockstore
2

Start each MongoDB instance.

For each replica set member, start the mongod daemon and specify “mongod” as the user. Start each instance on its own dedicated port number and with the data directory you created in the previous step. Use a different port number from the port used for the MongoDB instance hosting the Ops Manager Application Database. Specify the same replica set for all three members.

The following command starts a MongoDB instance as part of a replica set named blockstore, specifies the /data/blockstore data directory, and uses port 27018:

sudo -u mongod mongod --port 27018 --dbpath /data/blockstore --replSet blockstore --logpath /data/blockstore/mongodb.log --fork

After you complete this step, you should have new mongod instances running on server1, server2, and server3.

3

Connect to the MongoDB instance that will host the database’s primary.

Connect to the MongoDB instance running on server 2, which is the server that hosts the Backup Database’s primary. Make sure to connect on the correct port number for the MongoDB instance that hosts the Backup Database.

For example, the following command connects on port 27018 to a MongoDB instance running on mongodb2.example.net:

mongo --host mongodb2.example.net --port 27018

Once you are connected, your command prompt changes to >.

4

Initiate the replica set.

Issue the following command, which returns 1 when the replica set successfully initiates:

rs.initiate()

MongoDB returns 1 and creates a replica set with the current member as the initial member. The command prompt displays the current state of the member. When the member becomes primary, prompt displays PRIMARY>.

5

Add the remaining members to the replica set.

Add the mongod instances running on server 3 and server 1 as a secondary and an arbiter, respectively. Add the secondary first. For example, the following two commands add MongoDB instances running on mongodb3.example.net and on mongodb1.example.net:

rs.add('mongodb3.example.net:27018')
rs.addArb('mongodb1.example.net:27018')
6

Verify the replica set configuration.

To verify that the configuration includes the three members, issue rs.conf():

rs.conf()

The method returns output similiar to the following.

{
    "_id" : "blockstore",
    "version" : 3,
    "members" : [
        {
            "_id" : 0,
            "host" : "mongodb2.example.net:27018"
        },
        {
            "_id" : 1,
            "host" : "mongodb3.example.net:27018"
        },
        {
            "_id" : 2,
            "host" : "mongodb1.example.net:27018",
            "arbiterOnly" : true
        }
    ]
}

Optionally, connect to the MongoDB instances running on port 27018 on the other two servers and verify that server 3 has the SECONDARY> prompt and server 1 has the ARBITER> prompt.

For more information on deploying replica sets, see Deploy a Replica Set in the MongoDB manual.

Install Ops Manager

Install Ops Manager on server 1 and server 2.

1

Download the latest version of the Ops Manager package.

  1. In a browser, go to http://www.mongodb.com and click on the Download button.
  2. Complete the form.
  3. On the MongoDB Download Center page, click on the Ops Manager tab.
  4. Select RedHat 6+ / CentOS 6+ / SUSE 11+ / Amazon Linux from the Platforms drop-down menu.
  5. Select RPM from the Packages drop-down menu.
  6. Click Download.

Note

The downloaded package is named mongodb-mms-<version>.x86_64.rpm, where <version> is the version number.

2

Install the Ops Manager package on both server 1 and server 2.

Issue rpm --install with root privileges and specify the name of the downloaded package:

sudo rpm --install <downloaded-package>
3

Configure the Ops Manager connection to the Ops Manager Application Database.

On both server 1 and server 2, open /opt/mongodb/mms/conf/conf-mms.properties with root privileges and configure the settings described here, as appropriate.

Configure the following setting to provide the connection string Ops Manager uses to connect to the database:

If you will configure Ops Manager to use the Ops Manager Application Database over SSL, configure the following SSL settings.

Ops Manager also uses these settings for SSL connections to Backup Databases

If you will configure Ops Manager to use Kerberos to manage access to the Ops Manager Application Database, configure the following Kerberos settings:

4
5

Start Ops Manager on server 1.

On server 1, issue the following command:

sudo service mongodb-mms start

Do not start Ops Manager on server 2.

6

Open the Ops Manager home page and register the first user.

  1. Enter the following URL in a browser, where <host> is the fully qualified domain name of server 1:

    http://<host>:8080
    
  2. Click the Register link and follow the prompts to register the first user and create the first group. The first user is automatically assigned the Global Owner role.

7

Configure Ops Manager.

Ops Manager walks you through several configuration pages. Required settings are marked with an asterisk. For more information on a setting, see Ops Manager Configuration. When configuration is complete, Ops Manager opens the Deployment page.

8

Copy the gen.key file from the server 1 to server 2.

Ops Manager requires an identical gen.key file be stored on both servers running Ops Manager and uses the file to encrypt data at rest in the Ops Manager Application Database and Backup Database.

Use scp to copy the gen.key file from the /etc/mongodb-mms/ directory on server 1 to the /etc/mongodb-mms/ directory on server 2. You must copy the gen.key file before starting Ops Manager on server 2.

9

Enable the Backup Daemon.

  1. On server 2, create the directory that will store the head databases. The directory must be:

    • a dedicated disk partition that is not be used for any other purpose.
    • sized appropriately according to the Ops Manager System Requirements.
    • writable by the mongodb-mms user.
  2. Open Ops Manager and make sure you are logged in as the user you registered when installing Ops Manager. This user is the global owner.

  3. Click the Admin link at the top right of the page.

  4. Click the Backup tab.

  5. Follow the prompts to configure the Backup Daemon and Backup Storage.

    Warning

    Once the connection string is saved, any change to the string requires you to restart all Ops Manager instances, including those running enabled Backup Daemons. Making the change and clicking Save is not sufficient. Ops Manager will continue to use the previous string until you restart the instances.

    <hostname>:<port> Enter a comma-separated list of the fully qualified domain names and port numbers for all replica set members for the Backup Database.

    MongoDB Auth Username and

    MongoDB Auth Password

    Enter the user credentials if the database uses authentication.
    Encrypted Credentials Check this if the user credentials use the Ops Manager credentialstool. For more information, see Encrypt User Credentials.
    Use SSL Check this if the database uses SSL. If you select this, you must configure SSL settings Ops Manager. See Ops Manager Configuration.
    Connection Options To add additional connection options, enter them using the MongoDB Connection String URI Format. This field supports un-escaped values only.

Next Steps

To set up a replica set for a test environment, see Test Ops Manager Monitoring. The tutorial populates the replica set with test data, registers a user, and installs the Monitoring and Backup Agents on a client machine in order to monitor the test replica set.