Docs Menu
Docs Home
/
MongoDB Ops Manager
/

Ops Manager System Requirements

On this page

  • Hardware Requirements
  • Network Requirements
  • Software Requirements

This section 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.

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 the active Backup Daemon(s)

  • 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, back up 200 hosts, and run FCV 4.2 or later. 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 at least 100 GB of available disk capacity.

This example host would require a minimum of 15 GB of RAM and 100 GB of disk capacity.

Warning

Potential for Production Failure

Your Ops Manager instance can fail in production if you fail to configure the following:

Every host that serves the Ops Manager application must meet the following hardware requirements. Note that connecting too many hosts to a single project may cause performance issues.

Number of Monitored Hosts
CPU Cores
Physical Memory [1]
Disk
Up to 400 monitored hosts
4+
15 GB
10 GB for Ops Manager Application in /opt plus storage for logs [2]
Up to 2,000 monitored hosts
8+
15 GB
10 GB for Ops Manager Application in /opt plus storage for logs [2]
More than 2,000 hosts
Contact MongoDB Account Manager
Contact MongoDB Account Manager
Contact MongoDB Account Manager
[1] Physical Memory, in this context, means resident memory displayed as RES in the ps command results on Linux platforms. This applies to virtual machines and containers as well, even though their physical memory is a virtual construct.
[2](1, 2) Storage capacity needed for logs depends on how you Configure Log Rotation. By default, logs rotate every gigabyte and every 24 hours, whichever comes first. Conservative estimates require allocating 30 GB of disk for each month of logs you want to keep. Review your disk allocation and log rotation settings for the optimal disk configuration.

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. Note that connecting too many hosts to a single project may cause performance issues.

Number of Monitored Hosts
RAM
Disk Capacity
CPU Cores
Up to 400
8 GB RAM plus the RAM required for the mongod application
200 GB
4 × 2 GHz+
Up to 2,000
15 GB RAM plus the RAM required for the mongod application
500 GB
4 × 2 GHz+
More than 2,000
Contact your MongoDB Account Manager
Contact your MongoDB Account Manager
Contact your MongoDB Account Manager

For the best performance, use:

Disk capacity estimates are approximate. The needed disk capacity can increase or decrease due to the number of databases being monitored.

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.

Each host that serves an active Backup Daemon has the following hardware requirements:

The Backup Daemon should have at least 100 GB of available disk capacity.

Contact your MongoDB Account Manager to determine disk capacity and throughput 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
Disk Capacity
RAM
4 × 2 GHz+

The minimum disk capacity required for the Ops Manager blockstore uses the following formula:

(2 to 3 times the total size of the dbPath) * 2 (to allow groom jobs)

Contact MongoDB Support to accurately determine your minimum disk capacity.

8 GB of RAM per TB of blockstore disk to provide good snapshot and restore speed. Ops Manager defines 1 TB of blockstore as 1024 4 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.

If you configured Ops Manager to download binaries direct from the Internet, Ops Manager requires access to the following Internet sites over HTTPS using both IPv4 and IPv6 requests to the Internet:

Site
Purpose
downloads.mongodb.com, downloads.mongodb.org
opsmanager.mongodb.com
To download the MongoDB version manifest.
fastdl.mongodb.org

Connections between the Ops Manager Application host 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.

Many Ops Manager components connect to a running mongod process. These include:

  • the application database,

  • any backup databases, and

  • any MongoDB databases that the MongoDB Agent manages.

The systems that host these components send data traffic to each other to verify an active connection. The TCP keepalive setting determines how often to run this check. Most systems use the default value of 7200 seconds (two hours).

The network connection may drop within that timeframe. Without an existing connection, Ops Manager must create a new connection to that mongod process. This can delay communication or result in network timeouts or socket errors. To prevent this issue, reduce the keepalive value to increase the verification checks. All Ops Manager components must use the same keepalive value.

To learn how to set this to the recommended value, see Does TCP keepalive time affect MongoDB Deployments? in the MongoDB Server Manual.

Each MongoDB and MongoDB Agent host should self-identify as its FQDN to ensure reliable connectivity.

Use the following command to find the host FQDN:

> hostname -f

Your result should look like this:

mongodb.example.com

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:

PS C:\> systeminfo | findstr /B /C:"Host" /C:"Domain"

Your result should look like this:

Host Name: mongodb
Domain: example.com

Combine the Host Name and Domain with a . to get the FQDN. With the previous example, the FQDN is mongoodb.example.com.

The Ops Manager Application must be able to connect to users and MongoDB Agents over HTTP or HTTPS. MongoDB 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.

Diagram showing the connections between Ops Manager's components.
click to enlarge

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.

Ops Manager requires the following minimum network port requirements:

  • Both Ops Manager users and MongoDB 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, MongoDB Agents must be able to connect to all client MongoDB processes (mongod or mongos).

  • 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 hosts.

Service
Default Port
Transport
Direction
Purpose
Uses TLS?

HTTP

8080

TCP

Inbound
Provides a web connection to Ops Manager from users and MongoDB Agents.
No

HTTPS

8443

TCP

Inbound
Provides a secure web connection to Ops Manager from users and MongoDB 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 localhost and is disabled by default.

To enable it, see Enable the Health Check Endpoint. When enabled, you can access the endpoint at:

http://127.0.0.1:8090/health

IMPORTANT: This port is only accessible from localhost (or 127.0.0.1). The port number can be changed from 8090 to another value.

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:

{
"mms_db": "OK",
"backup_db": "OK"
}
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 host or to AWS SES.
Optional

Note

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 TLS?
ssh
22

TCP

Inbound
Linux System administration.
Yes
RDP
3389

TCP

Inbound
Windows System administration.
No

Ops Manager can back up MongoDB databases to one or more storage systems:

To back up MongoDB hosts, open the following ports to the preferred backup hosts (blockstore, S3-compatible storage snapshot store and/or file system snapshot store):

Service
Default Port
Transport
Direction
Purpose
Uses TLS?
MongoDB
27017

TCP

Outbound
Back up snapshots of entire database to blockstore or snapshot metadata to S3-compatible storage blockstore metadata database.
Optional

HTTPS

443

TCP

Outbound
Back up database snapshot data to S3-compatible storage 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
Proxy Server
25999

TCP

Outbound
Query the snapshot backup host.
No

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 Continuous Backup, then the Restore History tab, then click the download link next to the snapshot.

Note

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 TLS?
MongoDB
27700-27719

TCP

Inbound
Enable communication between the app host and a queryable backup snapshot.
Optional

MongoDB Enterprise users can authenticate Ops Manager users using LDAP. To authenticate using LDAP, open the following ports on Ops Manager and your LDAP host.

Service
Default Port
Transport
Direction
Purpose
Uses TLS?

LDAP

389

UDP

Both
Authenticate and/or authorize Ops Manager users against LDAP host.
No

LDAPS

636

UDP

Both
Authenticate and/or authorize Ops Manager users against LDAP host.
Yes

To configure the Ops Manager LDAP URI strings, including configuring a non-standard port, see User Authentication.

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 host(s).

Service
Default Port
Transport
Direction
Purpose
Uses TLS?
Kerberos
88
TCP / UDP
Outbound
Request authentication for MongoDB users against Kerberos host.
No
Kerberos
88

UDP

Inbound
Receive authentication for MongoDB users against Kerberos host.
No

LDAP

389

UDP

Both
Authenticate and/or authorize MongoDB users against LDAP host.
No

LDAPS

636

UDP

Both
Authenticate and/or authorize MongoDB users against LDAP host.
Yes

To configure Kerberos for authentication to the Ops Manager application database, see Configure Ops Manager to Authenticate with Application Databases.

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 TLS?

KMIP

5696

TCP

Outbound
Send messages between MongoDB databases and KMIP host.
Yes

Note

If you change the port for the KMIP host, see Encrypted Backup Snapshots to configure Ops Manager to use that new port.

If Ops Manager is not configured for Local Mode, it requires access to the following Internet sites over HTTPS:

Site
Purpose
downloads.mongodb.com, downloads.mongodb.org
opsmanager.mongodb.com
To download the MongoDB version manifest.
fastdl.mongodb.org

Each MongoDB Agent and Ops Manager instance must be able to resolve the hostname for each host hosting a MongoDB instance or MongoDB Agent.

On each host, 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 host helps you know which host you are using when logged into that host. To enable other hosts to know what the other hosts' hostnames are, you need to provide a way for those hosts to resolve hostnames.

There are two ways to configure hostname resolution.

To make the hosts' hostnames resolvable, run a host with a domain name service (DNS). DNS maps IP addresses to hostnames with a given domain (such as example.com). This DNS host should have an entry for each host in the deployment: Ops Manager, MongoDB Agent and MongoDB. Entries for LDAP, Kerberos, and email hosts as well as load balancers would be recommended.

If a DNS setup is not possible, add entries for each host in the hosts file of each system.

Operating System
hosts Location
Linux
/etc/hosts
Mac OS X
/private/etc/hosts
Windows
%SystemRoot%\System32\drivers\etc\hosts

This normally resolves to:

C:\Windows\System32\drivers\etc\hosts

The hosts file is a root-readable plain text and must be edited with root or Administrator permissions. The entry format is written as:

127.0.0.1 localhost
10.15.0.5 opsmgr.example.dev
10.15.10.15 rs1.example.dev
10.15.10.16 rs2.example.dev
10.15.10.17 rs3.example.dev

Hosts that run Ops Manager components must meet the following software requirements:

Important

Ops Manager 5.0 and later requires Bash 4.2 or later.

Hosts that run Ops Manager must run on a 64-bit version of one of the following operating systems:

Operating System
Ops Manager 6.0
Ops Manager 7.0
Ops Manager 8.0
Amazon Linux
2
2, 2023
2023
Debian
10, 11
11, 12
12
RHEL 1
7, 8, 9
7 (deprecated), 8, 9
8, 9
SUSE Linux Enterprise Server
12, 15
12 (deprecated), 15
15
Ubuntu
18.04, 20.04, 22.04
20.04 (deprecated), 22.04
22.04, 24.04

1 RHEL is different from RHEL Server. Ops Manager supports only RHEL.

Note

Though the MongoDB Agent can be installed on s390x and on PowerPC (ppc64le) architectures, the Ops Manager Application cannot be installed on these platforms. You must install the Ops Manager Application on one of the platforms listed in the previous table.

Though support for Microsoft Windows Server platforms is discontinued in Ops Manager 5.0 and any later versions, you can use one of the 5.0 and later Ops Manager versions from the list of supported platforms in the previous table, or deploy Ops Manager in a container with the Kubernetes Operator.

Hosts that run MongoDB Agents must run on a 64-bit version of one of the following hardware architectures and operating systems. The following table lists the MongoDB Server versions that you can deploy with the MongoDB Agent on the associated platforms:

Architecture
Distro/OS
8.0
7.0
6.0
5.0
4.4
4.2
4.0
3.6
x86_64
RHEL/Oracle Linux 7
RHEL/Rocky/Alma Linux/Oracle Linux 8
RHEL/Rocky/Alma Linux/Oracle Linux 9
Amazon Linux 2
Amazon Linux 2023
SUSE12
SUSE15
Debian 8
Debian 9
Debian 10
Debian 11
Debian 12
Ubuntu 16.x
Ubuntu 18.x
Ubuntu 20.x
Ubuntu 22.x 1
Ubuntu 24.x
Windows
ARM
RHEL 8
RHEL 9
Amazon Linux 2
Amazon Linux 2023
Ubuntu 20.x
Ubuntu 22.x
Ubuntu 24.x
PowerPC/ ppc64le
RHEL 7
RHEL 8
RHEL 9
zSeries/ 390x
RHEL 7
RHEL 8
RHEL 9

1 MongoDB Connector for BI isn't supported on Ubuntu 22.04.

Support for running MongoDB Agent on Windows 2008 or Windows Server 2008R2 ends beginning with Ops Manager 5.0.

MongoDB Agent still supports managing MongoDB deployments that run on Windows 2016, 2019, 2020.

Note

As of Ops Manager Server 4.0.11, Windows architectures require the Visual C++ Redistributable Packages for Visual Studio 2013.

Ops Manager requires the default exec option defined in /etc/fstab on the underlying host machine in order to run the required binaries stored in the volume backing the /var directory.

The Ops Manager package automatically raises the following ulimits:

  • Open files

  • Maximum user processes

  • Virtual memory

RHEL limits 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.

mongodb-mms soft nproc 200000
mongodb-mms hard nproc 500000

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.

For the following Ops Manager release series, you may run its backing databases on any of the following MongoDB versions:

Ops Manager Release
MongoDB 4.4
MongoDB 5.0
MongoDB 6.0
MongoDB 7.0
MongoDB 8.0
Ops Manager 8.0
Deprecated
Supported
Supported
Ops Manager 7.0
Deprecated
Supported
Supported
Ops Manager 6.0
Deprecated
Supported
Supported

Note

A deprecated version still works with the corresponding Ops Manager release, but we will remove the support for this version in the next release. MongoDB Support recommends migrating to a supported version to avoid potential incompatibility issues.

To learn more, see MongoDB Legacy Support Policy and MongoDB Software Lifecycle Schedules for Ops Manager.

Version support covers the full release series from the first to the last release.

To learn more about 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.

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):

Install and verify an Email Server. Ops Manager needs an email server to send alerts and recover user accounts. You may use an SMTP Server or an AWS SES server. To configure your Email Server, see Email Delivery Method Configuration.

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:

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.

To use Ops Manager, you must use one of the following supported browsers with Javascript enabled:

Supported Web Browser
Supported Version(s)
latest stable
latest stable
latest stable
latest stable

Ops Manager displays a warning on non-supported browsers.

Back

Installation Checklist