A felhőalapú számítástechnika egyre mélyebbre hatol az életünkbe, és valószínűleg nincs olyan ember, aki ne használt volna legalább egyszer semmilyen felhőszolgáltatást. Azt azonban, hogy mi is pontosan a felhő, és hogyan működik, kevesen tudják, még ötlet szintjén is. Az 5G már valósággá válik, és a távközlési infrastruktúra a pole-megoldásoktól a felhőmegoldások felé kezd elmozdulni, akárcsak akkor, amikor a teljesen hardveres megoldásokról a virtualizált „pillérek” felé mozdult el.
Ma a felhő infrastruktúra belső világáról fogunk beszélni, különös tekintettel a hálózati rész alapjaira.
Mi az a felhő? Ugyanaz a virtualizáció - profilnézet?
Több mint logikus kérdés. Nem – ez nem virtualizáció, bár enélkül nem is lehetne. Nézzünk két definíciót:
Cloud computing (a továbbiakban: felhő) egy olyan modell, amely felhasználóbarát hozzáférést biztosít az elosztott számítási erőforrásokhoz, amelyeket igény szerint kell telepíteni és elindítani a lehető legalacsonyabb késleltetéssel és minimális költséggel a szolgáltató számára.
Virtualizáció - ez az a lehetőség, hogy egy fizikai entitást (például egy szervert) több virtuálisra osztunk, ezzel növeljük az erőforrások kihasználtságát (például 3 szerverünk volt 25-30 százalékos terheléssel, virtualizáció után 1 szerver töltődik be 80-90 százalékon). Természetesen a virtualizáció felemészti az erőforrások egy részét - meg kell táplálnia a hipervizort, de a gyakorlat szerint a játék megéri a gyertyát. Ideális példa a virtualizációra a virtuális gépeket tökéletesen előkészítő VMWare, vagy például a KVM, amit én preferálok, de ez ízlés dolga.
A virtualizációt anélkül használjuk, hogy észrevennénk, és már a vas útválasztók is használják a virtualizációt – például a JunOS legújabb verziójában az operációs rendszer virtuális gépként van telepítve egy valós idejű Linux disztribúció (Wind River 9) tetejére. De a virtualizáció nem a felhő, hanem a felhő nem létezhet virtualizáció nélkül.
A virtualizáció az egyik építőelem, amelyre a felhő épül.
Felhő létrehozása egyszerűen több hypervisor összegyűjtésével egy L2 tartományba, néhány yaml-játékkönyv hozzáadásával a vlan-ek automatikus regisztrálásához valamilyen lehetséges eszközön keresztül, és valami hangszerelési rendszert belezavarva az egészbe a virtuális gépek automatikus létrehozása érdekében. Pontosabb lesz, de az eredményül kapott Frankenstein nem az a felhő, amelyre szükségünk van, bár lehet, hogy mások számára ez a végső álom. Sőt, ha ugyanazt az Openstacket vesszük, akkor az lényegében még mindig Frankenstein, de na jó, erről most ne beszéljünk.
De megértem, hogy a fent bemutatott definícióból nem teljesen világos, mit nevezhetünk valójában felhőnek.
Ezért a NIST (Nemzeti Szabványügyi és Technológiai Intézet) dokumentuma 5 fő jellemzőt tartalmaz, amelyekkel egy felhő infrastruktúrának rendelkeznie kell:
Igény szerint szolgáltatást nyújtunk. A felhasználó számára ingyenes hozzáférést kell biztosítani a számára kiosztott számítógépes erőforrásokhoz (például hálózatokhoz, virtuális lemezekhez, memóriához, processzormagokhoz stb.), és ezeket az erőforrásokat automatikusan – vagyis a szolgáltató beavatkozása nélkül – kell biztosítani.
A szolgáltatás széles körű elérhetősége. Az erőforrásokhoz való hozzáférést szabványos mechanizmusokkal kell biztosítani, amelyek lehetővé teszik mind a szabványos PC-k, mind a vékonykliensek és mobileszközök használatát.
Erőforrások egyesítése poolokba. Az erőforráskészleteknek képesnek kell lenniük arra, hogy egyidejűleg több ügyfél számára is biztosítsanak erőforrásokat, biztosítva, hogy az ügyfelek elszigeteltek legyenek, és mentesek legyenek az erőforrásokért folytatott kölcsönös befolyástól és versenytől. Hálózatok is szerepelnek a poolokban, ami jelzi az átfedő címzés alkalmazásának lehetőségét. A medencéknek igény szerint méretezhetőnek kell lenniük. A poolok használata lehetővé teszi a szükséges szintű erőforrás-hibatűrést, valamint a fizikai és virtuális erőforrások absztrakcióját - a szolgáltatás igénybevevője egyszerűen megkapja az általa kért erőforráskészletet (az erőforrások fizikailag hol találhatók, hányan szerverek és kapcsolók – ez a kliens számára nem számít). Figyelembe kell azonban venni azt a tényt, hogy a szolgáltatónak biztosítania kell ezen erőforrások átlátható lefoglalását.
Gyors alkalmazkodás a különböző körülményekhez. A szolgáltatásoknak rugalmasnak kell lenniük - az erőforrások gyors biztosítása, újraelosztása, erőforrások hozzáadása vagy csökkentése az ügyfél kérésére, és az ügyfél részéről érezni kell, hogy a felhő erőforrások végtelenek. A könnyebb érthetőség kedvéért például nem lát figyelmeztetést arra vonatkozóan, hogy az Apple iCloudban lévő lemezterület egy része eltűnt, mert a kiszolgáló merevlemeze meghibásodott, és a meghajtók meghibásodnak. Ráadásul az Ön részéről ennek a szolgáltatásnak a lehetőségei szinte korlátlanok - 2 TB kell - nem probléma, kifizette és megkapta. Hasonló példa a Google.Drive vagy a Yandex.Disk.
Lehetőség a nyújtott szolgáltatás mérésére. A felhőrendszereknek automatikusan ellenőrizniük és optimalizálniuk kell a felhasznált erőforrásokat, és ezeknek a mechanizmusoknak átláthatóknak kell lenniük mind a felhasználó, mind a szolgáltató számára. Vagyis mindig ellenőrizheti, hogy Ön és ügyfelei mennyi erőforrást fogyasztanak.
Érdemes megfontolni azt a tényt, hogy ezek a követelmények többnyire egy nyilvános felhőre vonatkoznak, így egy privát felhő (vagyis a vállalat belső igényeire indított felhő) esetében ezek a követelmények némileg módosíthatók. Ezeket azonban még meg kell tenni, különben nem fogjuk kihasználni a számítási felhő minden előnyét.
Miért van szükségünk felhőre?
Azonban minden új vagy meglévő technológia, bármilyen új protokoll létrejön valamire (na persze, kivéve a RIP-ng-t). Senkinek sem kell protokoll a protokoll kedvéért (na persze, kivéve a RIP-ng-t). Logikus, hogy a felhő azért jön létre, hogy valamilyen szolgáltatást nyújtson a felhasználónak/ügyfélnek. Mindannyian ismerünk legalább néhány felhőszolgáltatást, például a Dropboxot vagy a Google.Docs-t, és úgy gondolom, hogy a legtöbben sikeresen használják őket – például ez a cikk a Google.Docs felhőszolgáltatás használatával készült. De az általunk ismert felhőszolgáltatások csak egy részét képezik a felhő képességeinek – pontosabban csak egy SaaS-típusú szolgáltatás. Háromféleképpen tudunk felhőszolgáltatást nyújtani: SaaS, PaaS vagy IaaS formájában. Az, hogy milyen szolgáltatásra van szüksége, az Ön vágyaitól és képességeitől függ.
Nézzük meg mindegyiket sorrendben:
Szoftver mint szolgáltatás (SaaS) egy olyan modell, amely teljes körű szolgáltatást nyújt az ügyfélnek, például egy e-mail szolgáltatást, mint a Yandex.Mail vagy a Gmail. Ebben a szolgáltatásnyújtási modellben Ön, mint ügyfél, tulajdonképpen nem tesz mást, csak használja a szolgáltatásokat – vagyis nem kell a szolgáltatás beállításán, hibatűrésén, redundanciáján gondolkodnia. A legfontosabb dolog az, hogy ne veszélyeztesse jelszavát, a többit a szolgáltatás szolgáltatója elvégzi Ön helyett. A szolgáltató szemszögéből teljes mértékben ő felel a teljes szolgáltatásért - a szerver hardverétől és a host operációs rendszertől az adatbázis- és szoftverbeállításokig.
Platform mint szolgáltatás (PaaS) — ennek a modellnek a használatakor a szolgáltató a kliens számára munkadarabot biztosít a szolgáltatáshoz, például vegyünk egy webszervert. A szolgáltató biztosította a klienst egy virtuális szervert (valójában egy erőforráskészletet, pl. RAM/CPU/Storage/Nets stb.), sőt erre a szerverre telepítette az operációs rendszert és a szükséges szoftvereket is, azonban a mindezt az ügyfél maga végzi el, és a szolgáltatás teljesítéséhez az ügyfél válaszol. A szolgáltató az előző esethez hasonlóan felelős a fizikai berendezések, hipervizorok, magának a virtuális gépnek a teljesítményéért, hálózati elérhetőségéért stb., de maga a szolgáltatás már nem tartozik a felelősségi körébe.
Infrastruktúra mint szolgáltatás (IaaS) - ez a megközelítés már érdekesebb, sőt, a szolgáltató egy komplett virtualizált infrastruktúrát biztosít a kliensnek - vagyis valamilyen erőforráskészletet (készletet), például CPU magokat, RAM-ot, hálózatokat, stb. az ügyfél - hogy az ügyfél mit akar kezdeni ezekkel az erőforrásokkal a lefoglalt készleten (kvótán) belül - ez nem különösebben fontos a szállító számára. Függetlenül attól, hogy az ügyfél saját vEPC-t szeretne létrehozni, vagy akár egy mini operátort és kommunikációs szolgáltatásokat kíván nyújtani - nem kérdés - tegye meg. Ebben az esetben a szolgáltató felelős az erőforrások rendelkezésre bocsátásáért, hibatűréséért és rendelkezésre állásáért, valamint az operációs rendszerért, amely lehetővé teszi számukra az erőforrások összevonását és elérhetővé tételét az ügyfél számára, és bármikor növelheti vagy csökkentheti az erőforrásokat. az ügyfél kérésére. Az ügyfél maga konfigurálja az összes virtuális gépet és a többi elemet az önkiszolgáló portálon és a konzolon keresztül, beleértve a hálózatok beállítását (a külső hálózatok kivételével).
Mi az az OpenStack?
Mindhárom lehetőség esetén a szolgáltatónak olyan operációs rendszerre van szüksége, amely lehetővé teszi a felhő infrastruktúra létrehozását. Valójában a SaaS-nél több részleg felelős a technológia teljes kötegéért - van egy részleg, amely az infrastruktúráért felelős -, vagyis az IaaS-t egy másik részlegnek biztosítja, ez a részleg biztosítja a SaaS-t az ügyfélnek. Az OpenStack az egyik felhőalapú operációs rendszer, amely lehetővé teszi, hogy egy csomó kapcsolót, kiszolgálót és tárolórendszert egyetlen erőforráskészletbe gyűjtsön, ezt a közös készletet alkészletekre (bérlőkre) ossza fel, és ezeket az erőforrásokat a hálózaton keresztül biztosítsa az ügyfeleknek.
OpenStack egy felhőalapú operációs rendszer, amely lehetővé teszi a számítási erőforrások, adattárolás és hálózati erőforrások nagy készleteinek vezérlését, amelyeket API-n keresztül biztosítanak és kezelnek szabványos hitelesítési mechanizmusok segítségével.
Más szavakkal, ez egy ingyenes szoftverprojektek készlete, amelyet felhőszolgáltatások létrehozására terveztek (nyilvános és privát) - vagyis olyan eszközkészletet, amely lehetővé teszi a szerver és a kapcsolóberendezések egyetlen erőforráskészletbe történő kombinálását, kezelését. ezeket az erőforrásokat, biztosítva a szükséges hibatűrési szintet.
Az anyag írásakor az OpenStack szerkezete így nézett ki:
A kép innen készült
Az OpenStack minden egyes összetevője meghatározott funkciót lát el. Ez az elosztott architektúra lehetővé teszi, hogy a megoldásba belefoglalja a szükséges funkcionális összetevőket. Egyes összetevők azonban gyökérkomponensek, és eltávolításuk a megoldás egészének teljes vagy részleges működésképtelenségéhez vezet. Ezeket az összetevőket általában a következőképpen osztályozzák:
- Műszerfal — Webalapú grafikus felhasználói felület az OpenStack szolgáltatások kezeléséhez
- Zárókő egy központosított identitásszolgáltatás, amely hitelesítési és engedélyezési funkciókat biztosít más szolgáltatásokhoz, valamint kezeli a felhasználói hitelesítő adatokat és szerepköreiket.
- Neutron - hálózati szolgáltatás, amely kapcsolatot biztosít a különböző OpenStack szolgáltatások interfészei között (beleértve a virtuális gépek közötti kapcsolatot és azok külvilághoz való hozzáférését)
- salak — hozzáférést biztosít a virtuális gépek blokktárhelyéhez
- Nova — virtuális gépek életciklus-kezelése
- Pillantás — virtuális gép képeinek és pillanatképeinek tárháza
- Gyors — hozzáférést biztosít a tárolóobjektumhoz
- felhőalap-mérő berendezés — olyan szolgáltatás, amely lehetővé teszi a telemetria összegyűjtését és a rendelkezésre álló és felhasznált erőforrások mérését
- Hőség — az erőforrások automatikus létrehozására és rendelkezésre bocsátására szolgáló sablonokon alapuló hangszerelés
Az összes projekt és céljuk teljes listája megtekinthető .
Minden OpenStack-összetevő egy adott funkciót végrehajtó szolgáltatás, és API-t biztosít a funkció kezeléséhez, valamint más felhőalapú operációs rendszer szolgáltatásaival való interakcióhoz, hogy egységes infrastruktúrát hozzon létre. Például a Nova számítási erőforrás-kezelést és API-t biztosít az erőforrások konfigurálásához, a Glance képkezelést és API-t biztosít ezek kezeléséhez, a Cinder blokktárolást és API-t biztosít ezek kezelésére stb. Minden funkció nagyon szorosan kapcsolódik egymáshoz.
Ha azonban megnézzük, az OpenStackben futó összes szolgáltatás végső soron valamilyen virtuális gép (vagy konténer), amely a hálózathoz kapcsolódik. Felmerül a kérdés – miért van szükségünk ennyi elemre?
Végezzük el a virtuális gép létrehozásának algoritmusát, majd az Openstackben a hálózathoz és a perzisztens tárolóhoz való csatlakoztatását.
- Amikor kérelmet hoz létre egy gép létrehozására, legyen az egy kérés a Horizonon keresztül (irányítópulton) vagy egy kérés a CLI-n keresztül, az első dolog, ami történik, a kérés engedélyezése a Keystone-on – tud-e létrehozni egy gépet, rendelkezik-e a hálózat használati joga, a kvótatervezete stb.
- A Keystone hitelesíti a kérést, és létrehoz egy hitelesítési tokent a válaszüzenetben, amelyet a továbbiakban felhasználunk. Miután megkapta a választ a Keystone-tól, a kérést elküldi a Nova (nova api) felé.
- A Nova-api ellenőrzi kérésének érvényességét úgy, hogy kapcsolatba lép a Keystone-nal a korábban generált hitelesítési token használatával
- A Keystone hitelesítést hajt végre, és ezen a hitelesítési jogkivonat alapján ad tájékoztatást az engedélyekről és korlátozásokról.
- A Nova-api bejegyzést hoz létre az új virtuális géphez a nova-adatbázisban, és átadja a gép létrehozására vonatkozó kérést a nova-schedulernek.
- A Nova-scheduler a megadott paraméterek, súlyok és zónák alapján kiválasztja azt a gazdagépet (számítógép-csomópontot), amelyen a virtuális gép üzembe kerül. Ennek rekordja és a virtuális gép azonosítója a nova-adatbázisba kerül.
- Ezután a nova-scheduler felveszi a kapcsolatot a nova-compute-val egy példány telepítésére vonatkozó kéréssel. A Nova-compute felveszi a kapcsolatot a nova-conductorral, hogy információkat szerezzen a gép paramétereiről (a nova-conductor egy nova elem, amely proxyszerverként működik a nova-database és a nova-compute között, korlátozva a nova-adatbázisra irányuló kérések számát az adatbázissal kapcsolatos problémák elkerülése érdekében konzisztencia terhelés csökkentése).
- A Nova-conductor megkapja a kért információkat a nova-adatbázisból és továbbítja a nova-compute-nak.
- Ezután a nova-compute hívások egy pillantást vetve megkapják a képazonosítót. A Glace érvényesíti a kérést a Keystone-ban, és visszaküldi a kért információkat.
- A Nova-compute kapcsolatba lép a neutronokkal, hogy információkat szerezzen a hálózati paraméterekről. Hasonlóan a pillantáshoz, a neutron a Keystone-ban érvényesíti a kérést, majd létrehoz egy bejegyzést az adatbázisban (portazonosító stb.), létrehoz egy port létrehozására vonatkozó kérést, és visszaküldi a kért információkat a nova-compute-nak.
- A Nova-compute felveszi a kapcsolatot azzal a kéréssel, hogy rendeljen hozzá kötetet a virtuális géphez. A pillantáshoz hasonlóan a cider is érvényesíti a kérést a Keystone-ban, létrehoz egy kötetlétrehozási kérelmet, és visszaadja a kért információkat.
- A Nova-compute felveszi a kapcsolatot a libvirttel egy virtuális gép üzembe helyezését kérve a megadott paraméterekkel.
Valójában egy egyszerű virtuális gép létrehozásának látszólag egyszerű művelete a felhőplatform elemei közötti API-hívások ilyen örvényévé válik. Sőt, amint látható, még a korábban kijelölt szolgáltatások is kisebb komponensekből állnak, amelyek között interakció jön létre. Egy gép létrehozása csak egy kis része annak, amit a felhőplatform lehetővé tesz – van egy szolgáltatás, amely felelős a forgalom kiegyenlítéséért, egy szolgáltatás, amely a blokktárolásért felelős, egy szolgáltatás, amely a DNS-ért felelős, egy szolgáltatás, amely a csupasz fém szerverek kiépítéséért felelős stb. A felhő lehetővé teszi, hogy virtuális gépeit birkacsordaként kezelje (a virtualizációval ellentétben). Ha valami történik a gépeddel virtuális környezetben - visszaállítod biztonsági mentésekből stb., de a felhőalkalmazások úgy vannak felépítve, hogy a virtuális gép ne töltsön olyan fontos szerepet - a virtuális gép „meghalt” - nem probléma - most készül egy új, a jármű a sablon alapján készült, és ahogy mondják, az osztag nem vette észre a harcos elvesztését. Természetesen ez biztosítja a hangszerelési mechanizmusok jelenlétét - a Heat sablonok segítségével könnyedén telepíthet egy több tucat hálózatból és virtuális gépből álló összetett funkciót.
Mindig érdemes szem előtt tartani, hogy nincs felhő infrastruktúra hálózat nélkül - minden elem így vagy úgy kölcsönhatásba lép a többi elemmel a hálózaton keresztül. Ezenkívül a felhőnek abszolút nem statikus hálózata van. Természetesen az alátámasztó hálózat többé-kevésbé statikus - nem minden nap adnak hozzá új csomópontokat és kapcsolókat, de az overlay komponens elkerülhetetlenül folyamatosan változhat és változni fog - új hálózatok kerülnek hozzáadásra vagy törlésre, új virtuális gépek jelennek meg és a régiek meghal. És ahogy a cikk legelején megadott felhő definícióból is emlékszik, az erőforrásokat automatikusan és a szolgáltató legkevesebb (vagy jobb esetben) beavatkozása nélkül kell a felhasználóhoz rendelni. Vagyis az a típusú hálózati erőforrás-szolgáltatás, amely jelenleg front-end formájában létezik, a http/https-n keresztül elérhető személyes fiók és az ügyeletes Vaszilij hálózati mérnök mint háttérrendszer formájában, nem felhő, ha Vaszilijnak nyolc keze van.
A Neutron hálózati szolgáltatásként API-t biztosít a felhő infrastruktúra hálózati részének kezeléséhez. A szolgáltatás egy Network-as-a-Service (NaaS) nevű absztrakciós réteg biztosításával hatalmazza fel és kezeli az Openstack hálózati részét. Vagyis a hálózat ugyanaz a virtuális mérhető egység, mint például a virtuális CPU magok vagy a RAM mennyisége.
Mielőtt azonban ráté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 a hálózat fontos és szerves része a felhőnek.
Tehát két RED kliens virtuális gépünk és két GREEN kliens virtuális gépünk van. Tegyük fel, hogy ezek a gépek két hipervizoron helyezkednek el, így:
Jelenleg ez csak 4 szerver virtualizálása és semmi több, hiszen eddig csak 4 szervert virtualizáltunk, két fizikai szerverre helyezve. És eddig még csak nem is kapcsolódnak a hálózathoz.
Felhő létrehozásához több összetevőt kell hozzáadnunk. Először a hálózati részt virtualizáljuk – ezt a 4 gépet párban kell összekötnünk, és a kliensek L2 kapcsolatot akarnak. Használhat egy kapcsolót és konfigurálhat egy fővonalat az irányába, és mindent megoldhat egy linux híddal, vagy haladóbb felhasználók számára az openvswitch segítségével (erre később visszatérünk). De sok hálózat lehet, és nem a legjobb ötlet az L2-t folyamatosan nyomni egy switch-en keresztül - vannak különböző részlegek, szervizpult, hónapokig tartó várakozás az alkalmazás befejezésére, hetekig tartó hibaelhárítás - a modern világban ez megközelítés már nem működik. És minél előbb megérti ezt egy cég, annál könnyebben léphet előre. Ezért a hipervizorok között kiválasztunk egy L3 hálózatot, amelyen keresztül a virtuális gépeink kommunikálnak, és ezen az L3-as hálózaton virtuális L2 overlay hálózatokat építünk, ahol virtuális gépeink forgalma futni fog. Beágyazásként használhatja a GRE-t, a Geneve-t vagy a VxLAN-t. Most inkább az utóbbira koncentráljunk, bár ez nem különösebben fontos.
Valahol meg kell találnunk a VTEP-t (remélem mindenki ismeri a VxLAN terminológiát). Mivel egy L3-as hálózatunk közvetlenül a szerverekről érkezik, semmi sem akadályoz meg bennünket abban, hogy a VTEP-t magukon a szervereken helyezzük el, és az OVS (OpenvSwitch) kiválóan alkalmas erre. Ennek eredményeként ezt a tervet kaptuk:
Mivel a virtuális gépek közötti forgalmat fel kell osztani, a virtuális gépek felé irányuló portok eltérő VLAN-számmal rendelkeznek. A címkeszám csak egy virtuális kapcsolón belül játszik szerepet, hiszen VxLAN-ba tokozva könnyen eltávolíthatjuk, hiszen lesz VNI-nk.
Most már gond nélkül létrehozhatjuk számukra a gépeinket és a virtuális hálózatainkat.
De mi van akkor, ha a kliensnek van másik gépe, de más hálózaton van? Rootolásra van szükségünk a hálózatok között. Megvizsgálunk egy egyszerű lehetőséget, amikor központosított útválasztást használunk - vagyis a forgalmat speciális dedikált hálózati csomópontokon keresztül irányítják (jó, általában vezérlő csomópontokkal vannak kombinálva, így ugyanaz lesz).
Úgy tűnik, semmi bonyolult - a vezérlő csomóponton csinálunk egy híd interfészt, oda vezetjük a forgalmat, és onnan irányítjuk oda, ahol szükségünk van rá. De a probléma az, hogy a RED kliens a 10.0.0.0/24 hálózatot, a GREEN kliens pedig a 10.0.0.0/24 hálózatot szeretné használni. Azaz elkezdjük metszeni a címtereket. Ezen túlmenően az ügyfelek nem akarják, hogy más ügyfelek be tudjanak kapcsolódni belső hálózataikba, ami logikus. A hálózatok és a kliens adatforgalom szétválasztása érdekében mindegyikhez külön névteret rendelünk. A névtér valójában a Linux hálózati verem mása, vagyis a RED névtérben lévő kliensek teljesen el vannak szigetelve a GREEN névtérből származó kliensektől (jó, az ezen klienshálózatok közötti útválasztás az alapértelmezett névtéren keresztül vagy az upstream szállítóberendezéseken keresztül engedélyezett).
Vagyis a következő diagramot kapjuk:
Az L2 alagutak az összes számítási csomóponttól a vezérlőcsomóponthoz konvergálnak. csomópont, ahol ezeknek a hálózatoknak az L3 interfésze található, mindegyik külön külön névtérben.
A legfontosabbat azonban elfelejtettük. A virtuális gépnek szolgáltatást kell nyújtania a kliens számára, azaz rendelkeznie kell legalább egy külső interfésszel, amelyen keresztül elérhető. Vagyis ki kell mennünk a külvilágba. Itt különböző lehetőségek vannak. Tegyük a legegyszerűbb lehetőséget. Minden ügyfélhez egy hálózatot adunk, amely a szolgáltató hálózatában lesz érvényes, és nem fedi át más hálózatokat. A hálózatok keresztezhetik egymást, és különböző VRF-eket nézhetnek meg a szolgáltatói hálózat oldalán. A hálózati adatok az egyes kliensek névterében is élnek. Azonban továbbra is egyetlen fizikai (vagy kötés, ami logikusabb) interfészen keresztül jutnak ki a külvilágba. Az ügyfélforgalom elkülönítése érdekében a kifelé irányuló forgalmat a klienshez hozzárendelt VLAN-címkével látják el.
Ennek eredményeként a következő diagramot kaptuk:
Ésszerű kérdés, hogy miért nem készítenek átjárókat magukon a számítási csomópontokon? Ez nem nagy probléma, sőt, ha bekapcsolja az elosztott útválasztót (DVR), ez működni fog. Ebben a forgatókönyvben a legegyszerűbb lehetőséget fontolgatjuk egy központi átjáróval, amelyet alapértelmezés szerint használ az Openstack. A nagy terhelésű funkciókhoz elosztott útválasztót és gyorsítási technológiákat is fognak használni, mint például az SR-IOV és a Passthrough, de ahogy mondják, ez egy teljesen más történet. Először is foglalkozzunk az alap résszel, majd a részletekre térünk ki.
Valójában a rendszerünk már működőképes, de van néhány árnyalat:
- Valahogy meg kell védenünk a gépeinket, vagyis szűrőt kell tenni a kapcsoló felületére a kliens felé.
- Lehetővé teszi, hogy egy virtuális gép automatikusan megkapja az IP-címet, így nem kell minden alkalommal a konzolon keresztül bejelentkezni és regisztrálni a címet.
Kezdjük a gépvédelemmel. Ehhez használhatja a banális iptables-t, miért ne.
Vagyis most a topológiánk egy kicsit bonyolultabbá vált:
Menjünk tovább. Hozzá kell adnunk egy DHCP szervert. A legideálisabb hely az egyes kliensek DHCP-kiszolgálóinak megtalálásához a fent említett vezérlőcsomópont, ahol a névterek találhatók:
Van azonban egy kis probléma. Mi van, ha minden újraindul, és minden információ eltűnik a DHCP-n történő címbérlésről. Logikus, hogy a gépek új címeket kapnak, ami nem túl kényelmes. Itt két kiút van - vagy használj domain neveket, és minden klienshez adj hozzá egy DNS-kiszolgálót, akkor a cím nem lesz különösebben fontos számunkra (hasonlóan a k8s hálózati részéhez) - de a külső hálózatokkal van probléma, mivel címeket is ki lehet adni bennük DHCP-n keresztül - szinkronizálásra van szükség a felhőplatform DNS-szervereivel és egy külső DNS-szerverrel, ami véleményem szerint nem túl rugalmas, de teljesen lehetséges. Vagy a második lehetőség a metaadatok használata – vagyis a gépnek kiadott cím információinak mentése, hogy a DHCP szerver tudja, melyik címet adja ki a gépnek, ha a gép már kapott címet. A második lehetőség egyszerűbb és rugalmasabb, mivel lehetővé teszi további információk elmentését az autóról. Most adjuk hozzá az ügynök metaadatait a diagramhoz:
Egy másik kérdés, amelyet szintén érdemes megvitatni, az, hogy minden kliens egy külső hálózatot használhat, mivel a külső hálózatok, ha a teljes hálózaton érvényesnek kell lenniük, nehézkesek lesznek - folyamatosan ki kell osztani és ellenőrizni kell ezeknek a hálózatoknak a kiosztását. Nyilvános felhő létrehozásakor nagyon hasznos lesz az egyetlen külső előre konfigurált hálózat használatának lehetősége minden ügyfél számára. Ez megkönnyíti a gépek üzembe helyezését, mert nem kell címadatbázist keresnünk és egyedi címteret választanunk minden kliens külső hálózatához. Ezenkívül előzetesen regisztrálhatunk külső hálózatot, és a telepítéskor már csak külső címeket kell társítanunk a kliens gépekhez.
És itt a NAT segítségünkre van – csak lehetővé tesszük az ügyfelek számára, hogy az alapértelmezett névtéren keresztül hozzáférjenek a külvilághoz a NAT fordítással. Nos, itt van egy kis probléma. Ez akkor jó, ha a kliens szerver kliensként működik, és nem szerverként – vagyis inkább kezdeményez, mint fogadna kapcsolatokat. De nálunk ez fordítva lesz. Ebben az esetben meg kell csinálnunk a cél NAT-ot, hogy a forgalom fogadásakor a vezérlő csomópont megértse, hogy ez a forgalom az A kliens A virtuális gépére vonatkozik, ami azt jelenti, hogy NAT-fordítást kell végrehajtanunk egy külső címről, például 100.1.1.1-ről. .10.0.0.1, 100 belső címre. Ebben az esetben, bár minden kliens ugyanazt a hálózatot fogja használni, a belső elszigetelés teljesen megmarad. Vagyis dNAT-ot és sNAT-ot kell végrehajtanunk a vezérlőcsomóponton. Az, hogy egyetlen hálózatot használjon lebegő címekkel vagy külső hálózatokat, vagy mindkettőt egyszerre, attól függ, mit szeretne bevinni a felhőbe. Nem adunk hozzá lebegő címeket a diagramhoz, hanem elhagyjuk a korábban már hozzáadott külső hálózatokat - minden kliensnek saját külső hálózata van (a diagramon a külső interfészen vlan 200 és XNUMX-ként vannak feltüntetve).
Ennek eredményeként egy érdekes és egyben átgondolt megoldást kaptunk, amely bizonyos rugalmassággal rendelkezik, de még nincsenek hibatűrő mechanizmusai.
Először is, csak egy vezérlőcsomópontunk van - ennek meghibásodása az összes rendszer összeomlásához vezet. A probléma megoldásához legalább 3 csomópontból kell határozatképesnek lennie. Adjuk hozzá a diagramhoz:
Természetesen minden csomópont szinkronizálva van, és amikor egy aktív csomópont kilép, egy másik csomópont veszi át a feladatait.
A következő probléma a virtuális gép lemezei. Jelenleg ezeket maguk a hipervizorok tárolják, és a hipervizorral kapcsolatos problémák esetén az összes adatot elveszítjük - és a raid jelenléte itt nem segít, ha nem a lemezt, hanem az egész szervert veszítjük el. Ehhez létre kell hoznunk egy szolgáltatást, amely valamilyen tárhely kezelőfelületeként fog működni. Számunkra nem különösebben fontos, hogy milyen tároló lesz, de meg kell védenie adatainkat mind a lemez, mind a csomópont, esetleg az egész szekrény meghibásodásától. Itt több lehetőség is van - természetesen vannak SAN hálózatok Fibre Channel-lel, de legyünk őszinték - az FC már a múlt emléke - az E1 analógja a közlekedésben - igen, egyetértek, még mindig használják, de csak ott, ahol nélküle teljesen lehetetlen. Ezért 2020-ban nem telepítenék önként FC-hálózatot, tudván, hogy vannak más érdekesebb alternatívák. Bár mindenkinek a sajátja, lehetnek olyanok, akik úgy gondolják, hogy az FC a korlátaival együtt minden, amire szükségünk van – nem vitatkozom, mindenkinek megvan a maga véleménye. A legérdekesebb megoldás azonban véleményem szerint az SDS, például a Ceph használata.
A Ceph lehetővé teszi, hogy magas rendelkezésre állású adattárolási megoldást építsen fel egy csomó lehetséges biztonsági mentési lehetőséggel, kezdve a paritásellenőrzéssel rendelkező kódoktól (a raid 5-höz vagy a 6-hoz hasonlóan), a teljes adatreplikációig a különböző lemezekre, figyelembe véve a lemezek elhelyezkedését szerverek és szekrényekben lévő szerverek stb.
A Ceph felépítéséhez további 3 csomópontra van szükség. A tárolóval való interakció a hálózaton keresztül is megvalósul blokk-, objektum- és fájltárolási szolgáltatások segítségével. Adjunk hozzá tárhelyet a sémához:
Megjegyzés: létrehozhat hiperkonvergens számítási csomópontokat is – ez a koncepció több funkció egy csomóponton való kombinálásának koncepciója – például tárolás+számítás – anélkül, hogy speciális csomópontokat rendelnénk a ceph-tároláshoz. Ugyanazt a hibatűrő sémát kapjuk, mivel az SDS az általunk megadott foglalási szinttel fogja lefoglalni az adatokat. A hiperkonvergens csomópontok azonban mindig kompromisszumot jelentenek - mivel a tárolócsomópont nem csak melegíti a levegőt, ahogy első pillantásra tűnik (mivel nincsenek rajta virtuális gépek), hanem CPU erőforrásokat költ az SDS kiszolgálására (sőt, mindent csomópontok, lemezek stb. meghibásodása utáni replikáció és helyreállítás). Ez azt jelenti, hogy elveszíti a számítási csomópont teljesítményének egy részét, ha azt a tárolással kombinálja.
Ezeket a dolgokat valahogy kezelni kell – kell valami, amin keresztül gépet, hálózatot, virtuális útválasztót stb. hozhatunk létre. Ehhez adunk hozzá egy szolgáltatást a vezérlő csomóponthoz, amely műszerfalként fog működni – a kliens képes lesz csatlakozni ehhez a portálhoz a http/ https-en keresztül, és mindent megtehet, amire szüksége van (na jó, majdnem).
Ennek eredményeként ma már egy hibatűrő rendszerrel rendelkezünk. Ennek az infrastruktúrának minden elemét kezelni kell valahogy. Korábban már leírtuk, hogy az Openstack projektek halmaza, amelyek mindegyike sajátos funkciót lát el. Amint látjuk, több mint elég elem van, amelyeket konfigurálni és vezérelni kell. Ma a hálózati részről fogunk beszélni.
Neutron architektúra
Az OpenStackben a Neutron a felelős a virtuális gépek portjainak egy közös L2 hálózathoz való csatlakoztatásáért, a forgalomirányítás biztosításáért a különböző L2 hálózatokon található virtuális gépek között, valamint a kifelé irányításért, olyan szolgáltatásokat nyújtva, mint a NAT, Floating IP, DHCP stb.
Magas szinten a hálózati szolgáltatás (az alaprész) működése a következőképpen írható le.
A virtuális gép indításakor a hálózati szolgáltatás:
- Létrehoz egy portot egy adott virtuális géphez (vagy portokhoz), és értesíti erről a DHCP szolgáltatást;
- Új virtuális hálózati eszköz jön létre (a libvirt segítségével);
- A virtuális gép csatlakozik az 1. lépésben létrehozott port(ok)hoz;
Furcsa módon a Neutron munkája olyan szabványos mechanizmusokon alapul, amelyeket mindenki ismer, aki valaha is belemerült a Linuxba – névterek, iptables, linux hidak, openvswitch, conntrack stb.
Azonnal tisztázni kell, hogy a Neutron nem SDN vezérlő.
A neutron több, egymással összefüggő komponensből áll:
Openstack-neutron-szerver egy démon, amely az API-n keresztül működik a felhasználói kérésekkel. Ez a démon nem vesz részt a hálózati kapcsolatok regisztrálásában, de az ehhez szükséges információkat megadja a pluginjainak, amelyek aztán beállítják a kívánt hálózati elemet. Az OpenStack csomópontokon lévő neutron ügynökök regisztrálnak a Neutron szerveren.
A Neutron-server valójában egy python nyelven írt alkalmazás, amely két részből áll:
- REST szolgáltatás
- Neutron beépülő modul (mag/szolgáltatás)
A REST szolgáltatást úgy tervezték, hogy más összetevőktől származó API-hívásokat fogadjon (például kérések bizonyos információk megadására stb.)
A beépülő modulok olyan beépülő szoftverösszetevők/modulok, amelyeket API kérések során hívnak meg – vagyis egy szolgáltatás hozzárendelése rajtuk keresztül történik. A beépülő modulok két típusra oszthatók - a szolgáltatásra és a root. Általános szabály, hogy a lóbővítmény főként a címtér és a virtuális gépek közötti L2-kapcsolatok kezeléséért felelős, a szolgáltatás-bővítmények pedig már további funkciókat is biztosítanak, például VPN vagy FW.
A ma elérhető bővítmények listája megtekinthető pl
Több szolgáltatási bővítmény is lehet, de csak egy lóbővítmény.
openstack-neutron-ml2 a szabványos Openstack root plugin. Ez a bővítmény moduláris felépítésű (az elődjétől eltérően), és a hálózati szolgáltatást a hozzá csatlakoztatott illesztőprogramokon keresztül konfigurálja. Magát a beépülő modult egy kicsit később fogjuk megnézni, mivel valójában az OpenStack hálózati részének rugalmasságát biztosítja. A root beépülő modul lecserélhető (például a Contrail Networking csinál ilyen cserét).
RPC szolgáltatás (rabbitmq-szerver) — olyan szolgáltatás, amely sorkezelést és interakciót biztosít más OpenStack-szolgáltatásokkal, valamint interakciót a hálózati szolgáltatás ügynökei között.
Hálózati ügynökök — az egyes csomópontokban található ügynökök, amelyeken keresztül a hálózati szolgáltatások konfigurálhatók.
Többféle ügynök létezik.
A fő ügynök az L2 ügynök. Ezek az ügynökök mindegyik hipervizoron futnak, beleértve a vezérlő csomópontokat (pontosabban minden olyan csomóponton, amely bármilyen szolgáltatást nyújt a bérlők számára), és fő funkciójuk a virtuális gépek közös L2 hálózathoz való csatlakoztatása, valamint riasztások generálása, ha bármilyen esemény történik ( például a port letiltása/engedélyezése).
A következő, nem kevésbé fontos ügynök az L3 ügynök. Alapértelmezés szerint ez az ügynök kizárólag egy hálózati csomóponton fut (gyakran a hálózati csomópontot egy vezérlőcsomóponttal kombinálják), és útválasztást biztosít a bérlői hálózatok között (a saját hálózatai és más bérlők hálózatai között is, valamint elérhető a külvilág számára, biztosítva NAT, valamint DHCP szolgáltatás). Azonban DVR (distributed router) használatakor a számítási csomópontokon megjelenik az L3 plugin szükségessége is.
Az L3-ügynök Linux névtereket használ, hogy minden bérlő számára biztosítsa a saját elszigetelt hálózatait és a virtuális útválasztók funkcióit, amelyek a forgalmat irányítják, és átjárószolgáltatásokat biztosítanak a 2. rétegbeli hálózatokhoz.
adatbázis — a hálózatok, alhálózatok, portok, készletek stb. azonosítóinak adatbázisa.
Valójában a Neutron elfogadja az API kéréseket bármilyen hálózati entitás létrehozásától, hitelesíti a kérést, és RPC-n (ha hozzáfér valamilyen bővítményhez vagy ügynökhöz) vagy REST API-n (ha SDN-ben kommunikál) továbbítja az ügynököknek (bővítményeken keresztül) az igényelt szolgáltatás megszervezéséhez szükséges utasításokat.
Most térjünk át a teszttelepítésre (hogyan van telepítve és mit tartalmaz, később a gyakorlati részben látni fogjuk), és nézzük meg, hol találhatók az egyes összetevők:
(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 a neutron teljes szerkezete. Most érdemes egy kis időt szánni az ML2 bővítményre.
2. moduláris réteg
Ahogy fentebb említettük, a beépülő modul egy szabványos OpenStack gyökérbővítmény, és moduláris felépítésű.
Az ML2 plugin elődje monolitikus felépítésű volt, ami például nem tette lehetővé több technológia keverését egy telepítésben. Például nem használhatja egyszerre az openvswitchet és a linuxbridge-et – sem az elsőt, sem a másodikat. Emiatt jött létre az ML2 bővítmény és annak architektúrája.
Az ML2 két komponensből áll – kétféle illesztőprogramból: típus-illesztőprogramokból és mechanizmus-illesztőprogramokból.
Írja be az illesztőprogramokat meghatározza a hálózati kapcsolatok szervezéséhez használt technológiákat, például VxLAN, VLAN, GRE. Ugyanakkor a vezető lehetővé teszi a különböző technológiák használatát. A szabványos technológia a VxLAN tokozás az overlay hálózatokhoz és a külső vlan hálózatokhoz.
A típus-illesztőprogramok a következő hálózattípusokat tartalmazzák:
Lakás - címkézés nélküli hálózat
VLAN - címkézett hálózat
helyi — egy speciális típusú hálózat minden-az-egyben telepítésekhez (az ilyen telepítésekre akár fejlesztőknek, akár oktatáshoz van szükség)
GRE — átfedő hálózat GRE alagutak segítségével
VxLAN — átfedő hálózat VxLAN alagutak segítségével
Mechanizmus meghajtók definiáljon eszközöket, amelyek biztosítják a típusmeghajtóban meghatározott technológiák szervezését - például openvswitch, sr-iov, opendaylight, OVN stb.
Ennek az illesztőprogramnak a megvalósításától függően vagy a Neutron által vezérelt ügynökök kerülnek felhasználásra, vagy egy külső SDN-vezérlőhöz csatlakoznak, amely gondoskodik az L2 hálózatok szervezésével, útválasztással stb. kapcsolatos összes kérdésről.
Példa: ha az ML2-t az OVS-sel együtt használjuk, akkor minden OVS-t kezelő számítási csomópontra telepítve lesz egy L2-ügynök. Ha viszont például OVN-t vagy OpenDayLight-ot használunk, akkor az OVS irányítása az ő joghatóságuk alá tartozik - a Neutron a root pluginon keresztül parancsokat ad a vezérlőnek, és már azt csinálja, amit mondtak neki.
Frissítsük az Open vSwitch-et
Jelenleg az OpenStack egyik kulcsfontosságú összetevője az Open vSwitch.
Ha az OpenStack-et további szállítói SDN-ek, például a Juniper Contrail vagy a Nokia Nuage nélkül telepíti, az OVS a felhőhálózat fő hálózati összetevője, és az iptables-szal, a conntrack-kel és a névterekkel együtt lehetővé teszi teljes értékű többbérletes átfedő hálózatok szervezését. Természetesen ez az összetevő cserélhető, például harmadik fél által védett (szállítói) SDN-megoldások használatakor.
Az OVS egy nyílt forráskódú szoftverkapcsoló, amelyet virtualizált környezetekben való használatra terveztek virtuális forgalomirányítóként.
Jelenleg az OVS nagyon tisztességes funkcionalitással rendelkezik, amely olyan technológiákat tartalmaz, mint a QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK stb.
Megjegyzés: Az OVS-t eredetileg nem a nagy terhelésű telekommunikációs funkciók soft switcheként tervezték, hanem inkább a kevésbé sávszélességet igénylő IT-funkciókhoz, például a WEB-szerverhez vagy a levelezőszerverhez tervezték. Az OVS-t azonban tovább fejlesztik, és az OVS jelenlegi implementációi nagymértékben javították a teljesítményét és képességeit, ami lehetővé teszi, hogy a telekommunikációs szolgáltatók is használják magasan terhelt funkciókkal, például létezik egy DPDK-gyorsítást támogató OVS-implementáció.
Az OVS-nek három fontos összetevője van, amellyel tisztában kell lennie:
- Kernel modul — a kerneltérben található komponens, amely a vezérlőelemtől kapott szabályok alapján feldolgozza a forgalmat;
- vKapcsoló A démon (ovs-vswitchd) egy felhasználói térben elindított folyamat, amely a kernel modul programozásáért felelős - vagyis közvetlenül reprezentálja a kapcsoló működésének logikáját
- Adatbázis-kiszolgáló - minden OVS-t futtató gazdagépen egy helyi adatbázis, amelyben a konfiguráció tárolva van. Az SDN vezérlők ezen a modulon keresztül tudnak kommunikálni az OVSDB protokoll használatával.
Mindehhez egy sor diagnosztikai és felügyeleti segédprogram társul, mint például az ovs-vsctl, ovs-appctl, ovs-ofctl stb.
Jelenleg az Openstacket széles körben használják a távközlési szolgáltatók arra, hogy hálózati funkciókat, például EPC-t, SBC-t, HLR-t stb. migráljanak rá. Egyes funkciók az OVS-sel úgy működnek, ahogy van, de például az EPC feldolgozza az előfizetői forgalmat – majd áthalad hatalmas forgalom (most a forgalom eléri a több száz gigabitet másodpercenként). Természetesen az ilyen forgalom kernelterületen keresztül történő irányítása (mivel a továbbító alapértelmezés szerint ott található) nem a legjobb ötlet. Ezért az OVS-t gyakran teljes egészében a felhasználói térben telepítik a DPDK gyorsítási technológiával a forgalom továbbítására a hálózati kártyáról a felhasználói térbe, megkerülve a kernelt.
Megjegyzés: a távközlési funkciókhoz telepített felhő esetén lehetséges a forgalom az OVS-t megkerülő számítási csomópontból közvetlenül a kapcsolóberendezéshez továbbítani. Erre a célra SR-IOV és Passthrough mechanizmusokat használnak.
Hogyan működik ez egy valós elrendezésen?
Nos, most térjünk át a gyakorlati részre, és nézzük meg, hogyan működik mindez a gyakorlatban.
Először telepítsünk egy egyszerű Openstack telepítést. Mivel nincs kéznél szerverkészletem a kísérletekhez, ezért a prototípust egy fizikai szerveren állítjuk össze virtuális gépekből. Igen, természetesen egy ilyen megoldás nem alkalmas kereskedelmi célokra, de ahhoz, hogy példát lássunk a hálózat működésére az Openstackben, egy ilyen telepítés elég a szemnek. Sőt, egy ilyen telepítés edzési célokra még érdekesebb - mivel el lehet fogni a forgalmat stb.
Mivel csak az alap részt kell látnunk, ezért nem használhatunk több hálózatot, hanem mindent csak két hálózatból emelhetünk ki, és ebben az elrendezésben a második hálózatot kizárólag az undercloud és a DNS szerver eléréséhez használjuk. A külső hálózatokat egyelőre nem érintjük – ez egy külön nagy cikk témája.
Tehát kezdjük sorban. Először is egy kis elmélet. Az Openstack-et a TripleO (Openstack on Openstack) segítségével telepítjük. A TripleO lényege, hogy az Undercloud nevű Openstack all-in-one-t (vagyis egy csomópontra) telepítjük, majd a telepített Openstack képességeit felhasználva telepítjük a működésre szánt Openstack-et, az úgynevezett overcloud-ot. Az Undercloud a fizikai szerverek (csupasz fém) kezelésében rejlő képességét – az Ironic projektet – arra fogja használni, hogy hipervizorokat biztosítson, amelyek számítási, vezérlési és tárolási csomópontokat töltenek be. Vagyis nem használunk harmadik féltől származó eszközöket az Openstack telepítéséhez – az Openstacket az Openstack használatával telepítjük. A telepítés előrehaladtával sokkal világosabb lesz, ezért nem állunk meg itt, és haladunk tovább.
Megjegyzés: Ebben a cikkben az egyszerűség kedvéért nem használtam hálózati elkülönítést a belső Openstack hálózatokhoz, hanem minden csak egy hálózaton keresztül van telepítve. A hálózati leválasztás megléte vagy hiánya azonban nem befolyásolja a megoldás alapvető funkcionalitását - minden pontosan ugyanúgy fog működni, mint az elkülönítés használatakor, de a forgalom ugyanazon a hálózaton fog folyni. Kereskedelmi telepítés esetén természetesen szükség van különböző vlan-ok és interfészek segítségével történő leválasztásra. Például a ceph tárolókezelési forgalom és maga az adatforgalom (gépi hozzáférés a lemezekhez stb.) elkülönítve különböző alhálózatokat használ (Storage Management és Storage), és ez lehetővé teszi, hogy a megoldást hibatűrőbbé tegye a forgalom felosztásával, pl. , különböző portokon keresztül, vagy különböző QoS profilokat használnak a különböző forgalomhoz, hogy az adatforgalom ne szorítsa ki a jelzőforgalmat. A mi esetünkben ugyanazon a hálózaton mennek majd, és valójában ez semmilyen módon nem korlátoz bennünket.
Megjegyzés: Mivel a virtuális gépeket virtuális gépeken alapuló virtuális környezetben fogjuk futtatni, először engedélyeznünk kell a beágyazott virtualizációt.
Így ellenőrizheti, hogy a beágyazott virtualizáció engedélyezve van-e vagy sem:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ha az N betűt látja, akkor engedélyezzük a beágyazott virtualizáció támogatását a hálózaton található bármely útmutató szerint, például .
A következő áramkört kell összeállítanunk virtuális gépekből:
Az én esetemben a jövőbeni telepítés részét képező virtuális gépek összekapcsolásához (és kaptam 7-et, de 4-gyel is meg lehet érni, ha nincs sok erőforrásunk), az OpenvSwitch-et használtam. Létrehoztam egy ovs hidat, és port-csoportokon keresztül virtuális gépeket csatlakoztattam hozzá. Ehhez létrehoztam egy ilyen xml fájlt:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Itt három portcsoport van deklarálva - két hozzáférés és egy trönk (ez utóbbira a DNS-kiszolgálóhoz volt szükség, de megteheti nélküle, vagy telepítheti a gazdagépre - amelyik kényelmesebb). Ezután ezzel a sablonnal deklaráljuk a miénket a virsh net-define segítségével:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Most szerkesztjük a hypervisor port 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: ebben a forgatókönyvben az ovs-br1 porton lévő cím nem lesz elérhető, mert nem rendelkezik vlan címkével. Ennek javításához ki kell adnia a sudo ovs-vsctl set port ovs-br1 tag=100 parancsot. Viszont egy újraindítás után ez a címke eltűnik (ha valaki tudja, hogyan kell a helyén maradni, nagyon megköszönném). De ez nem annyira fontos, mert erre a címre csak a telepítés során lesz szükségünk, és nem lesz szükségünk rá, amikor az Openstack teljesen üzembe kerül.
Ezután létrehozunk egy felhő alatti 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=ttyS0A telepítés során minden szükséges paramétert beállítasz, mint a gép neve, jelszavak, userek, ntp szerverek stb., azonnal beállíthatod a portokat, de nekem személy szerint a telepítés után egyszerűbb a gépbe belépni a gépen keresztül. a konzolt, és javítsa ki a szükséges fájlokat. Ha már van egy kész kép, használhatja, vagy tegye azt, amit én - töltse le a minimális Centos 7 image-et, és használja a virtuális gép telepítéséhez.
Sikeres telepítés után rendelkeznie kell egy virtuális géppel, amelyre telepítheti az undercloud alkalmazást
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningElőször telepítse a telepítési folyamathoz 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és
Létrehozunk egy veremfelhasználót, beállítunk egy jelszót, hozzáadjuk a sudoerhez, és lehetőséget adunk neki, hogy jelszó megadása nélkül hajtson végre root parancsokat a sudo-n keresztül:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackMost megadjuk a teljes undercloud nevet a hosts fájlban:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Ezután hozzáadunk tárolókat, és telepítjü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 tervezi a ceph telepítését, akkor nem kell beírnia a ceph-hez kapcsolódó parancsokat. Én a Queens kiadást használtam, de használhatsz bármilyen mást, ami tetszik.
Ezután másolja az undercloud konfigurációs fájlt a felhasználó saját könyvtárába:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confMost ki kell javítanunk ezt a fájlt a telepítésünkhöz igazítva.
A következő sorokat kell hozzáadnia a fájl elejéhez:
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 menjünk végig a beállításokon:
undercloud_hostname — az undercloud szerver teljes nevének meg kell egyeznie a DNS-kiszolgáló bejegyzésével
local_ip — helyi felhős cím a hálózat kiépítéséhez
hálózati_átjáró - ugyanaz a helyi cím, amely átjáróként fog működni a külvilág felé a overcloud csomópontok telepítése során, egybeesik a helyi IP-címmel is
undercloud_public_host — külső API-cím, a kiépítési hálózat bármely szabad címe hozzá van rendelve
undercloud_admin_host belső API-cím, a kiépítési hálózat bármely szabad címe hozzá van rendelve
undercloud_nameservers - DNS szerver
gener_service_certificate - ez a sor nagyon fontos a mostani példában, mert ha nem hamisra állítod akkor hibaüzenetet kapsz a telepítés során, a probléma leírása a Red Hat hibakövetőn
local_interface interfész a hálózati kiépítésben. Ez az interfész át lesz konfigurálva az undercloud telepítés során, ezért két interfésznek kell lennie az undercloudban - az egyik az eléréséhez, a másik a hozzáféréshez
local_mtu — MTU. Mivel van tesztlaboratóriumunk és az OVS switch portjain 1500-as MTU-m van, ezért 1450-re kell állítani, hogy a VxLAN-ba tokozott csomagok átmenjenek.
network_cidr — szolgáltató hálózat
álöltözet — NAT használata külső hálózat eléréséhez
masquerade_network - hálózat, amely NAT-os lesz
dhcp_start — a címkészlet kezdőcíme, ahonnan címeket rendelnek a csomópontokhoz a felhőalapú telepítés során
dhcp_end — a címkészlet végső címe, ahonnan címeket rendelnek a csomópontokhoz a felhőalapú telepítés során
ellenőrzés_iprange — az önvizsgálathoz szükséges címkészlet (nem szabad átfedésben lennie a fenti készlettel)
ütemező_max_kísérletek — a túlzott felhő telepítési kísérleteinek maximális száma (nagyobbnak kell lennie, mint a csomópontok száma, vagy egyenlőnek kell lennie azzal)
A fájl leírása után kiadhatja az undercloud telepítésének parancsát:
openstack undercloud install
Az eljárás 10-30 percet vesz igénybe a vasalótól függően. Végül a következő kimenetet kell látnia:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Ez a kimenet azt mondja, hogy sikeresen telepítette az undercloudot, és most ellenőrizheti az undercloud állapotát, és folytathatja az overcloud telepítését.
Ha megnézed az ifconfig kimenetét, látni fogod, hogy megjelent egy új hídfelület
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> 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<link>
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 0Az overcloud telepítés ezen a felületen keresztül történik.
Az alábbi kimenetből láthatja, hogy minden szolgáltatásunk 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 |
+--------------------------+-----------+----------+Alább látható a felhő alatti hálózati rész konfigurációja:
(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és
Jelenleg csak alulfelhőink vannak, és nincs elég csomópontunk, ahonnan a overcloud összeáll. Ezért mindenekelőtt telepítsük a szükséges virtuális gépeket. A telepítés során az undercloud maga telepíti az operációs rendszert és a szükséges szoftvereket az overcloud gépre - vagyis nem kell teljesen telepíteni a gépet, hanem csak lemezt (vagy lemezeket) kell készíteni hozzá és meghatározni a paramétereit - azaz , valójában egy csupasz szervert kapunk, amelyre nincs telepítve operációs rendszer.
Menjünk a virtuális gépeink lemezeit tartalmazó mappába, és hozzuk létre a kívánt 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 működünk, meg kell változtatnunk ezeknek a lemezeknek a tulajdonosát, hogy ne legyen probléma a jogokkal:
[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 tervezi a ceph telepítését a tanulmányozása érdekében, akkor a parancsok nem hoznak létre legalább 3 csomópontot legalább két lemezzel, hanem a sablonban jelzik, hogy a vda, vdb stb. virtuális lemezeket használják.
Remek, most meg kell határoznunk ezeket a gépeket:
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 van egy -print-xml > /tmp/storage-1.xml parancs, amely létrehoz egy xml fájlt minden gép leírásával a /tmp/ mappában; ha nem adja hozzá, akkor nem lesz képes azonosítani a virtuális gépeket.
Most meg kell határoznunk ezeket a gépeket a virsh-ben:
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 State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Most egy kis árnyalat - a tripleO az IPMI-t használja a szerverek kezelésére a telepítés és az önvizsgálat során.
Az introspekció a hardver vizsgálatának folyamata annak érdekében, hogy megkapjuk a csomópontok további kiépítéséhez szükséges paramétereket. Az önvizsgálat az ironikus módszerrel történik, amely szolgáltatást úgy tervezték, hogy csupasz fém szerverekkel dolgozzon.
De itt van a probléma - míg a hardveres IPMI-kiszolgálóknak külön portja van (vagy megosztott portja, de ez nem fontos), addig a virtuális gépek nem rendelkeznek ilyen portokkal. Itt egy vbmc nevű mankó jön a segítségünkre - egy segédprogram, amely lehetővé teszi az IPMI port emulálását. Erre az árnyalatra különösen azoknak érdemes odafigyelniük, akik egy ilyen laboratóriumot szeretnének felállítani egy ESXI hipervizoron – őszintén szólva nem tudom, hogy van-e vbmc analógja, ezért érdemes elgondolkodni ezen a témán, mielőtt mindent telepít. .
Vbmc telepítése:
yum install yum install python2-virtualbmcHa az operációs rendszer nem találja a csomagot, adja hozzá a tárolót:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmMost beállítjuk a segédprogramot. Itt minden a szégyenig banális. Most már logikus, hogy nincsenek szerverek a vbmc listában
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Ahhoz, hogy megjelenjenek, manuálisan kell deklarálniuk a következőképpen:
[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 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Szerintem a parancs szintaxisa magyarázat nélkül egyértelmű. Egyelőre azonban minden munkamenetünk DOWN állapotban van. Ahhoz, hogy UP állapotba lépjenek, engedélyeznie kell őket:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#És az utolsó érintés - ki kell javítania a tűzfal szabályait (vagy teljesen le kell tiltania):
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 menjünk a felhőbe, és ellenőrizzük, hogy minden működik-e. A gazdagép címe 192.168.255.200, az undercloudban a telepítés előkészítése során hozzáadtuk a szükséges ipmitool csomagot:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningAmint látja, sikeresen elindítottuk a vezérlő csomópontot a vbmc-n keresztül. 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
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#A következő lépés a csomópontok önvizsgálata, amelyekre a overcloud telepítve lesz. Ehhez el kell készítenünk egy json fájlt a csomópontjaink leírásával. Kérjük, vegye figyelembe, hogy a csupasz szerverekre történő telepítéssel ellentétben a fájl jelzi azt a portot, amelyen a vbmc fut minden egyes gépen.
[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ópontnak két interfésze van, de ebben az esetben ez nem fontos, ebben a telepítésben nekünk egy is elég lesz.
Most elkészítjük a json fájlt. Meg kell adnunk annak a portnak a poppy címét, amelyen keresztül az üzembe helyezés történik, a csomópontok paramétereit, meg kell neveznünk őket, és meg kell adni, hogyan juthatunk el 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ítenünk a képeket az ironizálásra. Ehhez töltse le őket a wget-en keresztül, és telepítse:
(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épek feltöltése a felhőbe:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Ellenőrizzük, hogy minden kép betöltődött-e
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Még egy dolog - hozzá kell adnia egy DNS-kiszolgálót:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| 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
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| 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 | True |
| 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 is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Most kiadhatjuk az önvizsgálat parancsát:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Amint a kimenetből látható, minden hiba nélkül befejeződött. Ellenőrizzük, hogy minden csomópont elérhető állapotban van-e:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Ha a csomópontok eltérő állapotban vannak, általában kezelhetőek, akkor valami hiba történt, és meg kell néznie a naplót, és ki kell derítenie, hogy ez miért történt. Ne feledje, hogy ebben a forgatókönyvben virtualizációt használunk, és előfordulhatnak hibák a virtuális gépek vagy a vbmc használatához.
Ezután meg kell jelölnünk, hogy melyik csomópont melyik funkciót fogja végrehajtani - azaz meg kell jelölni a profilt, amellyel a csomópont telepíteni fog:
(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 ~]$Adja meg az egyes csomópontok profilját:
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 jól csináltunk-e:
(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 helyes, akkor adjuk ki az overcloud telepítésének parancsát:
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ésnél természetesen testreszabott sablonok kerülnek felhasználásra, esetünkben ez nagymértékben megnehezíti a folyamatot, mivel a sablonban minden szerkesztést meg kell magyarázni. Ahogy korábban írtuk, egy egyszerű telepítés is elég lesz ahhoz, hogy lássuk, hogyan működik.
Megjegyzés: ebben az esetben a --libvirt típusú qemu változó szükséges, mivel beágyazott virtualizációt fogunk használni. Ellenkező esetben nem tud virtuális gépeket futtatni.
Most körülbelül egy órája van, vagy talán több is (a hardver képességeitől függően), és csak remélheti, hogy ez idő elteltével a következő üzenetet fogja látni:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Most megvan az openstack szinte teljes verziója, amelyen tanulhat, kísérletezhet stb.
Ellenőrizzük, hogy minden megfelelően működik-e. A felhasználó saját könyvtárában két fájl található - az egyik stackrc (az undercloud kezelésére), a másik pedig az overcloudrc (a túlzott felhők kezelésére). Ezeket a fájlokat forrásként kell megadni, mivel a hitelesítéshez szükséges információkat tartalmaznak.
(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éshez még egy apró érintésre van szükség - egy útvonalat a vezérlőn, mivel a gép, amellyel dolgozom, egy másik hálózaton van. Ehhez lépjen a control-1-be a heat-admin fiók alatt, és regisztrálja az útvonalat
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[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.254Nos, most már mehetsz a horizontba. Minden információ - címek, bejelentkezési név és jelszó - a /home/stack/overcloudrc fájlban található. A végső diagram így néz ki:
Egyébként a mi telepítésünkben a gépcímeket DHCP-n keresztül adták ki, és mint látható, „véletlenszerűen” adják ki. A sablonban szigorúan meghatározhatja, hogy melyik géphez melyik címet kell csatolni a telepítés során, ha szüksége van rá.
Hogyan folyik a forgalom a virtuális gépek között?
Ebben a cikkben az áthaladó forgalom három lehetőségét vizsgáljuk meg
- Két gép egy hypervisoron egy L2 hálózaton
- Két gép különböző hipervizorokon ugyanazon az L2 hálózaton
- Két gép különböző hálózatokon (hálózatok közötti rootolás)
A külvilághoz külső hálózaton keresztüli hozzáféréssel, lebegő címekkel, valamint elosztott útválasztással kapcsolatos eseteket legközelebb mérlegeljük, egyelőre a belső forgalomra koncentrálunk.
Ennek ellenőrzéséhez állítsuk össze a következő diagramot:
Létrehoztunk 4 virtuális gépet - 3 egy L2 hálózaton - net-1 és 1 további a net-2 hálózaton
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Nézzük meg, milyen hipervizorokon helyezkednek el 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 gépek a compute-0-n, a vm-2 és vm-4 gépek az 1-es csomóponton találhatók.
Ezenkívül egy virtuális útválasztót hoztak létre, amely lehetővé teszi a megadott hálózatok közötti útválasztást:
(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 ~]$ Az útválasztónak két virtuális portja van, amelyek a hálózatok átjárójaké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 ~]$ Mielőtt azonban megnéznénk, hogyan folyik a forgalom, nézzük meg, hogy jelenleg mi van a vezérlő csomóponton (ami egyben hálózati csomópont is) és a számítási csomóponton. Kezdjük a számítási csomóponttal.
[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ópontnak három ovs-hídja van - br-int, br-tun, br-ex. Közöttük, mint látjuk, van egy sor interfész. A könnyebb érthetőség érdekében ábrázoljuk ezeket az interfészeket a diagramon, és nézzük meg, mi történik.
Ha megnézzük azokat a címeket, amelyekre a VxLAN alagutak fel vannak emelve, látható, hogy az egyik alagút a compute-1-re (192.168.255.26), a második pedig a control-1-re (192.168.255.15) van emelve. De a legérdekesebb az, hogy a br-ex nem rendelkezik fizikai interfészekkel, és ha megnézzük, hogy milyen áramlások vannak beállítva, akkor láthatjuk, hogy ez a híd jelenleg csak a forgalmat tudja csökkenteni.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> 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<link>
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 ~]$ Amint a kimenetből látható, a cím közvetlenül a fizikai porthoz van csavarozva, nem pedig a virtuális híd interfészéhez.
[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 mindent, ami a phy-br-ex portról jött, el kell dobni.
Valójában ezen a felületen (a br-int-tel való interfészen) kívül jelenleg máshol nem érkezhet forgalom erre a hídra, és a visszaesésekből ítélve a BUM forgalom már be is érkezett a hídba.
Vagyis a forgalom csak a VxLAN alagúton keresztül hagyhatja el ezt a csomópontot, semmi máson. Viszont ha bekapcsolod a DVR-t, akkor változni fog a helyzet, de ezzel máskor foglalkozunk. Hálózati elkülönítés használatakor, például VLAN-ok használatakor nem egy L3 interfész lesz a 0. vlan-ban, hanem több interfész. A VxLAN-forgalom azonban ugyanúgy elhagyja a csomópontot, de valamilyen dedikált vlan-be is be van zárva.
A számítási csomópontot rendeztük, térjünk át a vezérlő 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: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (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 elmondhatjuk, hogy minden a régi, de az IP-cím már nem a fizikai felületen van, hanem a virtuális hídon. Ez azért történik, mert ez a port az a port, amelyen keresztül a forgalom kilép a külvilágba.
[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 rajta vlan tagek, ez a port egy trönk port, amelyen minden vlan engedélyezett, most a forgalom címke nélkül megy kifelé, amint azt a vlan-id 0 jelzi a kimenet fent.
Jelenleg minden más hasonló a számítási csomóponthoz – ugyanazok a hidak, ugyanazok az alagutak, amelyek két számítási csomóponthoz vezetnek.
Ebben a cikkben nem foglalkozunk a tárolási csomópontokkal, de a megértéshez el kell mondani, hogy ezeknek a csomópontoknak a hálózati része a szégyenig banális. A mi esetünkben csak egy fizikai port (eth0) van hozzárendelve egy IP-címmel, és ennyi. Nincsenek VxLAN alagutak, alagúthidak stb. - ovs egyáltalán nincs, mivel nincs értelme. Hálózati elkülönítés használatakor ennek a csomópontnak két interfésze lesz (fizikai portok, bodny vagy csak két vlan - mindegy - attól függ, hogy mit akar) - az egyik a felügyelethez, a másik a forgalomhoz (írás a virtuális gép lemezére) , olvasás lemezről stb.)
Szolgáltatás hiányában kitaláltuk, hogy mi van a csomópontokon. Most indítsunk el 4 virtuális gépet, és nézzük meg, hogyan változik a fent leírt séma - kellenek portok, virtuális útválasztók stb.
Hálózatunk eddig így néz ki:
Minden számítógép-csomóponton két virtuális gépünk van. Példaként a compute-0 használatával nézzük meg, hogyan szerepel minden.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ A gépnek csak egy virtuális felülete van - tap95d96a75-a0:
[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 ~]$
Ez az interfész a Linux Bridge-ben néz ki:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Amint a kimenetből látható, csak két interfész van a hídban - tap95d96a75-a0 és qvb95d96a75-a0.
Itt érdemes egy kicsit elidőzni az OpenStack virtuális hálózati eszközeinek típusán:
vtap – egy példányhoz (VM) csatolt virtuális interfész
qbr - Linux híd
qvb és qvo - vEth pár csatlakozik a Linux hídhoz és az Open vSwitch hídhoz
br-int, br-tun, br-vlan — vSwitch hidak megnyitása
patch-, int-br-, phy-br- - Nyissa meg a vSwitch patch interfészt a hidak között
qg, qr, ha, fg, sg – A virtuális eszközök által használt vSwitch portok megnyitása az OVS-hez való csatlakozáshoz
Amint értitek, ha van egy qvb95d96a75-a0 port a hídban, ami vEth pár, akkor valahol ott van a megfelelője, amit logikusan qvo95d96a75-a0-nak kellene nevezni. Lássuk, 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 ~]$ Amint látjuk, a port a br-int. A Br-int kapcsolóként működik, amely lezárja a virtuális gépek portjait. A qvo95d96a75-a0 mellett a qvo5bd37136-47 port is látható a kimeneten. Ez a második virtuális gép portja. Ennek eredményeként a diagramunk most így néz ki:
Egy kérdés, ami azonnal érdekelheti a figyelmes olvasót - mi a linux híd a virtuális gép portja és az OVS port között? A helyzet az, hogy a gép védelmére biztonsági csoportokat használnak, amelyek nem mások, mint az iptables. Az OVS nem működik iptables-szal, ezért találták ki ezt a „mankót”. Ez azonban elavulttá válik – az új kiadásokban a conntrack váltja fel.
Vagyis a séma végül így néz ki:
Két gép egy hypervisoron egy L2 hálózaton
Mivel ez a két virtuális gép ugyanazon az L2 hálózaton és ugyanazon a hypervisoron található, a köztük lévő forgalom logikailag lokálisan folyik a br-int-en keresztül, mivel mindkét gép ugyanazon a VLAN-on 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ő hipervizorokon ugyanazon az L2 hálózaton
Most nézzük meg, hogyan megy a forgalom két gép között ugyanazon az L2 hálózaton, de különböző hipervizorokon. Őszintén szólva semmi sem fog sokat változni, csak a hypervisorok közötti forgalom a vxlan alagúton megy keresztül. Nézzünk egy példát.
Azon virtuális gépek címei, amelyek között a forgalmat figyeljük:
[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-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Megnézzük a br-int továbbítási táblázatát a compute-0-ban:
[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 forgalomnak a 2-es portra kell mennie – nézzük meg, milyen portról van szó:
[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 – vagyis a br-tun interfésze. Lássuk, mi történik a csomaggal a br-tunon:
[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 csomagot VxLAN-ba csomagolják és a 2-es portra küldik. Nézzük meg, hova 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 egy 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-hez, és nézzük meg, mi történik ezután 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 a compute-1 br-int továbbítási táblázatában található, és amint a fenti kimenetből látható, a 2-es porton keresztül látható, amely a br-tun felé vezető port:
[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:46Nos, akkor azt látjuk, hogy a br-int on compute-1-ben van egy cél mák:
[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 ~]$ Vagyis a kapott csomag a 3-as portra repül, ami mögött már van egy virtuális gép példánya-00000003.
Az Openstack virtuális infrastruktúrán való tanulásra való telepítésének szépsége az, hogy könnyedén rögzíthetjük a hipervizorok közötti forgalmat, és megnézhetjük, mi történik vele. Most ezt fogjuk tenni, futtassuk a tcpdump parancsot a vnet porton a compute-0 felé:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 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), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 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), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Az első sor azt mutatja, hogy a Patek a 10.0.1.85-ös címről a 10.0.1.88-as címre megy (ICMP-forgalom), és egy VxLAN-csomagba van csomagolva vni 22-vel, és a csomag a 192.168.255.19 (compute-0) gazdagépről a 192.168.255.26-as állomásra megy. .1 ( számítás-XNUMX). Ellenőrizhetjük, hogy a VNI egyezik-e az ovs-ban megadottal.
Térjünk vissza ehhez a sorhoz action=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. A 0x16 vni hexadecimális számrendszerben. Alakítsuk át ezt a számot 16-es rendszerré:
16 = 6*16^0+1*16^1 = 6+16 = 22Vagyis vni megfelel a valóságnak.
A második sor a visszatérő forgalmat mutatja, nos, nincs értelme magyarázni, ott minden világos.
Két gép különböző hálózatokon (hálózatok közötti útválasztás)
A mai nap utolsó esete a hálózatok közötti útválasztás egy projekten belül egy virtuális útválasztó segítségével. DVR nélküli esetet fontolgatunk (egy másik cikkben megnézzük), így az útválasztás a hálózati csomóponton történik. Esetünkben a hálózati csomópont nincs külön entitásban elhelyezve, és a vezérlő csomóponton található.
Először is nézzük meg, hogy működik-e az útválasztás:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msMivel ebben az esetben a csomagnak az átjáróhoz kell mennie és oda kell irányítani, meg kell találnunk az átjáró poppy címét, amihez a példányban az ARP táblát nézzük:
$ 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 lássuk, hova kell küldeni a (10.0.1.254) fa:16:3e:c4:64:70 célú forgalmat:
[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 ~]$ Nézzük, hova vezet a 2-es 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 ~]$ Minden logikus, br-tunra megy a forgalom. Lássuk, melyik vxlan alagútba fog csomagolni:
[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 ~]$ A harmadik port egy vxlan alagút:
[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 ~]$ Ami a vezérlő csomópontot nézi:
[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 elérte a vezérlő csomópontot, ezért oda kell mennünk, és meg kell néznünk, hogyan történik az útválasztás.
Emlékszel, a belső vezérlő csomópont pontosan ugyanúgy nézett ki, mint a számítási csomópont - ugyanaz a három híd, csak a br-exnek volt egy fizikai portja, amelyen keresztül a csomópont forgalmat küldhet kifelé. A példányok létrehozása megváltoztatta a számítási csomópontok konfigurációját - linux híd, iptable és interfészek kerültek a csomópontokhoz. A hálózatok és a virtuális útválasztó létrehozása is rányomta bélyegét a vezérlő csomópont konfigurációjára.
Tehát nyilvánvaló, hogy az átjáró MAC-címének a vezérlőcsomópont br-int továbbítási táblájában kell lennie. Ellenőrizzük, hogy ott van-e, és hol keres:
[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 ~]$ A Mac a qr-0c52b15f-8f portról látható. Ha visszamegyünk az Openstack virtuális portjainak listájához, akkor ez a porttípus különféle virtuális eszközök OVS-hez való csatlakoztatására szolgál. Pontosabban, a qr a virtuális útválasztó portja, amely névtérként jelenik meg.
Nézzük meg, milyen névterek vannak a szerveren:
[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 ~]$ Akár három példányban. De a nevek alapján kitalálhatja mindegyik célját. Később visszatérünk a 0 és 1 azonosítójú példányokra, most a qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe névtér érdekel:
[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 ~]$ Ez a névtér két belső névteret tartalmaz, amelyeket korábban hoztunk létre. Mindkét virtuális port hozzáadásra került 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éből ítélve erre az interfészre ment.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> 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<link>
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 ~]$ Vagyis ebben az esetben minden a szabványos útválasztás törvényei szerint működik. Mivel a forgalom a 10.0.2.8-as gazdagépre irányul, a qr-92fa49b5-54 második interfészen keresztül kell kilépnie, és a vxlan alagúton keresztül kell eljutnia a számítási csomóponthoz:
[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, nincs meglepetés. Nézzük meg, hol látható a 10.0.2.8-as gazdagép poppy címe a br-intben:
[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 ~]$ A várakozásoknak megfelelően a forgalom a br-tun felé halad, nézzük meg, 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 bemegy az alagútba az 1 kiszámításához. Nos, a compute-1-en minden egyszerű - a br-tun-ból a csomag a br-int-be megy, onnan pedig a virtuális gép felületére:
[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 valóban ez a megfelelő felület:
[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 ~]$
Tulajdonképpen végigmentünk a csomagon. Gondolom észrevetted, hogy a forgalom különböző vxlan alagutakon ment keresztül és különböző VNI-kkel távozott. Nézzük meg, milyen VNI-k ezek, utána gyűjtünk egy dump-ot a csomópont vezérlőportján, és megbizonyosodunk arról, hogy a forgalom pontosan a fent leírtak szerint folyik.
Tehát a compute-0 alagút a következő műveletekkel rendelkezik=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Alakítsuk át a 0x16-ot decimális számrendszerré:
0x16 = 6*16^0+1*16^1 = 6+16 = 22A compute-1 alagút a következő VNI-vel rendelkezik:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],kimenet:2. Alakítsuk át a 0x63-at decimális számrendszerré:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Nos, most nézzük a szemétlerakást:
[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 gazdagéptől (compute-0) a 192.168.255.15 állomásig (control-1) vni 22-vel, amelyen belül egy ICMP-csomag van csomagolva a 10.0.1.85-től a 10.0.2.8-ig. Ahogy fentebb kiszámoltuk, vni megegyezik azzal, amit a kimenetben láttunk.
A második csomag egy vxlan-csomag a 192.168.255.15-ös gazdagéptől (control-1) a 192.168.255.26-os gazdagépig (compute-1) vni 99-cel, amelyen belül egy ICMP-csomag van csomagolva a 10.0.1.85-ös gazdagéptől a 10.0.2.8-ig. Ahogy fentebb kiszámoltuk, vni megegyezik azzal, amit a kimenetben láttunk.
A következő két csomag visszatérő forgalom 10.0.2.8-ról, nem 10.0.1.85-ről.
Vagyis végül a következő vezérlő csomópont sémát kaptuk:
Úgy néz ki, ez az? Két névteret elfelejtettünk:
[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 ~]$ Ahogy a felhőplatform architektúrájáról beszéltünk, jó lenne, ha a gépek automatikusan kapnák a címeket egy DHCP szervertől. Ez két DHCP-szerver két hálózatunkhoz: 10.0.1.0/24 és 10.0.2.0/24.
Ellenőrizzük, hogy ez igaz-e. Ebben a névtérben csak egy cím található - 10.0.1.1 - magának a DHCP-kiszolgálónak a címe, és ez is benne van a br-intben:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
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<UP,BROADCAST,RUNNING,MULTICAST> 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<link>
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 a vezérlőcsomóponton a nevükben qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2-t tartalmazó folyamatok:
[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 ~]$ Létezik egy ilyen folyamat, és a fenti kimenetben bemutatott információk alapján például megnézhetjük, mi van jelenleg bérelhető:
[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 a következő szolgáltatáskészletet kapjuk a vezérlő csomóponton:
Nos, ne feledje – ez csak 4 gép, 2 belső hálózat és egy virtuális útválasztó... Itt most nincsenek külső hálózataink, egy csomó különböző projekt, mindegyiknek saját hálózata van (átfedésben), és van egy elosztott router kikapcsolt, és végül is csak egy vezérlő csomópont volt a tesztpadon (a hibatűréshez három csomópontnak kell határozatképesnek lennie). Logikus, hogy a kereskedelemben minden „kicsit” bonyolultabb, de ebből az egyszerű példából megértjük, hogyan is kell működnie – természetesen fontos, hogy 3 vagy 300 névtér van, de a teljes működés szempontjából szerkezete, semmi sem fog sokat változni... bár amíg nem csatlakoztat valamilyen gyártó SDN-t. De ez egy teljesen más történet.
Remélem érdekes volt. Ha van észrevétele/kiegészítése, vagy valahol egyenesen hazudtam (ember vagyok, és a véleményem mindig szubjektív) - írja meg, hogy mit kell javítani/kiegészíteni - mindent javítunk/hozzáadunk.
Végezetül szeretnék néhány szót ejteni az Openstack (mind a vanília, mind a gyártó) és a VMWare felhőmegoldásának összehasonlításáról – az elmúlt néhány évben túl gyakran tették fel ezt a kérdést, és őszintén szólva már belefáradt, de akkor is. Véleményem szerint nagyon nehéz összehasonlítani ezt a két megoldást, de határozottan kijelenthetjük, hogy mindkét megoldásnak vannak hátrányai, és az egyik megoldás kiválasztásakor mérlegelni kell az előnyöket és hátrányokat.
Ha az OpenStack egy közösségvezérelt megoldás, akkor a VMWare-nek joga van csak azt csinálni, amit akar (olvasd - ami megtérül számára), és ez logikus is - mert ez egy kereskedelmi cég, amely szokott pénzt keresni az ügyfeleiből. De van egy nagy és kövér DE - kiléphetsz az OpenStackből például a Nokiából, és kis költséggel válthatsz például a Juniper (Contrail Cloud) megoldására, de a VMWare-ről nem valószínű, hogy sikerül. . Számomra ez a két megoldás így néz ki - Az Openstack (vendor) egy egyszerű ketrec, amibe beteszik, de van kulcsa, és bármikor kimehet. A VMWare egy aranykalitka, a tulajdonosnál van a ketrec kulcsa és sokba fog kerülni.
Nem reklámozom sem az első, sem a második terméket – Ön választja ki, amire szüksége van. De ha lenne ilyen választásom, mindkét megoldást választanám - a VMWare-t az IT-felhőhöz (alacsony terhelés, egyszerű kezelés), az OpenStack-et valamelyik gyártótól (a Nokia és a Juniper nagyon jó kulcsrakész megoldásokat kínál) - a Telecom felhőhöz. Az Openstack-et nem használnám tisztán informatikai célokra – olyan, mintha ágyúval lőnék verebeket, de a redundancián kívül nem látok ellenjavallatot a használatára. Azonban a VMWare használata a távközlésben olyan, mint egy Ford Raptorral zúzott követ cipelni – kívülről gyönyörű, de a sofőrnek egy út helyett 10 utat kell megtennie.
Véleményem szerint a VMWare legnagyobb hátránya a teljes zártsága - a cég nem ad semmilyen információt arról, hogyan működik pl. vSAN, vagy mi van a hypervisor kernelben - egyszerűen nem kifizetődő neki - vagyis soha ne válj szakértővé a VMWare-ben – a gyártói támogatás nélkül pusztulásra van ítélve (nagyon gyakran találkozom VMWare-szakértőkkel, akik értetlenül állnak a triviális kérdések előtt). Számomra a VMWare zárt motorháztetős autót vesz - igen, lehet, hogy vannak szakembereid, akik ki tudják cserélni a vezérműszíjat, de csak az tudja kinyitni a motorháztetőt, aki eladta neked ezt a megoldást. Én személy szerint nem szeretem azokat a megoldásokat, amelyekbe nem férek bele. Azt fogja mondani, hogy nem kell bemennie a motorháztető alá. Igen, ez lehetséges, de megnézem, amikor egy nagy függvényt kell összeállítani a felhőben 20-30 virtuális gépből, 40-50 hálózatból, amelyek fele ki akar menni, a második fele pedig SR-IOV gyorsulás, különben több tucatnyi ilyen autóra lesz szüksége - különben a teljesítmény nem lesz elég.
Vannak más szempontok is, így csak Ön döntheti el, hogy mit válasszon, és ami a legfontosabb, akkor Ön lesz felelős a választásáért. Ez csak az én véleményem – olyan ember, aki látott és megérintett legalább 4 terméket – Nokia, Juniper, Red Hat és VMWare. Vagyis van mihez hasonlítanom.
Forrás: will.com