

Choosing the right deployment tool for an OpenStack cloud can be challenging. The OpenStack community does not provide a universal installer, and there are several open source and commercial players in the market that provide competitive OpenStack deployment tools.

This article will focus on the questions you should ask yourself before planning your first OpenStack deployment and will provide you with a few options to help get the job done.

Ask the Right Questions

Do You Need OpenStack?

First and foremost, you should have good reasons for choosing a private cloud vs. an existing public cloud platform. For example, you do not want to lock yourself into a single public cloud vendor or you may be required to have complete control over your infrastructure.

Using OpenStack internally for development or testing services, for example, or for production, business critical or customer facing applications, requires a well defined SLA. For example, if you are using Openstack internally for dev/test, you can potentially afford some downtime for maintenance or even for complete re-deployment.

Do You Have a Deployment Plan?

Real world deployments require several nodes and node utilization planning. In addition, you need to plan how many OpenStack controllers to use according to your SLA that, when properly configured, can support the high availability of your OpenStack cloud. Depending on the configuration, several controllers can handle hundreds of compute nodes. However, if you just want to evaluate OpenStack with a simple workload, you should plan a single node deployment (All-In-One).

In order to select the right hardware for your compute node configurations, consider the following:

The requirements for your various types of workloads

The number of VMs your cloud should be able to handle

The configuration of a single VM, such as the number of vCPUs, and the amount of RAM and disk capacity

Your storage requirements, which should include capacity, IOPS and latency, and should be made up of dedicated storage nodes in order to achieve highly available storage

Some deployment tools provide bare-metal provisioning capabilities, and some require the operating system to be installed on the nodes. In addition, some tools have specific requirements for networks. Your networking infrastructure should be properly configured before using a tool. For example, a management network should be in a single L2 segment so that planning the network and choosing a deployment tool are done in parallel, taking the tool’s features and constraints into consideration.

What Internal Expertise Do You Have?

You should be able to recognize your internal expertise that can be leveraged for your OpenStack deployment, as well as the skills that your organization has yet to master. You should use a hypervisor that is well known in your organization and can be efficiently supported by your internal team. Check your deployment tool specifications — your hypervisor may be supported out of the box, or require additional integration or third party plugins. In addition, if you have Database Administrators (DBA), you may want to use and maintain your own database within the OpenStack cloud instead of installing a new one.

If you have internal expertise with CI and CM tools such as Chef, Puppet or Ansible, you want to use a deployment tool that uses the same CI/CM tool internally. That way your team can integrate existing services into your deployment engine and can effectively support the existing recipes/manifests/playbooks as well as any customized ones.

OpenStack Deployment Tools: Know Your Options

There are several OpenStack distributions that usually contain their own versions based on stable OpenStack upstream releases. At the same time, as mentioned above, there are options, depending on your case, to deploy upstream OpenStack for your favorite operating system or with your favorite provisioning or configuration management tool.

Deploy OpenStack from Packages

OpenStack packages are available for Debian. Usually the packages for the recent OpenStack release are available for the Debian Unstable branch (codename Sid) and are backported to the recent Debian Stable branch (codename Jessie, that was released on April 26th, 2015).

Canonical provides OpenStack packages for their Ubuntu Servers in their main repository. In order to install the newest OpenStack releases on Ubuntu 12.04 and 14.04 (Long Term Support releases) you can use Ubuntu Cloud Archive. Follow this guide from the OpenStack community to install OpenStack Liberty on Ubuntu 14.04.

OpenStack Liberty packages are available on Red Hat Enterprise Linux 7 and its derivatives (CentOS) through the EPEL repository. Follow this guide from the OpenStack community to install OpenStack Liberty on Red Hat Enterprise Linux 7 or CentOS 7.

Deploy OpenStack Using Configuration Management Tools

TripleO

The purpose of TripleO (or “OpenStack on OpenStack”) is to use OpenStack’s own cloud facilities to install, upgrade and operate OpenStack clouds. To start, TripleO deploys multiple OpenStack clouds via a single OpenStack cloud that is referred to as the undercloud. The OpenStack cloud environment that the undercloud deploys is referred to as the overcloud.

Fuel

As an open source OpenStack deployment tool, Fuel recently became an official OpenStack component under the project’s current “big tent” organizational policy. The whole deployment is guided by a UI, which can be efficiently used for three nodes (minimal requirement) or for hundreds of nodes. Fuel installs Ubuntu 14.04 (Trusty) on OpenStack nodes.

Check this Q&A infographic about OpenStack deployment tools

Evaluate OpenStack with DevStack

To learn how OpenStack or a specific new release operates, you should use DevStack. It can help you install a complete stack on a single VM or even on your laptop. DevStack was written by developers and is targeted at developers and CI systems to use the raw upstream code. It makes many choices that are not appropriate for production systems. DevStack is just a shell script that does not use Chef, Puppet or another framework. It is the most operating system agnostic tool: it can deploy OpenStack on Debian Jessie, Ubuntu 14.04 (Trusty), Fedora 21 (or Fedora 22) and CentOS/RHEL 7. It can also install all of the OpenStack components on a single machine or a VM (All-In-One) and supports multi-node deployments.

OpenStack Distributions

It is not easy to install a plain vanilla OpenStack distribution and it requires you to understand the stack before running it. Known as the largest open source project worldwide, there are several distributions that can support stack deployment.

RDO – You can leverage the community edition of OpenStack on Red Hat based platforms a n d u s e t h e R D O Director which is based on TripleO for deployment. Juju – Install OpenStack on top of the Ubuntu operating system with Juju and leverage MAAS (Metal as a Service) for bare-metal provisioning. See Juju Deployer’s documentation for more information.

Your Cloud Day 2

How are you going to maintain your OpenStack cloud after the initial deployment? How flexible will your deployment be? Does the tool that you selected provide you with the proper configuration integration and management features for you to update initial changes to your OpenStack settings, and easily add and remove nodes? Along with these questions, you should define who is responsible for upgrade and patch management, including OpenStack security updates and bug fixes.

OpenStack upgrades are not trivial procedures, which is why you should decide if you want to upgrade your cloud at every seemingly stable OpenStack release. Is the new release/upgrade supported by the deployment tool you selected and what is the upgrade procedure? Does the upgrade require additional hardware? Does the downtime associated with the upgrade match your SLA?

OpenStack: DIY or Cloud in a Box?

While great advancements have been made, deploying a scalable OpenStack private cloud is not an easy task. And depending on the size of the deployment, it can take months, if not years, to prepare it for production. This is one of the major adoption obstacles that creates a gap in the private cloud market because IT teams face the same costs and risks that are usually associated with traditional IT projects.

In that respect, you may want to use a “cloud in a box” software-defined solution that comes with the typical private cloud advantages such as quick initial deployment and inherent robustness. Naturally, an OpenStack commercial offering that can leverage existing enterprise on-premises resources would help optimize investments and accelerate time to market.

Back to Blog>