- Install Ops Manager >
- Ops Manager System Requirements
Ops Manager System Requirements¶
On this page
- Hardware Requirements
- Network Requirements
- MongoDB and Ops Manager Agent Host Access
- Open Ports to Access Ops Manager
- Open Ports to Access Ops Manager and MongoDB Hosts
- Open Ports to Back Up, Restore, and Query MongoDB Instances using Ops Manager
- Open Ports to Integrate Ops Manager with SNMP
- Open Ports to Provide Additional Monitoring for Ops Manager
- Open Ports to Authenticate Ops Manager Users using LDAP
- Open Ports to Authenticate with MongoDB
- Open Ports to Manage Encryption Keys using KMIP
- Internet Site Access
- Software Requirements
This guide describes the hardware, software, and networking requirements for the hosts that run the Ops Manager components.
Important
Before deploying hosts, use the Installation Checklist to plan your configuration.
For requirements for the MongoDB instances running as the Ops Manager Application Database and the Backup Database, see Install the Ops Manager Application Database and Backup Database.
Hardware Requirements¶
Note
When using the term hardware on this page, it should be understood as the specifications per host using one of the following architectures:
- physical hardware,
- hardware components allocated to a virtual host,
- hardware components allocated to a virtual container, or
- hardware components allocated to a Kubernetes Worker Node.
Each host must meet the total RAM and disk capacity requirements for all Ops Manager components that it serves:
- Ops Manager application
- Ops Manager application databases
- Head databases for active Backup Daemon
- Backup Blockstore databases
Example
You want to serve both the Ops Manager application and a Backup Daemon on one host. This Ops Manager configuration will manage and monitor 300 MongoDB hosts and back up 200 hosts. The total disk capacity of all databases being backed up is 4 TB. The total requirements would be:
- Ops Manager application needs 15 GB of RAM.
- The Backup Daemon also needs:
- 15 GB of RAM and
- 2.5 times the 4 TB of backed up databases in disk capacity.
This example host would require a minimum of 30 GB of RAM and 10 TB of disk capacity.
Warning
Each host that serves a MongoDB instance must comply with the Production Notes in the MongoDB manual. MongoDB instances in Ops Manager include:
- The Ops Manager Application Database,
- Each Ops Manager Backup Daemon head database, and
- Each blockstore.
Failure to configure hosts according to the production notes can lead to production failure.
Ops Manager Hardware Requirements¶
Every host that serves the Ops Manager application must meet the following hardware requirements:
Number of Monitored Hosts | CPU Cores | Physical Memory [*] |
---|---|---|
Up to 400 monitored hosts | 4+ | 15 GB |
Up to 2,000 monitored hosts | 8+ | 15 GB |
More than 2,000 hosts | Contact MongoDB Account Manager | Contact MongoDB Account Manager |
[*] | Physical Memory, in this context, means resident memory
displayed as RES in the ps command results on Linux and
macOS platforms and Memory displayed in the
Task Manager on Windows platforms. This applies to
virtual machines and containers as well, even though their
physical memory is a virtual construct. |
Ops Manager Application Database Hardware Requirements¶
The Ops Manager Application Database runs as a three-member replica set that runs on dedicated hosts.
Every host that serves the Ops Manager Application Database must meet the following hardware (physical or virtual) requirements:
Number of Monitored Hosts | RAM | Disk Capacity |
---|---|---|
Up to 400 | 8 GB RAM plus the RAM required for Ops Manager application | 200 GB |
Up to 2,000 | 15 GB RAM plus the RAM required for Ops Manager application | 500 GB |
More than 2,000 | Contact your MongoDB Account Manager | Contact your MongoDB Account Manager |
For the best performance, use SSDs to store your Ops Manager Application Databases.
For the differences between WiredTiger and MMAPv1 storage engines, see the types of storage engines in the MongoDB manual.
Disk capacity estimates are approximate. The needed disk capacity can increase or decrease due to the number of databases being monitored.
Backup Daemon Hardware Requirements¶
Important
Before getting started with Backup, contact your MongoDB Account Manager to help estimate the storage requirements for your Backup Daemon host.
Each host on which you activate the Backup Daemon must meet the following requirements plus those for Ops Manager.
The Backup Daemon creates head databases that replicate data for each replica set assigned to the Daemon. Typically, each host on which you activate the Backup Daemon needs to store 2.0 to 2.5 times the sum of the size on disk of all the backed-up replica sets.
Specifically, each host must have:
- The disk capacity and write capacity to maintain each head database, plus
- The disk capacity to store an additional copy of the data for each head database to support point-in-time restores.
Each host that serves an active Backup Daemon has the following hardware requirements:
Number of hosts | CPU Cores | RAM |
---|---|---|
Up to 200 | 4+ × 2 GHz+ | 15 GB additional RAM |
Contact your MongoDB Account Manager to determine disk capacity and throughput requirements.
Backup Database Hardware Requirements¶
If you use Ops Manager Backup, you must provision hosts for the Backup Database.
Host requirements for the Backup Database vary, depending on whether you use a Blockstore database or file system storage to store your snapshots. The Backup Database always holds oplog data.
If you store snapshots in the Backup Database, its hosts typically must have enough capacity to store 2 to 3 times the total backed-up production data size. Snapshots are compressed and de-duplicated at the block level in the Blockstore.
Your specific requirements depend on your data compressibility and change rate. Contact your MongoDB Account Manager to help estimate the use case and workload-dependent storage requirements for your Backup Database hosts.
If you store snapshots in the Backup Database, each data-bearing member must meet the following requirements:
CPU Cores | RAM |
---|---|
4 × 2 GHz+ | 8 GB of RAM per TB of Blockstore disk to provide good snapshot and restore speed. Ops Manager defines 1 TB of Blockstore as 10244 bytes. |
Contact your MongoDB Account Manager to determine disk capacity and throughput requirements.
If you will not store snapshots in the Backup Database, each data-bearing member must meet the following requirements:
CPU Cores | Disk Capacity |
---|---|
4 × 2 GHz+ | The size of your oplogs compressed for the configured point in time window. The default is 24 hours. |
Network Requirements¶
Internet Site Access¶
If Ops Manager is not configured for Local Mode, it requires access to the following Internet sites over HTTPS:
Site | Purpose |
---|---|
downloads.mongodb.com | To download MongoDB Enterprise Builds. |
opsmanager.mongodb.com | To download the MongoDB version manifest. |
fastdl.mongodb.org | To download MongoDB Community Builds. |
Latency between Ops Manager and Backing Database Hosts¶
Connections between the Ops Manager Application Server and its Application Database, Oplog, and Blockstore replica sets must have the lowest possible network latency. With deployments exceeding 200 MongoDB hosts, latency between your Ops Manager Application components should be under 1 ms. Please contact MongoDB Support if you anticipate that your network environment cannot meet this requirement.
MongoDB and Ops Manager Agent Host Access¶
Each MongoDB and Ops Manager agent host should self-identify as its FQDN to ensure reliable connectivity.
- Linux or macOS
- Windows
Use the following command to find the host FQDN:
Your result should look like this:
Windows hosts host must be connected to the internet and attached to a Active Directory domain.
Use the following command to find the host FQDN:
Your result should look like this:
Combine the Host Name
and Domain
with a .
to get
the FQDN. With the previous example, the FQDN is
mongoodb.example.com
.
Accessible Ports¶
The Ops Manager application must be able to connect to users and Ops Manager agents over HTTP or HTTPS. Ops Manager agents must be able to connect to MongoDB client MongoDB databases.
Though Ops Manager only requires open HTTP (or HTTPS) and MongoDB network ports to connect with users and to databases, what ports are opened on a firewall depend upon what capabilities are enabled: encryption, authentication and monitoring.
This page defines which systems need to connect to which ports on other systems.
Ops Manager connects with a number of services. This page explains the ports that must be opened to deploy the various components used with an Ops Manager deployment.
The specific ports that must be open on any intermediate firewalls depend upon what capabilities are enabled, such as encryption, authentication, and monitoring.
Tip
All ports listed in the following sections are either the port specified in the documentation for MongoDB installations or the known ports for the specific service assigned by the IANA. If the port number can be changed, it is noted after the table in each section.
To run Ops Manager without an Internet connection, see Configure Deployment to Have Limited Internet Access to ensure you have all of the necessary binaries to run Ops Manager without an Internet connection.
Open Ports to Access Ops Manager¶
Ops Manager requires the following minimum network port requirements:
- Both Ops Manager users and Ops Manager agents must be able to connect to the Ops Manager application over HTTP or HTTPS.
- Ops Manager must be able to connect to the mongod running the Ops Manager application MongoDB databases.
- For each Ops Manager project, Ops Manager agents must be able to connect
to all client MongoDB processes (
mongod
ormongos
). - The Ops Manager application must also be able to send email to Ops Manager users.
To use Ops Manager, open the following ports to the specified servers.
Service | Default Port | Transport | Direction | Purpose | Uses SSL? |
---|---|---|---|---|---|
HTTP | 8080 | TCP | Inbound | Provides a web connection to Ops Manager from users and Ops Manager agents. | No |
HTTPS | 8443 | TCP | Inbound | Provides a secure web connection to Ops Manager from users and Ops Manager agents. | Yes |
HTTP or HTTPS | 8090 | TCP | Inbound | Provides a health-check endpoint for monitoring Ops Manager
through a monitoring service like Zabbix or Nagios. It is
only available through To enable it, see Enable the Health Check Endpoint. When enabled, you can access the endpoint at: Important This port is only accessible from The API endpoint provides the ability to check connections from the HTTP Service to the Ops Manager Application Database and the Backup Snapshot Storage. A successful response returns the following: |
Optional |
MongoDB | 27017 | TCP | Outbound | Connects to MongoDB application, backup and client databases. | Optional |
SMTP | 587 | TCP | Outbound | Sends emails from Ops Manager to an SMTP server or to AWS SES. | Optional |
Note
- To set a non-default port for Ops Manager, see Manage Ops Manager Ports.
- To configure a different port for the application database, see
mongo.mongoUri
. - To configure a different port for a client database, see Deploy a Standalone MongoDB Instance, Deploy a Replica Set, or Deploy a Sharded Cluster for a new deployment or Add Existing MongoDB Processes to Ops Manager for an existing deployment.
Open Ports to Access Ops Manager and MongoDB Hosts¶
Most Ops Manager administration can be performed through the user interface. Some procedures require access to the operating system. To permit your administrators to access your Ops Manager as well as MongoDB hosts, open the following ports to those hosts.
Service | Default Port | Transport | Direction | Purpose | Uses SSL? |
---|---|---|---|---|---|
ssh | 22 | TCP | Inbound | Linux System administration. | Yes |
RDP | 3389 | TCP | Inbound | Windows System administration. | No |
Open Ports to Back Up, Restore, and Query MongoDB Instances using Ops Manager¶
Ops Manager can back up MongoDB databases to one or more storage systems: a MongoDB database (blockstore), an S3 bucket (S3 blockstore) or a file system (file system store). To back up MongoDB servers, open the following ports to the preferred backup hosts (blockstore, S3 snapshot store and/or file system snapshot store):
Service | Default Port | Transport | Direction | Purpose | Uses SSL? |
---|---|---|---|---|---|
MongoDB | 27017 | TCP | Outbound | Back up snapshots of entire database to Blockstore or snapshot metadata to S3 Blockstore metadata database. | Optional |
HTTPS | 443 | TCP | Outbound | Back up database snapshot data to S3 bucket. | Yes |
NFS | 2049 | TCP | Outbound | Back up database snapshots to UNIX-/Linux-based file system. | No |
CIFS | 3020 | TCP | Outbound | Back up database snapshots to Windows-based file system. | No |
scp | 22 | TCP | Outbound | Restore snapshot to a server. | Yes |
Snapshots can also be restored using the link displayed in the Ops Manager application. The same ports needed to use Ops Manager would need to be open for the user to download the snapshot.
To find the download link, click Backup, then the Restore History tab, then click the download link next to the snapshot.
Note
- To configure a different port for the Blockstore, see Manage Blockstore Snapshot Storage.
- To configure a different port for the S3 Snapshot Store metadata database, see Manage S3 Blockstore Snapshot Storage.
MongoDB 3.4.2 Enterprise and later provides the ability to query backup snapshots. Ops Manager provisions these queryable snapshots as read-only MongoDB instances, as described in Query a Backup. To query a backup snapshot, open the following ports:
Service | Default Port | Transport | Direction | Purpose | Uses SSL? |
---|---|---|---|---|---|
MongoDB | 27700-27719 | TCP | Inbound | Enable communication between the app server and a queryable backup snapshot. | Optional |
Open Ports to Integrate Ops Manager with SNMP¶
Open the following ports between Ops Manager and your SNMP Manager to send and receive SNMP trap notifications from your MongoDB deployments to Ops Manager.
Service | Default Port | Transport | Direction | Purpose | Uses SSL? |
---|---|---|---|---|---|
SNMP | 162 | UDP | Outbound | Send Traps to SNMP Manager. | No |
SNMP | 11611 | UDP | Inbound | Receive requests from SNMP Manager. | No |
Ops Manager uses SNMP v2c. You can configure the Ops Manager Application to send a periodic heartbeat trap notification (v2c) that contains an internal health assessment of the Ops Manager Application. The Ops Manager Application can send traps to one or more endpoints on the standard SNMP UDP port 162.
To configure the Ops Manager Application to send trap notifications, first download the Management Information Base (MIB) file at http://downloads.mongodb.com/on-prem-monitoring/MMS-MONGODB-MIB.txt . Then add the following settings as custom settings. To do so, click the Admin link, then the General tab, then the Ops Manager Config page, and then the Custom section.
Open Ports to Provide Additional Monitoring for Ops Manager¶
Important
As of Automation Agent 2.7.0, using Munin to monitor hardware has been deprecated in favor of the native cross-platform hardware monitoring available to managed deployments through the Automation Agent.
Beyond Ops Manager’s built-in monitoring capability, it can use the Munin Graphing Framework to provide additional monitoring on UNIX/Linux-based MongoDB instances and hosts.
Service | Default Port | Transport | Direction | Purpose | Uses SSL? |
---|---|---|---|---|---|
munin-node | 4949 | TCP | Inbound | Provides CPU and disk throughput and latency metrics. | No |
To configure the munin-node
package, see
Configure Hardware Monitoring with munin-node.
Open Ports to Authenticate Ops Manager Users using LDAP¶
MongoDB Enterprise users can authenticate Ops Manager users using LDAP. To authenticate using LDAP, open the following ports on Ops Manager and your LDAP server.
Service | Default Port | Transport | Direction | Purpose | Uses SSL? |
---|---|---|---|---|---|
LDAP | 389 | UDP | Both | Authenticate and/or authorize Ops Manager users against LDAP server. | No |
LDAPS | 636 | UDP | Both | Authenticate and/or authorize Ops Manager users against LDAP server. | Yes |
To configure the Ops Manager LDAP URI strings, including configuring a non-standard port, see User Authentication.
Open Ports to Authenticate with MongoDB¶
MongoDB Enterprise users can use Kerberos or LDAP to authenticate MongoDB users. To authenticate using LDAP or Kerberos, open the following ports between the MongoDB client databases, Ops Manager, and the Kerberos or LDAP server(s).
Service | Default Port | Transport | Direction | Purpose | Uses SSL? |
---|---|---|---|---|---|
Kerberos | 88 | TCP / UDP | Outbound | Request authentication for MongoDB users against Kerberos server. | No |
Kerberos | 88 | UDP | Inbound | Receive authentication for MongoDB users against Kerberos server. | No |
LDAP | 389 | UDP | Both | Authenticate and/or authorize MongoDB users against LDAP server. | No |
LDAPS | 636 | UDP | Both | Authenticate and/or authorize MongoDB users against LDAP server. | Yes |
To configure Kerberos for authentication to the Ops Manager application database, see Configure Ops Manager to Connect to Backing Databases with Access Control.
Open Ports to Manage Encryption Keys using KMIP¶
MongoDB Enterprise deployments using the WiredTiger storage engine supports a native encryption option. You can use a KMIP service to manage the master encryption key. To support the encrypted storage engine via KMIP, open the following ports between the Backup Daemon hosts, the MongoDB hosts, and the KMIP hosts.
Service | Default Ports | Transport | Direction | Purpose | Uses SSL? |
---|---|---|---|---|---|
KMIP | 5696 | TCP | Outbound | Send messages between MongoDB databases and KMIP host. | Yes |
Note
If you change the port for the KMIP server, see Encrypted Backup Snapshots to configure Ops Manager to use that new port.
Internet Site Access¶
If Ops Manager is not configured for Local Mode, it requires access to the following Internet sites over HTTPS:
Site | Purpose |
---|---|
downloads.mongodb.com | To download MongoDB Enterprise Builds. |
opsmanager.mongodb.com | To download the MongoDB version manifest. |
fastdl.mongodb.org | To download MongoDB Community Builds. |
Use resolvable hostnames¶
Each Agent and Ops Manager instance must be able to resolve the hostname for each server hosting a MongoDB instance or Ops Manager agent.
On each server, set their hostnames to fully qualified domain names (FQDN) whenever possible. Consult the documentation for your operating system as to how to find and set the hostname as an FQDN.
Setting the FQDN on each server helps you know which server you are using when logged into that server. To enable other servers to know what the other servers’ hostnames are, you need to provide a way for those servers to resolve hostnames.
There are two ways to configure hostname resolution.
Use a Domain Name Service¶
To make the servers’ hostnames resolvable, run a server
with a domain name service (DNS). DNS maps IP addresses to
hostnames with a given domain (such as example.com
). This DNS
server should have an entry for each server in the deployment: Ops Manager,
Ops Manager agent and MongoDB. Entries for LDAP, Kerberos, SNMP and email
servers as well as load balancers would be recommended.
Edit Host Files¶
If a DNS setup is not possible, add entries for each server in the
hosts
file of each system.
Operating System | hosts Location |
---|---|
Linux | |
Mac OS X | |
Windows | This normally resolves to: |
The hosts
file is a root-readable plain text and must be edited
with root
or Administrator
permissions. The entry format is
written as:
Software Requirements¶
Hosts that run Ops Manager components must meet the following software requirements:
Operating System Compatibility Matricies¶
Ops Manager Host Operating System Compatibility Matrix¶
Hosts that run Ops Manager must run on a 64-bit version of one of the following operating systems on the provided hardware platforms:
Operating System | Versions Supported on x86_64 | Versions Supported on ppc64le |
---|---|---|
Red Hat Enterprise Linux / CentOS | 6.x, 7.x | 7.x |
SUSE Linux Enterprise Server | 12 | |
Debian | 8, 9 | |
Amazon Linux | 1, 2 | |
Ubuntu | 14.04, 16.04, 18.04 | 16.04 |
Microsoft Server | 2008R2, 2012, 2012R2, and 2016 |
In a future release, MongoDB will end support for Microsoft Windows Server 2008R2.
Note
Though the Ops Manager agents can be installed on s390x
architectures, the Ops Manager Application cannot be installed on that
platform. You must install the Ops Manager Application on one of the platforms
listed in the previous table.
Ops Manager Agent Host Operating System Compatibility Matrix¶
Hosts that run Ops Manager Agents must run on a 64-bit version of one of the following operating systems on the provided hardware platforms:
Operating System | Versions Supported on x86_64 | Versions Supported on ppc64le | Versions Supported on s390x |
---|---|---|---|
Amazon Linux | 1, 2 | ||
CentOS | 6.x, 7.x | 7.x | |
Debian | 8, 9 | ||
Red Hat Enterprise Linux | 6.x, 7.x | 7.x | 6.x |
SUSE Linux Enterprise Server | 12 | ||
Ubuntu | 14.x, 16.x, 18.x | 16.x | |
Windows | 2008R2, 2012, 2012R2, and 2016 |
Note
As of Ops Manager Server 4.0.11, Windows architectures require the Visual C++ Redistributable Packages for Visual Studio 2013.
Ulimits Requirements for Ops Manager Application
The Ops Manager package automatically raises the following ulimits
:
- Open files
- Maximum user processes
- Virtual memory
RHEL and CentOS 6 limit the maximum
number of user processes to 1024
. This overrides the general
user process limit (ulimit -u
) setting.
For the userid that runs Ops Manager (mongodb-mms
by default),
add soft
and hard
nproc
(number of processes) entries to the /etc/security/limits.d/99-mongodb-nproc.conf
user process
configuration file. Use values that are larger than the RHEL 1024
user process limit.
If /etc/security/limits.d/99-mongodb-nproc.conf
does not exist, create it. Use the contents of the
/etc/security/limits.d/90-nproc.conf
file as a template.
MongoDB Version for Ops Manager Application Database and Backup Database¶
For the following Ops Manager release series, you may run its backing databases on any of the following MongoDB versions.
Ops Manager Release Series | Minimum MongoDB 2.6 version | Minimum MongoDB 3.0 version | Minimum MongoDB 3.2 version | Minimum MongoDB 3.4 version | Minimum MongoDB 3.6 version | Minimum MongoDB 4.0 version |
---|---|---|---|---|---|---|
2.0 | 2.6.6 | 3.0.6 | 3.2.0 | |||
3.4 | 3.0.8 | 3.2.0 | 3.4.0 | |||
3.6 | 3.2.0 | 3.4.0 | 3.6.0 | |||
4.0 | 3.4.0 | 3.6.0 | 4.0 |
For more information on MongoDB versioning, see MongoDB Versioning in the MongoDB Manual.
Important
Only the MongoDB Ops Manager backing databases must meet this requirement. The MongoDB deployments that Ops Manager manages do not. For the minimum versions required for managed MongoDB deployments, see MongoDB Compatibility Matrix.
Ulimits Requirements for Backup Daemon and Backing Databases
Refer to the following pages in the MongoDB manual for ulimit
requirements for the hosts that run MongoDB (Backup Daemon and
Ops Manager Backing Databases hosts):
SMTP¶
Ops Manager requires email for fundamental host functionality such as password reset and alerts. Many Linux host-oriented distributions include a local SMTP server by default. These include, but are not limited to:
Windows Server includes an SMTP relay with Internet Information Server.
You also may configure Ops Manager to send mail via third party providers. These include, but are not limited to:
SNMP¶
If your environment includes SNMP, you can configure an SNMP trap receiver with periodic heartbeat traps to monitor the internal health of Ops Manager. Ops Manager uses SNMP v2c. To learn more, see Configure SNMP Heartbeat Support.
Install fontconfig on Linux Hosts¶
When installing Ops Manager version 4.0.13 or later on Linux hosts, install the fontconfig package to enable data export from the Status tab to PDF or PNG format.
Client Web Browsers¶
To use Ops Manager, you must use one of the following supported browsers with Javascript enabled:
Supported Web Browser | Supported Version(s) |
---|---|
Google Chrome | latest stable |
Mozilla Firefox | latest stable |
Microsoft Edge | latest stable |
Apple Safari | latest stable |
Ops Manager displays a warning on non-supported browsers.