Hodeiko informatika gero eta sakonago sartzen ari da gure bizitzan eta seguruenik ez dago hodeiko zerbitzurik gutxienez behin erabili ez duen pertsona bakar bat ere. Hala ere, hodei bat zer den eta nola funtzionatzen duen, jende gutxik daki, baita ideia mailan ere. Dagoeneko 5G errealitate bihurtzen ari da eta telekomunikazio-azpiegitura zutabe-konponbideetatik hodeiko soluzioetara pasatzen hasi da, guztiz hardware-soluzioetatik "zutabe" birtualizatuetara pasa zenean bezalaxe.
Gaur hodeiko azpiegituren barne munduari buruz hitz egingo dugu, bereziki sarearen zatiaren oinarriak aztertuko ditugu.
Zer da hodeia? Birtualizazio bera - profilaren ikuspegia?
Galdera logiko bat baino gehiago. Ez, hau ez da birtualizazioa, hura gabe egin ezin den arren. Ikus ditzagun bi definizio:
Hodeiko informatika (aurrerantzean Hodeia) Zerbitzu-hornitzailearentzat ahalik eta latentzia txikienarekin eta kostu minimoarekin eskaeraren arabera zabaldu eta abiarazi beharreko baliabide informatiko banatuetara erabilerraza den sarbidea eskaintzeko eredu bat da.
Birtualizazioa - entitate fisiko bat (adibidez, zerbitzari bat) hainbat birtualetan banatzeko gaitasuna da, eta horrela baliabideen erabilera areagotzen da (adibidez, 3 zerbitzariak ehuneko 25-30ean kargatuta dituzu, birtualizazioaren ondoren zerbitzari 1 kargatzen duzu ehuneko 80-90ean). Jakina, birtualizazioak baliabide batzuk jaten ditu - hipervisorea elikatu behar duzu, hala ere, praktikak erakutsi bezala, jokoak merezi du kandela. Birtualizazioaren adibide aproposa VMWare da, ezin hobeto prestatzen dituen makina birtualak, edo adibidez KVM, nik nahiago dudana, baina hau gustu kontua da.
Birtualizazioa konturatu gabe erabiltzen dugu, eta burdinazko bideratzaileek ere birtualizazioa erabiltzen dute dagoeneko; adibidez, JunOS-en azken bertsioan, sistema eragilea makina birtual gisa instalatzen da denbora errealeko Linux banaketa baten gainean (Wind River 9). Baina birtualizazioa ez da hodeia, baina hodeia ezin da existitu birtualizaziorik gabe.
Birtualizazioa hodeia eraikitzen den elementuetako bat da.
Hodei bat egitea L2 domeinu bakarrean hainbat hipervisor bilduz, yaml playbook pare bat gehitzea vlan-ak automatikoki erregistratzeko ansible moduko baten bidez eta orkestrazio-sistema bat bezalako zerbait sartzeak makina birtualak automatikoki sortzeko ez du funtzionatuko. Zehatzagoa izango da, baina ondorioz Frankenstein ez da behar dugun hodeia, nahiz eta beste batzuen ametsa izan daitekeen. Gainera, Openstack bera hartzen baduzu, funtsean oraindik Frankenstein da, baina tira, ez dezagun horretaz hitz egin oraingoz.
Baina ulertzen dut goian aurkeztutako definiziotik ez dagoela guztiz argi zer dei daitekeen hodei.
Horregatik, NIST-en (National Institute of Standards and Technology) dokumentu batek hodeiko azpiegitura batek izan behar dituen 5 ezaugarri nagusi eskaintzen ditu:
Eskaeraren arabera zerbitzua eskaintzea. Erabiltzaileari esleitzen zaizkion baliabide informatikoetara doan sarbidea eman behar zaio (esaterako, sareak, disko birtualak, memoria, prozesadore-nukleoak, etab.), eta baliabide horiek automatikoki eman behar zaizkio, hau da, zerbitzu-hornitzailearen esku-hartzerik gabe.
Zerbitzuaren erabilgarritasun zabala. Baliabideetarako sarbidea mekanismo estandarren bidez eman behar da, bai PC estandarrak bai bezero finak eta gailu mugikorrak erabiltzeko.
Baliabideak igerilekuetan konbinatzea. Baliabide-taldeek aldi berean hainbat bezerori baliabideak eskaintzeko gai izan behar dute, bezeroak isolatuak eta elkarrekiko eraginik eta baliabideen lehiarik gabe daudela ziurtatuz. Igerilekuetan sareak ere sartzen dira, eta horrek helbideratze gainjarritako erabiltzeko aukera adierazten du. Igerilekuek eskariaren arabera eskalatzeko gai izan behar dute. Igerilekuak erabiltzeari esker, baliabide fisikoen eta birtualen abstrakzio eta baliabideen akatsen tolerantzia eta abstrakzio maila eskaintzea ahalbidetzen da; zerbitzuaren hartzaileak eskatutako baliabide multzoa besterik ez zaio ematen (baliabide horiek fisikoki non dauden, zenbat eta zenbat). zerbitzariak eta etengailuak - ez dio axola bezeroari). Hala ere, kontuan hartu behar dugu hornitzaileak baliabide horien erreserba gardena bermatu behar duela.
Egokitzapen azkarra baldintza ezberdinetara. Zerbitzuak malguak izan behar dira: baliabideak azkar hornitzea, haiek birbanatzea, baliabideak gehitu edo murriztea bezeroak eskatuta, eta bezeroaren aldetik hodeiko baliabideak amaigabeak direlako sentsazioa izan behar du. Ulertzeko, adibidez, ez duzu ikusten abisurik Apple iCloud-en zure diskoko espazioaren zati bat desagertu dela zerbitzariko disko gogorra matxuratu delako eta unitateak matxuratu direlako. Gainera, zure aldetik, zerbitzu honen aukerak ia mugagabeak dira - 2 TB behar dituzu - ez dago arazorik, ordaindu eta jaso duzu. Google.Drive edo Yandex.Disk-ekin antzeko adibide bat eman daiteke.
Emandako zerbitzua neurtzeko aukera. Hodeiko sistemek automatikoki kontrolatu eta optimizatu behar dituzte kontsumitutako baliabideak, eta mekanismo horiek gardenak izan behar dute erabiltzailearentzat zein zerbitzu hornitzailearentzat. Hau da, zuk eta zure bezeroek zenbat baliabide kontsumitzen dituzun egiaztatu dezakezu beti.
Kontuan izan behar da eskakizun hauek gehienbat hodei publiko baterako eskakizunak direla, beraz, hodei pribatu baterako (hau da, enpresaren barne beharretarako abiarazitako hodei bat), eskakizun horiek apur bat egokitu daitezke. Hala ere, oraindik egin behar dira, bestela ez ditugu hodeiko informatikaren onura guztiak lortuko.
Zergatik behar dugu hodeia?
Hala ere, edozein teknologia berri edo lehendik dagoen, edozein protokolo berri zerbaitetarako sortzen da (beno, RIP-ng izan ezik, noski). Inork ez du protokolorik behar protokolo baten mesedetan (beno, RIP-ng izan ezik, noski). Logikoa da Hodeia erabiltzaileari/bezeroari nolabaiteko zerbitzu bat emateko sortzea. Denok ezagutzen ditugu gutxienez hodeiko zerbitzu pare bat, Dropbox edo Google.Docs adibidez, eta uste dut jende gehienak arrakastaz erabiltzen dituela; adibidez, artikulu hau Google.Docs hodeiko zerbitzua erabiliz idatzi da. Baina ezagutzen ditugun hodeiko zerbitzuak hodeiaren gaitasunen zati bat baino ez dira; zehatzago esanda, SaaS motako zerbitzu bat baino ez dira. Hodeiko zerbitzua hiru modutara eman dezakegu: SaaS, PaaS edo IaaS moduan. Zer zerbitzu behar duzun zure nahien eta gaitasunen araberakoa da.
Ikus ditzagun bakoitza ordenan:
Zerbitzu gisa softwarea (SaaS) bezeroari zerbitzu osoa emateko eredu bat da, adibidez, Yandex.Mail edo Gmail bezalako posta elektronikoko zerbitzu bat. Zerbitzua emateko eredu honetan, zuk, bezero gisa, ez duzu ezer egiten zerbitzuak erabiltzeaz gain, hau da, ez duzu pentsatu behar zerbitzua konfiguratzen, akatsen tolerantzian edo erredundantzian. Gauza nagusia zure pasahitza ez arriskuan jartzea da; zerbitzu honen hornitzaileak egingo du gainerakoa. Zerbitzu-hornitzailearen ikuspuntutik, bera da zerbitzu osoaren ardura osoa - zerbitzariaren hardwaretik eta ostalari-sistema eragileetatik datu-base eta software ezarpenetaraino.
Plataforma Zerbitzu gisa (PaaS) β Eredu hau erabiltzean, zerbitzu hornitzaileak bezeroari zerbitzurako pieza bat eskaintzen dio, adibidez, har dezagun web zerbitzari bat. Zerbitzu-hornitzaileak zerbitzari birtual bat eman zion bezeroari (hain zuzen ere, baliabide multzo bat, hala nola RAM/CPU/Biltegiratze/Sareak, etab.), eta zerbitzari honetan OS eta beharrezko softwarea ere instalatu zuen, hala ere, konfigurazioa. gauza hauek guztiak bezeroak berak egiten ditu eta bezeroak erantzuten du zerbitzua betetzeko. Zerbitzu-hornitzaileak, aurreko kasuan bezala, ekipamendu fisikoen, hipervisoreen, makina birtualaren beraren, sarearen erabilgarritasunaren, etab.en erantzule da, baina zerbitzua bera ez dago jada bere ardura-eremuan.
Azpiegitura zerbitzu gisa (IaaS) - Ikuspegi hori dagoeneko interesgarriagoa da, izan ere, zerbitzu-hornitzaileak bezeroari azpiegitura birtualizatu osoa eskaintzen dio, hau da, baliabide multzo batzuk (pilota), hala nola CPU Nukleoak, RAM, Sareak, etab. Gainontzeko guztia dago. bezeroak - bezeroak zer egin nahi duen baliabide horiekin esleitutako biltegiaren barruan (kuota) - ez da bereziki garrantzitsua hornitzailearentzat. Bezeroak bere vEPC propioa sortu nahi duen edo baita operadore txiki bat sortu eta komunikazio zerbitzuak eskaini nahi dituen ala ez, egin ezazu. Egoera horretan, zerbitzu-hornitzaileak baliabideak hornitzeaz arduratzen da, haien akatsen tolerantziaz eta erabilgarritasunaz, baita baliabide horiek bateratu eta bezeroaren eskura jartzen dituen sistema eragileaz ere, edozein unetan baliabideak handitu edo gutxitzeko gaitasunaz. bezeroak eskatuta. Bezeroak makina birtual guztiak eta beste tinsel batzuk berak konfiguratzen ditu autozerbitzuaren atariaren eta kontsolaren bidez, sareak konfiguratzea barne (kanpoko sareak izan ezik).
Zer da OpenStack?
Hiru aukeretan, zerbitzu hornitzaileak hodeiko azpiegitura bat sortzea ahalbidetuko duen OS bat behar du. Izan ere, SaaS-ekin, dibisio bat baino gehiago arduratzen da teknologien pila osoaren ardura -bada azpiegituraz arduratzen den dibisio bat-, hau da, beste dibisio bati IaaS ematen dio, dibisio honek SaaS eskaintzen dio bezeroari. OpenStack hodeiko sistema eragileetako bat da, etengailu, zerbitzari eta biltegiratze-sistema mordoa baliabide bakarrean biltzeko aukera ematen duena, multzo komun hau azpipooletan (errentari) zatitzea eta baliabide horiek bezeroei sarearen bidez eskaintzea.
OpenStack hodeiko sistema eragile bat da, eta API baten bidez hornitutako eta kudeatutako baliabide informatiko, datuen biltegiratze eta sareko baliabide multzo handiak kontrolatzeko aukera ematen du, autentifikazio-mekanismo estandarrak erabiliz.
Beste era batera esanda, hodeiko zerbitzuak (publikoak zein pribatuak) sortzeko diseinatutako software libreko proiektuen multzoa da hau, hau da, zerbitzaria eta ekipoak baliabide multzo bakarrean konbinatzea eta kudeatzea ahalbidetzen duten tresna multzoa. baliabide horiek, akatsen tolerantzia maila emanez.
Material hau idazteko momentuan, OpenStack egiturak honela dauka:
Bertatik ateratako argazkia
OpenStack-en sartutako osagai bakoitzak funtzio zehatz bat betetzen du. Banatutako arkitektura honek irtenbidean behar dituzun osagai funtzionalen multzoa sartzea ahalbidetzen du. Hala ere, osagai batzuk erro osagaiak dira eta horiek kentzeak soluzio osoaren funtzionagarritasun osoa edo partziala ekarriko du. Osagai hauek normalean honela sailkatu ohi dira:
- arbela β Webean oinarritutako GUI OpenStack zerbitzuak kudeatzeko
- Keystone identitate-zerbitzu zentralizatu bat da, beste zerbitzu batzuetarako autentifikazio- eta baimen-funtzionalitatea eskaintzen duena, baita erabiltzailearen kredentzialak eta haien rolak kudeatzen dituena ere.
- neutroi - OpenStack zerbitzu ezberdinen interfazeen arteko konektagarritasuna eskaintzen duen sare-zerbitzua (VMen arteko konexioa eta kanpoko mundurako sarbidea barne)
- errauts β makina birtualen bloke-biltegiratzerako sarbidea eskaintzen du
- New β makina birtualen bizi-zikloaren kudeaketa
- Glance β makina birtualen irudien eta argazkien biltegia
- Swift β biltegiratze-objekturako sarbidea ematen du
- Ceilometroa β telemetria biltzeko eta erabilgarri dauden eta kontsumitutako baliabideak neurtzeko gaitasuna ematen duen zerbitzua
- Bero β baliabideak automatikoki sortzeko eta hornitzeko txantiloietan oinarritutako orkestrazioa
Proiektu guztien eta haien helburuaren zerrenda osoa ikus daiteke .
OpenStack osagai bakoitza funtzio zehatz bat betetzen duen zerbitzu bat da eta funtzio hori kudeatzeko eta hodeiko sistema eragileko beste zerbitzu batzuekin elkarreragiteko API bat eskaintzen du azpiegitura bateratu bat sortzeko. Adibidez, Novak baliabide informatikoen kudeaketa eta baliabide horiek konfiguratzeko API bat eskaintzen du, Glance-k irudien kudeaketa eta horiek kudeatzeko API bat eskaintzen du, Cinder-ek blokeen biltegiratzea eta kudeatzeko API bat, etab. Funtzio guztiak elkarri lotuta daude oso modu estuan.
Hala ere, begiratuz gero, OpenStack-en exekutatzen diren zerbitzu guztiak sarera konektatuta dauden makina birtual (edo edukiontzi) moduko bat dira. Galdera sortzen da: zergatik behar ditugu hainbeste elementu?
Goazen makina birtual bat sortzeko eta Openstack-en sarera eta biltegiratze iraunkorra konektatzeko algoritmoa.
- Makina bat sortzeko eskaera bat sortzen duzunean, izan Horizon (Dashboard) edo CLI bidezko eskaera bat, gertatzen den lehenengo gauza Keystone-n zure eskaeraren baimena da - sor dezakezu makina bat, badu sare hau erabiltzeko eskubidea, zure zirriborroa egiten du, etab.
- Keystone-k zure eskaera autentifikatzen du eta autentifikazio-token bat sortzen du erantzun-mezuan, gehiago erabiliko dena. Keystoneren erantzuna jaso ondoren, eskaera Novara bidaltzen da (nova api).
- Nova-api-k zure eskaeraren baliozkotasuna egiaztatzen du Keystonerekin harremanetan jarriz aurrez sortutako autentifikazio-tokena erabiliz
- Keystone-k autentifikazioa egiten du eta baimen eta murrizketei buruzko informazioa ematen du autentifikazio-token honetan oinarrituta.
- Nova-api-k VM berrirako sarrera bat sortzen du nova-databasean eta makina sortzeko eskaera nova-scheduler-i pasatzen dio.
- Nova-scheduler-ek VM-a zabalduko den ostalaria (ordenagailu-nodoa) hautatzen du zehaztutako parametro, pisu eta zonen arabera. Honen erregistroa eta VM IDa nova-databasean idazten dira.
- Ondoren, nova-scheduler-ek nova-compute-rekin harremanetan jartzen du instantzia bat zabaltzeko eskaera batekin. Nova-compute-k nova-conductor-ekin harremanetan jartzen ditu makinen parametroei buruzko informazioa lortzeko (nova-conductor nova-database eta nova-compute-ren artean proxy zerbitzari gisa jarduten duen elementu nova da, nova-databaserako eskaera kopurua mugatuz datu-basearekin arazoak saihesteko. koherentzia-karga murriztea).
- Nova-conductor-ek eskatutako informazioa nova-databasetik jasotzen du eta nova-compute-ra pasatzen du.
- Ondoren, nova-compute-k begirada bat deitzen du irudiaren IDa lortzeko. Glace-k eskaera balioztatu du Keystonen eta eskatutako informazioa itzultzen du.
- Nova-konputazioa neutroiarekin harremanetan jartzen da sareko parametroei buruzko informazioa lortzeko. Begiradaren antzera, neutronek eskaera balioztatzen du Keystonen, eta ondoren datu-basean sarrera bat sortzen du (portuaren identifikatzailea, etab.), ataka bat sortzeko eskaera sortzen du eta eskatutako informazioa itzultzen du nova-compute-ra.
- Nova-compute-k erraustu egiten du makina birtualera bolumen bat esleitzeko eskaerarekin. Begiradaren antzera, sagardoak eskaera balioztatzen du Keystonen, bolumena sortzeko eskaera bat sortzen du eta eskatutako informazioa itzultzen du.
- Nova-compute-k libvirt-ekin harremanetan jartzen du zehaztutako parametroekin makina birtual bat zabaltzeko eskaerarekin.
Izan ere, makina birtual soil bat sortzeko eragiketa itxuraz sinplea hodeiko plataformako elementuen arteko API deien zurrunbiloa bihurtzen da. Gainera, ikus dezakezun bezala, aurretik izendatutako zerbitzuak ere osagai txikiagoz osatuta daude eta horien artean elkarrekintza gertatzen da. Makina bat sortzea hodeiko plataformak egiteko aukera ematen duenaren zati txiki bat baino ez da - trafikoa orekatzeaz arduratzen den zerbitzu bat dago, blokeen biltegiratzeaz arduratzen den zerbitzu bat, DNSz arduratzen den zerbitzu bat, metalezko zerbitzariak hornitzeaz arduratzen den zerbitzu bat, etab. Hodeiari esker, zure makina birtualak ardi artalde bat bezala tratatu behar dituzu (birtualizazioaren aurka). Ingurune birtualean zure makinari zerbait gertatzen bazaio - babeskopietatik eta abarretatik leheneratzen baduzu, baina hodeiko aplikazioak makina birtualak hain garrantzirik ez duen moduan eraikitzen dira - makina birtuala "hil egin da" - ez dago arazorik. - berri bat sortu besterik ez da ibilgailua txantiloian oinarritzen da eta, esaten den bezala, taldeek ez zuten borrokalariaren galera nabaritu. Jakina, horrek orkestrazio mekanismoen presentzia eskaintzen du - Heat txantiloiak erabiliz, dozenaka sare eta makina birtualek osatutako funtzio konplexu bat erraz zabaldu dezakezu.
Kontuan izan behar da beti ez dagoela hodeiko azpiegiturarik sarerik gabe: elementu bakoitzak era batera edo bestera elkarreragiten du sarearen bidez beste elementu batzuekin. Gainera, hodeiak sare guztiz ez-estatikoa du. Jakina, azpiko sarea are gehiago edo gutxiago estatikoa da - nodo eta etengailu berriak ez dira egunero gehitzen, baina gainjarritako osagaia etengabe aldatu daiteke eta ezinbestean aldatuko da - sare berriak gehitu edo ezabatuko dira, makina birtual berriak agertuko dira eta zaharrak. hil. Eta artikuluaren hasieran emandako hodeiaren definiziotik gogoratzen duzunez, baliabideak erabiltzaileari automatikoki esleitu behar zaizkio eta zerbitzu-hornitzailearen esku-hartze gutxien (edo hobeto esanda, gabe). Hau da, sare-baliabideen hornikuntza-mota gaur egun frontend moduan dagoen zure kontu pertsonala http/https-ren bidez eta Vasily laneko sare-ingeniaria backend moduan eskuragarri dagoen moduan ez da hodei bat, nahiz eta Vasilyk zortzi esku baditu.
Neutronek, sareko zerbitzu gisa, hodeiko azpiegituraren sare-zatia kudeatzeko API bat eskaintzen du. Zerbitzuak Openstack-en sareko zatia ahalmentzen eta kudeatzen du Network-as-a-Service (NaaS) izeneko abstrakzio-geruza bat eskainiz. Hau da, sarea, adibidez, CPU birtualen nukleoen edo RAM kantitatearen unitate neurgarri birtual bera da.
Baina OpenStack-en sare-zatiaren arkitekturara pasatu aurretik, azter dezagun nola funtzionatzen duen sare honek OpenStack-en eta zergatik den sarea hodeiaren zati garrantzitsu eta integrala.
Beraz, bi RED bezero VM eta bi GREEN bezero VM ditugu. Demagun makina hauek bi hiperbissoretan kokatuta daudela modu honetan:
Momentuz, 4 zerbitzarien birtualizazioa besterik ez da eta ezer gehiago, orain arte egin dugun guztia 4 zerbitzari birtualizatzea da, bi zerbitzari fisikotan jarriz. Eta orain arte ez daude sarera konektatuta ere.
Hodei bat egiteko, hainbat osagai gehitu behar ditugu. Lehenik eta behin, sarearen zatia birtualizatzen dugu: 4 makina hauek binaka konektatu behar ditugu eta bezeroek L2 konexioa nahi dute. Switch bat erabil dezakezu eta enbor bat bere norabidean konfiguratu eta dena konpon dezakezu linux zubi baten bidez edo, erabiltzaile aurreratuagoentzat, openvswitch (aurrerago itzuliko gara hona). Baina sare asko egon daitezke, eta etengabe L2 etengailu baten bidez bultzatzea ez da ideiarik onena - sail desberdinak daude, zerbitzu-mahai bat, hilabeteak aplikazio bat amaitu arte itxaron, arazoak konpontzeko asteak - mundu modernoan hau hurbilketak ez du funtzionatzen jada. Eta zenbat eta lehenago ulertu enpresa batek, orduan eta errazagoa izango da aurrera egitea. Hori dela eta, hipervisoreen artean gure makina birtualak komunikatuko diren L3 sare bat hautatuko dugu, eta L3 sare horren gainean L2 gainjarri sare birtualak eraikiko ditugu, non gure makina birtualen trafikoa exekutatu den. GRE, Geneve edo VxLAN erabil ditzakezu kapsulatze gisa. Azken honetan zentratu gaitezen oraingoz, bereziki garrantzitsua ez den arren.
VTEP nonbait kokatu behar dugu (espero dut denek ezagutzen dutela VxLAN terminologia). Zerbitzarietatik zuzenean L3 sare bat dugunez, ezerk ez digu VTEP zerbitzarietan jartzea eragozten, eta OVS (OpenvSwitch) bikaina da hori egiteko. Ondorioz, diseinu hau lortu dugu:
VM-en arteko trafikoa banatu behar denez, makina birtualetarako portuek vlan zenbaki desberdinak izango dituzte. Etiketa-zenbakiak etiketa birtual baten barruan bakarrik jokatzen du, izan ere, VxLAN-en kapsulatzen denean erraz kendu dezakegu, VNI bat izango baitugu.
Orain gure makinak eta sare birtualak sor ditzakegu inolako arazorik gabe.
Hala ere, zer gertatzen da bezeroak beste makina bat badu, baina beste sare batean badago? Sareen artean errotzea behar dugu. Aukera sinple bat aztertuko dugu bideratze zentralizatua erabiltzen denean - hau da, trafikoa sareko nodo dedikatu berezien bidez bideratzen da (beno, oro har, kontrol-nodoekin konbinatzen dira, beraz, gauza bera izango dugu).
Badirudi ezer konplikatua ez dela: zubi-interfaze bat egiten dugu kontrol-nodoan, bertara trafikoa gidatzen dugu eta hortik behar dugun tokira bideratzen dugu. Baina arazoa da RED bezeroak 10.0.0.0/24 sarea erabili nahi duela eta GREEN bezeroak 10.0.0.0/24 sarea erabili nahi duela. Hau da, helbide-espazioak gurutzatzen hasten gara. Gainera, bezeroek ez dute nahi beste bezeroek beren barne sareetara bideratu ahal izatea, eta horrek zentzuzkoa du. Sareak eta bezeroen datuen trafikoa bereizteko, izen-espazio bereizi bat esleituko diogu horietako bakoitzari. Namespace Linux sare-pilaren kopia bat da hain zuzen ere, hau da, RED izen-espazioko bezeroak guztiz isolatuta daude GREEN izen-espaziotik bezeroengandik (beno, bezero-sare horien arteko bideratzea onartzen da izen-espazio lehenetsiaren bidez edo gorako garraio-ekipoetan).
Hau da, diagrama hau lortuko dugu:
L2 tunelak konputazio-nodo guztietatik kontrol-nodora bat egiten dute. sare hauetarako L3 interfazea dagoen nodoa, bakoitza isolatzeko izen-espazio dedikatu batean.
Hala ere, garrantzitsuena ahaztu dugu. Makina birtualak zerbitzu bat eman behar dio bezeroari, hau da, gutxienez kanpoko interfaze bat izan behar du, bertatik bertara irits dadin. Hau da, kanpoaldera atera behar dugu. Hemen aukera desberdinak daude. Egin dezagun aukerarik errazena. Bezero bakoitzari sare bat gehituko diogu, hornitzailearen sarean baliozkoa izango dena eta ez du gainjarriko beste sare batzuekin. Sareak ere gurutza daitezke eta hornitzaile sarearen alboko VRF desberdinak begiratu. Sareko datuak bezero bakoitzaren izen-espazioan ere biziko dira. Hala ere, oraindik kanpo mundura aterako dira interfaze fisiko baten bidez (edo lotura, logikoagoa dena). Bezeroen trafikoa bereizteko, kanpora doan trafikoa bezeroari esleitutako VLAN etiketa batekin etiketatu beharko da.
Ondorioz, diagrama hau lortu dugu:
Arrazoizko galdera da zergatik ez egin atebideak konputazio-nodoetan bertan? Hau ez da arazo handia; gainera, bideratzaile banatua (DVR) pizten baduzu, honek funtzionatuko du. Eszenatoki honetan, aukerarik errazena aztertzen ari gara atebide zentralizatu batekin, lehenespenez Openstack-en erabiltzen dena. Karga handiko funtzioetarako, bideratzaile banatua eta SR-IOV eta Passthrough bezalako azelerazio teknologiak erabiliko dituzte, baina esan bezala, guztiz bestelakoa da hori. Lehenik eta behin, jorratu dezagun oinarrizko zatia, eta gero xehetasunetan sartuko gara.
Egia esan, gure eskema dagoeneko egingarria da, baina Γ±abardura pare bat daude:
- Gure makinak nolabait babestu behar ditugu, hau da, iragazki bat jarri switch interfazean bezeroari.
- Eman posible makina birtual batek IP helbide bat automatikoki lor dezan, kontsolaren bidez saioa hasi eta helbidea erregistratu beharrik izan ez dezazun bakoitzean.
Has gaitezen makinen babesarekin. Horretarako iptables hutsalak erabil ditzakezu, zergatik ez.
Hau da, orain gure topologia pixka bat konplikatu egin da:
Goazen aurrera. DHCP zerbitzari bat gehitu behar dugu. Bezero bakoitzarentzat DHCP zerbitzariak kokatzeko lekurik aproposena lehen aipatutako kontrol-nodoa izango litzateke, non izen-espazioak dauden:
Hala ere, arazo txiki bat dago. Zer gertatzen da dena berrabiarazi eta DHCP-n helbideen alokairuari buruzko informazio guztia desagertzen bada. Logikoa da makinei helbide berriak ematea, eta hori ez da oso erosoa. Hemen bi bide daude: domeinu-izenak erabili eta bezero bakoitzarentzat DNS zerbitzari bat gehitu, gero helbidea ez da guretzat bereziki garrantzitsua izango (k8s-en sareko zatiaren antzekoa) - baina kanpoko sareekin arazo bat dago, izan ere. helbideak DHCP bidez ere igor daitezke haietan - hodeiko plataformako DNS zerbitzariekin sinkronizatu behar duzu eta kanpoko DNS zerbitzari batekin, nire ustez oso malgua ez dena, baina nahiko posiblea da. Edo bigarren aukera metadatuak erabiltzea da, hau da, makinari emandako helbideari buruzko informazioa gordetzea, DHCP zerbitzariak jakin dezan zein helbide igorri behar dion makinari, makinak dagoeneko helbide bat jaso badu. Bigarren aukera sinpleagoa eta malguagoa da, autoari buruzko informazio gehigarria gordetzeko aukera ematen baitu. Orain gehi ditzagun agente metadatuak diagramari:
Eztabaidatu beharreko beste gai bat bezero guztiek kanpoko sare bat erabiltzeko gaitasuna da, kanpoko sareak, sare osoan baliozkoak izan behar badira, zailak izango baitira - etengabe esleitu eta kontrolatu behar duzu sare horien esleipena. Bezero guztientzat kanpoko aurrez konfiguratutako sare bakarra erabiltzeko gaitasuna oso erabilgarria izango da hodei publiko bat sortzeko orduan. Honek makinak hedatzea erraztuko du, ez baitugu helbide-datu-base bat kontsultatu eta bezero bakoitzaren kanpoko sarerako helbide-espazio bakarra hautatu beharrik. Gainera, aldez aurretik kanpoko sare bat erregistratu dezakegu eta zabaltzeko unean kanpoko helbideak bezero-makinekin lotu beharko ditugu soilik.
Eta hemen NAT gure laguntzara dator - bezeroei kanpoko mundura sartzeko aukera emango diegu izen-espazio lehenetsiaren bidez NAT itzulpena erabiliz. Beno, hona hemen arazo txiki bat. Hau ona da bezero-zerbitzariak bezero gisa jarduten badu eta ez zerbitzari gisa, hau da, konexioak abiarazten ditu onartu beharrean. Baina guretzat alderantziz izango da. Kasu honetan, helmugako NAT egin behar dugu, trafikoa jasotzean, kontrol-nodoak uler dezan trafiko hori A bezeroaren A makina birtualerako pentsatuta dagoela, hau da, NAT itzulpen bat egin behar dugu kanpoko helbide batetik, adibidez 100.1.1.1. .10.0.0.1, barne helbide batera 100. Kasu honetan, bezero guztiek sare bera erabiliko duten arren, barne isolamendua guztiz gordetzen da. Hau da, dNAT eta sNAT egin behar ditugu kontrol-nodoan. Helbide flotagarriekin edo kanpoko sareekin sare bakar bat erabiltzea, edo biak aldi berean, hodeira ekarri nahi duzunaren araberakoa da. Diagramari ez dizkiogu helbide flotagarriak gehituko, baina lehenago gehitutako kanpoko sareak utziko ditugu - bezero bakoitzak bere kanpoko sarea du (diagraman vlan 200 eta XNUMX gisa adierazten dira kanpoko interfazean).
Ondorioz, irtenbide interesgarri eta aldi berean ondo pentsatua jaso genuen, nolabaiteko malgutasuna duena baina oraindik akatsak jasateko mekanismorik ez duena.
Lehenik eta behin, kontrol-nodo bakarra dugu - bere hutsegiteak sistema guztien kolapsoa ekarriko du. Arazo hau konpontzeko, gutxienez 3 nodoko quoruma egin behar duzu. Gehi diezaiogun hau diagramari:
Jakina, nodo guztiak sinkronizatuta daude eta nodo aktibo bat irteten denean, beste nodo batek hartuko ditu bere ardurak.
Hurrengo arazoa makina birtualeko diskoak dira. Momentuz, hipervisoreetan gordetzen dira, eta hipervisorearekin arazoak izanez gero, datu guztiak galtzen ditugu, eta raid baten presentzia ez du lagunduko hemen diskoa ez galtzen badugu, zerbitzari osoa baizik. Horretarako, nolabaiteko biltegiratzeko frontend gisa funtzionatuko duen zerbitzu bat egin behar dugu. Nolako biltegiratzea izango den ez da bereziki garrantzitsua guretzat, baina gure datuak babestu beharko lituzke bai diskoaren, bai nodoaren eta, agian, armairu osoaren porrotetatik. Hainbat aukera daude hemen - Fibre Channel duten SAN sareak daude, noski, baina zintzoak izan gaitezen - FC iraganeko erlikia da dagoeneko - E1-en analogoa garraioan - bai, ados nago, oraindik erabiltzen da, baina hura gabe erabat ezinezkoa den lekuan bakarrik. Hori dela eta, ez nuke borondatez FC sare bat zabalduko 2020an, beste alternatiba interesgarriago batzuk daudela jakinda. Bakoitzak berea izan arren, egon daiteke FC bere muga guztiekin behar dugun guztia dela uste dutenak - ez dut argudiatuko, bakoitzak bere iritzia du. Hala ere, nire ustez irtenbiderik interesgarriena SDS bat erabiltzea da, Ceph adibidez.
Ceph-ek datu-biltegiratze-soluzio oso erabilgarri bat eraikitzeko aukera ematen du babeskopia-aukera posible ugarirekin, parekotasun egiaztapena duten kodeetatik hasita (raid 5 edo 6aren antzekoa) eta datuen erreplika osoa disko ezberdinetan amaituz, diskoen kokapena kontuan hartuta. zerbitzariak, eta zerbitzariak armairuetan, etab.
Ceph eraikitzeko 3 nodo gehiago behar dituzu. Biltegiarekiko interakzioa sarearen bidez ere egingo da bloke, objektu eta fitxategiak biltegiratzeko zerbitzuak erabiliz. Gehi diezaiogun biltegiratzea eskemari:
Oharra: konputazio-nodo hiperkonbergetuak ere egin ditzakezu -hau da hainbat funtzio konbinatzeko kontzeptua nodo batean -adibidez, biltegiratzea+konputazioa-, nodo berezirik eskaini gabe ceph biltegiratzerako. Akatsekiko tolerantzia-eskema bera lortuko dugu; izan ere, SDS-k datuak erreserbatuko ditu guk zehaztutako erreserba-mailarekin. Hala ere, nodo hiperkonbergetuak beti dira konpromisoa - biltegiratze-nodoak lehen begiratuan dirudienez airea berotzen ez duenez (makina birtualrik ez dagoenez) - CPU baliabideak gastatzen ditu SDS zerbitzuan (izan ere, guztia egiten du). nodoen, diskoen eta abarren hutsegiteen ondoren erreplikatzea eta berreskuratzea). Hau da, konputazio-nodo baten ahalmenaren zati bat galduko duzu biltegiratzearekin konbinatzen baduzu.
Gauza hauek guztiak nolabait kudeatu behar dira - makina bat, sare bat, bideratzaile birtual bat, etab sor ditzakegun zerbait behar dugu. Horretarako, aginte-panel gisa funtzionatuko duen kontrol-nodoan zerbitzu bat gehituko dugu - bezeroak http/ https bidez atari honetara konektatu eta behar duen guztia egin ahal izango du (beno, ia).
Ondorioz, akatsen aurrean sistema bat dugu orain. Azpiegitura honen elementu guztiak nolabait kudeatu behar dira. Aurretik deskribatu zen Openstack proiektu multzo bat dela, eta horietako bakoitzak funtzio zehatz bat eskaintzen du. Ikusten dugunez, konfiguratu eta kontrolatu beharreko elementuak baino gehiago daude. Gaur sarearen zatiari buruz hitz egingo dugu.
Neutroien arkitektura
OpenStack-en, Neutron da makina birtualeko atakak L2 sare komun batera konektatzeaz arduratzen dena, L2 sare ezberdinetan kokatutako VM-en arteko trafiko-bideraketa bermatuz, baita kanporako bideratzeaz, NAT, Floating IP, DHCP eta abar bezalako zerbitzuak eskainiz.
Maila altuan, sareko zerbitzuaren funtzionamendua (oinarrizko zatia) honela deskriba daiteke.
VM abiaraztean, sareko zerbitzua:
- VM (edo ataka) jakin baterako ataka bat sortzen du eta DHCP zerbitzuari horren berri ematen dio;
- Sare birtual gailu berri bat sortzen da (libvirt bidez);
- VM 1. urratsean sortutako ataka(k) konektatzen da;
Bitxia bada ere, Neutronen lana Linux-en murgildu diren guztientzat ezagunak diren mekanismo estandarretan oinarritzen da - namespaces, iptables, linux bridges, openvswitch, conntrack, etab.
Berehala argitu behar da Neutron ez dela SDN kontroladore bat.
Neutroiak elkarri lotuta dauden hainbat osagaiz osatuta dago:
Openstack-neutroi-zerbitzaria APIaren bidez erabiltzaileen eskaerekin lan egiten duen deabru bat da. Deabru honek ez du sareko konexiorik erregistratzen parte hartzen, baina horretarako beharrezkoa den informazioa ematen die bere pluginei, gero nahi den sareko elementua konfiguratzen dutenak. OpenStack-eko nodoetako neutroi agenteak Neutron zerbitzarian erregistratzen dira.
Neutron-server python-en idatzitako aplikazio bat da, bi zatiz osatua:
- REST zerbitzua
- Neutron Plugin (nukleoa/zerbitzua)
REST zerbitzua beste osagai batzuen API deiak jasotzeko diseinatuta dago (adibidez, informazio batzuk emateko eskaera bat, etab.)
Plugin-ak API-eskaeretan deitzen diren software osagai/moduluak dira, hau da, zerbitzu baten atribuzioa haien bidez gertatzen da. Pluginak bi motatan banatzen dira: zerbitzua eta root. Oro har, zaldi-pluginak VM-en arteko helbide-espazioa eta L2 konexioak kudeatzeaz arduratzen da nagusiki, eta zerbitzu-pluginek dagoeneko funtzionalitate gehigarriak eskaintzen dituzte, hala nola VPN edo FW.
Gaur egun eskuragarri dauden pluginen zerrenda ikus daiteke adibidez
Hainbat zerbitzu-plugin egon daitezke, baina zaldi-plugin bakarra egon daiteke.
openstack-neutron-ml2 Openstack root plugin estandarra da. Plugin honek arkitektura modularra du (aurrekoak ez bezala) eta sare-zerbitzua hari konektatutako kontrolatzaileen bidez konfiguratzen du. Plugin bera geroago ikusiko dugu, izan ere, OpenStack-ek sareko zatian duen malgutasuna ematen baitu. Erroko plugina ordezkatu daiteke (adibidez, Contrail Networking-ek ordezkapen hori egiten du).
RPC zerbitzua (rabbitmq-server) β ilarak kudeatzea eta beste OpenStack zerbitzu batzuekin elkarrekintza eskaintzen duen zerbitzua, baita sareko zerbitzu-agenteen arteko elkarrekintza ere.
Sareko eragileak β nodo bakoitzean kokatzen diren agenteak, zeinen bidez sareko zerbitzuak konfiguratzen diren.
Hainbat eragile mota daude.
Agente nagusia da L2 agentea. Agente hauek hipervisore bakoitzean exekutatzen dira, kontrol-nodoak barne (zehatzago esanda, maizterentzako edozein zerbitzu eskaintzen duten nodo guztietan) eta haien funtzio nagusia makina birtualak L2 sare komun batera konektatzea da, eta gertaeraren bat gertatzen denean alertak sortzea ere ( adibidez, ataka desgaitu/gaitu).
Hurrengo agentea, ez da hain garrantzitsua L3 agentea. Lehenespenez, agente hau sare-nodo batean bakarrik exekutatzen da (askotan sare-nodoa kontrol-nodo batekin konbinatzen da) eta maizter-sareen arteko bideratzea eskaintzen du (bere sareen eta beste maizterren sareen artean, eta kanpoko munduarentzat eskuragarria da, NAT, baita DHCP zerbitzua ere). Hala ere, DVR (banatutako bideratzailea) erabiltzean, L3 plugin baten beharra ere agertzen da konputazio-nodoetan.
L3 agenteak Linux izen-espazioak erabiltzen ditu maizter bakoitzari bere sare isolatuen multzoa eta trafikoa bideratzen duten eta 2. geruzako sareetarako atebide zerbitzuak eskaintzen dituzten bideratzaile birtualen funtzionaltasuna eskaintzeko.
Datu-basea β sareen, azpisareen, ataken, igerilekuen eta abarren identifikatzaileen datu-basea.
Izan ere, Neutronek sareko edozein entitateren sorreratik API eskaerak onartzen ditu, eskaera autentifikatzen du eta RPC bidez (plugin edo agenteren batean sartzen bada) edo REST APIaren bidez (SDNn komunikatzen bada) agenteei transmititzen die (plugin bidez) eskatutako zerbitzua antolatzeko beharrezkoak diren argibideak.
Orain probako instalaziora jo dezagun (nola zabaltzen den eta bertan zer sartzen den, geroago ikusiko dugu zati praktikoan) eta ikus dezagun non dagoen osagai bakoitza:
(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 ~]$
Egia esan, hori da Neutroiaren egitura osoa. Orain merezi du denbora pixka bat ematea ML2 pluginean.
2. geruza modularra
Goian esan bezala, plugina OpenStack root plugin estandarra da eta arkitektura modularra du.
ML2 pluginaren aurrekoak egitura monolitikoa zuen, eta horrek ez zuen baimentzen, adibidez, hainbat teknologiaren nahasketa instalazio batean erabiltzea. Esate baterako, ezin zenituzke biak openvswitch eta linuxbridge erabili aldi berean - ez lehenengoa ez bigarrena. Hori dela eta, ML2 plugina bere arkitekturarekin sortu zen.
ML2-k bi osagai ditu: bi kontrolatzaile mota: Mota kontrolatzaileak eta Mekanismoaren kontrolatzaileak.
Mota kontrolatzaileak zehaztu sareko konexioak antolatzeko erabiliko diren teknologiak, adibidez VxLAN, VLAN, GRE. Aldi berean, gidariak teknologia desberdinak erabiltzeko aukera ematen du. Teknologia estandarra VxLAN kapsulatzea da gainjarri sareetarako eta vlan kanpoko sareetarako.
Mota kontrolatzaileek sare mota hauek barne hartzen dituzte:
Flat - sarea etiketarik gabe
VLANak - etiketatutako sarea
Tokiko β Sare mota berezi bat bakarreko instalazioetarako (instalazio horiek beharrezkoak dira garatzaileentzat edo prestakuntzarako)
GRE β gainjarri sarea GRE tunelak erabiliz
VxLAN β gainjarri sarea VxLAN tunelak erabiliz
Mekanismoen gidariak Mota kontrolatzailean zehaztutako teknologien antolaketa ziurtatzen duten tresnak definitu - adibidez, openvswitch, sr-iov, opendaylight, OVN, etab.
Gidari honen ezarpenaren arabera, edo Neutronek kontrolatutako agenteak erabiliko dira, edo kanpoko SDN kontrolagailu baterako konexioak erabiliko dira, L2 sareak antolatzearekin, bideratzearekin, etab.
Adibidea: OVSrekin batera ML2 erabiltzen badugu, OVS kudeatzen duen nodo informatiko bakoitzean L2 agente bat instalatuko da. Hala ere, adibidez, OVN edo OpenDayLight erabiltzen baditugu, orduan OVSren kontrola haien eskumenean dago - Neutronek, root pluginaren bidez, komandoak ematen dizkio kontrolatzaileari, eta dagoeneko esandakoa egiten du.
Ikus dezagun Open vSwitch-en
Momentuz, OpenStack-en osagai nagusietako bat Open vSwitch da.
OpenStack SDN gehigarririk gabe instalatzen denean, hala nola Juniper Contrail edo Nokia Nuage, OVS hodeiko sareko sareko osagai nagusia da eta, iptables, conntrack, namespaces-ekin batera, maizterreko gainjartze sare osoak antolatzeko aukera ematen du. Jakina, osagai hau ordezkatu daiteke, adibidez, hirugarrenen jabedun (saltzaileak) SDN soluzioak erabiltzen dituzunean.
OVS kode irekiko software etengailua da, ingurune birtualizatuetan erabiltzeko diseinatuta dagoen trafiko birbidaltzaile birtual gisa.
Momentuz, OVS-k funtzionalitate oso duinak ditu, QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, etab.
Oharra: OVS ez zen hasiera batean karga handiko telekomunikazio-funtzioetarako etengailu leun gisa pentsatu eta banda zabalera gutxiago eskatzen duten IT funtzioetarako diseinatu zen, hala nola WEB zerbitzaria edo posta zerbitzaria. Hala ere, OVS gehiago garatzen ari da eta OVSren egungo inplementazioek bere errendimendua eta gaitasunak asko hobetu dituzte, eta horri esker, karga handiko funtzioak dituzten telekomunikazio-operadoreek erabil dezakete, adibidez, DPDK azeleraziorako euskarria duen OVS inplementazio bat dago.
OVSren hiru osagai garrantzitsuak ezagutu behar dituzu:
- Kernel modulua β kontrol-elementutik jasotako arauetan oinarritutako trafikoa prozesatzen duen nukleoaren espazioan kokatutako osagaia;
- vAldatu daemon (ovs-vswitchd) kernel modulua programatzeaz arduratzen den erabiltzailearen espazioan abiarazitako prozesu bat da, hau da, etengailuaren funtzionamenduaren logika zuzenean adierazten du.
- Datu base zerbitzaria - OVS exekutatzen ari den ostalari bakoitzean kokatutako datu-base lokal bat, non konfigurazioa gordetzen den. SDN kontrolagailuak modulu honen bidez komunikatu daitezke OVSDB protokoloa erabiliz.
Hau guztia diagnostiko- eta kudeaketa-erabilgarritasun multzo batekin batera dator, hala nola ovs-vsctl, ovs-appctl, ovs-ofctl, etab.
Gaur egun, Openstack oso erabilia da telekomunikazio-operadoreek sareko funtzioak bertara migratzeko, hala nola EPC, SBC, HLR, etab. Funtzio batzuk OVSrekin arazorik gabe bizi daitezke den bezala, baina, adibidez, EPCk harpidedunen trafikoa prozesatzen du - gero pasatzen da. trafiko-kopuru handia (orain trafiko-bolumena segundoko ehunka gigabitetara iristen da). Jakina, trafiko hori kernel-espaziotik gidatzea (bere bidaltzailea lehenespenez bertan kokatzen baita) ez da ideiarik onena. Hori dela eta, OVS sarritan guztiz zabaltzen da erabiltzaile-espazioan DPDK azelerazio-teknologia erabiliz trafikoa NICtik erabiltzaile-espaziora birbidaltzeko nukleoa saihestuz.
Oharra: telekomunikazio-funtzioetarako zabaldutako hodei baterako, posible da trafikoa ateratzea konputazio-nodo batetik OVS zuzenean saihestuz ekipoa aldatzeko. SR-IOV eta Passthrough mekanismoak erabiltzen dira horretarako.
Nola funtzionatzen du hau benetako diseinu batean?
Tira, orain pasa gaitezen zati praktikora eta ikus dezagun nola funtzionatzen duen praktikan.
Lehenik eta behin, zabaldu dezagun Openstack instalazio sinple bat. Esperimentuetarako zerbitzari multzo bat eskura ez daukadanez, prototipoa zerbitzari fisiko batean muntatuko dugu makina birtualetatik. Bai, jakina, irtenbide hori ez da helburu komertzialetarako egokia, baina sareak Openstack-en funtzionatzen duen adibide bat ikusteko, horrelako instalazio bat nahikoa da begietarako. Gainera, instalazio hori are interesgarriagoa da prestakuntza helburuetarako - trafikoa harrapatzeko, etab.
Oinarrizko zatia bakarrik ikusi behar dugunez, ezin ditugu hainbat sare erabili, baina dena igo bi sare bakarrik erabiliz, eta diseinu honetako bigarren sarea esklusiboki undercloud eta DNS zerbitzarirako sarbidea izateko erabiliko da. Oraingoz ez ditugu kanpoko sareak ukituko - artikulu handi baten gaia da hau.
Beraz, has gaitezen ordenan. Lehenik eta behin, teoria txiki bat. Openstack TripleO erabiliz instalatuko dugu (Openstack Openstack-en). TripleO-ren funtsa da Openstack all-in-one (hau da, nodo batean) instalatzen dugula, undercloud izenekoa, eta gero inplementatutako Openstack-aren gaitasunak erabiltzea funtzionatzeko pentsatutako Openstack instalatzeko, overcloud izenekoa. Undercloud-ek zerbitzari fisikoak (barre metal) kudeatzeko berezko gaitasuna erabiliko du -Ironic proiektua- konputazio, kontrol eta biltegiratze nodoen rolak beteko dituzten hiperbistoreak hornitzeko. Hau da, ez dugu hirugarrenen tresnarik erabiltzen Openstack zabaltzeko; Openstack zabaltzen dugu Openstack erabiliz. Instalazioa aurrera egin ahala askoz argiago geratuko da, beraz, ez gara hor geldituko eta aurrera egingo.
Oharra: Artikulu honetan, sinpletasunaren mesedetan, ez dut sarearen isolamendua erabili Openstack barneko sareetarako, baina dena sare bakarra erabiliz zabaltzen da. Hala ere, sarearen isolamenduaren presentzia edo ez egoteak ez du konponbidearen oinarrizko funtzionalitatean eragiten - dena isolamendua erabiltzean bezala funtzionatuko du, baina trafikoa sare berean joango da. Instalazio komertzial baterako, beharrezkoa da isolamendua erabiltzea vlan eta interfaze desberdinak erabiliz. Esaterako, ceph biltegiratze-kudeaketako trafikoak eta datu-trafikoak berak (makinen diskoetarako sarbidea, etab.) isolatuta daudenean azpisare desberdinak erabiltzen dituzte (Biltegiratze-kudeaketa eta Biltegiratzea) eta honek irtenbidea akatsekiko tolerantzia handiagoa izatea ahalbidetzen du trafiko hori zatituz, adibidez. , portu ezberdinetan edo QoS profil desberdinak erabiliz trafiko desberdinetarako, datu-trafikoak seinaleztapen-trafikoa estutu ez dezan. Gure kasuan, sare berean joango dira eta egia esan horrek ez gaitu inola ere mugatzen.
Oharra: makina birtualak makina birtualetan oinarritutako ingurune birtualean exekutatuko ditugunez, lehenik eta behin birtualizazio habiatua gaitu behar dugu.
Habiaraturiko birtualizazioa gaituta dagoen edo ez egiazta dezakezu honela:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#N hizkia ikusten baduzu, habiaraturiko birtualizaziorako euskarria gaituko dugu sarean aurkitzen duzun gidaren arabera, adibidez. .
Makina birtualetatik honako zirkuitu hau muntatu behar dugu:
Nire kasuan, etorkizuneko instalazioaren parte diren makina birtualak konektatzeko (eta 7 lortu ditut, baina baliabide asko ez badituzu 4rekin atera zaitezke), OpenvSwitch erabili dut. Ovs zubi bat sortu nuen eta makina birtualak konektatu nituen portu-taldeen bidez. Horretarako, honelako xml fitxategi bat sortu dut:
[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>Hiru ataka-talde deklaratzen dira hemen: bi sarbide eta enbor bat (azken hau DNS zerbitzarirako behar zen, baina gabe egin dezakezu edo makinan instalatu - zuretzako erosoena dena). Ondoren, txantiloi hau erabiliz, gurea deklaratzen dugu virsh net-define bidez:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Orain hipervisorearen atakaren konfigurazioak editatzen ditugu:
[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 ~]# Oharra: agertoki honetan, ovs-br1 atakako helbidea ez da eskuragarri izango vlan etiketarik ez duelako. Hau konpontzeko, sudo ovs-vsctl set port ovs-br1 tag=100 komandoa eman behar duzu. Hala ere, berrabiarazi ondoren, etiketa hau desagertu egingo da (norbaitek bere lekuan nola egin behar duen badaki, asko eskertuko dut). Baina hori ez da hain garrantzitsua, instalazioan zehar helbide hau bakarrik beharko dugulako eta ez baitugu beharko Openstack guztiz zabalduta dagoenean.
Ondoren, hodei azpiko makina bat sortuko dugu:
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=ttyS0Instalazioan zehar, beharrezkoak diren parametro guztiak ezarri dituzu, hala nola, makinaren izena, pasahitzak, erabiltzaileak, ntp zerbitzariak, etab., berehala portuak konfigura ditzakezu, baina niri pertsonalki, instalazioaren ondoren, errazagoa da makinan saioa hastea. kontsola eta zuzendu behar diren fitxategiak. Dagoeneko prest egindako irudi bat baduzu, erabil dezakezu edo egin dudana egin - deskargatu gutxieneko Centos 7 irudia eta erabili VM instalatzeko.
Instalazio arrakastatsuaren ondoren, makina birtual bat izan beharko zenuke, hodei azpian instalatu ahal izateko
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningLehenik eta behin, instalatu instalazio-prozesurako beharrezkoak diren tresnak:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud instalazioa
Erabiltzaile pila bat sortzen dugu, pasahitz bat ezartzen dugu, sudoer-era gehitzen dugu eta sudo bidez root komandoak exekutatzeko gaitasuna ematen diogu pasahitz bat sartu beharrik gabe:
useradd stack
passwd stack
echo βstack ALL=(root) NOPASSWD:ALLβ > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackOrain hodeiaren izen osoa zehazten dugu hosts fitxategian:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Ondoren, biltegiak gehitu eta behar dugun softwarea instalatuko dugu:
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-ansibleOharra: ceph instalatzeko asmoa ez baduzu, ez duzu zertan ceph-ekin lotutako komandoak sartu behar. Queens bertsioa erabili nuen, baina nahi duzun beste edozein erabil dezakezu.
Ondoren, kopiatu hodei azpiko konfigurazio fitxategia erabiltzailearen etxeko direktorio pilara:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confOrain fitxategi hau zuzendu behar dugu, gure instalaziora egokituz.
Lerro hauek gehitu behar dituzu fitxategiaren hasieran:
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 = 10Beraz, joan gaitezen ezarpenak:
undercloud_hostname β undercloud zerbitzariaren izen osoa, DNS zerbitzariko sarrerarekin bat etorri behar du
local_ip β tokiko hodeiko helbidea sare hornikuntzarako
sare_pasabidea β Overcloud nodoak instalatzean kanpoko mundura sartzeko atebide gisa funtzionatuko duen tokiko helbide bera ere tokiko iparekin bat dator.
undercloud_public_host β kanpoko API helbidea, hornikuntza-sarearen doako edozein helbide esleitzen da
undercloud_admin_host barneko API helbidea, hornikuntza-saretik doan edozein helbide esleitzen da
undercloud_nameservers - DNS zerbitzaria
sortu_zerbitzu_ziurtagiria - lerro hau oso garrantzitsua da uneko adibidean, izan ere, ez baduzu faltsu gisa ezartzen, errore bat jasoko duzu instalazioan, arazoa Red Hat akatsen jarraitzailean deskribatzen da.
tokiko_interfazea sare hornikuntzan interfazea. Interfaze hau birkonfiguratuko da hodei azpiko inplementazioan; beraz, bi interfaze izan behar dituzu hodeian: bata sartzeko, bigarrena hornitzeko.
tokiko_mtu - MTU. Proba laborategi bat daukagunez eta OVS switch-eko portuetan 1500eko MTU dudanez, beharrezkoa da 1450ean ezartzea, VxLAN-en kapsulatutako paketeak igaro daitezen.
sare_cidr β Hornidura-sarea
maskarada β NAT erabiliz kanpoko sare batera sartzeko
maskarada_sarea - NATed izango den sarea
dhcp_hasiera β Overcloud inplementatzean nodoei helbideak esleituko zaizkien helbide multzoaren hasierako helbidea
dhcp_end β Overcloud inplementatzean nodoei helbideak esleituko zaizkien helbide multzoaren azken helbidea
ikuskapen_iprange β Introspekziorako beharrezkoak diren helbide multzoa (ez luke goiko multzoarekin gainjarri behar)
scheduler_max_tempts β Overcloud instalatzeko gehieneko saiakera kopurua (nodo kopurua baino handiagoa edo berdina izan behar du)
Fitxategia deskribatu ondoren, azpiko hodeia zabaltzeko komandoa eman dezakezu:
openstack undercloud install
Prozedurak 10 eta 30 minutu behar ditu zure plantxaren arabera. Azken finean, honelako irteera ikusi beharko zenuke:
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.
#############################################################################Irteera honek undercloud behar bezala instalatu duzula dio eta orain undercloud-en egoera egiaztatu dezakezula eta overcloud instalatzen jarraitu.
Ifconfig irteerara begiratzen baduzu, zubi-interfaze berri bat agertu dela ikusiko duzu
[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 0Overcloud inplementazioa interfaze honen bidez egingo da.
Beheko irteeratik zerbitzu guztiak nodo batean ditugula ikus dezakezu:
(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 |
+--------------------------+-----------+----------+Jarraian azpiko sarearen zatiaren konfigurazioa dago:
(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 ~]$Overcloud instalazioa
Momentuz undercloud baino ez dugu, eta ez dugu overcloud muntatuko duten nodo nahikorik. Horregatik, lehenik eta behin, heda ditzagun behar ditugun makina birtualak. Inplementazioan zehar, undercloud-ek berak OS eta beharrezko softwarea instalatuko ditu overcloud makinan - hau da, ez dugu makina guztiz zabaldu behar, baizik eta disko bat (edo diskoak) sortu eta bere parametroak zehaztu behar ditugu - hau da. Izan ere, OS instalatu gabe zerbitzari huts bat lortzen dugu.
Goazen gure makina birtualen diskoak dituen karpetara eta sortu behar den tamainako diskoak:
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 160GRoot gisa ari garenez, disko hauen jabea aldatu behar dugu eskubideekin arazorik ez izateko:
[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]# Oharra: ez baduzu ceph instalatu asmorik aztertzeko, komandoek ez dituzte gutxienez 3 nodo sortzen gutxienez bi diskorekin, baina txantiloian adierazi vda, vdb, etab. disko birtualak erabiliko direla.
Bikaina, orain makina hauek guztiak definitu behar ditugu:
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 Bukaeran -print-xml > /tmp/storage-1.xml komando bat dago, makina bakoitzaren deskribapenarekin /tmp/ karpetan xml fitxategi bat sortzen duena; gehitzen ez baduzu, ez zara egongo makina birtualak identifikatzeko gai.
Orain makina hauek guztiak virsh-en definitu behar ditugu:
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 ~]#Orain Γ±abardura txiki bat - tripleO-k IPMI erabiltzen du zerbitzariak kudeatzeko instalazioan eta introspekzioan.
Introspekzioa hardwarea ikuskatzeko prozesua da, nodoak gehiago hornitzeko beharrezkoak diren parametroak lortzeko. Introspekzioa ironikoa erabiliz egiten da, bare metal zerbitzariekin lan egiteko diseinatutako zerbitzua.
Baina hona hemen arazoa - hardware IPMI zerbitzariek portu bereizi bat duten arren (edo partekatutako ataka bat, baina hori ez da garrantzitsua), orduan makina birtualek ez dute horrelako atakarik. Hemen vbmc izeneko makulu bat datorkigu laguntza - IPMI ataka bat emulatzeko aukera ematen duen erabilgarritasuna. Γabardura honi arreta jartzea merezi du bereziki laborategi bat ESXI hipervisorean ezarri nahi dutenentzat - egia esan, ez dakit vbmc-ren analogikorik duen, beraz, merezi du arazo honi buruz galdetzea dena zabaldu aurretik. .
Instalatu vbmc:
yum install yum install python2-virtualbmcZure sistema eragileak ezin badu paketea aurkitzen, gehitu biltegia:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmOrain utilitatea konfiguratu dugu. Hemen dena hutsala da lotsagarriraino. Orain logikoa da vbmc zerrendan zerbitzaririk ez egotea
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Horiek ager daitezen, eskuz honela deklaratu behar dira:
[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 ~]#Uste dut komandoaren sintaxia argia dela azalpenik gabe. Hala ere, oraingoz gure saio guztiak BEHERA egoeran daude. GORA egoerara pasatzeko, gaitu behar dituzu:
[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 ~]#Eta azken ukitua - suebakiaren arauak zuzendu behar dituzu (edo guztiz desgaitu):
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
Orain joan gaitezen hodeietara eta egiaztatu dena funtzionatzen ari dela. Ostalari-makinaren helbidea 192.168.255.200 da, undercloud-en beharrezko ipmitool paketea gehitu genuen hedapenerako prestatzerakoan:
[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 runningIkus dezakezunez, kontrol-nodoa arrakastaz abiarazi dugu vbmc bidez. Orain itzali eta aurrera egin dezagun:
[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 ~]#Hurrengo urratsa overcloud instalatuko den nodoen introspekzioa da. Horretarako, json fitxategi bat prestatu behar dugu gure nodoen deskribapenarekin. Kontuan izan, zerbitzari hutsetan instalatzea ez bezala, fitxategiak makina bakoitzerako vbmc zein atakatan exekutatzen ari den adierazten duela.
[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:27Oharra: kontrol-nodoak bi interfaze ditu, baina kasu honetan ez da garrantzitsua, instalazio honetan bat nahikoa izango zaigu.
Orain json fitxategia prestatzen dugu. Horniketa-zerbitzua egingo den portuaren amatxo-helbidea, nodoen parametroak, izenak eman eta ipmira nola iritsi adierazi behar dugu:
{
"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"
}
]
}Orain ironikorako irudiak prestatu behar ditugu. Horretarako, deskargatu wget bidez eta instalatu:
(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 ~]$Irudiak hodeian kargatzen:
(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 ~]$Irudi guztiak kargatu direla egiaztatzea
(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 ~]$Beste gauza bat - DNS zerbitzari bat gehitu behar duzu:
(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 ~]$Orain introspekziorako agindua eman dezakegu:
(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 ~]$Irteeran ikus dezakezun bezala, dena akatsik gabe osatu da. Egiaztatu dezagun nodo guztiak eskuragarri dauden egoeran daudela:
(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 ~]$ Nodoak beste egoera batean badaude, normalean kudeagarriak direnean, zerbait gaizki joan da eta erregistroa begiratu eta zergatik gertatu den jakin behar duzu. Kontuan izan agertoki honetan birtualizazioa erabiltzen ari garela eta makina birtualen edo vbmc erabiltzearekin lotutako akatsak egon daitezkeela.
Ondoren, zein nodok zein funtzio beteko duen adierazi behar dugu, hau da, nodoak zein profil erabiliko duen adierazi:
(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 ~]$Zehaztu nodo bakoitzaren profila:
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-d9afb69d1167Egiazta dezagun dena ondo egin dugula:
(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 ~]$Dena zuzena bada, overcloud zabaltzeko komandoa ematen dugu:
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 qemuBenetako instalazio batean pertsonalizatutako txantiloiak erabiliko dira naturalki, gure kasuan horrek asko zailduko du prozesua, txantiloiaren edizio bakoitza azaldu beharko baita. Lehen idatzi zen bezala, instalazio soil bat ere nahikoa izango da nola funtzionatzen duen ikusteko.
Oharra: --libvirt-type qemu aldagaia beharrezkoa da kasu honetan, birtualizazio habiatua erabiliko baitugu. Bestela, ezin izango dituzu makina birtualak exekutatu.
Orain ordubete inguru duzu, edo agian gehiago (hardwarearen gaitasunen arabera) eta denbora hori igaro ondoren mezu hau ikusiko duzula espero dezakezu:
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 ~]$Orain openstack-en bertsio ia osoa duzu, eta bertan aztertu, esperimentatu eta abar dezakezu.
Egiaztatu dezagun dena ondo funtzionatzen duela. Erabiltzailearen hasierako direktorio-pilean bi fitxategi daude: bat stackrc (undercloud kudeatzeko) eta bigarrena overcloudrc (overcloud kudeatzeko). Fitxategi hauek iturri gisa zehaztu behar dira, autentifikaziorako beharrezkoa den informazioa baitute.
(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 ~]$Nire instalazioak ukitu txiki bat behar du oraindik: kontrolagailuan ibilbide bat gehitzea, lan egiten dudan makina beste sare batean baitago. Horretarako, joan heat-admin kontuaren kontrola-1era eta erregistratu ibilbidea
(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.254Beno, orain horizontean sartu zaitezke. Informazio guztia - helbideak, saioa hasteko eta pasahitza - /home/stack/overcloudrc fitxategian dago. Azken diagrama itxura hau du:
Bide batez, gure instalazioan, makinen helbideak DHCP bidez igortzen ziren eta, ikusten duzuenez, "ausaz" ematen dira. Inplementazioan zehar zein helbideri erantsi behar zaion txantiloian zehatz dezakezu, behar izanez gero.
Nola gertatzen da trafikoa makina birtualen artean?
Artikulu honetan trafikoa pasatzeko hiru aukera aztertuko ditugu
- Bi makina hipervisor batean L2 sare batean
- Bi makina hipervisor desberdinetan L2 sare berean
- Bi makina sare ezberdinetan (sareen arteko errotzea)
Kanpoko sare baten bidez kanpoko mundura sarbidea duten kasuak, helbide flotagarriak erabiliz, baita bideratze banatua ere, hurrengoan kontuan hartuko ditugu, oraingoz barne trafikoan zentratuko gara.
Egiaztatzeko, bildu dezagun diagrama hau:
4 makina birtual sortu ditugu - 3 L2 sare batean - net-1, eta beste 1 net-2 sarean
(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 ~]$ Ikus dezagun zer hipervisoretan dauden sortutako makinak:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [pila @ undercloud ~]$
vm-1 eta vm-3 makinak compute-0-n daude, vm-2 eta vm-4 makinak compute-1 nodoan.
Horrez gain, bideratzaile birtual bat sortu da zehaztutako sareen arteko bideraketa gaitzeko:
(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 ~]$ Bideratzaileak bi ataka birtual ditu, sareetarako atebide gisa funtzionatzen dutenak:
(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 ~]$ Baina trafikoa nola gertatzen den ikusi baino lehen, ikus dezagun zer daukagun kontrol-nodoan (sare-nodoa ere bada) eta konputazio-nodoan. Has gaitezen konputazio-nodoarekin.
[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 ~]$Momentuz, nodoak hiru ovs zubi ditu - br-int, br-tun, br-ex. Bien artean, ikusten dugunez, interfaze multzo bat dago. Ulertzeko erraztasuna lortzeko, irudikatu ditzagun interfaze horiek guztiak diagraman eta ikus dezagun zer gertatzen den.
VxLAN tunelak altxatzen diren helbideei erreparatuz, ikus daiteke tunel bat konputazio-1era igotzen dela (192.168.255.26), bigarren tunelak kontrola-1 (192.168.255.15). Baina interesgarriena da br-ex-ek ez duela interfaze fisikorik, eta zer fluxu konfiguratuta dauden begiratuz gero, zubi honek momentuz trafikoa soilik jaitsi dezakeela ikusiko duzu.
[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 ~]$ Irteeran ikus dezakezun bezala, helbidea zuzenean ataka fisikora izorratzen da, eta ez zubi birtualeko interfazera.
[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 ~]$
Lehen arauaren arabera, phy-br-ex atakatik zetorren guztia baztertu behar da.
Egia esan, gaur egun ez dago trafikoa zubi honetara sartzeko beste inon interfaze honetatik (br-int-eko interfazea) izan ezik, eta tantak ikusita, BUM trafikoa zubian sartu da dagoeneko.
Hau da, trafikoa VxLAN tuneletik bakarrik irten daiteke nodo honetatik eta kito. Hala ere, DVR-a pizten baduzu, egoera aldatuko da, baina horri beste behin egingo diogu aurre. Sarearen isolamendua erabiltzean, adibidez vlanak erabiliz, ez duzu L3 interfaze bat izango 0 vlanean, hainbat interfaze baizik. Hala ere, VxLAN trafikoak nodotik irtengo da modu berean, baina vlan dedikatu moduko batean kapsulatutakoa ere bai.
Ordenatu dugu konputazio-nodoa, joan gaitezen kontrol-nodora.
[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 ~]$Izan ere, dena berdina dela esan dezakegu, baina IP helbidea jada ez dago interfaze fisikoan, zubi birtualean baizik. Hau egiten da portu hori trafikoa kanpotik aterako den portua delako.
[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 ~]$ Ataka hau br-ex zubiari lotuta dago eta bertan vlan etiketarik ez dagoenez, ataka hau vlan guztiak onartzen dituen enbor ataka da, orain trafikoa etiketarik gabe ateratzen da, vlan-id 0-k adierazten duen moduan. goiko irteera.
Une honetan beste guztia konputazio-nodoaren antzekoa da: zubi berdinak, tunel berdinak bi konputazio-nodotara doaz.
Artikulu honetan ez ditugu biltegiratze-nodoak kontuan hartuko, baina ulertzeko beharrezkoa da esan behar da nodo horien sarearen zatia hutsala dela lotsagarriraino. Gure kasuan, ataka fisiko bakarra (eth0) dago esleitutako IP helbide batekin eta kitto. Ez dago VxLAN tunelik, tunel zubirik, etab. - ez dago batere ovs, ez baitago punturik. Sarearen isolamendua erabiltzean, nodo honek bi interfaze izango ditu (portu fisikoak, bodny edo bi vlan besterik ez - ez du axola - nahi duzunaren araberakoa da) - bat kudeaketarako, bigarrena trafikorako (VM diskoan idaztea). , diskotik irakurtzea, etab.)
Zerbitzurik ezean nodoetan duguna asmatu dugu. Orain abiarazi ditzagun 4 makina birtual eta ikus ditzagun goian deskribatutako eskema nola aldatzen den - portuak, bideratzaile birtualak eta abar izan beharko genituzke.
Orain arte gure sarea honelakoa da:
Ordenagailu nodo bakoitzean bi makina birtual ditugu. Compute-0 adibide gisa erabiliz, ikus dezagun dena nola sartzen den.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Makinak interfaze birtual bakarra du - 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 ~]$
Interfaze honek linux zubian ikusten du:
[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 ~]$ Irteeran ikus dezakezun bezala, zubian bi interfaze baino ez daude: tap95d96a75-a0 eta qvb95d96a75-a0.
Hona hemen OpenStack-eko sare birtualeko gailu motetan pixka bat sakontzea:
vtap - instantzia bati (VM) erantsitako interfaze birtuala
qbr - Linux zubia
qvb eta qvo - vEth bikotea Linux zubiarekin eta Open vSwitch zubiarekin konektatuta
br-int, br-tun, br-vlan β Ireki vSwitch zubiak
patch-, int-br-, phy-br- - Ireki vSwitch adabaki-interfazeak zubiak konektatzeko
qg, qr, ha, fg, sg - Ireki gailu birtualek OVSra konektatzeko erabiltzen dituzten vSwitch portuak
Ulertzen duzunez, zubian qvb95d96a75-a0 ataka badugu, hau da, vEth bikotea, nonbait dago bere parekoa, logikoki qvo95d96a75-a0 deitu beharko litzatekeena. Ikus dezagun zer ataka dauden OVSn.
[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 ~]$ Ikus dezakegunez, portua br-int dago. Br-int-ek makina birtualeko atakak amaitzen dituen etengailu gisa jokatzen du. qvo95d96a75-a0-z gain, qvo5bd37136-47 ataka ikusgai dago irteeran. Hau bigarren makina birtualaren ataka da. Ondorioz, gure diagrama honen itxura du orain:
Irakurle arretatsua berehala interesatu beharko lukeen galdera bat - zein da makina birtualaren atakaren eta OVS atakaren arteko linux-zubia? Kontua da makina babesteko segurtasun taldeak erabiltzen direla, iptables baino ez direnak. OVS ez da iptables-ekin funtzionatzen, beraz, "makulu" hau asmatu zen. Hala ere, zaharkituta geratzen ari da - bertsio berrietan conntrack-ek ordezkatzen ari da.
Hau da, azken finean, eskemak honela dauka:
Bi makina hipervisor batean L2 sare batean
Bi VM hauek L2 sare berean eta hipervisor berean daudenez, haien arteko trafikoa logikoki br-int bidez joango da, bi makinak VLAN berean egongo baitira:
[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 ~]$ Bi makina hipervisor desberdinetan L2 sare berean
Ikus dezagun orain nola joango den trafikoa L2 sare bereko bi makinen artean, baina hipervisor desberdinetan kokatuta. Egia esateko, ez da ezer asko aldatuko, hipervisoren arteko trafikoa vxlan tuneletik igaroko da. Ikus dezagun adibide bat.
Trafikoa ikusiko dugun makina birtualen helbideak:
[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 ~]$ br-int-en birbidaltze-taula begiratuko dugu compute-0-n:
[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 ~]Trafikoak 2. portura joan behar du - ikus dezagun zer nolako portua den:
[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 ~]$Hau patch-tun da, hau da, br-tun-eko interfazea. Ikus dezagun zer gertatzen den br-tun paketearekin:
[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 ~]$ Paketea VxLAN-en paketatuta dago eta 2. atakara bidaliko da. Ikus dezagun 2 ataka nora doan:
[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 ~]$Hau vxlan tunel bat da compute-1-n:
[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 ~]$Goazen compute-1-era eta ikus dezagun zer gertatzen den paketearekin:
[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 br-int birbidaltze-taulan dago compute-1-en, eta goiko irteeran ikus daitekeen bezala, 2 atakatik ikusten da, hau da, br-tun aldera:
[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:46Beno, orduan ikusiko dugu br-int-en compute-1-en helmugako amatxo bat dagoela:
[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 ~]$ Hau da, jasotako paketea 3. atakara joango da, eta horren atzean dagoeneko makina birtualaren instantzia-00000003 dago.
Azpiegitura birtualean ikasteko Openstack hedatzearen edertasuna hiperbissoreen arteko trafikoa erraz har dezakegula da eta horrekin zer gertatzen den ikusi. Hau da orain egingo duguna, exekutatu tcpdump vnet atakan compute-0 aldera:
[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*******************Lehen lerroak erakusten du 10.0.1.85 helbidetik Patek 10.0.1.88 helbidera doala (ICMP trafikoa), eta vni 22 duen VxLAN pakete batean bilduta dagoela eta paketea 192.168.255.19 (konputatu-0) ostalaritik 192.168.255.26ra doa. .1 (konputatu-XNUMX). VNIa ovs-en zehaztutakoarekin bat datorrela egiaztatu dezakegu.
Itzul gaitezen lerro honetara actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 vni da zenbaki sistema hamaseimalean. Bihur dezagun zenbaki hau 16. sistemara:
16 = 6*16^0+1*16^1 = 6+16 = 22Hau da, vni errealitateari dagokio.
Bigarren lerroan itzulerako trafikoa agertzen da, ba, ez du balio azaltzeak, hor dena argi dago.
Bi makina sare ezberdinetan (sareen arteko bideratzea)
Gaurko azken kasua proiektu baten barruan sareen arteko bideratzea da bideratzaile birtual bat erabiliz. DVRrik gabeko kasu bat aztertzen ari gara (beste artikulu batean aztertuko dugu), beraz bideratzea sareko nodoan gertatzen da. Gure kasuan, sare-nodoa ez dago aparteko entitate batean jartzen eta kontrol-nodoan kokatzen da.
Lehenik eta behin, ikus dezagun bideratzeak funtzionatzen duela:
$ 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 msKasu honetan paketea atebidera joan behar denez eta bertara bideratu behar denez, atebidearen mitxoleta helbidea aurkitu behar dugu, eta horretarako ARP taula begiratuko dugu instantzian:
$ 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 eth0Orain ikus dezagun nora bidali behar den helmuga duen trafikoa (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 ~]$ Ikus dezagun 2. ataka nora doan:
[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 ~]$ Dena logikoa da, trafikoa br-tunera doa. Ikus dezagun zein vxlan tuneletan bilduko den:
[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 ~]$ Hirugarren ataka vxlan tunel bat da:
[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 ~]$ Kontrol-nodoari begiratzen diona:
[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 ~]$ Trafikoa kontrol-nodoraino iritsi da, beraz bertara joan eta bideratzea nola gertatuko den ikusi behar dugu.
Gogoratzen duzunez, barruko kontrol-nodoak konputazio-nodoaren itxura berdina zuen: hiru zubi berdinak, br-ex-ek bakarrik zuen ataka fisiko bat nodoak kanpora bidali ahal izateko. Instantziak sortzeak konputazio-nodoen konfigurazioa aldatu zuen - linux zubia, iptables eta interfazeak gehitu ziren nodoetara. Sareak eta bideratzaile birtual bat sortzeak ere arrastoa utzi zuen kontrol-nodoaren konfigurazioan.
Beraz, bistakoa da atebideko MAC helbideak kontrol-nodoko br-int birbidaltze-taulan egon behar duela. Egiazta dezagun hor dagoela eta non bilatzen ari den:
[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 qr-0c52b15f-8f atakatik ikusten da. Openstack-eko ataka birtualen zerrendara itzultzen bagara, ataka mota hau hainbat gailu birtual OVSra konektatzeko erabiltzen da. Zehatzago esateko, qr bideratzaile birtualerako ataka da, izen-espazio gisa irudikatzen dena.
Ikus dezagun zer izen-espazio dauden zerbitzarian:
[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 ~]$ Hiru ale bezainbeste. Baina izenak ikusita, horietako bakoitzaren helburua asma dezakezu. 0 eta 1 ID duten instantzietara itzuliko gara geroago, orain qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe izen-espazioa interesatzen zaigu:
[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 ~]$ Izen-espazio honek lehenago sortu ditugun bi barne ditu. Bi ataka birtualak gehitu dira br-int-era. Egiaztatu dezagun qr-0c52b15f-8f atakaren mac helbidea, trafikoa, helmugako mac helbidea ikusita, interfaze honetara joan zen.
[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 ~]$ Hau da, kasu honetan, dena bideratze estandarraren legeen arabera funtzionatzen du. Trafikoa 10.0.2.8 ostalarira zuzenduta dagoenez, bigarren interfazetik irten behar du qr-92fa49b5-54 eta vxlan tuneletik konputazio-nodoraino joan behar du:
[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 ~]$ Dena logikoa da, ezustekorik gabe. Ikus dezagun 10.0.2.8 ostalariaren mitxoleta helbidea non dagoen ikusgai br-int-en:
[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 ~]$ Espero bezala, trafikoa br-tunera doa, ikus dezagun zein tunelera doan trafikoa:
[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 ~]$ Trafikoa tunelera doa-1 konputatzera. Beno, compute-1-en dena erraza da - br-tun-etik paketea br-int-era doa eta handik makina birtualeko interfazera:
[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 ~]$ Egiaztatu dezagun hau interfaze zuzena dela:
[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 ~]$
Egia esan, pakete osoan zehar joan ginen. Uste dut konturatu zinela trafikoa vxlan tunel ezberdinetatik igaro eta VNI ezberdinekin irten zela. Ikus dezagun zer nolako VNI diren horiek, ondoren nodoaren kontrol-atarian iraulketa bat bilduko dugu eta trafikoa goian deskribatutako moduan zuzentzen dela ziurtatuko dugu.
Beraz, 0 kalkulatzeko tunelak ekintza hauek ditu=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Bihur ditzagun 0x16 zenbaki-sistema hamartarra:
0x16 = 6*16^0+1*16^1 = 6+16 = 221 kalkulatzeko tunelak VNI hauek ditu:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Bihur ditzagun 0x63 zenbaki-sistema hamartarra:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Tira, orain ikus dezagun zabortegia:
[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*******************Lehenengo paketea vxlan pakete bat da 192.168.255.19 ostalaritik (konputatu-0) ostalarira 192.168.255.15 (kontrol-1) vni 22rekin, zeinaren barruan ICMP pakete bat 10.0.1.85 ostalaritik 10.0.2.8 ostalarira paketatuta dagoen. Goian kalkulatu dugun bezala, vni irteeran ikusi dugunarekin bat dator.
Bigarren paketea vxlan pakete bat da 192.168.255.15 ostalaritik (kontrol-1) ostalarira 192.168.255.26 (konputatu-1) vni 99rekin, zeinaren barruan ICMP pakete bat 10.0.1.85 ostalaritik 10.0.2.8 ostalarira paketatuta dagoen. Goian kalkulatu dugun bezala, vni irteeran ikusi dugunarekin bat dator.
Hurrengo bi paketeak 10.0.2.8tik ez 10.0.1.85etik itzultzeko trafikoa dira.
Hau da, azkenean kontrol-nodoen eskema hau lortu dugu:
Itxura hori al da? Bi izen-espazio ahaztu ditugu:
[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 ~]$ Hodeiko plataformaren arkitekturari buruz hitz egin dugunez, ona litzateke makinek DHCP zerbitzari batetik helbideak automatikoki jasotzea. Hauek bi DHCP zerbitzari dira gure bi sareetarako 10.0.1.0/24 eta 10.0.2.0/24.
Egiaztatu dezagun hori egia dela. Izen-espazio honetan helbide bakarra dago - 10.0.1.1 - DHCP zerbitzariaren helbidea bera, eta br-int-en ere sartzen da:
[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 0Ikus dezagun qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 duten prozesuak kontrol-nodoan:
[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 ~]$ Halako prozesu bat dago eta goiko irteeran aurkeztutako informazioan oinarrituta, adibidez, gaur egun alokairuan duguna ikus dezakegu:
[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 ~]$Ondorioz, kontrol-nodoan honako zerbitzu multzo hauek lortuko ditugu:
Beno, kontuan izan - hau 4 makina besterik ez da, 2 barne sare eta bideratzaile birtual bat... Hemen ez dugu kanpoko sarerik orain, proiektu ezberdin mordoa, bakoitza bere sareekin (gainjarririk), eta badugu banatutako bideratzaile bat itzali zen, eta azken finean, proba-bankuan kontrol-nodo bakarra zegoen (hutsen tolerantziarako hiru nodoko quoruma egon behar da). Logikoa da merkataritzan dena "pixka bat" konplikatuagoa izatea, baina adibide sinple honetan ulertzen dugu nola funtzionatu behar duen - 3 edo 300 izen-espazio edukitzea garrantzitsua da noski, baina osoaren funtzionamenduaren ikuspuntutik. egitura, ezer ez da asko aldatuko... nahiz eta saltzaileen SDNren bat konektatuko ez duzun arte. Baina hori guztiz bestelako istorio bat da.
Espero dut interesgarria izan zela. Iruzkinak/gehikuntzak badituzu, edo nonbait gezurra esan nion (gizakia naiz eta nire iritzia beti subjektiboa izango da) - idatzi zuzendu/gehitu beharrekoa - dena zuzendu/gehituko dugu.
Amaitzeko, hitz batzuk esan nahiko nituzke Openstack (bai bainila eta saltzailea) VMWare-ren hodeiko soluzioarekin alderatzeari buruz - maizegi egin didate galdera hau azken bi urteetan eta, egia esanda, nago dagoeneko nekatuta, baina hala ere. Nire ustez, oso zaila da bi irtenbide hauek alderatzea, baina zalantzarik gabe esan dezakegu bi soluzioetan desabantailak daudela eta irtenbide bat aukeratzerakoan alde onak eta txarrak neurtu behar dituzula.
OpenStack komunitateak bultzatutako irtenbidea bada, orduan VMWare-k nahi duena bakarrik egiteko eskubidea du (irakurtzea - ββzer den errentagarria beretzat) eta hori logikoa da - bere bezeroekin dirua irabazteko ohituta dagoen merkataritza-enpresa bat delako. Baina handi eta lodi bat dago BAINA - OpenStack-etik irten zaitezke, adibidez, Nokia-tik, eta gastu gutxirekin, adibidez, Juniper-en (Contrail Cloud) irtenbide batera alda dezakezu, baina nekez aterako zara VMWaretik. . Niretzat, bi irtenbide hauek honelakoak dira - Openstack (saltzailea) kaiola soil bat da, bertan jartzen zaituzten, baina giltza daukazu eta edozein unetan utzi dezakezu. VMWare urrezko kaiola da, jabeak kaiolaren giltza du eta asko kostatuko zaizu.
Ez naiz lehen produktua edo bigarrena sustatzen ari; zuk aukeratzen duzu behar duzuna. Baina aukera hori izango banu, bi irtenbideak aukeratuko nituzke - VMWare IT hodeirako (karga baxuak, kudeaketa erraza), OpenStack saltzaile batzuena (Nokia eta Juniper-ek giltza eskuan oso irtenbide onak eskaintzen dituzte) - Telecom hodeirako. Ez nuke Openstack erabiliko IT hutserako - txolarreak kanoi batekin tiro egitea bezalakoa da, baina ez dut ikusten erredundantziaz gain erabiltzeko kontraindikaziorik. Hala ere, VMWare telekomunikazioetan erabiltzea Ford Raptor batean harri birrindua garraiatzea bezalakoa da; ederra da kanpotik, baina gidariak bat egin beharrean 10 bidaia egin behar ditu.
Nire ustez, VMWare-ren desabantailarik handiena erabateko itxitasuna da - konpainiak ez dizu nola funtzionatzen duenari buruzko informaziorik emango, adibidez, vSAN edo hipervisorearen nukleoan dagoenari buruz - ez da errentagarria, hau da, izango duzu. ez zaitez inoiz VMWare-n aditua izan - saltzaileen laguntzarik gabe, kondenatuta zaude (askotan galdera hutsalek nahastuta dauden VMWare-ko adituak ezagutzen ditut). Niretzat, VMWare auto bat erosten ari da kanpaia blokeatuta daukala - bai, baliteke kodifikazio-uhala alda dezaketen espezialistak izatea, baina soluzio hau saldu dizunak bakarrik ireki dezake kapaia. Pertsonalki, ez ditut gustuko sartu ezin ditudan irtenbideak. Esango duzu agian ez duzula kanpai azpian sartu behar. Bai, hau posible da, baina begiratuko zaitut hodeian funtzio handi bat muntatu behar duzunean 20-30 makina birtualetatik, 40-50 sareetatik, erdiak kanpora atera nahi dituena eta bigarren erdiak eskatzen duena. SR-IOV azelerazioa, bestela dozena pare bat auto gehiago beharko dituzu; bestela, errendimendua ez da nahikoa izango.
Badira beste ikuspuntu batzuk, beraz, zuk bakarrik erabaki dezakezu zer aukeratu eta, batez ere, orduan izango zara zure aukeraren ardura. Hau nire iritzia besterik ez da - gutxienez 4 produktu ikusi eta ukitu dituen pertsona bat - Nokia, Juniper, Red Hat eta VMWare. Hau da, badut zerbait konparatzeko.
Iturria: www.habr.com