Univerzita Hradec Králové Fakulta informatiky a managementu. Networking v prostředí OpenStack. Bakalářská práce

Transkript

1 Univerzita Hradec Králové Fakulta informatiky a managementu katedra informačních technologií Networking v prostředí OpenStack Bakalářská práce Autor: Marek Čeloud Studijní obor: Informační management Vedoucí práce: Ing. Jakub Pavlík, MSc. Hradec Králové duben 2015

2 Prohlášení literatury. Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím uvedené V Hradci Králové dne 26. dubna 2015 Marek Čeloud

3 Poděkování Rád bych zde poděkoval Ing. Jakubu Pavlíkovi, MSc. za odborné vedení práce, podnětné rady a čas, který mi věnoval.

4 Anotace Tato práce pojednává o fenoménu cloudového řešení OpenStack, konkrétně o jeho problematice softwarově definovaných sítí (SDN). První část představuje základní komponenty cloudového operačního systému a následně způsoby, jakými je možné řešit úroveň síťové infrastruktury. Ve čtvrté a páté kapitole jsou teoreticky popsána dvě komerční řešení pro síťové API. Tato řešení jsou v poslední části implementována v laboratorním prostředí a porovnána z několika úrovní. Cílem této práce je přiblížit čtenářum teoretické základy nejrozšířenější Open Source cloudové platformy OpenStack a způsoby, jak zajistit dostatečný síťový výkon pro produkční prostředí. Annotation Title: Networking in OpenStack This thesis focuses on phenomenon of cloud platform OpenStack especially about the topic of software defined netorking (SDN). The first part deals with basic parts of cloud environment and how these parts can communicate due to software defined networks. In the fourth and fifth chapter are described two commercial implementation for network API from the theoretical point of view. At the end of this thesis these two implementation were tested in laboratory environment and compared from different levels of perspective. The goal of this thesis is to show readers the theoretical basics of the most spread Open Source cloud platform OpenStack and how to ensure good enough networking performance for the production environment.

5 Obsah 1 Úvod 1 2 Seznámení s prostředím OpenStack Kontext Vymezení OpenStacku Proč OpenStack? Moduly Řešení sítí v OpenStack Základní pojmy VLAN VXLAN NVGRE Co je OpenStack Networking? Pluginy Tenant and provider sítě Open vswitch Shrnutí sekce OpenContrail Základní pojmy IF-MAP XMPP BGP MPLS Sandesh Základní informace Architektura

6 Obsah 4.4 Role Compute role Control role Configuration role Analytics role OpenContrail forwarding plane MPLS over GRE VXLAN MPLS over UDP L3 a L2 unicast L3 multicast VMware NSX Základní informace Architektura Data plane Control plane Management plane a Consumption Role NSX Controller Service role Hypervizor role Gateway role Směrování a přepínání Přepínání Směrování Zapouzdření komunikace STT GRE Porovnání Juniper Contrail a VMware NSX Lab prostředí Hardware infrastruktura Logická Architektura Výsledky testování

7 6.2.1 Výkonostní metriky Globální porovnání Shrnutí výsledků 50 8 Závěry a doporučení 51 Literatura 55

8 1 Úvod Jedním z nejpalčivějších témat dnešního IT je oblast počítačových sítí. Jejich klasické řešení není vhodné pro všechny, převážně datacentrové implementace. Kvůli virtualizaci je nutné řešit základní úkony, jako jsou přepínání a směrování paketů už na serverech. K tomuto účelu slouží softwarově definované sítě (SDN). Existuje mnoho SDN řešení, ale ne všechna jsou vhodná pro produkční nasazení. Tato práce má za cíl zjistit, zdali toto kritérium splňují dvě komerční implementace, které jsou považovány za nejrozšířenější na světě. Práce je rozdělena na 5 hlavních kapitol, přičemž první čtyři patří do teoretické části. Pátá kapitola je praktická. V první kapitole bude popsán koncept cloudové platformy OpenStack. Jsou zde rozebrány základní principy a jednotlivé moduly. Poté přichází na řadu zaměření na networking a jeho vztah k OpenStacku. V dalších dvou kapitolách přijde na řadu teoretické popsání komponent a funkcionalit vybraných SDN controllerů - OpenContrail a VMware NSX. Po této teoretické sekci bude věnována pozornost jejich praktickému nasazení a porovnání. Bude také měřen výkon sítě a proběhne test nabízených služeb. Na konci praktické části dojde k hlavnímu porovnání globálních vlastností obou produktů. Téma práce bylo vybráno ve spolupráci s firmou tcp cloud a.s., která poskytuje implementace jednoho z nejvýkonnějších cloudových řešení na světě. Firma umožnila využít stávající infrastrukturu v nejmodernějším datovém centru v České republice, které je v budově Technologického centra Písek s.r.o. Jednou z motivací pro výběr tohoto tématu byla možnost porovnání dvou nejrozšířenějších SDN controllerů na světě a otestování OpenContrail verze 2.1 s Juno OpenStackam a zjištění, zdali je tato implementace připravena pro produkční nasazení. 1

9 2 Seznámení s prostředím OpenStack V této kapitole bude představena největší otevřená cloudová platforma na světě - OpenStack. Nejdříve bude uveden krátký popis zkoumané domény, aby čtenář získal základní povědomí o kontextu IT odvětví, kterému bude v této práci věnována pozornost. Poté přijde na řadu vymezení OpenStacku a základních idejí, kterými se řídí. Na konci kapitoly budou popsány moduly, ze kterých se OpenStack skládá. 2.1 Kontext Informační technolologie tak, jak je známe dnes, prošly dlouholetým vývojem a postupnou transformací. Například počítačové servery dříve představovaly vyhrazené fyzické zařízení. Pokud někdo potřeboval přidat další aplikaci do organizace, připojil další zařízení osazené vlastním procesorem, operační pamětí apod. Tyto aplikace měly vyhrazeny hardwarové prostředky pouze pro sebe. Tento přístup v sobě nese neefektivnost nejen z hlediska hardwarových, ale i lidských zdrojů. Každá nefungující aplikace musela být složitě přehrávána ze záloh a každý rozbitý operační systém musel být obnovován či přeinstalován. Z toho důvodu bylo revoluční, když na pole serverů přišla virtualizace, která umožnila virtualizovat hardwarové prostředky a rozdělit je efektivně mezi jednotlivé virtuální stroje. Pokud organizace potřebuje novou aplikaci, stačí spustit nový virtuální stroj na aktuální infrastruktuře. Díky existenci virtualizace je možné však jít ještě dál a pracovat s aplikacemi odkudkoli - přišel cloud. Narozdíl od oblasti serverů by se dalo říct, že oblast počítačových sítí na dlouhé 2

10 Vymezení OpenStacku roky stagnovala. Probíhaly zde sice změny, ale nedostalo se jim takové revoluce jako je virtualizace. Nyní se však objevuje nový trend - softwarově definované sítě. Tento trend abstrahuje software síťových prvků od hardwaru. Tato oblast je však na tolik čerstvá, že se ještě nestačila zcela vyprofilovat, a proto zde existuje několik směrů. Jedním z nich je postavení virtuálních sítí nad již existující infrastrukturou a protokolech. Druhým je zcela jejich nahrazení. V následujících kapitolách bude věnována pozornost prvnímu přístupu. 2.2 Vymezení OpenStacku OpenStack je otevřenou platformou umožňující postavit IaaS cloud, který může být nainstalován i na běžném hardwaru. OpenStack věří v otevřený software, otevřený design, otevřený vývoj, otevřenou komunitu, kde se může do práce zapojit každý. Tato otevřenost dává možnost implementace tohoto prostředí téměř kdekoli. Vizí OpenStacku je do budoucna vytvořit dobře dostupnou cloudovou platformu, která bude splňovat všechny potřeby veřejných a soukromých poskytovatelů cloudů nezávisle na jejich velikosti. Celá stavba OpenStacku se skládá ze série na sobě nezávislých projektů, které byly složeny dohromady, a tím poskytuje různé komponenty, ze kterých je seskládáno celé cloudové řešení. Každá služba poskytuje otevřenou API, takže všechny zdroje mohou být spravovány skrze dashboard. Toto umožňuje administrátorovi kontrolu a uživatelům poskytuje přístup ke cloudu skrze webové rozhraní, příkazový řádek, nebo softwarové balíčky podporující API. Celé řešení se vyznačuje jednoduchostí implementace, obrovskou škálovatelností, velkým množstvím bohatých vylepšení. OpenStack tedy cílí na všechny typy organizací.[2] OpenStack umožňuje spustit několik instancí virtuálních strojů na libovolném množství hostitelských počítačů užívajících jeho prostředků. Tento otevřený projekt se snaží o to, aby byl nezávislý jak na konkrétním hardwaru, tak na hypervisorovi.[3] 3

11 Proč OpenStack? 2.3 Proč OpenStack? We wanted a community where people with similar philosophies about cloud architecture and open-source software can openly collaborate together. We believe in open source, open design, open developement and an open community that is fully transparent. Not a cathedral, a bazaar. OpenStack.org FAQ Na počátku stály dvě velké společnosti NASA a Rackspace. OpenStack debutoval v roce 2010 a vznikl právě z partnerského projektu dvou výše zmíněných společností. Došlo ke zkombinování NASA Nebula počítačové platformy a Rackspace cloudového uložiště.[7] Jednou z největších výhod OpenStacku je síla jeho komunity. Jelikož se na jeho vývoji může podílet opravdu každý, ať už se jedná o samostatné vývojáře, nebo celé společnosti, jde vývoj velmi rychle kupředu. Od svého vzniku už bylo vydáno několik softwarových verzí. Tyto verze jsou pojmenovávány postupně podle písmen abecedy. Jako první byla vydána verze Austin 31. října V současnosti je aktuální verze Juno, která byla vydána v říjnu 2014.[6] Tabulka 2.1: Verze OpenStacku Název Datum vydání Austin 21. října 2010 Bexar 3. února 2011 Cactus 15. dubna 2011 Diablo 22. září 2011 Essex 5. dubna 2012 Folosom 27. září 2012 Grizzly 4. dubna 2013 Havana 17. října 2013 Icehouse 17. dubna 2014 Juno 16. řijna 2014 Na verzi Juno se podílelo mnoho velkých firem jako Cisco Systems, HP, Red Hat, IBM, Vmware. Díky [1] můžeme vidět, jakým dílem přispěla která firma či jed- 4

12 Moduly notlivec. Na verzi Juno se nejvíce podílela společnost Red Hat a nejvíce se pracovalo na modulu nova. Obrázek 2.1: Přínos společností na verzi Juno (převzato z [1]) Obrázek 2.2: Množství práce na jednotlivých modulech (převzato z [1]) 2.4 Moduly V této kapitole budou přiblíženy jednotlivé části (moduly) prostředí OpenStack. OpenStack je systém složený ze série modulů, které mezi sebou komunikují prostřednictvím API. Díky tomu je toto prostředí velmi dobře modifikovatelné. Provázanost jednotlivých modelů lze pozorovat na obrázku 2.3. Dále je zde zmíněň základní princip multitenancy, který je pro cloudová řešení klíčový. Mezi základní moduly Openstacku řadíme: Identity - identifikační služba používaná OpenStackem pro autorizaci a autentizaci. Ověřování probíhá pomocí tokenů. Uživatel přihlášením odesílá žá- 5

13 Moduly dost na Keystone, který tento modul zpracuje, zjistí pověření a vytvoří token. Poté když uživatel odešle žádost do prostředí Compute, tak je vytvořený token odesílán s touto žádostí. Zde dojde ke komparaci tokenu se současnou přístupovou politikou a dojde ke zjištění, zdali má uživatel dostatečná oprávnění pro provedení požadovaného úkonu.[2] Image - služba umožňující práci s virtuálními imagy se nazývá Glance. Image dostupné skrze OpenStack Glance mohou být uloženy na mnoha různých místech od lokálních systémových disků až po distribuované souborové systémy, jako je OpenStack Storage.[3] Compute - také známý jako Nova, poskytuje compute služby, tedy umožňuje běh několika instancí virtuálních strojů na několika hostitelských strojích, na kterých je nainstalována služba OpenStack compute. Ta umožňuje integraci s různými hypervizory, které poskytují software pro správu přístupu virtuálních strojů k hardwaru. OpenStack podporuje KVM, QEMU, VMware ESX, Hyper- V, Xen, Docker. [3] Network - modul pro OpenStack se nazývá Neutron. Neutron spravuje všechny síťové aspekty pro Virtual Networing Infrastructure (VNI) a aspekty Physical Networking Infrastructure (PNI). OpenStack Networking umožňuje projektům vytvářet pokročilé virtuální topologie včetně služeb, jako je firewall, load balancer a virtual private network (VPN). [9] Více se Networkingem budeme zabývat v další kapitole. Cinder - poskytuje infrastrukturu pro mapování volumů v OpenStacku.[3] Telemetry - Ceilometer sbírá měřená data a poskytuje upozornění pro networking, uložiště a compute.[2] Orchestration - umožňuje orchestraci vytváření sady virtuálních strojů na základě vytvořených šablon.[4] Horizon - představuje webové rozhraní, které umožňuje cloudovým administrátorům a uživatelům spravovat různé zdroje a služby OpenStacku. Dashboard umožňuje interakci s OpenStackovým kontrolerem prostředníctvím API.[9] 6

14 Moduly Ve světě cloudu je důležíté oddělit nejen prostředky jednotlivých uživatelů, ale i skupin uživatelů. Tyto skupiny uživatelů se v OpenStacku nazývají tenant (projekt). Prostředí, kde se pohybuje mnoho tenantů, kteří sice sdílejí stejné hardwarové prostředky, ale nemají povědomí o ostatních tenantech, se nazývá multitenanat prostředí. Obrázek 2.3: Konceptuální architektura (převzato z [9]) 7

15 3 Řešení sítí v OpenStack V následující kapitole budou rozebrány protokoly umožňující vytváření virtuálních sítí. Nejdříve bude věnována pozornost technologii VLAN, která je standardem v současných produkčních sítích. Budou zde zmíněna jejich omezení. Dále bude rozebrána technologie VXLAN, která odstraňuje limity VLAN. Na konci bude ještě přiblížen protokol NVGRE. 3.1 Základní pojmy VLAN Pokud počet tenantů nepřesáhl počet okolo tisíce, VLANy jsou stále nejjednodušší a nejvíce efektivní řešení. Jedná se o nejjednodušší formu overlay sítě, kde flat IP síť běží na VLAN underlay. Nejvyšší možný počet je pak okolo 4000 tenantů. Zatímco toto řešení je lehké na implementaci, není příliš škálovatelné při překročení množství okolo 300 hostů v jedné VLANě. Problém také spočívá v závislosti na Spanning Tree Protocolu.[12] VXLAN Virtual Extensible LAN je technologie síťové virtualizace, která se snaží o zlepšení problémů se škálovatelností v datacentrech používajících technologii VLAN. VXLAN používá techniku zapouzdření podobnou jako VLAN, aby zapouzdřil Ethernetové rámce druhé vrstvy do UDP paketů třetí vrstvy. Zatímco rozsah VLANů je limitován 12 bity, identifikátor VXLAN má rozsah 24 bitů, což je přes 16 milionů unikátních identifikátorů.[12] Další výhodou oproti VLAN používající Spanning Tree Protocol je, že VXLAN 8

16 Základní pojmy pakety jsou přenášeny skrz underlay síť s L3 hlavičkou a tedy využívají všech výhod směrování, equal-cost multipath (ECMP) směrování a linkové agragace bez uzavření některých linek. VXLAN umožňuje vytvoření konektivity na druhé vrstvě skrze síť IP.[13] Obrázek 3.1: Formát VXLAN paketu [13] VXLAN používá VXLAN tunnel endpoint (VTEP) zařízení, která mapují koncová zařízení jednotlivých tenantů do segmentů. Tato zařízení mají také na starost VXLAN zapouzdření a rozbalení. Každé toto zařízení má dvě rozhraní, jedno pro LAN jako spojení s koncovým uživatelem a druhé jako IP rozhraní pro transport po IP síti. IP rozhraní má unikátní IP adresu, která identifikuje VTEP zařízení v IP síti, která se nazývá infrastructure LAN. VTEP zařízení použije tuto IP adresu pro zapouzdření Ethernetových rámců a odešle zapouzdřené pakety skrze IP rozhraní. Toto zařízení také objevuje ostatní vzdálená VTEP zařízení pro svůj VXLAN segment. VXLAN segmenty jsou nezávislé na underlay topologii. Dochází ke směrování zapouzdřených paketů založených na vnější IP hlavičce. Toto směrování započne prvním VTEP zařízením, které poskytne zdrojovou IP adresu a je ukončeno VTEP zařízením s cílovou IP adresou. [13] NVGRE Technologie NVGRE vychází z tradičního protokolu Generic Routing Encapsulation (GRE) a poupravuje jednotlivé části hlavičky zapouzdření pro účely síťové virtualizace. Network Virtualization using Generic Routing Encapsulation (NVGRE) protokol je technologie síťové virtualizace, která byla vynalazena v závislosti na problémech se škálovatelností spojené s dříve zmíněnými VLANy, se kterými se potýkají velká datová centra. Podobně jako VXLAN, NVGRE používá tunelování, které zapouzdřuje informace druhé vrstvy do paketu třetí vrstvy. Výsledkem je možnost vytvoření virtualizovaných sítí. 9

17 Co je OpenStack Networking? NVGRE používá unikátní ID zvané Tenant Network Identifier (TNI) s délkou 24 bitů, které je vložené do Ethernetového rámce. TNI umožňuje více než 16 milionů logických sítí. Rámec s GRE zapouzdřením je dále zapouzdřen vnější IP hlavičkou. Nakonec je paket zapouzdřen do vnější MAC hlavičky. [12] Obrázek 3.2: Formát GRE paketu [12] Každý TNI je spojen s vlastním GRE tunelem a identifikuje unikátní virtuální podsíť tenanta. Chování serveru, switche, nebo fyzické NIC, která zapouzdřuje komunikaci virtuálních strojů pomocí NVGRE protokolu, je poměrně přímočaré. Při přenosu dat z jednoho zařízení je přidán TNI do rámce. Ten je zapouzdřen do vnější IP a MAC hlavičky. Poté je odeslán skrze GRE tunel. V cíli dojde k rozbalení na původní rámec a ten je odeslán příslušnému zařízení s původní MAC adresou. [12] 3.2 Co je OpenStack Networking? Networking je pro cloudové řešení OpenStack jedním z klíčových témat. Jak už bylo zmíněno v předchozí kapitole, tak je tato cloudová platforma složena z několika modulů, které spolu komunikují prostřednictvím API. Díky tomuto přístupu jsou také všechny moduly rozšiřitelné pomocí softwaru třetích stran. Tato rozšíření se nazývají pluginy. V této kapitole budou zmíněny podporované síťové pluginy a bude zde rozebrán ten, který implementuje OpenStack v základu Pluginy Neutron podporuje množství pluginů pro networking. Některé pluginy používají klasické Linuxové VLANy a IP tables, zatímco ostatní používají mnohem pokročilejší technologie jako L2-in-L3 tunelování nebo OpenFlow. OpenStack využívá v základu Open vswitch jako network plugin. K nejznámějším z nich patří podle [8]: Big Switch 10

18 Co je OpenStack Networking? Brocade Cisco Cloudbase Hyper-V IBM SDN-VE Linux Bridge Mellanox Midonet ML2 NEC OpenFlow Open vswitch PLUMgrid VMware NSX OpenContrail Tenant and provider sítě Uživatelé vytvářejí tenant sítě kvůli konektivitě v rámci projektu. V základním nastavení jsou plně izolované a nejsou sdíleny s jinými projekty. OpenStack používá v základu Open vswitch plugin, který podle [5] podporuje několik druhů networkingu: Flat - všechny instance jsou na stejné síti, která může být sdílena s hosty. Nepoužívá se zde žádný VLAN tagování nebo jiná technologie pro oddělení sítí. Local - instance jsou na lokálním compute hostu a jsou efektivně izolované od externích sítí. VLAN VXLAN a GRE 11

19 Open vswitch Provider sítě jsou vyvářeny administrátorem a mapují se přímo do fyzické sítě datového centra. Zde se využívá flat nebo VLAN design. [8] 3.3 Open vswitch Open vswitch je otevřený software použitelný v produkčním prostředí, vytvořený pro nasazení jako virtuálního switche ve virtualizovaných prostředích. Virtuální switch posílá komunikaci jak mezi různými virtuálními stroji na stejném hostitelském přístroji, tak mezi virtuálními stroji a fyzickou sítí. Open vswitch může být implementován na stroji s Linuxovou distribucí.[10] Open vswitch je softwarový switch licencovaný pod Apache 2 licencí. Open vswitch podporuje několik na Linuxu postavených virtualizačních technologií jako Xen/XenServer, KVM a VirtualBox. Mezi hlavní komponenty Open vswitche patří: ovs-vswitchd, démon implementující switch. ovsdb-server, databázový server, ke kterému se dotazuje ovs-vswitchd, aby získal svoji konfiguraci. ovs-vsctl, služba pro dotazování a upravení konfigurace ovs-vswitchd. ovs-dpctl, nástroj pro konfiguraci jádra switche. ovs-appctl, služba posílající příkazy běžícím Open vswitch démonům. Open v vswitch dále nabízí nástroje jako: ovs-ofctl, služba pro dotazování a kontrolování OpenFlow switchů a controllerů. ovs-pki, služba pro vytvážření a správu veřejných klíčů pro OpenFlow switche. patch pro tcpdump umožňující analýzu OpenFlow zpráv. ovs-testcontroller, jednoduchý OpenFlow controller. V [22] je popsáno jaké technologie podporuje současná verze: 802.1Q VLAN s trunkovými a access porty výkonné přepínání za použití Linuxového jádra 12

20 Shrnutí sekce NIC bonding s nebo bez LACP na připojeném switchi 802.1ag NetFlow, sflow GRE, GRE over IPSEC, VXLAN,... OpenFlow Shrnutí sekce V předchazejících kapitolách byly představeny základní teoretické informace o cloudové platformě OpenStack. Zmíněny byly základní hodnoty, jako je otevřenost, principy, jako jsou modularita. Dále také jakými způsoby je řešen networking včetně představení pluginů pro něj určených. Následující kapitoly jsou zaměřeny právě na vybrané dva síťové pluginy. Tyto pluginy byly vybrány na základě konzultace s tcpcloud a.s., která díky dlouhodobému pozorování trhu doporučila OpenContrail a VMware NSX, jakožto nejrozšířenější SDN controllery. Tyto controllery budou nejdříve popsány z teoretického hlediska. Poté přijde na řadu jejich porovnání. 13

21 4 OpenContrail Tato kapitola bude zaměřena na popsání SDN řešení OpenContrail. Open- Contrail je otevřené řešení od firmy Juniper. Ta také poskytuje řešení Juniper Contrail, které je zpoplatněné a nabízí technickou podporu. Tyto verze se liší právě jenom existencí podpory. V této kapitole budou nejdříve rozebrány základní pojmy týkající se OpenContrailu. Dále budou popsány jednotlivé komponenty a jak spolu tyto komponenty komunikují. V závěru je vysvětlen princip datové komunikace v rámci tohoto SDN řešení. 4.1 Základní pojmy IF-MAP IF-MAP je zkratka pro The Interface for Metadata Access Points a jedná se o otevřený protokol typu klient-server. V systému OpenContrail je IF-MAP využíván pro rozšíření konfigurací z configuračních rolí do control rolí. [14] XMPP XMPP je zkratka pro Extensible Messaging and Presence Protocol. XMPP je několik otevřených technologií pro komunikaci jako chat, hlasové a video hovory.[15] V systému OpenContrail je XMPP využíván pro komunikaci mezi control a compute rolemi. Dochází pomocí něho k výměně informací jako směrovací informace, konfigurace, statistiky a logy.[14] 14

22 Základní pojmy BGP Border Gateway Protocol potří do skupiny Exterior Gateway Protocol (EGP) a slouží k propagaci, učení a vybrání nejlepších cest v rámci internetu. BGP se vyznačuje komplexním způsobem výpočtu metriky za použití BGP path attributes, které jsou vyměňovány v rámci BGP updatů. BGP se dělí na dva druhy sousedstí (peers), na internal BGP (ibgp) a external BGP (ebgp). Rozdíl mezi nimi je ten, že v rámci ibgp jsou oba sousedi součástí jednoho autonomního systému (AS), zatímco u ebgp patří každý do jiného. [16] V systému OpenContrail je BGP využíván pro výměnu směrovacích informací v rámci control rolí a mezi control rolemi a výchozími branami.[14] MPLS Multiprotocol Label Switching (MPLS) je síťová technologie, která používá připojených návěstí k paketům pro přenos dat po síti. Každý směrovač vytvoří svoje lokální návěstí pro každou síť, kterou má ve své směrovací tabulce. Tato návěstí jsou poté vyměněna se sousedním MPLS směrovačem pomocí protokolu, jako je LDP (Label Distribution Protocol). MPLS návěstí je vloženo mezi L2 a L3. Data jsou tedy směrována na základě MPLS návěstí, kdy jeden směrovač vloží lokální návěstí sousedního směrovače pro cílovou adresu. Sousední směrovač rozbalí paket na svojí lokální MPLS návěstí a znovu zapouzdří paket s lokálním návěstím svého souseda. A takhle proběhne přenos, dokud se paket nedostane do svého cíle. Nejpoužívanějším nasazením MPLS je MPLS VPN. Pro dosažení MPLS VPN je potřebná podpora technologie VRF na okrajových směrovačích. Virtual routing/- forwarding (VRF) představuje VPN směrovací instanci. Každý VRF má vlastní oddělenou směrovací tabulku. [18] Sandesh Sandesh je protokol, který slouží k zasílání analytických informací. V každé části každé role je spojení s analytics rolemi pomocí Sandesh.[14] 15

23 Základní informace 4.2 Základní informace OpenContrail je systém, který může být použit v mnoha síťových scénářích jako například v cloud networkingu nebo v sítích poskytovatele služeb. V soukromém cloudu, ve Virtual Private Cloud (VPC) a v IaaS se vyskytuje prostředí s velkým množstvím tenantů, kde několik tenantů sdílí stejné fyzické zdroje (server, uložiště, fyzickou síť). Každý tenant má přiřazeny vlastní logické zdroje (virtuální stroje, virtuální uložiště, virtuální sítě). Tyto logické zdroje různých tenantů musí být od sebe odděleny. Virtuální sítě v datacentrech mohou být také spojeny s fyzickou IP VPN nebo L2 VPN.[11] OpenContrail je složen ze dvou hlavních komponent. První z nich je Controller, který je logicky centralizovaný, ale fyzicky distribuovaný. Controller je zodpovědný za poskytnutí správy, kontroly a analytických funkcí pro virtuální síť. Také má na starost instruování vrouterů. Druhý je vrouter, který má na starost přenos dat. VRouter běží na hypervizorovi na virtualizovaném serveru. Rozšiřuje fyzickou síť v datovém centru o virtuální overlay síť hostované ve virtualizovaných serverech. VRouter narozdíl od vswitchů poskytuje směrování a služby vyšších vrstev. Virtuální sítě mohou být implementovány různými způsoby. Jedním z nich je použití VLAN nebo VPN. Druhým způsobem je použití dvou sítí, fyzické underlay sítě a virtuální overlay sítě. Role fyzikcé underlay sítě je poskytnutí IP konektivity z jakéhokoli fyzického zařízení do jakéhokoli fyzického zařízení. VRoutery běžící na hypervizorech ve virtuálních serverech vytváří novou overlay síť nad fyzickou underlay sítí za použití množství tunelů mezi sebou. OpenContrail podporuje MPLS over GRE/UDP nebo VXLAN tunely jako overlay síť. Fyzické routery nebo switche tedy neobsahují žádné údaje o tenantech, nemají MAC adresy, IP adresy virtuálních strojů. Znají pouze adresy fyzických serverů. Výjimkou jsou výchozí brány, které spojují virtuální síť s fyzickou sítí. Tyto brány obsahují informace o adresách tenantů. Na druhou stranu vroutery obsahují údaje o tenantech. Udržují oddělené forwarding tabulky pro každou virtuální síť. Tyto tabulky obsahují IP prefixy v případě L3 overlay nebo MAC adresy v případě L2 overlay. [20] Data plane, tedy vroutery mezi sebou, může používat různé technologie overlay jako MPLS over GRE, MPLS over UDP a VXLAN. Control plane protocol mezi Controllerem a fyzickým gateway routerem (nebo switchem) je BGP. Protokol použí- 16

24 Architektura vaný mezi Controllerem a vroutery se nazývá XMPP. Jak bylo výše zmíněno, OpenContrail Controller je fyzicky distribuovaný. To znamená, že je složen z několika typů rolí a každý z nich má několik instancí z důvodu vysoké dostupnosti a horizontální škálovatelnosti. Tyto role mohou být fyzické servery nebo virtuální stroje. Tyto role jsou: Configuration role - poskytuje north-bound Representational State Transfer (REST) Application Programming Interface (API). API může být použit pro konfiguraci systému nebo pro extrahování operačního stavu systému. Control role - implementuje logicky centralizovanou část control planu. Analytics role - je zodpovědný za sběr, porovnání a prezentaci analytických informací.[20] Datové modely hrají důležitou roli v systému OpenContrail. Datový model je tvořen několika objekty a vztahy mezi nimi. Datový model povoluje aplikacím vyjádřit jejich záměr deklarativním způsobem místo imperativního, což je důležité při programování. Datové modely se dělí na dva typy, na high-level service data a low-level technology data model. Oba modely jsou používají modelovací jazyk, který je založený na IF-MAP XML. High-level service data model popisuje požadovaný stav sítě na vysoké úrovni abstrakce za použití objektů, které představují služby poskytované koncovým uživatelům jako virtuální síť nebo bezpečnostní politika. Low-level technology data model popisuje požadovaný stav sítě na nízké úrovni abstrakce za použití objektů, které představují určitý prvek síťového protokolu, jako je BGP route-target nebo VXLAN network identifier. Configuration role jsou zodpovědné za přeměnu změn v high-level service data modelu do odpovídajících změn v low-level technology data modelu. [14] 4.3 Architektura Nyní bude přiblížena architektura OpenContrailu, který je složen ze dvou částí: controlleru a několik vrouterů. Controller poskytuje northbound REST API, které slouží pro integraci s cloudem, například s OpenStackem prostřednictvím neutronu. REST API může být použito také jinými aplikacemi nebo OSS/BSS. API také 17

25 Role slouží k implementaci grafického rozhraní, které je součástí OpenContrailu. Toto rozhraní je přístupné pomocí webového prohlížeče. OpenContrail poskytuje podle [11] tři rozhraní: North-bound REST API komunikující s cloudem a aplikacemi. South-bound rozhraní, které má na starost komunikaci s vroutery nebo fyzickými síťovými prvky. Pro komunikaci s vroutery se používá XMPP a pro komunikaci s routery a switchi se používá BGP a Netconf. East-west rozhraní pro peering s ostaními controllery. Používá se protokol BGP. Obrázek 4.1: Architektura OpenContrailu [11] 4.4 Role Zde bude vysvětlena interní struktura systému. Celý systém je složen z rolí, které spolu vzájemně spolupracují. Tyto role mohou běžet buď na oddělených fyzick- 18

26 Role ých serverech, nebo jenom na virtuálních strojích. Všechny role fungují na principu active-active, tedy že dochazí k rovnoměrnému rozdělení zátěže mezi nimi. Kromě rolí tvořící controller můžeme identifikovat další role, které hrají určitou úlohu v OpenContrail systému. Tyto role jsou vymezeny v [20]: Compute role = virtualizované servery, na kterých běží virtuální stroje tenantů. Gateway role = fyzická výchozí brána, která spojuje virtulní sítě s fyzickou sítí, jako je internet, zákazníkova VPN nebo jiné datové cenetrum. Service role v sobě zahrnuje síťové prvky poskytující služby jako Deep Packet Inspection (DPI), Intrusion Detection (IDP), Intrusion Prevention (IPS) nebo load balancery Compute role plane. V compute roli jsou dvě části vrouteru: vrouter agent a vrouter Forwarding Obrázek 4.2: Stavba compute role [14] VRouter agent představuje proces běžící v rámci Linuxu, který se chová jako lokální control plane a je zodpovědný za: Výměnu informací s Control rolemi za použití XMPP. 19

27 Role Hlášení logů, statistik a událostí analytickým rolím. Instalaci forwarding informací do forwarding plane. Objevování existence a atributů virtuálních strojů ve spolupráci s Novou. Poskytnutí DHCP, ARP, DNS, MDNS proxy. VRouter forwarding plane běží jako modul jádra Linuxu a je zodpovědný za: Zapouzdření paketů overlay sítě při odeslání a jejich rozbalení při přijetí. Přidělování paketů směrovacím instancím. Pakety přijaté z overlay sítě jsou přiřazeny ke směrovacím instancím na základě MPLS značky nebo Virtual Network Identifier (VNI). Virtuální rozhraní do lokálních virtuálních strojů jsou spojené se směrovací instancí. Forwarding plane má taky na starost prohledávání Forwarding Information Base (FIB), kvůli nalezení cílové adresy, a odeslání paketu do příslušné destinace. [11] Control role Control role má podle [14] na starost komunikaci s několika dalšími rolemi: Přijímá konfigurace od configuration role za použití IF-MAP. Vyměňuje informace o cestách s ostatními control rolemi za použití IBGP z důvodu zajištění konzistenci informací. Vyměňuje informace o cestách s vrouter agenty za použití XMPP. Za použití XMPP dochází k zasílání konfigurací, jako je směrovací instance. Slouží jako proxy pro compute role pro některé druhy přenosů. Vyměňuje informace o cestách s výchozími branami za použití BGP. Také odesílají stav konfigurace za použití Netconf. 20

28 Role Obrázek 4.3: Struktura control role [14] Configuration role Configuration role komunikuje s OpenStackem pomocí REST rozhraní. S ostatními configuration rolemi komunikuje skrze distribuovaný synchronizační mechanismus a s control rolemi komunikuje přes IF-MAP. V [14] jsou popsány následující komponenty: REST API server, který poskytuje north-bound rozhraní pro OpenStack nebo jinou aplikaci. Toto rozhraní zajišťuje instalaci konfiguračního stavu za použítí high-level datového modelu. Redis message bus pro zajištění komunikace v rámci vnitřních komponent. Cassandra databázi pro perzistentní uložiště konfigurací. Schema transformer, který se učí o změnách v high-level modelu prostřednictvím Redis message bus a transformuje tyto změny do odpovídajících změn v low-level modelu. 21

29 Role IF-MAP server, který poskytuje south bound rozhraní pro odeslání low-level konfigurací control rolím. Zookeeper slouží k alokaci unikátních identifikátorů objektů a k implementaci transakcí. Obrázek 4.4: Struktura configuration role (bez Zookeepera) [14] Analytics role Analytics role komunikuje s aplikacemi prostřednictvím north-bound REST API. S ostatními analytics rolemi komunikuje skrze distribuovaný synchronizační mechanismus a s ostatními komponentami v control a configuration rolích pomocí XML-base protokolu Sandesh. Analytics role obsahují podle [14] následující komponenty: Collector, který vyměňuje Sandesh zprávy s komponentami v control a configuration rolích, kvůli sběru analytických informací. NoSQL databázi pro ukládání získaných analytických informací. Rules engine automaticky sbírá operační stav při vzniku určité události. 22

30 OpenContrail forwarding plane REST API server poskytující north-bound rozhraní pro dotazování na analytickou databázi pro získání operačního stavu. Query engine slouží k vykonání získaných odpovědí z REST API. Obrázek 4.5: Struktura analytics role [14] 4.5 OpenContrail forwarding plane Nyní budou blíže přiblíženy overlay sítě v systému OpenContrail. Overlay síť může být impementována na třetí nebo druhé vrstvě MPLS over GRE MPLS L3VPN a EVPN běžně používají MPLS over MPLS zapouzdření. Je však možné použití zapouzdření MPLS over GRE. OpenContrail používá MPLS over GRE zapouzdření z několika důvodů, například časté absence podpory MPLS na underlay síti. MPLS over GRE podporuje L3 i L2 overlay. [11] 23

31 OpenContrail forwarding plane Obrázek 4.6: L3 zapouzdření MPLS over GRE [11] Obrázek 4.7: L2 zapouzdření MPLS over GRE [11] VXLAN VXLAN zapouzdření už bylo řešeno dříve, a proto si zde zmíníme jenom rozdíly při použití v OpenContrail. OpenContrail verze se liší ve dvou hlavních bodech. Prvním rozdílem je absence flood-and-learn control planu, místo kterého používá XMPP-based control plane. Z toho důvodu nevyžaduje multicastové skupiny v underlay síti. Druhým rozdílem je, že Virtual Network Identifier (VNI) v hlavičce VXLAN je unikátní v rámci odchozího vrouteru místo toho, aby byl globálně unikátní. Hlavní výhodou použití VXLAN zapouzdření je lepší podpora multi-path v undrelay síti díky přidání entropie do cílového UDP portu vnější hlavičky. Entropie je hash vnitřní hlavičky. [11] MPLS over UDP MPLS over UDP představuje něco mezi MPLS over GRE a VXLAN. Podporuje L2 a L3 overlay. Používá také vnitřní MPLS značku pro identifikaci instance, ale zároveň používá vnější UDP hlavičku s entropii pro efektivní multi-path v uderlay síti. [14] Obrázek 4.8: L3 zapouzdření MPLS over UDP[11] 24

32 OpenContrail forwarding plane Obrázek 4.9: L2 zapouzdření MPLS over UDP [11] L3 a L2 unicast Nyní bude na obrázku 4.10 představen příklad komunikace mezi instancemi při unicastovém vysílání na třetí vstvě. Zelená a červená barva představuje jednotlivé tenanty. Obrázek 4.10: Unicastové vysílání na třetí vrstvě [11] Komunikace započne odesláním IP paketu ze zeleného VM1 do VM2. VM1 má jako výchozí bránu nastavenou adresu zelené routing instance. VM1 odešle ARP požadavek na zjištění MAC adresy zelené routing instance a ARP proxy v routing instanci odešle odpověď. Poté už může VM1 odeslat IP paket. Routing instance prohledá IP FIB obsahující cesty do všech ostatních virtuálních strojů s maskou /32 25

33 OpenContrail forwarding plane ve stejné podsíti, jako je VM1. Tyto cesty jsou naučeny prostřednictvím control role za použití XMPP. Pokud předpokládáme overlay MPLS over GRE, tak routing instance vloží MPLS návěstí naučené od zelené routing instance na hypervizorovi 2. Poté vloží GRE hlavičku a cílovou IP adresu hypervizora 2, kterou nalezne v IP FIB 1. Nyní záleží přenos na typu underlay sítě. Ať je underlay druhé nebo třetí vrstvy, přenos zde proběhne stejně jako v sítí bez overlay. Poté, co underlay síť přenese IP paket na hypervizora 2, vrouter 2 rozbalí paket až na MPLS hlavičku. VRouter 2 prohledá MPLS FIB 2, aby zjistil, které instanci patří daná značka, a přepošle jí routing instanci. VRouter 2 poté odešle paket na VM L3 multicast Multicast může být řešen v OpenContrailu pomocí multicastových stromů v overlay nebo underlay. V případě použití overlay slouží k tvorbě multicastových stromů XMPP. VRoutery vytvoří stromy pro každou virtuální síť, zatímco underlay multicastový strom používá GRE tunel s multicastovou cílovou adresou. Tento přístup je závislý na některém z multicastových směrovacích prokolů jako Protocol Independent Multicast (PIM). [14] 26

34 5 VMware NSX V této kapitole bude příblížen druhý z testovaných SDN controllerů - VMware NSX. Nejdříve budou zmíněny základní obecné informace o produktu. Poté přijde na řadu popsání jednotlivých komponent, ze kterých je NSX složen. V závěru je věnována pozornost vysvětlení principů směrování a přepínání v overlay síti včetně představení, jakým způsobem VMware NSX zapouzdřuje pakety. 5.1 Základní informace VMware NSX představuje technologii síťové virtualizace. NSX umožňuje vytváření a správu softwarových virtuálních sítí. Patří do rodiny Software Defined Data Center (SDDC) produktů, kde SDDC představuje celou architekturu virtualizace napříč celým datovým centrem. Architektura NSX je složená z Consumption, Management plane, Control plane a Data plane. VMware NSX je dostupný ve dvou verzích - NSX-v a NSX-mh. NSX-v je verze závislá na proprietárním VMware řešení, tedy spolupracuje pouze s hypervizorem vsphere od VMware. Druhá verze je NSX-mh, kde mh znamená multi hypervizor a je tedy možné použití s různými hypervizory. Protože OpenStack používá v základu virtualizaci KVM, tak se zde budeme zabývat verzí NSX-mh. U VMware NSX existují dva pohledy na existující síť - logický a transportní. Logický pohled představuje množinu síťových služeb, které virtualizovaný stroj vidí v cloudu. Je tedy nezávislý na underlay hardwaru. V multi-tenant prostředí má každý tenant svůj logický pohled na svoji síť, ale nemůže vidět sítě ostatních tenantů. Tato síť se skládá z vituálních portů, virtuálních switchů a routerů, které spojují virtuální stroje mezi sebou nebo s vnějším světem. Transportní pohled nám na druhou stranu představuje underlay síť. Tato síť obsahuje hypervizory, NSX transport role 27

35 Architektura (jako NSX Gateway) a síťový hardware, který propojuje hypervizory mezi sebou a poskytuje spojení s externí sítí. NSX se chová jako síťový "hypervizor", který virtualizuje zařízení patřící do transportního pohledu. Jejich prostředky pak poskytuje logickým sítím. [19] 5.2 Architektura Architekura VMware NSX se skládá z několika komponent, z nichž některé jsou přímo součastí VMware NSX řešení. Další komponenty, jako je fyzická underlay síť, nebo Cloud Compsuntion (např. OpenStack), jsou součástí architektury, ale nejsou součástí řešení. Komponenty patřící VMware NSX řešení se dají dělit na data plane, control plane a management plane. Data plane představuje služby běžící na hypervizorech, jako jsou logický switch, distribuovaný logický router. Cotrol plane je složeno z clusteru NSX Controllerů. Management plane, poskytující mimo jiné API pro Cloud Compsuntion, je složen z NSX Managera. [21] Data plane V NSX je data plane představován virtuálními switchi, jako je NSX vswitch nebo OVS. VSwitch pro vsphere je založen na vsphere Distributed Switchi (VDS). V implementaci nepoužívající ESXi jako hypervizora je založen na Open vswitchi. Prvky z data plane jsou spravovány clusterem Controllerů. Data plane může být nasazen dvěma způsoby: Overlay network - Zapouzdření může být realizováno pomocí protokolů STT, GRE, VXLAN, IPSEC-STT a IPSEC-GRE. STT tunel je nejčastěji používanou variantou, protože poskytuje nejlepší propustnost. Bridged network - U tohoto způsobu nedochází k vnějšímu zapouzdření. Data jsou posílána přímo na fyzickou síť. Toto je zastaralá a zřídka využívaná varianta, a proto jí nebudeme věnovat další prostor. Data plane se případně ještě zkládá ze zařízení výchozí brány, která poskytuje L2 bridging z VXLAN do VLAN fyzické sítě. Toto zařízení může být NSX Edge 28

36 Role virtální zařízení, poskytující L2, L3, firewall, load-balancing, SSL VPN, DHCP,... Alternativou je použití fyzického switche, který podporuje VXLAN.[17] Control plane Komponentou control planu je NSX controller. NSX controller přijímá instrukce na konfiguraci logických sítí od tenantů prostřednictvím NSX API. Controller také komunikuje s hypervizory za účelem zjištění polohy virtuálních strojů. Díky těmto informacím poté konfiguruje flow prostřednictvím OpenFlow Open vswitche, které běží na transportních rolích. Flow představuje pětici identifikátorů, které jsou spojené s určitou akcí.[19] Controllery bývají shlukovány do clusterů z důvodů vysoké dostupnosti a škálovatelnosti Management plane a Consumption Management plane je tvořen komponentou NSX manager, který poskytuje centralizovanou konfiguraci a poskytuje REST API. Cloudy jsou spravovány a fungují pomocí cloud management platformy (CMP), jako je OpenStack. OpenStack posílá konfigurace logických sítí clusteru NSX Controllerů prostřednictvím NSX API. Správa NSX komponent může být realizována pomocí NSX Managera, který představuje webové grafické rozhraní. Toto rozhraní poskytuje jednoduchou možnost interakce s NSX API. Je potřeba zmínit, že běžná práce s virtuálními switchi bude realizována prostřednicvím OpenStacku, a ne pomocí Managera. [19] NSX-mh velmi často závisí na OpenStacku jako na consumption platformě. VMware nabízí plugin pro Neutron nazývaný NSX plugin. NSX plugin poté umožňuje Netronu využívat NSX-mh pro veškeré síťové služby. 5.3 Role NSX Controller Cluster NSX Controllerů má na starost správu Open vswichtů, které jsou zodpovědné za přenos dat na transportních rolích. Transportní role se dělí na Service, 29

37 Role Gateway a hypervizor. Controllery zajišťují konzistenci mezi logickým a transportním pohledem. Cluster Controllerů je propojen s transportní rolí pomocí dvou kanálů. První z nich využívá OVSDB protokol a druhý OpenFlow. OVSDB kanál poskytuje Controllerům MAC adresy a VIF-ID (ID logických rozhraní interního virtuálního switche) každého lokálního virtuálního stroje. Na základě těchto informací Controllery ví, kde se co nachází, a mohou vytvořit pravidla pro přenos. Controllery poté využívají OpenFlow, pomocí kterého posílají flow záznamy transportním rolím. [17] Obrázek 5.1: Komunikační kanály mezi clusterem Controllerů a OVS [19] Kanály mezi clusterem a transporní rolí mohou být vytvořeny až po proběhnutí autentizace, která probíhá pomocí SSL certifikátu. [21] Service role NSX Service role jsou fyzická zařízení s Open vswitchem. Tato zařízení mají na starost přenos broadcastových a multicastových přenosů. Service role jsou taky shlukovány do clusterů jako Controllery. Každá z transportních rolí (hypervizor nebo gateway) musí vytvořit tunel s každým členem Service clusteru podle overlay technologie, kterou jsme zvolili. Hypervizory nebo gatewaye mohou díky tomu provádět rozložení zátěže. Tyto tunely jsou konfigurovány NSX Controllery. 30

38 Role Obrázek 5.2: Cluster Service rolí [19] Hypervizor role Tyto role představují servery, na kterých běží virtuální stroje. Tyto stroje jsou napojeny na OVS. V základu tyto role využívají dvě fyzická rozhraní (může jich být více a tvořit agregovanou linku). Jedno pro management a druhé pro přenos dat virtuálních strojů. Rozhraní pro přenos dat virtuálních strojů je napojeno na externí bridge. Tento bridge je spojený také s interním bridgem, který je napojen na virtuální stroje. Flow informace přijímá od Controllerů právě interní bridge. [17] 31

39 Role Obrázek 5.3: Logická topologie v rámci serveru představující roli Hypervizora [19] Open vswitch se dá rozdělit na dvě oblasti podle toho, kde operuje v rámci operačního systému. První je uživatelský prostor, kde jsou moduly OVS zodpovědné za komunikaci s clusterem Controllerů a jsou zde uloženy flow informace. V druhé oblasti, oblasti jádra, se nachází OVS modul jádra. Když modul jádra poprvé přijme data, o kterých nemá záznam, tak je přepošle modulům do uživatelského prostředí, díky čemuž se od nich naučí, jak z daným tokem zacházet, a další pakety jsou už přeposílány pouze pomocí jádra. [21] Gateway role Gateway role se dají rozdělit do dvou kategorií - L2 a L3 gateway. L2 gateway provádí spojení mezi logickými switchi a nevirtualizovanými prostředky či zařízeními podporujícími pouze VLAN v rámci stejné podsítě. Princip u posílání dat z virtuálního světa do fyzického spočívá v tom, že virtuální stroje odešlou data na L2 gateway zapouzdřené v některém z tunelovacích protokolů. Gateway rozbalí pakety, odstraní overlay hlavičku a přepošle je do požadované VLANy. Z fyzického světa do virtuálního je fungování analogické. Druhou kategorií gateway je L3, která zajišťuje komunikaci v rámci různých podsítí. To je potřeba při East-west (L3 v rámci datového centra) i North-south (L3 spojení mimo datacentrum jako internet a WAN) komunikaci. L3 gateway se od L2 32

40 Směrování a přepínání liší hlavně tím, že poskytuje směrování. Každému tenantu je přiřazen jeden logický směrovač. L3 gateway rolí může být až 10, přičemž každý tenant má přiřazen 2 role - jednu jako aktivní a druhou jako zálohu. Controllery rozloží tenanty rovnoměrně mezi všechny L3 gateway. Každá jiná transportní role poté vytvoří STT tunel se svou aktivní a záložní gateway. [21] Obrázek 5.4: NSX L3 gateway [19] 5.4 Směrování a přepínání Přepínání Role jsme si představili a teď se podíváme, jak funguje logické přepínání. Díky spojení overlay a underlay sítě máme možnost propojit virtuální stroje ke stejné síti, ačkoli každý může běžet na jiném serveru. Nyní si představíme případ unicastu mezi virtuálními stroji. Před tím, než může proběhnout samotná výměna dat mezi nimi, musí naplnit svoje ARP tabulky. 33

41 Směrování a přepínání Obrázek 5.5: ARP komunikace mezi virtuálnimi stroji [17] V prvním kroku chce virtuální stroj VM1 komunikovat s VM3, přičemž oba patří do stejné logické sítě (zelená). VM1 vygeneruje ARP požadavek a odešle ho. Ve druhém kroku přijme OVS ARP požadavek, a protože se jedná o broadcastové vysílání, tak musí být odeslán na všechny VM patřící do zelené sítě. To znamená odeslání na VM2, který patří stejnému hypervizorovi, ale také odeslání na vzdáleného hypervizora. V tomto případě je použit broadcast pomocí Service rolí. OVS tedy zapouzdří ARP požadavek do používané overlay technologie a odešle ho příslušné Service roli. Ve třetím kroku přijme Service role ARP požadavek od OVS a přepošle ho na všechny transportní role, které mají alespoň jeden výskyt patřící do green LS - tedy na hypervizora číslo 2. Service role získají tuto informaci díky Controllerům, které mají pohled na celou topologii. Tyto informace jsou ve formě flow záznamů. V kroku číslo čtyři OVS přijme ARP požadavek a odešle ho všem virtuálním strojům pátřícím do zelené sítě (VM3). V pátem kroku VM3 přijme ARP požadavek, uloží si ARP záznam do své tabulky a odešle odpověď zpět na VM1. Krok číslo 6 a 7 představuje doručení ARP odpovědi. Když má VM1 propojenou IP adresu s konkrétní MAC adresou, může proběhnout samotná komunikace - tedy VM1 vygeneruje paket s cílovou adresou VM3. OVS na hypervizoru 1 má nyní uložený flow záznam do VM3. OVS zapouzdří paket a odešle ho na hypervizora 2. OVS na hypervizorovi 2 přijme paket, rozbalí ho a 34

42 Směrování a přepínání odešle ho VM3. [21] Obrázek 5.6: Unicastová komunikace mezi dvěma virtuálními stroji [21] Nakonec je potřeba přiblížit vícesměrové vysílání, jako je broadcast, neznámý unicast a nebo multicast (BUM). VMware NSX poskytuje dva módy pro vícesměrové vysílání - Service Node replikace a Source-based replikace. V dřívějších příkladech jsme uvažovali Service Node replikaci, která je také doporučena pro velké implementace. Source-based replikace spočívá v tom, že zodpovědnost za replikaci komunikace na sebe bere transportní role. [17] Směrování Nyní bude představeno logické směrování. Jak už bylo dříve zmíněno, tak směrovaná komunikace v datových centrech se dá dělit na komunikaci, která je v rámci datového centra, a na tu, která je mezi datovým centrem a venkovním světem. Směrování poskytované pluginem NSX se dá dělit na centralizované a distribuované. Centralizované směrování poskytuje jak east-west, tak north-south komunikaci. Kromě směrování NSX L3 Gateway poskytuje například NAT. V centralizovaném směrování jde veškerá komunikace mezi podsítěmi přes logický router, který sídlí na L3 Gateway, a to i v případě, že komunikujicí virtuální stroje patřící do jíné podsítě, jsou na stejném hypervizorovi. [17] 35

43 Směrování a přepínání Obrázek 5.7: Příklad komunikace při distribuovaném směrování[21] Komunikace započne mezi dvěma virtuálními stroji s předpokladem, že VM1 má zaplněnou APR cache a ví tedy, kde se nachází Gateway. VM1 vygeneruje paket, ten je zapouzdřen a odeslán na L3 Gateway. Gateway rozbalí paket a předá ho logickému směrovači. Při předpokladu, že logický router nemá ARP záznam o VM2, vygeneruje ARP požadavek, aby zjistil MAC adresu VM2. ARP požadavek je tedy odeslán na Service roli. Service role odešle ARP na všechny hypervizory, které mají alespoň jeden výskyt patřící do červeného LS. Hypervizor přijme ARP a předá ho VM2. VM2 odešle ARP odpověď zpět na L3 Gateway. Poté, co logický směrovač přijme ARP odpověď, odešle pakety z VM1 přímo na VM2. Tento typ komunikace je vyhovující při north-south komunikaci, ale jak už bylo dříve zmíněno, je neefektivní při south-east komunikaci. Z tohoto důvodu poskytuje NSX distribuované směrování. To znamená, že směrování je prováděno na každém hypervizorovi. To je zajištěno tím, že každý hypervizor nainstaluje do svého jádra specifické flow informace naučené od Controlleru. Směrování mezi virtuálními stroji je tedy zajištěno pomocí logických switchů a komunikace s vnějším světem je identická s centralizovaným směrováním. Toto chování je možné díky l3d daemonu, který implementuje směrovací funkcionalitu do OVS. Dá se tedy říct, že z OVS se stává logický směrovač. [21] 36

44 Zapouzdření komunikace 5.5 Zapouzdření komunikace STT Stateless Transport Tunneling (STT) protokol je overlay řešení poskytující L2inTCP zapouzření. To znamená, že originalní rámec od virtuálního stroje je zapozdřen do L2, L3 a L4 hlaviček. Vnější UDP port není okopírovaný port vnitřní hlavičky, jako je tomu u VXLAN, ale je získán hashováním vnitřích L2,L3 a L4 hlaviček. V obrázku 5.11 lze toto zapouzdření pozorovat. [21] Obrázek 5.8: STT zapouzdření [21] GRE GRE zde představuje L2inIP zapouzdření, kde je původní rámec zapouzdřen do L2 a L3 hlaviček. Vzhledem k tomu, že není přítomna L4 hlavička, tak bude rozložení zátěže probíhat pouze na základě cílové IP adresy. Toto zapouzdření je znázorněno na obrázku [21] Obrázek 5.9: GRE zapouzdření [21] 37

45 6 Porovnání Juniper Contrail a VMware NSX V této kapitole dojde na porovnání SDN controllerů Juniper Contrail a VMware NSX. Tyto dva produkty byly vybrány po konzultaci s odborníky ze společnosti tcp cloud a.s., která se dlouhodobě orientuje na implementaci jednoho z nejlepších cloudových řešení na světě. Snahou bylo vybrat dva nejsilnější hráče na poli SDN. Na základě dlouhodobého pozorování trhu jsme došli ke konsensu, že budou testovány právě produkty Juniperu, jakožto jednoho z předních výrobců síťových zařízení na světě, a VMwaru, který je světovou jedničkou na poli virtualice. Na začátku bude představena infrastruktura a laboratorní prostředí, na kterém nám bylo umožněno implementovat a testovat. Dále budou představeny architektury konkrétních implementací. Zde také budou přiloženy výsledky výkonostního testování SDN controlleru OpenContrail. Test controlleru VMware NSX nebude přiložen z důvodu případného porušení licenčních ujednání. Následovat bude testování service chainingu. Na závěr této kapitoly přijde na řadu hlavní porovnání obou controllerů z hlediska globálních vlastností. 6.1 Lab prostředí Jako prostředí pro implementaci byla použita infrastruktura datového centra Písek (tcp). Jejich datové centrum disponuje v současné době jedním z nejvyspělejších hardwarových infrastruktur v ČR. Serverové a storage služby zde zajišťuje špičkové vybavení od firmy IBM. Networking má na starost nejmodernější síťové vybavení od firmy Juniper Networks, jako je QFabric System a směrovače MX240. Tyto směrovače jsou připojeny přímo do NIX.CZ, se kterým si pomocí protokolu BGP vyměňují 38

46 Lab prostředí cesty do celého internetu. Díky tomuto zázemí je možné simulovat reálné produkční prostředí a je tedy možné otestovat, jak by obě řešení obstála v praxi Hardware infrastruktura V rámci této podkapitoly bude popsán hardware použitý pro instalaci. Jako servery posloužily IBM blade HS22V osazené 200GB RAM a dvěma procesory Intel Xeon s 12 jádry (6 jader každý) s podporou Hyper-threading. Síťová infrastruktura je zajištěna pomocí dvou zařízení Juniper EX4500, což jsou L3 switche osazené 10GB porty. Tyto switche jsou spojené do Virtual Chassis (zapojené do stohu). Datové uložiště je zajištěno pomocí diskového systému IBM Storwize V7000 připojeného fiber channelem, konkrétně čtyřmi páry z důvodu vysoké dostupnosti Logická Architektura V této podkapitole bude pozornost zaměřena na popsání logických topologií, nejdříve pro OpenContrail a poté pro VMware NSX. OpenContrail Zde bude představeno konrétní řešení OpenStacku s SDN controllerem Open- Contrail. OpenStack Controller byl spolu s Controllerem Contrailu nainstalován na jednom virtuálním stroji s Ubuntu LTS, který běžel na VMware ESXi. Compute role OpenStacku byly nainstalovány na dvou fyzických serverech s Ubuntu LTS. Zakončení tunelů a výchozí brána do externí sítě byla realizováno pomocí dvou routerů Juniper MX240. Na obrázku 6.1 jsou znázorněny dvě sítě, kde první spojuje storage IBM Storwize s Compute nody a VMware ESX. Tato síť představuje Storage Area Network (SAN), tedy oddělenou datovou síť pouze pro storage komunikaci. Druhá síť je běžná datová síť pro normální komunikaci. 39

47 Lab prostředí Obrázek 6.1: Logická topologie nasazení OpenContrail VMware NSX Zde bude popsána logická topologie, podle které probíhala implementace OpenStacku s SDN controllerem VMware NSX. OpenStack Controller byl stejně jako v případě verze s OpenContrailem nainstalován na VMware ESXi. Dále zde budou virtuální stroje NSX Manager, NSX Controller a NSX Gateway. Compute role byly na dvou fyzických strojích s Ubuntu LTS. 40

48 Výsledky testování Obrázek 6.2: Logická topologie nasazení VMware NSX 6.2 Výsledky testování Výkonostní metriky V této sekci se zaměříme na otestování výkonnostních metrik, jako je propustnost a odezva. OpenContrail testování K testování byly vytvořeny čtyři scénáře. Jako první uvažujme dvě instance, které patří do stejné sítě a jsou na stejné Compute roli. Druhý scénář počítá s dvěma instancemi na stejné Compute roli, ale každá v jiné síti. U třetího scénáře přidáme i druhou Compute roli a na každé jsme spustili jednu instanci, které však budou patřit do stejné sítě. Jako poslední test byly dvě Compute role, každá s jednou instancí, ale 41

49 Výsledky testování každá patřící do jiné sítě. Testované instance běžely na Ubuntu LTS. Testovalo se pomocí utilit iperf a ping. Iperf byl testován na TCP komunikaci bez duplexu, čili jedním směrem. Všude po cestě byla zvýšena maximální přenosová jednotku (MTU) na Obrázek 6.3: Testovací topologie Nyní přijde na řadu první testování, tedy dvě instance běžící na stejném hypervizorovi a patřící do stejné sítě. Tabulka 6.1: Dvě instance ve stejné síti na stejném hypervizorovi - propustnost Přeneseno Bandwidth 1. měření 18,2 GB 15,7 Gb/s 2. měření 19,4 GB 16,6 Gb/s 3. měření 19,2 GB 16,5 Gb/s 4. měření 17,9 GB 15,4 Gb/s 42

50 Výsledky testování Tabulka 6.2: Dvě instance ve stejné síti na stejném hypervizorovi - odezva min avg max 0,331 0,455 0,961 Tento test ukázal poměrně stabilní propustnost i dobrou průměrnou odezvu, která je okolo 0,5 ms. Druhý scénář - dvě instance na stejném hypervizorovi, ale každá v jiné síti. Tabulka 6.3: Dvě instance, každá v jiné síti na stejném hypervizorovi - propustnost Přeneseno Bandwidth 1. měření 18,0 GB 15,5 Gb/s 2. měření 12,9 GB 11,1 Gb/s 3. měření 16,1 GB 13,8 Gb/s 4. měření 19,0 GB 16,3 Gb/s Tabulka 6.4: Dvě instance, každá v jiné síti na stejném hypervizorovi - odezva min avg max 0,416 0,487 0,868 V tomto měření se vyskytl jeden výkyv od stabilních hodnot. Propustnost i odezva je však obdobná s předchozím měřením. Třetí scénář - dvě instance na jiném hypervizorovi, ale každá ve stejné síti. Tabulka 6.5: Dvě instance ve stejné síti na jiném hypervizorovi - propustnost Přeneseno Bandwidth 1. měření 11,4 GB 9,82 Gb/s 2. měření 11,4 GB 9,81 Gb/s 3. měření 11,4 GB 9,81 Gb/s 4. měření 11,4 GB 9,80 Gb/s 43

51 Výsledky testování Tabulka 6.6: Dvě instance ve stejné síti na jiném hypervizorovi - odezva min avg max 0,580 0,716 2,219 V tomto měření lze sledovat očekávatelný pokles propustnosti i odezvy. Ačkoli jsou hypervizory propojeny dvěma 10 GB linkami spojenými do jedné virtuální pomocí technologie LACP, maximální teoretickou hodnotu musíme brát 10 GB z podstaty fungování této technologie. A lze tedy říct, že hodnota okolo 9,81 je velmi dobrá. Průměrná propustnost pořád zůstala pod 1 ms. Čtvrtý scénář - dvě instance na jiném hypervizorovi a každá v jiné síti. Tabulka 6.7: Dvě instance, každá v jiné síti na jiném hypervizorovi - propustnost Přeneseno Bandwidth 1. měření 11,4 GB 9,81 Gb/s 2. měření 11,4 GB 9,80 Gb/s 3. měření 11,4 GB 9,82 Gb/s 4. měření 11,4 GB 9,77 Gb/s Tabulka 6.8: Dvě instance, každá v jiné síti na jiném hypervizorovi - odezva min avg max 0,867 0,988 2,258 V případě měření mezi dvěma hypervizory, kde jsou instance v jiných sítích, lze pozorovat obdobnou propustnost jako v předchozím měření. Zhoršila se však odezva. VMware NSX testování V této sekci bohužel nebudou výsledky testování VMware NSX z několika důvodů. První pokus o implementaci byl s veřejně dostupnou verzí OpenStacku od 44

52 Výsledky testování VMware - vsphere OpenStack Virtual Appliance, která ale v této verzi neobsahuje Neutron, který je pro implementaci s VMware NSX naprosto klíčový. Proto se přistoupilo k implementaci s VMware Integrated OpenStack (VIO), u které nemohou být zveřejněny výsledky, protože by to znamenalo porušení End User License Agreement (EULA). Funkční provnání Zde si přiblížíme, jak je v OpenContrailu a VMware NSX řešen service chaining. Service chaining je známý z klasických sítí, kde představuje spojení distribuovaných prvků, které poskytují nejrůznější služby od firewallu až po load balancery v řadě za sebou. V softwarově definovaných sítích je service chaining řešen vytvořením minimálně jedné servisní instance, která je poté propojena s virtuálními sítěmi. Jako servisní instance může sloužit jakýkoli virtulní stroj. Pokud by byl potřeba jednoduchý analyzátor síťového provozu, bohatě postačí například instance libovolné distribuce Linuxu s nainstalovaným nástrojem pro analýzu, jako je tcpdump nebo Wireshark. Není však problém použit virtuální firewall, který v dnešní době nabízejí firmy jako Fortigate nebo Palo Alto, a vložit ho třeba mezi virtuální síť v OpenStacku a síť veřejnou. Nejdříve byl otestovám load balancer as a service (LBaaS) u OpenContrailu. Poté bylo vyzkoušeno vložení servisní instance, která prováděla NAT mezi dvěma instancemi, kde každá běžela na jiné sítí. LBaaS řešení u OpenContrailu bylo otestováno vytvořením dvou instancí Ubuntu LTS a na každou byl nainstalován webový démon Apache2 se základní stránkou index.html a textem test1 na první instanci a test2 na druhé. Poté byl vytvořen load balancer pool, kterému se nastavil protokol HTTP pro rozložení zátěže a metodu round robin (každý požadavek jinam). Dále došlo na přiřazení našich instancí k tomuto poolu. Nakonec bylo třeba přiřadit virtuální IP (VIP) load balancer poolu. Test byl proveden opakovaným přistupovaním na virtuální IP a pozorováním přepínaní mezi test1 a test2. Tento tedy dopadl úspěšně. Na obrázku 6.4 lze vidět, že na zobrazení topologie není služba LBaaS nijak znázorněna. 45

53 Výsledky testování Obrázek 6.4: Testovací topologie LBaaS Dále bylo otestováno propojení dvou sítí přes servisní instanci Centos 6.4. Pro jeho test byly spuštěny dva virtuální stroje Ubuntu LTS, každý v jiné síti. Test byl proveden zkouškou spočívající v překladání adres mezi sítěmi (NAT). Nejdříve bylo potřeba vytvořit servisní šablonu v prostředí OpenContrail. Zde byl nastaven onen image Centosu včetně pravého a levého rozhraní, přes které se virtuální sítě propojují. Pak došlo na vytvoření konkrétní servisní instance. Poslední nastavení v OpenContrailu bylo vytvoření politiky povolující komunikaci mezi sítěmi a přiřazení servisní instance k této politice. 46

54 Výsledky testování Obrázek 6.5: Testovací topologie NAT Pak už bylo potřeba jenom nastavit Centos, aby překládal adresy. Nejdříve bylo nutné přepnout v kernelu parametr ipv4 ip forward na 1, tedy aby instance předávala dál síťovou komunikaci, která není pro ni určena. Poté už jenom stačilo přidat záznám do iptables, aby byl prováděn překlad adres, v linuxu takzvaná maškaráda. Test proběhl pomocí posílání ping requestů z jedné instance na druhou. Na druhé instanci byl spuštěn program tcpdump (program na odchytávání síťové komunikace) a pozorován příchozí ping se zdrojovou adresou servisní instance. Tento test tedy také proběhl úspěšně. VMware NSX-mh bohužel service chaining nenabízí, a proto zde nebudou žádné scénáře, které by u něj byly testovány. 47