Ang cloud computing ay lumalalim nang palalim ng palalim sa ating buhay at malamang na wala ni isang tao na hindi gumamit ng anumang mga serbisyo ng cloud kahit isang beses. Gayunpaman, kung ano nga ba ang isang ulap at kung paano ito gumagana, kakaunti ang nakakaalam, kahit na sa antas ng isang ideya. Nagiging katotohanan na ang 5G at ang imprastraktura ng telecom ay nagsisimula nang lumipat mula sa mga pole solution patungo sa mga cloud solution, tulad ng nangyari noong lumipat ito mula sa ganap na mga solusyon sa hardware patungo sa mga virtualized na "pillars".
Ngayon ay pag-uusapan natin ang tungkol sa panloob na mundo ng imprastraktura ng ulap, partikular na titingnan natin ang mga pangunahing kaalaman ng bahagi ng network.
Ano ang ulap? Ang parehong virtualization - view ng profile?
Higit pa sa isang lohikal na tanong. Hindi - hindi ito virtualization, bagama't hindi ito magagawa kung wala ito. Tingnan natin ang dalawang kahulugan:
Cloud computing (pagkatapos dito ay tinutukoy bilang Cloud) ay isang modelo para sa pagbibigay ng user-friendly na access sa mga distributed computing resources na dapat i-deploy at ilunsad on demand na may pinakamababang posibleng latency at minimal na gastos sa service provider.
Virtualization - ito ay ang kakayahang hatiin ang isang pisikal na entity (halimbawa, isang server) sa ilang virtual na mga virtual, at sa gayon ay nadaragdagan ang paggamit ng mga mapagkukunan (halimbawa, mayroon kang 3 server na na-load sa 25-30 porsyento, pagkatapos ng virtualization makakakuha ka ng 1 server na na-load sa 80-90 porsyento). Natural, kinakain ng virtualization ang ilan sa mga mapagkukunan - kailangan mong pakainin ang hypervisor, gayunpaman, tulad ng ipinakita ng kasanayan, ang laro ay nagkakahalaga ng kandila. Ang isang mainam na halimbawa ng virtualization ay ang VMWare, na perpektong naghahanda ng mga virtual machine, o halimbawa KVM, na mas gusto ko, ngunit ito ay isang bagay ng panlasa.
Gumagamit kami ng virtualization nang hindi namamalayan, at kahit na ang mga iron router ay gumagamit na ng virtualization - halimbawa, sa pinakabagong bersyon ng JunOS, ang operating system ay naka-install bilang isang virtual machine sa ibabaw ng isang real-time na pamamahagi ng Linux (Wind River 9). Ngunit ang virtualization ay hindi ang ulap, ngunit ang ulap ay hindi maaaring umiral nang walang virtualization.
Ang virtualization ay isa sa mga building block kung saan itinayo ang cloud.
Ang paggawa ng cloud sa pamamagitan lamang ng pagkolekta ng ilang hypervisors sa isang L2 domain, pagdaragdag ng ilang yaml playbook para sa awtomatikong pagrerehistro ng mga vlan sa pamamagitan ng ilang uri ng ansible at pag-jamming ng isang bagay tulad ng isang sistema ng orkestrasyon sa lahat ng ito para sa awtomatikong paglikha ng mga virtual machine ay hindi gagana. Ito ay magiging mas tumpak, ngunit ang magreresultang Frankenstein ay hindi ang ulap na kailangan natin, bagama't maaaring ito ang tunay na pangarap para sa iba. Bukod dito, kung kukuha ka ng parehong Openstack, ito ay mahalagang Frankenstein pa rin, ngunit oh well, huwag muna nating pag-usapan iyon sa ngayon.
Ngunit naiintindihan ko na mula sa depinisyon na ipinakita sa itaas ay hindi lubos na malinaw kung ano talaga ang matatawag na ulap.
Samakatuwid, ang isang dokumento mula sa NIST (National Institute of Standards and Technology) ay nagbibigay ng 5 pangunahing katangian na dapat magkaroon ng isang cloud infrastructure:
Nagbibigay ng serbisyo kapag hiniling. Ang gumagamit ay dapat bigyan ng libreng pag-access sa mga mapagkukunan ng computer na inilaan sa kanya (tulad ng mga network, virtual disk, memorya, mga core ng processor, atbp.), At ang mga mapagkukunang ito ay dapat na awtomatikong ibigay - iyon ay, nang walang interbensyon mula sa service provider.
Malawak na kakayahang magamit ng serbisyo. Ang pag-access sa mga mapagkukunan ay dapat ibigay ng mga karaniwang mekanismo upang payagan ang paggamit ng parehong mga karaniwang PC at thin client at mga mobile device.
Pagsasama-sama ng mga mapagkukunan sa mga pool. Ang mga mapagkukunang pool ay dapat na makapagbigay ng mga mapagkukunan sa maraming kliyente nang sabay-sabay, na tinitiyak na ang mga kliyente ay nakahiwalay at walang impluwensya sa isa't isa at kumpetisyon para sa mga mapagkukunan. Kasama rin ang mga network sa mga pool, na nagpapahiwatig ng posibilidad ng paggamit ng overlapping na pag-address. Ang mga pool ay dapat na makapag-scale on demand. Ang paggamit ng mga pool ay ginagawang posible na magbigay ng kinakailangang antas ng resource fault tolerance at abstraction ng pisikal at virtual na mga mapagkukunan - ang tatanggap ng serbisyo ay binibigyan lamang ng hanay ng mga mapagkukunan na kanyang hiniling (kung saan ang mga mapagkukunang ito ay pisikal na matatagpuan, kung gaano karami mga server at switch - hindi mahalaga sa kliyente). Gayunpaman, dapat nating isaalang-alang ang katotohanan na dapat tiyakin ng provider ang transparent na reserbasyon ng mga mapagkukunang ito.
Mabilis na pagbagay sa iba't ibang mga kondisyon. Ang mga serbisyo ay dapat na may kakayahang umangkop - mabilis na pagkakaloob ng mga mapagkukunan, ang kanilang muling pamamahagi, pagdaragdag o pagbabawas ng mga mapagkukunan sa kahilingan ng kliyente, at sa panig ng kliyente ay dapat na may pakiramdam na ang mga mapagkukunan ng ulap ay walang katapusan. Para sa kadalian ng pag-unawa, halimbawa, hindi ka nakakakita ng babala na ang bahagi ng iyong disk space sa Apple iCloud ay nawala dahil ang hard drive sa server ay nasira, at ang mga drive ay nasira. Bilang karagdagan, sa iyong bahagi, ang mga posibilidad ng serbisyong ito ay halos walang limitasyon - kailangan mo ng 2 TB - walang problema, binayaran mo at natanggap ito. Ang isang katulad na halimbawa ay maaaring ibigay sa Google.Drive o Yandex.Disk.
Posibilidad ng pagsukat ng serbisyong ibinigay. Ang mga cloud system ay dapat awtomatikong kontrolin at i-optimize ang mga nagamit na mapagkukunan, at ang mga mekanismong ito ay dapat na transparent sa parehong user at sa service provider. Iyon ay, maaari mong palaging suriin kung gaano karaming mga mapagkukunan ang ginagamit mo at ng iyong mga kliyente.
Ito ay nagkakahalaga ng pagsasaalang-alang sa katotohanan na ang mga kinakailangang ito ay halos kinakailangan para sa isang pampublikong ulap, kaya para sa isang pribadong ulap (iyon ay, isang ulap na inilunsad para sa mga panloob na pangangailangan ng kumpanya), ang mga kinakailangang ito ay maaaring bahagyang maisaayos. Gayunpaman, kailangan pa rin nilang gawin, kung hindi, hindi natin makukuha ang lahat ng benepisyo ng cloud computing.
Bakit kailangan natin ng ulap?
Gayunpaman, anumang bago o umiiral na teknolohiya, anumang bagong protocol ay nilikha para sa isang bagay (mabuti, maliban sa RIP-ng, siyempre). Walang nangangailangan ng isang protocol para sa kapakanan ng isang protocol (mabuti, maliban sa RIP-ng, siyempre). Lohikal na nilikha ang Cloud upang magbigay ng ilang uri ng serbisyo sa user/kliyente. Pamilyar tayong lahat sa kahit man lang ilang serbisyo sa cloud, halimbawa Dropbox o Google.Docs, at naniniwala akong matagumpay na ginagamit ng karamihan sa mga tao ang mga ito - halimbawa, isinulat ang artikulong ito gamit ang serbisyo ng cloud ng Google.Docs. Ngunit ang mga serbisyo ng cloud na alam namin ay bahagi lamang ng mga kakayahan ng cloudβmas tiyak, ang mga ito ay isang serbisyong uri lamang ng SaaS. Maaari kaming magbigay ng serbisyo sa cloud sa tatlong paraan: sa anyo ng SaaS, PaaS o IaaS. Anong serbisyo ang kailangan mo ay depende sa iyong mga hangarin at kakayahan.
Tingnan natin ang bawat isa sa pagkakasunud-sunod:
Software bilang isang Serbisyo (SaaS) ay isang modelo para sa pagbibigay ng ganap na serbisyo sa kliyente, halimbawa, isang serbisyo sa email tulad ng Yandex.Mail o Gmail. Sa modelong ito ng paghahatid ng serbisyo, ikaw, bilang isang kliyente, ay talagang walang ginagawa maliban sa paggamit ng mga serbisyo - iyon ay, hindi mo kailangang isipin ang tungkol sa pag-set up ng serbisyo, ang pagpapahintulot nito sa kasalanan o kalabisan. Ang pangunahing bagay ay hindi ikompromiso ang iyong password; gagawin ng provider ng serbisyong ito ang natitira para sa iyo. Mula sa punto ng view ng service provider, siya ay ganap na responsable para sa buong serbisyo - mula sa server hardware at host operating system hanggang sa mga setting ng database at software.
Platform bilang isang Serbisyo (PaaS) β kapag ginagamit ang modelong ito, binibigyan ng service provider ang kliyente ng workpiece para sa serbisyo, halimbawa, kumuha tayo ng Web server. Ang service provider ay nagbigay sa kliyente ng isang virtual server (sa katunayan, isang set ng mga mapagkukunan, tulad ng RAM/CPU/Storage/Nets, atbp.), at kahit na na-install ang OS at kinakailangang software sa server na ito, gayunpaman, ang configuration ng lahat ng bagay na ito ay ginagawa ng kliyente mismo at para sa pagganap ng serbisyo ang sagot ng kliyente. Ang service provider, tulad ng sa nakaraang kaso, ay responsable para sa pagganap ng mga pisikal na kagamitan, hypervisors, ang virtual machine mismo, ang pagkakaroon ng network nito, atbp., ngunit ang serbisyo mismo ay wala na sa lugar ng responsibilidad nito.
Imprastraktura bilang isang Serbisyo (IaaS) - ang diskarte na ito ay mas kawili-wili, sa katunayan, ang service provider ay nagbibigay sa kliyente ng isang kumpletong virtualized na imprastraktura - iyon ay, ilang set (pool) ng mga mapagkukunan, tulad ng CPU Cores, RAM, Networks, atbp. Lahat ng iba ay nakasalalay sa ang kliyente - kung ano ang gustong gawin ng kliyente sa mga mapagkukunang ito sa loob ng inilalaang pool (quota) - hindi ito partikular na mahalaga para sa supplier. Kung nais ng kliyente na lumikha ng kanyang sariling vEPC o kahit na lumikha ng isang mini operator at magbigay ng mga serbisyo sa komunikasyon - walang tanong - gawin ito. Sa ganoong sitwasyon, ang service provider ay may pananagutan para sa pagbibigay ng mga mapagkukunan, ang kanilang pagpapahintulot sa pagkakamali at kakayahang magamit, pati na rin ang OS na nagpapahintulot sa kanila na pagsamahin ang mga mapagkukunang ito at gawing available ang mga ito sa kliyente na may kakayahang dagdagan o bawasan ang mga mapagkukunan anumang oras sa kahilingan ng kliyente. Kino-configure mismo ng kliyente ang lahat ng virtual machine at iba pang tinsel sa pamamagitan ng self-service portal at console, kabilang ang pag-set up ng mga network (maliban sa mga panlabas na network).
Ano ang OpenStack?
Sa lahat ng tatlong opsyon, kailangan ng service provider ng OS na magbibigay-daan sa paglikha ng cloud infrastructure. Sa katunayan, sa SaaS, higit sa isang dibisyon ang responsable para sa buong stack ng mga teknolohiya - mayroong isang dibisyon na responsable para sa imprastraktura - iyon ay, nagbibigay ito ng IaaS sa isa pang dibisyon, ang dibisyong ito ay nagbibigay ng SaaS sa kliyente. Ang OpenStack ay isa sa mga cloud operating system na nagbibigay-daan sa iyong mangolekta ng isang grupo ng mga switch, server at storage system sa iisang resource pool, hatiin ang karaniwang pool na ito sa mga subpool (mga nangungupahan) at ibigay ang mga mapagkukunang ito sa mga kliyente sa network.
OpenStack ay isang cloud operating system na nagbibigay-daan sa iyong kontrolin ang malalaking pool ng computing resources, data storage at network resources, provisioned at pinamamahalaan sa pamamagitan ng API gamit ang standard authentication mechanisms.
Sa madaling salita, ito ay isang hanay ng mga libreng proyekto ng software na idinisenyo upang lumikha ng mga serbisyo sa ulap (parehong pampubliko at pribado) - iyon ay, isang hanay ng mga tool na nagbibigay-daan sa iyo upang pagsamahin ang server at paglipat ng kagamitan sa isang solong pool ng mga mapagkukunan, pamahalaan ang mga mapagkukunang ito, na nagbibigay ng kinakailangang antas ng fault tolerance .
Sa oras ng pagsulat ng materyal na ito, ang istraktura ng OpenStack ay ganito ang hitsura:
Kinuha ang larawan mula sa
Ang bawat isa sa mga bahagi na kasama sa OpenStack ay gumaganap ng isang partikular na function. Ang ipinamamahaging arkitektura na ito ay nagpapahintulot sa iyo na isama sa solusyon ang hanay ng mga functional na bahagi na kailangan mo. Gayunpaman, ang ilang mga bahagi ay mga bahagi ng ugat at ang kanilang pag-aalis ay hahantong sa kumpleto o bahagyang kawalan ng kakayahang magamit ng solusyon sa kabuuan. Ang mga sangkap na ito ay karaniwang inuri bilang:
- Tapalodo β Web-based na GUI para sa pamamahala ng mga serbisyo ng OpenStack
- Keystone ay isang sentralisadong serbisyo ng pagkakakilanlan na nagbibigay ng pagpapatunay at pagpapagana ng awtorisasyon para sa iba pang mga serbisyo, pati na rin ang pamamahala ng mga kredensyal ng user at ang kanilang mga tungkulin.
- Neutron - isang serbisyo sa network na nagbibigay ng koneksyon sa pagitan ng mga interface ng iba't ibang serbisyo ng OpenStack (kabilang ang koneksyon sa pagitan ng mga VM at ang kanilang pag-access sa labas ng mundo)
- Sinderela β nagbibigay ng access upang harangan ang storage para sa mga virtual machine
- Nova β pamamahala ng siklo ng buhay ng mga virtual machine
- Sulyap β imbakan ng mga imahe at snapshot ng virtual machine
- matulin β nagbibigay ng access sa storage object
- Ceilometer β isang serbisyong nagbibigay ng kakayahang mangolekta ng telemetry at sukatin ang mga magagamit at ginagamit na mapagkukunan
- Init β orkestrasyon batay sa mga template para sa awtomatikong paggawa at pagbibigay ng mga mapagkukunan
Ang isang kumpletong listahan ng lahat ng mga proyekto at ang kanilang layunin ay maaaring matingnan .
Ang bawat bahagi ng OpenStack ay isang serbisyo na gumaganap ng isang partikular na function at nagbibigay ng isang API upang pamahalaan ang function na iyon at makipag-ugnayan sa iba pang mga serbisyo ng cloud operating system upang lumikha ng isang pinag-isang imprastraktura. Halimbawa, ang Nova ay nagbibigay ng computing resource management at isang API para sa pag-access sa pag-configure ng mga mapagkukunang ito, ang Glance ay nagbibigay ng pamamahala ng imahe at isang API para sa pamamahala sa mga ito, Cinder ay nagbibigay ng block storage at isang API para sa pamamahala nito, atbp. Ang lahat ng mga function ay magkakaugnay sa isang napakalapit na paraan.
Gayunpaman, kung titingnan mo ito, ang lahat ng mga serbisyong tumatakbo sa OpenStack ay sa huli ay isang uri ng virtual machine (o lalagyan) na konektado sa network. Ang tanong ay lumitaw - bakit kailangan natin ng napakaraming elemento?
Tingnan natin ang algorithm para sa paglikha ng isang virtual machine at pagkonekta nito sa network at patuloy na storage sa Openstack.
- Kapag lumikha ka ng isang kahilingan upang lumikha ng isang makina, ito man ay isang kahilingan sa pamamagitan ng Horizon (Dashboard) o isang kahilingan sa pamamagitan ng CLI, ang unang bagay na mangyayari ay ang pahintulot ng iyong kahilingan sa Keystone - maaari kang lumikha ng isang makina, mayroon ba itong karapatang gamitin ang network na ito, ginagawa ba ang iyong draft na quota, atbp.
- Pinapatunayan ng Keystone ang iyong kahilingan at bumubuo ng isang token ng pagpapatunay sa mensahe ng pagtugon, na gagamitin pa. Pagkatanggap ng tugon mula sa Keystone, ipinadala ang kahilingan patungo sa Nova (nova api).
- Sinusuri ng Nova-api ang validity ng iyong kahilingan sa pamamagitan ng pakikipag-ugnayan sa Keystone gamit ang dating nabuong auth token
- Ang Keystone ay nagsasagawa ng pagpapatotoo at nagbibigay ng impormasyon sa mga pahintulot at paghihigpit batay sa token ng pagpapatunay na ito.
- Lumilikha ang Nova-api ng entry para sa bagong VM sa nova-database at ipinapasa ang kahilingang gawin ang makina sa nova-scheduler.
- Pinipili ng Nova-scheduler ang host (computer node) kung saan ide-deploy ang VM batay sa mga tinukoy na parameter, timbang at zone. Ang isang talaan nito at ang VM ID ay isinulat sa nova-database.
- Susunod, nakikipag-ugnayan ang nova-scheduler sa nova-compute na may kahilingang mag-deploy ng isang instance. Nakikipag-ugnayan ang Nova-compute sa nova-conductor upang makakuha ng impormasyon tungkol sa mga parameter ng makina (ang nova-conductor ay isang elemento ng nova na nagsisilbing proxy server sa pagitan ng nova-database at nova-compute, na nililimitahan ang bilang ng mga kahilingan sa nova-database upang maiwasan ang mga problema sa database pare-pareho ang pagbabawas ng pagkarga).
- Natatanggap ng Nova-conductor ang hiniling na impormasyon mula sa nova-database at ipinapasa ito sa nova-compute.
- Susunod, sulyap ng nova-compute na mga tawag para makuha ang image ID. Pinapatunayan ng Glace ang kahilingan sa Keystone at ibinabalik ang hiniling na impormasyon.
- Nova-compute contact neutron upang makakuha ng impormasyon tungkol sa mga parameter ng network. Katulad ng sulyap, pinapatunayan ng neutron ang kahilingan sa Keystone, pagkatapos nito ay lumikha ng isang entry sa database (port identifier, atbp.), lumilikha ng isang kahilingan upang lumikha ng isang port, at ibabalik ang hiniling na impormasyon sa nova-compute.
- Nova-compute contact cinder na may kahilingang maglaan ng volume sa virtual machine. Katulad ng sulyap, pinapatunayan ng cider ang kahilingan sa Keystone, gumagawa ng kahilingan sa paggawa ng volume, at ibinabalik ang hiniling na impormasyon.
- Nova-compute contact libvirt na may kahilingang mag-deploy ng virtual machine na may mga tinukoy na parameter.
Sa katunayan, ang isang tila simpleng operasyon ng paglikha ng isang simpleng virtual machine ay nagiging tulad ng isang whirlpool ng mga tawag sa API sa pagitan ng mga elemento ng cloud platform. Bukod dito, tulad ng nakikita mo, kahit na ang mga dating itinalagang serbisyo ay binubuo rin ng mas maliliit na bahagi kung saan nagaganap ang pakikipag-ugnayan. Ang paglikha ng isang makina ay isang maliit na bahagi lamang ng kung ano ang pinapayagan ng cloud platform na gawin mo - mayroong isang serbisyo na responsable para sa pagbabalanse ng trapiko, isang serbisyo na responsable para sa block storage, isang serbisyo na responsable para sa DNS, isang serbisyo na responsable para sa provisioning bare metal server, atbp Binibigyang-daan ka ng cloud na dapat mong ituring ang iyong mga virtual machine tulad ng isang kawan ng mga tupa (kumpara sa virtualization). Kung may nangyari sa iyong makina sa isang virtual na kapaligiran - ibinalik mo ito mula sa mga backup, atbp., ngunit ang mga cloud application ay binuo sa paraang ang virtual machine ay hindi gumaganap ng ganoong mahalagang papel - ang virtual machine ay "namatay" - walang problema - ang isang bago ay nilikha lamang ang sasakyan ay batay sa template at, tulad ng sinasabi nila, ang iskwad ay hindi napansin ang pagkawala ng manlalaban. Naturally, nagbibigay ito para sa pagkakaroon ng mga mekanismo ng orkestrasyon - gamit ang mga template ng Heat, madali mong mai-deploy ang isang kumplikadong function na binubuo ng dose-dosenang mga network at virtual machine.
Laging dapat tandaan na walang imprastraktura ng ulap na walang network - ang bawat elemento sa isang paraan o iba ay nakikipag-ugnayan sa iba pang mga elemento sa pamamagitan ng network. Bilang karagdagan, ang ulap ay may ganap na hindi static na network. Naturally, ang underlay network ay higit pa o hindi gaanong static - ang mga bagong node at switch ay hindi idinaragdag araw-araw, ngunit ang overlay na bahagi ay maaari at hindi maiiwasang magbago nang tuluy-tuloy - ang mga bagong network ay idaragdag o tatanggalin, ang mga bagong virtual machine ay lilitaw at ang mga luma ay lilitaw. mamatay. At tulad ng naaalala mo mula sa kahulugan ng cloud na ibinigay sa pinakadulo simula ng artikulo, ang mga mapagkukunan ay dapat na awtomatikong ilaan sa gumagamit at may hindi bababa sa (o mas mabuti pa, nang walang) interbensyon mula sa service provider. Iyon ay, ang uri ng probisyon ng mga mapagkukunan ng network na ngayon ay umiiral sa anyo ng isang front-end sa anyo ng iyong personal na account na maa-access sa pamamagitan ng http/https at ang on-duty na network engineer na si Vasily bilang isang backend ay hindi isang ulap, kahit na kung si Vasily ay may walong kamay.
Ang Neutron, bilang isang serbisyo sa network, ay nagbibigay ng isang API para sa pamamahala sa bahagi ng network ng imprastraktura ng ulap. Pinapalakas at pinamamahalaan ng serbisyo ang bahagi ng networking ng Openstack sa pamamagitan ng pagbibigay ng abstraction layer na tinatawag na Network-as-a-Service (NaaS). Iyon ay, ang network ay ang parehong virtual na masusukat na yunit bilang, halimbawa, mga virtual na CPU core o ang halaga ng RAM.
Ngunit bago lumipat sa arkitektura ng bahagi ng network ng OpenStack, isaalang-alang natin kung paano gumagana ang network na ito sa OpenStack at kung bakit ang network ay isang mahalaga at mahalagang bahagi ng cloud.
Kaya mayroon kaming dalawang RED client VM at dalawang GREEN client VM. Ipagpalagay natin na ang mga makinang ito ay matatagpuan sa dalawang hypervisor sa ganitong paraan:
Sa ngayon, ito ay virtualization lamang ng 4 na server at wala nang iba pa, dahil sa ngayon ang nagawa lang namin ay virtualize ang 4 na server, inilalagay ang mga ito sa dalawang pisikal na server. At sa ngayon ay hindi pa sila konektado sa network.
Upang makagawa ng cloud, kailangan nating magdagdag ng ilang bahagi. Una, i-virtualize natin ang bahagi ng network - kailangan nating ikonekta ang 4 na makinang ito nang magkapares, at gusto ng mga kliyente ng L2 na koneksyon. Maaari kang gumamit ng switch at i-configure ang isang trunk sa direksyon nito at lutasin ang lahat gamit ang isang linux bridge o, para sa mas advanced na mga user, openvswitch (babalikan namin ito mamaya). Ngunit maaaring mayroong maraming mga network, at ang patuloy na pagtulak sa L2 sa pamamagitan ng isang switch ay hindi ang pinakamahusay na ideya - mayroong iba't ibang mga departamento, isang service desk, mga buwan ng paghihintay para makumpleto ang isang aplikasyon, mga linggo ng pag-troubleshoot - sa modernong mundo ito hindi na gumagana ang diskarte. At kapag mas maaga itong naiintindihan ng isang kumpanya, mas madali itong sumulong. Samakatuwid, sa pagitan ng mga hypervisors ay pipili kami ng isang L3 network kung saan ang aming mga virtual machine ay makikipag-ugnayan, at sa ibabaw ng L3 network na ito kami ay bubuo ng virtual L2 overlay network kung saan ang trapiko ng aming mga virtual machine ay tatakbo. Maaari mong gamitin ang GRE, Geneve o VxLAN bilang encapsulation. Tumutok tayo sa huli sa ngayon, bagama't hindi ito partikular na mahalaga.
Kailangan nating hanapin ang VTEP sa isang lugar (sana lahat ay pamilyar sa terminolohiya ng VxLAN). Dahil mayroon kaming L3 network na diretso mula sa mga server, walang pumipigil sa amin na maglagay ng VTEP sa mga server mismo, at ang OVS (OpenvSwitch) ay mahusay sa paggawa nito. Bilang resulta, nakuha namin ang disenyong ito:
Dahil ang trapiko sa pagitan ng mga VM ay dapat na hatiin, ang mga port patungo sa mga virtual machine ay magkakaroon ng iba't ibang mga numero ng vlan. Ang numero ng tag ay gumaganap ng isang papel sa loob lamang ng isang virtual switch, dahil kapag naka-encapsulate sa VxLAN madali nating maalis ito, dahil magkakaroon tayo ng VNI.
Ngayon ay maaari na tayong lumikha ng ating mga makina at virtual network para sa kanila nang walang anumang problema.
Gayunpaman, paano kung ang kliyente ay may ibang makina, ngunit nasa ibang network? Kailangan namin ng rooting sa pagitan ng mga network. Titingnan natin ang isang simpleng opsyon kapag ginamit ang sentralisadong pagruruta - iyon ay, ang trapiko ay niruruta sa pamamagitan ng mga espesyal na dedikadong network node (mabuti, bilang isang panuntunan, ang mga ito ay pinagsama sa mga control node, kaya magkakaroon tayo ng parehong bagay).
Mukhang walang kumplikado - gumawa kami ng isang bridge interface sa control node, humimok ng trapiko dito at mula roon ay dinadala namin ito kung saan namin ito kailangan. Ngunit ang problema ay ang RED client ay gustong gamitin ang 10.0.0.0/24 network, at ang GREEN client ay gustong gamitin ang 10.0.0.0/24 network. Iyon ay, nagsisimula kaming mag-intersect sa mga puwang ng address. Bukod pa rito, ayaw ng mga kliyente na maka-ruta ang ibang mga kliyente sa kanilang mga panloob na network, na may katuturan. Upang paghiwalayin ang mga network at trapiko ng data ng kliyente, maglalaan kami ng hiwalay na namespace para sa bawat isa sa kanila. Sa katunayan, ang namespace ay isang kopya ng Linux network stack, iyon ay, ang mga kliyente sa namespace na RED ay ganap na nakahiwalay sa mga kliyente mula sa namespace na GREEN (mabuti, alinman sa pagruruta sa pagitan ng mga network ng kliyente na ito ay pinapayagan sa pamamagitan ng default na namespace o sa upstream na kagamitan sa transportasyon).
Iyon ay, nakukuha natin ang sumusunod na diagram:
Ang mga L2 tunnel ay nagtatagpo mula sa lahat ng computing node patungo sa control node. node kung saan matatagpuan ang interface ng L3 para sa mga network na ito, bawat isa ay nasa isang nakalaang namespace para sa paghihiwalay.
Gayunpaman, nakalimutan namin ang pinakamahalagang bagay. Ang virtual machine ay dapat magbigay ng isang serbisyo sa kliyente, iyon ay, dapat itong magkaroon ng hindi bababa sa isang panlabas na interface kung saan maaari itong maabot. Ibig sabihin, kailangan nating lumabas sa labas ng mundo. Mayroong iba't ibang mga pagpipilian dito. Gawin natin ang pinakasimpleng opsyon. Magdaragdag kami ng isang network sa bawat kliyente, na magiging wasto sa network ng provider at hindi magkakapatong sa ibang mga network. Ang mga network ay maaari ding mag-intersect at tumingin sa iba't ibang mga VRF sa gilid ng network ng provider. Ang data ng network ay mabubuhay din sa namespace ng bawat kliyente. Gayunpaman, lalabas pa rin sila sa labas ng mundo sa pamamagitan ng isang pisikal (o bond, na mas lohikal) na interface. Upang paghiwalayin ang trapiko ng kliyente, ang trapiko sa labas ay ita-tag ng isang VLAN tag na nakalaan sa kliyente.
Bilang resulta, nakuha namin ang diagram na ito:
Ang isang makatwirang tanong ay bakit hindi gumawa ng mga gateway sa mga compute node mismo? Hindi ito isang malaking problema; bukod dito, kung i-on mo ang distributed router (DVR), gagana ito. Sa sitwasyong ito, isinasaalang-alang namin ang pinakasimpleng opsyon na may sentralisadong gateway, na ginagamit bilang default sa Openstack. Para sa mga function na may mataas na load, gagamit sila ng parehong distributed router at acceleration technologies gaya ng SR-IOV at Passthrough, ngunit tulad ng sinasabi nila, iyon ay isang ganap na naiibang kuwento. Una, harapin natin ang pangunahing bahagi, at pagkatapos ay pupunta tayo sa mga detalye.
Sa totoo lang, ang aming scheme ay magagawa na, ngunit mayroong ilang mga nuances:
- Kailangan nating protektahan ang ating mga makina, iyon ay, maglagay ng filter sa interface ng switch patungo sa kliyente.
- Gawing posible para sa isang virtual machine na awtomatikong makakuha ng isang IP address, upang hindi mo na kailangang mag-log in dito sa pamamagitan ng console sa bawat oras at irehistro ang address.
Magsimula tayo sa proteksyon ng makina. Para dito maaari mong gamitin ang mga banal na iptables, bakit hindi.
Iyon ay, ngayon ang aming topology ay naging mas kumplikado:
Mag-move on na tayo. Kailangan nating magdagdag ng DHCP server. Ang pinakaperpektong lugar upang mahanap ang mga DHCP server para sa bawat kliyente ay ang control node na nabanggit na sa itaas, kung saan matatagpuan ang mga namespace:
Gayunpaman, mayroong isang maliit na problema. Paano kung mag-reboot ang lahat at mawala ang lahat ng impormasyon tungkol sa pagrenta ng mga address sa DHCP. Ito ay lohikal na ang mga makina ay bibigyan ng mga bagong address, na hindi masyadong maginhawa. Mayroong dalawang paraan dito - gumamit ng mga domain name at magdagdag ng DNS server para sa bawat kliyente, kung gayon ang address ay hindi magiging partikular na mahalaga sa amin (katulad ng bahagi ng network sa k8s) - ngunit may problema sa mga panlabas na network, dahil ang mga address ay maaari ding maibigay sa kanila sa pamamagitan ng DHCP - kailangan mo ng pag-synchronize sa mga DNS server sa cloud platform at isang panlabas na DNS server, na sa palagay ko ay hindi masyadong nababaluktot, ngunit posible. O ang pangalawang opsyon ay ang paggamit ng metadata - iyon ay, i-save ang impormasyon tungkol sa address na ibinigay sa makina upang malaman ng DHCP server kung aling address ang ibibigay sa makina kung ang makina ay nakatanggap na ng isang address. Ang pangalawang pagpipilian ay mas simple at mas nababaluktot, dahil pinapayagan ka nitong mag-save ng karagdagang impormasyon tungkol sa kotse. Ngayon, magdagdag tayo ng metadata ng ahente sa diagram:
Ang isa pang isyu na dapat ding pag-usapan ay ang kakayahang gumamit ng isang panlabas na network ng lahat ng mga kliyente, dahil ang mga panlabas na network, kung dapat silang wasto sa buong network, ay magiging mahirap - kailangan mong patuloy na maglaan at kontrolin ang paglalaan ng mga network na ito. Ang kakayahang gumamit ng isang panlabas na paunang na-configure na network para sa lahat ng mga kliyente ay magiging lubhang kapaki-pakinabang kapag gumagawa ng isang pampublikong ulap. Gagawin nitong mas madali ang pag-deploy ng mga machine dahil hindi namin kailangang kumonsulta sa database ng address at pumili ng natatanging address space para sa panlabas na network ng bawat kliyente. Bilang karagdagan, maaari kaming magparehistro ng isang panlabas na network nang maaga at sa oras ng pag-deploy kakailanganin lamang naming iugnay ang mga panlabas na address sa mga makina ng kliyente.
At dito tinutulungan kami ng NAT - gagawin lang namin na posible para sa mga kliyente na ma-access ang labas ng mundo sa pamamagitan ng default na namespace gamit ang pagsasalin ng NAT. Well, narito ang isang maliit na problema. Ito ay mabuti kung ang client server ay kumikilos bilang isang kliyente at hindi bilang isang server - iyon ay, ito ay nagsisimula sa halip na tumatanggap ng mga koneksyon. Ngunit para sa amin ito ay magiging kabaligtaran. Sa kasong ito, kailangan nating gawin ang destination NAT upang kapag tumatanggap ng trapiko, nauunawaan ng control node na ang trapikong ito ay inilaan para sa virtual machine A ng client A, na nangangahulugang kailangan nating gumawa ng NAT translation mula sa isang panlabas na address, halimbawa 100.1.1.1 .10.0.0.1, sa isang panloob na address 100. Sa kasong ito, kahit na ang lahat ng mga kliyente ay gagamit ng parehong network, ang panloob na paghihiwalay ay ganap na napanatili. Iyon ay, kailangan nating gawin ang dNAT at sNAT sa control node. Kung gagamit ng isang network na may mga lumulutang na address o panlabas na network, o pareho nang sabay-sabay, ay depende sa kung ano ang gusto mong dalhin sa cloud. Hindi kami magdaragdag ng mga lumulutang na address sa diagram, ngunit iiwan ang mga panlabas na network na naidagdag nang mas maaga - bawat kliyente ay may sariling panlabas na network (sa diagram ay ipinahiwatig ang mga ito bilang vlan 200 at XNUMX sa panlabas na interface).
Bilang resulta, nakatanggap kami ng isang kawili-wili at sa parehong oras na pinag-isipang mabuti na solusyon, na may tiyak na kakayahang umangkop ngunit wala pang mga mekanismo ng pagpapahintulot sa kasalanan.
Una, mayroon lamang kaming isang control node - ang pagkabigo nito ay hahantong sa pagbagsak ng lahat ng mga system. Upang ayusin ang problemang ito, kailangan mong gumawa ng hindi bababa sa isang korum ng 3 node. Idagdag natin ito sa diagram:
Naturally, lahat ng node ay naka-synchronize at kapag ang isang aktibong node ay umalis, isa pang node ang kukuha sa mga responsibilidad nito.
Ang susunod na problema ay ang mga virtual machine disk. Sa ngayon, ang mga ito ay naka-imbak sa mga hypervisor mismo, at sa kaso ng mga problema sa hypervisor, nawala namin ang lahat ng data - at ang pagkakaroon ng isang pagsalakay ay hindi makakatulong dito kung mawawala namin hindi ang disk, ngunit ang buong server. Para magawa ito, kailangan naming gumawa ng serbisyo na magsisilbing front end para sa ilang uri ng storage. Kung anong uri ng storage ito ay hindi partikular na mahalaga sa amin, ngunit dapat nitong protektahan ang aming data mula sa pagkabigo ng parehong disk at node, at posibleng ang buong cabinet. Mayroong ilang mga pagpipilian dito - mayroong, siyempre, mga network ng SAN na may Fiber Channel, ngunit maging tapat tayo - ang FC ay isang relic na ng nakaraan - isang analogue ng E1 sa transportasyon - oo, sumasang-ayon ako, ginagamit pa rin ito, ngunit lamang kung saan ito ay ganap na imposible kung wala ito. Samakatuwid, hindi ako boluntaryong magde-deploy ng isang network ng FC sa 2020, alam kong may iba pang mas kawili-wiling mga alternatibo. Bagama't sa kanya-kanyang sarili, maaaring may mga naniniwala na ang FC sa lahat ng limitasyon nito ay ang kailangan lang natin - Hindi ako magtatalo, lahat ay may kanya-kanyang opinyon. Gayunpaman, ang pinaka-kagiliw-giliw na solusyon sa aking opinyon ay ang paggamit ng isang SDS, tulad ng Ceph.
Pinapayagan ka ng Ceph na bumuo ng isang mataas na magagamit na solusyon sa pag-iimbak ng data na may isang bungkos ng mga posibleng backup na opsyon, na nagsisimula sa mga code na may parity checking (katulad ng raid 5 o 6) na nagtatapos sa buong pagtitiklop ng data sa iba't ibang mga disk, na isinasaalang-alang ang lokasyon ng mga disk sa mga server, at mga server sa mga cabinet, atbp.
Para makabuo ng Ceph kailangan mo ng 3 pang node. Ang pakikipag-ugnayan sa imbakan ay isasagawa rin sa pamamagitan ng network gamit ang mga serbisyo ng block, object at file storage. Magdagdag tayo ng storage sa schema:
Tandaan: maaari ka ring gumawa ng hyperconverged compute node - ito ang konsepto ng pagsasama-sama ng ilang function sa isang node - halimbawa, storage+compute - nang hindi nag-dedicate ng mga espesyal na node para sa ceph storage. Makakakuha kami ng parehong fault-tolerant scheme - dahil ang SDS ay magrereserba ng data sa antas ng reserbasyon na aming tinukoy. Gayunpaman, ang mga hyperconverged node ay palaging isang kompromiso - dahil ang storage node ay hindi lamang nagpapainit ng hangin na tila sa unang tingin (dahil walang mga virtual machine dito) - ginugugol nito ang mga mapagkukunan ng CPU sa pagseserbisyo sa SDS (sa katunayan, ginagawa nito ang lahat ang pagtitiklop at pagbawi pagkatapos ng mga pagkabigo ng mga node, disk, atbp.). Ibig sabihin, mawawala sa iyo ang ilan sa kapangyarihan ng compute node kung pagsasamahin mo ito sa storage.
Ang lahat ng bagay na ito ay kailangang pamahalaan kahit papaano - kailangan namin ng isang bagay kung saan maaari kaming lumikha ng isang makina, isang network, isang virtual na router, atbp. Upang gawin ito, magdaragdag kami ng isang serbisyo sa control node na magsisilbing isang dashboard - ang Makakakonekta ang kliyente sa portal na ito sa pamamagitan ng http/ https at gawin ang lahat ng kailangan niya (well, halos).
Bilang resulta, mayroon na tayong fault-tolerant system. Ang lahat ng mga elemento ng imprastraktura na ito ay dapat na pamahalaan kahit papaano. Nauna nang inilarawan na ang Openstack ay isang set ng mga proyekto, bawat isa ay nagbibigay ng isang partikular na function. Tulad ng nakikita natin, mayroong higit sa sapat na mga elemento na kailangang i-configure at kontrolin. Ngayon ay pag-uusapan natin ang bahagi ng network.
Arkitektura ng neutron
Sa OpenStack, si Neutron ang may pananagutan sa pagkonekta ng mga virtual machine port sa isang karaniwang L2 network, tinitiyak ang traffic routing sa pagitan ng mga VM na matatagpuan sa iba't ibang L2 network, pati na rin ang outward routing, na nagbibigay ng mga serbisyo tulad ng NAT, Floating IP, DHCP, atbp.
Sa isang mataas na antas, ang pagpapatakbo ng serbisyo ng network (ang pangunahing bahagi) ay maaaring ilarawan bilang mga sumusunod.
Kapag sinimulan ang VM, ang serbisyo ng network ay:
- Lumilikha ng port para sa isang naibigay na VM (o mga port) at inaabisuhan ang serbisyo ng DHCP tungkol dito;
- Ang isang bagong virtual network device ay nilikha (sa pamamagitan ng libvirt);
- Kumokonekta ang VM sa (mga) port na ginawa sa hakbang 1;
Kakatwa, ang gawain ng Neutron ay nakabatay sa mga karaniwang mekanismo na pamilyar sa lahat ng naka-dive sa Linux - mga namespace, iptables, linux bridges, openvswitch, conntrack, atbp.
Dapat itong agad na linawin na ang Neutron ay hindi isang SDN controller.
Ang Neutron ay binubuo ng ilang magkakaugnay na bahagi:
Openstack-neutron-server ay isang daemon na gumagana sa mga kahilingan ng user sa pamamagitan ng API. Ang demonyong ito ay hindi kasangkot sa pagrehistro ng anumang mga koneksyon sa network, ngunit nagbibigay ng kinakailangang impormasyon para dito sa mga plugin nito, na pagkatapos ay i-configure ang nais na elemento ng network. Ang mga ahente ng Neutron sa mga OpenStack node ay nagrerehistro sa Neutron server.
Ang Neutron-server ay talagang isang application na nakasulat sa python, na binubuo ng dalawang bahagi:
- Serbisyong REST
- Neutron Plugin (core/serbisyo)
Ang serbisyo ng REST ay idinisenyo upang makatanggap ng mga tawag sa API mula sa iba pang mga bahagi (halimbawa, isang kahilingan na magbigay ng ilang impormasyon, atbp.)
Ang mga plugin ay mga plug-in na bahagi/modul ng software na tinatawag sa panahon ng mga kahilingan sa API - iyon ay, ang pagpapatungkol ng isang serbisyo ay nangyayari sa pamamagitan ng mga ito. Ang mga plugin ay nahahati sa dalawang uri - serbisyo at ugat. Bilang panuntunan, ang horse plugin ang pangunahing responsable sa pamamahala sa address space at L2 na koneksyon sa pagitan ng mga VM, at ang mga service plugin ay nagbibigay na ng karagdagang functionality gaya ng VPN o FW.
Ang listahan ng mga plugin na magagamit ngayon ay maaaring matingnan halimbawa
Maaaring mayroong ilang mga plugin ng serbisyo, ngunit maaari lamang magkaroon ng isang plugin ng kabayo.
openstack-neutron-ml2 ay ang karaniwang Openstack root plugin. Ang plugin na ito ay may modular na arkitektura (hindi katulad ng hinalinhan nito) at kino-configure ang serbisyo ng network sa pamamagitan ng mga driver na konektado dito. Titingnan natin ang plugin mismo sa ibang pagkakataon, dahil sa katunayan ay nagbibigay ito ng flexibility na mayroon ang OpenStack sa bahagi ng network. Maaaring palitan ang root plugin (halimbawa, ang Contrail Networking ay gumagawa ng ganoong kapalit).
Serbisyo ng RPC (rabbitmq-server) β isang serbisyong nagbibigay ng pamamahala ng pila at pakikipag-ugnayan sa ibang mga serbisyo ng OpenStack, pati na rin ng pakikipag-ugnayan sa pagitan ng mga ahente ng serbisyo sa network.
Mga ahente sa network β mga ahente na matatagpuan sa bawat node, kung saan na-configure ang mga serbisyo ng network.
Mayroong ilang mga uri ng mga ahente.
Ang pangunahing ahente ay L2 ahente. Ang mga ahenteng ito ay tumatakbo sa bawat isa sa mga hypervisors, kabilang ang mga control node (mas tiyak, sa lahat ng mga node na nagbibigay ng anumang serbisyo para sa mga nangungupahan) at ang kanilang pangunahing function ay upang ikonekta ang mga virtual machine sa isang karaniwang L2 network, at bumuo din ng mga alerto kapag may nangyaring anumang kaganapan ( halimbawa huwag paganahin/paganahin ang port).
Ang susunod, walang gaanong mahalagang ahente ay L3 ahente. Bilang default, ang ahente na ito ay eksklusibo na tumatakbo sa isang network node (kadalasan ang network node ay pinagsama sa isang control node) at nagbibigay ng pagruruta sa pagitan ng mga network ng nangungupahan (kapwa sa pagitan ng mga network nito at ng mga network ng iba pang mga nangungupahan, at naa-access sa labas ng mundo, na nagbibigay ng NAT, pati na rin ang serbisyo ng DHCP). Gayunpaman, kapag gumagamit ng isang DVR (naipamahagi na router), ang pangangailangan para sa isang L3 plugin ay lilitaw din sa mga compute node.
Gumagamit ang L3 agent ng mga namespace ng Linux upang mabigyan ang bawat tenant ng isang set ng sarili nitong mga nakahiwalay na network at ang functionality ng mga virtual na router na nagruruta ng trapiko at nagbibigay ng mga serbisyo ng gateway para sa mga network ng Layer 2.
Database β isang database ng mga identifier ng mga network, subnet, port, pool, atbp.
Sa katunayan, tinatanggap ng Neutron ang mga kahilingan ng API mula sa paglikha ng anumang mga entity ng network, pinatutunayan ang kahilingan, at sa pamamagitan ng RPC (kung nag-access ito ng ilang plugin o ahente) o REST API (kung nakikipag-usap ito sa SDN) ipinapadala sa mga ahente (sa pamamagitan ng mga plugin) ang mga tagubilin na kinakailangan upang ayusin ang hiniling na serbisyo.
Ngayon ay bumaling tayo sa pag-install ng pagsubok (kung paano ito na-deploy at kung ano ang kasama dito, makikita natin mamaya sa praktikal na bahagi) at tingnan kung saan matatagpuan ang bawat bahagi:
(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 ~]$
Sa totoo lang, iyon ang buong istraktura ng Neutron. Ngayon ay sulit na gumugol ng ilang oras sa ML2 plugin.
Modular Layer 2
Tulad ng nabanggit sa itaas, ang plugin ay isang karaniwang OpenStack root plugin at may modular na arkitektura.
Ang hinalinhan ng ML2 plugin ay may monolitikong istraktura, na hindi pinapayagan, halimbawa, ang paggamit ng isang halo ng ilang mga teknolohiya sa isang pag-install. Halimbawa, hindi mo maaaring gamitin ang parehong openvswitch at linuxbridge sa parehong oras - alinman sa una o pangalawa. Para sa kadahilanang ito, nilikha ang ML2 plugin kasama ang arkitektura nito.
Ang ML2 ay may dalawang bahagi - dalawang uri ng mga driver: Uri ng mga driver at Mechanism driver.
Uri ng mga driver tukuyin ang mga teknolohiyang gagamitin upang ayusin ang mga koneksyon sa network, halimbawa VxLAN, VLAN, GRE. Kasabay nito, pinapayagan ng driver ang paggamit ng iba't ibang mga teknolohiya. Ang karaniwang teknolohiya ay VxLAN encapsulation para sa mga overlay na network at vlan external network.
Kasama sa mga driver ng uri ang mga sumusunod na uri ng network:
Patag - network nang walang pag-tag
Mga VLAN - naka-tag na network
Lokal β isang espesyal na uri ng network para sa mga all-in-one na pag-install (ang mga ganitong pag-install ay kailangan para sa mga developer o para sa pagsasanay)
GRE β overlay network gamit ang GRE tunnels
VxLAN β overlay network gamit ang VxLAN tunnels
Mga driver ng mekanismo tukuyin ang mga tool na nagsisiguro sa organisasyon ng mga teknolohiyang tinukoy sa uri ng driver - halimbawa, openvswitch, sr-iov, opendaylight, OVN, atbp.
Depende sa pagpapatupad ng driver na ito, gagamitin ang alinman sa mga ahente na kinokontrol ng Neutron, o gagamitin ang mga koneksyon sa isang external na controller ng SDN, na nangangasiwa sa lahat ng isyu na nauugnay sa pag-aayos ng mga L2 network, pagruruta, atbp.
Halimbawa: kung gagamitin namin ang ML2 kasama ng OVS, pagkatapos ay isang L2 agent ang naka-install sa bawat computing node na namamahala sa OVS. Gayunpaman, kung gagamitin natin, halimbawa, ang OVN o OpenDayLight, ang kontrol ng OVS ay nasa ilalim ng kanilang hurisdiksyon - Ang Neutron, sa pamamagitan ng root plugin, ay nagbibigay ng mga utos sa controller, at ginagawa na nito ang sinabi nito.
Mag-ayos tayo sa Open vSwitch
Sa ngayon, ang isa sa mga pangunahing bahagi ng OpenStack ay ang Open vSwitch.
Kapag nag-i-install ng OpenStack nang walang anumang karagdagang vendor na SDN gaya ng Juniper Contrail o Nokia Nuage, ang OVS ang pangunahing bahagi ng network ng cloud network at, kasama ng mga iptables, conntrack, namespaces, ay nagbibigay-daan sa iyong ayusin ang mga ganap na multi-tenancy overlay na network. Natural, ang bahaging ito ay maaaring palitan, halimbawa, kapag gumagamit ng mga solusyon sa SDN ng third-party na pagmamay-ari (vendor).
Ang OVS ay isang open source software switch na idinisenyo para gamitin sa mga virtualized na kapaligiran bilang isang virtual traffic forwarder.
Sa ngayon, ang OVS ay may napakahusay na pag-andar, na kinabibilangan ng mga teknolohiya tulad ng QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, atbp.
Tandaan: Ang OVS ay hindi paunang naisip bilang isang malambot na switch para sa mataas na load na mga function ng telecom at mas idinisenyo para sa mas kaunting bandwidth-demanding IT function tulad ng WEB server o mail server. Gayunpaman, ang OVS ay higit na binuo at ang kasalukuyang mga pagpapatupad ng OVS ay lubos na napabuti ang pagganap at mga kakayahan nito, na nagpapahintulot na magamit ito ng mga operator ng telecom na may mataas na load na mga function, halimbawa, mayroong isang pagpapatupad ng OVS na may suporta para sa DPDK acceleration.
May tatlong mahalagang bahagi ng OVS na kailangan mong malaman:
- Module ng kernel β isang bahagi na matatagpuan sa puwang ng kernel na nagpoproseso ng trapiko batay sa mga tuntuning natanggap mula sa elemento ng kontrol;
- vSwitch Ang daemon (ovs-vswitchd) ay isang prosesong inilunsad sa espasyo ng gumagamit na responsable para sa pagprograma ng kernel module - ibig sabihin, ito ay direktang kumakatawan sa lohika ng pagpapatakbo ng switch
- Server ng database - isang lokal na database na matatagpuan sa bawat host na nagpapatakbo ng OVS, kung saan naka-imbak ang configuration. Ang mga controller ng SDN ay maaaring makipag-usap sa pamamagitan ng module na ito gamit ang OVSDB protocol.
Ang lahat ng ito ay sinamahan ng isang set ng diagnostic at management utilities, gaya ng ovs-vsctl, ovs-appctl, ovs-ofctl, atbp.
Sa kasalukuyan, ang Openstack ay malawakang ginagamit ng mga operator ng telecom upang i-migrate ang mga function ng network dito, tulad ng EPC, SBC, HLR, atbp. Ang ilang mga function ay maaaring mabuhay nang walang problema sa OVS, ngunit halimbawa, ang EPC ay nagpoproseso ng trapiko ng subscriber - pagkatapos ay dumaan ito isang malaking halaga ng trapiko (ngayon ang dami ng trapiko ay umaabot sa ilang daang gigabit bawat segundo). Naturally, ang pagmamaneho ng naturang trapiko sa pamamagitan ng kernel space (dahil ang forwarder ay matatagpuan doon bilang default) ay hindi ang pinakamahusay na ideya. Samakatuwid, ang OVS ay kadalasang naka-deploy nang buo sa espasyo ng gumagamit gamit ang teknolohiya ng pagpapabilis ng DPDK upang ipasa ang trapiko mula sa NIC patungo sa espasyo ng gumagamit na lumalampas sa kernel.
Tandaan: para sa isang cloud na naka-deploy para sa mga function ng telecom, posibleng mag-output ng trapiko mula sa isang compute node na direktang lumalampas sa OVS patungo sa paglipat ng kagamitan. Ang mga mekanismo ng SR-IOV at Passthrough ay ginagamit para sa layuning ito.
Paano ito gumagana sa isang tunay na layout?
Well, ngayon ay lumipat tayo sa praktikal na bahagi at tingnan kung paano gumagana ang lahat sa pagsasanay.
Una, mag-deploy tayo ng simpleng pag-install ng Openstack. Dahil wala akong set ng mga server para sa mga eksperimento, bubuuin namin ang prototype sa isang pisikal na server mula sa mga virtual machine. Oo, natural, ang gayong solusyon ay hindi angkop para sa mga komersyal na layunin, ngunit upang makita ang isang halimbawa kung paano gumagana ang network sa Openstack, ang gayong pag-install ay sapat na para sa mga mata. Bukod dito, ang naturang pag-install ay mas kawili-wili para sa mga layunin ng pagsasanay - dahil maaari mong mahuli ang trapiko, atbp.
Dahil kailangan lang nating makita ang pangunahing bahagi, hindi tayo maaaring gumamit ng ilang network ngunit itaas ang lahat gamit lamang ang dalawang network, at ang pangalawang network sa layout na ito ay gagamitin nang eksklusibo para sa pag-access sa undercloud at DNS server. Hindi namin hawakan ang mga panlabas na network sa ngayon - ito ay isang paksa para sa isang hiwalay na malaking artikulo.
Kaya, magsimula tayo sa pagkakasunud-sunod. Una, isang maliit na teorya. I-install namin ang Openstack gamit ang TripleO (Openstack sa Openstack). Ang kakanyahan ng TripleO ay ang pag-install namin ng Openstack all-in-one (iyon ay, sa isang node), na tinatawag na undercloud, at pagkatapos ay ginagamit ang mga kakayahan ng na-deploy na Openstack upang i-install ang Openstack na inilaan para sa operasyon, na tinatawag na overcloud. Gagamitin ng Undercloud ang likas nitong kakayahan upang pamahalaan ang mga pisikal na server (bare metal) - ang Ironic na proyekto - upang magbigay ng mga hypervisor na gaganap sa mga tungkulin ng pag-compute, kontrol, at mga storage node. Ibig sabihin, hindi kami gumagamit ng anumang mga tool ng third-party upang i-deploy ang Openstack - i-deploy namin ang Openstack gamit ang Openstack. Ito ay magiging mas malinaw habang umuusad ang pag-install, kaya hindi kami titigil doon at sumulong.
Tandaan: Sa artikulong ito, para sa kapakanan ng pagiging simple, hindi ako gumamit ng network isolation para sa mga internal na Openstack network, ngunit lahat ay na-deploy gamit ang isang network lamang. Gayunpaman, ang pagkakaroon o kawalan ng paghihiwalay ng network ay hindi nakakaapekto sa pangunahing pag-andar ng solusyon - lahat ay gagana nang eksakto katulad ng kapag gumagamit ng paghihiwalay, ngunit ang trapiko ay dadaloy sa parehong network. Para sa isang komersyal na pag-install, natural na kinakailangan na gumamit ng paghihiwalay gamit ang iba't ibang mga vlan at interface. Halimbawa, ang trapiko sa pamamahala ng imbakan ng ceph at ang trapiko ng data mismo (pag-access sa makina sa mga disk, atbp.) kapag nakahiwalay ay gumagamit ng iba't ibang mga subnet (Pamamahala ng imbakan at Imbakan) at binibigyang-daan ka nitong gawing mas fault-tolerant ang solusyon sa pamamagitan ng paghahati sa trapikong ito, halimbawa. , sa iba't ibang port, o paggamit ng iba't ibang mga profile ng QoS para sa iba't ibang trapiko upang hindi masira ng trapiko ng data ang signaling traffic. Sa aming kaso, pupunta sila sa parehong network at sa katunayan hindi kami nililimitahan nito sa anumang paraan.
Tandaan: Dahil tatakbo tayo ng mga virtual machine sa isang virtual na kapaligiran batay sa mga virtual machine, kailangan muna nating paganahin ang nested virtualization.
Maaari mong suriin kung ang nested virtualization ay pinagana o hindi tulad nito:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Kung nakikita mo ang titik N, pinagana namin ang suporta para sa nested virtualization ayon sa anumang gabay na makikita mo sa network, halimbawa .
Kailangan nating tipunin ang sumusunod na circuit mula sa mga virtual machine:
Sa aking kaso, upang ikonekta ang mga virtual machine na bahagi ng pag-install sa hinaharap (at nakakuha ako ng 7 sa kanila, ngunit maaari kang makayanan ang 4 kung wala kang maraming mapagkukunan), ginamit ko ang OpenvSwitch. Gumawa ako ng isang ovs bridge at ikinonekta ang mga virtual machine dito sa pamamagitan ng mga port-group. Upang gawin ito, gumawa ako ng isang xml file tulad nito:
[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>Tatlong port group ang idineklara dito - dalawang access at isang trunk (kinailangan ang huli para sa DNS server, ngunit magagawa mo nang wala ito, o i-install ito sa host machine - alinman ang mas maginhawa para sa iyo). Susunod, gamit ang template na ito, ipinapahayag namin ang sa amin sa pamamagitan ng virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Ngayon i-edit namin ang mga pagsasaayos ng hypervisor port:
[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 ~]# Tandaan: sa sitwasyong ito, hindi maa-access ang address sa port ovs-br1 dahil wala itong vlan tag. Upang ayusin ito, kailangan mong mag-isyu ng command sudo ovs-vsctl set port ovs-br1 tag=100. Gayunpaman, pagkatapos ng pag-reboot, mawawala ang tag na ito (kung may nakakaalam kung paano ito mananatili sa lugar, lubos akong magpapasalamat). Ngunit hindi ito napakahalaga, dahil kakailanganin lang namin ang address na ito sa panahon ng pag-install at hindi na ito kakailanganin kapag ganap na na-deploy ang Openstack.
Susunod, lumikha kami ng isang undercloud machine:
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=ttyS0Sa panahon ng pag-install, itinakda mo ang lahat ng kinakailangang mga parameter, tulad ng pangalan ng makina, mga password, mga gumagamit, mga ntp server, atbp., maaari mong agad na i-configure ang mga port, ngunit para sa akin nang personal, pagkatapos ng pag-install, mas madaling mag-log in sa makina sa pamamagitan ng ang console at itama ang mga kinakailangang file. Kung mayroon ka nang yari na imahe, maaari mo itong gamitin, o gawin ang ginawa ko - i-download ang minimal na larawan ng Centos 7 at gamitin ito upang i-install ang VM.
Pagkatapos ng matagumpay na pag-install, dapat ay mayroon kang virtual machine kung saan maaari kang mag-install ng undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningUna, i-install ang mga tool na kinakailangan para sa proseso ng pag-install:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Pag-install ng undercloud
Lumilikha kami ng stack user, nagtakda ng password, idagdag ito sa sudoer at binibigyan siya ng kakayahang magsagawa ng mga root command sa pamamagitan ng sudo nang hindi kinakailangang magpasok ng password:
useradd stack
passwd stack
echo βstack ALL=(root) NOPASSWD:ALLβ > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNgayon ay tinukoy namin ang buong pangalan ng undercloud sa file ng mga host:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Susunod, nagdaragdag kami ng mga repositoryo at i-install ang software na kailangan namin:
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-ansibleTandaan: kung hindi mo planong mag-install ng ceph, hindi mo na kailangang magpasok ng mga command na nauugnay sa ceph. Ginamit ko ang Queens release, ngunit maaari mong gamitin ang anumang iba pang gusto mo.
Susunod, kopyahin ang undercloud configuration file sa home directory stack ng user:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNgayon ay kailangan naming itama ang file na ito, i-adjust ito sa aming pag-install.
Kailangan mong idagdag ang mga linyang ito sa simula ng file:
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 = 10Kaya, dumaan tayo sa mga setting:
undercloud_hostname β ang buong pangalan ng undercloud server, ay dapat tumugma sa entry sa DNS server
local_ip β lokal na undercloud na address patungo sa pagbibigay ng network
network_gateway β ang parehong lokal na address, na magsisilbing gateway para sa pag-access sa labas ng mundo sa panahon ng pag-install ng mga overcloud node, ay tumutugma din sa lokal na ip
undercloud_public_host β panlabas na API address, ang anumang libreng address mula sa provisioning network ay itinalaga
undercloud_admin_host panloob na API address, ang anumang libreng address mula sa provisioning network ay itinalaga
undercloud_nameservers - DNS server
generate_service_certificate - Napakahalaga ng linyang ito sa kasalukuyang halimbawa, dahil kung hindi mo ito itatakda sa false makakatanggap ka ng error sa panahon ng pag-install, ang problema ay inilalarawan sa Red Hat bug tracker
local_interface interface sa pagbibigay ng network. Ire-reconfigure ang interface na ito sa panahon ng undercloud deployment, kaya kailangan mong magkaroon ng dalawang interface sa undercloud - isa para ma-access ito, ang pangalawa para sa provisioning
local_mtu β MTU. Dahil mayroon kaming test laboratory at mayroon akong MTU na 1500 sa mga OVS switch port, kailangan itong itakda sa 1450 upang ang mga packet na naka-encapsulated sa VxLAN ay makapasa.
network_cidr β network ng pagbibigay
pagbabalatkayo β gamit ang NAT upang ma-access ang isang panlabas na network
masquerade_network - network na magiging NATed
dhcp_start β ang panimulang address ng address pool kung saan ang mga address ay itatalaga sa mga node sa panahon ng overcloud deployment
dhcp_end β ang huling address ng address pool kung saan ang mga address ay itatalaga sa mga node sa panahon ng overcloud deployment
inspeksyon_iprange β isang pool ng mga address na kailangan para sa introspection (hindi dapat mag-overlap sa pool sa itaas)
scheduler_max_attempts β maximum na bilang ng mga pagtatangka na mag-install ng overcloud (dapat mas malaki sa o katumbas ng bilang ng mga node)
Matapos ilarawan ang file, maaari mong ibigay ang command na mag-deploy ng undercloud:
openstack undercloud install
Ang pamamaraan ay tumatagal mula 10 hanggang 30 minuto depende sa iyong bakal. Sa huli dapat mong makita ang output tulad nito:
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.
#############################################################################Sinasabi ng output na ito na matagumpay mong na-install ang undercloud at maaari mo na ngayong suriin ang status ng undercloud at magpatuloy sa pag-install ng overcloud.
Kung titingnan mo ang output ng ifconfig, makikita mo na lumitaw ang isang bagong interface ng tulay
[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 0Ang overcloud deployment ay isasagawa na ngayon sa pamamagitan ng interface na ito.
Mula sa output sa ibaba makikita mo na mayroon kaming lahat ng mga serbisyo sa isang node:
(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 |
+--------------------------+-----------+----------+Nasa ibaba ang configuration ng undercloud na bahagi ng network:
(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 ~]$Pag-install ng overcloud
Sa ngayon, mayroon lang kaming undercloud, at wala kaming sapat na mga node kung saan bubuuin ang overcloud. Samakatuwid, una sa lahat, i-deploy natin ang mga virtual machine na kailangan natin. Sa panahon ng pag-deploy, ang undercloud mismo ay mag-i-install ng OS at ang kinakailangang software sa overcloud machine - iyon ay, hindi namin kailangang ganap na i-deploy ang makina, ngunit lumikha lamang ng isang disk (o mga disk) para dito at matukoy ang mga parameter nito - iyon ay , sa katunayan, nakakakuha kami ng hubad na server na walang OS na naka-install dito .
Pumunta tayo sa folder na may mga disk ng ating mga virtual machine at lumikha ng mga disk ng kinakailangang laki:
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 160GDahil kami ay tumatakbo bilang root, kailangan naming baguhin ang may-ari ng mga disk na ito upang hindi magkaroon ng problema sa mga karapatan:
[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]# Tandaan: kung hindi mo planong i-install ang ceph upang pag-aralan ito, kung gayon ang mga utos ay hindi lumikha ng hindi bababa sa 3 node na may hindi bababa sa dalawang disk, ngunit sa template ay nagpapahiwatig na ang mga virtual disk na vda, vdb, atbp. ay gagamitin.
Mahusay, ngayon kailangan nating tukuyin ang lahat ng mga makinang ito:
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 Sa dulo ay mayroong command -print-xml > /tmp/storage-1.xml, na lumilikha ng xml file na may paglalarawan ng bawat makina sa /tmp/ folder; kung hindi mo ito idadagdag, hindi ka magiging kayang tumukoy ng mga virtual machine.
Ngayon kailangan nating tukuyin ang lahat ng mga makinang ito sa 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 ~]#Ngayon ay isang maliit na nuance - ang tripleO ay gumagamit ng IPMI upang pamahalaan ang mga server sa panahon ng pag-install at pagsisiyasat ng sarili.
Ang introspection ay ang proseso ng pag-inspeksyon sa hardware upang makuha ang mga parameter nito na kinakailangan para sa karagdagang provisioning ng mga node. Introspection ay isinasagawa gamit ang ironic, isang serbisyo na idinisenyo upang gumana sa mga bare metal server.
Ngunit narito ang problema - habang ang mga server ng IPMI ng hardware ay may hiwalay na port (o isang nakabahaging port, ngunit hindi ito mahalaga), kung gayon ang mga virtual machine ay walang ganoong mga port. Narito ang isang saklay na tinatawag na vbmc ay tumulong sa amin - isang utility na nagbibigay-daan sa iyong tularan ang isang IPMI port. Ang nuance na ito ay nagkakahalaga ng pagbibigay pansin lalo na para sa mga nais mag-set up ng naturang laboratoryo sa isang ESXI hypervisor - upang maging matapat, hindi ko alam kung mayroon itong analogue ng vbmc, kaya sulit na magtaka tungkol sa isyung ito bago i-deploy ang lahat. .
I-install ang vbmc:
yum install yum install python2-virtualbmcKung hindi mahanap ng iyong OS ang package, idagdag ang repositoryo:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNgayon ay itinakda namin ang utility. Ang lahat dito ay banal hanggang sa kahihiyan. Ngayon ay lohikal na walang mga server sa listahan ng vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Para lumitaw ang mga ito, dapat silang manu-manong ideklara tulad nito:
[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 ~]#Sa tingin ko ang command syntax ay malinaw nang walang paliwanag. Gayunpaman, sa ngayon ang lahat ng aming mga session ay nasa DOWN status. Para makalipat sila sa katayuan ng UP, kailangan mong paganahin sila:
[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 ~]#At ang pangwakas na pagpindot - kailangan mong iwasto ang mga panuntunan sa firewall (o ganap na huwag paganahin ito):
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
Ngayon, pumunta tayo sa undercloud at tingnan kung gumagana ang lahat. Ang address ng host machine ay 192.168.255.200, sa undercloud idinagdag namin ang kinakailangang ipmitool package sa paghahanda para sa deployment:
[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 runningGaya ng nakikita mo, matagumpay naming nailunsad ang control node sa pamamagitan ng vbmc. Ngayon, i-off natin ito at magpatuloy:
[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 ~]#Ang susunod na hakbang ay introspection ng mga node kung saan mai-install ang overcloud. Upang gawin ito, kailangan naming maghanda ng isang json file na may paglalarawan ng aming mga node. Pakitandaan na, hindi tulad ng pag-install sa mga hubad na server, ipinapahiwatig ng file ang port kung saan tumatakbo ang vbmc para sa bawat makina.
[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:27Tandaan: ang control node ay may dalawang interface, ngunit sa kasong ito ay hindi ito mahalaga, sa pag-install na ito ay sapat na ang isa para sa amin.
Ngayon inihahanda namin ang json file. Kailangan nating ipahiwatig ang poppy address ng port kung saan isasagawa ang provisioning, ang mga parameter ng mga node, bigyan sila ng mga pangalan at ipahiwatig kung paano makarating sa 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"
}
]
}Ngayon ay kailangan nating maghanda ng mga larawan para sa ironic. Upang gawin ito, i-download ang mga ito sa pamamagitan ng wget at i-install:
(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 ~]$Pag-upload ng mga larawan sa 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 ~]$Sinusuri na ang lahat ng mga imahe ay na-load
(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 ~]$Isa pang bagay - kailangan mong magdagdag ng DNS server:
(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 ~]$Ngayon ay maaari nating ibigay ang utos para sa pagsisiyasat ng sarili:
(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 ~]$Tulad ng nakikita mo mula sa output, ang lahat ay nakumpleto nang walang mga error. Suriin natin na ang lahat ng node ay nasa available na estado:
(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 ~]$ Kung ang mga node ay nasa ibang estado, kadalasang mapapamahalaan, may nangyaring mali at kailangan mong tingnan ang log at alamin kung bakit ito nangyari. Tandaan na sa sitwasyong ito ay gumagamit kami ng virtualization at maaaring may mga bug na nauugnay sa paggamit ng mga virtual machine o vbmc.
Susunod, kailangan nating ipahiwatig kung aling node ang gaganap kung aling function - iyon ay, ipahiwatig ang profile kung saan i-deploy ang node:
(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 ~]$Tukuyin ang profile para sa bawat node:
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-d9afb69d1167Suriin natin kung ginawa namin nang tama ang lahat:
(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 ~]$Kung tama ang lahat, binibigyan namin ang command na mag-deploy ng overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuSa isang tunay na pag-install, ang mga customized na template ay natural na gagamitin, sa aming kaso ito ay lubos na magpapalubha sa proseso, dahil ang bawat pag-edit sa template ay kailangang ipaliwanag. Tulad ng naisulat kanina, kahit isang simpleng pag-install ay sapat na para makita natin kung paano ito gumagana.
Tandaan: ang --libvirt-type qemu variable ay kinakailangan sa kasong ito, dahil gagamitin namin ang nested virtualization. Kung hindi, hindi ka makakapagpatakbo ng mga virtual machine.
Ngayon ay mayroon kang halos isang oras, o marahil higit pa (depende sa mga kakayahan ng hardware) at maaari ka lamang umasa na pagkatapos ng oras na ito makikita mo ang sumusunod na mensahe:
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 ~]$Ngayon ay mayroon kang halos ganap na bersyon ng openstack, kung saan maaari kang mag-aral, mag-eksperimento, atbp.
Suriin natin kung gumagana nang maayos ang lahat. Sa home directory stack ng user mayroong dalawang file - isang stackrc (para sa pamamahala ng undercloud) at ang pangalawang overcloudrc (para sa pamamahala ng overcloud). Dapat na tukuyin ang mga file na ito bilang pinagmulan, dahil naglalaman ang mga ito ng impormasyong kinakailangan para sa pagpapatunay.
(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 ~]$Ang aking pag-install ay nangangailangan pa rin ng isang maliit na pagpindot - pagdaragdag ng isang ruta sa controller, dahil ang makina kung saan ako nagtatrabaho ay nasa ibang network. Upang gawin ito, pumunta sa control-1 sa ilalim ng heat-admin account at irehistro ang ruta
(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.254Well, ngayon ay maaari kang pumunta sa abot-tanaw. Lahat ng impormasyon - mga address, login at password - ay nasa file /home/stack/overcloudrc. Ang huling diagram ay ganito ang hitsura:
Sa pamamagitan ng paraan, sa aming pag-install, ang mga address ng machine ay inisyu sa pamamagitan ng DHCP at, tulad ng nakikita mo, ang mga ito ay inisyu "nang random". Maaari mong mahigpit na tukuyin sa template kung aling address ang dapat ilakip sa aling makina sa panahon ng pag-deploy, kung kailangan mo ito.
Paano dumadaloy ang trapiko sa pagitan ng mga virtual machine?
Sa artikulong ito titingnan natin ang tatlong opsyon para sa pagpasa ng trapiko
- Dalawang makina sa isang hypervisor sa isang L2 network
- Dalawang makina sa magkaibang hypervisors sa parehong L2 network
- Dalawang makina sa magkaibang network (cross-network rooting)
Ang mga kaso na may access sa labas ng mundo sa pamamagitan ng panlabas na network, gamit ang mga lumulutang na address, pati na rin ang distributed na pagruruta, isasaalang-alang namin sa susunod, sa ngayon ay tututuon kami sa panloob na trapiko.
Upang suriin, pagsama-samahin natin ang sumusunod na diagram:
Gumawa kami ng 4 na virtual machine - 3 sa isang L2 network - net-1, at 1 pa sa net-2 network
(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 ~]$ Tingnan natin kung saan matatagpuan ang mga hypervisors ng mga nilikhang makina:
(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 ~]$
Ang mga machine vm-1 at vm-3 ay matatagpuan sa compute-0, ang mga machine vm-2 at vm-4 ay matatagpuan sa node compute-1.
Bilang karagdagan, ang isang virtual na router ay nilikha upang paganahin ang pagruruta sa pagitan ng mga tinukoy na network:
(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 ~]$ Ang router ay may dalawang virtual port, na nagsisilbing gateway para sa mga network:
(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 ~]$ Ngunit bago natin tingnan kung paano dumadaloy ang trapiko, tingnan natin kung ano ang kasalukuyang mayroon tayo sa control node (na isa ring network node) at sa compute node. Magsimula tayo sa compute node.
[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 ~]$Sa ngayon, ang node ay may tatlong ovs na tulay - br-int, br-tun, br-ex. Sa pagitan ng mga ito, tulad ng nakikita natin, mayroong isang hanay ng mga interface. Para sa kadalian ng pag-unawa, i-plot natin ang lahat ng mga interface na ito sa diagram at tingnan kung ano ang mangyayari.
Kung titingnan ang mga address kung saan itinataas ang mga VxLAN tunnels, makikita na ang isang tunnel ay nakataas para ma-compute-1 (192.168.255.26), ang pangalawang tunnel ay tumitingin sa control-1 (192.168.255.15). Ngunit ang pinaka-kagiliw-giliw na bagay ay ang br-ex ay walang mga pisikal na interface, at kung titingnan mo kung anong mga daloy ang na-configure, makikita mo na ang tulay na ito ay maaari lamang mag-drop ng trapiko sa sandaling ito.
[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 ~]$ Tulad ng nakikita mo mula sa output, ang address ay direktang naka-screw sa pisikal na port, at hindi sa virtual na interface ng tulay.
[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 ~]$
Ayon sa unang panuntunan, lahat ng nagmula sa phy-br-ex port ay dapat itapon.
Sa totoo lang, sa kasalukuyan ay wala nang ibang lugar para makapasok ang trapiko sa tulay na ito maliban sa interface na ito (ang interface na may br-int), at sa paghusga sa mga patak, ang trapiko ng BUM ay lumipad na sa tulay.
Iyon ay, ang trapiko ay maaaring umalis sa node na ito lamang sa pamamagitan ng VxLAN tunnel at wala nang iba pa. Gayunpaman, kung bubuksan mo ang DVR, magbabago ang sitwasyon, ngunit haharapin namin iyon sa ibang pagkakataon. Kapag gumagamit ng network isolation, halimbawa gamit ang mga vlan, hindi ka magkakaroon ng isang L3 interface sa vlan 0, ngunit maraming mga interface. Gayunpaman, ang trapiko ng VxLAN ay iiwan ang node sa parehong paraan, ngunit naka-encapsulated din sa ilang uri ng nakalaang vlan.
Inayos namin ang compute node, lumipat tayo sa control node.
[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 ~]$Sa katunayan, maaari nating sabihin na ang lahat ay pareho, ngunit ang IP address ay wala na sa pisikal na interface ngunit sa virtual na tulay. Ginagawa ito dahil ang port na ito ay ang daungan kung saan lalabas ang trapiko sa labas ng mundo.
[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 ~]$ Ang port na ito ay nakatali sa br-ex bridge at dahil walang mga vlan tag dito, ang port na ito ay isang trunk port kung saan lahat ng vlan ay pinapayagan, ngayon ang trapiko ay lumalabas nang walang tag, gaya ng ipinahiwatig ng vlan-id 0 sa output sa itaas.
Ang lahat ng iba pa sa ngayon ay katulad ng compute node - ang parehong mga tulay, ang parehong mga tunnel na papunta sa dalawang compute node.
Hindi namin isasaalang-alang ang mga node ng imbakan sa artikulong ito, ngunit para sa pag-unawa ay kinakailangang sabihin na ang bahagi ng network ng mga node na ito ay karaniwan hanggang sa punto ng kahihiyan. Sa aming kaso, mayroon lamang isang pisikal na port (eth0) na may isang IP address na nakatalaga dito at iyon lang. Walang mga VxLAN tunnels, tunnel bridges, atbp. - walang ovs sa lahat, dahil walang punto dito. Kapag gumagamit ng network isolation, ang node na ito ay magkakaroon ng dalawang interface (pisikal na port, bodny, o dalawang vlan lang - hindi mahalaga - depende ito sa gusto mo) - isa para sa pamamahala, ang pangalawa para sa trapiko (pagsusulat sa VM disk , pagbabasa mula sa disk, atbp.)
Nalaman namin kung ano ang mayroon kami sa mga node sa kawalan ng anumang mga serbisyo. Ngayon, maglunsad tayo ng 4 na virtual machine at tingnan kung paano nagbabago ang scheme na inilarawan sa itaas - dapat ay mayroon tayong mga port, virtual router, atbp.
Sa ngayon, ganito ang hitsura ng aming network:
Mayroon kaming dalawang virtual machine sa bawat computer node. Gamit ang compute-0 bilang isang halimbawa, tingnan natin kung paano kasama ang lahat.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Ang makina ay mayroon lamang isang virtual na interface - 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 ~]$
Ang interface na ito ay makikita sa tulay ng 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 ~]$ Tulad ng nakikita mo mula sa output, mayroon lamang dalawang interface sa tulay - tap95d96a75-a0 at qvb95d96a75-a0.
Narito ito ay nagkakahalaga ng pag-isipan nang kaunti sa mga uri ng mga virtual network device sa OpenStack:
vtap - virtual interface na naka-attach sa isang instance (VM)
qbr - tulay ng Linux
qvb at qvo - vEth pares na konektado sa Linux bridge at Open vSwitch bridge
br-int, br-tun, br-vlan β Buksan ang vSwitch bridges
patch-, int-br-, phy-br- - Buksan ang vSwitch patch interface na kumukonekta sa mga tulay
qg, qr, ha, fg, sg - Buksan ang vSwitch port na ginagamit ng mga virtual na device para kumonekta sa OVS
Tulad ng naiintindihan mo, kung mayroon kaming isang qvb95d96a75-a0 port sa tulay, na isang pares ng vEth, kung gayon sa isang lugar ay mayroong katapat nito, na dapat na lohikal na tinatawag na qvo95d96a75-a0. Tingnan natin kung anong mga port ang nasa 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 ~]$ Tulad ng nakikita natin, ang port ay nasa br-int. Ang Br-int ay gumaganap bilang isang switch na nagtatapos sa mga virtual machine port. Bilang karagdagan sa qvo95d96a75-a0, ang port qvo5bd37136-47 ay makikita sa output. Ito ang port sa pangalawang virtual machine. Bilang resulta, ganito na ngayon ang aming diagram:
Isang tanong na dapat agad na interesado sa matulungin na mambabasa - ano ang tulay ng linux sa pagitan ng virtual machine port at ng OVS port? Ang katotohanan ay upang maprotektahan ang makina, ginagamit ang mga grupo ng seguridad, na hindi hihigit sa mga iptables. Ang OVS ay hindi gumagana sa mga iptable, kaya ang "saklay" na ito ay naimbento. Gayunpaman, ito ay nagiging lipas na - ito ay pinapalitan ng conntrack sa mga bagong release.
Iyon ay, sa huli ang scheme ay ganito ang hitsura:
Dalawang makina sa isang hypervisor sa isang L2 network
Dahil ang dalawang VM na ito ay matatagpuan sa parehong L2 network at sa parehong hypervisor, ang trapiko sa pagitan ng mga ito ay lohikal na dadaloy nang lokal sa pamamagitan ng br-int, dahil ang parehong mga makina ay nasa parehong VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Dalawang makina sa magkaibang hypervisors sa parehong L2 network
Ngayon tingnan natin kung paano mapupunta ang trapiko sa pagitan ng dalawang makina sa parehong L2 network, ngunit matatagpuan sa magkaibang hypervisors. To be honest, walang masyadong magbabago, traffic lang sa pagitan ng hypervisors ang dadaan sa vxlan tunnel. Tingnan natin ang isang halimbawa.
Mga address ng mga virtual machine kung saan kami magbabantay ng trapiko:
[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 ~]$ Tinitingnan namin ang talahanayan ng pagpapasa sa br-int sa 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 ~]Dapat pumunta ang trapiko sa port 2 - tingnan natin kung anong uri ito ng port:
[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 ~]$Ito ay patch-tun - iyon ay, ang interface sa br-tun. Tingnan natin kung ano ang mangyayari sa package sa 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 ~]$ Ang packet ay nakabalot sa VxLAN at ipinadala sa port 2. Tingnan natin kung saan humahantong ang port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Ito ay isang vxlan tunnel sa 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 ~]$Pumunta tayo sa compute-1 at tingnan kung ano ang susunod na mangyayari sa package:
[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 ~]$ Ang Mac ay nasa br-int forwarding table sa compute-1, at tulad ng makikita mula sa output sa itaas, ito ay makikita sa pamamagitan ng port 2, na siyang port patungo sa 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:46Kaya, pagkatapos ay nakita natin na sa br-int sa compute-1 mayroong patutunguhan na poppy:
[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 ~]$ Iyon ay, ang natanggap na packet ay lilipad sa port 3, sa likod kung saan mayroon nang virtual machine instance-00000003.
Ang kagandahan ng pag-deploy ng Openstack para sa pag-aaral sa virtual na imprastraktura ay madali nating makuha ang trapiko sa pagitan ng mga hypervisor at makita kung ano ang nangyayari dito. Ito ang gagawin natin ngayon, patakbuhin ang tcpdump sa vnet port patungo sa 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*******************Ang unang linya ay nagpapakita na ang Patek mula sa address na 10.0.1.85 ay papunta sa address na 10.0.1.88 (ICMP traffic), at ito ay nakabalot sa isang VxLAN packet na may vni 22 at ang packet ay napupunta mula sa host 192.168.255.19 (compute-0) hanggang sa host 192.168.255.26 .1 ( compute-XNUMX). Maaari naming suriin na ang VNI ay tumutugma sa tinukoy sa ovs.
Bumalik tayo sa linyang ito actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. Ang 0x16 ay vni sa hexadecimal number system. I-convert natin ang numerong ito sa ika-16 system:
16 = 6*16^0+1*16^1 = 6+16 = 22Iyon ay, ang vni ay tumutugma sa katotohanan.
Ang pangalawang linya ay nagpapakita ng pabalik na trapiko, mabuti, walang saysay na ipaliwanag ito, ang lahat ay malinaw doon.
Dalawang machine sa magkaibang network (inter-network routing)
Ang huling kaso para sa ngayon ay ang pagruruta sa pagitan ng mga network sa loob ng isang proyekto gamit ang isang virtual na router. Isinasaalang-alang namin ang isang kaso na walang DVR (titingnan namin ito sa isa pang artikulo), kaya ang pagruruta ay nangyayari sa network node. Sa aming kaso, ang network node ay hindi inilalagay sa isang hiwalay na entity at matatagpuan sa control node.
Una, tingnan natin na gumagana ang pagruruta:
$ 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 msDahil sa kasong ito ang packet ay dapat pumunta sa gateway at iruruta doon, kailangan nating malaman ang poppy address ng gateway, kung saan tinitingnan natin ang talahanayan ng ARP sa halimbawa:
$ 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 eth0Ngayon tingnan natin kung saan dapat ipadala ang trapikong may patutunguhan (10.0.1.254) fa:16:3e:c4:64:70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Tingnan natin kung saan humahantong ang port 2:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Ang lahat ay lohikal, ang trapiko ay papunta sa br-tun. Tingnan natin kung saang vxlan tunnel ito ibalot:
[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 ~]$ Ang ikatlong port ay isang vxlan tunnel:
[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 ~]$ Na tumitingin sa control node:
[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 ~]$ Naabot na ng trapiko ang control node, kaya kailangan nating puntahan ito at tingnan kung paano mangyayari ang pagruruta.
Tulad ng naaalala mo, ang control node sa loob ay eksaktong kapareho ng compute node - ang parehong tatlong tulay, tanging ang br-ex ay may pisikal na port kung saan ang node ay maaaring magpadala ng trapiko sa labas. Binago ng paglikha ng mga pagkakataon ang configuration sa mga compute node - linux bridge, iptables at mga interface ay idinagdag sa mga node. Ang paglikha ng mga network at isang virtual na router ay nag-iwan din ng marka sa pagsasaayos ng control node.
Kaya, malinaw na ang gateway MAC address ay dapat nasa br-int forwarding table sa control node. Suriin natin kung naroon ito at kung saan ito nakatingin:
[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 ~]$ Ang Mac ay makikita mula sa port qr-0c52b15f-8f. Kung babalik tayo sa listahan ng mga virtual port sa Openstack, ang ganitong uri ng port ay ginagamit upang ikonekta ang iba't ibang virtual device sa OVS. Upang maging mas tumpak, ang qr ay isang port sa virtual na router, na kinakatawan bilang isang namespace.
Tingnan natin kung anong mga namespace ang nasa server:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Hanggang tatlong kopya. Ngunit sa paghusga sa mga pangalan, maaari mong hulaan ang layunin ng bawat isa sa kanila. Babalik kami sa mga instance na may ID 0 at 1 mamaya, ngayon kami ay interesado sa namespace 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 ~]$ Ang namespace na ito ay naglalaman ng dalawang panloob na ginawa namin kanina. Ang parehong mga virtual port ay naidagdag sa br-int. Suriin natin ang mac address ng port qr-0c52b15f-8f, dahil ang trapiko, batay sa patutunguhang mac address, ay napunta sa interface na ito.
[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 ~]$ Iyon ay, sa kasong ito, gumagana ang lahat ayon sa mga batas ng karaniwang pagruruta. Dahil ang trapiko ay nakalaan para sa host 10.0.2.8, dapat itong lumabas sa pangalawang interface qr-92fa49b5-54 at dumaan sa vxlan tunnel patungo sa compute node:
[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 ~]$ Ang lahat ay lohikal, walang sorpresa. Tingnan natin kung saan makikita ang poppy address ng host 10.0.2.8 sa 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 ~]$ Gaya ng inaasahan, ang trapiko ay papunta sa br-tun, tingnan natin kung aling lagusan ang susunod na pupuntahan ng trapiko:
[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 ~]$ Ang trapiko ay pumapasok sa tunnel upang mag-compute-1. Well, sa compute-1 lahat ay simple - mula sa br-tun ang package ay mapupunta sa br-int at mula doon sa virtual machine interface:
[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 ~]$ Suriin natin na ito nga ang tamang interface:
[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 ~]$
Sa totoo lang, napunta kami sa buong pakete. Sa tingin ko napansin mo na ang trapiko ay dumaan sa iba't ibang vxlan tunnel at lumabas na may iba't ibang VNI. Tingnan natin kung anong uri ng VNI ang mga ito, pagkatapos nito ay magkokolekta tayo ng dump sa control port ng node at siguraduhin na ang trapiko ay dumadaloy nang eksakto tulad ng inilarawan sa itaas.
Kaya, ang tunnel na magko-compute-0 ay may mga sumusunod na aksyon=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. I-convert natin ang 0x16 sa sistema ng decimal na numero:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Ang tunnel na iko-compute-1 ay may sumusunod na VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. I-convert natin ang 0x63 sa sistema ng decimal na numero:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Well, ngayon tingnan natin ang dump:
[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*******************Ang unang packet ay isang vxlan packet mula sa host 192.168.255.19 (compute-0) hanggang sa host 192.168.255.15 (control-1) na may vni 22, kung saan ang isang ICMP packet ay naka-package mula sa host 10.0.1.85 hanggang host 10.0.2.8. Tulad ng aming kinakalkula sa itaas, ang vni ay tumutugma sa aming nakita sa output.
Ang pangalawang packet ay isang vxlan packet mula sa host 192.168.255.15 (control-1) hanggang sa host 192.168.255.26 (compute-1) na may vni 99, kung saan ang isang ICMP packet ay naka-package mula sa host 10.0.1.85 hanggang host 10.0.2.8. Tulad ng aming kinakalkula sa itaas, ang vni ay tumutugma sa aming nakita sa output.
Ang susunod na dalawang packet ay return traffic mula 10.0.2.8 hindi 10.0.1.85.
Iyon ay, sa huli nakuha namin ang sumusunod na control node scheme:
Parang yun lang? Nakalimutan namin ang tungkol sa dalawang namespace:
[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 ~]$ Habang pinag-uusapan natin ang tungkol sa arkitektura ng cloud platform, makabubuti kung awtomatikong makakatanggap ang mga machine ng mga address mula sa isang DHCP server. Ito ay dalawang DHCP server para sa aming dalawang network 10.0.1.0/24 at 10.0.2.0/24.
Suriin natin kung totoo ito. Mayroon lamang isang address sa namespace na ito - 10.0.1.1 - ang address ng DHCP server mismo, at kasama rin ito sa 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 0Tingnan natin kung ang mga prosesong naglalaman ng qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 sa kanilang pangalan sa control node:
[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 ~]$ Mayroong ganoong proseso at batay sa impormasyong ipinakita sa output sa itaas, maaari nating, halimbawa, tingnan kung ano ang kasalukuyang mayroon tayo para sa upa:
[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 ~]$Bilang resulta, nakukuha namin ang sumusunod na hanay ng mga serbisyo sa control node:
Buweno, tandaan - ito ay 4 na makina lamang, 2 panloob na network at isang virtual na router... Wala kaming mga panlabas na network dito ngayon, isang bungkos ng iba't ibang mga proyekto, bawat isa ay may sariling mga network (nagpapatong), at mayroon kaming naka-off ang isang ibinahagi na router, at sa dulo Pagkatapos ng lahat, mayroon lamang isang control node sa test bench (para sa fault tolerance dapat mayroong isang korum ng tatlong node). Lohikal na sa commerce ang lahat ay "medyo" mas kumplikado, ngunit sa simpleng halimbawang ito naiintindihan namin kung paano ito dapat gumana - kung mayroon kang 3 o 300 namespaces ay siyempre mahalaga, ngunit mula sa punto ng view ng pagpapatakbo ng buong istraktura, walang masyadong magbabago... bagama't hindi mo isaksak ang ilang vendor na SDN. Ngunit iyon ay isang ganap na naiibang kuwento.
Sana naging kawili-wili ito. Kung mayroon kang anumang mga komento/dagdag, o kung saan ako tahasang nagsinungaling (tao ako at ang aking opinyon ay palaging magiging subjective) - isulat kung ano ang kailangang itama/idagdag - itatama/dadagdagan namin ang lahat.
Sa konklusyon, gusto kong magsabi ng ilang salita tungkol sa paghahambing ng Openstack (parehong banilya at vendor) sa cloud solution mula sa VMWare - madalas akong tinanong sa tanong na ito sa nakalipas na ilang taon at, sa totoo lang, ako ay napagod na, pero ganun pa din. Sa palagay ko, napakahirap ihambing ang dalawang solusyon na ito, ngunit tiyak na masasabi natin na may mga disadvantages sa parehong mga solusyon at kapag pumipili ng isang solusyon kailangan mong timbangin ang mga kalamangan at kahinaan.
Kung ang OpenStack ay isang solusyon na hinimok ng komunidad, kung gayon ang VMWare ay may karapatan na gawin lamang kung ano ang gusto nito (basahin - kung ano ang kumikita para dito) at ito ay lohikal - dahil ito ay isang komersyal na kumpanya na ginagamit upang kumita ng pera mula sa mga kliyente nito. Ngunit mayroong isang malaki at mataba PERO - maaari kang bumaba sa OpenStack, halimbawa mula sa Nokia, at sa maliit na gastos ay lumipat sa isang solusyon mula sa, halimbawa, Juniper (Contrail Cloud), ngunit malamang na hindi ka makakaalis sa VMWare . Para sa akin, ganito ang hitsura ng dalawang solusyong ito - Ang Openstack (vendor) ay isang simpleng kulungan kung saan ka inilalagay, ngunit mayroon kang susi at maaari kang umalis anumang oras. Ang VMWare ay isang gintong hawla, ang may-ari ay may susi sa hawla at ito ay magastos sa iyo ng malaki.
Hindi ko pino-promote ang unang produkto o ang pangalawa - pipiliin mo kung ano ang kailangan mo. Ngunit kung mayroon akong ganoong pagpipilian, pipiliin ko ang parehong mga solusyon - VMWare para sa IT cloud (mababang pag-load, madaling pamamahala), OpenStack mula sa ilang vendor (Nokia at Juniper ay nagbibigay ng napakahusay na solusyon sa turnkey) - para sa Telecom cloud. Hindi ko gagamitin ang Openstack para sa purong IT - ito ay tulad ng pagbaril sa mga maya gamit ang isang kanyon, ngunit wala akong nakikitang anumang kontraindikasyon sa paggamit nito maliban sa kalabisan. Gayunpaman, ang paggamit ng VMWare sa telecom ay parang paghakot ng durog na bato sa isang Ford Raptor - maganda ito mula sa labas, ngunit ang driver ay kailangang gumawa ng 10 biyahe sa halip na isa.
Sa palagay ko, ang pinakamalaking kawalan ng VMWare ay ang kumpletong pagsasara nito - ang kumpanya ay hindi magbibigay sa iyo ng anumang impormasyon tungkol sa kung paano ito gumagana, halimbawa, vSAN o kung ano ang nasa hypervisor kernel - ito ay hindi kumikita para dito - iyon ay, ikaw ay hindi kailanman maging isang dalubhasa sa VMWare - nang walang suporta sa vendor, ikaw ay tiyak na mapapahamak (madalas na nakakasalubong ko ang mga eksperto sa VMWare na nalilito sa mga walang kuwentang tanong). Para sa akin, bumibili ang VMWare ng kotse na naka-lock ang hood - oo, maaaring mayroon kang mga espesyalista na maaaring magpalit ng timing belt, ngunit ang nagbebenta lamang sa iyo ng solusyon na ito ang maaaring magbukas ng hood. Sa personal, hindi ko gusto ang mga solusyon na hindi ako maaaring magkasya. Sasabihin mo na maaaring hindi mo kailangang pumunta sa ilalim ng talukbong. Oo, posible ito, ngunit titingnan kita kapag kailangan mong mag-assemble ng isang malaking function sa cloud mula sa 20-30 virtual machine, 40-50 network, kalahati nito ay gustong lumabas, at ang pangalawang kalahati ay humihingi ng SR-IOV acceleration, kung hindi, kakailanganin mo ng higit pa ng ilang dosenang mga kotse na ito - kung hindi ay hindi magiging sapat ang pagganap.
Mayroong iba pang mga pananaw, kaya ikaw lamang ang makakapagpasya kung ano ang pipiliin at, higit sa lahat, ikaw ang magiging responsable para sa iyong pinili. Ito ay opinyon ko lamang - isang taong nakakita at nakahawak ng hindi bababa sa 4 na produkto - Nokia, Juniper, Red Hat at VMWare. Ibig sabihin, may maikukumpara ako.
Pinagmulan: www.habr.com