NLB Intern

NLB ist eine Funktion, wie bis zu 32 Server die gleiche IP-Adresse verwenden können, um TCP/IP-basierte Dienste (z.B. Webserver, Terminaldienste etc.) hochverfügbar bereit zu stellen.

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.

NLB und Exchange 2007
Der Einsatz von NLB ist mit der RTM Version nur mit der CAS-Rolle unterstützt. Ein Einsatz auf einem Server mit einem HubTransport oder gar eine Mailbox Rolle ist nicht unterstützt.
Erste Exchange 2007 SP1 erlaubt NLB auch für SMTP-Connectoren für Client. Über diese Server darf dann aber keine IntraOrg-Kommunikation gehen:
Siehe auch E2007:ClientAccess und CAS und NLB

Bei Windows 2008 ist NLB ein "Feature"

nlb.wmv (20 MB, 24min)

Achtung:
Veröffentlichen Sie nie die NLB-Adresse über einen vorgeschalteten ReverseProxy (ISA, TMG), da das NLB Cluster hier dann nur einen Client (den Proxy) sieht und keine Lastverteilung für die unterschiedlichen Clients machen kann, die durch den ReverseProxy kommen. Der ReverseProxy muss selbst die Last verteilen.

NLB prüft keine Dienste
Im Gegensatz zu Load Balancern kann NLB nicht die Funktion der bereitgestellten Dienste aktiv testen, d.h. wenn der Server läuft aber z.B. Exchange einen "Fehler" hat, dann wird der Knoten weiterhin Verbindungen annehmen. Das können LoadBalancer besser

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.

Hochverfügbarkeit ist auch mit Exchange ein Thema und der Begriff "Network Load Balancing" (NLB) wird immer wieder  genannt. Und NLB kann tatsächlich im Einsatz mit Exchange eine höhere Erreichbarkeit bestimmter Dienste ermöglichen. Dazu müssen Sie aber wissen, was hinter NLB steht und was es nicht machen. NLB firmierte früher auch unter dem Namen Windows Load Balancing Service (WBLS), dem frühen Codenamen "Convoy" oder als Network Load Balancing  Services (NLBS).

Lizenztechnische ist diese Funktion Bestandteil jedes Windows 2003 Server, Windows 2000 Enterprise (nicht Standard !) und es gab diese Funktion als Add-On für Windows NT4.

Wie funktioniert das ?

Für das folgende Kapitel sollten Sie das ARP-Protokoll können. Es ordnet einer IP-Adresse eine MAC-Adresse zu.

Damit NLB überhaupt funktionieren kann, muss eine wichtige Forderung sichergestellt sein:

Alle eingehenden Pakete an die NLB-IP-Adresse müssen bei ALLEN des NLB-Teams Servern ankommen.

Das klingt im ersten Moment einfach aber zugleich auch verwirrend. Zum einen wissen Sie alle, dass eine IP-Adresse normalerweise genau einem System gehört und demnach auch genau eine Zuordnung zur Netzwerkkarte möglich ist. Die meisten Administratoren können nur "Broadcasts", die dann bei allen Systemen im gleichen Subnetz ankommen. Zudem bedeutet solche eine Forderung eine höhere Last auf allen Servern, da ein Server auch Pakete verarbeiten muss, für die ein anderer Server zuständig ist. Das sollte aber in Zeiten von 100 Megabit oder Gigabit kein Problem darstellen.

NLB ist kein Problem beim Einsatz eines Hub zwischen den Servern. Aber da heute nur noch "Switches" eingesetzt werden, welche die Pakete nur an den für die MAC-Adresse zugehörigen Port weiterleiten, muss man sich etwas überlegen. Wenn bis zu 32 PCs an einem Switch hängen, dann können ja nicht alle die gleiche MAC-Adresse vorgeben. Der Switch würde ja immer nur eine Adresse genau einem Port zuweisen.

Um dies zu lösen, kann NLB in einer von drei Betriebsarten arbeiten:

  • UNICAST
    Wenn ein Switch ein Paket an eine ihm noch nicht bekannte MAC-Adressen weiterleiten muss, dann sendet er das Paket per Default auf "allen" Ports weiter, in der Hoffnung, dass der Server schon dabei sein wird. NLB nutzt dieses Verhalten, indem es dem Switch keine Chance bietet, die MAC-Adresse zu lernen. Als Folge flutet der Switch natürlich alle Server. Das Fluten ist kein Problem, wenn Sie alle NLB-Knoten in einem eigenen VLAN betreiben.
  • MULTICAST
    Es gibt spezielle "MultiCast"-MAC-Adressen. Zusammen mit dem richtigen Switch kann dieser dann Pakete an diese MAC-Adressen an alle Ports mit dieser MAC-Adresse weitergeben. Die Daten erhalten also nur die Server, die diese Multicast Adresse im Switch reserviert haben und nicht alle Systeme am gleichen Switch bis VLAN.
  • IGMP Multicast (Ab Windows 2008)
    Nutzung von MuliCast-IP-Adressen in Verbindung mit IGMP, um die Wegewahl auf Switchports weiter zu optimieren. Hierzu sind aber Class-D IP-Adressen erforderlich.

Hier müssen Sie die "richtige" Betriebsart in Verbindung mit ihrem Switch abstimmen, denn nicht alle Switches "verstehen" MAC-Level-Multicast und es gibt Switches, die die ARP-Antworten der Server tief analysieren und nicht auf den Trick von NLB reinfallen. Auf der sicheren Seite sind sie natürlich beim Einsatz mir einem Hub.

Die Funktion und Tücken von ARP

Der Dreh und Angelpunkt von NLB ist die korrekte Funktion des Switches und ein Switch leitet Pakete anhand der MAC-Adresse an ein Zielsystem weiter. Der Switch lernt dabei, auf welchem Port welche MAC-Adressen angeschlossen sind. Der Switch "sollte" diese Information einfach aus den über ihn laufenden Paketen lernen. Wenn auf einem Port als ein Paket von der MAC1 kommt, dann lernt der Switch, dass hinter dem Port MAC1 angeschlossen ist. Kommen weitere Pakete von anderen MAC-Adressen über den gleichen Port, dann lernt der Switch auch diese. Kommt eine bereits gelernte MAC-Adresse aber plötzlich über einem anderen Port, dann muss der Switch diese auf dem neuen Port lernen und die alte Zuordnung vergessen. Das ist das "normale" Verhalten. Aber es gibt ein paar Ausnahmen.

  • NLB
    Für den Einsatz von NLB muss der Switch nun die gleiche MAC-Adresse auf mehreren Ports lernen undzudem das Paket auch auf alle Ports raus senden
  • Adapter Teaming
    Ist ein Server über zwei Netzwerkkarten an einen Switch angeschlossen, dann muss auch hier der Switch die Adresse auf mehreren Ports lernen aber das Paket nur auf einem der Ports raus senden. (Lastverteilung)
  • Intrusion Detection
    Einige Switches "mögen" es nicht, wenn eine MAC-Adresse zwischen Ports "hopst" und blockieren den Port nach einiger Zeit. Das kann natürlich störend sein.
  • Firewalls
    Speziell Server mit zwei Netzwerkkarten (eine mit NLB in Subnetz1 und das Backend in Subnet2) können trickreich sein, wenn Pakete über Subnetz1 ankommen, die Antwort dann aber über Subnetz 2 zurück geht. Einige Firewalls blockieren solche Fälle gerne als "Spoofing".

Egal ob sie nun Multicast oder unicast als Betriebsart nutzen, so sollten Sie wissen, dass Microsofts NLB-Lösung keine Sonderfunktion ist, sondern sich an Standards orientiert.

Achtung:
Oftmals vertragen sich NLB und Adapter Teaming nicht. konsultieren Sie vorab ihre Beschreibung zu den Netzwerkkartentreibern, den beide Verfahren verändern die MAC-Adresse der Netzwerkkarten.

Stellen wir uns einfach folgende Situation vor:

Ein Client sendet ein Paket an die 10.1.1.4 um eine Verbindung aufzubauen. Das Paket geht zum Router und dieser muss nun zur IP-Adresse die "passende" MAC-Adresse herausfinden. Der Router sendet dazu einen Ethernet-Broadcast (MAC-Adresse = FF:FF:FF:FF:FF:FF) in das LAN, der vom Switch auf alle Ports gesendet wird.

Folgendes Beispiel ist ein Mitschnitt des Systems 192.168.100.98, welches die MAC-Adresse des Systems 192.168.100.1 wissen möchte. Wenn es der Switch noch nicht weiß, dann lernt er die "Source" dieses Pakets für den Rückweg.

Das angefragte System antwortet mit einem ARP-Reply.

Nun passiert zweierlei:

  • Der Switch ...
    ... erkennt anhand des Ethernetpakets und der darin enthaltenen Quell MAC, auf welchen Switchport das Endgerät angeschlossen ist.
  • Der Router ..
    liest die Daten aus dem ARP-Reply und lernt so die MAC-Adresse zur angefragten IP-Adresse und legt Sie in seiner ARP-Table ab.

Das machen alle Systeme in einem Subnetz, wenn Sie ein anderes System im gleichen Subnetz erreichen wollen. Ohne den Einsatz von NLB, Cluster, Load-Balancer o.ä.  ist die MAC-Adresse im Ethernet Frame identisch mit der Sender-MAC-Adresse im ARP-Reply.

Wie schon geschrieben muss bei NLB sichergestellt werden, dass jedes Paket bei allen Mitgliedern im Team ankommt. Daher kann man für NLB natürlich keine physikalischen MAC-Adressen verwenden, die der Switch zudem immer nur genau einem Port zuweist. Also muss man tricksen. Dazu gibt es drei Optionen:

NLB-Filtertreiber: ARP und MAC-Adressen verändern sich, Pakete werden gefiltert

Auf dem LAN-Kabel ist alles noch recht einfach, aber zwischen dem TCP-Stack oben und der Netzwerkkarte unten hat sich der NLB-Filtertreiber eingeschaltet und der verändert die MAC-Adressen der Pakete. Bedenken Sie für die weiteren Betrachtungen folgende Aspekte:

  • Der NLB-Filter blockiert TCP/UDP-Pakete anderer Verbindungen
    Da mehrere NLB-Server im Team arbeiten, und jede Netzwerkkarte alle Pakete bekommt, muss der NLB-Filter die eigenen Verbindungen ausfindig machen und nach oben weiter reichen.
    Die Pakete von Verbindungen anderer Server werden verworfen.
  • NETMON und der Filter
    Der Microsoft Netzwerk Monitor schneidet per Default nicht direkt auf der Karte mit. Er "sieht" die Pakete, die nach dem NLB-Filter nach oben weiter gereicht werden. Insofern sehen Sie in NETMON auch nur "ihre" Pakete
  • ICMP wird nicht gefiltert
    NLB kann nur mit TCP und UDP-Paketen umgehen, für die es auch entsprechende "Regeln" gibt. Alle anderen Protokolle und Pakete werden ungefiltert weiter gegeben. Damit ist ICM P (PING.EXE) ein Weg die Flutung zu prüfen. Ein ICMP-Ping an die NLB-Adresse muss auf allen Servern landen und von allen Servern beantwortet werden
  • Multicast und unicast
    Auf dem Kabel wird ein Ethernetpaket an den NLB-Knoten gesendet, welches als Ethernet-Adresse entweder die Multicast-MAC-Adresse oder unicast-MAC-Adresse hat. Pakete, di der NLB-Filter nicht filtert und durchreicht, werden aber verändert, dass hier die MAC-Adresse der Netzwerkkarte erscheint. Eine Anwendung "sieht" also gar nicht diese besonderen MAC-Adressen. Entsprechend können Sie mit NETMON auch für TCP/UDP-Pakete die Funktion nicht verifizieren.
    Für ICMP funktioniert es aber und auch ein Mitschnitt auf dem Übertragungsweg selbst oder auf dem Router/Client im gleichen Subnetz zeigt die richtigen Pakete.

Sie sehen also, dass speziell das hinterher schnüffeln von NLB-Paketen nicht trivial ist.

NLB im uNICAST Mode

Die erste Betriebsart von NLB ist der Einsatz im "Unicast-Mode". Aus der IP-Adresse wird nun eine virtuelle MAC-Adresse generiert, die als Präfix mit "02-bf" beginnt. Auf den gleichen ARP-Request folgt nun eine andere Antwort:


NLB unicast ARP Antwort

Im Ethernet Paket kommt weiterhin die physikalische Adresse der Netzwerkkarte zum Einsatz, die auch der Switch gerne lernen kann. Aber im ARP-Reply wird eine besondere MAC-Adresse verwendet. Bei unicast beginnt diese mit 02-BF und die weitere Stellen repräsentieren die IP-Adresse in HEX. Der Router oder andere Systeme im gleichen Subnetz lernen anhand dieser Daten wieder die Zuordnung der IP-Adresse zur MAC-Adresse.

Der Trick dieser Antwort besteht darin, dass ein normaler Switch die 02-BF Adresse ja nie als Ethernet Adresse zu Gesicht bekommt und daher nicht lernen kann. Ein Paket an diese MAC-Adresse wird vom Switch also auf alle Ports verteilt und erreicht damit sicher alle NLB-Mitglieder. Leider flutet man damit auch alle anderen Ports im gleichen IP-Subnetz, so dass man dieses Verfahren nur in kleinen Netzwerken oder eigenen VLANs verwenden sollte.

Einige Switch wollen aber "schlauer" sein und werten auch die ARP-Antworten aus. Dieses Verhalten ist hier natürlich absolut störend, da damit NLB im unicast-Mode nicht mehr funktioniert.

Unicast und SingleMac
Wenn Sie einen NLB-Cluster mit nur einer Netzwerkkarte aufbauen und uNICAST einsetzen, dann nutzen alle Server auch die 02-BF Adresse und als direkte Folge können Sie nicht mehr untereinander kommunizieren. Der NLB-Knoten darf also selbst keine Dienste anbiete (z.B. SQL, DNS, WINS, LDAP etc.) da diese nicht von den Teammitgliedern erreichbar wären. Zudem können Sie mit der NLBS-Verwaltungskonsole nur eingeschränkt das Team verwalten.

NLB Single Network Adapter Limitations
http://technet.microsoft.com/en-us/library/cc780023.aspx

Auf vielen Switches können Sie sich die MAC-Addresstable anzeigen lassen. Hier sollte die uNICAST-Adresse nicht aufgeführt werden, sonst hat der Switch diese "gelernt" hat.

Werden NLB-Server unter VMWare ESX betrieben, ist in der Betriebsart "Unicast" Anpassungen im virtuellen Switch erforderlich
http://www.vmware.com/files/pdf/implmenting_ms_network_load_balancing.pdf

Beim Einsatz von unicast NLB unter Windows 2008 mit einer Netzwerkkarte für NLB nud einer Netzwerkkarte für den Host im gleichen Subnetz, muss wegen des strong host model folgender Befehl ausgeführt werden:

netsh interface ipv4 set int "NLB" forwarding=enabled

Weitere Informationen finden Sie auch auf

NLB im Multicast-Mode

Aufgrund der Problematik der Switches und vor allem das Fluten wird durch den Multicast Mode gelöst. Viele Administratoren und Netzwerker haben zwar schon mit IP Multicast- Adressen gehört (Class-D Netze, IP-Adresse 224.0.0.0 -239.255.255.255), welche z.B. beim Einsatz on Videokonferenzen und diversen Routerprotokollen (BGP etc.) zum Einsatz kommen. Aber es gibt auch auf Ethernet-Level (OSI Schicht 2) so genannte Ethernet "Multicast-MAC-Adressen". (Ich habe es anfangs auch nicht gewusst. In Verbindung mit dem richtigen Switch erlaubt dies eine sehr einfache effiziente Verteilung der gleichen IP-Pakete an mehrere Systeme).

Reihenfolge bei der Übertragung auf dem Kabel von links nach rechts:

0                           23 IP Multicast Adressgruppe   47
|                           | <--------------------------->|
1000 0000 0000 0000 0111 1010 xxxx xxx0 xxxx xxxx xxxx xxxx
|                                     |
Multicast Bit                         0 = Internet Multicast
                                      1 = Assigned für other uses

Ergibt 
0000 0001 0000 0000 0101 1110  oder 01 00 5E xx xx xx

Das erste Bit bei der Übertragung auf dem Kabel ist auf "1" gesetzt. Allerdings wird bei Ethernet zuerst das höchste Bit übertragen. Im Computerspeicher werden die Bits nach LSB abgelegt. Solche Adressen kommen natürlich auch bei Verwendung von Class-D Adressen im IP-Multicast betrieb zum Einsatz. Hierzu sind die Adressen "01-00-5E" über IP-Multicast  (also 224.x.x.x) reserviert. für die Nutzung mit NLB baut Microsoft eine andere Adresse zusammen in der Form:

03-bf-aa-bb-cc-dd

Die NLB-Knoten werden als Multicast-Knoten konfiguriert und nutzen dann eine MultiCast MAC-Adressen. Die MAC-Adresse wird anhand der IP-Adresse des NLB-Clusters gebildet. Ein entsprechender ARP-Reply sieht wie folgt aus:


NLB Multicast ARP-Antwort

Als "Source Adresse" steht die physikalische MAC-Adresse der Netzwerkkarte im Paket, aber der ARP-Reply liefert die 03-BF-Adresse. Die nächsten vier Bytes entsprechen der IP-Adresse des NLB-Clusters. Wenn ihr Cluster daher die IP-Adresse 192.168.100.33 nutzt, dann ermittelt sich die MAC-Adresse wie folgt:

03h
BFh
C0h = 192
A8h = 168
64h = 100
21h =  33

Multicast MAC für NLB = 03-BF-C0-A8-00-64

Damit können Sie anhand des ARP-Cache natürlich dann auch gleich auf die IP-Adresse des Clusters zurück schließen. Ein passender Switch wird verstehen, dass es Multicast Adressen sind und entsprechend lernen, auf welchen Ports Pakete an diese Adresse übertragen werden müssen.

Auf vielen Switches können Sie sich die MAC-Adresstabelle anzeigen lassen. Hier sollte die MULTICAST-Adresse für alle Ports aufgeführt werden, an denen ein NLB-Cluster-Knoten hängt.

Hier werden die Probleme des uNICAST-Mode umgangen, aber der Switch muss damit zurecht kommen. Keine Probleme gibt es immer, wenn man alle NLB-Knoten an einen Hub anschließt, da dieser die ganze MAC-Adressen Steuerung nicht kennt.

Wenn der Switch korrekt funktioniert, dann ist das schon der erste Schritt aber die zweite Hürde ist der Router, welcher Pakete aus anderen Subnetzen an die IP-Adresse des NLB-Clusters senden muss.

Viele Router akzeptieren keine Multicast-MAC-Adressen in einer ARP-Antwort. Hier müssen Sie manuell nachhelfen. Sie verhalten sich dabei auch noch RFC Konform:

RFC 1812 Requirements für IP Version 4 Routers
3.3.2 Address Resolution Protocol - ARP
"A router MUST not believe any ARP reply that claims that the Link Layer address of another host or router is a broadcast or multicast address..."
Quelle: http://www.ietf.org/rfc/rfc1812.txt

Entsprechend kann es sein, dass Sie auf den Routern in diesem Subnetz die IP-Adresse des NLB-Clusters zur passenden MAC-Adresse statisch eintragen müssen. Bei einem Cisco IOS lautet die entsprechende Sequenz:

EN
CONF T
IP ARP ip.ip.ip.ip 03BF.CCDD.EEFF ARPA
EXIT
WR

Nach dem Eintrag sollten sie nun auch aus anderen Subnetzen die NLB-IP-Adresse erreichen können, was vorher nicht möglich war.

Weitere Links