quantum networks

© 2012 IBM Corporation

Architecture of Quantum Folsom Release

Yong Sheng Gong (龚永生)

[email protected]

gongysh #openstack-dev

Quantum Core developer

mailto:[email protected]


Agenda

■ OpenStack and Quantum

■ Quantum Architecture

■ Quantum models

■ communications among quantum components

© 2012 IBM Corporation 4

OpenStack: core projects that form a complete IaaS solution Compute (Nova) Provision and manage virtual machines

Dashboard (Horizon) Self-service portal

Image (Glance) Catalog and manage server images

Identity (Keystone) Unified authentication, integrates with existing systems

Network(Quantum) provide "network connectivity as a service"

Object Storage (Swift) petabytes of secure, reliable object storage

Block Storage (Cinder)

adapted from:

http://26a0ff8ca8ba32139f7d-db711c577a50b6bdc946ea71aaca027d.r97.cf1.rackcdn.com/openstack-conceptual-arch-folsom.jpg /

http://ken.pepple.info/openstack/2012/02/21/revisit-openstack-architecture-diablo/










http://26a0ff8ca8ba32139f7d-db711c577a50b6bdc946ea71aaca027d.r97.cf1.rackcdn.com/openstack-conceptual-arch-folsom.jpg


Compute

Storage

Network

Nova

Swift (Objects)

Glance (Images)

*-as-a-Service Capability OpenStack Service

Quantum

Cinder (Block)

identity Keystone

Quantum-NaaS


Openstack architecture

Queue

quantum database

l3-agent

plugin-agent

dhcp-agent

REST

quantum-server

OpenStack Identity API

OpenStack Network API

OpenStack Network API


Flow of booting a virtual server


Quantum uses network virtualization

1.Hypervisor

2.nova-scheduler

3.nova-computes

1.quantum-server

2.plugin

3.agents


Agenda



■ Quantum models



One of Deployment Models

■ Management network. Used for internal communication between OpenStack Components. The IP addresses on this network should be reachable only within the data center.

■ Data network. Used for VM data communication within the cloud deployment. The IP addressing requirements of this network depend on the Quantum plugin in use.

■ External network. Used to provide VMs with Internet access in some deployment scenarios. The IP addresses on this network should be reachable by anyone on the Internet.

■ API network. Exposes all OpenStack APIs, including the Quantum API, to tenants. The IP addresses on this network should be reachable by anyone on the Internet. This may be the same network as the external network, as it is possible to create a quantum subnet for the external network that uses IP allocation ranges to use only less than the full range of IP addresses in an IP block.

from http://docs.openstack.org/trunk/openstack-network/admin/content/connectivity.html


Another one of Deployment Models

DHCP L3

Multi-host -> Multi-L3 Nodes?


Components of quantum

Quantum

server & plugin Plugin

agent

DHCPagent

DB Queue

■Quantum server

Implement Qauntum API and its extensions

Enforce network model

• Network, subnet, and port

IP addressing to each port

■Plugin agent

Run on each compute node

Connect instances to network port

■DHCP agent

In multi-host mode, run on each compute node (deferred)

Start/stop dhcp server

Maintain dhcp configuration

L3-agent To implement floating Ips and other L3

features, such as NAT

One per network

■Queue

Enhance communication between each components of quantum

■DB – persistent network model

Note: we can share DB service and Queue

with other OpenStack stack services

l3-agent


Layers in Quantum server

Quantum API and extensions

Common service

(Validation, Authn, Authz)

Plugin API

DB

Plugin

device

Quantum Core

vendor specific plugin or open source plugin:

1. linux bridge plugin

2. openvswitch plugin

3. nicira

4. …

vendor can add extensions

to provide more features


Agenda



■ Quantum models



Quantum models


Network and physical bindings

local

Flat

VLAN

GRE

Network binding

GRE and local bindings have no physical network

Linux bridge plugin has no GRE support

network

Physical network Identified by name

Virtual network Model in quantum

Tenant network provider network

Local binding are for devstack single box playing

Difference between provider network and tenant network?


Other ways to view networks

Private internal networks

private shared

external

internal

we can create floating ips and router gateway on it, They should be able to access public network

Other tenants besides the owner tenant can create ports on it.

Only owner tenant can create ports on it.

Private external networks

Shared internal networks

shared external networks

Only fixed Ips are allocated from there.


A network sample for fixed ips

Physnet1 vSwitch br-eth1

Physical net1 vlan ID 1000

Physnet2 vSwith br-eth2

physical net2 Flat

br-int

br-tun

GRE

host B

int-br-eth1

phy-br-eth1

int-br-eth2

phy-br-eth2

patch-tun

patch-int

patch-port

veth

Host A

host C

host C

network A local Vlan ID 1

network B local Vlan ID 2

network C local Vlan ID 3

local vlan id <-> tunnel id done by br-tun flow local vlan id <-> physical net vlan id done by physical net and br-int vSwitch

VM ports

DHCP ports

eth1 eth2


Floatingip and Router

internal nework External network router

gw_port 7.0.1.2/24 Floating ip: 7.0.1.4/24

Router interface 10.0.1.1/24 In general,

The port acting as router interface should has gateway address of subnet

Floatingip port

Floating ip fixed port on fixed ip network

l3_agent

external network vswitch br-ex

Vm 10.0.1.5/24 gw: 10.0.1.1/24

eth0

Router is used for VM to access outside and allow VMs on different subnets or networks access each other Floating IP is used for outside to access VM

Vm 20.0.1.5/24 gw: 20.0.1.1/24


A network sample for fixed ips and routers


Physical net1 vlan ID 1000


physical net2 Flat

br-int

br-tun

GRE

Host A ovs-quantum-agent




VM ports

DHCP ports

eth1 eth2

Router interface ports



br-int

br-tun

GRE

Host B L3-agent ovs-quantum-agent dhcp-agent




eth1 eth2

br-ex

external network D binding: local

Router gateway and flaoting ip ports

eth0

public net


Agenda



■ Quantum models



Quantum topic

q-plugin

Exchange:

Queue: notifications.info

quantum-server Dhcp agent

q-agent-notifier- network-delete_fanout

fanout

q-agent-notifier- tunnel-update_fanout

fanout

q-agent-notifier- port-update_fanout

fanout

q-agent-notifier- network-delete_fanout

_{uuid4}

q-agent-notifier- tunnel-update_fanout

_{uuid4}

q-agent-notifier- port-update_fanout

_{uuid4}

Plugin agent Comsumer:

get_device_details update_device_down tunnel_sync

Quantum rest api (resource CUD)

tunnel_update network_delete port_update

get_active_networks get_network_info get_dhcp_port release_dhcp_port release_port_fixed_ip update_lease_expiration

Plugin agent

Dhcp agent

quantum-server

AMQP communication among quantum components


Data flow of booting a virtual server among quantum components


Enjoy hacking OpenStack!


Backup – San Diego design summit

http://wiki.openstack.org/Summit/Grizzly/Etherpads

quantum networks

Documents