Hej, mit navn er Kostya Kramlikh, jeg er den ledende udvikler af Virtual Private Cloud-divisionen i Yandex.Cloud. Jeg er en virtuel netværker, og som du måske kan gætte, vil jeg i denne artikel tale om Virtual Private Cloud (VPC)-enheden generelt og det virtuelle netværk i særdeleshed. Og du vil også finde ud af, hvorfor vi, udviklerne af tjenesten, værdsætter feedback fra vores brugere. Men først ting først.
Hvad er VPC?
I dag er der en række muligheder for at implementere tjenester. Jeg er sikker på, at nogen stadig holder serveren under administratorens skrivebord, selvom jeg håber, der er færre sådanne historier.
Nu forsøger tjenester at gå til offentlige skyer, og det er her, de kolliderer med VPC'er. VPC er en del af en offentlig sky, der binder bruger, infrastruktur, platform og andre kapaciteter sammen, uanset hvor de er, i vores Cloud eller udenfor den. Samtidig giver VPC dig mulighed for ikke at udsætte disse kapaciteter for internettet unødigt, de forbliver inden for dit isolerede netværk.
Hvordan ser et virtuelt netværk ud udefra?
Med VPC mener vi primært et overlejringsnetværk og netværkstjenester, såsom VPNaaS, NATaas, LBaas osv. Og alt dette fungerer oven på en fejltolerant netværksinfrastruktur, som allerede er blevet her på Habré.
Lad os se nærmere på det virtuelle netværk og dets enhed.
Overvej to tilgængelighedszoner. Vi leverer et virtuelt netværk - det vi kaldte VPC. Faktisk definerer det det unikke rum for dine "grå" adresser. Inden for hvert virtuelt netværk har du fuld kontrol over det rum af adresser, du kan tildele til computerressourcer.
Netværket er globalt. Samtidig projiceres den på hver af tilgængelighedszonerne i form af en enhed kaldet Subnet. For hvert undernet tildeler du et CIDR på størrelse 16 eller mindre. Der kan være mere end én sådan enhed i hver tilgængelighedszone, og der er altid gennemsigtig routing mellem dem. Det betyder, at alle dine ressourcer inden for den samme VPC kan "tale" med hinanden, selvom de er i forskellige tilgængelighedszoner. "Kommunikere" uden adgang til internettet, gennem vores interne kanaler, og "tror", at de er inden for det samme private netværk.
Diagrammet ovenfor viser en typisk situation: to VPC'er, der krydser hinanden et sted i adresser. Begge kan blive dine. For eksempel den ene til udvikling, den anden til test. Der kan simpelthen være forskellige brugere – i dette tilfælde er det lige meget. Og en virtuel maskine er tilsluttet hver VPC.
Lad os gøre ordningen værre. Du kan gøre det, så en virtuel maskine sidder fast i flere undernet på én gang. Og ikke bare sådan, men i forskellige virtuelle netværk.
Hvis du samtidig skal eksponere maskiner til internettet, kan dette gøres gennem API'en eller UI. For at gøre dette skal du konfigurere NAT-oversættelse af din "grå", interne adresse til "hvid" - offentlig. Du kan ikke vælge en "hvid" adresse, den tildeles tilfældigt fra vores pulje af adresser. Så snart du holder op med at bruge den eksterne IP, returneres den til poolen. Du betaler kun for tidspunktet for brug af den "hvide" adresse.
Det er også muligt at give maskinen adgang til internettet ved hjælp af en NAT-instans. Du kan dirigere trafik til en instans gennem en statisk routingtabel. Vi har leveret sådan en sag, fordi brugerne nogle gange har brug for den, og vi kender til den. Derfor indeholder vores billedkatalog et specielt konfigureret NAT-billede.
Men selv når der er et klar NAT-billede, kan opsætningen være vanskelig. Vi forstod, at for nogle brugere er dette ikke den mest bekvemme mulighed, så i sidste ende gjorde vi det muligt at aktivere NAT for det ønskede undernet med et enkelt klik. Denne funktion er stadig i lukket forhåndsvisningsadgang, hvor den testes med hjælp fra fællesskabsmedlemmer.
Hvordan det virtuelle netværk er indrettet indefra
Hvordan interagerer brugeren med det virtuelle netværk? Nettet ser udad med sin API. Brugeren kommer til API'et og arbejder med måltilstanden. Gennem API'et ser brugeren, hvordan alt skal arrangeres og konfigureres, mens han ser status, hvor meget den faktiske tilstand afviger fra den ønskede. Dette er et billede af brugeren. Hvad sker der indeni?
Vi skriver den ønskede tilstand til Yandex-databasen og går til at konfigurere forskellige dele af vores VPC. Overlay-netværket i Yandex.Cloud er baseret på udvalgte komponenter i OpenContrail, som for nylig er blevet kaldt Tungsten Fabric. Netværkstjenester implementeres på en enkelt CloudGate-platform. I CloudGate brugte vi også en række open source-komponenter: GoBGP - til at få adgang til kontrolinformation, samt VPP - til at implementere en software-router, der kører ovenpå DPDK til datastien.
Tungsten Fabric kommunikerer med CloudGate via GoBGP. Fortæller, hvad der foregår i overlejringsnetværket. CloudGate forbinder til gengæld overlay-netværk med hinanden og med internettet.
Lad os nu se, hvordan et virtuelt netværk løser problemerne med skalering og tilgængelighed. Lad os overveje en simpel sag. Der er en tilgængelighedszone, og der oprettes to VPC'er i den. Vi implementerede én Tungsten Fabric-instans, og den trækker flere titusindvis af netværk. Netværk kommunikerer med CloudGate. CloudGate, som vi allerede har sagt, sikrer deres forbindelse med hinanden og med internettet.
Lad os sige, at der tilføjes en anden tilgængelighedszone. Det skulle fejle helt uafhængigt af det første. Derfor skal vi i den anden tilgængelighedszone installere en separat Tungsten Fabric-instans. Dette vil være et separat system, der håndterer overlejringen og ved lidt om det første system. Og synligheden af, at vores virtuelle netværk er globalt, skaber faktisk vores VPC API. Dette er hans opgave.
VPC1 tilknyttes tilgængelighedszone B, hvis der er ressourcer i tilgængelighedszone B, som er skubbet til VPC1. Hvis der ikke er ressourcer fra VPC2 i tilgængelighedszone B, vil vi ikke realisere VPC2 i denne zone. Til gengæld, da ressourcer fra VPC3 kun findes i zone B, eksisterer VPC3 ikke i zone A. Alt er enkelt og logisk.
Lad os gå lidt dybere og se, hvordan en bestemt vært i Y.Cloud fungerer. Det vigtigste, jeg vil bemærke, er, at alle værter er arrangeret på samme måde. Vi gør det sådan, at kun det nødvendige minimum af tjenester kører på hardware, resten kører på virtuelle maskiner. Vi bygger tjenester af højere orden baseret på basale infrastrukturtjenester, og bruger også Clouden til at løse nogle tekniske problemer, for eksempel inden for rammerne af Kontinuerlig Integration.
Hvis vi ser på en bestemt vært, kan vi se, at der er tre komponenter, der kører på værtens OS:
- Compute - den del, der er ansvarlig for distributionen af computerressourcer på værten.
- VRouter er en del af Tungsten Fabric, der organiserer et overlay, det vil sige, det tunnelerer pakker gennem et underlag.
- VDisks er bidder af storage-virtualisering.
Derudover lanceres tjenester i virtuelle maskiner: Cloud-infrastrukturtjenester, platformtjenester og kundekapacitet. Kundekapacitet og platformtjenester går altid til overlejringen gennem VRouter.
Infrastrukturtjenester kan holde sig ind i overlayet, men grundlæggende vil de arbejde i underlaget. De stikkes ind i underlaget ved hjælp af SR-IOV. Faktisk skærer vi kortet i virtuelle netværkskort (virtuelle funktioner) og skubber dem ind i virtuelle infrastrukturmaskiner for ikke at miste ydeevnen. For eksempel lanceres den samme CloudGate som en af disse virtuelle infrastrukturmaskiner.
Nu hvor vi har beskrevet de globale opgaver i det virtuelle netværk og strukturen af de grundlæggende komponenter i skyen, lad os se, hvordan præcis de forskellige dele af det virtuelle netværk interagerer med hinanden.
Vi skelner mellem tre lag i vores system:
- Config Plane - indstiller systemets måltilstand. Dette er hvad brugeren konfigurerer via API'et.
- Kontrolplan - giver brugerdefineret semantik, det vil sige bringer dataplantilstanden til det, der blev beskrevet af brugeren i Config Plane.
- Dataplan - behandler brugerens pakker direkte.
Som jeg sagde ovenfor, starter det hele med, at brugeren eller den interne platformstjeneste kommer til API'en og beskriver en bestemt måltilstand.
Denne tilstand skrives straks til Yandex-databasen, returnerer det asynkrone operations-id via API'et og starter vores interne maskineri for at returnere den tilstand, som brugeren ønskede. Konfigurationsopgaver går til SDN-controlleren og fortæller Tungsten Fabric, hvad der skal gøres i overlayet. For eksempel reserverer de porte, virtuelle netværk og lignende.
Config Plane i Tungsten Fabric sender den påkrævede tilstand til kontrolplanet. Gennem det kommunikerer Config Plane med værterne og fortæller, hvad der præcist vil snurre på dem snart.
Lad os nu se, hvordan systemet ser ud på værterne. Den virtuelle maskine har en netværksadapter tilsluttet VRouter. VRouter er et kernemodul i Tungsten Fabric, der ser på pakker. Hvis der allerede er et flow for en pakke, behandler modulet det. Hvis der ikke er noget flow, udfører modulet den såkaldte punting, det vil sige, at det sender en pakke til usermod-processen. Processen analyserer pakken og reagerer enten på den selv, som DHCP og DNS, eller fortæller VRouter, hvad den skal gøre med den. Derefter kan VRouter behandle pakken.
Yderligere går trafik mellem virtuelle maskiner inden for det samme virtuelle netværk gennemsigtigt, det er ikke dirigeret til CloudGate. De værter, som de virtuelle maskiner er installeret på, kommunikerer direkte med hinanden. De tunnelerer trafikken og sender den videre for hinanden gennem underlaget.
Kontrolplaner kommunikerer med hinanden mellem tilgængelighedszoner via BGP, som med en anden router. De fortæller, hvilke maskiner der er oppe hvor, så VM'er i én zone kan kommunikere direkte med andre VM'er.
Og Control Plane kommunikerer med CloudGate. På samme måde rapporterer den, hvor og hvilke virtuelle maskiner der er rejst, hvilke adresser de har. Dette giver dig mulighed for at dirigere ekstern trafik og trafik fra balancere til dem.
Trafikken, der forlader VPC'en, kommer til CloudGate, til datastien, hvor VPP'en med vores plugins hurtigt tygges op. Derefter sendes trafikken enten til andre VPC'er eller udenfor, til grænseroutere, der er konfigureret gennem selve CloudGates kontrolplan.
Planer for den nærmeste fremtid
Hvis vi opsummerer alt, der er sagt ovenfor i et par sætninger, kan vi sige, at VPC i Yandex.Cloud løser to vigtige opgaver:
- Giver isolation mellem forskellige klienter.
- Kombinerer ressourcer, infrastruktur, platformtjenester, andre skyer og on-premise i et enkelt netværk.
Og for at løse disse problemer godt, skal du sørge for skalerbarhed og fejltolerance på niveau med den interne arkitektur, hvilket VPC gør.
Gradvist erhverver VPC funktioner, vi implementerer nye funktioner, vi forsøger at forbedre noget med hensyn til brugervenlighed. Nogle ideer kommer til udtryk og kommer på prioriteringslisten takket være medlemmerne af vores fællesskab.
Vi har i øjeblikket følgende liste over planer for den nærmeste fremtid:
- VPN som en tjeneste.
- Private DNS-instanser er billeder til hurtig opsætning af virtuelle maskiner med en forudkonfigureret DNS-server.
- DNS som en tjeneste.
- Intern load balancer.
- Tilføjelse af en "hvid" IP-adresse uden at genskabe den virtuelle maskine.
Balanceren og muligheden for at skifte IP-adressen for en allerede oprettet virtuel maskine var på denne liste efter anmodning fra brugere. For at være ærlig, uden eksplicit feedback, ville vi have påtaget os disse funktioner lidt senere. Og så arbejder vi allerede på problemet omkring adresser.
I starten kunne en "hvid" IP-adresse kun tilføjes ved oprettelse af en maskine. Hvis brugeren glemte at gøre dette, skulle den virtuelle maskine genskabes. Det samme og fjern om nødvendigt den eksterne IP. Det vil snart være muligt at slå den offentlige IP til og fra uden at skulle genskabe maskinen.
Giv gerne udtryk for din andre brugere. Du hjælper os med at gøre skyen bedre og få vigtige og nyttige funktioner hurtigere!
Kilde: www.habr.com