Pozdravljeni, moje ime je Kostya Kramlikh, sem vodilni razvijalec oddelka Virtual Private Cloud v Yandex.Cloud. Sem virtualni omrežnik in kot morda ugibate, bom v tem članku govoril o napravi Virtual Private Cloud (VPC) na splošno in še posebej o virtualnem omrežju. Prav tako boste izvedeli, zakaj mi, razvijalci storitve, cenimo povratne informacije naših uporabnikov. Ampak najprej.
Kaj je VPC?
Dandanes obstajajo različne možnosti za uvajanje storitev. Prepričan sem, da še vedno nekdo hrani strežnik pod administratorsko mizo, čeprav upam, da bo takih zgodb manj.
Storitve zdaj poskušajo iti v javne oblake in tu trčijo z VPC-ji. VPC je del javnega oblaka, ki povezuje uporabnike, infrastrukturo, platformo in druge zmogljivosti, kjerkoli že so, v našem oblaku ali zunaj njega. Hkrati vam VPC omogoča, da teh kapacitet ne izpostavljate internetu po nepotrebnem, ampak ostanejo znotraj vašega izoliranega omrežja.
Kako izgleda virtualno omrežje od zunaj?
Z VPC mislimo predvsem na prekrivno omrežje in omrežne storitve, kot so VPNaaS, NATaas, LBaas itd. In vse to deluje na vrhu omrežne infrastrukture, odporne na napake, ki je že bila tukaj, na Habréju.
Oglejmo si podrobneje virtualno omrežje in njegovo napravo.
Razmislite o dveh območjih razpoložljivosti. Ponujamo virtualno omrežje – kar smo poimenovali VPC. Pravzaprav določa prostor edinstvenosti vaših "sivih" naslovov. Znotraj vsakega virtualnega omrežja imate popoln nadzor nad prostorom naslovov, ki jih lahko dodelite računalniškim virom.
Omrežje je globalno. Hkrati se projicira na vsako od območij razpoložljivosti v obliki entitete, imenovane Subnet. Za vsako podomrežje dodelite CIDR velikosti 16 ali manj. V vsakem območju razpoložljivosti je lahko več kot ena taka entiteta in med njimi je vedno pregledno usmerjanje. To pomeni, da se lahko vsi vaši viri znotraj istega VPC "pogovarjajo" med seboj, tudi če so v različnih območjih razpoložljivosti. »Komunicirajo« brez dostopa do interneta, prek naših internih kanalov, »misleč«, da so znotraj istega zasebnega omrežja.
Zgornji diagram prikazuje tipično situacijo: dva VPC-ja, ki se križata nekje v naslovih. Oba sta lahko vaša. Na primer enega za razvoj, drugega za testiranje. Lahko so preprosto različni uporabniki - v tem primeru ni pomembno. En virtualni stroj je priključen na vsak VPC.
Še poslabšajmo shemo. Naredite lahko tako, da je en navidezni stroj obtičal v več podomrežjih hkrati. In ne kar tako, ampak v različnih virtualnih omrežjih.
Hkrati, če morate stroje izpostaviti internetu, lahko to storite prek API-ja ali uporabniškega vmesnika. Če želite to narediti, morate konfigurirati NAT prevod vašega "sivega", notranjega naslova, v "beli" - javni. Ne morete izbrati "belega" naslova, dodeljen je naključno iz naše zbirke naslovov. Takoj ko prenehate uporabljati zunanji IP, se vrne v bazen. Plačate samo za čas uporabe "belega" naslova.
Napravi je mogoče omogočiti tudi dostop do interneta z uporabo NAT instance. Promet lahko usmerite do primerka prek statične usmerjevalne tabele. Tak primer smo zagotovili, ker ga uporabniki včasih potrebujejo in za to vemo. V skladu s tem naš katalog slik vsebuje posebej konfigurirano sliko NAT.
Toda tudi če obstaja pripravljena slika NAT, je nastavitev lahko težavna. Razumeli smo, da za nekatere uporabnike to ni najbolj priročna možnost, zato smo na koncu omogočili NAT za želeno podomrežje z enim klikom. Ta funkcija je še vedno v zaprtem predoglednem dostopu, kjer se preizkuša s pomočjo članov skupnosti.
Kako je virtualno omrežje urejeno od znotraj
Kako uporabnik komunicira z virtualnim omrežjem? Splet gleda navzven s svojim API-jem. Uporabnik pride do API-ja in dela s ciljnim stanjem. Preko API-ja uporabnik vidi, kako mora biti vse urejeno in konfigurirano, hkrati pa vidi stanje, koliko se dejansko stanje razlikuje od želenega. To je slika uporabnika. Kaj se dogaja notri?
Zapišemo želeno stanje v bazo podatkov Yandex in gremo na konfiguracijo različnih delov našega VPC. Prekrivno omrežje v Yandex.Cloudu temelji na izbranih komponentah OpenContrail, ki se pred kratkim imenuje Tungsten Fabric. Omrežne storitve so implementirane na eni platformi CloudGate. V CloudGate smo uporabili tudi številne odprtokodne komponente: GoBGP – za dostop do nadzornih informacij, kot tudi VPP – za implementacijo programskega usmerjevalnika, ki teče na vrhu DPDK za podatkovno pot.
Tungsten Fabric komunicira z CloudGate prek GoBGP. Pove, kaj se dogaja v prekrivnem omrežju. CloudGate pa povezuje prekrivna omrežja med seboj in z internetom.
Zdaj pa poglejmo, kako virtualno omrežje rešuje težave skaliranja in razpoložljivosti. Razmislimo o preprostem primeru. Obstaja eno območje razpoložljivosti in v njem sta ustvarjena dva VPC-ja. Namestili smo en primerek Tungsten Fabric, ki potegne več deset tisoč omrežij. Omrežja komunicirajo z CloudGate. CloudGate, kot smo že povedali, zagotavlja njihovo povezljivost med seboj in z internetom.
Recimo, da je dodano drugo območje razpoložljivosti. Moral bi odpovedati popolnoma neodvisno od prvega. Zato moramo v drugem območju razpoložljivosti namestiti ločen primerek Tungsten Fabric. To bo ločen sistem, ki se ukvarja s prekrivanjem in o prvem sistemu ve malo. In vidnost, da je naše virtualno omrežje globalno, pravzaprav ustvarja naš VPC API. To je njegova naloga.
VPC1 je preslikan v območje razpoložljivosti B, če obstajajo sredstva v območju razpoložljivosti B, ki so potisnjena v VPC1. Če v območju razpoložljivosti B ni sredstev iz VPC2, v tem območju ne bomo materializirali VPC2. Ker viri iz VPC3 obstajajo samo v coni B, VPC3 ne obstaja v coni A. Vse je preprosto in logično.
Pojdimo malo globlje in poglejmo, kako deluje določen gostitelj v Y.Cloudu. Glavna stvar, ki jo želim opozoriti, je, da so vsi gostitelji urejeni na enak način. Naredimo tako, da na strojni opremi teče samo nujni minimum storitev, vse ostale pa na virtualnih strojih. Storitve višjega reda gradimo na osnovi osnovnih infrastrukturnih storitev, oblak pa uporabljamo tudi za reševanje nekaterih inženirskih problemov, na primer v okviru kontinuirane integracije.
Če pogledamo določenega gostitelja, lahko vidimo, da se na gostiteljskem OS izvajajo tri komponente:
- Compute - del, odgovoren za distribucijo računalniških virov na gostitelju.
- VRouter je del Tungsten Fabric, ki organizira prekrivanje, to je tuneliranje paketov skozi podlago.
- VDisks so kosi virtualizacije shranjevanja.
Poleg tega se v virtualnih strojih uvajajo storitve: infrastrukturne storitve v oblaku, storitve platforme in zmogljivosti strank. Zmogljivosti strank in storitve platforme vedno gredo na prekrivanje prek VRouterja.
Infrastrukturne storitve se lahko držijo prekrivanja, vendar v bistvu želijo delati v podlagi. Zalepijo se v podlogo s pomočjo SR-IOV. Pravzaprav kartico razrežemo na virtualne omrežne kartice (virtualne funkcije) in jih potisnemo v infrastrukturne virtualne stroje, da ne izgubimo zmogljivosti. Na primer, isti CloudGate se zažene kot eden od teh infrastrukturnih virtualnih strojev.
Zdaj, ko smo opisali globalne naloge virtualnega omrežja in strukturo osnovnih komponent oblaka, si poglejmo, kako natančno med seboj sodelujejo različni deli virtualnega omrežja.
V našem sistemu ločimo tri plasti:
- Konfiguracijska ravnina - nastavi ciljno stanje sistema. To je tisto, kar uporabnik konfigurira prek API-ja.
- Nadzorna ravnina - zagotavlja uporabniško definirano semantiko, to pomeni, da prenese stanje podatkovne ravnine v tisto, kar je uporabnik opisal v konfiguracijski ravnini.
- Data Plane - neposredno obdeluje uporabnikove pakete.
Kot sem rekel zgoraj, se vse začne z dejstvom, da uporabnik ali interna storitev platforme pride do API-ja in opiše določeno ciljno stanje.
To stanje se takoj zapiše v bazo podatkov Yandex, vrne ID asinhrone operacije prek API-ja in zažene naš notranji stroj, da vrne stanje, ki ga je želel uporabnik. Konfiguracijske naloge gredo v krmilnik SDN in povedo Tungsten Fabric, kaj naj naredi v prekrivanju. Rezervirajo na primer vrata, virtualna omrežja in podobno.
Konfiguracijska ravnina v Tungsten Fabric pošlje zahtevano stanje v nadzorno ravnino. Prek njega Config Plane komunicira z gostitelji in jim sporoča, kaj točno se jim bo kmalu vrtelo.
Zdaj pa poglejmo, kako sistem izgleda na gostiteljih. Navidezni stroj ima omrežno kartico, priključeno na VRuter. VRouter je osrednji modul Tungsten Fabric, ki pregleduje pakete. Če za kakšen paket že obstaja tok, ga modul obdela. Če pretoka ni, modul naredi tako imenovano punting, to pomeni, da pošlje paket procesu usermod. Proces razčleni paket in se sam odzove nanj, kot sta DHCP in DNS, ali pa pove VRouterju, kaj naj z njim naredi. Po tem lahko VRuter obdela paket.
Poleg tega promet med virtualnimi stroji znotraj istega virtualnega omrežja poteka transparentno, ni usmerjen v CloudGate. Gostitelji, na katerih so razporejeni virtualni stroji, komunicirajo neposredno med seboj. Promet tunelirajo in ga posredujejo drug drugemu skozi podlago.
Nadzorne ravnine komunicirajo med seboj med območji razpoložljivosti prek BGP, kot z drugim usmerjevalnikom. Povedo, kateri stroji so kje pripravljeni, tako da lahko navidezni računalniki v enem območju neposredno komunicirajo z drugimi navideznimi računalniki.
In Control Plane komunicira z CloudGate. Podobno poroča, kje in kateri virtualni stroji so postavljeni, katere naslove imajo. To vam omogoča, da zunanji promet in promet od izravnalcev usmerite k njim.
Promet, ki zapusti VPC, pride v CloudGate, na podatkovno pot, kjer se VPP z našimi vtičniki hitro prežveči. Nato se promet sproži na druge VPC-je ali zunaj, na mejne usmerjevalnike, ki so konfigurirani prek nadzorne ravnine samega CloudGate-a.
Načrti za bližnjo prihodnost
Če povzamemo vse zgoraj povedano v nekaj stavkih, lahko rečemo, da VPC v Yandex.Cloudu rešuje dve pomembni nalogi:
- Zagotavlja izolacijo med različnimi strankami.
- Združuje vire, infrastrukturo, storitve platforme, druge oblake in lokalno v eno samo omrežje.
In da bi dobro rešili te težave, morate zagotoviti razširljivost in toleranco na napake na ravni notranje arhitekture, kar VPC tudi počne.
Postopoma VPC pridobiva funkcije, implementiramo nove funkcije, poskušamo nekaj izboljšati v smislu priročnosti za uporabnike. Nekatere ideje so izražene in pridejo na prednostni seznam zahvaljujoč članom naše skupnosti.
Trenutno imamo naslednji seznam načrtov za bližnjo prihodnost:
- VPN kot storitev
- Zasebni primerki DNS so slike za hitro nastavitev virtualnih strojev s predhodno konfiguriranim strežnikom DNS.
- DNS kot storitev.
- Notranji izravnalnik obremenitve.
- Dodajanje "belega" naslova IP brez ponovnega ustvarjanja virtualnega stroja.
Balanser in možnost zamenjave naslova IP za že ustvarjen virtualni stroj sta bila na tem seznamu na zahtevo uporabnikov. Iskreno povedano, brez eksplicitnih povratnih informacij bi te funkcije prevzeli malo kasneje. In tako že delamo na problemu naslovov.
Sprva je bil "beli" naslov IP mogoče dodati le pri ustvarjanju stroja. Če je uporabnik to pozabil storiti, je bilo treba virtualni stroj znova ustvariti. Enako in po potrebi odstranite zunanji IP. Kmalu bo mogoče vklopiti in izklopiti javni IP, ne da bi morali znova ustvariti stroj.
Prosto izrazite svoje drugih uporabnikov. Pomagate nam izboljšati oblak in hitreje pridobiti pomembne in uporabne funkcije!
Vir: www.habr.com