Cloud computing trenger dypere og dypere inn i livene våre og det er sannsynligvis ikke en eneste person som ikke har brukt noen skytjenester minst én gang. Men hva en sky er og hvordan den fungerer, er det få som vet, selv på idénivå. 5G er allerede i ferd med å bli en realitet og telekom-infrastrukturen begynner å bevege seg fra pilarløsninger til skyløsninger, akkurat som den gjorde da den gikk fra fullstendige maskinvareløsninger til virtualiserte «pilarer».
I dag skal vi snakke om den indre verden av skyinfrastruktur, spesielt vil vi se på det grunnleggende om nettverksdelen.
Hva er en sky? Samme virtualisering – profilvisning?
Mer enn et logisk spørsmål. Nei - dette er ikke virtualisering, selv om det ikke kunne gjøres uten det. La oss se på to definisjoner:
Cloud computing (heretter kalt Cloud) er en modell for å gi brukervennlig tilgang til distribuerte dataressurser som må distribueres og lanseres på forespørsel med lavest mulig ventetid og minimal kostnad for tjenesteleverandøren.
Virtualisering - dette er muligheten til å dele en fysisk enhet (for eksempel en server) i flere virtuelle, og dermed øke ressursutnyttelsen (for eksempel hadde du 3 servere lastet med 25-30 prosent, etter virtualisering får du 1 server lastet på 80-90 prosent). Naturligvis spiser virtualisering opp noen av ressursene - du må mate hypervisoren, men som praksis har vist, er spillet verdt lyset. Et ideelt eksempel på virtualisering er VMWare, som perfekt forbereder virtuelle maskiner, eller for eksempel KVM, som jeg foretrekker, men dette er en smakssak.
Vi bruker virtualisering uten å være klar over det, og til og med jernrutere bruker virtualisering allerede – for eksempel i den nyeste versjonen av JunOS er operativsystemet installert som en virtuell maskin på toppen av en sanntids Linux-distribusjon (Wind River 9). Men virtualisering er ikke skyen, men skyen kan ikke eksistere uten virtualisering.
Virtualisering er en av byggesteinene som skyen er bygget på.
Å lage en sky ved ganske enkelt å samle flere hypervisorer i ett L2-domene, legge til et par yaml-spillebøker for automatisk registrering av vlans gjennom en slags ansible og jamming av noe som et orkestreringssystem på det hele for automatisk å lage virtuelle maskiner, vil ikke fungere. Det vil være mer nøyaktig, men den resulterende Frankenstein er ikke skyen vi trenger, selv om det kan være den ultimate drømmen for andre. Dessuten, hvis du tar den samme Openstack, er det i hovedsak fortsatt Frankenstein, men jammen, la oss ikke snakke om det foreløpig.
Men jeg forstår at fra definisjonen presentert ovenfor er det ikke helt klart hva som faktisk kan kalles en sky.
Derfor gir et dokument fra NIST (National Institute of Standards and Technology) 5 hovedegenskaper som en skyinfrastruktur bør ha:
Tilbyr service på forespørsel. Brukeren må gis gratis tilgang til datamaskinressursene som er tildelt ham (som nettverk, virtuelle disker, minne, prosessorkjerner osv.), og disse ressursene må leveres automatisk - det vil si uten inngripen fra tjenesteleverandøren.
Bred tilgjengelighet av tjenester. Tilgang til ressurser må gis av standardmekanismer for å tillate bruk av både standard PC-er og tynnklienter og mobile enheter.
Kombinere ressurser i bassenger. Ressurspooler må kunne gi ressurser til flere klienter samtidig, og sikre at klienter er isolerte og fri for gjensidig påvirkning og konkurranse om ressurser. Nettverk er også inkludert i puljene, noe som indikerer muligheten for å bruke overlappende adressering. Bassenger skal kunne skaleres etter behov. Bruken av bassenger gjør det mulig å gi det nødvendige nivået av ressursfeiltoleranse og abstraksjon av fysiske og virtuelle ressurser - mottakeren av tjenesten får ganske enkelt det settet med ressurser han ba om (hvor disse ressursene er fysisk plassert, på hvor mange servere og svitsjer - det spiller ingen rolle for klienten). Vi må imidlertid ta hensyn til at tilbyderen skal sørge for transparent reservasjon av disse ressursene.
Rask tilpasning til ulike forhold. Tjenestene må være fleksible – rask tilførsel av ressurser, omfordeling av dem, tilføyelse eller reduksjon av ressurser etter kundens forespørsel, og fra kundens side bør det være en følelse av at skyressursene er uendelige. For å gjøre det lettere å forstå, ser du for eksempel ikke en advarsel om at deler av diskplassen din i Apple iCloud har forsvunnet fordi harddisken på serveren har gått i stykker, og stasjoner går i stykker. I tillegg, fra din side, er mulighetene for denne tjenesten nesten ubegrensede - du trenger 2 TB - ikke noe problem, du betalte og mottok den. Et lignende eksempel kan gis med Google.Drive eller Yandex.Disk.
Mulighet for å måle tjenesten som ytes. Skysystemer må automatisk kontrollere og optimalisere forbrukte ressurser, og disse mekanismene må være transparente for både brukeren og tjenesteleverandøren. Det vil si at du alltid kan sjekke hvor mange ressurser du og kundene dine bruker.
Det er verdt å vurdere det faktum at disse kravene stort sett er krav til en offentlig sky, så for en privat sky (det vil si en sky lansert for selskapets interne behov), kan disse kravene justeres litt. Imidlertid må de fortsatt gjøres, ellers får vi ikke alle fordelene med cloud computing.
Hvorfor trenger vi en sky?
Men enhver ny eller eksisterende teknologi, enhver ny protokoll er laget for noe (vel, bortsett fra RIP-ng, selvfølgelig). Ingen trenger en protokoll for en protokolls skyld (vel, bortsett fra RIP-ng, selvfølgelig). Det er logisk at skyen er skapt for å gi en eller annen form for tjeneste til brukeren/klienten. Vi er alle kjent med minst et par skytjenester, for eksempel Dropbox eller Google.Docs, og jeg tror de fleste bruker dem med hell - for eksempel ble denne artikkelen skrevet ved hjelp av skytjenesten Google.Docs. Men skytjenestene vi kjenner er bare en del av mulighetene til skyen – mer presist er de bare en SaaS-type tjeneste. Vi kan tilby en skytjeneste på tre måter: i form av SaaS, PaaS eller IaaS. Hvilken tjeneste du trenger avhenger av dine ønsker og evner.
La oss se på hver i rekkefølge:
Programvare som en tjeneste (SaaS) er en modell for å tilby en fullverdig tjeneste til klienten, for eksempel en e-posttjeneste som Yandex.Mail eller Gmail. I denne tjenesteleveringsmodellen gjør du som klient faktisk ingenting annet enn å bruke tjenestene – det vil si at du ikke trenger å tenke på å sette opp tjenesten, dens feiltoleranse eller redundans. Det viktigste er ikke å kompromittere passordet ditt; leverandøren av denne tjenesten vil gjøre resten for deg. Fra tjenesteleverandørens synspunkt er han fullt ut ansvarlig for hele tjenesten - fra servermaskinvare og vertsoperativsystemer til database- og programvareinnstillinger.
Plattform som en tjeneste (PaaS) - når du bruker denne modellen, gir tjenesteleverandøren klienten et arbeidsstykke for tjenesten, for eksempel, la oss ta en webserver. Tjenesteleverandøren ga klienten en virtuell server (faktisk et sett med ressurser, som RAM/CPU/Storage/Nets, etc.), og installerte til og med OS og nødvendig programvare på denne serveren, men konfigurasjonen av alt dette gjøres av klienten selv og for å utføre tjenesten klienten svarer. Tjenesteleverandøren er, som i det forrige tilfellet, ansvarlig for ytelsen til fysisk utstyr, hypervisorer, selve den virtuelle maskinen, nettverkstilgjengelighet osv., men selve tjenesten er ikke lenger innenfor sitt ansvarsområde.
Infrastructure as a Service (IaaS) - denne tilnærmingen er allerede mer interessant, faktisk gir tjenesteleverandøren klienten en komplett virtualisert infrastruktur - det vil si et sett (pool) av ressurser, som CPU-kjerner, RAM, nettverk, etc. Alt annet er opp til oppdragsgiver - hva oppdragsgiver ønsker å gjøre med disse ressursene innenfor tildelt pool (kvote) - det er ikke spesielt viktig for leverandøren. Enten klienten ønsker å lage sin egen vEPC eller til og med opprette en minioperatør og tilby kommunikasjonstjenester - ingen tvil - gjør det. I et slikt scenario er tjenesteleverandøren ansvarlig for klargjøring av ressurser, deres feiltoleranse og tilgjengelighet, samt operativsystemet som lar dem slå sammen disse ressursene og gjøre dem tilgjengelige for klienten med muligheten til å øke eller redusere ressurser når som helst på forespørsel fra klienten. Klienten konfigurerer alle virtuelle maskiner og annet tinsel selv gjennom selvbetjeningsportalen og konsollen, inkludert oppsett av nettverk (unntatt eksterne nettverk).
Hva er OpenStack?
I alle tre alternativene trenger tjenesteleverandøren et OS som gjør det mulig å lage en skyinfrastruktur. Faktisk, med SaaS er mer enn én divisjon ansvarlig for hele stabelen av teknologier - det er en divisjon som er ansvarlig for infrastrukturen - det vil si at den leverer IaaS til en annen divisjon, denne divisjonen gir SaaS til kunden. OpenStack er et av skyoperativsystemene som lar deg samle en haug med svitsjer, servere og lagringssystemer i en enkelt ressurspool, dele opp dette felles bassenget i underpooler (leietakere) og gi disse ressursene til klienter over nettverket.
Openstack er et skyoperativsystem som lar deg kontrollere store grupper av dataressurser, datalagring og nettverksressurser, klargjort og administrert via API ved bruk av standard autentiseringsmekanismer.
Med andre ord, dette er et sett med gratis programvareprosjekter som er designet for å lage skytjenester (både offentlige og private) - det vil si et sett med verktøy som lar deg kombinere server- og bytteutstyr til en enkelt pool av ressurser, administrere disse ressursene, gir det nødvendige nivået av feiltoleranse .
På tidspunktet for skriving av dette materialet ser OpenStack-strukturen slik ut:
Bilde tatt fra
Hver av komponentene som er inkludert i OpenStack utfører en spesifikk funksjon. Denne distribuerte arkitekturen lar deg inkludere i løsningen settet med funksjonelle komponenter du trenger. Noen komponenter er imidlertid rotkomponenter, og fjerning av dem vil føre til fullstendig eller delvis inoperabilitet av løsningen som helhet. Disse komponentene er vanligvis klassifisert som:
- Dashbord — Nettbasert GUI for administrasjon av OpenStack-tjenester
- Keystone er en sentralisert identitetstjeneste som gir autentiserings- og autorisasjonsfunksjonalitet for andre tjenester, i tillegg til å administrere brukerlegitimasjon og deres roller.
- Neutron - en nettverkstjeneste som gir tilkobling mellom grensesnittene til ulike OpenStack-tjenester (inkludert tilkobling mellom VM-er og deres tilgang til omverdenen)
- Cinder — gir tilgang til blokklagring for virtuelle maskiner
- Nova — livssyklusstyring av virtuelle maskiner
- blikk — lagringssted for virtuelle maskinbilder og øyeblikksbilder
- Swift — gir tilgang til lagringsobjektet
- Takmåler — en tjeneste som gir mulighet til å samle inn telemetri og måle tilgjengelige og forbrukte ressurser
- Hete — orkestrering basert på maler for automatisk opprettelse og levering av ressurser
En fullstendig liste over alle prosjekter og deres formål kan sees .
Hver OpenStack-komponent er en tjeneste som utfører en spesifikk funksjon og gir en API for å administrere denne funksjonen og samhandle med andre skyoperativsystemtjenester for å skape en enhetlig infrastruktur. For eksempel leverer Nova dataressursadministrasjon og en API for tilgang til å konfigurere disse ressursene, Glance gir bildebehandling og en API for å administrere dem, Cinder gir blokklagring og en API for å administrere den, etc. Alle funksjoner henger sammen på en veldig nær måte.
Men hvis du ser på det, er alle tjenester som kjører i OpenStack til syvende og sist en slags virtuell maskin (eller container) koblet til nettverket. Spørsmålet oppstår – hvorfor trenger vi så mange elementer?
La oss gå gjennom algoritmen for å lage en virtuell maskin og koble den til nettverket og vedvarende lagring i Openstack.
- Når du oppretter en forespørsel om å opprette en maskin, enten det er en forespørsel gjennom Horizon (Dashboard) eller en forespørsel gjennom CLI, er det første som skjer autorisasjonen av forespørselen din på Keystone - kan du opprette en maskin, har den rett til å bruke dette nettverket, gjør utkastskvoten din osv.
- Keystone autentiserer forespørselen din og genererer et autentiseringstoken i svarmeldingen, som vil bli brukt videre. Etter å ha mottatt svar fra Keystone, sendes forespørselen til Nova (nova api).
- Nova-api sjekker gyldigheten av forespørselen din ved å kontakte Keystone ved å bruke det tidligere genererte autentiseringstokenet
- Keystone utfører autentisering og gir informasjon om tillatelser og begrensninger basert på dette autentiseringstokenet.
- Nova-api oppretter en oppføring for den nye VM i nova-databasen og sender forespørselen om å opprette maskinen til nova-scheduler.
- Nova-scheduler velger verten (datamaskinnoden) som VM-en skal distribueres på basert på spesifiserte parametere, vekter og soner. En registrering av dette og VM-IDen skrives til nova-database.
- Deretter kontakter nova-scheduler nova-compute med en forespørsel om å distribuere en forekomst. Nova-compute kontakter nova-conductor for å få informasjon om maskinparametere (nova-conductor er et nova-element som fungerer som en proxy-server mellom nova-database og nova-compute, og begrenser antallet forespørsler til nova-database for å unngå problemer med databasen reduksjon av konsistensbelastning).
- Nova-conductor mottar den forespurte informasjonen fra nova-database og sender den til nova-compute.
- Deretter ser nova-compute-anrop for å få bilde-IDen. Glace validerer forespørselen i Keystone og returnerer den forespurte informasjonen.
- Nova-compute kontakter nøytron for å få informasjon om nettverksparametere. I likhet med et blikk, validerer nøytron forespørselen i Keystone, hvoretter den oppretter en oppføring i databasen (portidentifikator, etc.), oppretter en forespørsel om å opprette en port og returnerer den forespurte informasjonen til nova-compute.
- Nova-compute kontakter cinder med en forespørsel om å tildele et volum til den virtuelle maskinen. I likhet med et blikk, validerer cider forespørselen i Keystone, oppretter en volumopprettingsforespørsel og returnerer den forespurte informasjonen.
- Nova-compute kontakter libvirt med en forespørsel om å distribuere en virtuell maskin med de spesifiserte parameterne.
Faktisk blir en tilsynelatende enkel operasjon med å lage en enkel virtuell maskin til en slik virvel av API-anrop mellom elementer i skyplattformen. Dessuten, som du kan se, består selv de tidligere utpekte tjenestene også av mindre komponenter som interaksjonen skjer mellom. Å lage en maskin er bare en liten del av det skyplattformen lar deg gjøre - det er en tjeneste som er ansvarlig for å balansere trafikk, en tjeneste som er ansvarlig for blokklagring, en tjeneste ansvarlig for DNS, en tjeneste som er ansvarlig for å klargjøre bare metal-servere, etc. Skyen lar deg behandle de virtuelle maskinene dine som en flokk med sauer (i motsetning til virtualisering). Hvis noe skjer med maskinen din i et virtuelt miljø - gjenoppretter du den fra sikkerhetskopier osv., men skyapplikasjoner er bygget på en slik måte at den virtuelle maskinen ikke spiller en så viktig rolle - den virtuelle maskinen "døde" - ikke noe problem - en ny er ganske enkelt opprettet, kjøretøyet er basert på malen, og som de sier, troppen la ikke merke til tapet av jagerflyet. Naturligvis sørger dette for tilstedeværelsen av orkestreringsmekanismer - ved å bruke Heat-maler kan du enkelt distribuere en kompleks funksjon som består av dusinvis av nettverk og virtuelle maskiner.
Det er alltid verdt å huske på at det ikke finnes noen skyinfrastruktur uten et nettverk – hvert element samhandler på en eller annen måte med andre elementer gjennom nettverket. I tillegg har skyen et absolutt ikke-statisk nettverk. Naturligvis er underlagsnettverket enda mer eller mindre statisk - nye noder og brytere legges ikke til hver dag, men overleggskomponenten kan og vil uunngåelig endres konstant - nye nettverk vil bli lagt til eller slettet, nye virtuelle maskiner vil dukke opp og gamle vil dø. Og som du husker fra definisjonen av skyen gitt helt i begynnelsen av artikkelen, bør ressurser tildeles brukeren automatisk og med minst (eller enda bedre, uten) intervensjon fra tjenesteleverandøren. Det vil si at den typen levering av nettverksressurser som nå eksisterer i form av en front-end i form av din personlige konto tilgjengelig via http/https og den vakthavende nettverksingeniøren Vasily som backend, er ikke en sky, selv hvis Vasily har åtte hender.
Neutron, som en nettverkstjeneste, gir en API for å administrere nettverksdelen av skyinfrastrukturen. Tjenesten driver og administrerer nettverksdelen av Openstack ved å tilby et abstraksjonslag kalt Network-as-a-Service (NaaS). Det vil si at nettverket er den samme virtuelle målbare enheten som for eksempel virtuelle CPU-kjerner eller mengden RAM.
Men før vi går videre til arkitekturen til nettverksdelen av OpenStack, la oss vurdere hvordan dette nettverket fungerer i OpenStack og hvorfor nettverket er en viktig og integrert del av skyen.
Så vi har to RED-klient-VM-er og to GREEN-klient-VM-er. La oss anta at disse maskinene er plassert på to hypervisorer på denne måten:
For øyeblikket er dette bare virtualisering av 4 servere og ingenting mer, siden så langt har alt vi har gjort er å virtualisere 4 servere, og plassere dem på to fysiske servere. Og så langt er de ikke engang koblet til nettverket.
For å lage en sky må vi legge til flere komponenter. Først virtualiserer vi nettverksdelen - vi må koble disse 4 maskinene i par, og klientene vil ha en L2-tilkobling. Du kan bruke en bryter og konfigurere en trunk i dens retning og løse alt ved hjelp av en linux-bro eller, for mer avanserte brukere, openvswitch (vi kommer tilbake til dette senere). Men det kan være mange nettverk, og å konstant skyve L2 gjennom en bryter er ikke den beste ideen - det er forskjellige avdelinger, en servicedesk, måneder med venting på at en søknad skal fullføres, uker med feilsøking - i den moderne verden er dette tilnærmingen fungerer ikke lenger. Og jo raskere et selskap forstår dette, jo lettere er det for det å komme videre. Derfor vil vi mellom hypervisorene velge et L3-nettverk som våre virtuelle maskiner skal kommunisere gjennom, og på toppen av dette L3-nettverket vil vi bygge virtuelle L2-overleggsnettverk der trafikken til våre virtuelle maskiner vil kjøre. Du kan bruke GRE, Geneve eller VxLAN som innkapsling. La oss fokusere på sistnevnte for nå, selv om det ikke er spesielt viktig.
Vi må finne VTEP et sted (jeg håper alle er kjent med VxLAN-terminologi). Siden vi har et L3-nettverk som kommer rett fra serverne, er det ingenting som hindrer oss i å plassere VTEP på selve serverne, og OVS (OpenvSwitch) er utmerket til å gjøre dette. Som et resultat fikk vi dette designet:
Siden trafikk mellom VM-er må deles, vil portene mot de virtuelle maskinene ha forskjellige vlan-nummer. Tagnummeret spiller bare en rolle innenfor én virtuell svitsj, siden når det er innkapslet i VxLAN, kan vi enkelt fjerne det, siden vi vil ha en VNI.
Nå kan vi lage våre maskiner og virtuelle nettverk for dem uten problemer.
Men hva om klienten har en annen maskin, men er på et annet nettverk? Vi trenger rooting mellom nettverk. Vi vil se på et enkelt alternativ når sentralisert ruting brukes - det vil si at trafikk rutes gjennom spesielle dedikerte nettverksnoder (vel, som regel er de kombinert med kontrollnoder, så vi vil ha det samme).
Det virker som ingenting komplisert - vi lager et brogrensesnitt på kontrollnoden, kjører trafikk til den og derfra ruter vi den dit vi trenger den. Men problemet er at RED-klienten ønsker å bruke 10.0.0.0/24-nettverket, og GREEN-klienten ønsker å bruke 10.0.0.0/24-nettverket. Det vil si at vi begynner å krysse adresserom. I tillegg ønsker ikke klienter at andre klienter skal kunne rute inn i deres interne nettverk, noe som er fornuftig. For å skille nettverkene og klientdatatrafikken vil vi tildele et eget navneområde for hver av dem. Namespace er faktisk en kopi av Linux-nettverksstabelen, det vil si at klienter i navnerom RED er fullstendig isolert fra klienter fra navneområde GRØN (vel, enten er ruting mellom disse klientnettverkene tillatt gjennom standard navneområde eller på oppstrøms transportutstyr).
Det vil si at vi får følgende diagram:
L2-tunneler konvergerer fra alle databehandlingsnoder til kontrollnoden. node hvor L3-grensesnittet for disse nettverkene er plassert, hver i et dedikert navneområde for isolasjon.
Vi glemte imidlertid det viktigste. Den virtuelle maskinen må tilby en tjeneste til klienten, det vil si at den må ha minst ett eksternt grensesnitt som den kan nås gjennom. Det vil si at vi må ut i omverdenen. Det er forskjellige alternativer her. La oss gjøre det enkleste alternativet. Vi vil legge til ett nettverk til hver klient, som vil være gyldig i leverandørens nettverk og vil ikke overlappe med andre nettverk. Nettverkene kan også krysse hverandre og se på ulike VRF-er på siden av leverandørnettverket. Nettverksdataene vil også leve i navneområdet til hver klient. Imidlertid vil de fortsatt gå ut til omverdenen gjennom ett fysisk (eller bånd, som er mer logisk) grensesnitt. For å skille klienttrafikk vil trafikk som går utenfor bli merket med en VLAN-tag som er tildelt klienten.
Som et resultat fikk vi dette diagrammet:
Et rimelig spørsmål er hvorfor ikke lage gatewayer på selve beregningsnodene? Dette er ikke et stort problem; dessuten, hvis du slår på den distribuerte ruteren (DVR), vil dette fungere. I dette scenariet vurderer vi det enkleste alternativet med en sentralisert gateway, som brukes som standard i Openstack. For høybelastningsfunksjoner vil de bruke både en distribuert ruter og akselerasjonsteknologier som SR-IOV og Passthrough, men som de sier, det er en helt annen historie. La oss først ta for oss den grunnleggende delen, og så går vi inn i detaljene.
Egentlig er ordningen vår allerede gjennomførbar, men det er et par nyanser:
- Vi må på en eller annen måte beskytte maskinene våre, det vil si sette et filter på brytergrensesnittet mot klienten.
- Gjør det mulig for en virtuell maskin å automatisk få en IP-adresse, slik at du ikke trenger å logge på den gjennom konsollen hver gang og registrere adressen.
La oss starte med maskinbeskyttelse. For dette kan du bruke banale iptables, hvorfor ikke.
Det vil si at nå har topologien vår blitt litt mer komplisert:
La oss gå videre. Vi må legge til en DHCP-server. Det mest ideelle stedet å finne DHCP-servere for hver klient vil være kontrollnoden som allerede er nevnt ovenfor, hvor navneområdene er plassert:
Det er imidlertid et lite problem. Hva om alt starter på nytt og all informasjon om leieadresser på DHCP forsvinner. Det er logisk at maskinene får nye adresser, noe som ikke er særlig praktisk. Det er to utveier her – enten bruk domenenavn og legg til en DNS-server for hver klient, da vil ikke adressen være spesielt viktig for oss (i likhet med nettverksdelen i k8s) – men det er et problem med eksterne nettverk, siden adresser kan også utstedes i dem via DHCP - du trenger synkronisering med DNS-servere i skyplattformen og en ekstern DNS-server, som etter min mening ikke er veldig fleksibel, men er fullt mulig. Eller det andre alternativet er å bruke metadata - det vil si å lagre informasjon om adressen som er utstedt til maskinen slik at DHCP-serveren vet hvilken adresse som skal utstedes til maskinen hvis maskinen allerede har mottatt en adresse. Det andre alternativet er enklere og mer fleksibelt, da det lar deg lagre tilleggsinformasjon om bilen. La oss nå legge til agentmetadata i diagrammet:
En annen sak som også er verdt å diskutere er muligheten til å bruke ett eksternt nettverk av alle klienter, siden eksterne nettverk, hvis de må være gyldige i hele nettverket, vil være vanskelige - du må hele tiden allokere og kontrollere allokeringen av disse nettverkene. Muligheten til å bruke et enkelt eksternt forhåndskonfigurert nettverk for alle klienter vil være svært nyttig når du oppretter en offentlig sky. Dette vil gjøre det enklere å distribuere maskiner fordi vi ikke trenger å konsultere en adressedatabase og velge et unikt adresseområde for hver klients eksterne nettverk. I tillegg kan vi registrere et eksternt nettverk på forhånd og ved utrulling trenger vi kun å knytte eksterne adresser til klientmaskiner.
Og her kommer NAT til hjelp – vi vil bare gjøre det mulig for klienter å få tilgang til omverdenen gjennom standardnavneområdet ved å bruke NAT-oversettelse. Vel, her er et lite problem. Dette er bra hvis klientserveren fungerer som en klient og ikke som en server - det vil si at den initierer i stedet for å godta tilkoblinger. Men for oss blir det omvendt. I dette tilfellet må vi gjøre destinasjons-NAT slik at når den mottar trafikk, forstår kontrollnoden at denne trafikken er ment for virtuell maskin A til klient A, noe som betyr at vi må gjøre en NAT-oversettelse fra en ekstern adresse, for eksempel 100.1.1.1 .10.0.0.1, til en intern adresse 100. I dette tilfellet, selv om alle klienter vil bruke samme nettverk, er intern isolasjon fullstendig bevart. Det vil si at vi må gjøre dNAT og sNAT på kontrollnoden. Om du skal bruke et enkelt nettverk med flytende adresser eller eksterne nettverk, eller begge deler samtidig, avhenger av hva du vil ha med inn i skyen. Vi vil ikke legge til flytende adresser i diagrammet, men vil la de eksterne nettverkene være lagt til tidligere - hver klient har sitt eget eksterne nettverk (i diagrammet er de indikert som vlan 200 og XNUMX på det eksterne grensesnittet).
Som et resultat fikk vi en interessant og samtidig gjennomtenkt løsning, som har en viss fleksibilitet, men som ennå ikke har feiltoleransemekanismer.
For det første har vi bare en kontrollnode - feilen vil føre til kollaps av alle systemer. For å fikse dette problemet, må du gjøre minst et quorum på 3 noder. La oss legge dette til diagrammet:
Naturligvis er alle noder synkronisert, og når en aktiv node forlater, vil en annen node overta dens ansvar.
Det neste problemet er virtuelle maskindisker. For øyeblikket er de lagret på hypervisorene selv, og i tilfelle problemer med hypervisoren mister vi alle dataene - og tilstedeværelsen av et raid vil ikke hjelpe her hvis vi mister ikke disken, men hele serveren. For å gjøre dette må vi lage en tjeneste som fungerer som frontend for en slags lagring. Hva slags lagring det blir er ikke spesielt viktig for oss, men det skal beskytte dataene våre mot feil på både disken og noden, og muligens hele kabinettet. Det er flere alternativer her - det er selvfølgelig SAN-nettverk med Fibre Channel, men la oss være ærlige - FC er allerede en relikvie fra fortiden - en analog av E1 i transport - ja, jeg er enig, den brukes fortsatt, men bare der det er helt umulig uten. Derfor ville jeg ikke frivillig distribuert et FC-nettverk i 2020, vel vitende om at det finnes andre mer interessante alternativer. Selv om det for hver sin egen kan være de som tror at FC med alle dens begrensninger er alt vi trenger - jeg vil ikke argumentere, alle har sin egen mening. Den mest interessante løsningen etter min mening er imidlertid å bruke en SDS, slik som Ceph.
Ceph lar deg bygge en svært tilgjengelig datalagringsløsning med en rekke mulige sikkerhetskopieringsalternativer, som starter med koder med paritetskontroll (analogt med raid 5 eller 6) som slutter med full datareplikering til forskjellige disker, og tar hensyn til plasseringen av disker i servere, og servere i skap, etc.
For å bygge Ceph trenger du 3 noder til. Interaksjon med lagringen vil også bli utført via nettverket ved bruk av blokk-, objekt- og fillagringstjenester. La oss legge til lagring til diagrammet:
Merk: du kan også lage hyperkonvergerte beregningsnoder - dette er konseptet med å kombinere flere funksjoner på en node - for eksempel lagring+beregning - uten å dedikere spesielle noder for ceph-lagring. Vi vil få samme feiltolerante ordning - siden SDS vil reservere data med det reservasjonsnivået vi angir. Hyperkonvergerte noder er imidlertid alltid et kompromiss - siden lagringsnoden ikke bare varmer opp luften slik den ser ut ved første øyekast (siden det ikke er noen virtuelle maskiner på den) - den bruker CPU-ressurser på å betjene SDS (faktisk gjør den alt replikering og gjenoppretting etter feil på noder, disker, etc.). Det vil si at du vil miste noe av kraften til beregningsnoden hvis du kombinerer den med lagring.
Alt dette må administreres på en eller annen måte - vi trenger noe som vi kan lage en maskin, et nettverk, en virtuell ruter, etc. For å gjøre dette, vil vi legge til en tjeneste til kontrollnoden som vil fungere som et dashbord - klienten vil kunne koble seg til denne portalen via http/ https og gjøre alt han trenger (vel, nesten).
Som et resultat har vi nå et feiltolerant system. Alle elementer i denne infrastrukturen må administreres på en eller annen måte. Det ble tidligere beskrevet at Openstack er et sett med prosjekter, som hver gir en spesifikk funksjon. Som vi ser, er det mer enn nok elementer som må konfigureres og kontrolleres. I dag skal vi snakke om nettverksdelen.
Nøytronarkitektur
I OpenStack er det Neutron som er ansvarlig for å koble virtuelle maskinporter til et felles L2-nettverk, sikre trafikkruting mellom VM-er plassert på forskjellige L2-nettverk, samt utoverruting, levere tjenester som NAT, Floating IP, DHCP, etc.
På et høyt nivå kan driften av nettverkstjenesten (grunndelen) beskrives som følger.
Når du starter VM, vil nettverkstjenesten:
- Oppretter en port for en gitt VM (eller porter) og varsler DHCP-tjenesten om det;
- En ny virtuell nettverksenhet opprettes (via libvirt);
- VM-en kobles til porten(e) opprettet i trinn 1;
Merkelig nok er Neutrons arbeid basert på standardmekanismer som er kjent for alle som noen gang har dykket ned i Linux - navneområder, iptables, linux-broer, openvswitch, conntrack, etc.
Det bør umiddelbart avklares at Neutron ikke er en SDN-kontroller.
Nøytron består av flere sammenkoblede komponenter:
Openstack-nøytron-server er en demon som fungerer med brukerforespørsler gjennom API. Denne demonen er ikke involvert i å registrere noen nettverksforbindelser, men gir den nødvendige informasjonen for dette til sine plugins, som deretter konfigurerer ønsket nettverkselement. Nøytronagenter på OpenStack-noder registrerer seg på nøytronserveren.
Neutron-server er faktisk en applikasjon skrevet i python, som består av to deler:
- REST-tjeneste
- Neutron Plugin (kjerne/tjeneste)
REST-tjenesten er utformet for å motta API-anrop fra andre komponenter (for eksempel en forespørsel om å oppgi informasjon osv.)
Plugins er plugin-programvarekomponenter/-moduler som kalles opp under API-forespørsler – det vil si at tilordningen av en tjeneste skjer gjennom dem. Plugins er delt inn i to typer - service og root. Som regel er heste-plugin-modulen hovedsakelig ansvarlig for å administrere adresseområdet og L2-forbindelsene mellom VM-er, og tjenesteplugins gir allerede tilleggsfunksjonalitet som VPN eller FW.
Listen over tilgjengelige plugins i dag kan ses for eksempel
Det kan være flere tjenesteplugins, men det kan bare være én hesteplugin.
openstack-nøytron-ml2 er standard Openstack root-plugin. Denne plugin-en har en modulær arkitektur (i motsetning til forgjengeren) og konfigurerer nettverkstjenesten gjennom drivere som er koblet til den. Vi skal se på selve plugin-en litt senere, siden den faktisk gir fleksibiliteten som OpenStack har i nettverksdelen. Rot-plugin-modulen kan erstattes (for eksempel gjør Contrail Networking en slik erstatning).
RPC-tjeneste (rabbitmq-server) — en tjeneste som gir køhåndtering og interaksjon med andre OpenStack-tjenester, samt interaksjon mellom nettverkstjenesteagenter.
Nettverksagenter — agenter som er plassert i hver node, gjennom hvilke nettverkstjenester konfigureres.
Det finnes flere typer agenter.
Hovedagenten er L2 agent. Disse agentene kjører på hver av hypervisorene, inkludert kontrollnoder (mer presist, på alle noder som tilbyr tjenester for leietakere) og deres hovedfunksjon er å koble virtuelle maskiner til et felles L2-nettverk, og også generere varsler når det oppstår hendelser ( for eksempel deaktiver/aktiver porten).
Den neste, ikke mindre viktige agenten er L3 agent. Som standard kjører denne agenten utelukkende på en nettverksnode (ofte er nettverksnoden kombinert med en kontrollnode) og gir ruting mellom leietakernettverk (både mellom nettverkene og nettverkene til andre leietakere, og er tilgjengelig for omverdenen, forutsatt at NAT, samt DHCP-tjeneste). Men når du bruker en DVR (distribuert ruter), dukker behovet for en L3-plugin også opp på beregningsnodene.
L3-agenten bruker Linux-navneområder for å gi hver leietaker et sett med sine egne isolerte nettverk og funksjonaliteten til virtuelle rutere som ruter trafikk og leverer gatewaytjenester for lag 2-nettverk.
Database – en database med identifikatorer for nettverk, undernett, porter, bassenger osv.
Faktisk godtar Neutron API-forespørsler fra opprettelsen av nettverksenheter, autentiserer forespørselen, og gjennom RPC (hvis den får tilgang til en plugin eller agent) eller REST API (hvis den kommuniserer i SDN) overfører den til agentene (via plugins) instruksjoner som er nødvendige for å organisere den forespurte tjenesten.
La oss nå gå til testinstallasjonen (hvordan den er distribuert og hva som er inkludert i den, vi vil se senere i den praktiske delen) og se hvor hver komponent er plassert:
(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 ~]$
Egentlig er det hele strukturen til Neutron. Nå er det verdt å bruke litt tid på ML2-plugin.
Modulært lag 2
Som nevnt ovenfor er plugin en standard OpenStack root plugin og har en modulær arkitektur.
Forgjengeren til ML2-pluginen hadde en monolittisk struktur, som for eksempel ikke tillot å bruke en blanding av flere teknologier i én installasjon. For eksempel kunne du ikke bruke både openvswitch og linuxbridge samtidig - verken den første eller den andre. Av denne grunn ble ML2-plugin-modulen med sin arkitektur laget.
ML2 har to komponenter - to typer drivere: Typedrivere og Mechanism-drivere.
Skriv inn drivere bestemme teknologiene som skal brukes til å organisere nettverkstilkoblinger, for eksempel VxLAN, VLAN, GRE. Samtidig tillater driveren bruk av forskjellige teknologier. Standardteknologien er VxLAN-innkapsling for overleggsnettverk og eksterne vlan-nettverk.
Typedrivere inkluderer følgende nettverkstyper:
Flate - nettverk uten tagging
VLAN - merket nettverk
lokal — en spesiell type nettverk for alt-i-ett-installasjoner (slike installasjoner er nødvendig enten for utviklere eller for opplæring)
GRE — overleggsnettverk ved hjelp av GRE-tunneler
VxLAN — overlegg nettverk ved hjelp av VxLAN-tunneler
Mekanisme sjåfører definere verktøy som sikrer organiseringen av teknologiene spesifisert i typedriveren - for eksempel openvswitch, sr-iov, opendaylight, OVN, etc.
Avhengig av implementeringen av denne driveren, vil enten agenter kontrollert av Neutron bli brukt, eller tilkoblinger til en ekstern SDN-kontroller, som tar seg av alle problemer knyttet til organisering av L2-nettverk, ruting, etc.
Eksempel: hvis vi bruker ML2 sammen med OVS, installeres en L2-agent på hver datanod som administrerer OVS. Men hvis vi bruker for eksempel OVN eller OpenDayLight, så kommer kontrollen av OVS under deres jurisdiksjon - Neutron, gjennom root-pluginen, gir kommandoer til kontrolleren, og den gjør allerede det den ble fortalt.
La oss friske opp Open vSwitch
For øyeblikket er en av nøkkelkomponentene i OpenStack Open vSwitch.
Når du installerer OpenStack uten noen ekstra SDN-leverandør som Juniper Contrail eller Nokia Nuage, er OVS hovednettverkskomponenten i skynettverket, og sammen med iptables, conntrack, navneområder, lar deg organisere fullverdige multi-tenancy overlay-nettverk. Naturligvis kan denne komponenten erstattes, for eksempel ved bruk av tredjeparts proprietære (leverandør) SDN-løsninger.
OVS er en åpen kildekode-programvaresvitsj som er designet for bruk i virtualiserte miljøer som en virtuell trafikkformidler.
For øyeblikket har OVS svært anstendig funksjonalitet, som inkluderer teknologier som QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, etc.
Merk: OVS ble i utgangspunktet ikke tenkt som en myk bryter for høyt belastede telekomfunksjoner og var mer designet for mindre båndbreddekrevende IT-funksjoner som WEB-server eller e-postserver. OVS videreutvikles imidlertid og nåværende implementeringer av OVS har forbedret ytelsen og mulighetene betydelig, noe som gjør at den kan brukes av teleoperatører med høyt belastede funksjoner, for eksempel er det en OVS-implementering med støtte for DPDK-akselerasjon.
Det er tre viktige komponenter i OVS som du må være klar over:
- Kjernemodul — en komponent plassert i kjerneområdet som behandler trafikk basert på reglene mottatt fra kontrollelementet;
- vSwitch daemon (ovs-vswitchd) er en prosess lansert i brukerrommet som er ansvarlig for å programmere kjernemodulen - det vil si at den direkte representerer logikken til svitsjens operasjon
- Databaseserver - en lokal database på hver vert som kjører OVS, der konfigurasjonen er lagret. SDN-kontrollere kan kommunisere gjennom denne modulen ved å bruke OVSDB-protokollen.
Alt dette er ledsaget av et sett med diagnose- og administrasjonsverktøy, for eksempel ovs-vsctl, ovs-appctl, ovs-ofctl, etc.
For tiden er Openstack mye brukt av teleoperatører for å migrere nettverksfunksjoner til den, som EPC, SBC, HLR osv. Noen funksjoner kan leve uten problemer med OVS som den er, men for eksempel behandler EPC abonnenttrafikk - så går den gjennom en enorm mengde trafikk (nå når trafikkvolumet flere hundre gigabit per sekund). Naturligvis er det ikke den beste ideen å kjøre slik trafikk gjennom kjerneområdet (siden speditøren er plassert der som standard). Derfor er OVS ofte utplassert utelukkende i brukerområdet ved å bruke DPDK-akselerasjonsteknologi for å videresende trafikk fra NIC til brukerrom som omgår kjernen.
Merk: for en sky som er distribuert for telekomfunksjoner, er det mulig å sende ut trafikk fra en beregningsnode som omgår OVS direkte til bytteutstyr. SR-IOV og Passthrough-mekanismer brukes til dette formålet.
Hvordan fungerer dette på en ekte layout?
Vel, la oss nå gå videre til den praktiske delen og se hvordan det hele fungerer i praksis.
Først, la oss distribuere en enkel Openstack-installasjon. Siden jeg ikke har et sett med servere tilgjengelig for eksperimenter, vil vi sette sammen prototypen på én fysisk server fra virtuelle maskiner. Ja, naturlig nok er en slik løsning ikke egnet for kommersielle formål, men for å se et eksempel på hvordan nettverket fungerer i Openstack, er en slik installasjon nok for øynene. Dessuten er en slik installasjon enda mer interessant for treningsformål - siden du kan fange trafikk osv.
Siden vi bare trenger å se den grunnleggende delen, kan vi ikke bruke flere nettverk, men heve alt ved å bruke bare to nettverk, og det andre nettverket i denne layouten vil utelukkende brukes for tilgang til underskyen og DNS-serveren. Vi skal ikke berøre eksterne nettverk foreløpig - dette er et tema for en egen stor artikkel.
Så la oss starte i rekkefølge. Først en liten teori. Vi vil installere Openstack ved hjelp av TripleO (Openstack på Openstack). Essensen av TripleO er at vi installerer Openstack alt-i-ett (det vil si på én node), kalt undercloud, og deretter bruker egenskapene til den utplasserte Openstack for å installere Openstack beregnet for drift, kalt overcloud. Undercloud vil bruke sin iboende evne til å administrere fysiske servere (bare metal) - Ironic-prosjektet - til å levere hypervisorer som vil utføre rollene som databehandling, kontroll, lagringsnoder. Det vil si at vi ikke bruker noen tredjepartsverktøy for å distribuere Openstack – vi distribuerer Openstack ved å bruke Openstack. Det vil bli mye klarere etter hvert som installasjonen skrider frem, så vi stopper ikke der og går videre.
Merk: I denne artikkelen brukte jeg for enkelhets skyld ikke nettverksisolasjon for interne Openstack-nettverk, men alt er distribuert med bare ett nettverk. Tilstedeværelsen eller fraværet av nettverksisolasjon påvirker imidlertid ikke den grunnleggende funksjonaliteten til løsningen - alt vil fungere nøyaktig som ved bruk av isolasjon, men trafikken vil flyte på samme nettverk. For en kommersiell installasjon er det naturligvis nødvendig å bruke isolasjon ved bruk av forskjellige vlans og grensesnitt. For eksempel bruker ceph-lagringsadministrasjonstrafikk og selve datatrafikken (maskintilgang til disker osv.) når de er isolert, forskjellige undernett (Storage management og Storage), og dette lar deg gjøre løsningen mer feiltolerant ved å dele denne trafikken, for eksempel , på tvers av forskjellige porter, eller ved å bruke forskjellige QoS-profiler for forskjellig trafikk slik at datatrafikk ikke presser ut signaltrafikk. I vårt tilfelle vil de gå på samme nettverk og faktisk begrenser dette oss ikke på noen måte.
Merk: Siden vi skal kjøre virtuelle maskiner i et virtuelt miljø basert på virtuelle maskiner, må vi først aktivere nestet virtualisering.
Du kan sjekke om nestet virtualisering er aktivert eller ikke slik:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Hvis du ser bokstaven N, aktiverer vi støtte for nestet virtualisering i henhold til en hvilken som helst guide du finner på nettverket, for eksempel .
Vi må sette sammen følgende krets fra virtuelle maskiner:
I mitt tilfelle, for å koble til de virtuelle maskinene som er en del av den fremtidige installasjonen (og jeg fikk 7 av dem, men du kan klare deg med 4 hvis du ikke har mange ressurser), brukte jeg OpenvSwitch. Jeg opprettet en ovs-bro og koblet virtuelle maskiner til den via port-grupper. For å gjøre dette opprettet jeg en xml-fil som dette:
[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 deklarert her - to tilgang og en trunk (sistnevnte var nødvendig for DNS-serveren, men du kan klare deg uten den, eller installere den på vertsmaskinen - avhengig av hva som er mest praktisk for deg). Deretter, ved å bruke denne malen, erklærer vi vår via virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nå redigerer vi hypervisorportkonfigurasjonene:
[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 ~]# Merk: I dette scenariet vil ikke adressen på port ovs-br1 være tilgjengelig fordi den ikke har en vlan-tag. For å fikse dette, må du gi kommandoen sudo ovs-vsctl set port ovs-br1 tag=100. Etter en omstart vil imidlertid denne taggen forsvinne (hvis noen vet hvordan den skal holde seg på plass, vil jeg være veldig takknemlig). Men dette er ikke så viktig, fordi vi bare trenger denne adressen under installasjonen og vil ikke trenge den når Openstack er fullt utplassert.
Deretter lager vi en underskymaskin:
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 installasjonen setter du alle nødvendige parametere, som maskinnavn, passord, brukere, ntp-servere osv., du kan umiddelbart konfigurere portene, men for meg personlig er det lettere å logge inn på maskinen etter installasjonen. konsollen og korriger de nødvendige filene. Hvis du allerede har et ferdig bilde, kan du bruke det, eller gjøre det jeg gjorde - last ned det minimale Centos 7-bildet og bruk det til å installere VM.
Etter vellykket installasjon bør du ha en virtuell maskin som du kan installere undersky på
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningInstaller først verktøyene som er nødvendige for installasjonsprosessen:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undersky installasjon
Vi oppretter en stackbruker, setter et passord, legger det til sudoer og gir ham muligheten til å utføre root-kommandoer gjennom sudo uten å måtte skrive inn et passord:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNå spesifiserer vi hele underskynavnet i vertsfilen:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Deretter legger vi til depoter og installerer programvaren vi trenger:
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-ansibleMerk: Hvis du ikke planlegger å installere ceph, trenger du ikke å angi ceph-relaterte kommandoer. Jeg brukte Queens-utgivelsen, men du kan bruke hvilken som helst annen du vil.
Deretter kopierer du undersky-konfigurasjonsfilen til brukerens hjemmekatalogstabel:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNå må vi korrigere denne filen, justere den til installasjonen vår.
Du må legge til disse linjene i begynnelsen av 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å, la oss gå gjennom innstillingene:
undercloud_vertsnavn – det fulle navnet på undersky-serveren må samsvare med oppføringen på DNS-serveren
lokal_ip — lokal undersky-adresse mot nettverksforsyning
nettverksgateway — den samme lokale adressen, som vil fungere som en gateway for tilgang til omverdenen under installasjonen av overskynoder, faller også sammen med lokal ip
undercloud_public_host — ekstern API-adresse, enhver ledig adresse fra klargjøringsnettverket tildeles
undercloud_admin_host intern API-adresse, tildeles enhver ledig adresse fra klargjøringsnettverket
undercloud_nameservers - DNS-server
generere_tjenestesertifikat - denne linjen er veldig viktig i det gjeldende eksemplet, fordi hvis du ikke setter den til usann, vil du få en feilmelding under installasjonen, problemet er beskrevet på Red Hat bug tracker
lokalt_grensesnitt grensesnitt i nettverksprovisionering. Dette grensesnittet vil bli rekonfigurert under undersky-distribusjon, så du må ha to grensesnitt på undercloud - ett for å få tilgang til det, det andre for klargjøring
local_mtu — MTU. Siden vi har et testlaboratorium og jeg har en MTU på 1500 på OVS-svitsjportene, er det nødvendig å sette den til 1450 slik at pakker innkapslet i VxLAN kan passere gjennom
nettverk_cidr — provisjonsnettverk
Masquerade — bruke NAT for å få tilgang til et eksternt nettverk
maskeradenettverk - nettverk som vil bli NATert
dhcp_start — startadressen til adresseutvalget som adresser vil bli tildelt til noder under oversky-distribusjon
dhcp_end — den endelige adressen til adresseutvalget som adresser vil bli tildelt til noder under oversky-distribusjon
inspection_iprange – en samling adresser som er nødvendig for introspeksjon (skal ikke overlappe med bassenget ovenfor)
scheduler_max_tempts – maksimalt antall forsøk på å installere oversky (må være større enn eller lik antall noder)
Etter at filen er beskrevet, kan du gi kommandoen for å distribuere undersky:
openstack undercloud install
Prosedyren tar fra 10 til 30 minutter avhengig av strykejernet ditt. Til syvende og sist bør du se utdata 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.
#############################################################################Denne utgangen sier at du har installert undercloud, og du kan nå sjekke statusen til undercloud og fortsette å installere overcloud.
Hvis du ser på ifconfig-utgangen, vil du se at et nytt brogrensesnitt har dukket opp
[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 0Oversky-distribusjon vil nå bli utført gjennom dette grensesnittet.
Fra utdataene nedenfor kan du se at vi har alle tjenester 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 konfigurasjonen av underskynettverksdelen:
(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 ~]$Oversky installasjon
For øyeblikket har vi bare undersky, og vi har ikke nok noder som oversky vil bli satt sammen fra. Derfor, først av alt, la oss distribuere de virtuelle maskinene vi trenger. Under utrullingen vil undercloud selv installere operativsystemet og nødvendig programvare på overskymaskinen - det vil si at vi ikke trenger å distribuere maskinen fullstendig, men bare lage en disk (eller disker) for den og bestemme dens parametere - dvs. , faktisk får vi en bar server uten et OS installert på den.
La oss gå til mappen med diskene til våre virtuelle maskiner og lage disker med ønsket størrelse:
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GSiden vi opererer som root, må vi endre eieren av disse diskene for ikke å få et problem med rettigheter:
[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]# Merk: hvis du ikke planlegger å installere ceph for å studere det, oppretter ikke kommandoene minst 3 noder med minst to disker, men i malen indikerer at virtuelle disker vda, vdb, etc. vil bli brukt.
Flott, nå må vi definere alle disse maskinene:
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 På slutten er det en kommando -print-xml > /tmp/storage-1.xml, som lager en xml-fil med en beskrivelse av hver maskin i /tmp/-mappen; hvis du ikke legger den til, blir du ikke i stand til å identifisere virtuelle maskiner.
Nå må vi definere alle disse maskinene 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 ~]#Nå en liten nyanse - tripleO bruker IPMI til å administrere servere under installasjon og introspeksjon.
Introspeksjon er prosessen med å inspisere maskinvaren for å få dens parametere som er nødvendige for videre forsyning av noder. Introspeksjon utføres ved hjelp av ironic, en tjeneste designet for å fungere med bare metallservere.
Men her er problemet - mens maskinvare IPMI-servere har en separat port (eller en delt port, men dette er ikke viktig), så har ikke virtuelle maskiner slike porter. Her kommer en krykke kalt vbmc til unnsetning – et verktøy som lar deg etterligne en IPMI-port. Denne nyansen er verdt å ta hensyn til spesielt for de som ønsker å sette opp et slikt laboratorium på en ESXI hypervisor - for å være ærlig, jeg vet ikke om den har en analog av vbmc, så det er verdt å lure på dette problemet før du distribuerer alt .
Installer vbmc:
yum install yum install python2-virtualbmcHvis operativsystemet ditt ikke finner pakken, legger du til depotet:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNå setter vi opp verktøyet. Alt her er banalt til en skam. Nå er det logisk at det ikke er noen servere i vbmc-listen
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# For at de skal vises, må de deklareres manuelt slik:
[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 tror kommandosyntaksen er klar uten forklaring. Foreløpig er imidlertid alle øktene våre i NED-status. For at de skal flytte til OPP-status, må du aktivere dem:
[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 den siste detaljen - du må korrigere brannmurreglene (eller deaktivere den helt):
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
La oss nå gå til undercloud og sjekke at alt fungerer. Adressen til vertsmaskinen er 192.168.255.200, på undercloud la vi til den nødvendige ipmitool-pakken under forberedelse til distribusjon:
[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 lansert kontrollnoden via vbmc. La oss nå slå den av 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 neste trinnet er introspeksjon av nodene som overskyen skal installeres på. For å gjøre dette må vi forberede en json-fil med en beskrivelse av nodene våre. Vær oppmerksom på at, i motsetning til installasjon på bare servere, indikerer filen porten som vbmc kjører på for hver maskin.
[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:27Merk: kontrollnoden har to grensesnitt, men i dette tilfellet er dette ikke viktig, i denne installasjonen vil en være nok for oss.
Nå forbereder vi json-filen. Vi må angi valmueadressen til porten som klargjøring skal utføres gjennom, parameterne til nodene, gi dem navn og indikere hvordan du 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"
}
]
}Nå må vi forberede bilder for ironi. For å gjøre dette, last dem ned via wget og installer:
(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 ~]$Laster opp bilder 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 ~]$Sjekker at alle bildene er lastet inn
(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 til - du må legge til 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 ~]$Nå kan vi gi kommandoen for introspeksjon:
(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 fra utgangen, ble alt fullført uten feil. La oss sjekke at alle noder er i tilgjengelig 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 nodene er i en annen tilstand, vanligvis håndterbare, så gikk noe galt, og du må se på loggen og finne ut hvorfor dette skjedde. Husk at i dette scenariet bruker vi virtualisering og det kan være feil knyttet til bruk av virtuelle maskiner eller vbmc.
Deretter må vi indikere hvilken node som skal utføre hvilken funksjon - det vil si indikere profilen som noden vil distribuere:
(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 ~]$Spesifiser 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-d9afb69d1167La oss sjekke at vi gjorde alt riktig:
(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 riktig, gir vi kommandoen for å distribuere oversky:
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 ekte installasjon vil tilpassede maler naturligvis brukes, i vårt tilfelle vil dette komplisere prosessen i stor grad, siden hver redigering i malen må forklares. Som det ble skrevet tidligere, vil selv en enkel installasjon være nok for oss å se hvordan det fungerer.
Merk: --libvirt-type qemu-variabelen er nødvendig i dette tilfellet, siden vi vil bruke nestet virtualisering. Ellers vil du ikke kunne kjøre virtuelle maskiner.
Nå har du omtrent en time, eller kanskje mer (avhengig av egenskapene til maskinvaren), og du kan bare håpe at du etter denne tiden vil se følgende melding:
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 ~]$Nå har du en nesten fullverdig versjon av openstack, som du kan studere, eksperimentere osv.
La oss sjekke at alt fungerer som det skal. I brukerens hjemmekatalogstabel er det to filer - en stackrc (for å administrere undersky) og den andre overcloudrc (for å administrere oversky). Disse filene må angis som kilde, siden de inneholder informasjon som er nødvendig for autentisering.
(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 ~]$Installasjonen min krever fortsatt ett lite trykk - å legge til en rute på kontrolleren, siden maskinen jeg jobber med er på et annet nettverk. For å gjøre dette, gå til kontroll-1 under varme-admin-kontoen og registrer ruten
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Vel, nå kan du gå inn i horisonten. All informasjon - adresser, pålogging og passord - ligger i filen /home/stack/overcloudrc. Det endelige diagrammet ser slik ut:
Forresten, i installasjonen vår ble maskinadresser utstedt via DHCP, og som du kan se, utstedes de "tilfeldig". Du kan strengt definere i malen hvilken adresse som skal knyttes til hvilken maskin under distribusjon, hvis du trenger det.
Hvordan flyter trafikken mellom virtuelle maskiner?
I denne artikkelen skal vi se på tre alternativer for passerende trafikk
- To maskiner på én hypervisor på ett L2-nettverk
- To maskiner på forskjellige hypervisorer på samme L2-nettverk
- To maskiner på forskjellige nettverk (rooting på tvers av nettverk)
Saker med tilgang til omverdenen via eksternt nettverk, bruk av flytende adresser, samt distribuert ruting, vil vi vurdere neste gang, foreløpig fokuserer vi på intern trafikk.
For å sjekke, la oss sette sammen følgende diagram:
Vi har laget 4 virtuelle maskiner - 3 på ett L2-nettverk - net-1, og 1 til på net-2-nettverket
(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 ~]$ La oss se hvilke hypervisorer de opprettede maskinene er plassert på:
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 |
(oversky) [stack@undercloud ~]$
Maskinene vm-1 og vm-3 er plassert på compute-0, maskinene vm-2 og vm-4 er plassert på noden compute-1.
I tillegg er det laget en virtuell ruter for å muliggjøre ruting mellom de angitte nettverkene:
(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 ~]$ Ruteren har to virtuelle porter, som fungerer som gatewayer for nettverk:
(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 flyter, la oss se på hva vi for øyeblikket har på kontrollnoden (som også er en nettverksnode) og på beregningsnoden. La oss 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 ~]$For øyeblikket har noden tre ovs-broer - br-int, br-tun, br-ex. Mellom dem, som vi ser, er det et sett med grensesnitt. For å lette forståelsen, la oss plotte alle disse grensesnittene på diagrammet og se hva som skjer.
Ser man på adressene som VxLAN-tunneler er hevet til, kan det ses at en tunnel er hevet til compute-1 (192.168.255.26), den andre tunnelen ser ut til kontroll-1 (192.168.255.15). Men det mest interessante er at br-ex ikke har fysiske grensesnitt, og hvis du ser på hvilke strømmer som er konfigurert, kan du se at denne broen bare kan slippe trafikk for øyeblikket.
[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 du kan se av utgangen, er adressen skrudd direkte til den fysiske porten, og ikke til det virtuelle brogrensesnittet.
[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 ~]$
I henhold til den første regelen skal alt som kom fra phy-br-ex-porten kasseres.
Faktisk er det for øyeblikket ingen andre steder for trafikk å komme inn på denne broen enn fra dette grensesnittet (grensesnittet med br-int), og etter fallene å dømme har BUM-trafikken allerede fløyet inn på broen.
Det vil si at trafikk kan forlate denne noden bare gjennom VxLAN-tunnelen og ingenting annet. Men hvis du slår på DVR-en, vil situasjonen endre seg, men det tar vi en annen gang. Når du bruker nettverksisolasjon, for eksempel ved bruk av vlans, vil du ikke ha ett L3-grensesnitt i vlan 0, men flere grensesnitt. Imidlertid vil VxLAN-trafikk forlate noden på samme måte, men også innkapslet i en slags dedikert vlan.
Vi har sortert ut beregningsnoden, la oss gå videre til kontrollnoden.
[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 si at alt er det samme, men IP-adressen er ikke lenger på det fysiske grensesnittet, men på den virtuelle broen. Dette gjøres fordi denne havnen er havnen der trafikken vil gå ut 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 porten er knyttet til br-ex-broen, og siden det ikke er noen vlan-tagger på den, er denne porten en trunk-port der alle vlans er tillatt, nå går trafikken utenfor uten en tag, som indikert av vlan-id 0 i utgang ovenfor.
Alt annet for øyeblikket ligner på beregningsnoden - de samme broene, de samme tunnelene som går til to beregningsnoder.
Vi vil ikke vurdere lagringsnoder i denne artikkelen, men for å forstå det er det nødvendig å si at nettverksdelen av disse nodene er banal til en skam. I vårt tilfelle er det bare én fysisk port (eth0) med en IP-adresse tildelt den, og det er det. Det er ingen VxLAN-tunneler, tunnelbroer osv. - det er ingen ovs i det hele tatt, siden det ikke er noen vits i det. Når du bruker nettverksisolering, vil denne noden ha to grensesnitt (fysiske porter, bodny, eller bare to vlans - det spiller ingen rolle - det avhenger av hva du vil ha) - ett for administrasjon, det andre for trafikk (skriving til VM-disken) , lesing fra disk, etc.)
Vi fant ut hva vi har på nodene i fravær av noen tjenester. La oss nå starte 4 virtuelle maskiner og se hvordan ordningen beskrevet ovenfor endres - vi bør ha porter, virtuelle rutere, etc.
Så langt ser nettverket vårt slik ut:
Vi har to virtuelle maskiner på hver datamaskinnode. Ved å bruke compute-0 som eksempel, la oss se hvordan alt er inkludert.
[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 bare ett virtuelt grensesnitt - 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 ~]$
Dette grensesnittet ser ut i 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 utgangen, er det bare to grensesnitt i broen - tap95d96a75-a0 og qvb95d96a75-a0.
Her er det verdt å dvele litt ved typene virtuelle nettverksenheter i OpenStack:
vtap - virtuelt grensesnitt knyttet til en forekomst (VM)
qbr - Linux-bro
qvb og qvo - vEth-par koblet til Linux-broen og Open vSwitch-broen
br-int, br-tun, br-vlan — Åpne vSwitch-broer
patch-, int-br-, phy-br- - Åpne vSwitch-patch-grensesnitt som kobler sammen broer
qg, qr, ha, fg, sg - Åpne vSwitch-porter som brukes av virtuelle enheter for å koble til OVS
Som du forstår, hvis vi har en qvb95d96a75-a0-port i broen, som er et vEth-par, så er det et eller annet sted dets motstykke, som logisk sett burde hete qvo95d96a75-a0. La oss se hvilke porter som er 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 svitsj som avslutter virtuelle maskinporter. I tillegg til qvo95d96a75-a0, er porten qvo5bd37136-47 synlig i utgangen. Dette er porten til den andre virtuelle maskinen. Som et resultat ser diagrammet vårt nå slik ut:
Et spørsmål som umiddelbart bør interessere den oppmerksomme leseren - hva er linux-broen mellom den virtuelle maskinporten og OVS-porten? Faktum er at for å beskytte maskinen brukes sikkerhetsgrupper, som ikke er mer enn iptables. OVS fungerer ikke med iptables, så denne "krykken" ble oppfunnet. Den begynner imidlertid å bli foreldet - den erstattes av conntrack i nye utgivelser.
Det vil si at opplegget til syvende og sist ser slik ut:
To maskiner på én hypervisor på ett L2-nettverk
Siden disse to VM-ene er plassert på samme L2-nettverk og på samme hypervisor, vil trafikken mellom dem logisk flyte lokalt gjennom br-int, siden begge maskinene vil være på 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å forskjellige hypervisorer på samme L2-nettverk
La oss nå se hvordan trafikken vil gå mellom to maskiner på samme L2-nettverk, men plassert på forskjellige hypervisorer. For å være ærlig, ingenting vil endre mye, bare trafikk mellom hypervisorer vil gå gjennom vxlan-tunnelen. La oss se på et eksempel.
Adresser til virtuelle maskiner som vi vil se trafikk mellom:
[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 ~]$ Vi ser på videresendingstabellen 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 - la oss se hva slags 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 si grensesnittet i br-tun. La oss se hva som skjer 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 i VxLAN og sendes til port 2. La oss se hvor port 2 leder:
[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 ~]$La oss gå til compute-1 og se hva som skjer videre 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 er i br-int-videresendingstabellen på compute-1, og som man kan se fra utdataene ovenfor, er den synlig gjennom port 2, som er porten mot 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:46Vel, da ser vi at i br-int på compute-1 er det en destinasjonsvalmue:
[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 si at den mottatte pakken vil fly til port 3, bak som det allerede er en virtuell maskinforekomst-00000003.
Det fine med å distribuere Openstack for læring på virtuell infrastruktur er at vi enkelt kan fange opp trafikk mellom hypervisorer og se hva som skjer med den. Dette er hva vi skal gjøre nå, kjør tcpdump på vnet-porten mot 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 linjen viser at Patek fra adresse 10.0.1.85 går til adresse 10.0.1.88 (ICMP-trafikk), og den er pakket inn i en VxLAN-pakke med vni 22 og pakken går fra vert 192.168.255.19 (compute-0) til vert 192.168.255.26 .1 (beregning-XNUMX). Vi kan sjekke at VNI samsvarer med den som er spesifisert i ovs.
La oss gå tilbake til denne linjen actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 er vni i heksadesimalt tallsystem. La oss konvertere dette tallet til det 16. systemet:
16 = 6*16^0+1*16^1 = 6+16 = 22Det vil si at vni tilsvarer virkeligheten.
Den andre linjen viser returtrafikk, vel, det er ingen vits i å forklare det, alt er klart der.
To maskiner på forskjellige nettverk (ruting mellom nettverk)
Det siste tilfellet for i dag er ruting mellom nettverk innenfor ett prosjekt ved hjelp av en virtuell ruter. Vi vurderer en sak uten DVR (vi vil se på den i en annen artikkel), så ruting skjer på nettverksnoden. I vårt tilfelle er ikke nettverksnoden plassert i en egen enhet og er plassert på kontrollnoden.
La oss først se at ruting 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 msSiden i dette tilfellet må pakken gå til gatewayen og rutes dit, må vi finne ut poppy-adressen til gatewayen, som vi ser på ARP-tabellen for i forekomsten:
$ 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 eth0La oss nå se hvor trafikken med destinasjon (10.0.1.254) fa:16:3e:c4:64:70 skal sendes:
[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 ~]$ La oss se på hvor port 2 fører:
[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. La oss se hvilken vxlan-tunnel den vil bli pakket inn 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 porten 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å kontrollnoden:
[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ådd kontrollnoden, så vi må gå til den og se hvordan ruting vil skje.
Som du husker, så kontrollnoden inne nøyaktig lik ut som beregningsnoden - de samme tre broene, bare br-ex hadde en fysisk port som noden kunne sende trafikk utover. Opprettelsen av forekomster endret konfigurasjonen på beregningsnodene - linux-broen, iptables og grensesnitt ble lagt til nodene. Opprettelsen av nettverk og en virtuell ruter satte også sitt preg på konfigurasjonen av kontrollnoden.
Så det er åpenbart at gateway-MAC-adressen må være i br-int-videresendingstabellen på kontrollnoden. La oss sjekke at den er der og hvor den ser:
[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 tilbake til listen over virtuelle porter i Openstack, brukes denne typen porter for å koble ulike virtuelle enheter til OVS. For å være mer presis er qr en port til den virtuelle ruteren, som er representert som et navneområde.
La oss se hvilke navneområder som 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 ~]$ Så mange som tre eksemplarer. Men etter navnene å dømme, kan du gjette formålet med hver av dem. Vi kommer tilbake til forekomster med ID 0 og 1 senere, nå er vi interessert i navneområdet 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 ~]$ Dette navnerommet inneholder to interne som vi opprettet tidligere. Begge virtuelle portene er lagt til br-int. La oss sjekke mac-adressen til porten qr-0c52b15f-8f, siden trafikken, å dømme etter destinasjons-mac-adressen, gikk til dette grensesnittet.
[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 si at i dette tilfellet fungerer alt i henhold til lovene for standard ruting. Siden trafikken er bestemt for vert 10.0.2.8, må den gå ut gjennom det andre grensesnittet qr-92fa49b5-54 og gå gjennom 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. La oss se hvor valmueadressen til vert 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, la oss se hvilken tunnel trafikken går inn i neste 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 inn i tunnelen for å beregne-1. Vel, på compute-1 er alt enkelt - fra br-tun går pakken til br-int og derfra til det virtuelle maskingrensesnittet:
[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 ~]$ La oss sjekke at dette faktisk er riktig grensesnitt:
[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 gikk vi hele veien gjennom pakken. Jeg tror du la merke til at trafikken gikk gjennom forskjellige vxlan-tunneler og gikk ut med forskjellige VNI-er. La oss se hva slags VNI dette er, hvoretter vi vil samle en dump på kontrollporten til noden og sørge for at trafikken flyter nøyaktig som beskrevet ovenfor.
Så tunnelen til compute-0 har følgende actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. La oss konvertere 0x16 til desimaltallsystemet:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunnelen til compute-1 har følgende VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. La oss konvertere 0x63 til desimaltallsystemet:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Vel, la oss nå se på dumpen:
[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 pakken er en vxlan-pakke fra vert 192.168.255.19 (compute-0) til vert 192.168.255.15 (kontroll-1) med vni 22, i hvilken en ICMP-pakke er pakket fra vert 10.0.1.85 til vert 10.0.2.8. Som vi beregnet ovenfor, samsvarer vni med det vi så i utdataene.
Den andre pakken er en vxlan-pakke fra vert 192.168.255.15 (kontroll-1) til vert 192.168.255.26 (compute-1) med vni 99, i hvilken en ICMP-pakke er pakket fra vert 10.0.1.85 til vert 10.0.2.8. Som vi beregnet ovenfor, samsvarer vni med det vi så i utdataene.
De neste to pakkene er returtrafikk fra 10.0.2.8 ikke 10.0.1.85.
Det vil si at vi til slutt fikk følgende kontrollnodeskjema:
Ser det ut som det er det? Vi glemte to navneområder:
[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 ~]$ Da vi snakket om arkitekturen til skyplattformen, ville det være bra om maskiner mottok adresser automatisk fra en DHCP-server. Dette er to DHCP-servere for våre to nettverk 10.0.1.0/24 og 10.0.2.0/24.
La oss sjekke at dette er sant. Det er bare én adresse i dette navneområdet - 10.0.1.1 - adressen til selve DHCP-serveren, og den er også inkludert 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 0La oss se om prosesser som inneholder qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 i navnet på kontrollnoden:
[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 ~]$ Det er en slik prosess, og basert på informasjonen presentert i utgangen ovenfor, kan vi for eksempel se hva vi har til leie for øyeblikket:
[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 et resultat får vi følgende sett med tjenester på kontrollnoden:
Vel, husk - dette er bare 4 maskiner, 2 interne nettverk og en virtuell ruter... Vi har ikke eksterne nettverk her nå, en haug med forskjellige prosjekter, hver med sine egne nettverk (overlappende), og vi har en distribuert ruter slått av, og til slutt Det var tross alt bare en kontrollnode i testbenken (for feiltoleranse må det være et quorum på tre noder). Det er logisk at i handel er alt "litt" mer komplisert, men i dette enkle eksempelet forstår vi hvordan det skal fungere - om du har 3 eller 300 navnerom er selvfølgelig viktig, men fra synspunktet om driften av hele struktur, ingenting vil endre seg mye ... men før du ikke vil koble til noen leverandør SDN. Men det er en helt annen historie.
Jeg håper det var interessant. Hvis du har kommentarer/tilføyelser, eller et sted jeg rett og slett løy (jeg er menneskelig og min mening vil alltid være subjektiv) - skriv hva som må rettes/legges til - vi retter/legger til alt.
Avslutningsvis vil jeg si noen ord om å sammenligne Openstack (både vanilje og leverandør) med skyløsningen fra VMWare - jeg har fått dette spørsmålet for ofte i løpet av de siste par årene, og ærlig talt er jeg allerede lei av det, men likevel. Etter min mening er det veldig vanskelig å sammenligne disse to løsningene, men vi kan definitivt si at det er ulemper ved begge løsningene og når du velger én løsning må du veie fordeler og ulemper.
Hvis OpenStack er en fellesskapsdrevet løsning, så har VMWare rett til å gjøre bare det de vil (les - hva som er lønnsomt for det) og dette er logisk - fordi det er et kommersielt selskap som er vant til å tjene penger på sine kunder. Men det er ett stort og fett MEN - du kan gå av OpenStack, for eksempel fra Nokia, og med små kostnader bytte til en løsning fra for eksempel Juniper (Contrail Cloud), men du vil neppe klare å gå av VMWare . For meg ser disse to løsningene slik ut - Openstack (leverandør) er et enkelt bur du blir satt i, men du har en nøkkel og du kan gå når som helst. VMWare er et gullbur, eieren har nøkkelen til buret og det vil koste deg mye.
Jeg promoterer verken det første produktet eller det andre - du velger det du trenger. Men hvis jeg hadde et slikt valg, ville jeg valgt begge løsningene - VMWare for IT-skyen (lav belastning, enkel administrasjon), OpenStack fra en eller annen leverandør (Nokia og Juniper leverer veldig gode nøkkelferdige løsninger) - for Telecom-skyen. Jeg ville ikke brukt Openstack for ren IT - det er som å skyte spurver med en kanon, men jeg ser ingen kontraindikasjoner for å bruke det annet enn redundans. Å bruke VMWare i telekom er imidlertid som å frakte pukk i en Ford Raptor - det er vakkert fra utsiden, men sjåføren må ta 10 turer i stedet for én.
Etter min mening er den største ulempen med VMWare dens fullstendige lukkethet - selskapet vil ikke gi deg noen informasjon om hvordan det fungerer, for eksempel vSAN eller hva som er i hypervisorkjernen - det er rett og slett ikke lønnsomt for det - det vil si at du vil aldri bli en ekspert på VMWare - uten leverandørstøtte er du dømt (veldig ofte møter jeg VMWare-eksperter som blir forvirret av trivielle spørsmål). For meg kjøper VMWare en bil med panseret låst - ja, du har kanskje spesialister som kan bytte registerreim, men det er kun den som har solgt deg denne løsningen som kan åpne panseret. Personlig liker jeg ikke løsninger som jeg ikke kan passe inn i. Du vil si at du kanskje ikke trenger å gå under panseret. Ja, dette er mulig, men jeg skal se på deg når du trenger å sette sammen en stor funksjon i skyen fra 20-30 virtuelle maskiner, 40-50 nettverk, hvorav halvparten ønsker å gå utenfor, og den andre halvdelen ber om SR-IOV-akselerasjon, ellers trenger du flere et par dusin av disse bilene - ellers vil ikke ytelsen være nok.
Det er andre synspunkter, så det er bare du som kan bestemme hva du skal velge, og viktigst av alt, du vil da være ansvarlig for valget ditt. Dette er bare min mening - en person som har sett og rørt ved minst 4 produkter - Nokia, Juniper, Red Hat og VMWare. Det vil si at jeg har noe å sammenligne med.
Kilde: www.habr.com