Hallo, my naam is Kostya Kramlikh, ek is die hoofontwikkelaar van die Virtual Private Cloud-afdeling in Yandex.Cloud. Ek is 'n virtuele netwerker, en soos jy dalk raai, sal ek in hierdie artikel praat oor die Virtual Private Cloud (VPC) toestel in die algemeen en die virtuele netwerk in die besonder. En jy sal ook uitvind hoekom ons, die ontwikkelaars van die diens, terugvoer van ons gebruikers waardeer. Maar eerste dinge eerste.
Wat is VPC?
Deesdae is daar 'n verskeidenheid opsies vir die implementering van dienste. Ek is seker iemand hou nog steeds die bediener onder die administrateur se lessenaar, alhoewel ek hoop daar is minder sulke stories.
Nou probeer dienste na publieke wolke gaan, en dit is waar hulle met VPC's bots. VPC is deel van 'n publieke wolk wat gebruikers-, infrastruktuur-, platform- en ander vermoëns saambind, waar hulle ook al is, in ons Wolk of daarbuite. Terselfdertyd laat VPC jou toe om nie hierdie vermoëns onnodig aan die internet bloot te stel nie, hulle bly binne jou geïsoleerde netwerk.
Hoe lyk 'n virtuele netwerk van buite af?
Met VPC bedoel ons hoofsaaklik 'n oorlegnetwerk en netwerkdienste, soos VPNaaS, NATaas, LBaas, ens. En dit alles werk bo-op 'n foutverdraagsame netwerkinfrastruktuur, wat reeds is hier, op Habré.
Kom ons kyk van naderby na die virtuele netwerk en sy toestel.
Oorweeg twee beskikbaarheidsones. Ons verskaf 'n virtuele netwerk - wat ons VPC genoem het. Trouens, dit definieer die ruimte van uniekheid van jou "grys" adresse. Binne elke virtuele netwerk het jy volle beheer oor die spasie van adresse wat jy kan toewys om te bereken hulpbronne.
Die netwerk is wêreldwyd. Terselfdertyd word dit op elk van die beskikbaarheidsones geprojekteer in die vorm van 'n entiteit genaamd Subnet. Vir elke subnet ken jy 'n CIDR van grootte 16 of minder toe. Daar kan meer as een so 'n entiteit in elke beskikbaarheidsone wees, en daar is altyd deursigtige roetes tussen hulle. Dit beteken dat al jou hulpbronne binne dieselfde VPC met mekaar kan "praat", selfs al is hulle in verskillende Beskikbaarheidsones. "Kommunikeer" sonder toegang tot die internet, deur ons interne kanale, "dink" dat hulle binne dieselfde private netwerk is.
Die diagram hierbo toon 'n tipiese situasie: twee VPC's wat iewers in adresse sny. Albei kan joune wees. Byvoorbeeld, een vir ontwikkeling, die ander vir toetsing. Daar kan eenvoudig verskillende gebruikers wees - in hierdie geval maak dit nie saak nie. En een virtuele masjien is by elke VPC ingeprop.
Kom ons maak die skema erger. Jy kan dit so maak dat een virtuele masjien tegelyk in verskeie subnette vassit. En nie net so nie, maar in verskillende virtuele netwerke.
Terselfdertyd, as jy masjiene aan die internet moet blootstel, kan dit deur die API of UI gedoen word. Om dit te doen, moet jy NAT-vertaling van jou "grys", interne adres, instel na "wit" - publiek. Jy kan nie 'n "wit" adres kies nie, dit word lukraak uit ons poel adresse toegeken. Sodra jy ophou om die eksterne IP te gebruik, word dit na die swembad teruggestuur. Jy betaal slegs vir die tyd wat jy die "wit" adres gebruik.
Dit is ook moontlik om die masjien toegang tot die internet te gee deur 'n NAT-instansie te gebruik. Jy kan verkeer na 'n instansie stuur deur 'n statiese roeteringtabel. Ons het so 'n geval verskaf, want gebruikers het dit soms nodig, en ons weet daarvan. Gevolglik bevat ons beeldkatalogus 'n spesiaal gekonfigureerde NAT-beeld.
Maar selfs wanneer daar 'n gereed NAT-beeld is, kan die opstelling moeilik wees. Ons het verstaan dat dit vir sommige gebruikers nie die gerieflikste opsie is nie, so ons het dit uiteindelik moontlik gemaak om NAT vir die gewenste subnet in een klik te aktiveer. Hierdie kenmerk is steeds in geslote voorskoutoegang, waar dit met die hulp van gemeenskapslede getoets word.
Hoe die virtuele netwerk van binne gerangskik is
Hoe werk die gebruiker met die virtuele netwerk in wisselwerking? Die web kyk na buite met sy API. Die gebruiker kom na die API en werk met die teikenstaat. Deur die API sien die gebruiker hoe alles gereël en gekonfigureer moet word, terwyl hy die status sien, hoeveel die werklike toestand van die verlangde een verskil. Dit is 'n foto van die gebruiker. Wat gaan binne aan die gang?
Ons skryf die verlangde toestand na Yandex-databasis en gaan na verskillende dele van ons VPC op. Die oorlegnetwerk in Yandex.Cloud is gebaseer op geselekteerde komponente van OpenContrail, wat onlangs Tungsten Fabric genoem is. Netwerkdienste word op 'n enkele CloudGate-platform geïmplementeer. In CloudGate het ons ook 'n aantal oopbronkomponente gebruik: GoBGP - om toegang tot beheerinligting te verkry, sowel as VPP - om 'n sagtewareroeteerder te implementeer wat bo-op DPDK loop vir die datapad.
Tungsten Fabric kommunikeer met CloudGate via GoBGP. Vertel wat in die oorlegnetwerk aangaan. CloudGate verbind op sy beurt oorlegnetwerke met mekaar en met die internet.
Kom ons kyk nou hoe 'n virtuele netwerk die probleme van skaal en beskikbaarheid oplos. Kom ons kyk na 'n eenvoudige geval. Daar is een beskikbaarheidsone en twee VPC's word daarin geskep. Ons het een Tungsten Fabric-instansie ontplooi, en dit trek etlike tienduisende netwerke. Netwerke kommunikeer met CloudGate. CloudGate, soos ons reeds gesê het, verseker hul verbinding met mekaar en met die internet.
Kom ons sê 'n tweede beskikbaarheidsone word bygevoeg. Dit behoort heeltemal onafhanklik van die eerste te misluk. Daarom, in die tweede beskikbaarheidsone, moet ons 'n aparte Tungsten Fabric-instansie installeer. Dit sal 'n aparte stelsel wees wat met die oorleg handel en min van die eerste stelsel weet. En die sigbaarheid dat ons virtuele netwerk wêreldwyd is, skep in werklikheid ons VPC API. Dit is sy taak.
VPC1 word na Beskikbaarheidsone B gekarteer as daar hulpbronne in Beskikbaarheidsone B is wat na VPC1 gestoot word. As daar geen hulpbronne van VPC2 in beskikbaarheidsone B is nie, sal ons nie VPC2 in hierdie sone realiseer nie. Op sy beurt, aangesien hulpbronne van VPC3 slegs in sone B bestaan, bestaan VPC3 nie in sone A nie. Alles is eenvoudig en logies.
Kom ons gaan 'n bietjie dieper en kyk hoe 'n spesifieke gasheer in Y.Cloud werk. Die belangrikste ding wat ek wil opmerk, is dat alle gashere op dieselfde manier gerangskik is. Ons maak dit so dat slegs die nodige minimum dienste op hardeware werk, al die res op virtuele masjiene. Ons bou hoërorde-dienste gebaseer op basiese infrastruktuurdienste, en gebruik ook die Wolk om sommige ingenieursprobleme op te los, byvoorbeeld binne die raamwerk van Deurlopende Integrasie.
As ons na 'n spesifieke gasheer kyk, kan ons sien dat daar drie komponente op die gasheerbedryfstelsel loop:
- Reken - die deel wat verantwoordelik is vir die verspreiding van rekenaarhulpbronne op die gasheer.
- VRouter is 'n deel van Tungsten Fabric wat 'n oorleg organiseer, dit wil sê, dit tonnel pakkies deur 'n onderlaag.
- VDisks is stukke bergingvirtualisering.
Boonop word dienste in virtuele masjiene bekendgestel: Wolkinfrastruktuurdienste, platformdienste en klantekapasiteite. Kliëntevermoëns en platformdienste gaan altyd na die oorleg deur VRouter.
Infrastruktuurdienste kan by die oorleg vashou, maar basies wil hulle in die onderlaag werk. Hulle word met behulp van SR-IOV in die onderlaag vasgesteek. Trouens, ons sny die kaart in virtuele netwerkkaarte (virtuele funksies) en druk dit in infrastruktuur virtuele masjiene om nie prestasie te verloor nie. Byvoorbeeld, dieselfde CloudGate word as een van hierdie virtuele infrastruktuurmasjiene bekendgestel.
Noudat ons die globale take van die virtuele netwerk en die struktuur van die basiese komponente van die wolk beskryf het, kom ons kyk hoe presies die verskillende dele van die virtuele netwerk met mekaar omgaan.
Ons onderskei drie lae in ons stelsel:
- Config Plane - stel die teiken toestand van die stelsel. Dit is wat die gebruiker via die API konfigureer.
- Beheervlak - verskaf gebruikergedefinieerde semantiek, dit wil sê, bring die Datavlak-toestand na wat deur die gebruiker in Config Plane beskryf is.
- Data Plane - verwerk die gebruiker se pakkies direk.
Soos ek hierbo gesê het, begin dit alles met die feit dat die gebruiker of interne platformdiens na die API kom en 'n sekere teikentoestand beskryf.
Hierdie toestand word onmiddellik na Yandex-databasis geskryf, gee die asynchrone operasie-ID terug via die API, en begin ons interne masjinerie om die toestand terug te gee wat die gebruiker wou hê. Konfigurasietake gaan na die SDN-beheerder en vertel Tungsten Fabric wat om in die oorleg te doen. Hulle reserveer byvoorbeeld hawens, virtuele netwerke en dies meer.
Config Plane in Tungsten Fabric stuur die vereiste toestand na die Control Plane. Daardeur kommunikeer Config Plane met die gashere en vertel wat presies binnekort op hulle gaan draai.
Kom ons kyk nou hoe die stelsel op die gashere lyk. Die virtuele masjien het 'n netwerkadapter wat by VRouter ingeprop is. VRouter is 'n kern Tungsten Fabric-module wat na pakkies kyk. As daar reeds 'n vloei vir een of ander pakket is, verwerk die module dit. As daar geen vloei is nie, doen die module die sogenaamde punting, dit wil sê dit stuur 'n pakkie na die usermod-proses. Die proses ontleed die pakkie en reageer óf self daarop, soos DHCP en DNS, óf vertel VRouter wat om daarmee te doen. Daarna kan VRouter die pakkie verwerk.
Verder verloop verkeer tussen virtuele masjiene binne dieselfde virtuele netwerk deursigtig, dit word nie na CloudGate gerig nie. Die gashere waarop die virtuele masjiene ontplooi word, kommunikeer direk met mekaar. Hulle tonnel verkeer en stuur dit vir mekaar aan deur die onderlaag.
Beheervliegtuie kommunikeer met mekaar tussen beskikbaarheidsones via BGP, soos met 'n ander roeteerder. Hulle vertel watter masjiene waar op is sodat VM's in een sone direk met ander VM'e kan kommunikeer.
En Control Plane kommunikeer met CloudGate. Net so rapporteer dit waar en watter virtuele masjiene opgewek word, watter adresse hulle het. Dit laat jou toe om eksterne verkeer en verkeer van balanseerders na hulle te lei.
Die verkeer wat die VPC verlaat, kom na CloudGate, na die datapad, waar die VPP met ons inproppe vinnig opgekou word. Dan word die verkeer óf na ander VPC's óf buite afgevuur, na grensrouters wat deur die beheervlak van CloudGate self gekonfigureer is.
Planne vir die nabye toekoms
As ons alles hierbo in 'n paar sinne opsom, kan ons sê dat VPC in Yandex.Cloud twee belangrike take oplos:
- Bied isolasie tussen verskillende kliënte.
- Kombineer hulpbronne, infrastruktuur, platformdienste, ander wolke en op die perseel in 'n enkele netwerk.
En om hierdie probleme goed op te los, moet jy skaalbaarheid en fouttoleransie op die vlak van die interne argitektuur verskaf, wat VPC doen.
Geleidelik verkry VPC funksies, ons implementeer nuwe kenmerke, ons probeer iets verbeter in terme van gebruikersgerief. Sommige idees word uitgespreek en kom op die prioriteitslys danksy die lede van ons gemeenskap.
Ons het tans die volgende lys planne vir die nabye toekoms:
- VPN as 'n diens.
- Privaat DNS-gevalle is beelde vir die vinnige opstel van virtuele masjiene met 'n vooraf-gekonfigureerde DNS-bediener.
- DNS as 'n diens.
- Interne lasbalanseerder.
- Voeg 'n "wit" IP-adres by sonder om die virtuele masjien te herskep.
Die balanseerder en die vermoë om die IP-adres vir 'n reeds geskepde virtuele masjien te verander, was op hierdie lys op versoek van gebruikers. Om eerlik te wees, sonder eksplisiete terugvoer, sou ons hierdie funksies 'n bietjie later aangeneem het. En so werk ons reeds aan die probleem oor adresse.
Aanvanklik kon 'n "wit" IP-adres slegs bygevoeg word wanneer 'n masjien geskep word. As die gebruiker vergeet het om dit te doen, moes die virtuele masjien herskep word. Dieselfde en, indien nodig, verwyder die eksterne IP. Dit sal binnekort moontlik wees om die openbare IP aan en af te skakel sonder om die masjien te herskep.
Voel vry om jou uit te druk ander gebruikers. Jy help ons om die Wolk beter te maak en vinniger belangrike en nuttige kenmerke te kry!
Bron: will.com