Cloud computing po depërton gjithnjë e më thellë në jetën tonë dhe ndoshta nuk ka asnjë person të vetëm që të mos ketë përdorur ndonjë shërbim cloud të paktën një herë. Megjithatë, çfarë saktësisht është një re dhe si funksionon, pak njerëz e dinë, qoftë edhe në nivelin e një ideje. 5G tashmë po bëhet realitet dhe infrastruktura e telekomit ka filluar të kalojë nga zgjidhjet shtylla në zgjidhjet cloud, ashtu siç ndodhi kur kaloi nga zgjidhjet plotësisht harduerike në "shtylla" të virtualizuara.
Sot do të flasim për botën e brendshme të infrastrukturës cloud, në veçanti do të shohim bazat e pjesës së rrjetit.
Çfarë është një re? I njëjti virtualizim - pamja e profilit?
Më shumë se një pyetje logjike. Jo - ky nuk është virtualizim, megjithëse nuk mund të bëhej pa të. Le të shohim dy përkufizime:
Cloud computing (më tej referuar si Cloud) është një model për ofrimin e aksesit të lehtë për përdoruesit në burimet e shpërndara kompjuterike që duhet të vendosen dhe të lëshohen sipas kërkesës me vonesën më të ulët të mundshme dhe me kosto minimale për ofruesin e shërbimit.
Virtualizimi - kjo është aftësia për të ndarë një ent fizik (për shembull, një server) në disa virtuale, duke rritur kështu përdorimin e burimeve (për shembull, keni pasur 3 serverë të ngarkuar në 25-30 përqind, pas virtualizimit ju merrni 1 server të ngarkuar në 80-90 përqind). Natyrisht, virtualizimi ha disa nga burimet - ju duhet të ushqeni hipervizorin, megjithatë, siç ka treguar praktika, loja ia vlen qiriun. Një shembull ideal i virtualizimit është VMWare, i cili përgatit në mënyrë perfekte makinat virtuale, ose për shembull KVM, që unë e preferoj, por kjo është çështje shije.
Ne përdorim virtualizimin pa e kuptuar, madje edhe ruterat prej hekuri tashmë përdorin virtualizimin - për shembull, në versionin më të fundit të JunOS, sistemi operativ është instaluar si një makinë virtuale në krye të një shpërndarjeje Linux në kohë reale (Wind River 9). Por virtualizimi nuk është cloud, por cloud nuk mund të ekzistojë pa virtualizim.
Virtualizimi është një nga blloqet ndërtuese mbi të cilat është ndërtuar cloud.
Krijimi i një reje thjesht duke mbledhur disa hipervizorë në një domen L2, duke shtuar disa libra riprodhues yaml për regjistrimin automatik të vlan-eve përmes një lloj ansible dhe bllokimin e diçkaje si një sistem orkestrimi në të gjitha për krijimin automatik të makinave virtuale nuk do të funksionojë. Do të jetë më e saktë, por Frankenshtajni që rezulton nuk është reja që na nevojitet, megjithëse mund të jetë ëndrra përfundimtare për të tjerët. Për më tepër, nëse merrni të njëjtin Openstack, në thelb është akoma Frankenstein, por oh mirë, le të mos flasim për këtë tani për tani.
Por unë e kuptoj që nga përkufizimi i paraqitur më sipër nuk është plotësisht e qartë se çfarë mund të quhet në të vërtetë një re.
Prandaj, një dokument nga NIST (Instituti Kombëtar i Standardeve dhe Teknologjisë) ofron 5 karakteristika kryesore që duhet të ketë një infrastrukturë cloud:
Ofrimi i shërbimit sipas kërkesës. Përdoruesit duhet t'i jepet akses falas në burimet kompjuterike që i janë caktuar (siç janë rrjetet, disqet virtuale, memoria, bërthamat e procesorit, etj.), dhe këto burime duhet të sigurohen automatikisht - domethënë pa ndërhyrje nga ofruesi i shërbimit.
Disponueshmëri e gjerë e shërbimit. Qasja në burime duhet të sigurohet nga mekanizma standardë për të lejuar përdorimin e kompjuterëve standardë dhe të klientëve të hollë dhe pajisjeve mobile.
Kombinimi i burimeve në pishina. Pishinat e burimeve duhet të jenë në gjendje të ofrojnë burime për klientë të shumtë në të njëjtën kohë, duke siguruar që klientët të jenë të izoluar dhe të lirë nga ndikimi reciprok dhe konkurrenca për burime. Rrjetet janë gjithashtu të përfshira në grupe, gjë që tregon mundësinë e përdorimit të adresave të mbivendosura. Pishinat duhet të jenë në gjendje të shkallëzohen sipas kërkesës. Përdorimi i pishinave bën të mundur sigurimin e nivelit të nevojshëm të tolerancës së gabimeve të burimeve dhe abstraksionit të burimeve fizike dhe virtuale - marrësit të shërbimit i sigurohet thjesht grupi i burimeve që ai ka kërkuar (ku këto burime ndodhen fizikisht, në sa serverët dhe ndërprerësit - nuk ka rëndësi për klientin). Megjithatë, duhet të kemi parasysh faktin që ofruesi duhet të sigurojë rezervimin transparent të këtyre burimeve.
Përshtatje e shpejtë në kushte të ndryshme. Shërbimet duhet të jenë fleksibël - sigurimi i shpejtë i burimeve, rishpërndarja e tyre, shtimi ose zvogëlimi i burimeve sipas kërkesës së klientit, dhe nga ana e klientit duhet të ketë një ndjenjë që burimet e resë kompjuterike janë të pafundme. Për lehtësinë e të kuptuarit, për shembull, ju nuk shihni një paralajmërim që një pjesë e hapësirës së diskut në Apple iCloud është zhdukur sepse hard disku në server është prishur dhe disqet prishen. Përveç kësaj, nga ana juaj, mundësitë e këtij shërbimi janë pothuajse të pakufishme - ju duhen 2 TB - pa problem, e keni paguar dhe e keni marrë. Një shembull i ngjashëm mund të jepet me Google.Drive ose Yandex.Disk.
Mundësia e matjes së shërbimit të ofruar. Sistemet cloud duhet të kontrollojnë dhe optimizojnë automatikisht burimet e konsumuara dhe këto mekanizma duhet të jenë transparente si për përdoruesit ashtu edhe për ofruesin e shërbimit. Kjo do të thotë, gjithmonë mund të kontrolloni se sa burime po konsumoni ju dhe klientët tuaj.
Vlen të merret parasysh fakti se këto kërkesa janë kryesisht kërkesa për një re publike, kështu që për një re private (domethënë një re e lëshuar për nevojat e brendshme të kompanisë), këto kërkesa mund të rregullohen paksa. Sidoqoftë, ato ende duhet të kryhen, përndryshe nuk do të marrim të gjitha përfitimet e kompjuterit cloud.
Pse na duhet një re?
Sidoqoftë, çdo teknologji e re ose ekzistuese, çdo protokoll i ri krijohet për diçka (mirë, përveç RIP-ng, natyrisht). Askush nuk ka nevojë për një protokoll për hir të një protokolli (mirë, përveç RIP-ng, natyrisht). Është logjike që Cloud është krijuar për të ofruar një lloj shërbimi për përdoruesit/klientin. Të gjithë jemi të njohur me të paktën disa shërbime cloud, për shembull Dropbox ose Google.Docs, dhe besoj se shumica e njerëzve i përdorin ato me sukses - për shembull, ky artikull është shkruar duke përdorur shërbimin cloud Google.Docs. Por shërbimet cloud që ne njohim janë vetëm një pjesë e aftësive të cloud - më saktë, ato janë vetëm një shërbim i tipit SaaS. Ne mund të ofrojmë një shërbim cloud në tre mënyra: në formën e SaaS, PaaS ose IaaS. Çfarë shërbimi ju nevojitet varet nga dëshirat dhe aftësitë tuaja.
Le të shohim secilin me radhë:
Softueri si shërbim (SaaS) është një model për ofrimin e një shërbimi të plotë për klientin, për shembull, një shërbim email si Yandex.Mail ose Gmail. Në këtë model të ofrimit të shërbimit, ju, si klient, në fakt nuk bëni asgjë përveç përdorimit të shërbimeve - domethënë, nuk keni nevojë të mendoni për konfigurimin e shërbimit, tolerancën e tij ndaj gabimeve ose tepricën. Gjëja kryesore është të mos komprometoni fjalëkalimin tuaj; ofruesi i këtij shërbimi do të bëjë pjesën tjetër për ju. Nga pikëpamja e ofruesit të shërbimit, ai është plotësisht përgjegjës për të gjithë shërbimin - nga hardueri i serverit dhe sistemet operative të hostit deri te cilësimet e bazës së të dhënave dhe softuerit.
Platforma si Shërbim (PaaS) — kur përdorni këtë model, ofruesi i shërbimit i siguron klientit një pjesë pune për shërbimin, për shembull, le të marrim një server në internet. Ofruesi i shërbimit i ofroi klientit një server virtual (në fakt, një grup burimesh, si RAM/CPU/Storage/Nets, etj.), dhe madje instaloi OS dhe softuerin e nevojshëm në këtë server, megjithatë, konfigurimi i të gjitha këto gjëra bëhen nga vetë klienti dhe për kryerjen e shërbimit përgjigjet klienti. Ofruesi i shërbimit, si në rastin e mëparshëm, është përgjegjës për performancën e pajisjeve fizike, hipervizorëve, vetë makinës virtuale, disponueshmërisë së rrjetit të saj, etj., por vetë shërbimi nuk është më në fushën e tij të përgjegjësisë.
Infrastruktura si një Shërbim (IaaS) - kjo qasje është tashmë më interesante, në fakt, ofruesi i shërbimit i ofron klientit një infrastrukturë të plotë të virtualizuar - domethënë, një grup (pool) burimesh, si Bërthamat e CPU, RAM, Rrjetet, etj. Çdo gjë tjetër varet klienti - çfarë dëshiron të bëjë klienti me këto burime brenda grupit të caktuar (kuotës) - nuk është veçanërisht e rëndësishme për furnizuesin. Nëse klienti dëshiron të krijojë vEPC-në e tij apo edhe të krijojë një mini operator dhe të ofrojë shërbime komunikimi - pa dyshim - bëjeni. Në një skenar të tillë, ofruesi i shërbimit është përgjegjës për sigurimin e burimeve, tolerancën dhe disponueshmërinë e tyre ndaj gabimeve, si dhe OS që i lejon ata të bashkojnë këto burime dhe t'i vënë ato në dispozicion të klientit me aftësinë për të rritur ose ulur burimet në çdo kohë. me kërkesë të klientit. Klienti konfiguron vetë të gjitha makinat virtuale dhe xhingël të tjera përmes portalit dhe konsolës së vetë-shërbimit, duke përfshirë vendosjen e rrjeteve (përveç rrjeteve të jashtme).
Çfarë është OpenStack?
Në të tre opsionet, ofruesi i shërbimit ka nevojë për një OS që do të mundësojë krijimin e një infrastrukture cloud. Në fakt, me SaaS, më shumë se një divizion është përgjegjës për të gjithë grumbullin e teknologjive - ekziston një divizion që është përgjegjës për infrastrukturën - domethënë, ai i ofron IaaS një divizioni tjetër, ky divizion i ofron SaaS klientit. OpenStack është një nga sistemet operative cloud që ju lejon të grumbulloni një sërë çelsash, serverësh dhe sistemesh ruajtjeje në një grup të vetëm burimesh, të ndani këtë grup të përbashkët në nënpool (qiramarrës) dhe t'i ofroni këto burime klientëve përmes rrjetit.
OpenStack është një sistem operativ cloud që ju lejon të kontrolloni grupe të mëdha të burimeve kompjuterike, ruajtjes së të dhënave dhe burimeve të rrjetit, të siguruara dhe menaxhuara nëpërmjet API duke përdorur mekanizma standardë të vërtetimit.
Me fjalë të tjera, ky është një grup projektesh softuerësh falas që janë krijuar për të krijuar shërbime cloud (publike dhe private) - domethënë një grup mjetesh që ju lejojnë të kombinoni serverin dhe pajisjet e ndërrimit në një grup të vetëm burimesh, të menaxhoni këto burime, duke siguruar nivelin e nevojshëm të tolerancës ndaj gabimeve.
Në kohën e shkrimit të këtij materiali, struktura OpenStack duket si kjo:
Foto e marrë nga
Secili nga komponentët e përfshirë në OpenStack kryen një funksion specifik. Kjo arkitekturë e shpërndarë ju lejon të përfshini në zgjidhje grupin e komponentëve funksionalë që ju nevojiten. Megjithatë, disa komponentë janë përbërës rrënjë dhe heqja e tyre do të çojë në mosfunksionim të plotë ose të pjesshëm të zgjidhjes në tërësi. Këta komponentë zakonisht klasifikohen si:
- Profili — GUI i bazuar në ueb për menaxhimin e shërbimeve OpenStack
- parim baz është një shërbim i centralizuar i identitetit që ofron funksione vërtetimi dhe autorizimi për shërbime të tjera, si dhe menaxhon kredencialet e përdoruesve dhe rolet e tyre.
- neutron - një shërbim rrjeti që ofron lidhje midis ndërfaqeve të shërbimeve të ndryshme OpenStack (përfshirë lidhjen midis VM-ve dhe aksesin e tyre në botën e jashtme)
- zhir — siguron qasje në bllokimin e ruajtjes për makinat virtuale
- Yll i ri — Menaxhimi i ciklit jetësor të makinave virtuale
- shikoj — depo e imazheve dhe fotove të makinës virtuale
- I shpejtë — siguron akses në objektin e ruajtjes
- Ceilometri — një shërbim që ofron mundësinë për të mbledhur telemetrinë dhe për të matur burimet e disponueshme dhe të konsumuara
- Nxehtësi — orkestrimi i bazuar në shabllone për krijimin dhe sigurimin automatik të burimeve
Mund të shihet një listë e plotë e të gjitha projekteve dhe qëllimi i tyre .
Çdo komponent OpenStack është një shërbim që kryen një funksion specifik dhe ofron një API për të menaxhuar atë funksion dhe për të bashkëvepruar me shërbimet e tjera të sistemit operativ cloud për të krijuar një infrastrukturë të unifikuar. Për shembull, Nova ofron menaxhimin e burimeve kompjuterike dhe një API për qasje në konfigurimin e këtyre burimeve, Glance ofron menaxhimin e imazhit dhe një API për menaxhimin e tyre, Cinder siguron ruajtjen e bllokut dhe një API për menaxhimin e tij, etj. Të gjitha funksionet janë të ndërlidhura në një mënyrë shumë të ngushtë.
Sidoqoftë, nëse e shikoni, të gjitha shërbimet që funksionojnë në OpenStack janë në fund të fundit një lloj makine virtuale (ose kontejner) i lidhur me rrjetin. Shtrohet pyetja - pse na duhen kaq shumë elementë?
Le të kalojmë përmes algoritmit për krijimin e një makine virtuale dhe lidhjen e saj me rrjetin dhe ruajtjen e vazhdueshme në Openstack.
- Kur krijoni një kërkesë për të krijuar një makinë, qoftë kjo një kërkesë përmes Horizon (Pulti i kontrollit) ose një kërkesë përmes CLI, gjëja e parë që ndodh është autorizimi i kërkesës suaj në Keystone - a mund të krijoni një makinë, a ka të drejtën e përdorimit të këtij rrjeti, bën draft kuotën tuaj etj.
- Keystone vërteton kërkesën tuaj dhe gjeneron një shenjë vërtetimi në mesazhin e përgjigjes, e cila do të përdoret më tej. Pasi ka marrë një përgjigje nga Keystone, kërkesa i dërgohet Nova (nova api).
- Nova-api kontrollon vlefshmërinë e kërkesës suaj duke kontaktuar Keystone duke përdorur tokenin e autorizimit të krijuar më parë
- Keystone kryen vërtetimin dhe jep informacion mbi lejet dhe kufizimet bazuar në këtë shenjë vërtetimi.
- Nova-api krijon një hyrje për VM-në e re në bazën e të dhënave nova dhe ia kalon kërkesën për krijimin e makinës te nova-scheduler.
- Nova-scheduler zgjedh hostin (nyjen kompjuterike) në të cilën do të vendoset VM bazuar në parametrat, peshat dhe zonat e specifikuara. Një regjistrim i kësaj dhe ID-ja e VM-së janë shkruar në bazën e të dhënave nova.
- Më pas, nova-scheduler kontakton nova-compute me një kërkesë për të vendosur një shembull. Nova-compute kontakton nova-conductor për të marrë informacion rreth parametrave të makinës (nova-conductor është një element nova që vepron si një server proxy midis bazës së të dhënave nova dhe nova-compute, duke kufizuar numrin e kërkesave në bazën e të dhënave nova për të shmangur problemet me bazën e të dhënave ulje e ngarkesës së konsistencës).
- Nova-conductor merr informacionin e kërkuar nga baza e të dhënave nova dhe ia kalon në nova-compute.
- Më pas, telefonatat nova-compute hedhin një vështrim për të marrë ID-në e imazhit. Glace vërteton kërkesën në Keystone dhe kthen informacionin e kërkuar.
- Nova-llogarit kontaktet neutron për të marrë informacion rreth parametrave të rrjetit. Ngjashëm me shikimin, neutroni vërteton kërkesën në Keystone, pas së cilës krijon një hyrje në bazën e të dhënave (identifikuesin e portit, etj.), krijon një kërkesë për të krijuar një port dhe kthen informacionin e kërkuar në nova-compute.
- Nova-llogaritni kontaktet me një kërkesë për të ndarë një vëllim në makinën virtuale. Ngjashëm me shikimin, cider vërteton kërkesën në Keystone, krijon një kërkesë për krijimin e vëllimit dhe kthen informacionin e kërkuar.
- Nova-compute kontaktet libvirt me një kërkesë për të vendosur një makinë virtuale me parametrat e specifikuar.
Në fakt, një operacion në dukje i thjeshtë i krijimit të një makinerie të thjeshtë virtuale kthehet në një vorbull të tillë thirrjesh API midis elementeve të platformës cloud. Për më tepër, siç mund ta shihni, edhe shërbimet e përcaktuara më parë gjithashtu përbëhen nga komponentë më të vegjël ndërmjet të cilëve ndodh ndërveprimi. Krijimi i një makinerie është vetëm një pjesë e vogël e asaj që platforma cloud ju lejon të bëni - ekziston një shërbim përgjegjës për balancimin e trafikut, një shërbim përgjegjës për ruajtjen e bllokut, një shërbim përgjegjës për DNS, një shërbim përgjegjës për sigurimin e serverëve metalikë të zhveshur, etj. Reja ju lejon t'i trajtoni makinat tuaja virtuale si një tufë delesh (në krahasim me virtualizimin). Nëse diçka ndodh me makinën tuaj në një mjedis virtual - ju e rivendosni atë nga kopjet rezervë, etj., Por aplikacionet cloud janë ndërtuar në atë mënyrë që makina virtuale të mos luajë një rol kaq të rëndësishëm - makina virtuale "vdiq" - nuk ka problem - thjesht krijohet një e re, automjeti bazohet në shabllon dhe, siç thonë ata, skuadra nuk e vuri re humbjen e luftëtarit. Natyrisht, kjo parashikon praninë e mekanizmave të orkestrimit - duke përdorur shabllonet Heat, mund të vendosni lehtësisht një funksion kompleks të përbërë nga dhjetëra rrjete dhe makina virtuale.
Gjithmonë ia vlen të kihet parasysh se nuk ka infrastrukturë cloud pa një rrjet - secili element në një mënyrë ose në një tjetër ndërvepron me elementë të tjerë përmes rrjetit. Për më tepër, cloud ka një rrjet absolutisht jo statik. Natyrisht, rrjeti i nënshtresës është edhe pak a shumë statik - nyjet dhe ndërprerësit e rinj nuk shtohen çdo ditë, por komponenti i mbivendosjes mund dhe do të ndryshojë në mënyrë të pashmangshme vazhdimisht - rrjete të reja do të shtohen ose fshihen, makina të reja virtuale do të shfaqen dhe ato të vjetra do të vdes. Dhe siç e mbani mend nga përkufizimi i cloud i dhënë në fillim të artikullit, burimet duhet t'i ndahen përdoruesit automatikisht dhe me ndërhyrjen më të vogël (ose më mirë akoma, pa) nga ofruesi i shërbimit. Kjo do të thotë, lloji i ofrimit të burimeve të rrjetit që tani ekziston në formën e një front-end në formën e llogarisë tuaj personale të aksesueshme përmes http/https dhe inxhinierit të rrjetit në detyrë Vasily si një prapavijë nuk është një re, madje nëse Vasily ka tetë duar.
Neutron, si një shërbim rrjeti, ofron një API për menaxhimin e pjesës së rrjetit të infrastrukturës cloud. Shërbimi fuqizon dhe menaxhon pjesën e rrjetit të Openstack duke ofruar një shtresë abstraksioni të quajtur Network-as-a-a-Service (NaaS). Kjo do të thotë, rrjeti është e njëjta njësi virtuale e matshme si, për shembull, bërthamat virtuale të CPU-së ose sasia e RAM-it.
Por përpara se të kalojmë në arkitekturën e pjesës së rrjetit të OpenStack, le të shqyrtojmë se si funksionon ky rrjet në OpenStack dhe pse rrjeti është një pjesë e rëndësishme dhe integrale e cloud.
Pra, ne kemi dy VM klientësh KUQ dhe dy VM klientësh GREEN. Le të supozojmë se këto makina janë të vendosura në dy hipervizorë në këtë mënyrë:
Për momentin, bëhet fjalë vetëm për virtualizim të 4 serverëve dhe asgjë më shumë, pasi deri tani gjithçka që kemi bërë është virtualizimi i 4 serverëve, duke i vendosur në dy serverë fizikë. Dhe deri më tani ata nuk janë as të lidhur në rrjet.
Për të krijuar një re, duhet të shtojmë disa komponentë. Së pari, ne virtualizojmë pjesën e rrjetit - ne duhet t'i lidhim këto 4 makina në çifte, dhe klientët duan një lidhje L2. Mund të përdorni një ndërprerës dhe të konfiguroni një trunk në drejtimin e tij dhe të zgjidhni gjithçka duke përdorur një urë linux ose, për përdoruesit më të avancuar, openvswitch (ne do t'i kthehemi kësaj më vonë). Por mund të ketë shumë rrjete, dhe shtyrja e vazhdueshme e L2 përmes një ndërprerës nuk është ideja më e mirë - ka departamente të ndryshme, një tavolinë shërbimi, muaj pritje për të përfunduar një aplikacion, javë të zgjidhjes së problemeve - në botën moderne kjo qasja nuk funksionon më. Dhe sa më shpejt që një kompani ta kuptojë këtë, aq më lehtë është për të që të ecë përpara. Prandaj, midis hipervizorëve do të zgjedhim një rrjet L3 përmes të cilit do të komunikojnë makinat tona virtuale, dhe në krye të këtij rrjeti L3 do të ndërtojmë rrjete virtuale të mbivendosjes L2 ku do të rrjedhë trafiku i makinave tona virtuale. Ju mund të përdorni GRE, Geneve ose VxLAN si kapsulim. Le të përqendrohemi tek kjo e fundit për momentin, megjithëse nuk është veçanërisht e rëndësishme.
Ne duhet të gjejmë VTEP diku (shpresoj që të gjithë të jenë të njohur me terminologjinë VxLAN). Meqenëse ne kemi një rrjet L3 që vjen direkt nga serverët, asgjë nuk na pengon të vendosim VTEP në vetë serverët dhe OVS (OpenvSwitch) është i shkëlqyeshëm për ta bërë këtë. Si rezultat, ne morëm këtë dizajn:
Meqenëse trafiku ndërmjet VM-ve duhet të ndahet, portat drejt makinave virtuale do të kenë numra të ndryshëm vlan. Numri i etiketës luan një rol vetëm brenda një ndërprerës virtual, pasi kur futet në VxLAN mund ta heqim lehtësisht, pasi do të kemi një VNI.
Tani ne mund të krijojmë makinat tona dhe rrjetet virtuale për ta pa asnjë problem.
Megjithatë, çka nëse klienti ka një makinë tjetër, por është në një rrjet tjetër? Ne kemi nevojë për rrënjosje midis rrjeteve. Ne do të shikojmë një opsion të thjeshtë kur përdoret rutimi i centralizuar - domethënë, trafiku drejtohet përmes nyjeve të veçanta të rrjetit të dedikuar (epo, si rregull, ato kombinohen me nyjet e kontrollit, kështu që do të kemi të njëjtën gjë).
Duket si asgjë e komplikuar - ne bëjmë një ndërfaqe urë në nyjen e kontrollit, drejtojmë trafikun drejt saj dhe prej andej e drejtojmë atë 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. Kjo do të thotë, ne fillojmë të kryqëzojmë hapësirat e adresave. Për më tepër, klientët nuk duan që klientët e tjerë të jenë në gjendje të kalojnë në rrjetet e tyre të brendshme, gjë që ka kuptim. Për të ndarë rrjetet dhe trafikun e të dhënave të klientit, ne do të ndajmë një hapësirë të veçantë emri për secilën prej tyre. Hapësira e emrave është në fakt një kopje e grumbullit të rrjetit Linux, domethënë, klientët në hapësirën e emrave RED janë plotësisht të izoluar nga klientët nga hapësira e emrave GREEN (epo, ose rutimi midis këtyre rrjeteve të klientëve lejohet përmes hapësirës së emrave të paracaktuar ose në pajisjet e transportit në rrjedhën e sipërme).
Kjo do të thotë, marrim diagramin e mëposhtëm:
Tunelet L2 konvergojnë nga të gjitha nyjet llogaritëse në nyjen e kontrollit. nyja ku ndodhet ndërfaqja L3 për këto rrjete, secila në një hapësirë emri të dedikuar për izolim.
Megjithatë, ne harruam gjënë më të rëndësishme. Makina virtuale duhet t'i ofrojë klientit një shërbim, domethënë duhet të ketë të paktën një ndërfaqe të jashtme përmes së cilës mund të arrihet. Kjo do të thotë, ne duhet të dalim në botën e jashtme. Këtu ka opsione të ndryshme. Le të bëjmë opsionin më të thjeshtë. Ne do të shtojmë një rrjet për çdo klient, i cili do të jetë i vlefshëm në rrjetin e ofruesit dhe nuk do të mbivendoset me rrjetet e tjera. Rrjetet gjithashtu mund të kryqëzohen dhe të shikojnë VRF të ndryshme në anën e rrjetit të ofruesit. Të dhënat e rrjetit do të jetojnë gjithashtu në hapësirën e emrave të secilit klient. Megjithatë, ata do të vazhdojnë të dalin në botën e jashtme përmes një ndërfaqeje fizike (ose lidhje, që është më logjike). Për të ndarë trafikun e klientit, trafiku që del jashtë do të etiketohet me një etiketë VLAN të alokuar për klientin.
Si rezultat, kemi marrë këtë diagram:
Një pyetje e arsyeshme është pse të mos krijoni porta në vetë nyjet e llogaritjes? Ky nuk është një problem i madh; për më tepër, nëse ndizni ruterin e shpërndarë (DVR), kjo do të funksionojë. Në këtë skenar, ne po shqyrtojmë opsionin më të thjeshtë me një portë të centralizuar, e cila përdoret si parazgjedhje në Openstack. Për funksionet me ngarkesë të lartë, ata do të përdorin si një ruter të shpërndarë ashtu edhe teknologji të përshpejtimit si SR-IOV dhe Passthrough, por siç thonë ata, kjo është një histori krejtësisht e ndryshme. Së pari, le të merremi me pjesën bazë, dhe më pas do të hyjmë në detaje.
Në fakt, skema jonë tashmë është e zbatueshme, por ka disa nuanca:
- Ne duhet të mbrojmë disi makinat tona, domethënë të vendosim një filtër në ndërfaqen e ndërprerësit drejt klientit.
- Bëni të mundur që një makinë virtuale të marrë automatikisht një adresë IP, në mënyrë që të mos keni nevojë të hyni në të përmes tastierës çdo herë dhe të regjistroni adresën.
Le të fillojmë me mbrojtjen e makinës. Për këtë mund të përdorni iptables banale, pse jo.
Kjo do të thotë, tani topologjia jonë është bërë pak më e ndërlikuar:
Le të vazhdojmë. Duhet të shtojmë një server DHCP. Vendi më ideal për të lokalizuar serverët DHCP për çdo klient do të ishte nyja e kontrollit të përmendur tashmë më lart, ku ndodhen hapësirat e emrave:
Megjithatë, ka një problem të vogël. Po sikur gjithçka të rindizet dhe të gjitha informacionet në lidhje me marrjen me qira të adresave në DHCP zhduken. Është logjike që makinave t'u jepen adresa të reja, gjë që nuk është shumë e përshtatshme. Ka dy rrugëdalje këtu - ose përdorni emra domenesh dhe shtoni një server DNS për secilin klient, atëherë adresa nuk do të jetë veçanërisht e rëndësishme për ne (e ngjashme me pjesën e rrjetit në k8s) - por ka një problem me rrjetet e jashtme, pasi adresat gjithashtu mund të lëshohen në to përmes DHCP - keni nevojë për sinkronizim me serverët DNS në platformën cloud dhe një server të jashtëm DNS, i cili për mendimin tim nuk është shumë fleksibël, por është mjaft i mundshëm. Ose opsioni i dytë është përdorimi i meta të dhënave - d.m.th., ruani informacionin në lidhje me adresën e lëshuar në makinë në mënyrë që serveri DHCP të dijë se cilën adresë t'i lëshojë makinës nëse makina ka marrë tashmë një adresë. Opsioni i dytë është më i thjeshtë dhe më fleksibël, pasi ju lejon të ruani informacione shtesë për makinën. Tani le të shtojmë meta të dhënat e agjentit në diagram:
Një çështje tjetër që gjithashtu vlen të diskutohet është aftësia për të përdorur një rrjet të jashtëm nga të gjithë klientët, pasi rrjetet e jashtme, nëse ato duhet të jenë të vlefshme në të gjithë rrjetin, do të jenë të vështira - duhet të ndani dhe kontrolloni vazhdimisht shpërndarjen e këtyre rrjeteve. Aftësia për të përdorur një rrjet të vetëm të jashtëm të para-konfiguruar për të gjithë klientët do të jetë shumë i dobishëm kur krijoni një re publike. Kjo do ta bëjë më të lehtë vendosjen e makinerive sepse nuk kemi nevojë të konsultohemi me një bazë të dhënash adresash dhe të zgjedhim një hapësirë unike adresash për rrjetin e jashtëm të secilit klient. Përveç kësaj, ne mund të regjistrojmë një rrjet të jashtëm paraprakisht dhe në kohën e vendosjes do të na duhet vetëm të lidhim adresat e jashtme me makinat e klientit.
Dhe këtu NAT na vjen në ndihmë - ne thjesht do të bëjmë të mundur që klientët të kenë akses në botën e jashtme përmes hapësirës së paracaktuar të emrave duke përdorur përkthimin NAT. Epo, këtu është një problem i vogël. Kjo është mirë nëse serveri i klientit vepron si klient dhe jo si server - domethënë, ai fillon në vend se pranon lidhje. Por me ne do të jetë e kundërta. Në këtë rast, duhet të bëjmë NAT destinacioni në mënyrë që kur të marrim trafikun, nyja e kontrollit të kuptojë se ky trafik është i destinuar për makinën virtuale A të klientit A, që do të thotë se duhet të bëjmë një përkthim NAT nga një adresë e jashtme, për shembull 100.1.1.1. .10.0.0.1, në një adresë të brendshme 100. Në këtë rast, megjithëse të gjithë klientët do të përdorin të njëjtin rrjet, izolimi i brendshëm ruhet plotësisht. Kjo do të thotë, ne duhet të bëjmë dNAT dhe sNAT në nyjen e kontrollit. Nëse do të përdorni një rrjet të vetëm me adresa lundruese ose rrjete të jashtme, ose të dyja njëkohësisht, varet nga ajo që dëshironi të sillni në re. Ne nuk do të shtojmë adresa lundruese në diagram, por do të lëmë rrjetet e jashtme të shtuara më herët - secili klient ka rrjetin e tij të jashtëm (në diagram ato tregohen si vlan 200 dhe XNUMX në ndërfaqen e jashtme).
Si rezultat, ne morëm një zgjidhje interesante dhe në të njëjtën kohë të mirëmenduar, e cila ka një fleksibilitet të caktuar, por nuk ka ende mekanizma të tolerimit të gabimeve.
Së pari, ne kemi vetëm një nyje kontrolli - dështimi i saj do të çojë në kolapsin e të gjitha sistemeve. Për të zgjidhur këtë problem, duhet të krijoni të paktën një kuorum prej 3 nyjesh. Le ta shtojmë këtë në diagram:
Natyrisht, të gjitha nyjet janë të sinkronizuara dhe kur një nyje aktive largohet, një nyje tjetër do të marrë përsipër përgjegjësitë e saj.
Problemi tjetër janë disqet e makinës virtuale. Për momentin, ato ruhen në vetë hipervizorët, dhe në rast të problemeve me hipervizorin, ne humbasim të gjitha të dhënat - dhe prania e një bastisjeje nuk do të ndihmojë këtu nëse humbim jo diskun, por të gjithë serverin. Për ta bërë këtë, ne duhet të krijojmë një shërbim që do të veprojë si pjesa e përparme për një lloj ruajtjeje. Çfarë lloj ruajtjeje do të jetë nuk është veçanërisht e rëndësishme për ne, por duhet të mbrojë të dhënat tona nga dështimi i diskut dhe i nyjës, dhe ndoshta i gjithë kabinetit. Ka disa opsione këtu - ka, natyrisht, rrjete SAN me Fiber Channel, por le të jemi të sinqertë - FC është tashmë një relike e së kaluarës - një analog i E1 në transport - po, jam dakord, ai ende përdoret, por vetëm aty ku është absolutisht e pamundur pa të. Prandaj, nuk do të vendosja vullnetarisht një rrjet FC në vitin 2020, duke ditur se ka alternativa të tjera më interesante. Edhe pse për secilin të tijën, mund të ketë nga ata që besojnë se FC me të gjitha kufizimet e saj është gjithçka që na nevojitet - nuk do të debatoj, të gjithë kanë mendimin e tyre. Sidoqoftë, zgjidhja më interesante për mendimin tim është përdorimi i një SDS, siç është Ceph.
Ceph ju lejon të ndërtoni një zgjidhje shumë të disponueshme për ruajtjen e të dhënave me një mori opsionesh të mundshme rezervë, duke filluar me kodet me kontrollin e barazisë (analoge me bastisjen 5 ose 6) duke përfunduar me përsëritjen e plotë të të dhënave në disqe të ndryshëm, duke marrë parasysh vendndodhjen e disqeve në serverët, dhe serverët në kabinete, etj.
Për të ndërtuar Ceph ju duhen 3 nyje të tjera. Ndërveprimi me hapësirën ruajtëse do të kryhet gjithashtu nëpërmjet rrjetit duke përdorur shërbime të ruajtjes së bllokut, objekteve dhe skedarëve. Le të shtojmë hapësirën në skemë:
Shënim: ju gjithashtu mund të krijoni nyje llogaritëse hiperkonvergjente - ky është koncepti i kombinimit të disa funksioneve në një nyje - për shembull, ruajtja+llogaritja - pa dedikuar nyje speciale për ruajtjen ceph. Ne do të marrim të njëjtën skemë tolerante ndaj gabimeve - pasi SDS do të rezervojë të dhëna me nivelin e rezervimit që ne specifikojmë. Sidoqoftë, nyjet e hiperkonverguara janë gjithmonë një kompromis - pasi nyja e ruajtjes nuk ngroh vetëm ajrin siç duket në shikim të parë (pasi nuk ka makina virtuale në të) - ai shpenzon burimet e CPU për servisimin e SDS (në fakt, ai bën gjithçka përsëritja dhe rikuperimi pas dështimeve të nyjeve, disqeve, etj.). Kjo do të thotë, ju do të humbni një pjesë të fuqisë së nyjes llogaritëse nëse e kombinoni atë me hapësirën ruajtëse.
Të gjitha këto gjëra duhet të menaxhohen disi - ne kemi nevojë për diçka përmes së cilës mund të krijojmë një makinë, një rrjet, një ruter virtual, etj. Për ta bërë këtë, ne do të shtojmë një shërbim në nyjen e kontrollit që do të veprojë si një panel kontrolli - klienti do të jetë në gjendje të lidhet me këtë portal përmes http/ https dhe të bëjë gjithçka që i nevojitet (mirë, pothuajse).
Si rezultat, ne tani kemi një sistem tolerant ndaj gabimeve. Të gjithë elementët e kësaj infrastrukture duhet të menaxhohen disi. U përshkrua më parë se Openstack është një grup projektesh, secila prej të cilave ofron një funksion specifik. Siç e shohim, ka më shumë se mjaft elementë që duhet të konfigurohen dhe kontrollohen. Sot do të flasim për pjesën e rrjetit.
Arkitektura neutronike
Në OpenStack, është Neutron ai që është përgjegjës për lidhjen e porteve të makinës virtuale me një rrjet të përbashkët L2, duke siguruar drejtimin e trafikut midis VM-ve të vendosura në rrjete të ndryshme L2, si dhe drejtimin e jashtëm, duke ofruar shërbime si NAT, Floating IP, DHCP, etj.
Në një nivel të lartë, funksionimi i shërbimit të rrjetit (pjesa bazë) mund të përshkruhet si më poshtë.
Kur filloni VM-në, shërbimi i rrjetit:
- Krijon një port për një VM (ose porta) të caktuar dhe njofton shërbimin DHCP për të;
- Krijohet një pajisje e re e rrjetit virtual (nëpërmjet libvirt);
- VM lidhet me portën(at) e krijuar në hapin 1;
Mjaft e çuditshme, puna e Neutron bazohet në mekanizma standardë të njohur për të gjithë ata që janë zhytur ndonjëherë në Linux - hapësirat e emrave, iptables, urat linux, openvswitch, conntrack, etj.
Duhet të sqarohet menjëherë se Neutron nuk është një kontrollues SDN.
Neutroni përbëhet nga disa komponentë të ndërlidhur:
Openstack-neutron-server është një demon që punon me kërkesat e përdoruesve përmes API-së. Ky demon nuk është i përfshirë në regjistrimin e ndonjë lidhjeje rrjeti, por siguron informacionin e nevojshëm për këtë në shtojcat e tij, të cilat më pas konfigurojnë elementin e dëshiruar të rrjetit. Agjentët neutron në nyjet OpenStack regjistrohen me serverin Neutron.
Serveri neutron është në fakt një aplikacion i shkruar në python, i përbërë nga dy pjesë:
- Shërbimi REST
- Shtojca neutron (bërthamë/shërbim)
Shërbimi REST është krijuar për të marrë thirrje API nga komponentë të tjerë (për shembull, një kërkesë për të dhënë disa informacione, etj.)
Pluginat janë komponentë/module të softuerit plug-in që thirren gjatë kërkesave të API - domethënë, atribuimi i një shërbimi ndodh përmes tyre. Pluginat ndahen në dy lloje - shërbim dhe rrënjë. Si rregull, shtojca e kalit është kryesisht përgjegjëse për menaxhimin e hapësirës së adresave dhe lidhjeve L2 midis VM-ve, dhe shtojcat e shërbimit tashmë ofrojnë funksione shtesë si VPN ose FW.
Lista e shtojcave të disponueshme sot mund të shihet për shembull
Mund të ketë disa shtojca shërbimi, por mund të ketë vetëm një shtojcë kali.
openstack-neutron-ml2 është shtojca standarde e Openstack root. Ky plugin ka një arkitekturë modulare (ndryshe nga paraardhësi i tij) dhe konfiguron shërbimin e rrjetit përmes drejtuesve të lidhur me të. Vetë plugin-in do ta shohim pak më vonë, pasi në fakt ai jep fleksibilitetin që ka OpenStack në pjesën e rrjetit. Shtojca rrënjësore mund të zëvendësohet (për shembull, Contrail Networking bën një zëvendësim të tillë).
Shërbimi RPC (server rabbitmq) — një shërbim që ofron menaxhim të radhës dhe ndërveprim me shërbime të tjera OpenStack, si dhe ndërveprim ndërmjet agjentëve të shërbimit të rrjetit.
Agjentët e rrjetit — agjentët që ndodhen në çdo nyje, nëpërmjet të cilave konfigurohen shërbimet e rrjetit.
Ka disa lloje agjentësh.
Agjenti kryesor është Agjent L2. Këta agjentë funksionojnë në secilin prej hipervizorëve, duke përfshirë nyjet e kontrollit (më saktë, në të gjitha nyjet që ofrojnë ndonjë shërbim për qiramarrësit) dhe funksioni i tyre kryesor është të lidhin makinat virtuale në një rrjet të përbashkët L2, dhe gjithashtu të gjenerojnë alarme kur ndodhin ndonjë ngjarje ( për shembull çaktivizoni/aktivizoni portin).
Agjenti tjetër, jo më pak i rëndësishëm është Agjent L3. Si parazgjedhje, ky agjent funksionon ekskluzivisht në një nyje rrjeti (shpesh nyja e rrjetit kombinohet me një nyje kontrolli) dhe siguron rrugëzim midis rrjeteve të qiramarrësve (si midis rrjeteve të tij ashtu edhe rrjeteve të qiramarrësve të tjerë, dhe është i aksesueshëm për botën e jashtme, duke ofruar NAT, si dhe shërbimi DHCP). Sidoqoftë, kur përdorni një DVR (ruter i shpërndarë), nevoja për një plugin L3 shfaqet gjithashtu në nyjet llogaritëse.
Agjenti L3 përdor hapësirat e emrave Linux për t'i siguruar çdo qiramarrësi një grup rrjetesh të veta të izoluara dhe funksionalitetin e ruterave virtualë që drejtojnë trafikun dhe ofrojnë shërbime porta për rrjetet e shtresës 2.
Baza e të dhënave — një bazë të dhënash me identifikues të rrjeteve, nënrrjeteve, porteve, grupeve, etj.
Në fakt, Neutron pranon kërkesat API nga krijimi i çdo entiteti rrjeti, vërteton kërkesën dhe përmes RPC (nëse ka akses në ndonjë plugin ose agjent) ose REST API (nëse komunikon në SDN) transmeton te agjentët (nëpërmjet shtojcave) udhëzimet e nevojshme për organizimin e shërbimit të kërkuar.
Tani le të kthehemi te instalimi i testimit (si vendoset dhe çfarë përfshihet në të, do të shohim më vonë në pjesën praktike) dhe të shohim se ku ndodhet secili 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 ~]$
Në fakt, kjo është e gjithë struktura e Neutronit. Tani ia vlen të kaloni pak kohë në shtojcën ML2.
Shtresa modulare 2
Siç u përmend më lart, shtojca është një shtojcë standarde OpenStack root dhe ka një arkitekturë modulare.
Paraardhësi i shtojcës ML2 kishte një strukturë monolit, e cila nuk lejonte, për shembull, përdorimin e një përzierjeje të disa teknologjive në një instalim. Për shembull, nuk mund të përdorni njëkohësisht openvswitch dhe linuxbridge - qoftë të parën, qoftë të dytën. Për këtë arsye u krijua shtojca ML2 me arkitekturën e saj.
ML2 ka dy komponentë - dy lloje drejtuesish: Drejtuesit e tipit dhe drejtuesit e Mekanizmit.
Lloji drejtues përcaktoni teknologjitë që do të përdoren për të organizuar lidhjet e rrjetit, për shembull VxLAN, VLAN, GRE. Në të njëjtën kohë, shoferi lejon përdorimin e teknologjive të ndryshme. Teknologjia standarde është enkapsulimi VxLAN për rrjetet e mbivendosura dhe rrjetet e jashtme vlan.
Drejtuesit e tipit përfshijnë llojet e mëposhtme të rrjetit:
Apartament - rrjet pa etiketim
VLAN-et - rrjeti i etiketuar
Lokal — një lloj rrjeti i veçantë për instalimet të gjitha-në-një (instalime të tilla nevojiten ose për zhvilluesit ose për trajnim)
GRE — mbivendosja e rrjetit duke përdorur tunele GRE
VxLAN — mbivendosja e rrjetit duke përdorur tunele VxLAN
Drejtuesit e mekanizmave përcaktoni mjetet që sigurojnë organizimin e teknologjive të specifikuara në drejtuesin e tipit - për shembull, openvswitch, sr-iov, opendaylight, OVN, etj.
Në varësi të zbatimit të këtij drejtuesi, do të përdoren ose agjentë të kontrolluar nga Neutron, ose do të përdoren lidhjet me një kontrollues të jashtëm SDN, i cili kujdeset për të gjitha çështjet që lidhen me organizimin e rrjeteve L2, rrugëzimin, etj.
Shembull: nëse përdorim ML2 së bashku me OVS, atëherë një agjent L2 instalohet në çdo nyje kompjuterike që menaxhon OVS. Sidoqoftë, nëse përdorim, për shembull, OVN ose OpenDayLight, atëherë kontrolli i OVS bie nën juridiksionin e tyre - Neutron, përmes shtojcës rrënjë, i jep komanda kontrolluesit dhe ai tashmë bën atë që i është thënë.
Le të fillojmë me Open vSwitch
Për momentin, një nga komponentët kryesorë të OpenStack është Open vSwitch.
Kur instaloni OpenStack pa ndonjë shitës shtesë SDN si Juniper Contrail ose Nokia Nuage, OVS është komponenti kryesor i rrjetit të rrjetit cloud dhe, së bashku me iptables, conntrack, hapësira emrash, ju lejon të organizoni rrjete të plota mbivendosje me shumë qira. Natyrisht, ky komponent mund të zëvendësohet, për shembull, kur përdorni zgjidhje SDN të pronarit (shitës) të palëve të treta.
OVS është një ndërprerës softuerësh me burim të hapur që është krijuar për t'u përdorur në mjedise të virtualizuara si një përcjellës i trafikut virtual.
Për momentin, OVS ka funksionalitet shumë të mirë, i cili përfshin teknologji të tilla si QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, etj.
Shënim: OVS nuk u konceptua fillimisht si një ndërprerës i butë për funksionet e telekomit shumë të ngarkuar dhe ishte më i dizajnuar për funksione IT që kërkojnë më pak gjerësi bande, si serveri WEB ose serveri i postës. Sidoqoftë, OVS po zhvillohet më tej dhe implementimet aktuale të OVS kanë përmirësuar shumë performancën dhe aftësitë e tij, gjë që lejon që ajo të përdoret nga operatorët e telekomit me funksione shumë të ngarkuara, për shembull, ekziston një zbatim OVS me mbështetje për përshpejtimin e DPDK.
Ekzistojnë tre komponentë të rëndësishëm të OVS për të cilat duhet të jeni të vetëdijshëm:
- Moduli i kernelit — një komponent i vendosur në hapësirën e kernelit që përpunon trafikun bazuar në rregullat e marra nga elementi i kontrollit;
- v Ndërroni daemon (ovs-vswitchd) është një proces i nisur në hapësirën e përdoruesit që është përgjegjës për programimin e modulit të kernelit - domethënë, ai përfaqëson drejtpërdrejt logjikën e funksionimit të switch-it.
- Serveri i bazës së të dhënave - një bazë të dhënash lokale e vendosur në çdo host që ekzekuton OVS, në të cilin ruhet konfigurimi. Kontrollorët SDN mund të komunikojnë përmes këtij moduli duke përdorur protokollin OVSDB.
E gjithë kjo shoqërohet me një sërë 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 në të, si EPC, SBC, HLR, etj. Disa funksione mund të jetojnë pa probleme me OVS siç janë, por për shembull, EPC përpunon trafikun e abonentëve - pastaj kalon përmes një sasi e madhe trafiku (tani vëllimet e trafikut arrijnë disa qindra gigabit në sekondë). Natyrisht, drejtimi i një trafiku të tillë përmes hapësirës së kernelit (pasi dërguesi ndodhet atje si parazgjedhje) nuk është ideja më e mirë. Prandaj, OVS shpesh vendoset tërësisht në hapësirën e përdoruesit duke përdorur teknologjinë e përshpejtimit DPDK për të përcjellë trafikun nga NIC në hapësirën e përdoruesit duke anashkaluar kernelin.
Shënim: për një re të vendosur për funksionet e telekomit, është e mundur të nxirret trafiku nga një nyje llogaritëse duke anashkaluar OVS direkt në pajisjet komutuese. Për këtë qëllim përdoren mekanizmat SR-IOV dhe Passthrough.
Si funksionon kjo në një plan urbanistik të vërtetë?
Epo, tani le të kalojmë në pjesën praktike dhe të shohim se si funksionon gjithçka në praktikë.
Së pari, le të vendosim një instalim të thjeshtë Openstack. Meqenëse nuk kam një grup serverësh në dispozicion për eksperimente, ne do të mbledhim prototipin në një server fizik nga makinat virtuale. Po, natyrisht, një zgjidhje e tillë nuk është e përshtatshme për qëllime komerciale, por për të parë një shembull se si funksionon rrjeti në Openstack, një instalim i tillë mjafton për sytë. Për më tepër, një instalim i tillë është edhe më interesant për qëllime trajnimi - pasi mund të kapni trafikun, etj.
Meqenëse na duhet vetëm të shohim pjesën bazë, nuk mund të përdorim disa rrjete, por të ngremë gjithçka duke përdorur vetëm dy rrjete, dhe rrjeti i dytë në këtë plan urbanistik do të përdoret ekskluzivisht për qasje në serverin undercloud dhe DNS. Ne nuk do të prekim rrjetet e jashtme tani për tani - kjo është një temë për një artikull të veçantë të madh.
Pra, le të fillojmë me radhë. Së pari, një teori e vogël. Ne do të instalojmë Openstack duke përdorur TripleO (Openstack në Openstack). Thelbi i TripleO është që ne instalojmë Openstack të gjitha-në-një (d.m.th., në një nyje), të quajtur undercloud, dhe më pas përdorim aftësitë e Openstack të vendosur për të instaluar Openstack të destinuar për operim, të quajtur overcloud. Undercloud do të përdorë aftësinë e tij të natyrshme për të menaxhuar serverët fizikë (metal i zhveshur) - projekti Ironic - për të siguruar hipervizorë që do të kryejnë rolet e llogaritjes, kontrollit, nyjeve të ruajtjes. Kjo do të thotë, ne nuk përdorim asnjë mjet të palës së tretë për të vendosur Openstack - ne vendosim Openstack duke përdorur Openstack. Do të bëhet shumë më e qartë ndërsa instalimi përparon, kështu që ne nuk do të ndalemi këtu dhe të ecim përpara.
Shënim: Në këtë artikull, për hir të thjeshtësisë, nuk përdora izolimin e rrjetit për rrjetet e brendshme Openstack, por gjithçka vendoset duke përdorur vetëm një rrjet. Sidoqoftë, prania ose mungesa e izolimit të rrjetit nuk ndikon në funksionalitetin bazë të zgjidhjes - gjithçka do të funksionojë saktësisht njësoj si kur përdorni izolimin, por trafiku do të rrjedhë në të njëjtin rrjet. Për një instalim komercial, është natyrisht e nevojshme të përdoret izolimi duke përdorur vlan dhe ndërfaqe të ndryshme. Për shembull, trafiku i menaxhimit të ruajtjes ceph dhe vetë trafiku i të dhënave (qasja e makinerisë në disqe, etj.) kur janë të izoluara, përdorin nënrrjeta të ndryshme (Menaxhimi i hapësirës ruajtëse dhe ruajtja) dhe kjo ju lejon ta bëni zgjidhjen më tolerante ndaj gabimeve duke e ndarë këtë trafik, për shembull. , nëpër porte të ndryshme, ose duke përdorur profile të ndryshme QoS për trafik të ndryshëm në mënyrë që trafiku i të dhënave të mos shtrydh trafikun sinjalizues. Në rastin tonë, ata do të shkojnë në të njëjtin rrjet dhe në fakt kjo nuk na kufizon në asnjë mënyrë.
Shënim: Meqenëse do të ekzekutojmë makina virtuale në një mjedis virtual të bazuar në makina virtuale, fillimisht duhet të aktivizojmë virtualizimin e ndërlidhur.
Ju mund të kontrolloni nëse virtualizimi i mbivendosur është i aktivizuar apo jo si kjo:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Nëse shihni shkronjën N, atëherë ne mundësojmë mbështetjen për virtualizimin e mbivendosur sipas çdo udhëzuesi që gjeni në rrjet, p.sh. .
Ne duhet të mbledhim qarkun e mëposhtëm nga makinat virtuale:
Në rastin tim, për të lidhur makinat virtuale që janë pjesë e instalimit të ardhshëm (dhe unë mora 7 prej tyre, por ju mund t'i dilni me 4 nëse nuk keni shumë burime), përdora OpenvSwitch. Krijova një urë ovs dhe lidha makina virtuale me të nëpërmjet grupeve portuale. Për ta bërë këtë, unë krijova një skedar xml si ky:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Këtu janë deklaruar tre grupe portash - dy akses dhe një trunk (ky i fundit ishte i nevojshëm për serverin DNS, por mund të bëni pa të, ose ta instaloni në makinën pritës - cilado që është më e përshtatshme për ju). Më pas, duke përdorur këtë shabllon, ne e deklarojmë tonën 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 ne redaktojmë konfigurimet e portit 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 sepse nuk ka një etiketë vlan. Për ta rregulluar këtë, duhet të lëshoni komandën sudo ovs-vsctl set port ovs-br1 tag=100. Sidoqoftë, pas një rindezjeje, kjo etiketë do të zhduket (nëse dikush e di se si ta bëjë atë të qëndrojë në vend, do të jem shumë mirënjohës). Por kjo nuk është aq e rëndësishme, sepse ne do të na duhet vetëm kjo adresë gjatë instalimit dhe nuk do të na duhet kur Openstack të vendoset plotësisht.
Më pas, ne krijojmë një makinë nën re:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Gjatë instalimit, ju vendosni të gjithë parametrat e nevojshëm, si emrin e makinës, fjalëkalimet, përdoruesit, serverët ntp, etj., mund të konfiguroni menjëherë portet, por për mua personalisht, pas instalimit, është më e lehtë të hyni në makinë përmes konsolën dhe korrigjoni skedarët e nevojshëm. Nëse tashmë keni një imazh të gatshëm, mund ta përdorni ose bëni atë që bëra unë - shkarkoni imazhin minimal të Centos 7 dhe përdorni atë për të instaluar VM.
Pas instalimit të suksesshëm, duhet të keni një makinë virtuale në të cilën mund të instaloni undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningSë pari, instaloni mjetet e nevojshme për procesin e instalimit:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Instalimi nën re
Ne krijojmë një përdorues stack, vendosim një fjalëkalim, e shtojmë atë në sudoer dhe i japim atij mundësinë për të ekzekutuar komandat root përmes sudo pa pasur nevojë të fusë një fjalëkalim:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackTani ne specifikojmë emrin e plotë të undercloud në skedarin e hosteve:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Më pas, ne shtojmë depo dhe instalojmë softuerin 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 keni nevojë të futni komanda të lidhura me ceph. Kam përdorur versionin e Queens, por ju mund të përdorni cilindo që ju pëlqen.
Tjetra, kopjoni skedarin e konfigurimit të undercloud në pirgun e drejtorisë kryesore të përdoruesit:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confTani duhet ta korrigjojmë këtë skedar, duke e përshtatur atë me instalimin tonë.
Ju duhet të shtoni këto rreshta në fillim të skedarit:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Pra, le të kalojmë nëpër cilësimet:
undercloud_hostname — emri i plotë i serverit undercloud, duhet të përputhet me hyrjen në serverin DNS
lokale_ip — adresa lokale e nëncloud drejt ofrimit të rrjetit
portë_rrjeti — e njëjta adresë lokale, e cila do të veprojë si një portë për hyrjen në botën e jashtme gjatë instalimit të nyjeve overcloud, gjithashtu përkon me IP-në lokale
undercloud_public_host — Adresa e jashtme API, caktohet çdo adresë e lirë nga rrjeti sigurues
undercloud_admin_host adresa e brendshme e API-së, caktohet çdo adresë e lirë nga rrjeti sigurues
serverët e emrave të nëncloud - Serveri DNS
gjeneroj_certifikatë_shërbimi - kjo linjë është shumë e rëndësishme në shembullin aktual, sepse nëse nuk e vendosni në false, do të merrni një gabim gjatë instalimit, problemi përshkruhet në gjurmuesin e gabimeve Red Hat
ndërfaqja_lokale ndërfaqe në sigurimin e rrjetit. Kjo ndërfaqe do të rikonfigurohet gjatë vendosjes së undercloud, kështu që ju duhet të keni dy ndërfaqe në undercloud - një për të hyrë në të, e dyta për sigurimin
local_mtu - MTU. Meqenëse ne kemi një laborator testimi dhe unë kam një MTU prej 1500 në portat e ndërprerës OVS, është e nevojshme ta vendosim atë në 1450 në mënyrë që paketat e kapsuluara në VxLAN të kalojnë.
rrjet_cidr — rrjeti i ofrimit
maskaradë — duke përdorur NAT për të hyrë në një rrjet të jashtëm
maskaradë_rrjeti - rrjeti që do të jetë NATed
dhcp_start — adresa fillestare e grupit të adresave nga e cila adresat do t'u caktohen nyjeve gjatë vendosjes së mbicloud
dhcp_fund — adresa përfundimtare e grupit të adresave nga e cila adresat do t'u caktohen nyjeve gjatë vendosjes së mbicloud
inspektim_iprange — një grup adresash të nevojshme për introspeksion (nuk duhet të mbivendosen me grupin e mësipërm)
Scheduler_max_përpjekjet — numri maksimal i përpjekjeve për të instaluar overcloud (duhet të jetë më i madh ose i barabartë me numrin e nyjeve)
Pasi të përshkruhet skedari, mund të jepni komandën për të vendosur undercloud:
openstack undercloud install
Procedura zgjat nga 10 deri në 30 minuta në varësi të hekurit tuaj. Në fund të fundit ju duhet të shihni daljen si kjo:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Ky dalje thotë se ju keni instaluar me sukses undercloud dhe tani mund të kontrolloni statusin e undercloud dhe të vazhdoni të instaloni overcloud.
Nëse shikoni daljen ifconfig, do të shihni se është shfaqur një ndërfaqe e re urë
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Vendosja e mbi cloud tani do të kryhet përmes kësaj ndërfaqe.
Nga dalja e mëposhtme mund të shihni se ne i kemi të gjitha shërbimet në një nyje:
(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 së rrjetit 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 mbi renë
Për momentin kemi vetëm undercloud, dhe nuk kemi mjaft nyje nga të cilat do të montohet overcloud. Prandaj, para së gjithash, le të vendosim makinat virtuale që na duhen. Gjatë vendosjes, vetë undercloud do të instalojë OS dhe softuerin e nevojshëm në makinën overcloud - domethënë, nuk kemi nevojë ta vendosim plotësisht makinën, por vetëm të krijojmë një disk (ose disqe) për të dhe të përcaktojmë parametrat e tij - d.m.th. , në fakt, ne marrim një server të zhveshur pa një OS të instaluar në të.
Le të shkojmë te dosja me disqet e makinave tona virtuale dhe të krijojmë disqe me madhësinë e kërkuar:
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 160GMeqenëse funksionojmë si rrënjë, duhet të ndryshojmë pronarin e këtyre disqeve në mënyrë që të mos kemi problem me të drejtat:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Shënim: nëse nuk planifikoni të instaloni ceph për ta studiuar atë, atëherë komandat nuk krijojnë të paktën 3 nyje me të paktën dy disqe, por në shabllon tregojnë se do të përdoren disqe virtuale vda, vdb, etj.
E shkëlqyeshme, tani duhet të përcaktojmë 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 një komandë -print-xml > /tmp/storage-1.xml, e cila krijon një skedar xml me një përshkrim të secilës makinë në dosjen /tmp/; nëse nuk e shtoni atë, nuk do të jeni në gjendje të identifikojë makinat virtuale.
Tani duhet të përcaktojmë të gjitha këto makina në virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Tani një nuancë e vogël - tripleO përdor IPMI për të menaxhuar serverët gjatë instalimit dhe introspeksionit.
Introspeksioni është procesi i inspektimit të harduerit për të marrë parametrat e tij të nevojshëm për sigurimin e mëtejshëm të nyjeve. Introspeksioni kryhet duke përdorur ironi, një shërbim i krijuar për të punuar me serverë metalikë të zhveshur.
Por këtu është problemi - ndërsa serverët IPMI të harduerit kanë një portë të veçantë (ose një port të përbashkët, por kjo nuk është e rëndësishme), atëherë makinat virtuale nuk kanë porte të tilla. Këtu na vjen në ndihmë një paterica e quajtur vbmc - një mjet që ju lejon të imitoni një port IPMI. Kjo nuancë ia vlen t'i kushtohet vëmendje veçanërisht atyre që duan të ngrenë një laborator të tillë në një hipervizor ESXI - të jem i sinqertë, nuk e di nëse ka një analog të vbmc, kështu që ia vlen të pyesësh për këtë çështje përpara se të vendosësh gjithçka. .
Instaloni vbmc:
yum install yum install python2-virtualbmcNëse OS juaj nuk mund ta gjejë paketën, atëherë shtoni depon:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmTani kemi vendosur shërbimin. Gjithçka këtu është banale deri në turp. Tani është logjike që nuk ka serverë në listën vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Që ato të shfaqen, ato duhet të deklarohen manualisht si kjo:
[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 ~]#Unë mendoj se sintaksa e komandës është e qartë pa shpjegim. Megjithatë, tani për tani të gjitha seancat tona janë në statusin DOWN. Që ata të kalojnë në statusin UP, duhet t'i aktivizoni:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Dhe prekja e fundit - duhet të korrigjoni rregullat e murit të zjarrit (ose ta çaktivizoni 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ë shkojmë në undercloud dhe të kontrollojmë që gjithçka po funksionon. Adresa e makinës pritëse është 192.168.255.200, në undercloud shtuam paketën e nevojshme ipmitool gjatë përgatitjes për vendosje:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningSiç mund ta shihni, ne kemi nisur me sukses nyjen e kontrollit përmes vbmc. Tani le ta fikim dhe të vazhdojmë:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Hapi tjetër është introspeksioni i nyjeve në të cilat do të instalohet overcloud. Për ta bërë këtë, ne duhet të përgatisim një skedar json me një përshkrim të nyjeve tona. Ju lutemi vini re se, ndryshe nga instalimi në serverë të zhveshur, skedari tregon portën në të cilën po funksionon vbmc për secilën makinë.
[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: nyja e kontrollit ka dy ndërfaqe, por në këtë rast kjo nuk është e rëndësishme, në këtë instalim një do të na mjaftojë.
Tani përgatisim skedarin json. Ne duhet të tregojmë adresën poppy të portit përmes së cilës do të kryhet provizioni, parametrat e nyjeve, t'u japim emra dhe të tregojmë se 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 duhet të përgatisim imazhe për ironi. Për ta bërë këtë, shkarkoni ato përmes wget dhe instaloni:
(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 ~]$Ngarkimi i imazheve në undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Kontrolloni nëse të gjitha imazhet janë ngarkuar
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Një gjë tjetër - duhet të shtoni një server 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 is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Tani mund të japim komandën për introspeksion:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Siç mund ta shihni nga dalja, gjithçka përfundoi pa gabime. Le të kontrollojmë që të gjitha nyjet janë në gjendjen e disponueshme:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Nëse nyjet janë në një gjendje tjetër, zakonisht të menaxhueshme, atëherë diçka shkoi keq dhe ju duhet të shikoni regjistrin dhe të kuptoni pse ndodhi kjo. Mbani në mend se në këtë skenar ne po përdorim virtualizimin dhe mund të ketë gabime që lidhen me përdorimin e makinave virtuale ose vbmc.
Më pas, duhet të tregojmë se cila nyje do të kryejë cilin funksion - domethënë, të tregojmë profilin me të cilin do të vendoset nyja:
(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 secilën nyje:
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-d9afb69d1167Le të kontrollojmë 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ë e saktë, ne japim komandën për të vendosur overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuNë një instalim real, shabllonet e personalizuar do të përdoren natyrshëm, në rastin tonë kjo do ta komplikojë shumë procesin, pasi çdo modifikim në shabllon do të duhet të shpjegohet. Siç u shkrua më herët, edhe një instalim i thjeshtë do të na mjaftojë për të parë se si funksionon.
Shënim: ndryshorja qemu e tipit --libvirt është e nevojshme në këtë rast, pasi ne do të përdorim virtualizimin e mbivendosur. Përndryshe, nuk do të jeni në gjendje të ekzekutoni makina virtuale.
Tani keni rreth një orë, ose ndoshta më shumë (në varësi të aftësive të harduerit) dhe mund të shpresoni vetëm se pas kësaj kohe do të shihni mesazhin e mëposhtëm:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Tani ju keni një version pothuajse të plotë të openstack, mbi të cilin mund të studioni, eksperimentoni, etj.
Le të kontrollojmë që gjithçka po funksionon siç duhet. Në grupin e direktorive kryesore të përdoruesit ka dy skedarë - një stackrc (për menaxhimin e undercloud) dhe i dyti overcloudrc (për menaxhimin e overcloud). Këto skedarë duhet të specifikohen si burim, pasi përmbajnë informacione të nevojshme për vërtetim.
(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 ~]$Instalimi im kërkon ende një prekje të vogël - duke shtuar një rrugë në kontrollues, pasi makina me të cilën po punoj është në një rrjet tjetër. Për ta bërë këtë, shkoni te kontrolli-1 nën llogarinë e administratorit të ngrohjes dhe regjistroni itinerarin
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Epo, tani mund të shkoni në horizont. Të gjitha informacionet - adresat, identifikimi dhe fjalëkalimi - janë në skedarin /home/stack/overcloudrc. Diagrami përfundimtar duket si ky:
Nga rruga, në instalimin tonë, adresat e makinerive u lëshuan përmes DHCP dhe, siç mund ta shihni, ato lëshohen "rastësisht". Ju mund të përcaktoni rreptësisht në shabllon se cila adresë duhet t'i bashkëngjitet cilës makinë gjatë vendosjes, nëse ju nevojitet.
Si rrjedh trafiku midis makinave virtuale?
Në këtë artikull do të shikojmë tre opsione për kalimin e trafikut
- Dy makina në një hipervizor në një rrjet L2
- Dy makina në hipervizorë të ndryshëm në të njëjtin rrjet L2
- Dy makina në rrjete të ndryshme (rrënjosje në rrjet)
Rastet me akses në botën e jashtme përmes një rrjeti të jashtëm, duke përdorur adresa lundruese, si dhe me rrugë të shpërndarë, do t'i shqyrtojmë herën tjetër, tani për tani do të fokusohemi në trafikun e brendshëm.
Për të kontrolluar, le të bëjmë së bashku diagramin e mëposhtëm:
Ne kemi krijuar 4 makina virtuale - 3 në një rrjet L2 - net-1, dhe 1 më shumë 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ë ndodhen 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 |
(mbi re) [stack@undercloud ~]$
Makinat vm-1 dhe vm-3 janë të vendosura në compute-0, makinat vm-2 dhe vm-4 janë të vendosura në nyjen compute-1.
Për më tepër, një ruter virtual është krijuar për të mundësuar rrugëzimin midis rrjeteve të specifikuara:
(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 ~]$ Ruteri ka dy porte virtuale, të cilat veprojnë si porta 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 përpara se të shohim se si rrjedh trafiku, le të shohim se çfarë kemi aktualisht në nyjen e kontrollit (e cila është gjithashtu një nyje rrjeti) dhe në nyjen llogaritëse. Le të fillojmë me nyjen llogaritëse.
[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 ~]$Për momentin, nyja ka tre ura ovs - br-int, br-tun, br-ex. Midis tyre, siç e shohim, ekziston një grup ndërfaqesh. Për lehtësinë e të kuptuarit, le të vizatojmë të gjitha këto ndërfaqe në diagram dhe të shohim se çfarë ndodh.
Duke parë adresat në të cilat janë ngritur tunelet VxLAN, mund të shihet se një tunel është ngritur në llogaritje-1 (192.168.255.26), tuneli i dytë duket në kontroll-1 (192.168.255.15). Por gjëja më interesante është se br-ex nuk ka ndërfaqe fizike dhe nëse shikoni se çfarë fluksesh janë konfiguruar, mund të shihni se kjo urë mund të heqë trafikun vetëm për momentin.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Siç mund ta shihni nga dalja, adresa vidhoset drejtpërdrejt në portin fizik, dhe jo në ndërfaqen virtuale të urës.
[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ë ka ardhur nga porti phy-br-ex duhet të hidhet poshtë.
Në fakt, aktualisht nuk ka askund tjetër që trafiku të hyjë në këtë urë përveç nga kjo ndërfaqe (ndërfaqja me br-int), dhe duke gjykuar nga pikat, trafiku BUM tashmë ka fluturuar në urë.
Kjo do të thotë, trafiku mund të largohet nga kjo nyje vetëm përmes tunelit VxLAN dhe asgjë tjetër. Megjithatë, nëse ndizni DVR-në, situata do të ndryshojë, por do ta trajtojmë këtë herë tjetër. Kur përdorni izolimin e rrjetit, për shembull duke përdorur vlans, nuk do të keni një ndërfaqe L3 në vlan 0, por disa ndërfaqe. Sidoqoftë, trafiku VxLAN do të largohet nga nyja në të njëjtën mënyrë, por gjithashtu i kapsuluar në një lloj vlan të dedikuar.
Kemi renditur nyjen llogaritëse, le të kalojmë te nyja e kontrollit.
[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ë themi se gjithçka është e njëjtë, por adresa IP nuk është më në ndërfaqen fizike, por në urën virtuale. Kjo është bërë sepse ky port është porti përmes të cilit trafiku do të dalë në botën e jashtme.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Ky port është i lidhur me urën br-ex dhe meqenëse nuk ka etiketa vlan në të, ky port është një port trunk në të cilin lejohen të gjitha vlanet, tani trafiku del jashtë pa etiketë, siç tregohet nga vlan-id 0 në prodhimi i mësipërm.
Çdo gjë tjetër për momentin është e ngjashme me nyjen llogaritëse - të njëjtat ura, të njëjtat tunele që shkojnë në dy nyje llogaritëse.
Ne nuk do t'i konsiderojmë nyjet e ruajtjes në këtë artikull, por për ta kuptuar është e nevojshme të thuhet se pjesa e rrjetit të këtyre nyjeve është banale deri në turp. Në rastin tonë, ekziston vetëm një port fizik (eth0) me një adresë IP të caktuar dhe kaq. Nuk ka tunele VxLAN, ura tunelesh, etj. - nuk ka fare ovs, pasi nuk ka asnjë pikë në të. Kur përdorni izolimin e rrjetit, kjo nyje do të ketë dy ndërfaqe (porte fizike, bodny, ose vetëm dy vlan - nuk ka rëndësi - varet nga ajo që dëshironi) - një për menaxhimin, e dyta për trafikun (shkrimi në diskun VM , lexim nga disku, etj.)
Ne kuptuam se çfarë kemi në nyje në mungesë të ndonjë shërbimi. Tani le të lançojmë 4 makina virtuale dhe të shohim se si ndryshon skema e përshkruar më sipër - duhet të kemi porte, ruterë virtualë, etj.
Deri tani rrjeti ynë duket si ky:
Ne kemi dy makina virtuale në çdo nyje kompjuterike. Duke përdorur compute-0 si shembull, le të shohim se si përfshihet gjithçka.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Makina ka vetëm një ndërfaqe virtuale - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Kjo ndërfaqe duket në urën linux:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Siç mund ta shihni nga dalja, ka vetëm dy ndërfaqe në urë - tap95d96a75-a0 dhe qvb95d96a75-a0.
Këtu ia vlen të ndalemi pak në llojet e pajisjeve të rrjetit virtual në OpenStack:
vtap - ndërfaqe virtuale e bashkangjitur në një shembull (VM)
qbr - urë Linux
qvb dhe qvo - çifti vEth i lidhur me urën Linux dhe urën Open vSwitch
br-int, br-tun, br-vlan — Hap urat vSwitch
patch-, int-br-, phy-br- - Hap ndërfaqet vSwitch patch që lidhin urat
qg, qr, ha, fg, sg - Hap portat vSwitch të përdorura nga pajisjet virtuale për t'u lidhur me OVS
Siç e kuptoni, nëse kemi një port qvb95d96a75-a0 në urë, e cila është një çift vEth, atëherë diku është homologu i tij, i cili logjikisht duhet të quhet qvo95d96a75-a0. Le të shohim se cilat 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ç mund ta shohim, porti është në br-int. Br-int vepron si një ndërprerës që përfundon portet e makinës virtuale. Përveç qvo95d96a75-a0, porta qvo5bd37136-47 është e dukshme në dalje. Ky është porti për makinën e dytë virtuale. Si rezultat, diagrami ynë tani duket si ky:
Një pyetje që duhet të interesojë menjëherë lexuesin e vëmendshëm - cila është ura linux midis portit të makinës virtuale dhe portit OVS? Fakti është se për të mbrojtur makinën, përdoren grupe sigurie, të cilat nuk janë asgjë më shumë se iptables. OVS nuk funksionon me iptables, kështu që kjo "paterica" u shpik. Megjithatë, ai po bëhet i vjetëruar - ai po zëvendësohet nga conntrack në publikimet e reja.
Kjo do të thotë, në fund të fundit skema duket si kjo:
Dy makina në një hipervizor në një rrjet L2
Meqenëse këto dy VM janë të vendosura në të njëjtin rrjet L2 dhe në të njëjtin hipervizor, trafiku midis tyre logjikisht do të rrjedhë lokalisht përmes br-int, pasi të dy makinat do të jenë në të njëjtin VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Dy makina në hipervizorë të ndryshëm në të njëjtin rrjet L2
Tani le të shohim se si do të shkojë trafiku midis dy makinave në të njëjtin rrjet L2, por të vendosura në hipervizorë të ndryshëm. Për të qenë i sinqertë, asgjë nuk do të ndryshojë shumë, thjesht trafiku midis hipervizorëve do të kalojë përmes tunelit vxlan. Le të shohim një shembull.
Adresat e makinave virtuale ndërmjet të cilave do të shikojmë trafikun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Ne shikojmë tabelën e përcjelljes 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 çfarë lloj porti është:
[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 ~]$Kjo është patch-tun - domethënë ndërfaqja 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 është e paketuar në VxLAN dhe dërgohet në portin 2. Le të shohim se ku të çon porti 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Ky është një tunel vxlan në compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Le të shkojmë te compute-1 dhe të shohim se çfarë ndodh më pas me paketën:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac është në tabelën e përcjelljes br-int në compute-1, dhe siç mund të shihet nga dalja e mësipërme, është e dukshme 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:46Epo, atëherë shohim që në br-int në compute-1 ka një lulekuqe destinuese:
[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 ~]$ Kjo do të thotë, paketa e marrë do të fluturojë në portin 3, pas së cilës tashmë ekziston një shembull i makinës virtuale-00000003.
Bukuria e vendosjes së Openstack për të mësuar në infrastrukturën virtuale është se ne mund të kapim lehtësisht trafikun midis hipervizorëve dhe të shohim se çfarë po ndodh me të. Kjo është ajo që do të bëjmë tani, ekzekutoni tcpdump në portën vnet drejt compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Rreshti i parë tregon se Patek nga adresa 10.0.1.85 shkon në adresën 10.0.1.88 (trafik ICMP), dhe është i mbështjellë në një pako VxLAN me vni 22 dhe paketa shkon nga hosti 192.168.255.19 (llogarit-0) në host 192.168.255.26 .1 (llogarit-XNUMX). Mund të kontrollojmë nëse VNI përputhet me atë të specifikuar në ovs.
Le të kthehemi në këtë linjë veprimet=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],dalja:2. 0x16 është vni në sistemin e numrave heksadecimal. Le ta kthejmë këtë numër në sistemin e 16-të:
16 = 6*16^0+1*16^1 = 6+16 = 22Kjo do të thotë, vni korrespondon me realitetin.
Rreshti i dytë tregon trafikun e kthimit, mirë, nuk ka kuptim ta shpjegojmë, gjithçka është e qartë atje.
Dy makineri në rrjete të ndryshme (drejtimi ndër-rrjet)
Rasti i fundit për sot është rrugëtimi ndërmjet rrjeteve brenda një projekti duke përdorur një ruter virtual. Ne po shqyrtojmë një rast pa DVR (do ta shikojmë në një artikull tjetër), kështu që rutimi ndodh në nyjen e rrjetit. Në rastin tonë, nyja e rrjetit nuk vendoset në një entitet të veçantë dhe ndodhet në nyjen e kontrollit.
Së pari, le të shohim se rutimi funksionon:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msMeqenëse në këtë rast paketa duhet të shkojë në gateway dhe të drejtohet atje, ne duhet të gjejmë adresën poppy të portës, për të cilën shikojmë tabelën ARP në shembull:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Tani le të shohim se ku duhet të dërgohet trafiku me destinacion (10.0.1.254) fa:16:3e:c4:64:70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Le të shohim se ku të çon porti 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 ~]$ Gjithçka është logjike, trafiku shkon në br-tun. Le të shohim se në cilin tunel vxlan do të mbështillet:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Porti i tretë është 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 ~]$ E cila shikon nyjen 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 ka arritur në nyjen e kontrollit, kështu që ne duhet të shkojmë në të dhe të shohim se si do të ndodhë itinerari.
Siç e mbani mend, nyja e kontrollit brenda dukej saktësisht e njëjtë me nyjen llogaritëse - të njëjtat tre ura, vetëm br-ex kishte një portë fizike përmes së cilës nyja mund të dërgonte trafikun jashtë. Krijimi i instancave ndryshoi konfigurimin në nyjet llogaritëse - linux bridge, iptables dhe ndërfaqet u shtuan në nyje. Krijimi i rrjeteve dhe një ruteri virtual gjithashtu la gjurmë në konfigurimin e nyjes së kontrollit.
Pra, është e qartë se adresa MAC e portës duhet të jetë në tabelën e përcjelljes br-int në nyjen e kontrollit. Le të kontrollojmë nëse ë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 është i dukshëm nga porta qr-0c52b15f-8f. Nëse i kthehemi listës së portave virtuale në Openstack, ky lloj porti përdoret për të lidhur pajisje të ndryshme virtuale me OVS. Për të qenë më të saktë, qr është një port në ruterin virtual, i cili përfaqësohet si një hapësirë emri.
Le të shohim se cilat hapësira emrash 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 ~]$ Deri në tre kopje. Por duke gjykuar nga emrat, ju mund të merrni me mend qëllimin e secilit prej tyre. Ne do të kthehemi te shembujt me ID 0 dhe 1 më vonë, tani jemi të interesuar për hapësirën e emrave 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 ~]$ Kjo hapësirë emri përmban dy të brendshme që kemi krijuar më parë. Të dy portet virtuale janë shtuar në br-int. Le të kontrollojmë adresën mac të portit qr-0c52b15f-8f, pasi trafiku, duke gjykuar nga adresa mac i destinacionit, shkoi 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<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Kjo do të thotë, në këtë rast, gjithçka funksionon sipas ligjeve të kursit standard. Meqenëse trafiku është i destinuar për hostin 10.0.2.8, ai duhet të dalë përmes ndërfaqes së dytë qr-92fa49b5-54 dhe të kalojë përmes tunelit vxlan në nyjen llogaritëse:
[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 ~]$ Gjithçka është logjike, pa surpriza. Le të shohim se ku është e dukshme adresa poppy e hostit 10.0.2.8 në br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Siç pritej, trafiku shkon në br-tun, le të shohim se në cilin tunel shkon trafiku më pas:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Trafiku shkon në tunel për të llogaritur-1. Epo, në compute-1 gjithçka është e thjeshtë - nga br-tun paketa shkon në br-int dhe prej andej 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ë që kjo është me të vërtetë ndërfaqja e saktë:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$
Në fakt, ne e kaluam gjithë rrugën përmes paketës. Mendoj se keni vënë re që trafiku kalonte nëpër tunele të ndryshme vxlan dhe dilte me VNI të ndryshme. Le të shohim se çfarë lloj VNI janë këto, pas së cilës do të mbledhim një hale në portën e kontrollit të nyjës dhe do të sigurohemi që trafiku të rrjedhë saktësisht siç përshkruhet më sipër.
Pra, tuneli për të llogaritur-0 ka veprimet e mëposhtme=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Le ta kthejmë 0x16 në sistemin e numrave dhjetorë:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tuneli për llogaritjen-1 ka VNI-në e mëposhtme:aksione=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],dalje:2. Le ta kthejmë 0x63 në sistemin e numrave dhjetorë:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Epo, tani le të shohim hale:
[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 (llogari-0) në host 192.168.255.15 (kontroll-1) me vni 22, brenda së cilës një paketë ICMP paketohet nga hosti 10.0.1.85 në host 10.0.2.8. Siç kemi llogaritur më lart, vni përputhet me atë që pamë në dalje.
Paketa e dytë është një paketë vxlan nga hosti 192.168.255.15 (control-1) në host 192.168.255.26 (llogarit-1) me vni 99, brenda së cilës një paketë ICMP paketohet nga hosti 10.0.1.85 në host 10.0.2.8. Siç kemi llogaritur më lart, vni përputhet me atë që pamë në dalje.
Dy paketat e ardhshme janë trafik kthimi nga 10.0.2.8 jo 10.0.1.85.
Kjo do të thotë, në fund kemi marrë skemën e mëposhtme të nyjeve të kontrollit:
Duket se kjo është ajo? Ne harruam dy hapësira emrash:
[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 ~]$ Ndërsa folëm për arkitekturën e platformës cloud, do të ishte mirë që makinat të merrnin adresat automatikisht nga një server DHCP. Këta janë dy serverë DHCP për dy rrjetet tona 10.0.1.0/24 dhe 10.0.2.0/24.
Le të kontrollojmë nëse kjo është e vërtetë. Ekziston vetëm një adresë në këtë hapësirë emri - 10.0.1.1 - adresa e vetë serverit DHCP, dhe gjithashtu përfshihet në br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Le të shohim nëse proceset që përmbajnë qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 në emrin e tyre në nyjen e kontrollit:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Ekziston një proces i tillë dhe bazuar në informacionin e paraqitur në outputin e mësipërm, mund të shohim, për shembull, se çfarë kemi aktualisht me qira:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Si rezultat, ne marrim grupin e mëposhtëm të shërbimeve në nyjen e kontrollit:
Epo, mbani në mend - këto janë vetëm 4 makina, 2 rrjete të brendshme dhe një ruter virtual... Ne nuk kemi rrjete të jashtme këtu tani, një mori projektesh të ndryshme, secila me rrjetet e veta (të mbivendosura), dhe ne kemi një ruter i shpërndarë fiket, dhe në fund, në fund të fundit, kishte vetëm një nyje kontrolli në bankën e provës (për tolerancën e gabimeve duhet të ketë një kuorum prej tre nyjeve). Është logjike që në tregti gjithçka është "pak" më e ndërlikuar, por në këtë shembull të thjeshtë kuptojmë se si duhet të funksionojë - nëse keni 3 apo 300 hapësira emrash është sigurisht e rëndësishme, por nga pikëpamja e funksionimit të të gjithë Struktura, asgjë nuk do të ndryshojë shumë... edhe pse deri sa nuk do të lidhni ndonjë SDN të shitësit. Por kjo është një histori krejtësisht tjetër.
Shpresoj se ishte interesante. Nëse keni ndonjë koment/shtesë, ose diku kam gënjyer plotësisht (Unë jam njeri dhe mendimi im do të jetë gjithmonë subjektiv) - shkruani atë që duhet korrigjuar/shtuar - ne do të korrigjojmë/shtojmë gjithçka.
Si përfundim, do të doja të them disa fjalë në lidhje me krahasimin e Openstack (si vanilje ashtu edhe shitës) me zgjidhjen cloud nga VMWare - kjo pyetje më është bërë shumë shpesh gjatë dy viteve të fundit dhe, sinqerisht, jam tashmë të lodhur prej saj, por ende. Për mendimin tim, është shumë e vështirë të krahasohen këto dy zgjidhje, por patjetër mund të themi se ka disavantazhe në të dyja zgjidhjet dhe kur zgjedh një zgjidhje duhet të peshosh të mirat dhe të këqijat.
Nëse OpenStack është një zgjidhje e drejtuar nga komuniteti, atëherë VMWare ka të drejtë të bëjë vetëm atë që dëshiron (lexo - çfarë është fitimprurëse për të) dhe kjo është logjike - sepse është një kompani tregtare që është mësuar të fitojë para nga klientët e saj. Por ka një të madhe dhe të trashë POR - mund të dilni nga OpenStack, për shembull nga Nokia, dhe me pak shpenzime të kaloni në një zgjidhje nga, për shembull, Juniper (Contrail Cloud), por nuk ka gjasa të jeni në gjendje të dilni nga VMWare . Për mua, këto dy zgjidhje duken kështu - Openstack (shitësi) është një kafaz i thjeshtë në të cilin jeni futur, por keni një çelës dhe mund të largoheni në çdo kohë. VMWare është një kafaz i artë, pronari e ka çelësin e kafazit dhe do t'ju kushtojë shumë.
Unë nuk po promovoj as produktin e parë dhe as të dytin - ju zgjidhni atë që ju nevojitet. Por nëse do të kisha një zgjedhje të tillë, do të zgjidhja të dyja zgjidhjet - VMWare për cloud-in e IT (ngarkesa të ulëta, menaxhim i lehtë), OpenStack nga disa shitës (Nokia dhe Juniper ofrojnë zgjidhje shumë të mira me çelës në dorë) - për renë e Telekomit. Unë nuk do të përdorja Openstack për IT të pastër - është si të gjuash harabela me një top, por nuk shoh ndonjë kundërindikacion për ta përdorur atë përveç tepricës. Sidoqoftë, përdorimi i VMWare në telekom është si të tërheqësh gurë të grimcuar në një Ford Raptor - është i bukur nga jashtë, 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 tij e plotë - kompania nuk do t'ju japë asnjë informacion se si funksionon, për shembull, vSAN ose çfarë është në kernelin e hipervizorit - thjesht nuk është fitimprurëse për të - domethënë, ju do kurrë mos bëhuni ekspert në VMWare - pa mbështetjen e shitësve, ju jeni të dënuar (shumë shpesh takoj ekspertë të VMWare të cilët janë të hutuar nga pyetjet e parëndësishme). Për mua, VMWare po blen një makinë me kapuç të kyçur - po, mund të keni specialistë që mund të ndryshojnë rripin e kohës, por vetëm ai që ju ka shitur këtë zgjidhje mund ta hapë kapakun. Personalisht, nuk më pëlqejnë zgjidhjet në të cilat nuk mund të përshtatem. Ju do të thoni se mund të mos keni nevojë të shkoni nën kapuç. Po, kjo është e mundur, por unë do t'ju shikoj kur të keni nevojë të montoni një funksion të madh në cloud nga 20-30 makina virtuale, 40-50 rrjete, gjysma e të cilave duan të dalin jashtë dhe gjysma e dytë kërkon Përshpejtimi SR-IOV, përndryshe do t'ju duhen më shumë nja dy duzina nga këto makina - përndryshe performanca nuk do të jetë e mjaftueshme.
Ka këndvështrime të tjera, kështu që vetëm ju mund të vendosni se çfarë të zgjidhni dhe, më e rëndësishmja, atëherë do të jeni përgjegjës për zgjedhjen tuaj. Ky është vetëm mendimi im - një person që ka parë dhe prekur të paktën 4 produkte - Nokia, Juniper, Red Hat dhe VMWare. Domethënë, kam diçka për të krahasuar.
Burimi: www.habr.com