Quantum (OpenStack Meetup Feb 9th, 2012)

Intro to OpenStack QuantumDan Wendlandt – Quantum Hacker & PTL dan@nicira.com twitter - danwendlandt

Outline• Why Quantum?• What is Quantum? – API – High-level System Components• Current Project Status• Future Directions• Frequently Asked Questions

Why Quantum? Reason #1

Enterprise applications have sophisticated networking requirements Image curtsey of “the Hoff”: http://rationalsecurity.typepad.com/blog/2008/08/all-your-virtua.html

Traditional “clouds” provide little/no network control.Example of NovaNetwork “multi-NIC”.Each VM gets VIF onsame two networks,regardless of tenant.

Why Quantum? Reason #1• To attract enterprise workloads, cloud must give tenants the tools + control for enterprise- class networking. – Rich multi-tier topologies – Insert services (FW, VPN, IDS, etc.) – QoS guarantees for SLAs – Security & Monitoring for compliance• Quantum API can allows user control to build advanced networking configurations.

Why Quantum? Reason #2

Cloud Networking Challenges• Cloud environments stress networks like never before: – High-density multi-tenancy – Massive scale – Strong price pressure. – VM mobility – EVERYTHING must be automated

New approaches are looking to tackle these issues• Software-Defined Networking / OpenFlow• VXLAN / NVGRE• * insert other solution here…. +

Why Quantum? Reason #2• New technologies are needed to cope with new challenges in cloud networking.• Existing Nova implementation used basic Linux Bridge + VLANs (very limiting)• Quantum provides a “plugin” mechanism to enable different technologies implement calls made via the Quantum API.• Choice is a good thing!

Why Do You Care?• Cloud Provider / OpenStack consultants: Help understand how Quantum can overcome limitations of existing Nova networking.• Network Vendor: learn how you can integrate with or contribute to Quantum.• Cloud User: Help is on the way!

What is Quantum?

Quantum Basics Nova : virtual server Quantum : virtual networkQuantum is:- Expose a API for creating virtual networks and attaching instances (e.g., nova servers) to those networks.- Manage switches (virtual or physical) in the data center to implement connectivity described via API.- Provide a “plugin” architecture to leverage support using different back-end technologies.

Quantum API Abstractions• Networks: – Equivalent to a “virtual VLAN”, a dedicated L2 segment. – Tenants use Quantum API to create networks, get back UUID: – Example: quantum.foo.com/<tenant-id>/network/<network-id>• Ports: – When an interface (e.g., Nova vNIC) is attached to a network, attachment point is a “port”. – Ports expose configuration and monitoring state (e.g., ACLs, QoS policies, Packet Statistics) – Example: quantum.foo.com/<tenant-id>/network/<network- id>/port/<port-id>

Basic Quantum + Nova API FlowAPI 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

Old Model: Static Nova Networking Nova i-23 Nova i-26 Nova i-22 Nova i-24 10.0.0.23 10.0.0.26 10.0.0.22 10.0.0.24 Tenant-A Net • Single network exists (per-project or global). • VMs automatically get a vNIC on that single network on boot.

New Model: Dynamic Network Creation + Association Nova i-23 Nova i-26 Nova i-22 Nova i-24 10.0.0.23 10.0.0.26 10.0.0.22 10.0.0.24 Tenant-A Tenant-A Net #1 Net #2Internet • 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).

Quantum API Principles• Implementation Abstraction: At no time does the customer see details of how a network is implemented (e.g., VLANs).• Explicit Association: Association of interfaces with network is an explicit step  more control.• API Extensions: Plugins can expose API extensions to introduce more complex functionality (e.g., QoS). Extension support is queriable, so a customer can “discover” capabilities.• Extension Refactoring: API extensions that represent common functionality across many plug-ins can become part of the core API.• API Evolution: Core API is currently simple, focused on connectivity. Core API will evolve.

Plugin Architecture• “Quantum Plugin” design allows abstract network/port API to be implemented using many different technologies.• Plugins perform two main tasks: – Process all API calls: store the results of all network + port calls, while mapping abstract entities to a plugin-specific technology (e.g., map a network to a VLAN) – Manage switches: learn about nova interfaces when they are attached to the network and configure network switches accordingly.

Quantum ArchitectureAPI Clients Quantum Server Internal plugin communication. Uniform API Quantum Quantum for all clients API Plugin Tenant Create-net Create-net Scripts . . Nova Computeswitch virtual . . Nova Compute Horizon Nova Compute . . Nova Compute Create-port Create-port Nova Compute Nova Interfaces from a service like Nova plug into a switch manages by the API + Plugin = Quantum Service Quantum plugin.

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, finds q-port + q- network associated with interface-id, configures vswitch port with correct VLAN.

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 CommunicationTwo Plugins Available: nova-compute- Open vSwitch- Cisco UCS/Nexus vswitch XenServer #1 Internal Plugin Communication Hypervisor

Key Take-away• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” *• A “plugin” is NOT a “driver” * * Explained on next slide….

A plugin is not a driver• A plugin registers to handle all Quantum API calls in a “group” (e.g., all network/port calls).• Because Quantum only has one “group” of API calls right now, only one plugin runs at a time (this will change as APIs expand beyond L2).• A single plugin may talk to multiple types of switches (i.e., it may have multiple “drivers”)• “driver” code can be shared across plugins.

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

Current Project Status

Project Status: Essex Cycle• Started at Diablo summit, became “incubation” for Essex, will apply to be “core” in Folsom.• Available at: http://launchpad.net/quantum• Docs at: http://docs.openstack.org/incubation/• Current Features: – v1.1 of the Quantum L2 API, with extension support. – API client library and CLI – Nova Integration via the QuantumManager – OpenStack Dashboard Integration (a bit borked right now…) – Plugin framework & two publicly available plugins: • Open vSwitch Plugin • Cisco UCS/Nexus Plugin • Linux Bridge Plugin – Packaging for Ubuntu / Red Hat / Debian + more.

Project Status: Two Deployment Models• Model #1 (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.• Model #2 (few months out): – Tenants can create their own networks, determine their own IP addressing via Quantum API. – Tenants can insert other services exposed by service provider (e.g., router, VPN) using extensions.

Project Status: Who should use Quantum?• “Early adopters” are already putting Quantum into their OpenStack trial deployments.• Expect early adopters to go live with Quantum in spring / summer.• Caution: deployments are by bleeding edge, working closely with someone who knows Quantum well.• Folsom release will be first target for widespread adoption.

Future Directions• More L2 Plugins – Linux Bridge, Ryu Controller, Nicira NVP, Brocade• Beyond L2: Advanced Network Services – L3 routing + NAT, Firewall, VPN, DHCP, LB – Services may be part of Quantum, or separate projects that integrate with Quantum. – Additional services will be independently pluggable (i.e., can choose L2 plugin X, L3 plugin Y)• RBAC via API to allow for fine grain controls among users of the same tenant.

Play with Quantum• New integrated with DevStack• http://wiki.openstack.org/QuantumDevstack• Use nova-manage to create networks• Spin up VMs with -- nic option.• See Quantum Administrator Guide for details – http://docs.openstack.org/incubation/openstack- network/admin/content/

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.

Thanks! Questions / Comments? Come join us: http://wiki.openstack.org/Quantum netstack@lists.launchpad.net Dan Wendlandt Dan@nicira.com Twitter: danwendlandt http://www.slideshare.net/danwent/

Quantum (OpenStack Meetup Feb 9th, 2012)

by Dan Wendlandt on Feb 20, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Quantum (OpenStack Meetup Feb 9th, 2012) Presentation Transcript