OpenStack, Quantum and Open vSwitch – Part II
[Originally published on Openvswitch.com/openstack/blog by Somik Behera & others. 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
The goal of Quantum is simple, to provide a clean network service abstraction within OpenStack. While we’ll get into the particulars below, here is a cheat sheet of some of the benefits its design offers:
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
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’s primary interface is a programmatic RESTful API. The abstractions over which it operates are, by design, extremely simple.
The Quantum API allows for creation and management of “virtual networks” each of which can have one or more “ports”. A port on a virtual network can be attached to a “network interface”, where a “network interface” is anything which can source traffic, such as a vNIC exposed by a virtual machine, an interface on a load balancer, and so on. These abstractions offered by Quantum (virtual networks, virtual ports,and network interfaces) are the building blocks for building and managing logical network topologies.Of course, the technology that implements Quantum is fully decoupled from the API (that is, the backend is “pluggable”).
So, for example, the logical network abstraction could be implemented using simple VLANs, L2-in-L3 tunneling, or any other mechanism one can imagine and build. The only requirement is that the actual implementation provide the L2 connectivity described by the logical model.While the native Quantum API does not support more sophisticated network services such as, say, QoS or ACLs, it does provide an API extensibility mechanism that plugins can use to expose them. This is the conduit by which developers and vendors in the OpenStack ecosystem can innovate within Quantum. If an extension proves useful and generally applicable, it may become a part of the core Quantum API in a future version.
There are 3 key functional layers of abstraction that make up the Quantum service:
1) REST API layer: This layer is responsible for implementing the Quantum API and routing API requests to the correct end-point within Quantum’s pluggable infrastructure. The REST API layer also contains various infrastructure glue around launching the Quantum service, marshalling & unmarshalling requests and responses, and validating data format & data correctness. This layer can also contain security and stability infrastructure such as rate-limiting logic on inbound API calls to protect against Denial of Service attacks and make sure that the Service remains responsive under load.
REST API Extensions: Quantum provides an “extensibility” mechanism that enables anybody to extend the Core API and add additional features and functionality that are not currently part of the Core API. Taking today’s Core API as an example, one could use the extensibility mechanism to create a QoS extension that enables setting up Quality of Service parameters associated with Quantum networks. Similarly, you can imagine multiple parties can easily integrate advanced networking functionality using Quantum’s extensibility mechanism. Quantum community is actively working on implementing the extensibility framework (to follow the progress, check out the blueprint here).
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
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 … :)
andulkaphoto
romaincrisis
tangentwithtanner
origamiaround
izzy806
baratheonpilled
yousharknotpass
discoholicmusic