Síťové přepínání pro virtuální svět (2.)

Dokončení včerejšího článku…

Efektivní využití kapacity linek
Druhá oblast, o které se v současnosti hodně mluví v souvislosti s virtualizací datových center, se týká efektivnějšího využití kapacit dostupných linek v DC a potažmo zvyšování stability síťové infrastruktury DC.

V současných sítích pracujících na druhé úrovni (L2) se používají různé formy protokolu Spanning Tree, který zajišťuje ochranu proti případným komunikačním smyčkám v síti a jedinou cestu infrastrukturou. DC se budují redundantně kvůli ochraně proti selhání zařízení nebo spoje DC. Spanning Tree tyto redundantní linky blokuje, takže je jich mnoho nevytížených. Při komunikaci ze stanice H1 na stanici H2 lze využít pouze trasu přes přepínače S1-S2-S3. Trasa S1-S4-S3 je nevyužitelná, protože Spanning Tree blokuje linku mezi S1 a S4. Pro úplnost dodejme, že v současných sítích se běžně používá per VLAN RSTP (Rapid Spanning Tree Protocol) nebo MST (Multiple Spanning Tree). Tam lze Spanning Tree konfigurovat zvlášť pro jednotlivou VLAN nebo skupinu VLAN, a lze tak dosáhnout lepšího (v praxi ale ne optimálního)vytížení linek než v uvedeném příkladu. Pro stanici H1 ve VLAN X může být aktivní cesta S1-S2-S3, pro stanici H10 a její komunikaci na H20 ve VLAN Y pak cesta S1-S4-S3.

Multichassis link agregace
Základem pro možnost maximálního vytížení dostupných linek v DC je tedy eliminace techniky Spanning Tree. Jedna z metod, která je u některých výrobců již implementována, pracuje s klasickým standardem 802.3ad pro agregaci linek mezi dvěma ethernetovými zařízeními. Z hlediska Spanning Tree se takové agregované linky jeví jako jedna logická linka, a žádná z nich tedy není neblokována.

Typické koncové zařízení nebo přístupový přepínač jsou připojovány v DC duálně. Záměrem je v tomto případě umožnit, aby jednotlivé spojnice agregované linky mohly končit na různých přepínačích. Řeší se to firemním protokolem, který běží mezi uplinkovými switchi, a synchronizuje stav z hlediska agregace linek. Implementovaný mechanizmus musí řešit i případy, kdy linka mezi uplinkovými přepínači přestane být funkční.

Jiné implementované metody umožňují stohovat zařízení nebo dokonce virtualizovat dvě celá šasi, takže z hlediska síťových protokolů a správy vystupuje několik fyzických zařízení jako jediný systém.

V kterémkoliv z těchto případů se pak z pohledu LACP (802.3ad Link Access Control Protocol pro sestavování agregovaných linek) tato fyzická zařízení jeví jako jedno logické. Pro zařízení připojované na takový „virtualizovaný“ box přes 802.3ad, ať už jde o přepínač nebo koncovou stanici, je připojení zcela transparentní a všechny agregované spojnice jsou aktivní.

End-host módy
Jiným, u některých výrobců již implementovaným způsobem, jak v přístupové vrstvě eliminovat Spanning Tree a mít oba (nebo více) uplinky aktivní, je konfigurace takzvaného end-host módu. Zde se nastavuje pevná vazba mezi serverem (respektive MAC adresou) a jeho primárním a záložním uplinkem. Komunikace z jednotlivých serverů tak může být rozložena mezi různé spoje. Přepínač se v tomto módu nikdy neučí MAC adresy z uplink portů.  Jestliže cílová MAC neodpovídá některému z přímo připojených serverů, rámec se automaticky posílá  spojem „svázaným“ se zdrojovou MAC. Ochrana proti smyčkám je zajištěna pravidly, kde rámec přicházející z uplinkového rozhraní nikdy nesmí být přeposílán na jiný interface a rámce ze serverového rozhraní jsou přeposílány pouze tehdy, je-li jejich zdrojová MAC adresa obsažena ve forwardovací tabulce.

Layer 2 Multipath
To, co by mělo vytlačit Spanning Tree z DC, nás ovšem teprve čeká. Měly by jí být standardizované protokoly určené jako jeho přímá náhrada. Jde jednak o 802.1aq Shortest Path Bridging vyvíjený v rámci organizace IEEE, jednak TRILL (Transparent Interconnection of Lots of Links) realizovaný v rámci IETF. Oba tyto standardy umožní využívání optimální cesty – komunikace ze stanice H1 na H3 tak může běžet přes S1 a S4 a komunikace mezi H1 a H4 zase přes S1 a S2. Hlavní průlom pak bude představovat možnost využívat více cest k cíli. Stanice H1 tak bude moci komunikovat s H2 přes S1-S2-S3, ale s H20 ve stejné VLAN přes S1-S4-S3.

Obě zmiňované normy, 802.1aq a TRILL, vycházejí ze směrovacího protokolu IS-IS, často používaným ve sféře poskytovatelů služeb. Těžko ale říci, proč vznikají v cílech dva velice podobné standardy založené na stejném protokolu. Každopádně začátek prací na obou specifikacích se datuje někdy na přelom roku 2005/2006, a je tedy vidět, že je už překonávána řada překážek. Vzhledem ke stejnému výchozímu protokolu se zaměříme pouze na TRILL.

TRILL
TRILL  pracuje s konceptem takzvaného Routing Bridge (RBridge), na kterém běží IS-IS, což je link state routing protokol, a na základě jím poskytovaných informací o stavu linek se na RBridge vytváří topologický obraz sítě (tzv. link state databáze). IS-IS nepoužívá pro sestavení vazeb se sousedy IP protokol, ale OSI protokol CLNP (Connectionless Network Protocol). Zatímco Integrated IS-IS přenáší informace o IPv4/v6 adresách, TRILL využívá IS-IS k přenosu informací o MAC adresách v jednotlivých VLAN a nad link-state databází buduje SPT (Shortest Path Tree) pro cílový RBridge, za kterým je dostupná cílová MAC adresa v dané VLAN. Pro výpočet SPT se používá Dijkstra algoritmus známý i ze směrovacího protokolu OSPF.

Co se týká manipulace s datovými rámci, TRILL datové rámce mezi RBridge zapouzdřuje do hlaviček local-link a TRILL.  Prvně jmenovaná obsahuje zdrojovou a cílovou adresu, přičemž tou zdrojovou je MAC adresa příslušného RBridge na dané lince, konečnou pak MAC adresa cílového RBridge (v případě známého unicastu), případně All-RBridge.

Hlavička TRILL pak mimo jiné obsahuje parametr hop count pro předcházení případných problémů při zasmyčkování. Do rámce ji přidává první vstupní RBridge a odebírá až poslední výstupní RBridge (R2).  Mezi důvody, které vedly k volbě zapouzdření provozu mezi RBridge, lze uvést právě možnost sledování hopů, přes které rámec prošel. Dalším je například to, že je možné stanovit velikost forwardovací tabulky v tranzitních RBridge pouze na počet RBridge v síti, a nikoliv na množství koncových stanic v síti.

Cílem TRILL RFC je i kompatibilita se současným Spanning Tree protokolem a klasickými přepínači, tak aby byla možná postupná implementace do původních sítí a minimální nebo nulová nezbytná konfigurace.

Závěrem
Vedle práce na zmiňovaných standardech pokračují relativně rychlým tempem i práce na skupině standardů Data Center Bridging (DCB), popsaných podrobněji již v dřívějších vydáních  Computerworldu. Zároveň byl minulý rok v červnu standardizován protokol FiberChannel over Ethernet (FCoE), umožňující zapouzdření a transparentní přenos FC rámců po ethernetovém spoji. Společně se zde popisovanými standardy budou mít tyto aktivity velký vliv na návrh síťové infrastruktury DC, přičemž lze předpokládat, že design síťové infrastruktury DC se do několika let změní doslova k nepoznání.

Autor pracuje jako Manager – Communications Infrastructure ve společnosti Anect.