Embed Size (px)
DESCRIPTION
Overview and of OpenStack Quantum with the OpenVSwitch plugin.
Citation preview
Network Virtualization with OpenStack Quantum
Miguel Lavalle
Openstack Quantum Hacker
Outline
• Quantum in the OpenStack landscape
• Why Quantum?
• API Overview and the Main Abstraction
• Plugin Architecture
• Demo
• Physical realization: the provider API extension
• Openvswitch plug-in internals
• Setting up a development environment (DevStack) for Quantum
OpenStack overview
Queue
Queue
Quantum database
l3-agent
plugin-agent
dhcp-agent
REST
quantum-server
OpenStackIdentity API
OpenStackNetwork API
OpenStackNetwork API
Why Quantum?
Problem #1: No Tenant Control
“You can have any color as long as its black.“- Henry Ford about the Model-T
To move enterprise apps to the cloud, tenants want to “copy and paste” their existing data center 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 (“cloudbursting”).
Why Quantum? Reason #1On-demand Enterprise-Class Networking
• Tenants can:
– Create multiple private L2 networks
– Control IP addressing (bring your own!).
– Monitor basic network status.
– Connect to an upstream router for external access
• Quantum API extensions provide:
– Advanced control + visibility: Security policies, Quality-of-Service, Monitoring + Troubleshooting.
– Advanced Network Services: routers, Firewalls, VPN, IDS, etc.
Build rich networks,
customized to tenant needs.
Problem #2: Technology Limitations
• Cloud puts new stresses on networks:
– High-density multi-tenancy, massive scale● But VLAN's limit scale
– On demand provisioning● But traditional network solutions have interfaces
designed for manual configuration– Need to place / move workloads where capacity is
● But network state is tied to a particular location– Integrate with legacy hosting environments / remote
data centers.
– VM mobility
– On-demand service insertion
• Nova was limited to basic VLAN model + Linux IPtables.
Who needs private networks?
Trunking all VLANs is a great idea!
- Stone Age Man
Problem #2: Technology Limitations
• Cloud puts new stresses on networks:
– High-density multi-tenancy, massive scale● But VLAN's limit scale
– On demand provisioning● But traditional network solutions have interfaces
designed for manual configuration– Need to place / move workloads where capacity is
● But network state is tied to a particular location– Integrate with legacy hosting environments / remote
data centers.
– VM mobility
– On-demand service insertion
• Nova was limited to basic VLAN model + Linux IPtables.
Who needs private networks?
Trunking all VLANs is a great idea!
- Stone Age Man
Why Quantum? #2: Leveraging Advanced Technologies
• New networking technologies are emerging to try and tackle these challenges.
– Overlay tunneling: VXLAN, NVGRE, STT
– Software-defined Networking (SDN) / OpenFlow
– VPN-based solutions (e.g., E-VPN).
– L2 Fabric solutions: FabricPath, Qfabric, etc.
– [ insert other solution here ]
• Quantum provides a “plugin” mechanism to enable different technologies (more later).
• Choice is a good thing!
Use advanced technologies to reach new
heights.
Quantum Architecture
A generic tenant API to create and configure “virtual
networks”
A “plugin” architecture with
different back-end “engines”
An eco-system of tools that leverage the Quantum API.
Tenant Tools
(GUI, CLI, API code)
Compute API
Network API
Storage API
Generic OpenStack APIs
Operator Selected Backends
XenServer
Nicira NVP
EMC
Net1L2 virtual network
Basic API Abstractions
VM110.0.0.2Nova
Quantum
VM210.0.0.3
virtual server
virtual interface (VIF)
“virtual networks” and virtual subnets are fundamentally multi-tenant, just like virtual servers (e.g., overlapping IP's can be used on different networks)
virtual port
Virtual subnet10.0.0.0/24
TenantA-VM210.0.0.4 9.0.0.3
Quantum Model: Dynamic Network Creation + Association
TenantA-VM110.0.0.3
• 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 that provide
more advanced network functionality (e.g., routing + NAT).
Tenant-A Net110.0.0.0/24
Tenant-A Net29.0.0.0/24
TenantA-VM39.0.0.4
External Net172.31.0.0/24
Router
VMA2 B1
Tenant view vs. physical viewVMA1
Net A10.0.0.0/24 Net B
9.0.0.0/24
VMB2
Physical server 1
Hypervisor
VMA1
VMA1
VMB2
Physical server 2
Hypervisor
VMA2 B1
Tenant view
Physical view
Quantum API Extensions● Enables innovation in virtual networking
– Tenants can query API to programatically discover supported extensions
– Over time, extensions implemented by many plug-ins can become “core”
● Add properties on top of existing network/port abstractions:– QoS/SLA guarantees / limits
– Security filter policies
– Port statistics / netflow
● New services– L3 forwarding, ACL's + NAT (“elastic” or “floating” IP's)
– LBaaS
Quantum abstraction summary
Network classification
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.
Quantum Architecture
A generic tenant API to create and configure “virtual
networks”
A “plugin” architecture with
different back-end “engines”
An eco-system of tools that leverage the Quantum API.
Tenant Tools
(GUI, CLI, API code)
Compute API
Network API
Storage API
Generic OpenStack APIs
Operator Selected Backends
XenServer
Nicira NVP
EMC
Nova Compute
Virtual switch
API Clients Quantum Service
Uniform API for all clients
Interfaces from Nova plug into a switch managed by the
Quantum plug-in.
Backend X
Quantum Architecture (generic)
Tenant Scripts
HorizonGUI
OrchestrationCode
QuantumAPI
Create-net...
Create-port
APIExtensions
Plug-inX
Physical Network
Quantum status Folsom
● First “core” release (October 2012)– V2 API, with L2 + IP address management
(IPAM)
– Tenant API with Keystone and Horizon integration
– Updated CLI
– Extensions:● L3 “routers” with floating IP's● Provider networks● Bindings API
Demo “physical” set-up
● kvm vm running DevStack● 2 CPU's● 6GB of memory● Network interfaces
– eth0 NAT for DevStack
– eth1 management network 172.16.0.0/16
– eth3 external network 172.31.0.0/24
Demo: already set-up
Tenant demo net private10.0.0.0/24
Router
Demo logical set-up
● quantum net-create --tenant_id <tenant-id> private
● quantum subnet-create --tenant_id <tenant-id> --ip_version 4 --gateway 10.0.0.1 <net-id> 10.0.0.0/24
● quantum router-create --tenant_id <tenant-id> router1
● quantum router-interface-add <router-id> <subnet-id>
Demo: already set-up
Tenant demo net private10.0.0.0/24
External net172.31.0.0/24
Router
Demo logical set-up (cont.)
● quantum net-create nova -- --router:external=True
● quantum subnet-create --ip_version 4 <net-id> 172.31.0.0/24 -- --enable_dhcp=False
● quantum router-gateway-set <router-id> <ext-net-id>
Demo: the end result
Tenant demonet private10.0.0.0/24
Tenant demo net private2
TenantA-VM210.0.0.4 9.0.0.3
TenantA-VM110.0.0.3
TenantA-VM39.0.0.4
External net172.31.0.0/24
Router
172.31.0.3
9.0.0.0/24
Demo commands
● source devstack/openrc● quantum net-create private2● quantum subnet-create --ip_version 4
--gateway 9.0.0.1 <net-id> 9.0.0.0/24● nova boot --image <image-id>
--flavor 1 --nic net-id=<net-id-1> vm1
Demo commands (cont.)● nova boot --image <image-id> --flavor 1 --nic
net-id=<net-id-1> --nic net-id=<net-id-2> vm2● nova boot --image <image-id> --flavor 1 --nic
net-id=<net-id-2> vm3● nova list● nova get-vnc-console <vm2> novnc● (In VM2) sudo ifconfig eth1 9.0.0.3 netmask
255.255.255.0 up● quantum port-list -- --device_id <vm2>
Demo commands (cont.)
● quantum floatingip-create nova● quantum floatingip-associate <fip-id>
<port-id>● quantum floatingip-show <fip-id>
Quantum components
Quantumserver & plugin
Pluginagent
DHCP agent
DB Queue
■Quantum serverImplement Quantum API and its
extensionsEnforce network model
• Network, subnet, and portIP addressing to each port
■Plugin agentRun on each compute nodeConnect instances to network port
■DHCP agentIn multi-host mode, run on each
compute node (deferred)Start/stop dhcp serverMaintain dhcp configuration
L3-agentTo implement floating IPs and other L3
features, such as NATOne per external network
■QueueEnhance communication between each
components of quantum
■DB – persistent network model
Quantum can share DB service and Queue with other OpenStack stack services
l3-agent
Physical realization
local
Flat
VLAN
GRE
Network binding
network
Physical networkIdentified by name
Virtual networkModel in quantum
Tenant network provider network
● GRE and local bindings have no physical network
● Local bindings are for DevStack single box
● Linux bridge plug-in has no GRE support
Provider API Extension
● The provider networking extension allows administrators to explicitly manage the relationship between virtual networks and underlying physical mechanisms
● With this extension, users with admin privileges see additional provider attributes on all virtual networks and are able to specify these attributes
● As of Folsom, supported by the openvswitch and linuxbridge plugins
Provider API Extension: key terms● Virtual network: a Quantum L2 segment● Physical network: a network connecting virtualization hosts and other
network resources● Tenant network: a virtual network created by/for a tenant. The Tenant is
not aware of how that network is physically realized● Provider network: a virtual network administratively created to map to a
specific physical network● VLAN network: a virtual network realized as packets on a physical network
containing 802.1Q headers with a specific VID field value● Flat network: a virtual network realized as packets on a specific physical
network with no 802.1Q headers● GRE tunnel: a virtual network realized as packets encapsulated in a GRE
tunnel. The GRE tunnel packets are routed by the compute node hosts, so GRE tunnels are not associated with a specific physical network
Tenant networks realized with VLAN's (openvswitch)● Quantum server in controller
(/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini)– tenant_network_type = vlan
– network_vlan_ranges = physnet1:1000:2999,physnet2:3000:3999
● Bridge configuration in compute nodes: each physical network will require a bridge– sudo ovs-vsctl add-br br-eth1
– sudo ovs-vsctl add-port br-eth1 eth1
● Quantum agents in compute nodes (/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini)– network_vlan_ranges = physnet1:1000:2999,physnet2: 3000:3999
– bridge_mappings = physnet1:br-eth1,physnet2:br-eth2
● Example of creating a virtual network:– quantum net-create $tenant_network_name --provider:network_type vlan
--provider:physical_network physnet1 --provider:segmentation_id 1
Tenant networks realized with tunnels (openvswitch)● Quantum server in controller
(/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini)– tenant_network_type = gre
– tunnel_id_ranges = 1:1000
● Quantum agents in compute nodes (/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini)– enable_tunneling = True
– tunnel_id_ranges = 1:1000
– tunnel_bridge = br-tun
– local_ip = 10.0.0.3
● Example of creating a virtual network:– quantum net-create $tenant_network_name --provider:network_type gre
--provider:segmentation_id 1
Physnet1 vSwitchbr-eth1-1
Physical net1vlan ID 1000
Physnet2 vSwithbr-eth1-2
physical net2Flat
br-int
br-tunGRE
host B
int-br-eth1-1
phy-br-eth1-1
int-br-eth1-2
phy-br-eth1-2
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
External networks and floating ip's implementation
internal networkExternal networkrouter
gw_port7.0.1.2/24Floating ip:7.0.1.4/24
Router interface10.0.1.1/24
In general,The port acting as router interface should have gateway address of subnet
Floatingip port
Floating ip fixed port on fixed ip network
l3_agent
external networkvswitch br-ex
Vm10.0.1.5/24gw: 10.0.1.1/24
eth0
Router is used for VM to access outsideFloating IP is used for outside to access VM
AMPQ communication
Quantumtopic
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 agentComsumer:
get_device_detailsupdate_device_downtunnel_sync
Quantum rest api (resource CRUD)
tunnel_updatenetwork_delete port_update
get_active_networksget_network_infoget_dhcp_portrelease_dhcp_portrelease_port_fixed_ipupdate_lease_expiration
Plugin agent
Dhcp agentquantum-server
Booting a VM
DevStack set-up: localrc● HOST_IP=172.16.0.2● PUBLIC_INTERFACE=eth1● FIXED_RANGE=10.0.0.0/24● FIXED_NETWORK_SIZE=256● FLOATING_RANGE=172.31.0.0/24● disable_service n-net● enable_service q-svc● enable_service q-agt● enable_service q-dhcp● enable_service q-l3● enable_service quantum● Q_PLUGIN="openvswitch"● ENABLE_TENANT_TUNNELS=True● TENANT_TUNNEL_RANGES=1:100● ENABLE_TENANT_VLANS=False
