Koexistenz von Hub-Transport- und Postfachserverrollen bei Verwendung von Datenbankverfügbarkeitsgruppen

  • Artikel

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2015-03-09

Microsoft Exchange Server 2007 unterstützt keine Hub-Transport- und Postfachserverrollen auf derselben Serverhardware, wenn Hochverfügbarkeitsfunktionen wie Einzelkopiecluster (SCC) oder fortlaufende Clusterreplikation (CCR) verwendet werden. Eine minimale Hochverfügbarkeitsbereitstellung in Exchange 2007 erfordert vier Server: Zwei Knoten für die hohe Verfügbarkeit von Postfächern und zwei Hub-Transport-Server für die Nachrichtenübertragungsredundanz.

Damit die Anzahl der Server verringert wird, die für die Bereitstellung einer Lösung mit hoher Verfügbarkeit erforderlich sind, unterstützt Exchange Server 2010 Hub-Transport- und Postfachserverrollen auf derselben Serverhardware, wenn Database Availability Groups (DAGs) verwendet werden. Exchange 2010 stellt eine Funktion mit der Bezeichnung Shadow-Redundanz bereit, die vor Datenverlusten bei der Übertragung von Nachrichten schützt. Wenn sie zusammen verwendet werden, bieten DAGs und Shadow-Redundanz eine äußerst belastbare Infrastruktur.

Dieses Thema konzentriert sich darauf, wie sich die Exchange 2010-Hub-Transport-Serverrolle verhält, wenn sie auf derselben Serverhardware wie der Postfachserver bereitgestellt wird, der Mitglied einer DAG ist. Weitere Informationen zu DAGs finden Sie unter Grundlegendes zu Database Availability Groups.

Übermitteln und Zustellen von Nachrichten

Die Shadow-Redundanz verhindert Datenverluste während der Nachrichtenübertragung, indem eine Kopie der Nachricht im Nachrichtenpfad beibehalten wird. Wenn eine Nachricht aufgrund eines Fehlers während der Übertragung verloren geht, wird die Schattenkopie der Nachricht von der Transportkomponente erneut übermittelt. Ausführliche Informationen zum Implementieren der Shadow-Redundanz finden Sie unter Grundlegendes zur Shadow-Redundanz.

Während der anfänglichen Nachrichtenübermittlung sind Postfachserver einbezogen, wenn ein Benutzer auf Senden klickt. Während der abschließenden Zustellung sind diese ebenfalls einbezogen, wenn die Nachricht im Posteingang des Empfängers gespeichert wird. Wenn eine Nachricht an die Transportkomponente übermittelt wird, befindet sich die primäre Kopie der Nachricht in den Warteschlangen des Hub-Transport-Servers, an den die Nachricht übermittelt wurde. Die Schattenkopie dieser Nachricht ist das Element, das im Ordner "Gesendete Elemente" des Absenders gespeichert wird. Wenn eine Nachricht zugestellt wird, befindet sich die primäre Kopie im Posteingang des Empfängers und die Schattenkopie der Nachricht wird im Transportdumpster gespeichert.

Bei einem Szenario mit hoher Verfügbarkeit, in dem die Hub-Transport- und Postfachserverrollen auf derselben Serverhardware vorhanden sind, ist es wichtig zu vermeiden, dass sich beide Kopien einer Nachricht auf demselben Server befinden. Beachten Sie das Bereitstellungsszenario in der folgenden Abbildung. Die Topologie besteht aus zwei Exchange-Servern, die an einer DAG mit installierter Hub-Transport-Serverrolle beteiligt sind. Die Datenbanken "DB1" und "DB2" sind Teil der DAG. Aktive Datenbanken werden in Grün und passive Datenbanken in Blau angezeigt.

Topologie für zwei Server mit hoher Verfügbarkeit mit Hub-Transport- und Postfachserverrollen

Hochverfügbarkeitstopologie mit zwei Servern mit Hub- und Postfachrolle

Nehmen Sie in dieser Topologie an, dass ein Benutzer eine Nachricht sendet, dessen Postfach sich auf "DB1" befindet. Wenn diese Nachricht an die Hub-Transport-Serverrolle auf "Server1" übermittelt wird, werden sowohl die primären als auch die Schattennachrichten physikalisch auf "Server1" gespeichert. Die primären Nachrichten gelangen in die Warteschlangen des Hub-Transport-Servers und die Schattennachrichten befinden sich im Ordner "Gesendete Elemente" des Absenders, wie in der folgenden Abbildung veranschaulicht.

Unerwünschter Übermittlungspfad

Unerwünschter Übermittlungspfad

Wenn die Hub-Transport-Serverrolle auf "Server1" eine Nachricht empfängt, die an einen Benutzer auf"DB1" gerichtet ist, wird die Nachricht direkt zugestellt und sowohl die primären als auch die Schattennachrichten werden physikalisch auf "Server1" gespeichert. Die primären Nachrichten gelangen in den Posteingang des Empfängers und die Schattennachrichten befinden sich im Transportdumpster, wie in der folgenden Abbildung veranschaulicht. Wenn bei einer dieser Instanzen ein Serverfehler auftritt, besteht die Möglichkeit, dass die Nachricht verloren geht.

Unerwünschter Zustellungspfad

Unerwünschter Zustellungspfad

Zur Vermeidung dieser Szenarien, bei denen es zu Nachrichtenverlusten kommen kann, versucht Exchange, Nachrichten über eine Route zu übermitteln oder zuzustellen, die sicherstellt, dass die primären und Schattenkopien von Nachrichten auf verschiedenen physikalischen Servern gespeichert werden. Die veränderten Verhaltensweisen bei der Übermittlung und Zustellung von Nachrichten werden im folgenden Abschnitt besprochen.

Verhalten bei der Nachrichtenübermittlung

Wenn ein Benutzer, dessen Postfach sich in einer Datenbank befindet, die Mitglied einer DAG ist, eine Nachricht sendet, bevorzugt der Mailübergabedienst Remote-Hub-Transport-Server, wenn dieser erkennt, dass der Hub-Transport-Server ebenfalls auf dem lokalen Server installiert ist. Wie in der Abbildung "Topologie für zwei Server mit hoher Verfügbarkeit mit Hub-Transport- und Postfachserverrollen" gezeigt, versucht der Mailübergabedienst, den Hub-Transport-Server für die Nachrichtenübermittlung zu verwenden, der auf "Server2" installiert ist, wenn ein Benutzer eine Nachricht sendet, dessen Postfach sich auf "DB1" befindet. Die folgende Abbildung zeigt diesen bevorzugten Pfad für die Nachrichtenübermittlung.

Bevorzugter Übermittlungspfad

Bevorzugter Übermittlungspfad

Für den Fall, dass keine weiteren Hub-Transport-Server am Standort verfügbar sind (wenn z. B. "Server2" aufgrund von geplanten Wartungsmaßnahmen nicht verfügbar ist), übermittelt der Nachrichtenübergabedienst die Nachricht wieder an den lokalen Hub-Transport-Server. Obwohl dies hinsichtlich der Redundanz ein unerwünschter Übermittlungsfahrt ist, wird Exchange die Zustellung von Nachrichten nicht verzögern. Dieser Ausweichübermittlungspfad (Fallback) ist aufgrund der Verfügbarkeit und niedrigen Zustellungswartezeit wünschenswert.

Verhalten bei der Nachrichtenzustellung

In den meisten Fällen verändert sich das Verhalten beim Nachrichtenrouting und bei der Zustellung nicht. Wenn beispielsweise der in Abbildung "Topologie für zwei Server mit hoher Verfügbarkeit mit Hub-Transport- und Postfachserverrollen" gezeigte "Server1" eine Nachricht für einen Empfänger auf "DB2" empfängt, stellt er diese Nachricht normal zu, da diese Datenbank auf einem anderen Server aktiv ist. Das einzige Szenario, in dem ein Hub-Transport-Server eine eingehende Nachricht anders verarbeitet, ist, wenn sich das Zielpostfach in einer Datenbank befindet, die zu einer DAG gehört und ebenfalls auf dem lokalen Server aktiv ist. Da eine direkte Zustellung in dieser Situation dazu führt, dass sich sowohl die zugestellte Nachricht als auch die Kopie im Transportdumpster auf demselben Server befinden, leitet der Hub-Transport-Server diese Nachricht stattdessen an einen anderen Hub-Transport-Server innerhalb desselben Standorts weiter. Die folgende Abbildung zeigt den Nachrichtenzustellungspfad in diesem Szenario.

Bevorzugter Zustellungspfad

Bevorzugter Zustellungspfad

Für den Fall, dass keine weiteren Hub-Transport-Server am Standort verfügbar sind, weicht der Hub-Transport-Server dennoch auf die lokale Zustellung aus, obwohl dies hisichtlich der Redundanz unerwünscht ist. Dieser Ausweichzustellungspfad (Fallback) ist wiederum aufgrund der Verfügbarkeit und niedrigen Zustellungswartezeit wünschenswert.

Meldungsflussszenarien

In diesem Abschnitt wird ausführlich erläutert, was in verschiedenen Meldungsflussszenarien geschieht, wenn Hub-Transport- und Postfachserverrollen auf demselben Server vorhanden sind. Die in der folgenden Abbildung gezeigte Topologie wird zum Veranschaulichen verschiedener möglicher Meldungsflussszenarien verwendet.

Beispieltopologie für Meldungsflussszenarien

Beispieltopologie für Meldungsflussszenarien

In der folgenden Tabelle wird gezeigt, wie die Hub-Transport-Serverrolle auf "Server1" Nachrichten in verschiedenen Szenarien verarbeitet. In sämtlichen Fällen gilt "Server1" als Einstiegspunkt.

Absenderstandort Empfängerstandort Normaler Nachrichtenpfad Szenarien für hohe Verfügbarkeit

DB1, aktiv auf Server1

DB1, aktiv auf Server1

  1. Der Übergabedienst auf "Server1" übermittelt eine Nachricht an die Hub-Transport-Serverrolle auf "Server2".

  2. Die Hub-Transport-Serverrolle auf "Server2" stellt die Nachricht an "DB1" auf "Server1" zu und fügt die Nachricht zum Transportdumpster auf "Server2" hinzu.

  • Wenn "Server1" vor Abschluss der Nachrichtenübermittlung einen Fehler aufweist, geht möglicherweise die Nachricht im Postausgang des Absenders verloren.

  • Wenn "Server2" vor Abschluss der Nachrichtenübermittlung einen Fehler aufweist, wird die Nachricht an die Hub-Transport-Serverrolle auf "Server1" übermittelt.

  • Wenn "Server1" nach Abschluss der Nachrichtenübermittlung an die Hub-Transport-Serverrolle auf "Server2" einen Fehler aufweist, wird "DB1" auf "Server2" aktiviert. Die Nachricht wird auf "Server2" in die Warteschlange gestellt, bis "DB1" eingebunden wurde. Anschließend stellt die Hub-Transport-Serverrolle die Nachricht lokal zu.

  • Wenn "Server2" nach Abschluss der Nachrichtenübermittlung an die Hub-Transport-Serverrolle auf "Server2" einen Fehler aufweist, wird die Schattennachricht in "DB1" erneut an die Hub-Transport-Serverrolle auf "Server1" übermittelt, die die Nachricht lokal zugestellt.

  • Wenn "Server1" nach Abschluss der Nachrichtenzustellung einen Fehler aufweist, wird "DB1" auf "Server2" aktiviert. Wenn die zugestellte Nachricht noch nicht an die Datenbank übergeben wurde, wird sie aus dem Transportdumpster auf "Server2" erneut zugestellt.

DB1, aktiv auf Server1

DB2, aktiv auf Server2

  1. Der Übergabedienst auf "Server1" übermittelt die Nachricht an die Hub-Transport-Serverrolle auf "Server2".

  2. Die Hub-Transport-Serverrolle auf "Server2" leitet die Nachricht zur Hub-Transport-Serverrolle auf "Server1" um.

  3. Die Hub-Transport-Serverrolle auf "Server1" stellt die Nachricht an "DB2" auf "Server2" zu und fügt die Nachricht zum Transportdumpster auf "Server1" hinzu.

  • Sämtliche Serverfehler, die vor Abschluss der Nachrichtenübermittlung auftreten, werden wie in der vorherigen Zeile beschrieben behandelt.

  • Wenn "Server1" nach Abschluss der Nachrichtenübermittlung an die Hub-Transport-Serverrolle auf "Server2" einen Fehler aufweist, stellt die Hub-Transport-Serverrolle auf "Server2" die Nachricht lokal zu.

  • Wenn "Server2" nach Abschluss der Nachrichtenübermittlung an die Hub-Transport-Serverrolle auf "Server2" einen Fehler aufweist, wird "DB2" auf "Server1" aktiviert. Nachdem die Hub-Transport-Serverrolle auf "Server1" erkannt hat, dass die Hub-Transport-Serverrolle auf "Server2" nicht verfügbar ist, übermittelt sie die Schattennachricht erneut. Nachdem "DB2" auf "Server1" eingebunden ist, wird die Nachricht lokal zugestellt.

  • Wenn "Server1" nach der Umleitung der Nachricht zu "Server1" einen Fehler aufweist, übermittelt die Hub-Transport-Serverrolle auf "Server2" die Schattennachricht erneut, nachdem sie erkannt hat, dass die Hub-Transport-Serverrolle auf "Server1" nicht verfügbar ist. Die Nachricht wird dann lokal zugestellt.

  • Wenn "Server2" nach Umleitung der Nachricht zu "Server1" einen Fehler aufweist, wird "DB2" auf "Server1" aktiviert. Die Nachricht verbleibt in der Warteschlange auf "Server1", bis "DB2" auf "Server1" eingebunden ist. Anschließend wird sie lokal zugestellt.

  • Wenn "Server2" nach Abschluss der Nachrichtenzustellung einen Fehler aufweist, wird "DB2" auf "Server1" aktiviert. Wenn die zugestellte Nachricht noch nicht an die Datenbank übergeben wurde, wird sie aus dem Transportdumpster auf "Server1" erneut zugestellt.

Extern

DB1, aktiv auf Server1

  1. Die Hub-Transport-Serverrolle auf "Server1" leitet die Nachricht zur Hub-Transport-Serverrolle auf "Server2" um.

  2. Die Hub-Transport-Serverrolle auf "Server2" stellt die Nachricht an "DB1" auf "Server1" zu und fügt die Nachricht zum Transportdumpster auf "Server2" hinzu.

  • Wenn "Server1" vor Abschluss des Nachrichtenempfangs von "Edge1" einen Fehler aufweist, versucht "Edge1", die Nachricht an die Hub-Transport-Serverrolle auf "Server2" zuzustellen.

  • Wenn "Server1" nach Abschluss des Nachrichtenempfangs von "Edge1" einen Fehler aufweist, übermittelt "Edge1" die Nachricht erneut an die Hub-Transport-Serverrolle auf "Server2", nachdem erkannt wurde, dass die Hub-Transport-Serverrolle auf "Server1" nicht verfügbar ist. Die Hub-Transport-Serverrolle auf "Server2" stellt die Nachricht dann lokal zu, nachdem "DB1" auf "Server2" eingebunden wurde.

  • Alle anderen Fehlerszenarien werden wie in der ersten Zeile beschrieben behandelt.

Extern

DB2, aktiv auf Server2

  1. Die Hub-Transport-Serverrolle auf "Server1" stellt die Nachricht an "DB2" auf "Server2" zu und fügt die Nachricht zum Transportdumpster auf "Server1" hinzu.

  • Wenn "Server1" vor Abschluss des Nachrichtenempfangs von "Edge1" einen Fehler aufweist, versucht "Edge1" die Nachricht an die Hub-Transport-Serverrolle auf "Server2" zuzustellen.

  • Wenn "Server1" nach Abschluss des Nachrichtenempfangs von "Edge1", aber vor der Zustellung an "DB2" auf "Server2" einen Fehler aufweist, übermittelt "Edge1" die Nachricht erneut an die Hub-Transport-Serverrolle auf "Server2". Der Grund ist, dass "Server1" erst nach erfolgreicher Zustellung an "DB2" eine Bestätigung an "Edge1" sendet. Da "Edge1" keine Bestätigung empfangen hat, wird die Nachricht erneut übermittelt, nachdem erkannt wurde, dass "Server1" nicht verfügbar ist.

  • Wenn "Server2" nach Abschluss der Nachrichtenzustellung einen Fehler aufweist, wird "DB2" auf "Server1" aktiviert. Wenn die zugestellte Nachricht noch nicht an die Datenbank übergeben wurde, wird sie aus dem Transportdumpster auf "Server1" erneut zugestellt.

Die vorangehende Tabelle konzentriert sich auf das minimale Szenario, bei dem nur zwei Hub-Transport-Server an einem Standort vorhanden sind und beide gemeinsam mit Postfachserverrollen verwendet werden, die Mitglieder von DAGs sind. Bei komplexeren Bereitstellungen, in denen zusätzliche dedizierte Hub-Transport-Server zur Verfügung stehen, werden diese Server auch beim Treffen von Routingentscheidungen verwendet. Wenn Ihre Bereitstellung jedoch ausreichend groß ist, dass Sie dedizierte Hub-Transport-Server einsetzen können, erweist es sich als bewährte Methode, die Hub-Transport-Serverrolle nicht auf Postfachservern zu installieren, die Mitglieder einer DAG sind.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.