Quantum (OpenStack Meetup Feb 9th, 2012)

Intro to OpenStack Quantum Dan Wendlandt – Quantum Hacker & PTL [email protected] twitter - danwendlandt


This is a talk I gave on Quantum at the Bay Area OpenStack Meetup on Feb 9th, 2012. I added a few slides to try and address some of questions people had during the talk.

Transcript of Quantum (OpenStack Meetup Feb 9th, 2012)

Page 1: Quantum (OpenStack Meetup Feb 9th, 2012)

Intro to OpenStack Quantum

Dan Wendlandt – Quantum Hacker & [email protected]

twitter - danwendlandt

Page 2: Quantum (OpenStack Meetup Feb 9th, 2012)


• Why Quantum?• What is Quantum? – API– High-level System Components

• Current Project Status• Future Directions• Frequently Asked Questions

Page 3: Quantum (OpenStack Meetup Feb 9th, 2012)

Why Quantum?Reason #1

Page 4: Quantum (OpenStack Meetup Feb 9th, 2012)

Enterprise applications have sophisticated networking requirements

Image curtsey of “the Hoff”: http://rationalsecurity.typepad.com/blog/2008/08/all-your-virtua.html

Page 5: Quantum (OpenStack Meetup Feb 9th, 2012)

Traditional “clouds” provide little/no network control.

Example of Nova Network “multi-NIC”.

Each VM gets VIF on same two networks, regardless of tenant.

Page 6: Quantum (OpenStack Meetup Feb 9th, 2012)

Why Quantum? Reason #1

• To attract enterprise workloads, cloud must give tenants the tools + control for enterprise-class networking.– Rich multi-tier topologies– Insert services (FW, VPN, IDS, etc.) – QoS guarantees for SLAs– Security & Monitoring for compliance

• Quantum API can allows user control to build advanced networking configurations.

Page 7: Quantum (OpenStack Meetup Feb 9th, 2012)

Why Quantum?Reason #2

Page 8: Quantum (OpenStack Meetup Feb 9th, 2012)

Cloud Networking Challenges

• Cloud environments stress networks like never before: – High-density multi-tenancy– Massive scale– Strong price pressure. – VM mobility– EVERYTHING must be automated

Page 9: Quantum (OpenStack Meetup Feb 9th, 2012)

New approaches are looking to tackle these issues

• Software-Defined Networking / OpenFlow• VXLAN / NVGRE• [ insert other solution here…. ]

Page 10: Quantum (OpenStack Meetup Feb 9th, 2012)

Why Quantum? Reason #2

• New technologies are needed to cope with new challenges in cloud networking.

• Existing Nova implementation used basic Linux Bridge + VLANs (very limiting)

• Quantum provides a “plugin” mechanism to enable different technologies implement calls made via the Quantum API.

• Choice is a good thing!

Page 11: Quantum (OpenStack Meetup Feb 9th, 2012)

Why Do You Care?

• Cloud Provider / OpenStack consultants: Help understand how Quantum can overcome limitations of existing Nova networking.

• Network Vendor: learn how you can integrate with or contribute to Quantum.

• Cloud User: Help is on the way!

Page 12: Quantum (OpenStack Meetup Feb 9th, 2012)

What is Quantum?

Page 13: Quantum (OpenStack Meetup Feb 9th, 2012)

Quantum Basics

Nova : virtual serverQuantum : virtual network

Quantum is:- Expose a API for creating virtual networks and attaching

instances (e.g., nova servers) to those networks. - Manage switches (virtual or physical) in the data center to

implement connectivity described via API.- Provide a “plugin” architecture to leverage support using

different back-end technologies.

Page 14: Quantum (OpenStack Meetup Feb 9th, 2012)

Quantum API Abstractions

• Networks:– Equivalent to a “virtual VLAN”, a dedicated L2 segment. – Tenants use Quantum API to create networks, get back UUID: – Example: quantum.foo.com/<tenant-id>/network/<network-id>

• Ports:– When an interface (e.g., Nova vNIC) is attached to a network, attachment

point is a “port”. – Ports expose configuration and monitoring state (e.g., ACLs, QoS policies,

Packet Statistics)– Example:


Page 15: Quantum (OpenStack Meetup Feb 9th, 2012)

Basic Quantum + Nova API FlowAPI Client Quantum Server

Create Network (POST /tenant1/network)

Network UUID: ‘abc’

Create Server (POST /tenant1/server)

Nova Server

Server UUID: ‘def’

Get Server Interface(s) (GET /tenant1/server/def/interface)

Server Interface UUID List: [ ‘ghi’ ]

Create Port on Network (POST /tenant1/network/abc/port)

Port UUID ‘jkl’

Attach Interface to port (PUT /tenant1/network/abc/port/jkl) { ‘attachment’ : ‘ghi’ }


Page 16: Quantum (OpenStack Meetup Feb 9th, 2012)

Old Model: Static Nova Networking

Tenant-A Net

• Single network exists (per-project or global).

• VMs automatically get a vNIC on that single network on boot.

Nova i-2310.0.0.23

Nova i-2610.0.0.26

Nova i-2210.0.0.22

Nova i-2410.0.0.24

Page 17: Quantum (OpenStack Meetup Feb 9th, 2012)

New Model: Dynamic Network Creation + Association

Tenant-A Net #1

Tenant-A Net #2

Nova i-2310.0.0.23

Nova i-2610.0.0.26

Nova i-2210.0.0.22

Nova i-2410.0.0.24

• Tenant can use API to create many networks.• When booting a VM, define which network(s) it

should connect to.• Can even plug-in instances from other services

(e.g., a load-balancing service).

Load Balancer


Page 18: Quantum (OpenStack Meetup Feb 9th, 2012)

Quantum API Principles

• Implementation Abstraction: At no time does the customer see details of how a network is implemented (e.g., VLANs).

• Explicit Association: Association of interfaces with network is an explicit step more control.

• API Extensions: Plugins can expose API extensions to introduce more complex functionality (e.g., QoS). Extension support is queriable, so a customer can “discover” capabilities.

• Extension Refactoring: API extensions that represent common functionality across many plug-ins can become part of the core API.

• API Evolution: Core API is currently simple, focused on connectivity. Core API will evolve.

Page 19: Quantum (OpenStack Meetup Feb 9th, 2012)

Plugin Architecture

• “Quantum Plugin” design allows abstract network/port API to be implemented using many different technologies.

• Plugins perform two main tasks: – Process all API calls: store the results of all network

+ port calls, while mapping abstract entities to a plugin-specific technology (e.g., map a network to a VLAN)

– Manage switches: learn about nova interfaces when they are attached to the network and configure network switches accordingly.

Page 20: Quantum (OpenStack Meetup Feb 9th, 2012)

Nova ComputeNova Compute

Nova ComputeNova Compute

Nova Compute

Quantum Architecture

Tenant Scripts



API Clients Quantum Server

Quantum Plugin



virtual switch

Internal plugin communication.

Quantum API



Interfaces from a service like Nova plug into a

switch manages by the Quantum plugin. API + Plugin = Quantum Service

Uniform API for all clients

Page 21: Quantum (OpenStack Meetup Feb 9th, 2012)

Simple VLAN Plugin Example

• Plugin assumes all VLANs are trunked to all hypervisors (similar to nova-network)

• When new q-network is created, creates a DB entry mapping network to a free VLAN.

• Stores port + attachment mappings in DB. • Runs agent on hypervisor to recognize new vswitch

ports that represent Nova interfaces. • When new vswitch port appears, finds q-port + q-

network associated with interface-id, configures vswitch port with correct VLAN.

Page 22: Quantum (OpenStack Meetup Feb 9th, 2012)

Example Quantum + Nova ArchitectureDashboard /

Automation Tools

Nova Service

XenServer #1

Quantum Pluginnova-api





Tenant API Tenant API

Internal PluginCommunication

Internal novaCommunication

Quantum APIQuantumService

Two Plugins Available:- Open vSwitch- Cisco UCS/Nexus

Page 23: Quantum (OpenStack Meetup Feb 9th, 2012)

Key Take-away

• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *

* Explained on next slide….

Page 24: Quantum (OpenStack Meetup Feb 9th, 2012)

A plugin is not a driver

• A plugin registers to handle all Quantum API calls in a “group” (e.g., all network/port calls).

• Because Quantum only has one “group” of API calls right now, only one plugin runs at a time (this will change as APIs expand beyond L2).

• A single plugin may talk to multiple types of switches (i.e., it may have multiple “drivers”)

• “driver” code can be shared across plugins.

Page 25: Quantum (OpenStack Meetup Feb 9th, 2012)

Why separate plugins + drivers?

• Plugins may make decisions that are technology, but not device-specific (e.g., mapping q-network ‘foo’ to VLAN 99).

• That decision must be made by only a single entity… if multiple such decisions were made by different plugins, they likely would conflict.

• The plugin may use drivers to communicate the results of this decision to different devices (e.g., it may configure the VLAN on a vswitch port, and tell the upstream physical switch to trunk that VLAN).

Page 26: Quantum (OpenStack Meetup Feb 9th, 2012)

Current Project Status

Page 27: Quantum (OpenStack Meetup Feb 9th, 2012)

Project Status: Essex Cycle• Started at Diablo summit, became “incubation” for Essex, will

apply to be “core” in Folsom. • Available at: http://launchpad.net/quantum• Docs at: http://docs.openstack.org/incubation/• Current Features:

– v1.1 of the Quantum L2 API, with extension support. – API client library and CLI – Nova Integration via the QuantumManager– OpenStack Dashboard Integration (a bit borked right now…)– Plugin framework & two publicly available plugins:

• Open vSwitch Plugin• Cisco UCS/Nexus Plugin • Linux Bridge Plugin

– Packaging for Ubuntu / Red Hat / Debian + more.

Page 28: Quantum (OpenStack Meetup Feb 9th, 2012)

Project Status: Two Deployment Models

• Model #1 (available now): – QuantumManager in Nova is only Quantum API client. – Cloud admin must define networks with nova-manage. – Tenant can place VMs on different networks using nova extension

(--nic option in nova client).– Allows cloud provider to leverage advanced networking

technologies. • Model #2 (few months out):

– Tenants can create their own networks, determine their own IP addressing via Quantum API.

– Tenants can insert other services exposed by service provider (e.g., router, VPN) using extensions.

Page 29: Quantum (OpenStack Meetup Feb 9th, 2012)

Project Status: Who should use Quantum?

• “Early adopters” are already putting Quantum into their OpenStack trial deployments.

• Expect early adopters to go live with Quantum in spring / summer.

• Caution: deployments are by bleeding edge, working closely with someone who knows Quantum well.

• Folsom release will be first target for widespread adoption.

Page 30: Quantum (OpenStack Meetup Feb 9th, 2012)

Future Directions• More L2 Plugins– Linux Bridge, Ryu Controller, Nicira NVP, Brocade

• Beyond L2: Advanced Network Services– L3 routing + NAT, Firewall, VPN, DHCP, LB – Services may be part of Quantum, or separate projects

that integrate with Quantum. – Additional services will be independently pluggable

(i.e., can choose L2 plugin X, L3 plugin Y)• RBAC via API to allow for fine grain controls among

users of the same tenant.

Page 31: Quantum (OpenStack Meetup Feb 9th, 2012)

Play with Quantum

• New integrated with DevStack• http://wiki.openstack.org/QuantumDevstack• Use nova-manage to create networks• Spin up VMs with -- nic option. • See Quantum Administrator Guide for details– http://docs.openstack.org/incubation/openstack-


Page 32: Quantum (OpenStack Meetup Feb 9th, 2012)

Frequently Asked Questions

• Is OpenFlow required for Quantum– A: Nope! OpenFlow is just one technology that

Quantum enables.• Is Quantum “software-defined networking”?– It depends…

• How does Quantum compare to Amazon VPC? – A: Have similar goal of enabling advanced

networking in cloud. Quantum will give cloud operators ability to compete with (and go beyond) VPC feature-set.

Page 33: Quantum (OpenStack Meetup Feb 9th, 2012)

Thanks! Questions / Comments?

Come join us:http://wiki.openstack.org/Quantum

[email protected]

Dan [email protected]

Twitter: danwendlandthttp://www.slideshare.net/danwent/