Cloud computing dringt steeds dieper door in ons leven en er is waarschijnlijk geen enkele persoon die niet minstens één keer gebruik heeft gemaakt van clouddiensten. Maar wat een cloud precies is en hoe deze werkt, weten maar weinig mensen, zelfs niet op het niveau van een idee. 5G wordt al werkelijkheid en de telecominfrastructuur begint zich te ontwikkelen van pijleroplossingen naar cloudoplossingen, net zoals zij deed toen zij van volledig hardwareoplossingen naar gevirtualiseerde “pijlers” ging.
Vandaag zullen we het hebben over de innerlijke wereld van de cloudinfrastructuur, en in het bijzonder zullen we kijken naar de basisprincipes van het netwerkgedeelte.
Wat is een wolk? Dezelfde virtualisatie - profielweergave?
Meer dan een logische vraag. Nee - dit is geen virtualisatie, hoewel het zonder virtualisatie niet mogelijk zou zijn. Laten we naar twee definities kijken:
Cloud computing (hierna Cloud genoemd) is een model voor het bieden van gebruiksvriendelijke toegang tot gedistribueerde computerbronnen die op aanvraag moeten worden ingezet en gelanceerd met de laagst mogelijke latentie en minimale kosten voor de serviceprovider.
Virtualisatie - dit is de mogelijkheid om één fysieke entiteit (bijvoorbeeld een server) in verschillende virtuele entiteiten te verdelen, waardoor het gebruik van bronnen toeneemt (u had bijvoorbeeld 3 servers geladen met 25-30 procent, na virtualisatie krijgt u 1 server geladen bij 80-90 procent). Uiteraard slokt virtualisatie een deel van de bronnen op - je moet de hypervisor voeden, maar zoals de praktijk heeft geleerd, is het spel de kaars waard. Een ideaal voorbeeld van virtualisatie is VMWare, dat virtuele machines perfect voorbereidt, of bijvoorbeeld KVM, waar ik de voorkeur aan geef, maar dit is een kwestie van smaak.
We gebruiken virtualisatie zonder het te beseffen, en zelfs ijzeren routers maken al gebruik van virtualisatie - in de nieuwste versie van JunOS wordt het besturingssysteem bijvoorbeeld geïnstalleerd als een virtuele machine bovenop een realtime Linux-distributie (Wind River 9). Maar virtualisatie is niet de cloud, maar de cloud kan niet bestaan zonder virtualisatie.
Virtualisatie is een van de bouwstenen waarop de cloud is gebouwd.
Een cloud maken door simpelweg meerdere hypervisors in één L2-domein te verzamelen, een paar yaml-playbooks toe te voegen voor het automatisch registreren van vlans via een soort Ansible en er zoiets als een orkestratiesysteem bovenop te plaatsen voor het automatisch maken van virtuele machines zal niet werken. Het zal nauwkeuriger zijn, maar de resulterende Frankenstein is niet de wolk die we nodig hebben, hoewel het voor anderen misschien wel de ultieme droom is. Bovendien, als je dezelfde Openstack neemt, is het in wezen nog steeds Frankenstein, maar ach, laten we daar voorlopig niet over praten.
Maar ik begrijp dat het uit de hierboven gepresenteerde definitie niet helemaal duidelijk is wat eigenlijk een wolk kan worden genoemd.
Daarom geeft een document van NIST (National Institute of Standards and Technology) 5 hoofdkenmerken die een cloudinfrastructuur zou moeten hebben:
Het verlenen van service op aanvraag. De gebruiker moet vrije toegang krijgen tot de computerbronnen die hem zijn toegewezen (zoals netwerken, virtuele schijven, geheugen, processorkernen, enz.), en deze bronnen moeten automatisch ter beschikking worden gesteld, dat wil zeggen zonder tussenkomst van de serviceprovider.
Brede beschikbaarheid van service. Toegang tot bronnen moet worden geboden via standaardmechanismen om het gebruik van zowel standaard-pc's als thin clients en mobiele apparaten mogelijk te maken.
Het combineren van middelen in pools. Middelenpools moeten in staat zijn middelen aan meerdere klanten tegelijkertijd te leveren, waarbij wordt verzekerd dat klanten geïsoleerd zijn en vrij van wederzijdse beïnvloeding en concurrentie om hulpbronnen. Netwerken zijn ook opgenomen in de pools, wat de mogelijkheid aangeeft van het gebruik van overlappende adressering. Pools moeten op verzoek kunnen worden geschaald. Het gebruik van pools maakt het mogelijk om het noodzakelijke niveau van fouttolerantie voor bronnen en abstractie van fysieke en virtuele bronnen te bieden - de ontvanger van de dienst krijgt eenvoudigweg de set bronnen die hij heeft aangevraagd (waar deze bronnen zich fysiek bevinden, op hoeveel servers en switches - het maakt voor de client niet uit). We moeten er echter rekening mee houden dat de aanbieder moet zorgen voor een transparante reservering van deze middelen.
Snelle aanpassing aan verschillende omstandigheden. Diensten moeten flexibel zijn: snelle levering van bronnen, herverdeling ervan, het toevoegen of verminderen van bronnen op verzoek van de klant, en van de kant van de klant moet er een gevoel zijn dat de cloudbronnen eindeloos zijn. Voor het gemak zie je bijvoorbeeld geen waarschuwing dat een deel van je schijfruimte in Apple iCloud is verdwenen omdat de harde schijf op de server kapot is gegaan, en schijven gaan kapot. Bovendien zijn de mogelijkheden van deze dienst van uw kant vrijwel onbeperkt - u heeft 2 TB nodig - geen probleem, u heeft betaald en ontvangen. Een soortgelijk voorbeeld kan worden gegeven met Google.Drive of Yandex.Disk.
Mogelijkheid om de geleverde dienst te meten. Cloudsystemen moeten de verbruikte bronnen automatisch controleren en optimaliseren, en deze mechanismen moeten transparant zijn voor zowel de gebruiker als de serviceprovider. Dat wil zeggen dat u altijd kunt controleren hoeveel bronnen u en uw klanten verbruiken.
Het is de moeite waard om te overwegen dat deze vereisten meestal vereisten zijn voor een publieke cloud, dus voor een private cloud (dat wil zeggen een cloud die gelanceerd wordt voor de interne behoeften van het bedrijf) kunnen deze vereisten enigszins worden aangepast. Ze moeten echter nog steeds worden uitgevoerd, anders profiteren we niet van alle voordelen van cloud computing.
Waarom hebben we een wolk nodig?
Elke nieuwe of bestaande technologie, elk nieuw protocol, wordt echter ergens voor gemaakt (nou ja, behalve RIP-ng natuurlijk). Niemand heeft een protocol nodig omwille van een protocol (nou ja, behalve RIP-ng natuurlijk). Het is logisch dat de Cloud is gemaakt om een soort service aan de gebruiker/klant te bieden. We kennen allemaal minstens een paar cloudservices, bijvoorbeeld Dropbox of Google.Docs, en ik denk dat de meeste mensen ze met succes gebruiken - dit artikel is bijvoorbeeld geschreven met behulp van de Google.Docs-cloudservice. Maar de cloudservices die we kennen vormen slechts een deel van de mogelijkheden van de cloud. Om precies te zijn: ze zijn slechts een SaaS-achtige service. Een clouddienst kunnen wij op drie manieren leveren: in de vorm van SaaS, PaaS of IaaS. Welke service u nodig heeft, hangt af van uw wensen en mogelijkheden.
Laten we ze allemaal in volgorde bekijken:
Software als een dienst (SaaS) is een model voor het leveren van een volwaardige service aan de klant, bijvoorbeeld een e-mailservice zoals Yandex.Mail of Gmail. In dit dienstverleningsmodel doet u als klant eigenlijk niets anders dan de diensten gebruiken. U hoeft dus niet na te denken over het opzetten van de dienst, de fouttolerantie of redundantie ervan. Het belangrijkste is dat u uw wachtwoord niet compromitteert; de aanbieder van deze dienst doet de rest voor u. Vanuit het oogpunt van de serviceprovider is hij volledig verantwoordelijk voor de gehele service - van serverhardware en hostbesturingssystemen tot database- en software-instellingen.
Platform as a Service (PaaS) — bij gebruik van dit model levert de dienstverlener de klant een werkstuk voor de dienst, laten we bijvoorbeeld een webserver nemen. De serviceprovider voorzag de klant van een virtuele server (in feite een reeks bronnen, zoals RAM/CPU/opslag/netten, enz.) en installeerde zelfs het besturingssysteem en de benodigde software op deze server, maar de configuratie van al deze zaken worden door de klant zelf gedaan en voor de uitvoering van de dienst antwoordt de klant. De serviceprovider is, net als in het vorige geval, verantwoordelijk voor de prestaties van fysieke apparatuur, hypervisors, de virtuele machine zelf, de netwerkbeschikbaarheid ervan, enz., Maar de service zelf valt niet langer onder zijn verantwoordelijkheidsgebied.
Infrastructuur als een service (IaaS) - deze aanpak is al interessanter, sterker nog, de serviceprovider biedt de klant een complete gevirtualiseerde infrastructuur - dat wil zeggen een reeks (pool) bronnen, zoals CPU-kernen, RAM, netwerken, enz. Al het andere is aan de klant – wat de klant met deze middelen wil doen binnen de toegewezen pool (quota) – is voor de leverancier niet bijzonder belangrijk. Of de klant nu zijn eigen vEPC wil creëren of zelfs een mini-operator wil creëren en communicatiediensten wil leveren - geen twijfel mogelijk - doe het. In een dergelijk scenario is de serviceprovider verantwoordelijk voor het leveren van bronnen, hun fouttolerantie en beschikbaarheid, evenals voor het besturingssysteem waarmee ze deze bronnen kunnen bundelen en beschikbaar kunnen maken voor de klant, met de mogelijkheid om de bronnen op elk moment te vergroten of verkleinen. op verzoek van de opdrachtgever. De klant configureert zelf alle virtuele machines en andere klatergoud via het selfserviceportaal en de console, inclusief het opzetten van netwerken (behalve externe netwerken).
Wat is OpenStack?
Bij alle drie de opties heeft de serviceprovider een besturingssysteem nodig dat de creatie van een cloudinfrastructuur mogelijk maakt. In feite is bij SaaS meer dan één divisie verantwoordelijk voor de hele stapel technologieën - er is een divisie die verantwoordelijk is voor de infrastructuur - dat wil zeggen: het levert IaaS aan een andere divisie, deze divisie levert SaaS aan de klant. OpenStack is een van de cloudbesturingssystemen waarmee u een aantal switches, servers en opslagsystemen kunt verzamelen in één enkele resourcepool, deze gemeenschappelijke pool kunt opsplitsen in subpools (tenants) en deze resources via het netwerk aan klanten kunt leveren.
OpenStack is een cloudbesturingssysteem waarmee u grote hoeveelheden computerbronnen, gegevensopslag en netwerkbronnen kunt beheren, ingericht en beheerd via een API met behulp van standaard authenticatiemechanismen.
Met andere woorden, dit is een reeks gratis softwareprojecten die zijn ontworpen om clouddiensten te creëren (zowel publiek als privé) - dat wil zeggen een reeks tools waarmee u server- en schakelapparatuur kunt combineren in één enkele pool van bronnen, deze middelen, waardoor het noodzakelijke niveau van fouttolerantie wordt geboden.
Op het moment dat dit materiaal werd geschreven, ziet de OpenStack-structuur er als volgt uit:
Foto genomen van
Elk van de componenten in OpenStack vervult een specifieke functie. Met deze gedistribueerde architectuur kunt u de set functionele componenten die u nodig heeft in de oplossing opnemen. Sommige componenten zijn echter hoofdcomponenten en de verwijdering ervan zal leiden tot volledige of gedeeltelijke inoperabiliteit van de oplossing als geheel. Deze componenten worden meestal geclassificeerd als:
- Overzicht — Webgebaseerde GUI voor het beheren van OpenStack-services
- Sluitsteen is een gecentraliseerde identiteitsservice die authenticatie- en autorisatiefunctionaliteit biedt voor andere services, evenals het beheer van gebruikersreferenties en hun rollen.
- Neutron - een netwerkdienst die connectiviteit biedt tussen de interfaces van verschillende OpenStack-services (inclusief connectiviteit tussen VM's en hun toegang tot de buitenwereld)
- Sintel — biedt toegang tot blokopslag voor virtuele machines
- Nova — levenscyclusbeheer van virtuele machines
- oogopslag — opslagplaats van afbeeldingen en snapshots van virtuele machines
- Swift — biedt toegang tot het opslagobject
- Plafondmeter — een dienst die de mogelijkheid biedt om telemetrie te verzamelen en de beschikbare en verbruikte bronnen te meten
- Warmte — orkestratie op basis van sjablonen voor het automatisch creëren en ter beschikking stellen van bronnen
Een volledige lijst van alle projecten en hun doel kan worden bekeken .
Elke OpenStack-component is een service die een specifieke functie vervult en een API biedt om die functie te beheren en te communiceren met andere cloudbesturingssysteemservices om een uniforme infrastructuur te creëren. Nova biedt bijvoorbeeld het beheer van computerbronnen en een API voor toegang tot het configureren van deze bronnen, Glance biedt beeldbeheer en een API om deze te beheren, Cinder biedt blokopslag en een API om deze te beheren, enz. Alle functies zijn zeer nauw met elkaar verbonden.
Als je er echter naar kijkt, zijn alle services die in OpenStack draaien uiteindelijk een soort virtuele machine (of container) die met het netwerk is verbonden. De vraag rijst: waarom hebben we zoveel elementen nodig?
Laten we het algoritme doornemen voor het maken van een virtuele machine en deze verbinden met het netwerk en de permanente opslag in Openstack.
- Wanneer u een verzoek aanmaakt om een machine te maken, of het nu een verzoek is via Horizon (Dashboard) of een verzoek via de CLI, is het eerste dat gebeurt de autorisatie van uw verzoek op Keystone. Kunt u een machine maken, heeft deze de recht om dit netwerk te gebruiken, is uw conceptquotum, enz.
- Keystone verifieert uw verzoek en genereert een authentificatietoken in het antwoordbericht, dat verder zal worden gebruikt. Nadat we een reactie van Keystone hebben ontvangen, wordt het verzoek naar Nova (nova api) gestuurd.
- Nova-api controleert de geldigheid van uw verzoek door contact op te nemen met Keystone met behulp van het eerder gegenereerde auth-token
- Keystone voert authenticatie uit en geeft informatie over machtigingen en beperkingen op basis van dit authenticatietoken.
- Nova-api maakt een vermelding voor de nieuwe VM in nova-database en geeft het verzoek om de machine te maken door aan nova-scheduler.
- Nova-scheduler selecteert de host (computernode) waarop de VM wordt ingezet op basis van de opgegeven parameters, gewichten en zones. Een record hiervan en de VM-ID worden naar de nova-database geschreven.
- Vervolgens neemt nova-scheduler contact op met nova-compute met een verzoek om een exemplaar te implementeren. Nova-compute neemt contact op met nova-conductor om informatie te verkrijgen over machineparameters (nova-conductor is een nova-element dat fungeert als proxyserver tussen nova-database en nova-compute, waardoor het aantal verzoeken aan nova-database wordt beperkt om problemen met de database te voorkomen vermindering van consistentiebelasting).
- Nova-conductor ontvangt de gevraagde informatie uit de nova-database en geeft deze door aan nova-compute.
- Vervolgens kijken nova-compute-aanroepen om de afbeeldings-ID te verkrijgen. Glace valideert het verzoek in Keystone en retourneert de gevraagde informatie.
- Nova-compute neemt contact op met neutronen om informatie te verkrijgen over netwerkparameters. Net als bij blik valideert neutron het verzoek in Keystone, waarna het een vermelding in de database creëert (poortidentificatie, enz.), een verzoek creëert om een poort te creëren en de gevraagde informatie terugstuurt naar nova-compute.
- Nova-compute neemt contact op met cinder met het verzoek een volume aan de virtuele machine toe te wijzen. Net als bij blik valideert cider het verzoek in Keystone, creëert een verzoek voor het maken van een volume en retourneert de gevraagde informatie.
- Nova-compute neemt contact op met libvirt met een verzoek om een virtuele machine met de opgegeven parameters te implementeren.
In feite verandert een ogenschijnlijk eenvoudige handeling van het creëren van een eenvoudige virtuele machine in zo’n draaikolk van API-aanroepen tussen elementen van het cloudplatform. Bovendien bestaan, zoals je ziet, zelfs de eerder aangewezen diensten ook uit kleinere componenten waartussen interactie plaatsvindt. Het creëren van een machine is slechts een klein deel van wat het cloudplatform u mogelijk maakt - er is een dienst die verantwoordelijk is voor het balanceren van het verkeer, een dienst die verantwoordelijk is voor blokopslag, een dienst die verantwoordelijk is voor DNS, een dienst die verantwoordelijk is voor het inrichten van bare metal-servers, enz. Dankzij de cloud kunt u uw virtuele machines behandelen als een kudde schapen (in tegenstelling tot virtualisatie). Als er iets met uw machine gebeurt in een virtuele omgeving - u herstelt deze vanuit back-ups enz., maar cloudapplicaties zijn zo gebouwd dat de virtuele machine niet zo'n belangrijke rol speelt - de virtuele machine "stierf" - geen probleem - er is zojuist een nieuwe gemaakt, het voertuig is gebaseerd op de sjabloon en, zoals ze zeggen, heeft de ploeg het verlies van de jager niet opgemerkt. Uiteraard zorgt dit voor de aanwezigheid van orkestratiemechanismen - met behulp van Heat-sjablonen kunt u eenvoudig een complexe functie implementeren die bestaat uit tientallen netwerken en virtuele machines.
Het is altijd de moeite waard om in gedachten te houden dat er geen cloudinfrastructuur bestaat zonder een netwerk: elk element staat op de een of andere manier via het netwerk in wisselwerking met andere elementen. Bovendien beschikt de cloud over een absoluut niet-statisch netwerk. Uiteraard is het onderliggende netwerk nog min of meer statisch: er worden niet elke dag nieuwe knooppunten en schakelaars toegevoegd, maar de overlay-component kan en zal onvermijdelijk voortdurend veranderen – nieuwe netwerken zullen worden toegevoegd of verwijderd, nieuwe virtuele machines zullen verschijnen en oude zullen verschijnen. dood gaan. En zoals u zich herinnert uit de definitie van de cloud die helemaal aan het begin van het artikel wordt gegeven, moeten bronnen automatisch aan de gebruiker worden toegewezen en met de minste (of beter nog, zonder) tussenkomst van de serviceprovider. Dat wil zeggen, het type terbeschikkingstelling van netwerkbronnen dat nu bestaat in de vorm van een front-end in de vorm van uw persoonlijke account toegankelijk via http/https en de dienstdoende netwerkingenieur Vasily als backend is zelfs geen cloud. als Vasily acht handen heeft.
Neutron biedt als netwerkdienst een API voor het beheer van het netwerkgedeelte van de cloudinfrastructuur. De service drijft en beheert het netwerkgedeelte van Openstack aan door een abstractielaag aan te bieden genaamd Network-as-a-Service (NaaS). Dat wil zeggen dat het netwerk dezelfde virtueel meetbare eenheid is als bijvoorbeeld virtuele CPU-kernen of de hoeveelheid RAM.
Maar voordat we verder gaan met de architectuur van het netwerkgedeelte van OpenStack, laten we eens kijken hoe dit netwerk werkt in OpenStack en waarom het netwerk een belangrijk en integraal onderdeel van de cloud is.
We hebben dus twee RODE client-VM's en twee GROENE client-VM's. Laten we aannemen dat deze machines zich op deze manier op twee hypervisors bevinden:
Op dit moment is dit slechts de virtualisatie van 4 servers en niets meer, aangezien we tot nu toe alleen maar 4 servers hebben gevirtualiseerd en deze op twee fysieke servers hebben geplaatst. En tot nu toe zijn ze niet eens verbonden met het netwerk.
Om een wolk te maken, moeten we verschillende componenten toevoegen. Eerst virtualiseren we het netwerkgedeelte - we moeten deze 4 machines in paren verbinden, en de clients willen een L2-verbinding. Je kunt een switch gebruiken en een trunk in die richting configureren en alles oplossen met een Linux-bridge of, voor meer gevorderde gebruikers, openvswitch (we komen hier later op terug). Maar er kunnen veel netwerken zijn, en L2 voortdurend door een schakelaar duwen is niet het beste idee - er zijn verschillende afdelingen, een servicedesk, maanden wachten op de voltooiing van een applicatie, wekenlang probleemoplossing - in de moderne wereld is dit aanpak werkt niet meer. En hoe eerder een bedrijf dit begrijpt, hoe gemakkelijker het is om verder te komen. Daarom zullen we tussen de hypervisors een L3-netwerk selecteren waarmee onze virtuele machines zullen communiceren, en bovenop dit L3-netwerk zullen we virtuele L2-overlay-netwerken bouwen waar het verkeer van onze virtuele machines zal verlopen. U kunt GRE, Geneve of VxLAN als inkapseling gebruiken. Laten we ons nu op dat laatste concentreren, ook al is dat niet bijzonder belangrijk.
We moeten VTEP ergens lokaliseren (ik hoop dat iedereen bekend is met de VxLAN-terminologie). Omdat we een L3-netwerk hebben dat rechtstreeks van de servers komt, weerhoudt niets ons ervan om VTEP op de servers zelf te plaatsen, en OVS (OpenvSwitch) is hier uitstekend in. Als resultaat kregen we dit ontwerp:
Omdat het verkeer tussen VM's moet worden verdeeld, zullen de poorten naar de virtuele machines verschillende vlan-nummers hebben. Het tagnummer speelt slechts een rol binnen één virtuele switch, omdat we het, wanneer ingekapseld in VxLAN, gemakkelijk kunnen verwijderen, omdat we dan een VNI hebben.
Nu kunnen we zonder problemen onze machines en virtuele netwerken voor hen creëren.
Maar wat als de client een andere machine heeft, maar zich op een ander netwerk bevindt? We hebben worteling tussen netwerken nodig. We zullen kijken naar een eenvoudige optie wanneer gecentraliseerde routering wordt gebruikt - dat wil zeggen dat verkeer wordt gerouteerd via speciale speciale netwerkknooppunten (nou ja, in de regel worden ze gecombineerd met controleknooppunten, dus we zullen hetzelfde hebben).
Het lijkt niets ingewikkelds: we maken een bridge-interface op het besturingsknooppunt, leiden het verkeer ernaartoe en van daaruit leiden we het naar de plek waar we het nodig hebben. Maar het probleem is dat de RED-client het 10.0.0.0/24-netwerk wil gebruiken, en de GREEN-client het 10.0.0.0/24-netwerk wil gebruiken. Dat wil zeggen, we beginnen adresruimten te kruisen. Bovendien willen klanten niet dat andere klanten toegang kunnen krijgen tot hun interne netwerken, wat logisch is. Om de netwerken en het klantdataverkeer te scheiden, zullen we voor elk netwerk een aparte naamruimte toewijzen. Naamruimte is in feite een kopie van de Linux-netwerkstack, dat wil zeggen dat clients in naamruimte RED volledig geïsoleerd zijn van clients uit naamruimte GREEN (nou ja, routering tussen deze clientnetwerken is toegestaan via de standaardnaamruimte of op stroomopwaartse transportapparatuur).
Dat wil zeggen, we krijgen het volgende diagram:
L2-tunnels convergeren van alle computerknooppunten naar het besturingsknooppunt. knooppunt waar de L3-interface voor deze netwerken zich bevindt, elk in een speciale naamruimte voor isolatie.
Wij zijn echter het allerbelangrijkste vergeten. De virtuele machine moet een dienst aan de klant leveren, dat wil zeggen dat hij minimaal één externe interface moet hebben waarmee hij kan worden bereikt. Dat wil zeggen, we moeten naar de buitenwereld gaan. Er zijn verschillende opties hier. Laten we de eenvoudigste optie doen. We voegen aan elke client één netwerk toe, dat geldig is in het netwerk van de provider en niet overlapt met andere netwerken. De netwerken kunnen elkaar ook kruisen en naar verschillende VRF's aan de kant van het providernetwerk kijken. De netwerkgegevens bevinden zich ook in de naamruimte van elke client. Ze zullen echter nog steeds naar de buitenwereld gaan via één fysieke (of binding, wat logischer) interface. Om het clientverkeer te scheiden, wordt verkeer dat naar buiten gaat, getagd met een VLAN-tag die aan de client is toegewezen.
Als resultaat kregen we dit diagram:
Een redelijke vraag is: waarom maken we geen gateways op de rekenknooppunten zelf? Dit is geen groot probleem; bovendien zal dit werken als u de gedistribueerde router (DVR) inschakelt. In dit scenario overwegen we de eenvoudigste optie met een gecentraliseerde gateway, die standaard wordt gebruikt in Openstack. Voor functies met hoge belasting zullen ze zowel een gedistribueerde router als versnellingstechnologieën zoals SR-IOV en Passthrough gebruiken, maar zoals ze zeggen: dat is een heel ander verhaal. Laten we eerst het basisgedeelte behandelen, en dan zullen we ingaan op de details.
Eigenlijk is ons schema al werkbaar, maar er zijn een paar nuances:
- We moeten onze machines op de een of andere manier beschermen, dat wil zeggen, een filter op de switchinterface richting de client plaatsen.
- Maak het mogelijk dat een virtuele machine automatisch een IP-adres krijgt, zodat je niet telkens via de console hoeft in te loggen en het adres te registreren.
Laten we beginnen met machinebescherming. Hiervoor kun je banale iptables gebruiken, waarom niet.
Dat wil zeggen, nu is onze topologie een beetje ingewikkelder geworden:
Laten we verder gaan. We moeten een DHCP-server toevoegen. De meest ideale plaats om DHCP-servers voor elke client te lokaliseren is het hierboven genoemde controleknooppunt, waar de naamruimten 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 de machines nieuwe adressen krijgen, wat niet erg handig is. Er zijn hier twee manieren om hier uit te komen - gebruik ofwel domeinnamen en voeg een DNS-server toe voor elke client, dan zal het adres niet bijzonder belangrijk voor ons zijn (vergelijkbaar met het netwerkgedeelte in k8s) - maar er is een probleem met externe netwerken, aangezien adressen kunnen er ook via DHCP in worden uitgegeven - je hebt synchronisatie nodig met DNS-servers in het cloudplatform en een externe DNS-server, wat naar mijn mening niet erg flexibel is, maar wel goed mogelijk is. Of de tweede optie is het gebruik van metagegevens, dat wil zeggen het opslaan van informatie over het adres dat aan de machine is verstrekt, zodat de DHCP-server weet welk adres aan de machine moet worden verstrekt als de machine al een adres heeft ontvangen. De tweede optie is eenvoudiger en flexibeler, omdat u hiermee extra informatie over de auto kunt opslaan. Laten we nu metagegevens van de agent aan het diagram toevoegen:
Een ander probleem dat ook de moeite waard is om te bespreken is de mogelijkheid om door alle clients één extern netwerk te gebruiken, aangezien externe netwerken, als ze geldig moeten zijn in het hele netwerk, moeilijk zullen zijn - je moet de toewijzing van deze netwerken voortdurend toewijzen en controleren. De mogelijkheid om één extern, vooraf geconfigureerd netwerk voor alle klanten te gebruiken, zal zeer nuttig zijn bij het creëren van een publieke cloud. Dit maakt het eenvoudiger om machines in te zetten, omdat we niet een adresdatabase hoeven te raadplegen en een unieke adresruimte hoeven te selecteren voor het externe netwerk van elke klant. Bovendien kunnen we vooraf een extern netwerk registreren en hoeven we op het moment van implementatie alleen externe adressen aan clientmachines te koppelen.
En hier komt NAT ons te hulp: we maken het alleen mogelijk voor klanten om toegang te krijgen tot de buitenwereld via de standaardnaamruimte met behulp van NAT-vertaling. Nou, hier is een klein probleem. Dit is goed als de clientserver als client fungeert en niet als server; dat wil zeggen dat hij verbindingen initieert in plaats van accepteert. Maar bij ons zal het andersom zijn. In dit geval moeten we bestemmings-NAT uitvoeren, zodat het besturingsknooppunt bij het ontvangen van verkeer begrijpt dat dit verkeer bedoeld is voor virtuele machine A van client A, wat betekent dat we een NAT-vertaling moeten uitvoeren vanaf een extern adres, bijvoorbeeld 100.1.1.1 .10.0.0.1, naar een intern adres 100. In dit geval blijft de interne isolatie volledig behouden, ook al gebruiken alle clients hetzelfde netwerk. Dat wil zeggen dat we dNAT en sNAT op het besturingsknooppunt moeten uitvoeren. Of u één enkel netwerk met zwevende adressen of externe netwerken of beide tegelijk gebruikt, hangt af van wat u in de cloud wilt brengen. We voegen geen zwevende adressen toe aan het diagram, maar laten de externe netwerken die al eerder zijn toegevoegd, staan - elke client heeft zijn eigen externe netwerk (in het diagram worden ze op de externe interface aangegeven als vlan 200 en XNUMX).
Als resultaat kregen we een interessante en tegelijkertijd goed doordachte oplossing, die een zekere flexibiliteit heeft maar nog geen fouttolerantiemechanismen heeft.
Ten eerste hebben we maar één controleknooppunt: het falen ervan zal leiden tot de ineenstorting van alle systemen. Om dit probleem op te lossen, moet u minimaal een quorum van 3 knooppunten maken. Laten we dit aan het diagram toevoegen:
Uiteraard worden alle knooppunten gesynchroniseerd en wanneer een actief knooppunt vertrekt, neemt een ander knooppunt zijn verantwoordelijkheden over.
Het volgende probleem zijn virtuele machineschijven. Op dit moment worden ze opgeslagen op de hypervisors zelf, en in geval van problemen met de hypervisor verliezen we alle gegevens - en de aanwezigheid van een raid zal hier niet helpen als we niet de schijf verliezen, maar de hele server. Om dit te doen, moeten we een service maken die als front-end voor een soort opslag zal fungeren. Wat voor soort opslag het zal zijn, is voor ons niet bijzonder belangrijk, maar het zou onze gegevens moeten beschermen tegen uitval van zowel de schijf als het knooppunt, en mogelijk de hele kast. Er zijn hier verschillende opties - er zijn natuurlijk SAN-netwerken met Fibre Channel, maar laten we eerlijk zijn - FC is al een overblijfsel uit het verleden - een analoog van E1 in transport - ja, ik ben het ermee eens, het wordt nog steeds gebruikt, maar alleen waar het absoluut onmogelijk is zonder. Daarom zou ik in 2020 niet vrijwillig een FC-netwerk inzetten, wetende dat er andere, interessantere alternatieven zijn. Hoewel het ieder zijn ding is, zijn er misschien mensen die geloven dat FC met al zijn beperkingen alles is wat we nodig hebben - daar zal ik niet tegenin gaan, iedereen heeft zijn eigen mening. De meest interessante oplossing is naar mijn mening echter het gebruik van een SDS, zoals Ceph.
Met Ceph kunt u een zeer beschikbare oplossing voor gegevensopslag bouwen met een aantal mogelijke back-upopties, beginnend met codes met pariteitscontrole (analoog aan raid 5 of 6), eindigend met volledige gegevensreplicatie naar verschillende schijven, rekening houdend met de locatie van schijven in servers en servers in kasten, enz.
Om Ceph te bouwen heb je nog 3 knooppunten nodig. Interactie met de opslag zal ook plaatsvinden via het netwerk met behulp van blok-, object- en bestandsopslagdiensten. Laten we opslag aan het schema toevoegen:
Opmerking: u kunt ook hypergeconvergeerde rekenknooppunten maken - dit is het concept van het combineren van verschillende functies op één knooppunt - bijvoorbeeld opslag+rekenkracht - zonder speciale knooppunten toe te wijzen voor ceph-opslag. We krijgen hetzelfde fouttolerante schema, aangezien SDS gegevens reserveert met het reserveringsniveau dat we specificeren. Hypergeconvergeerde knooppunten zijn echter altijd een compromis - aangezien het opslagknooppunt niet alleen de lucht verwarmt zoals het op het eerste gezicht lijkt (aangezien er geen virtuele machines op staan) - besteedt het CPU-bronnen aan het onderhouden van SDS (in feite doet het alles de replicatie en het herstel na storingen van knooppunten, schijven, enz.). Dat wil zeggen dat u een deel van de kracht van het rekenknooppunt verliest als u dit combineert met opslag.
Al deze dingen moeten op de een of andere manier worden beheerd - we hebben iets nodig waarmee we een machine, een netwerk, een virtuele router, enz. kunnen creëren. Om dit te doen, zullen we een service aan het controleknooppunt toevoegen die als dashboard zal fungeren - het De klant kan via http/https verbinding maken met dit portaal en alles doen wat hij nodig heeft (nou ja, bijna).
Als gevolg hiervan hebben we nu een fouttolerant systeem. Alle elementen van deze infrastructuur moeten op de een of andere manier worden beheerd. Eerder werd beschreven dat Openstack een reeks projecten is, die elk een specifieke functie bieden. Zoals we zien, zijn er meer dan genoeg elementen die moeten worden geconfigureerd en gecontroleerd. Vandaag zullen we het hebben over het netwerkgedeelte.
Neutronen architectuur
Bij OpenStack is Neutron verantwoordelijk voor het verbinden van virtuele machinepoorten met een gemeenschappelijk L2-netwerk, waardoor verkeersroutering tussen VM's op verschillende L2-netwerken wordt gegarandeerd, evenals uitgaande routering, waarbij diensten worden geleverd zoals NAT, Floating IP, DHCP, enz.
Op hoog niveau kan de werking van de netwerkdienst (het basisgedeelte) als volgt worden beschreven.
Bij het starten van de VM doet de netwerkservice het volgende:
- Creëert een poort voor een bepaalde VM (of poorten) en informeert de DHCP-service hierover;
- Er wordt een nieuw virtueel netwerkapparaat aangemaakt (via libvirt);
- De VM maakt verbinding met de poort(en) die in stap 1 is gemaakt;
Vreemd genoeg is het werk van Neutron gebaseerd op standaardmechanismen die bekend zijn bij iedereen die zich ooit in Linux heeft verdiept: naamruimten, iptables, linux bridges, openvswitch, conntrack, enz.
Er moet onmiddellijk worden verduidelijkt dat Neutron geen SDN-controller is.
Neutron bestaat uit verschillende onderling verbonden componenten:
Openstack-neutronenserver is een daemon die werkt met gebruikersverzoeken via de API. Deze demon is niet betrokken bij het registreren van eventuele netwerkverbindingen, maar verstrekt hiervoor de benodigde informatie aan zijn plugins, die vervolgens het gewenste netwerkelement configureren. Neutronenagenten op OpenStack-nodes registreren zich bij de Neutron-server.
Neutron-server is eigenlijk een applicatie geschreven in Python, bestaande uit twee delen:
- REST-service
- Neutron Plugin (kern/service)
De REST-service is ontworpen om API-aanroepen van andere componenten te ontvangen (bijvoorbeeld een verzoek om bepaalde informatie te verstrekken, enz.)
Plug-ins zijn plug-in softwarecomponenten/modules die worden aangeroepen tijdens API-verzoeken - dat wil zeggen dat de toewijzing van een dienst via hen plaatsvindt. Plug-ins zijn onderverdeeld in twee typen: service en root. In de regel is de horse-plug-in vooral verantwoordelijk voor het beheer van de adresruimte en L2-verbindingen tussen VM's, en service-plug-ins bieden al extra functionaliteit zoals VPN of FW.
De lijst met plug-ins die vandaag beschikbaar zijn, kan bijvoorbeeld worden bekeken
Er kunnen meerdere serviceplug-ins zijn, maar er kan slechts één paardenplug-in zijn.
openstack-neutron-ml2 is de standaard OpenStack root-plug-in. Deze plug-in heeft een modulaire architectuur (in tegenstelling tot zijn voorganger) en configureert de netwerkdienst via daarop aangesloten stuurprogramma's. We zullen iets later naar de plug-in zelf kijken, omdat deze in feite de flexibiliteit biedt die OpenStack heeft op het gebied van het netwerk. De root-plug-in kan worden vervangen (Contrail Networking doet bijvoorbeeld een dergelijke vervanging).
RPC-service (rabbitmq-server) — een service die wachtrijbeheer en interactie met andere OpenStack-services biedt, evenals interactie tussen netwerkserviceagenten.
Netwerkagenten — agenten die zich in elk knooppunt bevinden en waarmee netwerkdiensten worden geconfigureerd.
Er zijn verschillende soorten agenten.
De hoofdagent is L2-agent. Deze agenten draaien op elk van de hypervisors, inclusief controleknooppunten (meer precies, op alle knooppunten die enige service bieden aan tenants) en hun belangrijkste functie is het verbinden van virtuele machines met een gemeenschappelijk L2-netwerk, en ook het genereren van waarschuwingen wanneer er gebeurtenissen plaatsvinden ( bijvoorbeeld de poort uitschakelen/inschakelen).
De volgende, niet minder belangrijke agent is L3-agent. Deze agent draait standaard uitsluitend op een netwerkknooppunt (vaak wordt het netwerkknooppunt gecombineerd met een besturingsknooppunt) en zorgt voor routering tussen huurdernetwerken (zowel tussen zijn netwerken als de netwerken van andere huurders, en is toegankelijk voor de buitenwereld, waardoor NAT, evenals DHCP-service). Wanneer u echter een DVR (gedistribueerde router) gebruikt, verschijnt de behoefte aan een L3-plug-in ook op de rekenknooppunten.
De L3-agent gebruikt Linux-naamruimten om elke tenant te voorzien van een reeks eigen geïsoleerde netwerken en de functionaliteit van virtuele routers die verkeer routeren en gatewayservices bieden voor Layer 2-netwerken.
Database — een database met identificatiegegevens van netwerken, subnetten, poorten, pools, enz.
In feite accepteert Neutron API-verzoeken vanaf de creatie van netwerkentiteiten, authenticeert het verzoek en verzendt via RPC (als het toegang heeft tot een plug-in of agent) of REST API (als het communiceert in SDN) naar de agenten (via plug-ins) de instructies die nodig zijn om de gevraagde dienst te organiseren.
Laten we nu eens kijken naar de testinstallatie (hoe deze wordt ingezet en wat erin zit, we zullen later in het praktische gedeelte zien) en zien waar elke component zich bevindt:
(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 ~]$
Eigenlijk is dat de hele structuur van Neutron. Nu is het de moeite waard om wat tijd aan de ML2-plug-in te besteden.
Modulaire laag 2
Zoals hierboven vermeld, is de plug-in een standaard OpenStack-rootplug-in en heeft een modulaire architectuur.
De voorganger van de ML2-plug-in had een monolithische structuur, waardoor het bijvoorbeeld niet mogelijk was om een mix van verschillende technologieën in één installatie te gebruiken. U kunt bijvoorbeeld niet zowel openvswitch als linuxbridge tegelijkertijd gebruiken, noch de eerste, noch de tweede. Om deze reden is de ML2-plug-in met zijn architectuur gemaakt.
ML2 bestaat uit twee componenten: twee typen stuurprogramma's: typestuurprogramma's en mechanismestuurprogramma's.
Typ stuurprogramma's bepaal de technologieën die zullen worden gebruikt om netwerkverbindingen te organiseren, bijvoorbeeld VxLAN, VLAN, GRE. Tegelijkertijd maakt de bestuurder het gebruik van verschillende technologieën mogelijk. De standaardtechnologie is VxLAN-inkapseling voor overlay-netwerken en externe vlan-netwerken.
Typestuurprogramma's omvatten de volgende netwerktypen:
Flat - netwerk zonder tagging
VLAN - getagd netwerk
Lokale — een speciaal type netwerk voor alles-in-één-installaties (dergelijke installaties zijn nodig voor ontwikkelaars of voor training)
GRE — overlay-netwerk met behulp van GRE-tunnels
VxLAN — overlay-netwerk met behulp van VxLAN-tunnels
Mechanisme bestuurders tools definiëren die de organisatie garanderen van de technologieën die zijn gespecificeerd in het type driver - bijvoorbeeld openvswitch, sr-iov, opendaylight, OVN, enz.
Afhankelijk van de implementatie van dit stuurprogramma zullen er agenten worden gebruikt die worden bestuurd door Neutron, of zullen er verbindingen met een externe SDN-controller worden gebruikt, die zorgt voor alle problemen met betrekking tot het organiseren van L2-netwerken, routering, enz.
Voorbeeld: als we ML2 samen met OVS gebruiken, dan wordt op elk computerknooppunt dat OVS beheert een L2-agent geïnstalleerd. Als we echter bijvoorbeeld OVN of OpenDayLight gebruiken, valt de besturing van OVS onder hun jurisdictie: Neutron geeft via de root-plug-in opdrachten aan de controller en deze doet al wat hem is opgedragen.
Laten we Open vSwitch eens opfrissen
Op dit moment is Open vSwitch een van de belangrijkste componenten van OpenStack.
Wanneer u OpenStack installeert zonder een extra SDN van een leverancier, zoals Juniper Contrail of Nokia Nuage, is OVS de belangrijkste netwerkcomponent van het cloudnetwerk en kunt u, samen met iptables, conntrack en naamruimten, volwaardige multi-tenancy overlay-netwerken organiseren. Uiteraard kan dit onderdeel bijvoorbeeld worden vervangen bij gebruik van eigen SDN-oplossingen van derden.
OVS is een open source softwareswitch die is ontworpen voor gebruik in gevirtualiseerde omgevingen als virtuele verkeersdoorstuurder.
Op dit moment heeft OVS een zeer behoorlijke functionaliteit, waaronder technologieën zoals QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, enz.
Let op: OVS was in eerste instantie niet bedoeld als soft switch voor zwaarbelaste telecomfuncties en was meer bedoeld voor IT-functies die minder bandbreedte vergen, zoals WEB-server of mailserver. OVS wordt echter verder ontwikkeld en de huidige implementaties van OVS hebben de prestaties en mogelijkheden ervan aanzienlijk verbeterd, waardoor het kan worden gebruikt door telecomoperatoren met zwaarbelaste functies. Er is bijvoorbeeld een OVS-implementatie met ondersteuning voor DPDK-versnelling.
Er zijn drie belangrijke componenten van OVS waar u rekening mee moet houden:
- Kernelmodule — een component in de kernelruimte die verkeer verwerkt op basis van de regels ontvangen van het besturingselement;
- vSchakelen daemon (ovs-vswitchd) is een proces dat wordt gelanceerd in de gebruikersruimte en verantwoordelijk is voor het programmeren van de kernelmodule - dat wil zeggen dat het rechtstreeks de logica van de werking van de switch vertegenwoordigt
- Database server - een lokale database op elke host waarop OVS draait, waarin de configuratie wordt opgeslagen. SDN-controllers kunnen via deze module communiceren met behulp van het OVSDB-protocol.
Dit alles gaat gepaard met een reeks diagnostische en beheerhulpprogramma's, zoals ovs-vsctl, ovs-appctl, ovs-ofctl, enz.
Momenteel wordt Openstack veel gebruikt door telecomoperatoren om netwerkfuncties ernaar te migreren, zoals EPC, SBC, HLR, enz. Sommige functies kunnen zonder problemen met OVS functioneren, maar EPC verwerkt bijvoorbeeld abonneeverkeer - en gaat vervolgens door een enorme hoeveelheid verkeer (nu bereiken de verkeersvolumes enkele honderden gigabits per seconde). Het is uiteraard niet het beste idee om dergelijk verkeer door de kernelruimte te sturen (aangezien de forwarder zich daar standaard bevindt). Daarom wordt OVS vaak volledig in de gebruikersruimte ingezet met behulp van DPDK-versnellingstechnologie om verkeer van NIC naar gebruikersruimte door te sturen, waarbij de kernel wordt omzeild.
Let op: voor een cloud die wordt ingezet voor telecomfuncties is het mogelijk om verkeer van een rekenknooppunt, waarbij OVS wordt omzeild, rechtstreeks naar schakelapparatuur te sturen. Hiervoor worden SR-IOV- en Passthrough-mechanismen gebruikt.
Hoe werkt dit op een echte lay-out?
Laten we nu verder gaan met het praktische gedeelte en kijken hoe het allemaal in de praktijk werkt.
Laten we eerst een eenvoudige OpenStack-installatie implementeren. Omdat ik geen set servers bij de hand heb voor experimenten, zullen we het prototype vanaf virtuele machines op één fysieke server samenstellen. Ja, zo'n oplossing is natuurlijk niet geschikt voor commerciële doeleinden, maar om een voorbeeld te zien van hoe het netwerk in Openstack werkt, is zo'n installatie voldoende voor de ogen. Bovendien is zo’n installatie nog interessanter voor trainingsdoeleinden – je kunt immers verkeer opvangen etc.
Omdat we alleen het basisgedeelte hoeven te zien, kunnen we niet meerdere netwerken gebruiken, maar alles verhogen met slechts twee netwerken, en het tweede netwerk in deze lay-out zal exclusief worden gebruikt voor toegang tot de undercloud en DNS-server. We zullen voorlopig niet ingaan op externe netwerken - dit is een onderwerp voor een apart groot artikel.
Laten we dus op volgorde beginnen. Eerst een beetje theorie. We zullen Openstack installeren met behulp van TripleO (Openstack op Openstack). De essentie van TripleO is dat we Openstack all-in-one installeren (dus op één node), genaamd undercloud, en vervolgens de mogelijkheden van de ingezette Openstack gebruiken om Openstack te installeren die bedoeld is voor gebruik, genaamd overcloud. Undercloud zal zijn inherente vermogen om fysieke servers (bare metal) te beheren – het Ironic-project – gebruiken om hypervisors te leveren die de rol van reken-, controle- en opslagknooppunten zullen vervullen. Dat wil zeggen dat we geen tools van derden gebruiken om Openstack te implementeren; we implementeren Openstack met behulp van Openstack. Het zal veel duidelijker worden naarmate de installatie vordert, dus we zullen daar niet stoppen en verder gaan.
Opmerking: In dit artikel heb ik omwille van de eenvoud geen netwerkisolatie gebruikt voor interne Openstack-netwerken, maar wordt alles geïmplementeerd via slechts één netwerk. De aan- of afwezigheid van netwerkisolatie heeft echter geen invloed op de basisfunctionaliteit van de oplossing: alles zal precies hetzelfde werken als bij gebruik van isolatie, maar het verkeer zal op hetzelfde netwerk stromen. Voor een commerciële installatie is het uiteraard noodzakelijk om isolatie te gebruiken met behulp van verschillende vlans en interfaces. Ceph-opslagbeheerverkeer en het dataverkeer zelf (machinetoegang tot schijven, enz.) gebruiken bijvoorbeeld, wanneer geïsoleerd, verschillende subnetten (opslagbeheer en opslag) en hierdoor kunt u de oplossing fouttoleranter maken door bijvoorbeeld dit verkeer te verdelen , over verschillende poorten, of door verschillende QoS-profielen te gebruiken voor verschillend verkeer, zodat het dataverkeer het signaalverkeer niet wegdrukt. In ons geval zullen ze op hetzelfde netwerk gaan en in feite beperkt dit ons op geen enkele manier.
Opmerking: aangezien we virtuele machines gaan draaien in een virtuele omgeving op basis van virtuele machines, moeten we eerst geneste virtualisatie inschakelen.
U kunt als volgt controleren of geneste virtualisatie is ingeschakeld of niet:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Als u de letter N ziet, schakelen we ondersteuning voor geneste virtualisatie in volgens bijvoorbeeld elke handleiding die u op het netwerk vindt .
We moeten het volgende circuit samenstellen uit virtuele machines:
In mijn geval heb ik OpenvSwitch gebruikt om de virtuele machines te verbinden die deel uitmaken van de toekomstige installatie (en ik heb er zeven, maar je kunt met vier rondkomen als je niet over veel bronnen beschikt). Ik heb een ovs-bridge gemaakt en er virtuele machines op aangesloten via poortgroepen. Om dit te doen, heb ik een xml-bestand als volgt gemaakt:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Hier worden drie poortgroepen gedeclareerd: twee toegangen en één trunk (de laatste was nodig voor de DNS-server, maar u kunt het zonder doen, of op de hostmachine installeren - afhankelijk van wat u het beste uitkomt). Vervolgens declareren we met behulp van dit sjabloon de onze via virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nu bewerken we de hypervisorpoortconfiguraties:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Let op: in dit scenario zal het adres op poort ovs-br1 niet toegankelijk zijn omdat het geen vlan-tag heeft. Om dit op te lossen, moet je de opdracht sudo ovs-vsctl set port ovs-br1 tag=100 geven. Na een herstart zal deze tag echter verdwijnen (als iemand weet hoe hij op zijn plaats kan blijven staan, zal ik u zeer dankbaar zijn). Maar dit is niet zo belangrijk, omdat we dit adres alleen nodig hebben tijdens de installatie en niet wanneer Openstack volledig is geïmplementeerd.
Vervolgens maken we een undercloud-machine:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Tijdens de installatie stelt u alle benodigde parameters in, zoals de machinenaam, wachtwoorden, gebruikers, ntp-servers, enz., u kunt meteen de poorten configureren, maar voor mij persoonlijk is het na installatie gemakkelijker om in te loggen op de machine via de console en corrigeer de benodigde bestanden. Als je al een kant-en-klare image hebt, kun je deze gebruiken, of doen wat ik deed: download de minimale Centos 7-image en gebruik deze om de VM te installeren.
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 runningInstalleer eerst de tools die nodig zijn voor het installatieproces:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud-installatie
We creëren een stackgebruiker, stellen een wachtwoord in, voegen het toe aan sudoer en geven hem de mogelijkheid om root-opdrachten uit te voeren via sudo zonder een wachtwoord in te voeren:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNu specificeren we de volledige undercloud-naam in het hosts-bestand:
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 repositories toe en installeren we de software die we nodig hebben:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleLet op: als u niet van plan bent ceph te installeren, hoeft u geen ceph-gerelateerde opdrachten in te voeren. Ik heb de Queens-versie gebruikt, maar je kunt elke andere gebruiken die je leuk vindt.
Kopieer vervolgens het undercloud-configuratiebestand naar de thuismapstapel van de gebruiker:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNu moeten we dit bestand corrigeren en aanpassen aan onze installatie.
U moet deze regels aan het begin van het bestand toevoegen:
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 dus de instellingen doornemen:
undercloud_hostnaam — de volledige naam van de undercloud-server moet overeenkomen met de vermelding op de DNS-server
local_ip — lokaal undercloud-adres voor netwerkvoorziening
netwerk_gateway — hetzelfde lokale adres, dat zal fungeren als gateway voor toegang tot de buitenwereld tijdens de installatie van overcloud-nodes, valt ook samen met lokaal ip
undercloud_public_host — extern API-adres, elk vrij adres uit het provisioningnetwerk wordt toegewezen
undercloud_admin_host intern API-adres, wordt elk vrij adres uit het provisioningnetwerk toegewezen
undercloud_nameservers - DNS server
genereren_service_certificaat - deze regel is erg belangrijk in het huidige voorbeeld, want als je deze niet op false instelt, krijg je een foutmelding tijdens de installatie, het probleem wordt beschreven op de Red Hat bugtracker
lokale_interface interface in netwerkvoorziening. Deze interface wordt tijdens de undercloud-implementatie opnieuw geconfigureerd, dus u heeft twee interfaces in de undercloud nodig: één voor toegang, de tweede voor provisioning
lokale_mtu — MTU. Omdat we een testlaboratorium hebben en ik een MTU van 1500 heb op de poorten van de OVS-switch, is het noodzakelijk om deze in te stellen op 1450 zodat pakketten die zijn ingekapseld in VxLAN er doorheen kunnen gaan
netwerk_cidr — bevoorradingsnetwerk
maskerade — NAT gebruiken om toegang te krijgen tot een extern netwerk
maskerade_netwerk - netwerk dat NAT zal zijn
dhcp_start — het startadres van de adrespool van waaruit adressen worden toegewezen aan knooppunten tijdens overcloud-implementatie
dhcp_end — het eindadres van de adrespool waaruit adressen zullen worden toegewezen aan knooppunten tijdens overcloud-implementatie
inspectie_ipbereik — een verzameling adressen die nodig zijn voor introspectie (mag niet overlappen met de bovenstaande verzameling)
planner_max_pogingen — maximaal aantal pogingen om overcloud te installeren (moet groter zijn dan of gelijk zijn aan het aantal knooppunten)
Nadat het bestand is beschreven, kunt u de opdracht geven om undercloud te implementeren:
openstack undercloud install
De procedure duurt 10 tot 30 minuten, afhankelijk van uw strijkijzer. Uiteindelijk zou je de uitvoer als volgt moeten zien:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Deze uitvoer geeft aan dat u undercloud met succes hebt geïnstalleerd en dat u nu de status van undercloud kunt controleren en kunt doorgaan met het installeren van overcloud.
Als je naar de ifconfig-uitvoer kijkt, zul je zien dat er een nieuwe bridge-interface is verschenen
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Overcloud-implementatie zal nu via deze interface worden uitgevoerd.
Uit de onderstaande uitvoer kunt u zien dat we alle services op één knooppunt hebben:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Hieronder vindt u de configuratie van het undercloud-netwerkgedeelte:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Overcloud-installatie
Op dit moment hebben we alleen maar undercloud, en we hebben niet genoeg knooppunten waaruit de overcloud zal worden samengesteld. Laten we daarom eerst de virtuele machines inzetten die we nodig hebben. Tijdens de implementatie zal undercloud zelf het besturingssysteem en de benodigde software op de overcloud-machine installeren - dat wil zeggen dat we de machine niet volledig hoeven in te zetten, maar er alleen een schijf (of schijven) voor moeten maken en de parameters ervan moeten bepalen - dat wil zeggen in feite krijgen we een kale server zonder dat er een besturingssysteem op is geïnstalleerd.
Laten we naar de map met de schijven van onze virtuele machines gaan en schijven van de vereiste grootte maken:
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 160GOmdat we als root opereren, moeten we de eigenaar van deze schijven veranderen om geen problemen met de rechten te krijgen:
[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 u niet van plan bent ceph te installeren om het te bestuderen, dan creëren de opdrachten niet minstens 3 knooppunten met minstens twee schijven, maar geven ze in de sjabloon aan dat virtuele schijven vda, vdb, enz. 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 is er een commando -print-xml > /tmp/storage-1.xml, dat een xml-bestand aanmaakt met een beschrijving van elke machine in de map /tmp/; als u dit niet toevoegt, wordt u niet in staat om virtuele machines te identificeren.
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 State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Nu een kleine nuance: tripleO gebruikt IPMI om servers te beheren tijdens installatie en introspectie.
Introspectie is het proces waarbij de hardware wordt geïnspecteerd om de parameters te verkrijgen die nodig zijn voor de verdere inrichting van knooppunten. Introspectie wordt uitgevoerd met behulp van Ironic, een dienst die is ontworpen om met bare metal-servers te werken.
Maar hier is het probleem: hoewel hardware-IPMI-servers een aparte poort hebben (of een gedeelde poort, maar dit is niet belangrijk), hebben virtuele machines dergelijke poorten niet. Hier komt een kruk genaamd vbmc ons te hulp - een hulpprogramma waarmee je een IPMI-poort kunt emuleren. Deze nuance is de moeite waard om op te letten, vooral voor degenen die zo'n laboratorium op een ESXI-hypervisor willen opzetten - om eerlijk te zijn, ik weet niet of het een analoog van vbmc heeft, dus het is de moeite waard om je over dit probleem af te vragen voordat je alles implementeert .
VBMC installeren:
yum install yum install python2-virtualbmcAls uw besturingssysteem het pakket niet kan vinden, voeg dan de repository toe:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNu hebben we het hulpprogramma ingesteld. Alles is hier banaal tot schandelijk toe. Nu is het 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 als volgt worden gedeclareerd:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Ik denk dat de syntaxis van de opdracht duidelijk is zonder uitleg. Voorlopig hebben al onze sessies echter de status DOWN. Om ze naar de UP-status te laten gaan, moet je ze inschakelen:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#En de laatste hand: u moet de firewallregels corrigeren (of volledig uitschakelen):
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 undercloud gaan en controleren of alles werkt. Het adres van de hostmachine is 192.168.255.200, op undercloud hebben we tijdens de voorbereiding voor de implementatie het benodigde ipmitool-pakket toegevoegd:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningZoals u kunt zien, hebben we het controleknooppunt met succes gelanceerd via VBMC. Laten we het 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 Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#De volgende stap is introspectie van de knooppunten waarop overcloud zal worden geïnstalleerd. Om dit te doen, moeten we een json-bestand voorbereiden met een beschrijving van onze knooppunten. Houd er rekening mee dat, in tegenstelling tot installatie op kale servers, het bestand voor elke machine de poort aangeeft waarop vbmc 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:27Let op: het besturingsknooppunt heeft twee interfaces, maar in dit geval is dit niet belangrijk, in deze installatie is één voor ons voldoende.
Nu bereiden we het json-bestand voor. We moeten het poppy-adres aangeven van de poort waarmee de inrichting zal worden uitgevoerd, de parameters van de knooppunten, ze namen geven en aangeven hoe we bij 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 afbeeldingen voorbereiden op ironie. Om dit te doen, downloadt u ze via wget en installeert u:
(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 ~]$Afbeeldingen uploaden naar undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Controleren of alle afbeeldingen zijn geladen
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Nog één ding: u moet een DNS-server toevoegen:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nu kunnen we het commando voor introspectie geven:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Zoals u aan de uitvoer kunt zien, is alles zonder fouten voltooid. Laten we controleren of alle knooppunten de status Beschikbaar hebben:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Als de knooppunten zich in een andere staat bevinden, die meestal beheersbaar is, dan is er iets misgegaan en moet je naar het logboek kijken om erachter te komen waarom dit is gebeurd. Houd er rekening mee dat we in dit scenario virtualisatie gebruiken en dat er bugs kunnen optreden bij het gebruik van virtuele machines of VBMC.
Vervolgens moeten we aangeven welk knooppunt welke functie zal uitvoeren - dat wil zeggen, het profiel aangeven waarmee het knooppunt zal worden ingezet:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Specificeer het profiel voor elk knooppunt:
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-d9afb69d1167Laten we controleren of we alles correct hebben gedaan:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Als alles klopt, geven we het commando om overcloud in te zetten:
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 qemuBij een echte installatie zullen uiteraard aangepaste sjablonen worden gebruikt, in ons geval zal dit het proces enorm bemoeilijken, aangezien elke wijziging in de sjabloon moet worden uitgelegd. Zoals eerder geschreven, is zelfs een eenvoudige installatie voldoende om te zien hoe het werkt.
Opmerking: de qemu-variabele van het type --libvirt is in dit geval nodig, omdat we geneste virtualisatie zullen gebruiken. Anders kunt u geen virtuele machines uitvoeren.
Nu heb je ongeveer een uur, of misschien meer (afhankelijk van de mogelijkheden van de hardware) en je kunt alleen maar hopen dat je na deze tijd de volgende melding te zien krijgt:
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Nu heb je een bijna volwaardige versie van openstack, waarop je kunt studeren, experimenteren, enz.
Laten we controleren of alles goed werkt. In de thuismapstapel van de gebruiker bevinden zich twee bestanden: één stackrc (voor het beheren van undercloud) en de tweede overcloudrc (voor het beheren van overcloud). Deze bestanden moeten als bron worden opgegeven, omdat ze informatie bevatten die nodig is voor authenticatie.
(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 ~]$Mijn installatie vereist nog steeds een kleine aanraking: het toevoegen van een route op de controller, aangezien de machine waarmee ik werk zich op een ander netwerk bevindt. Ga hiervoor naar controle-1 onder het warmte-admin account en registreer de route
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Welnu, nu kun je de horizon ingaan. Alle informatie - adressen, login en wachtwoord - staat in het bestand /home/stack/overcloudrc. Het uiteindelijke diagram ziet er als volgt uit:
Trouwens, in onze installatie werden machineadressen uitgegeven via DHCP en, zoals u kunt zien, worden ze “willekeurig” uitgegeven. U kunt in de sjabloon strikt definiëren welk adres tijdens de implementatie aan welke machine moet worden gekoppeld, als u dit nodig heeft.
Hoe stroomt het verkeer tussen virtuele machines?
In dit artikel bekijken we drie opties voor passerend verkeer
- Twee machines op één hypervisor op één L2-netwerk
- Twee machines op verschillende hypervisors op hetzelfde L2-netwerk
- Twee machines op verschillende netwerken (cross-network rooten)
Gevallen met toegang tot de buitenwereld via een extern netwerk, met behulp van zwevende adressen en gedistribueerde routering, zullen we de volgende keer overwegen, voorlopig zullen we ons concentreren op intern verkeer.
Om dit te controleren, stellen we het volgende diagram samen:
We hebben 4 virtuele machines gemaakt - 3 op één L2-netwerk - net-1, en nog 1 op het net-2-netwerk
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Laten we eens kijken op welke hypervisors de gemaakte 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 ~]$
Machines vm-1 en vm-3 bevinden zich op compute-0, machines vm-2 en vm-4 bevinden zich op knooppunt compute-1.
Daarnaast is er een virtuele router gemaakt 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 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 kijken hoe het verkeer stroomt, kijken we eerst naar wat we momenteel hebben op het besturingsknooppunt (dat ook een netwerkknooppunt is) en op het rekenknooppunt. Laten we beginnen met het rekenknooppunt.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Op dit moment heeft het knooppunt drie ovs-bruggen: br-int, br-tun, br-ex. Tussen hen is er, zoals we zien, een reeks interfaces. Laten we voor het gemak al deze interfaces in het diagram uitzetten en kijken wat er gebeurt.
Als we kijken naar de adressen waarnaar VxLAN-tunnels worden verhoogd, is te zien dat één tunnel wordt verhoogd naar compute-1 (192.168.255.26), terwijl de tweede tunnel lijkt op control-1 (192.168.255.15). Maar het meest interessante is dat br-ex geen fysieke interfaces heeft, en als je kijkt naar welke stromen zijn geconfigureerd, kun je zien dat deze brug op dit moment alleen maar verkeer kan laten vallen.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Zoals u aan de uitvoer kunt zien, wordt het adres rechtstreeks op de fysieke poort geschroefd, 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 alles wat uit de phy-br-ex-poort komt, worden weggegooid.
Eigenlijk kan er momenteel nergens anders verkeer deze brug binnenkomen dan via deze interface (de interface met br-int), en afgaande op de drops is het BUM-verkeer al de brug in gevlogen.
Dat wil zeggen dat verkeer dit knooppunt alleen via de VxLAN-tunnel kan verlaten en niets anders. Als u echter de DVR inschakelt, zal de situatie veranderen, maar daar zullen we een andere keer over praten. Wanneer u netwerkisolatie gebruikt, bijvoorbeeld bij gebruik van vlans, beschikt u in vlan 3 niet over één L0-interface, maar over meerdere interfaces. VxLAN-verkeer verlaat het knooppunt echter op dezelfde manier, maar ook ingekapseld in een soort speciale vlan.
We hebben het rekenknooppunt uitgezocht, laten we verder gaan met het besturingsknooppunt.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Eigenlijk kunnen we zeggen dat alles hetzelfde is, maar het IP-adres staat niet meer op de fysieke interface maar op de virtuele brug. Dit wordt gedaan omdat deze haven de haven is waarlangs het verkeer naar de buitenwereld gaat.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Deze poort is gekoppeld aan de br-ex bridge en aangezien er geen vlan-tags op staan, is deze poort een trunk-poort waarop alle vlans zijn toegestaan, nu gaat het verkeer naar buiten zonder tag, zoals aangegeven door vlan-id 0 in de uitvoer hierboven.
Al het andere is op dit moment vergelijkbaar met het rekenknooppunt: dezelfde bruggen, dezelfde tunnels die naar twee rekenknooppunten gaan.
We zullen in dit artikel geen aandacht besteden aan opslagknooppunten, maar om het te begrijpen is het noodzakelijk om te zeggen dat het netwerkgedeelte van deze knooppunten banaal is tot op het punt van schande. In ons geval is er slechts één fysieke poort (eth0) waaraan een IP-adres is toegewezen en dat is alles. Er zijn geen VxLAN-tunnels, tunnelbruggen, enz. - er zijn helemaal geen ovs, omdat het geen zin heeft. Wanneer u netwerkisolatie gebruikt, heeft dit knooppunt twee interfaces (fysieke poorten, bodny of slechts twee vlans - het maakt niet uit - het hangt af van wat u wilt) - één voor beheer, de tweede voor verkeer (schrijven naar de VM-schijf , lezen vanaf schijf, enz.)
We hebben uitgezocht wat we op de knooppunten hebben als er geen services zijn. Laten we nu vier virtuele machines lanceren en kijken hoe het hierboven beschreven schema verandert: we zouden poorten, virtuele routers, enz. moeten hebben.
Tot nu toe ziet ons netwerk er als volgt uit:
We hebben twee virtuele machines op elk computerknooppunt. Laten we, met behulp van compute-0 als voorbeeld, kijken hoe alles is inbegrepen.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ De machine heeft slechts één virtuele 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 ~]$
Deze interface ziet er in de Linux-bridge uit:
[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 ~]$ Zoals je aan de uitvoer kunt zien, zijn er slechts twee interfaces in de bridge: tap95d96a75-a0 en qvb95d96a75-a0.
Hier is het de moeite waard om even stil te staan bij de soorten virtuele netwerkapparaten in OpenStack:
vtap - virtuele interface gekoppeld aan een instantie (VM)
qbr - Linux-brug
qvb en qvo - vEth-paar verbonden met Linux-bridge en Open vSwitch-bridge
br-int, br-tun, br-vlan - Open vSwitch-bridges
patch-, int-br-, phy-br- - Open vSwitch-patchinterfaces die bruggen verbinden
qg, qr, ha, fg, sg - Open vSwitch-poorten die door virtuele apparaten worden gebruikt om verbinding te maken met OVS
Zoals u begrijpt, als we een qvb95d96a75-a0-poort in de bridge hebben, wat een vEth-paar is, dan is er ergens zijn tegenhanger, die logischerwijs qvo95d96a75-a0 zou moeten heten. 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: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Zoals we kunnen zien, bevindt de haven zich in BR-int. Br-int fungeert als een switch die virtuele machinepoorten beëindigt. Naast qvo95d96a75-a0 is de poort qvo5bd37136-47 zichtbaar in de uitvoer. Dit is de poort naar de tweede virtuele machine. Als gevolg hiervan ziet ons diagram er nu als volgt uit:
Een vraag die de aandachtige lezer onmiddellijk zou moeten interesseren: wat is de Linux-brug tussen de virtuele machinepoort en de OVS-poort? Feit is dat om de machine te beschermen beveiligingsgroepen worden gebruikt, die niets meer zijn dan iptables. OVS werkt niet met iptables, daarom is deze “kruk” uitgevonden. Het raakt echter verouderd: het wordt in nieuwe releases vervangen door conntrack.
Dat wil zeggen, uiteindelijk ziet het schema er als volgt uit:
Twee machines op één hypervisor op één L2-netwerk
Omdat deze twee VM's zich op hetzelfde L2-netwerk en op dezelfde hypervisor bevinden, zal het verkeer tussen hen logischerwijs lokaal via br-int stromen, aangezien beide machines zich op hetzelfde VLAN zullen 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 op hetzelfde L2-netwerk
Laten we nu eens kijken hoe het verkeer zal verlopen tussen twee machines op hetzelfde L2-netwerk, maar die zich op verschillende hypervisors bevinden. Eerlijk gezegd zal er niet veel veranderen, alleen het verkeer tussen de hypervisors gaat door de vxlan-tunnel. Laten we eens kijken naar een voorbeeld.
Adressen van virtuele machines waartussen we het verkeer zullen 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 kijken naar de doorstuurtabel 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 zou naar poort 2 moeten gaan - laten we eens kijken wat voor soort poort het 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 wil zeggen de interface in br-tun. Laten we eens 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 naar poort 2 gestuurd. Laten we eens kijken 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 vervolgens 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 ~]$ Mac staat in de br-int forwarding-tabel op compute-1, en zoals je kunt zien in de bovenstaande uitvoer, is deze zichtbaar via poort 2, de poort richting 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:46Welnu, dan zien we dat er in br-int op compute-1 een bestemmingspapaver is:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Dat wil zeggen dat het ontvangen pakket naar poort 3 vliegt, waarachter zich al een virtuele machine-instantie-00000003 bevindt.
Het mooie van het inzetten van Openstack voor leren op een virtuele infrastructuur is dat we gemakkelijk verkeer tussen hypervisors kunnen vastleggen en zien wat ermee gebeurt. Dit is wat we nu gaan doen, voer tcpdump uit op de vnet-poort richting compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************De eerste regel laat zien dat Patek van adres 10.0.1.85 naar adres 10.0.1.88 gaat (ICMP-verkeer), en het is verpakt in een VxLAN-pakket met vni 22 en het pakket gaat van host 192.168.255.19 (compute-0) naar host 192.168.255.26 .1 (reken-XNUMX). 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 vni in een hexadecimaal getalsysteem. Laten we dit getal omzetten naar het 16e systeem:
16 = 6*16^0+1*16^1 = 6+16 = 22Dat wil zeggen, vni komt overeen met de werkelijkheid.
De tweede regel toont retourverkeer, nou, het heeft geen zin om het uit te leggen, daar is alles duidelijk.
Twee machines op verschillende netwerken (routering tussen netwerken)
Het laatste geval voor vandaag is het routeren tussen netwerken binnen één project met behulp van een virtuele router. We overwegen een geval zonder DVR (we zullen dit in een ander artikel bekijken), dus routering vindt plaats op het netwerkknooppunt. In ons geval wordt het netwerkknooppunt niet in een aparte entiteit geplaatst en bevindt het zich op het besturingsknooppunt.
Laten we eerst eens kijken of routering werkt:
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msOmdat in dit geval het pakket naar de gateway moet gaan en daarheen moet worden gerouteerd, moeten we het poppy-adres van de gateway achterhalen, waarvoor we naar de ARP-tabel in de instance kijken:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Laten we nu eens kijken waar het verkeer met bestemming (10.0.1.254) fa:16:3e:c4:64:70 naartoe moet worden gestuurd:
[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 eens 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 ~]$ Alles is logisch, het verkeer gaat naar br-tun. Laten we eens kijken in welke vxlan-tunnel het zal worden ingepakt:
[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 het besturingsknooppunt:
[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 het controleknooppunt bereikt, dus we moeten erheen gaan en kijken hoe de routering zal gebeuren.
Zoals je je herinnert zag het controleknooppunt er precies hetzelfde uit als het rekenknooppunt: dezelfde drie bruggen, alleen had br-ex een fysieke poort waardoor het knooppunt verkeer naar buiten kon sturen. Door het maken van instances veranderde de configuratie op de rekenknooppunten: Linux bridge, iptables en interfaces werden aan de knooppunten toegevoegd. De creatie van netwerken en een virtuele router hebben ook hun stempel gedrukt op de configuratie van het controleknooppunt.
Het is dus duidelijk dat het gateway-MAC-adres in de br-int-doorstuurtabel op het besturingsknooppunt moet staan. Laten we controleren of het er 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 vanaf poort qr-0c52b15f-8f. Als we teruggaan naar de lijst met virtuele poorten in Openstack, wordt dit type poort gebruikt om verschillende virtuele apparaten met OVS te verbinden. Om preciezer te zijn: qr is een poort naar de virtuele router, die wordt weergegeven als een naamruimte.
Laten we eens kijken welke naamruimten er op de server staan:
[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 ~]$ Maar liefst drie exemplaren. Maar aan de hand van de namen kun je het doel van elk van hen raden. We komen later terug op instances met ID 0 en 1, nu zijn we geïnteresseerd in naamruimte qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Deze naamruimte bevat twee interne naamruimten die we eerder hebben gemaakt. Beide virtuele poorten zijn toegevoegd aan br-int. Laten we het mac-adres van de poort qr-0c52b15f-8f controleren, aangezien het verkeer, te oordelen naar het mac-adres van de bestemming, naar deze interface ging.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Dat wil zeggen dat in dit geval alles werkt volgens de wetten van standaardroutering. Omdat het verkeer bestemd is voor host 10.0.2.8, moet het de tweede interface qr-92fa49b5-54 verlaten en door de vxlan-tunnel naar het rekenknooppunt gaan:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Alles is logisch, geen verrassingen. Laten we eens kijken waar het klaproosadres 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 verwacht gaat het verkeer naar br-tun, laten we eens kijken naar welke tunnel het verkeer vervolgens 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. Welnu, op compute-1 is alles 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 ~]$
Eigenlijk hebben we het hele pakket doorgenomen. Ik denk dat je hebt gemerkt dat het verkeer door verschillende vxlan-tunnels ging en met verschillende VNI's naar buiten ging. Laten we eens kijken wat voor soort VNI dit zijn, waarna we een dump verzamelen op de controlepoort van het knooppunt en ervoor zorgen dat het verkeer precies stroomt zoals hierboven beschreven.
De tunnel naar compute-0 heeft dus de volgende acties=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Laten we 0x16 converteren naar het decimale getalsysteem:
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 converteren naar het decimale getalsysteem:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Laten we nu eens naar de dump kijken:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************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, waarbinnen een ICMP-pakket is verpakt van host 10.0.1.85 naar host 10.0.2.8. Zoals we hierboven hebben berekend, komt 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, waarbinnen een ICMP-pakket is verpakt van host 10.0.1.85 naar host 10.0.2.8. Zoals we hierboven hebben berekend, komt vni overeen met wat we in de uitvoer hebben gezien.
De volgende twee pakketten zijn retourverkeer van 10.0.2.8 en niet van 10.0.1.85.
Dat wil zeggen dat we uiteindelijk het volgende controleknooppuntschema kregen:
Het lijkt erop dat dat het is? We zijn twee naamruimten 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 ~]$ Terwijl we het hadden over de architectuur van het cloudplatform, zou het goed zijn als machines automatisch adressen zouden ontvangen van een DHCP-server. Dit zijn twee DHCP-servers voor onze twee netwerken 10.0.1.0/24 en 10.0.2.0/24.
Laten we controleren of dit waar is. Er is slechts één adres in deze naamruimte - 10.0.1.1 - het adres van de DHCP-server zelf, en het 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<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Laten we eens kijken of processen met qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 in hun naam op het controleknooppunt staan:
[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 bestaat zo'n proces en op basis van de informatie in de bovenstaande uitvoer kunnen we bijvoorbeeld zien wat we momenteel te 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 ~]$Als gevolg hiervan krijgen we de volgende reeks services op het besturingsknooppunt:
Houd er rekening mee dat dit slechts vier machines zijn, twee interne netwerken en één virtuele router... We hebben hier nu geen externe netwerken, een heleboel verschillende projecten, elk met hun eigen netwerken (overlappend), en we hebben een gedistribueerde router werd uitgeschakeld, en uiteindelijk was er tenslotte maar één controleknooppunt in de testbank (voor fouttolerantie moet er een quorum van drie knooppunten zijn). Het is logisch dat in de commercie alles “iets” ingewikkelder is, maar in dit eenvoudige voorbeeld begrijpen we hoe het zou moeten werken - of je 4 of 2 naamruimten hebt is natuurlijk belangrijk, maar vanuit het oogpunt van de werking van het geheel structuur, er zal niets veel veranderen... totdat je geen SDN van een leverancier aansluit. Maar dat is een heel ander verhaal.
Ik hoop dat het interessant was. Als je opmerkingen/aanvullingen hebt, of ergens heb ik ronduit gelogen (ik ben een mens en mijn mening zal altijd subjectief zijn) - schrijf op wat er gecorrigeerd/toegevoegd moet worden - wij zullen alles corrigeren/toevoegen.
Tot slot zou ik nog een paar woorden willen zeggen over het vergelijken van Openstack (zowel vanille als leverancier) met de cloudoplossing van VMWare. Deze vraag is mij de afgelopen jaren te vaak gesteld en, eerlijk gezegd, ben er al moe van, maar toch. Naar mijn mening is het erg moeilijk om deze twee oplossingen te vergelijken, maar we kunnen zeker zeggen dat er nadelen zijn aan beide oplossingen en dat je bij het kiezen van één oplossing de voor- en nadelen moet afwegen.
Als OpenStack een gemeenschapsgestuurde oplossing is, dan heeft VMWare het recht om alleen te doen wat het wil (lees: wat er winstgevend voor is) en dit is logisch - omdat het een commercieel bedrijf is dat gewend is geld te verdienen aan zijn klanten. Maar er is één grote en dikke MAAR: je kunt van OpenStack afstappen, bijvoorbeeld van Nokia, en met weinig kosten overstappen naar een oplossing van bijvoorbeeld Juniper (Contrail Cloud), maar het is onwaarschijnlijk dat je van VMWare af kunt komen . Voor mij zien deze twee oplossingen er als volgt uit: Openstack (vendor) is een eenvoudige kooi waarin je wordt geplaatst, maar je hebt een sleutel en je kunt op elk moment vertrekken. VMWare is een gouden kooi, de eigenaar heeft de sleutel van de kooi en het kost je veel.
Ik maak geen reclame voor het eerste product, noch voor het tweede - jij kiest wat je nodig hebt. Maar als ik zo'n keuze had, zou ik beide oplossingen kiezen - VMWare voor de IT-cloud (lage belasting, eenvoudig beheer), OpenStack van een of andere leverancier (Nokia en Juniper bieden zeer goede kant-en-klare oplossingen) - voor de Telecom-cloud. Ik zou Openstack niet voor pure IT gebruiken - het is alsof je met een kanon op mussen schiet, maar ik zie geen andere contra-indicaties voor het gebruik ervan dan redundantie. Het gebruik van VMWare in de telecom is echter als het vervoeren van steenslag in een Ford Raptor: het is prachtig van buiten, maar de chauffeur moet tien ritten maken in plaats van één.
Naar mijn mening is het grootste nadeel van VMWare de volledige geslotenheid ervan - het bedrijf zal je geen enkele informatie geven over hoe het werkt, bijvoorbeeld vSAN of wat er in de hypervisor-kernel zit - het is er simpelweg niet rendabel voor - dat wil zeggen, je zult word nooit een expert in VMWare - zonder ondersteuning van leveranciers ben je gedoemd (heel vaak ontmoet ik VMWare-experts die verbijsterd zijn door triviale vragen). Voor mij is VMWare het kopen van een auto met de motorkap op slot - ja, je hebt misschien specialisten die de distributieriem kunnen vervangen, maar alleen degene die je deze oplossing heeft verkocht, kan de motorkap openen. Persoonlijk hou ik niet van oplossingen waar ik niet in kan passen. Je zult zeggen dat je misschien niet onder de motorkap hoeft te gaan. Ja, dit is mogelijk, maar ik zal naar je kijken als je een grote functie in de cloud moet samenstellen van 20-30 virtuele machines, 40-50 netwerken, waarvan de helft naar buiten wil, en de tweede helft vraagt om SR-IOV-versnelling, anders heb je meer dan een paar dozijn van deze auto's nodig - anders zijn de prestaties niet genoeg.
Er zijn andere gezichtspunten, dus alleen jij kunt beslissen wat je kiest en, belangrijker nog, jij bent dan verantwoordelijk voor je keuze. Dit is slechts mijn mening - een persoon die minstens vier producten heeft gezien en aangeraakt: Nokia, Juniper, Red Hat en VMWare. Dat wil zeggen, ik heb iets om mee te vergelijken.
Bron: www.habr.com