Cloud computing dringt djipper en djipper yn ús libben troch en d'r is wierskynlik net ien persoan dy't op syn minst ien kear gjin wolktsjinsten hat brûkt. Wat in wolk krekt is en hoe't it wurket, witte in pear minsken, sels op it nivo fan in idee. 5G wurdt al in realiteit en de telekom-ynfrastruktuer begjint te ferpleatsen fan pylder-oplossingen nei wolk-oplossingen, krekt sa't it die doe't it ferhuze fan folslein hardware-oplossingen nei virtualisearre "pylders".
Hjoed sille wy prate oer de ynderlike wrâld fan wolk ynfrastruktuer, benammen wy sille sjen nei de basis fan it netwurk diel.
Wat is in wolk? Deselde virtualisaasje - profyl werjefte?
Mear as in logyske fraach. Nee - dit is gjin virtualisaasje, hoewol it net sûnder koe dien wurde. Litte wy nei twa definysjes sjen:
Cloud Computing (hjirnei oantsjutten as Cloud) is in model foar it jaan fan brûkerfreonlike tagong ta ferspraat komputerboarnen dy't moatte wurde ynset en lansearre op fraach mei de leechst mooglike latency en minimale kosten foar de tsjinstferliener.
Virtualisaasje - dit is de mooglikheid om ien fysike entiteit (bygelyks in tsjinner) te ferdielen yn ferskate firtuele, en dêrmei it brûken fan boarnen te fergrutsjen (jo hienen bygelyks 3 servers laden op 25-30 prosint, nei virtualisaasje krije jo 1 server laden op 80-90 prosint). Natuerlik yt virtualisaasje wat fan 'e boarnen op - jo moatte de hypervisor fiede, lykwols, lykas de praktyk hat sjen litten, is it spultsje de kears wurdich. In ideaal foarbyld fan virtualisaasje is VMWare, dy't perfekt taret firtuele masines, of bygelyks KVM, dat ik leaver, mar dit is in kwestje fan smaak.
Wy brûke virtualisaasje sûnder it te realisearjen, en sels izeren routers brûke al virtualisaasje - bygelyks yn 'e lêste ferzje fan JunOS wurdt it bestjoeringssysteem ynstalleare as in firtuele masine boppe op in real-time Linux-distribúsje (Wind River 9). Mar virtualisaasje is net de wolk, mar de wolk kin net bestean sûnder virtualisaasje.
Virtualisaasje is ien fan 'e boustiennen dêr't de wolk op boud is.
In wolk meitsje troch gewoan ferskate hypervisors yn ien L2-domein te sammeljen, in pear yaml-spielboeken ta te foegjen foar automatysk registrearjen fan vlans fia in soarte fan ansible en jammen wat as in orkestraasjesysteem op it allegear foar it automatysk meitsjen fan firtuele masines sil net wurkje. It sil krekter wêze, mar de resultearjende Frankenstein is net de wolk dy't wy nedich binne, hoewol it de ultime dream foar oaren kin wêze. Boppedat, as jo nimme deselde Openstack, it is yn wêzen noch Frankenstein, mar ach, lit ús net prate oer dat foar no.
Mar ik begryp dat út de hjirboppe presintearre definysje net hielendal dúdlik is wat eins in wolk neamd wurde kin.
Dêrom leveret in dokumint fan NIST (National Institute of Standards and Technology) 5 haadkenmerken dy't in wolkynfrastruktuer moat hawwe:
It jaan fan tsjinst op oanfraach. De brûker moat fergees tagong krije ta de oan him tawiisde komputerboarnen (lykas netwurken, firtuele skiven, ûnthâld, prosessorkearnen, ensfh.), En dizze boarnen moatte automatysk levere wurde - dat is sûnder yntervinsje fan 'e tsjinstferliener.
Wide beskikberens fan tsjinst. Tagong ta middels moatte wurde levere troch standertmeganismen om it gebrûk fan sawol standert PC's as tinne kliïnten en mobile apparaten mooglik te meitsjen.
Boarnen kombinearje yn puollen. Boarnepools moatte tagelyk boarnen kinne leverje oan meardere kliïnten, en soargje derfoar dat kliïnten isolearre binne en frij binne fan ûnderlinge ynfloed en konkurrinsje foar boarnen. Netwurken binne ek opnommen yn 'e swimbaden, wat de mooglikheid oanjout om oerlappende adressering te brûken. Pools moatte op fraach skaalber wêze kinne. It gebrûk fan swimbaden makket it mooglik om it nedige nivo fan boarnefouttolerânsje en abstraksje fan fysike en firtuele boarnen te leverjen - de ûntfanger fan 'e tsjinst wurdt gewoanlik foarsjoen fan de set fan boarnen dy't hy frege (wêr't dizze boarnen fysyk lizze, op hoefolle servers en switches - it makket neat út foar de kliïnt). Wy moatte lykwols rekken hâlde mei it feit dat de provider moat soargje foar transparante reservearring fan dizze middels.
Fluch oanpassing oan ferskate betingsten. Tsjinsten moatte fleksibel wêze - rappe foarsjenning fan boarnen, har werferdieling, tafoegjen of ferminderjen fan boarnen op fersyk fan 'e kliïnt, en fan' e kant fan 'e kliïnt moat d'r in gefoel wêze dat de wolkboarnen einleaze binne. Foar gemak fan ferstân, bygelyks, sjogge jo gjin warskôging dat in diel fan jo skiifromte yn Apple iCloud is ferdwûn, om't de hurde skiif op 'e tsjinner is ôfbrutsen, en skiven brekke. Derneist, fan jo kant, binne de mooglikheden fan dizze tsjinst hast ûnbeheind - jo hawwe 2 TB nedich - gjin probleem, jo hawwe it betelle en ûntfongen. In ferlykber foarbyld kin jûn wurde mei Google.Drive of Yandex.Disk.
Mooglikheid om te mjitten de levere tsjinst. Wolksystemen moatte konsumearre boarnen automatysk kontrolearje en optimalisearje, en dizze meganismen moatte transparant wêze foar sawol de brûker as de tsjinstferliener. Dat is, jo kinne altyd kontrolearje hoefolle boarnen jo en jo kliïnten konsumearje.
It is it wurdich te beskôgjen dat dizze easken meast easken binne foar in iepenbiere wolk, dus foar in privee wolk (dat is in wolk lansearre foar de ynterne behoeften fan it bedriuw), kinne dizze easken wat oanpast wurde. Se moatte lykwols noch dien wurde, oars krije wy net alle foardielen fan cloud computing.
Wêrom hawwe wy in wolk nedich?
Lykwols, elke nije as besteande technology, elk nij protokol wurdt makke foar wat (goed, útsein RIP-ng, fansels). Nimmen hat in protokol nedich om 'e wille fan in protokol (goed, útsein RIP-ng, fansels). It is logysk dat de Cloud is makke om in soarte fan tsjinst te leverjen oan de brûker / kliïnt. Wy binne allegear bekend mei op syn minst in pear wolktsjinsten, bygelyks Dropbox of Google.Docs, en ik leau dat de measte minsken se mei súkses brûke - dit artikel is bygelyks skreaun mei de Google.Docs-wolktsjinst. Mar de wolktsjinsten dy't wy kenne binne mar in diel fan 'e mooglikheden fan 'e wolk - krekter, se binne allinich in SaaS-type tsjinst. Wy kinne in wolktsjinst op trije manieren leverje: yn 'e foarm fan SaaS, PaaS of IaaS. Hokker tsjinst jo nedich hawwe hinget ôf fan jo winsken en mooglikheden.
Litte wy elk yn folchoarder besjen:
Software as tsjinst (SaaS) is in model foar it leverjen fan in folsleine tsjinst oan 'e kliïnt, bygelyks in e-posttsjinst lykas Yandex.Mail of Gmail. Yn dit model foar tsjinstferliening dogge jo, as klant, eins neat útsein it brûken fan de tsjinsten - dat is, jo hoege net te tinken oer it opsetten fan de tsjinst, syn skuldtolerânsje of oerstalligens. It wichtichste is om jo wachtwurd net te kompromittearjen; de provider fan dizze tsjinst sil de rest foar jo dwaan. Fanút it eachpunt fan 'e tsjinstferliener is hy folslein ferantwurdlik foar de heule tsjinst - fan serverhardware en hostbestjoeringssystemen oant database- en softwareynstellingen.
Platfoarm as tsjinst (PaaS) - as jo dit model brûke, leveret de tsjinstferliener de kliïnt in wurkstik foar de tsjinst, lit ús bygelyks in webtsjinner nimme. De tsjinstferliener joech de kliïnt in firtuele tsjinner (yn feite, in set fan boarnen, lykas RAM / CPU / Storage / Nets, ensfh.), En sels ynstalleare it OS en de nedige software op dizze tsjinner, lykwols, de konfiguraasje fan dit alles wurdt dien troch de klant sels en foar it útfieren fan de tsjinst antwurdet de klant. De tsjinstferliener, lykas yn it foarige gefal, is ferantwurdlik foar de prestaasjes fan fysike apparatuer, hypervisors, de firtuele masine sels, syn netwurkbeskikberens, ensfh., Mar de tsjinst sels is net mear yn har ferantwurdlikensgebiet.
Ynfrastruktuer as tsjinst (IaaS) - dizze oanpak is al nijsgjirriger, feitlik biedt de tsjinstferliener de klant in folsleine virtualisearre ynfrastruktuer - dat is wat set (pool) fan boarnen, lykas CPU Cores, RAM, Networks, ensfh. Al it oare is oan de klant - wat de klant wol dwaan mei dizze middels binnen de tawiisd pool (kwota) - it is net bysûnder wichtich foar de leveransier. Oft de klant syn eigen vEPC wol oanmeitsje of sels in mini-operator meitsje en kommunikaasjetsjinsten leverje - gjin fraach - doch it. Yn sa'n senario is de tsjinstferliener ferantwurdlik foar it leverjen fan boarnen, har fouttolerânsje en beskikberens, lykas it OS dat har mooglik makket om dizze boarnen te sammeljen en beskikber te meitsjen foar de klant mei de mooglikheid om boarnen op elk momint te fergrutsjen of te ferminderjen op fersyk fan de klant. De kliïnt konfigurearret alle firtuele masines en oare klatergoud sels fia it selsbestjoersportaal en konsole, ynklusyf it ynstellen fan netwurken (útsein foar eksterne netwurken).
Wat is OpenStack?
Yn alle trije opsjes hat de tsjinstferliener in OS nedich dat it meitsjen fan in wolkynfrastruktuer mooglik makket. Yn feite, mei SaaS is mear as ien divyzje ferantwurdlik foar de heule stapel technologyen - d'r is in divyzje dy't ferantwurdlik is foar de ynfrastruktuer - dat is, it leveret IaaS oan in oare divyzje, dizze divyzje leveret SaaS oan 'e klant. OpenStack is ien fan 'e wolkbestjoeringssystemen wêrmei jo in boskje skeakels, servers en opslachsystemen kinne sammelje yn ien boarnepool, dizze mienskiplike swimbad splitsje yn subpools (hierders) en dizze boarnen leverje oan kliïnten oer it netwurk.
OpenStack is in wolk bestjoeringssysteem wêrmei jo te kontrolearjen grutte puollen fan kompjûter boarnen, gegevens opslach en netwurk boarnen, foarsjoen en beheard fia API mei help fan standert autentikaasje meganismen.
Mei oare wurden, dit is in set fan fergese softwareprojekten dy't is ûntworpen om wolktsjinsten (sawol iepenbier as partikulier) te meitsjen - dat is in set ark wêrmei jo server- en wikselapparatuer kinne kombinearje yn ien pool fan boarnen, beheare dizze middels, it jaan fan it nedige nivo fan skuld tolerânsje.
Op it momint fan it skriuwen fan dit materiaal sjocht de OpenStack-struktuer der sa út:
Foto nommen út
Elk fan 'e komponinten opnommen yn OpenStack fiert in spesifike funksje. Dizze ferdielde arsjitektuer lit jo de set funksjonele komponinten dy't jo nedich hawwe yn 'e oplossing opnimme. Guon komponinten binne lykwols root-komponinten en har fuortheljen sil liede ta folsleine of foar in part inoperabiliteit fan 'e oplossing as gehiel. Dizze komponinten wurde normaal klassifisearre as:
- dashboard - Web-basearre GUI foar it behearen fan OpenStack-tsjinsten
- Keystone is in sintralisearre identiteitstsjinst dy't autentikaasje- en autorisaasjefunksjonaliteit leveret foar oare tsjinsten, lykas ek it behearen fan brûkersbewizen en har rollen.
- Neutron - in netwurktsjinst dy't ferbining leveret tusken de ynterfaces fan ferskate OpenStack-tsjinsten (ynklusyf ferbining tusken VM's en har tagong ta de bûtenwrâld)
- Cinder - jout tagong ta blok opslach foar firtuele masines
- nova - libbenssyklusbehear fan firtuele masines
- Eachopslach - repository fan ôfbyldings en snapshots fan firtuele masines
- Swift - jout tagong ta it opslachobjekt
- Ceilometer - in tsjinst dy't de mooglikheid biedt om telemetry te sammeljen en beskikbere en konsumeare boarnen te mjitten
- Hjitte - orkestraasje basearre op sjabloanen foar automatyske oanmeitsjen en foarsjenning fan boarnen
In folsleine list fan alle projekten en har doel kin wurde besjoen .
Elke OpenStack-komponint is in tsjinst dy't in spesifike funksje útfiert en in API leveret om dy funksje te behearjen en te ynteraksje mei oare tsjinsten foar wolkbestjoeringssysteem om in unifoarme ynfrastruktuer te meitsjen. Nova leveret bygelyks kompjûterboarnenbehear en in API foar tagong ta it konfigurearjen fan dizze boarnen, Glance leveret ôfbyldingsbehear en in API foar it behearen fan har, Cinder biedt blokopslach en in API foar it behearen, ensfh. Alle funksjes binne op in heul nauwe manier mei-inoar ferbûn.
As jo lykwols sjogge, binne alle tsjinsten dy't rinne yn OpenStack úteinlik in soarte fan firtuele masine (as kontener) ferbûn mei it netwurk. De fraach ûntstiet - wêrom hawwe wy safolle eleminten nedich?
Litte wy troch it algoritme gean foar it meitsjen fan in firtuele masine en it ferbinen mei it netwurk en oanhâldende opslach yn Openstack.
- As jo in fersyk meitsje om in masine te meitsjen, of it no in fersyk is fia Horizon (Dashboard) as in fersyk fia de CLI, it earste ding dat bart is de autorisaasje fan jo fersyk op Keystone - kinne jo in masine oanmeitsje, hat it de rjocht om dit netwurk te brûken, docht jo konseptkwota, ensfh.
- Keystone ferifiearret jo fersyk en genereart in authentic token yn it antwurdberjocht, dat fierder brûkt wurde sil. Nei't jo in antwurd fan Keystone krigen hawwe, wurdt it fersyk stjoerd nei Nova (nova api).
- Nova-api kontrolearret de jildichheid fan jo oanfraach troch kontakt op te nimmen mei Keystone mei it earder oanmakke auth token
- Keystone fiert autentikaasje en jout ynformaasje oer tagongsrjochten en beheiningen basearre op dit autentike token.
- Nova-api makket in yngong foar de nije VM yn nova-database en stjoert it fersyk om de masine te meitsjen oan nova-scheduler.
- Nova-scheduler selektearret de host (kompjûterknooppunt) wêrop de VM sil wurde ynset op basis fan de oantsjutte parameters, gewichten en sônes. In rekord fan dit en de VM ID wurde skreaun nei nova-database.
- Dêrnei kontaktet nova-scheduler nova-compute mei in fersyk om in eksimplaar yn te setten. Nova-compute kontakt nova-conductor om ynformaasje te krijen oer masineparameters (nova-conductor is in nova-elemint dat fungearret as in proxytsjinner tusken nova-database en nova-compute, en beheint it oantal oanfragen nei nova-database om problemen mei database te foarkommen reduksje fan konsistinsjelast).
- Nova-conductor ûntfangt de frege ynformaasje fan nova-database en jout it troch oan nova-compute.
- Folgjende, nova-compute ropt blik om de ôfbylding ID te krijen. Glace falidearret it fersyk yn Keystone en jout de frege ynformaasje werom.
- Nova-compute kontakten neutron te krijen ynformaasje oer netwurk parameters. Fergelykber mei blik, befêstiget neutron it fersyk yn Keystone, wêrnei't it in yngong makket yn 'e databank (havenidentifikaasje, ensfh.), in fersyk meitsje om in haven te meitsjen en de frege ynformaasje werom te jaan oan nova-compute.
- Nova-compute kontakten cinder mei in fersyk om tawize in folume oan de firtuele masine. Fergelykber mei blik, validearret cider it fersyk yn Keystone, makket in fersyk foar oanmeitsjen fan folume en jout de frege ynformaasje werom.
- Nova-compute kontakten libvirt mei in fersyk om in firtuele masine yn te setten mei de oantsjutte parameters.
Yn feite feroaret in skynber ienfâldige operaasje fan it meitsjen fan in ienfâldige firtuele masine yn sa'n draaikolk fan API-oproppen tusken eleminten fan it wolkplatfoarm. Boppedat, sa't jo sjen kinne, sels de earder oanwiisde tsjinsten besteane ek út lytsere komponinten tusken hokker ynteraksje optreedt. It meitsjen fan in masine is mar in lyts part fan wat it wolkplatfoarm jo kinne dwaan - d'r is in tsjinst ferantwurdlik foar it balansearjen fan ferkear, in tsjinst ferantwurdlik foar blokopslach, in tsjinst ferantwurdlik foar DNS, in tsjinst ferantwurdlik foar it leverjen fan bleate metalen tsjinners, ensfh. De wolk lit jo jo firtuele masines behannelje as in keppel skiep (yn tsjinstelling ta virtualisaasje). As der wat bart mei jo masine yn in firtuele omjouwing - jo restaurearje it fan backups, ensfh., mar wolkapplikaasjes binne sa boud dat de firtuele masine net sa'n wichtige rol spilet - de firtuele masine "stoar" - gjin probleem - in nij is krekt makke it reau is basearre op it sjabloan en, sa't se sizze, de squad net merken it ferlies fan 'e fighter. Natuerlik soarget dit foar de oanwêzigens fan orkestraasjemeganismen - mei help fan Heat-sjabloanen kinne jo maklik in komplekse funksje ynsette besteande út tsientallen netwurken en firtuele masines.
It is altyd it wurdich te hâlden dat d'r gjin wolkinfrastruktuer is sûnder in netwurk - elk elemint op ien of oare manier ynteraksje mei oare eleminten fia it netwurk. Derneist hat de wolk in absolút net-statysk netwurk. Natuerlik is it underlay-netwurk noch mear of minder statysk - nije knopen en skeakels wurde net alle dagen tafoege, mar de overlay-komponint kin en sil ûnûntkomber konstant feroarje - nije netwurken wurde tafoege of wiske, nije firtuele masines sille ferskine en âlde sille stjerre. En sa't jo ûnthâlde út 'e definysje fan' e wolk jûn oan it begjin fan it artikel, middels moatte wurde tawiisd oan de brûker automatysk en mei de minste (of better noch, sûnder) yntervinsje fan de tsjinst provider. Dat is, it type foarsjenning fan netwurkboarnen dy't no bestiet yn 'e foarm fan in front-end yn' e foarm fan jo persoanlik akkount tagonklik fia http/https en de tsjinstige netwurkyngenieur Vasily as in backend is gjin wolk, sels as Vasily hat acht hannen.
Neutron, as netwurktsjinst, leveret in API foar it behearen fan it netwurkdiel fan 'e wolkynfrastruktuer. De tsjinst macht en beheart it netwurkdiel fan Openstack troch in abstraksjelaach te leverjen neamd Network-as-a-Service (NaaS). Dat is, it netwurk is deselde firtuele mjitbere ienheid as bygelyks firtuele CPU-kearnen of it bedrach fan RAM.
Mar foardat jo trochgean nei de arsjitektuer fan it netwurkdiel fan OpenStack, litte wy beskôgje hoe't dit netwurk wurket yn OpenStack en wêrom it netwurk in wichtich en yntegraal diel fan 'e wolk is.
Dat wy hawwe twa RED client VM's en twa GREEN client VM's. Litte wy oannimme dat dizze masines op dizze manier op twa hypervisors sitte:
Op it stuit is dit gewoan virtualisaasje fan 4 tsjinners en neat mear, om't oant no ta alles wat wy dien hawwe is 4 tsjinners virtualisearje, en pleatse se op twa fysike tsjinners. En oant no ta binne se net iens ferbûn mei it netwurk.
Om in wolk te meitsjen, moatte wy ferskate komponinten tafoegje. Earst virtualisearje wy it netwurkdiel - wy moatte dizze 4 masines yn pearen ferbine, en de kliïnten wolle in L2-ferbining. Jo kinne brûk meitsje fan in switch en konfigurearje in romp yn syn rjochting en oplosse alles mei help fan in linux brêge of, foar mear avansearre brûkers, openvswitch (wy sille werom nei dit letter). Mar d'r kinne in protte netwurken wêze, en L2 konstant troch in skeakel drukke is net it bêste idee - d'r binne ferskate ôfdielingen, in servicedesk, moannen fan wachtsjen op in oanfraach om te foltôgjen, wiken fan probleemoplossing - yn 'e moderne wrâld is dit oanpak wurket net mear. En hoe earder in bedriuw dit begrypt, hoe makliker it is om foarút te gean. Dêrom sille wy tusken de hypervisors in L3-netwurk selektearje wêrmei ús firtuele masines sille kommunisearje, en boppe op dit L3-netwurk sille wy firtuele L2-overlay-netwurken bouwe wêr't it ferkear fan ús firtuele masines sil rinne. Jo kinne GRE, Geneve of VxLAN brûke as ynkapseling. Litte wy no rjochtsje op it lêste, hoewol it net bysûnder wichtich is.
Wy moatte locate VTEP earne (Ik hoopje dat elkenien is bekend mei VxLAN terminology). Sûnt wy hawwe in L3 netwurk komt direkt út de tsjinners, neat behinderet ús út in pleatsen VTEP op de tsjinners sels, en OVS (OpenvSwitch) is poerbêst op in dwaan dit. As gefolch hawwe wy dit ûntwerp krigen:
Sûnt ferkear tusken VM's moat wurde ferdield, sille de havens nei de firtuele masines ferskate vlannûmers hawwe. De tag nûmer spilet in rol allinnich binnen ien firtuele switch, sûnt doe't ynkapsele yn VxLAN kinne wy maklik fuortsmite, sûnt wy sille hawwe in VNI.
No kinne wy ús masines en firtuele netwurken foar har meitsje sûnder problemen.
Wat lykwols as de kliïnt in oare masine hat, mar is op in oar netwurk? Wy moatte rooting tusken netwurken. Wy sille sjen nei in ienfâldige opsje as sintralisearre routing wurdt brûkt - dat is, ferkear wurdt stjoerd troch spesjale tawijd netwurkknooppunten (goed, as regel wurde se kombineare mei kontrôleknooppunten, dus wy sille itselde ding hawwe).
It liket derop dat neat yngewikkeld is - wy meitsje in brêge-ynterface op 'e kontrôleknooppunt, ride ferkear dernei en dêrwei rûte wy it wêr't wy it nedich binne. Mar it probleem is dat de RED-kliïnt it 10.0.0.0/24-netwurk brûke wol, en de GREEN-kliïnt wol it 10.0.0.0/24-netwurk brûke. Dat is, wy begjinne adresromten te snijen. Derneist wolle kliïnten net dat oare kliïnten yn har ynterne netwurken kinne routerje, wat logysk is. Om de netwurken en kliïntgegevensferkear te skieden, sille wy elk fan har in aparte nammeromte tawize. Nammeromte is yn feite in kopy fan 'e Linux netwurk stack, dat is, kliïnten yn nammeromte RED binne folslein isolearre fan kliïnten út nammeromte GREEN (goed, óf routing tusken dizze client netwurken is tastien fia de standert nammeromte of op streamop ferfier apparatuer).
Dat is, wy krije it folgjende diagram:
L2-tunnels konvergearje fan alle komputerknooppunten nei it kontrôleknooppunt. knooppunt dêr't de L3 ynterface foar dizze netwurken leit, elk yn in tawijd nammeromte foar isolemint.
Wy fergeaten lykwols it wichtichste. De firtuele masine moat in tsjinst leverje oan 'e kliïnt, dat is, it moat op syn minst ien eksterne ynterface hawwe wêrmei't it kin wurde berikt. Dat is, wy moatte de bûtenwrâld yn. D'r binne hjir ferskate opsjes. Litte wy de ienfâldichste opsje dwaan. Wy sille ien netwurk tafoegje oan elke kliïnt, dy't jildich sil wêze yn it netwurk fan 'e provider en sil net oerlaapje mei oare netwurken. De netwurken kinne ek krusing en sjogge nei ferskate VRFs oan 'e kant fan it provider netwurk. De netwurkgegevens sille ek libje yn 'e nammeromte fan elke kliïnt. Lykwols, se sille noch útgean nei de bûtenwrâld fia ien fysike (of bân, dat is mear logyske) ynterface. Om klantferkear te skieden, sil ferkear dat bûten giet wurde tagged mei in VLAN-tag dy't oan 'e klant is tawiisd.
As resultaat krigen wy dit diagram:
In ridlike fraach is wêrom net poarten meitsje op 'e komputerknooppunten sels? Dit is net in grut probleem; boppedat, as jo de ferdielde router (DVR) ynskeakelje, sil dit wurkje. Yn dit senario beskôgje wy de ienfâldichste opsje mei in sintralisearre poarte, dy't standert brûkt wurdt yn Openstack. Foar funksjes mei hege lading sille se sawol in ferspraat router as fersnellingstechnologyen lykas SR-IOV en Passthrough brûke, mar sa't se sizze, dat is in folslein oar ferhaal. Lit ús earst omgean mei de basis diel, en dan geane wy yn 'e details.
Eins is ús skema al wurkber, mar d'r binne in pear nuânses:
- Wy moatte ús masines op ien of oare manier beskermje, dat is, in filter sette op 'e switch-ynterface nei de kliïnt.
- Meitsje it mooglik foar in firtuele masine om automatysk in IP-adres te krijen, sadat jo net elke kear moatte ynlogge fia de konsole en it adres registrearje.
Litte wy begjinne mei masinebeskerming. Hjirfoar kinne jo banale iptables brûke, wêrom net.
Dat is, no is ús topology wat komplisearre wurden:
Lit ús fierder gean. Wy moatte in DHCP-tsjinner tafoegje. It meast ideale plak om DHCP-tsjinners foar elke kliïnt te finen soe it hjirboppe neamde kontrôleknooppunt wêze, wêr't de nammeromten lizze:
D'r is lykwols in lyts probleem. Wat as alles opnij opstart en alle ynformaasje oer it hieren fan adressen op DHCP ferdwynt. It is logysk dat de masines krije nije adressen, dat is net hiel handich. D'r binne hjir twa manieren om hjir út te kommen - of brûk domeinnammen en foegje in DNS-tsjinner ta foar elke kliïnt, dan sil it adres foar ús net spesjaal wichtich wêze (lykas it netwurkdiel yn k8s) - mar d'r is in probleem mei eksterne netwurken, om't adressen kinne ek wurde útjûn yn harren fia DHCP - jo moatte syngronisaasje mei DNS tsjinners yn 'e wolk platfoarm en in eksterne DNS tsjinner, dy't nei myn miening is net hiel fleksibel, mar is hiel mooglik. Of de twadde opsje is om metadata te brûken - dat is, bewarje ynformaasje oer it adres dat is útjûn oan 'e masine, sadat de DHCP-tsjinner wit hokker adres oan' e masine moat wurde útjûn as de masine al in adres hat krigen. De twadde opsje is ienfâldiger en fleksibeler, om't jo ekstra ynformaasje oer de auto kinne bewarje. Litte wy no agentmetadata tafoegje oan it diagram:
In oar probleem dat ek de muoite wurdich is om te besprekken is de mooglikheid om ien ekstern netwurk te brûken troch alle kliïnten, om't eksterne netwurken, as se jildich moatte wêze yn it heule netwurk, lestich sille wêze - jo moatte de allocaasje fan dizze netwurken konstant allocearje en kontrolearje. De mooglikheid om in inkele eksterne foarkonfigureare netwurk te brûken foar alle kliïnten sil heul nuttich wêze by it meitsjen fan in iepenbiere wolk. Dit sil it makliker meitsje om masines yn te setten, om't wy gjin adresdatabase hoege te rieplachtsjen en in unike adresromte te selektearjen foar it eksterne netwurk fan elke klant. Derneist kinne wy foarôf in ekstern netwurk registrearje en op it momint fan ynset hoege wy allinich eksterne adressen te assosjearjen mei kliïntmasines.
En hjir komt NAT ús te helpen - wy sille it gewoan mooglik meitsje foar kliïnten om tagong te krijen ta de bûtenwrâld fia de standert nammeromte mei NAT-oersetting. No, hjir is in lyts probleem. Dit is goed as de client-tsjinner fungearret as in client en net as in server - dat wol sizze, it inisjearret ynstee fan ferbiningen te akseptearjen. Mar by ús sil it oarsom wêze. Yn dit gefal moatte wy bestimming NAT dwaan sadat by it ûntfangen fan ferkear de kontrôleknoop begrypt dat dit ferkear bedoeld is foar firtuele masine A fan kliïnt A, wat betsjut dat wy in NAT-oersetting moatte dwaan fan in ekstern adres, bygelyks 100.1.1.1 .10.0.0.1, nei in ynterne adres 100. Yn dit gefal, hoewol alle kliïnten itselde netwurk sille brûke, wurdt ynterne isolemint folslein bewarre bleaun. Dat is, wy moatte dNAT en sNAT dwaan op it kontrôleknooppunt. Of jo in inkeld netwurk brûke moatte mei driuwende adressen of eksterne netwurken, of beide tagelyk, hinget ôf fan wat jo yn 'e wolk wolle bringe. Wy sille gjin driuwende adressen tafoegje oan it diagram, mar sille de eksterne netwurken dy't al earder tafoege binne litte - elke kliïnt hat syn eigen eksterne netwurk (yn it diagram wurde se oanjûn as vlan 200 en XNUMX op 'e eksterne ynterface).
As gefolch hawwe wy in nijsgjirrige en tagelyk goed trochtochte oplossing krigen, dy't in bepaalde fleksibiliteit hat, mar noch gjin meganismen foar fouttolerânsje.
As earste hawwe wy mar ien kontrôleknooppunt - syn mislearring sil liede ta it ynstoarten fan alle systemen. Om dit probleem op te lossen, moatte jo op syn minst in kworum meitsje fan 3 knopen. Litte wy dit tafoegje oan it diagram:
Fansels binne alle knooppunten syngronisearre en as in aktive knooppunt fuortgiet, sil in oare knooppunt syn ferantwurdlikheden oernimme.
It folgjende probleem is firtuele masine-skiven. Op it stuit wurde se opslein op 'e hypervisors sels, en yn gefal fan problemen mei de hypervisor ferlieze wy alle gegevens - en de oanwêzigens fan in oerfal sil hjir net helpe as wy net de skiif ferlieze, mar de hiele tsjinner. Om dit te dwaan, moatte wy in tsjinst meitsje dy't sil fungearje as de foarkant foar in soarte fan opslach. Hokker soarte opslach it sil wêze is foar ús net spesjaal wichtich, mar it moat ús gegevens beskermje tsjin mislearring fan sawol de skiif as de knooppunt, en mooglik it hiele kabinet. D'r binne hjir ferskate opsjes - d'r binne fansels SAN-netwurken mei Fibre Channel, mar litte wy earlik wêze - FC is al in oerbliuwsel fan it ferline - in analoog fan E1 yn ferfier - ja, ik bin it iens, it wurdt noch altyd brûkt, mar allinnich dêr't it is perfoarst ûnmooglik sûnder it. Dêrom soe ik yn 2020 net frijwillich in FC-netwurk ynsette, wittende dat d'r oare nijsgjirrigere alternativen binne. Hoewol foar elk syn eigen, kinne d'r miskien wêze dy't leauwe dat FC mei al syn beheiningen alles is wat wy nedich binne - ik sil net bestride, elkenien hat har eigen miening. De meast nijsgjirrige oplossing is neffens my lykwols om in SDS te brûken, lykas Ceph.
Ceph lit jo in heul beskikbere oplossing foar gegevensopslach bouwe mei in protte mooglike reservekopy-opsjes, begjinnend mei koades mei pariteitskontrôle (analooch oan raid 5 of 6) einigje mei folsleine gegevensreplikaasje nei ferskate skiven, rekken hâldend mei de lokaasje fan skiven yn servers, en servers yn kasten, ensfh.
Om Ceph te bouwen hawwe jo 3 mear knopen nedich. Ynteraksje mei de opslach sil ek wurde útfierd fia it netwurk mei help fan blok-, objekt- en bestannen opslachtsjinsten. Litte wy opslach tafoegje oan it skema:
Opmerking: jo kinne ek hyperkonvergearre berekkeningsknooppunten meitsje - dit is it konsept fan it kombinearjen fan ferskate funksjes op ien knooppunt - bygelyks opslach + berekkenje - sûnder spesjale knooppunten te wijen foar ceph-opslach. Wy sille itselde fouttolerante skema krije - sûnt SDS sil gegevens reservearje mei it reservearringsnivo dat wy oantsjutte. Hyperconverged knooppunten binne lykwols altyd in kompromis - om't it opslachknooppunt net allinich de loft ferwaarmt sa't it op it earste each liket (om't d'r gjin firtuele masines op binne) - it besteget CPU-boarnen oan it betsjinjen fan SDS (yn feite docht it alles de replikaasje en herstel nei mislearrings fan knopen, skiven, ensfh.). Dat is, jo sille wat fan 'e krêft fan' e rekkenknooppunt ferlieze as jo it kombinearje mei opslach.
Dit alles moat op ien of oare manier beheard wurde - wy hawwe wat nedich wêrmei't wy in masine, in netwurk, in firtuele router, ensfh kinne meitsje. Om dit te dwaan, sille wy in tsjinst tafoegje oan 'e kontrôleknoop dy't as dashboard fungearret - de klant sil by steat wêze om te ferbinen mei dit portal fia http/ https en dwaan alles wat er nedich hat (goed, hast).
As gefolch hawwe wy no in fouttolerant systeem. Alle eleminten fan dizze ynfrastruktuer moatte op ien of oare manier wurde beheard. It waard earder beskreaun dat Openstack in set fan projekten is, wêrfan elk in spesifike funksje leveret. As wy sjogge, binne d'r mear dan genôch eleminten dy't moatte wurde konfigureare en kontroleare. Hjoed sille wy prate oer it netwurk diel.
Neutron arsjitektuer
Yn OpenStack is it Neutron dy't ferantwurdlik is foar it ferbinen fan firtuele masine-poarten oan in mienskiplik L2-netwurk, it garandearjen fan ferkearsrouting tusken VM's dy't op ferskate L2-netwurken lizze, lykas ek nei bûten, it leverjen fan tsjinsten lykas NAT, Floating IP, DHCP, ensfh.
Op in heech nivo kin de wurking fan 'e netwurktsjinst (it basisdiel) as folget wurde beskreaun.
By it starten fan de VM, de netwurktsjinst:
- Makket in haven foar in opjûne VM (of havens) en notify de DHCP tsjinst oer it;
- In nij firtuele netwurkapparaat wurdt makke (fia libvirt);
- De VM ferbynt mei de haven(s) makke yn stap 1;
Frjemd genôch is it wurk fan Neutron basearre op standertmeganismen bekend foar elkenien dy't oait yn Linux dûkt hat - nammeromten, iptables, linuxbrêgen, openvswitch, conntrack, ensfh.
It moat fuortendaliks dúdlik wurde dat Neutron gjin SDN-controller is.
Neutron bestiet út ferskate ûnderling ferbûne komponinten:
Openstack-neutron-tsjinner is in daemon dy't wurket mei brûkersoanfragen fia de API. Dizze demon is net belutsen by it registrearjen fan netwurkferbiningen, mar leveret de nedige ynformaasje foar dit oan syn plugins, dy't dan it winske netwurkelemint konfigurearje. Neutron-aginten op OpenStack-knooppunten registrearje by de Neutron-tsjinner.
Neutron-tsjinner is eins in applikaasje skreaun yn python, besteande út twa dielen:
- REST tsjinst
- Neutron Plugin (kearn/tsjinst)
De REST-tsjinst is ûntworpen om API-oproppen te ûntfangen fan oare komponinten (bygelyks in fersyk om wat ynformaasje te leverjen, ensfh.)
Ynstekkers binne plug-in software komponinten / modules dy't wurde neamd tidens API fersiken - dat is, de attribúsje fan in tsjinst komt troch harren. Plugins binne ferdield yn twa soarten - tsjinst en root. As regel is it hynderplugin benammen ferantwurdlik foar it behearen fan de adresromte en L2-ferbiningen tusken VM's, en serviceplugins jouwe al ekstra funksjonaliteit lykas VPN of FW.
De list mei plugins dy't hjoed beskikber binne kin bygelyks besjoen wurde
D'r kinne ferskate serviceplugins wêze, mar d'r kin mar ien hynderplugin wêze.
iepenstack-neutron-ml2 is de standert Openstack root plugin. Dizze plugin hat in modulêre arsjitektuer (oars as syn foargonger) en konfigurearret de netwurktsjinst fia bestjoerders dy't dêrmei ferbûn binne. Wy sille de plugin sels in bytsje letter besjen, om't it feitlik de fleksibiliteit jout dy't OpenStack hat yn it netwurkdiel. De root-plugin kin ferfongen wurde (Bygelyks, Contrail Networking docht sa'n ferfanging).
RPC-tsjinst (rabbitmq-tsjinner) - in tsjinst dy't wachtrige behear en ynteraksje leveret mei oare OpenStack-tsjinsten, lykas ynteraksje tusken netwurktsjinstaginten.
Netwurk aginten - aginten dy't lizze yn elke knooppunt, wêrtroch netwurktsjinsten wurde konfigureare.
D'r binne ferskate soarten aginten.
De wichtichste agint is L2 agent. Dizze aginten rinne op elk fan 'e hypervisors, ynklusyf kontrôleknooppunten (krekter sein, op alle knooppunten dy't elke tsjinst leverje foar hierders) en har haadfunksje is om firtuele masines te ferbinen mei in mienskiplik L2-netwurk, en ek warskôgings generearje as eveneminten foarkomme ( bygelyks de poarte útskeakelje / ynskeakelje).
De folgjende, net minder wichtige agent is L3 agent. Standert rint dizze agint eksklusyf op in netwurkknooppunt (faak wurdt it netwurkknooppunt kombinearre mei in kontrôleknooppunt) en soarget foar routing tusken hierdersnetwurken (sawol tusken syn netwurken as de netwurken fan oare hierders, en is tagonklik foar de bûtenwrâld, wêrtroch NAT, lykas DHCP-tsjinst). As jo lykwols in DVR (ferspraat router) brûke, ferskynt de needsaak foar in L3-plugin ek op 'e komputerknooppunten.
De L3-agint brûkt Linux-nammeromten om elke hierder in set fan har eigen isolearre netwurken te leverjen en de funksjonaliteit fan firtuele routers dy't ferkear routerje en gateway-tsjinsten leverje foar Layer 2-netwurken.
Databank - in databank fan identifiers fan netwurken, subnets, havens, pools, ensfh.
Yn feite aksepteart Neutron API-oanfragen fan 'e oprjochting fan alle netwurkentiteiten, autentisearret it fersyk, en fia RPC (as it tagong hat ta guon plugin of agent) of REST API (as it kommunisearret yn SDN) stjoert de aginten (fia plugins) de ynstruksjes nedich om de oanfrege tsjinst te organisearjen.
Litte wy no gean nei de testynstallaasje (hoe't it wurdt ynset en wat deryn is opnommen, sille wy letter yn it praktyske diel sjen) en sjen wêr't elke komponint leit:
(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 ~]$
Eins is dat de hiele struktuer fan Neutron. No is it wurdich wat tiid te besteegjen oan it ML2-plugin.
Modulêre laach 2
Lykas hjirboppe neamd, is it plugin in standert OpenStack root-plugin en hat in modulêre arsjitektuer.
De foargonger fan de ML2 plugin hie in monolithic struktuer, dy't net tastean, bygelyks, it brûken fan in miks fan ferskate technologyen yn ien ynstallaasje. Jo kinne bygelyks openvswitch en linuxbridge net tagelyk brûke - itsij de earste as de twadde. Om dizze reden waard de ML2-plugin mei syn arsjitektuer makke.
ML2 hat twa komponinten - twa soarten bestjoerders: Typebestjoerders en Mechanismebestjoerders.
Typ bestjoerders bepale de technologyen dy't brûkt wurde om te organisearjen netwurk ferbinings, Bygelyks VxLAN, VLAN, GRE. Tagelyk, de bestjoerder lit it brûken fan ferskate technologyen. De standert technology is VxLAN ynkapseling foar overlay netwurken en vlan eksterne netwurken.
Typebestjoerders omfetsje de folgjende netwurktypen:
Flet - netwurk sûnder tagging
VLANs - tagged netwurk
Pleatslik - in spesjaal soarte netwurk foar alles-yn-ien ynstallaasjes (soksoarte ynstallaasjes binne nedich foar ûntwikkelders of foar training)
GRE - overlay netwurk mei GRE-tunnels
VxLAN - overlay netwurk mei VxLAN-tunnels
Mechanisme bestjoerders definiearje ark dy't soargje foar de organisaasje fan de technologyen spesifisearre yn it type bestjoerder - bygelyks, openvswitch, sr-iov, opendaylight, OVN, ensfh.
Ofhinklik fan 'e ymplemintaasje fan dizze bestjoerder, wurde of troch Neutron kontroleare aginten brûkt, of ferbiningen mei in eksterne SDN-controller wurde brûkt, dy't soarget foar alle problemen yn ferbân mei it organisearjen fan L2-netwurken, routing, ensfh.
Foarbyld: as wy ML2 tegearre mei OVS brûke, dan wurdt in L2-agint ynstalleare op elke komputerknoop dy't OVS beheart. As wy lykwols bygelyks OVN of OpenDayLight brûke, dan komt de kontrôle fan OVS ûnder har jurisdiksje - Neutron, fia de root-plugin, jout kommando's oan 'e controller, en it docht al wat it waard ferteld.
Lit ús poetsen op Open vSwitch
Op it stuit is ien fan 'e wichtichste komponinten fan OpenStack Open vSwitch.
By it ynstallearjen fan OpenStack sûnder ekstra SDN-ferkeaper lykas Juniper Contrail of Nokia Nuage, is OVS de haadnetwurkkomponint fan it wolknetwurk en, tegearre mei iptables, conntrack, nammeromten, kinne jo folweardige multi-tenancy-overlay-netwurken organisearje. Natuerlik kin dizze komponint ferfongen wurde, bygelyks by it brûken fan proprietêre (ferkeaper) SDN-oplossingen fan tredden.
OVS is in iepen boarne software-switch dy't is ûntworpen foar gebrûk yn virtualisearre omjouwings as in firtuele ferkearsforwarder.
Op it stuit hat OVS heul fatsoenlike funksjonaliteit, dy't technologyen omfettet lykas QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, ensfh.
Opmerking: OVS waard ynearsten net betocht as in sêfte skeakel foar heul laden telekomfunksjes en wie mear ûntworpen foar minder bânbreedte-easkende IT-funksjes lykas WEB-tsjinner of e-posttsjinner. OVS wurdt lykwols fierder ûntwikkele en hjoeddeistige ymplemintaasjes fan OVS hawwe har prestaasjes en mooglikheden sterk ferbettere, wêrtroch it kin wurde brûkt troch telekomoperators mei heul laden funksjes, bygelyks is d'r in OVS-ymplemintaasje mei stipe foar DPDK-fersnelling.
D'r binne trije wichtige komponinten fan OVS wêrfan jo bewust moatte wêze:
- Kernel module - in komponint yn 'e kernelromte dy't ferkear ferwurket basearre op de regels ûntfongen fan it kontrôleelemint;
- vSwitch daemon (ovs-vswitchd) is in proses lansearre yn brûkersromte dat ferantwurdlik is foar it programmearjen fan de kernelmodule - dat is, it fertsjintwurdiget direkt de logika fan 'e operaasje fan' e switch
- Databanktsjinner - in lokale databank leit op elke host mei OVS, wêryn de konfiguraasje wurdt opslein. SDN-controllers kinne kommunisearje fia dizze module mei it OVSDB-protokol.
Dit alles wurdt begelaat troch in set fan diagnostyk- en behearprogramma's, lykas ovs-vsctl, ovs-appctl, ovs-ofctl, ensfh.
Op it stuit wurdt Openstack in soad brûkt troch telekomoperators om netwurkfunksjes nei it te migrearjen, lykas EPC, SBC, HLR, ensfh Guon funksjes kinne sûnder problemen libje mei OVS lykas is, mar bygelyks EPC ferwurket abonneeferkear - dan giet it troch in enoarme hoemannichte ferkear (no ferkearsvoluminten berikke ferskate hûnderten gigabits per sekonde). Fansels is it riden fan sa'n ferkear troch kernelromte (om't de trochstjoerder dêr standert leit) net it bêste idee. Dêrom wurdt OVS faak folslein yn brûkersromte ynset mei DPDK-fersnellingstechnology om ferkear fan NIC nei brûkersromte troch te stjoeren troch de kernel te omgean.
Opmerking: foar in wolk ynset foar telekommunikaasjefunksjes, is it mooglik om ferkear út te fieren fan in komputerknooppunt dy't OVS direkt omgiet nei wikseljen fan apparatuer. SR-IOV en Passthrough meganismen wurde brûkt foar dit doel.
Hoe wurket dit op in echte yndieling?
No, litte wy no oergean nei it praktyske diel en sjen hoe't it allegear yn 'e praktyk wurket.
Litte wy earst in ienfâldige Openstack-ynstallaasje ynsette. Sûnt ik haw gjin set fan tsjinners by de hân foar eksperiminten, wy sille assemble it prototype op ien fysike tsjinner fan firtuele masines. Ja, fansels, sa'n oplossing is net geskikt foar kommersjele doelen, mar om in foarbyld te sjen fan hoe't it netwurk wurket yn Openstack, sa'n ynstallaasje is genôch foar de eagen. Boppedat is sa'n ynstallaasje noch ynteressanter foar trainingsdoelen - om't jo ferkear kinne fange, ensfh.
Om't wy allinich it basisdiel moatte sjen, kinne wy ferskate netwurken net brûke, mar alles ferheegje mei mar twa netwurken, en it twadde netwurk yn dizze yndieling sil allinich brûkt wurde foar tagong ta de undercloud- en DNS-tsjinner. Wy sille no gjin eksterne netwurken oanreitsje - dit is in ûnderwerp foar in apart grut artikel.
Dus, lit ús yn oarder begjinne. Earst, in bytsje teory. Wy sille Openstack ynstallearje mei TripleO (Openstack op Openstack). De essinsje fan TripleO is dat wy Openstack alles-yn-ien ynstallearje (dat is op ien knooppunt), neamd undercloud, en dan de mooglikheden fan 'e ynset Openstack brûke om Openstack te ynstallearjen bedoeld foar operaasje, neamd overcloud. Undercloud sil syn ynherinte fermogen brûke om fysike tsjinners (keale metaal) te behearjen - it Ironyske projekt - om hypervisors te leverjen dy't de rollen fan berekkenje, kontrôle, opslachknooppunten sille útfiere. Dat is, wy brûke gjin ark fan tredden om Openstack yn te setten - wy ynsette Openstack mei Openstack. It sil folle dúdliker wurde as de ynstallaasje foarútgiet, dus sille wy dêr net ophâlde en foarút gean.
Opmerking: Yn dit artikel haw ik foar de ienfâld gjin netwurkisolaasje brûkt foar ynterne Openstack-netwurken, mar alles wurdt ynset mei mar ien netwurk. De oanwêzigens of ôfwêzigens fan netwurkisolaasje hat lykwols gjin ynfloed op de basisfunksjonaliteit fan 'e oplossing - alles sil krekt itselde wurkje as by it brûken fan isolaasje, mar ferkear sil streame op itselde netwurk. Foar in kommersjele ynstallaasje is it fansels nedich om isolaasje te brûken mei ferskate vlans en ynterfaces. Bygelyks, ceph opslach behear ferkear en gegevens ferkear sels (masine tagong ta skiven, ensfh) doe't isolearre gebrûk ferskillende subnets (Opslach behear en Storage) en dit kinne jo meitsje de oplossing mear flater-tolerant troch dielen fan dit ferkear, bygelyks . Yn ús gefal sille se op itselde netwurk gean en feitlik beheint dit ús op gjin inkelde manier.
Opmerking: Om't wy firtuele masines sille útfiere yn in firtuele omjouwing basearre op firtuele masines, moatte wy earst nestede virtualisaasje ynskeakelje.
Jo kinne kontrolearje oft geneste virtualisaasje is ynskeakele of net sa:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#As jo de letter N sjogge, skeakelje wy stipe yn foar geneste virtualisaasje neffens elke gids dy't jo fine op it netwurk, bygelyks .
Wy moatte it folgjende circuit gearstalle fan firtuele masines:
Yn myn gefal, om de firtuele masines te ferbinen dy't diel útmeitsje fan 'e takomstige ynstallaasje (en ik krige 7 fan har, mar jo kinne mei 4 komme as jo net in protte boarnen hawwe), haw ik OpenvSwitch brûkt. Ik makke ien ovs brêge en ferbûn firtuele masines oan it fia haven-groepen. Om dit te dwaan, haw ik in xml-bestân makke lykas dit:
[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>Trije poartegroepen wurde hjir ferklearre - twa tagong en ien romp (de lêste wie nedich foar de DNS-tsjinner, mar jo kinne sûnder it dwaan, of ynstallearje op 'e hostmasine - wat foar jo handiger is). Folgjende, mei dit sjabloan, ferklearje wy ús fia virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 No bewurkje wy de hypervisor-poartekonfiguraasjes:
[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 ~]# Opmerking: yn dit senario sil it adres op haven ovs-br1 net tagonklik wêze om't it gjin vlan-tag hat. Om dit te reparearjen, moatte jo it kommando útjaan sudo ovs-vsctl set port ovs-br1 tag = 100. Nei in trochstart sil dizze tag lykwols ferdwine (as immen wit hoe't it op syn plak bliuwt, sil ik tige tankber wêze). Mar dit is net sa wichtich, om't wy dit adres allinich nedich binne by ynstallaasje en sille it net nedich wêze as Openstack folslein ynset is.
Folgjende meitsje wy in undercloud masine:
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=ttyS0Tidens de ynstallaasje set jo alle nedige parameters yn, lykas de masinenamme, wachtwurden, brûkers, ntp-tsjinners, ensfh., Jo kinne de havens fuortendaliks konfigurearje, mar foar my persoanlik is it nei ynstallaasje makliker om yn te loggen op 'e masine fia de konsole en korrigearje de nedige bestannen. As jo al in klearmakke ôfbylding hawwe, kinne jo it brûke, of dwaan wat ik dien haw - download de minimale Centos 7-ôfbylding en brûk it om de VM te ynstallearjen.
Nei suksesfolle ynstallaasje moatte jo in firtuele masine hawwe wêrop jo undercloud kinne ynstallearje
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningYnstallearje earst de ark nedich foar it ynstallaasjeproses:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud ynstallaasje
Wy meitsje in stapelbrûker, set in wachtwurd yn, foegje it ta oan sudoer en jouwe him de mooglikheid om root-kommando's út te fieren fia sudo sûnder in wachtwurd yn te hoegen:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNo spesifisearje wy de folsleine undercloudnamme yn it hostbestân:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Dêrnei foegje wy repositories ta en ynstallearje de software dy't wy nedich binne:
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-ansibleOpmerking: as jo net fan plan binne ceph te ynstallearjen, dan hoege jo gjin ceph-relatearre kommando's yn te fieren. Ik brûkte de Queens-release, mar jo kinne elke oare brûke dy't jo wolle.
Kopiearje dan it undercloud-konfiguraasjebestân nei de stapel fan 'e thúsmap fan' e brûker:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNo moatte wy dit bestân korrigearje, it oanpasse oan ús ynstallaasje.
Jo moatte dizze rigels tafoegje oan it begjin fan it bestân:
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 = 10Dus, litte wy troch de ynstellings gean:
undercloud_hostname - de folsleine namme fan 'e undercloud-tsjinner, moat oerienkomme mei de yngong op' e DNS-tsjinner
local_ip - lokaal undercloud-adres foar netwurkfoarsjenning
netwurk_gateway - itselde lokale adres, dat sil fungearje as in poarte foar tagong ta de bûtenwrâld by de ynstallaasje fan overcloud knopen, komt ek oerien mei lokale ip
undercloud_public_host - ekstern API-adres, elk fergees adres fan it foarsjenningsnetwurk wurdt tawiisd
undercloud_admin_host ynterne API-adres, elk fergees adres fan it foarsjenningsnetwurk wurdt tawiisd
undercloud_nameservers - DNS-tsjinner
generearje_service_sertifikaat - dizze rigel is heul wichtich yn it hjoeddeistige foarbyld, om't as jo it net ynstelle op falsk, sille jo in flater krije by ynstallaasje, it probleem wurdt beskreaun op 'e Red Hat bug tracker
local_interface ynterface yn netwurkfoarsjenning. Dizze ynterface sil opnij konfigureare wurde tidens undercloud-ynset, dus jo moatte twa ynterfaces hawwe op undercloud - ien foar tagong ta it, de twadde foar foarsjenning
local_mtu - MTU. Om't wy in testlaboratoarium hawwe en ik MTU fan 1500 haw op 'e havens fan' e OVS-switch, is it nedich om it op 1450 yn te stellen sadat pakketten ynkapsulearre yn VxLAN kinne trochjaan
netwurk_cidr - foarsjenning netwurk
maskerade - NAT brûke om tagong te krijen ta in ekstern netwurk
masquerade_netwurk - netwurk dat sil wurde NATed
dhcp_start - it begjinadres fan 'e adrespool wêrfan adressen sille wurde tawiisd oan knooppunten tidens oerwolk-ynset
dhcp_end - it definitive adres fan 'e adrespool wêrfan adressen sille wurde tawiisd oan knooppunten tidens oerwolk-ynset
ynspeksje_iprange - in pool fan adressen nedich foar yntrospeksje (moat net oerlaapje mei it boppesteande swimbad)
scheduler_max_attempts - maksimum oantal pogingen om overcloud te ynstallearjen (moat grutter wêze as of gelyk oan it oantal knopen)
Nei't it bestân beskreaun is, kinne jo it kommando jaan om Undercloud yn te setten:
openstack undercloud install
De proseduere duorret fan 10 oant 30 minuten ôfhinklik fan jo izer. Uteinlik soene jo de útfier lykas dit moatte sjen:
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.
#############################################################################Dizze útfier seit dat jo undercloud mei súkses ynstalleare hawwe en jo kinne no de status fan undercloud kontrolearje en trochgean mei it ynstallearjen fan overcloud.
As jo nei de ifconfig-útfier sjogge, sille jo sjen dat in nije brêge-ynterface is ferskynd
[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 0Overcloud-ynset sil no wurde útfierd fia dizze ynterface.
Ut de útfier hjirûnder kinne jo sjen dat wy alle tsjinsten hawwe op ien knooppunt:
(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 |
+--------------------------+-----------+----------+Hjirûnder is de konfiguraasje fan it undercloud netwurkdiel:
(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 ~]$Overcloud ynstallaasje
Op it stuit hawwe wy allinich undercloud, en wy hawwe net genôch knopen wêrfan overcloud sil wurde gearstald. Dêrom litte wy earst de firtuele masines ynsette dy't wy nedich binne. Tidens de ynset sil undercloud sels it OS en de nedige software ynstalleare op 'e overcloud-masine - dat is, wy hoege de masine net folslein yn te setten, mar allinich in skiif (as skiven) foar it oanmeitsjen en de parameters te bepalen - dat is , yn feite, wy krije in bleate tsjinner sûnder in OS ynstallearre op it.
Litte wy nei de map gean mei de skiven fan ús firtuele masines en meitsje skiven fan 'e fereaske grutte:
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 160GSûnt wy wurkje as root, moatte wy de eigner fan dizze skiven feroarje om gjin probleem te krijen mei rjochten:
[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]# Opmerking: as jo net fan plan binne om ceph te ynstallearjen om it te studearjen, dan meitsje de kommando's net op syn minst 3 knooppunten mei op syn minst twa skiven, mar yn 'e sjabloan jouwe oan dat firtuele skiven vda, vdb, ensfh.
Geweldich, no moatte wy al dizze masines definiearje:
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 Oan 'e ein is d'r in kommando -print-xml > /tmp/storage-1.xml, dat in xml-bestân makket mei in beskriuwing fan elke masine yn 'e /tmp/-map; as jo it net tafoegje, sille jo net wêze kinne firtuele masines identifisearje.
No moatte wy al dizze masines definiearje yn 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 ~]#No in lytse nuânse - tripleO brûkt IPMI om servers te behearjen by ynstallaasje en yntrospeksje.
Yntrospeksje is it proses fan ynspeksje fan 'e hardware om syn parameters te krijen dy't nedich binne foar fierdere foarsjenning fan knopen. Yntrospeksje wurdt útfierd mei ironysk, in tsjinst ûntworpen om te wurkjen mei bleate metalen servers.
Mar hjir is it probleem - wylst hardware IPMI-tsjinners in aparte poarte hawwe (of in dielde poarte, mar dit is net wichtich), dan hawwe firtuele masines sokke havens net. Hjir komt in kruk neamd vbmc ús te helpen - in hulpprogramma wêrmei jo in IPMI-poarte kinne emulearje. Dizze nuânse is it wurdich omtinken te jaan foaral foar dyjingen dy't sa'n laboratoarium wolle opsette op in ESXI hypervisor - om earlik te wêzen, ik wit net oft it in analoog fan vbmc hat, dus it is it wurdich te freegjen oer dit probleem foardat alles ynset wurdt .
Ynstallearje vbmc:
yum install yum install python2-virtualbmcAs jo OS it pakket net kin fine, foegje dan it repository ta:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNo hawwe wy it nut ynsteld. Alles is hjir banaal oant it punt fan skande. No is it logysk dat d'r gjin servers binne yn 'e vbmc-list
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Foardat se ferskine, moatte se mei de hân wurde ferklearre sa:
[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 ~]#Ik tink dat de kommando syntaksis dúdlik is sûnder útlis. Foar no binne al ús sesjes lykwols yn DOWN-status. Foar har om te ferpleatsen nei UP-status, moatte jo se ynskeakelje:
[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 ~]#En de lêste touch - jo moatte de firewall-regels korrigearje (of it folslein útskeakelje):
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
Litte wy no nei Undercloud gean en kontrolearje dat alles wurket. It adres fan 'e hostmasine is 192.168.255.200, op undercloud hawwe wy it nedige ipmitool-pakket tafoege by de tarieding foar ynset:
[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 runningSa't jo sjen kinne, hawwe wy mei súkses lansearre de kontrôle node fia vbmc. Litte wy it no útsette en trochgean:
[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 ~]#De folgjende stap is yntrospeksje fan 'e knopen wêrop overcloud ynstalleare sil. Om dit te dwaan, moatte wy in json-bestân tariede mei in beskriuwing fan ús knopen. Tink derom dat, yn tsjinstelling ta ynstallaasje op bleate servers, it bestân de poarte oanjout wêrop vbmc foar elke masine rint.
[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:27Opmerking: it kontrôleknooppunt hat twa ynterfaces, mar yn dit gefal is dit net wichtich, yn dizze ynstallaasje sil ien foar ús genôch wêze.
No meitsje wy it json-bestân tariede. Wy moatte it poppy-adres oanjaan fan 'e haven wêrmei't foarsjenning sil wurde útfierd, de parameters fan 'e knopen, har nammen jaan en oanjaan hoe't jo nei ipmi komme:
{
"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"
}
]
}No moatte wy bylden tariede foar iroanysk. Om dit te dwaan, download se fia wget en ynstallearje:
(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 ~]$Ofbyldings uploade nei 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 ~]$Kontrolearje dat alle ôfbyldings binne laden
(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 ~]$Noch ien ding - jo moatte in DNS-tsjinner tafoegje:
(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 ~]$No kinne wy it kommando foar yntrospeksje jaan:
(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 ~]$Sa't jo sjen kinne út de útfier, alles foltôge sûnder flaters. Litte wy kontrolearje dat alle knopen yn 'e beskikbere steat binne:
(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 ~]$ As de knopen yn in oare steat binne, meastentiids te behearjen, dan gie der wat mis en jo moatte nei it log sjen en útfine wêrom dit barde. Hâld der rekken mei dat wy yn dit senario virtualisaasje brûke en d'r kinne bugs wêze ferbûn mei it brûken fan firtuele masines of vbmc.
Folgjende moatte wy oanjaan hokker knooppunt hokker funksje sil útfiere - dat is, oanjaan it profyl wêrmei't it knooppunt sil ynsette:
(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 ~]$Spesifisearje it profyl foar elke node:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Litte wy kontrolearje dat wy alles goed dien hawwe:
(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 ~]$As alles goed is, jouwe wy it kommando om overcloud yn te setten:
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 qemuYn in echte ynstallaasje sille fansels oanpaste sjabloanen brûkt wurde, yn ús gefal sil dit it proses tige komplisearje, om't elke bewurking yn 'e sjabloan útlein wurde moat. Lykas earder skreaun, sil sels in ienfâldige ynstallaasje genôch wêze foar ús om te sjen hoe't it wurket.
Opmerking: de --libvirt-type qemu fariabele is nedich yn dit gefal, om't wy geneste virtualisaasje sille brûke. Oars, do silst net by steat wêze om te rinne firtuele masines.
No hawwe jo sawat in oere, of miskien mear (ôfhinklik fan de mooglikheden fan 'e hardware) en jo kinne allinich hoopje dat jo nei dizze tiid it folgjende berjocht sille sjen:
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 ~]$No hawwe jo in hast folsleine ferzje fan openstack, wêrop jo kinne studearje, eksperimintearje, ensfh.
Lit ús kontrolearje dat alles goed wurket. Yn de stack fan 'e thúsmap fan' e brûker binne d'r twa bestannen - ien stackrc (foar it behearen fan undercloud) en de twadde overcloudrc (foar it behearen fan overcloud). Dizze bestannen moatte wurde oantsjutte as boarne, om't se ynformaasje befetsje dy't nedich is foar autentikaasje.
(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 ~]$Myn ynstallaasje fereasket noch ien lyts touch - it tafoegjen fan in rûte op 'e controller, om't de masine wêrmei ik wurkje is op in oar netwurk. Om dit te dwaan, gean nei kontrôle-1 ûnder it heat-admin-akkount en registrearje de rûte
(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.254No, no kinne jo de hoarizon yngean. Alle ynformaasje - adressen, oanmelden en wachtwurd - binne yn it bestân /home/stack/overcloudrc. It definitive diagram sjocht der sa út:
Trouwens, yn ús ynstallaasje waarden masineadressen fia DHCP útjûn en, lykas jo sjen kinne, wurde se "willekeurich" útjûn. Jo kinne strikt definiearje yn it sjabloan hokker adres moat wurde hechte oan hokker masine by ynset, as jo it nedich hawwe.
Hoe streamt ferkear tusken firtuele masines?
Yn dit artikel sille wy sjen nei trije opsjes foar trochjaan ferkear
- Twa masines op ien hypervisor op ien L2 netwurk
- Twa masines op ferskillende hypervisors op itselde L2 netwurk
- Twa masines op ferskate netwurken (cross-network rooting)
Saken mei tagong ta de bûtenwrâld fia in ekstern netwurk, mei driuwende adressen, lykas ferdielde routing, sille wy de folgjende kear beskôgje, foar no sille wy rjochtsje op ynterne ferkear.
Om te kontrolearjen, litte wy it folgjende diagram gearstelle:
Wy hawwe 4 firtuele masines makke - 3 op ien L2 netwurk - net-1, en 1 mear op it net-2 netwurk
(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 ~]$ Litte wy sjen op hokker hypervisors de oanmakke masines lizze:
(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 |
(oerwolk) [stack@undercloud ~]$
Masines vm-1 en vm-3 lizze op compute-0, masines vm-2 en vm-4 lizze op node compute-1.
Derneist is in firtuele router makke om routing mooglik te meitsjen tusken de opjûne netwurken:
(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 ~]$ De router hat twa firtuele havens, dy't fungearje as poarten foar netwurken:
(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 ~]$ Mar foardat wy sjogge nei hoe't it ferkear streamt, litte wy sjen nei wat wy op it stuit hawwe op it kontrôleknooppunt (dat ek in netwurkknooppunt is) en op it komputerknooppunt. Litte wy begjinne mei it komputerknooppunt.
[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 ~]$Op it stuit hat de knooppunt trije ovs-brêgen - br-int, br-tun, br-ex. Tusken har, lykas wy sjogge, is d'r in set fan ynterfaces. Lit ús foar gemak fan begryp al dizze ynterfaces op it diagram plotje en sjen wat der bart.
Sjoch op de adressen dêr't VxLAN tunnels wurde ferhege, kin sjoen wurde dat ien tunnel wurdt ferhege nei compute-1 (192.168.255.26), de twadde tunnel sjocht nei kontrôle-1 (192.168.255.15). Mar it meast nijsgjirrige ding is dat br-ex gjin fysike ynterfaces hat, en as jo sjogge hokker streamen binne konfigureare, kinne jo sjen dat dizze brêge op it stuit allinich ferkear kin falle.
[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 ~]$ Sa't jo sjen kinne út de útfier, it adres wurdt geschroefd direkt oan de fysike haven, en net oan de firtuele brêge ynterface.
[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 ~]$
Neffens de earste regel moat alles wat út 'e phy-br-ex-poarte kaam, fuorthelle wurde.
Eins is d'r op it stuit nearne oars foar ferkear yn dizze brêge te kommen, útsein fan dizze ynterface (de ynterface mei br-int), en nei de drippen te oardieljen is it BUM-ferkear al yn 'e brêge flein.
Dat is, ferkear kin dit knooppunt allinich ferlitte troch de VxLAN-tunnel en neat oars. As jo de DVR lykwols ynskeakelje, sil de situaasje feroarje, mar dêr sille wy in oare kear mei omgean. By it brûken fan netwurk isolaasje, Bygelyks mei help fan vlans, do silst hawwe net ien L3 ynterface yn vlan 0, mar ferskate Schnittstellen. Lykwols, VxLAN ferkear sil ferlitte it knooppunt op deselde wize, mar ek ynkapsele yn in soarte fan tawijd vlan.
Wy hawwe it komputerknooppunt sorteare, litte wy trochgean nei it kontrôleknooppunt.
[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 ~]$Yn feite kinne wy sizze dat alles itselde is, mar it IP-adres is net mear op 'e fysike ynterface, mar op' e firtuele brêge. Dit wurdt dien om't dizze haven de haven is dêr't ferkear troch nei de bûtenwrâld útkomt.
[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 ~]$ Dizze poarte is bûn oan 'e br-ex-brêge en om't d'r gjin vlan-tags op binne, is dizze poarte in romppoarte wêrop alle vlans tastien binne, no giet ferkear nei bûten sûnder in tag, lykas oanjûn troch vlan-id 0 yn 'e útfier boppe.
Al it oare is op it stuit te fergelykjen mei de komputerknooppunt - deselde brêgen, deselde tunnels dy't nei twa rekkenknooppunten gean.
Wy sille net beskôgje opslach knopen yn dit artikel, mar foar it begripen is it nedich om te sizzen dat it netwurk diel fan dizze knopen is banaal oant it punt fan skande. Yn ús gefal is d'r mar ien fysike poarte (eth0) mei in IP-adres tawiisd en dat is it. Der binne gjin VxLAN tunnels, tunnel brêgen, ensfh - der is gjin ovs hielendal, sûnt der is gjin punt yn it. By it brûken fan netwurkisolaasje sil dizze knooppunt twa ynterfaces hawwe (fysike havens, bodny, of gewoan twa vlans - it makket neat út - it hinget ôf fan wat jo wolle) - ien foar behear, de twadde foar ferkear (skriuwen nei de VM-skiif , lêzen fan skiif, ensfh.)
Wy hawwe útfûn wat wy op 'e knopen hawwe by it ûntbrekken fan tsjinsten. Litte wy no 4 firtuele masines starte en sjen hoe't it hjirboppe beskreaune skema feroaret - wy moatte havens, firtuele routers, ensfh.
Oant no ta sjocht ús netwurk der sa út:
Wy hawwe twa firtuele masines op elke kompjûterknooppunt. Mei help fan compute-0 as foarbyld, lit ús sjen hoe't alles is opnommen.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ De masine hat mar ien firtuele ynterface - 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 ~]$
Dizze ynterface sjocht yn 'e linux-brêge:
[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 ~]$ Sa't jo sjen kinne út de útfier, d'r binne mar twa ynterfaces yn 'e brêge - tap95d96a75-a0 en qvb95d96a75-a0.
Hjir is it de muoite wurdich om in bytsje te wenjen oer de soarten firtuele netwurkapparaten yn OpenStack:
vtap - firtuele ynterface ferbûn oan in eksimplaar (VM)
qbr - Linux brêge
qvb en qvo - vEth pear ferbûn mei Linux brêge en Iepenje vSwitch brêge
br-int, br-tun, br-vlan - Iepenje vSwitch-brêgen
patch-, int-br-, phy-br- - Iepenje vSwitch patch-ynterfaces dy't brêgen ferbine
qg, qr, ha, fg, sg - Iepenje vSwitch-poarten brûkt troch firtuele apparaten om te ferbinen mei OVS
Sa't jo begripe, as wy hawwe in qvb95d96a75-a0 haven yn 'e brêge, dat is in vEth pear, dan earne is der syn tsjinhinger, dat moat logysk neamd wurde qvo95d96a75-a0. Litte wy sjen hokker havens binne op 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 ~]$ Sa't wy sjen kinne, is de haven yn br-int. Br-int fungearret as in switch dy't termines firtuele masine havens. Neist qvo95d96a75-a0 is de haven qvo5bd37136-47 sichtber yn 'e útfier. Dit is de haven nei de twadde firtuele masine. As resultaat sjocht ús diagram der no sa út:
In fraach dy't de oandachtige lêzer fuortendaliks ynteressearje moat - wat is de Linux-brêge tusken de firtuele masine-poarte en de OVS-poarte? It feit is dat om de masine te beskermjen, wurde feiligensgroepen brûkt, dy't neat mear binne as iptables. OVS wurket net mei iptables, dus dizze "kruk" waard útfûn. It wurdt lykwols ferâldere - it wurdt ferfongen troch conntrack yn nije releases.
Dat is, úteinlik sjocht it skema der sa út:
Twa masines op ien hypervisor op ien L2 netwurk
Sûnt dizze twa VM's lizze op itselde L2-netwurk en op deselde hypervisor, sil ferkear tusken har logysk lokaal troch br-int streame, om't beide masines op deselde VLAN sille wêze:
[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 ~]$ Twa masines op ferskillende hypervisors op itselde L2 netwurk
Litte wy no sjen hoe't it ferkear sil gean tusken twa masines op itselde L2-netwurk, mar leit op ferskate hypervisors. Om earlik te wêzen, sil neat folle feroarje, gewoan ferkear tusken hypervisors sil troch de vxlan-tunnel gean. Litte wy nei in foarbyld sjen.
Adressen fan firtuele masines tusken wêr't wy ferkear sille sjen:
[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 ~]$ Wy sjogge nei de trochstjoertabel yn br-int op 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 ~]Ferkear moat nei haven 2 gean - lit ús sjen hokker soarte haven it is:
[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 ~]$Dit is patch-tun - dat is de ynterface yn br-tun. Litte wy sjen wat der bart mei it pakket op 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 ~]$ It pakket wurdt ferpakt yn VxLAN en stjoerd nei poarte 2. Litte wy sjen wêr't poarte 2 liedt:
[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 ~]$Dit is in vxlan-tunnel op 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 ~]$Litte wy nei compute-1 gean en sjen wat der neist bart mei it pakket:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac is yn 'e br-int trochstjoertabel op compute-1, en lykas kin wurde sjoen út' e útfier hjirboppe, is it sichtber fia poarte 2, dat is de poarte nei 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:46No, dan sjogge wy dat d'r yn br-int op compute-1 in bestimmingsmopper is:
[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 ~]$ Dat is, it ûntfongen pakket sil fleane nei poarte 3, dêr't d'r al in firtuele masine-eksimplaar-00000003 is.
De skientme fan it ynsetten fan Openstack foar learen op firtuele ynfrastruktuer is dat wy maklik ferkear kinne fange tusken hypervisors en sjen wat der mei bart. Dit is wat wy no sille dwaan, tcpdump útfiere op 'e vnet-poarte nei 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*******************De earste rigel lit sjen dat Patek fan adres 10.0.1.85 giet nei adres 10.0.1.88 (ICMP ferkear), en it is ferpakt yn in VxLAN pakket mei vni 22 en it pakket giet fan host 192.168.255.19 (komputer-0) nei host 192.168.255.26 .1 (berekkenje-XNUMX). Wy kinne kontrolearje dat de VNI oerienkomt mei de spesifisearre yn ovs.
Litte wy weromgean nei dizze rigel actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],útfier:2. 0x16 is vni yn it heksadesimale nûmersysteem. Litte wy dit nûmer konvertearje nei it 16e systeem:
16 = 6*16^0+1*16^1 = 6+16 = 22Dat is, vni komt oerien mei de werklikheid.
De twadde rigel lit weromferkear sjen, goed, it hat gjin punt om it út te lizzen, alles is dêr dúdlik.
Twa masines op ferskate netwurken (rûting tusken netwurken)
It lêste gefal foar hjoed is routing tusken netwurken binnen ien projekt mei in firtuele router. Wy beskôgje in saak sûnder in DVR (wy sille it sjen yn in oar artikel), dus routing komt op it netwurkknooppunt. Yn ús gefal is it netwurkknooppunt net yn in aparte entiteit pleatst en leit op it kontrôleknooppunt.
Litte wy earst sjen dat routing wurket:
$ 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 msOm't yn dit gefal it pakket nei de gateway moat gean en dêrhinne wurde trochstjoerd, moatte wy it MAC-adres fan 'e gateway fine, wêrfoar't wy de ARP-tabel yn it gefal sjogge:
$ 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 eth0Litte wy no sjen wêr't it ferkear mei bestimming (10.0.1.254) fa:16:3e:c4:64:70 ferstjoerd wurde moat:
[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 ~]$ Litte wy sjen wêr't haven 2 liedt:
[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 ~]$ Alles is logysk, ferkear giet nei br-tun. Litte wy sjen yn hokker vxlan-tunnel it sil wurde ferpakt:
[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 ~]$ De tredde haven is in vxlan-tunnel:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Wat sjocht nei it kontrôleknooppunt:
[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 ~]$ It ferkear hat it kontrôleknooppunt berikt, dus wy moatte dernei gean en sjen hoe't routing sil barre.
Sa't jo ûnthâlde, seach de kontrôleknooppunt binnen krekt itselde as it komputerknooppunt - deselde trije brêgen, allinich br-ex hie in fysike poarte wêrmei't it knooppunt ferkear nei bûten koe stjoere. De oprjochting fan eksimplaren feroare de konfiguraasje op 'e komputerknooppunten - linuxbrêge, iptables en ynterfaces waarden tafoege oan' e knopen. De oprjochting fan netwurken en in firtuele router liet ek syn mark op 'e konfiguraasje fan' e kontrôleknooppunt.
Dat, it is fanselssprekkend dat it MAC-adres fan it gateway moat wêze yn 'e br-int-trochstjoertabel op it kontrôleknooppunt. Litte wy kontrolearje dat it d'r is en wêr't it sjocht:
[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 ~]$ De Mac is sichtber fanút haven qr-0c52b15f-8f. As wy weromgean nei de list mei firtuele havens yn Openstack, wurdt dit type haven brûkt om ferskate firtuele apparaten te ferbinen mei OVS. Om krekter te wêzen, is qr in poarte nei de firtuele router, dy't wurdt fertsjintwurdige as in nammeromte.
Litte wy sjen hokker nammeromten op 'e tsjinner binne:
[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 ~]$ Sawol trije eksimplaren. Mar te beoardieljen troch de nammen, kinne jo riede it doel fan elk fan harren. Wy sille letter weromkomme nei gefallen mei ID 0 en 1, no binne wy ynteressearre yn nammeromte 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 ~]$ Dizze nammeromte befettet twa ynterne dy't wy earder makke hawwe. Beide firtuele havens binne tafoege oan br-int. Litte wy it mac-adres fan 'e haven qr-0c52b15f-8f kontrolearje, om't it ferkear, te beoardieljen nei it bestimming mac-adres, nei dizze ynterface gie.
[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 ~]$ Dat is, yn dit gefal, alles wurket neffens de wetten fan standert routing. Sûnt it ferkear is ornearre foar host 10.0.2.8, moat it útgean fia de twadde ynterface qr-92fa49b5-54 en gean troch de vxlan-tunnel nei it komputerknooppunt:
[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 ~]$ Alles is logysk, gjin ferrassingen. Litte wy sjen wêr't it poppy-adres fan host 10.0.2.8 sichtber is 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 ~]$ Lykas ferwachte giet it ferkear nei br-tun, lit ús sjen nei hokker tunnel it ferkear de folgjende giet:
[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 ~]$ Ferkear giet de tunnel yn om-1 te berekkenjen. No, op compute-1 is alles ienfâldich - fan br-tun giet it pakket nei br-int en dêrwei nei de firtuele masine-ynterface:
[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 ~]$ Litte wy kontrolearje dat dit yndie de juste ynterface is:
[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 ~]$
Eins giene wy it hiele pakket troch. Ik tink dat jo opfallen dat it ferkear gie troch ferskillende vxlan tunnels en útgien mei ferskillende VNIs. Lit ús sjen hokker soarte fan VNI dit binne, wêrnei't wy sille sammelje in dump op 'e kontrôle haven fan it knooppunt en soargje derfoar dat it ferkear streamt krekt lykas hjirboppe beskreaun.
Dat, de tunnel om-0 te berekkenjen hat de folgjende aksjes=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],útfier:3. Litte wy 0x16 konvertearje nei it desimale nûmersysteem:
0x16 = 6*16^0+1*16^1 = 6+16 = 22De tunnel om te berekkenjen-1 hat de folgjende VNI: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],útfier:2. Litte wy 0x63 konvertearje nei it desimale nûmersysteem:
0x63 = 3*16^0+6*16^1 = 3+96 = 99No, lit ús no nei de dump sjen:
[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*******************It earste pakket is in vxlan-pakket fan host 192.168.255.19 (compute-0) nei host 192.168.255.15 (kontrôle-1) mei vni 22, wêryn in ICMP-pakket wurdt ferpakt fan host 10.0.1.85 nei host 10.0.2.8. As wy hjirboppe berekkene, komt vni oerien mei wat wy seagen yn 'e útfier.
It twadde pakket is in vxlan-pakket fan host 192.168.255.15 (kontrôle-1) nei host 192.168.255.26 (compute-1) mei vni 99, wêryn in ICMP-pakket wurdt ferpakt fan host 10.0.1.85 nei host 10.0.2.8. As wy hjirboppe berekkene, komt vni oerien mei wat wy seagen yn 'e útfier.
De folgjende twa pakketten binne weromferkear fan 10.0.2.8 net 10.0.1.85.
Dat is, op it lêst krigen wy it folgjende kontrôleknooppuntskema:
Lyk as dat it is? Wy binne twa nammeromten fergetten:
[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 ~]$ As wy prate oer de arsjitektuer fan it wolkplatfoarm, soe it goed wêze as masines automatysk adressen ûntfange fan in DHCP-tsjinner. Dit binne twa DHCP-tsjinners foar ús twa netwurken 10.0.1.0/24 en 10.0.2.0/24.
Lit ús kontrolearje dat dit wier is. D'r is mar ien adres yn dizze nammeromte - 10.0.1.1 - it adres fan 'e DHCP-tsjinner sels, en it is ek opnommen 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 0Litte wy sjen as prosessen dy't qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 befetsje yn har namme op it kontrôleknooppunt:
[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 ~]$ D'r is sa'n proses en basearre op de ynformaasje presintearre yn 'e útfier hjirboppe, kinne wy bygelyks sjen wat wy op it stuit te huur hawwe:
[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 ~]$As gefolch krije wy de folgjende set tsjinsten op it kontrôleknooppunt:
No, hâld yn gedachten - dit is gewoan 4 masines, 2 ynterne netwurken en ien firtuele router ... Wy hawwe hjir no gjin eksterne netwurken, in protte ferskillende projekten, elk mei har eigen netwurken (oerlappend), en wy hawwe in ferspraat router útskeakele, en op it lêst Ommers, der wie mar ien kontrôle knooppunt yn de test bank (foar skuld tolerânsje moat der in kworum fan trije knopen). It is logysk dat yn 'e kommersje alles "in bytsje" yngewikkelder is, mar yn dit ienfâldige foarbyld begripe wy hoe't it moat wurkje - oft jo 3 of 300 nammeromten hawwe is fansels wichtich, mar út it eachpunt fan 'e operaasje fan 'e heule struktuer, neat sil feroarje folle ... hoewol't oant jo sille net plug yn guon ferkeaper SDN. Mar dat is in folslein oar ferhaal.
Ik hoopje dat it nijsgjirrich wie. As jo opmerkings/tafoegings hawwe, of earne haw ik perfoarst liigd (ik bin minske en myn miening sil altyd subjektyf wêze) - skriuw wat korrizjearre/tafoege wurde moat - wy korrigearje/foegje alles ta.
As konklúzje wol ik in pear wurden sizze oer it fergelykjen fan Openstack (sawol vanille as ferkeaper) mei de wolkoplossing fan VMWare - ik bin dizze fraach de ôfrûne pear jier te faak steld en, earlik sein, bin ik der al wurch fan, mar dochs. Yn myn miening is it heul lestich om dizze twa oplossingen te fergelykjen, mar wy kinne perfoarst sizze dat der neidielen binne yn beide oplossingen en as jo ien oplossing kieze moatte jo de foar- en neidielen weagje.
As OpenStack in community-oandreaune oplossing is, dan hat VMWare it rjocht om allinich te dwaan wat it wol (lês - wat der profitabel foar is) en dit is logysk - om't it in kommersjeel bedriuw is dat wend is om jild te meitsjen fan har kliïnten. Mar d'r is ien grut en fet MAAR - jo kinne fan OpenStack ôf komme, bygelyks fan Nokia, en mei in bytsje kosten oerskeakelje nei in oplossing fan bygelyks Juniper (Contrail Cloud), mar jo binne net wierskynlik te kinnen fan VMWare ôf. . Foar my sjogge dizze twa oplossingen sa út - Openstack (ferkeaper) is in ienfâldige koai wêryn jo wurde set, mar jo hawwe in kaai en jo kinne op elk momint ferlitte. VMWare is in gouden koai, de eigner hat de kaai foar de koai en it sil jo in protte kostje.
Ik befoarderje net it earste produkt of it twadde - jo kieze wat jo nedich binne. Mar as ik sa'n kar hie, soe ik beide oplossingen kieze - VMWare foar de IT-wolk (lege loads, maklik behear), OpenStack fan guon leveransiers (Nokia en Juniper leverje heul goede turnkey-oplossingen) - foar de Telecom-wolk. Ik soe Openstack net brûke foar pure IT - it is as sparrows sjitte mei in kanon, mar ik sjoch gjin kontraindikaasjes foar it brûken fan it oars as oerstalligens. It brûken fan VMWare yn telekommunikaasje is lykwols as it ferfieren fan smoarge stiennen yn in Ford Raptor - it is prachtich fan bûten, mar de bestjoerder moat 10 reizen meitsje ynstee fan ien.
Yn myn miening is it grutste neidiel fan VMWare syn folsleine slutenens - it bedriuw sil jo gjin ynformaasje jaan oer hoe't it wurket, bygelyks vSAN of wat der yn 'e hypervisor kernel is - it is gewoan net rendabel foar it - dat is, jo sille nea in ekspert wurden yn VMWare - sûnder ferkeaper-stipe binne jo feroardiele (heul faak moetsje ik VMWare-eksperts dy't ferbjustere binne troch triviale fragen). Foar my keapet VMWare in auto mei de kap op slot - ja, jo kinne spesjalisten hawwe dy't de timingriem kinne feroarje, mar allinich dejinge dy't jo dizze oplossing ferkocht kin de kap iepenje. Persoanlik hâld ik net fan oplossingen dêr't ik net yn passe kin. Jo sille sizze dat jo miskien net hoege te gean ûnder de motorkap. Ja, dit is mooglik, mar ik sil nei jo sjen as jo in grutte funksje yn 'e wolk moatte gearstalle fan 20-30 firtuele masines, 40-50 netwurken, wêrfan de helte nei bûten wol, en de twadde helte freget om SR-IOV-fersnelling, oars sille jo in pear tsientallen fan dizze auto's mear nedich wêze - oars sil de prestaasjes net genôch wêze.
D'r binne oare stânpunten, dus allinich kinne jo beslute wat jo kieze en, it wichtichste, jo sille dan ferantwurdlik wêze foar jo kar. Dit is gewoan myn miening - in persoan dy't op syn minst 4 produkten hat sjoen en oanrekke - Nokia, Juniper, Red Hat en VMWare. Dat is, ik haw wat te fergelykjen mei.
Boarne: www.habr.com