Hardware Load-Balancer

Beachten Sie dazu auch die Aufzeichnung eines WebCast vom Mail 2014 auf WebCast LB und HA.

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

  • Wir kann die Last für den jeweiligen Dienst verteilt werden ?
    Muss es ein Loadbalancer sein oder ist z.B. DNS RoundRobin möglich (billiger und einfacher)
  • Gibt es bessere Optionen einen Dienst hochverfügbar zu machen
    z.B. NLB, Windows Cluster oder IP-Failover
  • Wie wird der Loadbalancer im LAN integriert
    Er kann z.B. wie ein Router eingesetzt werden oder als "Proxy"
  • Affinity, Stickyness, Persistence
    Welche Anforderung hat die Anwendung und der Client (z.B. Terminal Server, Reverse Proxy) damit die Anfragen sinnvoll verteilt werden und Besonderheiten von parallele Verbindungen berücksichtigt werden. Und welche Anforderungen haben Sie als Administrator ?. Wenn viele Clients sich hinter der gleichen IP-Adresse verbergen, dann muss der Loadbalancer ein anderes Kriterium für die Zuordnung der Verbindungen nutzen. Die SourceIP ist dann nicht ausreichend. Und das ist gar nicht so selten. Denken Sie mal an viele Benutzer auf dem gleichen TerminalServer mit Outlook. Oder an viele mobile Geräte "draußen", die über einen ReverseProxy umgesetzt werden, der seine interne IP als "SourceIP" nutzt. Und selbst dann sollten Sie wissen, dass z.B. alle Surfer im gleichen ICE hinter einem NAT-Router sitzen und mit der gleichen IP-Adresse bei ihnen ankommen. Mit der IPv4-Knappheit werden auch immer mehr Provider ihren Kunden "private Adressen" geben und diese per NAT umzusetzen.
  • SSL Offloading und Reverse Proxy
    Soll oder muss der LB vielleicht HTTPS und andere SSL-Protokolle auspacken um Last vom Backend zu nehmen oder anhand der Inhalte die Verteilung zu optimieren ?
  • SourceNat, 65535 Port Problem, Direct Server Return
    Wie setzt der LB die Pakete um, damit der Dienst dahinter korrekt antwortet. Wenn der LB als "Client" auftritt, dann könnten viele Verbindungen die Ports aufbrauchen. Was meint ihre Firewall dazu, wenn Pakete vom Server am LB vorbei mit einer anderen IP-Adresse zum Client zurück gehen ?
  • Mehrere Dienste im gleiche Subnetz
    Wie gehen Sie mit den Besonderheiten um, wenn zwei Dienste per Loadbalancer verteilt werden aber miteinander sprechen müssen. Wie kommt z.B. ein Lync Server zum OWC-Server oder ein Sharepoint zum  Exchange Server (EWS), wenn beide Dienste im gleichen Subnetz sind ?
  • Logging der Source Adresse
    Abhängig von der Art der Einbindung des LB kann der eigentliche Server die IP-Adresse des realen Client sehen oder eben nicht. Welche Transparenz brauchen Sie hier z.B. für Fehlersuche, Accounting etc?
  • Monitoring
    Wir überwachen Sie die Funktion des oder der Loadbalancer und vor allem auch der Dienste dahinter, damit ein Ausfall auch "erkannt" wird, ehe er größere Kreise zieht ?
  • Sizing
    Wissen Sie, welche Dienste wie intensiv genutzt werden, um den "richtigen" LB vorzusehen ?

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

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:

  • Reverse-NAT, Reverse Proxy, Routing
    Ein Teil der Load Balancer funktioniert so, dass die Clients per DNS auf die IP-Adresse des Load-Balancer statt der eigentlichen Server geleitet werden. Dieses System nimmt dann die Anfragen an und gibt sie weiter. Das ist ein ganz üblicher Prozess bei der z.B. Veröffentlichung von Webseiten. Auch hier muss man sich natürlich Gedanken machen, wie der Zugriff auf den Load-Balancer selbst "hochverfügbar" gestaltet werden kann.
    Andere Systeme sind für den Client gar nicht real sichtbar, sondern sind eher wie ein "Router" zwischen Client und Backend angesiedelt und nutzen daher Routingprotokolle, um Clientzugriffe bei Ausfällen um zu routen. Vorteil ist hierbei auch, dass z.B. DNS-Einträge durch die eigentlichen Server nicht umgebaut werden müssen. Allerdings wird ihr Netzwerk komplexer da Clients und Server eben getrennt sein müssen.
  • Test der Backends
    Ein Load Balancer sollte immer wissen, welcher der Systeme, die er veröffentlicht, gerade "funktionieren". Verteilen kann er die last nur, wenn es mehrere Systeme im Hintergrund gibt. Diese werden aber auch immer mal mit Patches versehen oder zur anderen Wartungsarbeiten außer Betrieb genommen. Manchmal wird auch ein System auf eine neue Version aktualisiert und erst mal getestet, ehe es produktiv geht. Ein einfacher "Ping" ist als Test sicher nicht ausreichend. Das System sollte schon auf dem Level der Applikation selbst prüfen können, ob der Server korrekt arbeitet. für MAPI kann das z.B. der Port sein, auf den Sie MAPI auf dem Server fixiert haben.

    Kemp prüft dann z.B. alle 10 Sekunden die Erreichbarkeit des Ports. Andere Prüfungen (z.B. POP3, SMTP, HTTP etc. sind für die anderen CAS-Dienste natürlich sinnvoll.
  • Affinität und Persistence
    Je nach Anwendung müssen "Sitzungen" gepflegt werden. Wenn sich z.B. ein Client an einem Webserver anmeldet und die Anmeldedaten dann z.B. an der Session oder Cookies festgemacht sind, dann sollte der Load Balancer jede Folgeanfrage des Clients natürlich an den gleichen Server senden. Ansonsten könnte es sein, dass der Anwender sich immer wieder anmelden muss und zudem kostet es einfach viel mehr Ressourcen, wenn mehrere Backends die gleichen Sitzungen erstellen müssen. Anders ist es bei anonymen statischen Daten wie z.B. Bildern, Stylesheets, Downloads. Hier kann der Load Balancer wieder den Server mit der geringsten Last wählen. Das kann er natürlich nur, wenn er so weit ins Protokoll rein schauen kann, um diese unterschiede zu erkennen. für andere Protokolle (z. B. RDP, SMTP , POP etc.) gelten natürlich wieder andere Regeln. Hier eine Auswahl der möglichen Kriterien beim Einsatz eines HTTP-Protokolls und der Verteil-Optionen (Kemp LM2200 Version 5.1.45.

    Gerade wer auch andere Protokolle (z.B. MAPI) verteilt, muss damit rechnen, dass neben einen Port noch andere dazu kommen. Bei MAPI ist das nämlich 135 (RPC Portmapper) und dann noch ein Port für den Store und einer für den Adressbuchdienst. Entsprechend muss der Loadbalancer diese Pakete vom Client an den gleichen CAS senden, wie die erste Verbindung:
    Bei Kemp wird auf dem virtuellen Server der Port 135 definiert und dann die Zusatzports als "Extra Ports"
  • Idle Timeout
    Das Verwalten von Sessions kostet natürlich Ressourcen. Daher haben viele Loadbalancer einen Müllmann, der Sessions nach einiger Zeit Inaktivität killt. Bei Kemp ist dies je virtuellem Server einstellbar

    Der Wert 0 deaktiviert diese Aufräumaktion. Wer hier denkt, dass eine TCP-Session ja in der Regel nicht länger als 2 Minuten inaktiv ist und daher 2,1 Minuten einstellt, wird sehen, dass Outlook alle 2 Minuten einen Reconnect macht. Wer den Timeout nicht deaktivieren will, sollte ihn ausreichend hoch setzen und dabei auch die ActiveSync-Geräte nicht vergessen, die sehr lange "Idle" sein können.
    2535656 Troubleshooting long running MAPI connections to Exchange Server 2010 through Network Load Balancers
  • Firewall und Filter, Offloading und Kompression
    Wenn der Load Balancer schon die Verbindungen annimmt, dann kann er auch eine Validierung der übertragenen Daten durchführen. Einige Load Balancer gehen sogar so weit, dass Sie als Application Firewall agieren und URLs filtern und teilweise sogar eine Vorauthentifizierung übernehmen, um die aktiven Server vor Angriffen zu schützen. Sie können sogar SSL-Offloading betreiben und HTTP-Komprimierungen durchführen, und damit die Backend Server weiter entlasten.
  • Geografische Optimierung (DNS, Rerouting)
    Interessant wird es, wenn sie mehrere Server an verschiedenen Orten betreiben und die Anfragen durch einen Load Balancer so umgeleitet werden, dass der Client zum netztechnisch nächsten Server geroutet werden. Diverse intelligente Systeme optimieren dazu die DNS-Antworten abhängig von der anfragenden IP-Adresse (was meist passt, auch wenn der DNS des Providers nur bedingt über den Client etwas aussagt). Andere Systeme nehmen die Anfrage an um den Client dann aber einen Redirect (geht z.B. bei HTTP sehr elegant) auf einen andere Server zu lenken. So kann man auch Last zwischen Server "verteilen" und sogar geografisch optimieren.
  • Load Balancer und HA
    Verteilen ist nur eine Aufgabenstellung. Natürlich sollte auch die Lastverteilung "Hochverfügbar" erfolgen. Und hier stehen die Hersteller vor dem gleichen Dilemma wie ein Windows Admin mit NLB. Entweder mehrere Load Balancer arbeiten aktiv nebeneinander, womit sich auch hier die Frage von  "Multicast IP" etc. stellt oder jedem System ist ein "Standby"-System zugeordnet, welches beim Ausfall die Arbeit (und die IP-Adresse) übernimmt. Dies kann abgewandelt auch mit mehreren IPs erfolgen, bei denen die IP-Adresse eines ausgefallenen Systems einem anderen Server zugeordnet wird. (Siehe auch MiniSFT). Nur die ganz teuren Systeme schaffen es auch die Sitzungstabelle zwischen zwei Systemen zu spiegeln und damit beim Ausfall wirklich ohne Unterbrechung weiter zu arbeiten.

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:

  • 1-Arm oder 2-Arm
    Bei der Implementierung müssen sie sich überlegen, ob der Loadbalancer mit einem Anschluss mit dem Netzwerk verbunden ist und der Datenverkehr von Client über den LB zum Server über das gleiche Subnetz läuft. dann muss der LB die MAC/IP-Adressen NATten. Wird der LB aber wie ein "Router" in das Netzwerk eingebunden, bei dem die Clients auf einer Seite und die Server auf der anderen Seite laufen, dann bedeutet das eine Änderung ihres Netzwerkroutings und Einschränkungen beim Zugriff aus dem Server-LAN, quasi von "innen"
  • Grenzen von NAT bei 1-Arm
    Wenn nun ein Client eine Anfrage an einen Loadbalancer stellt, und die Anfrage von dort an einen Server weiter gegeben wird, dann muss der Loadbalancer als Source-Adresse natürlich seine eigene Adresse verwenden, damit die Antwort wieder über ihn an den Client ausgeliefert wird. Eine IP-Adresse kann aber maximal 65535 Ports "offen" haben, so dass ein Loadbalancer also maximal diese Anzahl an gleichzeitigen Verbindungen aufbauen kann.
    Siehe auch 65535 Port-Limit
  • Affinity mit NAT beim Client
    Wenn Sie dem Loadbalancer sagen, das er abhängig von der Quell-IP des Clients die Affinität zu einem Server im Backend aufbauen soll, dann wird das Problematik, wenn viele Clients sicher hinter einer IP-Adresse oder einem Firmenproxy verbergen. für den Loadbalancer ist das dann "ein" Client, der auf dem einen Server landet. So ist es auch nicht unüblich, dass z.B. mobile Anwender per UMTS/GSM über einen Proxy bzw. NAT arbeiten und im UMTS-Netzwerk eine "Private" Adresse verwendet wird, die dann zum Internet umgesetzt wird. So eine "Lastverteilung" ist nicht mehr ausgeglichen.
  • Cookie-Trouble und Affinity
    Viele Anwendungen erfordern, dass eine Sitzung eines Clients auch immer auf den gleichen Webserver landet. Damit spart man sich mehrere Sessions auf verschiedenen Server, die zum einen eine extra Anmeldung bedeuten kann aber vor allem unnötig Ressourcen frisst. Dazu eignen sich z.B. Cookies. Voraussetzung ist aber, dass der Loadbalancer den SSL-Traffic aufbricht um die Inhalte zu sehen und dass Sie natürlich den Namen des Cookie benennen können.
  • Failover
    Ein LB kann natürlich die Anfragen an ein oder mehrere Server im Backend weiter geben, aber wer sichert den LB ab?. Sicher sind zwei Systeme schnell installiert, aber was passiert im Fehlerfall? Hat das übernehmende System auch den Status der aktuellen Verbindungen oder fliegen alle Clients erst einmal raus ?. Und wie "übernimmt" er die Dienste des anderen Systems ?. Übernimmt er einfach nur die IP-Adresse oder zieht er auch eine virtuelle MAC-Adresse an sich.
  • Failover des Backends
    Es kann ja nicht nur der Loadbalancer ausfallen, sondern eine Funktion ist ja auch, dass er Ausfälle beim Backend erkennt und die neuen Anfragen an einen "verfügbaren" Server weitergibt. Über regelmäßige Tests kann der LB erkennen, ob der Dienst im Backend verfügbar ist. Hier muss der LB natürlich alle "verbundenen Ports" betrachten. Es reicht für MAPI z.B. nicht aus, nur den Port 135 zu überwachen. Wenn man die Ports für den Store und den Adressbuchdienst fixiert ha, sollte der LB auch diese überwachen und beim Fehler eines Ports auch alle Sessions der Portgruppe zurück setzen.

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

  • Authentifizierung
    Es gibt Anwendungen, die diese doppelte Umsetzung nicht tolerieren. Oft kann z.B.: NTLM nicht aus Anmeldeverfahren an einem Webserver genutzt werden, wenn die Adressen doppelt umgesetzt werden. Werden die Daten allerdings in einem SSL-Strom versteckt, dann funktioniert es wieder.
  • IP-Adresslogging
    Wenn der Backend-Server nur noch die IP-Adresse des Loadbalancer oder Reverse Proxy sieht, dann kann die Anwendung nicht mehr anhand der Client-IP unterschiedlich reagieren. Das betrifft

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

  • Mehrere Subnetze
    Wenn der Loadbalancer als Router arbeitet, dann müssen Sie natürlich auch was zu "routen" haben. Wie werden also weitere Subnetze, VLANs und Netzwerkkarten konfigurieren müssen
  • Keine Client im gleichen Subnetz
    Ein Client im gleichen Subnetz kann das Array von Backend Servern dann auch nicht erreichen, da der Server diese Antwortpakete nicht über den LB zurück senden wird. Das ist faktisch also das Aus für Blackberry, Faxserver etc. im gleichen Subnetz.
  • Fremdtraffic auf dem LB
    Wenn die BackendServer nicht noch weitere Netzwerkkarten "hinten herum" haben, dann wird jeder Zugriff auf den Server und vom Server in andere Subnetze durch den LB geroutet. Bedenken Sie dies z.B. beim Thema Backup, Monitoring, RDP-Zugriff etc.

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. ActiveSync oder Lync Mobile, die mit Exchange 2010 eine Affinität benötigen. Dort war die "Client-IP" nicht ausreichend als Kriterium. Ohne Layer7 gab es Funktionseinschränkungen. Das Trifft für Exchange 2013 und höher nicht mehr zu.

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 Round-Robin 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:

  • ICMP
    Ein einfacher "PING" auf das Backend ist der billigste aber auch schwächste Test. Natürlich müssen Sie ICMP auf dem Backend erst mal zulassen (Windows Firewall) aber eine qualitative Aussage zur Erreichbarkeit der Dienste ist auch das nicht
  • TCP-Port
    Etwas besser ist hier die Überprüfung, ob der zu erreichende Port auch reagiert. Ein Loadbalancer kann recht einfach einen TCP-Connect (3-Wege-Handshake) initiieren und die Verbindung dann wieder abbauen. Damit ist zumindest sicher, dass der Port reagiert, was aber noch nichts über die Funktion aussagt. Nur weil in IIS auf Port 443 lauscht, ist nicht die Funktion der Webapplikation garantiert.
    Zudem gibt es Dienste die mehrere Ports benutzen (135, ExchangeAB, ExchangeIS). Hier muss eine Verifikation alle Ports prüfen. Und hoffentlich sind diese dann statisch, da ansonsten noch die RPC-Antwort ausgewertet werden müsste.
  • Synthetische Transaktion (SMTP/POP/HTTP/RDP etc.)
    Einige LB können noch mehr als nur TCP-Ports zu proben. Wenn Sie das verwendete Protokoll können, können Sie auch eine Verbindung beginnen. Das kann ein SMTP-HELO mit nachfolgendem QUIT sein, die Überprüfung eines POP3-Headers oder sogar HTTP-Anfragen mit einem Check der übergebenen Webseiteninhalten. Damit bekommen Sie schon sehr gut ermittelt, wenn der Dienst nicht mehr verfügbar ist
  • Aktives Monitoring
    Die Königsfunktion ist natürlich eine aktive Überprüfung der Dienste z.B. mit einem Skript auf dem Server, welches zyklisch oder z.B. als ASPX-Seite ausgeführt wird und einen Status an den LB zurück gibt. Dieser Status könnte sogar die aktuelle Auslastung (numerisch) wiedergeben, so dass der LB neue Verbindungen an das System gibt, das am wenigsten Last hat.

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

Ein Loadbalancer wird auch gerne genutzt, um den Dienst "SMTP Empfang" hochverfügbar zu machen. Sie können ja mehrere Exchange Server nebeneinander aufbauen, die alle Mails per SMTP annehmen. Legitime Absender sind z.B. Scan2Mail-Geräte aber auch Storage-Systeme, ERP-Systeme etc, die ihr Mails zu Exchange einliefern und teilweise sogar über Exchange in das Internet weiter leiten. nicht alle Systeme können sich dabei "Authentifizieren", so dass die IP-Adresse oft als Schlüssel benötigt wird. Damit kommt natürlich auch die Integration des Loadbalancers eine gewichtige Rolle, denn je nach Betriebsart kann der Exchange Server die Source-IP gar nicht mehr sehen. Denn anders als bei HTTP-Anfragen, bei der ein Loadbalancer mit SSL-Offloading die Client-IP als HTTP-Header (Proxy-Via) addieren kann, geht das bei SMTP nicht. Der Exchange Receive Connector wertet die Verbindung beim "Connect" aus um die passende Konfiguration anzuwenden.

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

Wer also z.B. unterschiedliche Receive Connectoren einsetzen möchte, um nach "Anonym Relay" und "Anonym Accept" anhand der SourceIP zu unterscheiden, dann muss der Loadbalancer als "Dual-Arm" installiert sein und die Exchange Server senden alle Antworten über den Loadbalancer als Default Gateway zurück.

Wenn Sie eine Single-Arm Anbindung wählen, dann sieht Exchange die Source IP nicht, aber sie können natürlich nun auf dem Loadbalancer für jeden Conector quasi einen eigenen virtuellen Service mit einer eigenen IP-Adresse erstellen und diese dann auf verschiedene IP-Adressen oder Ports zum Exchange weiter geben. Die "Filterung", welcher Client dann welchen Exchange Connector erreichen kann, müssen Sie dann natürlich auf dem Loadbalancer oder einer Firewall einrichten. Auf dem Exchange Server können Sie zur Sicherheit die zusätzlichen Connectoren auf die Quell-IP des Loadbalancer setzen. Sie sollten aber die Finger vom "Default Connector" lassen und hier insbesondere keine IP-Beschränkungen einsetzen, die die Kommunikation zwischen den Exchange Servern stören könnte.

Exchange kann pro Client IP bestimmte Dienste drosseln. Dies betrifft insbesondere die Receive Connectoren, die in der Regel die Zugriffe von Client begrenzen. 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 für 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:

  • Load Balancer für WebServices
    Da Lync per DNS Round Robin schon Clients verteilen kann, können die DNS Einträge für den Pool auf die IPs der Server verweisen. Die Webservice URL muss aber auf den Loadbalancer verweisen was einen zusätzlichen Hostnamen (samt Zertifikat) bedeutet, da der Poolname ja auf die Server direkt verweist.
  • Load Balancer für ALLES
    Dieser Weg bedeutet natürlich mehr Last für den Loadbalancer aber erlaubt auch Clients einen hochverfügbaren Zugriff, die nicht mit DNS-Round Robin umgehen können. Die Pool-IP verweist dann auf den LB, welcher nun nicht nur 5061 (SIP/TLS) sondern eine ganze Menge von Ports bedienen muss, z.B. auch eventuell als Colocation installierte Mediation Server, Konferenz-Server, Response Groups.

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.

MS Lync 2013 Deployment Guide
http://kemptechnologies.com/files/downloads/documentation/7.0/Deployment_Guides/Deployment_Guide-MS_Lync_2013.pdf

MEX 2014 Session Load Balancing Exchange and Lync Server 2013
http://video.ch9.ms/sessions/mec/2014/DMI308_Shukla.pptx

Load Balancer und Skype für Business

Viel hat sich gegenüber Lync 2013 nicht geändert. Da war der Wechsel von Lync 2010 auf 2013 schon größer, da mit Lync 2013 mit den passenden Clients viel mit DNS Round Robin möglich ist und die WebDienste (LyncWeb) noch verteilt werden müssen. Das ist mit Skype für Business unverändert beibehalten worden

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

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:

  • SSL Transactions /Sek
    Diese Zahl ist relevant, wenn der Load Balancer den Port 443 nicht einfach auf TCP (Layer 4-Ebene) an ein Farmmitglied weiter gibt, sondern selbst das SSL-Zertifikat enthält und die SSL-Verbindung bedient. Wer also den Loadbalancer noch zum "SSL-Offloading" verwenden um die Webserver im Hintergrund die Verschlüsselung abzunehmen, der muss auf diesen Wert schauen. Wobei Kemp hier den "Verbindungsaufbau" meint, d.h. den Austausch der Schlüssel. Die eigentliche Übertragung per SSL ist nicht mehr kritisch. Der "kleine" kann also maximal 200 SSL-Verbindungen pro Sekunden "aufbauen". Halten und bedienen kann er mehr.
  • HTTP Requests/Sec
    Dies ist dann der relevante Counter für die tatsächlich zu verarbeitenden HTTP/HTTPS Lasten (GET/POST/PUT etc). Diese Zahl können Sie idealerweise an einer bestehenden Umgebung aus den IISLogs ermitteln. Bei Kemp sind das die Anzahl der Anfragen, die über bestehende Verbindungen auf Layer 7 bedient werden können.
  • Layer 4 Concurrent Connections
    Dieser Counter beschreibt, wie viele "Verbindungen" das System verwalten kann. Das ist durchaus relevant, da eine TCP-Connection normalerweise bis zu 2 Minuten nach dem letzten Paket "besteht", bei ActiveSync-Verbindungen sogar noch länger. Und wenn der Client "dumm" ist und eine TCP-Verbindung nicht erneut verwendet, könnte dieser z.B. 10 http-Requests pro Sekunde mit immer neuen TCP-Verbindungen senden und letztlich dann bis zu 120 Connections "belegen". Eine hohe Zahl hier macht auch DoS-Attacken schwerer. Anwendungen wie ActiveSync halten Verbindungen sehr lange.
    Dieses Wert können Sie am besten über PERFMON erfragen, wobei es da natürlich auch auf die Maximalwerte ankommt.
  • Durchsatz.
    Auch wenn die meisten Systeme schon mit Gigabit ausgestattet sind und die Internetanbindungen deutlich darunter liegen, so werden immer mehr Loadbalancer auch intern eingesetzt. Dann macht die maximale Bandbreite doch wieder Sinn.

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.

  • Logfiles der Anwendung (IISLog, POP3Log, IMAP4Log, SMTPLog o.ä.)
    Dort protokolliert z.B. ein Webserver jeden einzelnen Request mit Zeitstempel, Größe und Quell-IP. Ideale Quelle um die Anfragen pro Sekunde zu ermitteln und auch die Datenmenge sowohl als Mittelwert als auch die Spitzenwerte zu erhalten. Gerade die Auswertung des IIS-Logs ist mit diversen Programmen (z.B. LogParser) sehr nett machbar.
  • Performancecounter/SNMP
    Über diese Counter können Sie sowohl die Netzwerkauslastung (allerdings nur allgemein) und die offenen TCP-Ports ermitteln. Perfmon oder auch Tools wie PRTG und andere können hier weiter helfen.

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 ARR

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

  • Reverse Proxy gibt die Client IP als Source weiter
    Wenn der Proxy davor die Pakete nicht mit seiner IP-Adresse sondern weiter mit der originären Adresse des Clients an den LB weiter leitet, dann kann dieser weiterhin anhand der "Source-IP" die Daten verteilen. Erforderlich ist dann aber, dass der LB als "Default Gateway" die Pakete wieder an den Proxy leitet, damit er diese zum Client passend umsetzen kann. Das kann kniffliger werden, wenn der LB sowohl Zugriffe aus dem Internet als auch dem internen LAN bedienen soll
  • Reverse Proxy macht selbst die Lastverteilung
    Diverse Firewalls haben selbst Mechanismen zur Lastverteilung bestimmter Dienste. So kann ein TMG2010/ISA2006-Server z.B. HTTP auf eine "Webfarm" weitergeben und so selbst Verfügbarkeit und Lastverteilung hoch halten. Allerdings kann gerade der TMG2010/ISA2006 dies leider auch nur für HTTP/HTTPS aber nicht für SMTP, POP, IMAP und andere Protokolle.
  • Load Balancer nutzt anderes Verteilverfahren, z.B. Cookies
    Der LB muss sich nicht auf die SourceIP-Adresse als einziges Kriterium stützen. Wenn er z.B. ein SSL-Offloading unterstützt, dann kann er auch in den HTTPS-Datenstrom reinschauen und z.B.: Anhand Anmeldedaten, Sitzungscookies o.ä. die Zugriffe wiedererkennen und zuordnen. Dies ist ratsam, wenn man nicht nur den CAS-Server entlasten will, sondern der LB auch noch Schadcode abwehren kann oder viele Clients sich hinter wenigen IP-Adressen (NAT) verbergen.

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.

  • Loopback
    Nur was soll ein Loadbalancer denn mit einem Client anfangen, der vom Exchange CAS den Loadbalancer fragt und das Paket direkt wieder zum CAS zurück gibt. Wenn Sie hier den Loadbalancer nur "als Layer4-Router" betreiben, dann wird der CAS sich selbst antworten und keine Verbindung zustande kommen. Es gibt noch weitere Fälle. Wenn der Loadbalancer z.B. als ReverseProxy oder SNAT/DNAT arbeitet kann so ein Test funktionieren.
  • Real_Server-Test
    Weiterhin hilft es für die Überwachung wenig, wenn eine Probe den Clusternamen nutzt, hinter dem sich dann 5 CAS-Server verbergen. Der Ausfall des ein oder anderen Servers kann der Loadbalancer einfach "verbergen" und die Überwachung hat noch nichts bemerkt. Ratsam ist hier also, dass der physikalische Servername geprüft wird oder der Status des Loadbalancers mit integriert wird.

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.

Deploy Kemp Loadbalancer in Azure
http://player.vimeo.com/video/86310994

Weitere Links