Computimet në re po depërtojnë gjithnjë e më thellë në jetën tonë dhe tashmë duket se nuk ka asnjë njeri që të ketë shmangur ndonjëherë shërbimet e ndryshme në re. Por, çfarë është saktësisht reja dhe si funksionon ajo është një gjë që shumë njerëz e dinë vetëm në nivelin e konceptit. 5G tani është një realitet dhe infrastruktura telekomunikuese ka filluar të kalojë nga zgjidhjet tradicionale në zgjidhjet në re, ashtu siç kaloi nga zgjidhjet e plota harduerike në ato të virtualizuara.
Sot do të flasim për botën e brendshme të infrastrukturës në re, konkretisht do të shqyrtojmë bazat e pjesës rrjete.
ĂfarĂ« Ă«shtĂ« reja? NjĂ« formĂ« virtualizimi â njĂ« pamje nga profili?
NjĂ« pyetje shumĂ« logjike. Jo â nuk Ă«shtĂ« virtualizim, megjithĂ«se nuk ka munguar. Le tĂ« shqyrtojmĂ« dy pĂ«rkufizime:
Computimet nĂ« re (tĂ« quajtura mĂ« tej Reja) â Ă«shtĂ« njĂ« model i ofrimit tĂ« njĂ« qasjeje miqĂ«sore pĂ«r pĂ«rdoruesin nĂ« burimet kompjuterike tĂ« shpĂ«rndara, tĂ« cilat duhet tĂ« jenĂ« tĂ« vendosura dhe tĂ« aktivizuara sipas kĂ«rkesĂ«s me vonesĂ« minimale dhe me shpenzime minimale nga ana e ofruesit tĂ« shĂ«rbimeve.
Virtualizimi â Ă«shtĂ« mundĂ«sia pĂ«r tĂ« ndarĂ« njĂ« entitet fizik (si pĂ«r shembull njĂ« server) nĂ« disa virtualĂ«, duke rritur kĂ«shtu shfrytĂ«zimin e burimeve (pĂ«r shembull, nĂ«se keni 3 servera tĂ« ngarkuar nĂ« 25-30 pĂ«r qind, pas virtualizimit merrni 1 server tĂ« ngarkuar nĂ« 80-90 pĂ«r qind). Natyrisht, virtualizimi merr njĂ« pjesĂ« tĂ« burimeve â ju duhet tĂ« ushqeni hipervizorin, megjithatĂ«, siç ka treguar praktika, vlera e pĂ«rpjekjes Ă«shtĂ« e madhe. NjĂ« shembull perfekt i virtualizimit Ă«shtĂ« VMWare, e cila pĂ«rgatit shkĂ«lqyeshĂ«m makina virtuale, ose pĂ«r shembull KVM, qĂ« mĂ« pĂ«lqen mĂ« shumĂ«, por kjo Ă«shtĂ« çështje shije.
Ne pĂ«rdorim virtualizimin pa e kuptuar, madje edhe ruterat e harduerit pĂ«rdorin virtualizimin â pĂ«r shembull, nĂ« versionet e fundit tĂ« sistemit operativ JunOS, instalimi bĂ«het si njĂ« makinĂ« virtuale mbi njĂ« distribucion real-time linux (Wind River 9). Por virtualizimi nuk Ă«shtĂ« e njĂ«jta gjĂ« me re, megjithatĂ«, reja nuk mund tĂ« ekzistojĂ« pa virtualizim.
Virtualizimi është një nga blloqet mbi të cilat ndërtohet reja.
TĂ« krijosh njĂ« cloud thjesht duke grumbulluar disa hypervisors nĂ« njĂ« domain L2, duke shtuar disa playbooks yaml pĂ«r tĂ« automatizuar konfigurimin e VLAN-Ă«ve pĂ«rmes ndonjĂ« ansible dhe duke e mbuluar kĂ«tĂ« me njĂ« sistem orkestrimi pĂ«r krijimin automatike tĂ« makinave virtuale â nuk do tĂ« funksionojĂ«. SaktĂ«sisht, do tĂ« funksionojĂ«, por Frankenstein-i qĂ« rezulton nuk Ă«shtĂ« ai cloud qĂ« na nevojitet, megjithatĂ«, ndoshta pĂ«r disa, kjo Ă«shtĂ« kulmi i Ă«ndrrave. Gjithashtu, nĂ«se e marrim Openstack-in â pĂ«r nga natyra, edhe ai Ă«shtĂ« njĂ« Frankenstein i tillĂ«, por le tĂ« mos flasim pĂ«r kĂ«tĂ« tani.
Por e kuptoj që nga përkufizimi i paraqitur më sipër, nuk është krejtësisht e qartë se çfarë mund të quhet vërtet cloud.
Prandaj, në dokumentin e NIST (Instituti Kombëtar i Standardeve dhe Teknologjisë) janë renditur 5 karakteristika kryesore që duhet të ketë infrastruktura cloud:
Ofrimi i shĂ«rbimit sipas kĂ«rkesĂ«s. PĂ«rdoruesi duhet tĂ« ketĂ« qasje tĂ« lirĂ« nĂ« burimet kompjuterike tĂ« dedikuara (si rrjetet, diskĂ«t virtualĂ«, memorjen, bĂ«rthamat e procesorĂ«ve etj.) dhe kĂ«to burime duhet tĂ« ofrohen automatikisht â pra pa ndĂ«rhyrjen e ofruesit tĂ« shĂ«rbimit.
Disponueshmëria e gjerë e shërbimit. Qasja në burime duhet të sigurohet përmes mekanizmave standard për të mundësuar përdorimin e PC-ve standarde, klientëve të hollë dhe pajisjeve mobile.
Bashkimi i burimeve nĂ« grupe. Grupet e burimeve duhet tĂ« sigurojnĂ« ofrimin e burimeve pĂ«r disa klientĂ« nĂ« tĂ« njĂ«jtĂ«n kohĂ«, duke siguruar izolimin e klientĂ«ve dhe mungesĂ«n e ndikimit reciprok midis tyre dhe konkurrencĂ«s pĂ«r burime. Grupet pĂ«rfshijnĂ« edhe rrjetet, qĂ« tregon mundĂ«sinĂ« e pĂ«rdorimit tĂ« adresimit tĂ« pĂ«rfshirĂ«. Grupi duhet tĂ« mbĂ«shtesĂ« shkallĂ«zimin sipas kĂ«rkesĂ«s. PĂ«rdorimi i grupeve lejon sigurimin e nivelit tĂ« nevojshĂ«m tĂ« qĂ«ndrueshmĂ«risĂ« sĂ« burimeve dhe abstarhimin e burimeve fizike dhe virtuale â marrĂ«si i shĂ«rbimit thjesht merr setin e kĂ«rkuar tĂ« burimeve (ku janĂ« fizikisht kĂ«to burime, nĂ« sa servera dhe switch-a â klienti nuk ka rĂ«ndĂ«si). MegjithatĂ«, duhet tĂ« merret parasysh fakti se ofruesi duhet tĂ« sigurojĂ« rezervimin transparent tĂ« kĂ«tyre burimeve.
PĂ«rshtatje e shpejtĂ« ndaj kushteve tĂ« ndryshme. ShĂ«rbimet duhet tĂ« jenĂ« fleksibĂ«l â ofrim tĂ« shpejtĂ« tĂ« burimeve, ri-shpĂ«rndarje, shtim ose shkurtim tĂ« burimeve sipas kĂ«rkesĂ«s sĂ« klientit, duke i dhĂ«nĂ« klientit pĂ«rshtypjen se burimet e cloud-it janĂ« tĂ« pafundme. PĂ«r ta bĂ«rĂ« mĂ« tĂ« qartĂ«, pĂ«r shembull, ju nuk shihni njĂ« paralajmĂ«rim qĂ« ndonjĂ« hapĂ«sirĂ« e disku nĂ« Apple iCloud tuaj ka humbur pĂ«r shkak tĂ« njĂ« disku tĂ« thyer nĂ« server, ndonĂ«se disqet dĂ«shtojnĂ«. PĂ«r mĂ« tepĂ«r, mundĂ«sitĂ« e kĂ«tij shĂ«rbimi nga ana juaj janĂ« pothuajse tĂ« pakufizuara â nĂ«se ju nevojiten 2 TB â s'ka problem, paguani dhe merrni. NjĂ« shembull i ngjashĂ«m mund tĂ« jepet pĂ«r Google Drive ose Yandex Disk.
Mundësia për të matur shërbimin e ofruar. Sistemet cloud duhet të kontrollojnë dhe optimizojnë automatikisht burimet e konsumuara, duke qenë se këto mekanizma duhet të jenë të qarta si për përdoruesin ashtu edhe për ofruesin e shërbimeve. Kjo do të thotë se ju gjithmonë mund të kontrolloni sa burime konsumoni ju dhe klientët tuaj.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« merret parasysh se kĂ«to kĂ«rkesa kryesisht janĂ« kĂ«rkesa pĂ«r cloud publik, prandaj pĂ«r cloud privat (domethĂ«nĂ« cloud i drejtuar pĂ«r nevojat e brendshme tĂ« kompanisĂ«), kĂ«to kĂ«rkesa mund tĂ« jenĂ« paksa tĂ« ndryshuara. MegjithatĂ«, ato ende duhet tĂ« pĂ«rmbushen, pĂ«rndryshe nuk do tĂ« pĂ«rfitojmĂ« nga tĂ« gjitha avantazhet e llogaritjes nĂ« cloud.
Pse na duhet cloudi?
MegjithatĂ«, çdo teknologji e re apo ekzistuese, çdo protokoll i ri krijohet pĂ«r njĂ« qĂ«llim (pĂ«rveç RIP-ng, natyrisht). NjĂ« protokoll pĂ«r protokollin nuk ka vlerĂ« (pĂ«rveç RIP-ng, natyrisht). ĂshtĂ« logjike qĂ« Cloud krijohet pĂ«r tĂ« ofruar njĂ« shĂ«rbim pĂ«r pĂ«rdoruesin/konsumatorin. TĂ« gjithĂ« jemi njohur me disa shĂ«rbime cloud, siç janĂ« Dropbox ose Google.Docs, dhe e mendoj se shumica prej nesh i pĂ«rdorin me sukses â pĂ«r shembull, ky artikull Ă«shtĂ« shkruar duke pĂ«rdorur shĂ«rbimin cloud Google.Docs. Por shĂ«rbimet cloud qĂ« njohim janĂ« vetĂ«m njĂ« pjesĂ« e mundĂ«sive tĂ« cloud-it â mĂ« saktĂ«sisht, ato janĂ« vetĂ«m shĂ«rbime tĂ« tipit SaaS. Ne mund tĂ« ofrojmĂ« njĂ« shĂ«rbim cloud nĂ« tri forma: si SaaS, PaaS ose IaaS. ShĂ«rbimi qĂ« ju nevojitet varet nga dĂ«shirat dhe mundĂ«sitĂ« tuaja.
Le të shqyrtojmë secilin me radhë:
Software as a Service (SaaS) â Ă«shtĂ« njĂ« model i ofrimit tĂ« njĂ« shĂ«rbimi tĂ« plotĂ« pĂ«r klientin, pĂ«r shembull njĂ« shĂ«rbim postĂ« si Yandex.Mail ose Gmail. NĂ« kĂ«tĂ« model, ju si klient nĂ« tĂ« vĂ«rtetĂ« nuk bĂ«ni asgjĂ«, pĂ«rveçse pĂ«rdorni shĂ«rbimin â pra, nuk keni nevojĂ« tĂ« mendoni pĂ«r konfigurimin e shĂ«rbimit, qĂ«ndrueshmĂ«rinĂ« e tij ose rezervimin. E gjithĂ« çështja Ă«shtĂ« tĂ« mos e komprometoni fjalĂ«kalimin tuaj, gjithçka tjetĂ«r do ta bĂ«jĂ« ofruesi i kĂ«tij shĂ«rbimi. Nga pikĂ«pamja e ofruesit tĂ« shĂ«rbimit â ai merr pĂ«rgjegjĂ«sinĂ« e plotĂ« pĂ«r tĂ« gjithĂ« shĂ«rbimin â nga pajisjet server dhe sistemet operative tĂ« hostit, deri te cilĂ«sitĂ« e bazave tĂ« tĂ« dhĂ«nave dhe softuerit.
Platform as a Service (PaaS) â me pĂ«rdorimin e kĂ«tij modeli, ofruesi i shĂ«rbimeve i jep klientit njĂ« skelĂ« pĂ«r shĂ«rbimin, pĂ«r shembull marrim Serverin Web. Ofruesi i shĂ«rbimeve i dha klientit njĂ« server virtual (nĂ« fakt njĂ« grup burimesh, tĂ« tilla si RAM/CPU/Storage/Nets dhe tĂ« tjera), madje edhe instaloi nĂ« atĂ« server sistemin operativ dhe softuerin e nevojshĂ«m, por konfigurimin e tĂ« gjitha kĂ«tyre e kryen vetĂ« klienti dhe ai Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r funksionimin e shĂ«rbimit. Ofruesi i shĂ«rbimeve, siç ndodhi edhe nĂ« rastin e kaluar, Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r funksionimin e pajisjeve fizike, hipervizorĂ«ve, vetĂ« makinerisĂ« virtuale, aksesin e saj nĂ« rrjet etj., por shĂ«rbimi tashmĂ« Ă«shtĂ« jashtĂ« zonĂ«s sĂ« tij tĂ« pĂ«rgjegjĂ«sisĂ«.
InfrastrukturĂ« si ShĂ«rbim (IaaS) â kyçja nĂ« kĂ«tĂ« qasje Ă«shtĂ« mĂ« interesante, nĂ« fakt ofruesi i shĂ«rbimeve i ofron klientit njĂ« infrastrukturĂ« tĂ« plotĂ« tĂ« virtualizuar â domethĂ«nĂ« njĂ« grup (basen) burimesh, si CPU Cores, RAM, Networks etj. Ădo gjĂ« tjetĂ«r Ă«shtĂ« çështje e klientit â çfarĂ« dĂ«shiron tĂ« bĂ«jĂ« klienti me kĂ«to burime brenda basenit tĂ« tij tĂ« caktuar (kuotat) â ofruesit nuk i bĂ«het shumĂ« vonĂ«. NĂ«se klienti dĂ«shiron tĂ« krijojĂ« vEPC tĂ« vetin ose madje tĂ« bĂ«het njĂ« operator i vogĂ«l dhe tĂ« ofrojĂ« shĂ«rbime komunikimi â nuk Ă«shtĂ« problem â bĂ«je. NĂ« njĂ« skenar tĂ« tillĂ«, ofruesi i shĂ«rbimeve Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r sigurimin e burimeve, qĂ«ndrueshmĂ«rinĂ« e tyre dhe disponueshmĂ«rinĂ«, si dhe pĂ«r sistemin operativ qĂ« lejon bashkimin e kĂ«tyre burimeve nĂ« basene dhe t'ia sigurojĂ« klientit me mundĂ«sinĂ« pĂ«r tĂ« rritur ose ulur burimet nĂ« çdo moment sipas kĂ«rkesĂ«s sĂ« klientit. TĂ« gjitha makinat e virtualizuara dhe çdo gjĂ« tjetĂ«r klienti i konfiguron vetĂ« pĂ«rmes portalit tĂ« vetĂ«-shĂ«rbimit dhe konsolĂ«s, pĂ«rfshirĂ« edhe caktimin e rrjeteve (pĂ«rveç rrjeteve tĂ« jashtme).
ĂfarĂ« Ă«shtĂ« OpenStack?
NĂ« tĂ« tre variantet, ofruesi i shĂ«rbimeve ka nevojĂ« pĂ«r njĂ« sistem operativ qĂ« lejon ndĂ«rtimin e njĂ« infrastrukture nĂ« re. NĂ« fakt, nĂ« SaaS, pĂ«r tĂ« gjithĂ« teknologjinĂ« pĂ«rgjigjen jo njĂ« njĂ«si â ekziston njĂ« njĂ«si qĂ« kujdeset pĂ«r infrastrukturĂ«n â pra ofron IaaS pĂ«r njĂ« njĂ«si tjetĂ«r, dhe kjo njĂ«si ofron SaaS pĂ«r klientin. OpenStack Ă«shtĂ« njĂ« nga sistemet operative tĂ« reve qĂ« lejon grumbullimin e shumĂ« switch-esh, serverĂ«sh dhe sistemeve tĂ« ruajtjes nĂ« njĂ« grumbull burimesh tĂ« vetme, duke e ndarĂ« kĂ«tĂ« grumbull tĂ« pĂ«rbashkĂ«t nĂ« nĂ«n-grumbuj (tenantĂ«) dhe duke ofruar kĂ«to resurse pĂ«r klientĂ«t pĂ«rmes rrjetit.
OpenStack â Ă«shtĂ« njĂ« sistem operativ nĂ« re qĂ« lejon kontrollin e grumbujve tĂ« mĂ«dhenj tĂ« burimeve pĂ«rpunuese, hapĂ«sirave tĂ« dhĂ«nash dhe burimeve rrjetĂ«s, provizionimi dhe menaxhimi i tĂ« cilave bĂ«het pĂ«rmes API-sĂ« duke pĂ«rdorur mekanizmat standard tĂ« autentifikimit.
Me te thĂ«nĂ« ndryshe, ky Ă«shtĂ« njĂ« grup projektesh tĂ« softuerit tĂ« lirĂ« qĂ« synon krijimin e shĂ«rbimeve shĂ«ndrore nĂ« cloud, (si ato publike ashtu dhe private) â pra njĂ« set mjetesh qĂ« lejon bashkimin e pajisjeve serverike dhe komunikimit nĂ« njĂ« grup tĂ« vetĂ«m burimesh, menaxhimin e kĂ«tyre burimeve dhe sigurimin e nivelit tĂ« nevojshĂ«m tĂ« disponueshmĂ«risĂ«.
Në momentin e shkrimit të këtij materiali, struktura e OpenStack duket kështu:
Imazhi është marrë nga
Ădo komponent qĂ« pĂ«rbĂ«n OpenStack ka njĂ« funksion tĂ« caktuar. Kjo arkitekturĂ« e shpĂ«rndarĂ« lejon pĂ«rfshirjen e atij grupi komponentĂ«sh funksionalĂ« qĂ« ju nevojiten. MegjithatĂ«, disa komponentĂ« janĂ« komponentĂ« kryesorĂ« dhe heqja e tyre do tĂ« çonte nĂ« mosfunksionimin e plotĂ« ose tĂ« pjesshĂ«m tĂ« zgjidhjes nĂ« tĂ«rĂ«si. KomponentĂ«t e tillĂ« zakonisht pĂ«rfshijnĂ«:
- Tabela e informacionit â GUI bazuar nĂ« web pĂ«r menaxhimin e shĂ«rbimeve OpenStack
- Keystone â njĂ« shĂ«rbim i centralizuar i identifikimit, i cili ofron funksionalitetin e autentifikimit dhe autorizimit pĂ«r shĂ«rbime tĂ« tjera, si dhe menaxhon akreditivĂ«t e pĂ«rdoruesve dhe rolet e tyre.
- Neutron â njĂ« shĂ«rbim rrjeti qĂ« siguron lidhshmĂ«rinĂ« midis interfeseve tĂ« ndryshme tĂ« shĂ«rbimeve OpenStack (duke pĂ«rfshirĂ« lidhshmĂ«rinĂ« midis VM-ve dhe aksesin e tyre nĂ« botĂ«n e jashtme)
- Cinder â ofron akses nĂ« ruajtjen me bllok pĂ«r makinat virtuale
- Nova â menaxhimi i ciklit tĂ« jetĂ«s sĂ« makinave virtuale
- Glance â njĂ« repository pĂ«r imazhet e makinave virtuale dhe snapshots
- Swift â ofron akses nĂ« ruajtjen me objekte
- Ceilometer â njĂ« shĂ«rbim qĂ« ofron mundĂ«sinĂ« pĂ«r mbledhjen e telemetrisĂ« dhe matjen e burimeve ekzistuese dhe ato nĂ« pĂ«rdorim
- Heat â orkestrimi bazuar nĂ« template pĂ«r krijimin dhe provizionimin automatik tĂ« burimeve
Lista e plotë e të gjitha projekteve dhe qëllimeve të tyre mund të shikohet .
Secila nga komponentĂ«t e OpenStack Ă«shtĂ« njĂ« shĂ«rbim qĂ« pĂ«rgjigjet pĂ«r njĂ« funksion tĂ« caktuar dhe ofron njĂ« API pĂ«r menaxhimin e kĂ«tij funksioni dhe ndĂ«rveprimin e kĂ«tij shĂ«rbimi me shĂ«rbime tĂ« tjera tĂ« sistemit operativ nĂ« re, me qĂ«llim krijimin e njĂ« infrastrukture tĂ« vetme. PĂ«r shembull, Nova siguron menaxhimin e burimeve tĂ« kompjuterĂ«ve dhe API pĂ«r qasje nĂ« konfigurimin e kĂ«tyre burimeve, Glance â menaxhimin e imazheve dhe API pĂ«r menaxhimin e tyre, Cinder â magazinimin bllok dhe API pĂ«r menaxhim etj. TĂ« gjitha funksionet janĂ« tĂ« lidhura ngushtĂ«sisht me njĂ«ra-tjetrĂ«n.
MegjithatĂ«, nĂ«se e shqyrtojmĂ«, tĂ« gjithĂ« shĂ«rbimet qĂ« janĂ« aktivizuar nĂ« OpenStack pĂ«rfaqĂ«sojnĂ« nĂ« fund tĂ« fundit ndonjĂ« makinĂ« virtuale (ose kontejner) qĂ« Ă«shtĂ« e lidhur me rrjetin. Lind pyetja â pĂ«rse na nevojiten kaq shumĂ« elementĂ«?
Le të kalojmë përmes algoritmit për krijimin e një makine virtuale dhe lidhjen e saj me rrjetin dhe magazinimin e përhershëm në OpenStack.
- Kur ju krijoni njĂ« kĂ«rkesĂ« pĂ«r tĂ« krijuar njĂ« makinĂ«, qoftĂ« pĂ«rmes Horizon (Dashboard) ose pĂ«rmes CLI, gjĂ«ja e parĂ« qĂ« ndodh Ă«shtĂ« autorizimi i kĂ«rkesĂ«s suaj nĂ« Keystone â a keni tĂ« drejtĂ« tĂ« krijoni njĂ« makinĂ«, a keni tĂ« drejtĂ« tĂ« pĂ«rdorni kĂ«tĂ« rrjet, a keni mjaft kuota pĂ«r projektin tuaj etj.
- Keystone kryen autentikimin e kërkesës suaj dhe gjeneron në përgjigje një auth-token, i cili do të përdoret më tej. Pas marrjes së përgjigjes nga Keystone, kërkesa dërgohet drejt Nova (nova api).
- Nova-api kontrollon vlefshmërinë e kërkesës suaj duke u drejtuar në Keystone, duke përdorur auth-token e gjeneruar më parë.
- Keystone kryen autentikimin dhe ofron mbi bazën e këtij auth-token informacion mbi lejet dhe kufizimet.
- Nova-api krijon në nova-database një regjistrim për VM-në e re dhe dërgon kërkesën për krijimin e makinës në nova-scheduler.
- Nova-scheduler bën zgjedhjen e hostit (nodos kompjuterike), ku VM do të vendoset sipas parametrave të caktuar, peshave dhe zonas. Regjistrimi në lidhje me këtë dhe identifikuesi i VM-së regjistrohen në nova-database.
- Më pas, nova-scheduler i drejtohet nova-compute me një kërkesë për të shpërndarë një instancë. Nova-compute i drejtohet nova-conductor për të marrë informacionin mbi parametrat e makinës (nova-conductor është një komponent i nova-s që funksionon si një server proxy midis nova-database dhe nova-compute, duke kufizuar numrin e kërkesave ndaj nova-database për të parandaluar problemet me konsistencën e bazës së të dhënave dhe për të reduktuar ngarkesën).
- Nova-conductor merr informacionin e kërkuar nga nova-database dhe ia kalon atë nova-compute.
- Më pas, nova-compute i drejtohet glance për të marrë ID-në e imazhit. Glance realizon validimin e kërkesës në Keystone dhe kthen informacionin e kërkuar.
- Nova-compute i drejtohet neutron për të marrë informacionin mbi parametrat e rrjetit. Në mënyrë të ngjashme me glance, neutron realizon validimin e kërkesës në Keystone, më pas krijon një regjistrim në database (identifikuesin e portit, etj.), krijon një kërkesë për krijimin e portit dhe kthen informacionin e kërkuar në nova-compute.
- Nova-compute i drejtohet cinder me një kërkesë për alokimin e një volume virtual për makinën. Në mënyrë të ngjashme me glance, cinder realizon validimin e kërkesës në Keystone, krijon një kërkesë për krijimin e volumit dhe kthen informacionin e kërkuar.
- Nova-compute i drejtohet libvirt me një kërkesë për të krijuar një makinë virtuale me parametrat e caktuar.
NĂ« thelb, duket si njĂ« operacion i thjeshtĂ« pĂ«r krijimin e njĂ« makine virtuale, por shndĂ«rrohet nĂ« njĂ« grumbull thirrjesh API mes elementĂ«ve tĂ« platformĂ«s cloud. Gjithashtu, siç e shihni, edhe shĂ«rbimet e mĂ«parshme pĂ«rbĂ«hen nga komponentĂ« mĂ« tĂ« vegjĂ«l, mes tĂ« cilĂ«ve ndodh ndĂ«rveprimi. Krijimi i makinĂ«s Ă«shtĂ« vetĂ«m njĂ« pjesĂ« e vogĂ«l e asaj qĂ« ofron platforma cloud â ekziston njĂ« shĂ«rbim pĂ«r balancimin e trafikĂ«ve, njĂ« shĂ«rbim pĂ«r ruajtjen bllok, njĂ« shĂ«rbim pĂ«r DNS, njĂ« shĂ«rbim pĂ«r provizionimin e serverĂ«ve bare metal, etj. Cloud-i ju lejon tĂ« zhvilloni makinat tuaja virtuale si njĂ« tufĂ« dele (nĂ« krahasim me virtualizimin). NĂ«se nĂ« njĂ« mjedis virtual ndodh diçka me makinĂ«n â ju e rikuperoni atĂ« nga kopjet e sigurisĂ«, etj., ndĂ«rsa aplikacionet cloud janĂ« ndĂ«rtuar nĂ« njĂ« mĂ«nyrĂ« qĂ« makinat virtuale nuk luajnĂ« njĂ« rol tĂ« tillĂ« tĂ« rĂ«ndĂ«sishĂ«m â nĂ«se makina virtuale 'vdes' â nuk Ă«shtĂ« problem â thjesht krijohet njĂ« makinĂ« tjetĂ«r mbi bazĂ«n e njĂ« template dhe, siç thonĂ«, skuadra nuk e vĂ«ren humbjen e luftĂ«tarit. Natyrisht, kjo pĂ«rfshin praninĂ« e mekanizmave tĂ« orkestrimit â duke pĂ«rdorur template-t Heat, ju mund tĂ« krijoni pa ndonjĂ« problem njĂ« funksion tĂ« komplikuar, i cili pĂ«rbĂ«het nga dhjetĂ«ra rrjete dhe makina virtuale.
ĂshtĂ« gjithmonĂ« e rĂ«ndĂ«sishme tĂ« mbani mend se infrastruktura cloud nuk ekziston pa rrjet â çdo element ndĂ«rvepron nĂ« njĂ« mĂ«nyrĂ« ose tjetrĂ«n me elementĂ«t e tjerĂ« pĂ«rmes rrjetit. Gjithashtu, rrjeti i cloud-it nuk Ă«shtĂ« absolutisht statik. Natyrisht, rrjeti i nĂ«nĂ«s Ă«shtĂ« relativisht statik â nuk shtohen çdo ditĂ« nodet dhe switch-et e rinj, megjithatĂ« komponenti i overlay mund tĂ« ndryshojĂ« vazhdimisht â do tĂ« shtohen ose hiqen rrjete tĂ« reja, do tĂ« krijohen makina virtuale tĂ« reja dhe do tĂ« vdesin ato tĂ« vjetra. Dhe siç e mbani mend nga pĂ«rcaktimi i cloud-it, i dhĂ«nĂ« nĂ« fillim tĂ« artikullit â burimet duhet t'i caktohen pĂ«rdoruesit automatikisht dhe me minimalin (preferohet pa) ndĂ«rhyrjen nga ana e ofruesit tĂ« shĂ«rbimeve. Pra, ai tip i ofrimit tĂ« burimeve tĂ« rrjetit qĂ« ekziston tani si frontend nĂ« formĂ«n e kabinetit tuaj personal tĂ« aksesueshĂ«m pĂ«rmes http/https dhe inxhinierit tĂ« rrjetit nĂ« dispozicion Vasili si backend â nuk Ă«shtĂ« cloud, edhe me tĂ« qenit Vasili me tetĂ« duar.
Neutron, si një shërbim rrjetesh, ofron API për menaxhimin e pjesës rrjet të infrastrukturës cloud. Shërbimi siguron funksionalitet dhe menaxhim të pjesës rrjet të OpenStack duke ofruar një nivel abstraksioni, të quajtur Network-as-a-Service (NaaS). Kështu që rrjeti është një njësi virtuale e matshme ashtu siç janë bërthamat virtuale të CPU-së apo volumi i RAM-it.
Por para se të kalojmë në arkitekturën e pjesës rrjet të OpenStack, le të shqyrtojmë se si funksionon kjo rrjet në OpenStack dhe pse rrjeti është një pjesë e rëndësishme dhe e pandashme e cloud-it.
Kështu, kemi dy makina virtuale të klientit RED dhe dy makina virtuale të klientit GREEN. Le të supozojmë se këto makina ndodhen në dy hypervizorë në këtë mënyrë:
Në këtë moment, është thjesht virtualizimi i 4 serverëve dhe asgjë më shumë, pasi deri tani gjithçka çka kemi bërë është virtualizimi i 4 serverëve, duke i vendosur ato në dy serverë fizikë. Dhe për më tepër, ato deri tani nuk janë të lidhura me rrjetin.
PĂ«r tĂ« krijuar njĂ« re, na duhen disa komponentĂ«. SĂ« pari, duhet tĂ« virtualizojmĂ« pjesĂ«n rrjetoreâna duhen kĂ«to 4 makina tĂ« lidhura çiftç. KlientĂ«t e duan pikĂ«risht lidhjen L2. Natyrisht, mund tĂ« pĂ«rdorim njĂ« switch dhe tĂ« konfigurojmĂ« njĂ« tranzit nĂ« drejtim tĂ« tij dhe tĂ« menaxhojmĂ« gjithçka me bridge Linux, ose pĂ«r pĂ«rdoruesit mĂ« tĂ« avancuar, openvswitch (pĂ«r kĂ«tĂ« do tĂ« kthehemi mĂ« vonĂ«). Por mund tĂ« ketĂ« shumĂ« rrjete, dhe vazhdimisht tĂ« kalojmĂ« L2 pĂ«rmes switch-it nuk Ă«shtĂ« ideja mĂ« e mirĂ«ânĂ« tĂ« tillĂ« mĂ«nyrĂ« si sektorĂ« tĂ« ndryshĂ«m, shĂ«rbimi me klientĂ«t, muaj pritjeje pĂ«r pĂ«rfundimin e kĂ«rkesave, javĂ« troubleshootimiânĂ« botĂ«n moderne, ky qasja nuk funksionon mĂ«. Dhe sa mĂ« shpejt e kupton njĂ« kompani kĂ«tĂ«, aq mĂ« lehtĂ« do tĂ« shkojĂ« pĂ«rpara. Prandaj, midis hypervisorĂ«ve, do tĂ« ndajmĂ« njĂ« rrjet L3 pĂ«rmes tĂ« cilit do tĂ« komunikojnĂ« makinat tona virtuale, dhe mbi kĂ«tĂ« rrjet L3 do tĂ« ndĂ«rtosh rrjete pĂ«rshtatĂ«se L2 (overlay) ku do tĂ« qarkullojĂ« trafiku i makinave tona virtuale. Si incapsulim, mund tĂ« pĂ«rdorim GRE, Geneve ose VxLAN. Deri tani do tĂ« ndalojmĂ« tek e fundit, megjithĂ«se kjo nuk Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme.
Na nevojitet të vendosim ndonjë vend për VTEP (shpresoj që gjithkush të jetë i njohur me terminologjinë VxLAN). Duke qenë se nga serverët del menjëherë një rrjet L3, nuk na pengon asgjë të vendosim VTEP në vetë serverët, dhe me OVS (OpenvSwitch) kjo bëhet mjaft mirë. Si rezultat, kemi marrë këtë konstruksion:
Duke qenë se trafiku midis VM-ve duhet të ndahet, portet në drejtim të makinave virtuale do të kenë numra të ndryshëm VLAN-esh. Numri i etiketës luan një rol vetëm brenda një switch-i virtual, pasi gjatë inkapsulimit në VxLAN mund ta heqim pa probleme, sepse do të kemi VNI.
Tani mund të krijojmë makinat dhe rrjetet virtuale për to pa asnjë problem.
Por çfarĂ« ndodh nĂ«se klienti ka njĂ« makinĂ« tjetĂ«r, por ndodhet nĂ« njĂ« rrjet tjetĂ«r? Na nevojitet routing midis rrjeteve. Do tĂ« shqyrtojmĂ« njĂ« variant tĂ« thjeshtĂ«, kur pĂ«rdoret routing-i centralizuar â domethĂ«nĂ«, trafiku rrotullohet pĂ«rmes nyjeve speciale tĂ« rrjetit (nĂ« pĂ«rgjithĂ«si ato pĂ«rkojnĂ« me nyjet e kontrollit, prandaj do tĂ« kemi tĂ« njĂ«jtin rezultat).
Duket se nuk Ă«shtĂ« ndonjĂ« gjĂ« e komplikuar â krijojmĂ« njĂ« ndĂ«rfaqe bridge nĂ« noden e kontrollit, dĂ«rgojmĂ« trafik nĂ« tĂ« dhe nga aty e r routing nĂ« destinacione tĂ« tjera. Por problemi Ă«shtĂ« se klienti RED dĂ«shiron tĂ« pĂ«rdorĂ« rrjetin 10.0.0.0/24, dhe klienti GREEN dĂ«shiron tĂ« pĂ«rdorĂ« gjithashtu rrjetin 10.0.0.0/24. KĂ«shtu qĂ« fillojnĂ« tĂ« kryqĂ«zohen hapĂ«sirat adresore. PĂ«r mĂ« tepĂ«r, klientĂ«t nuk duan qĂ« klientĂ« tĂ« tjerĂ« tĂ« mund tĂ« rruazohen nĂ« rrjetet e tyre tĂ« brendshme, gjĂ« qĂ« Ă«shtĂ« logjike. PĂ«r tĂ« ndarĂ« rrjetet dhe trafikun e tĂ« dhĂ«nave tĂ« klientĂ«ve, ne do t'u ndajmĂ« atyre nga njĂ« namespace tĂ« veçantĂ«. Namespace Ă«shtĂ« nĂ« fakt njĂ« kopje e stack-ut tĂ« rrjetit Linux, qĂ« do tĂ« thotĂ« se klientĂ«t nĂ« namespace RED janĂ« tĂ« plotĂ«sisht izoluar nga klientĂ«t nĂ« namespace GREEN (ose ndryshe, rruazimi midis kĂ«tyre rrjeteve tĂ« klientĂ«ve lejohet pĂ«rmes namespace default ose tashmĂ« nĂ« pajisjen e transportit mĂ« tĂ« lartĂ«).
Pra, kemi këtë skemë:
Tunlet L2 bashkohen nga të gjitha nodet computuese në noden e kontrollit, ku ndodhet ndërfaqja L3 për këto rrjete, çdo njëra në një namespace të veçantë për izolim.
Megjithatë, ne haruam gjënë më të rëndësishme. Makinë virtuale duhet të ofrojë shërbimin për klientin, që do të thotë se duhet të ketë të paktën një ndërfaqe të jashtme, përmes së cilës mund të aksesosh atë. Pra, na nevojitet një lidhje me botën e jashtme. Këtu ka disa mundësi. Le të bëjmë variantin më të thjeshtë. Do t'i shtojmë klientëve nga një rrjet, i cili do të jetë i vlefshëm në rrjetin e ofruesit dhe nuk do të përputhet me rrjete të tjera. Rrjetet mund të jenë gjithashtu të mbivendosura dhe të shikojnë në VRF të ndryshme në anën e rrjetit të ofruesit. Këto rrjete gjithashtu do të jetojnë në namespace e secilit klient. Megjithatë, për të dalë në botën e jashtme, ato do të kalojnë përmes një interfese fizike (ose të bonduar, që është më logjike). Për të ndarë trafikun e klientëve, trafiku që del jashtë do të etiketojë VLAN me etiketë të caktuar për klientin.
Si rezultat, ne morëm këtë skemë:
NjĂ« pyetje e arsyeshme Ă«shtĂ« â pse nuk tĂ« bĂ«jnĂ« portat nĂ« vetĂ« nodet e compute? Nuk ka shumĂ« probleme me kĂ«tĂ«, pĂ«r mĂ« tepĂ«r, kur aktivizohet routeri i shpĂ«rndarĂ« (DVR) do tĂ« funksionojĂ« nĂ« kĂ«tĂ« mĂ«nyrĂ«. NĂ« kĂ«tĂ« skenar, ne po shqyrtojmĂ« opsionin mĂ« tĂ« thjeshtĂ« me njĂ« gateway tĂ« centralizuar, i cili pĂ«rdoret siç Ă«shtĂ« pĂ«r default nĂ« Openstack. PĂ«r funksionalitetet me ngarkesĂ« tĂ« lartĂ« do tĂ« pĂ«rdoren si routeri i shpĂ«rndarĂ« ashtu edhe teknologjitĂ« e pĂ«rshpejtimit si SR-IOV dhe Passthrough, por siç thonĂ«, kjo Ă«shtĂ« njĂ« histori krejt tjetĂ«r. Fillimisht, le tĂ« shqyrtojmĂ« pjesĂ«n bazĂ«, e mĂ« pas do tĂ« merremi me detajet.
Saktësisht, plani ynë tashmë është operativ, megjithatë ka disa nuanca:
- Na duhet si ndonjë kënd që të mbrojmë makinat tona, domethënë të vendosim një filtrues në ndërfaqen e switch-it drejt klientit.
- Të bëjmë të mundur që makina virtuale të marrë automatikisht adresën ip, që të mos duhet të hyjmë gjithmonë në të përmes konsolës dhe të shkruajmë adresën.
Të fillojmë me mbrojtjen e makinave. Për këtë, mund të përdorim iptables të thjeshta, pse jo.
Pra, tani topologjia jonë është bërë paksa më e ndërlikuar:
Të shkojmë më tej. Na nevojitet të shtojmë serverin DHCP. Vendi më i përshtatshëm për vendosjen e serverëve DHCP për secilin nga klientët do të jetë pika kontrolluese e përmendur më parë, ku ndodhen namespaces:
MegjithatĂ«, ka njĂ« problem tĂ« vogĂ«l. ĂfarĂ« ndodh nĂ«se gjithçka rinis dhe tĂ« gjithĂ« informacionet mbi qiratĂ« e adresave nĂ« DHCP humbin? ĂshtĂ« logjike qĂ« makinave do t'u jepen adresa tĂ« reja, qĂ« nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme. Ka dy shpjegime â ose tĂ« pĂ«rdorim emra domenesh dhe tĂ« shtojmĂ« njĂ« server DNS pĂ«r secilin klient, atĂ«herĂ« adresa nuk do tĂ« jetĂ« shumĂ« e rĂ«ndĂ«sishme (si nĂ« pjesĂ«n rrjetore nĂ« k8s) â por kĂ«tu ka njĂ« problem me rrjetet e jashtme, pasi edhe atje adresat mund tĂ« jepen pĂ«rmes DHCP â nevojitet sinkronizimi mes serverĂ«ve DNS nĂ« platformĂ«n cloud dhe serverit DNS tĂ« jashtĂ«m, qĂ« sipas mendimit tim nuk Ă«shtĂ« shumĂ« fleksibĂ«l, megjithatĂ« Ă«shtĂ« plotĂ«sisht e mundur. Ose mundĂ«sia e dytĂ« â tĂ« pĂ«rdorim metadata â dmth. tĂ« ruajmĂ« informacionin mbi adresĂ«n e dhĂ«nĂ« makinĂ«s nĂ« mĂ«nyrĂ« qĂ« serveri DHCP tĂ« dijĂ« se cila adresĂ« t'i japĂ« makinĂ«s, nĂ«se makina ka marrĂ« tashmĂ« njĂ« adresĂ«. Opsioni i dytĂ« Ă«shtĂ« mĂ« i thjeshtĂ« dhe mĂ« fleksibĂ«l, pasi lejon ruajtjen e informacionit shtesĂ« mbi makinĂ«n. Tani do tĂ« shtojmĂ« nĂ« skemĂ« agentin e metadata:
NjĂ« çështje tjetĂ«r qĂ« merret parasysh Ă«shtĂ« mundĂ«sia e pĂ«rdorimit tĂ« njĂ« rrjeti tĂ« jashtĂ«m nga tĂ« gjithĂ« klientĂ«t, pasi rrjetet e jashtme, nĂ«se duhen tĂ« jenĂ« tĂ« vlefshme nĂ« tĂ« gjithĂ« rrjetin, do tĂ« sjellin vĂ«shtirĂ«si â duhet tĂ« ndahet vazhdimisht dhe tĂ« kontrollohet ndarja e kĂ«tyre rrjeteve. MundĂ«sia e pĂ«rdorimit tĂ« njĂ« rrjeti tĂ« parakonfiguruar tĂ« vetme pĂ«r tĂ« gjithĂ« klientĂ«t do tĂ« ishte shumĂ« e dobishme nĂ« krijimin e njĂ« re public. Kjo do ta thjeshtonte instalimin e makinave, pasi nuk do tĂ« na nevojitej tĂ« kontrollonim bazĂ«n e tĂ« dhĂ«nave pĂ«r adresat dhe tĂ« zgjedhnim njĂ« hapĂ«sirĂ« tĂ« veçantĂ« adresash pĂ«r rrjetin e jashtĂ«m tĂ« çdo klienti. PĂ«r mĂ« tepĂ«r, ne mund ta shkruajmĂ« rrjetin e jashtĂ«m paraprakisht, dhe nĂ« momentin e vendosjes, do tĂ« na nevojitet thjesht tĂ« asociojmĂ« adresat e jashtme me makinat e klientĂ«ve.
Dhe kĂ«tu na vjen nĂ« ndihmĂ« NAT â thjesht do tĂ« krijojmĂ« mundĂ«sinĂ« pĂ«r klientĂ«t qĂ« tĂ« dalin nĂ« botĂ«n e jashtme pĂ«rmes hapĂ«sirĂ«s default duke pĂ«rdorur NAT. Ka njĂ« problem tĂ« vogĂ«l kĂ«tu. ĂshtĂ« mirĂ« nĂ«se serveri i klientit vepron si klient, jo si server â domethĂ«nĂ« iniciaton, jo pranon lidhjet. Por ne do tĂ« kemi tĂ« kundĂ«rtĂ«n. NĂ« kĂ«tĂ« rast, na nevojitet destination NAT, nĂ« mĂ«nyrĂ« qĂ« kur tĂ« merrnim trafikun, nyja e kontrollit tĂ« kuptonte se ky trafik ishte pĂ«r makinĂ«n virtuale A tĂ« klientit A, dhe nĂ«nkupton qĂ« duhet tĂ« bĂ«jmĂ« NAT nga adresa e jashtme, pĂ«r shembull 100.1.1.1 nĂ« adresĂ«n e brendshme 10.0.0.1. NĂ« kĂ«tĂ« mĂ«nyrĂ«, edhe pse tĂ« gjithĂ« klientĂ«t do tĂ« pĂ«rdorin tĂ« njĂ«jtin rrjet, izolimi i brendshĂ«m mbetet plotĂ«sisht i ruajtur. Pra, na nevojitet tĂ« bĂ«jmĂ« dNAT dhe sNAT nĂ« nyjĂ«n e kontrollit. PĂ«rdorimi i njĂ« rrjeti tĂ« vetĂ«m me alokim tĂ« adresave tĂ« lira ose rrjeteve tĂ« jashtme, ose tĂ« dyja menjĂ«herĂ« â pĂ«rcaktohet nga ajo qĂ« dĂ«shironi tĂ« tĂ«rheqni nĂ« re. Ne nuk do ta shĂ«nojmĂ« diagramin me adresat e lira, por do tĂ« lĂ«mĂ« rrjetet e jashtme qĂ« janĂ« shtuar mĂ« parĂ« â çdo klient ka rrjetin e tij tĂ« jashtĂ«m (nĂ« diagram janĂ« shĂ«nuar si VLAN 100 dhe 200 nĂ« ndĂ«rfaqen e jashtme).
Përfundimisht, ne arritëm një zgjidhje interesante dhe njëkohësisht të menduar, me një fleksibilitet të caktuar, por ende pa mekanizma për qëndrueshmëri shërbimi.
SĂ« pari, kemi vetĂ«m njĂ« nod kontrolli â dĂ«shtimi i saj do tĂ« çojĂ« nĂ« rrĂ«zimin e gjithĂ« sistemeve. PĂ«r tĂ« zgjidhur kĂ«tĂ« problem, duhet tĂ« kemi sĂ« paku njĂ« shumicĂ« prej 3 nodosh. Ta shtojmĂ« kĂ«tĂ« nĂ« skemĂ«:
Natyrisht, të gjitha nodet sinkronizohen dhe kur një nod aktiv dështojnë, detyrat e saj do t'i marrë një nod tjetër.
Problemi tjetĂ«r Ă«shtĂ« disqet e makinave virtuale. Momentalisht ato ruhet nĂ« vetĂ« hipervizorĂ«t dhe nĂ«se kemi probleme me hipervizorin, ne humbasim tĂ« gjitha tĂ« dhĂ«nat â dhe prania e RAID-it kĂ«tu nuk ndihmon nĂ«se humbasim jo njĂ« disk, por tĂ«rĂ« serverin. PĂ«r kĂ«tĂ« na nevojitet njĂ« shĂ«rbim, i cili do tĂ« veprojĂ« si frontend pĂ«r ndonjĂ« depo. Cila do tĂ« jetĂ« kjo depo nuk Ă«shtĂ« shumĂ« e rĂ«ndĂ«sishme pĂ«r ne, por ajo duhet tĂ« mbrojĂ« tĂ« dhĂ«nat tona nga dĂ«shtimi i disqeve, nodit dhe mundĂ«sisht edhe tĂ«rĂ« kabinetit. Ka disa opsione kĂ«tu â sigurisht qĂ« ka rrjete SAN me Fiber Channel, por le tĂ« jemi tĂ« sinqertĂ« â FC Ă«shtĂ« tashmĂ« njĂ« vazhdimĂ«si e sĂ« kaluarĂ«s â analoge e E1 nĂ« transport â po pranoj, ende pĂ«rdoret, por vetĂ«m atje ku nuk ka mundĂ«si tjetĂ«r. Prandaj, nuk do tĂ« isha i gatshĂ«m tĂ« vendosja njĂ« rrjet FC nĂ« vitin 2020, duke ditur pĂ«r praninĂ« e alternativave mĂ« interesante. MegjithatĂ«, tĂ« gjithĂ« kanĂ« mendimin e tyre dhe ndoshta do tĂ« jenĂ« ata qĂ« mendojnĂ« se FC me tĂ« gjitha kufizimet e tij Ă«shtĂ« gjithçka qĂ« na nevojitet â nuk do tĂ« debatoj, secili ka mendimin e tij. SidoqoftĂ«, zgjidhja mĂ« interesante sipas mendimit tim Ă«shtĂ« pĂ«rdorimi i SDS, pĂ«r shembull Ceph.
Ceph lejon ndihmon në ndërtimin e një zgjidhjeje me akses të lartë për ruajtjen e të dhënave, me shumë mundësi për rezervimin, që nga kodet e kontrollit të paritetit (ngjashëm me RAID 5 ose 6) deri te replikimi i plotë i të dhënave në dysheku të ndryshëm, duke marrë parasysh vendosjen e dyshekëve në servera dhe serverëve në dollapë, etj.
Për të ndërtuar Ceph, nevojiten edhe 3 nodo. Ndërveprimi me ruajtjen do të bëhet gjithashtu përmes rrjetit duke përdorur shërbime të ruajtjes blok, objekt dhe dosje. Le të shtojmë në skemë ruajtjen:
ShĂ«nim: Ă«shtĂ« e mundur tĂ« krijoni nodet e hiper-konverguara tĂ« llogaritjes â kjo Ă«shtĂ« njĂ« koncept i bashkĂ«ndarjes sĂ« disa funksioneve nĂ« njĂ« nod â pĂ«r shembull storage+compute â pa ndarĂ« nodet speciale pĂ«r storage-in ceph. Ne do tĂ« arrijmĂ« skemĂ«n e njĂ«jtĂ« tĂ« qĂ«ndrueshmĂ«risĂ« â sepse SDS do tĂ« rezervojĂ« tĂ« dhĂ«nat me nivelin e rezervimit qĂ« ne kemi pĂ«rcaktuar. MegjithatĂ«, nodet hiper-konverguara janĂ« gjithmonĂ« njĂ« kompromis â pasi nodi i storage-it nuk thjesht ngre ajrin siç duket nĂ« shikim tĂ« parĂ« (sepse nuk ka makina virtuale mbi tĂ«) â ai shpenzon burime CPU pĂ«r tĂ« mbajtur SDS (nĂ« fakt, ai bĂ«n tĂ« gjitha replikimet, rikuperimet nga dĂ«shtimet e nodit, disqeve, etj. nĂ« sfond). Pra, do tĂ« humbisni njĂ« pjesĂ« tĂ« fuqisĂ« sĂ« nodit tĂ« llogaritjes nĂ«se e kombinoni atĂ« me storage-in.
TĂ« gjitha kĂ«to duhet tĂ« menaxhohen nĂ« njĂ« farĂ« mĂ«nyre â na nevojitet diçka pĂ«rmes sĂ« cilĂ«s mund tĂ« krijojmĂ« njĂ« makinĂ«, rrjet, router virtual, etj. PĂ«r kĂ«tĂ«, nĂ« nodin kontrollues do tĂ« shtojmĂ« njĂ« shĂ«rbim qĂ« do tĂ« veprojĂ« si dashboard â klienti mund tĂ« lidhet me kĂ«tĂ« portal pĂ«rmes http/https dhe tĂ« bĂ«jĂ« gjithçka qĂ« i nevojitet (mirĂ«, pothuajse).
Si përfundim, tani kemi një sistem të qëndrueshëm. Të gjitha elementet e kësaj infrastrukture duhet menaxhuar siç duhet. Më parë përmenda se OpenStack është një grup projektesh, secili prej të cilëve siguron një funksion të caktuar. Siç e shohim, ka shumë elementë që duhen konfiguruar dhe kontrolluar. Sot do të flasim për pjesën rrjet.
Arkitektura Neutron
Në OpenStack, pikërisht Neutron është përgjegjës për lidhjen e porteve të makinerive virtuale me rrjetin e përbashkët L2, sigurimin e ruterimit të trafikut midis VM-ve që ndodhen në rrjete të ndryshme L2 si dhe ruterimin jashtë, duke ofruar shërbime si NAT, Floating IP, DHCP, etj.
Punën në nivel të lartë të shërbimit rrjetor (pjesa bazë) mund ta përshkruajmë kështu.
Kur niset një VM, shërbimi rrjetor:
- Krijon një port për këtë VM (ose porte) dhe njofton shërbimin DHCP;
- Krijohet një pajisje rrjeti virtuale të re (përmes libvirt);
- VM-ja lidhjet me portin (portet) të krijuar në hapin 1;
Siç Ă«shtĂ« pĂ«r t'u pritur, nĂ« thelb tĂ« funksionimit tĂ« Neutron qĂ«ndrojnĂ« mekanizmat standardĂ«, tĂ« njohur pĂ«r çdo tĂ« cilin ka kaluar nĂ« Linux â kĂ«to janĂ« namespaces, iptables, bridges linux, openvswitch, conntrack etj.
Duhet të sqarojmë menjëherë se Neutron nuk është një kontrollues SDN.
Neutron përbëhet nga disa komponente të ndërlidhura me njëra-tjetrën:
openstack-neutron-server â Ă«shtĂ« njĂ« demon qĂ« punon me kĂ«rkesat e pĂ«rdoruesve pĂ«rmes API-sĂ«. Ky demon nuk merret me caktimin e ndonjĂ« lidhjeje rrjeti, por ofron informacionin e nevojshĂ«m pĂ«r plugin-at e tij, tĂ« cilĂ«t mĂ« pas konfigurojnĂ« elementin pĂ«rkatĂ«s tĂ« rrjetit. Neutron-agentĂ«t nĂ« nyjat OpenStack regjistrohen nĂ« serverin Neutron.
Neutron-server është në thelb një aplikacion i shkruar në Python, që përbëhet nga dy pjesë:
- Shërbimi REST
- Neutron Plugin (core/service)
Shërbimi REST është i destinuar për të pranuar thirrjet API nga komponentët e tjerë (për shembull, kërkesa për ofrimin e ndonjë informacioni etj.)
Plugin-t janĂ« komponente/modula tĂ« integruara qĂ« thirren gjatĂ« kĂ«rkesave API â pra, lidhja e njĂ« shĂ«rbimi ndodh pĂ«rmes tyre. Plugin-t ndahen nĂ« dy lloje â shĂ«rbim dhe bazĂ«. NĂ« pĂ«rgjithĂ«si, plugin-i bazĂ« merret kryesisht me menaxhimin e hapĂ«sirĂ«s adresuese dhe lidhjet L2 midis VM-ve, ndĂ«rsa plugin-t e shĂ«rbimit ofrojnĂ« funksionalitete shtesĂ« si VPN ose FW.
Listën e pluginëve të disponueshëm sot mund ta shihni, për shembull,
Mund të ketë disa plugina shërbimi, por plugin i bazës mund të jetë vetëm një.
Openstack-neutron-ml2 â Ă«shtĂ« plugin standard i bazĂ«s sĂ« Openstack. Ky plugin ka njĂ« arkitekturĂ« modulare (nĂ« dallim nga paraardhĂ«si i tij) dhe pĂ«rmes drejtuesve qĂ« i lidhen, konfigurimi i shĂ«rbimit rrjetisĂ« bĂ«het. Ne do ta shqyrtojmĂ« pluginin pak mĂ« vonĂ«, pasi ai nĂ« fakt ofron fleksibilitetin qĂ« ka OpenStack nĂ« pjesĂ«n e rrjetĂ«s. Plugin-i i bazĂ«s mund tĂ« zĂ«vendĂ«sohet (pĂ«r shembull, Contrail Networking bĂ«n njĂ« zĂ«vendĂ«sim tĂ« tillĂ«).
ShĂ«rbimi RPC (rabbitmq-server) â shĂ«rbimi qĂ« siguron menaxhimin e radhĂ«ve dhe ndĂ«rveprimin me shĂ«rbime tĂ« tjera tĂ« OpenStack, si dhe ndĂ«rveprimin midis agjentĂ«ve tĂ« shĂ«rbimit rrjetĂ«s.
AgjentĂ«t e rrjetit â agjentĂ«t qĂ« ndodhen nĂ« çdo nod, pĂ«rmes tĂ« cilĂ«ve bĂ«het konfigurimi i shĂ«rbimeve rrjetĂ«s.
Agjentët janë të llojeve të ndryshme.
Agjenti kryesor është agjenti L2. Këta agjentë aktivizohen në çdo hipervizor përfshirë nodet e kontrollit (më saktësisht në të gjitha nodet që ofrojnë ndonjë shërbim për qiramarrësit) dhe funksioni i tyre kryesor është lidhja e makinave virtuale me rrjetin e përbashkët L2, si dhe gjenerimi i njoftimeve kur ndodhin ngjarje të ndryshme (p.sh. fikja / ndezja e portit).
Agjenti tjetër, i cili është po aq i rëndësishëm, është agjenti L3. Si rregull, ky agjent aktivizohet ekskluzivisht në nodën e rrjetit (shpesh nodë rrjeti kombinohet me nodën e kontrollit) dhe siguron ruterizimin midis rrjeteve të qiramarrësve (si midis rrjeteve të tij dhe rrjeteve të qiramarrësve të tjerë, po ashtu si dhe aksesin në botën e jashtme, duke ofruar NAT dhe shërbimin DHCP). Megjithatë, kur përdoret DVR (ruter i shpërndarë), nevoja për plugin L3 shqiptohet gjithashtu në nodet e llogaritjes.
Agjenti L3 përdor namespace-t e Linux për të ofruar çdo qiramarrësi një grup rrjetesh të izoluar dhe funksionalitetin e ruterëve virtualë, të cilët ruterizojnë trafikun dhe ofrojnë shërbime gateway për rrjetet e Layer 2.
Baza e tĂ« dhĂ«nave â njĂ« bazĂ« tĂ« dhĂ«nash pĂ«r identifikuesit e rrjeteve, nĂ«nrrjeteve, porteve, grupeve etj.
Faktikisht, Neutron pranon kërkesat API për krijimin e entiteteve rrjetërore, autentifikon kërkesën dhe përmes RPC (nëse i drejtohet ndonjë plugin-i ose agjenti) ose REST API (nëse komunikon në SDN) përcjell agjentëve (nëpërmjet plugina) udhëzimet e nevojshme për organizimin e shërbimit të kërkuar.
Tani le të kthehemi te instalimi testues (si është vendosur dhe çfarë përmban do të shohim më vonë në pjesën praktike) dhe të shikojmë ku ndodhet çdo komponent.
(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 ~]$ 
Kjo është e gjitha struktura e Neutron. Tani është koha të kushtoni disa minuta për plugin-in ML2.
Modular Layer 2
Siç u përmend më lart, plugin-i është plugin-i standard rrënjësor i OpenStack dhe ka një arkitekturë modulare.
ParaardhĂ«si i plugin-it ML2 kishte njĂ« strukturĂ« monolitike qĂ« nuk lejonte, pĂ«r shembull, pĂ«rdorimin e njĂ« kombinimi tĂ« disa teknologjive nĂ« njĂ« instalim. PĂ«r shembull, nuk mund tĂ« pĂ«rdornit si openvswitch ashtu edhe linuxbridge njĂ«kohĂ«sisht â ose njĂ«ra ose tjetra. PĂ«r kĂ«tĂ« arsye, u krijua plugin-i ML2 me arkitekturĂ«n e tij.
ML2 ka dy komponentĂ« â dy lloje drejtuesish: Type drivers dhe Mechanism drivers.
Type drivers përcaktojnë teknologjitë që do të përdoren për organizimin e lidhjeve rrjetore, për shembull VxLAN, VLAN, GRE. Ndërkohë, drejtuesi lejon përdorimin e teknologjive të ndryshme. Teknologjia standarde është inkapsulimi VxLAN për rrjetet overlay dhe vlan për rrjetet e jashtme.
Llojet e rrjeteve që përfshihen në Type drivers janë:
Flat â rrjet pa etiketim
VLAN â rrjet i etiketuar
Local â njĂ« tip i veçantĂ« rrjeti pĂ«r instalime all-in-one (tĂ« tilla instalime janĂ« tĂ« nevojshme pĂ«r zhvilluesit ose pĂ«r mĂ«sim)
GRE â rrjet overlay, qĂ« pĂ«rdor tunel GRE
VxLAN â rrjet overlay, qĂ« pĂ«rdor tunel VxLAN
Mechanism drivers pĂ«rcaktojnĂ« mjetet qĂ« sigurojnĂ« organizimin e teknologjive tĂ« caktuara nĂ« type driver â pĂ«r shembull, openvswitch, sr-iov, opendaylight, OVN etj.
Në varësi të implementimit të këtij drivere do të përdoren ose agjentë të menaxhuar nga Neutron, ose do të përdoren lidhje me një kontrollues SDN të jashtëm, i cili merr përsipër të gjitha çështjet lidhur me organizimin e rrjeteve L2, drejtimin etj.
PĂ«r shembull, nĂ«se pĂ«rdorim ML2 sĂ« bashku me OVS, atĂ«herĂ« nĂ« çdo nyje llogaritĂ«se instalohet njĂ« agjent L2, i cili menaxhon OVS. MegjithatĂ«, nĂ«se pĂ«rdorim, pĂ«r shembull, OVN ose OpenDayLight, atĂ«herĂ« menaxhimi i OVS kalon nĂ«n juridiksionin e tyre â Neutron pĂ«rmes plugin-it rrĂ«njĂ«sor i jep urdhra kontrolluesit, dhe ai bĂ«n atĂ« qĂ« i Ă«shtĂ« thĂ«nĂ«.
Le të freskojmë kujtesën për Open vSwitch
Në këtë moment, një nga komponentët kyç të OpenStack është Open vSwitch.
Kur gjatë instalimit të OpenStack pa ndonjë SDN të mëtejshëm nga furnizues si Juniper Contrail ose Nokia Nuage, OVS është komponenti kryesor i rrjetit të cloud dhe, në kombinim me iptables, conntrack, namespaces, mundëson organizimin e rrjeteve të plota overlay me multitenancy. Natyrisht, ky komponent mund të zëvendësohet, për shembull, kur përdoren zgjidhje SDN të treta ose pronësore.
OVS është një switch softuerik me kod të hapur, i destinuar për t'u përdorur në mjedise virtualizimi si një përparues virtual i trafikut.
Aktualisht, OVS ka një funksionalitet të konsiderueshëm, i cili përfshin teknologji si QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK dhe të tjera.
Vërejtje: fillimisht OVS nuk ishte menduar si një switch softuerik për funksione telekomunikacionesh me ngarkesë të lartë dhe ishte më shumë i përshtatur për funksione IT më pak të kërkueshme për kalimin e të dhënave si serverat WEB ose serverat e postës. Megjithatë, OVS po përmirësohet dhe realizimet aktuale të OVS kanë përmirësuar ndjeshëm performancën dhe kapacitetet e tij, që lejon përdorimin e tij nga operatorët e komunikimeve për funksione me ngarkesë të lartë; për shembull, ekziston një implementim i OVS me mbështetje për DPDK.
Ekzistojnë tri componente të rëndësishme të OVS, për të cilat është e nevojshme të dihet:
- Moduli i kernelit â komponenti i vendosur nĂ« hapĂ«sirĂ«n e kernelit, i cili pĂ«rpunon trafikun mbi bazĂ«n e rregullave tĂ« marra nga elementi menaxhues;
- vSwitch daemon (ovs-vswitchd) â Ă«shtĂ« njĂ« proces i filluar nĂ« hapĂ«sirĂ«n e pĂ«rdoruesit, qĂ« Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r programimin e modulit tĂ« kernelit â domethĂ«nĂ« pĂ«rfaqĂ«son logjikĂ«n e punĂ«s sĂ« switch-it.
- Serveri i bazĂ«s sĂ« tĂ« dhĂ«nave â njĂ« bazĂ« tĂ« dhĂ«nash lokale, e vendosur nĂ« çdo host ku Ă«shtĂ« e instaluar OVS, nĂ« tĂ« cilĂ«n ruhet konfigurimi. PĂ«rmes kĂ«tij moduli, kontrollorĂ«t SDN mund tĂ« komunikojnĂ« me protokollin OVSDB.
Përveç kësaj, ofrohet një grup mjetesh diagnostikuese dhe menaxhuese, si ovs-vsctl, ovs-appctl, ovs-ofctl etj.
Aktualisht, Openstack po pĂ«rdoret gjerĂ«sisht nga operatorĂ«t e telekomunikacionit pĂ«r tĂ« migruar funksionet rrjetĂ«rore, si EPC, SBC, HLR etj. Disa funksione mund tĂ« jetojnĂ« pa probleme me OVS ashtu si Ă«shtĂ«, por pĂ«r shembull, EPC pĂ«rpunon trafik tĂ« abonentĂ«ve â pra kalon nĂ«pĂ«r tĂ« njĂ« sasi tĂ« madhe trafik (aktualisht, volumet e trafikut arrijnĂ« disa qindra gigabite nĂ« sekondĂ«). Natyrisht, dĂ«rgimi i njĂ« trafiku tĂ« tillĂ« pĂ«rmes hapĂ«sirĂ«s sĂ« bĂ«rthamĂ«s (pasi pĂ«r default, pĂ«rparuesi ndodhet atje) â nuk Ă«shtĂ« ideja mĂ« e mirĂ«. Prandaj, shpesh OVS vendoset krejtĂ«sisht nĂ« hapĂ«sirĂ«n e pĂ«rdoruesit duke pĂ«rdorur teknologjinĂ« e pĂ«rshpejtimit DPDK pĂ«r tĂ« kaluar trafikun nga NIC nĂ« hapĂ«sirĂ«n e pĂ«rdoruesit duke anashkaluar bĂ«rthamĂ«n.
Shënim: për cloud-in e vendosur për funksionet e telekomit, ekziston mundësia për të dërguar trafikun nga nodi compute duke anashkaluar OVS direkt në pajisjet e komutimit. Për këtë qëllim përdoren mekanizmat SR-IOV dhe Passthrough.
Si funksionon në një model të vërtetë?
Tani, le të kalojmë në pjesën praktike dhe të shohim si funksionon gjithçka në praktikë.
SĂ« pari, do tĂ« nisim me njĂ« instalim tĂ« thjeshtĂ« tĂ« Openstack. Duke qenĂ« se nuk kam nĂ« dispozicion njĂ« grup serverash pĂ«r eksperimente, do tĂ« krijojmĂ« njĂ« model mbi njĂ« server fizike pĂ«rmes makinave virtuale. Po, natyrisht qĂ« njĂ« zgjidhje e tillĂ« nuk Ă«shtĂ« e pĂ«rshtatshme pĂ«r qĂ«llime komerciale, por pĂ«r tĂ« parĂ« se si funksionon rrjeti nĂ« Openstack, ky instalim Ă«shtĂ« mĂ« thane i mjaftueshĂ«m. PĂ«r mĂ« tepĂ«r, njĂ« instalim i tillĂ« pĂ«r qĂ«llime mĂ«simore Ă«shtĂ« edhe mĂ« interesante â pasi mund tĂ« kapim trafikun etj.
Duke qenĂ« se na nevojitet tĂ« shohim vetĂ«m pjesĂ«n bazĂ«, ne mund tĂ« mos pĂ«rdorim disa rrjete dhe t'i ngremĂ« tĂ« gjitha me vetĂ«m dy rrjete, pĂ«r mĂ« tepĂ«r rrjeti i dytĂ« nĂ« kĂ«tĂ« model do tĂ« pĂ«rdoret vetĂ«m pĂ«r qasje nĂ« serverin undercloud dhe nĂ« serverin dns. Rrjetet e jashtme nuk do t'i prekim pĂ«r momentin â kjo Ă«shtĂ« njĂ« temĂ« pĂ«r njĂ« artikull tĂ« madh tĂ« veçantĂ«.
Pra tĂ« fillojmĂ«, le tĂ« shohim ndonjĂ« teori. Do tĂ« instalojmĂ« OpenStack duke pĂ«rdorur TripleO (OpenStack mbi OpenStack). QĂ«llimi i TripleO Ă«shtĂ« qĂ« ne instalojmĂ« OpenStack all-in-one ( qĂ« do tĂ« thotĂ« nĂ« njĂ« nodĂ«), e quajtur undercloud, dhe mĂ« pas pĂ«rdorim kapacitetin e OpenStack tĂ« vendosur pĂ«r tĂ« instaluar OpenStack qĂ« Ă«shtĂ« e destinuar pĂ«r operimin, e quajtur overcloud. Undercloud do tĂ« pĂ«rdorĂ« funksionalitetin e integruar pĂ«r menaxhimin e serverĂ«ve fizikĂ« (bare metal) â projekti Ironic â pĂ«r tĂ« provizionuar hipervizorĂ«t qĂ« do tĂ« kryejnĂ« rolet e nodave compute, control, dhe storage. Pra, ne nuk pĂ«rdorim asnjĂ« mjet tĂ« jashtĂ«m pĂ«r tĂ« vendosur OpenStack â ne e vendosim OpenStack me ndihmĂ«n e OpenStack. NdĂ«rsa pĂ«rparojmĂ« nĂ« procesin e instalimit, do tĂ« bĂ«het mĂ« e qartĂ«, prandaj le tĂ« ecim pĂ«rpara.
ShĂ«nim: NĂ« kĂ«tĂ« artikull, pĂ«r thjeshtĂ«si, nuk pĂ«rdora izolimin e rrjetit pĂ«r rrjetet interne tĂ« Openstack, dhe gjithçka Ă«shtĂ« vendosur duke pĂ«rdorur vetĂ«m njĂ« rrjet. MegjithatĂ«, prania ose mungesa e izolimit tĂ« rrjeteve nuk ndikon nĂ« funksionalitetin bazĂ« tĂ« zgjidhjes â gjithçka do tĂ« funksionojĂ« pikĂ«risht ashtu si me pĂ«rdorimin e izolimit, por trafiku do tĂ« kalojĂ« nĂ« njĂ« rrjet. PĂ«r njĂ« instalim tregtar, natyrisht, Ă«shtĂ« e nevojshme tĂ« pĂ«rdoret izolimi me pĂ«rdorimin e VLAN-ve dhe ndĂ«rfaqeve tĂ« ndryshme. PĂ«r shembull, trafiku i menaxhimit tĂ« magazinĂ«s Ceph dhe trafiku i tĂ« dhĂ«nave (aksesi i makinave nĂ« disqe etj.) nĂ« rastin e izolimit pĂ«rdorin nĂ«nrrjete tĂ« ndryshme (Menaxhimi i magazinĂ«s dhe Magazinimi) dhe kjo lejon qĂ« zgjidhja tĂ« jetĂ« mĂ« e qĂ«ndrueshme, duke ndarĂ« kĂ«tĂ« trafik, pĂ«r shembull, nĂ« porta tĂ« ndryshme, ose duke pĂ«rdorur profile tĂ« ndryshme QoS pĂ«r trafik tĂ« ndryshĂ«m, nĂ« mĂ«nyrĂ« qĂ« trafiku i tĂ« dhĂ«nave tĂ« mos shtyjĂ« trafikun sinjal. NĂ« rastin tonĂ«, ata do tĂ« kalojnĂ« nĂ« tĂ« njĂ«jtin rrjet dhe nĂ« thelb, kjo nuk na limiton fare.
Shënim: Duke qenë se do të nisim makina virtuale në një mjedis virtual që bazohet në makina virtuale, fillimisht duhet të aktivizojmë virtualizimin nested.
Mund ta kontrolloni nëse virtualizimi nested është aktivizuar ose jo kështu:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Nëse shihni shkronjën N, atëherë aktivizoni mbështetje për virtualizimin nested sipas ndonjë udhëzimi që gjeni në internet, për shembull .
Na nevojitet të krijojmë një skemë të tillë me makina virtuale:
Në rastin tim, për lidhjen e makinave virtuale që janë pjesë e instalimit të ardhshëm (dhe kam 7 në total, por mund të shkoni me 4 nëse nuk keni shumë burime), kam përdorur OpenvSwitch. Kam krijuar një mostër ovs dhe i kam lidhur ato nëpërmjet grupeve të porteve. Për këtë krijova një skedar xml me formatin e mëposhtëm:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67KĂ«tu janĂ« shpallur tre grupe portesh â dy access dhe njĂ« trunk (e fundit ishte e nevojshme pĂ«r serverin DNS, por mund tĂ« kalohen pa tĂ«, ose ta ngrini nĂ« makinĂ«n pritĂ«se â si ju pĂ«rshtatet mĂ« mirĂ«). MĂ« pas, me kĂ«tĂ« shabllon shpallim rrjetin tonĂ« pĂ«rmes virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Tani rregullojmë konfigurimet e porteve të hipervizorit:
[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 ~]# ShĂ«nim: nĂ« kĂ«tĂ« skenar, adresa nĂ« portin ovs-br1 nuk do tĂ« jetĂ« e disponueshme, pasi nuk ka njĂ« tag VLAN. PĂ«r ta rregulluar kĂ«tĂ«, duhet tĂ« jepni komandĂ«n sudo ovs-vsctl set port ovs-br1 tag=100. MegjithatĂ«, pas rinisjes, ky tag do tĂ« zhduket (nĂ«se ndokush di si ta mbani atĂ« nĂ« vend â do tĂ« isha shumĂ« mirĂ«njohĂ«s). Por kjo nuk Ă«shtĂ« aq e rĂ«ndĂ«sishme, pasi kjo adresĂ« do na nevojitet vetĂ«m gjatĂ« instalimit dhe nuk do tĂ« jetĂ« e nevojshme kur OpenStack tĂ« jetĂ« e pĂ«rfunduar.
Më pas krijojmë makinën undercloud:
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=ttyS0GjatĂ« instalimit, vendosni tĂ« gjitha parametrat e nevojshĂ«m, si emri i makinĂ«s, fjalĂ«kalimet, pĂ«rdoruesit, serverat NTP, etj., mund tĂ« konfiguroni edhe portet menjĂ«herĂ«, por personalisht mĂ« duket mĂ« e lehtĂ« tĂ« hyj nĂ« makinĂ« pĂ«rmes konsolĂ«s pas instalimit dhe tĂ« rregulloj dosjet e nevojshme. NĂ«se tashmĂ« keni njĂ« imazh tĂ« gatshĂ«m, mund ta pĂ«rdorni atĂ« ose tĂ« veproni si unĂ« â shkarkoni njĂ« imazh minimal tĂ« CentOS 7 dhe pĂ«rdorni atĂ« pĂ«r tĂ« instaluar VM.
Pas instalimit të suksesshëm, duhet të keni një makinë virtuale në të cilën mund të vendosni undercloud.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningSë pari, vendosim mjetet e nevojshme gjatë procesit të instalimit:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instalimi i Undercloud
Krijojmë përdoruesin stack, caktojmë fjalëkalimin, e shtojmë në sudoer dhe i japim mundësinë të ekzekutojë komandat root përmes sudo pa pasur nevojë të fusë fjalëkalimin:
useradd stack
passwd stack
echo âstack ALL=(root) NOPASSWD:ALLâ > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackTani, caktuam emrin e plotë të undercloud në skedarin hosts:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Më pas, shtojmë repository-t dhe instalojmë softin e nevojshëm:
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-ansibleShënim: nëse nuk planifikoni të instaloni ceph, nuk keni nevojë të futni komandat e lidhura me ceph. Unë përdora versionin Queens, por ju mund të përdorni çdo version tjetër që ju pëlqen.
Më pas kopjojmë skedarin e konfigurimit undercloud në direktorinë shtëpiake të përdoruesit stack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confTani është e nevojshme të rregullojmë këtë skedar, duke e përshtatur atë me instalimin tonë.
Në fillim të skedarit duhet të shtojmë këto rreshta:
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 = 10Pra, le të shkojmë përmes konfigurimeve:
undercloud_hostname â emri i plotĂ« i serverit undercloud, duhet tĂ« pĂ«rputhet me regjistrimin nĂ« serverin DNS
local_ip â adresa lokale e undercloud-it nĂ« drejtim tĂ« rrjetit tĂ« provizionimit
network_gateway â e njĂ«jta adresĂ« lokale, e cila do tĂ« shĂ«rbejĂ« si gateway pĂ«r qasje nĂ« botĂ«n e jashtme gjatĂ« instalimit tĂ« node-ve overcloud, gjithashtu pĂ«rputhet me ip-nĂ« lokale
undercloud_public_host â adresa e jashtme e API-t, caktohet çdo adresĂ« e lirĂ« nga rrjeti i provisioning-ut
undercloud_admin_host adresa e brendshme e API-t, caktohet çdo adresë e lirë nga rrjeti i provisioning-ut
undercloud_nameservers â serveri DNS
generate_service_certificate â ky rresht Ă«shtĂ« shumĂ« i rĂ«ndĂ«sishĂ«m nĂ« kĂ«tĂ« shembull, pasi nĂ«se nuk e vendosni nĂ« vlerĂ«n false do tĂ« merrni njĂ« gabim gjatĂ« instalimit, problemi Ă«shtĂ« i pĂ«rshkruar nĂ« bug tracker-in e Red Hat
local_interface interfaci nĂ« rrjetin e provisioning-ut. Ky interfaci do tĂ« ri-konfigurohet gjatĂ« zbatimit tĂ« undercloud, prandaj nĂ« undercloud duhet tĂ« ketĂ« dy interfaca â njĂ« pĂ«r qasje nĂ« tĂ«, tjetri pĂ«r provisioning
local_mtu â MTU. Duke qenĂ« se kemi njĂ« laborator testimi dhe MTU-ja ime Ă«shtĂ« 1500 nĂ« portet e switch-it OVS, duhet ta vendosim nĂ« vlerĂ«n 1450, nĂ« mĂ«nyrĂ« qĂ« tĂ« kalojnĂ« paketat e inkapsuluara nĂ« VxLAN
network_cidr â rrjeti i provisioning-ut
masquerade â pĂ«rdorimi i NAT pĂ«r qasje nĂ« rrjetin e jashtĂ«m
masquerade_network â rrjeti qĂ« do tĂ« NAT-zohet
dhcp_start â adresa fillestare e pool-it tĂ« adresave, nga e cila do tĂ« caktohen adresat pĂ«r nodet gjatĂ« shpĂ«rndarjes sĂ« overcloud
dhcp_end â adresa pĂ«rfundimtare e pool-it tĂ« adresave, nga e cila do tĂ« caktohen adresat pĂ«r nodet gjatĂ« shpĂ«rndarjes sĂ« overcloud
inspection_iprange â grupi i adresave qĂ« nevojiten pĂ«r kryerjen e introspeksionit (nuk duhet tĂ« pĂ«rputhet me grupin e sipĂ«rpĂ«rmendur)
scheduler_max_attempts â numri maksimal i pĂ«rpjekjeve pĂ«r tĂ« instaluar overcloud (duhet tĂ« jetĂ« mĂ« i madh ose i barabartĂ« me numrin e nodave)
Pasi që skedari të jetë përshkruar, mund të jepni urdhër për të bërë deploy undercloud:
openstack undercloud install
Procedura zgjat nga 10 deri në 30 minuta në varësi të harduerit tuaj. Në fund, duhet të shihni këtë dalje:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Instalimi i undercloud përfundoi.
Skedari që përmban fjalëkalimet për këtë instalim është në
/home/stack/undercloud-passwords.conf.
Ka gjithashtu një skedë stackrc në /home/stack/stackrc.
Këta skedarë janë të nevojshëm për të ndërvepruar me shërbimet e OpenStack, dhe duhet të sigurohen.
#############################################################################Kjo dalje tregon se keni instaluar me sukses undercloud dhe tani mund të kontrolloni statusin e undercloud dhe të kaloni në instalimin e overcloud.
Nëse shihni daljen e ifconfig, do të shihni se është shfaqur një ndërfaqe bridge e re
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163 mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Përmes këtij interfejsi tani do të realizohet puna për implementimin e overcloud.
Nga dalja e mëposhtme shihet se të gjitha shërbimet janë në një nodë:
(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 |
+--------------------------+-----------+----------+Më poshtë është treguar konfigurimi i pjesës rrjetësore të undercloud:
(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 ~]$Instalimi i overcloud
Aktualisht kemi vetĂ«m undercloud, dhe na mungojnĂ« nodet nga tĂ« cilat do tĂ« krijohet overcloud. Prandaj, si hapin e parĂ« do tĂ« vendosim makinat virtuale qĂ« na nevojiten. GjatĂ« implementimit, undercloud do tĂ« instalohet sistemi operativ dhe programet e nevojshme nĂ« makinat e overcloud â qĂ« do tĂ« thotĂ« se nuk Ă«shtĂ« e nevojshme tĂ« vendosim plotĂ«sisht njĂ« makinĂ«, por vetĂ«m tĂ« krijojmĂ« njĂ« disk (ose disqe) pĂ«r tĂ« dhe tĂ« pĂ«rcaktojmĂ« parametrat e saj â qĂ« nĂ« thelb kemi njĂ« server tĂ« pastĂ«r pa njĂ« sistem operativ tĂ« instaluar mbi tĂ«.
Shkoni në dosjen me disqet e makinave tona virtuale dhe do të krijojmë disqet me volumin e nevojshëm:
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 160GDuke veprimi nga përdoruesi root, duhet të ndryshojmë pronarin e këtyre disqeve për të shmangur problemin me të drejtat:
[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]# Shënim: nëse nuk planifikoni të instaloni ceph për qëllime studimi, atëherë mos krijoni të paktën 3 nodet me të paktën dy disqe, dhe në template tregoni që do të përdoren disqet virtuale vda, vdb etj.
Shumë mirë, tani na nevojitet të identifikojmë të gjitha këto makina:
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 NĂ« fund, ka komanda âprint-xml > /tmp/storage-1.xml, e cila krijon njĂ« skedĂ« xml me pĂ«rshkrimin e çdo makine nĂ« dosjen /tmp/, nĂ«se nuk e shtoni, nuk do tĂ« jeni nĂ« gjendje tĂ« identifikoni makinat virtuale.
Tani na nevojitet që të përcaktojmë të gjitha këto makina në 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 ~]#Tani njĂ« detaj i vogĂ«l â tripleO pĂ«rdor IPMI pĂ«r tĂ« menaxhuar serverĂ«t gjatĂ« instalimit dhe introspeksionit.
Introspeksioni Ă«shtĂ« procesi i inspektimit tĂ« harduerit pĂ«r tĂ« marrĂ« parametrat e tij, tĂ« nevojshĂ«m pĂ«r provizionimin e mĂ«vonshĂ«m tĂ« nodĂ«ve. Introspeksioni kryhet me ndihmĂ«n e ironic â shĂ«rbim i destinuar pĂ«r tĂ« punuar me serverĂ« bare metal.
Por dĂ«met e serverĂ«ve fizikĂ« IPMI Ă«shtĂ« njĂ« port i veçantĂ« (ose njĂ« port i ndarĂ«, por kjo nuk ka shumĂ« rĂ«ndĂ«si), nĂ« serverat virtual tĂ« tillĂ« portet nuk ekzistojnĂ«. KĂ«tu na ndihmon njĂ« rregullim i quajtur vbmc â njĂ« mjet qĂ« lejon tĂ« emulojmĂ« portin IPMI. Ky detaj Ă«shtĂ« veçanĂ«risht i rĂ«ndĂ«sishĂ«m pĂ«r ata qĂ« duan tĂ« krijojnĂ« njĂ« laborator nĂ« hiperdistributorin ESXI â natyrisht, nuk e di nĂ«se ka njĂ« analog tĂ« vbmc atje, prandaj Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« merren parasysh kĂ«to çështje para se tĂ« filloni implantimin.
Instalojmë vbmc:
yum install python2-virtualbmcNëse sistemi juaj operativ nuk mund të gjejë paketën, shtoni depozitën:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmTani konfiguroni këtë mjet. Këtu është gjithçka tepër e thjeshtë. Tani është logjike që në listën e vbmc nuk ka serverë të shumtë
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Për t'i bërë ata të paraqiten duhet t'i shpallni me dorë si më poshtë:
[root@hp-gen9 ~]# vbmc shtoj control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc shtoj storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc shtoj storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc shtoj compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc shtoj compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc lista
+-------------+--------+---------+------+
| Emri i domenit | Statusi | Adresa | Port |
+-------------+--------+---------+------+
| compute-1 | poshtë | :: | 7004 |
| compute-2 | poshtë | :: | 7005 |
| control-1 | poshtë | :: | 7001 |
| storage-1 | poshtë | :: | 7002 |
| storage-2 | poshtë | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Mendoj se sintaksa e komandĂ«s Ă«shtĂ« e kuptueshme edhe pa shpjegime. MegjithatĂ«, aktualisht tĂ« gjitha sesionet tona janĂ« nĂ« statusin POSHTĂ. PĂ«r t'i kaluar ato nĂ« statusin SIP, duhet t'i aktivizojmĂ«:
[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 ~]#Dhe që duhet të bëjmë është të rregullojmë rregullat e firewall-it (apo ta çaktivizojmë plotësisht):
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
Tani të hyjmë në undercloud dhe të kontrollojmë nëse gjithçka funksionon. Adresa e makinës host është 192.168.255.200, në undercloud kemi shtuar paketën e nevojshme ipmitool gjatë përgatitjes për implementimin:
[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 runningSi e shihni, ne kemi aktivizuar me sukses nodën kontrolli përmes vbmc. Tani do ta fikim atë dhe do të vazhdojmë:
[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 ~]#Hapi tjetër është introspektimi i nodëve, në të cilat do të instalojmë overcloud. Për këtë, na nevojitet të përgatitim një skedë json me përshkrimin e nodëve tona. Vini re se, ndryshe nga instalimi në serverë të pastruar, në skedë tregohet porta në të cilën është aktivizuar vbmc për secilin nga makinat.
[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:27Shënim: në nodën e kontrollit ka dy interfesa, por në këtë rast kjo nuk është e rëndësishme, në këtë instalim mjafton dhe një.
Tani po përgatisim skedarin json. Na nevojitet të specifikojmë adresën MAC të portit, përmes të cilit do të bëhet provizioni, parametrat e nodave, t'u japim emra dhe të përcaktojmë si të arrijmë në ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"kontroll-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":"ruajtja-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":"ruajtja-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":"llogaritje-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":"llogaritje-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Tani duhet të përgatisim imazhet për ironic. Për këtë, i shkarkojmë ato përmes wget dhe i instalojmë:
(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 ~]$Po ngarkojmë imazhet në undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Imazhi "overcloud-full-vmlinuz" u ngarkua.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Emri | Formati i Diskut | Shkalla | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | aktiv |
+--------------------------------------+------------------------+-------------+---------+--------+
Imazhi "overcloud-full-initrd" u ngarkua.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Emri | Formati i Diskut | Shkalla | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | aktiv |
+--------------------------------------+-----------------------+-------------+----------+--------+
Imazhi "overcloud-full" u ngarkua.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Emri | Formati i Diskut | Shkalla | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | aktiv |
+--------------------------------------+----------------+-------------+------------+--------+
Imazhi "bm-deploy-kernel" u ngarkua.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Emri | Formati i Diskut | Shkalla | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | aktiv |
+--------------------------------------+------------------+-------------+---------+--------+
Imazhi "bm-deploy-ramdisk" u ngarkua.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Emri | Formati i Diskut | Shkalla | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | aktiv |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Kontrollojmë që të gjitha imazhet janë ngarkuar
(në nënqendër) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Emri | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aktiv |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | aktiv |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | aktiv |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | aktiv |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktiv |
+--------------------------------------+------------------------+--------+
(nĂ« nĂ«nqendĂ«r) [stack@undercloud ~]$NjĂ« detaj tjetĂ«r â duhet tĂ« shtojmĂ« serverin dns:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Emri | Rrjeti | NĂ«nrrjeti |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| 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
+-------------------+-----------------------------------------------------------+
| Fusha | Vlera |
+-------------------+-----------------------------------------------------------+
| pools_allocimi | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0\/24 |
| krijuar_ne | 2020-08-13T20:10:37Z |
| përshkrimi | |
| dns_nameservers | |
| enable_dhcp | E vërtetë |
| gateway_ip | 192.168.255.1 |
| rrugët_e_shtëpis | destination='169.254.169.254\/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| modalitet_ipv6 | Asnjë |
| modalitet_ra_ipv6 | Asnjë |
| emri | ctlplane-subnet |
| id_rrjeti | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| gjatësi_prefiksi | Asnjë |
| id_projekti | a844ccfcdb2745b198dde3e1b28c40a3 |
| numri_revisionit | 0 |
| id_segmenti | Asnjë |
| llojet_e_shërbimeve| |
| id_nënrrjeti | Asnjë |
| etiketat | |
| përditësuar_ne | 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 është e deprecated dhe do të hiqet në të ardhmen. Përdorni openstack CLI në vend.
Nënrrjeti i përditësuar: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Tani tani mund të japim urdhërin për introspektim:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Filloi Mistral Workflow tripleo.baremetal.v1.register_or_update. ID ekzekutimi: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Po presim mesazhe në radhën 'tripleo' pa kufizim.
5 nodë(e) u kaluan me sukses në gjendjen "e menaxhueshme".
Me sukses u regjistrua nodi UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Me sukses u regjistrua nodi UUID b89a72a3-6bb7-429a-93bc-48393d225838
Me sukses u regjistrua nodi UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Me sukses u regjistrua nodi UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Me sukses u regjistrua nodi UUID 766ab623-464c-423d-a529-d9afb69d1167
Po presim që introspektimi të përfundojë...
Filloi Mistral Workflow tripleo.baremetal.v1.introspect. ID ekzekutimi: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Po presim mesazhe në radhën 'tripleo' pa kufizim.
Introspektimi i nodit b89a72a3-6bb7-429a-93bc-48393d225838 përfundoi. Statusi: SUKSES. Gabime: Asnjë
Introspektimi i nodit 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e përfundoi. Statusi: SUKSES. Gabime: Asnjë
Introspektimi i nodit bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 përfundoi. Statusi: SUKSES. Gabime: Asnjë
Introspektimi i nodit 766ab623-464c-423d-a529-d9afb69d1167 përfundoi. Statusi: SUKSES. Gabime: Asnjë
Introspektimi i nodit b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 përfundoi. Statusi: SUKSES. Gabime: Asnjë
Më në fund, 5 nodë(e) u introspektuan me sukses.
Filloi Mistral Workflow tripleo.baremetal.v1.provide. ID ekzekutimi: f5594736-edcf-4927-a8a0-2a7bf806a59a
Po presim mesazhe në radhën 'tripleo' pa kufizim.
5 nodë(e) u kaluan me sukses në gjendjen "të disponueshme".
(undercloud) [stack@undercloud ~]$Siç duket nga daljeja, gjithçka përfundoi pa gabime. Le të kontrollojmë se të gjitha nodet janë në gjendjen e disponueshme:
(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 ~]$ Nëse nodet janë në një gjendje tjetër, zakonisht 'manageable', atëherë diçka ka shkuar keq dhe duhet të shikoni logun për të kuptuar pse ndodhi kështu. Kujtojeni që në këtë skenar po përdorim virtualizimin dhe mund të ketë gabime që lidhen me përdorimin e makinave virtuale ose vbmc.
MĂ« pas, na nevojitet tĂ« saktĂ«sojmĂ« se cila nodĂ« do tĂ« kryejĂ« cilĂ«n funksion â domethĂ«nĂ« tĂ« pĂ«rcaktojmĂ« profilin me tĂ« cilin do tĂ« deplojohet nodi:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | disponible | Asnjë | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | disponible | Asnjë | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | disponible | Asnjë | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | disponible | Asnjë | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | disponible | Asnjë | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Emri | RAM | Disk | Ephemeral | VCPUs | ĂshtĂ« Publik |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | Po |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | Po |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | Po |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | Po |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | Po |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | Po |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Specifikoni profilin për çdo nodë:
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-d9afb69d1167Kontrollojmë që të gjitha kanë dalë saktë:
(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 ~]$Nëse gjithçka është saktë, jepni komandën për të dërguar 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 qemuNĂ« njĂ« instalim real, natyrisht do tĂ« pĂ«rdoren template tĂ« personalizuara, nĂ« rastin tonĂ« kjo do ta komplikonin shumĂ« procesin, pasi do tĂ« duhej tĂ« shpjegohej çdo ndryshim nĂ« template. Siç u pĂ«rmend mĂ« herĂ«t â njĂ« instalim i thjeshtĂ« do tĂ« ishte i mjaftueshĂ«m pĂ«r tĂ« parĂ« se si funksionon.
ShĂ«nim: variabla âlibvirt-type qemu nĂ« kĂ«tĂ« rast Ă«shtĂ« e nevojshme, pasi do tĂ« pĂ«rdorim virtualizim tĂ« nĂ«nkuptuar. NĂ« tĂ« kundĂ«rt, makinat virtuale nuk do tĂ« startojnĂ«.
Tani keni rreth një orë, ndoshta edhe më shumë (varet nga kapacitetet e harduerit) dhe duhet të shpresoni se pas përfundimit të kësaj kohe do të shihni këtë mesazh:
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 ~]$Tani tani, tani tani, tani tani, tani tani, tani tani.
Le tĂ« verifikojmĂ« nĂ«se gjithçka funksionon normalisht. NĂ« direktorinĂ« e shtĂ«pisĂ« sĂ« pĂ«rdoruesit stack ka dy skedare â njĂ« stackrc (pĂ«r menaxhimin e undercloud) dhe tjetri overcloudrc (pĂ«r menaxhimin e overcloud). KĂ«to skedare duhet tĂ« specifikohen si source, pasi pĂ«rmbajnĂ« informacionin e nevojshĂ«m pĂ«r autentifikim.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Emri | Status | Rrjetet | Imazhi | Shija |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | AKTIV | ctlplane=192.168.255.15 | overcloud-full | kontroll |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | AKTIV | ctlplane=192.168.255.26 | overcloud-full | kompjuter |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | AKTIV | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | AKTIV | ctlplane=192.168.255.19 | overcloud-full | kompjuter |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | AKTIV | 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 | Emri |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | shërbim |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Lloji i Agentit | Host | Zona e Disponueshmërisë | Gjallë | Shteti | Binar |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | agent Open vSwitch | overcloud-novacompute-1.localdomain | Asnjë | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | agjent L3 | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | agjent DHCP | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | agent Open vSwitch | overcloud-novacompute-0.localdomain | Asnjë | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | agent Open vSwitch | overcloud-controller-0.localdomain | Asnjë | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | agjent Metadata | overcloud-controller-0.localdomain | Asnjë | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Në instalimin tim, kërkohet edhe një detaj i vogël - të shtoj një rrugë në kontrollues, pasi makina me të cilën po punoj është në një rrjet tjetër. Për këtë, do të lidhim në control-1 me akountin heat-admin dhe do të shkruajmë rrugën.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Hyrja e fundit: Fri Aug 14 09:47:40 2020 nga 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.254Tani mund të hyni në horizont. Të gjitha informacionet - adresat, emri i përdoruesit dhe fjasht e kalimit - ndodhen në skedarin /home/stack/overcloudrc. Schemi përfundimtar duket si më poshtë:
Për t'ju thënë të vërtetën, në instalimin tonë adresat e makinave u merren përmes DHCP dhe siç e shihni, ato jepen 'rastësisht'. Mund të përcaktoni saktësisht, në template, cilës adresë duhet t'i ngjitet çdo makine gjatë ndërlidhjes, nëse e keni të nevojshme.
Si kalon trafik të dhënash mes makinave virtuale?
Në këtë artikull do të shqyrtojmë tre variante të kalimit të trafikut.
- Dy makina në një hipervizor në një rrjet L2 të njëjtë.
- Dy makina në hipervizorë të ndryshëm në një rrjet L2 të njëjtë.
- Dy makina në rrjete të ndryshme (routing midis rrjeteve).
Rastele me ndihmojë të shohim se si të dalim në botën e jashtme përmes rrjetit external, duke përdorur adresa të lundrueshme, si dhe ruterizimin e shpërndarë. Për momentin, le të ndalemi te trafiku internal.
Për të verifikuar, do të grumbullojmë këtë diagram:
Kemi krijuar 4 makina virtuale â 3 nĂ« tĂ« njĂ«jtin rrjet L2 â net-1, dhe njĂ« tjetĂ«r nĂ« rrjetin net-2.
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Emri | ID i Qirasë | Statusi | Shteti i Detyrës | Shteti i Energjisë | Rrjetet |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | Po funksionon | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | Po funksionon | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | Po funksionon | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | Po funksionon | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Të shohim se në cilat hipervizorë janë vendosur makinat e krijuara:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 | (overcloud) [stack@undercloud ~]$
Makinat vm-1 dhe vm-3 ndodhen në compute-0, makinave vm-2 dhe vm-4 iu takon nodës compute-1.
Për më tepër, është krijuar një router virtual për mundësinë e routing-ut midis rrjeteve të cituara:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Emri | Status | Shteti | Distribuar | HA | Projekti |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | AKTIV | LART | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Routeri ka dy porte virtuale, të cilat shërbejnë si gateway për rrjetet:
(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 ~]$ Por para se të shohim si kalon trafiku, le të shqyrtojmë se çfarë kemi aktualisht në nodën e kontrollit (e cila gjithashtu është nodë rrjeti) dhe në nodën e kompjuterit. Le të fillojmë me nodën e kompjuterit.
[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 ~]$Aktualisht në nodë ka tri OVS bridge - br-int, br-tun, br-ex. Ndërmjet tyre, siç shohim, ka një grup ndërfaqesh. Për thjeshtësinë e perceptimit do t'i përshkruajmë të gjitha këto ndërfaqe në një skemë dhe do të shqyrtojmë se çfarë rezultati do të dalë.
Nga adresat ku janë ngritur tunelët VxLAN, duket se një tunel është ngritur në compute-1 (192.168.255.26), ndërsa tuneli tjetër është drejtuar ndaj control-1 (192.168.255.15). Por më interesante është se br-ex nuk ka ndërfaqe fizike, dhe nëse shikojmë se cilat rrjedha janë konfiguruar, mund të shohim se ky bridge aktualisht mund vetëm të bllokojë trafikun.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163 mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Si e duket nga dalja, adresa është e lidhur drejtpërdrejt me portin fizik, jo me ndërfaqen e urës virtuale.
[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 ~]$ Sipas rregullit të parë, gjithçka që vjen nga porta phy-br-ex duhet të hidhet.
Në të vërtetë, ky urë deri tani nuk ka asnjë burim tjetër për trafik, përveç kësaj ndërfaqe (lidhja me br-int), dhe gjykuar nga drop-et, në urë tashmë ka arritur trafik BUM.
Praktiçisht, nga kjo nodë trafiku mund të dalë vetëm përmes tunelit VxLAN dhe asnjë mënyrë tjetër. Megjithatë, nëse aktivizoni DVR, situata do të ndryshojë, por për këtë do të merremi një tjetër herë. Kur përdorni izolimin e rrjeteve, për shembull me VLAN, do të keni jo një, por disa interface L3 në VLAN-in 0. Megjithatë, trafiku VxLAN do të dalë nga nodi në të njëjtën mënyrë, por i inkapsuluar gjithashtu në një VLAN të veçantë.
Kemi përfunduar me nodën compute, tani kalojmë te nodi control.
[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 ~]$Në fakt, mund të thuhet se është e njëjta situatë, megjithatë adresa IP tani ndodhet jo në interface fizik, por në bridge virtual. Kjo është bërë sepse ky port është porti përmes të cilit do të dalë trafiku në botën e jashtme.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163 mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Kyçin e lidhur me bridgin br-ex, dhe pasi nuk ka etiketa VLAN, ky port është një port trunqi në të cilin janë të lejuara të gjitha VLAN-et; aktualisht, trafiku del jashtë pa etiketa, siç tregon vlan-id 0 në daljen më lart.
E gjithĂ« pjesa tjetĂ«r Ă«shtĂ« e ngjashme me nodĂ«n compute â tĂ« njĂ«jtat bridge, tĂ« njĂ«jtat tunel qĂ« shkojnĂ« nĂ« dy nodat compute.
Nuk do tĂ« flasim pĂ«r nodet e ruajtjes nĂ« kĂ«tĂ« artikull, por pĂ«r tĂ« kuptuar Ă«shtĂ« e nevojshme tĂ« thuhet se pjesa rrjetore e kĂ«tyre nodove Ă«shtĂ« tejet e thjeshtĂ«. NĂ« rastin tonĂ« ka vetĂ«m njĂ« port fizik (eth0) me njĂ« adresĂ« IP tĂ« caktuar dhe asgjĂ« mĂ« tej. Nuk ka as tunel VxLAN, as ura tunelesh etj. â nuk ka as OVS nĂ« pĂ«rgjithĂ«si, pasi nuk ka kuptim pĂ«r tĂ«. Kur pĂ«rdoret izolimi i rrjeteve â nĂ« kĂ«tĂ« nod do tĂ« ketĂ« dy interfaca (porte fizike, virtuozĂ«, ose thjesht dy VLAN-e â nuk ka rĂ«ndĂ«si â varet nga çfarĂ« dĂ«shiron) â njĂ« pĂ«r menaxhim, e dyta pĂ«r trafik (shkrim nĂ« disk VM, lexim nga disku etj).
E kuptuam se çfarĂ« kemi nĂ« nodet pa ndonjĂ« shĂ«rbim. Tani do tĂ« grevosh 4 makina virtuale dhe do tĂ« shohim se si do tĂ« ndryshojĂ« skema e pĂ«rshkruar mĂ« sipĂ«r â do tĂ« duhet tĂ« shfaqen porte, ruterĂ« virtualĂ« etj.
Tani për tani rrjeti ynë duket kështu:
Kemi dy makina virtuale në çdo nod të kompjuterit. Në shembullin compute-0 do të shikojmë se si është e gjithë përfshirë.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Mjeti ka vetĂ«m njĂ« ndĂ«rfaqe virtuale â 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 ~]$
Kjo ndërfaqe shikon në linux bridge:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Siç shihet nga daljet nĂ« bridge, ka dy ndĂ«rfaqe â tap95d96a75-a0 dhe qvb95d96a75-a0.
ĂshtĂ« e nevojshme tĂ« ndalemi pak mbi llojet e pajisjeve virtuale tĂ« rrjetit nĂ« OpenStack:
vtap â ndĂ«rfaqe virtuale e lidhur me instancĂ«n (VM)
qbr â Linux bridge
qvb dhe qvo â çifti vEth, e lidhur me Linux bridge dhe Open vSwitch bridge
br-int, br-tun, br-vlan â Open vSwitch bridges
patch-, int-br-, phy-br- â ndĂ«rfaqet patch tĂ« Open vSwitch, qĂ« lidhin bridges
qg, qr, ha, fg, sg â porte tĂ« Open vSwitch, tĂ« pĂ«rdorura nga pajisjet virtuale pĂ«r t'u lidhur me OVS
Si e kuptoni, nëse në bridge kemi portin qvb95d96a75-a0, i cili është një çift vEth, atëherë diku ekziston ana përkatëse, e cila logjikisht duhet të quhet qvo95d96a75-a0. Të shohim se cilët porte ekzistojnë në 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 ~]$ Siç e shohim, porta është në br-int. Br-int ka rolin e një switch-i, duke përfunduar portet e makinave virtuale. Përveç qvo95d96a75-a0, në daljen është gjithashtu porti qvo5bd37136-47. Në përfundim, skema jonë tani duket kështu:
Pyetjes qĂ« duhet menjĂ«herĂ« tĂ« tĂ«rheqĂ« vĂ«mendjen e lexuesit tĂ« kujdesshĂ«m Ă«shtĂ«: pĂ«rse njĂ« bridge linux mes portit tĂ« makinĂ« virtuale dhe portit OVS? E gjithĂ« kjo Ă«shtĂ« pĂ«r shkak se pĂ«r tĂ« mbrojtur makinĂ«n pĂ«rdoren grupet e sigurisĂ«, tĂ« cilat nuk janĂ« gjĂ« tjetĂ«r veçse iptables. OVS nuk funksionon me iptables, prandaj Ă«shtĂ« krijuar njĂ« âhackâ i tillĂ«. MegjithatĂ«, ai po kalon fazĂ«n e tij â nĂ« vend tĂ« tij po vjen conntrack nĂ« versionet e reja.
Pra, në fund të fundit skema duket kështu:
Dy makina në një hipervizor në një rrjet L2 të njëjtë.
Duke qenë se këto dy VM janë në të njëjtën rrjetë L2 dhe në të njëjtin hipervizor, trafiku midis tyre ka kuptim të kalojë lokalisht përmes br-int, pasi të dy makinat do të jenë në të njëjtin 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 ~]$ Dy makina në hipervizorë të ndryshëm në një rrjet L2 të njëjtë.
Tani tani e shohim se si do të kalojë traffiku midis dy makinave brenda një rrjeti L2, por të vendosura në hipervizorë të ndryshëm. Nëse të jemi të sinqertë, nuk do të ketë shumë ndryshime, thjesht traffiku midis hipervizorëve do të kalojë përmes një tuneli vxlan. Le të shikojmë një shembull.
Adresat e makinave virtuale midis të cilave do të shohim traffikun:
[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 ~]$ Le t'i shohim tabelën e përparimit në br-int në 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 ~]Traffiku duhet tĂ« shkojĂ« nĂ« portin 2 â le tĂ« shohim se cila Ă«shtĂ« kjo port:
[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 ~]$Ky Ă«shtĂ« patch-tun â domethĂ«nĂ« interfejsi nĂ« br-tun. Le tĂ« shohim se çfarĂ« ndodh me paketĂ«n nĂ« 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 ~]$ Paketa poqeshet në VxLAN dhe dërgohet në portin 2. Shikojmë ku lidhet porti 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Ky është një tunel vxlan në 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 ~]$Shkëmbejmë në compute-1 dhe shikojmë çfarë ndodh më pas me paketën:
[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 adresa është e pranishme në tabelën e përparimit br-int në compute-1, dhe siç dallohet nga dalja më sipër, ajo shihet përmes portit 2, i cili është port nga 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:46Pra nda shohim se në br-int në compute-1 ka një adresë destinimi:
[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 ~]$ Pra, paketa e marrë do të shkojë në portin 3, pas të cilit ndodhet makina virtuale instance-00000003.
Bukuria e shpërndarjes së Openstack për të studiuar në një infrastrukturë virtuale është se mund të kapim pa probleme trafikun mes hiper-vezhgjuesve dhe të shohim se çfarë po ndodh me të. Këtë do të bëjmë tani, do të fillojmë tcpdump në portin vnet në drejtim të compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: po dëgjon në vnet3, lloji i lidhjes EN10MB (Ethernet), madhësia e kapjes 262144 byte
*****************e hequr*******************
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
*****************e hequr*******************Rreshti i parë tregon se paketat me adresën 10.0.1.85 shkojnë në adresën 10.0.1.88 (trafik ICMP), dhe ato janë të paketuar në një paketë VxLAN me vni 22, duke shkuar nga hosti 192.168.255.19 (compute-0) në hostin 192.168.255.26 (compute-1). Mund të verifikojmë se VNI përputhet me atë që është specifikuar në ovs.
TĂ« kthehemi nĂ« kĂ«tĂ« rresht actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 â kjo Ă«shtĂ« vni nĂ« sistemin heksadecimal. Le tĂ« konvertojmĂ« kĂ«tĂ« numĂ«r nĂ« sistemin decimal:
16 = 6*16^0+1*16^1 = 6+16 = 22Pra, vni përputhet me realitetin.
Rreshti i dytë tregon trafik të kundërt, dhe nuk ka nevojë për shpjegim pasi gjithçka është e qartë.
Dy makina në rrjeta të ndryshme (routimi mes rrjetave)
Rasti i fundit pĂ«r sot â Ă«shtĂ« routimi mes rrjetave brenda njĂ« projekti duke pĂ«rdorur njĂ« router virtual. Ne po shqyrtojmĂ« rastin pa DVR (do ta shqyrtojmĂ« nĂ« njĂ« artikull tjetĂ«r), kĂ«shtu qĂ« routimi ndodh nĂ« nodĂ«n e rrjetit. NĂ« rastin tonĂ«, nodi i rrjetit nuk Ă«shtĂ« nxjerrĂ« si njĂ« entitet tĂ« veçantĂ« dhe ndodhet nĂ« nodin e kontrollit.
Fillimisht, le të shohim se si funksionon routimi:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 bytes of data
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 msNë këtë rast, paketa duhet të dërgohet në gateway dhe të route-zohet atje, prandaj na nevojitet të dimë adresën MAC të gateway, për të cilën do të shohim tabelën ARP në instancë:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] në eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] në eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] në eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] në eth0Tani do të shohim se ku duhet të dërgohet trafiku me destinacion (10.0.1.254) fa:16:3e:c4:64:70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Të shohim se ku çon porta 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Të gjitha janë të qarta, trafiku shkon në br-tun. Le të shohim në cilin tunel vxlan do të vendoset:
[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 ~]$ Porti i tretë është tuneli vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Kjo që shikon në nodën e kontrollit:
[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 ~]$ Trafiku arriti në nodën e kontrollit, kështu që duhet të kalojmë tek ajo dhe të shohim se si do të ndodhë routing.
Siç e mbani mend, nodĂ«n e kontrollit e shihnim njĂ«lloj si nodĂ«n compute â tĂ« njĂ«jtat tre bridge, pĂ«rveçse br-ex kishte njĂ« port fizik, me tĂ« cilin nodĂ« kishte mundĂ«si tĂ« dĂ«rgonte trafik jashtĂ«. Krijimi i instancave e ndryshoi konfigurimin nĂ« nodat compute â shtoheshin linux bridge, iptables dhe interface tĂ« reja nĂ« nodat. Krijimi i rrjeteve dhe routing virtual gjithashtu la gjurmĂ« nĂ« konfigurimin e nodĂ«s sĂ« kontrollit.
Pra, është e qartë se adresa MAC e gateway duhet të jetë në tabelën e forwarding br-int në nodën e kontrollit. Le të kontrollojmë nëse ajo është atje dhe se çfarë po shikon:
[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 ~]$ Mauza është e dukshme nga porta qr-0c52b15f-8f. Nëse rikthehemi në listën e porteve virtuale në Openstack, ky lloj porte përdoret për të lidhur pajisje virtuale të ndryshme me OVS. Më saktësisht, qr është porta në drejtim të routerit virtual, e cila paraqitet si namespace.
Le të shohim se cilat namespace ka në server:
[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 ~]$ Janë tre instance të plota. Por duke parë emrat, mund të kuptojmë qëllimin e secilit prej tyre. Do të kthehemi më vonë te instance me ID 0 dhe 1, tani na intereson namespace 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 ~]$ Në këtë namespace ka dy lidhje të brendshme, të cilat i kemi krijuar më parë. Të dy portat virtualë janë shtuar në br-int. Le të kontrollojmë adresën MAC të portit qr-0c52b15f-8f, pasi trafiku, sipas adresës MAC të destinacionit, po shkonte pikërisht në këtë ndërfaqe.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163 mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Kështu që në këtë rast gjithçka funksionon sipas ligjeve të standardit të rutimit. Pasi trafiku është i destinuar për hostin 10.0.2.8, ai duhet të dalë përmes ndërfaqes së dytë qr-92fa49b5-54 dhe të shkojë përmes tunelit vxlan në nodën compute:
[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 ~]$ E gjithë kjo është logjike, nuk ka surpriza. Të shohim nga ku duket adresa MAC e hostit 10.0.2.8 në 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 ~]$ Siç është e zakonshme, trafiku shkon në br-tun, le të shohim në cilin tunel do shkojë më tej trafiku:
[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 ~]$ Trafiku shkon nĂ« tunel deri te compute-1. Tek compute-1 gjithçka Ă«shtĂ« e thjeshtĂ« â nga br-tun paketi kalon nĂ« br-int dhe prej aty nĂ« ndĂ«rfaqen e makinerisĂ« virtuale:
[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 ~]$ Le të kontrollojmë nëse kjo është vërtet ndërfaqja e saktë:
[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 ~]$ Kemi kaluam të gjithë rrugën e paketës. Mendoj se keni vënë re se trafiku ka kaluar përmes tunelesh të ndryshme vxlan dhe ka dalë me VNI të ndryshme. Le të shohim se cilat janë këto VNI, pas së cilës do të marrim një dump në portin e nodit të kontrollit dhe do të sigurohemi që trafiku po kalon ashtu siç përshkruhet më sipër.
Pra, tuneli deri në compute-0 ka veprimet e mëposhtme: actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Le të konvertojmë 0x16 në sistemin decimal:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tuneli deri në compute-1 ka VNI-në e mëposhtëm: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Le të konvertojmë 0x63 në sistemin decimal:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Tani le të shohim dump-in:
[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*******************Paketi i parë është një paketë vxlan nga hosti 192.168.255.19 (compute-0) në hostin 192.168.255.15 (control-1) me vni 22, brenda të cilës është paketë ICMP nga hosti 10.0.1.85 në hostin 10.0.2.8. Siç e llogaritëm më lart, vni përputhet me atë që pamë në daljet.
Pako i dytë është një pako vxlan nga hosti 192.168.255.15 (control-1) në hostin 192.168.255.26 (compute-1) me vni 99, brenda së cilës është paketuar një paketë ICMP nga hosti 10.0.1.85 në hostin 10.0.2.8. Siç e kemi llogaritur më sipër, vni përputhet me atë që kemi parë në output.
Dy paketat e ardhshme janë trafiku i kundërt nga 10.0.2.8 dhe jo nga 10.0.1.85.
Pra, në fund kemi një skemë të tillë për nodën e kontrollit:
Duket se është gjithçka? Harrojmë dy namespace:
[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 ~]$ Siç e pĂ«rmendĂ«m pĂ«r arkitekturĂ«n e platformĂ«s nĂ« re â do tĂ« ishte mirĂ« qĂ« makinat tĂ« merrnin adresat automatikisht nga serveri DHCP. KĂ«ta janĂ« dy serverĂ« DHCP pĂ«r dy rrjetet tona 10.0.1.0/24 dhe 10.0.2.0/24.
TĂ« kontrollojmĂ« nĂ«se Ă«shtĂ« kĂ«shtu. NĂ« kĂ«tĂ« namespace ka vetĂ«m njĂ« adresĂ« â 10.0.1.1 â adresa e vetĂ« serverit DHCP, dhe ajo Ă«shtĂ« gjithashtu e pĂ«rfshirĂ« nĂ« br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163 mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Le të shohim nëse proceset që përmbajnë në emrin e tyre qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 në nodën kontrolle:
[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 ~]$ Ekziston një proces i tillë dhe, duke marrë parasysh informacionin e paraqitur në daljen më sipër, ne mund të shohim, për shembull, se çfarë kemi aktualisht në qira:
[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 ~]$Në përfundim, ne marrim një grup shërbimesh të tilla në nodën kontroll:
Dhe tĂ« keni parasysh â janĂ« vetĂ«m â 4 makina, 2 rrjete tĂ« brendshme dhe njĂ« rrugĂ«tar virtual⊠Tani nuk kemi rrjete tĂ« jashtme, njĂ« mori projektesh tĂ« ndryshme, secili me rrjetet e veta (tĂ« ndĂ«rsjellta), dhe kemi çaktivizuar rrugĂ«tarin e shpĂ«rndarĂ«, madje nĂ« fund tĂ« fundit nĂ« qĂ«ndrĂ«n testuese kishte vetĂ«m njĂ« nod kontrolli (pĂ«r qĂ«ndrueshmĂ«ri duhet tĂ« ketĂ« njĂ« kvorum prej tre nodash). ĂshtĂ« logjike se nĂ« tregti gjithçka Ă«shtĂ« âpakâ mĂ« e komplikuar, por nĂ« kĂ«tĂ« shembull tĂ« thjeshtĂ« kuptojmĂ« se si duhet tĂ« funksionojĂ« â do tĂ« keni 3 ose 300 hapĂ«sira emĂ«rimi, natyrisht Ă«shtĂ« e rĂ«ndĂ«sishme, por nga kĂ«ndvĂ«shtrimi i funksionimit tĂ« gjithĂ« strukturĂ«s â pĂ«rveç ndonjĂ« aparati SDN tĂ« ndryshĂ«m, nuk do tĂ« ndryshojĂ« veçanĂ«risht⊠por kjo Ă«shtĂ« njĂ« histori krejt e ndryshme.
Shpresoj se ishte interesante. NĂ«se ka vĂ«rejtje/plotĂ«sime, ose ndonjĂ«herĂ« kam thĂ«nĂ« diçka qĂ« nuk Ă«shtĂ« e vĂ«rtetĂ« (jam njeri dhe opinioni im gjithmonĂ« do tĂ« jetĂ« subjektiv) â shkruani çfarĂ« duhet tĂ« korrigjohet/shtohet â do t'i rregullojmĂ«/shtojmĂ« gjithçka.
NĂ« pĂ«rfundim, dĂ«shiroj tĂ« them disa fjalĂ« mbi krahasimin e Openstack (si versionin e tij origjinal, ashtu edhe atĂ« nga furnizuesit) me zgjidhjen cloud tĂ« kompanisĂ« VMWare â kaq shpesh mĂ« Ă«shtĂ« bĂ«rĂ« ky pyetje gjatĂ« dy viteve tĂ« fundit dhe sinqerisht kam filluar tĂ« lodhem nga tĂ« folurit pĂ«r tĂ«, por megjithatĂ«. NĂ« mendimin tim, Ă«shtĂ« shumĂ« e vĂ«shtirĂ« tĂ« krahasohen kĂ«to dy zgjidhje, por mund tĂ« thuhet me siguri se ka disavantazhe nĂ« tĂ« dyja zgjidhjet dhe kur zgjidhni njĂ« nga to, duhet tĂ« peshoj tĂ« mirat dhe tĂ« kĂ«qijat.
NĂ«se OpenStack Ă«shtĂ« njĂ« zgjidhje e drejtuar nga komuniteti, VMWare ka tĂ« drejtĂ« tĂ« bĂ«jĂ« vetĂ«m atĂ« qĂ« dĂ«shiron (lexoni â atĂ« qĂ« Ă«shtĂ« nĂ« interesin e saj) dhe kjo Ă«shtĂ« logjike â pasi Ă«shtĂ« njĂ« kompani tregtare qĂ« Ă«shtĂ« mĂ«suar tĂ« fitojĂ« para nga klientĂ«t e saj. Por kĂ«tu ka njĂ« "po" tĂ« madhe â ju mund tĂ« largoheni nga OpenStack, p.sh. nga Nokia, dhe tĂ« kaloni me lehtĂ«si nĂ« zgjidhjen nga p.sh. Juniper (Contrail Cloud), por e keni tĂ« vĂ«shtirĂ« tĂ« largoheni nga VMWare. PĂ«r mua, kĂ«to dy zgjidhje duken kĂ«shtu â Openstack (nga furnizuesit) Ă«shtĂ« njĂ« kosh i thjeshtĂ«, nĂ« tĂ« cilin ju e dini mbylljen, por keni çelĂ«sin dhe mund tĂ« dilni nĂ« çdo moment. VMWare â Ă«shtĂ« njĂ« kosh i artĂ«, çelĂ«si i tĂ« cilit Ă«shtĂ« te pronari dhe do t'ju kushtojĂ« shumĂ«.
Nuk po agitoj pĂ«r asnjĂ« nga produktet â ju zgjidhni atĂ« qĂ« ju nevojitet. Por nĂ«se do tĂ« kisha pĂ«r tĂ« bĂ«rĂ« njĂ« zgjedhje, do tĂ« zgjidhja tĂ« dy zgjidhjet â VMWare pĂ«r tĂ« gjitha nevojat IT (ngarkesa tĂ« vogla, menaxhim tĂ« lehtĂ«), OpenStack nga ndonjĂ« ofrues (Nokia dhe Juniper ofrojnĂ« zgjidhje shumĂ« tĂ« mira) â pĂ«r cloud-in Telekom. Nuk do ta pĂ«rdorja OpenStack pĂ«r IT-nĂ« e pastĂ«r â Ă«shtĂ« si tĂ« qĂ«llosh me armĂ« nga njĂ« top pĂ«r njĂ« zog, por nuk shoh asnjĂ« kundĂ«rshtim pĂ«r ta pĂ«rdorur, pĂ«rveç se pĂ«r shkak tĂ« tepricĂ«s. MegjithatĂ«, pĂ«rdorimi i VMWare nĂ« telekom Ă«shtĂ« si tĂ« transportosh guralecĂ« me njĂ« Ford Raptor â duket bukur nga jashtĂ«, por shoferi duhet tĂ« bĂ«jĂ« 10 herĂ« nga njĂ«herĂ«.
NĂ« mendimin tim, disavantazhi mĂ« i madh i VMWare Ă«shtĂ« mbyllja e saj totale â kompania nuk do t'ju japĂ« asnjĂ« informacion rreth mĂ«nyrĂ«s se si funksionon, pĂ«r shembull, vSAN-i ose çfarĂ« ka nĂ« bĂ«rthamĂ«n e hipervizorit â kjo nuk Ă«shtĂ« nĂ« interesin e saj â domethĂ«nĂ«, nuk do tĂ« bĂ«heni kurrĂ« ekspert nĂ« VMWare â pa mbĂ«shtetje nga shitĂ«si, jeni tĂ« dĂ«nuar (shpesh takohem me ekspertĂ« tĂ« VMWare qĂ« janĂ« tĂ« ngatĂ«rruar nga pyetje banale). PĂ«r mua, VMWare Ă«shtĂ« si tĂ« blini njĂ« makinĂ« me kapak tĂ« mbyllur â po, ndoshta keni specialistĂ« qĂ« mund tĂ« ndĂ«rojnĂ« grep tĂ« motorit, por vetĂ«m ai qĂ« ju tregtoi kĂ«tĂ« zgjidhje mund ta hapĂ« kapakun. Personalish, nuk mĂ« pĂ«lqejnĂ« zgjidhjet nĂ« tĂ« cilat nuk mund tĂ« hyj. Do tĂ« thoni se ndoshta nuk do t'ju duhet tĂ« hyni nĂ«n kapak. Po, mund tĂ« jetĂ« kĂ«shtu, por do tĂ« shikoj fytyrĂ«n tuaj kur t'ju duhet tĂ« ndĂ«rroni nĂ« njĂ« cloud njĂ« funksion tĂ« madh me 20-30 makina virtuale, 40-50 rrjete, gjysma e tĂ« cilave dĂ«shirojnĂ« tĂ« dalin jashtĂ«, ndĂ«rsa gjysma tjetĂ«r kĂ«rkon pĂ«rshpejtim SR-IOV, pĂ«rndryshe do t'ju nevojiten edhe disa dhjetĂ«ra tĂ« tilla â pĂ«rndryshe performanca nuk do tĂ« mjaftojĂ«.
EkzistojnĂ« pikĂ«pamje tĂ« tjera, kĂ«shtu qĂ« vetĂ«m ju vendosni se çfarĂ« tĂ« zgjidhni dhe mĂ« e rĂ«ndĂ«sishmja â ju do tĂ« mbani pĂ«rgjegjĂ«si pĂ«r zgjedhjen tuaj. Ky Ă«shtĂ« thjesht mendimi im â i njĂ« njeriu qĂ« ka parĂ« dhe prekur me duar tĂ« paktĂ«n 4 produkte â Nokia, Juniper, Red Hat dhe VMWare. Do tĂ« thotĂ« qĂ« kam me çfarĂ« tĂ« krahasoj.
Burimi: habr.com
