openstack quantum yahoo meetup 1 23-13
TRANSCRIPT
OpenStack Quantum Meetup:Grizzly Status and Blueprint Discussion
Openstack Quantum Hacker & Project Team Leadtwitter - danwendlandt
Why Quantum?
Networks for Enterprise Applications are Complex….
Image from windowssecurity.com
Why Quantum? Reason #1On-demand Enterprise-Class Networking
• Quantum has Tenants API to: – create multiple private L2
networks– control IP addressing (can use
same IP space as existing datacenter deployment)
– Connect to an upstream router for external access.
– Insert advanced network services: routers, firewalls, VPN, IDS, etc.
– Monitor network status
L2
L3
L2
L2
L2
Internet
L3
L3
L3
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
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.
What is Quantum?
Quantum Architecture
A generic tenant API to create and
configure “virtual networks”
A “plugin” architecture with different back-end
“engines”
An eco-system of tools that leverage the Quantum API.
Tenant Tools(GUI, CLI, API code)
Compute API
Network API
Storage API
Generic OpenStack APIs Operator Selected Backends
KVM
OVS Plugin
Ceph
Basic API Abstractions
Net110.0.0.0/24
VM110.0.0.2Nova
Quantum L2 virtual network
VM210.0.0.3
virtual port
virtual server
virtual interface (VIF)
“virtual networks” and “virtual subnets” are fundamentally multi-tenant, just like virtual servers (e.g., overlapping IPs can be used on different networks).
virtual subnet
Quantum Model: Dynamic Network Creation + Association
TenantA-VM110.0.0.2
TenantA-VM39.0.0.2
• 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).
TenantA-VM210.0.0.3 9.0.0.3
Router
External Net88.0.0.0/18
Tenant-A Net110.0.0.0/24
Tenant-A Net29.0.0.0/24
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.
Quantum Architecture
A generic tenant API to create and
configure “virtual networks”
A “plugin” architecture with different back-end
“engines”
An eco-system of tools that leverage the Quantum API.
Tenant Tools(GUI, CLI, API code)
Compute API
Network API
Storage API
Generic OpenStack APIs Operator Selected Backends
KVM
OVS plugin
Ceph
Tenant Scripts
Horizon GUI
Orchestration Code
API Clients Quantum Service
PluginX
Quantum API
Create-net...
Create-port
Uniform API for all clients
API Extensions
Nova Compute
virtual switch
Interfaces from Nova plug into a switch manages by
the Quantum plugin.
Physical Network
Backend X
Quantum Architecture (generic)
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!
Quantum Plugins
Open vSwitch / Linux Bridge
Ryu OpenFlowController
• 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
Quantum Plugins Trade-offs
Project Status
A Growing Team…
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
Grizzly Releasehttp://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.
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)
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!
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.
Grizzly Non-Feature Improvements
• Quantum Tempest tests• Quantum commit gating (yay!)• Quantum DB migration • String localization • XML API (expected)• Full API definition in WADL
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)
Thanks! Questions?Discussion Topics?
OpenStack Quantum Hacker & Project Team Leadtwitter - danwendlandt
Slides available at: http://www.slideshare.net/danwent
Backup Slides
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
Tenant Network Control (Horizon)
Tenant Network Control (Horizon)
Tenant Network Control (Horizon)
Taking Quantum for a spin..
• Admin Documentation: – http://docs.openstack.org/trunk/openstack-netwo
rk/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
Deployment Use Cases
Basic Physical Network Connectivity
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.
Single Flat Network
Similar to Nova-network Flat or FlatDHCP manager.
Multiple Flat Networks
Mixed Flat + Private Networks
Single Provider Router
Similar to Nova-network VlanManager.
Per-Tenant Routers
Similar to Amazon VPC or CloudStack model.