Përshëndetje, emri im është Kostya Kramlih, unë jam zhvilluesi kryesor i divizionit Virtual Private Cloud në Yandex.Cloud. Unë merrem me rrjetin virtual dhe, siç mund të kuptoni, në këtë artikull do t'ju tregoj për strukturën e Virtual Private Cloud (VPC) në përgjithësi dhe të rrjetit virtual në veçanti. Po ashtu do të mësoni se përse ne, zhvilluesit e shërbimit, e vlerësojmë shumë feedback-un nga përdoruesit tanë. Por le të fillojmë me renditjen.
Çfarë është VPC?
Në kohët tona ka shumë mundësi për zhvillimin e shërbimeve. Jam i sigurt se dikush ende mban një server nën tryezën e administratorit, megjithatë, shpresoj që këto histori të bëhen gjithnjë e më të pakta.
Aktualisht shërbimet përpiqen të kalojnë në cloud publik, dhe pikërisht këtu ata përballen me VPC. VPC është një pjesë e cloud-it publik që lidh fuqitë e përdoruesve, infrastrukturës, platformave dhe të tjerave së bashku, kudo që ndodhen, në Clouds tonë apo jashtë saj. Gjithashtu, VPC lejon që të mos ekspozoni këto fuqi në internet pa nevojë, ato mbeten brenda rrjetit tuaj të izoluar.
Si dhe duket një rrjet virtual nga jashtë
Me VPC, ne kuptojmë para se gjithash një rrjet mbështetje dhe shërbime rrjeti si VPNaaS, NATaas, LBaas etj. Të gjitha këto funksionojnë mbi një infrastrukturë rrjeti të qëndrueshme, për të cilën është folur më parë artikull i shkëlqyer këtu, në Habr.
Le të shohim më afër rrjetin virtual dhe strukturën e tij.
Të shqyrtojmë dy zona qasje. Ne ofrojmë një rrjet virtual - atë që e quajmë VPC. Në fakt, ajo përcakton hapësirën e veçantisë për adresat tuaja 'të grisë'. Brenda çdo rrjeti virtual, ju keni kontroll të plotë mbi hapësirën e adresave që mund të caktoni për burimet kompjuterike.
Rrjeti është global. Ai projektohet në çdo zonë të disponueshmërisë si një entitet i quajtur Subnet. Për çdo Subnet, duhet të caktoni një CIDR me një madhësi 16 ose më të vogël. Në çdo zonë të disponueshmërisë mund të ketë më shumë se një të tillë, dhe midis tyre gjithmonë ka routing transparent. Kjo do të thotë se të gjitha burimet tuaja brenda një VPC mund të "komunikojnë" me njëra-tjetrën, madje edhe nëse ndodhen në zona të ndryshme të disponueshmërisë. "Të komunikojnë" pa dalë në internet, nëpërmjet kanaleve tona të brendshme, të "mendoni" se ndodhen brenda një rrjeti privat.
Në diagramin e mësipërm është ilustruar një rast tipik: dy VPC-të, të cilat ndodhen diku që përputhen në adresat. Të dyja mund të përkasin juve. Për shembull, një për zhvillim, tjetra për testim. Mund të jenë thjesht përdorues të ndryshëm – në këtë rast nuk ka rëndësi. Dhe në çdo VPC është instaluar një makinë virtuale.
Ta përkeqësojmë diagramin. Mund të bëhet që një makinë virtuale të lidhet menjëherë me disa Subnet. Dhe jo thjesht ashtu, por në rrjete të ndryshme virtuale.
Në rast se keni nevojë të ekspozoni makinat në internet, mund ta bëni këtë përmes API-së ose UI-së. Për këtë, është e nevojshme të konfiguroni transmetimin NAT të adresës tuaj "të errët", brenda, në një adresë "të bardhë" – publike. Nuk mund të zgjidhni adresën "të bardhë", ajo caktohet rastësisht nga grupi ynë i adresave. Sapo të pushoni së përdoruri IP-në e jashtme, ajo kthehet në grup. Ju paguani vetëm për kohën e përdorimit të adresës "të bardhë".
Ka gjithashtu mundësinë për të dhënë një makinë akses në internet përmes një instancë NAT. Trafici mund të rrugëzohet në instancë përmes një tabele statike të rrugëzimit. Ne kemi parashikuar një rast të tillë, sepse ndodh shpesh që përdoruesit e kanë nevojë, dhe ne e dimë këtë. Prandaj, në katalogun tonë të imazheve ndodhet një imazh NAT i konfiguruar posaçërisht.
Megjithëse ekziston një imazh NAT i gatshëm, konfigurimi mund të jetë i ndërlikuar. Ne kuptuam se për disa përdorues ky nuk është opsioni më i përshtatshëm, prandaj në fund krijuam mundësinë për të aktivizuar NAT për subnet-in e nevojshëm me një klik. Kjo veçori është ende në aksesin preview të mbyllur, duke u testuar me ndihmën e anëtarëve të komunitetit.
Si është e organizuar një rrjet virtual nga brenda
Si ndikon përdoruesi në rrjetin virtual? Rrjeti shikon jashtë përmes API-së së tij. Përdoruesi hyn në API dhe punon me gjendjen e synuar. Përmes API-së, përdoruesi sheh si duhet të jetë strukturuar dhe konfiguruar gjithçka, duke parë gjithashtu statusin e saj, sa shumë gjendja aktuale ndryshon nga ajo që dëshirohet. Kjo është pamja e përdoruesit. Po çfarë ndodh brenda?
Ne regjistrojmë gjendjen e dëshiruar në Yandex Database dhe shkëmbejmë konfigurimin e pjesëve të ndryshme të VPC-së tonë. Rrjeti i mbështjelljes në Yandex.Cloud është ndërtuar mbi komponentët e zgjedhur të OpenContrail, i cili kohët e fundit ka marrë emrin Tungsten Fabric. Shërbimet rrjetërore janë të implementuara në një platformë të vetme, CloudGate. Në CloudGate ne gjithashtu përdorëm një sasi të caktuar komponentësh open source: GoBGP – për aksesimin e informacionit të kontrollit, si dhe VPP – për implementimin e një router-i programatik që funksionon mbi DPDK për rrugën e të dhënave.
Tungsten Fabric komunikon me CloudGate përmes GoBGP. Njofton se çfarë ndodh në rrjetin e mbështjelljes. CloudGate, nga ana tjetër, lidh rrjetet e mbështjelljes me njëra-tjetrën dhe me internetin.
Tani le të shohim se si rrjeti virtual zgjidh problemet e shkallëzueshmërisë dhe disponueshmërisë. Le të marrim një rast të thjeshtë. Kemi një zonë aksesuese dhe në të janë krijuar dy VPC. Ne kemi zhvilluar një instancë Tungsten Fabric, e cila mbart disa dhjetëra mijëra rrjete. Rrjetet lidhen me CloudGate. CloudGate, siç e kemi thënë më parë, siguron lidhshmërinë midis tyre dhe me internetin.
Supozoni se shtohet një zonë e dytë aksesuese. Ajo duhet të funksionojë plotësisht e pavarur nga e para. Prandaj, në zonën e dytë aksesuese ne duhet të vendosim një instancë të veçantë Tungsten Fabric. Kjo do të jetë një sistem i veçantë, i cili merret me overlay dhe di pak për sistemin e parë. Ndërsa, vizibiliteti se rrjeti ynë virtual është global, në fakt, krijohet nga API-ja jonë VPC. Kjo është detyra e tij.
VPC1 projektohet në zonën e aksesit B, nëse në zonën e aksesit B ka burime që lidhen me VPC1. Nëse nuk ka burime nga VPC2 në zonën e aksesit B, VPC2 në këtë zonë nuk materializohet. Nga ana tjetër, për shkak se burimet nga VPC3 ekzistojnë vetëm në zonën B, VPC3 nuk është në zonën A. E gjithë kjo është e thjeshtë dhe logjike.
Le të shkojmë pak më thellë dhe të shohim se si funksionon një host specifik në Y.Oblak. E vetmja gjë që duhet theksuar është se të gjithë hostet funksionojnë njësoj. Ne sigurojmë që vetëm minimumi i nevojshëm i shërbimeve të jetë aktiv në "harduer", ndërsa të gjitha shërbimet e tjera funksionojnë mbi makinat virtuale. Ne ndërtuam shërbime më të avancuara mbi shërbimet bazike infrastrukturore dhe gjithashtu përdorim Cloud për të zgjidhur disa detyra inxhinierike, siç është në kuadër të Continuous Integration.
Nëse shohim një host të veçantë, do të shohim se në sistemin operativ të hostit funksionojnë tre komponente:
- Compute – pjesa që merret me pajisjen e burimeve computuese në host.
- VRouter – pjesa e Tungsten Fabric që organizon overlay, dmth tunelon paketat përmes underlay.
- VDisk – këto janë segmente të virtualizimit të ruajtjes.
Përveç kësaj, në makinat virtuale janë aktive shërbime: shërbimet infrastrukturore të Cloud, shërbimet e platformës dhe kapacitetet e klientëve. Kapacitetet e klientëve dhe shërbimet e platformës gjithmonë kalojnë në overlay përmes VRouter.
Shërbimet infrastrukturore mund të integrohen në overlay, por kryesisht duan të punojnë në underlay. Në underlay, ato integrohen përmes SR-IOV. Faktikisht, ne e ndajmë kartën në karta virtuale rrjetesh (funksione virtuale) dhe i futim ato në makinat virtuale infrastrukturore, për të mos humbur performancën. Për shembull, CloudGate i famshëm është nisur si njëra prej këtyre makinave virtuale infrastrukturore.
Tani, kur kemi përshkruar detyrat globale të rrjetit virtual dhe strukturën e komponentëve bazë të rethit, le të shohim se si pjesët e ndryshme të rrjetit virtual ndërveprojnë me njëra-tjetrën.
Ne kemi identifikuar në sistemin tonë tre nivele:
- Config Plane – përcakton gjendjen e synuar të sistemit. Ky është parametrizimi që përdoruesi e bën përmes API.
- Control Plane – siguron semantikën e caktuar nga përdoruesi, domethënë e sjell gjendjen e Data Plane në atë që është përshkruar nga përdoruesi në Config Plane.
- Data Plane – përpunon drejtpërdrejt paketat e përdoruesit.
Siç e përmenda më lart, gjithçka fillon kur përdoruesi ose shërbimi i brendshëm i platformës hyn në API dhe përshkruan një gjendje të caktuar që do të arrihet.
Ky kyç është regjistruar menjëherë në Yandex Database, kthen përmes API ID të operacionit asinkron dhe niset mekanizmi ynë të brendshëm për të dhënë gjendjen që dëshiron përdoruesi. Detyrat e konfigurimit shkojnë në SDN-kontroller dhe tregojnë Tungsten Fabric se çfarë duhet bërë në overlay. Për shembull, ato rezervojnë porte, rrjeta virtuale dhe gjëra të ngjashme.
Plani i Konfigurimit në Tungsten Fabric dërgon në Planin e Kontrollit gjendjen e kërkuar. Përmes tij, Plani i Konfigurimit komunikon me hostet, duke thënë se çfarë do të funksionojë aty së shpejti.
Tani le të shohim se si duket sistemi në hoste. Në makinën virtuale ka një adaptues rrjeti, i vendosur në VRouter. VRouter është moduli thelbësor i Tungsten Fabric, i cili shqyrton paketat. Nëse për ndonjë paketë ka tashmë një rrjedhë, moduli e përpunon atë. Nëse s'ka rrjedhë, moduli bën atë që quhet punting, dmth dërgon paketën në procesin e modës së përdoruesit. Procesi analizon paketën dhe ose përgjigjet vetë, siç është në DHCP dhe DNS, ose i tregon VRouter se çfarë të bëjë me të. Pas kësaj, VRouter mund të përpunojë paketën.
Trafiku midis makinave virtuale brenda një rrjeti virtual është i kalueshëm, ai nuk dërgohet në CloudGate. Hostet, mbi të cilat janë vendosur makinat virtuale, komunikojnë me njëri-tjetrin përmes një lidhjeje direkte. Ata tunnelojnë trafikun dhe e kalojnë atë përmes rrjetit.
Control Plane komunikon me njëri-tjetrin midis zonave të disponueshmërisë përmes BGP, ashtu si me një router tjetër. Ata tregojnë se cilat makina janë ngritur dhe ku, në mënyrë që makinat virtuale në një zonë të mund të ndërveprojnë drejtpërdrejt me makinat virtuale të tjera.
Për më tepër, Control Plane komunikon me CloudGate. Ai njofton se ku dhe çfarë makinash virtuale janë ngritur dhe cilat janë adresat e tyre. Kjo lejon dërgimin e trafikut të jashtëm dhe trafikut nga balancuesit.
Trafiku që del nga VPC arrin në CloudGate, në rrugën e të dhënave, ku përpunohen shpejt me VPP-në tonë dhe pluginet. Më pas trafiku dërgohet ose në VPC të tjera, ose jashtë, në routerat kufitarë, të cilat konfigurohen përmes Control Plane të CloudGate.
Planet për të ardhmen e afërt
Nëse e përgjithësojmë të gjitha të thënë më lart në disa fraza, mund të themi se VPC në Yandex.Cloud përmbush dy detyra të rëndësishme:
- Siguron izolimin ndërmjet klientëve të ndryshëm.
- Përfshin burimet, infrastrukturën, shërbimet e platformave, re të tjera dhe on-premise në një rrjet të vetëm.
Dhe për të zgjidhur këto detyra mirë, nevojitet të sigurojmë shkallëzueshmëri dhe qëndrueshmëri në nivelin e arkitekturës së brendshme, gjë që e bën VPC.
Gradualisht, VPC shpërfaq funksione, ne realizojmë mundësi të reja dhe përpiqemi të përmirësojmë diçka në aspektin e komoditetit për përdoruesit. Disa ide shprehen dhe përfshihen në listën e prioriteteve falë pjesëmarrësve në komunitetin tonë.
Aktualisht, kemi një listë planesh për të ardhmen e afërt:
- VPN si një shërbim.
- Instancat Private DNS – imazhe për konfigurimin e shpejtë të makinave virtuale me një server DNS të parakonfiguruar.
- DNS si një shërbim.
- Balancuesi i ngarkesave të brendshëm.
- Shtimi i një adrese IP 'të bardhë' pa riprodhimin e makinerisë virtuale.
Balancuesi dhe mundësia për të ndërruar adresën IP për makinat virtuale që janë krijuar tashmë u përfshinë në këtë listë për kërkesën e përdoruesve. Të them sinqerisht, pa një kthim të qartë, do të merreshim me këto funksione disa më vonë. Tani, ne po punojmë për detyrën lidhur me adresat.
Në fillim, adresa IP "e bardhë" mund të shtohej vetëm gjatë krijimit të makinës. Nëse përdoruesi e harronte këtë, makina virutale duhej të ripërtërinte. E njëjta gjë ndodhte dhe kur duhej hequr IP e jashtme. Shpejt do të jetë e mundur të aktivizohet dhe dezaktivizohet IP publik pa e ripërtërirë makinën.
Mos hezitoni të shprehni ide dhe të mbështesni propozimet e përdoruesve të tjerë. Ju ndihmoni që të bëjmë Cloud më të mirë dhe të merrni më shpejt funksione të rëndësishme dhe të dobishme!
Burimi: habr.com
