Tölvuský er að ryðja sér dýpra og dýpra inn í líf okkar og það er líklega ekki einn einasti einstaklingur sem hefur ekki notað neina skýjaþjónustu að minnsta kosti einu sinni. Hins vegar, hvað nákvæmlega ský er og hvernig það virkar, vita fáir, jafnvel á hugmyndastigi. 5G er nú þegar að verða að veruleika og fjarskiptainnviðir eru farnir að færast frá pólalausnum yfir í skýjalausnir, alveg eins og þegar það færðist frá fullkomnum vélbúnaðarlausnum yfir í sýndargerðar „súlur“.
Í dag munum við tala um innri heim skýjainnviða, sérstaklega munum við skoða grunnatriði nethlutans.
Hvað er ský? Sama sýndarvæðing - prófílsýn?
Meira en rökrétt spurning. Nei - þetta er ekki sýndarvæðing, þó það væri ekki hægt án hennar. Við skulum skoða tvær skilgreiningar:
Cloud computing (hér eftir nefnt Cloud) er fyrirmynd til að veita notendavænan aðgang að dreifðum tölvuauðlindum sem þarf að dreifa og ræsa á eftirspurn með lægstu mögulegu leynd og lágmarkskostnaði fyrir þjónustuveituna.
Sýndarvæðing - þetta er hæfileikinn til að skipta einni líkamlegri einingu (til dæmis netþjóni) í nokkra sýndaraðila, og auka þannig nýtingu auðlinda (til dæmis, þú varst með 3 netþjóna hlaðna á 25-30 prósent, eftir sýndarvæðingu færðu 1 netþjón hlaðinn á 80-90 prósentum). Auðvitað étur sýndarvæðing upp hluta af auðlindunum - þú þarft að fæða hypervisor, hins vegar, eins og æfingin hefur sýnt, er leikurinn kertsins virði. Tilvalið dæmi um sýndarvæðingu er VMWare, sem undirbýr sýndarvélar fullkomlega, eða til dæmis KVM, sem ég kýs, en þetta er smekksatriði.
Við notum sýndarvæðingu án þess að gera okkur grein fyrir því og jafnvel járnbeinar nota nú þegar sýndarvæðingu - til dæmis er stýrikerfið sett upp sem sýndarvél ofan á rauntíma Linux dreifingu í nýjustu útgáfu JunOS (Wind River 9). En sýndarvæðing er ekki skýið, en skýið getur ekki verið til án sýndarvæðingar.
Sýndarvæðing er ein af byggingareiningunum sem skýið er byggt á.
Það virkar ekki að búa til ský með því einfaldlega að safna nokkrum yfirsýnum í eitt L2 lén, bæta við nokkrum yaml leikbókum til að skrá vlans sjálfkrafa í gegnum einhvers konar ansible og setja eitthvað eins og hljómsveitarkerfi inn á þetta allt til að búa til sýndarvélar sjálfkrafa. Það verður nákvæmara, en Frankenstein sem myndast er ekki skýið sem við þurfum, þó það gæti verið fullkominn draumur annarra. Þar að auki, ef þú tekur sama Openstack, þá er það í rauninni ennþá Frankenstein, en jæja, við skulum ekki tala um það í bili.
En mér skilst að út frá skilgreiningunni sem sett er fram hér að ofan sé ekki alveg ljóst hvað er í raun hægt að kalla ský.
Þess vegna gefur skjal frá NIST (National Institute of Standards and Technology) 5 megineinkenni sem skýjainnviði ætti að hafa:
Veitir þjónustu sé þess óskað. Notandinn verður að fá ókeypis aðgang að þeim tölvuauðlindum sem honum er úthlutað (svo sem netkerfum, sýndardiskum, minni, örgjörvakjarna o.s.frv.) og þessi úrræði verða að vera veitt sjálfkrafa - það er án afskipta þjónustuveitanda.
Mikið framboð á þjónustu. Aðgangur að auðlindum verður að vera veittur með stöðluðum aðferðum til að leyfa notkun bæði venjulegra PC-tölva og þunnra viðskiptavina og fartækja.
Að sameina auðlindir í laugar. Auðlindahópar verða að geta veitt mörgum viðskiptavinum úrræði á sama tíma og tryggt að viðskiptavinir séu einangraðir og lausir við gagnkvæm áhrif og samkeppni um auðlindir. Net eru einnig innifalin í laugunum, sem gefur til kynna möguleika á að nota skarast veffang. Sundlaugar verða að geta stækkað á eftirspurn. Notkun lauga gerir það mögulegt að veita nauðsynlega auðlindabilunarþol og útdrætti líkamlegra og sýndarauðlinda - viðtakanda þjónustunnar er einfaldlega útvegað það safn auðlinda sem hann bað um (þar sem þessar auðlindir eru líkamlega staðsettar, á hversu mörgum netþjóna og rofa - það skiptir ekki máli fyrir viðskiptavininn). Hins vegar verðum við að taka tillit til þess að veitandinn verður að tryggja gagnsæjan fyrirvara á þessum auðlindum.
Fljótleg aðlögun að mismunandi aðstæðum. Þjónusta verður að vera sveigjanleg - hröð útvegun auðlinda, endurdreifing þeirra, bæta við eða minnka auðlindir að beiðni viðskiptavinarins og af hálfu viðskiptavinarins ætti að vera tilfinning um að skýjaauðlindirnar séu endalausar. Til að auðvelda skilning, til dæmis, sérðu ekki viðvörun um að hluti af diskplássi þínu í Apple iCloud hafi horfið vegna þess að harði diskurinn á þjóninum hefur bilað og diskar bila. Þar að auki, af þinni hálfu, eru möguleikar þessarar þjónustu nánast ótakmarkaðir - þú þarft 2 TB - ekkert mál, þú borgaðir og fékkst hana. Svipað dæmi er hægt að gefa með Google.Drive eða Yandex.Disk.
Möguleiki á að mæla veitta þjónustu. Skýjakerfi verða sjálfkrafa að stjórna og hagræða neyttum auðlindum og þessar aðferðir verða að vera gagnsæar fyrir bæði notanda og þjónustuveitanda. Það er, þú getur alltaf athugað hversu mikið fjármagn þú og viðskiptavinir þínir neyta.
Það er þess virði að íhuga þá staðreynd að þessar kröfur eru að mestu leyti kröfur um almenningsský, þannig að fyrir einkaský (þ.e. ský sem er hleypt af stokkunum fyrir innri þarfir fyrirtækisins) er hægt að aðlaga þessar kröfur örlítið. Hins vegar þarf enn að gera þær, annars fáum við ekki allan ávinninginn af tölvuskýi.
Af hverju þurfum við ský?
Hins vegar, hvaða ný eða núverandi tækni, allar nýjar samskiptareglur eru búnar til fyrir eitthvað (ja, nema RIP-ng, auðvitað). Enginn þarf siðareglur vegna samskiptareglur (ja, nema RIP-ng, auðvitað). Það er rökrétt að skýið sé búið til til að veita notanda/viðskiptavini einhvers konar þjónustu. Við þekkjum öll að minnsta kosti nokkra skýjaþjónustu, til dæmis Dropbox eða Google.Docs, og ég tel að flestir noti þær með góðum árangri - til dæmis var þessi grein skrifuð með Google.Docs skýjaþjónustunni. En skýjaþjónustan sem við þekkjum er aðeins hluti af möguleikum skýsins - nánar tiltekið, þær eru aðeins SaaS-gerð þjónusta. Við getum veitt skýjaþjónustu á þrjá vegu: í formi SaaS, PaaS eða IaaS. Hvaða þjónusta þú þarft fer eftir óskum þínum og getu.
Við skulum skoða hvert í röð:
Hugbúnaður sem þjónusta (SaaS) er fyrirmynd til að veita viðskiptavinum fullgilda þjónustu, til dæmis tölvupóstþjónustu eins og Yandex.Mail eða Gmail. Í þessu þjónustumódeli gerir þú, sem viðskiptavinur, í raun ekkert nema að nota þjónustuna - það er að segja að þú þarft ekki að hugsa um uppsetningu þjónustunnar, bilanaþol hennar eða offramboð. Aðalatriðið er ekki að skerða lykilorðið þitt; veitandi þessarar þjónustu mun sjá um restina fyrir þig. Frá sjónarhóli þjónustuveitanda ber hann fulla ábyrgð á allri þjónustunni - frá vélbúnaði netþjóna og stýrikerfum til gagnagrunns- og hugbúnaðarstillinga.
Pallur sem þjónusta (PaaS) — þegar þetta líkan er notað, veitir þjónustuveitan viðskiptavininum vinnustykki fyrir þjónustuna, til dæmis, við skulum taka vefþjón. Þjónustuveitan útvegaði viðskiptavininum sýndarþjón (í rauninni safn af tilföngum, svo sem vinnsluminni/CPU/Geymsla/net o.s.frv.), og setti jafnvel upp stýrikerfið og nauðsynlegan hugbúnað á þessum netþjóni, samt sem áður stillingar allt þetta er gert af viðskiptavininum sjálfum og fyrir frammistöðu þjónustunnar sem viðskiptavinurinn svarar. Þjónustuveitan ber, eins og í fyrra tilvikinu, ábyrgð á frammistöðu efnisbúnaðar, yfirsýnar, sýndarvélarinnar sjálfrar, netframboðs hennar o.s.frv., en þjónustan sjálf er ekki lengur á ábyrgðarsviði þess.
Innviðir sem þjónusta (IaaS) - þessi nálgun er nú þegar áhugaverðari, í raun veitir þjónustuveitandinn viðskiptavininum fullkomna sýndargerða innviði - það er að segja sumt safn (safn) af auðlindum, svo sem CPU kjarna, vinnsluminni, netkerfi osfrv. Allt annað er undir höndum viðskiptavinurinn - hvað viðskiptavinurinn vill gera við þessar auðlindir innan úthlutaðs safns (kvóta) - það er ekki sérstaklega mikilvægt fyrir birginn. Hvort sem viðskiptavinurinn vill búa til sinn eigin vEPC eða jafnvel búa til smáfyrirtæki og veita samskiptaþjónustu - engin spurning - gerðu það. Í slíkri atburðarás ber þjónustuveitandinn ábyrgð á að útvega auðlindir, bilanaþol þeirra og aðgengi, svo og stýrikerfið sem gerir þeim kleift að sameina þessar auðlindir og gera þær aðgengilegar fyrir viðskiptavininn með getu til að auka eða minnka auðlindir hvenær sem er. að beiðni viðskiptavinar. Viðskiptavinurinn stillir allar sýndarvélar og annað tinsel sjálfur í gegnum sjálfsafgreiðslugáttina og stjórnborðið, þar með talið uppsetningu netkerfa (nema ytri netkerfi).
Hvað er OpenStack?
Í öllum þremur valkostunum þarf þjónustuveitandinn stýrikerfi sem gerir kleift að búa til skýjainnviði. Reyndar, með SaaS, eru fleiri en ein deild ábyrg fyrir öllum tæknistaflanum - það er deild sem er ábyrg fyrir innviðunum - það er að segja, hún veitir IaaS til annarar deildar, þessi deild veitir viðskiptavininum SaaS. OpenStack er eitt af skýjastýrikerfunum sem gerir þér kleift að safna fullt af rofum, netþjónum og geymslukerfum í einn auðlindahóp, skipta þessum sameiginlega laug í undirhópa (leigjendur) og veita þessum auðlindum til viðskiptavina yfir netið.
OpenStack er skýjastýrikerfi sem gerir þér kleift að stjórna stórum hópum af tölvuauðlindum, gagnageymslu og netauðlindum, útvegað og stjórnað í gegnum API með því að nota staðlaða auðkenningarkerfi.
Með öðrum orðum, þetta er safn ókeypis hugbúnaðarverkefna sem er hannað til að búa til skýjaþjónustu (bæði opinbera og einkaaðila) - það er sett af verkfærum sem gerir þér kleift að sameina netþjóna og skiptibúnað í einn auðlindapott, stjórna þessi úrræði, veita nauðsynlega bilanaþol.
Þegar þetta efni er skrifað lítur OpenStack uppbyggingin svona út:
Mynd tekin úr
Hver af íhlutunum sem eru í OpenStack framkvæma ákveðna aðgerð. Þessi dreifða arkitektúr gerir þér kleift að setja inn í lausnina sett af virkum íhlutum sem þú þarft. Hins vegar eru sumir íhlutir rótaríhlutir og fjarlæging þeirra mun leiða til óstarfhæfni lausnarinnar í heild eða að hluta. Þessir þættir eru venjulega flokkaðir sem:
- Mælaborð — Vefbundið GUI til að stjórna OpenStack þjónustu
- Keystone er miðlæg auðkennisþjónusta sem veitir auðkenningar- og heimildavirkni fyrir aðra þjónustu, auk þess að stjórna notendaskilríkjum og hlutverkum þeirra.
- Nifteind - netþjónusta sem veitir tengingu milli viðmóta ýmissa OpenStack þjónustu (þar á meðal tengingu milli VM og aðgang þeirra að umheiminum)
- Öskubuska — veitir aðgang að lokunargeymslu fyrir sýndarvélar
- Nova — lífsferilsstjórnun sýndarvéla
- Augnaráð — geymsla sýndarvélamynda og skyndimynda
- Swift — veitir aðgang að geymsluhlutnum
- Loftmælir — þjónusta sem veitir möguleika á að safna fjarmælingum og mæla tiltækar og notaðar auðlindir
- Heat — skipulagning byggð á sniðmátum fyrir sjálfvirka stofnun og útvegun auðlinda
Hægt er að skoða heildarlista yfir öll verkefni og tilgang þeirra .
Hver OpenStack hluti er þjónusta sem framkvæmir ákveðna aðgerð og veitir API til að stjórna þeirri aðgerð og hafa samskipti við aðra skýstýrikerfisþjónustu til að búa til sameinaðan innviði. Sem dæmi má nefna að Nova útvegar tölvuauðlindastjórnun og API fyrir aðgang að stillingum þessara tilfönga, Glance veitir myndstjórnun og API til að stjórna þeim, Cinder útvegar blokkgeymslu og API til að stjórna þeim o.s.frv. Allar aðgerðir eru samtengdar á mjög náinn hátt.
Hins vegar, ef þú horfir á það, eru allar þjónustur sem keyra í OpenStack á endanum einhvers konar sýndarvél (eða ílát) tengd netinu. Spurningin vaknar - hvers vegna þurfum við svona marga þætti?
Við skulum fara í gegnum reikniritið til að búa til sýndarvél og tengja hana við netið og viðvarandi geymslu í Openstack.
- Þegar þú býrð til beiðni um að búa til vél, hvort sem það er beiðni í gegnum Horizon (Mælaborð) eða beiðni í gegnum CLI, þá er það fyrsta sem gerist heimild fyrir beiðni þinni á Keystone - geturðu búið til vél, hefur hún rétt til að nota þetta net, gerir drög að kvóta o.s.frv.
- Keystone staðfestir beiðni þína og býr til auðkenningarmerki í svarskilaboðunum, sem verður notað frekar. Eftir að hafa fengið svar frá Keystone er beiðnin send til Nova (nova api).
- Nova-api athugar gildi beiðni þinnar með því að hafa samband við Keystone með því að nota áður myndaða auðkenningarlykilinn
- Keystone framkvæmir auðkenningu og veitir upplýsingar um heimildir og takmarkanir byggðar á þessum auðkenningarlykli.
- Nova-api býr til færslu fyrir nýja VM í nova-gagnagrunninum og sendir beiðnina um að búa til vélina til nova-scheduler.
- Nova-scheduler velur hýsilinn (tölvuhnút) sem VM verður settur á út frá tilgreindum breytum, þyngd og svæðum. Skrá um þetta og VM ID eru skrifuð í nova-gagnagrunn.
- Næst hefur nova-scheduler samband við nova-compute með beiðni um að dreifa tilviki. Nova-compute hefur samband við nova-conductor til að fá upplýsingar um færibreytur véla (nova-conductor er nova þáttur sem virkar sem proxy-þjónn á milli nova-gagnagrunns og nova-compute, takmarkar fjölda beiðna til nova-gagnagrunns til að forðast vandamál með gagnagrunninn minnkun samkvæmniálags).
- Nova-conductor fær umbeðnar upplýsingar úr nova-database og sendir þær til nova-compute.
- Næst líta nova-compute símtöl til að fá myndauðkenni. Glace staðfestir beiðnina í Keystone og skilar umbeðnum upplýsingum.
- Nova-compute hefur samband við nifteind til að fá upplýsingar um netbreytur. Svipað og í augnablikinu, staðfestir nifteind beiðnina í Keystone, eftir það býr hún til færslu í gagnagrunninum (hafnarauðkenni, osfrv.), býr til beiðni um að búa til höfn og skilar umbeðnum upplýsingum til nova-compute.
- Nova-compute tengiliðir cinder með beiðni um að úthluta magni til sýndarvélarinnar. Svipað og í augnablikinu, staðfestir cider beiðnina í Keystone, býr til beiðni um að búa til magn og skilar umbeðnum upplýsingum.
- Nova-compute tengiliðir libvirt með beiðni um að dreifa sýndarvél með tilgreindum breytum.
Reyndar breytist einföld aðgerð að því er virðist að búa til einfalda sýndarvél í svona hringiðu af API-símtölum á milli þátta skýjapallsins. Þar að auki, eins og þú sérð, samanstanda jafnvel áður tilnefnd þjónusta einnig af smærri hlutum sem samskipti eiga sér stað á milli. Að búa til vél er aðeins lítill hluti af því sem skýjapallurinn gerir þér kleift að gera - það er þjónusta sem ber ábyrgð á jafnvægi í umferð, þjónusta sem ber ábyrgð á blokkageymslu, þjónusta sem ber ábyrgð á DNS, þjónusta sem ber ábyrgð á útvegun á berum málmþjónum osfrv. Skýið gerir þér kleift að meðhöndla sýndarvélarnar þínar eins og sauðfjárhjörð (öfugt við sýndarvæðingu). Ef eitthvað kemur fyrir vélina þína í sýndarumhverfi - þú endurheimtir hana úr afritum o.s.frv., en skýjaforrit eru byggð á þann hátt að sýndarvélin gegnir ekki svo mikilvægu hlutverki - sýndarvélin „dó“ - ekkert mál - nýtt er einfaldlega búið til, farartækið er byggt á sniðmátinu og eins og sagt er tók sveitin ekki eftir tapi bardagakappans. Auðvitað, þetta gerir ráð fyrir tilvist hljómsveitarbúnaðar - með því að nota Heat sniðmát geturðu auðveldlega notað flókna aðgerð sem samanstendur af tugum neta og sýndarvéla.
Það er alltaf þess virði að hafa í huga að það er enginn skýjainnviði án netkerfis - hver þáttur hefur á einn eða annan hátt samskipti við aðra þætti í gegnum netið. Að auki hefur skýið algerlega óstöðugt net. Eðlilega er undirlagsnetið jafnvel meira og minna kyrrstætt - nýjum hnútum og rofum er ekki bætt við á hverjum degi, en yfirlagshluturinn getur og mun óhjákvæmilega breytast stöðugt - nýjum netum verður bætt við eða eytt, nýjar sýndarvélar munu birtast og gamlar munu deyja. Og eins og þú manst eftir skilgreiningunni á skýinu sem gefin var í upphafi greinarinnar, ætti að úthluta tilföngum til notandans sjálfkrafa og með minnstu (eða enn betra, án) íhlutunar frá þjónustuveitanda. Það er að segja, sú tegund af útvegun netauðlinda sem nú er til í formi framenda í formi persónulegs reiknings þíns sem er aðgengilegur í gegnum http/https og netverkfræðingur á vakt Vasily sem bakendi er ekki ský, jafnvel ef Vasily er með átta hendur.
Neutron, sem netþjónusta, veitir API til að stjórna nethluta skýjauppbyggingarinnar. Þjónustan knýr og stjórnar nethluta Openstack með því að útvega abstraktlag sem kallast Network-as-a-Service (NaaS). Það er að segja að netkerfið er sama sýndarmælanlega einingin og til dæmis sýndar örgjörvakjarnar eða magn vinnsluminni.
En áður en við förum yfir í arkitektúr nethluta OpenStack skulum við íhuga hvernig þetta net virkar í OpenStack og hvers vegna netið er mikilvægur og óaðskiljanlegur hluti af skýinu.
Þannig að við erum með tvo RED viðskiptavina VM og tvo GREEN viðskiptavinar VM. Gerum ráð fyrir að þessar vélar séu staðsettar á tveimur yfirsýnum á þennan hátt:
Í augnablikinu er þetta bara sýndarvæðing á 4 netþjónum og ekkert meira, þar sem allt sem við höfum gert er að virkja 4 netþjóna, setja þá á tvo líkamlega netþjóna. Og enn sem komið er eru þeir ekki einu sinni tengdir við netið.
Til að búa til ský þurfum við að bæta við nokkrum hlutum. Í fyrsta lagi sýndum við nethlutann - við þurfum að tengja þessar 4 vélar í pörum og viðskiptavinirnir vilja L2 tengingu. Þú getur notað rofa og stillt trunk í áttina og leyst allt með því að nota linux brú eða, fyrir lengra komna notendur, openvswitch (við munum koma aftur að þessu síðar). En það getur verið mikið af netkerfum og að ýta L2 stöðugt í gegnum rofa er ekki besta hugmyndin - það eru mismunandi deildir, þjónustuborð, margra mánaða bið eftir að umsókn verði klárað, vikna bilanaleit - í nútímanum er þetta nálgun virkar ekki lengur. Og því fyrr sem fyrirtæki skilur þetta, því auðveldara er fyrir það að komast áfram. Þess vegna munum við velja L3 net sem sýndarvélarnar okkar munu hafa samskipti í gegnum á milli yfirsýnaranna og ofan á þetta L3 net munum við byggja sýndar L2 yfirlagsnet þar sem umferð sýndarvélanna okkar mun keyra. Þú getur notað GRE, Geneve eða VxLAN sem hjúpun. Við skulum einbeita okkur að því síðarnefnda í bili, þó það sé ekki sérstaklega mikilvægt.
Við þurfum að finna VTEP einhvers staðar (ég vona að allir þekki VxLAN hugtök). Þar sem við erum með L3 net sem kemur beint frá netþjónunum kemur ekkert í veg fyrir að við setjum VTEP á netþjónana sjálfa og OVS (OpenvSwitch) er frábært í þessu. Fyrir vikið fengum við þessa hönnun:
Þar sem umferð á milli VM verður að skipta, munu portin í átt að sýndarvélunum hafa mismunandi vlan númer. Merkisnúmerið gegnir aðeins hlutverki innan eins sýndarrofa, þar sem þegar það er hjúpað í VxLAN getum við auðveldlega fjarlægt það, þar sem við verðum með VNI.
Nú getum við búið til vélarnar okkar og sýndarnet fyrir þær án vandræða.
Hins vegar, hvað ef viðskiptavinurinn er með aðra vél, en er á öðru neti? Við þurfum að róta á milli neta. Við munum skoða einfaldan valkost þegar miðlæg leið er notuð - það er, umferð er flutt í gegnum sérstaka sérstaka nethnúta (jæja, að jafnaði eru þeir sameinaðir stjórnhnútum, þannig að við munum hafa það sama).
Það virðist ekkert flókið - við gerum brúarviðmót á stjórnunarhnút, keyrum umferð að honum og þaðan leiðum við það þangað sem við þurfum. En vandamálið er að RED viðskiptavinurinn vill nota 10.0.0.0/24 netið og GREEN viðskiptavinurinn vill nota 10.0.0.0/24 netið. Það er að segja, við byrjum að skera heimilisfang rými. Að auki vilja viðskiptavinir ekki að aðrir viðskiptavinir geti farið inn á innri net sín, sem er skynsamlegt. Til að aðgreina netkerfin og gagnaumferð viðskiptavinarins munum við úthluta sérstöku nafnrými fyrir hvert þeirra. Nafnarými er í raun afrit af Linux netstaflanum, það er að segja viðskiptavinir í nafnrými RED eru algjörlega einangraðir frá viðskiptavinum frá nafnrými GREEN (jæja, annaðhvort er leið milli þessara viðskiptavinaneta leyfð í gegnum sjálfgefið nafnrými eða á andstreymis flutningsbúnaði).
Það er, við fáum eftirfarandi skýringarmynd:
L2 göng renna saman frá öllum tölvuhnútum að stjórnhnútnum. hnút þar sem L3 tengi fyrir þessi net er staðsett, hvert í sérstöku nafnrými til einangrunar.
Hins vegar gleymdum við því mikilvægasta. Sýndarvélin verður að veita viðskiptavininum þjónustu, það er að hún verður að hafa að minnsta kosti eitt ytra viðmót sem hægt er að ná í hana í gegnum. Það er að segja að við þurfum að fara út í umheiminn. Það eru mismunandi valkostir hér. Við skulum gera einfaldasta kostinn. Við munum bæta einu neti við hvern viðskiptavin, sem mun gilda í neti þjónustuveitunnar og skarast ekki við önnur net. Netkerfin geta einnig skerst og horft á mismunandi VRFs á hlið þjónustunetsins. Netgögnin munu einnig búa í nafnrými hvers viðskiptavinar. Hins vegar munu þeir samt fara út í umheiminn í gegnum eitt líkamlegt (eða tengsl, sem er rökréttara) viðmót. Til að aðgreina umferð viðskiptavinar verður umferð sem fer út merkt með VLAN merki sem er úthlutað til viðskiptavinarins.
Fyrir vikið fengum við þessa skýringarmynd:
Sanngjarn spurning er hvers vegna ekki að búa til gáttir á tölvuhnútunum sjálfum? Þetta er ekki stórt vandamál; þar að auki, ef þú kveikir á dreifða leiðinni (DVR), mun þetta virka. Í þessari atburðarás erum við að íhuga einfaldasta valkostinn með miðlægri gátt, sem er sjálfgefið notuð í Openstack. Fyrir háhleðsluaðgerðir munu þeir nota bæði dreifðan bein og hröðunartækni eins og SR-IOV og Passthrough, en eins og þeir segja, það er allt önnur saga. Fyrst skulum við takast á við grunnhlutann og síðan förum við í smáatriðin.
Reyndar er kerfið okkar nú þegar framkvæmanlegt, en það eru nokkur blæbrigði:
- Við þurfum einhvern veginn að vernda vélarnar okkar, það er að setja síu á rofaviðmótið í átt að viðskiptavininum.
- Gerðu það mögulegt fyrir sýndarvél að fá sjálfkrafa IP-tölu, svo að þú þurfir ekki að skrá þig inn á hana í gegnum stjórnborðið í hvert skipti og skrá heimilisfangið.
Byrjum á vélavörn. Fyrir þetta geturðu notað banal iptables, hvers vegna ekki.
Það er, nú er staðfræði okkar orðið aðeins flóknari:
Höldum áfram. Við þurfum að bæta við DHCP netþjóni. Besti staðurinn til að finna DHCP netþjóna fyrir hvern viðskiptavin væri stjórnunarhnúturinn sem þegar hefur verið nefndur hér að ofan, þar sem nafnrýmin eru staðsett:
Hins vegar er lítið vandamál. Hvað ef allt endurræsir sig og allar upplýsingar um að leigja heimilisföng á DHCP hverfa. Það er rökrétt að vélarnar fái ný heimilisföng, sem er ekki mjög þægilegt. Það eru tvær leiðir út hér - annaðhvort notaðu lén og bættu við DNS netþjóni fyrir hvern biðlara, þá mun heimilisfangið ekki vera sérstaklega mikilvægt fyrir okkur (svipað og nethlutinn í k8s) - en það er vandamál með ytri netkerfi, þar sem Einnig er hægt að gefa út heimilisföng í þeim í gegnum DHCP - þú þarft samstillingu við DNS netþjóna í skýjapallinum og ytri DNS netþjón, sem að mínu mati er ekki mjög sveigjanlegur, en er alveg mögulegt. Eða seinni kosturinn er að nota lýsigögn - það er að segja að vista upplýsingar um heimilisfangið sem gefið er út á vélina þannig að DHCP þjónninn viti hvaða heimilisfang á að gefa út á vélina ef vélin hefur þegar fengið heimilisfang. Annar kosturinn er einfaldari og sveigjanlegri þar sem hann gerir þér kleift að vista viðbótarupplýsingar um bílinn. Nú skulum við bæta lýsigögnum umboðsmanns við skýringarmyndina:
Annað mál sem er líka þess virði að ræða er möguleikinn á að nota eitt ytra net af öllum viðskiptavinum, þar sem ytri net, ef þau verða að gilda um allt netið, verða erfitt - þú þarft stöðugt að úthluta og stjórna úthlutun þessara neta. Hæfni til að nota eitt utanaðkomandi fyrirfram stillt net fyrir alla viðskiptavini mun vera mjög gagnlegt þegar búið er til almenningsský. Þetta mun gera það auðveldara að dreifa vélum vegna þess að við þurfum ekki að skoða heimilisfangagagnagrunn og velja einstakt heimilisfangarými fyrir ytra net hvers viðskiptavinar. Að auki getum við skráð utanaðkomandi net fyrirfram og við uppsetningu þurfum við aðeins að tengja ytri vistföng við biðlaravélar.
Og hér kemur NAT okkur til hjálpar - við munum bara gera viðskiptavinum kleift að fá aðgang að umheiminum í gegnum sjálfgefið nafnrými með því að nota NAT þýðingu. Jæja, hér er lítið vandamál. Þetta er gott ef biðlaraþjónninn virkar sem viðskiptavinur en ekki sem miðlari - það er að segja hann byrjar frekar en tekur við tengingum. En fyrir okkur verður þetta á hinn veginn. Í þessu tilviki þurfum við að gera áfangastað NAT þannig að þegar við fáum umferð skilji stjórnhnúturinn að þessi umferð er ætluð sýndarvél A viðskiptavinar A, sem þýðir að við þurfum að gera NAT þýðingu frá utanaðkomandi heimilisfangi, til dæmis 100.1.1.1 .10.0.0.1, á innra heimilisfang 100. Í þessu tilviki, þó að allir viðskiptavinir noti sama netið, er innri einangrun algjörlega varðveitt. Það er, við þurfum að gera dNAT og sNAT á stýrihnútnum. Hvort á að nota eitt net með fljótandi netföng eða ytri net, eða bæði í einu, fer eftir því hvað þú vilt koma með inn í skýið. Við munum ekki bæta fljótandi heimilisföngum við skýringarmyndina, heldur látum ytri netkerfin þegar verið bætt við fyrr - hver viðskiptavinur hefur sitt ytra net (á skýringarmyndinni eru þau sýnd sem vlan 200 og XNUMX á ytra viðmótinu).
Fyrir vikið fengum við áhugaverða og um leið úthugsaða lausn, sem hefur ákveðinn sveigjanleika en hefur enn ekki bilanaþolskerfi.
Í fyrsta lagi höfum við aðeins einn stjórnhnút - bilun hans mun leiða til hruns allra kerfa. Til að laga þetta vandamál þarftu að búa til að minnsta kosti 3 hnúta ályktun. Við skulum bæta þessu við skýringarmyndina:
Auðvitað eru allir hnútar samstilltir og þegar virkur hnútur fer mun annar hnútur taka við ábyrgð hans.
Næsta vandamál eru sýndarvéladiskar. Í augnablikinu eru þau geymd á hypervisorunum sjálfum og ef vandamál koma upp með hypervisor týnum við öll gögn - og nærvera árás mun ekki hjálpa hér ef við týnum ekki disknum, heldur öllum þjóninum. Til að gera þetta þurfum við að búa til þjónustu sem mun virka sem framhlið fyrir einhvers konar geymslu. Hvers konar geymsla það verður er ekki sérstaklega mikilvægt fyrir okkur, en það ætti að vernda gögnin okkar fyrir bilun bæði á disknum og hnútnum, og hugsanlega öllu skápnum. Það eru nokkrir möguleikar hér - það eru auðvitað SAN net með Fibre Channel, en við skulum vera heiðarleg - FC er nú þegar minjar fortíðar - hliðstæða E1 í flutningum - já, ég er sammála, það er enn notað, en aðeins þar sem það er algerlega ómögulegt án þess. Þess vegna myndi ég ekki sjálfviljugur senda FC net árið 2020, vitandi að það eru aðrir áhugaverðari kostir. Þó að hver og einn sé, þá gætu verið þeir sem trúa því að FC með öllum sínum takmörkunum sé allt sem við þurfum - ég ætla ekki að halda því fram, allir hafa sína skoðun. Hins vegar er áhugaverðasta lausnin að mínu mati að nota SDS, eins og Ceph.
Ceph gerir þér kleift að smíða mjög tiltæka gagnageymslulausn með fullt af mögulegum öryggisafritunarvalkostum, sem byrjar með kóða með jöfnunarprófun (líkt og raid 5 eða 6) endar með fullri afritun gagna á mismunandi diska, að teknu tilliti til staðsetningu diska í netþjóna og netþjóna í skápum o.s.frv.
Til að byggja Ceph þarftu 3 hnúta í viðbót. Samskipti við geymsluna munu einnig fara fram í gegnum netið með því að nota blokka-, hluta- og skráageymsluþjónustu. Við skulum bæta geymsluplássi við skemað:
Athugið: einnig er hægt að búa til ofsamrunna reiknihnúta - þetta er hugmyndin um að sameina nokkrar aðgerðir á einum hnút - til dæmis geymslu+tölva - án þess að tileinka sérstaka hnúta fyrir ceph geymslu. Við munum fá sama bilunarþolna kerfi - þar sem SDS mun panta gögn með því pöntunarstigi sem við tilgreinum. Hins vegar eru ofsamræmdir hnútar alltaf málamiðlun - þar sem geymsluhnúturinn hitar ekki bara loftið eins og það virðist við fyrstu sýn (þar sem það eru engar sýndarvélar á honum) - hann eyðir CPU auðlindum í að þjónusta SDS (reyndar gerir hann allt afritun og endurheimt eftir bilun í hnútum, diskum osfrv.). Það er að segja, þú munt tapa einhverju af krafti reiknihnútsins ef þú sameinar hann við geymslu.
Allt þetta dót þarf að stjórna einhvern veginn - við þurfum eitthvað sem við getum búið til vél, net, sýndarbeini osfrv. Til að gera þetta munum við bæta þjónustu við stjórnhnútinn sem mun virka sem mælaborð - viðskiptavinur mun geta tengst þessari gátt í gegnum http/ https og gert allt sem hann þarf (ja, næstum því).
Fyrir vikið höfum við nú bilanaþolið kerfi. Það verður að stjórna öllum þáttum þessa innviða einhvern veginn. Áður var því lýst að Openstack er safn verkefna sem hvert um sig veitir ákveðna virkni. Eins og við sjáum eru meira en nóg af þáttum sem þarf að stilla og stjórna. Í dag munum við tala um nethlutann.
Nifteindaarkitektúr
Í OpenStack er það Neutron sem er ábyrgur fyrir því að tengja sýndarvélatengi við sameiginlegt L2 net, tryggja umferðarleiðingu milli VMs sem staðsettir eru á mismunandi L2 netum, sem og útleið, veita þjónustu eins og NAT, Floating IP, DHCP o.s.frv.
Á háu stigi má lýsa rekstri sérþjónustunnar (grunnhlutanum) sem hér segir.
Þegar VM er ræst mun sérþjónustan:
- Býr til tengi fyrir tiltekið VM (eða tengi) og lætur DHCP þjónustuna vita um það;
- Nýtt sýndarnetstæki er búið til (í gegnum libvirt);
- VM tengist höfninni/höfnunum sem búið var til í skrefi 1;
Merkilegt nokk er verk Neutron byggt á stöðluðum aðferðum sem allir þekkja sem hafa nokkru sinni kafað inn í Linux - nafnrými, iptables, linux brýr, openvswitch, conntrack o.s.frv.
Það skal strax skýrt að Neutron er ekki SDN stjórnandi.
Nifteind samanstendur af nokkrum samtengdum íhlutum:
Openstack-neutron-þjónn er púkinn sem vinnur með notendabeiðnum í gegnum API. Þessi púki tekur ekki þátt í að skrá neinar nettengingar, en veitir nauðsynlegar upplýsingar fyrir þetta til viðbætur sínar, sem síðan stilla viðkomandi netþátt. Nifteindamiðlarar á OpenStack hnútum skrá sig hjá nifteindaþjóninum.
Nifteindaþjónn er í raun forrit skrifað í python, sem samanstendur af tveimur hlutum:
- REST þjónusta
- Neutron Plugin (kjarni/þjónusta)
REST þjónustan er hönnuð til að taka á móti API símtölum frá öðrum hlutum (til dæmis beiðni um að veita einhverjar upplýsingar osfrv.)
Viðbætur eru viðbætur hugbúnaðarhlutar/einingar sem kallaðar eru á meðan á API beiðnum stendur - það er að segja að úthlutun þjónustu á sér stað í gegnum þá. Viðbætur eru skipt í tvær tegundir - þjónustu og rót. Að jafnaði er hestaviðbótin aðallega ábyrg fyrir því að stjórna vistfangarýminu og L2 tengingum milli VMs og þjónustuviðbætur veita nú þegar viðbótarvirkni eins og VPN eða FW.
Til dæmis er hægt að skoða lista yfir viðbætur sem eru tiltækar í dag
Það geta verið nokkur þjónustuviðbætur, en það getur aðeins verið eitt hestaviðbót.
openstack-nifteind-ml2 er staðlað Openstack rót viðbót. Þessi viðbót er með einingaarkitektúr (ólíkt forvera sínum) og stillir netþjónustuna í gegnum rekla sem tengdir eru við hana. Við munum skoða viðbótina sjálfa aðeins síðar, þar sem það gefur í raun þann sveigjanleika sem OpenStack hefur í nethlutanum. Hægt er að skipta um rótarviðbót (til dæmis, Contrail Networking gerir slíka skipti).
RPC þjónusta (rabbitmq-þjónn) — þjónusta sem veitir biðröðstjórnun og samskipti við aðra OpenStack þjónustu, sem og samskipti milli netþjónustuaðila.
Netmiðlarar — umboðsmenn sem eru staðsettir í hverjum hnút, sem sérþjónusta er stillt í gegnum.
Það eru til nokkrar tegundir af umboðsmönnum.
Aðalumboðsmaður er L2 umboðsmaður. Þessir umboðsmenn keyra á öllum yfirsýnum, þar á meðal stjórnhnútum (nánar tiltekið, á öllum hnútum sem veita einhverja þjónustu fyrir leigjendur) og aðalhlutverk þeirra er að tengja sýndarvélar við sameiginlegt L2 net, og búa einnig til viðvaranir þegar einhver atvik eiga sér stað ( til dæmis slökkva/virkja höfnina).
Næsti, ekki síður mikilvægur umboðsmaður er L3 umboðsmaður. Sjálfgefið er að þessi umboðsmaður keyrir eingöngu á nethnút (oft er nethnútur sameinaður stjórnhnút) og veitir leið milli neta leigjanda (bæði milli neta þess og neta annarra leigjenda, og er aðgengilegur umheiminum, sem veitir NAT, sem og DHCP þjónustu). Hins vegar, þegar DVR (dreifður leið) er notaður, birtist þörfin fyrir L3 viðbót einnig á tölvuhnútunum.
L3 umboðsmaðurinn notar Linux nafnrými til að veita hverjum leigjanda safn af eigin einangruðum netum og virkni sýndarbeina sem leiða umferð og veita hliðarþjónustu fyrir Layer 2 net.
Gagnasafn — gagnagrunnur yfir auðkenni neta, undirneta, hafna, lauga osfrv.
Reyndar tekur Neutron við API-beiðnum frá stofnun hvers kyns neteininga, sannvotir beiðnina og í gegnum RPC (ef það hefur aðgang að einhverju viðbóti eða umboðsmanni) eða REST API (ef það hefur samskipti í SDN) sendir það til umboðsmannanna (í gegnum viðbætur) nauðsynlegar leiðbeiningar til að skipuleggja umbeðna þjónustu.
Snúum okkur nú að prófunaruppsetningunni (hvernig hún er sett upp og hvað er innifalið í henni, sjáum við síðar í verklega hlutanum) og sjáum hvar hver íhlutur er staðsettur:
(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 ~]$
Reyndar er það öll uppbygging nifteindarinnar. Nú er það þess virði að eyða tíma í ML2 viðbótina.
Modular Layer 2
Eins og getið er hér að ofan er viðbótin venjuleg OpenStack rótarviðbót og hefur einingaarkitektúr.
Forveri ML2 viðbótarinnar var með einlita uppbyggingu, sem leyfði til dæmis ekki að nota blöndu af nokkrum tækni í einni uppsetningu. Til dæmis gætirðu ekki notað bæði openvswitch og linuxbridge á sama tíma - annaðhvort fyrsta eða annað. Af þessum sökum var ML2 viðbótin með arkitektúrnum búin til.
ML2 hefur tvo íhluti - tvær tegundir ökumanna: Tegundarrekla og vélbúnaðarrekla.
Sláðu inn ökumenn ákvarða tækni sem verður notuð til að skipuleggja nettengingar, til dæmis VxLAN, VLAN, GRE. Á sama tíma leyfir ökumaðurinn notkun mismunandi tækni. Staðlaða tæknin er VxLAN hjúpun fyrir yfirborðsnet og vlan ytri net.
Tegund reklar innihalda eftirfarandi netgerðir:
Flat - net án merkingar
VLAN - merkt net
Local — sérstök tegund netkerfis fyrir allt-í-einn uppsetningar (slíkar uppsetningar eru nauðsynlegar annað hvort fyrir þróunaraðila eða fyrir þjálfun)
GRE — yfirborðsnet með GRE göngum
VxLAN — yfirborðsnet með VxLAN göngum
Bílstjóri vélbúnaðar skilgreina verkfæri sem tryggja skipulag tækninnar sem tilgreind er í tegundarökumanninum - til dæmis openvswitch, sr-iov, opendaylight, OVN o.s.frv.
Það fer eftir útfærslu þessa ökumanns, annað hvort verða notaðir umboðsmenn undir stjórn Neutron, eða tengingar við utanaðkomandi SDN stjórnandi, sem sér um öll mál sem tengjast skipulagningu L2 netkerfa, leiðarlýsingu o.fl.
Dæmi: ef við notum ML2 ásamt OVS, þá er L2 umboðsmaður settur upp á hverjum tölvuhnút sem stjórnar OVS. Hins vegar, ef við notum til dæmis OVN eða OpenDayLight, þá heyrir stjórn OVS undir lögsögu þeirra - Neutron, í gegnum rótarviðbótina, gefur stjórnandanum skipanir og hann gerir nú þegar það sem honum var sagt.
Við skulum endurskoða Open vSwitch
Í augnablikinu er einn af lykilþáttum OpenStack Open vSwitch.
Þegar OpenStack er sett upp án SDN viðbótarframleiðenda eins og Juniper Contrail eða Nokia Nuage, er OVS aðal nethluti skýjanetsins og ásamt iptables, conntrack, nafnasvæðum, gerir þér kleift að skipuleggja fullgild yfirbyggingarnet fyrir fjöleignarhús. Auðvitað er hægt að skipta út þessum íhlut, til dæmis þegar notaðar eru SDN-lausnir frá þriðja aðila (framleiðanda).
OVS er opinn hugbúnaðarrofi sem er hannaður til notkunar í sýndarumhverfi sem sýndarumferðarmiðlari.
Í augnablikinu hefur OVS mjög viðeigandi virkni, sem inniheldur tækni eins og QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK o.s.frv.
Athugið: OVS var upphaflega ekki hugsað sem mjúkur rofi fyrir mjög hlaðnar fjarskiptaaðgerðir og var meira hannað fyrir upplýsingatækniaðgerðir sem krefjast minna bandbreiddar eins og vefþjón eða póstþjón. Hins vegar er verið að þróa OVS áfram og núverandi útfærslur á OVS hafa stórbætt frammistöðu þess og getu, sem gerir það kleift að nota það af fjarskiptafyrirtækjum með mjög álagðar aðgerðir, til dæmis er OVS útfærsla með stuðningi við DPDK hröðun.
Það eru þrír mikilvægir þættir OVS sem þú þarft að vera meðvitaður um:
- Kjarnaeining — íhlutur sem er staðsettur í kjarnarýminu sem vinnur umferð út frá reglum sem berast frá stýrieiningunni;
- vSwitch púkinn (ovs-vswitchd) er ferli hleypt af stokkunum í notendarými sem er ábyrgt fyrir að forrita kjarnaeininguna - það er, það táknar beint rökfræði aðgerða rofans
- Gagnagrunnsþjónn - staðbundinn gagnagrunnur sem staðsettur er á hverjum gestgjafa sem keyrir OVS, þar sem stillingarnar eru geymdar. SDN stýringar geta átt samskipti í gegnum þessa einingu með því að nota OVSDB samskiptareglur.
Öllu þessu fylgir safn af greiningar- og stjórnunartólum, svo sem ovs-vsctl, ovs-appctl, ovs-ofctl, osfrv.
Eins og er, er Openstack mikið notað af fjarskiptafyrirtækjum til að flytja netaðgerðir yfir á það, svo sem EPC, SBC, HLR, o.s.frv. Sumar aðgerðir geta lifað án vandræða með OVS eins og er, en til dæmis vinnur EPC frá áskrifendaumferð - þá fer hún í gegnum mikið magn af umferð (nú nær umferðarmagn nokkur hundruð gígabitum á sekúndu). Að sjálfsögðu er það ekki besta hugmyndin að keyra slíka umferð í gegnum kjarnarými (þar sem framsendingarmaðurinn er sjálfgefið staðsettur þar). Þess vegna er OVS oft notað að öllu leyti í notendarými með því að nota DPDK hröðunartækni til að framsenda umferð frá NIC til notendarýmis framhjá kjarnanum.
Athugið: fyrir ský sem er notað fyrir fjarskiptaaðgerðir er mögulegt að senda frá sér umferð frá tölvuhnút sem fer framhjá OVS beint í skiptibúnað. SR-IOV og Passthrough kerfi eru notuð í þessu skyni.
Hvernig virkar þetta á alvöru skipulagi?
Jæja, nú skulum við halda áfram að verklega hlutanum og sjá hvernig þetta virkar allt í reynd.
Í fyrsta lagi skulum við nota einfalda Openstack uppsetningu. Þar sem ég hef ekki sett af netþjónum við höndina fyrir tilraunir munum við setja saman frumgerðina á einum líkamlegum netþjóni úr sýndarvélum. Já, náttúrulega hentar slík lausn ekki í viðskiptalegum tilgangi, en til að sjá dæmi um hvernig netið virkar í Openstack er slík uppsetning nóg fyrir augun. Þar að auki er slík uppsetning enn áhugaverðari í þjálfunarskyni - þar sem þú getur náð umferð osfrv.
Þar sem við þurfum aðeins að sjá grunnhlutann, getum við ekki notað nokkur net heldur hækkað allt með því að nota aðeins tvö net, og annað netið í þessu skipulagi verður eingöngu notað fyrir aðgang að undirskýinu og DNS netþjóninum. Við munum ekki snerta ytri net í bili - þetta er efni fyrir sérstaka stóra grein.
Svo, við skulum byrja í röð. Fyrst smá kenning. Við munum setja upp Openstack með TripleO (Openstack á Openstack). Kjarninn í TripleO er sá að við setjum upp Openstack allt-í-einn (þ.e. á einum hnút), sem kallast undercloud, og notum síðan möguleika hins opnaða Openstack til að setja upp Openstack sem ætlað er til notkunar, kallað overcloud. Undercloud mun nota eðlislæga hæfileika sína til að stjórna líkamlegum netþjónum (berum málmi) - Ironic verkefnið - til að útvega hypervisors sem munu gegna hlutverkum tölvunar, stjórna, geymsluhnúta. Það er að segja, við notum engin þriðja aðila verkfæri til að dreifa Openstack - við sendum Openstack með Openstack. Það verður mun skýrara eftir því sem líður á uppsetninguna, svo við munum ekki hætta þar og halda áfram.
Athugið: Í þessari grein, til einföldunar, notaði ég ekki neteinangrun fyrir innri Openstack net, heldur er allt notað með því að nota aðeins eitt net. Hins vegar hefur tilvist eða fjarvera neteinangrunar ekki áhrif á grunnvirkni lausnarinnar - allt mun virka nákvæmlega eins og þegar einangrun er notuð, en umferð mun flæða á sama neti. Fyrir uppsetningu í atvinnuskyni er náttúrulega nauðsynlegt að nota einangrun með mismunandi vlanum og viðmótum. Til dæmis, ceph geymslustjórnunarumferð og gagnaumferð sjálf (vélaaðgangur að diskum o.s.frv.) þegar hún er einangruð nota mismunandi undirnet (Geymslustjórnun og Geymsla) og þetta gerir þér kleift að gera lausnina bilanaþolnari með því að skipta þessari umferð, til dæmis , yfir mismunandi höfn, eða nota mismunandi QoS snið fyrir mismunandi umferð svo gagnaumferð kreisti ekki út merkjaumferð. Í okkar tilviki munu þeir fara á sama netið og í raun takmarkar þetta okkur ekki á neinn hátt.
Athugið: Þar sem við ætlum að keyra sýndarvélar í sýndarumhverfi sem byggir á sýndarvélum, þurfum við fyrst að virkja hreiðraða sýndarvæðingu.
Þú getur athugað hvort hreiður sýndarvæðing sé virkjuð eða ekki svona:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ef þú sérð bókstafinn N, þá gerum við stuðning við hreiðraða sýndarvæðingu samkvæmt hvaða leiðbeiningum sem þú finnur á netinu, til dæmis .
Við þurfum að setja saman eftirfarandi hringrás úr sýndarvélum:
Í mínu tilfelli, til að tengja sýndarvélarnar sem eru hluti af framtíðaruppsetningunni (og ég fékk 7 af þeim, en þú kemst af með 4 ef þú hefur ekki mikið af fjármagni), notaði ég OpenvSwitch. Ég bjó til one ovs brú og tengdi sýndarvélar við hana í gegnum port-groups. Til að gera þetta bjó ég til xml skrá eins og þessa:
[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>Þrír hafnarhópar eru lýstir yfir hér - tveir aðgangur og einn trunk (það síðarnefnda var nauðsynlegt fyrir DNS netþjóninn, en þú getur verið án þess, eða sett hann upp á hýsingarvélinni - hvort sem hentar þér betur). Næst, með því að nota þetta sniðmát, lýsum við yfir okkar í gegnum virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nú breytum við stillingum hypervisor portsins:
[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 ~]# Athugið: Í þessari atburðarás mun heimilisfangið á port ovs-br1 ekki vera aðgengilegt vegna þess að það er ekki með vlan tag. Til að laga þetta þarftu að gefa út skipunina sudo ovs-vsctl set port ovs-br1 tag=100. Hins vegar, eftir endurræsingu, mun þetta merki hverfa (ef einhver veit hvernig á að láta það vera á sínum stað mun ég vera mjög þakklátur). En þetta er ekki svo mikilvægt, vegna þess að við munum aðeins þurfa þetta heimilisfang meðan á uppsetningu stendur og munum ekki þurfa það þegar Openstack er að fullu dreift.
Næst búum við til undirskýjavél:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Á meðan á uppsetningu stendur stillirðu allar nauðsynlegar breytur, svo sem nafn vélarinnar, lykilorð, notendur, ntp netþjóna o.s.frv., þú getur samstundis stillt tengin, en fyrir mig persónulega, eftir uppsetningu, er auðveldara að skrá þig inn í vélina í gegnum stjórnborðinu og leiðréttu nauðsynlegar skrár. Ef þú ert nú þegar með tilbúna mynd geturðu notað hana, eða gert það sem ég gerði - hlaða niður lágmarks Centos 7 myndinni og notaðu hana til að setja upp VM.
Eftir vel heppnaða uppsetningu ættir þú að hafa sýndarvél sem þú getur sett upp undirský
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningFyrst skaltu setja upp nauðsynleg verkfæri fyrir uppsetningarferlið:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Uppsetning undir skýi
Við búum til staflanotanda, setjum lykilorð, bætum því við sudoer og gefum honum möguleika á að framkvæma rótarskipanir í gegnum sudo án þess að þurfa að slá inn lykilorð:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNú tilgreinum við fullt undirskýjaheitið í hýsingarskránni:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Næst bætum við við geymslum og setjum upp hugbúnaðinn sem við þurfum:
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-ansibleAthugið: ef þú ætlar ekki að setja upp ceph, þá þarftu ekki að slá inn ceph-tengdar skipanir. Ég notaði Queens útgáfuna, en þú getur notað hvaða aðra sem þú vilt.
Næst skaltu afrita undirskýjastillingarskrána yfir í heimaskrárstafla notandans:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNú þurfum við að leiðrétta þessa skrá, laga hana að uppsetningunni okkar.
Þú þarft að bæta þessum línum við upphaf skrárinnar:
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 = 10Svo, við skulum fara í gegnum stillingarnar:
undercloud_hostname — fullt nafn undirskýjaþjónsins, verður að passa við færsluna á DNS-þjóninum
local_ip — staðbundið undirskýjavistfang í átt að netútvegun
netgátt — sama staðbundið heimilisfang, sem mun virka sem gátt fyrir aðgang að umheiminum við uppsetningu yfirskýjahnúta, fellur einnig saman við staðbundið IP
undercloud_public_host - ytra API vistfang, hvaða ókeypis heimilisfangi sem er frá úthlutunarnetinu er úthlutað
undercloud_admin_host innra API vistfang, hvaða ókeypis heimilisfangi frá úthlutunarnetinu er úthlutað
undercloud_nameservers - DNS netþjónn
búa til_þjónustuvottorð - þessi lína er mjög mikilvæg í núverandi dæmi, vegna þess að ef þú stillir hana ekki á ósatt færðu villu við uppsetningu, vandamálinu er lýst á Red Hat villurekki
staðbundið_viðmót viðmót í netútvegun. Þetta viðmót verður endurstillt meðan á undercloud stendur, þannig að þú þarft að hafa tvö viðmót á undercloud - annað til að fá aðgang að því, annað fyrir úthlutun
local_mtu — MTU. Þar sem við erum með prófunarstofu og ég er með MTU upp á 1500 á OVS switch portunum, þá er nauðsynlegt að stilla það á 1450 þannig að pakkar sem eru hjúpaðir í VxLAN geti farið í gegnum
net_cidr — úthlutunarnet
masquerade — nota NAT til að fá aðgang að utanaðkomandi neti
masquerade_net - net sem verður NATed
dhcp_start — upphafsvistfang heimilisfangahópsins þar sem vistföngum verður úthlutað til hnúta við uppsetningu yfirskýja
dhcp_end — endanlegt heimilisfang heimilisfangahópsins þar sem vistföngum verður úthlutað til hnúta meðan á yfirskýi stendur
inspection_iprange — safn af heimilisföngum sem er nauðsynlegt fyrir sjálfskoðun (ætti ekki að skarast við ofangreindan hóp)
tímaáætlunar_max_tilraunir — hámarksfjöldi tilrauna til að setja upp yfirský (verður að vera meiri en eða jafn fjölda hnúta)
Eftir að skránni hefur verið lýst geturðu gefið skipunina um að dreifa undercloud:
openstack undercloud install
Aðferðin tekur frá 10 til 30 mínútur eftir járni þínu. Að lokum ættir þú að sjá úttak eins og þetta:
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.
#############################################################################Þessi framleiðsla segir að þú hafir sett upp undercloud og þú getur nú athugað stöðu undercloud og haldið áfram að setja upp overcloud.
Ef þú skoðar ifconfig úttakið muntu sjá að nýtt brúviðmót hefur birst
[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 0Yfirskýjadreifing verður nú framkvæmd í gegnum þetta viðmót.
Af úttakinu hér að neðan geturðu séð að við höfum alla þjónustu á einum hnút:
(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 |
+--------------------------+-----------+----------+Hér að neðan er uppsetning undirskýjanetshluta:
(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 ~]$Yfirskýjauppsetning
Í augnablikinu höfum við aðeins undirský og við höfum ekki nógu marga hnúta sem yfirskýið verður sett saman úr. Þess vegna skulum við fyrst og fremst dreifa sýndarvélunum sem við þurfum. Meðan á dreifingunni stendur mun undercloud sjálft setja upp stýrikerfið og nauðsynlegan hugbúnað á overcloud vélinni - það er, við þurfum ekki að dreifa vélinni alveg, heldur aðeins að búa til disk (eða diska) fyrir hana og ákvarða færibreytur hennar - þ.e. , í raun fáum við beran netþjón án þess að OS sé uppsett á honum.
Við skulum fara í möppuna með diskum sýndarvélanna okkar og búa til diska af nauðsynlegri stærð:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GÞar sem við erum að starfa sem rót þurfum við að skipta um eiganda þessara diska til að koma ekki í vandræðum með réttindi:
[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]# Athugið: ef þú ætlar ekki að setja upp ceph til að læra það, þá búa skipanirnar ekki til að minnsta kosti 3 hnúta með að minnsta kosti tveimur diskum, en í sniðmátinu gefa til kynna að sýndardiskar vda, vdb, osfrv.
Frábært, nú þurfum við að skilgreina allar þessar vélar:
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 Í lokin er skipunin -print-xml > /tmp/storage-1.xml, sem býr til xml skrá með lýsingu á hverri vél í /tmp/ möppunni; ef þú bætir henni ekki við verðurðu ekki fær um að bera kennsl á sýndarvélar.
Nú þurfum við að skilgreina allar þessar vélar í 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 ~]#Nú er smá blæbrigði - tripleO notar IPMI til að stjórna netþjónum við uppsetningu og sjálfskoðun.
Sjálfskoðun er ferlið við að skoða vélbúnaðinn til að fá færibreytur hans sem nauðsynlegar eru fyrir frekari útvegun hnúta. Sjálfskoðun er framkvæmd með því að nota kaldhæðni, þjónustu sem er hönnuð til að vinna með netþjóna úr berum málmi.
En hér er vandamálið - á meðan vélbúnaðar IPMI netþjónar eru með sérstakt tengi (eða sameiginlegt tengi, en þetta er ekki mikilvægt), þá hafa sýndarvélar ekki slíkar tengi. Hér kemur hækja sem heitir vbmc okkur til hjálpar - tól sem gerir þér kleift að líkja eftir IPMI tengi. Þessum blæbrigðum er vert að gefa gaum sérstaklega fyrir þá sem vilja setja upp slíka rannsóknarstofu á ESXI hypervisor - satt best að segja veit ég ekki hvort hann hefur hliðstæðu við vbmc, svo það er þess virði að velta þessu máli fyrir sér áður en allt er sett í notkun .
Settu upp vbmc:
yum install yum install python2-virtualbmcEf stýrikerfið þitt finnur ekki pakkann skaltu bæta við geymslunni:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNú setjum við upp tólið. Hér er allt banalt til skammar. Nú er rökrétt að það eru engir netþjónar á vbmc listanum
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Til þess að þær komi fram verða þær að vera handvirkt lýstar þannig:
[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 ~]#Ég held að skipanasetningin sé skýr án skýringa. Hins vegar, eins og er, eru allar lotur okkar í NIÐUR stöðu. Til þess að þau fari í UPP stöðu þarftu að virkja þau:
[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 ~]#Og lokasnertingin - þú þarft að leiðrétta eldveggsreglurnar (eða slökkva á honum alveg):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Nú skulum við fara í undercloud og athuga hvort allt sé að virka. Heimilisfang hýsingarvélarinnar er 192.168.255.200, á undercloud bættum við við nauðsynlegum ipmitool pakka við undirbúning fyrir dreifingu:
[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 runningEins og þú sérð höfum við ræst stjórnhnútinn með góðum árangri í gegnum vbmc. Nú skulum við slökkva á því og halda áfram:
[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 ~]#Næsta skref er sjálfskoðun á hnútunum sem overcloud verður sett upp á. Til að gera þetta þurfum við að útbúa json skrá með lýsingu á hnútunum okkar. Vinsamlegast athugaðu að, ólíkt uppsetningu á berum netþjónum, gefur skráin til kynna tengið sem vbmc keyrir á fyrir hverja vél.
[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:27Athugið: stýrihnúturinn hefur tvö tengi, en í þessu tilfelli er þetta ekki mikilvægt, í þessari uppsetningu mun einn vera nóg fyrir okkur.
Nú undirbúum við json skrána. Við þurfum að gefa til kynna poppy heimilisfang hafnarinnar þar sem úthlutun verður framkvæmd, færibreytur hnútanna, gefa þeim nöfn og tilgreina hvernig á að komast að 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"
}
]
}Nú þurfum við að undirbúa myndir fyrir kaldhæðni. Til að gera þetta skaltu hlaða þeim niður í gegnum wget og setja upp:
(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 ~]$Hleður upp myndum í undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Athugar hvort allar myndir hafi verið hlaðnar
(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 ~]$Eitt enn - þú þarft að bæta við DNS netþjóni:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nú getum við gefið skipunina til sjálfskoðunar:
(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 ~]$Eins og þú sérð á úttakinu var öllu lokið án villna. Við skulum athuga hvort allir hnútar séu í tiltæku ástandi:
(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 ~]$ Ef hnúðarnir eru í öðru ástandi, venjulega viðráðanlegir, þá fór eitthvað úrskeiðis og þú þarft að líta á annálinn og finna út hvers vegna þetta gerðist. Hafðu í huga að í þessari atburðarás erum við að nota sýndarvæðingu og það gætu verið villur tengdar notkun sýndarvéla eða vbmc.
Næst þurfum við að gefa til kynna hvaða hnút mun framkvæma hvaða aðgerð - það er að segja sniðið sem hnúturinn mun nota:
(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 ~]$Tilgreindu sniðið fyrir hvern hnút:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Við skulum athuga hvort við gerðum allt rétt:
(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 ~]$Ef allt er rétt gefum við skipunina um að dreifa overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuÍ raunverulegri uppsetningu verða sérsniðin sniðmát að sjálfsögðu notuð, í okkar tilviki mun þetta flækja ferlið mjög, þar sem hverja breytingu á sniðmátinu verður að útskýra. Eins og var skrifað áðan, mun jafnvel einföld uppsetning vera nóg fyrir okkur til að sjá hvernig það virkar.
Athugið: --libvirt-type qemu breytan er nauðsynleg í þessu tilfelli, þar sem við munum nota hreiðraða sýndarvæðingu. Annars muntu ekki geta keyrt sýndarvélar.
Nú hefur þú um það bil klukkutíma, eða kannski meira (fer eftir getu vélbúnaðarins) og þú getur aðeins vona að eftir þennan tíma muntu sjá eftirfarandi skilaboð:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Nú ertu með næstum fullgilda útgáfu af openstack, sem þú getur rannsakað, gert tilraunir á o.s.frv.
Við skulum athuga hvort allt virki rétt. Í stafla heimaskrár notandans eru tvær skrár - ein stackrc (til að stjórna undercloud) og önnur overcloudrc (til að stjórna overcloud). Þessar skrár verða að vera tilgreindar sem uppruna, þar sem þær innihalda nauðsynlegar upplýsingar til auðkenningar.
(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 ~]$Uppsetningin mín krefst samt einnar lítillar snertingar - að bæta við leið á stjórnandann, þar sem vélin sem ég er að vinna með er á öðru neti. Til að gera þetta, farðu í control-1 undir heat-admin reikningnum og skráðu leiðina
(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.254Jæja, nú geturðu farið út í sjóndeildarhringinn. Allar upplýsingar - heimilisföng, innskráning og lykilorð - eru í skránni /home/stack/overcloudrc. Lokamyndin lítur svona út:
Við the vegur, í uppsetningunni okkar voru vélföng gefin út í gegnum DHCP og eins og þú sérð eru þau gefin út „af handahófi“. Þú getur nákvæmlega skilgreint í sniðmátinu hvaða heimilisfang ætti að vera tengt við hvaða vél meðan á dreifingu stendur, ef þú þarft á því að halda.
Hvernig flæðir umferð á milli sýndarvéla?
Í þessari grein munum við skoða þrjá valkosti fyrir umferð sem fer framhjá
- Tvær vélar á einum hypervisor á einu L2 neti
- Tvær vélar á mismunandi yfirsýnum á sama L2 neti
- Tvær vélar á mismunandi netum (rætur yfir netkerfi)
Mál með aðgang að umheiminum í gegnum ytra net, með því að nota fljótandi vistföng, sem og dreifða leið, munum við skoða næst, í bili munum við einbeita okkur að innri umferð.
Til að athuga skulum við setja saman eftirfarandi skýringarmynd:
Við höfum búið til 4 sýndarvélar - 3 á einu L2 neti - net-1 og 1 í viðbót á net-2 netinu
(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 ~]$ Við skulum sjá á hvaða hypervisurum búnu vélarnar eru staðsettar:
(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 |
(yfirský) [stack@undercloud ~]$
Vélar vm-1 og vm-3 eru staðsettar á compute-0, vélar vm-2 og vm-4 eru staðsettar á hnút compute-1.
Að auki hefur sýndarbeini verið búinn til til að gera leið á milli tilgreindra neta:
(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 ~]$ Beininn hefur tvö sýndarport sem virka sem gátt fyrir netkerfi:
(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 ~]$ En áður en við skoðum hvernig umferðin flæðir, skulum við líta á það sem við höfum núna á stýrihnútnum (sem er líka nethnútur) og á reiknihnútnum. Byrjum á reiknihnútnum.
[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 ~]$Í augnablikinu hefur hnúturinn þrjár ovs brýr - br-int, br-tun, br-ex. Á milli þeirra, eins og við sjáum, er sett af viðmótum. Til að auðvelda skilning, skulum við teikna öll þessi viðmót á skýringarmyndinni og sjá hvað gerist.
Þegar litið er á vistföngin sem VxLAN göngin eru færð upp á má sjá að eitt göngin eru hækkuð í compute-1 (192.168.255.26), önnur göngin líta út fyrir stjórn-1 (192.168.255.15). En það sem er áhugaverðast er að br-ex er ekki með líkamleg viðmót og ef þú skoðar hvaða flæði eru stillt geturðu séð að þessi brú getur aðeins dregið úr umferð í augnablikinu.
[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 ~]$ Eins og þú sérð á úttakinu er heimilisfangið skrúfað beint við líkamlega höfnina en ekki við sýndarbrúarviðmótið.
[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 ~]$
Samkvæmt fyrstu reglu skal farga öllu sem kom frá phy-br-ex portinu.
Reyndar er nú hvergi annars staðar fyrir umferð að koma inn á þessa brúna nema frá þessu viðmóti (viðmótið við br-int), og af dropunum að dæma hefur BUM umferð þegar flogið inn á brúna.
Það er, umferð getur aðeins yfirgefið þennan hnút í gegnum VxLAN göngin og ekkert annað. Hins vegar, ef þú kveikir á DVR, mun staðan breytast, en við munum takast á við það í annað sinn. Þegar þú notar neteinangrun, til dæmis með vlans, muntu ekki hafa eitt L3 tengi í vlan 0, heldur nokkur tengi. Hins vegar mun VxLAN umferð yfirgefa hnútinn á sama hátt, en einnig hjúpuð í einhvers konar hollur vlan.
Við höfum flokkað reiknihnútinn, við skulum halda áfram í stjórnunarhnútinn.
[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 ~]$Reyndar getum við sagt að allt sé eins, en IP-talan er ekki lengur á líkamlegu viðmótinu heldur á sýndarbrúnni. Þetta er gert vegna þess að þessi höfn er höfnin sem umferð mun fara út um heiminn um.
[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 ~]$ Þessi höfn er bundin við br-ex brúna og þar sem engin vlan merki eru á henni, þá er þessi höfn trunk höfn sem öll vlan eru leyfð á, nú fer umferð út án merki, eins og gefið er til kynna með vlan-id 0 í framleiðsla hér að ofan.
Allt annað í augnablikinu er svipað og reiknihnútinn - sömu brýrnar, sömu göngin fara í tvo reiknihnúta.
Við munum ekki íhuga geymsluhnúta í þessari grein, en til að skilja það er nauðsynlegt að segja að nethluti þessara hnúta er banal til skammar. Í okkar tilviki er aðeins ein líkamleg höfn (eth0) með IP tölu sem henni er úthlutað og það er það. Það eru engin VxLAN göng, göng brýr, osfrv - það er engin ovs, þar sem það er ekkert vit í því. Þegar neteinangrun er notuð mun þessi hnút hafa tvö tengi (líkamleg tengi, bodny eða bara tvö vlan - það skiptir ekki máli - það fer eftir því hvað þú vilt) - annað fyrir stjórnun, annað fyrir umferð (skrifa á VM diskinn , lestur af diski osfrv.)
Við komumst að því hvað við höfum á hnútunum ef engin þjónusta er fyrir hendi. Nú skulum við ræsa 4 sýndarvélar og sjá hvernig kerfið sem lýst er hér að ofan breytist - við ættum að hafa höfn, sýndarbeini osfrv.
Hingað til lítur netið okkar svona út:
Við erum með tvær sýndarvélar á hverjum tölvuhnút. Með því að nota compute-0 sem dæmi skulum við sjá hvernig allt er innifalið.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Vélin hefur aðeins eitt sýndarviðmót - 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 ~]$
Þetta viðmót lítur út í Linux brúnni:
[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 ~]$ Eins og þú sérð af úttakinu eru aðeins tvö viðmót í brúnni - tap95d96a75-a0 og qvb95d96a75-a0.
Hér er þess virði að staldra aðeins við tegundir sýndarnettækja í OpenStack:
vtap - sýndarviðmót tengt við dæmi (VM)
qbr - Linux brú
qvb og qvo - vEth par tengt við Linux brú og Open vSwitch brú
br-int, br-tun, br-vlan — Opna vSwitch brýr
patch-, int-br-, phy-br- - Opna vSwitch patch tengi sem tengja brýr
qg, qr, ha, fg, sg - Opnaðu vSwitch tengi sem sýndartæki nota til að tengjast OVS
Eins og þú skilur, ef við erum með qvb95d96a75-a0 tengi í brúnni, sem er vEth par, þá er einhvers staðar hliðstæða þess, sem ætti rökrétt að heita qvo95d96a75-a0. Við skulum sjá hvaða höfn eru á 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 ~]$ Eins og við sjáum er höfnin í br-int. Br-int virkar sem rofi sem lokar sýndarvélahöfnum. Til viðbótar við qvo95d96a75-a0 er gáttin qvo5bd37136-47 sýnileg í úttakinu. Þetta er höfnin að annarri sýndarvélinni. Fyrir vikið lítur skýringarmyndin okkar núna svona út:
Spurning sem ætti strax að vekja athygli athyglisverðs lesanda - hver er linux brúin á milli sýndarvélatengsins og OVS tengisins? Staðreyndin er sú að til að vernda vélina eru öryggishópar notaðir sem eru ekkert annað en iptables. OVS virkar ekki með iptables, svo þessi „hækja“ var fundin upp. Hins vegar er það að verða úrelt - það er skipt út fyrir conntrack í nýjum útgáfum.
Það er, að lokum lítur kerfið svona út:
Tvær vélar á einum hypervisor á einu L2 neti
Þar sem þessar tvær VM eru staðsettar á sama L2 neti og á sama yfirsýnara, mun umferð á milli þeirra rökrétt flæða staðbundið í gegnum br-int, þar sem báðar vélarnar verða á sama 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 ~]$ Tvær vélar á mismunandi yfirsýnum á sama L2 neti
Nú skulum við sjá hvernig umferðin mun fara á milli tveggja véla á sama L2 netinu, en staðsett á mismunandi yfirsýnum. Satt að segja mun ekkert breytast mikið, bara umferð á milli hásjármanna mun fara í gegnum vxlan göngin. Við skulum skoða dæmi.
Heimilisföng sýndarvéla sem við munum fylgjast með umferð á milli:
[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 ~]$ Við skoðum framsendingartöfluna í 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 ~]Umferð ætti að fara í höfn 2 - við skulum sjá hvers konar höfn það er:
[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 ~]$Þetta er patch-tun - það er viðmótið í br-tun. Við skulum sjá hvað verður um pakkann á br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Pakkinn er pakkaður í VxLAN og sendur í port 2. Við skulum sjá hvert port 2 leiðir:
[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 ~]$Þetta eru vxlan göng á compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Við skulum fara í compute-1 og sjá hvað gerist næst með pakkanum:
[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 er í br-int framsendingartöflunni á compute-1, og eins og sjá má af úttakinu hér að ofan er það sýnilegt í gegnum port 2, sem er portið í átt að 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:46Jæja, þá sjáum við að í br-int á compute-1 er áfangastaður:
[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 ~]$ Það er, móttekinn pakki mun fljúga til hafnar 3, en á bak við það er nú þegar sýndarvélatilvik-00000003.
Fegurðin við að nota Openstack til að læra á sýndarinnviði er að við getum auðveldlega fanga umferð á milli yfirsýnar og séð hvað er að gerast með það. Þetta er það sem við munum gera núna, keyra tcpdump á vnet tenginu í átt að 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*******************Fyrsta línan sýnir að Patek frá heimilisfangi 10.0.1.85 fer í heimilisfang 10.0.1.88 (ICMP umferð), og það er vafinn inn í VxLAN pakka með vni 22 og pakkinn fer frá hýsil 192.168.255.19 (compute-0) í hýsil 192.168.255.26 .1 ( reikna-XNUMX). Við getum athugað hvort VNI passi við það sem tilgreint er í ovs.
Snúum okkur aftur að þessari línu actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 er vni í sextándu talnakerfi. Við skulum breyta þessari tölu í 16. kerfið:
16 = 6*16^0+1*16^1 = 6+16 = 22Það er, vni samsvarar raunveruleikanum.
Önnur línan sýnir umferð til baka, jæja, það þýðir ekkert að útskýra það, þar er allt á hreinu.
Tvær vélar á mismunandi netum (samskipt milli neta)
Síðasta tilvikið í dag er leið á milli neta innan eins verkefnis með sýndarbeini. Við erum að íhuga mál án DVR (við munum skoða það í annarri grein), þannig að leið á sér stað á nethnútnum. Í okkar tilviki er nethnúturinn ekki settur í sérstakri einingu og er hann staðsettur á stjórnhnútnum.
Fyrst skulum við sjá að leiðin virkar:
$ 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 msÞar sem pakkinn í þessu tilfelli verður að fara í gáttina og vera fluttur þangað, þurfum við að finna út poppy heimilisfang gáttarinnar, sem við skoðum ARP töfluna í dæminu:
$ 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 eth0Nú skulum við sjá hvert umferðin með áfangastað (10.0.1.254) fa:16:3e:c4:64:70 á að senda:
[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 ~]$ Við skulum skoða hvert höfn 2 leiðir:
[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 ~]$ Allt er rökrétt, umferð fer í br-tun. Við skulum sjá hvaða vxlan göng það verður pakkað inn í:
[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 ~]$ Þriðja höfnin er vxlan göng:
[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 ~]$ Sem lítur á stjórnhnútinn:
[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 ~]$ Umferðin er komin að stjórnhnútnum, þannig að við þurfum að fara að honum og sjá hvernig leiðsögn verður.
Eins og þú manst, leit stýrihnúturinn inni nákvæmlega eins út og reiknihnúturinn - sömu þrjár brýrnar, aðeins br-ex hafði líkamlega höfn sem hnúturinn gat sent umferð út um. Stofnun tilvika breytti uppsetningu á reiknihnútum - Linux brú, iptables og tengi var bætt við hnútana. Stofnun netkerfa og sýndarbeins setti einnig mark sitt á uppsetningu stjórnhnútsins.
Svo það er augljóst að MAC vistfang gáttarinnar verður að vera í br-int framsendingartöflunni á stjórnhnútnum. Við skulum athuga hvort það sé þarna og hvert það leitar:
[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 er sýnilegur frá port qr-0c52b15f-8f. Ef við förum aftur í listann yfir sýndarport í Openstack, þá er þessi tegund af tengi notuð til að tengja ýmis sýndartæki við OVS. Til að vera nákvæmari er qr tengi fyrir sýndarbeini, sem er táknað sem nafnrými.
Við skulum sjá hvaða nafnrými eru á þjóninum:
[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 ~]$ Allt að þrjú eintök. En af nöfnunum að dæma má giska á tilgang hvers þeirra. Við munum snúa aftur til tilvika með auðkenni 0 og 1 síðar, nú höfum við áhuga á nafnrými 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 ~]$ Þetta nafnrými inniheldur tvö innri sem við bjuggum til áðan. Báðum sýndarhöfnum hefur verið bætt við br-int. Athugum mac vistfang portsins qr-0c52b15f-8f, þar sem umferðin, miðað við áfangastað mac vistfangsins, fór í þetta viðmót.
[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 ~]$ Það er, í þessu tilfelli virkar allt samkvæmt lögum um staðlaða leið. Þar sem umferðin er ætluð hýsil 10.0.2.8 verður hún að fara út í gegnum annað viðmótið qr-92fa49b5-54 og fara í gegnum vxlan göngin að reiknihnútnum:
[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 ~]$ Allt er rökrétt, kemur ekkert á óvart. Við skulum sjá hvar poppy heimilisfang hýsilsins 10.0.2.8 er sýnilegt í br-int:
[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 ~]$ Eins og við var að búast fer umferð í br-tun, sjáum í hvaða göng umferðin fer næst:
[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 ~]$ Umferð fer inn í göngin til að reikna-1. Jæja, á compute-1 er allt einfalt - frá br-tun fer pakkinn í br-int og þaðan í viðmót sýndarvélarinnar:
[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 ~]$ Við skulum athuga hvort þetta sé örugglega rétt viðmót:
[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 ~]$
Reyndar fórum við alla leið í gegnum pakkann. Ég held að þú hafir tekið eftir því að umferðin fór í gegnum mismunandi vxlan göng og fór út með mismunandi VNI. Við skulum sjá hvers konar VNI þetta eru, eftir það munum við safna sorphaugi á stjórnhöfn hnútsins og ganga úr skugga um að umferðin flæði nákvæmlega eins og lýst er hér að ofan.
Svo, göngin til að reikna-0 hafa eftirfarandi actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Umbreytum 0x16 í tugatalnakerfið:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Göngin til að reikna-1 eru með eftirfarandi VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Umbreytum 0x63 í tugakerfi:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Jæja, nú skulum við líta á sorphauginn:
[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*******************Fyrsti pakkinn er vxlan pakki frá hýsil 192.168.255.19 (compute-0) til hýsil 192.168.255.15 (stjórna-1) með vni 22, þar sem ICMP pakki er pakkað frá hýsil 10.0.1.85 til hýsil 10.0.2.8. Eins og við reiknuðum út hér að ofan passar vni við það sem við sáum í úttakinu.
Annar pakkinn er vxlan pakki frá hýsil 192.168.255.15 (stjórna-1) til hýsil 192.168.255.26 (compute-1) með vni 99, þar sem ICMP pakki er pakkað frá hýsil 10.0.1.85 til hýsil 10.0.2.8. Eins og við reiknuðum út hér að ofan passar vni við það sem við sáum í úttakinu.
Næstu tveir pakkar eru afturumferð frá 10.0.2.8 ekki 10.0.1.85.
Það er, á endanum fengum við eftirfarandi stjórnhnútakerfi:
Lítur út eins og það sé það? Við gleymdum tveimur nafnasvæðum:
[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 ~]$ Eins og við ræddum um arkitektúr skýjapallsins væri gott ef vélar fengju heimilisföng sjálfkrafa frá DHCP netþjóni. Þetta eru tveir DHCP netþjónar fyrir tvö net okkar 10.0.1.0/24 og 10.0.2.0/24.
Við skulum athuga hvort þetta sé satt. Það er aðeins eitt heimilisfang í þessu nafnrými - 10.0.1.1 - heimilisfang DHCP þjónsins sjálfs og það er einnig innifalið í 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 0Við skulum sjá hvort ferli sem innihalda qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 í nafni þeirra á stjórnhnútnum:
[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 ~]$ Það er slíkt ferli og miðað við upplýsingarnar sem koma fram í úttakinu hér að ofan getum við til dæmis séð hvað við höfum til leigu eins og er:
[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 ~]$Fyrir vikið fáum við eftirfarandi þjónustusett á stjórnhnútnum:
Jæja, hafðu í huga - þetta eru bara 4 vélar, 2 innri net og einn sýndarbeini... Við erum ekki með ytri net hér núna, fullt af mismunandi verkefnum, hvert með sitt netkerfi (skarast), og við höfum slökkt var á dreifðum beini og á endanum Þegar öllu er á botninn hvolft var aðeins einn stýrihnútur á prófunarbekknum (fyrir bilanaþol verður að vera hæfilegur þriggja hnúta). Það er rökrétt að í viðskiptum er allt "aðeins" flóknara, en í þessu einfalda dæmi skiljum við hvernig það ætti að virka - hvort þú ert með 3 eða 300 nafnrými er auðvitað mikilvægt, en frá sjónarhóli reksturs alls uppbygging, ekkert mun breytast mikið ... þó fyrr en þú munt ekki stinga í SDN söluaðila. En það er allt önnur saga.
Ég vona að það hafi verið áhugavert. Ef þú hefur einhverjar athugasemdir/viðbætur, eða einhvers staðar laug ég beinlínis (ég er mannleg og mín skoðun verður alltaf huglæg) - skrifaðu það sem þarf að leiðrétta/bæta við - við leiðréttum/bætum við öllu.
Að lokum langar mig að segja nokkur orð um að bera saman Openstack (bæði vanillu og söluaðila) við skýjalausnina frá VMWare - ég hef verið spurð þessarar spurningar of oft undanfarin ár og í hreinskilni sagt er ég búinn að vera þreyttur á því, en samt. Að mínu mati er mjög erfitt að bera þessar tvær lausnir saman, en það má alveg segja að það séu ókostir á báðum lausnum og þegar þú velur aðra lausn þarf að vega kosti og galla.
Ef OpenStack er samfélagsdrifin lausn, þá hefur VMWare rétt á að gera aðeins það sem það vill (lesið - hvað er arðbært fyrir það) og það er rökrétt - því það er viðskiptafyrirtæki sem er vant að græða peninga á viðskiptavinum sínum. En það er eitt stórt og feit EN - þú getur komist af OpenStack, til dæmis frá Nokia, og með litlum kostnaði skipt yfir í lausn frá til dæmis Juniper (Contrail Cloud), en ólíklegt er að þú getir komist af VMWare . Fyrir mér líta þessar tvær lausnir svona út - Openstack (seljandi) er einfalt búr sem þú ert settur í, en þú ert með lykil og þú getur farið hvenær sem er. VMWare er gyllt búr, eigandinn er með lykilinn að búrinu og það mun kosta þig mikið.
Ég er hvorki að kynna fyrstu vöruna né þá seinni - þú velur það sem þú þarft. En ef ég hefði slíkt val myndi ég velja báðar lausnirnar - VMWare fyrir upplýsingatækniskýið (lítið álag, auðveld stjórnun), OpenStack frá einhverjum söluaðila (Nokia og Juniper bjóða upp á mjög góðar turnkey lausnir) - fyrir Telecom skýið. Ég myndi ekki nota Openstack fyrir hreina upplýsingatækni - það er eins og að skjóta spörva með fallbyssu, en ég sé engar frábendingar við að nota það annað en offramboð. Hins vegar að nota VMWare í fjarskiptum er eins og að draga mulið stein í Ford Raptor - það er fallegt að utan, en ökumaðurinn þarf að fara 10 ferðir í stað einnar.
Að mínu mati er stærsti ókosturinn við VMWare algjörlega lokun þess - fyrirtækið mun ekki gefa þér neinar upplýsingar um hvernig það virkar, td vSAN eða hvað er í hypervisor kjarnanum - það er einfaldlega ekki arðbært fyrir það - það er, þú munt aldrei verða sérfræðingur í VMWare - án stuðnings söluaðila ertu dæmdur (mjög oft hitti ég VMWare sérfræðinga sem eru undrandi yfir léttvægum spurningum). Fyrir mig er VMWare að kaupa bíl með húddinu læst - já, þú gætir verið með sérfræðinga sem geta skipt um tímareim, en aðeins sá sem seldi þér þessa lausn getur opnað húddið. Persónulega líkar mér ekki við lausnir sem ég get ekki passað inn í. Þú munt segja að þú gætir ekki þurft að fara undir hettuna. Já, þetta er mögulegt, en ég mun líta á þig þegar þú þarft að setja saman stóra aðgerð í skýinu úr 20-30 sýndarvélum, 40-50 netkerfum, helmingur þeirra vill fara út og seinni helmingurinn biður um SR-IOV hröðun, annars þarftu fleiri tugi af þessum bílum - annars dugar frammistaðan ekki.
Það eru önnur sjónarmið, þannig að aðeins þú getur ákveðið hvað þú átt að velja og, síðast en ekki síst, þú munt þá bera ábyrgð á vali þínu. Þetta er bara mín skoðun - manneskja sem hefur séð og snert að minnsta kosti 4 vörur - Nokia, Juniper, Red Hat og VMWare. Það er að segja, ég hef eitthvað til að bera saman við.
Heimild: www.habr.com