Përshëndetje, quhem Kostya Kramlikh dhe jam zhvilluesi kryesor i ekipit të Virtual Private Cloud në Yandex Cloud. Punoj me rrjetin virtual dhe, siç mund të merret me mend, në këtë artikull do të tregoj se si është ndërtuar Virtual Private Cloud (VPC) në tërësi dhe rrjeti virtual në veçanti. Gjithashtu do të mësoni pse ne, zhvilluesit e shërbimit, e vlerësojmë aq shumë feedback-un nga përdoruesit tanë. Por le t’i marrim gjërat me radhë.
Çfarë është VPC?
Sot ekzistojnë shumë mënyra për të vendosur shërbime. Jam i sigurt se dikush ende mban një server poshtë tavolinës së administratorit, megjithëse shpresoj që raste të tilla po bëhen gjithnjë e më të rralla.
Sot shërbimet po kalojnë gjithnjë e më shumë në cloud-et publike dhe pikërisht aty përballen me VPC. VPC është pjesa e cloud-it publik që lidh në një të vetme burimet e përdoruesit, infrastrukturës, platformës dhe kapacitete të tjera, pavarësisht se ku ndodhen, në Cloud-in tonë apo jashtë tij. Njëkohësisht, VPC ju lejon të mos i ekspozoni pa nevojë këto burime në internet, pasi ato mbeten brenda rrjetit tuaj të izoluar.
Si duket rrjeti virtual nga jashtë
Me VPC ne nënkuptojmë para së gjithash një rrjet overlay dhe shërbime rrjeti si VPNaaS, NATaaS, LBaaS etj. E gjithë kjo funksionon mbi një infrastrukturë rrjeti me tolerancë të lartë ndaj dështimeve, për të cilën është publikuar tashmë një artikull i shkëlqyer këtu po ashtu, në Habr.
Le ta shohim më nga afër rrjetin virtual dhe mënyrën si është ndërtuar ai.
Le të marrim në shqyrtim dy zona disponueshmërie. Ne ofrojmë një rrjet virtual, atë që e quajtëm VPC. Në thelb, ai përcakton hapësirën e unikalitetit të adresave tuaja “gri”. Brenda çdo rrjeti virtual, ju menaxhoni plotësisht hapësirën e adresave që mund t’ua caktoni burimeve kompjuterike.
Rrjeti është global. Megjithatë, ai projektohet në secilën zonë disponueshmërie si një entitet i quajtur Subnet. Për çdo Subnet caktoni një CIDR me madhësi 16 ose më të vogël. Në çdo zonë disponueshmërie mund të ketë më shumë se një entitet të tillë, dhe mes tyre ka gjithmonë routing transparent. Kjo do të thotë se të gjitha burimet tuaja brenda një VPC-je mund të «komunikojnë» me njëri-tjetrin, edhe nëse ndodhen në zona të ndryshme disponueshmërie. Të «komunikojnë» pa dalje në internet, përmes kanaleve tona të brendshme, duke «menduar» se ndodhen brenda të njëjtit rrjet privat.
Në skemën e mësipërme paraqitet një situatë tipike: dy VPC që diku mbivendosen në adresa. Të dyja mund t’ju përkasin juve. Për shembull, njëra për zhvillim, tjetra për testim. Mund të jenë edhe thjesht përdorues të ndryshëm — në këtë rast kjo nuk ka rëndësi. Dhe në secilën VPC është lidhur nga një makinë virtuale.
Le ta komplikojmë skemën. Mund të bëhet që një makinë virtuale të lidhet menjëherë me disa Subnet. Dhe jo vetëm kaq, por edhe në rrjete virtuale të ndryshme.
Nëse ju duhet t’i ekspozoni makinat në internet, kjo mund të bëhet përmes API ose UI. Për këtë duhet të konfiguroni përkthimin NAT të adresës suaj të brendshme, «gri», në një adresë «të bardhë» — publike. Adresën «të bardhë» nuk mund ta zgjidhni vetë; ajo caktohet rastësisht nga puli ynë i adresave. Sapo të ndaloni së përdoruri IP-në e jashtme, ajo kthehet në pool. Ju paguani vetëm për kohën gjatë së cilës përdorni adresën «të bardhë».
Ekziston gjithashtu mundësia t’i jepni makinës qasje në internet me ndihmën e një NAT instance. Trafiku mund të routohet drejt instancës përmes një tabele statike routimi. Ne e kemi parashikuar këtë skenar, sepse u nevojitet përdoruesve dhe e dimë këtë. Përkatësisht, në katalogun tonë të imazheve gjendet një imazh NAT i konfiguruar posaçërisht.
Por edhe kur ka një imazh NAT të gatshëm, konfigurimi mund të jetë i ndërlikuar. E kuptonim se për disa përdorues kjo nuk ishte zgjidhja më e përshtatshme, ndaj në fund krijuam mundësinë për të aktivizuar NAT për Subnet-in e nevojshëm me një klikim. Kjo veçori është ende në preview të mbyllur, ku po testohet me ndihmën e anëtarëve të komunitetit.
Si është ndërtuar rrjeti virtual nga brenda
Si ndërvepron përdoruesi me rrjetin virtual? Rrjeti ekspozon API-n e tij nga jashtë. Përdoruesi lidhet me API-n dhe punon me gjendjen e synuar. Përmes API-së, përdoruesi sheh si duhet të jetë organizuar dhe konfiguruar gjithçka, si edhe statusin që tregon sa ndryshon gjendja reale nga ajo e dëshiruar. Kjo është pamja e përdoruesit. Po brenda, çfarë ndodh?
Ne e regjistrojmë gjendjen e dëshiruar në Yandex Database dhe vazhdojmë me konfigurimin e pjesëve të ndryshme të VPC-së sonë. Rrjeti overlay në Yandex Cloud është ndërtuar mbi disa komponentë të përzgjedhur të OpenContrail, i cili së fundmi quhet Tungsten Fabric. Shërbimet e rrjetit janë implementuar mbi platformën e unifikuar CloudGate. Edhe në CloudGate kemi përdorur disa komponentë open source: GoBGP për shkëmbimin e informacionit të kontrollit, si dhe VPP për implementimin e një routeri softuerik që funksionon mbi DPDK për data path.
Tungsten Fabric komunikon me CloudGate përmes GoBGP. Ai i transmeton çfarë po ndodh në rrjetin overlay. CloudGate, nga ana e vet, lidh rrjetet overlay me njëri-tjetrin dhe me internetin.
Tani le të shohim se si rrjeti virtual i zgjidh sfidat e shkallëzimit dhe disponueshmërisë. Le të marrim një rast të thjeshtë. Kemi një zonë disponueshmërie dhe në të janë krijuar dy VPC. Kemi vendosur një instancë të Tungsten Fabric dhe ajo mban disa dhjetëra mijëra rrjete. Rrjetet lidhen me CloudGate. CloudGate, siç e thamë edhe më parë, siguron lidhjen e tyre me njëri-tjetrin dhe me internetin.
Të supozojmë se shtohet një zonë e dytë disponueshmërie. Ajo duhet të dështojë plotësisht në mënyrë të pavarur nga e para. Prandaj, në zonën e dytë të disponueshmërisë duhet të vendosim një instancë të veçantë të Tungsten Fabric. Kjo do të jetë një sistem më vete, që merret me overlay dhe di shumë pak për sistemin e parë. Ndërsa perceptimin se rrjeti ynë virtual është global e krijon pikërisht VPC API ynë. Kjo është detyra e tij.
VPC1 projektohet në zonën e disponueshmërisë B nëse në zonën B ka burime që lidhen me VPC1. Nëse në zonën e disponueshmërisë B nuk ka burime nga VPC2, atëherë VPC2 nuk materializohet në atë zonë. Nga ana tjetër, duke qenë se burimet nga VPC3 ekzistojnë vetëm në zonën B, VPC3 nuk ekziston në zonën A. Gjithçka është e thjeshtë dhe logjike.
Le të hyjmë pak më në thellësi dhe të shohim si është ndërtuar një host i caktuar në Y.Cloud. Gjëja kryesore që vlen të theksohet është se të gjithë hostët janë të ndërtuar njësoj. Ne e organizojmë kështu që në “hardware” të ekzekutohet vetëm minimumi i nevojshëm i shërbimeve, ndërsa të gjitha të tjerat punojnë në makina virtuale. Ne ndërtojmë shërbime të nivelit më të lartë mbi bazën e shërbimeve bazë të infrastrukturës, si dhe përdorim Cloud për zgjidhjen e disa detyrave inxhinierike, për shembull në kuadër të Continuous Integration.
Nëse shohim një host konkret, do të vërejmë se në OS e hostit ekzekutohen tre komponentë:
- Compute – pjesa që është përgjegjëse për shpërndarjen e burimeve llogaritëse në host.
- VRouter – pjesë e Tungsten Fabric, e cila organizon overlay, pra tunelon paketat përmes underlay.
- VDisk – këto janë komponentë të virtualizimit të ruajtjes.
Përveç kësaj, në makina virtuale ekzekutohen shërbimet: shërbimet e infrastrukturës së Cloud, shërbimet e platformës dhe kapacitetet e klientëve. Kapacitetet e klientëve dhe shërbimet e platformës kalojnë gjithmonë në overlay përmes VRouter.
Shërbimet e infrastrukturës mund të lidhen me overlay, por në përgjithësi preferojnë të punojnë pikërisht në underlay. Me underlay lidhen përmes SR-IOV. Në praktikë, ne e ndajmë kartën në karta rrjeti virtuale (funksione virtuale) dhe ua kalojmë makinerive virtuale të infrastrukturës, që të mos humbasim performancë. Për shembull, ai vetë CloudGate është nisur si një nga këto makina virtuale të infrastrukturës.
Tani që përshkruam detyrat globale të rrjetit virtual dhe arkitekturën e komponentëve bazë të cloud-it, le të shohim se si ndërveprojnë saktësisht pjesë të ndryshme të rrjetit virtual me njëra-tjetrën.
Në sistemin tonë dallojmë tre shtresa:
- Config Plane – përcakton gjendjen e synuar të sistemit. Kjo është ajo që përdoruesi konfiguron përmes API.
- Control Plane – siguron semantikën e përcaktuar nga përdoruesi, domethënë e çon gjendjen e Data Plane në atë që përdoruesi ka përshkruar në Config Plane.
- Data Plane – përpunon drejtpërdrejt paketat e përdoruesit.
Siç e përmenda më sipër, gjithçka fillon kur përdoruesi ose një shërbim i brendshëm i platformës hyn në API dhe përshkruan një gjendje të caktuar të synuar.
Kjo gjendje regjistrohet menjëherë në Yandex Database, kthen përmes API-së ID-në e operacionit asinkron dhe nis mekanizmat tanë të brendshëm për të ofruar gjendjen që kërkoi përdoruesi. Detyrat e konfigurimit shkojnë te kontrolluesi SDN dhe i tregojnë Tungsten Fabric çfarë duhet të bëjë në overlay. Për shembull, rezervojnë porta, rrjete virtuale dhe të ngjashme.
Config Plane në Tungsten Fabric i dërgon Control Plane gjendjen e kërkuar. Përmes tij, Config Plane komunikon edhe me hostet, duke u treguar çfarë saktësisht do të ekzekutohet së shpejti në to.
Tani të shohim si duket sistemi në hoste. Në makinën virtuale ka një përshtatës rrjeti të lidhur me VRouter. VRouter është një modul i kernelit të Tungsten Fabric që inspekton paketat. Nëse për një paketë të caktuar tashmë ekziston një flow, moduli e përpunon atë. Nëse flow mungon, moduli bën të ashtuquajturin punting, pra e dërgon paketën te një proces në user mode. Procesi e analizon paketën dhe ose i përgjigjet vetë, si për shembull në rastin e DHCP dhe DNS, ose i tregon VRouter çfarë të bëjë me të. Pas kësaj, VRouter mund ta përpunojë paketën.
Më tej, trafiku mes makinave virtuale brenda të njëjtit rrjet virtual qarkullon në mënyrë transparente; ai nuk dërgohet te CloudGate. Hostet ku janë vendosur makinat virtuale komunikojnë drejtpërdrejt me njëri-tjetrin. Ata tunelojnë trafikun dhe ia përcjellin njëri-tjetrit përmes underlay.
Control Plane komunikojnë me njëri-tjetrin mes zonave të disponueshmërisë përmes BGP, si me një router tjetër. Ata njoftojnë 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 në zonat e tjera.
Për më tepër, Control Plane komunikon edhe me CloudGate. Po ashtu njofton se ku dhe cilat makina virtuale janë ngritur, si edhe cilat janë adresat e tyre. Kjo bën të mundur drejtimin e trafikut të jashtëm dhe trafikut nga balancuesit drejt tyre.
Trafiku që del nga VPC mbërrin te CloudGate, në data path, ku përpunohet me shpejtësi nga VPP me plug-inet tona. Më pas trafiku dërgohet ose te VPC të tjera, ose jashtë, te routerët kufitarë, të cilët konfigurohen përmes Control Plane të vetë CloudGate.
Planet për të ardhmen e afërt
Nëse përmbledhim në disa fjali gjithçka që u tha më sipër, mund të themi se VPC në Yandex Cloud zgjidh dy detyra të rëndësishme:
- Siguron izolim midis klientëve të ndryshëm.
- Ai bashkon burimet, infrastrukturën, shërbimet e platformës, cloud-e të tjera dhe mjediset on-premise në një rrjet të vetëm.
Për t’i zgjidhur këto detyra me cilësi, duhet të sigurohet shkallëzueshmëria dhe toleranca ndaj dështimeve në nivelin e arkitekturës së brendshme, dhe pikërisht këtë bën VPC.
Gradualisht, VPC po zgjerohet me funksione të reja; ne po implementojmë mundësi të reja dhe po përpiqemi të përmirësojmë përdorshmërinë për përdoruesit. Disa ide propozohen dhe hyjnë në listën e prioriteteve falë anëtarëve të komunitetit tonë.
Aktualisht, lista jonë e planeve për të ardhmen e afërt është afërsisht kjo:
- VPN si shërbim.
- Instanca Private DNS – imazhe për konfigurim të shpejtë të makinave virtuale me server DNS të parakonfiguruar.
- DNS si shërbim.
- Balancues i brendshëm i ngarkesës.
- Shtimi i një adrese IP «të bardhë» pa rikrijuar makinën virtuale.
Balancuesi dhe mundësia për të ndërruar adresën IP për një makinë virtuale të krijuar tashmë janë përfshirë në këtë listë me kërkesë të përdoruesve. Ta them sinqerisht, pa reagime të qarta nga ju, do t’u hynim këtyre funksioneve disi më vonë. Ndërkohë, tashmë po punojmë për detyrën që lidhet me adresat.
Fillimisht, adresa IP «e bardhë» mund të shtohej vetëm gjatë krijimit të makinës. Nëse përdoruesi harronte ta bënte këtë, makina virtuale duhej rikrijuar. E njëjta gjë ndodhte edhe kur duhej hequr IP-ja e jashtme. Së shpejti do të jetë e mundur të aktivizohet dhe çaktivizohet IP-ja publike pa rikrijuar makinën.
Mos hezitoni të ndani idetë tuaja dhe të mbështesni propozimet e përdoruesve të tjerë. Ju na ndihmoni ta bëjmë Cloud-in më të mirë dhe merrni më shpejt funksione të rëndësishme e të dobishme!
Burimi: habr.com
