Foto: IBM
Die Art und Weise, wie Unternehmen IT-Ressourcen bereitstellen und wie Anwender diese nutzen, hat sich grundlegend gewandelt. Während früher starre, monolithische Rechensilos und hierarchische Server-Client-Beziehungen typisch waren, haben Trends aus dem Endkundenbereich wie Self-Service und das App-Prinzip längst auch in Unternehmensanwendungen Einzug gehalten.
Die zunehmende Virtualisierung der Server, Service-orientierte Architekturen (SOA) und auf Microservices oder Webservices basierende verteilte Softwarekonzepte haben zu einer anderen Verteilung der Kommunikationsströme geführt. Während früher der Datenaustausch von "Nord nach Süd" erfolgte, also von den zentralen Servern im Rechenzentrum zu Endgeräten im LAN, steht heute die Kommunikation zwischen - oft virtuellen - Servern in "Ost-West"-Richtung im Vordergrund.
Klassische dreistufige Netzwerktopologien sind für diese Verlagerung nur schlecht geeignet, da jedes Paket vom Quell-Server über die Edge-Ebene und die Aggregationsschicht in den Core und vor dort wieder über Aggregations- und Edge-Layer zurück zum Zielserver geleitet werden muss. Ein derart umständliches und ineffizientes Routing verlängert nicht nur die Reaktionszeiten, sondern sorgt durch seine Komplexität auch für einen hohen Wartungsaufwand und eine große Fehleranfälligkeit. Es macht Netzwerke unbeweglich und langsam und verhindert eine schnelle Bereitstellung von Services.
Der klassische Netzwerkaufbau im Rechenzentrum
Trotz dieser Nachteile sind auch heute noch viele Netzwerke im Rechenzentrum dreistufig aufgebaut. Grund dafür ist häufig, dass sich diese Topologie nicht so einfach ersetzen lässt, es gibt Sachzwänge wie Brandabschnitte oder die vorhandene Verkabelung.
Bei diesem Implementierungsmodell geht der erste Hop von einem Rackmount- oder Blade-Server meist zu redundanten Switches im Rack beziehungsweise Blade-Switches im Blade Enclosure. Diese Anbindung wird als "Top of Rack" (ToR) bezeichnet. Die Verkabelung erfolgt in der Regel über ebenfalls redundant ausgelegte 1- oder 10-Gigabit-Ethernet-Verbindungen.
Die erzielbare Portdichte ist abhängig vom jeweiligen Transceiver-Modul. So kann ein ToR-Switch auf einer Höheneinheit 48 Ports mit SFP+-Modulen (Small Form-Factor Pluggable plus) oder 32 Ports mit QSFP-Modulen (Quad Small Form Factor Pluggable) haben. Der blockierungsfreie Datendurchsatz von ToR-Switches kann ein Terabit pro Sekunde (Tbit/s) und höher sein.
Im nächsten Schritt fließt der Datenverkehr in eine Aggregations-Ebene. Häufig stehen die Aggregations-Switches am Ende einer Rack-Reihe, weshalb diese Stufe auch als "End of Row" (EoR) bezeichnet wird. EoR-Switches müsse natürlich deutlich performanter sein als ToR-Switches.
Von der Aggregationsschicht gelangt der Netzwerkverkehr in traditionellen Rechenzentren zur Core-Ebene. Core-Switches sind die leistungsfähigsten Netzwerkgeräte im Rechenzentrum mit der höchsten Portdichte, der geringsten Latenz und dem größten Durchsatz.
Das Spanning-Tree-Protokoll und seine Nachteile
Um Ausfallsicherheit zu gewährleisten, sind im Netzwerk in der Regel alle Verbindungen redundant ausgelegt. Das Spanning Tree Protocol (STP) - oder seine moderneren Varianten Rapid Spanning Tree Protocol (RSTP) und Multiple Spanning Tree Protocol (MSTP) sorgen klassischerweise dafür, dass immer nur ein Pfad zwischen zwei Switches aktiv ist, damit es nicht zu Endlosschleifen oder Broadcast-Stürmen kommt. Fällt der aktive Pfad aus, wählt das Protokoll automatisch eine Alternativverbindung und aktiviert diese. STP ist weit verbreitet und erfüllt die Aufgabe in der Regel sehr gut, ein Netzwerk ausfallsicher zu machen. In modernen, agilen Hochgeschwindigkeitsnetzen hat es jedoch einige gravierende Nachteile:
Lange Umschaltzeiten: Fällt ein Pfad oder Switch aus, kann es Sekunden dauern, bis STP einen alternativen Weg findet und aktiviert. Dies ist für viele Anwendungsfälle inakzeptabel. So hat das Marktforschungsunternehmen Aberdeen Group berechnet, dass für eine E-Commerce-Webseite, die 100.000 Euro am Tag umsetzt, bei einer täglichen Verzögerung von nur einer Sekunde jährliche Ertragseinbußen von 2,5 Millionen Euro zu erwarten sind. In einer Umfrage von Equation Research unter 400 Online-Einkäufern gaben 22 Prozent an, bei Komplikationen in einem Webshop sofort zur Konkurrenz zu wechseln. Noch gravierender können die Folgen für Finanztransaktionen sein, in denen oft Millisekunden über Milliardenbeträge entscheiden.
Komplexe Verwaltung: Auch wenn mit MSTP und RSTP die Umschaltzeiten wesentlich kürzer sind, haben alle drei Protokollvarianten gemein, dass sie besonders in großen Netzwerken sehr aufwendig zu managen sind. Jeder Switch muss einzeln verwaltet werden, auf jedem muss der Administrator die STP-Instanz für jeden Port oder sogar für jeden virtuellen Port aufsetzen und dafür sorgen, dass die Parameter benachbarter Switches zueinander passen. Die Fehlersuche in einem Spanning Tree ist ausgesprochen langwierig und schwierig, da die eigentliche Fehlerquelle häufig nur schwer zu finden ist.
Ineffizienz: Da STP immer nur einen Pfad zwischen zwei Punkten aktiviert, können bei einer redundanten Verkabelung maximal 50 Prozent der vorhandenen Bandbreite genutzt werden.
Zu viele Kompromisse: Die Wahl zwischen STP, MSTP und RSTP ist schwierig und stellt immer nur einen Kompromiss dar. So ist MSTP zwar wesentlich effizienter als die anderen beiden Varianten, dafür aber auch deutlich schwieriger zu managen. Die leichtere Verwaltung erkauft man sich bei STP und RSTP wiederum durch geringere Effizienz.
Vereinfachung der Netzwerktopologie
In einem ersten Schritt gilt es, die Topologie im Netzwerk auf zwei Stufen zu reduzieren, um zu einer "Spine-Leaf"-Architektur zu gelangen. Dazu integriert man Edge- und Aggregations-Layer und setzt im Core mehrere kleine Systeme statt wenige große ein, die man zu einem virtuellen Device zusammenfasst. Dies lässt sich beispielsweise mit dem "Intelligent Resilient Framework" (IRF) erreichen. Flache Netze lassen sich auch mit anderen Fabric-Technologien erreichen, etwa durch TRILL (Transparent Interconnection of Lots of Links) oder Shortest Path Bridging (SPB). TRILL-Switches, auch Routing Bridges (RBridges) genannt, kommunizieren über das Link-State-Protokoll IS-IS (Intermediate System to Intermediate System). IS-IS erlaubt ein reines Layer-2-Netzwerk ohne Konfiguration oder IP-Adressen.
Jeder Switch hat genügend Informationen über alle anderen Switches und die Verbindungen zwischen ihnen, um entweder den besten Pfad oder zumindest einen Verteilungsalgorithmus für den Datenverkehr zu erzeugen. Das geschieht etwa wenn das Ziel unbekannt ist oder es sich um einen Multi- beziehungsweise Broadcast handelt. Um die Effekte von Schleifenbildung abzumildern, senden TRILL-Switches im Header einen Hop Count und führen einen Reverse-Path-Check durch. SPB, auch als IEEE 802.1aq bekannt, blockiert im Unterschied zu STP keine Pfade.
Wie bei TRILL sorgt das Link-State-Protokoll IS-IS für die Kommunikation zwischen den Bridges. Es dient dazu, die Netzwerktopologie zwischen den kommunizierenden Geräten zu definieren und auszutauschen und die kürzesten Wege (Shortest Path Trees, SPT) zu berechnen. Beide Technologien lassen sich auch sehr effektiv in Kombination mit IRF einsetzen. Die Komplexität gegenüber herkömmlichen hierarchischen Topologien sinkt dadurch um den Faktor 20.
Die höchste Form der Vereinfachung ist die Aggregation des Netzwerkverkehrs im Server und die direkte Anbindung an den Core. Dies ist aber nur mit Blade Enclosures und Virtual-Connect-Modulen möglich. Diese Einschubmodule liefern N mal 10 GbE-Ports, die als virtuelle Ports von virtuellen NICs präsentiert werden. Anders als bei einem Switch stellen die Ports im Virtual-Connect-Modul keinen zusätzlichen Hop dar. Im Blade Enclosure gibt es dann keine Switch-Instanz mehr, sondern nur noch eine Abstraktion der Netzwerkadapter. Eine entsprechende Port-Dichte vorausgesetzt, kann der Netzwerkverkehr direkt auf den Core geleitet werden, sodass zwischen zwei Blade-Servern in unterschiedlichen Enclosures nur noch ein Hop nötig ist.
Auf dem Weg zum mandantenfähigen Cloud-Rechenzentrum
IRF, TRILL und SPB erlauben es, Netzwerktopologien zu vereinfachen und Umschaltzeiten zu minimieren. In Cloud-Umgebungen ist es jedoch oft auch erforderlich, Rechenkapazität und Services einzelnen Mandanten zur Verfügung zu stellen. Dazu müssen sich physikalische Geräte in mehrere logische Einheiten aufteilen lassen.
Die Zukunft der Netzwerke
Die Vereinfachung von Topologien und die Virtualisierung der Switches sind nur erste Schritte auf dem Weg in die Zukunft der Netzwerke. Folgende Trends erwarten uns in naher und etwas fernerer Zukunft:
Hyperscale-Rechenzentren mit Bare-Metal-Switches: Google und Facebook machen es vor: Statt komplexer funktionsreicher Switches nutzen sie einfache Hardware. Die komplette Intelligenz wandert ins Netzwerk. Portzahl, Bandbreite und Verbindungskapazität lassen sich in Sekunden erweitern, indem einfach weitere Bare-Metal-Switches zugeschaltet werden.
Software-Defined Networking (SDN): SDN zentralisiert und virtualisiert die komplette Control Plane und entkoppelt sie von der Data Plane. Dies reduziert nicht nur den Aufwand für Management und Konfiguration, sondern erlaubt es auch, Dienste und Ressourcen automatisiert im Self-Service bereitzustellen.
Data Center in a Box: Platz- und Energieverbrauch herkömmlicher Rechenzentren sind enorm und werden angesichts des Datenwachstums noch massiv zunehmen. Hochintegrierte Lösungen verbrauchen bei derselben Leistung fast 90 Prozent weniger Energie als traditionelle Systeme, und dies bei 80 Prozent weniger Platzbedarf. Die Verkabelung lässt sich gar um 98 Prozent reduzieren. Einen Quantensprung weiter geht das Projekt "The Machine". Dank Memristor-Technologie und der Datenübertragung per Lasertechnologie werden in der Zukunft auf einer Einschubkarte bis zu 2500 CPUs und 320 TB Speicher Platz haben. Ein Chassis von "The Machine" könnte möglicherweise 75.000 CPUs und 10 PB an Speicher zur Verfügung stellen und dabei weniger als 1.000 Watt Leistung benötigen. (mb)