![\"Kako](\"\/wp-content\/uploads\/2020\/02\/62b3d222c1911fb28a345defdd81135c.jpeg\")
<\/p>\n\u017divjo, moje ime je Kostja Kramlih, sem vodilni razvijalec oddelka Virtual Private Cloud pri Yandex.Cloud. Ukvarjam se z virtualnim omre\u017ejem in, kot lahko uganite, vam v tem \u010dlanku predstavim delovanje Virtual Private Cloud (VPC) na splo\u0161no ter virtualnega omre\u017eja posebej. Prav tako boste izvedeli, zakaj mi, razvijalci storitve, cenimo povratne informacije na\u0161ih uporabnikov. Ampak o vsem po vrsti.<\/p>\n
<\/p>\n
<\/a><\/p>\n Danes imamo na razpolago razli\u010dne mo\u017enosti za postavitev storitev. Prepri\u010dan sem, da nekdo \u0161e vedno dr\u017ei stre\u017enik pod mizo administratorja, \u010deprav upam, da tak\u0161nih zgodb postaja vse manj.<\/p>\n Danes se storitve trudijo preiti na javna oblaka, in prav tu naletijo na VPC. VPC je del javnega oblaka, ki povezuje uporabni\u0161ke, infrastrukturne, platformne in druge vire v eno celoto, kjer koli se nahajajo, v na\u0161em oblaku ali zunaj njega. Hkrati VPC omogo\u010da, da teh virov ni treba izpostavljati internetu, ostajajo znotraj va\u0161ega izoliranega omre\u017eja.<\/p>\n Pod VPC razumemo predvsem ovijalno omre\u017eje in omre\u017ene storitve, kot so VPNaaS, NATaas, LBaaS itd. In vse to deluje na vrhu odporninjske omre\u017ene infrastrukture, o kateri je bila \u017ee odli\u010dna \u010dlanek<\/a> tukaj, na Habr.<\/p>\n Poglejmo natan\u010dneje virtualno omre\u017eje in njegovo delovanje.<\/p>\n Oglejmo si dve dostopni coni. Nudimo virtualno omre\u017eje \u2013 to, kar smo poimenovali VPC. Dejansko dolo\u010da prostor edinstvenosti va\u0161ih 'sivih' naslovov. Znotraj vsakega virtualnega omre\u017eja v celoti upravljate s prostorom naslovov, ki jih lahko dodelite ra\u010dunalni\u0161kim virom.<\/p>\n Omre\u017eje je globalno. Hkrati se projicira v vsako od dostopnih con v obliki entitete, imenovane Subnet. Za vsako Subnet dodelite dolo\u010den CIDR z velikostjo 16 ali manj. V vsaki dostopni coni je lahko ve\u010d tak\u0161nih entitet, pri \u010demer je med njimi vedno prozoren usmerjevalnik. To pomeni, da se vsi va\u0161i viri znotraj enega VPC lahko 'pogovarjajo' med seboj, tudi \u010de se nahajajo v razli\u010dnih dostopnih conah. 'Pogovarjajo' se brez povezave na internet, preko na\u0161ih notranjih kanalov, \u2018mislijo\u010d\u2019, da se nahajajo znotraj ene zasebne mre\u017ee.<\/p>\n Na zgornjem diagramu je prikazana tipi\u010dna situacija: dva VPC, ki se nekje prekrivata po naslovih. Obe sta lahko v lasti vas. Na primer, ena za razvoj, druga \u2013 za testiranje. Morda so preprosto razli\u010dni uporabniki \u2013 v tem primeru to ni pomembno. In v vsako VPC je vgrajena ena virtualna naprava.<\/p>\n Zapletimo diagram. Lahko naredite tako, da se ena virtualna naprava priklju\u010di ve\u010d subnetom hkrati. In ne samo tako, ampak v razli\u010dnih virtualnih omre\u017ejih.<\/p>\n Pri tem, \u010de morate izpostaviti naprave na internet, to lahko storite preko API ali uporabni\u0161kega vmesnika. Za to je potrebno nastaviti NAT preusmerjanje va\u0161ega \u201esivega\u201c, notranjega naslova na \u201ebele\u201c, javne naslove. Izbrati \u201ebeli\u201c naslov ne morete, dodeljen je naklju\u010dno iz na\u0161ega sklada naslovov. Takoj ko prenehate uporabljati zunanji IP, se le-ta vrne v sklad. Pla\u010date samo za \u010das uporabe \u201ebelega\u201c naslova.<\/p>\n Obstaja tudi mo\u017enost, da napravi dovolite dostop do interneta preko NAT instanca. Na instanco lahko preusmerite promet preko stati\u010dne tabele usmerjanja. Predvideli smo tak\u0161no situacijo, ker jo uporabniki potrebujejo, in o tem vemo. Zato je v na\u0161em katalogu slik na voljo posebej konfiguriran NAT image.<\/p>\n Toda tudi ko je na voljo pripravljen NAT image, je nastavitev lahko zapletena. Zavedali smo se, da to za nekatere uporabnike ni najbolj priro\u010dna mo\u017enost, zato smo kon\u010dno omogo\u010dili vklju\u010ditev NAT za \u017eeleni subnet z enim klikom. Ta funkcionalnost je trenutno \u0161e v zaprtem predoglednem dostopu, kjer se testira s pomo\u010djo \u010dlanov skupnosti.<\/p>\n Kako uporabnik sodeluje z virtualnim omre\u017ejem? Omre\u017eje gleda zunaj s svojim API-jem. Uporabnik pride do API-ja in dela s ciljnim stanjem. Preko API-ja uporabnik vidi, kako bi moralo biti vse urejeno in nastavljeno, pri \u010demer vidi status, kako zelo dejansko stanje odstopa od \u017eelenega. To je slika uporabnika. Kaj pa se dogaja znotraj?<\/p>\n Zapisujemo \u017eeleno stanje v Yandex Database in gremo konfigurirati razli\u010dne dele na\u0161e VPC. Overlayska omre\u017eja v Yandex Cloud so zgrajena na osnovi izbranih komponent OpenContrail, ki se zdaj imenuje Tungsten Fabric. Omre\u017eni servisi so realizirani na enotni platformi CloudGate. V CloudGate smo prav tako uporabili nekaj odprtokodnih komponent: GoBGP \u2013 za dostop do nadzorne informacije, ter VPP \u2013 za implementacijo programske usmerjevalnika, ki deluje na DPDK za prenos podatkov.<\/p>\n Tungsten Fabric komunicira s CloudGate preko GoBGP. Pove, kaj se dogaja v overlayski mre\u017ei. CloudGate pa povezuje overlayske mre\u017ee med seboj in z internetom.<\/p>\n Sedaj si oglejmo, kako virtualna mre\u017ea re\u0161uje izzive skalabilnosti in razpolo\u017eljivosti. Razmislimo o preprostem primeru. Imamo eno dostopno cono in v njej sta ustvarjeni dve VPC. Namestili smo en instan\u010dni Tungsten Fabric, ki podpira ve\u010d deset tiso\u010d omre\u017eij. Omre\u017eja so povezana s CloudGate. CloudGate, kot smo \u017ee omenili, zagotavlja njihovo medsebojno povezljivost in povezavo z internetom.<\/p>\n Recimo, da dodamo drugo dostopno cono. Ta mora delovati povsem neodvisno od prve. Zato moramo v drugi dostopni coni namestiti lo\u010den instan\u010dni Tungsten Fabric. To bo lo\u010den sistem, ki se ukvarja z overlayskim omre\u017ejem in malo ve o prvem sistemu. Vidljivost na\u0161e virtualne mre\u017ee pa ustvarja na\u0161 VPC API. To je njegovo opravilo.<\/p>\n VPC1 se projicira v dostopno cono B, \u010de v dostopni coni B obstajajo viri, ki se priklju\u010dijo na VPC1. \u010ce v dostopni coni B ni virov iz VPC2, VPC2 v tej coni ne materializiramo. Hkrati, ker viri iz VPC3 obstajajo samo v coni B, VPC3 ni v coni A. Vse skupaj je preprosto in logi\u010dno.<\/p>\n Poglejmo nekoliko globlje, kako je organiziran konkretni gostitelj v Yandex Cloud. Glavna stvar, na katero \u017eelimo opozoriti, je, da so vsi gostitelji organizirani enako. Uredimo tako, da se na '\u017eelezu' vrti le nujna minimalna koli\u010dina storitev, vse ostale delujejo na virtualnim ma\u0161inama<\/a>. Gradimo storitve vi\u0161jega reda na osnovi osnovnih infrastrukturnih storitev in prav tako uporabljamo oblak za re\u0161evanje nekaterih in\u017eenirskih nalog, na primer v okviru Continuous Integration.<\/p>\n \u010ce pogledamo konkreten gostitelj, bomo videli, da v operacijskem sistemu gostitelja delujejo trije komplementarni elementi:<\/p>\n Poleg tega so virtualnim ma\u0161inama<\/a> zagnane storitve: infrastrukturne storitve oblaka, platformne storitve in zmogljivosti naro\u010dnikov. Zmogljivosti naro\u010dnikov in platformne storitve vedno delujejo v ovireh prek VRouterja.<\/p>\n Infrastrukturne storitve se lahko pove\u017eejo v ovire, vendar obi\u010dajno \u017eelijo delovati prav v podlagi. V podlago se povezujejo s pomo\u010djo SR-IOV. Dejstvo je, da delimo kartico na virtualne mre\u017ene kartice (virtualne funkcije) in jih vstavimo v infrastrukturne virtualne naprave, da ne izgubimo zmogljivosti. Na primer, ta znani CloudGate je zagnan kot ena izmed takih infrastrukturnih virtualnih naprav.<\/p>\n Zdaj, ko smo opisali globalne naloge virtualne mre\u017ee in strukturo osnovnih komponent oblaka, poglejmo, kako natan\u010dno razli\u010dni deli virtualne mre\u017ee medsebojno delujejo.<\/p>\n V na\u0161em sistemu izlo\u010damo tri plasti:<\/p>\n Kot sem \u017ee omenjal zgoraj, vse za\u010dne s tem, da uporabnik ali notranja platformna storitev dostopa do API in opisuje dolo\u010deno ciljno stanje.<\/p>\n To stanje takoj zapi\u0161e v Yandex Database, vrne preko API ID asinhrone operacije in za\u017eene na\u0161o interno mehanizacijo, da pridobi stanje, ki ga je \u017eelel uporabnik. Konfiguracijske naloge gredo v SDN-controller in sporo\u010dijo Tungsten Fabricu, kaj je treba storiti v ovireh. Na primer, rezervirajo vrata, virtualne mre\u017ee in podobno.<\/p>\n Config Plane v Tungsten Fabric prena\u0161a v Control Plane zahtevano stanje. Preko njega se Config Plane komunikira z gostitelji, pripoveduje, kaj to\u010dno se bo kmalu izvajalo na njih.<\/p>\n Zdaj poglejmo, kako izgleda sistem na gostiteljih. V virtualni napravi<\/a> Obstaja nek adapter za omre\u017eje, ki je priklju\u010den na VRouter. VRouter je jedrski modul Tungsten Fabric, ki gleda na pakete. \u010ce za dolo\u010den paket \u017ee obstaja flow, ga modul obdeluje. \u010ce flow ne obstaja, modul izvede tako imenovani punting, kar pomeni, da paket po\u0161lje v uporabni\u0161ki proces. Proces raz\u010dleni paket in bodisi sam odgovori nanj, kot na primer pri DHCP in DNS, bodisi pove VRouterju, kako ravnati s paketom. Po tem lahko VRouter obdeluje paket.<\/p>\n Nato promet med virtualnimi stroji znotraj ene virtualne mre\u017ee poteka transparentno in ni usmerjen na CloudGate. Storitve, na katerih so razporejeni virtualni stroji, med seboj neposredno komunicirajo. Tunelirajo promet in ga prena\u0161ajo drug drugemu preko podlage.<\/p>\n Control Plane komunicira med seboj med obmo\u010dji dostopnosti prek BGP, kot z drugim usmerjevalnikom. Povedo, v katerem obmo\u010dju je katere stroje, da lahko virtualni stroji v enem obmo\u010dju neposredno komunicirajo z drugimi virtualnimi stroji.<\/p>\n Poleg tega Control Plane komunicira tudi z CloudGate. Podobno sporo\u010da, kje in katere virtualne naprave so aktivne ter katere so njihove naslove. To omogo\u010da usmerjanje zunanjega prometa na njih in prometa iz uravnove\u0161evalnikov.<\/p>\n Promet, ki zapu\u0161\u010da VPC, prispe na CloudGate, v data path, kjer ga hitro obdela VPP z na\u0161imi vti\u010dniki. Nato se promet po\u0161lje bodisi v druge VPC bodisi zunaj, v mejne usmerjevalnike, ki jih nastavljamo prek Control Plane samega CloudGate.<\/p>\n \u010ce povzamemo vse zgoraj navedeno v nekaj stavkih, lahko re\u010demo, da VPC v Yandex.Cloud re\u0161uje dve pomembni nalogi:<\/p>\n In da bi te naloge dobro re\u0161evali, je potrebno zagotavljati skalabilnost in odpornost na ravni notranje arhitekture, kar VPC tudi po\u010dne.<\/p>\n Postopoma VPC pridobiva funkcionalnosti, izvajamo nove mo\u017enosti, trudimo se izbolj\u0161ati nekatere zadeve za udobje uporabnikov. Nekatere ideje se obravnavajo in uvrstijo na seznam prioritet zaradi sodelovanja z na\u0161o skupnostjo.<\/p>\n Trenutno imamo pribli\u017eno tak seznam na\u010drtov za bli\u017enjo prihodnost:<\/p>\n Balansirnik i mogu\u0107nost prebacivanja IP adrese za ve\u0107 kreiranu virtuelnu ma\u0161inu uklju\u010deni su u ovu listu na zahtev korisnika. Da budem iskren, bez jasnih povratnih informacija, ne bismo se uhvatili u ko\u0161tac s tim funkcijama jo\u0161 neko vreme. Tako da ve\u0107 radimo na zadatku o adresama.<\/p>\n Prvobitno je \"beli\" IP adrese moglo dodati samo prilikom kreiranja ma\u0161ine. Ako bi korisnik zaboravio to da uradi, moralo bi se ponovo kreirati virtuelna ma\u0161ina. To isto va\u017ei i kada je potrebno ukloniti spolja\u0161nji IP. Uskoro \u0107e mo\u0107i da se uklju\u010di i isklju\u010di javni IP, bez ponovnog kreiranja ma\u0161ine.<\/p>\n Ne ustru\u010davajte se da izrazite svoje ideje i podr\u017eite predloge<\/a> drugih korisnika. Poma\u017eete nam da oblak postane bolji i br\u017ee dobijate va\u017ene i korisne funkcije!<\/p>\nKaj je VPC?<\/h2>\n
Kako virtualno omre\u017eje izgleda od zunaj<\/h2>\n
![\"Kako](\"\/wp-content\/uploads\/2020\/02\/073a0cbac0e733decd8a4e6ffd9570ff.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/b1b7a15912f9c7995663ab9943d473f1.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/73e872a4f6c3e19576db4e4980d62a45.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/cc4ab2c7553d63ef2636924df1575479.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/c2375fd6d0fb7b55ca55787adf505229.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/744ac3bdd2f388bab2597d6fe1519d76.jpeg\")
<\/p>\nKako deluje virtualno omre\u017eje od znotraj<\/h2>\n
![\"Kako](\"\/wp-content\/uploads\/2020\/02\/71cab3ae7f067f165a87e30c60559794.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/222d68fff4b9577f316c8642e846172e.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/4da02ba041dcd886eee212dd8998718c.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/4664bd03793ba394ceda1f8214fa2c16.jpeg\")
<\/p>\n\n
\n
![\"Kako](\"\/wp-content\/uploads\/2020\/02\/644cddfa8bce83a501bf4788a21f9588.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/c2c6e443c93f8dedc6a63e4bd3fd7042.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/2139361a9e1837c7bc7f156e8bc36d38.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/1247f20fa2a12f093d7f1d2361d48a02.jpeg\")
<\/p>\n![\"Kako](\"\/wp-content\/uploads\/2020\/02\/f70cd562220c7367e29597d8e8b62f81.jpeg\")
<\/p>\nNa\u010drti za bli\u017enjo prihodnost.<\/h2>\n
\n
\n