Lastverteilung für Exchange-Umgebungen
3. Februar 2014
Mit Exchange 2013 hat Microsoft die Architektur im Vergleich zum 2010er-Vorgängermodell insbesondere hinsichtlich des Rollenmodells verändert. Diese Unterschiede gilt es in der Infrastruktur – speziell bei der Lastverteilung – zu berücksichtigen. Hier werden die Auswirkungen am Beispiel der Load Balancer aus dem Haus Kemp besprochen.
Zwischen Exchange 2010 und Exchange 2013 gibt es einige größere architektonische Unterschiede. Exchange 2010 stellt fünf Rollen auf Serverebene für das Verwalten der Nutzer-Berechtigungen bereit. Rollen entsprechen Gruppen im Windows-Betriebssystem. Serverrollen sind, wie der Name schon vermuten lässt, auf den Server beschränkt.
Bei Exchange 2010 beziehen sie sich auf: Zugang zum Arbeitsplatzrechner (Client Access), Hub-Transport, Postfach, Unified Messaging und Edge Transport. Dagegen hat Microsoft diese Rollen beim Exchange Server 2013 konsolidiert, so dass nur zwei Hauptrollen verblieben sind: Client Access und Rollen für den Postfach-Server-Zugang.
Client Access-Rolle: Diese Rolle ist zuständig für alle Verbindungsprotokolle auf Arbeitsplatzrechner-Ebene einschließlich HTTPS/IMAP/POP3, SMTP und Anrufweiterleitung im Unified Messaging. In der Exchange 2013-Architektur kommunizieren alle Arbeitsplatzrechner via Remote Procedure Call (RPC) über das Protokoll für verschlüsselte Webseiten (das HTTPS). Es ist kein RPC-Verkehr vom Client zum Server nötig. RPC-Aufrufe werden nun nur noch innerhalb der Postfach-Serverrolle abgearbeitet.
Postfach-Serverrolle: In Exchange 2010 waren sowohl die Datenbankdateien des Postfachs als auch die der öffentlichen Ordner über die Postfach-Serverrolle organisiert. Zudem verwaltete sie das Speichern der E-Mail-Nachrichten. Beim Exchange Server 2013 umfasst die Postfach-Serverrolle auch die Client Access-Protokolle, den Transportdienst, die Postfach-Datenbanken und Komponenten für das Unified Messaging.
Einer der Gründe für diese neue Architektur besteht darin, dass mehr Rollen innerhalb eines einzelnen Servers kombiniert werden können. Folglich sind weniger Serverrollen erforderlich und die Hardware wird effizienter genutzt. Wenn die zwei Rollen kombiniert werden, können sie außerdem intern über RPC kommunizieren. Das RPC-Protokoll muss daher nicht mehr außerhalb einer einzelnen Serverrolle unterstützt werden.
Durch die neue Architektur führt der Client-Access-Server seine Rolle anders aus, als er es in Exchange 2010-Umgebungen getan hat. Er agiert jetzt als Proxy für Verbindungen, die durch ihn hindurchgehen. Das erleichtert die Dienste-Bereitstellung aus mehreren Gründen.
Verbindungen sind jetzt zustandslos; die Client-Access-Server-Rolle beschränkt sich darauf, als Proxy- und Authentifizierungs-Server Verbindungen weiterzuleiten.
Jegliche Ausführung findet auf der Ebene des Postfach-Servers statt. Anders gesagt: Sollte ein Client-Access-Server ausfallen, kann die Sitzung problemlos an einen weiteren Client-Access-Server weitergeführt werden, denn Anfragen werden nicht wieder zum gleichen Server zurückgeleitet.
Das Load Balancing für Exchange 2013 kann also auf dem vierten Layer des Schichtenmodells erfolgen. Load Balancing auf der siebten Schicht bietet aber immer noch eine Reihe von Vorteilen, wie weiter unten gezeigt wird.
Die gesamte Kommunikation findet nun über https statt. Dagegen ist RPC-over-TCP (es wird bei MAPI, dem Messaging Application Programming Interface, verwendet), weggefallen.
Die zahlreichen Exchange-Rollen und Verantwortlichkeiten wurden konsolidiert. So ist beispielsweise die Client-Access-Server-Rolle jetzt auch für SMTP-Verbindungen zuständig. Der alleinige dafür verantwortliche Dienst ist der Frontend-Transport-Dienst, der jegliche mit SMTP in Beziehung stehende Funktionalität abwickelt. Das umfasst das Filtern von Absender und Empfänger sowie die Protokollaufzeichnung von Aktionen usw.
Was die Edge-Transport-Rolle anbelangt, so gibt es keine für den Edge Server 2013 spezifische Version. Das heißt für die erste Version von Exchange 2013: Der Exchange 2010 Edge Transport Server kann mit dem Exchange Server 2013 verwendet werden.
Verfügbarkeitsmanagement bei Exchange 2013
Eingebaut in beide Serverrollen in Exchange 2013 ist ein Verfügbarkeitsmanagement (Managed Availability), das auf drei asynchronen Hauptkomponenten beruht. Erster Bestandteil ist die Testumgebung. Sie nimmt Messungen auf dem Server vor, führt Tests durch und sammelt Betriebsdaten, die sie an die zweite Komponente, den Monitor übergibt. Der Monitor nimmt die Daten der Probe Engine auf und bewertet diese. In ihm ist die Geschäftslogik abgebildet. Auf Grundlage dieser Informationen bestimmt er also, ob der Server oder der Dienst fehlerfrei arbeitet.
Der Monitor sucht und erkennt einzigartige Verhaltensmuster, die Exchange 2013 mit unterschiedlichen Aktionen ausgelöst haben kann. Daraufhin entscheidet er, ob die Komponente als funktionsfähig betrachtet werden kann oder nicht.
Dritte im Bunde dieser Komponenten ist die Responder Engine. Wurde der Status als nicht gesund eingestuft, stößt die Responder Engine geeignete Reaktionen an, um dies zu korrigieren. Managed Availability verfügt über ein Stufenmodell zur Wiederherstellung: erstens versucht sie, den Anwendungspool, zweitens einen Dienst und drittens den Server neu zu starten. Erst wenn diese Schritte nicht helfen, initiiert die Responder Engine die vierte und letzte Maßnahme, nämlich den Server vom Netz zu nehmen, so dass er den Netzverkehr nicht mehr stört.
Als allerletzte automatisierte Aktion benachrichtigt das Verfügbarkeitsmanagement den Systemadministrator über einen Eventlogeintrag. An dieser Stelle wird der Status „Server / Dienst / Anwendung ist außer Betrieb“ oder „unhealthy“ am Load Balancer angezeigt.
Jeder Server kann seine eigenen Tests ausführen, sich selbst überwachen, Aktionen zur Wiederherstellung der eigenen Arbeitsfähigkeit in Gang setzen und selbstverständlich bei Bedarf Eskalationsstufen auslösen.
Die neuen eingebauten Verfügbarkeitsmanagement-Funktionen unterstützen Load Balancer somit dabei, ausgewogenere, punktgenauere und zielgerichtete Entscheidungen im Hinblick auf den Zustand einer Anwendung, eines Dienstes oder eines Servers zu treffen.
Load Balancing und Exchange 2013
Bei Exchange 2010 gestaltete sich die Konfiguration eines Load Balancers aus dem Hause Kemp vergleichsweise einfach und schnell. Man konnte die mitgelieferten Exchange-Vorlagen verwenden oder die Konfiguration manuell vornehmen. Der IT-Administrator musste lediglich zwei bis drei ausgewiesene virtuelle Dienste einrichten:
- einen für RPC/MAPI (alle Schnittstellen oder konfigurierte statische Schnittstellen),
- einen für HTTPS (443) und optional
- einen für Weiterleitungen von HTTP (80)-Anfragen auf HTTPS (443).
Andere Dienste wie SMTP (25), IMAP und POP konnten zur Exchange 2013-Konfiguration ergänzt werden; sie waren aber nicht zwingend nötig für den Betrieb von Exchange 2010. Der Screenshot in Abbildung 2 zeigt die fertige Konfiguration.
Mit der neuen Architektur in Exchange 2013 haben sich auch die Minimalanforderungen an den Load-Balancing-Traffic in Exchange 2013-Umgebungen verändert. So muss jetzt ein virtueller Dienst auf der Ebene 4 des Schichtenmodells für im HTTPS-Protokoll über den Port 443 eingehenden Datenverkehr konfiguriert werden. Teil des Setups sind Persistenz und Round-Robin-Load Balancing-Intelligenz (siehe Abbildung 3).
Um aber die Funktionsfähigkeit individueller Exchange 2013 Web Services zu überprüfen und die intelligenten Funktionen für das Optimieren der Netzeinrichtung nutzen zu können, muss Load Balancing auf der Anwendungsebene (der siebten Schicht) ausgeführt werden. In diesem Zusammenhang bietet KEMP die Möglichkeit, untergeordnete virtuelle Dienste zu schaffen, die einen virtuellen Dienst von einer bestimmten IP-Adresse und Port abzweigen. Da der Load Balancer den Zustand individueller Exchange 2013 Web Services prüft, wird der übergeordnete virtuelle Dienst bei Bedarf automatisch zu einem virtuellen Layer 7-Dienst.
Abbildung 4 zeigt die abschließende Konfiguration beim Aufsetzen eines übergeordneten virtuellen Dienstes für den Port 443 und eines untergeordneten virtuellen Dienstes für Outlook Web App, Exchange Administration Center, Exchange Web Services und andere Dienste.
An dieser Stelle ist es wichtig zu betonen, dass zwar – dank dem neu hinzugefügten Verfügbarkeitsmanagement – die Lastverteilung bei Exchange 2013 im Layer 4 vorgenommen werden kann. Layer 7 ist jedoch oftmals noch immer nötig, wenn man das Leistungsspektrum eines intelligenten Load Balancers voll ausschöpfen und viele der zusätzlichen Mehrwertfunktionen realisieren will.
Diese Exchange 2013-Erweiterungen machen die Funktionstests auf den Load Balancerm nicht obsolet, ergänzen sich aber gegenseitig. So erleichtern sie das automatische Entfernen von Servern, die im Funktionstest versagen, das selektive Ausschalten von Diensten und die automatische Wiederinbetriebnahme. Letzteres aber nur, wenn Exchange 2013 das Problem intern lösen konnte und der Server, der Dienst oder die Anwendung wieder am Netz ist.
Reverse Proxy for Exchange 2013
Genauso wie bei Exchange 2010 ziehen Exchange 2013-Umgebungen einen Nutzen daraus, wenn sie eine Reverse Proxy-Lösung verwenden. In diesem Zusammenhang ist insbesondere eine Veränderung im Markt wichtig, und zwar die Abkündigung der weit verbreiteten Microsoft Reverse Proxy-Lösung, Forefront Threat Management Gateway (TMG).
Ein Reverse Proxy bietet einige Sicherheitsvorteile in Exchange 2013. Auch wenn dies nicht allgemein bekannt ist, stellt ein Load Balancer inhärent einen Reverse Proxy dar. Tatsächlich ist das sogar einer seiner Hauptvorteile. KEMP Technologies hat mit dem Edge Security Pack (ESP) zusätzliche Reverse Proxy-Funktionalität integriert.
Das ESP ermöglicht vorgelagerte Authentifizierung von Netzverkehr zwischen externen Clients und dem Exchange 2013 Client Access Server zusammen mit einem Single Sign-On. ESP authentifiziert die Nutzeranfrage sicher an einer Active Directory-Domäne, bevor sie in eine Exchange 2013-Umgebung weitergeleitet wird. So entsteht eine zusätzliche Sicherheitsebene zwischen dem externen Client und dem internen Netzwerk.
Konfiguration und Inbetriebnahme des Edge Security Pack sind ähnlich einfach wie bei früheren Szenarien. Das Pack erfordert eine aktive SSL-Beschleunigung, bei der SSL-Zertifikate auf dem Load Balancer installiert sein müssen. Sobald das sichergestellt ist, können Single Sign-On-Domänen für die vorgelagerte Authentifizierung fertiggestellt werden.
Dafür sind nur wenige Schritte nötig. Dazu gehören das Benennen der Domänen-Namen (Abbildung 5) und der Adressen für die LDAP-Server, die für die clientseitige Authentifizierung eingesetzt werden sowie die Auswahl des Kommunikationsverfahrens zwischen Load Master und der Active Directory-Umgebung (vergleiche Abbildung 6).
