Shadow-Redundanz – Nachrichtenübermittlungsszenarios

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

Letztes Änderungsdatum des Themas: 2010-06-07

Die Funktion der Shadow-Redundanz in Microsoft Exchange Server 2010 bietet Redundanz für Nachrichten, während diese übertragen werden. Der allgemeine Meldungsfluss wird unter Grundlegendes zur Shadow-Redundanz erläutert. In diesem Thema werden die Vorgänge für jedes spezifische Meldungsflussszenario, das Exchange beinhalten kann, ausführlich erörtert.

Nachrichtenübermittlungszenarien

In der folgenden Abbildung werden die möglichen Redundanzszenarien in einer Exchange-Organisation veranschaulicht, und es wird aufgezeigt, wie die Nachrichtenredundanz in jedem einzelnen Szenario erreicht wird. Der schattierte Bereich kennzeichnet Shadow-Redundanz. Durch die Exchange 2010-Shadow-Redundanz wird ein Datenverlust während der Übertragung von Nachrichten innerhalb des schattierten Bereichs verhindert.

Nachrichtenübermittlungszenarien mit Shadow-Redundanz

Wie aus der vorangehenden Abbildung hervorgeht, kann für alle in einer Exchange-Organisation möglichen Nachrichtenübermittlungspfade eines der folgenden Szenarien angenommen werden:

A. MAPI-/Windows Mobile-Clientübermittlung

B. Nachrichtenübermittlung vom Postfachserver an den Hub-Transport-Server

C. Nachrichtenzustellung vom Hub-Transport-Server an den Postfachserver

D. Nachrichtenübermittlung zwischen Exchange 2010-Transportservern

E. Nachrichtenübermittlung von Exchange 2010-Transportservern an Mailserver, die keine Shadow-Redundanz unterstützen

F. Nachrichtenübermittlung von Mailservern, die keine Shadow-Redundanz unterstützen, an Exchange 2010-Transportserver

In den folgenden Abschnitten werden die Vorgänge für jedes Nachrichtenübermittlungsszenario erläutert.

A. MAPI-/Windows Mobile-Clientübermittlung

Nachrichtenübermittlungen von MAPI- oder Windows Mobile-Clients sind nicht redundant. Nachdem die Nachricht erfolgreich auf dem Postfachserver gespeichert wurde, können Exchange-Funktionen für hohe Verfügbarkeit in Kraft treten und dazu beitragen, Datenverluste zu verhindern. Dieses Szenario bietet ein vollständiges Bild des Meldungsflusses (vom Anfang bis zum Ende).

Zurück zur Liste der Szenarien zur Nachrichtenübermittlung

B. Nachrichtenübermittlung vom Postfachserver an den Hub-Transport-Server

Die folgenden Aktionen werden ausgeführt, wenn Nachrichten von einem Exchange 2010-Postfachserver an einen Exchange 2010-Hub-Transport-Server übermittelt werden.

1. Der Mailübergabedienst benachrichtigt den Hub-Transport-Server, dass eine neue Nachricht verfügbar ist.

2. Der Hub-Transport-Server ruft die Nachricht aus dem Postausgang des Postfachs ab, von dem die Nachricht gesendet wurde, und speichert sie in der Datenbank.

3. Wenn die Nachricht für Empfänger auf Postfachservern vorgesehen ist, die sich am selben Active Directory-Standort befinden, wird die Nachricht vom Hub-Transport-Server unter Ausführung der in Szenario C aufgeführten Schritte an die Zielpostfächer gesendet. Für alle anderen Empfänger übermittelt der Hub-Transport-Server die Nachricht an den nächsten Hop.

4. Nachdem die Zustellung an den nächsten Hop erfolgt ist, wird der Postfachserver vom Hub-Transport-Server darüber benachrichtigt, dass die Verarbeitung der Nachricht abgeschlossen ist und die Nachricht in Besitz genommen wurde. Im Anschluss an diese Benachrichtigung wird die Nachricht aus dem Postausgang gelöscht.

5. Wenn keiner der anderen Hops für die Nachricht Shadow-Redundanz unterstützt, wird die Nachricht vom Hub-Transport-Server gelöscht. Andernfalls wird die Nachricht in eine Shadow-Nachricht konvertiert, indem sie in den Shadow-Warteschlangen für die Hops gespeichert wird, denen die Nachricht zugestellt wurde.

Zurück zur Liste der Szenarien zur Nachrichtenübermittlung

C. Nachrichtenzustellung vom Hub-Transport-Server an den Postfachserver

Die folgenden Aktionen werden ausgeführt, wenn Nachrichten von einem Exchange 2010-Hub-Transport-Server an einen Exchange 2010-Postfachserver übermittelt werden.

1. Der Hub-Transport-Server sendet die Nachricht an die Zielpostfächer.

2. Nachdem die Nachrichtenzustellung an alle Zielpostfächer erfolgt ist, fügt der Hub-Transport-Server die Nachricht dem Transportdumpster hinzu.

3. Der Hub-Transport-Server stellt Löschbenachrichtigungen an den Hop in die Warteschlange, von dem er die Nachricht empfangen hat. Diese Löschbenachrichtigungen werden erstellt, wenn der Hop Abfragen an den Hub-Transport-Server sendet.

4. Der vorherige Hop löscht die entsprechende Shadow-Nachricht.

Zurück zur Liste der Szenarien zur Nachrichtenübermittlung

D. Nachrichtenübermittlung zwischen Exchange 2010-Transportservern

Der Prozess der Nachrichtenübermittlung vollzieht sich für den gesamten Nachrichtenaustausch zwischen Transportservern mit Exchange 2010 auf dieselbe Art und Weise. Es spielt dabei keine Rolle, ob der Austausch zwischen zwei Hub-Transport-Servern oder zwischen einem Hub-Transport-Server und einem Edge-Transport-Server stattfindet. Die folgenden Aktionen werden ausgeführt, wenn eine Nachricht von einem Exchange 2010-Transportserver an einen anderen Transportserver gesendet wird. Aus Gründen der Klarheit gehen wir hier davon aus, dass der die Nachricht sendende Server die Bezeichnung "Hub01" trägt und der Server, der die Nachricht empfängt, mit "Edge01" bezeichnet wird.

1. Hub01 stellt eine SMTP-Verbindung mit Edge01 her.

2. Edge01 bietet Unterstützung für Shadow-Redundanz.

3. Hub01 fordert durch Ausgeben eines XSHADOW-Befehls Shadow-Redundanz in der SMTP-Sitzung. Der Prozess ist mit dem Einrichten von TLS (Transport Layer Security) in einer SMTP-Sitzung vergleichbar.

4. Für jede Nachricht, die Hub01 an Edge01 senden muss, gilt Folgendes:

   1. Hub01 überträgt die Nachricht an Edge01.

   2. Edge01 markiert die Nachricht als Shadow-Nachricht von Hub01.

   3. Hub01 markiert Edge01 als primären Server und fügt ihn der Shadow-Warteschlange für Edge01 hinzu.

   4. Hub01 bereitet Löschbenachrichtigungen für die Nachricht vor, die an den Hop gesendet wird, von dem die Nachricht empfangen wurde.

5. Hub01 fragt Edge01 im Hinblick auf den Löschstatus von Nachrichten ab, die zuvor an Edge01 übermittelt wurden.

6. Edge01 sendet alle für Hub01 vorbereiteten Löschbenachrichtigungen. Diese können für in derselben SMTP-Sitzung gesendete Nachrichten oder für Nachrichten vorgesehen sein, die während vorheriger SMTP-Sitzungen gesendet wurden.

7. Hub01 löscht alle Shadow-Nachrichten, für die Edge01 eine Löschbenachrichtigung gesendet hat.

Zurück zur Liste der Szenarien zur Nachrichtenübermittlung

E. Nachrichtenübermittlung von Exchange 2010-Transportservern an Mailserver, die keine Shadow-Redundanz unterstützen

Weder Exchange Server 2007-Transportserver noch Exchange Server 2003-Bridgeheadserver unterstützen Shadow-Redundanz. Im Falle eines Koexistenzszenarios mit früheren Versionen von Exchange kann eine Nachrichtenzustellung durch Exchange 2010-Redundanzfunktionen daher nur bis zum Exchange-Legacyhop, jedoch nicht bis zum jeweiligen Ziel garantiert werden. Dasselbe gilt für ein Szenario, in dem Exchange 2010-Edge-Transport-Server Nachrichten an Mailserver ohne Exchange senden.

Die folgenden Aktionen werden ausgeführt, wenn ein Exchange 2010-Hub-Transport-Server eine Nachricht an einen Exchange-Transportserver sendet, auf dem eine frühere Version von Exchange ausgeführt wird, oder wenn ein Exchange 2010-Edge-Transport-Server eine Nachricht an einen Mailserver ohne Exchange sendet. Aus Gründen der Klarheit gehen wir hier davon aus, dass ein Exchange 2010-Hub-Transport-Server namens "Hub01" eine Nachricht an einen älteren Exchange-Transportserver mit der Bezeichnung "Legacy01" sendet.

1. Hub01 stellt eine SMTP-Verbindung mit Legacy01 her.

2. Legacy01 bietet keine Unterstützung für Shadow-Redundanz.

3. Da Legacy01 keine Unterstützung für Shadow-Redundanz bietet, initiiert Hub01 keine Shadow-Redundanz in der SMTP-Sitzung.

4. Hub01 übermittelt die Nachricht an Legacy01.

5. Hub01 löscht die Nachricht.

6. Hub01 bereitet Löschbenachrichtigungen für den Hop vor, von dem die Nachricht empfangen wurde.

Zurück zur Liste der Szenarien zur Nachrichtenübermittlung

F. Nachrichtenübermittlung von Mailservern, die keine Shadow-Redundanz unterstützen, an Exchange 2010-Transportserver

Es gibt vier Einstiegspunkte für eine Exchange-Organisation, in der ein Mailserver, der keine Shadow-Redundanz unterstützt, eine SMTP-Verbindung mit einem Exchange 2010-Transportserver herstellen und Nachrichten senden kann:

• Ein Exchange 2010-UM-Server (Unified Messaging), der eine Verbindung mit einem Exchange 2010-Hub-Transport-Server hergestellt

• Ein Exchange-Transportserver, auf dem Exchange 2007 oder Exchange 2003 ausgeführt wird, der eine Verbindung mit einem Exchange 2010-Hub-Transport-Server herstellt

• Ein Nicht-Exchange-Mailserver im Internet, der eine Verbindung mit einem Exchange 2010-Edge-Transport-Server herstellt

• Ein Nicht-Exchange-Mailserver in der Organisation (z. B. ein UNIX-Server) oder ein SMTP-Client, der Nachrichten an einen Exchange 2010-Hub-Transport-Server übermittelt.

In diesem Szenario erreicht Exchange 2010 Shadow-Redundanz mit einer Funktion, die als verzögerte Bestätigung bezeichnet wird. Wenn ein Exchange 2010-Transportserver eine Nachricht von einem Mailserver empfängt, der keine Shadow-Redundanz unterstützt, wird das Senden einer Bestätigung an den sendenden Mailserver verzögert, bis die erfolgreiche Zustellung der Nachricht an das jeweilige Ziel bestätigt wurde. Weitere Informationen zur verzögerten Bestätigung finden Sie unter Grundlegendes zur Shadow-Redundanz.

Zur Veranschaulichung dieses Szenarios gehen wir hier davon aus, dass ein Exchange 2010-Edge-Transport-Server namens "Edge01" eine Nachricht von einem Nicht-Exchange-Mailserver im Internet mit der Bezeichnung "Internet01" empfängt. In diesem Beispiel werden die folgenden Aktionen ausgeführt:

1. Internet01 stellt eine SMTP-Verbindung mit Edge01 her.

2. Edge01 bietet Unterstützung für Shadow-Redundanz.

3. Da Internet01 keine Shadow-Redundanz unterstützt, sendet er einfach die Nachricht an Edge01.

4. Edge01 markiert die Nachricht als Nachricht mit verzögerter Bestätigung.

5. Edge01 sendet die Nachricht unter Ausführung der in Szenario D aufgeführten Schritte an die nächsten Hops.

6. Edge01 fragt die nächsten Hops im Hinblick auf den Löschstatus der Nachricht ab.

7. Nachdem Edge01 Löschbenachrichtigungen von allen nächsten Hops empfangen hat, sendet er die Bestätigung an Internet01.

8. Edge01 löscht die Nachricht aus seiner Datenbank.

   Hinweis

   Wenn Edge01 die erfolgreiche Zustellung der Nachricht an alle nächsten Hops nicht innerhalb von 30 Sekunden überprüfen kann, erfolgt ein Timeout, und es wird eine Bestätigung an Internet01 gesendet. Dieser Timeoutwert wird vom Wert des Attributs MaxAcknowledgementDelay des Empfangsconnectors gesteuert.

Zurück zur Liste der Szenarien zur Nachrichtenübermittlung

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.