Intro to OpenStack Quantum

Dan Wendlandt – Quantum Hacker & PTLdan@nicira.com

twitter - danwendlandt

Outline

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

• Current Project Status• Future Directions• Frequently Asked Questions

Why Quantum?Reason #1

Enterprise applications have sophisticated networking requirements

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

Traditional “clouds” provide little/no network control.

Example of Nova Network “multi-NIC”.

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

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.

Why Quantum?Reason #2

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

New approaches are looking to tackle these issues

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

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!

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!

What is Quantum?

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.

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:

quantum.foo.com/<tenant-id>/network/<network-id>/port/<port-id>

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’ }

Success

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

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

Internet

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.

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.

Nova ComputeNova Compute

Nova ComputeNova Compute

Nova Compute

Quantum Architecture

Tenant Scripts

Horizon

Nova

API Clients Quantum Server

Quantum Plugin

Create-net...

Create-port

virtual switch

Internal plugin communication.

Quantum API

Create-net...

Create-port

Interfaces from a service like Nova plug into a

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

Uniform API for all clients

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.

Example Quantum + Nova ArchitectureDashboard /

Automation Tools

Nova Service

XenServer #1

Quantum Pluginnova-api

Hypervisor

vswitch

nova-scheduler

nova-compute

Tenant API Tenant API

Internal PluginCommunication

Internal novaCommunication

Quantum APIQuantumService

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

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….

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.

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).

Current Project Status

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.

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.

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.

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.

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-

network/admin/content/

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.

Thanks! Questions / Comments?

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

netstack@lists.launchpad.net

Dan WendlandtDan@nicira.com

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