Practical Tips to Get Started with OpenStack (Part 1)

OpenStack Design Summit 2014 ended successfully last month in Atlanta – Nimble was very fortunate to be invited to speak in the block storage design considerations breakout session.  In this blog post, I’ll share key observations, learning from the summit, as well as some quick practical tips to get started with the OpenStack journey.  If you missed the summit or the breakout session, no problem, the OpenStack Foundation has already posted all the session videos on their Youtube channel.   Below is the session recording featuring Nimble’s Jay Wang (our OpenStack R&D lead) and myself:

First of all, the summit was very well attended with 4500+ attendees worldwide.  There were hundreds of breakout sessions, most of which were deeply technical.  Networking & Storage sessions were all sold out (including the Nimble one of course).  It is a clear sign that OpenStack is picking up steam from companies of all sizes.  Jay and I had the opportunity to speak with a great number of attendees from various companies.  Our observations could be summarized as follows:

  • tremendous amount of interest in building out a highly available, highly scalable, high performance private cloud backed by OpenStack
  • great levels of interest in leveraging block storage to back OpenStack controllers, database and instances big & small (in fact, handful of users had difficulty getting good performance from DAS attached to servers)
  • many many questions around getting OpenStack up and running to prove viability for internal cloud projects (often times, folks do not get extra budget for dedicated OpenStack PoC)

Given the level of interest from folks in getting started quickly, I decided to share three practical tips that have worked well for a good number of Nimble customers, to kick start the OpenStack journey with agility, efficiency and cost effectiveness.

Tip #1: Leverage what you have

It may not be necessary to go all out and purchase dedicated equipment just to try out OpenStack.  If you already have an existing vSphere environment dedicated for dev/test, you could do the following to get OpenStack up and running within minutes:

    • carve out a resource pool to host openstack controller(s) and a few VM instances
    • carve out a volume from your shared storage array (with Nimble, you could easily find the array or cluster capacity and performance head room through Infosight; and then provision the volume from vCenter Plugin)
    • start out with a single “all-in-one” openstack controller/nova VM (CentOS is a good choice as it’s free)
    • automate openstack installation through Red Hat OpenStack (upstream OpenStack release code similar to Fedora/RHEL model); the installation for any release is literally three commands with packstack & puppet in the background (

Tip #2: Keep It Simple

To keep the OpenStack cloud up and running, both the controller and mysql database need to be highly available.  There are lots of design choices in achieving HA for these components (for example, mysql with galera replication over local DAS, pacemaker for IP monitoring).  You may be tempted to google for example configurations on all the available choices, and may even attempt to try them out in your own OpenStack cloud.  My recommendation is to keep it simple, and ask yourself whether the openstack cloud needs to have continuous availability (meaning zero down time).  If you are just starting out and testing the water with OpenStack, then the answer is most likely no.  In such a case, leverage vSphere HA to perform automatic restart of the controller and mysql VMs.  Why?  It simply works, it has been thoroughly tested by VMware, it has been used by large number of VMware customers in production, and most importantly, you could configure it within minutes (see wizard below).




Tip #3 Always have a safety net

Here’s one last tip that could save you from having to reinstall Openstack/controller OS from scratch.  Let’s not kid ourselves – as we play with configuration files, advanced settings (especially keystone), we could end up in a situation where things just stop working.  Instead of spending your time troubleshooting or trying to undo what was done, you could revert back to the original working state with a click of few buttons.  Let’s talk about snap & restore in more details:

Snap to capture working state

Take array volume snapshot every important step of the way…for example, after Centos OS installation on the VM, after openstack installation, before making keystone/nova/cinder configuration changes.  Doing so with Nimble is easy, if you have followed tip #1 above, you could leverage vCenter Plugin to take the array based snapshot to capture working states throughout (with Nimble’s snapshot efficiency, these snaps won’t take up much storage space, nor would you see performance degradation):



Restore back to working state

Reverting back to original working state is just as easy:

1)in vSphere, power off the controller/DB VM(s) that need to have its state reverted

2)from Nimble array, find the snapshot representing the working state you want to revert to, and then hit “Restore”

3)Rescan ESXi server

3)Power VM(s) back on and you are done



Notice a common theme with these practical tips?  The goal is to get started in a short amount of time, without having to invest in additional hardware, without sacrificing high availability and ability to revert back to working state.  You can easily achieve this goal with Nimble Storage.  In part 2, I will share cinder tips in areas of configuration, multi-tenancy, multipathing and “gotchas”.  Stay tuned for part II!

Leave a Reply

Your email address will not be published. Required fields are marked *