Cloud computing tränger djupare och djupare in i våra liv och det finns förmodligen inte en enda person som inte har använt några molntjänster minst en gång. Men vad exakt ett moln är och hur det fungerar är det få som vet, även på idénivå. 5G håller redan på att bli verklighet och telekominfrastrukturen börjar gå från pollösningar till molnlösningar, precis som den gjorde när den gick från helt hårdvarulösningar till virtualiserade "pelare".
Idag kommer vi att prata om den inre världen av molninfrastruktur, i synnerhet kommer vi att titta på grunderna i nätverksdelen.
Vad är ett moln? Samma virtualisering - profilvy?
Mer än en logisk fråga. Nej - detta är inte virtualisering, även om det inte skulle kunna göras utan det. Låt oss titta på två definitioner:
Cloud computing (nedan kallat moln) är en modell för att ge användarvänlig åtkomst till distribuerade datorresurser som måste distribueras och lanseras på begäran med lägsta möjliga latens och minimal kostnad för tjänsteleverantören.
Virtualisering - det här är möjligheten att dela upp en fysisk enhet (till exempel en server) i flera virtuella, och därigenom öka utnyttjandet av resurser (till exempel hade du 3 servrar laddade med 25-30 procent, efter virtualisering får du 1 server laddad vid 80-90 procent). Naturligtvis äter virtualisering upp en del av resurserna - du måste mata hypervisorn, men som praktiken har visat är spelet värt ljuset. Ett idealiskt exempel på virtualisering är VMWare, som perfekt förbereder virtuella maskiner, eller till exempel KVM, som jag föredrar, men detta är en smaksak.
Vi använder virtualisering utan att inse det, och även järnroutrar använder redan virtualisering – till exempel i den senaste versionen av JunOS är operativsystemet installerat som en virtuell maskin ovanpå en realtids Linux-distribution (Wind River 9). Men virtualisering är inte molnet, men molnet kan inte existera utan virtualisering.
Virtualisering är en av byggstenarna som molnet bygger på.
Att skapa ett moln genom att helt enkelt samla flera hypervisorer i en L2-domän, lägga till ett par yaml-spelböcker för att automatiskt registrera vlans genom någon form av ansible och jamma något som ett orkestreringssystem på det hela för att automatiskt skapa virtuella maskiner kommer inte att fungera. Det kommer att bli mer exakt, men det resulterande Frankenstein är inte molnet vi behöver, även om det kan vara den ultimata drömmen för andra. Dessutom, om du tar samma Openstack, är det i princip fortfarande Frankenstein, men jaja, låt oss inte prata om det för nu.
Men jag förstår att det från definitionen som presenteras ovan inte är helt klart vad som egentligen kan kallas ett moln.
Därför ger ett dokument från NIST (National Institute of Standards and Technology) 5 huvudegenskaper som en molninfrastruktur bör ha:
Tillhandahåller service på begäran. Användaren måste ges fri tillgång till de datorresurser som tilldelats honom (såsom nätverk, virtuella diskar, minne, processorkärnor, etc.), och dessa resurser måste tillhandahållas automatiskt - det vill säga utan ingripande från tjänsteleverantören.
Stor tillgänglighet av tjänster. Tillgång till resurser måste tillhandahållas av standardmekanismer för att tillåta användning av både standarddatorer och tunna klienter och mobila enheter.
Att kombinera resurser i pooler. Resurspooler måste kunna tillhandahålla resurser till flera kunder samtidigt, vilket säkerställer att kunderna är isolerade och fria från ömsesidigt inflytande och konkurrens om resurser. Nätverk ingår också i poolerna, vilket indikerar möjligheten att använda överlappande adressering. Pooler måste kunna skalas på efterfrågan. Användningen av pooler gör det möjligt att tillhandahålla den nödvändiga nivån av resursfeltolerans och abstraktion av fysiska och virtuella resurser - mottagaren av tjänsten förses helt enkelt med den uppsättning resurser han begärde (där dessa resurser finns fysiskt, på hur många servrar och switchar - det spelar ingen roll för klienten). Vi måste dock ta hänsyn till att leverantören måste säkerställa transparent reservation av dessa resurser.
Snabb anpassning till olika förhållanden. Tjänsterna måste vara flexibla – snabbt tillhandahållande av resurser, deras omfördelning, lägga till eller minska resurser på kundens begäran, och från kundens sida bör det finnas en känsla av att molnresurserna är oändliga. För att underlätta förståelsen, till exempel, ser du inte en varning om att en del av ditt diskutrymme i Apple iCloud har försvunnit eftersom hårddisken på servern har gått sönder och enheter går sönder. Dessutom, från din sida, är möjligheterna för denna tjänst nästan obegränsade - du behöver 2 TB - inga problem, du betalade och fick den. Ett liknande exempel kan ges med Google.Drive eller Yandex.Disk.
Möjlighet att mäta den tillhandahållna tjänsten. Molnsystem måste automatiskt styra och optimera förbrukade resurser, och dessa mekanismer måste vara transparenta för både användaren och tjänsteleverantören. Det vill säga att du alltid kan kontrollera hur många resurser du och dina kunder förbrukar.
Det är värt att tänka på det faktum att dessa krav mestadels är krav för ett offentligt moln, så för ett privat moln (det vill säga ett moln som lanserats för företagets interna behov) kan dessa krav justeras något. Men de måste fortfarande göras, annars får vi inte alla fördelar med cloud computing.
Varför behöver vi ett moln?
Men vilken ny eller existerande teknik som helst, vilket nytt protokoll som helst skapas för något (ja, förutom RIP-ng förstås). Ingen behöver ett protokoll för ett protokolls skull (nåja, förutom RIP-ng förstås). Det är logiskt att molnet är skapat för att tillhandahålla någon form av tjänst till användaren/klienten. Vi är alla bekanta med åtminstone ett par molntjänster, till exempel Dropbox eller Google.Docs, och jag tror att de flesta använder dem framgångsrikt - till exempel skrevs den här artikeln med hjälp av molntjänsten Google.Docs. Men de molntjänster vi känner till är bara en del av molnets möjligheter – mer exakt är de bara en tjänst av SaaS-typ. Vi kan tillhandahålla en molntjänst på tre sätt: i form av SaaS, PaaS eller IaaS. Vilken service du behöver beror på dina önskemål och förmågor.
Låt oss titta på var och en i ordning:
Programvara som en tjänst (SaaS) är en modell för att tillhandahålla en fullfjädrad tjänst till klienten, till exempel en e-posttjänst som Yandex.Mail eller Gmail. I denna tjänsteleveransmodell gör du som kund faktiskt ingenting förutom att använda tjänsterna – det vill säga du behöver inte tänka på att sätta upp tjänsten, dess feltolerans eller redundans. Det viktigaste är att inte kompromissa med ditt lösenord, leverantören av denna tjänst kommer att göra resten åt dig. Ur tjänsteleverantörens synvinkel är han fullt ansvarig för hela tjänsten - från serverhårdvara och värdoperativsystem till databas- och mjukvaruinställningar.
Plattform som en tjänst (PaaS) — När du använder den här modellen förser tjänsteleverantören klienten med ett arbetsstycke för tjänsten, låt oss till exempel ta en webbserver. Tjänsteleverantören försåg klienten med en virtuell server (i själva verket en uppsättning resurser, såsom RAM/CPU/Storage/Nets, etc.), och installerade till och med OS och nödvändig programvara på denna server, men konfigurationen av allt detta görs av kunden själv och för att utföra tjänsten som kunden svarar på. Tjänsteleverantören, som i det tidigare fallet, är ansvarig för prestanda för fysisk utrustning, hypervisorer, själva den virtuella maskinen, dess nätverkstillgänglighet etc., men själva tjänsten är inte längre inom sitt ansvarsområde.
Infrastructure as a Service (IaaS) - detta tillvägagångssätt är redan mer intressant, i själva verket förser tjänsteleverantören klienten med en komplett virtualiserad infrastruktur - det vill säga en uppsättning (pool) av resurser, såsom CPU-kärnor, RAM, nätverk, etc. Allt annat är upp till kunden - vad kunden vill göra med dessa resurser inom den tilldelade poolen (kvoten) - det är inte speciellt viktigt för leverantören. Oavsett om kunden vill skapa sin egen vEPC eller till och med skapa en minioperatör och tillhandahålla kommunikationstjänster - ingen fråga - gör det. I ett sådant scenario är tjänsteleverantören ansvarig för att tillhandahålla resurser, deras feltolerans och tillgänglighet, såväl som operativsystemet som tillåter dem att slå samman dessa resurser och göra dem tillgängliga för klienten med möjlighet att öka eller minska resurser när som helst på kundens begäran. Klienten konfigurerar alla virtuella maskiner och annat glitter själv genom självbetjäningsportalen och konsolen, inklusive konfigurering av nätverk (förutom externa nätverk).
Vad är OpenStack?
I alla tre alternativen behöver tjänsteleverantören ett OS som gör det möjligt att skapa en molninfrastruktur. Faktum är att med SaaS är mer än en division ansvarig för hela högen av teknologier - det finns en division som är ansvarig för infrastrukturen - det vill säga att den tillhandahåller IaaS till en annan division, den här divisionen tillhandahåller SaaS till kunden. OpenStack är ett av molnoperativsystemen som låter dig samla ett gäng switchar, servrar och lagringssystem till en enda resurspool, dela upp denna gemensamma pool i subpooler (hyresgäster) och tillhandahålla dessa resurser till klienter över nätverket.
Openstack är ett molnoperativsystem som låter dig kontrollera stora pooler av datorresurser, datalagring och nätverksresurser, tillhandahållna och hanterade via API med hjälp av vanliga autentiseringsmekanismer.
Med andra ord är detta en uppsättning gratis programvaruprojekt som är utformade för att skapa molntjänster (både offentliga och privata) - det vill säga en uppsättning verktyg som låter dig kombinera server- och växlingsutrustning till en enda pool av resurser, hantera dessa resurser, vilket ger den nödvändiga feltoleransnivån .
Vid tidpunkten för att skriva detta material ser OpenStack-strukturen ut så här:
Bild tagen från
Var och en av komponenterna som ingår i OpenStack utför en specifik funktion. Denna distribuerade arkitektur låter dig inkludera den uppsättning funktionella komponenter som du behöver i lösningen. Vissa komponenter är dock rotkomponenter och deras borttagning kommer att leda till fullständig eller delvis inoperabilitet av lösningen som helhet. Dessa komponenter klassificeras vanligtvis som:
- Dashboard — Webbaserat GUI för hantering av OpenStack-tjänster
- Keystone är en centraliserad identitetstjänst som tillhandahåller autentiserings- och auktoriseringsfunktioner för andra tjänster, samt hanterar användaruppgifter och deras roller.
- Neutron - en nätverkstjänst som tillhandahåller anslutning mellan gränssnitten för olika OpenStack-tjänster (inklusive anslutning mellan virtuella datorer och deras åtkomst till omvärlden)
- Slagg — ger åtkomst till blocklagring för virtuella maskiner
- Nytt — Livscykelhantering av virtuella maskiner
- Blick — arkiv av virtuella maskinbilder och ögonblicksbilder
- Snabb — ger åtkomst till lagringsobjektet
- ceilometer — En tjänst som ger möjlighet att samla in telemetri och mäta tillgängliga och förbrukade resurser
- Värme — orkestrering baserad på mallar för automatiskt skapande och tillhandahållande av resurser
En komplett lista över alla projekt och deras syfte kan ses .
Varje OpenStack-komponent är en tjänst som utför en specifik funktion och tillhandahåller ett API för att hantera den funktionen och interagera med andra molnoperativsystemtjänster för att skapa en enhetlig infrastruktur. Till exempel tillhandahåller Nova datorresurshantering och ett API för åtkomst till att konfigurera dessa resurser, Glance tillhandahåller bildhantering och ett API för att hantera dem, Cinder tillhandahåller blocklagring och ett API för att hantera det, etc. Alla funktioner är sammankopplade på ett mycket nära sätt.
Men om du tittar på det är alla tjänster som körs i OpenStack i slutändan någon form av virtuell maskin (eller behållare) ansluten till nätverket. Frågan uppstår - varför behöver vi så många element?
Låt oss gå igenom algoritmen för att skapa en virtuell maskin och ansluta den till nätverket och beständig lagring i Openstack.
- När du skapar en begäran om att skapa en maskin, vare sig det är en begäran genom Horizon (Dashboard) eller en begäran via CLI, är det första som händer auktoriseringen av din begäran på Keystone - kan du skapa en maskin, har den rätt att använda detta nätverk, gör din utkastkvot osv.
- Keystone autentiserar din begäran och genererar en autentiseringstoken i svarsmeddelandet, som kommer att användas vidare. Efter att ha fått svar från Keystone skickas förfrågan till Nova (nova api).
- Nova-api kontrollerar giltigheten av din begäran genom att kontakta Keystone med den tidigare genererade autentiseringstoken
- Keystone utför autentisering och ger information om behörigheter och begränsningar baserat på denna autentiseringstoken.
- Nova-api skapar en post för den nya virtuella datorn i nova-databasen och skickar begäran om att skapa maskinen till nova-scheduler.
- Nova-scheduler väljer den värd (datornod) som den virtuella datorn ska distribueras på baserat på de angivna parametrarna, vikterna och zonerna. En post över detta och VM ID skrivs till nova-databasen.
- Därefter kontaktar nova-scheduler nova-compute med en begäran om att distribuera en instans. Nova-compute kontaktar nova-conductor för att få information om maskinparametrar (nova-conductor är ett nova-element som fungerar som en proxyserver mellan nova-databas och nova-compute, vilket begränsar antalet förfrågningar till nova-databas för att undvika problem med databasen minskning av konsistensbelastningen).
- Nova-conductor tar emot den efterfrågade informationen från nova-databasen och skickar den till nova-compute.
- Därefter tittar nova-compute-anrop för att få bild-ID. Glace validerar begäran i Keystone och returnerar den begärda informationen.
- Nova-compute kontaktar neutron för att få information om nätverksparametrar. På samma sätt som en blick, validerar neutronen begäran i Keystone, varefter den skapar en post i databasen (portidentifierare, etc.), skapar en begäran om att skapa en port och returnerar den begärda informationen till nova-compute.
- Nova-compute kontaktar cinder med en begäran om att allokera en volym till den virtuella maskinen. På samma sätt som en blick validerar cider begäran i Keystone, skapar en begäran om att skapa volymer och returnerar den begärda informationen.
- Nova-compute kontaktar libvirt med en begäran om att distribuera en virtuell maskin med de angivna parametrarna.
Faktum är att en till synes enkel operation att skapa en enkel virtuell maskin förvandlas till en sådan virvel av API-anrop mellan element i molnplattformen. Dessutom, som du kan se, består även de tidigare utsedda tjänsterna också av mindre komponenter mellan vilka interaktion sker. Att skapa en maskin är bara en liten del av vad molnplattformen tillåter dig att göra - det finns en tjänst som ansvarar för att balansera trafik, en tjänst som ansvarar för blocklagring, en tjänst som ansvarar för DNS, en tjänst som ansvarar för att tillhandahålla bare metal-servrar, etc. Molnet låter dig behandla dina virtuella maskiner som en fårhjord (i motsats till virtualisering). Om något händer med din maskin i en virtuell miljö - du återställer den från säkerhetskopior etc., men molnapplikationer är byggda på ett sådant sätt att den virtuella maskinen inte spelar en så viktig roll - den virtuella maskinen "dog" - inga problem - en ny skapas helt enkelt, fordonet är baserat på mallen och, som de säger, märkte laget inte förlusten av fightern. Naturligtvis ger detta närvaron av orkestreringsmekanismer - med hjälp av Heat-mallar kan du enkelt distribuera en komplex funktion som består av dussintals nätverk och virtuella maskiner.
Det är alltid värt att tänka på att det inte finns någon molninfrastruktur utan ett nätverk – varje element interagerar på ett eller annat sätt med andra element genom nätverket. Dessutom har molnet ett absolut icke-statiskt nätverk. Naturligtvis är underläggsnätverket ännu mer eller mindre statiskt - nya noder och switchar läggs inte till varje dag, men överläggskomponenten kan och kommer oundvikligen att förändras hela tiden - nya nätverk kommer att läggas till eller tas bort, nya virtuella maskiner kommer att dyka upp och gamla kommer att dö. Och som du kommer ihåg från definitionen av molnet som gavs i början av artikeln, bör resurser tilldelas användaren automatiskt och med minsta (eller ännu bättre, utan) ingripande från tjänsteleverantören. Det vill säga, den typ av tillhandahållande av nätverksresurser som nu finns i form av en front-end i form av ditt personliga konto tillgängligt via http/https och den jourhavande nätverksingenjören Vasily som backend är inte ett moln, t.o.m. om Vasily har åtta händer.
Neutron, som en nätverkstjänst, tillhandahåller ett API för att hantera nätverksdelen av molninfrastrukturen. Tjänsten driver och hanterar nätverksdelen av Openstack genom att tillhandahålla ett abstraktionslager som kallas Network-as-a-Service (NaaS). Det vill säga nätverket är samma virtuella mätbara enhet som till exempel virtuella CPU-kärnor eller mängden RAM.
Men innan vi går vidare till arkitekturen för nätverksdelen av OpenStack, låt oss överväga hur detta nätverk fungerar i OpenStack och varför nätverket är en viktig och integrerad del av molnet.
Så vi har två RED-klient-VM och två GREEN-klient-VM. Låt oss anta att dessa maskiner är placerade på två hypervisorer på detta sätt:
För tillfället är detta bara virtualisering av 4 servrar och inget mer, eftersom allt vi har gjort hittills är att virtualisera 4 servrar, placera dem på två fysiska servrar. Och än så länge är de inte ens anslutna till nätverket.
För att göra ett moln behöver vi lägga till flera komponenter. Först virtualiserar vi nätverksdelen - vi måste ansluta dessa 4 maskiner i par, och klienterna vill ha en L2-anslutning. Du kan använda en switch och konfigurera en trunk i dess riktning och lösa allt med en linux-brygga eller, för mer avancerade användare, openvswitch (vi återkommer till detta senare). Men det kan finnas många nätverk, och att ständigt trycka L2 genom en switch är inte den bästa idén - det finns olika avdelningar, en servicedesk, månader av väntan på att en ansökan ska slutföras, veckor av felsökning - i den moderna världen är detta tillvägagångssätt fungerar inte längre. Och ju tidigare ett företag förstår detta, desto lättare är det för det att gå framåt. Därför kommer vi mellan hypervisorerna att välja ett L3-nätverk genom vilket våra virtuella maskiner kommer att kommunicera, och ovanpå detta L3-nätverk kommer vi att bygga virtuella L2-överlagringsnätverk där trafiken från våra virtuella maskiner kommer att köras. Du kan använda GRE, Geneve eller VxLAN som inkapsling. Låt oss fokusera på det senare för nu, även om det inte är särskilt viktigt.
Vi måste hitta VTEP någonstans (jag hoppas att alla är bekanta med VxLAN-terminologi). Eftersom vi har ett L3-nätverk som kommer direkt från servrarna hindrar ingenting oss från att placera VTEP på själva servrarna, och OVS (OpenvSwitch) är utmärkta på att göra detta. Som ett resultat fick vi denna design:
Eftersom trafik mellan virtuella datorer måste delas kommer portarna mot de virtuella maskinerna att ha olika vlan-nummer. Taggnumret spelar bara en roll inom en virtuell switch, eftersom när det är inkapslat i VxLAN kan vi enkelt ta bort det, eftersom vi kommer att ha en VNI.
Nu kan vi skapa våra maskiner och virtuella nätverk för dem utan problem.
Men vad händer om klienten har en annan maskin, men är på ett annat nätverk? Vi behöver rota mellan nätverk. Vi kommer att titta på ett enkelt alternativ när centraliserad routing används - det vill säga trafik dirigeras genom speciella dedikerade nätverksnoder (tja, som regel kombineras de med kontrollnoder, så vi kommer att ha samma sak).
Det verkar som inget komplicerat - vi gör ett brygggränssnitt på kontrollnoden, kör trafik till den och därifrån dirigerar vi den dit vi behöver den. Men problemet är att RED-klienten vill använda 10.0.0.0/24-nätverket, och GREEN-klienten vill använda 10.0.0.0/24-nätverket. Det vill säga vi börjar skära adressutrymmen. Dessutom vill klienter inte att andra klienter ska kunna dirigera in i sina interna nätverk, vilket är vettigt. För att separera nätverken och klientdatatrafiken kommer vi att tilldela ett separat namnutrymme för var och en av dem. Namnutrymmet är i själva verket en kopia av Linux-nätverksstacken, det vill säga klienter i namnutrymmet RED är helt isolerade från klienter från namnområdet GRÖN (nåja, antingen är routing mellan dessa klientnätverk tillåten genom standardnamnutrymmet eller på uppströms transportutrustning).
Det vill säga, vi får följande diagram:
L2-tunnlar konvergerar från alla beräkningsnoder till kontrollnoden. nod där L3-gränssnittet för dessa nätverk finns, var och en i ett dedikerat namnutrymme för isolering.
Vi glömde dock det viktigaste. Den virtuella maskinen måste tillhandahålla en tjänst till klienten, det vill säga den måste ha minst ett externt gränssnitt genom vilket den kan nås. Det vill säga att vi behöver gå ut i omvärlden. Det finns olika alternativ här. Låt oss göra det enklaste alternativet. Vi kommer att lägga till ett nätverk till varje klient, vilket kommer att vara giltigt i leverantörens nätverk och inte överlappar med andra nätverk. Nätverken kan också korsa varandra och titta på olika VRF:er på sidan av leverantörsnätverket. Nätverksdata kommer också att finnas i namnutrymmet för varje klient. Men de kommer fortfarande att gå ut till omvärlden genom ett fysiskt (eller bindning, vilket är mer logiskt) gränssnitt. För att separera klienttrafik kommer trafik som går utanför att märkas med en VLAN-tagg som tilldelas klienten.
Som ett resultat fick vi detta diagram:
En rimlig fråga är varför inte göra gateways på själva beräkningsnoderna? Detta är inte ett stort problem; dessutom, om du slår på den distribuerade routern (DVR), kommer detta att fungera. I det här scenariot överväger vi det enklaste alternativet med en centraliserad gateway, som används som standard i Openstack. För högbelastningsfunktioner kommer de att använda både en distribuerad router och accelerationstekniker som SR-IOV och Passthrough, men som de säger, det är en helt annan historia. Låt oss först ta itu med den grundläggande delen, och sedan går vi in på detaljerna.
Egentligen är vårt system redan fungerande, men det finns ett par nyanser:
- Vi måste på något sätt skydda våra maskiner, det vill säga sätta ett filter på switchgränssnittet mot klienten.
- Gör det möjligt för en virtuell maskin att automatiskt få en IP-adress, så att du inte behöver logga in på den via konsolen varje gång och registrera adressen.
Låt oss börja med maskinskydd. För detta kan du använda banala iptables, varför inte.
Det vill säga, nu har vår topologi blivit lite mer komplicerad:
Låt oss gå vidare. Vi måste lägga till en DHCP-server. Den mest idealiska platsen för att lokalisera DHCP-servrar för varje klient skulle vara kontrollnoden som redan nämnts ovan, där namnområdena finns:
Det finns dock ett litet problem. Tänk om allt startar om och all information om att hyra adresser på DHCP försvinner. Det är logiskt att maskinerna kommer att få nya adresser, vilket inte är särskilt bekvämt. Det finns två vägar ut här - antingen använd domännamn och lägg till en DNS-server för varje klient, då kommer adressen inte att vara särskilt viktig för oss (liknande nätverksdelen i k8s) - men det finns ett problem med externa nätverk, eftersom adresser kan också utfärdas i dem via DHCP - du behöver synkronisering med DNS-servrar i molnplattformen och en extern DNS-server, vilket enligt mig inte är särskilt flexibelt, men är fullt möjligt. Eller det andra alternativet är att använda metadata – det vill säga spara information om adressen som utfärdats till maskinen så att DHCP-servern vet vilken adress som ska utfärdas till maskinen om maskinen redan har fått en adress. Det andra alternativet är enklare och mer flexibelt, eftersom det låter dig spara ytterligare information om bilen. Låt oss nu lägga till agentmetadata till diagrammet:
En annan fråga som också är värd att diskutera är möjligheten att använda ett externt nätverk av alla klienter, eftersom externa nätverk, om de måste vara giltiga i hela nätverket, kommer att vara svårt - du måste hela tiden allokera och kontrollera allokeringen av dessa nätverk. Möjligheten att använda ett enda externt förkonfigurerat nätverk för alla klienter kommer att vara mycket användbar när du skapar ett offentligt moln. Detta kommer att göra det lättare att distribuera maskiner eftersom vi inte behöver konsultera en adressdatabas och välja ett unikt adressutrymme för varje klients externa nätverk. Dessutom kan vi registrera ett externt nätverk i förväg och vid tidpunkten för driftsättning behöver vi bara koppla externa adresser till klientdatorer.
Och här kommer NAT till vår hjälp - vi kommer bara att göra det möjligt för kunder att komma åt omvärlden genom standardnamnutrymmet med hjälp av NAT-översättning. Tja, här är ett litet problem. Detta är bra om klientservern fungerar som en klient och inte som en server - det vill säga den initierar snarare än accepterar anslutningar. Men för oss blir det tvärtom. I det här fallet måste vi göra destinations-NAT så att när den tar emot trafik förstår kontrollnoden att denna trafik är avsedd för virtuell maskin A hos klient A, vilket innebär att vi måste göra en NAT-översättning från en extern adress, till exempel 100.1.1.1 .10.0.0.1, till en intern adress 100. I det här fallet, även om alla klienter kommer att använda samma nätverk, är intern isolering helt bevarad. Det vill säga, vi måste göra dNAT och sNAT på kontrollnoden. Om du ska använda ett enda nätverk med flytande adresser eller externa nätverk, eller båda samtidigt, beror på vad du vill ha med dig in i molnet. Vi kommer inte att lägga till flytande adresser till diagrammet, utan kommer att lämna de externa nätverken som redan lagts till tidigare - varje klient har sitt eget externa nätverk (i diagrammet anges de som vlan 200 och XNUMX på det externa gränssnittet).
Som ett resultat fick vi en intressant och samtidigt genomtänkt lösning, som har en viss flexibilitet men ännu inte har feltoleransmekanismer.
För det första har vi bara en kontrollnod - dess misslyckande kommer att leda till kollaps av alla system. För att åtgärda detta problem måste du göra minst ett kvorum på 3 noder. Låt oss lägga till detta till diagrammet:
Naturligtvis är alla noder synkroniserade och när en aktiv nod lämnar kommer en annan nod att ta över dess ansvar.
Nästa problem är virtuella maskindiskar. För tillfället lagras de på hypervisorerna själva, och vid problem med hypervisorn förlorar vi all data - och närvaron av en raid hjälper inte här om vi förlorar inte disken, utan hela servern. För att göra detta måste vi göra en tjänst som kommer att fungera som frontend för någon form av lagring. Vilken typ av lagring det blir är inte speciellt viktigt för oss, men det ska skydda våra data från fel på både disken och noden, och eventuellt hela skåpet. Det finns flera alternativ här - det finns naturligtvis SAN-nät med Fibre Channel, men låt oss vara ärliga - FC är redan en kvarleva från det förflutna - en analog till E1 inom transport - ja, jag håller med, det används fortfarande, men bara där det är absolut omöjligt utan det. Därför skulle jag inte frivilligt distribuera ett FC-nätverk 2020, med vetskap om att det finns andra mer intressanta alternativ. Även om det för var och en kan finnas de som tror att FC med alla dess begränsningar är allt vi behöver - jag kommer inte att argumentera, alla har sin egen åsikt. Den mest intressanta lösningen enligt mig är dock att använda ett SDS, som Ceph.
Ceph låter dig bygga en mycket tillgänglig datalagringslösning med ett gäng möjliga säkerhetskopieringsalternativ, som börjar med koder med paritetskontroll (analogt med raid 5 eller 6) som slutar med fullständig datareplikering till olika diskar, med hänsyn till diskarnas placering i servrar och servrar i skåp osv.
För att bygga Ceph behöver du ytterligare 3 noder. Interaktion med lagringen kommer också att utföras via nätverket med hjälp av block-, objekt- och fillagringstjänster. Låt oss lägga till lagring till schemat:
Notera: du kan också göra hyperkonvergerade beräkningsnoder - detta är konceptet med att kombinera flera funktioner på en nod - till exempel lagring+beräkning - utan att dedikera speciella noder för ceph-lagring. Vi kommer att få samma feltoleranta system - eftersom SDS kommer att reservera data med den reservationsnivå vi anger. Hyperkonvergerade noder är dock alltid en kompromiss - eftersom lagringsnoden inte bara värmer luften som det verkar vid första anblicken (eftersom det inte finns några virtuella maskiner på den) - den spenderar CPU-resurser på att serva SDS (i själva verket gör den allt replikering och återställning efter fel på noder, diskar, etc.). Det vill säga, du kommer att förlora en del av kraften i beräkningsnoden om du kombinerar den med lagring.
Allt det här måste hanteras på något sätt - vi behöver något genom vilket vi kan skapa en maskin, ett nätverk, en virtuell router, etc. För att göra detta kommer vi att lägga till en tjänst till kontrollnoden som kommer att fungera som en instrumentpanel - den klienten kommer att kunna ansluta till denna portal via http/ https och göra allt han behöver (nåja, nästan).
Som ett resultat har vi nu ett feltåligt system. Alla delar av denna infrastruktur måste hanteras på något sätt. Det har tidigare beskrivits att Openstack är en uppsättning projekt, som vart och ett ger en specifik funktion. Som vi ser finns det mer än tillräckligt med element som måste konfigureras och kontrolleras. Idag ska vi prata om nätverksdelen.
Neutronarkitektur
I OpenStack är det Neutron som ansvarar för att koppla virtuella maskinportar till ett gemensamt L2-nätverk, säkerställa trafikdirigering mellan virtuella datorer som finns på olika L2-nätverk, samt utåtriktad routing, tillhandahålla tjänster som NAT, Floating IP, DHCP, etc.
På hög nivå kan driften av nättjänsten (grunddelen) beskrivas enligt följande.
När du startar den virtuella datorn, nättjänsten:
- Skapar en port för en given virtuell dator (eller portar) och meddelar DHCP-tjänsten om det;
- En ny virtuell nätverksenhet skapas (via libvirt);
- Den virtuella datorn ansluter till porten/portarna som skapades i steg 1;
Märkligt nog är Neutrons arbete baserat på standardmekanismer som är bekanta för alla som någonsin har dykt in i Linux - namnutrymmen, iptables, linux-bryggor, openvswitch, conntrack, etc.
Det bör omedelbart klargöras att Neutron inte är en SDN-styrenhet.
Neutron består av flera sammankopplade komponenter:
Openstack-neutron-server är en demon som arbetar med användarförfrågningar via API:et. Denna demon är inte inblandad i att registrera några nätverksanslutningar, men tillhandahåller nödvändig information för detta till sina plugins, som sedan konfigurerar det önskade nätverkselementet. Neutronagenter på OpenStack-noder registrerar sig hos Neutronservern.
Neutron-server är faktiskt en applikation skriven i python, som består av två delar:
- REST-tjänst
- Neutron Plugin (kärna/tjänst)
REST-tjänsten är utformad för att ta emot API-anrop från andra komponenter (till exempel en begäran om att tillhandahålla viss information, etc.)
Plugins är insticksprogramvarukomponenter/moduler som anropas under API-förfrågningar - det vill säga att tilldelningen av en tjänst sker genom dem. Plugins är uppdelade i två typer - service och root. Som regel är hästpluginen huvudsakligen ansvarig för att hantera adressutrymmet och L2-anslutningar mellan virtuella datorer, och serviceplugins tillhandahåller redan ytterligare funktionalitet som VPN eller FW.
Listan över plugins som är tillgängliga idag kan ses till exempel
Det kan finnas flera serviceplugin, men det kan bara finnas en hästplugin.
openstack-neutron-ml2 är Openstacks vanliga root-plugin. Denna plugin har en modulär arkitektur (till skillnad från sin föregångare) och konfigurerar nätverkstjänsten genom drivrutiner som är anslutna till den. Vi ska titta på själva pluginet lite senare, eftersom det faktiskt ger den flexibilitet som OpenStack har i nätverksdelen. Rotpluginet kan bytas ut (till exempel gör Contrail Networking en sådan ersättning).
RPC-tjänst (rabbitmq-server) — en tjänst som tillhandahåller köhantering och interaktion med andra OpenStack-tjänster, samt interaktion mellan nätverkstjänsteagenter.
Nätverksagenter — agenter som finns i varje nod, genom vilka nätverkstjänster konfigureras.
Det finns flera typer av agenter.
Huvudagenten är L2 agent. Dessa agenter körs på var och en av hypervisorerna, inklusive kontrollnoder (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 ett gemensamt L2-nätverk och även generera varningar när händelser inträffar ( till exempel inaktivera/aktivera porten).
Nästa, inte mindre viktiga agent är L3 agent. Som standard körs denna agent uteslutande på en nätverksnod (ofta kombineras nätverksnoden med en kontrollnod) och tillhandahåller routing mellan hyresgästnätverk (både mellan dess nätverk och andra hyresgästers nätverk, och är tillgänglig för omvärlden, vilket ger NAT, såväl som DHCP-tjänst). Men när du använder en DVR (distribuerad router) dyker behovet av en L3-plugin också upp på beräkningsnoderna.
L3-agenten använder Linux-namnområden för att förse varje hyresgäst med en uppsättning av sina egna isolerade nätverk och funktionaliteten hos virtuella routrar som dirigerar trafik och tillhandahåller gatewaytjänster för Layer 2-nätverk.
Databas — en databas med identifierare för nätverk, undernät, portar, pooler etc.
Faktum är att Neutron accepterar API-förfrågningar från skapandet av nätverksenheter, autentiserar begäran och via RPC (om den får åtkomst till något plugin eller agent) eller REST API (om det kommunicerar i SDN) sänder till agenterna (via plugins) instruktioner som är nödvändiga för att organisera den begärda tjänsten.
Låt oss nu vända oss till testinstallationen (hur den distribueras och vad som ingår i den, vi kommer att se senare i den praktiska delen) och se var varje komponent finns:
(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 hos Neutron. Nu är det värt att spendera lite tid på ML2-plugin.
Modulärt lager 2
Som nämnts ovan är insticksprogrammet ett standard OpenStack root-plugin och har en modulär arkitektur.
Föregångaren till ML2-pluginet hade en monolitisk struktur, som inte tillät till exempel att använda en blandning av flera tekniker i en installation. Till exempel kunde du inte använda både openvswitch och linuxbridge samtidigt - varken den första eller den andra. Av denna anledning skapades ML2-plugin med dess arkitektur.
ML2 har två komponenter - två typer av drivrutiner: Typdrivrutiner och Mekanismdrivrutiner.
Skriv drivrutiner bestämma vilken teknik som kommer att användas för att organisera nätverksanslutningar, till exempel VxLAN, VLAN, GRE. Samtidigt tillåter föraren användningen av olika tekniker. Standardtekniken är VxLAN-inkapsling för överlagringsnätverk och externa vlan-nätverk.
Typdrivrutiner inkluderar följande nätverkstyper:
Flat - nätverk utan taggning
VLAN - taggat nätverk
Lokala — En speciell typ av nätverk för allt-i-ett-installationer (sådana installationer behövs antingen för utvecklare eller för utbildning)
GRE — överläggsnätverk med GRE-tunnlar
VxLAN — överlägg nätverk med VxLAN-tunnlar
Mekanism förare definiera verktyg som säkerställer organisationen av de teknologier som anges i typdrivrutinen - till exempel openvswitch, sr-iov, opendaylight, OVN, etc.
Beroende på implementeringen av denna drivrutin kommer antingen agenter som styrs av Neutron att användas, eller så kommer anslutningar till en extern SDN-kontroller att användas, som tar hand om alla frågor relaterade till att organisera L2-nätverk, routing, etc.
Exempel: om vi använder ML2 tillsammans med OVS, installeras en L2-agent på varje datornod som hanterar OVS. Men om vi använder till exempel OVN eller OpenDayLight, så faller kontrollen av OVS under deras jurisdiktion - Neutron, genom rotpluginen, ger kommandon till kontrollern, och den gör redan vad den blev tillsagd.
Låt oss fräscha upp Open vSwitch
För närvarande är en av nyckelkomponenterna i OpenStack Open vSwitch.
När du installerar OpenStack utan någon ytterligare SDN-leverantör som Juniper Contrail eller Nokia Nuage, är OVS den huvudsakliga nätverkskomponenten i molnnätverket och, tillsammans med iptables, conntrack, namnutrymmen, låter dig organisera fullfjädrade multi-tenancy-överlagringsnätverk. Naturligtvis kan denna komponent ersättas, till exempel vid användning av tredje parts proprietära (leverantör) SDN-lösningar.
OVS är en mjukvaruväxel med öppen källkod som är designad för användning i virtualiserade miljöer som en virtuell trafikförmedlare.
För tillfället har OVS mycket anständig funktionalitet, som inkluderar teknologier som QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK, etc.
Notera: OVS var från början inte tänkt som en mjuk switch för högt belastade telekomfunktioner och var mer designad för mindre bandbreddskrävande IT-funktioner som WEB-server eller e-postserver. OVS utvecklas dock ytterligare och nuvarande implementeringar av OVS har avsevärt förbättrat dess prestanda och kapacitet, vilket gör att den kan användas av telekomoperatörer med högt laddade funktioner, till exempel finns det en OVS-implementation med stöd för DPDK-acceleration.
Det finns tre viktiga komponenter i OVS som du måste vara medveten om:
- Kärnmodul — en komponent placerad i kärnutrymmet som bearbetar trafik baserat på reglerna som tas emot från kontrollelementet;
- vSwitch daemon (ovs-vswitchd) är en process som startas i användarutrymmet som är ansvarig för programmering av kärnmodulen - det vill säga den representerar direkt logiken i switchens funktion
- Databasserver - en lokal databas på varje värd som kör OVS, i vilken konfigurationen lagras. SDN-styrenheter kan kommunicera via denna modul med OVSDB-protokollet.
Allt detta åtföljs av en uppsättning diagnostiska och hanteringsverktyg, såsom ovs-vsctl, ovs-appctl, ovs-ofctl, etc.
För närvarande används Openstack flitigt av teleoperatörer för att migrera nätverksfunktioner till den, såsom EPC, SBC, HLR, etc. Vissa funktioner kan leva utan problem med OVS som de är, men till exempel bearbetar EPC abonnenttrafik - sedan passerar den igenom en enorm mängd trafik (nu når trafikvolymerna flera hundra gigabit per sekund). Att köra sådan trafik genom kärnutrymmet (eftersom speditören är placerad där som standard) är naturligtvis inte den bästa idén. Därför distribueras OVS ofta helt och hållet i användarutrymmet med hjälp av DPDK-accelerationsteknik för att vidarebefordra trafik från NIC till användarutrymme som kringgår kärnan.
Obs: för ett moln som används för telekomfunktioner är det möjligt att mata ut trafik från en beräkningsnod som går förbi OVS direkt till växlingsutrustning. SR-IOV och Passthrough-mekanismer används för detta ändamål.
Hur fungerar detta på en riktig layout?
Nåväl, låt oss nu gå vidare till den praktiska delen och se hur det hela fungerar i praktiken.
Låt oss först distribuera en enkel Openstack-installation. Eftersom jag inte har en uppsättning servrar till hands för experiment, kommer vi att montera prototypen på en fysisk server från virtuella maskiner. Ja, naturligtvis är en sådan lösning inte lämplig för kommersiella ändamål, men för att se ett exempel på hur nätverket fungerar i Openstack räcker en sådan installation för ögonen. Dessutom är en sådan installation ännu mer intressant för träningsändamål - eftersom du kan fånga trafik etc.
Eftersom vi bara behöver se den grundläggande delen kan vi inte använda flera nätverk utan höja allt med bara två nätverk, och det andra nätverket i denna layout kommer att användas uteslutande för åtkomst till undermolnet och DNS-servern. Vi kommer inte att beröra externa nätverk för nu - det här är ett ämne för en separat stor artikel.
Så, låt oss börja i ordning. Först lite teori. Vi kommer att installera Openstack med TripleO (Openstack på Openstack). Kärnan i TripleO är att vi installerar Openstack allt-i-ett (det vill säga på en nod), kallad undercloud, och sedan använder funktionerna i den utplacerade Openstack för att installera Openstack avsedd för drift, kallad overcloud. Undercloud kommer att använda sin inneboende förmåga att hantera fysiska servrar (bar metal) - Ironic-projektet - för att tillhandahålla hypervisorer som kommer att utföra rollerna som beräknings-, kontroll- och lagringsnoder. Det vill säga att vi inte använder några tredjepartsverktyg för att distribuera Openstack - vi distribuerar Openstack med Openstack. Det kommer att bli mycket tydligare när installationen fortskrider, så vi stannar inte där och går vidare.
Obs: I den här artikeln använde jag för enkelhetens skull inte nätverksisolering för interna Openstack-nätverk, utan allt distribueras med bara ett nätverk. Närvaron eller frånvaron av nätverksisolering påverkar dock inte lösningens grundläggande funktionalitet - allt kommer att fungera precis som när man använder isolering, men trafiken kommer att flyta på samma nätverk. För en kommersiell installation är det naturligtvis nödvändigt att använda isolering med olika vlans och gränssnitt. Till exempel, ceph-lagringshanteringstrafik och själva datatrafiken (maskinåtkomst till diskar etc.) när de är isolerade använder olika subnät (Storage management och Storage) och detta gör att du kan göra lösningen mer feltolerant genom att dela upp denna trafik, till exempel , över olika portar, eller använder olika QoS-profiler för olika trafik så att datatrafiken inte klämmer ut signaltrafik. I vårt fall kommer de att gå på samma nätverk och i själva verket begränsar detta oss inte på något sätt.
Obs: Eftersom vi ska köra virtuella maskiner i en virtuell miljö baserad på virtuella maskiner måste vi först aktivera kapslad virtualisering.
Du kan kontrollera om kapslad virtualisering är aktiverad eller inte så här:
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Om du ser bokstaven N, så möjliggör vi stöd för kapslad virtualisering enligt någon guide som du hittar på nätverket, till exempel .
Vi måste sätta ihop följande krets från virtuella maskiner:
I mitt fall, för att ansluta de virtuella maskinerna som är en del av den framtida installationen (och jag fick 7 av dem, men du kan klara dig med 4 om du inte har mycket resurser), använde jag OpenvSwitch. Jag skapade en ovs-brygga och kopplade virtuella maskiner till den via port-grupper. För att göra detta skapade jag en xml-fil så här:
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Tre portgrupper deklareras här - två åtkomst och en trunk (den senare behövdes för DNS-servern, men du kan klara dig utan den, eller installera den på värddatorn - beroende på vilket som är bekvämast för dig). Därefter, med den här mallen, förklarar vi vår via virsh net-define:
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Nu redigerar vi hypervisorns portkonfigurationer:
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Obs: i det här scenariot kommer adressen på port ovs-br1 inte att vara tillgänglig eftersom den inte har en vlan-tagg. För att fixa detta måste du utfärda kommandot sudo ovs-vsctl set port ovs-br1 tag=100. Men efter en omstart kommer denna tagg att försvinna (om någon vet hur man får den att stanna på plats är jag mycket tacksam). Men detta är inte så viktigt, eftersom vi bara behöver den här adressen under installationen och kommer inte att behöva den när Openstack är fullt utplacerad.
Därefter skapar vi en undermolnmaskin:
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Under installationen ställer du in alla nödvändiga parametrar, såsom maskinnamn, lösenord, användare, ntp-servrar, etc., du kan omedelbart konfigurera portarna, men för mig personligen, efter installationen, är det lättare att logga in på maskinen via konsolen och korrigera nödvändiga filer. Om du redan har en färdig bild kan du använda den, eller göra som jag gjorde - ladda ner den minimala Centos 7-bilden och använd den för att installera den virtuella datorn.
Efter lyckad installation bör du ha en virtuell maskin som du kan installera undermoln på
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningInstallera först de verktyg som behövs för installationsprocessen:
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undermoln installation
Vi skapar en stackanvändare, ställer in ett lösenord, lägger till det i sudoer och ger honom möjligheten att utföra root-kommandon genom sudo utan att behöva ange ett lösenord:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackNu anger vi det fullständiga undercloud-namnet i hosts-filen:
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Därefter lägger vi till förråd och installerar programvaran vi behöver:
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-ansibleObs: om du inte planerar att installera ceph behöver du inte ange ceph-relaterade kommandon. Jag använde Queens release, men du kan använda vilken annan du vill.
Kopiera sedan undermolnets konfigurationsfil till användarens hemkatalogstack:
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confNu måste vi korrigera den här filen, anpassa den till vår installation.
Du måste lägga till dessa rader i början av filen:
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Så låt oss gå igenom inställningarna:
undercloud_hostname — Undermolnserverns fullständiga namn måste matcha posten på DNS-servern
local_ip — lokal undermolnadress mot nätverksprovisionering
nätverksgateway — samma lokala adress, som kommer att fungera som en gateway för åtkomst till omvärlden under installationen av övermolnsnoder, sammanfaller också med lokal ip
undercloud_public_host — extern API-adress, valfri ledig adress från provisioneringsnätverket tilldelas
undercloud_admin_host intern API-adress tilldelas valfri ledig adress från provisioneringsnätverket
undercloud_nameservers - DNS-server
generera_tjänstcertifikat - den här raden är mycket viktig i det aktuella exemplet, för om du inte ställer in den på falskt kommer du att få ett felmeddelande under installationen, problemet beskrivs på Red Hats buggspårare
lokalt_gränssnitt gränssnitt i nätverksprovisionering. Det här gränssnittet kommer att omkonfigureras under undermoln-distribution, så du måste ha två gränssnitt på undermolnet - ett för att komma åt det, det andra för provisionering
local_mtu — MTU. Eftersom vi har ett testlaboratorium och jag har en MTU på 1500 på OVS-switchportarna är det nödvändigt att ställa in det på 1450 så att paket inkapslade i VxLAN kan passera igenom
nätverk_cidr — Försörjningsnät
maskerad — använda NAT för att komma åt ett externt nätverk
maskeradnätverk - nätverk som kommer att NATeras
dhcp_start — startadressen för adresspoolen från vilken adresser kommer att tilldelas till noder under övermolndistribution
dhcp_end — den slutliga adressen till adresspoolen från vilken adresser kommer att tilldelas till noder under övermolndistribution
inspection_iprange — en pool av adresser som krävs för introspektion (bör inte överlappa med ovanstående pool)
schemaläggare_max_försök — maximalt antal försök att installera overcloud (måste vara större än eller lika med antalet noder)
När filen har beskrivits kan du ge kommandot att distribuera undermoln:
openstack undercloud install
Proceduren tar från 10 till 30 minuter beroende på ditt strykjärn. I slutändan bör du se utdata så här:
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 utgång säger att du har installerat undermoln framgångsrikt och du kan nu kontrollera undermolnets status och fortsätta med att installera overmoln.
Om du tittar på ifconfig-utgången ser du att ett nytt brygggränssnitt har dykt upp
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Overcloud-distribution kommer nu att utföras via detta gränssnitt.
Från utgången nedan kan du se att vi har alla tjänster 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 är konfigurationen av undermolnets nätverksdel:
(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 ~]$Övermoln installation
För tillfället har vi bara undermoln, och vi har inte tillräckligt med noder som övermoln kommer att monteras från. Låt oss därför först och främst distribuera de virtuella maskiner vi behöver. Under distributionen kommer undercloud självt att installera operativsystemet och den nödvändiga programvaran på overcloud-maskinen - det vill säga vi behöver inte distribuera maskinen helt, utan bara skapa en disk (eller diskar) för den och bestämma dess parametrar - dvs. , i själva verket får vi en bar server utan ett OS installerat på den.
Låt oss gå till mappen med diskarna på våra virtuella maskiner och skapa 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 160GEftersom vi fungerar som root måste vi byta ägare till dessa diskar för att inte få problem med rättigheterna:
[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]# Notera: om du inte planerar att installera ceph för att studera det, skapar kommandona inte minst 3 noder med minst två diskar, men i mallen indikerar att virtuella diskar vda, vdb, etc. kommer att användas.
Bra, nu måste 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 ett kommando -print-xml > /tmp/storage-1.xml, som skapar en xml-fil med en beskrivning av varje maskin i /tmp/-mappen; om du inte lägger till den kommer du inte att bli kunna identifiera virtuella maskiner.
Nu måste 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 nyans - tripleO använder IPMI för att hantera servrar under installation och introspektion.
Introspektion är processen att inspektera hårdvaran för att erhålla dess parametrar som är nödvändiga för ytterligare tillhandahållande av noder. Introspektion utförs med hjälp av ironic, en tjänst utformad för att fungera med barmetallservrar.
Men här är problemet - medan hårdvaru-IPMI-servrar har en separat port (eller en delad port, men detta är inte viktigt), så har virtuella maskiner inte sådana portar. Här kommer en krycka som heter vbmc till vår hjälp - ett verktyg som låter dig emulera en IPMI-port. Denna nyans är värd att uppmärksamma särskilt för dem som vill sätta upp ett sådant laboratorium på en ESXI hypervisor - för att vara ärlig, jag vet inte om den har en analog till vbmc, så det är värt att undra över det här problemet innan du distribuerar allt .
Installera vbmc:
yum install yum install python2-virtualbmcOm ditt operativsystem inte kan hitta paketet, lägg sedan till arkivet:
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmNu sätter vi upp verktyget. Allt här är banalt till en skam. Nu är det logiskt att det inte finns några servrar i vbmc-listan
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# För att de ska visas måste de deklareras manuellt så här:
[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 kommandosyntaxen är tydlig utan förklaring. Men för närvarande är alla våra sessioner i DOWN-status. För att de ska flytta till UPP-status måste du aktivera dem:
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Och sista handen - du måste korrigera brandväggsreglerna (eller inaktivera 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
Låt oss nu gå till undermolnet och kontrollera att allt fungerar. Adressen till värddatorn är 192.168.255.200, på undercloud la vi till det nödvändiga ipmitool-paketet under förberedelserna för distribution:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningSom du kan se har vi framgångsrikt lanserat kontrollnoden via vbmc. Låt oss nu stänga av den och gå vidare:
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Nästa steg är introspektion av noderna där overcloud kommer att installeras. För att göra detta måste vi förbereda en json-fil med en beskrivning av våra noder. Observera att, till skillnad från installation på bara servrar, anger filen porten som vbmc körs på för varje maskin.
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Notera: kontrollnoden har två gränssnitt, men i det här fallet är detta inte viktigt, i den här installationen räcker ett för oss.
Nu förbereder vi json-filen. Vi måste ange poppy-adressen för porten genom vilken provisionering kommer att utföras, parametrarna för noderna, ge dem namn och ange hur man kommer 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 ironi. För att göra detta, ladda ner dem via wget och installera:
(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 ~]$Ladda upp bilder till undermoln:
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Kontrollerar att alla bilder har laddats
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$En sak till - du måste lägga till en DNS-server:
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Nu kan vi ge kommandot för introspektion:
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Som du kan se från utgången slutfördes allt utan fel. Låt oss kontrollera att alla noder är i tillgängligt tillstånd:
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Om noderna är i ett annat tillstånd, vanligtvis hanterbart, gick något fel och du måste titta på loggen och ta reda på varför detta hände. Tänk på att i det här scenariot använder vi virtualisering och det kan finnas buggar förknippade med användningen av virtuella maskiner eller vbmc.
Därefter måste vi ange vilken nod som ska utföra vilken funktion - det vill säga ange profilen med vilken noden kommer att distribueras:
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Ange profilen 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-d9afb69d1167Låt oss kontrollera att vi gjorde 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 att distribuera overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuI en riktig installation kommer anpassade mallar naturligtvis att användas, i vårt fall kommer detta att komplicera processen avsevärt, eftersom varje redigering i mallen måste förklaras. Som skrevs tidigare kommer även en enkel installation att räcka för att vi ska se hur det fungerar.
Obs: variabeln --libvirt-type qemu är nödvändig i det här fallet, eftersom vi kommer att använda kapslad virtualisering. Annars kommer du inte att kunna köra virtuella maskiner.
Nu har du ungefär en timme, eller kanske mer (beroende på hårdvarans kapacitet) och du kan bara hoppas att du efter denna tid kommer 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 fullfjädrad version av openstack, på vilken du kan studera, experimentera osv.
Låt oss kontrollera att allt fungerar som det ska. I användarens hemkatalogstack finns två filer - en stackrc (för att hantera undermoln) och den andra overcloudrc (för att hantera overcloud). Dessa filer måste anges som källa, eftersom de innehåller information som är nödvändig för autentisering.
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Min installation kräver fortfarande en liten touch - lägga till en rutt på styrenheten, eftersom maskinen som jag arbetar med är på ett annat nätverk. För att göra detta, gå till kontroll-1 under heat-admin-kontot och registrera rutten
(undercloud) [stack@undercloud ~]$ ssh [email protected]
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Nåväl, nu kan du gå in i horisonten. All information - adresser, inloggning och lösenord - finns i filen /home/stack/overcloudrc. Det sista diagrammet ser ut så här:
Förresten, i vår installation utfärdades maskinadresser via DHCP och, som du kan se, utfärdas de "slumpmässigt". Du kan strikt definiera i mallen vilken adress som ska kopplas till vilken maskin under driftsättningen, om du behöver det.
Hur flyter trafiken mellan virtuella maskiner?
I den här artikeln kommer vi att titta på tre alternativ för passerande trafik
- Två maskiner på en hypervisor på ett L2-nätverk
- Två maskiner på olika hypervisorer på samma L2-nätverk
- Två maskiner i olika nätverk (rotning över nätverk)
Fall med tillgång till omvärlden via ett externt nätverk, med användning av flytande adresser, samt distribuerad routing, kommer vi att överväga nästa gång, för nu fokuserar vi på intern trafik.
För att kontrollera, låt oss sätta ihop följande diagram:
Vi har skapat 4 virtuella maskiner - 3 på ett L2-nätverk - net-1, och 1 till på net-2-nätverket
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Låt oss se vilka hypervisorer de skapade maskinerna finns 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 |
(övermoln) [stack@undercloud ~]$
Maskinerna vm-1 och vm-3 finns på compute-0, 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ätverk:
(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 tittar på hur trafiken flyter, låt oss titta på vad vi för närvarande har på kontrollnoden (som också är en nätverksnod) och på beräkningsnoden. Låt oss börja med beräkningsnoden.
[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 har noden tre ovs-bryggor - br-int, br-tun, br-ex. Mellan dem, som vi ser, finns det en uppsättning gränssnitt. För att underlätta förståelsen, låt oss rita upp alla dessa gränssnitt på diagrammet och se vad som händer.
Om man tittar på adresserna till vilka VxLAN-tunnlar höjs, kan man se att en tunnel höjs till compute-1 (192.168.255.26), den andra tunneln ser ut till kontroll-1 (192.168.255.15). Men det mest intressanta är att br-ex inte har fysiska gränssnitt, och om man tittar på vilka flöden som är konfigurerade kan man se att den här bron bara kan släppa trafik för tillfället.
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Som du kan se från utgången skruvas adressen direkt till den fysiska porten, och inte till det virtuella brygggrä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 allt som kom från phy-br-ex-porten kasseras.
Egentligen finns det för närvarande ingen annanstans för trafik att komma in på den här bron förutom från detta gränssnitt (gränssnittet med br-int), och av fallen att döma har BUM-trafiken redan flugit in på bron.
Det vill säga att trafik kan lämna denna nod endast genom VxLAN-tunneln och inget annat. Men om du slår på DVR:n kommer situationen att förändras, men vi tar itu med det en annan gång. När du använder nätverksisolering, till exempel med vlans, kommer du inte att ha ett L3-gränssnitt i vlan 0, utan flera gränssnitt. VxLAN-trafik kommer dock att lämna noden på samma sätt, men också inkapslad i någon form av dedikerad vlan.
Vi har sorterat ut beräkningsnoden, låt oss gå vidare till kontrollnoden.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Faktum är att vi kan säga att allt är sig likt, men IP-adressen finns inte längre på det fysiska gränssnittet utan på den virtuella bryggan. Detta görs eftersom denna hamn är den hamn genom vilken trafiken kommer att gå ut till omvärlden.
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Denna port är bunden till br-ex-bryggan och eftersom det inte finns några vlan-taggar på den, är denna port en trunkport där alla vlans är tillåtna, nu går trafiken utanför utan en tagg, vilket indikeras av vlan-id 0 i utgång ovan.
Allt annat för tillfället liknar beräkningsnoden - samma bryggor, samma tunnlar som går till två beräkningsnoder.
Vi kommer inte att överväga lagringsnoder i den här artikeln, men för att förstå är det nödvändigt att säga att nätverksdelen av dessa noder är banal till en skam. I vårt fall finns det bara en fysisk port (eth0) med en IP-adress tilldelad och det är det. Det finns inga VxLAN-tunnlar, tunnelbryggor, etc. - det finns inga ovs alls, eftersom det inte är någon mening med det. När du använder nätverksisolering kommer denna nod att ha två gränssnitt (fysiska portar, bodny eller bara två vlans - det spelar ingen roll - det beror på vad du vill ha) - ett för hantering, det andra för trafik (skriver till VM-disken) , läsa från disk, etc.)
Vi räknade ut vad vi har på noderna i avsaknad av några tjänster. Låt oss nu starta 4 virtuella maskiner och se hur schemat som beskrivs ovan förändras - vi borde ha portar, virtuella routrar, etc.
Hittills ser vårt nätverk ut så här:
Vi har två virtuella maskiner på varje datornod. Med hjälp av compute-0 som ett exempel, låt oss se hur allt ingår.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Maskinen har bara ett virtuellt gränssnitt - tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Det här gränssnittet ser ut i linux-bryggan:
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Som du kan se från utgången finns det bara två gränssnitt i bryggan - tap95d96a75-a0 och qvb95d96a75-a0.
Här är det värt att uppehålla sig lite vid typerna av virtuella nätverksenheter i OpenStack:
vtap - virtuellt gränssnitt kopplat till en instans (VM)
qbr - Linux-brygga
qvb och qvo - vEth-par anslutet till Linux-bryggan och Öppna vSwitch-bryggan
br-int, br-tun, br-vlan — Öppna vSwitch-bryggor
patch-, int-br-, phy-br- - Öppna vSwitch patch-gränssnitt som ansluter bryggor
qg, qr, ha, fg, sg - Öppna vSwitch-portar som används av virtuella enheter för att ansluta till OVS
Som du förstår, om vi har en qvb95d96a75-a0-port i bryggan, som är ett vEth-par, så finns det någonstans dess motsvarighet, som logiskt sett borde heta 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 kan se är hamnen i br-int. Br-int fungerar som en switch som avslutar virtuella maskinportar. Förutom qvo95d96a75-a0 är porten qvo5bd37136-47 synlig i utgången. Detta är porten till den andra virtuella maskinen. Som ett resultat ser vårt diagram nu ut så här:
En fråga som omedelbart borde intressera den uppmärksamma läsaren - vad är linux-bryggan mellan den virtuella maskinporten och OVS-porten? Faktum är att för att skydda maskinen används säkerhetsgrupper, som inte är något annat än iptables. OVS fungerar inte med iptables, så denna "krycka" uppfanns. Den håller dock på att bli föråldrad - den ersätts av conntrack i nya släpp.
Det vill säga, i slutändan ser schemat ut så här:
Två maskiner på en hypervisor på ett L2-nätverk
Eftersom dessa två virtuella datorer är placerade på samma L2-nätverk och på samma hypervisor, kommer trafiken mellan dem logiskt att flyta lokalt genom br-int, eftersom båda datorerna kommer att vara på 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 på samma L2-nätverk
Låt oss nu se hur trafiken kommer att gå mellan två maskiner på samma L2-nätverk, men placerade på olika hypervisorer. För att vara ärlig kommer ingenting att förändras mycket, bara trafik mellan hypervisorer kommer att gå genom vxlan-tunneln. Låt oss titta på ett exempel.
Adresser till virtuella maskiner mellan vilka vi kommer att titta på trafik:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Vi tittar på vidarebefordrantabellen 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 hamn 2 - låt oss se vilken typ av hamn 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 ~]$Det här är patch-tun - det vill säga gränssnittet i br-tun. Låt oss se 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 paketeras i VxLAN och skickas till port 2. Låt oss se 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 ~]$Det här är en vxlan-tunnel på compute-1:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Låt oss gå till compute-1 och se vad som händer härnäst 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 finns i br-int-vidarebefordrantabellen på compute-1, och som kan ses från utgången ovan är den synlig 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:46Tja, då ser vi att det i br-int på compute-1 finns en destinationsvallmo:
[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 flyga till port 3, bakom vilken det redan finns en virtuell maskininstans-00000003.
Det fina med att distribuera Openstack för lärande på virtuell infrastruktur är att vi enkelt kan fånga trafik mellan hypervisorer och se vad som händer med den. Detta är vad vi kommer att göra nu, kör tcpdump på vnet-porten mot compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Den första raden visar att Patek från adress 10.0.1.85 går till adress 10.0.1.88 (ICMP-trafik), och den är inlindad i ett VxLAN-paket med vni 22 och paketet går från värd 192.168.255.19 (compute-0) till värd 192.168.255.26 .1 (beräkna-XNUMX). Vi kan kontrollera att VNI matchar den som anges i ovs.
Låt oss återgå till den här raden actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2. 0x16 är vni i hexadecimalt talsystem. Låt oss konvertera detta tal till det tionde systemet:
16 = 6*16^0+1*16^1 = 6+16 = 22Det vill säga vni motsvarar verkligheten.
Den andra raden visar returtrafik, ja, det är ingen idé att förklara det, där är allt klart.
Två maskiner i olika nätverk (routing mellan nätverk)
Det sista fallet för idag är routing mellan nätverk inom ett projekt med hjälp av en virtuell router. Vi överväger ett fall utan en DVR (vi kommer att titta på det i en annan artikel), så routing sker på nätverksnoden. I vårt fall är nätverksnoden inte placerad i en separat enhet och ligger på kontrollnoden.
Låt oss först 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 statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msEftersom paketet i det här fallet måste gå till gatewayen och dirigeras dit, måste vi ta reda på MAC-adressen för gatewayen, för vilken vi tittar på ARP-tabellen i fallet:
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Låt oss nu se vart trafiken med destination (10.0.1.254) fa:16:3e:c4:64:70 ska skickas:
[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 ~]$ Låt oss titta på var 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 ~]$ Allt är logiskt, trafiken går till br-tun. Låt oss se vilken vxlan-tunnel den kommer att lindas 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 tittar 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 inuti exakt likadan ut som beräkningsnoden - samma tre bryggor, bara br-ex hade en fysisk port genom vilken noden kunde skicka trafik utanför. Skapandet av instanser ändrade konfigurationen på beräkningsnoderna - linuxbrygga, iptables och gränssnitt lades till noderna. Skapandet av nätverk och en virtuell router satte också sina spår på konfigurationen av kontrollnoden.
Så det är uppenbart att gateway-MAC-adressen måste finnas i br-int-vidarebefordrantabellen på kontrollnoden. Låt oss kontrollera att den finns där och var den letar:
[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 ~]$ Macen är synlig från port qr-0c52b15f-8f. Om vi går tillbaka till listan över virtuella portar i Openstack så används denna typ av port för att koppla olika virtuella enheter till OVS. För att vara mer exakt är qr en port till den virtuella routern, som representeras som ett namnområde.
Låt oss se vilka namnområden 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 ~]$ Så många som tre exemplar. Men av namnen att döma kan du gissa syftet med vart och ett av dem. Vi återkommer till instanser 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 ~]$ Detta namnutrymme innehåller två interna som vi skapade tidigare. Båda virtuella portarna har lagts till i br-int. Låt oss kontrollera mac-adressen för porten qr-0c52b15f-8f, eftersom trafiken, att döma av destinationens mac-adress, gick till detta 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<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Det vill säga, i det här fallet fungerar allt enligt lagarna för standard routing. Eftersom trafiken är avsedd för värd 10.0.2.8 måste den gå ut genom det andra gränssnittet qr-92fa49b5-54 och gå genom vxlan-tunneln till beräkningsnoden:
[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 var vallmoadressen för värd 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 väntat går trafiken till br-tun, låt oss se vilken tunnel trafiken går till härnäst:
[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 in i tunneln för att beräkna-1. Tja, på compute-1 är allt enkelt - från br-tun går paketet till br-int och därifrån till 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 detta 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 ~]$
Egentligen gick vi hela vägen igenom paketet. Jag tror att du märkte att trafiken gick genom olika vxlan-tunnlar och gick ut med olika VNI:er. Låt oss se vilken typ av VNI det är, varefter vi samlar in en dump på nodens kontrollport och ser till att trafiken flyter exakt 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 decimaltalssystemet:
0x16 = 6*16^0+1*16^1 = 6+16 = 22Tunneln 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 decimaltalssystemet:
0x63 = 3*16^0+6*16^1 = 3+96 = 99Nåväl, låt oss nu titta på soptippen:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Det första paketet är ett vxlan-paket från värd 192.168.255.19 (compute-0) till värd 192.168.255.15 (kontroll-1) med vni 22, i vilket ett ICMP-paket paketeras från värd 10.0.1.85 till värd 10.0.2.8. Som vi beräknade ovan matchar vni vad vi såg i utdata.
Det andra paketet är ett vxlan-paket från värd 192.168.255.15 (kontroll-1) till värd 192.168.255.26 (compute-1) med vni 99, i vilket ett ICMP-paket paketeras från värd 10.0.1.85 till värd 10.0.2.8. Som vi beräknade ovan matchar vni vad vi såg i utdata.
De nästa två paketen är returtrafik från 10.0.2.8 inte 10.0.1.85.
Det vill säga, till slut fick vi följande kontrollnodschema:
Ser det ut som det är det? Vi glömde två namnutrymmen:
[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 ~]$ När vi pratade om molnplattformens arkitektur skulle det vara bra om maskiner fick adresser automatiskt från en DHCP-server. Dessa är två DHCP-servrar för våra två nätverk 10.0.1.0/24 och 10.0.2.0/24.
Låt oss kontrollera att detta är sant. Det finns bara en adress i detta namnutrymme - 10.0.1.1 - adressen till 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<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Låt oss se om processer som innehåller qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 i deras namn 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 utifrån informationen som presenteras i utgången ovan kan vi till exempel se vad vi har att hyra just nu:
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Som ett resultat får vi följande uppsättning tjänster på kontrollnoden:
Tja, kom ihåg - det här är bara 4 maskiner, 2 interna nätverk och en virtuell router... Vi har inga externa nätverk här nu, en massa olika projekt, alla med sina egna nätverk (överlappande), och vi har en distribuerad router avstängd, och i slutändan Det fanns trots allt bara en kontrollnod i testbänken (för feltolerans måste det finnas ett kvorum på tre noder). Det är logiskt att i handeln är allt "lite" mer komplicerat, men i detta enkla exempel förstår vi hur det ska fungera - om du har 3 eller 300 namnrymder är naturligtvis viktigt, men ur synvinkeln av driften av hela struktur, ingenting kommer att förändras mycket... men tills du inte kopplar in någon leverantörs SDN. Men det är en helt annan historia.
Jag hoppas att det var intressant. Om du har några kommentarer/tillägg, eller någonstans jag rent ut ljög (jag är mänsklig och min åsikt kommer alltid att vara subjektiv) - skriv vad som behöver korrigeras/läggs till - vi korrigerar/lägger till allt.
Avslutningsvis skulle jag vilja säga några ord om att jämföra Openstack (både vanilj och leverantör) med molnlösningen från VMWare - jag har fått den här frågan för ofta under de senaste åren och ärligt talat, jag är redan trött på det, men ändå. Enligt mig är det väldigt svårt att jämföra dessa två lösningar, men vi kan definitivt säga att det finns nackdelar med båda lösningarna och när man väljer en lösning måste man väga för- och nackdelar.
Om OpenStack är en community-driven lösning så har VMWare rätt att bara göra vad den vill (läs - vad som är lönsamt för det) och det är logiskt - eftersom det är ett kommersiellt företag som är vant att tjäna pengar på sina kunder. Men det finns ett stort och tjockt MEN - du kan gå av OpenStack, till exempel från Nokia, och med små kostnader byta till en lösning från till exempel Juniper (Contrail Cloud), men det är osannolikt att du kommer att kunna ta dig av VMWare . För mig ser dessa två lösningar ut så här - Openstack (leverantör) är en enkel bur som du sätts i, men du har en nyckel och du kan lämna när som helst. VMWare är en gyllene bur, ägaren har nyckeln till buren och det kommer att kosta dig mycket.
Jag marknadsför varken den första produkten eller den andra - du väljer vad du behöver. Men om jag hade ett sådant val skulle jag välja båda lösningarna - VMWare för IT-molnet (låg belastning, enkel hantering), OpenStack från någon leverantör (Nokia och Juniper tillhandahåller mycket bra nyckelfärdiga lösningar) - för Telekommolnet. Jag skulle inte använda Openstack för ren IT - det är som att skjuta sparvar med en kanon, men jag ser inga kontraindikationer för att använda det annat än redundans. Men att använda VMWare i telekom är som att dra krossad sten i en Ford Raptor - det är vackert från utsidan, men föraren måste göra 10 turer istället för en.
Enligt min åsikt är den största nackdelen med VMWare dess fullständiga slutenhet - företaget kommer inte att ge dig någon information om hur det fungerar, till exempel vSAN eller vad som finns i hypervisorkärnan - det är helt enkelt inte lönsamt för det - det vill säga du kommer att bli aldrig expert på VMWare - utan leverantörssupport är du dömd (mycket ofta träffar jag VMWare-experter som förbryllas av triviala frågor). För mig köper VMWare en bil med motorhuven låst - ja, du kanske har specialister som kan byta kamremmen, men det är bara den som sålt dig den här lösningen som kan öppna motorhuven. Personligen gillar jag inte lösningar som jag inte kan passa in i. Du kommer att säga att du kanske inte behöver gå under huven. Ja, detta är möjligt, men jag ska titta på dig när du behöver montera en stor funktion i molnet från 20-30 virtuella maskiner, 40-50 nätverk, varav hälften vill gå ut och den andra hälften ber om SR-IOV-acceleration, annars behöver du mer ett par dussin av dessa bilar - annars räcker inte prestandan till.
Det finns andra synpunkter, så det är bara du som kan bestämma vad du ska välja och, viktigast av allt, du kommer då att ansvara 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. Dvs jag har något att jämföra med.
Källa: will.com