Sissejuhatus pilvetehnoloogia võrguosa

Pilveteenus muutub üha enam meie ellu ja tõenäoliselt ei ole ühtegi inimest, kes poleks kunagi kasutanud mõnda pilveteenust. Kuid mis täpselt on pilv ja kuidas see enamasti töötab, teab vähesed isegi ideetasemel. 5G on juba reaalsus ja telekomiinfrastruktuur hakkab liikuma traditsioonilistest lahendustest pilvepõhistesse, sarnaselt sellele, kuidas ta liikuda hakkas täielikult raudsetest lahendustest virtualiseeritud 'tugidele'.

Täna räägime pilvetehnoloogia sisemusest, eriti uurime võrguosa aluseid.

Mis on pilv? Kas see on lihtsalt virtualiseerimine — profiilis?

Seda on täiesti loogiline küsida. Ei — see ei ole virtualiseerimine, kuigi ilma selleta ei saa. Uurime kahte määret:

Pilveteenused (edaspidi Pilv) — on kasutajasõbralik ligipääs jaotatud arvutusressurssidele, mis peaksid olema juurutatud ja käivitatud nõudmisel võimalikult väikese latentsusaja ja teenusepakkuja poolt minimaalsete kuludega.

Virtualiseerimine — on võimalus jagada üks füüsiline entiteet (näiteks server) mitmeks virtuaalseks, suurendades seeläbi ressursside kasutust (näiteks kui sul oli 3 serverit, mis olid koormatud 25-30 protsenti, saad pärast virtualiseerimist 1 serveri, mis on koormatud 80-90 protsenti). Loomulikult nõuab virtualiseerimine osa ressursse — sul tuleb toita hüperviisorit, kuid nagu praktika on näidanud, tasub see vaeva. Ideaalne näide virtualiseerimisest on VMWare, mis valmistab suurepäraselt ette virtuaalmachinesid, või näiteks KVM, mis on mulle rohkem meeltmööda, kuid see juba sõltub maitsest.

Me kasutame ise virtualiseerimist, kellelegi arusaamatuks, ja isegi füüsilised ruuterid kasutavad juba virtualiseerimist — näiteks uusimates JunOS versioonides installitakse operatsioonisüsteem virtuaalmasinana reaalajas Linuxi distributsiooni (Wind River 9) peale. Kuid virtualiseerimine ei ole pilv, kuid pilv ei saa eksisteerida ilma virtualiseerimiseta.

Virtualiseerimine on üks kividest, millele pilv toetub.

Pilvede loomine, ühendades mitu hüperviisorit ühte L2 domeeni, lisades paar yaml mängutegevust VLAN-ide automaatseks seadistamiseks mõne ansible abil ja katma selle kõigega midagi orkestreerimissüsteemi, et automaatselt luua virtuaalmasinaid — ei toimi. Täpsemalt öeldes töötab see, kuid saadud Frankensteini - ei ole see pilv, mida me vajame, ehkki kellegile võib see olla unistuste tipp. Lisaks, kui võtta näiteks OpenStack - on see põhimõtteliselt samuti Frankensteini loom, aga las olla, ärme praegu sellest räägi.

Aga ma mõistan, et eespool toodud määratlus ei selgita päris hästi, mida tegelikult saab nimetada pilveks.

Seetõttu toob NIST (National Institute of Standards and Technology) dokumendis välja 5 põhijoonet, mida pilveinfrastruktuur peab omama:

Teenuse pakkumine nõudmisel. Kasutajale peab olema tagatud vaba juurdepääs talle eraldatud arvutusressurssidele (nt võrgud, virtuaalsed kettad, mälud, protsessorite tuumad jne), ja need ressursid peavad olema automaatselt kergesti kättesaadavad - st ilma teenusepakkuja sekkumiseta.

Teenuse lai juurdepääsetavus. Ressurssidele peab olema juurdepääs tagatud standardsete mehhanismide kaudu, et kasutada nii tavalisi personaalarvuteid, õhukesi kliente kui ka mobiilseid seadmeid.

Ressursside koondamine basseinidesse. Ressursside basseinid peavad tagama samal ajal ressursside jagamise mitme kliendi vahel, tagades klientide eraldatuse ja nende vahelise konkurentsi puudumise ressursside osas. Basseinidesse kuuluvad ka võrgud, mis näitab võimalust kasutada ühiselt adresseerimist. Basseinid peavad toetama skaleerimist nõudmisel. Basseinide kasutamine võimaldab tagada vajalikul määral ressursside töökindlust ja füüsiliste ja virtuaalsete ressursside abstraheerimist - teenuse saajale antakse lihtsalt soovitud ressursside komplekt (kus need ressursid füüsiliselt asuvad, mitmetel serveritel ja lülititel - kliendile pole see oluline). Siiski tuleb arvestada sellega, et teenusepakkuja peab tagama nende ressursside läbilaskva varundamise.

Kiire kohandumine erinevatesse tingimustesse. Teenused peavad olema paindlikud — kiire ressursside pakkumine, nende ümberjaotamine, ressursside lisamine või vähendamine kliendi soovil, samas kui kliendil peaks olema tunne, et pilv kui selline on lõputu. Üksikasjade lihtsustamiseks, näiteks, te ei näe hoiatusi selle kohta, et teie Apple iCloudis on kadunud osa kettaruumi, kuna serveris on kõvaketas rikki läinud, kuid kettaid ju juhtub. Samuti on teie poolt teenuse võimalused praktiliselt piiramatu — kui vajate 2 TB — pole probleemi, maksate ja saate. Sarnaselt võib tuua näite Google.Drive või Yandex.Disk'i kohta.

Teenuse pakkumise mõõtmise võimalus. Pilvesüsteemid peavad automaatsete arveid ja optimeerima kasutatavaid ressursse, samas peavad need mehhanismid olema läbipaistvad nii kasutajale kui ka teenusepakkujale. See tähendab, et te alati saate kontrollida, kui palju ressursse teie ja teie kliendid kasutavad.

Tasub arvestada, et need nõuded on enamasti nõuded avaliku pilve jaoks, seetõttu võivad need nõuded privaatse pilve (st pilve, mis on käivitatud ettevõtte sisemiseks kasutuseks) korral olla mõnevõrra kohandatud. Kuid need peavad siiski olema täidetud, vastasel juhul ei saa me kõiki pilvearvutuse eeliseid.

Miks me vajame pilve?

Kuid iga uus või juba olemasolev tehnoloogia, iga uus protokoll luuakse mingi põhjusel (välja arvatud RIP-ng, muidugi). Protokoll protokolli pärast — ei huvita kedagi (välja arvatud RIP-ng, muidugi). On loogiline, et Pilv luuakse, et pakkuda mingit teenust kasutajale/kliendile. Me kõik oleme tuttavad vähemalt paari pilveteenusega, näiteks Dropbox või Google.Docs ja ma usun, et enamik inimesi kasutab neid edukalt — näiteks see artikkel on kirjutatud Google.Docs'i pilveteenuse abil. Kuid tuntud pilveteenused on vaid osa pilve võimalustest — täpsemalt on need vaid SaaS tüüpi teenused. Pilveteenuse pakkumiseks saame kasutada kolme teed: SaaS, PaaS või IaaS. Milline teenus on just teile vajalik, sõltub teie soovidest ja võimalustest.

Käime igaühe läbi järjestikku:

Tarkvara teenus (SaaS) — see on kliendile täisteenuse pakkumise mudel, näiteks posti teenus nagu Yandex.Mail või Gmail. Sellise teenuse pakkumise mudeli korral ei tee te kui klient tegelikult midagi muud, kui kasutate teenust — see tähendab, et te ei pea mõtlema teenuse seadistamisele, selle talitlushäired või varundusele. Peamine on mitte oma parooli lõhuda, kõik muu teeb teie eest teenusepakkuja. Teenusepakkuja vaatenurgast vastutab ta täielikult kogu teenuse eest — alates serveri riistvarast ja hostimise operatsioonisüsteemidest kuni andmebaaside ja tarkvara seadistusteni.

Platvorm teenusena (PaaS) — selle mudeli kasutamisel pakub teenusepakkuja kliendile teenuse jaoks mallide komplekti, võtame näiteks veebiserveri. Teenusepakkuja on andnud kliendile virtuaalse serveri (tegelikult komplekti ressursse, nagu RAM/CPU/Säilitus/Võrgud jne), ning isegi installinud sellele serverile operatsioonisüsteemi ja vajaliku tarkvara, kuid kogu selle korralduse eest vastutab juba klient ning teenuse töökindluse eest vastutab samuti klient. Teenusepakkuja, nagu eelmisel korral, vastutab füüsilise riistvara, hüperviisorite, virtuaalmasina ja selle võrguühenduse töökindluse eest jne, kuid teenus ise jääb juba tema vastutusest välja.

Infrastruktuur teenusena (IaaS) — see lähenemine on juba huvitavam, sest teenusepakkuja pakub kliendile täielikku virtualiseeritud infrastruktuuri — tegelikult mingit komplekti (pools) ressursse, nagu CPU tuumad, RAM, võrgud jne. Kõik muu on kliendi asi — mida klient nende ressurssidega vajab teha eraldatud punkti (kvota) raames, teenusepakkujale eriti ei koti. Kui klient soovib luua omaenda vEPC või isegi luua mini operaatori ja pakkuda side teenuseid — pole probleemi — tee. Sellise stsenaariumi korral vastutab teenusepakkuja ressursside pakkumise, nende töökindluse ja kättesaadavuse ning ka operatsioonisüsteemi eest, mis võimaldab nende ressursside ühendamist ja nende pakkumist kliendile koos võimalusega igal ajal ressursse suurendada või vähendada kliendi nõudmisel. Kõik virtuaalsed masinad ja muu kraam seadistab klient ise läbi eneseteenindusportaali ja konsoli, sealhulgas ka võrkude määramine (väliste võrkude välja arvatud).

Mis on OpenStack?

Kõigis kolmes variandis vajab teenusepakkuja opsüsteemi, mis võimaldab luua pilveinfrastruktuuri. Tegelikult vastutab SaaS-i puhul kogu tehnoloogia stacki eest mitte üks osakond — on osakond, mis vastutab infrastruktuuri eest — see tähendab, et see pakub IaaS-i teisele osakonnale, see osakond pakub klientidele SaaS-i. OpenStack on üks pilve opsüsteem, mis võimaldab ühendada palju lüliteid, servereid ja salvestussüsteeme ühtseks ressursibaasiks, jagada seda ühine baasi osakuudeks (tenantideks) ja pakkuda neid ressursse klientidele võrgu kaudu.

OpenStack on pilve opsüsteem, mis võimaldab hallata suuri arvutusressursside, andmehoidlate ja võrguressursside baase, mille provisioneerimine ja haldamine toimub API kaudu, kasutades standardseid autentimismehhanisme.

Teisisõnu, see on tasuta tarkvara projektide kompleks, mis on mõeldud pilveteenuste loomiseks (nii avalike kui ka eraklike) — see tähendab tööriistade kogum, mis võimaldab ühendada serveri- ja lülitushardware ühtseks ressursibaasiks, haldades neid ressursse, tagades vajaliku taseme tõrkeohutust.

Käesoleva materjali kirjutamise ajal näeb OpenStacki struktuur välja selline:

Pilt on saadud openstack.org

Iga komponent, mis kuulub OpenStacki koosseisu, täidab mingit kindlat funktsiooni. Selline jaotatud arhitektuur võimaldab lisada lahendusse ainult need funktsionaalsed komponendid, mis teil on vajalikud. Siiski on osa komponente põhikomponendid ja nende eemaldamine toob kaasa lahenduse täieliku või osalise töövõimetuse. Sellistest komponentidest peetakse tavaliselt:

• Armatuurlaud — veebi põhine GUI OpenStacki teenuste haldamiseks
• Keystone — kesksed identiteediteenused, mis pakuvad autentimise ja autoriseerimise funktsioone teistele teenustele, samuti haldavad kasutajakonto andmeid ja nende rolle.
• Neutron on võrguteenistus, mis tagab ühenduse erinevate OpenStacki teenuste liideste vahel (sealhulgas VM-i ja nende pääsu vahel välishaavale)
• Cinder pakub juurdepääsu plokkhoidlatele virtuaalmasinatele
• Nova — virtuaalmasinate elutsükli haldamine
• Glance — virtuaalmasinate ja hetkepiltide piltide hoidla
• Swift — objektihoidla juurde pääsemise teenus
• Ceilometer — teenus, mis võimaldab telemeetria kogumist ning olemasolevate ja tarbitavate ressursside mõõtmist
• Heat — mallidel põhinev orkestreerimine ressursside automaatseks loomiseks ja provisionimiseks

Kogu projektide loend ja nende otstarve on vaadatav siit.

Iga OpenStacki komponent on teenus, mis vastutab kindla funktsiooni eest ja tagab API selle funktsiooni haldamiseks ning selle teenuse suhtlemiseks teiste teenustega pilve operatsioonisüsteemis, et luua ühtne infrastruktuur. Näiteks Nova haldab arvutusressursse ja pakub API andmete konfigureerimiseks, Glance – piltide haldamiseks ja API nende haldamiseks, Cinder – plokkhoidla ja API selle haldamiseks jne. Kõik funktsioonid on omavahel tihedalt seotud.

Kuid kui mõelda, siis kõik OpenStackis käivitatud teenused esitavad lõpuks mingi virtuaalmasina (või konteineri), mis on ühendatud võrku. Tõstatub küsimus — miks meil on nii palju komponente?

Vaatame lähemalt virtuaalmasina loomise ja selle võrku ning püsihoidlasse ühendamise algoritmi OpenStackis.

1. Kui teete masina loomise päringu, olgu see siis päring Horizonis (juhtpaneel) või CLI kaudu, toimub esimesena teie päringu autoriseerimine Keystone'is — kas teil on õigus luua masin, kas teil on õigus kasutada antud võrku, kas teie projektil on piisavalt kvooti jne.
2. Keystone autentib teie päringu ja genereerib vastuse, milles on auth-token, mida kasutatakse hiljem. Pärast vastuse saamist Keystone'ilt saadetakse päring Nova (nova api) suunas.
3. Nova-api kontrollib teie päringu kehtivust, pöördudes pärast auth-tokenit Keystone'i poole.
4. Keystone viib läbi autentimise ja annab selle auth-tokeni alusel teavet lubade ja piirangute kohta.
5. Nova-api loob nova-andmebaasis uue VM-iga seotud kirje ja edastab masina loomise päringu nova-scheduler'ile.
6. Nova-scheduler valib välja hosti (arvutussõlme), millel VM paigaldatakse, lähtudes antud parameetritest, kaaludest ja tsoonidest. Teave selle kohta ja VM-i identifikaator salvestatakse nova-andmebaasi.
7. Seejärel teeb nova-scheduler päringu nova-compute'ile instantsi paigaldamiseks. Nova-compute pöördub nova-conductor'i poole, et saada teavet masina parameetrite kohta (nova-conductor on elemendi nova osa, mis tegutseb proxy-serverina nova-andmebaasi ja nova-compute'i vahel, piirates päringute arvu nova-andmebaasi suunas, et vältida andmebaasi koormuse probleemide tekkimist).
8. Nova-conductor saab nova-andmebaasist taotletud teabe ja edastab selle nova-compute'ile.
9. Seejärel pöördub nova-compute glance'i poole pildi ID saamiseks. Glance valideerib päringu Keystone'is ja tagastab taotletud teabe.
10. Nova-compute pöördub neutroni poole võrgu parameetrite teabe saamiseks. Sarnaselt glance'ile valideerib neutron päringu Keystone'is, seejärel loob andmebaasis kirje (porti identifikaator jne), esitab päringu portaali loomise kohta ja tagastab taotletud teabe nova-compute'ile.
11. Nova-compute pöördub cinderi poole, paludes virtuaalmasinale mahu eraldamist. Sarnaselt glance'ile valideerib cinder päringu Keystone'is, loob päringu mahu loomiseks ja tagastab taotletud teabe.
12. Nova-compute pöördub libvirt'i poole, paludes virtuaalmasina paigaldamist antud parameetritega.

Tegemist on näiliselt lihtsa operatsiooniga, mille käigus luuakse lihtne virtuaalne masin, kuid see muutub kiiresti API-kutsungite keeriseks pilveplatvormi elementide vahel. Nagu näete, koosnevad isegi varem määratletud teenused väiksematest komponentidest, mille vahel toimub suhtlemine. Masina loomine on vaid väike osa sellest, mida pilveplatvorm võimaldab — on teenus, mis vastutab liikluse tasakaalustamise, teenus, mis vastutab plokkide salvestamise, teenus, mis vastutab DNS-i, teenus, mis vastutab bare metal serverite provisioneerimise jne eest. Pilv võimaldab teil suhelda oma virtuaalmasinatega kui lambakarjaga (erinevalt virtualiseerimisest). Kui virtuaalses keskkonnas juhtub masinaga midagi, siis taastate selle varukoopiatest jms, kuid pilve rakendused on üles ehitatud nii, et virtuaalsed masinad ei mängi nii olulist rolli — virtuaalmasin „suri“ — pole hullu — luuakse lihtsalt uus masin malli põhjal ja nagu öeldakse, kaaslast ei märgata kadunuks. Loomulikult eeldab see orkestrimise mehhanismide olemasolu — kasutades Heat malle, saate probleemideta käivitada keerulise funktsiooni, mis koosneb kümnetest võrkudest ja virtuaalmasinatest.

Alati tuleb meeles pidada, et pilve infrastruktuuri ei saa sans võrku — iga komponent suhtleb mingil moel teiste elementidega läbi võrgu. Lisaks sellele on pilve võrgu olemus täiesti staatiline. Loomulikult on aluseks olev võrk enam-vähem staatiline — uusi node ja lüliteid ei lisata igapäevaselt, kuid overlay komponent võib ja kindlasti muutub pidevalt — uusi võrgud tulevad ja kaovad, uued virtuaalsed masinad luuakse ja vanad surevad. Ja nagu te meeles pidate, kui määratlesime pilve alguses, peavad ressursid kasutajale automaatselt eralduma minimaalse (ja veel parem ilma) teenusepakkuja sekkumiseta. See tähendab, et see tüüpi võrguressursside edastamine, mis praegu eksisteerib teie isikliku kabineti kaudu http/https ja valves oleva võrguinseneri Vasili kaudu tagaküljel — see ei ole pilv, isegi kui Vasili on kaheksakäeline.

Neutron, olles võrgu teenus, pakub API-d pilve infrastruktuuri võrgupoolte haldamiseks. Teenus tagab OpenStacki võrguosa toimimise ja haldamise, pakkudes abstraktsioonitaset, mida nimetatakse Network-as-a-Service (NaaS). See tähendab, et võrk on virtuaalne mõõdetav üksus, nagu näiteks virtuaalsed CPU tuumad või RAM-i maht.

Kuid enne, kui liigume OpenStacki võrguarhitektuuri juurde, uurime, kuidas see võrk OpenStackis toimib ja miks see on oluline ja lahutamatu osa pilvest.

Niisiis, meil on kaks kliendi RED virtuaalset masinat ja kaks kliendi GREEN virtuaalset masinat. Eeldame, et need masinad asuvad kahes hüperviisorites selliselt:

Praegu on see lihtsalt nelja serveri virtualiseerimine ja mitte rohkem, kuna oleme lihtsalt virtualiseerinud 4 serverit, paigutades need kahele füüsilisele serverile. Lisaks ei ole nad isegi ühendatud võrku.

Kuna soovime luua pilve, peame lisama mõned komponendid. Esiteks virtualiseerime võrguosa — peame need 4 masinat paaridena ühendama, kusjuures kliendid soovivad, et need oleksid L2 ühenduses. Loomulikult võiks kasutada switchi ja seadistada selle suunas trunk ja hallata kõike Linuxi sillaga või, rohkem edasijõudnud kasutajate jaoks, Open vSwitchiga (keda me veel käsitleme). Kuid võrke võib olla väga palju ning L2 pidev läbi switchi edastamine ei ole parim idee — erinevate osakondade, teeninduslaua, taotluse täitmise ootamise ja tõrkeotsingute kuude tõttu ei toimi selline lähenemine tänapäeva maailmas enam. Mida varem ettevõte seda mõistab, seda lihtsam on tal edasi liikuda. Seetõttu eraldame hüperviisorite vahel L3 võrgu, mille kaudu meie virtuaalsed masinad suhtlevad, ja juba selle L3 võrgu peale ehitame virtuaalsed ülekatted L2 (overlay) võrgud, kus liigub meie virtuaalsete masinate liiklus. Inksaptsiooni jaoks võime kasutada GRE, Geneve või VxLAN. Praegu peatume viimasel, kuigi see pole eriti oluline.

Peame leidma koha VTEP-ile (loodetavasti on kõik tuttavad VxLAN terminoloogiaga). Kuna meie serveritest väljub kohe L3 võrk, ei takista meid miski VTEP-i paigutamine otse serveritesse, ning OVS (Open vSwitch) oskab seda suurepäraselt teha. Lõppkokkuvõttes saime sellise konstruktsiooni:

Kuna liiklus VMs peab olema jagatud, on virtuaalmasinate suunas portidel erinevad VLAN-nummbrid. Sildi number mängib rolli ainult ühe virtuaalse lüliti piires, kuna VXLAN-i kapseldamise korral saame selle probleemideta eemaldada, kuna meil on VNI.

Nüüd saame luua oma masinad ja virtuaalsed võrgud nende jaoks ilma probleemideta.

Kuid mis siis, kui kliendil on veel üks masin, kuid see asub teises võrgus? Me vajame võrgustikest rutiini. Vaatame lihtsat varianti, kui kasutatakse keskset rutiini — see tähendab, et liiklus suunatakse läbi spetsiaalsete pühendatud võrgusõlmede (tavaliselt on need kombineeritud kontrollsõlmedega, seega on meil sama asi).

Tundub, et midagi keerulist ei ole — teeme kontrollsõlmes silda ja suuname sinna liikluse ning sealt suuname selle sinna, kuhu me vajame. Kuid probleem seisneb selles, et klient RED tahab kasutada võrku 10.0.0.0/24 ja klient GREEN tahab kasutada võrku 10.0.0.0/24. See tähendab, et meil hakkab toimuma aadressiruumi ühisosa. Lisaks ei soovi kliendid, et teised kliendid saaksid suunata nende sisevõrkudesse, mis on mõistetav. Klientide võrkude ja andmeliikluse eraldamiseks määrame igale neist eraldi namespace'i. Namespace on tegelikult Linuxi võrgu staki koopia, mis tähendab, et RED namespace'is olevad kliendid on täielikult isoleeritud GREEN namespace'i klientidest (või on rutiin nende klientide vahel lubatud vaikimisi namespace'is või juba kõrgemas transpordiseadmes).

Nii et saame järgmise skeemi:

L2 tunnelid koonduvad kõigist arvutuslõppudest kontrollsõlme, kus asub L3 liides nende võrkude jaoks, igaühes eraldi namespace'is isolatsiooni tagamiseks.

Kuid me unustasime kõige olulisema. Virtuaalne masin peab kliendile teenust pakkuma, st tal peab olema vähemalt üks väline liides, mille kaudu temani pääseda. See tähendab, et peame minema välismaailma. Siin on erinevaid võimalusi. Teeme kõige lihtsama variandi. Lisame igale kliendile ühe võrgu, mis on kehtiv teenusepakkuja võrgus ja ei kattuks teiste võrkudega. Võrgud võivad samuti kattuda ja vaadata erinevatesse VRF-idesse teenusepakkuja võrgu poole. Need võrgud elavad samuti iga kliendi namespace'is. Kuid nad pääsevad välismaailma ikkagi ühe füüsilise (või loogilisema, bonda) liidese kaudu. Kliendi liikluse eraldamiseks toimub välimine liiklus VLAN-iga, mis on kliendile määratud.

Kokkuvõttes saime sellise skeemi:

Mõistlik küsimus on — miks mitte teha väravaid otse compute node'ides? Sellega pole tõsiselt probleemi, rohkemgi veel, jaotatud marsruuteri (DVR) sisse lülitamisel töötab see tõepoolest. Antud stsenaariumis käsitleme kõige lihtsamat varianti keskse väravaga, mida Openstack kasutab vaikimisi. Suure koormusega funktsioonide jaoks kasutatakse nii jaotatud marsruutereid kui SR-IOV ja Passthrough kiirusetehnoloogiaid, kuid nagu öeldakse, see on juba täiesti teine lugu. Alustame baasosa lahendamisest ja siis süveneme detailidesse.

Oma skeem on juba töötav, kuid paar nüanssi siiski on:

• Peame kuidagi kaitsma oma masinaid, st tuleb vahetada klientide poole suunatud lüliti liidesele filter.
• Luua võimalus virtuaalse masina automaatseks IP-aadressi saamiseks, et ei peaks igal korral konsolisse minema ja aadressi määrama.

Alustame masinate kaitsmisest. Selleks saab kasutada tavalisi iptables'e, miks ka mitte.

See tähendab, et meie topoloogia on nüüd natuke keerulisem:

Liigume edasi. Peame lisama DHCP serveri. Ideaalne koht iga kliendi DHCP serverite jaoks oleks juba mainitud kontrollnode, kus asuvad namespaces:

Kuid probleem on see, et kui kõik taaskäivitub, kaob kogu teave DHCP aadresside rentimise kohta. On loogiline, et masinatele antakse uued aadressid, mis ei ole eriti mugav. Siin on kaks võimalust — kas kasutada domeeninimesid ja lisada igale kliendile DNS server, siis ei ole aadress eriti oluline (sarnane võrguosaga k8s-s), kuid siin on probleem välistes võrkudes, kuna neis võivad aadressid samuti olla määratud DHCP kaudu — vajalik on sünkroonimine pilveteenuse DNS serveriga ja välise DNS serveriga, mis minu arvates ei ole kuigi paindlik, kuid täiesti teostatav. Teine võimalus on kasutada metaandmeid — see tähendab, et salvestame teabe määratud masina aadressi kohta, et DHCP server teaks, millise aadressi masinale anda, kui masin on juba aadressi saanud. Teine variant on lihtsam ja paindlikum, kuna võimaldab salvestada lisainfot masina kohta. Nüüd lisame skeemile metadata agendi:

Veel üks küsimus, mida tuleks samuti käsitleda, on võimalus, et kõik kliendid kasutavad ühte välist võrku, kuna välistes võrkudes, kui need peavad olema kehtivad kogu võrgu ulatuses, tõuseb keerukus — tuleb pidevalt eraldada ja kontrollida nende võrkude eraldamist. Ühe ühise välise eelnevalt konfigureeritud võrgu kasutamise võimalus kõikidele klientidele oleks avaliku pilve loomisel väga teretulnud. See lihtsustab masinate seadistamist, kuna meil ei ole vaja võrrelda aadresside andmebaasiga ja valida iga kliendi välise võrgu jaoks ainulaadne aadressiruumi. Lisaks saame välist võrku ette kirjutada ja seadistamise hetkel peame lihtsalt siduma välised aadressid kliendimasinatega.

Siin tuleb meile appi NAT — lihtsalt võimaldame klientide ühenduse loomise välistesse võrkudesse default namespace'i kaudu, kasutades NAT tõlget. Küll aga on siin väike probleem. See on hea, kui kliendi server töötab kui klient, mitte kui server — see tähendab, et see käivitab ühendusi, mitte ei võta neid vastu. Kuid meil on vastupidi. Sellisel juhul peame tegema sihtkoha NAT, et saades liiklust, kontrollsõlme saaks aru, et see liiklus on mõeldud kliendi A virtuaalkeskkonnale, seega peame tegema NAT tõlke välisest aadressist, näiteks 100.1.1.1 sisemisse aadressi 10.0.0.1. Sel juhul, ehkki kõik kliendid kasutavad üht ja sama võrku, säilib täielik sisemine isolatsioon. Seega peame kontrollsõlmes tegema dNAT ja sNAT. Ühe võrgu kasutamine koos ujuvate aadresside eraldamise või välistest võrkudest, või mõlemast korraga, sõltub sellest, mida soovite pilve tuua. Me ei lisa skeemile ujuvaid aadresse, vaid jätame alles varem lisatud välistesse võrkudesse — igal kliendil on oma väline võrk (skeemil on tähistatud VLAN-id 100 ja 200 välistel liidestel).

Kokkuvõtteks saime huvitava ja samas hästi läbimõeldud lahenduse, mis omab teatavat paindlikkust, kuid ei ole veel varukumismehanisme.

Esiteks on meil vaid üks kontrollsõlm — selle rike toob kaasa kogu süsteemi kokkuvarisemise. Selle probleemi lahendamiseks on vajalik luua vähemalt kolm sõlme koosolek. Lisame selle skeemile:

Muidugi, kõik sõlmed sünkroniseeruvad ja kui aktiivne sõlm ebaõnnestub, võtab teise sõlme kohustused enda peale.

Järgmine probleem on virtuaalmasinate ketastega. Praegu salvestatakse need hüperviisorites ja hüperviisoriga seotud probleemide korral kaotame kõik andmed — RAID sellest ei aita, kui kaotame mitte ketta, vaid kogu serveri. Seetõttu peame looma teenuse, mis toimib mingi salvestusruumi eesliinina. Mis salvestusruum see olema hakkab, pole nii oluline, kuid see peab kaitsma meie andmeid rikke, ketta ja sõlme, ning võib-olla isegi kogu kappe vastu. Siin on mitu varianti — küll on SAN-võrgud Fiber Channeliga, kuid olgem ausad — FC on juba minevik. See on nagu E1 transportimises — nõustun, et seda kasutatakse ikkagi, kuid ainult seal, kus ilma selleta kuidagi ei saa. Seetõttu ma ei sooviks 2020. aastal vabatahtlikult FC-võrku seadistada, teades, et on rohkem huvitavaid alternatiive. Kuid igaühel on oma arvamus ja võib-olla leidub inimesi, kes arvavad, et FC, koos oma piiretega, on kõikehõlmav lahendus — ei vaidle, igaühel on oma arvamus. Minu arvates on aga huvitavaim lahendus SDS-i, näiteks Ceph-i, kasutamine.

Ceph võimaldab luua kõrge kättesaadavuse andmesalvestuslahenduse, millel on tohutult erinevaid varundamisvõimalusi, alates pariteedikoodidest (analoog RAID 5 või 6) kuni täismahulise andmete replikatsioonini erinevatele ketastele, arvestades ketaste asukohti serverites ja serverite paiknemist kappides jne.

Ceph-i kokkupanemiseks on vaja veel 3 sõlme. Suhtlemine salvestusruumiga toimub samuti võrgu kaudu, kasutades plokki-, objekti- ja failihoidla teenuseid. Lisame skeemile salvestusruumi:

Märkus: saab luua ka hüperkonvergeeritud compute-sõlmi – see on mõisted, kus mitu funktsiooni on ühendatud ühte sõlme – näiteks storage+compute – mitte eraldada spetsiaalseid sõlmi Ceph storage'ile. Saame sama nurka, kuna SDS reserveerib andmed antud tasemega. Kuid hüperkonvergeeritud sõlmed on alati kompromiss – kuna storage-sõlm ei soojenda lihtsalt õhku, nagu esmapilgul tundub (kuna seal pole virtuaalseid masinaid) – see kulutab CPU ressursse SDS-i hooldamiseks (tegelikult ta taustal teostab kõik replikatsioonid, taastamise tõrgetest jne). See tähendab, et kaotate osa compute-sõlme jõudlusest, kui ühendada see storage'iga.

Kõike seda tuleb kuidagi hallata – vajame mingit süsteemi, mille kaudu saame luua masina, võrgu, virtuaalse reitaja jne. Selleks lisame kontrollsõlmele teenuse, mis täidab dashboardi rolli – klient saab sellele portaalile http/https kaudu ühenduda ja teha kõike, mida vaja (noh, peaaegu).

Kokkuvõtteks, meil on nüüd tõrketaluv süsteem. Kõiki selle infrastruktuuri komponente tuleb kuidagi hallata. Varasemalt on öeldud, et OpenStack on projektide kogum, millest igaühel on oma kindel funktsioon. Nagu näeme, on elemente, mida tuleb konfigureerida ja hallata, rohkem kui piisavalt. Täna räägime võrguosast.

Neutronic Architecture

OpenStackis vastutab just Neutron virtuaalsete masinate portide ühendamise eest üldise L2 võrgu kaudu, tagades liikluse suunamise VM-ide vahel, mis asuvad erinevates L2 võrkudes, samuti suunamise väljapoole, pakkudes selliseid teenuseid nagu NAT, Floating IP, DHCP jne.

Võrgu teenuse tegevust (põhiosa) saab kirjeldada järgmiselt.

Virtuaalmasina käivitamisel teeb võrgu teenus:

1. Loob antud VM (või portide) jaoks portaali ja teavitab sellest DHCP teenust;
2. Loo uus virtuaalne võrgu seade (libvirt kaudu);
3. VM ühendatakse portiga, mis loodi 1. sammus (portide);

Kuidas imelik see ka ei tundu, põhinevad Neutrone'i toimimine traditsioonilistel mehhanismidel, mis on tuttavad kõigile, kes on kunagi Linuxi kasutamisega kokku puutunud – need on nimede ruumid, iptables, linuxi sillad, openvswitch, conntrack jne.

Tuleb kohe selgitada, et Neutron ei ole SDN kontroller.

Neutron koosneb mitmest omavahel seotud komponendist:

Openstack-neutron-server — see on demon, mis töötab API kaudu kasutajate päringutega. See demon ei tegele mingite võrguside loomisega, vaid annab vajalikku teavet oma pistikprogrammidele, mis seejärel seadistavad vajaliku võrkelementi. Neutron-agendid OpenStacki sõlmedes registreeruvad Neutron-serveris.

Neutron-server on tegelikult rakendus, mis on kirjutatud Pythoni keeltes ja koosneb kahest osast:

• REST teenus
• Neutron Plugin (core/service)

REST teenus on mõeldud API päringute vastuvõtmiseks teistelt komponentidelt (näiteks teave taotlemise kohta jne).

Pistikprogrammid on laaditavad programmilised komponendid/modulid, mis kutsutakse esile API päringute korral — see tähendab, et teenuse lisamine toimub nende kaudu. Pistikprogrammid jagunevad kaheks tüübiks — teenus ja juur. Üldiselt vastutab juurpistikprogramm peamiselt adresseerimisruumi ja L2 ühenduste haldamise eest VM-de vahel, samas kui teenuspistikprogrammid pakuvad täiendavat funktsionaalsust, näiteks VPN või tulemüüri.

Saadaval olevate pistikprogrammide nimekirja saab vaadata näiteks siit

Teenuspistikprogramme võib olla mitu, kuid juurpistikprogramm võib olla ainult üks.

Openstack-neutron-ml2 — see on Openstacki standardne juurpistikprogramm. See pistikprogramm omab modulaarset arhitektuuri (erinevalt oma eelkäijast) ja konfigureerib võrgu teenust läbi sellele ühendatud draiverite. Sellest pistikprogrammist räägime hiljem, kuna see annab tegelikult selle paindlikkuse, millega OpenStacki võrgu osa koosneb. Juurpistikprogrammi saab asendada (näiteks Contrail Networking teeb sellise asenduse).

RPC teenus (rabbitmq-server) — teenus, mis tagab järjekordade haldamise ja suhtlemise teiste OpenStacki teenustega ning suhtlemise võrgu teenuse agentidega.

Võrguaineid — agendid, mis asuvad igas sõlmes, mille kaudu toimub võrgu teenuste konfigureerimine.

Agendid võivad olla erinevat tüüpi.

Peamine agent — see on L2 agent. Need agents are launched on each hypervisor including control nodes (to be precise, on all nodes that provide some service for tenants) and their main function is to connect virtual machines to a common L2 network and to generate alerts when any events occur (for example, port disconnections/connections).

The next equally important agent is L3 agent. By default, this agent is launched exclusively on the network node (often the network node is combined with the control node) and ensures routing between tenant networks (both between its networks and the networks of other tenants, as well as access to the external world by providing NAT and DHCP services). However, when using DVR (Distributed Router), the need for an L3 plugin arises also on compute nodes.

The L3 agent uses Linux namespaces to provide each tenant with a set of their own isolated networks and the functionality of virtual routers that route traffic and provide gateway services for Layer 2 networks.

Database — a database of network identifiers, subnets, ports, pools, etc.

In fact, Neutron receives API requests to create any network entities, authenticates the request, and via RPC (if it refers to some plugin or agent) or REST API (if it communicates in SDN) passes instructions to the agents (through plugins) needed to organize the requested service.

Now let's look at the test installation (how it is deployed and what it consists of will be discussed later in the practical part) and see where each component is located:

(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 ~]$ 

Nüüd on Neutron struktuur täielikult valmis. Jätkame ML2 pistiku kirjeldamisega.

Modulaarne Kiht 2

Nagu eelnevalt mainitud, on see pistik standardne OpenStacki juurpistik ja sellel on modulaarne arhitektuur.

Eelmine ML2 pistik oli monoliitne, mis ei võimaldanud näiteks kasutada mitut erinevat tehnoloogiat ühes installatsioonis. Näiteks ei saanud te samal ajal kasutada nii openvswitch'i kui linuxbridge'i — vaid ühte või teist. Seetõttu loodi ML2 pistik ja selle arhitektuur.

ML2-l on kaks komponenti — kaks tüüpi draivereid: Tüüpi draiverid ja Mehhanismidraiverid.

Tüüpi draiverid määravad tehnoloogiad, mida kasutatakse võrguühenduste korraldamiseks, näiteks VxLAN, VLAN, GRE. Samuti võimaldab draiver erinevate tehnoloogiate kasutamist. Standardne tehnoloogia on VxLAN-i kapseldamine overlay võrkude jaoks ja vlan välistest võrkudest.

Tüüpi draiverite hulka kuuluvad järgmised võrkude tüübid:

Flat — võrk, mis ei kasuta sildistamist
VLAN — sildistatud võrk
Local — eriline võrgu tüüp all-in-one installatsioonide jaoks (need installatsioonid on mõeldud kas arendajatele või koolituseks)
GRE — overlay-võrk, mis kasutab GRE tunnelit
VxLAN — overlay-võrk, mis kasutab VxLAN tunnelit

Mehhanismidraiverid määravad vahendid, mis tagavad määratud type driver tehnoloogiate rakendamise – näiteks openvswitch, sr-iov, opendaylight, OVN jne.

Sõltuvalt selle draiveri rakendamisest kasutatakse kas Neutroni hallatavaid agente või ühendusi välise SDN kontrolleriga, mis haldab kõiki küsimusi L2 võrkude, ruteerimise jne korraldamise kohta.

Näide, kui kasutame ML2 koos OVS-iga, siis igal arvutusnode'il installitakse L2 agent, mis haldab OVS-i. Kuid kui me näiteks kasutame OVN-i või OpenDayLight'i, siis läheb OVS-i juhtimine nende juristiktsiooni – Neutron saadab juurpluginaga käsud kontrollerile, kes juba täidab, mida talle öeldakse.

Korrigeerime meeles Open vSwitch'i

Hetkel on üks OpenStacki tähtsamaid komponente Open vSwitch.
OpenStacki installimisel ilma igasuguste lisavendorialuste SDN-de, nagu Juniper Contrail või Nokia Nuage, on OVS peamine võrgu komponent pilvenetis, ning koos iptables'i, conntrack'i ja nimede ruumidega võimaldab see täieliku multitenantviiruste korraldamist. Loomulikult võib selle komponenti asendada, näiteks kolmandate osapoolte patenteeritud (vendor) SDN lahenduste kasutamisel.

OVS on avatud lähtekoodiga tarkvara lüliti, mis on mõeldud kasutamiseks virtualiseeritud keskkondades virtuaalse liikluse suunajana.

Praegu on OVS-il väga korralik funktsionaalsus, mille hulka kuuluvad sellised tehnoloogiad nagu QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK jne.

Märkus: algselt ei olnud OVS mõeldud kõrge koormusega telekomifunktsioonide jaoks ja oli rohkem suunatud vähem nõudlike IT-funktsioonide, nagu veebiserver või meiliserver, jaoks. Kuid OVS-i arendatakse edasi ja praegused OVS-i rakendused on tugevalt parandanud selle jõudlust ja võimeid, mis võimaldab selle kasutamist sideoperaatoreile kõrge koormusega funktsioonide jaoks, näiteks on olemas OVS-i rakendus DPDK kiirusandmise toega.

On kolm olulist OVS-i komponenti, millest on teada vajalik:

• Kernel module — komponent, mis asub kernel space'is ja töötleb liiklust vastavalt juhtimiselt saadud reeglitele;
• vSwitch daemon (ovs-vswitchd) on protsess, mis töötab kasutaja ruumis ja vastutab kernel'i mooduli programmeerimise eest - see tähistab otse lüliti toimimise loogikat.
• Andmebaasiserver — lokaalne andmebaas, mis asub igas hostis, kus OVS töötab, ja kuhu salvestatakse konfiguratsioon. Selle mooduli kaudu saavad SDN kontrollerid suhelda OVSDB protokolli kaudu.

Sellele lisandub ka hulk diagnostilisi ja haldustööriistu, nagu ovs-vsctl, ovs-appctl, ovs-ofctl jne.

Praegu kasutatakse Openstacki laialdaselt telekommunikatsiooni operaatorite poolt võrgu funktsioonide, nagu EPC, SBC, HLR jne, migreerimiseks. Osa funktsioone võib probleemideta töötada OVS-is sellisena, nagu see on, kuid näiteks EPC töötleb abonentide liiklust - see tähendab, et see edastab tohutul hulgal liiklust (praegu ulatub liiklusmaht mitme saja gigabiti sekundi kohta). Loomulikult ei ole sellise liikluse edastamine kernel'i ruumi (kuna vaikimisi on edastaja seal) kõige parem idee. Seetõttu rakendatakse OVS sageli täielikult kasutaja ruumis DPDK tehnoloogia kasutada liikluse edastamiseks NIC-ilt kasutaja ruumi, mööda kernel'it.

Märkus: pilves, mis on juurutatud telekommunikatsioonifunktsioonide tarbeks, on võimalik suunata liiklust arvutussõlme kaudu otse OVS-ist kommutaatori seadmesse. Selle eesmärgi saavutamiseks kasutatakse SR-IOV ja Passthrough mehhanisme.

Kuidas see töötab reaalses prototüübis?

Nüüd liikume praktilise osa juurde ja vaatame, kuidas see kõik praktikas toimib.

Esmalt seadistame lihtsa Openstacki installatsiooni. Kuna mul ei ole katseliseks kasutamiseks sobivat serverite kogumit, siis ehitame mudeli ühel füüsilisel serveril virtuaalmasinate abil. Jah, loomulikult ei sobi selline lahendus kommertseesmärkidel, kuid et näha, kuidas Openstacki võrgud toimivad, on selline installatsioon piisav. Veelgi enam, selline installatsioon on õpikogemuste jaoks isegi huvitavam - kuna saab jälgida liiklust jne.

Kuna me peame nägema ainult baasosa, saame mitte kasutada mitut võrku ja kõik tõsta üles kasutades vaid kaht võrku, kusjuures teine võrk selles maketis kasutatakse eranditult connectimiseks undercloud-ile ja DNS serverile. Välistesse võrkudesse me praegu sekkuda ei kavatse — see on teema eraldi suurele artiklile.

Nii, alustame järjestikku. Esiteks veidi teooriat. Paigaldame OpenStacki TripleO (OpenStack OpenStacki peal) abil. TripleO olemus seisneb selles, et installime OpenStacki all-in-one (st ühele nodile), mida nimetatakse undercloudiks, ja kasutame seejärel käesoleva OpenStacki võimeid, et paigaldada tootmiseks mõeldud OpenStack, mida nimetatakse overcloudiks. Undercloud kasutab oma sisse ehitatud võimet hallata füüsilisi servereid (bare metal) – projekti Ironic – hüperviisореde provisionimiseks, mis täidavad compute, control, storage nodide rolle. See tähendab, et me ei kasuta OpenStacki installimiseks mingeid kolmandate osapoolte vahendeid – installeerime OpenStacki OpenStacki enda jõududega. Edasi, installimise käigus saab see palju arusaadavamaks, seega ei peatume selle peal ja liigume edasi.

Märkus: Käesolevas artiklis lihtsustamise mõttes ei kasutanud ma OpenStacki sisemiste võrkude jaoks võrguisolatsiooni ning kõik on paigaldatud vaid ühe võrgu abil. Kuid võrkude isoleerimise olemasolu või puudumine ei mõjuta lahenduse põhifunktsionaalsust - kõik töötab täpselt sama moodi, nagu isoleerimise kasutamisel, kuid liiklus liigub ühes ja samas võrgus. Kaubanduslikus installatsioonis on loomulikult vajalik kasutada isoleerimist erinevate VLANide ja liidestega. Näiteks Ceph hoidlate haldamise liiklus ja andmete liiklus (masinate juurdepääs kettale jne) kasutavad isoleerituna erinevaid alamvõrke (Storage management ja Storage), mis muudab lahenduse vastupidavamaks, jagades seda näiteks erinevate portide vahel või kasutades erinevaid QoS-profiile erinevale liiklusele, et andmeliiklus ei suruks välja signaaliliiklust. Meie puhul liiguvad nad aga ühes ja sama võrgus ning see ei piira meid tegelikult kuidagi.

Märkus: Kuna plaanime virtualiseeritud keskkonnas, mis põhineb virtuaalsetel masinatel, käitada virtuaalmasinaid, tuleb esmalt lubada pesastatud virtualiseerimine.

Pesastatud virtualiseerimise lubamise kontrollimiseks võib teha järgmist:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

Kui näete tähte N, siis lubage pesastatud virtualiseerimise tugi igasuguse juhendi järgi, mida internetist leiate, näiteks niisugust .

Peame looma sellise skeemi virtuaalmasinatest:

Minu puhul kasutasin virtuaalsete masinate seotuseks, mis kuuluvad tulevase installatsiooni alla (mul on neid 7, kuid 4 võib piisata, kui teil pole palju ressursse), OpenvSwitchi. Lõin ühe ovs sild ja ühendasin selle kaudu virtuaalsed masinad port-rühmadega. Selleks lõin järgmise sisu omava xml-faili:

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        

  ovs-network-1
  7a2e7de7-fc16-4e00-b1ed-4d190133af67

Siin on kuulutatud kolm portrühma - kaks access ja üks trunk (viimane oli vajalik DNS serveri jaoks, kuid ilma selleta saab ka hakkama või tõsta selle hostmasinale - nagu teile sobib). Edasi määrame selle malli kaudu oma võrgu virsh net-define abil:

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

Nüüd viime hüperviisori portide konfiguratsioonid korda:

[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 ~]# 

Märkus: antud stsenaariumis pole ovs-br1 pordi aadress saadaval, kuna tal ei ole VLAN-i sildi. Selle parandamiseks tuleb anda käsk sudo ovs-vsctl set port ovs-br1 tag=100. Kuid pärast taaskäivitamist kaob see silt (kui keegi teab, kuidas seda paigal hoida - oleksin väga tänulik). Kuid see ei ole nii oluline, kuna seda aadressi vajame ainult installimise ajaks ja see ei ole vajalik, kui OpenStack on täielikult loodud.

Edasi loome undercloud masina:

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=ttyS0

Installatsiooni käigus seadistage kõik vajalikud parameetrid, näiteks masina nimi, paroolid, kasutajad, ntp serverid jne. Portide seadistamine on samuti võimalik, kuid isiklikult on mul lihtsam pärast installatsiooni masinasse konsooli kaudu sisse logida ja vajalikud failid üle vaadata. Kui teil on juba valmis pilt, siis võite seda kasutada või toimida nagu mina — laadida alla minimaalne CentOS 7 pilt ja kasutada seda virtuaalmasina installimiseks.

Pärast edukat installatsiooni peaks teil olema virtuaalne masin, kuhu saab installida undercloudi.

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

Esmalt installime vajalikud tööriistad:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

Undercloudi installatsioon

Loome kasutaja stack, seame parooli, lisame sudoerisse ja anname talle võimaluse käivitada root-käsklusi sudo kaudu ilma parooli sisestamata:

useradd stack
passwd stack

echo "stack ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

Nüüd määrame hosts failis undercloudi täieliku nime:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Seejärel lisame repot ja installime vajaliku tarkvara:

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-ansible

Märkus: kui te ei plaani ceph'i installida, siis ceph'iga seotud käske sisestada ei maksa. Kasutasin Queens'i väljalaset, kuid teie võite kasutada mõnda muud, mis teile meeldib.

Seejärel kopeerime undercloudi konfiguratsiooni faili stacki kasutaja kodu katalooge:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

Nüüd tuleb seda faili kohandada, et see sobiks meie installatsiooniga.

Faili algusesse tuleb lisada järgmised read:

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 = 10

Nii, vaatame seadeid üle:

undercloud_hostname — undercloud serveri täielik nimi, peaks vastama DNS serveris olevale kirjele

local_ip — lokaalne aadress undercloud provizioneerimise võrgu suunal

network_gateway — sama lokaalne aadress, mis toimib gateway'na välismaailma juurdepääsuks overcloud nodede paigaldamise ajal, on samuti sama mis kohaliku IP

undercloud_public_host — välise API aadress, määratakse mis tahes vaba aadress provizioneerimise võrgust

undercloud_admin_host sisemise API aadress, määratakse mis tahes vaba aadress provizioneerimise võrgust

undercloud_nameservers — DNS server

generate_service_certificate — see rida on praeguses näites väga oluline, kuna kui te ei määra seda vale väärtuseks, siis saate paigaldamise ajal vea, probleem on kirjeldatud Red Hat'i veabug trackeris

local_interface interface provizioneerimise võrgus. See interface konfigureeritakse ümber undercloudi juurutamise ajal, seega peab undercloudil olema kaks interface'i - üks juurdepääsuks ja teine provizionimiseks

local_mtu — MTU. Kuna meil on testlabor ja MTU on 1500 OVS lüliti portidel, siis peab see olema seatud väärtusele 1450, et VxLAN pakettide kapseldamine toimiks

network_cidr — provizionimise võrk

masquerade — NAT kasutamine juurdepääsuks välisvõrku

masquerade_network — võrk, mis NAT-itakse

dhcp_start — algne aadressiaadressipakkumistest, millest aadresse määratakse nodedele overcloud'i paigaldamise ajal

dhcp_end — lõppaadress aadressipakkumisest, millest aadresse määratakse nodedele overcloud'i paigaldamise ajal

inspection_iprange — aadressipakkumine, mis on vajalik introspektsiooni jaoks (ei tohi kattuda eespool määratud aadressipakkumisega)

scheduler_max_attempts — maksimaalne katsete arv overcloud'i paigaldamiseks (peab olema suurem või võrdne nodede arvuga)

Kui fail on kirjeldatud, siis võite anda käsu undercloud'i juurutamiseks:

openstack undercloud install

Protseduur võtab aega 10 kuni 30 minutit, sõltuvalt teie riistvarast. Lõppkokkuvõttes peaksite nägema järgmist väljundit:

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud paigaldamine on lõpule viidud.

Fail, kus on selle paigaldamise paroolid, asub
/home/stack/undercloud-passwords.conf.

Samuti on olemas stackrc fail aadressil /home/stack/stackrc.

Need failid on vajalikud OpenStack teenustega suhtlemiseks ning need peaksid olema
kindlalt kaitstud.

#############################################################################

See väljund ütleb, et olete edukalt installinud undercloud'i ja nüüd on võimalik kontrolida undercloud'i olekut ning liikuda overcloud'i paigaldamise juurde.

Kui vaatate väljundit ifconfig, siis näete, et uus bridge interface on loodud

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Selleli liidese kaudu toimub nüüd overcloudi juurutamine.

Alljärgnevast väljundist on näha, et kõik teenused on meil ühes noodis:

(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     |
+--------------------------+-----------+----------+

Allpool on näidatud undercloudi võrgu konfiguratsioon:

(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 ~]$

Overcloudi installatsioon

Praegu on meil ainult undercloud ja meilt puuduvad noodid, millest overcloud kokku pannakse. Seetõttu alustame vajalike virtuaalmasinate juurutamist. Undercloud paigaldab operatsioonisüsteemi ja vajaliku tarkvara overcloudi masinatele, see tähendab, et me ei vaja masinate täielikku juurutamist, vaid peame vaid luues nende jaoks ketta (või ketaste) ja määrama nende parameetrid - seega saame tõeliselt aluse serveri ilma operatsioonisüsteemita.

Liigume virtuaalmasinate ketaste kausta ja loome vajalikus mahus kettad:

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 160G

Kuna tegutseme rootina, peame nende kettaste omaniku muutma, et vältida õiguste probleeme:

[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]# 

Märkus: kui te ei kavatse ceph'i õppimise eesmärgil installida, siis looge vähemalt 3 sõlme koos vähemalt kahe kettaga, ja šabloonis märkige, et kasutatakse virtuaalseid kettaid vda, vdb jne.

Suurepärane, nüüd peame kõik need masinad määratlema:

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 

Lõpus on käsud —print-xml > \/tmp\/storage-1.xml, mis loob igas masinas XML-faili kirjelduse kaustas \/tmp\/, kui seda ei lisata, ei saa te virtuaalseid masinaid määratleda.

Nüüd peame kõik need masinad virsh'iga määratlema:

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 ~]#

Nüüd on üks väike nüanss — tripleO kasutab IPMI-d serverite haldamiseks installimise ja introspektsiooni ajal.

Introspektsioon on protsess riistvara kontrollimiseks, et saada vajalikud parameetrid edasiseks node'ide varustamiseks. Introspektsioon toimub ironic'i abil — teenus, mis on mõeldud bare metal serveritega töötamiseks.

Kuid siin on probleem — kui füüsilistel serveritel on IPMI jaoks eraldi port (või jagatud port, aga see ei ole põhimõtteline), siis virtuaalmasinatel selliseid porte ei ole. Siin tuleb appi vbmc — utiliit, mis võimaldab simuleerida IPMI porti. Sellele nüansile tasub erilist tähelepanu pöörata neile, kes soovivad sellist laboratooriumi üles seada ESXI hüperviisoril — ausalt öeldes ei tea, kas seal on vbmc analoog, seetõttu tasub selle küsimusega eelnevalt tegeleda enne, kui kõik seadistama hakkate.

Installime vbmc:

yum install python2-virtualbmc

Kui teie operatsioonisüsteem ei leia paketti, siis lisage repository:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

Nüüd konfigureerime utiliidi. Siin on kõik erakordselt lihtne. Nüüd on loogiline, et vbmc nimekirjas ei ole ühtegi serverit.

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

Kuid nende sisenemiseks tuleb need käsitsi välja kuulutada järgmiselt:

[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 ~]#

Arvan, et käsu süntaks on selge ilma selgitusteta. Siiski on meie sessioonid praegu kõik staatuses DOWN. Et need üleminekuks UP staatusesse, tuleb need sisse lülitada:

[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 ~]#

Ja viimane puudutus — tuleks teha tulemüüri reeglid korda (või lülitage see täielikult välja):

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

Nüüd siseneme undercloud'i ja kontrollime, et kõik töötab. Host masina aadress on 192.168.255.200, undercloud'ile lisasime vajaliku ipmitooli paketi ettevalmistamise käigus:

[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                      running

Nagu näete, oleme edukalt käivitanud control sõlme vbmc kaudu. Nüüd lülitame selle välja ja liigume edasi:

[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 ~]#

Järgmine samm — on node'ide introspekteerimine, kuhu overcloud paigaldatakse. Selleks peame ette valmistama json-faili, mis kirjeldab meie node'e. Pange tähele, et erinevalt paljude serverite paigaldamisest on failis märgitud port, millele vbmc on iga masina jaoks seadistatud.

[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:27

Märkus: kontrollsõlmes on kaks liidest, kuid antud juhul see ei ole oluline, antud paigalduses piisab meile ühest.

Nüüd valmistame ette json faili. Peame näitama MAC-aadressi sadamast, mille kaudu toimub provisioneerimine, sõlmede parameetreid, määrama neile nimed ja näitama, kuidas IPMI-le pääseda:

{
    "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"
        }
    ]
}

Nüüd peame valmistama ette pildid Ironic jaoks. Selleks laadime need alla wget'i kaudu ja installime:

(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 ~]$

Laeme pildid undercloudi:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Pilt "overcloud-full-vmlinuz" on üles laaditud.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Nimi          | Diski formaat |   Suurus | Staatus |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | aktiivne |
+--------------------------------------+------------------------+-------------+---------+--------+
Pilt "overcloud-full-initrd" on üles laaditud.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Nimi         | Diski formaat |   Suurus  | Staatus |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | aktiivne |
+--------------------------------------+-----------------------+-------------+----------+--------+
Pilt "overcloud-full" on üles laaditud.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Nimi      | Diski formaat |    Suurus    | Staatus |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | aktiivne |
+--------------------------------------+----------------+-------------+------------+--------+
Pilt "bm-deploy-kernel" on üles laaditud.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Nimi       | Diski formaat |   Suurus  | Staatus |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | aktiivne |
+--------------------------------------+------------------+-------------+---------+--------+
Pilt "bm-deploy-ramdisk" on üles laaditud.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Nimi       | Diski formaat |    Suurus   | Staatus |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | aktiivne |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

Kontrollime, et kõik pildid oleksid üles laaditud

(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Nimi                   | Staatus |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | aktiivne |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | aktiivne |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | aktiivne |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | aktiivne |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktiivne |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

Veel üks detail — tuleb lisada DNS server:

(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 ~]$

Nüüd saame anda käsu introspektsiooniks:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Alustati Mistral Workflow tripleo.baremetal.v1.register_or_update. Täitmise ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Ootame sõnumeid järjekorras 'tripleo', ilma ajapiiranguta.


5 sõlme on edukalt muudetud "haldatavasse" olekusse.
Edukalt registreeritud sõlme UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Edukalt registreeritud sõlme UUID b89a72a3-6bb7-429a-93bc-48393d225838
Edukalt registreeritud sõlme UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Edukalt registreeritud sõlme UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Edukalt registreeritud sõlme UUID 766ab623-464c-423d-a529-d9afb69d1167
Ootame introspektsiooni lõpetamist...
Alustati Mistral Workflow tripleo.baremetal.v1.introspect. Täitmise ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Ootame sõnumeid järjekorras 'tripleo', ilma ajapiiranguta.
Sõlme b89a72a3-6bb7-429a-93bc-48393d225838 introspektsioon lõpetatud. Oleku:SUCCESS. Vead:None
Sõlme 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e introspektsioon lõpetatud. Oleku:SUCCESS. Vead:None
Sõlme bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 introspektsioon lõpetatud. Oleku:SUCCESS. Vead:None
Sõlme 766ab623-464c-423d-a529-d9afb69d1167 introspektsioon lõpetatud. Oleku:SUCCESS. Vead:None
Sõlme b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 introspektsioon lõpetatud. Oleku:SUCCESS. Vead:None
Edukalt introspekteeritud 5 sõlme.
Alustati Mistral Workflow tripleo.baremetal.v1.provide. Täitmise ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Ootame sõnumeid järjekorras 'tripleo', ilma ajapiiranguta.
5 sõlme on edukalt muudetud "saadaval" olekusse.
(undercloud) [stack@undercloud ~]$

Kuidas näha, et kõik lõppes ilma vigadeta. Kontrollime, et kõik sõlmed on olekus available:

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Nimi      | Instantsi UUID | Toiteolek  | Ülesandmise olek   | Hooldus     |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | kontroll-1 | None          | välja lülitatud | saadaval          | Vale        |
| b89a72a3-6bb7-429a-93bc-48393d225838 | salvestamine-1 | None          | välja lülitatud | saadaval          | Vale        |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | salvestamine-2 | None          | välja lülitatud | saadaval          | Vale        |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | arvutus-1 | None          | välja lülitatud | saadaval          | Vale        |
| 766ab623-464c-423d-a529-d9afb69d1167 | arvutus-2 | None          | välja lülitatud | saadaval          | Vale        |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

Kui sõlmed on teises olekus, tavaliselt manageable, siis on midagi valesti ning tuleb vaadata logisid, et mõista, miks see juhtus. Pidage meeles, et selles stsenaariumis kasutame virtualiseerimist ja võivad esineda vead, mis on seotud virtuaalsete masinate või vbmc kasutamisega.

Edasi peame määrama, milline sõlm millist funktsiooni täidab — see tähendab, et peame määrama profiili, millega sõlm juurutatakse:

(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 ~]$

Määrake iga node'i jaoks profiil:

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-d9afb69d1167

Kontrollime, kas oleme kõik õigesti teinud:

(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 ~]$

Kui kõik on õigesti, anname käsu overcloudi juurutamiseks:

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 qemu

Tõelises paigalduses kasutatakse loomulikult kohandatud malli, kuid meie puhul muudab see protsessi väga keeruliseks, kuna tuleb selgitada iga muudatust mallis. Nagu varem mainitud — isegi lihtne paigaldus on piisav, et näha, kuidas see töötab.

Märkus: muutuja —libvirt-type qemu on antud juhul vajalik, kuna me kasutame pesastatud virtualiseerimist. Vastasel juhul ei käivitu teie virtuaalsed masinad.

Nüüd on teil umbes tund, võib-olla rohkem (sõltub riistvarast) ja jääb loota, et selle aja möödudes näete sellist teadet:

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 ~]$

Nüüd on teil peaaegu täisfunktsionaalne OpenStack, milles saate õppida, katsetada jne.

Kontrollime, kas kõik töötab normaalselt. Kasutaja stack kodukataloogis on kaks faili — üks stackrc (undercloudi haldamiseks) ja teine overcloudrc (overcloudi haldamiseks). Need failid tuleb määrata kui source, kuna neis on vajalikud autentimise andmed.

(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 ~]$

Minu seadistuses on veel vajalik üks väike puudutus — lisada marsruut kontrolleris, kuna masin, millega ma töötan, asub teises võrgus. Selleks logime sisse control-1 kasutajanimega heat-admin ja määrame marsruudi.

(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15         
Viimane sisselogimine: Reede Aug 14 09:47:40 2020, 192.168.255.1-lt
[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.254

Ja nüüd saate minna horisonti. Kõik teave — aadressid, kasutajanimi ja parool — asuvad failis /home/stack/overcloudrc. Lõplik skeem näeb välja järgmine:

Tasub mainida, et meie paigalduses antakse masinate aadressid DHCP kaudu, ja nagu näete, antakse need "nagu juhtub". Kui soovite, võite mallis rangelt määrata, milline aadress peab igale masinale olema kinnitatud paigaldamise ajal.

Kuidas liiklus virtuaalsete masinate vahel liigub?

Käesolevas artiklis käsitleme kolme varianti, kuidas liiklus liigub.

• Kaks masinat ühel hüperviisoril ühes L2 võrgus.
• Kaks masinat erinevates hüperviisorites ühes L2 võrgus.
• Kaks masinat erinevates võrkudes (ruttimine võrkude vahel).

Juhtumid, kus liiklus välismaailma suunatakse eksternaalvõrgu kaudu, kasutades ujuvaid aadresse ning hajutatud ruttimist, vaatame järgmine kord, praegu jääme sisemisele liiklusele.

Kontrollimiseks kogume sellise skeemi:

Meil on loodud 4 virtuaalset masinat — 3 ühes L2 võrgus — net-1, ja veel 1 net-2 võrgus.

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Nimi | Rentniku ID                      | Staatus | Ülesande olek | Toite olek | Võrgud        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | AKTIIVNE | -          | Käitub     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | AKTIIVNE | -          | Käitub     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | AKTIIVNE | -          | Käitub     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | AKTIIVNE | -          | Käitub     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

Vaadakem, millistel hüperviisoritel loodud masinad asuvad:

(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 ~]$
Masinad vm-1 ja vm-3 asuvad compute-0-l, masinad vm-2 ja vm-4 asuvad node'l compute-1.

Lisaks on loodud virtuaalne ruuter võimaldamiseks marsruutimise vahel määratud võrkude vahel:

(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 ~]$ 

Ruuteril on kaks virtuaalset porti, mis toimivad väravad võrke jaoks:

(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 ~]$ 

Kuid enne, kui vaatame, kuidas liiklus liigub, vaadakem, mida me hetkel kontrollimisseondunud node'il (mis on samal ajal ka network node) ja compute node'il. Alustame compute node'ist.

[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 ~]$

Praegu on noodis kolm ovs silda — br-int, br-tun, br-ex. Nende vahel, nagu näeme, on hulgaliselt liideseid. Lihtsuse huvides joonistame kõik need liidesed skeemile ja vaatame, mis välja tuleb.

Aadressidel, kus VxLAN tunnelid on üles seadistatud, on näha, et üks tunnel on seadistatud compute-1 (192.168.255.26) ja teine tunnel suunab control-1 (192.168.255.15). Ent kõige huvitavam on see, et br-ex'il ei ole füüsilisi liideseid ja kui vaadata, millised vood on seadistatud, on näha, et see sild suudab praegu ainult liiklust blokeerida.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

Nagu nähtub väljundist, on aadress otseselt ühendatud füüsilise pordi, mitte virtuaalse sillaliidese külge.

[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 ~]$ 

Esimese reegli kohaselt tuleb kõik, mis saabub pordist phy-br-ex, kõrvaldada.
Tegelikkuses ei saa antud sillale rohkem liiklust tekkida, välja arvatud antud liidesest (ühendus br-intiga) ja arvesse võttes blokeerimisi on selge, et silda on juba jõudnud BUM liiklus.

See, traffic from this node can only exit through a VxLAN tunnel and not otherwise. However, if DVR is enabled, the situation changes, but we will address that another time. When using network isolation, for instance with VLANs, you will have not just one L3 interface on VLAN 0, but several interfaces. Nevertheless, VxLAN traffic will exit from the node in the same way, but encapsulated also in a specific VLAN.

We have dealt with the compute node, now let’s move on to the control node.

[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 ~]$

In fact, we can say that everything is the same, however, the IP address is now located not on a physical interface but on a virtual bridge. This is due to the fact that this port is the one through which traffic will exit to the outside world.

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163  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
        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 ~]$ 

This port is bound to the bridge br-ex and since there are no VLAN tags on it, this port is a trunk port on which all VLANs are allowed, currently the traffic is exiting without a tag, as indicated by the vlan-id 0 in the output above.

Everything else at the moment is similar to the compute node — the same bridges, the same tunnels going to the two compute nodes.

Salvestuse node, millest me selles artiklis räägime, ei arutata, kuid arusaamiseks on vajalik öelda, et nende node'ide võrgupositsioon on ülimalt lihtne. Meie juhul on seal ainult üks füüsiline port (eth0), millele on määratud IP-aadress, ja kõik. Seal ei ole mingit VxLAN tunnelit, tunnelibridže ega muud — OVS-i ei ole üldse, kuna sellest pole mingit mõtet. Kui kasutatakse võrgu isolatsiooni, siis sellel node'il on kaks liidest (füüsilisi porte, võrgukaarte, või lihtsalt kaks VLAN'i — see ei ole oluline — see sõltub sellest, mida soovite) — üks halduse jaoks, teine ​​liiklust (VM-i kettale salvestamine, kettalt lugemine jne).

Oleme mõistnud, mis meil node'ides on, ilma teenusteta. Nüüd käivitame 4 virtuaalmasinat ja vaatame, kuidas eespool kirjeldatud skeem muutub — meil peaksid ilmuma pordid, virtuaalsed ruuterid jne.

Praegu näeb meie võrk välja nii:

Igal kohal on kaks virtuaalmasinat. Vaadake ühe näitena compute-0, kuidas kõik on ühendatud.

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Nimi                           Oleku
----------------------------------------------------
 1     instance-00000001              käivitatud
 3     instance-00000003              käivitatud

[heat-admin@overcloud-novacompute-0 ~]$ 

Masinal on ainult üks virtuaalne liides — tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Liides        Tüüp       Allikas     Mudel       MAC
-------------------------------------------------------
tap95d96a75-a0 sillal     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

Käesolev liides vaatab linux-sillale:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
silla nimi     sill id                STP lubatud     liidesed
docker0         8000.0242904c92a8       ei
qbr5bd37136-47          8000.5e4e05841423       ei              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       ei              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

Kuidas on välja toodud, on sillal ainult kaks liidest — tap95d96a75-a0 ja qvb95d96a75-a0.

Siin on mõttekas peatuda OpenStacki virtuaalsete võrgu seadmete tüüpide üle:
vtap — virtuaalne liides, mis on kinnitatud instantsile (VM)
qbr — Linuxi bridge
qvb ja qvo — vEth paar, mis on ühendatud Linuxi sildade ja Open vSwitch sildadega
br-int, br-tun, br-vlan — Open vSwitch sillad
patch-, int-br-, phy-br- — Open vSwitch patch-liidesed, mis ühendavad sildu
qg, qr, ha, fg, sg — Open vSwitchi pordid, mida virtuaalsed seadmed kasutavad OVS-iga ühendamiseks

Nagu me näeme, kui meil on brügges qvb95d96a75-a0 port, mis on vEth paar, siis kuskil on selle vastaspool, mis loogiliselt peaks olema nimega qvo95d96a75-a0. Vaatame, millised pordid on OVS-is.

[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 ~]$ 

Nagu näeme, asub port br-int-is. Br-int toimib lülitina, mis lõpetab virtuaalmasinate pordiühendused. Lisaks qvo95d96a75-a0 on väljundis nähtav port qvo5bd37136-47. See on port teisele virtuaalmasinale. Lõpptulemusena näeb meie skeem nüüd välja nii:

Küsimus, mis peaks kohe tähelepaneliku lugeja tähelepanu haarama — miks on Linuxi sild virtuaalmasina pordi ja OVS pordi vahel? Asi on selles, et masina kaitsmiseks kasutatakse turvagrupe, mis tegelikult on mitte midagi muud kui iptables. OVS ei tööta iptablesiga, seega töötati välja selline "körv", mis nüüd aga oma tähtsust kaotab — selle asemele tuleb conntrack uutes versioonides.

Seega lõpuks näeb skeem välja nii:

Kaks masinat ühel hüperviisoril ühes L2 võrgus.

Kuna need kaks VM-i asuvad samas L2 võrgus ja samal hyperviisoril, siis liiklus nende vahel liigub loogiliselt lokaalselt läbi br-int, kuna mõlemad masinad asuvad samas VLAN-is:

[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 ~]$ 

Kaks masinat erinevates hüperviisorites ühes L2 võrgus.

Nüüd vaatame, kuidas liiklus kulgeb kahe masina vahel, mis asuvad samas L2 võrgus, kuid erinevatel hyperviisoritel. Kui olla aus, siis ei muutu eriti midagi, lihtsalt liiklus hyperviisorite vahel kulgeb läbi vxlan tunneli. Vaatame näite kaudu.

Virtuaalmasinate aadressid, mille vahel vaatame liiklust:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Liides        Tüüp       Allikas     Mudel       MAC
-------------------------------------------------------
tap95d96a75-a0 sillal     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 ~]$ 

Vaadake edastustabelit br-int-s br-int-s 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 ~]$

Liiklus peab minema pordile 2 — vaatame, mis port see on:

[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 ~]$

See on patch-tun — see tähendab, et see on liides br-tun-s. Vaatame, mis toimub pakettidega br-tun-s:

[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 ~]$ 

Pakett pakendatakse VxLAN-isse ja saadetakse pordile 2. Vaadake, kuhu port 2 viib:

[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 ~]$

See on vxlan tunnel compute-1-s:

[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 ~]$

Liigume compute-1-le ja vaatame, mis edasi juhtub pakettiga:

[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 on edastustabelis br-int compute-1-s ja nagu eelnevalt välja toodud, on see nähtav läbi port 2, mis on port br-tun-i suunas:

[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

Ja siis vaatame, et br-int-s compute-1-s on sihtmärk MAC:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

Seega saadetud pakett suundub porti 3, kus asub virtuaalmasin instance-00000003.

Openstacki paigaldamise ilu virtuaalses infrastruktuuris seisneb selles, et me saame probleemideta jälgida liiklust hüpervisorite vahel ja vaadata, mis toimub. Just seda me praegu teeme, käivitame tcpdump'i vnet sadamas suunal compute-0:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: kuulamine vnet3-l, link-tüüp EN10MB (Ethernet), salvestamise suurus 262144 baiti

*****************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*******************

Esimene rida näitab, et pakett aadressilt 10.0.1.85 läheb aadressile 10.0.1.88 (ICMP liiklus), olles samas pakitud VxLAN paketti vni 22 ning pakett liigub hostilt 192.168.255.19 (compute-0) hostile 192.168.255.26 (compute-1). Saame kontrollida, et VNI vastab sellele, mis on määratud ovs-is.

Naaseme sellele reale actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 on vni heksadesimaalses süsteemis. Muudame selle numbri kümnendsüsteemi:

16 = 6*16^0+1*16^1 = 6+16 = 22

See tähendab, et vni vastab tõele.

Teine rida näitab tagasiteed, kuid selle selgitamiseks ei ole mõtet, seal on kõik selge.

Kaks masinat erinevates võrkudes (marsruutimine võrkude vahel)

Viimane juhtum täna on marsruutimine võrkude vahel ühes projektis virtuaalse marsruuteriga. Arutame juhtumit ilma DVR-ta (seda käsitleme teises artiklis), seega marsruutimine toimub võrgusõlmes. Meie puhul ei ole võrgusõlm eraldi üksusena määratletud, vaid see asub juhtsõlmes.

Alustame kontrollimist, kas marsruutimine toimib:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 andmebaidi
64 baiti aadressilt 10.0.2.8: seq=0 ttl=63 aeg=7.727 ms
64 baiti aadressilt 10.0.2.8: seq=1 ttl=63 aeg=3.832 ms
^C
--- 10.0.2.8 ping'i statistika ---
2 paketti saadetud, 2 paketti vastu võetud, 0% pakettide kaotus
ühe suuna min/avg/max = 3.832/5.779/7.727 ms

Kuna antud juhul peab pakett minema lüli ja seal marsruutima, peame välja selgitama lüli MAC-aadressi, vaadates ARP tabelit instantsis:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) aadressil fa:16:3e:c4:64:70 [ether]  eth0 peal
host-10-0-1-1.openstacklocal (10.0.1.1) aadressil fa:16:3e:e6:2c:5c [ether]  eth0 peal
host-10-0-1-90.openstacklocal (10.0.1.90) aadressil fa:16:3e:83:ad:a4 [ether]  eth0 peal
host-10-0-1-88.openstacklocal (10.0.1.88) aadressil fa:16:3e:72:ad:53 [ether]  eth0 peal

Nüüd vaatame, kuhu peaks liiklus minema sihtkohta (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 ~]$ 

Vaadake, kuhu viib port 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 ~]$ 

Kõik on loogiline, liiklus läheb br-tun. Vaadake, millises vxlan tunnelis see suletakse:

[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 ~]$ 

Kolmas port on vxlan tunnel:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

Mis vaatab control sõlme:

[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 ~]$ 

Liiklus jõudis control sõlme, seega peame liikuma sinna ja vaatama, kuidas marsruutimine toimub.

Kuidas te mäletate, nägi kontrollsõlm välja täpselt sama nagu compute sõlm — need samad kolm silda, ainult et br-ex-l oli füüsiline port, mille kaudu sõlm sai liiklust välja saata. Instantside loomine muutis compute sõlmede konfiguratsiooni — lisandus linux bridge, iptables ja liidesed sõlmedesse. Võrkude ja virtuaalse marsruuteri loomine jättis samuti oma jälje control sõlme konfiguratsioonile.

Seega on ilmne, et gateway'i MAC-aadress peab olema br-int edastuslauas control sõlmes. Kontrollime, et see seal on ja kuhu see vaatab:

[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 on nähtav port qr-0c52b15f-8f. Kui naasta tagasi Opensteaki virtuaalsete portide loendisse, siis seda tüüpi porti kasutatakse OVS-i ühendamiseks erinevate virtuaalsete seadmetega. Täpsemalt öeldes on qr — see port, mis viib virtuaalsesse marsruuterisse, mis esitatakse nimekonnana.

Vaadake, millised namespace'id serveris on:

[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 ~]$ 

Kokku on olemas kolm instantsi. Nende nimed viitavad nende funktsioonidele. Tagasi instantside ID 0 ja 1 juurde tuleme hiljem, aga praegu huvitab meid nimepind 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 ~]$ 

Selles nimepinnas on kaks sisemist porti, mille me varem lõime. Mõlemad virtuaalsed pordid on lisatud br-int-sse. Kontrollime porta mac-aadressi qr-0c52b15f-8f, kuna liiklus, nagu sihtmärkadress näitab, läks just sellesse liidesesse.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

See tähendab, et kõik toimib standardse marsruutimise seaduste kohaselt. Kuna liiklus on suunatud hostile 10.0.2.8, peab see minema läbi teise liidese qr-92fa49b5-54 ja minema edasi läbi vxlan tunneli compute sõlme:

[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 ~]$ 

Kõik on loogiline, ei mingit üllatust. Vaadake, kust on nähtav hosti 10.0.2.8 mac-aadress br-int-s:

[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 ~]$ 

Nagu peab olema, liiklus suundub br-tun-sse, vaatame, millisesse tunnelisse liiklus edasi läheb:

[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 ~]$ 

Liiklus suundub tunnelisse kuni compute-1. Compute-1-s on kõik lihtne — br-tun-ist jõuab pakk br-int-i ja sealt edasi virtuaalmasina liidesesse:

[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 ~]$ 

Kontrollime, et see on tõepoolest õige liidese:

[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 ~]$

Olemegi oleme läbinud terve paketi tee. Arvan, et olete märganud, et liiklus läks erinevate vxlan tunnelite kaudu ja väljus erinevate VNI-dega. Vaatame, millised need VNI-d on, seejärel kogume kontrollnode sadamal katte ja veendume, et liiklus liigub just nii nagu ülal kirjeldatud.
Nii et tunnel kuni compute-0-l on järgmised actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Tõlgime 0x16 kümnendsüsteemi:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

Tunnel kuni compute-1-l sisaldab järgmist VNI: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Tõlgime 0x63 kümnendsüsteemi:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

Nüüd vaatame katte:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: kuulamine vnet4-l, link-tüüp EN10MB (Ethernet), salvestamise suurus 262144 bait 

*****************eemaldatud*******************

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
	
*****************eemaldatud*******************

Esimene pakett on vxlan pakett hostilt 192.168.255.19 (compute-0) hostile 192.168.255.15 (control-1) vni 22, mille sees on ICMP pakett hostilt 10.0.1.85 hostile 10.0.2.8. Nagu me eespool arvutasime, vastab vni sellele, mida oleme väljundites näinud.

Teine pakett on vxlan pakett hostilt 192.168.255.15 (control-1) hostile 192.168.255.26 (compute-1) vni 99, mille sees on ICMP pakett hostilt 10.0.1.85 hostile 10.0.2.8. Nagu me eespool arvutasime, vastab vni sellele, mida oleme väljundites näinud.

Kaks järgmist paketti on tagasitee 10.0.2.8-lt 10.0.1.85-le.

Seega on meil lõpuks selline skeem control sõlme:

Tundub, et kõik? Me unustasime kaks namespace'i:

[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 ~]$ 

Kuna rääkisime pilveplatvormi arhitektuurist - oleks hea, kui masinad saaksid aadresse automaatselt DHCP serverilt. Need on kaks DHCP serverit meie kahe võrgu 10.0.1.0/24 ja 10.0.2.0/24 jaoks.

Kontrollime, et see nii on. Käesolevas namespace'is on ainult üks aadress - 10.0.1.1 - DHCP serveri aadress ja see on samuti br-int-sse kaasatud:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Vaatame, kas protsessid, mille nimedes on qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2, on control nodis:

[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 ~]$ 

Sellest protsessist lähtuvalt ja ülaltoodud väljundi põhjal saame näiteks uurida, mis meil praegu üüritakse:

[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 ~]$

Kokkuvõttes saame control nodis järgmise teenuste komplekti:

Ja pidage meeles – see on vaid 4 masinat, 2 sisevõrku ja üks virtuaalne ruuter… Meil pole siin praegu väliseid võrke, erinevaid projekte, igaühel oma võrgud (ristuvad), ning meil on välja lülitatud jaotuv ruuter. Lõppude lõpuks oli testimistoodetes vaid üks juhtnupp (tugistruktuuriks peaks olema kolm nodi). On mõistetav, et kommertsektoris on kõik natuke keerulisem, kuid selle lihtsa näite kaudu saame aru, kuidas see peaks toimima – olgu trükis 3 või 300 nimiruumi, on see loomulikult oluline, kuid kogu süsteemi töö osas ei muutu eriti midagi… tõsi, kuni te ei rakenda mingit müüja SDN-i. Kuid see on juba hoopis teine lugu.

Loodetavasti oli see huvitav. Kui teil on märkusi/täiendusi või kohta, kus ma olen selgelt vale öelnud (ma olen inimene ja minu arvamus on alati subjektiivne) – andke teada, mida parandada/täiendatunde – me parandame/täiendame kõik.

Lõpetuseks tahaksin öelda paar sõna OpenStacki (nii puhtas vormis kui ka müüjatelt) ja VMWare’i pilvelahenduse võrdlemise kohta – liiga sageli on mulle viimasel paaril aastal seda küsimust esitatud ja ma olen juba ausalt väsinud, aga siiski. Minu arvates on neid kahte lahendust väga raske võrrelda, kuid on selgelt öeldav, et mõlemas lahenduses on miinuseid ning, valides ühe, tuleks kõik plussid ja miinused hoolikalt üle kaaluda.

Kui OpenStack on kogukonna juhitud lahendus, siis VMWARe’il on õigus teha vaid seda, mida nad tahavad (loe – mida neile kasulik), ja see on loogiline – kuna nad on kommertsfirma, kes on harjunud teenima raha oma klientidelt. Kuid siin on üks suur ja paks KUID – te võite minna OpenStackilt, näiteks Nokiast, lihtsate ebamugavustega Juniperi (Contrail Cloud) lahendusele, kuid VMWare’ilt lahkuda on teil ilmselt raske. Minu jaoks näevad need kaks lahendust välja nii: OpenStack (müüjalt) on lihtne puuri, kuhu teid pannakse, kuid teil on võti ja saate igal ajal välja minna. VMWare on kuldne puur, kus võti on omanikul ja maksab teile väga kalleks.

Ma ei toeta ei esimest ega teist toodet — valite selle, mis teile sobib. Kuid kui mul oleks selline valik, siis valiksin mõlemad lahendused — VMWare IT- pilve jaoks (madalad koormused, mugav haldamine), OpenStack mõnelt müüjalt (Nokia ja Juniper pakuvad väga head lahendust võtmed kätte) — telekomipilve jaoks. Ma ei soovitaks kasutada OpenStacki puhtalt IT jaoks — see on nagu püssiga varblaste pihta tulistamine, kuid vastuväiteid selle kasutamisele, peale üleliigsuse, ma ei näe. Kuid VMWare'i kasutamine telekomis on nagu killustiku vedamine Ford Raptoriga - ilus vaadata, kuid juhil tuleb teha 10 reisiga, mitte ühega.

Minu arvates on VMWare kõige suurem puudus selle täielik suletus — ettevõte ei anna mingit teavet selle kohta, kuidas on näiteks vSAN või hüperviisori tuum üles ehitatud — see ei ole neile lihtsalt kasulik — see tähendab, et te ei saa kunagi VMWare' ekspertiks — ilma müüja toeta olete hukka määratud (kohtan sageli VMWare eksperte, kellega tõstatatakse lihtsad küsimused). Minule isiklikult tundub VMWare nagu auto ostmine, mille kapott on lukus — jah, teil võib olla spetsialiste, kes võivad vahetada järelpinge rihma, kuid kapoti avab ainult see, kes teile selle lahenduse müüs. Isiklikult ei meeldi mulle lahendused, kuhu ma ei pääse. Te võite öelda, et teil ei pruugi olla vajadust kapoti alla ronida. Jah, see on võimalik, kuid ma vaatan teid, kui peate pilve kokku panema suure funktsiooni 20-30 virtuaalmasinaga, 40-50 võrguga, millest pooled tahavad välja minna, ja teised paluvad SR-IOV kiirendust, muidu peate veel paar tosinat sellist masinat — muidu ei piisa jõudlusest.

On olemas ka teisi arvamusi, seega on vaid teie otsustada, mida valida, ja mis kõige tähtsam — teie peate oma valiku eest hiljem vastutama. See on vaid minu arvamus — inimene, kes on näinud ja käinud kätega vähemalt 4 toodet — Nokia, Juniper, Red Hat ja VMWare. Seega on mul millegagi võrrelda.

Allikas: habr.com