OpenStack is developed like most open source software projects. The code is available at http://openstack.org, and it can be downloaded in the package format from: http://tarballs.openstack.org. As of the Queens release of OpenStack, there were over 700 individual projects available for download. That's a huge number of source repositories for an engineering team to sort through and manage, hence the development of the OpenStack distributions. Most of the OpenStack distributions are put together by the same groups that put together Linux distributions. For example, the three major distributions available are part of the Ubuntu, openSUSE, and CentOS Linux distributions. Each of these distributions maintain installation guides, which are available at: http://docs.openstack.org. There are also distributions available from companies...

Selecting a hardware platform for compute infrastructure in OpenStack is similar to selecting a hardware platform for any other workload in the data center. Some organizations have a brand loyalty to a particular vendor based on reputation, past performance, or business arrangements, and some organizations ask hardware vendors to bid on projects as they come up. A small number of organizations choose to assemble their own systems from components, but most OpenStack deployments use the same commodity systems that would be deployed to run any other Linux workload.

With that said, we've definitely seen hardware configurations that work well with OpenStack and ones that had to be reconfigured after the fact. We'll try to help you avoid that second purchase order in this section.

The network requirements for a particular OpenStack deployment also vary widely depending on the workload. OpenStack also typically provides an organization's first experience with Software-Defined Networking (SDN), which complicates the design process for the physical and virtual networks. Cloud Architects should lean heavily on their peers in the network architecture team in the planning of the network.

OpenStack's roots in the public cloud provider space have left a significant impact on the network design at both the physical and virtual layer. In a public cloud deployment, the relationship between the tenant workload and the provider workload is based on a total...

As compute hardware has become less expensive over the past few years, fewer and fewer workloads are constrained by a lack of processor or memory performance. Instead, most workloads are tuned so that they are constrained on I/O—particularly, storage I/O. OpenStack workloads typically separate the operating system storage from the application storage and Cinder, and the different object storage projects provide mechanisms to present many different kinds of storage with a single interface. This capability allows tenants to choose the storage that matches their application's requirements. In addition to Cinder providing persistence for applications, block storage and object storage also provide storage persistence for instances and allow instance live migration, backup, and recovery.

To properly evaluate the different compute, network, and storage options we've discussed in this chapter, an expanded OpenStack deployment with dedicated roles for different physical systems is required. Separating the compute functions from the control functions allows us to properly test different types of compute hardware. Separating storage functions from compute and control functions allows us to properly test different disk, NAS, or SAN configurations. In this section, we'll split out the roles we deployed in Chapter 1, Introducing OpenStack, to three physical systems. Each of these systems will be assigned a role, which we'll call a host group.

OpenStack deployments are often compared with snowflakes. There are so many different ways to combine the various supported compute, storage, and network configurations that no deployment resembles any other deployment. This analogy is frequently used in frustration at companies that offer commercial support for OpenStack—the diversity of deployments makes supporting customers extremely difficult. Many of the clients we work with have also expressed frustration at the myriad of options available. On the other hand, most of the people who have been running OpenStack for a while realize the value of having so many options. It allows them to continually provide new services and capabilities to their customers under a common interface.

In this chapter, we walked through each of the three major areas of technology in OpenStack—compute, network, and storage. In...

Please refer to the following links for further reading:

• The list of Neutron Plugins: https://wiki.openstack.org/wiki/Neutron#Plugins
• The list of Cinder Drivers: https://wiki.openstack.org/wiki/CinderSupportMatrix
• The list of OpenStack Distributions: https://www.openstack.org/marketplace/distros/
• Standard Performance Evaluation Comparison for Virtualization: http://spec.org/virt_sc2013/