- Ops Manager Overview >
- Ops Manager Architecture
Ops Manager Architecture¶
An Ops Manager installation includes hosts running Ops Manager and hosts serving and storing 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 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:
- A Blockstore: a MongoDB database stored in a local host. To learn about the requirements and procedures for Blockstores, see Manage Blockstore Snapshot Storage.
- An S3 Snapshot Store: a cloud data store in AWS S3. To learn about the requirements and procedures for S3 Snapshot Stores, see Manage S3 Blockstore Snapshot Storage.
- A File System Store: a local file system in the directory of your choosing. To learn about the requirements and procedures for File System Stores, see Manage File System Snapshot Storage.
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.