Originally Written by Pamela Eng

Welcome to our multi-part series on operations best practices. This post -- the second of three -- focuses on how to best run MongoDB in your datacenter. Download the MongoDB Operations Best Practices guide for more detail.

Manage MongoDB with Ops Manager

We recommend you install Ops Manager in your data center if you manage large scale MongoDB deployments. Ops Manager can alleviate the overhead of operating MongoDB deployments by as much as 95%. If you prefer a cloud-hosted service, you can use MongoDB Management Service (MMS), which offers many of the benefits of Ops Manager.

With Ops Manager, tasks that were once manual and time-consuming are now automated and possible with just a click of a button or an API call without taking the database offline.

Rely on Ops Manager to:

• Deploy and upgrade your system. Reliably perform the tasks that you have performed manually in the past - from deploying a new cluster, performing upgrades, creating point-in-time backups and more.
• Scale your MongoDB application. Dynamically resize capacity by adding shards and replica set members with Ops Manager.
• Deliver point-in-time recovery and scheduled backups. Restore to any point in time and configure Ops Manager to continuously maintain backups.
• Monitor and get performance alerts. Track over 100 key database and systems health metrics including operations counters, memory and CPU utilization, replication status, open connections, queues and any node status. Metrics are securely reported to Ops Manager and MMS where they are processed, aggregated, alerted and visualized in a browser so administrators can monitor MongoDB in real-time.

Monitoring system performance is a crucial aspect of your deployment to address. You should establish baselines on data volume, system load, performance and capacity utilization and periodically revisit these baselines as requirements change.

Set up custom alerts for key metrics that are out of range. Alerts can be set up for a range of parameters affecting individual hosts, replica sets, agents and backup.

Administrators can use the Ops Manager or MMS interface directly or invoke the Ops Manager RESTful API to integrate with existing enterprise tools.

For more information on the benefits of Ops Manager, download our datasheet. Ops Manager comes with MongoDB Enterprise Advanced but you can download an evaluation version. Note, however, that installing Ops Manager is a complex process so we strongly suggest you contact us to get help from one of our expert consultants.

Hardware considerations for smooth-running ops

Of course everyone brings different requirements and use cases to their MongoDB deployment. The specific configuration of your hardware depends on your data, queries, your performance SLA, your availability requirements, and the capabilities of the underlying hardware components. There are, however, a few high-level hardware considerations we would recommend:

• Memory. The working set should fit the RAM. As a general rule, the more RAM the better. MongoDB delegates the management of RAM to the operating system and will use as much RAM as possible until it exhausts what is available. The WiredTiger storage engine offers more memory control by letting you configure how much RAM to allocate to the WiredTiger cache.
• Storage. Be sure you have sufficient I/O bandwidth. Performance depends on good storage quality. Solid state drives (SSDs) are often a great choice because seek-time is significantly reduced. SSDs also provide more gradual performance degradation if the working set no longer fits in memory. If using disk arrays, we recommend using RAID-10 as RAID-5 and RAID-6 do not provide sufficient performance. RAID-O offers good write performance but limited read performance and insufficient fault tolerance.
• Compression. The WiredTiger storage engine decreases storage requirements by as much as 80% using compression. In addition, compression enables much higher storage I/O scalability as fewer bits are read from disk.
• CPU. Faster CPUs lead to better performance. With appropriate sizing and resource allocation using virtualization or container technologies, multiple MongoDB processes can run on a single server without contending for resources. For the sake of availability, multiple members of the same replica set should not be co-located on the same physical hardware.
• Process per host. You should run one mongod process per host.

These recommendations just scratch the surface of hardware considerations for performance. You can enlist a MongoDB engineer to provide consulting services and get a tailored set of recommendations for smooth-running ops. The Health Check and Production Readiness consulting services are particularly helpful for hardware selection guidance to optimize performance.

Running MongoDB on Linux

MongoDB is currently available for Mac OS X, Linux, Windows Server 2008 R2 64bit, Windows 7 (32 bit and 64 bit), Windows Vista, and Solaris platforms. Note that only 64-bit versions of operating systems are MongoDB supported.

Linux is one of the most popular systems for MongoDB deployments so we’ll cover off a couple of recommendations for configuring Linux here. But for more information on specific configurations for Linux and other supported operating systems, file systems and related topics, reference the MongoDB Production Notes documentation.

For MongoDB applications in production, you should use version 2.6.36 of the Linux kernel or later. We recommend the Ext4 and XFS file systems since MongoDB typically uses very large files. For the Ext4 file system, you need to use version 2.6.23 of the Linux Kernel or later. For the XFS file system, you need to use version 2.6.25 of the Linux Kernel or later.

In terms of configuring Linux for MongoDB, we recommend:

• Turning off atime for the storage volume with the database files
• Disabling hugepages virtual memory pages
• Disabling NUMA in your BIOS or invoking mongod with NUMA disabled
• Making sure that readahead settings for the block devices that store the database files are relatively small as most access is non-sequential
• Synchronizing time between your hosts, an especially important point for sharded MongoDB clusters

Networking and security

This might be stating the obvious but you should always run MongoDB in a trusted environment with network rules that prevent access from all unknown entities. It’s worth your time to read through the MongoDB Security Tutorials, which offers detailed information on default port numbers for MongoDB, configuring firewalls for MongoDB, VPN and other important security topics.

There are many resources to help you get started. In addition to the Operations Best Practices white paper, there is a plethora of resources on our website that you can plumb: from the webinar archives to conference presentations. You can also take the free, operations and advanced operations online courses on MongoDB University to get in-depth instruction on operating MongoDB.

Next week, we’ll conclude the series with a look at the topics of security, high availability and backing up your MongoDB deployment.

DOWNLOAD OPS BEST PRACTICE