Dobrý den, jmenuji se Kostya Kramlikh, jsem hlavní vývojář divize Virtual Private Cloud v Yandex.Cloud. Jsem virtuální networker, a jak asi tušíte, v tomto článku budu hovořit o zařízení Virtual Private Cloud (VPC) obecně a o virtuální síti konkrétně. A také se dozvíte, proč si my, vývojáři služby, ceníme zpětné vazby od našich uživatelů. Ale nejdřív.
Co je VPC?
V dnešní době existuje celá řada možností pro nasazení služeb. Jsem si jistý, že někdo stále drží server pod stolem správce, i když doufám, že takových příběhů bude méně.
Nyní se služby snaží přejít do veřejných cloudů a zde se střetávají s VPC. VPC je součástí veřejného cloudu, který spojuje uživatele, infrastrukturu, platformu a další kapacity, ať už jsou kdekoli, v našem Cloudu nebo mimo něj. VPC vám zároveň umožňuje tyto kapacity zbytečně nevystavovat internetu, zůstávají v rámci vaší izolované sítě.
Jak virtuální síť vypadá zvenčí?
VPC máme na mysli především překryvnou síť a síťové služby, jako jsou VPNaaS, NATaas, LBaas atd. A to vše funguje na síťové infrastruktuře odolné proti chybám, která již byla tady, na Habré.
Podívejme se blíže na virtuální síť a její zařízení.
Zvažte dvě zóny dostupnosti. Poskytujeme virtuální síť – to, čemu jsme říkali VPC. Ve skutečnosti vymezuje prostor jedinečnosti vašich „šedých“ adres. V rámci každé virtuální sítě máte úplnou kontrolu nad prostorem adres, které můžete přiřadit výpočetním prostředkům.
Síť je globální. Zároveň se promítá do každé zóny dostupnosti v podobě entity zvané Subnet. Pro každou podsíť přiřadíte CIDR o velikosti 16 nebo méně. V každé zóně dostupnosti může být více než jedna taková entita a mezi nimi je vždy transparentní směrování. To znamená, že všechny vaše zdroje v rámci stejného VPC spolu mohou „mluvit“, i když jsou v různých zónách dostupnosti. „Komunikovat“ bez přístupu k internetu prostřednictvím našich interních kanálů a „myslet si“, že jsou ve stejné privátní síti.
Výše uvedený diagram ukazuje typickou situaci: dvě VPC, která se někde protínají v adresách. Obojí může být vaše. Například jeden pro vývoj, druhý pro testování. Mohou prostě existovat různí uživatelé – v tomto případě na tom nezáleží. A do každého VPC je zapojen jeden virtuální stroj.
Pojďme to schéma zhoršit. Můžete to udělat tak, že jeden virtuální stroj je zaseknutý do několika podsítí najednou. A nejen tak, ale v různých virtuálních sítích.
Zároveň, pokud potřebujete vystavit stroje internetu, lze to provést prostřednictvím API nebo uživatelského rozhraní. Chcete-li to provést, musíte nakonfigurovat překlad NAT vaší „šedé“, interní adresy, na „bílou“ - veřejnou. Nemůžete si vybrat "bílou" adresu, je přidělena náhodně z naší zásoby adres. Jakmile přestanete používat externí IP, vrátí se do fondu. Platíte pouze za dobu používání „bílé“ adresy.
Je také možné dát stroji přístup k internetu pomocí instance NAT. Provoz můžete směrovat do instance prostřednictvím statické směrovací tabulky. Poskytli jsme takový případ, protože ho uživatelé někdy potřebují a víme o tom. V souladu s tím náš katalog obrazů obsahuje speciálně nakonfigurovaný obraz NAT.
Ale i když je připraven NAT obraz, může být nastavení složité. Pochopili jsme, že pro některé uživatele to není nejpohodlnější možnost, a tak jsme nakonec umožnili povolit NAT pro požadovanou Subnet jedním kliknutím. Tato funkce je stále v uzavřeném náhledovém přístupu, kde je testována za pomoci členů komunity.
Jak je virtuální síť uspořádána zevnitř
Jak uživatel komunikuje s virtuální sítí? Web vypadá se svým API směrem ven. Uživatel přijde do API a pracuje s cílovým stavem. Prostřednictvím API uživatel vidí, jak má být vše uspořádáno a konfigurováno, zároveň vidí stav, jak moc se skutečný stav liší od požadovaného. Toto je obrázek uživatele. Co se děje uvnitř?
Zapíšeme požadovaný stav do databáze Yandex a přejdeme ke konfiguraci různých částí našeho VPC. Překryvná síť v Yandex.Cloud je založena na vybraných komponentách OpenContrail, který byl nedávno nazván Tungsten Fabric. Síťové služby jsou implementovány na jediné CloudGate platformě. V CloudGate jsme také použili řadu open source komponent: GoBGP – pro přístup k řídicím informacím, a také VPP – k implementaci softwarového routeru, který běží na DPDK pro datovou cestu.
Tungsten Fabric komunikuje s CloudGate přes GoBGP. Říká, co se děje v překryvné síti. CloudGate zase propojuje překryvné sítě mezi sebou a s internetem.
Nyní se podívejme, jak virtuální síť řeší problémy škálování a dostupnosti. Podívejme se na jednoduchý případ. Existuje jedna zóna dostupnosti a jsou v ní vytvořeny dvě VPC. Nasadili jsme jednu instanci Tungsten Fabric, která stahuje několik desítek tisíc sítí. Sítě komunikují s CloudGate. CloudGate, jak jsme již řekli, zajišťuje jejich konektivitu mezi sebou i s internetem.
Řekněme, že je přidána druhá zóna dostupnosti. Mělo by selhat zcela nezávisle na prvním. Proto v druhé zóně dostupnosti musíme nainstalovat samostatnou instanci Tungsten Fabric. Toto bude samostatný systém, který se zabývá překrytím a o prvním systému ví jen málo. A viditelnost, že naše virtuální síť je globální, ve skutečnosti vytváří naše VPC API. To je jeho úkol.
VPC1 je mapován do zóny dostupnosti B, pokud jsou v zóně dostupnosti B zdroje, které jsou posunuty do VPC1. Pokud v zóně dostupnosti B nejsou žádné zdroje z VPC2, VPC2 v této zóně nezhmotníme. Na druhé straně, protože zdroje z VPC3 existují pouze v zóně B, VPC3 neexistuje v zóně A. Vše je jednoduché a logické.
Pojďme trochu hlouběji a podívejme se, jak konkrétní hostitel v Y.Cloud funguje. Hlavní věc, kterou chci poznamenat, je, že všichni hostitelé jsou uspořádáni stejným způsobem. Děláme to tak, že na hardwaru běží jen nezbytné minimum služeb, všechny ostatní běží na virtuálních strojích. Stavíme služby vyššího řádu založené na základních infrastrukturních službách a také využíváme Cloud k řešení některých inženýrských problémů, například v rámci kontinuální integrace.
Pokud se podíváme na konkrétního hostitele, můžeme vidět, že na hostitelském OS běží tři komponenty:
- Compute – část odpovědná za distribuci výpočetních zdrojů na hostiteli.
- VRouter je součástí Tungsten Fabric, která organizuje překrytí, to znamená, že tuneluje pakety přes podložení.
- VDisk jsou kusy virtualizace úložiště.
Kromě toho jsou služby spouštěny ve virtuálních strojích: služby cloudové infrastruktury, služby platforem a kapacity zákazníků. Kapacity zákazníků a služby platformy vždy jdou do překryvu přes VRouter.
Infrastrukturní služby se mohou nalepit na překrytí, ale v podstatě chtějí fungovat v překrytí. Do podložky se zapíchnou pomocí SR-IOV. Ve skutečnosti jsme kartu rozřezali na virtuální síťové karty (virtuální funkce) a natlačili je do infrastrukturních virtuálních strojů, abychom neztratili výkon. Například je spuštěn stejný CloudGate jako jeden z těchto infrastrukturních virtuálních strojů.
Nyní, když jsme popsali globální úkoly virtuální sítě a strukturu základních komponent cloudu, podívejme se, jak přesně na sebe jednotlivé části virtuální sítě vzájemně působí.
V našem systému rozlišujeme tři vrstvy:
- Config Plane - nastavuje cílový stav systému. To je to, co uživatel konfiguruje přes API.
- Řídicí rovina - poskytuje uživatelem definovanou sémantiku, to znamená, že přivádí stav datové roviny do stavu popsaného uživatelem v rovině konfigurace.
- Data Plane – přímo zpracovává pakety uživatele.
Jak jsem řekl výše, vše začíná tím, že uživatel nebo služba interní platformy přichází do API a popisuje určitý cílový stav.
Tento stav se okamžitě zapíše do databáze Yandex, vrátí ID asynchronní operace přes API a spustí naše interní zařízení, aby vrátil stav, který uživatel chtěl. Konfigurační úlohy jdou do řadiče SDN a říkají Tungsten Fabric, co má v překrytí udělat. Například rezervují porty, virtuální sítě a podobně.
Konfigurační rovina v Tungsten Fabric odešle požadovaný stav do řídicí roviny. Prostřednictvím něj Config Plane komunikuje s hostiteli a říká, co přesně se na nich brzy bude točit.
Nyní se podívejme, jak systém vypadá na hostitelích. Virtuální počítač má síťový adaptér zapojený do VRouteru. VRouter je základní modul Tungsten Fabric, který se dívá na pakety. Pokud již existuje tok pro nějaký balíček, modul jej zpracuje. Pokud nedochází k žádnému toku, modul provede tzv. punting, to znamená, že odešle paket do procesu usermod. Proces analyzuje paket a buď na něj sám odpoví, jako DHCP a DNS, nebo řekne VRouteru, co s ním má dělat. Poté může VRouter zpracovat paket.
Dále provoz mezi virtuálními stroji v rámci stejné virtuální sítě probíhá transparentně, není směrován do CloudGate. Hostitelé, na kterých jsou virtuální stroje nasazeny, spolu komunikují přímo. Tunelují dopravu a předávají si ji přes podložku.
Řídicí roviny spolu komunikují mezi zónami dostupnosti přes BGP, stejně jako s jiným routerem. Říkají, které počítače jsou kde nahoře, takže virtuální počítače v jedné zóně mohou přímo komunikovat s jinými virtuálními počítači.
A Control Plane komunikuje s CloudGate. Podobně hlásí, kde a které virtuální stroje jsou vyvolány, jaké mají adresy. To vám umožní nasměrovat externí provoz a provoz z balancerů na ně.
Provoz, který opouští VPC, přichází do CloudGate, do datové cesty, kde je VPP s našimi pluginy rychle rozžvýkaný. Poté je provoz směrován buď do jiných VPC nebo mimo, na hraniční směrovače, které jsou konfigurovány prostřednictvím řídicí roviny samotné CloudGate.
Plány na blízkou budoucnost
Pokud shrneme vše výše uvedené do několika vět, můžeme říci, že VPC v Yandex.Cloud řeší dva důležité úkoly:
- Poskytuje izolaci mezi různými klienty.
- Kombinuje zdroje, infrastrukturu, platformové služby, další cloudy a on-premise do jediné sítě.
A abyste tyto problémy dobře vyřešili, musíte zajistit škálovatelnost a odolnost proti chybám na úrovni vnitřní architektury, což VPC dělá.
Postupně VPC získává funkce, implementujeme nové funkce, snažíme se něco vylepšit z hlediska uživatelského komfortu. Některé nápady jsou vysloveny a dostávají se na seznam priorit díky členům naší komunity.
V současné době máme následující seznam plánů na blízkou budoucnost:
- VPN jako služba
- Soukromé instance DNS jsou obrazy pro rychlé nastavení virtuálních počítačů s předem nakonfigurovaným serverem DNS.
- DNS jako služba.
- Vnitřní vyvažovač zátěže.
- Přidání „bílé“ IP adresy bez opětovného vytvoření virtuálního počítače.
Balancér a možnost přepnout IP adresu pro již vytvořený virtuální stroj byly na tomto seznamu na žádost uživatelů. Abych byl upřímný, bez explicitní zpětné vazby bychom tyto funkce převzali o něco později. A tak už pracujeme na problému s adresami.
Zpočátku bylo možné „bílou“ IP adresu přidat pouze při vytváření stroje. Pokud to uživatel zapomněl udělat, musel být virtuální stroj vytvořen znovu. Totéž a v případě potřeby odstraňte externí IP. Brzy bude možné veřejnou IP zapínat a vypínat bez nutnosti znovu vytvářet stroj.
Neváhejte a vyjádřete svůj ostatní uživatelé. Pomáháte nám zlepšovat cloud a rychleji získávat důležité a užitečné funkce!
Zdroj: www.habr.com