MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Loadbalancing Grundlagen

Wer zwei oder mehr Exchange Server, WebServer, Mailserver o.ä. betreibt, muss sich über die Verteilung der Zugriffe, die Ausfallsicherheit aber auch Skalierung Gedanken machen. Es gibt viele Optionen und diese Seite soll einen Einstieg geben.

Verfügbarkeit und Lastverteilung

Sobald mehrere Server die gleiche Aufgabe übernehmen, kommt die Frage, wie die Client eigentlich den richtigen Server erreichen. Da gibt es zwei Gründe:

  • Verfügbarkeit
    Wenn ich mehrere Server habe und mir einer ausfällt oder er aktualisiert werden muss, dann muss ich sicherstellen, dass die Clients sich nicht mehr mit dem Server verbinden. Natürlich kann ich einem Client per DNS auch mehrere IP-Adressen auf einen Namen liefern und darauf hoffen, dass der Client bei einem Fehler die nächste Adresse versucht. Das machen aber viele Clients nicht und führt zu Verzögerungen. Ein DNS-Name funktioniert auch nicht, wenn die Software explizit eine IP-Adresse direkt ansprechen will.
  • Lastverteilung
    Die zweite Anforderung ist eine faire Verteilung der Zugriffe auf die verfügbaren Server. Wäre es nicht schön, wenn etwas den Gesundheitsstatus der Dienste auf einem Server abfragt und neue Anfragen entsprechend an den Server verteilt, der am wenigsten belastet ist? Ein weiterer Aspekt ist eine Verteilung nach Netzwerkstandort, z.B. dass ein Client immer den netztechnisch naheliegenden Service nutzt.

Die beiden Dinge hängen zusammen, denn genaugenommen ist ein Ausfall mit einem "unendlich hoch belasteten" Server zu vergleichen, der keine Anfragen mehr bekommen sollte. Je nach eingesetzer Technik kann die Lösung auch noch die TLS-Verschlüsselung übernehmen oder eingehende Anfragen auf Plausibilität und Angriffsmuster prüfen oder eine Preauthentifizierung des Clients machen. Loadbalancing kann also viel mehr sein, als nur etwas Verkehr zu leiten. Weiterhin sollten Sie überlegen, ob das verwendete Protokoll überhaupt eine erweiterter Hochverfügbarkeit braucht. Mailserver, die sich untereinander per MX-Record finden und Mails senden, sind per Definition auf mehrere MX-Records vorbereitet und können problemlos mit einen nicht erreichbaren Server umgehen. Hier brauchen Sie kein Loadbalancing. Viele andere Protokolle habe ähnliche Techniken eingebaut. Aber nur weil Mailserver per SMTP und MX-Record arbeiten, bedeutet dies ja nicht, dass auch Clients und z.B. "Send-MailMessage" oder "Blat", Scan2Mail-Geräte oder andere Versender selbständig einen alternativen Mailserver nutzen. Diese erwarte einfach, dass hinter einem Namen, notfalls auch einer IP-Adresse, der Service erreichbar ist.

Ich kenne mindesten sechs verschiedene Varianten, die Zugriffe eines Clients auf mehrere Server aufzuteilen. Wir nehmen zwei Exchange Server, die unter einen Namen "mail.msxfaq.de" erreichbar sein sollen und wir wollen die Clients auf beide Server verteilen. Die beiden Server sind dazu identisch konfiguriert, d.h. gleiche Rollen, gleiche Dienste, gleiche Zertifikate aber haben natürlich unterschiedliche IP-Adressen und Servernamen. Begeben wir uns auf die Reise.

In den folgenden Abschnitten verwende ich folgende IP-Adressen:

IP-A    IP-Adresse eines anfragenden Clients
IP-VIP  virtuelle IP-Adresse des angesprochenen Service
IP-LB   Reale IP des Loadbalancers, mit der eigene Pakete sendet
IP-1    IP eines Real-Server
IP-2    IP eines Real-Server

Microsoft Failover Cluster IP

Für den Betrieb eines Exchange Clusters wird im Unterbau ein Microsoft Cluster konfiguriert. Dieser Cluster hat aber normalerweise keine IP-Adressen (IP-Less Cluster) und auch keine gemeinsamen Cluster-Disks. Exchange nutzt einfach die Cluster-APIs, um seine AG zu formen. Allerdings könnten Sie dem Cluster auch eine IP-Adresse geben, die dann auf einem Knoten aktiv ist. Fällt der Knoten aus, dann schwenkt die IP-Adresse auf den anderen Knoten und die Clients können sich kurz danach wieder anmelden.

Technisch ist dies kaum ein Mehraufwand aber sie sehen sicher, wo die größte Einschränkung ist. Die Clients verbinden sich mit der IP-Adresse und landen alle auf dem gleichen Server, die quasi die ganze Arbeit macht. Sicher können Sie bei Exchange dann die Mailboxdatenbanken auf die anderen Server verteilen aber es ist schon eine "Spar-Hochverfügbarkeit".

Früher was Microsoft Failover Cluster nicht Bestandteil der Windows Standard Version. Es musste Windows Enterprise oder Datacenter sein. Zu der Zeit hatte ich mir per Skript eine eigene Lösung gebaut. Auf jedem Knoten lief ein Skript, welches per PING o.ä. die Erreichbarkeit der anderen Seite geprüft hat. War der andere Server nicht mehr erreichbar, habe ich die IP-Adresse des anderen Servers auf den anscheinend überlebenden Konten aktiviert. Dafür gibt es heute keinen Bedarf mehr

Windows Network Load Balancing NLB

Ähnliches gilt für den Netzwerklastenausgleich, den Windows mit dem Namen "NLB" als Feature bereitstellt. Hier haben mehrere Server einfach die gleiche IP-Adresse und alle Server bekommen alle anfragen. Im Netzwerk muss hier insbesondere der Switch mitspielen (Stichwort Multicast MAC) oder das Netzwerk segmentiert sein. Jeder Server pickt sich dann die Pakete heraus, die von ihm bearbeitet werden sollen. Die NLB-Knoten nutzen dazu z.B. einen aus MAC-Adresse oder IP-Adresse des Clients gebildeten Hashwert, den sie dann durch die Anzahl der aktiven NLB-Mitglieder teilen.

Ich habe NLB immer als "Loadbalancer des armen Mannes" bezeichnet, denn die Lastverteilung ist relativ statisch und mit wenigen Clients ist sie unausgewogen. NLB kann auch nicht mit MSCluster kombiniert werden, so dass dies für eine 2-ExchangeServer-DAG keine Option ist. Aber für einfache Webserver kann NLB durchaus eine Lösung sein.

DNS Round Robin

Viele Administratoren starten dann mit DNS Round Robin. Für den Namen "mail.msxfaq.de" legen wir einfach zwei A-Records im DNS an und jeder Client bekommt bei einer Anfrage die beiden IP-Adressen geliefert und sucht sich eine Adresse aus. Solange beide Server aktiv sind, haben Sie eine schöne Lastverteilung. Auch hier ist die Last umso ausgeglichener, je mehr Clients parallel arbeiten. Die Verteilung nimmt aber z.B. keine Rücksicht auf die aktuelle Auslastung der Server. Der einfache DNS-Server kennt die Server ja nicht und fragt diese auch nicht ab.

Interessant wird es beim Ausfall oder einer geplanten Wartung. Bei einer geplanten Wartung kann ich als Administrator z.B. dein Eintrag im DNS temporär löschen. Die Clients finden dann nur noch den anderen Server und mein zweiter Server wird nicht mehr genutzt. Beim ungeplanten Ausfall verbinden sich aber 50% der Clients erst einmal mit einer IP-Adresse, hinter kein Service mehr verfügbar ist. Der TCP-Handshake läuft auf einen Timeout. Je nach Client dauert das länger, bis der Client erneut eine Namensauflösung macht oder direkt eine weitere IP-Adresse versucht. Dieser Zustand bleibt auch so erhalten, bis der Server wieder online ist.

Die Anwender sehen dabei entweder eine nicht mehr reagierende Applikation, eine Sanduhr oder temporäre Fehlermeldungen, die auch wieder verschwinden. Solche Tickets sind sehr schwer zu analysieren und das sollte eine Erinnerung sein, dass ein hochverfügbares System nur so gut ist wie die Überwachung der Einzelkomponenten. Outlook kann übrigens relativ gut mit DNS Round Robin umgehen, insbesondere wenn es im Cache-Mode arbeitet und daher eine temporär unterbrochene Verbindung zum Exchange Server den Anwender selten auffällt.

DNS Loadbalancing

Die Schwächen von DNS Round Robin können wir aber mit einer Software lösen. Es gibt DNS-Dienste, die aktiv den Status von Servern abfragen und nur die IP-Adressen der erreichbaren Server zurückgeben. Diese Funktion ist in einem klassischen "Load Balancer" oft enthalten. Der DNS-Server für die Zone "msxfaq.de" hat dann keinen "A-Eintrag" für den Host "mail", sondern einen NS-Eintrag, um eine Zone "mail.msxfaq.de" auf eben diesen Loadbalancer zu delegieren.

Der Client fragt dann den DNS-Server für "msxfaq.de" nach dem Host "mail.msxfaq.de" und bekommt die Antwort, dass er bitte bei einem anderen DNS-Server nachfragen soll. Der Client geht dann zu diesem anderen Server, der die IP-Adresse eines funktionierenden und wenig belasteten Servers zurückgibt. Über einen kurzen TimeToLive (TTL) können Sie auch schnell auf veränderte Bedingungen reagieren.

Theoretisch könnten sich auch einfach den Windows DNS-Server nutzen und per PowerShell o.ä. den Status der Server im Backend jede Sekunde prüfen und die A-Records in der Zone entsprechend anpassen. Allerdings wäre eine Statusänderung immer auch eine DNS-Änderung mit Zonen-Replikation und Hochzählen der Seriennummer. Denkbar aber vielleicht nicht zielführend.

Single Arm LB

Bei allen bisher beschriebenen Optionen verbindet sich der Client aber direkt mit dem Server. Mit einem Loadbalancer ändert sich das Verhalten, wenn der Client den Namen auflöst und bei einem in sich hochverfügbaren System landet. Dieses System prüft kontinuierlich die realen Server auf ihre Verfügbarkeit und gibt dann die Verbindung entsprechend weiter. Wenn der Loadbalancer dabei nur mit einem Anschluss im Netz hängt, dann sprechen wir von einem "Single Arm"- oder "Single Leg"-Loadbalancer. Diese Konfiguration ist aus Netzwerksicht einfach zu implementieren, da der Loadbalancer keine Routing-Funktion übernimmt. Dabei passiert folgendes

  1. Client-A löst den Namen des Service und bekommt eine IP-Adresse "NLB-A" zurück
  2. Client-A sendet ein Paket an NLB-A
  3. Der NLB leitet das Paket nun mit seiner IP-Adresse "NLB-A" an z.B. Server-1 weiter
  4. Server 1 antwortet mit einem Paket von Server-1 an NLB-A
  5. Der Loadbalancer setzt das Paket wieder um mit NLB-A als Quelle an Client-1

Der Loadbalancer muss also sowohl die Ziel-IP-Adresse als auch die Quell-IP-Adresse umsetzen.

Das Modell hat mehrere Einschränkungen

  • Die Server sehen nur NLB-A als Client
    In den IIS-Logs eines Webserver oder den SMTP-Logs sehen wir daher immer nur NLB-A, was die Analyse, Fehlersuche und Auswertungen fast unmöglich macht. Für das Protokoll HTTP kann der Loadbalancer mit einem "X-Forwarded-For"-Header die echten Client-Adressen mit übergeben aber bei SMTP, POP, IMAP,SIP und anderen Protokollen gibt es das nicht.
  • Source-IP-Limits mit 65535 Ports
    Der Loadbalancer kann mit seiner IP-Adresse NLB-A selbst maximal 65535 ausgehende Verbindungen aufbauen. Mit etwas Tricks gilt das Limit pro realem Server und natürlich können Sie dem Loadbalancer noch weitere IP-Adressen geben, um die Limits immer wieder anzuheben.

Der Single-Arm-LB hat natürlich den Vorteil, dass er ohne große Umbauten einfach in ein bestehendes Netzwerk integriert werden kann.

Dual Arm LB

Wenn der Loadbalancer zwischen den Clients und dem Server steht und sich quasi wie ein Router verhält und von den Servern als Default Gateway genutzt wird, dann kann der Loadbalancer die originale IP-Adresse der Clients an die realen Server senden. Antwortpakete der Server werden über die normale Funktion des TCP/IP-Stacks zum Loadbalancer zurück gesendet, der das Paket aber abfängt und die Absenderadresse des Servers wieder durch die IP-Adresse des Loadbalancers ersetzt. Der Client mehr nicht, dass er nicht direkt mit dem Server gesprochen hat.

Der wichtigsten Vorteil einer Dual Arm Konfiguration ist, dass der Server selbst die IP-Adresse des Clients sehen kann, so dass diese nicht nur in Protokollen erscheint, sondern auch in der Konfiguration genutzt werden kann. Dies gilt besonders für die Exchange Receive Connectoren. Wenn Sie als anhand der Quell-IP-Adresse eines einzelnen Computers z.B. ein Relay erlauben wollen, dann muss Exchange die IP-Adresse des Clients sehen. 

Direct Server Return

Eine Variante von Dual-Arm/Singe-Arm ist die Nutzung von "Direct Server Return". Das Paket geht erst zur virtuellen IP-Adresse des Loadbalancers, welcher die ZIel-Adresse auf einen realen Server umschreibt. Die Source-IP bleibt aber der originale Absender. Das Rückpaket geht aber nicht mehr durch den Loadbalancer, sondern dran vorbei. Damit so ein Paket aber auf dem Weg und beim Client akzeptiert wird, muss der Real-Server als Absenderadresse die virtuelle Adresse des Loadbalancers verwenden. Das geht, aber das Betriebssystem darf auf diese Adresse selbst nicht reagieren, d.h. keine ARP-Anfragen mit seiner MAC-Adresse beantworten.

 

Wichtig.
Der Client hat die LB-Adresse angesprochen und erwartet auch eine Antwort von der LB-Adresse. Alles andere ist asynchrones Routing und die meisten Firewalls blocken eingehende Pakete, zu denen es keine ausgehende Verbindung gibt.

Bei der Konfiguration kann der Loadbalancer vom Verkehr auf dem Rückweg entlastet werden. Viel interessanter ist, dass selbst mit einem Single-Arm-Setup der Real-Server die echte IP-Adresse des Clients sieht und diese protokollieren und für abweichende Konfigurationen verwenden kann.

Layer 4 oder Layer 7, Preauth, SSL Offloading

Alle bisherigen Verfahren basieren auf "Layer-4", d.h. auf dem TCP-Protokoll. Loadbalancer können aber noch mehr. Wenn ein Loadbalancer das verwendete Protokoll versteht, kann er dieses intelligenter umsetzen. Die meisten Loadbalancer verstehen z.B. sehr gut das HTTP-Protokoll. Ein Client verbindet sich wie gewohnt mit der IP-Adresse des Loadbalancers, der aber nun seinerseits ohne Mithilfe des Servers dahinter die Verbindung selbst annimmt. Der Loadbalancer  kann sogar ein Zertifikat für die Webseite besitzen und eine TLS-Verbindung herstellen. Der Client sendet seine HTTP/HTTPS-Anfragen dann an den Loadbalancer, der diese Entschlüsselt und sowohl die URL, den Header und die Payload sieht. Das eröffnet ganz neue Möglichkeiten

  • SSL-Offlload
    Wenn es der Server im Backend erlaubt, kann der Loadbalancer die Verschlüsselungsarbeit bei TLS dem Server abnehmen, indem die Verbindung vom LB zum Server unverschlüsselt erfolgt. Natürlich sollten Sie dann diesen Netzwerkabschnitt sauber von anderen Verbindungen separieren.
  • URL/Malware Filter
    Wenn der LB die Verbindung schon aufbricht, dann kann er auch den Inhalt prüfen und z.B. nur ausgewählte URLs erreichbar machen. Denken Sie an einen Exchange Server, der OWA für alle bereitstellt aber z.B. Zugriffe auf den Migration-Endpunkt (MRSPROXY.SVC) nur für Exchange Online erlaubt.
  • Rewriting
    Auch die Rückantworten kann der LB erkennen und umschreiben. Bei einfachen Webseiten kann man so sehr einfach z.B. Icons oder URLs ändern.
  • Preauthentication
    Das ist aus meiner Sicht der wichtigste Faktor. Sie sollten nie einen Exchange Server ohne starke Authentifizierung aus dem Internet erreichbar machen. von intern soll der Server aber weiter möglichst nahe am Standard sein. Daher könnten Sie externe Zugriffe über einen eigenen Virtual Service des Loadbalancer schon dort authentifizieren lassen. Der Loadbalancer kann DoS-Attacken, Password Guessing/Spray verhindern der auch MFA umsetzen. Erst wenn der Benutzer sich dort gültig angemeldet hat, reicht der Loadbalancer die folgenden Anfragen an einen internen Server weiter, sei es per Benutzername/Kennwort oder Kerberos - Constraint Delegation und Double Hop.
  • X-Forwarded-For
    Wenn ein Loadbalancer auf Layer-7 arbeitet, dann startet er eigene Verbindungen mit seiner IP-Adressen zu den realen Servern. Damit ein Server dennoch zumindest die Client-IP mit auswerten kann, erlaubten es quasi alle Loadbalancer die IP-Adresse des Clients als Header in den Request zum Server einzubetten. Meist wird das Feld X-Forwarded-For benannt und kann z.B. in den IISLOGS dann als eigene Spalte mit ausgegeben werden.
  • NTLM Enhanced Protection
    Beachten Sie dabei Exchange Extended Protection, IIS Extended Protection beim Einsatz mit NTLM. Hier müssen Server und LB das identische Zertifikat nutzen, damit NTLM nicht bricht

Diese Funktion fordert natürlich deutlich mehr Rechenleistung auf dem Loadbalancer und die Konfiguration ist aufwändiger. Die Vorteile sind aber nicht von der Hand zu weisen. Layer 7-Loadbalancing funktioniert natürlich nur, wenn der Loadbalancer das Protokoll versteht. Nach meinen Erfahrungen ist das immer nur HTTP/HTTPS. Für andere Protokolle wie LDAP, POP3, IMAP4, SMTP etc. bleibt es meist beim einfachen NAT mit Layer-4

Gegenüberstellung

Die folgende Tabelle ist natürlich nur sehr rudimentär:

Verfahren IP Failover mit
MCSC IP Failover oder MiniSFT		 Network Load Balancing (NLB) DNS Round Robin DNS Loadbalancing Hardware Load-Balancer

Brauchen wir eine zusätzliche Server/Aktive Komponente

Nein

Nein

Nein

Vielleicht

Ja

Verbindung Client<->Server

Direkt zum aktiven Knoten

Direkt

Direkt

Direkt

Über HLB als Router oder Proxy

Weiß die Verteilung, ob der Service auf dem Real-Server verfügbar ist?

Möglich

Nein

Nein

Möglich

Ja

Wie flexibel ist die Verteilung steuerbar?

Nein, Aktiv/Passiv

Source-IP

RoundRobin

flexibel

flexibel

Welchen Einfluss hat die Lösung auf die Netzwerkkomplexität?

Gering

Multicast/Broadcast.
Nicht immer einfach

Keine

Gering

Geänderte Routen oder Proxy

Verbindung im Fehlerfall

Neuaufbau

Neuaufbau

Neuaufbau
Aussetzer

Neuaufbau

Neuaufbau oder Transparent
Applikationsabhängig

Kosten

Gering

Gering

Gering

Mittel

Hoch

Ich denke, dass Sie anhand der Beschreibungen weiter oben schon ermessen können, welche Lösung für ihre Problemstellung geeignet ist.

Weitere Themen

Damit habe ich die häufigsten Aspekte für ein Load Balancing beschrieben und vielleicht können Sie nun besser abwägen, welches Loadbalancing für ihren Einsatzzweck richtig ist. Ein paar technische Aspekte möchte ich aber noch erwähnen

  • Affinität/Stickness
    Verbindungen von einem Client sollten idealerweise immer auf den gleichen Server gehen, da es dort dann schon eine Anmeldesitzung gibt. Gerade Browser machen ja gerne mehrere TCP-Verbindungen auf, die jede für sich authentifiziert werden muss. Wenn der Loadbalancer die Source-IP des Clients sieht, kann dies ein passendes Kriterium sein. Problematisch wird es, wenn sich dann viele Clients hinter der gleichen IP-Adresse verstecken.
  • TCP-Connection Start
    Viele Loadbalancer bauen eine Verbindung zu einem realen Server erst auf, wenn die ersten Daten eintrudeln. Damit spart sich der Loadbalancer etwas Arbeit, wenn Angreifer oder Applikationen nur eine Verbindung aufbauen und noch keine Daten senden. Das funktioniert immer dann gut, wenn das Protokoll mit Daten vom Client startet. Wenn das Protokoll aber direkt bei der Verbindung zum Server eine Reaktion erwartet, dann funktioniert dies nicht. SMTP ist so ein Fall, dass nach der Verbindung der Server mit einer "220 Hallo"-Meldung dem Client antwortet. Das muss auf dem Loadbalancer entsprechend eingestellt werden.
  • Idle-Time
    Auch ein Loadbalancer muss mit seinen Ressourcen haushalten und viele Client beenden eine TCP-Verbindung nicht immer sauber. Daher gibt es Timeouts, nach denen ein Loadbalancer eine Verbindung wegräumt. Dieser Zeit muss höher sein, als der TCP-Timeout des Server aber niedriger als eine davor stehende Firewall. Details dazu habe ich auf TCP Session Timeout / TCP Idle Timeout beschrieben.
  • UDP
    Bislang war immer nur die Rege von TCP und das darauf aufsetzende HTTPS. Nun gibt es aber noch UDP und ICMP. Beide Protokolle können von einem Loadbalancer zwar auch verteilt werden aber es gibt hier keine "Verbindung", die er verwalten kann. UDP ist immer verbindungslos und die meisten Protokolle und Server arbeiten ohne Loadbalancer. Interessant wird es, wenn Sie Dienste per QUIC - HTTP/3 anbieten. Dann sollte ihr Loadbalancer vielleicht die QUIC-SessionID nutzen, um Pakete immer wieder zum gleichen Server zu routen
  • LB für intern und DMZ
    Viele Firmen denken noch in Netzwerkzonen (Intranet, DMZ, Internet) und stellen gerne einen Loadbalancer in eine DMZ um so den Reverse Proxy und Loadbalancing auf einmal zu erschlagen. Das ist möglich aber dann brauchen sie auch noch intern einen Loadbalancer für interne Client. Ich würde ungern meine internen Clients erst durch einen Proxy in die DMZ schicken, damit der Loadbalancer von dort die Pakete wieder nach innen weitergeleitet und damit alles zweimal durch Firewalls muss. Zudem möchte ich auf dem externen Zugang gerne eine strengere und andere Anmeldung nutzen, als von intern. Daher würde ich entweder zwei Loadbalancer vorsehen oder eine Web Application Firewall in ihrer DMZ kann die Anfragen auch zum Loadbalancer geben. Achten Sie dabei aber auf die Affinität, wenn jeder externe Zugriff aus dem Internet mit der IP-Adresse der Reverse-Proxy aus der DMZ ankommt.

Weitere Links