Jazyk P4 jako budoucnost SDN

Snad každý dnes slyšel o fenoménu Software Defined Networking – SDN. Ten se stal populárním, protože slibuje možnost efektivně a rychle měnit konfiguraci a využití síťové infrastruktury. SDN se často zaměňuje s pojmem OpenFlow, což je ale pouze jedna konkrétní implementace konceptu SDN, i když zdaleka nejrozšířenější. Aktuální implementace OpenFlow si našla cestu do mnoha reálných sítí, má však i určité nevýhody, které jsou spojeny s rozšiřitelností dalšího zpracování paketů nebo počtem podporovaných protokolů. Tento neduh se snaží vyřešit svým přístupem jazyk P4. Ten slibuje skutečné a důkladné oproštění od starých protokolů a modelů fungování sítí. S jazykem P4 si svou síťovou infrastrukturu konečně naprogramujete, nikoliv pouze nakonfigurujete. V dnešním díle našeho seriálu se podrobněji podíváme na koncept SDN.

Software-Defined Networking: definujeme budoucnost

S rozvojem, rostoucí rychlostí a složitostí počítačových sítí se stále více objevuje potřeba efektivnější správy síťové infrastruktury. Navíc se stále častěji používají aplikace, které potřebují zasahovat do síťové infrastruktury a efektivně měnit její konfiguraci, například z důvodů bezpečnosti, směrování síťových toků, load-balancingu, atd. Plnění takových úkolů je však velmi nelehké v infrastruktuře, kde je každý síťový prvek autonomním a samostatně konfigurovaným zařízením. Celkové chování sítě je totiž komplexní kombinací funkcí všech těchto zařízení. Která zařízení a jak mám překonfigurovat, abych změnil chování sítě požadovaným způsobem, a přitom neovlivnil stávající služby?

Navíc jsou zde i další trendy, které vedou ke změně přístupu k síťování jako takovému. Mezi ně můžeme zařadit:

• Požadavek na dynamické chování sítě z pohledu rezervace síťové kapacity. Tento trend můžeme primárně sledovat v projektech zaměřených na distribuované výpočty, kdy se data stahují z uložišť třeba i z jiných kontinentů. V takovém případě je důležité mít spojení požadované kvality a budování vlastní infrastruktury napříč kontinenty může být velmi nákladné.

• Rozvoj cloud služeb. Zákazníci si přejí přístup k pronajímané infrastruktuře dle potřeby.

• Změna infrastruktury (přidání nebo odebrání síťových prvku) a její správa jsou v případě velkých a komplexních sítí velmi časově náročné operace. Náročné jsou i úkony jako zavádění bezpečnostní politiky napříč takovými sítěmi.

• Zvyšování síťové rychlosti a její včasná alokace pro dané aplikace. Tento požadavek je velmi častý u velkých poskytovatelů služeb jako je například Google nebo Facebook. Inteligentní alokace a směrování dat může ušetřit nemalé finanční náklady.

• Nezávislost na značce síťového zařízení, změnšení rizika tzv. vendor lock-in.

Uvedené požadavky, nenaplněné “klasickými” sítěmi, daly vzniknout konceptu, který se nazývá Software-Defined Networking (SDN). Tento koncept striktně odděluje řídicí a datovou vrstvu síťové infrastruktury. Celé si to můžeme představit tak, že síťový hardware je velice rychlé zařízení, ale neobsahuje uvnitř sebe řídící software. Místo toho se připojuje k řídicí vrstvě, která se v SDN nazývá kontrolér. Ten má na starosti více SDN zařízení a udává jim přesné chování. Tímto způsobem se tedy přechází od distribuované definice chování siťových zařízení k centralizovanému. Tento centralizovaný pohled je velmi výhodný z hlediska plánování a řízení, protože kontrolér zprostředkovává pohled na síť jako na jeden celek a tak ušetří správci komunikaci s jednotlivými síťovými prvky (komunikujeme pouze s kontrolérem a ne s mnoha síťovými prvky). Můžeme tedy například jednoduše zvolit takové směrování dat skrze síť, které je globálně vhodné podle aktuální situace. Další nespornou výhodou je také svobodnější možnost volby síťového hardware – stačí, aby si hardware rozuměl s kontrolérem prostřednictvím standardizovaného protokolu.

SDN koncept přináší následující výhody:

• Přímá konfigurovatelnost – možné díky oddělení řídící a datové vrstvy

• Abstrakce – pro většinu činností nemusíme znát přesnou topologii sítě

• Centralizace – přináší výhody během správy sítě, řízení toku dat v síti, atd

• Otevřený standard – přináší nezávislost na výrobci síťového hardware

• API – S kontrolérem může uživatel nebo aplikace komunikovat přes standardizované API z aplikační vrstvy

Architektura SDN

OpenFlow

OpenFlow je zdaleka nejrozšířenější protokol sloužící pro komunikaci mezi řídící a datovou vrstvou. Je tedy určitým prostředkem, díky kterému můžeme realizovat koncept SDN. Tento komunikační protokol umožňuje konfigurovat síťové prvky – přepínače. Děje se tak především prostřednictvím plnění tabulek, které přiřazují síťovým tokům správné akce. Nad každým tokem tak můžeme spouštět různé akce, které mohou jejich pakety modifikovat, blokovat, posílat kontroléru, atd. Obvyklý scénář je, že jakmile přepínači přijde paket, se kterým si “neví rady” (protože nenašel odpovídající záznam v tabulce), odešle jej kontroléru. Kontrolér provede rozhodnutí a odpoví přepínači tím, že mu do jeho tabulky vloží správné pravidlo. Přepínač se tak postupně “učí”, jak zpracovávat pakety.

Základním prvkem v OpenFlow přepínači je tabulka. Těchto tabulek je v OpenFlow přepínači více a můžeme tak definovat i složitější operace. Tabulky jsou tří zakladních typů – flow tabulky, meter tabulky a group tabulky. Flow tabulka je základním typem tabulky, kde se provádí již zmiňovaná identifkace a přírazování operací k tokům. Meter tabulka je užitečná v takzvaném rate-limitingu nebo QoS, kdy například můžeme omezit datový tok na určitou IP adresu a provádět prioritizaci určitého typu dat. Poslední, group tabulka, slouží k podpoře komunikace jako je broadcast nebo multicast. Tato tabulka totiž pro každý záznam může definovat určitou množinu akcí, která se provádí nad kopií zpracovávaného paketu. Použití této tabulky si můžeme představit tak, že definujeme 32 různých zpracování paketu (tzn. 32 různých instancí), které se pak odešlou na síť.

Samotné zpracování toku v OpenFlow přepínači začíná rozparsováním příchozího paketu, který se pak vyhledává v první tabulce. Pokud je nalezen, tak se provede spuštění přiřazené akce. V případě nenalezení odpovídajícího toku se provede spuštění takzvané table-miss akce, které může například odeslat paket do kontroléru. Ten již může provést hlubší analýzu dat a vygenerovat pravidlo, které se nahraje do tabulek v OpenFlow přepínači. Samotný síťový hardware tak může být poměrně jednoduchý a rychlý. Logika síťových aplikací je pak implementována v kontroléru, který rozhoduje o osudu každého toku v síti. Ukázka tohoto zpracování je na obrázku. Následující text se bude podrobněji věnovat popisu toků a akcí.

Tok může být charakterizován různými políčky protokolů, které jsou přenášené v paketech. Nejčastěji je tok charakterizován pomocí pětice (sIP, dIP, sPort, dPort, Proto), kde sIP/dIP je zdrojová/cílová adresa, sPort/dPort je zdrojový/cílový port a Proto definuje transportní protokol (TCP nebo UDP). OpenFlow však umožňuje provádět klasifikaci toku i na základě vstupního portu, zdrojových/cílových MAC adres, EthType (políčko, které slouží pro specifikaci přenášeného protokolu v datové části Ethernetového rámce), hodnoty VLAN tagů, příznaků TCP protokolu, atd. Každá verze OpenFlow (aktuálně verze 1.5) typicky přináší nové podporované protokoly, které se mohou použít v průběhu identifikace toku. Ukázka počtu podporovaných protokolů je v tabulce.

Ukázka zpracování paketu v OpenFlow

Hodnoty sledovaných políček mohou být buď maskované nebo konkrétní hodnoty. V případě konkrétní hodnoty se při identifikaci toku extrahují sledovaná políčka protokolů a porovnají se s hodnotou uloženou v tabulce. Tento přístup však není v určitých situacích zcela vhodný, protože bychom museli zadat hodně pravidel – příkladem může být identifikace všech toků z nějaké sítě. V tomto případě je vhodné použít tzv. masku, která se použije na maskování příchozích dat (provedeme logický součin příchozích dat s maskou). Výsledná hodnota se poté použije při identifikaci toku.

Po provedené identifikaci toku se spustí daná akce, která je k němu přiřazena. Akce jsou většinou jednodušší a můžeme si je představit jako editaci políček, přidávání/odebírání hlaviček protokolů (např. přidání VLAN hlavičky), směrování požadavků do jiných tabulek OpenFlow přepínače, odesílání na daný výstupní port, atd.

OpenFlow je důležitou součástí moderních datových center, protože umožňuje jejich správcům jednoduše a podrobně ovládat chování síťové infrastruktury. Je využíváno i velkými hráči jako je Google. Ten využívá tuto technologii k propojení svých datových center, protože jako jediná dokázala uspokojit požadavky na škálovatelnost, programovatelnost, traffic-engineering, atd. Více informací ohledně nasazení je dostupných v dokumentu Inter-Datacenter WAN with centralized TE using SDN and OpenFlow [PDF].

Hlavním omezením OpenFlow je však uzavřenost na podporované protokoly a akce v dané verzi. Nemůžeme tak jednoduše využít k identifikaci nový protokol, protože ho naše OpenFlow přepínače a kontrolér prostě neznají. Musí se napřed provést upgrade. V případě softwarové implementace přepínače není situace zcela neřešitelná. Pokud máme k dispozici zdrojové kódy přepínače a kontroléru, můžeme si vytvořit vlastní variantu OpenFlow, rozšířenou o podporu našeho protokolu. Ukázka softwarových implementací OpenFlow přepínače je například na GitHubu, kde je dostupná pod open source licencí. Softwarově implementované přepínače mají však omezený výkon a nejsou tak vhodné pro síťové infrastruktury na vysokých rychlostech. V takovém prostředí se využívají hardwarové OpenFlow přepínače, ve kterých však upgrade na novou verzi OpenFlow vetšinou znamená výměnu celého zařízení. Jsme tedy tak trochu tam, kde jsme byli před OpenFlow. Tuto nevýhodu se snaží řešit jazyk P4, o kterém bude řeč příště.

Závěr

V dnešním díle jsme se podívali na nový přístup k síťování. Ten slibuje mnohé změny, které dokážou síťovému administrátorovi ulehčit práci. Podle nás má tato technologie budoucnost, protože umožní velmi rychlou změnu chování již existující infrastruktury. Navíc je již dnes používána ve velkých datových centrech společnosti Google. Nicméně má i nevýhody, které jsou spojeny s rozšiřitelností zpracování paketů nebo počtem podporovaných protokolů. Tento problém řeší nový jazyk P4, na který se podíváme v dalším díle tohoto seriálu.