OpenStack's Quantum network service project is an early attempt to define a common, simple abstraction of an OSI Layer 2 network segment. What does that abstraction look like, and how does Quantum allow the networking market to flourish and innovate under such a simple concept?
OpenStack itself is an open-source project that aims to deliver a massively scalable cloud operating system, the software that coordinates how infrastructure (such as servers, networks, and data storage) are delivered to the applications and services that consume that infrastructure. Easily the largest open-source community in this space--others include Eucalyptus andCloudStack--OpenStack consists of three core projects:
- Nova: a compute service that delivers virtual servers (or, theoretically, bare metal servers) on demand via an application programming interface, much like Amazon Web Service's EC2 compute service
- Swift: an object storage service that operates much like Amazon's S3 service
- Glance: a virtual machine image management service
Quantum is one of the new so-called incubation projects within OpenStack. The Quantum wiki page describes the project in the following terms:
Quantum is an incubated OpenStack project to provide "network connectivity as a service" between interface devices (e.g., vNICs) managed by other Openstack services (e.g., nova).
In other words, Quantum provides a way to manage links between the virtual network cards in your virtual machines, similar devices in network services (such as load balancers and firewalls), and other elements, such as gateways between network segments. It's a pretty straightforward service concept.
How does Quantum achieve this goal? Through a network abstraction, naturally. In part 1 of this series, I noted how the basic accepted model of the network in cloud computing is some simple network abstractions delivered by advanced physical networking infrastructure. Quantum addresses this model directly.
First, the abstraction itself. Quantum's abstraction, as pictured below, consists of a very simple combination of three basic components:
- A network segment, which represents a connection space through which interfaces can communicate with each other.
- Ports, which are simple abstractions of connection points to the network segment, and which have configurable traits that define what kinds of interfaces they support, who can connect to the port, and so on.
- Virtual interfaces (or VIFs), which are the (typically virtual) network controllers that reside on a virtual machine, network service appliance, or anything else that wants to connect to a port on the network segment.
The Quantum network abstraction
(Credit: James Urquhart)
Quantum itself is made up of two elements: the service itself, and a plug-in (typically vendor or technology specific).
Quantum's architecture
(Credit: James Urquhart)
The Quantum service handles managing network definitions, and things like making sure users are authorized to perform a given function. It provides an API for the management of network segments, and an API for plug-ins.
A plug-in owns every action necessary to map the abstractions to the physical networking it is managing. Today, there are two plug-ins in the official Quantum release: one for Open vSwitch, and one for Cisco's Nexus switches via the 802.1Qbh standard. Other vendors are reportedly creating additional plug-ins to be released with the next OpenStack release.
It is important to note that this separation of concerns between abstraction management and abstraction implementation allows for any abstraction defined solely on core Quantum elements and APIs to be deployed on any Quantum instance, regardless of the plug-in and underlying networking technologies.
Of course, there are mechanisms to allow vendors and technologists to extend both the API and the abstractions themselves where innovation dictates the need. Quantum hopes to evolve its core API based in part on concepts identified through the success of various plug-in extensions. This feedback loop should allow for the relatively rapid evolution of the service and its APIs based on market needs.
Quantum isn't finished, though. Today's implementation is entirely focused on OSI Layer 2 mechanisms--the next version is going to focus on network service attachment (for things like load balancers, firewalls, and so on), as well as other critical Layer 3 concepts, such as subnets, addressing, and DNS.
You might be asking how Quantum relates to software-defined networking, the now hot trend in network architecture that separates control of the network from the devices that deliver packets to their destination. In part 3 of this series, I'll describe how technologies such as OpenFlow fit into the network virtualization picture.
No comments:
Post a Comment