Network Load Balancing (NLB)

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.

Was ist NLB ?

Im Gegensatz zu Windows Cluster (Siehe Exchange Cluster), wo ein Dienst beim Ausfall auf einen anderen Server  übertragen wird, funktioniert NLB so dass mehrere Server sich eine Aufgabe teilen. Bis zu 32 Server bekommen zu diesem Zweck neben ihrer eigenen IP-Adresse eine weitere gemeinsame Adresse, d.h. alle bis zu 32 Server haben nach außen die GLEICHE IP-Adresse.

Damit dies funktioniert, müssen Sie sicherstellen, dass alle eingehenden Pakete an diese Adresse auch bei allen Servern ankommen. Die Server machen dann untereinander aus, welcher die Anfrage annimmt und bearbeitet. Dazu können Parameter wie aktuelle CPU-Auslastung und andere als Entscheidungskriterium genutzt werden. Je mehr Server sie haben, desto mehr Leistung stellen Sie ihren Clients bereit. Dies ist besonders interessant, wenn der Webserver z.B. umfangreiche ASP/ASP.NET oder andere Skripte und serverseitige Erweiterungen ausführt.

NLB ist durch diesen Ansatz aber viel flexibler und robuster als ein DNS-Round-Robin. Sie können z.B.: eine Webseite ja auch ohne NLB auf zwei Webservern laufen lassen und einfach beide IP-Adresse im DNS eintragen. Dann würden auch die Pakete verteilt (Load  Balancing) aber beim Ausfall eines Servers würden die Hälfte der Anfragen eben nicht mehr ankommen,  solange Sie die IP-Adresse nicht dem verbliebenen Server zuweisen oder den ausgefallenen Server wieder online bringen. NLB löst dies elegant, da ein ausgefallener Server  "unendlich teuer" ist und damit die verbliebenen neue Verbindungen übernehmen.

Dies bedeutet aber, dass alle Server auch über die gleichen Informationen verfügen müssen oder sich diese zumindest besorgen können. Sie können mit NLB also keinen Exchange Postfachserver auf mehrere Server verteilen und damit verfügbar machen.

NLB kommt dann zum Einsatz, wenn mehrere Server die gleiche Information über TCP/IP abgegeben oder annehmen können Damit sind z.B. folgende Einsatzbereiche denkbar:

NLB macht aber  keinen Sinn für Exchange Postfachserver, Dateiserver, SQL-Server etc.

Wie funktioniert das ?

Für das folgende Kapitel sollten Sie das ARP-Protokoll kennen. 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 kennen 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:

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.

NLB ist nicht "Application Aware" - Achtung bei Updates

Bei aller Funktion von NLB darf nicht vergessen werden, dass NLB nur auf den Host wirkt aber nicht die dahinter liegenden Dienste auf ihre Funktion überwacht. Wenn mehrere Server also z.B.: eine Webseite bereit stellen und sie auf einem Server die Webseite stoppen, dann "merkt" NLB das nicht und nimmt weiterhin Anfragen durch den Client an. Solche Fälle werden besser durch einen externen Loadbalancer bedient, die aktive Tests durchführen

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.

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:

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:

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

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 Ethernetlevel (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 for 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 for 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.

NLB Konfiguration

Erst dann beginnt erst die eigentliche NLB Konfiguration. Neben der NLB-Adresse braucht er 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.

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.

NLB Test

Das gemeine 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. Also muss man Testen. Vier Tests bieten sich an, wobei die ersten zwei eigentlich nicht für NLB direkt tauglich sind aber die Switches einfach testen.

ICMP

ICMP ist das Protokoll, welche hinter PING und TRACEROUTE steht 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. Auch wenn NLB eigentlich nur die Protokolle UDP und TCP unterstützt, so muss auch ein ICMP-Paket an die NLB-Adresse zugestellt und beantwortet werden. Da NLB aber keine Verbindung zu einem Host zuordnen kann, antworten eben beide Systeme. Nun ist wieder 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 (ipv4.addres == 192.168.0.1 oder so)

Der Client sollte erst einmal im gleichen Subnetz sein. Nach der ARP-Anfrage sendet der Client einen ICMP-Request an die NLB-IP-Adresse und verwendet die MAC-Adresse, die im NLB-Team konfiguriert ist. 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. Einige UNIX-Varianten meldet das sogar, dass mehr ICMP-Antworten eingetroffen sind. Manchmal können es auch drei Antworten sein, was ich noch nicht weiter untersucht habe. Sollte es nicht funktionieren, dann ist ein "ARP -A" auf dem Client ein Test, ob zumindest die ARP-Auflösung funktioniert.

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. 

Anwendung TCP und IIS

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. Also in der Art:

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

und einfach den Servernamen statt "Server1" einzutragen und nach "c:\inetpub\wwwroot\nlbtest.htm". Dann sucht man sich mehrere Clients und gibt im Browser eben 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. Man kann auch mit der Gewichtung arbeiten, um den ersten Server schlechter dastehen zu lassen.

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. 

Adapter Teaming

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:

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.

Wenn Sie NLB mit Teaming kombinieren, dann funktioniert dies meist nur mit MULTICAST !
Siehe auch 278431 Using teaming adapters with network load balancing may cause network problems

NLB mit Exchange

Ehe wir in die "Tiefen" von NLB und dessen Funktion einsteigen, sollten Sie zuerst einmal wissen, welchen Vorteil NLB in Verbindung mit Exchange haben kann. Der einzige Platz, bei dem NLB sinnvoll in einer Exchange Umgebung eingesetzt werden kann sind Exchange 200/2003 Frontend Server oder Exchange 2007 Client Access Rollen und eingeschränkt die Hub/Transport-Rolle. Mit NLB kann mit mehreren Servern eine bessere Verfügbarkeit von Diensten erreicht werden, wenn die Clients kein eigenes Failover können und DNS-Round-Robin nicht flexibel genug ist. Damit ist NLB prädestiniert für die Systeme, die Verbindung von Anwendern per POP3, IMAP4, HTTP und SMTP annehmen und dann nach "hinten" zu den Datenbankservern weitergeben.

NLB ist nicht geeignet, um Mailboxserver "hochverfügbar" zu machen, da es keinen Sinn macht, mehrere Mailboxserver unter einer virtuellen IP-Adresse erreichbar zu machen. Es macht auch keinen Sinn, mehrere Connectorserver über NLB zu verbinden, da alle Mailserver problemlos ein Failover über zwei MX-Records unterstützen. Etwas anderes ist es natürlich, wenn Sie mehrere SMTP-Server für die POP3/IMAP4-Clients bereit stellen wollen.

Zur Konfiguration sollten Sie dann einfach die erforderlichen Protokolle im NLB-Team konfigurieren. Dies sind bei Exchange:

Protokoll Ports
SMTP 25/TCP,  587/TCP, 465/TCP (Smtps) 
POP3 110/TCP, 995/TCP
IMAP4 143/TCP, 993/TCP
HTTP (OWA, ActiveSync) 80/TCP, 443/TCP

Eventuell nutzen Sie ja noch andere Ports.

NLB und ISA

NLB ist ja geradezu prädestiniert für den Einsatz bei Webservern oder HTTP-basierten Anwendungen. Allerdinge werden nur die wenigsten Firmen ihre Webserver (auch als NLB-Team) direkt im Internet erreichbar machen. Die meisten Firmen werden Firewall davor stellen. Gerade hier lauert aber die Gefahr, dass die NLB-Konfigration nicht wie gewünscht arbeitet. Das NLB-Team weist neuen Verbindungen ein Teammitglied anhand der "Affinität" zu. Normalerweise ist hier "Einzel" aktiv, d.h. eine weitere Verbindung der gleichen IP-Adresse wird dem gleichen Teammitglied zugewiesen. Das macht auch Sinn, wenn ein Client z.B.: mehrere parallele HTTP-Anfragen stellt, um Bilder etc. nachzuladen, dann sollte er auch auf dem gleichen physikalischen Webserver landen. Besonders wenn eine Anmeldung für den Zugriff erforderlich ist, würde die Verteilung auf ein Team beim Benutzer mehrfach eine Anmeldung anfordern.

Sehr viele Firewalls arbeiten allerdings als "Reverse Proxy", d.h. nehmen die Webanfragen an, terminieren diese und bauen ihrerseits eine eigene Verbindung zum internen Webserver auf. Die NLB-Farm sieht in diesem Fall natürlich nur die IP-Adresse der Firewall (z.B.: ISA-Server)

NLB Fehlerhaft mit Reverse Proxy

Wenn die erste Anfragen auf dem CAS2 landet, dann würde der CAS1 nur dann etwas zu tun bekommen, wenn CAS2 komplett ausfällt. Von einer Lastverteilung kann man hier natürlich nicht sprechen. Wenn man NLB mit Reverse Proxy-Servern kombinieren will, dann muss man entweder die IP des Internet Clients direkt bis zum CAS-Server durchreichen (ISA-Server kann das, wenn er als Gateway und Router dient, da nur dann auch die Antwort des NLB-Teams über das Default Gateway wieder beim ISA-Server landet).

Eine zweite Option ist natürlich, dass das Reverse Proxy System selbst auf mehrere Backendserver die Daten sinnvoll aufteilt (Load Balancer). Das könnt dann so aussehen:

NLB korrekt mit Reverse Proxy

Die mehrfach vorhandenen Reverse Proxy Systeme werden ihrerseits per NLB im Internet mit einer IP-Adresse veröffentlicht, und nehmen die Anfragen an. Wenn die Verbindung nach intern nicht mit der IP-Adresse des Clients aus dem Internet erfolgen soll, dann muss das Reverse Proxy Team selbst an die interne Farm eine Lastverteilung machen. Solch eine Funktion bietet z.B. ISA2006.

Es ist dabei nicht einmal verboten, intern die Webserver Farm auch weiterhin per NLB besser verfügbar zu machen. Allerdings sollte diese NLB-Adresse dann nur von internen Systemen und nicht über die Reverse Proxies angesprochen werden. Eine solche Konstellation könnte mit Exchange 2007 CAS-Servern durchaus sinnvoll sein, da auch die CAS-Server im internen Netzwerk als Zugriffspunkte für Clients dienen.

NLB und externe Load Balancer

Manchmal kann man kein NLB einsetzen, weil die Kombination von NLB mit MSCluster nicht möglich ist oder die Switches und Router nicht mitspielen. Dann bleibt noch die Option, vor die Serverfarm externe "Load Balancer" zu platzieren. Wenn Sie es sich aber genau anschauen, dann verlagern Sie das "Problem" damit nur eine Stufe nach vorne. Mal abgesehen von einer Konfiguration aus zwei Systemen, die Aktiv/Passiv arbeiten, benötigen alle anderen Lösungen ebenfalls einen Trick, damit die Anfragen der Clients auf die Lastverteiler aufschlagen. Aber vielleicht haben Sie solch ein System sogar schon am laufen. Hier eine Übersicht der gängigen Hersteller, die Sie aber nicht als Empfehlung oder Kompatibilitätsversprechen mit Exchange verstehen sollten

NLB und Hyper-V oder VMWare

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/HyperV 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

 

Weitere Links

Keywords: NLB WBLS NLBS Convoy