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.

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.

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.

Produkte und Hersteller

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.

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 OWA, EAS, POP, SMTP, IMAP, EWS
NICHT RPC !		 z.B. Net at Work
ISA mit NLB und CAS-Veröffentlichung als WebArray OWA, EAS, EWS
Kein RPC, POP/IMAP, SMTP		 z.B. Net at Work
KEMP Alle

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.
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		   http://www.cisco.com/en/US/products/ps6906/index.html
http://www.cisco.com/en/US/products/hw/contnetw/ps792/
F5 BigIP LTM   http://www.f5.com/products/big-ip/
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   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.

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.

Diese Besonderheit von Loadbalancern sind pro Applikation zu prüfen. Für Exchange galt 2011 folgende Tabelle

Erforderlich Empfohlen nicht erforderlich
OWA OA OAB
ECP EAS Autodiscover
EWS Adressbuch (RPC) POP3
RPC Powershell IMAP4

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 leider "dynamische" 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 unterscheiden

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.

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.

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

Weitere Links

Keywords:NLB ReverseProxy Loadbalancer Accelerator