Kaixo, nire izena Kostya Kramlikh da, Yandex.Cloud-en Virtual Private Cloud dibisioaren garatzaile nagusia naiz. Sare birtuala naiz, eta asmatuko duzuen bezala, artikulu honetan Virtual Private Cloud (VPC) gailuari buruz hitz egingo dut orokorrean eta bereziki sare birtualaz. Eta guk, zerbitzuaren garatzaileek, gure erabiltzaileen iritzia zergatik baloratzen dugun ere jakingo duzu. Baina lehenik eta behin.
Zer da VPC?
Gaur egun, hainbat aukera daude zerbitzuak zabaltzeko. Ziur nago oraindik norbaitek zerbitzaria administratzailearen mahaiaren azpian mantentzen duela, nahiz eta espero dudan horrelako istorio gutxiago egotea.
Orain zerbitzuak hodei publikoetara joaten saiatzen ari dira, eta hemen talka egiten dute VPCekin. VPC erabiltzailea, azpiegitura, plataforma eta beste gaitasun batzuk lotzen dituen hodei publiko baten zati bat da, edozein lekutan dauden, gure hodeian edo hortik kanpo. Aldi berean, VPC-k ahalmen hauek Internetera alferrik ez erakusteko aukera ematen du, zure sare isolatuan geratzen dira.
Nolakoa da sare birtual bat kanpotik?
VPC-ri dagokionez, batez ere gainjarritako sare bat eta sareko zerbitzuak esan nahi ditugu, hala nola VPNaaS, NATaas, LBaas, etab. Eta honek guztiak hutsegite-tolerantzia duten sare-azpiegitura baten gainean funtzionatzen du, zeina dagoeneko izan dena. hemen, HabrΓ©-n.
Ikus ditzagun sare birtuala eta bere gailua gertutik.
Demagun bi erabilgarritasun-zona. Sare birtual bat eskaintzen dugu - VPC deitu genuena. Izan ere, zure helbide "gris"en berezitasunaren espazioa definitzen du. Sare birtual bakoitzaren barruan, konputazio-baliabideei esleitu ditzakezun helbideen espazioaren kontrol osoa duzu.
Sarea globala da. Aldi berean, erabilgarritasun-eremu bakoitzean proiektatzen da Subsare izeneko entitate baten moduan. Azpisare bakoitzeko, 16 tamainako edo gutxiagoko CIDR bat esleitzen duzu. Erabilgarritasun-eremu bakoitzean horrelako entitate bat baino gehiago egon daiteke, eta haien artean bideratze gardena dago beti. Horrek esan nahi du VPC bereko baliabide guztiek elkarren artean "hitz egin" dezaketela, erabilgarritasun-gune desberdinetan egon arren. "Komunikatu" Internetera sartu gabe, gure barne-kanaletatik, sare pribatu beraren barruan daudela "pentsatuz".
Goiko diagramak egoera tipiko bat erakusten du: helbideetan nonbait gurutzatzen diren bi VPC. Biak zureak izan daitezke. Adibidez, bat garatzeko, bestea probak egiteko. Baliteke erabiltzaile desberdinak egotea, kasu honetan ez du axola. Eta makina birtual bat konektatzen da VPC bakoitzean.
Egin dezagun eskema okerrago. Makina birtual bat hainbat azpisaretan aldi berean itsatsita egon dadin egin dezakezu. Eta ez horrela bakarrik, sare birtual ezberdinetan baizik.
Aldi berean, makinak Internetera erakutsi behar badituzu, hau API edo UI bidez egin daiteke. Horretarako, zure "grisa" barruko helbidearen NAT itzulpena "zuria" - publikoa konfiguratu behar duzu. Ezin duzu helbide "zuria" aukeratu, gure helbide multzotik ausaz esleitzen da. Kanpoko IP erabiltzeari utzi bezain laster, igerilekura itzultzen da. Helbide "zuria" erabiltzeko denbora baino ez duzu ordaintzen.
Gainera, makinari Interneterako sarbidea ematea posible da NAT instantzia baten bidez. Trafikoa instantzia batera bidera dezakezu bideratze-taula estatiko baten bidez. Halako kasua eman dugu, erabiltzaileek batzuetan behar dutelako, eta badakigu. Horren arabera, gure irudien katalogoak bereziki konfiguratutako NAT irudi bat dauka.
Baina NAT irudia prest dagoenean ere, konfigurazioa zaila izan daiteke. Ulertu genuen erabiltzaile batzuentzat hau ez dela aukerarik erosoena, beraz, azkenean, nahi duzun Azpisarerako NAT gaitzea posible egin dugu klik bakarrean. Ezaugarri hau aurrebista sarbide itxian dago oraindik, non komunitateko kideen laguntzarekin probatzen den.
Nola antolatzen den sare birtuala barrutik
Nola eragiten du erabiltzaileak sare birtualarekin? Webak kanpora begiratzen du bere APIarekin. Erabiltzailea APIra dator eta xede-egoerarekin lan egiten du. APIaren bidez, erabiltzaileak dena nola antolatu eta konfiguratu behar den ikusten du, egoera ikusten duen bitartean, benetako egoera nahi denarekiko zenbat desberdintzen den. Hau erabiltzailearen argazkia da. Zer gertatzen da barruan?
Yandex datu-basean nahi duzun egoera idazten dugu eta gure VPCren zati desberdinak konfiguratzera joaten gara. Yandex.Cloud-en gainjartze-sarea OpenContrail-en osagai hautatuetan oinarritzen da, duela gutxi Tungsten Fabric deitu dena. Sare zerbitzuak CloudGate plataforma bakarrean ezartzen dira. CloudGate-n, kode irekiko osagai batzuk ere erabili ditugu: GoBGP - kontrol-informazioa atzitzeko, baita VPP - datu-biderako DPDKren gainean exekutatzen den software-bideratzaile bat ezartzeko.
Tungsten Fabric CloudGate-rekin komunikatzen da GoBGP bidez. Gainjartze sarean zer gertatzen den kontatzen du. CloudGate, gainjarritako sareak elkarren artean eta Internetekin konektatzen ditu.
Orain ikus dezagun nola konpontzen dituen sare birtual batek eskalatzeko eta erabilgarritasun arazoak. Azter dezagun kasu sinple bat. Eskuragarritasun eremu bat dago eta bi VPC sortzen dira bertan. Tungsten Fabric-en instantzia bat zabaldu dugu, eta hainbat hamarnaka sare ateratzen ditu. Sareak CloudGaterekin komunikatzen dira. CloudGate-k, lehen esan dugunez, elkarren artean eta Internetekin duten konexioa bermatzen du.
Demagun bigarren erabilgarritasun-eremu bat gehitzen dela. Lehenengoaren guztiz independentean huts egin beharko luke. Hori dela eta, bigarren erabilgarritasun eremuan, Tungsten Fabric instantzia bereizi bat instalatu behar dugu. Gainjartzeaz arduratzen den eta lehenengo sistemari buruz ezer gutxi dakien sistema bereizia izango da hau. Eta gure sare birtuala globala den ikusgarritasunak, hain zuzen ere, gure VPC APIa sortzen du. Hau da bere zeregina.
VPC1 B Eskuragarritasun Zonan mapatzen da B Eskuragarritasun Zonan VPC1era bidaltzen diren baliabideak badaude. B erabilgarritasun eremuan VPC2 baliabiderik ez badago, ez dugu eremu honetan VPC2 gauzatuko. Aldiz, VPC3-ko baliabideak B eremuan soilik existitzen direnez, VPC3 ez da A eremuan existitzen. Dena sinplea eta logikoa da.
Goazen pixka bat sakondu eta ikus dezagun Y.Cloud-eko ostalari jakin batek nola funtzionatzen duen. Kontuan izan nahi dudan gauza nagusia da ostalari guztiak modu berean antolatuta daudela. Beharrezko gutxieneko zerbitzuak hardwarean bakarrik exekutatzen direla egiten dugu, gainerako guztiak makina birtualetan exekutatzen direla. Oinarrizko azpiegitura zerbitzuetan oinarritutako goi mailako zerbitzuak eraikitzen ditugu, eta Hodeia ere erabiltzen dugu ingeniaritza arazo batzuk konpontzeko, adibidez, Etengabeko Integrazioaren esparruan.
Ostalari zehatz bati begiratzen badiogu, ikus dezakegu hiru osagai daudela ostalari OSan exekutatzen:
- Konputazioa - ostalariaren baliabide informatikoen banaketaz arduratzen den zatia.
- VRouter Tungsten Fabric-aren zati bat da, gainjarri bat antolatzen duena, hau da, paketeak azpiko geruza baten bidez tunelatzen ditu.
- VDisk biltegiratze birtualizazio zatiak dira.
Horrez gain, zerbitzuak makina birtualetan abiarazten dira: Hodeiko azpiegitura zerbitzuak, plataforma zerbitzuak eta bezeroen gaitasunak. Bezeroen gaitasunak eta plataforma-zerbitzuak VRouter bidez gainjarrira doaz beti.
Azpiegitura-zerbitzuak gainjarrietan itsats daitezke, baina funtsean azpian lan egin nahi dute. SR-IOV-ren laguntzarekin azpiko geruza batean itsatsita daude. Izan ere, txartela sare birtualeko txarteletan ebakitzen dugu (funtzio birtualak) eta azpiegiturako makina birtualetara bultzatzen dugu errendimendua ez galtzeko. Adibidez, CloudGate bera abiarazten da azpiegiturako makina birtual horietako bat bezala.
Sare birtualaren zeregin globalak eta hodeiaren oinarrizko osagaien egitura deskribatu ditugunean, ikus dezagun sare birtualeko zati ezberdinek elkarren artean nola elkarreragiten duten zehazki.
Gure sisteman hiru geruza bereizten ditugu:
- Config Plane - sistemaren xede-egoera ezartzen du. Hau da erabiltzaileak APIaren bidez konfiguratzen duena.
- Kontrol-planoa - erabiltzaileak definitutako semantika eskaintzen du, hau da, Datu-planoaren egoera erabiltzaileak Konfigurazio-planoan deskribatu zuenera ekartzen du.
- Data Plane - zuzenean prozesatzen ditu erabiltzailearen paketeak.
Goian esan dudan bezala, dena hasten da erabiltzailea edo barne plataformako zerbitzua APIra iristen dela eta helburu-egoera jakin bat deskribatzen duela.
Egoera hau Yandex datu-basean idazten da berehala, APIaren bidez eragiketa asinkronoaren IDa itzultzen du eta gure barne makineria abiarazten du erabiltzaileak nahi zuen egoera itzultzeko. Konfigurazio-zereginak SDN kontrolagailura joaten dira eta Tungsten Fabrici gainjartzean zer egin behar duen esan. Adibidez, portuak, sare birtualak eta antzekoak erreserbatzen dituzte.
Tungsten Fabric-eko Config Plane-k beharrezko egoera bidaltzen du Kontrol-planora. Horren bidez, Config Plane ostalariekin komunikatzen da, laster zer biraka izango den esanez.
Orain ikus dezagun sistemak ostalarietan nola ikusten duen. Makina birtualak sare-egokigailu bat du VRouter-en konektatua. VRouter paketeei begiratzen dien Tungsten Fabric modulu nagusia da. Dagoeneko pakete batzuen fluxua badago, moduluak prozesatzen du. Fluxurik ez badago, moduluak punting delakoa egiten du, hau da, pakete bat bidaltzen du usermod prozesura. Prozesuak paketea analizatzen du eta berari erantzuten dio, DHCP eta DNS bezala, edo VRouteri esaten dio zer egin harekin. Horren ondoren, VRouterrek paketea prozesatu dezake.
Gainera, sare birtualeko makina birtualen arteko trafikoa garden doa, ez da CloudGate-ra bideratzen. Makina birtualak zabaltzen diren ostalariak zuzenean komunikatzen dira elkarren artean. Trafikoa tunelean jartzen dute eta elkarri bideratzen diote azpiko estalkitik.
Kontrol-hegazkinak erabilgarritasun-eremuen artean komunikatzen dira BGP bidez, beste bideratzaile batekin bezala. Zein makina dauden non dauden esaten dute, zona bateko VM-ak beste VM batzuekin zuzenean komunikatu ahal izateko.
Eta Control Plane CloudGate-rekin komunikatzen da. Era berean, non eta zein makina birtual planteatzen diren, zein helbide dituzten jakinarazten du. Horri esker, kanpoko trafikoa eta trafikoa orekatzaileetatik haietara bideratu ditzakezu.
VPCtik ateratzen den trafikoa CloudGate-ra dator, datu-bidera, non gure pluginekin VPP-a azkar murtxikatzen den. Ondoren, trafikoa beste VPC batzuetara edo kanpoaldera bideratzen da, CloudGate beraren Kontrol Planoaren bidez konfiguratutako mugako bideratzaileetara.
Etorkizun hurbilerako planak
Goian esandako guztia esaldi gutxitan laburbiltzen badugu, Yandex.Cloud-en VPC-k bi zeregin garrantzitsu konpontzen dituela esan dezakegu:
- Bezero ezberdinen arteko isolamendua eskaintzen du.
- Baliabideak, azpiegiturak, plataforma-zerbitzuak, beste hodeiak eta lokala sare bakarrean konbinatzen ditu.
Eta arazo hauek ondo konpontzeko, eskalagarritasuna eta akatsen tolerantzia eman behar duzu barne arkitekturaren mailan, VPC-k egiten duena.
Pixkanaka VPC-k funtzioak hartzen ditu, ezaugarri berriak ezartzen ditugu, erabiltzailearen erosotasunari dagokionez zerbait hobetzen saiatzen gara. Ideia batzuk ahoskatzen dira eta lehentasunen zerrendan sartzen dira gure komunitateko kideei esker.
Gaur egun, etorkizun hurbilerako planen zerrenda hau dugu:
- VPN zerbitzu gisa.
- DNS instantzia pribatuak aurrez konfiguratutako DNS zerbitzari batekin makina birtualak azkar konfiguratzeko irudiak dira.
- DNS zerbitzu gisa.
- Barne karga orekatzeko.
- IP helbide "zuria" gehitzea makina birtuala birsortu gabe.
Balantzailea eta dagoeneko sortutako makina birtual baten IP helbidea aldatzeko gaitasuna zerrenda honetan zeuden erabiltzaileek eskatuta. Egia esateko, iritzi espliziturik gabe, funtzio horiek pixka bat geroago hartuko genituzke. Eta, beraz, helbideen arazoa lantzen ari gara dagoeneko.
Hasieran, makina bat sortzean soilik gehitu zitekeen IP helbide "zuria". Erabiltzaileari hau egitea ahazten bazaio, makina birtuala birsortu behar zen. Berdin eta, behar izanez gero, kendu kanpoko IPa. Laster IP publikoa piztu eta itzali ahal izango da makina birsortu beharrik gabe.
Anima zaitez zurea adierazteko beste erabiltzaile batzuk. Hodeia hobetzen eta funtzio garrantzitsuak eta erabilgarriak azkarrago lortzen laguntzen diguzu!
Iturria: www.habr.com