Openstack Quantum yahoo meetup 1 23-13
Download as PPTX, PDF3 likes1,730 views
The document summarizes OpenStack Quantum, a networking component that provides network connectivity as a service for tenants in OpenStack clouds. Key points: - Quantum provides APIs for tenants to create private networks with subnets and connect VMs to those networks, enabling complex multi-tenant networking. - It uses a plugin architecture so different networking technologies like OVS, Linux Bridge can be supported. - The Grizzly release will include features like metadata for overlapping IPs, security groups, L3 HA, and new plugin support. - Users can help with testing, documentation, and implementing open specifications.
![Why Quantum?
#2: Leveraging Advanced Technologies
• New networking technologies are
emerging to try and tackle these
challenges.
– Network virtualization
– Overlay tunneling: VXLAN, NVGRE, STT
– Software-defined Networking (SDN) /
OpenFlow
– L2 Fabric solutions: FabricPath, Qfabric,
etc.
– [ insert other solution here ]
• Quantum provides a “plugin”
mechanism to enable different
technologies.](https://image.slidesharecdn.com/quantumyahoomeetup1-23-13-130123162936-phpapp01/85/Openstack-Quantum-yahoo-meetup-1-23-13-6-320.jpg)
Openstack Quantum yahoo meetup 1 23-13
- 1. OpenStack Quantum Meetup: Grizzly Status and Blueprint Discussion Dan Wendlandt dan@nicira.com Openstack Quantum Hacker & Project Team Lead twitter - danwendlandt
- 2. Why Quantum?
- 3. Networks for Enterprise Applications are Complex…. Image from windowssecurity.com
- 4. Why Quantum? Reason #1 On-demand Enterprise-Class Networking • Quantum has Tenants API to: Internet – create multiple private L2 L3 networks L2 – control IP addressing (can use L3 same IP space as existing datacenter deployment) L2 – Connect to an upstream router L3 for external access. L2 – Insert advanced network L3 services: routers, firewalls, VPN, IDS, etc. L2 – Monitor network status
- 5. Cloud Stresses the Network…. • High-density multi-tenancy – But VLANs have trouble scaling • On-demand provisioning – But traditional network solutions have interfaces designed for manual configuration. • Need to place / move workloads were capacity exists – But network state (e.g., IP address) is tied to a particular location
- 6. Why Quantum? #2: Leveraging Advanced Technologies • New networking technologies are emerging to try and tackle these challenges. – Network virtualization – Overlay tunneling: VXLAN, NVGRE, STT – Software-defined Networking (SDN) / OpenFlow – L2 Fabric solutions: FabricPath, Qfabric, etc. – [ insert other solution here ] • Quantum provides a “plugin” mechanism to enable different technologies.
- 8. Quantum Architecture Generic OpenStack APIs Operator Selected Backends Compute API KVM Network API OVS Plugin Tenant Tools (GUI, CLI, Storage API Ceph API code) An eco-system of A generic tenant API A “plugin” architecture tools that leverage to create and with different back-end the Quantum API. configure “virtual “engines” networks”
- 9. Basic API Abstractions VM1 VM2 virtual server Nova 10.0.0.2 10.0.0.3 virtual interface (VIF) virtual port Quantum Net1 L2 virtual network 10.0.0.0/24 virtual subnet “virtual networks” and “virtual subnets” are fundamentally multi-tenant, just like virtual servers (e.g., overlapping IPs can be used on different networks).
- 10. 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 External 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” that provide more advanced network functionality (e.g., routing + NAT).
- 11. Quantum API Extensions • Enables innovation in virtual networking. – Tenants can query API to programmatically discover supported extensions. – Overtime, extensions implemented by many plugins can become “core”. • Add properties on top of existing network/port abstractions: – QoS/SLA guarantees / limits – Security Filter Policies – port statistics / netflow • New Services – L3 forwarding, ACLs + NAT (“elastic” or “floating” IPs) – VPN connectivity between cloud and customer site, or another cloud datacenter.
- 12. Quantum Architecture Generic OpenStack APIs Operator Selected Backends Compute API KVM Network API OVS plugin Tenant Tools (GUI, CLI, Storage API Ceph API code) An eco-system of A generic tenant API A “plugin” architecture tools that leverage to create and with different back-end the Quantum API. configure “virtual “engines” networks”
- 13. Quantum Architecture (generic) API Clients Quantum Service Backend X Quantum API Tenant Create-net Scripts . Horizon . Plugin GUI . X Create- Orchestration Physical port virtual switch Code Network Nova Compute API Extensions Interfaces from Nova plug into a switch manages by Uniform API the Quantum plugin. for all clients
- 14. World’s simplest Quantum Plugin* • API request is dumped into an email, send to your network administrator. • Administrator manually configures network connectivity. * Not recommended for use… ever!
- 15. Quantum Plugins Open vSwitch / Linux Bridge Ryu OpenFlow Controller
- 16. Quantum Plugins Trade-offs • Different back-end “engines” present different trade-offs: – Scalability – Forwarding performance – Hypervisor Compatibility – Network HW Compat (vendor specific? Allow L3 scale-out?) – Manageability / troubleshooting – Advanced Features (exposed as API extensions) – Production testing – High Availability (control & data plane) – Open source vs. Free vs. Paid • Cloud Operators weigh trade-offs, choose a plugin. • Note: Back-end technology hidden behind logical core API – Example: VLANs vs. tunneling
- 17. Project Status
- 18. A Growing Team…
- 19. Folsom • First “core” release (Folsom, Oct. ‘12) – v2 API, with L2 + IP address mgmt (IPAM) – Tenant API with Keystone + Horizon Integration – Updated CLI – Extensions: • L3 “routers” w/floating IPs • “provider networks” mapped to specific VLANs • Tenant quotas • Notifications
- 20. Grizzly Release http://wiki.openstack.org/GrizzlyReleaseSchedule • Release on April 4th. • We are already near the end of the Grizzly development cycle (G-3 freeze is Feb 19th) • Expect release candidates in March.
- 21. Grizzly Features • Metadata for Overlapping IPs. – Requires updated Nova as well. – Metadata on non-routed networks (expected) • Quantum Security Groups – Works with Overlapping IPs – Handles VMs with multiple NICs – Inbound / outbound rules – v6 matching • L3/DHCP multi-node scale-out + HA (expected)
- 22. Grizzly Features • Advanced Services Infrastructure • Load-balancing Service with HAproxy driver (expected) • New Plugins: – Big Switch / Floodlight – Hyper-V – Brocade (expected) • Many enhancements to existing plugins!
- 23. Grizzly Changes in Other Projects • Horizon: – L3: CRUD for quantum routers – Graphical view of network topology – Specifying multiple NICs when booting a VM – LBaaS control. • Client/CLI – Remodeled “pythonic” client API – New CLI commands for LB, services, etc.
- 24. Grizzly Non-Feature Improvements • Quantum Tempest tests • Quantum commit gating (yay!) • Quantum DB migration • String localization • XML API (expected) • Full API definition in WADL
- 25. How Can You Help? • Grab open blueprint or bug. • http://wiki.openstack.org/QuantumStarterBugs • Some specific highlights: – Vif hot plugging (Nova) – Auto-assign floating-ips. – Make sure euca-* network calls are proxied to Quantum (Nova)
- 26. Thanks! Questions? Discussion Topics? Slides available at: http://www.slideshare.net/danwent Dan Wendlandt dan@nicira.com OpenStack Quantum Hacker & Project Team Lead twitter - danwendlandt
- 27. Backup Slides
- 28. How Can You Help? • Test G-3 milestone and release candidates (Feb/March) • Help write and validate documentation. – https://bugs.launchpad.net/openstack- manuals/+bugs?field.tag=quantum – https://bugs.launchpad.net/openstack-api- site/+bugs?field.tag=netconn-api
- 29. Tenant Network Control (Horizon)
- 30. Tenant Network Control (Horizon)
- 31. Tenant Network Control (Horizon)
- 32. Taking Quantum for a spin.. • Admin Documentation: – http://docs.openstack.org/trunk/openstack- network/admin/content/ – Ubuntu and Red Hat deployments covered. – Please read the entire doc… if something is still unclear, send email to the list • Or use Devstack – http://wiki.openstack.org/QuantumDevstack
- 34. Basic Physical Network Connectivity
- 35. Two API Deployment Models • Cloud Operator creates networks for tenants – Quantum API is admin only, tenants do not use it. – Similar to nova-network model, but with flexibility around network topology, IP addressing, etc. • Expose API to tenants directly – True “self-service networking”. – Tenants use scripts, CLI, or web GUI to manage networks & subnets. • Can also mix-and-match strategies – Provider creates default network connectivity, tenants can choose to extend.
- 36. Single Flat Network Similar to Nova-network Flat or FlatDHCP manager.
- 38. Mixed Flat + Private Networks
- 39. Single Provider Router Similar to Nova-network VlanManager.
- 40. Per-Tenant Routers Similar to Amazon VPC or CloudStack model.