Openstack és fizikai hálózati eszközök integrációja

Halmos Dávid (2020) Openstack és fizikai hálózati eszközök integrációja. Pénzügyi és Számviteli Kar.

	PDF Halmos_David_szakdolgozat_BMKUSO_1738.pdf Hozzáférés joga: Csak nyilvántartásba vett egyetemi IP címekről nyitható meg Download (930kB)
	PDF BA_TO_Halmos_Dávid_BMKUSO.pdf Hozzáférés joga: Csak nyilvántartásba vett egyetemi IP címekről nyitható meg Download (262kB)

Absztrakt (kivonat)

Szakdolgozatom kezdetekben meghatározott célja volt, hogy az olvasó átfogó képet kapjon az OpenStack projektről és komponenseiről, valamint a DevStack fejlesztői környezet kialakításáról és az Extreme Switchek konfigurációjáért felelős mechanizmus meghajtó fejlesztéséről. Az OpenStack projekt célja egy infrastruktúra-szolgáltatást nyújtó platform megvalósítása nyílt forráskodú szoftverekkel, a projekt célközönsége pedig az egyszerű felhasználóktól egészen a rendszerüzemeltetőkig terjed. A választott komponensek és beállítások függvényében egészen komplex rendszerek kialakítására is alkalmas. Az OpenStack és az ML2 (Modular Layer 2) meghajtó megértéséhez, fontosnak tartottam szakirodalom alapján, röviden jellemezni a virtualizáció és a felhőalapú számítástechnika legfontosabb fogalmait, típusait. Ezen kívül igyekeztem kifejteni a virtualizációhoz szorosan kapcsolódó, hiperfelügyelő fogalmát. Az ezt követő részben röviden bemutattam az Openstack, jelenlegi dolgozatban is használt, főbb komponenseit. Többek között az autentikációért felelős Keystonet, a képfájlok kezeléséért felelős Glancet, a virtuális gépek kezeléséért felelős Novát, valamint a hálózati szervizekért felelős Neutron komponenst, amely a jelen fejlesztés részét képező meghajtó segítségével kommunikál a külső fizikai hálózati eszközzel. A fejlesztés kezdeti lépéseként összegyűjtöttem az eszközök listáját, amelyek szükségesek a fejlesztői környezet kialakításához, valamint a fejlesztés implementálásához: · Devstack: Egy szkript és segédprogramkészlet, OpenStack felhő fejlesztői környezet gyors létrehozását teszi lehetővővé, egyéni konfigurációs lehetőségekkel. Szakdolgozatomban a multi-node OpenStack telepítésére használtam fel. Részletesebben a 4.1 fejezetben írtam róla. · Libvirt: Szoftvergyűjtemény, amely képes különböző virtuálizációs technológiák kezelésére, mint például háttértár, hálózati interfész. A virtuális gépek, hálózatok létrehozására használtam a fejlesztői környezet kialakításakor. Részletesebben a 4.2 fejezetben írtam róla. · KVM: Hiperfelügyelő, amely képes kihasználni a processzorokban rejlő hardveres virtualizációt megvalósító technológiát. Az OpenStacket futtató virtuális gépek egyes perifériáinak emulálását látja el. Bővebben a 4.3 fejezetben írtam róla. · QEMU: Processzor bővítményei KVM-mel kombinálva jelentősen megnövelik a virtuális gépek teljesítményét, emellett biztosít egy robusztus hiperfelügyelőt, amely a kernel szintjén fut. A fejlesztői környezetben a virtuális gépek egyes perifériáinak emulálását látja el. A tenant VM-ek virtualizációját a devstack automatikusan ellátta, viszont a nodeokat(1 kontroller, 2 compute hoszt) és a Virtual EXOS VM-eket nekem kellett a virtuális képfájlból a virtuális gépet elindítani a QEMU segítségével. Bővebben a 4.4 fejezetben írtam róla. · EXOS SOAP: Az EXOS SOAP egy Extreme Networks által biztosított, python nyelven íródott programcsomag, amellyel a későbbiekben részletezett mechanizmus meghajtó képes a switchhel való kommunikációra. Az általam kifejlesztett ML2 Mechanizmus meghajtó ezt a programcsomagot használja a virtual EXOS-szel történő közvetlen kommunikációra. Erről a csomagról részletesebben is írok a 8.2 fejezetben. · Virtual EXOS: Ez egy virtuális képfájl, amit az Extreme Networks fejlesztett és bocsájt rendelkezésre. Segítségével a switch működését lehet emulálni, virtuális környezetben. A fejlesztés során ezt használtam devstack környezetben, annak érdekében, hogy a valós fizikai eszközt emuláljam. A Virtual EXOS virtuális gépet KVM-mel indítottam el és a megfelelő konfiguráció eredménye képpen a devstack tudta használni, mint hálózati kapcsoló. Dolgozatom 4.6 fejzetében írtam róla részletesebben. Ezek után megterveztem a fejlesztői környezethez szükséges hálózati topológiát, valamint a kommunikációhoz szükséges hálózati interfészeket. Az OpenStack szervizek futtatásához szükséges nodeok, valamint a menedzsment és tenant hálózat létrehozásához a libvirt, kvm, qemu eszközöket használtam. A korábban libvirtben definiált, hosztokon futtatott virtuális gépek forgalmához használt hálózat kialakítását linux hálózati hidak létrehozásával oldottam meg, amelyek az exOS virtuális switch egy-egy portjához csatlakoznak – így biztosítottam, hogy a tenantok közti forgalom a switchen menjen keresztül, szimulálva egy valós, fizikai környezetet. A fejlesztői környezet (Multi-Node konfiguráció) komponensei a következők: - Egy klaszter vezérlő, amelyen az OpenStack szervizek többsége fut, képes hálózati erőforrások létrehozására, virtuális gépek hosztolására, illetve indítására a compute hosztokon - Két compute hoszt, amelyen az OpenStack worker szervizei futnak. Virtuális gépek hosztolására képes. - Extreme switch emulátor, amelyet a klaszter vezérlőn futó neutron szerver konfigurál, a mechanizmus meghajtó implementálása és integrálása után. A virtuális gépek közötti forgalom ezen fut keresztül. A 6. fejezetben a tényleges rendszer konfigurációját és tesztelését mutatom be. Első lépésben ismertetem a szükséges hálózat, valamint a virtuális OpenStack hosztok létrehozását és konfigurációját. Ezután következett a Devstack fejlesztői környezet konfigurálása és telepítése - részletesen dokumentálva - az előbb említett topológiának megfelelően. A Devstack telepítését követően leteszteltem az OpenStack funkcióit – úgy mint képfájl, flavor (a virtuális gép számítási, memória és tároló kapacitását tartalmazza) hálózat, port, virtuális gépek létrehozása. Az OpenStack funkcióinak ellenőrzése után a különböző hosztokon indított gépek között teszteltem a kommunikációt, ezáltal meggyőződtem róla, hogy a forgalom valóban a switchen megy keresztül. A gépek kizárólag a switch konfigurálása után, az adott VLAN létrehozása, és portok hozzáadása után kaptak IP címet a DHCP kiszolgálótól, így ezen információ és további tesztek futtatásával sikerült megerősíteni, hogy sikerült a tervezett hálózati topológiát megvalósítani. Ezt követően a 7. fejezetben ismertettem a Neutron ML2 beépülő modul működését, amely lehetővé teszi az OpenStack Networking számára a 2. rétegbeli hálózati technológiák egyidejű felhasználását az adatközpontokban. Ez a modul különböző hálózat típusokat támogat – mint például: flat, vlan, vxlan. Ezen hálózati típusokat bemutattam és saját szerkesztésű ábrákon szemléltettem, majd taglaltam a MechanismDriver szerepét és működését. Ezen kívül szakirodalom alapján, röviden definiáltam a mechanizmus meghajtó által használható absztrakt metódusokat, amelyek valamely hálózati esemény megtörténése esetén, képes a Neutrontól függetlenül működő eszközökkel való kommunikációra. A 7. fejezet utolsó részében a MechanismDriver ismertetése után röviden elemeztem más gyártók megoldásait, ezáltal megismerve a szükséges konfigurációs sémát. Különböző gyártók egyedi megoldásokat nyújtanak annak érdekében, hogy az általuk gyártott hardver képes legyen a mechanizmus meghajtó által biztosított lehetőségeket kiaknázni, és ezáltal kiváltani a felhasználó által más esetben szükséges manuális konfigurációt. A 8. fejezet mutatja be a mechanizmus meghajtó implementálásának lépéseit az Extreme EXOS switchekhez. Mivel az Extreme Switchekkel SOAP protokollon keresztül kényelmesen lehet tranzakciókat megvalósítani, ezért én is ezt a protokollt választottam az implementációhoz. Ennek megfelelően részleteztem a SOAP protokoll jellemzőit és képességeit, amelynek alapjaira épül az Extreme SOAP interfész is. Az Extreme SOAP interfész képes a kommunikációhoz elengedhetetlen munkamenetek kezelésére, a kéréseket tartalmazó XML fájlok létrehozására és a válaszok feldolgozására. Az XML kérések továbbításához HTTP protokollra támaszkodik, az ennél szabányos kérés/válasz modellt használja. Ebben a fejezetben ismertettem továbbá a meghajtó Neutronba történő integrációjának lépéseit, valamint megterveztem és implementáltam egy konfigurációs sémát, amely a switchhel való kommunikációhoz szükséges adatokat és a portok térképét tartalmazza. Ezt, és a Neutron konfigurációs fájljait használja fel a meghajtó a megfelelő VLAN-ok létrehozásához, a hoszthoz tartozó portok beállításához. A konfiguráció beolvasását és feldolgozását, mind a Neutron konfigurációs fájlból, mind a felhő operátor által megadott ML2 konfigurációs fájlból (switch adatok, port térkép, VLAN intervallum) a meghajtótól függetlenül működő konfigurációs szkript végzi. Az ebből kiolvasott információk felhasználásával működik a következőkben bemutatott meghajtóprogram. Az általam kifejlesztett ML2 mechanizmus meghajtó jelenleg a következő hálózati események esetén képes a switch konfigurációjára: - VLAN típusú hálózat létrehozása esetén felkonfigurálja a switchet a Neutron által kiosztott segmentation_id alapján - Virtuális hálózattal, vagy porttal indított gép esetén, a kommunikáció biztosítása érdekében a megfelelő VLAN-hoz hozzáadja a gép hosztjaként szolgáló – switchet tartozó portot - Ha a gép nem a klaszter kontrolleren kerül indításra, azaz nem éri el közvetlenül a DHCP kiszolgálót, akkor a DHCP szervizeket futtató hoszt portját is hozzáadja a konfigurációhoz - Migrálás/Evakuáció esetén frissíti a switch konfigurációt - Virtuális gép törlése esetén törli a hoszt portját a konfigurációból, természetesen csak akkor, ha ezt más gép már nem használja - Hálózat törlése esetén eltávolítja az adott taggel rendelkező VLAN-t A mechanizmus meghajtó bemutatása és a tesztesetek kidolgozása után, részletesen dokumentáltam a használati esetek megvalósítását és ezek eredményeit. Utolsó lépésként felsoroltam olyan továbbfejlesztési lehetőségeket, melyek túlmutatnak a jelenlegi fejlesztésen, de elviekben lehetséges implementációjuk. Például: - Trunk portok támogatása, amely lehetővé teszi hálózati alagút megoldások támogatását - VXLAN hálózat támogatása - Virtuális router támogatása

Intézmény

Budapesti Gazdasági Egyetem

Kar

Pénzügyi és Számviteli Kar

Tanszék

Gazdaságinformatika Tanszék

Tudományterület/tudományág

NEM RÉSZLETEZETT

Szak

Gazdaságinformatikus (BA)

Konzulens(ek)

Konzulens neve

Konzulens típusa

Beosztás, tudományos fokozat, intézmény

Dr. Gubán Ákos

Belső

főiskolai tanár, Gazdaságinformatika Tanszék, PSZK

Guban.Akos@uni-bge.hu

Mű típusa:	diplomadolgozat (NEM RÉSZLETEZETT)
Kulcsszavak:	hálózat tervezése, meghajtó, ML2, openstack, telekommunikáció
SWORD Depositor:	Archive User
Felhasználói azonosító szám (ID):	Archive User
Rekord készítés dátuma:	2020. Nov. 27. 04:40
Utolsó módosítás:	2021. Már. 29. 10:54

Actions (login required)

Tétel nézet