Navigation
This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Ops Manager, refer to the upgrade documentation.
You were redirected from a different version of the documentation. Click here to go back.

Ops Manager System Requirements

This guide describes the hardware, software, and networking requirements for the servers that run the Ops Manager components.

Important

Before deploying servers, 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

Each server must meet the total RAM and disk capacity requirements for all Ops Manager components that it hosts:

  • Ops Manager application
  • Ops Manager application databases
  • Head databases for active Backup Daemon
  • Backup Blockstore databases

Example

You want to host both the Ops Manager application and a Backup Daemon on one server. 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 server would require a minimum of 30 GB of RAM and 10 TB of disk capacity.

Warning

Each server that hosts 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 servers according to the production notes can lead to production failure.

Ops Manager Hardware Requirements

Every server that runs the Ops Manager application must meet the following hardware requirements:

Number of Monitored Hosts CPU Cores RAM
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 Executive Contact MongoDB Account Executive

Ops Manager Application Database Hardware Requirements

The Ops Manager Application Database runs as a three-member replica set that runs on dedicated servers.

Every server that hosts the Ops Manager Application Database must meet the following hardware 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 Executive Contact your MongoDB Account Executive

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.

Important

During the upgrade to Ops Manager 3.4, your Ops Manager application database could increase to twice its current size. Make sure you have sufficient free disk capacity on the disk partitions that store your application database so the upgrade can complete.

EXAMPLE:

If your application database is 50 GB as a replica set, you need to have at least another 50 GB on each server hosting a replica set before upgrading to Ops Manager 3.4.

Backup Daemon Hardware Requirements

Important

Before getting started with Backup, contact your MongoDB Account Executive to help estimate the storage requirements for your Backup Daemon server.

Each server on which you activate the Backup Daemon must meet the following requirements plus the requirements for Ops Manager.

The Backup Daemon creates head databases that replicate data for each replica set assigned to the Daemon. Typically, each server 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 server 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 server that hosts 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 Executive to determine disk capacity and throughput requirements.

Backup Database Hardware Requirements

If you use Ops Manager Backup, you must provision servers for the Backup Database.

Server 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 servers 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 servers.

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 Executive 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.

Accessible Ports

The Ops Manager application must be able to connect to users and Ops Manager agents over or Secure HTTP (HTTPS). Ops Manager agents must be able to connect to MongoDB client MongoDB databases.

Though Ops Manager only requires open HTTP(S) 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.

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 Local Mode for Ops Manager Servers without 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 group, Ops Manager 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 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 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 server or to AWS SES. Optional

Note

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 and Restore 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

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

Note

To configure Ops Manager to use SNMP on non-standard ports, see SNMP Heartbeat Settings.

Open Ports to Provide Additional Monitoring for Ops Manager

Important

As of Ops Manager 3.4, 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 use Lightweight Directory Access Protocol (LDAP) to authenticate Ops Manager users. 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 Authentication through LDAP.

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 Kerberos Authentication to the Application Database.

Open Ports to Manage Encryption Keys using KMIP

MongoDB databases using the WiredTiger storage engine can be encrypted on disk. The encryption method requires another server to manage the encryption keys. To manage encryption keys using Key Management Interoperability Protocol (KMIP), open the following port between the hosts running the Backup Daemons and the KMIP server(s).

Service Default Port Transport Direction Purpose Uses SSL?
KMIP 5696 TCP Outbound Send messages between MongoDB databases and KMIP server. No

Note

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

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.

Locations of hosts files
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

Software Requirements

Servers that run Ops Manager components must meet the software requirements described here.

Ops Manager Operating System

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

  • CentOS 6 or later
  • Red Hat Enterprise Linux 6 or later
  • SUSE 11 or Later
  • Amazon Linux AMI (latest version only)
  • Ubuntu 12.04 or later
  • Microsoft Windows Server 2008 R2 or later

MongoDB Version for Ops Manager Application Database and Backup Database

You may run backing databases on any of the following MongoDB versions.

Ops Manager Compatible MongoDB Versions
2.0.X
  • 2.6.6 or later
  • 3.0.6 or later
  • 3.2.0 or later
  • 3.4.0 or later
3.4.X
  • 3.0.8 or later
  • 3.2.0 or later
  • 3.4.0 or later

For more information on MongoDB version numbers, 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 ulimit requirements for the servers that run MongoDB (i.e., the Backup Daemon servers and the servers that host the Ops Manager Application Database or the Backup Database), see all of the following:

The Ops Manager package automatically raises the following ulimits:

  • open files
  • max 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.

If a /etc/security/limits.d/99-mongodb-nproc.conf user process configuration file does not exist, create it. In this file, add soft and hard nproc (number of processes) entries with values that are larger than the RHEL 1024 user process limit. Use the contents of the /etc/security/limits.d/90-nproc.conf file as a template.

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.

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 Foundation Firefox latest stable
Microsoft Internet Explorer 10 and later
Microsoft Edge latest stable
Apple Safari latest stable

Ops Manager displays a warning on non-supported browsers.