Exchange 2013/2016 Loadbalancing
Eine Änderung in der Architektur von Exchange in der Version 2016 hat die Integration eines Loadbalancers in die Umgebung viel wahrscheinlicher gemacht. Warum das so ist, welche Optionen Sie haben und wie diese umgesetzt werden können, zeigt Markus Hengstler in diesem Beitrag.
Eine Änderung in der Architektur von Exchange in der Version 2016 hat die Integration eines Loadbalancers in die Umgebung viel wahrscheinlicher gemacht. Warum das so ist, welche Optionen Sie haben und wie diese umgesetzt werden können, möchte ich in diesem Artikel zeigen. Ich verwende einen virtuellen Loadbalancer der Firma Kemp Technologies, die Konzepte gelten aber weitgehend auch für andere Produkte.
Warum braucht es einen Loadbalancer?
Wenn Sie sich entscheiden, mehr als einen Exchange Server zu betreiben, um die Verfügbarkeit der Daten und des E-Mail Services zu erhöhen, verwenden Sie dafür im Hintergrund Windows Clustering und applikatorische Replikation der Datenbanken. Damit decken Sie aber nicht die Verteilung und Ausfallsicherheit des Zugriffs auf die Daten ab. In Exchange 2010 und 2013 konnte die Client-Access-Server-Rolle, die diese Zugriffe sicherstellt, noch separat installiert und das Feature Windows Network Loadbalancing (WNLB) implementiert werden. Microsofts Exchange Team hat aber schon immer die Verwendung eines Hardware Loadbalancers empfohlen, da WNLB in vielen Bereichen den Anforderungen nicht wirklich genügt, z.B. bei Healthchecks oder Affinitätsoptionen.
Die meisten Produkte bieten neben dem reinen Loadbalancing übrigens noch Zusatzfunktionen wie Authentisierung, Web Application Firewall oder Network Intrusion Detection.
Wichtige Begriffe rund um Loadbalancing
An dieser Stelle möchte ich ein paar Begriffe erklären, die beim Loadbalancing eine wichtige Rolle spielen:
Layer 4 / Layer 7
Der Loadbalancer kann entweder nur IP-Adresse und TCP/UDP Port auswerten (Layer 4) oder auch Einblick in den Applikationsteil der Netzwerkpakete haben (Layer 7). Im Falle von HTTPS muss dabei auch ein Zertifikat installiert werden, damit der Verkehr entschlüsselt werden kann.
Affinity/Persistence
Für einige Zugriffe ist es wichtig, dass der Benutzer immer den gleichen Backend Server benutzt, da nur dieser Informationen zur bestehenden Session speichert. Zu den möglichen Kriterien, die dazu benutzt werden können, gehören die IP-Adresse des Clients, Cookies, die der Webserver oder der Loadbalancer ausstellen oder die SSL Session ID.
Transparency
Der Loadbalancer kann entweder nur das Netzwerkpaket an den Zielserver senden (Transparency) oder die Quelladresse dieses Pakets gegen seine eigene austauschen (Network Address Translation, NAT). NAT muss oft verwendet werden, wenn der Loadbalancer und die Exchange Server im gleichen Subnet stehen, da sonst die Pakete der Antwort an den Client direkt geschickt werden und nicht mehr über den Loadbalancer gehen. Dies kann zu Problemen führen.
Scheduling
Die Methode zur Verteilung der Zugriffe. Dies kann z.B. Round Robin sein (gleichmässig), Weighted (in einem bestimmten Verhältnis) oder Least Connection (die wenigsten Verbindungen aus Sicht des Loadbalancers).
Content Rules
Der Loadbalancer kann im HTTP- und HTTPS-Verkehr die angeforderten URLs auswerten und die Zugriffe mit unterschiedlichen Einstellungen/Verteilungen abarbeiten. So kann er z.B. unterscheiden, ob ein Outlook Client https://mail.contoso.com/mapi anfordert oder ein Browser https://mail.contoso.com/owa.
Healthcheck
Der Loadbalancer kann die Backend Server überwachen und diese im Falle eines Fehlers nicht mehr berücksichtigen. Dies kann ein einfaches Pingen des Servers sein, das Öffnen einer TCP-Verbindung oder die Abfrage der Applikation, z.B. einer bestimmten Website. Exchange bietet dazu pro Protokoll in Abhängigkeit von der internen Selbstüberwachung (Managed Availability) einen Testpunkt an. Für OWA sieht er zum Beispiel so aus: https://mail.contoso.com/owa/healthcheck.htm
 |
Microsoft Exchange TrainingsFür mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse. |
Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.
Die Lösungsvarianten
Nachfolgend stelle ich die drei von Microsoft unterstützten Varianten für Loadbalancing vor. Generell gilt es zu beachten, dass alle Exchange Server das gleiche Zertifikat für die Frontend Services verwenden. Sonst muss der Benutzer beim Wechsel des Backends neu authentisiert werden.
Variante 1: Reines Layer 4 Loadbalancing
Seit Exchange 2013 benötigen keine Protokolle mehr Affinität. Deswegen ist es möglich, den Verkehr auf einen beliebigen Client Access Service zu senden. Dieser leitet dann auf den Server weiter, auf dem sich die aktive Datenbank mit der Benutzermailbox befindet. Die Lösung hat einen gewichtigen Nachteil: Es kann nur ein Healthcheck definiert werden. Funktioniert nur ein Service nicht und es ist nicht der überwachte, wird der Server vom Loadbalancer weiter berücksichtigt. Umgekehrt führt der Ausfall des überwachten Services zum Ausfall des Servers.
Hier die Beispiel-Konfiguration:
Im Screenshot ist ersichtlich, dass Layer 7 verwendet wird – dies ist aber eine Eigenheit der Kemp Loadbalancer – nur L7 Services können nicht-transparent konfiguriert werden. Da der Verkehr nicht analysiert wird (SSL Acceleration ist nicht eingeschaltet), werden nur IP und Port für die Verteilung verwendet.
Persistence ist None, also keine Affinität für einen bestimmten Backend Server und die Verteilung findet über die geringste Anzahl von Verbindungen statt (Least connections). Dabei ist es wichtig, einem neuen Server im Loadbalancing-Verbund, etwa nach einem Neustart, genügend Zeit zu lassen, wieder auf einen ähnlichen Stand wie die vorhandenen Server zu kommen. Ansonsten würde er, da er ja mit 0 Verbindungen startet, alle neuen Zugriffe abarbeiten müssen. Im folgenden Screenshot ist die entsprechende Option Least Connection Slow Start ersichtlich:
Falls das Loadbalancing-Produkt keine solche Option bieten sollte, ist die Empfehlung Round Robin statt Least Connection zu verwenden.
Die letzte Illustration zeigt die Konfiguration der Backend Server und des Healthchecks. Hier ist nur ein Port Check auf TCP 443 aktiv. Es könnte stattdessen auch eines der virtuellen Verzeichnisse überwacht werden – idealerweise dasjenige mit den wichtigsten oder meisten Clients.
Variante 2: Layer 4 Loadbalancing mit mehreren Namespaces
Um granulare Healthchecks zu ermöglichen, kann statt Layer 7 und Content Rules auch mit mehreren Namespaces gearbeitet werden. Dies sieht dann so aus:
Jedes Protokoll ist als separater virtueller Service konfiguriert. Dazu muss auch in DNS je ein Eintrag mit eigenem Namen erstellt werden und diese müssen alle im Zertifikat auf den Exchange Servern vorhanden sein. Hier kann ein Wildcard-Zertifikat praktisch sein.
Natürlich müssen die Namen auch noch in der Exchange-Konfiguration angepasst werden. Als Beispiel OWA und ECP:
Hier noch die Einstellungen der virtuellen Services am Beispiel von OWA:
Die Standard-Optionen sind gleich wie bei der vorhergehenden Variante, also Transparency ausgeschaltet, Persistence auf None und Scheduling Method ist Least Connection.
Variante 3: Layer 7 Loadbalancing mit Content Rules
Diese Variante ist zwar ein bisschen komplexer aufzusetzen, aber ist aufgrund der Granularität der Ausfallsicherheit und der Einfachheit bezüglich Namespace und Zertifikaten das von Microsoft empfohlene Setup.
Es wird ein virtueller Service (VS) eingerichtet und statt Backend Server werden Sub-VS erstellt, die alle ihre eigenen Einstellungen und Healthchecks haben können. Hier wieder das Beispiel OWA:
Dazu muss das Zertifikat, das auch die Exchange Server benutzen, importiert und SSL Acceleration aktiviert werden:
Zuguterletzt muss noch das Regelset erstellt werden, das die Verteilung des Verkehrs anhand der URL im Request auf die Sub-VS erlaubt:
Hier noch das Beispiel OWA:
Wichtig dabei ist nur die Option Ignore Case und natürlich die zu suchende Zeichenfolge.
In den Sub-VS wird dann diese Regel in den Advanced Properties referenziert:
Fazit
Loadbalancing ist eine wichtige Komponente fast jeder Exchange-Umgebung. Mit ein bisschen Wissen ist Design und Konfiguration nicht sonderlich schwierig, aber ein paar wichtige Punkte müssen verstanden und berücksichtigt werden.