Load-Balancer

Load Balancer vs- NLB
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.

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.

Funktionsprinzip

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. Schon daher kann die MSXFAQ hier keine Empfehlung geben oder Produktvergleiche anstellen. 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.

Opps die Liste ist fast leer ? Sie können mit helfen die Liste zu füllen und zu pflegen.

Load Balancer
Type/Versionsnummer		 Dienste
z.B. OWA, RDP, OCS, EAS		 Umgebung
z.B. Größe/Bandbreite		 Ansprechpartner
(Firma, Name, Link)
Windows NLB OWA, EAS, POP, SMTP, IMAP, EWS
NICHT RPC !		 5000 User z.B. Net at Work
ISA mit NLB und CAS-Veröffentlichung als WebArray OWA, EAS, POP, SMTP, IMAP, EWS
NICHT RPC !		   z.B. Net at Work
KEMP Alle Je nach Gerät KEMP Technologies, Inc
Luetzerodestr. 12 30161 Hannover
emea@kemptechnologies.com
Cisco      
F5      
Big IP      
Barracuda      

Angeblich will Microsoft zu gegebener Zeit eine Liste von Systemen bereit stellen, die mit OCS ihre Funktion zeigen konnten. Soweit ich aber weiß, gibt es von Microsoft keine Test oder Zertifizierungsprogramme für externe Load Balancer.

Load Balancer und Exchange 2010 CAS

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 ExchangeRPC-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.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
Value: TCP/IP Port
Type: DWORD

<configuration>
    <appSettings>
        <add key="RpcTcpPort" value="55001" />
    </appSettings>
</configuration>

Key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesMSExchangeABParameters
Value: RpcTcpPort
Type: REG_SZ

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.

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 si im Abschnitt "Mehrwert" schon gelesen haben, dann kommen für eine Entscheidung durchaus noch andere Themen dazu.

Weitere Links

Keywords: NLB ReverseProxy Loadbalancer Accelerator