Hei, jeg heter Kostya Kramlikh, jeg er hovedutvikleren av Virtual Private Cloud-divisjonen i Yandex.Cloud. Jeg er en virtuell nettverker, og som du kanskje gjetter, i denne artikkelen vil jeg snakke om Virtual Private Cloud (VPC)-enheten generelt og det virtuelle nettverket spesielt. Og du vil også finne ut hvorfor vi, utviklerne av tjenesten, verdsetter tilbakemeldinger fra brukerne våre. Men først ting først.
Hva er VPC?
I dag finnes det en rekke alternativer for distribusjon av tjenester. Jeg er sikker på at noen fortsatt holder serveren under administratorens skrivebord, selv om jeg håper det er færre slike historier.
Nå prøver tjenester å gå til offentlige skyer, og det er her de kolliderer med VPC-er. VPC er en del av en offentlig sky som binder bruker, infrastruktur, plattform og andre kapasiteter sammen, uansett hvor de er, i vår sky eller utenfor den. Samtidig lar VPC deg ikke eksponere disse kapasitetene for Internett unødvendig, de forblir innenfor ditt isolerte nettverk.
Hvordan ser et virtuelt nettverk ut fra utsiden?
Med VPC mener vi først og fremst et overleggsnettverk og nettverkstjenester, som VPNaaS, NATaas, LBaas osv. Og alt dette fungerer på toppen av en feiltolerant nettverksinfrastruktur, som allerede er her, på Habré.
La oss se nærmere på det virtuelle nettverket og enheten.
Vurder to tilgjengelighetssoner. Vi tilbyr et virtuelt nettverk - det vi kalte VPC. Faktisk definerer det det unike rommet til dine "grå" adresser. Innenfor hvert virtuelle nettverk har du full kontroll over plassen med adresser du kan tilordne dataressurser.
Nettverket er globalt. Samtidig projiseres den på hver av tilgjengelighetssonene i form av en enhet kalt Subnet. For hvert undernett tilordner du en CIDR på størrelse 16 eller mindre. Det kan være mer enn én slik enhet i hver tilgjengelighetssone, og det er alltid gjennomsiktig ruting mellom dem. Dette betyr at alle ressursene dine innenfor samme VPC kan "snakke" med hverandre, selv om de er i forskjellige tilgjengelighetssoner. "Kommuniser" uten tilgang til Internett, gjennom våre interne kanaler, "tenker" at de er innenfor samme private nettverk.
Diagrammet ovenfor viser en typisk situasjon: to VPC-er som krysser hverandre et sted i adressene. Begge kan bli dine. For eksempel en for utvikling, den andre for testing. Det kan rett og slett være forskjellige brukere - i dette tilfellet spiller det ingen rolle. Og én virtuell maskin er koblet til hver VPC.
La oss gjøre opplegget verre. Du kan gjøre det slik at én virtuell maskin sitter fast i flere undernett samtidig. Og ikke bare sånn, men i forskjellige virtuelle nettverk.
Samtidig, hvis du trenger å eksponere maskiner for Internett, kan dette gjøres gjennom API eller UI. For å gjøre dette må du konfigurere NAT-oversettelse av din "grå", interne adresse, til "hvit" - offentlig. Du kan ikke velge en "hvit" adresse, den tildeles tilfeldig fra vår pool av adresser. Så snart du slutter å bruke den eksterne IP-en, returneres den til bassenget. Du betaler kun for tidspunktet du bruker den "hvite" adressen.
Det er også mulig å gi maskinen tilgang til Internett ved hjelp av en NAT-instans. Du kan rute trafikk til en forekomst gjennom en statisk rutingtabell. Vi har levert en slik sak, fordi brukere noen ganger trenger det, og vi vet om det. Følgelig inneholder bildekatalogen vår et spesielt konfigurert NAT-bilde.
Men selv når det er et klart NAT-bilde, kan oppsettet være vanskelig. Vi forsto at for noen brukere er dette ikke det mest praktiske alternativet, så til slutt gjorde vi det mulig å aktivere NAT for ønsket undernett med ett klikk. Denne funksjonen er fortsatt i lukket forhåndsvisningstilgang, hvor den er testet ved hjelp av fellesskapsmedlemmer.
Hvordan det virtuelle nettverket er ordnet fra innsiden
Hvordan samhandler brukeren med det virtuelle nettverket? Nettet ser utover med sitt API. Brukeren kommer til API og jobber med måltilstanden. Gjennom API ser brukeren hvordan alt skal ordnes og konfigureres, mens han ser status, hvor mye den faktiske tilstanden avviker fra ønsket. Dette er et bilde av brukeren. Hva skjer inni?
Vi skriver ønsket tilstand til Yandex-databasen og går til å konfigurere forskjellige deler av vår VPC. Overleggsnettverket i Yandex.Cloud er basert på utvalgte komponenter av OpenContrail, som nylig har blitt kalt Tungsten Fabric. Nettverkstjenester implementeres på én enkelt CloudGate-plattform. I CloudGate brukte vi også en rekke åpen kildekode-komponenter: GoBGP - for å få tilgang til kontrollinformasjon, samt VPP - for å implementere en programvareruter som kjører på toppen av DPDK for databanen.
Tungsten Fabric kommuniserer med CloudGate via GoBGP. Forteller hva som skjer i overleggsnettverket. CloudGate kobler på sin side overleggsnettverk med hverandre og med Internett.
La oss nå se hvordan et virtuelt nettverk løser problemene med skalering og tilgjengelighet. La oss vurdere en enkel sak. Det er én tilgjengelighetssone og to VPC-er opprettes i den. Vi distribuerte én Tungsten Fabric-forekomst, og den trekker flere titusenvis av nettverk. Nettverk kommuniserer med CloudGate. CloudGate, som vi allerede har sagt, sikrer deres tilkobling med hverandre og med Internett.
La oss si at en ekstra tilgjengelighetssone er lagt til. Den skal mislykkes helt uavhengig av den første. Derfor, i den andre tilgjengelighetssonen, må vi installere en egen Tungsten Fabric-instans. Dette vil være et eget system som tar for seg overlegget og vet lite om det første systemet. Og synligheten av at vårt virtuelle nettverk er globalt, skaper faktisk vår VPC API. Dette er hans oppgave.
VPC1 er tilordnet til tilgjengelighetssone B hvis det er ressurser i tilgjengelighetssone B som er pushet til VPC1. Hvis det ikke er ressurser fra VPC2 i tilgjengelighetssone B, vil vi ikke materialisere VPC2 i denne sonen. I sin tur, siden ressurser fra VPC3 kun eksisterer i sone B, eksisterer ikke VPC3 i sone A. Alt er enkelt og logisk.
La oss gå litt dypere og se hvordan en bestemt vert i Y.Cloud fungerer. Det viktigste jeg vil merke meg er at alle verter er ordnet på samme måte. Vi gjør det slik at kun det nødvendige minimum av tjenester kjører på maskinvare, resten kjører på virtuelle maskiner. Vi bygger tjenester av høyere orden basert på grunnleggende infrastrukturtjenester, og bruker også skyen til å løse noen tekniske problemer, for eksempel innenfor rammen av kontinuerlig integrasjon.
Hvis vi ser på en spesifikk vert, kan vi se at det er tre komponenter som kjører på verts-OS:
- Compute - delen som er ansvarlig for distribusjonen av dataressurser på verten.
- VRouter er en del av Tungsten Fabric som organiserer et overlegg, det vil si at det tunnelerer pakker gjennom et underlag.
- VDisker er biter av lagringsvirtualisering.
I tillegg lanseres tjenester i virtuelle maskiner: Skyinfrastrukturtjenester, plattformtjenester og kundekapasiteter. Kundekapasitet og plattformtjenester går alltid til overlegget gjennom VRouter.
Infrastrukturtjenester kan feste seg i overlegget, men i utgangspunktet ønsker de å jobbe i underlaget. De stikkes inn i underlaget ved hjelp av SR-IOV. Faktisk kutter vi kortet i virtuelle nettverkskort (virtuelle funksjoner) og skyver dem inn i virtuelle maskiner for infrastruktur for ikke å miste ytelsen. For eksempel lanseres den samme CloudGate som en av disse virtuelle infrastrukturmaskinene.
Nå som vi har beskrevet de globale oppgavene til det virtuelle nettverket og strukturen til de grunnleggende komponentene i skyen, la oss se hvordan nøyaktig de forskjellige delene av det virtuelle nettverket samhandler med hverandre.
Vi skiller tre lag i systemet vårt:
- Config Plane - angir måltilstanden til systemet. Dette er hva brukeren konfigurerer via API.
- Kontrollplan - gir brukerdefinert semantikk, det vil si bringer dataplantilstanden til det som ble beskrevet av brukeren i Config Plane.
- Dataplan - behandler brukerens pakker direkte.
Som jeg sa ovenfor, starter det hele med at brukeren eller den interne plattformtjenesten kommer til APIen og beskriver en viss måltilstand.
Denne tilstanden skrives umiddelbart til Yandex Database, returnerer den asynkrone operasjons-IDen via API, og starter vårt interne maskineri for å returnere tilstanden som brukeren ønsket. Konfigurasjonsoppgaver går til SDN-kontrolleren og forteller Tungsten Fabric hva som skal gjøres i overlegget. For eksempel reserverer de porter, virtuelle nettverk og lignende.
Config Plane i Tungsten Fabric sender den nødvendige tilstanden til kontrollplanet. Gjennom den kommuniserer Config Plane med vertene, og forteller hva som vil snurre på dem snart.
La oss nå se hvordan systemet ser ut på vertene. Den virtuelle maskinen har en nettverksadapter koblet til VRouter. VRouter er en kjernemodul i Tungsten Fabric som ser på pakker. Hvis det allerede er en flyt for en pakke, behandler modulen den. Hvis det ikke er noen flyt, gjør modulen den såkalte punting, det vil si at den sender en pakke til usermod-prosessen. Prosessen analyserer pakken og svarer enten på den selv, som DHCP og DNS, eller forteller VRouter hva den skal gjøre med den. Etter det kan VRouter behandle pakken.
Videre går trafikken mellom virtuelle maskiner innenfor det samme virtuelle nettverket transparent, den blir ikke dirigert til CloudGate. Vertene som de virtuelle maskinene er utplassert på, kommuniserer direkte med hverandre. De tunnelerer trafikken og sender den videre for hverandre gjennom underlaget.
Kontrollfly kommuniserer med hverandre mellom tilgjengelighetssoner via BGP, som med en annen ruter. De forteller hvilke maskiner som er oppe hvor slik at VM-er i én sone kan kommunisere direkte med andre VM-er.
Og Control Plane kommuniserer med CloudGate. På samme måte rapporterer den hvor og hvilke virtuelle maskiner som er oppdratt, hvilke adresser de har. Dette lar deg dirigere ekstern trafikk og trafikk fra balansere til dem.
Trafikken som forlater VPC-en kommer til CloudGate, til databanen, hvor VPP-en med våre plugins raskt tygges opp. Deretter sendes trafikken enten til andre VPC-er eller utenfor, til grenserutere som er konfigurert gjennom kontrollplanet til selve CloudGate.
Planer for nær fremtid
Hvis vi oppsummerer alt som er sagt ovenfor i noen få setninger, kan vi si at VPC i Yandex.Cloud løser to viktige oppgaver:
- Gir isolasjon mellom ulike klienter.
- Kombinerer ressurser, infrastruktur, plattformtjenester, andre skyer og on-premise til ett enkelt nettverk.
Og for å løse disse problemene godt, må du sørge for skalerbarhet og feiltoleranse på nivå med den interne arkitekturen, noe VPC gjør.
Gradvis får VPC funksjoner, vi implementerer nye funksjoner, vi prøver å forbedre noe når det gjelder brukervennlighet. Noen ideer kommer til uttrykk og kommer på prioriteringslisten takket være medlemmene i samfunnet vårt.
Vi har for øyeblikket følgende liste over planer for nær fremtid:
- VPN som en tjeneste
- Private DNS-instanser er bilder for raskt å sette opp virtuelle maskiner med en forhåndskonfigurert DNS-server.
- DNS som en tjeneste.
- Intern lastbalanser.
- Legge til en "hvit" IP-adresse uten å gjenskape den virtuelle maskinen.
Balanseringen og muligheten til å bytte IP-adresse for en allerede opprettet virtuell maskin var på denne listen på forespørsel fra brukere. For å være ærlig, uten eksplisitt tilbakemelding, ville vi ha tatt på oss disse funksjonene litt senere. Så vi jobber allerede med problemet med adresser.
I utgangspunktet kunne en "hvit" IP-adresse bare legges til når du oppretter en maskin. Hvis brukeren glemte å gjøre dette, måtte den virtuelle maskinen gjenskapes. Det samme og, om nødvendig, fjern den eksterne IP-en. Det vil snart være mulig å slå den offentlige IP-en av og på uten å måtte gjenskape maskinen.
Uttrykk gjerne din andre brukere. Du hjelper oss med å gjøre skyen bedre og få viktige og nyttige funksjoner raskere!
Kilde: www.habr.com