Tere, minu nimi on Kostya Kramlikh, olen Yandex.Cloudi virtuaalse privaatpilve divisjoni juhtiv arendaja. Olen virtuaalne võrgukasutaja ja nagu võite arvata, räägin selles artiklis virtuaalse privaatpilve (VPC) seadmest üldiselt ja konkreetselt virtuaalsest võrgust. Samuti saate teada, miks meie, teenuse arendajad, hindame oma kasutajatelt tagasisidet. Aga kõigepealt asjad kõigepealt.
Mis on VPC?
Tänapäeval on teenuste juurutamiseks palju erinevaid võimalusi. Kindlasti hoiab keegi ikka serverit administraatori laua all, kuigi loodan, et selliseid lugusid on vähem.
Nüüd püüavad teenused minna avalikesse pilvedesse ja siin põrkuvad nad kokku VPC-dega. VPC on osa avalikust pilvest, mis seob kasutaja, infrastruktuuri, platvormi ja muud võimsused kokku, olenemata nende asukohast, meie pilves või väljaspool seda. Samal ajal võimaldab VPC teil neid võimsusi mitte tarbetult Internetile avaldada, need jäävad teie isoleeritud võrku.
Kuidas virtuaalne võrk väljastpoolt välja näeb?
VPC all peame silmas eelkõige kattevõrku ja võrguteenuseid, nagu VPNaaS, NATaas, LBaas jne. Ja kõik see toimib tõrketaluvusega võrgutaristu peal, mis on juba olemas siin, Habrel.
Vaatame lähemalt virtuaalset võrku ja selle seadet.
Mõelge kahele saadavuse tsoonile. Pakume virtuaalset võrku – seda nimetasime VPC-ks. Tegelikult määrab see teie "hallide" aadresside unikaalsuse ruumi. Igas virtuaalses võrgus on teil täielik kontroll aadresside ruumi üle, mida saate arvutusressurssidele määrata.
Võrk on globaalne. Samal ajal projitseeritakse see igale saadavuse tsoonile olemi kujul nimega Subnet. Iga alamvõrgu jaoks määrate CIDR-i suurusega 16 või vähem. Igas saadavuse tsoonis võib olla rohkem kui üks selline olem ja nende vahel on alati läbipaistev marsruutimine. See tähendab, et kõik teie sama VPC ressursid saavad üksteisega "vestelda", isegi kui need asuvad erinevates saadavustsoonides. "Suhtlevad" ilma Interneti-juurdepääsuta, meie sisemiste kanalite kaudu, "mõeldes", et nad on samas privaatvõrgus.
Ülaltoodud diagramm näitab tüüpilist olukorda: kaks VPC-d, mis ristuvad kuskil aadressides. Mõlemad võivad olla teie omad. Näiteks üks arenduseks, teine testimiseks. Kasutajad võivad lihtsalt olla erinevad – antud juhul pole see oluline. Ja iga VPC-ga on ühendatud üks virtuaalne masin.
Teeme skeemi hullemaks. Saate seda teha nii, et üks virtuaalne masin on korraga kinni jäänud mitmesse alamvõrku. Ja mitte niisama, vaid erinevates virtuaalvõrkudes.
Samal ajal, kui teil on vaja masinad Internetiga kokku puutuda, saab seda teha API või kasutajaliidese kaudu. Selleks peate konfigureerima oma "halli" siseaadressi NAT-i tõlke "valgeks" - avalikuks. Te ei saa valida "valget" aadressi, see määratakse juhuslikult meie aadresside hulgast. Niipea, kui lõpetate välise IP-aadressi kasutamise, tagastatakse see basseini. Maksate ainult "valge" aadressi kasutamise aja eest.
Samuti on võimalik anda masinale juurdepääs Internetile, kasutades NAT-i eksemplari. Saate liiklust eksemplari suunata staatilise marsruutimistabeli kaudu. Oleme sellise juhtumi pakkunud, sest kasutajatel on seda mõnikord vaja ja me teame sellest. Sellest lähtuvalt sisaldab meie pildikataloog spetsiaalselt konfigureeritud NAT-pilti.
Kuid isegi siis, kui on olemas valmis NAT-pilt, võib seadistamine olla keeruline. Mõistsime, et mõne kasutaja jaoks pole see kõige mugavam valik, nii et lõpuks võimaldasime NAT-i soovitud alamvõrgu jaoks ühe klõpsuga lubada. See funktsioon on endiselt suletud eelvaate juurdepääsuga, kus seda testitakse kogukonna liikmete abiga.
Kuidas on virtuaalne võrk seestpoolt korraldatud
Kuidas kasutaja virtuaalse võrguga suhtleb? Veeb näeb oma API-ga väljapoole. Kasutaja tuleb API-sse ja töötab sihtolekuga. API kaudu näeb kasutaja, kuidas kõik peaks olema korraldatud ja konfigureeritud, samas näeb ta olekut, kui palju tegelik olek erineb soovitud olekust. See on kasutaja pilt. Mis sees toimub?
Kirjutame soovitud oleku Yandexi andmebaasi ja läheme oma VPC erinevaid osi konfigureerima. Yandex.Cloudi ülekattevõrk põhineb OpenContraili valitud komponentidel, mida hiljuti hakati nimetama Tungsten Fabriciks. Võrguteenused on juurutatud ühel CloudGate platvormil. CloudGate'is kasutasime ka mitmeid avatud lähtekoodiga komponente: GoBGP - juurdepääsu kontrolliteabele, samuti VPP - tarkvara ruuteri juurutamiseks, mis töötab andmetee jaoks DPDK peal.
Tungsten Fabric suhtleb CloudGate'iga GoBGP kaudu. Annab teada, mis toimub ülekattevõrgus. CloudGate omakorda ühendab ülekattevõrgud omavahel ja Internetiga.
Nüüd vaatame, kuidas virtuaalne võrk lahendab skaleerimise ja kättesaadavuse probleemid. Vaatleme lihtsat juhtumit. Olemas on üks kättesaadavustsoon ja selles luuakse kaks VPC-d. Juurutasime ühe Tungsten Fabricu eksemplari ja see tõmbab mitukümmend tuhat võrku. Võrgud suhtlevad CloudGate'iga. CloudGate, nagu me juba ütlesime, tagab nende ühenduvuse üksteisega ja Internetiga.
Oletame, et lisatakse teine kättesaadavustsoon. See peaks ebaõnnestuma täiesti sõltumatult esimesest. Seetõttu peame teises kättesaadavustsoonis installima eraldi volframkanga eksemplari. See on eraldi süsteem, mis tegeleb ülekattega ja teab vähe esimesest süsteemist. Ja nähtavus, et meie virtuaalne võrk on ülemaailmne, loob tegelikult meie VPC API. See on tema ülesanne.
VPC1 kaardistatakse saadavuse tsooniga B, kui saadavuse tsoonis B on ressursse, mis lükatakse VPC1-sse. Kui saadavuse tsoonis B pole VPC2 ressursse, siis me VPC2 selles tsoonis ei realiseeri. Kuna VPC3 ressursid on omakorda olemas ainult tsoonis B, siis VPC3 tsoonis A ei eksisteeri. Kõik on lihtne ja loogiline.
Läheme veidi sügavamale ja vaatame, kuidas konkreetne host Y.Cloudis töötab. Peamine asi, mida tahan märkida, on see, et kõik hostid on paigutatud ühtemoodi. Teeme selle nii, et riistvaras töötab ainult vajalik miinimum teenustest, kõik ülejäänud töötavad virtuaalmasinates. Ehitame kõrgema järgu teenuseid, mis põhinevad infrastruktuuri põhiteenustel, ning kasutame Pilve ka mõne insenertehnilise probleemi lahendamiseks, näiteks Continuous Integration raames.
Kui vaatame konkreetset hosti, näeme, et hosti OS-is töötab kolm komponenti:
- Arvuta – arvutiressursside jaotamise eest vastutav osa.
- VRouter on osa Tungsten Fabricust, mis korraldab ülekatte, st tunnelib pakette läbi aluskatte.
- VDiskid on salvestusruumi virtualiseerimise tükid.
Lisaks käivitatakse virtuaalmasinates teenused: pilvetaristu teenused, platvormiteenused ja kliendivõimsused. Kliendi võimsused ja platvormiteenused lähevad alati ülekattele VRouteri kaudu.
Infrastruktuuriteenused võivad kattekihi sisse jääda, kuid põhimõtteliselt tahavad nad aluskihis töötada. Need kleebitakse SR-IOV abil aluskatte sisse. Tegelikult lõikasime kaardi virtuaalseteks võrgukaartideks (virtuaalsed funktsioonid) ja lükkame need taristu virtuaalsetesse masinatesse, et jõudlust mitte kaotada. Näiteks käivitatakse sama CloudGate ühena neist infrastruktuuri virtuaalmasinatest.
Nüüd, kui oleme kirjeldanud virtuaalse võrgu globaalseid ülesandeid ja pilve põhikomponentide ülesehitust, vaatame, kuidas täpselt virtuaalvõrgu erinevad osad omavahel suhtlevad.
Eristame oma süsteemis kolme kihti:
- Config Plane – määrab süsteemi sihtoleku. Seda konfigureerib kasutaja API kaudu.
- Juhttasand – pakub kasutaja määratletud semantikat, st toob andmetasandi oleku sellisele tasemele, nagu kirjeldas kasutaja konfiguratsioonitasandil.
- Data Plane – töötleb otse kasutaja pakette.
Nagu ma eespool ütlesin, algab kõik sellest, et kasutaja või siseplatvormi teenus tuleb API-sse ja kirjeldab teatud sihtolekut.
See olek kirjutatakse kohe Yandexi andmebaasi, tagastab API kaudu asünkroonse toimingu ID ja käivitab meie sisemise masinavärgi, et tagastada kasutaja soovitud olek. Konfiguratsiooniülesanded lähevad SDN-kontrollerile ja ütlevad Tungsten Fabricule, mida ülekattes teha. Näiteks reserveerivad nad pordid, virtuaalsed võrgud jms.
Volframkanga konfiguratsioonitasand saadab vajaliku oleku juhttasandile. Selle kaudu suhtleb Config Plane hostidega, rääkides, mis neil täpselt varsti keerlema hakkab.
Nüüd vaatame, kuidas süsteem hostides välja näeb. Virtuaalsel masinal on VRouterisse ühendatud võrguadapter. VRouter on volframkanga põhimoodul, mis vaatab pakette. Kui mõne paketi jaoks on voog juba olemas, töötleb moodul seda. Kui voogu pole, teeb moodul nn puntimise ehk saadab paketi usermod protsessi. Protsess parsib paketti ja vastab sellele ise, nagu DHCP ja DNS, või ütleb VRouterile, mida sellega teha. Pärast seda saab VRouter paketti töödelda.
Lisaks käib liiklus sama virtuaalvõrgu virtuaalmasinate vahel läbipaistvalt, seda ei suunata CloudGate'i. Hostid, millel virtuaalsed masinad on juurutatud, suhtlevad üksteisega otse. Nad tunneldavad liiklust ja edastavad selle üksteise jaoks läbi aluskatte.
Juhttasandid suhtlevad üksteisega kättesaadavustsoonide vahel BGP kaudu, nagu ka teise ruuteriga. Nad ütlevad, millised masinad kus on üleval, et ühes tsoonis asuvad virtuaalsed masinad saaksid teiste VM-idega otse suhelda.
Ja Control Plane suhtleb CloudGate'iga. Samamoodi annab see teada, kus ja millised virtuaalmasinad on üles ehitatud, millised aadressid neil on. See võimaldab suunata välist liiklust ja liiklust tasakaalustajatelt neile.
VPC-st väljuv liiklus jõuab CloudGate’i andmeteele, kus meie pistikprogrammidega VPP kiiresti ära näritakse. Seejärel suunatakse liiklus kas teistele VPC-dele või väljapoole, piirimarsruuteritele, mis on konfigureeritud CloudGate'i juhtimistasandi kaudu.
Lähituleviku plaanid
Kui võtame kõik ülaltoodud mõne lausega kokku, võime öelda, et VPC Yandex.Cloudis lahendab kaks olulist ülesannet:
- Pakub isolatsiooni erinevate klientide vahel.
- Ühendab ressursid, infrastruktuuri, platvormiteenused, muud pilved ja kohapealsed ühte võrku.
Ja selleks, et neid probleeme hästi lahendada, peate tagama mastaapsuse ja tõrketaluvuse sisemise arhitektuuri tasemel, mida VPC teeb.
Tasapisi omandab VPC funktsioone, juurutame uusi funktsioone, proovime midagi kasutajamugavuse osas paremaks muuta. Mõned ideed kõlavad ja satuvad prioriteetide nimekirja tänu meie kogukonna liikmetele.
Meil on praegu järgmine lähituleviku plaanide nimekiri:
- VPN kui teenus
- Privaatsed DNS-i eksemplarid on kujutised virtuaalsete masinate kiireks seadistamiseks eelkonfigureeritud DNS-serveriga.
- DNS kui teenus.
- Sisemine koormuse tasakaalustaja.
- "Valge" IP-aadressi lisamine ilma virtuaalmasinat uuesti loomata.
Tasakaalustaja ja juba loodud virtuaalmasina IP-aadressi vahetamise võimalus olid selles loendis kasutajate soovil. Ausalt öeldes oleksime ilma otsese tagasisideta võtnud need funktsioonid enda kanda veidi hiljem. Ja nii me juba tegeleme aadresside probleemiga.
Esialgu sai "valge" IP-aadressi lisada ainult masina loomisel. Kui kasutaja unustas seda teha, tuli virtuaalmasin uuesti luua. Sama ja vajadusel eemalda väline IP. Peagi on võimalik avalikku IP-d sisse ja välja lülitada, ilma et peaks masinat uuesti looma.
Väljendage julgelt oma teised kasutajad. Aitate meil pilve paremaks muuta ning olulisi ja kasulikke funktsioone kiiremini hankida!
Allikas: www.habr.com