Mae cyfrifiadura cwmwl yn treiddio'n ddyfnach ac yn ddyfnach i'n bywydau ac mae'n debyg nad oes un person nad yw wedi defnyddio unrhyw wasanaethau cwmwl o leiaf unwaith. Fodd bynnag, beth yn union yw cwmwl a sut mae'n gweithio, ychydig o bobl sy'n gwybod, hyd yn oed ar lefel syniad. Mae 5G eisoes yn dod yn realiti ac mae'r seilwaith telathrebu yn dechrau symud o atebion piler i atebion cwmwl, yn union fel y gwnaeth pan symudodd o atebion caledwedd llwyr i “bileri” rhithwir.
Heddiw byddwn yn siarad am fyd mewnol seilwaith cwmwl, yn benodol byddwn yn edrych ar hanfodion rhan y rhwydwaith.
Beth yw cwmwl? Yr un rhithwiroli - golwg proffil?
Mwy na chwestiwn rhesymegol. Na - nid rhithwiroli yw hyn, er na ellid ei wneud hebddo. Edrychwn ar ddau ddiffiniad:
Cyfrifiadura cwmwl (y cyfeirir ato o hyn ymlaen fel Cloud) yn fodel ar gyfer darparu mynediad hawdd ei ddefnyddio at adnoddau cyfrifiadurol gwasgaredig y mae'n rhaid eu defnyddio a'u lansio ar alw gyda'r hwyrni lleiaf posibl a'r gost leiaf posibl i'r darparwr gwasanaeth.
Rhithwiroli - dyma'r gallu i rannu un endid ffisegol (er enghraifft, gweinydd) yn sawl un rhithwir, a thrwy hynny gynyddu'r defnydd o adnoddau (er enghraifft, roedd gennych 3 gweinydd wedi'u llwytho ar 25-30 y cant, ar ôl rhithwiroli byddwch yn cael 1 gweinydd wedi'i lwytho ar 80-90 y cant). Yn naturiol, mae rhithwiroli yn bwyta rhai o'r adnoddau - mae angen i chi fwydo'r hypervisor, fodd bynnag, fel y dangosodd arfer, mae'r gêm yn werth y gannwyll. Enghraifft ddelfrydol o rhithwiroli yw VMWare, sy'n paratoi peiriannau rhithwir yn berffaith, neu er enghraifft KVM, sy'n well gennyf, ond mater o flas yw hwn.
Rydym yn defnyddio rhithwiroli heb ei sylweddoli, ac mae hyd yn oed llwybryddion haearn eisoes yn defnyddio rhithwiroli - er enghraifft, yn y fersiwn ddiweddaraf o JunOS, mae'r system weithredu wedi'i gosod fel peiriant rhithwir ar ben dosbarthiad Linux amser real (Wind River 9). Ond nid rhithwiroli yw'r cwmwl, ond ni all y cwmwl fodoli heb rithwiroli.
Rhithwiroli yw un o'r blociau adeiladu y mae'r cwmwl wedi'i adeiladu arno.
Ni fydd gwneud cwmwl trwy gasglu sawl hypervisors i un parth L2, ychwanegu cwpl o lyfrau chwarae yaml ar gyfer cofrestru vlans yn awtomatig trwy ryw fath o ansible a jamio rhywbeth fel system offeryniaeth ar y cyfan ar gyfer creu peiriannau rhithwir yn awtomatig yn gweithio. Bydd yn fwy cywir, ond nid y Frankenstein canlyniadol yw'r cwmwl sydd ei angen arnom, er efallai mai dyma'r freuddwyd eithaf i eraill. Ar ben hynny, os cymerwch yr un Openstack, Frankenstein ydyw yn y bôn, ond o wel, gadewch inni beidio â siarad am hynny am y tro.
Ond deallaf o'r diffiniad a gyflwynir uchod nad yw'n gwbl glir beth y gellir ei alw'n gwmwl mewn gwirionedd.
Felly, mae dogfen gan NIST (Sefydliad Cenedlaethol Safonau a Thechnoleg) yn darparu 5 prif nodwedd y dylai seilwaith cwmwl fod â:
Darparu gwasanaeth ar gais. Rhaid i'r defnyddiwr gael mynediad am ddim i'r adnoddau cyfrifiadurol a ddyrennir iddo (fel rhwydweithiau, disgiau rhithwir, cof, creiddiau prosesydd, ac ati), a rhaid darparu'r adnoddau hyn yn awtomatig - hynny yw, heb ymyrraeth gan y darparwr gwasanaeth.
Argaeledd eang o wasanaeth. Rhaid darparu mynediad i adnoddau trwy fecanweithiau safonol i ganiatáu defnyddio cyfrifiaduron personol safonol a chleientiaid tenau a dyfeisiau symudol.
Cyfuno adnoddau mewn pyllau. Rhaid i gronfeydd adnoddau allu darparu adnoddau i gleientiaid lluosog ar yr un pryd, gan sicrhau bod cleientiaid yn ynysig ac yn rhydd o gyd-ddylanwad a chystadleuaeth am adnoddau. Mae rhwydweithiau hefyd wedi'u cynnwys yn y pyllau, sy'n dangos y posibilrwydd o ddefnyddio cyfeiriadau sy'n gorgyffwrdd. Rhaid i gronfeydd allu graddio yn ôl y galw. Mae defnyddio pyllau yn ei gwneud hi'n bosibl darparu'r lefel angenrheidiol o oddefiad diffyg adnoddau a thynnu adnoddau ffisegol a rhithwir - yn syml, mae derbynnydd y gwasanaeth yn cael y set o adnoddau y gofynnodd amdanynt (lle mae'r adnoddau hyn wedi'u lleoli'n ffisegol, ar faint gweinyddwyr a switshis - nid oes ots i'r cleient). Fodd bynnag, rhaid inni ystyried y ffaith bod yn rhaid i’r darparwr sicrhau bod yr adnoddau hyn yn cael eu cadw’n dryloyw.
Addasiad cyflym i wahanol amodau. Rhaid i wasanaethau fod yn hyblyg - darpariaeth gyflym o adnoddau, eu hailddosbarthu, ychwanegu neu leihau adnoddau ar gais y cleient, ac ar ran y cleient dylai fod teimlad bod yr adnoddau cwmwl yn ddiddiwedd. Er hwylustod, er enghraifft, nid ydych chi'n gweld rhybudd bod rhan o'ch gofod disg yn Apple iCloud wedi diflannu oherwydd bod y gyriant caled ar y gweinydd wedi torri i lawr, a bod gyriannau'n torri i lawr. Yn ogystal, ar eich rhan chi, mae posibiliadau'r gwasanaeth hwn bron yn ddiderfyn - mae angen 2 TB arnoch chi - dim problem, fe wnaethoch chi ei dalu a'i dderbyn. Gellir rhoi enghraifft debyg gyda Google.Drive neu Yandex.Disk.
Posibilrwydd o fesur y gwasanaeth a ddarperir. Rhaid i systemau cwmwl reoli a gwneud y gorau o'r adnoddau a ddefnyddir yn awtomatig, a rhaid i'r mecanweithiau hyn fod yn dryloyw i'r defnyddiwr a darparwr y gwasanaeth. Hynny yw, gallwch chi bob amser wirio faint o adnoddau rydych chi a'ch cleientiaid yn eu defnyddio.
Mae'n werth ystyried y ffaith bod y gofynion hyn yn bennaf yn ofynion ar gyfer cwmwl cyhoeddus, felly ar gyfer cwmwl preifat (hynny yw, cwmwl a lansiwyd ar gyfer anghenion mewnol y cwmni), gellir addasu'r gofynion hyn ychydig. Fodd bynnag, mae'n rhaid eu gwneud o hyd, fel arall ni chawn holl fanteision cyfrifiadura cwmwl.
Pam mae angen cwmwl?
Fodd bynnag, unrhyw dechnoleg newydd neu bresennol, unrhyw brotocol newydd yn cael ei greu ar gyfer rhywbeth (wel, ac eithrio ar gyfer RIP-ng, wrth gwrs). Nid oes angen protocol ar unrhyw un er mwyn protocol (wel, heblaw am RIP-ng, wrth gwrs). Mae'n rhesymegol bod y Cwmwl yn cael ei greu i ddarparu rhyw fath o wasanaeth i'r defnyddiwr / cleient. Rydym i gyd yn gyfarwydd ag o leiaf cwpl o wasanaethau cwmwl, er enghraifft Dropbox neu Google.Docs, a chredaf fod y rhan fwyaf o bobl yn eu defnyddio'n llwyddiannus - er enghraifft, ysgrifennwyd yr erthygl hon gan ddefnyddio gwasanaeth cwmwl Google.Docs. Ond dim ond rhan o alluoedd y cwmwl yw'r gwasanaethau cwmwl rydyn ni'n eu hadnabod - yn fwy manwl gywir, dim ond gwasanaeth tebyg i SaaS ydyn nhw. Gallwn ddarparu gwasanaeth cwmwl mewn tair ffordd: ar ffurf SaaS, PaaS neu IaaS. Mae pa wasanaeth sydd ei angen arnoch yn dibynnu ar eich dymuniadau a'ch galluoedd.
Edrychwn ar bob un mewn trefn:
Meddalwedd fel Gwasanaeth (SaaS) yn fodel ar gyfer darparu gwasanaeth cyflawn i'r cleient, er enghraifft, gwasanaeth e-bost fel Yandex.Mail neu Gmail. Yn y model darparu gwasanaeth hwn, nid ydych chi, fel cleient, yn gwneud dim mewn gwirionedd heblaw defnyddio’r gwasanaethau – hynny yw, nid oes angen ichi feddwl am sefydlu’r gwasanaeth, ei oddefgarwch o fai neu ddileu swydd. Y prif beth yw peidio â pheryglu'ch cyfrinair; bydd darparwr y gwasanaeth hwn yn gwneud y gweddill i chi. O safbwynt y darparwr gwasanaeth, mae'n gwbl gyfrifol am y gwasanaeth cyfan - o galedwedd gweinyddwr a systemau gweithredu gwesteiwr i osodiadau cronfa ddata a meddalwedd.
Llwyfan fel Gwasanaeth (PaaS) - wrth ddefnyddio'r model hwn, mae'r darparwr gwasanaeth yn darparu darn gwaith i'r cleient ar gyfer y gwasanaeth, er enghraifft, gadewch i ni gymryd gweinydd Gwe. Darparodd darparwr y gwasanaeth weinydd rhithwir i'r cleient (mewn gwirionedd, set o adnoddau, megis RAM / CPU / Storio / Rhwydi, ac ati), a hyd yn oed gosod yr OS a'r feddalwedd angenrheidiol ar y gweinydd hwn, fodd bynnag, ffurfweddiad mae'r holl bethau hyn yn cael eu gwneud gan y cleient ei hun ac ar gyfer perfformiad y gwasanaeth y mae'r cleient yn ei ateb. Mae'r darparwr gwasanaeth, fel yn yr achos blaenorol, yn gyfrifol am berfformiad offer corfforol, hypervisors, y peiriant rhithwir ei hun, ei argaeledd rhwydwaith, ac ati, ond nid yw'r gwasanaeth ei hun bellach yn ei faes cyfrifoldeb.
Seilwaith fel Gwasanaeth (IaaS) - mae'r dull hwn eisoes yn fwy diddorol, mewn gwirionedd, mae'r darparwr gwasanaeth yn darparu seilwaith rhithwir cyflawn i'r cleient - hynny yw, rhai set (cronfa) o adnoddau, megis CPU Cores, RAM, Rhwydweithiau, ac ati. y cleient - yr hyn y mae'r cleient am ei wneud gyda'r adnoddau hyn o fewn y gronfa ddyranedig (cwota) - nid yw'n arbennig o bwysig i'r cyflenwr. P'un a yw'r cleient eisiau creu ei vEPC ei hun neu hyd yn oed greu gweithredwr bach a darparu gwasanaethau cyfathrebu - dim cwestiwn - gwnewch hynny. Mewn sefyllfa o'r fath, mae'r darparwr gwasanaeth yn gyfrifol am ddarparu adnoddau, eu goddefgarwch o ddiffygion ac argaeledd, yn ogystal â'r OS sy'n caniatáu iddynt gronni'r adnoddau hyn a'u gwneud ar gael i'r cleient gyda'r gallu i gynyddu neu leihau adnoddau ar unrhyw adeg ar gais y cleient. Mae'r cleient yn ffurfweddu pob peiriant rhithwir a tinsel arall ei hun trwy'r porth hunanwasanaeth a chonsol, gan gynnwys sefydlu rhwydweithiau (ac eithrio rhwydweithiau allanol).
Beth yw OpenStack?
Ym mhob un o'r tri opsiwn, mae angen OS ar y darparwr gwasanaeth a fydd yn galluogi creu seilwaith cwmwl. Mewn gwirionedd, gyda SaaS, mae mwy nag un adran yn gyfrifol am y pentwr cyfan o dechnolegau - mae yna is-adran sy'n gyfrifol am y seilwaith - hynny yw, mae'n darparu IaaS i adran arall, mae'r is-adran hon yn darparu SaaS i'r cleient. Mae OpenStack yn un o'r systemau gweithredu cwmwl sy'n eich galluogi i gasglu criw o switshis, gweinyddwyr a systemau storio yn un gronfa adnoddau, rhannu'r gronfa gyffredin hon yn is-gronfeydd (tenantiaid) a darparu'r adnoddau hyn i gleientiaid dros y rhwydwaith.
OpenStack yn system weithredu cwmwl sy'n eich galluogi i reoli cronfeydd mawr o adnoddau cyfrifiadurol, storio data ac adnoddau rhwydwaith, wedi'u darparu a'u rheoli trwy API gan ddefnyddio mecanweithiau dilysu safonol.
Mewn geiriau eraill, mae hwn yn set o brosiectau meddalwedd am ddim sydd wedi'u cynllunio i greu gwasanaethau cwmwl (cyhoeddus a phreifat) - hynny yw, set o offer sy'n eich galluogi i gyfuno gweinydd a newid offer yn un gronfa o adnoddau, rheoli yr adnoddau hyn, gan ddarparu'r lefel angenrheidiol o oddefiad o namau .
Ar adeg ysgrifennu'r deunydd hwn, mae strwythur OpenStack yn edrych fel hyn:
Llun wedi ei dynnu o
Mae pob un o'r cydrannau sydd wedi'u cynnwys yn OpenStack yn cyflawni swyddogaeth benodol. Mae'r bensaernïaeth ddosbarthedig hon yn caniatáu ichi gynnwys y set o gydrannau swyddogaethol sydd eu hangen arnoch yn yr ateb. Fodd bynnag, mae rhai cydrannau yn gydrannau gwraidd a bydd eu tynnu yn arwain at anweithredol llwyr neu rannol o'r datrysiad cyfan. Mae'r cydrannau hyn fel arfer yn cael eu dosbarthu fel:
- dangosfwrdd — GUI ar y we ar gyfer rheoli gwasanaethau OpenStack
- Keystone yn wasanaeth hunaniaeth canolog sy'n darparu swyddogaethau dilysu ac awdurdodi ar gyfer gwasanaethau eraill, yn ogystal â rheoli rhinweddau defnyddwyr a'u rolau.
- Neutron - gwasanaeth rhwydwaith sy'n darparu cysylltedd rhwng rhyngwynebau amrywiol wasanaethau OpenStack (gan gynnwys cysylltedd rhwng VMs a'u mynediad i'r byd y tu allan)
- Cinder — yn darparu mynediad i storfa bloc ar gyfer peiriannau rhithwir
- Nova - rheoli cylch bywyd peiriannau rhithwir
- Cipolwg — ystorfa o ddelweddau peiriant rhithwir a chipluniau
- Cyflym — yn darparu mynediad i'r gwrthrych storio
- Ceilometer — gwasanaeth sy'n darparu'r gallu i gasglu telemetreg a mesur yr adnoddau sydd ar gael ac a ddefnyddir
- Gwres — offeryniaeth yn seiliedig ar dempledi ar gyfer creu a darparu adnoddau yn awtomatig
Gellir gweld rhestr gyflawn o'r holl brosiectau a'u pwrpas .
Mae pob cydran OpenStack yn wasanaeth sy'n cyflawni swyddogaeth benodol ac yn darparu API i reoli'r swyddogaeth honno a rhyngweithio â gwasanaethau system gweithredu cwmwl eraill i greu seilwaith unedig. Er enghraifft, mae Nova yn darparu rheolaeth adnoddau cyfrifiadurol ac API ar gyfer mynediad at ffurfweddu'r adnoddau hyn, mae Glance yn darparu rheolaeth delwedd ac API ar gyfer eu rheoli, mae Cinder yn darparu storfa bloc ac API ar gyfer ei reoli, ac ati. Mae'r holl swyddogaethau wedi'u rhyng-gysylltu mewn ffordd agos iawn.
Fodd bynnag, os edrychwch arno, yn y pen draw mae'r holl wasanaethau sy'n rhedeg yn OpenStack yn rhyw fath o beiriant rhithwir (neu gynhwysydd) sy'n gysylltiedig â'r rhwydwaith. Mae'r cwestiwn yn codi - pam mae angen cymaint o elfennau?
Gadewch i ni fynd trwy'r algorithm ar gyfer creu peiriant rhithwir a'i gysylltu â'r rhwydwaith a storio parhaus yn Openstack.
- Pan fyddwch yn creu cais i greu peiriant, boed yn gais drwy Horizon (Dangosfwrdd) neu gais drwy'r CLI, y peth cyntaf sy'n digwydd yw awdurdodi eich cais ar Keystone - allwch chi greu peiriant, a oes ganddo'r hawl i ddefnyddio'r rhwydwaith hwn, a yw eich cwota drafft, ac ati.
- Mae Keystone yn dilysu'ch cais ac yn cynhyrchu tocyn awdurdod yn y neges ymateb, a fydd yn cael ei ddefnyddio ymhellach. Wedi derbyn ymateb gan Keystone, anfonir y cais tuag at Nova (nova api).
- Mae Nova-api yn gwirio dilysrwydd eich cais trwy gysylltu â Keystone gan ddefnyddio'r tocyn awdurdod a gynhyrchwyd yn flaenorol
- Mae Keystone yn cyflawni dilysiad ac yn darparu gwybodaeth am ganiatadau a chyfyngiadau yn seiliedig ar y tocyn awdurdod hwn.
- Mae Nova-api yn creu cofnod ar gyfer y VM newydd yn nova-database ac yn trosglwyddo'r cais i greu'r peiriant i nova-scheduler.
- Mae Nova-scheduler yn dewis y gwesteiwr (nôd cyfrifiadur) y bydd y VM yn cael ei ddefnyddio arno yn seiliedig ar y paramedrau, pwysau a pharthau penodedig. Ysgrifennir cofnod o hyn a'r ID VM i nova-database.
- Nesaf, mae nova-scheduler yn cysylltu â nova-compute gyda chais i ddefnyddio enghraifft. Cysylltiadau Nova-compute nova-conductor i gael gwybodaeth am baramedrau peiriant (mae nova-conductor yn elfen nova sy'n gweithredu fel gweinydd dirprwyol rhwng nova-database a nova-compute, gan gyfyngu ar nifer y ceisiadau i gronfa ddata nova i osgoi problemau gyda chronfa ddata lleihau cysondeb llwyth).
- Mae Nova-conductor yn derbyn y wybodaeth y gofynnwyd amdani o gronfa ddata nova ac yn ei throsglwyddo i nova-compute.
- Nesaf, mae galwadau nova-compute yn cael cipolwg i gael ID y ddelwedd. Mae Glace yn dilysu'r cais yn Keystone ac yn dychwelyd y wybodaeth y gofynnwyd amdani.
- Niwtron cysylltiadau Nova-cyfrifiadur i gael gwybodaeth am baramedrau rhwydwaith. Yn debyg i gipolwg, mae niwtron yn dilysu'r cais yn Keystone, ac ar ôl hynny mae'n creu cofnod yn y gronfa ddata (dynodwr porthladd, ac ati), yn creu cais i greu porthladd, ac yn dychwelyd y wybodaeth y gofynnwyd amdani i nova-compute.
- Mae cysylltiadau Nova-compute yn lludw gyda chais i ddyrannu cyfaint i'r peiriant rhithwir. Yn debyg i gipolwg, mae seidr yn dilysu'r cais yn Keystone, yn creu cais creu cyfaint, ac yn dychwelyd y wybodaeth y gofynnwyd amdani.
- Mae cysylltiadau Nova-compute libvirt gyda chais i leoli peiriant rhithwir gyda'r paramedrau penodedig.
Mewn gwirionedd, mae gweithrediad ymddangosiadol syml o greu peiriant rhithwir syml yn troi'n drobwll o'r fath o alwadau API rhwng elfennau o'r llwyfan cwmwl. Ar ben hynny, fel y gwelwch, mae hyd yn oed y gwasanaethau a ddynodwyd yn flaenorol hefyd yn cynnwys cydrannau llai y mae rhyngweithio'n digwydd rhyngddynt. Dim ond rhan fach o'r hyn y mae platfform y cwmwl yn caniatáu ichi ei wneud yw creu peiriant - mae yna wasanaeth sy'n gyfrifol am gydbwyso traffig, gwasanaeth sy'n gyfrifol am storio blociau, gwasanaeth sy'n gyfrifol am DNS, gwasanaeth sy'n gyfrifol am ddarparu gweinyddwyr metel noeth, ac ati. ■ Mae'r cwmwl yn caniatáu i chi drin eich peiriannau rhithwir fel buches o ddefaid (yn hytrach na rhithwiroli). Os bydd rhywbeth yn digwydd i'ch peiriant mewn amgylchedd rhithwir - rydych chi'n ei adfer o gopïau wrth gefn, ac ati, ond mae cymwysiadau cwmwl yn cael eu hadeiladu yn y fath fodd fel nad yw'r peiriant rhithwir yn chwarae rhan mor bwysig - bu farw'r peiriant rhithwir - dim problem - mae un newydd newydd ei greu mae'r cerbyd yn seiliedig ar y templed ac, fel y dywedant, ni sylwodd y garfan ar golli'r ymladdwr. Yn naturiol, mae hyn yn darparu ar gyfer presenoldeb mecanweithiau offeryniaeth - gan ddefnyddio templedi Gwres, gallwch chi ddefnyddio swyddogaeth gymhleth yn hawdd sy'n cynnwys dwsinau o rwydweithiau a pheiriannau rhithwir.
Mae bob amser yn werth cofio nad oes unrhyw seilwaith cwmwl heb rwydwaith - mae pob elfen mewn un ffordd neu'r llall yn rhyngweithio ag elfennau eraill trwy'r rhwydwaith. Yn ogystal, mae gan y cwmwl rwydwaith hollol ansefydlog. Yn naturiol, mae'r rhwydwaith isgarped hyd yn oed yn fwy sefydlog - nid yw nodau a switshis newydd yn cael eu hychwanegu bob dydd, ond mae'n anochel y gall y gydran troshaen newid yn gyson - bydd rhwydweithiau newydd yn cael eu hychwanegu neu eu dileu, bydd peiriannau rhithwir newydd yn ymddangos a bydd hen rai yn ymddangos. marw. Ac fel y cofiwch o'r diffiniad o'r cwmwl a roddwyd ar ddechrau'r erthygl, dylid dyrannu adnoddau i'r defnyddiwr yn awtomatig a chyda'r ymyrraeth leiaf (neu well eto, heb) gan y darparwr gwasanaeth. Hynny yw, nid cwmwl yw'r math o ddarpariaeth adnoddau rhwydwaith sydd bellach yn bodoli ar ffurf pen blaen ar ffurf eich cyfrif personol y gellir ei gyrchu trwy http/https a'r peiriannydd rhwydwaith ar ddyletswydd Vasily fel backend, hyd yn oed os oes gan Vasily wyth llaw.
Mae Neutron, fel gwasanaeth rhwydwaith, yn darparu API ar gyfer rheoli cyfran y rhwydwaith o seilwaith y cwmwl. Mae'r gwasanaeth yn pweru ac yn rheoli'r gyfran rwydweithio o Openstack trwy ddarparu haen echdynnu o'r enw Network-as-a-Service (NaaS). Hynny yw, mae'r rhwydwaith yr un uned fesuradwy rithwir ag, er enghraifft, creiddiau CPU rhithwir neu faint o RAM.
Ond cyn symud ymlaen i bensaernïaeth rhan rhwydwaith OpenStack, gadewch i ni ystyried sut mae'r rhwydwaith hwn yn gweithio yn OpenStack a pham mae'r rhwydwaith yn rhan bwysig ac annatod o'r cwmwl.
Felly mae gennym ddau VM cleient COCH a dau VM cleient GWYRDD. Gadewch i ni dybio bod y peiriannau hyn wedi'u lleoli ar ddau orweledydd yn y modd hwn:
Ar hyn o bryd, dim ond rhithwiroli 4 gweinydd yw hyn a dim byd arall, ers hyd yn hyn y cyfan yr ydym wedi'i wneud yw rhithwiroli 4 gweinydd, gan eu gosod ar ddau weinydd corfforol. A hyd yn hyn nid ydynt hyd yn oed yn gysylltiedig â'r rhwydwaith.
I wneud cwmwl, mae angen i ni ychwanegu sawl cydran. Yn gyntaf, rydym yn rhithwiroli rhan y rhwydwaith - mae angen i ni gysylltu'r 4 peiriant hyn mewn parau, ac mae'r cleientiaid eisiau cysylltiad L2. Gallwch ddefnyddio switsh a ffurfweddu boncyff yn ei gyfeiriad a datrys popeth gan ddefnyddio pont linux neu, ar gyfer defnyddwyr mwy datblygedig, openvswitch (byddwn yn dychwelyd at hyn yn nes ymlaen). Ond gall fod llawer o rwydweithiau, ac nid gwthio L2 trwy switsh yn gyson yw'r syniad gorau - mae yna wahanol adrannau, desg wasanaeth, misoedd o aros i gais gael ei gwblhau, wythnosau o ddatrys problemau - yn y byd modern hwn nid yw'r ymagwedd yn gweithio mwyach. A gorau po gyntaf y bydd cwmni'n deall hyn, yr hawsaf yw iddo symud ymlaen. Felly, rhwng y hypervisors byddwn yn dewis rhwydwaith L3 y bydd ein peiriannau rhithwir yn cyfathrebu drwyddo, ac ar ben y rhwydwaith L3 hwn byddwn yn adeiladu rhwydweithiau troshaen L2 rhithwir lle bydd traffig ein peiriannau rhithwir yn rhedeg. Gallwch ddefnyddio GRE, Geneve neu VxLAN fel amgáu. Gadewch i ni ganolbwyntio ar yr olaf am y tro, er nad yw'n arbennig o bwysig.
Mae angen i ni leoli VTEP yn rhywle (gobeithiaf fod pawb yn gyfarwydd â therminoleg VxLAN). Gan fod gennym rwydwaith L3 yn dod yn syth o'r gweinyddwyr, nid oes dim yn ein hatal rhag gosod VTEP ar y gweinyddwyr eu hunain, ac mae OVS (OpenvSwitch) yn wych am wneud hyn. O ganlyniad, cawsom y dyluniad hwn:
Gan fod yn rhaid rhannu traffig rhwng VMs, bydd gan y porthladdoedd tuag at y peiriannau rhithwir rifau vlan gwahanol. Dim ond o fewn un switsh rhithwir y mae rhif y tag yn chwarae rôl, oherwydd pan fydd wedi'i grynhoi yn VxLAN gallwn ei dynnu'n hawdd, gan y bydd gennym VNI.
Nawr gallwn greu ein peiriannau a'n rhwydweithiau rhithwir ar eu cyfer heb unrhyw broblemau.
Fodd bynnag, beth os oes gan y cleient beiriant arall, ond ei fod ar rwydwaith gwahanol? Mae angen gwreiddio rhwng rhwydweithiau. Byddwn yn edrych ar opsiwn syml pan ddefnyddir llwybro canolog - hynny yw, mae traffig yn cael ei gyfeirio trwy nodau rhwydwaith pwrpasol arbennig (wel, fel rheol, maent yn cael eu cyfuno â nodau rheoli, felly bydd gennym yr un peth).
Mae'n ymddangos fel dim byd cymhleth - rydyn ni'n gwneud rhyngwyneb pont ar y nod rheoli, yn gyrru traffig iddo ac oddi yno rydyn ni'n ei lwybro lle rydyn ni ei angen. Ond y broblem yw bod y cleient COCH eisiau defnyddio'r rhwydwaith 10.0.0.0/24, ac mae'r cleient GWYRDD eisiau defnyddio'r rhwydwaith 10.0.0.0/24. Hynny yw, rydym yn dechrau croestorri bylchau cyfeiriad. Yn ogystal, nid yw cleientiaid am i gleientiaid eraill allu llwybro i'w rhwydweithiau mewnol, sy'n gwneud synnwyr. Er mwyn gwahanu'r rhwydweithiau a'r traffig data cleientiaid, byddwn yn dyrannu gofod enw ar wahân ar gyfer pob un ohonynt. Mewn gwirionedd mae Namespace yn gopi o'r pentwr rhwydwaith Linux, hynny yw, mae cleientiaid yn gofod enwau RED wedi'u hynysu'n llwyr oddi wrth gleientiaid gofod enwau GWYRDD (wel, caniateir naill ai llwybro rhwng y rhwydweithiau cleientiaid hyn trwy'r gofod enwau diofyn neu ar offer trafnidiaeth i fyny'r afon).
Hynny yw, rydym yn cael y diagram canlynol:
Mae twneli L2 yn cydgyfeirio o'r holl nodau cyfrifiadurol i'r nod rheoli. nod lle mae'r rhyngwyneb L3 ar gyfer y rhwydweithiau hyn wedi'i leoli, pob un mewn gofod enw pwrpasol ar gyfer ynysu.
Fodd bynnag, rydym wedi anghofio y peth pwysicaf. Rhaid i'r peiriant rhithwir ddarparu gwasanaeth i'r cleient, hynny yw, rhaid iddo gael o leiaf un rhyngwyneb allanol y gellir ei gyrraedd. Hynny yw, mae angen inni fynd allan i'r byd y tu allan. Mae yna wahanol opsiynau yma. Gadewch i ni wneud yr opsiwn symlaf. Byddwn yn ychwanegu un rhwydwaith at bob cleient, a fydd yn ddilys yn rhwydwaith y darparwr ac ni fydd yn gorgyffwrdd â rhwydweithiau eraill. Gall y rhwydweithiau hefyd groestorri ac edrych ar wahanol VRFs ar ochr y rhwydwaith darparwyr. Bydd data'r rhwydwaith hefyd yn byw yng ngofod enwau pob cleient. Fodd bynnag, byddant yn dal i fynd allan i'r byd y tu allan trwy un rhyngwyneb corfforol (neu fond, sy'n fwy rhesymegol). Er mwyn gwahanu traffig cleientiaid, bydd traffig sy'n mynd allan yn cael ei dagio gyda thag VLAN wedi'i ddyrannu i'r cleient.
O ganlyniad, cawsom y diagram hwn:
Cwestiwn rhesymol yw beth am wneud pyrth ar y nodau cyfrifiadurol eu hunain? Nid yw hon yn broblem fawr; ar ben hynny, os trowch y llwybrydd dosbarthedig ymlaen (DVR), bydd hyn yn gweithio. Yn y senario hwn, rydym yn ystyried yr opsiwn symlaf gyda phorth canolog, a ddefnyddir yn ddiofyn yn Openstack. Ar gyfer swyddogaethau llwyth uchel, byddant yn defnyddio llwybrydd dosbarthedig a thechnolegau cyflymu fel SR-IOV a Passthrough, ond fel y dywedant, mae honno'n stori hollol wahanol. Yn gyntaf, gadewch i ni ddelio â'r rhan sylfaenol, ac yna byddwn yn mynd i mewn i'r manylion.
Mewn gwirionedd, mae ein cynllun eisoes yn ymarferol, ond mae yna ychydig o arlliwiau:
- Mae angen i ni rywsut amddiffyn ein peiriannau, hynny yw, rhoi hidlydd ar y rhyngwyneb switsh tuag at y cleient.
- Gwnewch hi'n bosibl i beiriant rhithwir gael cyfeiriad IP yn awtomatig, fel nad oes rhaid i chi fewngofnodi trwy'r consol bob tro a chofrestru'r cyfeiriad.
Gadewch i ni ddechrau gyda diogelu peiriant. Ar gyfer hyn gallwch ddefnyddio banal iptables, pam ddim.
Hynny yw, nawr mae ein topoleg wedi dod ychydig yn fwy cymhleth:
Gadewch i ni symud ymlaen. Mae angen i ni ychwanegu gweinydd DHCP. Y lle mwyaf delfrydol i leoli gweinyddwyr DHCP ar gyfer pob cleient fyddai'r nod rheoli a grybwyllwyd eisoes uchod, lle mae'r gofodau enwau wedi'u lleoli:
Fodd bynnag, mae problem fach. Beth os bydd popeth yn ailgychwyn a bod yr holl wybodaeth am gyfeiriadau rhentu ar DHCP yn diflannu. Mae'n rhesymegol y bydd y peiriannau'n cael cyfeiriadau newydd, nad yw'n gyfleus iawn. Mae dwy ffordd allan yma - naill ai defnyddio enwau parth ac ychwanegu gweinydd DNS ar gyfer pob cleient, yna ni fydd y cyfeiriad yn arbennig o bwysig i ni (yn debyg i'r rhan rhwydwaith yn k8s) - ond mae problem gyda rhwydweithiau allanol, ers hynny gellir cyhoeddi cyfeiriadau ynddynt hefyd trwy DHCP - mae angen cydamseriad arnoch chi â gweinyddwyr DNS yn y platfform cwmwl a gweinydd DNS allanol, nad yw yn fy marn i yn hyblyg iawn, ond mae'n eithaf posibl. Neu'r ail opsiwn yw defnyddio metadata - hynny yw, arbed gwybodaeth am y cyfeiriad a roddwyd i'r peiriant fel bod y gweinydd DHCP yn gwybod pa gyfeiriad i'w roi i'r peiriant os yw'r peiriant eisoes wedi derbyn cyfeiriad. Mae'r ail opsiwn yn symlach ac yn fwy hyblyg, gan ei fod yn caniatáu ichi arbed gwybodaeth ychwanegol am y car. Nawr, gadewch i ni ychwanegu metadata asiant at y diagram:
Mater arall sydd hefyd yn werth ei drafod yw'r gallu i ddefnyddio un rhwydwaith allanol gan bob cleient, gan y bydd rhwydweithiau allanol, os oes rhaid iddynt fod yn ddilys trwy'r rhwydwaith cyfan, yn anodd - mae angen i chi ddyrannu a rheoli dyraniad y rhwydweithiau hyn yn gyson. Bydd y gallu i ddefnyddio un rhwydwaith allanol wedi'i ffurfweddu ymlaen llaw ar gyfer pob cleient yn ddefnyddiol iawn wrth greu cwmwl cyhoeddus. Bydd hyn yn ei gwneud hi'n haws defnyddio peiriannau oherwydd nid oes rhaid i ni ymgynghori â chronfa ddata cyfeiriadau a dewis gofod cyfeiriad unigryw ar gyfer rhwydwaith allanol pob cleient. Yn ogystal, gallwn gofrestru rhwydwaith allanol ymlaen llaw ac ar adeg ei ddefnyddio dim ond cyfeiriadau allanol fydd angen i ni eu cysylltu â pheiriannau cleient.
A dyma NAT yn dod i'n cymorth - byddwn ni'n ei gwneud hi'n bosibl i gleientiaid gael mynediad i'r byd y tu allan trwy'r gofod enwau rhagosodedig gan ddefnyddio cyfieithiad NAT. Wel, dyma broblem fach. Mae hyn yn dda os yw'r gweinydd cleient yn gweithredu fel cleient ac nid fel gweinydd - hynny yw, mae'n cychwyn yn hytrach na derbyn cysylltiadau. Ond i ni bydd y ffordd arall o gwmpas. Yn yr achos hwn, mae angen i ni wneud NAT cyrchfan fel bod y nod rheoli, wrth dderbyn traffig, yn deall bod y traffig hwn wedi'i fwriadu ar gyfer peiriant rhithwir A cleient A, sy'n golygu bod angen i ni wneud cyfieithiad NAT o gyfeiriad allanol, er enghraifft 100.1.1.1 .10.0.0.1, i gyfeiriad mewnol 100. Yn yr achos hwn, er y bydd pob cleient yn defnyddio'r un rhwydwaith, mae ynysu mewnol wedi'i gadw'n llwyr. Hynny yw, mae angen i ni wneud dNAT a sNAT ar y nod rheoli. Mae p'un ai i ddefnyddio rhwydwaith sengl gyda chyfeiriadau arnofiol neu rwydweithiau allanol, neu'r ddau ar unwaith, yn dibynnu ar yr hyn rydych chi am ddod ag ef i'r cwmwl. Ni fyddwn yn ychwanegu cyfeiriadau symudol at y diagram, ond byddwn yn gadael y rhwydweithiau allanol a ychwanegwyd eisoes yn gynharach - mae gan bob cleient ei rwydwaith allanol ei hun (yn y diagram fe'u nodir fel vlan 200 a XNUMX ar y rhyngwyneb allanol).
O ganlyniad, cawsom ateb diddorol a ystyriwyd yn ofalus ar yr un pryd, sydd â rhywfaint o hyblygrwydd ond nad oes ganddo fecanweithiau goddef diffygion eto.
Yn gyntaf, dim ond un nod rheoli sydd gennym - bydd ei fethiant yn arwain at gwymp yr holl systemau. I ddatrys y broblem hon, mae angen i chi wneud o leiaf cworwm o 3 nod. Gadewch i ni ychwanegu hyn at y diagram:
Yn naturiol, mae pob nod yn cael ei gydamseru a phan fydd nod gweithredol yn gadael, bydd nod arall yn cymryd drosodd ei gyfrifoldebau.
Y broblem nesaf yw disgiau peiriant rhithwir. Ar hyn o bryd, maent yn cael eu storio ar y hypervisors eu hunain, ac mewn achos o broblemau gyda'r hypervisor, rydym yn colli'r holl ddata - ac ni fydd presenoldeb cyrch yn helpu yma os ydym yn colli nid y ddisg, ond y gweinydd cyfan. I wneud hyn, mae angen inni wneud gwasanaeth a fydd yn gweithredu fel pen blaen ar gyfer rhyw fath o storfa. Nid yw pa fath o storfa fydd yn arbennig o bwysig i ni, ond dylai amddiffyn ein data rhag methiant y ddisg a'r nod, ac o bosibl y cabinet cyfan. Mae yna sawl opsiwn yma - mae yna, wrth gwrs, rwydweithiau SAN gyda Fiber Channel, ond gadewch i ni fod yn onest - mae FC eisoes yn grair o'r gorffennol - analog o E1 mewn trafnidiaeth - ie, rwy'n cytuno, mae'n dal i gael ei ddefnyddio, ond dim ond lle mae'n gwbl amhosibl hebddo. Felly, ni fyddwn yn defnyddio rhwydwaith CC yn wirfoddol yn 2020, gan wybod bod dewisiadau eraill mwy diddorol ar gael. Er i bob un ei hun, efallai y bydd rhai sy'n credu mai FC gyda'i holl gyfyngiadau yw'r cyfan sydd ei angen arnom - ni fyddaf yn dadlau, mae gan bawb eu barn eu hunain. Fodd bynnag, yr ateb mwyaf diddorol yn fy marn i yw defnyddio SDS, fel Ceph.
Mae Ceph yn caniatáu ichi adeiladu datrysiad storio data sydd ar gael yn fawr gyda llawer o opsiynau wrth gefn posibl, gan ddechrau gyda chodau gyda gwirio cydraddoldeb (cyfateb i gyrch 5 neu 6) gan orffen gyda dyblygu data llawn i wahanol ddisgiau, gan ystyried lleoliad disgiau yn gweinyddion, a gweinyddion mewn cypyrddau, ac ati.
I adeiladu Ceph mae angen 3 nod arall arnoch chi. Bydd rhyngweithio â'r storfa hefyd yn cael ei wneud trwy'r rhwydwaith gan ddefnyddio gwasanaethau storio blociau, gwrthrychau a ffeiliau. Gadewch i ni ychwanegu storfa at y sgema:
Sylwch: gallwch hefyd wneud nodau cyfrifiadurol hypergydgyfeiriol - dyma'r cysyniad o gyfuno sawl swyddogaeth ar un nod - er enghraifft, storio + cyfrifiadur - heb neilltuo nodau arbennig ar gyfer storio ceph. Byddwn yn cael yr un cynllun goddefgar o fai - gan y bydd SDS yn cadw data gyda'r lefel cadw a nodir gennym. Fodd bynnag, mae nodau hypergydgyfeirio bob amser yn gyfaddawd - gan nad yw'r nod storio yn gwresogi'r aer yn unig fel y mae'n ymddangos ar yr olwg gyntaf (gan nad oes peiriannau rhithwir arno) - mae'n gwario adnoddau CPU ar wasanaethu SDS (mewn gwirionedd, mae'n gwneud y cyfan atgynhyrchu ac adfer ar ôl methiannau nodau, disgiau, ac ati). Hynny yw, byddwch chi'n colli rhywfaint o bŵer y nod cyfrifiadurol os byddwch chi'n ei gyfuno â storfa.
Mae angen rheoli'r holl bethau hyn rywsut - mae angen rhywbeth y gallwn greu peiriant, rhwydwaith, llwybrydd rhithwir, ac ati. I wneud hyn, byddwn yn ychwanegu gwasanaeth at y nod rheoli a fydd yn gweithredu fel dangosfwrdd - y bydd y cleient yn gallu cysylltu â'r porth hwn trwy http/ https a gwneud popeth sydd ei angen arno (wel, bron).
O ganlyniad, mae gennym bellach system sy’n goddef diffygion. Rhaid rheoli pob elfen o'r seilwaith hwn rywsut. Disgrifiwyd yn flaenorol mai set o brosiectau yw Openstack, y mae pob un ohonynt yn darparu swyddogaeth benodol. Fel y gwelwn, mae mwy na digon o elfennau y mae angen eu ffurfweddu a'u rheoli. Heddiw byddwn yn siarad am y rhan rhwydwaith.
Pensaernïaeth niwtron
Yn OpenStack, Neutron sy'n gyfrifol am gysylltu porthladdoedd peiriannau rhithwir â rhwydwaith L2 cyffredin, gan sicrhau llwybr traffig rhwng VMs sydd wedi'u lleoli ar wahanol rwydweithiau L2, yn ogystal â llwybro allan, gan ddarparu gwasanaethau fel NAT, IP floating, DHCP, ac ati.
Ar lefel uchel, gellir disgrifio gweithrediad y gwasanaeth rhwydwaith (y rhan sylfaenol) fel a ganlyn.
Wrth gychwyn y VM, mae'r gwasanaeth rhwydwaith:
- Yn creu porthladd ar gyfer VM (neu borthladdoedd) penodol ac yn hysbysu'r gwasanaeth DHCP amdano;
- Mae dyfais rhwydwaith rhithwir newydd yn cael ei chreu (trwy libvirt);
- Mae'r VM yn cysylltu â'r porthladd(iau) a grëwyd yng ngham 1;
Yn rhyfedd ddigon, mae gwaith Neutron yn seiliedig ar fecanweithiau safonol sy'n gyfarwydd i bawb sydd erioed wedi plymio i Linux - gofodau enwau, iptables, pontydd linux, openvswitch, conntrack, ac ati.
Dylid egluro ar unwaith nad yw Neutron yn rheolydd SDN.
Mae niwtron yn cynnwys nifer o gydrannau rhyng-gysylltiedig:
Openstack-neutron-server yn daemon sy'n gweithio gyda cheisiadau defnyddwyr trwy'r API. Nid yw'r cythraul hwn yn ymwneud â chofrestru unrhyw gysylltiadau rhwydwaith, ond mae'n darparu'r wybodaeth angenrheidiol ar gyfer hyn i'w ategion, sydd wedyn yn ffurfweddu'r elfen rhwydwaith a ddymunir. Mae asiantau niwtron ar nodau OpenStack yn cofrestru gyda'r gweinydd Neutron.
Mewn gwirionedd mae gweinydd niwtron yn gymhwysiad wedi'i ysgrifennu mewn python, sy'n cynnwys dwy ran:
- REST gwasanaeth
- Ategyn niwtron (craidd/gwasanaeth)
Mae'r gwasanaeth REST wedi'i gynllunio i dderbyn galwadau API o gydrannau eraill (er enghraifft, cais i ddarparu rhywfaint o wybodaeth, ac ati)
Mae ategion yn gydrannau/modiwlau meddalwedd plygio i mewn a elwir yn ystod ceisiadau API - hynny yw, mae priodoli gwasanaeth yn digwydd trwyddynt. Rhennir ategion yn ddau fath - gwasanaeth a gwraidd. Fel rheol, mae'r ategyn ceffyl yn bennaf gyfrifol am reoli'r gofod cyfeiriad a chysylltiadau L2 rhwng VMs, ac mae ategion gwasanaeth eisoes yn darparu swyddogaethau ychwanegol fel VPN neu FW.
Gellir gweld y rhestr o ategion sydd ar gael heddiw er enghraifft
Gall fod nifer o ategion gwasanaeth, ond dim ond un ategyn ceffyl all fod.
Openstack-niwtron-ml2 yw'r ategyn gwraidd Openstack safonol. Mae gan yr ategyn hwn bensaernïaeth fodiwlaidd (yn wahanol i'w ragflaenydd) ac mae'n ffurfweddu'r gwasanaeth rhwydwaith trwy yrwyr sy'n gysylltiedig ag ef. Byddwn yn edrych ar yr ategyn ei hun ychydig yn ddiweddarach, oherwydd mewn gwirionedd mae'n rhoi'r hyblygrwydd sydd gan OpenStack yn rhan y rhwydwaith. Gellir disodli'r ategyn gwraidd (er enghraifft, mae Contrail Networking yn ei le).
Gwasanaeth RPC (rabbitmq-server) — gwasanaeth sy'n darparu rheolaeth ciw a rhyngweithio â gwasanaethau OpenStack eraill, yn ogystal â rhyngweithio rhwng asiantau gwasanaethau rhwydwaith.
Asiantau rhwydwaith — asiantau sydd wedi'u lleoli ym mhob nod, y mae gwasanaethau rhwydwaith wedi'u ffurfweddu trwyddynt.
Mae yna sawl math o asiantau.
Y prif asiant yw Asiant L2. Mae'r asiantau hyn yn rhedeg ar bob un o'r hypervisors, gan gynnwys nodau rheoli (yn fwy manwl gywir, ar bob nod sy'n darparu unrhyw wasanaeth i denantiaid) a'u prif swyddogaeth yw cysylltu peiriannau rhithwir â rhwydwaith L2 cyffredin, a hefyd yn cynhyrchu rhybuddion pan fydd unrhyw ddigwyddiadau yn digwydd ( er enghraifft analluogi/galluogi'r porthladd).
Yr asiant nesaf, dim llai pwysig yw Asiant L3. Yn ddiofyn, mae'r asiant hwn yn rhedeg yn gyfan gwbl ar nod rhwydwaith (yn aml mae'r nod rhwydwaith yn cael ei gyfuno â nod rheoli) ac yn darparu llwybr rhwng rhwydweithiau tenantiaid (rhwng ei rwydweithiau a rhwydweithiau tenantiaid eraill, ac mae'n hygyrch i'r byd y tu allan, gan ddarparu NAT, yn ogystal â gwasanaeth DHCP). Fodd bynnag, wrth ddefnyddio DVR (llwybrydd wedi'i ddosbarthu), mae'r angen am ategyn L3 hefyd yn ymddangos ar y nodau cyfrifo.
Mae'r asiant L3 yn defnyddio gofodau enwau Linux i ddarparu set o'i rwydweithiau ynysig ei hun i bob tenant ac ymarferoldeb llwybryddion rhithwir sy'n llwybro traffig ac yn darparu gwasanaethau porth ar gyfer rhwydweithiau Haen 2.
Cronfa Ddata — cronfa ddata o ddynodwyr rhwydweithiau, is-rwydweithiau, porthladdoedd, pyllau, ac ati.
Mewn gwirionedd, mae Neutron yn derbyn ceisiadau API o greu unrhyw endidau rhwydwaith, yn dilysu'r cais, a thrwy RPC (os yw'n cyrchu rhyw ategyn neu asiant) neu REST API (os yw'n cyfathrebu yn SDN) yn trosglwyddo i'r asiantau (trwy ategion) y cyfarwyddiadau angenrheidiol i drefnu'r gwasanaeth y gofynnir amdano.
Nawr, gadewch i ni droi at y gosodiad prawf (sut mae'n cael ei ddefnyddio a beth sydd wedi'i gynnwys ynddo, fe welwn ni yn ddiweddarach yn y rhan ymarferol) a gweld ble mae pob cydran wedi'i lleoli:
(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 ~]$
A dweud y gwir, dyna strwythur cyfan Niwtron. Nawr mae'n werth treulio peth amser ar yr ategyn ML2.
Haen Modiwlaidd 2
Fel y soniwyd uchod, mae'r ategyn yn ategyn gwraidd OpenStack safonol ac mae ganddo bensaernïaeth fodiwlaidd.
Roedd gan ragflaenydd yr ategyn ML2 strwythur monolithig, nad oedd yn caniatáu, er enghraifft, defnyddio cymysgedd o sawl technoleg mewn un gosodiad. Er enghraifft, ni allech ddefnyddio openvswitch a linuxbridge ar yr un pryd - naill ai'r cyntaf neu'r ail. Am y rheswm hwn, crëwyd yr ategyn ML2 gyda'i bensaernïaeth.
Mae gan ML2 ddwy gydran - dau fath o yrwyr: Gyrwyr Math a gyrwyr Mecanwaith.
Math o yrwyr penderfynu ar y technolegau a ddefnyddir i drefnu cysylltiadau rhwydwaith, er enghraifft VxLAN, VLAN, GRE. Ar yr un pryd, mae'r gyrrwr yn caniatáu defnyddio gwahanol dechnolegau. Y dechnoleg safonol yw amgáu VxLAN ar gyfer rhwydweithiau troshaen a rhwydweithiau allanol vlan.
Mae gyrwyr math yn cynnwys y mathau rhwydwaith canlynol:
Meddalnod - rhwydwaith heb dagio
VLANs - rhwydwaith wedi'i dagio
Lleol - math arbennig o rwydwaith ar gyfer gosodiadau popeth-mewn-un (mae angen gosodiadau o'r fath naill ai ar gyfer datblygwyr neu ar gyfer hyfforddiant)
GRE — rhwydwaith troshaen gan ddefnyddio twneli GRE
VxLAN — rhwydwaith troshaenu gan ddefnyddio twneli VxLAN
Gyrwyr mecanwaith diffinio offer sy'n sicrhau trefniadaeth y technolegau a nodir yn y gyrrwr math - er enghraifft, openvswitch, sr-iov, opendaylight, OVN, ac ati.
Yn dibynnu ar weithrediad y gyrrwr hwn, bydd naill ai asiantau a reolir gan Neutron yn cael eu defnyddio, neu bydd cysylltiadau â rheolydd SDN allanol yn cael eu defnyddio, sy'n gofalu am yr holl faterion sy'n ymwneud â threfnu rhwydweithiau L2, llwybro, ac ati.
Enghraifft: os ydym yn defnyddio ML2 ynghyd ag OVS, yna mae asiant L2 yn cael ei osod ar bob nod cyfrifiadurol sy'n rheoli OVS. Fodd bynnag, os ydym yn defnyddio, er enghraifft, OVN neu OpenDayLight, yna mae rheolaeth OVS yn dod o dan eu hawdurdodaeth - mae Neutron, trwy'r ategyn gwraidd, yn rhoi gorchmynion i'r rheolwr, ac mae eisoes yn gwneud yr hyn a ddywedwyd wrtho.
Gadewch i ni wella ar Open vSwitch
Ar hyn o bryd, un o gydrannau allweddol OpenStack yw Open vSwitch.
Wrth osod OpenStack heb unrhyw werthwr ychwanegol SDN fel Juniper Contrail neu Nokia Nuage, OVS yw prif gydran rhwydwaith y rhwydwaith cwmwl ac, ynghyd ag iptables, conntrack, namespaces, mae'n caniatáu ichi drefnu rhwydweithiau troshaen aml-denantiaeth llawn. Yn naturiol, gellir disodli'r gydran hon, er enghraifft, wrth ddefnyddio datrysiadau SDN perchnogol (gwerthwr) trydydd parti.
Mae OVS yn switsh meddalwedd ffynhonnell agored sydd wedi'i gynllunio i'w ddefnyddio mewn amgylcheddau rhithwir fel anfonwr traffig rhithwir.
Ar hyn o bryd, mae gan OVS ymarferoldeb gweddus iawn, sy'n cynnwys technolegau fel QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, ac ati.
Sylwer: Ni chafodd OVS ei feddwl i ddechrau fel switsh meddal ar gyfer swyddogaethau telathrebu llwythol iawn ac fe'i cynlluniwyd yn fwy ar gyfer swyddogaethau TG â llai o alw am led band fel gweinydd WEB neu weinydd post. Fodd bynnag, mae OVS yn cael ei ddatblygu ymhellach ac mae gweithrediadau OVS cyfredol wedi gwella ei berfformiad a'i alluoedd yn fawr, sy'n caniatáu iddo gael ei ddefnyddio gan weithredwyr telathrebu â swyddogaethau llwyth uchel, er enghraifft, mae gweithrediad OVS gyda chefnogaeth ar gyfer cyflymiad DPDK.
Mae tair cydran bwysig o OVS y mae angen i chi fod yn ymwybodol ohonynt:
- Modiwl cnewyllyn — cydran sydd wedi'i lleoli yn y gofod cnewyllyn sy'n prosesu traffig yn seiliedig ar y rheolau a dderbyniwyd gan yr elfen reoli;
- vSwitch Mae daemon (ovs-vswitchd) yn broses a lansiwyd yn y gofod defnyddiwr sy'n gyfrifol am raglennu'r modiwl cnewyllyn - hynny yw, mae'n cynrychioli'n uniongyrchol resymeg gweithrediad y switsh
- Gweinydd cronfa ddata - cronfa ddata leol wedi'i lleoli ar bob gwesteiwr sy'n rhedeg OVS, lle mae'r ffurfwedd yn cael ei storio. Gall rheolwyr SDN gyfathrebu trwy'r modiwl hwn gan ddefnyddio'r protocol OVSDB.
Ynghyd â hyn i gyd mae set o gyfleustodau diagnostig a rheoli, megis ovs-vsctl, ovs-appctl, ovs-ofctl, ac ati.
Ar hyn o bryd, mae Openstack yn cael ei ddefnyddio'n helaeth gan weithredwyr telathrebu i fudo swyddogaethau rhwydwaith iddo, megis EPC, SBC, HLR, ac ati Gall rhai swyddogaethau fyw heb broblemau gydag OVS fel y mae, ond er enghraifft, mae EPC yn prosesu traffig tanysgrifiwr - yna mae'n mynd trwy llawer iawn o draffig (bellach mae maint y traffig yn cyrraedd cannoedd o gigabits yr eiliad). Yn naturiol, nid gyrru traffig o'r fath trwy ofod cnewyllyn (gan fod y blaenwr wedi'i leoli yno yn ddiofyn) yw'r syniad gorau. Felly, mae OVS yn aml yn cael ei ddefnyddio'n gyfan gwbl mewn gofod defnyddwyr gan ddefnyddio technoleg cyflymu DPDK i anfon traffig o NIC i ofod defnyddwyr gan osgoi'r cnewyllyn.
Sylwch: ar gyfer cwmwl a ddefnyddir ar gyfer swyddogaethau telathrebu, mae'n bosibl allbynnu traffig o nod cyfrifiadurol sy'n osgoi OVS yn uniongyrchol i newid offer. Defnyddir mecanweithiau SR-IOV a Passthrough at y diben hwn.
Sut mae hyn yn gweithio ar gynllun go iawn?
Wel, nawr gadewch i ni symud ymlaen at y rhan ymarferol a gweld sut mae'r cyfan yn gweithio'n ymarferol.
Yn gyntaf, gadewch i ni ddefnyddio gosodiad Openstack syml. Gan nad oes gennyf set o weinyddion wrth law ar gyfer arbrofion, byddwn yn cydosod y prototeip ar un gweinydd corfforol o beiriannau rhithwir. Ydy, yn naturiol, nid yw datrysiad o'r fath yn addas at ddibenion masnachol, ond i weld enghraifft o sut mae'r rhwydwaith yn gweithio yn Openstack, mae gosodiad o'r fath yn ddigon i'r llygaid. Ar ben hynny, mae gosodiad o'r fath hyd yn oed yn fwy diddorol at ddibenion hyfforddi - oherwydd gallwch chi ddal traffig, ac ati.
Gan mai dim ond y rhan sylfaenol y mae angen i ni ei weld, ni allwn ddefnyddio sawl rhwydwaith ond codi popeth gan ddefnyddio dau rwydwaith yn unig, a bydd yr ail rwydwaith yn y cynllun hwn yn cael ei ddefnyddio'n unig ar gyfer mynediad i'r gweinydd undercloud a DNS. Ni fyddwn yn cyffwrdd â rhwydweithiau allanol am y tro - mae hwn yn bwnc ar gyfer erthygl fawr ar wahân.
Felly, gadewch i ni ddechrau mewn trefn. Yn gyntaf, ychydig o theori. Byddwn yn gosod Openstack gan ddefnyddio TripleO (Openstack ar Openstack). Hanfod TripleO yw ein bod yn gosod Openstack popeth-mewn-un (hynny yw, ar un nod), a elwir yn undercloud, ac yna'n defnyddio galluoedd yr Openstack a ddefnyddir i osod Openstack y bwriedir ei weithredu, a elwir yn overcloud. Bydd Undercloud yn defnyddio ei allu cynhenid i reoli gweinyddwyr ffisegol (metel noeth) - y prosiect Eironig - i ddarparu hypervisors a fydd yn cyflawni rolau cyfrifiannu, rheoli, nodau storio. Hynny yw, nid ydym yn defnyddio unrhyw offer trydydd parti i ddefnyddio Openstack - rydym yn defnyddio Openstack gan ddefnyddio Openstack. Bydd yn dod yn llawer cliriach wrth i'r gosodiad fynd rhagddo, felly ni fyddwn yn stopio yno ac yn symud ymlaen.
Nodyn: Yn yr erthygl hon, er mwyn symlrwydd, ni ddefnyddiais ynysu rhwydwaith ar gyfer rhwydweithiau Openstack mewnol, ond mae popeth yn cael ei ddefnyddio gan ddefnyddio un rhwydwaith yn unig. Fodd bynnag, nid yw presenoldeb neu absenoldeb ynysu rhwydwaith yn effeithio ar ymarferoldeb sylfaenol yr ateb - bydd popeth yn gweithio'n union yr un fath ag wrth ddefnyddio ynysu, ond bydd traffig yn llifo ar yr un rhwydwaith. Ar gyfer gosodiad masnachol, mae'n naturiol yn angenrheidiol defnyddio ynysu gan ddefnyddio gwahanol vlans a rhyngwynebau. Er enghraifft, mae traffig rheoli storio ceph a thraffig data ei hun (mynediad peiriant i ddisgiau, ac ati) pan yn ynysig yn defnyddio gwahanol is-rwydweithiau (Rheoli Storio a Storio) ac mae hyn yn caniatáu ichi wneud yr ateb yn fwy goddefgar o fai trwy rannu'r traffig hwn, er enghraifft , ar draws gwahanol borthladdoedd, neu ddefnyddio gwahanol broffiliau QoS ar gyfer traffig gwahanol fel nad yw traffig data yn gwasgu traffig signalau allan. Yn ein hachos ni, byddant yn mynd ar yr un rhwydwaith ac mewn gwirionedd nid yw hyn yn ein cyfyngu mewn unrhyw ffordd.
Nodyn: Gan ein bod yn mynd i redeg peiriannau rhithwir mewn amgylchedd rhithwir yn seiliedig ar beiriannau rhithwir, yn gyntaf mae angen i ni alluogi rhithwiroli nythu.
Gallwch wirio a yw rhithwiroli nythu wedi'i alluogi ai peidio fel hyn:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Os gwelwch y llythyren N, yna rydym yn galluogi cefnogaeth ar gyfer rhithwiroli nythu yn ôl unrhyw ganllaw y byddwch yn dod o hyd iddo ar y rhwydwaith, er enghraifft .
Mae angen inni gydosod y gylched ganlynol o beiriannau rhithwir:
Yn fy achos i, i gysylltu'r peiriannau rhithwir sy'n rhan o'r gosodiad yn y dyfodol (a chefais 7 ohonyn nhw, ond gallwch chi fynd heibio gyda 4 os nad oes gennych chi lawer o adnoddau), defnyddiais OpenvSwitch. Creais un bont ovs a chysylltais beiriannau rhithwir ag ef trwy grwpiau porthladdoedd. I wneud hyn, creais ffeil xml fel hyn:
[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>Mae tri grŵp porthladd yn cael eu datgan yma - dau fynediad ac un gefnffordd (roedd angen yr olaf ar gyfer y gweinydd DNS, ond gallwch chi wneud hebddo, neu ei osod ar y peiriant gwesteiwr - pa un bynnag sydd fwyaf cyfleus i chi). Nesaf, gan ddefnyddio'r templed hwn, rydym yn datgan ein un ni trwy virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nawr rydym yn golygu'r ffurfweddiadau porthladd hypervisor:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Sylwch: yn y senario hwn, ni fydd y cyfeiriad ar port ovs-br1 yn hygyrch oherwydd nad oes ganddo dag vlan. I drwsio hyn, mae angen i chi gyhoeddi'r gorchymyn sudo ovs-vsctl set port ovs-br1 tag = 100. Fodd bynnag, ar ôl ailgychwyn, bydd y tag hwn yn diflannu (os oes unrhyw un yn gwybod sut i'w wneud yn aros yn ei le, byddaf yn ddiolchgar iawn). Ond nid yw hyn mor bwysig, oherwydd dim ond yn ystod y gosodiad y bydd angen y cyfeiriad hwn arnom ac ni fydd ei angen arnom pan fydd Openstack wedi'i ddefnyddio'n llawn.
Nesaf, rydym yn creu peiriant undercloud:
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=ttyS0Yn ystod y gosodiad, rydych chi'n gosod yr holl baramedrau angenrheidiol, megis enw'r peiriant, cyfrineiriau, defnyddwyr, gweinyddwyr ntp, ac ati, gallwch chi ffurfweddu'r porthladdoedd ar unwaith, ond i mi yn bersonol, ar ôl ei osod, mae'n haws mewngofnodi i'r peiriant trwy y consol a chywiro'r ffeiliau angenrheidiol. Os oes gennych ddelwedd barod eisoes, gallwch ei ddefnyddio, neu wneud yr hyn a wnes i - lawrlwythwch y ddelwedd Centos 7 leiaf a'i ddefnyddio i osod y VM.
Ar ôl gosod yn llwyddiannus, dylai fod gennych beiriant rhithwir y gallwch osod undercloud arno
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningYn gyntaf, gosodwch yr offer angenrheidiol ar gyfer y broses osod:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Gosod undercloud
Rydyn ni'n creu defnyddiwr pentwr, yn gosod cyfrinair, yn ei ychwanegu at sudoer ac yn rhoi'r gallu iddo weithredu gorchmynion gwraidd trwy sudo heb orfod nodi cyfrinair:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNawr rydym yn nodi'r enw undercloud llawn yn y ffeil gwesteiwr:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Nesaf, rydym yn ychwanegu storfeydd ac yn gosod y meddalwedd sydd ei angen arnom:
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-ansibleSylwch: os nad ydych chi'n bwriadu gosod ceph, yna nid oes angen i chi nodi gorchmynion sy'n gysylltiedig â ceph. Defnyddiais ryddhad y Frenhines, ond gallwch chi ddefnyddio unrhyw un arall yr hoffech chi.
Nesaf, copïwch y ffeil ffurfweddu undercloud i bentwr cyfeiriadur cartref y defnyddiwr:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNawr mae angen i ni gywiro'r ffeil hon, gan ei haddasu i'n gosodiad.
Mae angen i chi ychwanegu'r llinellau hyn at ddechrau'r ffeil:
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 = 10Felly, gadewch i ni fynd trwy'r gosodiadau:
undercloud_hostname — rhaid i enw llawn y gweinydd undercloud, gyd-fynd â'r cofnod ar y gweinydd DNS
lleol_ip — cyfeiriad undercloud lleol tuag at ddarpariaeth rhwydwaith
porth_rhwydwaith — mae'r un cyfeiriad lleol, a fydd yn gweithredu fel porth ar gyfer mynediad i'r byd y tu allan wrth osod nodau overcloud, hefyd yn cyd-fynd ag ip lleol
undercloud_public_host — cyfeiriad API allanol, neilltuir unrhyw gyfeiriad am ddim o'r rhwydwaith darparu
undercloud_admin_host cyfeiriad API mewnol, neilltuir unrhyw gyfeiriad am ddim o'r rhwydwaith darparu
undercloud_nameservers - gweinydd DNS
tystysgrif_cynhyrchu_gwasanaeth - mae'r llinell hon yn bwysig iawn yn yr enghraifft gyfredol, oherwydd os na fyddwch yn ei gosod yn ffug byddwch yn derbyn gwall yn ystod y gosodiad, disgrifir y broblem ar draciwr byg Red Hat
rhyngwyneb_lleol rhyngwyneb mewn darpariaeth rhwydwaith. Bydd y rhyngwyneb hwn yn cael ei ail-ffurfweddu wrth ddefnyddio undercloud, felly mae angen i chi gael dau ryngwyneb ar undercloud - un ar gyfer cael mynediad iddo, yr ail ar gyfer darparu
lleol_mtu - MTU. Gan fod gennym ni labordy prawf a bod gen i MTU o 1500 ar borthladdoedd switsh OVS, mae angen ei osod i 1450 fel y gall pecynnau sydd wedi'u hamgáu yn VxLAN basio drwodd.
rhwydwaith_cidr — rhwydwaith darparu
masquerade — defnyddio NAT i gael mynediad i rwydwaith allanol
masquerade_rhwydwaith - rhwydwaith a fydd yn cael ei NATed
dhcp_cychwyn — cyfeiriad cychwyn y gronfa o gyfeiriadau lle bydd cyfeiriadau'n cael eu neilltuo i nodau yn ystod y defnydd o orgwmwl
dhcp_diwedd — cyfeiriad terfynol y gronfa o gyfeiriadau lle bydd cyfeiriadau'n cael eu neilltuo i nodau yn ystod y defnydd o orgwmwl
arolygiad_iprange — cronfa o gyfeiriadau sy’n angenrheidiol ar gyfer mewnsylliad (ni ddylai gorgyffwrdd â’r gronfa uchod)
amserlennwr_max_ymgeisiau — uchafswm nifer yr ymdrechion i osod overcloud (rhaid iddo fod yn fwy na neu'n hafal i nifer y nodau)
Ar ôl i'r ffeil gael ei disgrifio, gallwch chi roi'r gorchymyn i ddefnyddio undercloud:
openstack undercloud install
Mae'r weithdrefn yn cymryd rhwng 10 a 30 munud yn dibynnu ar eich haearn. Yn y pen draw dylech weld allbwn fel hyn:
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.
#############################################################################Mae'r allbwn hwn yn dweud eich bod wedi gosod undercloud yn llwyddiannus a gallwch nawr wirio statws undercloud a symud ymlaen i osod overcloud.
Os edrychwch ar yr allbwn ifconfig, fe welwch fod rhyngwyneb pont newydd wedi ymddangos
[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 0Bydd defnydd Overcloud nawr yn cael ei wneud trwy'r rhyngwyneb hwn.
O'r allbwn isod gallwch weld bod gennym bob gwasanaeth ar un nod:
(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 |
+--------------------------+-----------+----------+Isod mae cyfluniad y rhan rhwydwaith undercloud:
(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 ~]$Gosod Overcloud
Ar hyn o bryd dim ond undercloud sydd gennym, ac nid oes gennym ddigon o nodau y bydd gorgwm yn cael ei ymgynnull ohonynt. Felly, yn gyntaf oll, gadewch i ni ddefnyddio'r peiriannau rhithwir sydd eu hangen arnom. Yn ystod y defnydd, bydd undercloud ei hun yn gosod yr OS a'r feddalwedd angenrheidiol ar y peiriant overcloud - hynny yw, nid oes angen i ni ddefnyddio'r peiriant yn llwyr, ond dim ond creu disg (neu ddisgiau) ar ei gyfer a phennu ei baramedrau - hynny yw , mewn gwirionedd, rydym yn cael gweinydd noeth heb OS wedi'i osod arno .
Gadewch i ni fynd i'r ffolder gyda disgiau ein peiriannau rhithwir a chreu disgiau o'r maint gofynnol:
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 160GGan ein bod yn gweithredu fel gwraidd, mae angen i ni newid perchennog y disgiau hyn er mwyn peidio â chael problem gyda hawliau:
[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]# Sylwch: os nad ydych chi'n bwriadu gosod ceph er mwyn ei astudio, yna nid yw'r gorchmynion yn creu o leiaf 3 nod gydag o leiaf dwy ddisg, ond yn y templed nodwch y bydd disgiau rhithwir vda, vdb, ac ati yn cael eu defnyddio.
Gwych, nawr mae angen i ni ddiffinio'r holl beiriannau hyn:
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 Ar y diwedd mae gorchymyn -print-xml> /tmp/storage-1.xml, sy'n creu ffeil xml gyda disgrifiad o bob peiriant yn y ffolder /tmp/; os na fyddwch yn ei ychwanegu, ni fyddwch yn gallu adnabod peiriannau rhithwir.
Nawr mae angen i ni ddiffinio'r holl beiriannau hyn mewn 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 ~]#Bellach naws fach - mae tripleO yn defnyddio IPMI i reoli gweinyddwyr yn ystod gosod a mewnsylliad.
Mewnwelediad yw'r broses o archwilio'r caledwedd er mwyn cael y paramedrau angenrheidiol ar gyfer darparu nodau ymhellach. Gwneir mewnsylliad gan ddefnyddio eironig, gwasanaeth a gynlluniwyd i weithio gyda gweinyddwyr metel noeth.
Ond dyma'r broblem - er bod gan weinyddion caledwedd IPMI borthladd ar wahân (neu borthladd a rennir, ond nid yw hyn yn bwysig), yna nid oes gan beiriannau rhithwir borthladdoedd o'r fath. Yma daw bagl o'r enw vbmc i'n cymorth - cyfleustodau sy'n eich galluogi i efelychu porthladd IPMI. Mae'n werth rhoi sylw i'r naws hwn yn arbennig ar gyfer y rhai sydd am sefydlu labordy o'r fath ar hypervisor ESXI - a dweud y gwir, nid wyf yn gwybod a oes ganddo analog o vbmc, felly mae'n werth pendroni am y mater hwn cyn defnyddio popeth. .
Gosod vbmc:
yum install yum install python2-virtualbmcOs na all eich OS ddod o hyd i'r pecyn, yna ychwanegwch yr ystorfa:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNawr rydym yn sefydlu'r cyfleustodau. Mae popeth yma yn warthus i'r pwynt o warthus. Nawr mae'n rhesymegol nad oes gweinyddwyr yn y rhestr vbmc
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Er mwyn iddynt ymddangos, rhaid eu datgan â llaw fel hyn:
[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 ~]#Rwy'n credu bod cystrawen y gorchymyn yn glir heb esboniad. Fodd bynnag, am y tro mae ein holl sesiynau mewn statws DOWN. Er mwyn iddynt symud i statws UP, mae angen i chi eu galluogi:
[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 ~]#A'r cyffyrddiad olaf - mae angen i chi gywiro'r rheolau wal dân (neu ei analluogi'n llwyr):
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
Nawr, gadewch i ni fynd i undercloud a gwirio bod popeth yn gweithio. Cyfeiriad y peiriant gwesteiwr yw 192.168.255.200, ar undercloud ychwanegwyd y pecyn ipmitool angenrheidiol wrth baratoi ar gyfer ei ddefnyddio:
[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 runningFel y gwelwch, rydym wedi lansio'r nod rheoli yn llwyddiannus trwy vbmc. Nawr gadewch i ni ei droi i ffwrdd a symud ymlaen:
[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 ~]#Y cam nesaf yw introspection o'r nodau y bydd overcloud yn cael ei osod arnynt. I wneud hyn, mae angen i ni baratoi ffeil json gyda disgrifiad o'n nodau. Sylwch, yn wahanol i osod ar weinyddion noeth, mae'r ffeil yn nodi'r porthladd y mae vbmc yn rhedeg arno ar gyfer pob peiriant.
[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:27Sylwch: mae gan y nod rheoli ddau ryngwyneb, ond yn yr achos hwn nid yw hyn yn bwysig, yn y gosodiad hwn bydd un yn ddigon i ni.
Nawr rydyn ni'n paratoi'r ffeil json. Mae angen i ni nodi cyfeiriad pabi'r porthladd y bydd y ddarpariaeth yn cael ei wneud trwyddo, paramedrau'r nodau, rhoi enwau iddynt a nodi sut i gyrraedd 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"
}
]
}Nawr mae angen i ni baratoi delweddau ar gyfer eironig. I wneud hyn, lawrlwythwch nhw trwy wget a'u gosod:
(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 ~]$Wrthi'n uwchlwytho lluniau i 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 ~]$Gwirio bod yr holl ddelweddau wedi'u llwytho
(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 ~]$Un peth arall - mae angen i chi ychwanegu gweinydd DNS:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nawr gallwn roi'r gorchymyn ar gyfer mewnsylliad:
(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 ~]$Fel y gwelwch o'r allbwn, cwblhawyd popeth heb wallau. Gadewch i ni wirio bod pob nod yn y cyflwr sydd ar gael:
(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 ~]$ Os yw'r nodau mewn cyflwr gwahanol, fel arfer yn hylaw, yna aeth rhywbeth o'i le ac mae angen i chi edrych ar y log a darganfod pam y digwyddodd hyn. Cofiwch ein bod yn defnyddio rhithwiroli yn y senario hwn ac efallai y bydd bygiau'n gysylltiedig â defnyddio peiriannau rhithwir neu vbmc.
Nesaf, mae angen i ni nodi pa nod fydd yn cyflawni pa swyddogaeth - hynny yw, nodi'r proffil y bydd y nod yn ei ddefnyddio:
(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 ~]$Nodwch y proffil ar gyfer pob nod:
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-d9afb69d1167Gadewch i ni wirio ein bod wedi gwneud popeth yn gywir:
(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 ~]$Os yw popeth yn gywir, rydyn ni'n rhoi'r gorchymyn i ddefnyddio 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 qemuMewn gosodiad go iawn, bydd templedi wedi'u haddasu yn cael eu defnyddio'n naturiol, yn ein hachos ni bydd hyn yn cymhlethu'r broses yn fawr, gan y bydd yn rhaid esbonio pob golygiad yn y templed. Fel yr ysgrifennwyd yn gynharach, bydd hyd yn oed gosodiad syml yn ddigon i ni weld sut mae'n gweithio.
Sylwch: mae'r newidyn qemu --libvirt-type yn angenrheidiol yn yr achos hwn, gan y byddwn yn defnyddio rhithwiroli nythu. Fel arall, ni fyddwch yn gallu rhedeg peiriannau rhithwir.
Nawr mae gennych chi tua awr, neu efallai mwy (yn dibynnu ar alluoedd y caledwedd) a dim ond gobeithio y byddwch chi'n gweld y neges ganlynol ar ôl yr amser hwn:
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 ~]$Nawr mae gennych chi fersiwn llawn bron o Openstack, y gallwch chi ei astudio, arbrofi, ac ati.
Gadewch i ni wirio bod popeth yn gweithio'n iawn. Yn pentwr cyfeiriadur cartref y defnyddiwr mae dwy ffeil - un stackrc (ar gyfer rheoli undercloud) a'r ail overcloudrc (ar gyfer rheoli overcloud). Rhaid nodi'r ffeiliau hyn fel ffynhonnell, gan eu bod yn cynnwys gwybodaeth sy'n angenrheidiol ar gyfer dilysu.
(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 ~]$Mae angen un cyffyrddiad bach o hyd ar gyfer fy gosodiad - ychwanegu llwybr ar y rheolydd, gan fod y peiriant yr wyf yn gweithio ag ef ar rwydwaith gwahanol. I wneud hyn, ewch i control-1 o dan y cyfrif gweinyddwr gwres a chofrestrwch y llwybr
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Wel, nawr gallwch chi fynd i'r gorwel. Mae'r holl wybodaeth - cyfeiriadau, mewngofnodi a chyfrinair - yn y ffeil /home/stack/overcloudrc. Mae'r diagram terfynol yn edrych fel hyn:
Gyda llaw, yn ein gosodiad, cyhoeddwyd cyfeiriadau peiriannau trwy DHCP ac, fel y gwelwch, fe'u cyhoeddir “ar hap”. Gallwch ddiffinio'n fanwl yn y templed pa gyfeiriad y dylid ei atodi i ba beiriant yn ystod y defnydd, os oes ei angen arnoch.
Sut mae traffig yn llifo rhwng peiriannau rhithwir?
Yn yr erthygl hon byddwn yn edrych ar dri opsiwn ar gyfer traffig sy'n mynd heibio
- Dau beiriant ar un hypervisor ar un rhwydwaith L2
- Dau beiriant ar hypervisors gwahanol ar yr un rhwydwaith L2
- Dau beiriant ar rwydweithiau gwahanol (gwreiddio traws-rwydwaith)
Achosion sydd â mynediad i'r byd y tu allan trwy rwydwaith allanol, gan ddefnyddio cyfeiriadau symudol, yn ogystal â llwybro dosbarthedig, byddwn yn ystyried y tro nesaf, am y tro byddwn yn canolbwyntio ar draffig mewnol.
I wirio, gadewch i ni lunio'r diagram canlynol:
Rydym wedi creu 4 peiriant rhithwir - 3 ar un rhwydwaith L2 - net-1, ac 1 arall ar y rhwydwaith net-2
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Gadewch i ni weld ar ba hypervisors y mae'r peiriannau a grëwyd:
(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 ~]$
Mae peiriannau vm-1 a vm-3 wedi'u lleoli ar compute-0, mae peiriannau vm-2 a vm-4 wedi'u lleoli ar nod compute-1.
Yn ogystal, mae llwybrydd rhithwir wedi'i greu i alluogi llwybro rhwng y rhwydweithiau penodedig:
(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 ~]$ Mae gan y llwybrydd ddau borthladd rhithwir, sy'n gweithredu fel pyrth ar gyfer rhwydweithiau:
(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 ~]$ Ond cyn i ni edrych ar sut mae'r traffig yn llifo, gadewch i ni edrych ar yr hyn sydd gennym ar hyn o bryd ar y nod rheoli (sydd hefyd yn nod rhwydwaith) ac ar y nod cyfrifo. Gadewch i ni ddechrau gyda'r nod cyfrifo.
[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 ~]$Ar hyn o bryd, mae gan y nod dair pont ovs - br-int, br-tun, br-ex. Rhyngddynt, fel y gwelwn, mae set o ryngwynebau. Er hwylustod, gadewch i ni blotio'r holl ryngwynebau hyn ar y diagram a gweld beth sy'n digwydd.
Wrth edrych ar y cyfeiriadau y codir twneli VxLAN iddynt, gellir gweld bod un twnnel yn cael ei godi i gyfrifo-1 (192.168.255.26), mae'r ail dwnnel yn edrych i reoli-1 (192.168.255.15). Ond y peth mwyaf diddorol yw nad oes gan br-ex ryngwynebau corfforol, ac os edrychwch ar ba lifau sydd wedi'u ffurfweddu, gallwch weld mai dim ond ar hyn o bryd y gall y bont hon ollwng traffig.
[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 ~]$ Fel y gwelwch o'r allbwn, caiff y cyfeiriad ei sgriwio'n uniongyrchol i'r porthladd ffisegol, ac nid i'r rhyngwyneb rhithwir bont.
[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 ~]$
Yn ôl y rheol gyntaf, rhaid taflu popeth a ddaeth o'r porthladd phy-br-ex.
Mewn gwirionedd, ar hyn o bryd nid oes unrhyw le arall i draffig ddod i mewn i'r bont hon ac eithrio o'r rhyngwyneb hwn (y rhyngwyneb â br-int), ac a barnu wrth y diferion, mae traffig BUM eisoes wedi hedfan i'r bont.
Hynny yw, dim ond trwy dwnnel VxLAN y gall traffig adael y nod hwn a dim byd arall. Fodd bynnag, os trowch y DVR ymlaen, bydd y sefyllfa'n newid, ond byddwn yn delio â hynny dro arall. Wrth ddefnyddio ynysu rhwydwaith, er enghraifft defnyddio vlans, ni fydd gennych un rhyngwyneb L3 yn vlan 0, ond sawl rhyngwyneb. Fodd bynnag, bydd traffig VxLAN yn gadael y nod yn yr un modd, ond hefyd wedi'i grynhoi mewn rhyw fath o vlan pwrpasol.
Rydyn ni wedi rhoi trefn ar y nod cyfrifo, gadewch i ni symud ymlaen i'r nod rheoli.
[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 ~]$Mewn gwirionedd, gallwn ddweud bod popeth yr un peth, ond nid yw'r cyfeiriad IP bellach ar y rhyngwyneb corfforol ond ar y bont rhithwir. Gwneir hyn oherwydd mai'r porthladd hwn yw'r porthladd y bydd traffig yn gadael i'r byd y tu allan drwyddo.
[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 ~]$ Mae'r porthladd hwn ynghlwm wrth y bont br-ex a chan nad oes tagiau vlan arno, mae'r porthladd hwn yn brif borthladd y caniateir pob vlan arno, nawr mae traffig yn mynd allan heb dag, fel y nodir gan vlan-id 0 yn y allbwn uchod.
Mae popeth arall ar hyn o bryd yn debyg i'r nod cyfrifo - yr un pontydd, yr un twneli yn mynd i ddau nod cyfrifiadurol.
Ni fyddwn yn ystyried nodau storio yn yr erthygl hon, ond er mwyn deall mae angen dweud bod rhan rhwydwaith y nodau hyn yn banal i'r pwynt o warth. Yn ein hachos ni, dim ond un porthladd ffisegol (eth0) sydd â chyfeiriad IP wedi'i neilltuo iddo a dyna ni. Nid oes unrhyw dwneli VxLAN, pontydd twnnel, ac ati - nid oes unrhyw ovs o gwbl, gan nad oes pwynt ynddo. Wrth ddefnyddio ynysu rhwydwaith, bydd gan y nod hwn ddau ryngwyneb (porthladdoedd corfforol, bodny, neu ddim ond dau vlan - does dim ots - mae'n dibynnu ar yr hyn rydych chi ei eisiau) - un ar gyfer rheoli, yr ail ar gyfer traffig (yn ysgrifennu i'r ddisg VM , darllen oddi ar ddisg, ac ati)
Fe wnaethom gyfrifo beth sydd gennym ar y nodau yn absenoldeb unrhyw wasanaethau. Nawr, gadewch i ni lansio 4 peiriant rhithwir a gweld sut mae'r cynllun a ddisgrifir uchod yn newid - dylem gael porthladdoedd, llwybryddion rhithwir, ac ati.
Hyd yn hyn mae ein rhwydwaith yn edrych fel hyn:
Mae gennym ddau beiriant rhithwir ar bob nod cyfrifiadur. Gan ddefnyddio compute-0 fel enghraifft, gadewch i ni weld sut mae popeth wedi'i gynnwys.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Dim ond un rhyngwyneb rhithwir sydd gan y peiriant - 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 ~]$
Mae'r rhyngwyneb hwn yn edrych yn y bont 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 ~]$ Fel y gwelwch o'r allbwn, dim ond dau ryngwyneb sydd yn y bont - tap95d96a75-a0 a qvb95d96a75-a0.
Yma mae'n werth aros ychydig ar y mathau o ddyfeisiau rhwydwaith rhithwir yn OpenStack:
vtap - rhyngwyneb rhithwir ynghlwm wrth enghraifft (VM)
qbr - pont Linux
qvb a qvo - pâr vEth wedi'i gysylltu â phont Linux a phont Agored vSwitch
br-int, br-tun, br-vlan—Agor pontydd vSwitch
patch-, int-br-, phy-br- - Rhyngwynebau clwt vSwitch agored sy'n cysylltu pontydd
qg, qr, ha, fg, sg - Agorwch borthladdoedd vSwitch a ddefnyddir gan ddyfeisiadau rhithwir i gysylltu ag OVS
Fel y deallwch, os oes gennym borthladd qvb95d96a75-a0 yn y bont, sef pâr vEth, yna rhywle mae ei gymar, y dylid ei alw'n rhesymegol qvo95d96a75-a0. Gawn ni weld pa borthladdoedd sydd ar 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 ~]$ Fel y gallwn weld, mae'r porthladd yn br-int. Mae Br-int yn gweithredu fel switsh sy'n terfynu porthladdoedd peiriant rhithwir. Yn ogystal â qvo95d96a75-a0, mae'r porthladd qvo5bd37136-47 yn weladwy yn yr allbwn. Dyma'r porthladd i'r ail beiriant rhithwir. O ganlyniad, mae ein diagram bellach yn edrych fel hyn:
Cwestiwn a ddylai fod o ddiddordeb i'r darllenydd sylwgar ar unwaith - beth yw'r bont linux rhwng y porthladd peiriant rhithwir a'r porthladd OVS? Y ffaith yw bod grwpiau diogelwch yn cael eu defnyddio i amddiffyn y peiriant, nad ydynt yn ddim mwy nag iptables. Nid yw OVS yn gweithio gydag iptables, felly dyfeisiwyd y “crutch” hwn. Fodd bynnag, mae'n dod yn anarferedig - mae conntrack yn ei ddisodli mewn datganiadau newydd.
Hynny yw, yn y pen draw mae'r cynllun yn edrych fel hyn:
Dau beiriant ar un hypervisor ar un rhwydwaith L2
Gan fod y ddau VM hyn wedi'u lleoli ar yr un rhwydwaith L2 ac ar yr un hypervisor, bydd traffig rhyngddynt yn llifo'n rhesymegol yn lleol trwy br-int, gan y bydd y ddau beiriant ar yr un 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 ~]$ Dau beiriant ar hypervisors gwahanol ar yr un rhwydwaith L2
Nawr, gadewch i ni weld sut y bydd y traffig yn mynd rhwng dau beiriant ar yr un rhwydwaith L2, ond wedi'i leoli ar wahanol hypervisors. I fod yn onest, ni fydd dim yn newid llawer, dim ond traffig rhwng hypervisors fydd yn mynd trwy dwnnel vxlan. Gadewch i ni edrych ar enghraifft.
Cyfeiriadau peiriannau rhithwir y byddwn yn gwylio traffig rhyngddynt:
[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 ~]$ Edrychwn ar y tabl anfon ymlaen yn br-int ar 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 ~]Dylai traffig fynd i borthladd 2 - gadewch i ni weld pa fath o borthladd ydyw:
[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 ~]$Mae hwn yn patch-tun - hynny yw, y rhyngwyneb yn br-tun. Gawn ni weld beth sy'n digwydd i'r pecyn ar 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 ~]$ Mae'r pecyn yn cael ei becynnu yn VxLAN a'i anfon i borthladd 2. Gadewch i ni weld lle mae porthladd 2 yn arwain:
[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 ~]$Mae hwn yn dwnnel vxlan ar 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 ~]$Gadewch i ni fynd i compute-1 a gweld beth sy'n digwydd nesaf gyda'r pecyn:
[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 ~]$ Mae Mac yn y tabl anfon ymlaen br-int ar compute-1, ac fel y gwelir o'r allbwn uchod, mae'n weladwy trwy borth 2, sef y porthladd tuag at 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:46Wel, yna gwelwn fod pabi cyrchfan yn br-int ar compute-1:
[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 ~]$ Hynny yw, bydd y pecyn a dderbynnir yn hedfan i borthladd 3, ac mae enghraifft peiriant rhithwir eisoes ar ei hôl hi -00000003.
Harddwch defnyddio Openstack ar gyfer dysgu ar seilwaith rhithwir yw y gallwn ddal traffig yn hawdd rhwng hypervisors a gweld beth sy'n digwydd ag ef. Dyma beth fyddwn ni'n ei wneud nawr, rhedeg tcpdump ar y porthladd vnet tuag at 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*******************Mae'r llinell gyntaf yn dangos bod Patek o gyfeiriad 10.0.1.85 yn mynd i gyfeiriad 10.0.1.88 (traffig ICMP), ac mae wedi'i lapio mewn pecyn VxLAN gyda vni 22 ac mae'r pecyn yn mynd o westeiwr 192.168.255.19 (cyfrifiadur-0) i gynnal 192.168.255.26 .1 (cyfrif- XNUMX ). Gallwn wirio bod y VNI yn cyfateb i'r un a nodir yn ofvs.
Gadewch i ni ddychwelyd i'r llinell hon gweithredoedd = llwyth: 0-> NXM_OF_VLAN_TCI[], llwytho: 0x16-> NXM_NX_TUN_ID[], allbwn: 2. Mae 0x16 yn vni mewn system rhif hecsadegol. Gadewch i ni drosi'r rhif hwn i'r 16fed system:
16 = 6*16^0+1*16^1 = 6+16 = 22Hynny yw, mae vni yn cyfateb i realiti.
Mae'r ail linell yn dangos traffig dychwelyd, wel, nid oes diben ei esbonio, mae popeth yn glir yno.
Dau beiriant ar rwydweithiau gwahanol (llwybrau rhyng-rwydwaith)
Yr achos olaf ar gyfer heddiw yw llwybro rhwng rhwydweithiau o fewn un prosiect gan ddefnyddio llwybrydd rhithwir. Rydym yn ystyried achos heb DVR (byddwn yn edrych arno mewn erthygl arall), felly mae llwybro yn digwydd ar nod y rhwydwaith. Yn ein hachos ni, nid yw'r nod rhwydwaith yn cael ei roi mewn endid ar wahân ac mae wedi'i leoli ar y nod rheoli.
Yn gyntaf, gadewch i ni weld bod llwybro yn gweithio:
$ 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 msGan fod yn rhaid i'r pecyn yn yr achos hwn fynd i'r porth a chael ei gyfeirio yno, mae angen i ni ddarganfod cyfeiriad MAC y porth, ac edrychwn ar y tabl ARP ar ei gyfer yn yr achos hwn:
$ 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 eth0Nawr gadewch i ni weld i ble y dylid anfon y traffig gyda'r cyrchfan (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 ~]$ Edrychwn ar ble mae porthladd 2 yn arwain:
[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 ~]$ Mae popeth yn rhesymegol, traffig yn mynd i br-tun. Gawn ni weld ym mha dwnnel vxlan y bydd yn cael ei lapio ynddo:
[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 ~]$ Twnnel vxlan yw'r trydydd porthladd:
[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 ~]$ Sy'n edrych ar y nod rheoli:
[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 ~]$ Mae'r traffig wedi cyrraedd y nod rheoli, felly mae angen inni fynd ato a gweld sut y bydd llwybro'n digwydd.
Fel y cofiwch, roedd y nod rheoli y tu mewn yn edrych yn union yr un fath â'r nod cyfrifo - yr un tair pont, dim ond br-ex oedd â phorthladd corfforol y gallai'r nod anfon traffig y tu allan drwyddo. Newidiodd creu achosion y ffurfweddiad ar y nodau cyfrifo - ychwanegwyd linux bridge, iptables a rhyngwynebau at y nodau. Gadawodd creu rhwydweithiau a llwybrydd rhithwir ei farc hefyd ar ffurfweddiad y nod rheoli.
Felly, mae'n amlwg bod yn rhaid i'r cyfeiriad MAC porth fod yn y bwrdd anfon ymlaen br-int ar y nod rheoli. Gadewch i ni wirio ei fod yno ac i ble mae'n edrych:
[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 ~]$ Mae'r Mac yn weladwy o borthladd qr-0c52b15f-8f. Os awn yn ôl at y rhestr o borthladdoedd rhithwir yn Openstack, defnyddir y math hwn o borthladd i gysylltu dyfeisiau rhithwir amrywiol i OVS. I fod yn fwy manwl gywir, mae qr yn borthladd i'r llwybrydd rhithwir, sy'n cael ei gynrychioli fel gofod enw.
Gawn ni weld pa ofodau enwau sydd ar y gweinydd:
[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 ~]$ Cymaint a thri chopi. Ond a barnu wrth yr enwau, gallwch ddyfalu pwrpas pob un ohonynt. Byddwn yn dychwelyd i achosion gydag ID 0 ac 1 yn ddiweddarach, nawr mae gennym ddiddordeb mewn gofod enwau 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 ~]$ Mae'r gofod enw hwn yn cynnwys dau o rai mewnol a grëwyd gennym yn gynharach. Mae'r ddau borthladd rhithwir wedi'u hychwanegu at br-int. Gadewch i ni wirio cyfeiriad mac y porthladd qr-0c52b15f-8f, ers i'r traffig, a barnu yn ôl y cyfeiriad mac cyrchfan, fynd i'r rhyngwyneb hwn.
[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 ~]$ Hynny yw, yn yr achos hwn, mae popeth yn gweithio yn unol â chyfreithiau llwybro safonol. Gan fod y traffig i fod ar gyfer gwesteiwr 10.0.2.8, rhaid iddo adael trwy'r ail ryngwyneb qr-92fa49b5-54 a mynd trwy'r twnnel vxlan i'r nod cyfrifo:
[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 ~]$ Mae popeth yn rhesymegol, dim syndod. Gadewch i ni weld lle mae cyfeiriad pabi gwesteiwr 10.0.2.8 i'w weld yn 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 ~]$ Yn ôl y disgwyl, mae traffig yn mynd i br-tun, gadewch i ni weld i ba dwnnel mae'r traffig yn mynd nesaf:
[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 ~]$ Mae traffig yn mynd i mewn i'r twnnel i gyfrifo-1. Wel, ar compute-1 mae popeth yn syml - o br-tun mae'r pecyn yn mynd i br-int ac oddi yno i'r rhyngwyneb peiriant rhithwir:
[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 ~]$ Gadewch i ni wirio mai hwn yn wir yw'r rhyngwyneb cywir:
[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 ~]$
Mewn gwirionedd, aethom yr holl ffordd drwy'r pecyn. Rwy'n meddwl ichi sylwi bod y traffig wedi mynd trwy wahanol dwneli vxlan ac wedi gadael gyda gwahanol VNIs. Gadewch i ni weld pa fath o VNI yw'r rhain, ac ar ôl hynny byddwn yn casglu domen ar borthladd rheoli'r nod a sicrhau bod y traffig yn llifo'n union fel y disgrifir uchod.
Felly, mae gan y twnnel i gyfrifo-0 y camau gweithredu canlynol = llwyth: 0-> NXM_OF_VLAN_TCI[], llwyth: 0x16-> NXM_NX_TUN_ID[], allbwn: 3. Gadewch i ni drosi 0x16 i'r system rhif degol:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Mae gan y twnnel i gyfrifo-1 y VNI canlynol: gweithredoedd = llwyth: 0-> NXM_OF_VLAN_TCI[],llwyth: 0x63-> NXM_NX_TUN_ID[], allbwn: 2. Gadewch i ni drosi 0x63 i'r system rhif degol:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Wel, nawr gadewch i ni edrych ar y domen:
[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*******************Mae'r pecyn cyntaf yn becyn vxlan o westeiwr 192.168.255.19 (cyfrifiadur-0) i gynnal 192.168.255.15 (rheolaeth-1) gyda vni 22, y tu mewn y mae pecyn ICMP wedi'i becynnu o westeiwr 10.0.1.85 i westeiwr 10.0.2.8. Fel y cyfrifasom uchod, y mae vni yn cyfateb i'r hyn a welsom yn yr allbwn.
Mae'r ail becyn yn becyn vxlan o westeiwr 192.168.255.15 (rheolaeth-1) i gynnal 192.168.255.26 (cyfrifiadur-1) gyda vni 99, y tu mewn y mae pecyn ICMP wedi'i becynnu o westeiwr 10.0.1.85 i westeiwr 10.0.2.8. Fel y cyfrifasom uchod, y mae vni yn cyfateb i'r hyn a welsom yn yr allbwn.
Mae'r ddau becyn nesaf yn draffig dychwelyd o 10.0.2.8 nid 10.0.1.85.
Hynny yw, yn y diwedd cawsom y cynllun nodau rheoli canlynol:
Edrych fel dyna ni? Rydym wedi anghofio tua dau ofod enw:
[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 ~]$ Wrth i ni siarad am bensaernïaeth y llwyfan cwmwl, byddai'n dda pe bai peiriannau'n derbyn cyfeiriadau yn awtomatig gan weinydd DHCP. Dyma ddau weinydd DHCP ar gyfer ein dau rwydwaith 10.0.1.0/24 a 10.0.2.0/24.
Gadewch i ni wirio bod hyn yn wir. Dim ond un cyfeiriad sydd yn y gofod enw hwn - 10.0.1.1 - cyfeiriad y gweinydd DHCP ei hun, ac mae hefyd wedi'i gynnwys yn 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 0Gadewch i ni weld a yw prosesau sy'n cynnwys qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 yn eu henw ar y nod rheoli:
[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 ~]$ Mae proses o’r fath ac yn seiliedig ar y wybodaeth a gyflwynir yn yr allbwn uchod, gallwn, er enghraifft, weld beth sydd gennym ar hyn o bryd ar gyfer rhent:
[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 ~]$O ganlyniad, rydym yn cael y set ganlynol o wasanaethau ar y nod rheoli:
Wel, cofiwch - dim ond 4 peiriant yw hyn, 2 rwydwaith mewnol ac un llwybrydd rhithwir ... Nid oes gennym rwydweithiau allanol yma nawr, criw o wahanol brosiectau, pob un â'i rwydweithiau ei hun (sy'n gorgyffwrdd), ac mae gennym ni llwybrydd dosbarthedig wedi'i ddiffodd, ac yn y diwedd Wedi'r cyfan, dim ond un nod rheoli oedd yn y fainc prawf (ar gyfer goddefgarwch bai mae'n rhaid bod cworwm o dri nod). Mae'n rhesymegol bod popeth mewn masnach "ychydig" yn fwy cymhleth, ond yn yr enghraifft syml hon rydym yn deall sut y dylai weithio - mae p'un a oes gennych 3 neu 300 o ofodau enwau yn bwysig wrth gwrs, ond o safbwynt gweithrediad y cyfan. strwythur, ni fydd unrhyw beth yn newid llawer ... ond hyd nes na fyddwch yn plygio rhywfaint o SDN gwerthwr i mewn. Ond mae honno'n stori hollol wahanol.
Rwy'n gobeithio ei fod yn ddiddorol. Os oes gennych unrhyw sylwadau/ychwanegiadau, neu rywle y gwnes i ddweud celwydd llwyr (dwi’n ddynol a bydd fy marn yn oddrychol bob amser) – ysgrifennwch beth sydd angen ei gywiro/ychwanegu – byddwn yn cywiro/ychwanegu popeth.
I gloi, hoffwn ddweud ychydig eiriau am gymharu Openstack (fanila a gwerthwr) gyda'r datrysiad cwmwl gan VMWare - mae'r cwestiwn hwn wedi cael ei ofyn i mi yn rhy aml dros yr ychydig flynyddoedd diwethaf ac, a dweud y gwir, rwy'n eisoes wedi blino arno, ond yn dal i fod. Yn fy marn i, mae'n anodd iawn cymharu'r ddau ateb hyn, ond gallwn ddweud yn bendant bod anfanteision yn y ddau ddatrysiad ac wrth ddewis un ateb mae angen i chi bwyso a mesur y manteision a'r anfanteision.
Os yw OpenStack yn ateb sy'n cael ei yrru gan y gymuned, yna mae gan VMWare yr hawl i wneud dim ond yr hyn y mae ei eisiau (darllenwch - beth sy'n broffidiol iddo) ac mae hyn yn rhesymegol - oherwydd ei fod yn gwmni masnachol sydd wedi arfer gwneud arian gan ei gleientiaid. Ond mae un mawr a braster OND - gallwch ddod oddi ar OpenStack, er enghraifft o Nokia, a heb fawr o gost newid i ateb o, er enghraifft, Juniper (Contrail Cloud), ond mae'n annhebygol y byddwch yn gallu dod oddi ar VMWare . I mi, mae'r ddau ddatrysiad hyn yn edrych fel hyn - mae Openstack (gwerthwr) yn gawell syml y cewch eich rhoi ynddo, ond mae gennych allwedd a gallwch chi adael ar unrhyw adeg. Mae VMWare yn gawell euraidd, mae gan y perchennog yr allwedd i'r cawell a bydd yn costio llawer i chi.
Nid wyf yn hyrwyddo naill ai'r cynnyrch cyntaf na'r ail - chi sy'n dewis yr hyn sydd ei angen arnoch chi. Ond pe bai gen i ddewis o'r fath, byddwn yn dewis y ddau ateb - VMWare ar gyfer y cwmwl TG (llwythi isel, rheolaeth hawdd), OpenStack gan rai gwerthwr (mae Nokia a Juniper yn darparu atebion un contractwr da iawn) - ar gyfer y cwmwl Telecom. Ni fyddwn yn defnyddio Openstack ar gyfer TG pur - mae fel saethu adar y to gyda canon, ond nid wyf yn gweld unrhyw wrtharwyddion i'w ddefnyddio ac eithrio colli swydd. Fodd bynnag, mae defnyddio VMWare mewn telathrebu fel tynnu cerrig mâl mewn Ford Raptor - mae'n brydferth o'r tu allan, ond mae'n rhaid i'r gyrrwr wneud 10 taith yn lle un.
Yn fy marn i, anfantais fwyaf VMWare yw ei gau yn llwyr - ni fydd y cwmni'n rhoi unrhyw wybodaeth i chi am sut mae'n gweithio, er enghraifft, vSAN neu beth sydd yn y cnewyllyn hypervisor - yn syml, nid yw'n broffidiol ar ei gyfer - hynny yw, byddwch yn gwneud hynny. peidiwch byth â dod yn arbenigwr ar VMWare - heb gefnogaeth gwerthwr, rydych chi'n doomed (yn aml iawn rydw i'n cwrdd ag arbenigwyr VMWare sy'n cael eu drysu gan gwestiynau dibwys). I mi, mae VMWare yn prynu car gyda'r cwfl wedi'i gloi - ie, efallai y bydd gennych arbenigwyr a all newid y gwregys amseru, ond dim ond yr un a werthodd yr ateb hwn i chi all agor y cwfl. Yn bersonol, nid wyf yn hoffi atebion na allaf ffitio iddynt. Byddwch yn dweud efallai na fydd yn rhaid i chi fynd o dan y cwfl. Ydy, mae hyn yn bosibl, ond edrychaf arnoch pan fydd angen i chi gydosod swyddogaeth fawr yn y cwmwl o 20-30 o beiriannau rhithwir, 40-50 o rwydweithiau, y mae hanner ohonynt eisiau mynd y tu allan, ac mae'r ail hanner yn gofyn am Cyflymiad SR-IOV, fel arall bydd angen mwy neu ddau ddwsin o'r ceir hyn arnoch chi - fel arall ni fydd y perfformiad yn ddigon.
Mae yna safbwyntiau eraill, felly dim ond chi all benderfynu beth i'w ddewis ac, yn bwysicaf oll, chi fydd wedyn yn gyfrifol am eich dewis. Dim ond fy marn i yw hyn - person sydd wedi gweld a chyffwrdd o leiaf 4 cynnyrch - Nokia, Juniper, Red Hat a VMWare. Hynny yw, mae gen i rywbeth i gymharu ag e.
Ffynhonnell: hab.com