Cloud computing her ku diçe kûrtir û kûrtir dikeve nav jiyana me û belkî kesek tune ku bi kêmanî carekê karûbarên ewr bikar neaniye. Lêbelê, ewr bi rastî çi ye û ew çawa dixebite, hindik kes pê dizanin, tewra di asta ramanê de. 5G jixwe dibe rastiyek û binesaziya telekomê dest pê dike ku ji çareseriyên polê berbi çareseriyên ewr ve diçe, mîna ku dema ku ew ji çareseriyên bi tevahî hardware derbasî "stûnên" virtual bû.
Îro em ê li ser cîhana hundurîn a binesaziya ewr biaxivin, nemaze em ê li bingehên beşa torê binêrin.
Ewr çi ye? Heman virtualkirin - dîtina profîlê?
Ji pirsek mantiqî zêdetir. Na - ev ne virtualîzasyon e, her çend bêyî wê nekare were kirin. Ka em li du pênaseyan binêrin:
Cloud computing (li vir şûnda wekî Cloud tê binav kirin) modelek e ji bo peydakirina gihîştina bikarhêner-heval a çavkaniyên berhevkar ên belavkirî ku divê li gorî daxwazê bi derengiya herî hindiktirîn û lêçûnek hindiktirîn ji pêşkêşkerê karûbarê re were bicîh kirin û dest pê kirin.
Virtualization - ev şiyana dabeşkirina yek hebûna laşî (mînakî, serverek) li çend virtual e, bi vî rengî karanîna çavkaniyan zêde dike (mînak, we 3 pêşkêşkerên ji sedî 25-30 hatine barkirin, piştî virtualkirinê hûn 1 serverek tê barkirin ji sedî 80-90). Bi xwezayî, virtualbûn hin çavkaniyan dixwe - hûn hewce ne ku hîpervisorê bixwin, lêbelê, wekî pratîkê destnîşan kiriye, lîstik hêjayî mûmê ye. Nimûneyek îdeal a virtualkirinê VMWare ye, ku makîneyên virtual bi rengek bêkêmasî amade dike, an jî mînakî KVM, ku ez tercîh dikim, lê ev mijarek tamê ye.
Em virtualbûnê bêyî ku haya wan jê hebe, bikar tînin, û tewra rêwerên hesin jî jixwe virtualbûnê bikar tînin - mînakî, di guhertoya herî dawî ya JunOS de, pergala xebitandinê wekî makîneyek virtual li ser belavkirina Linux-ê ya rast-ê hatî saz kirin (Wind River 9). Lê virtualkirin ne ewr e, lê ewr bêyî virtualbûnê nabe.
Virtualîzasyon yek ji blokên avahiyê ye ku ewr li ser tê çêkirin.
Çêkirina ewr bi tenê komkirina çend hîpervisoran li yek domainek L2, lê zêdekirina çend pirtûkên lîstikê yên yaml ji bo tomarkirina bixweber vlanan bi navgînek celebek ansible û tevlihevkirina tiştek mîna pergalek orkestrasyonê li ser hemîyan ji bo afirandina otomatîkî makîneyên virtual dê nexebite. Ew ê rasttir be, lê Frankenstein encam ne ewrê ye ku em hewce ne, her çend dibe ku ew ji bo yên din xewna paşîn be. Wekî din, heke hûn heman Openstack-ê bigirin, ew bi bingehîn hîn jî Frankenstein e, lê oh baş e, bila ji bo niha li ser wê neaxivin.
Lê ez fêm dikim ku ji pênaseya ku li jor hatî pêşkêş kirin bi tevahî ne diyar e ku bi rastî çi dikare jê re ewr were gotin.
Ji ber vê yekê, belgeyek ji NIST (Enstîtuya Neteweyî ya Standard û Teknolojiyê) 5 taybetmendiyên sereke yên ku divê binesaziyek ewr hebe peyda dike:
Li ser daxwazê karûbarê peyda dike. Pêdivî ye ku bikarhêner ji çavkaniyên kompîturê yên ku jê re hatine veqetandin (wek torgilok, dîskên virtual, bîranîn, navgînên pêvajoyê, hwd.) belaş bigihîje, û divê ev çavkanî bixweber bêne peyda kirin - ango bêyî destwerdana pêşkêşvanê karûbarê.
Hebûna berfireh ya xizmetê. Pêdivî ye ku gihîştina çavkaniyan ji hêla mekanîzmayên standard ve were peyda kirin da ku hem PC-yên standard û hem jî xerîdarên zirav û cîhazên mobîl bikar bînin.
Bihevxistina çavkaniyan di hewzan de. Pêdivî ye ku hewzên çavkaniyê bikarin di heman demê de çavkaniyan ji gelek xerîdaran re peyda bikin, dabîn bikin ku xerîdar veqetandî ne û ji bandor û pêşbaziya hevdu ya ji bo çavkaniyan bêpar in. Tora di heman demê de di hewzê de hene, ku ev yek îhtîmala karanîna navnîşanên hevgirtî destnîşan dike. Pêdivî ye ku hewz li gorî daxwazê mezin bibin. Bikaranîna hewzan gengaz dike ku asta pêwîst a tolerasyona xeletiya çavkaniyê û jêbirina çavkaniyên laşî û virtual peyda bike - wergirê karûbarê bi tenê komek çavkaniyên ku wî xwestiye tê peyda kirin (ku van çavkaniyan bi fîzîkî li ku ne, li ser çend server û guhêrbar - ji xerîdar re ne girîng e). Lêbelê, divê em vê rastiyê bihesibînin ku pêşkêşker divê rezerva zelal a van çavkaniyan peyda bike.
Adaptasyona bilez a ji bo şert û mercên cûda. Pêdivî ye ku karûbar maqûl bin - peydakirina bilez a çavkaniyan, ji nû ve dabeşkirina wan, li gorî daxwaza xerîdar çavkaniyan zêde an kêm bikin, û ji hêla xerîdar ve divê hestek hebe ku çavkaniyên ewr bêdawî ne. Mînakî, ji bo hêsan têgihiştinê, hûn hişyariyek nabînin ku beşek ji cîhê dîska we di Apple iCloud de winda bûye ji ber ku dîska hişk a li ser serverê têk çûye, û ajoker têk diçin. Wekî din, ji hêla we ve, îmkanên vê karûbarê hema hema bêsînor in - hûn 2 TB hewce ne - pirsgirêk nîne, we ew drav kir û wergirt. Mînakek weha dikare bi Google.Drive an jî Yandex.Disk re were dayîn.
Ihtîmala pîvandina karûbarê pêşkêşkirî. Pêdivî ye ku pergalên ewr bixweber çavkaniyên serfkirî kontrol bikin û xweşbîn bikin, û divê ev mekanîzma hem ji bikarhêner û hem jî ji pêşkêşkarê karûbarê re zelal bin. Ango, hûn dikarin her gav kontrol bikin ka hûn û xerîdarên we çend çavkaniyan dixwin.
Hêjayî gotinê ye ku ev hewcedarî bi piranî hewcedariyên ewrek gelemperî ne, ji ber vê yekê ji bo ewrek taybet (ango ewrek ku ji bo hewcedariyên hundurê pargîdaniyê hatî destpêkirin), ev hewcedarî dikarin hinekî werin sererast kirin. Lêbelê, ew hîn jî divê bêne kirin, wekî din em ê hemî feydeyên hesabkirina ewr negirin.
Çima ji me re ewr divê?
Lêbelê, her teknolojiyek nû an heyî, her protokolek nû ji bo tiştek tê afirandin (baş, ji bilî RIP-ng, bê guman). Ji bo xatirê protokolê kesek hewceyê protokolê nake (bê guman, ji bilî RIP-ng). Mantiqî ye ku Cloud ji bo peydakirina cûreyek karûbar ji bikarhêner / xerîdar re hatî çêkirin. Em hemî bi kêmanî çend karûbarên ewr dizanin, mînakî Dropbox an Google.Docs, û ez bawer dikim ku pir kes wan bi serfirazî bikar tînin - mînakî, ev gotar bi karanîna karûbarê cloudê Google.Docs hatî nivîsandin. Lê karûbarên ewr ên ku em dizanin tenê beşek ji kapasîteyên ewr in - bi rastî, ew tenê karûbarek SaaS-ê ne. Em dikarin karûbarek ewr bi sê awayan peyda bikin: di forma SaaS, PaaS an IaaS de. Kîjan karûbarê ku hûn hewce ne bi daxwaz û şiyanên we ve girêdayî ye.
Ka em li her yekê bi rêzê binêrin:
Nermalav wekî Xizmetek (SaaS) modelek e ku karûbarek bêkêmasî ji xerîdar re peyda dike, mînakî, karûbarek e-nameyê wekî Yandex.Mail an Gmail. Di vê modela radestkirina karûbarê de, hûn, wekî xerîdar, bi rastî ji bilî karanîna karûbaran tiştek nakin - ango, hûn ne hewce ne ku hûn li ser sazkirina karûbar, tolerasyona xeletiyê an zêdebûna wê bifikirin. Ya sereke ev e ku hûn şîfreya xwe tawîz nedin; pêşkêşkarê vê karûbarê dê yên din ji we re bike. Ji nihêrîna dabînkerê karûbarê, ew bi tevahî ji karûbarê berpirsiyar e - ji hardware server û pergalên xebitandinê yên mêvandar bigire heya mîhengên databas û nermalavê.
Platform wekî Xizmetek (PaaS) - Dema ku vê modelê bikar tînin, pêşkêşkarê karûbar ji bo karûbarek karûbarek ji xerîdar re peyda dike, mînakî, em serverek Webê bigirin. Pêşkêşkarê karûbar serverek virtual ji xerîdar re peyda kir (bi rastî, komek çavkaniyan, wek RAM / CPU / Storage / Tor, hwd.), û tewra OS û nermalava pêwîst li ser vê serverê saz kir, lêbelê, veavakirina hemî ev tişt ji hêla xerîdar bi xwe ve têne kirin û ji bo performansa karûbarê xerîdar bersiv dide. Pêşkêşkarê karûbarê, wekî di doza berê de, ji performansa alavên laşî, hîpervisor, makîneya virtual bixwe, hebûna torê, hwd. berpirsiyar e, lê karûbar bixwe êdî ne di qada berpirsiyariya xwe de ye.
Binesaziya wekî Karûbarê (IaaS) - ev nêzîkatî jixwe balkêştir e, bi rastî, pêşkêşkarê karûbarê binesaziyek bêkêmasî ya virtual ji xerîdar re peyda dike - ango hin komek (hewzek) çavkaniyan, wek Corên CPU, RAM, Tora, hwd. xerîdar - ku xerîdar dixwaze bi van çavkaniyan di hundurê hewza (kota) ya veqetandî de çi bike - ew bi taybetî ji bo dabînkerê ne girîng e. Ma xerîdar dixwaze vEPC-ya xwe biafirîne an tewra operatorek piçûk biafirîne û karûbarên ragihandinê peyda bike - bê pirs - wiya bike. Di senaryoyek weha de, peydakerê karûbar berpirsiyar e ji peydakirina çavkaniyan, toleransa xeletî û hebûna wan, û her weha OS-ya ku rê dide wan ku van çavkaniyan berhev bikin û wan ji xerîdar re peyda bikin bi şiyana zêdekirin an kêmkirina çavkaniyan di her kêliyê de. li ser daxwaza muwekîlê. Xerîdar bi navgîniya portal û konsolê xwe-xizmetê, tevî sazkirina toran (ji bilî torên derveyî) hemî makîneyên virtual û tinselên din bixwe mîheng dike.
OpenStack çi ye?
Di her sê vebijarkan de, pêşkêşvanê karûbar hewceyê OS-ya ku dê çêkirina binesaziyek ewr çêbike hewce dike. Bi rastî, bi SaaS-ê re, ji yek beş zêdetir berpirsiyarê tevahiya stûna teknolojiyên - dabeşek heye ku berpirsiyarê binesaziyê ye - ango, ew IaaS ji dabeşek din re peyda dike, ev dabeş SaaS ji xerîdar re peyda dike. OpenStack yek ji pergalên xebitandinê yên ewr e ku dihêle hûn komek guhêrbar, server û pergalên hilanînê li hewzek çavkaniyek yekane kom bikin, vê hewza hevpar li jêrpool (kirêdar) veqetînin û van çavkaniyan li ser torê ji xerîdaran re peyda bikin.
OpenStack pergalek xebitandinê ewr e ku dihêle hûn hewzên mezin ên çavkaniyên hesabkirinê, hilanîna daneyê û çavkaniyên torê kontrol bikin, ku bi navgîniya API-yê ve bi karanîna mekanîzmayên pejirandina standard ve têne peyda kirin û rêvebirin.
Bi gotinek din, ev komek projeyên nermalava belaş e ku ji bo afirandina karûbarên cloudê (hem gelemperî û taybet) hatine sêwirandin - ango komek amûran e ku dihêle hûn server û alavan biguhezînin nav hewzek çavkaniyan de, rêvebirin. van çavkaniyan, asta pêwîst a tolerasyona xeletiyê peyda dikin.
Di dema nivîsandina vê materyalê de, avahiya OpenStack bi vî rengî xuya dike:
Wêne ji hatî girtin
Her yek ji hêmanên ku di OpenStack de cih digirin fonksiyonek taybetî pêk tîne. Ev mîmariya belavkirî dihêle hûn di çareseriyê de komek pêkhateyên fonksiyonel ên ku hûn hewce ne bikin. Lêbelê, hin pêkhate hêmanên root in û rakirina wan dê bibe sedema bêkêmasî an jî qismî ya çareseriyê bi tevahî. Van pêkhateyan bi gelemperî wekî têne dabeş kirin:
- Rojhan - GUI-based Web-ê ji bo birêvebirina karûbarên OpenStack
- Keystone karûbarek nasnameyê ya navendî ye ku ji bo karûbarên din fonksiyonên erêkirin û destûrnameyê peyda dike, û hem jî pêbaweriyên bikarhêner û rola wan birêve dibe.
- Neutron - karûbarek torê ya ku pêwendiyê di navbera navberên karûbarên cihêreng ên OpenStack de peyda dike (tevî girêdana di navbera VM û gihîştina wan a cîhana derve de)
- Cinder - gihîştina astengkirina hilanînê ji bo makîneyên virtual peyda dike
- Nova - rêveberiya çerxa jiyanê ya makîneyên virtual
- Nerîn - depoya wêne û dîmenên makîneya virtual
- Swift - gihîştina tiştê hilanînê peyda dike
- Ceilometer - karûbarek ku şiyana berhevkirina telemetrî û pîvandina çavkaniyên berdest û xerckirî peyda dike
- Germa - orkestrasyona li ser bingeha şablonan ji bo afirandina otomatîk û peydakirina çavkaniyan
Navnîşek bêkêmasî ya hemî projeyan û armanca wan dikare were dîtin .
Her pêkhateyek OpenStack karûbarek e ku fonksiyonek taybetî pêk tîne û API-yek peyda dike da ku wê fonksiyonê birêve bibe û bi karûbarên din ên pergala xebitandina cloud re têkilî daynin da ku binesaziyek yekgirtî biafirînin. Mînakî, Nova ji bo gihandina mîhengkirina van çavkaniyan rêveberiya çavkaniya hesabker û API peyda dike, Glance rêveberiya wêneyê û API-yek ji bo birêvebirina wan peyda dike, Cinder hilanîna blokê û API-yek ji bo birêvebirina wê peyda dike, hwd. Hemî fonksiyon bi rengek pir nêzîk bi hev ve girêdayî ne.
Lêbelê, heke hûn lê mêze bikin, hemî karûbarên ku di OpenStack-ê de têne xebitandin di dawiyê de celebek makîneya virtual (an konteynir) bi torê ve girêdayî ne. Pirs derdikeve holê - çima em hewqas hêmanan hewce ne?
Ka em ji algorîtmaya afirandina makîneyek virtual û girêdana wê bi torê û hilanîna domdar a li Openstack re derbas bibin.
- Dema ku hûn daxwazek ji bo afirandina makîneyek diafirînin, ew daxwazek bi navgîniya Horizon (Dashboard) be an daxwazek bi navgîniya CLI-yê be, yekem tiştê ku diqewime destûrdana daxwaza we ya li ser Keystone ye - hûn dikarin makîneyek biafirînin, gelo ew heye? mafê bikaranîna vê torê, pêşnûmeya kotaya we dike, hwd.
- Keystone daxwaza we piştrast dike û di peyama bersivê de nîşanek rastdariyê çêdike, ku dê bêtir were bikar anîn. Piştî ku bersivek ji Keystone wergirt, daxwaz ji Nova (nova api) re tê şandin.
- Nova-api rastdariya daxwaza we kontrol dike û bi Keystone re têkilî bi karanîna tokena destûrnameyê ya berê hatî hilberandin re dike.
- Keystone erêkirinê pêk tîne û li ser bingeha vê nîşana destûrnameyê agahdarî li ser destûr û qedexeyan peyda dike.
- Nova-api ji bo VM-ya nû di nova-databasê de têketinek diafirîne û daxwaza çêkirina makîneyê ji nova-scheduler re derbas dike.
- Nova-scheduler mêvandarê (girêka komputerê) ya ku VM-ê li ser wê were bicîh kirin li gorî pîvan, giranî û deverên diyarkirî hildibijêre. Qeydek vê û VM ID-ê li nova-databasê têne nivîsandin.
- Dûv re, nova-scheduler bi daxwazek ji bo bicîhkirina mînakek bi nova-computer re têkilî dike. Nova-compute bi nova-conductor re têkilî dike da ku agahdariya li ser parametreyên makîneyê werbigire (nova-conductor hêmanek nova ye ku wekî serverek proxy di navbera databasa nova û nova-compute de tevdigere, hejmara daxwazan li databasa nova sînordar dike da ku pirsgirêkên bi databasê re nebin. kêmkirina barkirina hevgirtî).
- Nova-conductor agahdariya daxwazkirî ji nova-databasê distîne û ji nova-compute re derbas dike.
- Dûv re, nova-compute gazî nihêrînek dike ku nasnameya wêneyê bistîne. Glace daxwaza li Keystone rast dike û agahdariya daxwazkirî vedigerîne.
- Nova-kompîter bi neutronê re têkilî daynin da ku agahdariya li ser pîvanên torê bistînin. Mîna nihêrînê, neutron daxwazê li Keystone piştrast dike, piştî ku ew têketinek di databasê de çêdike (nasnameya portê, hwd.), daxwazek ji bo afirandina portek diafirîne, û agahdariya daxwazkirî vedigerîne nova-compute.
- Têkiliyên Nova-computer bi daxwaza veqetandina cildekê ji makîneya virtual re vediqetin. Mîna nihêrînê, cider daxwazê li Keystone rast dike, daxwazek çêkirina cildê diafirîne, û agahdariya daxwazkirî vedigerîne.
- Têkiliyên Nova-compute libvirt bi daxwazek ku makîneyek virtual bi pîvanên diyarkirî vebikin.
Di rastiyê de, operasyonek xuya ya hêsan a afirandina makîneyek virtual ya hêsan di navbera hêmanên platforma ewr de vediguhere dorhêlek wusa bangên API. Wekî din, wekî ku hûn dibînin, tewra karûbarên ku berê hatine destnîşan kirin jî ji hêmanên piçûktir ên ku di navbera wan de têkilî çêdibe jî pêk tê. Afirandina makîneyek tenê beşek piçûk e ji tiştê ku platforma ewr destûrê dide we - karûbarek heye ku berpirsiyarê hevsengkirina seyrûseferê ye, karûbarek ji hilanîna blokê berpirsiyar e, karûbarek ji DNS-ê berpirsiyar e, karûbarek ku ji peydakirina serverên metalê yên tazî berpirsiyar e, hwd. Ewr destûrê dide te ku divê hûn makîneyên xwe yên virtual wekî keriyek pez (bervajî virtualbûnê) bikin. Ger tiştek bi makîneya we re di hawîrdorek virtual de diqewime - hûn wê ji paşvekişandinê, hwd vegerînin, lê serîlêdanên ewr bi vî rengî têne çêkirin ku makîneya virtual rolek wusa girîng neleyze - makîneya virtual "mir" - pirsgirêk nîne - Wesayîtek nû hatî çêkirin, wesayît li ser bingeha şablonê hatî çêkirin û, wekî ku dibêjin, tîm ferqê windabûna şervan nekir. Bi xwezayî, ev hebûna mekanîzmayên orkestrasyonê peyda dike - bi karanîna şablonên Heat, hûn dikarin bi hêsanî fonksiyonek tevlihev a ku ji bi dehan toran û makîneyên virtual pêk tê bicîh bikin.
Her gav hêja ye ku ji bîr mekin ku binesaziya ewr bêyî torgilok tune - her hêman bi rengek an din bi hêmanên din re bi navgîniya torê re têkildar dibe. Wekî din, ewr xwedan torgilokek bêkêmasî ne-statîk e. Bi xwezayî, tora binavê hêj kêm-zêde statîk e - girêk û guhêrbarên nû her roj nayên zêdekirin, lê hêmana pêvekirî dikare û bi neçarî bi domdarî biguhezîne - torên nû dê werin zêdekirin an jêbirin, makîneyên nû yên virtual dê xuya bibin û yên kevin dê mirin. Û wekî ku hûn ji pênaseya ewr a ku di destpêka gotarê de hatî dayîn bi bîr tînin, pêdivî ye ku çavkanî bixweber û bi kêmtirîn (an çêtir hîn, bêyî) destwerdana pêşkêşvanê karûbar ji bikarhêner re bêne veqetandin. Ango, celebê peydakirina çavkaniyên torê ku naha di forma pêş-endê de heye di forma hesabê weya kesane de ku bi riya http/https ve tê gihîştin û endezyarê torê yê peywirdar Vasily wekî paşverû ne ewr e, hetta eger Vasily heşt destên.
Neutron, wekî karûbarek torê, ji bo birêvebirina beşa torê ya binesaziya ewr API peyda dike. Karûbar bi peydakirina qatek abstraksiyonê ya bi navê Network-as-a-Service (NaaS) beşa torê ya Openstack hêzdar dike û rêve dibe. Ango, torê heman yekîneya pîvandî ya virtual e ku, mînakî, korikên CPU-ya virtual an mîqdara RAM-ê ye.
Lê berî ku em biçin ser mîmariya beşa torê ya OpenStack, em bifikirin ka ev tora di OpenStack de çawa dixebite û çima torgilok beşek girîng û yekbûyî ya ewr e.
Ji ber vê yekê me du VM-yên xerîdar RED û du VM-yên xerîdar ên KESK hene. Ka em bihesibînin ku ev makîneyên bi vî rengî li ser du hîpervisoran cih digirin:
Heya nuha, ev tenê virtualkirina 4 pêşkêşkeran e û ne tiştek din e, ji ber ku heya nuha tiştê ku me kiriye virtual 4 server e, ku wan li ser du serverên fizîkî danîne. Û heta niha ew bi torê ve jî ne girêdayî ne.
Ji bo çêkirina ewr, pêdivî ye ku em çend pêkhateyan lê zêde bikin. Pêşîn, em beşa torê virtual dikin - pêdivî ye ku em van 4 makîneyan bi cotan ve girêdin, û xerîdar pêwendiyek L2 dixwazin. Hûn dikarin guhêrbarek bikar bînin û qurmek di rêça wê de mîheng bikin û her tiştî bi karanîna pirek linux an, ji bo bikarhênerên pêşkeftîtir, openvswitch çareser bikin (em ê paşê vegerin ser vê). Lê dibe ku gelek torgilok hebin, û bi domdarî xistina L2 bi navgînek veguheztinê ne ramana çêtirîn e - beşên cihêreng, maseyek karûbarê, mehan li benda qedandina serîlêdanek, hefteyên çareserkirina pirsgirêkan hene - di cîhana nûjen de ev nêzîkatî êdî kar nake. Û her ku zûtirîn pargîdaniyek vê yekê fêm dike, ew qas hêsantir e ku ew pêşve biçe. Ji ber vê yekê, di navbera hîpervisoran de em ê torgilokek L3 hilbijêrin ku tê de makîneyên meyên virtual dê bi hev re têkilî daynin, û li ser vê tora L3-ê em ê torên pêvekirî yên L2 yên virtual ku dê seyrûsefera makîneyên meyên virtual lê bimeşînin ava bikin. Hûn dikarin GRE, Geneve an VxLAN wekî encapsulation bikar bînin. Ka em ji bo niha li ser ya paşîn bisekinin, her çend ew bi taybetî ne girîng e.
Pêdivî ye ku em li cîhek VTEP-ê bi cih bikin (Ez hêvî dikim ku her kes bi termînolojiya VxLAN-ê nas e). Ji ber ku me torgilokek L3 rasterast ji pêşkêşkeran tê, tiştek me nahêle ku em VTEP-ê li ser serveran bixwe bi cîh bikin, û OVS (OpenvSwitch) di kirina vê yekê de hêja ye. Di encamê de, me ev sêwirandin wergirt:
Ji ber ku seyrûsefera di navbera VM-an de divê were dabeş kirin, portên berbi makîneyên virtual dê xwedî hejmarên vlan ên cihê bin. Hejmara tagê tenê di nav yek veguheztina virtual de rolekê dilîze, ji ber ku dema ku di VxLAN-ê de tê vegirtin em dikarin bi hêsanî jêbirin, ji ber ku em ê xwedî VNI bin.
Naha em dikarin makîneyên xwe û torên virtual ji wan re bê pirsgirêk biafirînin.
Lêbelê, heke xerîdar makîneyek din hebe, lê li ser tora cûda ye? Pêdiviya me bi rootkirina di navbera toran de heye. Em ê li vebijarkek hêsan binihêrin dema ku rêwîtiya navendîkirî were bikar anîn - ango, seyrûsefer di nav girêkên torê yên taybetî yên taybetî de têne rêve kirin (baş, wekî qaîdeyek, ew bi girêkên kontrolê re têne hev kirin, ji ber vê yekê em ê heman tişt hebin).
Wusa dixuye ku tiştek tevlihev nîne - em li ser girêka kontrolê têkiliyek pirê çêdikin, seyrûseferê ber bi wê ve dimeşînin û ji wir jî em wê li cîhê ku jê re hewce dike rêve dibin. Lê pirsgirêk ev e ku xerîdar RED dixwaze tora 10.0.0.0/24 bikar bîne, û xerîdar GREEN dixwaze tora 10.0.0.0/24 bikar bîne. Ango, em dest bi hevberkirina cîhên navnîşan dikin. Digel vê yekê, xerîdar naxwazin ku xerîdarên din nikaribin bikevin nav torên xwe yên hundurîn, ku watedar e. Ji bo veqetandina toran û seyrûsefera daneya xerîdar, em ê ji bo her yek ji wan navek cihê veqetînin. Cihê navan di rastiyê de kopiyek stûna torê ya Linux-ê ye, ango, xerîdarên li qada navan RED bi tevahî ji xerîdarên qada navan GREEN têne veqetandin (baş e, an rêvekirina di navbera van torên xerîdar de bi navgîniya navên xwerû an jî li ser alavên veguheztina jorîn destûr tê dayîn).
Ango em diagrama jêrîn digirin:
Tunelên L2 ji hemî girêkên hesabkirinê berbi girêka kontrolê ve diçin. girêka ku pêwendiya L3 ji bo van toran lê ye, her yek ji bo veqetandinê di nav cîhek taybetî de ye.
Lêbelê, me ya herî girîng ji bîr kir. Pêdivî ye ku makîneya virtual karûbarek ji xerîdar re peyda bike, ango, divê bi kêmanî yek pêwendiyek derveyî hebe ku tê de were gihîştin. Yanî divê em derkevin derve. Li vir vebijarkên cuda hene. Ka em vebijarka herî hêsan bikin. Em ê yek torê li her xerîdar zêde bikin, ku dê di tora pêşkêşker de derbasdar be û dê bi torên din re nekeve hev. Tora di heman demê de dikarin bi hev veqetînin û li VRF-yên cihêreng ên li tenişta tora pêşkêşker binihêrin. Daneyên torê jî dê di nav cîhê her xerîdar de bijî. Lêbelê, ew ê dîsa jî bi navgîniyek laşî (an girêdan, ku mentiqîtir e) derkevin cîhana derve. Ji bo veqetandina seyrûsefera xerîdar, seyrûsefera ku diçe derve dê bi etîketek VLAN ku ji xerîdar re hatî veqetandin were nîşankirin.
Di encamê de, me ev diagram girt:
Pirsek maqûl ev e ku çima xwe li ser girêkên hesabkirinê derwazeyan çê nakin? Ev ne pirsgirêkek mezin e; Wekî din, heke hûn routerê belavkirî (DVR) vekin, ew ê bixebite. Di vê senaryoyê de, em vebijarka herî hêsan a bi dergehek navendîparêz, ku ji hêla xwerû ve di Openstack de tê bikar anîn, dihesibînin. Ji bo fonksiyonên bargiraniyê, ew ê hem routerek belavkirî û teknolojiyên bilezkirinê yên wekî SR-IOV û Passthrough bikar bînin, lê wekî ku ew dibêjin, ew çîrokek bi tevahî cûda ye. Pêşî, em bi beşa bingehîn re mijûl bibin, û paşê em ê biçin nav hûrguliyan.
Bi rastî, pilana me jixwe kar e, lê çend nuwaze hene:
- Pêdivî ye ku em bi rengek makîneyên xwe biparêzin, ango, parzûnek li ser navbeynkariya guheztinê berbi xerîdar ve bikin.
- Vê gengaz bikin ku makîneyek virtual bixweber navnîşek IP-yê bistîne, da ku hûn ne hewce ne ku her carê bi navgîniya konsolê têkevin wê û navnîşan tomar bikin.
Ka em bi parastina makîneyê dest pê bikin. Ji bo vê yekê hûn dikarin iptablesên banal bikar bînin, çima na.
Ango, naha topolojiya me hinekî tevlihevtir bûye:
Werin em herin. Pêdivî ye ku em serverek DHCP zêde bikin. Cihê herî îdeal ji bo peydakirina serverên DHCP-ê ji bo her xerîdar dê girêk kontrolê be ku berê li jor hatî behs kirin, ku cîhên navan lê ne:
Lêbelê, pirsgirêkek piçûk heye. Ger her tişt ji nû ve dest pê bike û hemî agahdariya li ser kirêkirina navnîşanên li ser DHCP winda bibe. Mantiqî ye ku dê navnîşanên nû ji makîneyan re werin dayîn, ku ne pir rehet e. Li vir du rê hene - an navên domainê bikar bînin û ji bo her xerîdar serverek DNS-ê lê zêde bikin, wê hingê navnîş dê ji me re bi taybetî ne girîng be (wek beşa torê ya di k8s de) - lê di torên derveyî de pirsgirêkek heye, ji ber ku navnîşan jî dikarin bi navgîniya DHCP-ê ve di wan de bêne derxistin - hûn hewce ne ku bi serverên DNS-ê yên di platforma cloudê û serverek DNS-ya derveyî re hevdeng bikin, ku bi dîtina min ne pir maqûl e, lê pir gengaz e. An vebijarka duyemîn ev e ku meriv metadata bikar bîne - ango, agahdariya li ser navnîşana ku ji makîneyê re hatî derxistin hilîne da ku servera DHCP zanibe ku heke makîneyê berê navnîşek wergirtibe dê kîjan navnîşan bide makîneyê. Vebijarka duyemîn hêsantir û maqûltir e, ji ber ku ew dihêle hûn agahdariya zêde di derbarê gerîdeyê de hilînin. Naha em metadata ajanê li diagramê zêde bikin:
Pirsgirêkek din a ku di heman demê de hêjayî nîqaşê ye, şiyana karanîna yek tora derveyî ji hêla hemî xerîdar ve ye, ji ber ku torgilokên derveyî, heke divê ew li seranserê tevaya torê derbasdar bin, dê dijwar be - hûn hewce ne ku bi domdarî dabeşkirina van toran veqetînin û kontrol bikin. Hêza karanîna torgilokek derveyî ya pêş-sazkirî ya ji bo hemî xerîdar dê di dema afirandina ewrek gelemperî de pir bikêr be. Ev ê bicîhkirina makîneyan hêsantir bike ji ber ku ne hewce ye ku em bi databasek navnîşan şêwir bikin û ji bo tora derveyî ya her xerîdar cîhek navnîşek bêhempa hilbijêrin. Wekî din, em dikarin di pêş de torgilokek derveyî tomar bikin û di dema bicîhkirinê de em ê tenê hewce ne ku navnîşanên derveyî bi makîneyên xerîdar re têkildar bikin.
Û li vir NAT tê alîkariya me - em ê tenê mimkun bikin ku xerîdar bi karanîna wergera NAT-ê bi navgîniya navên xwerû bigihîjin cîhana derve. Belê, li vir pirsgirêkek piçûk heye. Ev baş e ger servera xerîdar wekî xerîdar û ne wekî serverek tevbigere - ango, ew ji bilî pejirandina girêdanan dest pê dike. Lê ji bo me ew ê berevajî be. Di vê rewşê de, pêdivî ye ku em NAT-ya armancê bikin da ku dema ku seyrûseferê werdigire, girêk kontrolê fam dike ku ev seyrûsefer ji bo makîneya virtual A ya xerîdar A tête armanc kirin, ku tê vê wateyê ku em hewce ne ku wergerek NAT ji navnîşek derveyî bikin, mînakî 100.1.1.1. .10.0.0.1, ji navnîşana navxweyî 100. Di vê rewşê de, her çend hemî xerîdar dê heman torê bikar bînin, îzolasyona hundurîn bi tevahî tê parastin. Ango divê em dNAT û sNAT li ser girêka kontrolê bikin. Ma hûn torgilokek yekane bi navnîşanên pêvekirî an torên derveyî bikar bînin, an her du yekcar, bi tiştê ku hûn dixwazin têxin nav ewr ve girêdayî ye. Em ê navnîşanên herikîn li diagramê zêde nekin, lê em ê torên derveyî yên ku berê hatine zêdekirin bihêlin - her xerîdar tora xweya derveyî heye (di diagramê de ew wekî vlan 200 û XNUMX li ser pêwendiya derveyî têne destnîşan kirin).
Wekî encamek, me çareseriyek balkêş û di heman demê de baş-hizirkirî wergirt, ku xwedan nermbûnek diyar e lê hîna mekanîzmayên tolerasyona xeletiyê tune.
Ya yekem, me tenê yek nodek kontrolê heye - têkçûna wê dê bibe sedema hilweşîna hemî pergalan. Ji bo rastkirina vê pirsgirêkê, hûn hewce ne ku bi kêmî ve 3 girêkan çêkin. Ka em vê li diagramê zêde bikin:
Bi xwezayî, hemî girêk hevdem in û dema ku girêkek çalak derkeve, girêkek din dê berpirsiyariyên wê bigire ser xwe.
Pirsgirêka din dîskên makîneya virtual e. Heya nuha, ew bixwe li ser hîpervisoran têne hilanîn, û di bûyera pirsgirêkên bi hypervisor re, em hemî daneyan winda dikin - û hebûna serdegirtinê dê li vir ne alîkar be heke em ne dîskê, lê tevahiya serverê winda bikin. Ji bo vê yekê, pêdivî ye ku em karûbarek çêbikin ku dê wekî dawiya pêşîn ji bo celebek hilanînê tevbigere. Ew ê çi celeb hilanîn be ji bo me ne girîng e, lê divê ew daneyên me ji têkçûna dîskê û nodê, û dibe ku tevahiya kabîneyê biparêze. Li vir gelek vebijark hene - bê guman, torên SAN bi Kanala Fiber re hene, lê em rast bin - FC jixwe bermayek paşerojê ye - di veguheztinê de analogek E1 - erê, ez qebûl dikim, ew hîn jî tê bikar anîn, lê tenê li cihê ku bêyî wê bi tevahî ne gengaz e. Ji ber vê yekê, ez ê di sala 2020-an de bi dilxwazî torgilokek FC-ê bi cih nekim, zanibim ku alternatîfên din ên balkêştir hene. Her çend ji her yekê ya xwe re, dibe ku yên bawer dikin ku FC digel hemî sînorên xwe tenê hewcedariya me ye - ez ê nîqaş nekim, her kes nêrîna xwe heye. Lêbelê, çareseriya herî balkêş li gorî min karanîna SDS-ê ye, wekî Ceph.
Ceph dihêle hûn bi komek vebijarkên hilanînê yên muhtemel re çareseriyek hilanîna daneya pir berdest ava bikin, bi kodên bi kontrolkirina hevsengiyê dest pê bikin (mîna êrîşa 5 an 6-an) û bi vekirina daneya tevahî li ser dîskên cihêreng bi dawî bibe, li gorî cîhê dîskên li pêşkêşker, û pêşkêşkerên di kabîneyan de, û hwd.
Ji bo avakirina Ceph hûn hewceyê 3 girêkên din in. Têkiliya bi hilanînê re jî dê bi riya torê ve bi karanîna karûbarên hilanîna blok, tişt û pelan were kirin. Ka em hilanînê li schemayê zêde bikin:
Nîşe: hûn dikarin girêkên hesabker ên hîperconverged jî çêbikin - ev têgîna berhevkirina çend fonksiyonan li ser yek girêk e - mînakî, hilanîn+hejmar - bêyî veqetandina girêkên taybetî ji bo hilanîna ceph. Em ê heman pilana xelet-toleransê bistînin - ji ber ku SDS dê daneyan bi asta veqetandinê ya ku em destnîşan dikin veqetîne. Lêbelê, girêkên hyperconverged her gav lihevhatinek in - ji ber ku girêka hilanînê ne tenê hewayê germ dike ku di nihêrîna pêşîn de xuya dike (ji ber ku makîneyên virtual li ser tune ne) - ew çavkaniyên CPU li ser karûbarê SDS-ê xerc dike (bi rastî, ew hemî dike dubarekirin û vejandina piştî têkçûna nod, dîskan, hwd.). Ango, heke hûn wê bi hilanînê re bikin yek, hûn ê hin hêza girêka hesabkirinê winda bikin.
Pêdivî ye ku ev hemî tişt bi rengekî were rêvebirin - hewcedariya me bi tiştek heye ku em bikarin makîneyek, torgilokek, rêwerek virtual û hwd biafirînin. xerîdar dê bikaribe bi vê portalê bi http/ https ve girêbide û her tiştê ku ew hewce dike bike (baş, hema hema).
Wekî encamek, me niha sîstemek xelet-tolerans heye. Divê hemû hêmanên vê binesaziyê bi awayekî bên birêvebirin. Berê hate diyar kirin ku Openstack komek projeyan e, ku her yek ji wan fonksiyonek taybetî peyda dike. Wekî ku em dibînin, ji têra xwe hêmanên ku divê bêne mîheng kirin û kontrol kirin hene. Îro em ê li ser beşa torê biaxivin.
Mîmariya Neutron
Di OpenStack de, ew Neutron e ku berpirsiyar e ku portên makîneya virtual bi tora L2-ya hevpar ve girêbide, rêça trafîkê di navbera VM-yên ku li ser torên cihêreng ên L2-ê de ne, û her weha rêvekirina derveyî, peydakirina karûbarên wekî NAT, IP-ya Floating, DHCP, hwd.
Di astek bilind de, xebata karûbarê torê (beşa bingehîn) dikare wekî jêrîn were vegotin.
Dema ku VM dest pê dike, karûbarê torê:
- Ji bo VM-yek (an port) benderek diafirîne û li ser wê karûbarê DHCP agahdar dike;
- Amûrek torê ya virtual ya nû tê afirandin (bi rêya libvirt);
- VM bi port(yên) ku di gava 1-ê de hatî çêkirin ve girêdide;
Pir ecêb e, xebata Neutron li ser bingeha mekanîzmayên standard ên ku ji her kesê ku berê xwe da Linuxê nas dikin - cîhên navan, iptables, pirên linux, openvswitch, conntrack, hwd.
Divê tavilê were zelal kirin ku Neutron ne kontrolkerek SDN ye.
Neutron ji çend hêmanên bi hev ve girêdayî pêk tê:
Openstack-neutron-server Daemonek e ku bi daxwazên bikarhêner bi navgîniya API-yê re dixebite. Ev cin di qeydkirina girêdanên torê de ne beşdar e, lê ji bo vê yekê agahdariya pêwîst ji pêvekên xwe re peyda dike, ku dûv re hêmana torê ya xwestî mîheng dike. Nûnerên Neutron ên li ser girêkên OpenStack bi servera Neutron re qeyd dikin.
Neutron-server bi rastî serîlêdanek e ku di python de hatî nivîsandin, ji du beşan pêk tê:
- xizmeta REST
- Pêveka Neutron (navend / karûbar)
Karûbarê REST ji bo wergirtina bangên API-ê ji pêkhateyên din hatî çêkirin (mînak, daxwazek ji bo peydakirina hin agahdarî, hwd.)
Plugin hêmanên nermalavê / modulên pêvekirî ne ku di dema daxwazên API-ê de têne gazî kirin - ango, veqetandina karûbarek bi wan re pêk tê. Plugin li du celeb têne dabeş kirin - karûbar û root. Wekî qaîdeyek, pêveka hespê bi giranî ji birêvebirina cîhê navnîşan û girêdanên L2 di navbera VM-an de berpirsiyar e, û pêvekên karûbarê berê fonksiyonên din ên wekî VPN an FW peyda dikin.
Navnîşa pêvekên ku îro têne peyda kirin dikare wekî mînak were dîtin
Dibe ku çend pêvekên karûbarê hebin, lê tenê pêvekek hespê dikare hebe.
openstack-neutron-ml2 pêveka root ya Openstack standard e. Vê pêvekê xwedan mîmariyek modular e (berevajî ya berê) û karûbarê torê bi navgîniya ajokarên ku pê ve girêdayî ye mîheng dike. Em ê hinekî paşê li pêvekê binihêrin, ji ber ku di rastiyê de ew nermbûna ku OpenStack di beşa torê de heye dide. Pêveka root dikare were guheztin (mînakek, Contrail Networking veguherînek wusa dike).
Karûbarê RPC (server-rabbitmq) - karûbarek ku rêveberiya rêzê û danûstendina bi karûbarên din ên OpenStack re, û her weha danûstendina di navbera ajanên karûbarê torê de peyda dike.
ajanên Network - ajanên ku di her girêkê de cih digirin, bi navgîniya ku karûbarên torê têne mîheng kirin.
Çend cureyên ajanan hene.
Nûnerê sereke ye nûnerê L2. Van nûneran li ser her yek ji hîpervisoran dimeşînin, di nav de girêkên kontrolê (bi rastî, li ser hemî girêkên ku karûbarek ji bo kirêdaran peyda dikin) û fonksiyona wan a sereke girêdana makîneyên virtual bi tora L2 ya hevpar re ye, û her weha gava ku bûyerek çêdibe hişyariyan çêbike ( Mînak portê neçalak bike/çalak bike).
Ajanê din, ne kêmtir girîng e nûnerê L3. Bi xwerû, ev ajan bi taybetî li ser girêkek torê dimeşe (pir caran girêka torê bi girêkek kontrolê re tê hev kirin) û rêgezê di navbera torên kirêdar de peyda dike (hem di navbera torên wê û torên kirêdarên din de, û ji cîhana derve re peyda dibe, peyda dike. NAT, û her weha karûbarê DHCP). Lêbelê, dema ku DVR (rûterek belavkirî) bikar tîne, hewcedariya pêvekek L3 jî li ser girêkên hesabkirinê xuya dike.
Nûnerê L3 navên navên Linux bikar tîne da ku ji her kirêdar re komek torên xwe yên veqetandî û fonksiyona rêgezên virtual ku seyrûseferê rêve dikin û karûbarên dergehê ji bo torên Layer 2 peyda dikin peyda bike.
Database - databasek nasnavên torê, subnet, port, hewz, hwd.
Di rastiyê de, Neutron daxwazên API-ê yên ji afirandina sazûmanên torê qebûl dike, daxwazê rast dike, û bi riya RPC (heke ew bigihîje hin pêvek an nûnerê) an REST API (eger ew di SDN-ê de danûstendinê) ji nûneran re (bi rêya pêvekan) veguhezîne. talîmatên ku ji bo organîzekirina karûbarê daxwazkirî hewce ne.
Naha em werin ser sazkirina ceribandinê (ew çawa tête bicîh kirin û çi tê de ye, em ê paşê di beşa pratîkî de bibînin) û bibînin ku her pêkhateyek li ku ye:
(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 ~]$
Bi rastî, ew tevahiya avahiya Neutronê ye. Naha ew hêja ye ku hin dem li ser pêveka ML2 derbas bikin.
Layera Modular 2
Wekî ku li jor behs kir, pêvek pêvekek bingehîn a OpenStack-ê ya standard e û xwedan mîmariyek modular e.
Pêşengê pêveka ML2 xwedan avahiyek monolîtîk bû, ku rê neda, mînakî, karanîna tevliheviya çend teknolojiyên di yek sazkirinê de. Mînakî, hûn nekarin hem openvswitch û hem jî linuxbridge di heman demê de bikar bînin - ya yekem an ya duyemîn. Ji ber vê yekê, pêveka ML2 bi mîmariya xwe ve hate afirandin.
ML2 du hêman hene - du celeb ajoker: ajokarên tîp û ajokarên Mekanîzmê.
ajokarên Type teknolojiyên ku dê ji bo organîzekirina girêdanên torê werin bikar anîn destnîşan bikin, mînakî VxLAN, VLAN, GRE. Di heman demê de, ajoker destûrê dide ku teknolojiyên cûda bikar bînin. Teknolojiya standard ji bo torên sergirtî û torên derveyî yên vlan vegirtinê VxLAN e.
Ajokarên tîpan celebên torê yên jêrîn hene:
mal - tora bêyî nîşankirinê
VLANs - tora nîşankirî
Herêmî - celebek torê ya taybetî ya ji bo sazkirinên hemî-yek-yek (sazkirinên weha ji bo pêşdebiran an jî ji bo perwerdehiyê hewce ne)
GRE - tora dorpêçkirinê bi karanîna tunelên GRE
VxLAN - tora sergirtî bi karanîna tunelên VxLAN
ajokarên mekanîzmaya Amûrên ku rêxistina teknolojiyên ku di ajokera celebê de hatine destnîşan kirin piştrast dikin - wek nimûne, openvswitch, sr-iov, opendaylight, OVN, hwd.
Bi pêkanîna vê ajokerê ve girêdayî, dê an ajanên ku ji hêla Neutron ve têne kontrol kirin werin bikar anîn, an jî dê girêdanên bi kontrolkerek SDN-ya derveyî ve werin bikar anîn, ku hemî pirsgirêkên têkildarî organîzekirina torên L2, rêkirin, hwd.
Mînak: heke em ML2 bi OVS re bi kar bînin, wê hingê li ser her girêka hesabkerê ku OVS-ê birêve dibe, karmendek L2 tê saz kirin. Lêbelê, heke em, mînakî, OVN an OpenDayLight bikar bînin, wê hingê kontrola OVS dikeve bin daraza wan - Neutron, bi navgîniya pêveka root, fermanan dide kontrolkerê, û ew jixwe tiştê ku jê re hatî gotin dike.
Ka em li ser Open vSwitch firçe bikin
Heya nuha, yek ji hêmanên sereke yên OpenStack Open vSwitch e.
Dema ku OpenStack bêyî SDN-ya firoşkarê zêde wekî Juniper Contrail an Nokia Nuage saz dike, OVS hêmana torê ya sereke ya tora ewr e û, digel iptables, conntrack, navên navan, dihêle hûn torên pir-kirêdar ên bêkêmasî organîze bikin. Bi xwezayî, ev hêman dikare were guheztin, mînakî, dema ku çareseriyên SDN-ê yên xwedan (firoşkar) yên sêyemîn bikar tînin.
OVS veguhezek nermalava çavkaniyek vekirî ye ku ji bo karanîna di hawîrdorên virtualkirî de wekî pêşnumayek seyrûsefera virtual hatî çêkirin.
Heya nuha, OVS xwedan fonksiyonek pir maqûl e, ku teknolojiyên wekî QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, hwd.
Nîşe: OVS di destpêkê de ji bo fonksiyonên têlefonê yên pir barkirî wekî guhezek nerm nehate fikirîn û bêtir ji bo fonksiyonên IT-ê yên kêm-daxwaza band-ê wekî servera WEB an servera e-nameyê hatî sêwirandin. Lêbelê, OVS hîn pêşdetir tê pêşve xistin û pêkanînên heyî yên OVS performans û kapasîteyên wê pir çêtir kirine, ku dihêle ku ew ji hêla operatorên telekomê ve bi fonksiyonên pir barkirî ve were bikar anîn, mînakî, pêkanîna OVS-ê bi piştgirîya bilezkirina DPDK heye.
Sê hêmanên girîng ên OVS hene ku hûn hewce ne ku ji wan haydar bin:
- Modula Kernel - pêkhateyek ku di cîhê kernelê de ye ku li ser bingeha rêgezên ku ji hêmana kontrolê hatine wergirtin seyrûseferê dike;
- vSwitch daemon (ovs-vswitchd) pêvajoyek e ku di cîhê bikarhêner de hatî destpêkirin ku berpirsiyarê bernamekirina modula kernelê ye - ango, ew rasterast mantiqa xebata guhêrbar temsîl dike.
- server Database - databasek herêmî ya ku li ser her mêvandarê ku OVS-ê dimeşîne, ku veavakirin tê de tête hilanîn. Kontrolkerên SDN dikarin bi vê modulê bi protokola OVSDB re têkilî daynin.
Hemî ev bi komek karûbarên tespîtkirin û rêvebirinê re, wekî ovs-vsctl, ovs-appctl, ovs-ofctl, hwd.
Heya nuha, Openstack bi berfirehî ji hêla operatorên telekomê ve tê bikar anîn da ku fonksiyonên torê biguhezîne wê, wek EPC, SBC, HLR, hwd. Hin fonksiyon dikarin bêyî pirsgirêk bi OVS re wekî ku bijîn, lê mînakî, EPC seyrûsefera aboneyan pêvajoyê dike - paşê ew di nav de derbas dibe. hejmareke mezin a seyrûseferê (naha qebareya trafîkê digihîje çend sed gigabit per second). Bi xwezayî, ajotina seyrûsefera wusa di nav cîhê kernelê de (ji ber ku şander ji hêla xwerû li wir e) ne ramana çêtirîn e. Ji ber vê yekê, OVS bi gelemperî bi tevahî li cîhê bikarhênerê bi karanîna teknolojiya bilezkirina DPDK-ê tête bicîh kirin da ku seyrûsefera ji NIC berbi cîhê bikarhênerê bi derbaskirina kernelê ve bişîne.
Nîşe: ji bo ewrek ku ji bo fonksiyonên telekomê hatî bicîh kirin, mimkun e ku meriv seyrûseferê ji girêkek hesabkerî derxe ku rasterast OVS-ê ji alavên veguheztinê re derbas dike. Ji bo vê armancê mekanîzmayên SR-IOV û Passthrough têne bikar anîn.
Ev li ser nexşeyek rastîn çawa dixebite?
Belê, naha em biçin beşa pratîkî û bibînin ka ew hemî di pratîkê de çawa dixebite.
Pêşîn, werin em sazkirinek Openstack-a hêsan saz bikin. Ji ber ku ji bo ceribandinan komek serverek li ber destê min tune, em ê prototîpa li ser yek serverek fîzîkî ji makîneyên virtual berhev bikin. Erê, bi xwezayî, çareseriyek wusa ji bo mebestên bazirganî ne maqûl e, lê ji bo dîtina mînakek çawa torê li Openstack dixebite, sazkirinek wusa ji çavan re bes e. Wekî din, sazkirinek wusa ji bo mebestên perwerdehiyê hîn balkêştir e - ji ber ku hûn dikarin seyrûseferê bigirin, hwd.
Ji ber ku em tenê hewce ne ku beşa bingehîn bibînin, em nekarin çend toran bikar bînin lê her tiştî bi karanîna du toran ve bilind bikin, û tora duyemîn di vê sêwiranê de dê bi taybetî ji bo gihîştina servera binerd û DNS were bikar anîn. Em ê heya niha dest nedin torên derveyî - ev mijarek ji bo gotarek mezin a cihê ye.
Ji ber vê yekê, em bi rêzê dest pê bikin. Pêşîn, teoriyek piçûk. Em ê Openstack bi karanîna TripleO saz bikin (Openstack li ser Openstack). Esasê TripleO ev e ku em Openstack-ê hemî-di-yek saz dikin (ango, li ser yek girêk), ku jê re undercloud tê gotin, û dûv re jî kapasîteyên Openstack-a hatî veqetandin bikar tînin da ku Openstack-ê ku ji bo xebatê hatî armanc kirin saz bikin, ku jê re overcloud tê gotin. Undercloud dê kapasîteya xweya xwerû ya birêvebirina serverên laşî (metalê tazî) - projeya Ironic - bikar bîne da ku hîpervisoran peyda bike ku dê rolên girêkên hesabkirin, kontrol, hilanînê pêk bînin. Ango, em tu amûrên sêyemîn bikar neynin ku Openstack-ê bicîh bikin - em Openstack-ê bi karanîna Openstack-ê saz dikin. Ew ê her ku sazkirinê pêşve diçe pir zelaltir bibe, ji ber vê yekê em ê li wir nesekinin û pêşde biçin.
Nîşe: Di vê gotarê de, ji bo sadebûnê, min îzolekirina torê ji bo torên Openstack-ê yên hundurîn bikar neanî, lê her tişt bi tenê yek torê bikar tîne. Lêbelê, hebûn an nebûna veqetandina torê bandorê li fonksiyona bingehîn a çareseriyê nake - dê her tişt tam eynî mîna dema ku veqetandinê bikar tîne bixebite, lê seyrûsefer dê li ser heman torê biherike. Ji bo sazkirinek bazirganî, bi xwezayî pêdivî ye ku meriv îzolasyonê bi karanîna vlan û navgînên cihêreng bikar bîne. Mînakî, seyrûsefera rêveberiya hilanînê ya ceph û seyrûsefera daneyê bixwe (gihîştina makîneyê ya dîskê, hwd.) dema ku were veqetandin, jêrtorên cihêreng bikar tînin (Rêveberiya hilanînê û hilanînê) û ev dihêle hûn bi dabeşkirina vê seyrûseferê çareserî bi xeletîtir bikin, mînakî , li ser portên cihêreng, an jî profîlên QoS yên cihêreng ji bo seyrûsefera cihêreng bikar tînin da ku seyrûsefera daneyê seyrûsefera îşaretkirinê qut neke. Di doza me de, ew ê li ser heman torê biçin û di rastiyê de ev me bi ti awayî sînor nake.
Nîşe: Ji ber ku em ê makîneyên virtual li hawîrdorek virtual li ser bingeha makîneyên virtual bimeşînin, pêşî hewce ye ku em virtualbûna hêlîn çalak bikin.
Hûn dikarin bi vî rengî kontrol bikin ka virtualbûna hêlîn çalak e an na:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ger hûn tîpa N-yê bibînin, wê hingê em li gorî her rêberek ku hûn li ser torê dibînin, piştgirî ji bo virtualkirina hêlîn çalak dikin, mînakî .
Pêdivî ye ku em çerxa jêrîn ji makîneyên virtual berhev bikin:
Di doza min de, ji bo girêdana makîneyên virtual ku beşek ji sazkirina paşerojê ne (û min 7 ji wan girt, lê hûn dikarin bi 4-an bi dest bixin ger çavkaniyên we pir nebin), min OpenvSwitch bikar anî. Min pira yek ovs afirand û makîneyên virtual bi nav-grûbên portê ve pê ve girêda. Ji bo vê yekê, min pelek xml bi vî rengî çêkir:
[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>Sê komên portê li vir têne ragihandin - du gihîştin û yek trunk (ya paşîn ji bo servera DNS-ê hewce bû, lê hûn dikarin bêyî wê bikin, an jî wê li ser makîneya mêvandar saz bikin - ya ku ji we re hêsantir e). Dûv re, bi karanîna vê şablonê, em bi riya virsh net-define ya xwe eşkere dikin:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Naha em mîhengên porta hypervisor biguherînin:
[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 ~]# Nîşe: Di vê senaryoyê de, navnîşana li ser port ovs-br1 dê negihîje ji ber ku wê tagek vlan tune. Ji bo rastkirina vê, hûn hewce ne ku emrê sudo ovs-vsctl set port ovs-br1 tag=100 derxînin. Lêbelê, piştî rebootkirinê, ev etîket dê winda bibe (heke kes zanibe ka meriv wê çawa di cîh de bimîne, ez ê pir spasdar bim). Lê ev ne ew qas girîng e, ji ber ku em ê tenê di dema sazkirinê de hewcedarê vê navnîşanê bin û dema ku Openstack bi tevahî were bicîh kirin dê hewce nebe.
Dûv re, em makîneyek binerdê diafirînin:
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=ttyS0Di dema sazkirinê de, hûn hemî pîvanên pêwîst destnîşan dikin, wek navê makîneyê, şîfre, bikarhêner, pêşkêşkerên ntp, û hwd., hûn dikarin tavilê benderan mîheng bikin, lê ji bo min bixwe, piştî sazkirinê, hêsantir e ku meriv bi navgîniya makîneyê têkevin. konsolê û pelên pêwîst rast bikin. Ger we jixwe wêneyek amadekirî heye, hûn dikarin wê bikar bînin, an tiştê ku min kiriye bikin - wêneya herî kêm Centos 7 dakêşin û wê bikar bînin da ku VM-ê saz bikin.
Piştî sazkirina serketî, pêdivî ye ku hûn makîneyek virtual hebe ku hûn dikarin li binê cloudê saz bikin
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningPêşîn, amûrên ku ji bo pêvajoya sazkirinê hewce ne saz bikin:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Sazkirina Undercloud
Em bikarhênerek stackê diafirînin, şîfreyek saz dikin, wê li sudoer zêde dikin û jê re şansê didin ku bi sudo fermanên root bicîh bike bêyî ku şîfreyek têxe:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNaha em di pelê mêvandar de navê tevahî undercloud diyar dikin:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Dûv re, em depoyan lê zêde dikin û nermalava ku em hewce ne saz dikin:
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-ansibleNîşe: Heke hûn ne plan dikin ku ceph saz bikin, wê hingê hûn ne hewce ne ku emrên girêdayî ceph-ê têkevin. Min serbestberdana Queens bikar anî, lê hûn dikarin her kesê ku hûn dixwazin bikar bînin.
Dûv re, pelê veavakirina undercloud li staka pelrêça malê ya bikarhêner kopî bikin:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNaha pêdivî ye ku em vê pelê rast bikin, li ser sazkirina xwe eyar bikin.
Pêdivî ye ku hûn van rêzan li destpêka pelê zêde bikin:
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 = 10Ji ber vê yekê, em bi mîhengan re derbas bibin:
undercloud_hostname - Navê tevahî ya servera binê cloudê, pêdivî ye ku têketina li ser servera DNS-ê li hev bike
local_ip - Navnîşana bin cloudê ya herêmî ber bi peydakirina torê ve
network_gateway - heman navnîşana herêmî, ya ku dê di dema sazkirina girêkên overcloud de wekî dergehek ji bo gihîştina cîhana derve tevbigere, di heman demê de bi ip-ya herêmî re hevaheng e.
undercloud_public_host - Navnîşana API-ya derveyî, her navnîşek belaş ji tora peydakirinê tê destnîşan kirin
undercloud_admin_host navnîşana API-ya hundurîn, her navnîşek belaş ji tora peydakirinê tê destnîşan kirin
undercloud_nameservers - Pêşkêşkara DNS
generate_service_certificate - ev rêz di mînaka heyî de pir girîng e, ji ber ku heke hûn wê li ser xelet nexin hûn ê di dema sazkirinê de xeletiyek bistînin, pirsgirêk li ser şopînera xeletiya Red Hat tê vegotin
navbeynkariya_ herêmî navbeynkar di peydakirina torê de. Ev navbeynkar dê di dema bicîhkirina bin cloudê de ji nû ve were mîheng kirin, ji ber vê yekê hûn hewce ne ku du navbeynkariya li ser bin cloudê hebin - yek ji bo gihîştina wê, ya duyemîn ji bo peydakirinê
local_mtu - MTU. Ji ber ku me laboratûvarek ceribandinê heye û li ser portên guheztina OVS-ya min MTU-ya 1500 heye, pêdivî ye ku ew li 1450-ê were danîn da ku pakêtên ku di VxLAN-ê de hatine girtin bikarin derbas bibin.
network_cidr - tora dabînkirinê
masquerade - NAT-ê bikar bînin ku bigihîjin torgilokek derveyî
masquerade_network - tora ku dê bibe NATE
dhcp_start - Navnîşana destpêkê ya hewza navnîşan a ku ji wê navnîşan dê di dema belavkirina overcloud de ji nokan re werin veqetandin
dhcp_end - Navnîşana paşîn a hewza navnîşan a ku navnîşan jê dê di dema birêkûpêkkirina overcloud de ji nokan re werin veqetandin
inspection_iprange - komek navnîşanên ku ji bo hundurînbûnê hewce ne (divê ku bi hewza jorîn re li hev nekeve)
scheduler_max_attempts - Hejmara herî zêde ya hewildanên ji bo sazkirina overcloud (divê ji hejmara girêkan mezintir an wekhev be)
Piştî ku pel hate şirove kirin, hûn dikarin fermanê bidin ku di bin cloudê de bicîh bikin:
openstack undercloud install
Pêvajo li gorî hesinê we ji 10 heta 30 hûrdeman digire. Di dawiyê de divê hûn encamek weha bibînin:
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.
#############################################################################Ev encam dibêje ku we bi serfirazî undercloud saz kiriye û hûn naha dikarin rewşa undercloud kontrol bikin û dest bi sazkirina overcloud bikin.
Ger hûn li derana ifconfig binêrin, hûn ê bibînin ku navgînek pira nû xuya bûye
[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 0Rakirina Overcloud dê naha bi navgîniya vê navberê ve were kirin.
Ji derana jêrîn hûn dikarin bibînin ku em hemî karûbar li ser yek girêk hene:
(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 |
+--------------------------+-----------+----------+Li jêr veavakirina beşa torê ya bin cloudê ye:
(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 ~]$Sazkirina Overcloud
Heya nuha tenê me bi binê cloudê heye, û têra me girêkên ku dê ji wan overcloud werin berhev kirin tune ne. Ji ber vê yekê, berî her tiştî, werin em makîneyên virtual yên ku em hewce ne bicîh bikin. Di dema bicîhkirinê de, undercloud bixwe dê OS û nermalava pêwîst li ser makîneya overcloud saz bike - ango, ne hewce ye ku em makîneyê bi tevahî bicîh bikin, lê tenê ji bo wê dîskek (an dîskek) biafirînin û pîvanên wê diyar bikin - yanî , bi rastî, em serverek tazî bêyî OS-ya ku li ser hatî saz kirin distînin.
Ka em biçin peldanka bi dîskên makîneyên xwe yên virtual û dîskên bi mezinahiya pêwîst biafirînin:
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 160GJi ber ku em wekî root dixebitin, pêdivî ye ku em xwediyê van dîskan biguhezînin da ku pirsgirêkek bi mafan re çênebe:
[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]# Nîşe: Heke hûn ne plan dikin ku ceph saz bikin da ku hûn wê bixwînin, wê hingê ferman bi kêmî ve du dîskan bi kêmî ve 3 girêkan naafirînin, lê di şablonê de destnîşan dikin ku dê dîskên virtual vda, vdb, hwd werin bikar anîn.
Baş e, naha divê em van hemî makîneyan diyar bikin:
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 Di dawiyê de fermanek -print-xml> /tmp/storage-1.xml heye, ku pelek xml bi ravekirina her makîneyê di peldanka /tmp/ de çêdike; heke hûn lê zêde nekin, hûn ê nebin. dikarin makîneyên virtual nas bikin.
Naha divê em van hemî makîneyan bi virsh diyar bikin:
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 ~]#Naha nuwazeyek piçûk - tripleO IPMI bikar tîne da ku di dema sazkirinê û hundurîn de serveran birêve bibe.
Introspection pêvajoyek teftîşkirina hardware ye ji bo bidestxistina parametreyên wê yên ku ji bo peydakirina bêtir girêkan hewce ne. Introspection bi karanîna îronîkî, karûbarek ku ji bo xebitandina serverên metalê yên tazî hatî çêkirin, tête kirin.
Lê pirsgirêk li vir e - dema ku serverên IPMI-ya hardware xwedan portek veqetandî ne (an portek hevpar, lê ev ne girîng e), wê hingê makîneyên virtual xwedan portên weha ne. Li vir kevçîyek bi navê vbmc tê alîkariya me - karûbarek ku dihêle hûn portek IPMI-ê mîna hev bikin. Bi taybetî ji bo kesên ku dixwazin laboratûvarek weha li ser hîpervisorek ESXI saz bikin hêja ye ku meriv bala xwe bide vê nuwazeyê - bi rastî, ez nizanim gelo wê analogek vbmc heye, ji ber vê yekê hêja ye ku berî ku her tiştî bişopîne li ser vê mijarê meraq bike. .
Vbmc saz bikin:
yum install yum install python2-virtualbmcGer OS-ya we nikaribe pakêtê bibîne, wê hingê depoyê lê zêde bike:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNiha em karûbar saz kirin. Li vir her tişt heta bi rezîliyê banal e. Naha mentiqî ye ku di navnîşa vbmc de serverek tune
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Ji bo ku ew xuya bibin, divê ew bi vî rengî bi destan werin ragihandin:
[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 ~]#Ez difikirim ku hevoksaziya fermanê bêyî ravekirin zelal e. Lêbelê, heya niha hemî danişînên me di statûya DOWN de ne. Ji bo ku ew derbasî rewşa UP-ê bibin, hûn hewce ne ku wan çalak bikin:
[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 ~]#Û pêwendiya dawîn - hûn hewce ne ku qaîdeyên dîwarê rast bikin (an jî bi tevahî neçalak bikin):
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
Naha em biçin bin cloudê û kontrol bikin ku her tişt dixebite. Navnîşana makîneya mêvandar 192.168.255.200 e, li ser undercloud me di dema amadekariyê de pakêta ipmitool-a pêwîst lê zêde kir:
[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 runningWekî ku hûn dibînin, me bi serfirazî girêka kontrolê bi rêya vbmc ve dest pê kiriye. Naha em wê vemirînin û bimeşin:
[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 ~]#Pêngava paşîn vekolîna girêkên ku dê overcloud li ser were saz kirin e. Ji bo vê yekê, pêdivî ye ku em pelek json bi ravekirina girêkên xwe amade bikin. Ji kerema xwe not bikin ku, berevajî sazkirinê li ser serverên tazî, pel porta ku vbmc ji bo her makîneyê tê xebitandin destnîşan dike.
[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:27Nîşe: girêka kontrolê du navber hene, lê di vê rewşê de ev ne girîng e, di vê sazkirinê de yek dê ji me re bes be.
Niha em pelê json amade dikin. Pêdivî ye ku em navnîşana poppy ya portê ku tê de dê peyda kirin, pîvanên girêkan destnîşan bikin, navên wan bidin û destnîşan bikin ka meriv çawa bigihîje 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"
}
]
}Naha divê em wêneyan ji bo îronîkî amade bikin. Ji bo vê yekê, wan bi wget dakêşin û saz bikin:
(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 ~]$Barkirina wêneyan li binê cloudê:
(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 ~]$Kontrol kirin ku hemî wêne hatine barkirin
(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 ~]$Tiştek din - hûn hewce ne ku serverek DNS zêde bikin:
(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 ~]$Naha em dikarin fermanê ji bo hundurîniyê bidin:
(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 ~]$Wekî ku hûn ji derketinê jî dibînin, her tişt bêyî xeletî qediya. Ka em kontrol bikin ku hemî girêk di rewşa berdest de ne:
(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 ~]$ Ger girêk di rewşek cûda de ne, bi gelemperî têne rêvebirin, wê hingê tiştek xelet çû û hûn hewce ne ku li têketinê binihêrin û fêm bikin ka çima ev çêbû. Bînin bîra xwe ku di vê senaryoyê de em virtualîzasyonê bikar tînin û dibe ku xeletiyên bi karanîna makîneyên virtual an vbmc re têkildar bin.
Dûv re, pêdivî ye ku em destnîşan bikin ka kîjan nod dê kîjan fonksiyonê pêk bîne - ango, profîla ku girêk dê pê re bicîh bike destnîşan bike:
(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 ~]$Ji bo her nodek profîla diyar bikin:
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-d9afb69d1167Ka em kontrol bikin ku me her tişt rast kir:
(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 ~]$Ger her tişt rast be, em fermanê didin ku overcloud bicîh bikin:
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 qemuDi sazkirinek rastîn de, şablonên xwerû dê bi xwezayî werin bikar anîn, di rewşa me de ev ê pêvajoyê pir tevlihev bike, ji ber ku her guhertinek di şablonê de pêdivî ye ku were rave kirin. Wekî ku berê hate nivîsandin, sazkirinek hêsan jî dê bes be ku em bibînin ka ew çawa dixebite.
Nîşe: guhêrbara qemu--libvirt-ê di vê rewşê de hewce ye, ji ber ku em ê virtualbûna hêlîn bikar bînin. Wekî din, hûn ê nikaribin makîneyên virtual bimeşînin.
Naha we bi qasî saetek, an jî dibe ku bêtir heye (li gorî kapasîteyên hardware ve girêdayî ye) û hûn tenê dikarin hêvî bikin ku piştî vê demê hûn ê peyama jêrîn bibînin:
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 ~]$Naha we guhertoyek hema hema bêkêmasî ya openstack heye, ku hûn dikarin li ser bixwînin, ceribandin, hwd.
Werin em kontrol bikin ku her tişt bi rêkûpêk dixebite. Di stûna pelrêça malê ya bikarhêner de du pel hene - yek stackrc (ji bo birêvebirina undercloud) û ya duyemîn overcloudrc (ji bo birêvebirina overcloud). Pêdivî ye ku ev pel wekî çavkanî bêne destnîşan kirin, ji ber ku ew agahdariya ku ji bo rastkirinê hewce ne dihewîne.
(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 ~]$Sazkirina min hîn jî pêvekek piçûk hewce dike - lê zêdekirina rêyek li ser kontrolkerê, ji ber ku makîneya ku ez pê re dixebitim li ser torek cûda ye. Ji bo kirina vê yekê, di binê hesabê germ-rêveberê de biçin control-1 û rêçê tomar bikin
(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.254Welê, niha hûn dikarin herin nav asoyê. Hemî agahdarî - navnîşan, têketin û şîfre - di pelê /home/stack/overcloudrc de ne. Diagrama dawîn wiha xuya dike:
Bi awayê, di sazkirina me de, navnîşanên makîneyê bi DHCP-ê ve hatin derxistin û, wekî ku hûn dibînin, ew "bi şiklê" têne derxistin. Hûn dikarin di şablonê de bi tundî diyar bikin ka kîjan navnîşan divê di dema bicîhkirinê de bi kîjan makîneyê ve were girêdan, heke we jê re lazim be.
Trafîka di navbera makîneyên virtual de çawa diherike?
Di vê gotarê de em ê li sê vebijarkan ji bo derbasbûna seyrûseferê binêrin
- Du makîneyên li ser yek hypervisor li ser yek tora L2
- Du makîneyên li ser hîpervisorên cihêreng ên li ser heman torê L2
- Du makîneyên li ser torên cihêreng (rootkirina nav-torê)
Bûyerên gihîştina cîhana derve bi riya torgilokek derveyî, bi karanîna navnîşanên herikîn, û her weha rêwîtiya belavkirî, em ê carek din bifikirin, heya naha em ê bala xwe bidin ser seyrûsefera navxweyî.
Ji bo kontrolkirinê, werin em şemaya jêrîn berhev bikin:
Me 4 makîneyên virtual afirandin - 3 li ser yek tora L2 - net-1, û 1 din li ser tora net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Ka em bibînin ka makîneyên hatine afirandin li ser kîjan hîpervisoran in:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(overcloud) [stack@undercloud ~]$
Makîneyên vm-1 û vm-3 li ser compute-0, makîneyên vm-2 û vm-4 li ser node compute-1 hene.
Wekî din, routerek virtual hate afirandin ku rêvekirinê di navbera torên diyarkirî de çalak bike:
(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 ~]$ Router du portên virtual hene, ku wekî dergehek ji bo torê tevdigerin:
(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 ~]$ Lê berî ku em binihêrin ka seyrûsefer çawa diherike, ka em li tiştê ku me niha li ser girêka kontrolê (ku di heman demê de girêkek torê ye) û li ser girêka hesabkirinê jî heye binihêrin. Ka em bi girêka hesabkirinê dest pê bikin.
[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 ~]$Heya nuha, nodê sê pirên ovs hene - br-int, br-tun, br-ex. Di navbera wan de, wekî ku em dibînin, komek navber hene. Ji bo hêsan têgihiştinê, werin em van hemî navbeynkaran li ser diagramê xêz bikin û bibînin ka çi diqewime.
Li navnîşanên ku tunelên VxLAN têne bilind kirin mêze dikin, meriv dikare were dîtin ku tunelek ji bo hesab-1 (192.168.255.26) tê bilind kirin, tûnela duyemîn wekî kontrol-1 (192.168.255.15) xuya dike. Lê ya herî balkêş ev e ku br-ex ne xwedan navgînên laşî ye, û heke hûn li ka çi herikîn têne mîheng kirin binihêrin, hûn dikarin bibînin ku ev pira tenê di vê gavê de dikare seyrûseferê bavêje.
[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 ~]$ Wekî ku hûn ji derketinê jî dibînin, navnîş rasterast li porta laşî, û ne li navgîniya pira virtual tê xêzkirin.
[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 ~]$
Li gorî qaîdeya yekem, her tiştê ku ji porta phy-br-ex hatî divê were avêtin.
Bi rastî, aniha ji bilî vê navberê (navbera bi br-int) ti cîhek din tune ku seyrûsefera xwe bikeve vê pirê, û li gorî dakêşan dadbar bikin, seyrûsefera BUM berê xwe daye pirê.
Ango, seyrûsefer dikare ji vê nodê tenê bi riya tunela VxLAN û ne tiştek din derkeve. Lêbelê, heke hûn DVR-ê vekin, rewş dê biguhere, lê em ê carek din bi wê re mijûl bibin. Dema ku îzolekirina torê bikar tînin, mînakî vlanan bikar tînin, hûn ê di vlan 3 de ne yek pêwendiyek L0, lê çend navbeynkar hebin. Lêbelê, seyrûsefera VxLAN dê bi heman rengî girêkê bihêle, lê di heman demê de di cûreyek vlanek taybetî de jî tê vegirtin.
Me girêka hesabkirinê ji hev veqetand, em biçin ser girêka kontrolê.
[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 ~]$Bi rastî, em dikarin bibêjin ku her tişt yek e, lê navnîşana IP-ê êdî ne li ser pêwendiya laşî lê li ser pira virtual ye. Ev tê kirin ji ber ku ev bender ew bendera ku dê seyrûsefer ji cîhana derve derkeve ye.
[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 ~]$ Ev bender bi pira br-ex ve girêdayî ye û ji ber ku ti etîketên vlan li ser tune ne, ev port portek barkêş e ku li ser hemî vlan têne destûr kirin, naha seyrûsefer bêyî nîşanek derdikeve derve, wekî ku ji hêla vlan-id 0 ve hatî destnîşan kirin derketina li jor.
Tiştên din ên vê gavê dişibin girêka hesabkirinê - heman pir, heman tunel diçin du girêkên hesabkirinê.
Em ê di vê gotarê de girêkên hilanînê nehesibînin, lê ji bo têgihiştinê pêdivî ye ku were gotin ku beşa torê ya van girêkan heya xala şermkirinê banal e. Di doza me de, tenê yek portek laşî (eth0) heye ku navnîşek IP-yê jê re hatî destnîşan kirin û ew e. Tunnelên VxLAN, pirên tunelan û hwd tune ne - bi tevahî ovs tune, ji ber ku xalek tê de tune. Dema ku îzolekirina torê bikar tîne, ev girêk dê xwediyê du navgînan be (portên laşî, bedenî, an tenê du vlan - ne girîng e - ew bi tiştê ku hûn dixwazin ve girêdayî ye) - yek ji bo rêveberiyê, ya duyemîn ji bo trafîkê (nivîsandina li ser dîska VM , xwendina ji dîskê, hwd.)
Me fêhm kir ku di nebûna karûbaran de li ser nokan çi hene. Naha em werin 4 makîneyên virtual bidin destpêkirin û bibînin ka nexşeya ku li jor hatî destnîşan kirin çawa diguhezîne - divê em port, rêwerên virtual, hwd.
Heya nuha tora me wiha xuya dike:
Li ser her girêka komputerê du makîneyên me yên virtual hene. Bi karanîna compute-0 wekî nimûne, em bibînin ka her tişt çawa tê de ye.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Makîne tenê yek pêwendiya virtual heye - 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 ~]$
Ev navber di pira linux de xuya dike:
[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 ~]$ Wekî ku hûn ji derketinê dibînin, di pirê de tenê du navber hene - tap95d96a75-a0 û qvb95d96a75-a0.
Li vir hêja ye ku meriv hinekî li ser celebên cîhazên torê yên virtual di OpenStack de raweste:
vtap - pêwendiya virtual ku bi mînakek ve girêdayî ye (VM)
qbr - pira Linux
qvb û qvo - cotek vEth bi pira Linux û pira vSwitch veke ve girêdayî ye
br-int, br-tun, br-vlan - Pirên vSwitch vekin
patch-, int-br-, phy-br- - Têkiliyên patchê yên ku piran girêdidin vekin
qg, qr, ha, fg, sg - Portên vSwitch vekin ku ji hêla cîhazên virtual ve têne bikar anîn da ku bi OVS-ê ve girêdayî bibin
Wekî ku hûn fêm dikin, heke me di pirê de portek qvb95d96a75-a0 hebe, ku cotek vEth e, wê hingê li cîhek hevtayê wê heye, ku divê bi mentiqî jê re qvo95d96a75-a0 were gotin. Ka em bibînin ka çi portên li ser OVS hene.
[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 ~]$ Wekî ku em dibînin, port di br-int de ye. Br-int wekî veguhezek ku portên makîneya virtual bi dawî dike tevdigere. Ji bilî qvo95d96a75-a0, porta qvo5bd37136-47 di encam de xuya ye. Ev porta makîneya virtual ya duyemîn e. Wekî encamek, diyagrama me niha wiha xuya dike:
Pirsek ku divê tavilê xwendevanê baldar eleqedar bike - pira linux di navbera porta makîneya virtual û porta OVS de çi ye? Rastî ev e ku ji bo parastina makîneyê, komên ewlehiyê têne bikar anîn, ku ji iptable-an wêdetir ne. OVS bi iptables re naxebite, ji ber vê yekê ev "kûçik" hate kifş kirin. Lêbelê, ew berbelav dibe - ew di weşanên nû de bi kontrack tê guheztin.
Ango, di dawiyê de plan wiha xuya dike:
Du makîneyên li ser yek hypervisor li ser yek tora L2
Ji ber ku ev her du VM li ser heman torê L2 û li ser heman hîpervisorê ne, dê seyrûsefera di navbera wan de bi mentiqî bi navgîniya br-int ve biherike, ji ber ku her du makîne dê li ser heman VLAN bin:
[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 makîneyên li ser hîpervisorên cihêreng ên li ser heman torê L2
Naha em bibînin ka dê seyrûsefer çawa di navbera du makîneyên li ser heman torê L2 de, lê li ser hîpervisorên cihêreng, biçe. Rast be, dê tiştek pir neguheze, tenê seyrûsefera di navbera hîpervisoran de dê di tunela vxlan re derbas bibe. Ka em li mînakekê binêrin.
Navnîşanên makîneyên virtual ku di navbera wan de em ê li trafîkê temaşe bikin:
[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 ~]$ Em li tabloya şandinê li br-int li ser compute-0 dinêrin:
[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 ~]Pêdivî ye ku seyrûsefer biçe porta 2 - em bibînin ka ew çi celeb port e:
[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 ~]$Ev patch-tun e - ango pêwendiya di br-tun de. Ka em bibînin ka pakêta li ser br-tun çi dibe:
[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 ~]$ Pakêt di VxLAN-ê de tê pakkirin û ji porta 2 re tê şandin. Ka em bibînin ka port 2 ber bi ku ve diçe:
[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 ~]$Ev tunelek vxlan li ser compute-1 e:
[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 ~]$Ka em biçin compute-1 û bibînin ka paşê bi pakêtê re çi diqewime:
[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 di tabloya şandina br-int de li ser compute-1-ê ye, û wekî ku ji derana jorîn tê dîtin, ew bi porta 2-ê, ku porta berbi br-tun-ê ye, xuya dibe:
[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:46Welê, wê gavê em dibînin ku di br-int-ê de li ser compute-1 deqek armanc heye:
[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 ~]$ Ango, pakêta wergirtî dê berbi porta 3-ê bifire, li pişt wê jî mînakek makîneya virtual-00000003 heye.
Bedewiya bicihkirina Openstack ji bo fêrbûna li ser binesaziya virtual ev e ku em dikarin bi hêsanî seyrûsefera di navbera hîpervisoran de bigirin û bibînin ka çi bi wê re diqewime. Ya ku em ê niha bikin ev e, tcpdump li ser porta vnet ber bi compute-0 ve bimeşînin:
[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*******************Rêza yekem nîşan dide ku Patek ji navnîşana 10.0.1.85 diçe navnîşana 10.0.1.88 (trafîka ICMP), û ew di pakêtek VxLAN de bi vni 22 ve hatî pêçandin û pakêt ji mêvandarê 192.168.255.19 (hejmartin-0) diçe mêvandarê 192.168.255.26. .1 (hejmartin-XNUMX). Em dikarin kontrol bikin ku VNI bi ya ku di ovs de hatî destnîşan kirin li hev dike.
Ka em vegerin ser vê rêzê: load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],derketin:2. 0x16 di pergala jimareya hexadecimal de vni ye. Ka em vê hejmarê veguherînin pergala 16-an:
16 = 6*16^0+1*16^1 = 6+16 = 22Ango vni bi rastiy ve li hev dike.
Rêza duyemîn seyrûsefera vegerê nîşan dide, baş e, ravekirina wê tune ye, her tişt li wir zelal e.
Du makîneyên li ser torên cihêreng (rêveçûna nav-torê)
Doza paşîn ji bo îro rêvekirina di navbera toran de di nav yek projeyê de bi karanîna routerek virtual ye. Em dozek bêyî DVR-ê dinirxînin (em ê di gotarek din de lê binihêrin), ji ber vê yekê rêkirin li ser girêka torê pêk tê. Di rewşa me de, girêka torê di nav saziyek cûda de nayê danîn û li ser girêka kontrolê ye.
Pêşîn, em bibînin ku rêvekirin dixebite:
$ 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 msJi ber ku di vê rewşê de pêdivî ye ku pakêt biçe dergehê û li wir were rêve kirin, pêdivî ye ku em navnîşana poppy ya dergehê fêr bibin, ji bo ku em di nimûneyê de li tabloya ARP-ê dinêrin:
$ 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 eth0Naha em bibînin ka seyrûsefera bi mebest (10.0.1.254) fa:16:3e:c4:64:70 li ku derê divê were şandin:
[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 ~]$ Ka em binihêrin ka port 2 li ku derê rêve dibe:
[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 ~]$ Her tişt mentiqî ye, trafîk diçe br-tun. Ka em bibînin ka ew ê di kîjan tunela vxlan de were pêçandin:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Porta sêyemîn tunelek vxlan e:
[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 ~]$ Ku li girêka kontrolê dinêre:
[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 ~]$ Trafîk gihîştiye girêka kontrolê, ji ber vê yekê divê em biçin wê û bibînin ka dê rêçkirin çawa bibe.
Wekî ku tê bîra we, girêka kontrolê ya hundurîn tam wekî girêka hesabkirinê xuya dikir - heman sê pira, tenê br-ex xwedan portek laşî bû ku tê de girêk dikaribû trafîkê bişîne derve. Afirandina mînakan veavakirina li ser girêkên hesabkirinê guherand - pira linux, iptables û navbeynkar li girêkan hatin zêdekirin. Afirandina toran û routerek virtual jî mohra xwe li ser veavakirina girêka kontrolê hişt.
Ji ber vê yekê, diyar e ku navnîşana MAC-a dergehê divê di tabloya şandina br-int de li ser girêka kontrolê be. Ka em kontrol bikin ka ew li wir e û li ku lê digere:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Mac ji porta qr-0c52b15f-8f xuya ye. Ger em vegerin navnîşa benderên virtual di Openstack de, ev celeb port ji bo girêdana cûrbecûr cîhazên virtual bi OVS re tê bikar anîn. Ji bo ku bêtir rast be, qr portek ji routerê virtual re ye, ku wekî cîhek navan tê destnîşan kirin.
Ka em bibînin ka çi navên li ser serverê hene:
[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 ~]$ Bi qasî sê nusxe. Lê li gorî navan dadbar, hûn dikarin armanca her yek ji wan texmîn bikin. Em ê paşê vegerin mînakên bi ID 0 û 1, naha em li qada navan qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe eleqedar dibin:
[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 ~]$ Ev navan du navên hundurîn ên ku me berê afirandine dihewîne. Her du portên virtual li br-int hatine zêdekirin. Ka em navnîşana mac-ê ya portê qr-0c52b15f-8f kontrol bikin, ji ber ku seyrûsefer, li gorî navnîşana mac-a armancê dadbar, çû vê navbeynê.
[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 ~]$ Ango, di vê rewşê de, her tişt li gorî qanûnên rêveçûna standard dixebite. Ji ber ku seyrûsefer ji bo mêvandarê 10.0.2.8-ê hatî armanc kirin, divê ew bi navgîniya duyemîn qr-92fa49b5-54 derkeve û di tunela vxlan re derbasî girêka hesabkirinê bibe:
[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 ~]$ Her tişt mentiqî ye, ne surprîz e. Ka em bibînin ku navnîşana poppy ya host 10.0.2.8 di br-int de xuya ye:
[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 ~]$ Wekî ku tê hêvî kirin, seyrûsefer ber bi br-tun ve diçe, em bibînin ka seyrûsefer ber bi kîjan tunelê ve diçe:
[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 ~]$ Trafîk diçe nav tunelê da ku hesab bike-1. Welê, li ser compute-1 her tişt hêsan e - ji br-tun pakêt diçe br-int û ji wir jî berbi navgîniya makîneya virtual:
[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 ~]$ Ka em kontrol bikin ku ev bi rastî pêwendiya rast e:
[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 ~]$
Bi rastî, em heta dawiyê di pakêtê de derbas bûn. Ez difikirim ku we ferq kir ku seyrûsefer di tunelên vxlan ên cihêreng re derbas bû û bi VNI-yên cihêreng derket. Ka em bibînin ka ev çi cûre VNI ne, piştî ku em ê li ser bendera kontrolê ya girêkê depoyek berhev bikin û pê ewle bibin ku seyrûsefer tam wekî ku li jor hatî destnîşan kirin diherike.
Ji ber vê yekê, tunela hesab-0 van kiryaran heye = barkirin:0->NXM_OF_VLAN_TCI[],barkirin:0x16->NXM_NX_TUN_ID[],derketin:3. Ka em 0x16 veguherînin pergala jimareya dehan:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunela hesab-1-ê VNI ya jêrîn heye: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],derketin:2. Ka em 0x63 veguherînin pergala jimareya dehan:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Belê, niha em li çolê binêrin:
[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*******************Pakêta yekem pakêtek vxlan e ji mêvandarê 192.168.255.19 (hejmar-0) heya mêvandarê 192.168.255.15 (kontrol-1) bi vni 22 re, ku di hundurê wê de pakêtek ICMP ji mêvandarê 10.0.1.85 heya mêvandarê 10.0.2.8 hatî pakêt kirin. Weke ku me li jor hesab kir, vni ya ku me di encam de dît li hev dike.
Pakêta duyemîn pakêtek vxlan e ji mêvandarê 192.168.255.15 (kontrol-1) heya mêvandarê 192.168.255.26 (hejmartin-1) bi vni 99, di hundurê wê de pakêtek ICMP ji mêvandarê 10.0.1.85 heya 10.0.2.8 hatî pakêt kirin. Weke ku me li jor hesab kir, vni ya ku me di encam de dît li hev dike.
Du pakêtên din seyrûsefera vegerê ne ji 10.0.2.8 ne 10.0.1.85.
Ango, di dawiyê de me pilana girêka kontrolê ya jêrîn girt:
Binêre qey ew e? Me du cîhên navan ji bîr kir:
[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 ~]$ Gava ku me li ser mîmariya platforma ewr axivî, dê baş be heke makîneyan navnîşan bixweber ji serverek DHCP wergirin. Van du serverên DHCP-ê ji bo du torên me 10.0.1.0/24 û 10.0.2.0/24 ne.
Ka em kontrol bikin ku ev rast e. Di vê navan de tenê navnîşek heye - 10.0.1.1 - navnîşana servera DHCP bixwe, û ew jî di br-int de ye:
[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 0Ka em bibînin ka pêvajoyên ku qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 bi navê wan li ser girêka kontrolê vedihewînin:
[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 ~]$ Pêvajoyek wusa heye û li ser bingeha agahdariya ku di hilberîna jorîn de hatî pêşkêş kirin, em dikarin, mînakî, bibînin ka em niha ji bo kirê çi ne:
[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 ~]$Wekî encamek, em karûbarên jêrîn li ser girêka kontrolê digirin:
Welê, ji bîr mekin - ev tenê 4 makîne, 2 torgilokên hundurîn û yek routerek virtual e... Naha li vir toreyên me yên derveyî tune ne, komek projeyên cihêreng, her yek bi torên xwe (lihevkirî), û me hene routerek belavkirî veqetiya, û di dawiyê de, li ber her tiştî, tenê yek girêk kontrolê di bendika testê de hebû (ji bo tolerasyona xeletiyê divê hejmarek ji sê girêkan hebe). Mantiqî ye ku di bazirganiyê de her tişt "piçek" tevlihevtir e, lê di vê mînaka hêsan de em fam dikin ka ew çawa divê bixebite - gelo we 3 an 300 cîhên navên we hene bê guman girîng e, lê ji xala xebitandina tevaya strukturê, tiştek dê pir neguheze... her çend hûn ê hin SDN-ya firoşkarê venekin. Lê ew çîrokek bi tevahî cûda ye.
Ez hêvî dikim ku ew balkêş bû. Ger şîroveyên we/zêdekirinên we hebin, an li cîhek ku min bi eşkere derewand (ez mirov im û nêrîna min dê her gav subjektîf be) - tiştê ku divê were rast kirin/lê zêdekirin binivîsin - em ê her tiştî rast bikin/lê zêde bikin.
Di encamê de, ez dixwazim çend peyvan li ser berhevdana Openstack (hem vanilla û hem jî firoşkar) bi çareseriya cloudê ya VMWare re bibêjim - di van du salên borî de pir caran ev pirs ji min tê pirsîn û, bi eşkereyî, ez jixwe ji wê westiyayî, lê dîsa jî. Bi dîtina min berawirdkirina van her du çareseriyan pir zehmet e, lê em teqez dikarin bibêjin ku di her du çareseriyan de dezawantaj jî hene û dema ku çareseriyek hilbijêrin hewce ye ku hûn berjewendî û xirabiyan binirxînin.
Ger OpenStack çareseriyek civatê ye, wê hingê mafê VMWare heye ku tenê tiştê ku ew dixwaze bike (bixwîne - çi jê re sûdmend e) û ev mentiqî ye - ji ber ku ew pargîdaniyek bazirganî ye ku ji xerîdarên xwe drav dide bikar anîn. Lê LÊ yek mezin û qelew heye - hûn dikarin ji OpenStack-ê, mînakî ji Nokia-yê derkevin, û bi lêçûnek hindik veguhezînin çareseriyek ji, mînakî, Juniper (Contrail Cloud), lê ne gengaz e ku hûn nikaribin ji VMWare derkevin. . Ji bo min, ev her du çareserî bi vî rengî xuya dikin - Openstack (firotanê) qefesek hêsan e ku hûn tê de têne danîn, lê miftek we heye û hûn dikarin her gav derkevin. VMWare qefeseke zêrîn e, mifteya qefesê xwediyê xwediyê wê ye û wê gelek mesrefa we bike.
Ez ne hilbera yekem û ne ya duyemîn pêşve nakim - hûn tiştê ku hûn hewce ne hilbijêrin. Lê ger min hilbijarkek wusa hebûya, ez ê her du çareseriyan bibijêrim - VMWare ji bo ewrê IT-ê (barkirinên kêm, rêveberiya hêsan), OpenStack ji hin firoşkaran (Nokia û Juniper çareseriyên kilama pir baş peyda dikin) - ji bo ewrê Telecom. Ez ê Openstack-ê ji bo IT-ya paqij bikar nekim - ew mîna gulebarana çivîkan bi topê ye, lê ez ji bilî zêdebûnê tu berevajîyên karanîna wê nabînim. Lêbelê, karanîna VMWare di telekomê de mîna hilgirtina kevirê pelçiqandî di Ford Raptor de ye - ew ji derve xweş e, lê ajokar neçar e ku li şûna yekê 10 rêwîtiyê bike.
Bi dîtina min, kêmasiya herî mezin a VMWare girtina wê ya bêkêmasî ye - pargîdanî dê di derheqê ka ew çawa dixebite de agahdarî nede we, mînakî, vSAN an di kernelê hypervisor de çi heye - ew bi tenê ji bo wê ne sûdmend e - ango hûn ê tu carî di VMWare-ê de nebin pispor - bêyî piştgirîya firoşkar, hûn mehkûm in (pir caran ez bi pisporên VMWare re ku ji pirsên piçûk matmayî ne, dicivim). Ji bo min, VMWare tirimbêlek bi kapê kilîtkirî dikire - erê, dibe ku hûn pisporên ku dikarin kembera demjimêrê biguhezînin hebin, lê tenê yê ku ev çareserî ji we re firotiye dikare kapê veke. Bi kesane, ez ji çareseriyên ku ez nikaribim tê de cih bigirim hez nakim. Hûn ê bibêjin ku dibe ku hûn neçar bin ku bikevin bin kapê. Erê, ev mimkun e, lê ez ê li we binerim gava ku hûn hewce ne ku ji 20-30 makîneyên virtual, 40-50 torên ku nîvê wan dixwazin derkevin derve, û nîvê duyemîn di ewrê de fonksiyonek mezin kom bikin. Lezkirina SR-IOV, wekî din hûn ê hewceyê çend duwan ji van gerîdeyan zêdetir bikin - wekî din performans dê têrê neke.
Nêrînên din hene, ji ber vê yekê tenê hûn dikarin biryar bidin ka çi hilbijêrin û ya herî girîng, hûn ê wê hingê berpirsiyariya hilbijartina xwe bin. Ev tenê nerîna min e - kesek ku bi kêmî ve 4 hilberan dîtiye û dest pê kiriye - Nokia, Juniper, Red Hat û VMWare. Yanî tiştekî min heye ku ez pê re bidim ber hev.
Source: www.habr.com