OpenStack , Quantum and Open vSwitch – Part I

[This is the beginning of a three part post to describe OpenStack, a new OpenStack-compatible networking service called Quantum, and the first Quantum plug-in which is based on Open vSwitch.]

We will start by providing some background on OpenStack, focusing on the original network model and the rational for creating Quantum. This is not meant to be an exhaustive (nor authoratative!) overview. If you are interested in learning more, or keeping track of the progress, check out the project homepage,

OpenStack Overview

OpenStack is a cloud management system (CMS) that orchestrates compute, storage, and networking to provide a platform for building on demand services such as IaaS. Traditionally, OpenStack has consisted of the following major subcomponents:

The following diagram provides a illustration of how the components are organized to provide the OpenStack platform.

High Level OpenStack Architecture

The system operates roughly as follows. The “Cloud Controller” cluster is responsible for managing the global state of the system. It interacts with LDAP (not shown), OpenStack Object Storage, and OpenStack Compute. OpenStack Object Storage and OpenStack Compute packages contain a centralized piece that usually runs on the Cloud Controller as well as a “worker” piece that usually runs on a particular compute or storage node. The “workers” can be thought of as agents that manage storage or compute resources locally on a single system. To communicate with compute and storage “workers”, the cloud controller uses Rabbit MQ.

The responsibilities of the primary components are:

OpenStack Compute (Nova), is responsible for managing the Hypervisor hosts, overseeing virtual machine configuration, creation, deployment and destruction on a “pool” of compute resources. Nova currently supports KVM, XEN,VMware vSphere and Hyper-V. Nova also orchestrates deployment across Availability Zones, which are often called Nova Zones{link to Nova Zones}. An availability zone represents a single unit of failure. An example of availability zone could be a Cloud provider’s San Francisco Datacenter, while another availability zone would be New York Datacenter. The rational of availability zone is that when one of the availability zone experiences failure, none of the other zones or impacted. This enables a Cloud user to mitigate risk by distributing and replicating workloads across availability zones. However availability zones need not necessarily span an entire datacenter, zones can very well consist of a single rack of servers that is situated at the north end of datacenter while another zone can be a rack of servers situated in the south end of the datacenter.

OpenStack Object Storage (Swift), allows the creation of clusters that can store, retrieve and update multi-petabyte objects, all within a single storage system. Swift handles data replication and integrity across the cluster to maintain availability during failure. The primary use cases tend to be around static, long-term data storage needs. For example, swift is used for storing virtual machine images and long term backups.

OpenStack Image Service (Glance), is a multi-format Virtual Machine Image repository that provides discovery, registration and delivery services for Virtual Machine Images and disks. Glance doesn’t actually provide the storage of the Virtual Machine Images. Rather, in order to store Virtual Machine images, Glance uses local disk, iSCSI/NAS/SAN ,and Swift as storage backends.

What about networking?

Noticeably absent from the list of major subcomponents within OpenStack is networking. The historical reason for this is that networking was originally designed as a part of Nova which supported two networking models:

  • Flat Networking – A single global network for workloads hosted in an OpenStack Cloud.
  • VLAN based Networking – A network segmentation mechanism that leverages existing VLAN technology to provide each OpenStack tenant, its own private network.

While these models have worked well thus far, and are very reasonable approaches to networking in the cloud, not treating networking as a first class citizen (like compute and storage) reduces the modularity of the architecture. Next we’ll briefly describe some of these shortcomings which precipitated the work towards Quantum, which is the proposed to sit alongside Nova, Swift, and Glance as a standalone service.

Limitations of the Current OpenStack Network Architecture

Limited network options: As we’ve mentioned, OpenStack only supports two network models. While suitable for some environments, they don’t cover all use cases.

For example, the flat model exposes one large “flat” network with no real isolation primitives, making it difficult to build support for multi-tenancy.

The VLAN model, on the other hand, provides basic isolation via 802.1Q tagging. However, it is burdened with the classic set of problems associated with VLANs such as, difficulty in supporting overlapping IP and MAC addresses, difficulty of extending L2 across subnets, VLAN scaling limits, MAC table scaling issues, dependency on proprietary interfaces for configuration of networking gear, etc.  Additionally, the VLAN model only supports having a single interface per VM.

No well-defined network interface: In addition to having limited network options, there is no well defined interface by which a new one can be created and slotted in non-disruptively.  The original developers did a good job designing flexibility into how networks are orchestrated, but the concepts of VLANs are bridges are embedded deeply in the nova codebase.

Simplistic network model: The current networking model is built around L2 and L3. However, interposition of higher-level services is a growing need and not well accommodated in the current model. For example, how would a new “Firewall as a service” offering plug into a private nova network?  Or how would one model connecting a tenant’s network to a remote data center using an MPLS circuit?

It is for these reasons that the Quantum network service was proposed. Quantum is designed to be a first class subcomponent which defines the interface for a network service. It can accommodate the existing FLAT and VLAN models, as well as many other service implementations including virtualized L2 using soft switches, service interposition, hardware integration etc.

In the next post, we will describe Quantum in detail, and describe an implementation of it using Open vSwitch.

Tagged with: , , , , , , , ,
Posted in openstack
No Comments » for OpenStack , Quantum and Open vSwitch – Part I
1 Pings/Trackbacks for "OpenStack , Quantum and Open vSwitch – Part I"