2. Outline• Why Quantum?• What is Quantum – Live Demo!• What is Quantum – Architecture• Current Project Status• Future Directions• Frequently Asked Questions
3. In the beginning..*-as-a-Service Capability OpenStack Service Compute Nova Swift (Objects) Storage Glance (Images) Network ?
4. Why Quantum?• Networking API strongly coupled as part of Nova(Compute) APIs• OpenStack Networking model was very rigid. – Flat Networking – FlatDHCP Networking – Or VLAN-based Networking model – One- Size fits all use-cases.• No support for integrating external NW services like best of breed Firewall and Load Balancers.• No “pluggability” in the Networking Architecture to take advantage of best of breed vendors or emerging SDN techniques.
5. Problem #1: Stone-age technology• 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.
6. Why Quantum? Reason #1 Advanced Technologies & Choice!• 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!
7. Problem #2: Rigid Networking model• 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.
8. Why Quantum? Reason #2 Flexible Enterprise-class Networking!• 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.
9. All is Right with the World…*-as-a-Service Capability OpenStack Service Compute Nova Swift (Objects) Storage Glance (Images) Network Quantum
10. OpenStack Quantum Demo! – Complex Enterprise Apps Tenant Coca-Cola Enterprise App Data2-net ExtendNet VM Tenant Pepsi Enterprise App Data2-net ExtendNet VM VM Data2-net ExtendNet VM VMVM VM VM VM VM VM Data1-net VM VM VM VM VMVM VM VM VM VM Data1-net VM VM VM VM VM VM VM VM VM VM Data1-net VM Mgmt-net VM VM VM VM Mgmt-net Mgmt-net
11. OpenStack Quantum – Architecture Basics• During demo tenant didn’t see the technology used to implement L2 isolation (VLANs, tunneling, etc.).• Key tenets: – Abstract logical API – “pluggable engine” back-end gives choice.• Pluggable engines will give operators choice of: – Advanced Features – Cost – Scale – High Availability – Hypervisor + Network HW Compatibility – Manageability / Polish
12. Quantum ‘Engine’ Architecture – SimpleAPI 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
13. Quantum ‘Engine’ Architecture - Advanced 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
14. OpenStack Folsom Architecture with Quantum COMPUTE NODE• OpenStack Architecture as of Essex• Network components are passed from Nova to Quantum QUANTUM MGR• In Folsom, Layer DHCP L3/NAT 3/NAT/DHCP will move from Nova QUANTUM to Quantum. PLUG-IN
15. Project Status: Essex Release• 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 Layer 2 API, with extension support. – API client library and CLI – Nova Integration via the QuantumManager – Pluggable Engine Framework • 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 .
16. Project Status: Two Deployment Models• Proxied Quantum (available as of Essex release): – 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 (available in Folsom release): – 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)
17. 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 targeted for widespread adoption.
18. How do I use OpenStack Quantum?• 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/
19. Folsom Direction• Tenant Control of Networking – Keystone Authn, Authz – Expose IPAM to tenants (Integrate Melange project) – Nova Integration enhancements – Horizon integration, CLI rewrite.• Move networking from Nova to Quantum – L3 Forwarding + NAT/Floating IPs, – Security Groups – DHCP injection• Follow Quantum pattern: – Enable tenant control by extending existing API – Allow pluggable backends ‘engines’
20. Finally! - Frequently Asked Questions• Is OpenFlow required for Quantum Answer: Nope! OpenFlow is just one technology that Quantum enables.• Is Quantum “software-defined networking”? Answer: It depends…• How does Quantum compare to Amazon VPC? Answer: Have similar goal of enabling advanced networking in cloud. Quantum will give cloud operators ability to compete with (and go beyond) VPC feature- set.