Cloudcomputing dringt dieper en dieper ons leven binnen, en er is waarschijnlijk niemand die nog nooit gebruik heeft gemaakt van een of andere cloudservice. Maar wat is een cloud en hoe werkt het? Dat weet meestal niemand echt, zelfs niet op het idee-niveau. 5G wordt al werkelijkheid en de telecommunicatie-infrastructuur begint over te stappen van traditionele oplossingen naar cloudoplossingen, net zoals het ooit van volledig fysieke oplossingen naar gevirtualiseerde 'kolommen' overstapte.
Vandaag gaan we het hebben over de interne wereld van cloudinfrastructuur, en in het bijzonder over de basisprincipes van het netwerkgedeelte.
Wat is een cloud? Is het gewoon een soort virtualisatie, bekeken van opzij?
Een volkomen logische vraag. Nee, het is geen virtualisatie, hoewel het daar niet zonder kan. Laten we twee definities bekijken:
Cloudcomputing (hierna Cloud) is een model voor het aanbieden van gebruiksvriendelijke toegang tot gedistribueerde computermiddelen, die op aanvraag moeten worden uitgerold en geactiveerd met de minimaal mogelijke vertraging en de minimale kosten voor de serviceprovider.
Virtualisatie is de mogelijkheid om Ă©Ă©n fysieke entiteit (bijvoorbeeld een server) op te splitsen in meerdere virtuele entiteiten, waardoor de benutting van middelen wordt verhoogd (bijvoorbeeld als je 3 servers had die voor 25-30 procent werden gebruikt, krijg je na virtualisatie 1 server die voor 80-90 procent wordt benut). Uiteraard verbruikt virtualisatie een deel van de middelen â je moet de hypervisor onderhouden. Echter, zoals de praktijk heeft aangetoond, is de moeite waard. Een ideaal voorbeeld van virtualisatie is VMWare, dat uitstekend virtuele machines voorbereidt, of bijvoorbeeld KVM, dat mijn persoonlijke voorkeur heeft, maar dat is een kwestie van smaak.
We gebruiken virtualisatie zonder het te beseffen. Zelfs fysieke routers maken al gebruik van virtualisatie â bijvoorbeeld in de laatste versies van JunOS wordt het besturingssysteem geĂŻnstalleerd als een virtuele machine bovenop een real-time Linux-distributie (Wind River 9). Maar virtualisatie is geen cloud, hoewel een cloud niet kan bestaan zonder virtualisatie.
Virtualisatie is een van de bouwstenen waarop de cloud wordt gebouwd.
Een cloud creĂ«ren door simpelweg een paar hypervisors in Ă©Ă©n L2-domein te verzamelen, een paar YAML-playbooks toe te voegen voor automatische VLAN-configuraties met Ansible en er iets als een orchestratiesysteem bovenop te plaatsen voor het automatisch aanmaken van virtuele machines, dat gaat niet lukken. Sterker nog, het zal wel lukken, maar de resulterende Frankenstein is niet de cloud die we nodig hebben; hoewel, voor sommigen kan dit het summum van dromen zijn. Bovendien, als we naar Openstack kijken â dat is in wezen ook zo'n Frankenstein, maar laten we het daar nu niet over hebben.
Maar ik begrijp dat uit de bovenstaande definitie niet helemaal duidelijk is wat we eigenlijk een cloud kunnen noemen.
Daarom worden in het document van NIST (National Institute of Standards and Technology) 5 belangrijkste kenmerken genoemd die een cloudinfrastructuur moet hebben:
Service on demand. De gebruiker moet vrij toegang krijgen tot de aan hem toegewezen computerbronnen (zoals netwerken, virtuele schijven, geheugen, processors, enz.), en deze bronnen moeten automatisch worden geleverd â dat wil zeggen, zonder tussenkomst van de serviceprovider.
Brede beschikbaarheid van de service. Toegang tot de bronnen moet worden gegarandeerd via standaardmechanismen zodat zowel standaard pc's als dunne clients en mobiele apparaten kunnen worden gebruikt.
Consolidatie van bronnen in pools. Resourcepools moeten gelijktijdige toegang tot bronnen voor meerdere klanten bieden, met waarborging van isolatie tussen klanten en het ontbreken van wederzijds invloed en concurrentie om bronnen. Netwerken zijn ook inbegrepen in de pools, wat wijst op de mogelijkheid van overlappende adressen. De pools moeten schaalbaarheid op aanvraag ondersteunen. Het gebruik van pools zorgt voor de noodzakelijke mate van fouttolerantie van bronnen en abstrahering van fysieke en virtuele bronnen â de ontvanger van de service krijgt gewoon het gevraagde aantal bronnen toegewezen (waar deze bronnen fysiek zijn, op hoeveel servers en switches, is voor de klant niet relevant). Het is echter belangrijk om te bedenken dat de provider transparante reservekopieĂ«n van deze middelen moet garanderen.
Snelle aanpassing aan verschillende omstandigheden. Diensten moeten flexibel zijnâsnelle levering van middelen, herverdeling, toevoeging of vermindering van middelen op verzoek van de klant, waarbij de klant de indruk moet hebben dat de cloudresources eindeloos zijn. Ter vereenvoudiging, bijvoorbeeld, u ziet geen waarschuwing dat u in Apple iCloud een deel van uw schijfruimte hebt verloren omdat de harde schijf op de server is kapot gegaan; harde schijven kunnen immers kapot gaan. Bovendien zijn de mogelijkheden van deze service aan uw kant praktisch onbeperktâheeft u 2 TB nodigâgeen probleem, u betaalt en krijgt het. Een vergelijkbaar voorbeeld kan worden gegeven met Google Drive of Yandex.Disk.
De mogelijkheid om de geleverde service te meten. Cloudsystemen moeten automatisch de verbruikte middelen controleren en optimaliseren; deze mechanismen moeten zowel voor de gebruiker als voor de dienstverlener transparant zijn. Dat wil zeggen, u kunt altijd controleren hoeveel middelen u en uw klanten verbruiken.
Het is belangrijk om in gedachten te houden dat deze eisen voornamelijk betrekking hebben op publieke cloudomgevingen; voor een privécloud (dat wil zeggen een cloud die voor interne behoeften van het bedrijf is opgezet) kunnen deze eisen enigszins worden aangepast. Desondanks moeten ze nog steeds worden nageleefd, anders krijgen we niet alle voordelen van cloud computing.
Waarom hebben we de cloud nodig?
Echter, elke nieuwe of bestaande technologie, elk nieuw protocol, wordt voor iets gemaakt (behalve RIP-ng natuurlijk). Een protocol voor het protocolâniemand heeft het nodig (behalve RIP-ng natuurlijk). Het is logisch dat de cloud wordt gecreĂ«erd om een bepaalde dienst aan de gebruiker/klant te bieden. We zijn allemaal wel bekend met een paar cloudservices, zoals Dropbox of Google Docs, en de meeste gebruiken deze succesvolâbijvoorbeeld, dit artikel is geschreven met behulp van de cloudservice Google Docs. Maar de bekende cloudservices zijn slechts een deel van de mogelijkheden van de cloudâeigenlijk zijn dit alleen diensten van het type SaaS. We kunnen cloudservices op drie manieren aanbieden: in de vorm van SaaS, PaaS of IaaS. Welke service precies u nodig heeft, hangt af van uw wensen en mogelijkheden.
Laten we elk in volgorde bekijken:
Software as a Service (SaaS) â dit is een model voor het bieden van een volledige service aan de klant, zoals een e-mailservice zoals Yandex.Mail of Gmail. In dit model maakt u als klant feitelijk niets mee, behalve het gebruik van de service â dat wil zeggen, u hoeft niet na te denken over de configuratie van de service, de beschikbaarheid of de back-up. Het belangrijkste is dat u uw wachtwoord niet compromitteert, de rest regelt de aanbieder van deze service voor u. Vanuit het perspectief van de serviceprovider is hij volledig verantwoordelijk voor de hele service â van de serverhardware en hostbesturingssystemen tot de configuraties van databases en software.
Platform as a Service (PaaS) â bij het gebruik van dit model biedt de dienstverlener de klant een sjabloon voor de service, bijvoorbeeld een webserver. De dienstverlener heeft de klant een virtuele server aangeboden (in feite een set middelen zoals RAM/CPU/Storage/Nets, enz.), en heeft zelfs het besturingssysteem en de benodigde software op deze server geĂŻnstalleerd, maar de configuratie van dit geheel wordt door de klant uitgevoerd en de klant is verantwoordelijk voor de werking van de service. De dienstverlener is, net als in het vorige geval, verantwoordelijk voor de werking van de fysieke apparatuur, hypervisors, de virtuele machine zelf, de netwerkbeschikbaarheid, enz., maar de service valt al buiten zijn verantwoordelijkheidsgebied.
Infrastructure as a Service (IaaS) â deze benadering is al interessanter, feitelijk biedt de dienstverlener de klant een volledige gevirtualiseerde infrastructuur â dat wil zeggen een bepaalde set (pool) van middelen, zoals CPU-kernen, RAM, netwerken, enz. De rest is de zaak van de klant â wat de klant met deze middelen binnen de hem toegewezen pool (quota) wil doen, dat is voor de provider niet bijzonder belangrijk. Wil de klant zijn eigen vEPC creĂ«ren of zelfs een mini-operator opzetten en telecommunicatiediensten aanbieden â geen probleem â ga ervoor. In zo'n scenario is de dienstverlener verantwoordelijk voor het leveren van middelen, hun beschikbaarheid en toegankelijkheid, evenals voor het besturingssysteem dat deze middelen in pools kan samenvoegen en aan de klant kan aanbieden met de mogelijkheid om op verzoek van de klant op elk moment de middelen te vergroten of te verminderen. Alle virtuele machines en andere zaken configureert de klant zelf via een selfserviceportaal en consoles, inclusief het instellen van netwerken (behoudens externe netwerken).
Wat is OpenStack?
In alle drie de varianten heeft de dienstverlener een besturingssysteem nodig dat een cloudinfrastructuur kan creĂ«ren. In feite is het bij SaaS zo dat niet Ă©Ă©n afdeling verantwoordelijk is voor de gehele stack van technologieĂ«n â er is een afdeling die verantwoordelijk is voor de infrastructuur â dat wil zeggen, die IaaS biedt aan een andere afdeling, terwijl die afdeling SaaS aan de klant levert. OpenStack is een van de cloud-besturingssystemen die het mogelijk maakt om veel switches, servers en opslag systemen samen te brengen in een enkele resourcepool, deze pool op te splitsen in sub-pools (tenants) en deze resources via het netwerk aan klanten te leveren.
OpenStack is een cloud-besturingssysteem dat het mogelijk maakt om grote pools van computresources, data-opslag en netwerkresources te beheren, waarvan provisioning en beheer plaatsvindt via API's met behulp van standaard authenticatiemechanismen.
Met andere woorden, het is een verzameling van open-source softwareprojecten die bedoeld zijn om cloudservices (zowel publiekelijk als privĂ©) te creĂ«ren â dat wil zeggen, een set tools die het mogelijk maken om server- en netwerkinfrastructuur samen te voegen in een enkele pool van resources, deze resources te beheren en de nodige mate van failover te garanderen.
Op het moment van schrijven van dit materiaal ziet de structuur van OpenStack er als volgt uit:
De afbeelding is afkomstig van
Elke component die deel uitmaakt van OpenStack heeft een specifieke functie. Deze gedistribueerde architectuur maakt het mogelijk om de set functionele componenten op te nemen die je nodig hebt. Echter, sommige componenten zijn cruciaal en het verwijderen ervan zal resulteren in totale of gedeeltelijke onbruikbaarheid van de oplossing als geheel. Dergelijke componenten omvatten doorgaans:
- Dashboard â Een webgebaseerde GUI voor het beheren van OpenStack-services
- Keystone â Een gecentraliseerde identificatieservice die authenticatie- en autorisatiefuncties biedt voor andere diensten, evenals het beheer van gebruikersgegevens en hun rollen.
- Neutron is een netwerkservice die connectiviteit biedt tussen de interfaces van verschillende OpenStack-diensten (inclusief connectiviteit tussen VM's en hun toegang tot de externe wereld).
- Cinder biedt toegang tot blokopslag voor virtuele machines.
- Nova â levenscyclusbeheer van virtuele machines
- Glance â een repository voor images van virtuele machines en snapshots
- Swift â biedt toegang tot objectopslag
- Ceilometer â een dienst die verzameling van telemetrie en metingen van bestaande en verbruikte middelen mogelijk maakt
- Heat â orkestratie op basis van templates voor het automatisch aanmaken en provisioning van middelen
Een volledige lijst van alle projecten en hun doeleinden is te zien .
Elke component van OpenStack is een dienst die verantwoordelijk is voor een specifieke functie en een API biedt voor het beheren van die functie en de interactie van deze dienst met andere diensten van het cloudbesturingssysteem om een uniforme infrastructuur te creĂ«ren. Bijvoorbeeld, Nova zorgt voor het beheer van rekenbronnen en biedt een API voor toegang tot de configuratie van deze middelen, Glance â voor het beheer van images en de API voor hun beheer, Cinder â voor block storage en de API voor hun beheer, enz. Alle functies zijn nauw met elkaar verbonden.
Echter, als je erover nadenkt, zijn alle diensten die worden uitgevoerd in OpenStack uiteindelijk een soort virtuele machine (of container) die is verbonden met het netwerk. De vraag is â waarom hebben we zoveel elementen nodig?
Laten we snel het algoritme doornemen voor het aanmaken van een virtuele machine en hoe deze wordt verbonden met het netwerk en permanente opslag in OpenStack.
- Wanneer je een verzoek indient voor het aanmaken van een machine, of het nu via Horizon (Dashboard) is of via de CLI, is het eerste wat er gebeurt â de autorisatie van je verzoek door Keystone â of je een machine kunt aanmaken, of je het recht hebt om dit netwerk te gebruiken, of je project voldoende quota heeft, enz.
- Keystone authenticates je verzoek en genereert een auth-token in de respons, dat later zal worden gebruikt. Na het ontvangen van het antwoord van Keystone, wordt het verzoek verzonden naar Nova (nova api).
- Nova-api controleert de geldigheid van je verzoek door in Keystone te communiceren, gebruikmakend van het eerder gegenereerde auth-token.
- Keystone voert de authenticatie uit en biedt op basis van het auth-token informatie over permissies en beperkingen.
- Nova-api maakt een record van de nieuwe VM aan in de nova-database en geeft het verzoek voor het aanmaken van de machine door aan nova-scheduler.
- De nova-scheduler selecteert de host (computernode) waar de VM zal worden uitgerold op basis van de opgegeven parameters, gewichten en zones. Deze informatie en de VM-ID worden in de nova-database opgeslagen.
- Daarna vraagt de nova-scheduler aan nova-compute om een instantie te implementeren. Nova-compute vraagt aan nova-conductor om informatie over de machineparameters (nova-conductor is een onderdeel van nova dat fungeert als proxyserver tussen nova-database en nova-compute, waarmee het aantal verzoeken naar de nova-database wordt beperkt om problemen met de consistentie van de database en de belasting te voorkomen).
- Nova-conductor ontvangt de gevraagde informatie uit de nova-database en stuurt deze door naar nova-compute.
- Vervolgens vraagt nova-compute aan glance om de ID van het beeld. Glance valideert het verzoek in Keystone en retourneert de gevraagde informatie.
- Nova-compute vraagt aan neutron om informatie over de netwerkinstellingen. Net als glance valideert neutron het verzoek in Keystone, waarna het een record in de database aanmaakt (poort-ID, enz.), een verzoek voor het aanmaken van een poort indient en de gevraagde informatie terugstuurt naar nova-compute.
- Nova-compute vraagt aan cinder om een volume voor de virtuele machine te reserveren. Net als glance valideert cinder het verzoek in Keystone, dient het een verzoek voor het aanmaken van een volume in en retourneert de gevraagde informatie.
- Nova-compute vraagt aan libvirt om een virtuele machine uit te rollen met de opgegeven parameters.
In feite lijkt het een eenvoudige operatie om een eenvoudige virtuele machine te creĂ«ren, maar het verandert in een wervelwind van API-aanroepen tussen de elementen van het cloudplatform. En zoals u kunt zien, bestaan zelfs de eerder genoemde diensten uit kleinere componenten die met elkaar interageren. Het creĂ«ren van een machine is slechts een klein onderdeel van wat een cloudplatform kan doen â er zijn diensten verantwoordelijk voor verkeersbalancering, voor block storage, voor DNS, voor provisioning van bare metal servers, enzovoorts. De cloud stelt u in staat om uw virtuele machines als een kudde schapen te beschouwen (in tegenstelling tot virtualisatie). Als er in een virtuele omgeving iets met de machine gebeurt â herstelt u deze uit back-ups, enzovoorts, terwijl cloudapplicaties zo zijn opgebouwd dat virtuele machines niet zo'n cruciale rol spelen â de virtuele machine is 'gestorven' â geen probleem â er wordt gewoon een nieuwe machine op basis van een template aangemaakt, en zoals men zegt, de eenheid merkt het verlies van een soldaat niet. Dit vereist uiteraard de aanwezigheid van orkestratiemechanismen â met Heat-templates kunt u zonder al te veel problemen een complexe functie implementeren, bestaande uit tientallen netwerken en virtuele machines.
Het is altijd belangrijk om in gedachten te houden dat cloudinfrastructuur zonder netwerk niet bestaat â elk element interageert op de een of andere manier met andere elementen via het netwerk. Bovendien heeft de cloud een absoluut niet-statische netwerk. Natuurlijk is het onderliggende netwerk nog redelijk statisch â er worden niet elke dag nieuwe nodes en switches toegevoegd, maar de overlay-component zal ongetwijfeld voortdurend veranderen â er zullen nieuwe netwerken worden toegevoegd of verwijderd, nieuwe virtuele machines zullen verschijnen en oude zullen verdwijnen. En zoals u zich herinnert uit de definitie van cloud aan het begin van dit artikel â middelen moeten automatisch aan de gebruiker worden toegewezen met de minste (of liever geen) bemoeienis van de serviceprovider. Met andere woorden, het type netwerkmiddelen dat momenteel als frontend beschikbaar is via uw persoonlijke account met http/https en het wachtdienstnetwerktechnicus Vasily als backend â dat is geen cloud, zelfs niet met Vasily's acht handen.
Neutron, als netwerkservice, biedt een API voor het beheer van het netwerkgedeelte van de cloudinfrastructuur. De service zorgt voor de werking en het beheer van het netwerkgedeelte van OpenStack en biedt een abstractieniveau dat Network-as-a-Service (NaaS) wordt genoemd. Dat wil zeggen, netwerken zijn net zo'n virtuele meeteenheid als bijvoorbeeld virtuele CPU-kernen of RAM-capaciteit.
Voordat we overgaan naar de architectuur van het netwerkgedeelte van OpenStack, laten we bekijken hoe netwerken in OpenStack functioneren en waarom netwerken een belangrijk en onmisbaar onderdeel van de cloud zijn.
We hebben dus twee virtuele machines van klant RED en twee virtuele machines van klant GREEN. Stel dat deze machines zich op twee hypervisors bevinden op de volgende manier:
Op dit moment is het gewoon virtualisatie van 4 servers en niet meer dan dat, omdat we tot nu toe alleen 4 servers hebben gevirtualiseerd, geplaatst op twee fysieke servers. Bovendien zijn ze momenteel zelfs nog niet verbonden met het netwerk.
Om een cloud te creĂ«ren, moeten we een paar componenten toevoegen. Ten eerste virtualiseren we het netwerkgedeelte â we moeten deze 4 machines paar voor paar met elkaar verbinden, en de klanten willen specifiek een L2-verbinding. We kunnen natuurlijk een switch gebruiken en een trunk naar hem toe instellen en alles regelen met behulp van linux bridge, of voor meer gevorderde gebruikers openvswitch (daar komen we later nog op terug). Maar er kunnen heel veel netwerken zijn, en constant L2 via de switch duwen is niet de beste oplossing â verschillende afdelingen, service desk, maanden wachten op aanvraagverwerking, weken met probleemoplossing â in de moderne wereld werkt deze aanpak gewoon niet meer. En hoe eerder een bedrijf dit begrijpt, hoe gemakkelijker het verder kan gaan. Daarom zullen we tussen de hypervisors een L3-netwerk toewijzen waar onze virtuele machines mee communiceren, en boven dit L3-netwerk bouwen we virtuele overlay L2-netwerken, waar het verkeer van onze virtuele machines zal plaatsvinden. Voor encapsulatie kunnen we GRE, Geneve of VxLAN gebruiken. Laten we voorlopig bij de laatste blijven, hoewel dat niet echt belangrijk is.
We moeten ergens de VTEP plaatsen (ik neem aan dat iedereen bekend is met de terminologie van VxLAN). Aangezien we vanaf de servers direct een L3-netwerk hebben, staat er niets in de weg om de VTEP op de servers zelf te plaatsen, en OVS (OpenvSwitch) kan dit uitstekend doen. Uiteindelijk hebben we de volgende constructie gekregen:
Omdat het verkeer tussen VM's verdeeld moet worden, zullen de poorten naar de virtuele machines verschillende VLAN-nummers hebben. Het nummer van de tag speelt alleen een rol binnen Ă©Ă©n virtuele switch, aangezien we deze probleemloos kunnen verwijderen bij encapsulatie in VxLAN, omdat we dan een VNI zouden hebben.
Nu kunnen we onze machines en virtuele netwerken voor hen zonder problemen vermenigvuldigen.
Maar wat als de klant nog een machine heeft, maar deze zich in een ander netwerk bevindt? We hebben routering tussen netwerken nodig. We bespreken een eenvoudige optie waarbij centrale routering wordt gebruikt â dat wil zeggen, het verkeer wordt gerouteerd via speciale toegewijde netwerkknopen (meestal zijn deze gecombineerd met controleknopen, dus we krijgen hetzelfde).
Het lijkt niets ingewikkelds â we creĂ«ren een bridge-interface op de controleknop, sturen het verkeer daarheen en routeren het vandaar naar waar we het nodig hebben. Maar het probleem is dat klant RED het netwerk 10.0.0.0/24 wil gebruiken, en klant GREEN ook 10.0.0.0/24 wil gebruiken. Dit betekent dat we overlap van adresruimten krijgen. Bovendien willen klanten niet dat andere klanten in hun interne netwerken kunnen worden gerouteerd, wat logisch is. Om de netwerken en de dataverkeer van klanten te scheiden, stellen we voor elk van hen een aparte namespace beschikbaar. Een namespace is in feite een kopie van de netwerkstack van Linux, wat betekent dat klanten in namespace RED volledig geĂŻsoleerd zijn van klanten in namespace GREEN (of de routering tussen deze klantnetwerken is toegestaan via de default namespace of op al het hogere transportapparatuur).
Dat geeft ons het volgende schema:
L2-tunnels convergeren vanuit alle rekenknooppunten naar de controleknop, waar de L3-interface voor deze netwerken zich bevindt, elke in de toegewezen namespace voor isolatie.
Echter, we zijn het belangrijkste vergeten. Een virtuele machine moet een dienst aan de klant bieden, wat betekent dat ze minstens Ă©Ă©n extern interface moet hebben waarlangs deze kan worden benaderd. Dit betekent dat we de externe wereld moeten betreden. Er zijn verschillende opties. Laten we de eenvoudigste optie maken. We voegen klanten elk Ă©Ă©n netwerk toe, dat geldig is in het netwerk van de provider en niet zal overlappen met andere netwerken. Netwerken kunnen ook overlappen en verschillende VRF's aan de kant van het provider-netwerk bekijken. Deze netwerken zullen ook leven in de namespace van elke klant. Maar ze zullen nog steeds de externe wereld betreden via Ă©Ă©n fysiek (of bond, wat logischer is) interface. Om het verkeer van de klanten te scheiden, zal het verkeer dat extern gaat worden getagd met een VLAN-tag die aan de klant is toegewezen.
Uiteindelijk hebben we het volgende schema gekregen:
Een gerechtvaardigde vraag is: waarom geen gateways op de compute nodes zelf maken? Daar is geen groot probleem mee, bovendien zal het werken met de inschakeling van de gedistribueerde router (DVR). In dit scenario beschouwen we de eenvoudigste optie met een gecentraliseerde gateway, die standaard in OpenStack wordt gebruikt. Voor zwaar belaste functies zullen zowel een gedistribueerde router als versnellingstechnologieën zoals SR-IOV en Passthrough worden gebruikt, maar zoals men zegt, dat is een heel ander verhaal. Laten we eerst de basiscomponenten begrijpen en dan de details bekijken.
Eigenlijk is ons schema al operationeel, maar er zijn een paar nuanceringen:
- We moeten onze machines op de een of andere manier beschermen, dus we moeten een filter op de switch-interface naar de klant hangen.
- Zorg ervoor dat de virtuele machine automatisch een IP-adres verkrijgt, zodat we niet elke keer via de console naar binnen hoeven te gaan om een adres in te voeren.
Laten we beginnen met het beveiligen van de machines. Hiervoor kunnen we eenvoudige iptables gebruiken, waarom niet.
Dat betekent dat onze topologie inmiddels al iets gecompliceerder is geworden:
Laten we verdergaan. We moeten een DHCP-server toevoegen. De ideale plek voor het plaatsen van DHCP-servers voor elke klant zou de eerder genoemde controle-node zijn, waar de namespaces zich bevinden:
Er is echter een klein probleem. Wat als alles opnieuw opstart en alle informatie over het huren van adressen op DHCP verdwijnt? Het is logisch dat machines nieuwe adressen zullen krijgen, wat niet erg handig is. Er zijn twee oplossingen â ofwel gebruikmaken van domeinnamen en een DNS-server toevoegen voor elke klant, dan is het adres voor ons niet zo belangrijk (vergelijkbaar met het netwerkdeel in k8s) â maar hier is er een probleem met externe netwerken, aangezien ook daar adressen via DHCP kunnen worden toegewezen â er is synchronisatie nodig met de DNS-servers op het cloudplatform en de externe DNS-server, wat naar mijn mening niet erg flexibel is, maar zeker mogelijk. Of de tweede optie â gebruikmaken van metadata â dat wil zeggen, het opslaan van informatie over het toegewezen machineadres, zodat de DHCP-server weet welk adres aan de machine moet worden toegewezen als de machine al een adres heeft gekregen. De tweede optie is eenvoudiger en flexibeler, omdat het mogelijk is extra informatie over de machine te bewaren. Laten we nu de metadata-agent aan de diagram toevoegen:
Een andere vraag die ook aandacht verdient, is de mogelijkheid om Ă©Ă©n extern netwerk door alle klanten te gebruiken, aangezien externe netwerken, als ze geldig moeten zijn binnen het hele netwerk, voor complicaties kunnen zorgen â we moeten deze netwerken voortdurend toewijzen en controleren. De mogelijkheid om een enkele, voor alle klanten vooraf geconfigureerde extern netwerk te gebruiken, zou zeer welkom zijn bij het opzetten van een publiek cloud. Dit zou het implementeren van machines vereenvoudigen, omdat we niet hoeven te controleren met de database van adressen en een unieke adresruimte voor het externe netwerk van elke klant hoeven te kiezen. Bovendien kunnen we het externe netwerk van tevoren definiĂ«ren, en tijdens de implementatie hoeven we alleen maar de externe adressen aan de klantmachines te associĂ«ren.
En dit is waar NAT in beeld komt - we zorgen ervoor dat klanten de externe wereld kunnen betreden via de default namespace met behulp van NAT-translatie. Er is echter een klein probleem. Dit werkt goed als de klantserver als client fungeert en niet als server - dat wil zeggen, als deze verbindingen initieert in plaats van aanneemt. Maar in ons geval is het precies andersom. In dat geval moeten we destination NAT maken, zodat de controlenode bij het ontvangen van verkeer begrijpt dat dit verkeer bedoeld is voor virtuele machine A van klant A, en daarom moeten we de NAT-translatie maken van het externe adres, bijvoorbeeld 100.1.1.1, naar het interne adres 10.0.0.1. In zo'n geval, hoewel alle klanten hetzelfde netwerk gebruiken, blijft de interne isolatie volledig behouden. We moeten dus dNAT en sNAT op de controlenode implementeren. Het gebruik van een enkel netwerk met toewijzing van drijvende adressen of externe netwerken of beide tegelijkertijd hangt af van wat je naar de cloud wilt brengen. We zullen niet nog eens drijvende adressen aan de schema toevoegen, maar blijven bij de eerder toegevoegde externe netwerken - elke klant heeft zijn eigen externe netwerk (aangeduid op het schema als VLAN 100 en 200 op de externe interface).
Uiteindelijk hebben we een interessante en tegelijkertijd doordachte oplossing gekregen, die bepaalde flexibiliteit biedt maar nog niet over mechanismen voor fouttolerantie beschikt.
Allereerst hebben we maar één controlenode - het falen daarvan leidt tot een totale systeemcrash. Om dit probleem op te lossen, is het noodzakelijk om minimaal een quorum van 3 nodes te creëren. We zullen dit aan het schema toevoegen:
Natuurlijk synchroniseren alle nodes en wanneer de actieve node uitvalt, zal een andere node de taken overnemen.
Het volgende probleem zijn de schijven van virtuele machines. Op dit moment worden ze opgeslagen op de hypervisors zelf, en bij problemen met de hypervisor verliezen we alle gegevens - en de aanwezigheid van een RAID-configuratie helpt niet als we niet alleen een schijf, maar de hele server verliezen. Daarom moeten we een dienst ontwikkelen die fungeert als de front-end voor een opslagoplossing. Het maakt ons niet zo veel uit welke opslag dit is, maar deze moet onze gegevens beschermen tegen falen van zowel de schijf als de node, en mogelijk zelfs van de hele kast. Er zijn verschillende opties - er zijn natuurlijk SAN-netwerken met Fiber Channel, maar laten we eerlijk zijn: FC is al een verouderde technologie - vergelijkbaar met E1 in transport. Ja, het wordt nog steeds gebruikt, maar alleen daar waar het niet anders kan. Daarom zou ik in 2020 niet vrijwillig een FC-netwerk opzetten, wetende dat er andere, interessantere alternatieven zijn. Hoewel ieder zijn voorkeuren heeft, en er misschien mensen zijn die denken dat FC met al zijn beperkingen precies is wat we nodig hebben - ik ga daar niet over discussiëren, iedereen heeft zijn mening. Echter, de voor mij meest interessante oplossing is het gebruik van SDS, bijvoorbeeld Ceph.
Ceph maakt het mogelijk om een hoogbeschikbaar dataopslagoplossing te creëren met tal van mogelijkheden voor gegevensreplicatie, variërend van codes met pariteitscontrole (vergelijkbaar met RAID 5 of 6) tot volledige replicatie van gegevens op verschillende schijven, rekening houdend met de locatie van de schijven in servers, en de servers in kasten, enz.
Voor het opzetten van Ceph zijn nog 3 nodes nodig. De interactie met de opslag zal ook via het netwerk plaatsvinden met behulp van block-, object- en file storage diensten. Laten we opslag aan het schema toevoegen:
Opmerking: hyperconvergerende compute-nodes zijn ook mogelijk - dit is het concept van het samenvoegen van verschillende functies op Ă©Ă©n node - bijvoorbeeld storage+compute - er hoeven geen speciale nodes voor ceph storage te worden toegewezen. We krijgen een even robuuste opzet, aangezien SDS de gegevens reserveert met het door ons aangegeven niveau van redundantie. Echter, hyperconvergerende nodes zijn altijd een compromis - aangezien de storage node niet gewoon lucht verwarmt zoals het op het eerste gezicht lijkt (aangezien er geen virtuele machines op draaien) - verbruikt het CPU-resources voor het onderhoud van SDS (in feite maakt het op de achtergrond alle replicaties en herstelprocessen na storingen van nodes, schijven, enzovoort). Dat wil zeggen, je verliest een deel van de kracht van de compute node als je deze samenvoegt met storage.
Al deze middelen moeten op de één of andere manier worden beheerd - we hebben iets nodig waarmee we een machine, netwerk, virtuele router, enzovoort kunnen creëren. Hiervoor voegen we een service toe aan de controle-node die als dashboard zal dienen - de klant kan verbinding maken met dit portaal via http/https en alles doen wat hij nodig heeft (nou ja, bijna alles).
Uiteindelijk hebben we nu een hoogbeschikbare systeem. Alle onderdelen van deze infrastructuur moeten op de Ă©Ă©n of andere manier beheerd worden. Eerder is beschreven dat Openstack een set projecten is, elk met een specifieke functie. Zoals we zien, zijn er meer dan genoeg elementen die geconfigureerd en gecontroleerd moeten worden. Vandaag zullen we het netwerkgedeelte bespreken.
Architectuur van Neutron
In OpenStack is Neutron verantwoordelijk voor het aansluiten van de poorten van virtuele machines aan het gedeelde L2-netwerk, het waarborgen van de routering van verkeer tussen VM's in verschillende L2-netwerken en de routering naar buiten, het bieden van diensten zoals NAT, Floating IP, DHCP, enzovoort.
De werking van de netwerksdienst op hoog niveau (basisdeel) kan als volgt worden beschreven.
Bij het opstarten van een VM zorgt de netwerksdienst voor:
- Creëert een poort voor deze VM (of poorten) en stelt de DHCP-service hiervan op de hoogte;
- Er wordt een nieuw virtueel netwerkapparaat gecreëerd (via libvirt);
- De VM maakt verbinding met de poort(en) die in stap 1 zijn gemaakt;
Verrassend genoeg zijn de basismechanismen waarop Neutron werkt standaardmechanismen die iedereen bekend zijn die ooit in Linux is gedoken - dit zijn namespaces, iptables, linux bridges, openvswitch, conntrack, enzovoort.
Het moet meteen worden verduidelijkt dat Neutron geen SDN-controller is.
Neutron bestaat uit verschillende met elkaar verbonden componenten:
Openstack-neutron-server â is a daemon that works with user requests via API. This daemon does not handle any network connections but provides the necessary information to its plugins, which then configure the required network element. Neutron agents on OpenStack nodes register with the Neutron server.
Neutron server is essentially an application written in Python, consisting of two parts:
- REST service
- Neutron Plugin (core/service)
The REST service is designed to receive API calls from other components (for example, requests for specific information, etc.)
Plugins are plug-in software components/modules that are invoked during API requests â that is, the assignment of a service occurs through them. Plugins are divided into two types â service and core. Typically, the core plugin is primarily responsible for managing the address space and L2 connections between VMs, while service plugins provide additional functionalities such as VPN or FW.
The list of available plugins can be viewed, for example,
There may be several service plugins, but there can be only one core plugin.
OpenStack Neutron ML2 â is the standard core plugin for OpenStack. This plugin has a modular architecture (unlike its predecessor) and configures the network service through its connected drivers. We will review the plugin shortly, as it provides the flexibility that OpenStack has in the networking aspect. The core plugin can be replaced (for example, Contrail Networking does such a replacement).
RPC service (rabbitmq-server) â is a service that manages queues and interacts with other OpenStack services as well as facilitates interaction between network service agents.
Network agents â agents that are located on each node, through which the configuration of network services is carried out.
There are several types of agents.
The main agent is the L2 agent. Deze agents worden op elke hypervisor uitgevoerd, inclusief de controle knooppunten (eigenlijk op alle knooppunten die een of andere service voor tenants bieden) en hun belangrijkste functie is het verbinden van virtuele machines met het gedeelde L2-netwerk, evenals het genereren van waarschuwingen bij het optreden van bepaalde gebeurtenissen (bijvoorbeeld het in- of uitschakelen van een poort).
De volgende, niet minder belangrijke agent is L3-agent. Standaard wordt deze agent uitsluitend op de network node uitgevoerd (vaak is de network node gecombineerd met de control node) en zorgt voor de routering tussen de netwerken van de tenants (zowel tussen zijn eigen netwerken als die van andere tenants, en hij is ook beschikbaar voor de externe wereld, met NAT en DHCP-service). Echter, bij het gebruik van DVR (gedistribueerde router) ontstaat de noodzaak voor de L3-plugin ook op compute nodes.
De L3-agent gebruikt Linux namespaces om elke tenant een set eigen geĂŻsoleerde netwerken en de functionaliteit van virtuele routers te bieden, die het verkeer routeren en gateway-services voor Layer 2-netwerken aanbieden.
Database â een database van net-id's, subnets, poorten, pools, enz.
Feitelijk ontvangt Neutron API-verzoeken voor het creëren van netwerkinstanties, authenticatieert het verzoek, en via RPC (wanneer het een plug-in of agent aanspreekt) of REST API (wanneer het communiceert in SDN) geeft het instructies aan de agents (via de plugins) die nodig zijn om de gevraagde service te organiseren.
Laten we nu eens kijken naar de testinstallatie (hoe deze is opgezet en wat erin zit, bekijken we later in de praktische sectie) en zien waar elke component is gelegen:
(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 ~]$ 
Hier is de volledige structuur van Neutron. Laten we nu wat tijd besteden aan de ML2-plugin.
Modular Layer 2
Zoals eerder vermeld, is de plugin de standaard root plugin van OpenStack en heeft het een modulaire architectuur.
De voorganger van de ML2-plugin had een monolithische structuur die bijvoorbeeld niet toestond om een mix van verschillende technologieĂ«n in Ă©Ă©n installatie te gebruiken. Je kon bijvoorbeeld niet zowel openvswitch als linuxbridge tegelijkertijd gebruiken â het was of het een, of het ander. Om deze reden is de ML2-plugin met zijn architectuur ontwikkeld.
ML2 heeft twee componenten â twee soorten drivers: Type drivers en Mechanism drivers.
Type drivers bepalen de technologieën die zullen worden gebruikt voor het organiseren van netwerkverbindingen, zoals VxLAN, VLAN, GRE. De driver staat het gebruik van verschillende technologieën toe. De standaardtechnologie is VxLAN encapsulatie voor overlay-netwerken en VLAN voor externe netwerken.
De volgende netwerktypen vallen onder Type drivers:
Flat â onge-tagged netwerk
VLAN â tagged netwerk
Local â een speciaal type netwerk voor all-in-one installaties (deze installaties zijn nodig voor ontwikkelaars of voor training)
GRE â overlay netwerk dat GRE-tunnels gebruikt
VxLAN â overlay netwerk dat VxLAN-tunnels gebruikt
Mechanism drivers bepalen de middelen die zorgen voor de organisatie van de in type driver aangegeven technologieën - bijvoorbeeld openvswitch, sr-iov, opendaylight, OVN, enz.
Afhankelijk van de implementatie van deze driver worden ofwel agents gebruikt die door Neutron worden beheerd, of worden er verbindingen met een externe SDN-controller gebruikt, die alle taken met betrekking tot de organisatie van L2-netwerken, routing, enz. op zich neemt.
Bijvoorbeeld, als we ML2 gebruiken samen met OVS, wordt er op elke compute-node een L2-agent geĂŻnstalleerd die OVS beheert. Maar als we bijvoorbeeld OVN of OpenDayLight gebruiken, valt het beheer van OVS onder hun jurisdictie â Neutron geeft via de root-plugin instructies aan de controller, en deze voert de gegeven commando's uit.
Laten we Open vSwitch in herinnering brengen.
Op dit moment is Open vSwitch een van de sleutelcomponenten van OpenStack.
Bij het installeren van OpenStack zonder aanvullende vendor-specifieke SDN zoals Juniper Contrail of Nokia Nuage, is OVS de belangrijkste netwerkcomponent van het cloudnetwerk en in combinatie met iptables, conntrack, namespaces maakt het volledige overlay-netwerken met multitenancy mogelijk. Natuurlijk kan deze component worden vervangen, bijvoorbeeld bij het gebruik van externe proprietary (vendor-specifieke) SDN-oplossingen.
OVS is een open-source software-switch die bedoeld is voor gebruik in gevirtualiseerde omgevingen als virtuele verkeersforewarder.
Momenteel heeft OVS een behoorlijk functioneel scala, inclusief technologieën zoals QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, enz.
Opmerking: OVS was aanvankelijk niet ontworpen als software-switch voor zwaarbelaste telecomfuncties en was meer gericht op minder veeleisende IT-functies zoals webservers of mailservers. Echter, OVS wordt verder ontwikkeld en de huidige implementaties hebben de prestaties en mogelijkheden aanzienlijk verbeterd, waardoor het kan worden gebruikt door telecomoperators met zwaarbelaste functies; er is bijvoorbeeld een implementatie van OVS met ondersteuning voor DPDK-versnelling.
Er zijn drie belangrijke componenten van OVS waarvan je op de hoogte moet zijn:
- Kernelmodule â een component die zich in de kernelruimte bevindt en verkeer verwerkt op basis van de van de beheereenheid ontvangen regels;
- vSwitch Deemon (ovs-vswitchd) is een proces dat wordt uitgevoerd in de user space en verantwoordelijk is voor het programmeren van de kernelmodule - dat wil zeggen, het vertegenwoordigt de logica van de werking van de switch.
- Database server Een lokale database die op elke host is gelegen waar OVS draait, en waarin de configuratie wordt opgeslagen. Via deze module kunnen SDN-controllers communiceren via het OVSDB-protocol.
Hierbij hoort ook een set diagnostische en beheertools zoals ovs-vsctl, ovs-appctl, ovs-ofctl, enzovoorts.
Op dit moment wordt Openstack veel gebruikt door telecomoperators voor de migratie van netwerkfuncties zoals EPC, SBC, HLR, enzovoorts. Een deel van de functies kan probleemloos functioneren met OVS zoals het is, maar bijvoorbeeld EPC verwerkt het verkeer van abonnees - met andere woorden, het laat een enorme hoeveelheid verkeer door (momenteel bereiken de verkeersvolumes enkele honderden gigabits per seconde). Natuurlijk is het niet de beste optie om zo'n verkeer door de kernel space te leiden (aangezien de forwarder zich daar standaard bevindt). Daarom wordt OVS vaak volledig in de user space uitgerold met behulp van DPDK-technologie voor het doorsturen van verkeer van NIC naar user space om de kernel te omzeilen.
Opmerking: voor de cloud die is uitgerold voor telecomfuncties is het mogelijk om verkeer van de compute-node rechtstreeks naar de switches te sturen, zonder OVS. Voor dit doel worden SR-IOV- en Passthrough-mechanismen gebruikt.
Hoe werkt dit in een echt model?
Laten we nu naar het praktische deel gaan en bekijken hoe dit alles in de praktijk werkt.
Om te beginnen gaan we een eenvoudige Openstack-installatie uitvoeren. Aangezien ik geen serverfarm tot mijn beschikking heb voor experimenten, gaan we het model opbouwen op één fysieke server met virtuele machines. Ja, uiteraard is zo'n oplossing niet geschikt voor commerciële doeleinden, maar om een voorbeeld te zien van hoe het netwerk in Openstack werkt, is deze installatie meer dan voldoende. Bovendien is zo'n installatie voor leerdoeleinden zelfs interessanter - omdat je het verkeer kunt monitoren, enzovoorts.
Aangezien we alleen de basisfunctie willen zien, kunnen we het met slechts twee netwerken doen, waarbij het tweede netwerk in dit model alleen wordt gebruikt voor toegang tot de undercloud en de dns-server. We zullen de externe netwerken voorlopig niet behandelen - dit is een onderwerp voor een apart, uitgebreid artikel.
Laten we systematisch beginnen. Eerst wat theorie. We gaan OpenStack installeren met behulp van TripleO (OpenStack op OpenStack). Het idee achter TripleO is dat we OpenStack all-in-one installeren (dat wil zeggen op Ă©Ă©n node), ook wel ondercloud genoemd, en vervolgens de capaciteiten van de uitgerolde OpenStack gebruiken om OpenStack te installeren voor operationeel gebruik, genaamd overcloud. De ondercloud zal gebruikmaken van de ingebouwde mogelijkheid om fysieke servers (bare metal) te beheren â het Ironic-project â voor het provisioneren van hypervisors die de rollen van compute-, control- en storage-nodes vervullen. Dit betekent dat we geen externe middelen gebruiken voor de uitrol van OpenStack â we zetten OpenStack op met de middelen van OpenStack. Naarmate de installatie vordert, zal het veel duidelijker worden, dus laten we hier niet bij stil staan en verder gaan.
Opmerking: In dit artikel heb ik ter vereenvoudiging geen netwerkisolatie gebruikt voor de interne netwerken van OpenStack, en alles is opgezet met slechts Ă©Ă©n netwerk. Het al dan niet hebben van netwerkisolatie heeft echter geen invloed op de basisfunctionaliteit van de oplossing â alles zal precies zo werken als bij het gebruik van isolatie, maar het verkeer zal in Ă©Ă©n netwerk lopen. Voor commerciĂ«le installaties is het natuurlijk noodzakelijk om isolatie te gebruiken met verschillende VLAN's en interfaces. Bijvoorbeeld, het beheerverkeer van de Ceph-opslag en het dataverkeer (de communicatie van machines met schijven etc.) gebruiken bij isolatie verschillende subnetten (Storage management en Storage), waardoor de oplossing robuuster wordt door dit verkeer bijvoorbeeld over verschillende poorten te scheiden, of verschillende QoS-profielen voor verschillend verkeer te gebruiken, zodat dataverkeer het signaalverkeer niet verdringt. In ons geval zal alles echter in hetzelfde netwerk plaatsvinden en feitelijk beperkt ons dat op geen enkele manier.
Opmerking: Aangezien we van plan zijn virtuele machines te draaien in een virtuele omgeving die is gebaseerd op virtuele machines, moeten we eerst de geneste virtualisatie inschakelen.
Je kunt controleren of geneste virtualisatie is ingeschakeld of niet als volgt:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Als je de letter N ziet, dan schakel je de ondersteuning voor geneste virtualisatie in volgens een handleiding die je ergens op het internet vindt, bijvoorbeeld .
We moeten een schema opbouwen van virtuele machines zoals deze:
In mijn geval heb ik OpenvSwitch gebruikt voor de verbinding tussen de virtuele machines die deel uitmaken van de toekomstige installatie (ik heb er 7, maar met 4 kom je ook toe als je niet veel middelen hebt). Ik heb Ă©Ă©n ovs-brug gemaakt en de virtuele machines verbonden via port-groups. Hiervoor heb ik een xml-bestand van de volgende vorm aangemaakt:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67Hier worden drie portgroepen gedefinieerd â twee access en Ă©Ă©n trunk (de laatste was nodig voor de DNS-server, maar je kunt het ook zonder doen of het op de hostmachine opzetten â dat is aan jou). Vervolgens definiĂ«ren we ons netwerk met behulp van dit sjabloon via virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nu passen we de configuraties van de poorten van de hypervisor aan:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Opmerking: in dit scenario is het adres op de poort ovs-br1 niet beschikbaar, omdat het geen VLAN-tag heeft. Om dit te verhelpen, moet je de opdracht sudo ovs-vsctl set port ovs-br1 tag=100 geven. Maar na herstart verdwijnt deze tag (als iemand weet hoe hij deze op zijn plaats kan houden, ben ik daar zeer dankbaar voor). Maar dit is niet zo belangrijk, want dit adres hebben we alleen nodig tijdens de installatie en is niet meer nodig zodra Openstack volledig is uitgerold.
Vervolgens maken we de undercloud-machine aan:
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=ttyS0Tijdens de installatie stelt u alle benodigde parameters in, zoals de naam van de machine, wachtwoorden, gebruikers, NTP-servers, enzovoort. Je kunt ook meteen de poorten instellen, maar persoonlijk vind ik het makkelijker om na de installatie via de console in de machine te komen en de benodigde bestanden te wijzigen. Als u al een kant-en-klaar beeld heeft, kunt u dit gebruiken, of zoals ik doen â download een minimalistisch beeld van CentOS 7 en gebruik dit voor het installeren van de VM.
Na een succesvolle installatie zou u een virtuele machine moeten hebben waarop u undercloud kunt installeren.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningLaten we eerst de benodigde gereedschappen voor de installatie installeren:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Installatie van Undercloud
We creëren de gebruiker stack, stellen een wachtwoord in, voegen deze toe aan sudoer en geven hem de mogelijkheid om root-commando's uit te voeren via sudo zonder dat een wachtwoord vereist is:
useradd stack
passwd stack
echo "stack ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNu geven we in het hosts-bestand de volledige naam van undercloud op:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Vervolgens voegen we de repositories toe en installeren we de benodigde software:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleOpmerking: als u niet van plan bent ceph te installeren, hoeft u de commando's met betrekking tot ceph niet uit te voeren. Ik heb de Queens-release gebruikt, maar u kunt elke andere versie gebruiken die u leuk vindt.
Kopiëren van het configuratiebestand van undercloud naar de persoonlijke map van de gebruiker stack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNu moet dit bestand worden aangepast, zodat het geschikt is voor onze installatie.
Aan het begin van het bestand moeten de volgende regels worden toegevoegd:
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 = 10Laten we de instellingen doornemen:
undercloud_hostname â de volledige naam van de undercloud-server, moet overeenkomen met de vermelding op de DNS-server
local_ip â lokaal adres undercloud in de richting van het provisioning-netwerk
network_gateway â ditzelfde lokale adres, dat als gateway zal dienen voor toegang tot de externe wereld tijdens de installatie van overcloud knooppunten, komt ook overeen met het lokale ip
undercloud_public_host â adres van de externe API, toegewezen aan een vrij adres uit het provisioning-netwerk
undercloud_admin_host adres van de interne API, toegewezen aan een vrij adres uit het provisioning-netwerk
undercloud_nameservers â DNS-server
generate_service_certificate â deze regel is erg belangrijk in het huidige voorbeeld, want als je deze niet op false zet, krijg je een fout tijdens de installatie, het probleem is beschreven in de bugtracker van Red Hat
local_interface interface in het provisioning-netwerk. Deze interface zal opnieuw worden geconfigureerd tijdens de uitrol van de undercloud, dus de undercloud moet over twee interfaces beschikken â Ă©Ă©n voor toegang tot de undercloud en de tweede voor provisioning
local_mtu â MTU. Aangezien we een testlaboratorium hebben en mijn MTU 1500 is op de OVS-switchpoorten, moet deze worden ingesteld op 1450, zodat ingekapselde VxLAN-pakketten doorgestuurd kunnen worden
network_cidr â provisioning netwerk
masquerade â gebruik van NAT voor toegang tot het externe netwerk
masquerade_network â netwerk dat NAT zal hebben
dhcp_start â startadres van de pool waaruit adressen aan de knooppunten zullen worden toegewezen tijdens de implementatie van de overcloud
dhcp_end â eindadres van de pool waaruit adressen aan de knooppunten zullen worden toegewezen tijdens de implementatie van de overcloud
inspection_iprange â pool adressen nodig voor introspectie (mag niet overlappen met de eerder genoemde pool)
scheduler_max_attempts â maximaal aantal pogingen voor installatie van de overcloud (moet groter of gelijk zijn aan het aantal knooppunten)
Nadat het bestand is beschreven, kan de opdracht voor de uitrol van de undercloud worden gegeven:
openstack undercloud install
De procedure duurt 10 tot 30 minuten, afhankelijk van je hardware. Uiteindelijk zou je de volgende uitvoer moeten zien:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Ondercloud-installatie voltooid.
Het bestand met de wachtwoorden van deze installatie bevindt zich op
/home/stack/undercloud-passwords.conf.
Er is ook een stackrc-bestand op /home/stack/stackrc.
Deze bestanden zijn nodig om interactie te hebben met de OpenStack-diensten en moeten worden beveiligd.
#############################################################################Deze uitvoer geeft aan dat je de undercloud succesvol hebt geĂŻnstalleerd en nu de staat van de undercloud kunt controleren om over te gaan naar de installatie van de overcloud.
Als je de uitvoer ifconfig bekijkt, zul je zien dat er een nieuwe bridge-interface is verschenen
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163 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
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 0Via deze interface zal nu de implementatie van overcloud plaatsvinden.
Uit de onderstaande uitvoer blijkt dat alle services op Ă©Ă©n node zijn:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Hostnaam | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Hieronder is de netwerconfiguratie van de undercloud weergegeven:
(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 ~]$Installeren van overcloud
Op dit moment hebben we alleen de undercloud, en we missen de nodes waaruit de overcloud zal worden opgebouwd. Daarom gaan we eerst de benodigde virtuele machines implementeren. Tijdens de deployment zal de undercloud zelf het besturingssysteem en de benodigde software op de overcloud machines installeren â dat wil zeggen dat we de machine niet volledig hoeven te implementeren, maar alleen een schijf (of schijven) voor haar moeten aanmaken en haar parameters moeten definiĂ«ren â we krijgen dus feitelijk een kale server zonder een geĂŻnstalleerd besturingssysteem.
Laten we naar de map met de schijven van onze virtuele machines gaan en de benodigde schijven van de juiste grootte aanmaken:
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 160GAangezien we als root handelen, moeten we de eigenaar van deze schijven wijzigen om problemen met rechten te voorkomen:
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu \/var\/lib\/libvirt\/images\/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Opmerking: als je van plan bent om ceph niet voor studie doeleinden te installeren, creëer dan geen minimum van 3 nodes met minimaal twee schijven, en geef in de template aan dat virtuele schijven vda, vdb, etc. zullen worden gebruikt.
Geweldig, nu moeten we al deze machines definiëren:
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 het einde zijn er commando's âprint-xml > \/tmp\/storage-1.xml, die een xml-bestand maakt met de beschrijving van elke machine in de map \/tmp\/, als je het niet toevoegt, kun je de virtuele machines niet definiĂ«ren.
Nu moeten we al deze machines in virsh definiëren:
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 Staat
----------------------------------------------------
6 dns-server draait
64 undercloud draait
- compute-1 uitgeschakeld
- compute-2 uitgeschakeld
- control-1 uitgeschakeld
- storage-1 uitgeschakeld
- storage-2 uitgeschakeld
[root@hp-gen9 ~]#Nu een klein detail â tripleO gebruikt IPMI om de servers te beheren tijdens de installatie en introspectie.
Introspectie is het proces van inspectie van de hardware om de parameters te verkrijgen die nodig zijn voor de verdere provisioning van nodes. Introspectie gebeurt met behulp van ironic â een service die is bedoeld voor het werken met bare metal servers.
Maar hier is het probleem â als bij fysieke servers IPMI een aparte poort is (of een gedeelde poort, maar dat is niet cruciaal), dan hebben virtuele machines dergelijke poorten niet. Hier komt een workaround genaamd vbmc om de hoek kijken â een hulpmiddel dat het mogelijk maakt om een IPMI-poort te emuleren. Dit detail is vooral relevant voor degenen die zo'n laboratorium op de ESXi hypervisor willen opzetten â eerlijk gezegd weet ik niet of er een equivalent van vbmc is, dus het is de moeite waard om deze kwestie te overdenken voordat je alles opzet.
We installeren vbmc:
yum install python2-virtualbmcAls je besturingssysteem het pakket niet kan vinden, voeg dan de repository toe:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNu configureren we het hulpmiddel. Het is allemaal verbazend eenvoudig. Het is nu logisch dat er geen servers in de vbmc-lijst staan.
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Om ze te laten verschijnen, moeten ze handmatig op deze manier worden toegevoegd:
[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
+-------------+--------+---------+------+
| Domeinnaam | Status | Adres | Poort |
+-------------+--------+---------+------+
| compute-1 | uit | :: | 7004 |
| compute-2 | uit | :: | 7005 |
| control-1 | uit | :: | 7001 |
| storage-1 | uit | :: | 7002 |
| storage-2 | uit | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Ik denk dat de syntaxis van het commando duidelijk is zonder uitleg. Echter, tot nu toe staan al onze sessies in de status DOWN. Om ze naar STATUS UP te laten overgaan, moeten ze ingeschakeld worden:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] vBMC-instantie voor domein control-1 gestart
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] vBMC-instantie voor domein storage-1 gestart
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] vBMC-instantie voor domein storage-2 gestart
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] vBMC-instantie voor domein compute-1 gestart
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] vBMC-instantie voor domein compute-2 gestart
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domeinnaam | Status | Adres | Poort |
+-------------+---------+---------+------+
| compute-1 | draaiend| :: | 7004 |
| compute-2 | draaiend| :: | 7005 |
| control-1 | draaiend| :: | 7001 |
| storage-1 | draaiend| :: | 7002 |
| storage-2 | draaiend| :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#De laatste stap is om de firewallregels te corrigeren (of deze helemaal uit te schakelen):
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
Laten we nu naar de undercloud gaan en controleren of alles werkt. Het adres van de hostmachine is 192.168.255.200, op de undercloud hebben we het nodige pakket ipmitool toegevoegd tijdens de voorbereiding op de deployment:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Naam Status
----------------------------------------------------
6 dns-server draaiend
64 undercloud draaiend
65 control-1 draaiendZoals u ziet, hebben we de control-node met succes via vbmc opgestart. Laten we deze nu uitschakelen en verder gaan:
[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 Naam Status
----------------------------------------------------
6 dns-server draaiend
64 undercloud draaiend
- compute-1 uitgeschakeld
- compute-2 uitgeschakeld
- control-1 uitgeschakeld
- storage-1 uitgeschakeld
- storage-2 uitgeschakeld
[root@hp-gen9 ~]#De volgende stap is de inspectie van de nodes waarop de overcloud zal worden geĂŻnstalleerd. Hiervoor moeten we een json-bestand voorbereiden met een beschrijving van onze nodes. Let op dat in tegenstelling tot de installatie op kale servers in het bestand de poort is vermeld waarop vbmc voor elk van de machines draait.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Opmerking: op de controle-node zijn er twee interfaces, maar dat is in dit geval niet belangrijk, in deze installatie is Ă©Ă©n genoeg.
Laten we nu het json-bestand voorbereiden. We moeten het MAC-adres van de poort opgeven waarmee provisioning zal plaatsvinden, de parameters van de nodes instellen, namen toewijzen en aangeven hoe we op ipmi kunnen komen:
{
"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"
}
]
}Nu moeten we de images voor ironic voorbereiden. Hiervoor downloaden we ze via wget en installeren we:
(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 ~]$Beelden worden in undercloud geladen:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~\/images\/
Afbeelding "overcloud-full-vmlinuz" is geĂŒpload.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Naam | Schijfformaat | Grootte | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | actief |
+--------------------------------------+------------------------+-------------+---------+--------+
Afbeelding "overcloud-full-initrd" is geĂŒpload.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Naam | Schijfformaat | Grootte | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | actief |
+--------------------------------------+-----------------------+-------------+----------+--------+
Afbeelding "overcloud-full" is geĂŒpload.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Naam | Schijfformaat | Grootte | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | actief |
+--------------------------------------+----------------+-------------+------------+--------+
Afbeelding "bm-deploy-kernel" is geĂŒpload.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Naam | Schijfformaat | Grootte | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | actief |
+--------------------------------------+------------------+-------------+---------+--------+
Afbeelding "bm-deploy-ramdisk" is geĂŒpload.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Naam | Schijfformaat | Grootte | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | actief |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$We controleren of alle afbeeldingen zijn geĂŒpload.
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Naam | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | actief |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | actief |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | actief |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | actief |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | actief |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Een laatste stap â we moeten de dns-server toevoegen:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Naam | Netwerk | 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
+-------------------+-----------------------------------------------------------+
| Veld | Waarde |
+-------------------+-----------------------------------------------------------+
| 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 | Waar |
| gateway_ip | 192.168.255.1 |
| host_routes | bestemming='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | Geen |
| ipv6_ra_mode | Geen |
| naam | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | Geen |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | Geen |
| service_types | |
| subnetpool_id | Geen |
| 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 verouderd en zal in de toekomst worden verwijderd. Gebruik in plaats daarvan openstack CLI.
Bijgewerkte subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nu kunnen we de opdracht voor introspectie geven:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Mistral Workflow tripleo.baremetal.v1.register_or_update gestart. Uitvoerings-ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Wachten op berichten in de wachtrij 'tripleo' zonder tijdslimiet.
5 node(s) zijn succesvol naar de "beheersbare" status verplaatst.
Node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 succesvol geregistreerd
Node UUID b89a72a3-6bb7-429a-93bc-48393d225838 succesvol geregistreerd
Node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e succesvol geregistreerd
Node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 succesvol geregistreerd
Node UUID 766ab623-464c-423d-a529-d9afb69d1167 succesvol geregistreerd
Wachten tot introspectie is voltooid...
Mistral Workflow tripleo.baremetal.v1.introspect gestart. Uitvoerings-ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Wachten op berichten in de wachtrij 'tripleo' zonder tijdslimiet.
Introspectie van node b89a72a3-6bb7-429a-93bc-48393d225838 voltooid. Status: SUCCESS. Fouten: Geen
Introspectie van node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e voltooid. Status: SUCCESS. Fouten: Geen
Introspectie van node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 voltooid. Status: SUCCESS. Fouten: Geen
Introspectie van node 766ab623-464c-423d-a529-d9afb69d1167 voltooid. Status: SUCCESS. Fouten: Geen
Introspectie van node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 voltooid. Status: SUCCESS. Fouten: Geen
5 node(s) succesvol geĂŻntrospecteerd.
Mistral Workflow tripleo.baremetal.v1.provide gestart. Uitvoerings-ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Wachten op berichten in de wachtrij 'tripleo' zonder tijdslimiet.
5 node(s) zijn succesvol naar de "beschikbare" status verplaatst.
(undercloud) [stack@undercloud ~]$Zoals te zien uit de uitvoer, is alles zonder fouten afgerond. Laten we controleren of alle nodes in de status beschikbaar zijn:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Naam | Instance UUID | Stroomstaat | Provisioning Status | Onderhoud |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | Geen | uitgeschakeld| beschikbaar | Nee |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | Geen | uitgeschakeld| beschikbaar | Nee |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | Geen | uitgeschakeld| beschikbaar | Nee |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | Geen | uitgeschakeld| beschikbaar | Nee |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | Geen | uitgeschakeld| beschikbaar | Nee |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Als de nodes in een andere status zouden zijn, meestal beheersbaar, dan is er iets misgegaan en moet je de log bekijken om te begrijpen waarom dat zo is. Houd er rekening mee dat we in dit scenario virtualisatie gebruiken, en er kunnen bugs zijn gerelateerd aan het gebruik van virtuele machines of vbmc.
Vervolgens moeten we aangeven welke node welke functie zal uitvoeren â dat wil zeggen, het profiel opgeven waarmee de node zal worden gedeployed:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | beschikbaar | Geen | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | beschikbaar | Geen | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | beschikbaar | Geen | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | beschikbaar | Geen | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | beschikbaar | Geen | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(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 | Waar |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | Waar |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | Waar |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | Waar |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | Waar |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | Waar |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Geef een profiel voor elke node aan:
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-d9afb69d1167Controleer of alles correct is:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | beschikbaar | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | beschikbaar | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | beschikbaar | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | beschikbaar | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | beschikbaar | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Als alles klopt, geven we het commando om de overcloud te deployen:
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 een echte installatie worden natuurlijk gepersonaliseerde sjablonen gebruikt, maar in ons geval zou dat het proces aanzienlijk compliceren, omdat elke wijziging in het sjabloon uitgelegd moet worden. Zoals eerder vermeld, is een eenvoudige installatie voldoende om te zien hoe dit werkt.
Opmerking: de variabele --libvirt-type qemu is in dit geval nodig, omdat we nested virtualisatie gaan gebruiken. Anders zul je geen virtuele machines kunnen starten.
Nu heb je ongeveer een uur, misschien meer (afhankelijk van de hardwaremogelijkheden) en je moet hopen dat je na deze tijd de volgende melding zult zien:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE succesvol afgerond
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 niet gevonden in /home/stack/.ssh/known_hosts
Mistral Workflow tripleo.deployment.v1.get_horizon_url gestart. Executie-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 bestand: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Nu heb je bijna een volledige versie van OpenStack waarop je kunt leren, experimenteren, enz.
Laten we controleren of alles goed werkt. In de thuisdirectory van de gebruiker stack zijn er twee bestanden â een stackrc (voor het beheren van de undercloud) en de tweede overcloudrc (voor het beheren van de overcloud). Deze bestanden moeten als source worden opgegeven, omdat ze de benodigde informatie voor authenticatie bevatten.
(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 ~]$In mijn installatie is er nog Ă©Ă©n klein detail nodig - een route toevoegen op de controller, aangezien de machine waarmee ik werk zich in een ander netwerk bevindt. Hiervoor gaan we inloggen op control-1 met het account heat-admin en stellen we de route in.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Laatste aanmelding: vr 14 aug 09:47:40 2020 vanaf 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.254En nu kunt u in de horizontale omgeving inloggen. Alle informatie â adressen, inlog en wachtwoord â staat in het bestand /home/stack/overcloudrc. Het eindschema ziet er als volgt uit:
Overigens, in onze installatie werden de adressen van de machines via DHCP verstrekt en zoals u ziet, worden ze âdoor elkaarâ gegeven. U kunt in de template specifiek vastleggen welk adres aan welke machine moet worden toegewezen tijdens de deployment, als u dat nodig heeft.
Hoe gaat het verkeer tussen de virtuele machines?
In dit artikel bekijken we drie opties voor het doorsteken van verkeer.
- Twee machines op Ă©Ă©n hypervisor in Ă©Ă©n L2-netwerk.
- Twee machines op verschillende hypervisors in Ă©Ă©n L2-netwerk.
- Twee machines in verschillende netwerken (routering tussen netwerken).
De gevallen met toegang tot de externe wereld via het externe netwerk, met gebruik van drijvende adressen, evenals gedistribueerde routering bespreken we de volgende keer; voor nu beperken we ons tot intern verkeer.
Voor de controle bouwen we een dergelijk schema:
We hebben 4 virtuele machines gecreĂ«erd â 3 in Ă©Ă©n L2-netwerk â net-1, en nog 1 in het netwerk net-2.
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Naam | Huurder ID | Status | Taakstaat | Stroomstaat | Netwerken |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIEF | - | Draait | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIEF | - | Draait | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIEF | - | Draait | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIEF | - | Draait | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Laten we eens kijken op welke hypervisors de aangemaakte machines zich bevinden:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 | (overcloud) [stack@undercloud ~]$
De machines vm-1 en vm-3 bevinden zich op compute-0, de machines vm-2 en vm-4 bevinden zich op node compute-1.
Daarnaast is er een virtuele router aangemaakt om routering tussen de opgegeven netwerken mogelijk te maken:
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ De router heeft twee virtuele poorten die fungeren als gateways voor de netwerken:
(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 we bekijken hoe het verkeer gaat, laten we eens kijken naar wat we momenteel hebben op de controle-node (die ook de netwerk-node is) en op de compute-node. Laten we beginnen met de compute-node.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (intern)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (intern)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (intern)
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 ~]$Momenteel zijn er drie OVS-bridges op de node â br-int, br-tun, br-ex. Tussen hen zien we een set interfaces. Voor de duidelijkheid zullen we al deze gegevens op een schema tekenen en kijken wat eruit komt.
Op de adressen waar de VxLAN-tunnels zijn opgezet, is te zien dat Ă©Ă©n tunnel is opgezet op compute-1 (192.168.255.26), de tweede tunnel kijkt naar control-1 (192.168.255.15). Maar het meest interessante is dat br-ex geen fysieke interfaces heeft, en als we kijken welke flows zijn ingesteld, blijkt dat deze bridge momenteel alleen verkeer kan afwijzen.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163 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
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 ~]$ Uit de uitvoer blijkt dat het adres direct op de fysieke poort is aangesloten, en niet op de virtuele bridge-interface.
[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 de eerste regel moet al het verkeer dat uit de poort phy-br-ex komt, worden afgewezen.
Eigenlijk kan er voor deze bridge voorlopig geen verkeer zijn, behalve van deze interface (verbinding met br-int), en gezien de drops heeft deze bridge al BUM-verkeer ontvangen.
Dat wil zeggen, dat het verkeer van deze node alleen via een VxLAN-tunnel kan gaan en verder niet. Als we echter DVR inschakelen, verandert de situatie, maar daar zullen we een andere keer op ingaan. Bij het gebruik van netwerktussenisolatie, bijvoorbeeld met VLANs, heeft u niet Ă©Ă©n L3-interface in VLAN 0, maar meerdere interfaces. Het VxLAN-verkeer zal echter op dezelfde manier van de node komen, maar ingekapseld in een bepaalde toegewezen VLAN.
We hebben de compute-node besproken, gaan nu verder met de control-node.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (intern)
eth0 1/2: (systeem)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (intern)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (intern)
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 ~]$In feite kunnen we zeggen dat alles hetzelfde is, maar het IP-adres bevindt zich nu niet op een fysiek interface, maar op een virtuele brug. Dit is gedaan omdat deze poort de poort is waardoor het verkeer naar de externe wereld zal gaan.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163 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
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 ~]$ Deze poort is verbonden met de brug br-ex, en omdat er geen VLAN-tags op staan, is deze poort een trunkport waarop alle VLANs zijn toegestaan. Momenteel gaat het verkeer naar buiten zonder tag, wat wordt aangegeven door vlan-id 0 in de bovenstaande uitvoer.
Verder is momenteel alles vergelijkbaar met de compute-node - dezelfde bruggen, dezelfde tunnels naar de twee compute-nodes.
We will not discuss storage nodes in this article, but for understanding, it is necessary to mention that the networking part of these nodes is blatantly simple. In our case, there is only one physical port (eth0) with an assigned IP address, and thatâs it. There are no VxLAN tunnels, tunnel bridges, etc. â there is no OVS at all because it doesn't make sense. When using network isolation, there will be two interfaces on this node (physical ports, bonds, or just two VLANs â it doesnât matter â it depends on what you want) â one for management and the other for traffic (writing to disk VM, reading from disk, etc.).
Now that we have examined what we have on the nodes in the absence of any services, let's start 4 virtual machines and see how the above diagram changes â we should see ports, virtual routers, etc.
For now, our network looks like this:
We have two virtual machines on each compute node. Let's take compute-0 as an example to see how everything is configured.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ The machine has only one virtual interface â tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
This interface is looking into the Linux bridge:
[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 ~]$ As seen from the bridge output, there are only two interfaces â tap95d96a75-a0 and qvb95d96a75-a0.
Here, it is worth stopping for a moment on the types of virtual network devices in OpenStack:
vtap â a virtual interface attached to an instance (VM)
qbr â Linux bridge
qvb and qvo â vEth pair connected to Linux bridge and Open vSwitch bridge
br-int, br-tun, br-vlan â Open vSwitch bridges
patch-, int-br-, phy-br- â Open vSwitch patch interfaces connecting bridges
qg, qr, ha, fg, sg â Open vSwitch ports used by virtual devices to connect to OVS
Zoals je begrijpt, als we in de bridge een poort hebben genaamd qvb95d96a75-a0, die een vEth-paar is, dan is er ergens een bijbehorende zijde, die logisch qvo95d96a75-a0 moet worden genoemd. Laten we eens kijken welke poorten er op OVS zijn.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (intern)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (intern)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (systeem)
qvo95d96a75-a0 3/5: (systeem)
br-tun:
br-tun 65534/3: (intern)
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 ~]$ Zoals we zien, bevindt de poort zich in br-int. Br-int fungeert als een switch die de poorten van virtuele machines beëindigt. Naast qvo95d96a75-a0 is er in de uitvoer ook de poort qvo5bd37136-47 zichtbaar. Dit is de poort voor de tweede virtuele machine. Uiteindelijk ziet onze schema er nu zo uit:
De vraag die de aandachtige lezer meteen zou moeten interesseren â waarom is er een Linux bridge tussen de poort van de virtuele machine en de poort van OVS? Het idee is dat er beveiligingsgroepen worden gebruikt voor de bescherming van de machine, die in wezen iptables zijn. OVS werkt niet met iptables, daarom werd er zoân âworkaroundâ bedacht. Maar dit is verouderd â in de nieuwe versies komt conntrack daarvoor in de plaats.
Dat wil zeggen, uiteindelijk ziet het schema er zo uit:
Twee machines op Ă©Ă©n hypervisor in Ă©Ă©n L2-netwerk.
Aangezien beide VM's zich in hetzelfde L2-netwerk en op dezelfde hypervisor bevinden, zal het verkeer tussen hen logisch lokaal via br-int gaan, omdat beide machines zich in dezelfde VLAN bevinden:
[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 machines op verschillende hypervisors in Ă©Ă©n L2-netwerk.
Laten we nu kijken hoe het verkeer tussen twee machines in hetzelfde L2-netwerk zal gaan, maar gelegen op verschillende hypervisors. Eerlijk gezegd zal er niet veel veranderen, simpelweg zal het verkeer tussen de hypervisors via een vxlan-tunnel gaan. Laten we dit bekijken aan de hand van een voorbeeld.
De adressen van de virtuele machines waar we het verkeer tussen gaan bekijken:
[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 ~]$ We bekijken de forwarding tabel 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 ~]$Het verkeer moet naar poort 2 gaan â laten we bekijken welke 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 â dat is de interface in br-tun. Laten we kijken wat er met het pakket op br-tun gebeurt:
[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 ~]$ Het pakket wordt verpakt in VxLAN en verzonden naar poort 2. Laten we bekijken waar poort 2 naartoe leidt:
[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 een vxlan-tunnel op compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Laten we naar compute-1 gaan en kijken wat er verder met het pakket gebeurt:
[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 ~]$ Het MAC-adres bevindt zich in de forwarding tabel van br-int op compute-1, en zoals uit de bovenstaande output blijkt, is het zichtbaar via poort 2, die de toegang geeft tot br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Laten we dus verder kijken; het blijkt dat er in br-int op compute-1 een bestemmings-MAC aanwezig 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 betekent dat het ontvangen pakket naar poort 3 zal gaan, achter welke de virtuele machine instance-00000003 zich bevindt.
De schoonheid van het inzetten van OpenStack voor studie op virtuele infrastructuur is dat we zonder problemen het verkeer tussen hypervisors kunnen volgen en kunnen zien wat er met dat verkeer gebeurt. Dit gaan we nu doen door tcpdump te starten op de vnet-poort richting compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: aan het luisteren op vnet3, link-type EN10MB (Ethernet), opnamegrootte 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************De eerste regel laat zien dat het pakket van adres 10.0.1.85 naar adres 10.0.1.88 gaat (ICMP-verkeer), verpakt in een VxLAN-pakket met vni 22. Het pakket komt van host 192.168.255.19 (compute-0) en gaat naar host 192.168.255.26 (compute-1). We kunnen controleren of de VNI overeenkomt met de waarde die is opgegeven in ovs.
Laten we terugkeren naar deze regel actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 is de vni in hexadecimale notatie. Laten we dit getal omzetten naar decimaal:
16 = 6*16^0+1*16^1 = 6+16 = 22Dat betekent dat de vni correct is.
De tweede regel toont het omgekeerde verkeer, maar daar is verder geen uitleg voor nodig; het is vanzelfsprekend.
Twee machines in verschillende netwerken (routering tussen netwerken)
De laatste casus van vandaag is routering tussen netwerken binnen Ă©Ă©n project met behulp van een virtuele router. We bekijken het geval zonder DVR (dit bekijken we in een ander artikel), daarom vindt de routering plaats op de netwerknode. In ons geval is de netwerknode niet als afzonderlijke entiteit geĂŻmplementeerd en bevindt zich op de control- node.
Laten we eerst controleren of de routering werkt:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes van 10.0.2.8: seq=0 ttl=63 tijd=7.727 ms
64 bytes van 10.0.2.8: seq=1 ttl=63 tijd=3.832 ms
^C
--- 10.0.2.8 pingstatistieken ---
2 pakketten verzonden, 2 pakketten ontvangen, 0% pakketverlies
round-trip min/avg/max = 3.832/5.779/7.727 msAangezien het pakket in dit geval naar de gateway moet gaan en daar gerouteerd zal worden, moeten we het MAC-adres van de gateway achterhalen. Laten we de ARP-tabel in de instantie bekijken:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) op fa:16:3e:c4:64:70 [ether] op eth0
host-10-0-1-1.openstacklocal (10.0.1.1) op fa:16:3e:e6:2c:5c [ether] op eth0
host-10-0-1-90.openstacklocal (10.0.1.90) op fa:16:3e:83:ad:a4 [ether] op eth0
host-10-0-1-88.openstacklocal (10.0.1.88) op fa:16:3e:72:ad:53 [ether] op eth0Laten we eens kijken waar het verkeer naartoe moet worden gestuurd met 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 ~]$ Laten we kijken waar poort 2 naartoe leidt:
[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 ~]$ Het is logisch, het verkeer gaat naar br-tun. Laten we kijken in welke vxlan tunnel het zal worden verpakt:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ De derde poort is een vxlan tunnel:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Die kijkt naar de control node:
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Het verkeer heeft de control node bereikt, dus laten we daarop overschakelen en kijken hoe de routering zal plaatsvinden.
Zoals je je herinnert, zag de control node eruit als de compute node â dezelfde drie bridges, alleen had br-ex een fysieke poort waardoor de node verkeer naar buiten kon sturen. Het creĂ«ren van instanties heeft de configuratie op de compute nodes veranderd â er zijn linux bridges, iptables en interfaces aan de nodes toegevoegd. Het creĂ«ren van netwerken en een virtuele router heeft ook invloed gehad op de configuratie van de control node.
Dus, het is duidelijk dat het mac-adres van de gateway in de forwarding-tabel van br-int op de control node moet staan. Laten we controleren of het daar is en waar het naar kijkt:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ De MAC is zichtbaar vanuit poort qr-0c52b15f-8f. Als we terugkijken naar de lijst van virtuele poorten in Openstack, wordt dit type poort gebruikt voor de verbinding met OVS van verschillende virtuele apparaten. Om preciezer te zijn, qr is een poort naar de virtuele router, die wordt gepresenteerd als een namespace.
Laten we kijken welke namespaces er op de server zijn:
[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 ~]$ Er zijn drie instanties. Maar aan de hand van hun namen kunnen we de functie van elk afleiden. We zullen later terugkomen op de instanties met ID 0 en 1, nu is namespace qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe voor ons van belang:
[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 ~]$ Binnen deze namespace zijn er twee interne, die we eerder hebben aangemaakt. Beide virtuele poorten zijn toegevoegd aan br-int. Laten we het MAC-adres van de poort qr-0c52b15f-8f controleren, aangezien het verkeer, op basis van het bestemmings-MAC-adres, bedoeld was voor deze interface.
[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 ~]$ Dus in dit geval werkt alles volgens de standaard routeringsregels. Omdat het verkeer bedoeld is voor host 10.0.2.8, moet het via de tweede interface qr-92fa49b5-54 gaan en via de vxlan-tunnel naar de compute-node vertrekken:
[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 logisch, geen verrassingen. Laten we bekijken vanwaar het MAC-adres van host 10.0.2.8 zichtbaar 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 ~]$ Zoals het hoort, gaat het verkeer naar br-tun. Laten we zien door welke tunnel het verkeer verder gaat:
[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 ~]$ Het verkeer gaat de tunnel in naar compute-1. En op compute-1 is het eenvoudig: van br-tun gaat het pakket naar br-int en van daaruit naar de virtuele machine interface.
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Laten we controleren of dit inderdaad de juiste interface 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 ~]$ We hebben de hele route van het pakket gevolgd. Ik denk dat je hebt opgemerkt dat het verkeer door verschillende vxlan-tunnels ging en met verschillende VNI's uitkwam. Laten we bekijken welke VNI's dit zijn, waarna we een dump van de controlnode-poort verzamelen om te bevestigen dat het verkeer gaat zoals hierboven beschreven.
De tunnel naar compute-0 heeft de volgende actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Laten we 0x16 omzetten naar decimale notatie:
0x16 = 6*16^0+1*16^1 = 6+16 = 22De tunnel naar compute-1 heeft de volgende VNI: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Laten we 0x63 omzetten naar decimale notatie:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Laten we nu de dump bekijken:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: luisterend op vnet4, link-type EN10MB (Ethernet), capturegrootte 262144 bytes
*****************weggelaten*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), lengte 134)
192.168.255.19.41591 > 192.168.255.15.4789: [geen cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), lengte 84)
10.0.1.85 > 10.0.2.8: ICMP echo aanvraag, id 5378, seq 9, lengte 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), lengte 134)
192.168.255.15.38983 > 192.168.255.26.4789: [geen cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), lengte 84)
10.0.1.85 > 10.0.2.8: ICMP echo aanvraag, id 5378, seq 9, lengte 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), lengte 134)
192.168.255.26.42588 > 192.168.255.15.4789: [geen cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), lengte 84)
10.0.2.8 > 10.0.1.85: ICMP echo antwoord, id 5378, seq 9, lengte 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), lengte 134)
192.168.255.15.38983 > 192.168.255.19.4789: [geen cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), lengte 84)
10.0.2.8 > 10.0.1.85: ICMP echo antwoord, id 5378, seq 9, lengte 64
*****************weggelaten*******************Het eerste pakket is een vxlan-pakket van host 192.168.255.19 (compute-0) naar host 192.168.255.15 (control-1) met vni 22, waarin een ICMP-pakket van host 10.0.1.85 naar host 10.0.2.8 is verpakt. Zoals we hierboven hebben berekend, komt de vni overeen met wat we in de uitvoer hebben gezien.
Het tweede pakket is een vxlan-pakket van host 192.168.255.15 (control-1) naar host 192.168.255.26 (compute-1) met vni 99, waarin een ICMP-pakket van host 10.0.1.85 naar host 10.0.2.8 is verpakt. Zoals we hierboven hebben berekend, komt de vni overeen met wat we in de uitvoer hebben gezien.
De volgende twee pakketten zijn het omgekeerde verkeer van 10.0.2.8 naar 10.0.1.85.
Dus, uiteindelijk hebben we zo'n schema van de control node gekregen:
Is dat alles? We zijn twee namespaces vergeten:
[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 ~]$ Zoals we het hadden over de architectuur van het cloudplatform â het zou goed zijn als machines automatisch adressen van een DHCP-server ontvangen. Dit zijn de twee DHCP-servers voor onze twee netwerken 10.0.1.0/24 en 10.0.2.0/24.
Laten we controleren of dat zo is. In deze namespace is er maar Ă©Ă©n adres â 10.0.1.1 â het adres van de DHCP-server zelf, en dit is ook opgenomen in br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
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 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
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 0Laten we bekijken of er processen zijn die in hun naam qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 bevatten op de control node:
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Er is een dergelijk proces en op basis van de informatie die hierboven is gegeven, kunnen we bijvoorbeeld kijken wat we momenteel als huur hebben:
[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 ~]$Uiteindelijk krijgen we deze set services op de control node:
Houd er rekening mee dat dit slechts 4 machines zijn, 2 interne netwerken en één virtuele router... We hebben momenteel geen externe netwerken, geen verschillende projecten, elk met zijn eigen (overlappende) netwerken, en we hebben de gedistribueerde router uitgeschakeld. Bovendien was er in de testomgeving maar één control node (voor redundantie moet er quorum zijn van drie nodes). Het is logisch dat commerciële setups 'een beetje' complexer zijn, maar in dit eenvoudige voorbeeld begrijpen we hoe het zou moeten werken - of je nu 3 of 300 namespaces hebt, het is natuurlijk belangrijk, maar vanuit het perspectief van de hele opstelling verandert er weinig... Tenzij je een vendor SDN aansluit. Maar dat is een heel ander verhaal.
Ik hoop dat het interessant was. Als er opmerkingen of aanvullingen zijn, of als ik ergens eerlijk gezegd heb gelogen (ik ben ook maar een mens en mijn mening zal altijd subjectief zijn) - laat het me weten wat ik moet aanpassen / toevoegen - we corrigeren / voegen alles toe.
Tot slot wil ik een paar woorden zeggen over de vergelijking van OpenStack (zowel de vanilla als de vendor versies) met de cloudoplossing van VMWare - ik heb deze vraag de afgelopen paar jaar te vaak gekregen en eerlijk gezegd ben ik al een beetje moe van dit onderwerp, maar toch. Naar mijn mening is het heel moeilijk om deze twee oplossingen te vergelijken, maar het is zeker te zeggen dat beide oplossingen nadelen hebben, en als je voor Ă©Ă©n oplossing kiest, moet je alles goed afwegen.
Als OpenStack een community-gedreven oplossing is, dan heeft VMWare het recht om alleen te doen wat zij willen (lees: wat voor hen voordelig is) en dat is logisch - omdat het een commercieel bedrijf is dat eraan gewend is geld te verdienen met hun klanten. Maar er is Ă©Ă©n groot en vet MAAR - je kunt overstappen van OpenStack, bijvoorbeeld van Nokia, en met relatief kleine moeite overstappen op een oplossing van bijvoorbeeld Juniper (Contrail Cloud), maar overstappen van VMWare zal je waarschijnlijk moeilijk lukken. Voor mij lijken deze twee oplossingen zo - OpenStack (vendor versie) is een eenvoudige kooi waarin je wordt geplaatst, maar je hebt de sleutel en kunt op elk moment naar buiten. VMWare is een gouden kooi, de sleutel van de kooi is in handen van de eigenaar en het zal je erg veel kosten.
Ik moedig geen van beide producten aan; u kiest wat u nodig heeft. Maar als ik de keuze had, zou ik beide oplossingen kiezen: VMWare voor IT-cloud (lichte belasting, gebruiksvriendelijke bediening), OpenStack van een bepaalde leverancier (Nokia en Juniper bieden behoorlijke turn-key oplossingen) voor de telecom-cloud. Ik zou OpenStack niet gebruiken voor puur IT â dat is als schieten met een kanon op een mus; echter zie ik geen andere contra-indicaties om het te gebruiken, behalve overbodigheid. Het gebruik van VMWare in de telecom lijkt op het vervoeren van grind met een Ford Raptor â het ziet er mooi uit, maar de bestuurder moet 10 ritten maken in plaats van Ă©Ă©n.
Naar mijn mening is het grootste nadeel van VMWare de volledige geslotenheid ervan â het bedrijf zal u geen informatie geven over hoe bijvoorbeeld vSAN is opgezet of wat er in de hypervisor-kernel zit â daar is het simpelweg niet winstgevend voor hen. U zult nooit een expert in VMWare worden â zonder ondersteuning van de leverancier bent u gedoemd (ik kom vaak experts tegen in VMWare die vastlopen bij eenvoudige vragen). Voor mij is VMWare als het kopen van een auto met een op slot hangende motorkap â ja, misschien heeft u specialisten die de distributieriem kunnen vervangen, maar alleen degene die u die oplossing heeft verkocht, kan de motorkap openen. Persoonlijk hou ik niet van oplossingen waarin ik niet kan duiken. U zegt misschien dat u het misschien niet nodig heeft om onder de motorkap te duiken. Dat kan kloppen, maar ik kijk naar u als u een grote functie in de cloud moet samenstellen uit 20-30 virtuele machines, 40-50 netwerken, waarvan de helft naar buiten wil en de andere helft SR-IOV-versnelling vraagt; anders hebt u misschien nog een paar van zulke machines nodig â anders houdt de prestaties niet voldoende stand.
Er zijn ook andere opvattingen, dus het is aan u om te beslissen wat u kiest en het belangrijkste â u bent verantwoordelijk voor uw keuze. Dit is slechts mijn mening â iemand die ten minste 4 producten heeft gezien en met zijn handen heeft aangeraakt â Nokia, Juniper, Red Hat en VMWare. Dus ik heb iets om mee te vergelijken.
Bron: habr.com
