23. Sept. 2011 - Eine aktuelle Übersicht zum Netzwerk-Design für Rechenzentren und einige Auswirkungen im Zusammenhang mit Speichernetzen...
Einleitung: Im Laufe der Jahre haben sich die Aufgabenstellungen an Ethernet- Netzwerke innerhalb des Rechenzentrums doch stark verändert. Netze sollen heute den Datenverkehr für unterschiedlichste Anwendungen, einschließlich Client-Server-Apps, Web Services, Unified Communications, Virtual Maschine-Management und zunehmend auch den virtualisierten Storage-Traffic mit jeweils unterschiedlichsten Profilen und Netzwerk-Service-Anforderungen unter gestiegenen QoS-Anforderungen sicherstellen. Und Private-/Hybrid Cloud - Infrastrukturen verlangen nach jederzeit leistungsmäßig skalierbaren Netzwerken, die möglichst einfach zu verwalten (Stichwort: Kosten) und zu konfigurieren sind.
- Aus Storage-Sicht stellt der Block-basierte (virtual-) Storage I/O zum Teil sehr hohe Anforderungen an das Netzwerk einschließlich der verlustfreier Übertragung, möglichst vorhersagbarer Latenzzeiten und entsprechender Bandbreite, dies auch immer öfter im Verbund mit Solid-State-Disk-Arrays... Oder mit anderen Worten: Gestiegene Anforderungen an die Skalierbarkeit, Performance, Verfügbarkeit, Sicherheit, Energieeffizienz sowie ein flexibles, transparentes Handling inklusive pro-aktivem Management sind im Rahmen des Designs von modernen Netzwerk-Infrastrukturen zu berücksichtigen...
Ethernet Fabrics (hier abgekürzt: EF’s) repräsentieren eine Technik, um die nachfolgend aufgeführten Beschränkungen traditioneller Ethernet-Netzwerke aufzuheben. Dies ist interessant im Zusammenhang mit Virtualisierung und Automation sowie der fortschreitende Konsolidierung und Standardisierung von Infrastrukturen in RZ. Die Konvergenz von FC SANs mittels FCoE setzt in diesem Zusammenhang voraus, dass die Limitationen des klassischen Ethernets beseitigt werden und existierende SAN-Fabrics über FCoE auch an eine Ethernet Fabric angeschlossen werden können.
1. Limitationen von Standard Ethernet Netzwerken
Klassische Ethernet-Netzwerke sind traditionell hierarchisch in mehreren Schichten aufgebaut. Der Traffic fließt innerhalb dieses logischen Baums im RZ nun zwischen Serverracks, was höhere Latenzzeiten sowie Bandbreiten-Engpässe bei Inter-Switch Links zur Folge hat. Das Spanning Tree Protocol (STP) verhindert zwar Loops, indem nur ein aktiver Pfad oder Interswitch-Link zwischen jeweils zwei Switches erlaubt ist. Das bedeutet aber, dass diese Bandbreite auf eine einzige Verbindung begrenzt ist: Mehrere Pfade zwischen den Switches sind nicht vorgesehen.
Verschiedene Erweiterungen ermöglichen es, diese Beschränkung durch Link Aggregation Groups (LAG) zu überwinden und wurden so definiert, dass mehrere physikalische Verbindungen zwischen den Switchen als eine einzige Verbindung ohne Loop gehandhabt werden können. Der Nachteil: Die LAG muss manuell konfiguriert werden und ist bei umfangreichen Konfigurationen nicht sehr flexibel (Bandbreiten-Begrenzung). Wenn ein neuer Switch hinzukommt, wird es zudem schwieriger, die verschiedenen LAG-Verbindungen zeitnah manuell zu konfigurieren.
2. Grundlagen zu Ethernet Fabrics
Die Ethernet Fabric arbeitet ohne Spanning-Tree-Protokoll mittels einer „Selbst-Aggregation“ von ISL-Verbindungen zwischen den angebundenen Switches. Im Gegensatz zur bisherigen (Layer-3) Hierarchie - Access, Aggregation, Core- handelt es sich ein flexibel erweiterbares, flaches Layer-2 Netzwerk. Die manuelle Konfiguration von LAG-Ports ist im Layer-2 Netz anders als bei Layer-3-Topologien überflüssig und skalierbare Bandbreite steht ohne QoS-Beeinträchtigung zur Verfügung. Die Fabric unterstützt dabei alle gängigen Netzwerk-Topologien wie Ring, Baum oder Mesh. Zur Vermeidung von Engpässen bieten aktive ISLs die Möglichkeit zur Skalierung des Netzwerkes, je nach Verkehrsaufkommen.
3. Die Vorteile der Ethernet Fabric bei der Virtualisierung
Standard-Ethernet-Switching erfordert die Konfiguration aller Switch-Ports. Hierzu zählen auch Policies wie QoS, VLAN-Verkehr oder Security. Solange ausschließlich physische Server mit dem Netzwerk verbunden sind (bisheriges Silo-Modell) ist diese Architektur meist ausreichend. Aber das rasche Wachstum virtualisierter Server-Instanzen und aufkommende private Cloud Computing - Modelle erfordern, dass immer mehr virtuelle Maschinen pro Switch-Port konfiguriert werden müssen.
Wenn jedoch nun eine oder mehrere virtuelle Maschinen entweder für Load Balancing- oder Wartungszwecke migriert werden sollen, muss die bisherige Port-Konfiguration jeweils zu dem neuen Netzwerk-Port verschoben werden oder die Migration ist fehlerhaft. Dies bedeutet manuelle Konfigurationseingriffe bzw. Skripting und steht damit einem pro-aktiven, automatisiertem Management der virtuellen Infrastrukturkomponenten kontraproduktiv entgegen.
- Ethernet Fabrics ermöglichen den Austausch gemeinsamer Konfigurationsparameter innerhalb aller Switch-Ports der Fabric. Im unserem Falle der Migration von virtuellen Maschinen sind die Netzwerk-Policies für die virtuelle Maschine bei jedem Switch-Port somit bereits vorhanden. Dies bedeutet, die Migration von VMs erfordert keine manuelle Änderungen an der Netzwerkkonfiguration, denn Konfigurations-Informationen werden immer zwischen allen Geräten getauscht. Die EF identifiziert immer den kürzesten Loop-freien Weg und leitet Frames mit der jeweils möglichst geringsten Latenz weiter. Dies ist sehr hilfreich beim Storage I/O: Hier sind hohe Latenzzeiten generell kritisch und können die Applikationsverfügbarkeit negativ beeinflussen.
Klassisches Ethernet wird bislang verwendet, um Loop-freie Pfade zu schaffen. Dafür bildet man einen logisch Switch-Baum, der hierarchisch aufgebaut ist. Selbst wenn mehrere Links für mehr Skalierbarkeit und Verfügbarkeit verbunden sind, kann jeweils nur ein Link bzw. LAG aktiv sein. Dies reduziert natürlich auch die Verfügbarkeit und QoS: Wenn ein neuer Link hinzugefügt oder entfernt wird, ist der gesamte Netzwerk-Verkehr unter Umständen für Sekunden unterbrochen während ein neuer Loop-freier Baum konfiguriert wird. Für den Storage-I/O-Traffic und virtual machine – Applikationen ist das ungünstig und kann bei latency-sensitiven Anwendungen zum Server-Crash führen. Ethernet Fabrics nutzen als Alternative ein sog. „Link State-Multipath Routing“, welches immer den jeweils kürzesten Weg durch das Netzwerk erlaubt. Wenn ein Link hinzugefügt oder entfernt wird, ist sichergestellt, dass weiterhin der Verkehr zu anderen Links unterbrechungsfrei fließt. Die Link-Ausfallsicherheit bleibt gewährleistet und die maximale Auslastung aller Verbindungen zwischen Switches ohne manuelle Konfigurationsänderungen ist möglich.
4. Vorteile beim Management und der Automatisierung
Klassisches Switching erfordert je nach Größe und Komplexität der Umgebung ein umfangreiches Management: Jeder Switch und Switch-Port muss für diverse Protokolle wie MSTP, LAG, STP, VLANs, Netzwerk-Policies, QoS, Sicherheit usw. konfiguriert werden. Je mehr Server-Racks hinzugefügt werden, desto mehrere Switche müssen eingerichtet werden. Jede Konfiguration erfordert damit typischerweise manuelle Eingriffe, denn gemeinsame Konfigurationsparameter existieren kaum. Die Folge: Eine Hochgradige Automatisierung ist kaum zu erzielen.
Wird in einer Ethernet Fabric ein neuer Switch hinzugefügt, erfolgt sofort der automatische Informationsaustausch zwischen allen angeschlossenen Switches innerhalb der Fabric. Informationen zu vorhandenen Geräte, Netzwerk-Policies, Security und QoS – Aspekten stehen automatisch zur Verfügung. Dies vereinfacht natürlich die Netzwerk-Konfiguration und reduziert menschliche Fehler bzw. Betriebskosten (TCO).
Bisheriges Fazit
Ethernet Fabrics repräsentieren eine neue Technologie-Kategorie innerhalb des Rechenzentrums, vielleicht vergleichbar FC (SAN-) Fabrics vor 10 Jahren. Bei der Evaluierung von entsprechenden Lösungen ist darauf zu achten, dass Ethernet Data Center Bridging (DCB), TRILL (Transparent Interconnection of Lots of Links) und Fiber Channel over Ethernet - Standards Produkt-/Anbieterseitig unterstützt werden um sicherzustellen, dass wichtige Entwicklungen wie Lossless Ethernet und low latency – Funktionen beim Aufbau einer konvergenten Netzwerk-Architektur im RZ entsprechend berücksichtigt werden.
Weitere Details zur Technik und Positionierung finden Sie auch in den unten genannten Blogs oder unter test.84ghz.de/PROJEKTE/storageconsortium_update
Quellenangaben:
> http://wikibon.org/blog/virtualization-requirements-driving-ethernet-fab...
> http://ethernetfabric.com/2011/01/what-is-an-ethernet-fabric/