true

1. OpenStack Quantum:
Taking OpenStack Networking to New Heights
Dan Wendlandt
dan@nicira.com
dwendlandt@vmware.com
Openstack Quantum Hacker & Project Team Lead
twitter - danwendlandt

2. Aaron Rosen, Quantum core dev at VMware, show his OpenStack Quantum team pride.

3. Outline
• Why Quantum?
• What is Quantum?
– API Abstractions
– Plugin Architecture
• Project Status
• Deployment Scenarios
• Looking Forward
• Questions

4. Why Quantum?

5. Networks for Enterprise Applications
are Complex….
Image from windowssecurity.com

6. 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

7. Cloud Stresses the Network….
• High-density multi-tenancy
– But VLANs limit scale
• 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

8. 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 (more later).

9. What is Quantum?

10. 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”

11. 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).

12. 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).

13. 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.

14. 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”

15. 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

16. 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!

17. 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

18. Quantum Plugins
Open source plugins based on Open vSwitch and Linux
Bridge exist (works with any hardware switches).
The following vendors have publicly stated that they already have
or are developing a Quantum plugin (others exist as well). In some
cases, vendor hardware is required.

19. Project Status

20. A Growing Team…

21. 6 Months Ago…
• Incubation release (Essex, April ‘12)
– v1 API, basic L2 API abstractions.
– Quantum API used by nova-network, but not
exposed to tenants.
– Plugin architecture to enable choice of back-end
technology.
– In production at early adopters.

22. Today
• 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

23. Tenant Network Control (Horizon)

24. Tenant Network Control (Horizon)

25. Tenant Network Control (Horizon)

26. What’s going to happen to nova-network?
• No forced upgrade in Folsom, or Grizzly.
• Existing nova-network stays even with
Quantum in core.
• Planning an “orderly transition”
1) Freeze on adding new functionality in
nova-network (already in effect).
2) Make sure Quantum covers all important
nova-network scenarios (target Grizzly)
3) Nova MAY simplifying nova-network code
by removing all but basic networking
support in subsequent release (possible
target H-release)

27. Should I start using Quantum?
• Go back to reasons project was created:
– API to build rich network topologies, insert
services.
– Overcome limitations of traditional networking
solutions (e.g., VLANs).
• If these are important to your OpenStack
deployment, go for it!
• Otherwise staying with nova-network is fine.

28. 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

29. Get Hands On!
Hands on Quantum Deployment Workshop
Thursday 9:00 – 10:30 am @ Manchester E

30. Deployment Use Cases

31. Basic Physical Network Connectivity

32. 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.

33. Single Flat Network
Similar to Nova-network Flat
or FlatDHCP manager.

34. Multiple Flat Networks

35. Mixed Flat + Private Networks

36. Single Provider Router
Similar to Nova-network
VlanManager.

37. Per-Tenant Routers
Similar to Amazon VPC or
CloudStack model.

38. Looking Forward

39. Grizzly Quantum: where are we going?
• Closing gaps:
– Security groups & metadata
service compatible with
overlapping IPs.
– Support L3-forwarding & DHCP
on compute nodes (similar to
nova “multi_host” flag)
• Advanced Services
– Load-balancing
– VPN

40. Talks by Quantum Users @ Summit
Wed @ 9:30 am
Includes
production
Wed @ 11:00 am Quantum
deployments
that have been
Wed @ 2:40 pm running for 6+
months on
Essex!
Wed @ 4:10 pm

41. Key Takeaways
• Quantum enables advanced networking in
OpenStack:
– API to configure rich network topologies.
– Plugin architecture for leveraging new network
technologies.
• With “core” status, expect jump in Quantum
production deployments in Folsom.
• Quantum team is growing quickly, come join!

42. Thanks! Questions?
Slides available at: http://www.slideshare.net/danwent
Dan Wendlandt
dan@nicira.com
dwendlandt@vmware.com
OpenStack Quantum Hacker & Project Team Lead
twitter - danwendlandt