Debesų kompiuterija vis giliau skverbiasi į mūsų gyvenimą ir tikriausiai nėra nė vieno žmogaus, kuris bent kartą nebūtų naudojęsis jokiomis debesijos paslaugomis. Tačiau kas tiksliai yra debesis ir kaip jis veikia, mažai kas žino net idėjos lygmeniu. 5G jau tampa realybe, o telekomunikacijų infrastruktūra pradeda pereiti nuo polių sprendimų prie debesų sprendimų, kaip ir tada, kai nuo visiškai techninės įrangos sprendimų pereinama prie virtualizuotų „ramsčių“.
Šiandien kalbėsime apie vidinį debesų infrastruktūros pasaulį, ypač pažvelgsime į tinklo dalies pagrindus.
Kas yra debesis? Ta pati virtualizacija – profilio rodinys?
Daugiau nei logiškas klausimas. Ne – tai ne virtualizacija, nors be jos to nebūtų galima padaryti. Pažvelkime į du apibrėžimus:
Debesų kompiuterija (toliau – debesis) yra modelis, suteikiantis vartotojui patogią prieigą prie paskirstytų skaičiavimo išteklių, kurie turi būti įdiegti ir paleisti pagal poreikį su mažiausiu įmanomu vėlavimu ir minimaliomis paslaugų teikėjo sąnaudomis.
Virtualizacija - tai galimybė padalyti vieną fizinį subjektą (pavyzdžiui, serverį) į keletą virtualių, taip padidinant resursų panaudojimą (pavyzdžiui, turėjote 3 serverius, apkrautus 25-30 proc., po virtualizacijos gaunate 1 serverį 80-90 procentų). Natūralu, kad virtualizacija suryja dalį resursų – reikia maitinti hipervizorių, tačiau, kaip parodė praktika, žaidimas vertas žvakės. Idealus virtualizacijos pavyzdys yra VMWare, kuris puikiai paruošia virtualias mašinas arba, pavyzdžiui, KVM, kuris man labiau patinka, bet čia jau skonio reikalas.
Virtualizaciją naudojame patys to nesuvokdami, net ir geležiniai maršrutizatoriai jau naudoja virtualizaciją – pavyzdžiui, naujausioje JunOS versijoje operacinė sistema įdiegta kaip virtuali mašina ant realiojo laiko Linux platinimo (Wind River 9). Tačiau virtualizacija nėra debesis, bet debesis negali egzistuoti be virtualizacijos.
Virtualizacija yra vienas iš elementų, ant kurių yra sukurtas debesis.
Sukurti debesį paprasčiausiai surenkant kelis hipervizorius į vieną L2 domeną, pridedant porą yaml žaidimų knygelių, skirtų automatiškai užregistruoti vlan per tam tikrą įmanomą priemonę, ir įjungti kažką panašaus į orkestravimo sistemą, kad būtų automatiškai kuriamos virtualios mašinos, neveiks. Tai bus tikslesnė, bet gautas Frankenšteinas nėra tas debesis, kurio mums reikia, nors kitiems tai gali būti didžiausia svajonė. Be to, jei imsite tą patį „Openstack“, tai iš esmės vis dar yra Frankensteinas, bet gerai, kol kas apie tai nekalbėkime.
Bet aš suprantu, kad iš aukščiau pateikto apibrėžimo nėra visiškai aišku, kas iš tikrųjų gali būti vadinama debesiu.
Todėl NIST (Nacionalinio standartų ir technologijų instituto) dokumente pateikiamos 5 pagrindinės debesų infrastruktūros savybės:
Paslauga teikiama pagal pageidavimą. Vartotojui turi būti suteikta nemokama prieiga prie jam skirtų kompiuterio resursų (pvz., tinklų, virtualių diskų, atminties, procesoriaus branduolių ir kt.), o šie ištekliai turi būti teikiami automatiškai – tai yra be paslaugų teikėjo įsikišimo.
Platus paslaugos prieinamumas. Prieiga prie išteklių turi būti užtikrinta naudojant standartinius mechanizmus, kad būtų galima naudoti ir standartinius asmeninius kompiuterius, ir plonuosius klientus, ir mobiliuosius įrenginius.
Išteklių sujungimas į telkinius. Išteklių telkiniai turi turėti galimybę teikti išteklius keliems klientams tuo pačiu metu, užtikrinant, kad klientai būtų izoliuoti ir be abipusės įtakos bei konkurencijos dėl išteklių. Tinklai taip pat yra įtraukti į telkinius, o tai rodo galimybę naudoti persidengiantį adresavimą. Baseinai turi būti keičiami pagal poreikį. Baseinų naudojimas leidžia užtikrinti reikiamą resursų atsparumo gedimams lygį ir fizinių bei virtualių išteklių paėmimą – paslaugos gavėjui tiesiog suteikiamas jo pageidaujamas išteklių rinkinys (kur šie ištekliai yra fiziškai, kiek serveriai ir komutatoriai – klientui tai nesvarbu). Tačiau turime atsižvelgti į tai, kad paslaugų teikėjas turi užtikrinti skaidrų šių išteklių rezervavimą.
Greitas prisitaikymas prie įvairių sąlygų. Paslaugos turi būti lanksčios – greitas resursų aprūpinimas, jų perskirstymas, resursų papildymas ar mažinimas pagal kliento pageidavimą, o iš kliento pusės turėtų būti jausmas, kad debesų resursų yra begalė. Pavyzdžiui, kad būtų lengviau suprasti, nematote įspėjimo, kad dalis jūsų disko vietos „Apple iCloud“ dingo, nes sugedo serveryje esantis standusis diskas, o diskai sugenda. Be to, iš jūsų pusės šios paslaugos galimybės beveik neribotos – reikia 2 TB – jokių problemų, sumokėjote ir gavote. Panašus pavyzdys gali būti pateiktas naudojant Google.Drive arba Yandex.Disk.
Galimybė išmatuoti teikiamą paslaugą. Debesų sistemos turi automatiškai valdyti ir optimizuoti sunaudojamus išteklius, o šie mechanizmai turi būti skaidrūs tiek vartotojui, tiek paslaugų teikėjui. Tai reiškia, kad visada galite patikrinti, kiek išteklių sunaudojate jūs ir jūsų klientai.
Verta atsižvelgti į tai, kad šie reikalavimai dažniausiai yra keliami viešajam debesiui, todėl privačiam debesiui (tai yra debesiui, paleistam įmonės vidiniams poreikiams) šie reikalavimai gali būti šiek tiek pakoreguoti. Tačiau jas vis tiek reikia padaryti, kitaip negausime visų debesų kompiuterijos privalumų.
Kodėl mums reikia debesies?
Tačiau bet kokia nauja ar esama technologija, bet koks naujas protokolas yra kuriamas kažkam (na, išskyrus RIP-ng, žinoma). Niekam nereikia protokolo dėl protokolo (na, išskyrus RIP-ng, žinoma). Logiška, kad debesis sukurtas tam, kad vartotojui/klientui teiktų tam tikras paslaugas. Visi esame susipažinę su bent keliomis debesies paslaugomis, pavyzdžiui, Dropbox arba Google.Docs, ir manau, kad dauguma žmonių sėkmingai jomis naudojasi – pavyzdžiui, šis straipsnis buvo parašytas naudojant Google.Docs debesies paslaugą. Tačiau mums žinomos debesies paslaugos yra tik dalis debesies galimybių – tiksliau, tai tik SaaS tipo paslauga. Debesijos paslaugą galime teikti trimis būdais: SaaS, PaaS arba IaaS forma. Kokios paslaugos jums reikia, priklauso nuo jūsų norų ir galimybių.
Pažvelkime į kiekvieną iš eilės:
Programinė įranga kaip paslauga (SaaS) yra visavertės paslaugos teikimo klientui modelis, pavyzdžiui, el. pašto paslauga, tokia kaip „Yandex.Mail“ arba „Gmail“. Šiame paslaugų teikimo modelyje jūs, kaip klientas, iš tikrųjų nieko nedarote, tik naudojatės paslaugomis – tai yra, jums nereikia galvoti apie paslaugos sukūrimą, jos atsparumą gedimams ar perteklių. Svarbiausia nepakenkti slaptažodžiui; visa kita už jus padarys šios paslaugos teikėjas. Paslaugų teikėjo požiūriu, jis yra visiškai atsakingas už visą paslaugą – nuo serverio techninės ir pagrindinių operacinių sistemų iki duomenų bazės ir programinės įrangos nustatymų.
Platforma kaip paslauga (PaaS) - naudojant šį modelį, paslaugų teikėjas klientui pateikia ruošinį paslaugai, pavyzdžiui, paimkime žiniatinklio serverį. Paslaugų teikėjas suteikė klientui virtualų serverį (tiesą sakant, resursų rinkinį, pvz., RAM/CPU/Storage/Nets ir kt.) ir netgi įdiegė šiame serveryje OS bei reikalingą programinę įrangą, tačiau visa tai atlieka pats klientas, o už paslaugos atlikimą klientas atsako. Paslaugų teikėjas, kaip ir ankstesniu atveju, yra atsakingas už fizinės įrangos, hipervizorių, pačios virtualios mašinos veikimą, jos tinklo pasiekiamumą ir pan., tačiau pati paslauga nebėra jo atsakomybės sferoje.
Infrastruktūra kaip paslauga (IaaS) - Toks požiūris jau įdomesnis, iš tikrųjų paslaugų teikėjas suteikia klientui visą virtualizuotą infrastruktūrą - tai yra tam tikrą išteklių rinkinį (bandą), pvz., CPU branduolius, RAM, tinklus ir tt Visa kita priklauso nuo klientas – ką klientas nori daryti su šiais ištekliais per paskirtą telkinį (kvotą) – tiekėjui tai nėra ypač svarbu. Nesvarbu, ar klientas nori sukurti savo vEPC, ar net sukurti mini operatorių ir teikti ryšio paslaugas – nekyla klausimų – padarykite tai. Tokiu atveju paslaugų teikėjas yra atsakingas už išteklių aprūpinimą, jų atsparumą gedimams ir prieinamumą, taip pat OS, leidžiančią sujungti šiuos išteklius ir padaryti juos prieinamus klientui, kad būtų galima bet kada padidinti arba sumažinti išteklius. kliento pageidavimu. Klientas pats konfigūruoja visas virtualias mašinas ir kitus dalykus per savitarnos portalą ir konsolę, įskaitant tinklų (išskyrus išorinius tinklus) nustatymą.
Kas yra OpenStack?
Visuose trijuose variantuose paslaugų teikėjui reikalinga OS, kuri leistų sukurti debesų infrastruktūrą. Tiesą sakant, su SaaS daugiau nei vienas padalinys yra atsakingas už visą krūvą technologijų – yra padalinys, atsakingas už infrastruktūrą – tai yra, jis teikia IaaS kitam padaliniui, šis padalinys klientui teikia SaaS. „OpenStack“ yra viena iš debesies operacinių sistemų, leidžiančių surinkti daugybę jungiklių, serverių ir saugojimo sistemų į vieną išteklių telkinį, padalinti šį bendrą telkinį į subpoolius (nuomininkus) ir teikti šiuos išteklius klientams tinkle.
OpenStack yra debesų operacinė sistema, leidžianti valdyti didelius skaičiavimo išteklių, duomenų saugyklos ir tinklo išteklių telkinius, aprūpintus ir valdomus per API naudojant standartinius autentifikavimo mechanizmus.
Kitaip tariant, tai yra nemokamos programinės įrangos projektų rinkinys, skirtas kurti debesijos paslaugas (tiek viešas, tiek privačias) – tai yra įrankių rinkinys, leidžiantis sujungti serverį ir perjungimo įrangą į vieną išteklių telkinį, valdyti. šių išteklių, užtikrinant reikiamą atsparumo gedimams lygį.
Šios medžiagos rašymo metu „OpenStack“ struktūra atrodo taip:
Nuotrauka daryta iš
Kiekvienas „OpenStack“ komponentas atlieka tam tikrą funkciją. Ši paskirstyta architektūra leidžia į sprendimą įtraukti reikalingų funkcinių komponentų rinkinį. Tačiau kai kurie komponentai yra šakniniai komponentai ir jų pašalinimas sukels visišką arba dalinį viso sprendimo neveikimą. Šie komponentai paprastai skirstomi į:
- Prietaisų skydas – Internetinė GUI, skirta „OpenStack“ paslaugoms valdyti
- Pagrindinis principas yra centralizuota tapatybės paslauga, teikianti kitų paslaugų autentifikavimo ir autorizacijos funkcijas, taip pat tvarko vartotojų kredencialus ir jų vaidmenis.
- neutronas - tinklo paslauga, suteikianti ryšį tarp įvairių „OpenStack“ paslaugų sąsajų (įskaitant ryšį tarp VM ir jų prieigą prie išorinio pasaulio)
- žarijos - suteikia prieigą prie virtualių mašinų blokų saugyklos
- Naujas — virtualių mašinų gyvavimo ciklo valdymas
- Žvilgsnis — virtualios mašinos vaizdų ir momentinių vaizdų saugykla
- greitai — suteikia prieigą prie saugojimo objekto
- Ceilometras — paslauga, suteikianti galimybę rinkti telemetriją ir matuoti turimus bei sunaudotus išteklius
- šiluma — orkestravimas, pagrįstas automatinio išteklių kūrimo ir aprūpinimo šablonais
Visą visų projektų sąrašą ir jų paskirtį galite peržiūrėti .
Kiekvienas „OpenStack“ komponentas yra paslauga, atliekanti tam tikrą funkciją ir teikianti API, skirtą tai funkcijai valdyti ir sąveikauti su kitomis debesies operacinės sistemos paslaugomis, kad būtų sukurta vieninga infrastruktūra. Pavyzdžiui, „Nova“ teikia skaičiavimo išteklių valdymą ir API, skirtą prieigai prie šių išteklių konfigūravimo, „Glance“ teikia vaizdų valdymą ir API jiems tvarkyti, „Cinder“ – blokų saugyklą ir API, skirtą jai valdyti ir t. t. Visos funkcijos yra labai glaudžiai tarpusavyje susijusios.
Tačiau, jei pažvelgsite į tai, visos „OpenStack“ veikiančios paslaugos galiausiai yra tam tikra virtuali mašina (arba konteineris), prijungtas prie tinklo. Kyla klausimas – kam mums reikia tiek daug elementų?
Peržiūrėkime algoritmą, kaip sukurti virtualią mašiną ir prijungti ją prie tinklo bei nuolatinės saugyklos „Openstack“.
- Kai sukuriate užklausą sukurti įrenginį, nesvarbu, ar tai būtų užklausa per „Horizon“ (prietaisų skydelį), ar užklausa per CLI, pirmas dalykas, kuris nutinka, yra jūsų užklausos autorizacija „Keystone“ – ar galite sukurti įrenginį, ar jis turi teisę naudotis šiuo tinklu, ar jūsų kvotos projektas ir pan.
- Keystone autentifikuoja jūsų užklausą ir atsakymo pranešime sugeneruoja autentifikavimo prieigos raktą, kuris bus naudojamas toliau. Gavus atsakymą iš Keystone, užklausa siunčiama link Nova (nova api).
- Nova-api patikrina jūsų užklausos galiojimą susisiekdama su Keystone naudodama anksčiau sugeneruotą autentifikavimo prieigos raktą
- Keystone atlieka autentifikavimą ir teikia informaciją apie leidimus ir apribojimus pagal šį autentifikavimo prieigos raktą.
- Nova-api sukuria naujos VM įrašą nova-duomenų bazėje ir perduoda užklausą sukurti įrenginį į nova-scheduler.
- „Nova-scheduler“ pasirenka pagrindinį kompiuterį (kompiuterio mazgą), kuriame bus įdiegta VM, atsižvelgdama į nurodytus parametrus, svorį ir zonas. Įrašas apie tai ir VM ID įrašomas į nova-duomenų bazę.
- Tada nova-scheduler susisiekia su nova-compute su prašymu įdiegti egzempliorių. Nova-compute susisiekia su nova-conductor, kad gautų informaciją apie mašinos parametrus (nova-conductor yra nova elementas, veikiantis kaip tarpinis serveris tarp nova-database ir nova-compute, ribojantis užklausų į nova-duomenų bazę skaičių, kad būtų išvengta problemų su duomenų baze konsistencijos apkrovos sumažinimas).
- Nova-conductor gauna prašomą informaciją iš nova-database ir perduoda ją nova-compute.
- Tada nova-compute iškviečia žvilgsnį, kad gautų vaizdo ID. Glace patvirtina užklausą Keystone ir grąžina prašomą informaciją.
- Nova-compute susisiekia su neutronu, kad gautų informaciją apie tinklo parametrus. Panašiai kaip žvilgsnis, neutronas patvirtina užklausą Keystone, po to sukuria įrašą duomenų bazėje (prievado identifikatorių ir pan.), sukuria užklausą sukurti prievadą ir grąžina prašomą informaciją į nova-compute.
- „Nova-compute“ susisiekia su prašymu skirti virtualiajai mašinai tomą. Panašiai kaip žvilgsnis, sidras patvirtina užklausą Keystone, sukuria tomo kūrimo užklausą ir grąžina prašomą informaciją.
- Nova-compute susisiekia su libvirt su prašymu įdiegti virtualią mašiną su nurodytais parametrais.
Tiesą sakant, iš pažiūros paprasta paprastos virtualios mašinos kūrimo operacija virsta tokiu API iškvietimų sūkuriu tarp debesų platformos elementų. Be to, kaip matote, net anksčiau paskirtos paslaugos taip pat susideda iš mažesnių komponentų, tarp kurių vyksta sąveika. Įrenginio kūrimas yra tik maža dalis to, ką leidžia debesies platforma – yra paslauga, atsakinga už srauto balansavimą, paslauga, atsakinga už blokų saugojimą, paslauga, atsakinga už DNS, paslauga, atsakinga už pliko metalo serverių aprūpinimą ir kt. Debesis leidžia su virtualiomis mašinomis elgtis kaip su avių banda (priešingai nei virtualizacija). Jei kas nors atsitiks jūsų kompiuteriui virtualioje aplinkoje - atkuriate jį iš atsarginių kopijų ir pan., tačiau debesų programos yra sukurtos taip, kad virtuali mašina neatlieka tokio svarbaus vaidmens - virtuali mašina "numirė" - jokių problemų - tiesiog sukuriama nauja transporto priemonė pagal šabloną ir, kaip sakoma, būrys nepastebėjo kovotojo praradimo. Natūralu, kad tai numato orkestravimo mechanizmų buvimą - naudodami Heat šablonus galite lengvai įdiegti sudėtingą funkciją, kurią sudaro dešimtys tinklų ir virtualių mašinų.
Visada verta nepamiršti, kad debesų infrastruktūros be tinklo nėra – kiekvienas elementas vienaip ar kitaip sąveikauja su kitais elementais per tinklą. Be to, debesyje yra absoliučiai nestatinis tinklas. Natūralu, kad apatinis tinklas yra dar daugiau ar mažiau statinis – nauji mazgai ir jungikliai nėra pridedami kiekvieną dieną, tačiau perdangos komponentas gali ir neišvengiamai nuolat keisis – bus pridedami arba ištrinami nauji tinklai, atsiras naujos virtualios mašinos, o senos. mirti. Ir kaip prisimenate iš pačioje straipsnio pradžioje pateikto debesies apibrėžimo, ištekliai vartotojui turėtų būti paskirstomi automatiškai ir kuo mažiau (ar dar geriau, be) paslaugų teikėjo įsikišimo. Tai yra, tinklo išteklių teikimo tipas, kuris dabar egzistuoja kaip priekinė dalis jūsų asmeninės paskyros, pasiekiamos per http/https ir budinčio tinklo inžinieriaus Vasilijaus, forma, nėra debesis, netgi jei Vasilijus turi aštuonias rankas.
Neutron, kaip tinklo paslauga, teikia API debesų infrastruktūros tinklo daliai valdyti. Paslauga įgalina ir valdo „Openstack“ tinklo dalį, teikdama abstrakcijos sluoksnį, vadinamą „Network-as-a-Service“ (NaaS). Tai yra, tinklas yra toks pat virtualus išmatuojamas vienetas, kaip, pavyzdžiui, virtualūs procesoriaus branduoliai arba RAM kiekis.
Tačiau prieš pereidami prie „OpenStack“ tinklo dalies architektūros, pasvarstykime, kaip šis tinklas veikia „OpenStack“ ir kodėl tinklas yra svarbi ir neatsiejama debesies dalis.
Taigi turime dvi RED klientų VM ir dvi GREEN klientų VM. Tarkime, kad šios mašinos yra dviejuose hipervizoriuose tokiu būdu:
Šiuo metu tai tik 4 serverių virtualizavimas ir nieko daugiau, nes iki šiol viskas, ką padarėme, tai virtualizavome 4 serverius, patalpindami juos į du fizinius serverius. Ir kol kas jie net neprisijungę prie tinklo.
Norėdami sukurti debesį, turime pridėti keletą komponentų. Pirmiausia virtualizuojame tinklo dalį – reikia sujungti šias 4 mašinas poromis, o klientai nori L2 ryšio. Galite naudoti jungiklį ir sukonfigūruoti kamieną jo kryptimi ir viską išspręsti naudodami linux tiltą arba, labiau pažengusiems vartotojams, openvswitch (prie to grįšime vėliau). Tačiau tinklų gali būti daug ir nuolat stumti L2 per jungiklį nėra pati geriausia mintis – yra skirtingi skyriai, aptarnavimo stalas, mėnesiai laukimo, kol paraiška bus užpildyta, savaitės trikčių šalinimo – šiuolaikiniame pasaulyje tai metodas nebeveikia. Ir kuo anksčiau įmonė tai supras, tuo lengviau jai judėti į priekį. Todėl tarp hipervizorių pasirinksime L3 tinklą, per kurį bendraus mūsų virtualios mašinos, o ant šio L3 tinklo kursime virtualius L2 perdangos tinklus, kuriuose veiks mūsų virtualių mašinų srautas. Kaip inkapsuliaciją galite naudoti GRE, Geneve arba VxLAN. Kol kas sutelkime dėmesį į pastarąjį, nors jis nėra ypač svarbus.
Turime kažkur rasti VTEP (tikiuosi, visi yra susipažinę su VxLAN terminologija). Kadangi turime L3 tinklą, ateinantį tiesiai iš serverių, niekas netrukdo VTEP patalpinti pačiuose serveriuose, o OVS (OpenvSwitch) puikiai tai daro. Dėl to gavome tokį dizainą:
Kadangi srautas tarp VM turi būti padalintas, prievadai į virtualias mašinas turės skirtingus VLAN numerius. Žymos numeris vaidina svarbų vaidmenį tik viename virtualiame jungiklyje, nes įdėtą į VxLAN galime lengvai jį pašalinti, nes turėsime VNI.
Dabar galime be jokių problemų sukurti jiems savo mašinas ir virtualius tinklus.
Tačiau ką daryti, jei klientas turi kitą įrenginį, bet yra kitame tinkle? Mums reikia įsišaknijimo tarp tinklų. Pažiūrėsime į paprastą variantą, kai naudojamas centralizuotas maršrutizavimas – tai yra, srautas nukreipiamas per specialius tam skirtus tinklo mazgus (na, kaip taisyklė, jie derinami su valdymo mazgais, todėl turėsime tą patį).
Atrodo, nieko sudėtingo - valdymo mazge sukuriame tilto sąsają, nukreipiame srautą į jį ir iš ten nukreipiame jį ten, kur reikia. Tačiau problema ta, kad RED klientas nori naudoti 10.0.0.0/24 tinklą, o GREEN klientas nori naudoti 10.0.0.0/24 tinklą. Tai yra, mes pradedame kirsti adresų erdves. Be to, klientai nenori, kad kiti klientai galėtų patekti į jų vidinius tinklus, o tai logiška. Norėdami atskirti tinklus ir kliento duomenų srautą, kiekvienam iš jų skirsime atskirą vardų erdvę. Vardų erdvė iš tikrųjų yra „Linux“ tinklo krūvos kopija, tai yra, klientai vardų erdvėje RED yra visiškai atskirti nuo klientų, esančių vardų erdvėje GREEN (gerai, maršrutas tarp šių klientų tinklų leidžiamas naudojant numatytąją vardų erdvę arba priešsrovinėje transporto įrangoje).
Tai yra, gauname tokią diagramą:
L2 tuneliai susilieja iš visų skaičiavimo mazgų į valdymo mazgą. mazgas, kuriame yra šių tinklų L3 sąsaja, kurių kiekvienas yra atskirtoje vardų erdvėje.
Tačiau pamiršome svarbiausią dalyką. Virtuali mašina turi teikti paslaugą klientui, tai yra, turi turėti bent vieną išorinę sąsają, per kurią ją būtų galima pasiekti. Tai yra, mums reikia išeiti į išorinį pasaulį. Čia yra įvairių variantų. Paimkime paprasčiausią variantą. Prie kiekvieno kliento pridėsime po vieną tinklą, kuris galios tiekėjo tinkle ir nepersidengs su kitais tinklais. Tinklai taip pat gali susikirsti ir pažvelgti į skirtingus VRF teikėjo tinklo pusėje. Tinklo duomenys taip pat bus kiekvieno kliento vardų erdvėje. Tačiau jie vis tiek išeis į išorinį pasaulį per vieną fizinę (arba ryšį, kas yra logiškesnė) sąsają. Siekiant atskirti kliento srautą, srautas, einantis iš išorės, bus pažymėtas klientui priskirta VLAN žyma.
Kaip rezultatas, mes gavome šią diagramą:
Pagrįstas klausimas, kodėl nesukūrus šliuzų pačiuose skaičiavimo mazguose? Tai nėra didelė problema, be to, jei įjungsite paskirstytą maršrutizatorių (DVR), tai veiks. Šiame scenarijuje svarstome paprasčiausią variantą su centralizuotu šliuzu, kuris pagal numatytuosius nustatymus naudojamas Openstack. Didelės apkrovos funkcijoms jie naudos ir paskirstytą maršrutizatorių, ir pagreičio technologijas, tokias kaip SR-IOV ir Passthrough, tačiau, kaip sakoma, tai visiškai kita istorija. Pirmiausia panagrinėkime pagrindinę dalį, o tada eikime į detales.
Tiesą sakant, mūsų schema jau veikia, tačiau yra keletas niuansų:
- Turime kažkaip apsaugoti savo mašinas, tai yra įdėti filtrą į jungiklio sąsają kliento atžvilgiu.
- Leiskite virtualiai mašinai automatiškai gauti IP adresą, kad jums nereikėtų kiekvieną kartą prisijungti per konsolę ir registruoti adresą.
Pradėkime nuo mašinos apsaugos. Tam galite naudoti banalius iptables, kodėl gi ne.
Tai yra, dabar mūsų topologija tapo šiek tiek sudėtingesnė:
Eikime toliau. Turime pridėti DHCP serverį. Idealiausia vieta rasti DHCP serverius kiekvienam klientui būtų jau minėtas valdymo mazgas, kuriame yra vardų erdvės:
Tačiau yra nedidelė problema. Ką daryti, jei viskas persikraus ir dings visa informacija apie adresų nuomą DHCP. Logiška, kad aparatams bus suteikti nauji adresai, o tai nėra labai patogu. Čia yra dvi išeitys - arba naudokite domenų vardus ir kiekvienam klientui pridėkite DNS serverį, tada adresas mums nebus ypač svarbus (panašiai kaip tinklo dalis k8s) - tačiau yra problema su išoriniais tinklais, nes adresus juose galima išduoti ir per DHCP - reikia sinchronizavimo su DNS serveriais debesies platformoje ir išoriniu DNS serveriu, kuris mano nuomone nėra labai lankstus, bet visai įmanomas. Arba antras variantas yra naudoti metaduomenis – tai yra išsaugoti informaciją apie aparatui išduotą adresą, kad DHCP serveris žinotų, kurį adresą jam išduoti, jei aparatas jau gavo adresą. Antrasis variantas yra paprastesnis ir lankstesnis, nes leidžia išsaugoti papildomą informaciją apie automobilį. Dabar prie diagramos pridėkime agento metaduomenis:
Kitas klausimas, kurį taip pat verta aptarti, yra galimybė visiems klientams naudoti vieną išorinį tinklą, nes išoriniai tinklai, jei jie turi galioti visame tinkle, bus sudėtingi – reikia nuolat paskirstyti ir kontroliuoti šių tinklų paskirstymą. Galimybė naudoti vieną išorinį iš anksto sukonfigūruotą tinklą visiems klientams bus labai naudinga kuriant viešą debesį. Taip bus lengviau įdiegti mašinas, nes mums nereikės ieškoti adresų duomenų bazės ir pasirinkti unikalios adresų erdvės kiekvienam kliento išoriniam tinklui. Be to, galime iš anksto užregistruoti išorinį tinklą, o diegimo metu mums tereikės susieti išorinius adresus su kliento kompiuteriais.
Ir čia mums į pagalbą ateina NAT – mes tiesiog suteiksime klientams galimybę pasiekti išorinį pasaulį per numatytąją vardų erdvę naudodami NAT vertimą. Na, čia yra maža problema. Tai gerai, jei kliento serveris veikia kaip klientas, o ne kaip serveris – tai yra, jis inicijuoja, o ne priima ryšius. Bet mums bus atvirkščiai. Šiuo atveju turime atlikti paskirties NAT, kad gaudamas srautą valdymo mazgas suprastų, kad šis srautas skirtas kliento A virtualiai mašinai A, o tai reiškia, kad turime atlikti NAT vertimą iš išorinio adreso, pavyzdžiui, 100.1.1.1. .10.0.0.1, vidiniu adresu 100. Šiuo atveju, nors visi klientai naudosis tuo pačiu tinklu, vidinė izoliacija yra visiškai išsaugota. Tai reiškia, kad valdymo mazge turime atlikti dNAT ir sNAT. Ar naudoti vieną tinklą su slankiaisiais adresais, ar išorinius tinklus, ar abu iš karto, priklauso nuo to, ką norite įtraukti į debesį. Prie diagramos nepridėsime slankiųjų adresų, o paliksime jau anksčiau pridėtus išorinius tinklus - kiekvienas klientas turi savo išorinį tinklą (schemoje jie nurodyti kaip vlan 200 ir XNUMX išorinėje sąsajoje).
Dėl to gavome įdomų ir kartu gerai apgalvotą sprendimą, kuris turi tam tikrą lankstumą, bet dar neturi gedimų tolerancijos mechanizmų.
Pirma, turime tik vieną valdymo mazgą – jo gedimas sukels visų sistemų žlugimą. Norėdami išspręsti šią problemą, turite sudaryti bent 3 mazgų kvorumą. Pridėkime prie diagramos:
Natūralu, kad visi mazgai yra sinchronizuojami ir kai aktyvus mazgas pasitraukia, kitas mazgas perims jo pareigas.
Kita problema yra virtualios mašinos diskai. Šiuo metu jie saugomi pačiuose hipervizoriuose, o iškilus problemoms su hipervizoriumi prarandame visus duomenis – o reidas čia nepadės, jei prarasime ne diską, o visą serverį. Norėdami tai padaryti, turime sukurti paslaugą, kuri veiktų kaip tam tikros rūšies saugyklos priekinė dalis. Kokia tai bus saugykla, mums nėra ypač svarbu, tačiau ji turėtų apsaugoti mūsų duomenis nuo disko ir mazgo, o galbūt ir visos spintos gedimo. Čia yra keletas variantų - žinoma, yra SAN tinklai su Fibre Channel, bet būkime atviri - FC jau yra praeities reliktas - E1 analogas transporte - taip, sutinku, jis vis dar naudojamas, bet tik ten, kur be jo visiškai neįmanoma. Todėl 2020 m. savanoriškai nediegčiau FC tinklo, žinodamas, kad yra ir kitų įdomesnių alternatyvų. Nors kiekvienam savo, bet gali būti manančių, kad FC su visais jo apribojimais yra viskas, ko mums reikia – nesiginčysiu, kiekvienas turi savo nuomonę. Tačiau, mano nuomone, įdomiausias sprendimas yra naudoti SDS, pvz., Ceph.
Ceph leidžia jums sukurti labai prieinamą duomenų saugojimo sprendimą su daugybe galimų atsarginių kopijų kūrimo parinkčių, pradedant kodais su pariteto tikrinimu (analogiškai kaip RAID 5 arba 6), baigiant visišku duomenų replikavimu į skirtingus diskus, atsižvelgiant į diskų vietą serveriai ir serveriai spintelėse ir kt.
Norint sukurti Ceph, reikia dar 3 mazgų. Sąveika su saugykla taip pat bus vykdoma per tinklą, naudojant blokų, objektų ir failų saugojimo paslaugas. Prie schemos pridėkime saugyklos vietos:
Pastaba: taip pat galite sukurti hiperkonverguotus skaičiavimo mazgus – tai yra kelių funkcijų derinimo viename mazge koncepcija – pavyzdžiui, saugykla+skaičiavimas – neskiriant specialių mazgų ceph saugojimui. Gausime tą pačią gedimams atsparią schemą – kadangi SDS rezervuos duomenis mūsų nurodytu rezervavimo lygiu. Tačiau hiperkonverguoti mazgai visada yra kompromisas – kadangi saugojimo mazgas ne tik šildo orą, kaip atrodo iš pirmo žvilgsnio (kadangi jame nėra virtualių mašinų), jis išleidžia procesoriaus išteklius SDS aptarnavimui (iš tikrųjų daro viską replikacija ir atkūrimas po mazgų, diskų ir kt. gedimų). Tai yra, jūs prarasite dalį skaičiavimo mazgo galios, jei sujungsite jį su saugykla.
Visus šiuos dalykus reikia kažkaip valdyti – mums reikia kažko, per kurį galėtume sukurti mašiną, tinklą, virtualų maršruto parinktuvą ir pan. Norėdami tai padaryti, į valdymo mazgą įtrauksime paslaugą, kuri veiks kaip prietaisų skydelis – klientas galės prisijungti prie šio portalo per http/ https ir padaryti viską, ko jam reikia (na, beveik).
Todėl dabar turime gedimams atsparią sistemą. Visi šios infrastruktūros elementai turi būti kažkaip tvarkomi. Anksčiau buvo aprašyta, kad Openstack yra projektų rinkinys, kurių kiekvienas atlieka tam tikrą funkciją. Kaip matome, elementų, kuriuos reikia konfigūruoti ir valdyti, yra daugiau nei pakankamai. Šiandien mes kalbėsime apie tinklo dalį.
Neutronų architektūra
„OpenStack“ sistemoje „Neutron“ yra atsakingas už virtualios mašinos prievadų prijungimą prie bendro L2 tinklo, srauto nukreipimo tarp skirtinguose L2 tinkluose esančių VM užtikrinimą, taip pat nukreipimą iš išorės, teikiant tokias paslaugas kaip NAT, Floating IP, DHCP ir kt.
Aukštu lygiu tinklo paslaugos (pagrindinės dalies) veikimą galima apibūdinti taip.
Paleidus VM, tinklo paslauga:
- Sukuria prievadą tam VM (ar prievadams) ir apie tai praneša DHCP tarnybai;
- Sukuriamas naujas virtualaus tinklo įrenginys (per libvirt);
- VM prisijungia prie prievado (-ų), sukurto 1 veiksme;
Kaip bebūtų keista, „Neutron“ darbas paremtas standartiniais mechanizmais, pažįstamais kiekvienam, kada nors nardžiusiam „Linux“ – vardų erdvėmis, iptables, linux tiltais, openvswitch, conntrack ir kt.
Reikėtų iš karto paaiškinti, kad „Neutron“ nėra SDN valdiklis.
Neutroną sudaro keli tarpusavyje susiję komponentai:
Openstack-neutron-server yra demonas, dirbantis su vartotojų užklausomis per API. Šis demonas nedalyvauja registruojant jokius tinklo ryšius, tačiau pateikia tam reikalingą informaciją savo įskiepiams, kurie vėliau sukonfigūruoja norimą tinklo elementą. „OpenStack“ mazgų neutronų agentai registruojasi „Neutron“ serveryje.
Neutron-serveris iš tikrųjų yra programa, parašyta python, susidedanti iš dviejų dalių:
- REST paslauga
- Neutron Plugin (pagrindinė / paslauga)
REST paslauga skirta gauti API skambučius iš kitų komponentų (pavyzdžiui, užklausą pateikti tam tikrą informaciją ir pan.)
Įskiepiai yra įskiepių programinės įrangos komponentai/moduliai, kurie iškviečiami API užklausų metu – tai yra, paslaugos priskyrimas vyksta per juos. Papildiniai skirstomi į du tipus – paslaugų ir šakninius. Paprastai arklio įskiepis yra daugiausia atsakingas už adresų erdvės ir L2 jungčių tarp VM valdymą, o paslaugų įskiepiai jau suteikia papildomų funkcijų, tokių kaip VPN arba FW.
Pavyzdžiui, galima peržiūrėti šiandien prieinamų priedų sąrašą
Gali būti keli paslaugų įskiepiai, bet gali būti tik vienas arklio įskiepis.
Openstack-neutron-ml2 yra standartinis Openstack šakninis įskiepis. Šis papildinys turi modulinę architektūrą (skirtingai nei jo pirmtakas) ir sukonfigūruoja tinklo paslaugą per prie jo prijungtas tvarkykles. Pažvelgsime į patį papildinį šiek tiek vėliau, nes iš tikrųjų jis suteikia lankstumo, kurį OpenStack turi tinklo dalyje. Galima pakeisti šakninį įskiepį (pavyzdžiui, „Contrail Networking“ atlieka tokį pakeitimą).
RPC paslauga (rabbitmq serveris) — paslauga, teikianti eilių valdymą ir sąveiką su kitomis „OpenStack“ paslaugomis, taip pat tinklo paslaugų agentų sąveiką.
Tinklo agentai — agentai, esantys kiekviename mazge, per kuriuos konfigūruojamos tinklo paslaugos.
Yra keletas agentų tipų.
Pagrindinis agentas yra L2 agentas. Šie agentai veikia kiekviename iš hipervizorių, įskaitant valdymo mazgus (tiksliau, visuose mazguose, kurie teikia bet kokias paslaugas nuomininkams), o jų pagrindinė funkcija yra prijungti virtualias mašinas prie bendro L2 tinklo, taip pat generuoti įspėjimus, kai įvyksta kokie nors įvykiai ( pavyzdžiui, išjungti / įjungti prievadą).
Kitas, ne mažiau svarbus agentas yra L3 agentas. Pagal numatytuosius nustatymus šis agentas veikia išskirtinai tinklo mazge (dažnai tinklo mazgas derinamas su valdymo mazgu) ir teikia maršrutą tarp nuomininkų tinklų (tiek tarp savo tinklų, tiek tarp kitų nuomininkų tinklų, ir yra pasiekiamas išoriniam pasauliui, NAT, taip pat DHCP paslauga). Tačiau naudojant DVR (paskirstytą maršrutizatorių), skaičiavimo mazguose atsiranda ir L3 įskiepio poreikis.
L3 agentas naudoja „Linux“ vardų sritis, kad kiekvienam nuomininkui pateiktų atskirų tinklų rinkinį ir virtualių maršrutizatorių, nukreipiančių srautą ir teikiančių šliuzo paslaugas 2 lygmens tinklams, funkcijas.
duomenų bazė — tinklų, potinklių, prievadų, telkinių ir kt. identifikatorių duomenų bazė.
Tiesą sakant, Neutron priima API užklausas iš bet kokių tinklo objektų kūrimo, autentifikuoja užklausą ir per RPC (jei pasiekia kokį nors papildinį ar agentą) arba REST API (jei jis bendrauja SDN) perduoda agentams (per papildinius) nurodymai , būtini norint organizuoti prašomą paslaugą .
Dabar pereikime prie bandomojo diegimo (kaip jis įdiegtas ir kas į jį įtraukta, pamatysime vėliau praktinėje dalyje) ir pažiūrėkime, kur yra kiekvienas komponentas:
(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 ~]$
Tiesą sakant, tai yra visa neutrono struktūra. Dabar verta skirti šiek tiek laiko ML2 papildiniui.
2 modulinis sluoksnis
Kaip minėta aukščiau, įskiepis yra standartinis OpenStack šakninis papildinys ir turi modulinę architektūrą.
ML2 įskiepio pirmtakas turėjo monolitinę struktūrą, kuri neleido, pavyzdžiui, vienoje instaliacijoje naudoti kelių technologijų derinį. Pavyzdžiui, negalėtumėte vienu metu naudoti ir openvswitch, ir linuxbridge – nei pirmojo, nei antrojo. Dėl šios priežasties buvo sukurtas ML2 įskiepis su jo architektūra.
ML2 turi du komponentus – dviejų tipų tvarkykles: tipo tvarkykles ir mechanizmo tvarkykles.
Tipo vairuotojai nustatyti technologijas, kurios bus naudojamos tinklo ryšiams organizuoti, pavyzdžiui, VxLAN, VLAN, GRE. Tuo pačiu metu vairuotojas leidžia naudoti skirtingas technologijas. Standartinė technologija yra VxLAN inkapsuliacija, skirta perdangos tinklams ir vlan išoriniams tinklams.
Tipo tvarkyklės apima šiuos tinklų tipus:
Butas - tinklas be žymėjimo
VLAN - pažymėtas tinklas
Vietinis — specialus tinklo tipas, skirtas „viskas viename“ įrenginiams (tokie įrenginiai reikalingi kūrėjams arba mokymams)
GRE — perdengti tinklą naudojant GRE tunelius
VxLAN — perdengti tinklą naudojant VxLAN tunelius
Mechanizmo vairuotojai apibrėžti įrankius, užtikrinančius tipo tvarkyklėje nurodytų technologijų organizavimą – pavyzdžiui, openvswitch, sr-iov, opendaylight, OVN ir kt.
Priklausomai nuo šios tvarkyklės įdiegimo, bus naudojami arba Neutron valdomi agentai, arba jungtys su išoriniu SDN valdikliu, kuris rūpinasi visais klausimais, susijusiais su L2 tinklų organizavimu, maršrutizavimu ir pan.
Pavyzdys: jei mes naudojame ML2 kartu su OVS, tada L2 agentas yra įdiegtas kiekviename skaičiavimo mazge, kuris valdo OVS. Tačiau jei naudojame, pavyzdžiui, OVN ar OpenDayLight, tai OVS valdymas patenka į jų jurisdikciją – Neutronas per root įskiepį duoda komandas valdikliui, ir jis jau daro tai, kas buvo liepta.
Atnaujinkime „Open vSwitch“.
Šiuo metu vienas iš pagrindinių „OpenStack“ komponentų yra „Open vSwitch“.
Diegiant „OpenStack“ be jokio papildomo tiekėjo SDN, pvz., „Juniper Contrail“ ar „Nokia Nuage“, OVS yra pagrindinis debesų tinklo tinklo komponentas ir kartu su iptables, conntrack, vardų erdvėmis leidžia organizuoti visaverčius kelių nuomos perdangų tinklus. Natūralu, kad šis komponentas gali būti pakeistas, pavyzdžiui, naudojant trečiosios šalies patentuotus (tiekėjo) SDN sprendimus.
OVS yra atvirojo kodo programinės įrangos jungiklis, skirtas naudoti virtualioje aplinkoje kaip virtualus srauto peradresatorius.
Šiuo metu OVS turi labai neblogą funkcionalumą, kuris apima tokias technologijas kaip QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK ir kt.
Pastaba: OVS iš pradžių nebuvo sukurtas kaip minkštas jungiklis labai apkrautoms telekomunikacijų funkcijoms ir buvo labiau sukurtas mažiau pralaidumo reikalaujančioms IT funkcijoms, tokioms kaip WEB serveris ar pašto serveris. Tačiau OVS yra toliau plėtojamas, o dabartinės OVS diegimos labai pagerino jo veikimą ir galimybes, o tai leidžia jį naudoti telekomunikacijų operatoriams su labai apkrautomis funkcijomis, pavyzdžiui, yra OVS diegimas su DPDK spartinimo palaikymu.
Yra trys svarbūs OVS komponentai, kuriuos turite žinoti:
- Branduolio modulis — branduolio erdvėje esantis komponentas, apdorojantis srautą pagal taisykles, gautas iš valdymo elemento;
- vSwitch demonas (ovs-vswitchd) yra vartotojo erdvėje paleidžiamas procesas, atsakingas už branduolio modulio programavimą, tai yra, jis tiesiogiai atspindi jungiklio veikimo logiką.
- Duomenų bazės serveris - vietinė duomenų bazė, esanti kiekviename pagrindiniame kompiuteryje, kuriame veikia OVS, ir kurioje saugoma konfigūracija. SDN valdikliai gali susisiekti per šį modulį naudodami OVSDB protokolą.
Visa tai lydi diagnostikos ir valdymo paslaugų rinkinys, pvz., ovs-vsctl, ovs-appctl, ovs-ofctl ir kt.
Šiuo metu „Openstack“ plačiai naudoja telekomunikacijų operatoriai, norėdami perkelti į jį tinklo funkcijas, tokias kaip EPC, SBC, HLR ir kt. Kai kurios funkcijos gali veikti be problemų su OVS, bet, pavyzdžiui, EPC apdoroja abonentų srautą – tada jis praeina. didžiulis srautas (dabar srauto apimtys siekia kelis šimtus gigabitų per sekundę). Natūralu, kad tokio srauto nukreipimas per branduolio erdvę (nes pagal nutylėjimą ten yra ekspeditorius) nėra pati geriausia idėja. Todėl OVS dažnai yra visiškai įdiegta vartotojo erdvėje, naudojant DPDK spartinimo technologiją, kad srautas būtų nukreiptas iš NIC į vartotojo erdvę, apeinant branduolį.
Pastaba: debesyje, įdiegtame telekomunikacijų funkcijoms, srautą iš skaičiavimo mazgo, apeinant OVS, galima tiesiogiai perduoti į perjungimo įrangą. Tam naudojami SR-IOV ir Passthrough mechanizmai.
Kaip tai veikia naudojant tikrąjį išdėstymą?
Na, o dabar pereikime prie praktinės dalies ir pažiūrėkime, kaip visa tai veikia praktiškai.
Pirmiausia įdiegkime paprastą „Openstack“ diegimą. Kadangi po ranka neturiu serverių rinkinio eksperimentams, prototipą surinksime viename fiziniame serveryje iš virtualių mašinų. Taip, natūralu, kad komerciniams tikslams toks sprendimas netinka, tačiau norint pamatyti pavyzdį, kaip veikia tinklas Openstack, akiai užtenka tokio įrengimo. Be to, tokia instaliacija yra dar įdomesnė mokymo tikslais - nes galite sugauti srautą ir pan.
Kadangi reikia matyti tik pagrindinę dalį, galime nenaudoti kelių tinklų, o viską pakelti naudodami tik du tinklus, o antrasis tinklas šiame makete bus naudojamas išskirtinai prieigai prie debesies ir DNS serverio. Išorinių tinklų kol kas neliesime – tai atskiro didelio straipsnio tema.
Taigi, pradėkime iš eilės. Pirma, šiek tiek teorijos. „Openstack“ įdiegsime naudodami „TripleO“ („Openstack on Openstack“). TripleO esmė ta, kad įdiegiame Openstack all-in-one (tai yra viename mazge), vadinamą undercloud, o tada panaudojame dislokuoto Openstack galimybes, kad įdiegtume Openstack, skirtą veikti, vadinamą overcloud. „Undercloud“ naudos savo gebėjimą valdyti fizinius serverius (be metalo) – projektą „Iron“, kad aprūpintų hipervizorius, kurie atliks skaičiavimo, valdymo ir saugojimo mazgų funkcijas. Tai yra, mes nenaudojame jokių trečiųjų šalių įrankių, kad įdiegtume „Openstack“ – „Openstack“ diegiame naudodami „Openstack“. Diegimo eigoje tai taps daug aiškiau, todėl tuo nesustosime ir judėsime į priekį.
Pastaba: Šiame straipsnyje dėl paprastumo nenaudojau tinklo izoliacijos vidiniams Openstack tinklams, tačiau viskas yra įdiegta naudojant tik vieną tinklą. Tačiau tinklo izoliacijos buvimas ar nebuvimas neturi įtakos pagrindiniam sprendimo funkcionalumui – viskas veiks lygiai taip pat, kaip ir naudojant izoliaciją, tačiau srautas vyks tame pačiame tinkle. Komerciniam įrengimui, žinoma, būtina naudoti izoliaciją naudojant skirtingus VLAN ir sąsajas. Pavyzdžiui, ceph saugyklos valdymo srautas ir pats duomenų srautas (mašinos prieiga prie diskų ir kt.), kai yra izoliuotas, naudoja skirtingus potinklius (Storage management ir Storage) ir tai leidžia padaryti sprendimą atsparesnį gedimams, padalijus šį srautą, pvz. , per skirtingus prievadus arba naudojant skirtingus QoS profilius skirtingam srautui, kad duomenų srautas neišstumtų signalų srauto. Mūsų atveju jie eis į tą patį tinklą ir iš tikrųjų tai mūsų niekaip neriboja.
Pastaba: kadangi ketiname paleisti virtualias mašinas virtualioje aplinkoje, pagrįstoje virtualiomis mašinomis, pirmiausia turime įjungti įdėtą virtualizaciją.
Galite patikrinti, ar įdėta virtualizacija įjungta, ar ne, kaip nurodyta toliau:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Jei matote raidę N, įgaliname įdėtojo virtualizavimo palaikymą pagal bet kurį tinkle rastą vadovą, pvz. .
Iš virtualių mašinų turime surinkti šią grandinę:
Mano atveju, norėdamas prijungti virtualias mašinas, kurios yra būsimojo diegimo dalis (ir aš jų gavau 7, bet galite apsieiti ir su 4, jei neturite daug išteklių), naudojau OpenvSwitch. Sukūriau vieną ovs tiltą ir prie jo prijungiau virtualias mašinas per prievadų grupes. Norėdami tai padaryti, sukūriau tokį xml failą:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Čia deklaruojamos trys prievadų grupės - dvi prieigas ir vienas magistralinis (pastarasis buvo reikalingas DNS serveriui, bet galite apsieiti ir be jo, arba įdiegti į pagrindinį kompiuterį – kaip jums patogiau). Tada, naudodami šį šabloną, deklaruojame savo per virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Dabar mes redaguojame hipervizoriaus prievado konfigūracijas:
[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 ~]# Pastaba: pagal šį scenarijų prievado ovs-br1 adresas nebus pasiekiamas, nes jame nėra vlan žymos. Norėdami tai išspręsti, turite išduoti komandą sudo ovs-vsctl set port ovs-br1 tag=100. Tačiau po perkrovimo ši žyma išnyks (jei kas žinos, kaip padaryti, kad ji liktų vietoje, būsiu labai dėkingas). Bet tai nėra taip svarbu, nes šio adreso mums reikės tik diegimo metu ir nereikės, kai Openstack bus visiškai įdiegtas.
Tada sukuriame debesų mašiną:
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=ttyS0Diegimo metu nustatote visus reikiamus parametrus, tokius kaip mašinos pavadinimas, slaptažodžiai, vartotojai, ntp serveriai ir pan., galite iš karto konfigūruoti prievadus, bet man asmeniškai po įdiegimo lengviau prisijungti prie mašinos per konsolę ir pataisykite reikiamus failus. Jei jau turite paruoštą vaizdą, galite jį naudoti arba daryti tai, ką aš dariau – atsisiųskite minimalų Centos 7 vaizdą ir naudokite jį VM įdiegimui.
Sėkmingai įdiegę turėtumėte turėti virtualią mašiną, kurioje galėsite įdiegti „undercloud“.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningPirmiausia įdiekite diegimo procesui reikalingus įrankius:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud diegimas
Sukuriame kamino vartotoją, nustatome slaptažodį, pridedame jį prie sudoer ir suteikiame jam galimybę vykdyti root komandas per sudo neįvedant slaptažodžio:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackDabar pagrindinio kompiuterio faile nurodome visą undercloud pavadinimą:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Tada pridedame saugyklas ir įdiegiame reikalingą programinę įrangą:
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-ansiblePastaba: jei neplanuojate įdiegti ceph, jums nereikia įvesti su ceph susijusių komandų. Aš naudojau Queens leidimą, bet galite naudoti bet kurį kitą, kuris jums patinka.
Tada nukopijuokite debesies konfigūracijos failą į vartotojo namų katalogų krūvą:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confDabar turime pataisyti šį failą, pritaikydami jį prie mūsų diegimo.
Failo pradžioje turite pridėti šias eilutes:
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 = 10Taigi, pereikime prie nustatymų:
undercloud_hostname — pilnas debesies serverio pavadinimas turi sutapti su įrašu DNS serveryje
vietinis_ip — vietinis debesų adresas, skirtas tinklo aprūpinimui
tinklo_vartai — tas pats vietinis adresas, kuris veiks kaip prieigos prie išorinio pasaulio vartai diegiant debesų mazgus, taip pat sutampa su vietiniu IP
undercloud_public_host — išorinis API adresas, priskiriamas bet koks laisvas adresas iš aprūpinimo tinklo
undercloud_admin_host vidinis API adresas, priskiriamas bet koks laisvas adresas iš aprūpinimo tinklo
undercloud_nameservers - DNS serveris
generuoti_paslaugos_sertifikatą - ši eilutė yra labai svarbi dabartiniame pavyzdyje, nes jei nenustatysite jos į false, diegimo metu gausite klaidą, problema aprašyta Red Hat klaidų sekimo priemonėje
vietinė_sąsaja tinklo aprūpinimo sąsaja. Ši sąsaja bus perkonfigūruota diegiant debesyje, todėl reikia turėti dvi sąsajas debesyje – vieną prieigai prie jos, antrą – aprūpinimui
local_mtu - MTU. Kadangi turime bandymų laboratoriją, o aš turiu 1500 MTU ant OVS komutatoriaus prievadų, būtina jį nustatyti į 1450, kad VxLAN įkapsuliuoti paketai galėtų praeiti pro
tinklo_cidr — aprūpinimo tinklas
maskuoti — NAT naudojimas norint pasiekti išorinį tinklą
masquerade_network - tinklas, kuris bus prijungtas prie NAT
dhcp_start — pradinis adresų telkinio adresas, iš kurio adresai bus priskirti mazgams diegiant debesyje
dhcp_end — galutinis adresų telkinio adresas, iš kurio adresai bus priskirti mazgams diegiant debesyje
apžiūra_iprange — adresų rinkinys, reikalingas savistabai (neturėtų sutapti su pirmiau nurodytu fondu)
planer_max_attempts - maksimalus bandymų įdiegti per debesį skaičius (turi būti didesnis arba lygus mazgų skaičiui)
Aprašę failą, galite duoti komandą dislokuoti debesį:
openstack undercloud install
Procedūra trunka nuo 10 iki 30 minučių, priklausomai nuo lygintuvo. Galiausiai turėtumėte pamatyti tokią išvestį:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Šiame išvestyje rašoma, kad sėkmingai įdiegėte „undercloud“ ir dabar galite patikrinti „undercloud“ būseną ir tęsti „overcloud“ diegimą.
Jei pažvelgsite į ifconfig išvestį, pamatysite, kad atsirado nauja tilto sąsaja
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Overcloud diegimas dabar bus vykdomas per šią sąsają.
Iš toliau pateiktos išvesties matote, kad visas paslaugas turime viename mazge:
(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 |
+--------------------------+-----------+----------+Žemiau pateikiama debesų tinklo dalies konfigūracija:
(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 ~]$Overdebesų įrengimas
Šiuo metu turime tik debesis, o mazgų, iš kurių būtų surinktas debesis, nepakanka. Todėl, visų pirma, įdiegkime mums reikalingas virtualias mašinas. Diegimo metu Undercloud pats įdiegs OS ir reikiamą programinę įrangą overcloud mašinoje - tai yra, mums nereikia visiškai įdiegti mašinos, o tik sukurti jam diską (ar diskus) ir nustatyti jo parametrus - tai yra , iš tikrųjų gauname tuščią serverį be jame įdiegtos OS.
Eikime į aplanką su mūsų virtualių mašinų diskais ir sukurkime reikiamo dydžio diskus:
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 160GKadangi dirbame kaip root, turime pakeisti šių diskų savininką, kad nekiltų problemų dėl teisių:
[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]# Pastaba: jei neplanuojate diegti ceph, kad jį ištirtumėte, tada komandos nesukuria bent 3 mazgų su bent dviem diskais, bet šablone nurodo, kad bus naudojami virtualūs diskai vda, vdb ir kt.
Puiku, dabar turime apibrėžti visas šias mašinas:
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 Pabaigoje yra komanda -print-xml > /tmp/storage-1.xml, kuri sukuria xml failą su kiekvienos mašinos aprašymu /tmp/ aplanke; jei jo neįdėsite, jūsų nebus. gali atpažinti virtualias mašinas.
Dabar turime apibrėžti visas šias mašinas virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Dabar mažas niuansas – tripleO naudoja IPMI serverių valdymui diegimo ir introspekcijos metu.
Introspekcija yra aparatinės įrangos tikrinimo procesas, siekiant gauti jos parametrus, reikalingus tolesniam mazgų aprūpinimui. Introspekcija atliekama naudojant ironiją, paslaugą, skirtą darbui su pliko metalo serveriais.
Tačiau čia yra problema - nors aparatinės įrangos IPMI serveriai turi atskirą prievadą (arba bendrą prievadą, bet tai nėra svarbu), virtualiosios mašinos tokių prievadų neturi. Čia mums į pagalbą ateina ramentas, vadinamas vbmc – įrankis, leidžiantis imituoti IPMI prievadą. Į šį niuansą verta atkreipti dėmesį ypač tiems, kurie nori įsirengti tokią laboratoriją ant ESXI hipervizoriaus – tiesą pasakius, nežinau, ar jis turi vbmc analogą, todėl verta pasidomėti šia problema prieš diegiant viską. .
Įdiekite vbmc:
yum install yum install python2-virtualbmcJei jūsų OS neranda paketo, pridėkite saugyklą:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmDabar mes nustatome naudingumą. Viskas čia banalu iki gėdos. Dabar logiška, kad vbmc sąraše nėra serverių
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Kad jie būtų rodomi, jie turi būti rankiniu būdu paskelbti taip:
[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 ~]#Manau, kad komandų sintaksė aiški be paaiškinimo. Tačiau kol kas visos mūsų sesijos yra DOWN būsenos. Kad jie pereitų į UP būseną, turite juos įjungti:
[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 ~]#Ir paskutinis prisilietimas - reikia pataisyti ugniasienės taisykles (arba visiškai ją išjungti):
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
Dabar pereikime prie debesies ir patikrinkime, ar viskas veikia. Pagrindinio kompiuterio adresas yra 192.168.255.200, debesyje mes pridėjome būtiną ipmitool paketą ruošdamiesi diegimui:
[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 runningKaip matote, mes sėkmingai paleidome valdymo mazgą per vbmc. Dabar išjunkite jį ir eikime toliau:
[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 ~]#Kitas žingsnis yra mazgų, kuriuose bus įdiegtas debesis, tyrimas. Norėdami tai padaryti, turime paruošti json failą su mūsų mazgų aprašymu. Atkreipkite dėmesį, kad, skirtingai nei diegimas atviruose serveriuose, faile nurodomas prievadas, kuriame veikia vbmc kiekviename kompiuteryje.
[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:27Pastaba: valdymo mazgas turi dvi sąsajas, tačiau šiuo atveju tai nėra svarbu, šioje instaliacijoje mums užteks vienos.
Dabar ruošiame json failą. Turime nurodyti prievado, per kurį bus vykdomas aprūpinimas, adresą, mazgų parametrus, suteikti jiems pavadinimus ir nurodyti, kaip patekti į ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Dabar turime paruošti vaizdus ironijai. Norėdami tai padaryti, atsisiųskite juos naudodami wget ir įdiekite:
(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 ~]$Vaizdų įkėlimas į debesis:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Tikrinama, ar visi vaizdai įkelti
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Dar vienas dalykas – reikia pridėti 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 ~]$Dabar galime duoti savistabos komandą:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Kaip matote iš išvesties, viskas atlikta be klaidų. Patikrinkite, ar visi mazgai yra galimos būsenos:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Jei mazgai yra kitokios būsenos, paprastai valdomos, tada kažkas nutiko, todėl turite pažvelgti į žurnalą ir išsiaiškinti, kodėl taip atsitiko. Atminkite, kad pagal šį scenarijų mes naudojame virtualizaciją ir gali būti klaidų, susijusių su virtualių mašinų ar vbmc naudojimu.
Toliau turime nurodyti, kuris mazgas atliks kurią funkciją - tai yra, nurodyti profilį, su kuriuo mazgas bus įdiegtas:
(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 ~]$Nurodykite kiekvieno mazgo profilį:
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-d9afb69d1167Patikrinkite, ar viską padarėme teisingai:
(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 ~]$Jei viskas teisinga, mes suteikiame komandą dislokuoti debesį:
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 qemuRealiame diegime natūraliai bus naudojami pritaikyti šablonai, mūsų atveju tai labai apsunkins procesą, nes kiekvienas šablono redagavimas turės būti paaiškintas. Kaip buvo rašyta anksčiau, kad pamatytume, kaip tai veikia, užteks net ir paprasto įrengimo.
Pastaba: šiuo atveju būtinas --libvirt tipo qemu kintamasis, nes naudosime įdėtą virtualizaciją. Priešingu atveju negalėsite paleisti virtualių mašinų.
Dabar turite apie valandą, o gal ir daugiau (priklausomai nuo aparatinės įrangos galimybių) ir belieka tikėtis, kad po šio laiko pamatysite tokį pranešimą:
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 ~]$Dabar jūs turite beveik visavertę „openstack“ versiją, kurioje galite mokytis, eksperimentuoti ir pan.
Patikrinkite, ar viskas veikia tinkamai. Vartotojo namų katalogų krūvoje yra du failai – vienas stackrc (skirtas undercloud valdymui) ir antras overcloudrc (overcloud tvarkymui). Šie failai turi būti nurodyti kaip šaltinis, nes juose yra informacija, reikalinga autentifikavimui.
(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 ~]$Mano diegimui vis tiek reikia nedidelio prisilietimo - pridėti maršrutą valdiklyje, nes mašina, su kuria aš dirbu, yra kitame tinkle. Norėdami tai padaryti, eikite į „control-1“ „heat-admin“ paskyroje ir užregistruokite maršrutą
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Na, dabar galite eiti į horizontą. Visa informacija – adresai, prisijungimo vardas ir slaptažodis – yra faile /home/stack/overcloudrc. Galutinė diagrama atrodo taip:
Beje, mūsų instaliacijoje mašinų adresai buvo išduodami per DHCP ir, kaip matote, išduodami „atsitiktinai“. Jei reikia, šablone galite griežtai apibrėžti, kuris adresas prie kurio įrenginio turi būti prijungtas diegiant.
Kaip srautas vyksta tarp virtualių mašinų?
Šiame straipsnyje apžvelgsime tris pravažiuojančio eismo galimybes
- Dvi mašinos viename hipervizoriuje viename L2 tinkle
- Dvi mašinos skirtinguose hipervizoriuose tame pačiame L2 tinkle
- Dvi mašinos skirtinguose tinkluose (įsišaknijimas tarp tinklų)
Atvejai, susiję su prieiga prie išorinio pasaulio per išorinį tinklą, naudojant slankiuosius adresus, taip pat paskirstytą maršrutą, svarstysime kitą kartą, kol kas daugiausia dėmesio skirsime vidiniam srautui.
Norėdami patikrinti, sudarykite šią diagramą:
Sukūrėme 4 virtualias mašinas – 3 viename L2 tinkle – net-1 ir dar 1 tinkle net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Pažiūrėkime, kokiuose hipervizoriuose yra sukurtos mašinos:
(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 ~]$
Mašinos vm-1 ir vm-3 yra compute-0, mašinos vm-2 ir vm-4 yra mazge compute-1.
Be to, buvo sukurtas virtualus maršrutizatorius, leidžiantis nukreipti maršrutą tarp nurodytų tinklų:
(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 ~]$ Maršrutizatorius turi du virtualius prievadus, kurie veikia kaip tinklų vartai:
(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 ~]$ Tačiau prieš pažvelgdami į srauto srautus, pažiūrėkime, ką šiuo metu turime valdymo mazge (kuris taip pat yra tinklo mazgas) ir skaičiavimo mazge. Pradėkime nuo skaičiavimo mazgo.
[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 ~]$Šiuo metu mazgas turi tris ovs tiltus - br-int, br-tun, br-ex. Tarp jų, kaip matome, yra sąsajų rinkinys. Kad būtų lengviau suprasti, pavaizduokime visas šias sąsajas diagramoje ir pažiūrėkime, kas atsitiks.
Žvelgiant į adresus, į kuriuos keliami VxLAN tuneliai, matyti, kad vienas tunelis pakeltas į compute-1 (192.168.255.26), antrasis tunelis žiūri į control-1 (192.168.255.15). Bet įdomiausia tai, kad br-ex neturi fizinių sąsajų, o pažiūrėjus kokie srautai sukonfigūruoti, matyti, kad šiuo tiltu šiuo metu gali tik nuleisti srautą.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Kaip matote iš išvesties, adresas prisukamas tiesiai prie fizinio prievado, o ne prie virtualaus tilto sąsajos.
[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 ~]$
Pagal pirmąją taisyklę viskas, kas atkeliavo iš phy-br-ex prievado, turi būti išmesta.
Tiesą sakant, šiuo metu niekur kitur, kur eismas galėtų patekti į šį tiltą, išskyrus šią sąsają (sąsaja su br-int), o, sprendžiant iš kritimų, BUM srautas jau įplaukė į tiltą.
Tai reiškia, kad eismas gali išeiti iš šio mazgo tik per VxLAN tunelį ir nieko daugiau. Tačiau jei įjungsite DVR, situacija pasikeis, bet su tuo spręsime kitą kartą. Naudodami tinklo izoliaciją, pavyzdžiui, naudodami vlan, turėsite ne vieną L3 sąsają vlan 0, o kelias sąsajas. Tačiau VxLAN srautas išeis iš mazgo tokiu pačiu būdu, bet taip pat įtrauktas į tam tikrą skirtą VLAN.
Sutvarkėme skaičiavimo mazgą, pereikime prie valdymo mazgo.
[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 ~]$Tiesą sakant, galime sakyti, kad viskas yra taip pat, tačiau IP adresas yra jau ne fizinėje sąsajoje, o virtualiame tilte. Tai daroma, nes šis uostas yra uostas, per kurį srautas išeis į išorinį pasaulį.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Šis prievadas yra susietas su br-ex tiltu ir kadangi jame nėra vlan žymų, šis prievadas yra magistralinis prievadas, kuriame leidžiami visi vlan, dabar eismas vyksta be žymos, kaip nurodo vlan-id 0 išvestis aukščiau.
Visa kita šiuo metu panašu į skaičiavimo mazgą – tie patys tiltai, tie patys tuneliai, einantys į du skaičiavimo mazgus.
Šiame straipsnyje mes nenagrinėsime saugojimo mazgų, tačiau norint suprasti, reikia pasakyti, kad šių mazgų tinklo dalis yra banali iki gėdos. Mūsų atveju yra tik vienas fizinis prievadas (eth0) su jam priskirtu IP adresu ir viskas. Nėra VxLAN tunelių, tunelių tiltų ir t.t. - ovų iš viso nėra, nes nėra prasmės. Naudojant tinklo izoliaciją, šis mazgas turės dvi sąsajas (fizinius prievadus, bodny arba tik du vlanus - nesvarbu - priklauso nuo to, ko norite) - vieną valdymui, antrą srautui (rašymui į VM diską). , skaitymas iš disko ir kt.)
Mes išsiaiškinome, ką turime mazguose, nesant jokių paslaugų. Dabar paleiskite 4 virtualias mašinas ir pažiūrėkime, kaip keičiasi aukščiau aprašyta schema - turėtume turėti prievadus, virtualius maršrutizatorius ir kt.
Kol kas mūsų tinklas atrodo taip:
Kiekviename kompiuterio mazge turime dvi virtualias mašinas. Naudodami compute-0 kaip pavyzdį, pažiūrėkime, kaip viskas įtraukta.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Įrenginys turi tik vieną virtualią sąsają - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Ši sąsaja atrodo „Linux Bridge“:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Kaip matote iš išvesties, tilte yra tik dvi sąsajos - tap95d96a75-a0 ir qvb95d96a75-a0.
Čia verta šiek tiek pasilikti prie virtualaus tinklo įrenginių tipų OpenStack:
vtap – virtuali sąsaja, prijungta prie egzemplioriaus (VM)
qbr - Linux tiltas
qvb ir qvo - vEth pora, prijungta prie Linux tilto ir Open vSwitch tilto
br-int, br-tun, br-vlan – atidaryti vSwitch tiltus
patch-, int-br-, phy-br- - Atidarykite vSwitch pataisų sąsajas, jungiančias tiltus
qg, qr, ha, fg, sg – atidarykite vSwitch prievadus, kuriuos virtualūs įrenginiai naudoja prisijungdami prie OVS
Kaip suprantate, jei tilte turime qvb95d96a75-a0 prievadą, kuris yra vEth pora, tada kažkur yra jo atitikmuo, kuris logiškai turėtų būti vadinamas qvo95d96a75-a0. Pažiūrėkime, kokie prievadai yra OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Kaip matome, uostas yra br-int. Br-int veikia kaip jungiklis, nutraukiantis virtualios mašinos prievadus. Be qvo95d96a75-a0, išvestyje matomas prievadas qvo5bd37136-47. Tai yra antrosios virtualios mašinos prievadas. Dėl to mūsų diagrama dabar atrodo taip:
Klausimas, kuris iš karto turėtų sudominti dėmesingą skaitytoją – koks yra linux tiltas tarp virtualios mašinos prievado ir OVS prievado? Faktas yra tas, kad norint apsaugoti mašiną, naudojamos saugos grupės, kurios yra ne kas kita, kaip iptables. OVS neveikia su iptables, todėl buvo išrastas šis „ramentas“. Tačiau jis pasensta – naujuose leidimuose jį pakeičia conntrack.
Tai yra, galiausiai schema atrodo taip:
Dvi mašinos viename hipervizoriuje viename L2 tinkle
Kadangi šios dvi VM yra tame pačiame L2 tinkle ir tame pačiame hipervizoriuje, srautas tarp jų logiškai vyks vietoje per br-int, nes abu įrenginiai bus tame pačiame VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Dvi mašinos skirtinguose hipervizoriuose tame pačiame L2 tinkle
Dabar pažiūrėkime, kaip srautas vyks tarp dviejų mašinų tame pačiame L2 tinkle, bet skirtinguose hipervizoriuose. Tiesą sakant, niekas labai nepasikeis, tiesiog eismas tarp hipervizorių vyks vxlan tuneliu. Pažiūrėkime į pavyzdį.
Virtualių mašinų, tarp kurių stebėsime srautą, adresai:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Mes žiūrime į persiuntimo lentelę br-int 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 ~]Eismas turėtų vykti į 2 prievadą – pažiūrėkime, koks tai prievadas:
[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 ~]$Tai yra patch-tun - tai yra sąsaja br-tun. Pažiūrėkime, kas atsitiks su br-tun paketu:
[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 ~]$ Paketas supakuotas VxLAN ir siunčiamas į 2 prievadą. Pažiūrėkime, kur veda 2 prievadas:
[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 ~]$Tai yra vxlan tunelis 1 skaičiavime:
[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 ~]$Pereikime prie skaičiavimo-1 ir pažiūrėkime, kas nutiks toliau su paketu:
[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“ yra „Compute-1“ br-int persiuntimo lentelėje ir, kaip matyti iš anksčiau pateiktos išvesties, jis matomas per 2 prievadą, kuris yra prievadas link br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Na, tada matome, kad br-int compute-1 yra paskirties poppy:
[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 ~]$ Tai yra, gautas paketas skris į 3 prievadą, už kurio jau yra virtualios mašinos egzempliorius-00000003.
„Openstack“ diegimo mokymuisi virtualioje infrastruktūroje grožis yra tas, kad galime lengvai užfiksuoti srautą tarp hipervizorių ir pamatyti, kas su juo vyksta. Štai ką mes padarysime dabar, paleiskite tcpdump Vnet prievade link compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Pirmoje eilutėje parodyta, kad „Patek“ iš adreso 10.0.1.85 eina į adresą 10.0.1.88 (ICMP srautas) ir yra suvyniotas į VxLAN paketą su vni 22, o paketas eina iš pagrindinio kompiuterio 192.168.255.19 (compute-0) į pagrindinį kompiuterį 192.168.255.26 .1 ( skaičiuoti-XNUMX). Galime patikrinti, ar VNI sutampa su nurodytu ovs.
Grįžkime prie šios eilutės action=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 yra vni šešioliktainėje skaičių sistemoje. Paverskime šį skaičių į 16-ą sistemą:
16 = 6*16^0+1*16^1 = 6+16 = 22Tai yra, vni atitinka tikrovę.
Antroje eilutėje rodomas grįžtamasis srautas, na, nėra prasmės aiškinti, ten viskas aišku.
Du įrenginiai skirtinguose tinkluose (tarptinklinis maršrutas)
Paskutinis atvejis šiandien yra maršruto parinkimas tarp tinklų viename projekte naudojant virtualų maršrutizatorių. Mes svarstome atvejį be DVR (pažiūrėsime kitame straipsnyje), todėl maršruto parinkimas vyksta tinklo mazge. Mūsų atveju tinklo mazgas nėra įtrauktas į atskirą objektą ir yra valdymo mazge.
Pirmiausia pažiūrėkime, ar maršrutas veikia:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msKadangi šiuo atveju paketas turi eiti į šliuzą ir būti ten nukreiptas, turime sužinoti šliuzo MAC adresą, kuriam pavyzdyje žiūrime į ARP lentelę:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Dabar pažiūrėkime, kur turėtų būti siunčiamas srautas su paskirties vieta (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 ~]$ Pažiūrėkime, kur veda 2 prievadas:
[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 ~]$ Viskas logiška, eismas vyksta į br-tun. Pažiūrėkime, į kurį vxlan tunelį jis bus įvyniotas:
[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 ~]$ Trečiasis prievadas yra vxlan tunelis:
[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 ~]$ Kuris žiūri į valdymo mazgą:
[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 ~]$ Eismas pasiekė valdymo mazgą, todėl turime eiti į jį ir pažiūrėti, kaip vyks maršrutas.
Kaip pamenate, valdymo mazgas viduje atrodė lygiai taip pat kaip skaičiavimo mazgas – tie patys trys tiltai, tik br-ex turėjo fizinį prievadą, per kurį mazgas galėjo siųsti srautą į lauką. Kuriant egzempliorius pasikeitė skaičiavimo mazgų konfigūracija – prie mazgų buvo pridėtas linux tiltas, iptables ir sąsajos. Tinklų ir virtualaus maršrutizatoriaus sukūrimas taip pat paliko pėdsaką valdymo mazgo konfigūracijoje.
Taigi akivaizdu, kad šliuzo MAC adresas turi būti valdymo mazgo br-int persiuntimo lentelėje. Patikrinkime, ar jis ten yra ir kur jis ieško:
[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“ matomas iš prievado qr-0c52b15f-8f. Jei grįšime prie virtualių prievadų sąrašo Openstack, tai tokio tipo prievadas naudojamas įvairių virtualių įrenginių prijungimui prie OVS. Tiksliau tariant, qr yra prievadas į virtualų maršrutizatorių, kuris vaizduojamas kaip vardų erdvė.
Pažiūrėkime, kokios vardų erdvės yra serveryje:
[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 ~]$ Net trys egzemplioriai. Tačiau sprendžiant iš pavadinimų, galima atspėti kiekvieno iš jų paskirtį. Prie egzempliorių su ID 0 ir 1 grįšime vėliau, dabar mus domina vardų sritis 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 ~]$ Šioje vardų erdvėje yra dvi vidinės, kurias sukūrėme anksčiau. Abu virtualūs prievadai buvo pridėti prie br-int. Patikrinkime prievado qr-0c52b15f-8f mac adresą, nes srautas, sprendžiant pagal paskirties mac adresą, pateko į šią sąsają.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Tai yra, šiuo atveju viskas veikia pagal standartinio maršruto parinkimo dėsnius. Kadangi srautas skirtas 10.0.2.8 pagrindiniam kompiuteriui, jis turi išeiti per antrąją sąsają qr-92fa49b5-54 ir eiti per vxlan tunelį į skaičiavimo mazgą:
[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 ~]$ Viskas logiška, jokių netikėtumų. Pažiūrėkime, kur br-int matomas 10.0.2.8 pagrindinio kompiuterio poppy adresas:
[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 ~]$ Kaip ir tikėtasi, eismas vyksta į br-tun, pažiūrėkime, į kurį tunelį toliau eismas:
[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 ~]$ Eismas eina į tunelį apskaičiuoti-1. Na, o compute-1 viskas paprasta - nuo br-tun paketas patenka į br-int ir iš ten į virtualios mašinos sąsają:
[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 ~]$ Patikrinkime, ar tai tikrai teisinga sąsaja:
[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 ~]$
Tiesą sakant, mes perėjome visą paketą. Manau, kad pastebėjote, kad eismas ėjo skirtingais vxlan tuneliais ir išėjo su skirtingais VNI. Pažiūrėkime, kokie tai yra VNI, po to surinksime sąvartyną mazgo valdymo prievade ir įsitikinsime, kad srautas vyksta tiksliai taip, kaip aprašyta aukščiau.
Taigi tunelis, skirtas apskaičiuoti-0, turi šiuos veiksmus=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],išvestis:3. Konvertuokime 0x16 į dešimtainę skaičių sistemą:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunelis, skirtas apskaičiuoti-1, turi tokį VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],išvestis:2. Konvertuokime 0x63 į dešimtainę skaičių sistemą:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Na, o dabar pažiūrėkime į sąvartyną:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Pirmasis paketas yra vxlan paketas nuo pagrindinio kompiuterio 192.168.255.19 (compute-0) iki pagrindinio kompiuterio 192.168.255.15 (kontrolė-1) su vni 22, kurio viduje supakuotas ICMP paketas nuo 10.0.1.85 iki 10.0.2.8. Kaip apskaičiavome aukščiau, vni atitinka tai, ką matėme išvestyje.
Antrasis paketas yra vxlan paketas nuo pagrindinio kompiuterio 192.168.255.15 (kontrolė-1) iki pagrindinio kompiuterio 192.168.255.26 (compute-1) su vni 99, kuriame ICMP paketas supakuotas iš 10.0.1.85 į 10.0.2.8. Kaip apskaičiavome aukščiau, vni atitinka tai, ką matėme išvestyje.
Kiti du paketai yra grįžtamasis srautas iš 10.0.2.8, o ne 10.0.1.85.
Tai yra, galų gale gavome tokią valdymo mazgo schemą:
Atrodo, kad viskas? Pamiršome dvi vardų sritis:
[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 ~]$ Kaip jau kalbėjome apie debesų platformos architektūrą, būtų gerai, jei mašinos adresus gautų automatiškai iš DHCP serverio. Tai yra du DHCP serveriai, skirti mūsų tinklams 10.0.1.0/24 ir 10.0.2.0/24.
Patikrinkime, ar tai tiesa. Šioje vardų erdvėje yra tik vienas adresas - 10.0.1.1 - paties DHCP serverio adresas, jis taip pat įtrauktas į br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Pažiūrėkime, ar procesų, kurių pavadinime yra qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2, valdymo mazge:
[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 ~]$ Yra toks procesas ir, remdamiesi aukščiau pateikta informacija, galime, pavyzdžiui, pamatyti, ką šiuo metu nuomojame:
[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 ~]$Dėl to valdymo mazge gauname šį paslaugų rinkinį:
Na, atminkite – tai tik 4 mašinos, 2 vidiniai tinklai ir vienas virtualus maršrutizatorius... Mes čia dabar neturime išorinių tinklų, krūva skirtingų projektų, kurių kiekvienas turi savo tinklus (persidengiančius), ir mes turime paskirstytas maršrutizatorius išsijungė, o galų gale bandymų stende buvo tik vienas valdymo mazgas (kad būtų atsparūs gedimams, turi būti trijų mazgų kvorumas). Logiška, kad prekyboje viskas yra „šiek tiek“ sudėtingiau, tačiau šiame paprastame pavyzdyje suprantame, kaip tai turėtų veikti – žinoma, svarbu, ar turite 3 ar 300 vardų erdvių, bet visos vardų srities veikimo požiūriu. struktūra, niekas labai nepasikeis... nors kol neprijungsite kokio nors pardavėjo SDN. Bet tai visiškai kita istorija.
Tikiuosi buvo įdomu. Jei turite komentarų/papildymų, ar kur aš atvirai melavau (esu žmogus ir mano nuomonė visada bus subjektyvi) - parašykite, ką reikia taisyti/papildyti - mes viską pataisysime/pridėsime.
Baigdamas norėčiau pasakyti keletą žodžių apie „Openstack“ (ir vanilės, ir pardavėjo) palyginimą su „VMWare“ debesies sprendimu – per pastaruosius porą metų man per dažnai užduodamas šis klausimas ir, atvirai kalbant, esu jau pavargau, bet vis tiek. Mano nuomone, labai sunku palyginti šiuos du sprendimus, tačiau tikrai galime teigti, kad abu sprendimai turi trūkumų ir renkantis vieną sprendimą reikia pasverti pliusus ir minusus.
Jei OpenStack yra bendruomenės valdomas sprendimas, tai VMWare turi teisę daryti tik tai, ką nori (skaitykite – kas jai yra pelninga) ir tai logiška – nes tai komercinė įmonė, įpratusi užsidirbti iš savo klientų. Tačiau yra vienas didelis ir storas BET - galite atsikratyti OpenStack, pavyzdžiui, iš Nokia, ir su nedidelėmis išlaidomis pereiti prie sprendimo, pavyzdžiui, iš Juniper (Contrail Cloud), bet vargu ar pavyks atsikratyti VMWare. . Man šie du sprendimai atrodo taip - Openstack (pardavėjas) yra paprastas narvas, į kurį tave įkiša, bet turi raktą ir gali bet kada išeiti. VMWare yra auksinis narvas, savininkas turi raktą nuo narvelio ir tai jums kainuos daug.
Nereklamuoju nei pirmo, nei antro produkto – tu renkiesi, ko tau reikia. Bet jei turėčiau tokį pasirinkimą, rinkčiausi abu sprendimus - VMWare IT debesiui (mažos apkrovos, lengvas valdymas), OpenStack iš kurio nors tiekėjo (Nokia ir Juniper teikia labai gerus raktus sprendimus) - Telecom debesiui. „Openstack“ nenaudočiau grynai IT – tai tarsi šaudymas į žvirblius iš patrankos, bet nematau jokių kontraindikacijų jį naudoti, išskyrus atleidimą. Tačiau VMWare naudojimas telekomunikacijų srityje yra tarsi skaldos traukimas Ford Raptor – tai gražu iš išorės, tačiau vairuotojas turi atlikti 10 kelionių, o ne vieną.
Mano nuomone, didžiausias VMWare trūkumas yra visiškas uždarumas - įmonė neduos jums jokios informacijos apie tai, kaip jis veikia, pavyzdžiui, vSAN ar kas yra hipervizoriaus branduolyje - tai jam tiesiog neapsimoka - tai yra niekada netapkite VMWare ekspertu – be pardavėjo palaikymo esate pasmerktas (labai dažnai sutinku VMWare ekspertus, kuriuos glumina nereikšmingi klausimai). Man VMWare perka automobilį su užrakintu gaubtu – taip, pas jus gali būti specialistai, kurie gali pakeisti paskirstymo diržą, bet kapotą gali atidaryti tik tas, kuris jums pardavė šį sprendimą. Asmeniškai aš nemėgstu sprendimų, į kuriuos negaliu tilpti. Sakysite, kad gal ir nereikės eiti po gaubtu. Taip, tai įmanoma, bet pažiūrėsiu, kai reikės surinkti didelę funkciją debesyje iš 20-30 virtualių mašinų, 40-50 tinklų, kurių pusė nori išeiti į lauką, o antroji pusė prašo SR-IOV pagreitis, kitaip jums reikės dar poros dešimčių šių automobilių - kitaip našumo nepakaks.
Yra ir kitų požiūrių, todėl tik jūs galite nuspręsti, ką pasirinkti, ir, svarbiausia, tuomet būsite atsakingas už savo pasirinkimą. Tai tik mano nuomonė – žmogaus, kuris matė ir palietė bent 4 produktus – Nokia, Juniper, Red Hat ir VMWare. Tai yra, turiu su kuo palyginti.
Šaltinis: www.habr.com