Tere, minu nimi on Kostja Kramlih, olen Yandex.Cloudi Virtuaalse Eraklubi arenduse juht. Tegelen virtuaalse võrguga ja nagu võite arvata, räägin selles artiklis Virtuaalse Eraklubi (VPC) toimimisest üldiselt ja virtuaalsest võrgust spetsiifiliselt. Samuti saate teada, miks me, teenuse arendajad, hindame tagasisidet meie kasutajatelt. Aga kõigest järgemööda.
Mis on VPC?
Tänapäeval on teenuste käivitamiseks palju erinevaid võimalusi. Olen kindel, et keegi hoiab endiselt serverit administraatori laua all, kuigi loodan, et selliseid lugusid jääb järjest vähemaks.
Praegu püüdlevad teenused avalikkusesse pilvedesse ja just seal nad puutuvad VPC-ga kokku. VPC on osa avalikust pilvest, mis ühendab kasutajate, infrastruktuuri, platvormi ja muid ressurssi olenemata nende asukohast, meie pilves või väljaspool seda. Samuti võimaldab VPC neid ressursse internetti mittavälja näidata, need jäävad teie isoleeritud võrku.
Kuidas näeb virtuaalne võrk välja väljastpoolt
VPC all mõistame eelkõige katvust ja võrguteenuseid nagu VPNaaS, NATaas, LBaas jne. Ja kõik see töötab usaldusväärse võrgu infrastruktuuri peal, millest on juba juttu olnud suurepärane artikkel siin, Habr'is.
Vaatame virtuaalset võrku ja selle ülesehitust lähemalt.
Vaatame kaht kättesaadavuse tsooni. Pakume virtuaalset võrgulahendust – seda, mida nimetame VPC-ks. Tegelikult määratleb see teie "hallide" aadresside ainulaadsuse ruumi. Igas virtuaalses võrgus juhite täielikult aadresside ruumi, mida võite määrata arvutusressurssidele.
Võrk on globaalne. Samuti projitseeritakse see kõigile kättesaadavuse tsoonidele Subneti nime all. Iga Subneti jaoks määrate mingi CIDR suurusega 16 või vähem. Igas kättesaadavuse tsoonis võib olla rohkem kui üks selline üksus, olles samas alati läbipaistva marsruudiga. See tähendab, et kõik teie ressursid ühe VPC piires saavad omavahel "suhelda", isegi kui nad asuvad erinevates kättesaadavuse tsoonides. "Suhelda" ilma internetti sisenemata, meie sisekanaleid pidi, "mõeldes", et nad asuvad ühes privaatvõrgus.
Ülaltoodud skeem näitab tüüpilist olukorda: kaks virtuaalset privaatvõrku (VPC), mis asuvad aadresside poolest osaliselt kattuvad. Mõlemad võivad kuuluda teile. Näiteks üks arenduseks, teine testimiseks. Need võivad olla ka lihtsalt erinevad kasutajad - sel juhul pole see oluline. Ja iga VPC-s on üks virtuaalmasin.
Skeemi keerulisemaks muutmiseks on võimalik seadistada nii, et üks virtuaalmasin oleks ühendatud mitme alamvõrguga. Ja mitte lihtsalt, vaid erinevates virtuaalsetes võrkudes.
Kui teil on vaja masinaid internetti suunata, saate seda teha läbi API või kasutajaliidese. Selleks on vajalik seadistada NAT-ülevaade teie „hall“ sisemine aadress avalikuks „valgeks“ aadressiks. Te ei saa valida „valget“ aadressi, see määratakse juhuslikult meie aadresside hulgast. Kui te enam ei kasuta väliseid IP-aadresse, tagastatakse need tagasi hulka. Te maksate ainult „valge“ aadressi kasutamise aja eest.
Samuti on võimalik anda masinale interneti ligipääs NAT-instrumendi abil. Trafficit saab suunata läbi staatilise marsruutimise tabeli. Oleme sellise juhtumi jaoks ette näinud lahenduse, kuna teame, et see on mõnedele kasutajatele vajalik. Seega on meie pildikataloogis spetsiaalselt konfigureeritud NAT-pilt.
Kuid isegi kui NAT-pilt on olemas, võib seadistamine olla keeruline. Me mõistsime, et see ei ole mõne kasutaja jaoks kõige mugavam valik, seetõttu tegime lõpuks võimaluse lubada NAT soovitud alamvõrgus ühe klõpsuga. See funktsioon on praegu veel suletud eelvaates, kus seda testitakse kogukonna liikmete abil.
Kuidas virtuaalne võrk seestpoolt toimib
Kuidas kasutaja virtuaalse võrguga suhtleb? Võrk vaatab väljapoole oma API kaudu. Kasutaja külastab API-d ja töötab sihtolekuga. API kaudu näeb kasutaja, kuidas kõik peaks olema seadistatud ja korraldatud, samal ajal kui ta näeb olekut, kui palju tegelik seisukord erineb soovitud seisundist. See on kasutaja pilt. Mis toimub sees?
Me salvestame soovitud oleku Yandex Database'i ja läheme konfigureerima erinevaid osi meie VPC-st. Ülekatte võrgustik Yandex.Cloudis on üles ehitatud valitud komponentidele OpenContrail, mis viimasel ajal kannab nime Tungsten Fabric. Võrguteenuseid pakutakse ühel platvormil CloudGate. CloudGate'is kasutasime ka mõningaid avatud lähtekoodiga komponente: GoBGP kontrollinformatsiooni saamiseks ja VPP programmihalduri teostamiseks, mis töötab DPDK peal andmepath'i jaoks.
Tungsten Fabric suhtleb CloudGate'iga läbi GoBGP. See selgitab, mis meie ülekatte võrgus toimub. CloudGate omakorda seob ülekatte võrgud üksteisega ja internetiga.
Nüüd vaatame, kuidas virtuaalne võrk lahendab skaleerimise ja kättesaadavuse probleeme. Vaatame lihtsat juhtumit. On üks kättesaadavusala ja seal on loodud kaks VPC-d. Me oleme juurinud ühe Tungsten Fabric'i instantsi, mis haldab mitu kümmet tuhat võrgustikku. Võrgud on seotud CloudGate'iga. CloudGate, nagu juba ütlesime, tagab nende omavahelise ja interneti vahelise ühenduse.
Oletame, et lisandub teine kättesaadavusala. See peab olema täiesti sõltumatu esimesest. Seega peame teises kättesaadavusalas seadma eraldi Tungsten Fabric'i instantsi. See on eraldi süsteem, mis tegeleb ülekattega ja teab vähe esimese süsteemi kohta. Ja just see, et meie virtuaalne võrk on globaalne, loob meie VPC API. See on tema ülesanne.
VPC1 projektiitub kättesaadavusala B, kui kättesaadavusala B-s on ressursid, mis on ühendatud VPC1-ga. Kui kättesaadavusala B-s pole VPC2 ressursse, ei materialiseeri VPC2 selles alas. Omakorda, kuna VPC3 ressursid eksisteerivad ainult alal B, ei ole VPC3 alal A. Kõik on lihtne ja loogiline.
Vaatame nüüd natuke lähemalt, kuidas konkreetne host on korraldatud Yandex.Cloudis. Peamine, mida tahaksin märkida, on see, et kõik hostid on üles ehitatud ühtemoodi. Me teeme nii, et ainult vajalik minimaalne teenuste hulk töötab "rauda" peal, kõik teised toimivad virtuaalmasinaid. Me ehitame kõrgema taseme teenuseid põhitehnilise infrastruktuuri teenuste baasil ning kasutame Pilve, et lahendada mõningaid insenerimisprobleeme, näiteks pideva integreerimise raames.
Kui vaatame konkreetset hosti, näeme, et hosti operatsioonisüsteemis töötavad kolm komponenti:
- Compute – osa, mis vastutab arvutusressursside jaotamise eest hostis.
- VRouter – osa Tungsten Fabricist, mis korraldab ülekatte, st tunnelib pakette läbi aluskihi (underlay).
- VDisk – need on virtualiseerimise salvestuse tükid.
Lisaks on virtuaalmasinaid käivitatud teenused: infrastruktuuri teenused Pilves, platvormiteenused ja klientide võimsused. Klientide võimsused ja platvormiteenused kulgevad alati ülekatte kaudu VRouteri kaudu.
Infrastruktuuri teenused võivad ühendada ülekattega, kuid soovivad peamiselt töötada just aluskihis. Aluskihis ühendavad nad end SR-IOV kaudu. Tegelikult lõikame kaardi virtuaalseteks võrgu kaartideks (virtuvaalsed funktsioonid) ja sisestame need infrastruktuuri virtuaalmasinatesse, et mitte kaotada jõudlust. Näiteks on sama CloudGate käivitatud ühe sellise infrastruktuuri virtuaalmasina kujul.
Nüüd, kui oleme kirjeldanud virtuaalse võrgu globaalseid ülesandeid ja pilve põhikomponentide ülesehitust, vaatame, kuidas erinevad virtuaalse võrgu osad omavahel suhtlevad.
Me eraldame oma süsteemis kolm kihti:
- Config Plane – määrab süsteemi sihtoleku. See on see, mida konfigureerib kasutaja API kaudu.
- Control Plane – tagab kasutaja määratud semantika, st viib Data Plane'i seisundi selliseks, nagu see oli määratud Config Plane'is.
- Data Plane – töötleb kasutaja pakette otse.
Kuidas ma juba eespool mainisin, kõik algab sellest, et kasutaja või sisemine platvormiteenus pöördub API poole ja kirjeldab teatud sihtolekut.
See olek salvestatakse kohe Yandex Database'i, tagastab API kaudu asünkroonse operatsiooni ID ja käivitab meie sisemise mehhanismi, et anda kasutaja soovitud olek. Konfigureerimisülesanded lähevad SDN-kontrollerisse ja ütlevad Tungsten Fabricile, mida on vaja teha ülekatte kaudu. Näiteks broneerivad nad porte, virtuaalvõrke ja nii edasi.
Config Plane Tungsten Fabricis edastab Control Plane'i vajalikku olekut. Selle kaudu suhtleb Config Plane hostidega, öeldes neile, mis täpselt neis peagi tööle hakkab.
Nüüd vaatame, milline süsteem hostides välja näeb. V virtuaalses masinas on olemas võrgukaart, mis on ühendatud VRouteriga. VRouter on Tungsten Fabriku tuumamoodul, mis jälgib pakette. Kui mingil paketil on juba flow, siis töötleb moodul seda. Kui flow-d ei ole, siis teeb moodul nii nimetatud punting'i, saates paketi kasutajarežiimi protsessi. Protsess analüüsib paketti ja kas vastab sellele ise, näiteks DHCP ja DNS-i puhul, või ütleb VRouterile, mida selle paketiga teha. Pärast seda saab VRouter paketti töödelda.
Edasi liigub liiklus virtuaalmasinate vahel ühe virtuaalvõrgu piires läbipaistvalt, see ei suunata CloudGate'i. Hostid, millel virtuaalmasinad on juurutatud, suhtlevad omavahel otse. Nad tunnelivad liiklust ja edastavad seda üksteisele läbi aluse.
Control Plane suhtleb omavahel kättesaadavuse tsoonides BGP kaudu, nagu teise ruutijaga. Nad teatavad, millised masinad on kus üles tõstetud, nii et virtuaalmasinad ühes tsoonis saaksid otse suhelda teiste virtuaalmasinatega.
Ja Control Plane suhtleb ka CloudGate'iga. Samuti teatab, kus ja millised virtuaalmasinad on üles tõstetud ja millised on nende aadressid. See võimaldab suunata nendele välist liiklust ja liiklust tasakaalustajatelt.
Liiklus, mis väljub VPC-st, jõuab CloudGate'i, andmete teele, kus VPP koos meie pistikutega kiiresti töötleb. Edasi suunatakse liiklus kas teistesse VPC-desse või väljapoole, piiriruutijatele, mis konfigureeritakse CloudGate'i Control Plane'i kaudu.
Plaane lähitulevikuks
Kokkuvõtlikult võib öelda, et VPC Yandex.Cloudis lahendab kaks olulist ülesannet:
- Tagab isolatsiooni erinevate klientide vahel.
- Kombineerib ressursid, infrastruktuuri, platvormiteenused, teised pilved ja kohapealsed teenused ühtseks võrguks.
Ja et neid ülesandeid hästi lahendada, tuleb tagada skaleeritavus ja talitlushäireteta toimimine sisemise arhitektuuri tasemel, mida VPC ka teeb.
Aja jooksul VPC rikastub funktsioonidega, rakendame uusi võimalusi ja püüame pidevalt midagi kasutajate mugavuse osas parandada. Mõned ideed sõnastatakse ja jõuavad prioriteetide nimekirja meie kogukonna liikmete kaudu.
Praegu on meil umbes selline plaanide nimekiri lähitulevikuks:
- VPN nagu teenus.
- Privaat DNS instantsid – pildid kiireks virtuaalsete masinate seadistamiseks koos eelkonfigureeritud DNS-serveriga.
- DNS teenusena.
- Sisemine koormuse tasakaalustaja.
- Valge IP-aadressi lisamine ilma virtuaalse masina uuesti loomata.
Koormuse tasakaalustaja ja võimalus vahetada IP-aadressi juba loodud virtuaalmaja jaoks said sellele nimekirjale kasutajate päringu tõttu. Pean tunnistama, et ilma selgete tagasisideteta oleksime nende funktsioonide kallal töötamisega mõnevõrra hiljem alustanud. Nüüd töötame juba ülesande kallal aadresside osas.
Alguses sai valge IP-aadressi lisada ainult masina loomise hetkel. Kui kasutaja unustas seda teha, tuli virtuaalne masin uuesti luua. Sama kehtib ka välishi ning eemaldamise vajaduse korral. Peagi saab avalikku IP-d sisse ja välja lülitada ilma masinat uuesti loomata.
Ärge kartke jagada oma ideid ja toetada teiste kasutajate ettepanekuid. Aitate meil muuta Pilve paremaks ja saate kiiremini olulisi ja kasulikke funktsioone! Tere, minu nimi on Kostja Kramlih, olen Jandexi Pilve Virtuaalse Erasektori juhtiv arendaja.
Allikas: habr.com
