Pozdrav, moje ime je Kostya Kramlich, vodeći sam programer odjela Virtual Private Cloud u Yandex.Cloudu. Radim na virtualnoj mreži i, kao što možda pretpostavljate, u ovom ću članku govoriti o uređaju Virtual Private Cloud (VPC) općenito, a posebno o virtualnoj mreži. Također ćete saznati zašto mi, razvojni programeri usluga, cijenimo povratne informacije od naših korisnika. Ali prvo o svemu.
Što je VPC?
U današnje vrijeme postoje različite mogućnosti za implementaciju usluga. Siguran sam da još netko drži server pod administratorskim stolom, iako se nadam da je takvih priča sve rjeđe.
Sada se usluge pokušavaju preseliti u javne oblake i tu se susreću s VPC-ovima. VPC je dio javnog oblaka koji povezuje korisnike, infrastrukturu, platformu i druge kapacitete zajedno, gdje god se nalazili, u našem Cloudu ili šire. U isto vrijeme, VPC vam omogućuje da izbjegnete nepotrebno izlaganje ovih kapaciteta internetu; oni ostaju unutar vaše izolirane mreže.
Kako virtualna mreža izgleda izvana
Pod VPC-om prije svega mislimo na preklapajuću mrežu i mrežne usluge, kao što su VPNaaS, NATaas, LBaas, itd. I sve to radi na mrežnoj infrastrukturi otpornoj na pogreške, o kojoj je već bilo riječi ovdje na Habréu.
Pogledajmo pobliže virtualnu mrežu i njenu strukturu.
Pogledajmo dvije zone dostupnosti. Pružamo virtualnu mrežu - ono što smo nazvali VPC. Zapravo, definira prostor jedinstvenosti vaših "sivih" adresa. Unutar svake virtualne mreže imate punu kontrolu nad prostorom adresa koje možete dodijeliti računalnim resursima.
Mreža je globalna. Istodobno se projicira na svaku od zona dostupnosti u obliku entiteta koji se naziva Subnet. Za svaku podmrežu dodijelite CIDR veličine 16 ili manje. Svaka zona dostupnosti može imati više od jednog takvog entiteta, a između njih uvijek postoji transparentno usmjeravanje. To znači da svi vaši resursi unutar istog VPC-a mogu "razgovarati" jedni s drugima, čak i ako su u različitim zonama dostupnosti. “Komuniciraju” bez pristupa internetu, preko naših internih kanala, “misleći” da su unutar iste privatne mreže.
Gornji dijagram prikazuje tipičnu situaciju: dva VPC-a koji se križaju negdje u svojim adresama. Obje mogu biti vaše. Na primjer, jedan za razvoj, drugi za testiranje. Jednostavno mogu postojati različiti korisnici - u ovom slučaju to nije važno. I svaki VPC ima jedan virtualni stroj.
Pogoršajmo shemu. Jedno virtualno računalo možete spojiti na nekoliko podmreža odjednom. I ne samo tako, već u različitim virtualnim mrežama.
U isto vrijeme, ako trebate izložiti strojeve na Internetu, to se može učiniti putem API-ja ili korisničkog sučelja. Da biste to učinili, trebate konfigurirati NAT prijevod svoje "sive", interne adrese, u "bijelu" - javnu adresu. Ne možete odabrati "bijelu" adresu; ona se dodjeljuje nasumično iz našeg skupa adresa. Čim prestanete koristiti vanjski IP, on se vraća u bazen. Plaćate samo vrijeme korištenja "bijele" adrese.
Također je moguće stroju dati pristup Internetu pomoću NAT instance. Možete usmjeriti promet do svoje instance kroz statičku tablicu usmjeravanja. Omogućili smo takav slučaj jer je korisnicima ponekad potreban, a mi znamo za to. Sukladno tome, u našem direktoriju slika postoji posebno konfigurirana NAT slika.
Ali čak i kada postoji gotova NAT slika, konfiguracija može biti složena. Shvatili smo da za neke korisnike ovo nije najprikladnija opcija, pa smo na kraju omogućili da jednim klikom omogućimo NAT za željenu podmrežu. Ova je značajka još uvijek u zatvorenom pristupu pretpregledu, gdje se testira uz pomoć članova zajednice.
Kako virtualna mreža funkcionira iznutra
Kako korisnik komunicira s virtualnom mrežom? Mreža svojim API-jem gleda prema van. Korisnik dolazi do API-ja i radi s ciljnim stanjem. Preko API-ja korisnik vidi kako sve treba posložiti i konfigurirati, dok vidi status, koliko se stvarno stanje razlikuje od željenog. Ovo je slika korisnika. Što se događa unutra?
Bilježimo željeno stanje u Yandex bazi podataka i idemo konfigurirati različite dijelove našeg VPC-a. Prekrivajuća mreža u Yandex.Cloudu izgrađena je na temelju odabranih komponenti OpenContraila, koji se nedavno naziva Tungsten Fabric. Mrežne usluge implementirane su na jednoj CloudGate platformi. U CloudGateu smo također koristili niz komponenti otvorenog koda: GoBGP za rukovanje kontrolnim informacijama, kao i VPP za implementaciju softverskog usmjerivača koji radi na vrhu DPDK za put podataka.
Tungsten Fabric komunicira s CloudGateom putem GoBGP-a. Govori što se događa u preklopnoj mreži. CloudGate, zauzvrat, povezuje preklapajuće mreže međusobno i s internetom.
Sada pogledajmo kako virtualna mreža rješava probleme skalabilnosti i dostupnosti. Razmotrimo jednostavan slučaj. Postoji jedna zona dostupnosti iu njoj su stvorena dva VPC-a. Postavili smo jednu instancu Tungsten Fabric koja sadrži nekoliko desetaka tisuća mreža. Mreže komuniciraju s CloudGateom. CloudGate, kao što smo već rekli, osigurava njihovu međusobnu povezanost i povezanost s internetom.
Recimo da je dodana druga zona dostupnosti. Trebao bi propasti potpuno neovisno o prvom. Stoga moramo instalirati zasebnu instancu Tungsten Fabric u drugoj zoni dostupnosti. Ovo će biti zaseban sustav koji upravlja preklapanjem i zna malo o prvom sustavu. A privid da je naša virtualna mreža globalna, zapravo, stvara naš VPC API. Ovo je njegov zadatak.
VPC1 se preslikava u zonu dostupnosti B ako zona dostupnosti B ima resurse koji se drže VPC1. Ako nema resursa iz VPC2 u zoni dostupnosti B, ne materijaliziramo VPC2 u ovoj zoni. S druge strane, budući da resursi iz VPC3 postoje samo u zoni B, VPC3 ne postoji u zoni A. Sve je jednostavno i logično.
Idemo malo dublje i vidimo kako funkcionira određeni host u Y.Cloudu. Glavna stvar koju bih želio napomenuti je da su svi hostovi dizajnirani isto. Pobrinjavamo se da samo potreban minimum usluga radi na hardveru; sve ostale rade na virtualnim strojevima. Gradimo usluge višeg reda na temelju osnovnih infrastrukturnih usluga, a također koristimo Cloud za rješavanje nekih inženjerskih problema, na primjer, kao dio kontinuirane integracije.
Ako pogledamo određeni host, možemo vidjeti da postoje tri komponente koje rade u OS-u hosta:
- Compute je dio odgovoran za distribuciju računalnih resursa na hostu.
- VRouter je dio Tungsten Fabric-a, koji organizira prekrivanje, odnosno tunelira pakete kroz podlogu.
- VDisks su dijelovi virtualizacije pohrane.
Osim toga, virtualni strojevi pokreću usluge: usluge infrastrukture oblaka, usluge platforme i kapacitet korisnika. Kapaciteti kupaca i usluge platforme uvijek idu na prekrivanje putem VRoutera.
Infrastrukturne usluge mogu se uključiti u sloj, ali uglavnom žele raditi u sloju. Zalijepe se u podlogu pomoću SR-IOV. Zapravo, izrezujemo karticu u virtualne mrežne kartice (virtualne funkcije) i guramo ih u infrastrukturne virtualne strojeve kako ne bi izgubili performanse. Na primjer, isti CloudGate je pokrenut kao jedan od ovih infrastrukturnih virtualnih strojeva.
Sada kada smo opisali globalne zadatke virtualne mreže i dizajn osnovnih komponenti oblaka, pogledajmo kako točno različiti dijelovi virtualne mreže međusobno djeluju.
U našem sustavu razlikujemo tri sloja:
- Config Plane – postavlja ciljno stanje sustava. To je ono što korisnik konfigurira putem API-ja.
- Kontrolna ravnina – pruža korisnički specificiranu semantiku, odnosno dovodi stanje podatkovne ravnine na ono što je korisnik opisao u konfiguracijskoj ravnini.
- Data Plane – izravno obrađuje korisničke pakete.
Kao što sam rekao gore, sve počinje s korisnikom ili unutarnjom platformskom uslugom koja dolazi do API-ja i opisuje određeno ciljno stanje.
Ovo se stanje odmah zapisuje u Yandexovu bazu podataka, vraća ID asinkrone operacije putem API-ja i pokreće naš interni mehanizam za proizvodnju stanja koje je korisnik želio. Konfiguracijski zadaci idu do SDN kontrolera i govore Tungsten Fabricu što treba učiniti u sloju. Na primjer, rezerviraju portove, virtualne mreže i slično.
Konfiguracijska ravnina u Tungsten Fabric učitava potrebno stanje u kontrolnu ravninu. Preko njega Config Plane komunicira s hostovima, govoreći im što će se točno na njima izvoditi u bliskoj budućnosti.
Sada da vidimo kako sustav izgleda na hostovima. Virtualni stroj ima određeni mrežni adapter priključen na VRouter. VRouter je osnovni modul Tungsten Fabric koji gleda pakete. Ako već postoji tijek za neki paket, modul ga obrađuje. Ako nema protoka, modul radi tzv. punting, odnosno šalje paket u usermod proces. Proces analizira paket i ili sam odgovara na njega, kao DHCP i DNS, ili govori VRouteru što da radi s njim. VRuter tada može obraditi paket.
Nadalje, promet između virtualnih strojeva unutar iste virtualne mreže teče transparentno, ne šalje se CloudGateu. Domaćini na kojima su virtualni strojevi raspoređeni međusobno izravno komuniciraju. Probijaju promet u tunelima i prosljeđuju ga jedni drugima kroz podlogu.
Kontrolne razine komuniciraju jedna s drugom preko zona dostupnosti putem BGP-a, baš kao s drugim usmjerivačem. Oni vam govore koji su strojevi gdje instalirani, tako da virtualni strojevi u jednoj zoni mogu izravno komunicirati s drugim virtualnim strojevima.
Control Plane također komunicira s CloudGateom. Slično, izvješćuje gdje i koji su virtualni strojevi instalirani, koje su njihove adrese. To vam omogućuje usmjeravanje vanjskog prometa i prometa od balansera prema njima.
Promet koji napušta VPC dolazi u CloudGate, u podatkovnoj stazi, gdje se VPP s našim dodacima brzo prožvače. Zatim se promet usmjerava prema drugim VPC-ovima ili prema van, prema rubnim usmjerivačima, koji su konfigurirani kroz kontrolnu ravninu samog CloudGatea.
Planovi za blisku budućnost
Ako sve gore rečeno sažmemo u nekoliko rečenica, možemo reći da VPC u Yandex.Cloudu rješava dva važna problema:
- Omogućuje izolaciju između različitih klijenata.
- Ujedinjuje resurse, infrastrukturu, usluge platforme, druge oblake i lokalnu mrežu u jednu mrežu.
A da biste dobro riješili te probleme, morate osigurati skalabilnost i toleranciju na greške na razini interne arhitekture, što VPC i radi.
VPC postupno dobiva funkcije, implementiramo nove značajke i pokušavamo poboljšati nešto u smislu pogodnosti za korisnike. Neke su ideje izrečene i uključene u listu prioriteta zahvaljujući članovima naše zajednice.
Sada imamo otprilike sljedeći popis planova za blisku budućnost:
- VPN kao usluga.
- Privatne DNS instance – slike za brzo postavljanje virtualnih strojeva s unaprijed konfiguriranim DNS poslužiteljem.
- DNS kao usluga.
- Unutarnji balanser opterećenja.
- Dodavanje "bijele" IP adrese bez ponovnog stvaranja virtualnog stroja.
Balancer i mogućnost promjene IP adrese za već stvoren virtualni stroj uključeni su u ovaj popis na zahtjev korisnika. Da budem iskren, bez eksplicitnih povratnih informacija ove bismo funkcije preuzeli malo kasnije. I tako već radimo na problemu oko adresa.
U početku se "bijela" IP adresa mogla dodati samo prilikom stvaranja stroja. Ako je korisnik to zaboravio učiniti, virtualni stroj je morao biti ponovno kreiran. Isto vrijedi i za uklanjanje vanjskog IP-a ako je potrebno. Uskoro će biti moguće uključiti i isključiti javni IP bez ponovnog kreiranja stroja.
Slobodno izrazite svoje drugim korisnicima. Pomažete nam da poboljšamo Cloud i brže dobijemo važne i korisne značajke!
Izvor: www.habr.com