Quantum (OpenStack Meetup Feb 9th, 2012)
-
Upload
dan-wendlandt -
Category
Technology
-
view
4.171 -
download
3
description
Transcript of Quantum (OpenStack Meetup Feb 9th, 2012)
Intro to OpenStack Quantum
Dan Wendlandt – Quantum Hacker & [email protected]
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
Twitter: danwendlandthttp://www.slideshare.net/danwent/