Hej, jag heter Kostya Kramlikh, jag är ledande utvecklare av Virtual Private Cloud-divisionen i Yandex.Cloud. Jag är en virtuell nätverkare, och som du kanske kan gissa, i den här artikeln kommer jag att prata om Virtual Private Cloud (VPC)-enheten i allmänhet och det virtuella nätverket i synnerhet. Och du får också reda på varför vi, utvecklarna av tjänsten, värdesätter feedback från våra användare. Men först till kvarn.
Vad är VPC?
Nuförtiden finns det en mängd olika alternativ för att distribuera tjänster. Jag är säker på att någon fortfarande håller servern under administratörens skrivbord, även om jag hoppas att det finns färre sådana historier.
Nu försöker tjänster gå till offentliga moln, och det är här de kolliderar med VPC:er. VPC är en del av ett offentligt moln som binder samman användare, infrastruktur, plattform och andra kapaciteter, var de än befinner sig, i vårt moln eller utanför det. Samtidigt låter VPC dig inte exponera dessa kapaciteter för Internet i onödan, de förblir inom ditt isolerade nätverk.
Hur ser ett virtuellt nätverk ut från utsidan?
Med VPC menar vi i första hand ett överläggsnätverk och nätverkstjänster, såsom VPNaaS, NATaas, LBaas, etc. Och allt detta fungerar ovanpå en feltolerant nätverksinfrastruktur, som redan har varit här, på Habré.
Låt oss ta en närmare titt på det virtuella nätverket och dess enhet.
Tänk på två tillgänglighetszoner. Vi tillhandahåller ett virtuellt nätverk - vad vi kallade VPC. I själva verket definierar det utrymmet av unikhet för dina "grå" adresser. Inom varje virtuellt nätverk har du fullständig kontroll över utrymmet med adresser som du kan tilldela beräkningsresurser.
Nätverket är globalt. Samtidigt projiceras den på var och en av tillgänglighetszonerna i form av en enhet som kallas Subnet. För varje subnät tilldelar du en CIDR av storlek 16 eller mindre. Det kan finnas mer än en sådan enhet i varje tillgänglighetszon, och det finns alltid en transparent routing mellan dem. Det betyder att alla dina resurser inom samma VPC kan "prata" med varandra, även om de är i olika Tillgänglighetszoner. "Kommunicera" utan tillgång till Internet, genom våra interna kanaler, "tror" att de är inom samma privata nätverk.
Diagrammet ovan visar en typisk situation: två VPC:er som skär varandra någonstans i adresser. Båda kan bli dina. Till exempel, en för utveckling, den andra för testning. Det kan helt enkelt vara olika användare - i det här fallet spelar det ingen roll. Och en virtuell maskin är ansluten till varje VPC.
Låt oss göra schemat värre. Du kan göra det så att en virtuell maskin fastnar i flera undernät samtidigt. Och inte bara så, utan i olika virtuella nätverk.
Samtidigt, om du behöver exponera maskiner för Internet, kan detta göras genom API eller UI. För att göra detta måste du konfigurera NAT-översättning av din "grå", interna adress till "vit" - offentlig. Du kan inte välja en "vit" adress, den tilldelas slumpmässigt från vår pool av adresser. Så fort du slutar använda den externa IP:n återförs den till poolen. Du betalar endast för tiden du använder den "vita" adressen.
Det är också möjligt att ge maskinen åtkomst till Internet med hjälp av en NAT-instans. Du kan dirigera trafik till en instans genom en statisk routingtabell. Vi har tillhandahållit ett sådant fall, eftersom användare ibland behöver det, och vi vet om det. Följaktligen innehåller vår bildkatalog en speciellt konfigurerad NAT-bild.
Men även när det finns en färdig NAT-bild kan installationen vara knepig. Vi förstod att för vissa användare är detta inte det mest bekväma alternativet, så till slut gjorde vi det möjligt att aktivera NAT för det önskade subnätet med ett klick. Den här funktionen är fortfarande i stängd förhandsvisningsåtkomst, där den testas med hjälp av communitymedlemmar.
Hur det virtuella nätverket är ordnat från insidan
Hur interagerar användaren med det virtuella nätverket? Webben ser utåt med sitt API. Användaren kommer till API:et och arbetar med måltillståndet. Genom API:t ser användaren hur allt ska ordnas och konfigureras, samtidigt som han ser status, hur mycket det faktiska tillståndet skiljer sig från det önskade. Detta är en bild på användaren. Vad händer inuti?
Vi skriver det önskade tillståndet till Yandex Database och går till att konfigurera olika delar av vår VPC. Överlagringsnätverket i Yandex.Cloud är baserat på utvalda komponenter i OpenContrail, som nyligen kallats Tungsten Fabric. Nätverkstjänster implementeras på en enda CloudGate-plattform. I CloudGate använde vi också ett antal komponenter med öppen källkod: GoBGP - för att komma åt kontrollinformation, samt VPP - för att implementera en mjukvarurouter som körs ovanpå DPDK för datavägen.
Tungsten Fabric kommunicerar med CloudGate via GoBGP. Berättar vad som händer i överläggsnätverket. CloudGate kopplar i sin tur samman överlagringsnätverk med varandra och med Internet.
Låt oss nu se hur ett virtuellt nätverk löser problemen med skalning och tillgänglighet. Låt oss överväga ett enkelt fall. Det finns en tillgänglighetszon och två VPC:er skapas i den. Vi distribuerade en Tungsten Fabric-instans, och den drar flera tiotusentals nätverk. Nätverk kommunicerar med CloudGate. CloudGate, som vi redan har sagt, säkerställer deras anslutning till varandra och med Internet.
Låt oss säga att en andra tillgänglighetszon läggs till. Den borde misslyckas helt oberoende av den första. Därför måste vi i den andra tillgänglighetszonen installera en separat Tungsten Fabric-instans. Detta kommer att vara ett separat system som hanterar överlägget och vet lite om det första systemet. Och synligheten att vårt virtuella nätverk är globalt skapar faktiskt vårt VPC API. Detta är hans uppgift.
VPC1 mappas till tillgänglighetszon B om det finns resurser i tillgänglighetszon B som skjuts till VPC1. Om det inte finns några resurser från VPC2 i tillgänglighetszon B kommer vi inte att realisera VPC2 i denna zon. I sin tur, eftersom resurser från VPC3 endast finns i zon B, existerar inte VPC3 i zon A. Allt är enkelt och logiskt.
Låt oss gå lite djupare och se hur en viss värd i Y.Cloud fungerar. Det viktigaste som jag vill notera är att alla värdar är ordnade på samma sätt. Vi gör det så att endast det nödvändiga minimum av tjänster körs på hårdvara, resten körs på virtuella maskiner. Vi bygger högre ordningstjänster baserade på grundläggande infrastrukturtjänster, och använder även molnet för att lösa vissa tekniska problem, till exempel inom ramen för Continuous Integration.
Om vi tittar på en specifik värd kan vi se att det finns tre komponenter som körs på värdoperativsystemet:
- Compute - den del som ansvarar för distributionen av datorresurser på värden.
- VRouter är en del av Tungsten Fabric som organiserar ett överlägg, det vill säga den tunnlar paket genom ett underlag.
- VDisks är bitar av lagringsvirtualisering.
Dessutom lanseras tjänster i virtuella maskiner: Molninfrastrukturtjänster, plattformstjänster och kundkapacitet. Kundkapacitet och plattformstjänster går alltid till överlagringen genom VRouter.
Infrastrukturtjänster kan sticka in i överlägget, men i grunden vill de arbeta i underlägget. De sticks in i underlaget med hjälp av SR-IOV. Faktum är att vi skär kortet i virtuella nätverkskort (virtuella funktioner) och trycker in dem i virtuella infrastrukturmaskiner för att inte förlora prestanda. Till exempel lanseras samma CloudGate som en av dessa virtuella infrastrukturmaskiner.
Nu när vi har beskrivit de globala uppgifterna för det virtuella nätverket och strukturen för de grundläggande komponenterna i molnet, låt oss se hur exakt de olika delarna av det virtuella nätverket interagerar med varandra.
Vi skiljer tre lager i vårt system:
- Config Plane - ställer in systemets måltillstånd. Detta är vad användaren konfigurerar via API:et.
- Kontrollplan - tillhandahåller användardefinierad semantik, det vill säga bringar tillståndet Dataplan till det som beskrevs av användaren i Config Plane.
- Data Plane - bearbetar användarens paket direkt.
Som jag sa ovan börjar allt med att användaren eller den interna plattformstjänsten kommer till API:t och beskriver ett visst måltillstånd.
Detta tillstånd skrivs omedelbart till Yandex Database, returnerar det asynkrona operations-ID via API:t och startar vårt interna maskineri för att returnera det tillstånd som användaren ville ha. Konfigurationsuppgifter går till SDN-styrenheten och talar om för Tungsten Fabric vad som ska göras i överlägget. De reserverar till exempel portar, virtuella nätverk och liknande.
Config Plane in Tungsten Fabric skickar det erforderliga tillståndet till kontrollplanet. Genom det kommunicerar Config Plane med värdarna och berättar vad som kommer att snurra på dem snart.
Låt oss nu se hur systemet ser ut på värdarna. Den virtuella maskinen har en nätverksadapter ansluten till VRouter. VRouter är en kärnmodul för Tungsten Fabric som tittar på paket. Om det redan finns ett flöde för något paket, bearbetar modulen det. Om det inte finns något flöde gör modulen så kallad punting, det vill säga den skickar ett paket till usermod-processen. Processen analyserar paketet och svarar antingen på det själv, som DHCP och DNS, eller talar om för VRouter vad den ska göra med det. Efter det kan VRouter bearbeta paketet.
Vidare går trafik mellan virtuella maskiner inom samma virtuella nätverk transparent, den dirigeras inte till CloudGate. Värdarna på vilka de virtuella maskinerna är utplacerade kommunicerar direkt med varandra. De tunnlar trafiken och vidarebefordrar den åt varandra genom underlaget.
Kontrollplan kommunicerar med varandra mellan tillgänglighetszoner via BGP, som med en annan router. De berättar vilka maskiner som är uppe var så att virtuella datorer i en zon kan kommunicera direkt med andra virtuella datorer.
Och Control Plane kommunicerar med CloudGate. På samma sätt rapporterar den var och vilka virtuella maskiner som är uppbyggda, vilka adresser de har. Detta gör att du kan dirigera extern trafik och trafik från balansörer till dem.
Trafiken som lämnar VPC:n kommer till CloudGate, till datavägen, där VPP med våra plugins snabbt tuggas i sig. Sedan skickas trafiken antingen till andra VPC:er eller utanför, till gränsroutrar som är konfigurerade genom själva CloudGates kontrollplan.
Planer för den närmaste framtiden
Om vi sammanfattar allt som sagts ovan i några få meningar kan vi säga att VPC i Yandex.Cloud löser två viktiga uppgifter:
- Ger isolering mellan olika klienter.
- Kombinerar resurser, infrastruktur, plattformstjänster, andra moln och on-premise till ett enda nätverk.
Och för att lösa dessa problem väl måste du tillhandahålla skalbarhet och feltolerans på nivån för den interna arkitekturen, vilket VPC gör.
Gradvis får VPC funktioner, vi implementerar nya funktioner, vi försöker förbättra något när det gäller användarvänlighet. Vissa idéer uttrycks och hamnar på prioriteringslistan tack vare medlemmarna i vår community.
Vi har för närvarande följande lista med planer för den närmaste framtiden:
- VPN som en tjänst.
- Privata DNS-instanser är bilder för att snabbt ställa in virtuella maskiner med en förkonfigurerad DNS-server.
- DNS som en tjänst.
- Intern lastbalanserare.
- Lägga till en "vit" IP-adress utan att återskapa den virtuella maskinen.
Balanseringen och möjligheten att byta IP-adress för en redan skapad virtuell maskin fanns på denna lista på begäran av användare. För att vara ärlig, utan explicit feedback, skulle vi ha tagit på oss dessa funktioner lite senare. Och så arbetar vi redan med problemet med adresser.
Från början kunde en "vit" IP-adress bara läggas till när en maskin skapades. Om användaren glömde att göra detta måste den virtuella maskinen återskapas. Detsamma och, om nödvändigt, ta bort den externa IP-adressen. Det kommer snart att vara möjligt att slå på och av den offentliga IP-adressen utan att behöva återskapa maskinen.
Ge gärna uttryck för din andra användare. Du hjälper oss att göra molnet bättre och få viktiga och användbara funktioner snabbare!
Källa: will.com