Load-Balancer

NLB vs. HLB
Oft stellt man mir die Frage, warum man nicht einfach das kostenfreie NLB nutzt. Tatsächlich kann auch mit NLB eine Lastverteilung zwischen Server erreicht werden. Allerdings gibt es oft seitens der Netzwerkadministratoren Vorbehalte. Zudem kann NLB nicht auf einem Microsoft Cluster gleichzeitig genutzt werden, was dann gegen den CAS auf dem Cluster spricht. Der größte Nachteil ist aber wohl, dass NLB nicht aktiv die Dienste hinter einer IP-Adresse auf die Funktion prüfen kann. Ein "hängender IIS", der noch Verbindungen annimmt aber keine Daten mehr liefert, kann NLB nicht erkennen. Ein guter Load Balancer mit passender Konfiguration aber sehr wohl.

Loadbalancer stehen in der Regel vor Exchange, Lync aber auch anderen Diensten wie DNS, LDAP und leiten die Anfragen an die Dienste dann wirklich an die Server weiter, die tatsächlich auch verfügbar sind und sinnvolle Daten liefern. Zudem können Sie auch Ausfälle erkennen und sie sparen sich die Probleme mit NLB Unicast (Fluten des Subnetzes) oder NLB Multicast (Konfiguration auf Router/Switch) und in Verbindung mit Virtualisierungslösungen behalten Sie die Flexibilität.

Outlook scheint bei der Verwendung des SCP für Autodiscover immer den "ältesten" CAS-Server in der AD-Site zu nutzen. Dies ist wohl noch ein Fehler in Outlook, welches bei der LDAP-Anfrage zwar ein Array bekommt, aber immer den ersten (ältesten) Eintrag nutzt. Wohl dem. der die SCP-URLs auf einen generischen Namen gelegt, hat, welcher per Loadbalancer einen verfügbaren CAS erreicht.

Windows selbst kennt seit NT4-Zeiten die Funktion, mehreren Servern die gleiche IP-Adresse zu geben, um Dienste, die auf allen Servern identisch vorgehalten werden, besser4 verfügbar und skalierbar zu machen. Früher unter dem Codenamen "Convoy und dann WLBS ist NLB seit Windows 2003 nun in jeder Windows Version vorhanden und kann einfach integriert werden. Mit NLB werden Anfragen von allen Server im Team empfangen und einer der Server übernimmt die Aufgabe diese Verbindung zu bedienen. Allerdings erkennt NLB nur, ob der Server und Port erreichbar ist aber nicht, ob der dahinter lauschende Dienst sinnvolle Daten ausliefert. Dies ist ein Grund, warum NLB nicht in allen Fällen die optimale Lösung ist. NLB ist z.B.: nicht kompatible mit Microsoft Cluster. Wer also z.B. einen Exchange 2010 Cluster als Database Availability Group betreibt, kann die darauf mit installieren CAS-Server nicht per NLB verfügbar gestalten. (Siehe auch 2-Server-DAG). Externe Load-Balancer können hier helfen, zwei zusätzliche Exchange Server einzusparen. NLB kann auch nur zwischen Windows Systemen genutzt werden. Firmen würden aber auch gerne andere Systeme bereit stellen und irgendwann kommen Sie dann doch dazu, externe Load-Balancer einzusetzen.

Planung ist wichtig !

Auch wenn die Werbung es ihnen gerne so beschreibt: Der Einsatz eines Loadbalancers in einem Netzwerk ist nicht immer ein "einfaches" Unterfangen, sondern durchaus eine nicht ganz unkomplizierte Komponente. In der Regel werde ich erst "danach" gerufen, wenn es "unerklärliche Effekte" gibt. Daher möchte ich einfach ein paar Stichworte vorab einwerfen.

Ehe Sie also einen LB einfach mal so kaufen und mal schnell installieren, sollten Sie sehr genau ihre Netzwerktopologie, die Dienste und Anforderungen kennen.

Funktionalität

Doch die Ansichten, was und wie ein Load Balancer funktioniert, sind nicht ganz einheitlich. Klar muss es ein System sein, welches die Anfragen der Clients zuerst erreicht und dann auf einen geeigneten "Backend-Server" weiter gibt. Aber da gibt es gleich mehrere Faktoren:

Das sind jedem Menge Punkte, die bei der Produktevaluierung und Auswahl zu beachten sind.

Details zur Funktion

Was auf den ersten Punkt so einfach aussieht, kann sich im Details als sehr knifflige Aufgabe herausstellen. Hier ein paar Beispiele, die es zu bedenken gibt:

Sie sollten daher schon etwas Erfahrung mit Routern, Switches, ARP, Routing, NAT und Werkzeugen wie NETMON haben, um bei Fehlern die Ursache einzukreisen.

Concurrent Connections und Affinity

Der Einsatz von Loadbalancern kann ihnen viele Sorgen und Probleme ersparen, aber in einigen Situationen sollten Sie genau die Funktionsweise verstehen, speziell wenn es um andere Protokolle als HTTP/HTTPS geht. Für HTTP/HTTPS haben viele Hersteller über den Reverse Proxy eine Erkennung der individuellen Sessions aber für Protokolle wie SMTP, POP, IMAP, welche für die meisten Loadbalancer einfache TCP-Verbindungen sind, setzen die meisten Systeme einfach die IP-Adressen um.

Die internen Server können dann aber nicht mehr die IP-Adresse des Clients erkennen, sondern sehen als Client nur die IP-Adresse des LoadBalancers. Damit treffen natürlich diese Einschränkungen z.B. auch auf Receive Connectoren zu.

[PS] C:\>(Get-ReceiveConnector)[1] |fl

Fqdn                                    : W2K8R2E2010.E2010.local
MaxInboundConnection                    : 5000
MaxInboundConnectionPerSource           : 20
MaxInboundConnectionPercentagePerSource : 2
PermissionGroups                        : ExchangeUsers
RemoteIPRanges                          : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}

Sie sehen hier schon den kritischen Faktor "MaxInboundConnectionPerSource". Dies ist zwar "nur" der Client Connector, aber wenn viele Personen parallel über einen Loadbalancer auf Exchange zugreifen, kann diese Zahl ganz schnell erreicht werden. Hier muss also der Grenzwert dann deutlich höher angesetzt werden oder der LoadBalancer in einer anderen Betriebsart konfiguriert werden, z.B. selbst als hochverfügbarer SMTP-Proxy oder als Default Router, so dass die Source-IP unverändert bis zum Backend Server weiter gegeben wird.

Aber auch in anderer Richtung kann die Wirkung eines Loadbalancers eingeschränkt werden. Wenn der Loadbalancer die Datenverbindungen anhand der Client-IP verteilt, dann ist er natürlich auch davon abhängig, dass die Clients wirklich mit unterschiedlichen Client-IPs bei ihm ankommen. Das ist leider z.B. nicht der Fall, wenn eine Niederlassung über einen gemeinsamen HTTP-Proxy auf Outlook Anywhere zugreifen oder viele Clients hinter einem NAT-Router sich verbergen (z.B. bei UMTS- oder VPN-Zugängen etc.). Auch dann sieht ein Loadbalancer nur wenige Source-IP-Adressen und belastet die BackendServer ungleichmäßig.

Diese "Affinität" ist aber für bestimmte Funktionen wichtig. Stellen Sie sich vor ein Client nutzt mehrere parallele TCP-Connections, was beim Einsatz von RPC ja schon "normal" ist. Der Client verbindet sich mit Port 135 und wird vom Loadbalancer zu einem Backend-Server weitergeleitet. Der dortige RPC-Portmapper auf 135 sendet als Antwort, dass der angefragte Dienst auf einem bestimmten Port läuft. Der Client verbindet sich nun mit diesem Port und wenn der Load Balancer nun die Pakete nicht zum gleichen Backend senden würde, dann würde der andere Server die Verbindung eventuell gar nicht annehmen oder eine Firewall aufgrund der fehlenden Port135-Voranbfrage die Verbindung blockieren. Zudem macht es natürlich keinen Sinn, wenn z.B. ein Webbrowser sich über einen TCP-Verbindung am Webserver anmeldet und dann mehrere parallele Verbindungen öffnet, um JavaScript, Stylesheets und Images herunter zu laden. Da sollte er natürlich ebenfalls auf dem gleichen Webserver bleiben. Ein anderer Backend-Server würde ansonsten sicher wieder Anmelddaten abfragen, da er die Session-Cookies nicht kennt und zusätzlich Speicher benötigen.

Transparency

Wenn ein Loadbalander als "Single Arm"-Konfiguration betrieben wird, dann muss diese nicht nur die Zieladresse sondern auch die Quelladresse umsetzen. Der Backend-Server sieht also eine Anfrage "vom Loadbalancer". Das macht z.B. ein TMG als Reverse Proxy auch erst mal per Default. So ist sichergestellt, dass das Antwortpaket auch immer beim Loadbalancer bzw. Proxy landet und ausgehend auch wieder umgesetzt wird. Dieses Verfahren hat zwei große Nachteile

Daher ist es oft ratsamer, den Loadbalancer als "Router" zu betrachten und die Backend-Server per Default Gateway zum Loadbalancer zu lenken. Dann kann der Loadbalancer die originale Client-IP an den Backend Server leiten und diese Einschränkungen entfallen. Aber wo Licht ist, ist auch schatten

Die Entscheidung ist also gar nicht einfach, ob sie ihren Loadbalancer nun als Router oder als "Single-Arm"-Konfiguration betreiben.

Layer4 oder Layer7

Als wenn es damit nicht schon genug wäre, gibt es noch die Unterscheidung nach Layer4 und Layer7. Wer sich etwas in den OSI-Modellen auskennt, wird Layer4 mit der Transportschicht (hier also TCP) und Layer7 mit dem obersten Protokoll (z.B. HTTP, FTP etc.) gleich setzen. Genauso ist es Loadbalancer auch gemeint. Er kann einfach nur TCP-Pakete umsetzen oder auf Protokoll-Level arbeiten. Bei Layer 7 hingegen "versteht" der LB das Protokoll. Meist ist das aber auf HTTP/HTTPS beschränkt.

  Layer 4 Layer 7
Pro
  • Schneller
  • billiger
  • weniger Ressourcen
  • Fast alle TCP-basierten Dienste zu verteilen
  • Kleine Firewall, da das Protokoll verstanden wird
  • SSL-Offloading möglich
  • Leistungsfähige Methoden zum Verteilen
  • Cookie Injection möglich
Contra
  • Persistence nur auf SourceIP
  • Keine Zuordnung anhand Daten in verschlüsselten Verbindungen
  • Mehr Ressourcen
  • Protokollspezifisch
  • Umfangreichere Konfiguration
Bewertung Wer es "einfach" mag, wird einfach mit Layer4 LB arbeiten Es gibt Dienste wie z.B. ActivesSync oder Lync Mobile, dort ist die "ClientIP" nicht ausreichend als Kriterium. Ohne Layer7 gibt es Funktionseinschränkungen.

Eine allgemeingültige Aussage für das beste Protokoll gibt es nicht. Layer4 ist in der Regel "einfacher", schneller und günstiger möglich. Bestimmte Dienste benötigen aber Funktionen, die nur mit Layer7 möglich sind.

Lync Mobile ist z.B.: ein Dienst, bei dem die Lync Webservices unbedingt anhand eines Cookie im Header immer wieder auf den gleichen FE-Server landen müssen, auch wenn der Client zwischen WiFi, UMTS, GPRS pendelt und dabei von intern und verschiedenen externen IP-Adressen den Loadbalancer anspricht.

Achten Sie dann aber auf die Leistung der Appliances.

Verteilung und HealthCheck

Eine Verteilung der Clients auf die Server per RoundRobin ist einfach, aber nur bei wechselnden Verbindungen ratsam. Besser ist eine "Least Connection"-Verteilung bei der immer der Backend-Server angesprochen wird, der aktuell die wenigsten Verbindungen bedient. Das ist natürlich immer nur auf einen Client zu beziehen. Wenn ein Client mehrere Verbindungen aufmacht wie dies bei RPC oder auch auf OWA der Fall ist, dann sollte der LB diese Pakete immer zum gleichen CAS-Server senden.

Aber der LB muss natürlich auch die "Gesundheit" eines Backend-Systems überwachen. Auch hier unterscheiden sich Produkte in ihrer Funktion und Leistung. meist stehen verschiedene Wege zur Auswahl:

Das Verfahren zur "Prüfung" ist auch aus anderem Grunde interessant: Wenn Sie einen Backend Server für Wartungszwecke außer Betrieb nehmen wollen, können Sie bei einer geeigneten Prüfung auch ohne Änderungen am Loadbalancer diesem eine "sehr hohe Last" mitteilen und einfach warten, bis die Clients alle den Server verlassen haben. Und nach dem reboot wird so sichergestellt, dass der LB die Anfragen nicht gleich wieder an den Server gibt, obwohl dieser vieleicht noch gar nicht komplett betriebsbereit ist.

Load Balancer und Exchange Receive Connectoren

Exchange kann pro Client IP bestimmte Dienste drosseln. Dies betrifft insbesondere die Receive Connectoren, die in der Regel die Zugriffe von Client begrenzen.

Wichtig:
Wenn ein Loadbalancer mit seiner eigenen IP-Adresse zum Server geht (SNAT), dann kann der Server nicht mehr den echten Client erkennen. Für den Server hinter dem Loadbalancer gibt es also nur noch genau eine "Client-IP", nämlich der Loadbalancer

In dem Fall müssen Sie eventuell die Throttling-Richtlinien anpassen.

Load Balancer und Exchange 2010 CAS mit RPC

Siehe auch CASArray

Wenn Sie nur einen Webserver veröffentlichen, dann ist eine Regel noch recht einfach. Wenn Sie aber z.B.: den Exchange 2010 CAS als CAS-Array betreiben und nicht mit NLB veröffentlichen, dann sollte ihr Loadbalancer auch Ports "gruppieren" können. Die RPC Kommunikation verwendet nämlich neben dem Exchange RPC-Port, welchen Sie sowieso für einen solchen Einsatz "fest" einstellen müssen auch noch RPC (135/TCP). Wenn der Load Balancer nun feststellt, dass ein Knoten nicht erreichbar ist, dann muss er nicht nur die Anfragen auf den Exchange-RPC-Port auf die verbliebenen CAS-Server umleiten, sondern auch die Zugriffe auf den Port 135, selbst wenn dieser auf dem defekten CAS-Server natürlich weiterhin erreichbar ist.

Sofern der Loadbalancer dies also anbietet, sollten Sie nicht, oder nicht nur den Port 135/TCP als Lebend-Erkennung "proben", sondern auch die Ports die vom ExchangeRPC- und ExchangeAB-Dienst genutzt werden. Diese sind per Default "dynamisch" aber können per Konfiguration auf dem CAS-Server fixiert werden.

Dies ist insbesondere dann auch wichtig, wenn Sie per LB nicht die ganze Portrange veröffentlichen wollen, sondern zum einen aus Schutzüberlegungen aber auch bezüglich Monitoring oder QoS-Einstellungen feste Ports bevorzugen. Allerdings sollten Sie zwischen den Zugriffen von Client auf Exchange und Exchange auf Exchange, z.B. in einer MultiSite-Umgebung, unterscheiden.

Diese Besonderheit von Loadbalancern sind pro Applikation zu prüfen.

Anwendung Ports
Verzeichnisse		 Affinität
Persistence
Stickyness		 Verfahren Timeout
Outlook WebApp 443/OWA
443/ECP		 Erforderlich ClientIP, Cookie 1h
Exchange Webservice 443/EWS Erforderlich ClientIP, Cookie 1h
RPC 135
MSExchangeIS
MSExchangeAB		 Erforderlich ClientIP 1h
Outlook Anywhere 443/RPC Ratsam ClientIP 1h
ActiveSync 443/Microsof....Sync Ratsam Authentication (SSL Offload)  
Powershell 443/Powershell
80/Powershell		 Ratsam ClientIP  
Offline Addressbuch 443/OAB Nein nicht relevant  
Autodiscover 443/Autodiscover Nein nicht relevant  
POP3/IMAP4 110/TCP
143/TCP
993/TCP
995/TCP		 Nein nicht relevant  
SMTP 25/TCP   nicht relevant  
Lync Webservices 443->4443 Ratsam ClientIP  
Lync Mobility 443-4443/MCX Erforderlich Erforderlich: Cookie !  

Bitte prüfen Sie Individuell, ob diese Einträge durch Updates und Servicepacks nicht verändert wurden. Zudem sollten Sie auch im Innenverhältnis aufpassen.

Exchange Standorte, die keine "external URL" haben, werden nämlich von anderen Servern bedient.

Protokoll Client -> Exchange Exchange -> Exchange Proxy
OWA Ratsam Nicht ratsam. OWA hat selbst Loadbalancing. d.h. Internal URL für OWA sollte nicht auf Loadbalancer verweisen.
ActiveSync Ratsam Ratsam aber ohne SSL-Offloading

Eine ganze Sammlung von Links liefert hier weitergehende Informationen finden Sie auf:

Load Balancer und OCS

Auch für OCS ist der Einsatz von Load Balancern möglich und in einigen Umgebungen sogar erforderlich, z.B. wenn mehrere Edge oder Direktoren ohne Edge verwendet werden.

Load Balancer und Lync

Microsoft hat mit Lync 2010 die Funktion „DNS-RoundRobin“ für viele Funktionen eingeführt, so dass die früher mit einem Enterprise-Pool erforderlichen LB für SIP nicht mehr erforderlich sind, wenn alle Clients ebenfalls mit dem Lync 2010 Communicator arbeiten. Allerdings funktioniert DNS-Round Robin nicht für die Lync Webservices und auch in Verbindung mit mehreren Edge-Servern (Hochverfügbarkeit) oder alten OCS-Clients sind weiterhin LB erforderlich.

Auch wenn eine DNS-RoundRobin in Lync mit dem Lync Communicator funktioniert, so kann es dennoch wünschenswert sein, auch den Zugriff auf Port 5061 zu verteilen. Da dort aber natürlich "TLS" gesprochen wird und einige Loadbalancer dies nicht gut "überwachen" können, bietet Lync die Funktion auf dem Pool einen alternativen Port zu hinterlegen.

Auf dem Port lauscht der Lync Frontend dann und meldet nur folgendes zurück "488” Port is configured for health monitoring only”. Wer später mal vorhätte, auch SIP over TCP anzubieten, z.B. weil ein bestimmter Clients an den Zertifikaten scheitert, dann sollten Sie hier vielleicht einen anderen Port nutzen.

Lync reagiert nur dann auf dem Port, wenn der Registrar läuft. Sobald der Dienst RTCSrv nicht läuft oder die Verbindungen per "Draining" unterbunden sind, ist der Port nicht erreichbar. So kann ein Loadbalancer die "nicht Erreichbarkeit" einfach erkennen und die nachfolgenden Zugriffe auf einen anderen Frontend weiter leiten. Die Verfügbarkeit dieses Ports stelle aber nicht sicher, dass alle Dienste, die für Lync relevant sind, gestartet sind. Dies ist aber nicht zwingend erforderlich, weil z.B. für den Konferenzdienst und viele anderen Dienste alternativen "Failover-Funktionen" möglich sind.

Hinweis:
Wer den SIP-Traffic per LB verteilt, sollte die Affinität auf TCP-Level mit einem Timeout setzen, der Größer ist also das "SIP Keep-Alive interval" (normalerweise 30 minuten).

Für den Zugriff aus dem Internet ist natürlich eine "Web Service URL" zu definieren, hinter der möglichst "Verfügbar" dein Frontend erreichbar ist. Die Verfügbarkeit ist hierbei natürlich abhängig von der Firewall-Lösung und ihres Reverse Proxy und wie dieser die Anfragen nach intern weiter gibt. Ein Microsoft TMG-Server kann ja auch eine "Webfarm" veröffentlichen und damit Lastverteilung und Verfügbarkeit von extern auf einen internen Pool sicherstellen. Bei der Konfiguration von Lync müssen Sie bei einem Pool diesen FQDN konfigurieren.

Die Erreichbarkeit des internen Webservice und Lync-Dienste können auf zwei Wege bereit gestellt werden:

Wer intern ganz ohne Loadbalancer arbeiten will, sollte einen vom Pool-Namen auch intern unterschiedlichen Namen für die Webservices definieren und z.B. auf einen FE lenken. Im Fehlerfall dieses FE muss dieser Name dann natürlich auf den anderen FE umgestellt werden (DNS-Eintrag) ändern. Diese Aussagen gelten zudem nur, wenn Sie auch Lync Clients und andere Lync kompatible Systeme einsetzen, die DNS-RoundRobin unterstützen.

Da der Einsatz von NLB auf Lync Frontend Servern nicht sinnvoll möglich ist und Microsoft für die Veröffentlichung der LyncWeb eines Enterprise Pools sowieso LoadBalancer vorschreibt, müssen Sie diese Dienste über gesonderte Hardware "veröffentlichen". Die Webdienste nutzen aber SSL und einige Loadbalancer bieten eine SSL-Acceleration oder SSL-Offloading an. Dies kann genutzt werden. Allerdings ist auf dem Lync Webdiensten eine Umleitung von Zugriffen auf Port 80 nach 443 eingerichtet. Das bedeutet aber auch, dass ein Loadbalancer nicht wirklich mit SSL-Offloading arbeiten kann. Er kann natürlich die SSL-Verbindung aufbrechen, um z.B. Anhand von Cookies die Sessions zu erkennen aber er muss auch zum Backend (also Lync Server) wieder mit SSL weiter arbeiten, da ein Umsetzen der Zugriffe von Extern Port 443 auf intern 80 einen "Redirect" auslösen würde.

Load Balancer und COM/RPC/SMB

Wenn eine Loadbalancer eine Verbindung eines Clients zum Server durchgibt, dann ist das ja noch einfach, aber oft heißt der Server physikalisch anders als die Adresse, unter denen ein Client den Server anspricht. Seit Windows 2003 SP1 kann ihnen hier eine neue Schutzfunktion von Windows die Funktion blockieren.

Sizing ermitteln

Nun ist es ja so, dass diverse Hersteller ganz unterschiedliche Produkte anbieten und wer sich z.B. die Produktmatrix von Kemp oder anderen Anbietern ansieht, der bekommt ein paar Zahlen angezeigt, mit denen ein normaler Administrator erst mal nichts anfangen kann.


Quelle: http://www.kemptechnologies.com/emea/server-load-balancing-appliances/product-matrix.html Stand Jan 2010

Auf der einen Seite hat das kleinste System schon 1 Mio "concurrent Layer4 Connections" und kann 25.000 HTTP-Requests/Sek bedienen aber mehr als 200 SSL-Transaktionen schafft es nicht. Bei all den Daten fragt sich der normale Administrator natürlich, was für seine Umgebung die "passenden" Zahlen sind. Daher müssen zumindest die drei Kennzahlen erläutert werden:

All diese Daten können (und sollten) sie natürlich aus ihrem aktuellen System, welches ohne LoadBalancer läuft, vorab ermitteln.

Relevant sind hierbei immer die Spitzenwerte, nicht ein Durchschnitt. Beachten Sie aber, dass es "Betriebsspitzen" sind und keine Spitzen eines Angriffs oder Missbrauchs, für den Sie sich nur bedingt vorsorgen können.
Die Angabe der "Anzahl Postfächer" ist allein kein hinreichender Ausgangswert

Dazu helfen ihnen zwei Faktoren.

Unterschätzen Sie nicht den Bedarf an "Connections". Internet Explorer baut z.B. bis zu 4 Connections parallel auf, d.h. ein OWA-User hat vier "Channels" offen.
Auch Outlook hat in der Regel 3 und mehr Kanäle offen und nutzt parallel noch die Webservices (OOF, Free/Busy/UM), OAB und andere Dienste, die weitere Ports bedeuten.
ActiveSync Clients hingegen nutzen meist nur eine Connection, die aber permanent gehalten wird.

Und dann kommt natürlich noch die Bandbreite dazu, wobei 4x GB oder auch 950 Megabits schon mehr ist, als was ein Exchange Server oder ihre externe Internetanbindung wohl erreichen kann.

Losgelöst von der nackten "Performance" unterscheiden sich Produkte durchaus auch noch bei dem Funktionsumfang. Das ist teilweise wie bei der Konfiguration eines Neuwagens. Es gibt Hersteller, die sehr günstig sind und wem die gebotene Funktion ausreicht, fährt damit sehr gut. In der Kompakt oder Mittelklasse ist es aber so, dass viele Hersteller eine allgemein gute Basis anbieten aber zu Zubehörlisten oder feinen Unterschiede erst nach längerer Beschäftigung mit der Materie klar werden.

Load Balancer und Application Routing mit IIS AAR

Auch Microsoft hat natürlich erkannt, dass eine Farm von Webservern mit NLB alleine nicht in jeder Hinsicht "Hochverfügbar" gemacht werden kann. NLB erkennt ja nicht, wenn ein Dienst nicht mehr sauber arbeitet. Zudem ist die Verteilung nur anhand der Client IPs aber z.B. nicht anhand von URLs möglich. Seit Feb 2009 gibt es nun ein AAR-Proxy für den IIS, welcher einen IIS vergleichbar zu Apache mit MODProxy nun zu einem URL-Proxy werden lässt. Damit kann ein Windows Server mit IIS7 selbst auch als Reverse Proxy Lasten Verteilen und mit verschiedenen Tests Systeme auf ihre Funktionsfähigkeit testen.

Das ist aus meiner Sicht aber eher etwas für größere Umgebungen, bei der eine Farm von "IIS7-Servern" zusammengeschaltet auf eine Farm von nachgeschalteten Applikations-Webservern zugreift. Die meisten Leser sind mit einem ISA/TMG als Reverse Proxy vermutlich besser bedient.

Sollten Sie dennoch mit IIS7 ARR Proxy einmal z.B. Outlook Anywhere (RPC over HTTP) veröffentlichen wollen, dann müssen Sie wissen, dass Outlook immer einen Request mit 1GB (1073741824 genaue Bytes) anfordert, selbst wenn die Menge an Daten dann kleiner ist. Der IIS7 hat aber per Default ein Limit auf 30 MB (HTTP Request Limit). Im IISLog kann man aber nicht erkennen, dass der Client einen so großen Request anfordert aber nicht wirklich verwendet. Entsprechend müssen Sie den Wert für "maximum allowed content length (Bytes)" im IIS7 anpassen.

Loadbalancer und Firewall

Einen häufigen Design-Fehler müssen Sie aber noch im Hinterkopf haben. Der Loadbalancer muss natürlich die Clients unterscheiden können, um die Verbindungen sauber zuordnen zu können. Wenn Sie aber nun eine Firewall auf dem Web vom Internet nach intern "vor" den Loadbalancer setzen und diese Firewall dann als "Reverse Proxy" agiert und die originäre Source-IP des Clients verschleiert, dann "sieht" der Loadbalancer nur die interne IP-Adresse des ReverseProxy. Eine "Verteilung" anhand der Source-IP ist dann natürlich der falsche Ansatz.

Es gibt mehrere Lösungswege, von denen ich drei einfach zu erklärende Optionen ich hier beschreibe

Es gibt durchaus weitere Optionen, aber nicht jedes Verfahren ist für jede Anwendung gleich gut geeignet.

Loadbalancer und SCOM

Loadbalancer habe auch Auswirkungen auf die Überwachung von Diensten. Zum einen muss natürlich ein Loadbalancer die veröffentlichen Server selbst prüfen, um Ausfälle des physikalischen Dienstes zu erkennen und die Last abhängig von der Belastung der Server zu verteilen. Aber die Exchange Commandlets, die auch SCOM nutzt, sprechen z.B. die "InternalURL" und "ExternalURL" an. Wenn Sie diese passend zu ihrer Umgebung angepasst haben (Siehe CASArray und CASURLs), dann wird auch SCOM und die Exchange Test-Commandlets auf diese Namen gehen.

Sie sehen also, dass ein Loadbalancer auch hier zusätzliche Anpassungen erforderlich macht. 

Produkte und Hersteller

Diese Seite kann sicher keine vollständige, aktuelle Übersicht aller Load Balancer im Markt bereit stellen. Sehen Sie diese Links eher als Startpunkt für eigene Recherchen. Zumal die Funktion der Lastverteilung nicht immer die einzige Funktion ist, sondern eine Teilkomponente einer kompletten Lösung. Schon daher ist das nicht alles "vergleichbar". Wie sie im Abschnitt "Mehrwert" schon gelesen haben, dann kommen für eine Entscheidung durchaus noch andere Themen dazu.

Ich werde aber, soweit ich davon Kenntnis habe, funktionierende Konfigurationen dokumentieren.

Wer einen "Load Balancer" mit Exchange, OCS o.ä. betreibt, kann mir gerne einen Hinweis zur Installation zukommen lassen. Interessant ist das eingesetzte Produkt mit Versionsnummer, die bereitgestellten Dienste und etwas die Größe. Für Rückfragen kann ich ihre Kontaktdaten gerne aufführen.

Ich kann hier nur von meinen eigenen Erfahrungen berichten und Links zu Loadbalancern aufnehmen, die ihre Funktion mit Exchange bzw. Lync bewiesen haben. Microsoft selbst stellt eine entsprechende Liste von getesteten Lösungen bereit:

Ich bin auf ihr Feedback angewiesen, damit diese Liste vollständig wird.

Load Balancer
Type/Versionsnummer		 Dienste
z.B. OWA, RDP, OCS, EAS		 Ansprechpartner
(Firma, Name, Link)
Windows NLB Exchange z.B. Net at Work (Siehe Einschränkungen auf NLB)
ISA mit NLB und CAS-Veröffentlichung als WebArray Exchange (ohne RPC) z.B. Net at Work
KEMP Exchange
Lync
Sharepoint

z.B. Net at Work

KEMP Technologies, Inc
Luetzerodestr. 12 30161 Hannover
emea@kemptechnologies.com

http://www.kemptechnologies.com/emea/server-load-balancing-appliances/loadmaster-exchange/overview.html
Ich würde aber den Aufpreis für die weniger beschränkte Version lieber in Kauf nehmen und LM2200 oder höher kaufen.
Loadbalancer.org Exchange
Lync
OCS		 http://de.loadbalancer.org/matrix.php
Citrix NetScaler Exchange 2010, OCS2007, Sharepoint, ASP.NET http://community.citrix.com/display/ns/Microsoft
http://www.citrix.com/English/ps2/products/product.asp?contentID=21679
Cisco ACE
Cisco CSS		  
F5 BigIP LTM  
Barracuda Loadbalancer   http://www.barracudanetworks.com/ns/products/balancer_overview.php
A10 AX Series   http://www.a10networks.com/
Avanu WebMux   http://www.avanu.com/products/webmux.htm
Brocade ServerIron   http://www.brocade.com/sites/dotcom/products-solutions/products/ethernet-switches-routers/application-delivery/product-details/serveriron-adx-series/index.page 
Radware AppDirector Exchange
OCS		 http://www.radware.com/Products/ApplicationDelivery/AppDirector/default.aspx 

Wer einmal erster Schritte mit der Thematik "Load Balancing" machen möchte, kann auch eine Freeware einsetzen, die einfach nur einen TCP-Port an ein oder mehrere andere nachgelagerte Systeme verteilt:

Das ist natürlich nur eine sehr einfach Lösung für erste Gehversuche. Ich würde daher eher dazu raten, einen der oben beschriebenen Systeme als virtuelle Maschine sich anzuschauen. Einige davon sind für mehrere Tage/Wochen kostenfrei zu verwenden.

Weitere Links

Keywords:NLB ReverseProxy Loadbalancer Accelerator