Lastenausgleich in Exchange Server
Der Lastenausgleich in Exchange 2016 und höher basiert auf der Hochverfügbarkeits- und Netzwerkresilienzplattform von Microsoft, die in Exchange 2013 bereitgestellt wird. Wenn dies mit der Verfügbarkeit von Lastenausgleichslösungen von Drittanbietern (Hardware und Software) kombiniert wird, gibt es mehrere Optionen für die Implementierung des Lastenausgleichs in Ihrer Exchange-Organisation.
Durch Exchange-Architekturänderungen, die in Exchange 2013 eingeführt wurden, entstanden die Postfachserver- und Clientzugriffs-Serverrollen. Vergleichen Sie dies mit Exchange 2010, wo Clientzugriff, Postfach, Hub-Transport und Unified Messaging auf separaten Servern ausgeführt wurden.
Exchange 2016 und 2019 bietet mithilfe von minimalen Serverrollen Folgendes:
Vereinfachte Bereitstellung, wobei auf dem Postfachserver Clientzugriffsdienste und Edge-Transport-Serverrollen ausgeführt werden.
Der nachrichtenfluss wird in der Transportpipeline verwaltet. Hierbei handelt es sich um eine Sammlung von Diensten, Verbindungen, Warteschlangen und Komponenten, die Nachrichten an das Kategorisieren des Transportdiensts auf dem Postfachserver weiterleiten.
Hohe Verfügbarkeit durch die Bereitstellung von Lastenausgleichsmodulen zur Verteilung des Clientdatenverkehrs.
Der mit Exchange 2013 eingeführte HTTP-Protokollstandard bedeutet, dass in Exchange 2016 und Exchange 2019 keine Sitzungsaffinität mehr erforderlich ist. Die Sitzungsaffinität ermöglicht eine dauerhafte Verbindung für messagingfähige Dienste, sodass ein Benutzer seinen Benutzernamen und sein Kennwort nicht mehrmals erneut eingeben muss.
In früheren Versionen wurde RPC über HTTP für Outlook Anywhere von Exchange 2007 und Exchange 2010 unterstützt. In Exchange 2013 wurde MAPI über HTTP eingeführt, obwohl dies standardmäßig nicht aktiviert war. Es ist jetzt standardmäßig in Exchange 2016 und Exchange 2019 aktiviert.
Wenn das HTTP-Protokoll verwendet wird, stellen alle nativen Clients eine Verbindung über HTTP und HTTPs in Exchange Server her. Aufgrund dieses Standardprotokolls ist die Affinität nicht mehr erforderlich, die bisher benötigt wurde, um eine erneute Aufforderung zur Eingabe von Benutzeranmeldeinformationen zu verhindern, wenn der Lastenausgleich die Verbindung auf einen anderen Server umleitete.
Serverrollen in Exchange Server
Die reduzierte Anzahl von Serverrollen für Exchange 2016 und Exchange 2019 vereinfacht die Exchange-Implementierung und die Hardwareanforderungen. Die Anzahl der Serverrollen in Exchange 2016 und 2019 wird von sieben auf zwei reduziert: der Postfachserver und der Edge-Transport-Server. Die Postfachserverrolle umfasst Clientzugriffsdienste, während der Edge-Transport-Server einen sicheren Nachrichtenfluss in Exchange 2016 und Exchange 2019 bereitstellt, genau wie in früheren Versionen von Exchange.
In Exchange 2013 wurde bei dem Versuch eines Benutzers, auf sein Postfach zuzugreifen, durch die Clientzugriffs-Serverrolle sichergestellt, dass der Server die Anforderung zurück an den Postfachserver leitete, der das Postfach des Benutzers aktiv bediente. Dies bedeutete, dass Dienste wie Outlook im Web (bisher als Outlook Web App bekannt) für den Benutzer im Postfach selbst gerendert wurden, sodass keine Affinität mehr erforderlich war.
Die gleiche Funktionalität bleibt auch in Exchange 2016 und Exchange 2019 bestehen. Wenn zwei Postfachserver unterschiedliche Postfächer hosten, können sie bei Bedarf Datenverkehr gegenseitig umleiten. Der Postfachserver, der die aktive Kopie des Postfachs hostet, bedient den Benutzer, der darauf zugreift, auch dann, wenn der Benutzer eine Verbindung zu einem anderen Postfachserver herstellt.
Weitere Informationen zu den Änderungen der Serverrolle in Exchange Server finden Sie im Artikel Exchange Server Architektur.
| Serverrolle | Dienste |
|---|---|
| Postfachserver | Verwendet EdgeSync zur Verwaltung der einseitigen Replikation von Bestätigungs- und Konfigurationsinformationen von Active Directory an die AD LDS-Instanz auf dem Edge-Transport-Server. Kopiert nur Informationen, die erforderlich sind, damit Edge-Transport Antispam ausführen und den End-to-End-Nachrichtenfluss aktivieren kann. |
| Edge-Transport | Verwaltet den gesamten eingehenden und ausgehenden Internetnachrichtenfluss mithilfe von:
Kein Mitglied der Active Directory-Gesamtstruktur. |
Obwohl nicht erforderlich, befindet sich der Edge-Transport-Server wie in früheren Exchange-Versionen im Umkreisnetzwerk, um einen sicheren eingehenden und ausgehenden E-Mail-Fluss für Ihre Exchange-Organisation bereitzustellen.
Weitere Informationen zum Transportdienst finden Sie im Artikel Grundlegendes zum Transportdienst auf Edge-Transport-Servern.
Protokolle in Exchange Server
Ab Exchange 2016 verwenden alle nativen Exchange-Clients das HTTP-Protokoll, um eine Verbindung mit einem bestimmten Dienst herzustellen. Dabei werden dem Benutzer bei der Anmeldung HTTP-Cookies bereitgestellt, die mit dem SSL-Zertifikat der Clientzugriffsdienste verschlüsselt werden. Ein angemeldeter Benutzer kann die Sitzung auf einem anderen Postfachserver fortsetzen, auf dem Clientzugriffsdienste ausgeführt werden, ohne sich erneut zu authentifizieren. Server, die das gleiche SSL-Zertifikat verwenden, können das Clientauthentifizierungscookie entschlüsseln.
HTTP ermöglicht die Verwendung von Dienst- oder Anwendungsintegritätsprüfungen in Ihrem Exchange-Netzwerk. In Abhängigkeit von Ihrer Lastenausgleichslösung können Sie den Integritätstests implementieren, um unterschiedliche Komponenten Ihres Systems zu überprüfen.
Der Effekt des Zugriffs für Clients nur mit HTTP besteht darin, dass auch der Lastenausgleich einfacher ist. Wenn Sie möchten, könnten Sie DNS für den Lastenausgleich Ihres Exchange-Datenverkehrs verwenden. Sie würden dem Client die IP-Adresse jedes Postfachservers bereitstellen, und der HTTP-Client würde die Aufgaben übernehmen. Wenn ein Exchange-Server fehlschlägt, versucht das Protokoll eine Verbindung zu einem anderen Server herzustellen. Es gibt jedoch Nachteile beim Lastenausgleich mit DNS, die im folgenden Abschnitt Lastenausgleichsoptionen in Exchange Server erläutert werden.
Weitere Informationen zu HTTP und Exchange Server finden Sie im Artikel MAPI über HTTP in Exchange Server.
Lastenausgleichsoptionen in Exchange Server
Im hier dargestellten Beispiel hosten mehrere Server, die in einer Datenbankverfügbarkeitsgruppe (DAG) konfiguriert sind, die Postfachserver, auf denen Clientzugriffsdienste ausgeführt werden. Dies bietet eine hohe Verfügbarkeit bei kleinem Exchange-Platzbedarf. Der Client stellt eine Verbindung zum Lastenausgleich und nicht direkt mit den Exchange-Servern her. Es sind keine Lastenausgleichspaare erforderlich. Wir empfehlen jedoch die Bereitstellung in Clustern, um die Netzwerkresilienz zu verbessern.
Beachten Sie jedoch, dass Datenbankverfügbarkeitsgruppen Microsoft Clustering Services verwenden. Diese Dienste können nicht auf demselben Server wie Windows- Netzwerklastenausgleich (NLB) aktiviert werden. Windows-NLB ist daher bei Verwendung von Datenbankverfügbarkeitsgruppen keine Option. In diesem Fall gibt es Drittanbietersoftware und virtuelle Anwendungslösungen.
Die Verwendung von DNS ist die einfachste Option für den Lastenausgleich ihres Exchange-Datenverkehrs. Beim DNS-Lastenausgleich müssen Sie Ihren Clients nur die IP-Adresse jedes Postfachservers bereitstellen. Anschließend verteilt DNS-Roundrobin diesen Datenverkehr auf Ihre Postfachserver. Der HTTP-Client ist so intelligent, dass eine Verbindung zu einem anderen Server hergestellt wird, falls ein Exchange-Server vollständig fehlschlägt.
Die Einfachheit hat ihren Preis. In diesem Fall ist DNS-Roundrobin jedoch kein wirklicher Lastenausgleich für den Datenverkehr, da es keine Möglichkeit gibt, programmgesteuert sicherzustellen, dass jeder Server einen angemessenen Anteil am Datenverkehr erhält. Außerdem gibt es keine Überwachung des Servicelevels, sodass Clients nicht automatisch an einen verfügbaren Dienst umgeleitet werden, wenn ein einzelner Dienst ausfällt. Wenn sich Outlook im Web beispielsweise im Fehlermodus befindet, wird für die Clients eine Fehlerseite angezeigt.
Für den DNS-Lastenausgleich sind beim externen Veröffentlichen mehrere externe IP-Adressen erforderlich. Das bedeutet, dass für jeden einzelnen Exchange-Server in Ihrer Organisation eine externe IP-Adresse erforderlich wäre.
Es gibt elegantere Lösungen für den Lastenausgleich Ihres Datenverkehrs, z. B. Hardware, die Transportebene 4 oder Anwendungebene 7 verwendet, um den Datenverkehr aufzuteilen. Lastenausgleichsmodule überwachen jeden clientseitigen Exchange-Dienst, und wenn ein Dienstfehler auftritt, können Lastenausgleichsmodule Datenverkehr an einen anderen Server weiterleiten und den Problemserver offline schalten. Außerdem wird durch ein gewisses Maß an Lastverteilung sichergestellt, dass kein einzelner Postfachserver die Großteil des Clientzugriffs weiterleitet.
Lastenausgleichsdienste können Ebene 4 oder Ebene 7 oder eine Kombination verwenden, um den Datenverkehr zu verwalten. Bei jeder Lösung gibt es Vor- und Nachteile.
Lastenausgleichsmodule der Ebene 4 arbeiten auf der Transportschicht, um Datenverkehr weiterzuleiten, ohne den Inhalt zu überprüfen.
Da der Inhalt des Datenverkehrs nicht geprüft wird, sparen Lastenausgleichsmodule der Ebene 4 Zeit beim Transit. Dies birgt jedoch ein Nachteile. Lastenausgleichsmodule der Ebene 4 kennen nur die IP-Adresse, das Protokoll und den TCP-Port. Da das Lastenausgleichsmodul nur eine einzelne IP-Adresse kennt, kann nur ein einziger Dienst überwacht werden.
Zu den Vorteilen des Lastenausgleichs für Layer 4 gehören:
Weniger Ressourcen erforderlich (kein Inhaltsprüfung).
Datenverkehr wird auf der Transportebene verteilt.
Das Risiko einer Lösung auf Ebene 4 besteht darin, dass, wenn ein Dienst ausfällt, der Server jedoch noch verfügbar ist, Clients eine Verbindung zu dem fehlgeschlagenen Dienst herstellen können. Dies bedeutet, dass für eine stabile Implementierung auf Ebene 4 mehrere IP-Adressen mit separaten HTTP-Namespaces pro Dienst konfiguriert werden müssen, z. B. owa.contoso.com, eas.contoso.com, mapi.contoso.com, wodurch eine Überwachung auf Dienstebene ermöglicht wird.
Lastenausgleichsmodule auf Ebene 7 arbeiten auf der Anwendungsebene und können den Inhalt des Datenverkehrs überprüfen und entsprechend weiterleiten.
Bei Lastenausgleichsmodulen auf Ebene 7 wird zugunsten der Einfachheit eines einzigen Namespace, z. B. mail.contoso.com, und einer Überwachung pro Dienst auf die Leistungsvorteile bei Lastenausgleichsmodulen auf Ebene 4 verzichtet. Lastenausgleichsmodule auf Ebene 7 verstehen den HTTP-Pfad, z. B. /owa or /Microsoft-Server-ActiveSync, or /mapi,, und können Datenverkehr an arbeitende Server basierend auf Überwachungsdaten umleiten.
Zu den Vorteilen des Lastenausgleichs für Layer 7 gehören:
Es ist nur eine einzige IP-Adresse erforderlich.
Inhalte werden überprüft, und Datenverkehr kann umgeleitet werden.
Möglichkeit der Benachrichtigung über einen fehlgeschlagenen Dienst, der offline geschaltet werden kann.
Die SSL-Terminierung des Lastenausgleichs wird behandelt.
Datenverkehr wird auf der Anwendungsebene verteilt, die Ziel-URL wird verstanden.
SSL sollte auf der Ebene des Lastenausgleichs terminiert werden, da dies einen zentralen Punkt zur Korrektur von SSL-Angriffen bietet.
Die Ports, für die ein Lastenausgleich erforderlich ist, enthalten einige, z. B. für IMAP4 oder POP3, die möglicherweise nicht einmal in Ihrer Exchange-Organisation verwendet werden können.
| TCP-Port | Rollen | Verwendung |
|---|---|---|
| 25 | Postfach | SMTP eingehend |
| 587 | Postfach | Eingehendes SMTP für Clients |
| 110 | Postfach | POP3-Clients |
| 143 | Postfach | IMAP4-Clients |
| 443 | Postfach | HTTPS (Outlook im Web, AutoErmittlung, Webdienste, ActiveSync, MAPI über HTTP, RPC über HTTP, OAB, EAC) |
| 993 | Postfach | Sichere IMAP4-Clients |
| 995 | Postfach | Sichere POP3-Clients |
Bereitstellungsszenarien für den Lastenausgleich in Exchange Server
Exchange 2016 hat erhebliche Flexibilität für Ihre Namespace- und Lastenausgleichsarchitektur eingeführt. Angesichts der vielen Optionen zur Bereitstellung eines Lastenausgleichs in Ihrer Exchange-Organisation, von einfachem DNS bis hin zu fortschrittlichen Lösungen der Ebene 4 und Ebene 7, wird empfohlen, dass Sie sich alle Optionen im Hinblick auf die Anforderungen Ihrer Organisation genauer ansehen.
Die folgenden Szenarien weisen Vorteile und Einschränkungen auf, und es ist wichtig, dass Sie diese verstehen, um eine Lösung zu implementieren, die den Anforderungen Ihrer Exchange-Organisation entspricht:
Szenario A Einzelner Namespace, keine Sitzungsaffinität: Ebene 4 oder Ebene 7
Szenario B Einzelner Namespace, keine Sitzungsaffinität: Ebene 7
Szenario C Einzelner Namespace mit Sitzungsaffinität, Ebene 7:
Szenario D Einzelner Namespace, keine Sitzungsaffinität, Ebene 4:
Szenario A Einzelner Namespace, keine Sitzungsaffinität: Ebene 4 oder Ebene 7
In diesem Szenario der Ebene 4 wird ein einzelner Namespace (mail.contoso.com) für die HTTP-Protokollclients bereitgestellt. Der Lastenausgleich behält die Sitzungsaffinität nicht bei. Da es sich um eine Lösung der Ebene 4 handelt, ist der Lastenausgleich so konfiguriert, dass nur die Integrität eines einzelnen virtuellen Verzeichnisses überprüft wird, da er Outlook im Web Anforderungen nicht von RPC-Anforderungen unterscheiden kann.
Aus sicht des Lastenausgleichs in diesem Beispiel erfolgt die Integrität pro Server und nicht pro Protokoll für den angegebenen Namespace. Administratoren müssen auswählen, welches virtuelle Verzeichnis sie für den Integritätstest verwenden möchten. Es wird empfohlen, ein stark genutztes virtuelles Verzeichnis auszuwählen. Wenn die Mehrheit Ihrer Benutzer z. B. Outlook im Web verwendet, wählen Sie im Integritätstest das virtuelle Verzeichnis Outlook im Web aus.
Solange die Antwort des Outlook im Web Integritätstests fehlerfrei ist, behält der Lastenausgleich den Zielpostfachserver im Lastenausgleichspool bei. Wenn der Outlook im Web Integritätstest jedoch aus irgendeinem Grund fehlschlägt, entfernt der Lastenausgleich den Zielpostfachserver aus dem Lastenausgleichspool für alle Anforderungen, die diesem Namespace zugeordnet sind. Dies bedeutet, dass bei einem Fehler beim Integritätstest alle Clientanforderungen für diesen Namespace unabhängig vom Protokoll an einen anderen Server weitergeleitet werden.
Szenario B Einzelner Namespace, keine Sitzungsaffinität: Ebene 7
In diesem Szenario der Ebene 7 wird ein einzelner Namespace (mail.contoso.com) für alle HTTP-Protokollclients bereitgestellt. Der Lastenausgleich behält die Sitzungsaffinität nicht bei. Da der Lastenausgleich für Layer 7 konfiguriert ist, erfolgt die SSL-Terminierung, und der Lastenausgleich kennt die Ziel-URL.
Wir empfehlen diese Konfiguration für Exchange 2016 und Exchange 2019. Der Lastenausgleich ist so konfiguriert, dass die Integrität der Zielpostfachserver im Lastenausgleichspool überprüft wird, und für jedes virtuelle Verzeichnis wird ein Integritätstest konfiguriert.
Solange beispielsweise die Antwort des Outlook im Web Integritätstests fehlerfrei ist, behält der Lastenausgleich den Zielpostfachserver im Outlook im Web Lastenausgleichspool bei. Wenn der Outlook im Web Integritätstest jedoch aus irgendeinem Grund fehlschlägt, entfernt der Lastenausgleich den Zielpostfachserver aus dem Lastenausgleichspool für Outlook im Web Anforderungen. In diesem Beispiel ist die Integrität pro Protokoll angegeben, was bedeutet, dass nur das betroffene Clientprotokoll an einen anderen Server weitergeleitet wird, wenn der Integritätstest fehlschlägt.
Szenario C Einzelner Namespace mit Sitzungsaffinität, Ebene 7:
In diesem Szenario der Ebene 7 wird ein einzelner Namespace (mail.contoso.com) für alle HTTP-Protokollclients bereitgestellt. Da das Lastenausgleichsmodul für Ebene 7 konfiguriert ist, gibt es eine SSL-Terminierung, und das Lastenausgleichsmodul kennt die Ziel-URL. Der Lastenausgleich ist auch so konfiguriert, dass die Integrität der Zielpostfachserver im Lastenausgleichspool überprüft wird. Der Integritätstest wird in jedem virtuellen Verzeichnis konfiguriert.
Durch Aktivieren der Sitzungsaffinität wird jedoch die Kapazität und Auslastung verringert. Dies liegt daran, dass die stärker involvierten Affinitätsoptionen, der cookiebasierte Lastenausgleich oder die SSL-Sitzungs-ID (Secure Sockets Layer) mehr Verarbeitung und Ressourcen erfordern. Es wird empfohlen, sich mit Ihrem Anbieter zu erkundigen, wie sich die Sitzungsaffinität auf Die Skalierbarkeit des Lastenausgleichs auswirkt.
Wie im vorherigen Szenario behält der Lastenausgleich den Zielpostfachserver im Outlook im Web Lastenausgleichspool bei, solange die Antwort des Outlook im Web Integritätstests fehlerfrei ist. Wenn der Outlook im Web Integritätstest jedoch aus irgendeinem Grund fehlschlägt, entfernt der Lastenausgleich den Zielpostfachserver aus dem Lastenausgleichspool für Outlook im Web Anforderungen. In diesem Beispiel ist die Integrität pro Protokoll angegeben, was bedeutet, dass nur das betroffene Clientprotokoll an einen anderen Server weitergeleitet wird, wenn der Integritätstest fehlschlägt.
Szenario D Mehrere Namespaces und keine Sitzungsaffinität
Dieses letzte Szenario mit mehreren Namespaces ohne Sitzungsaffinität bietet Integritätsüberprüfungen pro Protokoll sowie die Leistungsfähigkeit von Ebene 4. Ein eindeutiger Namespace wird für jeden HTTP-Protokollclient bereitgestellt. Sie würden beispielsweise die HTTP-Protokollclients als mail.contoso.com, mapi.contoso.com und eas.contoso.com konfigurieren.
Dieses Szenario bietet eine Integritätsüberprüfung pro Protokoll, erfordert aber keine komplexe Lastenausgleichslogik. Der Lastenausgleich verwendet Layer 4 und ist nicht für die Beibehaltung der Sitzungsaffinität konfiguriert. Die Konfiguration des Lastenausgleichs überprüft die Integrität der Zielpostfachserver im Lastenausgleichspool. Bei dieser Einstellung werden die Integritätstests so konfiguriert, dass auf die Integrität eines jeden virtuellen Verzeichnisses abgezielt wird, da jedes virtuelle Verzeichnis einen eindeutigen Namespace aufweist. Da das Lastenausgleichsmodul für Ebene 4 konfiguriert ist, weiß das Lastenausgleichsmodul nicht, dass auf die URL zugegriffen wird, das Ergebnis sieht jedoch so aus, als wüsste es Bescheid. Da die Integrität pro Protokoll angegeben ist, wird nur das betroffene Clientprotokoll an einen anderen Server weitergeleitet wird, wenn der Integritätstest fehlschlägt.
Lastenausgleich und verwaltete Verfügbarkeit in Exchange Server
Die Überwachung der verfügbaren Server und Dienste ist für hochverfügbare Netzwerke entscheidend. Da einige Lastenausgleichslösungen die Ziel-URL oder den Inhalt der Anforderung nicht kennen, kann dies zu Komplexitäten bei Exchange-Integritätstests führen.
Exchange 2016 und Exchange 2019 enthalten eine integrierte Überwachungslösung, die als verwaltete Verfügbarkeit bezeichnet wird. Die verwaltete Verfügbarkeit, auch als Aktive Überwachung oder lokale aktive Überwachung bezeichnet, ist die Integration integrierter Überwachungs- und Wiederherstellungsaktionen in die Exchange-Hochverfügbarkeitsplattform.
Die Verwaltete Verfügbarkeit umfasst einen Offline-Responder. Wenn der Offline-Responder aufgerufen wird, wird das betroffene Protokoll (oder der betroffene Server) vom Dienst entfernt.
Um sicherzustellen, dass Lastenausgleichsmodule keinen Datenverkehr an einen Postfachserver weiterleiten, der als offline markiert wurde, müssen Load Balancer-Integritätstests so konfiguriert werden, dass virtualdirectory>/healthcheck.htm überprüft <werden, <https://mail.contoso.com/owa/healthcheck.htm>z. B. .
Weitere Informationen zur verwalteten Verfügbarkeit finden Sie unter Verwaltete Verfügbarkeit.