Intro to OpenStack Quantum for Cloud Operators

Dan Wendlandt – Quantum Hacker & PTLdan@nicira.com

twitter - danwendlandt

Caveats

• Quantum is young: there are lots of things that it WILL do, but doesn’t yet.

• Target of talk is Cloud Operators that would deploy Quantum.

Outline

• Why Quantum?• What is Quantum? • Current Project Status• Demo!• Future Directions• Questions

Why Quantum?

What is OpenStack?• Open Source Cloud Software…• A collection of “cloud services”• Each service includes: – A tenant-facing API that exposes

logical abstractions for consuming the service.

– One or more backend implementations of that API

In the beginning..

Compute

Storage

Network

Nova

Swift (Objects)

Glance (Images)

?

*-as-a-Service Capability OpenStack Service

Why Quantum?

• Networking was sub-component of Nova• Two Key Problems:

#1: Limited technology “baked in” to design. #2: No tenant control of networking.

Problem #1: Technology Limitations

• Cloud stresses networks like never before: – High-density multi-tenancy, massive scale– Strict uptime requirements.– Integrate with legacy hosting environments /

remote data centers.– VM mobility

• Nova provides only basic technologies: – VLANs are only option for multitenancy– Linux Bridge only– “network controller” node is centralized

single-point of failure for large networks.

Who needs private networks?

Trunking all VLANs is a great idea!

- Stone Age Man

Why Quantum? #1: Leveraging Advanced Technologies

• New networking technologies are emerging to try and tackle these challenges.– Software-defined Networking (SDN) / OpenFlow– Overlay tunneling: VXLAN, NVGRE, STT– Fabric solutions: FabricPath, Qfabric, etc. – [ insert other solution here ]

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

• Choice is a good thing!

Problem #2: No Tenant Control

“You can have any color as long as its black.“- Henry Ford about the Model-T

• Cloud tenants want to replicate rich enterprise network topologies: – Ability to create “multi-tier” networks (e.g.,

web tier, app tier, db tier) – Control over IP addressing. – Ability to insert and configure your own

services (e.g., firewall, IPS)– VPN/Bridge to remote physical hosting or

customer premises (“cloudbursting”).

• Nova provides no tenant control: – No way to control topology.– Cloud assigns IP prefixes + addresses. – No generic service insertion.

Why Quantum? Reason #2On-demand Enterprise-Class Networking

• Tenants can: – create multiple private networks– control IP addressing (bring your own!).

• Quantum API extensions enable additional control:– Security, Quality-of-Service, Monitoring +

Troubleshooting.

• “Advanced Network Services”– Routers, Firewalls, VPN, IDS, etc.

Finally, Network-as-a-Service!

Compute

Storage

Network

Nova

Swift (Objects)

Glance (Images)

*-as-a-Service Capability OpenStack Service

Quantum

Why Quantum?

Quantum enables advanced network “engines”….

that let you leave Amazon VPC in the dust…

Why Quantum?

Questions?

What is Quantum?

Quantum Basics (by analogy to Nova)Nova Quantum

*-as-a-service Compute Network

Major API abstractions “virtual servers”: represents a host with CPU, memory, disk, and NICs.

“virtual networks”: A basic L2 network segment.“virtual ports”: Attachment point for devices connecting to virtual networks.

Interactions with other OpenStack services.

virtual servers use “virtual images” from Glance.

virtual ports are linked to vNICs on “virtual servers”.

Supports different back-end technologies

“virt-drivers” for KVM, XenServer, Hyper-V, VMWare ESX

“plugins” for Open vSwitch Cisco UCS, Linux Bridge, Nicira NVP, Ryu Controller (and more!).

API Extensibility for new or back-end specific features.

keypairs, instance rescue, volumes, etc.

quality-of-service, port statistics, security groups, etc.

Basic API Abstractions

Net110.0.0.0/24

VM110.0.0.2Nova

Quantum virtual network

VM210.0.0.3

virtual port

virtual server

virtual interface (VIF)

“virtual networks” are fundamentally multi-tenant, just like virtual servers.

Quantum API Extensions• Enables innovation in virtual networking.

• Add properties to existing network/port abstractions (e.g., QoS settings on virtual port, port statistics).

• Can introduce new API entities (e.g., Security

Groups that are linked to ports).

Old Model: Static Nova Networking

Public Net88.0.0.0/18

• Single network exists (per-project or global). • VMs automatically get a vNIC on that single network on boot. • Tenants have no control over IP addressing.

TenantA-VM188.0.0.2

TenantB-VM188.0.0.3

TenantA-VM288.0.0.4

TenantA-VM388.0.0.5

Quantum Model: Dynamic Network Creation + Association

TenantA-VM110.0.0.2

TenantA-VM39.0.0.2

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

TenantA-VM210.0.0.3 9.0.0.3

Load Balancer

Public Net88.0.0.0/18

Tenant-A Net110.0.0.0/24

Tenant-A Net29.0.0.0/24

• “Plugin” model give cloud operators choices: – Advanced Features (exposed as API extensions)– Cost / open vs. propriety– Scale – High Availability – Hypervisor + Network HW Compatibility – Manageability / Polish

• Abstract logical API – tenants don’t see underlying technologies– Example: VLANs vs. tunneling

Quantum “Plugins”

Current Project Status

Project Status: Essex Cycle• Started at Diablo summit, “incubated” for Essex, “core” in Folsom. • Available at: http://launchpad.net/quantum• http://docs.openstack.org/incubation/openstack-network/admin/content/• Current Capabilities:

– v1.1 of the Quantum L2 API, with extension support. – API client library and CLI – Nova Integration via the QuantumManager (DHCP, L3/NAT)– Plugin framework & several publicly available plugins:

• Open vSwitch Plugin• Cisco UCS/Nexus Plugin • Linux Bridge Plugin• Nicira Network Virtualization Platform (NVP)• Ryu OpenFlow Controller

– Integrated with “devstack” (see: http://wiki.openstack.org/QuantumDevstack)– Packaging for Ubuntu 12.04 / Fedora 17 / Debian .

Project Status: Two Deployment Models

• Admin-facing Quantum (available now): – 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, but doesn’t give tenant’s network control.

• Tenant-facing Quantum (Folsom Target): – Tenants can create their own networks, determine their own IP

addressing via Quantum API. – Tenants can insert other logical services exposed by service

provider (e.g., router, VPN) using extensions.

Project Status: Is Quantum “Ready”?

• “Early adopters” already putting Quantum into production deployments (using Essex).

• Many more are testing it out.

• Folsom release is target for general adoption. Planned to be default networking option.

OpenStack networking Panel today @ 3:50 in

Seacliff AB

Interested in a demo? Let me

know!

Future Directions

Folsom Priorities: Tenant Control

• Enabling tenant-facing network control.– Keystone Integration – New 2.0 API (with IP address management)– Horizon Integration– Improved CLI

Folsom Priorities: Network Services

• Quantum is not just about L2 networks.

• Essex already supports simple service insertion as VMs

• Enable Quantum APIs for advanced services: – Quantum API extensions to control “service”.– Pluggable back-end implementations.

• Achieve “Nova Parity” with L3/NAT + DHCP services:– plugins can eliminates single-point-of-failure and bottlenecks of

existing nova-network implementations!– Programmatically build rich L2 + L3 topologies.

Service Example: “virtual NAT router”

• API to create/manage “instances” – POST /router/• Create router, specify NAT/forwarding configuration.

– PUT /router/<uuid> • Modify router later.

– POST /router/<uuid>/interface• Specify network that this interface is attached to.

• On demand creation of rich L2+L3 topologies.

Folsom Priorities: Growing the Quantum Community

• Growing Development team

• Networking Vendors: – Many planning new plugins.

• OpenStack Integrators/Distros: – Get them up to speed on Quantum early. – Improve packaging, install processes.

• OpenStack Users/Operators: – Improving documentation, help + support channels. – Let’s work together to stand it up!

Key Takeaways• Enterprise-class OpenStack networking is here:– Leveraging advanced technologies.– Tenant control of networking.

• Enable you as a cloud operator to not just copy Amazon VPC, but to innovate beyond that.

• Quantum is in production today at early adopters.

• Folsom is target for widespread deployment.

Thanks!Questions?

Dan Wendlandt – Quantum Hacker & PTLdan@nicira.com

twitter - danwendlandt

Bonus Slides

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.

Plugins: A tiny bit of technical detail…

• Define “quantum plugin”: Code that communicates with network devices to implement a particular set of Quantum API calls.

• API currently has one set of calls for “base L2” networking => one plugin running at a time.

• A plugin is not a “driver”. A single plugin can talk to different types of network devices.

• Future: will support multiple plugins that expose different APIs (e.g., “virtual networks” vs. “virtual firewalls”)

Nova ComputeNova Compute

Nova ComputeNova Compute

Quantum Architecture (simple)

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

API Extensions DB

Nova ComputeNova Compute

Nova ComputeNova Compute

Quantum Architecture (advanced)

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

External Manager

DB

DBAPI

Extensions

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

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

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.