Flachere Strukturen gefordert

Die Fabric als neues Netz-Dogma

09.11.2011 von Jürgen Hill
Cloud Computing und Virtualisierung haben nun auch ihre Konsequenzen im Netz: Bisherige Architekturen genügen den Anforderungen nicht mehr - das neue Credo ist die Fabric.
Mit Cloud-Computing und Virtualisierung werden flache Strukturen auf Layer-2-Ebene gefordert.
Foto: Anatoly Stojko

Egal ob VoIP, Unified Communications oder Konvergenz - an der Art, Netze zu bauen, änderte sich in den letzten Jahren wenig. Sie waren hierarchisch, geswitcht und schlossen immer mehr den Layer 3 ein. Fehlte einmal die Bandbreite, wurde auf den nächsten Ethernet-Standard aufgerüstet. Mit Techniken wie Quality of Service (QoS), VLAN, Spanning Tree oder Erweiterungen wie Link Aggregation wurden die Handicaps klassischer Ethernet-Strukturen umschifft.

Eine Strategie, die, wie sich nun herauskristallisiert, im Zeitalter von Cloud Computing und Virtualisierung nicht mehr greift. Wenn Tausende von virtuellen Maschinen und Ports in Sekundenbruchteilen umzukonfigurieren sind, funktionieren die klassischen Ethernet-Management-Strukturen nicht mehr. Sie sind schlicht zu unflexibel, um die angestrebte Automatisierung im Rechenzentrum oder in der Cloud zu erreichen.

Als Ausweg aus diesem Dilemma propagieren die Netzwerk-Player mittlerweile die Idee der Ethernet Fabric, wobei auch häufig herstellerspezifische Bezeichnungen wie OneFabric, Openflow, OpenFabric, FlexFab, oder Q Fabric verwendet werden.

Flexibler und effizienter

Angesichts der noch jungen Technik hat sich noch keine allgemeingültige Definition durchgesetzt. Vereinfacht ausgedrückt geht es im Fabric-Gedanken darum, den Datendurchsatz in Ethernet-Infrastrukturen effizient zu steigern und gleichzeitig die Komplexität des Managements zu reduzieren sowie die Flexibilität zu erhöhen. Oder wie es Frank Koelmel, Director bei Brocade, formuliert: "Man versucht mit der Fabric, den Blockgedanken der Speichernetze aufzunehmen und zu flacheren Strukturen zu kommen." Dementsprechend setzt eine Fabric auf der Ebene zwei an und versucht die Layer-3-Ebene nicht für Steuerungsfunktionen einzubeziehen. Auf der anderen Seite sollen aber die Applikationen auf den höheren Netzebenen - hierzu ist auch eine virtuelle Maschine zu zählen - selbst steuernd in die Netzkonfiguration eingreifen können und so zur gewünschten Automatisierung beitragen.

Oder anders formuliert: Eine Fabric führt zur Trennung zwischen Datennetz und Steuerung. Im Gegensatz zur ursprünglichen Fabric-Idee im Speichernetz soll die Ethernet Fabric bis in den Edge-Bereich des Netzes reichen und so eine End-to-End-Kontrolle aller Netzkomponenten erreichen. Ziel ist auch die Ablösung von Ethernet-Techniken wie dem Spanning Tree, die sich immer mehr als Performance-Bremsen entpuppen.

Neue Protokolle in der Fabric

Um eine höhere Performance und Flexibilisierung, verbunden mit der geforderten Automatisierung, zu erreichen, führen die Ethernet Fabrics neue Verfahren wie Transparent Interconnection of Lots of Links (Trill), Ethernet Data Bridging (EDCB oder DCB), Inter Switch Links (ISL), Shortest Path Bridging (SPB), Multi-Switch Link Aggregation (M-LAG) oder das Link State Multipath Routing (LSMPR) ein.

Neuerungen, die den Entscheidungsträger vor ein Problem stellen: Wie evaluiert man eine Lösung, wenn die klassischen Entscheidungskritierien wie Port-Dichte, Geschwindigkeit oder Zahl der 10-Gigabit-EthernetPorts nicht mehr greifen? Zumal die Fabric eher als System denn als einzelne Komponente zu begreifen ist. Unter Systemaspekten sollte der Entscheider prüfen, ob der Hersteller wie auf dem Papier versprochen auch ältere und Fremdsysteme in seine Fabric einbeziehen kann. Skaliert die Fabric entsprechend den eigenen Bedürfnissen? Unterstützt der Hersteller standardbasierte Protokolle, oder setzt er auf spezifische eigene Erweiterungen?