Computing in the cloud is increasingly penetrating our lives, and there probably isn't a single person who hasn't used any cloud services at least once. However, what exactly is the cloud and how does it work? Most people know very little about it, even at a basic level. 5G is becoming a reality, and telecommunications infrastructure is beginning to shift from traditional solutions to cloud solutions, just as it once transitioned from entirely hardware-based solutions to virtualized 'poles'.
Today, we will talk about the inner workings of cloud infrastructure, particularly focusing on the basics of the network component.
What is the cloud? Is it just virtualization â a profile view?
A very logical question. No, it is not virtualization, although it is certainly involved. Let's consider two definitions:
Cloud computing (hereafter referred to as the Cloud) is a model for providing convenient user access to distributed computing resources that should be provisioned and launched on demand with minimal latency and minimal costs to the service provider.
Virtualizimi is the ability to divide a single physical entity (such as a server) into several virtual entities, thereby increasing resource utilization (for example, if you had 3 servers loaded at 25-30 percent, after virtualization you get 1 server functioning at 80-90 percent). Naturally, virtualization consumes some resources â you need to support the hypervisor; however, as practice has shown, the game is worth the candle. An ideal example of virtualization is VMWare, which excels at preparing virtual machines, or, for instance, KVM, which I prefer, but that's a matter of taste.
We use virtualization without even realizing it; even hardware routers already utilize virtualization â for instance, in the latest versions of JunOS, the operating system is installed as a virtual machine on top of a real-time Linux distribution (Wind River 9). But virtualization is not the cloud; however, the cloud cannot exist without virtualization.
Virtualization is one of the building blocks on which the cloud is built.
Krijimi i njĂ« cloud-i, duke mbledhur thjesht disa hypervisors nĂ« njĂ« domen L2, duke shtuar disa skripta YAML pĂ«r tĂ« automatizuar ndarjen e VLAN-it pĂ«rmes ndonjĂ« ansible dhe duke i vĂ«nĂ« tĂ« gjitha nĂ«n diçka si njĂ« sistem orkestrimi pĂ«r krijimin automatizues tĂ« makinave virtuale â nuk do tĂ« funksionojĂ«. SaktĂ«sisht, do tĂ« funksionojĂ«, por Frankenstein-i i marrĂ« â nuk Ă«shtĂ« cloud-i qĂ« na nevojitet, megjithatĂ« ndoshta pĂ«r dikĂ« tjetĂ«r kjo Ă«shtĂ« kulmi i Ă«ndrrave. PĂ«r mĂ« tepĂ«r, nĂ«se merret OpenStack â nĂ« thelb Ă«shtĂ« njĂ« tjetĂ«r Frankenstein, por le tĂ« mos flasim pĂ«r kĂ«tĂ« tani.
Por e kuptoj që nga përkufizimi i mësipërm nuk është shumë e qartë se çfarë mund të quhet vërtet cloud.
Prandaj, në dokumentin e NIST (Instituti Kombëtar i Standardeve dhe Teknologjisë) janë paraqitur 5 karakteristika kryesore që duhet të ketë infrastruktura cloud:
Ofrimi i shĂ«rbimeve sipas kĂ«rkesĂ«s. KĂ«to burime duhet t'i jepen pĂ«rdoruesit 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 kompjuterëve standardë, si dhe klientëve të hollë dhe pajisjeve mobile.
Grumbullimi i burimeve nĂ« pool. Pools duhet tĂ« nxisin ofrimin e burimeve tĂ« shumta pĂ«r disa klientĂ«, duke siguruar izolimin e klientĂ«ve dhe pa ndikim reciprok midis tyre dhe konkurencĂ«s pĂ«r burime. NĂ« pool pĂ«rfshihen edhe rrjetet, duke treguar mundĂ«sinĂ« e adresimit tĂ« ndĂ«rprerĂ«. Pools duhet tĂ« mbĂ«shtesin shkallĂ«zimin sipas kĂ«rkesĂ«s. PĂ«rdorimi i pool-ve lejon pĂ«r tĂ« siguruar njĂ« nivel tĂ« nevojshĂ«m tĂ« qĂ«ndrueshmĂ«risĂ« dhe abstraktimin e burimeve fizike dhe virtuale â klienti merr thjesht grupin e burimeve tĂ« kĂ«rkuara (ku janĂ« vendosur fizikisht kĂ«to burime, nĂ« sa servera dhe switch-e â klienti nuk e ka problem). MegjithatĂ«, duhet marrĂ« parasysh se ofruesi duhet tĂ« sigurojĂ« rezervimin transparent tĂ« kĂ«tyre burimeve.
Adaptimi i shpejtĂ« ndaj kushteve tĂ« ndryshme. ShĂ«rbimet duhet tĂ« jenĂ« fleksibile â ofrimi i burimeve tĂ« shpejtĂ«, ripĂ«rshpĂ«rndarja, shtimi ose zvogĂ«limi i 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 thjeshtuar, pĂ«r shembull, ju nuk e shihni njĂ« paralajmĂ«rim qĂ« ju mungon njĂ« pjesĂ« e hapĂ«sirĂ«s nĂ« disk nĂ« Apple iCloud pĂ«r shkak se disku nĂ« server Ă«shtĂ« dĂ«mtuar, kurse diskĂ«t dĂ«mtohen. Nga ana juaj, mundĂ«sitĂ« e kĂ«tij shĂ«rbimi janĂ« pothuajse tĂ« pakufizuara â nĂ«se ju nevojiten 2 TB â s'ka problem, paguani dhe merrni. NjĂ« shembull i ngjashĂ«m Ă«shtĂ« edhe me 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 konsumuar, ndërkohë që këto mekanizma duhet të jenë të qarta si për përdoruesin ashtu edhe për ofruesin e shërbimit. Në të vërtetë, ju gjithmonë mund të kontrolloni se sa burime ju dhe klientët tuaj po konsumoni.
Duhet të merret parasysh fakti se këto kërkesa në shumicën e rasteve janë kërkesa për cloud publik, kështu që për cloud privat (pra cloud të vendosur për nevojat e brendshme të kompanisë) këto kërkesa mund të jenë paksa të modifikuara. Megjithatë, ato duhet të përmbushen, përndryshe ne nuk do të përfitojmë të gjitha avantazhet e llogaritjeve cloud.
PĂ«rse na duhet cloud?
MegjithatĂ«, çdo teknologji e re apo tĂ« ekzistueshme, çdo protokoll i ri krijohet pĂ«r njĂ« qĂ«llim (pĂ«rveç RIP-ng natyrisht). NjĂ« protokoll pĂ«r protokollin â askujt nuk i nevojitet (pĂ«rveç RIP-ng natyrisht). ĂshtĂ« logjikĂ« qĂ« Cloud krijohet pĂ«r tĂ« ofruar njĂ« lloj shĂ«rbimi pĂ«r pĂ«rdoruesin/klientin. TĂ« gjithĂ« jemi tĂ« njohur me disa shĂ«rbime cloud, pĂ«r shembull Dropbox ose Google.Docs dhe besoj se shumica e tyre i pĂ«rdor me sukses â pĂ«r shembull, ky artikull Ă«shtĂ« shkruar duke pĂ«rdorur shĂ«rbimin cloud Google.Docs. Por shĂ«rbimet cloud tĂ« njohura pĂ«r ne janĂ« vetĂ«m njĂ« pjesĂ« e mundĂ«sive tĂ« cloud-it â mĂ« saktĂ«, ato janĂ« vetĂ«m njĂ« lloj shĂ«rbimi si SaaS. ShĂ«rbimin cloud mund ta ofrojmĂ« nĂ« tri mĂ«nyra: si SaaS, PaaS ose IaaS. Cili shĂ«rbim ju nevojitet varet nga dĂ«shirat dhe mundĂ«sitĂ« tuaja.
Të shqyrtojmë secilin rend pas rend.
Software as a Service (SaaS) â kjo Ă«shtĂ« njĂ« model i ofrimit tĂ« shĂ«rbimeve tĂ« plota pĂ«r klientin, siç Ă«shtĂ« njĂ« shĂ«rbim postĂ« si Yandex.Mail ose Gmail. NĂ« kĂ«tĂ« model tĂ« ofrimit tĂ« shĂ«rbimeve, ju si klient nĂ« tĂ« vĂ«rtetĂ« nuk bĂ«ni asgjĂ« tjetĂ«r veçse pĂ«rdorni shĂ«rbimin â domethĂ«nĂ«, nuk keni nevojĂ« tĂ« mendoni pĂ«r konfigurot e shĂ«rbimit, qĂ«ndrueshmĂ«rinĂ« e tij ose rezervimin. E rĂ«ndĂ«sishmja Ă«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Ă«rbimeve â ai Ă«shtĂ« plotĂ«sisht pĂ«rgjegjĂ«s pĂ«r tĂ« gjithĂ« shĂ«rbimin â duke filluar nga pajisjet server dhe sistemet operative tĂ« hostit, deri te konfigurimet e bazave tĂ« tĂ« dhĂ«nave dhe softuerit.
Platform as a Service (PaaS) â kur pĂ«rdoret ky model, ofruesi i shĂ«rbimeve i ofron klientit njĂ« pĂ«rgatitje pĂ«r shĂ«rbimin, pĂ«r shembull njĂ« server WEB. Ofruesi i shĂ«rbimeve iu dha klientit njĂ« server virtual (nĂ« fakt njĂ« grup burimesh, si RAM/CPU/Storage/Nets etj.), dhe madje instaloi nĂ« kĂ«tĂ« server sistemin operativ dhe softuerin e nevojshĂ«m, megjithatĂ« konfigurimin e tĂ« gjithave kĂ«tyre e bĂ«n vetĂ« klienti dhe pĂ«r funksionimin e shĂ«rbimit tashmĂ« pĂ«rgjigjet klienti. Ofruesi i shĂ«rbimeve, si nĂ« rastin e kaluar, pĂ«rgjigjet pĂ«r funksionimin e pajisjeve fizike, hipervizorĂ«ve, vetĂ« makinĂ«s virtuale, aksesin e saj nĂ« rrjet etj., por shĂ«rbimi vetĂ« tashmĂ« Ă«shtĂ« jashtĂ« zonĂ«s sĂ« tij tĂ« pĂ«rgjegjĂ«sisĂ«.
Infrastructure as a Service (IaaS) â ky qasje Ă«shtĂ« mĂ« interesante, nĂ« thelb ofruesi i shĂ«rbimeve i ofron klientit njĂ« infrastrukturĂ« tĂ« plotĂ« tĂ« virtualizuar â domethĂ«nĂ« njĂ« grup (pool) burimesh, si CPU Cores, RAM, Networks etj. TĂ« gjitha gjĂ«rat e tjera â janĂ« punĂ« e klientit â çfarĂ« dĂ«shiron klienti tĂ« bĂ«jĂ« me kĂ«to burime brenda grupit tĂ« tij tĂ« caktuar (kuotĂ«s) â pĂ«r ofruesin nuk ka shumĂ« rĂ«ndĂ«si. NĂ«se klienti dĂ«shiron tĂ« krijojĂ« vetĂ« njĂ« vEPC apo madje tĂ« bĂ«jĂ« njĂ« operator tĂ« vogĂ«l dhe tĂ« ofrojĂ« shĂ«rbime komunikimi â çështje e thjeshtĂ« â bĂ«je. NĂ« njĂ« skenar tĂ« tillĂ«, ofruesi i shĂ«rbimeve Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r ofrimin e burimeve, qĂ«ndrueshmĂ«rinĂ« dhe disponueshmĂ«rinĂ« e tyre, si dhe pĂ«r sistemin operativ qĂ« lejon bashkimin e kĂ«tyre burimeve nĂ« grupe dhe t'i ofrojĂ« klientit mundĂ«sinĂ« pĂ«r tĂ« rritur ose zvogĂ«luar burimet sipas kĂ«rkesĂ«s sĂ« klientit nĂ« çdo moment. TĂ« gjitha makinat virtuale dhe çdo gjĂ« tjetĂ«r, klienti e konfiguronte vetĂ« pĂ«rmes portalit tĂ« vet-shĂ«rbimit dhe konsollĂ«s, duke pĂ«rfshirĂ« edhe konfigurimet e rrjeteve (pĂ«rveç rrjeteve tĂ« jashtme).
ĂfarĂ« Ă«shtĂ« OpenStack?
NĂ« tĂ« tre variantet, ofruesi i shĂ«rbimeve ka nevojĂ« pĂ«r njĂ« OS qĂ« lejon krijimin e njĂ« infrastrukture nĂ« re. NĂ« fakt, me SaaS, pĂ«r gjithĂ« stek-in, pĂ«rgjegjĂ«s pĂ«r kĂ«tĂ« stek teknologjish nuk Ă«shtĂ« vetĂ«m njĂ« divizion â ka njĂ« divizion qĂ« ndihmon pĂ«r infrastrukturĂ«n â pra, ofron IaaS pĂ«r njĂ« divizion tjetĂ«r, dhe ky divizion iu ofron klientĂ«ve SaaS. OpenStack Ă«shtĂ« njĂ« nga OS-tĂ« nĂ« re qĂ« lejon mbledhjen e shumĂ« switch-eve, serverĂ«ve dhe sistemeve tĂ« ruajtjes nĂ« njĂ« pool burimesh tĂ« vetme, duke i ndarĂ« kĂ«to burime nĂ« nĂ«n-pula (tenanta) dhe duke iu ofruar kĂ«to burime klientĂ«ve pĂ«rmes rrjetit.
steal time â Ă«shtĂ« njĂ« sistem operativ nĂ« re qĂ« lejon kontrollin e grupeve tĂ« mĂ«dha tĂ« burimeve llogaritĂ«se, ruajtjeve tĂ« tĂ« dhĂ«nave dhe burimeve rrjetĂ«sore, ku provizionimi dhe menaxhimi realizohen pĂ«rmes API-sĂ« me pĂ«rdorimin e mekanizmave standarde tĂ« autentifikimit.
Me fjalĂ« tĂ« tjera, kjo Ă«shtĂ« njĂ« kompleks projektesh software-i tĂ« lirĂ« qĂ« synon krijimin e shĂ«rbimeve nĂ« re, (si publike ashtu edhe private) â pra, Ă«shtĂ« njĂ« grup mjetesh qĂ« lejojnĂ« bashkimin e pajisjeve server dhe atĂ« tĂ« drejtimit nĂ« njĂ« pool burimesh, pĂ«r tĂ« menaxhuar kĂ«to burime, duke siguruar nivelin e nevojshĂ«m tĂ« qĂ«ndrueshmĂ«risĂ«.
Në momentin e shkruajtjes së këtij materiali, struktura e OpenStack duket kështu:
Imazhi është marrë nga
Ădo komponentĂ« qĂ« bĂ«n pjesĂ« nĂ« OpenStack ka njĂ« funksion tĂ« caktuar. Kjo arkitekturĂ« e shpĂ«rndarĂ« lejon pĂ«rfshirjen nĂ« zgjidhje tĂ« atij grupi funksional tĂ« komponentĂ«ve qĂ« ju nevojiten. MegjithatĂ«, disa komponentĂ« janĂ« komponentĂ« kryesorĂ« dhe eliminimi i tyre do tĂ« çonte nĂ« papunĂ«sinĂ« totale ose tĂ« pjesshme tĂ« zgjidhjes si njĂ« e tĂ«rĂ«. KomponentĂ«t e tillĂ« zakonisht pĂ«rfshijnĂ«:
- Panair â GUI mbi web pĂ«r menaxhimin e shĂ«rbimeve OpenStack
- Keystone â shĂ«rbimi i centralizuar i identifikimit, i cili ofron funksionalitetin e autentifikimit dhe autorizimit pĂ«r shĂ«rbime tĂ« tjera, si dhe menaxhon tĂ« dhĂ«nat e pĂ«rdoruesve dhe rolet e tyre.
- Neutron â shĂ«rbimi rrjetĂ«sor qĂ« siguron lidhshmĂ«rinĂ« midis interfecave tĂ« shĂ«rbimeve tĂ« ndryshme OpenStack (pĂ«rfshirĂ« lidhshmĂ«rinĂ« midis VM-ve dhe qasjen e tyre nĂ« botĂ«n e jashtme)
- Cinder â ofron qasje nĂ« ruajtjen blok pĂ«r makinat virtuale
- Nova â menaxhimi i ciklit tĂ« jetĂ«s sĂ« makinave virtuale
- Glance â depoja e imazheve tĂ« makinave virtuale dhe snapshtotĂ«ve
- Swift â ofron qasje nĂ« ruajtjen objektive
- Ceilometer â shĂ«rbimi qĂ« ofron mundĂ«sinĂ« e mbledhjes sĂ« telemetrisĂ« dhe matjes sĂ« burimeve aktuale dhe atyre qĂ« konsumohen
- Heat â orkestrimi i bazuar nĂ« shabllone pĂ«r krijimin dhe provizionimin automatik tĂ« burimeve
Lista e plotë e të gjitha projekteve dhe qëllimi i tyre mund të shikohet .
Ădo komponent i OpenStack Ă«shtĂ« njĂ« shĂ«rbim qĂ« pĂ«rgjigjet pĂ«r njĂ« funksion tĂ« caktuar dhe siguron API pĂ«r menaxhimin e kĂ«tij funksioni dhe ndĂ«rveprimin e kĂ«tij shĂ«rbimi me shĂ«rbime tĂ« tjera nĂ« sistemin operativ tĂ« dĂ«rgĂ«s, pĂ«r qĂ«llimin e krijimit tĂ« njĂ« infrastrukture tĂ« vetme. PĂ«r shembull, Nova menaxhon burimet llogaritĂ«se dhe siguron API pĂ«r qasje nĂ« konfigurimin e kĂ«tyre burimeve, Glance â menaxhimin e imazheve dhe API pĂ«r menaxhimin e tyre, Cinder â ruajtjen bllok dhe API pĂ«r menaxhimin e saj, etj. TĂ« gjitha funksionet janĂ« tĂ« ndĂ«rthurura ngushtĂ« me njĂ«ra-tjetrĂ«n.
MegjithatĂ«, nĂ«se e mendoni, tĂ« gjithĂ« shĂ«rbimet e nisura nĂ« OpenStack pĂ«rfaqĂ«sojnĂ« nĂ« pĂ«rfundim ndonjĂ« makinĂ« virtuale (ose kontejner) tĂ« lidhur me rrjetin. ĂĂ«shtja Ă«shtĂ« â pĂ«rse na nevojiten kaq shumĂ« elemente?
Le të kalojmë përmes algoritmit të krijimit të një makine virtuale dhe lidhjes së saj me rrjetin dhe ruajtjen e qëndrueshme në OpenStack.
- Kur krijoni njĂ« kĂ«rkesĂ« pĂ«r tĂ« krijuar njĂ« makinĂ«, qoftĂ« kjo kĂ«rkesĂ« pĂ«rmes Horizon (Dashboard) ose pĂ«rmes CLI, gjĂ«ja e parĂ« qĂ« ndodh â Ă«shtĂ« autorizimi i kĂ«rkesĂ«s tuaj nĂ« Keystone â a keni tĂ« drejtĂ« tĂ« krijoni makinĂ«n, a keni tĂ« drejtĂ«n pĂ«r tĂ« pĂ«rdorur kĂ«tĂ« rrjet, a mjafton kuota e projektit tuaj, etj.
- Keystone kryen autentikimin e kërkesës tuaj dhe gjeneron në përgjigje një token auth, i cili do të përdoret më tej. Pas marrjes së përgjigjes nga Keystone, kërkesa dërgohet në drejtim të Nova (nova api).
- Nova-api kontrollon vlefshmërinë e kërkesës tuaj, duke iu drejtuar Keystone-it përmes token-it auth të gjeneruar më parë.
- Keystone kryen autentikimin dhe ofron bazuar në këtë token auth informacion rreth lejeve dhe kufizimeve.
- Nova-api krijon një regjistrim për VM-në e re në bazën e të dhënave nova dhe dërgon kërkesën për të krijuar makinën në nova-scheduler.
- Nova-scheduler zgjedh hostin (nyllet e kompjuterit) ku VM do të zhvillohet, bazuar në parametrat e caktuar, peshat dhe zonat. Një regjistër për këtë dhe identifikatori i VM shkruhen në nova-database.
- Më pas, nova-scheduler drejtohet te nova-compute me një kërkesë për zhvillimin e një instance. Nova-compute drejtohet te nova-conductor për të marrë informacionin mbi parametrat e makinës (nova-conductor është një komponent i nova-s që vepron si një server proxy midis nova-database dhe nova-compute, duke kufizuar numrin e kërkesave drejt nova-database për të shmangur problemet me konsistencën e bazës së të dhënave dhe ngarkesën).
- Nova-conductor merr informacionin e kërkuar nga nova-database dhe ia transmeton nova-compute.
- Më pas, nova-compute drejtohet te glance për të marrë ID-në e imazhit. Glance bën validimin e kërkesës në Keystone dhe kthen informacionin e kërkuar.
- Nova-compute drejtohet te neutron për të marrë informacion mbi parametrat e rrjetit. Njësoj si glance, neutron bën validimin e kërkesës në Keystone, pas së cilës krijon një regjistër në database (identifikatori i portit etj.), krijon një kërkesë për krijimin e portit dhe kthen informacionin e kërkuar te nova-compute.
- Nova-compute drejtohet te cinder me një kërkesë për alokimin e një volumi për virtual machine. Njësoj si glance, cinder bën validimin e kërkesës në Keystone, krijon një kërkesë për krijimin e volumit dhe kthen informacionin e kërkuar.
- Nova-compute drejtohet te libvirt me një kërkesë për zhvillimin e një makine virtuale me parametrat e caktuar.
Faktikisht, nje operacion i dukshĂ«m i thjeshtĂ« pĂ«r tĂ« krijuar njĂ« makinĂ« virtuale tĂ« thjeshtĂ« shndĂ«rrohet nĂ« njĂ« pĂ«rzierje tĂ« thirrjeve API midis elementĂ«ve tĂ« platformĂ«s cloud. Madje, siç mund ta shihni, edhe shĂ«rbimet e ndryshuara mĂ« parĂ« pĂ«rbĂ«hen nga komponente mĂ« tĂ« vogla, mes tĂ« cilave ndodhin ndĂ«rveprime. Krijimi i makinĂ«s Ă«shtĂ« vetĂ«m njĂ« pjesĂ« e vogĂ«l e asaj qĂ« platforma cloud ofron â ka shĂ«rbime qĂ« pĂ«rgjigjen pĂ«r balancimin e trafikut, shĂ«rbime qĂ« reagojnĂ« pĂ«r ruajtjen nĂ« bllok, shĂ«rbime pĂ«r DNS, shĂ«rbime qĂ« menaxhojnĂ« provisioning-in e serverĂ«ve bare metal, e shumĂ« e tjera. Cloud-i ju lejon tĂ« shihni makinat tuaja virtuale si njĂ« tufĂ« dhi (ndryshe nga virtualizimi). NĂ«se nĂ« njĂ« mjedis virtual ndodh diçka me makinĂ«n â ju e riktheni atĂ« nga backup-et etj., aplikacionet cloud janĂ« ndĂ«rtuar nĂ« mĂ«nyrĂ« qĂ« makinat virtuale tĂ« mos luajnĂ« njĂ« rol kaq tĂ« rĂ«ndĂ«sishĂ«m â nĂ«se makina virtuale 'vdes' â nuk ka problem â thjesht krijohet njĂ« makinĂ« e re mbi bazĂ«n e njĂ« template dhe, siç thonĂ«, grupi nuk e vuri re humbjen e luftĂ«tarit. Sigurisht, kjo parashikon ekzistencĂ«n e mekanizmave tĂ« orkestrimit â duke pĂ«rdorur template Heat, ju mund tĂ« aktivizoni njĂ« funksion kompleks, pĂ«rbĂ«rĂ« nga dhjetĂ«ra rrjeta dhe makina virtuale pa ndonjĂ« problem.
Duhet gjithmonĂ« tĂ« mbani parasysh se infrastruktura cloud nuk ekziston pa rrjetin â çdo element nĂ« njĂ« mĂ«nyrĂ« ose tjetĂ«r ndĂ«rvepron me elemente tĂ« tjera pĂ«rmes rrjetit. PĂ«rveç kĂ«saj, rrjeti cloud ka njĂ« natyrĂ« krejtĂ«sisht jo statike. Natyrisht, rrjeti underlay Ă«shtĂ« mĂ« ose mĂ« pak statik â nuk shtohen çdo ditĂ« node tĂ« reja dhe switch-e, megjithatĂ« komponenti overlay mund dhe patjetĂ«r do tĂ« ndryshojĂ« vazhdimisht â do tĂ« shtohen ose hiqen rrjeta tĂ« reja, do tĂ« shfaqen makina virtuale tĂ« reja dhe do tĂ« vdesin tĂ« vjetra. Dhe siç e mbani mend nga definicioni i cloud-it, i dhĂ«nĂ« nĂ« fillim tĂ« artikullit â burimet duhet t'i ndahen pĂ«rdoruesit automatikisht dhe me sa mĂ« pak (e preferuara pa) ndĂ«rhyrje nga ana e ofruesit tĂ« shĂ«rbimit. KĂ«shtu qĂ« ai tip i ofrimit tĂ« burimeve tĂ« rrjetit, i cili ekziston tani nĂ« formĂ«n e frontend-it si kabinetin tuaj personal tĂ« aksesueshĂ«m pĂ«rmes http/https dhe inxhinierit tĂ« rrjetit Vasili si back-end â kjo nuk Ă«shtĂ« cloud, madje edhe me praninĂ« e tetĂ« duarve tĂ« Vasilit.
Neutron, si një shërbim rrjetesh, ofron një API për menaxhimin e pjesës rrjetëore të infrastrukturës cloud. Shërbimi siguron funksionimin dhe menaxhimin e pjesës rrjetëore të OpenStack, duke ofruar një nivel abstraksioni të quajtur Network-as-a-Service (NaaS). Kjo do të thotë që rrjeti është njësi e matshme virtuale, ashtu siç janë bërthamat virtuale të CPU-së ose kapaciteti i RAM-it.
Por para se të kalojmë në arkitekturën e pjesës rrjetëore 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.
Pra, kemi dy makina virtuale të klientit RED dhe dy makina virtuale të klientit GREEN. Le të supozojmë se këto makina janë vendosur në dy hipervizorë në këtë mënyrë:
Në këtë moment, kjo është thjesht virtualizimi i 4 serverëve dhe asgjë më shumë, sepse deri tani gjithçka që kemi bërë është të virtualizojmë 4 serverë, duke i vendosur ato në dy serverë fizikë. Ato madje nuk janë të lidhura me rrjetin.
PĂ«r tĂ« krijuar njĂ« cloud, na nevojiten disa komponentĂ«. SĂ« pari, duam tĂ« virtualizojmĂ« pjesĂ«n rrjetĂ«ore â duhet tĂ« lidhnim kĂ«to 4 makina dy nga dy, duke pasur parasysh se klientĂ«t duan njĂ« lidhje L2. Sigurisht, mund tĂ« pĂ«rdorim njĂ« switch dhe ta konfigurojmĂ« atĂ« nĂ« drejtim tĂ« trunk dhe tĂ« zgjidhim gjithçka me ndihmĂ«n e linux bridge, ose pĂ«r pĂ«rdorues mĂ« tĂ« avancuar, openvswitch (pĂ«r tĂ« cilin do tĂ« kthehemi mĂ« vonĂ«). Por mund tĂ« ketĂ« shumĂ« rrjete, dhe vazhdimisht tĂ« dĂ«rgoni L2 pĂ«rmes switch-it nuk Ă«shtĂ« ideja mĂ« e mirĂ« â ndonjĂ«herĂ« ndarjet e ndryshme, shĂ«rbimi i ndihmĂ«s, muajt e pritjes sĂ« kĂ«rkesave, javĂ«t e troubleshooting-ut â nĂ« botĂ«n moderne, njĂ« qasje e tillĂ« nuk funksionon mĂ«. Dhe sa mĂ« shpejt ta kuptojĂ« kĂ«tĂ« njĂ« kompani, aq mĂ« lehtĂ« do tĂ« trajtojĂ« tĂ« ardhmen. Prandaj, midis hipervizorĂ«ve do tĂ« ndarim njĂ« rrjet L3, nĂ«pĂ«rmjet tĂ« cilit do tĂ« komunikojnĂ« makinat tona virtuale, dhe mbi kĂ«tĂ« rrjet L3 do tĂ« ndĂ«rtojmĂ« rrjete tĂ« mbivendosura L2 (overlay), ku do tĂ« kalojĂ« trafiku i makinave tona virtuale. PĂ«r inkapsulimin, mund tĂ« pĂ«rdorim GRE, Geneve ose VxLAN. Deri tani do tĂ« ndalojmĂ« tek e fundit, megjithĂ«se nuk Ă«shtĂ« aq e rĂ«ndĂ«sishme.
Na duhet një vend për të vendosur VTEP (shpresoj që të gjithë janë të njohur me terminologjinë VxLAN). Duke pasur parasysh që nga serverët dilet menjëherë në një rrjet L3, nuk ka asgjë që na pengon ta vendosim VTEP-në në vetë serverët, dhe OVS (OpenVSwitch) e bën këtë mjaft mirë. Si rezultat, kemi marrë një strukturë të tillë:
Pasi që trafiku midis VM duhet të ndahet, portet drejt makinave virtuale do të kenë numra të ndryshëm VLAN-esh. Numri i tagut ka rëndësi vetëm brenda një switch-i virtual, sepse gjatë inkapsulimit në VxLAN mund ta heqim pa probleme, pasi do të kemi VNI.
Tani mund të krijojmë makinat tona dhe rrjetet virtuale për to pa ndonjë problem.
Por çfarë 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 qendror - do të thotë që trafiku rrugëzohet përmes node-ve speciale të dedikuara rrjetit (zakonisht ato janë të kombinuara me node të kontrollit, kështu që do të kemi të njëjtën gjë).
Duket se nuk ka asgjë të komplikuar - krijojmë një ndërfaqe bridge në nodën e kontrollit, dërgojmë trafikun aty dhe nga aty e rrugëzojmë atje ku na nevojitet. 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ë rrjetin 10.0.0.0/24. Pra, kemi një përplasje të hapësirave adresuese. Përveç kësaj, klientët nuk dëshirojnë që klientët e tjerë të mund të rrugëzojnë në rrjetet e tyre të brendshme, gjë që është logjike. Për të ndarë rrjetet dhe trafikun e të dhënave të klientëve, do t'i ndamë ato në çdo namespace të veçantë. Namespace - në fakt është një kopje e stack-ut rrjetor Linux, që do të thotë se klientët në namespace RED janë plotësisht të izoluar nga klientët në namespace GREEN (ose rrugëzimi midis këtyre rrjeteve të klientëve lejohet përmes namespace default ose në pajisjet e transportit më të larta).
Pra, arrijmë një skemë të tillë:
Të gjitha tunelët L2 bashkohen nga të gjitha nodat e llogaritjes në nodën e kontrollit, ku ndodhet ndërfaqja L3 për këto rrjete, secili në një namespace të dedikuar për izolim.
Megjithatë, harrojmë gjënë më të rëndësishme. Një makinë virtuale duhet të ofrojë shërbim për klientin, dmth. ajo duhet të ketë të paktën një ndërfaqe të jashtme përmes së cilës mund të arrihet. Pra, na nevojitet të dalim në botën e jashtme. Këtu ka variante të ndryshme. Do të bëjmë variantin më të thjeshtë. Do t'u shtojmë klientëve nga një rrjet, i cili do të jetë valid në rrjetin e ofruesit dhe nuk do të përsërisë rrjetet e tjera. Rrjetet gjithashtu mund të përputhen dhe të shikojnë në VRF të ndryshme në anën e rrjetit të ofruesit. Këto rrjete gjithashtu do të jetojnë në hapësirën e emrave të secilit klient. Sidoqoftë, dalja në botën e jashtme do të ndodhë përmes një ndërfaqeje fizike (ose një bindi, që është më logjike). Për të ndarë trafikun e klientëve, trafiku që del jashtë do të realizohet me etiketimin VLAN me etiketën e dedikuar për klientin.
Në fund, ne morëm këtë skemë:
NjĂ« pyetje e arsyeshme â pse tĂ« mos krijojmĂ« porta nĂ« vetĂ« nodat e llogaritjes? Nuk ka ndonjĂ« problem tĂ« madh nĂ« kĂ«tĂ«, madje, me aktivizimin e ruterit tĂ« shpĂ«rndarĂ« (DVR) kjo do tĂ« funksionojĂ« ashtu siç duhet. NĂ« kĂ«tĂ« skenar po shqyrtojmĂ« variantin mĂ« tĂ« thjeshtĂ« me njĂ« gateway tĂ« centralizuar, i cili pĂ«rdoret si parazgjedhje nĂ« Openstack. PĂ«r funksionet me ngarkesa tĂ« larta do tĂ« pĂ«rdoren si ruter tĂ« shpĂ«rndarĂ« ashtu edhe teknologji pĂ«rshpejtimi si SR-IOV dhe Passthrough, por siç thotĂ« shprehja, kjo Ă«shtĂ« njĂ« histori krejtĂ«sisht tjetĂ«r. Fillimisht do tĂ« merremi me pjesĂ«n bazĂ« dhe mĂ« pas do tĂ« kalojmĂ« nĂ« detaje.
Në thelb, skema jonë është tashmë funksionale, megjithatë ka disa nuanca:
- Na nevojitet si të mbrojmë makinat tona, dmth. të vendosim një filtrin në ndërfaqen e switch-it në drejtim të klientit.
- Të mundësojmë marrjen automatikisht të adresës ip nga makina virtuale, në mënyrë që të mos na duhet të hyjmë çdo herë në të përmes konsolës dhe të shkruajmë adresën.
Le të fillojmë me mbrojtjen e makinave. Për këtë, mund të përdorim iptables të zakonshme, pse jo.
Pra, tani topologjia jonë është pak më e ndërlikuar:
Të vazhdojmë. Na nevojitet të shtojmë serverin DHCP. Vendi më ideal për vendosjen e serverëve DHCP për secilin klient do të jetë nodi i kontrollit të përmendur më sipër, ku janë vendosur hapësirat e emrave:
MegjithatĂ«, ka njĂ« problem tĂ« vogĂ«l. ĂfarĂ« ndodh nĂ«se gjithçka ri-nis dhe tĂ« gjitha informacionet mbi qiranĂ« e adresave nĂ« DHCP zhduken. Logjikisht, automjetet do t'u jepeshin adresa tĂ« reja, qĂ« nuk Ă«shtĂ« shumĂ« e pĂ«rshtatshme. Ka dy rrugĂ«: ose tĂ« pĂ«rdorim emrat domain dhe tĂ« shtojmĂ« njĂ« server DNS pĂ«r çdo klient, atĂ«herĂ« adresa nuk do tĂ« jetĂ« shumĂ« e rĂ«ndĂ«sishme pĂ«r ne (si nĂ« pjesĂ«n rrjetore nĂ« k8s) â por kĂ«tu Ă«shtĂ« njĂ« problem me rrjetet e jashtme, pasi nĂ« to adresat gjithashtu mund tĂ« jepen nga DHCP â Ă«shtĂ« e nevojshme njĂ« sinkronizim me serverĂ«t DNS nĂ« platformĂ«n nĂ« cloud dhe me serverin e jashtĂ«m DNS, qĂ« pĂ«r mendimin tim nuk Ă«shtĂ« shumĂ« fleksibĂ«l, megjithatĂ« Ă«shtĂ« plotĂ«sisht e mundur. Ose mundĂ«sia e dytĂ« â tĂ« pĂ«rdorim metadatĂ«n â dmth. tĂ« ruajmĂ« informacionin mbi adresĂ«n e dhĂ«nĂ« tĂ« automjetit nĂ« mĂ«nyrĂ« qĂ« serveri DHCP tĂ« dijĂ« se cila adresĂ« t'i japĂ« automjetit, nĂ«se automjeti tashmĂ« ka marrĂ« adresĂ«. Opsioni i dytĂ« Ă«shtĂ« mĂ« i lehtĂ« dhe mĂ« fleksibĂ«l, pasi lejon ruajtjen e informacionit shtesĂ« rreth automjetit. Tani nĂ« skemĂ« do tĂ« shtojmĂ« agjentin e metadata:
NjĂ« pyetje tjetĂ«r qĂ« gjithashtu duhet tĂ« diskutohet Ă«shtĂ« mundĂ«sia e pĂ«rdorimit tĂ« njĂ« rrjete tĂ« jashtme nga tĂ« gjithĂ« klientĂ«t, pasi rrjetet e jashtme, nĂ«se duhet tĂ« jenĂ« tĂ« vlefshme nĂ« tĂ« gjithĂ« rrjetin, do tĂ« sjellin vĂ«shtirĂ«si â duhet tĂ« dĂ«shmojmĂ« dhe tĂ« kontrollojmĂ« vazhdimisht ndarjen e kĂ«tyre rrjeteve. MundĂ«sia e pĂ«rdorimit tĂ« njĂ« rrjeti tĂ« parapĂ«rgatitur tĂ« vetĂ«m pĂ«r tĂ« gjithĂ« klientĂ«t do tĂ« ishte shumĂ« e dobishme gjatĂ« krijimit tĂ« njĂ« cloud publik. Kjo do ta thjeshtojĂ« shpĂ«rndarjen e automjeteve, pasi nuk do tĂ« kemi nevojĂ« tĂ« konsultohemi me bazĂ«n e tĂ« dhĂ«nave tĂ« adresave dhe tĂ« zgjidhim njĂ« hapĂ«sirĂ« unike adresash pĂ«r rrjetin e jashtĂ«m tĂ« secilit klient. PĂ«r mĂ« tepĂ«r, ne mund ta shkruajmĂ« rrjetin e jashtĂ«m paraprakisht dhe nĂ« momentin e shpĂ«rndarjes, do tĂ« na nevojitet vetĂ«m tĂ« asociojmĂ« adresat e jashtme me automjetet e klientĂ«ve.
Dhe kĂ«tu na vjen nĂ« ndihmĂ« NAT â thjesht do tĂ« mundĂ«sojmĂ« qĂ« klientĂ«t tĂ« dalin nĂ« botĂ«n e jashtme pĂ«rmes default namespace duke pĂ«rdorur pĂ«rkthimin NAT. Por ka njĂ« problem tĂ« vogĂ«l. Kjo Ă«shtĂ« nĂ« rregull nĂ«se serveri i klientit funksionon si klient dhe jo si server â do tĂ« thotĂ«, ai iniciaton dhe jo pranon lidhjet. Por ne do tĂ« kemi tĂ« kundĂ«rtĂ«n. NĂ« kĂ«tĂ« rast, na nevojitet destinacioni NAT, nĂ« mĂ«nyrĂ« qĂ« kur tĂ« marrim trafik, nodi kontrollues tĂ« kuptojĂ« se ky trafik i takon makinĂ«s virtuale A tĂ« klientit A, dhe kjo do tĂ« thotĂ« se duhet tĂ« bĂ«jmĂ« pĂ«rkthimin NAT nga adresa e jashtme, pĂ«r shembull 100.1.1.1 nĂ« adresĂ«n e brendshme 10.0.0.1. NĂ« kĂ«tĂ« rast, ndonĂ«se tĂ« gjithĂ« klientĂ«t do tĂ« pĂ«rdorin tĂ« njĂ«jtin rrjet, izolimi i brendshĂ«m ruhet plotĂ«sisht. DomethĂ«nĂ«, na nevojitet tĂ« bĂ«jmĂ« dNAT dhe sNAT nĂ« nodin kontrollues. PĂ«rdorimi i njĂ« rrjeti tĂ« vetĂ«m me dhĂ«nien e adresave fluturuese ose rrjeteve tĂ« jashtme, ose tĂ« dyja sĂ« bashku â varet nga ajo qĂ« dĂ«shoni tĂ« tĂ«rheqni nĂ« re. Ne nuk do tĂ« vendosim nĂ« skemĂ« edhe adresat fluturuese, por do tĂ« lĂ«mĂ« rrjetet e jashtme qĂ« janĂ« shtuar mĂ« parĂ« â çdo klient ka rrjetin e tij tĂ« jashtĂ«m (nĂ« skemĂ« tĂ« shpallura si vlan 100 dhe 200 nĂ« ndĂ«rfaqen e jashtme).
Si rezultat, ne erdhëm në një zgjidhje interesante dhe njëkohësisht të menduar, e cila ka një lloj fleksibiliteti, por ende nuk ka mekanizma të qëndrueshmërisë.
SĂ« pari, ne kemi vetĂ«m njĂ« nod kontrollues â dalja e saj nga funksioni do tĂ« çonte nĂ« shembjen e tĂ« gjitha sistemeve. PĂ«r tĂ« eliminuar kĂ«tĂ« problem, Ă«shtĂ« e nevojshme tĂ« krijojmĂ« tĂ« paktĂ«n njĂ« kuorum prej 3 nodesh. Do ta shtojmĂ« kĂ«tĂ« nĂ« skemĂ«:
Natyrisht, tĂ« gjitha nodet do tĂ« 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. Aktualisht ato ruhen nĂ« vetĂ« hypervizorĂ«t dhe nĂ« rast problemesh me hypervizorin, ne humbasim tĂ« gjitha tĂ« dhĂ«nat â dhe prania e RAID-it kĂ«tu nuk ndihmon nĂ« asnjĂ« mĂ«nyrĂ« nĂ«se humbasim jo njĂ« disk, por tĂ«rĂ« serverin. PĂ«r kĂ«tĂ«, na nevojitet njĂ« shĂ«rbim qĂ« do tĂ« veprojĂ« si njĂ« ndĂ«rfaqe pĂ«r ndonjĂ« depo. Cila do tĂ« jetĂ« kjo depo, nuk ka shumĂ« rĂ«ndĂ«si pĂ«r ne, por ajo duhet tĂ« mbrojĂ« tĂ« dhĂ«nat tona nga dĂ«shtimi i diskeve dhe nodave, madje edhe ndoshta tĂ« gjithĂ« kardhĂ«n. Ka disa mundĂ«si kĂ«tu â gjithmonĂ« ka rrjete SAN me Fiber Channel, por tĂ« themi tĂ« vĂ«rtetĂ«n â FC Ă«shtĂ« tashmĂ« njĂ« relikt i kaluar â analog i E1 nĂ« transport â po pranoj, ai akoma pĂ«rdoret, por vetĂ«m aty ku nuk mund tĂ« bĂ«het ndryshe. Prandaj, tĂ« krijosh njĂ« rrjet FC nĂ« vitin 2020, unĂ« nuk do ta bĂ«nte, duke e ditur ekzistencĂ«n e alternativave mĂ« interesante. MegjithatĂ«, çdo njeri ka mendimin e tij dhe ndoshta do tĂ« bĂ«hen ata qĂ« mendojnĂ« se FC me tĂ« gjitha kufizimet e tij Ă«shtĂ« gjithçka çfarĂ« na nevojitet â nuk do tĂ« diskutoj, çdonjĂ«ri ka mendimin e tij. MegjithatĂ«, zgjidhja mĂ« interesante sipas mendimit tim Ă«shtĂ« pĂ«rdorimi i SDS, siç Ă«shtĂ« Ceph.
Ceph lejon ndërtimin e një zgjidhjeje me disponueshmëri të lartë për ruajtjen e të dhënave me shumë mundësi për rezervim, duke filluar nga kodet me verifikimin e paritetit (analog i RAID 5 ose 6) deri te replikimi i plotë i të dhënave në disqe të ndryshëm në përputhje me vendosjen e disqeve në serverë, dhe serverëve në kardhë etj.
Për të ndërtuar Ceph nevojiten edhe 3 node. Ndërveprimi me depot do të bëhet gjithashtu përmes rjetit duke përdorur shërbime të ruajtjes me blloqe, objekte dhe skedarë. Le të shtojmë depo në diagram:
ShĂ«nim: mund tĂ« krijoni nodet kompjuterike hiper-konvergjente â kjo Ă«shtĂ« koncepti i bashkimit tĂ« disa funksioneve nĂ« njĂ« nodĂ« â pĂ«r shembull storage + compute â pa i ndarĂ« nodet speciale pĂ«r storage ceph. Ne do tĂ« marrim njĂ« skemĂ« tĂ« ngjashme qĂ« reziston ndaj dĂ«shtimeve â pasi SDS do tĂ« rezervojĂ« tĂ« dhĂ«nat me nivelin e rezervimit qĂ« e kemi pĂ«rcaktuar. MegjithatĂ«, nodet hiper-konvergjente janĂ« gjithmonĂ« njĂ« kompromis â pasi nodi storage nuk ngroh thjesht ajrin siç duket nĂ« pamje tĂ« parĂ« (pasi nuk ka makina virtuale) â ajo shpenzon burime CPU pĂ«r mirĂ«mbajtjen e SDS (nĂ« fakt, ajo nĂ« sfond bĂ«n tĂ« gjitha replikimet, rikthimet pas dĂ«shtimeve tĂ« nodĂ«ve, harduerĂ«ve etj). Kjo do tĂ« thotĂ« se do tĂ« humbni njĂ« pjesĂ« tĂ« energjisĂ« sĂ« nodit compute nĂ«se e kombinoni atĂ« me storage.
TĂ« gjithĂ« kĂ«to elemente duhet tĂ« menaxhohen siç duhet â na nevojitet njĂ« mĂ«nyrĂ« pĂ«r tĂ« krijuar makina, rrjete, njĂ« rrugĂ«toj virtual etj. PĂ«r kĂ«tĂ«, do tĂ« shtojmĂ« njĂ« shĂ«rbim nĂ« nodĂ«n kontrolle, e cila do tĂ« shĂ«rbejĂ« si dashboard â klienti do tĂ« mund tĂ« lidhet me kĂ«tĂ« portal pĂ«rmes http/https dhe tĂ« bĂ«jĂ« gjithçka qĂ« i nevojitet (aq sa mundet).
Si rrjedhojë, tani kemi një sistem që reziston ndaj dështimeve. Të gjithë elementët e kësaj infrastrukture duhet të menaxhohen nganjëherë. Më parë është përmendur se OpenStack është një grup projektesh, secili prej të cilëve siguron një funksion të caktuar. Siç e shohim, ka mjaft elemente që duhen konfiguruar dhe kontrolluar. Sot do të flasim mbi pjesën rrjetësore.
Arkitektura Neutron
Në OpenStack, Neutron është përgjegjës për lidhjen e porteve të makinave virtuale me rrjetin e përbashkët L2, sigurinë e drejtimit të trafik më VM-të që ndodhen në rrjete të ndryshme L2, si dhe drejtimin jashtë, duke ofruar shërbime si NAT, Floating IP, DHCP etj.
Përmbledhja e lartë e punës së shërbimit të rrjetit (pjesa bazë) mund të përshkruhet si më poshtë.
Kur nis një VM, shërbimi rrjetor:
- Krijon një port për këtë VM (ose porte) dhe e njofton shërbimin DHCP;
- Krijohet një pajisje rrjetësore virtuale të re (përmes libvirt);
- VM lidhet me portin (portet) e krijuara në hapin 1;
Siç duket çuditshĂ«m, por nĂ« thelb tĂ« punĂ«s sĂ« Neutron janĂ« mekanizmat standarde qĂ« çdo kush qĂ« Ă«shtĂ« marrĂ« me Linux i njeh â kĂ«to janĂ« namespaces, iptables, bridges linux, openvswitch, conntrack etj.
Duhet të sqarojmë se Neutron nuk është një kontrollues SDN.
Neutron përbëhet nga disa componente të ndërvarura:
Openstack-neutron-server â Ă«shtĂ« njĂ« demon qĂ« punon me kĂ«rkesat e pĂ«rdoruesve pĂ«rmes API. Ky demon nuk merret me caktimin e lidhjeve nĂ« rrjet, por ofron informacionin e nevojshĂ«m pĂ«r pluginat e tij, tĂ« cilĂ«t mĂ« pas konfigurojnĂ« elementin e nevojshĂ«m tĂ« rrjetit. AgjentĂ«t Neutron nĂ« nodet OpenStack regjistrohen nĂ« serverin Neutron.
Neutron-server është në të vërtetë një aplikacion i shkruar në python, i përbërë nga dy pjesë:
- Shërbimi REST
- Neutron Plugin (themel/shërbim)
Shërbimi REST është i destinuar për të pranuar thirrje API nga komponentët e tjerë (p.sh. kërkesë për të ofruar ndonjë informacion etj.)
Pluginat janĂ« komponente/modula qĂ« lidhen dhe thirren nĂ« kĂ«rkesat API â pra, caktimi i ndonjĂ« shĂ«rbimi ndodh pĂ«rmes tyre. Pluginat ndahen nĂ« dy lloje â shĂ«rbim dhe themel. Zakonisht, plugin-i themelor merret kryesisht me menaxhimin e hapĂ«sirĂ«s adresuese dhe lidhjes L2 midis VM, ndĂ«rsa pluginat shĂ«rbim ofrojnĂ« funksionalitete shtesĂ« si VPN ose FW.
Lista e pluginave të disponueshëm sot mund të shikohet, për shembull,
Ka disa pluginë shërbimi, megjithatë plugin-i themelor mund të jetë vetëm një.
Openstack-neutron-ml2 â Ă«shtĂ« plugin-i standard themelor i Openstack. Ky plugin ka njĂ« arkitekturĂ« modulare (ndryshe nga paraardhĂ«si i tij) dhe konfiguron shĂ«rbimin rrjetor pĂ«rmes shoferĂ«ve tĂ« lidhur me tĂ«. VetĂ« plugin-in do ta shqyrtojmĂ« pak mĂ« vonĂ«, pasi nĂ« tĂ« vĂ«rtetĂ« ai ofron fleksibilitetin qĂ« ka OpenStack nĂ« pjesĂ«n rrjetore. Plugin-i themelor mund tĂ« zĂ«vendĂ«sohet (p.sh. Contrail Networking bĂ«n njĂ« tĂ« tillĂ«).
ShĂ«rbimi RPC (rabbitmq-server) â shĂ«rbimi qĂ« siguron menaxhimin e radhĂ«ve dhe ndĂ«rveprimin me shĂ«rbime tĂ« tjera OpenStack si dhe ndĂ«rveprimin midis agjentĂ«ve tĂ« shĂ«rbimit rrjetor.
AgjentĂ«t e rrjetit â agjentĂ« qĂ« ndodhen nĂ« secilĂ«n nodĂ«, pĂ«rmes tĂ« cilĂ«ve bĂ«het konfigurimi i shĂ«rbimeve rrjetore.
Agjentët kanë disa lloje.
Agjenti kryesor është L2 agjenti. Këta agjentë aktivizohen në secilin nga hipervizorët duke përfshirë edhe nodet e kontrollit (më saktësisht në të gjithë nodet që ofrojnë ndonjë shërbim për tenantët) dhe funksioni i tyre kryesor është të lidhin makinat virtuale me rrjetin e përbashkët L2, si dhe të gjenerojnë njoftime në rastin e ndodhisë së ndonjë ngjarjeje (për shembull, fikja/aktivizimi i portit).
Agjenti tjetër, po aq i rëndësishëm, është agjenti L3. Nga e drejta, ky agjent aktivizohet ekskluzivisht në noden e rrjetit (shpesh nodi i rrjetit përputhet me nodin e kontrollit) dhe ofron rutigjimin midis rrjeteve të tenantëve (si midis rrjeteve të tij dhe rrjeteve të tenantëve të tjerë, ashtu si dhe aksesin në botën e jashtme, duke ofruar NAT, si dhe shërbimin DHCP). Megjithatë, kur përdoret DVR (ruter i shpërndarë), nevoja për plugin-in L3 shfaqet gjithashtu në nodet e përpunimit.
Agjenti L3 përdor namespaces të Linux-it për t'i ofruar çdo tenant një set të rrjeteve të izoluara dhe funksionalitetin e ruterëve virtualë, të cilët rutigjojnë trafikun dhe ofrojnë shërbime portash për rrjetet e Layer 2.
Baza e tĂ« dhĂ«nave â njĂ« bazĂ« tĂ« dhĂ«nash tĂ« identifikuesve tĂ« rrjeteve, nĂ«nrrjeteve, porteve, grupeve, etj.
Në fakt, Neutron pranon kërkesa API për krijimin e ndonjë entiteti rrjetor, autentifikon kërkesën dhe nëpërmjet RPC (nëse po i drejtohet ndonjë plugin-i ose agjenti) ose REST API (nëse po komunikon në SDN) i transmeton agjentëve (nëpërmjet plugina) udhëzimet e nevojshme për organizimin e shërbimit të kërkuar.
Tani le të shikojmë instalimin testues (si është vendosur dhe çfarë përfshin do ta shqyrtojmë më vonë në pjesën praktike) dhe të shohim se ku ndodhen secila 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ë struktura e Neutron. Tani është koha për të kushtuar disa momente për plugin-in ML2.
Modular Layer 2
Siç u tha më parë, plugin-i është plugin-i standard rrënjor i OpenStack dhe ka një arkitekturë modulare.
ParardhĂ«si i plugin-it ML2 kishte njĂ« strukturĂ« monolite qĂ« nuk lejonte, pĂ«r shembull, pĂ«rdorimin e njĂ« miks-i tĂ« teknologjive tĂ« ndryshme nĂ« njĂ« instalim tĂ« vetĂ«m. PĂ«r shembull, nuk mund tĂ« pĂ«rdornit njĂ«kohĂ«sisht openvswitch dhe linuxbridge â ose njĂ«ri, ose tjetri. PĂ«r kĂ«tĂ« arsye, u krijua plugin-i ML2 me arkitekturĂ«n e tij.
ML2 ka dy komponente â dy lloje drejtuesish: Type drivers dhe Mechanism drivers.
Type drivers përcaktojnë teknologjitë që do të përdoren për ndërtimin e lidhjeve rrjetore, për shembull VxLAN, VLAN, GRE. Ndërkohë drejtuesi lejon përdorimin e teknologjive të ndryshme. Teknologjia standarde është VxLAN për inkapsulimin e rrjeteve overlay dhe vlan për rrjetet e jashtme.
Llojet e rrjeteve që përfshihen në Type drivers janë:
Flat â rrjeti pa etiketim
VLAN â rrjeti i etiketuar
Local â njĂ« lloj i veçantĂ« rrjeti pĂ«r instalimet all-in-one (kĂ«to instalime nevojiten ose pĂ«r zhvilluesit ose pĂ«r trajnim)
GRE. â rrjeti overlay qĂ« pĂ«rdor tunel GRE
VxLAN â rrjeti overlay qĂ« pĂ«rdor tunel VxLAN
Mechanism drivers pĂ«rcaktojnĂ« mjete 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 drejtuesi do të përdoren ose agjentë që menaxhohen 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, ruterimin etj.
Shembulli: nĂ«se pĂ«rdorim ML2 sĂ« bashku me OVS, atĂ«herĂ« nĂ« çdo nodĂ« llogaritĂ«se instalohet agjenti L2, i cili menaxhon OVS. MegjithatĂ«, nĂ«se pĂ«rdorim pĂ«r shembull OVN ose OpenDayLight, menaxhimi i OVS kalon nĂ«n juridiksionin e tyre â Neutron pĂ«rmes plugin-it rrĂ«njor jep urdhra kontrolluesit, dhe ai e bĂ«n atĂ« qĂ« i Ă«shtĂ« thĂ«nĂ«.
Le të rifreskojmë kujtesën për Open vSwitch
Në këtë moment, një nga komponentët kryesorë të OpenStack është Open vSwitch.
Kur instalohet OpenStack pa ndonjë SDN shtesë nga ndonjë ofrues si Juniper Contrail ose Nokia Nuage, OVS është komponenti kryesor rrjetor i rrjetit në re dhe në kombinim me iptables, conntrack, namespaces lejon organizimin e rrjeteve të plota ovelay me shumë qira. Natyrisht, ky komponent mund të zëvendësohet, për shembull, kur përdoren zgjidhje SDN proprietarë (nga ofruesë të jashtëm).
OVS është një kalimtar softuerik me burim të hapur, i cili është i destinuar për t'u përdorur në mjedise të virtualizuara si një përparues trafiku virtual.
Në këtë moment, OVS ka një funksionalitet të shkëlqyer, i cili përfshin teknologji të tilla si QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK etj.
Shënim: në fillim, OVS nuk ishte menduar si një kalimtar softuerik për funksione telekom me ngarkesë të lartë dhe ishte më shumë i orientuar për funksione IT që ishin më pak kërkuese për kapacitet, si serverë WEB ose serverë email. Megjithatë, OVS është përmirësuar dhe implementimet aktuale të OVS kanë përmirësuar ndjeshëm performancën dhe mundësitë e tij, duke lejuar përdorimin e tij nga operatorët e komunikimit me funksione me ngarkesë të lartë, për shembull, ka një implementim OVS me mbështetje për acelerimin DPDK.
Ekzistojnë tre komponentë të rëndësishëm të OVS, të cilët duhet të dihet:
- Moduli i Kernel-it â njĂ« komponent i vendosur nĂ« hapĂ«sirĂ«n e kernel-it, i cili kryen pĂ«rpunimin e trafikut nĂ« bazĂ« tĂ« rregullave tĂ« marra nga elementi menaxhues;
- vSwitch daemon (ovs-vswitchd) Ă«shtĂ« njĂ« proces i nisur nĂ« hapĂ«sirĂ«n e pĂ«rdoruesit, i cili Ă«shtĂ« pĂ«rgjegjĂ«s pĂ«r programimin e modulit kernel â pra paraqet logjikĂ«n e punĂ«s sĂ« switch-it.
- Serveri i databazĂ«s â njĂ« bazĂ« tĂ« dhĂ«nash lokale, e vendosur nĂ« çdo host ku Ă«shtĂ« nisur OVS, nĂ« tĂ« cilĂ«n ruhet konfigurimi. PĂ«rmes kĂ«tij moduli, kontrollet SDN mund tĂ« komunikojnĂ« pĂ«rmes protokollit OVSDB.
Përveç kësaj, është bashkangjitur një set mjetesh diagnostikuese dhe menaxhuese si ovs-vsctl, ovs-appctl, ovs-ofctl etj.
Aktualisht, Openstack pĂ«rdoret gjerĂ«sisht nga operatorĂ«t e telekomit pĂ«r tĂ« migruar funksionet e rrjetit, si EPC, SBC, HLR etj. Disa funksione mund tĂ« vazhdojnĂ« tĂ« ekzistojnĂ« pa asnjĂ« problem me OVS nĂ« formĂ«n e tij aktuale, por pĂ«r shembull EPC pĂ«rpunon trafik abonentĂ«sh â dmth kalon pĂ«rmes saj njĂ« sasi tĂ« madhe trafiku (aktualisht volumi i trafikut arrin qindra gigabite nĂ« sekondĂ«). Natyrisht, kalimi i kĂ«tij trafiku pĂ«rmes hapĂ«sirĂ«s sĂ« kernelit (pasi ndryshe pĂ«rforcuesi ndodhet aty) nuk Ă«shtĂ« ideja mĂ« e mirĂ«. Pra, shpesh OVS organizohet 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 kernelin.
Shënim: për një cloud të instaluar për funksione telekomi, ekziston mundësia e kalimit të trafikut nga nodi kompjuterik duke anashkaluar OVS direkt në pajisjen e lidhjes. Për këtë qëllim përdoren mekanizmat SR-IOV dhe Passthrough.
Si funksionon kjo në një model real?
Tani le të kalojmë në pjesën praktike dhe të shohim si funksionon gjithçka në praktikë.
Si fillim, do tĂ« vendosim njĂ« instalim tĂ« thjeshtĂ« tĂ« Openstack. Sepse nuk kam nĂ« dispozicion njĂ« grup serverĂ«sh pĂ«r eksperimente, do tĂ« ndĂ«rtojmĂ« modelin nĂ« njĂ« server fizik nga makina virtuale. Po, natyrisht, pĂ«r qĂ«llime komerciale kjo zgjidhje nuk Ă«shtĂ« e pĂ«rshtatshme, por pĂ«r tĂ« parĂ« si funksionon rrjeti nĂ« njĂ« instalim tĂ« tillĂ« Openstack mjafton. PĂ«r mĂ« tepĂ«r, njĂ« instalim i tillĂ« pĂ«r arsye edukative Ă«shtĂ« edhe mĂ« interesant â sepse mund tĂ« kapim trafikun etj.
Duke qenĂ« se na duhet tĂ« shohim vetĂ«m pjesĂ«n bazike, ne mund tĂ« mos pĂ«rdorim disa rrjete, por tĂ« ngremĂ« gjithçka duke pĂ«rdorur vetĂ«m dy rrjete, ndĂ«rsa rrjeti i dytĂ« nĂ« kĂ«tĂ« model do tĂ« pĂ«rdoret ekskluzivisht pĂ«r qasje nĂ« undercloud dhe serverin DNS. Rrjetet e jashtme pĂ«r momentin nuk do t'i prekim â ky Ă«shtĂ« njĂ« temĂ« pĂ«r njĂ« artikull tĂ« madh tĂ« veçantĂ«.
Le tĂ« fillojmĂ« me rend. Fillimisht, pak teori. Ne do tĂ« instalojmĂ« OpenStack me ndihmĂ«n e TripleO (OpenStack mbi OpenStack). QĂ«llimi i TripleO Ă«shtĂ« qĂ« tĂ« instalojmĂ« OpenStack all-in-one (pra, nĂ« njĂ« nodĂ«), i quajtur undercloud, dhe mĂ« pas tĂ« pĂ«rdorim mundĂ«sitĂ« e OpenStack tĂ« instaluar pĂ«r tĂ« vendosur OpenStack-in e destinuar pĂ«r prodhim, tĂ« quajtur overcloud. Undercloud do tĂ« pĂ«rdorĂ« aftĂ«sinĂ« e ndĂ«rtuar pĂ«r tĂ« menaxhuar serverĂ«t fizikĂ« (bare metal) â projekti Ironic â pĂ«r provizionimin e hypervisorĂ«ve qĂ« do tĂ« kryejnĂ« rolet e nodave compute, control dhe storage. Pra, ne nuk pĂ«rdorim asnjĂ« mjet tĂ« jashtĂ«m pĂ«r vendosjen e OpenStack â ne e vendosim OpenStack me forcat e OpenStack. MĂ« pas, gjatĂ« instalimit, do tĂ« bĂ«het shumĂ« mĂ« e qartĂ«, kĂ«shtu qĂ« mos tĂ« ndalojmĂ« nĂ« kĂ«tĂ« dhe tĂ« vazhdojmĂ« pĂ«rpara.
ShĂ«nim: NĂ« kĂ«tĂ« artikull, pĂ«r qĂ«llime thjeshtĂ«simi, nuk kam pĂ«rdorur izolimin e rrjetit pĂ«r rrjetet e brendshme 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Ă« po ashtu siç do tĂ« ndodhte me pĂ«rdorimin e izolimit, por trafiku do tĂ« kalonte nĂ« tĂ« njĂ«jtin rrjet. PĂ«r njĂ« instalim komercial, natyrisht, duhet tĂ« pĂ«rdoret izolimi me pĂ«rdorimin e VLAN-eve dhe ndĂ«rfaqeve tĂ« ndryshme. PĂ«r shembull, trafiku i menaxhimit tĂ« depove ceph dhe trafiku i tĂ« dhĂ«nave (burimet e makinave nĂ« disqe etj.) gjatĂ« izolimit pĂ«rdorin subnet tĂ« ndryshme (Storage management dhe Storage) dhe kjo e bĂ«n zgjidhjen mĂ« tĂ« qĂ«ndrueshme, duke ndarĂ« kĂ«tĂ« trafik, pĂ«r shembull, nĂ« porte tĂ« ndryshme, ose 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 sinjalizues. NĂ« rastin tonĂ«, ato do tĂ« shkojnĂ« nĂ« tĂ« njĂ«jtin rrjet dhe nĂ« fakt kjo nuk na kufizon nĂ« asnjĂ« mĂ«nyrĂ«.
Shënim: Duke qenë se po planifikojmë të drejtojmë makinat virtuale në një ambient virtual, i bazuar në makina virtuale, së pari duhet të aktivizojmë virtualizimin e vendosur (nested virtualization).
Për të kontrolluar nëse virtualizimi i vendosur është aktivizuar ose jo, mund ta bëni kështu:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Nëse shihni shkronjën N, aktivizoni mbështetje për virtualizimin e vendosur sipas ndonjë udhëzimi që do të gjeni në internet, për shembull. .
Na nevojitet që të krijojmë një skemë të tillë nga makinat virtuale:
Në rastin tim, për lidhjen e makinave virtuale që do të jenë pjesë e instalimit të ardhshëm (dhe unë kam arritur 7, por mund të punohet edhe me 4 nëse nuk keni shumë burime), kam përdorur OpenvSwitch. Kam krijuar një briedh ovs dhe kam lidhur makinat virtuale në të përmes port-groups. Për këtë, krijova një skedar xml të tillë:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67KĂ«tu janĂ« shpallur tre grupe porti â dy akses dhe njĂ« trunk (e fundit ishte e nevojshme pĂ«r serverin DNS, por mund tĂ« kaloni pa tĂ«, ose ta ngrini nĂ« makinĂ«n e hostit â 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 e rregullojmë konfigurimin 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 aksesueshme, pasi ajo 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Ă« humbasĂ« (nĂ«se dikush di si ta mbajĂ« atĂ« nĂ« vend â do tĂ« isha shumĂ« mirĂ«njohĂ«s). Por kjo nuk Ă«shtĂ« aq e rĂ«ndĂ«sishme, pasi kjo adresĂ« do tĂ« na nevojitet vetĂ«m gjatĂ« instalimit dhe nuk do tĂ« jetĂ« e nevojshme, kur Openstack tĂ« jetĂ« instaluar plotĂ«sisht.
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=ttyS0Durante instalimin, vendosni të gjitha parametrat e nevojshëm, si emri i makinës, fjalëkalimet, përdoruesit, serverat ntp, etj., mund të konfiguroni menjëherë edhe portet, por për mua është më e lehtë të hyj në makinë përmes konsolës pas instalimit dhe të rregulloj dosjet përkatëse. Nëse keni një imazh të gatshëm, mund ta përdorni atë, ose mund të veproni si unë - shkarkoni imazhin minimal Centos 7 dhe përdorni atë për instalimin e VM-së.
Pas instalimit të suksesshëm, duhet të keni një makinë virtuale mbi 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 e root-it përmes sudo pa nevojën e futjes së fjalëkalimit:
useradd stack
passwd stack
echo "stack ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackTani përcaktojmë 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ë repositorët dhe instalojmë softin që na nevojitet:
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, atëherë nuk është e nevojshme të futni komandat që lidhen me ceph. Unë përdora versionin Queens, por mund të përdorni çdo version tjetër që ju pëlqen.
Më pas kopjojmë skedarin e konfigurimit të undercloud në direktorinë e shtëpisë së 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ë për 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 = 10Prandaj, le të kalojmë në konfigurimet:
undercloud_hostname â emri i plotĂ« i serverit undercloud, duhet tĂ« pĂ«rputhet me regjistrimin nĂ« serverin DNS
local_ip â adresa lokale undercloud nĂ« anĂ«n e rrjetit tĂ« provisionimit
network_gateway â kjo Ă«shtĂ« e njĂ«jta adresĂ« lokale, e cila do tĂ« funksionojĂ« si gateway pĂ«r akses nĂ« botĂ«n e jashtme gjatĂ« instalimit tĂ« nodave overcloud, gjithashtu pĂ«rputhet me ip-nĂ« lokale
undercloud_public_host â adresa e jashtme API, caktohet ndonjĂ« adresĂ« tĂ« lirĂ« nga rrjeti i provisionimit
undercloud_admin_host adresa e brendshme API, caktohet ndonjë adresë të lirë nga rrjeti i provisionimit
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Ă« pĂ«rshkruar nĂ« bug tracker tĂ« Red Hat
local_interface interfaqja nĂ« rrjetin e provisionimit. Kjo interfaqe do tĂ« rikonfigurohet gjatĂ« implementimit tĂ« undercloud, prandaj undercloud duhet tĂ« ketĂ« dy interfejsa â njĂ« pĂ«r akses dhe njĂ« tjetĂ«r pĂ«r provisionim
local_mtu â MTU. PasiqĂ« kemi laborator testimi dhe MTU mâi Ă«shtĂ« 1500 nĂ« portet e switch-it OVS, duhet vendosur nĂ« vlerĂ«n 1450, nĂ« mĂ«nyrĂ« qĂ« tĂ« kalojnĂ« paketat e inkapsuluara nĂ« VxLAN
network_cidr â rrjeti i provisionimit
masquerade â pĂ«rdorimi i NAT pĂ«r akses nĂ« rrjetin e jashtĂ«m
masquerade_network â rrjeti qĂ« do tĂ« NAT-ojĂ«
dhcp_start â adresa fillestare e grupit tĂ« adresave, nga e cila do tĂ« caktohen adresat pĂ«r nodat gjatĂ« deploy-it tĂ« overcloud
dhcp_end â adresa pĂ«rfundimtare e grupit tĂ« adresave, nga e cila do tĂ« caktohen adresat pĂ«r nodat gjatĂ« deploy-it tĂ« overcloud
inspection_iprange â grupi i adresave tĂ« nevojshme pĂ«r introspeksion (nuk duhet tĂ« prekĂ« grupin e mĂ«sipĂ«rm)
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 është përshkruar skedari, mund të jepni komandën për deploy-in e undercloud:
openstack undercloud install
Procedura zgjat nga 10 deri në 30 minuta në varësi të harduerit tuaj. Në fund, duhet të shihni një dalje të tillë:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Instalimi i Undercloud përfundoi.
Skedari që përmban fjalëkalimet e këtij instalimi është në
/home/stack/undercloud-passwords.conf.
ĂshtĂ« gjithashtu njĂ« skedĂ« stackrc nĂ« /home/stack/stackrc.
Këto skeda janë të nevojshme për të ndërvepruar me shërbimet OpenStack dhe duhet të
garantohet siguria e tyre.
#############################################################################Kjo dalje tregon se keni instaluar me sukses undercloud dhe tani mund të kontrolloni gjendjen e undercloud dhe të kaloni në instalimin e overcloud.
Nëse shikoni daljen ifconfig, do të shihni se është shfaqur një interfejs ri bridge
[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 0Ky ky këtij interfaci tani do të kryejmë punën për implementimin e overcloud.
Nga dalja më poshtë shihet se të gjitha shërbimet tona 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ë 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
NĂ« kĂ«tĂ« moment kemi vetĂ«m undercloud, dhe na mungojnĂ« nodet nga tĂ« cilat do tĂ« krijohet overcloud. Prandaj, hapi i parĂ« Ă«shtĂ« tĂ« implementojmĂ« makinĂ«n virtuale qĂ« na nevojitet. GjatĂ« implementimit, undercloud do tĂ« instalojĂ« vetĂ« OS-nĂ« dhe softin e nevojshĂ«m nĂ« makinat e overcloud â kĂ«shtu qĂ« nuk Ă«shtĂ« nevoja tĂ« instalojmĂ« plotĂ«sisht makinĂ«n, vetĂ«m tĂ« krijojmĂ« njĂ« disk (ose disqe) dhe tĂ« pĂ«rcaktojmĂ« parametrat e saj â nĂ« fakt, marrim njĂ« server tĂ« zbrazĂ«t pa sistem operativ tĂ« instaluar.
Kalojmë në dosjen me disqet e makinave tona virtuale dhe do të krijojmë disqet me madhësinë e nevojshme:
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 qenë se veprojmë si root, duhet të ndryshojmë pronarin e këtyre disqeve për të shmangur probleme 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]# Kujtesë: nëse nuk planifikoni të instaloni ceph për qëllime studimi, mos krijoni më pak se 3 node me të paktën dy disqet, dhe në template shënoni se do të përdoren disqe virtuale vda, vdb etj.
Shumë mirë, tani duhet t'i definim 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 komandat âprint-xml > \/tmp\/storage-1.xml, qĂ« krijon njĂ« skedar xml me pĂ«rshkrimin e çdo makine nĂ« dosjen \/tmp\/, nĂ«se nuk e shtoni, nuk do tĂ« jeni nĂ« gjendje tĂ« definoni makinat virtuale.
Tani duhet t'i definim 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 Ă«shtĂ« njĂ« detaj â tripleO pĂ«rdor IPMI pĂ«r tĂ« menaxhuar serverat gjatĂ« instalimit dhe introspeksionit.
Introspeksioni Ă«shtĂ« procesi i inspektimit tĂ« harduerit pĂ«r tĂ« marrĂ« parametrat e nevojshĂ«m pĂ«r provizionimin e mĂ«tejshĂ«m tĂ« nodave. Introspeksioni realizohet me ndihmĂ«n e ironic â shĂ«rbimi i dedikuar pĂ«r punĂ« me serverat bare metal.
Por kĂ«tu kemi njĂ« problem â nĂ«se pĂ«r serverĂ«t fizikĂ« IPMI Ă«shtĂ« njĂ« port i veçantĂ« (ose port i ndarĂ«, por kjo nuk ka rĂ«ndĂ«si), pĂ«r makinat virtuale nuk ka porta tĂ« tilla. KĂ«tu na ndihmon njĂ« tricks e quajtur vbmc â njĂ« utilitar qĂ« lejon tĂ« emulohet njĂ« port IPMI. Ky detaj duhet marrĂ« parasysh sidomos nga ata qĂ« dĂ«shirojnĂ« tĂ« ngrisin njĂ« laborator tĂ« tillĂ« mbi hypervisorin ESXI â natyrisht, nuk e di se a ekziston njĂ« analog i vbmc nĂ« tĂ«, prandaj Ă«shtĂ« mirĂ« t'i kushtohet vĂ«mendje kĂ«tij problemi para se tĂ« filloni gjithçka.
Instalojmë vbmc:
yum install yum install python2-virtualbmcNëse sistemi juaj nuk mund ta gjejë paketën, atëherë shtoni depandencën:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmTani konfiguroni utilitarin. Këtu është gjithçka shumë e thjeshtë. Tani është logjike që në listën vbmc të mos ketë asnjë server
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Që të shfaqen ata, duhet t'i shpallni manualisht në këtë mënyrë:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Mendoj që sintaksa e komandës është e qartë dhe pa shpjegim. Megjithatë, derisa të gjitha sesionet tona janë në statusin DOWN. Për t'i kaluar ato në statusin UP, është e nevojshme t'i ndizni:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Instance vBMC për domenin control-1 filloi
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Instance vBMC për domenin storage-1 filloi
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Instance vBMC për domenin storage-2 filloi
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Instance vBMC për domenin compute-1 filloi
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Instance vBMC për domenin compute-2 filloi
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Emri i Domenit | Status | Adresa | Porta |
+-------------+---------+---------+------+
| compute-1 | në punë | :: | 7004 |
| compute-2 | në punë | :: | 7005 |
| control-1 | në punë | :: | 7001 |
| storage-1 | në punë | :: | 7002 |
| storage-2 | në punë | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Dhe hapi i fundit â duhet tĂ« rregullojmĂ« rregullat e firewall-it (ose ta fikim atĂ« 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, le të hyjmë në undercloud dhe të kontrollojmë nëse gjithçka funksionon. Adresa e makinës host është 192.168.255.200, në undercloud ne shtuam paketën e nevojshme ipmitool gjatë përgatitjes për deploy:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 statusi i energjisë
Energjia e shasisë është e fikur
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 energji on
Kontrolli i Energjisë së Shasisë: Lart/Në
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Emri Shtet
----------------------------------------------------
6 serveri-dns në punë
64 undercloud në punë
65 control-1 në punëSiç mund ta shihni, ne kemi filluar me sukses nodën control përmes vbmc. Tani le të fikim atë dhe të vazhdojmë:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 energji off
Kontrolli i Energjisë së Shasisë: Poshtë/Fikur
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 statusi i energjisë
Energjia e shasisë është e fikur
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Emri Shtet
----------------------------------------------------
6 serveri-dns në punë
64 undercloud në punë
- compute-1 i fikur
- compute-2 i fikur
- control-1 i fikur
- storage-1 i fikur
- storage-2 i fikur
[root@hp-gen9 ~]#Hapi tjetĂ«r â Ă«shtĂ« introspektimi i nodĂ«ve, mbi tĂ« cilat do tĂ« instalohet overcloud. PĂ«r kĂ«tĂ« na nevojitet tĂ« pĂ«rgatisim njĂ« skedar json me pĂ«rshkrimin e nodĂ«ve tona. Vini re se, ndryshe nga instalimi nĂ« serverĂ« tĂ« papĂ«rpunuar, skedari ka portin ku ka nisur vbmc pĂ«r secilĂ«n 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 ndërfaqe, por në këtë rast kjo nuk ka rëndësi, në këtë instalim na mjafton edhe një.
Tani po përgatisim skedarin json. Na nevojitet të saktësojmë adresën MAC të portit, përmes të cilit do të kryhet provisionimi, parametrat e nodave, t'i caktojmë emrat dhe të specifikojmë si të arrijmë në ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Tani na nevojitet të përgatisim imazhet për ironic. Për këtë shkak 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 ~]$Duke imazhet në undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~\/images\/
Imazhi "overcloud-full-vmlinuz" u ngarkua.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Emri | Formati i Diskut | Madhësia | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | aktiv |
+--------------------------------------+------------------------+-------------+---------+--------+
Imazhi "overcloud-full-initrd" u ngarkua.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Emri | Formati i Diskut | Madhësia | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | aktiv |
+--------------------------------------+-----------------------+-------------+----------+--------+
Imazhi "overcloud-full" u ngarkua.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Emri | Formati i Diskut | Madhësia | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | aktiv |
+--------------------------------------+----------------+-------------+------------+--------+
Imazhi "bm-deploy-kernel" u ngarkua.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Emri | Formati i Diskut | Madhësia | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | aktiv |
+--------------------------------------+------------------+-------------+---------+--------+
Imazhi "bm-deploy-ramdisk" u ngarkua.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Emri | Formati i Diskut | Madhësia | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | aktiv |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Verifikojmë që të gjitha imazhet janë ngarkuar
(undercloud) [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 |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$NjĂ« detaj tjetĂ«r â duhet tĂ« shtojmĂ« serverin dns:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI është e vjetruar dhe do të hiqet në të ardhmen. Përdorni CLI openstack në vend.
Subneti i përditësuar: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Tani mund të japim urdhërin për introspezion:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Filloi Workflow Mistral tripleo.baremetal.v1.register_or_update u nisem. ID i ekzekutimit: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Po presim mesazhet në radhën 'tripleo' pa kufizim kohor.
5 nodet u transferuan me sukses në gjendjen "e menaxhueshme".
Nodë e regjistruar me sukses UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Nodë e regjistruar me sukses UUID b89a72a3-6bb7-429a-93bc-48393d225838
Nodë e regjistruar me sukses UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Nodë e regjistruar me sukses UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Nodë e regjistruar me sukses UUID 766ab623-464c-423d-a529-d9afb69d1167
Po presim përfundimin e introspeksionit...
Filloi Workflow Mistral tripleo.baremetal.v1.introspect. ID i ekzekutimit: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Po presim mesazhet në radhën 'tripleo' pa kufizim kohor.
Introspeksioni i nodës b89a72a3-6bb7-429a-93bc-48393d225838 përfundoi. Statusi:SUCCESS. Gabimet:Asnjë
Introspeksioni i nodës 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e përfundoi. Statusi:SUCCESS. Gabimet:Asnjë
Introspeksioni i nodës bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 përfundoi. Statusi:SUCCESS. Gabimet:Asnjë
Introspeksioni i nodës 766ab623-464c-423d-a529-d9afb69d1167 përfundoi. Statusi:SUCCESS. Gabimet:Asnjë
Introspeksioni i nodës b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 përfundoi. Statusi:SUCCESS. Gabimet:Asnjë
Introspeksioni i suksesshëm për 5 nodet.
Filloi Workflow Mistral tripleo.baremetal.v1.provide. ID i ekzekutimit: f5594736-edcf-4927-a8a0-2a7bf806a59a
Po presim mesazhet në radhën 'tripleo' pa kufizim kohor.
5 nodet u transferuan me sukses në gjendjen "të disponueshme".
(undercloud) [stack@undercloud ~]$Siç e shihni nga rezultati, gjithçka përfundoi pa gabime. Le të kontrollojmë nëse të gjitha nodet janë në gjendjen e disponueshme:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Emri | UUID i Instancës | Gjendja e Energjisë | Gjendja e Furnizimit | Mirëmbajtja |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | kontroll-1 | Asnjë | ndaluar | e disponueshme | E pavërtetuar |
| b89a72a3-6bb7-429a-93bc-48393d225838 | ruajtje-1 | Asnjë | ndaluar | e disponueshme | E pavërtetuar |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | ruajtje-2 | Asnjë | ndaluar | e disponueshme | E pavërtetuar |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | llogaritje-1 | Asnjë | ndaluar | e disponueshme | E pavërtetuar |
| 766ab623-464c-423d-a529-d9afb69d1167 | llogaritje-2 | Asnjë | ndaluar | e disponueshme | E pavërtetuar |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Nëse nodet janë në një gjendje tjetër, zakonisht e menaxhueshme, atëherë ka ndodhur diçka e gabuar dhe duhet të kontrolloni logun, për të parë pse ndodhi kështu. Mbani parasysh se në këtë skenar po përdorim virtualizimin dhe mund të kenë ndodhur gabime në lidhje me përdorimin e makinave virtuale ose vbmc.
MĂ« pas na duhet tĂ« tregojmĂ« se cila nodĂ« do tĂ« kryejĂ« cilin funksion â domethĂ«nĂ« tĂ« specifikojmĂ« profilin me tĂ« cilin nodĂ« do tĂ« vihet nĂ« funksion:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$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-d9afb69d1167Verifikoni nëse kemi bërë gjithçka siç duhet:
(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ë në rregull, jepni komandën për të bërë deploy 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 tĂ« vĂ«rtetĂ« do tĂ« pĂ«rdoren natyrisht modele tĂ« personalizuara, por nĂ« rastin tonĂ« kjo do ta komplikonit shumĂ« procesin, sepse duhet tĂ« shpjegojmĂ« çdo modifikim nĂ« model. Siç u tha mĂ« parĂ« â edhe njĂ« instalim i thjeshtĂ« do tĂ« mjaftonte pĂ«r tĂ« parĂ« se si funksionon.
VĂ«rejtje: variabla âlibvirt-type qemu nĂ« kĂ«tĂ« rast Ă«shtĂ« e nevojshme, sepse ne do tĂ« pĂ«rdorim virtualizim tĂ« ngjitur. NĂ« tĂ« kundĂ«rt, nuk do tĂ« mundni tĂ« hapni makinat virtuale.
Tani keni rreth një orë, ndoshta edhe më shumë (varet nga mundësitë e harduerit) dhe ju mbetet të shpresoni se pas kalimit të këtij kohë do të shihni një mesazh të tillë:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE u përfundua me sukses
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 nuk u gjet në /home/stack/.ssh/known_hosts
Filloi Mistral Workflow tripleo.deployment.v1.get_horizon_url. ID e Ekzekutimit: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Skeda rc e Overcloud: /home/stack/overcloudrc
Overcloud u instalua
(undercloud) [stack@undercloud ~]$Tani keni një version pothuajse të plotë të OpenStack, në të cilin mund të mësoni, të provoni eksperimentet etj.
TĂ« kontrollojmĂ« qĂ« gjithçka tĂ« funksionojĂ« normalisht. NĂ« drejtorinĂ« e shtĂ«pisĂ« sĂ« pĂ«rdoruesit stack ka dy skedarĂ« â njĂ« Ă«shtĂ« stackrc (pĂ«r menaxhimin e undercloud) dhe tjetri overcloudrc (pĂ«r menaxhimin e overcloud). KĂ«ta skedarĂ« duhet tĂ« shĂ«nohen si source, pasi pĂ«rmbajnĂ« informacionin e nevojshĂ«m pĂ«r autentifikim.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$NĂ« instalimin tim, nevojitet njĂ« shtesĂ« e vogĂ«l â tĂ« shtoj njĂ« rrugĂ« te kontrolluesi, pasi makina me tĂ« cilĂ«n po punoj ndodhet nĂ« njĂ« rrjet tjetĂ«r. PĂ«r kĂ«tĂ«, do tĂ« hyj nĂ« control-1 me llogarinĂ« heat-admin dhe do tĂ« vendos rrugĂ«n.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Tani tani mund të hyni në horizont. Të gjitha informacionet - adresat, loguina dhe fjalëkalimi - ndodhen në skedarin /home/stack/overcloudrc. Skema përfundimtare duket si më poshtë:
Për të thënë të vërtetën, në instalimin tonë, adresat e makinave u jepeshin përmes DHCP dhe siç e shihni, ato jepen 'në mënyrë të rastësishme'. Mund të caktoni me forcë se cilat adresa duhet të ngjiten me cilat makina gjatë deplyimit, nëse është e nevojshme.
Si kalon trafiku ndërmjet makinave virtuale?
Në këtë artikull do të shqyrtojmë tre variante të kalimit të trafikut.
- Dy makina në një hipervizor në një rrjet L2
- Dy makina në hipervizorë të ndryshëm në një rrjet L2
- Dy makina në rrjete të ndryshme (rutinimi midis rrjeteve)
ĂĂ«shtjet me daljen nĂ« botĂ«n e jashtme pĂ«rmes rrjetit external, duke pĂ«rdorur adresa tĂ« lundrueshme, si dhe routingu tĂ« shpĂ«rndarĂ« do tĂ« shqyrtohen herĂ«n tjetĂ«r, pĂ«r momentin do tĂ« ndalojmĂ« nĂ« trafik tĂ« brendshĂ«m.
Për të kontrolluar do të mbledhim një skemë të tillë:
Kemi krijuar 4 makina virtuale - 3 në një rrjet L2 - net-1, dhe një tjetër në rrjetin net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Le të shohim se në cilët 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 ~]$
Makinë vm-1 dhe vm-3 ndodhen në compute-0, ndërsa makinat vm-2 dhe vm-4 ndodhen në nodin compute-1.
Përveç kësaj, është krijuar një router virtual për të mundësuar routing midis rrjeteve të cituara:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Routeri ka dy porte virtuale, të cilat funksionojnë si kalime 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ë shikojmë se si qarkullon trafiku, le të shqyrtojmë se çfarë kemi në këtë moment në nodin e kontrollit (i cili gjithashtu është nodi i rrjetit) dhe në nodin compute. Le të fillojmë me nodin compute.
[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 tre bridge-ov ovs â br-int, br-tun, br-ex. NdĂ«rmjet tyre, siç e shohim, ka njĂ« set interfesh. PĂ«r ta thjeshtuar perceptimin, do tĂ« vizatojmĂ« tĂ« gjitha kĂ«to interfesa nĂ« njĂ« skemĂ« dhe do tĂ« shohim se çfarĂ« do tĂ« rezultojĂ«.
Në adresat ku janë ngritur tunellet VxLAN, duket se një tunel është ngritur në compute-1 (192.168.255.26), ndërsa tuneli tjetër shikon në control-1 (192.168.255.15). Por më interesant është se br-ex nuk ka interfesa fizike, dhe nëse shikojmë se cilat flow janë të konfiguruara, shihet se ky bridge aktualisht mund të heqë vetëm trafik.
[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ç duket nga dalja, adresa është e fikstur direkt në portin fizik, dhe jo në një bridge virtual.
[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 poshtë.
Përveç kësaj, në këtë bridge aktualisht nuk ka burime tjera për trafik, përveç nga ky interfes (shkëputja me br-int), dhe gjëja më e dukshme është që në bridge kanë mbërritur trafiku BUM.
Kështu që nga kjo nyje, trafiku mund të largohet vetëm përmes tunelit VxLAN dhe asnjë tjetër. Megjithatë, nëse aktivizoni DVR, situata do të ndryshojë, por për këtë do të diskutojmë në një tjetër rast. Kur përdorni izolimin e rrjeteve, për shembull me VLAN-e, do të keni më shumë se një ndërfaqe L3 në VLAN-in 0, por disa ndërfaqe. Megjithatë, trafiku VxLAN do të dalë nga nyja në të njëjtën mënyrë, por i inkapsuluar gjithashtu në një VLAN të caktuar.
Pas diskutimit mbi nyjën compute, kalojmë te nyja 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 gjithçka është e njëjtë, megjithatë adresa IP tani gjendet jo në ndërfaqen fizike, por në urë virtuale. Kjo është bërë sepse kjo port është porta përmes së cilës 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 ~]$ Kjo port është lidhur me urën br-ex dhe duke qenë se nuk ka asnjë etiketë VLAN mbi të, kjo port konsiderohet port trun, në të cilin janë të lejuara të gjitha VLAN-et, aktualisht trafiku del jashtë pa etiketë, që tregon VLAN-ID 0 në daljen e mësipërme.
Gjithçka tjetër në këtë moment është e ngjashme me nyjën compute - të njëjtat ure, të njëjtat tunel të cilat shkojnë në dy nyjat compute.
Ne do tĂ« diskutoni mbi nodet e ruajtjes nĂ« kĂ«tĂ« artikull, por pĂ«r ta kuptuar, Ă«shtĂ« e nevojshme tĂ« thuhet se pjesa rrjetĂ« e kĂ«tyre nodĂ«ve Ă«shtĂ« tejet e thjeshtĂ«. NĂ« rastin tonĂ«, aty ka vetĂ«m njĂ« port fizik (eth0) me njĂ« adresĂ« IP tĂ« lidhur dhe mjaft. Nuk ka asnjĂ« tunel VxLAN, as bridge tunelesh etj. â nuk ka OVS fare, pasi nuk ka kuptim. Kur pĂ«rdoret izolimi i rrjeteve â nĂ« kĂ«tĂ« nod do tĂ« ketĂ« dy ndĂ«rfaqe (porte fizike, bodĂ« ose thjesht dy VLANs â kjo nuk ka rĂ«ndĂ«si â varet nga çfarĂ« dĂ«shironi) â njĂ« pĂ«r menaxhim, tjetri pĂ«r trafik (shkrimi nĂ« disk VM, leximi nga disku etj.).
Kemi kaluar nĂ« kuptimin se çfarĂ« kemi nĂ« nodet nĂ« mungesĂ« tĂ« shĂ«rbimeve. Tani do tĂ« fillojmĂ« 4 makina virtuale dhe do tĂ« shohim se si do tĂ« ndryshojĂ« skema e pĂ«rshkruar mbi â duhet tĂ« shfaqen porte, router virtuale etj.
Aktualisht, rrjeti ynë duket kështu:
Kemi dy makina virtuale në çdo nod kompjuterik. Në shembullin compute-0, le të shohim se si janë të gjitha të lidhura.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Emri Shteti
----------------------------------------------------
1 instance-00000001 duke funksionuar
3 instance-00000003 duke funksionuar
[heat-admin@overcloud-novacompute-0 ~]$ MakinĂ«s i takon vetĂ«m njĂ« ndĂ«rfaqe virtuale â tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Ndërfaqe Tip Burimi Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Kjo ndërfaqe shikon në bridge-in Linux:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
emri i bridge id e bridge STP e aktivizuar ndërfaqet
docker0 8000.0242904c92a8 jo
qbr5bd37136-47 8000.5e4e05841423 jo qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 jo qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Siç duket nga dalja, nĂ« bridge ka vetĂ«m dy ndĂ«rfaqe â tap95d96a75-a0 dhe qvb95d96a75-a0.
Këtu është e rëndësishme të ndalemi pak te llojet e pajisjeve virtuale në rrjet në OpenStack:
vtap â ndĂ«rfaqe virtuale, e lidhur me instancĂ«n (VM)
qbr â bridge Linux
qvb dhe qvo â çift dhe ueth, e lidhur me bridge Linux dhe bridge Open vSwitch
br-int, br-tun, br-vlan â bridges tĂ« Open vSwitch
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Ă«rdorur nga pajisjet virtuale pĂ«r t'u lidhur me OVS
Si e kuptoni, nëse kemi një port në bridge që është qvb95d96a75-a0, atëherë qëndron diçka tjetër, e cila logjikisht duhet të quhet qvo95d96a75-a0. Të shohim cilët porte janë 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 ndodhet në br-int. Br-int luan rolin e një switch-i, që përfundon portet e makinave virtuale. Përveç qvo95d96a75-a0, në daljen shihet porti qvo5bd37136-47. Kështu, skema jonë tani duket kështu:
Pyetja qĂ« duhet menjĂ«herĂ« tĂ« shqetĂ«sojĂ« lexuesin e vĂ«mendshĂ«m â pĂ«rse njĂ« linux bridge midis portit tĂ« makinĂ«s virtuale dhe portit OVS? Arsyeja Ă«shtĂ« se pĂ«r tĂ« mbrojtur makinĂ«n pĂ«rdoren security groups, tĂ« cilat nuk janĂ« gjĂ« tjetĂ«r veçse iptables. OVS nuk punon me iptables, prandaj u shpik njĂ« âhackâ i tillĂ«. MegjithatĂ«, ky po bie nĂ« pritje â qasja e conntrack po vjen nĂ« versionet e reja.
Kështu që skema në fund duket kështu:
Dy makina në një hipervizor në një rrjet L2
Duke qenë se këto dy VM ndodhen në të njëjtin rrjet L2 dhe në të njëjtin hypervisor, atëherë trafiku midis tyre do të kalojë logjikisht lokalisht përmes br-int, për shkak se 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
Tani le të shohim se si do të kalojë traffiku midis dy makinave në të njëjtin rrjet L2, por që ndodhen në hypervisora të ndryshëm. Nëse duhet të jemi të sinqertë, shumëçka nuk do të ndryshojë, trafiku midis hypervisorëve do të kalojë përmes tunelit vxlan. Të dëshmojmë me një shembull.
Adresat e makinave virtuale midis të cilave do të shohim trafikun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Ndërfaqe Tip Burimi 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 ~]$ Shikojmë 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 ~]Trafiku duhet tĂ« shkojĂ« nĂ« portin 2 â le tĂ« shohim se ç'Ă«shtĂ« ky 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Ă« njĂ« ndĂ«rfaqe 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 paketizohet në VxLAN dhe dërgohet në portin 2. Le të shohim ku çon porta 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ë tuneli 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 ~]$Shkoni në compute-1 dhe shikoni se çfarë ndodh 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-i është në tabelën e përparimit br-int në compute-1, dhe siç duket nga rezultati më sipër, ai është i dukshëm përmes portit 2, i cili është porti drejt 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:46Dhe më pas shikojmë se në br-int në compute-1 ka një MAC për destinacionin:
[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 ~]$ Kështu që paketa e marrë do të shkojë në portin 3, ku ndodhet makina virtuale instance-00000003.
Të gjithë bukuria e implementimit të OpenStack për t'u mësuar në infrastrukturën virtuale është se ne mund ta kapim pa probleme trafikun midis hypervisorëve dhe të shohim se çfarë po ndodh me të. Këtë do ta bëjmë tani, do të nisnim tcpdump në portin vnet në drejtim të compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: duke dëgjuar në vnet3, tipi i lidhjes EN10MB (Ethernet), madhësia e kapjes 262144 bytes
***************** omituar *******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), gjatësi 134)
192.168.255.19.39096 > 192.168.255.26.4789: [pa cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), gjatësi 84)
10.0.1.85 > 10.0.1.88: ICMP kërkesë echo, id 5634, seq 16, gjatësi 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), gjatësi 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [pa cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [asnjë], proto ICMP (1), gjatësi 84)
10.0.1.88 > 10.0.1.85: ICMP përgjigje echo, id 5634, seq 16, gjatësi 64
***************** omituar *******************Rreshti i parë tregon se paketa me adresë 10.0.1.85 shkon në adresën 10.0.1.88 (trafiku ICMP), për më tepër, ajo është e mbështjellë në një paketë VxLAN me vni 22 dhe paketa shkon nga hosti 192.168.255.19 (compute-0) në hostin 192.168.255.26 (compute-1). Mund të verifikojmë që VNI përputhet me atë që është e shënuar në ovs.
TĂ« kthehemi te ky rresht actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 â kjo Ă«shtĂ« vni nĂ« sistemin hexadecimal. TĂ« konvertojmĂ« kĂ«tĂ« numĂ«r nĂ« sistemin decimal:
16 = 6*16^0+1*16^1 = 6+16 = 22Pra, vni është i saktë.
Rreshti i dytë tregon trafikun në drejtim të kundërt, por nuk ka nevojë për shpjegim, aty është e qartë.
Dy makina në rrjete të ndryshme (rrugëzim midis rrjeteve)
Rasti i fundit pĂ«r sot â Ă«shtĂ« rrugĂ«zimi midis rrjeteve brenda njĂ« projekti duke pĂ«rdorur njĂ« router virtual. Ne po shqyrtojmĂ« rastin pa DVR (atĂ« do ta shqyrtojmĂ« nĂ« njĂ« artikull tjetĂ«r), prandaj rrugĂ«zimi ndodh nĂ« nodin e rrjetit. NĂ« rastin tonĂ«, nodi i rrjetit nuk Ă«shtĂ« nxjerrĂ« si njĂ« entitet i veçantĂ« dhe ndodhet nĂ« nodin kontrol.
Fillimisht, le të shohim se rrugëzimi funksionon:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 bytes të dhënash
64 bytes nga 10.0.2.8: seq=0 ttl=63 kohë=7.727 ms
64 bytes nga 10.0.2.8: seq=1 ttl=63 kohë=3.832 ms
^C
--- statistikat e ping për 10.0.2.8 ---
2 paketa të dërguara, 2 paketa të pranuara, 0% humbje pakete
koha e kthimit min/mesatar/max = 3.832/5.779/7.727 msSepse në këtë rast paketa duhet të shkojë në portën e hyrjes dhe atje të bëhet rrugëzim, na nevojitet adresë MAC e portës, për çfarë do të shohim tabelën ARP në instancë:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) në fa:16:3e:c4:64:70 [ether] në eth0
host-10-0-1-1.openstacklocal (10.0.1.1) në fa:16:3e:e6:2c:5c [ether] në eth0
host-10-0-1-90.openstacklocal (10.0.1.90) në fa:16:3e:83:ad:a4 [ether] në eth0
host-10-0-1-88.openstacklocal (10.0.1.88) në fa:16:3e:72:ad:53 [ether] në eth0Tani është një shikim se ku duhet të dërgohet trafiku me destinacionin (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 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 ~]$ E gjitha është logjike, trafiku shkon në br-tun. Le të shohim në cilin tunel vxlan do të përfshihet:
[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 ~]$ Porta e tretë është një tunel 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 ~]$ I cili drejtohet tek noda 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 si do të ndodhë rutimi.
Siç e mbani mend, nodën e kontrollit duket saktësisht si nodo e llogarisë - të njëjtat tri urat, vetëm se br-ex kishte një port fizik, përmes të cilit nodë mund të dërgonte trafik jashtë. Krijimi i instancave ndryshoi konfigurimin në nodat e llogarisë - u shtuan bridge linux, iptables dhe interfecet në nodë. Krijimi i rrjeteve dhe routerit 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 përparimit të br-int në nodën e kontrollit. Le të kontrollojmë se a është atje dhe ku 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 ~]$ MAC adresi është i dukshëm nga porta qr-0c52b15f-8f. Nëse kthehemi në listën e porteve virtuale në Openstack, ky lloj porti përdoret për t'u lidhur me OVS të ndryshimeve virtuale. Më saktësisht qr - është një port në drejtim të routerit virtual, i cili paraqitet si një namespace.
Le të shohim se cilat namespace janë 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 ~]$ Tre instanca të plota. Por gjykuar nga emrat, mund të bëhet një hipotezë mbi qëllimin e secilës prej tyre. Do të rikthehemi te instancat me ID 0 dhe 1 më vonë, 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 kemi dy porta të brendshme, të cilat i kemi krijuar më parë. Të dy portat virtuale janë të shtuar në br-int. Le të kontrollojmë adresën MAC të portës qr-0c52b15f-8f, pasi trafiku, gjykuar nga adresa MAC e destinacionit, 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 standarde të rrugëzimit. Duke marrë parasysh që trafiku i destinuar për hostin 10.0.2.8, duhet të dalë përmes ndërfaqes së dytë qr-92fa49b5-54 dhe të shkojë përmes tunelit vxlan në nodin 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 ~]$ Të gjitha janë logjike, pa surpriza. Të shohim se nga se cilat adresat MAC të hostit 10.0.2.8 janë të dukshme 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 ~]$ Sipas zakonit, trafiku shkon në br-tun, le të shohim se në cilin tunel do të 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 po tĂ« shkon nĂ« tunel deri nĂ« compute-1. Dhe tek compute-1 gjithçka Ă«shtĂ« e thjeshtĂ« â nga br-tun pako kalon nĂ« br-int dhe nga aty nĂ« ndĂ«rfaqen e makinĂ«s 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 ky është me të vërtetë ndërfaqja e duhur:
[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 ~]$ Realizimi i gjithë rrugës së paketës. Mendoj se keni vërejtur se trafiku kaloi përmes tunelesh të ndryshme vxlan dhe doli me VNI të ndryshme. Le të shikojmë se cilat janë këto VNI, pas së cilës do të mbledhim një dump në portin e nodës së kontrollit dhe do të sigurohemi që trafiku kalon ashtu siç është përshkruar më lart.
Kështu, tuneli deri në compute-0 ka veprimin e mëposhtëm: 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ë veprimin: 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ë shikojmë dumpin:
[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*******************Paketa e 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 së cilës është një paketë ICMP nga hosti 10.0.1.85 në hostin 10.0.2.8. Siç e llogaritëm më sipër, vni përputhet me atë që pamë në daljet.
Paketa e dytë është një paketë 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ë një paketë ICMP nga hosti 10.0.1.85 në hostin 10.0.2.8. Siç e llogaritëm më sipër, vni përputhet me atë që pamë në daljet.
Dy paketat në vazhdim janë trafik i kthen nga 10.0.2.8 në 10.0.1.85.
Kështu që në fund kemi një skemë të tillë për nodën e kontrollit:
Duket se është gjithçka? Harrojmë për 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 rreth arkitekturĂ«s sĂ« platformĂ«s nĂ« re â do ishte mirĂ« qĂ« makina tĂ« merrnin adresat automatikisht nga serveri DHCP. KĂ«to janĂ« dy serverĂ« DHCP pĂ«r dy rrjetet tona 10.0.1.0/24 dhe 10.0.2.0/24.
Le ta kontrollojmĂ« se kĂ«shtu Ă«shtĂ«. NĂ« kĂ«tĂ« namespace ka vetĂ«m njĂ« adresĂ« â 10.0.1.1 â adresa e 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 0Të shohim nëse proceset që përmbajnë në emrin e tyre qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 në nodën kontrolluese:
[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 ~]$ Ka një proces të tillë dhe duke iu referuar informacionit të paraqitur në daljen e mësipërme, mund të shohim se çfarë kemi renditur aktualisht:
[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 këtë grup shërbimesh në nodën kontrolluese:
Mbani tĂ« keni parasysh qĂ« kĂ«to janĂ« vetĂ«m 4 makina, 2 rrjete tĂ« brendshme dhe njĂ« ruter virtual... Tani kĂ«tu nuk kemi rrjete tĂ« jashtme, njĂ« mori projektesh tĂ« ndryshme, secila me rrjetet e saj (tĂ« tejkalueshme), dhe ruterin e shpĂ«rndarĂ« e kemi fikur; nĂ« fund tĂ« fundit, nĂ« skenarin testues kishte vetĂ«m njĂ« nodĂ« kontrolli (pĂ«r qĂ«ndrueshmĂ«ri duhet tĂ« ketĂ« njĂ« kuorum prej tre nodash). ĂshtĂ« logjike qĂ« nĂ« tregtinĂ« reale 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Ă«rtimi, sigurisht qĂ« Ă«shtĂ« e rĂ«ndĂ«sishme, por sa i pĂ«rket funksionimit tĂ« gjithĂ« strukturĂ«s â nuk do tĂ« ketĂ« ndonjĂ« ndryshim tĂ« rĂ«ndĂ«sishĂ«m... pĂ«rveç se kur tĂ« integroni ndonjĂ« SDN tĂ« markĂ«s. Por kjo Ă«shtĂ« njĂ« histori krejt tjetĂ«r.
Shpresoj se ishte interesante. NĂ«se keni vĂ«rejtje/shtesa ose nĂ«se kam gĂ«njyer ndonjĂ«herĂ« (jam njeri dhe mendimi im gjithmonĂ« do tĂ« jetĂ« subjektiv) â shkruani çfarĂ« duhet tĂ« korrigjojmĂ«/shtojmĂ« â do ta rregullojmĂ«/shtojmĂ« gjithçka.
NĂ« pĂ«rfundim, do tĂ« doja tĂ« them disa fjalĂ« mbi krahasimin e Openstack (si versioni vanilla, ashtu edhe versionet e markave) me zgjidhjen cloud nga kompania VMWare â shumĂ« shpesh mĂ« kanĂ« bĂ«rĂ« kĂ«tĂ« pyetje gjatĂ« dy viteve tĂ« fundit dhe tashmĂ« jam lodhur nga ajo, por megjithatĂ«. NĂ« opinionin tim, kĂ«to dy zgjidhje janĂ« shumĂ« tĂ« vĂ«shtira pĂ«r t'u krahasuar, por mund tĂ« themi me siguri se tĂ« dyja kanĂ« disavantazhe dhe duke zgjedhur njĂ« nga kĂ«to duhen peshuar tĂ« gjitha pĂ«rparĂ«sitĂ« dhe disavantazhet.
NĂ«se OpenStack Ă«shtĂ« njĂ« zgjidhje e udhĂ«hequr nga komuniteti, atĂ«herĂ« VMWare ka tĂ« drejtĂ« tĂ« bĂ«jĂ« vetĂ«m atĂ« qĂ« dĂ«shiron (lexo â 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 dhe tĂ« rĂ«ndĂ«sishme â mund tĂ« largohesh nga OpenStack, pĂ«r shembull, nga Nokia dhe tĂ« kalosh lehtĂ«sisht nĂ« zgjidhjen nga Juniper (Contrail Cloud), por me VMWare do t'ju jetĂ« shumĂ« e vĂ«shtirĂ« tĂ« largoheni. PĂ«r mua, kĂ«to dy zgjidhje duken kĂ«shtu â Openstack (i markĂ«s) Ă«shtĂ« njĂ« kafaz i thjeshtĂ« ku ju mbyllin, por keni çelĂ«sin dhe mund tĂ« dilni nĂ« çdo moment. VMWare Ă«shtĂ« njĂ« kafaz i artĂ«, çelĂ«si i kafazit Ă«shtĂ« te pronari dhe do t'ju kushtojĂ« shumĂ« shtrenjtĂ«.
Nuk po inkurajoj as produktin e parĂ« as tĂ« dytin â ju zgjidhni atĂ« qĂ« ju nevojitet. Por po tĂ« mĂ« duhej tĂ« bĂ«ja njĂ« zgjedhje, do tĂ« zgjidhja tĂ« dy zgjidhjet â VMWare pĂ«r cloud-in IT (ngarkesa tĂ« vogla, menaxhim i lehtĂ«), OpenStack nga ndonjĂ« furnizues (Nokia dhe Juniper ofrojnĂ« zgjidhje shumĂ« tĂ« mira turn-key) â pĂ«r cloud-in Telekom. Nuk do ta pĂ«rdorja OpenStack pĂ«r cloud tĂ« pastĂ«r IT â Ă«shtĂ« si tĂ« qĂ«llosh me armĂ« mbi shallow, por nuk shoh pengesa pĂ«r ta pĂ«rdorur pĂ«rveçse pĂ«r shkak tĂ« tepĂ«rsisĂ«. MegjithatĂ«, pĂ«rdorimi i VMWare nĂ« telekom â Ă«shtĂ« si tĂ« transportosh gĂ«lqere me njĂ« Ford Raptor â duket bukur nga ana, por shoferi duhet tĂ« bĂ«jĂ« 10 udhĂ«time nĂ« vend tĂ« njĂ«.
Sipas mendimit tim, disavantazhi mĂ« i madh i VMWare Ă«shtĂ« mbyllja e saj e plotĂ« â kompania nuk do t'ju japĂ« asnjĂ« informacion se si funksionon, pĂ«r shembull, vSAN ose çfarĂ« ka nĂ« thelb tĂ« hipervizorit â nuk Ă«shtĂ« e leverdisshme pĂ«r ta â do tĂ« thotĂ« qĂ« kurrĂ« nuk do tĂ« bĂ«heni ekspert nĂ« VMWare â pa mbĂ«shtetje nga furnizuesi, jeni tĂ« dĂ«nuar (shumĂ« herĂ« takoj ekspertĂ« tĂ« VMWare qĂ« ngatĂ«rrohen nga pyetje tĂ« zakonshme). PĂ«r mua, VMWare Ă«shtĂ« njĂ« blerje makine me kapakun e mbyllur me çelĂ«s â po, ndoshta keni specialistĂ« qĂ« mund tĂ« ndihmojnĂ« nĂ« ndĂ«rrimin e belit tĂ« GRM, por vetĂ«m ai qĂ« ju ka shitur kĂ«tĂ« zgjidhje mund ta hapĂ« kapakun. Personalish nuk i pĂ«lqej zgjidhjet nĂ« tĂ« cilat nuk mund tĂ« futem. Ju do tĂ« thoni se ndoshta nuk do t'ju nevojitet tĂ« hidhni dorĂ«n nĂ«n kapak. Po, Ă«shtĂ« e mundur, por do ta shoh atĂ«herĂ« kur tĂ« duhet tĂ« ndihmoj njĂ« funksion tĂ« madh nĂ« cloud nga 20-30 makinat virtuale, 40-50 rrjete, gjysma e tĂ« cilave dĂ«shiron tĂ« dalĂ« jashtĂ«, ndĂ«rsa gjysma tjetĂ«r kĂ«rkon pĂ«rshpejtimin SR-IOV, pĂ«rndryshe do t'ju duhen edhe disa d10 makinat e tilla â pĂ«rndryshe performanca nuk do tĂ« jetĂ« e mjaftueshme.
EkzistojnĂ« dhe pikĂ«pamje tĂ« tjera, prandaj vetĂ«m ju e vendosni çfarĂ« tĂ« zgjidhni, dhe e rĂ«ndĂ«sishme â ju jeni ata qĂ« do tĂ« pĂ«rgjigjeni pĂ«r zgjedhjen tuaj. Ky Ă«shtĂ« thjesht mendimi im â i njĂ« njeriu qĂ« ka parĂ« dhe mbajtur nĂ« duar tĂ« paktĂ«n 4 produkte â Nokia, Juniper, Red Hat dhe VMWare. Do tĂ« thotĂ« qĂ« kam me çfarĂ« tĂ« krahasoj.
Burimi: habr.com
