A felhőalapú számítástechnika egyre mélyebben beágyazódik életünkbe, és mára valószínű, hogy nincs olyan ember, aki legalább egyszer ne használta volna valamilyen felhőszolgáltatást. De vajon mit is jelent a felhő, és hogyan működik? A legtöbben nem tudják ezt még az alapötlet szintjén sem. Az 5G már valósággá válik, és a telekommunikációs infrastruktúra elkezdi átállni a hagyományos megoldásokról a felhőalapú megoldásokra, ahogyan annak idején a teljesen fizikai megoldásokról a virtualizált „oszlopokra”.
Ma a felhőinfrastruktúra belső világáról beszélünk, különösen a hálózati rész alapjait fogjuk körüljárni.
Mi az a felhő? Csak egyféle virtualizáció, ugye?
Ez egy teljesen logikus kérdés. Nem, ez nem virtualizáció, bár anélkül nem létezne. Két meghatározást fogunk megvizsgálni:
A felhőalapú számítástechnika (a továbbiakban Felhő) — olyan modell, amely lehetővé teszi a felhasználóbarát hozzáférést a megosztott számítási erőforrásokhoz, amelyeket igény szerint, minimális késleltetéssel és a szolgáltató számára a legkisebb költséggel kell telepíteni és üzemeltetni.
Virtualizáció — a lehetőség, hogy egy fizikai entitást (például egy szervert) több virtuálisra osszunk, ezáltal növelve a források kihasználtságát (például ha korábban 3 szerverünk volt 25-30 százalékos terheltséggel, a virtualizáció után 1 szerverünk 80-90 százalékos terheltséggel rendelkezik). Természetesen a virtualizáció elvon némi erőforrást — szükség van a hypervisor fenntartására, azonban a gyakorlat azt mutatja, hogy a befektetés megtérül. A virtualizáció tökéletes példája a VMWare, amely kiválóan készíti a virtuális gépeket, vagy például a KVM, amely számomra kedvesebb, de ez már egyéni ízlés kérdése.
Saját magunk sem vesszük észre, de már a fizikai routerek is használják a virtualizációt — például az utolsó JunOS verziókban az operációs rendszer egy virtuális gépként települ a real-time linux disztribúciójára (Wind River 9). De a virtualizáció nem a felhő, ám a felhő nem létezhet virtualizáció nélkül.
A virtualizáció egy olyan építőkocka, amelyre a felhő épül.
Az, hogy a felhőt egyszerűen néhány hipervizor egy L2 doménbe való összevonásával, néhány YAML playbook hozzáadásával a VLAN-ok automatikus beállításához valamilyen Ansible segítségével, és az egészre valami hasonló orchestrációs rendszert alkalmazva virtuális gépek automatikus létrehozásához - nem fog működni. Pontosabban fog működni, de az így kapott Frankenstein - nem az a felhő, amire szükségünk van, bár lehet, hogy valakinek ez az álma. Ráadásul, ha megnézzük az OpenStack-et - valójában egy másik Frankenstein, de ezt most hagyjuk.
De értem, hogy a fent bemutatott definícióból nem teljesen világos, hogy valójában mi nevezhető felhőnek.
Ezért a NIST (National Institute of Standards and Technology) dokumentuma öt alapvető jellemzőt sorol fel, amelyekkel a felhőinfrastruktúrának rendelkeznie kell:
Szolgáltatás igény szerint. A felhasználónak szabad hozzáférést kell kapnia a számára kijelölt számítástechnikai erőforrásokhoz (mint például hálózatok, virtuális lemezek, memória, processzormagok stb.), és ezeket az erőforrásokat automatikusan kell biztosítani - tehát a szolgáltató beavatkozása nélkül.
Széleskörű szolgáltatás hozzáférhetőség. Az erőforrásokhoz való hozzáférésnek standard mechanizmusok révén kell biztosítania a lehetőséget mind a standard PC-k, mind a vékony kliensek és mobil eszközök használatára.
Az erőforrások poolokba vonása. Az erőforrás pooloknak egyszerre kell biztosítaniuk erőforrásokat több kliens számára, biztosítva a kliensek elszigeteltségét, a kölcsönös hatások hiányát és a forrásokkal való versenyt. A poolokba beleértendők a hálózatok is, ami a keresztbevágott címzés lehetőségét jelzi. A pooloknak támogatniuk kell a kereslet szerinti skálázást. A poolok használata biztosítja az erőforrások szükséges szintű hibatűrését és a fizikai és virtuális erőforrások elabstrakcióját - a szolgáltatás igénybevevője egyszerűen megkapja a kért erőforrások együttesét (hogy ezek az erőforrások fizikailag hol helyezkednek el, hány szerveren és kapcsolón - a kliens számára nem lényeges). Azonban figyelembe kell venni, hogy a szolgáltatónak biztosítania kell az ezekre az erőforrásokra vonatkozó átlátható rezervációt.
Gyors alkalmazkodás a különböző körülményekhez. A szolgáltatásoknak rugalmasnak kell lenniük — gyors erőforrás-nyújtás, erőforrások átcsoportosítása, erőforrások hozzáadása vagy csökkentése a kliens kérésére, miközben a kliens részéről az az érzés alakul ki, hogy a felhő erőforrásai végtelenek. Az egyszerűség kedvéért, például nem tapasztalsz figyelmeztetést, ha az Apple iCloud-ból eltűnik egy résznyi tárolóhely, mert a szerveren elromlott a merevlemez, pedig a merevlemezek elromlanak. Ráadásul a te oldaladról ennek a szolgáltatásnak a lehetőségei gyakorlatilag határtalanok — szükséged van 2 TB-ra — nem probléma, csak fizess és megkapod. Hasonló példát hozhatunk a Google Drive-ra vagy a Yandex.Disk-re.
A nyújtott szolgáltatás mérhetősége. A felhő alapú rendszereknek automatikusan ellenőrizniük és optimalizálniuk kell a felhasználásra kerülő erőforrásokat, és ezeknek a mechanizmusoknak átláthatónak kell lenniük mind a felhasználó, mind a szolgáltató számára. Vagyis mindig ellenőrizheted, hogy mennyi erőforrást használsz te és az ügyfeleid.
Figyelembe kell venni, hogy ezek a követelmények többnyire a nyilvános felhőre vonatkoznak, így a privát felhőre (azaz a vállalat belső szükségleteire indított felhőre) ezek a követelmények némi módosítást igényelhetnek. Ennek ellenére a felhő számítási előnyeinek kihasználásához ezeket a követelményeket be kell tartani.
Miért van szükségünk a felhőre?
Mindazonáltal bármely új vagy már létező technológia, bármilyen új protokoll valamiért készül (kivéve nyilván a RIP-ng esetében). A protokoll a protokollért — senkinek sem kell (kivéve nyilván a RIP-ng esetében). Logikus, hogy a Felhőt azért hozzák létre, hogy valamilyen szolgáltatást nyújtson a felhasználónak/ügyfélnek. Mindannyian ismerünk legalább néhány felhőalapú szolgáltatást, például a Dropboxot vagy a Google.Docs-ot, és úgy vélem, hogy a legtöbben sikeresen használják őket — például ez a cikk a Google.Docs felhőalapú szolgáltatásának használatával készült. De a számunkra ismert felhőszolgáltatások csupán a felhő lehetőségeinek egy részét jelentik — pontosabban ez csak a SaaS típusú szolgáltatás. Felhőszolgáltatást három módon nyújthatunk: SaaS, PaaS vagy IaaS formájában. Az, hogy melyik szolgáltatásra van szükséged, függ a vágyaidtól és lehetőségeidtől.
Nézzük meg mindegyiket sorjában:
Szoftver mint Szolgáltatás (SaaS) — ez a modell teljeskörű szolgáltatásnyújtás például a Yandex.Mail vagy a Gmail levelezési szolgáltatás keretein belül. Ebben a szolgáltatásnyújtási modellben Ön, mint ügyfél, lényegében semmit sem csinál, csak használja a szolgáltatást — tehát nem kell foglalkoznia a szolgáltatás beállításával, a hibamentességével vagy a biztonsági másolatok készítésével. A legfontosabb, hogy ne kompromittálja a jelszavát, a többit a szolgáltató elintézi. A szolgáltató szempontjából — ő teljes mértékben felelős az egész szolgáltatásért — kezdve a szerverhardverektől és a host operációs rendszerektől, egészen az adatbázisok és szoftverek beállításáig.
Platform mint Szolgáltatás (PaaS) — ezen modell használatával a szolgáltató egy sablont kínál az ügyfél számára, például vegyük a Web kiszolgálót. A szolgáltató virtuális szervert biztosított az ügyfélnek (valójában egy erőforrás-összesség, mint például RAM/CPU/Tárolás/Hálózatok stb.), sőt még az operációs rendszert és a szükséges szoftvereket is telepítette erre a szerverre, azonban mindezt az ügyfél állítja be és ő felel a szolgáltatás működéséért. A szolgáltató, akárcsak az előző esetben, felelős a fizikai hardver, a hipervizorok, a virtuális gép és a hálózati hozzáférés működéséért stb., de a szolgáltatás már nem tartozik az ő felelősségi körébe.
Infrastruktúra mint Szolgáltatás (IaaS) — ez a megközelítés már izgalmasabb, valójában a szolgáltató teljes virtualizált infrastruktúrát biztosít az ügyfél számára — tehát egy erőforrás-összességet (pool), mint például CPU magok, RAM, Hálózatok stb. A többi már az ügyfél dolga — hogy mit szeretne kezdeni ezekkel az erőforrásokkal a számára fenntartott pool keretein belül (kvóta) — a szolgáltatónak nem különösebben fontos. Ha az ügyfél saját vEPC-t szeretne létrehozni, vagy akár mini szolgáltatót szeretne indítani, és távközlési szolgáltatásokat nyújtani — nem probléma — csinálja. Ilyen forgatókönyvben a szolgáltató felelős az erőforrások biztosításáért, azok hibamentességéért és elérhetőségéért, valamint az operációs rendszerért, amely lehetővé teszi az erőforrások egyesítését poolokká, és az ügyfél számára a források bármikor történő növelését vagy csökkentését igény szerint. Az összes virtuális gépet és egyéb beállításokat az ügyfél önállóan konfigurálja az önkiszolgáló portálon és a konzolon keresztül, beleértve a hálózatok definiálását is (kivéve a külső hálózatokat).
Mi az az OpenStack?
Mindhárom lehetőség esetén az szolgáltatónak szüksége van egy operációs rendszerre, amely lehetővé teszi a felhőinfrastruktúra létrehozását. A valóságban a SaaS esetén a teljes technológiai stackért nem egyetlen osztály felel — van egy osztály, amely az infrastruktúráért felelős — azaz IaaS-t biztosít egy másik osztálynak, amely SaaS-t biztosít az ügyfeleknek. Az OpenStack egy olyan felhő operációs rendszer, amely lehetővé teszi rengeteg kapcsoló, szerver és tárolórendszer összegyűjtését egy egységes erőforrás-poolban, ennek a közös poolnak az alpoolokra (tenantokra) való felosztását és ezen erőforrások ügyfeleknek történő biztosítását a hálózaton keresztül.
OpenStack — egy felhő operációs rendszer, amely lehetővé teszi a nagy számítási teljesítményű erőforrások, adattárolók és hálózati erőforrások kezelését, melyek provizionálása és kezelése API-n keresztül történik, standard hitelesítési mechanizmusok használatával.
Más szavakkal, ez egy szabad szoftverprojektek összessége, amely felhőszolgáltatások létrehozására szolgál (mind nyilvános, mind magántulajdonú) — azaz egy olyan eszközkészlet, amely lehetővé teszi a szerver- és kapcsolási berendezések egyesítését egy egységes erőforrás-poolban, ezen erőforrások kezelését, biztosítva a szükséges hibatűrési szintet.
A dokumentum írásának időpontjában az OpenStack struktúrája a következőképpen néz ki:
A kép forrása
Minden olyan összetevő, amely az OpenStack része, valamilyen konkrét funkciót lát el. Ez a megosztott architektúra lehetővé teszi, hogy az Ön által szükséges funkcionális összetevők mellett a megoldásba beépítsék azokat is. Azonban néhány összetevő alapvető összetevő, és eltávolításuk a megoldás teljes vagy részleges nem működéséhez vezet. Az ilyen alapvető összetevők közé sorolják:
- Mérőműsor — Web-alapú GUI az OpenStack szolgáltatások kezelésére
- Keystone — központosított azonosító szolgáltatás, amely hitelesítési és jogosultsági funkciókat biztosít más szolgáltatások számára, valamint kezeli a felhasználói fiókokat és szerepeiket.
- Neutron — hálózati szolgáltatás, amely összekapcsolja az OpenStack különböző szolgáltatásainak interfészeit (beleértve a VM és a külső világ közötti kapcsolatot is)
- Cinder — hozzáférést biztosít a blokkok tárolásához virtuális gépek számára
- Nova — a virtuális gépek életciklusának kezelése
- Glance — virtuális gépek és pillanatfelvételek képgyűjteménye
- Swift — hozzáférést biztosít az objektumtárolóhoz
- Ceilometer — szolgáltatás, amely lehetővé teszi a telemetria gyűjtését és a meglévő és fogyasztott erőforrások mérését
- Heat — sablon alapú automatikus erőforrás-előállítás és -provizionálás
Az összes projekt teljes listáját és célját megtekintheti .
Az OpenStack minden összetevője egyetlen szolgáltatás, amely egy adott funkcióért felelős, és API-t biztosít ennek a funkciónak a kezelésére és a szolgáltatás más felhőoperációs rendszerekkel való interakcióra. Például a Nova a számítási erőforrások kezelését és az ezekhez való hozzáférést biztosító API-t biztosít, a Glance az képek kezelését és a velük való műveletekhez szükséges API-t, a Cinder blokk-tárolási megoldás és az azt kezelő API stb. Mindezek a funkciók nagyon szoros összefüggésben állnak egymással.
Ha azonban jobban megnézzük, az OpenStack-ben futó összes szolgáltatás valójában végül is valamilyen virtuális gépet (vagy konténert) képvisel, amely csatlakozik a hálózatra. Felmerül a kérdés: miért van szükség ennyi elemre?
Nézzük át a virtuális gép létrehozásának és a hálózatra, valamint a tartós tárolóra való csatlakozásának algoritmusát az OpenStack-ben.
- Amikor létrehozási kérelmet nyújt be, legyen az kérelme a Horizon (Dashboard) felületen vagy CLI-n keresztül, az első dolog, ami történik — az a kérésének hitelesítése a Keystone által — tudja-e létrehozni a gépet, van-e joga használni azt a hálózatot, és elegendő-e a projektjéhez tartozó kvóta stb.
- A Keystone hitelesíti a kérését, és egy válaszüzenetben auth-token-t generál, amelyet később használnak. A Keystone-tól kapott válasz után a kérés átkerül a Nova (nova api) felé.
- A Nova-api ellenőrzi a kérés érvényességét, a Keystone-hoz fordulva, az előzőleg generált auth-token-t használva.
- A Keystone hitelesíti, és az auth-token alapján információt ad a jogosultságokról és korlátozásokról.
- A Nova-api bejegyzést hoz létre a nova-datában egy új VM-ről, és átadja a gép létrehozási kérését a nova-scheduler-nek.
- A Nova-scheduler kiválasztja a gazdagépet (számítógép csomópontot), amelyre a VM-et az adott paraméterek, súlyok és zónák alapján telepítik. Erről egy bejegyzés és a VM azonosítója rögzítésre kerül a nova adatbázisban.
- Ezután a nova-scheduler a nova-compute-hoz fordul az instance telepítésének kérésével. A nova-compute a nova-conductor-hoz fordul, hogy információt szerezzen a gép paramétereiről (a nova-conductor a nova része, amely proxy szerverként működik a nova-database és a nova-compute között, korlátozva ezzel a nova-database felé irányuló kérések számát, hogy elkerülje az adatbázis konzisztenciájával kapcsolatos problémákat és csökkentse a terhelést).
- A nova-conductor a nova-database-ből megszerzi a kért információt, majd továbbítja azt a nova-compute-nak.
- Ezután a nova-compute a glance-hoz fordul az image ID megszerzéséért. A glance érvényesíti a kérést a Keystone-ban, és visszaadja a kért információt.
- A nova-compute a neutronhoz fordul a hálózati paraméterek információjának megszerzéséért. Hasonlóan a glance-hoz, a neutron is érvényesíti a kérést a Keystone-ban, majd bejegyzést készít az adatbázisban (például port azonosító stb.), létrehozza a port létrehozására vonatkozó kérelmet, és visszaadja a kért információt a nova-compute-nak.
- A nova-compute a cinderhez fordul a virtuális gép számára volume kiosztásának kérésével. Hasonlóan a glance-hoz, a cinder érvényesíti a kérést a Keystone-ban, létrehozza a volume létrehozására vonatkozó kérelmet, és visszaadja a kért információt.
- A nova-compute a libvirt-hez fordul a virtuális gép telepítésének kérésével a megadott paraméterek alapján.
A seemingly simple operation of creating a straightforward virtual machine turns into a whirlwind of API calls between elements of the cloud platform. Moreover, as you can see, even the previously defined services consist of smaller components that interact with each other. Creating a machine is just a small part of what the cloud platform enables — there are services responsible for traffic balancing, services for block storage, services for DNS, services for provisioning bare metal servers, and so on. The cloud allows you to treat your virtual machines like a flock of sheep (unlike virtualization). If something happens to a machine in a virtual environment — you restore it from backups, etc., whereas cloud applications are designed in such a way that virtual machines do not play such a crucial role — if a virtual machine “dies” — no problem — just create a new machine based on a template, and, as they say, the team didn't notice the loss of a soldier. Naturally, this demands orchestration mechanisms — by using Heat templates, you can easily deploy a complex function composed of dozens of networks and virtual machines.
It’s always worth keeping in mind that there is no cloud infrastructure without a network — every element interacts with other elements through the network. Furthermore, the cloud has a completely non-static network. Naturally, the underlay network is more or less static — new nodes and switches are not added every day; however, the overlay component may and will inevitably change constantly — new networks will be added or deleted, new virtual machines will emerge, and old ones will die. And as you recall from the definition of the cloud provided at the very beginning of this article — resources should be allocated to users automatically and with minimal (preferably no) intervention from the service provider. The current type of resource provision in the form of a frontend, like your personal account accessed via http/https, and the on-call network engineer Vasily as the backend — this is not the cloud, even if Vasily has eight arms.
A Neutron, mint hálózati szolgáltatás, API-t biztosít a felhő infrastruktúra hálózati részének kezelésére. A szolgáltatás garantálja a hálózati rész működését és kezelését az OpenStackben, biztosítva egy absztrakciós szintet, amelyet Network-as-a-Service-nak (NaaS) neveznek. Tehát a hálózat egy olyan virtuális, mérhető egység, mint például a virtuális CPU magok vagy a RAM kapacitás.
De mielőtt áttérnénk az OpenStack hálózati részének architektúrájára, nézzük meg, hogyan működik ez a hálózat az OpenStackben, és miért fontos és elengedhetetlen része a felhőnek.
Tehát van két virtuális gépünk a RED ügyféltől és két virtuális gépünk a GREEN ügyféltől. Tegyük fel, hogy ezek a gépek két hypervizoron találhatóak az alábbi módon:
Jelenleg ez csak 4 szerver virtualizálása, semmi több, mivel eddig csak 4 szervert virtualizáltunk, amelyeket két fizikai szerveren helyeztünk el. Ráadásul eddig még nincsenek is hálózatra csatlakoztatva.
Ahhoz, hogy felhő legyen belőle, hozzá kell adnunk néhány komponenst. Először is virtualizáljuk a hálózati részt - ezeket a 4 gépet párba kell kötni, ráadásul az ügyfelek kifejezetten L2 kapcsolatot szeretnének. Használhatunk természetesen egy kapcsolót, és beállíthatunk egy trunkot a felé, valamint minden telepíthető linux bridge-t, vagy a haladóbb felhasználók számára openvswitch-ot (erre még visszatérünk). De sok hálózat lehet, és folyamatosan L2-t tolni a kapcsolón keresztül - nem a legjobb ötlet - mivel különböző osztályok, szervizdesk, hónapok várakozási ideje, hetek hibaelhárítás - a modern világban ez a megközelítés már nem működik. Minél előbb érti ezt meg a vállalat, annál könnyebb lesz előre haladnia. Ezért a hypervizorok között L3 hálózatot különítünk el, amin kommunikálnak a virtuális gépeink, majd erre a L3 hálózatra építjük a virtuális L2 (overlay) hálózatokat, ahol a virtuális gépeink forgalma kering. A kapszulázásra használhatunk GRE-t, Geneve-t vagy VxLAN-t. Egyelőre maradjunk az utolsónál, bár ez nem különösebben fontos.
Valahol el kell helyeznünk a VTEP-et (remélem, mindenki ismeri a VxLAN terminológiát). Mivel a szerverekből közvetlenül L3 hálózatunk van, semmi nem akadályozza meg, hogy a VTEP-et magukra a szerverekre helyezzük, ráadásul az OVS (OpenvSwitch) ezt rendkívül jól tudja kezelni. Ennek eredményeként kaptunk egy ilyen szerkezetet:
Mivel a forgalmat a VM-ek között szét kell választani, a virtuális gépek felé irányuló portok különböző VLAN számokat fognak kapni. A címke száma csak egy virtuális kapcsoló keretein belül játszik szerepet, mivel VxLAN-ba ágyazva ezt könnyedén eltávolíthatjuk, mivel lesz VNI-nk.
Most már problémák nélkül szaporíthatjuk a gépeinket és a virtuális hálózatokat számukra.
De mi van, ha az ügyfélnek van egy másik gépe, de egy másik hálózaton található? Szükségünk van routingra a hálózatok között. Megvizsgáljuk a legegyszerűbb esetet, amikor központosított routingot használunk — azaz a forgalom speciálisan kijelölt hálózati csomópontokon keresztül kerül irányításra (jellemzően ezek kombinálva vannak az irányító csomópontokkal, így ugyanazt az eredményt kapjuk).
Úgy tűnik, hogy nincs benne semmi bonyolult — hozunk létre egy bridge interfészt az irányító csomóponton, odavezetjük a forgalmat, és onnan irányítjuk, ahová szükség van. De a probléma az, hogy a RED ügyfél a 10.0.0.0/24 hálózatot szeretné használni, míg a GREEN ügyfél ugyanazt a 10.0.0.0/24 hálózatot kívánja használni. Tehát itt címterületek átfedése lép fel. Ráadásul az ügyfelek nem szeretnék, ha más ügyfelek irányíthatók lennének a belső hálózataikba, ami érthető. A hálózatok és az ügyfelek adatforgalmának szétválasztásához külön namespace-t rendelünk minden ügyfél számára. A namespace lényegében a Linux hálózati veremének egy másolata, így a RED namespace-ben lévő ügyfelek teljesen elszigetelődnek a GREEN namespace-ből származó ügyfelektől (vagy a hálózatok közötti routing engedélyezett a default namespace-en keresztül, vagy már a magasabb szintű szállító berendezésen).
Tehát ezt a sémát kapjuk:
Az L2 alagút minden számítási csomópontból a vezérlő csomópontra irányul, ahol az adott hálózatok számára L3 interfész található, mindegyik saját, elkülönített namespace-ben az elszigetelés érdekében.
Azonban elfelejtettük a legfontosabbat. A virtuális gépnek szolgáltatást kell nyújtania az ügyfél számára, azaz szükséges, hogy legalább egy külső interfésze legyen, amelyen keresztül elérhető. Ezért ki kell lépnünk a külvilágba. Itt különböző lehetőségek vannak. Csináljuk a legszimplább megoldást. Minden ügyfélnek adjunk egy hálózatot, amely érvényes a szolgáltató hálózatában, és nem ütközik más hálózatokkal. A hálózatok egymással is ütközhetnek, és különböző VRF-ekhez is tartozhatnak a szolgáltatói hálózat oldalán. Ezek a hálózatok szintén minden ügyfél namespace-ében fognak létezni. Azonban a külvilágra mindenképpen egy fizikális (vagy logikus, ami értelemszerűbb) interfészen keresztül lépnek ki. Az ügyfélforgalom elkülönítésére a kimenő forgalom VLAN tag-elést kap, amely az ügyfél számára van kijelölve.
Ennek eredményeképpen megkaptuk ezt a sémát:
Érthető kérdés, hogy miért ne telepítsük a gateway-eket magukra a compute node-okra? Ezzel nem nagyon lenne probléma, sőt, elosztott router (DVR) bekapcsolása esetén így is működni fog. Ebben a forgatókönyvben a legegyszerűbb megoldást vizsgáljuk, központosított gateway-jel, amely az Openstack alatt alapértelmezett. Nagy terhelésű funkciók esetén használnak majd elosztott routert, valamint gyorsító technológiákat, mint az SR-IOV és Passthrough, de mint mondják, ez már egy teljesen más történet. Először is nézzük meg az alapvető részét, majd térjünk át a részletekre.
Valójában a sémánk már működőképes, azonban van néhány árnyalat:
- Valahogy védenünk kell a gépeinket, azaz a switch interfészen az ügyfél felé szűrőt kell alkalmaznunk.
- Lehetővé kell tenni a virtuális gép automatikus IP címének megszerzését, hogy ne kelljen mindig konzolon belépni és beállítani a címet.
Kezdjük a gépek védelmével. Erre használhatjuk a banális iptables-t, miért ne.
Tehát most a topológiánk már egy kicsit bonyolultabbá vált:
Folytassuk. DHCP szervert kell hozzáadnunk. A legideálisabb hely a DHCP szerverek elhelyezésére minden ügyfélnél a fent említett kontroll node, ahol a namespace-ek találhatóak:
Van egy apró probléma. Mi van, ha minden újraindul, és az összes információ a DHCP címkölcsönzésről eltűnik? Logikus, hogy az eszközök új címeket fognak kapni, ami nem túl kényelmes. Két megoldás létezik: vagy használjunk domain neveket, és adjunk hozzá DNS szervert minden egyes klienshez, így számunkra a cím nem lesz túl fontos (a k8s hálózati része alapján) — de itt problémák merülhetnek fel a külső hálózatokkal, mivel ott is DHCP-n keresztül osztanak ki címeket — szükség van a felhőplatform DNS szervereinek és a külső DNS szervernek a szinkronizálására, ami szerintem nem túl rugalmas, de megvalósítható. A második lehetőség az, hogy metainformációkat használjunk — tehát megőrizzük az információt az adott gép címéről, hogy a DHCP szerver tudja, milyen cím adható a gépnek, ha már kapott címet. A második lehetőség egyszerűbb és rugalmasabb, mivel lehetővé teszi a gépről szóló további információk megőrzését. Most a séma hozzáad akármetadatügynököt:
Van egy másik kérdés is, amelyet érdemes megvilágítani — ez a lehetőség, hogy egy külső hálózatot minden ügyfél használjon, mivel a külső hálózatok, ha érvényesek kell legyenek az egész hálózaton, nehézséget okoznak — folyamatosan szét kell választanunk és ellenőriznünk kell ezeknek a hálózatoknak a kiosztását. Az összes ügyfél számára egy közös, előre konfigurált külső hálózat használata nagyon hasznos lenne a publikus felhő létrehozása során. Ez egyszerűsíti a gépek telepítését, mivel nem kell a címadatbázissal összehangolnunk és unikális címteret választanunk minden ügyfél külső hálózatához. Ezen kívül előre megadhatjuk a külső hálózatot, és a telepítés során csak annyit kell tennünk, hogy asszociáljuk a külső címeket az ügyfél gépeivel.
Itt jön segítségünkre a NAT – lehetővé tesszük, hogy az ügyfelek a default namespace-en keresztül lépjenek ki a külső világba NAT transzlációval. De van egy kis probléma. Ez jól működik, ha az ügyfélszerver kliensként működik, és nem szerverként – azaz kezdeményez, nem fogad kapcsolódásokat. De nálunk ennek az ellenkezője történik. Ebben az esetben destination NAT-ra van szükség, hogy a forgalom fogadó csomópontja tudja, hogy ez a forgalom az A ügyfél virtuális gépét célozza, így NAT transzlációt kell végezni egy külső címről, például 100.1.1.1 a belső címre 10.0.0.1. Ebben az esetben, bár minden ügyfél ugyanazt a hálózatot használja, a belső izoláció teljes mértékben megmarad. Ezért a kontroll csomóponton dNAT-ot és sNAT-ot kell alkalmaznunk. Az egyetlen hálózat, lebegő címek kiosztásával, külső hálózatok használatával, vagy akár mindkettő egyszerre, attól függ, hogy mit szeretne behúzni a felhőbe. Nem kívánjuk tovább bonyolítani a sémát lebegő címekkel, hanem a korábban hozzáadott külső hálózatokat hagyjuk meg – minden ügyfélnek saját külső hálózata van (a sémán VLAN 100 és 200 néven van feltüntetve a külső interfészen).
Ennek eredményeként egy érdekes és egyben átgondolt megoldást kaptunk, amely bizonyos rugalmassággal bír, de egyelőre nem rendelkezik a hibatűrő mechanizmusokkal.
Először is, csak egy kontroll csomópontunk van – ennek meghibásodása az összes rendszer összeomlásához vezet. E probléma megoldásához legalább három csomópontból álló kórus szükséges. Ezt hozzáadjuk a sémához:
Természetesen az összes csomópont szinkronizálódik, és ha az aktív csomópont kiesik, a feladatait egy másik csomópont átveszi.
A következő probléma a virtuális gépek lemezei. Jelenleg a hypervisorokon tárolódnak, és ha a hypervisorral probléma adódik, akkor minden adatunk elveszik — a RAID itt sem segít, ha nem egy lemezt, hanem az egész szervert veszítjük el. Ehhez szükségünk van egy szolgáltatásra, amely egy front-endként működik valamilyen tárolóhoz. Hogy milyen tároló lesz, az különösebben nem számít, de védenie kell az adatainkat a lemez és a csomópont, esetleg az egész rack meghibásodása ellen. Itt több lehetőség van — természetesen léteznek SAN hálózatok Fiber Channel-lel, de mondjuk ki őszintén — a FC már a múlté — analógja az E1-nek a szállításban — igen, elfogadom, hogy még használják, de csak ott, ahol nélküle nem lehet. Ezért önszántamból 2020-ban nem állnék neki FC hálózatot kiépíteni, tudva más, érdekesebb alternatívák létezéséről. Bár kinek-kinek a véleménye, és lehet, hogy lesznek olyanok, akik úgy gondolják, hogy a FC, minden korlátozásával együtt, éppen az, amire szükségünk van — nem fogok vitatkozni, mindenkinek megvan a saját véleménye. Azonban a számomra a legérdekesebb megoldás a SDS használata, például Ceph.
A Ceph lehetővé teszi a nagy rendelkezésre állású adatmegőrzési megoldások kiépítését, rengeteg lehetséges biztonsági megoldással, kezdve a paritásellenőrző kódokkal (analóg RAID 5 vagy 6) egészen a teljes adatreplikációig különböző lemezekre, figyelembe véve a lemezek elhelyezkedését a szervereken és a szerverek helyét a rackekben, és így tovább.
A Ceph összeszereléséhez további 3 csomóra van szükség. A tárolóval való interakció szintén a hálózaton keresztül történik, blokkolt, objektum- és fájltároló szolgáltatások használatával. Adjunk hozzá a tárolóhoz a sémához:
Megjegyzés: hiperkonvergált compute node-ok is létrehozhatók – ez a koncepció több funkció egy node-on történő összevonását jelenti – például tárolás + compute – azaz nem kell külön node-okat fenntartani a ceph tárolásnak. Így egy olyan hibatűrő sémát kapunk, amely képes a megadott tartósítással (SDS) eltárolni az adatokat. Azonban a hiperkonvergált node-ok mindig kompromisszummal járnak – mivel a tároló node nem csak „fűti a levegőt”, ahogy elsőre tűnhet (mivel nincs rajta virtuális gép) – CPU erőforrásokat használ az SDS fenntartására (valójában a háttérben végzi el a replikációkat, a node-ok, lemezek meghibásodása utáni helyreállítást stb.). Tehát részben elveszíted a compute node teljesítményét, ha ezt tárolóval kombinálod.
Ezeket a rendszereket valahogyan kezelni kell – szükség van egy eszközre, amin keresztül létrehozhatunk gépeket, hálózatokat, virtuális routereket stb. Ehhez a kontroll node-hoz hozzáadunk egy szolgáltatást, amely a dashboard szerepét tölti be – a kliens http/https protokollon keresztül hozzáférhet ehhez a portálhoz, és mindent megtehet, amire szüksége van (nem egészen mindent).
Végül most egy hibatűrő rendszer áll rendelkezésünkre. Minden elemét kezelni kell valahogyan. Korábban említettük, hogy az OpenStack egy projektgyűjtemény, amely minden egyes eleme egy konkrét funkciót biztosít. Ahogy láthatjuk, bőven vannak elemek, amelyeket konfigurálni és ellenőrizni kell. Ma a hálózati részeiről fogunk beszélni.
A Neutron architektúrája
Az OpenStack-ben a Neutron felelős a virtuális gépek portjainak csatlakoztatásáért a közös L2 hálózathoz, a forgalom irányításáért a különböző L2 hálózatokban található VM-ek között, valamint a külső irányításhoz, olyan szolgáltatások biztosításához, mint a NAT, Floating IP, DHCP stb.
A hálózati szolgáltatás működésének magas szintű leírása (alapvető rész) a következőképpen fogalmazható meg.
Virtuális gép indításakor a hálózati szolgáltatás:
- Portot hoz létre a virtuális gép számára (vagy portokat) és értesíti erről a DHCP szolgáltatást;
- Új virtuális hálózati eszköz jön létre (libvirt-en keresztül);
- A VM csatlakozik az első lépésben létrehozott portra (portokhoz);
Meghökkentő módon a Neutron működésének alapja olyan standard mechanizmusok, amelyeket mindenki ismer, aki valaha is belemerült a Linuxba – ezek a namespaces, iptables, linux bridges, openvswitch, conntrack stb.
Azonnal tisztázni kell, hogy a Neutron nem SDN irányító.
A Neutron több összefonódott komponensből áll:
Openstack-neutron-server — ez egy démon, amely az API-n keresztül dolgozik a felhasználói kérésekkel. Ez a démon nem foglalkozik hálózati kapcsolatok létrehozásával, hanem az ehhez szükséges információkat adja át a plugineknek, amelyek ezután beállítják a szükséges hálózati elemet. A Neutron-ügynökök az OpenStack csomópontjain regisztrálnak a Neutron szerveren.
A Neutron-szerver valójában egy Python-ban írt alkalmazás, amely két részből áll:
- REST szolgáltatás
- Neutron Plugin (core/service)
A REST szolgáltatás célja API-hívások fogadása a többi komponenstől (például információ kérés stb.).
A pluginek olyan csatlakoztatható szoftverkomponensek/modulok, amelyeket API-kéréseknél hívnak meg — azaz egy szolgáltatás hozzáadása ezek révén történik. A pluginek két típusra oszlanak — szolgáltatás és gyökér. Általában a gyökérplugin elsősorban a címkezelésért és az L2 kapcsolatokért felelős a VM között, míg a szolgáltatás pluginek további funkciókat biztosítanak, például VPN-t vagy FW-t.
A jelenleg elérhető pluginek listáját például itt lehet megtekinteni.
Szolgáltatás pluginek száma lehet több, de a gyökérpluginból csak egy létezhet.
Openstack-neutron-ml2 — ez az OpenStack alapértelmezett gyökérpluginja. Ez a plugin moduláris architektúrával rendelkezik (ellentétben elődjével), és az ahhoz csatlakozó driverekkel konfigurálja a hálózati szolgáltatást. Magát a plugint később tárgyaljuk, mivel valójában ő biztosítja azt a rugalmasságot, amellyel az OpenStack a hálózati részén rendelkezik. A gyökérplugint lehet cserélni (például a Contrail Networking ilyet végez).
RPC szolgáltatás (rabbitmq-server) — egy szolgáltatás, amely a sorok kezelését és az OpenStack más szolgáltatásaival való interakciót biztosít, valamint a hálózati szolgáltatás ügynökeivel való interakciót.
Hálózati ügynökök — ügynökök, amelyek minden csomóponton találhatók, és ezeken keresztül valósul meg a hálózati szolgáltatások konfigurálása.
Az ügynökök többféle lehet.
A fő ügynök — ez a L2 ügynök. Ezek az ügynökök minden hipervizoron, beleértve a vezérlő csomópontokat is (pontosabban minden csomóponton, amely valamilyen szolgáltatást nyújt a bérlőknek), futnak, és fő funkciójuk a virtuális gépek csatlakoztatása a közös L2 hálózathoz, valamint figyelmeztetések generálása különböző események bekövetkeztekor (például port kikapcsolásakor/bekapcsolásakor).
A következő, nem kevésbé fontos ügynök a L3 ügynök. Alapértelmezés szerint ez az ügynök kizárólag a hálózati csomóponton fut (a hálózati csomópont gyakran egybeesik a vezérlő csomóponttal), és biztosítja a bérlők közötti hálózatok közötti irányítást (mind a saját hálózatai és más bérlők hálózatai között, mind a külvilág felé NAT-ot és DHCP szolgáltatást biztosítva). Azonban, ha DVR-t (elágaztatott routert) használnak, az L3 bővítmény szükségessé válik a számítási csomópontokon is.
Az L3 ügynök Linux névtér használatával biztosítja, hogy minden bérlő saját elszigetelt hálózatainak és virtuális routerének halmazába férjen hozzá, amelyek irányítják a forgalmat és átjáró szolgáltatásokat nyújtanak a Layer 2 hálózatokhoz.
Adatbázis — azonosítók, alhálózatok, portok, tart poolok stb. adatbázisa.
A Neutron valójában API kéréseket fogad el bármilyen hálózati entitás létrehozására, hitelesíti a kérést, és RPC-n (ha valamilyen bővítményhez vagy ügynökhöz fordul) vagy REST API-n (ha SDN-ben kommunikál) keresztül adja át az ügynököknek (a bővítményeken keresztül) azokat az utasításokat, amelyek szükségesek a kért szolgáltatás megszervezéséhez.
Most térjünk át a teszt telepítésre (hogy hogyan van felállítva és mi található benne, azt később a gyakorlati részben megnézzük), és nézzük meg, hol helyezkedik el milyen komponens:
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 
Valójában ez az egész Neutron struktúrája. Most érdemes egy kis időt szánni az ML2 pluginra.
Moduláris 2. réteg
Ahogy azt már említettük, a plugin az OpenStack szabványos alap pluginja, moduláris architektúrával rendelkezik.
Az ML2 plugin elődjének monolitikus felépítése miatt nem volt lehetséges például több technológia egyetlen telepítésben való használata. Például nem lehetett egyszerre openvswitch és linuxbridge - csak az egyik vagy a másik. Ezért jött létre az ML2 plugin a maga architektúrájával.
Az ML2 két összetevőből áll - két típusú driverből: Típusú driverek és Mechanizmus driverek.
Típusú driverek meghatározzák azokat a technológiákat, amelyek a hálózati kapcsolatok létrehozásához lesznek használva, például VxLAN, VLAN, GRE. Ezen túlmenően a driver lehetővé teszi a különböző technológiák használatát. A standard technológia a VxLAN kapszulázás overlay hálózatokhoz és a VLAN külső hálózatok számára.
A Típusú driverek a következő hálózat típusokat tartalmazzák:
Lap — címkézetlen hálózat
VLAN — címkézett hálózat
Helyi — különleges hálózati típus all-in-one jellegű telepítésekhez (ilyen telepítések szükségesek vagy fejlesztőknek, vagy oktatáshoz)
GRE — overlay hálózat, amely GRE alagutakat használ
VxLAN — overlay hálózat, amely VxLAN alagutakat használ
Mechanizmus driverek meghatározzák azokat az eszközöket, amelyek biztosítják a type driver által megadott technológiákat — például openvswitch, sr-iov, opendaylight, OVN stb.
A driver implementációjától függően vagy Neutron által vezérelt ügynököket használnak, vagy kapcsolatokat létesítenek egy külső SDN vezérlővel, amely átveszi az L2 hálózatok, a forgalomirányítás stb. megszervezésével kapcsolatos kérdéseket.
Például, ha ML2-t használunk OVS-sel, akkor minden számítási nodén L2 ügynököt telepítenek, amely az OVS-t kezeli. Azonban, ha például OVN-t vagy OpenDayLight-ot használunk, akkor az OVS kezelése az ő jogkörük alá kerül — a Neutron a gyökér pluginon keresztül utasítja a vezérlőt, és ő végrehajtja az utasításait.
Frissítsük fel a memóriánkban az Open vSwitch-t
Jelenleg az OpenStack egyik kulcsfontosságú összetevője az Open vSwitch.
OpenStack telepítésekor, anélkül, hogy bármilyen további gyártói SDN, például a Juniper Contrail vagy a Nokia Nuage jelen lenne, az OVS a felhőhálózat fő hálózati összetevője, és az iptables, conntrack, namespaces párosával teljes értékű overlay hálózatokat biztosít több bérlő számára. Természetesen ez az összetevő helyettesíthető, például harmadik féltől származó, szabadalmaztatott (gyártói) SDN megoldások használatakor.
Az OVS egy nyílt forráskódú szoftver váltó, amelyet virtualizált környezetekben használnak, mint virtuális forgalomirányító.
Jelenleg az OVS nagyon tisztességes funkcionalitással bír, beleértve olyan technológiákat, mint QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK stb.
Megjegyzés: kezdetben az OVS-t nem úgy tervezték, mint szoftveres váltót nagy terhelésű távközlési funkciókhoz, hanem inkább az alacsonyabb sávszélesség-igénnyel rendelkező IT funkciók, például WEB szerver vagy levelezőszerver számára. Azonban az OVS javítva van, és a jelenlegi OVS implementációk jelentősen javították a teljesítményét és lehetőségeit, ami lehetővé teszi, hogy távközlési szolgáltatók nagy terhelésű funkciókkal használják; például van egy DPDK gyorsítást támogató OVS implementáció.
Három fontos OVS összetevő létezik, amelyeket tudni kell:
- Kernel modul — a kernel térben elhelyezkedő összetevő, amely a vezérlőegységtől kapott szabályok alapján végzi a forgalom feldolgozását;
- vSwitch A daemon (ovs-vswitchd) is a process running in user space that is responsible for programming the kernel module, meaning it directly embodies the logic of the switch's operation.
- Adatbázis szerver — a helyi adatbázis, amely minden olyan hoston található, ahol az OVS fut, és ahol a konfiguráció tárolódik. Ezen a modulon keresztül SDN vezérlők kommunikálhatnak OVSDB protokollal.
Ehhez egy diagnosztikai és vezérlőeszközökből álló készlet is tartozik, mint például ovs-vsctl, ovs-appctl, ovs-ofctl stb.
Jelenleg az OpenStacket széles körben használják telekommunikációs szolgáltatók a hálózati funkciók, például az EPC, SBC, HLR migrálására. Egyes funkciók problémamentesen működhetnek az OVS-sel úgy, ahogy van, de például az EPC a felhasználók forgalmát kezeli — tehát óriási mennyiségű forgalmat bocsát át (jelenleg a forgalom volumene több száz gigabit per másodperc). Természetesen nem a legjobb ötlet, hogy ilyen forgalmat jelenítsenek meg kernel space-en (mivel alapértelmezetten a forgalomirányító ott található). Ezért gyakran az OVS-t teljesen user space-en telepítik a DPDK gyorsítási technológia használatával, hogy a forgalmat a NIC-jel közvetlenül a user space-be vezethessék, megkerülve a kernel-t.
Megjegyzés: a telekommunikációs funkciókhoz telepített felhő esetén lehetőség van a forgalom kimenetének megvalósítására a compute node-ból, megkerülve az OVS-t, közvetlenül a kapcsoló berendezésbe. Ehhez az SR-IOV és a Passthrough mechanizmusokat használják.
Hogyan működik ez egy valós maketten?
Most áttérünk a gyakorlati részre, és megnézzük, hogyan működik ez mind a gyakorlatban.
Először is telepítünk egy egyszerű OpenStack példányt. Mivel nincs kéznél egy szervercsomag a kísérletezéshez, ezért egy fizikai szerveren virutális gépekből építjük fel a makettet. Igen, természetesen ilyen megoldás kereskedelmi célokra nem alkalmas, de hogy megfigyelhessük, hogyan működik a hálózat az OpenStack-en, ez a telepítés elegendő. Egyébként ez a telepítés a tanulás számára még érdekesebb — mivel lehetőség adódik a forgalom megfigyelésére stb.
Mivel csak az alap részét szeretnénk meglátni, nem szükséges több hálózatot használnunk, elegendő két hálózatot felállítanunk, ráadásul a második hálózat ebben a maketten kizárólag az undercloud és a DNS szerverhez való hozzáférésre fog szolgálni. A külső hálózatokkal egyelőre nem foglalkozunk — ez külön téma lenne egy nagyobb cikkhez.
Tehát, kezdjük a legelején. Először egy kis elmélet. Az OpenStacket a TripleO segítségével telepítjük (OpenStack az OpenStacken). A TripleO lényege, hogy az OpenStacket all-in-one módban (vagyis egy node-ra) telepítjük, amelyet undercloud-nak hívunk, majd az elindított OpenStack képességeit felhasználva telepítjük az üzemeltetésre szánt OpenStacket, amelyet overcloud-nak nevezünk. Az undercloud a fizikai szerverek (bare metal) kezelésére képes — az Ironic projekt — a hypervisorok provisioningjához fogja használni, amelyek a compute, control és storage node-okat fogják ellátni. Vagyis nem használunk harmadik fél eszközeit az OpenStack telepítéséhez — az OpenStack segítségével telepítjük az OpenStacket. A telepítés során sokkal világosabbá válik, ezért nem állunk meg itt, és haladjunk tovább.
Megjegyzés: A cikk egyszerűsítése érdekében nem használtam hálózati izolációt az OpenStack belső hálózatainak érdekében, minden telepítés csak egy hálózat használatával történt. Azonban a hálózatok izolációjának megléte vagy hiánya nem befolyásolja a megoldás alapvető funkcionalitását — mindez pontosan úgy fog működni, mint az izoláció használatakor, de a forgalom egyetlen hálózaton fog áthaladni. Természetesen kereskedelmi telepítés esetén szükséges különböző VLAN-ok és interfészek használatával izolációt alkalmazni. Például a Ceph tároló kezelésére szolgáló forgalom és a tényleges adatok (gépek diskekhez való hozzáférése stb.) izolációja különböző alhálózatokat használ (Storage management és Storage), és ez lehetővé teszi a megoldás hibamentességének javítását a forgalom például különböző portokon való szétválasztásával, vagy különböző QoS profilok használatával a különböző forgalmak számára, hogy az adatforgalom ne nyomja el a jelzési forgalmat. A mi esetünkben viszont mindez egy hálózaton fog áthaladni, és ez számunkra nem korlátoz minket.
Megjegyzés: Mivel virtuális gépeket fogunk futtatni egy virtuális környezetben, amely virtuális gépeken alapul, először engedélyeznünk kell a nested virtualizációt.
A nested virtualizáció engedélyezésének ellenőrzéséről így tájékozódhatunk:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ha N betűt lát, aktiválja a nested virtualizáció támogatását bármilyen útmutató szerint, amelyet az interneten talál, például .
Olyan diagramot kell összeállítanunk, mint az alábbi:
Az én esetemben a virtuális gépek összekapcsolásához, amelyek a jövőbeli telepítés részét képezik (összesen 7 darabot sikerült létrehoznom, de 4-el is elboldogulhat, ha nem áll rendelkezésére sok erőforrás), OpenvSwitch-t használtam. Készítettem egy ovs hidat, és csatlakoztattam hozzá a virtuális gépeket port-csoportokon keresztül. Ehhez az alábbi struktúrájú xml fájlt hoztam létre:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67Itt három portcsoportot deklarálunk — két access-t és egy trunk-ot (az utóbbi a DNS szerverhez szükséges, de el lehet lenni nélküle is, vagy futtathatja a gazdagépen — ahogy önnek kényelmesebb). Ezek után a megadott sablon segítségével definiáljuk a hálózatot a virsh net-define paranccsal:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Most módosítjuk a hipervizor portjainak konfigurációit:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Megjegyzés: az adott forgatókönyvben az ovs-br1 port címe nem lesz elérhető, mivel nincs VLAN címkéje. Ezt a problémát a sudo ovs-vsctl set port ovs-br1 tag=100 parancs kiadásával lehet orvosolni. Azonban a rendszer újraindítása után ez a címke eltűnik (ha valaki tudja, hogyan lehetne ezt megőrizni — nagyon hálás lennék). De ez nem annyira fontos, mivel erre a címre csak a telepítés ideje alatt van szükség, és amikor az OpenStack teljesen telepítve van, már nem lesz rá szükség.
Ezután létrehozzuk az undercloud gépet:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Az telepítés során állítsa be az összes szükséges paramétert, mint például a gép nevét, jelszavakat, felhasználókat, NTP szervereket stb. A portokat is azonnal beállíthatja, de számomra személy szerint egyszerűbb, ha telepítés után lépek be a gépbe a konzolon és igazítom a szükséges fájlokat. Ha már van kész képe, azt használhatja, vagy teheti, mint én — letölteni a minimalis CentOS 7 képet és azt használni a VM telepítéséhez.
A sikeres telepítés után virtuális gépnek kell megjelennie, amelyre telepíthető az undercloud.
[root@hp-gen9 bormoglotx]# virsh list
Id Név Állapot
----------------------------------------------------
6 dns-server működik
62 undercloud működikElőször telepítjük a telepítéshez szükséges eszközöket:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud telepítése
Hozzunk létre egy stack felhasználót, állítsunk be jelszót, adjuk hozzá a sudoer-hez, és adjuk meg neki a lehetőséget, hogy root parancsokat hajtson végre a sudo-n keresztül jelszó megadása nélkül:
useradd stack
passwd stack
echo "stack ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackMost a hosts fájlban adjuk meg az undercloud teljes nevét:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Ezután adjuk hozzá a tárolókat és telepítsük a szükséges szoftvert:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleMegjegyzés: ha nem tervezel ceph-et telepíteni, akkor a ceph-re vonatkozó parancsokat nem kell beírni. Én a Queens kiadást használtam, de bármely más kiadást használhatsz, ami tetszik.
Ezután másoljuk át az undercloud konfigurációs fájlt a stack felhasználó otthoni könyvtárába:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confMost szükséges módosítani ezt a fájlt, hogy az összeállításunkhoz passzoljon.
A fájl elejére szükséges hozzáadni az alábbi sorokat:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Tehát nézzük végig a beállításokat:
undercloud_hostname — az undercloud szerver teljes neve, amelynek meg kell egyeznie a DNS szerveren lévő bejegyzéssel
local_ip — helyi cím undercloud a provisioning hálózat felé
network_gateway — ugyanaz a helyi cím, amely átjáróként szolgál a külső világ felé az overcloud node-ok telepítésekor, szintén megegyezik a local ip-vel
undercloud_public_host — a külső API címe, bármely szabad cím a provisioning hálózatból kijelölhető
undercloud_admin_host a belső API címe, bármely szabad cím a provisioning hálózatból kijelölhető
undercloud_nameservers — DNS szerver
generate_service_certificate — ez a sor nagyon fontos a jelen példában, mivel ha nem állítja false értékre, telepítési hibát kap, a probléma leírva a Red Hat hibakövetőben
local_interface interfész a provisioning hálózatban. Ez az interfész újrakonfigurálva lesz az undercloud telepítése alatt, ezért az undercloud-nak két interfésszel kell rendelkeznie — egy a hozzáféréshez, egy a provisioning-hoz
local_mtu — MTU. Mivel tesztlaboratóriumunk van, és az MTU 1500 az OVS kapcsoló portjain, 1450 értékre kell beállítani, hogy az VxLAN csomagok megfelelően átmenjenek
network_cidr — provisioning hálózat
masquerade — NAT használata a külső hálózathoz való hozzáféréshez
masquerade_network — a NAT-olt hálózat
dhcp_start — a címkiosztási tartomány kezdő címe, ahonnan a node-oknak címet fognak kiosztani az overcloud telepítése alatt
dhcp_end — a címkiosztási tartomány végső címe, ahonnan a node-oknak címet fognak kiosztani az overcloud telepítése alatt
inspection_iprange — a szükséges cím tartomány introspekcióhoz (nem szabad átfedéseket mutatnia a fent megnevezett tartománnyal)
scheduler_max_attempts — az overcloud telepítési kísérletek maximális számát, amelynek nagyobbnak vagy egyenlőnek kell lennie a node-ok számával
Miután a fájl le van írva, parancsot adhat az undercloud telepítésére:
openstack undercloud install
A folyamat 10-30 percet vehet igénybe a hardverétől függően. Végső soron ilyen kimenetet kell látnia:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud telepítés befejeződött.
A telepítéshez használt jelszavakat tartalmazó fájl itt található:
/home/stack/undercloud-passwords.conf.
Van egy stackrc fájl is a következő helyen: /home/stack/stackrc.
Ezekre a fájlokra szükség van az OpenStack szolgáltatásokkal való interakcióhoz, és biztonságban kell őket tartani.
#############################################################################Ez a kimenet azt jelzi, hogy sikeresen telepítette az undercloud-t, és most ellenőrizheti az állapotát, majd folytathatja az overcloud telepítését.
Ha megnézi az ifconfig kimenetét, láthatja, hogy egy új bridge interfész jelent meg
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163 mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Ezen az interfészen keresztül fog zajlani az overcloud telepítése.
Az alábbi kimenetből látható, hogy az összes szolgáltatás egy csomóponton található:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Az alábbiakban bemutatjuk az undercloud hálózati konfigurációját:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Overcloud telepítése
Jelenleg csak undercloudunk van, és hiányoznak a csomópontok, amelyekből az overcloud összegyűlhet. Ezért először telepítjük a szükséges virtuális gépeket. Az undercloud telepítése során automatikusan telepíti az operációs rendszert és a szükséges szoftvereket az overcloud gépekre — tehát nem kell teljesen telepítenünk a gépet, csak létre kell hoznunk számukra egy (vagy több) lemezt, és meg kell határoznunk a paramétereit — lényegében egy üres szervert kapunk operációs rendszer nélkül.
Lépjünk be a virtuális gépeink lemezeinek mappájába, és hozzuk létre a szükséges méretű lemezeket:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GMivel rootként járunk el, meg kell változtatnunk ezeknek a lemezeknek a tulajdonosát, hogy elkerüljük a jogosultsági problémákat:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu \/var\/lib\/libvirt\/images\/*.qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Megjegyzés: Ha nem tervezed a Ceph telepítését tanulmányozási céllal, akkor legalább három csomópontot kell létrehoznod, minimum két lemezzel, a sablonban pedig jelöld meg, hogy virtuális lemezeket, például vda, vdb stb. fogsz használni.
Remek, most már az összes gépet definiálnunk kell:
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > \/tmp\/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > \/tmp\/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > \/tmp\/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > \/tmp\/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > \/tmp\/compute-2.xml A végén ott van a parancs —print-xml > \/tmp\/storage-1.xml, amely létrehoz egy XML fájlt, amely minden gép leírását tartalmazza a \/tmp\/ mappában. Ha ezt nem adod hozzá, nem tudod definiálni a virtuális gépeket.
Most már az összes gépet a virsh-ben kell definiálnunk:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name Állapot
----------------------------------------------------
6 dns-server fut
64 undercloud fut
- compute-1 leállítva
- compute-2 leállítva
- control-1 leállítva
- storage-1 leállítva
- storage-2 leállítva
[root@hp-gen9 ~]#Most egy kis részlet — a tripleO IPMI-t használ a szerverek kezelésére az installáció és introspekció során.
Az introspekció a hardver elemek átvizsgálásának folyamata a további node provisioninghoz szükséges paraméterek megszerzésére. Az introspekció az ironic segítségével történik — egy szolgáltatás, amely bare metal szerverekkel dolgozik.
De itt van a probléma — míg a fizikai szervereknél az IPMI egy külön port (vagy megosztott port, de ez nem lényeges), a virtuális gépeknek nincsenek ilyen portjaik. Itt jön a segítségünkre a vbmc nevű megoldás — egy eszköz, amely lehetővé teszi az IPMI port emulálását. Ezt a részletet különösen figyelembe kell venni azoknak, akik labort szeretnének felállítani ESXi hypervisoron — őszintén szólva, nem tudom, hogy van-e hozzá hasonló vbmc az ESXi-ben, ezért érdemes előre foglalkozni ezzel a kérdéssel, mielőtt mindent beállítanak.
Telepítsük a vbmc-t:
yum install python2-virtualbmcHa az operációs rendszer nem találja a csomagot, akkor adja hozzá a repository-t:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmMost konfiguráljuk az eszközt. Itt minden rendkívül egyszerű. Jelenleg logikus, hogy a vbmc listájában nincsenek szerverek.
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Ahhoz, hogy megjelenjenek, kézzel kell őket bejelenteni az alábbiak szerint:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | leállítva | :: | 7004 |
| compute-2 | leállítva | :: | 7005 |
| control-1 | leállítva | :: | 7001 |
| storage-1 | leállítva | :: | 7002 |
| storage-2 | leállítva | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Azt hiszem, a parancs szintaxisa világos anélkül is, hogy magyarázni kellene. Azonban egyelőre minden session leállított állapotban van. Ahhoz, hogy átváltsanak UP állapotba, be kell őket kapcsolni:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Elindítva a vBMC példány a control-1 domainhez
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Elindítva a vBMC példány a storage-1 domainhez
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Elindítva a vBMC példány a storage-2 domainhez
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Elindítva a vBMC példány a compute-1 domainhez
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Elindítva a vBMC példány a compute-2 domainhez
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain név | Állapot | Cím | Port |
+-------------+---------+---------+------+
| compute-1 | fut | :: | 7004 |
| compute-2 | fut | :: | 7005 |
| control-1 | fut | :: | 7001 |
| storage-1 | fut | :: | 7002 |
| storage-2 | fut | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Az utolsó simítás — ki kell javítani a tűzfal szabályait (vagy teljesen ki kell kapcsolni):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Most lépjünk be az undercloudba és ellenőrizzük, hogy minden működik. A gazdagép címe — 192.168.255.200, az undercloudon a szükséges ipmitool csomagot hozzáadtuk a telepítés előkészítése során:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
A házkészülék áramellátása ki van kapcsolva
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
A házkészülék áramellátása: Fenn/Be
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Név Állapot
----------------------------------------------------
6 dns-server fut
64 undercloud fut
65 control-1 futAhogy látjátok, sikeresen elindítottuk a control csomópontot a vbmc segítségével. Most kapcsoljuk ki és menjünk tovább:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
A házkészülék áramellátása: Lehangolt/Ki
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
A házkészülék áramellátása ki van kapcsolva
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Név Állapot
----------------------------------------------------
6 dns-server fut
64 undercloud fut
- compute-1 kikapcsolva
- compute-2 kikapcsolva
- control-1 kikapcsolva
- storage-1 kikapcsolva
- storage-2 kikapcsolva
[root@hp-gen9 ~]#A következő lépés a csomópontok introspektálása, amelyekre az overcloudot telepítjük. Ehhez elő kell készítenünk egy json fájlt a csomópontjaink leírásával. Vegye figyelembe, hogy a natív szerverekre történő telepítéshez képest a fájl tartalmazza a portot, amelyen a vbmc minden gépen fut.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Megjegyzés: a vezérlő csomóponton két interfész található, de ebben az esetben ez nem fontos, a jelenlegi telepítéshez elegendő egy is.
Most készítjük el a json fájlt. Meg kell adnunk a port MAC-címét, amelyen a provisioning végrehajtásra kerül, a csomópont paramétereit, nevüket, és meg kell határoznunk, hogy hogyan lehet hozzáférni az ipmi-hez:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Most fel kell készülnünk az ironic képek előkészítésére. Ehhez letöltjük őket wget segítségével és telepítjük őket:
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$Képeket töltünk fel az undercloud-ba:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
A "overcloud-full-vmlinuz" kép sikeresen feltöltve.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Név | Lemezformátum | Méret | Állapot |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | aktív |
+--------------------------------------+------------------------+-------------+---------+--------+
A "overcloud-full-initrd" kép sikeresen feltöltve.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Név | Lemezformátum | Méret | Állapot |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | aktív |
+--------------------------------------+-----------------------+-------------+----------+--------+
A "overcloud-full" kép sikeresen feltöltve.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Név | Lemezformátum | Méret | Állapot |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | aktív |
+--------------------------------------+----------------+-------------+------------+--------+
A "bm-deploy-kernel" kép sikeresen feltöltve.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Név | Lemezformátum | Méret | Állapot |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | aktív |
+--------------------------------------+------------------+-------------+---------+--------+
A "bm-deploy-ramdisk" kép sikeresen feltöltve.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Név | Lemezformátum | Méret | Állapot |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | aktív |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Ellenőrizzük, hogy minden kép sikeresen feltöltődött.
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Név | Állapot |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aktív |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | aktív |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | aktív |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | aktív |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktív |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Még egy lépés — hozzá kell adni a dns szervert:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Név | Hálózat | Alhálózat |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Mező | Érték |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | Igaz |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI elavult és a jövőben eltávolításra kerül. Használja az openstack CLI-t helyette.
Frissített alhálózat: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Most parancsot adhatunk az introspekcióra:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Elindult a Mistral munkafolyamat: tripleo.baremetal.v1.register_or_update. Végrehajtási azonosító: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Várakozás a 'tripleo' soron érkező üzenetekre időkorlát nélkül.
5 csomópont sikeresen áthelyezve a "kezelhető" állapotba.
Sikeresen regisztrálva lett a csomópont UUID-ja: b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Sikeresen regisztrálva lett a csomópont UUID-ja: b89a72a3-6bb7-429a-93bc-48393d225838
Sikeresen regisztrálva lett a csomópont UUID-ja: 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Sikeresen regisztrálva lett a csomópont UUID-ja: bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Sikeresen regisztrálva lett a csomópont UUID-ja: 766ab623-464c-423d-a529-d9afb69d1167
Várakozás az introspekció befejezésére...
Elindult a Mistral munkafolyamat: tripleo.baremetal.v1.introspect. Végrehajtási azonosító: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Várakozás a 'tripleo' soron érkező üzenetekre időkorlát nélkül.
Az b89a72a3-6bb7-429a-93bc-48393d225838 csomópont introspekciója befejeződött. Áállapot: SIKERES. Hibák: Nincs
A 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e csomópont introspekciója befejeződött. Áállapot: SIKERES. Hibák: Nincs
A bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 csomópont introspekciója befejeződött. Áállapot: SIKERES. Hibák: Nincs
A 766ab623-464c-423d-a529-d9afb69d1167 csomópont introspekciója befejeződött. Áállapot: SIKERES. Hibák: Nincs
A b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 csomópont introspekciója befejeződött. Áállapot: SIKERES. Hibák: Nincs
Sikeresen introspektálva: 5 csomópont.
Elindult a Mistral munkafolyamat: tripleo.baremetal.v1.provide. Végrehajtási azonosító: f5594736-edcf-4927-a8a0-2a7bf806a59a
Várakozás a 'tripleo' soron érkező üzenetekre időkorlát nélkül.
5 csomópont sikeresen áthelyezve a "elérhető" állapotba.
(undercloud) [stack@undercloud ~]$Ahogy a kimenetből látható, minden hiba nélkül zárult. Ellenőrizzük, hogy minden csomópont elérhető állapotban van:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Név | Példány UUID | Áramellátás | Telepítési állapot | Karbantartás |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | ki | elérhető | Hamis |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | ki | elérhető | Hamis |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | ki | elérhető | Hamis |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | ki | elérhető | Hamis |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | ki | elérhető | Hamis |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Ha a csomópontok más állapotban vannak, például ha kezelhetőek, akkor valami probléma történt, és ellenőrizni kell a naplókat, hogy megtudjuk, miért történt ez. Ne feledje, hogy ebben a forgatókönyvben virtualizációt használunk, ami esetleg hibákhoz vezethet virtuális gépek vagy vbmc használatával.
Továbbá meg kell határoznunk, hogy melyik csomópont milyen funkciót fog ellátni — ezáltal segítve a csomópont profiljának megadását a telepítéshez:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Megadjuk a profilokat minden egyes nodhoz:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Ellenőrizzük, hogy mindent helyesen csináltunk:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Ha minden rendben van, adjuk ki a parancsot az overcloud telepítésére:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuValódi telepítés során természetesen testreszabott sablonokat használnak, de a mi esetünkben ez nagyon megnehezítené a folyamatot, mivel minden módosítást el kellene magyarázni a sablonban. Ahogy korábban említettem — a legegyszerűbb telepítés is elegendő lesz ahhoz, hogy lássuk, hogyan működik.
Megjegyzés: a --libvirt-type qemu változó ebben az esetben szükséges, mivel beágyazott virtualizációt fogunk használni. Ellenkező esetben nem tudja elindítani a virtuális gépeket.
Most körülbelül egy órája van, vagy talán több (a hardver lehetőségeitől függően), és remélni kell, hogy az idő letelte után ezt a feliratot fogja látni:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE successfully completed
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 nem található a /home/stack/.ssh/known_hosts fájlban
Megkezdődött a Mistral Workflow tripleo.deployment.v1.get_horizon_url. Végrehajtási azonosító: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud végpont: http://192.168.255.21:5000/
Overcloud Horizon irányítópult URL: http://192.168.255.21:80/dashboard
Overcloud rc fájl: /home/stack/overcloudrc
Overcloud telepítve
(undercloud) [stack@undercloud ~]$Most van egy majdnem teljes verziója az OpenStacknak, amelyen tanulhat, kísérletezhet stb.
Ellenőrizzük, hogy minden rendben működik-e. A stack felhasználó otthoni könyvtárában két fájl található — az egyik a stackrc (az undercloud kezeléséhez), a másik az overcloudrc (az overcloud kezeléséhez). Ezeket a fájlokat forrásként kell megadni, mivel az autentikációhoz szükséges információkat tartalmazzák.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$A telepítésemhez még egy apró részlet szükséges – egy útvonal hozzáadása a vezérlőn, mivel a gép, amiről dolgozom, másik hálózatban van. Ehhez be kell lépnünk a control-1-re a heat-admin fiókkal, és be kell állítanunk az útvonalat.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Utolsó bejelentkezés: 2020. augusztus 14. 09:47:40 192.168.255.1-ről
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Most már beléphet a horizontba. Minden információ — címek, felhasználónév és jelszó — a /home/stack/overcloudrc fájlban található. A végső séma a következőképpen néz ki:
Egyébként a mi telepítésünkben a gépek címeit DHCP-n keresztül osztották ki, és ahogy látja, ezek 'véletlenszerűen' kerülnek kiosztásra. A sablonban megadhatja, hogy melyik cím melyik géphez legyen rendelve a telepítés során, ha ez szükséges.
Hogyan áramlik a forgalom a virtuális gépek között?
Ebben a cikkben három lehetőséget fogunk megvizsgálni a forgalom átáramlására.
- Két gép egy hypervisoron belül, egy L2 hálózaton.
- Két gép különböző hypervisorokon, egy L2 hálózaton.
- Két gép különböző hálózatokban (routing a hálózatok között).
A külső világgal való kapcsolatok esetén, a floating címek használatával és a megosztott routinggal foglalkozunk legközelebb, addig is maradjunk a belső forgalomnál.
Ellenőrzés céljából összeállítjuk az alábbi sémát:
Négy virtuális gépet hoztunk létre — hármat egy L2 hálózaton (net-1), és egyet a net-2 hálózaton.
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Név | Tenant ID | Állapot | Feladat állapot | Teljesítmény állapot | Hálózatok |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | AKTÍV | - | Futtatás | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | AKTÍV | - | Futtatás | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | AKTÍV | - | Futtatás | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | AKTÍV | - | Futtatás | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Nézzük meg, hogy mely hypervisorokon találhatók a létrehozott gépek:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 | (overcloud) [stack@undercloud ~]$
A vm-1 és vm-3 a compute-0-n van, a vm-2 és vm-4 pedig a compute-1-en található.
Ezen kívül létrehoztunk egy virtuális routert a megadott hálózatok közötti irányítás érdekében:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ A routernek két virtuális portja van, amelyek a hálózatok számára kapuként működnek:
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ De mielőtt megnéznénk, hogyan mozog a forgalom, nézzük át, hogy jelenleg mit látunk az irányító noden (ami egyben a network node is) és a compute noden. Kezdjük a compute nodal.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Jelenleg a csomóponton három ovs híd van: br-int, br-tun, br-ex. Közöttük, ahogy látjuk, van egy sor interfész. Az egyszerűbb felfogás kedvéért ábrázoljuk ezeket az interfészeket egy diagramon és megnézzük, mit kapunk.
A VxLAN alagutak IP-címeit nézve látható, hogy az egyik alagút a compute-1-en (192.168.255.26) van, a másik pedig a control-1-re (192.168.255.15) mutat. Ami a legérdekesebb, hogy a br-ex-nek nincsenek fizikai interfészei, és ha megnézzük, milyen flow-k vannak beállítva, látható, hogy ez a híd jelenleg csak forgalmat tud blokkolni.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163 mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Látható a kimenetből, hogy az IP közvetlenül a fizikai portra van kötve, nem pedig egy virtuális híd interfészre.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ Az első szabály szerint minden, ami a phy-br-ex porton érkezik, el kell veszni.
Ez a híd jelenleg egyetlen forrástól sem kaphat forgalmat, csak a megadott interfészről (csatlakozás a br-int-hez), és a hídba érkező dropok alapján már érkezett BUM forgalom.
Ez azt jelenti, hogy erről a csomópontból a forgalom csak VxLAN alagúton keresztül távozhat, más módon nem. Ha azonban engedélyezzük a DVR-t, a helyzet megváltozik, de ezzel egy másik alkalommal foglalkozunk. Hálózati izoláció alkalmazásakor, például VLAN-ok segítségével, nem egy L3 interfész lesz a 0-ás VLAN-ban, hanem több interfész. Ugyanakkor a VxLAN forgalom ugyanúgy fog kimenni a csomópontból, de beágyazva is egy elkülönített VLAN-ba.
A compute csomóponttal végeztünk, lépjünk a control csomópontra.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (belső)
eth0 1/2: (rendszer)
phy-br-ex 2/nincs: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (belső)
int-br-ex 1/nincs: (patch: peer=phy-br-ex)
patch-tun 2/nincs: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (belső)
patch-int 1/nincs: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Valójában elmondható, hogy minden ugyanaz, azonban az IP-cím már nem a fizikai interfészen, hanem a virtuális hídon található. Ezt azért tettük, mert ez a port az a port, amelyen a forgalom a külső világ felé távozik.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Ez a port a br-ex hídhoz van kötve, és mivel nincsenek VLAN címkék, ezért ez a port egy trunk port, amelyen minden VLAN engedélyezve van, a forgalom jelenleg címke nélkül távozik, amit a fenti kimenet VLAN-id 0-ja jelez.
Minden egyéb jelenleg hasonló a compute csomóponthoz — ugyanazok a hidak, ugyanazok a csatornák, amelyek két compute csomópontra vezetnek.
A tárolócsomópontokat nem tárgyaljuk ebben a cikkben, de a megértéshez fontos megemlíteni, hogy ezeknek a csomópontoknak a hálózati része rendkívül egyszerű. Az esetünkben csupán egy fizikai port (eth0) található, amelyhez egy IP-cím van hozzárendelve, és ennyi. Nincsenek VxLAN alagút, alagúthíd stb. — az OVS-nek semmilyen szerepe nincs, mert ennek nincs értelme. Hálózati izoláció használata esetén ezeken a csomópontokon két interfész lesz (fizikai portok, bodok vagy egyszerűen két VLAN — ez lényegtelen — attól függ, mit szeretne) — egy a management számára, a másik a forgalom számára (VM lemezre írás, lemezről olvasás stb.).
Most, hogy áttekintettük a csomópontokon található szolgáltatások nélküli állapotot, indítsunk el 4 virtuális gépet, és nézzük meg, hogyan alakul a fent leírt séma — meg kell, hogy jelenjenek portok, virtuális routerek stb.
Jelenleg a hálózatunk így néz ki:
Két-két virtuális gép található minden számítógép csomóponton. A compute-0 példáján keresztül nézzük meg, hogyan van minden bekapcsolva.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Név Állapot
----------------------------------------------------
1 instance-00000001 fut
3 instance-00000003 fut
[heat-admin@overcloud-novacompute-0 ~]$ A gépnek csupán egy virtuális interfésze van — tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interfész Típus Forrás Modell MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Ez az interfész a linux bridge-re mutat:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge név bridge id STP engedélyezve interfészek
docker0 8000.0242904c92a8 nem
qbr5bd37136-47 8000.5e4e05841423 nem qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 nem qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Amint az a híd kimenetéből látható, összesen két interfész található — tap95d96a75-a0 és qvb95d96a75-a0.
Itt érdemes egy pillanatra megállni és beszélni az OpenStack virtuális hálózati eszközeiről:
vtap — virtuális interfész, amely egy példányhoz (VM) csatlakozik
qbr — Linux híd
qvb és qvo — vEth pár, amely a Linux hídhoz és az Open vSwitch hídhoz csatlakozik
br-int, br-tun, br-vlan — Open vSwitch hidak
patch-, int-br-, phy-br- — Open vSwitch patch interfészek, amelyek a hidakat összekötik
qg, qr, ha, fg, sg — Open vSwitch portok, amelyeket virtuális eszközök használnak az OVS-hez való csatlakozáshoz
Ahogy látjuk, ha a brídgen van egy qvb95d96a75-a0 port, amely egy vEth pár, akkor logikusan van egy párja is, amelyet qvo95d96a75-a0-nak kell hívni. Nézzük meg, milyen portok vannak az OVS-en.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Ahogy látjuk, a port a br-int-en található. A br-int szerepe a virtuális gépek portjainak terminálja. A qvo95d96a75-a0 mellett a qvo5bd37136-47 port is látható a kimenetben. Ez a port a második virtuális géphez tartozik. Tehát a sémánk most így néz ki:
A kérdés, amely azonnal felkelteti a figyelmes olvasó érdeklődését — miért van Linux híd a virtuális gép portja és az OVS portja között? Az a helyzet, hogy a gép védelmére használt security groupok nem mások, mint az iptables. Az OVS nem működik az iptables-szal, ezért találták ki ezt a „megoldást”. Azonban ez már elavult — helyére a conntrack lép az újabb verziókban.
Tehát végül a séma így néz ki:
Két gép egy hypervisoron belül, egy L2 hálózaton.
Mivel ezek a VM-ek ugyanazon L2 hálózaton és ugyanazon hypervizoron vannak, a forgalom közöttük logikusan helyben fog áthaladni a br-int-en, mivel mindkét gép ugyanabban a VLAN-ban lesz:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Két gép különböző hypervisorokon, egy L2 hálózaton.
Most nézzük meg, hogyan fog áramlani a forgalom a két gép között egyazon L2 hálózaton, de különböző hypervizorokon elhelyezkedve. Ha őszinték akarunk lenni, akkor nagyon nem fog változni semmi, egyszerűen a forgalom a hypervizorok között egy vxlan alagúton fog terjedni. Nézzük meg egy példán keresztül.
A virtuális gépek címei, amelyeket figyelni fogunk forgalom szempontjából:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interfész Típus Forrás Modell MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Típus Forrás Modell MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Nézzük meg a br-int forwarding tábláját a compute-0-n:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]A forgalom a 2-es portra megy — nézzük meg, mi ez a port:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Ez a patch-tun — azaz a br-tun interfész. Nézzük meg, mi történik a csomaggal a br-tun-on:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ A csomag VxLAN-ba csomagolva és a 2-es portra küldve. Nézzük meg, hová vezet a 2-es port:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Ez a vxlan alagút a compute-1-en:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Menjünk a compute-1-re, és nézzük meg, mi történik tovább a csomaggal:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ A MAC címe megtalálható a br-int forwarding táblájában a compute-1-en, és mint az előző kimenetből látható, a 2-es porton keresztül látható a br-tun irányába:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Most nézzük meg, hogy a compute-1 br-int táblájában van-e a címzett MAC:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Ez azt jelenti, hogy a kapott csomag a 3-as portra kerül, ahonnan már a virtuális gép instance-00000003 található.
Az Openstack telepítésének minden szépsége abban rejlik, hogy a virtuális infrastruktúrában problémamentesen tudjuk nyomon követni a forgalmat a hypervisorok között, és megnézni, mi történik vele. Ezt most meg fogjuk tenni, tcpdump-ot indítunk a vnet porton a compute-0 felé:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: figyelés a vnet3-on, linktípus EN10MB (Ethernet), rögzítési méret 262144 bájt
*****************kibővítve*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), hossz 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), hossz 84)
10.0.1.85 > 10.0.1.88: ICMP echo kérés, id 5634, seq 16, hossz 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), hossz 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), hossz 84)
10.0.1.88 > 10.0.1.85: ICMP echo válasz, id 5634, seq 16, hossz 64
*****************kibővítve*******************Az első sor azt mutatja, hogy a 10.0.1.85 címről érkező csomag a 10.0.1.88 cím felé halad (ICMP forgalom), amely be van csomagolva egy VxLAN csomagba a 22-es vni-vel, és a csomag a 192.168.255.19 (compute-0) gépről a 192.168.255.26 (compute-1) gépre megy. Ellenőrizhetjük, hogy a VNI megfelel annak, ami az ovs-ben van megadva.
Térjünk vissza erre a sorra: actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 — ez a vni hexadecimális számrendszerben. Fordítsuk át ezt a számot decimálisra:
16 = 6*16^0+1*16^1 = 6+16 = 22Tehát a vni a valóságnak megfelel.
A második sor a visszafelé haladó forgalmat mutatja, aminek a magyarázata nem szükséges, ott már minden világos.
Két gép különböző hálózatokban (irányítás a hálózatok között)
A mai utolsó eset a hálózatok közötti irányítás egy projekten belül virtuális útválasztóval. Az esetet DVR nélkül vizsgáljuk (arról másik cikkben lesz szó), ezért az irányítás a network noden történik. Az esetünkben a network node nem került külön entitásba, és az control node-on helyezkedik el.
Először nézzük meg, hogy működik az irányítás:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bájt a 10.0.2.8-ból: seq=0 ttl=63 time=7.727 ms
64 bájt a 10.0.2.8-ból: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statisztikák ---
2 csomag küldve, 2 csomag fogadva, 0% csomagveszteség
körút minimum/átlag/máximál = 3.832/5.779/7.727 msMivel ebben az esetben a csomagnak a gateway-re kell mennie, és ott kell irányítania, tudnunk kell a gateway MAC címét, ezért megnézzük az ARP táblázatot az instance-ban:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Most examined, where the traffic with destination (10.0.1.254) fa:16:3e:c4:64:70 should be sent.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Looking at where port 2 leads:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ It's clear, the traffic goes to br-tun. Let's see which vxlan tunnel it will be wrapped in:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ The third port is a vxlan tunnel:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Which is connected to the control node:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ The traffic reached the control node, so we need to switch to it and see how routing will occur.
As you may remember, the control node inside looked exactly like the compute node — the same three bridges, only br-ex had a physical port through which the node could send traffic outside. The creation of instances altered the configuration on the compute nodes — new linux bridges, iptables, and interfaces were added to the nodes. Creating networks and a virtual router also left its mark on the control node's configuration.
So, it is obvious that the MAC address of the gateway should be in the forwarding table of br-int on the control node. Let's check if it is there and where it points:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ The MAC is visible from port qr-0c52b15f-8f. If we go back to the list of virtual ports in Openstack, this type of port is used to connect various virtual devices to OVS. To be more precise, qr is the port towards the virtual router, which is presented as a namespace.
Let's see what namespaces exist on the server:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Összesen három példány. De a nevek alapján kitalálható, hogy mindegyik milyen célt szolgál. Az 0 és 1 azonosítójú példányokkal később foglalkozunk, most a qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe névtér érdekel minket.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Ebben a névtérben két belső interfész található, amelyeket korábban hoztunk létre. Mindkét virtuális port hozzá lett adva a br-int-hez. Ellenőrizzük a qr-0c52b15f-8f port MAC-címét, mivel a forgalom, a cél MAC-cím alapján, pontosan erre az interfészre érkezett.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163 mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Ez azt jelenti, hogy jelen esetben minden a szokásos útválasztási szabályok szerint működik. Mivel a forgalom a 10.0.2.8 hosztra irányul, a második qr-92fa49b5-54 interfészen keresztül kell kiállnia, és a VXLAN alagúton át a compute Node-ba kell távoznia.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Minden logikus, nincsenek meglepetések. Nézzük meg, honnan látszik a 10.0.2.8 hoszt MAC-címe a br-int-en.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Ahogy kell, a forgalom a br-tun-ra megy, nézzük meg, hogy melyik alagútba megy tovább a forgalom:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ A forgalom a compute-1 felé halad a alagúton. A compute-1-nél minden egyszerű — a br-tun-ból érkező csomag a br-int-be kerül, ahonnan a virtuális gép interfészére jut:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Ellenőrizzük, hogy ez valóban a megfelelő interfész:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$ Valójában végigkövettük a csomag útját. Gondolom, észrevették, hogy a forgalom különböző vxlan alagútakon keresztül haladt és különböző VNI-kkal jött ki. Nézzük meg, hogy ezek a VNI-k milyenek, majd rögzítünk egy dumpot a vezérlő csomóponton, és meggyőződünk arról, hogy a forgalom valóban úgy halad, ahogyan fent leírtuk.
Tehát az alagút a compute-0-hoz a következő actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Konvertáljuk a 0x16-ot decimális számrendszerbe:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Az alagút a compute-1-hez a következő VNI-t tartalmazza: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Konvertáljuk a 0x63-at decimális számrendszerbe:
0x63 = 3*16^0+6*16^1 = 3+96 = 99És most nézzük meg a dumpot:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Az első csomag egy vxlan csomag a 192.168.255.19 (compute-0) hosztól a 192.168.255.15 (control-1) hosztra vni 22-vel, amelyben egy ICMP csomag található a 10.0.1.85 hoszttól a 10.0.2.8 hosztra. Ahogyan fentebb számoltuk, a vni megfelel annak, amit a kimeneten láttunk.
A második csomag egy vxlan csomag a 192.168.255.15 (control-1) hosztól a 192.168.255.26 (compute-1) hosztra vni 99-vel, amelyben egy ICMP csomag is található a 10.0.1.85 hoszttól a 10.0.2.8 hosztra. Ahogyan fentebb számoltuk, a vni megfelel annak, amit a kimeneten láttunk.
A következő két csomag a visszafele irányuló forgalom a 10.0.2.8-tól a 10.0.1.85-ig.
Tehát végül így néz ki a control node diagramunk:
Úgy tűnik, hogy minden rendben? Elfelejtettük a két névtérrel foglalkozni:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Ahogyan a felhőplatform architektúrájáról beszéltünk - jó lenne, ha az eszközök automatikusan IP-címeket kapnának a DHCP szervertől. Ez a két DHCP szerver a mi két hálózatunkhoz: 10.0.1.0/24 és 10.0.2.0/24.
Ellenőrizzük, hogy ez így van-e. Ebben a névtérben csak egy cím található - 10.0.1.1 - a DHCP szerver címe, és ez is benne van a br-int-ben:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163 mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Nézzük meg, hogy vannak-e folyamatok, amelyek tartalmazzák a nevükben a qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2-t a vezérlőn:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Van egy ilyen folyamat, és az előző kimenetben bemutatott információk alapján megnézhetjük, hogy jelenleg mi van bérelve:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Ennek eredményeként egy ilyen szolgáltatáscsomagot kapunk a vezérlőn:
Ne feledkezz el arról, hogy mindez csupán négy gépből, két belső hálózatból és egy virtuális routerből áll… Jelenleg nincsenek külső hálózatok, rengeteg különböző projekt, mindegyik saját hálózattal (amelyek átfedésben vannak), és a terjesztett router ki van kapcsolva – igazából a tesztkörnyezetben csak egy control node volt (megbízhatóság szempontjából három node kórusára van szükség). Logikus, hogy a kereskedelemben minden „egy kicsit” bonyolultabb, de ezen az egyszerű példán megértjük, hogyan kellene működnie – legyen három vagy 300 namespace, természetesen fontos, de a teljes konstrukció működése szempontjából nem különösebben változik semmi… igaz, amíg nem kapcsolsz be valamilyen gyártói SDN-t. De ez már egy teljesen másik történet.
Remélem, érdekes volt. Ha bármilyen észrevételed van, vagy ha valahol nyilvánvalóan tévedtem (én is ember vagyok, és a véleményem mindig szubjektív lesz) – írd meg, mit kellene javítani vagy hozzáadni – mindent megoldunk.
A végén szeretnék pár szót szólni az Openstack (mind a védett, mind a gyártói verziókkal) és a VMWare felhőmegoldása közötti összehasonlításról – az utóbbi években sokan feltették nekem ezt a kérdést, és már őszintén szólva belefáradtam, de mégis. Szerintem ez a két megoldás nehezen összehasonlítható, de határozottan elmondható, hogy mindkettőnek vannak hátrányai, és amikor egy megoldást választasz, mindent mérlegelni kell.
Míg az OpenStack közösség által vezérelt megoldás, a VMWare-nak joga van csak azt tenni, amit akar (olvassuk – amit számára hasznot hoz), és ez logikus – mivel ez egy kereskedelmi vállalat, amely hozzászokott a pénzkereséshez az ügyfelein. De itt van egy nagy és vaskos DE – bármikor eltávolodhatsz az OpenStacktől, például a Nokia révén, és könnyedén átmehetsz a Juniper (Contrail Cloud) megoldására, de a VMWare-ről nehezen fogsz tudni távozni. Számomra ez a két megoldás úgy néz ki – az Openstack (gyártói) egy egyszerű ketrec, amelybe bezárnak, de van kulcsod, és bármikor kijöhetsz. A VMWare aranyketrec, a kulcs a gazdánál van, és nagyon drágán fog kerülni.
Nem buzdítok egyik termék mellett sem — Ön választja, ami szükséges. De ha ilyen választás elé állnék, mindkét megoldást választanám — VMWare az IT felhőhöz (kis terhelések, kényelmes irányítás), OpenStack egy gyártótól (Nokia és Juniper nagyon jó kulcsrakész megoldásokat kínálnak) — a Telekom felhőhöz. Az OpenStack-et nem használnám tiszta IT számára — olyan, mint puskával veréb célba venni, de ellenjavallatokat nem látok, kivéve a túlnyereséget. Azonban a VMWare használata telekommunikációban — olyan, mint köveket szállítani egy Ford Raptorral — szépnek tűnik, de a vezetőnek 10 utat kell megtennie egy helyett.
Szerintem a VMWare legnagyobb hátránya a teljes bezártsága — a cég nem ad ki semmilyen információt arról, hogy például hogyan működik a vSAN vagy mi van a hipervizor magjában — ez egyszerűen nem jövedelmező számukra — tehát soha nem válhat szakértővé a VMWare terén — a gyártói támogatás nélkül Ön rendszerszerűen kudarcra van ítélve (nagyon gyakran találkozom VMWare szakértőkkel, akiket egyszerű kérdések gátolnak meg). Számomra a VMWare olyan, mint egy autó vásárlása, amelynek motorházteteje zárva van — igen, lehet, hogy vannak szakemberei, akik ki tudják cserélni a vezérműszíjat, de a motorháztetőt csak az tudja kinyitni, aki eladta Önnek ezt a megoldást. Személy szerint nem szeretem azokat a megoldásokat, ahová nem tudok belekukkantani. Ön azt mondja, lehet, hogy nem kell majd belenyúlnia a motorháztető alá. Igen, ez lehetséges, de nézni fogom, amikor egy nagy funkciót kell felépítenie a felhőben 20-30 virtuális gépből, 40-50 hálózatból, amelynek fele ki akar menni, másik fele pedig SR-IOV gyorsítást kér, különben még néhány tucat ilyen gépre szüksége lesz — különben nem lesz elegendő a teljesítmény.
Vannak más nézőpontok is, ezért csak Ön dönti el, mit választ, és a legfontosabb — Önnek kell felelnie a választásáért. Ez csupán a véleményem — egy olyan emberé, aki legalább 4 terméket látott és tapintott — Nokia, Juniper, Red Hat és VMWare. Tehát van mivel összehasonlítani.
Forrás: habr.com
