Nuba komputado penetras pli kaj pli profunde en niajn vivojn kaj verŝajne ne ekzistas unu homo, kiu almenaŭ unufoje ne uzis iujn ajn nubservojn. Tamen, kio ĝuste estas nubo kaj kiel ĝi funkcias, malmultaj homoj scias, eĉ je la nivelo de ideo. 5G jam fariĝas realaĵo kaj la telekomunika infrastrukturo komencas moviĝi de kolonaj solvoj al nubaj solvoj, same kiel ĝi faris kiam ĝi moviĝis de tute aparataj solvoj al virtualigitaj "kolonoj".
Hodiaŭ ni parolos pri la interna mondo de nuba infrastrukturo, precipe ni rigardos la bazaĵojn de la reto-parto.
Kio estas nubo? La sama virtualigo - profilvido?
Pli ol logika demando. Ne - ĉi tio ne estas virtualigo, kvankam ĝi ne povus esti farita sen ĝi. Ni rigardu du difinojn:
Nuba komputado (ĉi-poste nomata Nubo) estas modelo por havigi uzant-amika aliro al distribuitaj komputikresursoj kiuj devas esti deplojitaj kaj lanĉitaj laŭ postulo kun la plej malalta ebla latenteco kaj minimuma kosto al la teleliveranto.
Virtualigo - ĉi tio estas la kapablo dividi unu fizikan enton (ekzemple servilo) en plurajn virtualajn, tiel pliigante la utiligon de rimedoj (ekzemple, vi havis 3 servilojn ŝarĝitaj je 25-30 procentoj, post virtualigo vi ŝarĝas 1 servilon. je 80-90 procentoj). Nature, virtualigo manĝas kelkajn el la rimedoj - vi devas nutri la hiperviziero, tamen, kiel praktiko montris, la ludo valoras la kandelon. Ideala ekzemplo de virtualigo estas VMWare, kiu perfekte preparas virtualajn maŝinojn, aŭ ekzemple KVM, kiun mi preferas, sed ĉi tio estas demando de gusto.
Ni uzas virtualigon sen rimarki ĝin, kaj eĉ feraj enkursigiloj jam uzas virtualigon - ekzemple, en la plej nova versio de JunOS, la operaciumo estas instalita kiel virtuala maŝino supre de realtempa Linukso-distribuo (Wind River 9). Sed virtualigo ne estas la nubo, sed la nubo ne povas ekzisti sen virtualigo.
Virtualigo estas unu el la konstrubriketoj sur kiuj la nubo estas konstruita.
Fari nubon simple kolektante plurajn hipervizilojn en unu L2-domajnon, aldonante kelkajn yaml-ludlibrojn por aŭtomate registri vlan-ojn per ia ansible kaj bloki ion kiel orkestradsistemon sur ĉio por aŭtomate krei virtualajn maŝinojn ne funkcios. Ĝi estos pli preciza, sed la rezulta Frankenstein ne estas la nubo, kiun ni bezonas, kvankam ĝi povas esti la finfina revo por aliaj. Krome, se vi prenas la saman Openstack, ĝi esence ankoraŭ estas Frankenstein, sed nu, ni ne parolu pri tio nuntempe.
Sed mi komprenas, ke el la supre prezentita difino ne estas tute klare, kion oni povas fakte nomi nubo.
Tial, dokumento de NIST (Nacia Instituto pri Normoj kaj Teknologio) disponigas 5 ĉefajn karakterizaĵojn, kiujn nuba infrastrukturo devus havi:
Provizante servon laŭ peto. La uzanto devas havi liberan aliron al la komputilaj rimedoj asignitaj al li (kiel retoj, virtualaj diskoj, memoro, procesorokernoj, ktp.), kaj tiuj rimedoj devas esti provizitaj aŭtomate – tio estas, sen interveno de la servoprovizanto.
Vasta havebleco de servo. Aliro al resursoj devas esti disponigita per normaj mekanismoj por permesi la uzon de kaj normaj komputiloj kaj maldikaj klientoj kaj porteblaj aparatoj.
Kombinante rimedojn en naĝejojn. Rimedoj devas povi disponigi resursojn al pluraj klientoj samtempe, certigante ke klientoj estas izolitaj kaj liberaj de reciproka influo kaj konkurado pri resursoj. Retoj ankaŭ estas inkluditaj en la naĝejoj, kio indikas la eblecon uzi imbrikitan adresadon. Naĝejoj devas povi grimpi laŭ postulo. La uzo de naĝejoj ebligas provizi la necesan nivelon de resursa faŭltoleremo kaj abstraktado de fizikaj kaj virtualaj rimedoj - la ricevanto de la servo estas simple provizita per la aro de rimedoj, kiujn li petis (kie ĉi tiuj rimedoj estas fizike lokitaj, sur kiom serviloj kaj ŝaltiloj - ne gravas al la kliento). Tamen, ni devas konsideri la fakton, ke la provizanto devas certigi travideblan rezervadon de ĉi tiuj rimedoj.
Rapida adaptiĝo al malsamaj kondiĉoj. Servoj devas esti flekseblaj - rapida liverado de rimedoj, ilia redistribuo, aldonado aŭ reduktado de rimedoj laŭ la peto de la kliento, kaj flanke de la kliento devus esti sento, ke la nubaj rimedoj estas senfinaj. Por facileco de kompreno, ekzemple, vi ne vidas averton, ke parto de via diskospaco en Apple iCloud malaperis ĉar la malmola disko sur la servilo paneis, kaj diskoj ja malfunkcias. Krome, viaflanke, la eblecoj de ĉi tiu servo estas preskaŭ senlimaj - vi bezonas 2 TB - neniu problemo, vi pagis kaj ricevis ĝin. Simila ekzemplo povas esti donita per Google.Drive aŭ Yandex.Disk.
Eblo mezuri la servon provizitan. Nubaj sistemoj devas aŭtomate kontroli kaj optimumigi konsumitajn resursojn, kaj ĉi tiuj mekanismoj devas esti travideblaj al kaj la uzanto kaj la servoprovizanto. Tio estas, vi ĉiam povas kontroli kiom da rimedoj vi kaj viaj klientoj konsumas.
Indas konsideri la fakton, ke ĉi tiuj postuloj estas plejparte postuloj por publika nubo, do por privata nubo (tio estas, nubo lanĉita por la internaj bezonoj de la kompanio), ĉi tiuj postuloj povas esti iomete ĝustigitaj. Tamen, ili ankoraŭ devas esti faritaj, alie ni ne ricevos ĉiujn avantaĝojn de nuba komputado.
Kial ni bezonas nubon?
Tamen, ajna nova aŭ ekzistanta teknologio, ajna nova protokolo estas kreita por io (nu, krom RIP-ng, kompreneble). Neniu bezonas protokolon pro protokolo (nu, krom RIP-ng, kompreneble). Estas logike, ke la Nubo estas kreita por provizi ian servon al la uzanto/kliento. Ni ĉiuj konas almenaŭ kelkajn nubajn servojn, ekzemple Dropbox aŭ Google.Docs, kaj mi kredas ke la plej multaj homoj uzas ilin sukcese - ekzemple, ĉi tiu artikolo estis skribita per la Google.Docs nuba servo. Sed la nubaj servoj, kiujn ni konas, estas nur parto de la kapabloj de la nubo—pli precize, ili estas nur SaaS-tipa servo. Ni povas provizi nuban servon en tri manieroj: en la formo de SaaS, PaaS aŭ IaaS. Kia servo vi bezonas dependas de viaj deziroj kaj kapabloj.
Ni rigardu ĉiun en ordo:
Programaro kiel Servo (SaaS) estas modelo por provizi plenrajtan servon al la kliento, ekzemple retpoŝta servo kiel Yandex.Mail aŭ Gmail. En ĉi tiu servo-livermodelo, vi, kiel kliento, efektive faras nenion krom uzi la servojn - tio estas, vi ne bezonas pensi pri agordo de la servo, ĝia erartoleremo aŭ redundo. La ĉefa afero estas ne kompromiti vian pasvorton; la provizanto de ĉi tiu servo faros la reston por vi. El la vidpunkto de la provizanto de servoj, li plene respondecas pri la tuta servo - de servila aparataro kaj gastigaj operaciumoj ĝis datumbazo kaj programaro agordoj.
Platformo kiel Servo (PaaS) — kiam vi uzas ĉi tiun modelon, la provizanto de servoj provizas al la kliento laborpecon por la servo, ekzemple, ni prenu Retservilon. La servoprovizanto provizis la klienton per virtuala servilo (fakte, aro da rimedoj, kiel RAM/CPU/Storage/Retoj, ktp.), kaj eĉ instalis la OS kaj necesan programaron sur ĉi tiu servilo, tamen, la agordo de ĉio ĉi estas farita de la kliento mem kaj por la plenumado de la servo la kliento respondas. La provizanto de servoj, kiel en la antaŭa kazo, respondecas pri la agado de fizikaj ekipaĵoj, hiperviziiloj, la virtuala maŝino mem, ĝia reto havebleco ktp., sed la servo mem ne plu estas en sia areo de respondeco.
Infrastrukturo kiel Servo (IaaS) - ĉi tiu aliro jam estas pli interesa, fakte, la provizanto de servoj provizas la klienton kun kompleta virtualigita infrastrukturo - tio estas, ia aro (pool) de rimedoj, kiel CPU Kernoj, RAM, Retoj, ktp. Ĉio alia estas ĝis la kliento - kion la kliento volas fari kun ĉi tiuj rimedoj ene de la asignita naĝejo (kvoto) - ĝi ne estas precipe grava por la provizanto. Ĉu la kliento volas krei sian propran vEPC aŭ eĉ krei mini-funkciigiston kaj provizi komunikajn servojn - sen demando - faru ĝin. En tia scenaro, la provizanto de servoj respondecas pri provizado de rimedoj, ilia faŭltoleremo kaj havebleco, same kiel la OS, kiu permesas al ili kunigi ĉi tiujn rimedojn kaj disponigi ilin al la kliento kun la kapablo pliigi aŭ malpliigi rimedojn iam ajn. laŭ peto de la kliento. La kliento mem agordas ĉiujn virtualajn maŝinojn kaj aliajn tinsel per la memserva portalo kaj konzolo, inkluzive de agordo de retoj (krom eksteraj retoj).
Kio estas OpenStack?
En ĉiuj tri opcioj, la servoprovizanto bezonas OS, kiu ebligos la kreadon de nuba infrastrukturo. Fakte, kun SaaS, pli ol unu dividado respondecas pri la tuta stako de teknologioj - ekzistas dividado, kiu respondecas pri la infrastrukturo - tio estas, ĝi provizas IaaS al alia dividado, ĉi tiu dividado provizas SaaS al la kliento. OpenStack estas unu el la nubaj operaciumoj, kiuj ebligas al vi kolekti amason da ŝaltiloj, serviloj kaj stoksistemoj en ununuran rimedon, dividi ĉi tiun komunan naĝejon en subgrupojn (luantoj) kaj provizi ĉi tiujn rimedojn al klientoj tra la reto.
OpenStack estas nuba operaciumo, kiu ebligas al vi kontroli grandajn arojn de komputikaj rimedoj, datumstokado kaj retaj rimedoj, provizitaj kaj administritaj per API per normaj aŭtentikigmekanismoj.
Alivorte, ĉi tio estas aro de projektoj pri libera programaro, kiu estas desegnita por krei nubservojn (kaj publikaj kaj privataj) - tio estas, aro da iloj, kiuj ebligas al vi kombini servilon kaj ŝanĝi ekipaĵon en ununuran aron da rimedoj, administri. ĉi tiuj rimedoj, disponigante la necesan nivelon de faŭltoleremo.
En la momento de verkado de ĉi tiu materialo, la OpenStack-strukturo aspektas jene:
Bildo prenita de
Ĉiu el la komponantoj inkluzivitaj en OpenStack plenumas specifan funkcion. Ĉi tiu distribuita arkitekturo permesas al vi inkluzivi en la solvo la aron de funkciaj komponantoj, kiujn vi bezonas. Tamen iuj komponantoj estas radikaj komponantoj kaj ilia forigo kondukos al kompleta aŭ parta nefunkciebleco de la solvo entute. Ĉi tiuj komponantoj estas kutime klasifikitaj kiel:
- Dashboard — Ret-bazita GUI por administri OpenStack-servojn
- Keystone estas alcentrigita identeca servo kiu disponigas aŭtentikigon kaj rajtigan funkcion por aliaj servoj, same kiel administrante uzantajn akreditaĵojn kaj iliajn rolojn.
- Neŭtrono - retservo kiu provizas konekteblecon inter la interfacoj de diversaj OpenStack-servoj (inkluzive de konektebleco inter VM-oj kaj ilia aliro al la ekstera mondo)
- Cindro — provizas aliron al blokado de stokado por virtualaj maŝinoj
- Nova — vivcikla administrado de virtualaj maŝinoj
- Rigardo — deponejo de virtualaj maŝinaj bildoj kaj momentfotoj
- Swift — provizas aliron al la konserva objekto
- Ceilometro — servo kiu disponigas la kapablon kolekti telemetrion kaj mezuri disponeblajn kaj konsumitajn rimedojn
- varmo — orkestrado bazita sur ŝablonoj por aŭtomata kreado kaj provizado de rimedoj
Kompleta listo de ĉiuj projektoj kaj ilia celo estas videbla .
Ĉiu OpenStack-komponento estas servo kiu plenumas specifan funkcion kaj disponigas API por administri tiun funkcion kaj interagi kun aliaj nubaj operaciumaj servoj por krei unuigitan infrastrukturon. Ekzemple, Nova provizas komputikan resursan administradon kaj API por aliro al agordo de ĉi tiuj rimedoj, Glance disponigas bildadministradon kaj API por administri ilin, Cinder provizas blokan stokadon kaj API por administri ĝin, ktp. Ĉiuj funkcioj estas interligitaj en tre proksima maniero.
Tamen, se vi rigardas ĝin, ĉiuj servoj kurantaj en OpenStack estas finfine ia virtuala maŝino (aŭ ujo) konektita al la reto. Estiĝas la demando - kial ni bezonas tiom da elementoj?
Ni trarigardu la algoritmon por krei virtualan maŝinon kaj konekti ĝin al la reto kaj konstanta stokado en Openstack.
- Kiam vi kreas peton por krei maŝinon, ĉu ĝi estas peto per Horizon (Dashboard) aŭ peto per la CLI, la unua afero kiu okazas estas la rajtigo de via peto sur Keystone - ĉu vi povas krei maŝinon, ĉu ĝi havas la rajton uzi ĉi tiun reton, ĉu via skizo kvoto, ktp.
- Keystone aŭtentikigas vian peton kaj generas aŭtentikan signon en la respondmesaĝo, kiu estos uzata plu. Ricevinte respondon de Keystone, la peto estas sendita al Nova (nova api).
- Nova-api kontrolas la validecon de via peto kontaktante Keystone uzante la antaŭe generitan aŭtentikan signon
- Keystone plenumas aŭtentikigon kaj provizas informojn pri permesoj kaj limigoj bazitaj sur ĉi tiu aŭtsignalo.
- Nova-api kreas eniron por la nova VM en nova-datumbazo kaj pasas la peton krei la maŝinon al nova-planisto.
- Nova-planisto elektas la gastiganton (komputila nodo) sur kiu la VM estos deplojita surbaze de la specifitaj parametroj, pezoj kaj zonoj. Noto pri tio kaj la VM-ID estas skribitaj al nova-datumbazo.
- Poste, nova-scheduler kontaktas nova-compute kun peto deploji petskribon. Nova-komputilo kontaktas nova-konduktilon por akiri informojn pri maŝinparametroj (nova-konduktilo estas nova elemento kiu funkcias kiel prokura servilo inter nova-datumbazo kaj nova-komputilo, limigante la nombron da petoj al nova-datumbazo por eviti problemojn kun datumbazo. konsistenca ŝarĝoredukto).
- Nova-konduktoro ricevas la petitajn informojn de nova-datumbazo kaj pasas ĝin al nova-komputilo.
- Poste, nova-komputilo vokas ekrigardon por akiri la bildan ID. Glace validas la peton en Keystone kaj resendas la petitajn informojn.
- Nova-komputilo kontaktas neŭtronon por akiri informojn pri retaj parametroj. Simile al rigardo, neŭtrono validas la peton en Keystone, post kio ĝi kreas eniron en la datumbazo (havenidentigilo, ktp.), kreas peton por krei havenon, kaj resendas la petitajn informojn al nova-komputilo.
- Nova-komputilo kontaktas cinder kun peto asigni volumon al la virtuala maŝino. Simile al rigardo, cidro validas la peton en Keystone, kreas volumenan krepeton kaj resendas la petitajn informojn.
- Nova-komputado kontaktas libvirt kun peto deploji virtualan maŝinon kun la specifitaj parametroj.
Fakte, ŝajne simpla operacio de kreado de simpla virtuala maŝino iĝas tia kirlo de API-vokoj inter elementoj de la nuba platformo. Krome, kiel vi povas vidi, eĉ la antaŭe indikitaj servoj ankaŭ konsistas el pli malgrandaj komponantoj inter kiuj okazas interagado. Krei maŝinon estas nur malgranda parto de tio, kion la nuba platformo permesas al vi fari - ekzistas servo respondeca pri ekvilibro de trafiko, servo respondeca pri bloka stokado, servo respondeca pri DNS, servo respondeca por provizi nudametalajn servilojn ktp. La nubo permesas vin trakti viajn virtualajn maŝinojn kiel gregon da ŝafoj (kontraste al virtualigo). Se io okazas al via maŝino en virtuala medio - vi restarigas ĝin de sekurkopioj ktp., sed nubaj aplikaĵoj estas konstruitaj tiel, ke la virtuala maŝino ne ludas tiom gravan rolon - la virtuala maŝino "mortis" - neniu problemo - nova estas ĵus kreita, la veturilo baziĝas sur la ŝablono kaj, kiel oni diras, la taĉmento ne rimarkis la perdon de la batalanto. Nature, ĉi tio provizas la ĉeeston de instrumentaj mekanismoj - uzante Heat-ŝablonojn, vi povas facile disfaldi kompleksan funkcion konsistantan el dekoj da retoj kaj virtualaj maŝinoj.
Ĉiam indas konsideri, ke ne ekzistas nuba infrastrukturo sen reto - ĉiu elemento laŭ unu maniero aŭ alia interagas kun aliaj elementoj per la reto. Krome, la nubo havas absolute ne-statikan reton. Kompreneble, la submeta reto estas eĉ pli-malpli senmova - novaj nodoj kaj ŝaltiloj ne estas aldonitaj ĉiutage, sed la supermetaĵo povas kaj neeviteble ŝanĝiĝos konstante - novaj retoj estos aldonitaj aŭ forigitaj, novaj virtualaj maŝinoj aperos kaj malnovaj aperos. morti. Kaj kiel vi memoras de la difino de la nubo donita ĉe la komenco de la artikolo, rimedoj devus esti asignitaj al la uzanto aŭtomate kaj kun la plej malgranda (aŭ pli bone, sen) interveno de la servoprovizanto. Tio estas, la speco de provizo de retresursoj, kiu nun ekzistas en la formo de front-end en la formo de via persona konto alirebla per http/https kaj la deĵoranta ret-inĝeniero Vasilij kiel backend ne estas nubo, eĉ se Vasilij havas ok manojn.
Neutron, kiel retservo, disponigas API por administri la retan parton de la nuba infrastrukturo. La servo povigas kaj administras la interkonektan parton de Openstack disponigante abstraktan tavolon nomitan Network-as-a-Service (NaaS). Tio estas, la reto estas la sama virtuala mezurebla unuo kiel, ekzemple, virtualaj CPU-kernoj aŭ la kvanto de RAM.
Sed antaŭ ol transiri al la arkitekturo de la retoparto de OpenStack, ni konsideru kiel ĉi tiu reto funkcias en OpenStack kaj kial la reto estas grava kaj integra parto de la nubo.
Do ni havas du RUĜAJ klientajn VM-ojn kaj du VERDAjn klientajn VM-ojn. Ni supozu, ke ĉi tiuj maŝinoj situas sur du hiperviziiloj tiamaniere:
Nuntempe tio estas nur virtualigo de 4 serviloj kaj nenio pli, ĉar ĝis nun ĉio, kion ni faris, estas virtualigi 4 servilojn, metante ilin sur du fizikajn servilojn. Kaj ĝis nun ili eĉ ne estas konektitaj al la reto.
Por fari nubon, ni devas aldoni plurajn komponantojn. Unue, ni virtualigas la retan parton - ni devas konekti ĉi tiujn 4 maŝinojn duope, kaj la klientoj volas L2-konekton. Vi povas uzi ŝaltilon kaj agordi trunkon en ĝia direkto kaj solvi ĉion uzante linuksan ponton aŭ, por pli progresintaj uzantoj, openvswitch (ni revenos al tio poste). Sed povas ekzisti multaj retoj, kaj senĉese puŝi L2 tra ŝaltilo ne estas la plej bona ideo - ekzistas malsamaj fakoj, servotablo, monatoj da atendado por kompletigo de aplikaĵo, semajnoj da problemoj - en la moderna mondo ĉi tio. alproksimiĝo ne plu funkcias. Kaj ju pli frue kompanio komprenas ĉi tion, des pli facile estas por ĝi antaŭeniri. Sekve, inter la hiperviziiloj ni elektos L3-reton per kiu niaj virtualaj maŝinoj komunikiĝos, kaj supre de ĉi tiu L3-reto ni konstruos virtualajn L2-retajn retojn, kie la trafiko de niaj virtualaj maŝinoj funkcios. Vi povas uzi GRE, Geneve aŭ VxLAN kiel enkapsuligon. Ni koncentriĝu pri ĉi-lasta nuntempe, kvankam ĝi ne estas aparte grava.
Ni devas lokalizi VTEP ie (mi esperas, ke ĉiuj konas la terminologion de VxLAN). Ĉar ni havas L3-reton venantan rekte de la serviloj, nenio malhelpas nin meti VTEP sur la servilojn mem, kaj OVS (OpenvSwitch) bonegas fari tion. Kiel rezulto, ni ricevis ĉi tiun dezajnon:
Ĉar trafiko inter VM-oj devas esti dividita, la havenoj al la virtualaj maŝinoj havos malsamajn vlan-nombrojn. La etikedo-numero rolas nur ene de unu virtuala ŝaltilo, ĉar kiam enkapsulite en VxLAN ni povas facile forigi ĝin, ĉar ni havos VNI.
Nun ni povas krei niajn maŝinojn kaj virtualajn retojn por ili sen problemoj.
Tamen, kio se la kliento havas alian maŝinon, sed estas en malsama reto? Ni bezonas enradikiĝon inter retoj. Ni rigardos simplan opcion kiam centralizita vojigo estas uzata - tio estas, trafiko estas direktita per specialaj dediĉitaj retaj nodoj (nu, kiel regulo, ili estas kombinitaj kun kontrolnodoj, do ni havos la samon).
Ŝajnas nenio komplika - ni faras pontan interfacon sur la kontrolnodo, veturas trafikon al ĝi kaj de tie ni direktas ĝin kien ni bezonas ĝin. Sed la problemo estas, ke la RED-kliento volas uzi la 10.0.0.0/24-reton, kaj la VERDA-kliento volas uzi la 10.0.0.0/24-reton. Tio estas, ni komencas intersekci adresspacojn. Aldone, klientoj ne volas, ke aliaj klientoj povu iri en siajn internajn retojn, kio havas sencon. Por apartigi la retojn kaj klientdatumtrafikon, ni asignos apartan nomspacon por ĉiu el ili. Nomspaco fakte estas kopio de la Linukso retstako, tio estas, klientoj en nomspaco RUĜA estas tute izolitaj de klientoj de nomspaco VERDA (nu, ĉu vojigo inter ĉi tiuj klientretoj estas permesita tra la defaŭlta nomspaco aŭ sur kontraŭflua transporta ekipaĵo).
Tio estas, ni ricevas la sekvan diagramon:
L2-tuneloj konverĝas de ĉiuj komputiknodoj al la kontrolnodo. nodo kie la L3-interfaco por tiuj retoj situas, ĉiu en diligenta nomspaco por izolado.
Tamen ni forgesis la plej gravan aferon. La virtuala maŝino devas provizi servon al la kliento, tio estas, ĝi devas havi almenaŭ unu eksteran interfacon tra kiu ĝi povas esti atingita. Tio estas, ni devas eliri en la eksteran mondon. Estas malsamaj ebloj ĉi tie. Ni faru la plej simplan eblon. Ni aldonos unu reton al ĉiu kliento, kiu validos en la reto de la provizanto kaj ne interkovros kun aliaj retoj. La retoj ankaŭ povas intersekci kaj rigardi malsamajn VRFojn flanke de la provizanto-reto. La retaj datumoj ankaŭ loĝos en la nomspaco de ĉiu kliento. Tamen, ili ankoraŭ eliros al la ekstera mondo per unu fizika (aŭ ligo, kio estas pli logika) interfaco. Por apartigi klienttrafikon, trafiko iranta eksteren estos etikedita kun VLAN-etikedo asignita al la kliento.
Kiel rezulto, ni ricevis ĉi tiun diagramon:
Racia demando estas kial ne fari enirejojn sur la komputaj nodoj mem? Ĉi tio ne estas granda problemo; krome, se vi ŝaltas la distribuitan enkursigilon (DVR), tio funkcios. En ĉi tiu scenaro, ni konsideras la plej simplan opcion kun centralizita enirejo, kiu estas uzata defaŭlte en Openstack. Por altŝarĝaj funkcioj, ili uzos ambaŭ distribuitan enkursigilon kaj akcelajn teknologiojn kiel ekzemple SR-IOV kaj Passthrough, sed kiel ili diras, tio estas tute alia rakonto. Unue, ni traktu la bazan parton, kaj poste ni eniros la detalojn.
Efektive, nia skemo jam estas realigebla, sed estas kelkaj nuancoj:
- Ni devas iel protekti niajn maŝinojn, tio estas, meti filtrilon sur la ŝaltila interfaco al la kliento.
- Ebligu, ke virtuala maŝino aŭtomate akiru IP-adreson, por ke vi ne devas ĉiufoje ensaluti ĝin per la konzolo kaj registri la adreson.
Ni komencu per maŝina protekto. Por tio vi povas uzi banala iptables, kial ne.
Tio estas, nun nia topologio fariĝis iom pli komplika:
Ni pluiru. Ni devas aldoni DHCP-servilon. La plej ideala loko por lokalizi DHCP-servilojn por ĉiu kliento estus la kontrolnodo jam menciita supre, kie troviĝas la nomspacoj:
Tamen, estas malgranda problemo. Kio se ĉio rekomencas kaj ĉiuj informoj pri luadresoj ĉe DHCP malaperas. Estas logike, ke la maŝinoj ricevos novajn adresojn, kio ne estas tre oportuna. Estas du vojoj ĉi tie - aŭ uzu domajnajn nomojn kaj aldonu DNS-servilon por ĉiu kliento, tiam la adreso ne estos aparte grava por ni (simila al la retoparto en k8s) - sed estas problemo kun eksteraj retoj, ĉar adresoj ankaŭ povas esti elsenditaj en ili per DHCP - oni bezonas sinkronigon kun DNS-serviloj en la nuba platformo kaj ekstera DNS-servilo, kio laŭ mi ne estas tre fleksebla, sed estas tute ebla. Aŭ la dua opcio estas uzi metadatenojn - tio estas, konservi informojn pri la adreso eldonita al la maŝino, por ke la DHCP-servilo sciu kiun adreson doni al la maŝino se la maŝino jam ricevis adreson. La dua opcio estas pli simpla kaj pli fleksebla, ĉar ĝi permesas vin konservi pliajn informojn pri la aŭto. Nun ni aldonu agentajn metadatumojn al la diagramo:
Alia afero, kiu ankaŭ valoras diskuti, estas la kapablo uzi unu eksteran reton de ĉiuj klientoj, ĉar eksteraj retoj, se ili devas esti validaj tra la tuta reto, estos malfacilaj - vi devas konstante asigni kaj kontroli la atribuon de ĉi tiuj retoj. La kapablo uzi ununuran eksteran antaŭ-konfiguritan reton por ĉiuj klientoj estos tre utila dum kreado de publika nubo. Ĉi tio faciligos disfaldi maŝinojn ĉar ni ne devas konsulti adresdatumbazon kaj elekti unikan adresspacon por la ekstera reto de ĉiu kliento. Krome, ni povas registri eksteran reton anticipe kaj en la momento de deplojo ni nur bezonos asocii eksterajn adresojn kun klientaj maŝinoj.
Kaj ĉi tie NAT venas al nia helpo - ni nur ebligos al klientoj aliri la eksteran mondon per la defaŭlta nomspaco uzante NAT-tradukon. Nu, jen malgranda problemo. Ĉi tio estas bona se la klientservilo agas kiel kliento kaj ne kiel servilo - tio estas, ĝi iniciatas prefere ol akceptas konektojn. Sed por ni estos inverse. En ĉi tiu kazo, ni devas fari celon NAT por ke kiam ricevante trafikon, la kontrolnodo komprenu, ke ĉi tiu trafiko estas destinita por virtuala maŝino A de kliento A, kio signifas, ke ni devas fari NAT-tradukon de ekstera adreso, ekzemple 100.1.1.1. .10.0.0.1, al interna adreso 100. En ĉi tiu kazo, kvankam ĉiuj klientoj uzos la saman reton, interna izolado estas tute konservita. Tio estas, ni devas fari dNAT kaj sNAT sur la kontrolnodo. Ĉu uzi ununuran reton kun flosantaj adresoj aŭ eksteraj retoj, aŭ ambaŭ samtempe, dependas de tio, kion vi volas alporti en la nubon. Ni ne aldonos flosajn adresojn al la diagramo, sed lasos la eksterajn retojn jam aldonitajn pli frue - ĉiu kliento havas sian propran eksteran reton (en la diagramo ili estas indikitaj kiel vlan 200 kaj XNUMX sur la ekstera interfaco).
Rezulte, ni ricevis interesan kaj samtempe bone pripensitan solvon, kiu havas certan flekseblecon sed ankoraŭ ne havas misfunkciajn toleremajn mekanismojn.
Unue, ni havas nur unu kontrolnodon - ĝia fiasko kondukos al disfalo de ĉiuj sistemoj. Por solvi ĉi tiun problemon, vi devas fari almenaŭ kvorumon de 3 nodoj. Ni aldonu ĉi tion al la diagramo:
Nature, ĉiuj nodoj estas sinkronigitaj kaj kiam aktiva nodo foriras, alia nodo transprenos siajn respondecojn.
La sekva problemo estas virtualaj maŝinaj diskoj. Nuntempe, ili estas konservitaj sur la hiperviziiloj mem, kaj en kazo de problemoj kun la hiperviziero, ni perdas ĉiujn datumojn - kaj la ĉeesto de atako ne helpos ĉi tie, se ni perdos ne la diskon, sed la tutan servilon. Por fari tion, ni devas fari servon, kiu funkcios kiel la antaŭa fino por ia stokado. Kia stokado ĝi estos ne aparte gravas por ni, sed ĝi devus protekti niajn datumojn kontraŭ malsukceso de kaj la disko kaj la nodo, kaj eble la tuta kabineto. Estas pluraj ebloj ĉi tie - ekzistas, kompreneble, SAN-retoj kun Fibre Channel, sed ni estu honestaj - FC jam estas restaĵo de la pasinteco - analogo de E1 en transporto - jes, mi konsentas, ĝi ankoraŭ estas uzata, sed nur kie ĝi estas absolute neebla sen ĝi. Tial mi ne libervole disfaldis FC-reton en 2020, sciante, ke ekzistas aliaj pli interesaj alternativoj. Kvankam al ĉiu sia propra, eble ekzistas tiuj, kiuj kredas, ke FC kun ĉiuj ĝiaj limoj estas ĉio, kion ni bezonas - mi ne argumentos, ĉiu havas sian propran opinion. Tamen la plej interesa solvo laŭ mi estas uzi SDS, kiel Ceph.
Ceph ebligas al vi konstrui tre haveblan datuman stokan solvon kun amaso da eblaj rezervaj opcioj, komencante per kodoj kun egaleco-kontrolado (analoga al raid 5 aŭ 6) finiĝante kun plena datumreproduktado al malsamaj diskoj, konsiderante la lokon de diskoj en serviloj, kaj serviloj en kabinetoj, ktp.
Por konstrui Ceph vi bezonas 3 pliajn nodojn. Interago kun la stokado ankaŭ estos efektivigita per la reto uzante blokajn, objektojn kaj dosierojn stokadservojn. Ni aldonu stokadon al la skemo:
Noto: vi ankaŭ povas fari hiperkonverĝajn komputajn nodojn - jen la koncepto de kombini plurajn funkciojn sur unu nodo - ekzemple stokado+komputi - sen dediĉi specialajn nodojn por ceph-stokado. Ni ricevos la saman mistolereman skemon - ĉar SDS rezervos datumojn kun la rezerva nivelo, kiun ni specifas. Tamen, hiperkonverĝaj nodoj ĉiam estas kompromiso - ĉar la stokadnodo ne nur varmigas la aeron kiel ŝajnas unuavide (ĉar ne estas virtualaj maŝinoj sur ĝi) - ĝi elspezas CPU-resursojn por priservado de SDS (fakte, ĝi faras ĉion. la reproduktado kaj reakiro post misfunkciadoj de nodoj, diskoj, ktp.). Tio estas, vi perdos iom da la potenco de la komputa nodo se vi kombinas ĝin kun stokado.
Ĉiuj ĉi aferoj devas esti administritaj iel - ni bezonas ion per kio ni povas krei maŝinon, reton, virtualan enkursigilon, ktp. Por fari tion, ni aldonos servon al la kontrolnodo, kiu funkcios kiel panelo - la kliento povos konektiĝi al ĉi tiu portalo per http/ https kaj fari ĉion, kion li bezonas (nu, preskaŭ).
Kiel rezulto, ni nun havas mistoleran sistemon. Ĉiuj elementoj de ĉi tiu infrastrukturo devas esti administritaj iel. Antaŭe estis priskribite, ke Openstack estas aro de projektoj, ĉiu el kiuj disponigas specifan funkcion. Kiel ni vidas, estas pli ol sufiĉe da elementoj, kiuj devas esti agordaj kaj kontrolitaj. Hodiaŭ ni parolos pri la reto-parto.
Neŭtrona arkitekturo
En OpenStack, estas Neutron kiu respondecas pri ligado de virtualaj maŝinhavenoj al ofta L2-reto, certigante trafikvojigon inter VM-oj situantaj sur malsamaj L2-retoj, same kiel eksteren vojigon, disponigante servojn kiel NAT, Floating IP, DHCP, ktp.
Je alta nivelo, la funkciado de la retservo (la baza parto) povas esti priskribita jene.
Komencante la VM, la retservo:
- Kreas havenon por donita VM (aŭ havenoj) kaj sciigas la DHCP-servon pri ĝi;
- Nova virtuala reta aparato estas kreita (per libvirt);
- La VM konektas al la haveno(j) kreita(j) en la paŝo 1;
Sufiĉe, la laboro de Neutron baziĝas sur normaj mekanismoj konataj al ĉiuj, kiuj iam plonĝis en Linukso - nomspacoj, iptables, linuksaj pontoj, openvswitch, conntrack, ktp.
Oni devas tuj klarigi, ke Neutron ne estas SDN-regilo.
Neŭtrono konsistas el pluraj interligitaj komponentoj:
Openstack-neŭtron-servilo estas demono kiu funkcias kun uzantpetoj per la API. Ĉi tiu demono ne okupiĝas pri registrado de iuj retaj konektoj, sed provizas la necesajn informojn por tio al siaj kromaĵoj, kiuj tiam agordas la deziratan retan elementon. Neŭtronaj agentoj sur OpenStack-nodoj registras ĉe la Neutron-servilo.
Neutron-servilo estas fakte aplikaĵo skribita en python, konsistanta el du partoj:
- REST-servo
- Neŭtrona Kromaĵo (kerno/servo)
La REST-servo estas desegnita por ricevi API-vokojn de aliaj komponentoj (ekzemple, peto provizi iujn informojn, ktp.)
Kromaĵoj estas aldonaĵaj programaraj komponantoj/moduloj, kiuj estas nomitaj dum API-petoj - tio estas, la atribuo de servo okazas per ili. Kromaĵoj estas dividitaj en du tipojn - servo kaj radiko. Kiel regulo, la ĉevalkromaĵo respondecas ĉefe pri administrado de la adresspaco kaj L2-konektoj inter VM-oj, kaj servaj aldonaĵoj jam provizas plian funkciecon kiel VPN aŭ FW.
La listo de aldonaĵoj disponeblaj hodiaŭ povas esti vidita ekzemple
Povas ekzisti pluraj servaj aldonaĵoj, sed povas esti nur unu ĉevalaldonaĵo.
openstack-neŭtron-ml2 estas la norma Openstack radika kromaĵo. Ĉi tiu kromaĵo havas modulan arkitekturon (male al sia antaŭulo) kaj agordas la retan servon per ŝoforoj konektitaj al ĝi. Ni rigardos la kromprogramon mem iom poste, ĉar fakte ĝi donas la flekseblecon, kiun OpenStack havas en la retoparto. La radika kromaĵo povas esti anstataŭigita (ekzemple, Contrail Networking faras tian anstataŭaĵon).
RPC-servo (rabbitmq-servilo) — servo kiu provizas atendovicadministradon kaj interagadon kun aliaj OpenStack-servoj, same kiel interagadon inter retaj servaj agentoj.
Retaj agentoj — agentoj kiuj situas en ĉiu nodo, per kiuj retaj servoj estas agorditaj.
Estas pluraj specoj de agentoj.
La ĉefa agento estas L2 agento. Ĉi tiuj agentoj funkcias sur ĉiu el la hiperviziiloj, inkluzive de kontrolnodoj (pli precize, sur ĉiuj nodoj, kiuj provizas ajnan servon por luantoj) kaj ilia ĉefa funkcio estas konekti virtualajn maŝinojn al komuna L2-reto, kaj ankaŭ generi atentigojn kiam okazas iuj ajn eventoj ( ekzemple malŝalti/aktivigi la havenon).
La sekva, ne malpli grava agento estas L3 agento. Defaŭlte, ĉi tiu agento funkcias ekskluzive sur retnodo (ofte la retnodo estas kombinita kun kontrolnodo) kaj disponigas vojigon inter luantretoj (kaj inter ĝiaj retoj kaj la retoj de aliaj luantoj, kaj estas alirebla por la ekstera mondo, disponigante NAT, same kiel DHCP-servo). Tamen, uzante DVR (distribuita enkursigilo), la bezono de L3 kromaĵo ankaŭ aperas sur la komputaj nodoj.
La L3-agento uzas Linuksajn nomspacojn por provizi ĉiun luanton per aro de siaj propraj izolitaj retoj kaj la funkciecon de virtualaj enkursigiloj kiuj direktas trafikon kaj disponigas enirejservojn por Tavolo 2-retoj.
Datumbazo — datumbazo de identigiloj de retoj, subretoj, havenoj, naĝejoj, ktp.
Fakte, Neutron akceptas API-petojn de la kreado de iuj retaj entoj, aŭtentikigas la peton, kaj per RPC (se ĝi aliras iun kromaĵon aŭ agenton) aŭ REST API (se ĝi komunikas en SDN) transdonas al la agentoj (per kromaĵoj) la instrukcioj necesaj por organizi la petitan servon.
Nun ni turnu nin al la testa instalado (kiel ĝi estas deplojita kaj kio estas inkluzivita en ĝi, ni vidos poste en la praktika parto) kaj vidu kie troviĝas ĉiu komponanto:
(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 ~]$
Efektive, tio estas la tuta strukturo de Neutron. Nun indas pasigi iom da tempo sur la kromaĵo ML2.
Modula Tavolo 2
Kiel menciite supre, la kromaĵo estas norma OpenStack radika kromaĵo kaj havas modulan arkitekturon.
La antaŭulo de la kromaĵo ML2 havis monolitan strukturon, kiu ne permesis, ekzemple, uzi miksaĵon de pluraj teknologioj en unu instalaĵo. Ekzemple, vi ne povus uzi kaj openvswitch kaj linuxbridge samtempe - aŭ la unuan aŭ la duan. Tial, la kromaĵo ML2 kun sia arkitekturo estis kreita.
ML2 havas du komponentojn - du specojn de ŝoforoj: Tipo-ŝoforoj kaj Mekanismo-ŝoforoj.
Tajpu ŝoforojn determini la teknologiojn, kiuj estos uzataj por organizi retajn konektojn, ekzemple VxLAN, VLAN, GRE. Samtempe, la ŝoforo permesas la uzon de malsamaj teknologioj. La norma teknologio estas VxLAN-enkapsuligo por overlay retoj kaj vlan eksteraj retoj.
Tippeliloj inkluzivas la jenajn retajn tipojn:
plata - reto sen etikedado
VLANO - etikedita reto
lokaj - speciala speco de reto por tute-en-unu instalaĵoj (tiaj instalaĵoj estas bezonataj aŭ por programistoj aŭ por trejnado)
GRE — tegu reton uzante GRE-tunelojn
VxLAN — tegu reton uzante VxLAN-tunelojn
Mekanismo-ŝoforoj difinu ilojn, kiuj certigas la organizon de la teknologioj specifitaj en la tippelilo - ekzemple openvswitch, sr-iov, opendaylight, OVN, ktp.
Depende de la efektivigo de ĉi tiu ŝoforo, aŭ agentoj kontrolitaj de Neutron estos uzataj, aŭ ligoj al ekstera SDN-regilo estos uzataj, kiu prizorgas ĉiujn aferojn rilate al organizado de L2-retoj, vojigo ktp.
Ekzemplo: se ni uzas ML2 kune kun OVS, tiam L2-agento estas instalita sur ĉiu komputika nodo kiu administras OVS. Tamen, se ni uzas, ekzemple, OVN aŭ OpenDayLight, tiam la kontrolo de OVS venas sub ilia jurisdikcio - Neutron, per la radika kromaĵo, donas komandojn al la regilo, kaj ĝi jam faras tion, kion oni diris al ĝi.
Ni tuŝu Open vSwitch
Nuntempe, unu el la ĉefaj komponantoj de OpenStack estas Open vSwitch.
Kiam vi instalas OpenStack sen iu plia vendisto SDN kiel Juniper Contrail aŭ Nokia Nuage, OVS estas la ĉefa reta komponanto de la nuba reto kaj, kune kun iptables, conntrack, nomspacoj, ebligas al vi organizi plenrajtajn plurluajn retojn. Kompreneble, ĉi tiu komponanto povas esti anstataŭigita, ekzemple, kiam oni uzas triajn proprietajn (vendistajn) SDN-solvojn.
OVS estas malfermfonta softvarŝaltilo kiu estas dizajnita por uzo en virtualigitaj medioj kiel virtuala trafika plusendisto.
Nuntempe, OVS havas tre decan funkciecon, kiu inkluzivas teknologiojn kiel QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, ktp.
Notu: OVS ne estis komence elpensita kiel mola ŝaltilo por tre ŝarĝitaj telekomunikaj funkcioj kaj estis pli dizajnita por malpli bendolarĝ-postulemaj IT-funkcioj kiel ekzemple RETEJO-servilo aŭ poŝtservilo. Tamen, OVS estas plue evoluigita kaj nunaj efektivigoj de OVS multe plibonigis ĝian efikecon kaj kapablojn, kio permesas al ĝi esti uzita de teleentreprenistoj kun tre ŝarĝitaj funkcioj, ekzemple, ekzistas OVS-efektivigo kun subteno por DPDK-akcelo.
Estas tri gravaj komponantoj de OVS, pri kiuj vi devas esti konscia:
- Kernelmodulo — komponanto situanta en la kernspaco, kiu prilaboras trafikon surbaze de la reguloj ricevitaj de la kontrolelemento;
- vŜaltilo demono (ovs-vswitchd) estas procezo lanĉita en uzantspaco, kiu respondecas pri programado de la kernomodulo - tio estas, ĝi rekte reprezentas la logikon de la operacio de la ŝaltilo.
- Datumbaza servilo - loka datumbazo situanta sur ĉiu gastiganto kuranta OVS, en kiu la agordo estas konservita. SDN-regiloj povas komuniki per ĉi tiu modulo uzante la OVSDB-protokolon.
Ĉio ĉi estas akompanata de aro da diagnozaj kaj administradaj utilecoj, kiel ovs-vsctl, ovs-appctl, ovs-ofctl, ktp.
Nuntempe, Openstack estas vaste uzata de telekomunikaj operatoroj por migri retajn funkciojn al ĝi, kiel EPC, SBC, HLR, ktp. Iuj funkcioj povas vivi sen problemoj kun OVS kiel estas, sed ekzemple EPC prilaboras abonan trafikon - tiam ĝi trapasas. grandega trafiko (nun trafikaj volumoj atingas kelkcent gigabitojn sekundo). Kompreneble, veturi tian trafikon tra kernspaco (ĉar la plusendilo troviĝas tie defaŭlte) ne estas la plej bona ideo. Tial, OVS ofte estas deplojita tute en uzantspaco uzante DPDK-akcelteknologion por plusendi trafikon de NIC al uzantspaco preterirante la kernon.
Notu: por nubo deplojita por telekomunikaj funkcioj, estas eble eligi trafikon de komputa nodo preterirante OVS rekte al ŝanĝanta ekipaĵon. SR-IOV kaj Passthrough-mekanismoj estas uzitaj por tiu celo.
Kiel tio funkcias sur reala aranĝo?
Nu, nun ni transiru al la praktika parto kaj vidu kiel ĉio funkcias en la praktiko.
Unue, ni disfaldu simplan instaladon de Openstack. Ĉar mi ne havas aron da serviloj ĉemane por eksperimentoj, ni kunvenos la prototipon sur unu fizika servilo de virtualaj maŝinoj. Jes, nature, tia solvo ne taŭgas por komercaj celoj, sed por vidi ekzemplon pri kiel la reto funkcias en Openstack, tia instalado sufiĉas por la okuloj. Krome, tia instalado estas eĉ pli interesa por trejnado - ĉar vi povas kapti trafikon ktp.
Ĉar ni bezonas nur vidi la bazan parton, ni ne povas uzi plurajn retojn sed levi ĉion uzante nur du retojn, kaj la dua reto en ĉi tiu aranĝo estos uzata ekskluzive por aliro al la subnubo kaj DNS-servilo. Ni ne tuŝos eksterajn retojn nun - ĉi tio estas temo por aparta granda artikolo.
Do, ni komencu en ordo. Unue, iom da teorio. Ni instalos Openstack uzante TripleO (Openstack sur Openstack). La esenco de TripleO estas, ke ni instalas Openstack ĉio-en-unu (tio estas, sur unu nodo), nomita subnubo, kaj poste uzas la kapablojn de la deplojita Openstack por instali Openstack celitan por funkciado, nomitan overcloud. Undercloud uzos sian propran kapablon administri fizikajn servilojn (nuda metalo) - la Ironia projekto - por provizi hipervizilojn, kiuj plenumos la rolojn de komputado, kontrolo, stokado nodoj. Tio estas, ni ne uzas iujn ajn triajn ilojn por deploji Openstack - ni deplojas Openstack uzante Openstack. Ĝi fariĝos multe pli klara dum la instalado progresas, do ni ne haltos tie kaj antaŭeniros.
Noto: En ĉi tiu artikolo, por simpleco, mi ne uzis retan izolitecon por internaj Openstack-retoj, sed ĉio estas deplojita uzante nur unu reton. Tamen, la ĉeesto aŭ foresto de retizolado ne influas la bazan funkcion de la solvo - ĉio funkcios ekzakte same kiel kiam oni uzas izoladon, sed trafiko fluos sur la sama reto. Por komerca instalado, estas nature necese uzi izolitecon uzante malsamajn vlanojn kaj interfacojn. Ekzemple, ceph-stokado-administrada trafiko kaj datumtrafiko mem (maŝina aliro al diskoj, ktp.) kiam izolite uzas malsamajn subretojn (stokado-administrado kaj stokado) kaj ĉi tio ebligas al vi fari la solvon pli mistolerema dividante ĉi tiun trafikon, ekzemple , trans malsamaj havenoj, aŭ uzante malsamajn QoS-profilojn por malsama trafiko tiel ke datumtrafiko ne elpremu signalan trafikon. En nia kazo, ili iros en la sama reto kaj fakte ĉi tio neniel limigas nin.
Noto: Ĉar ni funkcios virtualajn maŝinojn en virtuala medio bazita sur virtualaj maŝinoj, ni unue devas ebligi nestitan virtualigon.
Vi povas kontroli ĉu nesta virtualigo estas ebligita aŭ ne tiel:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Se vi vidas la literon N, tiam ni ebligas subtenon por nestita virtualigo laŭ iu ajn gvidilo, kiun vi trovas en la reto, ekzemple .
Ni devas kunveni la sekvan cirkviton de virtualaj maŝinoj:
En mia kazo, por konekti la virtualajn maŝinojn kiuj estas parto de la estonta instalado (kaj mi ricevis 7 el ili, sed vi povas elteni per 4 se vi ne havas multajn rimedojn), mi uzis OpenvSwitch. Mi kreis unu ovs-ponton kaj konektis virtualajn maŝinojn al ĝi per havengrupoj. Por fari tion, mi kreis xml-dosieron jene:
[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>Tri havengrupoj estas deklaritaj ĉi tie - du aliroj kaj unu trunko (ĉi-lasta estis bezonata por la DNS-servilo, sed vi povas malhavi ĝin, aŭ instali ĝin sur la gastiga maŝino - kiu ajn estas pli oportuna por vi). Poste, uzante ĉi tiun ŝablonon, ni deklaras la nian per virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nun ni redaktas la agordojn de la haveno de hiperviziero:
[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 ~]# Notu: en ĉi tiu scenaro, la adreso sur haveno ovs-br1 ne estos alirebla ĉar ĝi ne havas vlan-etikedon. Por ripari ĉi tion, vi devas elsendi la komandon sudo ovs-vsctl set port ovs-br1 tag=100. Tamen, post rekomenco, ĉi tiu etikedo malaperos (se iu scias kiel igi ĝin resti surloke, mi estos tre dankema). Sed ĉi tio ne estas tiel grava, ĉar ni bezonos ĉi tiun adreson nur dum instalado kaj ne bezonos ĝin kiam Openstack estos plene deplojita.
Poste ni kreas subnuban maŝinon:
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=ttyS0Dum la instalado, vi agordas ĉiujn necesajn parametrojn, kiel la maŝinnomon, pasvortojn, uzantojn, ntp-servilojn ktp., vi povas tuj agordi la pordojn, sed por mi persone, post instalado, estas pli facile ensaluti en la maŝinon per la konzolo kaj korektu la necesajn dosierojn. Se vi jam havas pretan bildon, vi povas uzi ĝin, aŭ fari tion, kion mi faris - elŝutu la minimuman bildon de Centos 7 kaj uzu ĝin por instali la VM.
Post sukcesa instalado, vi devus havi virtualan maŝinon sur kiu vi povas instali subnubon
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningUnue, instalu la ilojn necesajn por la instala procezo:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Subnuba instalado
Ni kreas stakan uzanton, fiksas pasvorton, aldonas ĝin al sudoer kaj donas al li la kapablon ekzekuti radikajn komandojn per sudo sen devi enigi pasvorton:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNun ni specifas la plenan subnuban nomon en la gastiganta dosiero:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Poste, ni aldonas deponejojn kaj instalas la programaron, kiun ni bezonas:
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-ansibleNoto: se vi ne planas instali ceph, tiam vi ne bezonas enigi ceph-rilatajn komandojn. Mi uzis la Queens-eldonon, sed vi povas uzi ajnan alian, kiun vi ŝatas.
Poste, kopiu la subnuban agordan dosieron al la hejmdosierujo de la uzanto:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNun ni devas korekti ĉi tiun dosieron, ĝustigante ĝin al nia instalado.
Vi devas aldoni ĉi tiujn liniojn al la komenco de la dosiero:
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 = 10Do, ni trarigardu la agordojn:
subnubo_gastigantonomo — la plena nomo de la subnuba servilo, devas kongrui kun la eniro sur la DNS-servilo
loka_ip — loka subnuba adreso al reto-provizo
reto_enirejo — la sama loka adreso, kiu funkcios kiel enirejo por aliro al la ekstera mondo dum la instalado de tronubaj nodoj, ankaŭ koincidas kun loka ip
undercloud_public_host — ekstera API-adreso, ajna libera adreso de la provizanta reto estas asignita
undercloud_admin_host interna API-adreso, ajna libera adreso de la provizoreto estas asignita
undercloud_nameservers - DNS-servilo
generi_servon_atestilon - ĉi tiu linio estas tre grava en la nuna ekzemplo, ĉar se vi ne agordas ĝin al falsa, vi ricevos eraron dum instalado, la problemo estas priskribita en la cimspurilo de Red Hat.
loka_interfaco interfaco en retoprovizado. Ĉi tiu interfaco estos reagordita dum subnuba deplojo, do vi devas havi du interfacojn sur subnubo - unu por aliri ĝin, la dua por provizi.
loka_mtu — MTU. Ĉar ni havas testan laboratorion kaj mi havas MTU de 1500 sur la OVS-ŝaltilhavenoj, necesas agordi ĝin al 1450 por ke pakoj enkapsuligitaj en VxLAN povu trapasi.
reto_cidr — provizoreto
maskerado — uzante NAT por aliri eksteran reton
maskerado_reto - reto kiu estos NATigita
dhcp_start — la komenca adreso de la adresgrupo de kiu adresoj estos asignitaj al nodoj dum tronuba deplojo
dhcp_end — la fina adreso de la adresgrupo de kiu adresoj estos asignitaj al nodoj dum tronuba deplojo
inspection_iprange - aro da adresoj necesaj por introspekto (ne devus interkovri kun la supra naĝejo)
scheduler_max_attempts - maksimuma nombro da provoj instali tronubon (devas esti pli granda ol aŭ egala al la nombro da nodoj)
Post kiam la dosiero estas priskribita, vi povas doni la komandon por disfaldi subnubon:
openstack undercloud install
La procedo daŭras de 10 ĝis 30 minutoj depende de via fero. Finfine vi devus vidi eligon kiel ĉi tio:
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.
#############################################################################Ĉi tiu eligo diras, ke vi sukcese instalis subnubon kaj vi nun povas kontroli la staton de subnubo kaj daŭrigi instali supernubon.
Se vi rigardas la ifconfig-eligon, vi vidos, ke nova ponta interfaco aperis
[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 0Tronuba deplojo nun estos farita per ĉi tiu interfaco.
El la suba eligo vi povas vidi, ke ni havas ĉiujn servojn sur unu nodo:
(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 |
+--------------------------+-----------+----------+Malsupre estas la agordo de la subnuba retoparto:
(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 ~]$Supernuba instalado
Nuntempe ni havas nur subnubon, kaj ni ne havas sufiĉe da nodoj de kiuj supernubo estos kunvenita. Tial, antaŭ ĉio, ni disfaldi la virtualajn maŝinojn, kiujn ni bezonas. Dum la deplojo, subnubo mem instalos la OS kaj la necesan programaron sur la tronuba maŝino - tio estas, ni ne bezonas tute deploji la maŝinon, sed nur krei diskon (aŭ diskojn) por ĝi kaj determini ĝiajn parametrojn - tio estas , fakte, ni ricevas nudan servilon sen OS instalita sur ĝi.
Ni iru al la dosierujo kun la diskoj de niaj virtualaj maŝinoj kaj kreu diskojn de la bezonata grandeco:
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 160GĈar ni funkcias kiel radiko, ni devas ŝanĝi la posedanton de ĉi tiuj diskoj por ne havi problemon pri rajtoj:
[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]# Noto: se vi ne planas instali ceph por studi ĝin, tiam la ordonoj ne kreas almenaŭ 3 nodojn kun almenaŭ du diskoj, sed en la ŝablono indikas, ke virtualaj diskoj estos uzataj vda, vdb ktp.
Bonege, nun ni devas difini ĉiujn ĉi tiujn maŝinojn:
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 Fine estas komando -print-xml > /tmp/storage-1.xml, kiu kreas xml-dosieron kun priskribo de ĉiu maŝino en la dosierujo /tmp/; se vi ne aldonas ĝin, vi ne estos kapabla identigi virtualajn maŝinojn.
Nun ni devas difini ĉiujn ĉi tiujn maŝinojn en virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Nun malgranda nuanco - tripleO uzas IPMI por administri servilojn dum instalado kaj introspekto.
Introspekto estas la procezo de inspektado de la aparataro por akiri ĝiajn parametrojn necesajn por plia provizo de nodoj. Introspekto estas farita per ironia, servo desegnita por labori kun nudaj metalaj serviloj.
Sed jen la problemo - dum aparataj IPMI-serviloj havas apartan havenon (aŭ komunan havenon, sed ĉi tio ne gravas), tiam virtualaj maŝinoj ne havas tiajn havenojn. Ĉi tie venas nian helpon lambastonon nomata vbmc - ilo, kiu ebligas al vi kopii IPMI-havenon. Ĉi tiu nuanco indas atenti precipe por tiuj, kiuj volas starigi tian laboratorion sur ESXI-hiperviziero - sincere, mi ne scias ĉu ĝi havas analogon de vbmc, do indas demandi pri ĉi tiu afero antaŭ ol disfaldi ĉion. .
Instalu vbmc:
yum install yum install python2-virtualbmcSe via OS ne povas trovi la pakaĵon, tiam aldonu la deponejon:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNun ni starigis la ilon. Ĉio ĉi tie estas banala ĝis la punkto de malhonoro. Nun estas logike, ke ne estas serviloj en la vbmc-listo
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Por ke ili aperu, ili devas esti mane deklaritaj jene:
[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 ~]#Mi pensas, ke la komanda sintakso estas klara sen klarigo. Tamen, nuntempe ĉiuj niaj sesioj estas en DOWN statuso. Por ke ili moviĝu al UP statuso, vi devas ebligi ilin:
[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 ~]#Kaj la fina tuŝo - vi devas korekti la regulojn de fajroŝirmilo (aŭ tute malŝalti ĝin):
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
Nun ni iru al subnubo kaj kontrolu, ke ĉio funkcias. La adreso de la gastiga maŝino estas 192.168.255.200, sur subnubo ni aldonis la necesan ipmitool-pakaĵon dum preparo por deplojo:
[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 runningKiel vi povas vidi, ni sukcese lanĉis la kontrolnodon per vbmc. Nun ni malŝaltu ĝin kaj pluiru:
[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 ~]#La sekva paŝo estas introspekto de la nodoj sur kiuj supernubo estos instalita. Por fari tion, ni devas prepari json-dosieron kun priskribo de niaj nodoj. Bonvolu noti, ke, male al instalado sur nudaj serviloj, la dosiero indikas la pordon sur kiu vbmc funkcias por ĉiu maŝino.
[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:27Noto: la kontrolnodo havas du interfacojn, sed ĉi-kaze tio ne gravas, en ĉi tiu instalaĵo unu sufiĉos por ni.
Nun ni preparas la json-dosieron. Ni devas indiki la papavo-adreson de la haveno per kiu provizado estos efektivigita, la parametrojn de la nodoj, doni al ili nomojn kaj indiki kiel atingi ipmi:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Nun ni devas prepari bildojn por ironia. Por fari tion, elŝutu ilin per wget kaj instalu:
(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 ~]$Alŝuto de bildoj al subnubo:
(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 ~]$Kontrolante ke ĉiuj bildoj estas ŝargitaj
(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 ~]$Ankoraŭ unu afero - vi devas aldoni DNS-servilon:
(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 ~]$Nun ni povas doni la komandon por introspekto:
(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 ~]$Kiel vi povas vidi de la eligo, ĉio kompletigis sen eraroj. Ni kontrolu, ke ĉiuj nodoj estas en la disponebla stato:
(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 ~]$ Se la nodoj estas en malsama stato, kutime regebla, tiam io misfunkciis kaj vi devas rigardi la protokolon kaj ekscii kial tio okazis. Memoru, ke en ĉi tiu scenaro ni uzas virtualigon kaj povas esti cimoj asociitaj kun la uzo de virtualaj maŝinoj aŭ vbmc.
Poste, ni devas indiki, kiu nodo plenumos kiun funkcion - tio estas, indiki la profilon per kiu la nodo disfaldiĝos:
(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 ~]$Indiku la profilon por ĉiu nodo:
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-d9afb69d1167Ni kontrolu, ke ni faris ĉion ĝuste:
(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 ~]$Se ĉio estas ĝusta, ni donas la komandon por disfaldi supernubon:
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 qemuEn reala instalo, personecigitaj ŝablonoj nature estos uzataj, en nia kazo tio ege malfaciligos la procezon, ĉar ĉiu redakto en la ŝablono devos esti klarigita. Kiel estis skribita pli frue, eĉ simpla instalado sufiĉos por ke ni vidu kiel ĝi funkcias.
Notu: la --libvirt-type qemu variablo estas necesa en ĉi tiu kazo, ĉar ni uzos nestitan virtualigon. Alie, vi ne povos ruli virtualajn maŝinojn.
Nun vi havas ĉirkaŭ unu horon, aŭ eble pli (depende de la kapabloj de la aparataro) kaj vi povas nur esperi, ke post ĉi tiu tempo vi vidos la jenan mesaĝon:
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 ~]$Nun vi havas preskaŭ plenan version de openstack, sur kiu vi povas studi, eksperimenti ktp.
Ni kontrolu, ke ĉio funkcias ĝuste. En la hejmdosierujo de la uzanto estas du dosieroj - unu stackrc (por administri subnubon) kaj la dua overcloudrc (por administri tronubon). Ĉi tiuj dosieroj devas esti specifitaj kiel fonto, ĉar ili enhavas informojn necesajn por aŭtentigo.
(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 ~]$Mia instalado ankoraŭ postulas unu malgrandan tuŝon - aldoni itineron al la regilo, ĉar la maŝino kun kiu mi laboras estas en alia reto. Por fari tion, iru al control-1 sub la varmo-administra konto kaj registri la itineron
(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.254Nu, nun vi povas iri en la horizonton. Ĉiuj informoj - adresoj, ensaluto kaj pasvorto - estas en la dosiero /home/stack/overcloudrc. La fina diagramo aspektas jene:
Cetere, en nia instalado, maŝinadresoj estis elsenditaj per DHCP kaj, kiel vi povas vidi, ili estas elsenditaj "hazarde". Vi povas strikte difini en la ŝablono kiu adreso devas esti alkroĉita al kiu maŝino dum deplojo, se vi bezonas ĝin.
Kiel fluas trafiko inter virtualaj maŝinoj?
En ĉi tiu artikolo ni rigardos tri eblojn por preterpasi trafikon
- Du maŝinoj sur unu hiperviziero sur unu L2-reto
- Du maŝinoj sur malsamaj hiperviziiloj sur la sama L2-reto
- Du maŝinoj sur malsamaj retoj (interreta radikado)
Kazoj kun aliro al la ekstera mondo per ekstera reto, uzante flosajn adresojn, same kiel distribuitan enrutadon, ni konsideros venontfoje, nuntempe ni koncentriĝos pri interna trafiko.
Por kontroli, ni kunigu la sekvan diagramon:
Ni kreis 4 virtualajn maŝinojn - 3 sur unu L2-reto - net-1, kaj 1 pli sur la reto-2-reto
(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 ~]$ Ni vidu sur kiuj hiperviziiloj troviĝas la kreitaj maŝinoj:
(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 |
(supernubo) [stako@subnubo ~]$
Maŝinoj vm-1 kaj vm-3 situas sur compute-0, maŝinoj vm-2 kaj vm-4 situas sur nodo compute-1.
Krome, virtuala enkursigilo estis kreita por ebligi vojigon inter la specifitaj retoj:
(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 ~]$ La enkursigilo havas du virtualajn havenojn, kiuj funkcias kiel enirejoj por retoj:
(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 ~]$ Sed antaŭ ol ni rigardu kiel la trafiko fluas, ni rigardu, kion ni nuntempe havas sur la kontrolnodo (kiu ankaŭ estas reta nodo) kaj sur la komputa nodo. Ni komencu per la komputa nodo.
[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 ~]$Nuntempe, la nodo havas tri ov-pontojn - br-int, br-tun, br-ex. Inter ili, kiel ni vidas, estas aro da interfacoj. Por facileco de kompreno, ni grafiku ĉiujn ĉi tiujn interfacojn sur la diagramo kaj vidu kio okazas.
Rigardante la adresojn al kiuj VxLAN-tuneloj estas levitaj, oni povas vidi ke unu tunelo estas levita al komputi-1 (192.168.255.26), la dua tunelo rigardas al kontrolo-1 (192.168.255.15). Sed la plej interesa afero estas, ke br-ex ne havas fizikajn interfacojn, kaj se vi rigardas kiajn fluojn agordas, vi povas vidi, ke ĉi tiu ponto povas nur faligi trafikon nuntempe.
[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 ~]$ Kiel vi povas vidi el la eligo, la adreso estas ŝraŭbita rekte al la fizika haveno, kaj ne al la virtuala ponta interfaco.
[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 ~]$
Laŭ la unua regulo, ĉio, kio venis el la phy-br-ex-haveno, devas esti forĵetita.
Efektive, estas nuntempe nenie alie por trafiko veni en ĉi tiun ponton krom de ĉi tiu interfaco (la interfaco kun br-int), kaj se juĝante laŭ la gutoj, BUM-trafiko jam flugis en la ponton.
Tio estas, trafiko povas forlasi ĉi tiun nodon nur tra la tunelo VxLAN kaj nenio alia. Tamen, se vi ŝaltas la DVR, la situacio ŝanĝiĝos, sed ni traktos tion alian fojon. Kiam vi uzas retan izolitecon, ekzemple uzante vlanojn, vi havos ne unu L3-interfacon en vlan 0, sed plurajn interfacojn. Tamen, VxLAN-trafiko forlasos la nodon en la sama maniero, sed ankaŭ enkapsuligita en ia diligenta vlan.
Ni ordigis la komputan nodon, ni transiru al la kontrolnodo.
[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 ~]$Fakte, ni povas diri, ke ĉio estas la sama, sed la IP-adreso ne plu estas sur la fizika interfaco sed sur la virtuala ponto. Ĉi tio estas farita ĉar ĉi tiu haveno estas la haveno tra kiu trafiko eliros al la ekstera mondo.
[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 ~]$ Ĉi tiu haveno estas ligita al la br-ex-ponto kaj ĉar ne estas vlan-etikedoj sur ĝi, ĉi tiu haveno estas trunka haveno sur kiu ĉiuj vlan-oj estas permesitaj, nun trafiko iras eksteren sen etikedo, kiel indikite per vlan-id 0 en la eligo supre.
Ĉio alia nuntempe similas al la komputa nodo - la samaj pontoj, la samaj tuneloj iras al du komputa nodo.
Ni ne konsideros stokajn nodojn en ĉi tiu artikolo, sed por kompreni necesas diri, ke la retoparto de ĉi tiuj nodoj estas banala ĝis la punkto de malhonoro. En nia kazo, ekzistas nur unu fizika haveno (eth0) kun IP-adreso asignita al ĝi kaj jen ĝi. Ne estas VxLAN-tuneloj, tunelaj pontoj, ktp. - tute ne ekzistas ov, ĉar ne havas signifon en ĝi. Kiam vi uzas retan izolitecon, ĉi tiu nodo havos du interfacojn (fizikaj havenoj, bodny aŭ nur du vlanoj - ne gravas - dependas de tio, kion vi volas) - unu por administrado, la dua por trafiko (skribi al la VM-disko). , legado de disko, ktp.)
Ni eksciis, kion ni havas sur la nodoj sen iuj servoj. Nun ni lanĉu 4 virtualajn maŝinojn kaj vidu kiel ŝanĝiĝas la supre priskribita skemo - ni havu havenojn, virtualajn enkursigilojn ktp.
Ĝis nun nia reto aspektas jene:
Ni havas du virtualajn maŝinojn sur ĉiu komputila nodo. Uzante komputi-0 kiel ekzemplon, ni vidu kiel ĉio estas inkluzivita.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ La maŝino havas nur unu virtualan interfacon - 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 ~]$
Ĉi tiu interfaco aspektas en la linukso-ponto:
[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 ~]$ Kiel vi povas vidi el la eligo, estas nur du interfacoj en la ponto - tap95d96a75-a0 kaj qvb95d96a75-a0.
Ĉi tie indas iom resti pri la specoj de virtualaj retaj aparatoj en OpenStack:
vtap - virtuala interfaco alkroĉita al kazo (VM)
qbr - Linukso-ponto
qvb kaj qvo - vEth paro konektita al Linukso-ponto kaj Open vSwitch-ponto
br-int, br-tun, br-vlan — Malfermu vSwitch-pontojn
patch-, int-br-, phy-br- - Malfermu vSwitch-fakajn interfacojn ligantajn pontojn
qg, qr, ha, fg, sg - Malfermu vSwitch-havenojn uzatajn de virtualaj aparatoj por konekti al OVS
Kiel vi komprenas, se ni havas qvb95d96a75-a0 havenon en la ponto, kiu estas vEth-paro, tiam ie estas ĝia ekvivalento, kiu logike devus esti nomita qvo95d96a75-a0. Ni vidu, kiaj havenoj estas sur OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Kiel ni povas vidi, la haveno estas en br-int. Br-int funkcias kiel ŝaltilo kiu finas virtualajn maŝinajn havenojn. Krom qvo95d96a75-a0, la haveno qvo5bd37136-47 estas videbla en la eligo. Ĉi tiu estas la haveno al la dua virtuala maŝino. Kiel rezulto, nia diagramo nun aspektas jene:
Demando, kiu devus tuj interesi la atentan leganton - kio estas la linukso-ponto inter la virtuala maŝina haveno kaj la OVS-haveno? La fakto estas, ke por protekti la maŝinon oni uzas sekurecajn grupojn, kiuj estas nenio pli ol iptables. OVS ne funkcias kun iptables, do ĉi tiu "lambastono" estis inventita. Tamen, ĝi malnoviĝas - ĝi estas anstataŭigita per conntrack en novaj eldonoj.
Tio estas, finfine la skemo aspektas jene:
Du maŝinoj sur unu hiperviziero sur unu L2-reto
Ĉar ĉi tiuj du VM-oj situas sur la sama L2-reto kaj sur la sama hiperviziero, trafiko inter ili logike fluos loke tra br-int, ĉar ambaŭ maŝinoj estos sur la sama VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Du maŝinoj sur malsamaj hiperviziiloj sur la sama L2-reto
Nun ni vidu kiel la trafiko iros inter du maŝinoj sur la sama L2-reto, sed situanta sur malsamaj hiperviziiloj. Por esti honesta, nenio multe ŝanĝiĝos, nur trafiko inter hiperviziiloj trairos la vxlan tunelon. Ni rigardu ekzemplon.
Adresoj de virtualaj maŝinoj inter kiuj ni rigardos trafikon:
[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 ~]$ Ni rigardas la plusendan tabelon en br-int sur compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Trafiko devus iri al haveno 2 - ni vidu kia haveno ĝi estas:
[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 ~]$Ĉi tio estas patch-tun - tio estas la interfaco en br-tun. Ni vidu kio okazas al la pakaĵo sur br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ La pakaĵo estas pakita en VxLAN kaj sendita al la haveno 2. Ni vidu kien kondukas la haveno 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Ĉi tio estas vxlan tunelo sur komputo-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Ni iru al komputi-1 kaj vidu kio okazas poste kun la pako:
[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 estas en la br-int plusenda tabelo sur compute-1, kaj kiel povas esti vidita de la eligo supre, ĝi estas videbla tra haveno 2, kiu estas la haveno al br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Nu, tiam ni vidas, ke en br-int sur compute-1 estas cela papavo:
[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 ~]$ Tio estas, la ricevita pako flugos al haveno 3, malantaŭ kiu jam estas virtuala maŝino instance-00000003.
La beleco de deplojado de Openstack por lerni sur virtuala infrastrukturo estas ke ni povas facile kapti trafikon inter hiperviziiloj kaj vidi kio okazas kun ĝi. Jen kion ni faros nun, rulu tcpdump sur la vnet-haveno al compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************La unua linio montras, ke Patek de adreso 10.0.1.85 iras al adreso 10.0.1.88 (ICMP-trafiko), kaj ĝi estas envolvita en VxLAN-pako kun vni 22 kaj la pako iras de gastiganto 192.168.255.19 (komputilo-0) al gastiganto 192.168.255.26. .1 ( komputi-XNUMX). Ni povas kontroli, ke la VNI kongruas kun tiu specifita en ovs.
Ni revenu al ĉi tiu linio actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 estas vni en deksesuma nombrosistemo. Ni konvertu ĉi tiun nombron al la 16-a sistemo:
16 = 6*16^0+1*16^1 = 6+16 = 22Tio estas, vni respondas al realo.
La dua linio montras revenan trafikon, nu, ne utilas klarigi ĝin, ĉio estas klara tie.
Du maŝinoj sur malsamaj retoj (interreta vojigo)
La lasta kazo hodiaŭ estas vojigo inter retoj ene de unu projekto uzante virtualan enkursigilon. Ni pripensas kazon sen DVR (ni rigardos ĝin en alia artikolo), do vojigo okazas sur la retnodo. En nia kazo, la retnodo ne estas metita en apartan enton kaj situas sur la kontrolnodo.
Unue, ni vidu, ke vojigo funkcias:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msĈar en ĉi tiu kazo la pakaĵo devas iri al la enirejo kaj esti direktita tien, ni devas eltrovi la papav-adreson de la enirejo, por kiu ni rigardas la ARP-tabelon en la kazo:
$ 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 eth0Nun ni vidu kie la trafiko kun celo (10.0.1.254) fa:16:3e:c4:64:70 estu sendita:
[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 ~]$ Ni rigardu kien la haveno 2 kondukas:
[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 ~]$ Ĉio estas logika, trafiko iras al br-tun. Ni vidu en kiu vxlan tunelo ĝi estos envolvita:
[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 ~]$ La tria haveno estas vxlan tunelo:
[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 ~]$ Kiu rigardas la kontrolnodon:
[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 ~]$ La trafiko atingis la kontrolnodon, do ni devas iri al ĝi kaj vidi kiel vojigo okazos.
Kiel vi memoras, la kontrolnodo interne aspektis ekzakte la sama kiel la komputa nodo - la samaj tri pontoj, nur br-ex havis fizikan havenon tra kiu la nodo povis sendi trafikon eksteren. La kreado de petskriboj ŝanĝis la agordon sur la komputaj nodoj - linuksa ponto, iptables kaj interfacoj estis aldonitaj al la nodoj. La kreado de retoj kaj virtuala enkursigilo ankaŭ lasis sian markon sur la agordo de la kontrolnodo.
Do, estas evidente, ke la enirejo MAC-adreso devas esti en la br-int plusenda tabelo sur la kontrolnodo. Ni kontrolu, ke ĝi estas tie kaj kie ĝi serĉas:
[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 ~]$ La Mac estas videbla de haveno qr-0c52b15f-8f. Se ni revenas al la listo de virtualaj havenoj en Openstack, ĉi tiu tipo de haveno estas uzata por konekti diversajn virtualajn aparatojn al OVS. Por esti pli preciza, qr estas haveno al la virtuala enkursigilo, kiu estas reprezentita kiel nomspaco.
Ni vidu, kiaj nomspacoj estas sur la servilo:
[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 ~]$ Eĉ tri ekzempleroj. Sed juĝante laŭ la nomoj, vi povas diveni la celon de ĉiu el ili. Ni revenos al kazoj kun ID 0 kaj 1 poste, nun ni interesiĝas pri nomspaco qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Ĉi tiu nomspaco enhavas du internajn, kiujn ni kreis pli frue. Ambaŭ virtualaj havenoj estis aldonitaj al br-int. Ni kontrolu la mac-adreson de la haveno qr-0c52b15f-8f, ĉar la trafiko, juĝante laŭ la cel-mac-adreso, iris al ĉi tiu interfaco.
[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 ~]$ Tio estas, en ĉi tiu kazo, ĉio funkcias laŭ la leĝoj de norma vojigo. Ĉar la trafiko estas destinita por gastiganto 10.0.2.8, ĝi devas eliri tra la dua interfaco qr-92fa49b5-54 kaj iri tra la vxlan tunelo al la komputa nodo:
[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 ~]$ Ĉio estas logika, sen surprizoj. Ni vidu kie la papavo adreso de gastiganto 10.0.2.8 estas videbla en br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Kiel atendite, trafiko iras al br-tun, ni vidu en kiu tunelo iras la trafiko poste:
[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 ~]$ Trafiko iras en la tunelon por komputi-1. Nu, ĉe compute-1 ĉio estas simpla - de br-tun la pakaĵo iras al br-int kaj de tie al la virtuala maŝino interfaco:
[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 ~]$ Ni kontrolu, ke ĉi tio ja estas la ĝusta interfaco:
[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 ~]$
Efektive, ni trairis la tutan pakon. Mi pensas, ke vi rimarkis, ke la trafiko iris tra malsamaj vxlan-tuneloj kaj eliris per malsamaj VNIoj. Ni vidu kiaj VNI ĉi tiuj estas, post kio ni kolektos rubejon sur la kontrolhaveno de la nodo kaj certigos, ke la trafiko fluas ĝuste kiel priskribite supre.
Do, la tunelo por komputi-0 havas la jenajn agojn=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Ni konvertu 0x16 al la dekuma nombrosistemo:
0x16 = 6*16^0+1*16^1 = 6+16 = 22La tunelo por komputi-1 havas la jenan VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Ni konvertu 0x63 al la dekuma nombrosistemo:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Nu, nun ni rigardu la rubejon:
[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*******************La unua pakaĵeto estas vxlan-pako de gastiganto 192.168.255.19 (komputilo-0) ĝis gastiganto 192.168.255.15 (kontrolo-1) kun vni 22, ene de kiu ICMP-pako estas pakita de gastiganto 10.0.1.85 ĝis gastiganto 10.0.2.8. Kiel ni kalkulis supre, vni kongruas kun tio, kion ni vidis en la eligo.
La dua pako estas vxlan-pako de gastiganto 192.168.255.15 (kontrolo-1) ĝis gastiganto 192.168.255.26 (komputilo-1) kun vni 99, ene de kiu ICMP-pako estas pakita de gastiganto 10.0.1.85 ĝis gastiganto 10.0.2.8. Kiel ni kalkulis supre, vni kongruas kun tio, kion ni vidis en la eligo.
La sekvaj du pakoj estas reventrafiko de 10.0.2.8 ne 10.0.1.85.
Tio estas, finfine ni ricevis la sekvan kontrolnodan skemon:
Ŝajnas, ke tio estas? Ni forgesis pri du nomspacoj:
[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 ~]$ Ĉar ni parolis pri la arkitekturo de la nuba platformo, estus bone, se maŝinoj ricevus adresojn aŭtomate de DHCP-servilo. Ĉi tiuj estas du DHCP-serviloj por niaj du retoj 10.0.1.0/24 kaj 10.0.2.0/24.
Ni kontrolu, ke tio estas vera. Estas nur unu adreso en ĉi tiu nomspaco - 10.0.1.1 - la adreso de la DHCP-servilo mem, kaj ĝi ankaŭ estas inkluzivita en br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Ni vidu ĉu procezoj enhavantaj qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 en sia nomo sur la kontrolnodo:
[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 ~]$ Estas tia procezo kaj surbaze de la informoj prezentitaj en la supra eligo, ni povas, ekzemple, vidi kion ni nuntempe havas por luo:
[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 ~]$Kiel rezulto, ni ricevas la sekvan aron da servoj sur la kontrolnodo:
Nu, memoru - ĉi tio estas nur 4 maŝinoj, 2 internaj retoj kaj unu virtuala enkursigilo... Ni ne havas eksterajn retojn ĉi tie nun, amason da malsamaj projektoj, ĉiu kun siaj propraj retoj (interkovritaj), kaj ni havas distribuita enkursigilo malŝaltita, kaj finfine, estis nur unu kontrolnodo en la testbenko (por misfunkciado devas esti kvorumo de tri nodoj). Estas logike, ke en komerco ĉio estas “iom” pli komplika, sed en ĉi tiu simpla ekzemplo ni komprenas kiel ĝi devus funkcii - ĉu vi havas 3 aŭ 300 nomspacojn estas kompreneble grava, sed el la vidpunkto de la funkciado de la tutaĵo. strukturo, nenio multe ŝanĝiĝos... kvankam ĝis vi ne enŝovos iun vendiston SDN. Sed tio estas tute alia historio.
Mi esperas, ke ĝi estis interesa. Se vi havas komentojn/aldonojn, aŭ ie mi rekte mensogis (mi estas homo kaj mia opinio ĉiam estos subjektiva) - skribu tion, kion oni devas korekti/aldonu - ni korektos/aldonos ĉion.
Konklude, mi ŝatus diri kelkajn vortojn pri komparo de Openstack (kaj vanilo kaj vendisto) kun la nuba solvo de VMWare - oni demandis min tro ofte dum la pasintaj du jaroj kaj, sincere, mi estas jam tedas pri tio, sed tamen. Laŭ mi, estas tre malfacile kompari ĉi tiujn du solvojn, sed ni certe povas diri, ke estas malavantaĝoj en ambaŭ solvoj kaj elektante unu solvon vi devas pesi la avantaĝojn kaj malavantaĝojn.
Se OpenStack estas komunuma solvo, tiam VMWare havas la rajton fari nur tion, kion ĝi volas (legu - kio estas profita por ĝi) kaj tio estas logika - ĉar ĝi estas komerca kompanio, kiu kutimas gajni monon de siaj klientoj. Sed estas unu granda kaj dika SED - vi povas eliri OpenStack, ekzemple de Nokia, kaj kun malmulte da elspezo ŝanĝi al solvo de, ekzemple, Juniper (Contrail Cloud), sed vi verŝajne ne povos eltiri VMWare. . Por mi, ĉi tiuj du solvoj aspektas tiel - Openstack (vendisto) estas simpla kaĝo, en kiu vi estas metita, sed vi havas ŝlosilon kaj vi povas foriri kiam ajn. VMWare estas ora kaĝo, la posedanto havas la ŝlosilon al la kaĝo kaj ĝi kostos al vi multe.
Mi ne reklamas nek la unuan produkton nek la duan - vi elektas tion, kion vi bezonas. Sed se mi havus tian elekton, mi elektus ambaŭ solvojn - VMWare por la IT-nubo (malaltaj ŝarĝoj, facila administrado), OpenStack de iu vendisto (Nokia kaj Juniper provizas tre bonajn ŝlosilajn solvojn) - por la Telecom-nubo. Mi ne uzus Openstack por pura IT - ĝi estas kiel pafado de paseroj per kanono, sed mi ne vidas kontraŭindikiĝojn por uzi ĝin krom redundo. Tamen uzi VMWare en telekomunikado estas kiel transporti dispremitan ŝtonon en Ford Raptor - ĝi estas bela de ekstere, sed la ŝoforo devas fari 10 vojaĝojn anstataŭ unu.
Laŭ mi, la plej granda malavantaĝo de VMWare estas ĝia kompleta fermo - la firmao ne donos al vi ajnajn informojn pri kiel ĝi funkcias, ekzemple, vSAN aŭ kio estas en la hipervizila kerno - ĝi simple ne estas profita por ĝi - tio estas, vi faros. neniam fariĝu spertulo pri VMWare - sen vendisto-subteno, vi estas kondamnita (tre ofte mi renkontas spertulojn de VMWare, kiuj estas konfuzitaj de bagatelaj demandoj). Por mi, VMWare aĉetas aŭton kun la kapuĉo ŝlosita - jes, vi eble havas specialistojn, kiuj povas ŝanĝi la tempozonon, sed nur tiu, kiu vendis al vi ĉi tiun solvon, povas malfermi la kapuĉon. Persone, mi ne ŝatas solvojn, en kiuj mi ne povas konveni. Vi diros, ke vi eble ne devos iri sub la kapuĉo. Jes, ĉi tio eblas, sed mi rigardos vin kiam vi bezonos kunveni grandan funkcion en la nubo de 20-30 virtualaj maŝinoj, 40-50 retoj, el kiuj duono volas eliri eksteren, kaj la dua duono petas SR-IOV-akcelo, alie vi bezonos pli da kelkaj dekduoj da ĉi tiuj aŭtoj - alie la agado ne sufiĉos.
Estas aliaj vidpunktoj, do nur vi povas decidi kion elekti kaj, plej grave, vi tiam respondecos pri via elekto. Ĉi tio estas nur mia opinio - homo, kiu vidis kaj tuŝis almenaŭ 4 produktojn - Nokia, Juniper, Red Hat kaj VMWare. Tio estas, mi havas ion kun kio kompari.
fonto: www.habr.com