Lastenausgleich in Exchange 2016

[Dieses Thema gehört zur Vorabdokumentation und kann in künftigen Versionen geändert werden. Leere Themen wurden als Platzhalter hinzugefügt. Wenn Sie Feedback dazu haben, freuen wir uns über Ihre Nachricht. Senden Sie uns eine E-Mail an: ExchangeHelpFeedback@microsoft.com.]  

Zusammenfassung: Erfahren Sie mehr über die Möglichkeiten, wie der Lastenausgleich in Exchange 2016 E-Mail-aktivierte Verbindungen behandelt, was zu einer besseren Verfügbarkeit und Stabilität in Ihrem Exchange-Unternehmensnetzwerk führt.

Der Lastenausgleich in Exchange 2016 basiert auf der Microsoft-Plattform für hohe Verfügbarkeit und Netzwerkstabilität. Darüber hinaus bietet Exchange 2016 Verbesserungen an der Exchange-Architektur. Wenn diese mit der Verfügbarkeit von Lastenausgleichslösungen von Drittanbietern (sowohl Hardware als auch Software) kombiniert werden, gibt es mehrere Optionen zur 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.

Unter Verwendung minimaler Serverrollen stellt Exchange 2016 Folgendes bereit:

  • Vereinfachte Bereitstellung, wobei auf dem Postfachserver Clientzugriffsdienste und Edge-Transport-Serverrollen ausgeführt werden.

  • Nachrichtenfluss, der in der Transport-Pipeline verwaltet wird; dabei handelt es sich um die Sammlung von Diensten, Verbindungen, Warteschlangen und Komponenten, die Nachrichten an die Transportdienstkategorisierung auf dem Postfachserver weiterleitet.

  • Hohe Verfügbarkeit durch die Bereitstellung von Lastenausgleichsmodulen zur Verteilung des Clientdatenverkehrs.

Der in Exchange 2013 eingeführte HTTP-Protokollstandard bedeutet, dass die Sitzungsaffinität in Exchange 2016 nicht mehr erforderlich ist. Die Sitzungsaffinität ermöglicht eine beständige Verbindung für Messaging-fähige Dienste, sodass der Benutzer seinen Benutzernamen und das Kennwort nicht mehrere Male 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. In Exchange 2016 ist es nun standardmäßig aktiviert.

Aufgrund des HTTP-Protokolls stellen alle systemeigenen Clients mithilfe von HTTP und HTTPS in Exchange 2016 eine Verbindung 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.

Aufgrund der geringeren Anzahl von Serverrollen für Exchange 2016 werden die Anforderungen für die Exchange-Implementierung und die Hardware vereinfacht. Die Anzahl von Serverrollen in Exchange 2016 wurde 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 (genau wie in früheren Versionen von Exchange) bereitstellt.

Konzeptionelle Übersicht über den Exchange-Lastenausgleichsprozess

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 wurde in Exchange 2016 beibehalten. 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 an den Serverrollen in Exchange 2016 finden Sie im Thema Exchange 2016-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.

Es werden nur die Informationen, die erforderlich sind, damit der Edge-Transport Antispam durchführen und einen End-to-End-Nachrichtenfluss aktivieren kann.

Edge-Transport

Verwaltet den gesamten eingehenden und ausgehenden Internetnachrichtenfluss mithilfe von:

  • E-Mail-Weiterleitung

  • Smarthost

  • Agents, die einen zusätzliche Antispam-Dienst bereitstellen.

  • Agents, die Transport zur Steuerung des Nachrichtenflusses anwenden

Kein Mitglied der Active Directory-Gesamtstruktur

Obwohl dies nicht erforderlich ist, befindet sich der Edge-Transport-Server, so wie in früheren Versionen von Exchange im Umkreisnetzwerk, um einen sicheren eingehenden und ausgehenden Nachrichtenfluss für Ihre Exchange-Organisation bereitzustellen.

Weitere Informationen zum Transportdienst finden Sie unter Understanding the Transport service on Edge Transport servers.

Ab Exchange 2016 verwenden alle systemeigenen Exchange-Clients das HTTP-Protokoll, um eine Verbindung zu einem designierten Dienst herzustellen, wobei dem Benutzer bei der Anmeldung HTTP-Cookies bereitgestellt werden, die mithilfe des SSL-Zertifikats für Clientzugriffsdienste verschlüsselt wurden. 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 einfach die IP-Adresse jedes Postfachservers bereitstellen, und der HTTP-Client würde die Aufgaben abarbeiten. Wenn ein Exchange-Server fehlschlägt, versucht das Protokoll eine Verbindung zu einem anderen Server herzustellen. Beim Lastenausgleich in DNS gibt es jedoch Nachteile, die im folgenden Abschnitt Lastenausgleichsoptionen in Exchange 2016 beschrieben werden.

Weitere Informationen zu HTTP und Exchange 2016 finden Sie im Thema MAPI über HTTP in Exchange 2016.

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. Lastenausgleichspaare sind nicht erforderlich, es wird eine Bereitstellung in Clustern empfohlen, um die Netzwerkstabilität zu verbessern.

Clientverbindungen mit Lastenausgleichsmodulen, die Anforderungen an DAG verteilen

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.

Diese Vereinfachung hat jedoch ihren Preis. In diesem Fall führt der DNS-Roundrobin keinen wirklichen Lastenausgleich für den Datenverkehr aus, da es keine programmgesteuerte Möglichkeit gibt, um sicherzustellen, dass jeder Server einen gerechten Anteil des Datenverkehrs erhält. Außerdem gibt es keine Überwachung auf Dienstebene, wenn daher ein einzelner Server fehlschlägt, werden Clients nicht automatisch an einen verfügbaren Dienst umgeleitet. 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; im Falle eines Dienstausfalls können Lastenausgleichsmodule den Datenverkehr auf einen anderen Server umleiten und das Problem offline lösen. 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 auf Ebene 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 auf Ebene 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

110

Postfach

POP3-Clients

143

Postfach

IMAP4-Clients

443

Postfach

HTTPS (Outlook im Web, AutoErmittlung, Webdienste, ActiveSync, MAPI über HTTP, RPC über HTTP, OAB, Exchange-Verwaltungskonsole)

993

Postfach

Sichere IMAP4-Clients

995

Postfach

Sichere POP3-Clients

In Exchange 2016 wird eine wesentliche 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, wird der Lastenausgleich so konfiguriert, dass die Integrität eines einzelnen virtuellen Verzeichnisses überprüft wird, da Outlook im Web-Anforderungen nicht von RPC-Anforderungen unterschieden werden können.

Aus der Perspektive des Lastenausgleichs in diesem Beispiel wird die Integrität pro Server und nicht pro Protokoll für den designierten Namespace angegeben. Administratoren müssen auswählen, welches virtuelle Verzeichnis als Ziel für den Integritätstest verwendet werden soll. Es wird empfohlen, dass Sie ein stark beanspruchtes virtuelles Verzeichnis auswählen. Wenn der Großteil der Benutzer beispielsweise Outlook im Web verwendet, sollten Sie für den Integritätstest das virtuelle Verzeichnis von Outlook im Web auswählen.

Solange das Ergebnis des Integritätstests von Outlook im Web fehlerfrei ist, behält der Lastenausgleich den Zielpostfachserver im Lastenausgleichspool bei. Wenn der Integritätstest für Outlook im Web allerdings aus irgendeinem Grund fehlschlägt, entfernt der Lastenausgleich den Zielpostfachserver aus dem Lastenausgleichspool für alle Anforderungen, die mit diesem Namespace verknüpft sind. Wenn der Integritätstest fehlschlägt, bedeutet dies also, dass alle Clientanforderungen für diesen Namespace an einen anderen Server gleitet werden, unabhängig vom Protokoll.

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 das Lastenausgleichsmodul für Ebene 7 konfiguriert ist, gibt es eine SSL-Terminierung, und das Lastenausgleichsmodul kennt die Ziel-URL.

Diese Konfiguration wird für Exchange 2016 empfohlen. Der Lastenausgleich ist so konfiguriert, dass die Integrität der Zielpostfachserver im Lastenausgleichspool überprüft wird; ein Integritätstest wird in jedem virtuellen Verzeichnis konfiguriert.

Solange das Ergebnis des Integritätstests von Outlook im Web fehlerfrei ist, behält der Lastenausgleich den Zielpostfachserver im Lastenausgleichspool für Outlook im Web bei. Wenn der Integritätstest für Outlook im Web allerdings 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 wird auch konfiguriert, um die Integrität der Zielpostfachserver im Lastenausgleichsmodul zu überprüfen. 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 für die stärker beteiligten Affinitätsoptionen, den Cookie-basierten Lastenausgleich oder die Sitzungs-ID von Secure Sockets Layer (SSL) mehr Verarbeitung und Ressourcen erforderlich sind. Wir empfehlen, dass Sie sich beim Anbieter erkundigen, wie sich die Sitzungsaffinität auf die Skalierbarkeit des Lastenausgleichs auswirkt.

Genau wie im vorherigen Szenario gilt: Solange das Ergebnis des Integritätstests von Outlook im Web fehlerfrei ist, behält der Lastenausgleich den Zielpostfachserver im Lastenausgleichspool für Outlook im Web bei. Wenn der Integritätstest für Outlook im Web allerdings 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 Ebene 4 und ist nicht so konfiguriert, dass die Sitzungsaffinität beibehalten wird. Die Lastenausgleichskonfiguration überprüft auch 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.

Die Überwachung der verfügbaren Server und Dienste ist für hochverfügbare Netzwerke entscheidend. Da einige Lastenausgleichslösungen nicht die Ziel-URL oder den Inhalt der Anforderung kennen, kann dies zu Komplexitäten für Exchange-Integritätstests führen.

Exchange 2016 enthält eine integrierte Überwachungslösung, die als Verwaltete Verfügbarkeit bezeichnet wird. Bei der verwalteten Verfügbarkeit, auch als „Aktive Überwachung“ oder „Lokale aktive Überwachung“ bezeichnet, handelt es sich um die Integration integrierter Überwachungs- und Wiederherstellungsaktionen in die integrierte, hochverfügbare Plattform von Exchange.

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 die Lastenausgleichsmodule den Datenverkehr nicht an einen Postfachserver weiterleiten, den die Verwaltete Verfügbarkeit als offline markiert hat, müssen Integritätstests für Lastenausgleichsmodule so konfiguriert werden, dass <virtualdirectory>/healthcheck.htm überprüft wird, z. B. https://mail.contoso.com/owa/healthcheck.htm.

Weitere Informationen zur verwalteten Verfügbarkeit finden Sie unter Verwaltete Verfügbarkeit.

 
Anzeigen: