Računalništvo v oblaku prodira vse globlje v naša življenja in verjetno ni človeka, ki ne bi vsaj enkrat uporabil katere od storitev v oblaku. Kaj sploh je oblak in kako deluje, pa le malo ljudi ve, že na ravni ideje. 5G že postaja resničnost in telekomunikacijska infrastruktura se začenja premikati od stebrnih rešitev k rešitvam v oblaku, tako kot je to storila, ko je prešla iz popolnoma strojnih rešitev v virtualizirane »stebre«.
Danes bomo govorili o notranjem svetu infrastrukture v oblaku, še posebej si bomo ogledali osnove omrežnega dela.
Kaj je oblak? Ista virtualizacija - pogled profila?
Več kot logično vprašanje. Ne – to ni virtualizacija, čeprav brez nje ne bi šlo. Poglejmo si dve definiciji:
Računalništvo v oblaku (v nadaljevanju oblak) je model za zagotavljanje uporabniku prijaznega dostopa do porazdeljenih računalniških virov, ki jih je treba namestiti in zagnati na zahtevo z najnižjo možno zakasnitvijo in minimalnimi stroški za ponudnika storitev.
Virtualizacija - to je možnost, da eno fizično entiteto (npr. strežnik) razdelite na več virtualnih in s tem povečate izkoriščenost virov (npr. imeli ste 3 strežnike obremenjene 25-30 odstotkov, po virtualizaciji dobite 1 strežnik naložen pri 80-90 odstotkih). Seveda virtualizacija poje nekaj virov - nahraniti morate hipervizor, vendar je, kot je pokazala praksa, igra vredna sveče. Idealen primer virtualizacije je VMWare, ki odlično pripravi virtualne stroje, ali na primer KVM, ki mi je ljubši, vendar je to stvar okusa.
Uporabljamo virtualizacijo, ne da bi se tega zavedali, in celo železni usmerjevalniki že uporabljajo virtualizacijo - na primer, v najnovejši različici JunOS je operacijski sistem nameščen kot virtualni stroj na vrhu distribucije Linuxa v realnem času (Wind River 9). Toda virtualizacija ni oblak, ampak oblak ne more obstajati brez virtualizacije.
Virtualizacija je eden od gradnikov, na katerih je zgrajen oblak.
Izdelava oblaka s preprostim zbiranjem več hipervizorjev v eno domeno L2, dodajanjem nekaj yaml playbookov za samodejno registracijo vlanov prek nekakšnega ansibla in motenje nečesa, kot je sistem orkestracije na vse skupaj za samodejno ustvarjanje virtualnih strojev, ne bo delovalo. Bolj natančno bo, vendar nastali Frankenstein ni oblak, ki ga potrebujemo, čeprav so morda največje sanje za druge. Poleg tega, če vzamete isti Openstack, je v bistvu še vedno Frankenstein, a oh, ne bomo o tem za zdaj.
Razumem pa, da iz zgornje definicije ni povsem jasno, kaj pravzaprav lahko imenujemo oblak.
Zato dokument NIST (National Institute of Standards and Technology) podaja 5 glavnih značilnosti, ki jih mora imeti infrastruktura v oblaku:
Storitev na zahtevo. Uporabniku mora biti omogočen prost dostop do računalniških virov, ki so mu dodeljeni (kot so omrežja, virtualni diski, pomnilnik, procesorska jedra itd.), ti viri pa morajo biti zagotovljeni samodejno – torej brez posredovanja ponudnika storitev.
Široka razpoložljivost storitev. Dostop do virov mora biti zagotovljen s standardnimi mehanizmi, ki omogočajo uporabo tako standardnih osebnih računalnikov kot lahkih odjemalcev in mobilnih naprav.
Združevanje virov v bazene. Skupine virov morajo biti sposobne zagotavljati vire več odjemalcem hkrati, kar zagotavlja, da so odjemalci izolirani ter brez medsebojnega vpliva in konkurence za vire. V bazene so vključena tudi omrežja, kar kaže na možnost uporabe prekrivajočega se naslavljanja. Bazeni morajo imeti možnost prilagajanja na zahtevo. Uporaba bazenov omogoča zagotavljanje potrebne stopnje odpornosti na napake virov in abstrakcije fizičnih in virtualnih virov – prejemniku storitve se preprosto zagotovi nabor virov, ki jih je zahteval (kje se ti viri fizično nahajajo, na koliko strežniki in stikala - ni pomembno za odjemalca). Pri tem pa moramo upoštevati dejstvo, da mora ponudnik zagotoviti transparentno rezervacijo teh virov.
Hitro prilagajanje različnim razmeram. Storitve morajo biti fleksibilne - hitro zagotavljanje virov, njihova redistribucija, dodajanje ali zmanjševanje virov na željo naročnika, pri naročniku pa mora biti občutek, da so viri v oblaku neskončni. Zaradi lažjega razumevanja na primer ne vidite opozorila, da je del vašega diskovnega prostora v Apple iCloud izginil, ker se je trdi disk na strežniku pokvaril, pogoni pa se pokvarijo. Poleg tega so z vaše strani možnosti te storitve skoraj neomejene - potrebujete 2 TB - ni problema, plačali ste in prejeli. Podoben primer lahko navedemo z Google.Drive ali Yandex.Disk.
Možnost merjenja opravljene storitve. Oblačni sistemi morajo samodejno nadzorovati in optimizirati porabljene vire, ti mehanizmi pa morajo biti transparentni tako za uporabnika kot za ponudnika storitev. To pomeni, da lahko vedno preverite, koliko sredstev porabite vi in vaše stranke.
Upoštevati velja dejstvo, da so te zahteve večinoma zahteve za javni oblak, zato se lahko za zasebni oblak (torej oblak, ki je lansiran za interne potrebe podjetja) te zahteve nekoliko prilagodijo. Vendar jih je še vedno treba narediti, sicer ne bomo deležni vseh prednosti računalništva v oblaku.
Zakaj potrebujemo oblak?
Vendar pa je vsaka nova ali obstoječa tehnologija, vsak nov protokol ustvarjen za nekaj (no, razen za RIP-ng, seveda). Nihče ne potrebuje protokola zaradi protokola (no, razen RIP-ng, seveda). Logično je, da je oblak ustvarjen za zagotavljanje neke vrste storitve uporabniku/stranki. Vsi poznamo vsaj nekaj storitev v oblaku, na primer Dropbox ali Google.Docs, in verjamem, da jih večina ljudi uspešno uporablja – ta članek je na primer napisan z uporabo storitve v oblaku Google.Docs. Toda storitve v oblaku, ki jih poznamo, so le del zmogljivosti oblaka – natančneje, so le storitev tipa SaaS. Storitev v oblaku lahko nudimo na tri načine: v obliki SaaS, PaaS ali IaaS. Kakšno storitev potrebujete, je odvisno od vaših želja in zmožnosti.
Oglejmo si vsakega po vrsti:
Programska oprema kot storitev (SaaS) je model za zagotavljanje popolne storitve stranki, na primer e-poštne storitve, kot sta Yandex.Mail ali Gmail. V tem modelu zagotavljanja storitev vi kot naročnik dejansko ne počnete ničesar, razen da uporabljate storitve – to pomeni, da vam ni treba razmišljati o nastavitvi storitve, njeni odpornosti na napake ali redundanci. Glavna stvar je, da ne ogrozite svojega gesla, vse ostalo bo namesto vas naredil ponudnik te storitve. Z vidika ponudnika storitev je v celoti odgovoren za celotno storitev – od strežniške strojne opreme in gostiteljskih operacijskih sistemov do podatkovnih baz in nastavitev programske opreme.
Platforma kot storitev (PaaS) — pri uporabi tega modela ponudnik storitve naročniku zagotovi obdelovanec za storitev, vzemimo na primer spletni strežnik. Ponudnik storitev je odjemalcu zagotovil navidezni strežnik (pravzaprav nabor virov, kot je RAM/CPE/Storage/Nets itd.) in celo namestil OS in potrebno programsko opremo na ta strežnik, vendar konfiguracija vse te stvari opravi naročnik sam in za izvedbo storitve odgovarja naročnik. Ponudnik storitve je tako kot v prejšnjem primeru odgovoren za delovanje fizične opreme, hipervizorjev, samega virtualnega stroja, njegovo omrežno razpoložljivost ipd., sama storitev pa ni več v njegovem območju odgovornosti.
Infrastruktura kot storitev (IaaS) - ta pristop je že bolj zanimiv, v resnici ponudnik storitev stranki zagotovi celotno virtualizirano infrastrukturo - torej nek nabor (pool) virov, kot so jedra procesorja, RAM, omrežja itd. Vse ostalo je odvisno od naročnik - kaj želi naročnik narediti s temi viri znotraj dodeljenega bazena (kvote) - za dobavitelja ni posebej pomembno. Ne glede na to, ali želi stranka ustvariti svoj lasten vEPC ali celo ustvariti mini operaterja in zagotavljati komunikacijske storitve - brez dvoma - naredite to. V takem scenariju je ponudnik storitev odgovoren za zagotavljanje virov, njihovo odpornost na napake in razpoložljivost ter OS, ki mu omogoča združevanje teh virov in njihovo dajanje na voljo odjemalcu z možnostjo povečanja ali zmanjšanja virov kadar koli. na željo naročnika. Odjemalec sam konfigurira vse virtualne stroje in drugo drobtino preko samopostrežnega portala in konzole, vključno z nastavitvijo omrežij (razen zunanjih omrežij).
Kaj je OpenStack?
Pri vseh treh možnostih ponudnik potrebuje OS, ki bo omogočal izgradnjo oblačne infrastrukture. Pravzaprav je pri SaaS več kot en oddelek odgovoren za celoten nabor tehnologij – obstaja oddelek, ki je odgovoren za infrastrukturo – to pomeni, da zagotavlja IaaS drugemu oddelku, ta oddelek zagotavlja SaaS stranki. OpenStack je eden od operacijskih sistemov v oblaku, ki vam omogoča, da zberete kup stikal, strežnikov in sistemov za shranjevanje v eno skupino virov, razdelite to skupno skupino na podskupine (najemnike) in te vire zagotovite strankam prek omrežja.
OpenStack je operacijski sistem v oblaku, ki vam omogoča nadzor velikih skupin računalniških virov, shranjevanja podatkov in omrežnih virov, ki so omogočeni in upravljani prek API-ja z uporabo standardnih mehanizmov za preverjanje pristnosti.
Z drugimi besedami, to je nabor projektov brezplačne programske opreme, ki je zasnovan za ustvarjanje storitev v oblaku (tako javnih kot zasebnih) – to je nabor orodij, ki vam omogočajo združevanje strežniške in preklopne opreme v eno skupino virov, upravljanje ti viri, ki zagotavljajo potrebno raven tolerance napak.
V času pisanja tega gradiva je struktura OpenStack videti takole:
Slika posneta iz
Vsaka komponenta, vključena v OpenStack, opravlja določeno funkcijo. Ta porazdeljena arhitektura vam omogoča, da v rešitev vključite nabor funkcionalnih komponent, ki jih potrebujete. Vendar so nekatere komponente korenske komponente in njihova odstranitev povzroči popolno ali delno nedelovanje celotne rešitve. Te komponente so običajno razvrščene kot:
- Splošno — Spletni GUI za upravljanje storitev OpenStack
- Keystone je centralizirana storitev identitete, ki zagotavlja funkcijo preverjanja pristnosti in avtorizacije za druge storitve ter upravljanje uporabniških poverilnic in njihovih vlog.
- Nevtron - omrežna storitev, ki omogoča povezljivost med vmesniki različnih storitev OpenStack (vključno s povezljivostjo med VM in njihovim dostopom do zunanjega sveta)
- Cinder — omogoča dostop do blokovnega pomnilnika za virtualne stroje
- Nova — upravljanje življenjskega cikla virtualnih strojev
- Pogled — repozitorij slik in posnetkov virtualnih strojev
- Swift — omogoča dostop do shranjevalnega objekta
- Ceilometer — storitev, ki omogoča zbiranje telemetrije in merjenje razpoložljivih in porabljenih virov
- Toplota — orkestracija na podlagi predlog za samodejno ustvarjanje in zagotavljanje virov
Ogledate si lahko celoten seznam vseh projektov in njihov namen .
Vsaka komponenta OpenStack je storitev, ki izvaja določeno funkcijo in ponuja API za upravljanje te funkcije in interakcijo z drugimi storitvami operacijskega sistema v oblaku za ustvarjanje enotne infrastrukture. Na primer, Nova zagotavlja upravljanje računalniških virov in API za dostop do konfiguracije teh virov, Glance zagotavlja upravljanje slik in API za njihovo upravljanje, Cinder zagotavlja shranjevanje blokov in API za njihovo upravljanje itd. Vse funkcije so med seboj zelo tesno povezane.
Vendar, če pogledate, so vse storitve, ki se izvajajo v OpenStacku, navsezadnje neke vrste virtualni stroj (ali vsebnik), povezan z omrežjem. Postavlja se vprašanje - zakaj potrebujemo toliko elementov?
Oglejmo si algoritem za ustvarjanje virtualnega stroja in njegovo povezavo z omrežjem in trajnim pomnilnikom v Openstacku.
- Ko ustvarite zahtevo za ustvarjanje stroja, pa naj gre za zahtevo prek Horizon (nadzorna plošča) ali zahtevo prek CLI, je prva stvar, ki se zgodi, avtorizacija vaše zahteve na Keystoneu – ali lahko ustvarite stroj, ali ima pravico do uporabe tega omrežja, ali vaš osnutek kvote itd.
- Keystone preveri pristnost vaše zahteve in v odgovoru ustvari žeton za avtentifikacijo, ki bo uporabljen naprej. Po prejemu odgovora Keystonea se zahteva pošlje Novi (nova api).
- Nova-api preveri veljavnost vaše zahteve tako, da se obrne na Keystone z uporabo predhodno ustvarjenega žetona za avtorizacijo
- Keystone izvaja preverjanje pristnosti in zagotavlja informacije o dovoljenjih in omejitvah na podlagi tega žetona za preverjanje pristnosti.
- Nova-api ustvari vnos za nov VM v nova-database in posreduje zahtevo za ustvarjanje stroja v nova-scheduler.
- Nova-scheduler izbere gostitelja (računalniško vozlišče), na katerem bo nameščen VM, na podlagi podanih parametrov, uteži in con. Zapis o tem in ID VM se zapišeta v bazo podatkov nova.
- Nato se nova-scheduler obrne na nova-compute z zahtevo za uvedbo primerka. Nova-compute kontaktira nova-conductor, da pridobi informacije o strojnih parametrih (nova-conductor je element nova, ki deluje kot proxy strežnik med nova-database in nova-compute, kar omejuje število zahtev do nova-database, da se izogne težavam z bazo podatkov zmanjšanje obremenitve konsistence).
- Nova-conductor prejme zahtevane informacije iz nova-database in jih posreduje nova-compute.
- Nato nova-compute pokliče pogled, da pridobi ID slike. Glace potrdi zahtevo v Keystone in vrne zahtevane informacije.
- Nova-compute vzpostavi stik z nevtronom, da pridobi informacije o parametrih omrežja. Podobno kot glance tudi neutron potrdi zahtevo v Keystoneu, nato ustvari vnos v bazi podatkov (identifikator vrat itd.), ustvari zahtevo za ustvarjanje vrat in vrne zahtevane informacije v nova-compute.
- Nova-compute naveže stike z zahtevo za dodelitev nosilca virtualnemu stroju. Podobno kot glance tudi cider potrdi zahtevo v Keystoneu, ustvari zahtevo za ustvarjanje nosilca in vrne zahtevane informacije.
- Nova-compute se obrne na libvirt z zahtevo za uvedbo virtualnega stroja z navedenimi parametri.
Pravzaprav se na videz preprosta operacija ustvarjanja preprostega virtualnega stroja spremeni v vrtinec klicev API med elementi platforme v oblaku. Poleg tega, kot lahko vidite, so tudi predhodno določene storitve sestavljene iz manjših komponent, med katerimi pride do interakcije. Ustvarjanje stroja je le majhen del tega, kar vam omogoča platforma v oblaku - obstaja storitev, odgovorna za uravnoteženje prometa, storitev, odgovorna za shranjevanje blokov, storitev, odgovorna za DNS, storitev, odgovorna za zagotavljanje golih strežnikov itd. Oblak vam omogoča, da svoje virtualne stroje obravnavate kot čredo ovac (v nasprotju z virtualizacijo). Če se vašemu stroju kaj zgodi v virtualnem okolju - obnovite ga iz varnostnih kopij itd., vendar so aplikacije v oblaku zgrajene tako, da virtualni stroj ne igra tako pomembne vloge - virtualni stroj je "umrl" - ni problema - novo je preprosto ustvarjeno, vozilo temelji na predlogi in, kot pravijo, ekipa ni opazila izgube borca. Seveda to zagotavlja prisotnost mehanizmov za orkestracijo - s predlogami Heat lahko enostavno uvedete kompleksno funkcijo, ki jo sestavljajo desetine omrežij in virtualnih strojev.
Vedno velja imeti v mislih, da oblačne infrastrukture ni brez omrežja – vsak element na tak ali drugačen način komunicira z drugimi elementi prek omrežja. Poleg tega ima oblak popolnoma nestatično omrežje. Seveda je osnovno omrežje še bolj ali manj statično - nova vozlišča in stikala se ne dodajajo vsak dan, vendar se prekrivna komponenta lahko in se bo neizogibno nenehno spreminjala - nova omrežja bodo dodana ali izbrisana, pojavili se bodo novi virtualni stroji in stari umreti. In kot se spomnite iz definicije oblaka, podane na samem začetku članka, bi morali biti viri uporabniku dodeljeni samodejno in z najmanj (ali še bolje, brez) posredovanja ponudnika storitev. To pomeni, da vrsta zagotavljanja omrežnih virov, ki zdaj obstaja v obliki sprednjega dela v obliki vašega osebnega računa, dostopnega prek http/https, in dežurnega omrežnega inženirja Vasilija kot zaledja, ni oblak, niti če ima Vasilij osem rok.
Neutron kot omrežna storitev zagotavlja API za upravljanje omrežnega dela infrastrukture v oblaku. Storitev poganja in upravlja omrežni del Openstacka z zagotavljanjem abstraktne plasti, imenovane Network-as-a-Service (NaaS). To pomeni, da je omrežje enaka navidezna merljiva enota kot na primer navidezna jedra procesorja ali količina RAM-a.
Toda preden preidemo na arhitekturo omrežnega dela OpenStacka, razmislimo, kako to omrežje deluje v OpenStacku in zakaj je omrežje pomemben in sestavni del oblaka.
Tako imamo dva RDEČA odjemalska VM in dva ZELENA odjemalska VM. Predpostavimo, da so ti stroji nameščeni na dveh hipervizorjih na ta način:
Trenutno je to le virtualizacija 4 strežnikov in nič več, saj smo do sedaj naredili samo virtualizacijo 4 strežnikov, ki smo jih postavili na dva fizična strežnika. In zaenkrat niso niti povezani v omrežje.
Za izdelavo oblaka moramo dodati več komponent. Najprej virtualiziramo omrežni del - te 4 stroje moramo povezati v pare, odjemalci pa želijo povezavo L2. Uporabite lahko stikalo in konfigurirate deblo v njegovi smeri ter rešite vse z uporabo linux bridge ali, za naprednejše uporabnike, openvswitch (k temu se bomo vrnili kasneje). Toda omrežij je lahko veliko in nenehno potiskanje L2 prek stikala ni najboljša ideja - obstajajo različni oddelki, servisna miza, meseci čakanja na dokončanje aplikacije, tedni odpravljanja težav - v sodobnem svetu je to pristop ne deluje več. In prej ko podjetje to razume, lažje gre naprej. Zato bomo med hipervizorji izbrali omrežje L3, prek katerega bodo naši virtualni stroji komunicirali, na vrhu tega omrežja L3 pa bomo zgradili virtualna prekrivna omrežja L2, kjer bo potekal promet naših virtualnih strojev. Kot enkapsulacijo lahko uporabite GRE, Geneve ali VxLAN. Osredotočimo se zaenkrat na slednje, čeprav ni posebej pomembno.
Nekje moramo najti VTEP (upam, da vsi poznajo terminologijo VxLAN). Ker imamo omrežje L3, ki prihaja naravnost iz strežnikov, nam nič ne preprečuje, da bi VTEP postavili na same strežnike, in OVS (OpenvSwitch) je odličen pri tem. Kot rezultat smo dobili ta dizajn:
Ker mora biti promet med virtualnimi stroji razdeljen, bodo imela vrata proti virtualnim strojem različne številke vlan. Številka oznake igra vlogo le znotraj enega navideznega stikala, saj jo, ko je inkapsulirana v VxLAN, zlahka odstranimo, saj bomo imeli VNI.
Zdaj lahko brez težav ustvarimo naše stroje in virtualna omrežja zanje.
Kaj pa, če ima odjemalec drugo napravo, vendar je v drugem omrežju? Potrebujemo rootanje med omrežji. Ogledali si bomo preprosto možnost, ko se uporablja centralizirano usmerjanje - to je, da se promet usmerja skozi posebna namenska omrežna vozlišča (no, praviloma so kombinirana z nadzornimi vozlišči, tako da bomo imeli isto).
Zdi se, da ni nič zapletenega - naredimo mostni vmesnik na nadzornem vozlišču, napeljemo promet do njega in od tam ga usmerimo, kamor ga potrebujemo. Toda težava je v tem, da RDEČI odjemalec želi uporabljati omrežje 10.0.0.0/24, ZELENI odjemalec pa želi uporabljati omrežje 10.0.0.0/24. To pomeni, da začnemo sekati naslovne prostore. Poleg tega odjemalci ne želijo, da bi drugi odjemalci lahko usmerjali v njihova notranja omrežja, kar je smiselno. Da bi ločili omrežja in podatkovni promet odjemalcev, bomo vsakemu od njih dodelili ločen imenski prostor. Imenski prostor je pravzaprav kopija omrežnega sklada Linuxa, kar pomeni, da so odjemalci v imenskem prostoru RED popolnoma izolirani od odjemalcev iz imenskega prostora GREEN (no, usmerjanje med temi odjemalskimi omrežji je dovoljeno prek privzetega imenskega prostora ali na navzgornji transportni opremi).
To pomeni, da dobimo naslednji diagram:
Tuneli L2 konvergirajo od vseh računalniških vozlišč do nadzornega vozlišča. vozlišče, kjer se nahaja vmesnik L3 za ta omrežja, vsako v namenskem imenskem prostoru za izolacijo.
Vendar smo pozabili na najpomembnejše. Virtualni stroj mora odjemalcu zagotavljati storitev, to pomeni, da mora imeti vsaj en zunanji vmesnik, preko katerega je dosegljiv. To pomeni, da moramo iti ven v zunanji svet. Tukaj so različne možnosti. Naredimo najpreprostejšo možnost. Vsakemu odjemalcu bomo dodali eno omrežje, ki bo veljalo v omrežju ponudnika in se ne bo prekrivalo z drugimi omrežji. Omrežja se lahko tudi sekajo in gledajo različne VRF-je na strani omrežja ponudnika. Omrežni podatki bodo živeli tudi v imenskem prostoru vsakega odjemalca. Vendar pa bodo še vedno šli v zunanji svet prek enega fizičnega (ali vezi, kar je bolj logično) vmesnika. Za ločevanje prometa odjemalca bo promet, ki gre zunaj, označen z oznako VLAN, dodeljeno odjemalcu.
Kot rezultat smo dobili ta diagram:
Razumno vprašanje je, zakaj ne bi naredili prehodov na samih računalniških vozliščih? To ni velik problem, poleg tega, če vklopite distribuirani usmerjevalnik (DVR), bo to delovalo. V tem scenariju razmišljamo o najpreprostejši možnosti s centraliziranim prehodom, ki se privzeto uporablja v Openstacku. Za visoko obremenjene funkcije bodo uporabljali tako porazdeljeni usmerjevalnik kot pospeševalne tehnologije, kot sta SR-IOV in Passthrough, a kot pravijo, je to povsem druga zgodba. Najprej se posvetimo osnovnemu delu, nato pa se poglobimo v podrobnosti.
Pravzaprav je naša shema že izvedljiva, vendar obstaja nekaj odtenkov:
- Naše stroje moramo nekako zaščititi, torej postaviti filter na stikalni vmesnik proti odjemalcu.
- Omogočite, da virtualni stroj samodejno pridobi naslov IP, da se vam ne bo treba vsakič prijaviti vanj prek konzole in registrirati naslova.
Začnimo z zaščito stroja. Za to lahko uporabite banalne iptables, zakaj pa ne.
Se pravi, zdaj je naša topologija postala nekoliko bolj zapletena:
Gremo naprej. Dodati moramo strežnik DHCP. Najbolj idealno mesto za iskanje strežnikov DHCP za vsakega odjemalca bi bilo zgoraj omenjeno nadzorno vozlišče, kjer se nahajajo imenski prostori:
Vendar pa obstaja majhen problem. Kaj pa, če se vse znova zažene in vse informacije o zakupu naslovov na DHCP izginejo. Logično je, da bodo stroji dobili nove naslove, kar ni zelo priročno. Tukaj sta dva izhoda - ali uporabimo domenska imena in dodamo DNS strežnik za vsakega odjemalca, takrat nam naslov ne bo posebej pomemben (podobno kot omrežni del v k8s) - vendar je problem z zunanjimi omrežji, saj naslove je mogoče izdati v njih tudi preko DHCP - potrebujete sinhronizacijo z DNS strežniki v oblačni platformi in zunanjim DNS strežnikom, kar po mojem mnenju ni preveč prilagodljivo, je pa povsem mogoče. Ali pa je druga možnost uporaba metapodatkov - to je shranjevanje informacij o naslovu, izdanem stroju, tako da strežnik DHCP ve, kateri naslov izdati stroju, če je stroj že prejel naslov. Druga možnost je enostavnejša in bolj prilagodljiva, saj omogoča shranjevanje dodatnih podatkov o avtomobilu. Zdaj pa dodamo metapodatke agenta v diagram:
Drugo vprašanje, o katerem je prav tako vredno razpravljati, je zmožnost uporabe enega zunanjega omrežja za vse odjemalce, saj bodo zunanja omrežja, če morajo veljati v celotnem omrežju, težavna - morate nenehno dodeljevati in nadzorovati dodeljevanje teh omrežij. Možnost uporabe enega samega zunanjega vnaprej konfiguriranega omrežja za vse odjemalce bo zelo koristna pri ustvarjanju javnega oblaka. To bo olajšalo uvajanje strojev, ker se nam ni treba posvetovati z zbirko podatkov o naslovih in izbrati edinstven naslovni prostor za zunanje omrežje vsakega odjemalca. Poleg tega lahko vnaprej registriramo zunanje omrežje in v času uvajanja bomo morali samo povezati zunanje naslove z odjemalskimi stroji.
In tukaj nam na pomoč priskoči NAT - odjemalcem bomo le omogočili dostop do zunanjega sveta prek privzetega imenskega prostora z uporabo prevoda NAT. No, tukaj je majhna težava. To je dobro, če odjemalski strežnik deluje kot odjemalec in ne kot strežnik - to pomeni, da iniciira in ne sprejema povezav. Pri nas pa bo ravno obratno. V tem primeru moramo narediti ciljni NAT, tako da nadzorno vozlišče ob prejemu prometa razume, da je ta promet namenjen virtualnemu stroju A odjemalca A, kar pomeni, da moramo narediti prevod NAT z zunanjega naslova, na primer 100.1.1.1 .10.0.0.1, na notranji naslov 100. Čeprav bodo v tem primeru vsi odjemalci uporabljali isto omrežje, se notranja izolacija popolnoma ohrani. To pomeni, da moramo narediti dNAT in sNAT na nadzornem vozlišču. Ali boste uporabili eno omrežje s plavajočimi naslovi ali zunanja omrežja ali oboje hkrati, je odvisno od tega, kaj želite prenesti v oblak. V diagram ne bomo dodajali plavajočih naslovov, ampak bomo pustili prej dodana zunanja omrežja - vsak odjemalec ima svoje zunanje omrežje (v diagramu so označeni kot vlan 200 in XNUMX na zunanjem vmesniku).
Kot rezultat smo dobili zanimivo in hkrati dobro premišljeno rešitev, ki ima določeno fleksibilnost, vendar še nima mehanizmov tolerance napak.
Prvič, imamo samo eno nadzorno vozlišče - njegova okvara bo povzročila propad vseh sistemov. Če želite odpraviti to težavo, morate sestaviti vsaj kvorum 3 vozlišč. Dodajmo to v diagram:
Seveda so vsa vozlišča sinhronizirana in ko aktivno vozlišče zapusti, bo drugo vozlišče prevzelo njegove odgovornosti.
Naslednja težava so diski virtualnih strojev. Trenutno so shranjeni na samih hipervizorjih in v primeru težav s hipervizorjem izgubimo vse podatke - in prisotnost raida tukaj ne bo pomagala, če izgubimo ne disk, ampak celoten strežnik. Da bi to naredili, moramo narediti storitev, ki bo delovala kot front end za nekakšno shranjevanje. Za kakšno shrambo bo šlo, nam ni posebej pomembno, naj pa zaščiti naše podatke pred odpovedjo tako diska kot vozlišča in morda celotne omare. Tu je več možnosti - seveda obstajajo omrežja SAN z optičnim kanalom, vendar bodimo iskreni - FC je že relikt preteklosti - analog E1 v prometu - ja, strinjam se, še vedno se uporablja, vendar le tam, kjer brez tega nikakor ne gre. Zato leta 2020 ne bi prostovoljno uvedel omrežja FC, saj vem, da obstajajo druge bolj zanimive alternative. Čeprav vsak po svoje, morda obstajajo tisti, ki verjamejo, da je FC z vsemi svojimi omejitvami vse, kar potrebujemo - ne bom se prepiral, vsak ima svoje mnenje. Vendar je po mojem mnenju najbolj zanimiva rešitev uporaba SDS, kot je Ceph.
Ceph vam omogoča, da zgradite visoko razpoložljivo rešitev za shranjevanje podatkov s kopico možnih možnosti varnostnega kopiranja, začenši s kodami s preverjanjem paritete (analogno raidu 5 ali 6) in konča s popolno replikacijo podatkov na različne diske, ob upoštevanju lokacije diskov v strežniki in strežniki v omarah itd.
Če želite zgraditi Ceph, potrebujete še 3 vozlišča. Interakcija s shrambo bo potekala tudi prek omrežja s storitvami za shranjevanje blokov, objektov in datotek. Dodajmo shrambo v shemo:
Opomba: ustvarite lahko tudi hiperkonvergirana računalniška vozlišča - to je koncept združevanja več funkcij na enem vozlišču - na primer shranjevanje+računanje - brez namenitve posebnih vozlišč za shranjevanje ceph. Dobili bomo enako shemo, ki je tolerantna na napake - saj bo SDS rezerviral podatke s stopnjo rezervacije, ki jo določimo. Hiperkonvergirana vozlišča pa so vedno kompromis - ker skladiščno vozlišče ne greje le zraka, kot se zdi na prvi pogled (ker na njem ni navideznih strojev) - porablja sredstva CPU za servisiranje SDS (pravzaprav počne vse podvajanje in obnovitev po okvarah vozlišč, diskov itd.). To pomeni, da boste izgubili nekaj moči računalniškega vozlišča, če ga združite s shranjevanjem.
Vse te stvari je treba nekako upravljati - potrebujemo nekaj, s čimer lahko ustvarimo stroj, omrežje, virtualni usmerjevalnik itd. Da bi to naredili, bomo v nadzorno vozlišče dodali storitev, ki bo delovala kot nadzorna plošča - odjemalec se bo lahko povezal na ta portal preko http/ https in naredil vse kar potrebuje (no, skoraj).
Posledično imamo zdaj sistem, odporen na napake. Vse elemente te infrastrukture je treba nekako upravljati. Prej je bilo opisano, da je Openstack niz projektov, od katerih vsak zagotavlja določeno funkcijo. Kot vidimo, je elementov, ki jih je treba konfigurirati in nadzorovati, več kot dovolj. Danes bomo govorili o omrežnem delu.
Nevtronska arhitektura
V OpenStacku je Neutron odgovoren za povezovanje vrat navideznega stroja s skupnim omrežjem L2, zagotavljanje usmerjanja prometa med VM-ji, ki se nahajajo v različnih omrežjih L2, kot tudi usmerjanje navzven, zagotavljanje storitev, kot so NAT, plavajoči IP, DHCP itd.
Na visoki ravni lahko delovanje omrežne storitve (osnovnega dela) opišemo takole.
Ob zagonu VM omrežna storitev:
- Ustvari vrata za dani VM (ali vrata) in o tem obvesti storitev DHCP;
- Ustvari se nova virtualna omrežna naprava (prek libvirt);
- VM se poveže z vrati, ustvarjenimi v 1. koraku;
Nenavadno je, da Neutronovo delo temelji na standardnih mehanizmih, ki jih poznajo vsi, ki so se kdaj potopili v Linux - imenski prostori, iptables, linux mostovi, openvswitch, conntrack itd.
Takoj je treba pojasniti, da Neutron ni krmilnik SDN.
Nevtron je sestavljen iz več med seboj povezanih komponent:
Openstack-neutron-strežnik je demon, ki deluje z uporabniškimi zahtevami prek API-ja. Ta demon ni vključen v registracijo nobenih omrežnih povezav, ampak zagotavlja potrebne informacije za to svojim vtičnikom, ki nato konfigurirajo želeni omrežni element. Agenti Neutron na vozliščih OpenStack se registrirajo na strežniku Neutron.
Neutron-server je pravzaprav aplikacija, napisana v pythonu, sestavljena iz dveh delov:
- Storitev REST
- Vtičnik Neutron (jedro/storitev)
Storitev REST je zasnovana za sprejemanje klicev API-ja iz drugih komponent (na primer zahteva za posredovanje nekaterih informacij itd.)
Vtičniki so komponente/moduli programske opreme vtičnikov, ki se kličejo med zahtevami API – to pomeni, da prek njih pride do dodelitve storitve. Vtičniki so razdeljeni na dve vrsti - servisni in korenski. Konjski vtičnik je praviloma odgovoren predvsem za upravljanje naslovnega prostora in L2 povezav med VM-ji, storitveni vtičniki pa že zagotavljajo dodatne funkcionalnosti, kot sta VPN ali FW.
Seznam vtičnikov, ki so danes na voljo, si lahko ogledate na primer
Storitvenih vtičnikov je lahko več, lahko pa je samo en konjski vtičnik.
openstack-neutron-ml2 je standardni korenski vtičnik Openstack. Ta vtičnik ima modularno arhitekturo (za razliko od svojega predhodnika) in konfigurira omrežno storitev prek gonilnikov, povezanih z njim. Sam vtičnik si bomo ogledali malo kasneje, saj pravzaprav daje fleksibilnost, ki jo ima OpenStack v omrežnem delu. Korenski vtičnik je mogoče zamenjati (tako zamenjavo na primer naredi Contrail Networking).
Storitev RPC (strežnik rabbitmq) — storitev, ki zagotavlja upravljanje čakalne vrste in interakcijo z drugimi storitvami OpenStack ter interakcijo med agenti omrežnih storitev.
Omrežni agenti — agenti, ki se nahajajo v vsakem vozlišču, preko katerega se konfigurirajo omrežne storitve.
Poznamo več vrst agentov.
Glavni agent je agent L2. Ti agenti se izvajajo na vsakem od hipervizorjev, vključno z nadzornimi vozlišči (natančneje, na vseh vozliščih, ki zagotavljajo kakršne koli storitve za najemnike) in njihova glavna funkcija je povezovanje virtualnih strojev v skupno omrežje L2 ter ustvarjanje opozoril, ko pride do kakršnih koli dogodkov ( na primer onemogoči/omogoči vrata).
Naslednji, nič manj pomemben agent je agent L3. Privzeto se ta agent izvaja izključno na omrežnem vozlišču (pogosto je omrežno vozlišče kombinirano z nadzornim vozliščem) in zagotavlja usmerjanje med omrežji najemnikov (med svojimi omrežji in omrežji drugih najemnikov ter je dostopen zunanjemu svetu, kar zagotavlja NAT, kot tudi storitev DHCP). Pri uporabi DVR (distribuiranega usmerjevalnika) pa se potreba po vtičniku L3 pojavi tudi na računalniških vozliščih.
Agent L3 uporablja imenske prostore Linux, da vsakemu najemniku zagotovi nabor lastnih izoliranih omrežij in funkcionalnost navideznih usmerjevalnikov, ki usmerjajo promet in zagotavljajo storitve prehodov za omrežja 2. plasti.
Baze podatkov — zbirka podatkov o identifikatorjih omrežij, podomrežij, vrat, bazenov itd.
Pravzaprav Neutron sprejema zahteve API-ja od ustvarjanja katere koli omrežne entitete, preverja pristnost zahteve in prek RPC (če dostopa do nekega vtičnika ali agenta) ali REST API (če komunicira v SDN) posreduje agentom (prek vtičnikov) navodila, potrebna za organizacijo zahtevane storitve.
Zdaj pa se obrnemo na testno namestitev (kako je nameščena in kaj je vanjo vključeno, bomo videli kasneje v praktičnem delu) in poglejmo, kje se nahaja vsaka komponenta:
(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 ~]$
Pravzaprav je to celotna struktura Neutrona. Zdaj je vredno porabiti nekaj časa za vtičnik ML2.
Modularna plast 2
Kot je navedeno zgoraj, je vtičnik standardni korenski vtičnik OpenStack in ima modularno arhitekturo.
Predhodnik vtičnika ML2 je imel monolitno strukturo, ki na primer ni dovoljevala uporabe mešanice več tehnologij v eni namestitvi. Na primer, ne morete uporabljati obeh openvswitch in linuxbridge hkrati - bodisi prvega bodisi drugega. Iz tega razloga je bil ustvarjen vtičnik ML2 s svojo arhitekturo.
ML2 ima dve komponenti – dve vrsti gonilnikov: gonilnike tipa in gonilnike mehanizma.
Vrsta gonilnikov določiti tehnologije, ki bodo uporabljene za organizacijo omrežnih povezav, na primer VxLAN, VLAN, GRE. Voznik hkrati omogoča uporabo različnih tehnologij. Standardna tehnologija je enkapsulacija VxLAN za prekrivna omrežja in zunanja omrežja vlan.
Tipski gonilniki vključujejo naslednje vrste omrežij:
Stanovanje - omrežje brez označevanja
VLAN - označeno omrežje
Lokalno — posebna vrsta omrežja za namestitve vse v enem (take namestitve so potrebne bodisi za razvijalce bodisi za usposabljanje)
GRE — prekrivanje omrežja z uporabo tunelov GRE
VxLAN — prekrivanje omrežja z uporabo tunelov VxLAN
Gonilniki mehanizma definirajte orodja, ki zagotavljajo organizacijo tehnologij, določenih v gonilniku tipa - na primer openvswitch, sr-iov, opendaylight, OVN itd.
Odvisno od implementacije tega gonilnika bodo uporabljeni bodisi agenti, ki jih nadzoruje Neutron, ali pa bodo uporabljene povezave z zunanjim krmilnikom SDN, ki skrbi za vsa vprašanja v zvezi z organizacijo omrežij L2, usmerjanjem itd.
Primer: če uporabljamo ML2 skupaj z OVS, potem je na vsako računalniško vozlišče, ki upravlja OVS, nameščen agent L2. Če pa uporabljamo na primer OVN ali OpenDayLight, potem je nadzor OVS v njihovi pristojnosti - Neutron prek korenskega vtičnika daje ukaze krmilniku, ta pa že naredi, kar mu je bilo naročeno.
Osvežimo Open vSwitch
Trenutno je ena ključnih komponent OpenStacka Open vSwitch.
Pri namestitvi OpenStacka brez dodatnega SDN-ja ponudnika, kot sta Juniper Contrail ali Nokia Nuage, je OVS glavna omrežna komponenta omrežja v oblaku in vam skupaj z iptables, conntrack, imenskimi prostori omogoča organiziranje polnopravnih prekrivnih omrežij z več najemniki. Seveda je to komponento mogoče zamenjati, na primer pri uporabi lastniških (prodajalcev) rešitev SDN tretjih oseb.
OVS je odprtokodno programsko stikalo, ki je zasnovano za uporabo v virtualiziranih okoljih kot virtualni posrednik prometa.
Trenutno ima OVS zelo spodobno funkcionalnost, ki vključuje tehnologije, kot so QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK itd.
Opomba: OVS sprva ni bil zasnovan kot mehko stikalo za visoko obremenjene telekomunikacijske funkcije in je bil bolj zasnovan za manj pasovno zahtevne IT funkcije, kot sta spletni strežnik ali poštni strežnik. Vendar se OVS še naprej razvija in trenutne implementacije OVS so močno izboljšale njegovo delovanje in zmogljivosti, kar omogoča, da ga uporabljajo telekomunikacijski operaterji z zelo obremenjenimi funkcijami, na primer obstaja implementacija OVS s podporo za pospeševanje DPDK.
Obstajajo tri pomembne komponente OVS, ki se jih morate zavedati:
- Modul jedra — komponenta, ki se nahaja v prostoru jedra, ki obdeluje promet na podlagi pravil, prejetih od nadzornega elementa;
- vSwitch daemon (ovs-vswitchd) je proces, zagnan v uporabniškem prostoru, ki je odgovoren za programiranje modula jedra - to pomeni, da neposredno predstavlja logiko delovanja stikala
- Strežnik baz podatkov - lokalna baza podatkov, ki se nahaja na vsakem gostitelju, ki izvaja OVS, v kateri je shranjena konfiguracija. Krmilniki SDN lahko komunicirajo prek tega modula z uporabo protokola OVSDB.
Vse to spremlja nabor diagnostičnih in upravljalskih pripomočkov, kot so ovs-vsctl, ovs-appctl, ovs-ofctl itd.
Trenutno Openstack široko uporabljajo telekomunikacijski operaterji za selitev omrežnih funkcij, kot so EPC, SBC, HLR itd. Nekatere funkcije lahko brez težav živijo z OVS, kakršen je, toda na primer EPC obdeluje naročniški promet – nato gre skozi ogromno prometa (zdaj obseg prometa dosega nekaj sto gigabitov na sekundo). Seveda vožnja takšnega prometa skozi prostor jedra (ker je posrednik privzeto nameščen tam) ni najboljša ideja. Zato je OVS pogosto v celoti nameščen v uporabniškem prostoru s tehnologijo pospeševanja DPDK za posredovanje prometa iz omrežne kartice v uporabniški prostor mimo jedra.
Opomba: za oblak, razporejen za telekomunikacijske funkcije, je možno posredovati promet iz računalniškega vozlišča mimo OVS neposredno na preklopno opremo. V ta namen se uporabljajo mehanizmi SR-IOV in Passthrough.
Kako to deluje na resnični postavitvi?
No, zdaj pa preidimo na praktični del in poglejmo, kako vse skupaj deluje v praksi.
Najprej namestimo preprosto namestitev Openstack. Ker nimam pri roki nabora strežnikov za eksperimente, bomo prototip sestavili na enem fizičnem strežniku iz virtualnih strojev. Da, seveda takšna rešitev ni primerna za komercialne namene, a če si ogledate primer delovanja omrežja v Openstacku, je takšna namestitev dovolj za oči. Poleg tega je takšna namestitev še bolj zanimiva za namene usposabljanja - saj lahko ujamete promet itd.
Ker moramo videti samo osnovni del, ne moremo uporabljati več omrežij, ampak dvignemo vse samo z dvema omrežjema, drugo omrežje v tej postavitvi pa bo namenjeno izključno dostopu do podoblaka in DNS strežnika. Zunanjih omrežij se za zdaj ne bomo dotikali - to je tema za ločen velik članek.
Pa začnimo po vrsti. Najprej malo teorije. Openstack bomo namestili s pomočjo TripleO (Openstack na Openstack). Bistvo TripleO je v tem, da namestimo Openstack all-in-one (torej na eno vozlišče), imenovano undercloud, nato pa z zmožnostmi razporejenega Openstacka namestimo Openstack namenjen delovanju, imenovan overcloud. Undercloud bo uporabil svojo inherentno zmožnost upravljanja fizičnih strežnikov (bare metal) – projekt Ironic – za zagotavljanje hipervizorjev, ki bodo izvajali vloge računalniških, nadzornih in pomnilniških vozlišč. To pomeni, da za uvajanje Openstacka ne uporabljamo nobenih orodij tretjih oseb - Openstack uvajamo z uporabo Openstacka. Ko bo namestitev napredovala, bo postalo veliko bolj jasno, zato se ne bomo ustavili pri tem in šli naprej.
Opomba: V tem članku zaradi poenostavitve nisem uporabil omrežne izolacije za notranja omrežja Openstack, ampak je vse nameščeno samo z enim omrežjem. Prisotnost ali odsotnost omrežne izolacije pa ne vpliva na osnovno funkcionalnost rešitve – vse bo delovalo popolnoma enako kot pri uporabi izolacije, vendar bo promet tekel po istem omrežju. Za komercialno namestitev je seveda potrebna uporaba izolacije z uporabo različnih vlanov in vmesnikov. Na primer promet za upravljanje shranjevanja ceph in sam podatkovni promet (strojni dostop do diskov itd.), kadar sta izolirana, uporabljata različna podomrežja (upravljanje shranjevanja in shranjevanje), kar vam omogoča, da naredite rešitev bolj odporno na napake, tako da razdelite ta promet, npr. , prek različnih vrat ali z uporabo različnih profilov QoS za različen promet, tako da podatkovni promet ne iztisne signalnega prometa. V našem primeru bodo šli na isto omrežje in pravzaprav nas to v ničemer ne omejuje.
Opomba: ker bomo izvajali virtualne stroje v virtualnem okolju, ki temelji na virtualnih strojih, moramo najprej omogočiti ugnezdeno virtualizacijo.
Ali je ugnezdena virtualizacija omogočena ali ne, lahko preverite tako:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Če vidite črko N, potem omogočamo podporo za ugnezdeno virtualizacijo v skladu s katerim koli vodnikom, ki ga najdete v omrežju, npr. .
Iz virtualnih strojev moramo sestaviti naslednje vezje:
V mojem primeru sem za povezovanje navideznih strojev, ki so del prihodnje namestitve (in dobil sem jih 7, vendar lahko preživite s 4, če nimate veliko sredstev), uporabil OpenvSwitch. Ustvaril sem en ovs most in nanj povezal virtualne stroje prek skupin vrat. Da bi to naredil, sem ustvaril datoteko xml, kot je ta:
[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>Tu so deklarirane tri skupine vrat - dve dostopni in ena trunk (slednja je bila potrebna za strežnik DNS, vendar lahko brez njega ali pa jo namestite na gostiteljski stroj - kar vam bolj ustreza). Nato z uporabo te predloge razglasimo našo prek virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Zdaj urejamo konfiguracije vrat hipervizorja:
[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 ~]# Opomba: v tem scenariju naslov na vratih ovs-br1 ne bo dostopen, ker nima oznake vlan. Če želite to popraviti, morate izdati ukaz sudo ovs-vsctl set port ovs-br1 tag=100. Po ponovnem zagonu pa bo ta oznaka izginila (če kdo ve, kako naj ostane na svojem mestu, bom zelo hvaležen). Vendar to ni tako pomembno, saj bomo ta naslov potrebovali samo med namestitvijo in ga ne bomo potrebovali, ko bo Openstack v celoti nameščen.
Nato ustvarimo podoblačni stroj:
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=ttyS0Med namestitvijo nastaviš vse potrebne parametre, kot so ime stroja, gesla, uporabniki, ntp strežniki itd., takoj lahko konfiguriraš vrata, ampak meni osebno se po namestitvi lažje prijavim v stroj preko konzolo in popravite potrebne datoteke. Če že imate pripravljeno sliko, jo lahko uporabite ali naredite, kar sem naredil jaz - prenesite minimalno sliko Centos 7 in jo uporabite za namestitev VM.
Po uspešni namestitvi bi morali imeti virtualni stroj, na katerega lahko namestite undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningNajprej namestite orodja, potrebna za postopek namestitve:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud namestitev
Ustvarimo uporabnika sklada, nastavimo geslo, ga dodamo v sudoer in mu damo možnost izvajanja korenskih ukazov prek sudo, ne da bi moral vnesti geslo:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackZdaj določimo celotno ime podoblaka v datoteki hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Nato dodamo repozitorije in namestimo programsko opremo, ki jo potrebujemo:
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-ansibleOpomba: če ne nameravate namestiti ceph, vam ni treba vnesti ukazov, povezanih s cephom. Uporabil sem izdajo Queens, vendar lahko uporabite katero koli drugo, ki vam je všeč.
Nato kopirajte konfiguracijsko datoteko Undercloud v sklad domačega imenika uporabnika:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confZdaj moramo to datoteko popraviti in jo prilagoditi naši namestitvi.
Te vrstice morate dodati na začetek datoteke:
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 = 10Torej, pojdimo skozi nastavitve:
undercloud_ime_gostitelja — polno ime strežnika Undercloud se mora ujemati z vnosom na strežniku DNS
lokalni_ip — lokalni podoblačni naslov proti zagotavljanju omrežja
network_gateway — isti lokalni naslov, ki bo med namestitvijo vozlišč overcloud deloval kot prehod za dostop do zunanjega sveta, sovpada tudi z lokalnim ip
undercloud_public_host — zunanji naslov API, dodeljen je kateri koli prosti naslov iz omrežja za zagotavljanje
undercloud_admin_host notranji naslov API, je dodeljen kateri koli prosti naslov iz omrežja za zagotavljanje
undercloud_nameservers - DNS strežnik
generiraj_certifikat_storitve - ta vrstica je v trenutnem primeru zelo pomembna, ker če je ne nastavite na false, boste med namestitvijo prejeli napako, težava je opisana v sledilniku napak Red Hat
lokalni_vmesnik vmesnik pri zagotavljanju omrežja. Ta vmesnik bo na novo konfiguriran med uvedbo UnderCloud, zato morate imeti dva vmesnika UnderCloud - enega za dostop do njega, drugega za oskrbo
local_mtu — MTU. Ker imamo testni laboratorij in imam MTU 1500 na vratih stikala OVS, ga je treba nastaviti na 1450, da lahko paketi, inkapsulirani v VxLAN, prehajajo skozi
network_cidr — zagotavljanje omrežja
Maškarada — uporaba NAT za dostop do zunanjega omrežja
maškaradno_omrežje - omrežje, ki bo NATed
dhcp_start — začetni naslov skupine naslovov, iz katerega bodo naslovi dodeljeni vozliščem med uvedbo overclouda
dhcp_end — končni naslov skupine naslovov, iz katerega bodo naslovi dodeljeni vozliščem med uvedbo overclouda
pregled_iprange — zbirka naslovov, potrebnih za introspekcijo (ne sme se prekrivati z zgornjo skupino)
razporejevalnik_max_poskusov — največje število poskusov namestitve overclouda (mora biti večje ali enako številu vozlišč)
Ko je datoteka opisana, lahko podate ukaz za namestitev Undercloud:
openstack undercloud install
Postopek traja od 10 do 30 minut, odvisno od vašega železa. Na koncu bi morali videti takšen rezultat:
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.
#############################################################################Ta izhod pravi, da ste uspešno namestili Undercloud in zdaj lahko preverite status Undercloud ter nadaljujete z namestitvijo Overcloud.
Če pogledate izhod ifconfig, boste videli, da se je pojavil nov mostni vmesnik
[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 0Uvedba Overcloud bo zdaj izvedena prek tega vmesnika.
Iz spodnjega rezultata lahko vidite, da imamo vse storitve na enem vozlišču:
(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 |
+--------------------------+-----------+----------+Spodaj je konfiguracija dela omrežja pod oblakom:
(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 ~]$Namestitev Overcloud
Trenutno imamo samo podoblak, nimamo pa dovolj vozlišč, iz katerih bi sestavili nadoblak. Zato najprej razmestimo virtualne stroje, ki jih potrebujemo. Undercloud bo med uvedbo sam namestil OS in potrebno programsko opremo na overcloud stroj - to pomeni, da nam stroja ni treba popolnoma uvesti, ampak le ustvariti disk (ali diske) zanj in določiti njegove parametre - tj. , pravzaprav dobimo goli strežnik brez nameščenega operacijskega sistema.
Pojdimo v mapo z diski naših virtualnih strojev in ustvarimo diske zahtevane velikosti:
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 160GKer delujemo kot root, moramo spremeniti lastnika teh diskov, da ne bi imeli težav s pravicami:
[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]# Opomba: če ne nameravate namestiti ceph, da bi ga preučili, potem ukazi ne ustvarijo vsaj 3 vozlišč z vsaj dvema diskoma, ampak v predlogi navedejo, da bodo uporabljeni virtualni diski vda, vdb itd.
Super, zdaj moramo definirati vse te stroje:
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 Na koncu je ukaz -print-xml > /tmp/storage-1.xml, ki ustvari datoteko xml z opisom posameznega stroja v mapi /tmp/, če je ne dodate, ne boste sposobni prepoznati virtualne stroje.
Zdaj moramo vse te stroje definirati v virsh:
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 ~]#Zdaj majhen odtenek - tripleO uporablja IPMI za upravljanje strežnikov med namestitvijo in introspekcijo.
Introspekcija je postopek pregledovanja strojne opreme, da se pridobijo njeni parametri, potrebni za nadaljnjo oskrbo vozlišč. Introspekcija se izvaja z ironic, storitvijo, zasnovano za delo z golimi strežniki.
Toda tukaj je težava - medtem ko imajo strežniki strojne opreme IPMI ločena vrata (ali vrata v skupni rabi, vendar to ni pomembno), virtualni stroji nimajo takih vrat. Tu nam na pomoč priskoči bergla, imenovana vbmc - pripomoček, ki omogoča posnemanje vrat IPMI. Na ta odtenek je vredno biti pozoren predvsem za tiste, ki želijo vzpostaviti tak laboratorij na hipervizorju ESXI - če sem iskren, ne vem, ali ima analog vbmc, zato se je vredno vprašati o tem vprašanju, preden vse uvedete .
Namestite vbmc:
yum install yum install python2-virtualbmcČe vaš OS ne najde paketa, dodajte repozitorij:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmZdaj smo postavili pripomoček. Tu je vse banalno do sramote. Zdaj je logično, da na seznamu vbmc ni strežnikov
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Da se prikažejo, jih je treba ročno deklarirati takole:
[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 ~]#Mislim, da je sintaksa ukaza jasna brez razlage. Vendar so zaenkrat vse naše seje v NEDOLOČENEM statusu. Da se premaknejo v stanje UP, jih morate omogočiti:
[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 ~]#In zadnji dotik - popraviti morate pravila požarnega zidu (ali ga popolnoma onemogočiti):
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
Zdaj pa pojdimo v Undercloud in preverimo, ali vse deluje. Naslov gostiteljskega stroja je 192.168.255.200, na Undercloud smo dodali potreben paket ipmitool med pripravo na namestitev:
[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 runningKot lahko vidite, smo uspešno zagnali nadzorno vozlišče prek vbmc. Zdaj pa ga izklopimo in nadaljujemo:
[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 ~]#Naslednji korak je introspekcija vozlišč, na katerih bo nameščen overcloud. Za to moramo pripraviti datoteko json z opisom naših vozlišč. Upoštevajte, da za razliko od namestitve na golih strežnikih datoteka označuje vrata, na katerih se izvaja vbmc za vsak računalnik.
[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:27Opomba: krmilno vozlišče ima dva vmesnika, vendar v tem primeru to ni pomembno, v tej namestitvi nam bo eden dovolj.
Zdaj pripravimo datoteko json. Navesti moramo mak naslov vrat, prek katerih se bo izvajalo oskrbovanje, parametre vozlišč, jim dati imena in navesti, kako priti do ipmi:
{
"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"
}
]
}Zdaj moramo pripraviti slike za ironijo. Če želite to narediti, jih prenesite prek wget in namestite:
(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 ~]$Nalaganje slik v Undercloud:
(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 ~]$Preverjanje, ali so se naložile vse slike
(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 ~]$Še ena stvar - dodati morate DNS strežnik:
(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 ~]$Zdaj lahko damo ukaz za introspekcijo:
(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 ~]$Kot lahko vidite iz rezultatov, je vse potekalo brez napak. Preverimo, ali so vsa vozlišča v razpoložljivem stanju:
(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 ~]$ Če so vozlišča v drugačnem stanju, običajno obvladljiva, je šlo nekaj narobe in morate pogledati dnevnik in ugotoviti, zakaj se je to zgodilo. Upoštevajte, da v tem scenariju uporabljamo virtualizacijo in lahko pride do napak, povezanih z uporabo virtualnih strojev ali vbmc.
Nato moramo navesti, katero vozlišče bo opravljalo katero funkcijo - to je navesti profil, s katerim bo vozlišče uvedeno:
(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 ~]$Določite profil za vsako vozlišče:
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-d9afb69d1167Preverimo, ali smo vse naredili pravilno:
(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 ~]$Če je vse pravilno, damo ukaz za namestitev overclouda:
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 qemuV resnični namestitvi bodo seveda uporabljene prilagojene predloge, v našem primeru bo to zelo zapletlo postopek, saj bo treba vsako urejanje v predlogi pojasniti. Kot je bilo že napisano, bo že preprosta namestitev dovolj, da vidimo, kako deluje.
Opomba: v tem primeru je potrebna spremenljivka qemu tipa --libvirt, saj bomo uporabili ugnezdeno virtualizacijo. V nasprotnem primeru ne boste mogli zagnati virtualnih strojev.
Sedaj imate približno eno uro ali morda več (odvisno od zmogljivosti strojne opreme) in samo upate lahko, da boste po tem času videli naslednje sporočilo:
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 ~]$Zdaj imate skoraj popolno različico openstacka, na kateri se lahko učite, eksperimentirate itd.
Preverimo, ali vse deluje pravilno. V skladu uporabnikovega domačega imenika sta dve datoteki - ena stackrc (za upravljanje podoblaka) in druga overcloudrc (za upravljanje nad oblaka). Te datoteke je treba navesti kot vir, saj vsebujejo informacije, potrebne za avtentikacijo.
(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 ~]$Moja namestitev še vedno zahteva en majhen dotik - dodajanje poti na krmilniku, saj je stroj, s katerim delam, v drugem omrežju. Če želite to narediti, pojdite na control-1 pod računom heat-admin in registrirajte pot
(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.254No, zdaj lahko greš v obzorje. Vsi podatki - naslovi, prijava in geslo - so v datoteki /home/stack/overcloudrc. Končni diagram izgleda takole:
Mimogrede, v naši namestitvi so bili naslovi stroja izdani prek DHCP in, kot lahko vidite, so izdani "naključno". V predlogi lahko natančno določite, kateri naslov naj bo priložen kateremu stroju med uvedbo, če ga potrebujete.
Kako poteka promet med virtualnimi stroji?
V tem članku si bomo ogledali tri možnosti za prehod prometa
- Dva stroja na enem hipervizorju v enem omrežju L2
- Dva stroja na različnih hipervizorjih v istem omrežju L2
- Dva stroja v različnih omrežjih (koreninjenje med omrežjem)
Primere z dostopom do zunanjega sveta prek zunanjega omrežja, uporabo plavajočih naslovov, pa tudi porazdeljenega usmerjanja bomo obravnavali naslednjič, za zdaj se bomo osredotočili na notranji promet.
Za preverjanje sestavimo naslednji diagram:
Ustvarili smo 4 virtualne stroje - 3 na enem omrežju L2 - net-1 in še 1 na omrežju net-2
(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 ~]$ Poglejmo, na katerih hipervizorjih se nahajajo ustvarjeni stroji:
(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 ~]$
Stroji vm-1 in vm-3 se nahajajo na compute-0, stroji vm-2 in vm-4 se nahajajo na vozlišču compute-1.
Poleg tega je bil ustvarjen navidezni usmerjevalnik, ki omogoča usmerjanje med navedenimi omrežji:
(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 ~]$ Usmerjevalnik ima dva virtualna vrata, ki delujejo kot prehodi za omrežja:
(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 ~]$ Toda preden pogledamo, kako teče promet, poglejmo, kaj trenutno imamo na nadzornem vozlišču (ki je tudi omrežno vozlišče) in na računalniškem vozlišču. Začnimo z računalniškim vozliščem.
[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 ~]$Trenutno ima vozlišče tri ovs mostove - br-int, br-tun, br-ex. Med njimi, kot vidimo, obstaja niz vmesnikov. Za lažje razumevanje narišite vse te vmesnike na diagramu in poglejte, kaj se zgodi.
Če pogledamo naslove, na katere so dvignjeni tuneli VxLAN, je razvidno, da je en tunel dvignjen na compute-1 (192.168.255.26), drugi tunel pa na control-1 (192.168.255.15). Toda najbolj zanimivo je, da br-ex nima fizičnih vmesnikov in če pogledate, kateri tokovi so konfigurirani, lahko vidite, da lahko ta most trenutno samo spusti promet.
[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 ~]$ Kot lahko vidite iz izhoda, je naslov privit neposredno na fizična vrata in ne na vmesnik virtualnega mostu.
[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 ~]$
Po prvem pravilu je treba zavreči vse, kar je prišlo iz pristanišča phy-br-ex.
Pravzaprav trenutno ni nikjer drugje za promet na ta most, razen iz tega vmesnika (vmesnik z br-int) in sodeč po padcih je BUM promet že stekel na most.
To pomeni, da lahko promet zapusti to vozlišče samo skozi tunel VxLAN in nič drugega. Če pa vklopite DVR, se bo situacija spremenila, a o tem bomo drugič. Pri uporabi omrežne izolacije, na primer z uporabo vlan, ne boste imeli enega vmesnika L3 v vlan 0, ampak več vmesnikov. Vendar bo promet VxLAN zapustil vozlišče na enak način, vendar tudi enkapsuliran v nekakšen namenski vlan.
Razvrstili smo računalniško vozlišče, pojdimo k nadzornemu vozlišču.
[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 ~]$Pravzaprav lahko rečemo, da je vse po starem, le da naslov IP ni več na fizičnem vmesniku, temveč na virtualnem mostu. To se naredi zato, ker so ta vrata vrata, skozi katera bo promet izstopal v zunanji svet.
[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 ~]$ Ta vrata so povezana z mostom br-ex in ker na njih ni oznak vlan, so ta vrata trunk vrata, na katerih so dovoljeni vsi vlani, zdaj gre promet zunaj brez oznake, kot je označeno z vlan-id 0 v izpis zgoraj.
Vse ostalo je trenutno podobno računalniškemu vozlišču – isti mostovi, isti tuneli, ki vodijo do dveh računalniških vozlišč.
V tem članku ne bomo obravnavali vozlišč za shranjevanje, vendar je za razumevanje potrebno povedati, da je omrežni del teh vozlišč banalen do sramote. V našem primeru obstaja samo ena fizična vrata (eth0) z dodeljenim naslovom IP in to je to. Ni tunelov VxLAN, tunelskih mostov itd. - sploh ni ovs, saj v tem nima smisla. Pri uporabi omrežne izolacije bo imelo to vozlišče dva vmesnika (fizična vrata, bodny ali samo dva vlana - ni pomembno - odvisno kaj želite) - enega za upravljanje, drugega za promet (pisanje na disk VM , branje z diska itd.)
Ugotovili smo, kaj imamo na vozliščih, če ni nobenih storitev. Zdaj pa zaženimo 4 virtualne stroje in poglejmo, kako se spremeni zgoraj opisana shema - morali bi imeti vrata, virtualne usmerjevalnike itd.
Zaenkrat naše omrežje izgleda takole:
Na vsakem računalniškem vozlišču imamo dva virtualna stroja. Na primeru compute-0 poglejmo, kako je vse vključeno.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Stroj ima samo en virtualni vmesnik - 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 ~]$
Ta vmesnik izgleda v mostu linux:
[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 ~]$ Kot lahko vidite iz izhoda, sta v mostu samo dva vmesnika - tap95d96a75-a0 in qvb95d96a75-a0.
Tukaj se je vredno malo posvetiti vrstam virtualnih omrežnih naprav v OpenStacku:
vtap - virtualni vmesnik, pritrjen na instanco (VM)
qbr - most za Linux
qvb in qvo - par vEth, povezan z mostom Linux in mostom Open vSwitch
br-int, br-tun, br-vlan — Odprite mostove vSwitch
patch-, int-br-, phy-br- - Open vSwitch patch vmesniki, ki povezujejo mostove
qg, qr, ha, fg, sg - Odprite vrata vSwitch, ki jih uporabljajo virtualne naprave za povezavo z OVS
Kot razumete, če imamo v mostu vrata qvb95d96a75-a0, ki je par vEth, potem nekje obstaja njegov dvojnik, ki bi se moral logično imenovati qvo95d96a75-a0. Poglejmo, katera vrata so na OVS.
[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 ~]$ Kot lahko vidimo, je pristanišče v br-int. Br-int deluje kot stikalo, ki prekine vrata navideznega stroja. Poleg qvo95d96a75-a0 so v izhodu vidna vrata qvo5bd37136-47. To so vrata do drugega virtualnega stroja. Posledično je naš diagram zdaj videti takole:
Vprašanje, ki bi moralo takoj zanimati pozornega bralca - kakšen je linuxov most med vrati virtualnega stroja in vrati OVS? Dejstvo je, da se za zaščito stroja uporabljajo varnostne skupine, ki niso nič drugega kot iptables. OVS ne deluje z iptables, zato je bila ta "bergla" izumljena. Vendar postaja zastarel - v novih izdajah ga nadomešča conntrack.
To pomeni, da na koncu shema izgleda takole:
Dva stroja na enem hipervizorju v enem omrežju L2
Ker se ta dva VM nahajata v istem omrežju L2 in na istem hipervizorju, bo promet med njima logično potekal lokalno prek br-int, saj bosta oba stroja v istem VLAN:
[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 ~]$ Dva stroja na različnih hipervizorjih v istem omrežju L2
Zdaj pa poglejmo, kako bo potekal promet med dvema strojema v istem omrežju L2, vendar na različnih hipervizorjih. Če sem iskren, se ne bo nič veliko spremenilo, samo promet med hipervizorji bo potekal skozi tunel vxlan. Poglejmo si primer.
Naslovi virtualnih strojev, med katerimi bomo spremljali promet:
[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 ~]$ Ogledamo si tabelo za posredovanje v br-int na compute-0:
[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 ~]Promet bi moral iti na vrata 2 - poglejmo, kakšna vrata so:
[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 ~]$To je patch-tun - to je vmesnik v br-tun. Poglejmo, kaj se zgodi s paketom na br-tun:
[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 ~]$ Paket je zapakiran v VxLAN in poslan na vrata 2. Poglejmo, kam vodijo vrata 2:
[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 ~]$To je tunel vxlan na compute-1:
[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 ~]$Pojdimo na compute-1 in poglejmo, kaj se bo zgodilo s paketom:
[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 ~]$ Mac je v tabeli posredovanja br-int na compute-1 in kot je razvidno iz zgornjega izhoda, je viden skozi vrata 2, ki so vrata proti br-tun:
[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:46No, potem vidimo, da je v br-int na compute-1 ciljni mak:
[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 ~]$ To pomeni, da bo prejeti paket letel do vrat 3, za katerimi že obstaja primerek virtualnega stroja-00000003.
Lepota uvajanja Openstacka za učenje na virtualni infrastrukturi je v tem, da lahko preprosto zajamemo promet med hipervizorji in vidimo, kaj se z njim dogaja. To je tisto, kar bomo storili zdaj, zaženite tcpdump na vratih vnet proti compute-0:
[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*******************Prva vrstica kaže, da gre Patek z naslova 10.0.1.85 na naslov 10.0.1.88 (promet ICMP) in je zavit v paket VxLAN z vni 22, paket pa gre od gostitelja 192.168.255.19 (compute-0) do gostitelja 192.168.255.26 .1 (izračunaj-XNUMX). Lahko preverimo, ali se VNI ujema s tistim, navedenim v ovs.
Vrnimo se k tej vrstici actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 je vni v šestnajstiškem številskem sistemu. Pretvorimo to število v 16. sistem:
16 = 6*16^0+1*16^1 = 6+16 = 22Se pravi, vni ustreza realnosti.
Druga vrstica prikazuje povratni promet, no, nima smisla razlagati, tam je vse jasno.
Dva stroja v različnih omrežjih (medomrežno usmerjanje)
Zadnji primer za danes je usmerjanje med omrežji znotraj enega projekta z uporabo virtualnega usmerjevalnika. Razmišljamo o primeru brez DVR-ja (ogledali si ga bomo v drugem članku), zato se usmerjanje zgodi v omrežnem vozlišču. V našem primeru omrežno vozlišče ni postavljeno v ločeno entiteto in se nahaja na nadzornem vozlišču.
Najprej poglejmo, ali usmerjanje deluje:
$ 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 msKer mora v tem primeru paket iti do prehoda in biti tja usmerjen, moramo ugotoviti naslov MAC prehoda, za kar pogledamo tabelo ARP v primeru:
$ 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 eth0Zdaj pa poglejmo, kam naj se pošlje promet z destinacijo (10.0.1.254) fa:16:3e:c4:64:70:
[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 ~]$ Poglejmo, kam vodijo vrata 2:
[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 ~]$ Vse je logično, promet gre na br-tun. Poglejmo, v kateri tunel vxlan bo zavit:
[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 ~]$ Tretja vrata so tunel vxlan:
[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 ~]$ Ki gleda na kontrolno vozlišče:
[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 ~]$ Promet je dosegel kontrolno vozlišče, zato moramo iti do njega in videti, kako bo potekalo usmerjanje.
Kot se spomnite, je bilo kontrolno vozlišče v notranjosti videti popolnoma enako kot računalniško vozlišče - enaki trije mostovi, samo br-ex je imel fizična vrata, skozi katera je vozlišče lahko pošiljalo promet ven. Ustvarjanje instanc je spremenilo konfiguracijo na računalniških vozliščih - vozliščem so bili dodani linux bridge, iptables in vmesniki. Ustvarjanje omrežij in virtualnega usmerjevalnika je pustilo pečat tudi pri konfiguraciji krmilnega vozlišča.
Torej je očitno, da mora biti naslov MAC prehoda v tabeli za posredovanje br-int na nadzornem vozlišču. Preverimo, ali je tam in kam išče:
[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 ~]$ Mac je viden iz vrat qr-0c52b15f-8f. Če se vrnemo na seznam virtualnih vrat v Openstacku, se ta vrsta vrat uporablja za povezavo različnih virtualnih naprav z OVS. Natančneje, qr so vrata za virtualni usmerjevalnik, ki je predstavljen kot imenski prostor.
Poglejmo, kateri imenski prostori so na strežniku:
[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 ~]$ Kar trije izvodi. Toda sodeč po imenih lahko uganete namen vsakega od njih. K primerkom z ID-jem 0 in 1 se bomo vrnili pozneje, zdaj nas zanima imenski prostor qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[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 ~]$ Ta imenski prostor vsebuje dva notranja, ki smo ju ustvarili prej. Obe virtualni vrati sta bili dodani v br-int. Preverimo mac naslov vrat qr-0c52b15f-8f, saj je promet, sodeč po ciljnem mac naslovu, šel na ta vmesnik.
[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 ~]$ To pomeni, da v tem primeru vse deluje v skladu z zakoni standardnega usmerjanja. Ker je promet namenjen gostitelju 10.0.2.8, mora zapustiti drugi vmesnik qr-92fa49b5-54 in iti skozi tunel vxlan do računalniškega vozlišča:
[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 ~]$ Vse je logično, brez presenečenj. Poglejmo, kje je v br-int viden poppy naslov gostitelja 10.0.2.8:
[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 ~]$ Po pričakovanjih promet poteka v smeri br-tun, poglejmo v kateri predor poteka naslednji promet:
[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 ~]$ Promet gre v predor za izračun-1. No, na compute-1 je vse preprosto - od br-tun gre paket do br-int in od tam do vmesnika virtualnega stroja:
[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 ~]$ Preverimo, ali je to res pravi vmesnik:
[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 ~]$
Pravzaprav smo šli skozi celoten paket. Mislim, da ste opazili, da je promet potekal skozi različne tunele vxlan in izstopal z različnimi VNI. Poglejmo, kakšne vrste VNI so to, nato pa bomo zbrali odlagališče na kontrolnih vratih vozlišča in se prepričali, da promet teče točno tako, kot je opisano zgoraj.
Torej ima tunel za izračun-0 naslednja dejanja=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Pretvorimo 0x16 v decimalni številski sistem:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Predor za izračun-1 ima naslednje VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Pretvorimo 0x63 v decimalni številski sistem:
0x63 = 3*16^0+6*16^1 = 3+96 = 99No, zdaj pa poglejmo smetišče:
[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*******************Prvi paket je paket vxlan od gostitelja 192.168.255.19 (compute-0) do gostitelja 192.168.255.15 (control-1) z vni 22, znotraj katerega je zapakiran paket ICMP od gostitelja 10.0.1.85 do gostitelja 10.0.2.8. Kot smo izračunali zgoraj, se vni ujema s tem, kar smo videli v izhodu.
Drugi paket je paket vxlan od gostitelja 192.168.255.15 (control-1) do gostitelja 192.168.255.26 (compute-1) z vni 99, znotraj katerega je zapakiran paket ICMP od gostitelja 10.0.1.85 do gostitelja 10.0.2.8. Kot smo izračunali zgoraj, se vni ujema s tem, kar smo videli v izhodu.
Naslednja dva paketa sta povratni promet iz 10.0.2.8 in ne 10.0.1.85.
To pomeni, da smo na koncu dobili naslednjo shemo krmilnega vozlišča:
Izgleda, da je to to? Pozabili smo na dva imenska prostora:
[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 ~]$ Kot smo govorili o arhitekturi platforme v oblaku, bi bilo dobro, če bi stroji samodejno prejemali naslove s strežnika DHCP. To sta dva strežnika DHCP za naši dve omrežji 10.0.1.0/24 in 10.0.2.0/24.
Preverimo, ali je to res. V tem imenskem prostoru je samo en naslov - 10.0.1.1 - naslov samega strežnika DHCP in je vključen tudi v br-int:
[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 0Poglejmo, ali procesi, ki v svojem imenu vsebujejo qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 v nadzornem vozlišču:
[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 ~]$ Obstaja tak postopek in na podlagi informacij, predstavljenih v zgornjem izpisu, lahko na primer vidimo, kaj imamo trenutno za najem:
[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 ~]$Kot rezultat dobimo naslednji nabor storitev na nadzornem vozlišču:
No, ne pozabite - to so samo 4 stroji, 2 notranji omrežji in en navidezni usmerjevalnik ... Tukaj zdaj nimamo zunanjih omrežij, kup različnih projektov, vsak s svojimi omrežji (prekrivajočimi se), in imamo porazdeljeni usmerjevalnik se je izklopil in na koncu Konec koncev je bilo v preskusni napravi samo eno krmilno vozlišče (za toleranco napak mora obstajati kvorum treh vozlišč). Logično je, da je v trgovini vse “malo” bolj zapleteno, a v tem preprostem primeru razumemo, kako bi moralo delovati - ali imate 3 ali 300 imenskih prostorov je seveda pomembno, a z vidika delovanja celotnega struktura, nič se ne bo veliko spremenilo ... čeprav dokler ne boste priklopili nekega ponudnika SDN. A to je povsem druga zgodba.
Upam, da je bilo zanimivo. Če imate pripombe/dopolnitve ali pa sem kje čisto lagal (sem človek in moje mnenje bo vedno subjektivno) - napišite, kaj je treba popraviti/dodati - vse bomo popravili/dodali.
Za zaključek bi rad povedal nekaj besed o primerjavi Openstacka (tako vanilla kot prodajalca) z rešitvijo v oblaku podjetja VMWare – to vprašanje so mi v zadnjih nekaj letih postavljali prepogosto in, odkrito povedano, že naveličani, a vseeno. Po mojem mnenju je zelo težko primerjati ti dve rešitvi, vsekakor pa lahko rečemo, da imata obe rešitvi slabosti in pri izbiri ene rešitve je treba pretehtati prednosti in slabosti.
Če je OpenStack rešitev, ki jo vodi skupnost, potem ima VMWare pravico delati samo tisto, kar hoče (beri - tisto, kar se mu splača) in to je logično - ker je komercialno podjetje, ki je navajeno služiti denar od svojih strank. Obstaja pa en velik in debel AMPAK - lahko se izstopite iz OpenStacka, na primer pri Nokii, in z majhnimi stroški preidete na rešitev iz na primer Juniperja (Contrail Cloud), VMWare pa verjetno ne boste uspeli. . Pri meni ti dve rešitvi izgledata takole - Openstack (prodajalec) je enostavna kletka v katero te dajo, a imaš ključ in lahko kadarkoli odideš. VMWare je zlata kletka, lastnik ima ključ od kletke in to vas bo veliko stalo.
Ne promoviram ne prvega ne drugega izdelka - sami izberite, kar potrebujete. A če bi imel tako izbiro, bi izbral obe rešitvi - VMWare za IT oblak (nizke obremenitve, enostavno upravljanje), OpenStack kakšnega prodajalca (Nokia in Juniper ponujata zelo dobre rešitve na ključ) - za Telekomov oblak. Openstacka ne bi uporabljal za čisti IT - to je kot streljanje vrabcev s topom, vendar ne vidim drugih kontraindikacij za uporabo, razen redundance. Vendar je uporaba VMWare v telekomunikacijah podobna prevažanju drobljenih kamnov v Fordu Raptorju – od zunaj je čudovit, vendar mora voznik opraviti 10 voženj namesto ene.
Po mojem mnenju je največja pomanjkljivost VMWare njegova popolna zaprtost - podjetje vam ne bo dalo nobenih informacij o tem, kako deluje, na primer vSAN ali kaj je v jedru hipervizorja - to mu preprosto ni dobičkonosno - to pomeni, da boste nikoli ne postanite strokovnjak za VMWare – brez podpore proizvajalca ste obsojeni na propad (zelo pogosto srečam strokovnjake za VMWare, ki jih begajo nepomembna vprašanja). Zame VMWare kupi avto z zaklenjeno havbo - ja, morda imaš specialiste, ki lahko zamenjajo zobati jermen, ampak samo tisti, ki ti je prodal to rešitev, lahko odpre haubo. Osebno ne maram rešitev, v katere se ne morem vklopiti. Rekli boste, da vam morda ne bo treba iti pod pokrov. Da, to je možno, vendar te bom pogledal, ko boš moral sestaviti veliko funkcijo v oblaku iz 20-30 virtualnih strojev, 40-50 omrežij, od katerih jih polovica želi iti ven, druga polovica pa zahteva Pospešek SR-IOV, sicer boste potrebovali več nekaj ducatov teh avtomobilov - sicer zmogljivost ne bo dovolj.
Obstajajo tudi drugačna stališča, zato se lahko samo vi odločite, kaj boste izbrali, in kar je najpomembneje, potem boste odgovorni za svojo izbiro. To je samo moje mnenje - osebe, ki je videla in se dotaknila vsaj 4 izdelkov - Nokia, Juniper, Red Hat in VMWare. Se pravi, imam s čim primerjati.
Vir: www.habr.com