MÄkoÅdatoÅ”ana arvien dziļÄk iekļūst mÅ«su dzÄ«vÄ, un, iespÄjams, nav neviena cilvÄka, kurÅ” kaut reizi nebÅ«tu izmantojis mÄkoÅpakalpojumus. TaÄu, kas Ä«sti ir mÄkonis un kÄ tas darbojas, pat idejas lÄ«menÄ« zina retais. 5G jau kļūst par realitÄti, un telekomunikÄciju infrastruktÅ«ra sÄk pÄriet no polu risinÄjumiem uz mÄkoÅa risinÄjumiem, tÄpat kÄ tad, kad tÄ no pilnÄ«bÄ aparatÅ«ras risinÄjumiem pÄrcÄlÄs uz virtualizÄtiem "pÄ«lÄriem".
Å odien mÄs runÄsim par mÄkoÅa infrastruktÅ«ras iekÅ”Äjo pasauli, jo Ä«paÅ”i mÄs apskatÄ«sim tÄ«kla daļas pamatus.
Kas ir mÄkonis? TÄ pati virtualizÄcija - profila skats?
VairÄk nekÄ loÄ£isks jautÄjums. NÄ ā tÄ nav virtualizÄcija, lai gan bez tÄs nevarÄtu iztikt. ApskatÄ«sim divas definÄ«cijas:
MÄkoÅdatoÅ”ana (turpmÄk tekstÄ ā mÄkonis) ir modelis lietotÄjam draudzÄ«gas piekļuves nodroÅ”inÄÅ”anai izkliedÄtajiem skaitļoÅ”anas resursiem, kas pÄc pieprasÄ«juma ir jÄizvieto un jÄpalaiž ar iespÄjami zemÄko latentumu un minimÄlÄm izmaksÄm pakalpojumu sniedzÄjam.
VirtualizÄcija - tÄ ir iespÄja sadalÄ«t vienu fizisko entÄ«tiju (piemÄram, serveri) vairÄkÄs virtuÄlajÄs, tÄdÄjÄdi palielinot resursu izmantoÅ”anu (piemÄram, jums bija 3 serveri noslogoti ar 25-30 procentiem, pÄc virtualizÄcijas jÅ«s saÅemat 1 servera ielÄdi par 80-90 procentiem). Protams, virtualizÄcija patÄrÄ daļu resursu - jums ir jÄpabaro hipervizors, tomÄr, kÄ rÄda prakse, spÄle ir sveces vÄrta. IdeÄls virtualizÄcijas piemÄrs ir VMWare, kas lieliski sagatavo virtuÄlÄs maŔīnas vai piemÄram KVM, kam es dodu priekÅ”roku, bet tÄ ir gaumes lieta.
MÄs izmantojam virtualizÄciju, to neapzinoties, un pat dzelzs marÅ”rutÄtÄji jau izmanto virtualizÄciju - piemÄram, jaunÄkajÄ JunOS versijÄ operÄtÄjsistÄma ir instalÄta kÄ virtuÄla maŔīna virs reÄllaika Linux izplatÄ«Å”anas (Wind River 9). Bet virtualizÄcija nav mÄkonis, bet mÄkonis nevar pastÄvÄt bez virtualizÄcijas.
VirtualizÄcija ir viens no elementiem, uz kura tiek veidots mÄkonis.
MÄkoÅa izveide, vienkÄrÅ”i savÄcot vairÄkus hipervizorus vienÄ L2 domÄnÄ, pievienojot pÄris yaml rokasgrÄmatas, lai automÄtiski reÄ£istrÄtu vlans, izmantojot kaut kÄdu ansible, un tam visam iesprÅ«dot kaut ko, piemÄram, orÄ·estrÄÅ”anas sistÄmu, lai automÄtiski izveidotu virtuÄlÄs maŔīnas. Tas bÅ«s precÄ«zÄk, taÄu iegÅ«tais FrankenÅ”teins nav mums vajadzÄ«gais mÄkonis, lai gan tas var bÅ«t galvenais sapnis citiem. TurklÄt, ja Åemat to paÅ”u Openstack, tas bÅ«tÄ«bÄ joprojÄm ir FrankenÅ”teins, bet, labi, par to pagaidÄm nerunÄsim.
Bet es saprotu, ka no iepriekÅ” sniegtÄs definÄ«cijas nav pilnÄ«gi skaidrs, ko patiesÄ«bÄ var saukt par mÄkoni.
TÄpÄc NIST (NacionÄlais standartu un tehnoloÄ£iju institÅ«ts) dokumentÄ ir sniegti 5 galvenie raksturlielumi, kÄdiem jÄbÅ«t mÄkoÅa infrastruktÅ«rai:
Pakalpojumu sniegÅ”ana pÄc pieprasÄ«juma. LietotÄjam ir jÄnodroÅ”ina brÄ«va pieeja viÅam pieŔķirtajiem datora resursiem (piemÄram, tÄ«kliem, virtuÄlajiem diskiem, atmiÅai, procesora kodoliem utt.), un Å”ie resursi ir jÄnodroÅ”ina automÄtiski ā tas ir, bez pakalpojumu sniedzÄja iejaukÅ”anÄs.
PlaÅ”a pakalpojuma pieejamÄ«ba. Piekļuve resursiem jÄnodroÅ”ina ar standarta mehÄnismiem, kas ļautu izmantot gan standarta personÄlos datorus, gan plÄnos klientus un mobilÄs ierÄ«ces.
Resursu apvienoÅ”ana baseinos. Resursu kopumiem jÄspÄj vienlaikus nodroÅ”inÄt resursus vairÄkiem klientiem, nodroÅ”inot, ka klienti ir izolÄti un brÄ«vi no savstarpÄjas ietekmes un konkurences par resursiem. PÅ«los ir iekļauti arÄ« tÄ«kli, kas norÄda uz iespÄju izmantot pÄrklÄjoÅ”u adresÄciju. Baseinus jÄspÄj pielÄgot pÄc pieprasÄ«juma. PÅ«lu izmantoÅ”ana ļauj nodroÅ”inÄt nepiecieÅ”amo resursu kļūdu tolerances lÄ«meni un fizisko un virtuÄlo resursu abstrakciju - pakalpojuma saÅÄmÄjam vienkÄrÅ”i tiek nodroÅ”inÄts viÅa pieprasÄ«tais resursu kopums (kur Å”ie resursi fiziski atrodas, cik daudz serveri un slÄdži - klientam tas nav svarÄ«gi). TaÄu jÄÅem vÄrÄ fakts, ka pakalpojumu sniedzÄjam ir jÄnodroÅ”ina pÄrskatÄma Å”o resursu rezervÄÅ”ana.
Ätra pielÄgoÅ”anÄs dažÄdiem apstÄkļiem. Pakalpojumiem ir jÄbÅ«t elastÄ«giem - Ätra resursu nodroÅ”inÄÅ”ana, to pÄrdale, resursu pievienoÅ”ana vai samazinÄÅ”ana pÄc klienta pieprasÄ«juma, un no klienta puses ir jÄbÅ«t sajÅ«tai, ka mÄkoÅa resursi ir bezgalÄ«gi. Lai atvieglotu izpratni, piemÄram, jÅ«s neredzat brÄ«dinÄjumu, ka daļa no jÅ«su diska vietas pakalpojumÄ Apple iCloud ir pazudusi, jo servera cietais disks ir sabojÄjies un diskdziÅi sabojÄjas. TurklÄt no jÅ«su puses Ŕī servisa iespÄjas ir gandrÄ«z neierobežotas - vajag 2 TB - nekÄdu problÄmu, samaksÄjÄt un saÅÄmÄt. LÄ«dzÄ«gu piemÄru var sniegt ar Google.Drive vai Yandex.Disk.
IespÄja izmÄrÄ«t sniegto pakalpojumu. MÄkoÅsistÄmÄm ir automÄtiski jÄkontrolÄ un jÄoptimizÄ patÄrÄtie resursi, un Å”iem mehÄnismiem ir jÄbÅ«t pÄrskatÄmiem gan lietotÄjam, gan pakalpojuma sniedzÄjam. Tas nozÄ«mÄ, ka jÅ«s vienmÄr varat pÄrbaudÄ«t, cik daudz resursu jÅ«s un jÅ«su klienti patÄrÄ.
Ir vÄrts Åemt vÄrÄ faktu, ka Ŕīs prasÄ«bas pÄrsvarÄ ir prasÄ«bas publiskajam mÄkonim, tÄpÄc privÄtajam mÄkonim (tas ir, uzÅÄmuma iekÅ”ÄjÄm vajadzÄ«bÄm palaistajam mÄkonim) Ŕīs prasÄ«bas var nedaudz koriÄ£Ät. TomÄr tie joprojÄm ir jÄdara, pretÄjÄ gadÄ«jumÄ mÄs neiegÅ«sim visas mÄkoÅdatoÅ”anas priekÅ”rocÄ«bas.
KÄpÄc mums ir vajadzÄ«gs mÄkonis?
TomÄr jebkura jauna vai esoÅ”a tehnoloÄ£ija, jebkurÅ” jauns protokols tiek radÄ«ts kaut kam (nu, protams, izÅemot RIP-ng). Protokols nevienam nav vajadzÄ«gs protokola dÄļ (nu, protams, izÅemot RIP-ng). LoÄ£iski, ka mÄkonis ir izveidots, lai sniegtu lietotÄjam/klientam kÄdu pakalpojumu. MÄs visi esam pazÄ«stami ar vismaz pÄris mÄkoÅpakalpojumiem, piemÄram, Dropbox vai Google.Docs, un es uzskatu, ka lielÄkÄ daļa cilvÄku tos izmanto veiksmÄ«gi ā piemÄram, Å”is raksts tika uzrakstÄ«ts, izmantojot Google.Docs mÄkoÅpakalpojumu. TaÄu mums zinÄmie mÄkoÅpakalpojumi ir tikai daļa no mÄkoÅa iespÄjÄm ā precÄ«zÄk, tie ir tikai SaaS tipa pakalpojumi. MÄs varam nodroÅ”inÄt mÄkoÅpakalpojumu trÄ«s veidos: SaaS, PaaS vai IaaS veidÄ. Tas, kÄds pakalpojums jums ir nepiecieÅ”ams, ir atkarÄ«gs no jÅ«su vÄlmÄm un iespÄjÄm.
ApskatÄ«sim katru secÄ«bÄ:
ProgrammatÅ«ra kÄ pakalpojums (SaaS) ir modelis pilnvÄrtÄ«ga pakalpojuma sniegÅ”anai klientam, piemÄram, e-pasta pakalpojums, piemÄram, Yandex.Mail vai Gmail. Å ajÄ pakalpojuma sniegÅ”anas modelÄ« jÅ«s kÄ klients faktiski neko nedara, izÅemot pakalpojumu izmantoÅ”anu ā tas ir, jums nav jÄdomÄ par pakalpojuma iestatÄ«Å”anu, tÄ kļūdu toleranci vai dublÄÅ”anu. Galvenais ir neapdraudÄt savu paroli; pÄrÄjo jÅ«su vietÄ paveiks Ŕī pakalpojuma sniedzÄjs. No pakalpojumu sniedzÄja viedokļa viÅÅ” ir pilnÄ«bÄ atbildÄ«gs par visu pakalpojumu - no servera aparatÅ«ras un resursdatora operÄtÄjsistÄmÄm lÄ«dz datu bÄzes un programmatÅ«ras iestatÄ«jumiem.
Platforma kÄ pakalpojums (PaaS) ā izmantojot Å”o modeli, pakalpojumu sniedzÄjs nodroÅ”ina klientam pakalpojuma sagatavi, piemÄram, Åemsim Web serveri. Pakalpojuma sniedzÄjs nodroÅ”inÄja klientam virtuÄlo serveri (patiesÄ«bÄ resursu kopumu, piemÄram, RAM/CPU/Storage/Nets u.c.) un pat instalÄja Å”ajÄ serverÄ« OS un nepiecieÅ”amo programmatÅ«ru, tomÄr visu Å”o lietu dara pats klients un par pakalpojuma izpildi klients atbild. Pakalpojuma sniedzÄjs, tÄpat kÄ iepriekÅ”ÄjÄ gadÄ«jumÄ, ir atbildÄ«gs par fiziskÄ aprÄ«kojuma, hipervizoru, paÅ”as virtuÄlÄs maŔīnas darbÄ«bu, tÄs tÄ«kla pieejamÄ«bu utt., bet pats pakalpojums vairs nav tÄ atbildÄ«bas jomÄ.
InfrastruktÅ«ra kÄ pakalpojums (IaaS) - Ŕī pieeja jau ir interesantÄka, faktiski pakalpojumu sniedzÄjs nodroÅ”ina klientam pilnÄ«gu virtualizÄtu infrastruktÅ«ru - tas ir, kÄdu resursu kopumu (kopu), piemÄram, CPU kodoli, RAM, tÄ«kli utt. Viss pÄrÄjais ir atkarÄ«gs no klients - ko klients vÄlas darÄ«t ar Å”iem resursiem pieŔķirtÄ pÅ«la (kvotas) ietvaros - piegÄdÄtÄjam tas nav Ä«paÅ”i svarÄ«gi. NeatkarÄ«gi no tÄ, vai klients vÄlas izveidot savu vEPC vai pat izveidot mini operatoru un sniegt sakaru pakalpojumus - bez Å”aubÄm - dariet to. Å ÄdÄ gadÄ«jumÄ pakalpojumu sniedzÄjs ir atbildÄ«gs par resursu nodroÅ”inÄÅ”anu, to kļūdu toleranci un pieejamÄ«bu, kÄ arÄ« OS, kas ļauj apvienot Å”os resursus un padarÄ«t tos pieejamus klientam ar iespÄju jebkurÄ laikÄ palielinÄt vai samazinÄt resursus. pÄc klienta pieprasÄ«juma. Klients pats konfigurÄ visas virtuÄlÄs maŔīnas un citus sÄ«kumus, izmantojot paÅ”apkalpoÅ”anÄs portÄlu un konsoli, ieskaitot tÄ«klu iestatÄ«Å”anu (izÅemot ÄrÄjos tÄ«klus).
Kas ir OpenStack?
VisÄs trÄ«s opcijÄs pakalpojuma sniedzÄjam ir nepiecieÅ”ama OS, kas ļaus izveidot mÄkoÅa infrastruktÅ«ru. Faktiski ar SaaS vairÄk nekÄ viena nodaļa ir atbildÄ«ga par visu tehnoloÄ£iju kaudzi - ir nodaļa, kas ir atbildÄ«ga par infrastruktÅ«ru - tas ir, tÄ nodroÅ”ina IaaS citai nodaļai, Ŕī nodaļa nodroÅ”ina SaaS klientam. OpenStack ir viena no mÄkoÅa operÄtÄjsistÄmÄm, kas ļauj apkopot virkni slÄdžu, serveru un uzglabÄÅ”anas sistÄmu vienÄ resursu baseinÄ, sadalÄ«t Å”o kopÄjo kopu apakÅ”pulkos (Ä«rniekiem) un nodroÅ”inÄt Å”os resursus klientiem tÄ«klÄ.
OpenStack ir mÄkoÅa operÄtÄjsistÄma, kas ļauj kontrolÄt lielus skaitļoÅ”anas resursu, datu krÄtuves un tÄ«kla resursu kopumus, kas nodroÅ”inÄti un pÄrvaldÄ«ti, izmantojot API, izmantojot standarta autentifikÄcijas mehÄnismus.
Citiem vÄrdiem sakot, Å”is ir bezmaksas programmatÅ«ras projektu kopums, kas paredzÄts mÄkoÅpakalpojumu (gan publisko, gan privÄto) izveidoÅ”anai - tas ir, rÄ«ku komplekts, kas ļauj apvienot serveri un komutÄcijas iekÄrtas vienÄ resursu kopumÄ, pÄrvaldÄ«t. Å”os resursus, nodroÅ”inot nepiecieÅ”amo kļūdu tolerances lÄ«meni.
Å Ä« materiÄla rakstÄ«Å”anas laikÄ OpenStack struktÅ«ra izskatÄs Å”Ädi:
Katrs no OpenStack komponentiem veic noteiktu funkciju. Å Ä« izplatÄ«tÄ arhitektÅ«ra ļauj risinÄjumÄ iekļaut nepiecieÅ”amo funkcionÄlo komponentu komplektu. TomÄr daži komponenti ir saknes komponenti, un to noÅemÅ”ana novedÄ«s pie risinÄjuma kÄ veseluma pilnÄ«gas vai daļÄjas nedarboÅ”anÄs. Å Ä«s sastÄvdaļas parasti klasificÄ Å”Ädi:
Mans Profils ā TÄ«mekļa GUI OpenStack pakalpojumu pÄrvaldÄ«bai
Pamatprincips ir centralizÄts identitÄtes pakalpojums, kas nodroÅ”ina autentifikÄcijas un autorizÄcijas funkcionalitÄti citiem pakalpojumiem, kÄ arÄ« lietotÄju akreditÄcijas datu un viÅu lomu pÄrvaldÄ«bu.
neitronu - tÄ«kla pakalpojums, kas nodroÅ”ina savienojamÄ«bu starp dažÄdu OpenStack pakalpojumu saskarnÄm (tostarp savienojamÄ«bu starp virtuÄlajÄm maŔīnÄm un to piekļuvi Ärpasaulei)
Skatiens ā virtuÄlÄs maŔīnas attÄlu un momentuzÅÄmumu krÄtuve
Swift kods ā nodroÅ”ina piekļuvi krÄtuves objektam
Celometrs ā pakalpojums, kas nodroÅ”ina iespÄju apkopot telemetriju un izmÄrÄ«t pieejamos un patÄrÄtos resursus
Siltums ā uz veidnÄm balstÄ«ta orÄ·estrÄÅ”ana resursu automÄtiskai izveidei un nodroÅ”inÄÅ”anai
Pilns visu projektu saraksts un to mÄrÄ·is ir apskatÄms Å”eit.
Katrs OpenStack komponents ir pakalpojums, kas veic noteiktu funkciju un nodroÅ”ina API, lai pÄrvaldÄ«tu Å”o funkciju un mijiedarbotos ar citiem mÄkoÅa operÄtÄjsistÄmas pakalpojumiem, lai izveidotu vienotu infrastruktÅ«ru. PiemÄram, Nova nodroÅ”ina skaitļoÅ”anas resursu pÄrvaldÄ«bu un API, lai piekļūtu Å”o resursu konfigurÄÅ”anai, Glance nodroÅ”ina attÄlu pÄrvaldÄ«bu un API to pÄrvaldÄ«bai, Cinder nodroÅ”ina bloku krÄtuvi un API to pÄrvaldÄ«bai utt. Visas funkcijas ir savstarpÄji ļoti cieÅ”i saistÄ«tas.
TomÄr, ja paskatÄs uz to, visi pakalpojumi, kas darbojas OpenStack, galu galÄ ir sava veida virtuÄlÄ maŔīna (vai konteiners), kas savienots ar tÄ«klu. Rodas jautÄjums ā kÄpÄc mums vajag tik daudz elementu?
ApskatÄ«sim algoritmu, lai izveidotu virtuÄlo maŔīnu un savienotu to ar tÄ«klu un pastÄvÄ«go krÄtuvi programmÄ Openstack.
Kad veidojat pieprasÄ«jumu izveidot maŔīnu, neatkarÄ«gi no tÄ, vai tas ir pieprasÄ«jums, izmantojot Horizon (informÄcijas paneli) vai pieprasÄ«jums, izmantojot CLI, pirmÄ lieta, kas notiek, ir jÅ«su pieprasÄ«juma autorizÄcija Keystone ā vai varat izveidot maŔīnu, vai tai ir tiesÄ«bas izmantot Å”o tÄ«klu, vai jÅ«su kvotas projekts utt.
Keystone autentificÄ jÅ«su pieprasÄ«jumu un atbildes ziÅojumÄ Ä£enerÄ autentifikÄcijas pilnvaru, kas tiks izmantota turpmÄk. SaÅemot atbildi no Keystone, pieprasÄ«jums tiek nosÅ«tÄ«ts uz Nova (nova api).
Nova-api pÄrbauda jÅ«su pieprasÄ«juma derÄ«gumu, sazinoties ar Keystone, izmantojot iepriekÅ” Ä£enerÄtu autentifikÄcijas pilnvaru
Keystone veic autentifikÄciju un sniedz informÄciju par atļaujÄm un ierobežojumiem, pamatojoties uz Å”o autentifikÄcijas pilnvaru.
Nova-api izveido jaunÄs virtuÄlÄs maŔīnas ierakstu nova-database un nosÅ«ta pieprasÄ«jumu izveidot maŔīnu nova-scheduler.
Nova-scheduler atlasa resursdatoru (datora mezglu), uz kura tiks izvietota virtuÄlÄ maŔīna, pamatojoties uz norÄdÄ«tajiem parametriem, svariem un zonÄm. Ieraksts par Å”o un virtuÄlÄs maŔīnas ID tiek ierakstÄ«ts nova-database.
PÄc tam nova-scheduler sazinÄs ar nova-compute ar pieprasÄ«jumu izvietot gadÄ«jumu. Nova-compute sazinÄs ar nova-conductor, lai iegÅ«tu informÄciju par maŔīnas parametriem (nova-conductor ir nova elements, kas darbojas kÄ starpniekserveris starp nova-database un nova-compute, ierobežojot pieprasÄ«jumu skaitu nova-database, lai izvairÄ«tos no problÄmÄm ar datu bÄzi konsistences slodzes samazinÄÅ”ana).
Nova-conductor saÅem pieprasÄ«to informÄciju no nova-database un nodod to nova-compute.
PÄc tam nova-compute zvani, lai iegÅ«tu attÄla ID. Glace apstiprina pieprasÄ«jumu Keystone un atgriež pieprasÄ«to informÄciju.
Nova-compute sazinÄs ar neitronu, lai iegÅ«tu informÄciju par tÄ«kla parametriem. LÄ«dzÄ«gi kÄ skatiens, neitrons apstiprina pieprasÄ«jumu Keystone, pÄc tam izveido ierakstu datu bÄzÄ (porta identifikatoru utt.), izveido pieprasÄ«jumu izveidot portu un atgriež pieprasÄ«to informÄciju nova-compute.
Nova-compute sazinÄs ar lÅ«gumu pieŔķirt sÄjumu virtuÄlajai maŔīnai. LÄ«dzÄ«gi kÄ skatiens, sidrs apstiprina pieprasÄ«jumu Keystone, izveido sÄjuma izveides pieprasÄ«jumu un atgriež pieprasÄ«to informÄciju.
Nova-compute sazinÄs ar libvirt ar pieprasÄ«jumu izvietot virtuÄlo maŔīnu ar norÄdÄ«tajiem parametriem.
PatiesÄ«bÄ Å”Ä·ietami vienkÄrÅ”a vienkÄrÅ”as virtuÄlÄs maŔīnas izveides darbÄ«ba pÄrvÄrÅ”as par Å”Ädu API zvanu virpuli starp mÄkoÅa platformas elementiem. TurklÄt, kÄ redzat, pat iepriekÅ” noteiktie pakalpojumi sastÄv no mazÄkiem komponentiem, starp kuriem notiek mijiedarbÄ«ba. MaŔīnas izveide ir tikai neliela daļa no tÄ, ko mÄkoÅa platforma ļauj darÄ«t ā ir pakalpojums, kas atbild par trafika lÄ«dzsvaroÅ”anu, pakalpojums, kas atbild par bloku krÄtuvi, pakalpojums, kas atbild par DNS, pakalpojums, kas atbild par tukÅ”a metÄla serveru nodroÅ”inÄÅ”anu utt. MÄkonis ļauj jums izturÄties pret virtuÄlajÄm maŔīnÄm kÄ pret aitu ganÄmpulku (pretstatÄ virtualizÄcijai). Ja kaut kas notiek ar jÅ«su maŔīnu virtuÄlajÄ vidÄ - jÅ«s to atjaunojat no dublÄjumkopijÄm utt., bet mÄkoÅa aplikÄcijas ir uzbÅ«vÄtas tÄ, ka virtuÄlÄ maŔīna nespÄlÄ tik svarÄ«gu lomu - virtuÄlÄ maŔīna "nomira" - nav problÄmu - vienkÄrÅ”i tiek izveidots jauns, transportlÄ«dzeklis ir balstÄ«ts uz veidni, un, kÄ saka, komanda nepamanÄ«ja cÄ«nÄ«tÄja zaudÄjumu. Protams, tas nodroÅ”ina orÄ·estrÄÅ”anas mehÄnismu klÄtbÅ«tni - izmantojot Heat veidnes, jÅ«s varat viegli izvietot sarežģītu funkciju, kas sastÄv no desmitiem tÄ«klu un virtuÄlo maŔīnu.
VienmÄr ir vÄrts paturÄt prÄtÄ, ka nav mÄkoÅa infrastruktÅ«ras bez tÄ«kla ā katrs elements tÄdÄ vai citÄdÄ veidÄ mijiedarbojas ar citiem elementiem caur tÄ«klu. TurklÄt mÄkonim ir absolÅ«ti nestatisks tÄ«kls. Dabiski, ka apakÅ”tÄ«kls ir pat vairÄk vai mazÄk statisks - jauni mezgli un slÄdži netiek pievienoti katru dienu, bet pÄrklÄjuma komponents var un neizbÄgami mainÄ«sies pastÄvÄ«gi - tiks pievienoti vai dzÄsti jauni tÄ«kli, parÄdÄ«sies jaunas virtuÄlÄs maŔīnas un vecÄs. mirt. Un, kÄ jÅ«s atceraties no mÄkoÅa definÄ«cijas, kas sniegta paÅ”Ä raksta sÄkumÄ, resursi lietotÄjam ir jÄpieŔķir automÄtiski un ar vismazÄko (vai vÄl labÄk, bez) pakalpojumu sniedzÄja iejaukÅ”anÄs. Tas nozÄ«mÄ, ka tÄ«kla resursu nodroÅ”inÄÅ”anas veids, kas tagad pastÄv priekÅ”gala veidÄ jÅ«su personÄ«gÄ konta veidÄ, kuram var piekļūt, izmantojot http/https, un dežurÄjoÅ”ais tÄ«kla inženieris Vasilijs kÄ aizmugursistÄma nav mÄkonis, pat ja Vasilijam ir astoÅas rokas.
Neutron kÄ tÄ«kla pakalpojums nodroÅ”ina API mÄkoÅa infrastruktÅ«ras tÄ«kla daļas pÄrvaldÄ«Å”anai. Pakalpojums nodroÅ”ina un pÄrvalda Openstack tÄ«kla daļu, nodroÅ”inot abstrakcijas slÄni ar nosaukumu Network-as-a-Service (NaaS). Tas nozÄ«mÄ, ka tÄ«kls ir tÄda pati virtuÄlÄ izmÄrÄmÄ vienÄ«ba kÄ, piemÄram, virtuÄlie CPU kodoli vai RAM apjoms.
Bet pirms pÄriet uz OpenStack tÄ«kla daļas arhitektÅ«ru, apskatÄ«sim, kÄ Å”is tÄ«kls darbojas OpenStack un kÄpÄc tÄ«kls ir svarÄ«ga un neatÅemama mÄkoÅa sastÄvdaļa.
TÄtad mums ir divas RED klientu virtuÄlÄs maŔīnas un divas GREEN klienta virtuÄlÄs maŔīnas. PieÅemsim, ka Ŕīs maŔīnas atrodas uz diviem hipervizoriem Å”ÄdÄ veidÄ:
Å obrÄ«d tÄ ir tikai 4 serveru virtualizÄcija un nekas vairÄk, jo lÄ«dz Å”im viss, ko esam paveikuÅ”i, ir virtualizÄjuÅ”i 4 serverus, novietojot tos uz diviem fiziskajiem serveriem. Un lÄ«dz Å”im tie pat nav savienoti ar tÄ«klu.
Lai izveidotu mÄkoni, mums jÄpievieno vairÄki komponenti. PirmkÄrt, mÄs virtualizÄjam tÄ«kla daļu - mums ir jÄsavieno Ŕīs 4 maŔīnas pa pÄriem, un klienti vÄlas L2 savienojumu. Varat izmantot slÄdzi un konfigurÄt maÄ£istrÄli tÄ virzienÄ un atrisinÄt visu, izmantojot linux tiltu vai, pieredzÄjuÅ”Äkiem lietotÄjiem, openvswitch (pie tÄ atgriezÄ«simies vÄlÄk). TaÄu tÄ«klu var bÅ«t daudz, un nepÄrtraukta L2 stumÅ”ana caur slÄdzi nav tÄ labÄkÄ ideja ā ir dažÄdas nodaļas, apkalpoÅ”anas galds, mÄneÅ”iem ilgi jÄgaida, lÄ«dz tiks pabeigta lietojumprogramma, nedÄļÄm ilga problÄmu novÄrÅ”ana ā mÅ«sdienu pasaulÄ tas ir pieeja vairs nedarbojas. Un jo ÄtrÄk uzÅÄmums to saprot, jo vieglÄk tam ir virzÄ«ties uz priekÅ”u. TÄpÄc starp hipervizoriem mÄs izvÄlÄsimies L3 tÄ«klu, caur kuru sazinÄsies mÅ«su virtuÄlÄs maŔīnas, un papildus Å”im L3 tÄ«klam mÄs izveidosim virtuÄlos L2 pÄrklÄjuma tÄ«klus, kuros darbosies mÅ«su virtuÄlo maŔīnu trafiks. KÄ iekapsulÄÅ”anu varat izmantot GRE, Geneve vai VxLAN. PagaidÄm pievÄrsÄ«simies pÄdÄjam, lai gan tas nav Ä«paÅ”i svarÄ«gi.
Mums kaut kur jÄatrod VTEP (es ceru, ka visi ir pazÄ«stami ar VxLAN terminoloÄ£iju). TÄ kÄ mums ir L3 tÄ«kls, kas nÄk tieÅ”i no serveriem, nekas neliedz mums izvietot VTEP paÅ”os serveros, un OVS (OpenvSwitch) lieliski to dara. RezultÄtÄ mÄs ieguvÄm Å”Ädu dizainu:
TÄ kÄ satiksme starp virtuÄlajÄm maŔīnÄm ir jÄsadala, portiem, kas vÄrsti uz virtuÄlajÄm maŔīnÄm, bÅ«s atŔķirÄ«gi VLAN numuri. Taga numuram ir nozÄ«me tikai vienÄ virtuÄlajÄ slÄdžÄ, jo, kad tas ir iekapsulÄts VxLAN, mÄs to varam viegli noÅemt, jo mums bÅ«s VNI.
Tagad mÄs varam bez problÄmÄm izveidot viÅiem savas maŔīnas un virtuÄlos tÄ«klus.
TomÄr ko darÄ«t, ja klientam ir cita iekÄrta, bet tas atrodas citÄ tÄ«klÄ? Mums ir nepiecieÅ”ama sakÅu izveide starp tÄ«kliem. MÄs apskatÄ«sim vienkÄrÅ”u iespÄju, ja tiek izmantota centralizÄta marÅ”rutÄÅ”ana - tas ir, trafika tiek marÅ”rutÄta caur Ä«paÅ”iem Ä«paÅ”iem tÄ«kla mezgliem (kÄ likums, tie ir apvienoti ar vadÄ«bas mezgliem, tÄpÄc mums bÅ«s tas pats).
Å Ä·iet, ka nekas sarežģīts - mÄs uztaisÄm tilta interfeisu uz vadÄ«bas mezgla, pievadÄm satiksmi uz to un no turienes virzÄm to, kur mums tas ir nepiecieÅ”ams. Bet problÄma ir tÄ, ka RED klients vÄlas izmantot 10.0.0.0/24 tÄ«klu, bet GREEN klients vÄlas izmantot 10.0.0.0/24 tÄ«klu. Tas ir, mÄs sÄkam krustot adreÅ”u telpas. TurklÄt klienti nevÄlas, lai citi klienti varÄtu marÅ”rutÄt viÅu iekÅ”Äjos tÄ«klos, kas ir loÄ£iski. Lai nodalÄ«tu tÄ«klus un klientu datu trafiku, katram no tiem pieŔķirsim atseviŔķu nosaukumvietu. Nosaukumvieta faktiski ir Linux tÄ«kla steka kopija, tas ir, klienti nosaukumvietÄ RED ir pilnÄ«bÄ izolÄti no klientiem no nosaukumvietas GREEN (labi, vai nu marÅ”rutÄÅ”ana starp Å”iem klientu tÄ«kliem ir atļauta, izmantojot noklusÄjuma nosaukumvietu vai augÅ”upÄjÄs transporta iekÄrtas).
Tas ir, mÄs iegÅ«stam Å”Ädu diagrammu:
L2 tuneļi saplÅ«st no visiem skaitļoÅ”anas mezgliem uz vadÄ«bas mezglu. mezgls, kurÄ atrodas Å”o tÄ«klu L3 interfeiss, katrs atseviÅ”Ä·Ä nosaukumvietÄ izolÄcijai.
TomÄr mÄs aizmirsÄm vissvarÄ«gÄko. VirtuÄlajai maŔīnai ir jÄnodroÅ”ina pakalpojums klientam, tas ir, tai ir jÄbÅ«t vismaz vienam ÄrÄjam interfeisam, caur kuru to var sasniegt. Tas ir, mums ir jÄiziet ÄrpasaulÄ. Å eit ir dažÄdas iespÄjas. IzdarÄ«sim vienkÄrÅ”Äko variantu. Katram klientam pievienosim vienu tÄ«klu, kas bÅ«s derÄ«gs pakalpojumu sniedzÄja tÄ«klÄ un nepÄrklÄsies ar citiem tÄ«kliem. TÄ«kli var arÄ« krustoties un apskatÄ«t dažÄdus VRF pakalpojumu sniedzÄja tÄ«kla pusÄ. TÄ«kla dati arÄ« dzÄ«vos katra klienta nosaukumu telpÄ. TomÄr viÅi joprojÄm izies uz Ärpasauli, izmantojot vienu fizisku (vai saiti, kas ir loÄ£iskÄk) saskarni. Lai atdalÄ«tu klienta trafiku, datplÅ«sma, kas iziet ÄrpusÄ, tiks marÄ·Äta ar klientam pieŔķirto VLAN tagu.
RezultÄtÄ mÄs saÅÄmÄm Å”Ädu diagrammu:
SaprÄtÄ«gs jautÄjums ir, kÄpÄc gan neizveidot vÄrtejas paÅ”os skaitļoÅ”anas mezglos? TÄ nav liela problÄma; turklÄt, ja ieslÄdzat sadalÄ«to marÅ”rutÄtÄju (DVR), tas darbosies. Å ajÄ scenÄrijÄ mÄs apsveram vienkÄrÅ”Äko iespÄju ar centralizÄtu vÄrteju, kas tiek izmantota pÄc noklusÄjuma Openstack. Lielas slodzes funkcijÄm tie izmantos gan sadalÄ«to marÅ”rutÄtÄju, gan paÄtrinÄÅ”anas tehnoloÄ£ijas, piemÄram, SR-IOV un Passthrough, taÄu, kÄ viÅi saka, tas ir pavisam cits stÄsts. Vispirms apskatÄ«sim pamata daļu, un tad iedziļinÄsimies detaļÄs.
PatiesÄ«bÄ mÅ«su shÄma jau darbojas, taÄu ir dažas nianses:
Mums ir kaut kÄ jÄaizsargÄ mÅ«su maŔīnas, tas ir, slÄdža saskarnÄ jÄievieto filtrs pret klientu.
Dodiet iespÄju virtuÄlajai maŔīnai automÄtiski iegÅ«t IP adresi, lai jums nebÅ«tu katru reizi tajÄ jÄpiesakÄs caur konsoli un jÄreÄ£istrÄ adrese.
SÄksim ar maŔīnu aizsardzÄ«bu. Å im nolÅ«kam varat izmantot banÄlus iptables, kÄpÄc gan ne.
Tas ir, tagad mÅ«su topoloÄ£ija ir kļuvusi nedaudz sarežģītÄka:
Ejam tÄlÄk. Mums jÄpievieno DHCP serveris. IdeÄlÄkÄ vieta DHCP serveru atraÅ”anai katram klientam bÅ«tu jau iepriekÅ” minÄtais vadÄ«bas mezgls, kurÄ atrodas nosaukumu telpas:
TomÄr ir neliela problÄma. Ko darÄ«t, ja viss tiek restartÄts un visa informÄcija par adreÅ”u nomu DHCP tÄ«klÄ pazÅ«d. LoÄ£iski, ka automÄtiem tiks pieŔķirtas jaunas adreses, kas nav Ä«paÅ”i Ärti. Å eit ir divas izejas - vai nu izmantojiet domÄna nosaukumus un pievienojiet DNS serveri katram klientam, tad adrese mums nebÅ«s Ä«paÅ”i svarÄ«ga (lÄ«dzÄ«gi kÄ tÄ«kla daļai k8s) - taÄu ir problÄma ar ÄrÄjiem tÄ«kliem, jo adreses tajÄs var izsniegt arÄ« caur DHCP - nepiecieÅ”ama sinhronizÄcija ar DNS serveriem mÄkoÅplatformÄ un ÄrÄjais DNS serveris, kas manuprÄt nav Ä«paÅ”i elastÄ«gs, bet ir pilnÄ«gi iespÄjams. Vai arÄ« otrÄ iespÄja ir izmantot metadatus - tas ir, saglabÄt informÄciju par maŔīnai izsniegto adresi, lai DHCP serveris zinÄtu, kuru adresi iekÄrtai izsniegt, ja iekÄrta jau ir saÅÄmusi adresi. OtrÄ iespÄja ir vienkÄrÅ”Äka un elastÄ«gÄka, jo ļauj saglabÄt papildu informÄciju par automaŔīnu. Tagad pievienosim diagrammai aÄ£enta metadatus:
VÄl viens jautÄjums, kas arÄ« ir vÄrts apspriest, ir iespÄja visiem klientiem izmantot vienu ÄrÄjo tÄ«klu, jo ÄrÄjie tÄ«kli, ja tiem ir jÄbÅ«t derÄ«giem visÄ tÄ«klÄ, bÅ«s sarežģīti - jums ir pastÄvÄ«gi jÄpieŔķir un jÄkontrolÄ Å”o tÄ«klu pieŔķirÅ”ana. IespÄja izmantot vienu ÄrÄju iepriekÅ” konfigurÄtu tÄ«klu visiem klientiem bÅ«s ļoti noderÄ«ga, veidojot publisko mÄkoni. Tas atvieglos maŔīnu izvietoÅ”anu, jo mums nav jÄmeklÄ adreÅ”u datubÄze un jÄizvÄlas unikÄla adreÅ”u telpa katra klienta ÄrÄjam tÄ«klam. TurklÄt mÄs varam iepriekÅ” reÄ£istrÄt ÄrÄjo tÄ«klu, un izvietoÅ”anas laikÄ mums bÅ«s jÄsaista tikai ÄrÄjÄs adreses ar klientu iekÄrtÄm.
Un Å”eit mums palÄ«dz NAT ā mÄs tikai nodroÅ”inÄsim klientiem piekļuvi Ärpasaulei, izmantojot noklusÄjuma nosaukumvietu, izmantojot NAT tulkojumu. Nu, lÅ«k, neliela problÄma. Tas ir labi, ja klienta serveris darbojas kÄ klients, nevis kÄ serveris - tas ir, tas iniciÄ, nevis pieÅem savienojumus. Bet mums bÅ«s otrÄdi. Å ajÄ gadÄ«jumÄ mums ir jÄveic galamÄrÄ·a NAT, lai, saÅemot trafiku, vadÄ«bas mezgls saprastu, ka Ŕī trafika ir paredzÄta klienta A virtuÄlajai maŔīnai A, kas nozÄ«mÄ, ka mums ir jÄveic NAT tulkojums no ÄrÄjÄs adreses, piemÄram, 100.1.1.1. .10.0.0.1, uz iekÅ”Äjo adresi 100. Å ajÄ gadÄ«jumÄ, lai gan visi klienti izmantos vienu un to paÅ”u tÄ«klu, iekÅ”ÄjÄ izolÄcija ir pilnÄ«bÄ saglabÄta. Tas ir, mums ir jÄveic dNAT un sNAT vadÄ«bas mezglÄ. Tas, vai izmantot vienu tÄ«klu ar peldoÅ”Äm adresÄm vai ÄrÄjiem tÄ«kliem, vai abus vienlaikus, ir atkarÄ«gs no tÄ, ko vÄlaties ievietot mÄkonÄ«. MÄs diagrammai nepievienosim peldoÅ”Äs adreses, bet atstÄsim jau iepriekÅ” pievienotos ÄrÄjos tÄ«klus - katram klientam ir savs ÄrÄjais tÄ«kls (shÄmÄ tie ir norÄdÄ«ti kÄ vlan 200 un XNUMX ÄrÄjÄ saskarnÄ).
RezultÄtÄ saÅÄmÄm interesantu un tajÄ paÅ”Ä laikÄ pÄrdomÄtu risinÄjumu, kuram ir zinÄma elastÄ«ba, bet vÄl nav kļūdu tolerances mehÄnismu.
PirmkÄrt, mums ir tikai viens vadÄ«bas mezgls - tÄ kļūme novedÄ«s pie visu sistÄmu sabrukuma. Lai novÄrstu Å”o problÄmu, jums ir nepiecieÅ”ams vismaz 3 mezglu kvorums. Pievienosim diagrammai Å”o:
Protams, visi mezgli tiek sinhronizÄti un, kad aktÄ«vs mezgls aiziet, cits mezgls pÄrÅems savus pienÄkumus.
NÄkamÄ problÄma ir virtuÄlÄs maŔīnas diski. Å obrÄ«d tie tiek glabÄti paÅ”os hipervizoros, un, ja rodas problÄmas ar hipervizoru, mÄs zaudÄjam visus datus - un reida klÄtbÅ«tne Å”eit nepalÄ«dzÄs, ja mÄs zaudÄsim nevis disku, bet visu serveri. Lai to izdarÄ«tu, mums ir jÄizveido pakalpojums, kas darbosies kÄ kÄda veida krÄtuves priekÅ”gals. Mums nav Ä«paÅ”i svarÄ«gi, kÄda veida krÄtuve tÄ bÅ«s, taÄu tai vajadzÄtu aizsargÄt mÅ«su datus no diska un mezgla un, iespÄjams, visa korpusa kļūmÄm. Å eit ir vairÄkas iespÄjas - ir, protams, SAN tÄ«kli ar Fibre Channel, bet bÅ«sim godÄ«gi - FC jau ir pagÄtnes relikts - E1 analogs transportÄ - jÄ, piekrÄ«tu, joprojÄm tiek izmantots, bet tikai tur, kur bez tÄ nav iespÄjams. TÄpÄc es 2020. gadÄ brÄ«vprÄtÄ«gi neizvietotu FC tÄ«klu, zinot, ka ir arÄ« citas interesantÄkas alternatÄ«vas. Lai gan katram savs, iespÄjams, ir tÄdi, kas uzskata, ka FC ar visiem tÄs ierobežojumiem ir viss, kas mums vajadzÄ«gs - nestrÄ«dÄÅ”os, katram savs viedoklis. TomÄr visinteresantÄkais risinÄjums, manuprÄt, ir izmantot SDS, piemÄram, Ceph.
Ceph ļauj izveidot ļoti pieejamu datu glabÄÅ”anas risinÄjumu ar daudzÄm iespÄjamÄm rezerves iespÄjÄm, sÄkot ar kodiem ar paritÄtes pÄrbaudi (analogs 5. vai 6. reidam) un beidzot ar pilnu datu replikÄciju dažÄdos diskos, Åemot vÄrÄ disku atraÅ”anÄs vietu serveri un serveri kabinetos utt.
Lai izveidotu Ceph, jums ir nepiecieÅ”ami vÄl 3 mezgli. MijiedarbÄ«ba ar krÄtuvi tiks veikta arÄ« caur tÄ«klu, izmantojot bloku, objektu un failu uzglabÄÅ”anas pakalpojumus. Pievienosim shÄmai krÄtuvi:
PiezÄ«me: varat izveidot arÄ« hiperkonverÄ£Ätus skaitļoÅ”anas mezglus ā tÄ ir vairÄku funkciju apvienoÅ”anas koncepcija vienÄ mezglÄ, piemÄram, krÄtuve+aprÄÄ·inÄÅ”ana, neatvÄlot Ä«paÅ”us mezglus ceph glabÄÅ”anai. MÄs iegÅ«sim to paÅ”u kļūdu izturÄ«go shÄmu - tÄ kÄ SDS rezervÄs datus ar mÅ«su norÄdÄ«to rezervÄcijas lÄ«meni. TomÄr hiperkonverÄ£Ätie mezgli vienmÄr ir kompromiss ā tÄ kÄ uzglabÄÅ”anas mezgls ne tikai silda gaisu, kÄ Å”Ä·iet pirmajÄ mirklÄ« (jo tajÄ nav virtuÄlo maŔīnu), ā tas tÄrÄ CPU resursus SDS apkalpoÅ”anai (patiesÄ«bÄ tas dara visu replikÄcija un atkopÅ”ana pÄc mezglu, disku uc kļūmÄm). Tas nozÄ«mÄ, ka, apvienojot to ar krÄtuvi, jÅ«s zaudÄsit daļu no aprÄÄ·ina mezgla jaudas.
Visas Ŕīs lietas ir kaut kÄ jÄpÄrvalda ā mums ir nepiecieÅ”ams kaut kas, ar kura palÄ«dzÄ«bu mÄs varam izveidot maŔīnu, tÄ«klu, virtuÄlo marÅ”rutÄtÄju utt. Lai to izdarÄ«tu, vadÄ«bas mezglam pievienosim pakalpojumu, kas darbosies kÄ informÄcijas panelis ā klients varÄs pieslÄgties Å”im portÄlam caur http/ https un darÄ«t visu nepiecieÅ”amo (nu, gandrÄ«z).
TÄ rezultÄtÄ mums tagad ir kļūmju izturÄ«ga sistÄma. Visi Ŕīs infrastruktÅ«ras elementi ir kaut kÄ jÄpÄrvalda. IepriekÅ” tika aprakstÄ«ts, ka Openstack ir projektu kopums, no kuriem katrs nodroÅ”ina noteiktu funkciju. KÄ redzam, elementu, kas jÄkonfigurÄ un jÄkontrolÄ, ir vairÄk nekÄ pietiekami. Å odien mÄs runÄsim par tÄ«kla daļu.
Neitronu arhitektūra
OpenStack tieÅ”i Neutron ir atbildÄ«gs par virtuÄlÄs maŔīnas pieslÄgvietu pievienoÅ”anu kopÄjam L2 tÄ«klam, trafika marÅ”rutÄÅ”anas nodroÅ”inÄÅ”anu starp virtuÄlajÄm maŔīnÄm, kas atrodas dažÄdos L2 tÄ«klos, kÄ arÄ« izbraukÅ”anu, nodroÅ”inot tÄdus pakalpojumus kÄ NAT, Floating IP, DHCP u.c.
AugstÄ lÄ«menÄ« tÄ«kla pakalpojuma (pamata daļas) darbÄ«bu var raksturot Å”Ädi.
Izveido portu dotajai VM (vai portiem) un paziÅo par to DHCP servisam;
Tiek izveidota jauna virtuÄlÄ tÄ«kla ierÄ«ce (izmantojot libvirt);
VirtuÄlÄ maŔīna izveido savienojumu ar 1. darbÄ«bÄ izveidoto(-iem) portu(-iem);
SavÄdi, bet Neutron darbs ir balstÄ«ts uz standarta mehÄnismiem, kas ir pazÄ«stami ikvienam, kurÅ” jebkad ir ieniris Linux - namespaces, iptables, Linux tilti, openvswitch, conntrack utt.
NekavÄjoties jÄprecizÄ, ka Neutron nav SDN kontrolieris.
Neitrons sastÄv no vairÄkiem savstarpÄji saistÄ«tiem komponentiem:
Openstack-neutron-serveris ir dÄmons, kas darbojas ar lietotÄju pieprasÄ«jumiem, izmantojot API. Å is dÄmons nav iesaistÄ«ts tÄ«kla savienojumu reÄ£istrÄÅ”anÄ, bet sniedz Å”im nolÅ«kam nepiecieÅ”amo informÄciju saviem spraudÅiem, kas pÄc tam konfigurÄ vÄlamo tÄ«kla elementu. Neitronu aÄ£enti OpenStack mezglos reÄ£istrÄjas Neutron serverÄ«.
Neitron-serveris faktiski ir lietojumprogramma, kas rakstÄ«ta python un sastÄv no divÄm daļÄm:
REST serviss
Neitron spraudnis (pamats/pakalpojums)
Pakalpojums REST ir paredzÄts API zvanu saÅemÅ”anai no citiem komponentiem (piemÄram, pieprasÄ«jumu sniegt kÄdu informÄciju utt.)
SpraudÅi ir spraudÅu programmatÅ«ras komponenti/moduļi, kas tiek izsaukti API pieprasÄ«jumu laikÄ ā tas ir, pakalpojuma attiecinÄÅ”ana notiek caur tiem. SpraudÅi ir sadalÄ«ti divos veidos - serviss un saknes. Parasti zirga spraudnis galvenokÄrt ir atbildÄ«gs par adreÅ”u telpas un L2 savienojumu pÄrvaldÄ«bu starp virtuÄlajÄm maŔīnÄm, un pakalpojumu spraudÅi jau nodroÅ”ina papildu funkcionalitÄti, piemÄram, VPN vai FW.
PiemÄram, var apskatÄ«t Å”odien pieejamo spraudÅu sarakstu Å”eit
Var bÅ«t vairÄki pakalpojumu spraudÅi, bet var bÅ«t tikai viens zirgu spraudnis.
openstack-neutron-ml2 ir standarta Openstack saknes spraudnis. Å im spraudnim ir modulÄra arhitektÅ«ra (atŔķirÄ«bÄ no tÄ priekÅ”gÄjÄja), un tas konfigurÄ tÄ«kla pakalpojumu, izmantojot tam pievienotos draiverus. PaÅ”u spraudni apskatÄ«sim nedaudz vÄlÄk, jo patiesÄ«bÄ tas nodroÅ”ina OpenStack tÄ«kla daļas elastÄ«bu. Saknes spraudni var aizstÄt (piemÄram, Contrail Networking veic Å”Ädu nomaiÅu).
RPC pakalpojums (rabbitmq-server) ā pakalpojums, kas nodroÅ”ina rindu pÄrvaldÄ«bu un mijiedarbÄ«bu ar citiem OpenStack pakalpojumiem, kÄ arÄ« mijiedarbÄ«bu starp tÄ«kla pakalpojumu aÄ£entiem.
TÄ«kla aÄ£enti ā aÄ£enti, kas atrodas katrÄ mezglÄ, caur kuriem tiek konfigurÄti tÄ«kla pakalpojumi.
Ir vairÄki aÄ£entu veidi.
Galvenais aÄ£ents ir L2 aÄ£ents. Å ie aÄ£enti darbojas katrÄ no hipervizoriem, tostarp vadÄ«bas mezgliem (precÄ«zÄk, visos mezglos, kas sniedz jebkÄdus pakalpojumus nomniekiem), un to galvenÄ funkcija ir savienot virtuÄlÄs maŔīnas ar kopÄju L2 tÄ«klu, kÄ arÄ« Ä£enerÄt brÄ«dinÄjumus, kad notiek kÄdi notikumi ( piemÄram, atspÄjot/iespÄjot portu).
NÄkamais, ne mazÄk svarÄ«gais aÄ£ents ir L3 aÄ£ents. PÄc noklusÄjuma Å”is aÄ£ents darbojas tikai tÄ«kla mezglÄ (bieži tÄ«kla mezgls tiek apvienots ar vadÄ«bas mezglu) un nodroÅ”ina marÅ”rutÄÅ”anu starp nomnieku tÄ«kliem (gan starp saviem tÄ«kliem, gan citu nomnieku tÄ«kliem, kÄ arÄ« ir pieejams Ärpasaulei, nodroÅ”inot NAT, kÄ arÄ« DHCP pakalpojumu). TomÄr, izmantojot DVR (distributed router), nepiecieÅ”amÄ«ba pÄc L3 spraudÅa parÄdÄs arÄ« skaitļoÅ”anas mezglos.
L3 aÄ£ents izmanto Linux nosaukumvietas, lai nodroÅ”inÄtu katram nomniekam savu izolÄtu tÄ«klu kopu un virtuÄlo marÅ”rutÄtÄju funkcionalitÄti, kas marÅ”rutÄ trafiku un nodroÅ”ina vÄrtejas pakalpojumus 2. slÄÅa tÄ«kliem.
DatubÄze ā tÄ«klu, apakÅ”tÄ«klu, portu, kopu utt. identifikatoru datu bÄze.
Faktiski Neutron pieÅem API pieprasÄ«jumus no jebkura tÄ«kla entÄ«tiju izveides, autentificÄ pieprasÄ«jumu un caur RPC (ja tas piekļūst kÄdam spraudnim vai aÄ£entam) vai REST API (ja tas sazinÄs SDN) pÄrsÅ«ta aÄ£entiem (izmantojot spraudÅus) norÄdÄ«jumi, kas nepiecieÅ”ami pieprasÄ«tÄ pakalpojuma organizÄÅ”anai.
Tagad pievÄrsÄ«simies testa instalÄcijai (kÄ tÄ tiek izvietota un kas tajÄ ir iekļauta, redzÄsim vÄlÄk praktiskajÄ daļÄ) un redzÄsim, kur atrodas katra sastÄvdaļa:
(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 ~]$
Faktiski tÄ ir visa neitrona struktÅ«ra. Tagad ir vÄrts kÄdu laiku veltÄ«t spraudnim ML2.
2. moduļu slÄnis
KÄ minÄts iepriekÅ”, spraudnis ir standarta OpenStack saknes spraudnis, un tam ir modulÄra arhitektÅ«ra.
ML2 spraudÅa priekÅ”gÄjÄjam bija monolÄ«ta struktÅ«ra, kas neļÄva, piemÄram, vienÄ instalÄcijÄ izmantot vairÄku tehnoloÄ£iju sajaukumu. PiemÄram, jÅ«s nevarÄjÄt vienlaikus izmantot gan openvswitch, gan linuxbridge - ne pirmo, ne otro. Å Ä« iemesla dÄļ tika izveidots spraudnis ML2 ar tÄ arhitektÅ«ru.
ML2 ir divas sastÄvdaļas - divu veidu draiveri: tipa draiveri un mehÄnisma draiveri.
Ierakstiet draiverus noteikt tehnoloÄ£ijas, kas tiks izmantotas tÄ«kla savienojumu organizÄÅ”anai, piemÄram, VxLAN, VLAN, GRE. TajÄ paÅ”Ä laikÄ vadÄ«tÄjs ļauj izmantot dažÄdas tehnoloÄ£ijas. Standarta tehnoloÄ£ija ir VxLAN iekapsulÄÅ”ana pÄrklÄjuma tÄ«kliem un VLAN ÄrÄjiem tÄ«kliem.
Tipu draiveri ietver Å”Ädus tÄ«klu veidus:
DzÄ«voklis - tÄ«kls bez marÄ·ÄÅ”anas VLAN - atzÄ«mÄts tÄ«kls Uz vietas ā Ä«paÅ”a veida tÄ«kls instalÄcijÄm viss vienÄ (Å”Ädas iekÄrtas ir vajadzÄ«gas izstrÄdÄtÄjiem vai apmÄcÄ«bai) GRE ā pÄrklÄjuma tÄ«kls, izmantojot GRE tuneļus VxLAN ā pÄrklÄjuma tÄ«kls, izmantojot VxLAN tuneļus
MehÄnismu draiveri definÄt rÄ«kus, kas nodroÅ”ina tipa draiverÄ« norÄdÄ«to tehnoloÄ£iju organizÄÅ”anu - piemÄram, openvswitch, sr-iov, opendaylight, OVN u.c.
AtkarÄ«bÄ no Ŕī draivera ievieÅ”anas tiks izmantoti vai nu Neutron kontrolÄti aÄ£enti, vai arÄ« savienojumi ar ÄrÄju SDN kontrolieri, kas rÅ«pÄjas par visiem jautÄjumiem, kas saistÄ«ti ar L2 tÄ«klu organizÄÅ”anu, marÅ”rutÄÅ”anu utt.
PiemÄrs: ja mÄs izmantojam ML2 kopÄ ar OVS, tad L2 aÄ£ents tiek instalÄts katrÄ skaitļoÅ”anas mezglÄ, kas pÄrvalda OVS. TaÄu, ja lietojam, piemÄram, OVN vai OpenDayLight, tad OVS vadÄ«ba nonÄk viÅu jurisdikcijÄ - Neutron caur root spraudni dod komandas kontrolierim, un tas jau dara to, ko lika.
AtjauninÄsim informÄciju par Open vSwitch
Šobrīd viens no OpenStack galvenajiem komponentiem ir Open vSwitch.
InstalÄjot OpenStack bez papildu pÄrdevÄja SDN, piemÄram, Juniper Contrail vai Nokia Nuage, OVS ir galvenÄ mÄkoÅa tÄ«kla tÄ«kla sastÄvdaļa un kopÄ ar iptables, conntrack, namespaces ļauj organizÄt pilnvÄrtÄ«gus vairÄku nomas pÄrklÄjumu tÄ«klus. Protams, Å”o komponentu var aizstÄt, piemÄram, izmantojot treÅ”Äs puses patentÄtus (pÄrdevÄja) SDN risinÄjumus.
OVS ir atvÄrtÄ pirmkoda programmatÅ«ras slÄdzis, kas paredzÄts lietoÅ”anai virtualizÄtÄ vidÄ kÄ virtuÄlÄ trafika pÄrsÅ«tÄ«tÄjs.
Å obrÄ«d OVS ir ļoti pieklÄjÄ«ga funkcionalitÄte, kas ietver tÄdas tehnoloÄ£ijas kÄ QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK u.c.
PiezÄ«me: OVS sÄkotnÄji netika iecerÄts kÄ mÄ«ksts slÄdzis ļoti noslogotÄm telekomunikÄciju funkcijÄm, un tas bija vairÄk paredzÄts IT funkcijÄm, kurÄm ir mazÄks joslas platums, piemÄram, WEB serverim vai pasta serverim. TaÄu OVS tiek tÄlÄk attÄ«stÄ«ts un paÅ”reizÄjÄs OVS implementÄcijas ir krietni uzlabojuÅ”as tÄ veiktspÄju un iespÄjas, kas ļauj to izmantot telekomunikÄciju operatoriem ar ļoti noslogotÄm funkcijÄm, piemÄram, ir OVS implementÄcija ar atbalstu DPDK paÄtrinÄjumam.
Ir trÄ«s svarÄ«gi OVS komponenti, kas jums jÄzina:
Kodola modulis ā komponents, kas atrodas kodola telpÄ, kas apstrÄdÄ trafiku, pamatojoties uz noteikumiem, kas saÅemti no vadÄ«bas elementa;
vSlÄdzis dÄmons (ovs-vswitchd) ir lietotÄja telpÄ palaists process, kas ir atbildÄ«gs par kodola moduļa programmÄÅ”anu - tas ir, tas tieÅ”i atspoguļo slÄdža darbÄ«bas loÄ£iku
Datu bÄzes serveris - lokÄlÄ datu bÄze, kas atrodas katrÄ resursdatorÄ, kurÄ darbojas OVS, un kurÄ tiek saglabÄta konfigurÄcija. SDN kontrolleri var sazinÄties, izmantojot Å”o moduli, izmantojot OVSDB protokolu.
Tam visam ir pievienots diagnostikas un pÄrvaldÄ«bas utilÄ«tu komplekts, piemÄram, ovs-vsctl, ovs-appctl, ovs-ofctl utt.
PaÅ”laik Openstack plaÅ”i izmanto telekomunikÄciju operatori, lai uz to migrÄtu tÄ«kla funkcijas, piemÄram, EPC, SBC, HLR u.c. Dažas funkcijas var darboties bez problÄmÄm ar tÄdu OVS, kÄds tas ir, bet, piemÄram, EPC apstrÄdÄ abonentu trafiku - tad tas iet cauri. milzÄ«gs satiksmes apjoms (tagad trafika apjoms sasniedz vairÄkus simtus gigabitu sekundÄ). Protams, Å”Ädas trafika vadÄ«Å”ana caur kodola vietu (jo ekspeditors pÄc noklusÄjuma atrodas tur) nav labÄkÄ ideja. TÄpÄc OVS bieži tiek pilnÄ«bÄ izvietots lietotÄju telpÄ, izmantojot DPDK paÄtrinÄjuma tehnoloÄ£iju, lai pÄrsÅ«tÄ«tu trafiku no NIC uz lietotÄja vietu, apejot kodolu.
PiezÄ«me: mÄkonim, kas izvietots telekomunikÄciju funkcijÄm, ir iespÄjams izvadÄ«t trafiku no skaitļoÅ”anas mezgla, apejot OVS, tieÅ”i uz komutÄcijas aprÄ«kojumu. Å im nolÅ«kam tiek izmantoti SR-IOV un Passthrough mehÄnismi.
KÄ tas darbojas reÄlÄ izkÄrtojumÄ?
Nu, tagad pÄriesim uz praktisko daļu un redzÄsim, kÄ tas viss darbojas praksÄ.
Vispirms izvietosim vienkÄrÅ”u Openstack instalÄciju. TÄ kÄ man nav pie rokas serveru komplekta eksperimentiem, mÄs saliksim prototipu vienÄ fiziskajÄ serverÄ« no virtuÄlajÄm maŔīnÄm. JÄ, dabiski, ka Å”Äds risinÄjums nav piemÄrots komerciÄliem nolÅ«kiem, taÄu, lai redzÄtu piemÄru, kÄ Openstack darbojas tÄ«kls, ar Å”Ädu instalÄciju acÄ«m pietiek. TurklÄt Å”Äda instalÄcija ir vÄl interesantÄka apmÄcÄ«bas nolÅ«kos - jo jÅ«s varat noÄ·ert satiksmi utt.
TÄ kÄ mums ir jÄredz tikai pamata daļa, mÄs nevaram izmantot vairÄkus tÄ«klus, bet visu pacelt, izmantojot tikai divus tÄ«klus, un otrs tÄ«kls Å”ajÄ izkÄrtojumÄ tiks izmantots tikai piekļuvei undercloud un DNS serverim. PagaidÄm mÄs nepieskaramies ÄrÄjiem tÄ«kliem - Ŕī ir atseviŔķa liela raksta tÄma.
TÄtad, sÄksim secÄ«bÄ. PirmkÄrt, neliela teorija. MÄs instalÄsim Openstack, izmantojot TripleO (Openstack uz Openstack). TripleO bÅ«tÄ«ba ir tÄda, ka mÄs instalÄjam Openstack all-in-one (tas ir, vienÄ mezglÄ), ko sauc par undercloud, un pÄc tam izmantojam izvietotÄ Openstack iespÄjas, lai instalÄtu darbÄ«bai paredzÄto Openstack, ko sauc par overcloud. Undercloud izmantos tai piemÄ«toÅ”o spÄju pÄrvaldÄ«t fiziskos serverus (bezmetÄla) ā Ironic projektu ā, lai nodroÅ”inÄtu hipervizorus, kas pildÄ«s skaitļoÅ”anas, vadÄ«bas un uzglabÄÅ”anas mezglu funkcijas. Tas nozÄ«mÄ, ka mÄs neizmantojam nekÄdus treÅ”o puÅ”u rÄ«kus, lai izvietotu Openstack ā mÄs izvietojam Openstack, izmantojot Openstack. InstalÄÅ”anas gaitÄ tas kļūs daudz skaidrÄks, tÄpÄc mÄs neapstÄsimies un virzÄ«simies uz priekÅ”u.
PiezÄ«me. Å ajÄ rakstÄ vienkÄrŔības labad es neizmantoju tÄ«kla izolÄciju iekÅ”Äjiem Openstack tÄ«kliem, bet viss tiek izvietots, izmantojot tikai vienu tÄ«klu. TaÄu tÄ«kla izolÄcijas esamÄ«ba vai neesamÄ«ba neietekmÄ risinÄjuma pamata funkcionalitÄti ā viss darbosies tieÅ”i tÄpat, kÄ lietojot izolÄciju, taÄu trafika plÅ«dÄ«s tajÄ paÅ”Ä tÄ«klÄ. KomerciÄlai instalÄcijai, protams, ir jÄizmanto izolÄcija, izmantojot dažÄdus vlanus un saskarnes. PiemÄram, ceph krÄtuves pÄrvaldÄ«bas trafiks un pati datu trafika (maŔīnas piekļuve diskiem utt.), kad tÄ ir izolÄta, izmanto dažÄdus apakÅ”tÄ«klus (Storage management un Storage), un tas ļauj risinÄjumu padarÄ«t izturÄ«gÄku pret kļūmÄm, piemÄram, sadalot Å”o trafiku. , izmantojot dažÄdus portus vai izmantojot dažÄdus QoS profilus dažÄdai trafikai, lai datu trafiks neizspiestu signalizÄcijas trafiku. MÅ«su gadÄ«jumÄ tie darbosies vienÄ tÄ«klÄ, un patiesÄ«bÄ tas mÅ«s nekÄdi neierobežo.
PiezÄ«me. TÄ kÄ virtuÄlÄs maŔīnas darbinÄsim virtuÄlajÄ vidÄ, kuras pamatÄ ir virtuÄlÄs maŔīnas, vispirms ir jÄiespÄjo ligzdotÄ virtualizÄcija.
Varat pÄrbaudÄ«t, vai ligzdotÄ virtualizÄcija ir iespÄjota vai nav, Å”Ädi:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]#
Ja redzat burtu N, mÄs iespÄjojam atbalstu ligzdotai virtualizÄcijai saskaÅÄ ar jebkuru ceļvedi, ko atrodat tÄ«klÄ, piemÄram, Å”Äds .
Mums ir jÄsamontÄ Å”Äda Ä·Äde no virtuÄlajÄm maŔīnÄm:
ManÄ gadÄ«jumÄ, lai savienotu virtuÄlÄs maŔīnas, kas ir daļa no turpmÄkÄs instalÄcijas (un man ir 7 no tÄm, bet jÅ«s varat iztikt ar 4, ja jums nav daudz resursu), es izmantoju OpenvSwitch. Es izveidoju vienu ovs tiltu un pievienoju tam virtuÄlÄs maŔīnas, izmantojot portu grupas. Lai to izdarÄ«tu, es izveidoju Å”Ädu xml failu:
Å eit ir deklarÄtas trÄ«s portu grupas - divas piekļuves un viena maÄ£istrÄle (pÄdÄjÄ bija nepiecieÅ”ama DNS serverim, bet jÅ«s varat iztikt bez tÄ vai instalÄt to resursdatorÄ - kÄ jums ÄrtÄk). PÄc tam, izmantojot Å”o veidni, mÄs deklarÄjam savu, izmantojot virsh net-define:
PiezÄ«me: Å”ajÄ gadÄ«jumÄ adrese portÄ ovs-br1 nebÅ«s pieejama, jo tai nav vlan taga. Lai to novÄrstu, jums ir jÄizdod komanda sudo ovs-vsctl set port ovs-br1 tag=100. TomÄr pÄc pÄrstartÄÅ”anas Å”is tags pazudÄ«s (ja kÄds zina, kÄ likt tam palikt vietÄ, bÅ«Å”u ļoti pateicÄ«gs). Bet tas nav tik svarÄ«gi, jo Ŕī adrese mums bÅ«s nepiecieÅ”ama tikai instalÄÅ”anas laikÄ un nebÅ«s vajadzÄ«ga, kad Openstack bÅ«s pilnÄ«bÄ izvietots.
InstalÄÅ”anas laikÄ jÅ«s iestatÄt visus nepiecieÅ”amos parametrus, piemÄram, maŔīnas nosaukumu, paroles, lietotÄjus, ntp serverus utt., jÅ«s varat uzreiz konfigurÄt portus, bet man personÄ«gi pÄc instalÄÅ”anas ir vieglÄk pieteikties maŔīnÄ caur konsoli un labojiet nepiecieÅ”amos failus. Ja jums jau ir gatavs attÄls, varat to izmantot vai darÄ«t to, ko es darÄ«ju - lejupielÄdÄjiet minimÄlo Centos 7 attÄlu un izmantojiet to VM instalÄÅ”anai.
MÄs izveidojam steka lietotÄju, iestatÄm paroli, pievienojam to sudoer un dodam viÅam iespÄju izpildÄ«t root komandas, izmantojot sudo, neievadot paroli:
PiezÄ«me: ja neplÄnojat instalÄt ceph, jums nav jÄievada ar ceph saistÄ«tas komandas. Es izmantoju Queens izlaidumu, bet jÅ«s varat izmantot jebkuru citu, kas jums patÄ«k.
PÄc tam nokopÄjiet mÄkoÅdatoÅ”anas konfigurÄcijas failu lietotÄja mÄjas direktoriju kaudzÄ:
network_gateway ā tÄ pati vietÄjÄ adrese, kas darbosies kÄ vÄrteja piekļuvei Ärpasaulei mÄkoÅu mezglu uzstÄdÄ«Å”anas laikÄ, sakrÄ«t arÄ« ar vietÄjo IP
undercloud_public_host ā ÄrÄjÄ API adrese, tiek pieŔķirta jebkura brÄ«va adrese no nodroÅ”inÄÅ”anas tÄ«kla
undercloud_admin_host iekÅ”ÄjÄ API adrese, tiek pieŔķirta jebkura bezmaksas adrese no nodroÅ”inÄÅ”anas tÄ«kla
undercloud_nameservers ā DNS serveris
Gene_service_certificate - Ŕī rinda ir ļoti svarÄ«ga paÅ”reizÄjÄ piemÄrÄ, jo, ja jÅ«s to neiestatÄ«sit uz false, instalÄÅ”anas laikÄ tiks parÄdÄ«ta kļūda, problÄma ir aprakstÄ«ta Red Hat kļūdu izsekotÄjÄ
vietÄjais_interfeiss saskarne tÄ«kla nodroÅ”inÄÅ”anÄ. Å is interfeiss tiks pÄrkonfigurÄts undercloud izvietoÅ”anas laikÄ, tÄpÄc jums ir jÄbÅ«t diviem interfeisiem undercloud ā vienai, lai piekļūtu tai, otrai ā nodroÅ”inÄÅ”anai.
local_mtu ā MTU. TÄ kÄ mums ir testÄÅ”anas laboratorija un man ir MTU 1500 uz OVS slÄdža portiem, ir jÄiestata uz 1450, lai VxLAN iekapsulÄtÄs paketes varÄtu iziet cauri.
tÄ«kls_cidr ā nodroÅ”inÄÅ”anas tÄ«kls
maskarÄde ā izmantojot NAT, lai piekļūtu ÄrÄjam tÄ«klam
masquerade_network - tīkls, kas tiks savienots ar NAT
dhcp_start ā adreÅ”u kopas sÄkuma adrese, no kuras adreses tiks pieŔķirtas mezgliem mÄkoÅa izvietoÅ”anas laikÄ
dhcp_end ā adreÅ”u kopas galÄ«gÄ adrese, no kuras adreses tiks pieŔķirtas mezgliem mÄkoÅa izvietoÅ”anas laikÄ
inspekcijas_izlaide ā adreÅ”u kopums, kas nepiecieÅ”ams paÅ”pÄrbaudei (nedrÄ«kst pÄrklÄties ar iepriekÅ” minÄto kopu)
scheduler_max_attempts ā maksimÄlais mÄkoÅu uzstÄdÄ«Å”anas mÄÄ£inÄjumu skaits (jÄbÅ«t lielÄkam vai vienÄdam ar mezglu skaitu)
Kad fails ir aprakstīts, varat dot komandu izvietot undercloud:
openstack undercloud install
ProcedÅ«ra ilgst no 10 lÄ«dz 30 minÅ«tÄm atkarÄ«bÄ no jÅ«su gludekļa. Galu galÄ jums vajadzÄtu redzÄt Å”Ädu izvadi:
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.
#############################################################################
Å Ä« izvade norÄda, ka esat veiksmÄ«gi instalÄjis undercloud, un tagad varat pÄrbaudÄ«t undercloud statusu un turpinÄt instalÄt overcloud.
Ja paskatÄs uz ifconfig izvadi, jÅ«s redzÄsit, ka ir parÄdÄ«jies jauns tilta interfeiss
Å obrÄ«d mums ir tikai mÄkonis, un mums nav pietiekami daudz mezglu, no kuriem tiks montÄti mÄkoÅi. TÄpÄc, pirmkÄrt, izvietosim mums nepiecieÅ”amÄs virtuÄlÄs maŔīnas. IzvietoÅ”anas laikÄ Undercloud pats instalÄs OS un nepiecieÅ”amo programmatÅ«ru overcloud maŔīnÄ - tas ir, mums nav pilnÄ«bÄ jÄizvieto maŔīna, bet tikai jÄizveido tai disks (vai diski) un jÄnosaka tÄ parametri - tas ir. , patiesÄ«bÄ mÄs iegÅ«stam tukÅ”u serveri, kurÄ nav instalÄta OS.
Dosimies uz mapi ar mÅ«su virtuÄlo maŔīnu diskiem un izveidosim vajadzÄ«gÄ izmÄra diskus:
TÄ kÄ mÄs darbojamies kÄ root, mums ir jÄmaina Å”o disku Ä«paÅ”nieks, lai nerastos problÄmas ar tiesÄ«bÄm:
[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]#
PiezÄ«me: ja neplÄnojat instalÄt ceph, lai to izpÄtÄ«tu, tad komandas neveido vismaz 3 mezglus ar vismaz diviem diskiem, bet veidnÄ norÄda, ka tiks izmantoti virtuÄlie diski vda, vdb utt.
Lieliski, tagad mums ir jÄdefinÄ visas Ŕīs maŔīnas:
BeigÄs ir komanda -print-xml > /tmp/storage-1.xml, kas izveido xml failu ar katras maŔīnas aprakstu mapÄ /tmp/; ja jÅ«s to nepievienosit, jÅ«s vairs nebÅ«siet. spÄj identificÄt virtuÄlÄs maŔīnas.
Tagad mums ir jÄdefinÄ visas Ŕīs maŔīnas 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 ~]#
Tagad neliela nianse ā tripleO izmanto IPMI, lai pÄrvaldÄ«tu serverus instalÄÅ”anas un paÅ”pÄrbaudes laikÄ.
Introspekcija ir aparatÅ«ras pÄrbaudes process, lai iegÅ«tu tÄs parametrus, kas nepiecieÅ”ami tÄlÄkai mezglu nodroÅ”inÄÅ”anai. Introspekcija tiek veikta, izmantojot ironiju, pakalpojumu, kas paredzÄts darbam ar tukÅ”a metÄla serveriem.
Bet Å”eit ir problÄma - lai gan aparatÅ«ras IPMI serveriem ir atseviŔķs ports (vai koplietots ports, bet tas nav svarÄ«gi), virtuÄlajÄm maŔīnÄm Å”Ädu portu nav. Å eit mums palÄ«dz kruÄ·is ar nosaukumu vbmc - utilÄ«ta, kas ļauj emulÄt IPMI portu. Å ai niansei ir vÄrts pievÄrst uzmanÄ«bu Ä«paÅ”i tiem, kas vÄlas izveidot Å”Ädu laboratoriju uz ESXI hipervizora - godÄ«gi sakot, es nezinu, vai tam ir vbmc analogs, tÄpÄc ir vÄrts padomÄt par Å”o problÄmu pirms visa izvietoÅ”anas. .
InstalÄjiet vbmc:
yum install yum install python2-virtualbmc
Ja jÅ«su operÄtÄjsistÄma nevar atrast pakotni, pievienojiet repozitoriju:
Es domÄju, ka komandu sintakse ir skaidra bez paskaidrojumiem. TomÄr pagaidÄm visas mÅ«su sesijas ir DOWN statusÄ. Lai tie pÄrietu uz UP statusu, tie ir jÄiespÄjo:
[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 ~]#
Un pÄdÄjais pieskÄriens - jums ir jÄlabo ugunsmÅ«ra noteikumi (vai pilnÄ«bÄ jÄatspÄjo):
Tagad pÄriesim uz mÄkoÅiem un pÄrbaudÄ«sim, vai viss darbojas. ResursmaŔīnas adrese ir 192.168.255.200, mÄkoÅdatnÄ mÄs pievienojÄm nepiecieÅ”amo ipmitool pakotni, gatavojoties izvietoÅ”anai:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 running
KÄ redzat, mÄs esam veiksmÄ«gi palaiduÅ”i vadÄ«bas mezglu, izmantojot vbmc. Tagad izslÄgsim to un turpinÄsim:
[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Äkamais solis ir to mezglu introspekcija, uz kuriem tiks uzstÄdÄ«ts mÄkonis. Lai to izdarÄ«tu, mums ir jÄsagatavo json fails ar mÅ«su mezglu aprakstu. LÅ«dzu, Åemiet vÄrÄ, ka atŔķirÄ«bÄ no instalÄÅ”anas uz tukÅ”iem serveriem fails norÄda portu, kurÄ darbojas vbmc katrai maŔīnai.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27
PiezÄ«me: vadÄ«bas mezglam ir divas saskarnes, taÄu Å”ajÄ gadÄ«jumÄ tas nav svarÄ«gi, Å”ajÄ instalÄcijÄ mums pietiks ar vienu.
Tagad mÄs sagatavojam json failu. Mums jÄnorÄda porta magoÅu adrese, caur kuru tiks veikta nodroÅ”inÄÅ”ana, mezglu parametri, jÄpieŔķir tiem nosaukumi un jÄnorÄda, kÄ nokļūt ipmi:
Tagad mums ir jÄsagatavo attÄli ironijai. Lai to izdarÄ«tu, lejupielÄdÄjiet tos, izmantojot wget, un instalÄjiet:
(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 ~]$
AttÄlu augÅ”upielÄde mÄkoÅos:
(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 ~]$
PÄrbauda, āāvai visi attÄli ir ielÄdÄti
(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 ~]$
(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 ~]$
KÄ redzat no izvades, viss tika pabeigts bez kļūdÄm. PÄrbaudÄ«sim, vai visi mezgli ir pieejamajÄ stÄvoklÄ«:
(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 ~]$
Ja mezgli ir citÄ stÄvoklÄ«, parasti pÄrvaldÄmi, tad kaut kas nogÄja greizi, un jums ir jÄaplÅ«ko žurnÄls un jÄnoskaidro, kÄpÄc tas notika. Å emiet vÄrÄ, ka Å”ajÄ scenÄrijÄ mÄs izmantojam virtualizÄciju un var bÅ«t kļūdas, kas saistÄ«tas ar virtuÄlo maŔīnu vai vbmc izmantoÅ”anu.
TÄlÄk mums jÄnorÄda, kurÅ” mezgls kÄdu funkciju pildÄ«s, tas ir, jÄnorÄda profils, ar kuru mezgls izvietos:
ReÄlÄ instalÄcijÄ, protams, tiks izmantotas pielÄgotas veidnes, mÅ«su gadÄ«jumÄ tas ievÄrojami sarežģīs procesu, jo katrs veidnes labojums bÅ«s jÄpaskaidro. KÄ jau tika rakstÄ«ts iepriekÅ”, pat ar vienkÄrÅ”u instalÄciju mums pietiks, lai redzÄtu, kÄ tÄ darbojas.
PiezÄ«me: Å”ajÄ gadÄ«jumÄ ir nepiecieÅ”ams mainÄ«gais --libvirt tipa qemu, jo mÄs izmantosim ligzdotu virtualizÄciju. PretÄjÄ gadÄ«jumÄ jÅ«s nevarÄsit palaist virtuÄlÄs maŔīnas.
Tagad jums ir aptuveni stunda vai varbÅ«t vairÄk (atkarÄ«bÄ no aparatÅ«ras iespÄjÄm), un jÅ«s varat tikai cerÄt, ka pÄc Ŕī laika jÅ«s redzÄsit Å”Ädu ziÅojumu:
Tagad jums ir gandrÄ«z pilnvÄrtÄ«ga openstack versija, kurÄ varat mÄcÄ«ties, eksperimentÄt utt.
PÄrbaudÄ«sim, vai viss darbojas pareizi. LietotÄja mÄjas direktoriju stekÄ ir divi faili ā viens stackrc (undercloud pÄrvaldÄ«bai) un otrs overcloudrc (overcloud pÄrvaldÄ«Å”anai). Å ie faili ir jÄnorÄda kÄ avots, jo tie satur autentifikÄcijai nepiecieÅ”amo informÄciju.
(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 ~]$
Manai instalÄÅ”anai joprojÄm ir nepiecieÅ”ams neliels pieskÄriens - marÅ”ruta pievienoÅ”ana kontrollerÄ«, jo iekÄrta, ar kuru es strÄdÄju, atrodas citÄ tÄ«klÄ. Lai to izdarÄ«tu, siltuma administratora kontÄ dodieties uz kontroli-1 un reÄ£istrÄjiet marÅ”rutu
(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.254
Nu, tagad jÅ«s varat doties uz horizontu. Visa informÄcija - adreses, pieteikÅ”anÄs vÄrds un parole - atrodas failÄ /home/stack/overcloudrc. GalÄ«gÄ diagramma izskatÄs Å”Ädi:
Starp citu, mÅ«su instalÄcijÄ maŔīnu adreses tika izsniegtas, izmantojot DHCP, un, kÄ redzat, tÄs tiek izsniegtas ānejauÅ”iā. VeidnÄ varat stingri noteikt, kura adrese ir jÄpievieno kurai maŔīnai izvietoÅ”anas laikÄ, ja jums tÄ ir nepiecieÅ”ama.
KÄ notiek trafika plÅ«sma starp virtuÄlajÄm maŔīnÄm?
Å ajÄ rakstÄ mÄs apskatÄ«sim trÄ«s iespÄjas garÄmbraucoÅ”ai satiksmei
Divas maŔīnas vienÄ hipervizorÄ vienÄ L2 tÄ«klÄ
Divas maŔīnas dažÄdos hipervizoros vienÄ L2 tÄ«klÄ
Divas maŔīnas dažÄdos tÄ«klos (starptÄ«klu sakÅoÅ”ana)
GadÄ«jumus ar piekļuvi ÄrÄjai pasaulei, izmantojot ÄrÄjo tÄ«klu, izmantojot peldoÅ”Äs adreses, kÄ arÄ« izkliedÄtu marÅ”rutÄÅ”anu, mÄs izskatÄ«sim nÄkamreiz, pagaidÄm koncentrÄsimies uz iekÅ”Äjo trafiku.
Bet pirms mÄs aplÅ«kojam trafika plÅ«smu, apskatÄ«sim, kas mums paÅ”laik ir vadÄ«bas mezglÄ (kas arÄ« ir tÄ«kla mezgls) un skaitļoÅ”anas mezglÄ. SÄksim ar skaitļoÅ”anas mezglu.
Å obrÄ«d mezglÄ ir trÄ«s ovs tilti - br-int, br-tun, br-ex. Starp tiem, kÄ mÄs redzam, ir saskarÅu kopums. Lai atvieglotu izpratni, uzzÄ«mÄsim visas Ŕīs saskarnes diagrammÄ un redzÄsim, kas notiek.
AplÅ«kojot adreses, uz kurÄm tiek pacelti VxLAN tuneļi, redzams, ka viens tunelis ir paaugstinÄts uz compute-1 (192.168.255.26), otrs tunelis izskatÄs uz control-1 (192.168.255.15). Bet pats interesantÄkais ir tas, ka br-ex nav fizisku saskarÅu, un, ja paskatÄs, kÄdas plÅ«smas ir konfigurÄtas, var redzÄt, ka Å”is tilts Å”obrÄ«d var tikai atmest satiksmi.
SaskaÅÄ ar pirmo noteikumu viss, kas nÄca no phy-br-ex porta, ir jÄizmet.
PatiesÄ«bÄ Å”obrÄ«d nav kur citur satiksmei iekļūt Å”ajÄ tiltÄ, izÅemot no Ŕīs saskarnes (saskarne ar br-int), un, spriežot pÄc kritumiem, BUM satiksme jau ir ieplÅ«dusi tiltÄ.
Tas nozÄ«mÄ, ka satiksme var atstÄt Å”o mezglu tikai caur VxLAN tuneli un neko citu. TaÄu, ja ieslÄdzat DVR, situÄcija mainÄ«sies, bet ar to tiksim galÄ citreiz. Izmantojot tÄ«kla izolÄciju, piemÄram, izmantojot vlans, jums bÅ«s nevis viens L3 interfeiss vlan 0, bet gan vairÄkas saskarnes. TomÄr VxLAN trafiks iziet no mezgla tÄdÄ paÅ”Ä veidÄ, bet arÄ« iekapsulÄts kaut kÄdÄ Ä«paÅ”Ä VLAN.
MÄs esam sakÄrtojuÅ”i aprÄÄ·ina mezglu, pÄriesim uz vadÄ«bas mezglu.
PatiesÄ«bÄ mÄs varam teikt, ka viss ir vienÄds, bet IP adrese vairs nav fiziskajÄ saskarnÄ, bet gan virtuÄlajÄ tiltÄ. Tas tiek darÄ«ts, jo Ŕī osta ir osta, caur kuru satiksme izies uz Ärpasauli.
Å is ports ir piesaistÄ«ts br-ex tiltam un, tÄ kÄ uz tÄ nav vlan tagu, Å”is ports ir maÄ£istrÄlais ports, kurÄ ir atļauti visi vlani, tagad satiksme iet ÄrpusÄ bez atzÄ«mes, kÄ to norÄda vlan-id 0 izvade iepriekÅ”.
Viss pÄrÄjais Å”obrÄ«d ir lÄ«dzÄ«gs skaitļoÅ”anas mezglam - tie paÅ”i tilti, tie paÅ”i tuneļi, kas iet uz diviem skaitļoÅ”anas mezgliem.
Å ajÄ rakstÄ mÄs neapskatÄ«sim krÄtuves mezglus, taÄu, lai saprastu, jÄsaka, ka Å”o mezglu tÄ«kla daļa ir banÄla lÄ«dz apkaunojuma vietai. MÅ«su gadÄ«jumÄ ir tikai viens fiziskais ports (eth0) ar tam pieŔķirtu IP adresi, un tas arÄ« viss. Nav VxLAN tuneļu, tuneļu tiltu u.c. - ovs vispÄr nav, jo nav jÄgas. Izmantojot tÄ«kla izolÄciju, Å”im mezglam bÅ«s divas saskarnes (fiziskie porti, bodny vai tikai divi VLAN ā tas nav svarÄ«gi ā tas ir atkarÄ«gs no tÄ, ko vÄlaties) - viens pÄrvaldÄ«bai, otrs trafikam (rakstÄ«Å”anai VM diskÄ , lasÄ«Å”ana no diska utt.)
MÄs noskaidrojÄm, kas mums ir uz mezgliem, ja nebija pakalpojumu. Tagad palaidÄ«sim 4 virtuÄlÄs maŔīnas un redzÄsim, kÄ mainÄs iepriekÅ” aprakstÄ«tÄ shÄma - mums vajadzÄtu bÅ«t portiem, virtuÄlajiem marÅ”rutÄtÄjiem utt.
LÄ«dz Å”im mÅ«su tÄ«kls izskatÄs Å”Ädi:
Mums ir divas virtuÄlÄs maŔīnas katrÄ datora mezglÄ. Izmantojot compute-0 kÄ piemÄru, redzÄsim, kÄ viss ir iekļauts.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$
IekÄrtai ir tikai viens virtuÄlais interfeiss - 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 ~]$
Å is interfeiss izskatÄs Linux tiltÄ:
[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 ~]$
KÄ redzat no izejas, tiltÄ ir tikai divas saskarnes - tap95d96a75-a0 un qvb95d96a75-a0.
Å eit ir vÄrts nedaudz pakavÄties pie OpenStack virtuÄlÄ tÄ«kla ierÄ«Äu veidiem:
vtap ā virtuÄlais interfeiss, kas pievienots instancei (VM)
qbr - Linux tilts
qvb un qvo - vEth pÄris, kas savienots ar Linux tiltu un Open vSwitch tiltu
br-int, br-tun, br-vlan ā atveriet vSwitch tiltus
patch-, int-br-, phy-br- ā atvÄrt vSwitch ielÄpu saskarnes, kas savieno tiltus
qg, qr, ha, fg, sg ā atver vSwitch portus, ko izmanto virtuÄlÄs ierÄ«ces, lai izveidotu savienojumu ar OVS
KÄ jÅ«s saprotat, ja mums tiltÄ ir qvb95d96a75-a0 ports, kas ir vEth pÄris, tad kaut kur ir tÄ lÄ«dzinieks, kuru loÄ£iski vajadzÄtu saukt par qvo95d96a75-a0. ApskatÄ«sim, kÄdi porti ir uz OVS.
KÄ redzam, osta atrodas br-int. Br-int darbojas kÄ slÄdzis, kas pÄrtrauc virtuÄlÄs maŔīnas portus. Papildus qvo95d96a75-a0 izvadÄ ir redzams ports qvo5bd37136-47. Å is ir ports uz otro virtuÄlo maŔīnu. RezultÄtÄ mÅ«su diagramma tagad izskatÄs Å”Ädi:
JautÄjums, kuram uzreiz vajadzÄtu interesÄt vÄrÄ«go lasÄ«tÄju - kÄds ir linux tilts starp virtuÄlÄs maŔīnas portu un OVS portu? Fakts ir tÄds, ka maŔīnas aizsardzÄ«bai tiek izmantotas droŔības grupas, kas ir nekas vairÄk kÄ iptables. OVS nedarbojas ar iptables, tÄpÄc tika izgudrots Å”is ākruÄ·isā. TomÄr tas kļūst novecojis - tas tiek aizstÄts ar conntrack jaunajos izlaidumos.
Tas ir, galu galÄ shÄma izskatÄs Å”Ädi:
Divas maŔīnas vienÄ hipervizorÄ vienÄ L2 tÄ«klÄ
TÄ kÄ Å”Ä«s divas virtuÄlÄs maŔīnas atrodas tajÄ paÅ”Ä L2 tÄ«klÄ un tajÄ paÅ”Ä hipervizorÄ, satiksme starp tÄm loÄ£iski plÅ«st lokÄli caur br-int, jo abas maŔīnas bÅ«s vienÄ 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 ~]$
Divas maŔīnas dažÄdos hipervizoros vienÄ L2 tÄ«klÄ
Tagad redzÄsim, kÄ trafiks notiks starp divÄm maŔīnÄm tajÄ paÅ”Ä L2 tÄ«klÄ, bet kas atrodas dažÄdos hipervizoros. Ja godÄ«gi, nekas Ä«paÅ”i nemainÄ«sies, tikai satiksme starp hipervizoriem ies caur vxlan tuneli. ApskatÄ«sim piemÄru.
To virtuÄlo maŔīnu adreses, starp kurÄm mÄs vÄrosim trafiku:
[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 ~]$
Mac ir br-int pÄrsÅ«tÄ«Å”anas tabulÄ compute-1, un, kÄ redzams no iepriekÅ” esoÅ”Äs izvades, tas ir redzams caur portu 2, kas ir ports virzienÄ uz br-tun:
Tas ir, saÅemtÄ pakete lidos uz portu 3, aiz kura jau atrodas virtuÄlÄs maŔīnas instance-00000003.
Openstack izvietoÅ”ana mÄcÄ«bÄm virtuÄlajÄ infrastruktÅ«rÄ ir tÄda, ka mÄs varam viegli uztvert trafiku starp hipervizoriem un redzÄt, kas ar to notiek. Tas ir tas, ko mÄs tagad darÄ«sim, palaidÄ«sim tcpdump vnet portÄ virzienÄ uz 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*******************
PirmajÄ rindÄ redzams, ka Patek no adreses 10.0.1.85 dodas uz adresi 10.0.1.88 (ICMP trafiks), un tas ir iesaiÅots VxLAN paketÄ ar vni 22, un pakete pÄriet no resursdatora 192.168.255.19 (compute-0) uz resursdatoru 192.168.255.26. .1 ( aprÄÄ·ina-XNUMX). Varam pÄrbaudÄ«t, vai VNÄŖ atbilst ovs norÄdÄ«tajam.
AtgriezÄ«simies pie Ŕīs rindas action=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],izeja:2. 0x16 ir vni heksadecimÄlajÄ skaitļu sistÄmÄ. PÄrveidosim Å”o skaitli 16. sistÄmÄ:
16 = 6*16^0+1*16^1 = 6+16 = 22
Tas ir, vni atbilst realitÄtei.
OtrajÄ rindÄ redzama atgrieÅ”anÄs satiksme, nu, nav jÄgas to skaidrot, tur viss skaidrs.
Divas maŔīnas dažÄdos tÄ«klos (starptÄ«klu marÅ”rutÄÅ”ana)
PÄdÄjais gadÄ«jums Å”odien ir marÅ”rutÄÅ”ana starp tÄ«kliem viena projekta ietvaros, izmantojot virtuÄlo marÅ”rutÄtÄju. MÄs apsveram gadÄ«jumu bez DVR (mÄs to aplÅ«kosim citÄ rakstÄ), tÄpÄc marÅ”rutÄÅ”ana notiek tÄ«kla mezglÄ. MÅ«su gadÄ«jumÄ tÄ«kla mezgls nav ievietots atseviÅ”Ä·Ä entÄ«tijÄ un atrodas vadÄ«bas mezglÄ.
Vispirms apskatÄ«sim, vai marÅ”rutÄÅ”ana darbojas:
$ 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
TÄ kÄ Å”ajÄ gadÄ«jumÄ paketei ir jÄiet uz vÄrteju un jÄnovirza tur, mums ir jÄnoskaidro vÄrtejas magones adrese, kuras gadÄ«jumÄ mÄs skatÄmies uz ARP tabulu:
$ 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 eth0
Tagad paskatÄ«simies, kur jÄnosÅ«ta satiksme ar galamÄrÄ·i (10.0.1.254) fa:16:3e:c4:64:70:
Satiksme ir sasniegusi vadÄ«bas mezglu, tÄpÄc mums jÄdodas uz to un jÄskatÄs, kÄ notiks marÅ”rutÄÅ”ana.
KÄ atceraties, vadÄ«bas mezgls iekÅ”Ä izskatÄ«jÄs tieÅ”i tÄpat kÄ skaitļoÅ”anas mezgls - tie paÅ”i trÄ«s tilti, tikai br-ex bija fiziska pieslÄgvieta, caur kuru mezgls varÄja nosÅ«tÄ«t trafiku ÄrpusÄ. InstanÄu izveide mainÄ«ja konfigurÄciju skaitļoÅ”anas mezglos - mezgliem tika pievienots linux tilts, iptables un saskarnes. TÄ«klu un virtuÄlÄ marÅ”rutÄtÄja izveide arÄ« atstÄja savas pÄdas vadÄ«bas mezgla konfigurÄcijÄ.
TÄtad ir skaidrs, ka vÄrtejas MAC adresei jÄbÅ«t vadÄ«bas mezgla br-int pÄrsÅ«tÄ«Å”anas tabulÄ. PÄrbaudÄ«sim, vai tas tur ir un kur tas meklÄ:
Mac ir redzams no porta qr-0c52b15f-8f. Ja mÄs atgriežamies pie Openstack virtuÄlo portu saraksta, Å”Äda veida porti tiek izmantoti dažÄdu virtuÄlo ierÄ«Äu savienoÅ”anai ar OVS. PrecÄ«zÄk sakot, qr ir ports uz virtuÄlo marÅ”rutÄtÄju, kas tiek attÄlots kÄ nosaukumvieta.
ApskatÄ«sim, kÄdas nosaukumvietas atrodas serverÄ«:
Pat trÄ«s eksemplÄri. Bet, spriežot pÄc nosaukumiem, jÅ«s varat uzminÄt katra no tiem mÄrÄ·i. MÄs vÄlÄk atgriezÄ«simies pie gadÄ«jumiem ar ID 0 un 1, tagad mÅ«s interesÄ nosaukumvieta 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 ~]$
Å ajÄ nosaukumvietÄ ir divas iekÅ”ÄjÄs, kuras mÄs izveidojÄm iepriekÅ”. Abi virtuÄlie porti ir pievienoti br-int. PÄrbaudÄ«sim porta qr-0c52b15f-8f mac adresi, jo trafiks, spriežot pÄc galamÄrÄ·a mac adreses, nonÄca Å”ajÄ saskarnÄ.
Tas ir, Å”ajÄ gadÄ«jumÄ viss darbojas saskaÅÄ ar standarta marÅ”rutÄÅ”anas likumiem. TÄ kÄ trafiks ir paredzÄts resursdatoram 10.0.2.8, tai ir jÄiziet caur otro saskarni qr-92fa49b5-54 un jÄiet cauri vxlan tuneli uz skaitļoÅ”anas mezglu:
[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 ~]$
Viss ir loÄ£iski, bez pÄrsteigumiem. ApskatÄ«sim, kur br-int ir redzama resursdatora 10.0.2.8 magones adrese:
Satiksme ieiet tunelÄ«, lai aprÄÄ·inÄtu-1. Nu, compute-1 viss ir vienkÄrÅ”i - no br-tun pakotne nonÄk br-int un no turienes uz virtuÄlÄs maŔīnas saskarni:
PÄrbaudÄ«sim, vai Ŕī patieÅ”Äm ir pareizÄ saskarne:
[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 ~]$
PatiesÄ«bÄ mÄs izgÄjÄm cauri paku. Es domÄju, ka pamanÄ«jÄt, ka satiksme gÄja pa dažÄdiem vxlan tuneļiem un izbrauca ar dažÄdiem VNI. ApskatÄ«sim, kas tie ir par VNI, pÄc tam savÄksim izgÄztuvi mezgla vadÄ«bas portÄ un pÄrliecinÄsimies, ka satiksme notiek tieÅ”i tÄ, kÄ aprakstÄ«ts iepriekÅ”.
TÄtad tunelim, lai aprÄÄ·inÄtu-0, ir Å”Ädas darbÄ«bas=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],izeja:3. PÄrveidosim 0x16 par decimÄlo skaitļu sistÄmu:
0x16 = 6*16^0+1*16^1 = 6+16 = 22
Tunelim, lai aprÄÄ·inÄtu-1, ir Å”Äds VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],izeja:2. PÄrveidosim 0x63 par decimÄlo skaitļu sistÄmu:
0x63 = 3*16^0+6*16^1 = 3+96 = 99
Nu, tagad apskatÄ«sim izgÄztuvi:
[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*******************
PirmÄ pakete ir vxlan pakete no resursdatora 192.168.255.19 (compute-0) uz resursdatoru 192.168.255.15 (control-1) ar vni 22, kurÄ ir iesaiÅota ICMP pakete no resursdatora 10.0.1.85 uz resursdatoru 10.0.2.8. KÄ mÄs aprÄÄ·inÄjÄm iepriekÅ”, vni atbilst tam, ko mÄs redzÄjÄm izvadÄ.
OtrÄ pakete ir vxlan pakete no resursdatora 192.168.255.15 (control-1) uz resursdatoru 192.168.255.26 (compute-1) ar vni 99, kurÄ ICMP pakete ir iepakota no resursdatora 10.0.1.85 uz resursdatoru 10.0.2.8. KÄ mÄs aprÄÄ·inÄjÄm iepriekÅ”, vni atbilst tam, ko mÄs redzÄjÄm izvadÄ.
NÄkamÄs divas paketes ir atgriezeniskÄ trafika no 10.0.2.8, nevis 10.0.1.85.
Tas ir, galu galÄ mÄs saÅÄmÄm Å”Ädu vadÄ«bas mezgla shÄmu:
IzskatÄs, ka tas tÄ ir? MÄs aizmirsÄm par divÄm nosaukumvietÄm:
TÄ kÄ mÄs runÄjÄm par mÄkoÅa platformas arhitektÅ«ru, bÅ«tu labi, ja maŔīnas automÄtiski saÅemtu adreses no DHCP servera. Å ie ir divi DHCP serveri mÅ«su diviem tÄ«kliem 10.0.1.0/24 un 10.0.2.0/24.
PÄrbaudÄ«sim, vai tÄ ir patiesÄ«ba. Å ajÄ nosaukumvietÄ ir tikai viena adrese - 10.0.1.1 - paÅ”a DHCP servera adrese, un tÄ ir iekļauta arÄ« br-int:
RezultÄtÄ vadÄ«bas mezglÄ mÄs iegÅ«stam Å”Ädu pakalpojumu kopu:
Nu, paturiet prÄtÄ - Ŕīs ir tikai 4 maŔīnas, 2 iekÅ”Äjie tÄ«kli un viens virtuÄlais marÅ”rutÄtÄjs... Mums Å”eit nav ÄrÄjo tÄ«klu, ir daudz dažÄdu projektu, katram ir savi tÄ«kli (pÄrklÄjas), un mums ir sadalÄ«ts marÅ”rutÄtÄjs izslÄdzÄs, un galu galÄ testa stendÄ bija tikai viens kontroles mezgls (lai nodroÅ”inÄtu kļūdu toleranci, ir jÄbÅ«t trÄ«s mezglu kvorumam). LoÄ£iski, ka tirdzniecÄ«bÄ viss ir ānedaudzā sarežģītÄk, taÄu Å”ajÄ vienkÄrÅ”ajÄ piemÄrÄ mÄs saprotam, kÄ tam vajadzÄtu darboties ā protams, ir svarÄ«gi, vai tev ir 3 vai 300 nosaukumvietas, bet no visas nosaukumvietas darbÄ«bas viedokļa. struktÅ«ra, nekas daudz nemainÄ«sies... lai gan, kamÄr jÅ«s nepievienosiet kÄda pÄrdevÄja SDN. Bet tas ir pavisam cits stÄsts.
Ceru, ka bija interesanti. Ja jums ir kÄdi komentÄri/papildinÄjumi vai kaut kur es tieÅ”i meloju (esmu cilvÄks un mans viedoklis vienmÄr bÅ«s subjektÄ«vs) - rakstiet, kas jÄlabo/pievieno - visu labosim/pievienosim.
NobeigumÄ es vÄlos teikt dažus vÄrdus par Openstack (gan vaniļas, gan pÄrdevÄja) salÄ«dzinÄÅ”anu ar mÄkoÅrisinÄjumu no VMWare ā man Å”is jautÄjums pÄdÄjo pÄris gadu laikÄ ir uzdots pÄrÄk bieži, un, atklÄti sakot, es esmu jau apnicis, bet tomÄr. ManuprÄt, ir ļoti grÅ«ti salÄ«dzinÄt Å”os divus risinÄjumus, taÄu noteikti varam teikt, ka abiem risinÄjumiem ir trÅ«kumi un izvÄloties vienu risinÄjumu ir jÄizsver plusi un mÄ«nusi.
Ja OpenStack ir kopienas virzÄ«ts risinÄjums, tad VMWare ir tiesÄ«bas darÄ«t tikai to, ko vÄlas (lasi - kas tam ir izdevÄ«gi) un tas ir loÄ£iski - jo tÄ ir komercsabiedrÄ«ba, kas ir pieradusi pelnÄ«t naudu no saviem klientiem. Bet ir viens liels un trekns BET - jÅ«s varat izkÄpt no OpenStack, piemÄram, no Nokia un ar nelieliem izdevumiem pÄriet uz risinÄjumu, piemÄram, no Juniper (Contrail Cloud), bet diez vai jÅ«s varÄsit izkÄpt no VMWare . Man Å”ie divi risinÄjumi izskatÄs Å”Ädi - Openstack (vendor) ir vienkÄrÅ”s bÅ«ris, kurÄ tevi ieliek, bet tev ir atslÄga un tu vari iziet jebkurÄ brÄ«dÄ«. VMWare ir zelta bÅ«ris, saimniekam ir bÅ«ra atslÄga un tas tev izmaksÄs dÄrgi.
Es nereklamÄju ne pirmo, ne otro produktu - jÅ«s izvÄlaties to, kas jums nepiecieÅ”ams. Bet, ja man bÅ«tu tÄda izvÄle, es izvÄlÄtos abus risinÄjumus - VMWare IT mÄkonim (zemas slodzes, vienkÄrÅ”a pÄrvaldÄ«ba), OpenStack no kÄda pÄrdevÄja (Nokia un Juniper nodroÅ”ina ļoti labus pabeigtus risinÄjumus) - Telecom mÄkonim. Es neizmantotu Openstack tikai IT vajadzÄ«bÄm - tas ir kÄ Å”aut uz zvirbuļiem ar lielgabalu, bet es neredzu nekÄdas kontrindikÄcijas tÄ lietoÅ”anai, izÅemot atlaiÅ”anu. TomÄr VMWare izmantoÅ”ana telekomunikÄcijÄs ir kÄ Å”Ä·embu vilkÅ”ana ar Ford Raptor ā tas ir skaisti no Ärpuses, bet vadÄ«tÄjam ir jÄveic 10 braucieni, nevis viens.
ManuprÄt lielÄkais VMWare mÄ«nuss ir tÄ pilnÄ«ga noslÄgtÄ«ba - uzÅÄmums nedos nekÄdu informÄciju par to kÄ tas darbojas, piemÄram, vSAN vai kas atrodas hipervizora kodolÄ - tas viÅam vienkÄrÅ”i nav izdevÄ«gi - proti, jÅ«s nekad nekļūsti par VMWare ekspertu ā bez pÄrdevÄja atbalsta tu esi lemts (ļoti bieži es sastopu VMWare ekspertus, kuri ir neizpratnÄ par triviÄliem jautÄjumiem). Man VMWare pÄrk auto ar aizslÄgtu motora pÄrsegu - jÄ, jums var bÅ«t speciÄlisti, kas var nomainÄ«t zobsiksnu, bet pÄrsegu var atvÄrt tikai tas, kurÅ” jums pÄrdeva Å”o risinÄjumu. PersonÄ«gi man nepatÄ«k risinÄjumi, kuros es nevaru iekļauties. Teiksiet, ka var nebÅ«t zem pÄrsega iet. JÄ, tas ir iespÄjams, bet es paskatÄ«Å”os uz jums, kad jums bÅ«s jÄsamontÄ liela funkcija mÄkonÄ« no 20-30 virtuÄlajÄm maŔīnÄm, 40-50 tÄ«kliem, no kuriem puse vÄlas iet ÄrÄ, bet otrÄ puse prasa SR-IOV paÄtrinÄjums, pretÄjÄ gadÄ«jumÄ jums bÅ«s nepiecieÅ”ami vÄl pÄris desmiti Å”o automaŔīnu - pretÄjÄ gadÄ«jumÄ ar veiktspÄju nepietiks.
Ir arÄ« citi viedokļi, tÄpÄc tikai jÅ«s varat izlemt, ko izvÄlÄties, un, pats galvenais, jÅ«s pÄc tam bÅ«siet atbildÄ«gs par savu izvÄli. Tas ir tikai mans viedoklis - cilvÄks, kurÅ” ir redzÄjis un aptaustÄ«jis vismaz 4 produktus - Nokia, Juniper, Red Hat un VMWare. Tas ir, man ir ar ko salÄ«dzinÄt.