OpenStack Quantum: Taking OpenStack Networking to New Heights Dan Wendlandt firstname.lastname@example.org email@example.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
Networks for Enterprise Applications are Complex…. Image from windowssecurity.com
Why Quantum? Reason #1 On-demand Enterprise-Class Networking • Quantum has Tenants API to: Internet – create multiple private L2 L3 networks L2 – control IP addressing (can use L3 same IP space as existing L2 datacenter deployment) L3 – Connect to an upstream router L2 for external access. L3 – Insert advanced network services: routers, firewalls, VPN, IDS, etc. L2 – Monitor network status
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 Generic OpenStack APIs Operator Selected Backends Co C m o put m e put e AP A I KVM KV Ne N t e wo w r o k r k AP A I OV O S V S Plugin Tenant Tools (GUI, CLI, Sto t r o a r ge g e AP A I Ce C ph p API code) An eco-system of A generic tenant API A “plugin” architecture tools that leverage to create and with different back-end the Quantum API. configure “virtual “engines” networks”
Basic API Abstractions VM V 1 VM2 virtual server Nova VM2 10. 10 0. 0 0. 0 2 10 1 . 0 0.0. 0. 3 0. virtual interface (VIF) virtual port Quantum Net e 1 t L2 virtual network 10.0.0.0/24 virtual subnet “virtual networks” and “virtual subnets” are fundamental y multi-tenant, just like virtual servers (e.g., overlapping IPs can be used on different networks).
Quantum Model: Dynamic Network Creation + Association Te T na n nt n A-V A M -V 1 TenantA-VM2 Te T na e nt n A-V A M -V 3 TenantA-VM2 10. 1 0. 0. 0. 0 2 10.0.0.3 18.104.22.168 9.0. 9. 0. 0. 2 10.0.0.3 22.214.171.124 Te T nan a t n -A t Ne N t e 1 t Te T nan a t n -A t Net e 2 t Rou R te t r 10.0 10. .0 . .0/ . 24 9.0.0 0. .0 . /24 / Ext E e xt rn r al a Ne N t e 126.96.36.199/1 0/ 8 • 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).
Quantum API Extensions • Enables innovation in virtual networking. – Tenants can query API to programmatical y 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 Generic OpenStack APIs Operator Selected Backends Co C m o put m e put e AP A I KVM KV Ne N t e wo w r o k r k AP A I OV O S V plugin Tenant Tools (GUI, CLI, Sto t r o a r ge g e AP A I Ce C ph p API code) An eco-system of A generic tenant API A “plugin” architecture tools that leverage to create and with different back-end the Quantum API. configure “virtual “engines” networks”
Quantum Architecture (generic) API Clients Quantum Service Backend X Qua Q nt n um um AP A I Te T n e ant an t Cr C e r a e t a e t -net e Scr c ipt p s t . Ho H rizo iz n n . Plugi ug n . GUI X . Create-port Phy Ph s y ica c l a Or O c r h c e h st s r t a r tio a n n Create-port vi v rtu t al swi s tc t h c h Co C de d Ne N t e w t or w k or Nov o a v C a ompu p t u e t AP A I Ext E e xt n e sions Interfaces from Nova plug Uniform API into a switch manages by for all clients the Quantum plugin.
World’s simplest Quantum Plugin* • API request is dumped into an email, send to your network administrator. • Administrator manual y configures network connectivity. * Not recommended for use… ever!
Quantum Plugins Trade-offs • Different back-end “engines” present different trade-offs: – Scalability – Forwarding performance – Hypervisor Compatibility – Network HW Compat (vendor specific? Al ow 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 Open 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 wel ). In some cases, vendor hardware is required.
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.
Get Hands On! Hands on Quantum Deployment Workshop Thursday 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.
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 Includes production Wed @ 11:00 am Quantum deployments that have been Wed @ 2:40 pm running for 6+ months on Essex! Wed @ 4:10 pm
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!