Quantum Folsom Summit Developer Overview
Download as PPTX, PDF6 likes1,630 views
The document is an introduction to OpenStack Quantum, presenting its purpose and functionalities in enhancing networking capabilities compared to the traditional Nova networking. It discusses the limitations of Nova, including lack of tenant control and outdated technology, and how Quantum addresses these issues through a plugin architecture that supports advanced networking technologies. The current project status and future priorities for Quantum's development are also outlined, emphasizing the need for tenant control, improved system quality, and the transition of networking responsibilities from Nova to Quantum.
![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!](https://image.slidesharecdn.com/quantumfolsomsummitoverview-120417125728-phpapp02/85/Quantum-Folsom-Summit-Developer-Overview-9-320.jpg)
Quantum Folsom Summit Developer Overview
- 1. Intro to OpenStack Quantum Dan Wendlandt – Quantum Hacker & PTL dan@nicira.com twitter - danwendlandt
- 2. Caveats • Contents may shift in flight… • Quantum is young: there are lots of things that it COULD do, but doesn’t yet. • I will not finish these slides…
- 3. Outline • Why Quantum? • What is Quantum? – Basic Concepts & Demo – High-level System Architecture • Current Project Status • Future Directions • Frequently Asked Questions
- 4. Why Quantum?
- 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. In the beginning.. *-as-a-Service Capability OpenStack Service Compute Nova Swift (Objects) Storage Glance (Images) Network ?
- 7. Why Quantum? • Networking was sub-component of Nova • Two Key Problems: #1: Limited technology “baked in” to design. #2: No tenant control of networking.
- 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. 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. 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. 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. All is Right with the World… *-as-a-Service Capability OpenStack Service Compute Nova Swift (Objects) Storage Glance (Images) Network Quantum
- 14. What is Quantum?
- 15. Quantum Basics (by analogy to Nova) Nova Quantum *-as-a-service Compute Network Major 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 on OpenStack services. images” from Glance. “virtual servers”. Supports different “virt-drivers” for KVM, “plugins” for Open vSwitch Cisco back-end technologies XenServer, Hyper-V, UCS, Linux Bridge, Nicira NVP, Ryu VMWare ESX Controller (and more!). API Extensibility for keypairs, instance rescue, quality-of-service, port statistics, new or back-end volumes, etc. security groups, etc. specific features.
- 16. API Abstractions VM1 VM2 virtual server Nova 10.0.0.2 10.0.0.3 virtual interface (VIF) virtual port Quantum Net1 virtual network 10.0.0.0/24
- 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. – Example: quantum.foo.com/<tenant-id>/network/<network- id>/port/<port-id> • API Extensions: – Can add properties to existing network/port abstractions (e.g., QoS settings for a virtual port). – Can introduce new API entities (e.g., Security Groups that are linked to ports, or L3 + NAT Forwarding Elements that attach to networks).
- 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. 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 Net 88.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. Quantum Architecture Basics • “Plugin” model give cloud operators choices: – Advanced Features (exposed as API extensions) – Cost – Scale – High Availability – Hypervisor + Network HW Compatibility – Manageability / Polish • Abstract logical API – tenants don’t see underlying technologies – Example: VLANs vs. tunneling
- 21. A bit about plugins (more later!) • A common point of confusion. • Define “quantum plugin”: Code that communicates with network devices to implement a particular set of Quantum API calls. • API currently has one set of calls for “base L2” networking => one plugin running at a time. • A plugin is not a “driver”. A single plugin can talk to different types of network devices.
- 22. 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
- 23. Quantum Architecture (advanced) External API 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. 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 12.04 / Fedora 17 / Debian .
- 26. Project Status: Two Deployment Models • Proxied Quantum (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, but doesn’t give tenant’s network control. • Direct Quantum (Folsom Target): – Tenants can create their own networks, determine their own IP addressing via Quantum API. – Tenants can insert other logical services exposed by service provider (e.g., router, VPN) using extensions. – Requires Keystone Authn/Authz for API and a tenant API for IPAM (i.e., Melange)
- 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. Project status: Try it Yourself • Now integrated with DevStack • http://wiki.openstack.org/QuantumDevstack • Use nova-manage to create networks (i.e. proxied mode) • Spin up VMs with -- nic option. • See Quantum Administrator Guide for details – http://docs.openstack.org/incubation/openstack- network/admin/content/
- 29. Folsom Priorities #1 • Enable tenant control of networking – Keystone Authn, Authz – Expose IPAM to tenants (e.g., integrate Melange) – Rework Nova integration (remove ties to Nova DB) – Horizon integration, CLI rewrite.
- 30. Folsom Priorities #2 • Improve system quality + scale – Unit test – System-test – CI-integration – API scaling
- 31. Folsom Priorities #3 • Move networking from Nova to Quantum – L3 Forwarding + NAT/Floating IPs – Security Groups – DHCP injection – VPN (?) • Follow Quantum pattern: – Enable tenant control by extending existing API – Allow pluggable backends
- 32. Developer, Developer Developers • Folsom goals, including becoming default network platform, are VERY ambitious • We’ll need many more developers to: – Implement new functionality (particularly for open source plugins!) – Be familiar enough with Quantum to answer user questions on ML, launchpad, IRC, etc. • Let’s help grow the team.
- 33. Deeper Technical Dive (until we run out of time)
- 34. Basic code flow
- 35. “Create Network” in Proxied Mode • Network created by cloud operator using nova-manage: • QuantumManager (QM) in Nova calls to Quantum, creates network. • QM creates IPAM subnet using Nova DB or Melange. • QM stashes resulting data in Nova DB.
- 36. “Create VM” in Proxied Mode • Tenant uses Nova API to create VM • Extension allows VM to pass in a list of network UUIDs (see --nic option in novaclient) • Nova-compute makes nova RPC call to “allocate_for_instance” method of network manager. • QM creates a VIF entry in nova DB for each attached network. • QM creates a Quantum port for each VIF, tells Quantum the associated “vif-id”. • Nova-compute creates VM, and “vif-plugging” reports bindings between “vif-id” and “switch port” to Quantum plugin.
- 37. “Create Network” in Direct Mode • Tenant contacts Quantum directly, passing in network details, including associated IPAM subnet. • All data is stored in Quantum plugin (nothing stored in Nova).
- 38. “Create VM” in Proxied Mode • Tenant uses Nova API to create VM • Extension allows VM to pass in a list of same network UUIDs (see --nic option in novaclient) • Nova-compute makes direct REST call to Quantum, creating a port for each network (no more QM or nova-network) • Nova-compute creates VM, and “vif- plugging” reports bindings between “quantum port” and “switch port” to Quantum plugin.
- 39. Plugin Details
- 40. 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, agent finds q- port + q-network associated with interface- id, configures vswitch port with correct VLAN.
- 41. Persistent Data Stored by Plugins • All persistent data (networks, ports, etc) is stored by the plugin, not the API layer. • Why? – Data schema for plugin depends on plugin-specific implementation details (e.g, networks -> VLANs) – Data schema depends on supported extensions. – Plugins may make different trade-offs around scale, HA, data consistency, etc. • Common data models are shared across plugins using a library of “base” SQLAlchemy models.
- 42. 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). • Driver code can be shared across plugins with libraries.
- 43. 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.
- 44. Bonus Slides
- 45. Basic Quantum + Nova API Flow API 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
- 46. 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 Communication nova-compute vswitch XenServer #1 Internal Plugin Communication Hypervisor
Editor's Notes
- #16: Common to run both Quantum and Nova on the same set of controller hosts.