Openstack Quantum:Virtual Networks for OpenStack<br />Dan Wendlandt – dan@nicira.com<br />
Outline<br />What?<br />Why?<br />How?<br />
What is Quantum?<br />Astandalone Openstackservice<br />Provides network connectivity between a set of network “interfaces...
What is Quantum NOT?<br />Something that provides all network-related processing behavior. <br />Initial focus is on conne...
Example Architecture: Single Service<br />Openstack Dashboard<br />Tenant API<br />Tenant API<br />Quantum Service<br />No...
Example Architecture: Two Services<br />Tenant API<br />Quantum Service<br />Network Edge:<br />Point at which a service “...
Virtual Network Abstractions (1)<br />Services (e.g., nova, atlas) expose interface-IDs via their own tenant APIs to repre...
Virtual Network Abstractions (2)<br />Note:  At no time does the customer see details of how a network is implemented (e.g...
Example Scenario: <br />Nova i-24<br />10.0.0.24<br />Nova i-26<br />10.0.0.26<br />Nova i-22<br />10.0.0.22<br />Nova i-2...
Live Demo…<br />
Why Quantum?<br />API gives ability to create interesting network topologies.<br />Example: create multi-tier applications...
How? Quantum Design Goals<br />Decoupled from nova and other services<br />Communication between quantum and another servi...
How? Inside Quantum<br />Plugin interface maps to “core” tenant API + admin API.<br />“Network agents” running on nova hyp...
Edge Bindings<br />Services that expose interface-IDs must tell quantum where that interface is currently “plugged” into t...
Simple Plug-in Example with VLANs<br />Similar to what Nova does for private networks:<br />One VLAN per “network”.<br />H...
Plans for Diablo timeframe<br />“experimental” Quantum plug-in <br />Plug-in Agnostic: <br />Create API, including way for...
This is Just the Beginning….<br />Our goals within Diablo time frame are well scoped.<br />Quantum is a building block, no...
Many important questions remain:<br />How should knowledge of the network topology and resources/capacity be used to influ...
Upcoming SlideShare
Loading in …5
×

Quantum diablo summary

56,600 views

Published on

Slides from OpenStack Design Summit presentation on the Quantum, a virtual network service.

Published in: Technology
0 Comments
21 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
56,600
On SlideShare
0
From Embeds
0
Number of Embeds
43,517
Actions
Shares
0
Downloads
837
Comments
0
Likes
21
Embeds 0
No embeds

No notes for slide

Quantum diablo summary

  1. 1. Openstack Quantum:Virtual Networks for OpenStack<br />Dan Wendlandt – dan@nicira.com<br />
  2. 2. Outline<br />What?<br />Why?<br />How?<br />
  3. 3. What is Quantum?<br />Astandalone Openstackservice<br />Provides network connectivity between a set of network “interfaces” from other service (e.g., vNICs from compute service, interfaces on a load-balancer service).<br />Exposes API of logical abstractions for describing network connectivity + policy between interfaces. <br />Uses a “plug-in” architecture, so multiple technologies can implement the logical abstractions.<br />Provides a “building block” for sophisticated cloud network topologies.<br />
  4. 4. What is Quantum NOT?<br />Something that provides all network-related processing behavior. <br />Initial focus is on connectivity.<br />Other advanced services like load-balancers, firewalls, etc can “plug” into a network offered by Quantum. <br />IP address management (see next talk on IPAM)<br />Orchestration of multiple network-related building blocks to provide higher-level abstractions to tenants (see talk on Donabe)<br />
  5. 5. Example Architecture: Single Service<br />Openstack Dashboard<br />Tenant API<br />Tenant API<br />Quantum Service<br />Nova Service<br />Admin API<br />nova-api<br />nova-scheduler<br />Quantum Plugin<br />Internal nova<br />Communication<br />XenServer #1<br />Hypervisor<br />nova-compute<br />vswitch<br />Internal Plugin<br />Communication<br />
  6. 6. Example Architecture: Two Services<br />Tenant API<br />Quantum Service<br />Network Edge:<br />Point at which a service “plugs” into the network.<br />Quantum Plugin<br />Internal Plugin<br />Communication<br />vswitch<br />vswitch<br />physical<br />switch<br />VM<br />VM<br />VM<br />VM<br />FW<br />FW<br />FW<br />Firewall Service<br />Compute Service<br />Tenant API<br />Tenant API<br />
  7. 7. Virtual Network Abstractions (1)<br />Services (e.g., nova, atlas) expose interface-IDs via their own tenant APIs to represent any device from that service that can be “plugged” into a virtual network. <br />Example: nova.foo.com/<tenant-id>/server/<server-id>/eth0<br />Tenants use Quantum API to create networks, get back UUID: <br />Example: quantum.foo.com/<tenant-id>/network/<network-id><br />Tenants can create ports on a network, get a UUID, and associate config with those ports (APIs for advanced port config are TBD, initially ports give L2 connectivity):<br />Example: quantum.foo.com/<tenant-id>/network/<network-id>/port/<port-id><br />Tenants can “plug” an interface into a port by setting the attachment of a port to be the appropriate interface-id. <br />Example: set quantum.foo.com/<tenant-id>/network/<network-id>/port/<port-id>/attach to value “nova.foo.com/<tenant-id>/server/<server-id>/eth0” . <br />
  8. 8. Virtual Network Abstractions (2)<br />Note: At no time does the customer see details of how a network is implemented (e.g., VLANs).<br />Association of interfaces with network is an explicit step.<br />Plugins can expose API extensions to introduce more complex functionality (e.g., QoS). Extension support is queriable, so a customer can “discover” capabilities. <br />API extensions that represent common functionality across many plug-ins can become part of the core API.<br />Core API for diablo is simple, focused on connectivity. Core API will evolve.<br />
  9. 9. Example Scenario: <br />Nova i-24<br />10.0.0.24<br />Nova i-26<br />10.0.0.26<br />Nova i-22<br />10.0.0.22<br />Nova i-23<br />10.0.0.23<br />GW Instance-1<br />10.0.0.1<br />Private Net #2<br />Private Net #1<br />Tenant<br />View<br />Provider View<br />Nova i-24<br />10.0.0.24<br />Nova i-26<br />10.0.0.26<br />Nova i-26<br />10.0.0.26<br />Data Center<br />Network<br />GW Instance-1<br />10.0.0.1<br />Nova i-24<br />10.0.0.24<br />NAT Gateway Service<br />Compute Service<br />
  10. 10. Live Demo…<br />
  11. 11. Why Quantum?<br />API gives ability to create interesting network topologies.<br />Example: create multi-tier applications<br />Provide way to connect interconnect multiple Openstack services (*-aaS).<br />Example: Nova VM + Atlas LB on same private network.<br />Open the floodgates to let anyone build services (open or closed) that plug into Openstack networks. <br />Examples: VPN-aaS, firewall-aaS, IDS-aaS.<br />Allows innovation plugins that overcomes common cloud networking problems<br />Example: avoid VLAN limits, provide strong QoS<br />
  12. 12. How? Quantum Design Goals<br />Decoupled from nova and other services<br />Communication between quantum and another service should happen via well-defined Rest API (not direct python calls, no nova RPC, not shared understanding of database schemas)<br />Be able to run without nova. <br />Flexible enough to support plugins for many different “network edges”:<br />Bridge / Open vSwitch on Linux<br />Vmware DVS / Nexus 1000V <br />Physical switches <br />Physical switches with VEPA / VNtag<br />
  13. 13. How? Inside Quantum<br />Plugin interface maps to “core” tenant API + admin API.<br />“Network agents” running on nova hypervisor fit within this model.<br />Plugin might manage just the network edge (e.g., a vswitch), or all network devices.<br />Tenant API<br />Admin API<br />Auth (talk to Keystone)<br />API Limits<br />Plugin<br />Communicate with external devices in a plugin-specific way to implement logical abstractions from the tenant API.<br />
  14. 14. Edge Bindings<br />Services that expose interface-IDs must tell quantum where that interface is currently “plugged” into the network. <br />We call this an “edge binding”<br />Impl still fuzzy: Quantum may support an admin API that allows other services to register <interface-id, interface-location> pairs with Quantum. <br />Many different “types” of interface-location data:<br />XenServer: VIF-UUID<br />Cisco 1000v: veth0 device<br />Physical Hosting: physical switch ID + port number<br />Openstackdeployers must make sure all services able to “speak” a interface-location type supported by the switch.<br />There will be a “default” type supported by an open source plugin (VLAN based, like nova today?)<br />
  15. 15. Simple Plug-in Example with VLANs<br />Similar to what Nova does for private networks:<br />One VLAN per “network”.<br />Hypervisor NIC is VLAN trunk, all switches are trunked.<br />When an interface-ID is associated is associated with a network, plugin uses the edge binding to find the interface-location (a port on a vswitch) and puts that port on the correct VLAN. <br />
  16. 16. Plans for Diablo timeframe<br />“experimental” Quantum plug-in <br />Plug-in Agnostic: <br />Create API, including way for plugin to register extensions.<br />Store “ownership” + integrate with keystone for auth.<br />Implement “edge bindings” database + API. <br />Plugins:<br />At least one (hopefully more!) open-source plugin that anyone can use to experiment with Quantum.<br />Services:<br />Perform “edge bindings” integration with nova and at least one other service. <br />
  17. 17. This is Just the Beginning….<br />Our goals within Diablo time frame are well scoped.<br />Quantum is a building block, not the entire solution for all networking problems. <br />Goal is to make sure Quantum design for Diablo does not preclude doing things we will likely consider important in the future.<br />
  18. 18. Many important questions remain:<br />How should knowledge of the network topology and resources/capacity be used to influence workload placement decisions by the scheduler?<br />What should be included in a broader set of core APIs (QoS, packet stats, ACLs, etc) in future iterations? <br />Is L2 VPN (e.g., to customer site) a part of this core API, ok something the “plugs” into a virtual network?<br />How to expose attributes of the physical network (e.g., redundant NICs) via the logical model?<br /><Insert your question here…> <br />

×