Bok, moje ime je Kostya Kramlikh i glavni sam programer u odjelu za virtualni privatni oblak u Yandex.Cloudu. Radim na virtualnim mrežama i, kao što možete pretpostaviti, u ovom ću članku obraditi arhitekturu virtualnog privatnog oblaka (VPC) općenito, a posebno virtualne mreže. Također ćete saznati zašto mi, programeri usluge, cijenimo povratne informacije naših korisnika. Ali prvo ono najvažnije.
Što je VPC?
Ovih dana postoje sve vrste opcija za implementaciju usluga. Siguran sam da netko još uvijek drži server ispod administratorskog stola, iako se nadam da su takve priče sve rjeđe.
Usluge se trenutno sele u javne oblake i tu se susreću s VPC-ovima. VPC je dio javnog oblaka koji povezuje korisnika, infrastrukturu, platformu i druge resurse, bez obzira nalaze li se unutar našeg oblaka ili izvan njega. VPC sprječava izlaganje tih resursa internetu osim ako nije potrebno; oni ostaju unutar vaše izolirane mreže.
Kako virtualna mreža izgleda izvana
Pod VPC-om prije svega mislimo na prekrivajuću mrežu i mrežne usluge poput VPNaaS-a, NATaasa, LBaasa itd. I sve to funkcionira preko mrežne infrastrukture otporne na greške o kojoj je već bilo riječi. sjajan članak ovdje na Habru.
Pogledajmo pobliže virtualnu mrežu i njezinu strukturu.
Pogledajmo dvije zone dostupnosti. Pružamo virtualnu mrežu - ono što nazivamo VPC. Ona u biti definira jedinstveni prostor za vaše "sive" adrese. Unutar svake virtualne mreže imate potpunu kontrolu nad adresnim prostorom koji možete dodijeliti svojim računalnim resursima.
Mreža je globalna. Mapirana je na svaku zonu dostupnosti kao entitet koji se naziva Podmreža. Za svaku Podmrežu dodjeljujete CIDR od 16 ili manje. Svaka zona dostupnosti može imati više takvih entiteta i uvijek postoji transparentno usmjeravanje između njih. To znači da svi vaši resursi unutar jednog VPC-a mogu međusobno komunicirati, čak i ako se nalaze u različitim zonama dostupnosti. Komuniciraju bez pristupa internetu, putem naših internih kanala, misleći da su unutar iste privatne mreže.
Gornji dijagram prikazuje tipičnu situaciju: dva VPC-a s preklapajućim adresama. Oba mogu pripadati vama. Na primjer, jedan je za razvoj, drugi za testiranje. Mogu biti jednostavno različiti korisnici - u ovom slučaju to je nebitno. I svaki VPC sadrži jedan virtualni stroj.
Idemo dalje. Možemo omogućiti da se jedan virtualni stroj istovremeno spoji na više podmreža. I ne na bilo koju podmrežu, već na različite virtualne mreže.
Ako trebate izložiti računala internetu, to možete učiniti putem API-ja ili korisničkog sučelja. Da biste to učinili, morate konfigurirati NAT prijevod vaše "sive", interne adrese u "bijelu", javnu. Ne možete odabrati "bijelu" adresu; ona se dodjeljuje nasumično iz našeg skupa adresa. Nakon što prestanete koristiti vanjsku IP adresu, ona se vraća u skup. Plaćate samo za vrijeme korištenja "bijele" adrese.
Također je moguće omogućiti računalu pristup internetu pomoću NAT instance. Promet se može usmjeriti na instancu putem statičke tablice usmjeravanja. Uključili smo ovaj scenarij jer ga korisnici ponekad trebaju, a mi smo toga svjesni. Sukladno tome, posebno konfigurirana NAT slika dostupna je u našem katalogu slika.
Ali čak i s gotovom NAT slikom, postavljanje može biti složeno. Prepoznali smo da to nije najprikladnija opcija za neke korisnike, pa smo na kraju implementirali mogućnost omogućavanja NAT-a za određenu podmrežu jednim klikom. Ova je značajka trenutno u zatvorenoj pretpremijeri, gdje je testiramo uz pomoć članova zajednice.
Kako je virtualna mreža strukturirana iznutra
Kako korisnik komunicira s virtualnom mrežom? Mreža je izvana izložena putem svog API-ja. Korisnik pristupa API-ju i komunicira s ciljnim stanjem. Putem API-ja korisnik vidi kako bi sve trebalo biti strukturirano i konfigurirano, a također vidi status i kako se stvarno stanje razlikuje od željenog. Ovo je korisnički pogled. Ali što se događa interno?
Željeno stanje bilježimo u Yandex bazu podataka i nastavljamo s konfiguriranjem različitih dijelova našeg VPC-a. Prekrivajuća mreža u Yandex.Cloudu izgrađena je korištenjem odabranih komponenti OpenContraila, koji je nedavno preimenovan u Tungsten Fabric. Mrežne usluge implementirane su na jedinstvenoj CloudGate platformi. U CloudGateu smo također koristili nekoliko komponenti otvorenog koda: GoBGP za razmjenu kontrolnih informacija i VPP za implementaciju softverskog usmjerivača koji radi na DPDK-u za put podataka.
Tungsten Fabric komunicira s CloudGateom putem GoBGP-a, izvještavajući što se događa u prekrivajućoj mreži. CloudGate pak povezuje prekrivajuće mreže jednu s drugom i s internetom.
Sada pogledajmo kako virtualna mreža rješava probleme skalabilnosti i dostupnosti. Razmotrimo jednostavan scenarij. Postoji jedna zona dostupnosti i unutar nje su stvorena dva VPC-a. Implementirali smo jednu instancu Tungsten Fabrica i ona obrađuje nekoliko desetaka tisuća mreža. Te su mreže povezane s CloudGateom. CloudGate, kao što smo već raspravljali, osigurava njihovu međusobnu povezanost i povezanost s internetom.
Recimo da dodajemo drugu zonu dostupnosti. Trebala bi potpuno neovisno o prvoj. Stoga moramo implementirati zasebnu instancu Tungsten Fabric-a u drugoj zoni dostupnosti. To će biti zaseban sustav koji obrađuje preklapanje i ima malo znanja o prvom sustavu. A privid da je naša virtualna mreža globalna zapravo je ono što stvara naš VPC API. To mu je posao.
VPC1 se projicira u Zonu dostupnosti B ako u Zoni dostupnosti B postoje resursi koji se priključuju na VPC1. Ako u Zoni dostupnosti B nema resursa iz VPC2, ne materijaliziramo VPC2 u toj zoni. Suprotno tome, budući da resursi iz VPC3 postoje samo u Zoni dostupnosti B, VPC3 nije prisutan u Zoni dostupnosti A. Sve je jednostavno i logično.
Idemo malo dublje istražiti kako je strukturiran određeni Yandex.Cloud hosting. Glavna stvar koju želim napomenuti jest da su svi hosting hostingi strukturirani identično. Osiguravamo da se samo minimum usluga pokreće na hardveru, dok sve ostalo radi na virtualni strojeviIzgrađujemo usluge višeg reda povrh osnovnih infrastrukturnih usluga, a također koristimo Cloud za rješavanje određenih inženjerskih izazova, kao što je kontinuirana integracija.
Ako pogledamo određeni host, vidimo da u host OS-u rade tri komponente:
- Izračunavanje je dio odgovoran za distribuciju računalnih resursa na hostu.
- VRouter je dio Tungsten Fabrica koji organizira sloj, odnosno tunelira pakete kroz podlogu.
- VDisk su dijelovi virtualizacije pohrane.
Osim ovoga, virtualni strojevi Pokrenute su sljedeće usluge: Usluge infrastrukture u oblaku, platformske usluge i korisnički kapaciteti. Korisnički kapaciteti i platformske usluge uvijek pristupaju sloju putem VRoutera.
Infrastrukturne usluge mogu se uključiti u sloj, ali općenito preferiraju izvođenje u podlozi. U podlogu se uključuju pomoću SR-IOV-a. U biti, mi dijelimo mrežnu kartu na virtualne mrežne kartice (virtualne funkcije) i ubacujemo ih u infrastrukturne virtualne strojeve kako bismo održali performanse. Na primjer, CloudGate se pokreće kao jedan od tih infrastrukturnih virtualnih strojeva.
Sada kada smo opisali globalne zadatke virtualne mreže i strukturu osnovnih komponenti oblaka, pogledajmo kako točno različiti dijelovi virtualne mreže međusobno djeluju.
U našem sustavu razlikujemo tri sloja:
- Konfiguracijska ravnina – definira ciljno stanje sustava. To je ono što korisnik konfigurira putem API-ja.
- Kontrolna ravnina – pruža korisnički definiranu semantiku, odnosno dovodi stanje podatkovne ravnine u ono što je korisnik opisao u konfiguracijskoj ravnini.
- Podatkovna ravnina – izravno obrađuje korisničke pakete.
Kao što sam već spomenuo, sve počinje s korisnikom ili internom uslugom platforme koja dolazi do API-ja i opisuje određeno ciljno stanje.
Ovo stanje se odmah zapisuje u Yandex bazu podataka, vraća asinkroni ID operacije putem API-ja i pokreće naš interni mehanizam da vrati stanje koje je korisnik zatražio. Konfiguracijski zadaci šalju se SDN kontroleru i govore Tungsten Fabricu što treba učiniti u sloju. Na primjer, rezerviraju portove, virtualne mreže i tako dalje.
Konfiguracijska ravnina u Tungsten Fabricu šalje potrebno stanje kontrolnoj ravnini. Putem kontrolne ravnine, konfiguracijska ravnina komunicira s hostovima, obavještavajući ih o tome što će se uskoro na njima izvoditi.
Sada da vidimo kako sustav izgleda na hostovima. virtualni stroj U VRouter je priključen mrežni adapter. VRouter je Tungsten Fabric kernel modul koji prati pakete. Ako već postoji protok za paket, modul ga obrađuje. Ako nema protoka, modul izvodi ono što se naziva punting, što znači slanje paketa usermod procesu. Proces parsira paket i ili sam odgovara na njega, kao kod DHCP-a i DNS-a, ili govori VRouteru što da s njim učini. VRouter tada može obraditi paket.
Promet između virtualnih strojeva unutar iste virtualne mreže tada teče transparentno; ne usmjerava se kroz CloudGate. Hostovi koji hostiraju virtualne strojeve komuniciraju izravno jedni s drugima, tunelirajući promet i prosljeđujući ga kroz podlogu.
Kontrolne ravnine međusobno komuniciraju preko zona dostupnosti putem BGP-a, kao da su drugi usmjerivač. One komuniciraju koja računala gdje rade, tako da virtualna računala u jednoj zoni mogu izravno komunicirati s drugim virtualnim računalima.
Control Plane također komunicira s CloudGateom. Također izvještava gdje i koji virtualni strojevi rade, zajedno s njihovim adresama. To omogućuje usmjeravanje vanjskog prometa i prometa od uravnoteživača opterećenja prema njima.
Promet koji izlazi iz VPC-a stiže na CloudGateovu podatkovnu putanju, gdje ga VPP brzo obrađuje s našim dodacima. Promet se zatim šalje ili drugim VPC-ovima ili prema van prema rubnim usmjerivačima, koji su konfigurirani putem CloudGateove kontrolne ravnine.
Planovi za blisku budućnost
Da sažmemo sve gore navedeno u nekoliko rečenica, možemo reći da VPC u Yandex.Cloudu rješava dva važna problema:
- Pruža izolaciju između različitih klijenata.
- Integrira resurse, infrastrukturu, usluge platforme, ostale oblake i lokalnu platformu u jednu mrežu.
Da biste učinkovito riješili ove probleme, morate osigurati skalabilnost i toleranciju grešaka na razini interne arhitekture, što je upravo ono što VPC radi.
VPC se postupno širi novim značajkama, implementiramo nove mogućnosti i neprestano radimo na poboljšanju korisničkog iskustva. Neke ideje su izražene i prioritetne zahvaljujući članovima naše zajednice.
Trenutno imamo popis planova za blisku budućnost koji izgleda otprilike ovako:
- VPN kao usluga.
- Privatne DNS instance su slike za brzo postavljanje virtualnih strojeva s unaprijed konfiguriranim DNS poslužiteljem.
- DNS kao usluga.
- Interni uravnoteživač opterećenja.
- Dodavanje "bijele" IP adrese bez ponovnog stvaranja virtualnog stroja.
Na zahtjev korisnika, na ovaj popis dodani su uravnoteživač opterećenja i mogućnost promjene IP adresa za postojeći virtualni stroj. Iskreno, bez eksplicitnih povratnih informacija, ove bismo značajke malo odgodili. Već radimo na problemu s adresom.
U početku se javna IP adresa mogla dodati samo prilikom stvaranja virtualnog stroja. Ako bi korisnik zaboravio to učiniti, virtualni stroj je morao biti ponovno stvoren. Isto vrijedi i ako je javnu IP adresu trebalo ukloniti. Uskoro će biti moguće omogućiti i onemogućiti javnu IP adresu bez ponovnog stvaranja virtualnog stroja.
Ne ustručavajte se izraziti svoje ideje i prijedlozi podrške drugim korisnicima. Pomažete nam da poboljšamo Oblak i brže dobijemo važne i korisne značajke!
Izvor: www.habr.com
