Hej, jag heter Kostya Kramlih och jag Àr ledande utvecklare inom Virtual Private Cloud-sektionen pÄ Yandex.Cloud. Jag arbetar med virtuella nÀtverk, och som du kanske kan gissa kommer jag i den hÀr artikeln att berÀtta om hur Virtual Private Cloud (VPC) Àr organiserat i stort och virtuella nÀtverk i synnerhet. Dessutom kommer du att fÄ veta varför vi, tjÀnsteutvecklarna, vÀrderar feedback frÄn vÄra anvÀndare. Men lÄt oss ta det steg för steg.
Vad Àr VPC?
Numera finns det mÄnga olika möjligheter för att driftsÀtta tjÀnster. Jag Àr sÀker pÄ att det fortfarande finns nÄgon som har en server under administratörens skrivbord, Àven om jag hoppas att sÄdana historier blir allt fÀrre.
Nu strÀvar tjÀnster efter att flytta till offentliga moln, och hÀr stöter de pÄ VPC. VPC Àr en del av det offentliga molnet som sammanfogar anvÀndarens, infrastrukturella, plattforms- och andra resurser, oavsett var de finns, i vÄrt moln eller utanför det. Samtidigt gör VPC det möjligt att inte exponera dessa resurser pÄ internet utan att det Àr nödvÀndigt, de förblir inom ditt avskilda nÀtverk.
Hur det virtuella nÀtverket ser ut utifrÄn
Med VPC menar vi först och frÀmst ett overlay-nÀtverk och nÀtverkstjÀnster sÄsom VPNaaS, NATaas, LBaas, etc. Och allt detta fungerar ovanpÄ en felresistent nÀtverksinfrastruktur som redan har diskuterats en utmÀrkt artikel hÀr pÄ Habr.
LÄt oss ta en nÀrmare titt pÄ det virtuella nÀtverket och dess struktur.
Vi ska titta pĂ„ tvĂ„ tillgĂ€nglighetszoner. Vi tillhandahĂ„ller ett virtuellt nĂ€tverk â det vi kallar VPC. Faktiskt definierar det utrymmet för unika "grĂ„" adresser. Inom varje virtuellt nĂ€tverk har du full kontroll över adresserna som du kan tilldela berĂ€kningsresurser.
NÀtverket Àr globalt. Det projiceras pÄ varje tillgÀnglighetszon genom en enhet som kallas Subnet. För varje Subnet tilldelar du en CIDR-storlek pÄ 16 eller mindre. Det kan finnas mer Àn en sÄdan enhet i varje tillgÀnglighetszon, och det finns alltid transparent routing mellan dem. Detta innebÀr att alla dina resurser inom en VPC kan "kommunicera" med varandra, Àven om de befinner sig i olika tillgÀnglighetszoner. "Kommunicera" utan att nÄ internet, genom vÄra interna kanaler, "tÀnkande" att de befinner sig inom samma privata nÀtverk.
I diagrammet ovan visas en typisk situation: tvĂ„ VPC:er som överlappar varandra pĂ„ adresserna. BĂ„da kan tillhöra dig. Till exempel, en för utveckling, en annan för testning. Det kan ocksĂ„ vara olika anvĂ€ndare â i detta fall spelar det ingen roll. Och i varje VPC finns en virtuell maskin.
LÄt oss försvÄra schemat. Man kan göra sÄ att en virtuell maskin kopplas till flera Subnet samtidigt. Och inte bara sÄ, utan i olika virtuella nÀtverk.
Om du behöver exponera maskinerna pĂ„ internet kan detta göras via API eller UI. För detta Ă€ndamĂ„l mĂ„ste du konfigurera NAT-översĂ€ttning av din "grĂ„", interna adress till en "vit" â publik. Du kan inte vĂ€lja den "vita" adressen, den tilldelas slumpmĂ€ssigt frĂ„n vĂ„r adresspool. SĂ„ snart du slutar anvĂ€nda den externa IP-adressen Ă„tergĂ„r den till poolen. Du betalar endast för den tid du anvĂ€nder den "vita" adressen.
Det finns ocksÄ möjlighet att ge en maskin internetÄtkomst med hjÀlp av en NAT-instans. Trafik kan dirigeras genom en statisk routingtabel till instansen. Vi har förberett ett sÄdant fall, eftersom det kan vara behövt av anvÀndare, och vi Àr medvetna om detta. DÀrför finns det en sÀrskilt konfigurerad NAT-image i vÄr bildkatalog.
Men Àven nÀr det finns en fÀrdig NAT-image kan konfigurationen vara komplicerad. Vi förstod att det för vissa anvÀndare inte Àr det mest bekvÀma alternativet, sÄ vi gjorde i slutÀndan det möjligt att aktivera NAT för den önskade Subnet med ett klick. Denna funktion Àr fortfarande i stÀngt förhandsvisningslÀge, och testas av medlemmar i samhÀllet.
Hur en virtuell nÀtverk Àr uppbyggd inifrÄn
Hur interagerar en anvÀndare med det virtuella nÀtverket? NÀtverket ser utÄt genom sitt API. AnvÀndaren gÄr in i API:t och arbetar med det önskade tillstÄndet. Genom API:t ser anvÀndaren hur allt ska vara uppstÀllt och konfigurerat och ser status över hur mycket det aktuella tillstÄndet avviker frÄn det önskade. Det Àr anvÀndarens bild. Men vad hÀnder inuti?
Vi registrerar det önskade tillstĂ„ndet i Yandex Database och fortsĂ€tter med att konfigurera olika delar av vĂ„r VPC. Ăverlagret i Yandex.Cloud Ă€r byggt pĂ„ utvalda komponenter frĂ„n OpenContrail, som nyligen har blivit kĂ€nt som Tungsten Fabric. NĂ€tverkstjĂ€nsterna implementeras pĂ„ en enhetlig plattform, CloudGate. I CloudGate har vi ocksĂ„ anvĂ€nt ett antal open source-komponenter: GoBGP för att hĂ€mta kontrollinformation, samt VPP för att implementera en programvarurouter som arbetar över DPDK för datapath.
Tungsten Fabric kommunicerar med CloudGate genom GoBGP. Den berÀttar vad som hÀnder i överlagret. CloudGate Ä sin sida kopplar ihop överlagren med varandra och med internet.
LÄt oss nu se hur det virtuella nÀtverket löser problem med skalerbarhet och tillgÀnglighet. Vi övervÀger ett enkelt fall. Det finns en tillgÀnglighetszon dÀr tvÄ VPC:er har skapats. Vi har distribuerat en instans av Tungsten Fabric, som hanterar flera tiotusentals nÀtverk. NÀtverken kopplas till CloudGate. CloudGate, som vi redan nÀmnt, sÀkerstÀller deras sammankoppling med varandra och med internet.
Anta att en andra tillgÀnglighetszon lÀggs till. Den mÄste fallera helt oberoende av den första. DÀrför mÄste en separat instans av Tungsten Fabric sÀttas upp i den andra tillgÀnglighetszonen. Det kommer att vara ett separat system som hanterar överlagret och som har lite kunskap om det första systemet. Det Àr faktiskt vÄr VPC API som skapar en uppfattning om att vÄrt virtuella nÀtverk Àr globalt. Det Àr dess uppgift.
VPC1 projiceras i tillgÀnglighetszon B, om det finns resurser i tillgÀnglighetszon B som kopplas till VPC1. Om det inte finns nÄgra resurser frÄn VPC2 i tillgÀnglighetszon B, kommer vi inte att materialisera VPC2 i denna zon. à sin sida, eftersom resurser frÄn VPC3 endast finns i zon B, finns VPC3 inte i zon A. Allt Àr enkelt och logiskt.
LÄt oss gÄ lite djupare och se hur en specifik vÀrd fungerar i Y.Cloud. Det viktigaste att notera Àr att alla vÀrdar Àr uppbyggda pÄ samma sÀtt. Vi ser till att endast det minimum av tjÀnster körs pÄ hÄrdvaran, medan alla övriga körs pÄ virtuella maskiner. Vi bygger högre ordningstjÀnster baserade pÄ grundlÀggande infrastrukturtjÀnster och anvÀnder ocksÄ molnet för att lösa vissa ingenjörsuppgifter, till exempel inom ramen för Continuous Integration.
Om vi ser pÄ en specifik vÀrd kommer vi att se att tre komponenter körs i vÀrdens OS:
- Compute â delen som ansvarar för fördelningen av datorkapacitet pĂ„ vĂ€rden.
- VRouter â en del av Tungsten Fabric som organiserar överlagret, det vill sĂ€ga tunnelar paket genom underlaget (underlay).
- VDisk â detta Ă€r delar av virtuallagring.
Utöver detta körs virtuella maskiner tjÀnster: infrastrukturtjÀnster frÄn molnet, plattformstjÀnster och kundernas kapacitet. Kundernas kapacitet och plattformstjÀnster gÄr alltid via överlagret genom VRouter.
InfrastrukturtjÀnster kan kopplas in i överlagret, men vill i huvudsak arbeta i underlaget. I underlaget kopplas de in med hjÀlp av SR-IOV. Faktiskt skÀr vi kortet i virtuella nÀtverkskort (virtuella funktioner) och stoppar dem i infrastrukturella virtuella maskiner för att inte tappa prestanda. Till exempel Àr den sÄ kallade CloudGate igÄng som en av dessa infrastrukturella virtuella maskiner.
Nu nÀr vi har beskrivit de globala uppgifterna för det virtuella nÀtverket och konstruktionen av de grundlÀggande komponenterna i molnet, lÄt oss se hur olika delar av det virtuella nÀtverket interagerar med varandra.
Vi identifierar tre lager i vÄrt system:
- Config Plane â anger det önskade tillstĂ„ndet för systemet. Det Ă€r vad anvĂ€ndaren konfigurerar via API.
- Control Plane â sĂ€kerstĂ€ller den av anvĂ€ndaren angivna semantiken, det vill sĂ€ga fĂ„r Data Plane att uppnĂ„ det tillstĂ„nd som beskrevs av anvĂ€ndaren i Config Plane.
- Data Plane â hanterar direkt anvĂ€ndarens paket.
Som jag nÀmnde ovan börjar allt med att anvÀndaren eller en intern plattformstjÀnst kommer till API och beskriver ett visst önskat tillstÄnd.
Detta tillstÄnd registreras omedelbart i Yandex Database, returnerar via API ID för den asynkrona operationen och startar vÄr interna maskin för att ge det tillstÄnd som anvÀndaren önskade. Konfigurationsuppgifter gÄr till SDN-kontrollern och berÀttar för Tungsten Fabric vad som behöver göras i överlaget. Till exempel reserverar de portar, virtuella nÀtverk och liknande.
Config Plane i Tungsten Fabric levererar det önskade tillstÄndet till Control Plane. Genom det kommunicerar Config Plane med vÀrdarna och informerar om vad som snart kommer att köras pÄ dem.
Nu ska vi se hur systemet ser ut pÄ vÀrdarna. I en virtuell maskin finns en nÀtverksadapter som Àr instoppad i VRouter. VRouter Àr en kÀrnmodul i Tungsten Fabric som övervakar paketen. Om det redan finns en flow för ett visst paket, behandlar modulen det. Om det inte finns nÄgon flow, utför modulen sÄ kallad punting, det vill sÀga skickar paketet till anvÀndarmodes-processen. Processen analyserar paketet och antingen svarar pÄ det sjÀlv, som till exempel pÄ DHCP och DNS, eller talar om för VRouter vad som ska göras med det. Efter det kan VRouter behandla paketet.
DÀrefter passerar trafiken mellan virtuella maskiner inom samma virtuella nÀtverk transparent, den dirigeras inte till CloudGate. VÀrdarna dÀr de virtuella maskinerna Àr distribuerade kommunicerar direkt med varandra. De tunnelar trafik och skickar den till varandra genom underlaget.
Control Plane kommunicerar med varandra mellan tillgÀnglighetszoner via BGP, som med en annan router. De informerar om vilka maskiner som Àr uppe och var, sÄ att virtuella maskiner i en zon kan interagera direkt med andra virtuella maskiner.
Dessutom kommunicerar Control Plane med CloudGate. PÄ liknande sÀtt meddelar den var och vilka virtuella maskiner som Àr uppe, samt deras adresser. Detta möjliggör att extern trafik och trafik frÄn lastbalanserare kan dirigeras till dem.
Trafiken som gÄr ut frÄn VPC kommer till CloudGate, i data path, dÀr den snabbt bearbetas av VPP med vÄra plugins. DÀrefter skickas trafiken antingen till andra VPC:er eller ut, till grÀnsrouters som konfigureras via Control Plane för CloudGate.
Planer för den nÀrmaste framtiden
Om man sammanfattar allt som har sagts ovan i nÄgra meningar kan man sÀga att VPC i Yandex.Cloud löser tvÄ viktiga uppgifter:
- Den sÀkerstÀller isolering mellan olika kunder.
- Samlar resurser, infrastruktur, plattforms-tjÀnster, andra moln och on-premise i ett enda nÀtverk.
För att lösa dessa uppgifter effektivt behöver man sÀkerstÀlla skalbarhet och felbenÀgenhet pÄ nivÄ med den interna arkitekturen, vilket VPC gör.
Gradvis fÄr VPC fler funktioner, vi implementerar nya möjligheter och strÀvar efter att förbÀttra anvÀndarvÀnligheten. Vissa idéer nÀmns och kommer in pÄ prioritetslistan tack vare deltagare i vÄrt samhÀlle.
Just nu har vi ungefÀr följande lista med planer för den nÀrmaste framtiden:
- VPN som en tjÀnst.
- Private DNS-instans - avbilder för snabb konfiguration av virtuella maskiner med förkonfigurerad DNS-server.
- DNS som en tjÀnst.
- Intern belastningsbalanserare.
- LĂ€gg till en "vit" IP-adress utan att Ă„terskapa den virtuella maskinen.
Belastningsbalanserare och möjligheten att vÀxla IP-adressen för en redan skapad virtuell maskin har tagits med pÄ denna lista pÄ begÀran av anvÀndare. Jag ska vara Àrlig, utan tydlig feedback skulle vi ha tagit oss an dessa funktioner nÄgot senare. Men nu arbetar vi redan med uppgiften kring adresser.
Initialt kunde en "vit" IP-adress endast lÀggas till vid skapandet av maskinen. Om anvÀndaren glömde att göra detta, var man tvungen att Äterskapa den virtuella maskinen. Samma sak gÀllde för att ta bort den externa IP-adressen. Snart kommer man att kunna slÄ pÄ och av den offentliga IP-adressen utan att Äterskapa maskinen.
Tveka inte att uttrycka dina idéer och stödja förslag frÄn andra anvÀndare. Du hjÀlper oss att göra molnet bÀttre och snabbare fÄ viktiga och anvÀndbara funktioner!
KĂ€lla: habr.com
