Visit Nutanix

Nutanix Connect Blog

Welcome to the Nutanix NEXT community. To get started please read our short welcome post. Thanks!

Showing results for 
Search instead for 
Do you mean 

Stateful Container Services on Nutanix Part 3: MongoDB Replica Set

by Community Manager ‎12-06-2016 09:38 AM - edited ‎12-09-2016 01:00 PM (2,072 Views)


This blog was authored by Ray Hassan, Sr. Solutions & Performance Engineer at Nutanix, and Kate Guillemette, Technical Writer & Editor, Solutions & Performance


In this final post in our stateful container series, we use some of the container tools available to set up a MongoDB replica set within containers and have each instance store its data to a volume on the Nutanix storage layer. We created and provisioned these Dockerized VMs in Part 2; here, we are getting them to run MongoDB.


The best way I’ve found to generate a repeatable build process for setting up the same MongoDB instance every time is with Docker Compose. Compose uses a YAML-based configuration file to set up multiple container environments, so a single command can stop, start, and rebuild container services.


Where Docker Machine and Compose really come into their own is in conjunction with an orchestration and scheduling framework like Docker Swarm, for example. Swarm treats a collection of Docker hosts as a single virtual host. With the scaling that Compose makes possible, you can then deploy services across the hosts according to desired constraints and affinities. I’m not going to cover Swarm or other automation frameworks here, but such technologies will be part of our ongoing work on the orchestration and scheduling of “stateful” applications or services.


Here are the next steps to get our MongoDB instances up and running:

  • Connect to each Docker Machine.
  • Install Docker Compose using the instructions available here.
  • On each machine, create a Compose file with the following contents:

Screen Shot 2016-12-06 at 7.26.30 AM.png


In the above Compose file, we define a mongodb: container service using the default mongo image: from Docker Hub, and we are using the Nutanix volume_driver: for our volumes. We create a single persistent volume, dbata0n, where n = 1…3. This volume maps to /data/db within the container runtime.


I decided to map the ports: like for like, so here port 27017 (mongod) in the container maps to 27017 on the host. I start the mongod daemon with the replSet option. Using this option requires an additional ntnx parameter (the name of the replica set). Finally, I am using the host: networking directly. In our example, I’ve made this choice purely for convenience, but database vendors deploying their applications in containers often call direct host networking out as a best practice.


  • Start the container service by running the compose up command on the Compose file above like so:

# docker-compose -f ./mongo.yaml up -d


  • Verify that your MongoDB container service is running via one of the commands below:

Screen Shot 2016-12-06 at 7.28.50 AM.png


In the steps above, we’ve covered the creation of volumes “on the fly” within the Compose workflow. However, you can also use volumes that you’d already created and had ready for reuse. Maybe your workflows demand that you create volumes up front, ahead of time. We’ll cover that use case in the following section.


Volumes are a first-class citizen within Docker, which means that you can create them as standalone units. So, if you prefer to precreate your volumes using docker volume create, you need an alternate “version 2” of the Compose file syntax. First, create the Docker volumes using the Nutanix volume driver, then call them out as “external” volumes in the Compose file itself. Here is an example of this procedure:


  • Precreate your named volume and ensure that you specify the Nutanix volume driver.

Screen Shot 2016-12-06 at 7.31.53 AM.png

  • Bring up the MongoDB container service using a Compose file with the version 2 syntax.

Screen Shot 2016-12-06 at 7.34.19 AM.png


When you compare this version 2 block to our original Compose file above, notice that services: and volumes: are now in their own separate YAML stanzas. If we were to use overlay networks, we would do the same with networks. We’ve also changed the network_mode: label in this version.


Both mechanisms for running container services with persistent volumes created via the Nutanix volume driver create the volumes as iSCSI block devices in a VG within the Prism GUI. See below:




Now that we have each individual MongoDB instance running in its own container with its own persistent volume, we can finally initialize our replica set. We need to connect to a Docker Machine, attach to its running container, and manipulate the database via the MongoDB API interface.


Screen Shot 2016-12-06 at 7.39.12 AM.png


  • Obtain the container ID and attach a bash shell to that running container.
  • From within the container, run a mongo shell session.


Screen Shot 2016-12-06 at 7.40.05 AM.png 


  • From within the mongo session, create a replica set configuration JSON document and then initialize the replica set.
  • Obtain the Docker Machine IP addresses from either docker-machine ls or docker-machine ip <machine hostname> I strongly recommend using the form of set initialization below. If you use the default rs.initiate() without a cfg document parameter, your primary MongoDB instance hostname could end up resolving to the loopback interface or localhost, leaving you unable to speak to the other replica set members.

Screen Shot 2016-12-06 at 9.26.47 AM.png



One of the issues people frequently encounter with pet containers is the requirement for longstanding DNS names. Therefore, unless you want to manage IP addresses locally, you definitely need to assign each of the replica set members an IP address that is resolved via DNS. Without a resolvable address, the other instances might not be able to synchronize data from the primary, so you would have to attempt to reconfigure the set membership by hand. Not only is this not a nice position to be in at this stage, but it also might prove difficult to do at all without starting the whole process again.


At this point, you should have a replica set running between your three MongoDB instances:


Screen Shot 2016-12-06 at 9.29.35 AM.png


The process we’ve outlined so far has not quite brought the deployment to the point where it’s truly production-ready. However, in a real use case, we could automate much of this labor. Further work toward streamlining deployment could include building out stateful services across a cluster of Docker Machine hosts; this project would allow us to think about affinities and constraints when considering how to locate (or more importantly not colocate) the various database services.


If you're working on stateful services that are running in a hybrid cloud environment, we would love to talk more and share experiences. Get in touch with us via our social media channels or the Nutanix Community Forums.


Additional Information

The Intersection of Docker, DevOps, and Nutanix

Containers Enter the Acropolis Data Fabric

Nutanix Acropolis 4.7: Container Support




Disclaimer: This blog contains links to external websites that are not part of Nutanix.com. Nutanix does not control these sites, and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

Stateful Container Services on Nutanix Part 2: MongoDB

by Community Manager ‎11-28-2016 03:32 PM - edited ‎12-09-2016 01:01 PM (2,205 Views)

This post was authored by Ray Hassan, Sr. Solutions & Performance Engineer at Nutanix and Kate Guillemette, Technical Writer & Editor, Solutions & Performance at Nutanix.


In our last post on stateful containers, we talked about using the Nutanix-Docker integration components to configure and run stateful (“pet”) applications or long-running services in containers. Many organizations have been reluctant to try running their pet workloads in containers, at least in a production setting. Using MongoDB as a test case, I hope to provide some assurance that containers aren’t just for short-lived applications anymore.



Source: https://twitter.com/mfdii/status/697532387240996864 (Used with permission.)


Using containers to bring up a cloud-native database application like MongoDB is nontrivial to do right. I don’t plan to cover every aspect of a production deployment at this stage, but future solutions-based work in this area will work on it. You can see from the image above that there is far more to deploying containers than the docker pull/docker run sequence.


First, let’s consider the virtual host provisioning and data persistence aspects of a stateful deployment.


Installation and Setup


First off, we need to download the Docker Machine driver for Nutanix along with the CentOS container host image from the Nutanix portal. Upload the container host image to the Acropolis Image Service and copy the Docker Machine driver to a directory on your Docker CLI host. In these examples, the CLI host is a Linux VM running on my desktop, but Nutanix also provides drivers for Mac/OSX and Windows—just adapt the instructions accordingly. I’ve tried to capture all of the required installation steps below, but if you need more details, please download the Acropolis Container Services Guide.


[ Related Reading: Stateful Container Services on Nutanix Part 1 ]


Ensure that you are running AOS version 4.7 or later and assign a dataservices IP to the cluster via either Acropolis Prism or nCLI.


Screen Shot 2016-11-28 at 3.12.35 PM.png


  • Download the CentOS container image to your laptop or workstation from the Nutanix support portal, then upload it to the Acropolis Image Service—the example below uploads directly from the portal URL.

Screen Shot 2016-11-28 at 3.13.29 PM.png


The next step is to download the Docker Machine driver from Nutanix and install it into my Linux VM.

Screen Shot 2016-11-28 at 3.14.46 PM.png


Now we’re ready to spin up Docker Machines on the Nutanix platform.


Nutanix Docker Machine and Volume Driver

The Nutanix Docker Machine driver allows us to deploy VMs with Docker Engine preinstalled, much like you could do in a public cloud. The difference is that the VMs run on Nutanix AHV, the hypervisor that underpins the Nutanix Enterprise Cloud Platform. Using the create option, you can customize your Docker Machines, not only with VM sizing and base OS configuration, but also with the Nutanix driver itself. This flexibility means that we can generate VMs in various sizes. The following command line help option shows some of the additional parameters you can supply to the Nutanix driver when building out Dockerized machines:


Screen Shot 2016-11-28 at 3.16.33 PM.png


This command returns Nutanix driver-related options that allow you to create VMs with the desired RAM (--nutanix-vm-mem) and CPU or core count (--nutanix-vm-cpus or --nutanix-vm-cores) using the docker-machine CLI.


Now that we’ve seen how to tailor VM specifications, it’s time to create some machines using the Nutanix driver. Let’s start by setting up three Dockerized VMs. Each VM runs a MongoDB instance that will eventually form part of a replica set.


Screen Shot 2016-11-28 at 3.19.58 PM.png

The intention is to use the Docker ecosystem components (Machine, Compose, and so on) to make a repeatable, automated build process for our MongoDB instances. The command line syntax for each host follows the same format.


Screen Shot 2016-11-28 at 3.21.11 PM.png


In the Docker Machine command above, we’re creating a Dockerized VM called dbhost01. We specify the Nutanix machine driver, the Nutanix Prism network endpoint, and the user credentials for talking to the Prism API. We also call out the CentOS container host image and the network (vlan.68) where the VM should run. I added in a few extra options that set CPU and RAM resources a little above default, at one CPU, eight cores, and 1 GB RAM—it’s going to run a database, after all!


Next, we can choose how we administer Docker on the newly minted VM: either connect to the machine directly via SSH or run the eval command string locally and talk remotely to Docker Engine on the Docker machine host (VM). Let’s do a little of both to show you the options:


  • Set up the Docker Machine connection environment.


Screen Shot 2016-11-28 at 3.25.01 PM.png


  • Now we are talking to the Docker daemon on the new machine. Pull the Nutanix volume plugin from its repository if required—the start-volume-plugin.sh script should already be installed on the VM in the root home directory, however.

Screen Shot 2016-11-28 at 3.26.14 PM.png


  • Connect to the Docker Machine and configure the Nutanix volume plugin:

Screen Shot 2016-11-28 at 3.27.23 PM.png


In total, create three Dockerized VMs and deploy them on the Nutanix platform. Each one has the Docker Engine and the Nutanix volume plugin installed, so we can create persistent volumes for the database instances.


You can find these VMs in the Prism GUI under the VM → Table dropdown menu and manage them like any other VMs. The Acropolis DHCP/IPAM facility assigns them an IP address. Even after creation, you can change the number of cores or the memory capacity as shown below.





Here we have our Dockerized VMs up and ready to host services. In the next post, we’ll cover the setup of a MongoDB replica set, using the Nutanix volume plugin to create persistent storage on the DSF.


If you’re working on stateful services that are running in a hybrid cloud environment, we would love to talk more and share experiences. Get in touch with us via our social media channels or the Nutanix Community Forums.


Additional Information

The Intersection of Docker, DevOps, and Nutanix

Containers Enter the Acropolis Data Fabric

Nutanix Acropolis 4.7: Container Support


Disclaimer: This blog contains links to external websites that are not part of Nutanix.com. Nutanix does not control these sites, and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

Nutanix partners with MongoDB – Now a certified IaaS platform

by Community Manager ‎07-10-2015 12:20 PM - edited ‎07-10-2015 12:43 PM (2,463 Views)

We are proud to report that Nutanix is now an official MongoDB Technology Partner. This means that MongoDB have certified Nutanix as an Infrastructure as a Service (IaaS) platform to run the latest versions of MongoDB Enterprise. This is fantastic news for our joint customers, as they now get to reap the joint synergy benefits of running a database and computing platform, both of which are built on the ideals and principles of web-scale technology.


MongoDB is fast becoming one of the cornerstones of Big Data techniques and technology. Gartner defines Big Data using the 3 V’s or volume, velocity and variety.  Where volume is the amount of data, velocity relates to how fast data is generated and/or processed, while variety acknowledges the range of data types and their respective sources. Our growing requirement to store, retrieve and analyse increasingly larger, more varied datasets means the adoption of newer approaches to data management. MongoDB uses such techniques as horizontal scale out on cloud or commodity servers, in-memory transactions, and the ability to absorb unstructured data to address these challenges. MongoDB is a general purpose, open source document database that is used to create OLTP-style ‘Systems of Engagement’. Popular use cases include: the Internet of Things (IOT), inventory management, shopping cart, ad serving, content management, messaging applications and real-time analytics.


Deploying MongoDB on the Nutanix Xtreme Computing Platform (XCP) helps to lower time to value further by providing an unparalleled ease-of-use story. XCP is founded on the same web-scale and Big Data principles that promote easy scale out and provide predictable performance at increasing scale. Horizontal scale can be achieved by simply growing the Nutanix cluster a node at a time. Consumer grade virtual machine (VM) management operations are streamlined to the point where they are single click operations driven via Nutanix Prism. Alternatively, the same operations can be automated via a REST API or using PowerShell Commandlets. All of which allows customers to focus more on applications and driving innovation within their organisation. Running such applications on converged compute and storage within a turnkey Nutanix solution ensures your infrastructure becomes truly invisible and frees up the time that would ordinarily have been spent planning and carry out maintenance.


Moving forward post certification, we will look to strengthen our partnership with MongoDB by working towards developing further performance optimizations, additional scale-out testing, in addition to further joint solution development and detailed use case scenarios.


Nutanix has developed Best Practices for designing and deploying MongoDB on Nutanix. I wanted to share those resources with you here in the community and use this space to talk about the subject.


Contact us now for a briefing and demo customised to your use case: Tweet @nutanix, or email us at info@nutanix.com




One of the features you see a lot of on social media sites are @Mentions. With @Mentions you can acknowledge other community members.

Read More: Did you know: You can @Mention other members