Cloud computing trænger dybere og dybere ind i vores liv, og der er sandsynligvis ikke en eneste person, der ikke har brugt nogle cloud-tjenester mindst én gang. Men hvad skyen er, og hvordan den fungerer, er noget, som de fleste ved, selv på idéniveau. 5G er allerede ved at blive en realitet, og telekommunikationsinfrastrukturen er begyndt at bevæge sig fra polbaserede løsninger til cloudløsninger, ligesom den er bevæget sig fra fuldt hardwarebaserede løsninger til virtualiserede "søjler".
I dag vil vi tale om den indre verden af cloud-infrastruktur, især vil vi analysere det grundlæggende i netværksdelen.
Hvad er en sky? Den samme virtualisering - profilvisning?
Et mere end logisk spørgsmål. Nej, dette er ikke virtualisering, selvom det ikke var uden. Lad os overveje to definitioner:
Cloud computing (herefter benævnt Cloud) — er en model til at give brugervenlig adgang til distribuerede computerressourcer, der skal implementeres og lanceres efter behov med minimal mulig latenstid og minimale omkostninger fra tjenesteudbyderens side.
Virtualisering — dette er muligheden for at opdele en fysisk enhed (for eksempel en server) i flere virtuelle, og derved øge udnyttelsen af ressourcer (for eksempel havde du 3 servere belastet med 25-30 procent, efter virtualisering får du 1 server belastet med 80-90 procent). Naturligvis bruger virtualisering nogle ressourcer - du skal fodre hypervisoren, men som praksis har vist, er spillet pengene værd. Det ideelle eksempel på virtualisering er VMWare, som er fantastisk til at forberede virtuelle maskiner, eller for eksempel KVM, som jeg bedre kan lide, men det er en smagssag.
Vi bruger virtualisering uden at være klar over det, og selv hardware-routere bruger allerede virtualisering - for eksempel i de nyeste versioner af JunOS installeres operativsystemet som en virtuel maskine oven på en realtids Linux-distribution (Wind River 9). Men virtualisering er ikke skyen, men skyen kan ikke eksistere uden virtualisering.
Virtualisering er en af byggestenene, som skyen er bygget på.
Det vil ikke fungere at oprette en cloud ved blot at samle flere hypervisorer i ét L2-domæne, tilføje et par Yaml-playbooks til automatisk registrering af vlans via en eller anden Ansible og derefter sætte alt dette på som en slags orkestreringssystem til automatisk oprettelse af virtuelle maskiner. Mere præcist vil det nok gå, men den resulterende Frankenstein er ikke den sky, vi har brug for, selvom det afhænger af personen, måske er det for nogen den ultimative drøm. Desuden, hvis vi tager den samme Openstack, er det i bund og grund stadig Frankenstein, men nå, lad os ikke tale om det for nu.
Men jeg forstår, at det ud fra den ovenfor præsenterede definition ikke er helt klart, hvad der egentlig kan kaldes en sky.
Derfor oplister et dokument fra NIST (National Institute of Standards and Technology) 5 nøgleegenskaber, som en cloud-infrastruktur bør have:
Yder service efter anmodning. Brugeren skal have fri adgang til de computerressourcer, der er tildelt ham (såsom netværk, virtuelle diske, hukommelse, processorkerner osv.), og disse ressourcer skal stilles til rådighed automatisk - det vil sige uden indgriben fra tjenesteudbyderen.
Bred tilgængelighed af service. Adgang til ressourcer skal sikres via standardmekanismer, der muliggør brug af både standard-pc'er, tynde klienter og mobile enheder.
Samling af ressourcer. Ressourcepuljer skal levere ressourcer til flere klienter samtidigt, samtidig med at det sikres, at klienterne er isolerede og ikke forstyrrer hinanden eller konkurrerer om ressourcer. Netværk er også inkluderet i poolene, hvilket indikerer muligheden for at bruge overlappende adressering. Puljer skal understøtte skalering efter behov. Brugen af pools muliggør det nødvendige niveau af ressourcefejltolerance og abstraktion af fysiske og virtuelle ressourcer - tjenestemodtageren får simpelthen forsynet det sæt af ressourcer, som han anmoder om (hvor disse ressourcer fysisk er placeret, på hvor mange servere og switche - klienten er ligeglad). Det er dog nødvendigt at tage højde for, at udbyderen skal sikre gennemsigtig reservation af disse ressourcer.
Hurtig tilpasning til forskellige forhold. Tjenesterne skal være fleksible - hurtig tilvejebringelse af ressourcer, omfordeling af disse, tilføjelse eller reduktion af ressourcer efter kundens anmodning, og kunden skal have en følelse af, at cloud-ressourcerne er uendelige. For at lette forståelsen ser du for eksempel ikke en advarsel om, at du har mistet diskplads i Apple iCloud, fordi harddisken på serveren er gået i stykker, og diske går i stykker. Desuden er mulighederne for denne tjeneste fra din side praktisk talt ubegrænsede - hvis du har brug for 2 TB - intet problem, du betaler og får det. Et lignende eksempel kan gives med Google.Drive eller Yandex.Disk.
Mulighed for at måle den leverede service. Cloud-systemer bør automatisk kontrollere og optimere de forbrugte ressourcer, og disse mekanismer bør være transparente for både brugeren og tjenesteudbyderen. Det betyder, at du altid kan tjekke, hvor mange ressourcer du og dine kunder forbruger.
Det er værd at overveje, at disse krav primært er krav til en offentlig cloud, så for en privat cloud (dvs. en cloud, der er lanceret til en virksomheds interne behov) kan disse krav justeres en smule. De skal dog stadig implementeres, ellers får vi ikke alle fordelene ved cloud computing.
Hvorfor har vi brug for en sky?
Men enhver ny eller eksisterende teknologi, enhver ny protokol, er skabt til et eller andet (nå, bortset fra RIP-ng, selvfølgelig). En protokol for en protokols skyld er ikke til nogen nytte (undtagen RIP-ng, selvfølgelig). Det er logisk, at skyen er skabt for at yde en eller anden service til brugeren/klienten. Vi kender alle mindst et par cloud-tjenester, såsom Dropbox eller Google.Docs, og jeg tror, at de fleste af os bruger dem med succes - for eksempel blev denne artikel skrevet ved hjælp af Google.Docs cloud-tjenesten. Men de cloud-tjenester, vi kender, er kun en del af cloudens muligheder – mere præcist er de kun SaaS-lignende tjenester. Vi kan tilbyde cloud-tjenester på tre måder: som SaaS, PaaS eller IaaS. Hvilken service du har brug for, afhænger af dine ønsker og muligheder.
Lad os overveje hver enkelt i rækkefølge:
Software som en service (SaaS) — er en model til at levere en komplet service til klienten, for eksempel en mailtjeneste som Yandex.Mail eller Gmail. I denne model for servicelevering gør du som klient intet andet end at bruge tjenesten - det vil sige, at du ikke behøver at tænke på opsætning af tjenesten, dens fejltolerance eller backup. Det vigtigste er ikke at kompromittere din adgangskode; Udbyderen af denne tjeneste vil gøre alt andet for dig. Fra tjenesteudbyderens synspunkt er denne fuldt ansvarlig for hele tjenesten - fra serverhardware og værtsoperativsystemer til database- og softwareindstillinger.
Platform som en service (PaaS) — Når denne model anvendes, giver tjenesteudbyderen klienten en skabelon til en tjeneste, lad os f.eks. tage en webserver. Tjenesteudbyderen leverede en virtuel server til klienten (faktisk et sæt ressourcer såsom RAM/CPU/lager/netværk osv.) og installerede endda operativsystemet og den nødvendige software på denne server, men klienten konfigurerer alt dette selv, og klienten er allerede ansvarlig for tjenestens ydeevne. Tjenesteudbyderen er, som i det foregående tilfælde, ansvarlig for driften af det fysiske udstyr, hypervisorer, selve den virtuelle maskine, dens netværkstilgængelighed osv., men selve tjenesten er ikke længere dens ansvarsområde.
Infrastructure as a Service (IaaS) — denne tilgang er allerede mere interessant, faktisk leverer tjenesteudbyderen klienten en komplet virtualiseret infrastruktur — det vil sige et sæt (pulje) af ressourcer, såsom CPU-kerner, RAM, netværk osv. Alt andet er klientens sag — hvad klienten ønsker at gøre med disse ressourcer inden for den pulje (kvote), der er tildelt ham, er ikke særlig vigtigt for udbyderen. Hvis en klient ønsker at oprette sin egen vEPC eller endda oprette en minioperatør og levere kommunikationstjenester, er der intet problem – bare gør det. I et sådant scenarie er tjenesteudbyderen ansvarlig for levering af ressourcer, deres fejltolerance og tilgængelighed, samt det operativsystem, der tillader, at disse ressourcer samles og leveres til klienten med mulighed for at øge eller mindske ressourcerne når som helst efter klientens anmodning. Klienten konfigurerer selv alle virtuelle maskiner og andet tilbehør via selvbetjeningsportalen og konsollen, inklusive registrering af netværk (undtagen eksterne netværk).
Hvad er OpenStack?
I alle tre muligheder har tjenesteudbyderen brug for et operativsystem, der muliggør oprettelse af en cloud-infrastruktur. Faktisk er der med SaaS ikke kun én afdeling, der er ansvarlig for hele stakken af teknologier - der er en afdeling, der er ansvarlig for infrastrukturen - det vil sige, at den leverer IaaS til en anden afdeling, denne afdeling leverer SaaS til klienten. OpenStack er et af de cloud-operativsystemer, der giver dig mulighed for at samle en række switche, servere og lagringssystemer i en enkelt ressourcepulje, opdele denne fælles pulje i underpuljer (lejere) og levere disse ressourcer til klienter over netværket.
OpenStack — er et cloud-operativsystem, der tillader kontrol over store puljer af computerressourcer, datalagring og netværksressourcer, der leveres og administreres via en API ved hjælp af standardgodkendelsesmekanismer.
Med andre ord er det et sæt gratis softwareprojekter, der er designet til at skabe cloud-tjenester (både offentlige og private) - det vil sige et sæt værktøjer, der giver dig mulighed for at kombinere server- og switching-udstyr i en enkelt pulje af ressourcer, administrere disse ressourcer og dermed give det nødvendige niveau af fejltolerance.
I skrivende stund ser OpenStack-strukturen således ud:
Billedet er taget fra
Hver af komponenterne i OpenStack udfører en specifik funktion. Denne distribuerede arkitektur giver dig mulighed for at inkludere det sæt af funktionelle komponenter, du har brug for, i din løsning. Nogle komponenter er dog rodkomponenter, og fjernelse af dem vil føre til fuldstændig eller delvis ubrugelighed af løsningen som helhed. Sådanne komponenter omfatter:
- Hovedmenu — Webbaseret brugergrænseflade til administration af OpenStack-tjenester
- Keystone — en centraliseret identitetstjeneste, der leverer godkendelses- og autorisationsfunktionalitet til andre tjenester samt administrerer brugerlegitimationsoplysninger og -roller.
- neutron — en netværkstjeneste, der leverer forbindelse mellem grænseflader for forskellige OpenStack-tjenester (herunder forbindelse mellem VM'er og deres adgang til omverdenen)
- Cinder - giver adgang til bloklagring for virtuelle maskiner
- Nova - styring af virtuel maskines livscyklus
- Blik — arkiv over virtuelle maskinbilleder og snapshots
- Swift - giver adgang til objektlagring
- Loftmåler — en tjeneste, der giver mulighed for at indsamle telemetri og måle tilgængelige og forbrugte ressourcer
- Heat — skabelonbaseret orkestrering til automatisk oprettelse og provisionering af ressourcer
En komplet liste over alle projekter og deres formål kan ses .
Hver OpenStack-komponent er en tjeneste, der er ansvarlig for en specifik funktion og leverer en API til at administrere denne funktion og til at tjenesten kan interagere med andre cloud-operativsystemtjenester for at skabe en samlet infrastruktur. For eksempel tilbyder Nova administration af computerressourcer og en API til adgang til konfigurationen af disse ressourcer, Glance leverer billedadministration og en API til administration af dem, Cinder leverer bloklagring og en API til administration af det osv. Alle funktioner er meget tæt forbundet.
Men hvis man tænker over det, repræsenterer alle tjenester, der lanceres i OpenStack, i sidste ende en slags virtuel maskine (eller container), der er forbundet til netværket. Spørgsmålet opstår: hvorfor har vi brug for så mange elementer?
Lad os gennemgå algoritmen til at oprette en virtuel maskine og forbinde den til netværket og persistent storage i Openstack.
- Når du opretter en anmodning om at oprette en maskine, uanset om det er en anmodning via Horizon (Dashboard) eller en anmodning via CLI, er det første, der sker, at Keystone godkender din anmodning - om du kan oprette en maskine, om du har eller har ret til at bruge dette netværk, om dit projekt har tilstrækkelig kvote osv.
- Keystone godkender din anmodning og genererer et godkendelsestoken i svarmeddelelsen, som vil blive brugt senere. Efter at have modtaget et svar fra Keystone, sendes anmodningen til Nova (nova api).
- Nova-api kontrollerer gyldigheden af din anmodning ved at kontakte Keystone ved hjælp af det tidligere genererede godkendelsestoken.
- Keystone udfører godkendelse og giver oplysninger om tilladelser og begrænsninger baseret på dette godkendelsestoken.
- Nova-api opretter en post over den nye VM i nova-database og sender anmodningen om at oprette maskinen til nova-scheduler.
- Nova-scheduler vælger den vært (computernode), hvor den virtuelle maskine skal implementeres, baseret på de angivne parametre, vægte og zoner. En registrering af dette og VM-ID'et skrives til nova-databasen.
- Dernæst beder nova-scheduler nova-compute om at implementere en instans. Nova-compute kontakter nova-conductor for at få information om maskinens parametre (nova-conductor er et nova-element, der fungerer som en proxyserver mellem nova-database og nova-compute, hvilket begrænser antallet af anmodninger til nova-database for at undgå problemer med databasekonsistens og reducere belastningen).
- Nova-conductor henter de ønskede oplysninger fra nova-databasen og sender dem til nova-compute.
- Dernæst kalder nova-compute glance for at hente billed-ID'et. Glace validerer anmodningen mod Keystone og returnerer de anmodede oplysninger.
- Nova-compute kontakter neutron for at indhente information om netværksparametre. Ligesom Glance validerer Neutron anmodningen i Keystone, opretter derefter en post i databasen (port-ID osv.), opretter en anmodning om at oprette porten og returnerer de anmodede oplysninger til nova-compute.
- Nova-compute kontakter cinder med en anmodning om at allokere et volumen til den virtuelle maskine. I lighed med Glance validerer cider anmodningen i Keystone, opretter en anmodning om at oprette et volumen og returnerer de anmodede oplysninger.
- Nova-compute sender en anmodning til libvirt om at installere en virtuel maskine med de givne parametre.
Faktisk forvandles en tilsyneladende simpel operation for at oprette en simpel virtuel maskine til en hvirvelvind af API-kald mellem elementer i cloudplatformen. Desuden, som du kan se, består selv de tidligere udpegede tjenester også af mindre komponenter, mellem hvilke der opstår interaktion. Oprettelse af en maskine er kun en lille del af, hvad en cloudplatform giver dig mulighed for at gøre - der er en tjeneste, der er ansvarlig for trafikbalancering, en tjeneste, der er ansvarlig for bloklagring, en tjeneste, der er ansvarlig for DNS, en tjeneste, der er ansvarlig for klargøring af bare metal-servere osv. Clouden giver dig mulighed for at behandle dine virtuelle maskiner som en flok får (i modsætning til virtualisering). Hvis der sker noget med din maskine i et virtuelt miljø, gendanner du den fra sikkerhedskopier osv., men cloud-applikationer er bygget på en sådan måde, at den virtuelle maskine ikke spiller en så vigtig rolle - den virtuelle maskine "dør" - intet problem - en ny maskine oprettes simpelthen baseret på skabelonen, og som man siger, bemærker truppen ikke tabet af en soldat. Dette kræver naturligvis tilstedeværelsen af orkestreringsmekanismer - ved hjælp af Heat-skabeloner kan du nemt implementere en kompleks funktion bestående af snesevis af netværk og virtuelle maskiner.
Det er altid værd at huske på, at der ikke findes en cloud-infrastruktur uden et netværk - hvert element interagerer med andre elementer via netværket på den ene eller anden måde. Derudover har skyen et fuldstændig ikke-statisk netværk. Naturligvis er underliggende netværk stadig mere eller mindre statisk - nye noder og switche tilføjes ikke hver dag, men overlay-komponenten kan og vil uundgåeligt ændre sig konstant - nye netværk vil blive tilføjet eller fjernet, nye virtuelle maskiner vil dukke op, og gamle vil dø. Og som du husker fra definitionen af cloud-teknologi, der blev givet i begyndelsen af artiklen, bør ressourcer allokeres til brugeren automatisk og med mindst mulig (eller endnu bedre, uden) indgriben fra tjenesteudbyderen. Det vil sige, at den type netværksressourceforsyning, der i øjeblikket findes i form af en frontend i form af din personlige konto, der er tilgængelig via http/https, og den vagthavende netværksingeniør Vasily som backend, ikke er en sky, selvom Vasily har otte hænder.
Neutron, som en netværkstjeneste, leverer en API til administration af netværksdelen af cloudinfrastrukturen. Tjenesten leverer funktionaliteten og administrationen af netværksdelen af Openstack ved at tilbyde et abstraktionslag kaldet Network-as-a-Service (NaaS). Det vil sige, at netværket er den samme virtuelle måleenhed som for eksempel virtuelle CPU-kerner eller RAM-volumen.
Men før vi går videre til arkitekturen af netværksdelen af OpenStack, lad os se på, hvordan dette netværk fungerer i OpenStack, og hvorfor netværket er en vigtig og integreret del af skyen.
Så vi har to RØDE klient-VM'er og to GRØNNE klient-VM'er. Lad os antage, at disse maskiner er placeret på to hypervisorer på denne måde:
I øjeblikket er dette blot virtualisering af 4 servere og intet mere, da alt, hvad vi indtil videre har gjort, er at virtualisere 4 servere og placere dem på to fysiske servere. Desuden er de ikke engang forbundet til netværket endnu.
For at få en sky skal vi tilføje flere komponenter. Først virtualiserer vi netværksdelen - vi skal forbinde disse 4 maskiner parvis, og klienterne ønsker en L2-forbindelse. Du kan selvfølgelig bruge en switch og oprette en trunk i dens retning og ordne alt ved hjælp af Linux bridge eller, for mere avancerede brugere, openvswitch (vi vender tilbage til det senere). Men der kan være mange netværk, og konstant at skulle presse L2 gennem en switch er ikke den bedste idé - forskellige afdelinger, en servicedesk, måneders venten på at anmodningen bliver opfyldt, uger med fejlfinding - i den moderne verden fungerer denne tilgang ikke længere. Og jo før en virksomhed forstår dette, jo lettere er det for den at komme videre. Derfor vil vi mellem hypervisorerne allokere et L3-netværk, hvorigennem vores virtuelle maskiner vil kommunikere, og oven på dette L3-netværk vil vi bygge virtuelle overlay L2-netværk, hvor trafikken fra vores virtuelle maskiner vil køre. GRE, Geneve eller VxLAN kan bruges som indkapsling. Lad os for nu fokusere på den sidste, selvom den ikke er særlig vigtig.
Vi er nødt til at placere VTEP et sted (jeg håber, at alle er bekendt med VxLAN-terminologien). Da L3-netværket kommer ud fra serverne, er der intet, der forhindrer os i at placere VTEP på selve serverne, og OVS (OpenvSwitch) er rigtig god til at gøre dette. Som følge heraf fik vi følgende design:
Da trafikken mellem VM'er skal adskilles, vil porte mod virtuelle maskiner have forskellige VLAN-numre. Tagnummeret spiller kun en rolle inden for én virtuel switch, da vi kan fjerne det uden problemer ved indkapsling i VxLAN, da vi vil have VNI.
Nu kan vi oprette vores maskiner og virtuelle netværk til dem uden problemer.
Men hvad nu hvis klienten har en anden maskine, men den er på et andet netværk? Vi har brug for rooting mellem netværk. Vi vil analysere en simpel mulighed, når centraliseret routing anvendes - det vil sige, at trafikken dirigeres gennem specielle dedikerede netværksnoder (ja, som regel kombineres de med kontrolnoder, så vi får det samme).
Det virker ikke som noget kompliceret - vi laver en brogrænseflade på kontrolnoden, sender trafik til den og derfra ruter den derhen, hvor vi har brug for den. Men problemet er, at den RØDE klient vil bruge 10.0.0.0/24-netværket, og den GRØNNE klient vil bruge 10.0.0.0/24-netværket. Det vil sige, vi begynder at opleve et skæringspunkt mellem adresserum. Derudover ønsker klienter ikke, at andre klienter skal kunne route til deres interne netværk, hvilket giver mening. For at adskille netværkene og trafikken af kundedata, vil vi allokere et separat navnerum til hver af dem. Navnerummet er faktisk en kopi af Linux-netværksstakken, det vil sige, at klienter i navnerummet RØD er fuldstændig isoleret fra klienter i navnerummet GRØN (eller routing mellem disse klientnetværk er tilladt via standardnavnerummet eller allerede på det højere niveau af transportudstyr).
Det vil sige, vi får følgende diagram:
L2-tunneller konvergerer fra alle computernoder til kontrolnoden. node, hvor L3-grænsefladen for disse netværk er placeret, hver i et dedikeret navnerum til isolering.
Vi har dog glemt det vigtigste. En virtuel maskine skal levere en tjeneste til klienten, det vil sige, at den skal have mindst én ekstern grænseflade, hvorigennem den kan nås. Det vil sige, vi er nødt til at komme ud i den ydre verden. Der er forskellige muligheder her. Lad os lave den enkleste mulighed. Vi tilføjer ét netværk til hver klient, som vil være gyldigt i udbyderens netværk og ikke vil krydse andre netværk. Netværk kan også krydse hinanden og undersøge forskellige VRF'er på udbyderens netværksside. Netværksdata vil også ligge i navneområdet for hver klient. De vil dog stadig gå ud i omverdenen gennem én fysisk (eller binding, hvilket er mere logisk) grænseflade. For at adskille klienttrafikken, vil den udgående trafik blive tagget med et VLAN-tag, der er tildelt klienten.
Som et resultat fik vi følgende diagram:
Et rimeligt spørgsmål: hvorfor ikke lave gateways på selve computernoderne? Der er ikke noget stort problem med dette, og desuden vil det fungere, når du aktiverer den distribuerede router (DVR). I dette scenarie overvejer vi den enkleste løsning med en centraliseret gateway, som bruges som standard i Openstack. Til funktioner med høj belastning vil både en distribueret router og accelerationsteknologier som SR-IOV og Passthrough blive brugt, men som man siger, det er en helt anden historie. Lad os starte med den grundlæggende del, og så går vi i detaljer.
Faktisk er vores ordning allerede operationel, men der er et par nuancer:
- Vi er nødt til at beskytte vores maskiner på en eller anden måde, det vil sige ved at hænge et filter på switch-grænsefladen, der vender mod klienten.
- Gør det muligt for en virtuel maskine automatisk at hente en IP-adresse, så du ikke behøver at logge ind på den via konsollen og indtaste adressen hver gang.
Lad os starte med at beskytte maskinerne. Til dette kan du bruge banale iptables, hvorfor ikke.
Det vil sige, at vores topologi nu er blevet lidt mere kompliceret:
Lad os komme videre. Vi skal tilføje en DHCP-server. Det mest ideelle sted at finde DHCP-servere for hver klient ville være den ovennævnte kontrolnode, hvor navnerummene er placeret:
Der er dog et lille problem. Hvad hvis alt genstarter, og alle oplysninger om DHCP-adresseleasinger forsvinder. Det er logisk, at bilerne får nye adresser, hvilket ikke er særlig praktisk. Der er to udveje - enten brug domænenavne og tilføj en DNS-server for hver klient, så vil adressen ikke være særlig vigtig for os (ligner netværksdelen i k8s) - men der er et problem med eksterne netværk, da adresser i dem også kan udstedes via DHCP - synkronisering med DNS-servere i cloudplatformen og en ekstern DNS-server er nødvendig, hvilket efter min mening ikke er særlig fleksibelt, men ret muligt. Eller den anden mulighed er at bruge metadata - det vil sige at gemme oplysninger om den adresse, der er givet til maskinen, så DHCP-serveren ved, hvilken adresse den skal give til maskinen, hvis maskinen allerede har modtaget en adresse. Den anden mulighed er enklere og mere fleksibel, da den giver dig mulighed for at gemme yderligere oplysninger om bilen. Lad os nu tilføje agentens metadata til diagrammet:
Et andet problem, der også er værd at dække, er muligheden for at bruge ét eksternt netværk af alle klienter, da eksterne netværk, hvis de skal være gyldige i hele netværket, vil være vanskelige - det er nødvendigt konstant at allokere og kontrollere allokeringen af disse netværk. Muligheden for at bruge et enkelt, forudkonfigureret eksternt netværk til alle klienter vil være meget nyttig, når man opretter en offentlig cloud. Dette vil gøre det nemmere at implementere maskiner, da vi ikke behøver at konsultere en adressedatabase og vælge et unikt adresseområde for hver klients eksterne netværk. Derudover kan vi registrere det eksterne netværk på forhånd, og på implementeringstidspunktet behøver vi kun at tilknytte eksterne adresser til klientmaskiner.
Og her kommer NAT os til undsætning - vi vil ganske enkelt gøre det muligt for klienter at få adgang til omverdenen gennem standardnavneområdet ved hjælp af NAT-oversættelse. Jamen, der er et lille problem her. Det er godt, hvis klient-serveren fungerer som en klient og ikke som en server - det vil sige, at den initierer i stedet for at acceptere forbindelser. Men for os vil det være omvendt. I dette tilfælde skal vi oprette en destinations-NAT, så kontrolnoden, når den modtager trafik, forstår, at denne trafik er beregnet til virtuel maskine A på klient A, hvilket betyder, at vi skal foretage en NAT-oversættelse fra en ekstern adresse, for eksempel 100.1.1.1, til en intern adresse 10.0.0.1. I dette tilfælde, selvom alle klienter bruger det samme netværk, opretholdes den interne isolation fuldt ud. Det vil sige, vi skal udføre dNAT og sNAT på kontrolnoden. Om du skal bruge et enkelt netværk med flydende adresseallokering eller eksterne netværk, eller begge dele på én gang, afhænger af, hvad du vil trække ind i skyen. Vi tilføjer ikke flydende adresser til diagrammet, men beholder de eksterne netværk, der allerede er tilføjet tidligere - hver klient har sit eget eksterne netværk (angivet på diagrammet som VLAN 100 og 200 på den eksterne grænseflade).
Som et resultat fik vi en interessant og samtidig velgennemtænkt løsning, der har en vis fleksibilitet, men som endnu ikke har fejltolerancemekanismer.
For det første har vi kun én kontrolnode - dens fejl vil føre til hele systemets sammenbrud. For at eliminere dette problem er det nødvendigt at oprette mindst 3 noder. Lad os tilføje dette til diagrammet:
Naturligvis er alle noder synkroniseret, og når en aktiv node forlader den, overtager en anden node dens opgaver.
Det næste problem er virtuelle maskindiske. I øjeblikket er de gemt på selve hypervisorerne, og i tilfælde af problemer med hypervisoren mister vi alle dataene - og tilstedeværelsen af et raid vil ikke hjælpe her, hvis vi ikke mister en disk, men hele serveren. For at gøre dette, skal vi oprette en tjeneste, der fungerer som en frontend for en form for lagring. Hvilken slags lagring det bliver, er ikke særlig vigtigt for os, men det skal beskytte vores data mod fejl i både disken og noden, og muligvis hele kabinettet. Der er flere muligheder her - selvfølgelig er der SAN-netværk med Fiber Channel, men lad os være ærlige - FC er allerede en levn fra fortiden - en analog af E1 inden for transport - ja, jeg er enig, det bruges stadig, men kun hvor det er absolut umuligt at undvære det. Derfor ville jeg ikke frivilligt udrulle et FC-netværk i 2020, vel vidende at der findes andre mere interessante alternativer. Selvom hver sin mening har, og måske vil der være dem, der mener, at FC med alle sine begrænsninger er alt, hvad vi behøver - vil jeg ikke diskutere, alle har deres egen mening. Den mest interessante løsning efter min mening er dog at bruge SDS, såsom Ceph.
Ceph giver dig mulighed for at bygge en datalagringsløsning med høj tilgængelighed og en række mulige backupmuligheder, lige fra koder med paritetskontrol (analogt med RAID 5 eller 6) til fuld datareplikering til forskellige diske, under hensyntagen til placeringen af diske i servere og servere i kabinetter osv.
For at bygge Ceph skal du bruge 3 noder mere. Interaktion med lagringen vil også foregå via netværket ved hjælp af blok-, objekt- og fillagringstjenester. Lad os tilføje lagerplads til diagrammet:
Bemærk: Det er muligt at lave hyperkonvergerede beregningsnoder - dette er konceptet med at kombinere flere funktioner på én node - for eksempel lagring+beregning - uden at allokere særlige noder til ceph-lagring. Vi får den samme fejltolerante ordning - da SDS vil reservere dataene med det redundansniveau, vi specificerer. Hyperkonvergerede noder er dog altid et kompromis - da lagernoden ikke bare opvarmer luften, som det ser ud ved første øjekast (da der ikke er nogen virtuelle maskiner på den) - den bruger CPU-ressourcer på at servicere SDS (faktisk udfører den alle replikationer, gendannelse efter nodefejl, diske osv. i baggrunden). Det vil sige, at du vil miste noget af computernodens kraft, hvis du kombinerer den med lagerplads.
Alt dette skal styres på en eller anden måde - vi har brug for noget, hvorigennem vi kan oprette en maskine, et netværk, en virtuel router osv. For at gøre dette tilføjer vi en tjeneste til kontrolnoden, der fungerer som et dashboard - klienten vil kunne oprette forbindelse til denne portal via http/https og gøre alt, hvad han har brug for (nå ja, næsten).
Som følge heraf har vi nu et fejltolerant system. Alle elementer i denne infrastruktur skal forvaltes på en eller anden måde. Det blev tidligere beskrevet, at Openstack er et sæt af projekter, der hver især leverer en specifik funktion. Som vi kan se, er der mere end nok elementer, der skal konfigureres og kontrolleres. I dag skal vi tale om netværksdelen.
Neutronarkitektur
I OpenStack er Neutron ansvarlig for at forbinde virtuelle maskinporte til et fælles L2-netværk, sikre trafikrouting mellem VM'er placeret i forskellige L2-netværk, samt udadgående routing, der leverer tjenester som NAT, Floating IP, DHCP osv.
På et overordnet niveau kan netværkstjenestens drift (den grundlæggende del) beskrives som følger.
Når VM starter, netværkstjenesten:
- Opretter en port til den givne VM (eller porte) og underretter DHCP-tjenesten om den;
- En ny virtuel netværksenhed oprettes (via libvirt);
- VM'en opretter forbindelse til den/de port(e), der blev oprettet i trin 1;
Mærkeligt nok er Neutron baseret på standardmekanismer, der er velkendte for alle, der nogensinde har fordybet sig i Linux - navnerum, iptables, Linux-broer, openvswitch, conntrack osv.
Det bør straks præciseres, at Neutron ikke er en SDN-controller.
Neutron består af flere sammenkoblede komponenter:
Openstack-neutron-server — er en dæmon, der arbejder med brugeranmodninger via API. Denne dæmon registrerer ingen netværksforbindelser, men leverer de nødvendige oplysninger til sine plugins, som derefter konfigurerer det nødvendige netværkselement. Neutron-agenter på OpenStack-noder registreres hos Neutron-serveren.
Neutron-server er faktisk en applikation skrevet i Python, der består af to dele:
- REST-tjeneste
- Neutron-plugin (kerne/tjeneste)
REST-tjenesten er designet til at modtage API-kald fra andre komponenter (f.eks. en anmodning om at give oplysninger osv.)
Plugins er pluggbare softwarekomponenter/moduler, der kaldes under API-anmodninger - det vil sige, at tildelingen af en tjeneste sker gennem dem. Plugins er opdelt i to typer: service og root. Som regel er root-plugin'et primært ansvarligt for at administrere adresserummet og L2-forbindelserne mellem VM'er, og service-plugins leverer allerede yderligere funktionalitet, såsom VPN eller FW.
Listen over plugins, der er tilgængelige i dag, kan f.eks. ses
Der kan være flere service-plugins, men der kan kun være ét root-plugin.
Openstack-neutron-ml2 — er et standard Openstack root-plugin. Dette plugin har en modulær arkitektur (i modsætning til sin forgænger) og konfigurerer netværkstjenesten via de drivere, der er tilsluttet den. Vi vil se på selve plugin'et lidt senere, da det faktisk giver den samme fleksibilitet som OpenStack har i netværksdelen. Root-plugin'et kan erstattes (for eksempel laver Contrail Networking en sådan erstatning).
RPC-tjeneste (rabbitmq-server) — en tjeneste, der leverer køstyring og interaktion med andre OpenStack-tjenester, samt interaktion mellem netværkstjenesteagenter.
Netværksagenter — agenter, der er placeret i hver node, hvorigennem netværkstjenester konfigureres.
Der findes flere typer agenter.
Hovedagenten er L2-agent. Disse agenter startes på hver af hypervisorerne, inklusive kontrolnoder (eller mere præcist på alle noder, der leverer tjenester til lejere), og deres hovedfunktion er at forbinde virtuelle maskiner til et fælles L2-netværk samt generere advarsler, når der opstår hændelser (f.eks. deaktivering/aktivering af en port).
Den næste, ikke mindre vigtige agent er L3-agent. Som standard kører denne agent udelukkende på netværksnoden (ofte kombineres netværksnoden med kontrolnoden) og leverer routing mellem lejernetværk (både mellem dens netværk og andre lejeres netværk og er tilgængelig for omverdenen ved at levere NAT samt DHCP-tjeneste). Men når man bruger DVR (distribueret router), opstår der også behov for et L3-plugin på computernoder.
L3-agenten bruger Linux-navneområder til at give hver lejer sit eget sæt af isolerede netværk og virtuel routerfunktionalitet, der dirigerer trafik og leverer gateway-tjenester til Layer 2-netværk.
Database — en database med identifikatorer for netværk, undernet, porte, puljer osv.
Faktisk accepterer Neutron API-anmodninger om oprettelse af netværksenheder, autentificerer anmodningen og sender via RPC (hvis den tilgår et plugin eller en agent) eller REST API (hvis den kommunikerer i SDN) de instruktioner, der er nødvendige for at organisere den anmodede tjeneste, til agenter (gennem plugins).
Lad os nu se på testinstallationen (vi vil se, hvordan den implementeres, og hvad den indeholder 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 ~]$ 
Det er faktisk hele strukturen af Neutron. Nu er det tid til at bruge lidt tid på ML2-pluginnet.
Modulært lag 2
Som nævnt ovenfor er plugin'et et standard OpenStack root-plugin og har en modulær arkitektur.
Forgængeren til ML2-plugin'et havde en monolitisk struktur, som for eksempel ikke tillod brugen af en blanding af flere teknologier i én installation. For eksempel kunne du ikke bruge både openvswitch og linuxbridge på samme tid - hverken den første eller den anden. Af denne grund blev ML2-plugin'et med dets arkitektur oprettet.
ML2 har to komponenter - to typer drivere: Typedrivere og mekanismedrivere.
Type drivere Definer de teknologier, der skal bruges til at organisere netværksforbindelser, såsom VxLAN, VLAN, GRE. Samtidig giver driveren dig mulighed for at bruge forskellige teknologier. Standardteknologien er VxLAN-indkapsling til overlay-netværk og eksterne VLAN-netværk.
Følgende netværkstyper betragtes som Typedrivere:
Flad - netværk uden tagging
VLAN - tagget netværk
Lokale — en særlig type netværk til alt-i-én-installationer (sådanne installationer er nødvendige enten for udviklere eller til træning)
GRE — overlay-netværk ved hjælp af GRE-tunneler
VxLAN — overlay-netværk ved hjælp af VxLAN-tunneler
Mekanismedrivere Definer de midler, der sikrer organiseringen af de teknologier, der er specificeret i typedriveren - for eksempel openvswitch, sr-iov, opendaylight, OVN osv.
Afhængigt af implementeringen af denne driver vil enten agenter styret af Neutron blive brugt, eller forbindelser til en ekstern SDN-controller vil blive brugt, som tager sig af alle problemer relateret til organisering af L2-netværk, routing osv.
Hvis vi for eksempel bruger ML2 sammen med OVS, så er der installeret en L2-agent på hver computernode, der administrerer OVS. Men hvis vi bruger for eksempel OVN eller OpenDayLight, så falder OVS-styring under deres jurisdiktion - Neutron giver kommandoer til controlleren via root-plugin'et, og den gør, hvad den har fået besked på.
Lad os genopfriske vores hukommelse om Open vSwitch
I øjeblikket er en af nøglekomponenterne i OpenStack Open vSwitch.
Når du installerer OpenStack uden yderligere leverandør-SDN'er, såsom Juniper Contrail eller Nokia Nuage, er OVS den primære netværkskomponent i cloud-netværket, og sammen med iptables, conntrack og namespaces giver det dig mulighed for at organisere fuldgyldige overlay-netværk med multi-tenancy. Denne komponent kan naturligvis udskiftes, for eksempel ved brug af tredjeparts proprietære (leverandør-) SDN-løsninger.
OVS er en open source-softwareswitch, der er designet til brug i virtualiserede miljøer som en virtuel trafikvideresendelse.
I øjeblikket har OVS en meget god funktionalitet, som inkluderer teknologier som QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK osv.
Bemærk: OVS var oprindeligt ikke beregnet som en softwareswitch til højbelastede telekommunikationsfunktioner og var mere designet til mindre båndbreddeintensive IT-funktioner såsom en webserver eller mailserver. OVS bliver dog forbedret, og nuværende implementeringer af OVS har forbedret dets ydeevne og muligheder betydeligt, hvilket gør det muligt for teleoperatører med højt belastede funktioner at bruge det. For eksempel findes der en OVS-implementering med DPDK-accelerationsunderstøttelse.
Der er tre vigtige komponenter i OVS, som du skal kende til:
- Kernel-modul — en komponent placeret i kerneområdet, der behandler trafik baseret på de regler, der modtages fra kontrolelementet;
- vSwitch Daemonen (ovs-vswitchd) er en proces, der kører i brugerområdet, og som er ansvarlig for programmering af kernemodulet - det vil sige, at den direkte repræsenterer logikken i switch-operationen.
- Databaseserver — en lokal database placeret på hver vært, der kører OVS, som gemmer konfigurationen. SDN-controllere kan kommunikere via dette modul ved hjælp af OVSDB-protokollen.
Ud over alt dette er der også et sæt diagnosticerings- og administrationsværktøjer, såsom ovs-vsctl, ovs-appctl, ovs-ofctl osv.
I øjeblikket bruges Openstack i vid udstrækning af teleoperatører til at migrere netværksfunktioner som EPC, SBC, HLR osv. Nogle funktioner kan fungere problemfrit med OVS i sin nuværende form, men for eksempel behandler EPC abonnenttrafik - det vil sige, at den passerer igennem en enorm mængde trafik (i øjeblikket når trafikmængderne op på flere hundrede gigabit per sekund). Det er naturligvis ikke den bedste idé at køre sådan trafik gennem kerneområdet (da videresendelsesprogrammet som standard er placeret der). Derfor implementeres OVS ofte udelukkende i brugerområdet ved hjælp af DPDK-accelerationsteknologi til at videresende trafik fra NIC'et til brugerområdet og omgå kernen.
Bemærk: For en cloud, der er implementeret til telekommunikationsfunktioner, er det muligt at sende trafik fra en computernode direkte til switchudstyret, uden om OVS. Til dette formål anvendes SR-IOV og Passthrough-mekanismer.
Hvordan fungerer det på en rigtig model?
Nå, lad os nu gå videre til den praktiske del og se, hvordan det hele fungerer i praksis.
Lad os først implementere en simpel Openstack-installation. Da jeg ikke har et sæt servere ved hånden til eksperimenter, vil vi samle layoutet på én fysisk server fra virtuelle maskiner. Ja, naturligvis er sådan en løsning ikke egnet til kommercielle formål, men for at se et eksempel på, hvordan et netværk fungerer i Openstack, er sådan en installation mere end nok. Desuden er en sådan installation til uddannelsesmæssige formål endnu mere interessant - da det er muligt at fange trafik osv.
Da vi kun behøver at se den grundlæggende del, kan vi ikke bruge flere netværk, men hæve alt ved hjælp af kun to netværk, og det andet netværk i dette layout vil udelukkende blive brugt til adgang til underclouden og DNS-serveren. Vi vil ikke komme ind på eksterne netværk lige nu – det er et emne for en separat, større artikel.
Så lad os starte i rækkefølge. Først lidt teori. Vi installerer Openstack ved hjælp af TripleO (Openstack på Openstack). Ideen bag TripleO er, at vi installerer Openstack all-in-one (dvs. på én node), kaldet undercloud, og derefter bruger funktionerne i den installerede Openstack til at installere Openstack beregnet til produktion, kaldet overcloud. Undercloud vil bruge sin indbyggede evne til at administrere fysiske bare metal-servere – Ironic-projektet – til at klargøre hypervisorer, der skal udføre rollerne som computer-, kontrol- og lagringsnoder. Det vil sige, at vi ikke bruger tredjepartsværktøjer til at implementere Openstack - vi implementerer Openstack ved hjælp af Openstack. Det vil blive meget tydeligere efterhånden som installationen skrider frem, så lad os ikke dvæle ved dette og gå videre.
Bemærk: I denne artikel har jeg for enkelhedens skyld ikke brugt netværksisolering til de interne Openstack-netværk, og alt implementeres kun ved hjælp af ét netværk. Tilstedeværelsen eller fraværet af netværksisolation påvirker dog ikke løsningens grundlæggende funktionalitet - alt vil fungere præcis på samme måde som ved brug af isolation, men trafikken vil flyde i ét netværk. For kommercielle installationer er det naturligvis nødvendigt at anvende isolation ved hjælp af forskellige VLAN'er og grænseflader. For eksempel bruger ceph storage management-trafik og datatrafik (maskiner, der tilgår diske osv.) forskellige undernet (Storage management og Storage), når de er isoleret, og dette gør løsningen mere fejltolerant ved at opdele denne trafik, for eksempel på tværs af forskellige porte, eller ved at bruge forskellige QoS-profiler til forskellig trafik, så datatrafik ikke presser signaltrafik ud. I vores tilfælde vil de gå på det samme netværk, og faktisk begrænser dette os ikke på nogen måde.
Bemærk: Da vi skal køre virtuelle maskiner i et virtuelt maskinbaseret miljø, skal vi først aktivere indlejret virtualisering.
Du kan kontrollere, om indlejret virtualisering er aktiveret eller ej, således:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Hvis du ser bogstavet N, skal du aktivere understøttelse af indlejret virtualisering ved hjælp af en hvilken som helst vejledning, du finder online, for eksempel .
Vi skal sammensætte et skema som dette fra virtuelle maskiner:
I mit tilfælde brugte jeg OpenvSwitch til at forbinde virtuelle maskiner, der er inkluderet i den fremtidige installation (og 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 forbandt virtuelle maskiner til den via portgrupper. For at gøre dette, har jeg oprettet en xml-fil af følgende type:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Tre portgrupper er angivet her - to adgangsgrupper og én trunk (sidstnævnte var nødvendig for DNS-serveren, men du kan undvære den eller konfigurere den på værtsmaskinen - alt efter hvad der er mest praktisk for dig). Dernæst, ved hjælp af denne skabelon, deklarerer vi vores eat via virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nu redigerer vi hypervisorportkonfigurationerne:
[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å port ovs-br1 ikke være tilgængelig, fordi den ikke har et VLAN-tag. For at løse dette skal du udføre kommandoen sudo ovs-vsctl set port ovs-br1 tag=100. Men efter genstart vil dette tag forsvinde (hvis nogen ved, hvordan man får det til at forblive på plads, ville jeg være meget taknemmelig). Men det er ikke så vigtigt, fordi vi kun skal bruge denne adresse under installationen og ikke, når Openstack er fuldt implementeret.
Dernæst opretter vi en undercloud-maskine:
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 installationen indstiller du alle de nødvendige parametre, såsom maskinnavn, adgangskoder, brugere, ntp-servere osv. Du kan også konfigurere porte med det samme, men for mig personligt er det nemmere at logge ind på maskinen via konsollen efter installationen og redigere de nødvendige filer. Hvis du allerede har et færdigt image, kan du bruge det, eller gøre som jeg gjorde - downloade det minimale Centos 7-image og bruge det til at installere VM'en.
Efter vellykket installation burde du have en virtuel maskine, hvorpå du kan installere UnderCloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningFørst installerer vi de nødvendige værktøjer til installationsprocessen:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Installation af Undercloud
Vi opretter en brugerstak, indstiller en adgangskode, tilføjer den til sudoer og giver den mulighed for at udføre root-kommandoer via sudo uden at skulle indtaste en adgangskode:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNu angiver vi det fulde navn på underclouden i hosts-filen:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Dernæst tilføjer vi arkiver og installerer den software, vi har brug for:
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-ansibleBemærk: Hvis du ikke planlægger at installere ceph, behøver du ikke at indtaste kommandoer relateret til ceph. Jeg brugte Queens-udgivelsen, men du kan bruge en hvilken som helst anden, du har lyst til.
Dernæst kopierer vi undercloud-konfigurationsfilen til stack-brugerens hjemmemappe:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNu skal vi rette denne fil og tilpasse den til vores installation.
Følgende linjer skal tilføjes i starten af filen:
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 = 10Så lad os gennemgå indstillingerne:
undercloud_hostname — det fulde navn på undercloud-serveren skal stemme overens med posten på DNS-serveren
lokal_ip — lokal undercloud-adresse mod provisioneringsnetværket
netværksgateway — den samme lokale adresse, som vil fungere som en gateway for adgang til omverdenen under installationen af overcloud-noden, matcher også den lokale IP-adresse
undercloud_offentlig_vært — ekstern API-adresse, enhver ledig adresse fra provisioneringsnetværket tildeles
undercloud_admin_host intern API-adresse, enhver ledig adresse fra provisioneringsnetværket tildeles
undercloud_navneservere — DNS-server
generer_service_certifikat — denne linje er meget vigtig i det aktuelle eksempel, fordi hvis du ikke sætter den til falsk, vil du få en fejl under installationen. Problemet er beskrevet i Red Hat-fejlsporeren.
lokal_grænseflade grænseflade i provisioneringsnetværket. Denne grænseflade vil blive omkonfigureret under implementeringen af underclouden, så det er nødvendigt at have to grænseflader på underclouden - en til adgang til den, den anden til provisionering.
lokal_mtu — MTU. Da vi har et testlaboratorium, og min MTU er 1500 på OVS-switchportene, er det nødvendigt at indstille den til 1450, så pakker indkapslet i VxLAN passerer igennem.
netværk_cidr — leveringsnetværk
maskerade - brug af NAT til at få adgang til det eksterne netværk
maskerade_netværk — det netværk, der vil blive NATet
dhcp_start — den oprindelige adresse for adressepuljen, hvorfra adresser tildeles noder under overcloud-implementering
dhcp_end — den endelige adresse på adressepuljen, hvorfra adresser tildeles noder under overcloud-implementering
inspektions_iprange — en pulje af adresser, der kræves for at udføre introspektion (bør ikke overlappe med ovenstående pulje)
scheduler_max_attempts — maksimalt antal forsøg på at installere overcloud (skal være større end eller lig med antallet af noder)
Når filen er beskrevet, kan du udføre en kommando for at implementere undercloud:
openstack undercloud install
Proceduren tager fra 10 til 30 minutter afhængigt af din hardware. I sidste ende burde du se output som dette:
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Dette output fortæller dig, at du har installeret UnderCloud, og at du nu kan kontrollere status for UnderCloud og fortsætte med at installere OverCloud.
Hvis du ser på outputtet fra ifconfig, vil du se, at en ny bridge-grænseflade er dukket op.
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Overcloud-implementeringsarbejde vil nu blive udført via denne grænseflade.
Fra outputtet nedenfor kan du se, at alle vores tjenester er på én node:
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Nedenfor er konfigurationen af netværksdelen af underclouden:
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Overcloud-installation
I øjeblikket har vi kun undercloud, og vi mangler noder, hvorfra overcloud skal samles. Derfor er det første, vi vil gøre, at implementere de virtuelle maskiner, vi har brug for. Under implementeringen vil Undercloud selv installere operativsystemet og den nødvendige software på Overcloud-maskiner - det vil sige, at vi ikke behøver at implementere maskinen fuldt ud, men kun oprette en disk (eller diske) til den og bestemme dens parametre - det vil sige, at vi faktisk får en bare server uden et OS installeret på den.
Lad os gå til mappen med diskene på vores virtuelle maskiner og oprette diske med den nødvendige mængde:
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 fungerer som root, er vi nødt til at æ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 det formål at studere det, skal du ikke oprette mindst 3 noder med mindst to diske, og i skabelonen skal du angive, at virtuelle diske vda, vdb osv. vil blive brugt.
Fantastisk, nu skal vi identificere 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 en beskrivelse af hver maskine i /tmp/-mappen. Hvis du ikke tilføjer den, vil du ikke kunne bestemme 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 Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Nu en lille nuance - tripleO bruger IPMI til at administrere servere under installation og introspektion.
Introspektion er processen med at inspicere hardwaren for at bestemme dens parametre, der er nødvendige for yderligere klargøring af noder. Introspektion udføres ved hjælp af ironic, en tjeneste designet til at fungere med bare metal-servere.
Men her er problemet - hvis IPMI-hardwareservere har en separat port (eller en delt port, men dette er ikke vigtigt), så har virtuelle maskiner ikke sådanne porte. Her kommer et hack kaldet vbmc os til hjælp - et værktøj, der giver dig mulighed for at emulere en IPMI-port. Denne nuance er især værd at være opmærksom på for dem, der ønsker at oprette et sådant laboratorium på ESXI-hypervisoren - for at være ærlig, ved jeg ikke, om det har en analog til vbmc, så det er værd at overveje dette problem, før man implementerer alt.
Installer vbmc:
yum install yum install python2-virtualbmcHvis dit operativsystem ikke kan finde pakken, skal du tilføje repository'et:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNu konfigurerer vi værktøjet. Alt her er banalt til det grimhedslige. Nu giver det mening, at der ikke er nogen servere på vbmc-listen.
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# For at de kan vises, skal de deklareres manuelt som følger:
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Jeg synes, at kommandosyntaksen er klar uden forklaring. Men for nuværende har alle vores sessioner status NED. For at de kan få UP-status, skal de være aktiveret:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Og det sidste touch - du skal justere firewallreglerne (eller deaktivere dem 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å til Undercloud og tjekke, at alt fungerer. Værtsmaskinens adresse er 192.168.255.200. På Undercloud tilføjede vi den nødvendige ipmitool-pakke under forberedelsen af implementeringen:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningSom du kan se, har vi med succes startet kontrolnoden via vbmc. Lad os nu slukke den og gå videre:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Det næste skridt er at undersøge de noder, der skal være vært for overcloud. For at gøre dette skal vi forberede en json-fil med en beskrivelse af vores noder. Bemærk venligst, at i modsætning til bare-metal-installationen angiver filen den port, som vbmc kører på for hver maskine.
[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: Der er to grænseflader på kontrolnoden, men i dette tilfælde er det ikke vigtigt, i denne installation er én nok for os.
Nu forbereder vi json-filen. Vi skal angive MAC-adressen på den port, hvorigennem provisioneringen skal udføres, nodeparametre, give dem navne og angive, hvordan man kommer 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 billeder til ironi. For at gøre dette skal du downloade dem via wget og installere:
(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 ~]$Upload billeder til Undercloud:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Kontroller at alle billeder er indlæst
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$En ting mere - du skal tilføje en DNS-server:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nu kan vi give kommandoen til introspektion:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Som du kan se på resultatet, blev alt gennemført uden fejl. Lad os kontrollere, at alle noder er i tilgængelig tilstand:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Hvis noderne er i en anden tilstand, som normalt er håndterbar, så er der gået noget galt, og du skal se i loggen for at finde ud af, hvorfor dette skete. Bemærk venligst, at vi i dette scenarie bruger virtualisering, og der kan være fejl forbundet med brugen af virtuelle maskiner eller vbmc.
Dernæst skal vi angive, hvilken node der skal udføre hvilken funktion - det vil sige angive den profil, som noden skal implementeres 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 specificerer 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-d9afb69d1167Lad os tjekke, at 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 implementere 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 rigtig installation vil der naturligvis blive brugt brugerdefinerede skabeloner, hvilket i vores tilfælde vil komplicere processen betydeligt, da det vil være nødvendigt at forklare hver redigering i skabelonen. Som skrevet tidligere, vil selv en simpel installation være nok til at vi kan se, hvordan det fungerer.
Bemærk: variablen --libvirt-type qemu er nødvendig i dette tilfælde, da vi vil bruge indlejret virtualisering. Ellers vil du ikke kunne køre virtuelle maskiner.
Nu har du cirka en time, eller måske mere (afhængigt af hardwarens kapacitet), og du kan kun håbe, at du efter dette tidsrum vil se denne besked:
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 en næsten komplet version af OpenStack, som du kan studere, eksperimentere osv. på.
Lad os tjekke, at alt fungerer fint. I brugerstakkens hjemmemappe er der to filer - en stackrc (til administration af undercloud) og den anden overcloudrc (til administration af overcloud). Disse filer skal angives som kilde, fordi de indeholder de oplysninger, der er nødvendige for godkendelse.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Min installation mangler stadig en lille detalje - tilføj en rute på controlleren, da den maskine, jeg arbejder med, er på et andet netværk. For at gøre dette skal du gå til kontrol-1 under heat-admin-kontoen og indtaste ruten
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Nå, nu kan du gå ind i horisonten. Alle oplysninger - adresser, login og adgangskode - findes i filen /home/stack/overcloudrc. Det endelige diagram ser sådan ud:
Forresten, i vores installation blev maskinadresserne udstedt via DHCP, og som du kan se, blev de udstedt "under alle omstændigheder". Du kan hardcode i skabelonen, hvilken adresse der skal knyttes til hvilken maskine under implementeringen, hvis det er nødvendigt.
Hvordan flyder trafikken mellem virtuelle maskiner?
I denne artikel vil vi overveje tre muligheder for forbipasserende trafik
- To maskiner på én hypervisor i ét L2-netværk
- To maskiner på forskellige hypervisorer i ét L2-netværk
- To maskiner i forskellige netværk (routing mellem netværk)
Vi vil overveje tilfælde med adgang til omverdenen via et eksternt netværk, ved hjælp af flydende adresser, samt distribueret routing næste gang; For nu vil vi fokusere på intern trafik.
For at kontrollere, lad os samle følgende kredsløb:
Vi har oprettet 4 virtuelle maskiner - 3 i ét L2-netværk - net-1, og 1 mere i net-2-netværket.
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Lad os se på hvilke hypervisorer de oprettede maskiner er placeret:
(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 | (oversky) [stak@undersky ~]$
Maskinerne vm-1 og vm-3 er placeret på compute-0, og maskinerne vm-2 og vm-4 er placeret på node compute-1.
Derudover er der oprettet en virtuel router for at muliggøre routing 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, der fungerer som gateways for netværk:
(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 flyder, lad os se på, hvad vi i øjeblikket har på kontrolnoden (som også er netværksnoden) og på beregningsnoden. Lad os starte med beregningsnoden.
[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. Mellem dem, som vi kan se, er der et sæt grænseflader. For at lette overskueligheden, lad os sætte alle disse grænseflader på diagrammet og se, hvad der sker.
Baseret på de adresser, som VxLAN-tunnellerne er oprettet til, er det tydeligt, at den ene tunnel er oprettet på compute-1 (192.168.255.26), mens den anden tunnel kigger på control-1 (192.168.255.15). Men det mest interessante er, at br-ex ikke har fysiske grænseflader, og hvis man ser på, hvilke flows der er konfigureret, kan man se, at denne bro kun kan droppe trafik i øjeblikket.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Som det kan ses af outputtet, er adressen knyttet direkte til den fysiske port og ikke til den virtuelle brogrænseflade.
[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 kom fra phy-br-ex-porten, kasseres.
Faktisk er der intet andet sted, trafikken kan komme fra på denne bro end fra denne grænseflade (krydset med br-int), og at dømme efter faldene, er BUM-trafik allerede ankommet til broen.
Det vil sige, at trafik fra denne node kun kan forlades gennem VxLAN-tunnelen og intet andet. Men hvis du tænder for DVR'en, vil situationen ændre sig, men det tager vi en anden gang. Når du bruger netværksisolering, for eksempel med VLAN'er, vil du ikke have én L3-grænseflade i VLAN 0, men flere grænseflader. VxLAN-trafik vil dog forlade noden på præcis samme måde, men indkapslet i et dedikeret VLAN.
Vi har styr på beregningsnoden, lad os gå videre til kontrolnoden.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Faktisk kan vi sige, at alt er det samme, men IP-adressen er ikke længere på den fysiske grænseflade, men på den virtuelle bro. Dette gøres, fordi denne port er den port, hvorigennem trafikken vil gå ud til omverdenen.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Denne port er forbundet til br-ex-broen, og da den ikke har nogen vlan-tags, er denne port en trunk-port, hvor alle vlaner er tilladt. Nu går trafikken ud uden et tag, som angivet af vlan-id 0 i outputtet ovenfor.
Alt andet ligner i øjeblikket en beregningsnode - de samme broer, de samme tunneler, der går til to beregningsnoder.
Vi vil ikke overveje lagringsnoder i denne artikel, men for at forstå det er nødvendigt at sige, at netværksdelen af disse noder er banal til det grimhedslige punkt. I vores tilfælde er der kun én fysisk port (eth0) med en tildelt IP-adresse, og det er det. Der er ingen VxLAN-tunneler, tunnelbroer osv. - der er slet ingen ovs, da der ikke er nogen mening i det. Når du bruger netværksisolation, vil der være to grænseflader på denne node (fysiske porte, bauds eller blot to VLAN'er - det er ligegyldigt - det afhænger af, hvad du ønsker) - en til administration, den anden til trafik (skrivning til VM-disken, læsning fra disken osv.).
Vi fandt ud af, hvad vi har på noderne i mangel af tjenester. Lad os nu starte 4 virtuelle maskiner og se, hvordan ovenstående skema ændrer sig - vi skal have porte, virtuelle routere osv.
Indtil videre ser vores netværk således ud:
Vi har to virtuelle maskiner på hver computernode. Lad os bruge compute-0 som eksempel, og se hvordan alt er inkluderet.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Maskinen har kun én virtuel grænseflade - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Denne brugerflade undersøger Linux-broen:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Som du kan se fra outputtet, er der kun to grænseflader i broen - tap95d96a75-a0 og qvb95d96a75-a0.
Her er det værd at dvæle lidt ved typerne af virtuelle netværksenheder i OpenStack:
vtap - virtuel grænseflade knyttet til en instans (VM)
qbr — Linux-bro
qvb og qvo er et vEth-par forbundet til en Linux-bro og en Open vSwitch-bro.
br-int, br-tun, br-vlan — Åbne vSwitch-broer
patch-, int-br-, phy-br- — Åbne vSwitch patch-grænseflader, der forbinder broer
qg, qr, ha, fg, sg — Åbne vSwitch-porte, der bruges af virtuelle enheder til at oprette forbindelse til OVS
Som du forstår, hvis vi har en qvb95d96a75-a0 port i broen, som er et vEth par, så er der et sted dens modstykke, som logisk set burde kaldes qvo95d96a75-a0. Lad os se, hvilke porte der er tilgængelige 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: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Som vi kan se, er havnen i br-int. Br-int fungerer som en switch, der afslutter porte på virtuelle maskiner. Udover qvo95d96a75-a0 viser outputtet også port qvo5bd37136-47. Dette er en port til den anden virtuelle maskine. Som følge heraf ser vores skema nu således ud:
Spørgsmålet, der straks burde interessere den opmærksomme læser, er: hvorfor er der en Linux-bro mellem den virtuelle maskinport og OVS-porten? Sagen er, at sikkerhedsgrupper bruges til at beskytte maskinen, hvilket ikke er andet end iptables. OVS fungerer ikke med iptables, så denne "løsning" blev opfundet. Den er dog ved at blive forældet - den bliver erstattet af conntrack i nye udgivelser.
Så i sidste ende ser ordningen sådan ud:
To maskiner på én hypervisor i ét L2-netværk
Da disse to VM'er er i det samme L2-netværk og på den samme hypervisor, vil trafikken mellem dem logisk set gå lokalt via br-int, da begge maskiner vil være i det 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 ét L2-netværk
Lad os nu se, hvordan trafikken vil flyde mellem to maskiner i det samme L2-netværk, men placeret på forskellige hypervisorer. For at være ærlig, vil der ikke ændre sig meget, trafikken mellem hypervisorer vil simpelthen gå gennem vxlan-tunnelen. Lad os se på et eksempel.
Adresser på virtuelle maskiner, mellem hvilke vi vil overvåge trafikken:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Lad os se på videresendelsestabellen 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 en brugerflade i br-tun. Lad os se, hvad der sker med pakken på 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 ~]$Lad os 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-adressen findes i br-int-videresendelsestabellen på compute-1, og som det kan ses af outputtet ovenfor, er den synlig via 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:46Nå, så ser vi på, hvad der er i br-int på compute-1, der er en destination MAC:
[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 modtagne pakke flyver til port 3, bag hvilken den virtuelle maskininstans-00000003 allerede er placeret.
Det smukke ved at implementere Openstack til læring på en virtuel infrastruktur er, at vi nemt kan registrere trafikken mellem hypervisorer og se, hvad der sker med den. Dette er, hvad vi vil gøre nu, køre tcpdump på vnet-porten mod compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Den første linje viser, at stien fra adresse 10.0.1.85 går til adresse 10.0.1.88 (ICMP-trafik), og at den er pakket ind i en VxLAN-pakke med vni 22, og at pakken går fra vært 192.168.255.19 (compute-0) til vært 192.168.255.26 (compute-1). Vi kan kontrollere, at VNI'en matcher den, der er angivet i ovs.
Lad os gå tilbage til denne linje actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 er vni i hexadecimal notation. Lad os omregne dette tal til det 16. system:
16 = 6*16^0+1*16^1 = 6+16 = 22Det vil sige, at vni svarer til virkeligheden.
Den anden linje viser returtrafikken, ja, der er ingen grund til at forklare det, alt er tydeligt der.
To maskiner på forskellige netværk (routing mellem netværk)
Det sidste tilfælde for i dag er routing mellem netværk inden for ét projekt ved hjælp af en virtuel router. Vi overvejer et tilfælde uden DVR (vi vil behandle det i en anden artikel), så routing sker på netværksnoden. I vores tilfælde er netværksnoden ikke opdelt i en separat enhed og er placeret på kontrolnoden.
Lad os først se, om routing 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 statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msDa pakken i dette tilfælde skal gå til gatewayen og dirigeres dertil, skal vi finde gatewayens MAC-adresse, som vi vil se 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 nu se, hvor trafik 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 ~]$ Alt er logisk, trafikken går til br-tun. Lad os se, hvilken vxlan-tunnel den bliver pakket ind 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 har nået kontrolnoden, så vi er nødt til at skifte til den og se, hvordan routingen vil foregå.
Som du husker, så kontrolnoden præcis den samme ud indvendigt som beregningsnoden - de samme tre broer, kun br-ex havde en fysisk port, hvorigennem noden kunne sende trafik ud. Oprettelse af instanser ændrede konfigurationen på beregningsnoder - Linux Bridge, iptables og interfaces blev tilføjet til noderne. Oprettelsen af netværk og en virtuel router satte også sit præg på kontrolnodens konfiguration.
Så det er indlysende, at gatewayens MAC-adresse skal være i br-int-videresendelsestabellen på kontrolnoden. Lad os tjekke, om den er der, og hvor den kigger 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'en er synlig fra port qr-0c52b15f-8f. Hvis vi går tilbage til listen over virtuelle porte i Openstack, bruges denne type port til at forbinde forskellige virtuelle enheder til OVS. For at være mere præcis er qr en port mod en virtuel router, som er repræsenteret som et navnerum.
Lad os se hvilke navnerum 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 ~]$ Tre eksemplarer i alt. Men at dømme efter navnene, kan man gætte formålet med hver af dem. Vi vender tilbage til instanser med ID 0 og 1 senere, nu hvor vi er interesserede i navnerummet 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 navnerum er der to interne, som vi oprettede tidligere. Begge virtuelle porte er blevet tilføjet til br-int. Lad os tjekke MAC-adressen på porten qr-0c52b15f-8f, da trafikken, at dømme ud fra destinationens MAC-adresse, gik 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<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Det vil sige, at i dette tilfælde fungerer alt i henhold til lovene for standardruting. Da trafikken er beregnet til vært 10.0.2.8, skal den gå ud gennem den anden grænseflade qr-92fa49b5-54 og gå gennem vxlan-tunnelen til beregningsnoden:
[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 er logisk, ingen overraskelser. Lad os se, hvor MAC-adressen på værten 10.0.2.8 er synlig 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 forventet går trafikken til br-tun. Lad os se hvilken tunnel trafikken går til næste gang:
[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 ~]$ Trafikken går ind i tunnelen for at beregne-1. Nå, på compute-1 er alt simpelt - fra br-tun går pakken til br-int og derfra til den virtuelle maskingrænseflade:
[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 ~]$ Lad os tjekke, om dette faktisk er den korrekte grænseflade:
[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 ~]$ Faktisk har vi gennemgået hele pakkeprocessen. Jeg tror, du har bemærket, at trafikken gik gennem forskellige vxlan-tunneller og kom ud med forskellige VNI'er. Lad os se, hvilke VNI'er disse er, derefter indsamle en dump på kontrolnodeporten og sørge for, at trafikken flyder præcis som beskrevet ovenfor.
Så tunnelen til at beregne-0 har følgende actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Lad os konvertere 0x16 til decimaltal:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunnelen til beregning af-1 har følgende VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Lad os konvertere 0x63 til decimaltal:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Nå, lad os nu se på lossepladsen:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************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 ovenfor, matcher vni det, vi så i konklusionerne.
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 ovenfor, matcher vni det, vi så i konklusionerne.
De næste to pakker er returtrafik fra 10.0.2.8, ikke 10.0.1.85.
Så til sidst fik vi følgende kontrolnodediagram:
Det er alt, tror jeg? Vi glemte to navnerum:
[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 sagde om cloudplatformarkitekturen, ville det være godt, hvis maskiner automatisk modtog adresser fra en DHCP-server. Dette er to DHCP-servere til vores to netværk, 10.0.1.0/24 og 10.0.2.0/24.
Lad os tjekke om det er tilfældet. I dette navnerum 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<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Lad os se om processerne indeholder qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 i deres navn 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 findes en sådan proces, og baseret på oplysningerne i ovenstående output kan vi for eksempel se, hvad vi i øjeblikket har til leje:
[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 ~]$Som følge heraf får vi følgende sæt af tjenester på kontrolnoden:
Husk dog på - det er kun 4 maskiner, 2 interne netværk og én virtuel router... Vi har ingen eksterne netværk her nu, en masse forskellige projekter, hver med deres egne netværk (der krydser hinanden), og vi har den distribuerede router slukket, og til sidst var der kun én kontrolnode i teststanden (for fejltolerance skal der være et quorum på tre noder). Det er logisk, at alting er "lidt" mere kompliceret inden for handel, men i dette simple eksempel forstår vi, hvordan det skal fungere - om du har 3 eller 300 navnerum er selvfølgelig vigtigt, men set fra hele strukturens drift - vil der ikke ændre sig meget... indtil du indsætter et eller andet leverandør-SDN, altså. Men det er en helt anden historie.
Jeg håber det var interessant. Hvis du har kommentarer/tilføjelser, eller hvis jeg åbenlyst har løjet et sted (jeg er et menneske, og min mening vil altid være subjektiv) - så skriv hvad der skal rettes/tilføjes - vi retter/tilføjer alt.
Afslutningsvis vil jeg gerne sige et par ord om at sammenligne Openstack (både vanilla og vendor) med cloud-løsningen fra VMWare - jeg er blevet stillet dette spørgsmål alt for ofte de sidste par år, og jeg er allerede træt af det, ærligt talt, men alligevel. Efter min mening er det meget vanskeligt at sammenligne disse to løsninger, men det er tydeligt, at begge løsninger har deres ulemper, og når man vælger én løsning, er man nødt til at afveje alle fordele og ulemper.
Hvis OpenStack er en community-drevet løsning, så har VMWare ret til kun at gøre, hvad de vil (læs - hvad der er profitabelt for dem), og det er logisk - fordi det er en kommerciel virksomhed, der er vant til at tjene penge på sine kunder. Men der er ét stort og fedt MEN her - du kan komme væk fra OpenStack, for eksempel, fra Nokia og skifte til en løsning fra for eksempel Juniper (Contrail Cloud) med en lille indsats, men du vil næppe kunne komme væk fra VMWare. For mig ser disse to løsninger sådan her ud - Openstack (leverandør) er et simpelt bur, hvor du bliver placeret, men du har nøglen, og du kan gå når som helst. VMWare er et gyldent bur, nøglen til buret er i ejerens hænder, og det vil koste dig en masse.
Jeg kæmper ikke for hverken det første eller det andet produkt – du vælger, hvad du har brug for. Men hvis jeg skulle vælge, ville jeg vælge begge løsninger - VMWare til IT-clouden (lav belastning, nem administration), OpenStack fra en leverandør (Nokia og Juniper leverer meget gode nøglefærdige løsninger) - til telekommunikationsclouden. Jeg ville ikke bruge Openstack til ren IT - det er som at skyde spurve med en kanon, men jeg ser ingen kontraindikationer for at bruge det, udover redundans. At bruge VMWare inden for telekommunikation er dog som at transportere grus i en Ford Raptor - den ser godt ud udefra, men chaufføren skal køre 10 ture i stedet for én.
Efter min mening er den største ulempe ved VMWare dens fuldstændig lukkede natur - virksomheden vil ikke give dig nogen information om, hvordan for eksempel vSAN er arrangeret, eller hvad der er i hypervisorkernen - det er simpelthen ikke rentabelt for det - det vil sige, du bliver aldrig ekspert i VMWare - uden leverandørstøtte er du dømt (meget ofte møder jeg VMWare-eksperter, der sidder fast i trivielle spørgsmål). For mig er VMWare som at købe en bil med motorhjelmen låst - ja, du har måske specialister, der kan skifte tandremmen, men det er kun den person, der solgte dig denne løsning, der kan åbne motorhjelmen. Personligt kan jeg ikke lide beslutninger, som jeg ikke selv kan være involveret i. Man kan sige, at man måske ikke behøver at sætte sig ind under kølerhjelmen. Ja, det er muligt, men jeg vil se på dig, når du skal samle en stor funktion i skyen fra 20-30 virtuelle maskiner, 40-50 netværk, hvoraf halvdelen vil gå udenfor, og den anden halvdel beder om SR-IOV-acceleration, ellers skal du bruge et par dusin mere af den slags maskiner - ellers vil ydeevnen ikke være nok.
Der er andre synspunkter, så det er op til dig at beslutte, hvad du skal vælge, og vigtigst af alt, vil du være ansvarlig for dit valg senere. Dette er bare min mening - en person der har set og rørt ved mindst 4 produkter - Nokia, Juniper, Red Hat og VMWare. Det betyder, at jeg har noget at sammenligne mig med.
Kilde: www.habr.com
