OpenStack
Super
Bootcamp
Mirantis, 2012
Agenda
OpenStack Essex architecture recap
Folsom architecture overview
Quantum vs Essex's networking model
Initial State
Tenant is created, provisioning
quota is available, user has an
access to Horizon/CLI
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 1: Request VM Provisioning via UI/CLI
User specifies VM params:
name, flavor, keys, etc. and hits
"Create" button
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 2: Validate Auth Data
Horizon sends HTTP request to
Keystone. Auth info is specified
in HTTP headers.
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 2: Validate Auth Data
Keystone sends temporary
token back to Horizon via HTTP.
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 3: Send API request to nova-api
Horizon sends POST request to
nova-api (signed with given
token).
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 4: Validate API Token
nova-api sends HTTP request to
validate API token to Keystone.
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 4: Validate API Token
Keystone validates API token
and sends HTTP response with
token acceptance/rejection info.
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 5: Process API request
Horizon
nova-api parses request and
validates it by fetching data from
nova-db. If request is valid, it
saves initia db entry about VM
to the database.
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 6: Publish provisioning request to queue
Horizon
nova-api makes rpc.call to
scheduler. It publishes a short
message to scheduler queue
with VM info.
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 6: Pick up provisioning request
scheduler picks up the message
from MQ.
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 7: Schedule provisioning
Horizon
Scheduler fetches information
about the whole cluster from
database and based on this info
selects the most applicable
compute host.
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 8: Start VM provisioning on compute node
Horizon
Scheduler publishes message
to the compute queue (based on
host ID) and triggers VM
provisioning
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 9: Start VM rendering via hypervisor
Horizon
nova-compute fetches
information about VM from DB,
creates a command to
hypervisor and delegates VM
rendering to hypervisor.
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 10: Request VM Image from Glance
hypervisor request VM image
from Glance via Image ID
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 11: Get Image URI from Glance
If image with given image ID
can be found - return
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 12: Download image from Swift
Horizon
hypervisor downloads image
using URI, given by Glance,
from Glance's back-end. After
downloading - it renders it.
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 13: Configure network
nova-compute makes rpc.call to
nova-network requesting
networking info.
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 14: allocate and associate network
nova-network updates tables
with networking info and VM
entry in database
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 15: Request volume attachment
Tenant is created, provisioning
quota is available, user has an
access to Horizon/CLI
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Initial State
Tenant is created, provisioning
quota is available, user has an
access to Horizon/CLI
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Still part of nova
Horizon
CLI
Keystone
nova: Cloud Controller
nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Limitations?
Nova is "overloaded" to do 3 things
Compute
Networking
Block Storage
API for networking and block storage are still
parts of nova
Keystone
UI: horizon or CLI
keystone
server
nova
compute node
controller
queu
e
nova-api
nova:
novaCompute
Hypervisor
compute
Quantum
V
M
scheduler
keystone
-db
quantum
server
nova-db
Network
quantum
-db
Cinder
endpoint
scheduler
cinder-db
queu
e
cinder-vol
block
storage
node
glance-api
storage
glance-registry
Glance
quantum
plugin
Swift
proxy-server
glance
db
object
store
Keystone
UI: horizon or CLI
keystone
server
nova
compute node
controller
queu
e
nova-api
nova:
novaCompute
Hypervisor
compute
Quantum
V
M
scheduler
keystone
-db
quantum
server
nova-db
Network
quantum
-db
Cinder
endpoint
scheduler
cinder-db
queu
e
cinder-vol
block
storage
node
glance-api
storage
glance-registry
Glance
quantum
plugin
Swift
proxy-server
glance
db
object
store
Essex' networking model overview
single-host vs multi-host networking
the role of network manager
different network manager types
floating IPs
Revisit of KVM networking with linux bridge
router
router: 10.0.0.1
(def. gateway for VMs)
VM
10.0.0.2
nova-compute host
VM
10.0.0.4
VM
10.0.0.3
VM
10.0.0.5
linux
bridge
linux
bridge
eth0
eth0
switch
nova-compute host
Single-host networking
KVM host == nova-compute
router == nova-network
eth1
public ip
routing/NAT
eth0
nova-network host
eth0 IP:10.0.0.1
(def. gateway for VMs)
VM
10.0.0.3
VM
10.0.0.4
VM
10.0.0.2
nova-compute host
VM
10.0.0.5
linux
bridge
linux
bridge
eth0
eth0
switch
nova-compute host
What happens if nova-network host dies
VM:~root$ ping google.com
eth1
No route to host
routing/NAT
eth0
VM
10.0.0.2
nova-compute host
VM
10.0.0.4
VM
10.0.0.3
VM
10.0.0.5
linux
bridge
linux
bridge
eth0
eth0
switch
nova-compute host
Multi-host networking
Move routing from the central server
to each compute node independently to
prevent SPOF.
eth1
routing/NAT
eth0
public ip
public ip
eth1
eth1
routing/NAT
routing/NAT
VM
10.0.0.2
nova-compute &
nova-network host
VM
10.0.0.4
VM
10.0.0.3
VM
10.0.0.5
linux
bridge
linux
bridge
eth0
eth0
switch
nova-compute &
nova-network host
Multi-host networking
Compute servers maintain Internet access independent from each other. Each of
them runs nova-network & nova-compute components.
public ip
public ip
eth1
eth1
routing/NAT
routing/NAT
VM
10.0.0.2
10.0.0.1(gw)
VM
10.0.0.4
VM
10.0.0.3
linux
bridge
10.0.0.6(gw)
linux
bridge
eth0
eth0
nova-compute &
nova-network host
VM
10.0.0.5
switch
nova-compute &
nova-network host
Multi-host networking - features
Independent traffic:
Instances on both compute nodes access external
networks independently. For each of them, the local linux
bridge is used as default gateway
Multi-host networking - features
Independent traffic:
Instances on both compute nodes access external
networks independently. For each of them, the local linux
bridge is used as default gateway
Routing:
Kernel routing tables are checked to decide if the packet
should be NAT-ed to eth1 or sent via eth0
Multi-host networking - features
Independent traffic:
Instances on both compute nodes access external
networks independently. For each of them, the local linux
bridge is used as default gateway
Routing:
Kernel routing tables are checked to decide if the packet
should be NAT-ed to eth1 or sent via eth0
IP address management:
nova-network maintains IP assignments to linux bridges
and instances in nova database
Network manager
Determines network layout of the cloud
infrastructure
Capabilities of network managers
Plugging instances into linux bridges
Creating linux bridges
IP allocation to instances
Injecting network configuration into instances
Providing DHCP services for instances
Configuring VLANs
Traffic filtering
Providing external connectivity to instances
FlatManager
Features:
Operates on ONE large IP pool. Chunks of it are shared between tenants.
Allocates IPs to instances (in nova database) as they are created
Plugs instances into a predefined bridge
Injects network config to /etc/network/interfaces
eth1
eth1
VM
VM
/etc/network/interfaces:
"address 10.0.0.2
gateway 10.0.0.1"
linux
bridge
linux
bridge
eth0
nova-compute &
nova-network
eth0
nova-compute &
nova-network
10.0.0.1(gw)
FlatDHCPManager
Features:
Operates on ONE large IP pool. Chunks of it are shared between tenants
Allocates IPs to instances (in nova database) as they are created
Creates a bridge and plugs instances into it
Runs a DHCP server (dnsmasq) for instances to boot from
eth1
VM
eth1
VM
obtain dhcp static lease:
ip: 10.0.0.2
gw: 10.0.0.1
dnsmasq
eth0
nova-compute &
nova-network
linux
bridge 10.0.0.1(gw)
eth0
nova-compute
& nova-network
DHCP server (dnsmasq) operation
is managed by nova-network component
in multi-host networking runs on every compute node and
provides addresses only to instances on that node (based
on DHCP reservations)
eth1
VM
ip: 10.0.0.4
gw: 10.0.0.3
dnsmasq: static leases for
10.0.0.4 & 10.0.0.6
eth1
VM
ip: 10.0.0.6
gw: 10.0.0.3
linux
bridge
10.0.0.3(gw)
VM
ip: 10.0.0.5
gw: 10.0.0.1
VM
ip: 10.0.0.2
gw: 10.0.0.1
dnsmasq: static leases for
10.0.0.2 & 10.0.0.5
eth0
linux
bridge
eth0
nova-compute &
nova-network
nova-compute
& nova-network
switch
10.0.0.1(gw)
VlanManager
Features:
Can manage many IP subnets
Uses a dedicated network bridge for each network
Can map networks to tenants
Runs a DHCP server (dnsmasq) for instances to boot from
Separates network traffic with 802.1Q VLANs
eth1
eth1
VM_net2
VM_net1
VM_net1
VM_net2
br100
br200
dnsmasq_net1
eth0
nova-compute &
nova-network
dnsmasq_net2
eth0.100
nova-compute
& nova-network
eth0 eth0.200
VlanManager - switch requirements
The switch requires support for 802.1Q tagged VLANs to
connect instances on different compute nodes
eth1
eth1
VM_net1
VM_net2
VM_net2
VM_net1
br100
br200
br100
br200
eth0.100
nova-compute
& nova-network
eth0.200
eth0 eth0.200
nova-compute
& nova-network
tagged traffic
802.1Q capable switch
eth0
eth0.100
Network managers comparison
Name
Possible use cases
FlatManager
Deprecated - should not be used for
any deployments.
Limitations
FlatDHCPManager
Internal, relatively small corporate
clouds which do not require tenant
isolation.
VlanManager
Public clouds which require L2 traffic
isolation between tenants and use of
dedicated subnets.
Only Debian derivatives
supported.
Single IP network suffers from
scalability limitations.
Instances share the same linux
bridge regardless which tenant
they belong to.
Limited scalability because of one
huge IP subnet.
Requires 802.1Q capable switch.
Scalable only to 4096 VLANs
Inter-tenant traffic
Compute node's routing table
consulted to route traffic
between tenants' networks
(based on IPs of the linux
bridges)
public ip
eth1
VM_net1
VM_net2
routing
10.100.0.0 via br100
10.200.0.0 via br200
br100
10.100.0.1
eth0.100
nova-compute
& nova-network
br200
10.200.0.1
eth0 eth0.200
Accessing internet
eth1 address is set as the
compute node's default gateway
Compute node's routing table
consulted to route traffic from
the instance to the internet over
the public interface (eth1)
source NAT is performed to the
compute node's public address
public ip
eth1
VM_net1
VM_net2
routing/NAT
0.0.0.0 via eth1
src 10.100.0.0 -j SNAT to public_ip
br100
10.100.0.1
eth0.100
nova-compute
& nova-network
br200
10.200.0.1
eth0 eth0.200
Floating & fixed IPs
Fixed IPs:
given to each instance on boot (by dnsmasq)
private IP ranges (10.0.0.0, 192.168.0.0, etc.)
only for communication between instances and to
external networks
inaccessible from external networks
Floating IPs:
allocated & associated to instances by cloud users
bunches of publicly routable IPs registered in
Openstack by cloud dmin
accessible from external networks
multiple floating IP pools, leading to different ISP-s
Floating IPs
User associates a floating
IP with VM:
floating IP is added as a
secondary IP address on
compute node's eth1 (public
IF)
DNAT rule is set to redirect
floating IP -> fixed IP
(10.0.0.2)
floating IP
added as a
secondary IP
on eth1
vm_float_ ip: 92.93.94.95
public ip
eth1
floating IP DNAT:
-d 92.93.94.95/32 -j DNAT -to-destination 10.0.0.2
VM
10.0.0.2
VM
10.0.0.3
linux
bridge
eth0
nova-compute &
nova-network host
Limitations
Networking management is available only for
admin
Implementation is coupled with networking
abstractions
QUANTUM - a new networking platform
Provides a flexible API for service providers or their
tenants to manage OpenStack network topologies
Presents a logical API and a corresponding plug-in
architecture that separates the description of network
connectivity from its implementation
Offers an API that is extensible and evolves
independently of the compute API
Provides a platform for integrating advanced networking
solutions
QUANTUM - a new networking platform
Provides a flexible API for service providers or their
tenants to manage OpenStack network topologies
Presents a logical API and a corresponding plug-in
architecture that separates the description of network
connectivity from its implementation
Offers an API that is extensible and evolves
independently of the compute API
Provides a platform for integrating advanced networking
solutions
QUANTUM - a new networking platform
Provides a flexible API for service providers or their
tenants to manage OpenStack network topologies
Presents a logical API and a corresponding plug-in
architecture that separates the description of network
connectivity from its implementation
Offers an API that is extensible and evolves
independently of the compute API
Provides a platform for integrating advanced networking
solutions
QUANTUM - a new networking platform
Provides a flexible API for service providers or their
tenants to manage OpenStack network topologies
Presents a logical API and a corresponding plug-in
architecture that separates the description of network
connectivity from its implementation
Offers an API that is extensible and evolves
independently of the compute API
Provides a platform for integrating advanced networking
solutions
QUANTUM - a new networking platform
Provides a flexible API for service providers or their
tenants to manage OpenStack network topologies
E
C
I
Presents a logical API and a corresponding
plug-in
V
R
architecture that separates the description
of network
E
S
connectivity from its implementation.
N
O
I
T
Offers an API that isCextensible
and evolves
independently R
ofA
the compute API
T
S
B
Provides
A a platform for integrating advanced networking
solutions
N
A
Quantum Overview
quantum abstracts
quantum architecture
quantum Open vSwitch plugin
quantum L3 agents
QUANTUM - abstracts - tenant network layout
provider nets
external net
8.8.0.0/16
external net
172.24.0.0/16
NAT
NAT
router1
10.0.0.1
GW
router2
192.168.0.1
10.23.0.1
GW
vm
vm
vm
vm
10.0.0.2
192.168.0.2
10.23.0.2
10.23.0.3
local nets
QUANTUM - abstracts
virtual L2 networks (port & switches)
IP pools & DHCP
virtual routers & NAT
"local" & "external" networks
Quantum network abstracts vs hardware
compute node
vm
DC net
vm
compute node
vm
vm
vm
vm
remote
DC
tunnel
DC DMZ
compute node
(another DC)
internet
vm
vm
vm
QUANTUM - abstracts
virtual L2 networks
IP pools & DHCP
virtual ports & routers
"local" & "external" networks
virtual networks delivered on
top of datacenter hardware
Quantum - architecture
source: http://openvswitch.org
quantum uses plugins to deal
with hardware diversity and
different layers of the OSI model
Quantum plugin architecture
source: http://openvswitch.org
Quantum plugin architecture
source: http://openvswitch.org
Quantum plugin architecture
source: http://openvswitch.org
quantum plugin determines
network connectivity layout.
Folsom - available quantum plugins
Linux Bridge
OpenVSwitch
Nicira NVP
Cisco (UCS Blade + Nexus)
Ryu OpenFlow controller
NEC ProgrammableFlow Controller
Example plugin: OpenVswitch
Example - Open vSwitch plugin
leverages OpenVSwitch software switch
modes of operation:
FLAT:
networks share one L2 domain
VLAN:
networks are separated by 802.1Q VLANs
TUNNEL:
traffic is carried over GRE with different pernet tunnel IDs
Open vSwitch plugin - bridges
single integration
bridge "br-int"
compute node
vm
vm
LV_1
LV_2
br-int
a patch port leads to
a bridge which is
attached to a
physical interface
ovs
daemon
breth0
q-agt
eth0
Integration bridge & NIC bridge
Open vSwitch plugin - ovs daemon
compute node
openvswitch
daemon accepts
calls from Quantum
agent & reconfigures
network
Quantum agent
accepts calls from
the central quantum
server via plugin
vm
vm
LV_1
LV_2
br-int
ovs
daemon
breth0
quantum server
qplugi
n
q-agt
eth0
Open vSwitch plugin vs compute farm
quantum server
qplugi
n
Quantum server manages an OpenVswitch server farm
through Quantum agents on compute nodes
Open vSwitch plugin - local VLANs
traffic separated by
"local" VLANs:
LV_1, LV_2
compute node
vm
vm
LV_1
LV_2
br-int
ovs
daemon
breth0
q-agt
eth0
One bridge, many VLANs
OpenStack connectivity - Open vSwitch plugin
leverages OpenVSwitch software switch
modes of operation:
FLAT:
networks share one L2 domain
VLAN:
networks are separated by 802.1Q VLANs
TUNNEL:
traffic is carried over GRE with different pernet tunnel IDs
Open vSwitch plugin - FLAT mode
Single L2 bcast
domain
Local vs global traffic ID-s - FLAT mode
openvswitch
FLAT:
LV_1 >> UNTAGGED
LV_1
VM
br-int
br-eth0
eth0
Local VLAN tag stripped before sending down the wire
Open vSwitch plugin - VLAN mode
802.1Q VLANs
Local vs global traffic ID-s - VLAN mode
openvswitch
VLAN:
LV_1 >> NET1_GLOBAL_VID
LV_1
VM
br-int
br-eth0
eth0
Local VLAN tag changed to "global" VLAN tag.
Open vSwitch plugin - Tunnel mode
GRE tunnel IDs
Local vs global traffic ID-s - Tunnel mode
openvswitch
GRE:
LV_1 >> NET1_TUNNEL_ID
LV_1
VM
br-int
br-tun
Local VLAN tag changed to GRE tunnel ID
eth0
VLAN vs GRE scalability
VLAN ID: 12bit field:
2^12 = 4096
GRE tunnel ID: 32bit field: 2^32 = 4
294 967 296
Tenant connection needs - provider networks
compute node
vm
vm
compute node
vm
DC net
need for many physical
connections per
compute node
vm
vm
vm
remote
DC
tunnel
DC DMZ
compute node
(another DC)
internet
vm
vm
vm
Integration with cloud and datacenter networks
dedicated per-NIC
bridge
Integration with cloud and datacenter networks
vlan range:
100-400
vlan range:
401-800
tunnel ID
range:
50-600
vlan ranges are
mapped to per-NIC
bridges
Agents: routing/NAT & IPAM
Tenant connection needs - L3
vm
vm
vm
vm
vm
vm
vm
Ensuring "wired" instance
connectivity is not enough
vm
vm
Tenant connection needs - L3
10.1.0.0/24
vm
vm
10.0.0.0/24
vm
vm
vm
vm
10.2.0.0/24
vm
We need IP addresses
vm
vm
Tenant connection needs - L3
10.1.0.0/24
vm
vm
10.0.0.0/24
vm
vm
vm
vm
10.2.0.0/24
vm
We need routers
vm
vm
Tenant connection needs - L3
10.1.0.0/24
vm
vm
10.0.0.0/24
vm
vm
vm
vm
10.2.0.0/24
vm
We need external
access/NAT
vm
vm
Quantum vs L3 services
dhcp-agent &
quantum db
for IP address
mgmt
10.1.0.0/24
vm
vm
10.0.0.0/24
vm
vm
vm
vm
10.2.0.0/24
vm
vm
l3-agent for
routing & NAT
vm
IPAM
create Quantum network
create Quantum subnet
pair subnet with network
boot instances and throw them into the network
DHCP
dhcp-agent: aims to manage different dhcp backends to
provide dhcp services to openstack instances.
Routing
l3-agent:
creates virtual routers and plugs them into different
subnets
provides connectivity between Quantum networks
creates default gateways for instances
NAT
l3-agent: creates NAT-ed connections to "external" networks
Compute cluster /w plugins & agents
quantum server
dhcp host
gateway host
dnsmasq
routing/NAT
dhcp-agent
l3-agent
Quantum - plugin & agent summary
OVS
flat
vlan
CISCO
gre
nexus
UCS
NICIRA
RYU
NEC
OTHER?
NVP
Open
Flow/O
VS
Progra
mmabl
eFlow
???
QUANTUM
dnsma
sq
DHCP
AGENT
NAT
router
L3
AGENT
iptable
s
???
FIREWALL
AGENT
HApro
xy
F5
L-B
AGENT
???
Quantum /w OVS - model summary
each tenant manages his IP addresses independently
networks separated on L2 with VLANs or GRE
tunnel IDs
disjoint concepts of "network" and "IP pool"
tenant networks connected with one another by
"virtual routers"
internal vs external networks
Quantum vs nova-network
NOVA-NETWORK
QUANTUM
multi-host
Yes
No
VLAN networking
Yes
Yes
Flat(DHCP)
networking
Yes
Yes
Tunneling (GRE)
No
Yes
many bridges
No
Yes
SDN
No
Yes
IPAM
Yes
Yes
dashboard support
No
Limited - no floating
IPs
Yes
Limited - only with
non-overlapping IP
pools
security groups
Questions?
[email protected]
