Network Load Balancing Troubleshooter

Unterstützung durch Net at Work:
NLB ist im Prinzip sehr einfach, aber oftmals liegt der Teufel im Detail. Da für die Planung, Installation und Fehlersuche unterschiedliche Kenntnisse erforderlich sind. Nutzen Sie doch einfach unsere Serviceleistung.

Bitte lesen Sie unbedingt vorher die Seite NLB-Grundlagen und NLB-Intern

Diese Seite zeigt ihnen ein wenigen Schritten, wie Sie mit wenigen Schritten den Fehler einer NLB-Installation eingrenzen können. Allerdings gibt es immer wieder Router und Switches bzw. Konstellationen, in denen die erforderlichen Konfigurationen nicht oder nur mit größeren Umstellung en (z.B. VLANs, eigene Subnetze) bereit gestellt werden können.

Gemein bei NLB ist, dass nach einem Setup die Funktion sogar gegeben erscheint aber man erst bei mehr Last bemerkt, dass etwas falsch ist. Das ist durchaus denkbar, wenn der erste Knoten alle Pakete bekommt und der zweite Knoten diese nicht sieht. Solange keine Last anliegt, wird der erste Knoten auch die Verbindungen bedienen. Erst wenn die Last zunimmt und der nächste Knoten (Es sind ja bis zu 32 Stück pro NLB-Cluster möglich) einspringen soll, dann merken Clients, dass es doch nicht geht. Sie sollten also einige "gute" Tests anwenden. Vier Tests bieten sich an, wobei die ersten zwei eigentlich nicht für NLB direkt tauglich sind aber die Switches einfach testen.

Basisfunktion mit ICMP (PING) testen

ICMP ist das Protokoll, welche von PING und TRACEROUTE genutzt wird und den PC zuerst zwingt, per ARP die MAC-Adresse zu einer bestimmten IP-Adressen zu bestimmen und dann ein Packet dorthin zu senden und die Antwort einzusammeln. NLB unterstützt nur die Protokolle UDP und TCP aber nicht ICMP. Das hat den netten Effekt, dass ein ICMP-Paket bei korrekter Funktion an die NLB-Adresse zugestellt wird. Da NLB aber keine Verbindung zu einem spezielle Host zuordnen kann, antworten eben beide Systeme. Nun ist ein Netzwerkmonitor (NetMon3, Packetyzer, etc.) gefragt, den wir auf beiden NLB-Knoten starten und optional auch auf dem Client starten und einen Filter auf die IP-Adresse des Clients setzen (z.B. ipv4.addres == 192.168.0.1) ein PING auf einem Unix-System meldet sogar wenn auf ein ICMP-Request mehrere Antworten kommen.

Mit dieser Logik können wir nun nacheinander die NLB-Funktion aus verschiedenen Startpositionen überprüfen.

Start

Wir gegen für die Überprüfungen von folgender Konfiguration aus:

Server 1 und Server 2 sind zwei Server im NLB-Team, die in einem IP-Subnetz (z.B. VLAN oder am gleichen Switch) hängen. In diesem Netz ist auch der "Client1" direkt angeschlossen. Das muss später nicht von Bestand sein, aber für den Test wichtig, um Fehler einzugrenzen. Ein "Ping" vom Router oder im Switch im gleichen Subnetz ist nicht zuverlässig für den Test.

Zudem müssen Sie auf allen vier Systeme den Microsoft Netzwerkmonitor installieren. (NetMon3), damit wir die Pakete auch nachweisen können. Konfigurieren Sie nun auf allen Systemen einen Capture Filter "IMCP", damit NetMon nur noch "PING"-Pakete mitschneidet.

Geben Sie dazu "ICMP" im Filterfester (ROT) ein, drücken dann auf den "APPLY"-Button (BLAU), damit der Filter auch angewendet wird (GRÜN) und starten Sie dann den Capture.

Test1: Ping im Subnetz

Zuerst starten wir mit einem Client im gleichen Subnetz, um Probleme mit dem Router und IP-Routingtabellen auszuschließen. Um das ICMP-Paket zuzustellen, muss der Client zuerst mit einer ARP-Anfrage die passende MAC-Adresse ermitteln. Erst dann sendet der Client einen ICMP-Request an die NLB-IP-Adresse und verwendet die MAC-Adresse, die im NLB-Team konfiguriert ist.

Starten Sie auf dem Client 1 einen PING1 auf die NLB-IP-Adresse.

Sehen Sie auf Server1 und Server2 die ICMP-Anfragen und Antworten ?
Sehen Sie auf dem Client die vier Anfragen und die acht Antworten
Sehen Sie auf dem Client mit "ARP -a" die

JA: dann ist die Funktion innerhalb des Subnetzes quasi schon bestätigt. Ihr Switch sollte wie erwartet funktionieren und sie können zum nächsten Test gehen

Nein: Beheben Sie das Problem anhand "Problem: Keine Funktion im Subnetz"

 Dieses Paket muss man auf beiden NLB-Knoten sehen. Erst dann kann man sicher sein, dass der Switch das NLB richtig unterstützt. Kommen die ICMP-Pakete nicht bei beiden Knoten an, brauchen Sie mit der aktuellen Konfiguration nicht weiter zu testen.

Funktioniert dies jedoch, dann antworten beide NLB-Knoten und auf dem Client sollten mindestens zwei ICMP-Antworten aufschlagen.

Test2: Ping von Client 2 über Router

Test 2 ist dann ein Client aus einem anderen Subnetz, so dass der Router das ICMP-Paket (PING) an die IP-Adresse auf die MAC-Adresse umsetzen muss. Oft scheitert es nämlich am Router, der mit Multicast-MAC nicht umgehen kann. Einige Cisco-Router z.B. benötigen erst einen statischen ARP-Eintrag, wenn Sie die Multicast-MAC-Adresse nicht lernen wollen.

Auch hier ist dann ein Netzwerkmonitor wieder zur Überprüfung hilfreich. Wer auf dem Router die ARP-Tabelle einsehen kann, kann auch hier sehen, ob der Router die erste Hürde genommen hat.

Test3: TCP Connect zum Webserver

Wenn ICMP dann den Weg bereitet hat, dann müssen Sie natürlich auch die TCP-Funktion von NLB prüfen. Das einfachste ist, wenn auf allen Knoten ein IIS installiert ist und sie auf jedem IIS die gleiche Datei mit unterschiedlichem Inhalt ablegen. Erzeugen Sie eine Datei "c:\inetpub\wwwroot\nlbtest.htm" mit folgenden Inhalt

<html>
<head>Server1</head>
<body>
  <h1>Server1</h1>
</body>
</html>

Natürlich sollte der "Servername" auf jedem NLB-Teammitglied den realen Servernamen wiederspiegeln. Dann benötigen Sie mehrere Clients und geben im Browser ein: "http://nlb.ip.addr.esse/nlbtest.htm". Allerdings muss man schon mehrere Clients nutzen, da NLB per Default Anfragen der gleichen IP-Adresse immer an den gleichen Host gibt. (Affinity). Das ist ja sinnvoll, da man so eine bestehende Anmeldung und Session auf einem Webserver wiederverwenden kann und mehrfache Anmeldungen spart.

Das Problem hierbei kann aber sein, dass man einfach nicht genug Anfragen generieren kann, um wirklich eine "Verteilung" zu schaffen. In so einem Fall helfen dann WGET und andere Tools, die einfach massenhaft HTTP-Anfragen absetzen oder die Berechnung der Fakultät mit dem Taschenrechner um den ersten Server etwas zu bremsen. Sie können auch die NLB-Gewichtung des ersten Hosts ändern, so dass er wenige Anfragen bedient und der zweite Server mehr zu tun bekommt.

Der ganze Test sollte natürlich dann auch noch ein Clients aus einem anderen Subnetz ausgeführt werden, um auch hier wieder den Router als mögliche Fehlerquelle auszuschließen.

Flussdiagramm

Ein erster Versuch eines Fehlersuchdiagramms

Weitere Links