![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/62b3d222c1911fb28a345defdd81135c.jpeg\")
<\/p>\nHej, jeg hedder Kostya Kramlix, jeg er hovedudvikler i Virtual Private Cloud-afdelingen i Yandex.Cloud. Jeg arbejder med det virtuelle netv\u00e6rk, og som du nok kan g\u00e6tte, vil jeg i denne artikel fort\u00e6lle om strukturen af Virtual Private Cloud (VPC) generelt og det virtuelle netv\u00e6rk specifikt. Desuden vil du finde ud af, hvorfor vi, udviklerne af tjenesten, v\u00e6rds\u00e6tter feedback fra vores brugere. Men lad os tage det hele i r\u00e6kkef\u00f8lge.<\/p>\n
<\/p>\n
<\/a><\/p>\n I dag er der mange forskellige muligheder for at implementere tjenester. Jeg er sikker p\u00e5, at nogen stadig har en server st\u00e5ende under administratorens skrivebord, selvom jeg h\u00e5ber, at s\u00e5danne historier bliver f\u00e6rre.<\/p>\n Nu til dags fors\u00f8ger tjenesterne at bev\u00e6ge sig over i offentlige skyer, og her st\u00f8der de netop p\u00e5 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\u00f8dvendigt at eksponere disse ressourcer p\u00e5 internettet; de forbliver inden for dit isolerede netv\u00e6rk.<\/p>\n Under VPC forst\u00e5r vi f\u00f8rst og fremmest et overlay-netv\u00e6rk og netv\u00e6rkstjenester som VPNaaS, NATaas, LBaas osv. Og alt dette fungerer oven p\u00e5 en fejltolerant netv\u00e6rksinfrastruktur, som allerede er blevet beskrevet i en fremragende artikel<\/a> her p\u00e5 Habr.<\/p>\n Lad os tage et n\u00e6rmere kig p\u00e5 det virtuelle netv\u00e6rk og dets struktur.<\/p>\n Lad os se p\u00e5 to tilg\u00e6ngelighedszoner. Vi tilbyder et virtuelt netv\u00e6rk \u2013 det, vi kalder VPC. Faktisk definerer det rummet for unikke \"gr\u00e5\" adresser. Inden for hvert virtuelt netv\u00e6rk kontrollerer du helt rummet for adresser, som du kan tildele til beregningsressourcer.<\/p>\n Nettet er globalt. Det projiceres p\u00e5 hver tilg\u00e6ngelig zone som en enhed kaldet Subnet. For hver Subnet tildeler du en CIDR p\u00e5 st\u00f8rrelse 16 eller mindre. Der kan v\u00e6re mere end \u00e9n s\u00e5dan enhed i hver tilg\u00e6ngelig zone, og der er altid gennemsigtig routing mellem dem. Det betyder, at alle dine ressourcer inden for \u00e9n VPC kan \"kommunikere\" med hinanden, selvom de befinder sig i forskellige tilg\u00e6ngelige zoner. \"Kommunikere\" uden at g\u00e5 p\u00e5 internettet, via vores interne kanaler, \"t\u00e6nker\", at de befinder sig inden for et privat netv\u00e6rk.<\/p>\n Diagrammet ovenfor viser en typisk situation: to VPC'er, der et sted krydser adresser. Begge kan tilh\u00f8re dig. For eksempel \u00e9n til udvikling, en anden til test. Det kan simpelthen v\u00e6re forskellige brugere \u2013 i dette tilf\u00e6lde er det ikke vigtigt. Og i hver VPC er der tilsluttet en virtuel maskine.<\/p>\n Lad os komplicere diagrammet. Man kan g\u00f8re det muligt, at \u00e9n virtuel maskine kan tilsluttes flere Subnets p\u00e5 \u00e9n gang. Og ikke bare s\u00e5dan, men i forskellige virtuelle netv\u00e6rk.<\/p>\n Hvis du har brug for at eksponere maskinerne til internettet, kan dette g\u00f8res via API eller UI. For dette skal du konfigurere NAT-overs\u00e6ttelse af din \"gr\u00e5\", interne adresse til \"hvid\" \u2013 offentlig. Du kan ikke v\u00e6lge den \"hvite\" adresse, den tildeles tilf\u00e6ldigt fra vores adressepulje. S\u00e5 snart du stopper med at bruge den eksterne IP, returneres den til puljen. Du betaler kun for den tid, du bruger den \"hvide\" adresse.<\/p>\n Der er ogs\u00e5 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\u00e5dant tilf\u00e6lde, fordi det kan v\u00e6re n\u00f8dvendigt for brugerne, og vi ved det. Derfor ligger der en specielt konfigureret NAT-image i vores billedkatalog.<\/p>\n Men selv n\u00e5r der er en klar NAT-image, kan ops\u00e6tningen v\u00e6re kompliceret. Vi forstod, at dette ikke var den mest bekvemme l\u00f8sning for nogle brugere, s\u00e5 vi har i sidste ende lavet en mulighed for at aktivere NAT for den \u00f8nskede Subnet med et enkelt klik. Denne funktion er stadig i lukket preview-adgang, hvor den testes med hj\u00e6lp fra samfundets medlemmer.<\/p>\n Hvordan interagerer brugeren med det virtuelle netv\u00e6rk? Nettet ser udad med sin API. Brugeren kommer til API'en og arbejder med den \u00f8nskede tilstand. Gennem API'en ser brugeren, hvordan alt skal v\u00e6re organiseret og konfigureret, samtidig med at han ser status for, hvor langt den faktiske tilstand adskiller sig fra den \u00f8nskede. Dette er brugerens billede. Men hvad sker der indeni?<\/p>\n Vi gemmer den \u00f8nskede tilstand i Yandex Database og g\u00e5r i gang med at konfigurere forskellige dele af vores VPC. Overlay-netv\u00e6rket i Yandex.Cloud er bygget p\u00e5 udvalgte komponenter fra OpenContrail, som for nylig er blevet kendt som Tungsten Fabric. Netv\u00e6rkstjenesterne er implementeret p\u00e5 en ensartet CloudGate-platform. I CloudGate har vi ogs\u00e5 anvendt nogle open source-komponenter: GoBGP til at hente kontrolinformation og VPP til at implementing en software-router, der k\u00f8rer over DPDK for data path.<\/p>\n Tungsten Fabric kommunikerer med CloudGate via GoBGP. Det rapporterer, hvad der sker i overlay-netv\u00e6rket. CloudGate forbinder p\u00e5 sin side overlay-netv\u00e6rkene med hinanden og med internettet.<\/p>\n Lad os nu se p\u00e5, hvordan det virtuelle netv\u00e6rk l\u00f8ser skalerings- og tilg\u00e6ngelighedsopgaver. Lad os overveje et enkelt tilf\u00e6lde. Der er en tilg\u00e6ngelighedszone, og der er oprettet to VPC'er i den. Vi har rullet et Tungsten Fabric-instans ud, og det underst\u00f8tter flere tusinde netv\u00e6rk. Netv\u00e6rkene forbindes med CloudGate. CloudGate sikrer, som vi allerede har n\u00e6vnt, forbindelse mellem dem og med internettet.<\/p>\n Lad os sige, at der tilf\u00f8jes en anden tilg\u00e6ngelighedszone. Den skal v\u00e6re helt uafh\u00e6ngig af den f\u00f8rste. Derfor skal vi i den anden tilg\u00e6ngelighedszone installere et separat Tungsten Fabric-instans. Dette vil v\u00e6re et separat system, der h\u00e5ndterer overlayet og ikke ved meget om det f\u00f8rste system. Og synligheden af, at vores virtuelle netv\u00e6rk er globalt, skabes faktisk af vores VPC API. Det er dens opgave.<\/p>\n VPC1 projiceres ind i tilg\u00e6ngelighedszonen B, hvis der er ressourcer i tilg\u00e6ngelighedszonen B, som er tilsluttet VPC1. Hvis der ikke er nogen ressourcer fra VPC2 i tilg\u00e6ngelighedszonen B, materieliserer vi ikke VPC2 i denne zone. P\u00e5 den anden side, da ressourcerne fra VPC3 kun eksisterer i zone B, findes VPC3 ikke i zone A. Det er simpelt og logisk.<\/p>\n Lad os g\u00e5 lidt dybere og se p\u00e5, hvordan en specifik v\u00e6rt er opbygget i \u042f.\u041e\u0431\u043b\u0430\u043a\u0435. Det vigtigste, jeg gerne vil fremh\u00e6ve, er, at alle v\u00e6rter er opbygget ens. Vi s\u00f8rger for, at kun det n\u00f8dvendige minimum af tjenester k\u00f8rer p\u00e5 \"hardwaren\", mens alle andre k\u00f8rer p\u00e5 virtuelle maskiner<\/a>. Vi bygger tjenester af h\u00f8jere orden baseret p\u00e5 grundl\u00e6ggende infrastrukturtjenester samt bruger Cloud til at l\u00f8se nogle ingeni\u00f8ropgaver, f.eks. inden for Continuous Integration.<\/p>\n Hvis vi ser p\u00e5 en specifik v\u00e6rt, vil vi se, at der k\u00f8rer tre komponenter i v\u00e6rtens OS:<\/p>\n Derudover er der virtuelle maskiner<\/a> tjenester k\u00f8rende: infrastrukturtjenester fra Cloud, platformtjenester og kundernes kapaciteter. Kundernes kapaciteter og platformtjenester g\u00e5r altid i overlay gennem VRouter.<\/p>\n Infrastrukturtjenester kan tilsluttes overlay, men \u00f8nsker som regel at arbejde i underlay. I underlay tilsluttes de via SR-IOV. Faktisk sk\u00e6rer vi kortet op i virtuelle netv\u00e6rkskort (virtuelle funktioner) og inds\u00e6tter dem i infrastrukturelle virtuelle maskiner for ikke at miste ydeevne. For eksempel er den samme CloudGate k\u00f8rt som en af disse infrastrukturelle virtuelle maskiner.<\/p>\n Nu, hvor vi har beskrevet de globale opgaver for det virtuelle netv\u00e6rk og strukturen af de grundl\u00e6ggende komponenter i skyen, lad os se p\u00e5, hvordan de forskellige dele af det virtuelle netv\u00e6rk interagerer med hinanden.<\/p>\n Vi fremh\u00e6ver tre lag i vores system:<\/p>\n Som jeg n\u00e6vnte tidligere, begynder det hele med, at brugeren eller en intern platformtjeneste kommer til API'et og beskriver en specifik m\u00e5ltilstand.<\/p>\n 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 \u00f8nskede tilstand til brugeren. Konfigurationstasks sendes til SDN-controlleren og informerer Tungsten Fabric om, hvad der skal g\u00f8res i overlayet. For eksempel reserverer de porte, virtuelle netv\u00e6rk og lignende.<\/p>\n Config Plane i Tungsten Fabric leverer den n\u00f8dvendige tilstand til Control Plane. Gennem det kommunikerer Config Plane ogs\u00e5 med v\u00e6rterne og fort\u00e6ller, hvad der snart vil k\u00f8re p\u00e5 dem.<\/p>\n Lad os nu se, hvordan systemet ser ud p\u00e5 v\u00e6rterne. I virtuelle maskiner<\/a> er der en netv\u00e6rksadapter tilsluttet VRouter. VRouter er den centrale modul i Tungsten Fabric, der ser p\u00e5 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\u00e5 den, som i tilf\u00e6lde af DHCP og DNS, eller instruerer VRouter om, hvad der skal g\u00f8res med den. Herefter kan VRouter behandle pakken.<\/p>\n Trafikken mellem virtuelle maskiner inden for et virtuelt netv\u00e6rk g\u00e5r gennemsigtigt, den dirigeres ikke til CloudGate. V\u00e6rterne, hvor de virtuelle maskiner er implementeret, kommunikerer direkte med hinanden. De tunnelere trafikken og sender den videre til hinanden gennem overlayet.<\/p>\n Control Plane kommunikerer med hinanden mellem tilg\u00e6ngelighedszonerne over BGP, som med en anden router. De informerer, hvilke maskiner der er oppe, s\u00e5 virtuelle maskiner i en zone kan interagere direkte med andre virtuelle maskiner.<\/p>\n Control Plane kommunikerer ogs\u00e5 med CloudGate. I lighed med dette informerer de om, hvor og hvilke virtuelle maskiner der er oppe, og hvilke adresser de har. Dette muligg\u00f8r, at ekstern trafik og trafik fra belastningsbalancerere kan dirigeres til dem.<\/p>\n 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\u00e6nserouternes, som konfigureres gennem Control Plane i CloudGate.<\/p>\n Hvis man opsummerer alt det ovenst\u00e5ende i nogle f\u00e5 s\u00e6tninger, kan man sige, at VPC i Yandex.Cloud l\u00f8ser to vigtige opgaver:<\/p>\n For at l\u00f8se disse opgaver godt, er det n\u00f8dvendigt at sikre skalerbarhed og fejltolerance p\u00e5 niveau med den interne arkitektur, hvilket VPC g\u00f8r.<\/p>\n Efterh\u00e5nden som VPC udvikler sig, tilf\u00f8jer vi nye funktioner, str\u00e6ber efter at forbedre brugervenligheden. Nogle id\u00e9er bliver fremh\u00e6vet og kommer p\u00e5 prioritetslisten takket v\u00e6re medlemmerne af vores f\u00e6llesskab.<\/p>\n Vi har i \u00f8jeblikket cirka denne liste over planer for den n\u00e6rmeste fremtid:<\/p>\n Belastningsbalancer og muligheden for at skifte IP-adresse for en allerede oprettet virtuel maskine var blevet efterspurgt af brugerne. Jeg m\u00e5 v\u00e6re \u00e6rlig: uden tydelig feedback ville vi tage fat p\u00e5 disse funktioner lidt senere. Men nu arbejder vi allerede p\u00e5 opgaven med adresser.<\/p>\n Oprindeligt kunne den \u201ehvide\u201c IP-adresse kun tilf\u00f8jes ved oprettelsen af maskinen. Hvis brugeren glemte at g\u00f8re dette, m\u00e5tte den virtuelle maskine genskabes. Det samme gjaldt for behovet for at fjerne den eksterne IP. Snart vil det v\u00e6re muligt at aktivere og deaktivere den offentlige IP uden at genskabe maskinen.<\/p>\n T\u00f8v ikke med at give dine id\u00e9er og st\u00f8tte forslagene<\/a> fra andre brugere. Du hj\u00e6lper os med at g\u00f8re Cloud bedre og hurtigere f\u00e5 vigtige og nyttige funktioner!<\/p>\nHvad er VPC?<\/h2>\n
Hvordan det virtuelle netv\u00e6rk ser ud udefra<\/h2>\n
![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/073a0cbac0e733decd8a4e6ffd9570ff.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/b1b7a15912f9c7995663ab9943d473f1.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/73e872a4f6c3e19576db4e4980d62a45.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/cc4ab2c7553d63ef2636924df1575479.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/c2375fd6d0fb7b55ca55787adf505229.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/744ac3bdd2f388bab2597d6fe1519d76.jpeg\")
<\/p>\nHvordan et virtuelt netv\u00e6rk er opbygget indenfra.<\/h2>\n
![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/71cab3ae7f067f165a87e30c60559794.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/222d68fff4b9577f316c8642e846172e.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/4da02ba041dcd886eee212dd8998718c.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/4664bd03793ba394ceda1f8214fa2c16.jpeg\")
<\/p>\n\n
\n
![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/644cddfa8bce83a501bf4788a21f9588.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/c2c6e443c93f8dedc6a63e4bd3fd7042.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/2139361a9e1837c7bc7f156e8bc36d38.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/1247f20fa2a12f093d7f1d2361d48a02.jpeg\")
<\/p>\n![\"Hvordan](\"\/wp-content\/uploads\/2020\/02\/f70cd562220c7367e29597d8e8b62f81.jpeg\")
<\/p>\nPlaner for den n\u00e6rmeste fremtid<\/h2>\n
\n
\n