NLB mit anderen Load Balancern

Der Einsatz von NLB mit anderen Lastverteilern ist nicht ganz frei von Tücken. Dabei gibt es gleich zwei Fronten:

  • Veröffentlichen eines Dienstes, welcher mit NLB arbeitet
    Hierbei müssen Sie sich immer daran erinnern, dass es bei NLB eine "Affinity" gibt und das NLB-Cluster anhand der ClientIP oder Subnetz die Pakete immer an den gleichen Host zuleitet. Wenn der vorgeschaltete Loadbalancer daher nicht die externe IP des Anfragers sondern als ReverseProxy seine IP nutzt, findet keine Lastverteilung statt.
  • NLB auf dem Load Balancer
    Es ist durchaus möglich, mit NLB selbst einen Lastverteilungsmechanismus aufzubauen. ISA und TMG sind nur zwei Beispiele, um Anfragen von Clients auf einen Verbund zu verteilen, die dann auf nachgelagerte Server verteilt werden.

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 mit ISA/TMG

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-Konfiguration 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 hinter externen Load Balancern

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 Reverse Proxy muss selbst die Last verteilen.

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.