NLB Cluster in der virtuellen Maschine

Hinweis: Bitte beachten Sie, dass dieser Artikel / diese Kategorie sich entweder auf ältere Software/Hardware Komponenten bezieht oder aus sonstigen Gründen nicht mehr gewartet wird. Diese Seite wird nicht mehr aktualisiert und ist rein zu Referenzzwecken noch hier im Archiv abrufbar.

von Carsten Schäfer

Windows & NLB (Network Load Balancing Cluster)-Konfiguration

Der Windows 2003 Server wurde mit zwei Netzwerkkarten versehen:

vLAN_Backend
vLAN_Management

vLAN_Backend

Über diese Netzwerkkarte läuft die NLB-Kommunikation, d.h. diese Netzwerkkarten werden in NLB eingebunden und im vLAN_Backend wird auch die virtuelle NLB-Adresse bereitgestellt. Die Netzwerkkonfiguration dieser Netzwerkkarte:

IP-Adresse manuell vergeben
Gateway definiert
keine Angabe von DNS-Servern

vLAN_Management

Diese Netzwerkkarte ist in die Standard-Windows-Kommunikation eingebunden und daher ist die IP-Adresse dieser Netzwerkkarte mit dem Host-Namen in DNS eingetragen.

Die Netzwerkkonfiguration dieser Netzwerkkarte:

IP-Adresse manuell vergeben
Gateway definiert
DNS-Server angegeben
Host-Name wird in DNS auf diese IP-Adresse registriert

Konfiguration NLB

Beim Hinzufügen eines Hosts zum NLB-Cluster wurde die Netzwerkkarte des vLAN_Backends verwendet.
Die virtuelle IP-Adresse des Hosts befindet sich im vLAN_Backend
Der cluster operation mode ist Unicast

NLB Hosts auf VI3

Jeder NLB Host befindet sich auf einem anderen ESX 3.0.1 Host. Für jede Netzwerkkarte des Windows Hosts existiert eine gleichnamige PortGroup in einem vSwitch welche mittels NIC Teaming auf einen Port eines physikalischen Switch konnektiert ist. Die Einstellungen des vSwitches sind Default-Einstellungen, im NIC Teaming wurden beide Netzwerkkarten als Active definiert.

Das Problem

Beim Stoppen oder Starten eines NLB-Hosts verlor der jeweils andere NLB-Host seine Netzwerkverbindung im vLAN_Backend. Somit war der komplette NLB-Cluster ausser Funktion gesetzt. Nach einigen Minuten war die Netzwerkverbindung wieder hergestellt. Das Problem tritt beim Starten sowie beim Stoppen eines beliebigen NLB-Knotens auf. Kein Problem jedoch stellte der NLB-Cluster bei der Verwendung des Mulitcast-Modus dar.

Hinweis in der VMware KB

Der Artikel 1556 beschreibt ein ähnliches Problem, jedoch für ESX2. Das Problem äusserte sich darin, dass sämtlicher Netzwerkverkehr nur über einen NLB-Host gesendet wurde. VMwares Lösung lt. diesem Artikel lautet:

Einstellung in den Advanced Options: Net.NotifySwitch auf 0 setzen

Diese Einstellung ist eine globale Einstellung, d.h. alle VMs sind davon betroffen. Gleichzeitig warnt VMware vor dieser Einstellung und empfiehlt den NLB-Cluster im multicast-Mode laufen zu lassen da oben genannte Einstellung die VMotion-Funktionalität beeinträchtigt. Diese Einstellung wurde in unserer Test-Umgebung versucht, brachte jedoch keine Besserung.

Hinweis in den VI3-Handbüchern

Ein Hinweis im ESX 3 Handbuch „Server Configuration Guide“ (vi3_server_config.pdf) auf Seite 59 zur Netzwerkkarten-Konfiguration Notify Switches: Do not use this option when the virtual machines using the port group are using Microsoft Network Load Balancing in unicast mode. No such issue exists with NLB running in multicast mode. Laut Server Config Guide, Page 59, beschreibt Notfiy Switches nur eine Einstellung im Kontext von NIC Teaming. Lt. VMware ist dies auch ein Bug in der Doku denn diese Einstellung hat auch generelle Auswirkungen auf das Verhalten des vSwitches hinsichtlich der angeschlossenen VMs. Siehe hierzu dazu den Abschnitt Technischer Hintergrund.

Doch was bewirkt Notify Swiches?

Diese Einstellung gibt an, ob Switche im Falle eines Failovers benachrichtigt werden sollen. Ist diese Einstellung auf yes, wird bei jedem Hinzufügen einer virtuellen Netzwerkkarte zum vSwitch sowie einer Änderung der Route des Netzwerkverkehrs im Falle eines Fail Overs einer Netzwerkkarte eine Benachrichtigung zum physikalischen Switch gesendet um die Tabellen des Switches zu aktualisieren. In den meisten Fällen ist dies die beste Einstellung um die geringste Latenzzeit während eines Fail Overs sowie bei einer VMotion-Migration zu erhalten.

Lösung

Der vSwitch mit der Port Group für das NLB-Kommunikations-Netzwerk (Netzwerk & Port Group-Name vLAN_Backend) wird um eine weitere Port Group erweitert:

Name: vLAN_Backend_NLB
alle Einstellungen bis auf Notify Switches werden der Konfiguration des vSwitch vererbt
Notifiy Switches wird explizit auf 0 gesetzt

Der vSwitch sieht wie folgt aus:

Die Netzwerkkarte des NLB-Hosts welche für die NLB-Kommunikation verwendet wird, wird auf die neue Port Group verbunden:

Der NLB-Cluster verwendet dann die neue Port Group:

Technischer Hintergrund

Alle Netzwerkkarten eines NLB-Clusters im unicast mode teilen sich eine gemeinsame MAC-Adresse. Der NLB-Cluster maskiert the MAC-Adresse des NLB-Clusters bei ausgehendem Netzwerkverkehr um zu vermeiden, dass der Switch die MAC-Adresse des NLB-Hosts lernt. Dies bedeutet, dass der gesamte Netzwerkverkehr auf einem Switch auf alle Ports gesendet wird, an dem die NLB-Hosts konnektiert sind.

Der vmkernel des ESX-Servers sendet ein RARP-Paket bei jedem Startvorgang einer VM um den Switch über die MAC-Adresse der VM informieren. Im Falle eines NLB-Hosts als VM bewirkt dies jedoch, dass die MAC-Adresse des NLB-Hosts und nicht die MAC-Adresse des NLB-Clusters dem Switch bekanntgegeben wird. Die Folge davon ist, dass sämtlicher Netzwerkverkehr zum NLB-Cluster falsch geleitet wird.

Die Einstellung Notify Switches bewirkt scheinbar, dass der Switch über MAC-Adress-Änderungen im Allgemeinen informiert wird. Daher bewirkt ein Setzen auf No den gewünschten Effekt für NLB-Clusters, nämlich keine Mitteilung über MAC-Adress-Änderungen der VM an den virtuellen Switch des ESX-Servers.

Autor: Carsten Schäfer, Benutzer für Benutzer VMachine.de