Konečně technologie, která vyřeší všechny problémy síťové infrastruktury. To, co jsme již dříve několikrát slyšeli, je tu znovu. Softwarově definované sítě (SDN) jsou nyní, měřeno okem gartnerovské hype křivky, na vrcholu „nafouknutých“ očekávání. Tedy přesně tam, kde byly před dvěma lety technologie Fabric a FCoE (Fibre Channel over Ethernet), přičemž FCoE je dnes ve fázi deziluze (through of disillusionment).

Označit nynější pozici SDN za vrchol nafouknutých očekávání lze například na základě těchto skutečností: všudypřítomná diskuse nad řešením problémů prostřednictvím SDN, počet nově vznikajících výrobců v této oblasti, nejasné definice v oblasti SDN či nákup začínající společnosti VMwarem za více jak miliardu amerických dolarů. Celá koncepce SDN přitom jednoznačně dává smysl a zřejmě má ty nejlepší předpoklady pro úspěch. V naší společnosti s ní experimentujeme od počátku devadesátých let, a to aniž by to u nás kdokoliv termínem softwarově definované sítě nazýval. Mnoho zákazníků již tyto technologie také úspěšně provozuje. V telefonii je koncept SDN obsažen v podobě inteligentních sítí.

Co přesně je SDN?

Vše má jedno společné – snahu co nejvíce oddělit kontrolní a vlastní datovou vrstvu. Cílem je mít lepší centralizovanou správu a možnosti pro jednoduché definice služeb, pružnost a vysoký stupeň automatizace prostřednictvím integrace s dalšími IT aplikacemi (přes tzv. northbound rozhraní API) v rámci definicí nových služeb v síti – například integrace virtualizovaných serverů v datovém centru.
 

Obr. 1: SDN referenční architektura

Síťová infrastruktura je z pohledu správce jednoduše logicky rozdělena, tedy síťově virtualizována, což by mělo při odpovídající standardizaci ve výsledku přinést značné úspory nákladů, protože síťová infrastruktura bude jednoduše zaměnitelná. Ačkoliv se o standardizaci protokolu umožňujícího SDN pokusila komunita OpenFlow prostřednictvím Open Network Foundation, právě v této oblasti je potřeba toho ještě hodně udělat. SDN je totiž mnohem víc než OpenFlow. Na základě zkušeností s dostupnými řešeními OpenFlow je zřejmé, že jsme stále ještě příliš daleko od použitelného výsledku, který musí být škálovatelný a dostatečně robustní.

Lidé věnující se tomuto tématu na univerzitách velice rádi experimentují a dodavatelé služeb (jako je například Deutsche Telekom) i velcí poskytovatelé datových center a cloudových aplikací (Google, Facebook a jiní) jsou velmi aktivní v ONF a v rámci testování a pilotních projektů získávají odpovídající zkušenosti. Někteří z nich mluví o komerčním zavádění, je však více než zřejmé, že v podmínkách omezené velikosti.

Tyto instituce si jsou vědomy toho, že pro práci v síti a základní kompetence je nutné investovat do velkého množství odborníků, kteří se této problematice věnují. To však v mnoha firmách v současné době není možné. A vzhledem k tomu, že vše musí pracovat jednoduše, je zde před námi ještě dlouhá cesta. Ale je také možné, že nikdy nedosáhneme svého cíle.

Co je nutné vyřešit?

Prvním problémem je standardizace celého řešení. Dalším, ale přímo souvisejícím, je pak dostupnost již prověřených funkcí, které známe z dnešních sítí. Otevřené kontroléry jsou navrženy jako demonstrace schopností jednotlivých protokolů, avšak většina z nich nabízí pouze základní přepínání, jako příklad API, vše ostatní je ponecháno na vlastním uživateli. Například často chybějící podpora Spanning Tree může v těchto otevřených architekturách způsobovat postupem času smyčky.

Nic nelze považovat za samozřejmost. OSPF, politiky, případně ověřování identit, nebo něco, co byste očekávali v přepínači podnikové třídy, musíte sami naprogramovat nebo využít některé z modulů již vyvinutých a dostupných na internetu.

Každodenní běžné provozní úkoly jsou ponechány na uživateli, jako například redundance kontrolérů nebo udržování sítě v provozu během upgradu softwaru kontroléru. Dostupné produkty OpenFlow toto bohužel stále často nepodporují. Určitou výjimkou jsou kontroléry SNAC dostupné v rámci otevřené komunity. SNAC je původní vývoj od společnosti Nicira. Nabízí použitelné webové rozhraní, možnost nasazení politik a funkce řízení přístupu do sítě, které je však stále daleko za jakýmkoliv komerčním řešením NAC.

Nejzásadnějším problémem je však škálovatelnost celého řešení. Teoretické výhody kompletní centralizace (vrstva řízení) jsou ze své podstaty zjevné. K dořešení zbývá především dostupnost a problém škálování definice IP toků, jako je typické u testování OpenFlow v náročných podmínkách. V dnešních implementacích je ve výsledku vše předem statické. To znamená, že musíte vědět předem, kdo s kým bude komunikovat – typicky na IP subnet maskách (zástupné znaky pro klíčová slova, maskování částí IP hlavičky jako TCP/UDP porty atd.).

S OpenFlow implementacemi aktuálně nelze poskytnout podrobnější kontrolu a dynamičnost sítě. Implementace OpenFlow neposkytují viditelnost do všech částí IP hlavičky ani neumožňují provést rozhodnutí pro naprogramování datových toků na sběrnici v reálném čase. Představte si každého uživatele s několika novými toky za sekundu. Ve výsledku pak můžeme ve větších sítích očekávat několik set tisíc toků za sekundu. A to již nelze centrálně spravovat, a dokonce to ani dnešní architektury přepínacích sítí nepodporují. Výjimku tvoří architektury založené na vlastních ASIC procesorech, například CoreFlow2. Přepínač založený na CoreFlow2 podporuje až 64 milionů toků v hardwaru a poskytuje viditelnost a statistiky o každém z těchto toků. Běžně používané procesory ASIC (což je mimochodem jeden z argumentů pro používání OpenFlow kvůli snižování nákladů) podporují obvykle množství toků v rozmezí 1k až 10k. Pro vyšší počet možných toků se však bude muset volit opět distribuovaná architektura pro řízení sběrnice. Tím se zase zvyšuje složitost a dochází k eliminaci předpokládaných výhod oproti dnešním distribuovaným architekturám síťové infrastruktury.

Obr. 2: Využití hybridní architektury

Všimněte si, že využití hybridních architektur je pro rozvoj SDN velmi užitečné: řízení toků, management topologie a rozhodnutí o směrování je prováděné lokálně a tak, jak je dnes běžné, vlastní definice je centralizovaná a je následně distribuována do všech částí sítě. Integrace s dalšími IT aplikacemi skrze otevřené rozhraní API přináší značné výhody, které s sebou nese architektura SDN, a to v bezpečném, robustním a škálovatelné provedení. Tento způsob mnohem lépe odráží požadavky kladené IT odděleními jednotlivých podniků a organizací. V závislosti na vývoji jednotlivých protokolů je nahrazují otevřené standardy. Vlastní otevřenost rozhraní, tzv. northbound API, je primárním parametrem užitečnosti SDN z hlediska flexibility a automatizace činností. Na trhu jsou dnes již dostupné takové produkty pro pevné i bezdrátové sítě, které třetím stranám umožňují přikázat síti, jakým způsobem je potřeba nastavit koncová zařízení či virtuální servery, VOIP aplikace, o jaký telefon se jedná a jakou konfiguraci nastavit, MDM (mobile device management) systémy pomohou nastavit v síti, která mobilní zařízení jsou v majetku společnosti a která z nich jsou BYOD, vlastněná zaměstnanci či hosty.

Investujte s rozmyslem

Jak jsme již zmínili, SDN architektura má ty nejlepší předpoklady k úspěchu, tedy širokému nasazení. V jaké to bude formě, zůstává stále otevřené, a v příštích dvanácti až dvaceti čtyř měsících bude pravděpodobně docházet k vlastnímu směrování technologie. Doporučujeme zákazníkům zbytečně neinvestovat do řešení, o kterých se jen teoreticky mluví, ale rozumně zvážit využití dnes již existujících a prověřených řešení, které jsou navíc vyvíjeny v duchu SDN.

Michal Zlesák, Zdeněk Pala
Oba autoři působí ve společnosti Enterasys. Michal Zlesák jako area sales manager, Zdeněk Pala na pozici technical key account manager.