Živjo, moje ime je Kostja Kramlih, sem vodilni razvijalec oddelka Virtual Private Cloud pri Yandex.Cloud. Ukvarjam se z virtualnim omrežjem in, kot lahko uganite, vam v tem članku predstavim delovanje Virtual Private Cloud (VPC) na splošno ter virtualnega omrežja posebej. Prav tako boste izvedeli, zakaj mi, razvijalci storitve, cenimo povratne informacije naših uporabnikov. Ampak o vsem po vrsti.
Kaj je VPC?
Danes imamo na razpolago različne možnosti za postavitev storitev. Prepričan sem, da nekdo še vedno drži strežnik pod mizo administratorja, čeprav upam, da takšnih zgodb postaja vse manj.
Danes se storitve trudijo preiti na javna oblaka, in prav tu naletijo na VPC. VPC je del javnega oblaka, ki povezuje uporabniške, infrastrukturne, platformne in druge vire v eno celoto, kjer koli se nahajajo, v našem oblaku ali zunaj njega. Hkrati VPC omogoča, da teh virov ni treba izpostavljati internetu, ostajajo znotraj vašega izoliranega omrežja.
Kako virtualno omrežje izgleda od zunaj
Pod VPC razumemo predvsem ovijalno omrežje in omrežne storitve, kot so VPNaaS, NATaas, LBaaS itd. In vse to deluje na vrhu odporninjske omrežne infrastrukture, o kateri je bila že odlična članek tukaj, na Habr.
Poglejmo natančneje virtualno omrežje in njegovo delovanje.
Oglejmo si dve dostopni coni. Nudimo virtualno omrežje – to, kar smo poimenovali VPC. Dejansko določa prostor edinstvenosti vaših 'sivih' naslovov. Znotraj vsakega virtualnega omrežja v celoti upravljate s prostorom naslovov, ki jih lahko dodelite računalniškim virom.
Omrežje je globalno. Hkrati se projicira v vsako od dostopnih con v obliki entitete, imenovane Subnet. Za vsako Subnet dodelite določen CIDR z velikostjo 16 ali manj. V vsaki dostopni coni je lahko več takšnih entitet, pri čemer je med njimi vedno prozoren usmerjevalnik. To pomeni, da se vsi vaši viri znotraj enega VPC lahko 'pogovarjajo' med seboj, tudi če se nahajajo v različnih dostopnih conah. 'Pogovarjajo' se brez povezave na internet, preko naših notranjih kanalov, ‘mislijoč’, da se nahajajo znotraj ene zasebne mreže.
Na zgornjem diagramu je prikazana tipična situacija: dva VPC, ki se nekje prekrivata po naslovih. Obe sta lahko v lasti vas. Na primer, ena za razvoj, druga – za testiranje. Morda so preprosto različni uporabniki – v tem primeru to ni pomembno. In v vsako VPC je vgrajena ena virtualna naprava.
Zapletimo diagram. Lahko naredite tako, da se ena virtualna naprava priključi več subnetom hkrati. In ne samo tako, ampak v različnih virtualnih omrežjih.
Pri tem, če morate izpostaviti naprave na internet, to lahko storite preko API ali uporabniškega vmesnika. Za to je potrebno nastaviti NAT preusmerjanje vašega „sivega“, notranjega naslova na „bele“, javne naslove. Izbrati „beli“ naslov ne morete, dodeljen je naključno iz našega sklada naslovov. Takoj ko prenehate uporabljati zunanji IP, se le-ta vrne v sklad. Plačate samo za čas uporabe „belega“ naslova.
Obstaja tudi možnost, da napravi dovolite dostop do interneta preko NAT instanca. Na instanco lahko preusmerite promet preko statične tabele usmerjanja. Predvideli smo takšno situacijo, ker jo uporabniki potrebujejo, in o tem vemo. Zato je v našem katalogu slik na voljo posebej konfiguriran NAT image.
Toda tudi ko je na voljo pripravljen NAT image, je nastavitev lahko zapletena. Zavedali smo se, da to za nekatere uporabnike ni najbolj priročna možnost, zato smo končno omogočili vključitev NAT za želeni subnet z enim klikom. Ta funkcionalnost je trenutno še v zaprtem predoglednem dostopu, kjer se testira s pomočjo članov skupnosti.
Kako deluje virtualno omrežje od znotraj
Kako uporabnik sodeluje z virtualnim omrežjem? Omrežje 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 čemer vidi status, kako zelo dejansko stanje odstopa od želenega. To je slika uporabnika. Kaj pa se dogaja znotraj?
Zapisujemo želeno stanje v Yandex Database in gremo konfigurirati različne dele naše VPC. Overlayska omrežja v Yandex Cloud so zgrajena na osnovi izbranih komponent OpenContrail, ki se zdaj imenuje Tungsten Fabric. Omrežni servisi so realizirani na enotni platformi CloudGate. V CloudGate smo prav tako uporabili nekaj odprtokodnih komponent: GoBGP – za dostop do nadzorne informacije, ter VPP – za implementacijo programske usmerjevalnika, ki deluje na DPDK za prenos podatkov.
Tungsten Fabric komunicira s CloudGate preko GoBGP. Pove, kaj se dogaja v overlayski mreži. CloudGate pa povezuje overlayske mreže med seboj in z internetom.
Sedaj si oglejmo, kako virtualna mreža rešuje izzive skalabilnosti in razpoložljivosti. Razmislimo o preprostem primeru. Imamo eno dostopno cono in v njej sta ustvarjeni dve VPC. Namestili smo en instančni Tungsten Fabric, ki podpira več deset tisoč omrežij. Omrežja so povezana s CloudGate. CloudGate, kot smo že omenili, zagotavlja njihovo medsebojno povezljivost in povezavo z internetom.
Recimo, da dodamo drugo dostopno cono. Ta mora delovati povsem neodvisno od prve. Zato moramo v drugi dostopni coni namestiti ločen instančni Tungsten Fabric. To bo ločen sistem, ki se ukvarja z overlayskim omrežjem in malo ve o prvem sistemu. Vidljivost naše virtualne mreže pa ustvarja naš VPC API. To je njegovo opravilo.
VPC1 se projicira v dostopno cono B, če v dostopni coni B obstajajo viri, ki se priključijo na VPC1. Če 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čno.
Poglejmo nekoliko globlje, kako je organiziran konkretni gostitelj v Yandex Cloud. Glavna stvar, na katero želimo opozoriti, je, da so vsi gostitelji organizirani enako. Uredimo tako, da se na 'železu' vrti le nujna minimalna količina storitev, vse ostale delujejo na virtualnim mašinama. Gradimo storitve višjega reda na osnovi osnovnih infrastrukturnih storitev in prav tako uporabljamo oblak za reševanje nekaterih inženirskih nalog, na primer v okviru Continuous Integration.
Če pogledamo konkreten gostitelj, bomo videli, da v operacijskem sistemu gostitelja delujejo trije komplementarni elementi:
- Compute – del, ki odgovarja za razporeditev računalniških virov na gostitelju.
- VRouter – del Tungsten Fabric, ki organizira ovire, torej tunelira pakete prek podlage (underlay).
- VDisk – to so kosi virtualizacije shranjevanja.
Poleg tega so virtualnim mašinama zagnane storitve: infrastrukturne storitve oblaka, platformne storitve in zmogljivosti naročnikov. Zmogljivosti naročnikov in platformne storitve vedno delujejo v ovireh prek VRouterja.
Infrastrukturne storitve se lahko povežejo v ovire, vendar običajno želijo delovati prav v podlagi. V podlago se povezujejo s pomočjo SR-IOV. Dejstvo je, da delimo kartico na virtualne mrežne 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.
Zdaj, ko smo opisali globalne naloge virtualne mreže in strukturo osnovnih komponent oblaka, poglejmo, kako natančno različni deli virtualne mreže medsebojno delujejo.
V našem sistemu izločamo tri plasti:
- Config Plane – določa cilj state sistema. To je tisto, kar konfigurira uporabnik prek API.
- Control Plane – zagotavlja uporabniško predpisano semantiko, torej prinaša stanje Data Plane do tistega, kar je uporabnik opisal v Config Plane.
- Data Plane – neposredno obdeluje uporabniške pakete.
Kot sem že omenjal zgoraj, vse začne s tem, da uporabnik ali notranja platformna storitev dostopa do API in opisuje določeno ciljno stanje.
To stanje takoj zapiše v Yandex Database, vrne preko API ID asinhrone operacije in zažene našo interno mehanizacijo, da pridobi stanje, ki ga je želel uporabnik. Konfiguracijske naloge gredo v SDN-controller in sporočijo Tungsten Fabricu, kaj je treba storiti v ovireh. Na primer, rezervirajo vrata, virtualne mreže in podobno.
Config Plane v Tungsten Fabric prenaša v Control Plane zahtevano stanje. Preko njega se Config Plane komunikira z gostitelji, pripoveduje, kaj točno se bo kmalu izvajalo na njih.
Zdaj poglejmo, kako izgleda sistem na gostiteljih. V virtualni napravi Obstaja nek adapter za omrežje, ki je priključen na VRouter. VRouter je jedrski modul Tungsten Fabric, ki gleda na pakete. Če za določen paket že obstaja flow, ga modul obdeluje. Če flow ne obstaja, modul izvede tako imenovani punting, kar pomeni, da paket pošlje v uporabniški proces. Proces razčleni 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.
Nato promet med virtualnimi stroji znotraj ene virtualne mreže poteka transparentno in ni usmerjen na CloudGate. Storitve, na katerih so razporejeni virtualni stroji, med seboj neposredno komunicirajo. Tunelirajo promet in ga prenašajo drug drugemu preko podlage.
Control Plane komunicira med seboj med območji dostopnosti prek BGP, kot z drugim usmerjevalnikom. Povedo, v katerem območju je katere stroje, da lahko virtualni stroji v enem območju neposredno komunicirajo z drugimi virtualnimi stroji.
Poleg tega Control Plane komunicira tudi z CloudGate. Podobno sporoča, kje in katere virtualne naprave so aktivne ter katere so njihove naslove. To omogoča usmerjanje zunanjega prometa na njih in prometa iz uravnoveševalnikov.
Promet, ki zapušča VPC, prispe na CloudGate, v data path, kjer ga hitro obdela VPP z našimi vtičniki. Nato se promet pošlje bodisi v druge VPC bodisi zunaj, v mejne usmerjevalnike, ki jih nastavljamo prek Control Plane samega CloudGate.
Načrti za bližnjo prihodnost.
Če povzamemo vse zgoraj navedeno v nekaj stavkih, lahko rečemo, da VPC v Yandex.Cloud rešuje dve pomembni nalogi:
- Zagotavlja izolacijo med različnimi strankami.
- Združuje vire, infrastrukturo, platformne storitve, druge oblake in lokalno infrastrukturo v eno omrežje.
In da bi te naloge dobro reševali, je potrebno zagotavljati skalabilnost in odpornost na ravni notranje arhitekture, kar VPC tudi počne.
Postopoma VPC pridobiva funkcionalnosti, izvajamo nove možnosti, trudimo se izboljšati nekatere zadeve za udobje uporabnikov. Nekatere ideje se obravnavajo in uvrstijo na seznam prioritet zaradi sodelovanja z našo skupnostjo.
Trenutno imamo približno tak seznam načrtov za bližnjo prihodnost:
- VPN kot storitev.
- Privatni DNS instanci – slike za brzu konfiguraciju virtuelnih mašina sa unapred podešenim DNS serverom.
- DNS kao servis.
- Interni balansirnik opterećenja.
- Dodavanje "belog" IP adrese bez ponovnog kreiranja virtuelne mašine.
Balansirnik i mogućnost prebacivanja IP adrese za već kreiranu virtuelnu mašinu uključeni su u ovu listu na zahtev korisnika. Da budem iskren, bez jasnih povratnih informacija, ne bismo se uhvatili u koštac s tim funkcijama još neko vreme. Tako da već radimo na zadatku o adresama.
Prvobitno je "beli" IP adrese moglo dodati samo prilikom kreiranja mašine. Ako bi korisnik zaboravio to da uradi, moralo bi se ponovo kreirati virtuelna mašina. To isto važi i kada je potrebno ukloniti spoljašnji IP. Uskoro će moći da se uključi i isključi javni IP, bez ponovnog kreiranja mašine.
Ne ustručavajte se da izrazite svoje ideje i podržite predloge drugih korisnika. Pomažete nam da oblak postane bolji i brže dobijate važne i korisne funkcije!
Izvor: habr.com
