quantum (openstack meetup feb 9th, 2012)
DESCRIPTION
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
![Page 1: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/1.jpg)
Intro to OpenStack Quantum
Dan Wendlandt – Quantum Hacker & [email protected]
twitter - danwendlandt
![Page 2: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/2.jpg)
Outline
• 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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/3.jpg)
Why Quantum?Reason #1
![Page 4: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/4.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/5.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/6.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/7.jpg)
Why Quantum?Reason #2
![Page 8: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/8.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/9.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/10.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/11.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/12.jpg)
What is Quantum?
![Page 13: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/13.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/14.jpg)
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>
![Page 15: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/15.jpg)
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
![Page 16: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/16.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/17.jpg)
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
![Page 18: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/18.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/19.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/20.jpg)
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
![Page 21: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/21.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/22.jpg)
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
![Page 23: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/23.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/24.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/25.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/26.jpg)
Current Project Status
![Page 27: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/27.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/28.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/29.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/30.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/31.jpg)
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/
![Page 32: Quantum (OpenStack Meetup Feb 9th, 2012)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/32.jpg)
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)](https://reader031.vdocuments.net/reader031/viewer/2022020115/55515037b4c905f2288b5493/html5/thumbnails/33.jpg)
Thanks! Questions / Comments?
Come join us:http://wiki.openstack.org/Quantum
Twitter: danwendlandthttp://www.slideshare.net/danwent/