V předchozím vydání Popisoval jsem rámec síťové automatizace. Podle názorů se u některých lidí dokonce tento první přístup k problému rozložil některé otázky na jednotlivé části. A to mě velmi těší, protože naším cílem v cyklu není pokrýt Ansible skripty, ale vybudovat systém.

Tento rámec určuje pořádek, ve kterém se budeme zabývat otázkou.
A virtualizace sítě, které se tento díl věnuje, se příliš nehodí do tematiky ADSM, kde se zabýváme automatikou.

Ale pojďme se na ni podívat z jiného úhlu.

Už dávno používá jednu síť mnoho služeb. V případě operátora je to 2G, 3G, LTE, ŠP a B2B, například. V případě datových center: konektivita pro různé klienty, internet, blokové úložiště, objektové úložiště.

A všechny služby vyžadují izolaci navzájem. Tak vznikly overlayové sítě.

A všechny služby nechtějí čekat, až je někdo nastaví ručně. Tak se objevily orchestrátory a SDN.

První přístup k systematické automatizaci sítě, přesněji její části, byl již dávno podniknut a na mnoha místech zaveden do praxe: VMWare, OpenStack, Google Compute Cloud, AWS, Facebook.

S tím se dnes také podíváme.

Obsah

Důvody
Terminologie
Underlay — fyzická síť
Overlay — virtuální síť
- Overlay z ToR
- Overlay z hostitele
- Na příkladu Tungsten Fabric
  - Komunikace uvnitř jednoho fyzického stroje
  - Komunikace mezi VM umístěnými na různých fyzických strojích
  - Výstup do vnějšího světa
Často kladené dotazy
Závěr
Užitečné odkazy

Důvody

A jelikož jsme o tom začali mluvit, stojí za zmínku předpoklady pro virtualizaci sítě. Opravdu tento proces nezačal včera.

Pravděpodobně jste nesčetněkrát slyšeli, že síť byla vždy tou nejnepodajnější částí jakéhokoli systému. A to je pravda ve všech ohledech. Síť je základem, na kterém všechno stojí, a provádět změny na ní je docela složité — služby nesnášejí, když síť nefunguje. Často výpadek jednoho uzlu může ovlivnit velkou část aplikací a mnoho klientů. Částečně proto se síťový tým může bránit jakýmkoli změnám — protože to teď nějak funguje (možná ani nevíme jak), a teď je potřeba něco nového nastavit a není jasné, jak to ovlivní síť.

Aby se lidé nemuseli dožadovat toho, když síťaři aktivují VLAN, a nemuseli zapisovat jakékoli služby na každý uzel sítě, vymysleli možnost používat overlaye — překryté sítě — kterých je mnoho různých typů: GRE, IPinIP, MPLS, MPLS L2/L3VPN, VXLAN, GENEVE, MPLSoverUDP, MPLSoverGRE atd.

Jejich přitažlivost spočívá ve dvou jednoduchých věcech:

Konfigurují se pouze koncové uzly — transitní se nemusí dotýkat. To výrazně urychluje proces a někdy dokonce umožňuje zcela vyloučit oddělení síťové infrastruktury z procesu zavádění nových služeb.
Zátěž je skryta hluboko uvnitř hlaviček — transitní uzly o ní nemusí nic vědět, o adresování na hostitelích, trasách překryté sítě. To znamená, že je třeba uchovávat méně informací v tabulkách, což znamená použít jednodušší/levnější zařízení.

V tomto ne úplně kompletním vydání nemám v plánu rozebírat všechny možné technologie, spíše popíšu rámec fungování overlayových sítí v datovém centru.

Celá série bude popisovat datové centrum složené z řad stejnorodých skříní, v nichž je nainstalováno stejné serverové vybavení.

Na tomto vybavení běží virtuální stroje/kontejnery/serverless, které realizují služby.

Terminologie

V cyklu serverem budu nazývat program, který realizuje serverovou část klient-server komunikace.

Fyzické stroje v skříních budeme nazývat servery. ne Fyzická stroj

je x86 počítač umístěný v racku. Nejčastěji používaný termín je . Tak ji budeme nazývat „ hoststroj“ neboHypervisor host.

je aplikace běžící na fyzickém stroji, která emuluje fyzické zdroje, na nichž běží virtuální stroje. Někdy se v literatuře a na internetu slovo „hypervisor“ používá jako synonymum pro „host“. je operační systém běžící na fyzickém stroji nad hypervisorem. Pro nás v rámci tohoto cyklu není až tak důležité, zda jde skutečně o virtuální stroj nebo jen kontejner. Budeme to nazývat „

Virtuální stroj VMTenat«

je široký termín, který v tomto článku vydefinuji jako samostatnou službu nebo jednotlivého klienta. Multitenantnost

nebo multi-tenanting je využívání jedné a téže aplikace různými klienty/službami. Přičemž izolace klientů navzájem je dosaženo díky architektuře aplikace, a ne samostatně spuštěným instancím. ToR — Top of the Rack switch

ToR — switč na vrcholu skříně — serverový switch umístěný v racku, ke kterému jsou připojeny všechny fyzické stroje.

Kromě topologie ToR různí poskytovatelé praktikují End of Row (EoR) nebo Middle of Row (i když to poslední je opomíjená vzácnost a zkratky MoR jsem neslyšel).

Podkladová síť nebo podkladová síť nebo underlay — fyzická síťová infrastruktura: switche, routovacie zařízení, kabely.

Nadložní síť nebo nadložní síť nebo overlay — virtuální síť tunelů fungujících nad fyzickou infrastrukturou.

L3-fabrika nebo IP-fabrika — ohromné vynález lidstva, které umožňuje na pohovorech nezapomínat na STP a neučit se TRILL. Koncept, ve kterém je celá síť od úrovně přístupu výhradně L3, bez VLAN a tím pádem obrovských rozlehlých širokých domén. Odkud se vzalo slovo „fabrika“, to prozkoumáme v následující části.

SDN — Software Defined Network. Sotva potřebuje představení. Přístup k řízení sítě, kdy změny na síti provádí program, nikoli člověk. Obvykle znamená přesun Control Plane za hranice koncových síťových zařízení na kontrolér.

NFV — Network Function Virtualization — virtualizace síťových zařízení, která předpokládá, že část funkcí sítě může být spuštěna jako virtuální stroje nebo kontejnery za účelem urychlení zavádění nových služeb, organizace Service Chaining a jednodušší horizontální škálovatelnosti.

VNF — Virtual Network Function. Konkrétní virtuální zařízení: router, switch, firewall, NAT, IPS/IDS atd.

Schválně nyní zjednodušuji popis na konkrétní implementaci, aby čtenáře příliš nezmátl. Pro důkladnější čtení ho odkazuji na sekci Odkazy. Kromě toho Roman Horge, kritizující tento článek za nepřesnosti, slibuje napsat samostatné číslo o technologiích virtualizace serverů a sítí, které bude podrobnější a zaměří se na detaily.

Většinu sítí dnes lze jasně rozdělit na dvě části:

Podkladová — fyzická síť se stabilní konfigurací.
Nadložní — abstrakce nad podkladovou sítí pro izolaci tenantů.

To platí jak pro případ datových center (který se v tomto článku probereme), tak pro ISP (který nebudeme rozebírat, protože to již bylo v SDN). Se sítí pro podniky je situace samozřejmě poněkud odlišná.

Obrázek se zaměřením na síť:

Podkladová

Underlay — je fyzická síť: hardwarové switche a kabely. Zařízení v underlay vědí, jak se dostat k fyzickým strojům.

Spoléhá na standardní protokoly a technologie. Ne poslední řadě proto, že hardwarová zařízení pracují na proprietárním softwaru, který neumožňuje programování čipu ani implementaci vlastních protokolů, a proto je potřeba kompatibilita s jinými dodavateli a standardizace.

Ale někdo jako Google si může dovolit vyvinout vlastní switche a vzdát se obecně uznávaných protokolů. Ale LAN_DC není Google.

Underlay se poměrně zřídka mění, protože jeho úkolem je základní IP konektivita mezi fyzickými stroji. Underlay neví nic o službách, klientech, tenantech běžících nad ním — potřebuje pouze doručit paket z jednoho stroje na druhý.
Underlay může být například takovýto:

IPv4+OSPF
IPv6+ISIS+BGP+L3VPN
L2+TRILL
L2+STP

Underlay síť se nastavuje klasickým způsobem: CLI/GUID/NETCONF.

Manuálně, skripty, proprietárními utilitami.

Další podrobnosti o underlay budou předmětem dalšího článku v této sérii.

Nadložní

Overlay — virtuální síť tunelů, natáhnutá nad Underlay, umožňuje VM jednoho klienta komunikovat mezi sebou, přičemž zajišťuje izolaci od ostatních klientů.

Data klienta jsou inkapsulována do nějakých tunelovacích hlaviček pro přenos přes společnou síť.

Tak VM jednoho klienta (jedné služby) mohou komunikovat mezi sebou přes Overlay, aniž by měly tušení, jakou cestu paket ve skutečnosti zabírá.

Overlay může být například takový, jak jsem již zmínil výše:

GRE-tunel
VXLAN
EVPN
L3VPN
GENEVE

Overlay síť se obvykle nastavuje a udržuje přes centrální kontrolér. Odtud je konfigurace, Control Plane a Data Plane doručována na zařízení, která se zabývají směrováním a inkapsulací klientského provozu. Trochu níže to rozebereme na příkladech.

Ano, toto je SDN v čisté podobě.

Existují dva zásadně odlišné přístupy k organizaci Overlay sítě:

Overlay z ToR
Overlay z hostitele

Overlay z ToR

Overlay může začínat na přístupovém switchi (ToR) umístěném v racku, jak tomu bývá například v případě VXLAN fabric.

To je prověřený mechanismus v sítích ISP a všichni dodavatelé síťových zařízení ho podporují.

V tomto případě musí ToR přepínač umět oddělovat různé služby, přičemž síťový administrátor by měl do určité míry spolupracovat s administrátory virtuálních strojů a automaticky provádět změny v konfiguraci zařízení.

Odkazuji čtenáře na článek o VxLAN na Habr našeho starého přítele @bormoglotx.
V této prezentace z ENOG podrobně popisuje přístupy k výstavbě DC s EVPN VXLAN fabrikou.

Pro podrobnější pochopení reality si můžete přečíst knihu od Cisco A Modern, Open, and Scalable Fabric: VXLAN EVPN.

Poznamenávám, že VXLAN je pouze metoda enkapsulace a terminace tunelů může probíhat nikoli na ToR, ale na hostiteli, jak se to děje například v případě OpenStacku.
Nicméně, VXLAN fabrika, kde přehled začíná na ToR, je jedním z ustálených návrhů overlay sítě.

Overlay z hostitele

Druhý přístup je začít a ukončit tunely na koncových hostech.
V tomto případě zůstává síť (Underlay) co nejjednodušší a statická.
Hostitel pak provádí všechny potřebné enkapsulace.

K tomu bude samozřejmě nutné spustit speciální aplikaci na hostitelích, ale stojí to za to.

Za prvé, spuštění klienta na linuxovém stroji je jednodušší, nebo lépe řečeno — vůbec možné — zatímco na přepínači pravděpodobně bude nutné se zatím obrátit na proprietární SDN řešení, což zabíjí myšlenku multivendoru.

Za druhé, ToR přepínač lze v tomto případě nechat co nejjednodušší, jak z hlediska Control Plane, tak Data Plane. Opravdu — s SDN kontrolerem se nemusí komunikovat a také uchovávat sítě/ARP všech připojených klientů — stačí znát IP adresu fyzického stroje, což výrazně zjednodušuje tabulky přepínání/routování.

V sérii ADSM volím přístup overlay z hosta — dále budeme mluvit pouze o něm a k VXLAN fabrice se již nebudeme vracet.

Nejlépe to lze ilustrovat na příkladech. A jako laboratoř vezmeme open-source SDN platformu OpenContrail, dnes známou jako Tungsten Fabric.

Na konci článku uvedu několik úvah o analogii s OpenFlow a OpenvSwitch.

Na příkladu Tungsten Fabric

Na každém fyzickém stroji je vRouter — virtuální router, který zná připojené sítě a kterým klientům patří — v podstatě — PE-router. Pro každého klienta udržuje izolovanou tabulku směrování (čti VRF). A samotný vRouter provádí tunelování přes Overlay.

Trochu podrobněji o vRouteru — na konci článku.

Každá VM umístěná na hypervizoru se připojuje k vRouteru této mašiny přes TAP rozhraní.

TAP — Terminal Access Point — virtuální rozhraní v jádře Linuxu, které umožňuje provádět síťovou komunikaci.

Pokud je za vRouterem několik sítí, pro každou z nich se vytváří virtuální rozhraní, na které se přiřazuje IP adresa — ta bude adresou brány pro výchozí nastavení.
Všechny sítě jednoho klienta jsou umístěny v jednom VRF (jedné tabulce), různé — v různé.
Udělám zde poznámku, že to není tak jednoduché, a pošlu zvídavého čtenáře na konec článku..

Aby si vRoutery mohly vzájemně komunikovat, a tím i VM, které jsou za nimi, vyměňují si směrovací informace přes SDN kontroler.

Abychom se dostali do vnějšího světa, existuje výstupní bod z matice — brána virtuální sítě VNGW — Virtual Network GateWay (můj termín).

Nyní si probereme příklady komunikací — a bude jasno.

Komunikace uvnitř jednoho fyzického stroje

VM0 chce poslat paket na VM2. Předpokládejme zatím, že se jedná o VM jednoho klienta.

Data Plane

VM-0 má výchozí trasu na jeho rozhraní eth0. Paket je odeslán tam.
Toto rozhraní eth0 je ve skutečnosti virtuálně spojeno s virtuálním routerem vRouter přes TAP rozhraní tap0.
vRouter analyzuje, na které rozhraní paket přišel, tj. ke kterému klientovi (VRF) patří, srovnává adresu příjemce s tabulkou směrování tohoto klienta.
Zjišťujíc, že příjemce je na této mašině za jiným portem, vRouter jednoduše odešle paket tam bez jakýchkoli dalších hlaviček — v tomto případě má vRouter již ARP záznam.

Paket se v tomto případě nedostane do fyzické sítě — byl zpracován uvnitř vRouteru.

Control Plane

Hypervizor při spuštění virtuálního stroje jí oznámí:

Její vlastní IP adresu.
Výchozí trasa — přes IP adresu vRouteru v této síti.

vRouteru přes speciální API hypervizor oznámí:

Že je třeba vytvořit virtuální rozhraní.
Jakou potřebuje (VM) vytvořit Virtuální síť.
K jakému VRF ji (VN) připojit.
Statická ARP záznam pro tuto VM — za kterým rozhraním se nachází její IP adresa a ke kterému MAC adresa je přiřazena.

Znovu, skutečný postup interakce je zjednodušen ve prospěch pochopení konceptu.

Takže všechny VM jednoho klienta na tomto stroji vRouter vidí jako přímo připojené sítě a mohou mezi nimi samy směrovat.

VM0 a VM1 patří různým klientům, a proto se nacházejí v různých tabulkách vRouteru.

Zda budou moci komunikovat přímo, závisí na nastavení vRouteru a návrhu sítě.
Například, pokud VM obou klientů používají veřejné adresy nebo NAT se provádí přímo na vRouteru, lze provést i přímé směrování na vRouter.

Naopak v jiné situaci může dojít ke kolizi adresových prostorů — je nutné přejít přes NAT server, aby se získala veřejná adresa — to vypadá jako výstup do externích sítí, o kterých bude podrobněji zmíněno níže.

Komunikace mezi VM umístěnými na různých fyzických strojích

Data Plane

Začátek je přesně stejný: VM-0 posílá paket adresátovi VM-7 (172.17.3.2) podle svého výchozímu nastavení.
vRouter jej přijímá a tentokrát vidí, že adresát je na jiném stroji a je dostupný přes tunel Tunnel0.
Nejprve přidává MPLS označení, které identifikuje vzdálené rozhraní, aby na opačné straně vRouter mohl určit, kam tento paket umístit, a to bez dodatečných obchvatů.
Tunnel0 má zdroj 10.0.0.2, příjemce: 10.0.1.2.
vRouter přidává GRE (nebo UDP) hlavičky a novou IP k výchozímu paketu.
V tabulce směrování vRouteru je výchozí trasa přes adresu ToR1 10.0.0.1. Tam a posílá.
ToR1 jako účastník Underlay sítě ví (například z OSPF), jak se dostat k 10.0.1.2, a odesílá paket podle trasy. Všimněte si, že zde se zapíná ECMP. Na ilustraci jsou dvě next-hopy, a různé toky se do nich rozloží podle hash. V případě skutečné továrny by zde bylo spíše 4 next-hopy.
Přitom vědět, co se nachází pod vnějším IP záhlavím, není třeba. Tedy fakticky pod IP může být sendvič z IPv6 přes MPLS přes Ethernet přes MPLS přes GRE přes....
Na přijímací straně tedy vRouter odejme GRE a podle MPLS označení určí, do kterého rozhraní má tento paket poslat, odstraní ho a pošle ho v původní podobě příjemci.

Control Plane

Při spuštění stroje se děje to samé, co bylo popsáno výše.

A navíc ještě následující:

Pro každého klienta vRouter přiděluje MPLS značku. To je servisní značka L3VPN, podle které budou klienti rozděleni v rámci jednoho fyzického zařízení.
Ve skutečnosti je MPLS značka nepodmíněně přidělována vRouterem — nikdo dopředu neví, že se stroj bude komunikovat pouze s jinými stroji za tímto vRouterem, a to pravděpodobně ani není pravda.
vRouter navazuje spojení s SDN kontrolérem přes protokol BGP (nebo podobný — v případě TF je to XMPP 0_o).
Sestavením této relace vRouter oznamuje SDN kontroléru směry k připojeným sítím:
- Adresa sítě
- Metoda enkapsulace (MPLSoGRE, MPLSoUDP, VXLAN)
- MPLS značka klienta
- Jeho IP adresu jako nexthop
SDN kontrolér přijímá tyto směry od všech připojených vRouterů a přenáší je dalším. Jinými slovy, funguje jako Route Reflector.

To samé se děje i na opačné straně.

Overlay se může měnit i každou minutu. Přesně tak to funguje v veřejných cloudech, když klienti pravidelně spouštějí a vypínají své virtuální stroje.

Centrální kontrolér se ujímá všech složitostí spojených s údržbou konfigurace a kontrolou tabulek přepínání/routingu na vRouter.

Zjednodušeně řečeno, kontrolér se spojuje se všemi vRoutery přes BGP (nebo podobný protokol) a prostě předává směrovací informace. BGP například má již Address-Family pro přenos metody enkapsulace. MPLS-in-GRE nebo MPLS-in-UDP.

Přitom se nijak nemění konfigurace Underlay sítě, kterou je mimochodem mnohem složitější automatizovat, a je jednodušší ji rozbít nešikovným pohybem.

Výstup do vnějšího světa

Někde musí simulace skončit a z virtuálního světa je třeba přejít do reálného. A je potřeba telefonní brána.

Existují dva přístupy:

Instalace hardwarového routeru.
Spuštění nějakého apace, který implementuje funkce routeru (ano, ano, po SDN jsme se setkali i s VNF). Pojmenujme to virtuální brána.

Výhodou druhého přístupu je levná horizontální škálovatelnost — pokud chybí výkon, spustíme další virtuálku se bránou. Na jakémkoli fyzickém zařízení, bez nutnosti hledat volné stojany, jednotky, napájení, kupovat samotný hardware, dovážet, instalovat, zapojovat, konfigurovat a pak ještě měnit vadné komponenty.
Nevýhody virtuálního brány spočívají v tom, že fyzický směrovač je mnohem výkonnější než vícejadrový virtuální stroj, a jeho software, přizpůsobený jeho hardwarové základně, pracuje výrazně stabilněji (ne). Je těžké popřít, že softwarový a hardwarový komplex jednoduše funguje a vyžaduje pouze nastavení, zatímco spuštění a údržba virtuální brány je záležitostí silných inženýrů.

Jednou nohou brána nahlíží do virtuální sítě Overlay, jako běžná virtuální stroj, a může interagovat se všemi ostatními VM. Může také terminovat sítě všech klientů a tím pádem provádět směrování mezi nimi.

Druhou nohou brána nahlíží již do páteřní sítě a ví, jak se dostat na Internet.

Data Plane

To znamená, že proces vypadá takto:

VM-0, having default in the same vRouter, sends a packet with an external address (185.147.83.177) to the interface eth0.
vRouter obdrží tento paket a provede lookup cílové adresy v tabulce směrování – najde výchozí trasu přes bránu VNGW1 prostřednictvím tunelu 1.
Také vidí, že se jedná o tunel GRE se SIP 10.0.0.2 a DIP 10.0.255.2, a že je třeba nejprve přiřadit MPLS značku tohoto klienta, kterou VNGW1 očekává.
vRouter zabalí původní paket do hlaviček MPLS, GRE a nové IP a odešle na adresu ToR1 10.0.0.1 podle výchozího nastavení.
Podkladová síť doručí paket k bráně VNGW1.
Brána VNGW1 odstraní tunelovací hlavičky GRE a MPLS, podívá se na cílovou adresu, konzultuje svou tabulku směrování a chápe, že je směrována na Internet – tedy prostřednictvím Full View nebo Default. V případě potřeby provede NAT transformaci.
Od VNGW k hranici může být běžná IP síť, což je nepravděpodobné.
Může to být klasická MPLS síť (IGP+LDP/RSVP TE), může to být zpětná fabrika s BGP LU nebo GRE tunel od VNGW k hranici přes IP síť.
Ať je to jakkoli, VNGW1 provede potřebné enkapsulace a odešle původní paket směrem k hranici.

Provoz zpět prochází stejnými kroky v opačném pořadí.

Hranice doručí paket k VNGW1
Ten jej rozloží, podívá se na cílovou adresu a vidí, že je dostupná prostřednictvím tunelu Tunnel1 (MPLSoGRE nebo MPLSoUDP).
Podle toho přiřazuje značku MPLS, hlavičku GRE/UDP a novou IP a odesílá na svůj ToR3 10.0.255.1.
Cílová adresa tunelu – IP adresa vRouteru, za kterým se nachází cílová VM – 10.0.0.2.
Podkladová síť doručuje paket do požadovaného vRouteru.
Cílový vRouter rozbalí GRE/UDP, určí rozhraní podle MPLS štítku a odešle holý IP paket do svého TAP rozhraní, které je spojeno s eth0 VM.

Control Plane

VNGW1 vytváří BGP sousedství se SDN kontrolérem, od kterého získává všechny směrovací informace o klientech: za jakou IP adresou (vRouterem) se nachází který klient a jakým MPLS štítkem je identifikován.

Podobně SDN kontrolér informuje o výchozí směrování se štítkem tohoto klienta, přičemž sebe uvádí jako nexthop. A toto výchozí směrování poté přichází na vRoutery.

Na VNGW se obvykle provádí agregace směrování nebo NAT překlad.

A na druhou stranu do relace s border bary nebo Route Reflectory posílá právě tuto agregovanou trasu. A od nich obdrží výchozí trasu, buď Full-View, nebo něco jiného.

Z hlediska zapouzdření a výměny provozu se VNGW od vRouteru nijak neliší.
Pokud mírně rozšíříte oblast, můžete k VNGW a vRouterům přidat i jiná síťová zařízení, jako jsou firewally, čištění nebo obohacování provozu, IPS a podobně.

A pomocí sekvenčního vytváření VRF a správného oznámení tras můžete donutit provoz vykonávat loop tak, jak chcete, což se nazývá Service Chaining.

Tedy i zde SDN kontrolér vystupuje v roli Route Reflectora mezi VNGW, vRoutery a dalšími síťovými zařízeními.

Ale ve skutečnosti kontrolér přenáší také informace o ACL a PBR (Policy Based Routing), což donutí jednotlivé toky provozu chovat se jinak, než jak jim určuje trasa.

Často kladené dotazy

Proč stále děláš poznámku o GRE/UDP?

No, vlastně, to bych řekl, že je specifické pro Tungsten Fabric – vůbec se to nemusí brát v úvahu.

Ale pokud se na to zaměříme, samotný TF, když byl ještě OpenContrail, podporoval obě zapouzdření: MPLS v GRE a MPLS v UDP.

UDP je dobrý tím, že v Source Portu v jeho záhlaví lze snadno zakódovat hash funkci z původních IP+Proto+Port, což umožňuje vyvažování.

V případě GRE, bohužel, existují pouze vnější záhlaví IP a GRE, které jsou stejné pro celý zapouzdřený provoz a o vyvažování nemůže být řeč – málokdo se může ponořit tak hluboko dovnitř paketu.

Až donedávna uměly směrovače, pokud měly dynamické tunely, pouze v MPLSoGRE, a teprve nedávno se naučily i MPLSoUDP. Proto je vždy nutné zmínit možnosti dvou různých enkapsulací.

Z pohledu spravedlnosti stojí za zmínku, že TF plně podporuje i L2 spojení pomocí VXLAN.

Slíbil jsi, že vysvětlíš paralely s OpenFlow.
Oni se opravdu nabízejí. vSwitch ve stejném OpenStack dělá velmi podobné věci, používající VXLAN, který má mimochodem také UDP hlavičku.

V Data Plane fungují přibližně stejně, zásadně se však liší Control Plane. Tungsten Fabric používá XMPP pro doručování informací o směrech do vRouteru, zatímco v OpenStacku funguje Openflow.

Mohl bys říct něco více o vRouteru?
Dělí se na dvě části: vRouter Agent a vRouter Forwarder.

První běží v uživatelském prostoru hostitelského operačního systému a komunikuje se SDN kontrolerem, vyměňuje si informace o směrech, VRF a ACL.

Druhý implementuje Data Plane — obvykle v jádrovém prostoru, ale může být spuštěn i na SmartNICách — síťových kartách s CPU a samostatným programovatelným čipem pro přepínání, což umožňuje snížit zátěž na CPU hostitelské mašiny a učinit síť rychlejší a předvídatelnější.

Také je možný scénář, kdy je vRouter aplikace DPDK v uživatelském prostoru.

vRouter Agent předává nastavení na vRouter Forwarder.

Co je to Virtual Network?
Na začátku článku jsem zmínil VRF, že každý tenant je vázán na svůj VRF. A pokud pro povrchní pochopení fungování overlay sítě to bylo dostatečné, pak už v další iteraci je třeba provést upřesnění.

Obvykle v mechanismech virtualizace se entita Virtual Network (to se dá považovat za vlastní jméno) zavádí odděleně od klientů/tenantů/virtuálních strojů — je to zcela samostatná věc. A tento Virtual Network je pak možné připojit přes rozhraní do jednoho tenanta, do druhého, do dvou, klidně kamkoliv. Takto například probíhá Service Chaining, kdy je třeba propustit provoz přes určité uzly v požadované posloupnosti, jednoduše se správnou posloupností vytvářením a vázáním Virtual Networks.

Proto neexistuje žádné přímé odpovídající spojení mezi Virtual Network a tenantem.

Závěr

Toto je velmi obecný popis fungování virtuální sítě s overlay s hostitele a SDN kontrolérem. Ale ať už vezmete jakoukoli virtualizační platformu dnes, bude fungovat podobným způsobem, ať už je to VMWare, ACI, OpenStack, CloudStack, Tungsten Fabric nebo Juniper Contrail. Lišit se budou typy enkapsulací a hlaviček, protokoly doručování informací k cílovým síťovým zařízením, ale princip softwarově definované overlay sítě, která funguje nad relativně jednoduchou a statickou underlay sítí, zůstane stejný.
Lze říci, že oblasti vytváření soukromého cloudu dnes vyhrály SDN založené na overlay síti. To však neznamená, že OpenFlow nemá místo v moderním světě — je používán v OpenStacku a také ve VMWare NSX, jak mi je známo, používá ho Google pro konfiguraci underlay sítě.

Níže uvádím odkazy na podrobnější materiály, pokud chcete studovat téma hlouběji.

A co náš Underlay?

V zásadě nic. Po celou dobu zůstává stejný. Vše, co musí dělat v případě overlay s hostitele, je aktualizovat směrovací tabulky a ARP, jakmile se vyskytují a zanikají vRouter/VNGW, a přenášet pakety mezi nimi.

Pojďme formulovat seznam požadavků na Underlay síť.

Být schopen použít nějaký směrovací protokol, v našem případě — BGP.
Mít širokou šířku pásma, ideálně bez přetížení, aby se zamezilo ztrátám paketů v důsledku přetížení.
Podporovat ECMP — nedílná součást fabriky.
Být schopen zajistit QoS, včetně složitějších věcí, jako je ECN.
Podporovat NETCONF — příprava na budoucnost.

Práci samotné Underlay sítě jsem zde věnoval velmi málo času. To je proto, že se v další části série budu právě na ní soustředit, zatímco Overlay budeme probírat pouze okrajově.

Je zřejmé, že se silně omezujeme, používajíc jako příklad síť datacentra postavenou na fabriku Clos s čistým IP směrováním a overlay s hostitele.

Jsem však přesvědčen, že jakoukoli síť s designem lze popsat v formálních termínech a automatizovat. Mým cílem je tady zaměřit se na přístupy k automatizaci, nikoli zmást všechny tím, že se pokusím řešit obecný problém.

V rámci ADSM plánujeme s Romanem Gorgem publikovat zvláštní vydání o virtualizaci výpočetních zdrojů a jejím zapojení do virtualizace sítě. Zůstaňte v kontaktu.

Užitečné odkazy

Architektura Tungsten Fabric.
o:cloud. 6 hodin o Yandex.Cloud, kde se také hovoří o virtuální síti na TF.
Co je Open vSwitch?
Úvod do VxLAN.
RFC 7348. Virtuální eXtensible Local Area Network (VXLAN): Rámec pro překrývání virtualizovaných sítí vrstvy 2 nad sítěmi vrstvy 3.
Přístup Scaleway k VXLAN EVPN Fabric. Zde se hovoří o celé síti datového centra, včetně Underlay, Overlay, přístupech k multi-homing a správě.

Děkuji

Roman Goreg — bývalý moderátor podcastu linkmeup, nyní expert na cloudové platformy. Za komentáře a úpravy. A těšíme se na jeho podrobnější článek o virtualizaci v blízké budoucnosti.
Alexandra Shalimova — mému kolegovi a expertovi na vývoj virtuálních sítí. Za komentáře a úpravy.
Valentina Sinitsyna — mému kolegovi a expertovi na Tungsten Fabric. Za komentáře a úpravy.
Artemu Chernobayu — ilustrátorovi linkmeup. Za KDPV.
Alexandru Limonovovi. Za meme „automato“.

Zdroj: habr.com