OpenStack Primer

The OpenStack submit has ended here in Texas so I decided to write a high-level overview of the OpenStack platform. Many of my customers and readers have inquired about OpenStack as the discussion around Cloud in a lot of organizations starts to heat up. So what is OpenStack? Why would I want to use OpenStack? These are some of the questions I will attempt to answer. However, I want to add a disclaimer here. I’m not an OpenStack guru and this was just as much as learning exercise for me as I hope it will be for you.

Introduction and History

OpenStack was a collection of open source technologies that formed a cloud computing framework that created large pools of compute, networking and storage resources that are centrally managed by a Dashboard while empowering users to provision resources. It also has a command line interpreter and large collection of APIs which makes is highly customizable when it comes to meeting the needs of an organization. As an open technology that goal of OpenStack was to promote collaboration between developers and partners in the spirit of transparency.

OpenStack started back in 2010. It was created by Rackspace and NASA as an answer to Amazon’s AWS public cloud offering. It was a combination of NASA’s Nebula Computing Platform and Rackspace’s Cloud Files Platform.

Organizational Overview

OpenStack is maintained by a Board of Directors, Technical Committee, and a User Committee. Known as the OpenStack Foundation. The goal of the OpenStack Foundation is to promote, maintain, and serve the entire ecosystem. Contributions can come in the form of individual developers, Manufacture development and Documentation. Each area performs a key role in the development of OpenStack and making sure the product goes through a proper development cycle.

OpenStack has a fairly simple release name format. The release names are in alphabetical order which makes it easier to determine the version and the release date. The development cycles are typically around 6 months. There release cycle is pretty straightforward.

Planning & Design: Lasts around 4-weeks with the final revision approved at the design summit

Implementation: This is when the rubber hits the road and the coding begins and the creation of the documentation. The implementation is broken up into iterations

Release Candidates: Testing and bug fixes are addressed at this stage. No more features are added after RC1 or Release Candidate 1.

Release Day: The last release candidates are published

Here is a link to the latest releases.

OpenStack Components

OpenStack is a modular platform that is manages compute, networking and storage components within the cloud infrastructure. This modular design allows for flexibility and the mobility of your application(s) using exposed APIs. These components in the OpenStack lingo are known as “Projects”. Each project has a team leader who responsible for the overall development and interoperability with vendors and partners. Projects are broken down into several terms which describes their roles in the overall process. OpenStack uses has developed a nomenclature that describes a projects status within the OpenStack organization. This link shows the project types.

OpenStack Requirements

The following is needed to build an OpenStack environment.

Host Operating System (Windows, Linux, VMware, etc.): A host operating system is needed for the compute platform. That can be a bare metal instance or a more commonly a virtualization platform like VMware, Hyper-V or KVM. And that brings me to one biggest misconceptions about OpenStack. OpenStack is not a replacement for your Hypervisor. OpenStack is a Cloud Frameworks that ties everything together into a cloud framework. You still need a host operating system.

Database Service: Like most software nowadays, a database backend is needed to power the OpenStack engine. The Database service is powered by MySQL.

Requires a Message Queuing (IMQ) Service: Message Queuing the process that allows a group of application components to form a much larger application. Without a message queuing service OpenStack components would not be able to communicate and scale. Making each component or project a separate independent application. RabbitMQ, Qpid, and ZeroMQ are the supported IMQ services.

Networking (Layer 2 and Layer 3): This is a no brainer. Without networking your users wouldn’t be able to gain access to applications or services.

Key Services:

OpenStack is made up of several key services which at a minimum are needed to deploy a OpenStack cloud environment.

  1. Compute Services (Nova)
  2. Networking Services (Nova or Neutron)
  3. Storage (Cinder or SWIFT)
  4. Identity Services (Keystone)
  5. Image Services (Glance)

Each of these services are building blocks for an OpenStack deployment. Let’s explore each of these and get a better understanding how each works.


Nova is a control plane or management layer for the compute environment. Your instance will run on top of Nova. Under Nova is your hyper-visor environment. Most hyper-visors (as I mentioned earlier) are supported including VMware, Hyper-V, and KVM. For each Hypervisor instance there is a corresponding Nova instance. So the hypervisor acts as the data layer and Nova would be the management layer.  This is an important distinction to understand going forward. For those with a Cisco background understand a control and data plane. Think of the control plan as the management layer and the data plane as the data layer in a Nova Compute environment.

Nova Networking

Nova comes with the standard networking components. From L2/L3 connectivity, DHCP services and VLANs. Networks can range from the simple flat networks to a multi-VLAN network gives most organizations flexibility they need in an OpenStack deployment. Nova runs into some scalability issues in larger deployments and that is were Neutron come into play.

Neutron Networking

Neutron is a software defined networking platform which designed for larger organizations and service providers. As mentioned before, Nova has some inebriate scalability limits which could cause challenges for large OpenStack deployments. One of the biggest was the 4096 VLAN limitations which for most organization is more than enough but it’s could be a challenge in larger service providers. It also didn’t do well from an interoperability standpoint outside of the OpenStack environment. Finally, the code base for Nova was becoming by far the largest projects and it quickly made sense to create a separate project to handle networking.

Neutron introduced support for advanced features like stretch and overlay VLANs. This opened the door for third parity plugins which allowed for seamless integration with networks outside of the OpenStack ecosystem. Some of the newer topologies introduced were VXLANs and GRE.


Keystone is OpenStack’s Identity Service. Identity Services provide a means to authentic and authorize users in a OpenStack Cloud environment. These users can be users accessing a specific application or service. The OpenStack identity service uses a token based system as a way to authorize a user to a specific set of resources. Keystone can be standalone or has the ability to integrate with Microsoft Active Directory.


If you are familiar with any Hypervisor platform than virtual machine images. This is where OpenStack Glance comes into the picture. Images allow you to create prebuilt Virtual Machines templates for rapid deployment of Virtual Machine guests. Glance can manage images at a global or ternate level depending on the use case. Images are typically stored in a dedicated volume which can be stored locally or in the public cloud like AWS.


Cinder is the OpenStack is a block storage platform. Its comparable to AWS’s Elastic Block Storage volumes and are persistent when an instance (Virtual Machine) is terminated (Unlike ephemeral storage which is deleted when an instance is terminated). A lot of storage vendors are contributing to the Cinder platform allowing for growth of features and functionality.

Cinder attaches and detaches volumes using iSCSI. A wide variety of features are available including Snapshots and Cloning. The feature list of Cinder will continue to grow as the project matures and better integration with manufactures like NetApp, EMC and others.


Swift is OpenStack object storage projects. It is similar to Amazon S3 protocol. Object storage allows applications to access web objects which makes accessing data a whole lot simpler for developers. Swift has been around since the beginning of OpenStack and can be used as a standalone product. Swift can leverage commodity servers and disk drives (JBODs) and create a distributed storage environment that is highly saleable. RAID is not needed in a SWIFT deployment but instead leverages a three replica or erasure coding data protection schemes. Three replica or object copy is pretty straightforward. There are three copies of object in the object storage environment which can be across three data centers. This is effective but also presents a lot of overhead. Erasure coding removed some of the overhead by striping the data across data centers like RAID 5 does to disk drives. This is far more efficient from a capacity standpoint. For more info on object storage please check out my post here.

Whew! That was a lot of information! As you can see, OpenStack is a very complex and extensive solution. We just barely scratched the surface. Each of these areas could be easily a week long course. My goal was to get you familiar with the terminology and understand at a high-level how OpenStack works. I personally believe as the technology matures we’ll see more adoption. At this time large organizations and service providers are the most likely candidates. Smaller shops just don’t have the time or the expertise to put in OpenStack.

Leave a Reply

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