quantum ptl update - grizzly summit.pptx

OpenStack Quantum:Taking OpenStack Networking to New Heights

Dan Wendlandtdan@nicira.com

dwendlandt@vmware.com Openstack Quantum Hacker & Project Team Lead

twitter - danwendlandt

Aaron Rosen, Quantum core dev at VMware, show his OpenStack Quantum team pride.

Outline

• Why Quantum?• What is Quantum? – API Abstractions– Plugin Architecture

• Project Status• Deployment Scenarios• Looking Forward• Questions

Why Quantum?

Networks for Enterprise Applications are Complex….

Image from windowssecurity.com

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

• Quantum has Tenants API to: – create multiple private L2

networks– control IP addressing (can use

same IP space as existing datacenter deployment)

– Connect to an upstream router for external access.

– Insert advanced network services: routers, firewalls, VPN, IDS, etc.

– Monitor network status

L2

L3

L2

L2

L2

Internet

L3

L3

L3

Cloud Stresses the Network….

• High-density multi-tenancy– But VLANs limit scale

• On-demand provisioning– But traditional network solutions have interfaces designed for manual

configuration. • Need to place / move workloads were capacity exists

– But network state (e.g., IP address) is tied to a particular location

Why Quantum? #2: Leveraging Advanced Technologies

• New networking technologies are emerging to try and tackle these challenges.– Network virtualization– Overlay tunneling: VXLAN, NVGRE, STT– Software-defined Networking (SDN) /

OpenFlow– L2 Fabric solutions: FabricPath, Qfabric, etc. – [ insert other solution here ]

• Quantum provides a “plugin” mechanism to enable different technologies (more later).

What is Quantum?

Quantum Architecture

A generic tenant API to create and

configure “virtual networks”

A “plugin” architecture with different back-end

“engines”

An eco-system of tools that leverage the Quantum API.

Tenant Tools(GUI, CLI, API code)

Compute API

Network API

Storage API

Generic OpenStack APIs Operator Selected Backends

KVM

OVS Plugin

Ceph

Basic API Abstractions

Net110.0.0.0/24

VM110.0.0.2Nova

Quantum L2 virtual network

VM210.0.0.3

virtual port

virtual server

virtual interface (VIF)

“virtual networks” and “virtual subnets” are fundamentally multi-tenant, just like virtual servers (e.g., overlapping IPs can be used on different networks).

virtual subnet

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” that provide more

advanced network functionality (e.g., routing + NAT).

TenantA-VM210.0.0.3 9.0.0.3

Router

External Net88.0.0.0/18

Tenant-A Net110.0.0.0/24

Tenant-A Net29.0.0.0/24

Quantum API Extensions• Enables innovation in virtual networking.

– Tenants can query API to programmatically discover supported extensions. – Overtime, extensions implemented by many plugins can become “core”.

• Add properties on top of existing network/port abstractions:

– QoS/SLA guarantees / limits

– Security Filter Policies

– port statistics / netflow

• New Services– L3 forwarding, ACLs + NAT (“elastic” or “floating” IPs)– VPN connectivity between cloud and customer site, or another cloud datacenter.

Quantum Architecture

A generic tenant API to create and

configure “virtual networks”

A “plugin” architecture with different back-end

“engines”

An eco-system of tools that leverage the Quantum API.

Tenant Tools(GUI, CLI, API code)

Compute API

Network API

Storage API

Generic OpenStack APIs Operator Selected Backends

KVM

OVS plugin

Ceph

Tenant Scripts

Horizon GUI

Orchestration Code

API Clients Quantum Service

PluginX

Quantum API

Create-net...

Create-port

Uniform API for all clients

API Extensions

Nova Compute

virtual switch

Interfaces from Nova plug into a switch manages by

the Quantum plugin.

Physical Network

Backend X

Quantum Architecture (generic)

World’s simplest Quantum Plugin*

• API request is dumped into an email, send to your network administrator.

• Administrator manually configures network connectivity.

* Not recommended for use… ever!

• Different back-end “engines” present different trade-offs: – Scalability– Forwarding performance– Hypervisor Compatibility– Network HW Compat (vendor specific? Allow L3 scale-out?)– Manageability / troubleshooting– Advanced Features (exposed as API extensions)– Production testing– High Availability (control & data plane)– Open source vs. Free vs. Paid

• Cloud Operators weigh trade-offs, choose a plugin.

• Note: Back-end technology hidden behind logical core API – Example: VLANs vs. tunneling

Quantum Plugins Trade-offs

Quantum PluginsOpen source plugins based on Open vSwitch and Linux Bridge exist (works with any hardware switches).

The following vendors have publicly stated that they already have or are developing a Quantum plugin (others exist as well). In some cases, vendor hardware is required.

Project Status

A Growing Team…

6 Months Ago…

• Incubation release (Essex, April ‘12)– v1 API, basic L2 API abstractions. – Quantum API used by nova-network, but not

exposed to tenants.– Plugin architecture to enable choice of back-end

technology.– In production at early adopters.

Today• First “core” release (Folsom, Oct. ‘12)– v2 API, with L2 + IP address mgmt (IPAM)– Tenant API with Keystone + Horizon Integration– Updated CLI– Extensions: • L3 “routers” w/floating IPs• “provider networks” mapped to specific VLANs• Tenant quotas• Notifications

Tenant Network Control (Horizon)

Tenant Network Control (Horizon)

Tenant Network Control (Horizon)

What’s going to happen to nova-network?

• No forced upgrade in Folsom, or Grizzly.• Existing nova-network stays even with

Quantum in core. • Planning an “orderly transition”

1) Freeze on adding new functionality in nova-network (already in effect).

2) Make sure Quantum covers all important nova-network scenarios (target Grizzly)

3) Nova MAY simplifying nova-network code by removing all but basic networking support in subsequent release (possible target H-release)

Should I start using Quantum?

• Go back to reasons project was created: – API to build rich network topologies, insert

services.– Overcome limitations of traditional networking

solutions (e.g., VLANs). • If these are important to your OpenStack

deployment, go for it!• Otherwise staying with nova-network is fine.

Taking Quantum for a spin..

• Admin Documentation: – http://docs.openstack.org/trunk/openstack-netwo

rk/admin/content/

– Ubuntu and Red Hat deployments covered.– Please read the entire doc… if something is still

unclear, send email to the list• Or use Devstack– http://wiki.openstack.org/QuantumDevstack

Get Hands On!

Hands on Quantum Deployment WorkshopThursday 9:00 – 10:30 am @ Manchester E

Deployment Use Cases

Basic Physical Network Connectivity

Two API Deployment Models

• Cloud Operator creates networks for tenants– Quantum API is admin only, tenants do not use it. – Similar to nova-network model, but with flexibility around network

topology, IP addressing, etc.

• Expose API to tenants directly– True “self-service networking”.– Tenants use scripts, CLI, or web GUI to manage networks & subnets.

• Can also mix-and-match strategies– Provider creates default network connectivity, tenants can choose to

extend.

Single Flat Network

Similar to Nova-network Flat or FlatDHCP manager.

Multiple Flat Networks

Mixed Flat + Private Networks

Single Provider Router

Similar to Nova-network VlanManager.

Per-Tenant Routers

Similar to Amazon VPC or CloudStack model.

Looking Forward

Grizzly Quantum: where are we going?

• Closing gaps: – Security groups & metadata

service compatible with overlapping IPs.

– Support L3-forwarding & DHCP on compute nodes (similar to nova “multi_host” flag)

• Advanced Services– Load-balancing– VPN

Talks by Quantum Users @ Summit

Wed @ 9:30 am

Wed @ 11:00 am

Wed @ 2:40 pm

Wed @ 4:10 pm

Includes production Quantum

deployments that have been running for 6+

months on Essex!

Key Takeaways

• Quantum enables advanced networking in OpenStack: – API to configure rich network topologies. – Plugin architecture for leveraging new network

technologies. • With “core” status, expect jump in Quantum

production deployments in Folsom. • Quantum team is growing quickly, come join!

Thanks! Questions?

Dan Wendlandtdan@nicira.com

dwendlandt@vmware.comOpenStack Quantum Hacker & Project Team Lead

twitter - danwendlandt

Slides available at: http://www.slideshare.net/danwent