Kompyuta ya wingu inapenya zaidi na zaidi katika maisha yetu na labda hakuna mtu hata mmoja ambaye hajatumia huduma zozote za wingu angalau mara moja. Hata hivyo, ni nini hasa wingu na jinsi inavyofanya kazi, watu wachache wanajua, hata kwa kiwango cha wazo. 5G tayari inafanyika uhalisia na miundombinu ya mawasiliano ya simu inaanza kuhama kutoka kwa suluhisho la nguzo hadi suluhu za wingu, kama ilivyokuwa wakati ilihama kutoka kwa suluhisho za maunzi kamili hadi "nguzo" zilizoboreshwa.
Leo tutazungumzia kuhusu ulimwengu wa ndani wa miundombinu ya wingu, hasa tutaangalia misingi ya sehemu ya mtandao.
Wingu ni nini? Uboreshaji sawa - mtazamo wa wasifu?
Zaidi ya swali la kimantiki. Hapana - hii sio uvumbuzi, ingawa haikuweza kufanywa bila hiyo. Hebu tuangalie ufafanuzi mbili:
Cloud computing (hapa inajulikana kama Cloud) ni kielelezo cha kutoa ufikiaji unaomfaa mtumiaji kwa rasilimali za kompyuta zilizosambazwa ambazo lazima zitumike na kuzinduliwa inapohitajika kwa muda wa chini zaidi wa kusubiri na gharama ndogo kwa mtoa huduma.
Usanifu - huu ni uwezo wa kugawa chombo kimoja cha mwili (kwa mfano, seva) katika anuwai kadhaa, na hivyo kuongeza utumiaji wa rasilimali (kwa mfano, ulikuwa na seva 3 zilizopakiwa kwa asilimia 25-30, baada ya uvumbuzi unapata seva 1 iliyopakiwa. kwa asilimia 80-90). Kwa kawaida, virtualization inakula baadhi ya rasilimali - unahitaji kulisha hypervisor, hata hivyo, kama mazoezi yameonyesha, mchezo ni wa thamani ya mshumaa. Mfano bora wa uboreshaji ni VMWare, ambayo huandaa kikamilifu mashine za kawaida, au kwa mfano KVM, ambayo napendelea, lakini hili ni suala la ladha.
Tunatumia uboreshaji bila kutambua, na hata vipanga njia vya chuma tayari vinatumia uboreshaji - kwa mfano, katika toleo la hivi karibuni la JunOS, mfumo wa uendeshaji umesakinishwa kama mashine pepe juu ya usambazaji wa Linux wa wakati halisi (Wind River 9). Lakini virtualization sio wingu, lakini wingu haliwezi kuwepo bila virtualization.
Virtualization ni moja ya vizuizi vya ujenzi ambavyo wingu hujengwa.
Kutengeneza wingu kwa kukusanya viboreshaji kadhaa kwenye kikoa kimoja cha L2, kuongeza vitabu kadhaa vya kuml vya kusajili kiotomatiki vlans kupitia aina fulani ya Ansible na kuweka kitu kama mfumo wa ochestration juu yake kwa kuunda kiotomatiki mashine pepe haitafanya kazi. Itakuwa sahihi zaidi, lakini matokeo ya Frankenstein sio wingu tunalohitaji, ingawa inaweza kuwa ndoto ya mwisho kwa wengine. Zaidi ya hayo, ikiwa unachukua Openstack sawa, kimsingi bado ni Frankenstein, lakini oh vizuri, hebu tuzungumze kuhusu hilo kwa sasa.
Lakini ninaelewa kuwa kutoka kwa ufafanuzi uliowasilishwa hapo juu sio wazi kabisa ni nini kinachoweza kuitwa wingu.
Kwa hivyo, hati kutoka NIST (Taasisi ya Kitaifa ya Viwango na Teknolojia) hutoa sifa kuu 5 ambazo miundombinu ya wingu inapaswa kuwa nayo:
Kutoa huduma kwa ombi. Mtumiaji lazima apewe upatikanaji wa bure kwa rasilimali za kompyuta zilizotengwa kwake (kama vile mitandao, disks virtual, kumbukumbu, cores processor, nk), na rasilimali hizi lazima kutolewa moja kwa moja - yaani, bila kuingilia kati kutoka kwa mtoa huduma.
Upatikanaji mkubwa wa huduma. Upatikanaji wa rasilimali lazima utolewe na mifumo ya kawaida ili kuruhusu matumizi ya Kompyuta za kawaida na wateja nyembamba na vifaa vya simu.
Kuchanganya rasilimali kwenye mabwawa. Mabwawa ya rasilimali lazima yaweze kutoa rasilimali kwa wateja wengi kwa wakati mmoja, kuhakikisha kuwa wateja wametengwa na hawana ushawishi wa pande zote na ushindani wa rasilimali. Mitandao pia imejumuishwa kwenye mabwawa, ambayo inaonyesha uwezekano wa kutumia anwani zinazoingiliana. Mabwawa lazima yawe na kiwango kulingana na mahitaji. Matumizi ya mabwawa hufanya iwezekanavyo kutoa kiwango kinachohitajika cha uvumilivu wa makosa ya rasilimali na uondoaji wa rasilimali za kimwili na za kawaida - mpokeaji wa huduma hutolewa tu na seti ya rasilimali alizoomba (ambapo rasilimali hizi ziko kimwili, kwa ngapi seva na swichi - haijalishi kwa mteja). Hata hivyo, lazima tuzingatie ukweli kwamba mtoa huduma lazima ahakikishe uhifadhi wa uwazi wa rasilimali hizi.
Marekebisho ya haraka kwa hali tofauti. Huduma lazima ziwe rahisi - utoaji wa haraka wa rasilimali, ugawaji wao, kuongeza au kupunguza rasilimali kwa ombi la mteja, na kwa upande wa mteja kunapaswa kuwa na hisia kwamba rasilimali za wingu hazina mwisho. Kwa urahisi wa kuelewa, kwa mfano, huoni onyo kwamba sehemu ya nafasi yako ya diski katika Apple iCloud imetoweka kwa sababu gari ngumu kwenye seva imevunjika, na anatoa huvunja. Kwa kuongeza, kwa upande wako, uwezekano wa huduma hii ni karibu usio na kikomo - unahitaji 2 TB - hakuna shida, ulilipa na kuipokea. Mfano sawa unaweza kutolewa na Google.Drive au Yandex.Disk.
Uwezekano wa kupima huduma iliyotolewa. Mifumo ya wingu lazima idhibiti na kuboresha rasilimali zinazotumiwa kiotomatiki, na mbinu hizi lazima ziwe wazi kwa mtumiaji na mtoa huduma. Hiyo ni, unaweza kuangalia kila wakati ni rasilimali ngapi wewe na wateja wako mnatumia.
Inafaa kuzingatia ukweli kwamba mahitaji haya ni mahitaji zaidi ya wingu la umma, kwa hivyo kwa wingu la kibinafsi (hiyo ni, wingu lililozinduliwa kwa mahitaji ya ndani ya kampuni), mahitaji haya yanaweza kubadilishwa kidogo. Walakini, bado zinapaswa kufanywa, vinginevyo hatutapata faida zote za kompyuta ya wingu.
Kwa nini tunahitaji wingu?
Hata hivyo, teknolojia yoyote mpya au iliyopo, itifaki yoyote mpya imeundwa kwa kitu (vizuri, isipokuwa kwa RIP-ng, bila shaka). Hakuna mtu anayehitaji itifaki kwa ajili ya itifaki (vizuri, isipokuwa kwa RIP-ng, bila shaka). Ni sawa kwamba Wingu limeundwa ili kutoa aina fulani ya huduma kwa mtumiaji/mteja. Sote tunafahamu angalau huduma kadhaa za wingu, kwa mfano Dropbox au Google.Docs, na ninaamini watu wengi wanazitumia kwa mafanikio - kwa mfano, makala haya yaliandikwa kwa kutumia huduma ya wingu ya Google.Docs. Lakini huduma za wingu tunazojua ni sehemu tu ya uwezo wa wingu-kwa usahihi zaidi, ni huduma ya aina ya SaaS tu. Tunaweza kutoa huduma ya wingu kwa njia tatu: kwa njia ya SaaS, PaaS au IaaS. Ni huduma gani unayohitaji inategemea tamaa na uwezo wako.
Wacha tuangalie kila moja kwa mpangilio:
Programu kama Huduma (SaaS) ni kielelezo cha kutoa huduma kamili kwa mteja, kwa mfano, huduma ya barua pepe kama Yandex.Mail au Gmail. Katika mtindo huu wa utoaji huduma, wewe, kama mteja, hufanyi chochote isipokuwa kutumia huduma - yaani, huna haja ya kufikiria juu ya kuanzisha huduma, uvumilivu wake wa makosa au upungufu. Jambo kuu sio kuhatarisha nenosiri lako; mtoaji wa huduma hii atakufanyia mengine. Kutoka kwa mtazamo wa mtoa huduma, anajibika kikamilifu kwa huduma nzima - kutoka kwa vifaa vya seva na mifumo ya uendeshaji ya mwenyeji kwenye hifadhidata na mipangilio ya programu.
Jukwaa kama Huduma (PaaS) - wakati wa kutumia mfano huu, mtoa huduma hutoa mteja na workpiece kwa huduma, kwa mfano, hebu tuchukue seva ya Mtandao. Mtoa huduma alimpa mteja seva pepe (kwa kweli, seti ya rasilimali, kama vile RAM/CPU/Hifadhi/Nvu, n.k.), na hata kusakinisha OS na programu muhimu kwenye seva hii, hata hivyo, usanidi wa mambo haya yote yanafanywa na mteja mwenyewe na kwa ajili ya utendaji wa huduma mteja anajibu. Mtoa huduma, kama ilivyo katika kesi ya awali, anajibika kwa utendaji wa vifaa vya kimwili, hypervisors, mashine ya kawaida yenyewe, upatikanaji wake wa mtandao, nk, lakini huduma yenyewe haipo tena katika eneo lake la uwajibikaji.
Miundombinu kama Huduma (IaaS) - Mbinu hii tayari inavutia zaidi, kwa kweli, mtoa huduma humpa mteja miundombinu kamili iliyoboreshwa - ambayo ni, seti fulani ya rasilimali, kama vile Cores za CPU, RAM, Mitandao, nk. Kila kitu kingine kiko juu mteja - kile mteja anataka kufanya na rasilimali hizi ndani ya bwawa lililotengwa (mgawo) - sio muhimu haswa kwa mtoaji. Ikiwa mteja anataka kuunda vEPC yake mwenyewe au hata kuunda operator mini na kutoa huduma za mawasiliano - hakuna swali - fanya hivyo. Katika hali kama hiyo, mtoa huduma anawajibika kwa utoaji wa rasilimali, uvumilivu wao wa makosa na upatikanaji, pamoja na OS ambayo inawaruhusu kukusanya rasilimali hizi na kuzifanya zipatikane kwa mteja na uwezo wa kuongeza au kupunguza rasilimali wakati wowote. kwa ombi la mteja. Mteja husanidi mashine zote za mtandaoni na vichungi vingine mwenyewe kupitia lango la huduma ya kibinafsi na kiweko, pamoja na kusanidi mitandao (isipokuwa mitandao ya nje).
OpenStack ni nini?
Katika chaguzi zote tatu, mtoa huduma anahitaji OS ambayo itawezesha kuundwa kwa miundombinu ya wingu. Kwa kweli, na SaaS, zaidi ya mgawanyiko mmoja unawajibika kwa safu nzima ya teknolojia - kuna mgawanyiko ambao unawajibika kwa miundombinu - ambayo ni, inatoa IaaS kwa mgawanyiko mwingine, mgawanyiko huu hutoa SaaS kwa mteja. OpenStack ni mojawapo ya mifumo ya uendeshaji ya wingu ambayo inakuwezesha kukusanya rundo la swichi, seva na mifumo ya kuhifadhi kwenye hifadhi moja ya rasilimali, kugawanya bwawa hili la kawaida katika vikundi vidogo (wapangaji) na kutoa rasilimali hizi kwa wateja kupitia mtandao.
OpenStack ni mfumo wa uendeshaji wa wingu unaokuwezesha kudhibiti hifadhi kubwa za rasilimali za kompyuta, hifadhi ya data na rasilimali za mtandao, zinazotolewa na kudhibitiwa kupitia API kwa kutumia njia za uthibitishaji za kawaida.
Kwa maneno mengine, hii ni seti ya miradi ya programu ya bure ambayo imeundwa kuunda huduma za wingu (za umma na za kibinafsi) - yaani, seti ya zana zinazokuwezesha kuchanganya seva na vifaa vya kubadili kwenye bwawa moja la rasilimali, kusimamia. rasilimali hizi, kutoa kiwango muhimu cha uvumilivu wa makosa.
Wakati wa kuandika nyenzo hii, muundo wa OpenStack unaonekana kama hii:
Picha iliyochukuliwa kutoka
Kila moja ya vipengele vilivyojumuishwa katika OpenStack hufanya kazi maalum. Usanifu huu uliosambazwa hukuruhusu kujumuisha katika suluhisho seti ya vifaa vya kufanya kazi ambavyo unahitaji. Hata hivyo, baadhi ya vipengele ni vipengele vya mizizi na kuondolewa kwao kutasababisha kutofanya kazi kamili au sehemu ya suluhisho kwa ujumla. Vipengele hivi kawaida huwekwa kama:
- Dashibodi - GUI ya Wavuti ya kudhibiti huduma za OpenStack
- Keystone ni huduma ya utambulisho ya kati ambayo hutoa utendakazi wa uthibitishaji na uidhinishaji wa huduma zingine, pamoja na kudhibiti kitambulisho cha mtumiaji na majukumu yao.
- Neutroni - huduma ya mtandao ambayo hutoa muunganisho kati ya miingiliano ya huduma mbali mbali za OpenStack (pamoja na muunganisho kati ya VM na ufikiaji wao kwa ulimwengu wa nje)
- Cinder - hutoa ufikiaji wa uhifadhi wa kuzuia kwa mashine pepe
- Nova - Usimamizi wa mzunguko wa maisha wa mashine za kawaida
- Uzuri - hazina ya picha za mashine na vijipicha
- Swift β hutoa ufikiaji wa kitu cha kuhifadhi
- Ceilometer - huduma ambayo hutoa uwezo wa kukusanya telemetry na kupima rasilimali zilizopo na zinazotumiwa
- Joto - ochestration kulingana na violezo vya kuunda kiotomatiki na utoaji wa rasilimali
Orodha kamili ya miradi yote na madhumuni yao yanaweza kutazamwa .
Kila kipengee cha OpenStack ni huduma inayotekeleza utendakazi mahususi na hutoa API ya kudhibiti utendakazi huo na kuingiliana na huduma zingine za mfumo wa uendeshaji wa wingu ili kuunda miundombinu iliyounganishwa. Kwa mfano, Nova hutoa usimamizi wa rasilimali za kompyuta na API ya ufikiaji wa kusanidi rasilimali hizi, Glance hutoa usimamizi wa picha na API ya kuzidhibiti, Cinder hutoa hifadhi ya block na API ya kuidhibiti, nk. Kazi zote zimeunganishwa kwa njia ya karibu sana.
Walakini, ukiiangalia, huduma zote zinazoendeshwa katika OpenStack hatimaye ni aina fulani ya mashine (au chombo) iliyounganishwa kwenye mtandao. Swali linatokea - kwa nini tunahitaji vipengele vingi?
Wacha tupitie algorithm ya kuunda mashine pepe na kuiunganisha kwenye mtandao na uhifadhi endelevu katika Openstack.
- Unapounda ombi la kuunda mashine, iwe ombi kupitia Horizon (Dashibodi) au ombi kupitia CLI, jambo la kwanza kutokea ni idhini ya ombi lako kwenye Keystone - unaweza kuunda mashine, je ina haki ya kutumia mtandao huu, je, rasimu yako ya upendeleo, nk.
- Keystone huthibitisha ombi lako na kutoa tokeni ya uthibitishaji katika ujumbe wa majibu, ambayo itatumika zaidi. Baada ya kupokea jibu kutoka kwa Keystone, ombi linatumwa kuelekea Nova (nova api).
- Nova-api hukagua uhalali wa ombi lako kwa kuwasiliana na Keystone kwa kutumia tokeni ya uthibitishaji iliyotengenezwa hapo awali
- Keystone hutekeleza uthibitishaji na hutoa maelezo kuhusu ruhusa na vikwazo kulingana na tokeni hii ya uthibitishaji.
- Nova-api huunda ingizo la VM mpya katika hifadhidata ya nova na kupitisha ombi la kuunda mashine kwa mratibu wa nova.
- Nova-scheduler huchagua mwenyeji (nodi ya kompyuta) ambayo VM itatumika kulingana na vigezo maalum, uzito na kanda. Rekodi ya hii na kitambulisho cha VM zimeandikwa kwa hifadhidata ya nova.
- Ifuatayo, nova-scheduler contacts nova-compute na ombi la kupeleka mfano. Nova-compute mawasiliano nova-conductor ili kupata taarifa kuhusu vigezo vya mashine (nova-conductor ni kipengele cha nova ambacho hufanya kazi kama seva mbadala kati ya nova-database na nova-compute, ikiweka kikomo idadi ya maombi kwa nova-database ili kuepuka matatizo na hifadhidata. kupunguza uthabiti wa mzigo).
- Nova-conductor hupokea taarifa iliyoombwa kutoka kwa nova-database na kuipitisha kwa nova-compute.
- Ifuatayo, tazama simu za nova-compute ili kupata kitambulisho cha picha. Glace huthibitisha ombi katika Keystone na kurejesha maelezo yaliyoombwa.
- Nova-compute mawasiliano nyutroni ili kupata taarifa kuhusu vigezo mtandao. Sawa na kutazama, nyutroni huthibitisha ombi katika Keystone, na kisha kuunda ingizo katika hifadhidata (kitambulisho cha bandari, n.k.), huunda ombi la kuunda lango, na kurudisha taarifa iliyoombwa kwa nova-compute.
- Nova-compute waasiliani na ombi la kutenga kiasi kwa mashine pepe. Sawa na kutazama, cider huthibitisha ombi katika Keystone, huunda ombi la kuunda sauti, na kurejesha maelezo yaliyoombwa.
- Nova-compute contacts libvirt na ombi la kupeleka mashine pepe yenye vigezo maalum.
Kwa kweli, operesheni inayoonekana rahisi ya kuunda mashine rahisi ya kawaida hugeuka kuwa kimbunga cha simu za API kati ya vipengele vya jukwaa la wingu. Zaidi ya hayo, kama unaweza kuona, hata huduma zilizowekwa hapo awali pia zinajumuisha vipengele vidogo kati ya mwingiliano hutokea. Kuunda mashine ni sehemu ndogo tu ya kile jukwaa la wingu hukuruhusu kufanya - kuna huduma inayohusika na kusawazisha trafiki, huduma inayohusika na uhifadhi wa block, huduma inayowajibika kwa DNS, huduma inayohusika na utoaji wa seva za chuma wazi, nk. . Wingu hukuruhusu kutibu mashine zako pepe kama kundi la kondoo (kinyume na uboreshaji). Ikiwa kitu kitatokea kwa mashine yako katika mazingira ya kawaida - unairejesha kutoka kwa chelezo, nk, lakini programu za wingu zimejengwa kwa njia ambayo mashine ya kawaida haina jukumu muhimu kama hilo - mashine ya kawaida "ilikufa" - hakuna shida. - mpya imeundwa tu gari inategemea kiolezo na, kama wanasema, kikosi hakikugundua upotezaji wa mpiganaji. Kwa kawaida, hii hutoa uwepo wa mifumo ya ochestration - kwa kutumia templeti za Joto, unaweza kupeleka kwa urahisi kazi ngumu inayojumuisha kadhaa ya mitandao na mashine za kawaida.
Inafaa kukumbuka kila wakati kuwa hakuna miundombinu ya wingu bila mtandao - kila kitu kwa njia moja au nyingine huingiliana na vitu vingine kupitia mtandao. Kwa kuongeza, wingu ina mtandao usio na static kabisa. Kwa kawaida, mtandao wa chini ni zaidi au chini ya tuli - nodi mpya na swichi haziongezwe kila siku, lakini sehemu ya juu inaweza kubadilika kila wakati - mitandao mpya itaongezwa au kufutwa, mashine mpya za mtandao zitaonekana na za zamani zitatokea. kufa. Na kama unavyokumbuka kutoka kwa ufafanuzi wa wingu uliotolewa mwanzoni mwa kifungu, rasilimali zinapaswa kugawiwa mtumiaji kiotomatiki na kwa uingiliaji mdogo (au bora zaidi, bila) kutoka kwa mtoa huduma. Hiyo ni, aina ya utoaji wa rasilimali za mtandao ambazo sasa zipo katika mfumo wa mwisho wa mbele katika mfumo wa akaunti yako ya kibinafsi inayopatikana kupitia http/https na mhandisi wa mtandao wa kazini Vasily kama backend sio wingu, hata. ikiwa Vasily ana mikono minane.
Neutron, kama huduma ya mtandao, hutoa API ya kudhibiti sehemu ya mtandao ya miundombinu ya wingu. Huduma ina nguvu na kudhibiti sehemu ya mtandao ya Openstack kwa kutoa safu ya uondoaji inayoitwa Network-as-a-Service (NaaS). Hiyo ni, mtandao ni kitengo sawa cha kupimika kama, kwa mfano, cores virtual CPU au kiasi cha RAM.
Lakini kabla ya kuendelea na usanifu wa sehemu ya mtandao ya OpenStack, hebu tuchunguze jinsi mtandao huu unavyofanya kazi katika OpenStack na kwa nini mtandao ni sehemu muhimu na muhimu ya wingu.
Kwa hivyo tuna VM mbili za mteja RED na VM mbili za GREEN mteja. Wacha tufikirie kuwa mashine hizi ziko kwenye hypervisors mbili kwa njia hii:
Kwa sasa, hii ni uboreshaji wa seva 4 tu na hakuna chochote zaidi, kwani hadi sasa tulichofanya ni kuboresha seva 4, kuziweka kwenye seva mbili za mwili. Na hadi sasa hawajaunganishwa hata kwenye mtandao.
Ili kufanya wingu, tunahitaji kuongeza vipengele kadhaa. Kwanza, tunaboresha sehemu ya mtandao - tunahitaji kuunganisha mashine hizi 4 kwa jozi, na wateja wanataka muunganisho wa L2. Unaweza kutumia kubadili na kusanidi shina katika mwelekeo wake na kutatua kila kitu kwa kutumia daraja la linux au, kwa watumiaji wa juu zaidi, openvswitch (tutarudi kwa hili baadaye). Lakini kunaweza kuwa na mitandao mingi, na kusukuma L2 kila wakati kupitia swichi sio wazo bora - kuna idara tofauti, dawati la huduma, miezi ya kungojea ombi kukamilika, wiki za utatuzi - katika ulimwengu wa kisasa. mbinu haifanyi kazi tena. Na kwa haraka kampuni inaelewa hili, ni rahisi zaidi kusonga mbele. Kwa hivyo, kati ya hypervisors tutachagua mtandao wa L3 ambao mashine zetu za kawaida zitawasiliana, na juu ya mtandao huu wa L3 tutaunda mitandao ya ufunikaji ya L2 ambapo trafiki ya mashine zetu za kawaida itaendesha. Unaweza kutumia GRE, Geneve au VxLAN kama encapsulation. Wacha tuzingatie mwisho kwa sasa, ingawa sio muhimu sana.
Tunahitaji kupata VTEP mahali fulani (natumai kila mtu anafahamu istilahi za VxLAN). Kwa kuwa tuna mtandao wa L3 unaokuja moja kwa moja kutoka kwa seva, hakuna kinachotuzuia kuweka VTEP kwenye seva zenyewe, na OVS (OpenvSwitch) ni bora katika kufanya hivi. Kama matokeo, tulipata muundo huu:
Kwa kuwa trafiki kati ya VM lazima igawanywe, bandari kuelekea mashine pepe zitakuwa na nambari tofauti za vlan. Nambari ya lebo ina jukumu tu ndani ya swichi moja ya kawaida, kwani inapowekwa kwenye VxLAN tunaweza kuiondoa kwa urahisi, kwani tutakuwa na VNI.
Sasa tunaweza kuunda mashine zetu na mitandao ya mtandaoni kwao bila matatizo yoyote.
Hata hivyo, vipi ikiwa mteja ana mashine nyingine, lakini iko kwenye mtandao tofauti? Tunahitaji mizizi kati ya mitandao. Tutaangalia chaguo rahisi wakati uelekezaji wa kati unatumiwa - ambayo ni, trafiki inapitishwa kupitia nodi maalum za mtandao zilizojitolea (vizuri, kama sheria, zinajumuishwa na nodi za udhibiti, kwa hivyo tutakuwa na kitu kimoja).
Inaonekana kama hakuna kitu ngumu - tunatengeneza kiolesura cha daraja kwenye nodi ya kudhibiti, tunaendesha trafiki kwake na kutoka hapo tunaielekeza tunapohitaji. Lakini tatizo ni kwamba mteja wa RED anataka kutumia mtandao wa 10.0.0.0/24, na mteja wa GREEN anataka kutumia mtandao wa 10.0.0.0/24. Hiyo ni, tunaanza kukatiza nafasi za anwani. Zaidi ya hayo, wateja hawataki wateja wengine waweze kutumia mitandao yao ya ndani, ambayo ina maana. Ili kutenganisha mitandao na trafiki ya data ya mteja, tutatenga nafasi tofauti ya majina kwa kila mmoja wao. Nafasi ya majina kwa hakika ni nakala ya rundo la mtandao wa Linux, yaani, wateja katika nafasi ya majina RED wametengwa kabisa na wateja kutoka nafasi ya majina GREEN (vizuri, njia kati ya mitandao hii ya wateja inaruhusiwa kupitia nafasi ya majina chaguomsingi au kwenye vifaa vya usafiri vya juu).
Hiyo ni, tunapata mchoro ufuatao:
Vichungi vya L2 huungana kutoka nodi zote za kompyuta hadi nodi ya kudhibiti. nodi ambapo kiolesura cha L3 cha mitandao hii kinapatikana, kila moja katika nafasi maalum ya jina ili kutengwa.
Walakini, tulisahau jambo muhimu zaidi. Mashine ya mtandaoni lazima itoe huduma kwa mteja, yaani, inapaswa kuwa na angalau kiolesura kimoja cha nje ambacho kinaweza kufikiwa. Hiyo ni, tunahitaji kwenda nje katika ulimwengu wa nje. Kuna chaguzi tofauti hapa. Wacha tufanye chaguo rahisi zaidi. Tutaongeza mtandao mmoja kwa kila mteja, ambao utakuwa halali katika mtandao wa mtoa huduma na hautaingiliana na mitandao mingine. Mitandao pia inaweza kukatiza na kuangalia VRF tofauti kwenye upande wa mtandao wa mtoaji. Data ya mtandao pia itaishi katika nafasi ya majina ya kila mteja. Walakini, bado wataenda nje kwa ulimwengu wa nje kupitia kiolesura kimoja cha kimwili (au kifungo, ambacho kina mantiki zaidi). Ili kutenganisha trafiki ya mteja, trafiki inayoenda nje itawekwa lebo ya VLAN iliyotengwa kwa mteja.
Kama matokeo, tulipata mchoro huu:
Swali linalofaa ni kwa nini usifanye lango kwenye nodi za compute wenyewe? Hili sio shida kubwa; zaidi ya hayo, ikiwa utawasha kipanga njia kilichosambazwa (DVR), hii itafanya kazi. Katika hali hii, tunazingatia chaguo rahisi zaidi na lango la kati, ambalo hutumiwa kwa chaguo-msingi katika Openstack. Kwa vitendaji vya upakiaji wa juu, watatumia kipanga njia kilichosambazwa na teknolojia za kuongeza kasi kama vile SR-IOV na Passthrough, lakini kama wanasema, hiyo ni hadithi tofauti kabisa. Kwanza, hebu tushughulike na sehemu ya msingi, na kisha tutaingia kwenye maelezo.
Kwa kweli, mpango wetu tayari unafanya kazi, lakini kuna nuances kadhaa:
- Tunahitaji kwa namna fulani kulinda mashine zetu, yaani, kuweka kichungi kwenye kiolesura cha kubadili kuelekea mteja.
- Fanya uwezekano wa mashine ya kawaida kupata anwani ya IP kiotomatiki, ili usihitaji kuingia ndani yake kupitia console kila wakati na kusajili anwani.
Wacha tuanze na ulinzi wa mashine. Kwa hili unaweza kutumia iptables za banal, kwa nini sivyo.
Hiyo ni, sasa topolojia yetu imekuwa ngumu zaidi:
Hebu tuendelee. Tunahitaji kuongeza seva ya DHCP. Mahali pazuri zaidi pa kupata seva za DHCP kwa kila mteja itakuwa nodi ya udhibiti iliyotajwa hapo juu, ambapo nafasi za majina ziko:
Hata hivyo, kuna tatizo ndogo. Itakuwaje ikiwa kila kitu kitaanza upya na habari zote kuhusu anwani za kukodisha kwenye DHCP zitatoweka. Ni busara kwamba mashine zitapewa anwani mpya, ambayo si rahisi sana. Kuna njia mbili hapa - ama tumia majina ya kikoa na uongeze seva ya DNS kwa kila mteja, basi anwani haitakuwa muhimu sana kwetu (sawa na sehemu ya mtandao katika k8s) - lakini kuna shida na mitandao ya nje, kwani anwani zinaweza pia kutolewa ndani yao kupitia DHCP - unahitaji maingiliano na seva za DNS kwenye jukwaa la wingu na seva ya nje ya DNS, ambayo kwa maoni yangu si rahisi sana, lakini inawezekana kabisa. Au chaguo la pili ni kutumia metadata - yaani, kuhifadhi habari kuhusu anwani iliyotolewa kwa mashine ili seva ya DHCP ijue ni anwani gani ya kutoa kwa mashine ikiwa mashine tayari imepokea anwani. Chaguo la pili ni rahisi na rahisi zaidi, kwani inakuwezesha kuokoa maelezo ya ziada kuhusu gari. Sasa hebu tuongeze metadata ya wakala kwenye mchoro:
Suala jingine ambalo pia linafaa kujadiliwa ni uwezo wa kutumia mtandao mmoja wa nje na wateja wote, kwa kuwa mitandao ya nje, ikiwa ni lazima iwe halali katika mtandao mzima, itakuwa vigumu - unahitaji daima kutenga na kudhibiti ugawaji wa mitandao hii. Uwezo wa kutumia mtandao mmoja wa nje uliowekwa tayari kwa wateja wote utakuwa muhimu sana wakati wa kuunda wingu la umma. Hii itarahisisha kusambaza mashine kwa sababu si lazima kushauriana na hifadhidata ya anwani na kuchagua nafasi ya kipekee ya anwani kwa mtandao wa nje wa kila mteja. Kwa kuongeza, tunaweza kusajili mtandao wa nje mapema na wakati wa kupelekwa tutahitaji tu kuhusisha anwani za nje na mashine za mteja.
Na hapa NAT inakuja kutusaidia - tutafanya iwezekane kwa wateja kufikia ulimwengu wa nje kupitia nafasi chaguomsingi ya majina kwa kutumia tafsiri ya NAT. Kweli, hapa kuna shida ndogo. Hii ni nzuri ikiwa seva ya mteja inafanya kazi kama mteja na sio kama seva - yaani, inaanzisha badala ya kukubali miunganisho. Lakini kwetu itakuwa kinyume chake. Katika kesi hii, tunahitaji kufanya lengwa la NAT ili wakati wa kupokea trafiki, nodi ya udhibiti ielewe kuwa trafiki hii inakusudiwa mashine pepe A ya mteja A, ambayo inamaanisha tunahitaji kufanya tafsiri ya NAT kutoka kwa anwani ya nje, kwa mfano 100.1.1.1 .10.0.0.1, kwa anwani ya ndani 100. Katika kesi hii, ingawa wateja wote watatumia mtandao sawa, kutengwa kwa ndani kunahifadhiwa kabisa. Hiyo ni, tunahitaji kufanya dNAT na sNAT kwenye nodi ya udhibiti. Iwapo utatumia mtandao mmoja wenye anwani zinazoelea au mitandao ya nje, au zote mbili kwa wakati mmoja, inategemea kile unachotaka kuleta kwenye wingu. Hatutaongeza anwani zinazoelea kwenye mchoro, lakini tutaacha mitandao ya nje tayari imeongezwa mapema - kila mteja ana mtandao wake wa nje (kwenye mchoro wameonyeshwa kama vlan 200 na XNUMX kwenye kiolesura cha nje).
Matokeo yake, tulipokea ufumbuzi wa kuvutia na wakati huo huo uliofikiriwa vizuri, ambao una kubadilika fulani lakini bado hauna taratibu za kuvumilia makosa.
Kwanza, tuna nodi moja tu ya kudhibiti - kushindwa kwake kutasababisha kuanguka kwa mifumo yote. Ili kurekebisha tatizo hili, unahitaji kufanya angalau akidi ya nodi 3. Wacha tuongeze hii kwenye mchoro:
Kwa kawaida, nodes zote zinapatanishwa na wakati node inayofanya kazi inaondoka, node nyingine itachukua majukumu yake.
Shida inayofuata ni diski za mashine halisi. Kwa sasa, zimehifadhiwa kwenye hypervisors wenyewe, na katika kesi ya matatizo na hypervisor, tunapoteza data zote - na uwepo wa uvamizi hautasaidia hapa ikiwa hatupoteza diski, lakini seva nzima. Ili kufanya hivyo, tunahitaji kutengeneza huduma ambayo itafanya kama sehemu ya mbele ya uhifadhi wa aina fulani. Ni aina gani ya uhifadhi itakuwa sio muhimu sana kwetu, lakini inapaswa kulinda data yetu kutokana na kushindwa kwa diski na node, na ikiwezekana baraza la mawaziri lote. Kuna chaguzi kadhaa hapa - kuna, kwa kweli, mitandao ya SAN na Fiber Channel, lakini hebu tuwe waaminifu - FC tayari ni nakala ya zamani - analog ya E1 katika usafirishaji - ndio, nakubali, bado inatumika, lakini tu ambapo haiwezekani kabisa bila hiyo. Kwa hivyo, singetuma mtandao wa FC kwa hiari mwaka wa 2020, nikijua kuwa kuna njia mbadala zinazovutia zaidi. Ingawa kwa kila mtu wake, kunaweza kuwa na wale wanaoamini kuwa FC na mapungufu yake yote ndio tunayohitaji - sitabishana, kila mtu ana maoni yake. Walakini, suluhisho la kufurahisha zaidi kwa maoni yangu ni kutumia SDS, kama vile Ceph.
Ceph hukuruhusu kuunda suluhisho la uhifadhi wa data linalopatikana sana na rundo la chaguzi zinazowezekana za chelezo, kuanzia na nambari na ukaguzi wa usawa (sawa na uvamizi 5 au 6) na kuishia na nakala kamili ya data kwa diski tofauti, kwa kuzingatia eneo la diski ndani. seva, na seva katika makabati, nk.
Ili kuunda Ceph unahitaji nodi 3 zaidi. Mwingiliano na hifadhi pia utafanywa kupitia mtandao kwa kutumia huduma za kuzuia, kitu na kuhifadhi faili. Wacha tuongeze uhifadhi kwenye schema:
Kumbuka: unaweza pia kufanya nodi za compute za hyperconverged - hii ni dhana ya kuchanganya kazi kadhaa kwenye node moja - kwa mfano, kuhifadhi + compute - bila kujitolea nodes maalum kwa hifadhi ya ceph. Tutapata mpango sawa wa kuhimili makosa - kwa kuwa SDS itahifadhi data na kiwango cha uhifadhi tunachobainisha. Walakini, nodi zilizo na hyperconverged kila wakati ni maelewano - kwani nodi ya uhifadhi haichoshi hewa tu kama inavyoonekana mwanzoni (kwani hakuna mashine za kawaida juu yake) - hutumia rasilimali za CPU kuhudumia SDS (kwa kweli, hufanya yote. replication na ahueni baada ya kushindwa kwa nodi, disks, nk). Hiyo ni, utapoteza baadhi ya nguvu za node ya compute ikiwa unachanganya na hifadhi.
Vitu hivi vyote vinahitaji kusimamiwa kwa njia fulani - tunahitaji kitu ambacho tunaweza kuunda mashine, mtandao, kipanga njia cha mtandao, n.k. Ili kufanya hivyo, tutaongeza huduma kwenye nodi ya udhibiti ambayo itafanya kama dashibodi - mteja ataweza kuunganisha kwenye tovuti hii kupitia http/ https na kufanya kila kitu anachohitaji (vizuri, karibu).
Matokeo yake, sasa tuna mfumo wa kustahimili makosa. Vipengele vyote vya miundombinu hii lazima vidhibitiwe kwa njia fulani. Hapo awali ilielezwa kuwa Openstack ni seti ya miradi, ambayo kila mmoja hutoa kazi maalum. Kama tunavyoona, kuna zaidi ya vipengele vya kutosha ambavyo vinahitaji kusanidiwa na kudhibitiwa. Leo tutazungumza juu ya sehemu ya mtandao.
Usanifu wa Neutron
Katika OpenStack, ni Neutron ambayo ina jukumu la kuunganisha bandari za mashine kwenye mtandao wa kawaida wa L2, kuhakikisha uelekezaji wa trafiki kati ya VM zilizo kwenye mitandao tofauti ya L2, na vile vile uelekezaji wa nje, kutoa huduma kama vile NAT, IP ya Kuelea, DHCP, n.k.
Kwa kiwango cha juu, uendeshaji wa huduma ya mtandao (sehemu ya msingi) inaweza kuelezewa kama ifuatavyo.
Wakati wa kuanzisha VM, huduma ya mtandao:
- Huunda lango la VM fulani (au bandari) na kuarifu huduma ya DHCP kuihusu;
- Kifaa kipya cha mtandao cha mtandao kinaundwa (kupitia libvirt);
- VM inaunganishwa na bandari iliyoundwa katika hatua ya 1;
Cha ajabu, kazi ya Neutron inategemea mifumo ya kawaida inayojulikana kwa kila mtu ambaye amewahi kupiga mbizi kwenye Linux - nafasi za majina, iptables, madaraja ya linux, openvswitch, conntrack, n.k.
Inapaswa kufafanuliwa mara moja kuwa Neutron sio kidhibiti cha SDN.
Neutron ina vipengele kadhaa vilivyounganishwa:
Openstack-neutron-server ni daemon inayofanya kazi na maombi ya mtumiaji kupitia API. Pepo hili halihusiki katika kusajili miunganisho yoyote ya mtandao, lakini hutoa taarifa muhimu kwa hili kwa programu-jalizi zake, ambazo kisha husanidi kipengele cha mtandao kinachohitajika. Mawakala wa nyutroni kwenye nodi za OpenStack hujisajili na seva ya Neutron.
Seva ya Neutron kwa kweli ni programu iliyoandikwa kwa python, inayojumuisha sehemu mbili:
- REST huduma
- Programu-jalizi ya Neutron (msingi/huduma)
Huduma ya REST imeundwa kupokea simu za API kutoka kwa vipengele vingine (kwa mfano, ombi la kutoa taarifa fulani, nk.)
Programu-jalizi ni sehemu/moduli za programu-jalizi ambazo huitwa wakati wa maombi ya API - yaani, maelezo ya huduma hutokea kupitia kwao. Plugins imegawanywa katika aina mbili - huduma na mizizi. Kama sheria, programu-jalizi ya farasi ina jukumu kubwa la kudhibiti nafasi ya anwani na miunganisho ya L2 kati ya VM, na programu-jalizi za huduma tayari hutoa utendakazi wa ziada kama vile VPN au FW.
Orodha ya programu-jalizi zinazopatikana leo zinaweza kutazamwa kwa mfano
Kunaweza kuwa na programu-jalizi kadhaa za huduma, lakini kunaweza kuwa na programu-jalizi moja tu ya farasi.
Openstack-neutron-ml2 ndio programu-jalizi ya kawaida ya Openstack. Programu-jalizi hii ina usanifu wa kawaida (tofauti na mtangulizi wake) na husanidi huduma ya mtandao kupitia viendeshaji vilivyounganishwa nayo. Tutaangalia programu-jalizi yenyewe baadaye kidogo, kwani kwa kweli inatoa ubadilikaji ambao OpenStack inayo katika sehemu ya mtandao. Programu-jalizi ya mizizi inaweza kubadilishwa (kwa mfano, Mtandao wa Contrail hufanya uingizwaji kama huo).
Huduma ya RPC (rabbitmq-server) β huduma ambayo hutoa usimamizi wa foleni na mwingiliano na huduma zingine za OpenStack, pamoja na mwingiliano kati ya mawakala wa huduma za mtandao.
Mawakala wa mtandao - mawakala ambao wako katika kila nodi, ambayo huduma za mtandao husanidiwa.
Kuna aina kadhaa za mawakala.
Wakala mkuu ni wakala wa L2. Wakala hawa huendesha kwenye kila hypervisors, ikiwa ni pamoja na nodi za udhibiti (kwa usahihi zaidi, kwenye nodi zote zinazotoa huduma yoyote kwa wapangaji) na kazi yao kuu ni kuunganisha mashine za kawaida kwenye mtandao wa kawaida wa L2, na pia kuzalisha tahadhari wakati matukio yoyote yanatokea ( kwa mfano zima / wezesha bandari).
Ifuatayo, sio wakala muhimu sana wakala wa L3. Kwa chaguo-msingi, wakala huyu anaendesha pekee kwenye nodi ya mtandao (mara nyingi nodi ya mtandao inaunganishwa na nodi ya kudhibiti) na hutoa njia kati ya mitandao ya wapangaji (zote kati ya mitandao yake na mitandao ya wapangaji wengine, na inapatikana kwa ulimwengu wa nje, kutoa NAT, pamoja na huduma ya DHCP). Hata hivyo, wakati wa kutumia DVR (router iliyosambazwa), haja ya Plugin ya L3 pia inaonekana kwenye nodes za compute.
Wakala wa L3 hutumia nafasi za majina za Linux kumpa kila mpangaji seti ya mitandao yake iliyojitenga na utendakazi wa vipanga njia pepe vinavyoelekeza trafiki na kutoa huduma za lango la mitandao ya Tabaka 2.
Database - hifadhidata ya vitambulisho vya mitandao, subnets, bandari, mabwawa, nk.
Kwa kweli, Neutron inakubali maombi ya API kutoka kwa kuundwa kwa huluki zozote za mtandao, huthibitisha ombi, na kupitia RPC (ikiwa inafikia programu-jalizi fulani au wakala) au REST API (ikiwa inawasiliana katika SDN) hutuma kwa mawakala (kupitia programu-jalizi) maelekezo muhimu ili kupanga huduma iliyoombwa.
Sasa hebu tugeuke kwenye ufungaji wa mtihani (jinsi inavyotumiwa na ni nini kilichojumuishwa ndani yake, tutaona baadaye katika sehemu ya vitendo) na tuone ambapo kila sehemu iko:
(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 ~]$
Kwa kweli, huo ndio muundo mzima wa Neutron. Sasa inafaa kutumia muda kwenye programu-jalizi ya ML2.
Safu ya Modular 2
Kama ilivyoelezwa hapo juu, programu-jalizi ni programu-jalizi ya kawaida ya OpenStack na ina usanifu wa kawaida.
Mtangulizi wa Plugin ya ML2 alikuwa na muundo wa monolithic, ambao haukuruhusu, kwa mfano, kutumia mchanganyiko wa teknolojia kadhaa katika ufungaji mmoja. Kwa mfano, haungeweza kutumia openvswitch na linuxbridge kwa wakati mmoja - ama ya kwanza au ya pili. Kwa sababu hii, programu-jalizi ya ML2 yenye usanifu wake iliundwa.
ML2 ina vipengele viwili - aina mbili za madereva: madereva ya aina na madereva ya Mechanism.
Aina za madereva kuamua teknolojia ambazo zitatumika kuandaa miunganisho ya mtandao, kwa mfano VxLAN, VLAN, GRE. Wakati huo huo, dereva inaruhusu matumizi ya teknolojia tofauti. Teknolojia ya kawaida ni encapsulation ya VxLAN kwa mitandao ya juu na mitandao ya nje ya vlan.
Viendeshaji vya aina ni pamoja na aina zifuatazo za mtandao:
Flat - mtandao bila kuweka alama
VLAN - mtandao uliowekwa alama
Mitaa - aina maalum ya mtandao kwa usakinishaji wa kila mmoja (usakinishaji kama huo unahitajika kwa wasanidi programu au kwa mafunzo)
GRE - funika mtandao kwa kutumia vichuguu vya GRE
VxLAN β funika mtandao kwa kutumia vichuguu vya VxLAN
Waendeshaji wa utaratibu fafanua zana zinazohakikisha shirika la teknolojia zilizoainishwa katika kiendeshi cha aina - kwa mfano, openvswitch, sr-iov, opendaylight, OVN, nk.
Kulingana na utekelezaji wa kiendeshi hiki, mawakala wanaodhibitiwa na Neutron watatumiwa, au viunganisho kwa kidhibiti cha nje cha SDN kitatumika, ambacho kinashughulikia masuala yote yanayohusiana na kupanga mitandao ya L2, uelekezaji, n.k.
Mfano: ikiwa tunatumia ML2 pamoja na OVS, basi wakala wa L2 husakinishwa kwenye kila nodi ya kompyuta inayosimamia OVS. Hata hivyo, ikiwa tunatumia, kwa mfano, OVN au OpenDayLight, basi udhibiti wa OVS unakuja chini ya mamlaka yao - Neutron, kupitia programu-jalizi ya mizizi, inatoa amri kwa mtawala, na tayari hufanya kile kilichoambiwa.
Wacha tuboreshe Fungua vSwitch
Kwa sasa, moja ya vipengele muhimu vya OpenStack ni Open vSwitch.
Wakati wa kusakinisha OpenStack bila SDN yoyote ya ziada ya muuzaji kama vile Juniper Contrail au Nokia Nuage, OVS ndio sehemu kuu ya mtandao wa mtandao wa wingu na, pamoja na iptables, contrack, namespaces, hukuruhusu kupanga mitandao kamili ya upangaji wa upangaji mwingi. Kwa kawaida, sehemu hii inaweza kubadilishwa, kwa mfano, wakati wa kutumia ufumbuzi wa wamiliki wa tatu (muuzaji) wa SDN.
OVS ni swichi ya programu huria ambayo imeundwa kwa ajili ya matumizi katika mazingira yaliyoboreshwa kama kisambaza data pepe.
Kwa sasa, OVS ina utendakazi mzuri sana, unaojumuisha teknolojia kama vile QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, n.k.
Kumbuka: OVS haikubuniwa kama swichi laini ya vitendaji vya mawasiliano vilivyopakiwa sana na iliundwa zaidi kwa vitendaji vya IT ambavyo vinahitaji kipimo data kidogo kama vile seva ya WEB au seva ya barua. Hata hivyo, OVS inaendelezwa zaidi na utekelezaji wa sasa wa OVS umeboresha sana utendaji na uwezo wake, ambayo inaruhusu kutumiwa na waendeshaji wa mawasiliano ya simu na kazi zilizojaa sana, kwa mfano, kuna utekelezaji wa OVS na usaidizi wa kuongeza kasi ya DPDK.
Kuna vipengele vitatu muhimu vya OVS ambavyo unapaswa kufahamu:
- Moduli ya Kernel - sehemu iliyo kwenye nafasi ya kernel ambayo inashughulikia trafiki kulingana na sheria zilizopokelewa kutoka kwa kipengele cha kudhibiti;
- vSwitch daemon (ovs-vswitchd) ni mchakato uliozinduliwa katika nafasi ya mtumiaji ambayo inawajibika kwa kupanga moduli ya kernel - ambayo ni, inawakilisha moja kwa moja mantiki ya uendeshaji wa swichi.
- Seva ya hifadhidata - hifadhidata ya ndani iko kwenye kila mwenyeji anayeendesha OVS, ambayo usanidi huhifadhiwa. Vidhibiti vya SDN vinaweza kuwasiliana kupitia moduli hii kwa kutumia itifaki ya OVSDB.
Yote hii inaambatana na seti ya huduma za uchunguzi na usimamizi, kama vile ovs-vsctl, ovs-appctl, ovs-ofctl, nk.
Hivi sasa, Openstack inatumiwa sana na waendeshaji wa mawasiliano ya simu kuhamishia huduma za mtandao kwake, kama vile EPC, SBC, HLR, n.k. Baadhi ya vitendaji vinaweza kuishi bila matatizo na OVS kama ilivyo, lakini kwa mfano, EPC huchakata trafiki ya mteja - kisha hupitia. kiasi kikubwa cha trafiki (sasa kiasi cha trafiki kinafikia gigabits mia kadhaa kwa pili). Kwa kawaida, kuendesha trafiki kama hiyo kupitia nafasi ya kernel (kwani mtoaji iko hapo kwa chaguo-msingi) sio wazo bora. Kwa hivyo, OVS mara nyingi hutumwa kabisa katika nafasi ya mtumiaji kwa kutumia teknolojia ya kuongeza kasi ya DPDK kusambaza trafiki kutoka NIC hadi nafasi ya mtumiaji kwa kupita kernel.
Kumbuka: kwa wingu iliyotumiwa kwa kazi za mawasiliano ya simu, inawezekana kutoa trafiki kutoka kwa nodi ya compute inayopita OVS moja kwa moja hadi vifaa vya kubadili. Njia za SR-IOV na Passthrough hutumiwa kwa kusudi hili.
Je, hii inafanyaje kazi kwenye mpangilio halisi?
Kweli, sasa hebu tuendelee kwenye sehemu ya vitendo na tuone jinsi yote inavyofanya kazi katika mazoezi.
Kwanza, hebu tupeleke usakinishaji rahisi wa Openstack. Kwa kuwa sina seti ya seva karibu kwa majaribio, tutakusanya mfano kwenye seva moja halisi kutoka kwa mashine pepe. Ndiyo, kwa kawaida, ufumbuzi huo haufaa kwa madhumuni ya kibiashara, lakini kuona mfano wa jinsi mtandao unavyofanya kazi katika Openstack, ufungaji huo ni wa kutosha kwa macho. Kwa kuongezea, usanikishaji kama huo unavutia zaidi kwa madhumuni ya mafunzo - kwani unaweza kupata trafiki, nk.
Kwa kuwa tunahitaji tu kuona sehemu ya msingi, hatuwezi kutumia mitandao kadhaa lakini kuinua kila kitu kwa kutumia mitandao miwili tu, na mtandao wa pili katika mpangilio huu utatumika pekee kwa upatikanaji wa chini ya wingu na seva ya DNS. Hatutagusa mitandao ya nje kwa sasa - hii ni mada ya nakala kubwa tofauti.
Kwa hiyo, hebu tuanze kwa utaratibu. Kwanza, nadharia kidogo. Tutasakinisha Openstack kwa kutumia TripleO (Openstack kwenye Openstack). Kiini cha TripleO ni kwamba tunasakinisha Openstack yote kwa moja (yaani, kwenye nodi moja), inayoitwa undercloud, na kisha kutumia uwezo wa Openstack iliyotumika kusakinisha Openstack inayokusudiwa kufanya kazi, inayoitwa overcloud. Undercloud itatumia uwezo wake wa asili wa kusimamia seva za kimwili (chuma tupu) - mradi wa Kejeli - kutoa hypervisors ambazo zitafanya majukumu ya kuhesabu, kudhibiti, nodi za kuhifadhi. Hiyo ni, hatutumii zana zozote za wahusika wengine kupeleka Openstack - tunasambaza Openstack kwa kutumia Openstack. Itakuwa wazi zaidi kadiri usakinishaji unavyoendelea, kwa hivyo hatutaishia hapo na kusonga mbele.
Kumbuka: Katika makala hii, kwa ajili ya unyenyekevu, sikutumia kutengwa kwa mtandao kwa mitandao ya ndani ya Openstack, lakini kila kitu kinatumiwa kwa kutumia mtandao mmoja tu. Hata hivyo, kuwepo au kutokuwepo kwa kutengwa kwa mtandao hakuathiri utendaji wa msingi wa suluhisho - kila kitu kitafanya kazi sawa na wakati wa kutumia kutengwa, lakini trafiki itapita kwenye mtandao huo. Kwa usakinishaji wa kibiashara, kwa asili ni muhimu kutumia kutengwa kwa kutumia vlans tofauti na miingiliano. Kwa mfano, trafiki ya usimamizi wa uhifadhi wa ceph na trafiki ya data yenyewe (ufikiaji wa mashine kwa diski, nk) wakati umetengwa tumia subnets tofauti (Usimamizi wa Uhifadhi na Uhifadhi) na hii inakuwezesha kufanya ufumbuzi uwe wa kustahimili makosa zaidi kwa kugawa trafiki hii, kwa mfano. , kwenye milango tofauti, au kutumia wasifu tofauti wa QoS kwa trafiki tofauti ili trafiki ya data isibanye kuashiria trafiki. Kwa upande wetu, wataenda kwenye mtandao huo na kwa kweli hii haina kikomo kwetu kwa njia yoyote.
Kumbuka: Kwa kuwa tutaendesha mashine pepe katika mazingira ya mtandaoni kulingana na mashine pepe, tunahitaji kwanza kuwezesha uboreshaji uliowekwa.
Unaweza kuangalia ikiwa uboreshaji uliowekwa kwenye kiota umewezeshwa au la kama hii:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Ikiwa utaona herufi N, basi tunawezesha usaidizi wa uboreshaji wa kiota kulingana na mwongozo wowote unaopata kwenye mtandao, kwa mfano. .
Tunahitaji kukusanya mzunguko ufuatao kutoka kwa mashine za kawaida:
Katika kesi yangu, kuunganisha mashine za kawaida ambazo ni sehemu ya usakinishaji wa siku zijazo (na nilipata 7 kati yao, lakini unaweza kupata na 4 ikiwa huna rasilimali nyingi), nilitumia OpenvSwitch. Niliunda daraja moja la ovs na kuunganisha mashine za kawaida kwake kupitia vikundi vya bandari. Ili kufanya hivyo, niliunda faili ya xml kama hii:
[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>Vikundi vitatu vya bandari vinatangazwa hapa - ufikiaji mbili na shina moja (mwisho ulihitajika kwa seva ya DNS, lakini unaweza kufanya bila hiyo, au kuiweka kwenye mashine ya mwenyeji - chochote kinachofaa zaidi kwako). Ifuatayo, kwa kutumia kiolezo hiki, tunatangaza chetu kupitia virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Sasa tunahariri usanidi wa bandari ya hypervisor:
[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 ~]# Kumbuka: katika hali hii, anwani kwenye port ovs-br1 haitapatikana kwa sababu haina lebo ya vlan. Ili kurekebisha hili, unahitaji kutoa amri sudo ovs-vsctl set port ovs-br1 tag=100. Walakini, baada ya kuanza upya, lebo hii itatoweka (ikiwa mtu yeyote anajua jinsi ya kuifanya iwe mahali pake, nitashukuru sana). Lakini hii sio muhimu sana, kwa sababu tutahitaji anwani hii tu wakati wa ufungaji na hatutahitaji wakati Openstack inatumiwa kikamilifu.
Ifuatayo, tunaunda mashine ya chini ya wingu:
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=ttyS0Wakati wa usanikishaji, unaweka vigezo vyote muhimu, kama vile jina la mashine, nywila, watumiaji, seva za ntp, nk, unaweza kusanidi bandari mara moja, lakini kwangu kibinafsi, baada ya usakinishaji, ni rahisi kuingia kwenye mashine kupitia. console na kurekebisha faili muhimu. Ikiwa tayari unayo picha iliyotengenezwa tayari, unaweza kuitumia, au fanya kile nilichofanya - pakua picha ndogo ya Centos 7 na uitumie kusakinisha VM.
Baada ya usakinishaji uliofanikiwa, unapaswa kuwa na mashine ya kawaida ambayo unaweza kusanikisha undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningKwanza, sasisha zana zinazohitajika kwa mchakato wa ufungaji:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Ufungaji wa chini ya wingu
Tunaunda mtumiaji wa stack, kuweka nenosiri, kuiongeza kwa sudoer na kumpa uwezo wa kutekeleza amri za mizizi kupitia sudo bila kuingiza nenosiri:
useradd stack
passwd stack
echo βstack ALL=(root) NOPASSWD:ALLβ > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackSasa tunataja jina kamili la chini ya wingu katika faili ya majeshi:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Ifuatayo, tunaongeza hazina na kusanikisha programu tunayohitaji:
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-ansibleKumbuka: ikiwa huna mpango wa kusakinisha ceph, basi huna haja ya kuingiza amri zinazohusiana na ceph. Nilitumia toleo la Queens, lakini unaweza kutumia nyingine yoyote unayopenda.
Ifuatayo, nakili faili ya usanidi wa chini ya wingu kwenye safu ya saraka ya nyumbani ya mtumiaji:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confSasa tunahitaji kusahihisha faili hii, kurekebisha kwa usakinishaji wetu.
Unahitaji kuongeza mistari hii mwanzoni mwa faili:
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 = 10Kwa hivyo, wacha tupitie mipangilio:
undercloud_jina la mwenyeji - jina kamili la seva ya chini ya wingu, lazima lilingane na ingizo kwenye seva ya DNS
mitaa_ip - anwani ya ndani ya wingu kuelekea utoaji wa mtandao
mtandao_lango - anwani ile ile ya eneo, ambayo itafanya kama lango la ufikiaji wa ulimwengu wa nje wakati wa usakinishaji wa nodi za wingu, pia inalingana na ip ya ndani.
undercloud_public_host - Anwani ya API ya nje, anwani yoyote ya bure kutoka kwa mtandao wa utoaji imepewa
undercloud_admin_host anwani ya ndani ya API, anwani yoyote ya bure kutoka kwa mtandao wa utoaji imetolewa
undercloud_nameservers - seva ya DNS
kuzalisha_huduma_cheti - mstari huu ni muhimu sana katika mfano wa sasa, kwa sababu ikiwa haujaiweka kwa uongo utapokea hitilafu wakati wa ufungaji, tatizo linaelezwa kwenye tracker ya hitilafu ya Red Hat.
kiolesura_cha_ndani interface katika utoaji wa mtandao. Kiolesura hiki kitarekebishwa tena wakati wa kupelekwa kwa wingu, kwa hivyo unahitaji kuwa na miingiliano miwili kwenye undercloud - moja ya kuipata, ya pili kwa utoaji.
mtaa_mtu - MTU. Kwa kuwa tunayo maabara ya majaribio na nina MTU ya 1500 kwenye bandari za kubadili OVS, ni muhimu kuiweka 1450 ili pakiti zilizowekwa kwenye VxLAN ziweze kupita.
mtandao_cidr - mtandao wa usambazaji
kushambulia β kwa kutumia NAT kufikia mtandao wa nje
mtandao_wa_masquerade - mtandao ambao utakuwa NATED
dhcp_anza - anwani ya kuanzia ya dimbwi la anwani ambalo anwani zitapewa nodi wakati wa kupelekwa kwa wingu
dhcp_mwisho - anwani ya mwisho ya dimbwi la anwani ambalo anwani zitapewa nodi wakati wa kupelekwa kwa wingu
ukaguzi_iprange - idadi kubwa ya anwani zinazohitajika kwa uchunguzi (haipaswi kuingiliana na dimbwi hapo juu)
Majaribio_ya_ya_max_ya_max - idadi ya juu ya majaribio ya kusakinisha wingu (lazima iwe kubwa kuliko au sawa na idadi ya nodi)
Baada ya faili kuelezewa, unaweza kutoa amri ya kupeleka undercloud:
openstack undercloud install
Utaratibu huchukua kutoka dakika 10 hadi 30 kulingana na chuma chako. Mwishowe unapaswa kuona pato kama hili:
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.
#############################################################################Pato hili linasema kuwa umesakinisha kwa ufanisi undercloud na sasa unaweza kuangalia hali ya undercloud na kuendelea kusakinisha overcloud.
Ukiangalia pato la ifconfig, utaona kuwa kiolesura kipya cha daraja kimeonekana
[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 0Usambazaji wa Overcloud sasa utatekelezwa kupitia kiolesura hiki.
Kutoka kwa matokeo hapa chini unaweza kuona kuwa tunayo huduma zote kwenye nodi moja:
(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 |
+--------------------------+-----------+----------+Ifuatayo ni usanidi wa sehemu ya mtandao wa chini ya wingu:
(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 ~]$Ufungaji wa overcloud
Kwa sasa tunayo chini ya wingu tu, na hatuna nodi za kutosha ambazo mawingu ya juu yatakusanyika. Kwa hivyo, kwanza kabisa, hebu tupeleke mashine za kawaida tunazohitaji. Wakati wa kupelekwa, undercloud yenyewe itaweka OS na programu muhimu kwenye mashine ya overcloud - yaani, hatuhitaji kupeleka mashine kabisa, lakini tu kuunda disk (au disks) kwa ajili yake na kuamua vigezo vyake - yaani. , kwa kweli, tunapata seva isiyo wazi bila OS iliyosanikishwa juu yake.
Wacha tuende kwenye folda na diski za mashine zetu za kawaida na uunda diski za saizi inayohitajika:
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 160GKwa kuwa tunafanya kazi kama mzizi, tunahitaji kubadilisha mmiliki wa diski hizi ili tusipate shida na haki:
[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]# Kumbuka: ikiwa huna mpango wa kufunga ceph ili kuisoma, basi amri haziunda angalau nodes 3 na angalau disks mbili, lakini katika template zinaonyesha kuwa disks virtual vda, vdb, nk zitatumika.
Sawa, sasa tunahitaji kufafanua mashine hizi zote:
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 Mwishoni kuna amri -print-xml > /tmp/storage-1.xml, ambayo huunda faili ya xml na maelezo ya kila mashine kwenye /tmp/ folda; ikiwa hautaiongeza, hautakuwa. uwezo wa kutambua mashine virtual.
Sasa tunahitaji kufafanua mashine hizi zote katika virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Sasa nuance ndogo - tripleO hutumia IPMI kusimamia seva wakati wa usakinishaji na uchunguzi.
Kuchunguza ni mchakato wa kukagua vifaa ili kupata vigezo vyake muhimu kwa utoaji zaidi wa nodi. Uchunguzi wa ndani unafanywa kwa kutumia kejeli, huduma iliyoundwa kufanya kazi na seva za chuma tupu.
Lakini hapa kuna shida - wakati seva za IPMI za vifaa zina bandari tofauti (au bandari iliyoshirikiwa, lakini hii sio muhimu), basi mashine za kawaida hazina bandari kama hizo. Hapa mkongojo unaoitwa vbmc unakuja kwa usaidizi wetu - matumizi ambayo hukuruhusu kuiga bandari ya IPMI. Nuance hii inafaa kuzingatia haswa kwa wale ambao wanataka kuanzisha maabara kama hiyo kwenye hypervisor ya ESXI - kuwa waaminifu, sijui ikiwa ina analog ya vbmc, kwa hivyo inafaa kujiuliza juu ya suala hili kabla ya kupeleka kila kitu. .
Weka vbmc:
yum install yum install python2-virtualbmcIkiwa OS yako haiwezi kupata kifurushi, basi ongeza hazina:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmSasa tunaanzisha matumizi. Kila kitu hapa ni banal hadi kufikia aibu. Sasa ni sawa kwamba hakuna seva kwenye orodha ya vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Ili zionekane, lazima zitangazwe kwa mikono kama hii:
[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 ~]#Nadhani syntax ya amri iko wazi bila maelezo. Walakini, kwa sasa vipindi vyetu vyote viko katika hali ya CHINI. Ili wao kuhamia hali ya UP, unahitaji kuwawezesha:
[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 ~]#Na mguso wa mwisho - unahitaji kurekebisha sheria za firewall (au uzima kabisa):
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
Sasa hebu tuende kwa undercloud na angalia ikiwa kila kitu kinafanya kazi. Anwani ya mashine ya mwenyeji ni 192.168.255.200, kwenye undercloud tuliongeza kifurushi muhimu cha ipmitool wakati wa maandalizi ya kupelekwa:
[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 runningKama unavyoona, tumefanikiwa kuzindua nodi ya udhibiti kupitia vbmc. Sasa wacha tuizime na tuendelee:
[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 ~]#Hatua inayofuata ni uchunguzi wa nodi ambazo overcloud itawekwa. Ili kufanya hivyo, tunahitaji kuandaa faili ya json na maelezo ya nodi zetu. Tafadhali kumbuka kuwa, tofauti na usakinishaji kwenye seva tupu, faili inaonyesha bandari ambayo vbmc inaendesha kwa kila mashine.
[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:27Kumbuka: node ya udhibiti ina interfaces mbili, lakini katika kesi hii hii si muhimu, katika ufungaji huu moja itakuwa ya kutosha kwa ajili yetu.
Sasa tunatayarisha faili ya json. Tunahitaji kuonyesha anwani ya poppy ya bandari ambayo utoaji utafanywa, vigezo vya nodi, kuwapa majina na kuonyesha jinsi ya kupata 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"
}
]
}Sasa tunahitaji kuandaa picha kwa kejeli. Ili kufanya hivyo, zipakue kupitia wget na usakinishe:
(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 ~]$Inapakia picha kwenye undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Inakagua kuwa picha zote zimepakiwa
(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 ~]$Jambo moja zaidi - unahitaji kuongeza seva ya DNS:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Sasa tunaweza kutoa amri ya utangulizi:
(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 ~]$Kama unaweza kuona kutoka kwa matokeo, kila kitu kimekamilika bila makosa. Wacha tuangalie ikiwa nodi zote ziko katika hali inayopatikana:
(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 ~]$ Ikiwa nodes ziko katika hali tofauti, kwa kawaida huweza kudhibitiwa, basi kitu kilikwenda vibaya na unahitaji kutazama logi na kujua kwa nini hii ilitokea. Kumbuka kuwa katika hali hii tunatumia uboreshaji wa mtandao na kunaweza kuwa na hitilafu zinazohusiana na matumizi ya mashine pepe au vbmc.
Ifuatayo, tunahitaji kuonyesha ni nodi gani itafanya kazi gani - ambayo ni, onyesha wasifu ambao nodi itatumia:
(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 ~]$Bainisha wasifu kwa kila nodi:
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-d9afb69d1167Wacha tuangalie ikiwa tulifanya kila kitu kwa usahihi:
(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 ~]$Ikiwa kila kitu ni sawa, tunatoa amri ya kupeleka mawingu:
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 qemuKatika usakinishaji halisi, templates zilizobinafsishwa zitatumika kwa kawaida, kwa upande wetu hii itakuwa ngumu sana mchakato, kwani kila hariri kwenye kiolezo italazimika kuelezewa. Kama ilivyoandikwa hapo awali, hata usakinishaji rahisi utatosha kwetu kuona jinsi inavyofanya kazi.
Kumbuka: --libvirt-aina ya qemu kutofautisha ni muhimu katika kesi hii, kwani tutatumia uboreshaji wa kiota. Vinginevyo, hutaweza kuendesha mashine pepe.
Sasa una kama saa moja, au labda zaidi (kulingana na uwezo wa vifaa) na unaweza tu kutumaini kwamba baada ya wakati huu utaona ujumbe ufuatao:
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 ~]$Sasa una toleo la karibu kamili la openstack, ambalo unaweza kusoma, kujaribu, nk.
Wacha tuangalie ikiwa kila kitu kinafanya kazi vizuri. Katika safu ya saraka ya nyumbani ya mtumiaji kuna faili mbili - stackrc moja (ya kudhibiti undercloud) na ya pili ya overcloudrc (ya kudhibiti overcloud). Faili hizi lazima zibainishwe kama chanzo, kwa kuwa zina maelezo muhimu kwa uthibitishaji.
(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 ~]$Usanikishaji wangu bado unahitaji mguso mmoja mdogo - kuongeza njia kwenye mtawala, kwani mashine ambayo ninafanya kazi iko kwenye mtandao tofauti. Ili kufanya hivyo, nenda kwa udhibiti-1 chini ya akaunti ya msimamizi wa joto na uandikishe njia
(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.254Kweli, sasa unaweza kwenda kwenye upeo wa macho. Taarifa zote - anwani, kuingia na nenosiri - ziko kwenye faili /home/stack/overcloudrc. Mchoro wa mwisho unaonekana kama hii:
Kwa njia, katika usakinishaji wetu, anwani za mashine zilitolewa kupitia DHCP na, kama unaweza kuona, zinatolewa "kwa nasibu". Unaweza kufafanua madhubuti kwenye kiolezo ambayo anwani inapaswa kushikamana na mashine gani wakati wa kupeleka, ikiwa unahitaji.
Trafiki hutiririkaje kati ya mashine pepe?
Katika makala hii tutaangalia chaguzi tatu za kupitisha trafiki
- Mashine mbili kwenye hypervisor moja kwenye mtandao mmoja wa L2
- Mashine mbili kwenye hypervisors tofauti kwenye mtandao huo wa L2
- Mashine mbili kwenye mitandao tofauti (kuweka mizizi kwenye mtandao)
Kesi zilizo na ufikiaji wa ulimwengu wa nje kupitia mtandao wa nje, kwa kutumia anwani zinazoelea, pamoja na uelekezaji uliosambazwa, tutazingatia wakati ujao, kwa sasa tutazingatia trafiki ya ndani.
Ili kuangalia, hebu tuweke pamoja mchoro ufuatao:
Tumeunda mashine 4 za kawaida - 3 kwenye mtandao mmoja wa L2 - net-1, na 1 zaidi kwenye mtandao wa 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 ~]$ Wacha tuone ni hypervisors gani mashine iliyoundwa ziko:
(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 ~]$
Mashine vm-1 na vm-3 ziko kwenye compute-0, mashine vm-2 na vm-4 ziko kwenye node compute-1.
Kwa kuongezea, kipanga njia cha mtandao kimeundwa ili kuwezesha uelekezaji kati ya mitandao maalum:
(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 ina bandari mbili pepe, ambazo hufanya kama lango la mitandao:
(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 ~]$ Lakini kabla ya kuangalia jinsi trafiki inapita, hebu tuangalie kile tulicho nacho sasa kwenye node ya udhibiti (ambayo pia ni node ya mtandao) na kwenye node ya compute. Hebu tuanze na nodi ya compute.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Kwa sasa, node ina madaraja matatu ya ovs - br-int, br-tun, br-ex. Kati yao, kama tunavyoona, kuna seti ya miingiliano. Kwa urahisi wa kuelewa, hebu tupange miingiliano hii yote kwenye mchoro na tuone kinachotokea.
Kuangalia anwani ambazo vichuguu vya VxLAN vimeinuliwa, inaweza kuonekana kuwa handaki moja imeinuliwa kwa compute-1 (192.168.255.26), handaki ya pili inaonekana kudhibiti-1 (192.168.255.15). Lakini jambo la kuvutia zaidi ni kwamba br-ex haina miingiliano ya kimwili, na ukiangalia ni mtiririko gani umeundwa, unaweza kuona kwamba daraja hili linaweza tu kuacha trafiki kwa sasa.
[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 ~]$ Kama unavyoona kutoka kwa pato, anwani imebanwa moja kwa moja hadi kwenye mlango halisi, na si kwa kiolesura cha daraja pepe.
[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 ~]$
Kwa mujibu wa sheria ya kwanza, kila kitu kilichotoka kwenye bandari ya phy-br-ex lazima kitupwe.
Kwa kweli, kwa sasa hakuna mahali pengine pa trafiki kuingia kwenye daraja hili isipokuwa kutoka kwa kiolesura hiki (kiolesura chenye br-int), na kwa kuangalia kushuka, trafiki ya BUM tayari imeingia kwenye daraja.
Hiyo ni, trafiki inaweza kuondoka nodi hii tu kupitia handaki ya VxLAN na hakuna kitu kingine chochote. Hata hivyo, ikiwa utawasha DVR, hali itabadilika, lakini tutashughulikia hilo wakati mwingine. Unapotumia kutengwa kwa mtandao, kwa mfano kutumia vlans, hautakuwa na kiolesura kimoja cha L3 katika vlan 0, lakini miingiliano kadhaa. Walakini, trafiki ya VxLAN itaacha nodi kwa njia ile ile, lakini pia imefungwa katika aina fulani ya vlan iliyojitolea.
Tumepanga nodi ya compute, hebu tuendelee kwenye nodi ya udhibiti.
[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 ~]$Kwa kweli, tunaweza kusema kwamba kila kitu ni sawa, lakini anwani ya IP haipo tena kwenye interface ya kimwili lakini kwenye daraja la kawaida. Hii inafanywa kwa sababu bandari hii ni bandari ambayo trafiki itatoka kwa ulimwengu wa nje.
[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 ~]$ Bandari hii imefungwa kwenye daraja la br-ex na kwa kuwa hakuna vitambulisho vya vlan juu yake, bandari hii ni bandari kuu ambayo waendeshaji wote wanaruhusiwa, sasa trafiki huenda nje bila lebo, kama inavyoonyeshwa na vlan-id 0 katika pato hapo juu.
Kila kitu kingine kwa sasa ni sawa na nodi ya compute - madaraja sawa, vichuguu sawa kwenda kwenye nodi mbili za compute.
Hatutazingatia nodes za kuhifadhi katika makala hii, lakini kwa kuelewa ni muhimu kusema kwamba sehemu ya mtandao ya nodes hizi ni banal hadi hatua ya aibu. Kwa upande wetu, kuna bandari moja tu ya kawaida (eth0) iliyo na anwani ya IP iliyopewa na ndivyo hivyo. Hakuna vichuguu vya VxLAN, madaraja ya tunnel, nk - hakuna ovs kabisa, kwa kuwa hakuna uhakika ndani yake. Wakati wa kutumia kutengwa kwa mtandao, nodi hii itakuwa na miingiliano miwili (bandari za mwili, bodny, au vlans mbili tu - haijalishi - inategemea kile unachotaka) - moja kwa usimamizi, ya pili kwa trafiki (kuandika kwa diski ya VM. , kusoma kutoka kwa diski, nk)
Tuligundua kile tulichonacho kwenye nodes kwa kutokuwepo kwa huduma yoyote. Sasa hebu tuzindue mashine 4 pepe na tuone jinsi mpango ulioelezwa hapo juu unavyobadilika - tunapaswa kuwa na bandari, vipanga njia pepe, n.k.
Kufikia sasa mtandao wetu unaonekana kama hii:
Tuna mashine mbili pepe kwenye kila nodi ya kompyuta. Kutumia compute-0 kama mfano, hebu tuone jinsi kila kitu kinajumuishwa.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Mashine ina kiolesura kimoja pekee - 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 ~]$
Kiolesura hiki kinaonekana kwenye daraja la linux:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Kama unavyoona kutoka kwa matokeo, kuna miingiliano miwili tu kwenye daraja - tap95d96a75-a0 na qvb95d96a75-a0.
Hapa inafaa kukaa kidogo juu ya aina za vifaa vya mtandao kwenye OpenStack:
vtap - kiolesura halisi kilichowekwa kwenye mfano (VM)
qbr - daraja la Linux
qvb na qvo - jozi ya vEth iliyounganishwa kwenye daraja la Linux na Fungua daraja la vSwitch
br-int, br-tun, br-vlan - Fungua madaraja ya vSwitch
kiraka-, int-br-, phy-br- - Fungua violesura vya viraka vya vSwitch vinavyounganisha madaraja
qg, qr, ha, fg, sg - Fungua bandari za vSwitch zinazotumiwa na vifaa pepe kuunganisha kwenye OVS
Kama unavyoelewa, ikiwa tunayo bandari ya qvb95d96a75-a0 kwenye daraja, ambayo ni jozi ya vEth, basi mahali fulani kuna mwenzake, ambayo inapaswa kuitwa qvo95d96a75-a0. Wacha tuangalie ni bandari gani ziko kwenye OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Kama tunavyoona, bandari iko katika br-int. Br-int hufanya kama swichi ambayo huzima bandari za mashine pepe. Mbali na qvo95d96a75-a0, bandari qvo5bd37136-47 inaonekana katika pato. Hii ni bandari ya mashine ya pili ya mtandaoni. Kama matokeo, mchoro wetu sasa unaonekana kama hii:
Swali ambalo linapaswa kuvutia msomaji makini mara moja - ni daraja gani la linux kati ya bandari ya mashine halisi na bandari ya OVS? Ukweli ni kwamba kulinda mashine, vikundi vya usalama hutumiwa, ambavyo sio zaidi ya iptables. OVS haifanyi kazi na iptables, kwa hivyo "crutch" hii iligunduliwa. Hata hivyo, inazidi kupitwa na wakati - inabadilishwa na conntrack katika matoleo mapya.
Hiyo ni, mwishowe mpango unaonekana kama hii:
Mashine mbili kwenye hypervisor moja kwenye mtandao mmoja wa L2
Kwa kuwa VM hizi mbili ziko kwenye mtandao huo wa L2 na kwenye hypervisor moja, trafiki kati yao itatiririka kimantiki kupitia br-int, kwani mashine zote mbili zitakuwa kwenye VLAN moja:
[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 ~]$ Mashine mbili kwenye hypervisors tofauti kwenye mtandao huo wa L2
Sasa hebu tuone jinsi trafiki itaenda kati ya mashine mbili kwenye mtandao huo wa L2, lakini iko kwenye hypervisors tofauti. Kuwa waaminifu, hakuna kitakachobadilika sana, trafiki tu kati ya hypervisors itapitia handaki ya vxlan. Hebu tuangalie mfano.
Anwani za mashine pepe kati ya ambayo tutatazama trafiki:
[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 ~]$ Tunaangalia jedwali la usambazaji katika br-int kwenye compute-0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Trafiki inapaswa kwenda kwenye bandari 2 - wacha tuone ni aina gani ya bandari:
[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 ~]$Hii ni patch-tun - yaani, interface katika br-tun. Wacha tuone kinachotokea kwa kifurushi kwenye br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Kifurushi kimewekwa katika VxLAN na kutumwa kwa bandari 2. Wacha tuone ni wapi bandari 2 inaongoza:
[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 ~]$Hili ni handaki ya vxlan kwenye compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Wacha tuende kwa compute-1 na tuone kinachofuata na kifurushi:
[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 iko kwenye jedwali la usambazaji la br-int kwenye compute-1, na kama inavyoweza kuonekana kutoka kwa matokeo hapo juu, inaonekana kupitia bandari 2, ambayo ni bandari kuelekea br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Kweli, basi tunaona kwamba katika br-int kwenye compute-1 kuna poppy lengwa:
[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 ~]$ Hiyo ni, pakiti iliyopokelewa itaruka hadi bandari 3, nyuma ambayo tayari kuna mfano wa mashine-00000003.
Uzuri wa kupeleka Openstack kwa ajili ya kujifunza kwenye miundombinu ya mtandaoni ni kwamba tunaweza kunasa trafiki kwa urahisi kati ya hypervisors na kuona kinachoendelea nayo. Hivi ndivyo tutafanya sasa, endesha tcpdump kwenye bandari ya vnet kuelekea compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Mstari wa kwanza unaonyesha kuwa Patek kutoka kwa anwani 10.0.1.85 huenda kushughulikia 10.0.1.88 (trafiki ya ICMP), na imefungwa kwenye pakiti ya VxLAN na vni 22 na pakiti inatoka kwa mwenyeji 192.168.255.19 (compute-0) ili kukaribisha 192.168.255.26 .1 ( hesabu-XNUMX). Tunaweza kuangalia kuwa VNI inalingana na ile iliyoainishwa kwenye ovs.
Hebu turejee kwenye mstari huu actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 ni vni katika mfumo wa nambari ya hexadecimal. Wacha tubadilishe nambari hii kuwa mfumo wa 16:
16 = 6*16^0+1*16^1 = 6+16 = 22Hiyo ni, vni inalingana na ukweli.
Mstari wa pili unaonyesha trafiki ya kurudi, vizuri, hakuna maana katika kuielezea, kila kitu ni wazi huko.
Mashine mbili kwenye mitandao tofauti (uelekezaji baina ya mtandao)
Kesi ya mwisho kwa leo ni kuelekeza kati ya mitandao ndani ya mradi mmoja kwa kutumia kipanga njia pepe. Tunazingatia kesi bila DVR (tutaiangalia katika makala nyingine), hivyo uelekezaji hutokea kwenye node ya mtandao. Kwa upande wetu, node ya mtandao haijawekwa katika chombo tofauti na iko kwenye node ya kudhibiti.
Kwanza, wacha tuone kwamba uelekezaji hufanya kazi:
$ 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 msKwa kuwa katika kesi hii pakiti lazima iende kwenye lango na kupelekwa huko, tunahitaji kujua anwani ya MAC ya lango, ambalo tunaangalia jedwali la ARP kwa mfano:
$ 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 eth0Sasa hebu tuone ni wapi trafiki iliyo na lengwa (10.0.1.254) fa:16:3e:c4:64:70 inapaswa kutumwa:
[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 ~]$ Wacha tuangalie ni wapi bandari 2 inaongoza:
[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 ~]$ Kila kitu ni mantiki, trafiki huenda kwa br-tun. Wacha tuone ni handaki gani la vxlan litafungwa ndani:
[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 ~]$ Bandari ya tatu ni handaki ya vxlan:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Ambayo inaangalia nodi ya kudhibiti:
[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 ~]$ Trafiki imefikia nodi ya udhibiti, kwa hivyo tunahitaji kuiendea na kuona jinsi uelekezaji utafanyika.
Kama unavyokumbuka, nodi ya udhibiti ndani ilionekana sawa na nodi ya compute - madaraja hayo matatu, tu br-ex ilikuwa na bandari ya kimwili ambayo nodi inaweza kutuma trafiki nje. Uundaji wa matukio ulibadilisha usanidi kwenye nodes za compute - daraja la linux, iptables na interfaces ziliongezwa kwenye nodes. Uundaji wa mitandao na router ya kawaida pia iliacha alama yake juu ya usanidi wa node ya kudhibiti.
Kwa hivyo, ni dhahiri kwamba lango la anwani ya MAC lazima iwe kwenye jedwali la usambazaji la br-int kwenye nodi ya kudhibiti. Wacha tuangalie ikiwa iko na inatafuta wapi:
[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 inaonekana kutoka bandari qr-0c52b15f-8f. Tukirudi kwenye orodha ya bandari pepe katika Openstack, aina hii ya bandari hutumiwa kuunganisha vifaa mbalimbali pepe kwenye OVS. Ili kuwa sahihi zaidi, qr ni mlango wa kipanga njia pepe, ambacho kinawakilishwa kama nafasi ya majina.
Wacha tuone ni nafasi gani za majina kwenye seva:
[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 ~]$ Nakala nyingi kama tatu. Lakini kwa kuhukumu kwa majina, unaweza kudhani madhumuni ya kila mmoja wao. Tutarejea kwenye hali na kitambulisho 0 na 1 baadaye, sasa tunavutiwa na nafasi ya majina qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Nafasi hii ya majina ina mbili za ndani ambazo tulitengeneza hapo awali. Lango zote mbili pepe zimeongezwa kwa br-int. Wacha tuangalie anwani ya mac ya bandari qr-0c52b15f-8f, kwa kuwa trafiki, kwa kuzingatia anwani ya marudio ya mac, ilienda kwenye kiolesura hiki.
[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 ~]$ Hiyo ni, katika kesi hii, kila kitu hufanya kazi kulingana na sheria za upangaji wa kawaida. Kwa kuwa trafiki imekusudiwa kwa seva pangishi 10.0.2.8, lazima itoke kupitia kiolesura cha pili qr-92fa49b5-54 na ipite kwenye handaki ya vxlan hadi nodi ya kukokotoa:
[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 ~]$ Kila kitu ni mantiki, hakuna mshangao. Wacha tuone ni wapi anwani ya poppy ya mwenyeji 10.0.2.8 inaonekana katika br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Kama inavyotarajiwa, trafiki inakwenda kwa br-tun, wacha tuone ni njia gani trafiki inakwenda inayofuata:
[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 ~]$ Trafiki huenda kwenye handaki ili kukokotoa-1. Kweli, kwenye compute-1 kila kitu ni rahisi - kutoka kwa br-tun kifurushi huenda kwa br-int na kutoka hapo hadi kiolesura cha mashine halisi:
[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 ~]$ Wacha tuangalie ikiwa hii ndio kiolesura sahihi:
[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 ~]$
Kwa kweli, tulipitia kifurushi. Nadhani umegundua kuwa trafiki ilipitia vichuguu tofauti vya vxlan na kutoka na VNI tofauti. Wacha tuone ni aina gani za VNI hizi, baada ya hapo tutakusanya dampo kwenye bandari ya udhibiti wa nodi na hakikisha kuwa trafiki inapita kama ilivyoelezwa hapo juu.
Kwa hivyo, handaki ya kukokotoa-0 ina vitendo vifuatavyo=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Wacha tubadilishe 0x16 kuwa mfumo wa nambari ya desimali:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Njia ya kukokotoa-1 ina VNI:actions=load:0->NXM_OF_VLAN_TCI ifuatayo [],load:0x63->NXM_NX_TUN_ID[],output:2. Wacha tubadilishe 0x63 kuwa mfumo wa nambari ya desimali:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Kweli, sasa hebu tuangalie dampo:
[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*******************Pakiti ya kwanza ni pakiti ya vxlan kutoka kwa mwenyeji 192.168.255.19 (compute-0) ili kupangisha 192.168.255.15 (control-1) na vni 22, ndani ambayo pakiti ya ICMP inafungwa kutoka kwa mwenyeji 10.0.1.85 hadi mwenyeji 10.0.2.8. Kama tulivyohesabu hapo juu, vni inalingana na kile tulichoona kwenye matokeo.
Pakiti ya pili ni pakiti ya vxlan kutoka kwa mwenyeji 192.168.255.15 (control-1) ili kupangisha 192.168.255.26 (compute-1) na vni 99, ndani ambayo pakiti ya ICMP inafungwa kutoka kwa mwenyeji 10.0.1.85 ili kupangisha 10.0.2.8. Kama tulivyohesabu hapo juu, vni inalingana na kile tulichoona kwenye matokeo.
Pakiti mbili zifuatazo ni trafiki ya kurudi kutoka 10.0.2.8 si 10.0.1.85.
Hiyo ni, mwisho tulipata mpango ufuatao wa nodi ya kudhibiti:
Inaonekana ndivyo hivyo? Tulisahau kuhusu nafasi mbili za majina:
[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 ~]$ Tulipozungumza kuhusu usanifu wa jukwaa la wingu, itakuwa nzuri ikiwa mashine zitapokea anwani moja kwa moja kutoka kwa seva ya DHCP. Hizi ni seva mbili za DHCP kwa mitandao yetu miwili 10.0.1.0/24 na 10.0.2.0/24.
Wacha tuangalie kama hii ni kweli. Kuna anwani moja tu katika nafasi hii ya majina - 10.0.1.1 - anwani ya seva ya DHCP yenyewe, na pia imejumuishwa katika br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Wacha tuone ikiwa michakato iliyo na qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 kwa jina lao kwenye nodi ya kudhibiti:
[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 ~]$ Kuna mchakato kama huu na kulingana na habari iliyowasilishwa kwenye matokeo hapo juu, tunaweza, kwa mfano, kuona kile tulicho nacho kwa sasa:
[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 ~]$Kama matokeo, tunapata seti ifuatayo ya huduma kwenye nodi ya kudhibiti:
Sawa, kumbuka - hii ni mashine 4 tu, mitandao 2 ya ndani na kipanga njia moja cha mtandao... Hatuna mitandao ya nje hapa sasa, rundo la miradi tofauti, kila moja ikiwa na mitandao yake (inaingiliana), na tunayo mitandao ya nje. router iliyosambazwa imezimwa, na mwisho Baada ya yote, kulikuwa na node moja tu ya udhibiti katika benchi ya mtihani (kwa uvumilivu wa kosa lazima iwe na quorum ya nodes tatu). Ni jambo la busara kwamba katika biashara kila kitu ni "kidogo" ngumu zaidi, lakini katika mfano huu rahisi tunaelewa jinsi inavyopaswa kufanya kazi - ikiwa una nafasi za majina 3 au 300 bila shaka ni muhimu, lakini kutoka kwa mtazamo wa uendeshaji wa kazi nzima. muundo, hakuna kitakachobadilika sana... ingawa hadi hautachomeka SDN ya muuzaji. Lakini hiyo ni hadithi tofauti kabisa.
Natumaini ilikuwa ya kuvutia. Ikiwa una maoni/nyongeza yoyote, au mahali fulani nilidanganya kabisa (mimi ni binadamu na maoni yangu yatakuwa ya kibinafsi kila wakati) - andika kile kinachohitaji kusahihishwa / kuongezwa - tutasahihisha / kuongeza kila kitu.
Kwa kumalizia, ningependa kusema maneno machache kuhusu kulinganisha Openstack (wote vanilla na muuzaji) na suluhisho la wingu kutoka VMWare - Nimeulizwa swali hili mara nyingi sana katika miaka michache iliyopita na, kusema ukweli, nina tayari nimechoka nayo, lakini bado. Kwa maoni yangu, ni vigumu sana kulinganisha ufumbuzi huu wawili, lakini tunaweza kusema kwa hakika kuwa kuna hasara katika ufumbuzi wote na wakati wa kuchagua suluhisho moja unahitaji kupima faida na hasara.
Ikiwa OpenStack ni suluhisho linaloendeshwa na jamii, basi VMWare ina haki ya kufanya tu kile inachotaka (kusoma - ni faida gani kwake) na hii ni mantiki - kwa sababu ni kampuni ya kibiashara ambayo hutumiwa kutengeneza pesa kutoka kwa wateja wake. Lakini kuna moja kubwa na mafuta LAKINI - unaweza kutoka OpenStack, kwa mfano kutoka Nokia, na kwa gharama kidogo kubadili kwa ufumbuzi kutoka, kwa mfano, Juniper (Contrail Cloud), lakini kuna uwezekano wa kuwa na uwezo wa kupata off VMWare. . Kwangu, suluhisho hizi mbili zinaonekana kama hii - Openstack (muuzaji) ni ngome rahisi ambayo umewekwa, lakini unayo ufunguo na unaweza kuondoka wakati wowote. VMWare ni ngome ya dhahabu, mmiliki ana ufunguo wa ngome na itakugharimu sana.
Sitangazi bidhaa ya kwanza au ya pili - unachagua unachohitaji. Lakini ikiwa ningekuwa na chaguo kama hilo, ningechagua suluhisho zote mbili - VMWare kwa wingu la IT (mizigo ya chini, usimamizi rahisi), OpenStack kutoka kwa muuzaji fulani (Nokia na Juniper hutoa suluhisho nzuri sana za turnkey) - kwa wingu la Telecom. Nisingetumia Openstack kwa IT safi - ni kama kurusha shomoro na kanuni, lakini sioni ukiukwaji wowote wa kuitumia isipokuwa kupunguzwa tena. Walakini, kutumia VMWare kwenye mawasiliano ya simu ni kama kuvuta mawe yaliyopondwa kwenye Ford Raptor - ni nzuri kutoka nje, lakini dereva lazima afanye safari 10 badala ya moja.
Kwa maoni yangu, hasara kubwa ya VMWare ni kufungwa kwake kamili - kampuni haitakupa habari yoyote juu ya jinsi inavyofanya kazi, kwa mfano, vSAN au kile kilicho kwenye kernel ya hypervisor - sio faida kwa hiyo - yaani, utafanya kazi. usiwe mtaalam katika VMWare - bila usaidizi wa muuzaji, umepotea (mara nyingi sana mimi hukutana na wataalam wa VMWare ambao wanashangazwa na maswali madogo). Kwangu, VMWare inanunua gari na kofia imefungwa - ndio, unaweza kuwa na wataalam ambao wanaweza kubadilisha ukanda wa wakati, lakini ni yule tu aliyekuuza suluhisho hili ndiye anayeweza kufungua kofia. Binafsi, sipendi suluhu ambazo siwezi kutoshea. Utasema kwamba huenda usiingie chini ya kofia. Ndio, hii inawezekana, lakini nitakuangalia wakati unahitaji kukusanyika kazi kubwa katika wingu kutoka kwa mashine 20-30 za kawaida, mitandao 40-50, nusu ambayo inataka kwenda nje, na nusu ya pili inauliza. Kuongeza kasi ya SR-IOV, vinginevyo utahitaji zaidi ya kadhaa ya magari haya - vinginevyo utendaji hautatosha.
Kuna maoni mengine, kwa hivyo tu unaweza kuamua nini cha kuchagua na, muhimu zaidi, basi utawajibika kwa chaguo lako. Haya ni maoni yangu tu - mtu ambaye ameona na kugusa angalau bidhaa 4 - Nokia, Juniper, Red Hat na VMWare. Yaani nina kitu cha kulinganisha nacho.
Chanzo: mapenzi.com