Navigation
This version of the documentation is archived and no longer supported. It will be removed on EOL_DATE. 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.
This version of the manual is no longer supported. It will be removed on EOL_DATE.

Ops Manager Architecture

An Ops Manager installation includes hosts running Ops Manager and hosts serving and storing application data and snapshots.

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

The Ops Manager Application requires a dedicated Application Database and, if you enabled backups, Snapshot Stores.

Ops Manager Application

The Ops Manager Application provides 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 if each instance uses the same configuration and application database. Users and agents can interact with any instance.

By default, the Ops Manager Application runs on port 8080 and contains the web interface for managing Ops Manager users, monitoring of MongoDB hosts, and managing host backups.

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

Backup Daemon Service

You can configure any Ops Manager instance to run the Backup Daemon service to back up MongoDB databases. The Backup Daemon service manages the local copies of the backed-up databases and snapshots for each database. The daemon does scheduled work based on data coming into the Ops Manager from its Backup Agents. No client applications can talk directly to the daemon. Its state and job queues come from the Ops Manager Application Database.

The local backup copy of a deployment is called the head database. The Backup Daemon stores all its head databases in its head directory path. To create each head database, the daemon’s host acts as an “invisible” secondary for each replica set designated for backup.

The daemon takes scheduled snapshots and stores these snapshots in a snapshot store. The daemon retrieves data from the snapshot store when it receives a restore request. It then delivers the snapshot to the requested destination.

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

If you run multiple Backup Daemons, Ops Manager selects the Backup Daemon to use when a user enables backup for a deployment. The head database resides with the daemon’s host.

Dedicated Storage for Operational Data

Ops Manager Application Database

Ops Manager uses a dedicated MongoDB database to store the Ops Manager’s operational data. The application database runs as a replica set to ensure redundancy and high availability. This replica set hosts only Ops Manager data. Before installing Ops Manager, you must provision the application database. This database contains Ops Manager Application metadata:

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

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

Snapshot Storage

Ops Manager creates snapshots of deployments to back up data. You can have Ops Manager store these snapshots in snapshot stores. Snapshot stores can be local databases, local file systems, or cloud-based data stores. There can be more than one snapshot store per project. Ops Manager writes the recent history of the deployment database to a separate database regardless of where the snapshots are written.

The components of snapshot storage include:

Snapshot Stores

Snapshots can be written to one of three target storage systems:

Oplog Store

This store retains oplog entries the Backup Daemon applies to its local copies of your backed-up deployments. To learn about the requirements and procedures for Oplog Stores, see Manage Oplog Storage.