In diesem Whitepaper finden Sie häufig gestellte Fragen und Antworten zum Netzwerklastenausgleich, dem so genannten Network Load Balancing (NLB). Im Mittelpunkt des NLB steht die Einrichtung von Server-Clustern. Ein Cluster ist eine Gruppe unabhängiger Computer, die jeweils die gleichen Anwendungen ausführen und beim Zugriff durch einen Client als ein einziges System dargestellt werden. Die Computer sind physikalisch durch Kabel und programmatisch durch Clustersoftware miteinander verbunden. Durch das Vorhandensein dieser Verbindungen können im Cluster Probleme für den Client transparent behoben werden, z. B. durch die Umverteilung von Aufgaben bei Ausfall eines Knotens auf einen anderen (Failover in Server-Clustern) oder eine Verteilung aller zu bearbeitenden Aufgaben über einen Lastenausgleich in Netzwerklastenausgleich (Network Load Balancing, NLB)-Clustern.
| Grundlagen | |
| NLB und andere Cluster-Technologien | |
| NLB und Skalierbarkeit | |
| NLB für Hochverfügbarkeit | |
| NLB-Grundlagen | |
| Spezielle Fragen zur Bereitstellung | |
| Unterstützung von Sitzungen |
Ein Cluster ist eine Gruppe unabhängiger Computer, die jeweils die gleichen Anwendungen ausführen und beim Zugriff durch einen Client als ein einziges System dargestellt werden. Die Computer sind physikalisch durch Kabel und programmatisch durch Clustersoftware miteinander verbunden. Durch das Vorhandensein dieser Verbindungen können im Cluster Probleme für den Client transparent behoben werden, z. B. durch die Umverteilung von Aufgaben bei Ausfall eines Knotens auf einen anderen (Failover in Server-Clustern) oder eine Verteilung aller zu bearbeitenden Aufgaben über einen Lastenausgleich in Netzwerklastenausgleich (Network Load Balancing, NLB)-Clustern.
Netzwerklastenausgleich (NLB) ist eine Clustertechnologie, die von Microsoft® als Teil von Windows® 2000 Advanced und Datacenter Server angeboten wird. NLB steht auch unter Windows Server 2003 in der Enterprise- und der Datacenter-Edition zur Verfügung. NLB benutzt einen verteilen Algorithmus für den Lastenausgleich von IP-Datenverkehr über mehrere Hosts. Das führt zu einer besseren Skalierbarkeit und Verfügbarkeit unternehmenskritischer, IP-basierter Dienste. Beispiele sind Webdienste, Virtual Privat Netzwerk (Virtual Private Network, VPN)-Dienste, Streaming-Media, Terminaldienste, Proxy-Dienste und viele andere mehr. NLB kann Ausfälle von Hosts automatisch erkennen und den Datenverkehr an andere Hosts umleiten, dadurch wird eine Hochverfügbarkeit des NLB-Clusters erreicht.
W2K: Nein, Server-Cluster und NLB laufen derzeit nicht auf dem gleichen System.
Windows Server 2003: Nein, Server-Cluster und NLB laufen derzeit nicht auf dem gleichen System.
Die Größe des Clusters hängt von den Anwendungen ab, die auf dem System gehostet werden und für die ein Lastenausgleich durchgeführt werden soll. Daneben sind die auf der Hostmaschine zur Bearbeitung der Client-Anfragen verfügbaren Systemressourcen ausschlaggebend. Wenn Sie feststellen, dass die Client-Anforderungen immer langsamer beantwortet werden, je mehr Clients sich verbinden und Anfragen an die Anwendungen senden, wird es Zeit, dem Cluster weitere Hosts hinzuzufügen. Ein einzelner Cluster kann bis zu 32 Hosts besitzen.
Tests haben gezeigt, dass die NLB-Leistung zunehmend nicht mehr linear skaliert, wenn ein Cluster über 20 bis 25 Knoten hinauswächst. Allerdings hängt das vom tatsächlichen Umfang des Datenverkehrs ab, der in Form von Clientanfragen an die Anwendungen fließt. Die folgende Grafik gibt einen Eindruck von der NLB-Leistung bei wachsender Clustergröße und steigender Benutzeranzahl.

Abbildung 1: Gleichzeitige Benutzer vs. Anzahl der Anwendungsserver

Abbildung 2: Abweichung von der idealen Linie bei zunehmenden Clientanfragen

Abbildung 3: Zusätzliche Belastung (Overhead) durch NLB für die Filterung abhängig vom Datendurchsatz (Web Load: Anfragen für 10 KB statische Webseiten)
Die obigen Diagramme beschreiben die Last bei der Abfrage von statischen Webseiten, die jeweils 10 KB groß sind.
Kann man NLB auf einem Front-End-Cluster mit mehr als 32 Knoten einsetzen, obwohl die Clustergröße auf 32 Knoten beschränkt bleiben sollte?
NLB kann auch einer Systemgröße von über 32 Maschinen angepasst werden. Hierzu wird über ein Round-Robin-DNS-Verfahren der Namensauflösung eine vorgeschaltete quasi-zufällige Verteilung zwischen mehreren NLB-Clustern erreicht, wie es in Abbildung 4 gezeigt wird.

Abbildung 4: Einsatz mehrerer Cluster
Jeder Host des NLB-Clusters sendet während der Bearbeitung von Client-Anfragen so genannte "Herzschläge" an die anderen Hosts des Clusters. Wenn ein Host ausfällt und keine Herzschläge mehr sendet, werden nach 5 Sekunden die verbleibenden Hosts innerhalb des Clusters einer so genannten Konvergenz unterzogen. Die Konvergenz entfernt den ausgefallenen Host aus dem Cluster und leitet die Clientverbindungen auf die verbleibenden Hosts innerhalb des Clusters um, die dann die Clientanfragen bedienen.
Fünf Sekunden.
Nein, die Pakete für die Herzschläge, die im Sekundentakt von jedem Host ausgesandt werden, benötigen weniger als 1.500 Bytes. Das ist weniger als ein Ethernet-Frame.
Nein. Die Herzschläge werden auf der gleichen Netzwerkschnittstelle versendet, auf der auch die Datenpakete empfangen und versendet werden. Es besteht keine Notwendigkeit für ein zusätzliches Back-End-Netzwerk für die Kontrollpakete (Herzschläge).
Ja. NLB verfügt mit wlbs.sys über eine Kernel-Komponente. Technisch gesehen handelt es sich um einen zwischengeschalteten NDIS-Treiber.
| • | Es gibt keinen "Single-Point of Failure" und automatische Kompensation von Rechnerausfällen. Es ist kein manueller Eingriff erforderlich. |
| • | Es gibt keinen zentralen Knotenpunkt, der zu Leistungsengpässen führen könnte. |
Alle Verbindungen, die aus dem AOL-Netzwerk stammen werden durch einen clientseitigen Proxy geleitet. Es gibt jedoch keine Garantie, dass zwei aufeinander folgende TCP-Verbindungen desselben Clients durch den gleichen Proxy gesendet werden. Nehmen wir z.B. an, dass ein Client aus dem AOL-Netzwerk heraus eine SSL-Sitzung mit einem NLB-Cluster im Internet eröffnet. Um sicherzustellen, dass die Sitzung nicht unterbrochen wird, müssen alle TCP-Verbindungen, die von diesem Client stammen und Teil dieser Sitzung sind, an den gleichen Host innerhalb des Clusters gesendet werden. Dafür muss der NLB-Cluster im Einfachen Affinitäts-Modus konfiguriert sein.
Nun ist es aber möglich, dass unterschiedliche TCP-Verbindungen eines Clients aus dem AOL-Netzwerk über verschiedene clientseitige Proxies an den NLB-Cluster gesendet werden. Der NLB-Cluster betrachtet diese TCP-Verbindungen als Verbindungen unterschiedlicher Clients (da sie nicht die gleiche Quell-IP-Adresse haben), obwohl sie vom gleichen Host stammen. Da NLB den Lastenausgleich auf Basis der Ursprungs-IP-Adresse der Verbindung durchführt, kann es dazu kommen, dass die Verbindungen von unterschiedlichen Hosts bearbeitet werden, obwohl sie Teil der gleichen Sitzung sind. Das führt zum Abbruch der Sitzung.
Wenn Verbindungen von verschiedenen Clients durch den gleichen clientseitigen Proxy geleitet werden, erreichen sie den NLB-Cluster mit der gleichen Ursprungs-IP-Adresse. Daher nimmt der NLB-Cluster an, dass diese Verbindungen von einer einzigen Maschine kommen. Ist der Cluster im Einfachen Affinitäts-Modus, prüft NLB nur die Ursprungs-IP-Adresse der eingehenden Pakete, um einen Lastenausgleich durchzuführen. Da aber alle diese Verbindungen von einem Client zu stammen scheinen, werden sie alle an den gleichen Host innerhalb des Clusters weitergeleitet. Im No Affinity-Modus des Clusters, der keine feste Clientzuordnung durchführt, wertet NLB sowohl die Quell-IP-Adresse als auch den Quell-Port aus. Der Lastenausgleich erfolgt damit über alle Hosts.
Standardmäßig setzt NLB den Unicast-Modus ein. Dabei verändert NLB die MAC-Adresse des Netzwerkadapters, für den NLB aktiviert ist. Alle Rechner im Cluster erhalten damit die gleiche MAC-Adresse. Ankommende Pakete werden so von allen Hosts des Clusters empfangen und an den NLB-Treiber zur Filterung weitergeleitet.
Im Multicast-Modus weist NLB jedem Adapter innerhalb des Clusters eine Layer-2-Multicast-Adresse zu und lässt die MAC-Adresse des Clients unverändert.
Beide Betriebsarten haben ihre Vor- und Nachteile. Der Vorteil des Unicast-Modus ist, dass er nahtlos mit allen Routern und Switches zusammenarbeitet. Der Nachteil ist, dass keine Kommunikation zwischen den Hosts, die im Unicast-Modus konfiguriert sind, möglich ist, da alle Hosts innerhalb des Clusters die gleiche IP- und MAC-Adresse haben. Der Multicast-Modus kennt diesen Nachteil nicht, da er eine Layer-2-Multicast-Adresse zuweist, die den Austausch zwischen den Hosts ermöglicht, da die Hosts ihre originale, eindeutige MAC-Adresse behalten und bereits eine eindeutige dedizierte IP-Adresse besitzen. Allerdings ordnet die ARP-Antwort, die von einem Host des Clusters als Antwort auf eine ARP-Anfrage ausgesendet wird, die Unicast-IP-Adresse des Clusters der Multicast-MAC-Adresse des Hosts zu. Diese Zuordnung innerhalb einer ARP-Antwort wird von Cisco-Routern zurückgewiesen. Daher müssen Administratoren einen statischen ARP-Eintrag innerhalb der Cisco-Router vornehmen, der die Cluster-IP-Adresse der gemeinsamen Cluster-MAC-Adresse zuordnet.
Windows Server 2003 bietet als neue Funktion eine Unterstützung von IGMP. Damit wird die Switchüberflutung auf die Ports begrenzt, mit denen tatsächlich NLB-Maschinen verbunden sind. So wird der Verkehr, der nur für den NLB-Cluster bestimmt ist, nicht an Maschinen geleitet, die nicht Teil des NLB-Clusters sind; alle Maschinen des Clusters erhalten weiterhin den gesamten Verkehr, der für den Cluster bestimmt ist. Damit kann der NLB-Algorithmus verwendet werden. IGMP-Unterstützung kann nur aktiviert werden, wenn NLB im Multicast-Modus konfiguriert ist.
Der Multicast-Modus hat allerdings seine eigenen Nachteile, die sehr ausführlich in der Knowledge-Base unter http://support.microsoft.com diskutiert werden. Der Benutzer sollte sich der Nachteile bewusst sein, bevor er die IGMP-Unterstützung einsetzt.
Die Switch-Überflutung lässt sich auch mit dem Unicast-Modus einschränken, indem VLANs im Switch angelegt werden und der NLB-Cluster in sein eigenes VLAN gesetzt wird. Der Unicast-Modus hat nicht die Nachteile des Multicast-Modus, daher sollte man ihn zur Einschränkung der Switch-Überflutung vorziehen.
NLB benötigt nur eine Netzwerkkarte pro Host. Allerdings gibt es einige Umstände, unter denen Benutzer besser weitere Netzwerkkarten einsetzen sollten:
| • | Datenaustausch zwischen Hosts im Unicast-Modus.: Im Unicast-Modus hat jeder Host die gleiche IP-Adresse und die gleiche MAC-Adresse. So können sie innerhalb des Netzwerks als vollständig identisch dargestellt werden. Allerdings hat der Unicast-Modus damit den Nebeneffekt, dass eine Kommunikation zwischen den Hosts nicht möglich ist. |
| • | Trennen von eintreffendem und ausgehendem Datenverkehr: Durch den Einsatz von mehreren Netzwerkkarten können Sie auf jeder Maschine für NLB eine Netzwerkkarte für die Bearbeitung des eingehenden Verkehrs konfigurieren und der zweiten Netzwerkkarte eine dedizierte IP-Adresse zuweisen, so dass der ausgehende Datenverkehr immer über die dedizierte Netzwerkkarte gesendet wird. |
| • | Trennen des Front-End- vom Back-End-Datenverkehr: Die Netzwerkkarte, die an NLB gebunden wird, kann dazu benutzt werden, ankommende Verbindungen zu bearbeiten. Die Verbindungen zu Back-End-Datenbanken, könnten zum Beispiel von einer separaten Back-End-Netzwerkkarte hergestellt werden. |
Nein. Der gesamte Cluster muss sich in einem einheitlichen Operationsmodus befinden.
Ja. NLB unterstützt mehrere, virtuelle IP-Adressen. Weitere Informationen finden Sie im Knowledge Base-Artikel Q232000 - How to Configure WLBS with Multiple Virtual IP Addresses.
W2K: Nein, Portregeln betreffen alle hinzugefügten VIPs. Zusätzlich müssen alle Hosts die gleichen VIPs besitzen. Weitere Informationen finden Sie in dem Knowledge Base-Artikel Q232000 - How to Configure WLBS with Multiple Virtual IP Addresses.
Windows Server 2003: Virtuelle Cluster vermeiden die oben genannten Einschränkungen durch die Verwendung von IP-Portregeln. Nun ist es möglich, verschiedene Portregeln für unterschiedliche VIPs auf der gleichen Maschine anzulegen.
Ja. Es funktioniert zwar, wird aber nicht empfohlen.
Ja. Der parallele Betrieb von Windows NT® 4.0 WLBS, Windows 2000 NLB und Windows Server 2003 wird ohne weitere Netzwerkvoraussetzungen unterstützt. Die "Herzschlag"-Pakete von NLB unter Windows sind abwärtskompatibel mit WLBS unter NT 4.0 und Windows 2000 NLB.
Hinweis: Im gemischten Modus können neue Funktionen von Windows Server 2003-NLB - wie virtuelle Cluster, IGMP-Untestützung oder Bidirektionale Affinität - nicht verwendet werden.
W2K: Nein. Unter Windows 2000 ist dies nicht möglich.
Windows Server 2003: Ja. Sie können NLB an verschiedene Netzwerkkarten binden.
Nein, WINS sollte nicht eingesetzt werden, wenn NLB verwendet wird. Das Problem bei der Registrierung mit dem WINS-Server besteht darin, dass die VIP zwischen allen Hosts gemeinsam genutzt wird, die DIP dagegen nicht. Bei einem Zugriff über die DIP, wird die IP-Adresse möglicherweise auf die VIP aufgelöst.
Nein. Die dynamische Registrierung von Namen sollte nicht in Verbindung mit NLB eingesetzt werden. Alle IP-Adressen werden über den DNS-Server registriert. Beim Zugriff wäre eine Namensauflösung nach DIP oder VIP möglich und daher nicht eindeutig.
Ja. Unter Windows Server 2003 unterstützt NLB sowohl PPTP- als auch L2TP-VPN-Sitzungen. NLB-Unterstützung für das PPTP- und das L2TP-Protokoll erfordern aber, dass NLB im Einfachen Affinitäts-Modus konfiguriert wird.
Ein neues Werkzeug in Windows Server 2003, der sog. NLB-Manager, erlaubt die Konfiguration und Verwaltung von NLB-Clustern von einem zentralen Punkt aus. Einige Schlüsselfunktionen des NLB-Managers sind:
| • | Erstellen neuer NLB-Cluster und automatische Übermittlung von Clusterparametern und Portregeln auf alle Hosts im Cluster. Außerdem können Hostparameter an bestimmte Hosts in einem Cluster übermittelt werden. |
| • | Hinzufügen und Entfernen von Hosts in NLB-Clustern. |
| • | Automatisches Hinzufügen der Cluster-IP-Adresse zur TCP/IP-Konfiguration. |
| • | Verwalten vorhandener Cluster durch Herstellung einer Verbindung zum Cluster oder Laden der Hostinformationen des Clusters in eine Datei und Speichern dieser Informationen zur späteren Verwendung. |
| • | Konfiguration von NLB für einen Lastenausgleich mehrerer Websites oder Anwendungen in einem NLB-Cluster. Dies umfasst das Hinzufügen aller Cluster-IP-Adressen zur TCP/IP-Konfiguration und die Steuerung des an bestimmte Anwendungen auf bestimmten Hosts im Cluster gesendeten Verkehrs. |
| • | Diagnose falsch konfigurierter Cluster. |
Der NLB Remote-Steuerungsmechanismus ist standardmäßig deaktiviert. NLB (und damit auch WLBS.EXE) benutzt die UDP-Control-Ports 1717 und 2504, um NLB-Cluster remote zu verwalten. Unter Windows Server 2003 wird dringend empfohlen, den NLB-Manager für die Verwaltung und Konfiguration von NLB einzusetzen.
Bevor Sie die Remote-Steuerung für NLB-Cluster aktivieren, sollten Sie den Artikel "NLB Security Best Practices" auf www.microsoft.com lesen.
Im Einfachen Affinitäts-Modus führt NLB einen Lastenausgleich auf Basis der Quell-IP-Adresse der eintreffenden Verbindungen durch. Dies stellt sicher, dass alle eingehenden Verbindungen desselben Clients (IP-Adresse) an den gleichen Host innerhalb des Clusters gesendet werden. Dies gilt, bis entweder ein Host dem Cluster hinzugefügt wird oder der Host, mit dem die Clientverbindung bestanden hat, aus dem Cluster genommen wird. In diesen Fall wird die IP-Adresse des Clients an einen anderen Host gebunden.
Im Modus ohne Affinität führt NLB den Lastenausgleich des Datenverkehrs auf Basis von Quell-IP-Adresse und Quell-Port des eintreffenden Datenverkehrs durch. So können in diesem Modus mehrfache Verbindungen, die über den gleichen Client eintreffen von unterschiedlichen Hosts entgegengenommen werden, solange diese Verbindungen unterschiedliche Ports benutzen.
Welcher Mode letztendlich eingesetzt wird, hängt von den Anwendungen ab, die über den Lastenausgleich verteilt werden. Wenn eine Anwendung Sitzungen über mehrere TCP-Verbindungen hinweg nutzt, sollte NLB im Einfachen Affinitäts-Modus konfiguriert sein. Hier kann sichergestellt werden, dass alle TCP-Verbindungen, die zu einer Sitzung gehören, dem gleichen Host innerhalb des Clusters zugeordnet werden.
Anwendungen, die keine Sitzungen nutzen und für die es hinnehmbar ist, dass unterschiedliche Verbindungen eines Clients von mehreren unterschiedlichen Hosts innerhalb des Clusters bedient werden, sollten dagegen im Modus ohne Affinität ausgeführt werden.
Ja. Stellen Sie sicher, dass NLB im Einfachen Affinitäts-Modus ausgeführt wird. Allerdings sollten Sie einige wenige Punkte beachten:
| • | Der Lastenausgleich ist nicht so fein steuerbar wie im Modus ohne Affinität. |
| • | Sitzungen werden unterbrochen, wenn Hosts im Cluster entfernt oder hinzugefügt werden. |
Wenn alle Sitzungen durch einen clientseitigen Proxy weitergeleitet werden, funktioniert der Lastenausgleich nicht, da alle TCP-Verbindungen die gleiche IP-Adresse aufweisen und damit durch die gleiche Maschine innerhalb des Clusters bearbeitet werden.