A Comparison Between ClusterControl and MongoDB OPS Manager

There are various ways to provision MongoDB servers, e.g., manual installation by command line, configuration management tools (eg. ansible, saltstack), or specialized MongoDB deployment tools such as ClusterControl and MongoDB Ops Manager. 

Manual installation will usually take time to set up, as we need to type in commands manually, starting from installing dependencies, downloading the database software, installing the database software and configuring/tuning the database servers. Following the steps outlined in a how-to is not hard, the harder thing is to ensure the deployment is done the right way if it is a production system – is the configuration adapted for the hardware and workload, are the servers secured, do we understand the tradeoffs between performance and reliability when setting certain configuration parameters. 

Using configuration management software can take even longer, there is a learning curve for the automation software itself before we can use it to automate deployments in a production environment. Of course, there will be trial and error in between the testing.

Using a specialized deployment tool for MongoDB helps companies with minimum resources and knowledge of MongoDB itself to provision the database easily and efficiently. In this blog, we will compare MongoDB Ops Manager to ClusterControl from Severalnines. 

Deployment

MongoDB has various architectures, such as MongoDB Standalone, Replication, ReplicaSets, and Sharded Clusters. Those architectures require different number of servers and components. For example, a ReplicaSet will consist of at least 3 nodes, and there are also various types of Secondary nodes e.g., delayed secondary, hidden secondary.

ClusterControl supports the 3 main topologies of MongoDB, starting from a standalone node, MongoDB ReplicaSet, and Sharded Cluster. It supports MongoDB deployment from two upstream sources, which are Percona and MongoDB. The database versions supported are from 3.6 to 4.2 at the time of writing.

The deployment for MongoDB in ClusterControl requires SSH connectivity between the controller and the database nodes and the user must have sudo privileges. We need to fill the cluster name, ssh user, password, the upstream vendor, and then specify the IP addresses of the database nodes.

MongoDB Ops Manager uses agents for the deployment of MongoDB. It also supports the deployment of standalone, ReplicaSet, and Sharded Cluster. We need to install the agent on the database node first, configure the mms endpoint, mms groupId and the mms api keys. After that, we need to prepare the data directory and configure the ownership of the directory. The last thing we need to do is bring up the agent service:

$ systemctl start mongodb-mms-automation-agent.service

And we can verify that Ops Manager can connect to the agent by clicking the Verify Agent button.

In the screenshot below, we’re setting up a ReplicaSet. 

There are options for configuring parameter settings, e.g., heartbeat timeout, election timeout, write concern majority.

Both ClusterControl and MongoDB Ops Manager have similar capabilities in deploying various MongoDB topologies.

Scalability

There are two options when we talk about scalability; scale-up and scale-out. Scale-up is a process of increasing the specs of the existing server, e.g.into a bigger VM. Scale-out is the process of adding more nodes to the database cluster.

ClusterControl supports the scale-out of the MongoDB cluster. In the Cluster menu, it is enough to use the  Add Node option.

There are two options when adding a node, we can add a brand new node where the software is installed, or import an existing MongoDB server. There is an option of the node type, either it is database server or arbiter. We just need to fill in the hostname and click finish. As simple as that for adding a new node in ClusterControl.

ClusterControl also has capabilities to convert ReplicaSets and Standalone nodes into Sharded Clusters.

MongoDB Ops Manager also has a feature for scaling out an existing database cluster. When we add the new MongoDB node, there are a few options of member types we can choose from :

• Default – the MongoDB database server node

• Arbiter – the arbiter is a MongoDB service that does not store the data, acts only for completing the quorum of the cluster.

• Hidden – the node will not visible from the application perspective.

• Hidden Delayed – the hidden delayed is the node that is hidden from the application and has delayed replication based on the threshold that we configure.

Both ClusterControl and MongoDB Ops Manager can perform scale-out of the cluster by adding new nodes. The difference is that MongoDB has an option for hidden and delayed secondary.

Monitoring and Alerting 

ClusterControl has various metrics in the dashboard, there are 2 categories of MongoDB metrics which are Replicaset and Server metrics. We can see information about the connection, the WiredTiger cache, concurrent read and writes,  global locking, and some other information. We can also see the performance advisors regarding the database and operating system.

These graphs will give us visibility about the current condition of the MongoDB database. ClusterControl also provides alerts via email, or it can be integrated with external tools. 

We can specify an External Email and choose the events we want to set to deliver. ClusterControl supports alerts to various collaboration channels eg: VictorOps, Telegram, OpsGenie, Slack, or we can create our own webhook in ClusterControl.

ClusterControl also provides performance advisors, which are mini programs that alert on different conditions. ClusterControl allows users to create their own custom advisors in a JavaScript like DSL language using a Developer Studio.

MongoDB Ops Manager also comes with metrics, such as database metrics, node metrics, and replication metrics. We can dig into the data if there is any performance issue in the database, and also we can configure database profiling to capture the queries and read the performance advisors.

The alert in MongoDB has a flexible setting which we can set based on certain conditions and criteria.

We can send the alert to specific roles and email too. On the integration part, MongoDB Ops Manager also has various integration options as below:

Both ClusterControl and MongoDB Ops Manager have the capability to monitor the current MongoDB database service and send the alert through the integration into the various third-party alerting applications.

Backup

Backup and restore is one of the most important tasks when managing a database. Backup is a critical aspect to tackle data loss that might lead to the disruption of business operations.

ClusterControl supports two methods of backup; mongodump and Percona Backup for MongoDB. The mongodump is a logical backup method that will take a backup for your collections, including the data and write it into the file. Percona Backup for MongoDB supports Point in Time Recovery backup for consistent backup across the MongoDB sharded clusters. This gives us the flexibility to restore based on an exact time. Percona Backup for MongoDB requires an agent called PBM Agent to be installed across the nodes and we need to have shared storage configured too.

MongoDB Ops Manager has its own built-in backup for taking the backup from source through agents. It will stream the data into the Oplog Store temporarily by the Backup Daemon. During the streaming of the backup, there is a process for watching the oplog. This is to gather the difference between the changes between the backup state and the current state of the database. The building process of backup starts when Ops Manager receives the first batch of sync and creates a local version of the backed up database which is called head database. The Backup Daemon will start inserting documents from the Oplog Store into the head database and applying oplog will apply tailed oplog entries that have already been watched into the head database. 

Support for Polyglot environments 

It is not uncommon for an application or a platform to be using other databases along with MongoDB, and these other databases also have to be managed – everything from maintaining availability, monitoring, managing backups, and so on. This is probably one of the biggest differences between ClusterControl and MongoDB Ops Manager, as ClusterControl allows its users to also automate MySQL, MariaDB, PostgreSQL, Redis, and Timescale.
 

That’s all for today. There are probably more differences that we have not covered in this post, we welcome you to share your own experiences.