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.
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.
To learn how to start, check the status of, stop, and restart the Backup daemon on a server, see Start and Stop the Backup Daemon.
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 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.
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.
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 |
|---|---|---|
A MongoDB database stored in a local host. | ||
A cloud data store in S3-compatible storage. | ||
A local file system in the directory of your choosing. |
Oplog Store
The Oplog Store retains the oplog entries that the Backup Daemon applies to its local copies of your backed-up deployments.
Tip
See also:
To learn about the requirements and procedures for Oplog Stores, see Manage Oplog Storage.