Koexistenz von Hub-Transport- und Postfachserverrollen bei Verwendung von Datenbankverfügbarkeitsgruppen
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
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
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
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
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
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
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 |
|
|
DB1, aktiv auf Server1 |
DB2, aktiv auf Server2 |
|
|
Extern |
DB1, aktiv auf Server1 |
|
|
Extern |
DB2, aktiv auf Server2 |
|
|
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.