Ahoj, jmenuji se Kostya Kramlih, jsem vedoucí vývojář oddělení Virtuálního Privátního Cloudu ve Yandex.Cloud. Zabývám se virtuálními sítěmi a, jak asi tušíte, v tomto článku vám povím o architektuře Virtuálního Privátního Cloudu (VPC) a virtuální síti jako takové. Také se dozvíte, proč my, vývojáři této služby, oceňujeme zpětnou vazbu od našich uživatelů. Ale všechno pěkně popořádku.
Co je to VPC?
Dnes máme k dispozici různé možnosti pro nasazení služeb. Jsem si jistý, že někdo stále drží server pod stolem administrátora, i když doufám, že takových příběhů ubývá.
V současnosti se služby snaží migrovat do veřejných cloudů, a právě zde se setkávají s VPC. VPC je část veřejného cloudu, která spojuje uživatelské, infrastrukturní, platformní a další zdroje dohromady, bez ohledu na to, kde se nacházejí, ať už v našem cloudu nebo mimo něj. VPC také umožňuje, abyste tyto zdroje nezveřejňovali na internetu, ale zůstaly v rámci vaší izolované sítě.
Jak vypadá virtuální síť zvenčí
V rámci VPC rozumíme především overlay síti a síťovým službám, jako jsou VPNaaS, NATaas, LBaas atd. A to vše funguje nad odolnou síťovou infrastrukturou, o které se již psalo výborný článek na tomto místě na Habru.
Pojďme se blíže podívat na virtuální síť a její strukturu.
Prozkoumejme dvě zóny dostupnosti. Poskytujeme virtuální síť – to, čemu říkáme VPC. Ve skutečnosti definuje prostor jedinečnosti vašich „šedých“ adres. V rámci každé virtuální sítě plně spravujete adresní prostor, který můžete přiřadit výpočetním zdrojům.
Síť je globální. Projikuje se do každé zóny dostupnosti jako entita s názvem Subnet. Pro každou Subnet přiřazujete určité CIDR velikosti 16 nebo menší. V každé zóně dostupnosti může být více takových entit, přičemž mezi nimi vždy existuje transparentní routování. To znamená, že všechny vaše zdroje v rámci jedné VPC mohou „komunikovat“ navzájem, i když se nacházejí v různých zónách dostupnosti. „Komunikují“ bez opuštění internetových kanálů, po našich interních kanálech, „myslíce“, že jsou v rámci jedné soukromé sítě.
Na schémat je uvedena typická situace: dvě VPC, které se někde překrývají podle adres. Obě mohou patřit vám. Například jedna pro vývoj, druhá – pro testování. Mohou zde být také různí uživatelé – v tomto případě je to nepodstatné. A do každé VPC je zapojena jedna virtuální stroj.
Zhoršujeme schéma. Můžete to udělat tak, že jedno virtuální stroj se vloží najednou do několika Subnet. A ne jen tak, ale v různých virtuálních sítích.
Pokud potřebujete vystavit stroje na internet, můžete to udělat prostřednictvím API nebo UI. K tomu je třeba nastavit překlad NAT vašeho „šedého“, vnitřního adresu na „bílý“ – veřejný. „Bílou“ adresu si vybrat nemůžete, je přiřazena náhodně z našeho adresního poolu. Jakmile přestanete používat externí IP, vrátí se do poolu. Platíte pouze za dobu používání „bílé“ adresy.
Také je možné poskytnout stroji přístup na internet pomocí NAT-instance. Na instanci můžete přesměrovat provoz prostřednictvím statické tabulky směrování. Tento případ jsme zohlednili, protože je potřeba uživatelům a víme o tom. V našem katalogu obrazů se nachází speciálně nakonfigurovaný NAT-obraz.
Ale i když je připravený NAT-obraz, konfigurace může být složitá. Chápali jsme, že pro některé uživatele to není nejpohodlnější varianta, a proto jsme nakonec zavedli možnost zapnout NAT pro konkrétní Subnet jedním kliknutím. Tato funkce je zatím v uzavřeném preview přístupu, kde se testuje s pomocí členů komunity.
Jak je virtuální síť uspořádána zevnitř
Jak uživatel interaguje s virtuální sítí? Síť se dívá ven svým API. Uživatel přichází do API a pracuje s cílovým stavem. Prostřednictvím API uživatel vidí, jak by mělo být vše uspořádáno a nastaveno, přičemž vidí stav, jak moc se aktuální stav liší od požadovaného. To je pohled uživatele. A co se děje uvnitř?
Zápis požadovaného stavu do Yandex Database a přecházíme k konfiguraci různých částí naší VPC. Overlay síť v Yandex.Cloud je postavena na vybraných komponentách OpenContrail, který se v poslední době nazývá Tungsten Fabric. Síťové služby jsou realizovány na jedné platformě CloudGate. V CloudGate jsme také použili určité množství open source komponentů: GoBGP – pro dotazování na kontrolní informace, a také VPP – pro realizaci programového routeru, fungujícího nad DPDK pro data path.
Tungsten Fabric komunikuje s CloudGate přes GoBGP. Informuje o tom, co se děje v overlay síti. CloudGate zase propojuje overlay sítě navzájem a s internetem.
Nyní se podívejme, jak virtuální síť řeší problémy s škálováním a dostupností. Podíváme se na jednoduchý případ. Máme jednu zónu dostupnosti, ve které jsou vytvořeny dvě VPC. Nasadili jsme jeden instance Tungsten Fabric, která pojme několik desítek tisíc sítí. Sítě jsou spojeny s CloudGate. CloudGate, jak už jsme řekli, zajišťuje jejich propojení mezi sebou a s internetem.
Předpokládejme, že se přidává druhá zóna dostupnosti. Ta by měla být plně nezávislá na první. Proto musíme ve druhé zóně dostupnosti nasadit samostatnou instanci Tungsten Fabric. Bude to samostatný systém, který se stará o overlay a má málo informací o první systému. A viditelnost, že naše virtuální síť je globální, vlastně vytváří náš VPC API. To je jeho úkol.
VPC1 se promítá do zóny dostupnosti B, pokud v zóně dostupnosti B jsou zdroje, které se připojují k VPC1. Pokud v zóně dostupnosti B nejsou žádné zdroje z VPC2, VPC2 v této zóně nematerializujeme. Naopak, protože zdroje z VPC3 existují pouze v zóně B, VPC3 není v zóně A. Všechno je jednoduché a logické.
Pojďme se podívat hlouběji a zjistit, jak je konkrétní host v Yandex.Cloud uspořádán. Hlavní, co chceme zdůraznit, je, že všechny hosty jsou uspořádány stejně. Děláme to tak, že pouze nezbytné minimum služeb běží na 'železe', všechny ostatní fungují na virtual machines. Budujeme služby vyšší úrovně na základě základních infrastrukturních služeb a také využíváme Cloud pro řešení některých inženýrských úkolů, například v rámci Continuous Integration.
Podíváme-li se na konkrétní hostitel, uvidíme, že na hostitelském systému běží tři komponenty:
- Compute – část, která se stará o rozdělení výpočetních zdrojů na hostiteli.
- VRouter – část Tungsten Fabric, která organizuje overlay, tedy tuneluje pakety přes underlay.
- VDisk – to jsou kusy virtualizace úložiště.
Kromě toho jsou virtual machines spuštěny služby: infrastrukturální služby Cloudu, platformové služby a kapacity zákazníků. Kapacity zákazníků a platformové služby vždy běží v overlay přes VRouter.
Infrastrukturální služby mohou být napojeny na overlay, ale většinou chtějí pracovat právě v underlay. Do underlay se napojují pomocí SR-IOV. V podstatě rozdělujeme kartu na virtuální síťové karty (virtuální funkce) a zavádíme je do infrastrukturálních virtuálních strojů, abychom neztráceli výkon. Například ten známý CloudGate je spuštěn jako jedna z těchto infrastrukturálních virtuálních strojů.
Nyní, když jsme popsali globální úkoly virtuální sítě a strukturu základních komponentů cloudu, pojďme se podívat, jak konkrétně různé části virtuální sítě spolu komunikují.
V naší systému rozlišujeme tři úrovně:
- Config Plane – nastavuje cílový stav systému. To, co uživatel konfiguruje přes API.
- Control Plane – zajišťuje uživatelsky definovanou sémantiku, tedy přivádí stav Data Plane do podoby, kterou uživatel popsal v Config Plane.
- Data Plane – přímo zpracovává pakety uživatele.
Jak jsem již zmínil, vše začíná tím, že uživatel nebo interní platformová služba přichází do API a popisuje určité cílové nastavení.
Tento stav je okamžitě zapsán do Yandex Database, vrací přes API ID asynchronní operace a spouští naši interní mašinerii, aby vydala stav, který uživatel chtěl. Konfiguracní úkoly jdou do SDN kontroléru a říkají Tungsten Fabric, co je třeba udělat v overlay. Například si rezervují porty, virtuální sítě a podobně.
Config Plane v Tungsten Fabric dodává do Control Plane požadovaný stav. Přes něj Config Plane komunikuje s hostiteli a říká jim, co se na nich brzy spustí.
Nyní se podívejme, jak vypadá systém na hostitelích. V virtuálním stroji Existuje určitý síťový adaptér zapojený do VRouteru. VRouter je jádrový modul Tungsten Fabric, který sleduje pakety. Pokud pro určitý paket již existuje flow, modul jej zpracovává. Pokud flow není, modul provede takzvané punting, což znamená, že pošle paket do uživatelského procesu. Proces rozebere paket a buď na něj odpoví sám, jako například na DHCP a DNS, nebo řekne VRouteru, co s ním má dělat. Poté může VRouter zpracovávat paket.
Dále veškerý provoz mezi virtuálními stroji v rámci jedné virtuální sítě probíhá transparentně, není směrován na CloudGate. Hostitelé, na kterých jsou nasazeny virtuální stroje, komunikují mezi sebou přímo. Tunelují provoz a přenášejí ho mezi sebou skrze underlay.
Control Plane komunikuje mezi zónami dostupnosti pomocí BGP, jako s jiným routerem. Říkají si, které stroje jsou kde spuštěny, aby virtuální stroje v jedné zóně mohly přímo interagovat s dalšími virtuálními stroji.
A Control Plane také komunikuje s CloudGate. Podobně oznamuje, kde a jaké virtuální stroje jsou spuštěny, jaké mají adresy. To umožňuje směrovat na ně externí provoz a provoz od vyvažovačů.
Provoz, který opouští VPC, přichází na CloudGate, do data path, kde je rychle zpracován VPP s našimi pluginy. Dále je provoz vyslán buď do jiných VPC, nebo ven, do hraničních routerů, které jsou konfigurovány prostřednictvím Control Plane samotného CloudGate.
Plány na nejbližší budoucnost
Pokud shrneme vše výše uvedené do několika vět, můžeme říci, že VPC v Yandex.Cloud řeší dvě důležité úkoly:
- Zajišťuje izolaci mezi různými klienty.
- Spojuje zdroje, infrastrukturu, platformové služby, jiné cloudu a on-premise do jediné sítě.
A aby tyto úkoly plnil dobře, je třeba zajistit škálovatelnost a odolnost na úrovni vnitřní architektury, což VPC skutečně dělá.
Postupně VPC získává nové funkce, realizujeme nové možnosti, snažíme se zlepšovat něco v oblasti uživatelské pohodlnosti. Některé nápady jsou vyřčeny a dostávají se na seznam priorit díky účastníkům naší komunity.
Nyní máme přibližně takový seznam plánů na nejbližší budoucnost:
- VPN jako služba.
- Instancí soukromého DNS – obrazy pro rychlé nastavení virtuálních strojů s předkonfigurovaným DNS serverem.
- DNS jako služba.
- Interní vyvažovač zátěže.
- Přidání 'bílého' IP adresy bez nutnosti opětovného vytvoření virtuálního stroje.
Vyvažovač zátěže a možnost přepínat IP adresu pro již vytvořenou virtuální mašinu se ocitli tento seznam na žádost uživatelů. Řeknu upřímně, bez jasné zpětné vazby bychom se těchto funkcí chopili o něco později. Takto na úkolu ohledně adres již pracujeme.
Zprvu bylo možné přidat 'bílou' IP adresu pouze při vytváření stroje. Pokud si uživatel na to nevzpomněl, bylo nutné virtuální stroj znovu vytvořit. Totéž platilo při potřebě odebrat externí IP. Brzy bude možné veřejný IP zapínat a vypínat, aniž by bylo nutné stroj znovu vytvářet.
Neváhejte vyjádřit své nápady a podporovat návrhy ostatních uživatelů. Pomáháte nám zlepšovat Cloud a rychleji získávat důležité a užitečné funkce!
Zdroj: habr.com
