Navigation
This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.

Ops Manager Components

An Ops Manager installation includes servers running Ops Manager and servers hosting dedicated MongoDB databases for storing application data and snapshots.

Network Diagram

Network diagram showing flows of data between Ops Manager's components.

Ops Manager

The Ops Manager installation package consists of the Ops Manager Application and Backup Daemon Service. The Ops Manager application requires an Ops Manager Application Database (a dedicated MongoDB database to hold operational data) as well as dedicated MongoDB Backup Database(s).

Ops Manager Application

The Ops Manager Application contains the user interface and the HTTP services the Agents use to transmit data to and from Ops Manager. These are all stateless and start automatically when the Ops Manager Application starts. Multiple instances of the Ops Manager Application can run as long as each instance has the same configuration. Users and agents can interact with any instance.

The HTTP Service runs on port 8080 by default and 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 Daemon Service

Any Ops Manager instance can be configured to run the Backup Daemon service to provide backup capabilities. The Backup Daemon service manages both the local copies of the backed-up databases and each backup’s snapshots. The daemon does scheduled work based on data coming into the 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 takes scheduled snapshots and stores the snapshots in either databases (the Backup Data Storage) or on the file system (the file system store). It also acts on restore requests by retrieving data from the Backup Database and delivering it to the requested destination.

Multiple Backup Daemons scale horizontally to increase your storage and can provide manual failover.

The Backup Daemon exposes a health-check endpoint. See Firewall Configuration.

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 operational backup data. The backing databases run as replica sets to ensure redundancy and high availability. The replica sets host only Ops Manager data. You must provision the replica sets before installing Ops Manager.

Ops Manager Application Database

This database contains Ops Manager Application metadata:

  • Monitoring data collected from Monitoring Agents.
  • Metadata for Ops Manager users, groups, hosts, monitoring data, and backup state.

For topology and specifications, see Ops Manager Application Database Hardware Requirements.

Backup Data Storage

Ops Manager backs up snapshots of deployments. These snapshots are stored in either databases or file systems. There can be more than one database and/or file system paths to which snapshots are written. The recent history of the deployment database is written to a separate database regardless of where the snapshots are written.

The components of backup data storage include:

  • Snapshots. Snapshots can be written to one of two destinations:
  • Oplog Slices. The Oplog Store retains oplog entries the Backup Daemon applies to its local copies of your backed-up deployments.

The Blockstore backup option requires:

  • Two databases that run on a dedicated MongoDB deployment that holds no other data:
    • A large database to store the backup data (the Blockstore).
    • A small database to store the operations logs (the Oplog Store).
  • Disk space proportional to the deployments being backed up. See Backup Database Hardware Requirements.

If redundancy and high availability for the backup data is desired, configure the Blockstores and Oplog Stores as a replica sets with three data-bearing members.

Important

Ops Manager cannot be backed up using Ops Manager Backup. See Back Up Ops Manager.

The File System Store backup option requires:

  • A small backup database (the Oplog Store) in a MongoDB deployment.
  • A filesystem path that can be mounted from all Ops Manager application instances so they can read and write backup snapshots.

Default Ports

For a list of Ops Manager’s default ports and health-check endpoints, see Firewall Configuration.