Ethernet für Netzwerke in Rechenzentren optimieren

Rechenzentren stellen besonders hohe Anforderungen an die Netzwerkinfrastruktur. Daher muss ein Ethernet-Netzwerk dahingehend optimiert werden.

Ethernet ist seit Jahrzehnten die LAN-Technologie der Wahl. Vor diesem Hintergrund ist es keine Überraschung, dass...

ihre Bedeutung auch in den Netzwerken von Rechenzentren zunimmt. Druck zur Kostensenkung, Konsolidierung von Ressourcen und Unterstützung neuer Software-Modelle wie SOA bringen dabei zusammen einen ganz neuen Satz von Anforderungen für Ethernet im Rechenzentrum.

Fast ohne Zweifel wird Ethernet irgendwann in der Lage sein, diese Anforderungen zu erfüllen. Ebenso sicher allerdings ist, dass die Entwicklung der Ethernet-Technologie selbst sowie die von alten Modellen für Ethernet-LANs zu neueren in den nächsten drei Jahren einige Unruhe in die Planung von Rechenzentren-Netzwerken bringen wird – also den gesamten aktuellen Refresh-Zyklus über. Während des Übergangs müssen Rechenzentren- und Netzwerk-Teams lernen, Ethernet in seiner jetzigen Form zu optimieren, sich also um Latenz und Paket-Verluste zu kümmern. Dabei helfen Strategien wie das Isolieren von Storage-Netzwerken oder die Auswahl der passenden Switches.

Rechenzentren-Ethernet: Mehr als Basis-Konnektivität

Rechenzentren-Netzwerke haben sich ausgehend von ihrer ursprünglichen Mission, Konnektivität zwischen zentralen Computer-Systemen und Nutzern bereitzustellen, weiterentwickelt. Heute haben sie drei unterschiedliche Aufgabenbereiche, von denen jeder seine eigenen Anforderungen hinsichtlich Datenverkehr und QoS hat:

  • Traditioneller Client/Server- oder „Frontend“-Traffic, der gegenüber Latenz wie Paket-Verlusten relativ unempfindlich ist.
  • „Horizontaler“ Datenverkehr innerhalb von Anwendungen; dieser entsteht größtenteils durch den Trend zu Software in Komponenten und Service-orientierten Architekturen (SOA) und erfordert geringe Latenz, ist aber nicht sehr sensibel gegenüber Paket-Verlusten.
  • Storage-Datenverkehr, der sich aus der Migration von Storage-Protokollen zu IP und Ethernet (iSCSI und FCoE) ergibt. Storage-Traffic ist sensibel gegenüber Latenz und noch sensibler bei Paket-Verlusten.

Unterschiedliche Traffic-Typen bringen also unterschiedliche Anforderungen hinsichtlich QoS im Netzwerk eines Rechenzentrums mit sich. Das ist eine Herausforderung, die noch größer wird durch die Tatsache, dass diese Typen stark miteinander zusammenhängen. Von Nutzern generierte Transaktionen in der Client/Server-Kommunikation aktivieren Prozesse, die horizontal miteinander verbunden werden müssen, und diese Prozesse greifen auch auf Storage-Arrays zu. Die Performance einer Anwendung hängt also von all diesen Datenströmen zusammen ab – und davon, ob Traffic von einem mit einem anderen um Ressourcen konkurriert.

QoS in Rechenzentren-Netzwerken: Isolieren von Storage-Netzwerken

Wenn gegenseitige Abhängigkeiten ein Thema sind, liegt eine offensichtliche Lösung darin, den Datenverkehr in unabhängige LANs zu unterteilen. Dies kann zunächst erscheinen wie ein verschwenderischer Verzicht auf die Größenvorteile, die Ethernet im Rechenzentrum bietet. Doch für manche Nutzer ist es absolut sinnvoll, Storage-Netzwerke zumindest so lange zu isolieren, bis sie auf Ethernet-Verbindungen migriert sind. Große Rechenzentren dürften die meisten Größenvorteile auch dann erreichen, wenn ihre LANs physisch getrennt sind. Weil Storage-Datenverkehr mit Abstand am stärksten auf gute Netzwerk-Performance angewiesen ist, kann seine Abtrennung die Schwierigkeiten beim QoS-Management für die drei Anwendungsklassen deutlich verringern.

Wichtig in diesem Zusammenhang: Durch eine Partitionierung über virtuelle LANs (VLANs) lässt sich normalerweise keine Isolierung von Datenverkehr erreichen, denn bei den meisten Switching-Produkten werden VLAN-Partitionen beim Zugriff auf die Leitungen zwischen Switches und beim Warteschlangen-Management nicht berücksichtigt. Derzeit begutachten IEEE und IETF eine Reihe von Standards, die Unternehmen mehr Kontrolle über Traffic-Klassen in Ethernet-Netzen geben sollen, doch die Entwicklung ist hier noch nicht abgeschlossen. Zu den Standards zählen Data Center Bridging (DCB), Priority Flow Control (PFC), Lossless Service und Enhanced Transmission Selection (ETS). Netzwerk-Planer sollten die Unterstützung ihrer Technik-Lieferanten für diese Standards prüfen, wenn sie Rechenzentren konzipieren.

Maßnahmen gegen Latenz und Paket-Verluste in Rechenzentren-Netzwerken

Sogar ohne neue Standards gibt es einige Möglichkeiten, um Verbesserungen bei Latenz und Paket-Verlusten zu erreichen. Dazu zählen:

  • Verwendung der höchsten Ethernet-Geschwindigkeit, die wirtschaftlich zu rechtfertigen ist. Die Latenz lässt sich durch mehr Tempo bei der Anbindung und zwischen Switches stets verringern. Mit schnelleren Verbindungen geht außerdem eine geringe Auslastung einher, die sich positiv auf Paket-Verluste auswirkt. Wenn es nicht praktikabel ist, alle Ethernet-Verbindungen zu beschleunigen, sollten Sie zumindest dafür sorgen, dass Storage-Traffic über die schnellsten verfügbaren Verbindungen geleitet wird.
  • Einsatz großer Switches statt Schichten vieler kleiner. Dieses Vorgehen, auch als „Verflachung“ des Netzwerks bezeichnet, verringert die Zahl der Switches, die ein bestimmter Datenstrom zwischen Quelle und Ziel passieren muss. Dadurch sinken Latenz und die Gefahr von Paket-Verlusten. Ebenfalls verringert wird der Jitter, also die Schwankungen bei diesen beiden Parametern, was die Performance von Anwendungen besser planbar macht.
  • Verwendung von „cut through“-Switches, die das Switching gegenüber dem üblichen „store and forward“-Ansatz beschleunigen können. Konventionelle Switches warten, bis der gesamte Daten-Frame eingetroffen ist, bevor er weitergeleitet wird. Bei Cut Through dagegen wird sofort der Header von Paketen untersucht und die Pakete zur Warteschlange des entsprechenden Output-Ports geleitet. Dadurch sinkt die Switching-Latenz.
  • Besondere Beachtung der Netzwerk-Karten für Server und Storage-Systeme. Manche davon sind so konzipiert, dass sie den Host von einiger Verarbeitung entlasten; dadurch bieten sie bessere und berechenbarere Performance.
  • Den wichtigsten Traffic durch eine möglichst geringe Zahl von Switches leiten. Server und Storage-Arrays, die üblicherweise zusammen genutzt werden, sollten also denselben Switch verwenden. Zumindest aber sollten sie auf direkt verbundenen Switches liegen statt auf einem Pfad, der durch ein Zwischen-Gerät führt (manche bezeichnen das als „Routing auf derselben Switch-Ebene“, im Gegensatz zu einer Beförderung von Daten über verschiedene Ebenen der Switch-Hierarchie).
  • Switch-Parameter auf Storage-Ports so einstellen, dass der Paket-Verlust am geringsten ist – selbst um den Preis von Verzögerungen. Paket-Verluste können für Protokolle im Bereich Storage-over-Ethernet verheerend sein.

Separieren des Nutzer-Traffics für QoS in Rechenzentren-Netzwerken

Ein wirklich optimales Netzwerk für ein Rechenzentrum kann nicht auf der Grundlage einer alten Struktur mit vernetzten Ethernet-Switches am Hauptsitz entstehen. Meist ist es sogar so: Die Integration des „Frontend“-Teils zum Zugriff auf Anwendungen im Rechenzentrum mit dem Storage- bzw. horizontalen Teil am Backend verhindert eine optimale Performance.

Ein wirklich optimales Netzwerk für ein Rechenzentrum kann nicht auf der Grundlage einer alten Struktur mit vernetzten Ethernet-Switches am Hauptsitz entstehen.

Tom Nolle, President, CIMI Corporation

Stattdessen ließe sich der Nutzer-Datenverkehr über von Storage- oder horizontalem Traffic komplett getrennte Einrichtungen leiten. Wenn Sie die Traffic-Typen trotzdem integrieren, zwingen Sie Ihr Netzwerk, für Latenz und Verluste sensiblen Datenverkehr zusammen mit anspruchsloserem zu befördern. Damit müssen Sie entweder Ausrüstung im Übermaß anschaffen oder warten, bis Standards eine unterschiedliche Behandlung der Verkehrstypen ermöglichen.

Mindestens sollten Sie sicherstellen, dass interne Anwendungen wie Storage und SOA-Vernetzung beim Datenverkehr nicht mit Nutzer-Zugriffen vermischt werden. Dies dient zugleich der Sicherung Ihrer Assets im Rechenzentrum. Achten Sie außerdem darauf, dass Discovery-Protokolle wie Spanning Tree, die im Frontend-LAN zum Einsatz kommen, nicht auch das Rechenzentrum selbst erfassen. Ansonsten können sie dem Traffic-Management in die Quere kommen und die Erholung des Netzwerks nach Fehlern beeinträchtigen.

Sowohl Produkte als auch Standards für Netzwerke in Rechenzentren entwickeln sich im Zuge der Verbreitung von Technologien Virtualisierung und Cloud-Computing derzeit rasch weiter. Netzwerk-Planer sollten prüfen, welche Richtung ihre Technik-Anbieter beim Switching im Rechenzentrum einschlagen und bei kurzfristigen Änderungen am Netzwerk die zukünftigen Architekturen im Hinterkopf behalten.

Über den Autor: Tom Nolle ist Präsident der CIMI Corporation, einer strategischen Beratungsfirma mit Spezialisierung auf Telekommunikation und Daten-Kommunikation seit 1982. Er ist Herausgeber von Netwatcher, einem Online-Journal über moderne Telecom-Strategien. Lesen Sie auch seinen Netzwerk-Blog Uncommon Wisdom bei SearchTelecom.com.

Artikel wurde zuletzt im April 2010 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Ethernet im Data Center

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close