name: title class: center, middle background-image: url(images/title_background.png) background-size: 908.21px 681px background-position: 50% 0 # SDN in the world of Openstack .presenter[ Sławek Kapłoński slawomir.kaplonski@ovh.net IRC: slaweq ] --- name: agenda # Agenda 1. What is SDN? 2. What is Openstack? * Openstack in general * Main components 3. How SDN is done in Openstack * Basic concept of Openstack Neutron * Neutron's main components 4. Example of connections scenario made by Openstack Neutron * legacy scenario with Openvswitch and Network node --- name: sdn_definition # What is SDN? **Software-defined networking (SDN)** is an approach to computer networking that allows network administrators to programmatically initialize, control, change, and manage network behavior dynamically via open interfaces and abstraction of lower-level functionality. .source_txt[Source: [wikipedia](https://en.wikipedia.org/wiki/Software-defined_networking)] .left_side_img[ ![onf_logo](images/onf-logo.png) ] .right_side_img[ ![openflow_logo](images/OpenFlow-Logo-Small.jpg) ] ??? Definicja SDN wg wikipedia SDN zapewnia możliwość programowalnego: * zmieniania * kontroli * zarządzania sieciami Ma API, które przykrywa implementacje pod spodem --- name: sdn_definition_2 # What is SDN? .full_slide_img[ ![sdn_diagram](images/sdn-3layers.gif) ] .source_txt[source: https://www.opennetworking.org] ??? 3 warstwy w SDN: * warstwę aplikacji * warstwę kontrolną - udostępnia API i zarządza całym SDN'em; jest ona scentralizowana * warstwę infrastrukturalną z urządzeniami sieciowymi - najczęściej Openflow najczęściej do komunikacji --- name: openstack_general class: split-40 # What is Openstack? .column[ ![openstack_logo](images/OpenStack-Logo-Vertical.png) .source_txt[source: http://www.openstack.org] ] .column[ OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface. ] ??? Ogólna definicja ze strony Openstack Foundation: * kontroluje zasoby mocy obliczeniowej, storage i sieci w DC * Ma API i dashboard przez który można tym zarządzać i używać --- name: openstack_main_components class: center # Base Openstack components ![openstack_architecture](images/openstack-software-diagram.png) .source_txt[source: http://www.openstack.org/software] ??? Openstack'a można podzielić na 3 podstawowe części: * compute - Nova (VMs), Glance (Images) * storage - Swift (object storage), Cinder (block storage) * networking - Neutron oraz inne * Horizon (dashboard), * keystone (autentykacja), * ceilometer (telemetry) or kuryr (networking for containers) Wsystkie te projekty dostarczają REST API do zarządzania/obsługi Openstack'a -- name: openstack_main_components .left_side_list[ * compute - Nova (VMs), Glance (Images) ] -- name: openstack_main_components .left_side_list[ * storage - Swift (object storage), Cinder (block storage) ] -- name: openstack_main_components .left_side_list[ * networking - Neutron ] --- name: neutron_main_components class: center # Neutron main components ![architecture](images/neutron_components_architecture.png) ??? Komponenty neutrona: * neutron server - zapewnia obsługę API, ma dostęp do bazy, * L2 agenty - działają na wszystkich node'ach w klastrze - zapewniają podłączenie L2 "portów" do sieci * DHCP agent, L3 agent czy metadata agent Komunikacja przez RPC Jest tak w ML2 plugin. Inne core pluginy mogą to robić inaczej: * Midonet * Calico * PLUMgrid --- name: neutron_as_sdn class: center # Neutron as SDN ![neutron_sdn_diagram](images/neutron-sdn-3layers.png) ??? Openstack w modelu SDN: * warstwa aplikacji - np. nova-compute, korzysta z API neutron'a * warstwa zarządzająca - neutron server; ma API, dostępo do bazy, zna całą sieć, agenty, typy sieci itp. * warstwa infrastruktury - serwery w klastrze; mają L2 i L3 agenty Komunikacja przez RPC a nie przez Openflow jak w SDN'ie. Openflow wykorzystywany przez OVS agent'y --- name: example_scenario_1 class: center, scenario #Deployment example ![scenario overview](images/scenario-legacy-general.png) ??? Przykładowy klaster Openstacka (legacy z network node'em): * network node - usługi 3 warstwy (vrouter, floating ip), usługa DHCP * compute node'y - serwery w klastrze --- name: neutron_usage_example_create_network class: center # How to use Neutron .left_side_list[ create network ] ``` admin@devstack-2:~$ neutron net-create Local-Network Created a new network: +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | availability_zone_hints | | | availability_zones | | | created_at | 2016-08-01T12:38:36 | | description | | | id | 74149489-5cd6-473e-aeb7-d003652c8048 | | ipv4_address_scope | | | ipv6_address_scope | | | mtu | 0 | | name | Local-Network | | port_security_enabled | True | | provider:network_type | local | | provider:physical_network | | | provider:segmentation_id | | ``` ??? Sieć jest to jakiś izolowany segment. Można porównać to np. do VLANu w sieci fizycznej. Typy sieci: * tenant network - sieci prywatne, per tenant - domyślnie realizowane przez tunele vxlan lub gre * provider network - sieć mapowana bezpośrednio na fizyczną sieć w DC, np. vlan albo flat network * external network - taka jak provider network ale zapewniająca również dostęp do internetu --- name: neutron_usage_example_create_subnet class: center # How to use Neutron .left_side_list[ create subnet ] ``` admin@devstack-2:~$ neutron subnet-create Local-Network 10.0.0.0/24 Created a new subnet: +-------------------+--------------------------------------------+ | Field | Value | +-------------------+--------------------------------------------+ | allocation_pools | {"start": "10.0.0.2", "end": "10.0.0.254"} | | cidr | 10.0.0.0/24 | | created_at | 2016-08-01T12:47:28 | | description | | | dns_nameservers | | | enable_dhcp | True | | gateway_ip | 10.0.0.1 | | host_routes | | | id | 9f31692e-f2b8-4db0-9073-1c732373b9af | | ip_version | 4 | | ipv6_address_mode | | | ipv6_ra_mode | | | name | | | network_id | 74149489-5cd6-473e-aeb7-d003652c8048 | | subnetpool_id | | ``` ??? Subnet to: * block adresów IP * z konfiguracją (gw, dhcp server IP, IP range) --- name: neutron_usage_example_create_port class: center # How to use Neutron .left_side_list[ create port ] ``` admin@devstack-2:~$ neutron port-create Local-Network --binding:host_id devstack-2 +-----------------------+------------------------------------------------+ | Field | Value | +-----------------------+------------------------------------------------+ | admin_state_up | True | | binding:host_id | devstack-2 | | binding:vif_details | {"port_filter": true, "ovs_hybrid_plug": true} | | binding:vif_type | ovs | | binding:vnic_type | normal | | created_at | 2017-03-03T21:08:04Z | | fixed_ips | {"subnet_id": "...", "ip_address": "10.0.0.5"} | | id | 269cc404-5fb2-465a-94dc-76a17b3781dd | | mac_address | fa:16:3e:6e:f8:9f | | network_id | 45b19f14-e531-431b-b66a-755d8d64ba17 | | port_security_enabled | True | | project_id | 4ec2efced54b44719377a710aacbf3da | | revision_number | 6 | | status | DOWN | ``` ??? Port tworzy często Nova-compute. Trzeba go skonfigurować wstępnie na hoście (vif_type) Gdy port jest już dodany do bridge'a, resztę konfiguracji na hoście robi L2 agent (ovs w tym wypadku) --- name: example_scenario_2 class: center, scenario #Network scenario example .left_side_img[ ![scenario compute 1](images/scenario-legacy-ovs-compute1.png) ] .right_side_img[ ![scenario compute 2](images/scenario-legacy-ovs-compute2.png) ] ??? Compute node. Po lewej ogólnie: * instancja, * Linuxbridge, który realizuje tzw. security grupy * ovs z bridgami integracji, tunnelu i vlanowy Po prawej szczegółowo: * port tap w linuksowym bridge'u * drugi port w qbr to koniec veth'a * drugi koniec veth'a w br-int * br-int połączony przez patch port'y z br-tun i br-vlan --- name: example_scenario_3 class: center, scenario #Network scenario example .left_side_img[ ![scenario network 1](images/scenario-legacy-ovs-network1.png) ] .right_side_img[ ![scenario network 2](images/scenario-legacy-ovs-network2.png) ] ??? Network node. Po lewej ogólnie: * L3 agent i DHCP agent * dodatkowo w ovs’ie jest br-ex który służy do podłączenia sieci external Po prawej: * namespace dhcp (qdhcp) i interfej tap serwera dhcp wpięty do br-int. * namespace qrouter (porty w br-int) * routera do sieci prywatnej (qr) * do internetu (qg). Reguły openflow kierują później pakiety do odpowiednich bridge’y (br-tun, br-ex, vlan) --- name: example_scenario_4 class: center, scenario #Network scenario example .full_slide_img[ ![scenario flows](images/scenario-legacy-ovs-flowns1-compute.png) ] ??? Ruch north-south (do internetu) VM - qbr - br-int -- OF rules -- patch-port -- {br-tun, br-vlan} -- OF(np. zmień VLAN, nadaj VNI) -- out --- name: example_scenario_5 class: center, scenario #Network scenario example .image-w80pr[ ![scenario flows](images/scenario-legacy-ovs-flowns1-network.png) ] ??? W network node podobnie: {br-tun,br-vlan} -- OF(np. zmień/nadaj vlan id) -- patch-port -- br-int -- router (przez qr) -- NAT -- qg -- br-int -- br-ex -- internet --- class: last # Questions? .presenters[ Sławek Kapłoński slawomir.kaplonski@ovh.net IRC: slaweq ] ## Do You want to build Openstack clouds? .job_link[ ovh.pl/jobs - Openstack Cloud Engineer ] ## Reference * https://wiki.openstack.org/wiki/Neutron * https://www.opennetworking.org/ * http://slawqo.github.io/neutron_openstack_sdn/