- Install Ops Manager >
- Ops Manager Hardware and Software Requirements
Ops Manager Hardware and Software Requirements¶
This page describes the hardware and software requirements for the servers that run the Ops Manager Components, including the servers that run the backing MongoDB replica sets.
The servers that run the Backup Daemon and the backing replica sets must also meet the configuration requirements in the MongoDB Production Notes in addition to the requirements on this page. The Production Notes include information on ulimits, NUMA, Transparent Huge Pages (THP), and other configuration options.
Warning
Failure to configure servers according to the MongoDB Production Notes can lead to production failure.
This page also includes requirements for the EC2 security group used when installing on AWS servers.
Hardware Requirements¶
Each server must meet the sum of the requirements for all its components.
Ops Manager Monitoring and Automation require servers for the following components:
Ops Manager Application Database replica set members
Note
Usually the Ops Manager Application runs on the same server as one of the replica set members for the Ops Manager Application Database.
If you run Backup, Ops Manager also requires servers for the following:
- Backup Daemon
- Backup Database replica set members
Note
The following requirements are specific to a given component. You must add together the requirements for the components you will install. For example, the requirements for the Ops Manager Application do not cover the Ops Manager Application Database.
Ops Manager Application Hardware¶
The Ops Manager Application requires the hardware listed here.
| Number of Monitored Hosts | CPU Cores | RAM |
|---|---|---|
| Up to 400 monitored hosts | 4+ | 15 GB |
| Up to 2000 monitored hosts | 8+ | 15 GB |
| More than 2000 hosts | Contact MongoDB Account Manager | Contact MongoDB Account Manager |
Ops Manager Application Database Hardware¶
The Ops Manager Application Database holds monitoring and other metadata for the Ops Manager Application.
The database runs as a three-member replica set. If you cannot
allocate space for three data-bearing members, the third member can be an
arbiter, but keep in mind that Ops Manager uses w:2 write concern, which reports a write operation as successful
after acknowledgement from the primary and one secondary. If you use a replica
set with fewer than 3 data-bearing members, and if you lose one of the
data-bearing members, MongoDB blocks write operations, meaning the
Ops Manager Application Database has redundancy but not high availability.
Run the replica set on dedicated servers. You can optionally run one member of the replica set on the same physical server as the Ops Manager Application.
For a test deployment, you can use a MongoDB standalone in place of a replica set.
Each server that hosts a MongoDB process for the Ops Manager Application Database must comply with the Production Notes in the MongoDB manual. The Production Notes include important information on ulimits, NUMA, Transparent Huge Pages (THP), and other configuration options.
Warning
Failure to configure servers according to the MongoDB Production Notes can lead to production failure.
Each server also requires the following:
| Number of Monitored Hosts | RAM | Disk Space |
|---|---|---|
| Up to 400 monitored hosts | 8 GB additional RAM beyond the RAM required for the Ops Manager Application | 200 GB of storage space |
| Up to 2000 monitored hosts | 15 GB additional RAM beyond the RAM required for the Ops Manager Application | 500 GB of storage space |
| More than 2000 hosts | Contact MongoDB account manager | Contact MongoDB account manager |
For the best results use SSD-backed storage.
Ops Manager Backup Daemon Hardware¶
The Backup Daemon server must meet the requirements in the table below and also must meet the configuration requirements in the MongoDB Production Notes. The Production Notes include information on ulimits, NUMA, Transparent Huge Pages (THP), and other options.
Warning
Failure to configure servers according to the MongoDB Production Notes can lead to production failure.
If you wish to install the Backup Daemon on the same physical server as the Ops Manager Application, the server must satisfy these requirements separately from the requirements in Ops Manager Application Hardware.
The server running the Backup Daemon acts like a hidden secondary for every replica set assigned to it, receiving the streamed oplog entries each replica set’s primary. However, the Backup Daemon differs from a hidden secondary in that the replica set is not aware of it.
The server must have the disk space and write capacity to maintain the replica sets plus the space to store an additional copy of the data to support point-in-time restore. Typically, the Backup Daemon must be able to store 2 to 2.5 times the sum of the size on disk of all the backed-up replica sets, as it also needs space locally to build point-in-time restores.
Before installing the Backup Daemon, we recommend contacting your MongoDB Account Manager for assistance in estimating the storage requirements for your Backup Daemon server.
| Number of Hosts | CPU Cores | RAM | Disk Space | Storage IOPS/s |
|---|---|---|---|---|
| Up to 200 hosts | 4+ 2Ghz+ | 15 GB additional RAM | Contact MongoDB Account Manager | Contact MongoDB Account Manager |
Ops Manager Backup Database Hardware¶
Provision Backup Database servers only if you are deploying Ops Manager Backup.
Replica Set for the Backup Database¶
Backup requires a separate, dedicated MongoDB replica set to hold backup data, which include snapshots, oplog data and temporary sync data. This cannot be a replica set used for any purpose other than holding the backup data.
For redundancy, the replica set must have at least two data-bearing members. For high availability, the replica set must have at least three data-bearing members.
Note
Ops Manager uses w:2 write concern,
which reports a write operation as successful after acknowledgement
from the primary and one secondary. If you use a replica set with two
data-bearing members and an arbiter, and you lose one of the
data-bearing members, write operations will be blocked.
For testing only you may use a standalone MongoDB deployment in place of a replica set.
Server Size for the Backup Database¶
Snapshots are compressed and de-duplicated at the block level in the Backup Blockstore Database. Typically, depending on data compressibility and change rate, the replica set must run on servers with enough capacity to store 2 to 3 times the total backed-up production data size.
Contact your MongoDB Account Manager for assistance in estimating the use-case and workload-dependent storage requirements for your Blockstore servers.
Configuration Requirements from the MongoDB Production Notes¶
Each server that hosts a MongoDB process for the Backup Database must comply with the Production Notes in the MongoDB manual. The Production Notes include important information on ulimits, NUMA, Transparent Huge Pages (THP), and other configuration options.
Warning
Failure to configure servers according to the MongoDB Production Notes can lead to production failure.
Other Requirements for the Backup Database¶
For each data-bearing member of the replica set member
| CPU Cores | RAM | Disk Space | Storage IOPS |
|---|---|---|---|
| 4 x 2ghz+ | 8 GB of RAM for every 1 TB disk of Blockstore to provide good snapshot and restore speed. Ops Manager defines 1 TB of Blockstore as 10244 bytes. | Contact your MongoDB Account Manager. | Medium grade HDDs should have enough I/O throughput to handle the load of the Blockstore. |
EC2 Security Groups¶
If you install on AWS servers, you must have at least one EC2 security group configured with the following inbound rules:
- An SSH rule on the
sshport, usually port22, that allows traffic from all IPs. This is to provide administrative access. - A custom TCP rule that allows connection on ports
8080and8081on the server that runs the Ops Manager Application. This lets users connect to Ops Manager. - A custom TCP rule that allows traffic on all MongoDB ports from any member
of the security group. This allows communication between the various Ops Manager
components. MongoDB usually uses ports between
27000and28000.
Software Requirements¶
Operating System¶
The Ops Manager Application and Backup Daemon(s) can run on 64-bit versions of the following operating systems:
CentOS 5 or later
Red Hat Enterprise Linux 5 or later
SUSE 11 or Later
Amazon Linux AMI (latest version only)
Ubuntu 12.04 or later
Windows Server 2008 R2 or later
Warning
Ops Manager supports Monitoring and Backup on Windows but does not support Automation on Windows.
Ulimits¶
The Ops Manager packages automatically raise the open file, max user processes, and
virtual memory ulimits. On Red Hat, be sure to check for a
/etc/security/limits.d/90-nproc.conf file that may override the max user
processes limit. If the /etc/security/limits.d/90-nproc.conf file exists,
remove it before continuing.
See MongoDB ulimit Settings for recommended ulimit settings.
Warning
Always refer to the MongoDB Production Notes to ensure healthy server configurations.
Authentication¶
If you are using LDAP for user authentication to Ops Manager (as described in Configure Users and Groups with LDAP for Ops Manager), you must enable LDAP before setting up Ops Manager.
Important
You cannot enable LDAP once you have opened the Ops Manager user interface and registered the first user. You can enable LDAP only on a completely blank, no-hosts, no-users installation.
MongoDB¶
Changed in version 1.8: The Ops Manager Application Database and Backup Database must run MongoDB version 2.6.0 or later. Ops Manager 1.8 does not support backing databases running earlier versions of MongoDB.
Your backed-up sharded cluster deployments must run at least MongoDB 2.4.3 or later. Your backed-up replica set deployments must run at least MongoDB 2.2 or later.
Web Browsers¶
Ops Manager supports clients using the following browsers:
- Chrome 8 and greater
- Firefox 12 and greater
- IE 9 and greater
- Safari 6 and greater
The Ops Manager Application will display a warning on non-supported browsers.
SMTP¶
Ops Manager requires email for fundamental server functionality such as password reset and alerts.
Many Linux server-oriented distributions include a local SMTP server by default, for example, Postfix, Exim, or Sendmail. You also may configure Ops Manager to send mail via third party providers, including Gmail and Sendgrid.
SNMP¶
If your environment includes SNMP, you can configure an SMNP trap receiver with periodic heartbeat traps to monitor the internal health of Ops Manager. Ops Manager uses SNMP v2c.
For more information, see Configure SNMP Heartbeat Support.