openstack super bootcamp.pdf
DESCRIPTION
trueTRANSCRIPT
![Page 1: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/1.jpg)
OpenStack SuperBootcamp
Mirantis, 2012
![Page 2: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/2.jpg)
Agenda
● OpenStack Essex architecture recap● Folsom architecture overview● Quantum vs Essex's networking model
![Page 3: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/3.jpg)
nova: Compute
Swift
nova: Cloud Controller
Initial State
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
Tenant is created, provisioning quota is available, user has an access to Horizon/CLI
![Page 4: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/4.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 1: Request VM Provisioning via UI/CLI
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
User specifies VM params: name, flavor, keys, etc. and hits "Create" button
![Page 5: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/5.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 2: Validate Auth Data
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
Horizon sends HTTP request to Keystone. Auth info is specified in HTTP headers.
![Page 6: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/6.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 2: Validate Auth Data
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
Keystone sends temporary token back to Horizon via HTTP.
![Page 7: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/7.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 3: Send API request to nova-api
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
Horizon sends POST request to nova-api (signed with given token).
![Page 8: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/8.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 4: Validate API Token
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
nova-api sends HTTP request to validate API token to Keystone.
![Page 9: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/9.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 4: Validate API Token
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
Keystone validates API token and sends HTTP response with token acceptance/rejection info.
![Page 10: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/10.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 5: Process API request
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
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.
![Page 11: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/11.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 6: Publish provisioning request to queue
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
nova-api makes rpc.call to scheduler. It publishes a short message to scheduler queue with VM info.
![Page 12: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/12.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 6: Pick up provisioning request
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
scheduler picks up the message from MQ.
![Page 13: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/13.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 7: Schedule provisioning
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
Scheduler fetches information about the whole cluster from database and based on this info selects the most applicable compute host.
![Page 14: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/14.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 8: Start VM provisioning on compute node
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
Scheduler publishes message to the compute queue (based on host ID) and triggers VM provisioning
![Page 15: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/15.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 9: Start VM rendering via hypervisor
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
nova-compute fetches information about VM from DB, creates a command to hypervisor and delegates VM rendering to hypervisor.
![Page 16: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/16.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 10: Request VM Image from Glance
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
hypervisor request VM image from Glance via Image ID
![Page 17: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/17.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 11: Get Image URI from Glance
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
If image with given image ID can be found - return
![Page 18: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/18.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 12: Download image from Swift
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
hypervisor downloads image using URI, given by Glance, from Glance's back-end. After downloading - it renders it.
![Page 19: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/19.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 13: Configure network
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
nova-compute makes rpc.call to nova-network requesting networking info.
![Page 20: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/20.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 14: allocate and associate network
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
nova-network updates tables with networking info and VM entry in database
![Page 21: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/21.jpg)
nova: Compute
Swift
nova: Cloud Controller
Step 15: Request volume attachment
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
Tenant is created, provisioning quota is available, user has an access to Horizon/CLI
![Page 22: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/22.jpg)
nova: Compute
Swift
nova: Cloud Controller
Initial State
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
Tenant is created, provisioning quota is available, user has an access to Horizon/CLI
![Page 23: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/23.jpg)
nova: Compute
Swift
nova: Cloud Controller
Still part of nova
nova-api
scheduler
nova-network
nova-volume
nova-db
queue
nova-compute
hypervisor
Glance
glance-api
object store
glance-registry
Keystone
Shared Storage
endpoint
proxy-server
Horizon CLI
![Page 24: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/24.jpg)
Limitations?
● Nova is "overloaded" to do 3 things○ Compute○ Networking○ Block Storage
● API for networking and block storage are still parts of nova
![Page 25: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/25.jpg)
nova
nova-db
queue
Swift
object store
proxy-server
UI: horizon or CLI
Quantum
quantum-db
quantumplugin
quantumserver
Cinder
endpoint
cinder-db
scheduler
queue
cinder-vol
controller
nova-api
scheduler
Keystone
keystoneserver
keystone-db
Glance
glance-api
glance-registry
glancedb
block storage
node
storage
compute node
Hypervisor
Network
VM
nova: Computenova-
compute
![Page 26: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/26.jpg)
nova
nova-db
queue
Swift
object store
proxy-server
UI: horizon or CLI
Quantum
quantum-db
quantumplugin
quantumserver
Cinder
endpoint
cinder-db
scheduler
queue
cinder-vol
controller
nova-api
scheduler
Keystone
keystoneserver
keystone-db
Glance
glance-api
glance-registry
glancedb
block storage
node
storage
compute node
Hypervisor
Network
VM
nova: Computenova-
compute
![Page 27: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/27.jpg)
Essex' networking model overview
● single-host vs multi-host networking● the role of network manager● different network manager types● floating IPs
![Page 28: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/28.jpg)
Revisit of KVM networking with linux bridge
switch
VM10.0.0.2
VM10.0.0.3
linuxbridge
nova-compute host
eth0
VM10.0.0.4
VM10.0.0.5
linuxbridge
nova-compute host
eth0
router
router: 10.0.0.1(def. gateway for VMs)
![Page 29: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/29.jpg)
● KVM host == nova-compute● router == nova-network
routing/NAT
eth0
eth1
nova-network hosteth0 IP:10.0.0.1
(def. gateway for VMs)
public ip
Single-host networking
switch
VM10.0.0.2
VM10.0.0.3
linuxbridge
nova-compute host
eth0
VM10.0.0.4
VM10.0.0.5
linuxbridge
nova-compute host
eth0
![Page 30: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/30.jpg)
VM:~root$ ping google.com
No route to host
routing/NAT
eth0
eth1
switch
VM10.0.0.2
VM10.0.0.3
linuxbridge
nova-compute host
eth0
VM10.0.0.4
VM10.0.0.5
linuxbridge
nova-compute host
eth0
What happens if nova-network host dies
![Page 31: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/31.jpg)
Multi-host networkingMove routing from the central server to each compute node independently to prevent SPOF. routing/NAT
eth0
eth1
switch
VM10.0.0.2
VM10.0.0.3
linuxbridge
nova-compute &nova-network host
eth0
VM10.0.0.4
VM10.0.0.5
linuxbridge
nova-compute &nova-network host
eth0
routing/NAT
eth1
routing/NAT
eth1public ippublic ip
![Page 32: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/32.jpg)
Multi-host networking
switch
VM10.0.0.2
VM10.0.0.3
linuxbridge
nova-compute &nova-network host
eth0
VM10.0.0.4
VM10.0.0.5
linuxbridge
nova-compute &nova-network host
eth0
routing/NAT
eth1
routing/NAT
eth1public ippublic ip
10.0.0.1(gw) 10.0.0.6(gw)
Compute servers maintain Internet access independent from each other. Each of them runs nova-network & nova-compute components.
![Page 33: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/33.jpg)
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
![Page 34: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/34.jpg)
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
![Page 35: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/35.jpg)
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
![Page 36: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/36.jpg)
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
![Page 37: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/37.jpg)
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
VM
linuxbridge
nova-compute &nova-network
eth0
VM/etc/network/interfaces:
"address 10.0.0.2gateway 10.0.0.1"
linuxbridge
nova-compute &nova-network
eth0
10.0.0.1(gw)
eth1 eth1
![Page 38: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/38.jpg)
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
VM
nova-compute &nova-network
eth0
VMobtain dhcp static lease:
ip: 10.0.0.2gw: 10.0.0.1
linuxbridge
nova-compute& nova-network
eth0
10.0.0.1(gw)
dnsmasq
eth1 eth1
![Page 39: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/39.jpg)
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)
nova-compute &nova-network
eth0
VMip: 10.0.0.2gw: 10.0.0.1
linuxbridge
nova-compute& nova-network
eth0
10.0.0.1(gw)dnsmasq: static leases for 10.0.0.2 & 10.0.0.5
eth1 eth1
switch
VMip: 10.0.0.5gw: 10.0.0.1
linuxbridge 10.0.0.3(gw)
dnsmasq: static leases for 10.0.0.4 & 10.0.0.6
VMip: 10.0.0.4gw: 10.0.0.3
VMip: 10.0.0.6gw: 10.0.0.3
![Page 40: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/40.jpg)
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
VM_net1
nova-compute &nova-network
eth0
VM_net1
br100
nova-compute& nova-network
eth0
dnsmasq_net1
eth0.100
VM_net2 VM_net2
eth0.200
br200
dnsmasq_net2
eth1 eth1
![Page 41: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/41.jpg)
VlanManager - switch requirementsThe switch requires support for 802.1Q tagged VLANs to connect instances on different compute nodes
VM_net1
br100
nova-compute& nova-network
eth0eth0.100
VM_net2
eth0.200
br200
VM_net2
br100
nova-compute& nova-network
eth0eth0.200
VM_net1
eth0.100
br200
802.1Q capable switch
tagged traffic
eth1 eth1
![Page 42: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/42.jpg)
Network managers comparisonName Possible use cases Limitations
FlatManager Deprecated - should not be used for any deployments.
● Only Debian derivatives supported.
● Single IP network suffers from scalability limitations.
FlatDHCPManager Internal, relatively small corporate clouds which do not require tenant isolation.
● Instances share the same linux bridge regardless which tenant they belong to.
● Limited scalability because of one huge IP subnet.
VlanManager Public clouds which require L2 traffic isolation between tenants and use of dedicated subnets.
● Requires 802.1Q capable switch.● Scalable only to 4096 VLANs
![Page 43: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/43.jpg)
Inter-tenant trafficCompute node's routing table consulted to route traffic between tenants' networks (based on IPs of the linux bridges) VM_net1
br100
nova-compute& nova-network
eth0eth0.100
VM_net2
eth0.200
br200
routing10.100.0.0 via br10010.200.0.0 via br200
eth1public ip
10.100.0.1 10.200.0.1
![Page 44: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/44.jpg)
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
VM_net1
br100
nova-compute& nova-network
eth0eth0.100
VM_net2
eth0.200
br200
eth1
routing/NAT0.0.0.0 via eth1
src 10.100.0.0 -j SNAT to public_ip
public ip
10.100.0.1 10.200.0.1
![Page 45: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/45.jpg)
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
![Page 46: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/46.jpg)
Floating IPs
VM10.0.0.2
VM10.0.0.3
linuxbridge
nova-compute &nova-network host
eth0
floating IP DNAT:-d 92.93.94.95/32 -j DNAT --
to-destination 10.0.0.2
eth1public ip
● 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
![Page 47: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/47.jpg)
Limitations
● Networking management is available only for admin
● Implementation is coupled with networking abstractions
![Page 48: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/48.jpg)
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
![Page 49: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/49.jpg)
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
![Page 50: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/50.jpg)
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
![Page 51: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/51.jpg)
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
![Page 52: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/52.jpg)
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 AN ABSTRACTION SERVICE
![Page 53: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/53.jpg)
Quantum Overview
● quantum abstracts● quantum architecture● quantum Open vSwitch plugin● quantum L3 agents
![Page 54: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/54.jpg)
provider nets
NAT
local nets
QUANTUM - abstracts - tenant network layout
vm
10.0.0.2
router1
vm
192.168.0.2
10.0.0.1 192.168.0.1GW
external net8.8.0.0/16
NAT
vm
10.23.0.2
router2
10.23.0.1
external net172.24.0.0/16
GW
vm
10.23.0.3
![Page 55: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/55.jpg)
QUANTUM - abstracts● virtual L2 networks (port & switches)● IP pools & DHCP● virtual routers & NAT● "local" & "external" networks
![Page 56: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/56.jpg)
Quantum network abstracts vs hardwarecompute node
vm vm vm
DC net DC DMZremote
DC tunnel
compute node
vm vm vm
compute node (another DC)
vm vm vm
internet
![Page 57: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/57.jpg)
QUANTUM - abstracts● virtual L2 networks● IP pools & DHCP● virtual ports & routers● "local" & "external" networks
virtual networks delivered on top of datacenter hardware
![Page 58: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/58.jpg)
Quantum - architecture
source: http://openvswitch.org
![Page 59: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/59.jpg)
quantum uses plugins to deal with hardware diversity and different layers of the OSI model
![Page 60: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/60.jpg)
Quantum plugin architecture
source: http://openvswitch.org
![Page 61: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/61.jpg)
Quantum plugin architecture
source: http://openvswitch.org
![Page 62: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/62.jpg)
Quantum plugin architecture
source: http://openvswitch.org
![Page 63: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/63.jpg)
quantum plugin determines network connectivity layout.
![Page 64: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/64.jpg)
Folsom - available quantum plugins
● Linux Bridge● OpenVSwitch● Nicira NVP● Cisco (UCS Blade + Nexus)● Ryu OpenFlow controller● NEC ProgrammableFlow Controller
![Page 65: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/65.jpg)
Example plugin: OpenVswitch
![Page 66: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/66.jpg)
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 per-net tunnel IDs
![Page 67: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/67.jpg)
Open vSwitch plugin - bridges
vm vm
br-int
br-eth0
eth0
LV_1 LV_2
compute nodesingle integration bridge "br-int"
a patch port leads to a bridge which is attached to a physical interface
ovsdaemon
q-agt
Integration bridge & NIC bridge
![Page 68: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/68.jpg)
Open vSwitch plugin - ovs daemon
vm vm
br-int
br-eth0
eth0
LV_1 LV_2
compute node
ovsdaemon
Quantum agent accepts calls from
the central quantum server via plugin
openvswitchdaemon accepts
calls from Quantum agent & reconfigures
network
q-agtquantum serverq-plugin
![Page 69: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/69.jpg)
Open vSwitch plugin vs compute farm
quantum server
Quantum server manages an OpenVswitch server farm through Quantum agents on compute nodes
q-plugin
![Page 70: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/70.jpg)
Open vSwitch plugin - local VLANs
vm vm
br-int
br-eth0
eth0
LV_1 LV_2
compute nodetraffic separated by "local" VLANs:
LV_1, LV_2
ovsdaemon
q-agt
One bridge, many VLANs
![Page 71: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/71.jpg)
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 per-net tunnel IDs
![Page 72: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/72.jpg)
Open vSwitch plugin - FLAT mode
Single L2 bcast domain
![Page 73: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/73.jpg)
Local vs global traffic ID-s - FLAT mode
VM br-int br-eth0 eth0LV_1
LV_1 >> UNTAGGEDFLAT:
openvswitch
Local VLAN tag stripped before sending down the wire
![Page 74: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/74.jpg)
Open vSwitch plugin - VLAN mode
802.1Q VLANs
![Page 75: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/75.jpg)
Local vs global traffic ID-s - VLAN mode
VM br-int br-eth0 eth0LV_1
LV_1 >> NET1_GLOBAL_VIDVLAN:
openvswitch
Local VLAN tag changed to "global" VLAN tag.
![Page 76: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/76.jpg)
Open vSwitch plugin - Tunnel mode
GRE tunnel IDs
![Page 77: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/77.jpg)
Local vs global traffic ID-s - Tunnel mode
VM br-int br-tun eth0LV_1
LV_1 >> NET1_TUNNEL_IDGRE:
openvswitch
Local VLAN tag changed to GRE tunnel ID
![Page 78: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/78.jpg)
VLAN vs GRE scalability
VLAN ID: 12bit field: 2^12 = 4096
GRE tunnel ID: 32bit field: 2^32 = 4 294 967 296
![Page 79: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/79.jpg)
Tenant connection needs - provider networkscompute node
vm vm vm
DC net DC DMZremote
DC tunnel
compute node
vm vm vm
compute node (another DC)
vm vm vm
internet
need for many physicalconnections percompute node
![Page 80: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/80.jpg)
Integration with cloud and datacenter networks
dedicated per-NICbridge
![Page 81: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/81.jpg)
Integration with cloud and datacenter networks
vlan range:100-400
vlan range:401-800
tunnel ID range:50-600
vlan ranges aremapped to per-NICbridges
![Page 82: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/82.jpg)
Agents: routing/NAT & IPAM
![Page 83: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/83.jpg)
Tenant connection needs - L3
vm
vm
vm
vm
vm
vm
vm
vm
vm
Ensuring "wired" instance connectivity is not enough
![Page 84: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/84.jpg)
Tenant connection needs - L3
vm
vm
vm
vm
vm
vm
vm
vm
vm
We need IP addresses
10.0.0.0/24
10.1.0.0/24
10.2.0.0/24
![Page 85: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/85.jpg)
Tenant connection needs - L3
vm
vm
vm
vm
vm
vm
vm
vm
vm
We need routers
10.0.0.0/24
10.1.0.0/24
10.2.0.0/24
![Page 86: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/86.jpg)
Tenant connection needs - L3
vm
vm
vm
vm
vm
vm
vm
vm
vm
We need externalaccess/NAT
10.0.0.0/24
10.1.0.0/24
10.2.0.0/24
![Page 87: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/87.jpg)
Quantum vs L3 services
vm
vm
vm
vm
vm
vm
vm
vm
vm
10.0.0.0/24
10.1.0.0/24
10.2.0.0/24
dhcp-agent & quantum dbfor IP address mgmt
l3-agent for routing & NAT
![Page 88: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/88.jpg)
IPAM
● create Quantum network● create Quantum subnet● pair subnet with network● boot instances and throw them into the network
![Page 89: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/89.jpg)
DHCP
dhcp-agent: aims to manage different dhcp backends to provide dhcp services to openstack instances.
![Page 90: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/90.jpg)
Routing
l3-agent:
● creates virtual routers and plugs them into different subnets
● provides connectivity between Quantum networks
● creates default gateways for instances
![Page 91: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/91.jpg)
NAT
l3-agent: creates NAT-ed connections to "external" networks
![Page 92: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/92.jpg)
Compute cluster /w plugins & agents
quantum server
gateway host
l3-agent
routing/NAT
dhcp host
dhcp-agent
dnsmasq
![Page 93: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/93.jpg)
Quantum - plugin & agent summary
OVS
flat vlan gre
CISCO NICIRA
nexus UCS NVP
RYU
OpenFlow/O
VS
ProgrammableFlow
NEC OTHER?
???
DHCPAGENT
dnsmasq
L3AGENT
NAT router iptables
FIREWALL AGENT
L-BAGENT
HAproxy F5 ??????
QUANTUM
![Page 94: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/94.jpg)
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
![Page 95: OpenStack Super Bootcamp.pdf](https://reader031.vdocuments.us/reader031/viewer/2022020306/54b755c04a79596e388b48f0/html5/thumbnails/95.jpg)
Quantum vs nova-networkNOVA-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
security groups YesLimited - only with non-overlapping IP
pools