- Ops Manager Introduction >
- Ops Manager Components
Ops Manager Components¶
On this page
An Ops Manager installation consists of the Ops Manager Application and optional Backup Daemon. Each package also requires a dedicated MongoDB database to hold operational data.
Network Diagram¶
Ops Manager Application¶
The front-end Ops Manager Application contains the UI the end user interacts with, as well as HTTPS services used by the Monitoring Agent and Backup Agent to transmit data to and from Ops Manager. The components are 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.
For Monitoring, you need to install only the application package. The application package consists of the following components:
Ops Manager HTTP Service¶
The HTTP server runs on port 8080 by default. This component
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 HTTP Service¶
The HTTP server runs on port 8081 by default. The Backup HTTP Service
contains a set of web services used by the Backup Agent. The agent
retrieves its configuration from this service. The agent also sends
back initial sync and oplog data through this interface. There is no
user interaction with this service. The Backup HTTP Service runs on
port 8081 by default.
The Backup HTTP Service exposes an endpoint that reports on the state of the service and the underlying database to support monitoring of the Backup service. This status also checks the connections from the service to the Ops Manager Application Database and the Backup Database. See Backup HTTP Service Endpoint.
Backup Daemon¶
The Backup Daemon manages both the local copies of the backed-up databases and each backup’s snapshots. The daemon does scheduled work based on data coming in to the Backup 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 will take scheduled snapshots and store the snapshots in the Backup Database. It will also act on restore requests by retrieving data from the Backup Database and delivering it to the requested destination.
Multiple Backup Daemons can increase your storage by scaling horizontally and can provide manual failover.
The Backup Daemon exposes a health-check endpoint. See Backup Daemon Endpoint.
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 snapshots. To ensure redundancy and high availability, the backing databases run as replica sets. The replica sets host only Ops Manager data. You must set up the backing replica sets before installing Ops Manager.
Ops Manager Application Database¶
This database contains application metadata used by the Ops Manager Application. The database stores:
- 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.
Backup Database¶
The Backup Database stores snapshots of your backed up deployments and stores temporary backup data. The Backup Database is actually three databases. You can have multiple instances of each, according to your sizing needs:
- The Backup Blockstore Database, which stores the snapshots of your backed-up deployments and requires the bulk of the space on the Backup Database servers.
- The Oplog Store Database, which stores oplog entries the Backup Daemon will apply to its local copies of your backed-up deployments.
- The Sync Store Database, which stores temporary backup information when you start a new backup. The Backup Daemon creates its local backup by performing an initial sync using this data.
The databases must run on a dedicated MongoDB deployment that holds no other data. For production, configure the MongoDB deployment as a replica set to provide redundancy for the data. To provide high availability through automatic failover, configure the replica set with three data-bearing members.
You cannot back up the Blockstore Database with Ops Manager Backup. To back up Ops Manager Backup, see Back Up Ops Manager.
The Backup Database requires disk space proportional to the backed-up deployments. For specifications, see Ops Manager Backup Database Hardware.