Ein Problem der Fabric-Architektur ist: Es gibt unterschiedliche Ansätze, etwa auf der Basis von Protokollen wie Shortest Path Bridging und Trill. Lokale Netze (LANs) basieren derzeit in der Regel auf einer traditionellen hierarchischen Infrastruktur auf Basis von Ethernet-Switches und drei Ebenen:
• Zugangssysteme (Access-Switches),
• Aggregation-Switches und
• Core-Switches.
In einem Rechenzentrum sind beispielsweise Server-Racks in vielen Fällen mit einem Top-of-Rack-Switch (ToR) ausgestattet. Alternativ dazu wird zwischen Server-Racks ein Middle-of-Row-Switch (MoR) platziert, oder am "Ende" einer Reihe von Server-Racks kommt ein End-of-Row-Switch (EoR) zum Einsatz. Alle Switches kommunizieren miteinander über Inter-Switch-Links (ILS). Für diese Verbindungen gelten jedoch strikte Einschränkungen: Sie dürfen keine Schleifen (Loops) bilden. Das Spanning Tree Protocol (STP) verhindert dies, indem es nur eine aktive Verbindung (Pfad) zwischen zwei Switches ermöglicht.
Das bedeutet, dass eine baumartige hierarchische Infrastruktur entsteht. Der Datenverkehr läuft in diesem Fall in "Nord-Süd-Richtung", also von den Access-Switches zu Aggregation- und Core-Systemen und wieder "hinunter". Diese wenig effiziente Technik war bislang für die meisten Einsatzzwecke ausreichend. Bei speziellen Anwendungen, etwa der Anbindung von Storage-Systemen, kamen Protokolle wie Fibre Channel und separate Speichernetze zum Zuge, die parallel zum Ethernet-LAN betrieben wurden. Um die Ausfallsicherheit sicherzustellen, wurden zusätzliche Switches und Netzwerkverbindungen eingesetzt.
Nun stehen Änderungen ins Haus: LAN Fabrics, die Ethernet-Switches auf Layer 2 mit Elementen des Layer-3-Routings verknüpfen, sollen die überkommende Struktur ablösen. Dafür führen die Anbieter von Fabrics mehrere Gründe an: den Trend in Richtung Virtualisierung und Cloud Computing, höhere Datenraten von 10 Gbit/s, 40 Gbit/s und künftig 100 Gbit/s sowie die Konvergenz unterschiedlicher Protokolle und Netztypen, speziell von Storage- und Datennetzen.
Virtual Machines erfordern neuartige Netzwerkinfrastruktur
Für den Einsatz von LAN Fabrics spricht, dass sie die Mobilität von Virtual Machines (VM) erhöhen. VM lassen sich mit einer Fabric schnell implementieren und bei Bedarf von einem Server oder Rack zu einem anderen verlagern. Dieser Vorgang kann automatisiert werden. In einem herkömmlichen Netzwerk ist das Verschieben von VMs von einem Server-Rack in ein anderes oder gar in ein anderes Rechenzentrum aufwendig. So muss der IT-Administrator Switch-Ports neu konfigurieren und sicherstellen, dass jeder VM Storage-Kapazitäten, Netzwerkbandbreite und Quality-of-Service-Eigenschaften (QoS) im erforderlichen Maß zur Verfügung stehen.
Wegen der engen Kopplung von LAN-Infrastruktur und IT-Services ist es zudem aufwendig, Netzwerkdienste in der gewünschten Qualität bereitzustellen oder an wechselnde Anforderungen anzupassen. Dies ist speziell in Cloud-Computing-Umgebungen ein Manko, zu deren größten Vorteilen die hohe Flexibilität zählt. Hinzu kommt, dass in virtualisierten Umgebungen, aber auch bei Web-2.0-Anwendungen, der Anteil der direkten Server-zu-Server-Kommunikation zunimmt. Das heißt, die Kommunikationsströme laufen verstärkt in "Ost-West-Richtung". Müssen Daten über Core-Switches und ein traditionelles Backbone-Netz übermittelt werden, sind Performance-Einbußen die Folge.
IT-Services von der Netzwerkinfrastruktur trennen
Ein Ausweg bietet die Trennung der LAN-Infrastruktur von IT-Services, die darüber bereitgestellt werden. Das lässt sich mithilfe von Fabrics erreichen. Bei diesem Ansatz wird zwischen der physischen Netzwerktopologie und der Routing-Ebene eine "virtuelle" Ethernet-Schicht implementiert. In Rechenzentren werden Fabrics eingesetzt, um die Trennung zwischen Daten- und Storage-Netzen aufzuheben. Mithilfe von Techniken wie Fibre Channel over Ethernet (FCoE) lassen sich beispielsweise Storage-Daten über die vorhandene IP-Infrastruktur übermitteln.
Foto: IDC
Eine Fabric bietet im Vergleich zu einer herkömmlichen LAN-Infrastruktur unter anderem folgende Vorteile:
• Die Netzwerkstruktur wird vereinfacht ("flacher").
• Applikationen, vor allem virtualisierte Anwendungen, weisen bessere Leistungsdaten auf.
• Eine Fabric weist eine bessere Redundanz auf, weil mehrere Pfade zwischen den Netzwerkknoten bestehen.
• Neue Services können schneller bereitgestellt und durchgängig (Ende-zu-Ende) verwaltet werden.
• Netzwerkknoten lassen sich im laufenden Betrieb zur Fabric hinzufügen oder von dieser entfernen. Die Switches ermitteln die neuen Pfade dabei selbstständig.
Mit dem Fabric-Konzept wollen die Hersteller die Anforderungen erfüllen, die laut einer Studie von IDC von 2012 derzeit vor allem IT-Fachleute beschäftigen, die Private Clouds aufbauen möchten. Demnach erweist sich nach Einschätzung der IT-Experten das konventionelle LAN als Problem bei der Bereitstellung neuer IT-Services. Bemängelt werden laut der Untersuchung insbesondere Bandbreitenengpässe, die komplexe Konfiguration und Wartung sowie der hohe Aufwand bei der Integration neuer Systeme ins Netz.
Layer 2 Multipath: Shortest Path Bridging oder Trill
Ein Kernproblem bei Fabrics ist die unübersichtliche Lage bei der Implementierung von Standards. Generell sind Layer-2-Multipath-Verfahren und Layer-3-Techniken zu unterscheiden. Die prominentesten Vertreter von Layer-2-Multipath-Protokollen sind Shortest Path Bridging (SPB) der Arbeitsgruppe 802.1aq des IEEE (Institute of Electrical and Electronics Engineers) sowie Transparent Interconnection of Lots of Links (Trill) der Internet Engineering Task Force (IETF).
SPB basiert auf einer Technik, die ursprünglich von Fachleuten von Nortel Networks für den Carrier-Bereich entwickelt wurde und nach der Insolvenz von Nortel zu Avaya gelangte. Seit März 2012 ist Shortest Path Bridging ein IEEE-Standard. SPB lässt Links und Protokolle im Netzwerk transparent werden und erzeugt auf diese Weise ein logisches LAN, in das alle Arten von End Points eingebunden werden können. Über das IS-IS-Routing-Protokoll (Intermediate System to Intermediate System) tauschen Netzwerkknoten in einer SPB-Domäne Statusinformationen, Fehlermeldungen und Routing-Daten aus.
Foto: Avaya
Trill und SPB verwenden unterschiedliche Verfahren für das Adressieren und den Transport (Forwarding) von Datenpaketen: Trill nutzt ein komplexes Verfahren, das eine Berechnung der Zieladressen in jedem Netzwerkknoten erforderlich macht. Bei SPB werden die MAC-Adresstabellen zur Berechnung des kürzesten Pfades durch das Netz herangezogen. Der gesamte Datenfluss lässt sich somit auf einfache Weise anhand der Quell- und Zieladresse nachvollziehen.
Beim Forwarding verwendet IEEE 802.1aq Link-Metriken, um im Vorfeld den idealen Datenpfad durch das Netzwerk zu ermitteln und diesem anschließend die zugehörigen Unicast- und Multicast-Pakete zuzuweisen. Es ist daher einfach, solche Traffic Flows nachzuverfolgen und mögliche Fehlerquellen zu ermitteln. Bei Trill kommen dagegen zwei unterschiedliche Mechanismen für Unicast- und Multicast-Paket zum Einsatz.
Jeder führende Netzwerkhersteller hat seine Fabric
Mittlerweile hat so gut wie jeder Hersteller von Switches eine "Fabric"-Lösung entwickelt und auf den Markt gebracht. Nach Einschätzung der Marktforschungsgesellschaft Gartner spielen derzeit vier Anbieter eine führende Rolle:
• Brocade mit VCS Fabric,
• Cisco Systems mit FabricPath,
• HP mit seiner FlexNetwork Architecture und
• Juniper Networks, das QFabric ins Rennen schickt.
Brocade hat seine VCS-Fabric, die bereits 2010 auf den Markt kam, in die Switches der VDX-Reihe integriert. Der Hersteller konzentriert sich mit seiner Fabric auf die Access-Ebene, lässt also kostspielige Core-Switches außen vor. Der Port-on-Demand-Ansatz von Brocade erlaubt es, Netzwerk-Ports in Häppchen hinzuzufügen. Ein Vorteil von Fabrics, so Jason Nolet, Vice President von Broacdes Data Center Group, sei die weitgehende Automatisierung von Managementfunktionen. Dies reduziere den Zeitaufwand um 15 bis 20 Prozent und verringere die Zahl von Fehlern infolge falscher Konfigurationseinstellungen.
Foto: Cisco
Cisco Systems verfolgt mit FabricPath und den Nexus-Switches einen anderen Ansatz. Ein Plus ist die große Skalierbarkeit von mehr als 10.000 Ports pro Fabric - ein "Muss" in großen Netzen. Ein weiteres Plus ist, dass der Anwender eine Lösung aus einer Hand bekommt. Der Vorteil: Der Nutzer erhält eine homogene Plattform mit Fabric-Modulen, die auf spezielle Anwendungsfelder zugeschnitten sind, etwa Big Data oder den Transport von Echtzeitdaten wie Voice over IP. Der Nachteil: Der Anwender bindet sich an einen Hersteller und dessen Lösungspartner. Im Februar 2013 stellt Cisco mit dem ONE Software Controller ein System vor, das Multiprotokoll-Interfaces für das Cisco One Open Platform Kit (onePK) und OpenFlow bereitstellt. Dies ist ein Schritt in Richtung Software Defined Networks.
Von flexiblen Netzen zu Virtual Application Networks
Einen ähnlichen Weg wie Cisco geht HP mit FlexNetwork. Dieses Fabric-Konzept ist nur ein Bestandteil einer übergeordneten Architektur, die Netzwerk-Services für den Campus-Bereich (FlexCampus) und für Außenstellen (FlexBranch) zur Verfügung stellt. Als Bindeglieder dienen eine (Netzwerk-)Managementebene (FlexManagement) und die FlexNetwork Architecture. FlexFabric fällt in dieser Konstellation die Aufgabe zu, im Rechenzentrum eine einheitliche Transportebene für Daten und Storage-Informationen zu bilden.
Foto: HP
Die FlexFabric bildet, ebenso wie FlexPath, die Basis für virtualisierte Netzwerke beziehungsweise IT-Services, sogenannte Virtual Application Networks (VANs). Ein VAN wird beispielsweise für E-Mail reserviert, eines für SAP-Datentransfers, eines für Video. Jedem VAN lasse sich spezielle Eigenschaften zuweisen, etwa Quality-of-Service-Features.
Foto: Juniper
Mit QFabric hat Juniper Networks einen anderen Weg als Cisco, Brocade und HP gewählt. Im Gegensatz zu den Fabrics der genannten Hersteller basiert QFabric nicht auf Trill, sondern auf einer eigenen Architektur. Vereinfacht gesagt kann man sich QFabric als großes, virtuelles Switch-Gehäuse vorstellen, in das der Nutzer bei Bedarf "Blades" einfügt. Der Ansatz basiert auf drei Elementen: dem QFabric Director, der für das Routing zuständig ist, dem QFabric Interconnect, der eigentlichen Fabric, die als Backplane fungiert, sowie den QFabric Nodes. Diese fungieren als Line Cards am Rand des Netzes und übernehmen das Routing und Switching zwischen den angeschlossenen Endgeräten.
Weitere Ansätze: von Alcatel-Lucent bis Dell
Weitere Anbieter sind Alcatel-Lucent mit Application Fluent Swichting und Avaya, das mit VENA (Virtual Enterprise Network Architecture) eine Architektur entwickelt hat, die auf Shortest Path Bridging aufsetzt. Avaya bietet mit den Collaboration Pods schlüsselfertige Fabric-Lösungen in Kombination mit Anwendungen an. Sie bestehen aus virtualisierten Servern, Speichersystemen sowie Netzwerk- und Managementkomponenten von Herstellern wie Avaya, EMC und VMware.
Die OneFabric des Switch-Herstellers Enterasys ist, ähnlich wie VENA von Avaya, darauf ausgelegt, sowohl das Rechenzentrum als auch einen Campus und mobile Systeme am Netzwerkrand in eine Fabric mit einbeziehen. Der Hersteller zielt mit seinem Produkt weniger auf eine Optimierung der Netzwerkinfrastruktur. Vielmehr will er auf Basis von Policies (Regelwerken), Network Access Control (NAC) und Sicherheitsfunktionen IT-Services in bestmöglicher Qualität bereitstellen - ein ambitionierter Ansatz, zumal Enterasys damit gegen Größen wie Brocade, Cisco, HP und Juniper antritt.
Extreme und Dell/Force10: Clouds und Virtualisierung im Fokus
Extreme Networks will mit der Open Fabric Data Center Solution vor allem das Einrichten von Private Clouds erleichtern. Ein Schwerpunkt des Ansatzes ist denn auch die Option, mehrere tausend Virtual Machines zu unterstützen und diese nach Belieben im Netzwerk zu bewegen. Extreme unterstützt neben SPB auch Trill und Data Center Bridging (DBB) sowie Multi-Switch Link Aggregation (M-LAG). Mittels M-LAG lässt sich im Netz die Auslastung von Links im Vergleich zum herkömmlichen Spanning-Tree-Verfahren verdoppeln. Die Architektur ist zudem für unterschiedliche Verkehrsarten ausgelegt, also neben IP auch für Fibre-Channel-Daten (via FCoE) und iSCSI.
Auch Dell mischt bei Ethernet- und Data-Center-Fabrics mit, allerdings mit Produkten, die durch die Übernahme von Force10 ins Haus kamen. Die Open Distributed Core Data Center Architecture basiert auf den Z9000-Switches von Force10. Sie lassen sich als Layer-2/3-Systeme konfigurieren oder alternativ dazu als Grundlage für eine Layer-2-Fabric auf Basis von Trill nutzen. Mittlerweile hat Dell seinen Ansatz zu einer Virtual Network Architecture (VNA) weiterentwickelt. Darin sind Fabrics nur ein Bestandteil, neben Netzwerkdiensten, einer übergeordneten Forwarding-Control-Ebene für Layer-2- und Layer-3-Daten sowie VXLANs. Auf der obersten Ebene sind Hypervisoren (Hyper-V, VMware, Citrix-Xen) und neue Ansätze wie OpenStack vertreten.
Hersteller zwischen Trill, SPB und eigenen Ansätzen
Eines der Kernprobleme, mit dem sich derzeit die Hersteller von Fabric-Lösungen, aber auch die Anwender auseinandersetzen müssen, besteht darin, dass die Anbieter von Switches unterschiedliche Wege verfolgen. Ein Teil setzt auf Trill, ein anderer auf SPB, wieder andere haben Switches für beide Normen entwickelt. Hinzu kommen herstellerspezifische Verfahren und proprietäre Ausprägungen von SPB und Trill. Für Anwender bedeutet dies, dass sie bei der Implementierung einer Fabric-Infrastruktur Gefahr laufen, auf die Produkte eines Anbieters festgelegt zu werden, Stichwort: "Vendor Lock-in".
So setzt Cisco Systems mit FabricPath in seinen "Nexus"-Switches eine eigene Trill-Version ein, behauptet jedoch, Trill-konform zu sein. Brocade greift bei seiner VCS-Architektur (Virtual Cluster Switching) de facto auf eine proprietäre Lösung zurück. Sie basiert zwar in der Data Plane auf Trill, verwendet auf der Control-Plane-Ebene jedoch Fabric Shortest Path First (FSPF) statt IS-IS. Nach eigenen Aussagen will Brocade allerdings künftig die von der IETF freigegebene Trill-Version unterstützen. HPs FlexNetwork-Architektur soll sowohl für Trill als auch für SPB ausgelegt sein. Bei Dell/Force10 sind ebenfalls mehrere Technologien im Spiel, neben Trill auch DCB (Data Center Bridging), EVB (Ethernet Virtual Bridging) und VEPA (Virtual Ethernet Port Aggregation).
Virtualisierung als Schlüsselfaktor für Fabric-Architektur
Für den Einsatz von Ethernet Fabrics spricht der verstärkte Einsatz von Virtualisierung. Die Marktforschungsinstitute Gartner und IDC haben ermittelt, dass die Hälfte aller Unternehmen mehr als 50 Prozent ihrer Produktionsserver virtualisiert hat oder das bis Ende 2013 zu tun beabsichtigt. Der Virtualisierungsspezialist VMware schätzt, dass Firmen und Organisationen mittlerweile 30 bis 40 Prozent der Server im Data Center virtualisiert haben. Die IT-Beratungsfirma Lippis erwartet daher, dass im Jahr 2014 rund 80 Prozent des Datenverkehrs über Layer-2-Multi-Path-Switching-Netze in "Ost-West-Richtung" laufen, also direkt zwischen Servern und Virtual Machines, und nicht mehr über die "Nord-Süd-Achse" von Access- bis zu Core-Switches und wieder zurück.
Wann der Umstieg auf ein Fabric-Netzwerk sinnvoll ist
Eine Ethernet-Fabric statt einer konventionellen Netzwerkinfrastruktur in einem Rechenzentrum kann Vorteile bringen. Nach Angaben von Zeus Kerravala, Gründer und Leiter der IT-Beratungs- und Marktforschungsfirma ZK Research, kommt die Implementierung einer Fabric insbesondere dann infrage, wenn folgende Faktoren gegeben sind:
Performance-Probleme des bestehenden Netzes: Steht ein Aufrüsten von Servern, Storage-Systemen und Netzwerk an, um Leistungsengpässe zu beseitigen, sollte der Umstieg auf eine Fabric in Erwägung gezogen werden.
Notwendigkeit, häufig Virtual Machines zu verschieben: Eine Fabric ist nicht unbedingt erforderlich, wenn VM nur innerhalb eines Server-Racks verschoben werden oder nur selten "VM Mobility" gefragt ist. Sobald Virtual Machines zwischen Racks oder gar Data-Centern bewegt werden, erleichtert eine Fabric dies jedoch.
Mangel an Platz, Kühlung und Stromversorgung: Eine Fabric beseitigt Flaschenhälse beim Datenverkehr in "Ost-West"-Richtung im Netz. Dadurch lässt sich die Virtual-Machine-Dichte erhöhen, was wiederum weniger Server, Kühlsysteme und Energie erforderlich macht.
Konvergenz von Daten- und Storage-Netzwerk: Konventionelle Netze sind nicht für konvergente Netze für Ethernet- beziehungsweise IP-Daten und die Übermittlung von Storage-Daten optimiert. Eine Fabric ist in dieser Beziehung deutlich flexibler.
Bevorstehendes Upgrade der Netzwerkinfrastruktur: Steht ohnehin ein Umbau des Netzes an, bietet es sich an, eine Fabric zu implementieren. Umbau bedeutet beispielsweise die Implementierung von 10- oder 40-Gigabit-Ethernet oder von Fibre-Channel-over-Ethernet (FCoE).
Konsolidierung des Rechenzentrums oder Einrichtung eines neuen Data Centers: So wie bei größeren Upgrades der Netzwerkinfrastruktur sollte auch in diesem Fall abgewogen werden, ob nicht besser eine Ethernet- beziehungsweise Data-Center-Fabric statt althergebrachter Technologien implementiert werden soll. Für eine Fabric spricht in jedem Fall die Zukunftssicherheit.
Hoher Virtualisierungsgrad von Anwendungen: Sind mehr als 50 Prozent der Tier-1-Anwendungen - der geschäftskritischen Applikationen - virtualisiert, steigen die Anforderungen an die Zuverlässigkeit und Verfügbarkeit des Netzwerks. Fabrics sind wegen der Verfügbarkeit von redundanten Verbindungen fehlertoleranter als eine herkömmliche Infrastruktur. Daher sind sie für solche Anwendungen besser geeignet.
Zu hoher Komplexitätsgrad der bestehenden Infrastruktur: Ein Indikator dafür, dass eine Netzwerkinfrastruktur "zu komplex" ist, sind stark steigende Kosten für den IT-Support. Fabrics sind einfacher zu managen und flexibler, was die Konfiguration betrifft. Unternehmen, die ihr Netz vereinfachen und die Managementkosten senken wollen, sollten daher die Implementierung einer Fabric-basierten Infrastruktur ins Auge fassen.
Administrationsaufwand: RSMLT und MSTP versus Shortest Path Bridging
Ein Argument, das Anbieter von Netzwerk-Fabrics für ihre Produkte ins Feld führen, ist unter anderem der niedrigere Zeitaufwand bei der Administration der Netzwerkinfrastruktur. Verlässliche Daten dazu sind jedoch rar. Die amerikanische Beratungsgesellschaft Miercom hat im Auftrag von Avaya ermittelt, wie viel Zeit IT-Administratoren pro Jahr für die Konfiguration von Virtual LANs zwischen zwei Rechenzentren aufwenden müssen, wenn unterschiedliche Layer-2-Link-Aggregation-Protokolle zum Einsatz kommen. Verglichen wurden die herkömmlichen Ansätze Routed Split Multi-Link Trunking (RSMLT) und Multiple Spanning Tree Protocol (MTSP) mit Shortest Path Bridging (SPB).
Foto: Miercom
Das Ergebnis: Abhängig davon, wie viele Top-of-Rack-Switches (ToR) eingesetzt wurden, fielen bei SMLT rund 300 Stunden (bei 50 Switches) bis 17.600 Stunden (bei 10.000 Switches) an. Bei MSTP waren es zwischen 770 Stunden und rund 71.000 Stunden pro Jahr. Deutlich darunter lag SPB mit Werten von 191 Mannstunden bei 50 Switches und rund 1.550 Stunden, wenn 10.000 ToR-Switches in einem Großrechenzentrum zum Zuge kamen. Das heißt, dass sich mithilfe von Shortest Path Bridging in erheblichem Maße Arbeitszeit einsparen lässt. Das wiederum bedeutet eine geringere Belastung der IT-Abteilung und niedrigere Personalkosten.
Zudem prüfte Miercom die Fehlerredundanz von Shortest Path Bridging. Fiel ein kompletter Switch oder ein einzelner Port aus, betrug die Failover-Zeit weniger als eine Sekunde. Der gleiche Wert wurde für das komplette Netzwerk ermittelt, wenn Switch-Cluster eingesetzt wurden.
Unbefriedigende Situation
Für Unternehmen, die eine Fabric implementieren möchten, ist diese Lage höchst unbefriedigend. Solange unterschiedliche Standards und "Industrienormen" existieren, müssen sie sich de facto an einen Anbieter binden. Das bringt naturgemäß Netzwerkfirmen mit einer großer "Ökosphäre" wie Cisco, HP, Brocade, Brocade und Juniper Vorteile. Oder die Anwender warten ab, bis sich ein Standard, etwa Trill oder Shortest Path Bridging, durchgesetzt hat und interoperable Produkte mehrerer Anbieter zur Verfügung stehen.
Damit nicht genug: Neben Fabrics drängen weitere Technologien ins Rechenzentrum, etwa Software Defined Networks (SDN). Somit bleibt dem Netzwerkverwalter nur eines: Er muss sorgfältig abwägen, auf welche Technik beziehungsweise welchen Hersteller er setzen möchte. Das bedeutet nicht zwangsläufig, dass ein großer Anbieter wie etwa Cisco die beste Wahl ist. Wichtig ist in jedem Fall, dass der Anbieter eine schlüssige Strategie vorweisen kann, die Schlüsseltechnologien wie Virtualisierung und die Anbindung von Cloud-Computing-Ressourcen umfasst. (hal)