Network Load Balancing (NLB) - Konfigurationshinweise

Neben der NLB-Adresse braucht jeder Knoten auch noch eine IP-Adresse für die Verwaltung und die Kommunikation mit dem Backend. Alle NLB-Server und Dienste müssen die gleiche Information tragen. denn ein Client verbindet sich mit EINEM Server. Also müssen die Daten entweder repliziert werden oder von einem anderen gemeinsamen Server (z.B. Exchange oder SQL Cluster) bezogen werden. Insofern eignet sich NLB idealer weise für Web und FTP-Server, aber auch als Fehlertoleranz für Druckserver, Exchange Frontend Server und alle anderen Dienste deren Daten repliziert oder redundant abgelegt werden können.

Sie müssen die Team Adresse auf allen Systemen als weitere IP-Adresse in den Eigenschaften des TCP/IP-Protokolls hinzufügen. Der NLB-Treiber sorgt dann dafür, dass die Adresse nicht erreichbar ist und es keine "Konflikt"-Meldungen gibt.

Bei Windows 2008 ist NLB ein "Feature"

nlb.wmv (20 MB, 24min)

NLB mit Single LAN

Die reine Lehre ist natürlich, wenn man ein Subnetz für die Kommunikation mit dem Client vorsieht und die Kommunikation mit dem Backend (Also einem Exchange, File oder SQL-Server o.ä. ) über ein zweites unabhängiges Netzwerk erfolgt. So ist klar getrennt, dass die Kommunikation zwischen den NLB-Nodes und dem Backend eben nicht über die IP-Adresse des NLB-Clusters erfolgt. (Das ist besonders beim Einsatz von uNICAST nützlich)

Aber auch mit einem Subnetz "kann" man doch etwas helfen, wenn man den Server nämlich über zwei Netzwerkkarten an das gleichen LAN verbindet. Das ist ein unterschied von der Option, auf einer Netzwerkkarte einfach zwei IP-Adressen zu binden.

NLB Single LAN

Die Karte mit der blauen IP-Adresse (11 und 12) ist die primäre Karte, auf die auch der Microsoft Client, WINS, DNS und das Default Gateway konfiguriert ist. Hierüber erfolgt eigentlich die komplette interne Kommunikation zwischen den Servern und natürlich auch zu Domain Controllern etc.

Die zweite Karte steht in der Reihenfolge an zweiter Stelle und hat nur TCP/IP-und eben NLB gebunden.  Zwar gehen die Verkehrsströme damit über das gleiche LAN aber doch über getrennte Karten. Man kann sehr viel einfacher mit NETMON die Daten untersuchen und wenn der Switch kein "Multicast" kann, dann ist es nur ein kleiner Schritt zu einem VLAN.

Adapter Teaming

Wenn Sie NLB mit Teaming kombinieren, dann funktioniert dies meist nur mit MULTICAST !

Um die Verwirrung noch etwas aufzulösen: Die Möglichkeit, dass eine MAC-Adresse bei einem Switch auf verschiedenen Ports anliegt, ist auch eine der Grundfunktionen des Adapter Teaming. Hierbei werden mehrere Netzwerkkarten im gleichen Server als Bündel betrieben und auf den gleichen oder auch unterschiedliche Switches verbunden. Das Ziel ist hierbei eine höhere Ausfallsicherheit und/oder eine höhere Bandbreite. Die verschiedenen Optionen haben Namen wie:

  • FEC
    Fast Ethernet Channel bündelt  mehrere Ethernet Karten zu einem Trunk
  • GEC
    Gigabit Ethernet Channel bündelt ähnlich zur FEC Gigabit Links
  • Network Trunk
    Bezeichnung für eine manuelle Konfiguration am  Switch mehrere Leitungen zu einem Bündel
  • Adaptive Load Balancing
    Besondere Form für die Bündelung von ausgehenden Daten zur Verteilung über mehrere Karten
  • IEEE802.3ad
    Standard, damit Switch und Endgerät selbständig die Bündel definieren

Hierbei geht es aber darum, den gleichen PC mehrfach anzubinden. Meist werden durch das Bündel nur die Daten vom PC zum Switch über mehrere Wege übertragen. Der Switch kann dabei den gleichen PC über mehrere Wege erreichen und daher mehr Paket in der gleichen Zeit senden oder beim Ausfall eines Links die verbliebenen Links nutzen. Hierbei wird das entsprechende Paket aber über genau einen Link gesendet und nicht mehrfach über alle Links. Damit ist dies nicht mit NLB zu verwechseln, bei dem das gleiche Paket zu mehreren Servern übertragen werden muss. NLB kann aber mit Adapter Teaming kombiniert werden,  um die Bandbreite weiter zu erhöhen. Achten Sie aber darauf, dass die Treiber auch damit kompatibel sind.

  • 278431 using teaming adapters with network load balancing may cause network problems

NLB mit virtuellen Systemen (Hyper-V oder VMWare)

NLB mit VMWare
http://www.vmware.com/files/pdf/implmenting_ms_network_load_balancing.pdf
Achtung: Bei einem Kunden hat Windows 2008 R2 mit NLB einen VMWare ESX 3.5-Host zuverlässig gekillt. Nach dem Update auf vSphere 4 war das Problem dann erledigt.

Der Betrieb von Systemen mit NLB als Gast einer virtuellen Plattform bedarf je nach System und Version zusätzlicher Einstellungen. NLB verändert ja die MAC-Adresse beim Versand und Empfang, was aber von der Plattform nicht zwingend unterstützt werden muss. Schließlich nimmt dieses das Paket und sendet es über einen "virtuellen Switch" an die physikalische Netzwerkkarte zum physikalischen Switch. Damit ist hier auch ein Stör und Problempotential, wie beim physikalischen Switch ebenfalls.

Probleme können dabei schon mit einem einzigen Host mit NLB auftreten oder auch erst, wenn zwei Hosts der gleichen NLB-Farm auf dem gleichen Gast liegen. Hier sind also weitergehende Tests erforderlich. Meine Zwischenergebnisse:

Host Gast NLB Mode Bemerkungen und Ergebnisse

ESX 3.x

Win2008R2

Multicast

ESX-Host wurde instabil !!!
(kann ein Einzelfall gewesen sein, aber nach Update auf ESX4 war die gleiche Hardware dann i.O.

ESX4

Win2008R2
Win2008

Multicast

Scheint zu funktionieren

ESX4

Win2008

Unicast

Nicht selbst getestet aber laut VMWare möglich, wenn man den virtuellen Switch anpasst

Hyper-V

Win2008

Unicast

Hotfix erforderlich, Konfiguration erforderlich

  • 953828 Windows Server 2008 Hyper-V virtual machines generate a Stop error when NLB is configured or when the NLB cluster does not converge as expected
  • http://robwhitehouse.com/virtualisation/enable-nlb-in-a-hyper-v-guest/Hyper-V und VMWare
  • Die 02BF-Adresse des Clusters muss in der Hyper-V Konfiguration der Netzwerkkarte statische eingetragen werden

Hyper-V R2

Win2008

Unicast

Hotfix und Hyper-V Konfiguration erforderlich

  • 953828 Windows Server 2008 Hyper-V virtual machines generate a Stop error when NLB is configured or when the NLB cluster does not converge as expected
  • Das "Spoofing" der MAC-Adresse muss erlaubt sein

Hyper-V R2

Win2008R2

Multicast

Scheint zu funktionieren

*

*

IGMP

noch nicht getestet

Weitere Tests und Ergebnisse reiche ich gerne nach

Wenn Sie selbst schon NLB unter virtuellen Umgebungen nutzen, dann können Sie mir gerne ihre Erfahrungen, die Versionen und eventuell erforderliche Anpassungen zukommen lassen

NLB und Windows Versionen

Normalweise sind alle System eines NLB-Teams mit dem gleichen Betriebssystem installiert. Aber bei einem Update ist dies natürlich nicht immer zu gewährleisten. Ideal ist es, wenn Sie ein neues Team parallel aufbauen und testen können und erst dann die Last "umschalten". aber auch ein "Swing Update" ist möglich, wenn einige Dinge betrachtet werden, z.B.

"During an upgrade, an NLB cluster will simultaneously have Windows Server 2003 and Windows Server 2008 cluster nodes in the same cluster. This mixed mode setup is supported only when the upgrade installation is in progress and should not be used für an extended period of time in deployment. After the entire NLB cluster has been upgraded to Windows Server 2008, you can use new NLB features, such as IPv6 and support für multiple dedicated IP addresses. If you have both Windows Server 2003 and Windows Server 2008 cluster nodes, you cannot use the new NLB Windows Server 2008 features."
Quelle http://technet.microsoft.com/en-us/library/cc753944(WS.10).aspx

Siehe auch

Weitere Links