Network virtualization with open stack quantum

13,916 views

Published on

Overview and of OpenStack Quantum with the OpenVSwitch plugin.

  • Be the first to comment

Network virtualization with open stack quantum

  1. 1. Network Virtualization with OpenStack Quantum Miguel Lavalle miguel@mlavalle.com Openstack Quantum Hacker
  2. 2. 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
  3. 3. OpenStack overview OpenStack Network API OpenStack Network API quantum- server REST QQ uu l3-agent ee uu ee plugin-agent Quantu m databa se dhcp-agent OpenStack Identity API
  4. 4. Why Quantum?
  5. 5. Problem #1: No Tenant ControlTo move enterprise apps to the cloud,tenants want to “copy and paste” theirexisting 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”). “You can have any color as long as its black.“ - Henry Ford about the Model-T
  6. 6. Why Quantum? Reason #1 On-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 Build rich policies, Quality-of-Service, Monitoring + networks, Troubleshooting. customized to tenant needs. – Advanced Network Services: routers, Firewalls, VPN, IDS, etc.
  7. 7. Problem #2: Technology Limitations• Cloud puts new stresses on networks: – High-density multi-tenancy, massive scale ● But VLANs 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 Who needs – On-demand service insertion private networks?• Nova was limited to basic VLAN model + Linux IPtables. Trunking all VLANs is a great idea! - Stone Age Man
  8. 8. Problem #2: Technology Limitations• Cloud puts new stresses on networks: – High-density multi-tenancy, massive scale ● But VLANs 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 Who needs – On-demand service insertion private networks?• Nova was limited to basic VLAN model + Linux IPtables. Trunking all VLANs is a great idea! - Stone Age Man
  9. 9. 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). Use advanced technologies to reach new• Choice is a good thing! heights.
  10. 10. Quantum Architecture Generic OpenStack Operator Selected APIs Backends Compute API XenServer Network API Nicira NVP Tenant Tools Storage API EMC (GUI, CLI, API code)An eco-system of A generic tenant A “plugin”tools that API to create and architecture withleverage the configure “virtual different back-endQuantum API. networks” “engines”
  11. 11. Basic API Abstractions VM1 VM2 virtual serverNova 10.0.0.2 10.0.0.3 virtual interface (VIF) virtual port L2 virtual network Net1Quantum 10.0.0.0/24 Virtual subnet“virtual networks” and virtual subnets are fundamentally multi-tenant, just like virtual servers (e.g., overlapping IPs can be used ondifferent networks)
  12. 12. Quantum Model: Dynamic Network Creation + Association TenantA-VM1 TenantA-VM2 TenantA-VM3 10.0.0.3 10.0.0.4 9.0.0.3 9.0.0.4 Router Tenant-A Net1 Tenant-A Net2 10.0.0.0/24 9.0.0.0/24 External Net • Tenant can use API to create many networks.172.31.0.0/24 • 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).
  13. 13. Tenant view vs. physical view VM VM VM A1 A2 B1 B2 Net A Net B 10.0.0.0/24 9.0.0.0/24Tenant viewPhysical view Physical server 1 Physical server 2 VM VM VM A1 B2 A2 B1 Hypervisor Hypervisor
  14. 14. 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, ACLs + NAT (“elastic” or “floating” IPs) – LBaaS
  15. 15. Quantum abstractionsummary
  16. 16. Network classificationinternal Only fixed Private internal networks Shared internal networks Ips are allocated from there.external we can create floating ips and Private external networks shared external networks router gateway on it, They should be able to access public network Other tenants Only owner private tenant can shared besides the owner tenant create ports on can create it. ports on it.
  17. 17. Quantum Architecture Generic OpenStack Operator Selected APIs Backends Compute API XenServer Network API Nicira NVP Tenant Tools Storage API EMC (GUI, CLI, API code)An eco-system of A generic tenant A “plugin”tools that API to create and architecture withleverage the configure “virtual different back-endQuantum API. networks” “engines”
  18. 18. Quantum Architecture (generic)API Clients Quantum Backend X Service Quantum Physical API Network Tenant Scripts Create-net . Horizon GUI . Plug-in . XOrchestration Create-port Virtual switch Code Nova Compute API Extensions Interfaces from Nova plug into a switch Uniform API managed by the for all Quantum plug-in. clients
  19. 19. 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 IPs ● Provider networks ● Bindings API
  20. 20. Demo “physical” set-up● kvm vm running DevStack● 2 CPUs● 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
  21. 21. Demo: already set-upRouter Tenant demo net private 10.0.0.0/24
  22. 22. 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>
  23. 23. Demo: already set-up Router Tenant demo net private 10.0.0.0/24 External net172.31.0.0/24
  24. 24. 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>
  25. 25. Demo: the end result TenantA-VM1 TenantA-VM2 TenantA-VM3 10.0.0.3 10.0.0.4 9.0.0.3 9.0.0.4 172.31.0.3 Router Tenant demo Tenant demo net private net private2 10.0.0.0/24 9.0.0.0/24 External net172.31.0.0/24
  26. 26. 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
  27. 27. 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>
  28. 28. Demo commands (cont.)● quantum floatingip-create nova● quantum floatingip-associate <fip-id> <port-id>● quantum floatingip-show <fip-id>
  29. 29. Quantum components ■Quantum server Implement Quantum API and its l3-agent extensions Enforce network model Quantum • Network, subnet, and port IP addressing to each port server & plugin Plugin ■Plugin agent agent Run on each compute node Connect instances to network port ■DHCP agent In multi-host mode, run on each DHCP compute node (deferred) agent Start/stop dhcp server DB Maintain dhcp configuration Queue L3-agent To implement floating IPs and other L3 features, such as NAT One per external networkQuantum can share DB service ■Queue and Queue with other Enhance communication between each OpenStack stack services components of quantum ■DB – persistent network model
  30. 30. Physical realization network Physical network Virtual network Identified by name Model in quantum Network binding Tenant network provider network VLAN Flat● GRE and local bindings have no physical network GRE● Local bindings are for DevStack single box local● Linux bridge plug-in has no GRE support
  31. 31. 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
  32. 32. Provider API Extension: keyterms● 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
  33. 33. Tenant networks realizedwith VLANs (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
  34. 34. Tenant networks realizedwith 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
  35. 35. Host A network A local Vlan ID 1 network C local Vlan ID 3 int-br- eth1-1 patch-tun br-int patch-port ve th int-br-eth1-2 network B local Vlan ID 2 phy-br- patch-int eth1-1 phy-br-eth1-2 Physnet1 vSwitch Physnet2 vSwith br-eth1-1 br-eth1-2 br-tun GRE Physical net1 physical net2 vlan ID 1000 host B Flat host C host C
  36. 36. External networks andfloating ips implementation Vm 10.0.1.5/24 Floating ip gw: 10.0.1.1/24 fixed port on fixed ip Floatingip network Router interface In general, port The port acting 10.0.1.1/24 as router gw_port 7.0.1.2/24 interface should Floating ip: have gateway 7.0.1.4/24 address of subnetExternal network internal network router external network vswitch br-ex eth0 l3_agent Router is used for VM to access outside Floating IP is used for outside to access VM
  37. 37. Dhcp agent AMPQ communication quantum-server get_active_networks get_network_info get_dhcp_port release_dhcp_port release_port_fixed_ip update_lease_expirationPlugin agent Quantum rest api (resource CRUD) get_device_details update_device_down network_delete tunnel_update port_update tunnel_sync q-agent-notifier- q-agent-notifier- q-agent-notifier- Quantum network-delete_fanout tunnel-update_fanout port-update_fanoutExchange: topic fanout fanout fanout q-agent-notifier- q-agent-notifier- q-agent-notifier- Queue: q-plugin notifications.info network-delete_fanout tunnel-update_fanout port-update_fanout _{uuid4} _{uuid4} _{uuid4}Comsumer: quantum-server Dhcp agent Plugin agent
  38. 38. Booting a VM
  39. 39. 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
  40. 40. Thanks!Questions?I am looking for a job Miguel Lavalle miguel@mlavalle.com OpenStack Quantum Hacker

×