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 Architecture

An Ops Manager installation includes hosts that run the Ops Manager Application and hosts that serve and store 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 MongoDB Agent uses 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 the same 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.

How the Backup Daemon performs depends upon the MongoDB version compatibility of your database. This Feature Compatibility Version ranges from the current version to one version earlier. For example, with MongoDB 4.2, the FCV can be 4.0 or 4.2. Backup functionality changed with FCV 4.2.

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 the MongoDB Agents. Client applications can’t communicate with 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. When the client requests a restore, the daemon retrieves data from the snapshot store. It then delivers the snapshot to the requested target.

The Backup Daemon service provides the following services for FCV 4.2 or later databases:

  • Performs some state updates to the backup job
  • Perform a queryable restore

The daemon does scheduled work based on data coming into the Ops Manager from the MongoDB Agents. Client applications can’t communicate with the daemon. Its state and job queues come from the Ops Manager Application Database. Ops Manager creates snapshots from the database being backed up.

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 the MongoDB 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 your databases. 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.

Snapshot storage include two components:

Snapshot Stores

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

System Storage Method Learn More
blockstore A MongoDB database stored in a local host. Manage Blockstore Snapshot Storage
S3 snapshot store A cloud data store in AWS S3. Manage S3 Snapshot Storage
file system store A local file system in the directory of your choosing. Manage File System Snapshot Storage

Oplog Store

The Oplog Store retains the oplog entries that the Backup Daemon applies to its local copies of your backed-up deployments.

See also

To learn about the requirements and procedures for Oplog Stores, see Manage Oplog Storage.