Cloud computing bliver stadig mere en del af vores liv, og der er nÊppe nogen, der ikke har brugt nogen form for cloud-tjenester mindst en gang. Men hvad er skyen egentlig, og hvordan fungerer den? De fleste har kun en vag idé om det. 5G er allerede blevet en realitet, og telekominfrastrukturen begynder at bevÊge sig fra traditionelle lÞsninger til cloud-lÞsninger, ligesom den tidligere gik fra helt fysiske lÞsninger til virtualiserede »sÞjler«.
I dag vil vi tale om den indre verden af cloud-infrastrukturen, specielt dykke ned i grundlaget af dens netvĂŠrksmĂŠssige del.
Hvad er en sky? Er det blot virtualisering set fra en vinkel?
Det er et logisk spÞrgsmÄl. Nej, det er ikke virtualisering, selvom den spiller en rolle. Lad os se pÄ to definitioner:
Cloud computing (herefter kaldet Skyen) â er en model for at give brugervenlig adgang til distribuerede computingsressourcer, som skal kunne aktiveres og kĂžre efter anmodning med minimal forsinkelse og omkostninger fra serviceudbyderens side.
Virtualisering â er muligheden for at opdele en fysisk enhed (f.eks. en server) i flere virtuelle, hvilket dermed Ăžger ressourceudnyttelsen (for eksempel, hvis du havde 3 servere, der blev udnyttet 25-30 procent, fĂ„r du efter virtualisering 1 server, der er udnyttet 80-90 procent). Naturligvis krĂŠver virtualiseringen ogsĂ„ nogle ressourcer â du skal forsyne hypervisoren, men som erfaringen viser, er det det vĂŠrd. Et perfekt eksempel pĂ„ virtualisering er VMWare, som fremstiller virtuelle maskiner fremragende, eller KVM, som jeg foretrĂŠkker, men det er en smagssag.
Vi bruger virtualisering uden at vĂŠre klar over det. Selv de fysiske routere bruger allerede virtualisering â for eksempel installeres operativsystemet i de seneste versioner af JunOS som en virtuel maskine oven pĂ„ en real-time Linux-distribution (Wind River 9). Men virtualisering er ikke skyen, men skyer kan ikke eksistere uden virtualisering.
Virtualisering er en af de byggesten, som skyen er bygget pÄ.
At skabe en sky ved blot at samle flere hypervisorer i et enkelt L2-domĂŠne og tilfĂžje et par yaml-playbooks til automatisk at konfigurere VLANs via en eller anden ansible, og sĂ„ lĂŠgge et orkestreringssystem ovenpĂ„ til automatisk oprettelse af virtuelle maskiner, er ikke muligt. Mere prĂŠcist er det muligt, men den resulterende Frankenstein er ikke den sky, vi har brug for; mĂ„ske er det drĂžmmen for nogen. Desuden, hvis man ser pĂ„ OpenStack â det er i grunden ogsĂ„ en slags Frankenstein, men lad os ikke dvĂŠle ved det for nu.
Men jeg forstÄr, at det ikke er helt klart fra den ovenstÄende definition, hvad man reelt kan kalde en sky.
Derfor er der i dokumentet fra NIST (National Institute of Standards and Technology) beskrevet fem grundlĂŠggende karakteristika, som en cloud-infrastruktur skal have:
Service on demand. Brugeren skal have fri adgang til de tildelte computerressourcer (sĂ„som netvĂŠrk, virtuelle diske, hukommelse, processorkerner osv.), og disse ressourcer skal tildeles automatisk â uden mellemkomst fra serviceudbyderen.
Bred tilgÊngelighed af service. Adgang til ressourcerne skal sikres ved hjÊlp af standardmekanismer, sÄ bÄde almindelige pc'er, hurtige klienter og mobile enheder kan anvendes.
SammenlĂŠgning af ressourcer i puljer. Ressourcepuljer skal muliggĂžre samtidig tildeling af ressourcer til flere kunder, sikrer isolering mellem kunderne og undgĂ„r mutual indflydelse og konkurrence om ressourcer. Puljerne inkluderer ogsĂ„ netvĂŠrk, hvilket indikerer muligheden for at bruge overlapning i adressering. Puljerne skal understĂžtte skalering efter behov. Brug af puljer muliggĂžr det nĂždvendige niveau af fejltolerance for ressourcerne og abstraktion af fysiske og virtuelle ressourcer â servicemodtageren fĂ„r simpelthen tildelt det sĂŠt ressourcer, de har anmodet om (det er ligegyldigt for klienten, hvor disse ressourcer er fysisk placeret, pĂ„ hvor mange servere og switche). Dog skal man tage hĂžjde for, at udbyderen skal sikre en gennemsigtig backup af disse ressourcer.
Hurtig tilpasning til forskellige forhold. Tjenesterne skal vĂŠre fleksible â hurtig levering af ressourcer, omfordeling, tilfĂžjelse eller reduktion af ressourcer efter kundens anmodning, hvor kunden skal have fĂžlelsen af, at cloudressourcerne er uendelige. For at gĂžre det mere forstĂ„eligt, sĂ„ ser man f.eks. ikke en advarsel om, at en del af lagerpladsen i Apple iCloud er forsvundet, fordi en harddisk pĂ„ serveren er blevet defekt, og harddiske kan jo gĂ„ i stykker. Desuden er mulighederne for denne tjeneste nĂŠsten ubegrĂŠnsede â har du brug for 2 TB â intet problem, betal og fĂ„ det. Et lignende eksempel kan gives med Google Drive eller Yandex.Disk.
Muligheden for at mÄle den leverede service. Cloudsystemer skal automatisk overvÄge og optimere de forbrugte ressourcer, og disse mekanismer skal vÊre gennemsigtige bÄde for brugeren og tjenesteudbyderen. Det betyder, at du altid kan kontrollere, hvor mange ressourcer du og dine kunder forbruger.
Det er vigtigt at tage hÞjde for, at disse krav for det meste gÊlder for offentlige skyer, sÄ for private skyer (det vil sige skyer, der drives til interne behov i en virksomhed) kan disse krav vÊre noget justeret. Men de skal stadig opfyldes, ellers fÄr vi ikke alle fordelene ved cloud computing.
Hvorfor har vi brug for cloud?
Dog skabes enhver ny eller eksisterende teknologi, enhver ny protokol, for en Ă„rsag (bortset fra RIP-ng naturligvis). Protokoller for protokollens skyld â ingen har brug for dem (bortset fra RIP-ng selvfĂžlgelig). Det giver mening, at cloudtjenesten skabes for at give en eller anden service til brugeren/klienten. Vi kender alle i det mindste et par cloudtjenester, sĂ„som Dropbox eller Google Docs, og jeg formoder, at de fleste bruger dem med succes â for eksempel er denne artikel skrevet ved hjĂŠlp af cloudtjenesten Google Docs. Men de cloudtjenester, vi kender, er kun en del af mulighederne i skyen â mere prĂŠcist er det kun SaaS-typen af service. At tilbyde en cloudservice kan vi gĂžre pĂ„ tre mĂ„der: som SaaS, PaaS eller IaaS. Hvilken service er nĂždvendig for dig, afhĂŠnger af dine behov og muligheder.
Lad os se pÄ hver enkelt i rÊkkefÞlge:
Software as a Service (SaaS) â er en model for at levere fuld service til kunden, som for eksempel en e-mailservice som Yandex.Mail eller Gmail. I denne service-model gĂžr du som kunde faktisk ingenting andet end at bruge tjenesten â det vil sige, du behĂžver ikke tĂŠnke pĂ„ at konfigurere tjenesten, dens fejltolerance eller backup. Det vigtigste er ikke at kompromittere dit password, alt andet vil leverandĂžren af denne service tage sig af. Set fra serviceleverandĂžrens perspektiv â er de fuldt ansvarlige for hele tjenesten â fra serverhardware og host-operativsystemer til databaseindstillinger og software.
Platform as a Service (PaaS) â ved brug af denne model giver tjenesteudbyderen kunden en skabelon til tjenesten, for eksempel en webserver. Tjenesteudbyderen har givet kunden en virtuel server (faktisk et sĂŠt ressourcer som RAM/CPU/Storage/Nets osv.), og har endda installeret operativsystemet og nĂždvendig software pĂ„ denne server, men konfigurationen af det hele foretager kunden selv, og ansvaret for tjenestens funktionalitet pĂ„hviler allerede kunden. Tjenesteudbyderen, ligesom i det tidligere tilfĂŠlde, er ansvarlig for driften af den fysiske hardware, hypervisorerne, selve den virtuelle maskine, dens netvĂŠrksadgang osv., men selve tjenesten ligger allerede uden for deres ansvar.
Infrastructure as a Service (IaaS) â denne tilgang er allerede mere interessant, for faktis leverer tjenesteudbyderen kunden en komplet virtualiseret infrastruktur â det vil sige et sĂŠt (pulje) af ressourcer som CPU-kerner, RAM, netvĂŠrk osv. Alt andet er kundens ansvar â hvad kunden Ăžnsker at gĂžre med disse ressourcer inden for den tildelte pulje (kvote) â er ikke sĂŠrligt vigtigt for udbyderen. Ănsker kunden at skabe sin egen vEPC eller endda oprette en minioperatĂžr og levere telekommunikationstjenester â intet problem â gĂžr det. I et sĂ„dant scenarie er tjenesteudbyderen ansvarlig for at levere ressourcerne, deres fejltolerance og tilgĂŠngelighed, samt for operativsystemet, der gĂžr det muligt at samle disse ressourcer i puljer og tilbyde dem til kunden med mulighed for nĂ„r som helst at Ăžge eller reducere ressourcerne efter kundens anmodning. Alle virtuelle maskiner og diverse konfigurationer indstiller kunden selv via selvbetjeningsportalen og konsollen, herunder netvĂŠrkene (undtagen de eksterne netvĂŠrk).
Hvad er OpenStack?
For all three options, the service provider needs an OS that allows for the creation of a cloud infrastructure. In fact, in SaaS, the entire technology stack is not managed by one division â there is a division that takes care of the infrastructure â that is, it provides IaaS to another division, which then provides SaaS to the client. OpenStack is one of the cloud OS options that allows for the aggregation of switches, servers, and storage systems into a single resource pool, partitioning this common pool into sub-pools (tenants) and providing these resources to clients over the network.
OpenStack â is a cloud operating system that allows for the control of large pools of computing resources, data storage, and network resources, the provisioning and management of which is done via API using standard authentication mechanisms.
In other words, it is a comprehensive suite of open-source software projects designed to create cloud services (both public and private) â that is, a set of tools that enables the consolidation of server and switching hardware into a single resource pool, managing these resources while ensuring the required level of fault tolerance.
At the time of writing this material, the structure of OpenStack looks like this:
Image taken from
Each component that is part of OpenStack performs a specific function. This distributed architecture allows for the inclusion of the set of functional components that you need in the solution. However, some components are core components, and their removal will lead to the complete or partial inoperability of the solution as a whole. Such components are typically referred to as:
- Dashboard â A web-based GUI for managing OpenStack services
- Keystone â A centralized identity service that provides authentication and authorization functionality for other services, as well as managing user credentials and their roles.
- Neutron â A networking service that provides connectivity between the interfaces of various OpenStack services (including connectivity between VMs and their access to the outside world)
- Cinder â Provides access to block storage for virtual machines
- Nova â livscyklusmanagement for virtuelle maskiner
- Glance â depot for billeder af virtuelle maskiner og snapshots
- Swift â giver adgang til objektlagring
- Ceilometer â tjeneste, der muliggĂžr indsamling af telemetri og mĂ„ling af tilgĂŠngelige og forbrugte ressourcer
- Heat â orkestrering baseret pĂ„ skabeloner til automatisk oprettelse og provisioning af ressourcer
Den fulde liste over alle projekter og deres formÄl kan ses .
Hver komponent i OpenStack er en tjeneste, der er ansvarlig for en bestemt funktion og leverer et API til hĂ„ndtering af denne funktion og interaktion mellem denne tjeneste og andre tjenester i det cloud-baserede operativsystem for at skabe en samlet infrastruktur. For eksempel sĂžrger Nova for styring af compute-ressourcer og API til adgang til konfiguration af disse ressourcer, Glance â styring af billeder og API til hĂ„ndtering af dem, Cinder â bloklagring og API til hĂ„ndtering af det osv. Alle funktioner er meget tĂŠt forbundet med hinanden.
Men hvis man tĂŠnker efter, reprĂŠsenterer alle tjenester, der kĂžrer i OpenStack, i sidste ende en eller anden form for virtuel maskine (eller container), der er tilsluttet netvĂŠrket. SpĂžrgsmĂ„let opstĂ„r â hvorfor har vi sĂ„ mange elementer?
Lad os hurtigt gennemgÄ algoritmen til oprettelse af en virtuel maskine og tilslutning af den til netvÊrket og det permanente lager i OpenStack.
- NĂ„r du indsender en anmodning om at oprette en maskine, hvad enten det er via Horizon (Dashboard) eller via CLI, er det fĂžrste, der sker â autorisation af din anmodning i Keystone â kan du oprette en maskine, har du ret til at bruge dette netvĂŠrk, har dit projekt nok kvote osv.
- Keystone autentificerer din anmodning og genererer i svaret en auth-token, der vil blive brugt videre. Efter at have modtaget svar fra Keystone sendes anmodningen mod Nova (nova api).
- Nova-api tjekker validiteten af din anmodning ved at kontakte Keystone, ved hjĂŠlp af den tidligere genererede auth-token.
- Keystone autentificerer og giver pÄ grundlag af denne auth-token information om tilladelser og begrÊnsninger.
- Nova-api opretter en post om den nye VM i nova-database og sender anmodningen om at oprette maskinen til nova-scheduler.
- Nova-scheduler vÊlger en vÊrt (computernode), hvor VM'en skal implementeres baseret pÄ de angivne parametre, vÊgte og zoner. Oplysninger om dette og VM-id'et gemmes i nova-database.
- Derefter henvender nova-scheduler sig til nova-compute med en anmodning om implementering af instansen. Nova-compute kontakter nova-conductor for at fÄ information om maskinens parametre (nova-conductor fungerer som en proxyserver mellem nova-database og nova-compute, hvilket begrÊnser antallet af anmodninger til nova-database for at undgÄ problemer med databasens konsistens og reducere belastningen).
- Nova-conductor modtager de Ăžnskede oplysninger fra nova-database og sender dem til nova-compute.
- Derefter kontakter nova-compute glance for at fÄ billed-ID'et. Glance validator anmodningen i Keystone og returnerer de Þnskede oplysninger.
- Nova-compute henvender sig til neutron for at fÄ information om netvÊrksparametre. Ligesom glance validator neutron anmodningen i Keystone, hvorefter den opretter en post i databasen (port-id osv.), opretter anmodning om oprettelse af port og returnerer de Þnskede oplysninger til nova-compute.
- Nova-compute kontakter cinder med en anmodning om at tildele en volume til den virtuelle maskine. Ligesom glance validator cinder anmodningen i Keystone, opretter anmodning om at oprette volume og returnerer de Ăžnskede oplysninger.
- Nova-compute henvender sig til libvirt med anmodning om at implementere den virtuelle maskine med de angivne parametre.
I praksis bliver en tilsyneladende simpel operation til oprettelse af en virtuel maskine til en virvelvind af API-kald mellem elementerne pĂ„ den cloud-baserede platform. Som du kan se, bestĂ„r selv de tidligere nĂŠvnte tjenester af mindre komponenter, der interagerer med hinanden. Oprettelsen af maskinen er kun en lille del af, hvad den cloud-baserede platform kan tilbyde â der er en tjeneste, der hĂ„ndterer trafikbalance, en tjeneste, der er ansvarlig for bloklagring, en tjeneste til DNS, en tjeneste, der hĂ„ndterer provisionering af bare metal-servere osv. Cloudâen giver dig mulighed for at betragte dine virtuelle maskiner som en flok fĂ„r (i modsĂŠtning til virtualisering). Hvis der sker noget med en maskine i det virtuelle miljĂž â gendanner du den fra backups osv., mens cloud-applikationer er bygget pĂ„ en mĂ„de, sĂ„ virtuelle maskiner ikke spiller en sĂ„ vigtig rolle â hvis den virtuelle maskine er "dĂžd" â er det ikke et problem â der oprettes blot en ny maskine baseret pĂ„ en skabelon, og som man siger, bemĂŠrker enhederne ikke tabet af en soldat. Det krĂŠver naturligvis orkestreringsmekanismer â ved at bruge Heat-skabeloner kan du uden problemer deployere en kompleks funktion bestĂ„ende af dusinvis af netvĂŠrk og virtuelle maskiner.
Det er altid vigtigt at huske, at der ingen cloud-infrastruktur er uden netvĂŠrk â hver komponent interagerer pĂ„ en eller anden mĂ„de med andre komponenter gennem netvĂŠrket. Desuden har cloudâen et fuldstĂŠndigt dynamisk netvĂŠrk. Underlaget er naturligvis mere eller mindre statisk â nye noder og switche tilfĂžjes ikke hver dag, men overlay-delen kan, og vil uundgĂ„eligt, konstant ĂŠndre sig â nye netvĂŠrk vil blive tilfĂžjet eller fjernet, nye virtuelle maskiner vil fremstĂ„ og gamle vil forsvinde. Og som du husker fra definitionen af cloud'en givet i begyndelsen af artiklen â ressourcer skal tildeles brugeren automatisk og med minimal (eller helst ingen) indblanding fra tjenesteudbyderen. Det vil sige, at den type ressourcelevering af netvĂŠrket, der nu eksisterer i form af frontend i din personlige konto tilgĂŠngelig via http/https og den vagthavende netvĂŠrksingeniĂžr Vasily som backend â ikke er cloud, selv med Vasily's otte hĂŠnder.
Neutron, som en netvÊrkstjeneste, giver et API til at administrere den netvÊrksmÊssige del af den cloud-infrastruktur. Tjenesten sikrer funktionalitet og kontrol over netvÊrksdelen af OpenStack ved at tilbyde et abstraheringsniveau, kaldet Network-as-a-Service (NaaS). Det betyder, at netvÊrket er en lige sÄ virtuel og mÄlbar enhed som for eksempel virtuelle CPU-kerner eller RAM-kapacitet.
Men fÞr vi gÄr videre til arkitekturen for netvÊrksdelen af OpenStack, lad os se pÄ, hvordan netvÊrket fungerer i OpenStack, og hvorfor netvÊrket er en vigtig og integreret del af skyen.
SÄ vi har to virtuelle maskiner for kunden RED og to virtuelle maskiner for kunden GREEN. Lad os antage, at disse maskiner er placeret pÄ to hypervisorer pÄ fÞlgende mÄde:
I Þjeblikket er dette blot virtualisering af fire servere og ikke mere, da alt, hvad vi har gjort indtil videre, er at virtualisere fire servere, som er placeret pÄ to fysiske servere. Desuden er de endnu ikke koblet til netvÊrket.
For at skabe en cloud skal vi tilfĂžje nogle komponenter. FĂžrst virtualiserer vi netvĂŠrksdelen â vi skal forbinde disse fire maskiner parvis, og kunderne Ăžnsker netop L2-forbindelse. Man kan selvfĂžlgelig bruge en switch og opsĂŠtte trunk mod denne og styre det hele med en Linux-bro, eller for mere avancerede brugere, Open vSwitch (som vi vender tilbage til senere). Men der kan vĂŠre mange netvĂŠrk, og jĂŠvnligt at presse L2 gennem en switch er ikke den bedste idĂ© â forskellige afdelinger, servicetjenester, mĂ„neder med ventetid pĂ„ anmodninger, uger med fejlsĂžgning â i den moderne verden fungerer denne tilgang ikke lĂŠngere. Jo fĂžr virksomheden indser dette, jo lettere vil det vĂŠre for den at komme videre. Derfor vil vi mellem hypervisorerne dedikere et L3-netvĂŠrk, som vores virtuelle maskiner vil kommunikere gennem, og oven pĂ„ dette L3-netvĂŠrk vil vi opbygge virtuelle L2-overlay-netvĂŠrk, hvor trafikken fra vores virtuelle maskiner vil strĂžmme. Til indkapsling kan vi bruge GRE, Geneve eller VxLAN. Lige nu vil vi stoppe ved sidstnĂŠvnte, selvom det ikke er sĂ„ vigtigt.
Vi skal placere VTEP et sted (jeg hÄber, alle kender terminologien for VxLAN). Da L3-netvÊrket straks forlader serverne, er der intet, der forhindrer os i at placere VTEP pÄ selve serverne, og OVS (Open vSwitch) kan gÞre dette glimrende. Resultatet er, at vi har fÄet en sÄdan konstruktion:
Da trafik mellem VM'er skal opdeles, vil portene mod de virtuelle maskiner have forskellige VLAN-numre. Tag-nummeret spiller kun en rolle inden for en enkelt virtuel switch, da vi kan fjerne det uden problemer, nÄr det er indkapslet i VxLAN, da vi vil have VNI.
Nu kan vi nemt oprette vores maskiner og virtuelle netvĂŠrk til dem uden nogen problemer.
Men hvad hvis kunden har en anden maskine, men den befinder sig i et andet netvĂŠrk? Vi har brug for routing mellem netvĂŠrkene. Vi vil gennemgĂ„ et enkelt scenarie, hvor der anvendes centraliseret routing â det vil sige, at trafikken routedes gennem specifikke dedikerede netvĂŠrksnoder (som ofte er kombineret med kontrolnoder, sĂ„ vi fĂ„r det samme).
Det virker ikke sĂ„ kompliceret â vi laver en brointerface pĂ„ kontrolnoden, leder trafikken derhen og router den derfra, hvor vi har brug for det. Men problemet er, at kunden RED Ăžnsker at bruge netvĂŠrket 10.0.0.0/24, og kunden GREEN Ăžnsker at bruge netvĂŠrket 10.0.0.0/24. Det vil sige, at vi begynder at fĂ„ overlap i adresseomrĂ„derne. Derudover vil kunderne ikke have, at andre kunder kan rutte til deres interne netvĂŠrk, hvilket er logisk. For at adskille netvĂŠrkene og kundernes datatrafik vil vi tildele hver enkelt dem et separat namespace. Et namespace er i virkeligheden en kopi af Linux-netvĂŠrksstakken, hvilket betyder, at kunder i namespace RED er fuldstĂŠndigt isolerede fra kunder i namespace GREEN (eller routing mellem disse kunders netvĂŠrk er tilladt gennem default namespace eller pĂ„ overliggende transportudstyr).
SÄ vi fÄr fÞlgende skema:
L2 tunneler konvergerer fra alle beregningsnoder til kontrolnoden, hvor L3-interfacet for disse netvĂŠrk er placeret, hver i et dedikeret namespace for isolation.
Men glemte dog det vigtigste. Den virtuelle maskine skal levere en service til kunden, det vil sige, at den skal have mindst én ekstern grÊnseflade, som man kan kommunikere med. Det vil sige, at vi har brug for at komme ud til den ydre verden. Der er forskellige muligheder. Vi laver den enkleste lÞsning. Vi tilfÞjer én netvÊrk til hvert kunde, som vil vÊre gyldige i udbyderens netvÊrk og ikke vil overlappe med andre netvÊrk. NetvÊrkene kan ogsÄ vÊre overlappende og se ind i forskellige VRF'er pÄ udbyderens side. Disse netvÊrk vil ogsÄ leve i hvert enkelt kundes namespace. Dog vil de stadig komme ud i den ydre verden gennem én fysisk (eller bonded, hvilket er mere logisk) grÊnseflade. For at adskille kundernes trafik vil den udgÄende trafik blive tagget med en VLAN-tag, der er tildelt kunden.
Som resultat har vi fÄet fÞlgende diagram:
Et rimeligt spĂžrgsmĂ„l â hvorfor ikke lave gateways pĂ„ selve compute noderne? Der er ikke meget problem ved det, og faktisk vil det fungere, nĂ„r der aktiveres en distribueret router (DVR). I dette scenario betragter vi den enkleste lĂžsning med en central gateway, som anvendes som standard i OpenStack. For hĂžjt belastede funktioner vil bĂ„de den distribuerede router og accelerationsteknologier som SR-IOV og Passthrough blive anvendt, men som sagt, det er en helt anden historie. Lad os fĂžrst fokusere pĂ„ det grundlĂŠggende, og sĂ„ gĂ„r vi i detaljer.
Faktisk er vores skema allerede funktionsdygtigt, men der er et par nuancer:
- Vi skal finde en mÄde at beskytte vores maskiner pÄ, det vil sige at hÊnge et filter pÄ switchens grÊnseflade mod kunden.
- Mulighed for automatisk at modtage IP-adresse pÄ den virtuelle maskine, sÄ man ikke skal ind i den via konsollen hver gang for at sÊtte adressen.
Lad os starte med at beskytte maskinerne. Til dette kan vi bruge det velkendte iptables, hvorfor ikke.
SĂ„ nu er vores topologi blevet lidt mere kompliceret:
Lad os gÄ videre. Vi skal tilfÞje en DHCP-server. Det mest ideelle sted at placere DHCP-servere for hver kunde ville vÊre den kontrolnode, der blev nÊvnt tidligere, hvor namespaces er placeret:
Der er dog et lille problem. Hvad hvis alt genstarter, og al information om leje af adresser pĂ„ DHCP forsvinder? Det er logisk, at maskinerne vil fĂ„ tildelt nye adresser, hvilket ikke er sĂŠrlig praktisk. Der er to lĂžsninger â enten bruge domĂŠnenavne og tilfĂžje en DNS-server til hver klient, sĂ„ adressen ikke bliver sĂ„ vigtig for os (pĂ„ samme mĂ„de som netvĂŠrksdelen i k8s) â men der er et problem med de eksterne netvĂŠrk, da adresserne ogsĂ„ kan blive tildelt via DHCP â der skal vĂŠre en synkronisering mellem DNS-serverne pĂ„ den cloud-baserede platform og den eksterne DNS-server, hvilket efter min mening ikke er sĂŠrlig fleksibelt, men bestemt muligt. Den anden mulighed er at bruge metadata â det vil sige at gemme information om den tildelte maskineadresse, sĂ„ DHCP-serveren ved, hvilken adresse der skal tildeles, hvis maskinen allerede har modtaget en adresse. Den anden mulighed er enklere og mere fleksibel, da den tillader lagring af yderligere information om maskinen. Nu tilfĂžjer vi metadata-agenten til skemaet:
Et andet spĂžrgsmĂ„l, som ogsĂ„ bĂžr belyses â er muligheden for at bruge et enkelt ekstern netvĂŠrk for alle kunder, da eksterne netvĂŠrk, hvis de skal vĂŠre gyldige i hele netvĂŠrket, vil medfĂžre vanskeligheder â der skal konstant tildeles og kontrolleres disse netvĂŠrk. Muligheden for at bruge et fĂŠlles, forudkonfigureret eksternt netvĂŠrk vil vĂŠre meget passende ved oprettelsen af et offentligt cloud. Dette vil forenkle implementeringen af maskiner, da vi ikke skal sammenligne med databasen over adresser og vĂŠlge et unikt adresserum for den eksterne netvĂŠrk for hver kunde. Desuden kan vi pĂ„ forhĂ„nd definere det eksterne netvĂŠrk, og nĂ„r vi implementerer, skal vi blot associere de eksterne adresser med kundemaskinerne.
Og her kommer NAT til vores hjĂŠlp â vi skal blot gĂžre det muligt for kunder at fĂ„ adgang til omverdenen gennem standardnavnerummet ved hjĂŠlp af NAT-oversĂŠttelse. Men der er et lille problem her. Det er fint, hvis kundens server fungerer som klient og ikke som server â det vil sige, at den initierer forbindelser snarere end at modtage dem. Men for os vil det vĂŠre det modsatte. I dette tilfĂŠlde skal vi lave destination NAT, sĂ„ nĂ„r trafik modtages, forstĂ„r kontrolnoden, at denne trafik er rettet mod virtuel maskine A for kunde A, hvilket betyder, at der skal laves en NAT-oversĂŠttelse fra den eksterne adresse, for eksempel 100.1.1.1 til den interne adresse 10.0.0.1. PĂ„ den mĂ„de, selv om alle kunder bruger det samme netvĂŠrk, opretholdes den interne isolation fuldstĂŠndigt. Det vil sige, at vi skal lave dNAT og sNAT pĂ„ kontrolnoden. At bruge et enkelt netvĂŠrk med tildeling af flydende adresser eller eksterne netvĂŠrk, eller begge dele pĂ„ Ă©n gang, afhĂŠnger af, hvad du Ăžnsker at trĂŠkke ind i skyen. Vi vil ikke tilfĂžje flydende adresser til diagrammet, men lade de allerede tilfĂžjede eksterne netvĂŠrk vĂŠre â hver kunde har sit eget eksterne netvĂŠrk (markeret som VLAN 100 og 200 pĂ„ den eksterne grĂŠnseflade).
Resultatet er, at vi har fÄet en interessant og samtidig gennemarbejdet lÞsning, der har en vis fleksibilitet, men som endnu ikke besidder mekanismer til fejlbeskyttelse.
For det fĂžrste har vi kun Ă©n kontrolnode â nedbruddet af denne vil fĂžre til, at hele systemet kollapser. For at lĂžse dette problem er det nĂždvendigt at have et quorum af mindst 3 noder. Lad os tilfĂžje dette til diagrammet:
Naturligvis synkroniseres alle noder, og nÄr den aktive node fejler, vil en anden node overtage dens opgaver.
Det nĂŠste problem er de virtuelle maskiners diske. I Ăžjeblikket er de gemt pĂ„ hypervisorerne, og i tilfĂŠlde af problemer med hypervisoren mister vi alle data â og tilstedevĂŠrelsen af RAID hjĂŠlper ikke, hvis vi mister hele serveren i stedet for blot en disk. Derfor er vi nĂždt til at oprette en tjeneste, der fungerer som frontend for et eller andet lager. Hvilket lager vi vĂŠlger, er ikke sĂ„ vigtigt for os, men det skal beskytte vores data mod fejl, der kan skyldes bĂ„de disken og noden, og muligvis ogsĂ„ hele skabet. Der er flere muligheder â der findes selvfĂžlgelig SAN-netvĂŠrk med Fiber Channel, men lad os vĂŠre ĂŠrlige â FC er allerede en relikvie fra fortiden â svarende til E1 i transport â jeg er enig i, at det stadig bruges, men kun der, hvor det er helt uundgĂ„eligt. Derfor ville jeg ikke frivilligt implementere et FC-netvĂŠrk i 2020, nu hvor der findes andre, mere interessante alternativer. Selvom hver sin egen og der mĂ„ske findes dem, der mener, at FC med alle dets begrĂŠnsninger â er alt, hvad vi behĂžver â jeg vil ikke diskutere, hver har sin mening. Men den mest interessante lĂžsning efter min mening er brugen af SDS, for eksempel Ceph.
Ceph gÞr det muligt at opbygge en hÞjtilgÊngelig lÞsning til datalagring med mange mulige backupmuligheder, der spÊnder fra koder med paritet (svare til RAID 5 eller 6) til fuld replikering af data pÄ forskellige diske med hensyntagen til placeringen af diskene i serverne og serverne i skabene osv.
For at samle Ceph skal der ogsÄ bruges 3 noder. Interaktionen med lageret vil ogsÄ finde sted via netvÊrket ved hjÊlp af tjenester til blok-, objekt- og filopbevaring. Lad os tilfÞje lageret til skemaet:
BemĂŠrk: Det er muligt at lave hyperkonvergerende compute-noder â dette er en konceptuel sammenslutning af flere funktioner pĂ„ Ă©n node â for eksempel storage+compute â uden at allokere specielle noder til Ceph storage. Vi fĂ„r et tilsvarende fejltolerance mĂžnster â da SDS reservedele data med det niveau af redundans, vi angiver. Men hyperkonvergerende noder er altid et kompromis â da storage-noden ikke blot varme luften, som det umiddelbart kan synes (da der ikke er virtuelle maskiner pĂ„ den) â den bruger CPU-ressourcer til at vedligeholde SDS (faktisk udfĂžrer den i baggrunden alle replikationer, genopretninger efter fejl i noder, diske osv.). Det vil sige, at du vil miste en del af kapaciteten fra compute-noden, hvis du kombinerer den med storage.
Alt dette skal styres pĂ„ en eller anden mĂ„de â vi har brug for noget, ved hjĂŠlp af hvilket vi kan oprette maskiner, netvĂŠrk, virtuelle routere osv. Derfor vil vi tilfĂžje en tjeneste til kontrolnoden, som vil fungere som dashboard â klienten vil kunne oprette forbindelse til denne portal via http/https og gĂžre alt, hvad der er nĂždvendigt (nĂ„ nĂŠsten).
Som resultat har vi nu et fejltolerant system. Alle elementer i denne infrastruktur skal styres pÄ en eller anden mÄde. Tidligere blev det beskrevet, at OpenStack er en rÊkke projekter, hvor hver isÊr giver en bestemt funktion. Som vi kan se, er der mere end rigeligt af elementer, der skal konfigureres og kontrolleres. I dag vil vi tale om netvÊrksdelen.
Neutrons arkitektur
I OpenStack er det netop Neutron, der stÄr for tilslutning af porte pÄ virtuelle maskiner til det fÊlles L2-netvÊrk, sikrer routing af trafik mellem VM'er, der er placeret i forskellige L2-netvÊrk samt routing udad, tilbyder tjenester som NAT, Floating IP, DHCP osv.
Den hÞj-niveau drift af netvÊrkstjenesten (den grundlÊggende del) kan beskrives sÄledes.
Ved opstart af VM'en foretager netvĂŠrkstjenesten:
- Opretter en port til denne VM (eller porte) og informerer DHCP-tjenesten herom;
- Der oprettes en ny virtuel netvĂŠrksenhed (gennem libvirt);
- VM'en tilsluttes den port (de porte), der blev oprettet i trin 1;
MĂŠrkeligt nok hviler Neutrons funktion pĂ„ standardmekanismer, som alle er bekendt med, der nogensinde har dykket ned i Linux â dette er namespaces, iptables, linux bridges, openvswitch, conntrack osv.
Det skal straks prĂŠciseres, at Neutron ikke er en SDN-controller.
Neutron bestÄr af flere indbyrdes relaterede komponenter:
Openstack-neutron-server â er en dĂŠmon, der arbejder med brugerforespĂžrgsler via API. Denne dĂŠmon beskĂŠftiger sig ikke med at definere netvĂŠrksforbindelser, men leverer den nĂždvendige information til sine plugins, som derefter konfigurerer det nĂždvendige netvĂŠrkselement. Neutron-agenterne pĂ„ OpenStack-noder registrerer sig pĂ„ Neutron-serveren.
Neutron-server er faktisk en applikation, der er skrevet i Python og bestÄr af to dele:
- REST-tjeneste
- Neutron Plugin (core/service)
REST-tjenesten er beregnet til at modtage API-anmodninger fra de Ăžvrige komponenter (f.eks. anmodninger om at levere bestemt information osv.)
Plugins er tilsluttede softwarekomponenter/modules, der kaldes ved API-anmodninger â det vil sige, at tilfĂžjelsen af en service sker gennem dem. Plugins inddeles i to typer â service- og kerne-plugin. Som regel er kerne-pluginet primĂŠrt ansvarligt for at administrere adresseomrĂ„det og L2-forbindelser mellem VM'er, mens service-plugins leverer yderligere funktionalitet, sĂ„som VPN eller FW.
Listen over tilgĂŠngelige plugins kan f.eks. ses
Der kan vĂŠre flere service-plugins, men der kan kun vĂŠre et kerne-plugin.
Openstack-neutron-ml2 â er det standard kerne-plugin til Openstack. Dette plugin har en modulĂŠr arkitektur (i modsĂŠtning til sin forgĂŠnger) og konfigurerer netvĂŠrkstjenesten gennem tilsluttede drivere. Selve plugin'et vil vi se nĂŠrmere pĂ„ senere, da det faktisk giver den fleksibilitet, som OpenStack har i det netvĂŠrksmĂŠssige omrĂ„de. Kerne-pluginet kan erstattes (f.eks. gĂžr Contrail Networking en sĂ„dan udskiftning).
RPC-tjeneste (rabbitmq-server) â en tjeneste, der sikrer hĂ„ndtering af kĂžer og interaktion med andre OpenStack-tjenester samt interaktion mellem agenter for netvĂŠrkstjenesten.
NetvĂŠrksagenter â agenter, der er placeret i hver node, gennem hvilke konfiguration af netvĂŠrkstjenesterne foregĂ„r.
Agenterne findes i flere typer.
Hovedagenten â er L2 agent. Disse agenter kĂžrer pĂ„ hver af hypervisorerne, inklusive kontrolnoderne (mere prĂŠcist sagt pĂ„ alle noder, der tilbyder en eller anden tjeneste til lejere), og deres primĂŠre funktion er at forbinde virtuelle maskiner til det fĂŠlles L2-netvĂŠrk samt at generere alarmer ved opstĂ„en af ââbegivenheder (for eksempel ved afbrydelse/aktivering af en port).
Den nÊste, ikke mindre vigtige agent er L3 agent. Som standard kÞrer denne agent udelukkende pÄ netvÊrksnoden (oftest er netvÊrksnoden sammenlagt med kontrolnoden) og sikrer routing mellem lejernes netvÊrk (bÄde mellem hans netvÊrk og netvÊrkene af andre lejere samt adgang til den ydre verden, idet den sikrer NAT og DHCP-service). Men ved brug af DVR (distribueret router) opstÄr der behov for L3-plugin ogsÄ pÄ compute-noderne.
L3-agenten bruger Linux-namespaces til at give hver lejer et sĂŠt af deres egne isolerede netvĂŠrk og funktionaliteten af virtuelle routere, der ruter trafik og tilbyder gateway-tjenester til Layer 2-netvĂŠrk.
Database â en database over identifikatorer for netvĂŠrk, undernetvĂŠrk, porte, puljer osv.
Faktisk modtager Neutron API-anmodninger til oprettelse af netvĂŠrksenheder, godkender anmodningen, og gennem RPC (hvis den henvender sig til et plugin eller agent) eller REST API (hvis den kommunikerer i SDN) videregiver den til agenten (via plugins) instruktioner, der er nĂždvendige for at organisere den anmodede tjeneste.
Lad os nu se pÄ testinstallationen (hvordan den er implementeret og hvad den indeholder, ser vi senere i den praktiske del) og se hvor hver komponent er placeret:
(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 ~]$ 
Her er hele strukturen af Neutron. Nu er det tid til at dedikere lidt tid til ML2-plugin.
Modular Layer 2
Som nĂŠvnt tidligere er plugin'et den standardmĂŠssige rodtplugin for OpenStack og har en modulĂŠr arkitektur.
ForgĂŠngeren til ML2-plugin'et havde en monolitisk struktur, hvilket ikke gjorde det muligt at bruge en blanding af flere teknologier i Ă©n installation. For eksempel kunne du ikke bruge bĂ„de openvswitch og linuxbridge pĂ„ Ă©n gang â det mĂ„tte vĂŠre det ene eller det andet. Derfor blev ML2-plugin'et oprettet med sin arkitektur.
ML2 har to komponenter â to typer drivere: Type drivers og Mechanism drivers.
Type drivers definerer de teknologier, der vil blive anvendt til at organisere netvÊrksforbindelser, sÄsom VxLAN, VLAN, GRE. Disse drivere tillader brugen af forskellige teknologier. Den standardmÊssige teknologi er VxLAN-inkapsling for overlay-netvÊrk og vlan for eksterne netvÊrk.
FĂžlgende typer netvĂŠrk er inkluderet under Type drivers:
Flad â et netvĂŠrk uden tagging
VLAN â et tagged netvĂŠrk
Local â en speciel type netvĂŠrk til all-in-one installationer (disse installationer er nĂždvendige enten for udviklere eller til trĂŠning)
GRE â et overlay-netvĂŠrk, der bruger GRE-tunneler
VxLAN â et overlay-netvĂŠrk, der bruger VxLAN-tunneler
Mechanism drivers definerer middel, der muliggĂžr organisering af de angivne driver-teknologier - for eksempel openvswitch, sr-iov, opendaylight, OVN osv.
AfhÊngigt af implementeringen af denne driver vil enten agenter, der styres af Neutron, eller forbindelser til en ekstern SDN-controller blive brugt, som tager sig af alle spÞrgsmÄl om organisering af L2-netvÊrk, routing osv.
For eksempel, hvis vi bruger ML2 sammen med OVS, installeres der en L2-agent pÄ hver compute-node, som styrer OVS. Men hvis vi eksempelvis bruger OVN eller OpenDayLight, overgÄr styringen af OVS til deres jurisdiktion - Neutron sender kommandoer til controlleren via rod-plugins, og controlleren udfÞrer de givne instrukser.
Lad os friske hukommelsen om Open vSwitch.
I Ăžjeblikket er en af nĂžglekomponenterne i OpenStack Open vSwitch.
NĂ„r OpenStack installeres uden nogen yderligere vendor SDN som Juniper Contrail eller Nokia Nuage, er OVS den primĂŠre netvĂŠrkskomponent i det cloud-netvĂŠrk og gĂžr det muligt at organisere fuldgyldige overlay-netvĂŠrk med multitenancy ved hjĂŠlp af iptables, conntrack og namespaces. Naturligvis kan denne komponent erstattes, for eksempel ved brug af eksterne proprietĂŠre SDN-lĂžsninger.
OVS er en software-switch med open source, der er designet til brug i virtualiserede miljÞer som en virtuel trafikhÄndterer.
I Ăžjeblikket har OVS en meget anstĂŠndig funktionalitet, der inkluderer teknologier som QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK osv.
BemĂŠrk: Oprindeligt blev OVS ikke designet som en software-switch til hĂžjtydende telekomfunktioner og var mere tiltĂŠnkt mindre krĂŠvende IT-funktioner som webservere eller mailservere. Men OVS forbedres, og de nuvĂŠrende implementationer af OVS har vĂŠsentligt forbedret ydeevne og muligheder, hvilket gĂžr det muligt for teleoperatĂžrer at anvende det til hĂžjt belastede funktioner; der er for eksempel en OVS-implementering med DPDK-acceleration.
Der er tre vigtige komponenter i OVS, man bĂžr kende til:
- Kernel-modul â komponent placeret i kernel space, som hĂ„ndterer trafik baseret pĂ„ de regler, der modtages fra kontrolenheden;
- vSwitch daemon (ovs-vswitchd) er en proces, der kĂžrer i user space, som er ansvarlig for programmering af kernel-modulet â det vil sige, at det reprĂŠsenterer selve logikken for switchens drift.
- Database server â en lokal database, der er placeret pĂ„ hver host, hvor OVS kĂžrer, i hvilken konfigurationen opbevares. Gennem denne modul kan SDN controllere kommunikere via OVSDB-protokollen.
Derudover medfÞlger en samling diagnostiske og styringsvÊrktÞjer, sÄsom ovs-vsctl, ovs-appctl, ovs-ofctl osv.
I Ăžjeblikket anvendes Openstack vidt og bredt af teleselskaber til at migrere netvĂŠrksfunktioner som EPC, SBC, HLR osv. Nogle funktioner kan uden problemer fungere med OVS i den form, den har, men f.eks. hĂ„ndterer EPC trafikken fra abonnenterne â det vil sige, at det lader en enorm mĂŠngde trafik passere (i Ăžjeblikket nĂ„r trafikmĂŠngderne flere hundrede gigabit i sekundet). Det er selvfĂžlgelig ikke en god idĂ© at kĂžre sĂ„dan trafik gennem kernel space (da forwarderen som standard er placeret der). Derfor implementeres OVS ofte helt i user space ved at bruge DPDK-teknologien til at omdirigere trafik fra NIC til user space og omgĂ„ kernel.
BemÊrk: For skyen, der er implementeret til telekomfunktioner, er der mulighed for at lede trafik fra compute-noden direkte til switching-udstyret og omgÄ OVS. Til dette formÄl anvendes mekanismerne SR-IOV og Passthrough.
Hvordan fungerer det i en real-world prototype?
Lad os nu gÄ videre til den praktiske del og se, hvordan det hele fungerer i praksis.
For at starte, vil vi implementere en simpel Openstack-installation. Da jeg ikke har et sĂŠt servere ved hĂ„nden til eksperimenter, vil vi bygge prototypen pĂ„ Ă©n fysisk server ved hjĂŠlp af virtuelle maskiner. Ja, selvfĂžlgelig er en sĂ„dan lĂžsning ikke egnet til kommercielle formĂ„l, men for at se, hvordan netvĂŠrket fungerer i Openstack, er en sĂ„dan installation mere end tilstrĂŠkkelig. Desuden er en sĂ„dan installation til uddannelsesmĂŠssige formĂ„l endda mere interessant â da man kan fange trafikken osv.
Da vi kun skal se den grundlĂŠggende del, kan vi undlade at bruge flere netvĂŠrk og i stedet opsĂŠtte alt med kun to netvĂŠrk, hvor det andet netvĂŠrk i dette design vil blive brugt udelukkende til adgang til undercloud og DNS-serveren. Vi vil ikke rĂžre ved de eksterne netvĂŠrk lige nu â det er et emne for en separat stor artikel.
Lad os komme i gang. FĂžrst lidt teori. Vi vil installere OpenStack ved hjĂŠlp af TripleO (OpenStack pĂ„ OpenStack). Essensen af TripleO er, at vi installerer OpenStack all-in-one (dvs. pĂ„ Ă©n node), kaldet undercloud, og derefter bruger de muligheder, som den installerede OpenStack giver, til at installere det produktionsklare OpenStack, kaldet overcloud. Undercloud vil bruge den indbyggede mulighed for at administrere fysiske servere (bare metal) â projektet Ironic â til at provisionere hypervisorer, som skal udfĂžre rollerne som compute-, control- og storage-noder. Det vil sige, at vi ikke bruger nogen tredjeparts vĂŠrktĂžjer til at implementere OpenStack â vi implementerer OpenStack med OpenStack selv. Det bliver meget klarere, mens vi gĂ„r igennem installationen, sĂ„ lad os ikke stoppe her og komme videre.
BemĂŠrkning: I denne artikel har jeg for enkelhedens skyld valgt ikke at bruge netvĂŠrksisolering for de interne OpenStack-netvĂŠrk, og alt er opsat med kun Ă©t netvĂŠrk. Dog pĂ„virker tilstedevĂŠrelsen eller fravĂŠret af netvĂŠrksisolering ikke den grundlĂŠggende funktionalitet af lĂžsningen â alt vil fungere prĂŠcis som med brug af isolering, men trafikken vil bevĂŠge sig i Ă©t netvĂŠrk. For en kommerciel installation er det selvfĂžlgelig nĂždvendigt at anvende isolering ved hjĂŠlp af forskellige VLAN og grĂŠnseflader. For eksempel vil administrations-trafikken til Ceph-lagringssystemet og den faktiske datatrafik (maskinernes dataanmodninger til diskene osv.) ved isolering bruge forskellige undernet (Storage management og Storage), hvilket gĂžr lĂžsningen mere fejltolerant ved at adskille denne trafik, f.eks. ved at bruge forskellige porte eller anvende forskellige QoS-profiler til forskellige trafiktyper, sĂ„ datatrafikken ikke overbelaster signaltrafikken. I vores tilfĂŠlde vil de dog alle bevĂŠge sig i det samme netvĂŠrk, og det limiterer os pĂ„ ingen mĂ„de.
BemÊrkning: Da vi planlÊgger at kÞre virtuelle maskiner i et virtuelt miljÞ baseret pÄ virtuelle maskiner, skal vi fÞrst aktivere nested virtualisering.
Du kan kontrollere, om nested virtualisering er aktiveret eller ej, pÄ fÞlgende mÄde:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Hvis du ser bogstavet N, sÄ aktiverer du understÞttelse af nested virtualisering efter enhver vejledning, du mÄtte finde online, for eksempel .
Vi skal samle et diagram, der ser sÄdan her ud, med virtuelle maskiner:
I mit tilfÊlde brugte jeg OpenvSwitch til sammenkobling af de virtuelle maskiner, der skulle indgÄ i den kommende installation (jeg endte med 7 af dem, men du kan klare dig med 4, hvis du ikke har mange ressourcer). Jeg oprettede en ovs-bro og tilsluttede de virtuelle maskiner via port-grupper. For dette oprettede jeg en XML-fil af fÞlgende slags:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
ovs-network-1
7a2e7de7-fc16-4e00-b1ed-4d190133af67Her erklĂŠres tre portgrupper â to access og en trunk (den sidste var nĂždvendig for DNS-serveren, men du kan klare dig uden den, eller opsĂŠtte den pĂ„ hostmaskinen â alt efter hvad der passer dig bedst). Herefter erklĂŠrer vi vores netvĂŠrk via virsh net-define ved hjĂŠlp af denne skabelon:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nu justerer vi hypervisorens portkonfigurationer:
[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 ~]# BemÊrk: i dette scenarie vil adressen pÄ porten ovs-br1 ikke vÊre tilgÊngelig, da den ikke har en VLAN-tag. For at rette dette skal du give kommandoen sudo ovs-vsctl set port ovs-br1 tag=100. Dog vil denne tag forsvinde efter genstart (hvis nogen ved, hvordan man fÄr den til at blive, ville jeg vÊre yderst taknemmelig). Men det er ikke sÄ vigtigt, da denne adresse kun er nÞdvendig i installationsperioden og vil ikke vÊre nÞdvendig, nÄr OpenStack er fuldt implementeret.
DernĂŠst opretter vi undercloud-maskinen:
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=ttyS0Under installation, set all necessary parameters, such as the machine name, passwords, users, NTP servers, etc. You can also configure the ports right away, but I personally find it easier to log into the machine via console after installation and adjust the required files. If you already have a ready-made image, you can use it, or do as I doâdownload the minimal CentOS 7 image and use it for VM installation.
After successful installation, you should have a virtual machine where you can install Undercloud.
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningFirst, we install the necessary tools for the installation process:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Installing Undercloud
We create a user named stack, set a password, add him to sudoers, and give him permission to execute root commands via sudo without entering a password:
useradd stack
passwd stack
echo âstack ALL=(root) NOPASSWD:ALLâ > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNow we specify the full name of Undercloud in the hosts file:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Next, we add repositories and install the necessary software:
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleNote: if you do not plan to install Ceph, then do not enter the commands related to Ceph. I used the Queens release, but you can use any other that you prefer.
Next, copy the Undercloud configuration file to the home directory of the stack user:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNow you need to modify this file to suit our installation.
You should add the following lines at the beginning of the file:
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 = 10So, let's go through the settings:
undercloud_hostname â the full name of the Undercloud server, it must match the entry on the DNS server.
local_ip â lokal adresse undercloud mod provisioning-netvĂŠrket
network_gateway â denne samme lokale adresse vil fungere som gateway for adgang til omverdenen under installationen af overcloud-noderne, og stemmer ogsĂ„ overens med den lokale ip
undercloud_public_host â adresse for ekstern API, tildeles en hvilken som helst ledig adresse fra provisioning-netvĂŠrket
undercloud_admin_host adresse for intern API, tildeles en hvilken som helst ledig adresse fra provisioning-netvĂŠrket
undercloud_nameservers â DNS-server
generate_service_certificate â denne linje er meget vigtig i det nuvĂŠrende eksempel, da hvis den ikke er indstillet til false, vil du fĂ„ en fejl under installationen, problemet er beskrevet i bug-tracker Red Hat
local_interface interface i provisioning-netvĂŠrket. Dette interface vil blive rekonfigureret under implementeringen af undercloud, sĂ„ undercloud skal have to interfaces â et til adgang til det, det andet til provisioning
local_mtu â MTU. Da vi har et testlaboratorium og MTU er 1500 pĂ„ OVS-switchens porte, er det nĂždvendigt at sĂŠtte vĂŠrdien til 1450, sĂ„ indkapslede VxLAN-pakker kan passere
network_cidr â provisioning-netvĂŠrk
masquerade â brug af NAT for adgang til det eksterne netvĂŠrk
masquerade_network â netvĂŠrk, der vil blive NAT'et
dhcp_start â startadresse for adressenpoolen, hvorfra der vil blive tildelt adresser til noderne under implementeringen af overcloud
dhcp_end â slutadresse for adressenpoolen, hvorfra der vil blive tildelt adresser til noderne under implementeringen af overcloud
inspection_iprange â adressepool, der er nĂždvendig til introspektion (mĂ„ ikke overlappe med den ovenfor nĂŠvnte pool)
scheduler_max_attempts â det maksimale antal forsĂžg pĂ„ installation af overcloud (skal vĂŠre stĂžrre end eller lig med antallet af noder)
NĂ„r filen er beskrevet, kan du give kommandoen til at implementere undercloud:
openstack undercloud install
Proceduren tager fra 10 til 30 minutter afhÊngigt af dit hardware. I sidste ende skal du se sÄdan et output:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud installation fuldfĂžrt.
Filen med denne installations adgangskoder ligger pÄ
/home/stack/undercloud-passwords.conf.
Der er ogsÄ en stackrc-fil pÄ /home/stack/stackrc.
Disse filer er nĂždvendige for at interagere med OpenStack-tjenesterne og bĂžr
sikres.
#############################################################################Dette output indikerer, at du har installeret undercloud med succes, og nu kan du kontrollere tilstanden af undercloud og gÄ videre til installationen af overcloud.
Hvis du ser output fra ifconfig, vil du se, at der er oprettet et nyt bridge-interface
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163 mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Gennem denne grĂŠnseflade vil arbejdet med at implementere overcloud nu finde sted.
Fra output nedenfor kan vi se, at alle tjenester er pÄ én node:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Hostnavn | Tjeneste | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Nedenfor vises konfigurationen af netvĂŠrksdelen af undercloud:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Installation af overcloud
I Ăžjeblikket har vi kun undercloud, og vi mangler noderne, som overcloud skal bygges af. Derfor vil vi fĂžrst implementere de virtuelle maskiner, vi har brug for. Under implementeringen vil undercloud automatisk installere operativsystemet og den nĂždvendige software pĂ„ overcloud-maskinerne â det vil sige, at vi ikke behĂžver at implementere maskinen helt, men blot oprette en disk (eller diske) til den og bestemme dens parametre â vi fĂ„r faktisk en tom server uden installeret operativsystem.
Vi gÄr ind i mappen med vores virtuelle maskiners diske og opretter diske i den Þnskede stÞrrelse:
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 160GDa vi handler fra roden, skal vi Êndre ejeren af disse diske for at undgÄ problemer med rettigheder:
[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]# BemÊrk: Hvis du ikke planlÊgger at installere ceph med henblik pÄ at lÊre det, sÄ opret ikke mindst 3 noder med mindst to diske, og angiv i skabelonen, at der vil blive brugt virtuelle diske som vda, vdb osv.
Fint, nu skal vi definere alle disse maskiner:
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 Til sidst er der kommandoer âprint-xml > /tmp/storage-1.xml, som opretter en xml-fil med beskrivelsen af hver maskine i mappen /tmp/, hvis den ikke tilfĂžjes, kan du ikke definere de virtuelle maskiner.
Nu skal vi definere alle disse maskiner i virsh:
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Navn Status
----------------------------------------------------
6 dns-server kĂžrer
64 undercloud kĂžrer
- compute-1 slukket
- compute-2 slukket
- control-1 slukket
- storage-1 slukket
- storage-2 slukket
[root@hp-gen9 ~]#Der er nu en lille nuance â tripleO bruger IPMI til at styre serverne under installation og introspektion.
Introspektion er processen med at inspicere hardwarekomponenterne for at indhente de nĂždvendige parametre til videre provisioning af noder. Introspektionen udfĂžres med ironic â tjenesten, der er designet til at arbejde med bare metal-servere.
Men her kommer problemet â hvis de fysiske servere har en separat IPMI-port (eller en delt port, men det er ikke sĂ„ vigtigt), sĂ„ har virtuelle maskiner ikke sĂ„danne porte. Her kommer en lĂžsning kaldet vbmc til hjĂŠlp â et vĂŠrktĂžj, der kan simulere en IPMI-port. Det er vigtigt at vĂŠre opmĂŠrksom pĂ„ denne detalje, isĂŠr for dem, der Ăžnsker at oprette et sĂ„dant laboratorium pĂ„ en ESXi hypervisor â jeg ved ikke, om der findes en analog til vbmc i den, sĂ„ det er vĂŠrd at tĂŠnke over dette spĂžrgsmĂ„l, inden man ruller alt ud.
Installerer vbmc:
yum install python2-virtualbmcHvis dit operativsystem ikke kan finde pakken, sÄ tilfÞj repositoryet:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNu konfigurerer vi vĂŠrktĂžjet. Her er alt banal til det ekstreme. Det er rimeligt, at der i listen over vbmc ikke er nogen servere.
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# For at de skal dukke op, skal de erklÊres manuelt pÄ fÞlgende mÄde:
[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
+-------------+--------+---------+------+
| DomĂŠnenavn | Status | Adresse | Port |
+-------------+--------+---------+------+
| compute-1 | nede | :: | 7004 |
| compute-2 | nede | :: | 7005 |
| control-1 | nede | :: | 7001 |
| storage-1 | nede | :: | 7002 |
| storage-2 | nede | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Jeg tror, at syntaksen for kommandoen er forstÄelig uden forklaring. Men indtil videre er alle vores sessioner i status DOWN. For at de kan skifte til status UP, skal de tÊskes pÄ:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Startede vBMC-instans for domĂŠnet control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Startede vBMC-instans for domĂŠnet storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Startede vBMC-instans for domĂŠnet storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Startede vBMC-instans for domĂŠnet compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Startede vBMC-instans for domĂŠnet compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| DomĂŠnenavn | Status | Adresse | Port |
+-------------+---------+---------+------+
| compute-1 | kĂžrende | :: | 7004 |
| compute-2 | kĂžrende | :: | 7005 |
| control-1 | kĂžrende | :: | 7001 |
| storage-1 | kĂžrende | :: | 7002 |
| storage-2 | kĂžrende | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Og den sidste detalje â det er nĂždvendigt at justere firewall-reglerne (eller slukke den helt):
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
Lad os nu gÄ ind i undercloud og tjekke, at alt fungerer. IP-adressen pÄ vÊrtmaskinen er 192.168.255.200, og vi har tilfÞjet den nÞdvendige pakke ipmitool under forberedelsen til deployment:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Navn Status
----------------------------------------------------
6 dns-server kĂžrende
64 undercloud kĂžrende
65 control-1 kĂžrendeSom du kan se, har vi med succes startet kontrolnoden via vbmc. Lad os nu slukke den og fortsĂŠtte:
[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 Navn Status
----------------------------------------------------
6 dns-server kĂžrende
64 undercloud kĂžrende
- compute-1 slukket
- compute-2 slukket
- control-1 slukket
- storage-1 slukket
- storage-2 slukket
[root@hp-gen9 ~]#Det nÊste skridt er introspektion af noderne, som overcloud vil blive installeret pÄ. For dette skal vi forberede en JSON-fil med beskrivelsen af vores noder. VÊr opmÊrksom pÄ, at i modsÊtning til installation pÄ bare servere er porten, hvor vbmc er kÞrende, angivet for hver af maskinerne.
[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:27BemĂŠrk: PĂ„ kontrolnoden er der to interface, men i dette tilfĂŠlde er det ikke vigtigt, i denne installation er Ă©n nok.
Nu forbereder vi JSON-filen. Vi skal angive MAC-adressen for porten, der skal bruges til provisioning, nodernes parametre, tildele dem navne og angive, hvordan man fÄr adgang til IPMI:
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Nu skal vi forberede billederne til Ironic. For at gĂžre dette downloader vi dem via wget og installerer:
(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 ~]$Uploaderer billeder til undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Billede "overcloud-full-vmlinuz" blev uploadet.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Navn | Disk Format | StĂžrrelse | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | aktiv |
+--------------------------------------+------------------------+-------------+---------+--------+
Billede "overcloud-full-initrd" blev uploadet.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Navn | Disk Format | StĂžrrelse | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | aktiv |
+--------------------------------------+-----------------------+-------------+----------+--------+
Billede "overcloud-full" blev uploadet.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Navn | Disk Format | StĂžrrelse | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | aktiv |
+--------------------------------------+----------------+-------------+------------+--------+
Billede "bm-deploy-kernel" blev uploadet.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Navn | Disk Format | StĂžrrelse | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | aktiv |
+--------------------------------------+------------------+-------------+---------+--------+
Billede "bm-deploy-ramdisk" blev uploadet.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Navn | Disk Format | StĂžrrelse | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | aktiv |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Vi tjekker, at alle billeder er uploadet.
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Navn | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aktiv |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | aktiv |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | aktiv |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | aktiv |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktiv |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$En sidste ting â vi skal tilfĂžje DNS-serveren:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Navn | NetvĂŠrk | 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
+-------------------+-----------------------------------------------------------+
| Felt | VĂŠrdi |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0\/24 |
| created_at | 2020-08-13T20:10:37Z |
| beskrivelse | |
| 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 |
| navn | 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 er forĂŠldet og vil blive fjernet i fremtiden. Brug openstack CLI i stedet.
Opdateret subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nu kan vi give kommandoen til introspektion:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Startede Mistral Workflow tripleo.baremetal.v1.register_or_update. UdfĂžrelses ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Venter pÄ beskeder i kÞen 'tripleo' uden timeout.
5 node(r) blev med succes flyttet til "manageable" tilstand.
Node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 blev med succes registreret.
Node UUID b89a72a3-6bb7-429a-93bc-48393d225838 blev med succes registreret.
Node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e blev med succes registreret.
Node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 blev med succes registreret.
Node UUID 766ab623-464c-423d-a529-d9afb69d1167 blev med succes registreret.
Venter pÄ introspektion for at afslutte...
Startede Mistral Workflow tripleo.baremetal.v1.introspect. UdfĂžrelses ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Venter pÄ beskeder i kÞen 'tripleo' uden timeout.
Introspektion af node b89a72a3-6bb7-429a-93bc-48393d225838 fĂŠrdiggjort. Status:SUCCESS. Fejl:Ingen
Introspektion af node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e fĂŠrdiggjort. Status:SUCCESS. Fejl:Ingen
Introspektion af node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 fĂŠrdiggjort. Status:SUCCESS. Fejl:Ingen
Introspektion af node 766ab623-464c-423d-a529-d9afb69d1167 fĂŠrdiggjort. Status:SUCCESS. Fejl:Ingen
Introspektion af node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 fĂŠrdiggjort. Status:SUCCESS. Fejl:Ingen
5 node(r) blev med succes introspekteret.
Startede Mistral Workflow tripleo.baremetal.v1.provide. UdfĂžrelses ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Venter pÄ beskeder i kÞen 'tripleo' uden timeout.
5 node(r) blev med succes flyttet til "available" tilstand.
(undercloud) [stack@undercloud ~]$Som det fremgÄr af uddataene, er alt afsluttet uden fejl. Lad os tjekke, om alle noder er i tilstanden available:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Navn | Instance UUID | Power State | Provisioning State | Vedligeholdelse |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | Ingen | slukket | available | Falsk |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | Ingen | slukket | available | Falsk |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | Ingen | slukket | available | Falsk |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | Ingen | slukket | available | Falsk |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | Ingen | slukket | available | Falsk |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Hvis noderne er i en anden tilstand, typisk manageable, sÄ er der sket noget galt og du skal kigge i loggen for at finde ud af, hvad der er gÄet galt. VÊr opmÊrksom pÄ, at vi i dette scenarie bruger virtualisering, og der kan vÊre fejl relateret til brugen af virtuelle maskiner eller vbmc.
DernĂŠst skal vi angive, hvilken node der skal udfĂžre hvilken funktion â det vil sige angive profilen, som noden skal deployeres med:
(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 ~]$Vi angiver profilen for hver node:
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Vi tjekker, om vi har gjort alt korrekt:
(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 ~]$Hvis alt er korrekt, giver vi kommandoen til at deploye overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuI en reel installation vil vi naturligvis bruge tilpassede skabeloner, men i vores tilfĂŠlde vil det gĂžre processen meget mere kompliceret, da vi skal forklare hver enkelt ĂŠndring i skabelonen. Som nĂŠvnt tidligere er en simpel installation tilstrĂŠkkelig til at se, hvordan det fungerer.
BemĂŠrk: variablen --libvirt-type qemu er nĂždvendig i dette tilfĂŠlde, da vi vil bruge nested virtualisering. Ellers vil dine virtuelle maskiner ikke kunne starte.
Nu har du cirka en time, mÄske lÊngere (afhÊngigt af hardwarekapaciteten), og alt du kan gÞre er at hÄbe, at efter denne tid vil du se fÞlgende meddelelse:
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 har du nÊsten en fuldstÊndig version af OpenStack, som du kan lÊre pÄ, eksperimentere med osv.
Lad os tjekke, om alt fungerer korrekt. I hjemme-mappen for brugeren stack er der to filer â en stackrc (til styring af undercloud) og den anden overcloudrc (til styring af overcloud). Disse filer skal angives som source, da de indeholder de nĂždvendige oplysninger til autentificering.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Navn | Status | NetvĂŠrk | Billede | Smag |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | AKTIV | ctlplane=192.168.255.15 | overcloud-full | kontrol |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | AKTIV | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | AKTIV | ctlplane=192.168.255.34 | overcloud-full | ceph-lager |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | AKTIV | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | AKTIV | ctlplane=192.168.255.44 | overcloud-full | ceph-lager |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Navn |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | VĂŠrts | TilgĂŠngelig Zonen | Aktiv | Status | BinĂŠr |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | Ingen | :-) | OP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | OP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | OP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | Ingen | :-) | OP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | Ingen | :-) | OP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | Ingen | :-) | OP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$I min installation er der stadig en lille detalje, der mangler â at tilfĂžje en rute pĂ„ controllere, da maskinen, jeg arbejder pĂ„, er i et andet netvĂŠrk. For at gĂžre dette, logger vi ind pĂ„ control-1 med heat-admin-kontoen og tilfĂžjer ruten.
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Sidste login: Fre Aug 14 09:47:40 2020 fra 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.254Nu kan du gĂ„ ind i horisonten. Alle oplysninger â adresser, login og adgangskode â findes i filen /home/stack/overcloudrc. Den endelige skema ser sĂ„ledes ud:
For resten blev maskiners adresser tildelt via DHCP, og som du kan se, tildeles de "hér og dér". Du kan i skabelonen fastkode, hvilken adresse der skal knyttes til hvilken maskine under deployment, hvis det er nÞdvendigt.
Hvordan flyder trafikken mellem virtuelle maskiner?
I denne artikel vil vi se pÄ tre muligheder for trafikforlÞb.
- To maskiner pÄ én hypervisor i det samme L2-netvÊrk.
- To maskiner pÄ forskellige hypervisorer i det samme L2-netvÊrk.
- To maskiner i forskellige netvĂŠrk (routing mellem netvĂŠrk).
Vi vil i nÊste gang se pÄ sager med adgang til den eksterne verden via et eksternt netvÊrk, ved brug af flydende adresser samt distribueret routing, men nu stopper vi ved intern trafik.
Til verificering vil vi samle fĂžlgende skema:
Vi har oprettet 4 virtuelle maskiner â 3 i det samme L2-netvĂŠrk â net-1, og yderligere 1 i netvĂŠrket net-2.
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Navn | Tenant ID | Status | Opgave Status | StrĂžm Status | NetvĂŠrk |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | KĂžrer | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | KĂžrer | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | KĂžrer | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | - | KĂžrer | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Lad os se pÄ, hvilke hypervisorer de oprettede maskiner er placeret pÄ:
(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 ~]$
Maskinerne vm-1 og vm-3 er placeret pÄ compute-0, og maskinerne vm-2 og vm-4 er placeret pÄ node compute-1.
Desuden er der oprettet en virtuel router for muligheden for at rute mellem de angivne netvĂŠrk:
(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 ~]$ Routeren har to virtuelle porte, som fungerer som gateways for netvĂŠrkene:
(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 ~]$ Men fÞr vi ser pÄ, hvordan trafikken bevÊger sig, lad os tage et kig pÄ, hvad vi har i Þjeblikket pÄ kontrolnoden (som ogsÄ er network node) og pÄ compute noden. Lad os starte med compute noden.
[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 ~]$I Ăžjeblikket er der tre OVS-broer pĂ„ noden â br-int, br-tun, br-ex. Som vi kan se, er der et sĂŠt interfaces imellem dem. For nemheds skyld vil vi kortlĂŠgge alle disse interfaces pĂ„ en skitse og se, hvad vi fĂ„r.
PÄ de adresser, hvor VxLAN-tunnelerne er oprettet, kan vi se, at den ene tunnel er oprettet pÄ compute-1 (192.168.255.26), mens den anden tunnel peger mod control-1 (192.168.255.15). Men det mest interessante er, at br-ex ikke har fysiske interfaces, og hvis vi ser pÄ, hvilke flows der er konfigureret, kan vi se, at denne bro i Þjeblikket kun kan droppe trafik.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163 mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Som det fremgÄr af outputtet, er adressen knyttet direkte til den fysiske port og ikke til den virtuelle brointerface.
[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 ~]$ IfĂžlge den fĂžrste regel skal alt, der kommer fra porten phy-br-ex, droppes.
Det vil sige, at denne bro i Þjeblikket ikke kan modtage trafik fra andre kilder end denne interface (forbindelsen til br-int), og ifÞlge droppene har der allerede vÊret BUM-trafik pÄ broen.
Det vil sige, at trafikken kun kan forlade denne node gennem VxLAN-tunnelen og ikke pÄ andre mÄder. Men hvis DVR aktiveres, vil situationen Êndre sig, men vi vil tackle det en anden gang. NÄr man bruger netvÊrksisolering, for eksempel ved hjÊlp af VLANs, vil du have mere end én L3-grÊnseflade i VLAN 0, men flere grÊnseflader. Dog vil VxLAN-trafikken forlade noden pÄ samme mÄde, men ogsÄ indkapslet i et specifikt VLAN.
Vi har forstÄet compute-noden, lad os gÄ videre til control-noden.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (intern)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (intern)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (intern)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Faktisk kan man sige, at alt er det samme, men IP-adressen findes nu ikke pÄ den fysiske grÊnseflade, men pÄ den virtuelle bro. Dette er gjort, fordi denne port er en port, hvorigennem trafikken vil forlade til omverdenen.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163 mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Denne port er tilknyttet broen br-ex, og da der ikke er nogen VLAN-tags pÄ den, fungerer denne port som en trunkport, hvor alle VLANs er tilladt. I Þjeblikket forlader trafikken netvÊrket uden tag, hvilket fremgÄr af VLAN-ID 0 i output ovenfor.
Alt andet er i Ăžjeblikket det samme som compute-noden â de samme broer, de samme tunneler der gĂ„r til de to compute-noder.
Vi vil ikke behandle storage-noder i denne artikel, men for forstĂ„elsens skyld skal det nĂŠvnes, at netvĂŠrksdelen af disse noder er helt banal. I vores tilfĂŠlde er der kun Ă©n fysisk port (eth0) med en IP-adresse tilknyttet, og det er alt. Der er ingen VxLAN-tunneler, tunneling-broer osv. â der er ikke noget OVS overhovedet, da det ikke giver mening. Ved brug af netvĂŠrksisolation vil denne node have to grĂŠnseflader (fysiske porte, bondede eller bare to VLANs â det er ikke vigtigt â det afhĂŠnger af, hvad du Ăžnsker) â en til styring, den anden til trafik (skrive til disk VM, lĂŠse fra disk osv.).
Vi har forstĂ„et, hvad vi har pĂ„ noderne i fravĂŠr af nogen tjenester. Lad os nu starte 4 virtuelle maskiner og se, hvordan den beskrevne skema vil ĂŠndre sig â der skal komme porte, virtuelle rutere osv.
Lige nu ser vores netvÊrk sÄdan ud:
Vi har to virtuelle maskiner pÄ hver compute-node. Lad os tage et kig pÄ, hvordan alt er tilsluttet ved hjÊlp af compute-0 som eksempel.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Navn Status
----------------------------------------------------
1 instance-00000001 kĂžrer
3 instance-00000003 kĂžrer
[heat-admin@overcloud-novacompute-0 ~]$ Maskinen har kun Ă©n virtuel grĂŠnseflade â tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
GrĂŠnseflade Type Kilde Model MAC
-------------------------------------------------------
tap95d96a75-a0 bro qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Denne grÊnseflade ser pÄ linux-broen:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bro navn bro id STP aktiveret interfaces
docker0 8000.0242904c92a8 nej
qbr5bd37136-47 8000.5e4e05841423 nej qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 nej qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Som det fremgĂ„r af outputtet, er der kun to grĂŠnseflader i broen â tap95d96a75-a0 og qvb95d96a75-a0.
Her skal vi lige stoppe op pÄ typerne af virtuelle netvÊrksenheder i OpenStack:
vtap â virtuel grĂŠnseflade tilsluttet til instansen (VM)
qbr â Linux-bro
qvb og qvo â vEth-par tilsluttet til Linux-bro og Open vSwitch-bro
br-int, br-tun, br-vlan â Open vSwitch-broer
patch-, int-br-, phy-br- â Open vSwitch patch-grĂŠnseflader, der forbinder broerne
qg, qr, ha, fg, sg â porte i Open vSwitch, der bruges af virtuelle enheder til at forbinde til OVS
Som du forstÄr, hvis vi har en bro med porten qvb95d96a75-a0, som er et vEth-par, sÄ mÄ der et andet sted vÊre dens modpart, som logisk bÞr hedde qvo95d96a75-a0. Lad os kigge pÄ, hvilke porte der findes pÄ OVS.
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (intern)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (intern)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (intern)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Som vi ser, er porten i br-int. Br-int fungerer som en switch, der terminerer portene for virtuelle maskiner. Udover qvo95d96a75-a0 kan vi i outputtet se porten qvo5bd37136-47. Dette er porten til den anden virtuelle maskine. SÄ vores diagram ser nu sÄdan ud:
SpĂžrgsmĂ„let, der straks bĂžr interessere den opmĂŠrksomme lĂŠser, er: hvorfor er der en linux bridge mellem porten for den virtuelle maskine og porten OVS? Ă
rsagen er, at der anvendes sikkerhedsgrupper til at beskytte maskinen, som i realiteten er iptables. OVS arbejder ikke med iptables, derfor blev en sĂ„dan "lĂžsning" opfundet. Men det er ved at vĂŠre forĂŠldet â i de nye versioner kommer conntrack til at erstatte det.
SÄledes ser diagrammet i sidste ende sÄdan ud:
To maskiner pÄ én hypervisor i det samme L2-netvÊrk.
Da begge VM'er befinder sig i det samme L2-netvÊrk og pÄ den samme hypervisor, vil trafikken mellem dem logisk set gÄ lokalt gennem br-int, da begge maskiner vil vÊre i den samme VLAN:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ To maskiner pÄ forskellige hypervisorer i det samme L2-netvÊrk.
Lad os nu se pĂ„, hvordan trafikken gĂ„r mellem to maskiner i det samme L2-netvĂŠrk, men som er placeret pĂ„ forskellige hypervisorer. Ărligt talt vil der ikke ĂŠndre sig meget; blot vil trafikken mellem hypervisorerne gĂ„ gennem en vxlan-tunnel. Lad os se pĂ„ et eksempel.
Adresserne for de virtuelle maskiner, som vi skal overvÄge trafikken mellem:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
GrĂŠnseflade Type Kilde Model MAC
-------------------------------------------------------
tap95d96a75-a0 bro 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 ~]$ Vi ser pÄ forwarding-tabellen i br-int pÄ 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 ~]Trafikken skal gĂ„ til port 2 â lad os se, hvilken port det er:
[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 ~]$Dette er patch-tun â det vil sige et interface i br-tun. Lad os se, hvad der sker med pakken i br-tun:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Pakken pakkes ind i VxLAN og sendes til port 2. Lad os se, hvor port 2 fĂžrer hen:
[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 ~]$Dette er en vxlan tunnel pÄ 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 ~]$GĂ„ til compute-1 og se, hvad der sker med pakken:
[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'en findes i forwarding-tabellen br-int pÄ compute-1, og som det ses i ovenstÄende output, er den synlig gennem port 2, som er porten mod 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:46Lad os sÄ se, hvad der er i br-int pÄ compute-1, der er MAC'en til destination:
[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 ~]$ Det vil sige, at den modtagende pakke vil blive sendt til port 3, hvor den virtuelle maskine instance-00000003 er placeret.
Hele skÞnheden ved at implementere OpenStack for at studere pÄ en virtuel infrastruktur er, at vi uden problemer kan fange trafikken mellem hypervisorerne og se, hvad der sker med den. Det er netop, hvad vi vil gÞre nu, vi vil kÞre tcpdump pÄ vnet-porten mod compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: lytter pÄ 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*******************Den fÞrste linje viser, at pakken fra adressen 10.0.1.85 gÄr til adressen 10.0.1.88 (ICMP trafik), og den er pakket ind i en VxLAN pakke med vni 22. Pakken kommer fra vÊrten 192.168.255.19 (compute-0) og gÄr til vÊrten 192.168.255.26 (compute-1). Vi kan tjekke, at VNI'en svarer til den, der er angivet i ovs.
Lad os vende tilbage til denne linje actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 â det er vni i hexadecimalt. Lad os konvertere dette tal til decimalt:
16 = 6*16^0+1*16^1 = 6+16 = 22Det betyder, at vni'en er korrekt.
Den anden linje viser den omvendte trafik, og der er ikke meget at forklare, da alt er klart.
To maskiner i forskellige netvĂŠrk (routing mellem netvĂŠrk)
Den sidste sag for i dag â det er routing mellem netvĂŠrk inde i et projekt ved hjĂŠlp af en virtuel router. Vi betragter en situation uden DVR (den vil vi tage i en anden artikel), sĂ„ routing sker pĂ„ network noden. I vores tilfĂŠlde er network noden ikke udskilt som en separat enhed og er placeret pĂ„ control noden.
Lad os fĂžrst se, om routingen fungerer:
$ 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-statistik ---
2 pakker sendt, 2 pakker modtaget, 0% pakke tab
round-trip min/avg/max = 3.832/5.779/7.727 msDa pakken i dette tilfÊlde skal gÄ til gatewayen og blive routet der, skal vi finde MAC-adressen for gatewayen. For at gÞre dette ser vi pÄ ARP-tabellen i instansen:
$ 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 eth0Lad os se, hvor trafikken med destination (10.0.1.254) fa:16:3e:c4:64:70 skal sendes hen.
[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 ~]$ Lad os se, hvor port 2 fĂžrer hen:
[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 ~]$ Det giver mening, trafikken gÄr til br-tun. Lad os se, hvilken vxlan-tunnel den vil blive indkapslet i:
[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 ~]$ Den tredje port er en 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 ~]$ Som ser pÄ kontrolnoden:
[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 ~]$ Trafikken er nÄet frem til kontrolnoden, sÄ vi skal skifte til den og se, hvordan routing foregÄr.
Som du husker, sĂ„ sĂ„ kontrolnoden ud prĂŠcis som compute-noden â de samme tre broere, kun med en fysisk port pĂ„ br-ex, som noden kunne sende trafik ud af. Oprettelsen af instanser ĂŠndrede konfigurationen pĂ„ compute-noderne â der blev tilfĂžjet linux bridges, iptables og interfacer til noderne. Oprettelsen af netvĂŠrk og den virtuelle router satte ogsĂ„ sit prĂŠg pĂ„ kontrolnodens konfiguration.
SÄ det er tydeligt, at mac-adressen for gateway skal vÊre i forwarding-tabellen pÄ br-int pÄ kontrolnoden. Lad os tjekke, om den er der, og hvor den peger hen:
[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 ~]$ Mac-adressen er synlig fra port qr-0c52b15f-8f. Hvis man vender tilbage til listen over virtuelle porte i Openstack, sÄ bruges denne type port til at forbinde forskellige virtuelle enheder til OVS. Mere prÊcist, qr er porten mod den virtuelle router, som prÊsenteres i form af et namespace.
Lad os se, hvilke namespaces der er pÄ serveren:
[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 ~]$ Der er tre instanser i alt. Men ud fra navnene kan man gÊtte, hvad formÄlet med hver enkelt er. Vi vender tilbage til instanserne med ID 0 og 1 senere; lige nu er vi interesseret i namespace 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 ~]$ I dette namespace er der to interne, som vi har oprettet tidligere. Begge virtuelle porte er blevet tilfĂžjet til br-int. Lad os tjekke MAC-adressen for porten qr-0c52b15f-8f, da trafikken, ifĂžlge destinations MAC-adressen, er kommet til denne grĂŠnseflade.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163 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
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 ~]$ Det vil sige, at i dette tilfĂŠlde fungerer alt efter standardroutingens regler. Da trafikken er beregnet til vĂŠrten 10.0.2.8, skal den sendes gennem den anden grĂŠnseflade qr-92fa49b5-54 og ud gennem VXLAN-tunnelen til compute-noden:
[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 ~]$ Alt hĂŠnger sammen, der er ingen overraskelser. Lad os se, hvor MAC-adressen for vĂŠrten 10.0.2.8 ses i 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 ~]$ Som det skal vÊre, gÄr trafikken til br-tun. Lad os se, hvilken tunnel trafikken vil gÄ videre til:
[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 ~]$ Traffic is going through the tunnel to compute-1. And on compute-1, everything is simple â from br-tun, the packet goes to br-int and from there to the virtual machine's 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 ~]$ Let's check if this is indeed the correct interface:
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$ We have traced the entire path of the packet. I believe you noticed that the traffic was going through different vxlan tunnels and exiting with different VNIs. Letâs see what these VNIs are, then we will collect a dump on the control node's port and confirm that the traffic is indeed flowing as described above.
So, the tunnel to compute-0 has the following actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Let's convert 0x16 into decimal:
0x16 = 6*16^0+1*16^1 = 6+16 = 22The tunnel to compute-1 has the following VNI: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Let's convert 0x63 into decimal:
0x63 = 3*16^0+6*16^1 = 3+96 = 99And now let's take a look at the dump:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: lytter pÄ vnet4, link-type EN10MB (Ethernet), opfangst stÞrrelse 262144 bytes
*****************udladt*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), lĂŠngde 134)
192.168.255.19.41591 > 192.168.255.15.4789: [ingen cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), lĂŠngde 84)
10.0.1.85 > 10.0.2.8: ICMP echo-request, id 5378, sekvens 9, lĂŠngde 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), lĂŠngde 134)
192.168.255.15.38983 > 192.168.255.26.4789: [ingen cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), lĂŠngde 84)
10.0.1.85 > 10.0.2.8: ICMP echo-request, id 5378, sekvens 9, lĂŠngde 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), lĂŠngde 134)
192.168.255.26.42588 > 192.168.255.15.4789: [ingen cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), lĂŠngde 84)
10.0.2.8 > 10.0.1.85: ICMP echo-svar, id 5378, sekvens 9, lĂŠngde 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), lĂŠngde 134)
192.168.255.15.38983 > 192.168.255.19.4789: [ingen cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), lĂŠngde 84)
10.0.2.8 > 10.0.1.85: ICMP echo-svar, id 5378, sekvens 9, lĂŠngde 64
*****************udladt*******************Den fÞrste pakke er en vxlan-pakke fra vÊrt 192.168.255.19 (compute-0) til vÊrt 192.168.255.15 (control-1) med vni 22, indeni hvilken der er pakket en ICMP-pakke fra vÊrt 10.0.1.85 til vÊrt 10.0.2.8. Som vi beregnede tidligere, svarer vni til det, vi sÄ i udskrifterne.
Den anden pakke er en vxlan-pakke fra vÊrt 192.168.255.15 (control-1) til vÊrt 192.168.255.26 (compute-1) med vni 99, indeni hvilken der er pakket en ICMP-pakke fra vÊrt 10.0.1.85 til vÊrt 10.0.2.8. Som vi beregnede tidligere, svarer vni til det, vi sÄ i udskrifterne.
De to nĂŠste pakker er den omvendte trafik fra 10.0.2.8 til 10.0.1.85.
SÄ i sidste ende har vi fÄet dette diagram af kontrolnoden:
Ser ud til at vĂŠre alt? Vi glemte to namespaces:
[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 ~]$ Som vi nĂŠvnte om arkitekturen af den cloud-baserede platform â ville det vĂŠre godt, hvis maskinerne fik adresser automatisk fra DHCP-serveren. Det er de to DHCP-servere til vores to netvĂŠrk 10.0.1.0/24 og 10.0.2.0/24.
Lad os kontrollere, at det er tilfĂŠldet. I denne namespace er der kun Ă©n adresse â 10.0.1.1 â adressen pĂ„ selve DHCP-serveren, og den er ogsĂ„ inkluderet i br-int:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163 mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Lad os se, om der er processer med navnet qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 pÄ kontrolnoden:
[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 ~]$ Der er en sÄdan proces, og baseret pÄ oplysningerne fra ovenstÄende output kan vi f.eks. se, hvad vi har til leje i Þjeblikket:
[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 ~]$Resultatet er, at vi fÄr et sÊt tjenester pÄ kontrolnoden:
Og husk â det er kun â 4 maskiner, 2 interne netvĂŠrk og en virtuel router⊠Vi har ikke eksterne netvĂŠrk lige nu, en masse forskellige projekter, hver med sine egne netvĂŠrk (der overlapper hinanden), og vores distribuerede router er slukket, og i testmiljĂžet var der i sidste ende kun Ă©n kontrolnode (for hĂžj tilgĂŠngelighed skal der vĂŠre et quorum pĂ„ tre noder). Det er logisk, at det i kommercielle sammenhĂŠnge er âlidtâ mere komplekst, men med dette enkle eksempel forstĂ„r vi, hvordan det skal fungere â om du har 3 eller 300 namespaces er selvfĂžlgelig vigtigt, men set fra hele konstruktionens synspunkt ĂŠndrer det sig ikke meget⊠i det mindste indtil du tilslutter en eller anden leverandĂžrs SDN. Men det er en helt anden historie.
Jeg hĂ„ber, det var interessant. Hvis der er bemĂŠrkninger/tilfĂžjelser, eller hvis jeg har lĂžjet Ă„benlyst et eller andet sted (jeg er et menneske, og min mening vil altid vĂŠre subjektiv) â skriv, hvad der skal rettes/tilfĂžjes â vi retter/tilfĂžjer alt.
Som afslutning vil jeg gerne sige et par ord om sammenligning af OpenStack (bĂ„de vanilje- og leverandĂžrspecifik) med cloud-lĂžsningen fra VMWare â jeg har fĂ„et dette spĂžrgsmĂ„l alt for mange gange de seneste par Ă„r, og ĂŠrligt talt er jeg blevet trĂŠt af det, men alligevel. Efter min mening er det meget svĂŠrt at sammenligne disse to lĂžsninger, men det kan klart siges, at der er ulemper ved begge lĂžsninger, og nĂ„r man vĂŠlger en lĂžsning, skal man veje alle for og imod.
Hvis OpenStack er en community-drevet lĂžsning, har VMWare ret til at gĂžre prĂŠcist, hvad de vil (lĂŠs â hvad der gavner dem), og det er logisk â for det er en kommerciel virksomhed, der er vant til at tjene penge pĂ„ sine kunder. Men her er der et stort og fedt MEN â du kan forlade OpenStack, for eksempel fra Nokia, og skifte til en lĂžsning fra for eksempel Juniper (Contrail Cloud) uden mange problemer, men det vil du nok ikke kunne gĂžre med VMWare. For mig fremstĂ„r disse to lĂžsninger sĂ„ledes â OpenStack (leverandĂžrspecifik) er et enkelt bur, som de sĂŠtter dig i, men du har nĂžglen og kan gĂ„ ud nĂ„r som helst. VMWare â det er et gyldent bur, nĂžglen til buret tilhĂžrer ejer, og den vil koste dig meget.
Jeg anbefaler ikke det fĂžrste produkt eller det andet â du vĂŠlger det, du har brug for. Men hvis jeg skulle vĂŠlge, ville jeg vĂŠlge begge lĂžsninger â VMWare til IT-skyen (smĂ„ belastninger, nem styring), OpenStack fra en eller anden leverandĂžr (Nokia og Juniper tilbyder nogle ganske gode nĂžglefĂŠrdige lĂžsninger) â til Telecom-skyen. Jeg ville ikke bruge OpenStack til ren IT â det er som at skyde med kanoner pĂ„ spurve, men jeg ser ingen andre imod at bruge det udover overflĂždighed. Men at bruge VMWare i telekom â det er som at transportere grus med en Ford Raptor â ser flot ud, men chauffĂžren skal lave 10 ture i stedet for Ă©n.
Efter min mening er den stĂžrste ulempe ved VMWare dens fuldstĂŠndige lukkethed â firmaet vil ikke give dig nogen information om, hvordan deres f.eks. vSAN fungerer, eller hvad der er i kernen af hypervisoren â det er ganske enkelt ikke rentabelt for dem â det vil sige, at du aldrig vil blive ekspert i VMWare â uden stĂžtte fra leverandĂžren er du dĂžmt (jeg mĂžder ofte VMWare-eksperter, der bliver sat i vanskeligheder af banale spĂžrgsmĂ„l). For mig er VMWare som at kĂžbe en bil med et lĂ„st motorhjelm â ja, mĂ„ske har du specialister, der kan udskifte timingremmen, men kun den, der solgte dig lĂžsningen kan Ă„bne motorhjelmen. Personligt kan jeg ikke lide lĂžsninger, som jeg ikke kan komme ind i. Du vil mĂ„ske sige, at du muligvis ikke behĂžver at kigge under motorhjelmen. Ja, det er muligt, men jeg ser pĂ„ dig, nĂ„r du skal sĂŠtte en stor funktion op i skyen bestĂ„ende af 20-30 virtuelle maskiner, 40-50 netvĂŠrk, hvoraf halvdelen Ăžnsker at komme ud, og den anden halvdel beder om SR-IOV acceleration, ellers skal du have endnu et par dusin sĂ„danne maskiner â ellers er der ikke nok ydeevne.
Der findes andre synspunkter, sĂ„ det er kun dig, der kan beslutte, hvad du vĂŠlger, og vigtigst af alt â det er dig, der skal stĂ„ til ansvar for dit valg. Dette er blot min mening â som en person, der har set og rĂžrt ved mindst 4 produkter â Nokia, Juniper, Red Hat og VMWare. SĂ„ jeg har noget at sammenligne med.
Kilde: habr.com
