Ahoj, volám sa Kosti Krámlikh, som hlavným vývojárom v oddelení Virtual Private Cloud v Yandex.Cloud. Zaoberám sa virtuálnou sieťou a, ako si môžete domyslieť, v tomto článku vám poviem o fungovaní Virtual Private Cloud (VPC) vo všeobecnosti a virtuálnej sieti konkrétne. Takisto sa dozviete, prečo my, vývojári služby, si veľmi ceníme spätnú väzbu od našich používateľov. Ale po poriadku.
Čo je to VPC?
V súčasnosti je pre nasadenie služieb množstvo rôznych možností. Som presvedčený, že niekto si stále drží server pod stolom administrátora, aj keď dúfam, že takých príbehov ubúda.
Služby sa teraz snažia prechádzať do verejných cloudov a práve tu sa stretávajú s VPC. VPC je časť verejného cloudu, ktorá spája používateľské, infraštruktúrne, platformové a iné zdroje do jedného celku, kdekoľvek sa nachádzajú, v našom Cloude alebo mimo neho. Pri tom VPC umožňuje, aby sa tieto zdroje bez potreby nevyhadzovali na internet, zostávajú v rámci vašej izolovanej siete.
Ako vyzerá virtuálna sieť zvonka
Pod VPC rozumieme predovšetkým overlay sieť a sieťové služby ako VPNaaS, NATaas, LBaas a ďalšie. A to všetko funguje na vrchu redundantnej sieťovej infraštruktúry, o ktorej už bola reč skvelý článok tu na Habre.
Pozrime sa na virtuálnu sieť a jej fungovanie podrobnejšie.
Spoznajme dve zóny dostupnosti. Poskytujeme virtuálnu sieť – to, čo sme nazvali VPC. V skutočnosti určuje priestor jedinečnosti vašich "šedých" adries. V rámci každej virtuálnej siete máte úplnú kontrolu nad priestorom adries, ktoré môžete priradiť výpočtovým zdrojom.
Sieť je globálna. Pri tom sa premieta do každej zo zón dostupnosti v podobe entity nazvanej Subnet. Pre každú Subnet priraďujete určitý CIDR s veľkosťou 16 alebo menšou. V každej zóne dostupnosti môže existovať viac ako jedna takáto entita, pričom medzi nimi vždy existuje transparentné smerovanie. To znamená, že všetky vaše zdroje v rámci jednej VPC môžu "komunikovať" medzi sebou, aj keď sa nachádzajú v rôznych zónach dostupnosti. "Komunikovať" bez opustenia internetu, cez naše vnútorné kanály, "mysliac", že sa nachádzajú v rámci jednej súkromnej siete.
Na schéme vyššie je znázornená typická situácia: dve VPC, ktoré sa niekde prekryjú adresami. Obe môžu patriť vám. Napríklad jedna pre vývoj, druhá – pre testovanie. Môžu to byť aj rôzni používatelia – v tomto prípade na tom nezáleží. A do každej VPC je zasadená jedna virtuálna mašina.
Zosložitíme schému. Môžete konfigurovať, aby sa jedna virtuálna mašina pripojila naraz k viacerým subnetom. A nie len tak, ale v rôznych virtuálnych sieťach.
Ak však potrebujete vystaviť stroje na internet, môžete to urobiť cez API alebo UI. Na to je potrebné nastaviť preklad NAT vášho „šedého“, vnútorného adresy na „biely“ – verejný. „Bielu“ adresu si nemôžete vybrať, je priradená náhodne z nášho adresného priestoru. Keď prestanete používať externú IP, vráti sa do bazéna. Platíte iba za čas používania „bielej“ adresy.
Existuje aj možnosť poskytnúť stroju prístup na internet pomocou NAT inštancie. Na inštanciu môžete smerovať prenos cez statickú tabuľku smerovania. Tento prípad sme zohľadnili, pretože je potrebný pre niektorých používateľov, a vieme o tom. Preto v našom katalógu obrazov nájdete špeciálne nakonfigurovaný NAT obraz.
Ale aj keď je k dispozícii hotový NAT obraz, nastavenie môže byť zložité. Uvedomovali sme si, že pre niektorých používateľov to nie je ten najpohodlnejší variant, preto sme nakoniec vytvorili možnosť zapnúť NAT pre požadovaný subnet jedným kliknutím. Táto funkcia je zatiaľ v uzavretom preview prístupe, kde sa testuje s pomocou členov komunity.
Ako je virtuálna sieť koncipovaná zvnútra
Ako interaguje používateľ s virtuálnou sieťou? Sieť sleduje vonkajšok svojím API. Používateľ prichádza do API a pracuje s cieľovým stavom. Cez API používateľ vidí, ako by to malo byť usporiadané a nastavené, pritom vidí stav, do akej miery sa aktuálny stav líši od požadovaného. To je obraz používateľa. A čo sa deje vo vnútri?
Zaznamenávame požadovaný stav do Yandex Database a ideme konfigurovať rôzne časti našej VPC. Overlay sieť v Yandex. Cloud je postavená na vybraných komponentoch OpenContrail, ktorý sa nedávno premenoval na Tungsten Fabric. Sieťové služby sú realizované na jedinej platforme CloudGate. V CloudGate sme tiež použili niekoľko open source komponentov: GoBGP – na získanie kontrolnej informácie, a tiež VPP – na realizáciu programového smerovača fungujúceho na DPDK pre data path.
Tungsten Fabric komunikuje s CloudGate cez GoBGP. Rozpráva, čo sa deje v overlay sieti. CloudGate, na druhej strane, prepája overlay siete medzi sebou a s internetom.
Teraz sa pozrime, ako virtuálna sieť rieši úlohy škálovania a dostupnosti. Zvážme jednoduchý prípad. Máme jednu zónu dostupnosti a v nej vytvorené dve VPC. Nasadili sme jeden inštanciu Tungsten Fabric, a ten si ťahá niekoľko desiatok tisíc sietí. Siete sú prepojené s CloudGate. CloudGate, ako sme už spomenuli, zabezpečuje ich prepojenosť medzi sebou a s internetom.
Predpokladajme, že sa pridáva druhá zóna dostupnosti. Tá by mala zlyhať úplne nezávisle od prvej. Preto v druhej zóne dostupnosti musíme umiestniť samostatnú inštanciu Tungsten Fabric. To bude samostatný systém, ktorý sa zaoberá overlayom a málo vie o prvej sústave. A viditeľnosť, že naša virtuálna sieť je globálna, vlastne vytvára náš VPC API. To je jeho úloha.
VPC1 sa premieta do zóny dostupnosti B, ak v zóne dostupnosti B existujú zdroje, ktoré sú zapojené do VPC1. Ak v zóne dostupnosti B nie sú zdroje z VPC2, VPC2 v tejto zóne nebudeme materializovať. Na druhej strane, keďže zdroje z VPC3 existujú len v zóne B, VPC3 nie je v zóne A. Všetko je to jednoduché a logické.
Poďme ísť trochu hlbšie a pozrime sa, ako je usporiadaný konkrétny hostiteľ v Yandex. Cloud. Hlavné, čo chcem zdôrazniť, je, že všetky hostiteľské zariadenia sú usporiadané rovnako. Snažíme sa, aby na "železe" bežala iba nevyhnutná minimálna sada služieb, všetky ostatné fungujú na virtuálnych strojoch. Vytvárame služby vyšších úrovní na základe základných infraštruktúrnych služieb a tiež využívame Cloud na riešenie niektorých inžinierskych úloh, napríklad v rámci Continuous Integration.
Ak sa pozrieme na konkrétny host, uvidíme, že v operačnom systéme hosta bežia tri komponenty:
- Compute – časť zodpovedajúca za distribúciu výpočtových zdrojov na hoste.
- VRouter – súčasť Tungsten Fabric, ktorá organizuje overlay, teda tuneluje pakety cez underlay.
- VDisk – ide o kusy virtualizácie úložiska.
Okrem toho sú virtuálnych strojoch spustené služby: infraštruktúrne služby cloudu, platformové služby a kapacity zákazníkov. Kapacity zákazníkov a platformové služby vždy prechádzajú do overlay cez VRouter.
Infrastruktúrne služby môžu byť zapojené do overlay, ale väčšinou chcú fungovať práve v underlay. Do underlay sa zapájajú pomocou SR-IOV. Fakticky rozdelíme kartu na virtuálne sieťové karty (virtuálne funkcie) a zapojíme ich do infraštruktúrnych virtuálnych strojov, aby sme nestrácali výkon. Napríklad, ten istý CloudGate je spustený ako jedna z takých infraštruktúrnych virtuálnych strojov.
Teraz, keď sme opísali globálne úlohy virtuálnej siete a usporiadanie základných komponentov cloudu, pozrime sa, ako presne rôzne časti virtuálnej siete vzájomne komunikujú.
V našom systéme vyčleňujeme tri vrstvy:
- Config Plane – určuje cieľový stav systému. To je to, čo konfiguruje používateľ cez API.
- Control Plane – zabezpečuje používateľom stanovenú sémantiku, teda dotiahne stav Data Plane do podoby, ktorú používateľ opísal v Config Plane.
- Data Plane – priamo spracováva pakety používateľa.
Ako som už povedal vyššie, všetko sa začína tým, že používateľ alebo interná platformová služba prichádza do API a opisuje určitý cieľový stav.
Tento stav sa okamžite zapíše do Yandex Database, vráti sa cez API ID asynchrónnej operácie a spustí našu vnútornú mašinériu, aby sa dosiahol stav, ktorý chcel používateľ. Konfiguračné úlohy idú do SDN kontroléra a informujú Tungsten Fabric, čo je potrebné urobiť v overlay. Napríklad, rezervujú porty, virtuálne siete a podobne.
Config Plane v Tungsten Fabric odovzdáva Control Plane požadovaný stav. Cez ňu sa Config Plane komunikuje s hostiteľmi a informuje ich, čo presne na nich bude čoskoro bežať.
Teraz sa pozrime, ako vyzerá systém na hostiteľoch. V virtuálnom stroji existuje sieťový adaptér zapojený do VRouteru. VRouter je jadrový modul Tungsten Fabric, ktorý sleduje pakety. Ak pre určitý paket už existuje flow, modul ho spracováva. Ak flow neexistuje, modul vykonáva takzvané punting, čo znamená, že posiela paket do procesu v užívateľskom móde. Proces analyzuje paket a buď naň sám odpovedá, ako napríklad na DHCP a DNS, alebo hovorí VRouteru, čo s ním robiť. Potom VRouter môže spracovávať paket.
Ďalej traffic medzi virtuálnymi strojmi v rámci jednej virtuálnej siete prechádza transparentne, nepreposiela sa na CloudGate. Hostitelia, na ktorých sú rozložené virtuálne stroje, komunikujú medzi sebou priamo. Tunnellujú traffic a prenášajú ho medzi sebou cez underlay.
Control Plane kommunikuje medzi sebou medzi zónami dostupnosti cez BGP, ako s iným routerom. Hovoria, v akých strojoch je čo nasadené, aby virtuálne stroje v jednej zóne mohli priamo interagovať s inými virtuálnymi strojmi.
A Control Plane komunikuje aj s CloudGate. Analogicky poskytuje informácie o tom, kde a aké virtuálne stroje sú nasadené, aké majú adresy. To umožňuje nasmerovať na ne externý traffic a traffic od vyrovnávačov.
Traffic, ktorý vychádza z VPC, prichádza na CloudGate, do data path, kde rýchlo prechádza cez VPP s našimi pluginmi. Následne je traffic vystrieľaný buď do iných VPC, alebo von, do hraničných routerov, ktoré sú konfigurované cez Control Plane samotného CloudGate.
Plány na najbližšiu budúcnosť
Ak zhrnieme všetko povedané vyššie v niekoľkých vetách, môžeme povedať, že VPC v Yandex.Cloud rieši dve dôležité úlohy:
- Zabezpečuje izoláciu medzi rôznymi klientmi.
- Zlučuje zdroje, infraštruktúru, platformové služby, iné cloudu a on-premise do jednej siete.
Aby bolo možné tieto úlohy vykonávať dobre, je potrebné zabezpečiť škálovateľnosť a odolnosť voči chybám na úrovni vnútornej architektúry, čo VPC zabezpečuje.
Postupne VPC nadobúda funkcie, realizujeme nové možnosti, snažíme sa zlepšovať niečo z pohľadu pohodlia pre používateľov. Niektoré nápady sú vyslovené a dostávajú sa na prioritný zoznam vďaka účastníkom našej komunity.
Teraz máme približne takýto zoznam plánov na najbližšiu budúcnosť:
- VPN ako služba.
- Súkromné DNS inštancie – obrazy na rýchle nastavenie virtuálnych strojov s predkonfigurovaným DNS serverom.
- DNS ako služba.
- Interný vyvažovač zaťaženia.
- Pridanie "bielej" IP adresy bez potreby obnovovania virtuálneho stroja.
Vyvažovač a možnosť prepínať IP adresu pre už vytvorenú virtuálku sa dostali do tohto zoznamu na základe požiadaviek používateľov. Úprimne poviem, keby nebolo jasnej spätnej väzby, začali by sme s týmito funkciami o niečo neskôr. Ale už pracujeme na úlohe týkajúcej sa adries.
Pôvodne mohla byť "biela" IP adresa pridaná iba pri vytváraní stroja. Ak si používateľ na to zabudol, musel virtuálny stroj znova vytvoriť. To isté platilo aj v prípade, ak bolo potrebné odstrániť vonkajšiu IP. Čoskoro bude možné zapnúť a vypnúť verejnú IP bez obnovovania stroja.
Nebojte sa vyjadriť svoje nápady a podporiť návrhy iných používateľov. Pomáhate nám zlepšovať Cloud a rýchlejšie získavate dôležité a užitočné funkcie!
Zdroj: habr.com
