Openstack és fizikai hálózati eszközök integrációja
Saved in:
| Main Author: | |
|---|---|
| Other Authors: | |
| Format: | Thesis |
| Kulcsszavak: | hálózat tervezése meghajtó ML2 openstack telekommunikáció |
| Online Access: | http://dolgozattar.uni-bge.hu/27243 |
MARC
| LEADER | 00000nta a2200000 i 4500 | ||
|---|---|---|---|
| 001 | dolg27243 | ||
| 005 | 20210329105436.0 | ||
| 008 | 201127suuuu hu om 000 hun d | ||
| 040 | |a BGE Dolgozattár Repozitórium |b hun | ||
| 041 | |a hu | ||
| 100 | 1 | |a Halmos Dávid | |
| 245 | 1 | 0 | |a Openstack és fizikai hálózati eszközök integrációja |c Halmos Dávid |h [elektronikus dokumentum] |
| 520 | 3 | |a Szakdolgozatom kezdetekben meghatározottcélja volt, hogy az olvasó átfogó képet kapjon az OpenStack projektről éskomponenseiről, valamint a DevStack fejlesztői környezet kialakításáról és azExtreme 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ó platformmegvaló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álasztottkomponensek és beállítások függvényében egészen komplex rendszerek kialakításárais alkalmas.Az OpenStack és az ML2 (Modular Layer 2)meghajtó megértéséhez, fontosnak tartottam szakirodalom alapján, rövidenjellemezni a virtualizáció és a felhőalapú számítástechnika legfontosabbfogalmait, típusait. Ezen kívül igyekeztem kifejteni a virtualizációhozszorosan kapcsolódó, hiperfelügyelő fogalmát. Az ezt követő részben rövidenbemutattam az Openstack, jelenlegidolgozatban is használt, főbb komponenseit. Többek között az autentikációértfelelős Keystonet, a képfájlok kezeléséért felelős Glancet, a virtuális gépekkezeléséért felelős Novát, valamint a hálózati szervizekért felelős Neutronkomponenst, amely a jelen fejlesztés részét képező meghajtó segítségévelkommunikál a külső fizikai hálózati eszközzel. Afejlesztés kezdeti lépéseként összegyűjtöttem az eszközök listáját, amelyekszükségesek a fejlesztői környezet kialakításához, valamint a fejlesztésimplementálásához:· Devstack: Egy szkript éssegédprogramkészlet, OpenStack felhő fejlesztői környezet gyors létrehozásátteszi lehetővővé, egyéni konfigurációs lehetőségekkel. Szakdolgozatomban amulti-node OpenStack telepítésére használtam fel. Részletesebben a 4.1fejezetben írtam róla.· Libvirt:Szoftvergyűjtemény, amely képes különböző virtuálizációs technológiákkezelésére, mint például háttértár, hálózati interfész. A virtuális gépek, hálózatoklétrehozására használtam a fejlesztői környezet kialakításakor. Részletesebbena 4.2 fejezetben írtam róla.· KVM:Hiperfelügyelő, amely képes kihasználni a processzorokban rejlő hardveresvirtualizációt megvalósító technológiát. Az OpenStacket futtató virtuális gépekegyes perifériáinak emulálását látja el. Bővebben a 4.3 fejezetben írtam róla.· QEMU: Processzorbővítményei KVM-mel kombinálva jelentősen megnövelik a virtuális gépekteljesítményét, emellett biztosít egy robusztus hiperfelügyelőt, amely a kernelszintjén fut. A fejlesztői környezetben a virtuális gépek egyes perifériáinakemulálását látja el. A tenant VM-ek virtualizációját a devstack automatikusanellátta, viszont a nodeokat(1 kontroller, 2 compute hoszt) és a Virtual EXOSVM-eket nekem kellett a virtuális képfájlból a virtuális gépet elindítani aQEMU segítségével. Bővebben a 4.4 fejezetben írtam róla.· EXOS SOAP: Az EXOS SOAPegy Extreme Networks által biztosított, python nyelven íródott programcsomag,amellyel a későbbiekben részletezett mechanizmus meghajtó képes a switchhelvaló kommunikációra. Az általam kifejlesztett ML2 Mechanizmus meghajtó ezt aprogramcsomagot 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 egyvirtuá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. Afejlesztés során ezt használtam devstack környezetben, annak érdekében, hogy avalós fizikai eszközt emuláljam. A Virtual EXOS virtuális gépet KVM-melindítottam el és a megfelelő konfiguráció eredménye képpen a devstack tudtahasználni, mint hálózati kapcsoló. Dolgozatom 4.6 fejzetében írtam rólarészletesebben.Ezek után megterveztem a fejlesztőikörnyezethez szükséges hálózati topológiát, valamint a kommunikációhozszükséges hálózati interfészeket. Az OpenStack szervizek futtatásához szükségesnodeok, 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, hosztokonfuttatott virtuális gépek forgalmához használt hálózat kialakítását linuxhálózati hidak létrehozásával oldottam meg, amelyek az exOS virtuális switchegy-egy portjához csatlakoznak – így biztosítottam, hogy a tenantok köztiforgalom a switchen menjen keresztül, szimulálva egy valós, fizikaikörnyezetet. Afejlesztő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ásoklétrehozására, virtuális gépek hosztolására, illetve indítására a computehosztokon- Két compute hoszt,amelyen az OpenStack worker szervizei futnak. Virtuális gépek hosztolásáraké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 futkeresztül.A 6. fejezetben a tényleges rendszerkonfigurációját és tesztelését mutatom be. Első lépésben ismertetem a szükségeshá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őenleteszteltem az OpenStack funkcióit – úgy mint képfájl, flavor (a virtuális gépszámítási, memória és tároló kapacitását tartalmazza) hálózat, port, virtuálisgépek létrehozása. Az OpenStack funkcióinak ellenőrzése után akülönböző hosztokon indított gépek között teszteltem a kommunikációt, ezáltalmeggyőződtem róla, hogy a forgalom valóban a switchen megy keresztül. A gépekkizárólag a switch konfigurálása után, az adott VLAN létrehozása, és portokhozzáadása után kaptak IP címet a DHCP kiszolgálótól, így ezen információ és továbbitesztek futtatásával sikerült megerősíteni, hogy sikerült a tervezett hálózatitopológiát megvalósítani. Ezt követően a 7. fejezetben ismertettem aNeutron ML2 beépülő modul működését, amely lehetővé teszi az OpenStackNetworking számára a 2. rétegbeli hálózati technológiák egyidejű felhasználásátaz adatközpontokban. Ez a modul különböző hálózat típusokat támogat – mintpéldául: flat, vlan, vxlan. Ezen hálózati típusokat bemutattam és sajátszerkeszté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 amechanizmus meghajtó által használható absztrakt metódusokat, amelyek valamelyhá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 aMechanismDriver 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 egyedimegoldásokat nyújtanak annak érdekében, hogy az általuk gyártott hardver képeslegyen a mechanizmus meghajtó által biztosított lehetőségeket kiaknázni, ésezáltal kiváltani a felhasználó által más esetben szükséges manuáliskonfigurációt.A 8. fejezet mutatja be a mechanizmus meghajtó implementálásánaklépéseit az Extreme EXOS switchekhez. Mivel az Extreme Switchekkel SOAPprotokollon keresztül kényelmesen lehet tranzakciókat megvalósítani, ezért énis ezt a protokollt választottam az implementációhoz. Ennek megfelelően részleteztema SOAP protokoll jellemzőit és képességeit, amelynek alapjaira épül az ExtremeSOAP interfész is. Az Extreme SOAP interfész képes a kommunikációhozelengedhetetlen munkamenetek kezelésére, a kéréseket tartalmazó XML fájloklétrehozására és a válaszok feldolgozására. Az XML kérések továbbításához HTTPprotokollra támaszkodik, az ennél szabányos kérés/válasz modellt használja.Ebben a fejezetben ismertettem továbbá a meghajtó Neutronbatörténő integrációjának lépéseit, valamint megterveztem és implementáltam egykonfigurációs sémát, amely a switchhel való kommunikációhoz szükségesadatokat és a portok térképéttartalmazza. 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 ésfeldolgozá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, VLANintervallum) a meghajtótól függetlenül működő konfigurációs szkript végzi. Azebből kiolvasott információk felhasználásával működik a következőkbenbemutatott meghajtóprogram.Azáltalam kifejlesztett ML2 mechanizmus meghajtó jelenleg a következő hálózati eseményekesetén képes a switch konfigurációjára:- VLAN típusú hálózatlétrehozása esetén felkonfigurálja a switchet a Neutron által kiosztottsegmentation_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 klaszterkontrolleren 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énfrissíti a switch konfigurációt- Virtuális gép törléseesetén törli a hoszt portját a konfigurációból, természetesen csak akkor, haezt más gép már nem használja- Hálózat törlése eseténeltávolítja az adott taggel rendelkező VLAN-t Amechanizmus meghajtó bemutatása és a tesztesetek kidolgozása után, részletesen dokumentáltama 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úlmutatnaka jelenlegi fejlesztésen, de elviekben lehetséges implementációjuk. Például:- Trunkportok támogatása, amely lehetővé teszi hálózati alagút megoldások támogatását- VXLANhálózat támogatása- Virtuálisrouter támogatása | |
| 695 | |a hálózat tervezése | ||
| 695 | |a meghajtó | ||
| 695 | |a ML2 | ||
| 695 | |a openstack | ||
| 695 | |a telekommunikáció | ||
| 700 | 1 | |a Gubán Dr. Ákos |e ths | |
| 856 | 4 | 0 | |u http://dolgozattar.uni-bge.hu/27243/1/Halmos_David_szakdolgozat_BMKUSO_1738.pdf |z Dokumentum-elérés |
| 856 | 4 | 0 | |u http://dolgozattar.uni-bge.hu/27243/2/BA_TO_Halmos_D%C3%A1vid_BMKUSO.pdf |z Dokumentum-elérés |