OpenStack components

OpenStack is a modular system. Although some OpenStack Architects choose to implement a reference architecture of all of the core components shipped by an OpenStack distributor, many will only implement the services required to meet their business cases.

Reference implementations are typically used for development use cases where the final production state of the service might not be well-defined. Production deployments will likely gate the availability of some services to reduce the amount of configuration and testing required for implementation. Reference deployments will typically not vary from the distributor's implementation so that the distributor's deployment and testing tools can be reused without modification.

In this book, we'll be focusing on the following core components of OpenStack.

Compute

OpenStack Compute (Nova) is one of the original components of OpenStack. It provides the ability to provision a virtual machine, an application container, or a physical system, depending on configuration. All provisioning is image-based, and the OpenStack Image Service (Glance) is a prerequisite for the Compute service. Some kind of networking is also required to launch a compute instance.

Networking was originally provided by the Compute service in OpenStack, but the use of Nova Networking was deprecated in the Newton release of OpenStack, and it is no longer supported. Networking is provided by the Neutron service, which offers a wide range of functionality.

In OpenStack, we refer to provisioned compute nodes as instances and not virtual machines. Although this might seem like a matter of semantics, it's a useful device for a few reasons. The first reason is that it describes the deployment mechanism; all compute in OpenStack is the instantiation of a Glance image with a specified hardware template, the flavor.

The flavor describes the characteristics of the instantiated image, and it normally represents a number of cores of compute with a given amount of memory and storage. Storage may be provided by the Compute service or the block storage service, Cinder. Although quotas are defined to limit the amount of cores, memory, and storage available to a given user (the tenant), charge-back is traditionally established by the flavor (that is, instantiating a particular image on an m1-small flavor may cost a tenant a certain number of cents an hour).

The second reason that the term instance is useful is that virtual machines in OpenStack do not typically have the same life cycle as they do in traditional virtualization. Although we might expect virtual machines to have a multiyear life cycle like physical machines, we would expect instances to have a life cycle which is measured in days or weeks. Virtual machines are backed up and recovered, whereas instances are rescued or evacuated. Legacy virtualization platforms assume resizing and modifying behaviors are in place; cloud platforms such as OpenStack expect redeployment of virtual machines or adding additional capacity through additional instances, not adding additional resources to existing virtual machines.

The third reason that we find it useful to use the term instance is that the Compute service has evolved over the years to launch a number of different types of compute. Some OpenStack deployments may only launch physical machines, whereas others may launch a combination of physical, virtual, and container-based instances. The same construct applies, regardless of the compute provider.

Some of the lines between virtual machines and instances are becoming more blurred as more enterprise features are added to the OpenStack Compute service. Later on, we'll discuss some of the ways in which we can launch instances which act more like virtual machines for more traditional compute workloads.

Object storage

Ephemeral backing storage for compute instances is provided by the Nova service. This storage is referred to as ephemeral because its life cycle coterminates with the life cycle of the compute instance. That is, when an instance is terminated, the ephemeral storage associated with the instance is deleted from the compute host on which it resided. The first kind of persistent storage provided in the OpenStack system was object storage, based on the S3 service available in the Amazon Web Service environment.

Object Storage is provided by the Swift service in OpenStack. Just as Nova provides an EC2- compatible compute API, Swift provides an S3-compatible object storage API. Applications which are written to run on the Amazon EC2 service and read and write their persistent data to the S3 Object Storage service do not need to be rewritten to run on an OpenStack system.

A number of third-party applications provide an S3 or Swift-compatible API, and they may be substituted for Swift in a typical OpenStack deployment. These include open source object stores, such as Gluster or Ceph, or proprietary ones, such as Scality or Cloudian. The Swift service is broken down into a few components, and third-party applications may use the Proxy component of Swift for API services and implement only a backend, or may replace the Swift service entirely. All OpenStack-compatible object stores will consume the tenant model of OpenStack and accept Keystone tokens for authentication.

Block storage

Traditional persistent storage is provided to OpenStack workloads through the Cinder block storage component. The life cycle of Cinder volumes is maintained independent of compute instances, and volumes may be attached or detached to one or more compute instances to provide a backing store for filesystem-based storage.

OpenStack ships with a reference implementation of Cinder, which leverages local storage on the host and uses LVM as well as the ability to use iSCSI to share a block device attached to a Cinder storage node that can use its storage for instances. This implementation lacks high availability, and it is typically only used in test environments. Production deployments tend to leverage a software-based or hardware-based block storage solution, such as Ceph or NetApp, chosen based on performance and availability requirements.

Network

The last of the foundational services in OpenStack is Neutron, the Network service. Neutron provides an API for creating ports, subnets, networks, and routers. Additional network services, such as firewalls and load balancers, are provided in some OpenStack deployments.

As with Cinder, the reference implementation, based on Open vSwitch, is typically used in test environments or smaller deployments. Large-scale production deployments will leverage one of the many available software-based or hardware-based SDN solutions, which have Neutron drivers. These solutions range from open source implementations such as Juniper's OpenContrail to proprietary solutions such as VMware's NSX platform.