Wolkrekenaarkunde dring dieper en dieper in ons lewens deur en daar is waarskynlik nie 'n enkele persoon wat ten minste een keer geen wolkdienste gebruik het nie. Wat 'n wolk is en hoe dit werk, weet min mense egter, selfs op die vlak van 'n idee. 5G word 'n werklikheid en telekommunikasie-infrastruktuur begin van pooloplossings na wolkoplossings beweeg, soos dit gedoen het toe dit van alle-hardeware-oplossings na gevirtualiseerde "pilare" beweeg het.
Vandag sal ons praat oor die innerlike wêreld van wolkinfrastruktuur, ons sal veral die basiese beginsels van die netwerkdeel ontleed.
Wat is 'n wolk? Dieselfde virtualisering - 'n profielaansig?
Meer as 'n logiese vraag. Nee - dit is nie virtualisering nie, hoewel dit nie daarsonder sou kon klaarkom nie. Oorweeg twee definisies:
Wolkberekening (hierna na verwys as die Wolk) is 'n model vir die verskaffing van gebruikersvriendelike toegang tot verspreide rekenaarhulpbronne wat ontplooi en op aanvraag uitgevoer moet word met die laagste moontlike vertraging en minimale koste vir die diensverskaffer.
Virtualisering - dit is die vermoë om een fisiese entiteit (byvoorbeeld 'n bediener) in verskeie virtuele te verdeel, waardeur die benutting van hulpbronne verhoog word (byvoorbeeld, jy het 3 bedieners met 25-30 persent gelaai, na virtualisering kry jy 1 bediener gelaai met 80-90 persent). Natuurlik vreet virtualisasie sommige van die hulpbronne weg - jy moet die hiperviser voed, maar soos die praktyk getoon het, is die speletjie die kers werd. 'n Ideale voorbeeld van virtualisering is VMWare, wat uitstekend is om virtuele masjiene voor te berei, of byvoorbeeld KVM, wat ek verkies, maar dit is reeds 'n kwessie van smaak.
Ons gebruik self virtualisering sonder dat ons dit besef, en selfs ysterrouters gebruik reeds virtualisering – byvoorbeeld, in die jongste weergawe van JunOS word die bedryfstelsel as 'n virtuele masjien bo-op die intydse linux-verspreiding (Wind River 9) geïnstalleer. Maar virtualisasie is nie die wolk nie, maar die wolk kan nie sonder virtualisering bestaan nie.
Virtualisering is een van die boustene waarop die wolk gebou is.
Dit sal nie werk om 'n wolk te maak bloot deur verskeie hiperviseerders in een L2-domein te versamel, 'n paar yaml-speelboeke by te voeg om vlans outomaties deur 'n soort ansible te registreer en iets soos 'n orkestrasiestelsel daarop te vul om outomaties virtuele masjiene te skep nie. Meer presies, dit sal blyk, maar die gevolglike Frankenstein is nie die wolk wat ons nodig het nie, alhoewel dit vir iemand is, miskien is dit vir iemand die uiteindelike droom. Daarbenewens, as jy dieselfde Openstack neem, is dit in werklikheid steeds Frankenstein, maar tog, laat ons nie nou daaroor praat nie.
Maar ek verstaan dat uit die definisie wat hierbo aangebied is, dit nie heeltemal duidelik is wat eintlik 'n wolk genoem kan word nie.
Daarom lys die dokument van NIST (Nasionale Instituut vir Standaarde en Tegnologie) 5 hoofkenmerke wat 'n wolkinfrastruktuur moet hê:
Lewer diens op versoek. Die gebruiker moet gratis toegang kry tot die rekenaarhulpbronne wat aan hom toegeken is (soos netwerke, virtuele skywe, geheue, verwerkerkerne, ens.), en hierdie hulpbronne moet outomaties verskaf word - dit wil sê sonder ingryping van die diensverskaffer.
Wye diensbeskikbaarheid. Toegang tot hulpbronne moet verskaf word deur standaardmeganismes om beide standaard rekenaars en dun kliënte en mobiele toestelle te kan gebruik.
Die kombinasie van hulpbronne in poele. Hulpbronpoele moet hulpbronne terselfdertyd aan verskeie kliënte verskaf, om te verseker dat kliënte geïsoleer is en nie met mekaar inmeng en om hulpbronne meeding nie. Netwerke is ook by die poele ingesluit, wat die moontlikheid aandui om gekruiste adressering te gebruik. Poele moet skaal op aanvraag ondersteun. Die gebruik van poele laat jou toe om die nodige vlak van fouttoleransie van hulpbronne en onttrekking van fisiese en virtuele hulpbronne te verskaf - die ontvanger van die diens word eenvoudig voorsien van die stel hulpbronne wat hy versoek het (waar hierdie hulpbronne fisies geleë is, op hoeveel bedieners en skakelaars - die kliënt gee nie om nie). 'n Mens moet egter die feit in ag neem dat die verskaffer deursigtige bespreking van hierdie hulpbronne moet verseker.
Vinnige aanpassing by verskillende toestande. Dienste moet buigsaam wees—verskaf hulpbronne vinnig, hertoewys dit, voeg hulpbronne by of verminder op versoek van die kliënt, en die kliënt moet die gevoel hê dat wolkhulpbronne eindeloos is. Vir maklike begrip, sien jy byvoorbeeld nie 'n waarskuwing dat 'n deel van jou skyfspasie in Apple iCloud verdwyn het nie as gevolg van die feit dat die hardeskyf op die bediener gebreek het en die skywe breek. Boonop is die moontlikhede van hierdie diens van u kant byna onbeperk - u benodig 2 TB - geen probleem nie, u het betaal en ontvang. Net so kan jy 'n voorbeeld gee met Google.Drive of Yandex.Disk.
Die vermoë om die diens wat gelewer word te meet. Wolkstelsels behoort verbruikte hulpbronne outomaties te beheer en te optimaliseer, terwyl hierdie meganismes deursigtig moet wees vir beide die gebruiker en die diensverskaffer. Dit wil sê, jy kan altyd kyk hoeveel hulpbronne jy en jou kliënte verbruik.
Dit is die moeite werd om die feit in ag te neem dat hierdie vereistes hoofsaaklik vereistes vir 'n publieke wolk is, dus vir 'n private wolk (dit wil sê 'n wolk wat vir die maatskappy se interne behoeftes bekendgestel is), kan hierdie vereistes effens aangepas word. Hulle moet egter steeds vervul word, anders kry ons nie al die voordele van wolkrekenaars nie.
Hoekom het ons 'n wolk nodig?
Enige nuwe of bestaande tegnologie, enige nuwe protokol word egter vir iets geskep (wel, behalwe vir RIP-ng, natuurlik). 'n Protokol ter wille van 'n protokol word deur niemand benodig nie (wel, behalwe vir RIP-ng, natuurlik). Dit is logies dat die Wolk geskep word om 'n soort diens aan die gebruiker / kliënt te lewer. Ons is almal vertroud met ten minste 'n paar wolkdienste, soos Dropbox of Google.Docs, en ek glo dat die meeste van hulle dit suksesvol gebruik - byvoorbeeld, hierdie artikel is geskryf met behulp van die Google.Docs-wolkdiens. Maar die wolkdienste wat aan ons bekend is, is slegs deel van die vermoëns van die wolk - meer presies, dit is slegs 'n SaaS-tipe diens. Ons kan 'n wolkdiens op drie maniere verskaf: in die vorm van SaaS, PaaS of IaaS. Watter diens jy benodig hang af van jou begeertes en vermoëns.
Kom ons kyk na elkeen in volgorde:
Sagteware as 'n diens (SaaS) is 'n model vir die verskaffing van 'n volwaardige diens aan 'n kliënt, byvoorbeeld 'n posdiens soos Yandex.Mail of Gmail. In hierdie diensleweringsmodel doen jy as kliënt eintlik niks anders as om die dienste te gebruik nie – dit wil sê, jy hoef nie te dink aan die opstel van die diens, sy fouttoleransie of oortolligheid nie. Die belangrikste ding is om nie u wagwoord te kompromitteer nie, die verskaffer van hierdie diens sal die res vir u doen. Uit die oogpunt van die diensverskaffer is hy ten volle verantwoordelik vir die hele diens – van bedienerhardeware en gasheerbedryfstelsels tot databasis- en sagteware-instellings.
Platform as 'n diens (PaaS) - wanneer hierdie model gebruik word, voorsien die diensverskaffer die kliënt van 'n werkstuk vir die diens, byvoorbeeld, kom ons neem 'n webbediener. Die diensverskaffer het die kliënt voorsien van 'n virtuele bediener (in werklikheid 'n stel hulpbronne, soos RAM / SVE / Berging / Nets, ens.), en selfs die bedryfstelsel en die nodige sagteware op hierdie bediener geïnstalleer, maar die kliënt self konfigureer al hierdie goedheid en vir die diens se prestasie antwoord die kliënt. Die diensverskaffer, soos in die vorige geval, is verantwoordelik vir die prestasie van fisiese toerusting, hipervisers, die virtuele masjien self, sy netwerkbeskikbaarheid, ens., maar die diens self is reeds buite sy verantwoordelikheidsgebied.
Infrastruktuur as 'n diens (IaaS) - hierdie benadering is reeds meer interessant, om die waarheid te sê, die diensverskaffer voorsien die kliënt van 'n volledige gevirtualiseerde infrastruktuur - dit wil sê, 'n soort stel (poel) hulpbronne, soos CPU Cores, RAM, Networks, ens. Alles anders is aan die kliënt - wat die kliënt met hierdie hulpbronne wil doen binne die poel wat aan hom toegeken is (kwota) - is dit nie besonder belangrik vir die verskaffer nie. As die kliënt sy eie vEPC wil skep of selfs 'n mini-operateur wil maak en kommunikasiedienste wil verskaf - geen twyfel nie - doen dit. In so 'n scenario is die diensverskaffer verantwoordelik vir die verskaffing van hulpbronne, hul fouttoleransie en beskikbaarheid, sowel as vir die bedryfstelsel, wat dit moontlik maak om hierdie hulpbronne saam te voeg en aan die kliënt te voorsien met die vermoë om hulpbronne te eniger tyd te verhoog of te verminder die versoek van die kliënt. Die kliënt konfigureer alle virtuele masjiene en ander klatergoud deur die selfdiensportaal en konsoles, insluitend die toewysing van netwerke (behalwe vir eksterne netwerke).
Wat is OpenStack?
In al drie opsies benodig die diensverskaffer 'n bedryfstelsel wat hulle in staat sal stel om 'n wolkinfrastruktuur te skep. Trouens, met SaaS is meer as een departement verantwoordelik vir die hele tegnologiestapel - daar is 'n departement wat verantwoordelik is vir die infrastruktuur - dit wil sê, dit verskaf IaaS aan 'n ander departement, hierdie departement verskaf SaaS aan die kliënt. OpenStack is een van die wolkbedryfstelsels wat jou toelaat om 'n klomp skakelaars, bedieners en bergingstelsels in 'n enkele hulpbronpoel te versamel, hierdie gemeenskaplike poel in subpoele (huurders) te verdeel en hierdie hulpbronne aan kliënte oor die netwerk te verskaf.
OpenStack is 'n wolkbedryfstelsel wat jou toelaat om groot poele rekenaarhulpbronne, databerging en netwerkhulpbronne te beheer, wat voorsien en bestuur word deur API met behulp van standaard verifikasiemeganismes.
Met ander woorde, dit is 'n stel gratis sagtewareprojekte wat ontwerp is om wolkdienste (beide publiek en privaat) te skep - dit wil sê 'n stel gereedskap wat jou toelaat om bediener- en skakeltoerusting in 'n enkele poel hulpbronne te kombineer, te bestuur hierdie hulpbronne, wat die nodige vlak van fouttoleransie verskaf.
Ten tyde van hierdie skrywe lyk die OpenStack-struktuur soos volg:
Foto geneem uit
Elkeen van die komponente waaruit OpenStack bestaan, verrig 'n spesifieke funksie. Hierdie verspreide argitektuur laat jou toe om die stel funksionele komponente wat jy nodig het in die oplossing in te sluit. Sommige van die komponente is egter wortelkomponente en die verwydering daarvan sal lei tot volledige of gedeeltelike onwerkbaarheid van die oplossing as geheel. Hierdie komponente word algemeen na verwys as:
- Dashboard - Webgebaseerde GUI vir die bestuur van OpenStack-dienste
- Keystone - 'n gesentraliseerde identiteitsdiens wat stawing- en magtigingsfunksies vir ander dienste verskaf, sowel as die bestuur van gebruikersbewyse en hul rolle.
- neutron - 'n netwerkdiens wat konneksie verskaf tussen die koppelvlakke van verskeie OpenStack-dienste (insluitend konneksie tussen VM's en hul toegang tot die buitewêreld)
- slak - bied toegang tot blokberging vir virtuele masjiene
- New - lewensiklusbestuur van virtuele masjiene
- oogopslag - 'n bewaarplek van virtuele masjienbeelde en kiekies
- Swift - bied toegang tot voorwerpberging
- Plafonmeter - 'n diens wat die vermoë bied om telemetrie te versamel en beskikbare en verbruikende hulpbronne te meet
- Hitte — orkestrasie gebaseer op sjablone vir outomatiese skepping en voorsiening van hulpbronne
'n Volledige lys van alle projekte en hul doel kan besigtig word .
Elkeen van die OpenStack-komponente is 'n diens wat verantwoordelik is vir 'n spesifieke funksie en bied 'n API vir die bestuur van hierdie funksie en interaksie met ander dienste van die wolkbedryfstelsel om 'n enkele infrastruktuur te skep. Nova bied byvoorbeeld rekenaarhulpbronbestuur en 'n API vir toegang tot hulpbrondatakonfigurasie, Glance verskaf beeldbestuur en 'n API vir die bestuur daarvan, Cinder verskaf blokberging en 'n API om dit te bestuur, ensovoorts. Alle funksies is op 'n baie noue manier met mekaar verbind.
As ons egter oordeel, is alle dienste wat in OpenStack loop uiteindelik 'n soort virtuele masjien (of houer) wat aan die netwerk gekoppel is. Die vraag ontstaan - hoekom het ons soveel elemente nodig?
Kom ons gaan deur die algoritme om 'n virtuele masjien te skep en dit aan die netwerk en aanhoudende berging in Openstack te koppel.
- Wanneer jy 'n versoek skep om 'n motor te skep, of dit nou 'n versoek via Horizon (Dashboard) of 'n versoek via die CLI is, is die eerste ding wat gebeur die magtiging van jou versoek op Keystone - kan jy 'n motor skep, het of die reg om hierdie netwerk te gebruik, doen jou kwotaprojek, ens.
- Keystone staaf jou versoek en genereer 'n bekragtigingstoken in die antwoordboodskap, wat later gebruik sal word. Nadat 'n antwoord van Keystone ontvang is, word die versoek na Nova (nova api) gestuur.
- Nova-api kontroleer die geldigheid van jou versoek deur Keystone te kontak deur die voorheen gegenereerde magtigingsteken te gebruik
- Keystone voer stawing uit en verskaf inligting oor toestemmings en beperkings gebaseer op hierdie magtigingsteken.
- Nova-api skep 'n nuwe VM-inskrywing in nova-databasis en stuur 'n versoek om 'n masjien te skep na nova-skeduleerder.
- Nova-skeduleerder kies die gasheer (nodusrekenaar) waarop die VM ontplooi sal word, gebaseer op die gegewe parameters, gewigte en sones. 'n Rekord hiervan en die VM ID word na nova-databasis geskryf.
- Vervolgens roep nova-skeduleerder nova-compute met 'n versoek om die instansie te ontplooi. Nova-compute roep nova-geleier om inligting oor masjienparameters te verkry (nova-geleier is 'n nova-element wat optree as 'n instaanbediener tussen nova-databasis en nova-rekenaar, wat die aantal versoeke na nova-databasis beperk om probleme te vermy met databasiskonsekwentheidladingvermindering).
- Nova-conductor haal die gevraagde inligting uit nova-databasis en gee dit deur aan nova-compute.
- Vervolgens kyk nova-compute-oproepe om die beeld-ID te kry. Glace bekragtig die versoek in Keystone en gee die gevraagde inligting terug.
- Nova-compute roep neutron vir inligting oor netwerkparameters. Net soos 'n oogopslag, bekragtig neutron die versoek in Keystone, skep dan 'n inskrywing in die databasis (poort-ID, ens.), skep 'n versoek om 'n poort te skep, en stuur die gevraagde inligting terug na nova-compute.
- Nova-compute roep cinder met 'n versoek om volume aan die virtuele masjien toe te ken. Soortgelyk aan 'n oogopslag, bevestig cider die versoek in Keystone, skep 'n versoek om 'n volume te skep en gee die gevraagde inligting terug.
- Nova-compute roep libvirt met 'n versoek om 'n virtuele masjien met die gegewe parameters te ontplooi.
Trouens, 'n oënskynlik eenvoudige operasie om 'n eenvoudige virtuele masjien te skep, verander in so 'n maalkolk van api-oproepe tussen elemente van die wolkplatform. Verder, soos u kan sien, bestaan selfs die voorheen aangewese dienste ook uit kleiner komponente, waartussen interaksie plaasvind. Die skep van 'n masjien is slegs 'n klein deel van wat die wolkplatform jou toelaat om te doen - daar is 'n diens wat verantwoordelik is vir die balansering van verkeer, 'n diens verantwoordelik vir blokberging, 'n diens verantwoordelik vir DNS, 'n diens wat verantwoordelik is vir die voorsiening van kaalmetaalbedieners, ens. Die wolk laat jou toe om jou virtuele masjiene soos 'n trop skape te behandel (anders as virtualisering). As iets met die masjien in jou virtuele omgewing gebeur het - jy herstel dit vanaf rugsteun, ens., terwyl wolktoepassings so gebou is dat die virtuele masjien nie so 'n belangrike rol speel nie - die virtuele masjien het "gesterf" - dit doen maak nie saak nie - net 'n nuwe een is geskep motor gebaseer op die sjabloon en, soos hulle sê, die span het nie die verlies van 'n vegter opgemerk nie. Natuurlik maak dit voorsiening vir die teenwoordigheid van orkestrasiemeganismes - met behulp van Heat-sjablone kan u 'n komplekse funksie wat uit dosyne netwerke en virtuele masjiene bestaan sonder enige probleme ontplooi.
Dit is altyd die moeite werd om in gedagte te hou dat daar geen wolkinfrastruktuur sonder 'n netwerk is nie - elke element is op een of ander manier met ander elemente deur die netwerk in wisselwerking. Daarbenewens het die wolk 'n absoluut nie-statiese netwerk. Natuurlik is die onderlaagnetwerk selfs min of meer staties - nuwe nodusse en skakelaars word nie elke dag bygevoeg nie, maar die oorlegkomponent kan en sal onvermydelik voortdurend verander - nuwe netwerke sal bygevoeg of verwyder word, nuwe virtuele masjiene sal verskyn en oues sal sterf. En soos u onthou uit die definisie van die wolk wat heel aan die begin van die artikel gegee word, moet hulpbronne outomaties aan die gebruiker toegewys word en met die minste (of beter sonder) ingryping van die diensverskaffer. Dit wil sê, die tipe verskaffing van netwerkhulpbronne wat nou in die vorm van 'n frontend in die vorm van jou persoonlike rekening beskikbaar is via http / https en Vasily die netwerkingenieur aan diens as 'n backend is nie 'n wolk nie, selfs al het Vasily agt hande.
Neutron, synde 'n netwerkdiens, bied 'n API vir die bestuur van die netwerkdeel van die wolkinfrastruktuur. Die diens verskaf die gesondheid en bestuur van die netwerkdeel van Openstack deur 'n abstraksielaag genaamd Network-as-a-Service (NaaS) te verskaf. Dit wil sê, die netwerk is dieselfde virtuele meetbare eenheid, soos die virtuele kerne van die SVE of die hoeveelheid RAM.
Maar voordat ons verder gaan na die argitektuur van die netwerkdeel van OpenStack, kom ons kyk na hoe hierdie netwerk in OpenStack werk en hoekom die netwerk 'n belangrike en integrale deel van die wolk is.
So ons het twee ROOI kliënt virtuele masjiene en twee GROEN kliënt virtuele masjiene. Kom ons neem aan dat hierdie masjiene op hierdie manier op twee hipervisors geleë is:
Op die oomblik is dit net virtualisering van 4 bedieners en niks meer nie, aangesien al wat ons tot dusver gedoen het is om 4 bedieners te gevirtualiseer en op twee fisiese bedieners te plaas. En tog is hulle nie eers aan die netwerk gekoppel nie.
Om 'n wolk te kry, moet ons verskeie komponente byvoeg. Eerstens virtualiseer ons die netwerkdeel - ons moet hierdie 4 masjiene in pare koppel, en die kliënte wil presies die L2-verbinding hê. U kan natuurlik die skakelaar gebruik en 'n stam in sy rigting opstel en alles oplos met behulp van die linux-brug, of vir meer gevorderde openvswitch-gebruikers (ons sal later daarna terugkeer). Maar daar kan baie netwerke wees, en om L2 voortdurend deur 'n skakelaar te druk is nie die beste idee nie - so verskillende departemente, 'n dienstoonbank, maande se wag vir 'n aansoek om voltooi te word, weke se probleemoplossing - in die moderne wêreld, hierdie benadering werk nie meer nie. En hoe gouer die maatskappy dit verstaan, hoe makliker is dit om vorentoe te beweeg. Daarom sal ons tussen hiperviseerders 'n L3-netwerk kies waardeur ons virtuele masjiene sal kommunikeer, en bo-op hierdie L3-netwerk sal ons virtuele oorleg L2 (oorleg) netwerke bou waar die verkeer van ons virtuele masjiene sal loop. Inkapseling kan GRE, Geneve of VxLAN wees. Kom ons fokus vir eers op laasgenoemde, hoewel dit nie besonder belangrik is nie.
Ons moet VTEP iewers opspoor (ek hoop almal is vertroud met VxLAN-terminologie). Aangesien die L3-netwerk ons bedieners onmiddellik verlaat, verhoed niks ons om VTEP op die bedieners self te plaas nie, en OVS (OpenvSwitch) is perfek in staat om dit te doen. As gevolg hiervan het ons die volgende struktuur gekry:
Aangesien die verkeer tussen die VM's geskei moet word, sal die poorte na die virtuele masjiene verskillende vlan-nommers hê. Die merkernommer speel slegs 'n rol binne een virtuele skakelaar, aangesien ons dit maklik kan verwyder wanneer ons in VxLAN inkapsel, aangesien ons VNI sal hê.
Nou kan ons sonder enige probleme ons masjiene en virtuele netwerke vir hulle skep.
Wat egter as die kliënt 'n ander masjien het, maar op 'n ander netwerk is? Ons benodig wortels tussen netwerke. Ons sal 'n eenvoudige opsie ontleed wanneer gesentraliseerde wortels gebruik word - dit wil sê, verkeer word deur spesiale toegewyde netwerknodusse gelei (wel, as 'n reël word dit gekombineer met beheernodusse, so ons sal dieselfde ding hê).
Dit blyk niks ingewikkeld te wees nie - ons maak 'n brug-koppelvlak op die beheernodus, ry verkeer daarheen en van daar af stuur ons dit na waar ons dit nodig het. Maar die probleem is dat die ROOI kliënt die 10.0.0.0/24 netwerk wil gebruik en die GROEN kliënt wil die 10.0.0.0/24 netwerk gebruik. Dit wil sê, ons begin die kruising van adresruimtes. Daarbenewens wil kliënte nie hê dat ander kliënte na hul interne netwerke kan roeteer nie, wat logies is. Om die netwerke en verkeer van hierdie kliënte te skei, sal ons 'n aparte naamspasie vir elkeen van hulle toewys. Naamruimte is in werklikheid 'n kopie van die Linux-netwerkstapel, dit wil sê, kliënte in naamruimte ROOI is heeltemal geïsoleer van kliënte vanaf naamruimte GREEN (wel, óf roetering tussen hierdie kliëntnetwerke word toegelaat deur versteknaamruimte of reeds op hoër vervoertoerusting).
Dit wil sê, ons kry die volgende skema:
L2 tonnels konvergeer van alle rekenaarnodusse na die beheer een. nodus waar die L3-koppelvlak vir hierdie netwerke geleë is, elk in 'n toegewyde naamruimte vir isolasie.
Ons het egter die belangrikste ding vergeet. Die virtuele masjien moet 'n diens aan die kliënt verskaf, dit wil sê, dit moet ten minste een eksterne koppelvlak hê waardeur dit bereik kan word. Dit wil sê, ons moet na die buitewêreld gaan. Hier is verskillende opsies. Kom ons doen die eenvoudigste opsie. Kom ons voeg kliënte by een netwerk wat geldig sal wees in die verskaffer se netwerk en nie met ander netwerke sal oorvleuel nie. Netwerke kan ook kruis en kyk na verskillende VRF's aan die kant van die verskaffernetwerk. Die netwerkdata sal ook in die naamruimte van elk van die kliënte woon. Hulle sal egter steeds na die buitewêreld gaan deur een fisiese (of band, wat meer logies is) koppelvlak. Om kliëntverkeer te skei, sal verkeer wat na buite gaan, VLAN-gemerk wees met 'n merker wat aan die kliënt toegeken is.
As gevolg hiervan het ons die volgende skema gekry:
'n Redelike vraag is waarom nie self poorte op die rekenaarnodusse maak nie? Dit is nie 'n groot probleem nie, bowendien, wanneer jy die verspreide router (DVR) aanskakel, sal dit so werk. In hierdie scenario oorweeg ons die eenvoudigste opsie met 'n gesentraliseerde poort, wat by verstek in Openstack gebruik word. Vir hoëladingsfunksies sal hulle beide 'n verspreide router en versnellingstegnologieë soos SR-IOV en Passthrough gebruik, maar soos hulle sê, dit is 'n heeltemal ander storie. Kom ons gaan eers met die basiese deel, en dan gaan ons in op die besonderhede.
Eintlik is ons skema reeds in werking, maar daar is 'n paar nuanses:
- Ons moet op een of ander manier ons masjiene beskerm, dit wil sê, 'n filter op die skakelaarkoppelvlak na die kliënt hang.
- Maak dit moontlik om outomaties 'n ip-adres deur 'n virtuele masjien te verkry sodat jy dit nie elke keer deur die konsole hoef in te voer en die adres voor te skryf nie.
Kom ons begin met motorbeskerming. Om dit te doen, kan jy die banale iptables gebruik, hoekom nie.
Dit wil sê, nou het ons topologie 'n bietjie meer ingewikkeld geword:
Kom ons gaan verder. Ons moet 'n DHCP-bediener byvoeg. Die mees ideale plek om DHCP-bedieners vir elk van die kliënte op te spoor, is die beheernodus wat reeds hierbo genoem is, waar naamruimtes geleë is:
Daar is egter 'n klein probleem. Wat as alles herlaai en alle DHCP-huurinligting verdwyn. Dit is logies dat die masjiene nuwe adresse sal kry, wat nie baie gerieflik is nie. Daar is twee uitweg - óf gebruik domeinname en voeg 'n DNS-bediener by vir elke kliënt, dan sal die adres nie baie belangrik vir ons wees nie (soortgelyk aan die netwerkdeel in k8s) - maar daar is 'n probleem met eksterne netwerke, aangesien adresse kan ook via DHCP in hulle uitgereik word - u benodig sinchronisasie met DNS-bedieners in die wolkplatform en 'n eksterne DNS-bediener, wat na my mening nie baie buigsaam is nie, maar dit is heel moontlik. Of die tweede opsie is om metadata te gebruik - dit wil sê om inligting te stoor oor die adres wat aan die masjien uitgereik is sodat die DHCP-bediener weet watter adres om aan die masjien uit te reik as die masjien reeds die adres ontvang het. Die tweede opsie is eenvoudiger en meer buigsaam, aangesien dit jou toelaat om bykomende inligting oor die motor te stoor. Kom ons voeg nou die agent se metadata by die skema:
Nog 'n kwessie wat ook die moeite werd is om te wy, is die vermoë om een eksterne netwerk deur alle kliënte te gebruik, aangesien eksterne netwerke, as hulle regdeur die netwerk geldig moet wees, dit moeilik sal wees - jy moet voortdurend die toekenning van hierdie netwerke kies en beheer. Die vermoë om 'n enkele eksterne vooraf-gekonfigureerde netwerk vir alle kliënte te gebruik, sal baie nuttig wees wanneer 'n publieke wolk geskep word. Dit sal die ontplooiing van masjiene vereenvoudig, aangesien ons nie die adresdatabasis hoef te raadpleeg en 'n unieke adresspasie vir elke kliënt se eksterne netwerk te kies nie. Daarbenewens kan ons vooraf 'n eksterne netwerk voorskryf en ten tyde van ontplooiing sal ons slegs eksterne adresse met kliëntmasjiene hoef te assosieer.
En hier kom NAT tot die redding - ons sal dit eenvoudig vir kliënte moontlik maak om toegang tot die buitewêreld te kry deur die versteknaamruimte deur NAT-vertaling te gebruik. Wel, hier is 'n probleempie. Dit is goed as die kliëntbediener as 'n kliënt werk, en nie as 'n bediener nie - dit wil sê, dit begin en aanvaar nie verbindings nie. Maar vir ons sal dit andersom wees. In hierdie geval moet ons bestemming NAT maak sodat wanneer verkeer ontvang word, die beheernodus verstaan dat hierdie verkeer bedoel is vir kliënt A se virtuele masjien A, wat beteken dat ons NAT-vertaling vanaf 'n eksterne adres moet maak, byvoorbeeld 100.1.1.1. 10.0.0.1 na 'n interne adres 100. In hierdie geval, hoewel alle kliënte dieselfde netwerk sal gebruik, word interne isolasie heeltemal bewaar. Dit wil sê, ons moet dNAT en sNAT op die beheernodus doen. Gebruik 'n enkele netwerk met toewysing van drywende adresse of eksterne netwerke, of albei gelyktydig - dit word bepaal deur die feit dat jy dit in die wolk wil vasmaak. Ons sal nie ook drywende adresse op die diagram plaas nie, maar sal die voorheen bygevoegde eksterne netwerke verlaat - elke kliënt het sy eie eksterne netwerk (in die diagram word hulle as vlan 200 en XNUMX op die eksterne koppelvlak aangedui).
Gevolglik het ons 'n interessante en terselfdertyd weldeurdagte oplossing gekry wat 'n sekere buigsaamheid het, maar tot dusver nie fouttoleransiemeganismes het nie.
Eerstens het ons net een beheernodus - die mislukking daarvan sal lei tot die ineenstorting van alle stelsels. Om hierdie probleem op te los, moet jy ten minste 'n kworum van 3 nodusse maak. Kom ons voeg dit by die diagram:
Natuurlik is alle nodusse gesinchroniseer en wanneer die aktiewe nodus verlaat, sal 'n ander nodus sy pligte oorneem.
Die volgende kwessie is virtuele masjienskywe. Op die oomblik word dit op die hypervisors self gestoor, en in die geval van probleme met die hypervisor, verloor ons alle data - en die teenwoordigheid van 'n klopjag sal nie hier help as ons nie die skyf verloor nie, maar die hele bediener. Om dit te doen, moet ons 'n diens maak wat sal dien as 'n frontend vir enige berging. Watter soort berging dit sal wees, is nie vir ons besonder belangrik nie, maar dit behoort ons data te beskerm teen mislukking van beide die skyf en die nodus, en moontlik die hele kabinet. Hier is verskeie opsies - natuurlik is daar SAN-netwerke met Fibre Channel, maar kom ons wees eerlik - FC is reeds 'n oorblyfsel van die verlede - 'n analoog van E1 in vervoer - ja, ek stem saam, dit word steeds gebruik, maar slegs waar dit onmoontlik is daarsonder. Daarom sal ek nie vrywillig die FC-netwerk in 2020 ontplooi nie, met die wete dat daar ander meer interessante alternatiewe is. Alhoewel vir elkeen sy eie en miskien is daar diegene wat glo dat FC met al sy beperkings al is wat ons nodig het - ek sal nie stry nie, elkeen het hul eie mening. Die interessantste oplossing na my mening is egter die gebruik van SDS, soos Ceph.
Ceph laat jou toe om 'n hoogs beskikbare bergingsoplossing te bou met 'n klomp moontlike oortolligheidsopsies, van pariteitskodes (soortgelyk aan raid 5 of 6) tot volledige replikasie van data na verskillende skywe, met inagneming van die ligging van skywe in bedieners en bedieners in kaste, ens.
Jy benodig nog 3 nodusse om Ceph te bou. Interaksie met die berging sal ook uitgevoer word via die netwerk met behulp van blok-, objek- en lêerbergingsdienste. Kom ons voeg berging by die skema:
Let wel: jy kan ook hipergekonvergeerde rekenaarnodusse maak - dit is die konsep om verskeie funksies op een nodus te kombineer - byvoorbeeld berging + rekenaar - moenie spesiale nodusse vir ceph-berging toeken nie. Ons sal dieselfde foutverdraagsame skema kry - aangesien SDS die data sal reserveer met die vlak van oortolligheid wat ons gespesifiseer het. Hipergekonvergeerde nodusse is egter altyd 'n kompromie - aangesien 'n bergingsnodus nie net die lug verhit soos dit met die eerste oogopslag lyk nie (aangesien daar geen virtuele masjiene op is nie) - dit spandeer SVE-hulpbronne om SDS te diens (in werklikheid doen dit alles replikasies in die agtergrond, herstel na mislukkings van nodusse, skywe, ens.). Dit wil sê, jy sal van die rekenkrag van die nodus verloor as jy dit met berging kombineer.
Al hierdie goed moet op een of ander manier bestuur word - ons het iets nodig waardeur ons 'n masjien, 'n netwerk, 'n virtuele router, ens. kan skep. Om dit te doen, voeg 'n diens by die beheernodus wat as 'n dashboard sal optree - die kliënt sal in staat wees om aan hierdie portaal te koppel via http/ https en doen wat dit ook al nodig het (wel, amper).
Gevolglik het ons nou 'n foutverdraagsame stelsel. Alle elemente van hierdie infrastruktuur moet op een of ander manier bestuur word. Daar is voorheen beskryf dat Openstack 'n stel projekte is, wat elkeen 'n spesifieke funksie verskaf. Soos ons kan sien, is daar meer as genoeg elemente wat gekonfigureer en beheer moet word. Vandag sal ons praat oor die netwerk deel.
Neutron argitektuur
In OpenStack is Neutron verantwoordelik vir die koppeling van virtuele masjienpoorte aan 'n gemeenskaplike L2-netwerk, die verskaffing van verkeersroetering tussen VM's wat in verskillende L2-netwerke geleë is, sowel as uitwaartse roetering, verskaffing van dienste soos NAT, Floating IP, DHCP, ens.
Hoëvlakwerking van die netwerkdiens (basiese deel) kan soos volg beskryf word.
Wanneer die VM begin word, sal die netwerkdiens:
- Skep 'n poort vir hierdie VM (of poorte) en stel die DHCP-diens daaroor in kennis;
- 'n Nuwe virtuele netwerktoestel word geskep (via libvirt);
- Die VM koppel aan die poort(e) wat in stap 1 geskep is;
Vreemd genoeg is Neutron gebaseer op standaardmeganismes wat bekend is aan almal wat al ooit in Linux ingeduik het - dit is naamruimtes, iptables, linux-brûe, openvswitch, conntrack, ens.
Dit moet onmiddellik uitgeklaar word dat Neutron nie 'n SDN-beheerder is nie.
Neutron bestaan uit verskeie onderling gekoppelde komponente:
oopstapel-neutron-bediener is 'n daemoon wat met gebruikersversoeke deur die API werk. Hierdie daemon skryf geen netwerkverbindings nie, maar verskaf die nodige inligting aan sy inproppe, wat dan die gewenste netwerkelement konfigureer. Neutron-agente op OpenStack-nodes is by die Neutron-bediener geregistreer.
Neutron-bediener is eintlik 'n toepassing wat in python geskryf is, wat uit twee dele bestaan:
- RUS diens
- Neutron-inprop (kern/diens)
REST-diens is ontwerp om API-oproepe vanaf ander komponente te ontvang (byvoorbeeld 'n versoek om inligting te verskaf, ens.)
Inproppe is inprop-sagtewarekomponente / -modules wat op API-versoeke geroep word - dit wil sê, die toewysing van 'n soort diens vind daardeur plaas. Inproppe word in twee tipes verdeel - diens en wortel. As 'n reël is die wortelinprop hoofsaaklik verantwoordelik vir die bestuur van die adresruimte en L2-verbindings tussen VM's, terwyl diensinproppe reeds bykomende funksionaliteit bied, soos VPN of FW.
Die lys van tans beskikbare inproppe kan byvoorbeeld bekyk word
Daar kan verskeie diensinproppe wees, maar daar kan net een wortelinprop wees.
oopstapel-neutron-ml2 is die standaard Openstack-wortelinprop. Hierdie inprop het 'n modulêre argitektuur (anders as sy voorganger) en konfigureer die netwerkdiens deur die drywers wat daaraan gekoppel is. Ons sal die inprop self 'n bietjie later oorweeg, aangesien dit in werklikheid die buigsaamheid gee wat OpenStack in die netwerkdeel het. Die root plugin kan vervang word (bv. Contrail Networking doen so 'n vervanging).
RPC-diens (rabbitmq-bediener) - 'n diens wat toubestuur en interaksie met ander OpenStack-dienste verskaf, sowel as interaksie tussen netwerkdiensagente.
netwerk agente - agente wat in elke nodus geleë is, waardeur netwerkdienste gekonfigureer word.
Agente is van verskeie tipes.
Die hoofagent is L2 agent. Hierdie agente loop op elk van die hipervisors, insluitend beheernodusse (meer presies, op alle nodusse wat enige diens aan huurders verskaf) en hul hooffunksie is om virtuele masjiene aan 'n gemeenskaplike L2-netwerk te koppel, asook waarskuwings te genereer wanneer enige gebeurtenisse plaasvind (byvoorbeeld deaktiveer/aktiveer die poort).
Die volgende, nie minder belangrike agent nie is L3 agent. By verstek loop hierdie agent uitsluitlik op 'n netwerknodus (dikwels word 'n netwerknodus gekombineer met 'n beheernodus) en verskaf roetering tussen huurdernetwerke (beide tussen sy netwerke en netwerke van ander huurders, en is beskikbaar vir die buitewêreld, wat NAT verskaf. , sowel as DHCP-diens). Wanneer 'n DVR (verspreide router) egter gebruik word, verskyn die behoefte aan 'n L3-inprop ook op rekenaarnodusse.
Die L3-agent gebruik Linux-naamruimtes om elke huurder te voorsien van 'n stel van sy eie geïsoleerde netwerke en die funksionaliteit van virtuele roeteerders wat verkeer lei en poortdienste vir Laag 2-netwerke verskaf.
Databasis - 'n databasis van identifiseerders vir netwerke, subnette, poorte, poele, ens.
Trouens, Neutron aanvaar API-versoeke vanaf die skepping van enige netwerkentiteite, verifieer die versoek en stuur deur RPC (as dit na 'n soort inprop of agent verwys) of REST API (as dit in SDN kommunikeer) na die agente (via plugins) die instruksies wat nodig is om die gevraagde diens te organiseer.
Kom ons gaan nou na die toetsinstallasie (hoe dit ontplooi word en wat dit bevat, sal ons later in die praktiese deel sien) en kyk waar watter komponent geleë is:
(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 ~]$
Eintlik is dit die hele struktuur van Neutron. Nou is dit die moeite werd om tyd aan die ML2-inprop te spandeer.
Modulêre laag 2
Soos hierbo genoem, is die inprop 'n standaard OpenStack-wortelinprop en het 'n modulêre argitektuur.
Die voorganger van die ML2-inprop het 'n monolitiese struktuur gehad, wat dit nie moontlik gemaak het om byvoorbeeld 'n mengsel van verskeie tegnologieë in een installasie te gebruik nie. Byvoorbeeld, jy kon nie beide openvswitch en linuxbridge op dieselfde tyd gebruik nie - óf die eerste óf die tweede. Om hierdie rede is 'n ML2-inprop met sy argitektuur geskep.
ML2 het twee komponente - twee tipes drywers: Tipe drywers en Mechanism drivers.
Tik bestuurders definieer tegnologieë wat gebruik sal word om netwerkverbindings te organiseer, soos VxLAN, VLAN, GRE. In hierdie geval laat die bestuurder jou toe om verskillende tegnologieë te gebruik. Die standaardtegnologie is VxLAN-inkapseling vir oorlegnetwerke en eksterne vlan-netwerke.
Tipe drywers is die volgende tipe netwerke:
Flat - netwerk sonder tagging
VLAN's - gemerkte netwerk
Plaaslike - 'n spesiale tipe netwerk vir alles-in-een installasies (sulke installasies is nodig vir ontwikkelaars of vir opleiding)
GRE - oorleg netwerk met behulp van GRE tonnels
VxLAN - oorleg netwerk met behulp van VxLAN tonnels
Meganisme drywers definieer die middele wat die organisasie verskaf van die tegnologieë wat in die tipe drywer gespesifiseer word - byvoorbeeld openvswitch, sr-iov, opendaylight, OVN, ens.
Afhangende van die implementering van hierdie drywer, sal óf agente wat deur Neutron beheer word gebruik word, óf verbindings met 'n eksterne SDN-beheerder sal gebruik word, wat sorg vir al die kwessies van die organisering van L2-netwerke, roetering, ens.
Byvoorbeeld, as ons ML2 saam met OVS gebruik, dan word 'n L2-agent geïnstalleer op elke rekenaarnodus wat OVS bestuur. As ons egter byvoorbeeld OVN of OpenDayLight gebruik, dan gaan OVS-beheer onder hul jurisdiksie - Neutron gee opdragte aan die kontroleerder deur die root-inprop, en dit doen reeds wat vir hom gesê is.
Kom ons verfris die geheue van Open vSwitch
Op die oomblik is een van die sleutelkomponente van OpenStack Open vSwitch.
Wanneer jy OpenStack installeer sonder enige bykomende SDN van verskaffers soos Juniper Contrail of Nokia Nuage, is OVS die hoofnetwerkkomponent van die wolknetwerk en, saam met iptables, conntrack, naamruimtes, laat jou toe om 'n volwaardige multi-huur-oorlegnetwerk te organiseer. Natuurlik kan hierdie komponent vervang word, byvoorbeeld, wanneer derdeparty-eiendoms (verkoper) SDN-oplossings gebruik word.
OVS is 'n oopbronsagtewareskakelaar wat ontwerp is vir gebruik in gevirtualiseerde omgewings as 'n virtuele verkeersaansender.
Op die oomblik het OVS 'n baie ordentlike funksionaliteit, wat tegnologieë soos QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, ens.
Let wel: Aanvanklik was OVS nie ontwerp as 'n sagteskakelaar vir hoëlading-telekommunikasiefunksies nie en was meer ontwerp vir IT-funksies wat minder bandwydte vereis, soos 'n WEB-bediener of posbediener. OVS word egter gefinaliseer en huidige OVS-implementerings het sy werkverrigting en vermoëns aansienlik verbeter, wat dit moontlik maak om deur telekommunikasie-operateurs met hoogs gelaaide funksies gebruik te word, daar is byvoorbeeld 'n OVS-implementering met DPDK-versnellingsondersteuning.
Daar is drie belangrike OVS-komponente om van bewus te wees:
- Kern module - 'n komponent geleë in die kernspasie wat verkeer verwerk op grond van die reëls wat van die beheerelement ontvang is;
- vSkakel daemon (ovs-vswitchd) is 'n proses wat in gebruikersruimte loop, wat verantwoordelik is vir die programmering van die kernmodule - dit wil sê, dit verteenwoordig direk die logika van die skakelaar
- Databasisbediener is 'n plaaslike databasis geleë op elke gasheer wat OVS bestuur wat die konfigurasie stoor. Deur hierdie module kan SDN-beheerders kommunikeer deur die OVSDB-protokol te gebruik.
Dit alles gaan gepaard met 'n stel diagnostiese en bestuurshulpmiddels, soos ovs-vsctl, ovs-appctl, ovs-ofctl, ens.
Op die oomblik word Openstack wyd deur telekommunikasie-operateurs gebruik om netwerkfunksies daarheen te migreer, soos EPC, SBC, HLR, ens. Sommige funksies kan sonder probleme leef met OVS in die vorm waarin dit is, maar byvoorbeeld EPC-prosesse intekenaarverkeer - dan gaan dit deur 'n groot hoeveelheid verkeer (nou bereik verkeersvolumes 'n paar honderd gigabits per sekonde). Natuurlik is dit nie die beste idee om sulke verkeer deur die kernspasie te bestuur nie (aangesien die expediteur by verstek daar geleë is). Daarom word OVS dikwels geheel en al in gebruikersruimte ontplooi deur DPDK-versnellingstegnologie te gebruik om verkeer van NIC na gebruikersruimte aan te stuur wat die kern omseil.
Let wel: vir 'n wolk wat vir telekommunikasiefunksies ontplooi is, is dit moontlik om verkeer uit te voer vanaf rekenaarnodusse wat OVS direk omseil na skakeltoerusting. Vir hierdie doel word die SR-IOV en Passthrough meganismes gebruik.
Hoe werk dit op 'n regte uitleg?
Wel, kom ons gaan nou oor na die praktiese deel en kyk hoe dit alles in die praktyk werk.
Laat ons eers 'n eenvoudige Openstack-installasie ontplooi. Aangesien ek nie 'n stel bedieners byderhand het vir eksperimente nie, sal ons die uitleg op een fisiese bediener vanaf virtuele masjiene saamstel. Ja, natuurlik is so 'n oplossing nie geskik vir kommersiële doeleindes nie, maar om te sien hoe die netwerk in Openstack werk, is so 'n installasie genoeg vir die oë. Boonop is so 'n installasie vir opleidingsdoeleindes selfs meer interessant - aangesien u verkeer kan vang, ens.
Aangesien ons net die basisgedeelte hoef te sien, kan ons nie verskeie netwerke gebruik nie, maar alles verhoog deur slegs twee netwerke te gebruik, en die tweede netwerk in hierdie uitleg sal uitsluitlik gebruik word om toegang tot die onderwolk en dns-bediener te verkry. Ons sal vir eers nie aan eksterne netwerke raak nie - dit is 'n onderwerp vir 'n aparte groot artikel.
So, kom ons begin in volgorde. Eerstens 'n bietjie teorie. Ons sal Openstack installeer met behulp van TripleO (Openstack op Openstack). Die essensie van TripleO is dat ons Openstack alles-in-een installeer (dit wil sê op een nodus), genoem undercloud, en dan die vermoëns van die ontplooide Openstack gebruik om Openstack te installeer, ontwerp vir uitbuiting, genoem overcloud. Undercloud sal sy vermoë gebruik om fisiese bedieners (kaalmetaal) te bestuur - die Ironic-projek - om hiperviseerders te voorsien wat sal optree as rekenaar-, beheer- en bergingsnodusse. Dit wil sê, ons gebruik geen derdeparty-nutsgoed om Openstack te ontplooi nie - ons ontplooi Openstack met behulp van Openstack. Verder langs die installasie sal dit baie duideliker word, so ons sal nie daar stop en voortgaan nie.
Let wel: In hierdie artikel het ek, ter wille van eenvoud, nie netwerkisolasie vir die interne netwerke van Openstack gebruik nie, maar alles word met slegs een netwerk ontplooi. Die teenwoordigheid of afwesigheid van netwerkisolasie beïnvloed egter nie die basiese funksionaliteit van die oplossing nie - alles sal presies dieselfde werk as wanneer isolasie gebruik word, maar verkeer sal op dieselfde netwerk gaan. Vir 'n kommersiële installasie is dit natuurlik nodig om isolasie te gebruik deur verskillende vlans en koppelvlakke te gebruik. Byvoorbeeld, ceph-bergingbestuursverkeer en direkte dataverkeer (masjientoegange tot skywe, ens.) gebruik verskillende subnette (bergingbestuur en berging) tydens isolasie, en dit laat jou toe om die oplossing meer foutverdraagsaam te maak deur hierdie verkeer te verdeel, vir byvoorbeeld in verskillende poorte, of gebruik verskillende QoS-profiele vir verskillende verkeer sodat die dataverkeer nie die seinverkeer uitdruk nie. In ons geval sal hulle op dieselfde netwerk gaan en in werklikheid beperk dit ons op geen manier nie.
Let wel: Aangesien ons virtuele masjiene in 'n virtuele masjien-gebaseerde omgewing gaan gebruik, moet ons eers geneste virtualisering aktiveer.
U kan kyk of geneste virtualisasie geaktiveer is of nie soos volg nie:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#As jy die letter N sien, aktiveer dan ondersteuning vir geneste virtualisasie volgens enige gids wat jy op die net kry, byvoorbeeld .
Ons moet die volgende skema vanaf virtuele masjiene saamstel:
In my geval, vir die konnektiwiteit van die virtuele masjiene wat deel is van die toekomstige installasie (en ek het 7 van hulle gekry, maar jy kan klaarkom met 4 as jy nie baie hulpbronne het nie), het ek OpenvSwitch gebruik. Ek het een ovs-brug geskep en virtuele masjiene daaraan gekoppel via poortgroepe. Om dit te doen, het ek 'n xml-lêer van die volgende vorm geskep:
[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>Drie poortgroepe word hier verklaar - twee toegang en een stam (laasgenoemde was nodig vir die DNS-bediener, maar jy kan daarsonder klaarkom, of dit op die gasheermasjien verhoog - wat ook al vir jou geriefliker is). Vervolgens, met behulp van hierdie sjabloon, verklaar ons ons s'n deur virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nou wysig ons die konfigurasie van die hypervisor-poorte:
[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 ~]# Let wel: in hierdie scenario sal die adres op die ovs-br1-poort nie beskikbaar wees nie, aangesien dit nie 'n vlan-merker het nie. Om dit reg te stel, moet jy die opdrag sudo ovs-vsctl stel port ovs-br1 tag=100 uitreik. Na 'n herlaai sal hierdie merker egter verdwyn (as iemand weet hoe om dit in plek te laat bly, sal ek baie dankbaar wees). Maar dit is nie so belangrik nie, want ons sal hierdie adres slegs tydens die installasie benodig en sal nie nodig wees wanneer Openstack volledig ontplooi is nie.
Skep dan 'n onderwolkmasjien:
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=ttyS0Tydens installasie stel jy al die nodige parameters, soos masjiennaam, wagwoorde, gebruikers, ntp-bedieners, ens. Jy kan dadelik poorte konfigureer, maar dit is vir my persoonlik makliker om na installasie by die masjien aan te meld deur die konsole en die nodige reg te stel. lêers. As jy reeds 'n klaargemaakte prent het, kan jy dit gebruik, of doen soos ek gedoen het - laai die minimum Centos 7-prent af en gebruik dit om die VM te installeer.
Na suksesvolle installasie behoort jy 'n virtuele masjien te hê waarop jy undercloud kan installeer
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningEerstens installeer ons die nodige gereedskap tydens die installasieproses:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Onderwolk installasie
Ons skep 'n stapelgebruiker, stel 'n wagwoord, voeg dit by sudoer en gee dit die vermoë om wortelopdragte deur sudo uit te voer sonder om 'n wagwoord in te voer:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNou spesifiseer ons die volle naam van undercloud in die gashere-lêer:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Voeg dan die bewaarplekke by en installeer die sagteware wat ons benodig:
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-ansibleLet wel: as jy nie van plan is om ceph te installeer nie, hoef jy nie opdragte wat met ceph verband hou, in te voer nie. Ek het die Queens-vrystelling gebruik, maar jy kan net wat jy wil gebruik.
Kopieer dan die onderwolk-konfigurasielêer na die stapelgebruiker se tuisgids:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNou moet ons hierdie lêer regmaak, dit aanpas by ons installasie.
Voeg die volgende reëls by die begin van die lêer:
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, kom ons gaan deur die instellings:
undercloud_gasheernaam - volle naam van die onderwolkbediener, moet ooreenstem met die inskrywing op die DNS-bediener
plaaslike_ip - plaaslike adres onderwolk na netwerkvoorsiening
netwerk_poort - dieselfde plaaslike adres, wat sal dien as 'n poort om toegang tot die buitewêreld te verkry tydens die installering van oorwolk nodusse, pas ook by die plaaslike ip
undercloud_public_host - eksterne API-adres, enige gratis adres van die voorsieningsnetwerk word toegeken
undercloud_admin_gasheer adres van die interne API, word enige gratis adres van die voorsieningsnetwerk toegeken
onderwolk_naambedieners - DNS-bediener
genereer_dienssertifikaat - hierdie reël is baie belangrik in die huidige voorbeeld, want as jy dit nie op vals stel nie, sal jy 'n installasiefout kry, die probleem word beskryf op die Red Hat foutspoorder
plaaslike_koppelvlak koppelvlak na die voorsieningsnetwerk. Hierdie koppelvlak sal herkonfigureer word tydens onderwolk-ontplooiing, so jy moet twee koppelvlakke op undercloud hê - een vir toegang daartoe, die tweede vir voorsiening
plaaslike_mtu — MTU. Aangesien ons 'n toetslaboratorium het en ek MTU 1500 op die OVS-poorte van die skakelaar het, is dit nodig om dit op 1450 te stel sodat die pakkies wat in VxLAN ingekapsuleer is, kan slaag
netwerk_cidr — voorsieningsnetwerk
maskerade - gebruik NAT om toegang tot die eksterne netwerk te verkry
maskerade_netwerk - 'n netwerk wat NAT-Xia sal wees
dhcp_start - die beginadres van die adrespoel waarvandaan adresse aan die nodusse toegeken sal word tydens die oorwolk-ontplooiing
dhcp_end - eindadres van die adrespoel waarvandaan adresse aan nodusse toegeken sal word tydens oorwolk-ontplooiing
inspeksie_iprange - 'n poel van adresse wat nodig is vir introspeksie (moet nie met bogenoemde poel oorvleuel nie)
skeduleerder_maksimum_pogings - die maksimum aantal pogings om oorwolk te installeer (moet groter as of gelyk aan die aantal nodusse wees)
Nadat die lêer beskryf is, kan u 'n opdrag uitreik om undercloud te ontplooi:
openstack undercloud install
Die prosedure neem van 10 tot 30 minute, afhangende van jou yster. Uiteindelik moet u uitvoer soos volg sien:
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.
#############################################################################Hierdie uitset sê dat u undercloud suksesvol geïnstalleer het en nou kan u die status van undercloud nagaan en voortgaan om oorwolk te installeer.
As jy na die ifconfig-uitvoer kyk, sal jy sien dat 'n nuwe brugkoppelvlak verskyn het
[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 0Deur hierdie koppelvlak sal daar nou gewerk word om oorwolk te ontplooi.
Uit die afvoer hieronder kan u sien dat ons al die dienste op dieselfde nodus het:
(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 |
+--------------------------+-----------+----------+Hieronder is die konfigurasie van die onderwolknetwerkdeel:
(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 ~]$oorwolk installasie
Op die oomblik het ons net 'n onderwolk, en ons het nie genoeg nodusse waaruit die oorwolk gebou sal word nie. Daarom is die eerste stap om die virtuele masjiene wat ons benodig, te ontplooi. Tydens die ontplooiing sal undercloud self die bedryfstelsel en die nodige sagteware op die oorwolk van die masjien installeer - dit wil sê, ons hoef nie die masjien volledig te ontplooi nie, maar slegs 'n skyf (of skywe) daarvoor te skep en sy parameters te bepaal - dit wil sê, in werklikheid kry ons 'n kaal bediener sonder 'n bedryfstelsel wat daarop geïnstalleer is.
Gaan na die gids met die skywe van ons virtuele masjiene en skep skywe van die vereiste grootte:
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 160GAangesien ons as wortel optree, moet ons die eienaar van hierdie skywe verander om nie 'n probleem met regte te kry nie:
[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]# Let wel: as jy nie van plan is om ceph te installeer om dit te bestudeer nie, skep die opdragte nie ten minste 3 nodusse met ten minste twee skywe nie, maar dui in die sjabloon aan dat virtuele skywe vda, vdb, ens. gebruik sal word.
Groot, nou moet ons al hierdie masjiene definieer:
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 Aan die einde is daar opdragte -print-xml > /tmp/storage-1.xml, wat 'n xml-lêer skep met 'n beskrywing van elke masjien in die /tmp/-lêergids, as jy dit nie byvoeg nie, sal jy nie in staat wees om om virtuele masjiene te definieer.
Nou moet ons al hierdie masjiene in virsh definieer:
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 ~]#Nou 'n bietjie nuanse - tripleO gebruik IPMI om bedieners te bestuur tydens installasie en introspeksie.
Introspeksie is die proses om die hardeware te inspekteer om sy parameters te verkry wat nodig is vir verdere nodusvoorsiening. Introspeksie word gedoen met behulp van ironic, 'n diens wat ontwerp is om met kaalmetaalbedieners te werk.
Maar hier is die probleem - as IPMI-ysterbedieners 'n aparte poort het (of 'n gedeelde poort, maar dit is nie belangrik nie), dan het virtuele masjiene nie sulke poorte nie. Hier kom 'n kruk genaamd vbmc ons te hulp - 'n nutsding wat jou toelaat om 'n IPMI-poort na te boots. Hierdie nuanse is die moeite werd om aandag aan te gee veral vir diegene wat so 'n laboratorium op 'n ESXI hipervisor wil opstel - om eerlik te wees, ek weet nie of dit 'n analoog van vbmc het nie, so jy moet verbaas wees oor hierdie vraag voordat jy ontplooi alles.
Installeer vbmc:
yum install yum install python2-virtualbmcAs jou bedryfstelsel nie die pakket kan vind nie, voeg dan die bewaarplek by:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmKom ons stel nou die hulpprogram op. Alles hier is banaal tot skande. Nou is dit logies dat daar geen bedieners in die vbmc-lys is nie
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Om hulle te laat verskyn, moet hulle met die hand op hierdie manier verklaar word:
[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 ~]#Ek dink die sintaksis van die opdrag is duidelik sonder verduideliking. Vir nou is al ons sessies egter in DOWN-status. Om na die UP-status oor te skakel, moet jy hulle aktiveer:
[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 die laaste aanraking - jy moet die firewall-reëls regmaak (wel, of dit heeltemal afskakel):
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
Kom ons gaan nou na undercloud en kyk of alles werk. Die gasheermasjienadres is 192.168.255.200, ons het die nodige ipmitool-pakket by die onderwolk gevoeg tydens voorbereiding vir die ontplooiing:
[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 runningSoos u kan sien, het ons die beheernodus suksesvol via vbmc bekendgestel. Skakel dit nou af en gaan aan:
[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 ~]#Die volgende stap is die introspeksie van die nodusse waarop die oorwolk geplaas sal word. Om dit te doen, moet ons 'n json-lêer voorberei met 'n beskrywing van ons nodusse. Neem asseblief kennis dat anders as installasie op kaal bedieners, die lêer die poort spesifiseer waarop vbmc vir elk van die masjiene loop.
[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:27Let wel: daar is twee koppelvlakke op die beheernodus, maar in hierdie geval maak dit nie saak nie, in hierdie installasie is een vir ons genoeg.
Nou berei ons die json-lêer voor. Ons moet die papaweradres spesifiseer van die poort waardeur voorsiening uitgevoer sal word, die parameters van die nodusse, hulle name gee en aandui hoe om by ipmi uit te kom:
{
"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"
}
]
}Nou moet ons die beelde voorberei vir ironies. Om dit te doen, laai hulle af via wget en installeer:
(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 ~]$Laai prente op na onderwolk:
(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 ~]$Verifieer dat alle beelde gelaai is
(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 ~]$Nog een aanraking - jy moet 'n dns-bediener byvoeg:
(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 ~]$Nou kan ons introspeksie beveel:
(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 ~]$Soos u uit die uitvoer kan sien, is alles sonder foute voltooi. Kontroleer dat alle nodusse in die beskikbare toestand is:
(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 die nodusse in 'n ander toestand is, gewoonlik hanteerbaar, dan het iets verkeerd geloop en jy moet na die log kyk, uitvind hoekom dit gebeur het. Hou in gedagte dat ons in hierdie scenario virtualisering gebruik en daar kan foute wees wat verband hou met die gebruik van virtuele masjiene of vbmc.
Vervolgens moet ons spesifiseer watter nodus watter funksie sal verrig - dit wil sê, spesifiseer die profiel waarmee die nodus sal ontplooi:
(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 ~]$Spesifiseer 'n profiel vir elke nodus:
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-d9afb69d1167Ons kyk of ons alles reg gedoen het:
(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 korrek is, gee ons die opdrag om overcloud te ontplooi:
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 qemuIn 'n regte installasie sal hulle natuurlik pasgemaakte sjablone gebruik, in ons geval sal dit die proses baie bemoeilik, aangesien dit nodig sal wees om elke wysiging in die sjabloon te verduidelik. Soos vroeër geskryf is, sal selfs 'n eenvoudige installasie vir ons genoeg wees om te sien hoe dit werk.
Let wel: Die --libvirt-tipe qemu veranderlike is nodig in hierdie geval aangesien ons geneste virtualisasie sal gebruik. Andersins sal jy nie virtuele masjiene laat loop nie.
Nou het jy omtrent 'n uur, of dalk meer (afhangende van die vermoëns van die yster) en jy kan net hoop dat jy na hierdie tyd hierdie inskripsie sal sien:
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 ~]$Nou het jy 'n amper volwaardige weergawe van die oop stapel, waarop jy kan studeer, eksperimenteer, ens.
Kom ons kyk of alles goed werk. Daar is twee lêers in die gebruiker se tuisgidsstapel - een stackrc (vir onderwolkbestuur) en die tweede overcloudrc (vir oorwolkbestuur). Hierdie lêers moet as bron gespesifiseer word omdat hulle inligting bevat wat nodig is vir stawing.
(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 ~]$My installasie het nog een klein aanraking nodig - om 'n roete op die beheerder by te voeg, aangesien die masjien waarmee ek werk op 'n ander netwerk is. Om dit te doen, gaan na beheer-1 onder die hitte-admin-rekening en skryf die roete
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Wel, nou kan jy na die horison gaan. Alle inligting - adresse, login en wagwoord - is in die lêer /home/stack/overcloudrc. Die finale skema lyk soos volg:
Terloops, in ons installasie is masjienadresse via DHCP uitgereik, en soos u kan sien, word dit "in elk geval" uitgereik. Jy kan in die sjabloon hardkodeer watter adres aan watter masjien gekoppel moet word tydens ontplooiing, as jy dit nodig het.
Hoe vloei verkeer tussen virtuele masjiene?
In hierdie artikel sal ons drie opsies vir verbygaande verkeer oorweeg
- Twee masjiene op een hypervisor in een L2-netwerk
- Twee masjiene op verskillende hipervisors in dieselfde L2-netwerk
- Twee masjiene op verskillende netwerke (kruisnetwerkworteling)
Sake met toegang tot die buitewêreld deur 'n eksterne netwerk, met behulp van drywende adresse, sowel as verspreide roetering, sal volgende keer oorweeg word, vir nou fokus ons op interne verkeer.
Om te toets, kom ons stel die volgende skema saam:
Ons het 4 virtuele masjiene geskep - 3 in dieselfde L2-netwerk - net-1, en nog 1 in die net-2-netwerk
(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 ~]$ Kom ons kyk op watter hipervisors die geskepde masjiene geleë is:
(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 |
(oorwolk) [stack@undercloud ~]$
Masjiene vm-1 en vm-3 is op compute-0 geleë, masjiene vm-2 en vm-4 is op node compute-1 geleë.
Daarbenewens is 'n virtuele roeteerder geskep om roetering tussen die gespesifiseerde netwerke moontlik te maak:
(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 ~]$ Die router het twee virtuele poorte wat as poorte vir netwerke dien:
(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 ~]$ Maar voordat ons kyk na hoe die verkeer verloop, kom ons kyk na wat ons tans op die beheernodus (wat ook 'n netwerknodus is) en op die rekenaarnodus het. Kom ons begin met die rekenknoop.
[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 ~]$Daar is tans drie ovs-brûe op die nodus - br-int, br-tun, br-ex. Tussen hulle, soos ons kan sien, is daar 'n stel koppelvlakke. Vir gemak van persepsie, kom ons plaas al hierdie koppelvlakke op die diagram en kyk wat gebeur.
Van die adresse waarheen VxLAN-tonnels verhoog is, kan gesien word dat een tonnel op bereken-1 (192.168.255.26) verhoog is, die tweede tonnel kyk na beheer-1 (192.168.255.15). Maar die interessantste ding is dat br-ex nie fisiese koppelvlakke het nie, en as jy kyk watter vloeie gekonfigureer is, kan jy sien dat hierdie brug op die oomblik net verkeer kan laat val.
[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 ~]$ Soos gesien kan word uit die afvoer, word die adres direk aan die fisiese poort geskroef, en nie aan die virtuele brugkoppelvlak nie.
[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 ~]$
Volgens die eerste reël moet alles wat uit die phy-br-ex-poort gekom het, weggegooi word.
Eintlik is daar nog geen ander plek vir verkeer om na hierdie brug te kom nie, behalwe vanaf hierdie koppelvlak (aansluiting met br-int), en te oordeel aan die druppels, het BUM-verkeer reeds in die brug aangekom.
Dit wil sê, verkeer vanaf hierdie nodus kan slegs deur die VxLAN-tonnel vertrek en niks anders nie. As jy egter die DVR aanskakel, sal die situasie verander, maar ons sal dit 'n ander keer hanteer. As u byvoorbeeld netwerkisolasie gebruik, deur vlans te gebruik, sal u nie een L3-koppelvlak in die 0de vlan hê nie, maar verskeie koppelvlakke. VxLAN-verkeer sal egter die nodus op presies dieselfde manier verlaat, maar ook ingekapsuleer in een of ander toegewyde vlan.
Ons het die rekenaarknoop uitgepluis, gaan na die beheernodus.
[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 ~]$Trouens, ons kan sê dat alles dieselfde is, maar die IP-adres is nie meer op die fisiese koppelvlak nie, maar op die virtuele brug. Dit word gedoen omdat hierdie hawe die hawe is waardeur verkeer na die buitewêreld sal gaan.
[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 ~]$ Hierdie poort is gekoppel aan die br-ex brug en aangesien dit geen vlan tags het nie, is hierdie poort 'n stampoort waarop alle vlans toegelaat word, nou gaan die verkeer uit sonder 'n tag, soos aangedui deur vlan-id 0 in die uitset hierbo.
Alles anders op die oomblik is soortgelyk aan 'n bereken nodus - dieselfde brûe, dieselfde tonnels wat na twee bereken nodusse gaan.
Ons sal nie stoornodusse in hierdie artikel oorweeg nie, maar om te verstaan is dit nodig om te sê dat die netwerkdeel van hierdie nodusse banaal tot skande is. In ons geval is daar net een fisiese poort (eth0) met 'n IP-adres daaraan toegeken, en dit is dit. Daar is geen VxLAN-tonnels, tonnelbrûe, ens nie - daar is glad geen ovs nie, aangesien dit geen sin maak nie. Wanneer jy netwerkisolasie gebruik - hierdie nodus sal twee koppelvlakke hê (fisiese poorte, bodns, of net twee vlans - dit maak nie saak nie - dit hang af van wat jy wil hê) - een vir beheer, die tweede vir verkeer (skryf na die VM-skyf , lees vanaf skyf, ens.).
Ons het uitgepluis wat ons op die nodusse het in die afwesigheid van enige dienste. Laat ons nou 4 virtuele masjiene laat loop en kyk hoe die skema hierbo beskryf verander - ons moet poorte, virtuele routers, ens.
Tot dusver lyk ons netwerk so:
Ons het twee virtuele masjiene op elke rekenaarnodus. Gebruik compute-0 as 'n voorbeeld, kom ons kyk hoe alles ingesluit is.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Die masjien het net een virtuele koppelvlak - 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 ~]$
Hierdie koppelvlak lyk in die Linux-brug:
[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 ~]$ Soos u uit die afvoer kan sien, is daar slegs twee koppelvlakke in die brug - tap95d96a75-a0 en qvb95d96a75-a0.
Hier is dit die moeite werd om 'n bietjie stil te staan by die tipe virtuele netwerktoestelle in OpenStack:
vtap is 'n virtuele koppelvlak gekoppel aan 'n instansie (VM)
qbr - Linux-brug
qvb en qvo - vEth-paar gekoppel aan Linux-brug en Open vSwitch-brug
br-int, br-tun, br-vlan - Maak vSwitch-brûe oop
patch-, int-br-, phy-br- — Maak vSwitch-patch-koppelvlakke oop wat brûe verbind
qg, qr, ha, fg, sg - Maak vSwitch-poorte oop wat deur virtuele toestelle gebruik word om aan OVS te koppel
Soos u verstaan, as ons 'n qvb95d96a75-a0-poort in die brug het, wat 'n vEth-paar is, dan is daar iewers sy eweknie, wat logieserwys qvo95d96a75-a0 genoem moet word. Ons kyk watter poorte op OVS is.
[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 ~]$ Soos ons kan sien is die hawe in br-int. Br-int dien as 'n skakelaar wat virtuele masjienpoorte beëindig. Benewens qvo95d96a75-a0, is die qvo5bd37136-47-poort sigbaar in die uitvoer. Dit is 'n poort na die tweede virtuele masjien. Gevolglik lyk ons skema nou so:
Die vraag wat die aandagtige leser onmiddellik behoort te interesseer, is watter linux-brug tussen die virtuele masjienpoort en die OVS-poort is? Die feit is dat sekuriteitsgroepe gebruik word om die masjien te beskerm, wat niks meer as iptables is nie. OVS werk nie met iptables nie, so so 'n "kruk" is uitgevind. Hy raak egter verouderd – hy word vervang deur conntrack in nuwe vrystellings.
Dit wil sê, op die ou end lyk die skema soos volg:
Twee masjiene op een hypervisor in een L2-netwerk
Aangesien hierdie twee VM's in dieselfde L2-netwerk en op dieselfde hipervisor is, sal dit logies wees dat verkeer tussen hulle plaaslik via br-int gaan, aangesien beide masjiene in dieselfde VLAN sal wees:
[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 ~]$ Twee masjiene op verskillende hipervisors in dieselfde L2-netwerk
Kom ons kyk nou hoe die verkeer tussen twee masjiene in dieselfde L2-netwerk sal gaan, maar op verskillende hipervisors geleë is. Om eerlik te wees, niks sal veel verander nie, net verkeer tussen hipervisers sal deur die vxlan-tonnel gaan. Kom ons kyk na 'n voorbeeld.
Adresse van virtuele masjiene waartussen ons verkeer sal kyk:
[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 ~]$ Ons kyk na die aanstuurtabel in 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 ~]Verkeer moet na poort 2 gaan - kyk watter poort dit 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 - dit wil sê die koppelvlak in br-tun. Kom ons kyk wat gebeur met die 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 ~]$ Die pakkie word in VxLAN verpak en na poort 2 gestuur. Ons kyk waarheen poort 2 lei:
[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 die vxlan-tonnel 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 ~]$Ons gaan na compute-1 en kyk wat volgende met die pakket gebeur:
[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 ~]$ Die papawer is in die br-int-aanstuurtabel op compute-1, en soos u uit die afvoer hierbo kan sien, is dit sigbaar deur poort 2, wat die poorte na br-tun is:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Wel, dan kyk ons dat daar 'n bestemmingspapawer in br-int op compute-1 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 ~]$ Dit wil sê, die ontvangde pakkie sal na poort 3 vlieg, waaragter daar reeds 'n virtuele masjien-instansie-00000003 is.
Die skoonheid van die ontplooiing van Openstack om op 'n virtuele infrastruktuur te studeer, is dat ons maklik verkeer tussen hipervisers kan vang en sien wat daarmee gebeur. Dit is wat ons nou sal doen, hardloop tcpdump op die vnet-poort na 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*******************Die eerste reël wys dat die pakkie vanaf adres 10.0.1.85 na adres 10.0.1.88 (ICMP-verkeer) gaan, en dit is toegedraai in 'n VxLAN-pakkie met vni 22 en die pakkie gaan van gasheer 192.168.255.19 (compute-0) na gasheer 192.168.255.26 ( bereken-1). Ons kan seker maak dat die VNI ooreenstem met die een gespesifiseer in ovs.
Kom ons gaan terug na hierdie reël actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],uitvoer:2. 0x16 is vni in heksadesimale getallestelsel. Kom ons skakel hierdie getal om na die 16de stelsel:
16 = 6*16^0+1*16^1 = 6+16 = 22Dit wil sê, vni is waar.
Die tweede reël wys omgekeerde verkeer, wel, dit maak geen sin om dit daar te verduidelik nie, en dus is alles duidelik.
Twee masjiene op verskillende netwerke (roetering tussen netwerke)
Die laaste geval vir vandag is roetering tussen netwerke binne dieselfde projek met behulp van 'n virtuele router. Ons beskou die saak sonder 'n DVR (ons sal dit in 'n ander artikel oorweeg), dus vind die roetering op die netwerknodus plaas. In ons geval is die netwerknodus nie 'n aparte entiteit nie en is dit op die beheernodus geleë.
Kom ons kyk eers dat die roetering werk:
$ 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 msAangesien die pakkie in hierdie geval na die poort moet gaan en daarheen gestuur moet word, moet ons die poppy-adres van die poort uitvind, waarvoor ons in die geval na die ARP-tabel sal kyk:
$ 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 eth0Kom ons kyk nou waarheen die verkeer gestuur moet word met die bestemming (10.0.1.254) fa:16:3e:c4:64:70:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Ons kyk waarheen poort 2 lei:
[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 logies, die verkeer gaan na br-tun. Kom ons kyk in watter vxlan-tonnel dit toegedraai sal word:
[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 ~]$ Die derde hawe is die vxlan-tonnel:
[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 kyk na die beheernodus:
[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 ~]$ Verkeer het na die beheernodus gevlieg, so ons moet daarheen gaan en kyk hoe die roetering sal plaasvind.
Soos jy onthou, het die beheernodus binne presies dieselfde gelyk as die berekeningsnodus - dieselfde drie brûe, net br-ex het 'n fisiese poort gehad waardeur die nodus verkeer na buite kon stuur. Die skep van gevalle het die konfigurasie op rekenaarnodusse verander - linux-brug, iptables en koppelvlakke is by die nodusse gevoeg. Die skepping van netwerke en 'n virtuele router het ook sy stempel op die opstelling van die beheernodus gelaat.
So, natuurlik, moet die poort-papawer-adres in die br-int-aanstuurtabel op die beheernodus wees. Kom ons kyk of dit daar is en waar dit lyk:
[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 ~]$ Die Mac is sigbaar vanaf poort qr-0c52b15f-8f. Om terug te gaan na die lys van virtuele poorte in Openstack, word hierdie poorttipe gebruik om verskeie virtuele toestelle aan OVS te koppel. Om meer presies te wees, qr is die poort na die virtuele router, wat as 'n naamruimte voorgestel word.
Kom ons kyk watter naamruimte op die bediener is:
[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 ~]$ Daar is drie kopieë. Maar te oordeel aan die name, kan jy die doel van elkeen raai. Ons sal later terugkeer na gevalle met ID 0 en 1, nou stel ons belang in naamruimte 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 ~]$ In hierdie naamruimte is daar twee interne wat ons vroeër geskep het. Beide virtuele poorte word by br-int gevoeg. Kom ons kyk na die MAC-poortadres qr-0c52b15f-8f, aangesien die verkeer, te oordeel aan die bestemming MAC-adres, na hierdie koppelvlak gegaan het.
[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 ~]$ Dit wil sê, in hierdie geval werk alles volgens die wette van standaard roetering. Aangesien die verkeer vir gasheer 10.0.2.8 bedoel is, moet dit deur die tweede koppelvlak qr-92fa49b5-54 uitgaan en deur die vxlan-tonnel na die rekenaarnodus gaan:
[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 logies, geen verrassings nie. Ons kyk van waar die papawer-adres van die gasheer 10.0.2.8 sigbaar is in 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 ~]$ Soos verwag, gaan die verkeer na br-tun, kom ons kyk na watter tonnel die verkeer volgende sal gaan:
[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 ~]$ Verkeer gaan in die tonnel in om-1 te bereken. Wel, op compute-1 is alles eenvoudig - van br-tun kom die pakket na br-int en van daar af na die koppelvlak van die virtuele masjien:
[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 ~]$ Kom ons kyk of dit wel die regte koppelvlak 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 ~]$
Eintlik het ons die hele pad van die pakket gegaan. Ek dink jy het opgemerk dat die verkeer deur verskillende vxlan-tonnels gegaan het en met verskillende VNI's uitgegaan het. Kom ons kyk wat VNI's is, waarna ons 'n stortplek op die beheerpoort van die nodus sal versamel en seker maak dat die verkeer presies verloop soos hierbo beskryf.
Die tonnel om-0 te bereken het dus die volgende actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],uitvoer:3. Kom ons vertaal 0x16 in die desimale getallestelsel:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Die tonnel om te bereken-1 het die volgende VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],uitvoer:2. Kom ons vertaal 0x63 in die desimale getallestelsel:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Wel, kom ons kyk nou na die storting:
[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*******************Die eerste pakkie is 'n vxlan-pakkie van gasheer 192.168.255.19 (bereken-0) na gasheer 192.168.255.15 (kontrole-1) met vni 22, waarin 'n ICMP-pakkie gepak word vanaf gasheer 10.0.1.85 tot gasheer 10.0.2.8. Soos ons hierbo bereken het, stem vni ooreen met wat ons in die uitset gesien het.
Die tweede pakkie is 'n vxlan-pakkie van gasheer 192.168.255.15 (kontrole-1) na gasheer 192.168.255.26 (rekenaar-1) met vni 99, waarin 'n ICMP-pakkie gepak word vanaf gasheer 10.0.1.85 tot gasheer 10.0.2.8. Soos ons hierbo bereken het, stem vni ooreen met wat ons in die uitset gesien het.
Die volgende twee pakkies is retoerverkeer vanaf 10.0.2.8 nie 10.0.1.85 nie.
Dit wil sê, op die ou end het ons die volgende beheernodusskema gekry:
Lyk dit is dit? Ons het van twee naamruimtes vergeet:
[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 ~]$ Soos ons oor die argitektuur van die wolkplatform gepraat het, sal dit lekker wees as die masjiene adresse outomaties vanaf die DHCP-bediener ontvang. Dit is die twee DHCP-bedieners vir ons twee netwerke 10.0.1.0/24 en 10.0.2.0/24.
Kom ons kyk of dit so is. Daar is net een adres in hierdie naamruimte - 10.0.1.1 - die adres van die DHCP-bediener self, en dit is ook ingesluit in 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 0Kom ons kyk of die prosesse qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 in hul naam op die beheernodus bevat:
[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 ~]$ Daar is so 'n proses en, gebaseer op die inligting wat in die afvoer hierbo aangebied word, kan ons byvoorbeeld sien wat ons op die oomblik te huur het:
[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 gevolg hiervan kry ons die volgende stel dienste op die beheernodus:
Wel, hou in gedagte - dit is net - 4 masjiene, 2 interne netwerke en een virtuele router ... Ons het nie nou eksterne netwerke hier nie, hope verskillende projekte, elk met sy eie netwerke (kruis mekaar), en ons het 'n verspreide roeteerder het afgeskakel, maar op die ou end was daar net een beheernodus in die toetsbank (vir fouttoleransie moet daar 'n kworum van drie nodusse wees). Dit is logies dat alles "'n bietjie" meer ingewikkeld is in handel, maar in hierdie eenvoudige voorbeeld verstaan ons hoe dit moet werk - of jy 3 of 300 naamruimtes het is natuurlik belangrik, maar vanuit die oogpunt van die werking van die hele struktuur, niks sal veel verander nie ... alhoewel jy nou nie een of ander verskaffer SDN inprop nie. Maar dit is 'n heeltemal ander storie.
Ek hoop dit was interessant. As daar kommentaar / byvoegings is, of iewers het ek eerlik gelieg (ek is 'n persoon en my opinie sal altyd subjektief wees) - skryf wat reggemaak / bygevoeg moet word - ons sal alles regmaak / byvoeg.
Ten slotte wil ek graag 'n paar woorde sê oor die vergelyking van Openstack (beide vanielje en verkoper) met 'n wolkoplossing van VMWare - ek is hierdie vraag te dikwels oor die afgelope paar jaar gevra en ek is eerlikwaar reeds moeg daarvoor , maar steeds. Na my mening is dit baie moeilik om hierdie twee oplossings te vergelyk, maar ons kan beslis sê dat daar nadele in albei oplossings is, en wanneer jy een oplossing kies, moet jy die voor- en nadele opweeg.
As OpenStack 'n gemeenskapsgedrewe oplossing is, dan het VMWare die reg om net te doen wat hy wil (lees - wat voordelig daarvoor is) en dit is logies - want dit is 'n kommersiële maatskappy wat gewoond is om geld uit sy kliënte te maak. Maar daar is een groot en vet MAAR – jy kan byvoorbeeld van OpenStack van Nokia af afklim en na ’n oplossing van byvoorbeeld Juniper (Contrail Cloud) oorskakel, maar dit is onwaarskynlik dat jy van VMWare sal afkom. Vir my lyk hierdie twee oplossings so - Openstack (verkoper) is 'n eenvoudige hok wat jou insit, maar jy het die sleutel en jy kan enige tyd vertrek. VMWare is 'n goue hok, die sleutel tot die hok is by die eienaar en dit sal jou baie kos.
Ek beywer my nie vir óf die eerste produk óf die tweede nie – jy kies wat jy nodig het. Maar as ek so 'n keuse gehad het, dan sou ek albei oplossings kies - VMWare vir die IT-wolk (ligte vragte, gerieflike bestuur), OpenStack van een of ander verskaffer (Nokia en Juniper bied baie goeie sleuteloplossings) - vir die Telecom-wolk. Ek sal nie Openstack vir suiwer IT gebruik nie - dit is soos om mossies uit 'n kanon te skiet, maar ek sien geen kontraindikasies om dit te gebruik nie, behalwe vir oortolligheid. Om VMWare in telekommunikasie te gebruik - soos om rommel in 'n Ford Raptor te sleep - is egter pragtig van buite, maar die bestuurder moet 10 ritte maak in plaas van een.
Na my mening is die grootste nadeel van VMWare die volledige nabyheid daarvan - die maatskappy sal jou geen inligting gee oor hoe dit werk nie, byvoorbeeld vSAN of wat in die hipervisorkern is - dit is eenvoudig nie winsgewend daarvoor nie - dit wil sê, jy sal nooit 'n kenner van VMWare word nie - sonder verskafferondersteuning is jy gedoem (ek ontmoet baie dikwels VMWare-kundiges wat verstom is deur banale vrae). Vir my koop VMWare 'n kar met die kap gesluit - ja, jy het dalk spesialiste wat die tydband kan verander, maar net die persoon wat hierdie oplossing aan jou verkoop het, sal die enjinkap kan oopmaak. Persoonlik hou ek nie van besluite waarby ek nie kan inpas nie. Jy sal sê dat jy dalk nie onder die enjinkap hoef te gaan nie. Ja, dit is moontlik, maar ek sal na jou kyk wanneer jy 'n groot funksie in die wolk moet versamel van 20-30 virtuele masjiene, 40-50 netwerke, waarvan die helfte buite wil gaan, en die ander helfte vra vir SR -IOV-versnelling anders sal jy meer 'n paar dosyn van hierdie masjiene nodig hê - anders sal die werkverrigting nie genoeg wees nie.
Daar is ander standpunte, so dit is aan jou om te besluit wat om te kies, en die belangrikste, jy sal dan verantwoordelik wees vir jou keuse. Dit is net my mening - 'n persoon wat ten minste 4 produkte gesien en aangeraak het - Nokia, Juniper, Red Hat en VMWare. So ek het iets om te vergelyk.
Bron: will.com