Introduktion till nätverksdelen av molninfrastruktur

Molntjänster tränger djupare och djupare in i våra liv, och det finns nog ingen person som åtminstone en gång inte har använt någon form av molntjänst. Men vad är egentligen ett moln och hur fungerar det? Det är det få känner till ens på idénivå. 5G blir nu en verklighet och telekominfrastrukturen börjar övergå från traditionella lösningar till molnbaserade lösningar, liksom man tidigare övergick från helt hårdvarubaserade lösningar till virtualiserade "pelare".

I dag kommer vi att diskutera den interna världen av molninfrastruktur, särskilt grunderna i nätverksdelen.

Vad är ett moln? Är det samma som virtualisering – en profilvy?

En mer än logisk fråga. Nej – det är inte virtualisering, även om det är involverat. Låt oss titta på två definitioner:

Molntjänster (hädanefter Molnet) är en modell för att tillhandahålla användarvänlig åtkomst till distribuerade datorkällor, som ska kunna distribueras och startas på begäran med minimal fördröjning och minimala kostnader för serviceleverantören.

Virtualisering är möjligheten att dela en fysisk enhet (till exempel en server) i flera virtuella enheter, vilket därmed ökar resursutnyttjandet (till exempel hade du 3 servrar som var belastade till 25-30 procent, efter virtualisering får du 1 server belastad till 80-90 procent). Självklart tar virtualisering en del av resurserna – du måste ge stöd åt hypervisorn, men som erfarenheten har visat, är det värt mödan. Ett perfekt exempel på virtualisering är VMWare, som utmärkt skapar virtuella maskiner, eller till exempel KVM, som jag föredrar, men det är en smaksak.

Vi använder virtualisering utan att ens förstå det, och även hårdvaruroutrar använder redan virtualisering – till exempel i de senaste versionerna av JunOS installeras operativsystemet som en virtuell maskin ovanpå en realtidslinuxdistribution (Wind River 9). Men virtualisering är inte ett moln; dock kan ett moln inte existera utan virtualisering.

Virtualisering är en av byggstenarna som molnet byggs på.

Att göra en molnstruktur genom att helt enkelt sammanföra flera hypervisorer i ett enda L2-domän, lägga till några YAML-spelplaner för automatisk konfiguration av VLAN via någon ansible och slå på något som en orkestreringssystem för automatisk skapelse av virtuella maskiner – kommer inte att fungera. Snarare kommer det att fungera, men den resulterande Frankensteinen är inte det moln vi behöver, även om det kan vara drömmen för vissa. Dessutom, om man tar OpenStack – är det egentligen ett sådant Frakenstein, men låt oss inte gå in på det just nu.

Men jag förstår att det från den ovan presenterade definitionen inte är helt klart vad som egentligen kan kallas moln.

Därför har NIST (National Institute of Standards and Technology) i sitt dokument angett 5 grundläggande egenskaper som en molninfrastruktur måste ha:

Service på begäran. Användaren ska ha fri tillgång till de dedikerade datorkällorna (såsom nätverk, virtuella diskar, minne, processorerkärnor etc.), och dessa resurser ska tillhandahållas automatiskt – det vill säga utan inblandning från tjänsteleverantören.

Bred tillgång till tjänster. Tillgång till resurser ska ske genom standarder mekanismer för att möjliggöra användning av både vanliga datorer samt tunna klienter och mobila enheter.

Sammanställning av resurser i pooler. Resurspooler måste tillhandahålla samtidiga resurser till flera kunder, säkerställa kundisolering och avsaknad av ömsesidig påverkan samt konkurrens om resurser. Poolerna inkluderar även nätverk, vilket visar på möjligheten att använda överlappande adressering. Poolerna ska stödja skalbarhet på begäran. Användning av pooler gör det möjligt att säkerställa nödvändig nivå av resiliens för resurser och abstrahera fysiska och virtuella resurser – servicemottagaren får helt enkelt det uppsättning resurser som efterfrågas (var dessa resurser ligger fysiskt, på hur många servrar och switchar – är ointressant för kunden). Men det måste beaktas att leverantören ska säkerställa en transparent reserv av dessa resurser.

Snabb anpassning till olika förhållanden. Tjänster måste vara flexibla – snabb tillgång till resurser, omfördelning, tillägg eller minskning av resurser på kundens begäran, där kunden ska ha intrycket av att molnets resurser är oändliga. För enkelhetens skull, till exempel, ser du inte en varning om att du har förlorat en del av ditt utrymme i Apple iCloud för att en hårddisk kraschat på servern – hårddiskar går faktiskt sönder. Dessutom är möjligheterna med denna tjänst praktiskt taget gränslösa för dig – behöver du 2 Tb – inga problem, betala och få det. Man kan också ta ett exempel med Google.Drive eller Yandex.Disk.

Möjlighet att mäta den tjänst som tillhandahålls. Molnsystem måste automatiskt övervaka och optimera de resurser som förbrukas, och dessa mekanismer måste vara transparenta både för användaren och för tjänsteleverantören. Det betyder att du alltid kan kontrollera hur mycket resurser du och dina kunder förbrukar.

Det är värt att notera att dessa krav i de flesta fall gäller för offentliga moln, så för privata moln (dvs. moln som körs för företagets interna behov) kan dessa krav justeras något. Men de måste fortfarande uppfyllas, annars får vi inte alla fördelar med molnberäkningar.

Varför behöver vi molnet?

Men varje ny eller redan existerande teknologi, varje nytt protokoll skapas för något (förutom RIP-ng förstås). Ett protokoll enbart för protokollets skull – ingen är intresserad av det (förutom RIP-ng naturligtvis). Det är logiskt att molnet skapas för att erbjuda någon slags tjänst till användaren/kunden. Vi är alla bekanta med åtminstone några molntjänster, till exempel Dropbox eller Google.Docs, och jag antar att de flesta framgångsrikt använder dem – till exempel är denna artikel skriven med hjälp av molntjänsten Google.Docs. Men de molntjänster vi känner till är bara en del av molnets möjligheter – snarare är de bara tjänster av typen SaaS. Vi kan erbjuda en molntjänst på tre sätt: som SaaS, PaaS eller IaaS. Vilken tjänst just du behöver beror på dina önskemål och möjligheter.

Låt oss gå igenom dem i ordning:

Programvara som tjänst (SaaS) — detta är en modell för att tillhandahålla en fullständig tjänst till kunden, till exempel e-posttjänster som Yandex.Mail eller Gmail. I en sådan tjänstemodell gör du som kund egentligen ingenting annat än att använda tjänsten — det vill säga du behöver inte tänka på inställningen av tjänsten, dess redundans eller backup. Huvudsaken är att inte kompromettera ditt lösenord, allt annat ordnar tjänsteleverantören. Med tanke på tjänsteleverantören — tar de fullt ansvar för hela tjänsten — från serverutrustning och värdansoperativsystem, till inställningar av databaser och mjukvara.

Platform as a Service (PaaS) — vid användning av denna modell tillhandahåller tjänsteleverantören till kunden en mall för tjänsten, låt oss ta en webserver som exempel. Tjänsteleverantören har tillhandahållit kunden en virtuell server (i huvudsak en uppsättning resurser som RAM/CPU/Lagring/Nät etc.), och även installerat operativsystemet och nödvändig mjukvara på den virtuella servern. Dock gör kunden alla inställningar och ansvarar för tjänstens funktionalitet. Tjänsteleverantören ansvarar, liksom i det tidigare fallet, för funktionaliteten hos den fysiska utrustningen, hypervisorerna, den virtuella maskinen, dess nätverkstillgänglighet etc., men själva tjänsten faller utanför deras ansvar.

Infrastructure as a Service (IaaS) — denna modell är redan mer intressant, i praktiken tillhandahåller tjänsteleverantören en fullständig virtualiserad infrastruktur till kunden — det vill säga en uppsättning (pool) av resurser, såsom CPU-kärnor, RAM, nätverk etc. Allt annat är kundens ansvar — vad kunden vill göra med dessa resurser inom den tilldelade poolen (kvoten) är inte särskilt viktigt för tjänsteleverantören. Om kunden vill skapa sitt eget vEPC eller till och med agera som en minioperatör och erbjuda telekommunikationstjänster — inget problem — gör det. I ett sådant scenario ansvarar tjänsteleverantören för tillhandahållandet av resurser, deras redundans och tillgänglighet, samt för operativsystemet som möjliggör sammanställning av dessa resurser i pooler och tillhandahåller dem till kunden med möjlighet att när som helst öka eller minska resurserna på begäran av kunden. Alla virtuella maskiner och annan utrustning konfigurerar kunden själv genom självbetjäningportalen och konsolen, inklusive nätverkskonfiguration (förutom externa nätverk).

Vad är OpenStack?

I alla tre varianter behövs ett operativsystem som möjliggör skapandet av en molninfrastruktur. I praktiken ansvarar emellertid inte en enhet för hela teknikstacken vid SaaS — det finns en enhet som ansvarar för infrastrukturen — det vill säga som tillhandahåller IaaS till en annan enhet, och denna enhet erbjuder SaaS till kunden. OpenStack är ett av de molnbaserade operativsystem som gör det möjligt att sammanföra en mängd switchar, servrar och lagringssystem till en enhetlig resurspool, dela upp denna gemensamma pool i undergrupper (tenants) och tillhandahålla dessa resurser till kunder via nätverket.

OpenStack — det är ett molnbaserat operativsystem som gör det möjligt att kontrollera stora pooler av datorkraft, datalagring och nätverksresurser, vars provisionering och hantering sker via API med hjälp av standardiserade autentiseringsmekanismer.

Med andra ord är detta ett komplex av fri programvara som är avsett för att skapa molntjänster, (både offentliga och privata) — det vill säga en uppsättning verktyg som möjliggör att förena server- och switchutrustning till en gemensam resurspool och hantera dessa resurser, vilket säkerställer nödvändig nivå av redundans.

Vid tidpunkten för skrivandet av detta material ser strukturen av OpenStack ut så här:

Bilden hämtad från openstack.org

Varje komponent som ingår i OpenStack utför en specifik funktion. Denna distribuerade arkitektur möjliggör att inkludera de funktionella komponenter som du behöver i lösningen. Men vissa komponenter är grundläggande och deras borttagning leder till fullständig eller delvis funktionsfel för lösningen som helhet. Sådana komponenter brukar inkludera:

• Dashboard — GUI baserat på webben för att hantera OpenStack-tjänster
• Keystone — en centraliserad identifieringstjänst som erbjuder autentisering och auktorisering för andra tjänster, samt hanterar användardata och deras roller.
• Neutron — nätverkstjänst som säkerställer anslutning mellan gränssnitten för olika OpenStack-tjänster (inklusive anslutning mellan VM och deras tillgång utanför världen)
• Cinder — ger åtkomst till blocklagring för virtuella maskiner
• Nova — hantering av livscykeln för virtuella maskiner
• Glance — ett repository för bilder av virtuella maskiner och snapshots
• Swift — tillhandahåller åtkomst till objektlagring
• Ceilometer — en tjänst som möjliggör insamling av telemetri och mätning av resurser som används och de som behövs
• Heat — orkestrering baserad på mallar för automatisk skapelse och provisionering av resurser

Den fullständiga listan över alla projekt och deras syften kan ses ). Ett typiskt exempel på användning:.

Varje komponent i OpenStack är en tjänst som ansvarar för en viss funktion och erbjuder ett API för att hantera denna funktion och interagera med andra tjänster i det molnbaserade operativsystemet för att skapa en enhetlig infrastruktur. Till exempel hanterar Nova beräkningsresurser och erbjuder API för att konfigurera dessa resurser, Glance – hantering av bilder och API för att administrera dem, Cinder – blocklagring och API för att hantera den, etc. Alla funktioner är mycket tätt sammankopplade.

Men om man tänker efter, representerar alla tjänster som körs i OpenStack i slutändan någon typ av virtuell maskin (eller container) kopplad till nätverket. Frågan är — varför behöver vi så många element?

Låt oss gå igenom algoritmen för att skapa en virtuell maskin och koppla den till nätverket och lagringen i OpenStack.

1. När du skapar en begäran om att skapa en maskin, oavsett om det är en begäran via Horizon (Dashboard) eller via CLI, är det första som händer — autentisering av din begäran i Keystone — om du kan skapa en maskin, har rätt att använda det här nätverket, om ditt projekt har tillräckligt med kvoter, etc.
2. Keystone autentiserar din begäran och genererar i svaret en auth-token som kommer att användas senare. Efter att ha fått svar från Keystone skickas begäran vidare till Nova (nova api).
3. Nova-api kontrollerar giltigheten av din begäran genom att fråga Keystone, med den tidigare genererade auth-token.
4. Keystone utför autentisering och tillhandahåller baserat på denna auth-token information om behörigheter och begränsningar.
5. Nova-api skapar en post om den nya VM:en i nova-databasen och skickar begäran om att skapa maskinen till nova-scheduler.
6. Nova-scheduler väljer den värd (datorknuten) där VM kommer att distribueras baserat på angivna parametrar, vikter och zoner. Information om detta och ID:t för VM sparas i nova-database.
7. Därefter kontaktar nova-scheduler nova-compute för att begära distribution av instansen. Nova-compute kontaktar nova-conductor för att få information om maskinens parametrar (nova-conductor är en del av nova som fungerar som en proxyserver mellan nova-database och nova-compute, vilket begränsar antalet begärningar till nova-database för att undvika problem med databasens konsistens och minska belastningen).
8. Nova-conductor får den begärda informationen från nova-database och vidarebefordrar den till nova-compute.
9. Därefter kontaktar nova-compute glance för att få bildens ID. Glance validerar begäran i Keystone och returnerar den begärda informationen.
10. Nova-compute kontaktar neutron för att få information om nätverksparametrar. På samma sätt som glance validerar neutron begäran i Keystone, skapar den sedan en post i databasen (portens ID osv.), gör en begäran om att skapa en port och returnerar den begärda informationen till nova-compute.
11. Nova-compute kontaktar cinder för att begära tildelning av en volym till den virtuella maskinen. På samma sätt som glance validerar cinder begäran i Keystone, gör den en begäran om att skapa en volym och återger den begärda informationen.
12. Nova-compute kontaktar libvirt för att begära distribution av en virtuell maskin med angivna parametrar.

I själva verket verkar en till synes enkel operation för att skapa en grundläggande virtuell maskin förvandlas till en virvelvind av API-anrop mellan elementen på molnplattformen. Dessutom, som du ser, består även tidigare nämnda tjänster av mindre komponenter som interagerar med varandra. Att skapa en maskin är bara en liten del av vad molnplattformen erbjuder — det finns en tjänst som ansvarar för trafikbalansering, en tjänst för blocklagring, en tjänst för DNS, en tjänst för provisioning av bare metal-servrar, och så vidare. Molnet gör att du kan hantera dina virtuella maskiner som en flock får (till skillnad från virtualisering). Om något händer med maskinen i den virtuella miljön — återställer du den från säkerhetskopior osv., medan molnapplikationer är byggda på ett sätt där den virtuella maskinen inte spelar en så viktig roll — den virtuella maskinen "dog" — ingen fara — en ny maskin skapas helt enkelt baserat på en mall och, som man säger, truppen märkte inte förlusten av en soldat. Självklart förutsätter detta att det finns orkestreringsmekanismer — genom att använda Heat-mallar kan du utan större problem rulla ut en komplex funktion bestående av tiotals nätverk och virtuella maskiner.

Det är alltid viktigt att ha i åtanke att en molninfrastruktur inte kan existera utan nätverk — varje element interagerar på något sätt med andra element via nätverket. Dessutom är molnet inte ett statiskt nätverk. Självklart är underlay-nätverket mer eller mindre statiskt — det tillkommer inte nya noder och switchar varje dag, men overlay-delen kan och kommer oundvikligen att förändras ständigt — nya nätverk kommer att läggas till eller tas bort, nya virtuella maskiner kommer att tillkomma och gamla kommer att dö. Och som du minns från definitionen av molnet som gavs i början av artikeln — resurser ska tilldelas användaren automatiskt och med minsta möjliga (eller helst ingen) inblandning från tjänsteleverantören. Det vill säga den typ av resursfördelning som finns nu i form av frontend via ditt personliga konto tillgängligt via http/https och den tjänstgörande nätverksingenjören Vasja som backend — det är inte ett moln, även om Vasja har åtta armar.

Neutron, som en nätverks tjänst, tillhandahåller ett API för att hantera nätverksdelen av molninfrastrukturen. Tjänsten säkerställer funktionalitet och hantering av nätverksdelen av OpenStack, vilket ger en nivå av abstraktion kallad Network-as-a-Service (NaaS). Det innebär att nätverket är en lika virtuell mätbar enhet som till exempel virtuella CPU-kärnor eller RAM-minneskapacitet.

Men innan vi går vidare till arkitekturen för nätverksdelen av OpenStack, låt oss titta på hur nätverket fungerar inom OpenStack och varför nätverket är en viktig och integrerad del av molnet.

Så, vi har två virtuella maskiner för kunden RED och två virtuella maskiner för kunden GREEN. Anta att dessa maskiner är placerade på två hypervisorer på följande sätt:

Just nu handlar det bara om virtualisering av fyra servrar och inte mer, eftersom vi hittills bara har virtualiserat fyra servrar och placerat dem på två fysiska servrar. Dessutom är de för tillfället inte ens anslutna till nätverket.

För att få till ett moln måste vi lägga till flera komponenter. För det första behöver vi virtualisera nätverksdelen – vi måste koppla samman dessa fyra maskiner parvis, och kunderna vill ha just L2-anslutning. Man kan självklart använda en switch och ställa in trunk i dess riktning och fixa allt med en Linux-bro, eller för mer avancerade användare openvswitch (vi kommer att återkomma till det). Men det kan finnas många nätverk, och kontinuerligt trycka L2 genom en switch är inte den bästa idén – olika avdelningar, servicedesk, månader av väntan på att få sin ansökan utförd, veckor av felsökning – i dagens moderna värld fungerar sådana tillvägagångssätt inte längre. Ju tidigare företaget förstår detta, desto lättare blir det att gå framåt. Därför kommer vi att styra en L3-nätverk mellan hypervisorerna genom vilket våra virtuella maskiner kommer att kommunicera, och ovanpå detta L3-nätverk bygger vi virtuella överlagrade L2-nätverk där trafiken från våra virtuella maskiner kommer att flöda. För kapsling kan vi använda GRE, Geneve eller VxLAN. Vi stannar vid den sista, även om det inte är så viktigt.

Vi behöver placera VTEP någonstans (jag hoppas att alla är bekanta med termen VxLAN). Eftersom L3-nätverket redan kommer från servrarna, finns det ingenting som hindrar oss från att placera VTEP på själva servrarna, och OVS (OpenvSwitch) klarar detta utmärkt. I slutändan fick vi en sådan konstruktion:

Eftersom trafiken mellan VM måste separeras kommer portarna mot de virtuella maskinerna att ha olika VLAN-nummer. Taggnummret spelar bara roll inom en virtuell switch, eftersom vi kan ta bort det utan problem vid inkapsling i VxLAN, eftersom vi har VNI.

Nu kan vi skapa våra maskiner och virtuella nätverk för dem utan några problem.

Men vad händer om kunden har en annan maskin, men den befinner sig i ett annat nätverk? Vi behöver routing mellan nätverken. Vi kommer att gå igenom ett enkelt alternativ där centraliserad routing används — det vill säga trafiken routas genom specialiserade dedikerade nätverksnoder (ofta kombinerade med kontrollnoder, så det blir samma sak).

Det verkar inte vara något komplicerat — vi gör en brygggränssnitt på kontrollnoden, skickar trafiken dit och routerar den därifrån dit vi behöver. Men problemet är att kunden RED vill använda nätverket 10.0.0.0/24, och kunden GREEN vill använda nätverket 10.0.0.0/24. Det innebär att vi får en överlappning av adresser. Dessutom vill kunderna inte att andra kunder ska kunna routas till deras interna nätverk, vilket är rimligt. För att separera nätverken och kundernas datatrafik kommer vi att tilldela varje kund ett separat namespace. Namespace är faktiskt en kopia av Linux nätverksstack, vilket innebär att kunder i namespace RED är helt isolerade från kunder i namespace GREEN (eller så tillåts routing mellan dessa kunders nätverk via default namespace eller på högre transportutrustning).

Så vi får följande schema:

L2-tunnlar konvergerar från alla beräkningsnoder till kontrollnoden, där L3-gränssnittet för dessa nätverk finns, varje i ett dedikerat namespace för isolering.

Men vi glömde det viktigaste. Den virtuella maskinen måste tillhandahålla en tjänst till kunden, det vill säga den måste ha minst ett externt gränssnitt genom vilket man kan nå den. Vi behöver alltså nå den yttre världen. Här finns olika alternativ. Låt oss göra den enklaste varianten. Vi lägger till ett nätverk för varje kund som kommer att vara giltigt i leverantörens nät och inte korsa andra nätverk. Näten kan också korsa varandra och se på olika VRF på leverantörens nätverkssida. Dessa nät kommer också att existera i varje kunds namespace. Men de måste fortfarande nå den yttre världen genom ett enda fysiskt (eller bond, vilket är mer logiskt) gränssnitt. För att separera kundernas trafik kommer den trafik som går ut att taggas med en VLAN-tagg som tilldelats kunden.

Resultatet blev detta schema:

En rimlig fråga är — varför inte skapa gateways på själva compute-noderna? Det finns inget stort problem med detta, tvärtom, när den distribuerade routern (DVR) aktiveras kommer det att fungera så. I detta scenario överväger vi den enklaste varianten med en central gateway, som används som standard i OpenStack. För högbelastade funktioner kommer både den distribuerade routern och accelereringsteknologier som SR-IOV och Passthrough att användas, men som man säger, det är en helt annan historia. Först ska vi förstå den grundläggande delen, och sedan gå in på detaljer.

Vår schema är redan funktionell, men det finns några nyanser:

• Vi måste på något sätt skydda våra maskiner, det vill säga sätta en filter på switchens gränssnitt mot kunden.
• Göra det möjligt för den virtuella maskinen att automatiskt få en IP-adress, så att man inte behöver gå in i den via konsolen och ange adressen varje gång.

Låt oss börja med att skydda maskinerna. För detta kan vi använda vanliga iptables, varför inte.

Det innebär att vår topologi nu har blivit något mer komplicerad:

Vi går vidare. Vi måste lägga till en DHCP-server. Den mest idealiska platsen för att placera DHCP-servrarna för varje kund skulle vara den ovan nämnda kontrollnoden, där namespaces finns:

Det finns dock ett litet problem. Vad händer om allt startar om och all information om hyra av adresser på DHCP försvinner? Det är logiskt att maskinerna kommer att få nya adresser, vilket inte är särskilt praktiskt. Det finns två alternativ här - antingen använda domännamn och lägga till en DNS-server för varje klient, så att adressen inte är särskilt viktig för oss (liknande den nätverksdel i k8s) - men det finns ett problem med externa nätverk, eftersom adresserna där också kan tilldelas via DHCP - det krävs synkronisering mellan DNS-servrarna i molnplattformen och den externa DNS-servern, vilket jag anser inte är särskilt flexibelt, men fullt möjligt. Det andra alternativet är att använda metadatan - det vill säga att spara information om den tilldelade maskinens adress så att DHCP-servern vet vilken adress den ska tilldela om maskinen redan har fått en adress. Det andra alternativet är enklare och mer flexibelt, eftersom det tillåter oss att spara extra information om maskinen. Nu lägger vi till metadata-agenten i schemat:

En annan fråga som också bör belysas är möjligheten att använda ett enda externt nätverk för alla kunder, eftersom externa nätverk, om de ska vara giltiga i hela nätverket, kommer att medföra svårigheter - det blir nödvändigt att ständigt tilldela och kontrollera tilldelningen av dessa nätverk. Möjligheten att använda ett enhetligt för alla kunder förkonfigurerat externt nätverk skulle vara mycket användbart vid skapandet av ett offentligt moln. Detta skulle förenkla distributionen av maskiner, eftersom vi inte behöver kontrollera adressdatabasen och välja unikt adresseringsområde för varje klients externa nätverk. Dessutom kan vi redan i förhand definiera det externa nätverket, och vid distributionsöka behöver vi bara associera externa adresser med klientmaskiner.

Och här kommer NAT till vår hjälp – vi gör helt enkelt det möjligt för kunderna att nå den externa världen via standardnamnområde med hjälp av NAT-översättning. Men det finns en liten problematik här. Det är bra om kundens server fungerar som klient och inte som server – det vill säga att den initierar istället för att ta emot anslutningar. Men vi kommer att ha motsatsen. I sådana fall måste vi göra destination NAT, så att kontrollnoden förstår att denna trafik är avsedd för klient A:s virtuella maskin, och därmed måste vi utföra NAT-översättning från den externa adressen, till exempel 100.1.1.1, till den interna adressen 10.0.0.1. På så sätt, även om alla kunder använder samma nätverk, bibehålls den interna isoleringen helt. Det innebär att vi på kontrollnoden måste göra både dNAT och sNAT. Att använda ett gemensamt nätverk med tilldelning av flytande adresser eller externa nätverk, eller både och, beror på vad ni vill dra in i molnet. Vi kommer inte att inkludera flytande adresser i diagrammet, utan behåller endast de externa nätverk som redan lagts till – varje kund har sitt eget externa nätverk (markerade i diagrammet som VLAN 100 och 200 på det externa gränssnittet).

I resultatet fick vi en intressant och samtidigt genomtänkt lösning, med viss flexibilitet men som ännu saknar mekanismer för hög tillgänglighet.

För det första har vi bara en kontrollnod – om den går ner kommer hela systemet att kollapsa. För att lösa detta problem måste vi ha minst tre noder i kvorum. Vi lägger till det i diagrammet:

Naturligtvis synkroniseras alla noder, och när den aktiva noden går ner kommer en annan nod att ta över dess uppgifter.

Det kommande problemet handlar om virtuella maskiners diskar. De lagras för närvarande på hypervisorerna själva och i händelse av problem med hypervisorn förlorar vi all data — och jämfört med RAID hjälper det inte mycket om vi förlorar hela servern istället för en disk. För detta behöver vi skapa en tjänst som fungerar som en frontend för något lagringssystem. Vilket lagringssystem det blir spelar egentligen ingen större roll, men det måste skydda våra data mot fel på både diskar och noder, och kanske även ett helt skåp. Det finns flera alternativ — det finns naturligtvis SAN-nät med Fiber Channel, men låt oss vara ärliga — FC är redan en kvarleva från det förflutna, motsvarande E1 inom transport — visst, det används fortfarande, men endast där det är helt nödvändigt. Så, att frivilligt bygga ett FC-nätverk år 2020 skulle jag inte göra, med vetskap om att det finns andra mer intressanta alternativ. Även om alla har sina åsikter och det kanske finns de som tycker att FC med alla sina begränsningar är allt vi behöver — jag kommer inte att argumentera, alla har olika uppfattningar. Det mest intressanta alternativet, enligt min åsikt, är användningen av SDS, exempelvis Ceph.

Ceph gör det möjligt att bygga en högt tillgänglig datalagringslösning med många alternativ för redundans, allt från koder med paritetskontroll (motsvarande RAID 5 eller 6) till fullständig replikering av data på olika diskar med hänsyn till diskarnas placering i servrar och servrar i skåp, osv.

För att bygga Ceph krävs ytterligare 3 noder. Interaktionen med lagringssystemet kommer även att ske via nätverket med hjälp av block-, objekt- och fillagringstjänster. Låt oss lägga till lagringssystemet i schemat:

Observera: det går att skapa hyperkonvergerade compute-noder — detta är konceptet att kombinera flera funktioner på en nod — till exempel storage+compute — utan att särskilt avsätta noder för ceph storage. Vi får en liknande felresistent lösning — då SDS reserverar data med den nivå av reservkopiering vi angav. Men hyperkonvergerade noder är alltid en kompromiss — eftersom storage-noden inte bara står stilla, som det kan verka vid första anblick — den använder CPU-resurser för att underhålla SDS (i bakgrunden gör den all replikation, återställning efter misslyckande av noder, diskar etc.). Det betyder att du kommer att förlora en del av kapaciteten hos compute-noden om du kombinerar den med storage.

Allt detta behöver hanteras på något sätt — vi behöver något genom vilket vi kan skapa maskiner, nätverk, virtuella routrar osv. För detta ändamål lägger vi till en tjänst på kontrollnoden som kommer att fungera som en dashboard — kunden kan ansluta till denna portal via http/https och göra allt han behöver (nästan).

Som ett resultat har vi nu ett felresistent system. Alla dessa infrastrukturelement måste på något sätt hanteras. Tidigare beskrevs att OpenStack är en uppsättning projekt, där varje projekt tillhandahåller en viss funktion. Som vi ser är det mer än tillräckligt med element som måste konfigureras och kontrolleras. Idag ska vi prata om nätverksdelen.

Neutron-arkitektur

I OpenStack ansvarar Neutron för att ansluta portarna på virtuella maskiner till det gemensamma L2-nätverket, för att säkerställa trafikdirigering mellan VM som befinner sig i olika L2-nätverk samt för att dirigera trafik utåt, erbjuda tjänster som NAT, Floating IP, DHCP osv.

Arbetet med nätverkstjänsten på hög nivå (grundläggande del) kan beskrivas så här.

Vid start av VM gör nätverkstjänsten:

1. Skapar en port för denna VM (eller portar) och meddelar DHCP-tjänsten;
2. En ny virtuell nätverksenhet skapas (genom libvirt);
3. VM kopplas till den port (eller portar) som skapades i steg 1;

Konstigt nog bygger Neutrons arbete på standardmekanismer som är bekanta för alla som har dykt ner i Linux — detta är namespaces, iptables, linux-bryggor, openvswitch, conntrack osv.

Det ska genast klargöras att Neutron inte är en SDN-controller.

Neutron består av flera sammankopplade komponenter:

Openstack-neutron-server — är en demon som arbetar med användarförfrågningar via API. Denna demon hanterar inte att skriva några nätverkskopplingar, utan ger den nödvändiga informationen till sina plugins, som sedan konfigurerar det nödvändiga nätverkselementet. Neutron-agenter på OpenStack-noder registreras på Neutron-servern.

Neutron-server är i praktiken en applikation som är skriven i Python, bestående av två delar:

• REST-tjänst
• Neutron Plugin (core/service)

REST-tjänsten är avsedd för att ta emot API-anrop från andra komponenter (till exempel begäran om viss information osv.).

Plugins är modulära programkomponenter som anropas vid API-förfrågningar — det vill säga, tilldelningen av en viss tjänst sker genom dem. Plugins delas in i två typer — tjänsteplugin och kärnplugin. Som regel ansvarar kärnplugin huvudsakligen för hantering av adresseringsrymden och L2-anslutningar mellan VM, medan tjänsteplugins tillhandahåller ytterligare funktionalitet, till exempel VPN eller brandvägg.

Listan över tillgängliga plugins idag kan ses till exempel ). Ett typiskt exempel på användning:

Det kan finnas flera tjänsteplugins, men det kan bara finnas en kärnplugin.

Openstack-neutron-ml2 — är standard kärnplugin för OpenStack. Denna plugin har en modulär arkitektur (till skillnad från sin föregångare) och konfigurerar nätverkstjänsten via anslutna drivrutiner. Själva pluggen kommer vi att titta på lite senare, då den faktiskt ger den flexibilitet som OpenStack har i den nätverksrelaterade delen. Kärnplugin kan bytas ut (till exempel gör Contrail Networking en sådan utbyte).

RPC-tjänst (rabbitmq-server) — en tjänst som säkerställer köhantering och interaktion med andra OpenStack-tjänster samt interaktion mellan agenterna för nätverkstjänster.

Nätverksagenter — agenter som är placerade i varje nod, genom vilka konfigurationen av nätverkstjänster genomförs.

Agenter finns i flera olika typer.

Huvudagenten — är L2-agent. Dessa agenter körs på var och en av hypervisorerna, inklusive kontrollnoder (för att vara mer exakt, på alla noder som tillhandahåller någon tjänst för hyresgäster) och deras huvudsakliga funktion är att ansluta virtuella maskiner till det gemensamma L2-nätverket, samt att generera aviseringar vid uppkomst av händelser (till exempel avstängning/påslagning av porten).

Den nästa, lika viktiga agenten är L3-agenten. Som standard körs denna agent enbart på nätverksnoden (ofta sammanfaller nätverksnoden med kontrollnoden) och säkerställer routning mellan hyresgästernas nätverk (både mellan deras nätverk och nätverk från andra hyresgäster, samt ger tillgång till den externa världen genom att erbjuda NAT och DHCP-tjänst). Men vid användning av DVR (distribuerad router) behövs L3-plugin även på beräkningsnoder.

L3-agenten använder Linux-namespaces för att ge varje hyresgäst en uppsättning av egna isolerade nätverk och funktionalitet för virtuella routrar som rutter trafiken och tillhandahåller gatewaytjänster för Layer 2-nätverk.

Databas — en databas över identifierare för nätverk, delnät, portar, pooler osv.

Faktiskt tar Neutron emot API-anrop för att skapa olika nätverksenheter, autentiserar anropet och vidarebefordrar genom RPC (om den kontaktar en plugin eller agent) eller REST API (om den kommunicerar i SDN) till agenterna (genom plugins) instruktioner som är nödvändiga för att organisera den begärda tjänsten.

Nu ska vi titta på den testinstallation (hur den är distribuerad och vad som ingår i den kommer vi att se senare i den praktiska delen) och se var varje komponent är placerad:

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

Det är faktiskt hela strukturen för Neutron. Nu är det dags att ägna lite tid åt ML2-plugin.

Modular Layer 2

Som nämnt ovan är pluginet den standardiserade grundpluginet för OpenStack och har en modulär arkitektur.

Föregångaren till ML2-pluginet hade en monolitisk struktur som inte tillät exempelvis användning av en blandning av flera teknologier i en installation. Till exempel kunde du inte använda både openvswitch och linuxbridge samtidigt — antingen det ena eller det andra. Av denna anledning skapades ML2-pluginet med sin arkitektur.

ML2 har två komponenter — två typer av drivrutiner: Type drivers och Mechanism drivers.

Type drivers bestämmer de teknologier som kommer att användas för att organisera nätverksanslutningar, som VxLAN, VLAN, GRE. Samtidigt tillåter drivrutinen användning av olika teknologier. Den standardiserade teknologin är VxLAN-inkapsling för overlay-nätverk och VLAN för externa nätverk.

De typer av nätverk som tillhör Type drivers är:

Flat — nätverk utan taggning
VLAN — taggat nätverk
Local — en speciell typ av nätverk för installationer av typen all-in-one (sådana installationer behövs antingen för utvecklare eller för utbildning)
GRE — overlay-nätverk som använder GRE-tunnlar
VxLAN — overlay-nätverk som använder VxLAN-tunnlar

Mechanism drivers definierar medel som säkerställer organisationen av de angivna type driver teknologierna — till exempel openvswitch, sr-iov, opendaylight, OVN etc.

Beroende på implementationen av denna drivrutin kommer antingen agenter som hanteras av Neutron att användas, eller så kommer anslutningar till en extern SDN-kontrollör att användas, som tar hand om alla frågor gällande organisering av L2-nätverk, routning etc.

Ett exempel är om vi använder ML2 tillsammans med OVS, så installeras en L2-agent på varje beräkningsnod, som hanterar OVS. Men om vi till exempel använder OVN eller OpenDayLight, så övergår hanteringen av OVS till deras jurisdiktion — Neutron ger genom rotpluginet kommandon till kontrollören, och denne gör sedan det som har beordrats.

Låt oss påminna om Open vSwitch

För närvarande är en av de viktigaste komponenterna i OpenStack Open vSwitch.
Vid installation av OpenStack utan någon ytterligare leverantörsspecifik SDN som Juniper Contrail eller Nokia Nuage, är OVS den primära nätverkskomponenten i det molnbaserade nätverket och i kombination med iptables, conntrack, namespaces möjliggör det att organisera fullt funktionsdugliga overlay-nätverk med multitenancy. Naturligtvis kan denna komponent bytas ut, till exempel vid användning av tredjeparts proprietära (leverantörsspecifika) SDN-lösningar.

OVS är en programvaruswitch med öppen källkod som är avsedd att användas i virtualiserade miljöer som en virtuell trafikdirigerare.

För närvarande har OVS en mycket anständig funktionalitet som inkluderar teknologier som QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK etc.

Observera: OVS var ursprungligen inte avsedd som en programvaruswitch för högbelastade telekomfunktioner och var mer anpassad för mindre krav på bandbredd IT-funktioner som webbservrar eller e-postservrar. Men OVS har förbättrats och de nuvarande implementationerna av OVS har kraftigt förbättrat dess prestanda och kapabiliteter vilket gör att den kan användas av operatörer för kommunikation med högbelastade funktioner, till exempel finns det en implementation av OVS med stöd för DPDK-acceleration.

Det finns tre viktiga komponenter i OVS som bör beaktas:

• Kernelmodul — komponenten som finns i kernelutrymmet, som utför trafikbearbetning baserat på de regler som mottagits från kontrollenheten;
• vSwitch Daemon (ovs-vswitchd) är en process som körs i användarutrymmet och ansvarar för programmeringen av kernelmodulen — det representerar direkt logiken för hur switchen fungerar.
• Databasserver — en lokal databas som ligger på varje värd där OVS körs, där konfigurationen lagras. Genom denna modul kan SDN-kontrollörer kommunicera via OVSDB-protokollet.

Därtill finns en uppsättning diagnostiska och hanteringsverktyg, som ovs-vsctl, ovs-appctl, ovs-ofctl etc.

För tillfället används OpenStack i stor utsträckning av telekombolag för att migrera nätverksfunktioner som EPC, SBC, HLR etc. Vissa funktioner kan fungera utan problem med OVS i dess nuvarande form, men till exempel EPC hanterar abonnenttrafik — det vill säga passerar ett stort mängd trafik (just nu når trafikvolymerna flera hundra gigabit per sekund). Det är uppenbarligen ingen bra idé att leda sådan trafik genom kernelutrymmet (eftersom standardforwardern ligger där). Därför implementeras OVS ofta helt i användarutrymmet med hjälp av DPDK-teknologi för att omdirigera trafik från NIC till användarutrymmet utan att gå via kernel.

Observera: För ett moln som implementerats för telekomfunktioner finns det en möjlighet att leda trafik från compute-noden direkt till switchutrustningen utan att gå via OVS. För detta ändamål används mekanismer som SR-IOV och Passthrough.

Hur fungerar detta på en verklig modell?

Nu går vi vidare till den praktiska delen och ser hur allt detta fungerar i praktiken.

Först kommer vi att installera en enkel OpenStack-installation. Eftersom jag för experimentet inte har en uppsättning servrar tillgängliga, kommer vi att bygga modellen på en fysisk server med hjälp av virtuella maskiner. Ja, det är uppenbart att en sådan lösning inte är lämplig för kommersiella ändamål, men för att se hur nätverket fungerar i en OpenStack-installation är den här installationen mer än tillräcklig. Dessutom är en sådan installation för utbildningsändamål ännu mer intressant — eftersom man kan fånga upp trafik etc.

Eftersom vi bara behöver se den grundläggande delen, kan vi undvika att använda flera nätverk och istället använda två nätverk, där det andra nätverket i denna modell endast kommer att användas för åtkomst till undercloud och DNS-servern. Vi kommer att undvika externa nätverk för tillfället — det är ett ämne för en separat stor artikel.

Låt oss börja i ordning. Först lite teori. Vi kommer att installera OpenStack med hjälp av TripleO (OpenStack på OpenStack). Essensen av TripleO är att vi installerar OpenStack all-in-one (det vill säga på en nod), kallad undercloud, och sedan använder vi de resurser som det distribuerade OpenStack erbjuder för att installera det produktionsinriktade OpenStack, kallad overcloud. Undercloud kommer att använda inbyggd funktionalitet för att hantera fysiska servrar (bare metal) — projektet Ironic — för att provisionera hypervisorer som kommer att utföra rollerna av compute-, control- och storage-noder. Det innebär att vi inte använder några tredjepartsverktyg för att distribuera OpenStack — vi distribuerar OpenStack med hjälp av OpenStack. Det kommer att bli mycket tydligare under installationen, så vi stannar inte här utan går vidare.

Anmärkning: I denna artikel för enkelhetens skull valde jag att inte använda nätverksisolering för interna nätverk av OpenStack, utan allt är distribuerat med hjälp av endast ett nätverk. Men förekomsten eller frånvaron av nätverksisolering påverkar inte grundläggande funktionalitet — allt kommer att fungera precis som med isolering, men trafiken kommer att gå inom ett och samma nätverk. För en kommersiell installation är det självklart nödvändigt att använda isolering med olika VLAN och gränssnitt. Till exempel använder hanteringstrafik för Ceph-lagringen och faktiska datatrafik (maskinernas åtkomst till diskar osv.) vid isolering olika subnät (Storage management och Storage), vilket gör lösningen mer fel tolerant genom att dela upp trafiken, till exempel över olika portar, eller använda olika QoS-profiler för att se till att datatrafiken inte överbelastat signalsignaler. I vårt fall kommer de att gå inom samma nätverk och faktiskt begränsar det oss inte på något sätt.

Anmärkning: Eftersom vi planerar att köra virtuella maskiner i en virtuell miljö som baseras på virtuella maskiner, måste vi först aktivera nested virtualisering.

För att kontrollera om nested virtualisering är aktiverat eller inte kan man göra så här:

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

Om du ser bokstaven N, aktiverar du stöd för nested virtualisering med vilken guide som helst du hittar på nätet, till exempel en sådan .

Vi behöver skapa en sådan här struktur av virtuella maskiner:

I mitt fall använde jag OpenvSwitch för att koppla samman virtuella maskiner som skulle ingå i den framtida installationen (jag har 7 stycken, men det går att klara sig med 4 om du har få resurser). Jag skapade en ovs-bro och kopplade virtuella maskiner till den via port-grupper. För detta skapade jag en xml-fil av följande typ:

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        

  ovs-network-1
  7a2e7de7-fc16-4e00-b1ed-4d190133af67

Här deklareras tre portgrupper – två access och en trunk (den sistnämnda var nödvändig för DNS-servern, men den kan uteslutas eller köras på värdmaskinen – det beror på vad som passar dig bäst). Därefter definierar vi vårt nätverk med hjälp av följande mall genom virsh net-define:

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

Nu justerar vi konfigurationerna för hypervisorportarna:

[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 ~]# 

Notera: i detta scenario kommer adressen på porten ovs-br1 inte att vara tillgänglig, då den saknar en vlan-tagg. För att åtgärda detta, ge kommandot sudo ovs-vsctl set port ovs-br1 tag=100. Men efter omstart kommer denna tagg att försvinna (om någon vet hur man får den att stanna kvar, skulle jag vara mycket tacksam). Men detta är inte så viktigt, eftersom vi endast kommer att behöva denna adress under installationen, och den kommer att vara överflödig när Openstack är fullt installerad.

Därefter skapar vi undercloud-maskinen:

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

Under installation, set all necessary parameters such as the machine name, passwords, users, NTP servers, etc. You can also configure the ports immediately, but personally, I find it easier to access the machine through the console after installation and adjust the necessary files. If you already have a ready-made image, you can use it, or proceed as I do - download the minimal CentOS 7 image and use it to install the VM.

After a successful installation, you should have a virtual machine where you can install the undercloud.

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

First, we install the necessary tools for the installation process:

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

Installing Undercloud

Create a user stack, set the password, add it to the sudoers, and give it the ability to execute root commands via sudo without needing to enter a password:

useradd stack
passwd stack

echo "stack ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

Now specify the full name of undercloud in the hosts file:

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

Next, add the repositories and install the necessary software:

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

Note: If you do not plan to install ceph, do not enter commands related to ceph. I used the Queens release, but you can use any other one you prefer.

Next, copy the undercloud configuration file to the stack user's home directory:

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

Now it is necessary to adjust this file, tailoring it to our installation.

At the beginning of the file, you need to add the following lines:

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 = 10

So, let's go through the settings:

undercloud_hostname — the full name of the undercloud server, it must match the entry on the DNS server

local_ip — lokal adress för undercloud mot provisioning nätverk

network_gateway — samma lokala adress som kommer att fungera som gateway för att få åtkomst till den externa världen under installationen av overcloud noder, överensstämmer också med lokal ip

undercloud_public_host — adress för extern API, tilldelas vilken ledig adress som helst från provisioning nätverk

undercloud_admin_host adress för intern API, tilldelas vilken ledig adress som helst från provisioning nätverk

undercloud_nameservers — DNS-server

generate_service_certificate — denna rad är mycket viktig i det aktuella exemplet, eftersom om den inte sätts till värdet false kommer du att få ett fel vid installationen, problemet beskrivs på bugtracker Red Hat

local_interface gränssnitt i provisioning nätverket. Detta gränssnitt kommer att omkonfigureras under installationen av undercloud, så det behövs två gränssnitt för undercloud — ett för åtkomst till det, det andra för provisioning

local_mtu — MTU. Eftersom vi har ett testlaboratorium och MTU är 1500 på OVS switchportar, måste vi ställa in det på 1450 så att de inkapslade VxLAN-paketen passerar

network_cidr — provisioning nätverk

masquerade — användning av NAT för åtkomst till det externa nätverket

masquerade_network — nätverk som kommer att NAT:as

dhcp_start — startadress för adresspoolen från vilken adresser kommer att tilldelas noder under deployment av overcloud

dhcp_end — slutadress för adresspoolen från vilken adresser kommer att tilldelas noder under deployment av overcloud

inspection_iprange — adresser som behövs för inspektion (får inte överlappa med ovanstående pool)

scheduler_max_attempts — maximalt antal försök för att installera overcloud (måste vara större än eller lika med antalet noder)

När filen har beskrivits kan du ge kommandot för att deploya undercloud:

openstack undercloud install

Proceduren tar 10 till 30 minuter beroende på din hårdvara. Slutligen bör du se en sådan utdata:

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.

#############################################################################

Denna utdata visar att du har lyckats installera undercloud och nu kan kontrollera tillståndet för undercloud och gå vidare till installationen av overcloud.

Om du tittar på utdata från ifconfig, kommer du att se att en ny brygggränssnitt har dykt upp

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Genom detta gränssnitt kommer vi nu att arbeta med att distribuera overcloud.

Från utskriften nedan kan vi se att alla tjänster finns på en nod:

(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     |
+--------------------------+-----------+----------+

Nedan visas konfigurationen för det nätverksmässiga undercloud:

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

Installation av overcloud

För närvarande har vi bara undercloud, och vi saknar noder som kommer att byggas upp till overcloud. Så det första vi ska göra är att distribuera de virtuella maskiner vi behöver. Under distributionen kommer undercloud att installera operativsystemet och nödvändig programvara på overcloud-maskinerna — vilket betyder att vi inte behöver distribuera en maskin helt, utan bara skapa en disk (eller diskar) för den och definiera dess parametrar — vi får faktiskt en ren server utan installerat operativsystem.

Vi går till mappen med diskarna för våra virtuella maskiner och skapar diskar av önskad storlek:

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 160G

Eftersom vi agerar som root måste vi ändra ägaren av dessa diskar för att inte få problem med behörigheter:

[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]# 

Observera: om du inte planerar att installera Ceph för att studera det, bör du minst skapa 3 noder med minst två diskar, och i mallen ange att virtuella diskar vda, vdb osv. kommer att användas.

Bra, nu behöver vi definiera alla dessa maskiner:

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > \/tmp\/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > \/tmp\/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > \/tmp\/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > \/tmp\/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=\/var\/lib\/libvirt\/images\/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > \/tmp\/compute-2.xml 

I slutet finns kommandona —print-xml > \/tmp\/storage-1.xml, som skapar en xml-fil med beskrivningen av varje maskin i mappen \/tmp\/. Om du inte lägger till det kan du inte definiera de virtuella maskinerna.

Nu behöver vi definiera alla dessa maskiner i virsh:

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

Nu en liten detalj — tripleO använder IPMI för att styra servrar under installation och introspektion.

Introspektion är en process för inspektion av hårdvaran för att få dess parametrar som krävs för vidare provisioning av noder. Introspektion utförs med hjälp av ironic — en tjänst avsedd för att arbeta med bare metal-servrar.

Men här är problemet — om för hårdvaruservrar är IPMI en separat port (eller en delad port, men det är inte avgörande), så har virtuella maskiner inga sådana portar. Här kommer en lösning som kallas vbmc — ett verktyg som möjliggör emulering av en IPMI-port. Detta bör särskilt beaktas av dem som vill bygga ett sådant laboratorium på ESXI-hypervisorn — om det nu finns något motsvarande till vbmc där, så är det värt att tänka på detta innan man implementerar allt.

Installerar vbmc:

yum install yum install python2-virtualbmc

Om ditt operativsystem inte kan hitta paketet, lägg till repositoryt:

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

Nu konfigurerar vi verktyget. Här är allt banal till otrevlighet. Just nu är det logiskt att det inte finns några servrar listade i vbmc.

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

För att de ska dyka upp måste de manuellt deklareras på följande sätt:

[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 ~]#

Jag tror att syntaxen för kommandot är tydlig utan förklaringar. Men hittills är alla våra sessioner i status DOWN. För att de ska gå över till status UP måste de slås på:

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Startade vBMC-instansen för domän control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Startade vBMC-instansen för domän storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Startade vBMC-instansen för domän storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Startade vBMC-instansen för domän compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Startade vBMC-instansen för domän compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domännamn  | Status  | Adress  | Port |
+-------------+---------+---------+------+
| compute-1   | kör     | ::      | 7004 |
| compute-2   | kör     | ::      | 7005 |
| control-1   | kör     | ::      | 7001 |
| storage-1   | kör     | ::      | 7002 |
| storage-2   | kör     | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

Och den sista detaljen — vi måste justera brandväggsreglerna (eller stänga av 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

Nu går vi in i undercloud och kontrollerar att allt fungerar. Adressen till värdmaskinen är 192.168.255.200, och vi har lagt till det nödvändiga paketet ipmitool under förberedelserna för deployment:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassinets ström är av
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassikontroll: På
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Namn                            Status
----------------------------------------------------
 6     dns-server                     kör
 64    undercloud                     kör
 65    control-1                      kör

Som ni ser har vi framgångsrikt startat control-noden via vbmc. Nu stänger vi av den och fortsätter:

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassikontroll: Av
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassinets ström är av
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Namn                            Status
----------------------------------------------------
 6     dns-server                     kör
 64    undercloud                     kör
 -     compute-1                      avstängd
 -     compute-2                      avstängd
 -     control-1                      avstängd
 -     storage-1                      avstängd
 -     storage-2                      avstängd

[root@hp-gen9 ~]#

Nästa steg är att göra en inspektion av noderna där overcloud ska installeras. För detta behöver vi förbereda en json-fil med beskrivning av våra noder. Observera att, till skillnad från installation på rena servrar, anges porten där vbmc är igång för varje maskin i filen.

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Typ       Källa     Modell       MAC
-------------------------------------------------------
-          nätverk    ovs-network-1 virtio      52:54:00:20:a2:2f
-          nätverk    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Typ       Källa     Modell       MAC
-------------------------------------------------------
-          nätverk    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Typ       Källa     Modell       MAC
-------------------------------------------------------
-          nätverk    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Typ       Källa     Modell       MAC
-------------------------------------------------------
-          nätverk    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Typ       Källa     Modell       MAC
-------------------------------------------------------
-          nätverk    ovs-network-1 virtio      52:54:00:a7:fe:27

Obs: på kontrollnoden finns det två gränssnitt, men i detta fall spelar det ingen roll, vi behöver bara ett i denna installation.

Nu förbereder vi JSON-filen. Vi måste ange MAC-adressen för porten som provisioning ska utföras genom, noderna, ge dem namn och ange hur man får tillgång till IPMI:

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

Nu måste vi förbereda bilder för Ironic. För detta laddar vi ner dem via wget och installerar:

(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 ~]$

Laddar bilder till undercloud:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Bild "overcloud-full-vmlinuz" har laddats upp.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Namn         | Diskformat  |   Storlek | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | aktiv |
+--------------------------------------+------------------------+-------------+---------+--------+
Bild "overcloud-full-initrd" har laddats upp.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Namn         | Diskformat  |   Storlek | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | aktiv |
+--------------------------------------+-----------------------+-------------+----------+--------+
Bild "overcloud-full" har laddats upp.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Namn      | Diskformat  |    Storlek  | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | aktiv |
+--------------------------------------+----------------+-------------+------------+--------+
Bild "bm-deploy-kernel" har laddats upp.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Namn       | Diskformat  |   Storlek | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | aktiv |
+--------------------------------------+------------------+-------------+---------+--------+
Bild "bm-deploy-ramdisk" har laddats upp.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Namn       | Diskformat  |    Storlek  | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | aktiv |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

Vi kontrollerar att alla bilder har laddats upp.

(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Namn                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | aktiv |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | aktiv |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | aktiv |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | aktiv |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aktiv |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

En sista detalj — vi behöver lägga till dns-servern:

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

Nu kan vi ge kommandot för introspektion:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Startade Mistral-arbetsflödet tripleo.baremetal.v1.register_or_update. Utförande-ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Väntar på meddelanden i kö 'tripleo' utan tidsgräns.


5 nod(er) flyttades framgångsrikt till "hanterbart" tillstånd.
Nod UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 registrerad framgångsrikt.
Nod UUID b89a72a3-6bb7-429a-93bc-48393d225838 registrerad framgångsrikt.
Nod UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e registrerad framgångsrikt.
Nod UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 registrerad framgångsrikt.
Nod UUID 766ab623-464c-423d-a529-d9afb69d1167 registrerad framgångsrikt.
Väntar på att introspektion ska avslutas...
Startade Mistral-arbetsflödet tripleo.baremetal.v1.introspect. Utförande-ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Väntar på meddelanden i kö 'tripleo' utan tidsgräns.
Introspektion av nod b89a72a3-6bb7-429a-93bc-48393d225838 avslutad. Status: SUCCESS. Fel: Inga
Introspektion av nod 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e avslutad. Status: SUCCESS. Fel: Inga
Introspektion av nod bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 avslutad. Status: SUCCESS. Fel: Inga
Introspektion av nod 766ab623-464c-423d-a529-d9afb69d1167 avslutad. Status: SUCCESS. Fel: Inga
Introspektion av nod b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 avslutad. Status: SUCCESS. Fel: Inga
5 nod(er) introspekterades framgångsrikt.
Startade Mistral-arbetsflödet tripleo.baremetal.v1.provide. Utförande-ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Väntar på meddelanden i kö 'tripleo' utan tidsgräns.
5 nod(er) flyttades framgångsrikt till "tillgängligt" tillstånd.
(undercloud) [stack@undercloud ~]$

Som framgår av utdata har allt avslutats utan fel. Låt oss kontrollera att alla noder är i tillståndet tillgänglig:

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Namn      | Instans UUID   | Strömtillstånd | Provisioneringstillstånd | Underhåll |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | Ingen         | avstängd     | tillgänglig         | Falsk      |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | Ingen         | avstängd     | tillgänglig         | Falsk      |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | Ingen         | avstängd     | tillgänglig         | Falsk      |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | Ingen         | avstängd     | tillgänglig         | Falsk      |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | Ingen         | avstängd     | tillgänglig         | Falsk      |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

Om noderna är i ett annat tillstånd, vanligtvis hanterbart, har något gått fel och du måste titta på loggarna för att förstå varför det har blivit så. Tänk på att i detta scenario använder vi virtualisering, och det kan finnas buggar kopplade till användningen av virtuella maskiner eller vbmc.

Vidare måste vi ange vilken nod som ska utföra vilken funktion — det vill säga ange profilen som noden ska distribueras med:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Nodens UUID                         | Nodens namn | Provision State | Nuvarande profil | Möjliga profiler |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | kontroll-1 | tillgänglig     | Ingen           |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | lagring-1  | tillgänglig     | Ingen           |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | lagring-2  | tillgänglig     | Ingen           |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | beräkning-1 | tillgänglig     | Ingen           |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | beräkning-2 | tillgänglig     | Ingen           |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Namn         |  RAM | Disk | Temporär | VCPUs | Är offentlig |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-lagring | 4096 |   40 |         0 |     1 | Sant      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | Sant      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | kontroll      | 4096 |   40 |         0 |     1 | Sant      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-lagring | 4096 |   40 |         0 |     1 | Sant      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | beräkning     | 4096 |   40 |         0 |     1 | Sant      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-lagring  | 4096 |   40 |         0 |     1 | Sant      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

Ange profil för varje nod:

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-d9afb69d1167

Kontrollera att vi har gjort allt korrekt:

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

Om allt är korrekt, ger vi kommandot för att deploya övermolnet:

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 qemu

I en verklig installation kommer vi naturligtvis att använda anpassade mallar, vilket i vårt fall skulle komplicera processen avsevärt, eftersom vi skulle behöva förklara varje ändring i mallen. Som nämnts tidigare — även en enkel installation är tillräcklig för att se hur det fungerar.

Observera: variabeln --libvirt-type qemu är nödvändig i detta fall, eftersom vi kommer att använda nested virtualisering. Annars kommer virtuella maskiner inte att kunna startas.

Nu har du ungefär en timme, kanske mer (beroende på hårdvarans kapabiliteter) och du kan bara hoppas att efter denna tid, kommer du att se följande meddelande:

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

Nu har du en nästan fullt fungerande version av OpenStack där du kan lära dig, experimentera osv.

Låt oss kontrollera att allt fungerar som det ska. I hemmappen för användaren stack finns två filer — en stackrc (för att hantera undercloud) och den andra overcloudrc (för att hantera overcloud). Dessa filer måste anges som source, eftersom de innehåller den information som krävs för autentisering.

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Namn                    | Status | Nätverk                | Bild           | Smak        |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | AKTIV | ctlplane=192.168.255.15 | overcloud-full | kontroll     |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | AKTIV | ctlplane=192.168.255.26 | overcloud-full | beräkning    |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | AKTIV | ctlplane=192.168.255.34 | overcloud-full | ceph-lagring |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | AKTIV | ctlplane=192.168.255.19 | overcloud-full | beräkning    |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | AKTIV | ctlplane=192.168.255.44 | overcloud-full | ceph-lagring |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Namn    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agenttyp          | Värd                                | Tillgänglighetszon | Aktiv | Status | Binär                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch-agent | overcloud-novacompute-1.localdomain | Ingen              | :-)   | 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 | Ingen              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch-agent | overcloud-controller-0.localdomain  | Ingen              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata-agent    | overcloud-controller-0.localdomain  | Ingen              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

I min installation behövs det ett litet ytterligare steg - att lägga till en rutt på kontrollern, eftersom maskinen jag arbetar på ligger i ett annat nätverk. För detta loggar vi in på control-1 med kontot heat-admin och lägger till rutten.

(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15         
Senaste inloggning: fre 14 aug 09:47:40 2020 från 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.254

Nu kan ni gå in i horisonten. All information – adresser, inloggning och lösenord – finns i filen /home/stack/overcloudrc. Slutschemat ser ut som följer:

För övrigt, i vår installation tilldelades maskinernas adresser via DHCP och som ni ser, tilldelas de "slumptalsvis". Ni kan i mallen hårt ange vilken adress som ska knytas till vilken maskin under deployment, om ni så önskar.

Hur går trafiken mellan de virtuella maskinerna?

I denna artikel kommer vi att gå igenom tre alternativ för trafikflöde

• Två maskiner på samma hypervisor i samma L2-nätverk
• Två maskiner på olika hypervisorer i samma L2-nätverk
• Två maskiner i olika nätverk (routing mellan nätverken)

Fall med utgång till den externa världen genom det externa nätverket, med användning av flytande adresser, samt distribuerad routing kommer vi att behandla nästa gång, men för tillfället fokuserar vi på intern trafik.

För att verifiera, låt oss skapa detta schema:

Vi har skapat 4 virtuella maskiner — 3 i samma L2-nätverk — net-1, och ytterligare 1 i nätverket net-2

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Namn | Tenant ID                        | Status | Arbetsstatus | Strömstatus | Nätverk         |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | -          | Pågår      | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | -          | Pågår      | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | -          | Pågår      | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | AKTIV | -          | Pågår      | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

Låt oss se på vilka hypervisorer de skapade maskinerna är placerade på:

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(overcloud) [stack@undercloud ~]$
Maskinerna vm-1 och vm-3 är placerade på compute-0, medan maskinerna vm-2 och vm-4 är placerade på noden compute-1.

Dessutom har en virtuell router skapats för att möjliggöra routing mellan de angivna nätverken:

(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 ~]$ 

Routern har två virtuella portar som fungerar som gateways för nätverken:

(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 innan vi kollar på hur trafiken går, låt oss se vad vi har just nu på kontrollnoden (som också är nätverksnoden) och på compute-noden. Låt oss börja med compute-noden.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

För tillfället finns det tre ovs-broar på noderna — br-int, br-tun, br-ex. Mellan dem, som vi ser, finns det en uppsättning gränssnitt. För att förenkla visualiseringen kommer vi att överföra alla dessa gränssnitt till en skiss och se vad vi får.

Vid adresserna där VxLAN-tunnlarna är aktiverade syns det att en tunnel är aktiverad på compute-1 (192.168.255.26) och den andra tittar på control-1 (192.168.255.15). Men det mest intressanta är att br-ex inte har några fysiska gränssnitt, och om vi tittar på vilka flöden som är konfigurerade ser vi att denna bro för tillfället endast kan släppa trafik.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

Som man kan se från utskriften är adressen kopplad direkt till den fysiska porten, och inte till den virtuella brogränssnittet.

[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 ~]$ 

Enligt den första regeln ska all trafik som kommer från porten phy-br-ex avvisas.
Egentligen finns det ingen annan källa för trafik till denna bro, förutom från detta gränssnitt (koppling med br-int), och med tanke på bortfallen har det redan kommit BUM-trafik till bron.

Det betyder att trafiken från denna nod endast kan gå ut genom VxLAN-tunneln och inte på något annat sätt. Men om DVR aktiveras kommer situationen att förändras, men det får vi ta senare. När man använder nätverksisolering, till exempel med VLAN, så har ni inte bara en L3-gränssnitt i VLAN 0, utan flera gränssnitt. Men VxLAN-trafiken kommer att lämna noden på samma sätt, men innesluten även i ett speciellt VLAN.

Vi har förstått compute-noden, så vi går vidare till control-noden.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (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 ~]$

I praktiken kan man säga att allt är detsamma, men IP-adressen finns redan inte på det fysiska gränssnittet utan på en virtuell bro. Detta har gjorts eftersom denna port är en port genom vilken trafiken kommer att gå ut till den yttre världen.

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

Denna port är kopplad till bron br-ex och eftersom det inte finns några VLAN-taggar på den, så är denna port en trunkport där alla VLAN är tillåtna. Just nu går trafiken ut utan tagg, vilket indikeras av VLAN-ID 0 i utskriften ovan.

Allt annat är för närvarande likadant som compute-noden - samma broar, samma tunnlar som går till två compute-noder.

Vi kommer inte att titta på lagringsnoder i denna artikel, men för att förstå måste vi säga att den nätverksdel som dessa noder har är banal till det absurda. I vårt fall finns det bara en fysisk port (eth0) med ett IP-adress kopplat till den, och det är allt. Det finns inga VxLAN-tunnlar, tunnelbroar osv. — det finns inte ens OVS eftersom det inte finns något syfte med det. När man använder nätverksisolering — på denna nod kommer det att finnas två gränssnitt (fysiska portar, VLAN, eller bara två VLAN — detta spelar ingen roll — det beror på vad du vill) — den ena för administration, den andra för trafik (skriva till disk VM, läsa från disk osv.).

Nu har vi klarat av vad vi har på noderna utan någon form av tjänster. Låt oss nu starta 4 virtuella maskiner och se hur det ovan beskrivna schemat förändras — vi borde få portar, virtuella routrar osv.

Hittills ser vårt nätverk ut så här:

Vi har två virtuella maskiner på varje beräkningsnod. Låt oss titta på hur allt är aktiverat med exempelvis compute-0.

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Namn                           Status
----------------------------------------------------
 1     instance-00000001              kör
 3     instance-00000003              kör

[heat-admin@overcloud-novacompute-0 ~]$ 

Maskinen har bara ett virtuellt gränssnitt — tap95d96a75-a0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Gränssnitt  Typ       Källa     Modell       MAC
-------------------------------------------------------
tap95d96a75-a0 bro       qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

Detta gränssnitt pekar på linux-bro:

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bro namn     bro id               STP aktiverad     gränssnitt
docker0         8000.0242904c92a8       nej
qbr5bd37136-47          8000.5e4e05841423       nej              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       nej              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

Som kan ses från utskriften, i bron finns det totalt två gränssnitt — tap95d96a75-a0 och qvb95d96a75-a0.

Här är det värt att stanna upp lite vid typerna av virtuella nätverksenheter i OpenStack:
vtap — virtuellt gränssnitt kopplat till instansen (VM)
qbr — Linux-bro
qvb och qvo — vEth-par kopplade till Linux-bro och Open vSwitch-bro
br-int, br-tun, br-vlan — Open vSwitch-broar
patch-, int-br-, phy-br- — Open vSwitch patch-gränssnitt som kopplar broar
qg, qr, ha, fg, sg — Open vSwitch-portar som används av virtuella enheter för att ansluta till OVS

Som ni förstår, om vi har en brygga med en qvb95d96a75-a0 port, som är en vEth-uppkoppling, finns det någonstans dess motsatta sida, som logiskt bör kallas qvo95d96a75-a0. Låt oss se vilka portar som finns 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 ser är porten ansluten till br-int. Br-int fungerar som en switch som terminerar portar för virtuella maskiner. Förutom qvo95d96a75-a0 kan vi i utskriften se porten qvo5bd37136-47. Detta är porten för den andra virtuella maskinen. Resultatet av vår plan ser nu ut så här:

Frågan som omedelbart bör intressera den observanta läsaren är: varför finns det en linux-brygga mellan porten för den virtuella maskinen och OVS-porten? Anledningen är att säkerhetsgrupper används för att skydda maskinen, vilka i själva verket är iptables. OVS fungerar inte med iptables, så det här ”arbeteområdet” har skapats. Men det håller på att föråldras – något nytt som conntrack kommer att ersätta detta i framtida versioner.

Så i slutändan ser diagrammet ut så här:

Två maskiner på samma hypervisor i samma L2-nätverk

Eftersom dessa två VM:ar befinner sig i samma L2-nätverk och på samma hypervisor, så kommer trafiken mellan dem logiskt att färdas lokalt via br-int, eftersom båda maskinerna kommer att vara i samma 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 ~]$ 

Två maskiner på olika hypervisorer i samma L2-nätverk

Låt oss nu se hur trafiken kommer att flöda mellan två maskiner i samma L2-nätverk, men placerade på olika hypervisorer. Om vi ska vara ärliga kommer inget speciellt att förändras, utan trafiken mellan hypervisorerna kommer att gå genom ett vxlan-tunnel. Låt oss titta på ett exempel.

Adresserna för virtuella maskiner mellan vilka vi ska granska trafiken:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Gränssnitt  Typ       Källa     Modell       MAC
-------------------------------------------------------
tap95d96a75-a0 bro       qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Gränssnitt  Typ        Källan      Modell       MAC
-------------------------------------------------------
tape7e23f1b-07 bro       qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

Vi kollar på vidarebefordrings-tabellen i br-int på compute-0:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

Trafiken ska gå till port 2 — vi kollar vilken port det är:

[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 ~]$

Detta är patch-tun — det vill säga gränssnittet i br-tun. Vi undersöker vad som händer med paketet 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 ~]$ 

Paketet packas i VxLAN och skickas till port 2. Vi kontrollerar vart 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 ~]$

Detta är vxlan-tunneln 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 ~]$

Vi går till compute-1 och ser vad som händer med paketet:

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

MAC:en finns i vidarebefordrings-tabellen br-int på compute-1, och som det framgår av utskriften ovan syns den genom port 2, som är 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:46

Och vidare ser vi att det finns en destination MAC i br-int på compute-1:

[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 vill säga det mottagna paketet kommer att skickas till port 3, där den virtuella maskinen instance-00000003 redan finns.

Det fantastiska med att distribuera Openstack för undervisning på virtuell infrastruktur är att vi enkelt kan fånga trafik mellan hypervisorerna och se vad som händer med den. Det gör vi nu genom att starta tcpdump på vnet-porten mot compute-0:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: lyssnar på vnet3, länktyp EN10MB (Ethernet), fångststorlek 262144 byte

*****************utelämnat*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), längd 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [ingen cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), längd 84)
    10.0.1.85 > 10.0.1.88: ICMP eko begäran, id 5634, seq 16, längd 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), längd 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [ingen cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [ingen], proto ICMP (1), längd 84)
    10.0.1.88 > 10.0.1.85: ICMP eko svar, id 5634, seq 16, längd 64
	
*****************utelämnat*******************

Den första raden visar att paketet från adress 10.0.1.85 går till adress 10.0.1.88 (ICMP-trafik), och det är inkapslat i ett VxLAN-paket med vni 22. Paketet går från värden 192.168.255.19 (compute-0) till värden 192.168.255.26 (compute-1). Vi kan kontrollera att VNI stämmer överens med den som anges i ovs.

Låt oss gå tillbaka till den här raden actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 är vni i hexadecimal form. Låt oss konvertera detta tal till decimal:

16 = 6*16^0+1*16^1 = 6+16 = 22

Så vni stämmer.

Den andra raden visar den omvända trafiken, men det behövs ingen förklaring där, allt är tydligt.

Två maskiner i olika nätverk (routing mellan nätverken)

Det sista fallet för idag är routing mellan nätverk inom ett enda projekt med användning av virtuella routrar. Vi granskar fallet utan DVR (det kommer vi att titta på i en annan artikel), så routing sker på nätverksnoden. I vårt fall är nätverksnoden inte ett separat objekt utan är placerad på kontrollnoden.

Först ska vi se att routing fungerar:

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping-statistik ---
2 paket sända, 2 paket mottagna, 0% paketförlust
rundtur min/medel/max = 3.832/5.779/7.727 ms

Eftersom paketet i detta fall måste gå till gatewayen och routeras där, måste vi ta reda på MAC-adressen för gatewayen, så vi kommer att titta på ARP-tabellen i instansen:

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  på eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  på eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  på eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  på eth0

Låt oss nu titta på vart trafiken ska skickas med destination (10.0.1.254) fa:16:3e:c4:64:70:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

Vi tittar på vart port 2 leder:

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

Det är logiskt, trafiken går till br-tun. Låt oss se vilken vxlan-tunnel den kommer att kapslas in 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 är 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 pekar 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 ~]$ 

Trafiken har nått kontrollnoden, så vi måste gå till den och se hur routing kommer att ske.

Som ni minns såg kontrollnoden exakt likadant ut som compute-noden — samma tre broar, fast br-ex hade en fysisk port genom vilken noden kunde skicka trafik utåt. Att skapa instanser ändrade konfigurationen på compute-noderna — ytterligare linuxbridge, iptables och gränssnitt på noderna lades till. Skapandet av nätverk och en virtuell router lämnade också sitt spår på konfigurationen av kontrollnoden.

Så det är tydligt att MAC-adressen för gateway bör finnas i forwarding-tabellen för br-int på kontrollnoden. Vi kontrollerar om den finns där och vart den pekar:

[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 är synlig från port qr-0c52b15f-8f. Om vi återgår till listan över virtuella portar i Openstack, så används denna typ av port för att ansluta olika virtuella enheter till OVS. Mer specifikt, qr är en port mot den virtuella routern, som presenteras i form av ett namespace.

Låt oss se vilka namnrymd som finns på servern:

[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 ~]$ 

Hela tre instanser. Men utifrån namnen kan man gissa deras syfte. Vi kommer att återkomma till instanserna med ID 0 och 1 senare, nu är vi intresserade av namnområ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 ~]$ 

I detta namnområde finns två interna som vi skapade tidigare. Båda virtuella portar är tillagda br-int. Låt oss kontrollera MAC-adressen för port qr-0c52b15f-8f, eftersom trafiken, utifrån MAC-adressen, verkar gå till denna gränssnitt.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

Det vill säga, i detta fall fungerar allt enligt standard routingprinciper. Eftersom trafiken är avsedd för värden 10.0.2.8, bör den gå ut genom det andra gränssnittet qr-92fa49b5-54 och vidare genom vxlan-tunneln till compute-noden:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

Allt är logiskt, inga överraskningar. Låt oss se varifrån MAC-adressen för värden 10.0.2.8 är 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 det ska vara går trafiken genom br-tun, låt oss se vilken tunnel trafiken går vidare i:

[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 ~]$ 

Trafiken går genom tunneln till compute-1. Och på compute-1 är det enkelt — från br-tun går paketet till br-int och därifrån in i den virtuella maskinens gränssnitt:

[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 ~]$ 

Låt oss kontrollera att det verkligen är rätt gränssnitt:

[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 ~]$

Så vi har gått igenom hela paketets väg. Jag tror du har märkt att trafiken gick genom olika vxlan-tunnlar och dök upp med olika VNI. Låt oss titta på vilka dessa VNI är, och därefter fånga en dump på kontrollnodens port och försäkra oss om att trafiken flödar som beskrivits ovan.
Så tunneln till compute-0 har följande actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3. Låt oss konvertera 0x16 till decimalform:

0x16 = 6*16^0+1*16^1 = 6+16 = 22

Tunneln till compute-1 har följande VNI: actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2. Låt oss konvertera 0x63 till decimalform:

0x63 = 3*16^0+6*16^1 = 3+96 = 99

Låt oss titta på dumpen nu:

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: lyssnar på vnet4, länktyp EN10MB (Ethernet), fångststorlek 262144 byte

*****************utelämnat*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), längd 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [ingen cksum] VXLAN, flaggor [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), längd 84)
    10.0.1.85 > 10.0.2.8: ICMP ekobegäran, id 5378, sekvens 9, längd 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), längd 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [ingen cksum] VXLAN, flaggor [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), längd 84)
    10.0.1.85 > 10.0.2.8: ICMP ekobegäran, id 5378, sekvens 9, längd 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), längd 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [ingen cksum] VXLAN, flaggor [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), längd 84)
    10.0.2.8 > 10.0.1.85: ICMP ekosvar, id 5378, sekvens 9, längd 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), längd 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [ingen cksum] VXLAN, flaggor [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), längd 84)
    10.0.2.8 > 10.0.1.85: ICMP ekosvar, id 5378, sekvens 9, längd 64
	
*****************utelämnat*******************

Den första paketet är ett vxlan-paket från värden 192.168.255.19 (compute-0) till värden 192.168.255.15 (control-1) med vni 22, inne i vilket ett ICMP-paket är förpackat från värden 10.0.1.85 till värden 10.0.2.8. Som vi beräknade tidigare, motsvarar vni det vi såg i utskrifterna.

Det andra paketet är ett vxlan-paket från värden 192.168.255.15 (control-1) till värden 192.168.255.26 (compute-1) med vni 99, inne i vilket ett ICMP-paket är förpackat från värden 10.0.1.85 till värden 10.0.2.8. Som vi beräknade tidigare, motsvarar vni det vi såg i utskrifterna.

De följande två paketen är bakåttrafik med 10.0.2.8 till 10.0.1.85.

Så i slutändan har vi fått ett sådant schema för kontrollknoden:

Verkar som allt? Vi glömde de två namnområdena:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

Som vi nämnde angående arkitekturen för molnplattformen — det skulle vara bra om maskinerna automatiskt fick adresser från DHCP-servern. Det är de två DHCP-servrarna för våra två nätverk 10.0.1.0/24 och 10.0.2.0/24.

Låt oss kontrollera att det är så. I detta namnrum finns endast en adress — 10.0.1.1 — adressen för själva DHCP-servern, och den ingår också i br-int:

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Låt oss se om det finns processer som innehåller namnet qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 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 finns en sådan process, och baserat på informationen som presenteras ovan kan vi till exempel se vad vi har för uthyrning för tillfället:

[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 ~]$

Slutligen får vi en sådan uppsättning tjänster på kontrollnoden:

Tänk på att det här bara handlar om 4 maskiner, 2 interna nätverk och en virtuell router… För närvarande har vi inga externa nätverk, en massa olika projekt, var och en med sina egna (överlappande) nätverk, och vi har stängt av den distribuerade routern. Dessutom, i testmiljön fanns det bara en kontrollnod (för redundans måste det finnas ett kvorum av tre noder). Det är logiskt att det inom kommersiell verksamhet är "lite" mer komplicerat, men med det här enkla exemplet förstår vi hur det borde fungera – oavsett om du har 3 eller 300 namespace är det viktigt, men när det gäller hela konstruktionen förändras inte speciellt mycket… förutsatt att du inte sätter in någon leverantörsspecifik SDN. Men det är en helt annan historia.

Jag hoppas att det var intressant. Om det finns kommentarer/tillägg eller om jag där jag har ljugit (jag är mänsklig och min åsikt kommer alltid vara subjektiv) – skriv gärna vad som behöver justeras/tilläggas – så fixar vi det.

Avslutningsvis vill jag säga några ord om jämförelsen mellan OpenStack (både vanilla och leverantörsspecifika versioner) och molnlösningen från VMWare – de senaste åren har många ställt denna fråga och jag har ärligt talat tröttnat på den, men ändå. Enligt min åsikt är det väldigt svårt att jämföra de här två lösningarna, men det går att säga att det finns nackdelar med båda, så när man väljer en lösning måste man väga för- och nackdelar noggrant.

Om OpenStack är en community-driven lösning, så har VMWare rätt att göra precis vad de vill (läs – vad som är fördelaktigt för dem) och det är logiskt – eftersom det är ett kommersiellt företag som är van vid att tjäna pengar på sina kunder. Men här finns en stor och viktig NACKDEL – du kan enkelt byta från OpenStack, till exempel från Nokia, och med lätthet gå över till en lösning från Juniper (Contrail Cloud), men att byta från VMWare kommer sannolikt vara mycket svårt. För mig ser de här två lösningarna ut så här – OpenStack (leverantörsspecifik) är en enkel bur, där du har en nyckel och kan gå ut när som helst. VMWare är en gyllene bur, nyckeln till buren tillhör ägaren, och det kommer att kosta dig mycket.

Jag förespråkar varken den första produkten eller den andra — du väljer det som passar dig. Men om jag skulle göra det valet skulle jag välja båda lösningarna — VMWare för IT-molnet (lätta belastningar, enkel hantering), OpenStack från någon leverantör (Nokia och Juniper erbjuder mycket bra nyckelfärdiga lösningar) — för Telekom-molnet. Jag skulle inte använda OpenStack för rent IT — det är som att skjuta med kanoner på månget, men jag ser inga kontraindikationer för att använda det, förutom för överflödighet. Att använda VMWare i telekom är som att transportera grus med en Ford Raptor — snyggt från utsidan, men föraren måste göra 10 körningar istället för en.

Enligt min mening är den största nackdelen med VMWare dess fullständiga slutna natur — företaget ger dig ingen information om hur exempelvis vSAN fungerar eller vad som finns i kärnan på hypervisorn — det är helt enkelt inte i deras intresse — det vill säga, du kommer aldrig att bli expert på VMWare — utan leverantörsstöd är du dömd (jag träffar ofta VMWare-experter som blir ställda av banala frågor). För mig är VMWare som att köpa en bil med ett låst motorhuv — ja, du kanske har specialister som kan byta kamremmen, men endast den som sålde dig lösningen kan öppna motorhuven. Personligen gillar jag inte lösningar som jag inte kan undersöka. Du kanske säger att du förmodligen inte behöver gå ner under motorhuven. Ja, det kan vara så, men jag ser på dig när du behöver bygga en stor funktion i molnet med 20-30 virtuella maskiner, 40-50 nätverk, hälften av dem som vill gå utåt och den andra hälften som begär SR-IOV-accelerering, annars behöver du ytterligare ett par dussin sådana maskiner — annars blir det inte tillräcklig prestanda.

Det finns också andra synpunkter, så det är bara du som kan avgöra vad du ska välja, och viktigast av allt — det är du som sedan ansvarar för ditt val. Detta är bara min åsikt — en person som har sett och rört vid minst 4 produkter — Nokia, Juniper, Red Hat och VMWare. Det vill säga, jag har något att jämföra med.

Källa: habr.com