Slides presented to OpenStack developer summit during the "Quantum Overview" session (note: these are not the slides presented during the conference, these slides are more technical, and less polished)
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Â
Quantum Folsom Summit Developer Overview
1. Intro to OpenStack Quantum
Dan Wendlandt â Quantum Hacker & PTL
dan@nicira.com
twitter - danwendlandt
2. Caveats
⢠Contents may shift in flightâŚ
⢠Quantum is young: there are lots of things
that it COULD do, but doesnât yet.
⢠I will not finish these slidesâŚ
3. Outline
⢠Why Quantum?
⢠What is Quantum?
â Basic Concepts & Demo
â High-level System Architecture
⢠Current Project Status
⢠Future Directions
⢠Frequently Asked Questions
5. What is OpenStack?
⢠Open Source Cloud SoftwareâŚ
⢠A collection of âcloud servicesâ
⢠Each service includes:
â A tenant-facing API that exposes
logical abstractions for consuming
the service.
â One or more backend
implementations of that API
7. Why Quantum?
⢠Networking was sub-component of Nova
⢠Two Key Problems:
#1: Limited technology âbaked inâ to design.
#2: No tenant control of networking.
8. Problem #1: Technology Limitations
⢠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.
9. Why Quantum? Reason #1
⢠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!
10. Problem #2: No Tenant Control
⢠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.
11. Why Quantum? Reason #2
⢠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.
12. All is Right with the WorldâŚ
*-as-a-Service Capability OpenStack Service
Compute Nova
Swift (Objects)
Storage
Glance (Images)
Network Quantum
15. Quantum Basics (by analogy to Nova)
Nova Quantum
*-as-a-service Compute Network
Major API abstractions âvirtual serversâ: represents âvirtual networksâ:
a host with CPU, memory, A basic L2 network segment.
disk, and NICs. âvirtual portsâ:
Attachment point for devices
connecting to virtual networks.
Interactions with other virtual servers use âvirtual virtual ports are linked to vNICs on
OpenStack services. imagesâ from Glance. âvirtual serversâ.
Supports different âvirt-driversâ for KVM, âpluginsâ for Open vSwitch Cisco
back-end technologies XenServer, Hyper-V, UCS, Linux Bridge, Nicira NVP, Ryu
VMWare ESX Controller (and more!).
API Extensibility for keypairs, instance rescue, quality-of-service, port statistics,
new or back-end volumes, etc. security groups, etc.
specific features.
16. API Abstractions
VM1 VM2 virtual server
Nova 10.0.0.2 10.0.0.3
virtual interface (VIF)
virtual port
Quantum Net1
virtual network
10.0.0.0/24
17. Quantum Rest API Abstraction Details
⢠Virtual Networks:
â Equivalent to a âvirtual VLANâ, a dedicated L2 segment.
â Example: quantum.foo.com/<tenant-id>/network/<network-id>
⢠Virtual Ports:
â Where a virtual interface (e.g., Nova vNIC) attaches to a network.
â Example: quantum.foo.com/<tenant-id>/network/<network-
id>/port/<port-id>
⢠API Extensions:
â Can add properties to existing network/port abstractions (e.g., QoS
settings for a virtual port).
â Can introduce new API entities (e.g., Security Groups that are linked to
ports, or L3 + NAT Forwarding Elements that attach to networks).
18. Old Model: Static Nova Networking
TenantA-VM1 TenantB-VM1 TenantA-VM2 TenantA-VM3
88.0.0.2 88.0.0.3 88.0.0.4 88.0.0.5
Public Net
88.0.0.0/18
⢠Single network exists (per-project or global).
⢠VMs automatically get a vNIC on that single network on boot.
⢠Tenants have no control over IP addressing.
19. 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
Public 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 from other services
(e.g., a load-balancing service).
20. Quantum Architecture Basics
⢠âPluginâ model give cloud operators choices:
â Advanced Features (exposed as API extensions)
â Cost
â Scale
â High Availability
â Hypervisor + Network HW Compatibility
â Manageability / Polish
⢠Abstract logical API
â tenants donât see underlying technologies
â Example: VLANs vs. tunneling
21. A bit about plugins (more later!)
⢠A common point of confusion.
⢠Define âquantum pluginâ:
Code that communicates with network devices to
implement a particular set of Quantum API calls.
⢠API currently has one set of calls for âbase L2â
networking => one plugin running at a time.
⢠A plugin is not a âdriverâ. A single plugin can
talk to different types of network devices.
22. Quantum Architecture (simple)
API 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
23. Quantum Architecture (advanced)
External
API 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
25. Project Status: Essex Cycle
⢠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 L2 API, with extension support.
â API client library and CLI
â Nova Integration via the QuantumManager
â Plugin framework & several publicly available plugins:
⢠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 .
26. Project Status: Two Deployment Models
⢠Proxied Quantum (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, but doesnât give tenantâs network control.
⢠Direct Quantum (Folsom Target):
â 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)
27. 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 first target for
widespread adoption.
28. Project status: Try it Yourself
⢠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/
29. Folsom Priorities #1
⢠Enable tenant control of networking
â Keystone Authn, Authz
â Expose IPAM to tenants (e.g., integrate Melange)
â Rework Nova integration (remove ties to Nova DB)
â Horizon integration, CLI rewrite.
30. Folsom Priorities #2
⢠Improve system quality + scale
â Unit test
â System-test
â CI-integration
â API scaling
31. Folsom Priorities #3
⢠Move networking from Nova to Quantum
â L3 Forwarding + NAT/Floating IPs
â Security Groups
â DHCP injection
â VPN (?)
⢠Follow Quantum pattern:
â Enable tenant control by extending existing API
â Allow pluggable backends
32. Developer, Developer Developers
⢠Folsom goals, including becoming
default network platform, are
VERY ambitious
⢠Weâll need many more developers
to:
â Implement new functionality
(particularly for open source
plugins!)
â Be familiar enough with Quantum
to answer user questions on
ML, launchpad, IRC, etc.
⢠Letâs help grow the team.
35. âCreate Networkâ in Proxied Mode
⢠Network created by cloud operator using
nova-manage:
⢠QuantumManager (QM) in Nova calls to
Quantum, creates network.
⢠QM creates IPAM subnet using Nova DB or
Melange.
⢠QM stashes resulting data in Nova DB.
36. âCreate VMâ in Proxied Mode
⢠Tenant uses Nova API to create VM
⢠Extension allows VM to pass in a list of network UUIDs
(see --nic option in novaclient)
⢠Nova-compute makes nova RPC call to
âallocate_for_instanceâ method of network manager.
⢠QM creates a VIF entry in nova DB for each attached
network.
⢠QM creates a Quantum port for each VIF, tells Quantum
the associated âvif-idâ.
⢠Nova-compute creates VM, and âvif-pluggingâ reports
bindings between âvif-idâ and âswitch portâ to Quantum
plugin.
37. âCreate Networkâ in Direct Mode
⢠Tenant contacts Quantum directly, passing in
network details, including associated IPAM
subnet.
⢠All data is stored in Quantum plugin (nothing
stored in Nova).
38. âCreate VMâ in Proxied Mode
⢠Tenant uses Nova API to create VM
⢠Extension allows VM to pass in a list of same
network UUIDs (see --nic option in
novaclient)
⢠Nova-compute makes direct REST call to
Quantum, creating a port for each network
(no more QM or nova-network)
⢠Nova-compute creates VM, and âvif-
pluggingâ reports bindings between
âquantum portâ and âswitch portâ to
Quantum plugin.
40. 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, agent finds q-
port + q-network associated with interface-
id, configures vswitch port with correct VLAN.
41. Persistent Data Stored by Plugins
⢠All persistent data (networks, ports, etc) is stored
by the plugin, not the API layer.
⢠Why?
â Data schema for plugin depends on plugin-specific
implementation details (e.g, networks -> VLANs)
â Data schema depends on supported extensions.
â Plugins may make different trade-offs around
scale, HA, data consistency, etc.
⢠Common data models are shared across plugins
using a library of âbaseâ SQLAlchemy models.
42. 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).
⢠Driver code can be shared across plugins with libraries.
43. 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.
45. Basic Quantum + Nova API Flow
API 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
46. 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
Communication
nova-compute
vswitch
XenServer #1
Internal Plugin
Communication Hypervisor
Hinweis der Redaktion
Common to run both Quantum and Nova on the same set of controller hosts.