The document discusses the integration of OpenStack Nova and Quantum for managing and networking virtual machines in large data centers, highlighting challenges and solutions provided by this technology. It contrasts OpenStack with AWS's Virtual Private Cloud (VPC), emphasizing OpenStack's open and scalable platform and its plug-in architecture for enhanced network management. Future directions for Quantum include seeking core project status, adding new plugins, and improving integration with other services.

1. OpenStack Nova and Quantum
Dave Lapsley
dlapsley@nicira.com

2. Outline
• What is the challenge?
• How do Nova + Quantum meet the challenge?
• What about AWS VPC?
• Quantum Architecture
• Where is Quantum headed?

3. Nova/Quantum Architecture http
Dashboard
EC2/Openstack API
EC2/Admin API
Glance API
Glance API Nova API
Nova
Compute
Nova
Glance Image Nova Network/
Nova
Registry Store Queue Quantum
Database
(swift,etc) Manager
Glance
Database
Volume Nova Nova
Storage Volume Schedule
Adapted from http://ken.pepple.info/openstack/2011/04/22/openstack-nova-architecture/

4. Large data centers today can have
around 2.4 million Virtual Machines
How do we manage and network
these virtual machines and the
services built around them?

5. OpenStack provides an open-source,
innovation-enabling platform for
doing just this
Open, scalable, secure, and
manageable computing and
networking in the cloud*
* Storage too! But that’s an entire presentation in itself.

6. OpenStack Nova  Virtualize Computation
Hypervisor 1 Hypervisor 32
VM VM VM VM VM VM VM VM
VM VM VM VM VM VM VM VM
VM VM VM VM VM VM VM VM
VM VM VM VM VM VM VM VM
to Public Network
Physical Network
Hypervisor 992 Hypervisor 1024
VM VM VM VM VM VM VM VM
VM VM VM VM VM VM VM VM
VM VM VM VM VM VM VM VM
VM VM VM VM VM VM VM VM

7. How do we manage connectivity?
Tenant
VM
VM Tenant
VM
VM VM
VM VM VM
VM
VM VM
VM VM
VM VM VM
VM VM VM
VM
VM
VM VM VM
VM VM
VM VM
VM
VM
VM
Public Network Accesss VM
VM
VM
VM
VM VM VM VM
VM VM VM VM
VM VM
VM VM VM
VM
VM VM
VM
VM VM
VM VM VM
VM
VM
VM VM VM Tenant
VM
VM
Tenant

8. Quantum  Virtualize Network
Tenant A Tenant B Tenant C
S S S
S S WS WS
S
S
IDS
IPS
S
IPS
FW WS
WS
FW
Public Network Access
Tenant D
FW FW WS
WS
IDS
IPS IPS
S
IDS
S
S
S S S S S S S S

9. Quantum
• A standalone OpenStack service
• Provides network connectivity between a set of
network interfaces from other services
• Exposes API of logical abstractions for describing
network connectivity + policy between interfaces.
• Uses a plug-in architecture, so multiple
technologies can implement the logical
abstractions
• Provides a technology agnostic platform for
sophisticated cloud network topologies

10. AWS VPC
• Amazon Web Service Virtual Private Cloud
– “…lets you provision a private, isolated section of the
Amazon Web Services (AWS) Cloud where you can
launch AWS resources in a virtual network that you
define.”
– Similar goals and functionality to OpenStack Quantum
• But… different ecosystem
– Closed system
– Provided API and that’s it
– Must use AWS
• Compare with Nova + Quantum

11. Quantum: Single Service
OpenStack Dashboard
Quantum Plugin nova-api
Tenant API
Quantum Service
Nova Service
nova-api
quantum-plugin nova-scheduler
Internal plugin
communication
VM VM VM nova-compute
VM VM VM VM VM
Hypervisor
VM VM VM VM VM VM VM VM
vswitch

12. Quantum: Two Services
OpenStack Dashboard
firewall service Quantum Plugin nova-api
Tenant API
Quantum Service
Nova Service
nova-api
quantum-plugin nova-scheduler
Internal plugin
communication
VM firewall service
VM VM VM VM VM VM nova-compute
VM VM VM VM VM
Hypervisor
FW FW FW FW VM VM VM VM VM VM VM VM
physical switch vswitch

13. Quantum Architecture
Tenant API Admin API
Auth (via Keystone)
Plugin might
manage just the
API Access Control network edge
Plugin interface maps to
(e.g., a vswitch),
“core” tenant API +
or all network
admin API.
Plugin devices.
External Devices
Plugin communicates with external devices to “Network agents” running on nova
implement logical abstractions from the tenant hypervisor fit within this model.
API

14. Virtual Network Abstractions (1)
• Interface IDs:
– Services (e.g., nova, atlas) expose interface-IDs via their own tenant APIs to represent any
device from that service that can be “plugged” into a virtual network.
– Example: nova.foo.com/<tenant-id>/server/<server-id>/eth0
• Networks:
– Tenants use Quantum API to create networks, get back UUID:
– Example: quantum.foo.com/<tenant-id>/network/<network-id>
• Ports:
– Tenants can create ports on a network, get a UUID, and associate config with those ports (APIs
for advanced port config are TBD, initially ports give L2 connectivity):
– Example: quantum.foo.com/<tenant-id>/network/<network-id>/port/<port-id>
• Attachments:
– Tenants can “plug” an interface into a port by setting the attachment of a port to be the
appropriate interface-id.
– Example: set quantum.foo.com/<tenant-id>/network/<network-id>/port/<port-id>/attach
to value “nova.foo.com/<tenant-id>/server/<server-id>/eth0” .

15. Virtual Network Abstractions (2)
• 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.

16. Example Scenario
Nova i-23 Nova i-26 Nova i-22 Nova i-24 GW instance
10.0.0.23 10.0.0.26 10.0.0.22 10.0.0.24 10.0.0.1
Tenant View
Private Private
Net #1 Net #2
Hypervisor 1
Nova i-23 Nova i-22
10.0.0.23 10.0.0.22
Provider View
Data GW instance
Center 10.0.0.1
Hypervisor 2 Nework
Nova i-26 Nova i-24
10.0.0.26 10.0.0.24
Compute Service NAT Gateway Service

17. Example Scenario w/ VLAN Plugin
Nova i-23 Nova i-26 Nova i-22 Nova i-24 GW instance
Tenant View 10.0.0.23 10.0.0.26 10.0.0.22 10.0.0.24 10.0.0.1
Private Private
Net #1 Net #2
Hypervisor 1
Nova i-23 Nova i-22
10.0.0.23 10.0.0.22
Provider View
Data GW instance
Center 10.0.0.1
Hypervisor 2 Nework
Nova i-26 Nova i-24
10.0.0.26 10.0.0.24
Compute Service NAT Gateway Service

18. VLAN Plugin
• One VLAN per “network”
• Hypervisor NIC is VLAN trunk, all switches are
trunked.
• When an interface-ID is associated with a
network, plugin uses the edge binding to find
the interface-location (a port on a vswitch)
and puts that port on the correct VLAN.

19. Future Directions
• Applying for core project status for Folsom
• Expect 5-10 new plugins in next 6 months.
• Support for new overlay technologies like NVGRE
+ VXLAN
• L3 routing + Firewall capabilities via new
Quantum API
• VPN, data-center-interconnect technologies.
• Closer integration with Melange (IP address
management)
• Improved Horizon integration.

20. Summary
• What is the challenge?
– Managing and networking data centers and their services
• How do Nova + Quantum meet the challenge?
– Open, scalable, secure, and manageable computing and
networking in the cloud*
• What about AWS VPC?
– Great goals! Not open.
• Quantum Architecture
– Network connectivity as a service, API of logical abstractions,
plug-in architecture, service pluggability.
• Where is Quantum headed?
– Core status, new plugins, new technologies, L3/FW + new API,
VPN DCI technologies, closer integration with IPAM and Horizon

21. Thank you
dlapsley@nicira.com
http://wiki.openstack.org/Quantum