Port-Trunking via LACP für Windows-Server 2008 R2

Dieser Artikel erschien zuerst auf Bents Blog.

Für eine Kundeninstallation bin ich kürzlich mit dem Thema Link-Aggregation (auch als LAG oder Port Trunking bezeichnet) in Berührung gekommen und habe ca. zwei Tage mit Aufbau, Tests und auch diverser Fehlersuche und Recherche im Netz verbracht. Die hierbei gewonnenen Erfahrungen und Schlussforderungen möchte ich nun an dieser Stelle zusammenfassen. Der Einfachheit halber werde ich folgend einfach immer einheitlich von einem Trunk sprechen, auch wenn dieser Begriff gemeinhin als veraltet gilt.

Das Ziel bestand darin, einen funktionierenden Trunk zwischen zwei Servern herzustellen und dessen Funktion durch mittels eines entsprechenden Datendurchsatzes zu messen. Da die Server später räumlich getrennt voneinander stehen, sollte die Verbindung über einen Switch zustande kommen.

Zunächst sollte man sich vor Augen halten, dass ein Trunk keinesfalls den maximalen Datendurchsatz einer Verbindung erhöht. D.h. über zwei bzw. vier Gigabit-Verbindungen lässt sich kein Datenstrom mit zwei bzw. vier Gigabit Durchsatz ermöglichen. Über die höhere Anzahl mehrerer logischer Verbindungen lässt sich einzig die gesamte aggregierte Bandbreite besser ausnutzen.

Ein Einstieg zur Thematik befindet sich hier: Link Aggregation und LACP Grundlagen.

Voraussetzungen

Da die zur Verfügung stehende Hardware, in diesem Fall Switches der D-Link DGS-1210-xx Serie sowie die HP Netzwerkkarten HP-NC326i und HP-NC373i, alle das LACP Protokoll unterstützen, sollte dieses zur Anwendung kommen. Wichtig ist, dass alle an der Kommunikation beteiligten Komponenten dieses Protokoll unterstützen.

Bei der Konfiguration des Switches sollte man beachten, dass zunächst das Spanning-Tree-Protokoll (STP) auf allen an LCAP-Trunks beteiligtenden Switchport deaktiviert ist. Das verhindert, dass ggf. Ports aufgrund der automatischen Erkennung von redundanten Pfaden deaktiviert werden. Auf anderen Ports sollte STP aber aktiviert bleiben, um Netzwerkschleifen zu verhindern.

Einrichtung

Es bietet sich an, mit der Konfiguration der Switchports zu beginnen und bisher unbenutzte Ports zu verwenden. Im Fall von D-Link Switches findet man die benötigten Einstellungen unter dem Punkt Link Aggregation. Hier sollte darauf geachtet werden, den Aggregationstyp auf LACP zu stellen. Sofern die Möglichkeit besteht, empfiehlt es sich auch, den LACP-Timer für die Trunk-Ports auf ein kurzes Intervall einzustellen (bei D-Link: Short / 3 sec), damit Verbindungsabbrüche entsprechend schnell erkannt werden und der Failover auf verbleibende Netzwerkverbindungen nach kürzester Zeit erfolgen kann.

Bei der Einrichtung der Netzwerkkarten unter Windows gibt es aber ein paar mehr Fallstricke. Zunächst muss der Treiber die entsprechenden Trunking-Funktionen mitbringen – die Konfiguration erfolgt meist über ein separates Tool. Bei Intel heißt das Werkzeug dafür Intel PROSet, bei Hewlett Packard Network configuration Utility (NCU). Bei Intel-Netzwerkadaptern habe ich zudem schon erlebt, dass das Konfigurationstool nur in den Eigenschaften der Netzwerkkarte auftaucht, wenn man sich auf einer Konsolensitzung befindet. Da bei diesem Vorgang ein neuer, logischer Adapter erstellt wird, der zunächst keine Konfiguration erhält, ist ein direkter physischer Zugang zum Server (oder auch eine Sitzung per IPMI oder ILO) empfehlenswert.

Da bei der Erstellung eines Trunks die Konfiguration der zugrundeliegenden, physikalischen Netzwerkadapter nicht gelöscht wird, kann man in eine “Falle tappen”, wenn man für den neu erstellten, logischen Adapter dieselbe IP-Konfiguration verwenden möchte. Man erhält dann bei der Konfiguration schlicht den Hinweis, dass die eingestellte Adresse bereits vorhanden ist. Nach der Erstellung des Trunks hat man leider keinen Einfluss mehr auf die IP-Konfiguration der physikalischen Adapter so dass man in diesem Fall die nicht mehr benötigten Einstellungen direkt in der Registry entfernen muss:

HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces

Hier gibt es für jeden Netzwerkadapter einen Unterzweig mit den entsprechenden Einstellungen. Mithilfe der IP-Adresse hat man den entsprechenden Adapter schnell identifiziert und kann die Einstellungen

• IPAdress
• SubnetMask
• DefaultGateway

bereinigen.

Will man das Problem komplett umgehen, kann man auch die Einstellungen des physikalischen Adapters vor der Bildung des Trunks auf DHCP zurücksetzen (und ggf. vorher die Netzwerkverbindung trennen).

Ähnliches gilt bei der Auflösung eines Trunks. Man kann hier die gewünschte, spätere IP-Konfiguration der physischen Netzwerkadapter durchaus vorkonfigurieren, damit das System nach der Auflösung des Trunks direkt erreichbar ist. In meinen Tests wurde der logische Netzwerkadapter für den Trunk immer komplett aus der Registry entfernt.

Für einen Trunk gibt es noch einige, oft herstellerspezifische Optionen. Wichtig ist, dass auch dier LACP-Modus ausgewählt wird. Bei HP-Netzwerkkarten heißt die Option 802.3ad Dynamic with Fault Tolerance. Die zur Verfügug stehenden Optionen werden in folgenden Artikel ausführlicher beschrieben (mit zahlreichen Referenzen zu den entsprechenden Dokumentationen der Hersteller). Leider lässt sich die IP-Konfiguration des logischen Netzwerkadapters nicht vor dessen Aktivierung definieren, so dass dieser immer mit Standardeinstellungen (i.d.R. DHCP) aktiv wird. Ansosnten lässt sich der logische Netzwerkadapter wie jede andere Netzwerkkarte konfigurieren und verwenden.

Analyse und Messung

Um den Datendurchsatz zu messen, habe ich mich des Tools iperf (bzw. jperf) bedient. Bei iperf handelt es sich um ein Kommandozeilentool für Datendurchsatzmessungen per TCP oder UDP, jperf ist ein Java-basierter, grafischer Aufsatz dafür. Beides kann im Paket hier bezogen werden: http://code.google.com/p/xjperf/.

Für den Test muss mindestens ein System immer als Datenquelle und eines als Datensenke fungieren. Da in der grafischen Oberfläche die verwendeten Kommendozeilenoptionen für iperf ausgegeben werden, kann man diesen einfach auf die benötigten Systeme kopieren und anpassen. Damit vermeidet man gleichzeitig unnötige Java-Installationen.

Ich habe bei meinen Tests jeweils mit

• 16 Einzelverbindungen je Client zu Server Verbindung gearbeitet und jeweils
• vier Quellserver auf
• ein Ziel

oder vice versa Daten verschicken lassen.

Ergebnisse

Wie sich bei meinen Tests sehr schnell herausstellte, findet eine Verteilung der Datenpakete stets nur in Senderichtung des Servers aus statt. Anfragen werden stets nur über einen dedizierten Port beantwortet. D.h. für den Beispielfall eines Backup-Servers, der Daten von verschiedenen Agents erhält, bringt das Szenario keinerlei Vorteile, ebenso wie für einen Dateiserver mit einem hohen Anteil an Schreibanforderungen. Für einen klassischen Dateiserver im KMU-Umfeld, der hauptsächlich als zentrale Datenablage für Dokumente, Zeichnungen und Nutzerprofile dient, kann das Trunking hingegen eine Entlastung bedeuten. Hier gilt es separat zu untersuchen, ob das Netzwerk wirklich der begrenzende Faktor ist und nicht etwa das zugrundeliegende Speichersystem, da viele verteilte Anfragen mehrerer Clients als zufällige E/A Anfragen auf dem Plattenspeicher landen, was bei Systemen mit wenigen Spindeln (was gerade im KMU Umfeld nicht unüblich ist) schnell zu Engpässen führt.

Testergebnisse mit 2-fach Port-Trunk

Eine letzte, festgestellte Eigenart möchte ich aber auch nicht vorenthalten: Mir ist es nur gelungen, über einen Gigabit an Daten über eine Switchverbindung zu transferieren, wenn die Verbindung physisch mindestens doppelt soviele Schnittstellen beinhaltet wie die Clients, d.h. in meinem Fall 4 Ports pro Switch. Ich vermute hier eine Eigenart der eingesetzten Hardware (D-Link DGS-1210-Serie), welche auch nur wenig Konfigurationsoptionen bezüglich der Verbindung erlaubt. Um genau zu sein, kann zwischen statischen und LACP-Trunking unterschieden werden sowie der Signalisierungszeitraum entweder auf 60 oder 3 Sekunden, sowie die einzelnen Ports bei der Verwendung von LACP zwischen aktiv und passiv umgeschaltet werden. Mir ist es nicht gelungen, für das Verhalten eine passende Erklärung zu finden. Abschließend habe ich nochmal mit einem Port-Trunk über vier physikalische Netzwerkadapter getestet, wobei sich bei diesem Test jeweils zwei Zielserver auf demselben Switch wie der Fileserver, sowie zwei weitere auf einem anderen Switch (angebunden über einen LACP-Trunk mit 2 Mitgliedern) befanden:

Testergebnisse mit 4-fach Port-Trunk

Erkennbar ist, dass die Skalierung bei vier Ports in meinem Szenario schon deutlich schlechter wird. Ich führe dass hauptsächlich auf die eben beschriebene Eigenart der Switchverbindung sowie zurück. Die D-Link Switche setzen LACP grundsätzlich auf der Basis von MAC-Adressen (Layer2) ein. Andere Geräte erlauben zusätzlich LACP Links auf der Basis von IP-Adressen (Layer3) oder TCP-Ports (Layer4) zu verteilen, was aber auch kontrovers diskutiert wird.

Fazit

Als Fazit aus diesen kurzen Tests möchte ich festhalten, dass Port-Trunking nur einen sehr eingeschränkten Nutzwert hat. In den meisten Fällen dürfte dieser in keinen Verhältnis zum erhöhten Implementierungsaufwand stehen, vor allem wenn die Einführung in eine bereits bestehende Umgebung erfolgt. In reinen Speichernetzen mit blockbasierten Speichergeräten erfolgt die Lastverteilung über mehrere physikalische Verbindungen im Regelfall über Multipath-Treiber, welche wesentlich weniger Einschränkungen besitzen.