Hej, jeg hedder Kostya Kramlix, jeg er hovedudvikler i Virtual Private Cloud-afdelingen i Yandex.Cloud. Jeg arbejder med det virtuelle netværk, og som du nok kan gætte, vil jeg i denne artikel fortælle om strukturen af Virtual Private Cloud (VPC) generelt og det virtuelle netværk specifikt. Desuden vil du finde ud af, hvorfor vi, udviklerne af tjenesten, værdsætter feedback fra vores brugere. Men lad os tage det hele i rækkefølge.
Hvad er VPC?
I dag er der mange forskellige muligheder for at implementere tjenester. Jeg er sikker på, at nogen stadig har en server stående under administratorens skrivebord, selvom jeg håber, at sådanne historier bliver færre.
Nu til dags forsøger tjenesterne at bevæge sig over i offentlige skyer, og her støder de netop på VPC. VPC er en del af den offentlige sky, der forbinder brugerens, infrastrukturens, platformens og andre ressourcers styrke, uanset hvor de befinder sig, i vores sky eller udenfor. Samtidig tillader VPC ikke unødvendigt at eksponere disse ressourcer på internettet; de forbliver inden for dit isolerede netværk.
Hvordan det virtuelle netværk ser ud udefra
Under VPC forstår vi først og fremmest et overlay-netværk og netværkstjenester som VPNaaS, NATaas, LBaas osv. Og alt dette fungerer oven på en fejltolerant netværksinfrastruktur, som allerede er blevet beskrevet i en fremragende artikel her på Habr.
Lad os tage et nærmere kig på det virtuelle netværk og dets struktur.
Lad os se på to tilgængelighedszoner. Vi tilbyder et virtuelt netværk – det, vi kalder VPC. Faktisk definerer det rummet for unikke "grå" adresser. Inden for hvert virtuelt netværk kontrollerer du helt rummet for adresser, som du kan tildele til beregningsressourcer.
Nettet er globalt. Det projiceres på hver tilgængelig zone som en enhed kaldet Subnet. For hver Subnet tildeler du en CIDR på størrelse 16 eller mindre. Der kan være mere end én sådan enhed i hver tilgængelig zone, og der er altid gennemsigtig routing mellem dem. Det betyder, at alle dine ressourcer inden for én VPC kan "kommunikere" med hinanden, selvom de befinder sig i forskellige tilgængelige zoner. "Kommunikere" uden at gå på internettet, via vores interne kanaler, "tænker", at de befinder sig inden for et privat netværk.
Diagrammet ovenfor viser en typisk situation: to VPC'er, der et sted krydser adresser. Begge kan tilhøre dig. For eksempel én til udvikling, en anden til test. Det kan simpelthen være forskellige brugere – i dette tilfælde er det ikke vigtigt. Og i hver VPC er der tilsluttet en virtuel maskine.
Lad os komplicere diagrammet. Man kan gøre det muligt, at én virtuel maskine kan tilsluttes flere Subnets på én gang. Og ikke bare sådan, men i forskellige virtuelle netværk.
Hvis du har brug for at eksponere maskinerne til internettet, kan dette gøres via API eller UI. For dette skal du konfigurere NAT-oversættelse af din "grå", interne adresse til "hvid" – offentlig. Du kan ikke vælge den "hvite" adresse, den tildeles tilfældigt fra vores adressepulje. Så snart du stopper med at bruge den eksterne IP, returneres den til puljen. Du betaler kun for den tid, du bruger den "hvide" adresse.
Der er også mulighed for at give en maskine adgang til internettet via en NAT-instans. Trafikken kan rutes gennem en statisk routingtabel. Vi har forudset et sådant tilfælde, fordi det kan være nødvendigt for brugerne, og vi ved det. Derfor ligger der en specielt konfigureret NAT-image i vores billedkatalog.
Men selv når der er en klar NAT-image, kan opsætningen være kompliceret. Vi forstod, at dette ikke var den mest bekvemme løsning for nogle brugere, så vi har i sidste ende lavet en mulighed for at aktivere NAT for den ønskede Subnet med et enkelt klik. Denne funktion er stadig i lukket preview-adgang, hvor den testes med hjælp fra samfundets medlemmer.
Hvordan et virtuelt netværk er opbygget indenfra.
Hvordan interagerer brugeren med det virtuelle netværk? Nettet ser udad med sin API. Brugeren kommer til API'en og arbejder med den ønskede tilstand. Gennem API'en ser brugeren, hvordan alt skal være organiseret og konfigureret, samtidig med at han ser status for, hvor langt den faktiske tilstand adskiller sig fra den ønskede. Dette er brugerens billede. Men hvad sker der indeni?
Vi gemmer den ønskede tilstand i Yandex Database og går i gang med at konfigurere forskellige dele af vores VPC. Overlay-netværket i Yandex.Cloud er bygget på udvalgte komponenter fra OpenContrail, som for nylig er blevet kendt som Tungsten Fabric. Netværkstjenesterne er implementeret på en ensartet CloudGate-platform. I CloudGate har vi også anvendt nogle open source-komponenter: GoBGP til at hente kontrolinformation og VPP til at implementing en software-router, der kører over DPDK for data path.
Tungsten Fabric kommunikerer med CloudGate via GoBGP. Det rapporterer, hvad der sker i overlay-netværket. CloudGate forbinder på sin side overlay-netværkene med hinanden og med internettet.
Lad os nu se på, hvordan det virtuelle netværk løser skalerings- og tilgængelighedsopgaver. Lad os overveje et enkelt tilfælde. Der er en tilgængelighedszone, og der er oprettet to VPC'er i den. Vi har rullet et Tungsten Fabric-instans ud, og det understøtter flere tusinde netværk. Netværkene forbindes med CloudGate. CloudGate sikrer, som vi allerede har nævnt, forbindelse mellem dem og med internettet.
Lad os sige, at der tilføjes en anden tilgængelighedszone. Den skal være helt uafhængig af den første. Derfor skal vi i den anden tilgængelighedszone installere et separat Tungsten Fabric-instans. Dette vil være et separat system, der håndterer overlayet og ikke ved meget om det første system. Og synligheden af, at vores virtuelle netværk er globalt, skabes faktisk af vores VPC API. Det er dens opgave.
VPC1 projiceres ind i tilgængelighedszonen B, hvis der er ressourcer i tilgængelighedszonen B, som er tilsluttet VPC1. Hvis der ikke er nogen ressourcer fra VPC2 i tilgængelighedszonen B, materieliserer vi ikke VPC2 i denne zone. På den anden side, da ressourcerne fra VPC3 kun eksisterer i zone B, findes VPC3 ikke i zone A. Det er simpelt og logisk.
Lad os gå lidt dybere og se på, hvordan en specifik vært er opbygget i Я.Облаке. Det vigtigste, jeg gerne vil fremhæve, er, at alle værter er opbygget ens. Vi sørger for, at kun det nødvendige minimum af tjenester kører på "hardwaren", mens alle andre kører på virtuelle maskiner. Vi bygger tjenester af højere orden baseret på grundlæggende infrastrukturtjenester samt bruger Cloud til at løse nogle ingeniøropgaver, f.eks. inden for Continuous Integration.
Hvis vi ser på en specifik vært, vil vi se, at der kører tre komponenter i værtens OS:
- Compute – den del, der er ansvarlig for at fordele beregningsressourcer på værten.
- VRouter – en del af Tungsten Fabric, som organiserer overlay, dvs. tunnelerer pakker gennem underlay.
- VDisk – disse er stykker af virtualisering af lager.
Derudover er der virtuelle maskiner tjenester kørende: infrastrukturtjenester fra Cloud, platformtjenester og kundernes kapaciteter. Kundernes kapaciteter og platformtjenester går altid i overlay gennem VRouter.
Infrastrukturtjenester kan tilsluttes overlay, men ønsker som regel at arbejde i underlay. I underlay tilsluttes de via SR-IOV. Faktisk skærer vi kortet op i virtuelle netværkskort (virtuelle funktioner) og indsætter dem i infrastrukturelle virtuelle maskiner for ikke at miste ydeevne. For eksempel er den samme CloudGate kørt som en af disse infrastrukturelle virtuelle maskiner.
Nu, hvor vi har beskrevet de globale opgaver for det virtuelle netværk og strukturen af de grundlæggende komponenter i skyen, lad os se på, hvordan de forskellige dele af det virtuelle netværk interagerer med hinanden.
Vi fremhæver tre lag i vores system:
- Config Plane – angiver systemets måltilstand. Det er det, brugeren konfigurerer via API.
- Control Plane – sikrer, at det, brugeren har angivet, er realiseret, altså bringer Data Plane til den tilstand, der er beskrevet af brugeren i Config Plane.
- Data Plane – behandler direkte brugerens pakker.
Som jeg nævnte tidligere, begynder det hele med, at brugeren eller en intern platformtjeneste kommer til API'et og beskriver en specifik måltilstand.
Denne tilstand registreres straks i Yandex Database, returnerer gennem API ID'et for den asynkrone operation og starter vores interne maskiner til at levere den ønskede tilstand til brugeren. Konfigurationstasks sendes til SDN-controlleren og informerer Tungsten Fabric om, hvad der skal gøres i overlayet. For eksempel reserverer de porte, virtuelle netværk og lignende.
Config Plane i Tungsten Fabric leverer den nødvendige tilstand til Control Plane. Gennem det kommunikerer Config Plane også med værterne og fortæller, hvad der snart vil køre på dem.
Lad os nu se, hvordan systemet ser ud på værterne. I virtuelle maskiner er der en netværksadapter tilsluttet VRouter. VRouter er den centrale modul i Tungsten Fabric, der ser på pakkerne. Hvis der allerede er et flow for en given pakke, behandler modulet den. Hvis der ikke er noget flow, laver modulet det, der kaldes punting, hvilket betyder, at det sender pakken til user-mode-processen. Processen analyserer pakken og svarer enten selv på den, som i tilfælde af DHCP og DNS, eller instruerer VRouter om, hvad der skal gøres med den. Herefter kan VRouter behandle pakken.
Trafikken mellem virtuelle maskiner inden for et virtuelt netværk går gennemsigtigt, den dirigeres ikke til CloudGate. Værterne, hvor de virtuelle maskiner er implementeret, kommunikerer direkte med hinanden. De tunnelere trafikken og sender den videre til hinanden gennem overlayet.
Control Plane kommunikerer med hinanden mellem tilgængelighedszonerne over BGP, som med en anden router. De informerer, hvilke maskiner der er oppe, så virtuelle maskiner i en zone kan interagere direkte med andre virtuelle maskiner.
Control Plane kommunikerer også med CloudGate. I lighed med dette informerer de om, hvor og hvilke virtuelle maskiner der er oppe, og hvilke adresser de har. Dette muliggør, at ekstern trafik og trafik fra belastningsbalancerere kan dirigeres til dem.
Trafikken, der forlader VPC, kommer til CloudGate, i data path, hvor den hurtigt behandles af VPP med vores plugins. Herefter sendes trafikken enten til andre VPC'er eller udadtil til grænserouternes, som konfigureres gennem Control Plane i CloudGate.
Planer for den nærmeste fremtid
Hvis man opsummerer alt det ovenstående i nogle få sætninger, kan man sige, at VPC i Yandex.Cloud løser to vigtige opgaver:
- Sikrer isolation mellem forskellige kunder.
- Sammensætter ressourcer, infrastruktur, platformtjenester, andre skyer og on-premise i et samlet netværk.
For at løse disse opgaver godt, er det nødvendigt at sikre skalerbarhed og fejltolerance på niveau med den interne arkitektur, hvilket VPC gør.
Efterhånden som VPC udvikler sig, tilføjer vi nye funktioner, stræber efter at forbedre brugervenligheden. Nogle idéer bliver fremhævet og kommer på prioritetslisten takket være medlemmerne af vores fællesskab.
Vi har i øjeblikket cirka denne liste over planer for den nærmeste fremtid:
- VPN som en tjeneste.
- Private DNS-instanser – billeder til hurtig opsætning af virtuelle maskiner med en forudkonfigureret DNS-server.
- DNS som en tjeneste.
- Intern belastningsbalancer.
- Tilføjelse af en „hvid“ IP-adresse uden at skulle genskabe den virtuelle maskine.
Belastningsbalancer og muligheden for at skifte IP-adresse for en allerede oprettet virtuel maskine var blevet efterspurgt af brugerne. Jeg må være ærlig: uden tydelig feedback ville vi tage fat på disse funktioner lidt senere. Men nu arbejder vi allerede på opgaven med adresser.
Oprindeligt kunne den „hvide“ IP-adresse kun tilføjes ved oprettelsen af maskinen. Hvis brugeren glemte at gøre dette, måtte den virtuelle maskine genskabes. Det samme gjaldt for behovet for at fjerne den eksterne IP. Snart vil det være muligt at aktivere og deaktivere den offentlige IP uden at genskabe maskinen.
Tøv ikke med at give dine idéer og støtte forslagene fra andre brugere. Du hjælper os med at gøre Cloud bedre og hurtigere få vigtige og nyttige funktioner!
Kilde: habr.com
