[This is the second post in a three part series to describe OpenStack, a new OpenStack-compatible networking service called Quantum, and the first Quantum plug-in which is based on Open vSwitch.]
In the previous post, we provided some background for OpenStack and described how it has major sub components for Compute (Nova), Object Storage (Swift), and Image Management (Glance), yet networking is missing as a first class component (currently it is a part of Nova). While this made sense in the initial context in which OpenStack was designed, there has been a lot of effort within the OpenStack community to define a network service allowing networking to evolve easily and independently.
In this post, we describe Quantum, a recently created networking service compatible with OpenStack.
The Quantum Project – A Virtual Networking Service for OpenStack
- Provides a flexible API for service providers or their tenants to manage OpenStack network topologies (e.g., create multi-tier web applications)
- Presents a logical API and a corresponding plug-in architecture that separates the description of network connectivity from its implementation. This allows virtual networking to be implemented in virtual switches, physical switches, or both, and supports incorporating technologies from multiple vendors / open source projects.
- Offers an API that is extensible and evolves independently of the compute API, allowing plugins to easily introduce more advanced network capabilities (e.g., QoS, ACLs, etc.)
- Provides a platform for integrating advanced networking solutions such as:
- Existing firewall services
- Load balancer services
- MPLS infrastructure
The Big Picture – Quantum Cloud Networking Fabric
We’ll start by describing how Quantum fits within the existing OpenStack component architecture, shown in the diagram below.
Quantum Internals
There are 3 key functional layers of abstraction that make up the Quantum service:
Key Quantum API methods:
Method: Create Network
REST URL: POST /tenants/{tenant-id}/networks
HTTP Request Body: Specified the symbolic name for the network being created.
E.g.
{ "network":
{
"name": "symbolic name for network1"
}
}
Description: This operation creates a Layer-2 network in Quantum based on the information provided in the request body.
Method: List all networks for a particular tenant
REST URL: GET /tenants/{tenant-id}/networks
HTTP Request Body: Not Applicable
Description: This operation returns the list of all networks currently defined in Quantum
Method: Update Network
REST URL: PUT /tenants/{tenant-id}/networks/{network-id}
HTTP Request Body: Specify a new symbolic name for a particular Quantum network
E.g.
{ "network":
{
"name": "new symbolic name"
}
}
Description: This operation updates a network’s attributes in Quantum. The only attribute that can be updated, as it stands now, is the network’s symbolic name.
Method: Delete Network
REST URL: DELETE /tenants/{tenant-id}/networks/{network-id}
HTTP Request Body: Not Applicable
Description: This operation deletes the network specified in the Request URI.
Keeping in line with principles of RESTful interfaces, we have shown examples of Create, Read, Update, Delete(CRUD) methods for the “network” resource. Similar CRUD API methods are available for other resources managed by Quantum, such as “Ports” and “Port Attachments.”
Detailed API Specification is available as a living document at the following Wiki.
2) Authentication & Authorization: This layer is not yet complete, but will be reponsible for validating incoming API Requests and ensuring that an authenticated user is making the request before letting the API call pass through the rest of the stack. Quantum authentication will use the OpenStack Keystone Identity Service.
In addition to basic authentication, the API will enforce client access rights to REST resources. This is an important component for enforcing access rights in multi-tenant environments in which network configuration is exposed to the tenants.
Key Authorization roles that are currently under consideration are:
- Super User/System – Super User can operate on any network within the Quantum namespace, this account will be typically reserved for Service Providers.
- Tenant – A Tenant can create networks from the “pool” of service provider networks. The Tenant can create ports on these networks and attach interfaces to the ports, as long as the Tenant owns those interfaces (e.g., it is an interface of one of the Tenant’s nova VMs).
Quantum community is still actively defining the Authentication and Authorization capabilities of the API. The blueprint tracking this effort is available here.
3) Pluggable Backend: As we’ve mentioned, Quantum decouples the abstractions from the implementations. The primary mechanism for doing so is through a pluggable architecture in which the mechanism that implements the virtual networks is implemented as a plugin.
So, how do I implement a Quantum Plugin?
This is far from comprehensive, but to give you a general idea of how plugins work, we have put together an architectural sketch of a sample Quantum plugin (that is loosely based on the Open vSwitch plugin we will describe in the next post).
Our Reference Architecture for Quantum plugin contains:
a) A centralized Quantum controller: This is the box titled “Quantum Cloud Network Fabric Plugin”, and this controller is responsible for servicing users of Cloud environments such as OpenStack. The controller helps tie the end-user facing cloud network model, with the physical networks that are being imlemented by connecting vSwitches and pSwitches.
b) A centralized data model: This is the data model represents the network connectivity model as desired by the cloud users, where they care about creating virtual networks that provide connectivity between a set of virtual machines. A common mechanism to store this cloud network model would be for the plugin to contain an internal database. This database can be used to store the network model being desired by the cloud users. This database will also serve as the single source of “truth” for responding to Quantum API calls as well as for implementing the cloud network model by communicating with various physical and virtual switches that a particular plugin supports.
c) Virtual and Physical Switch communication channel: The final component of our reference architecture is a mechanism for the centralized Quantum controller to communicate with various virtual and physical switches to implement the physical connectivity. One possible mechanism for establishing such a communication channel would be to install a Quantum plugin agent on every Hypervisor that is running a vSwitch as well as on every physical switch that is supported. The agent can then “phone home” to get updates from the centralized Quantum controller. The agent here is responsible for communicating with various switches using the appropriate APIs and establishing L2 connectivity. The agent can choose a mechanism (e.g., VLANs) to create the isolation between packets from different Quantum networks.
For a more detailed view on how to create a Quantum plugin, take a look at the Open Source Quantum plug-in that uses Open vSwitch. Or, just wait for the next post … 