Intro to OpenStack QuantumDan Wendlandt – Quantum Hacker & PTL          dan@nicira.com       twitter - danwendlandt
Caveats• “Contents may shift in flight”   – Quantum is a young and rapidly evolving project. My     focus will be on big p...
Outline• Why Quantum?• What is Quantum?  – Basic Concepts & Demo  – High-level System Architecture• Current Project Status...
Why Quantum?
What is OpenStack?• Open Source Cloud Software…• A collection of “cloud services”• Each service includes:  – A tenant-faci...
In the beginning..*-as-a-Service Capability      OpenStack Service         Compute                       Nova             ...
Why Quantum?• Networking was sub-component of Nova• Two Key Problems:  #1: Limited technology “baked in” to design.  #2: N...
Problem #1: Technology Limitations• Cloud stresses networks like never before:   – High-density multi-tenancy, massive sca...
Why Quantum? Reason #1• New networking technologies are emerging to try and  tackle these challenges.   –   Software-defin...
Problem #2: No Tenant Control• Cloud tenants want to replicate rich  enterprise network topologies:   – Ability to create ...
Why Quantum? Reason #2• Base Quantum API lets tenants create multiple  private networks, control IP addressing on them.• Q...
All is Right with the World…*-as-a-Service Capability   OpenStack Service        Compute                     Nova         ...
Why Quantum? Questions?
What is Quantum?
Quantum Basics (by analogy to Nova)                                     Nova                            Quantum*-as-a-serv...
API Abstractions             VM1                VM2           virtual serverNova        10.0.0.2           10.0.0.3       ...
Quantum Rest API Abstraction Details• Virtual Networks:   – Equivalent to a “virtual VLAN”, a dedicated L2 segment.   – Ex...
Old Model: Static Nova Networking       TenantA-VM1    TenantB-VM1     TenantA-VM2   TenantA-VM3         88.0.0.2       88...
Quantum Model: Dynamic Network     Creation + Association                           TenantA-VM2           TenantA-VM3     ...
Demo!  What could possibly go wrong?Questions on Quantum Basics or Demo?
Quantum Architecture Basics• At no time during demo did tenant see the technology  used to implement L2 isolation (VLANs, ...
Plugin Architecture• Plugins perform two main tasks:  – Process API calls: store the results of all network    + port call...
Quantum Architecture (simple)API Clients                    Quantum Server                                                ...
Quantum Architecture (adv.)                                                                                     ExternalAP...
Current Project Status
Project Status: Essex Cycle•   Started at Diablo summit, “incubated” for Essex, “core” in Folsom.•   Available at: http://...
Project Status: Who should use Quantum?• “Early adopters” already putting Quantum into  trial & production OpenStack deplo...
Future Directions• More and more Plugins  – Already have a pipeline of additional plugins...• Merge with Melange IP Addres...
Play with Quantum•   New integrated with DevStack•   http://wiki.openstack.org/QuantumDevstack•   Use nova-manage to creat...
Frequently Asked Questions• Is OpenFlow required for Quantum  – A: Nope! OpenFlow is just one technology that    Quantum e...
Thanks! Questions / Comments?          Come join us:  http://wiki.openstack.org/Quantum     netstack@lists.launchpad.net  ...
Bonus Slides
Basic Quantum + Nova API FlowAPI Client                                      Quantum                           Nova Server...
Simple VLAN Plugin Example• Plugin assumes all VLANs are trunked to all  hypervisors (similar to nova-network)• When new q...
Example Quantum + Nova Architecture                                             Dashboard /                               ...
Common Question: Can I run multiple        plugins at once?•   A “plugin” is NOT a “driver” *•   A “plugin” is NOT a “driv...
A plugin is not a driver• A plugin registers to handle all Quantum API  calls in a “group” (e.g., all network/port calls)....
Why separate plugins + drivers?• Plugins may make decisions that are technology,  but not device-specific (e.g., mapping q...
Upcoming SlideShare
Loading in...5
×

OpenStack Quantum Intro (OS Meetup 3-26-12)

60,652

Published on

This is the presentation I gave at the Bay Area OpenStack Meetup on 3-26-12.

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

No Downloads
Views
Total Views
60,652
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
2,714
Comments
0
Likes
81
Embeds 0
No embeds

No notes for slide
  • Common to run both Quantum and Nova on the same set of controller hosts.
  • OpenStack Quantum Intro (OS Meetup 3-26-12)

    1. 1. Intro to OpenStack QuantumDan Wendlandt – Quantum Hacker & PTL dan@nicira.com twitter - danwendlandt
    2. 2. Caveats• “Contents may shift in flight” – Quantum is a young and rapidly evolving project. My focus will be on big picture concepts, not on deploying it right now.• “Handwave, Handwave” – Target audience is future users of Quantum (cloud tenants, cloud operators). Not enough time to satisfy details of developers.• “One point of view” – Quantum is a community, and differences of opinion “sometimes” exist.
    3. 3. Outline• Why Quantum?• What is Quantum? – Basic Concepts & Demo – High-level System Architecture• Current Project Status• Future Directions• Frequently Asked Questions
    4. 4. Why Quantum?
    5. 5. What is OpenStack?• Open Source Cloud Software…• A collection of “cloud services”• Each service includes: – A tenant-facing API that exposes logical abstractions for consuming the service. – One or more backend implementations of that API
    6. 6. In the beginning..*-as-a-Service Capability OpenStack Service Compute Nova Swift (Objects) Storage Glance (Images) Network ?
    7. 7. Why Quantum?• Networking was sub-component of Nova• Two Key Problems: #1: Limited technology “baked in” to design. #2: No tenant control of network topology and addressing, no way to insert advanced network services (e.g., firewall).
    8. 8. Problem #1: Technology Limitations• Cloud stresses networks like never before: – High-density multi-tenancy, massive scale – Strict uptime requirements. – Integrate with legacy hosting environments / remote data centers. – Price pressure to use commodity gear. – VM mobility• Nova provides only basic technologies: – VLANs are only option for multitenancy – Used simple Linux Bridge (no advanced QoS, ACLs, or monitoring) VLANs are Great! – “network controller” node is centralized - Stone Age Man single-point of failure for large networks.
    9. 9. Why Quantum? Reason #1• New networking technologies are emerging to try and tackle these challenges. – Software-defined Networking (SDN) / OpenFlow – Overlay tunneling: VXLAN, NVGRE, STT – Fabric solutions: FabricPath, Qfabric, etc. – [ insert other solution here ]• Quantum provides a “plugin” mechanism to enable different technologies implement calls made via the Quantum API.• Choice is a good thing!
    10. 10. Problem #2: No Tenant Control• Cloud tenants want to replicate rich enterprise network topologies: – Ability to create “multi-tier” networks (e.g., web tier, app tier, db tier) – Control over IP addressing. – Ability to insert and configure your own services (e.g., firewall, IPS) – VPN/Bridge to remote physical hosting or customer premises.• Nova provides no tenant control: “You can have any color as long – No way to control topology. as its black.“ - Henry Ford about the Model-T – Cloud assigns IP prefixes + addresses. – No generic service insertion.
    11. 11. Why Quantum? Reason #2• Base Quantum API lets tenants create multiple private networks, control IP addressing on them.• Quantum API extensions enable additional control: – Security & Compliance Policies – Quality-of-Service – Monitoring + Troubleshooting• “Advanced Network Services” such as firewall, intrusion detection, VPN, can be inserted either as VMs that route between networks, or as API extensions.
    12. 12. All is Right with the World…*-as-a-Service Capability OpenStack Service Compute Nova Swift (Objects) Storage Glance (Images) Network Quantum
    13. 13. Why Quantum? Questions?
    14. 14. What is Quantum?
    15. 15. Quantum Basics (by analogy to Nova) Nova Quantum*-as-a-service Compute NetworkMajor API abstractions “virtual servers”: represents “virtual networks”: a host with CPU, memory, A basic L2 network segment. disk, and NICs. “virtual ports”: Attachment point for devices connecting to virtual networks.Interactions with other virtual servers use “virtual virtual ports are linked to vNICs onOpenStack services. images” from Glance. “virtual servers”.Supports different “virt-drivers” for KVM, “plugins” for Open vSwitch Ciscoback-end technologies XenServer, Hyper-V, UCS, Linux Bridge, Nicira NVP, Ryu VMWare ESX Controller.API Extensibility for keypairs, instance rescue, quality-of-service, port statistics,new or back-end volumes, etc. security groups, etc.specific features.
    16. 16. API Abstractions VM1 VM2 virtual serverNova 10.0.0.2 10.0.0.3 virtual interface (VIF) virtual portQuantum Net1 virtual network 10.0.0.0/24
    17. 17. Quantum Rest API Abstraction Details• Virtual Networks: – Equivalent to a “virtual VLAN”, a dedicated L2 segment. – Example: quantum.foo.com/<tenant-id>/network/<network- id>• Virtual Ports: – Where a virtual interface (e.g., Nova vNIC) attaches to a network. – Ports expose configuration and monitoring state via extensions (e.g., ACLs, QoS policies, Packet Statistics) – Example: quantum.foo.com/<tenant-id>/network/<network- id>/port/<port-id>
    18. 18. Old Model: Static Nova Networking TenantA-VM1 TenantB-VM1 TenantA-VM2 TenantA-VM3 88.0.0.2 88.0.0.3 88.0.0.4 88.0.0.5 Public Net 88.0.0.0/18 • Single network exists (per-project or global). • VMs automatically get a vNIC on that single network on boot. • Tenants have no control over IP addressing.
    19. 19. Quantum Model: Dynamic Network Creation + Association TenantA-VM2 TenantA-VM3 TenantA-VM1 10.0.0.3 9.0.0.2 10.0.0.2 9.0.0.3 Tenant-A Net1 Tenant-A Net2 10.0.0.0/24 9.0.0.0/24 Public Net88.0.0.0/18 • 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).
    20. 20. Demo! What could possibly go wrong?Questions on Quantum Basics or Demo?
    21. 21. Quantum Architecture Basics• At no time during demo did tenant see the technology used to implement L2 isolation (VLANs, tunneling, etc.).• Key tenant: abstract logical API, “pluggable” back-end gives provider choice.• Plugins will give operators choices in terms of: – Advanced Features – Cost – Scale – High Availability – Hypervisor + Network HW Compatibility – Manageability / Polish
    22. 22. Plugin Architecture• Plugins perform two main tasks: – Process API calls: store the results of all network + port calls, while mapping abstract entities to a plugin-specific identifiers (e.g., map a network UUID to a VLAN) – Manage virtual switches: learn about VIFs when they are attached to the network and configure network switches accordingly (e.g., assign a vswitch port to a particular VLAN).
    23. 23. Quantum Architecture (simple)API Clients Quantum Server Internal plugin Quantum communication. Uniform API for all clients API Quantum Plugin Tenant Create-net Scripts . Create-net virtual switch Nova Compute . . Horizon Nova Compute . . Nova Compute Create-port Nova Compute Nova . Create-port Interfaces from a service API like Nova plug into a Extensions DB switch manages by the Quantum plugin. API + Plugin = Quantum Service
    24. 24. Quantum Architecture (adv.) ExternalAPI Clients Quantum Server Manager DB Internal plugin Uniform API Quantum communication. for all clients API Quantum Plugin Tenant Create-net Scripts . Create-net virtual switch Nova Compute . . Horizon Nova Compute . . Nova Compute Create-port Nova Compute Nova . Create-port Interfaces from a service API like Nova plug into a Extensions DB switch manages by the Quantum plugin. API + Plugin = Quantum Service
    25. 25. Current Project Status
    26. 26. Project Status: Essex Cycle• Started at Diablo summit, “incubated” for Essex, “core” in Folsom.• Available at: http://launchpad.net/quantum• Docs at: http://docs.openstack.org/incubation/• Current Capabilities: – v1.1 of the Quantum L2 API, with extension support. – API client library and CLI – Nova Integration via the QuantumManager – Plugin framework & several publicly available plugins: • Open vSwitch Plugin • Cisco UCS/Nexus Plugin • Linux Bridge Plugin • Nicira Network Virtualization Platform (NVP) • Ryu OpenFlow Controller – Integrated with “devstack” (see: http://wiki.openstack.org/QuantumDevstack) – Packaging for Ubuntu (Precise) / Fedora / Debian .
    27. 27. Project Status: Who should use Quantum?• “Early adopters” already putting Quantum into trial & production OpenStack deployments.• Caution: Deployments are by people at the cutting edge, require significant familiarity with Quantum.• Folsom release will be first target for widespread adoption.
    28. 28. Future Directions• More and more Plugins – Already have a pipeline of additional plugins...• Merge with Melange IP Address Mgmt. Project• Beyond L2: Advanced Network Services – L3 routing + NAT/Floating IPs – Firewall & Security Groups. – QoS Guarantees – VPN, DHCP, LB (may be part of Quantum, or separate projects that integrate with Quantum).• Keystone: fine-grain API permissions• Horizon: GUI for configuring networking.
    29. 29. 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/
    30. 30. 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.
    31. 31. Thanks! Questions / Comments? Come join us: http://wiki.openstack.org/Quantum netstack@lists.launchpad.net Dan Wendlandt Dan@nicira.com Twitter: danwendlandt http://www.slideshare.net/danwent/
    32. 32. Bonus Slides
    33. 33. Basic Quantum + Nova API FlowAPI Client Quantum Nova Server Create Network (POST /tenant1/network) Server Network UUID: ‘abc’ Create Server (POST /tenant1/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
    34. 34. 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.
    35. 35. Example Quantum + Nova Architecture Dashboard / Automation Tools Tenant API Tenant API Quantum Quantum API Nova Service Service nova-scheduler nova-api Quantum Plugin Internal nova CommunicationTwo Plugins Available: nova-compute- Open vSwitch- Cisco UCS/Nexus vswitch XenServer #1 Internal Plugin Communication Hypervisor
    36. 36. Common Question: Can I run multiple plugins at once?• 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….
    37. 37. 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.
    38. 38. 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).
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×