MongoDB Ops Manager Manual Opsmanager V1.6

opsmanager-manual-v1.6

User Manual:

Open the PDF directly: View PDF .
Page Count: 457 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Ops Manager Introduction
Install Ops Manager
Create a New MongoDB Deployment
Import an Existing MongoDB Deployment
Manage Deployments
Back Up MongoDB Deployments
Security
Administration
API
Troubleshooting
Frequently Asked Questions
Reference
Release Notes

MongoDB Ops Manager Manual

Release 1.6

MongoDB, Inc.

Dec 04, 2017

Contents

1 Ops Manager Introduction 11

1.1 Functional Overview ........................................... 11

Overview ................................................. 12

Monitoring ................................................ 12

Automation ................................................ 12

Backup .................................................. 12

1.2 Ops Manager Components ........................................ 13

Network Diagram ............................................. 14

Ops Manager Application ......................................... 14

Backup Daemon .............................................. 15

Dedicated MongoDB Databases for Operational Data .......................... 15

1.3 Install a Simple Test Ops Manager Installation .............................. 16

Overview ................................................. 16

Procedure ................................................. 16

2 Install Ops Manager 20

2.1 Installation Checklist ........................................... 20

Overview ................................................. 20

Topology Decisions ............................................ 21

Security Decisions ............................................ 23

Backup Decisions ............................................. 23

2.2 Example Installation Diagrams ...................................... 23

Overview ................................................. 24

Non-Durable, Test Install on a Single Server ............................... 24

Durable Production Install ........................................ 24

Durable, Highly Available Install with Multiple Backup Databases ................... 25

2.3 Ops Manager Hardware and Software Requirements ........................... 27

Hardware Requirements ......................................... 27

EC2 Security Groups ........................................... 30

Software Requirements .......................................... 30

2.4 Deploy Backing MongoDB Replica Sets ................................. 32

Overview ................................................. 32

Replica Sets Requirements ........................................ 32

Server Prerequisites ............................................ 33

Procedures ................................................. 33

2.5 Install Ops Manager ............................................ 35

Install Ops Manager with deb Packages ................................. 35

Install Ops Manager with rpm Packages ................................. 40

Install Ops Manager from tar.gz or zip Archives .......................... 45

Install Ops Manager on Windows ..................................... 50

2.6 Upgrade Ops Manager .......................................... 54

Upgrade Ops Manager with deb Packages ................................ 54

Upgrade Ops Manager with rpm Packages ................................ 57

Upgrade Ops Manager from tar.gz or zip Archives ......................... 61

Upgrade from Version 1.2 and Earlier .................................. 64

2.7 Conﬁgure Local Mode if Ops Manager has No Internet Access ..................... 65

Overview ................................................. 66

Prerequisites ................................................ 66

Required Access ............................................. 68

Procedure ................................................. 68

2.8 Conﬁgure High Availability ........................................ 70

Conﬁgure a Highly Available Ops Manager Application ......................... 70

Conﬁgure a Highly Available Ops Manager Backup Service ...................... 72

2.9 Conﬁgure Backup Jobs and Storage ................................... 73

Conﬁgure Multiple Blockstores in Multiple Data Centers ........................ 73

Move Jobs from a Lost Backup Service to another Backup Service ................... 76

2.10 Test Ops Manager Monitoring ...................................... 77

Overview ................................................. 78

Procedure ................................................. 78

3 Create a New MongoDB Deployment 80

3.1 Add Servers for Use by Automation ................................... 80

Overview ................................................. 80

Add Existing Servers to Ops Manager .................................. 81

3.2 Deploy a Replica Set ........................................... 82

Overview ................................................. 82

Consideration ............................................... 83

Prerequisites ................................................ 83

Procedure ................................................. 83

3.3 Deploy a Sharded Cluster ......................................... 84

Overview ................................................. 84

Prerequisites ................................................ 84

Procedure ................................................. 84

3.4 Deploy a Standalone MongoDB Instance ................................. 85

Overview ................................................. 85

Prerequisites ................................................ 85

Procedure ................................................. 86

3.5 Connect to a MongoDB Process ..................................... 86

Overview ................................................. 86

Firewall Rules ............................................... 86

Procedures ................................................. 87

4 Import an Existing MongoDB Deployment 88

4.1 Add Existing MongoDB Processes to Monitoring ............................ 88

Overview ................................................. 88

Prerequisite ................................................ 89

Add MongoDB Processes ......................................... 89

4.2 Add Monitored Processes to Automation ................................. 90

Overview ................................................. 90

Prerequisites ................................................ 90

Procedures ................................................. 91

4.3 Reactivate Monitoring for a Process ................................... 92

Overview ................................................. 92

Procedure ................................................. 92

4.4 Remove Hosts ............................................... 93

Overview ................................................. 93

Procedure ................................................. 93

5 Manage Deployments 93

5.1 Edit a Replica Set ............................................. 94

Overview ................................................. 94

Procedures ................................................. 94

Additional Information .......................................... 97

5.2 Migrate a Replica Set Member to a New Server ............................. 97

Overview ................................................. 98

Considerations .............................................. 98

Procedure ................................................. 98

5.3 Move or Add a Monitoring or Backup Agent ............................... 99

Overview ................................................. 100

Procedures ................................................. 100

5.4 Change the Version of MongoDB ..................................... 101

Overview ................................................. 101

Considerations .............................................. 102

Procedure ................................................. 102

5.5 Restart a MongoDB Process ....................................... 102

Overview ................................................. 103

Considerations .............................................. 103

Procedure ................................................. 103

5.6 Shut Down MongoDB Processes ..................................... 103

Overview ................................................. 104

Procedure ................................................. 104

Additional Information .......................................... 104

5.7 Remove Processes from Monitoring ................................... 104

Overview ................................................. 104

Considerations .............................................. 105

Procedure ................................................. 105

5.8 Alerts ................................................... 105

Manage Host Alerts ............................................ 105

Create an Alert Conﬁguration ....................................... 105

Manage Alert Conﬁguration ....................................... 108

Manage Alerts ............................................... 110

Alert Conditions .............................................. 112

5.9 Monitoring Metrics ............................................ 119

Deployment ................................................ 119

Host Statistics ............................................... 120

Aggregated Cluster Statistics ....................................... 122

Replica Set Statistics ........................................... 123

Proﬁle Databases ............................................. 124

5.10 View Logs ................................................. 126

Overview ................................................. 127

MongoDB Real-Time Logs ........................................ 127

MongoDB On-Disk Logs ......................................... 128

Agent Logs ................................................ 128

6 Back Up MongoDB Deployments 129

6.1 Backup Flows ............................................... 130

Introduction ................................................ 130

Initial Sync ................................................ 130

Routine Operation ............................................. 131

Snapshots ................................................. 131

Grooms .................................................. 132

6.2 Backup Preparations ........................................... 132

Overview ................................................. 132

Snapshot Frequency and Retention Policy ................................ 132

Excluded Namespaces .......................................... 133

Storage Engine .............................................. 133

Resyncing Production Deployments ................................... 133

Checkpoints ................................................ 133

Snapshots when Agent Cannot Stop Balancer .............................. 134

Snapshots when Agent Cannot Contact a mongod ........................... 134

6.3 Activate Backup .............................................. 134

Overview ................................................. 134

Prerequisites ................................................ 134

Procedure ................................................. 134

6.4 Edit a Backup’s Settings ......................................... 135

Overview ................................................. 136

Procedure ................................................. 136

6.5 Restore MongoDB Deployments ..................................... 138

Restore Flows ............................................... 138

Restore a Sharded Cluster from a Backup ................................ 142

Restore a Replica Set from a Backup ................................... 151

6.6 Restore MongoDB Instances with Backup ................................ 156

Restore from a Stored Snapshot ..................................... 157

Retrieve a Snapshot with SCP Delivery ................................. 159

Restore from a Point in the Last 24 Hours ................................ 160

Restore a Single Database ........................................ 160

Seed a New Secondary from Backup Restore .............................. 162

6.7 Backup Maintenance ........................................... 164

Select Backup File Delivery Method and Format ............................. 164

Delete Snapshots for Replica Sets and Sharded Clusters ......................... 166

Stop, Start, or Disable the Ops Manager Backup Service ........................ 166

Resync Backup .............................................. 168

7 Security 170

7.1 Security Overview ............................................ 170

Overview ................................................. 170

Security Options ............................................. 171

Supported User Authentication Per Release ............................... 171

Supported MongoDB Security Features on Linux ............................ 171

Supported MongoDB Security Features on Windows .......................... 172

7.2 Firewall Conﬁguration .......................................... 173

Overview ................................................. 173

Ports .................................................... 173

Monitoring HTTP Endpoints ....................................... 174

7.3 Change the Ops Manager Ports ...................................... 175

Overview ................................................. 175

Procedures ................................................. 175

7.4 Conﬁgure SSL Connections to Ops Manager ............................... 178

Overview ................................................. 178

Run the Ops Manager Application Over HTTPS ............................. 178

7.5 Conﬁgure the Connections to the Backing MongoDB Instances ..................... 179

Overview ................................................. 179

Prerequisites ................................................ 179

Procedures ................................................. 179

7.6 Conﬁgure SSL for MongoDB ....................................... 182

Overview ................................................. 182

Procedures ................................................. 183

7.7 Conﬁgure Users and Groups with LDAP for Ops Manager ....................... 183

Overview ................................................. 184

Prerequisites ................................................ 185

Procedure ................................................. 185

7.8 Conﬁgure MongoDB Authentication and Authorization ......................... 186

Overview ................................................. 187

Access Control Mechanisms ....................................... 187

Edit Host Credentials ........................................... 187

7.9 Manage Two-Factor Authentication for Ops Manager .......................... 189

Overview ................................................. 189

Procedures ................................................. 190

7.10 Manage Your Two-Factor Authentication Options ............................ 191

Overview ................................................. 191

Procedures ................................................. 192

8 Administration 194

8.1 Manage Your Account .......................................... 194

Account Page ............................................... 195

Personalization Page ........................................... 195

API Keys & Whitelists Page ....................................... 196

My Groups Page ............................................. 196

Group Settings Page ........................................... 196

Users Page ................................................ 196

Agents Page ................................................ 196

Billing/Subscriptions ........................................... 196

Payment History ............................................. 196

8.2 Administer the System .......................................... 197

General Tab ................................................ 197

Backup Tab ................................................ 199

Control Panel Tab ............................................. 203

8.3 Manage Groups .............................................. 204

Overview ................................................. 204

Working with Multiple Environments .................................. 204

Procedures ................................................. 204

8.4 Manage Ops Manager Users and Roles .................................. 206

Manage Ops Manager Users ....................................... 206

Ops Manager Roles ............................................ 208

8.5 Manage MongoDB Users and Roles ................................... 212

Enable MongoDB Role-Based Access Control .............................. 212

Manage MongoDB Users and Roles ................................... 213

Manage Custom Roles .......................................... 215

8.6 Conﬁgure Available MongoDB Versions ................................. 218

Overview ................................................. 218

Procedure ................................................. 219

8.7 Backup Alerts ............................................... 219

Backup Agent Down ........................................... 219

Backups Broken .............................................. 219

Cluster Snapshot Failed .......................................... 220

Bind Failure ................................................ 220

Snapshot Behind Snitch .......................................... 220

8.8 Start and Stop Ops Manager Application ................................. 220

Start the Ops Manager Server ....................................... 221

Stop the Ops Manager Server ....................................... 221

Startup Log File Output .......................................... 221

Optional: Run as Different User ..................................... 222

Optional: Ops Manager Application Server Port Number ........................ 222

8.9 Back Up Ops Manager .......................................... 222

Back Up with the Public API ....................................... 223

Shut Down and Back Up ......................................... 223

Online Backup .............................................. 223

9 API 223

9.1 Public API Principles ........................................... 223

Overview ................................................. 224

HTTP Methods .............................................. 224

JSON ................................................... 224

Linking .................................................. 225

Lists .................................................... 226

Envelopes ................................................. 226

Pretty Printing ............................................... 227

Response Codes .............................................. 227

Errors ................................................... 227

Authentication ............................................... 228

Automation ................................................ 228

Additional Information .......................................... 228

9.2 Public API Resources ........................................... 228

Root .................................................... 229

Hosts ................................................... 230

Metrics .................................................. 236

Clusters .................................................. 241

Groups ................................................... 244

Users ................................................... 249

Alerts ................................................... 255

Alert Conﬁgurations ........................................... 261

Backup Conﬁgurations .......................................... 270

Snapshot Schedule ............................................ 274

Snapshots ................................................. 276

Restore Jobs ................................................ 280

Whitelist .................................................. 285

Automation Conﬁguration ........................................ 288

Automation Status ............................................ 295

9.3 Public API Tutorials ........................................... 297

Enable the Public API ........................................... 297

Deploy a Cluster through the API .................................... 299

Update the MongoDB Version of a Deployment ............................. 307

10 Troubleshooting 310

10.1 Getting Started Checklist ......................................... 310

Authentication Errors ........................................... 310

Check Agent Output or Log ....................................... 310

Conﬁrm Only One Agent is Actively Monitoring ............................ 310

Ensure Connectivity Between Agent and Monitored Hosts ....................... 311

Ensure Connectivity Between Agent and Ops Manager Server ..................... 311

Allow Agent to Discover Hosts and Collect Initial Data ......................... 311

10.2 Installation ................................................ 311

Why doesn’t the monitoring server startup successfully? ........................ 311

10.3 Monitoring ................................................ 311

Alerts ................................................... 311

Deployments ............................................... 312

Monitoring Agent Fails to Collect Data ................................. 313

Hosts ................................................... 313

Groups ................................................... 313

Munin ................................................... 314

10.4 Authentication ............................................... 315

Two-Factor Authentication ........................................ 315

LDAP ................................................... 315

Cannot Enable LDAP ........................................... 315

Forgot to Change MONGODB-CR Error ................................. 316

All Deployments ............................................. 316

10.5 Backup .................................................. 317

Logs Display MongodVersionException ................................. 317

10.6 System ................................................... 318

Logs Display OutOfMemoryError .................................... 318

10.7 Automation Checklist ........................................... 318

11 Frequently Asked Questions 318

11.1 Monitoring FAQs ............................................. 319

Host Conﬁguration ............................................ 319

Monitoring Agent ............................................. 319

Data Presentation ............................................. 321

Data Retention .............................................. 322

11.2 Backup FAQs ............................................... 322

Requirements ............................................... 322

Interface .................................................. 323

Operations ................................................. 323

Conﬁguration ............................................... 325

Restoration ................................................ 325

11.3 Administration FAQs ........................................... 328

User and Group Management ....................................... 328

Activity .................................................. 328

Operations ................................................. 329

About Ops Manager ............................................ 329

12 Reference 329

12.1 Ops Manager Conﬁguration Files ..................................... 330

Overview ................................................. 330

Settings .................................................. 331

Encrypt MongoDB User Credentials ................................... 345

MongoDB User Access .......................................... 346

12.2 Automation Agent ............................................ 346

Install the Automation Agent ....................................... 346

Automation Agent Conﬁguration ..................................... 355

12.3 Monitoring Agent ............................................. 358

Install Monitoring Agent ......................................... 358

Monitoring Agent Conﬁguration ..................................... 374

Required Access for Monitoring Agent .................................. 377

Conﬁgure Monitoring Agent for Access Control ............................. 380

Conﬁgure Monitoring Agent for SSL ................................... 385

Conﬁgure Hardware Monitoring with munin-node .......................... 387

Start or Stop the Monitoring Agent .................................... 389

Remove Monitoring Agents from Ops Manager ............................. 391

12.4 Backup Agent ............................................... 392

Install Backup Agent ........................................... 392

Backup Agent Conﬁguration ....................................... 410

Required Access for Backup Agent .................................... 412

Conﬁgure Backup Agent for Access Control ............................... 414

Conﬁgure Backup Agent for SSL ..................................... 421

Start or Stop the Backup Agent ...................................... 422

Remove the Backup Agent from Ops Manager .............................. 424

12.5 Audit Events ............................................... 425

User Audits ................................................ 425

Host Audits ................................................ 426

Alert Conﬁg Audits ............................................ 427

Backup Audits .............................................. 427

Group Audits ............................................... 428

12.6 Monitoring Reference ........................................... 428

Host Types ................................................ 428

Host Process Types ............................................ 429

Event Types ................................................ 429

Alert Types ................................................ 429

Chart Colors ................................................ 429

Database Commands Used by the Monitoring Agent .......................... 430

12.7 Supported Browsers ............................................ 431

12.8 Advanced Options for MongoDB Deployments ............................. 431

Overview ................................................. 431

Advanced Options ............................................. 431

12.9 Automation Conﬁguration ........................................ 432

Overview ................................................. 433

Fields ................................................... 433

12.10Supported MongoDB Options for Automation .............................. 445

Overview ................................................. 445

MongoDB 2.6 and Later Conﬁguration Options ............................. 445

MongoDB 2.4 and Earlier Conﬁguration Options ............................ 447

13 Release Notes 448

13.1 Ops Manager Server Changelog ..................................... 448

Ops Manager Server 1.6.4 ........................................ 448

Ops Manager Server 1.6.3 ........................................ 448

Ops Manager Server 1.6.2 ........................................ 448

Ops Manager Server 1.6.1 ........................................ 449

Ops Manager Server 1.6.0 ........................................ 449

MMS Onprem Server 1.5.5 ........................................ 450

MMS Onprem Server 1.5.4 ........................................ 450

MMS OnPrem Server 1.5.3 ........................................ 451

MMS OnPrem Server 1.5.2 ........................................ 451

MMS OnPrem Server 1.5.1 ........................................ 451

MMS OnPrem Server 1.5.0 ........................................ 451

MMS OnPrem Server 1.4.3 ........................................ 452

MMS OnPrem Server 1.4.2 ...................................... 453

MMS OnPrem Server 1.4.1 ...................................... 453

MMS OnPrem Server 1.4.0 ...................................... 453

MMS OnPrem Server 1.3.0 ...................................... 453

MMS OnPrem Server 1.2.0 ...................................... 454

13.2 Automation Agent Changelog ...................................... 454

Automation Agent 1.4.18.1199-1 .................................. 454

Automation Agent 1.4.16.1075 ................................... 454

Automation Agent 1.4.15.999 .................................... 454

Automation Agent 1.4.14.983 .................................... 454

13.3 Monitoring Agent Changelog ....................................... 455

Monitoring Agent 2.9.2.184 ..................................... 455

Monitoring Agent 2.9.1.176 ..................................... 455

Monitoring Agent 2.4.2.113 ..................................... 455

Monitoring Agent 2.3.1.89-1 .................................... 455

Monitoring Agent 2.1.4.51-1 .................................... 456

Monitoring Agent 2.1.3.48-1 .................................... 456

Monitoring Agent 2.1.1.41-1 .................................... 456

Monitoring Agent 1.6.6 ........................................ 456

13.4 Backup Agent Changelog ......................................... 456

Backup Agent 3.1.2.274 ....................................... 456

Backup Agent 3.1.1.263 ....................................... 456

Backup Agent 2.3.3.209-1 ...................................... 457

Backup Agent 2.3.1.160 ....................................... 457

Backup Agent 1.5.1.83-1 ...................................... 457

Backup Agent 1.5.0.57-1 ...................................... 457

Backup Agent 1.4.6.42-1 ...................................... 457

Ops Manager is a package for managing MongoDB deployments. Ops Manager provides Ops Manager Monitoring

and Ops Manager Backup, which helps users optimize clusters and mitigate operational risk.

You can also download a PDF edition of the Ops Manager Manual.

Introduction Describes Ops Manager components and provides steps to install a test deployment.

Install Ops Manager Install Ops Manager.

Create New Deployments Set up servers and create MongoDB deployments.

Import Existing Deployments Import your existing MongoDB deployments to Ops Manager.

Manage Deployments Monitor, update, and manage your deployments.

Back Up Deployments Initiate and restore backups.

Security Describes Ops Manager security features.

Administration Conﬁgure and manage Ops Manager.

API Manage Ops Manager through the API.

Troubleshooting Troubleshooting advice for common issues.

Frequently Asked Questions Common questions about the operation and use of Ops Manager.

Reference Reference material for Ops Manager components and operations.

Release Notes Changelogs and notes on Ops Manager releases.

1 Ops Manager Introduction

Functional Overview Describes Ops Manager services and operations.

Ops Manager Components Describes Ops Manager components.

Install a Simple Test Ops Manager Set up a simple test installation in minutes.

1.1 Functional Overview

On this page

•Overview

•Monitoring

•Automation

•Backup

Overview

MongoDB Ops Manager is a service for managing, monitoring and backing up a MongoDB infrastructure. Ops

Manager provides the services described here.

Monitoring

Ops Manager Monitoring provides real-time reporting, visualization, and alerting on key database and hardware indi-

cators.

How it Works: A lightweight Monitoring Agent runs within your infrastructure and collects statistics from the nodes

in your MongoDB deployment. The agent transmits database statistics back to Ops Manager to provide real-time

reporting. You can set alerts on indicators you choose.

Automation

Ops Manager Automation provides an interface for conﬁguring MongoDB nodes and clusters and for upgrading your

MongoDB deployment.

How it Works: Automation Agents on each server maintain your deployments. The Automation Agent also maintains

the Monitoring and Backup agents and starts, restarts, and upgrades the agents as needed.

Automation allows only one agent of each type per machine and will remove additional agents. For example, when

maintaining Backup Agents, automation will remove a Backup Agent from a machine that has two Backup Agents.

Backup

Ops Manager Backup provides scheduled snapshots and point-in-time recovery of your MongoDB replica sets and

sharded clusters.

How it Works: A lightweight Backup Agent runs within your infrastructure and backs up data from the MongoDB

processes you have speciﬁed.

Data Backup

When you start Backup for a MongoDB deployment, the agent performs an initial sync of the deployment’s data as

if it were creating a new, “invisible” member of a replica set. For a sharded cluster the agent performs a sync of

each shard’s primary and of each conﬁg server. The agent ships initial sync and oplog data over HTTPS back to Ops

Manager.

The Backup Agent then tails each replica set’s oplog to maintain on disk a standalone database, called a head database.

Ops Manager maintains one head database for each backed-up replica set. The head database is consistent with the

original primary up to the last oplog supplied by the agent.

Backup performs the initial sync and the tailing of the oplog using standard MongoDB queries. The production replica

set is not aware of the copy of the backup data.

Backup uses a mongod with a version equal to or greater than the version of the replica set it backs up.

Backup takes and stores snapshots based on a user-deﬁned snapshot retention policy. Sharded clusters snapshots

temporarily stop the balancer via the mongos so that they can insert a marker token into all shards and conﬁg servers

in the cluster. Ops Manager takes a snapshot when the marker tokens appear in the backup data.

Compression and block-level de-duplication technology reduce snapshot data size. The snapshot only stores the

differences between successive snapshots. Snapshots use only a fraction of the disk space required for full snapshots.

Data Restoration

Ops Manager Backup lets you restore data from a scheduled snapshot or from a selected point between snapshots. For

sharded clusters you can restore from checkpoints between snapshots. For replica sets, you can restore from selected

points in time.

When you restore from a snapshot, Ops Manager reads directly from the Backup Blockstore database and transfers

ﬁles either through an HTTPS download link or by sending them via HTTPS or SCP.

When you restore from checkpoint or point in time, Ops Manager ﬁrst creates a local restore of a snapshot from the

blockstore and then applies stored oplogs until the speciﬁed point is reached. Ops Manager delivers the backup via

the same HTTPS or SCP mechanisms.

The amount of oplog to keep per backup is conﬁgurable and affects the time window available for checkpoint and

point-in-time restores.

1.2 Ops Manager Components

On this page

•Network Diagram

•Ops Manager Application

•Backup Daemon

•Dedicated MongoDB Databases for Operational Data

An Ops Manager installation consists of the Ops Manager Application and optional Backup Daemon. Each package

also requires a dedicated MongoDB database to hold operational data.

Network Diagram

Ops Manager Application

The front-end Ops Manager Application contains the UI the end user interacts with, as well as HTTPS services used

by the Monitoring Agent and Backup Agent to transmit data to and from Ops Manager. All three components start

automatically when the Ops Manager Application starts. These components are stateless. Multiple instances of the

front-end package can run as long as each instance has the same conﬁguration. Users and agents can interact with any

instance.

For Monitoring, you only need to install the application package. The application package consists of the following

components:

•Ops Manager HTTP Service

•Backup HTTP Service

•Backup Alert Service

Ops Manager HTTP Service

The HTTP server runs on port 8080 by default. This component contains the web interface for managing Ops

Manager users, monitoring of MongoDB servers, and managing those server’s backups. Users can sign up, create new

accounts and groups, as well as join an existing group.

Backup HTTP Service

The HTTP server runs on port 8081 by default. The Backup HTTP Service contains a set of web services used by

the Backup Agent. The agent retrieves its conﬁguration from this service. The agent also sends back initial sync and

oplog data through this interface. There is no user interaction with this service. The Backup HTTP service runs on

port 8081 by default.

The Backup HTTP Service exposes an endpoint that reports on the state of the service and the underlying database

to support monitoring of the Backup service. This status also checks the connections from the service to the Ops

Manager Application Database and the Backup Blockstore Database. See Backup HTTP Service Endpoint.

Backup Alert Service

The Backup Alert Service watches the state of all agents, local copies of backed up databases, and snapshots. It sends

email alerts as problems occur. The Backup Alert Service exposes a health-check endpoint. See Backup Alert Service

Endpoint.

Backup Daemon

The Backup Daemon manages both the local copies of the backed-up databases and each backup’s snapshots. The

daemon does scheduled work based on data coming in to the Backup HTTP Service from the Backup Agents. No

client applications talk directly to the daemon. Its state and job queues come from the Ops Manager Application

Database.

The Backup Daemon’s local copy of a backed-up deployment is called the head database. The daemon stores all its

head databases in its rootDirectory path. To create each head database, the daemon’s server acts as though it

were an “invisible” secondary for each replica set designated for backup.

If you run multiple Backup Daemons, Ops Manager selects the Backup Daemon to use when a user enables backup

for a deployment. The local copy of the deployment resides with that daemon’s server.

The daemon will take scheduled snapshots and store the snapshots in the Backup Blockstore database. It will also act

on restore requests by retrieving data from the Blockstore and delivering it to the requested destination.

Multiple Backup Daemons can increase your storage by scaling horizontally and can provide manual failover.

The Backup Daemon exposes a health-check endpoint. See Backup Daemon Endpoint.

Dedicated MongoDB Databases for Operational Data

Ops Manager uses dedicated MongoDB databases to store the Ops Manager Application’s monitoring data and the

Backup Daemon’s snapshots. To ensure redundancy and high availability, the backing databases run as replica sets.

The replica sets host only Ops Manager data. You must set up the backing replica sets before installing Ops Manager.

Ops Manager Application Database

This database contains application metadata used by the Ops Manager Application. The database stores:

• Monitoring data collected from Monitoring Agents.

• Metadata for Ops Manager users, groups, hosts, monitoring data, and backup state.

For topology and speciﬁcations, see Ops Manager Application Database Hardware.

Backup Blockstore Database

This database contains all snapshots of databases backed up and oplogs retained for point in time restores. The Backup

Blockstore database requires disk space proportional to the backed-up databases.

Conﬁgure the Blockstore as a replica set to provide durability and automatic failover to the backup and restore com-

ponents. The replica set must have at least three members that hold data.

You cannot back up the Blockstore database with Ops Manager Backup. To back up Ops Manager Backup, see Back

Up Ops Manager.

For additional speciﬁcations, see Ops Manager Backup Blockstore Database Hardware.

1.3 Install a Simple Test Ops Manager Installation

On this page

•Overview

•Procedure

Overview

To evaluate Ops Manager, you can quickly create a test installation by installing the Ops Manager Application and

Ops Manager Application Database on a single server. This setup provides all the functionality of Ops Manager

monitoring and automation but provides no failover or high availability. This is not a production setup.

Unlike a production installation, the simple test installation uses only one mongod for the Ops Manager Application

database. In production, the database requires a dedicated replica set.

This procedure includes optional instructions to install Ops Manager Backup, in which case you would install the

Backup Daemon and Backup Blockstore database on the same server as the other Ops Manager components. The

Backup Blockstore database uses only one mongod and not a dedicated replica set, as it would in production.

This procedure installs the test deployment on servers running either RHEL 6+ or Amazon Linux.

Procedure

Warning: This setup is not suitable for a production deployment.

To install Ops Manager for evaluation:

Step 1: Set up a RHEL 6+ or Amazon Linux server that meets the following requirements:

• The server must have 15 GB of memory and 50 GB of disk space for the root partition. You can meet the size

requirements by using an Amazon Web Services EC2 m3.xlarge instance and changing the size of the root

partition from 8 GB to 50 GB. When you log into the instance, execute “df -h” to verify the root partition has

50 GB of space.

• You must have root access to the server.

Step 2: Conﬁgure the yum package management system to install the latest stable release of Mon-

goDB.

Issue the following command to set up a yum repository deﬁnition:

echo "[MongoDB]

name=MongoDB Repository

baseurl=http://downloads-distro.mongodb.org/repo/redhat/os/x86_64

gpgcheck=0

enabled=1" | sudo tee /etc/yum.repos.d/mongodb.repo

Step 3: Install MongoDB.

Issue the following command to install the latest stable release of MongoDB:

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

Step 4: Create the data directory for the Ops Manager Application database.

Issue the following two commands to create the data directory and change its ownership:

sudo mkdir -p /data/db

sudo chown -R mongod:mongod /data

OPTIONAL: To also install the Backup feature, issue following additional commands for the Backup Blockstore

database:

sudo mkdir -p /data/backup

sudo chown mongod:mongod /data/backup

Step 5: Start the MongoDB backing instance for the Ops Manager Application database.

Issue the following command to start MongoDB as the mongod user. Start MongoDB on port 27017 and specify

the /data/db for both data ﬁles and logs. Include the --fork option to run the process in the background and

maintain control of the terminal.

sudo -u mongod mongod --port 27017 --dbpath /data/db --logpath /data/db/mongodb.log --

˓→fork

OPTIONAL: To also install the Backup feature, issue following command to start a MongoDB instance similar to the

other but on port 27018 and with the data directory and log path of the Backup Blockstore database:

sudo -u mongod mongod --port 27018 --dbpath /data/backup --logpath /data/backup/

˓→mongodb.log --fork

Step 6: Download the Ops Manager Application package.

1. In a browser, go to http://www.mongodb.com/download.

2. Fill out and submit the subscription form.

3. On the MongoDB Enterprise Downloads page, go to the MongoDB Ops Manager section and click the here

link.

4. On the Ops Manager Download page, acknowledge the recommendation to contact MongoDB for production

installs.

5. On the MongoDB Ops Manager Downloads page, copy the link address of the RPM link for Monitoring, Au-

tomation and Core. OPTIONAL: If you will install Backup, copy the link address of the RPM link for Backup

as well.

6. Open a system prompt.

7. Download the Ops Manager Application package by issuing a curl command that uses the link address copied

for the RPM for Monitoring, Automation and Core:

curl -OL <link-address-for-monitoring-automation-core-rpm>

OPTIONAL: Download the Backup Daemon package by issuing a curl command that uses the link address

copied for the Backup RPM:

curl -OL <link-address-for-backup-rpm>

Step 7: Install the Ops Manager Application.

Install the Monitoring, Automation and Core RPM package that you downloaded. Issue the rpm --install com-

mand with root privileges and specify the package name:

sudo rpm --install <rpm-package-for-monitoring-automation-core>

OPTIONAL: To also install Backup, issue the rpm --install command with root privileges and specify the

Backup RPM package:

sudo rpm --install <rpm-package-for-backup>

Step 8: Get your server’s public IP address.

If you are using an EC2 instance, this is available on the instance’s Description tab.

Alternately, you can get the public IP address by issuing the following:

curl -s http://whatismijnip.nl |cut -d ""-f 5

Step 9: Conﬁgure the Ops Manager Application.

Edit /opt/mongodb/mms/conf/conf-mms.properties with root privileges and set the following options.

For detailed information on each option, see Ops Manager Conﬁguration Files.

Set mms.centralUrl and mms.backupCentralUrl as follows, where <ip_address> is the IP address of

the server running the Ops Manager Application.

mms.centralUrl=http://<ip_address>:8080

mms.backupCentralUrl=http://<ip_address>:8081

Set the following Email Address Settings as appropriate. You can use the same email address throughout, or specify a

different address for each ﬁeld.

mms.fromEmailAddr=<email_address>

mms.replyToEmailAddr=<email_address>

mms.adminFromEmailAddr=<email_address>

mms.adminEmailAddr=<email_address>

mms.bounceEmailAddr=<email_address>

Set the mongo.mongoUri option to the port hosting the Ops Manager Application database:

mongo.mongoUri=mongodb://localhost:27017

OPTIONAL: If you installed the Backup Daemon, edit /opt/mongodb/mms-backup-daemon/conf/

conf-daemon.properties with root privileges and set the mongo.mongoUri value to the port hosting the

Ops Manager Application database:

mongo.mongoUri=mongodb://localhost:27017

Step 10: Start the Ops Manager Application.

To start the Ops Manager Application, issue the following:

sudo service mongodb-mms start

OPTIONAL: To start the Backup Daemon, issue the following:

sudo service mongodb-mms-backup-daemon start

Step 11: Open the Ops Manager home page.

In a browser, enter the following URL, where <ip_address> is the IP address of the server:

http://<ip_address>:8080

Step 12: To begin testing Ops Manager, click Register and follow the prompts to create the ﬁrst user

and group.

The ﬁrst user receives Global Owner permissions for the test install.

Step 13: At the Welcome page, follow the prompts to set up Automation or Monitoring.

Automation lets you deﬁne a MongoDB deployment through the Ops Manager interface and rely on the Automation

Agent to construct the deployment. If you select Automation, Ops Manager prompts you to download the Automation

Agent and Monitoring Agent to the server.

Monitoring lets you manage a MongoDB deployment through the Ops Manager interface. If you select Monitoring,

Ops Manager prompts you to download only the Monitoring Agent to the server.

OPTIONAL: If you installed the Backup Daemon, do the following to enable Backup: click the Admin link

in at the top right of the Ops Manager page and click the Backup tab. In the <hostname>:<port> ﬁeld, enter

localhost:27018 and click Save.

2 Install Ops Manager

Installation Checklist Prepare for your installation.

Example Installation Diagrams Provides diagrams of Ops Manager deployments.

Hardware and Software Requirements Describes the hardware and software requirements for the servers that run the

Ops Manager components, including the servers that run the backing MongoDB replica sets.

Deploy Application and Backup Databases Set up the Ops Manager Application Database and Backup Database.

Install Ops Manager Operating-system speciﬁc instructions for installing the Ops Manager Application and the

Backup Daemon.

Upgrade Ops Manager Operating-system speciﬁc instructions for upgrading the Ops Manager Application and the

Backup Daemon.

Conﬁgure Ofﬂine Binary Access Conﬁgure local mode for an installation that uses Automation but has no internet

access for downloading the MongoDB binaries.

Conﬁgure High Availability Conﬁgure the Ops Manager application and components to be highly available.

Conﬁgure Backup Jobs and Storage Manage and control the jobs used by the Backup system to create snapshots.

Test Ops Manager Monitoring Set up a replica set for testing Ops Manager Monitoring.

2.1 Installation Checklist

On this page

•Overview

•Topology Decisions

•Security Decisions

•Backup Decisions

Overview

You must make the following decisions before you install Ops Manager. During the install procedures you will make

choices based on your decisions here.

If you have not yet read the Ops Manager Components page, please do so for a description of the system’s components.

The sequence for installing Ops Manager is to:

• Plan your installation according to the questions on this page.

• Provision servers that meet the Hardware and Software Requirements

• Set up the Ops Manager Application Database and optional Backup Database.

• Install the Ops Manager Application and optional Backup Daemon.

Note: To install a simple evaluation deployment on a single server, see Install a Simple Test Ops Manager Installation.

Topology Decisions

Do you require durability and/or high availability?

Ops Manager stores application metadata and snapshots in the Ops Manager Application Database and Backup

Database respectively. To provide data durability, run each database as a three-member replica set on multiple servers.

To provide high availability for write operations to the databases, set up each replica set so that all three members hold

data. This way, if a member is unreachable the replica set can still write data. Ops Manager uses w:2 write concern,

which requires acknowledgement from the primary and one secondary for each write operation.

To provide high availability for the Ops Manager Application, run at least two instances of the application and use a

load balancer. For more information, see Conﬁgure a Highly Available Ops Manager Application.

The following tables describe the pros and cons for each combination of durability and high availability.

Non-Durable, Test Install

This is a non-durable install that runs on one server. If you lose the server, you must start over from scratch.

Pros: Needs only needs one server.

Cons: If you lose the server, you lose everything: users and groups, metadata, backups, automation

conﬁgurations, stored monitoring metrics, etc.

Durable Production Install

This install runs on at least three servers and provides durability for your metadata and snapshots. The replica sets for

the Ops Manager Application Database and the Backup Database are each made up of two data-bearing members and

an arbiter. This installation does not provide high availability.

Pros: Can run on as few as three servers. Ops Manager metadata and backups are durable from the

perspective of the Ops Manager Application.

Cons: No high availability, neither for the databases nor the application:

1. If the Ops Manager Application Database or the Backup Database loses a data-bearing

member, the data is durable but you must restart the member to gain back full Ops Manager

functionality. For the Backup Database, Ops Manager will not write new snapshots until

the member is again running.

2. Loss of the Ops Manager Application requires you to manually start a new Ops Manager

Application. No Ops Manager functionality is available while the application is down.

Durable Production Install with Highly Available Backup and Application Data

This install requires at least three servers. The replica sets for the Ops Manager Application Database and the Backup

Database each comprise at least three data-bearing members. This requires more storage and memory than for the

Durable Production Install.

Pros: You can lose a member of the Ops Manager Application Database or Backup Database and still

maintain Ops Manager availability. No Ops Manager functionality is lost while the member is

down.

Cons: Loss of the Ops Manager Application requires you to manually start a new Ops Manager Appli-

cation. No Ops Manager functionality is available while the application is down.

Durable Production Install with a Highly Available Ops Manager Application

This runs multiple Ops Manager Applications behind a load balancer and requires infrastructure outside of what Ops

Manager offers. For details, see Conﬁgure a Highly Available Ops Manager Application.

Pros: Ops Manager continues to be available even when any individual server is lost.

Cons: Requires a larger number of servers, and requires a load balancer capable of routing trafﬁc to

available application servers.

Will you deploy managed MongoDB instances on servers that have no internet access?

If you use Automation and if the servers where you will deploy MongoDB do not have internet access, then you must

conﬁgure Ops Manager to locally store and share the binaries used to deploy MongoDB so that the Automation agents

can download them directly from Ops Manager.

You must conﬁgure local mode and store the binaries before you create the ﬁrst managed MongoDB deployment from

Ops Manager. For more information, see Conﬁgure Local Mode if Ops Manager has No Internet Access.

Will you use a proxy for the Ops Manager application’s outbound network connections?

If Ops Manager will use a proxy server to access external services, you must conﬁgure the proxy settings in Ops

Manager’s conf-mms.properties conﬁguration ﬁle. If you have already started Ops Manager, you must restart

after conﬁguring the proxy settings.

Security Decisions

Will you use authentication and/or SSL for the connections to the backing databases?

If you will use authentication or SSL for connections to the Ops Manager Application Database and Backup Database,

you must conﬁgure those options on each database when deploying the database and then you must conﬁgure Ops

Manager with the necessary certiﬁcate information for accessing the databases. For details, see Conﬁgure the Connec-

tions to the Backing MongoDB Instances

Will you use LDAP for user authenticate to Ops Manager?

If you will use LDAP for user management, you must conﬁgure LDAP authentication before you register any Ops

Manager user or group. If you have already created an Ops Manager user or group, you must start from scratch with a

fresh Ops Manager install.

During the procedure to install Ops Manager, you are given the option to conﬁgure LDAP before creating users or

groups. For details on LDAP authentication, see Conﬁgure Users and Groups with LDAP for Ops Manager.

Will you use SSL (HTTPS) for connections to the Ops Manager application?

If you will use SSL for connections to Ops Manager from agents, users, and the API, then you must conﬁgure Ops

Manager to use SSL. The procedure to install Ops Manager includes the option to conﬁgure SSL access.

Backup Decisions

Will the servers that run your Backup Daemons have internet access?

If the servers that run your Backup Daemons have no internet access, you must conﬁgure ofﬂine binary access for the

Backup Daemon before running the Daemon. The install procedure includes the option to conﬁgure ofﬂine binary

access.

Are certain backups required to be in certain data centers?

If you need to assign backups of particular MongoDB deployments to particular data centers, then each data center re-

quires its own Ops Manager Application, Backup Daemon, and Backup Agent. The separate Ops Manager Application

instances must share a single dedicated Ops Manager Application Database. The Backup Agent in each data center

must use the URL for its local Ops Manager Application, which you can conﬁgure through either different hostnames

or split-horizon DNS. For detailed requirements, see Conﬁgure Multiple Blockstores in Multiple Data Centers.

2.2 Example Installation Diagrams

On this page

•Overview

•Non-Durable, Test Install on a Single Server

•Durable Production Install

•Durable, Highly Available Install with Multiple Backup Databases

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 conﬁgure the appropriate ulimits for the deployment.

The head databases are dynamically created and maintained by the Backup Daemon. They reside on the disk partition

speciﬁed in the conf-daemon.properties ﬁle.

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.

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 speciﬁed in the conf-daemon.properties ﬁle. 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 /tutorial/install-basic-deployment.

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.

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 trafﬁc for the Ops Manager HTTP Service and Backup service.

Ops Manager does not supply an HTTP Load Balancer: you must deploy and conﬁgure it yourself.

All of the software services need to be able to communicate with the Ops Manager Application databases, and the

Backup Blockstore databases. Conﬁgure your ﬁrewalls to allow trafﬁc 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 speciﬁed

in the conf-daemon.properties ﬁle. 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 speciﬁes 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: Conﬁgure a Highly Available Ops Manager Application.

2.3 Ops Manager Hardware and Software Requirements

On this page

•Hardware Requirements

•EC2 Security Groups

•Software Requirements

This page describes the hardware and software requirements for the servers that run the Ops Manager Components,

including the servers that run the backing MongoDB replica sets.

The servers that run the Backup Daemon and the backing replica sets must also meet the conﬁguration requirements

in the MongoDB Production Notes in addition to the requirements on this page. The Production Notes include infor-

mation on ulimits,NUMA,Transparent Huge Pages (THP), and other conﬁguration options.

Warning: Failure to conﬁgure servers according to the MongoDB Production Notes can lead to production

failure.

This page also includes requirements for the EC2 security group used when installing on AWS servers.

Hardware Requirements

Each server must meet the sum of the requirements for all its components.

Ops Manager Monitoring and Automation require servers for the following components:

•Ops Manager Application.

•Ops Manager Application Database replica set members

Note: Usually the Ops Manager Application and one of the Application database’s replica set members run on

the same server.

If you run Backup, Ops Manager also requires servers for the following:

•Backup Daemon

•Backup Blockstore database replica set members

Note: The following requirements are speciﬁc to a given component. You must add together the requirements for the

components you will install. For example, the requirements for the Ops Manager Application do not cover the Ops

Manager Application database.

Ops Manager Application Hardware

The Ops Manager Application requires the hardware listed here.

Number of Monitored Hosts CPU Cores RAM

Up to 400 monitored hosts 4+ 15 GB

Up to 2000 monitored hosts 8+ 15 GB

More than 2000 hosts Contact MongoDB Account Manager Contact MongoDB Account Manager

Ops Manager Application Database Hardware

The Ops Manager Application Database holds monitoring and other metadata for the Ops Manager Application.

The database runs as a three-member replica set. If you cannot allocate space for three data-bearing members, the third

member can be an arbiter, but keep in mind that Ops Manager uses w:2 write concern, which reports a write operation

as successful after acknowledgement from the primary and one secondary. If you use a replica set with fewer than 3

data-bearing members, and if you lose one of the data-bearing members, MongoDB blocks write operations, meaning

the Ops Manager Application Database has durability but not high availability.

Run the replica set on dedicated servers. You can optionally run one member of the replica set on the same physical

server as the Ops Manager Application.

For a test deployment, you can use a MongoDB standalone in place of a replica set.

Each server that hosts a MongoDB process for the Ops Manager Application database must comply with the Pro-

duction Notes in the MongoDB manual. The Production Notes include important information on ulimits,NUMA,

Transparent Huge Pages (THP), and other conﬁguration options.

Warning: Failure to conﬁgure servers according to the MongoDB Production Notes can lead to production

failure.

Each server also requires the following:

Number of Moni-

tored Hosts

RAM Disk Space

Up to 400 monitored

hosts

8 GB additional RAM beyond the RAM required for the

Ops Manager Application

200 GB of storage space

Up to 2000 monitored

hosts

15 GB additional RAM beyond the RAM required for the

Ops Manager Application

500 GB of storage space

More than 2000 hosts Contact MongoDB account manager Contact MongoDB ac-

count manager

For the best results use SSD-backed storage.

Ops Manager Backup Daemon Hardware

The Backup Daemon server must meet the requirements in the table below and also must meet the conﬁguration

requirements in the MongoDB Production Notes. The Production Notes include information on ulimits,NUMA,

Transparent Huge Pages (THP), and other options.

Warning: Failure to conﬁgure servers according to the MongoDB Production Notes can lead to production

failure.

If you wish to install the Backup Daemon on the same physical server as the Ops Manager Application, the server

must satisfy these requirements separately from the requirements in Ops Manager Application Hardware.

The server running the Backup Daemon acts like a hidden secondary for every replica set assigned to it, receiving the

streamed oplog entries each replica set’s primary. However, the Backup Daemon differs from a hidden secondary in

that the replica set is not aware of it.

The server must have the disk space and write capacity to maintain the replica sets plus the space to store an additional

copy of the data to support point-in-time restore. Typically, the Backup Daemon must be able to store 2 to 2.5 times the

sum of the size on disk of all the backed-up replica sets, as it also needs space locally to build point-in-time restores.

Before installing the Backup Daemon, we recommend contacting your MongoDB Account Manager for assistance in

estimating the storage requirements for your Backup Daemon server.

Number of Hosts CPU Cores RAM Disk Space Storage IOPS/s

Up to 200 hosts 4+ 2Ghz+ 15 GB

additional

RAM

Contact MongoDB

Account Manager

Contact MongoDB

Account Manager

Ops Manager Backup Blockstore Database Hardware

Blockstore servers store snapshots of MongoDB deployments. Only provision Blockstore servers if you are deploying

Ops Manager Backup.

Replica Set for the Blockstore Database

Backup requires a separate, dedicated MongoDB replica set to hold snapshot data. This cannot be a replica set used

for any purpose other than holding the snapshots.

For durability, the replica set must have at least two data-bearing members. For high availability the replica set must

have at least three data-bearing members.

Note: Ops Manager uses w:2 write concern, which reports a write operation as successful after acknowledgement

from the primary and one secondary. If you use a replica set with two data-bearing members and an arbiter, and you

lose one of the data-bearing members, write operations will be blocked.

For testing only you may use a standalone MongoDB deployment in place of a replica set.

Server Size for the Blockstore Database

Snapshots are compressed and de-duplicated at the block level in the Blockstore database. Typically, depending on

data compressibility and change rate, the replica set must run on servers with enough capacity to store 2 to 3 times the

total backed-up production data size.

Contact your MongoDB Account Manager for assistance in estimating the use-case and workload-dependent storage

requirements for your Blockstore servers.

Conﬁguration Requirements from the MongoDB Production Notes

Each server that hosts a MongoDB process for the Blockstore database must comply with the Production Notes in the

MongoDB manual. The Production Notes include important information on ulimits,NUMA,Transparent Huge Pages

(THP), and other conﬁguration options.

Warning: Failure to conﬁgure servers according to the MongoDB Production Notes can lead to production

failure.

Other Requirements for the Blockstore Databsase

For each data-bearing member of the replica set member

CPU

Cores

RAM Disk Space Storage IOPS

4 x

2ghz+

8 GB of RAM for every 1 TB disk of Blockstore to

provide good snapshot and restore speed. Ops Man-

ager deﬁnes 1 TB of Blockstore as 10244bytes.

Contact your

MongoDB

Account

Manager.

Medium grade HDDs should

have enough I/O throughput to

handle the load of the Block-

store.

EC2 Security Groups

If you install on AWS servers, you must have at least one EC2 security group conﬁgured with the following inbound

rules:

• An SSH rule on the ssh port, usually port 22, that allows trafﬁc from all IPs. This is to provide administrative

access.

• A custom TCP rule that allows connection on ports 8080 and 8081 on the server that runs the Ops Manager

Application. This lets users connect to Ops Manager.

• A custom TCP rule that allows trafﬁc on all MongoDB ports from any member of the security group. This

allows communication between the various Ops Manager components. MongoDB usually uses ports between

27000 and 28000.

Software Requirements

Operating System

The Ops Manager Application and Backup Daemon(s) can run on 64-bit versions of the following operating systems:

• CentOS 5 or later

• Red Hat Enterprise Linux 5 or later

• SUSE 11 or Later

• Amazon Linux AMI (latest version only)

• Ubuntu 12.04 or later

• Windows Server 2008 R2 or later

Warning: Ops Manager supports Monitoring and Backup on Windows but does not support Automation

on Windows.

Ulimits

The Ops Manager packages automatically raise the open ﬁle, max user processes, and virtual memory ulimits. On Red

Hat, be sure to check for a /etc/security/limits.d/90-nproc.conf ﬁle that may override the max user

processes limit. If the /etc/security/limits.d/90-nproc.conf ﬁle exists, remove it before continuing.

See MongoDB ulimit Settings for recommended ulimit settings.

Warning: Always refer to the MongoDB Production Notes to ensure healthy server conﬁgurations.

Authentication

If you are using LDAP for user authentication to Ops Manager (as described in Conﬁgure Users and Groups with

LDAP for Ops Manager), you must enable LDAP before setting up Ops Manager, beyond starting the service.

Important: You cannot enable LDAP once you have opened the Ops Manager user interface and registered the ﬁrst

user. You can enable LDAP only on a completely blank, no-hosts, no-users installation.

MongoDB

The Ops Manager Application Database and Backup Blockstore Database must run on MongoDB 2.4.9 or later.

Note: Ops Manager 1.8.0, when released, will not support MongoDB 2.4 for the Ops Manager Application database

and Backup Blockstore database.

Your backed-up sharded cluster deployments must run at least MongoDB 2.4.3 or later. Your backed-up replica set

deployments must run at least MongoDB 2.2 or later.

Web Browsers

Ops Manager supports clients using the following browsers:

• Chrome 8 and greater

• Firefox 12 and greater

• IE 9 and greater

• Safari 6 and greater

The Ops Manager Application will display a warning on non-supported browsers.

SMTP

Ops Manager requires email for fundamental server functionality such as password reset and alerts.

Many Linux server-oriented distributions include a local SMTP server by default, for example, Postﬁx, Exim, or

Sendmail. You also may conﬁgure Ops Manager to send mail via third party providers, including Gmail and Sendgrid.

SNMP

If your environment includes SNMP, you can conﬁgure an SMNP trap receiver with periodic heartbeat traps to monitor

the internal health of Ops Manager. Ops Manager uses SNMP v2c.

For more information, see Conﬁgure SNMP Heartbeat Support.

2.4 Deploy Backing MongoDB Replica Sets

On this page

•Overview

•Replica Sets Requirements

•Server Prerequisites

•Procedures

Overview

Ops Manager uses two dedicated replica sets to store operational data: one replica set to store the Ops Manager Appli-

cation Database and another to store the Backup Blockstore Database. If you use multiple application or blockstore

databases, set up separate replica sets for each database.

The backing MongoDB replica sets are dedicated to operational data and must store no other data.

Replica Sets Requirements

Each replica set that hosts the Ops Manager Application Database or a Backup Database:

• Stores data in support of Ops Manager operations only and stores no other data.

• Must run on a server that meets the server prerequisites below.

• Must run MongoDB 2.4.9 or later.

• Must use the MMAPv1 storage engine.

• Must have the MongoDB security.javascriptEnabled set to true, which is the default. The Ops

Manager Application uses the $where query and requires this setting be enabled on the Ops Manager Appli-

cation database.

• Must not run the MongoDB notablescan option.

Server Prerequisites

The servers that run the replica sets must meet the following requirements.

• The hardware requirements described in Ops Manager Application Database Hardware or Ops Manager Backup

Blockstore Database Hardware, depending on which database the server will host. If a server hosts other Ops

Manager components in addition to the database, you must sum the hardware requirements for each component

to determine the requirements for the server.

• The system requirements in the MongoDB Production Notes. The Production Notes include important informa-

tion on ulimits,NUMA,Transparent Huge Pages (THP), and other conﬁguration options.

• The MongoDB ports requirements described in Firewall Conﬁguration. Each server’s ﬁrewall rules must allow

access to the required ports.

•RHEL servers only: if the /etc/security/limits.d directory contains the 90-nproc.conf ﬁle,

remove the ﬁle. The ﬁle overrides limits.conf, decreasing ulimit settings. Issue the following command

to remove the ﬁle:

sudo rm /etc/security/limits.d/90-nproc.conf

Procedures

Install MongoDB on Each Server

Warning: Failure to conﬁgure servers according to the MongoDB Production Notes can lead to production

failure.

Use servers that meet the above prerequisites.

The following procedure assumes that you are installing MongoDB on a server running Red Hat Enterprise Linux

(RHEL). If you are installing MongoDB on another Linux operating system, or you prefer to use cURL rather than

yum, refer to the installation guides in the MongoDB manual.

Step 1: Create a repository ﬁle on each server by issuing the following command:

echo "[mongodb-org-3.0]

name=MongoDB Repository

baseurl=http://repo.mongodb.org/yum/redhat/\$releasever/mongodb-org/3.0/x86_64/

gpgcheck=0

enabled=1" | sudo tee -a /etc/yum.repos.d/mongodb-org-3.0.repo

Step 2: Install MongoDB on each server by issuing the following command:

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

Deploy a Backing Replica Set

This procedure deploys a three-member replica set dedicated to store either the Ops Manager Application database or

Backup Blockstore database. Deploy the replica set to three servers that meet the requirements for the database.

Repeat this procedure for each backing replica set that your installation requires.

Step 1: Create a data directory on each server.

Create a data directory on each server and set mongod as the directory’s owner. For example:

sudo mkdir -p /data

sudo chown mongod:mongod /data

Step 2: Start each MongoDB process.

For each replica set member, start the mongod process and specify mongod as the user. Start each process on its own

dedicated port and point to the data directory you created in the previous step. Specify the same replica set for all three

members.

The following command starts a MongoDB process as part of a replica set named operations and speciﬁes the

/data directory.

sudo -u mongod mongod --port 27017 --dbpath /data --replSet operations --logpath /

˓→data/mongodb.log --fork

Step 3: Connect to the MongoDB process on the server that will initially host the database’s primary.

For example, the following command connects on port 27017 to a MongoDB process running on mongodb1.

example.net:

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

When you connect, the MongoDB shell displays its version as well as the database to which you are connected.

Step 4: Initiate the replica set.

To initiate the replica set, issue the following command:

rs.initiate()

MongoDB returns 1upon successful completion, and creates a replica set with the current mongod as the initial

member.

The server on which you initiate the replica set becomes the initial primary. The mongo shell displays the replica set

member’s state in the prompt.

MongoDB supports automatic failover, so this mongod may not always be the primary.

Step 5: Add the remaining members to the replica set.

In a mongo shell connected to the primary, use the rs.add() method to add the other two replica set members. For ex-

ample, the following adds the mongod instances running on mongodb2.example.net:27017 and mongodb3.

example.net:27017 to the replica set:

rs.add(’mongodb2.example.net:27017’)

rs.add(’mongodb3.example.net:27017’)

Step 6: Verify the replica set conﬁguration.

To verify that the conﬁguration includes the three members, issue rs.conf():

rs.conf()

The method returns output similiar to the following.

{

"_id" :"operations",

"version" :3,

"members" :[

{

"_id" :0,

"host" :"mongodb1.example.net:27017"

{

"_id" :1,

"host" :"mongodb2.example.net:27017"

{

"_id" :2,

"host" :"mongodb3.example.net:27017",

}

]

}

Optionally, run rs.status() </reference/method/rs.status to verify the status of the replica set and see the state of each

replica set member.

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

2.5 Install Ops Manager

Install with DEB Packages Install Ops Manager on Debian and Ubuntu systems.

Install with RPM Packages Install Ops Manager on Red Hat, Fedora, CentOS, and Amazon AMI Linux.

Install from Archives on Linux Install Ops Manager on other Linux systems, without using package management.

Install on Windows Install Ops Manager on Windows.

Install Ops Manager with deb Packages

On this page

•Overview

•Prerequisites

•Install Procedures

Overview

To install Ops Manager you install the Ops Manager Application and the optional Backup Daemon. This tutorial

describes how to install both using deb packages. The Ops Manager Application monitors MongoDB deployments,

and the Backup Daemon creates and stores deployment snapshots.

If you are instead upgrading an existing deployment, please see Upgrade Ops Manager.

Warning: To use Ops Manager 1.6 Automation to manage MongoDB Enterprise deployments, you must ﬁrst

install the MongoDB Enterprise dependencies to each server that runs MongoDB Enterprise. You must install the

dependencies to the servers before using Automation.

Note that Automation does not yet support use of the MongoDB Enterprise advanced security features (SSL,

LDAP, Kerberos, and auditing). Automation will support these features in the next major Ops Manager release.

To run MongoDB Enterprise with advanced security now, deploy MongoDB Enterprise manually (not through

Automation) and use Ops Manager only for Monitoring and Backup.

Prerequisites

Deploy Servers

Prior to installation, you must set up servers for the entire Ops Manager deployment, including the Ops Manager

Application, the optional Backup Daemon, and the backing replica sets. For deployment diagrams, see Example

Installation Diagrams.

Deploy servers that meet the hardware requirements described in Ops Manager Hardware and Software Requirements.

Servers for the Backup Daemon and the backing replica sets must also comply with the Production Notes in the

MongoDB manual. Conﬁgure as many servers as needed for your deployment.

Warning: Failure to conﬁgure servers according to the MongoDB Production Notes can lead to production

failure.

Deploy MongoDB

Install MongoDB on the servers that will store the Ops Manager Application Database and Backup Blockstore

Database. The Backup Blockstore database is required only if you run the Backup Daemon. The databases require

dedicated MongoDB instances. Do not use MongoDB installations that store other data.

Install separate MongoDB instances for the two databases and install the instances as replica sets. Ensure that ﬁrewall

rules on the servers allow access to the ports that the instances runs on.

The Ops Manager Application and Backup Daemon must authenticate to their databases as a MongoDB user with

appropriate access. The user must have the following roles:

•readWriteAnyDatabase

•dbAdminAnyDatabase.

•clusterAdmin if the database is a sharded cluster, otherwise clusterMonitor

Install Procedures

You must have administrative access on the machines to which you install.

Install and Start the Ops Manager Application

Step 1: Download the latest version of the Ops Manager Application package.

1. In a browser, go to http://www.mongodb.com/download.

2. Submit the subscription form.

3. On the MongoDB Enterprise Downloads page, go to the MongoDB Ops Manager section and click the here

link.

4. On the Ops Manager Download page, acknowledge the recommendation to contact MongoDB for production

installs.

5. On the MongoDB Ops Manager Downloads page, copy the link address of the “Monitoring, Automation and

Core” DEB link.

6. Open a system prompt.

7. Download the Ops Manager Application package by issuing a curl command that uses the copied link address:

curl -OL <link-address-for-monitoring-automation-core-deb>

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

version number.

Step 2: Install the Ops Manager Application package.

Install the .deb package by issuing the following command, where <version> is the version of the .deb package:

sudo dpkg --install mongodb-mms_<version>_x86_64.deb

When installed, the base directory for the Ops Manager software is /opt/mongodb/mms/. The .deb package

creates a new system user mongodb-mms under which the server will run.

Step 3: Conﬁgure Monitoring.

Open <install-directory>/conf/conf-mms.properties with root privileges and set values for the set-

tings described in this step. For detailed information on each setting, see the Ops Manager Conﬁguration Files page.

Set mms.centralUrl and mms.backupCentralUrl as follows, where <host> is the fully qualiﬁed domain

name of the server running the Ops Manager Application.

mms.centralUrl=http://<host>:8080

mms.backupCentralUrl=http://<host>:8081

Set the following Email Address Settings as appropriate. Each may be the same or different.

mms.fromEmailAddr=<email_address>

mms.replyToEmailAddr=<email_address>

mms.adminFromEmailAddr=<email_address>

mms.adminEmailAddr=<email_address>

mms.bounceEmailAddr=<email_address>

Set mongo.mongoUri to the servers and ports hosting the Ops Manager Application database. For example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

If you use HTTPS to encrypt user connections to Ops Manager, set mms.https.PEMKeyFile to a PEM ﬁle

containing an X509 certiﬁcate and private key, and set mms.https.PEMKeyFilePassword to the password for

the certiﬁcate. For example:

mms.https.PEMKeyFile=<path_and_name_of_pem_file>

mms.https.PEMKeyFilePassword=<password_for_pem_file>

To conﬁgure authentication, email, and other optional settings, see Ops Manager Conﬁguration Files. To run the Ops

Manager application in a highly available conﬁguration, see Conﬁgure a Highly Available Ops Manager Application.

Step 4: Start the Ops Manager Application.

Issue the following command:

sudo service mongodb-mms start

Step 5: Open the Ops Manager home page and register the ﬁrst user.

To open the home page, enter the following URL in a browser, where <host> is the fully qualiﬁed domain name of

the server:

http://<host>:8080

Click the Register link and follow the prompts to register the ﬁrst user and create the ﬁrst group. The ﬁrst user is

automatically assigned the Global Owner role. When you ﬁnish, you are logged into the Ops Manager Application as

the new user. For more information on creating and managing users, see Manage Ops Manager Users.

Step 6: At the Welcome page, follow the prompts to set up Automation (which includes Monitoring)

or just Monitoring alone.

Automation lets you deploy and conﬁgure MongoDB processes from Ops Manager as well as monitor and manage

them. If you select Automation, Ops Manager prompts you to download the Automation Agent and Monitoring Agent.

Monitoring lets you manage a MongoDB deployment from Ops Manager. If you select Monitoring, Ops Manager

prompts you to download only the Monitoring Agent.

Install the Backup Daemon (Optional)

If you use Backup, install the Backup Daemon.

Step 1: Download the Backup Daemon package.

1. In a browser, go to http://www.mongodb.com/download.

2. Submit the subscription form.

3. On the MongoDB Enterprise Downloads page, go to the MongoDB Ops Manager section and click the here

link.

4. On the Ops Manager Download page, acknowledge the recommendation to contact MongoDB for production

installs.

5. On the MongoDB Ops Manager Downloads page, copy the link address of the “Backup” DEB link.

6. Open a system prompt.

7. Download the Backup Daemon package by issuing a curl command that uses the copied link address:

curl -OL <link-address-for-backup-deb-package>

The downloaded package is named mongodb-mms-backup-daemon-<version>.x86_64.deb, where

<version> is replaced by the version number.

Step 2: Install the Backup Daemon package.

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

sudo dpkg --install <downloaded-package>

When installed, the base directory for the Ops Manager software is /opt/mongodb/mms/. The .deb package

creates a new system user mongodb-mms under which the server will run.

Step 3: Point the Backup Daemon to the Ops Manager Application database.

Open the /opt/mongodb/mms-backup-daemon/conf/conf-daemon.properties ﬁle with root privi-

leges and set the mongo.mongoUri value to the servers and ports hosting the Ops Manager Application database.

For example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

Step 4: Synchronize the gen.key ﬁle

Synchronize the /etc/mongodb-mms/gen.key ﬁle from an Ops Manager Application server. This is only re-

quired if the Backup Daemon was installed on a different server than the Ops Manager Application.

Step 5: Start the back-end software package.

To start the Backup Daemon run:

sudo service mongodb-mms-backup-daemon start

If everything worked the following displays:

Start Backup Daemon [OK ]

If you run into any problems, the log ﬁles are at /opt/mongodb/mms-backup-daemon/logs.

Step 6: Open Ops Manager and access the Backup conﬁguration page.

Open the Ops Manager home page and log in as the user you ﬁrst registered when installing the Ops Manager Appli-

cation. (This user is the global owner.) Then click the Admin link at the top right of the page. Then click the Backup

tab.

Step 7: Enter conﬁguration information for the Backup database.

Enter the conﬁguration information described below, and then click Save. Ops Manager uses this information to create

the connection string URI used to connect to the database.

<hostname>:<port>: Enter a comma-separated list of the fully qualiﬁed domain names and port numbers for all

replica set members for the Backup database.

MongoDD Auth Username and MongoDB Auth Password: Enter the user credentials if the database uses authentica-

tion.

Encrypted Credentials: Check this if the user credentials use the Ops Manager credentialstool. For more

information, see Encrypt MongoDB User Credentials.

Use SSL: Check this if the MongoDB database uses SSL. If you select this, you must conﬁgure SSL settings for both

the Ops Manager Application and Backup Daemon. See Ops Manager Conﬁguration Files.

Connection Options: To add additional connection options, enter them using the MongoDB Connection String URI

Format.

Install Ops Manager with rpm Packages

On this page

•Overview

•Prerequisites

•Install Procedures

Overview

To install Ops Manager you install the Ops Manager Application and the optional Backup Daemon. This tutorial

describes how to install both using rpm packages. The Ops Manager Application monitors MongoDB deployments,

and the Backup Daemon creates and stores deployment snapshots.

If you are instead upgrading an existing deployment, please see Upgrade Ops Manager.

Warning: To use Ops Manager 1.6 Automation to manage MongoDB Enterprise deployments, you must ﬁrst

install the MongoDB Enterprise dependencies to each server that runs MongoDB Enterprise. You must install the

dependencies to the servers before using Automation.

Note that Automation does not yet support use of the MongoDB Enterprise advanced security features (SSL,

LDAP, Kerberos, and auditing). Automation will support these features in the next major Ops Manager release.

To run MongoDB Enterprise with advanced security now, deploy MongoDB Enterprise manually (not through

Automation) and use Ops Manager only for Monitoring and Backup.

Prerequisites

Deploy Servers

Prior to installation, you must set up servers for the entire Ops Manager deployment, including the Ops Manager

Application, the optional Backup Daemon, and the backing replica sets. For deployment diagrams, see Example

Installation Diagrams.

Deploy servers that meet the hardware requirements described in Ops Manager Hardware and Software Requirements.

Servers for the Backup Daemon and the backing replica sets must also comply with the Production Notes in the

MongoDB manual. Conﬁgure as many servers as needed for your deployment.

Warning: Failure to conﬁgure servers according to the MongoDB Production Notes can lead to production

failure.

Deploy MongoDB

Install MongoDB on the servers that will store the Ops Manager Application Database and Backup Blockstore

Database. The Backup Blockstore database is required only if you run the Backup Daemon. The databases require

dedicated MongoDB instances. Do not use MongoDB installations that store other data.

Install separate MongoDB instances for the two databases and install the instances as replica sets. Ensure that ﬁrewall

rules on the servers allow access to the ports that the instances runs on.

The Ops Manager Application and Backup Daemon must authenticate to their databases as a MongoDB user with

appropriate access. The user must have the following roles:

•readWriteAnyDatabase

•dbAdminAnyDatabase.

•clusterAdmin if the database is a sharded cluster, otherwise clusterMonitor

Install Procedures

You must have administrative access on the machines to which you install.

Install and Start the Ops Manager Application

Step 1: Download the latest version of the Ops Manager Application package.

1. In a browser, go to http://www.mongodb.com/download.

2. Submit the subscription form.

3. On the MongoDB Enterprise Downloads page, go to the MongoDB Ops Manager section and click the here

link.

4. On the Ops Manager Download page, acknowledge the recommendation for production installs.

5. On the MongoDB Ops Manager Downloads page, copy the link address of the “Monitoring, Automation and

Core” RPM link.

6. Open a system prompt.

7. Download the Ops Manager Application package by issuing a curl command that uses the copied link address:

curl -OL <link-address-for-monitoring-automation-core-rpm>

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

version number.

Step 2: Install the Ops Manager Application package.

Install the .rpm package by issuing the following command, where <version> is the version of the .rpm package:

sudo rpm -ivh mongodb-mms-<version>.x86_64.rpm

When installed, the base directory for the Ops Manager software is /opt/mongodb/mms/. The RPM package

creates a new system user mongodb-mms under which the server runs.

Step 3: Conﬁgure Monitoring.

Open <install-directory>/conf/conf-mms.properties with root privileges and set values for the set-

tings described in this step. For detailed information on each setting, see the Ops Manager Conﬁguration Files page.

Set mms.centralUrl and mms.backupCentralUrl as follows, where <host> is the fully qualiﬁed domain

name of the server running the Ops Manager Application.

mms.centralUrl=http://<host>:8080

mms.backupCentralUrl=http://<host>:8081

Set the following Email Address Settings as appropriate. Each may be the same or different.

mms.fromEmailAddr=<email_address>

mms.replyToEmailAddr=<email_address>

mms.adminFromEmailAddr=<email_address>

mms.adminEmailAddr=<email_address>

mms.bounceEmailAddr=<email_address>

Set mongo.mongoUri to the servers and ports hosting the Ops Manager Application database. For example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

If you use HTTPS to encrypt user connections to Ops Manager, set mms.https.PEMKeyFile to a PEM ﬁle

containing an X509 certiﬁcate and private key, and set mms.https.PEMKeyFilePassword to the password for

the certiﬁcate. For example:

mms.https.PEMKeyFile=<path_and_name_of_pem_file>

mms.https.PEMKeyFilePassword=<password_for_pem_file>

To conﬁgure authentication, email, and other optional settings, see Ops Manager Conﬁguration Files. To run the Ops

Manager application in a highly available conﬁguration, see Conﬁgure a Highly Available Ops Manager Application.

Step 4: Start the Ops Manager Application.

Issue the following command:

sudo service mongodb-mms start

Step 5: Open the Ops Manager home page and register the ﬁrst user.

To open the home page, enter the following URL in a browser, where <host> is the fully qualiﬁed domain name of

the server:

http://<host>:8080

Click the Register link and follow the prompts to register the ﬁrst user and create the ﬁrst group. The ﬁrst user is

automatically assigned the Global Owner role. When you ﬁnish, you are logged into the Ops Manager Application as

the new user. For more information on creating and managing users, see Manage Ops Manager Users.

Step 6: At the Welcome page, follow the prompts to set up Automation (which includes Monitoring)

or just Monitoring alone.

Automation lets you deploy and conﬁgure MongoDB processes from Ops Manager as well as monitor and manage

them. If you select Automation, Ops Manager prompts you to download the Automation Agent and Monitoring Agent.

Monitoring lets you manage a MongoDB deployment from Ops Manager. If you select Monitoring, Ops Manager

prompts you to download only the Monitoring Agent.

Install the Backup Daemon (Optional)

If you use Backup, install the Backup Daemon.

Step 1: Download the Backup Daemon package.

To download the Backup Daemon package:

1. In a browser, go to http://www.mongodb.com/download.

2. Submit the subscription form.

3. On the MongoDB Enterprise Downloads page, go to the MongoDB Ops Manager section and click the here

link.

4. On the Ops Manager Download page, acknowledge the recommendation to contact MongoDB for production

installs.

5. On the MongoDB Ops Manager Downloads page, copy the link address of the “Backup” RPM link.

6. Open a system prompt.

7. Download the Backup Daemon package by issuing a curl command that uses the copied link address:

curl -OL <link-address-for-backup-rpm>

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

<version> is replaced by the version number.

Step 2: Install the Backup Daemon package.

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

sudo rpm --install <downloaded-package>

The software is installed to /opt/mongodb/mms-backup-daemon.

Step 3: Point the Backup Daemon to the Ops Manager Application database.

Open the /opt/mongodb/mms-backup-daemon/conf/conf-daemon.properties ﬁle with root privi-

leges and set the mongo.mongoUri value to the servers and ports hosting the Ops Manager Application database.

For example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

Step 4: Synchronize the gen.key ﬁle

Synchronize the /etc/mongodb-mms/gen.key ﬁle from an Ops Manager Application server. This is only re-

quired if the Backup Daemon was installed on a different server than the Ops Manager Application.

Step 5: Start the back-end software package.

To start the Backup Daemon run:

sudo service mongodb-mms-backup-daemon start

If everything worked the following displays:

Start Backup Daemon [OK ]

If you run into any problems, the log ﬁles are at /opt/mongodb/mms-backup-daemon/logs.

Step 6: Open Ops Manager and access the Backup conﬁguration page.

Open the Ops Manager home page and log in as the user you ﬁrst registered when installing the Ops Manager Appli-

cation. (This user is the global owner.) Then click the Admin link at the top right of the page. Then click the Backup

tab.

Step 7: Enter conﬁguration information for the Backup database.

Enter the conﬁguration information described below, and then click Save. Ops Manager uses this information to create

the connection string URI used to connect to the database.

<hostname>:<port>: Enter a comma-separated list of the fully qualiﬁed domain names and port numbers for all

replica set members for the Backup database.

MongoDD Auth Username and MongoDB Auth Password: Enter the user credentials if the database uses authentica-

tion.

Encrypted Credentials: Check this if the user credentials use the Ops Manager credentialstool. For more

information, see Encrypt MongoDB User Credentials.

Use SSL: Check this if the MongoDB database uses SSL. If you select this, you must conﬁgure SSL settings for both

the Ops Manager Application and Backup Daemon. See Ops Manager Conﬁguration Files.

Connection Options: To add additional connection options, enter them using the MongoDB Connection String URI

Format.

Install Ops Manager from tar.gz or zip Archives

On this page

•Overview

•Prerequisites

•Install Procedures

Overview

To install Ops Manager you install the Ops Manager Application and the optional Backup Daemon. This tutorial

describes how to install both using tar.gz or zip packages. The tutorial installs to a Linux OS. The Ops Manager

Application monitors MongoDB deployments, and the Backup Daemon creates and stores deployment snapshots.

If you are instead upgrading an existing deployment, please see Upgrade Ops Manager.

Warning: To use Ops Manager 1.6 Automation to manage MongoDB Enterprise deployments, you must ﬁrst

install the MongoDB Enterprise dependencies to each server that runs MongoDB Enterprise. You must install the

dependencies to the servers before using Automation.

Note that Automation does not yet support use of the MongoDB Enterprise advanced security features (SSL,

LDAP, Kerberos, and auditing). Automation will support these features in the next major Ops Manager release.

To run MongoDB Enterprise with advanced security now, deploy MongoDB Enterprise manually (not through

Automation) and use Ops Manager only for Monitoring and Backup.

Prerequisites

Deploy Servers

Prior to installation, you must set up servers for the entire Ops Manager deployment, including the Ops Manager

Application, the optional Backup Daemon, and the backing replica sets. For deployment diagrams, see Example

Installation Diagrams.

Deploy servers that meet the hardware requirements described in Ops Manager Hardware and Software Requirements.

Servers for the Backup Daemon and the backing replica sets must also comply with the Production Notes in the

MongoDB manual. Conﬁgure as many servers as needed for your deployment.

Warning: Failure to conﬁgure servers according to the MongoDB Production Notes can lead to production

failure.

Deploy MongoDB

Install MongoDB on the servers that will store the Ops Manager Application Database and Backup Blockstore

Database. The Backup Blockstore database is required only if you run the Backup Daemon. The databases require

dedicated MongoDB instances. Do not use MongoDB installations that store other data.

Install separate MongoDB instances for the two databases and install the instances as replica sets. Ensure that ﬁrewall

rules on the servers allow access to the ports that the instances runs on.

The Ops Manager Application and Backup Daemon must authenticate to their databases as a MongoDB user with

appropriate access. The user must have the following roles:

•readWriteAnyDatabase

•dbAdminAnyDatabase.

•clusterAdmin if the database is a sharded cluster, otherwise clusterMonitor

Install Procedures

You must have administrative access on the machines to which you install.

Install and Start the Ops Manager Application

Step 1: Download the Ops Manager Application package.

1. In a browser, go to http://www.mongodb.com/download.

2. Submit the subscription form.

3. On the MongoDB Enterprise Downloads page, go to the MongoDB Ops Manager section and click the here

link.

4. On the Ops Manager Download page, acknowledge the recommendation to contact MongoDB for production

installs.

5. On the MongoDB Ops Manager Downloads page, copy the link address of the “Monitoring, Automation and

Core” TAR.GZ link.

6. Open a system prompt.

7. Download the Ops Manager Application package by issuing a curl command that uses the copied link address:

curl -OL <link-address-for-monitoring-automation-core-tar.gz>

The downloaded package is named mongodb-mms-<version>.x86_64.tar.gz, where <version>

is the version number.

Step 2: Extract the Ops Manager Application package.

Navigate to the directory to which to install the Ops Manager Application. Extract the archive to that directory:

tar -zxf mongodb-mms-<version>.x86_64.tar.gz

When complete, Ops Manager is installed.

Step 3: Conﬁgure Monitoring.

Open <install-directory>/conf/conf-mms.properties with root privileges and set values for the set-

tings described in this step. For detailed information on each setting, see the Ops Manager Conﬁguration Files page.

Set mms.centralUrl and mms.backupCentralUrl as follows, where <host> is the fully qualiﬁed domain

name of the server running the Ops Manager Application.

mms.centralUrl=http://<host>:8080

mms.backupCentralUrl=http://<host>:8081

Set the following Email Address Settings as appropriate. Each may be the same or different.

mms.fromEmailAddr=<email_address>

mms.replyToEmailAddr=<email_address>

mms.adminFromEmailAddr=<email_address>

mms.adminEmailAddr=<email_address>

mms.bounceEmailAddr=<email_address>

Set mongo.mongoUri to the servers and ports hosting the Ops Manager Application database. For example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

If you use HTTPS to encrypt user connections to Ops Manager, set mms.https.PEMKeyFile to a PEM ﬁle

containing an X509 certiﬁcate and private key, and set mms.https.PEMKeyFilePassword to the password for

the certiﬁcate. For example:

mms.https.PEMKeyFile=<path_and_name_of_pem_file>

mms.https.PEMKeyFilePassword=<password_for_pem_file>

To conﬁgure authentication, email, and other optional settings, see Ops Manager Conﬁguration Files. To run the Ops

Manager application in a highly available conﬁguration, see Conﬁgure a Highly Available Ops Manager Application.

Step 4: Start the Ops Manager Application.

To start Ops Manager, issue the following command:

<install_dir>/bin/mongodb-mms start

Step 5: Open the Ops Manager home page and register the ﬁrst user.

To open the home page, enter the following URL in a browser, where <host> is the fully qualiﬁed domain name of

the server:

http://<host>:8080

Click the Register link and follow the prompts to register the ﬁrst user and create the ﬁrst group. The ﬁrst user is

automatically assigned the Global Owner role. When you ﬁnish, you are logged into the Ops Manager Application as

the new user. For more information on creating and managing users, see Manage Ops Manager Users.

Step 6: At the Welcome page, follow the prompts to set up Automation (which includes Monitoring)

or just Monitoring alone.

Automation lets you deploy and conﬁgure MongoDB processes from Ops Manager as well as monitor and manage

them. If you select Automation, Ops Manager prompts you to download the Automation Agent and Monitoring Agent.

Monitoring lets you manage a MongoDB deployment from Ops Manager. If you select Monitoring, Ops Manager

prompts you to download only the Monitoring Agent.

Install the Backup Daemon (Optional)

If you use Backup, install the Backup Daemon.

Step 1: Download the Backup Daemon package.

1. In a browser, go to http://www.mongodb.com/download.

2. Submit the subscription form.

3. On the MongoDB Enterprise Downloads page, go to the MongoDB Ops Manager section and click the here

link.

4. On the Ops Manager Download page, acknowledge the recommendation to contact MongoDB for production

installs.

5. On the MongoDB Ops Manager Downloads page, copy the link address of the “Backup” TAR.GZ link.

6. Open a system prompt.

7. Download the Backup Daemon package by issuing a curl command that uses the copied link address:

curl -OL <link-address-for-backup-tar.gz>

The downloaded package is named mongodb-mms-backup-daemon-<version>.x86_64.tar.gz,

where <version> is replaced by the version number.

Step 2: To install the Backup Daemon, extract the downloaded archive ﬁle.

tar -zxf <downloaded-archive-file>

Step 3: Point the Backup Daemon to the Ops Manager Application database.

Open the <install-dir>/conf/conf-daemon.properties ﬁle and set the mongo.mongoUri value to

the servers and ports hosting the Ops Manager Application database. For example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

Additionally, ensure that the ﬁle system that holds the rootDirectory has sufﬁcient space to accommodate the

current snapshots of all backed up instances.

Step 4: Synchronize the mms-gen-key ﬁle.

Synchronize the <install-dir>/bin/mms-gen-key ﬁle from the Ops Manager Application server. This is

required only if the Backup Daemon is installed on a different server than the Ops Manager Application.

Step 5: Start the Backup Daemon.

To start the Backup Daemon run:

<install_dir>/bin/mongodb-mms-backup-daemon start

If you run into any problems, the log ﬁles are at <install_dir>/logs.

Step 6: Open Ops Manager and access the Backup conﬁguration page.

Open the Ops Manager home page and log in as the user you ﬁrst registered when installing the Ops Manager Appli-

cation. (This user is the global owner.) Then click the Admin link at the top right of the page. Then click the Backup

tab.

Step 7: Enter conﬁguration information for the Backup database.

Enter the conﬁguration information described below, and then click Save. Ops Manager uses this information to create

the connection string URI used to connect to the database.

<hostname>:<port>: Enter a comma-separated list of the fully qualiﬁed domain names and port numbers for all

replica set members for the Backup database.

MongoDD Auth Username and MongoDB Auth Password: Enter the user credentials if the database uses authentica-

tion.

Encrypted Credentials: Check this if the user credentials use the Ops Manager credentialstool. For more

information, see Encrypt MongoDB User Credentials.

Use SSL: Check this if the MongoDB database uses SSL. If you select this, you must conﬁgure SSL settings for both

the Ops Manager Application and Backup Daemon. See Ops Manager Conﬁguration Files.

Connection Options: To add additional connection options, enter them using the MongoDB Connection String URI

Format.

Install Ops Manager on Windows

On this page

•Overview

•Prerequisites

•Procedures

•Next Step

Overview

This tutorial describes how to install the Ops Manager Application, which monitors MongoDB deployments, and the

optional Backup Daemon, which creates and stores deployment snapshots. This tutorial installs to Windows servers.

Ops Manager supports Monitoring and Backup on Windows but does not support Automation on Windows.

Prerequisites

Prior to installation you must:

• Conﬁgure Windows servers that meet the hardware and software requirements. Conﬁgure as many servers as

needed for your deployment. For deployment diagrams, see Example Installation Diagrams.

• Deploy the dedicated MongoDB instances that store the Ops Manager Application Database and Backup Block-

store Database. Do not use MongoDB instances that store other data. Ensure that ﬁrewall rules allow access to

the ports the instances runs on. See Deploy Backing MongoDB Replica Sets.

• Optionally install an SMTP email server.

Procedures

You must have administrative access on the machines to which you install.

Install and Start the Ops Manager Application

Step 1: Download Monitoring.

1. In a browser, go to http://www.mongodb.com/download.

2. Submit the subscription form.

3. On the MongoDB Enterprise Downloads page, go to the MongoDB Ops Manager section and click the here

link.

4. On the Ops Manager Download page, acknowledge the recommendation to contact MongoDB for production

installs.

5. On the MongoDB Ops Manager Downloads page, click the “Monitoring and Core” MSI link.

Step 2: Install the Ops Manager Application.

Right-click on the mongodb-mms-<version>.msi ﬁle and select Install. Follow the instructions in the Setup

Wizard.

During setup, the Conﬁguration/Log Folder screen prompts you to specify a folder for conﬁguration and log ﬁles. The

installation restricts access to the folder to administrators only.

Step 3: Conﬁgure the Ops Manager Application.

In the folder you selected for conﬁguration and log ﬁles, navigate to \Server\Config. For example, if you chose

C:\MMSData for conﬁguration and log ﬁles, navigate to C:\MMSData\Server\Config.

Open the conf-mms.properties ﬁle and conﬁgure the required settings below, as well as any additional settings

your deployment uses, such as authentication settings. For descriptions of all settings, see Ops Manager Conﬁguration

Files.

Set mms.centralUrl and mms.backupCentralUrl as follows, where <host> is the fully qualiﬁed domain

name of the server running the Ops Manager Application.

mms.centralUrl=http://<host>:8080

mms.backupCentralUrl=http://<host>:8081

Set the following Email Address Settings as appropriate. Each can be the same or different values.

mms.fromEmailAddr=<email_address>

mms.replyToEmailAddr=<email_address>

mms.adminFromEmailAddr=<email_address>

mms.adminEmailAddr=<email_address>

mms.bounceEmailAddr=<email_address>

Set the mongo.mongoUri option to the servers and ports hosting the Ops Manager Application database. For

example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

Step 4: Start the MongoDB Ops Manager HTTP Service.

Before starting the service, make sure the MongoDB instances that store the Ops Manager Application Database are

running and that they are reachable from the Ops Manager Application’s host machine. Ensure that ﬁrewall rules allow

access to the ports the MongoDB instances runs on.

To start the service, open Control Panel, then System and Security, then Administrative Tools,

and then Services.

In the Services list, right-click on the MongoDB Ops Manager HTTP Service and select Start.

Step 5: If you will also run MMS Backup, start the two Backup services.

In the Services list, right-click on the following services and select Start:

•MMS Backup HTTP Service

•MMS Backup Alert Service

Step 6: Open the Ops Manager home page and register the ﬁrst user.

To open the home page, enter the following URL in a browser, where <host> is the fully qualiﬁed domain name of

the server:

http://<host>:8080

Click the Register link and follow the prompts to register the ﬁrst user and create the ﬁrst group. The ﬁrst user is

automatically assigned the Global Owner role. When you ﬁnish, you are logged into the Ops Manager Application as

the new user. For more information on creating and managing users, see Manage Ops Manager Users.

Step 7: At the Welcome page, follow the prompts to set up Monitoring.

Ops Manager prompts you to download only the Monitoring Agent.

Install the Backup Daemon (Optional)

If you use Backup, install the Backup Daemon.

Step 1: Download the Backup Daemon package.

1. In a browser, go to http://www.mongodb.com/download.

2. Submit the subscription form.

3. On the MongoDB Enterprise Downloads page, go to the MongoDB Ops Manager section and click the here

link.

4. On the Ops Manager Download page, acknowledge the recommendation to contact MongoDB for production

installs.

5. On the MongoDB Ops Manager Downloads page, copy the link address of the “Backup” MSI link.

Step 2: Install the Backup Daemon.

Right-click on the mongodb-mms-backup-daemon-<version>.msi ﬁle and select Install. Follow the in-

structions in the Setup Wizard.

During setup, the Daemon Paths screen prompts you to specify the following folders. The installer will restrict access

to these folders to administrators only:

•Conﬁguration/Log Path. The location of the Backup Daemon’s conﬁguration and log ﬁles.

•Backup Data Root Path. The path where the Backup Daemon stores the local copies of the backed-up databases.

This location must have enough storage to hold a full copy of each database being backed up.

•MongoDB Releases Path. The location of the MongoDB software releases required to replicate the backed up

databases. These releases will be downloaded from mongodb.org by default.

Step 3: Conﬁgure the Backup Daemon.

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

In the folder you selected for storing conﬁguration and log ﬁles, navigate to \BackupDaemon\Config. For exam-

ple, if you chose C:\MMSData, navigate to C:\MMSData\BackupDaemon\Config.

Open the conf-daemon.properties ﬁle and conﬁgure the mongo.mongoUri property to point the Backup

Daemon to the servers and ports hosting the Ops Manager Application database. For example:

Step 4: Copy the gen-key ﬁle from the Ops Manager Application server to the Backup Daemon

server.

Important: You must copy the ﬁle as a whole. Do not open the ﬁle and copy its content.

Copy the gen.key ﬁle from the C:\MMSData\Secrets folder on the Ops Manager Application server to the

empty C:\MMSData\Secrets folder on the Backup Daemon server.

Step 5: If you have not already done so, start the Backup services on the Ops Manager Application

server.

On the Ops Manager Application server, open Control Panel, then System and Security, then

Administrative Tools, and then Services. Right-click on the following services and select Start:

•MMS Backup HTTP Service

•MMS Backup Alert Service

Step 6: Start the Backup Daemon.

On the Backup Daemon server, open Control Panel, then System and Security, then

Administrative Tools, and then Services. Right-click on the MMS Backup Daemon Service

and select Start.

Step 7: Open Ops Manager and access the Backup conﬁguration page.

Open the Ops Manager home page and log in as the user you registered when installing the Ops Manager Application.

Then click the Admin link at the top right of the page. Then click the Backup tab.

Step 8: Enter conﬁguration information for the Backup database.

Enter the conﬁguration information described here, and then click Save. Ops Manager uses this information to create

the connection string URI used to connect to the database.

<hostname>:<port>: Enter a comma-separated list of the fully qualiﬁed domain names and port numbers for all

replica set members for the Backup database. For test deployments, you can use a standalone MongoDB instance for

the database.

MongoDD Auth Username and MongoDB Auth Password: Enter the user credentials if the database uses authentica-

tion.

Encrypted Credentials: Check this if the user credentials use the Ops Manager credentialstool. For more

information, see Encrypt MongoDB User Credentials.

Use SSL: Check this if the MongoDB database uses SSL. If you select this, you must conﬁgure SSL settings for both

the Ops Manager Application and Backup Daemon. See Ops Manager Conﬁguration Files.

Connection Options: To add additional connection options, enter them using the MongoDB Connection String URI

Format.

Next Step

Set up security for your Ops Manager servers, Ops Manager agents, and MongoDB deployments.

Note: To set up a deployment 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.

2.6 Upgrade Ops Manager

Upgrade with DEB Packages Upgrade Ops Manager on Debian and Ubuntu systems.

Upgrade with RPM Packages Upgrade Ops Manager on Red Hat, Fedora, CentOS, and Amazon AMI Linux.

Upgrade from Archives on Linux Upgrade Ops Manager on other Linux systems, without using package manage-

ment.

Upgrade from Version 1.2 and Earlier Upgrade from a version before 1.3.

Upgrade Ops Manager with deb Packages

On this page

•Overview

•Prerequisite

•Procedures

Warning: To use Ops Manager 1.6 Automation to manage MongoDB Enterprise deployments, you must ﬁrst

install the MongoDB Enterprise dependencies to each server that runs MongoDB Enterprise. You must install the

dependencies to the servers before using Automation.

Note that Automation does not yet support use of the MongoDB Enterprise advanced security features (SSL,

LDAP, Kerberos, and auditing). Automation will support these features in the next major Ops Manager release.

To run MongoDB Enterprise with advanced security now, deploy MongoDB Enterprise manually (not through

Automation) and use Ops Manager only for Monitoring and Backup.

Overview

This tutorial describes how to upgrade an existing Ops Manager Application and Backup Daemon using deb packages.

Prerequisite

You must have administrative access on the machines on which you perform the upgrade.

You must have the download link available on the customer downloads page provided to you by MongoDB. If you do

not have this link, you can access the download page for evaluation at http://www.mongodb.com/download.

Procedures

If your version is earlier than 1.3, please see instead Upgrade from Version 1.2 and Earlier.

Upgrade the Ops Manager Application from Version 1.3 and Later

If you have an existing Ops Manager Application, use the following procedure to upgrade to the latest release. There

are no supported downgrade paths for Ops Manager.

Step 1: Recommended. Take a full backup of the Ops Manager database before beginning the

upgrade procedure.

Step 2: Shut down Ops Manager.

For example:

sudo service mongodb-mms stop

Step 3: If you are running Ops Manager Backup, shutdown the Ops Manager Backup Daemon.

The daemon may be installed on a different server. It is critical that this is also shut down. To shut down, issue a

command similar to the following:

sudo service mongodb-mms-backup-daemon stop

Step 4: Save a copy of your previous conﬁguration ﬁle.

For example:

sudo cp /opt/mongodb/mms/conf/conf-mms.properties ~/.

Step 5: Upgrade the package.

For example:

sudo dpkg -i mongodb-mms_<version>_x86_64.deb

Step 6: Edit the new conﬁguration ﬁle.

Fill in the new conﬁguration ﬁle at /opt/mongodb/mms/conf/conf-mms.properties using your old ﬁle

as a reference point.

Step 7: Start Ops Manager.

For example:

sudo service mongodb-mms start

Step 8: Update all Monitoring Agents.

See Install Monitoring Agent for more information.

Step 9: Update the Backup Daemon and any Backup Agent, as appropriate.

If you are running Backup, update the Backup Daemon package and any Backup Agent.

See Install Backup Agent for more information.

Upgrade the Backup Daemon

Step 1: Stop the currently running instance.

sudo service mongodb-mms-backup-daemon stop

Step 2: Download the latest version of the Backup Daemon.

Download the new version of the Backup Daemon package by issuing a curl command with the download link

available on the customer downloads page provided to you by MongoDB.

curl -OL <link-address-for-backup-deb-package>

Step 3: Point the Backup Daemon to the Ops Manager Application database.

Open the /opt/mongodb/mms-backup-daemon/conf/conf-daemon.properties ﬁle with root privi-

leges and set the mongo.mongoUri value to the servers and ports hosting the Ops Manager Application database.

For example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

Step 4: Synchronize the gen.key ﬁle

Synchronize the /etc/mongodb-mms/gen.key ﬁle from an Ops Manager Application server. This is only re-

quired if the Backup Daemon was installed on a different server than the Ops Manager Application.

Step 5: Start the back-end software package.

To start the Backup Daemon run:

sudo service mongodb-mms-backup-daemon start

If everything worked the following displays:

Start Backup Daemon [OK ]

If you run into any problems, the log ﬁles are at /opt/mongodb/mms-backup-daemon/logs.

Step 6: Open Ops Manager and access the Backup conﬁguration page.

Open the Ops Manager home page and log in as the user you ﬁrst registered when installing the Ops Manager Appli-

cation. (This user is the global owner.) Then click the Admin link at the top right of the page. Then click the Backup

tab.

Step 7: Enter conﬁguration information for the Backup database.

Enter the conﬁguration information described below, and then click Save. Ops Manager uses this information to create

the connection string URI used to connect to the database.

<hostname>:<port>: Enter a comma-separated list of the fully qualiﬁed domain names and port numbers for all

replica set members for the Backup database.

MongoDD Auth Username and MongoDB Auth Password: Enter the user credentials if the database uses authentica-

tion.

Encrypted Credentials: Check this if the user credentials use the Ops Manager credentialstool. For more

information, see Encrypt MongoDB User Credentials.

Use SSL: Check this if the MongoDB database uses SSL. If you select this, you must conﬁgure SSL settings for both

the Ops Manager Application and Backup Daemon. See Ops Manager Conﬁguration Files.

Connection Options: To add additional connection options, enter them using the MongoDB Connection String URI

Format.

Upgrade Ops Manager with rpm Packages

On this page

•Overview

•Prerequisite

•Procedures

Warning: To use Ops Manager 1.6 Automation to manage MongoDB Enterprise deployments, you must ﬁrst

install the MongoDB Enterprise dependencies to each server that runs MongoDB Enterprise. You must install the

dependencies to the servers before using Automation.

Note that Automation does not yet support use of the MongoDB Enterprise advanced security features (SSL,

LDAP, Kerberos, and auditing). Automation will support these features in the next major Ops Manager release.

To run MongoDB Enterprise with advanced security now, deploy MongoDB Enterprise manually (not through

Automation) and use Ops Manager only for Monitoring and Backup.

Overview

This tutorial describes how to upgrade an existing Ops Manager Application and Backup Daemon using rpm packages.

Prerequisite

You must have administrative access on the machines on which you perform the upgrade.

You must have the download link available on the customer downloads page provided to you by MongoDB. If you do

not have this link, you can access the download page for evaluation at http://www.mongodb.com/download.

Procedures

If your version is earlier than 1.3, please see instead Upgrade from Version 1.2 and Earlier.

Upgrade the Ops Manager Application from Version 1.3 and Later

If you have an existing Ops Manager Application, use the following procedure to upgrade to the latest release. There

are no supported downgrade paths for Ops Manager.

Step 1: Recommended. Take a full backup of the Ops Manager database before beginning the

upgrade procedure.

Step 2: Shut down Ops Manager.

For example:

sudo service mongodb-mms stop

Step 3: If you are running Ops Manager Backup, shutdown the Ops Manager Backup Daemon.

The daemon may be installed on a different server. It is critical that this is also shut down. To shut down, issue a

command similar to the following:

sudo service mongodb-mms-backup-daemon stop

Step 4: Save a copy of your previous conﬁguration ﬁle.

For example:

sudo cp /opt/mongodb/mms/conf/conf-mms.properties ~/.

Step 5: Upgrade the package.

For example:

sudo rpm -U mongodb-mms-<version>.x86_64.rpm

Step 6: Move the new version of the conﬁguration ﬁle into place.

Move the conf-mms.properties conﬁguration ﬁle to the following location:

/opt/mongodb/mms/conf/conf-mms.properties

Step 7: Edit the new conﬁguration ﬁle.

Fill in the new conﬁguration ﬁle at /opt/mongodb/mms/conf/conf-mms.properties using your old ﬁle

as a reference point.

Step 8: Start Ops Manager.

For example:

sudo service mongodb-mms start

Step 9: Update all Monitoring Agents.

See Install Monitoring Agent for more information.

Step 10: Update the Backup Daemon and any Backup Agent, as appropriate.

If you are running Backup, update the Backup Daemon package and any Backup Agent.

See Install Backup Agent for more information.

Upgrade the Backup Daemon

Step 1: Stop the currently running instance.

sudo service mongodb-mms-backup-daemon stop

Step 2: Download the latest version of the Backup Daemon.

Download the new version of the Backup Daemon package by issuing a curl command with the download link

available on the customer downloads page provided to you by MongoDB.

curl -OL <link-address-for-backup-rpm>

Step 3: Point the Backup Daemon to the Ops Manager Application database.

Open the /opt/mongodb/mms-backup-daemon/conf/conf-daemon.properties ﬁle with root privi-

leges and set the mongo.mongoUri value to the servers and ports hosting the Ops Manager Application database.

For example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

Step 4: Synchronize the gen.key ﬁle

Synchronize the /etc/mongodb-mms/gen.key ﬁle from an Ops Manager Application server. This is only re-

quired if the Backup Daemon was installed on a different server than the Ops Manager Application.

Step 5: Start the back-end software package.

To start the Backup Daemon run:

sudo service mongodb-mms-backup-daemon start

If everything worked the following displays:

Start Backup Daemon [OK ]

If you run into any problems, the log ﬁles are at /opt/mongodb/mms-backup-daemon/logs.

Step 6: Open Ops Manager and access the Backup conﬁguration page.

Open the Ops Manager home page and log in as the user you ﬁrst registered when installing the Ops Manager Appli-

cation. (This user is the global owner.) Then click the Admin link at the top right of the page. Then click the Backup

tab.

Step 7: Enter conﬁguration information for the Backup database.

Enter the conﬁguration information described below, and then click Save. Ops Manager uses this information to create

the connection string URI used to connect to the database.

<hostname>:<port>: Enter a comma-separated list of the fully qualiﬁed domain names and port numbers for all

replica set members for the Backup database.

MongoDD Auth Username and MongoDB Auth Password: Enter the user credentials if the database uses authentica-

tion.

Encrypted Credentials: Check this if the user credentials use the Ops Manager credentialstool. For more

information, see Encrypt MongoDB User Credentials.

Use SSL: Check this if the MongoDB database uses SSL. If you select this, you must conﬁgure SSL settings for both

the Ops Manager Application and Backup Daemon. See Ops Manager Conﬁguration Files.

Connection Options: To add additional connection options, enter them using the MongoDB Connection String URI

Format.

Upgrade Ops Manager from tar.gz or zip Archives

On this page

•Overview

•Prerequisite

•Procedures

Warning: To use Ops Manager 1.6 Automation to manage MongoDB Enterprise deployments, you must ﬁrst

install the MongoDB Enterprise dependencies to each server that runs MongoDB Enterprise. You must install the

dependencies to the servers before using Automation.

Note that Automation does not yet support use of the MongoDB Enterprise advanced security features (SSL,

LDAP, Kerberos, and auditing). Automation will support these features in the next major Ops Manager release.

To run MongoDB Enterprise with advanced security now, deploy MongoDB Enterprise manually (not through

Automation) and use Ops Manager only for Monitoring and Backup.

Overview

This tutorial describes how to upgrade an existing Ops Manager Application and Backup Daemon using tar.gz or zip

ﬁles.

Prerequisite

You must have administrative access on the machines on which you perform the upgrade.

You must have the download link available on the customer downloads page provided to you by MongoDB. If you do

not have this link, you can access the download page for evaluation at http://www.mongodb.com/download.

Procedures

If your version is earlier than 1.3, please see instead Upgrade from Version 1.2 and Earlier.

Upgrade the Ops Manager Application from Version 1.3 and Later

If you have an existing Ops Manager Application, use the following procedure to upgrade to the latest release. There

are no supported downgrade paths for Ops Manager.

To upgrade a tarball installation, backup the conﬁguration ﬁle and logs, and then re-install the Ops Manager server.

Important: It is crucial that you back up the existing conﬁguration because the upgrade process will delete existing

data.

In more detail:

Step 1: Shutdown the Ops Manager server and take a backup of your existing conﬁguration and

logs.

For example:

<install_dir>/bin/mongodb-mms stop

cp -a <install_dir>/conf ~/mms_conf.backup

cp -a <install_dir>/logs ~/mms_logs.backup

Step 2: If you are running Ops Manager Backup, shutdown the Ops Manager Backup Daemon.

The daemon may be installed on a different server. It is critical that this is also shut down. To shut down, issue a

command similar to the following:

<install_dir>/bin/mongodb-mms-backup-daemon stop

Step 3: Remove your existing Ops Manager server installation entirely and extract the latest release

in its place.

For example:

cd <install_dir>/../

rm -rf <install_dir>

tar -zxf -C . /path/to/mongodb-mms-<version>.x86_64.tar.gz

Step 4: Compare and reconcile any changes in conﬁguration between versions.

For example:

diff -u ~/mms_conf.backup/conf-mms.properties <install_dir>/conf/conf-mms.properties

diff -u ~/mms_conf.backup/mms.conf <install_dir>/conf/mms.conf

Step 5: Edit your conﬁguration to resolve any conﬂicts between the old and new versions.

Make conﬁguration changes as appropriate. Changes to mms.centralUri, email addresses, and MongoDB are the

most common conﬁguration changes.

Step 6: Restart the Ops Manager server.

For example:

<install_dir>/bin/mongodb-mms start

Step 7: Update all Monitoring Agents.

See Install Monitoring Agent for more information.

Step 8: Update the Backup Daemon and any Backup Agent, as appropriate.

If you are running Backup, update the Backup Daemon package and any Backup Agent.

See Install Backup Agent for more information.

Upgrade the Backup Daemon

Step 1: Stop the currently running instance.

<install_dir>/bin/mongodb-mms-backup-daemon stop

Step 2: Download the latest version of the Backup Daemon.

Download the new version of the Backup Daemon archive by issuing a curl command with the download link

available on the customer downloads page provided to you by MongoDB.

curl -OL <link-address-for-backup-tar.gz>

Step 3: To install the Backup Daemon, extract the downloaded archive ﬁle.

tar -zxf <downloaded-archive-file>

Step 4: Point the Backup Daemon to the Ops Manager Application database.

Open the <install-dir>/conf/conf-daemon.properties ﬁle and set the mongo.mongoUri value to

the servers and ports hosting the Ops Manager Application database. For example:

mongo.mongoUri=mongodb://mongodb1.example.net:27017,mongodb2.example.net:27017,

˓→mongodb3.example.net:27017

Additionally, ensure that the ﬁle system that holds the rootDirectory has sufﬁcient space to accommodate the

current snapshots of all backed up instances.

Step 5: Synchronize the mms-gen-key ﬁle.

Synchronize the <install-dir>/bin/mms-gen-key ﬁle from the Ops Manager Application server. This is

required only if the Backup Daemon is installed on a different server than the Ops Manager Application.

Step 6: Start the Backup Daemon.

To start the Backup Daemon run:

<install_dir>/bin/mongodb-mms-backup-daemon start

If you run into any problems, the log ﬁles are at <install_dir>/logs.

Step 7: Open Ops Manager and access the Backup conﬁguration page.

Open the Ops Manager home page and log in as the user you ﬁrst registered when installing the Ops Manager Appli-

cation. (This user is the global owner.) Then click the Admin link at the top right of the page. Then click the Backup

tab.

Step 8: Enter conﬁguration information for the Backup database.

Enter the conﬁguration information described below, and then click Save. Ops Manager uses this information to create

the connection string URI used to connect to the database.

<hostname>:<port>: Enter a comma-separated list of the fully qualiﬁed domain names and port numbers for all

replica set members for the Backup database.

MongoDD Auth Username and MongoDB Auth Password: Enter the user credentials if the database uses authentica-

tion.

Encrypted Credentials: Check this if the user credentials use the Ops Manager credentialstool. For more

information, see Encrypt MongoDB User Credentials.

Use SSL: Check this if the MongoDB database uses SSL. If you select this, you must conﬁgure SSL settings for both

the Ops Manager Application and Backup Daemon. See Ops Manager Conﬁguration Files.

Connection Options: To add additional connection options, enter them using the MongoDB Connection String URI

Format.

Upgrade from Version 1.2 and Earlier

On this page

•Overview

•Procedure

Warning: To use Ops Manager 1.6 Automation to manage MongoDB Enterprise deployments, you must ﬁrst

install the MongoDB Enterprise dependencies to each server that runs MongoDB Enterprise. You must install the

dependencies to the servers before using Automation.

Note that Automation does not yet support use of the MongoDB Enterprise advanced security features (SSL,

LDAP, Kerberos, and auditing). Automation will support these features in the next major Ops Manager release.

To run MongoDB Enterprise with advanced security now, deploy MongoDB Enterprise manually (not through

Automation) and use Ops Manager only for Monitoring and Backup.

Overview

Because of a company name change, the name of the Ops Manager package changed between versions 1.2 and 1.3.

Therefore, to upgrade from any version before 1.3, use the following procedure:

Procedure

1. Recommended. Take a full backup of the MMS database before beginning the upgrade procedure.

2. Shut down MMS, using the following command:

/etc/init.d/10gen-mms stop

3. Download the latest Ops Manager package from the downloads page and proceed with the instructions for a

fresh install. Do not attempt to use your package manager to do an upgrade.

4. Follow the procedure for a new install, including steps to conﬁgure the conf-mms.properties ﬁle. If

you used encrypted authentication credentials you will need to regenerate these manually. Do not copy the

credentials from your old properties ﬁle. Old credentials will not work.

5. Start Ops Manager using the new package name.

For upgrades using rpm or deb packages, issue:

sudo /etc/init.d/mongodb-mms start

For upgrades using tar.gz or zip archives, issue:

<install_dir>/bin/mongodb-mms start

6. Update the Monitoring Agent. See Install Monitoring Agent for more information.

2.7 Conﬁgure Local Mode if Ops Manager has No Internet Access

On this page

•Overview

•Prerequisites

•Required Access

•Procedure

Overview

The Automation Agent requires access to MongoDB binaries in order to install MongoDB on new deployments or

change MongoDB versions on existing ones. In a default conﬁguration, the agents access the binaries over the internet

from MongoDB Inc. If you deploy MongoDB on servers that have no internet access, you can run Automation by

conﬁguring Ops Manager to run in “local” mode, in which case the Automation Agents access the binaries from a

directory on the Ops Manager Application server.

Specify the directory in the conf-mms.properties conﬁguration ﬁle and then place .tgz archives of the binaries in that

directory. The Automation Agents will use these archives for all MongoDB installs. The “mongodb-mms” user must

possess the permissions to read the .tgz ﬁles in the “binaries” directory.

The following shows the ls -l output of the “binaries” directory for an example Ops Manager install that deploys

only the versions of MongoDB listed:

$cd /opt/mongodb/mms/mongodb-releases

$ ls -l

total 355032

-rw-r----- 1mongodb-mms staff 116513825 Apr 27 15:06 mongodb-linux-x86_64-2.6.9.tgz

-rw-r----- 1mongodb-mms staff 50194275 Apr 27 15:05 mongodb-linux-x86_64-3.0.2.tgz

-rw-r----- 1mongodb-mms staff 95800685 Apr 27 15:05 mongodb-linux-x86_64-enterprise-

˓→amzn64-2.6.9.tgz

-rw-r----- 1mongodb-mms staff 50594134 Apr 27 15:04 mongodb-linux-x86_64-enterprise-

˓→amzn64-3.0.2.tgz

-rw-r----- 1mongodb-mms staff 50438645 Apr 27 15:04 mongodb-linux-x86_64-enterprise-

˓→suse11-3.0.2.tgz

Prerequisites

Download Binaries Before Importing a Deployment

Populate the binaries directory with all required MongoDB versions before you import the deployment. If a version

is missing, the Automation Agents will not be able to take control of the deployment.

Determine Which Binaries to Store

Your binaries directory will require archives of following versions:

• versions used by existing deployments that you will import

• versions you will use to create new deployments

• versions you will use during an intermediary step in an upgrade. For example, if you will import an existing

MongoDB 2.6 Community deployment and upgrade it ﬁrst to MongoDB 3.0 Community and then to MongoDB

3.0 Enterprise, you must include all those editions and versions.

If you use both the MongoDB Community edition and the MongoDB Enterprise subscription edition, you must include

the required versions of both.

The following table describes the archives required for speciﬁc versions:

Edition Version Archive

Community 2.6+, 2.4+ Linux archive at http://www.mongodb.org/downloads.

Community 3.0+ Linux 64-bit legacy version at http://www.

mongodb.org/downloads.

Enterprise 3.0+, 2.6+, 2.4+ Platform-speciﬁc archive available from http:

//mongodb.com/download.

Warning: If you run Ops Manager 1.6 and use Automation to deploy MongoDB Enterprise, then you must

pre-install the MongoDB Enterprise Dependencies on your servers.

If your MongoDB Enterprise deployments use Enterprise’s advanced security features (SSL, LDAP, Kerberos, and

auditing), you can use Ops Manager for Monitoring and Backup only. You cannot currently use Automation with

the advanced security features. Automation will support these features in the next major Ops Manager release.

Prerequisite Packages Required for MongoDB Enterprise

If you use MongoDB Enterprise you must install the following prerequisite packages to each server that will run

MongoDB Enterprise:

•net-snmp

•net-snmp-libs

•openssl

•net-snmp-utils

•cyrus-sasl

•cyrus-sasl-lib

•cyrus-sasl-devel

•cyrus-sasl-gssapi

To install these packages on RHEL, CentOS and Amazon Linux, you can issue the following command:

sudo yum install openssl net-snmp net-snmp-libs net-snmp-utils cyrus-sasl cyrus-sasl-

˓→lib cyrus-sasl-devel cyrus-sasl-gssapi

Version Manifest

When you run in local mode, you must provide Ops Manager with the MongoDB version manifest, which lists all

released MongoDB versions. You provide the manifest to make Ops Manager aware of MongoDB versions, but

to make a version available to the Automation Agent, you must install the version’s archive on the Ops Manager

Application server and then select it for use in the associated group’s Version Manager.

To provide Ops Manager with the manifest, , in the Ops Manager web interface, click Admin in the upper right,

then click General, and then click Version Manifest. Here, you can update the manifest directly, if your browser has

internet access. Otherwise, copy the manifest from https://opsmanager.mongodb.com/static/version_manifest/1.6.json

and click the link for pasting in the manifest.

When MongoDB releases new versions, update the manifest.

Required Access

You must have Global Automation Admin or Global Owner access to perform this procedure.

Procedure

Step 1: Stop the Ops Manager Application if not yet running in local mode.

Use the command appropriate to your operating system.

On a Linux system installed with a package manager:

sudo service mongodb-mms stop

On a Linux system installed with a .tar ﬁle:

<install_dir>/bin/mongodb-mms stop

Step 2: Edit the conf-mms.properties conﬁguration ﬁle to enable local mode and to specify the

local directory for MongoDB binaries.

Open conf-mms.properties with root privileges and set the following automation.versions values:

Set the automation.versions.source setting to the value local:

automation.versions.source=local

Set automation.versions.directory to the directory on the Ops Manager Application server where you

will store .tgz archives of the MongoDB binaries for access by the Automation Agent.

For example:

automation.versions.directory=/opt/mongodb/mms/mongodb-releases/

Step 3: Start the Ops Manager Application.

Use the command appropriate to your operating system.

On a Linux system installed with a package manager:

sudo service mongodb-mms start

On a Linux system installed with a .tar ﬁle:

<install_dir>/bin/mongodb-mms start

Step 4: Populate the Ops Manager Application server directory with the .tgz ﬁles for the MongoDB

binaries.

Populate the directory you speciﬁed in the automation.versions.directory setting with the necessary ver-

sions of MongoDB as determined by the Determine Which Binaries to Store topic on this page.

Important: If you have not yet read the Determine Which Binaries to Store topic on this page, please do so before

continuing with this procedure.

For example, to download MongoDB Enterprise 3.0 on Amazon Linux, issue a command similar to the following,

replacing <download-url.tgz> with the download url for the archive:

sudo curl -OL <download-url.tgz>

Step 5: Ensure that the “mongodb-mms” user can read the MongoDB binaries.

The “mongodb-mms” user must be able to read the .tgz ﬁles placed in the directory you speciﬁed in the

automation.versions.directory.

For example, if on a Linux platform you place the .tgz ﬁles in the /opt/mongodb/mms/mongodb-releases/

directory, you could use the following sequence of commands to change ownership for all ﬁles in that directory to

“mongodb-mms”:

cd /opt/mongodb/mms/mongodb-releases/

sudo chown mongodb-mms:mongodb-mms ./*

Step 6: Open Ops Manager.

If you have not yet registered a user, click the Register link and follow the prompts to register a user and create the

ﬁrst group. The ﬁrst registered user is automatically assigned the Global Owner role.

Step 7: Copy the version manifest to Ops Manager.

1. If you have not already done so, copy the version manifest from https://opsmanager.mongodb.com/static/

version_manifest/1.6.json.

2. Click the Admin link in the upper right to go to the system-wide Administration settings.

3. Click the General tab and then click Version Manifest.

4. Do one of the following:

• If your browser has internet access, click Update the MongoDB Version Manifest and paste in the manifest.

• If your browser does not have internet access, follow the instructions on the page.

Step 8: Specify which versions are available for download by Automation Agents associated with

each group.

1. Click Ops Manager in the upper left to leave the system-wide Administration settings.

2. Click Deployment and then click Version Manager.

3. Select the checkboxes for the versions of MongoDB that you have made available on the Ops Manager Appli-

cation server.

4. Click Review & Deploy at the top of the page.

5. Click Conﬁrm & Deploy.

Step 9: Install the Automation Agent on each server on which you will manage MongoDB processes.

1. Click Administration and then Agents.

2. In the Automation section of the page, click the link for the operating system to which you will install. Following

the installation instructions.

3. Pre-install the MongoDB Enterprise Dependencies if deploying MongoDB Enterprise.

2.8 Conﬁgure High Availability

Application High Availability Outlines the process for achieving a highly available Ops Manager deployment.

Backup High Availability Make the Backup system highly available.

Conﬁgure a Highly Available Ops Manager Application

On this page

•Overview

•Prerequisites

•Procedure

•Additional Information

Overview

The Ops Manager Application provides high availability through horizontal scaling and through use of a replica set

for the backing MongoDB instance that hosts the Ops Manager Application Database.

Horizontal Scaling

The components of the Ops Manager Application 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 ﬁlls requests.

To take advantage of this for high availability, conﬁgure a load balancer to balance between the pool of Ops Man-

ager Application servers. Use the load balancer of your choice. Conﬁgure each application server’s conf-mms.

properties ﬁle to point the mms.centralUrl and mms.backupCentralUrl properties to the load balancer.

For more information, see Ops Manager Conﬁguration Files.

The mms.remoteIp.header property should reﬂect 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 for monitoring. Replica sets have

automatic failover if the primary becomes unavailable.

When deploying a replica set with members in multiple facilities, ensure that a single facility has enough votes to elect

aprimary 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.

To deploy a replica set, see Deploy a Replica Set.

You can create backups of the replica set using ﬁle system snapshots. File system snapshots use system-level tools to

create copies of the device that holds replica set’s data ﬁles.

Prerequisites

Deploy a replica set for the backing instance for the Ops Manager Application Database. To deploy a replica set, see

Deploy a Replica Set.

Procedure

To conﬁgure multiple application servers with load balancing:

Step 1: Conﬁgure a load balancer with the pool of Ops Manager Application servers.

This conﬁguration depends on the general conﬁguration of your load balancer and environment.

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

On each server, edit the conf-mms.properties ﬁle to conﬁgure the mms.centralUrl and mms.

backupCentralUrl properties to point to the load balancer URL.

The conf-mms.properties ﬁle is located in the <install_dir>/conf/ directory. See Ops Manager Con-

ﬁguration Files for more information.

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

On each server, edit the conf-mms.properties ﬁle to set the mongo.mongoUri property to the connection

string of the Ops Manager Application Database. You must specify at least 3hosts 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

Step 4: Synchronize the gen.key ﬁle across all the Ops Manager Application servers.

Synchronize the /etc/mongodb-mms/gen.key ﬁle across all Application Servers. The Ops Manager Applica-

tion server uses this ﬁle to encrypt sensitive information before storing the data in a database.

Additional Information

For information on making Ops Manager Backup highly available, see Conﬁgure a Highly Available Ops Manager

Backup Service.

Conﬁgure a Highly Available Ops Manager Backup Service

On this page

•Overview

•Additional Information

Overview

The Backup Daemon maintains copies of the data from your backed up mongod instances and creates snapshots used

for restoring data. The ﬁle system that the Backup Daemon uses must have sufﬁcient disk space and write capacity to

store the backed up instances.

For replica sets, the local copy is equivalent to an additional secondary replica set member. For sharded clusters the

daemon maintains a local copy of each shard as well as a copy of the conﬁg database.

To conﬁgure high availability

• scale your deployment horizontally by using multiple backup daemons, and

• provide failover for your Ops Manager Application Database and Backup Database by deploying replica sets

for the dedicated MongoDB processes that host the databases.

Multiple Backup Daemons

To increase your storage and to scale horizontally, you can run multiple instances of the Backup Daemon. With

multiple daemons, Ops Manager binds each backed up replica set or shard to a particular Backup Daemon. For

example, if you run two Backup Daemons for a cluster that has three shards, and if Ops Manager binds two shards to

the ﬁrst daemon, then that daemon’s server replicates only the data of those two shards. The server running the second

daemon replicates the data of the remaining shard.

Multiple Backup Daemons allow for manual failover should one daemon become unavailable. You can instruct Ops

Manager to transfer the daemon’s backup responsibilities to another Backup Daemon. Ops Manager reconstructs the

data on the new daemon’s server and binds the associated replica sets or shards to the new daemon. See Move Jobs

from a Lost Backup Service to another Backup Service for a description of this process.

Ops Manager reconstructs the data using a snapshot and the oplog from the Backup Blockstore Database. Installing

the Backup Daemon is part of the procedure to Install Ops Manager. Select the procedure speciﬁc to your operation

system.

Replica Sets for Application and Backup Data

Deploy replica sets rather than standalones for the dedicated MongoDB processes that host the Ops Manager Applica-

tion Database and Backup Database. Replica sets provide automatic failover should the primary become unavailable.

When deploying a replica set with members in multiple facilities, ensure that a single facility has enough votes to elect

aprimary 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.

To deploy a replica set, see Deploy a Replica Set.

Additional Information

To move jobs from a lost Backup server to another Backup server, see Move Jobs from a Lost Backup Service to

another Backup Service.

For information on making the Ops Manager Application highly available, see Conﬁgure a Highly Available Ops

Manager Application.

2.9 Conﬁgure Backup Jobs and Storage

Backup Data Locality Use multiple Backup daemons and blockstore instances to improve backup data locality.

Manage Backup Daemon Jobs Manage job assignments among the backup daemon

Conﬁgure Multiple Blockstores in Multiple Data Centers

On this page

•Overview

•Prerequisites

•Procedures

Overview

The Backup Blockstore databases are the primary storage systems for the backup data of your MongoDB deployments.

You can add new blockstores to your data center if existing ones have reached capacity.

If needed, you can also deploy blockstores in multiple data centers and assign backups of particular MongoDB deploy-

ments to particular data centers, as described on this page. You assign backups to data centers by attaching speciﬁc

Ops Manager groups to speciﬁc blockstores.

Deploy blockstores to multiple data centers when:

• Two sets of backed up data cannot have co-located storage for regulatory reasons.

• You have multiple data centers and want to reduce cross-data center network trafﬁc by keeping each blockstore

in the data center it backs.

This tutorial sets up two blockstores in two separate data centers and attaches a separate group to each.

Prerequisites

Each data center hosts a Backup Blockstore database and requires its own Ops Manager Application,Backup Daemon,

and Backup Agent

The two Ops Manager Application instances must share a single dedicated Ops Manager Application Database. You

can put members of the Ops Manager Application database replica set in each data center.

Conﬁgure each Backup Agent to use the URL for its local Ops Manager Application. You can conﬁgure each Ops

Manager Application to use a different hostname, or you can use split-horizon DNS to point each agent to its local

Ops Manager Application.

The Ops Manager Application database and the Backup Blockstore databases are MongoDB databases and can run as

standalones or replica sets. For production deployments, use replica sets to provide database high availability.

Procedures

Provision Servers in Each Data Center

Each server must meet the cumulative hardware and software requirements for the components it runs. See Ops

Manager Hardware and Software Requirements.

Servers that run the Backup Damon, Ops Manager Application database, and the Backup Blockstore databases all run

MongoDB. They must meet the conﬁguration requirements in the MongoDB Production Notes.

Install MongoDB

Install MongoDB on the servers that host the:

• Backup Daemon

• Ops Manager Application database

• Backup Blockstore databases

See Install MongoDB in the MongoDB manual to ﬁnd the correct install procedure for your operating system. To run

replica sets for the Ops Manager Application database and Backup Blockstore databases, see Deploy a Replica Set in

the MongoDB manual.

Install the Ops Manager Application

Install the Ops Manager Application in each data center but do not perform the step to start the service. See Install

Ops Manager to ﬁnd the procedure for your operating system.

In the step for conﬁguring the conf-mms.properties ﬁle, set the same Ops Manager Application URL in both

data centers. For example, in both data centers, set mms.centralUrl and mms.centralBackupUrl to point to

the server in Data Center 1:

mms.centralUrl =<application-server-in-data-center-1>:<8080>

mms.centralBackupUrl =<application-server-in-data-center-1>:<8081>

Start the Ops Manager Application

The Ops Manager Application creates a gen.key ﬁle on initial startup. You must start the Ops Manager Application

in one data center and copy its gen.key ﬁle before starting the other Ops Manager Application. Ops Manager uses

the same gen.key ﬁle for all servers in both data centers.

The gen.key ﬁle is binary. You cannot copy the contents: you must copy the ﬁle. For example, use SCP.

Step 1: Start the Ops Manager Application in Data Center 1.

Issue the following:

service mongodb-mms start

Step 2: Copy the gen.key ﬁle.

Copy the /etc/mongodb-mms/gen.key ﬁle from the Ops Manager Application server in Data Center 1 to the:

•/etc/mongodb-mms directory on the Ops Manager Application server in Data Center 2.

•/etc/mongodb-mms directory of each Backup Daemon server in each data center.

Step 3: Start the Ops Manager Application server in Data Center 2.

Issue the following:

service mongodb-mms start

Install the Backup Daemon

Install and start the Backup Daemon in each data center. See Install Ops Manager for instructions for your operating

system.

Bind Groups to Backup Resources

Step 1: In a web browser, open Ops Manager.

Step 2: Create a new Ops Manager group for the ﬁrst data center.

To create a group, select the Administration tab and open the My Groups page. Then, click Add Group and specify the

group name.”

Step 3: Create a second Ops Manager group for the second data center.

Step 4: Open the Admin interface.

In Ops Manager, select the Admin link in the upper right.

Step 5: Conﬁgure backup resources.

Select the Backup tab and do the following:

• Select the Daemons page and ensure there are two daemons listed.

• Select the Blockstores page. Add a blockstore with the hostname and port of the blockstore for the second data

center and click Save.

• Select the Sync Stores page. Add a sync store with the hostname and port of the blockstore for the second data

center and click Save.

• Select the Oplog Stores page. Add an oplog store with the hostname and port of the blockstore for the second

data center and click Save.

Step 6: Assign resources to the data centers.

Open the General tab, then the Groups page. Select the group you will house in the ﬁrst data center, and then select

the View link for the Backup Conﬁguration.

For each of the following, click the drop-down box and select the local option for the group:

•Backup Daemons

•Sync Stores

•Oplog Stores

•Block Stores

Repeat the above steps for the second group.

Step 7: Install agents.

If you are using Automation, install the Automation Agent for the group in Data Center 1 on each server in Data Center

1. Install the Automation Agent for Data Center 2 on each server in Data Center 2. The Automation Agent will then

install Monitoring and Backup agents as needed.

If you are not using Automation, download and install the Monitoring and Backup agents for the group assigned to

Data Center 1 by navigating to the Administration and then Agents page while viewing that group in Ops Manager.

Then, switch to the group in Data Center 2 by choosing it from the drop-down menu in the top navigation bar in Ops

Manager, and download and install its Monitoring and Backup agents.

See the following pages for the procedures for installing the agents manually:

•Install Monitoring Agent

•Install Backup Agent

Move Jobs from a Lost Backup Service to another Backup Service

On this page

•Overview

•Procedure

Overview

If the server running a Backup Daemon fails, and if you run multiple Backup Daemons, then an administrator with the

global owner or global backup admin role can move all the daemon’s jobs to another Backup Daemon.

The new daemon takes over the responsibility to back up the associated shards and replica sets.

When you move jobs, the destination daemon reconstructs the data using a snapshot and the oplog from the Backup

Blockstore database. Reconstruction of data takes time, depending on the size of the databases on the source.

During the time it takes to reconstruct the data and reassign the backups to the new Backup Daemon:

• Ops Manager Backup does not take new snapshots of the jobs that are moving until the move is complete. Jobs

that are not moving are not affected.

• Ops Manager Backup does save incoming oplog data. Once the jobs are on the new Backup Daemon’s server,

Ops Manager Backup takes the missed snapshots at the regular snapshot intervals.

• Restores of previous snapshots are still available.

• Ops Manager can produce restore artifacts using existing snapshots with point-in-time recovery for replica sets

or checkpoints for sharded clusters.

Procedure

With administrative privileges, you can move jobs between Backup daemons using the following procedure:

Step 1: Click the Admin link at the top of Ops Manager.

Step 2: Select Backup and then select Daemons.

The Daemons page lists all active Backup Daemons.

Step 3: Locate the failed Backup Daemon and click the Move all heads link.

Ops Manager displays a drop-down list from which to choose the destination daemon. The list displays only those

daemons with more free space than there is used space on the source daemon.

Step 4: Move the jobs to the new daemon.

Select the destination daemon and click the Move all heads button.

2.10 Test Ops Manager Monitoring

On this page

•Overview

•Procedure

Overview

The following procedure creates a MongoDB replica set and sets up a database populated with random data for use in

testing an Ops Manager installation. Create the replica set on a separate machine from Ops Manager.

These instructions create the replica set on a server running RHEL 6+ or Amazon Linux. The procedure installs all

the members to one server.

Procedure

Step 1: Increase each server’s default ulimit settings.

If you are installing to RHEL, check whether the /etc/security/limits.d directory contains the 90-nproc.

conf ﬁle. If the ﬁle exists, remove it. (The 90-nproc.conf ﬁle overrides limits.conf.) Issue the following

command to remove the ﬁle:

sudo rm /etc/security/limits.d/90-nproc.conf

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

Step 2: Install MongoDB on each server.

First, set up a repository deﬁnition by issuing the following command:

echo "[mongodb-org-3.0]

name=MongoDB Repository

baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.0/x86_64/

gpgcheck=0

enabled=1" | sudo tee -a /etc/yum.repos.d/mongodb-org-3.0.repo

Second, install MongoDB by issuing the following command:

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

Step 3: Create the data directories for the replica set.

Create a data directory for each replica set member and set mongod.mongod as each data directory’s owner.

For example, the following command creates the directory /data and then creates a data directory for each member

of the replica set. You can use different directory names:

sudo mkdir -p /data /data/mdb1 /data/mdb2 /data/mdb3

The following command sets mongod.mongod as owner of the new directories:

sudo chown mongod:mongod /data /data/mdb1 /data/mdb2 /data/mdb3

Step 4: Start a separate MongoDB instance for each replica set member.

Start each mongod instance on its own dedicated port number and with the data directory you created in the last step.

For each instance, specify mongod as the user. Start each instance with the replSet command-line option specifying

the name of the replica set.

For example, the following three commands start three members of a new replica set named rs0:

sudo -u mongod mongod --port 27017 --dbpath /data/mdb1 --replSet rs0 --logpath /data/

˓→mdb1/mongodb.log --fork

sudo -u mongod mongod --port 27018 --dbpath /data/mdb2 --replSet rs0 --logpath /data/

˓→mdb2/mongodb.log --fork

sudo -u mongod mongod --port 27019 --dbpath /data/mdb3 --replSet rs0 --logpath /data/

˓→mdb3/mongodb.log --fork

Step 5: Connect to one of the members.

For example, the following command connects to the member running on port 27017:

mongo --port 27017

Step 6: Initiate the replica set and add members.

In the mongo shell, issue the rs.initiate() and rs.add() methods, as shown in the following example. Replace the

hostnames in the example with the hostnames of your servers:

rs.initiate()

rs.add("mdb.example.net:27018")

rs.add("mdb.example.net:27019")

Step 7: Verify the replica set conﬁguration.

Issue the rs.conf() method and verify that the members array lists the three members:

rs.conf()

Step 8: Add data to the replica set.

Issue the following for loop to create a collection titled testData and populate it with 25,000 documents, each

with an _id ﬁeld and a ﬁeld xset to a random string.

for (var i=1;i<= 25000; i++) {

db.testData.insert( { x :Math.random().toString(36).substr(2,15) } );

sleep(0.1);

}

Step 9: Conﬁrm data entry.

After the script completes, you can view a document in the testData collection by issuing the following:

db.testData.findOne()

To conﬁrm that the script inserted 25,000 documents into the collection, issue the following:

db.testData.count()

Step 10: Open the Ops Manager home page in a web browser and register the ﬁrst user.

The ﬁrst user created for Ops Manager is automatically assigned the Global Owner role.

Enter the following URL in a web browser, where <ip_address> is the IP address of the server:

http://<ip_address>:8080

Click the Register link and enter information for the new Global Owner user. When you ﬁnish, you are logged into

the Ops Manager Application as that user. For more information on creating and managing users, see Manage Ops

Manager Users.

Step 11: Set up monitoring for the replica set.

If you have installed the Backup Daemon, click the Get Started button for Backup and follow the instructions. This

will set up both monitoring and backup. Otherwise click the Get Started button for Monitoring and follow instructions.

When prompted to add a host, enter the hostname and port of one of the replica set members in the form

<hostname>:<port>. For example: mdb.example.net:27018

When you ﬁnish the instructions, Ops Manager is running and monitoring the replica set.

3 Create a New MongoDB Deployment

Add Servers for Use by Automation Add servers to Ops Manager.

Deploy a Replica Set Use Ops Manager to deploy a managed replica set.

Deploy a Sharded Cluster Use Ops Manager to deploy a managed sharded cluster.

Deploy a Standalone For testing and deployment, create a new standalone MongoDB instance.

Connect to a MongoDB Process Connect to a MongoDB deployment managed by Ops Manager.

3.1 Add Servers for Use by Automation

This section describes how to add servers for use by Ops Manager Automation.

Overview How to add servers to Ops Manager.

Add Existing Servers to Ops Manager Add your existing servers to Ops Manager.

Overview

On this page

•Add Servers for Use by Automation

•Server Requirements

Add Servers for Use by Automation

You can add servers to Automation in the following ways:

• Provision existing systems and infrastructure. Ops Manager can deploy and manage MongoDB on your existing

servers. To use your existing hardware, you must deploy the Automation Agent to each server on which Ops

Manager will deploy MongoDB. See Add Existing Servers to Ops Manager.

• Use your local system for testing. Ops Manager can deploy MongoDB to your laptop or desktop system. Do

not use local systems for production deployments. To use your local system, you must deploy the Automation

Agent.

Server Requirements

The following are the minimum requirements for the servers that will host your MongoDB deployments:

Hardware:

• At least 10 GB of free disk space plus whatever space is necessary to hold your MongoDB data.

• At least 4 GB of RAM.

• If you use Amazon Web Services (AWS) EC2 instances, we recommend at least an m3.medium instance.

Networking:

• For each server that hosts a MongoDB process managed by Ops Manager, the output of hostname -f must

generate a hostname that is resolvable from all other servers in the MongoDB deployment.

Software:

If you provision your own servers and if you use MongoDB Enterprise, you must install the prerequisite packages on

the servers before deploying MongoDB Enterprise to the servers.

Add Existing Servers to Ops Manager

On this page

•Overview

•Prerequisites

•Procedure

Overview

You can allow Ops Manager to install, manage, and discover MongoDB processes on your existing servers. To do so,

you install the Automation Agent on each server.

Prerequisites

Ensure that the directories used by the Automation Agent have appropriate permissions for the user running the agent.

You can install the Automation Agent on the operating systems listed in Ops Manager on the Administration tab’s

Agents page.

To install the agent using rpm or deb packages, you must have root access.

Important: If a server runs MongoDB Enterprise, you must install the prerequisite packages on the server before

deploying MongoDB Enterprise on the servers.

Procedure

Install the Automation Agent on each each server that you want Ops Manager to manage. The following procedure

applies to all operating systems. For instructions for a speciﬁc operating system, see Install the Automation Agent.

Step 1: Select the Administration tab and then select Agents.

Step 2: Under Automation at the bottom of the page, click your operation system and follow the

instructions to install and run the agent.

If the install ﬁle is a tar.gz archive ﬁle, make sure to extract the archive after download.

Step 3: Ensure that the directories used by the Automation Agent have appropriate permissions for

the user that runs the agent.

Set the required permissions described in Directory and File Permissions.

Once you have installed the agent to all your servers, you can deploy your ﬁrst replica set,cluster, or standalone.

3.2 Deploy a Replica Set

On this page

•Overview

•Consideration

•Prerequisites

•Procedure

Overview

Areplica set is a group of MongoDB deployments that maintain the same data set. Replica sets provide redundancy and

high availability and are the basis for all production deployments. See the Replication Introduction in the MongoDB

manual for more information about replica sets.

Use this procedure to deploy a new replica set managed by Ops Manager. After deployment, use Ops Manager to

manage the replica set, including such operations as adding, removing, and reconﬁguring members.

Consideration

Use unique replica set names for different replica sets within an Ops Manager group. Do not give different replica sets

the same name. Ops Manager uses the replica set name to identify which set a member belongs to.

Prerequisites

You must have an existing set of servers to which to deploy, and Ops Manager must have access to the servers.

The servers can exist on your own system or on Amazon Web Services (AWS). To give Ops Manager access to servers

on your system, install the Automation Agent to each server.

Important: If you provision your own servers and if you use MongoDB Enterprise, you must install the prerequisite

packages on the servers before deploying MongoDB Enterprise on the servers.

Procedure

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click edit mode, and then click Add and select Create New Replica Set.

Step 3: Conﬁgure the replica set.

Enter information as required and click Apply.

To select speciﬁc servers to use for the deployment, enter the preﬁx of the servers in the Eligible Server RegExp ﬁeld.

You can use regular expressions. To use all provisioned servers, enter a period (“.”). To run the deployment on your

local machine, enter the name of the machine.

For information on replica set options in the Member Options box, see Replica Set Members in the MongoDB Manual.

The votes ﬁeld applies only to pre-2.6 versions of MongoDB.

To conﬁgure additional mongod runtime options, such as specifying the oplog size, or modifying journaling settings,

click Advanced Options. For option descriptions, see Advanced Options for MongoDB Deployments.

Step 4: Click Review & Deploy to review the conﬁguration.

Ops Manager displays the full conﬁguration for you to review.

Step 5: Click Conﬁrm & Deploy.

To view deployment progress, click View Agent Logs and select an agent at the top of the Agent Logs page. To check

for updated entries, refresh the page.

If you diagnose an error and need to correct the deployment conﬁguration, click Edit Conﬁguration and then click Edit

Conﬁguration again. Reconﬁgure the deployment through the deployment arrow button or through the Add button. If

you cannot ﬁnd a solution, shut down the deployment. When you complete your changes, click Review & Deploy and

then Conﬁrm & Deploy.

3.3 Deploy a Sharded Cluster

On this page

•Overview

•Prerequisites

•Procedure

Overview

Sharded clusters provide horizontal scaling for large data sets and enable high throughput operations by distributing

the data set across a group of servers. See the Sharding Introduction in the MongoDB manual for more information.

Use this procedure to deploy a new sharded cluster managed by Ops Manager. Later, you can use Ops Manager to add

shards and perform other maintenance operations on the cluster.

Prerequisites

You must have an existing set of servers to which to deploy, and Ops Manager must have access to the servers.

The servers can exist on your own system or on Amazon Web Services (AWS). To give Ops Manager access to servers

on your system, install the Automation Agent to each server.

Important: If you provision your own servers and if you use MongoDB Enterprise, you must install the prerequisite

packages on the servers before deploying MongoDB Enterprise on the servers.

Procedure

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click edit mode, and then click Add and select Create New Cluster.

Step 3: Conﬁgure the sharded cluster.

Enter information as required and click Apply.

To select speciﬁc servers to use for the deployment, enter the preﬁx of the servers in the Eligible Server RegExp ﬁeld.

You can use regular expressions. To use all provisioned servers, enter a period (“.”). To run the deployment on your

local machine, enter the name of the machine.

For information on replica set options in the Member Options box, see Replica Set Members in the MongoDB Manual.

The votes ﬁeld applies only to pre-2.6 versions of MongoDB.

To conﬁgure additional mongod or mongos options, such as specifying the oplog size, or modifying journaling

settings, click Advanced Options. For option descriptions, see Advanced Options for MongoDB Deployments.

Step 4: Click Review & Deploy to review the conﬁguration.

Ops Manager displays the full conﬁguration for you to review.

Step 5: Click Conﬁrm & Deploy.

To view deployment progress, click View Agent Logs and select an agent at the top of the Agent Logs page. To check

for updated entries, refresh the page.

If you diagnose an error and need to correct the deployment conﬁguration, click Edit Conﬁguration and then click Edit

Conﬁguration again. Reconﬁgure the deployment through the deployment arrow button or through the Add button. If

you cannot ﬁnd a solution, shut down the deployment. When you complete your changes, click Review & Deploy and

then Conﬁrm & Deploy.

3.4 Deploy a Standalone MongoDB Instance

On this page

•Overview

•Prerequisites

•Procedure

Overview

You can deploy a standalone MongoDB instance managed by Ops Manager. Use standalone instances for testing and

development. Do not use these deployments, which lack replication and high availability, for production systems. For

all production deployments use replica sets. See Deploy a Replica Set for production deployments.

Prerequisites

You must have an existing server to which to deploy. For testing purposes, you can use your localhost, or another

machine to which you have access.

Important: If you provision your own server and if you use MongoDB Enterprise, you must install the prerequisite

packages to the server before deploying MongoDB Enterprise on it.

Procedure

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click edit mode, and click Add and select Create New Standalone.

Step 3: Conﬁgure the standalone MongoDB instance.

Enter information as required and click Apply. For descriptions of Advanced Options, see Advanced Options for

MongoDB Deployments.

Step 4: Click Review & Deploy to review the conﬁguration.

Ops Manager displays the full conﬁguration for you to review.

Step 5: Click Conﬁrm & Deploy.

To view deployment progress, click View Agent Logs and select an agent at the top of the Agent Logs page. To check

for updated entries, refresh the page.

If you diagnose an error and need to correct the deployment conﬁguration, click Edit Conﬁguration and then click Edit

Conﬁguration again. Reconﬁgure the deployment through the deployment arrow button or through the Add button. If

you cannot ﬁnd a solution, shut down the deployment. When you complete your changes, click Review & Deploy and

then Conﬁrm & Deploy.

3.5 Connect to a MongoDB Process

On this page

•Overview

•Firewall Rules

•Procedures

Overview

To connect to a MongoDB instance, retrieve the hostname and port information from the Ops Manager console and

then use a MongoDB client, such as the mongo shell or a MongoDB driver, to connect to the instance. You can

connect to a cluster,replica set,orstandalone.

Firewall Rules

Firewall rules and user authentication affect your access to MongoDB. You must have access to the server and port of

the MongoDB process.

If your MongoDB instance runs on Amazon Web Services (AWS), then the security group associated with the AWS

servers also affects access. AWS security groups control inbound and outbound trafﬁc to their associated servers.

Procedures

Get the Connection Information for the MongoDB Instance

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click view mode.

Step 3: Click the process.

For a replica set, click the primary. For a sharded cluster, click the mongod.

Ops Manager displays the hostname and port of the process at the top of the charts page.

Connect to a Deployment Using the Mongo Shell

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click view mode.

Step 3: Click the process.

For a replica set, click the primary. For a sharded cluster, click the mongod.

Ops Manager displays the hostname and port of the process above the status charts.

Step 4: On a system shell, run mongo and specify the host and port of the deployment.

Issue a command in the following form:

mongo --username <user> --password <pass> --host <host> --port <port>

Connect to a Deployment Using a MongoDB Driver

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click view mode.

Step 3: Click the process.

For a replica set, click the primary. For a sharded cluster, click the mongod.

Ops Manager displays the hostname and port of the process at the top of the charts on the page.

Step 4: Connect from your driver.

Use your driver to create a connection string that speciﬁes the hostname and port of the deployment. The connection

string for your driver will resemble the following:

mongodb://[<username>:<password>@]hostname0<:port>[,hostname1:<port1>][,hostname2:

˓→<port2>][...][,hostnameN:<portN>]

If you specify a seed list of all hosts in a replica set in the connection string, your driver will automatically connect to

the term:primary.

For standalone deployments, you will only specify a single host. For sharded clusters, only specify a single mongos

instance.

Retrieve the Command to Connect Directly from the Process’s Server

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click view mode.

Step 3: Click the instance’s gear icon and select Connect to this Instance.

Ops Manager provides a mongo shell command that you can use to connect to the MongoDB process if you are

connecting from the system where the deployment runs.

4 Import an Existing MongoDB Deployment

Add Existing Processes to Monitoring Add existing MongoDB processes to Ops Manager Monitoring.

Add Monitored Processes to Automation Add an existing MongoDB deployment to be managed through Ops Man-

ager Automation.

Reactivate Monitoring for a Process Reactivate a deactivated MongoDB process.

Remove Hosts Remove processes you no longer use from monitoring.

4.1 Add Existing MongoDB Processes to Monitoring

On this page

•Overview

•Prerequisite

•Add MongoDB Processes

Overview

You can monitor existing MongoDB processes in Ops Manager by adding the hostnames and ports of the processes.

Ops Manager will start monitoring the mongod and mongos instances.

If you add processes from an environment that uses authentication, you must add each mongod instance separately

and explicitly set the authentication credentials on each.

If you add processes in an environment that does not use authentication, you can manually add one process from a

replica set or a sharded cluster as a seed. Once the Monitoring Agent has the seed, it automatically discovers all the

other nodes in the replica set or sharded cluster.

Unique Replica Set Names

Do not add two different replica sets with the same name. Ops Manager uses the replica set name to identify which

set a member belongs to.

Preferred Hostnames

If the MongoDB process is accessible only by speciﬁc hostname or IP address, or if you need to specify the hostname

to use for servers with multiple aliases, set up a preferred hostname. For details, see the Preferred Hostnames setting

in Group Settings.

Prerequisite

You must install a Monitoring Agent to your infrastructure.

To monitor or back up MongoDB 3.0 deployments, you must install Ops Manager 1.6 or higher. To monitor a Mon-

goDB 3.0 deployment, you must also run Monitoring Agent version 2.7.0 or higher.

Important: If you provision your own servers and if you use MongoDB Enterprise, you must install the prerequisite

packages on the servers before deploying MongoDB Enterprise on the servers.

Add MongoDB Processes

If your deployments use authentication, perform this procedure for each process. If your deployment does not use

authentication, add one process from a replica set or sharded cluster and Ops Manager will discover the other nodes in

the replica set or sharded cluster.

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Select view mode and then select Add Host.

Step 3: Enter information for the MongoDB process.

Enter the following information, as appropriate:

Host Type The type of MongoDB deployment.

Internal Hostname The hostname of the MongoDB instance as seen from the Monitoring

Agent.

Port The port on which the MongoDB instance runs.

Auth Mechanism The authentication mechanism used by the host.

•MONGODB-CR,

•LDAP (PLAIN), or

•Kerberos(GSSAPI).

See Add Monitoring Agent User for MONGODB-CR,Conﬁgure Monitor-

ing Agent for LDAP, or Conﬁgure the Monitoring Agent for Kerberos for

setting up user credentials.

DB Username If the authentication mechanism is MONGODB-CR or LDAP, the user-

name used to authenticate the Monitoring Agent to the MongoDB deploy-

ment.

DB Password If the authentication mechanism is MONGODB-CR or LDAP, the pass-

word used to authenticate the Monitoring Agent to the MongoDB deploy-

ment.

My deployment supports SSL for Mon-

goDB connections

If checked, the Monitoring Agent must have a trusted CA certiﬁcate in

order to connect to the MongoDB instances. See Conﬁgure Monitoring

Agent for SSL.

Step 4: Click Add.

To view agent output logs, click the Administration tab, then Agents, and then view logs for the agent.

To view process logs, click the Deployment tab, then the Deployment page, then the process, and then the Logs tab.

For more information on logs, see View Logs.

4.2 Add Monitored Processes to Automation

On this page

•Overview

•Prerequisites

•Procedures

Overview

Ops Manager can automate operations for your monitored MongoDB processes. Adding your processes to Automation

lets you reconﬁgure, stop, and restart MongoDB through the Ops Manager interface.

Adding monitored processes involves two steps. First, install the Automation Agent on each server hosting a monitored

MongoDB process. Second, add the processes to Automation through the Ops Manager interface.

Prerequisites

Automation Agents can run only on 64-bit architectures.

Automation supports most but not all available MongoDB options. Automation supports the options described in

Supported MongoDB Options for Automation.

The user running the Automation Agent must the same as the user running the MongoDB process to be managed.

The servers that host the MongoDB processes must have full networking access to each other through their fully

qualiﬁed domain names (retrieved on each server by issuing hostname -f). Each server must be able to reach

every other server through the FQDN.

Ensure that your network conﬁguration allows each Automation Agent to connect to every MongoDB process listed

on the Deployment tab. Ensure that the network and security systems, including all interfaces and ﬁrewalls, allow

these connections.

Ops Manager must be currently monitoring the MongoDB processes, and the Monitoring Agent must be running. The

processes must appear in the Ops Manager Deployment tab.

Procedures

Install the Automation Agent on Each Server

Install the Automation Agent on each server that hosts a monitored MongoDB process. Ensure that the Automation

Agent has adequate permissions to stop and restart the existing Monitoring Agent so that it can update the Monitoring

Agent as new versions are released.

On each server, you must download the agent, create the necessary directories, and conﬁgure the agent’s local.

config ﬁle with the Group ID and API key.

Step 1: In Ops Manager, select the Administration tab and then select Agents.

Step 2: Under Automation at the bottom of the page, click your operation system and follow the

instructions to install and run the agent.

For additional information on installing the agent, see Install the Automation Agent.

Add the Processes to Automation

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click edit mode, and then click the Add button and select Attach to Existing.

Step 3: Select the MongoDB processes.

Click the Deployment Item ﬁeld to display your currently monitored processes. Select the cluster, replica set or

standalone to add.

Step 4: Click Start Import.

Ops Manager displays the progress of the import for each MongoDB process, including any errors. If you need to

correct errors, click Stop Import, correct them, and restart this procedure.

Step 5: Click Conﬁrm Import.

Step 6: Click Review & Deploy.

Step 7: Click Conﬁrm & Deploy.

Ops Manager Automation takes over the management of the processes and peforms a rolling restart. To view progress,

click View Agent Logs.

If you diagnose an error that causes Automation to fail to complete the deployment, click Edit Conﬁguration to correct

the error.

4.3 Reactivate Monitoring for a Process

On this page

•Overview

•Procedure

Overview

If the Monitoring Agent cannot collect information from a MongoDB process, Ops Manager stops monitoring the

process. By default, Ops Manager stops monitoring a mongos that is unreachable for 24 hours and a mongod that is

unreachable for 7 days. Your group might have different default behavior. Ask your system administrator.

When the system stops monitoring a process, the Deployment page marks the process with an xin the Last Ping

column. If the instance is a mongod, Ops Manager displays a caution icon at the top of each Deployment page.

You can reactivate monitoring for the process whether or not the process is running. When you reactivate monitoring,

the Monitoring Agent has an hour to reestablish contact and provide a ping to Ops Manager. If a process is running

and reachable, it appears marked with a green circle in the Last Ping column. If it is unavailable, it appears marked

with a red square. If it remains unreachable for an hour, Ops Manager again stops monitoring the process.

You can optionally remove a process that you are no longer using. Removed processes are permanently hidden from

Ops Manager. For more information, see Remove Hosts.

Procedure

To reactivate monitoring for a process:

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click the warning icon at the top of the page.

Step 3: Click Reactivate ALL hosts.

The processes that are now running and reachable by the Monitoring Agent will appear marked with green circles in

the Last Ping column.

The processes that are unavailable or unreachable will appear marked with a red square. If a process does not send a

ping within an hour after reactivation, it is deactivated again.

Step 4: Add the mongos instances.

To activate the mongos instances, click the Add Host button and enter the hostname, port, and optionally an admin

database username and password. Then click Add.

4.4 Remove Hosts

On this page

•Overview

•Procedure

Overview

You can remove hosts that you no longer use, but when you do they are hidden permanently. If you run the instance

again, Ops Manager will not discover it. If you choose to add the host again, Ops Manager will not display it.

Only a global administrator can undelete the host so that it will again display if added. The administrator can add the

host back through the Deleted Hosts page in the Ops Manager Admin interface.

Instead of removing a host, you can optionally disable alerts for the host, which does not remove it from the Deploy-

ment pages. See Manage Host Alerts.

Procedure

To remove a host from Ops Manager:

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: On the line listing the process, click the gear icon and select Remove Host.

Step 3: Click Delete.

Step 4: If prompted for a two-factor authentication code, enter it, click Verify, and then click Delete

again.

5 Manage Deployments

Edit a Replica Set Add hosts to, remove hosts from, or modify the conﬁguration of hosts in an Ops Manager managed

replica set. - ‘cloud’ - ‘onprem’

Migrate a Replica Set Member to a New Server Migrate replica sets to new underlying systems by adding members

to the set and decommissioning existing members.

Move or Add a Monitoring or Backup Agent Migrate a backup and monitoring agents to different servers.

Change the Version of MongoDB Upgrade or downgrade MongoDB deployments managed by Ops Manager.

Restart a MongoDB Process Restart MongoDB deployments managed by Ops Manager.

Shut Down MongoDB Processes Shut down MongoDB deployments managed by Ops Manager.

Remove Processes from Monitoring Remove MongoDB deployments from management by Ops Manager.

Alerts Set up and manage alert conﬁgurations.

Monitoring Metrics Interpreting the metrics.

Logs View host and agent logs.

5.1 Edit a Replica Set

On this page

•Overview

•Procedures

•Additional Information

Overview

You can add, remove, and reconﬁgure members in a replica set directly in the Ops Manager console.

Procedures

Add a Replica Set Member

You must have an existing server to which to deploy the new replica set member. To add a member to an existing

replica set, increasing the size of the set:

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Edit the replica set.

Click edit mode. Then click the arrow to the right of the replica set and click the Edit button.

Step 3: Add the member.

In the MongoDs Per Replica Set ﬁeld, click +to increase the number of members for the replica set.

Conﬁgure the new members as desired in the Member Options box.

Then click Apply.

Step 4: Click Review & Deploy to review the conﬁguration.

Ops Manager displays the full conﬁguration for you to review.

Step 5: Click Conﬁrm & Deploy.

To view deployment progress, click View Agent Logs and select an agent at the top of the Agent Logs page. To check

for updated entries, refresh the page.

If you diagnose an error and need to correct the deployment conﬁguration, click Edit Conﬁguration and then click Edit

Conﬁguration again. Reconﬁgure the deployment through the deployment arrow button or through the Add button. If

you cannot ﬁnd a solution, shut down the deployment. When you complete your changes, click Review & Deploy and

then Conﬁrm & Deploy.

Edit a Replica Set Member

Use this procedure to:

• Reconﬁgure a member as hidden

• Reconﬁgure a member as delayed

• Reset a member’s priority level in elections

• Reset a member’s votes (for pre-2.6 versions of MongoDB)

To reconﬁgure a member as an arbiter, see Replace a Member with an Arbiter.

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click edit mode, and then click the arrow to the right of the replica set and click the Edit

button.

Step 3: In the Member Options box, conﬁgure each member as needed.

For information on member options, see the following in the MongoDB manual:

•Hidden Members

•Delayed Members

•Elections, which describes priority levels.

The Votes ﬁeld applies to pre-2.6 versions of MongoDB.

Step 4: Click Apply.

Step 5: Click Review & Deploy to review the conﬁguration.

Ops Manager displays the full conﬁguration for you to review.

Step 6: Click Conﬁrm & Deploy.

To view deployment progress, click View Agent Logs and select an agent at the top of the Agent Logs page. To check

for updated entries, refresh the page.

If you diagnose an error and need to correct the deployment conﬁguration, click Edit Conﬁguration and then click Edit

Conﬁguration again. Reconﬁgure the deployment through the deployment arrow button or through the Add button. If

you cannot ﬁnd a solution, shut down the deployment. When you complete your changes, click Review & Deploy and

then Conﬁrm & Deploy.

Replace a Member with an Arbiter

You cannot directly reconﬁgure a member as an arbiter. Instead, you must must add a new member to the replica set

as an arbiter. Then you must shut down an existing secondary.

Step 1: Select the Deployment tab and then the Deployment page.

Step 2: Click edit mode.

Step 3: Click the arrow to the right of the replica set and then click the Edit button.

Step 4: Add an arbiter.

In the MongoDs Per Replica Set ﬁeld, increase the number of members by 1.

In the Member Options box, click the member’s drop-down arrow and select Arbiter.

Click Apply.

Step 5: Click Review & Deploy.

Step 6: Click Conﬁrm & Deploy.

Step 7: Remove the secondary.

When the deployment completes, click the arrow to the right of the secondary to remove. Click the gear icon drop-

down list, and select Remove Member.”

Step 8: Click Review & Deploy.

Step 9: Click Conﬁrm & Deploy.

To view deployment progress, click View Agent Logs and select an agent at the top of the Agent Logs page. To check

for updated entries, refresh the page.

If you diagnose an error and need to correct the deployment conﬁguration, click Edit Conﬁguration and then click Edit

Conﬁguration again. Reconﬁgure the deployment through the deployment arrow button or through the Add button. If