Our founders, back in the day,  were part of the .NET framework team at Microsoft. So it’s no surprise that their first version of ElasticBox was written on C#, .NET framework and SQL Server.

Fast forward to 2012. As the ElasticBox vision crystallized, we wanted a robust, scalable architecture to match our vision. So we reevaluated all the existing technologies.

Among other things, we decided to move from a relational database model to a document based approach. The main reason was because we wanted to store hierarchical data and be able to version it.

Today, to accommodate our data needs, ElasticBox relies on MongoDB clusters, which we run on three separate providers–two public, one private. Thanks to ElasticBox, we can now deploy our MongoDB cluster in a matter of minutes.

The Basics

What is MongoDB? MongoDB is an open-source document store database.

Why would you want to cluster MongoDB? To provide redundancy and high-availability for production deployments.

How We Use MongoDB

In our case, MongoDB is using a replica set model. A replica set is a group of MongoDB instances that host the same data set. One MongoDB, the primary, receives all write operations. All other instances, secondaries, apply operations from the primary so that they have the same data set.

The primary accepts all write operations from clients. Replica sets can have only one primary. Because only one member can accept write operations, replica sets provide strict consistency.

Screenshot 2014-06-18 16.47.20

Deploying MongoDB through ElasticBox

ElasticBox provides a default MongoDB box that’s available to the public. It deploys a standalone instance of the MongoDB server. Our MongoDB production box very closely resembles the default box, minus a few configuration settings required for our production scenario.

While the default MongoDB box configuration is suited for development purposes, it needs to be configured further to use in production. To configure the MongoDB default box for production use, follow the steps below:

Step 1. Create a new box called MongoDB Replica. Add a box variable for the MongoDB Server (this is to use the default box settings).Screenshot 2014-06-18 16.11.18

Screenshot 2014-06-18 16.12.08

Step 2. Add a text variable REPLICA_SET to hold the replica set name. This value must be shared between all the members of the cluster.

Screenshot 2014-06-18 16.12.42

Step 3. Expand the MongoDB Server box. Edit its file variable COMMON_YAML and paste the following:

Screenshot 2014-06-18 15.35.45

mongodb::replica_set: {{ REPLICA_SET }}

mongodb::key_file: /etc/mongod.key

Screenshot 2014-06-18 16.15.36

This file will be used by hiera to pass arguments to puppet automatically without modifying the existing puppet default.pp file.

Step 4. Add a binding named primary of type MongoDB Replica (the box you just created).

Screenshot 2014-06-18 16.14.05

Step 5. Add an install script. Get the script here.

Screenshot 2014-06-18 16.16.10

Screenshot 2014-06-18 22.34.28

Step 6. Add a start script. Get the script here.

Screenshot 2014-06-20 11.40.08Screenshot 2014-06-20 11.40.35

When you deploy the box without a binding, it creates a cluster for you with an initial configuration. On the other hand, if you bind to an existing instance, it adds the instance to the existing cluster!

There, you have it, a MongoDB cluster in a few easy steps!