Grundlegendes zur Shadow-Redundanz
Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3
Letztes Änderungsdatum des Themas: 2015-03-09
Strategien für eine hohe Verfügbarkeit von Exchange konzentrieren sich auf die Verfügbarkeit und Wiederherstellbarkeit von Daten, die in Postfachdatenbanken gespeichert sind. Wenn Sie eine hoch verfügbare Lösung für Ihre Postfachserver implementieren, gehen E-Mail-Nachrichten nicht verloren und können nach einem Fehler einfach wiederhergestellt werden, wenn sie bereits in einem Postfach empfangen wurden.
Diese Strategien greifen jedoch nicht für Nachrichten, die sich in der Übertragung befinden. Wenn ein Hub-Transport-Server während der Verarbeitung von Nachrichten ausfällt und nicht wiederherstellt werden kann, kann dies zu Datenverlusten führen. Mit einem steigenden Aufkommen von Nachrichten, die von Hub-Transport-Servern verarbeitet werden, steigt für Administratoren auch die Sorge in Bezug auf einen möglichen Datenverlust.
In Microsoft Exchange Server 2007 wurde der Transportdumpster für die Hub-Transport-Serverrolle eingeführt. Ein Exchange 2007-Hub-Transport-Server verwaltet eine Warteschlange der Nachrichten, die vor kurzem an Empfänger mit Postfächern auf einem Postfachclusterserver zugestellt wurden. Bei einem Failover fordert der Postfachclusterserver automatisch jeden Hub-Transport-Server am Active Directory-Standort auf, alle Nachrichten aus der Transportdumpster-Warteschlange erneut zu senden. Auf diese Weise gehen in der Zeit, die für das Clusterfailover benötigt wird, keine Nachrichten verloren. Wenngleich auf diese Weise eine grundlegende Transportredundanz bereitgestellt wird, steht diese nur für die Nachrichtenzustellung in einer CCR-Umgebung (Cluster Continuous Replication) zur Verfügung und verhindert nicht den potenziellen Nachrichtenverlust, wenn sich Nachrichten in der Übertragung zwischen Hub-Transport- und Edge-Transport-Servern befinden.
In Exchange Server 2010 wird die Shadow-Redundanz eingeführt, um für Nachrichten während der gesamten Übertragungszeit Redundanz bereitzustellen. Diese Lösung beruht auf einer Technik, die dem Transportdumpster ähnelt. Mit der Shadow-Redundanz wird das Löschen einer Nachricht aus den Transportdatenbanken verzögert, bis der Transportserver sichergestellt hat, dass die jeweilige Nachricht an alle nächsten Hops vollständig zugestellt wurde. Wenn bei einem der nächsten Hops ein Fehler auftritt, bevor die erfolgreiche Zustellung gemeldet wurde, wird die Nachricht erneut an diesen nächsten Hop zugestellt.
Shadow-Redundanz bietet die folgenden Vorteile:
Es entfällt die Abhängigkeit vom Zustand eines bestimmten Hub-Transport- oder Edge-Transport-Servers. Solange redundante Nachrichtenpfade in der Routingtopologie vorhanden sind, werden Transportserver austauschbar.
Wenn ein Transportserver ausfällt, können Sie ihn aus der Produktionsumgebung entfernen, ohne die zugehörigen Warteschlangen zu leeren oder Nachrichten zu verlieren.
Wenn Sie einen Hub-Transport-Server oder Edge-Transport-Server aktualisieren möchten, können Sie diesen Server jederzeit offline schalten, ohne das Risiko eines Nachrichtenverlusts einzugehen.
Es entfällt die Notwendigkeit zur Bereitstellung von Hardwareredundanz für Transportserver.
Es wird weniger Bandbreite benötigt als beim Erstellen doppelter Kopien von Nachrichten auf mehreren Servern. Durch die Shadow-Redundanz wird lediglich zusätzlicher Netzwerkverkehr durch den Austausch von Informationen zum Löschstatus zwischen Transportservern generiert. Als Löschstatus werden die Informationen bezeichnet, die jeder Transportserver verwaltet. Er gibt an, dass eine Nachricht aus der Transportdatenbank gelöscht werden kann.
Die Shadow-Redundanz bietet Ausfallsicherheit und vereinfacht die Wiederherstellung nach einem Transportserverausfall.
Die Shadow-Redundanz wird durch eine Erweiterung des SMTP-Diensts implementiert. Die Diensterweiterung ermöglicht SMTP-Hosts das Aushandeln der Unterstützung für Shadow-Redundanz und den Austausch des Löschstatus für Shadow-Nachrichten.
Möchten Sie wissen, welche Verwaltungsaufgaben es im Zusammenhang mit Transportservern gibt? Informationen hierzu finden Sie unter Verwalten von Transportservern.
Komponenten der Shadow-Redundanz
Die folgende Tabelle enthält Beschreibungen aller Komponenten der Shadow-Redundanz.
Komponenten der Shadow-Redundanz
| Komponente | Beschreibung |
|---|---|
Primäre Nachricht |
Die ursprünglich zur Zustellung an den Transport gesendete Nachricht. |
Shadow-Nachricht |
Die Kopie einer Nachricht, die ein Transportserver beibehält, bis bestätigt wurde, dass alle nächsten Hops für diese Nachricht erfolgreich abgeschlossen wurden. |
Primärer Server |
Der Transportserver, der zurzeit eine Nachricht verarbeitet. |
Shadow-Server |
Der Transportserver, der Shadow-Kopien einer Nachricht enthält, nachdem die Nachricht an den primären Server zugestellt wurde. |
Shadow-Warteschlange |
Die Warteschlange, die ein Transportserver zum Speichern von Shadow-Nachrichten verwendet. Ein Transportserver verfügt über separate Shadow-Wartschlangen für jeden Hop, an den die primäre Nachricht zugestellt wurde. |
Löschstatus |
Die von einem Transportserver für Shadow-Nachrichten verwaltete Information, dass eine Nachricht gelöscht werden kann. |
Löschbenachrichtigung |
Die von einem primären Server an einen Shadow-Server gesendete Antwort, dass eine Nachricht gelöscht werden kann. |
Shadow-Redundanz-Manager |
Die Transportkomponente, die die Shadow-Redundanz verwaltet. |
Taktsignal |
Der Prozess des Transportservers zur Überprüfung der gegenseitigen Verfügbarkeit. |
Zurück zum Seitenanfang
Nachrichtenfluss bei der Shadow-Redundanz
Zur Veranschaulichung der Nachrichtenübermittlung bei aktivierter Shadow-Redundanz können Sie sich ein einfaches Szenario vorstellen, bei dem ein Hub-Transport-Server über einen Edge-Transport-Server eine Nachricht an einen Drittanbieter-E-Mail-Server im Umkreisnetzwerk sendet.
Nachrichtenfluss bei aktivierter Shadow-Redundanz
.gif "Nachrichtenübermittlung mit Shadow-Redundanz")
In diesem Szenario umfasst der Nachrichtenfluss die folgenden Phasen:
Der Hub-Transport-Server stellt eine Nachricht an den Edge-Transport-Server zu.
Der Hub-Transport-Server öffnet eine SMTP-Sitzung mit dem Edge-Transport-Server.
Der Edge-Transport-Server kündigt die Unterstützung von Shadow-Redundanz an.
Der Hub-Transport-Server weist den Edge-Transport-Server an, den Löschstatus zu verfolgen.
Der Hub-Transport-Server übermittelt die Nachricht an den Edge-Transport-Server.
Der Edge-Transport-Server bestätigt den Empfang der Nachricht und protokolliert die Identität des Hub-Transport-Servers zum Senden von Löschinformationen für die Nachricht.
Der Hub-Transport-Server verschiebt die Nachricht in die Shadow-Warteschlange für den Edge-Transport-Server und markiert den Edge-Transport-Server als primären Server. Der Hub-Transport-Server wird zum Shadow-Server.
Der Edge-Transport-Server stellt die Nachricht an den nächsten Hop zu.
Der Edge-Transport-Server übermittelt die Nachricht an einen Drittanbieter-E-Mail-Server.
Der Drittanbieter-E-Mail-Server bestätigt den Empfang der Nachricht.
Der Edge-Transport-Server aktualisiert den Löschstatus für die Nachricht mit der Information, dass die Zustellung abgeschlossen wurde.
Der Hub-Transport-Server fragt den Löschstatus beim Edge-Transport-Server ab (bei erfolgreicher Zustellung).
Am Ende jeder SMTP-Sitzung mit dem Edge-Transport-Server fragt der Hub-Transport-Server den Löschstatus zuvor übertragener Nachrichten beim Edge-Transport-Server ab. Wenn der Hub-Transport-Server keine SMTP-Sitzungen mit dem Edge-Transport-Server geöffnet hat, nachdem die erste Nachricht übertragen wurde, wird eine SMTP-Sitzung mit dem Edge-Transport-Server geöffnet, um nach einem bestimmten Zeitraum den Löschstatus abzufragen.
Der Edge-Transport-Server überprüft den lokalen Löschstatus, sendet eine Liste der zugestellten Nachrichten und entfernt die Löschinformationen.
Der Hub-Transport-Server löscht die Liste der Nachrichten aus seiner Shadow-Warteschlange.
Der Hub-Transport-Server fragt den Löschstatus beim Edge-Transport-Server ab und übermittelt die Nachricht erneut (bei nicht erfolgreicher Zustellung).
Wenn der Hub-Transport-Server den Edge-Transport-Server nicht kontaktieren kann, übernimmt der Hub-Transport-Server erneut die Rolle des primären Servers und übermittelt die Nachricht erneut an die Shadow-Warteschlange.
Erneut übermittelte Nachrichten werden an einen anderen Edge-Transport-Server zugestellt und der Nachrichtenfluss beginnt erneut bei Phase 1.
Hinweis
Falls keine alternativen Routen für eine Shadow-Nachricht verfügbar sind (wie z. B. der zweite Edge-Transport-Server in der vorstehenden Abbildung), wird die Nachricht nicht erneut übermittelt, verbleibt jedoch in der Shadow-Warteschlange.
Weitere Informationen zum Nachrichtenfluss in verschiedenen Szenarien finden Sie unter Shadow-Redundanz – Nachrichtenübermittlungsszenarios.
Szenario mit mehreren Hops
Wenn eine Nachricht mehrere Server durchläuft, die Shadow-Redundanz unterstützen, wird die Shadow-Nachricht nur solange auf einem Server beibehalten, bis der nächste Server im Nachrichtenpfad die Zustellung bestätigt. Zur Veranschaulichung der Funktionsweise dieses Vorgangs können Sie sich eine Organisation vorstellen, die über fünf Active Directory-Standorte mit installierten Hub-Transport-Servern verfügt. Die Standorte sind wie in der folgenden Abbildung gezeigt miteinander verbunden. In der Organisation sind die Standorte New York und London als Hub-Standorte konfiguriert, daher müssen Nachrichten von den Standorten Chicago oder Atlanta die Hub-Transport-Server in den Standorten New York und London passieren, um an den Standort Dublin zugestellt zu werden.
Beispieltopologie für ein Szenario mit mehreren Hops
.gif "Komplexe Topologie (Beispiel)")
Angenommen, eine Nachricht wird von einem Benutzer am Standort Chicago an einen Benutzer am Standort Dublin gesendet. Diese Nachricht muss die Standorte New York und London passieren, um nach Dublin übermittelt zu werden. In diesem Fall geschieht Folgendes:
Der Hub-Transport-Server in Chicago sendet die Nachricht an den Hub-Transport-Server in New York und speichert eine Shadow-Kopie der Nachricht.
Der Hub-Transport-Server in New York sendet die Nachricht an den Hub-Transport-Server in London und speichert den Löschstatus für den Chicago-Hub.
Der Chicago-Hub fragt den Löschstatus beim New York-Hub ab und empfängt die Löschbenachrichtigung für die Nachricht. Zu diesem Zeitpunkt kann die Shadow-Nachricht aus der Datenbank entfernt werden. Ob die Nachricht von London nach Dublin zugestellt wurde, hat keinerlei Auswirkung darauf, ob der Server in Chicago die Shadow-Nachricht löscht.
Shadow-Redundanzschutz bei gemeinsamer Verwendung der Hub-Transport- und Postfachserverrolle mit DAGs (Database Availability Groups)
Bei Verwenden von Database Availability Groups (DAGs) werden die Nachrichten, für die bereits in den Postfachdatenbanken ein Commit ausgeführt wurde, durch die DAG-Architektur geschützt. Für alle Nachrichten, die an eine zu einer DAG gehörende Postfachdatenbank übermittelt werden, wird die Schattenkopie dieser Nachricht so lange im Transportdumpster aufbewahrt, bis diese Nachricht auf alle Mitglieder der DAG repliziert wurde. Gleichermaßen verfügen alle Nachrichten, die von einem DAG-Mitglied an Hub-Transport-Server übermittelt werden, über zwei Kopien, von denen sich eine in der Warteschlange des Hub-Transport-Servers befindet und auf die Übermittlung wartet und ihre Schattenkopie sich im Ordner Gesendete Elemente des Absenders befindet. Dieser Ansatz ist ein Hauptelement der Shadow-Redundanz.
Wenn sich die Hub-Transport- und Postfachserverrolle jedoch auf demselben Server verwendet werden und Sie über Postfachdatenbanken verfügen, die zu einer DAG gehören, müssen Hub-Transport-Server eine Nachricht ggf. durch einen zusätzlichen Hop leiten, um zu vermeiden, dass sich die Nachricht und ihre Schattenkopie auf derselben Serverhardware befinden. Die Hub-Transport-Serverrolle versucht insbesondere die folgenden beiden Situationen zu vermeiden, in denen der Ausfall eines einzelnen Servers zum Verlust von Nachrichten und ihrer Schattenkopien führen kann:
Während der Nachrichtenübermittlung befinden sich die aktive Postfachdatenbank des Nachrichtenempfängers und der Transportdumpster mit der Schattenkopie der Nachricht auf demselben Server Um dies zu vermeiden, leitet der Hub-Transport-Server die Nachricht durch einen anderen Hub-Transport-Server am Standort, um sicherzustellen, dass die Schattenkopie auf anderer Serverhardware gespeichert wird. Wenn jedoch keine anderen Hub-Transport-Server verfügbar sind, wird die Nachricht direkt übermittelt.
Während der Nachrichtenübermittlung befinden sich die Transportwarteschlange mit der eigentlichen Nachricht und die Schattenkopie im Ordner Gesendete Elemente des Absenders auf demselben Server Um dies zu vermeiden, wählt der Informationsspeichertreiber für die Nachrichtenübermittlung andere Hub-Transport-Server aus. Wenn jedoch am Standort keine anderen Hub-Transport-Server verfügbar sind, wird die Nachricht an den lokalen Hub-Transport-Server übermittelt.
Weitere Informationen zum gemeinesamen von Verwenden der Hub-Transport- und Postfachserverrolle mit Database Availability Groups finden Sie unter Koexistenz von Hub-Transport- und Postfachserverrollen bei Verwendung von Datenbankverfügbarkeitsgruppen.
Interoperabilität
Über die Verwendung oder Nichtverwendung von Shadow-Redundanz wird bei der Einrichtung einer neuen SMTP-Verbindung entschieden. Wenn beide an der SMTP-Verbindung beteiligten Server die Shadow-Redundanz unterstützen, wird der zuvor beschriebene Workflow verwendet. Es gibt jedoch Situationen, in denen Exchange 2010-Transportserver Nachrichten mit E-Mail-Servern austauschen, die keine Shadow-Redundanz unterstützen. Hierbei kann es sich um E-Mail-Server von Drittanbietern, ältere Versionen von Exchange oder um eine Exchange 2010-Organisation handelt, für die keine Shadow-Redundanz aktiviert wurde.
Wenn ein Exchange 2010 mit Unterstützung der Shadow-Redundanz eine Verbindung mit einem Server ohne Unterstützung der Shadow-Redundanz herstellt, geschieht Folgendes:
Exchange richtet eine SMTP-Verbindung mit dem Zielserver ein.
Der Zielserver bietet keine Unterstützung für Shadow-Redundanz.
Da der Zielserver keine Unterstützung für Shadow-Redundanz bietet, führt Exchange für jede Nachricht die folgenden Schritte aus:
Die Nachricht wird an den Zielserver zugestellt.
Der Shadow-Redundanz-Manager protokolliert, dass die Nachricht an den nächsten Hop zugestellt wurde.
Die Nachricht wird gelöscht, nachdem sie an alle nächsten Hops zugestellt wurde.
Wenn ein Server ohne Unterstützung der Shadow-Redundanz eine Verbindung mit einem Exchange 2010-Server herstellt, geschieht Folgendes:
Der sendende Server richtet eine SMTP-Verbindung mit Exchange ein.
Exchange kündigt die Unterstützung von Shadow-Redundanz an.
Der sendende Server bietet keine Unterstützung für Shadow-Redundanz und verwendet diese daher nicht. Nachrichten werden an den Exchange zugestellt.
Für jede Nachricht, die Exchange empfängt, werden folgende Schritte ausgeführt:
Die Nachricht wird an den nächsten Hop zugestellt, oder es wird eine Shadow-Kopie der Nachricht erstellt.
Es wird eine Bestätigung an den sendenden Server gesendet.
Verzögerte Bestätigung
Das grundlegende Prinzip der Shadow-Redundanz ist die Beibehaltung einer Nachrichtenkopie auf dem vorherigen Hop, bis der Server bestätigt, dass die Nachricht erfolgreich an alle nächsten Hops zugestellt wurde. Dies ist nicht möglich, wenn ein Exchange 2010-Transportserver eine Nachricht von einem E-Mail-Server erhält, der keine Unterstützung für Shadow-Redundanz bietet. Dieser E-Mail-Server kann entweder ein Exchange-Server mit einer älteren Version von Exchange, ein Standard-SMTP-Client oder ein Nicht-Exchange-E-Mail-Server im Internet sein. In diesem Fall versucht Exchange, Shadow-Redundanz zu erreichen, indem die Bestätigung an den E-Mail-Server verzögert wird, bis sichergestellt ist, dass die Nachricht erfolgreich intern an alle nächsten Hops zugestellt wurde. Auf diese Weise geht der sendende Server bei einem Ausfall des Exchange 2010-Servers davon aus, dass die Nachricht nicht an Exchange zugestellt wurde, und übermittelt die Nachricht erneut.
Die Nachrichtenzustellung an die nächsten Hops kann jedoch aufgrund der Komplexität Ihrer Routinginfrastruktur oder aufgrund eines Fehlers bei einem der nächsten Hops sehr viel Zeit in Anspruch nehmen. Um in diesem Fall ein Timeout der SMTP-Sitzung zu verhindern, sendet der Exchange 2010-Transportserver eine Bestätigung an den sendenden E-Mail-Server. Damit ist die E-Mail-Redundanz nicht garantiert, es wird jedoch dem Best-Effort-Prinzip Genüge geleistet. Beispielsweise kann eine Nachricht im folgenden Szenario verloren gehen: Ein Internet-E-Mail-Server übermittelt eine Nachricht an einen Edge-Transport-Server. Der Edge-Transport-Server kann aufgrund eines Netzwerkproblems nicht mit dem Hub-Transport-Server kommunizieren und bestätigt den Empfang der Nachricht gegenüber dem Internet-E-Mail-Server. Der Edge-Transport-Server fällt anschließend aus und kann nicht wiederhergestellt werden, bevor das Netzwerkproblem gelöst ist. Zu diesem Zeitpunkt geht die Nachricht verloren.
Der Timeoutwert für die verzögerte Bestätigung wird über das Attribut MaxAcknowledgementDelay jedes Empfangsconnectors gesteuert. Die Standardeinstellung ist 30 Sekunden. Weitere Informationen zum Konfigurieren dieses Attributs finden Sie unter Konfigurieren von Shadow-Redundanz.
Umgehen der verzögerten Bestätigung
Es gibt Situationen, in denen es unwahrscheinlich ist, dass eine Nachricht übermittelt wird, bevor das Timeout der verzögerten Bestätigung erreicht ist. In diesen Fällen verfährt der Transportserver mit Nachrichten mithilfe einer der folgenden Methoden:
Auslassen der verzögerten Bestätigung Der Transportserver lässt die verzögerte Bestätigung standardmäßig aus, um den SMTP-Empfangsdurchsatz beizubehalten. Dies bedeutet im Wesentlichen, dass der Transportserver eine Bestätigung ausstellt, bevor das Timeout erreicht wird.
Heraufstufung der Shadow-Redundanz In Microsoft Exchange Server 2010 Service Pack 1 (SP1) kann der Transportserver anstatt für das Auslassen der verzögerten Bestätigung so konfiguriert werden, dass die Nachricht an einen anderen Transportserver am Standort weitergeleitet wird. Dadurch wird die Nachricht in die Shadow-Redundanzpipeline eingefügt und somit geschützt. Dieser Vorgang wird als Heraufstufung der Shadow-Redundanz bezeichnet. Bei diesem Ansatz wird die Anzahl ungeschützter Nachrichten in der Organisation im Vergleich zum Auslassen der verzögerten Bestätigung minimiert. Das Feature ist standardmäßig deaktiviert. Zur Aktivierung der Heraufstufung der Shadow-Redundanz muss ein Administrator die Datei "Edgetransport.exe.config" bearbeiten und den Schlüssel shadowredundancypromotionenabled in true ändern. Nach dem Speichern der Änderungen an der Datei muss der Microsoft Exchange-Transportdienst (MSExchangeTransport.exe) neu gestartet werden. Weitere Informationen zur Vorgehensweise finden Sie im Abschnitt "Aktivieren der Heraufstufung der Shadow-Redundanz" im Thema "Konfigurieren von Shadow-Redundanz".
In der folgenden Tabelle werden verschiedene Szenarien aufgeführt, in denen ein Transportserver die verzögerte Bestätigung umgeht. Außerdem wird beschrieben, wie ein Exchange 2010-Server mit dem jeweiligen Szenario umgeht.
| Szenario | Exchange 2010-Standardverhalten (Auslassen der verzögerten Bestätigung) | Exchange 2010 SP1 mit aktivierter Heraufstufung der Shadow-Redundanz |
|---|---|---|
Die Zielwarteschlange der Nachricht hat entweder den Status "Angehalten" oder "Wiederholen". |
Der empfangende Transportserver lässt die verzögerte Bestätigung aus. |
Der empfangende Transportserver verwendet unmittelbar die Heraufstufung der Shadow-Redundanz. |
Die Zielwarteschlange wechselt in den Status "Wiederholen", nachdem ihr die Nachricht hinzugefügt wurde. |
Der empfangende Transportserver lässt die verzögerte Bestätigung bei nachfolgenden Nachrichten aus, bis die Zielwarteschlange wieder den Status "Bereit" hat. |
Der empfangende Transportserver verwendet die Heraufstufung der Shadow-Redundanz bei nachfolgenden Nachrichten, bis die Zielwarteschlange wieder den Status "Bereit" hat. |
Ein Administrator hält entweder die Zielwarteschlange oder die Nachricht an. |
Wenn der Administrator die Zielwarteschlange anhält, lässt der empfangende Transportserver die verzögerte Bestätigung aus, bis die Zielwarteschlange wieder den Status "Bereit" hat. Wenn der Administrator die Nachricht anhält, verarbeitet der empfangende Transportserver nachfolgende Nachrichten normal. |
Wenn der Administrator die Zielwarteschlange anhält, verwendet der empfangende Transportserver die Heraufstufung der Shadow-Redundanz, bis die Zielwarteschlange wieder den Status "Bereit" hat. Wenn der Administrator die Nachricht anhält, verarbeitet der empfangende Transportserver nachfolgende Nachrichten normal. |
Die Zielwarteschlange für die Nachricht enthält mehr als 100 Nachrichten. |
Der empfangende Transportserver lässt die verzögerte Bestätigung aus, bis die Zielwarteschlange weniger als 100 Nachrichten enthält. |
Wenn die Zielwarteschlange Nachrichten enthält, verwendet der empfangende Transportserver die Heraufstufung der Shadow-Redundanz bei nachfolgenden Nachrichten, bis die Warteschlange leer ist. |
Zurück zum Seitenanfang
Shadow-Redundanz-Manager
Der Shadow-Redundanz-Manager ist die Kernkomponente eines Exchange 2010-Transportservers, der für die Verwaltung der Shadow-Redundanz sorgt.
Der Shadow-Redundanz-Manager verwaltet die folgenden Informationen für alle primären Nachrichten, die ein Server aktuell verarbeitet:
Informationen zum Shadow-Server für jede primäre Nachricht, die verarbeitet wird
Löschstatus, der an die Shadow-Server gesendet wird
Der Shadow-Redundanz-Manager übernimmt für alle Shadow-Nachrichten, die ein Server in seiner Shadow-Warteschlange verwaltet, die folgenden Aufgaben:
Verwalten der Liste primärer Server für jede Shadow-Nachricht
Überprüfen der Verfügbarkeit aller primären Server, für die sich eine Shadow-Nachricht in der Warteschlange befindet
Verarbeiten von Löschbenachrichtigungen von primären Servern
Entfernen der Shadow-Nachrichten aus der Datenbank, nachdem alle erwarteten Löschbenachrichtigungen empfangen wurden
Entscheidung darüber, ob der Shadow-Server den Besitz von Shadow-Nachrichten übernimmt und zu einem primären Server wird
Darüber hinaus ist der Shadow-Redundanz-Manager für das Verwalten von Leistungsindikatoren in Zusammenhang mit der Shadow-Redundanz verantwortlich.
Taktsignal
Der Shadow-Redundanz-Manager verwendet ein Taktsignal, um die Verfügbarkeit der Server zu ermitteln, für die Shadow-Nachrichten in die Warteschlange eingereiht wurden. Während der SMTP-Sitzung zwischen zwei Servern, die beide Shadow-Redundanz unterstützen, fragt der Server, der die Verbindung initiiert hat, den Löschstatus von zuvor an den Server übermittelten Nachrichten beim Zielserver ab. Der initiierende Server erreicht dies, indem ein XQUERYDISCARD-Befehl gesendet wird. Der Zielserver gibt als Antwort die Löschbenachrichtigung zurück. Dieser Austausch zwischen den zwei Servern wird als Taktsignal für die Shadow-Redundanz verwendet.
Es gibt einen Timeoutwert für das Taktsignal. Wenn innerhalb dieses Zeitraums keine Verbindungen mit einem Server hergestellt werden, für die der Shadow-Redundanz-Manager eine Shadow-Warteschlange verwaltet, versucht der Server, eine SMTP-Verbindung mit dem primären Server herzustellen, um den Löschstatus abzufragen und den Zeitgeber zurückzusetzen. Der Timeoutwert wird über den Parameter ShadowHeartbeatTimeoutInterval des Cmdlets Set-TransportConfig gesteuert. Dieser Parameter hat folgenden Standardwert: 300 Sekunden in der RTM-Version (Release to Manufacture) von Exchange 2010 und 900 Sekunden in Exchange 2010 SP1.
Wenn der Server bei Erreichen des Timeoutwerts keine Verbindung mit dem primären Server herstellen kann, wird der Zeitgeber zurückgesetzt und erneut versucht, eine Verbindung herzustellen. Wenn der Timeoutwert zwölf Mal nacheinander erreicht wird (drei Mal nacheinander in Exchange 2010), geht der Server davon aus, dass der primäre Server ausgefallen ist, und übernimmt der Server den Besitz der Shadow-Nachrichten. Anschließend beginnt der Server, Löschbenachrichtigungen für die Nachrichten zu generieren, die an den ausgefallenen primären Server gesendet werden. Die Anzahl der Timeouts, die ein Server abwartet, bevor er den primären Server als ausgefallen einstuft, wird über den Parameter ShadowHeartbeatRetryCount des Cmdlets Set-TransportConfig gesteuert.
Weitere Informationen zum Konfigurieren des Taktsignals für die Shadow-Redundanz finden Sie unter Konfigurieren von Shadow-Redundanz.
Zurück zum Seitenanfang
Nachrichtenverarbeitung nach einem Ausfall
Die Shadow-Redundanz minimiert den Nachrichtenverlust aufgrund von Serverausfällen. Wenn ein Transportserver nach einem Ausfall wieder online geschaltet wird, gibt es zwei Szenarien:
Der Server wird mit einer neuen Transportdatenbank online geschaltet In diesem Szenario kann die Transportdatenbank aufgrund von Datenbeschädigung oder eines Hardwarefehlers nicht wiederhergestellt werden. Da der Transportserver in diesem Fall über eine neue Datenbank-ID verfügt, wird er von den anderen Transportservern in der Organisation als neue Route erkannt. Dies gilt auch für Situationen, in denen ein Server nicht wiederhergestellt werden kann und als Ersatz ein neuer Server bereitgestellt wird.
Der Server wird mit derselben Transportdatenbank online geschaltet In diesem Szenario ist der betreffende Transportserver nicht ausgefallen, sondern war für eine längere Zeitspanne offline. Dieses Szenario kann beispielsweise durch einen Netzwerkkartenfehler oder eine längere Wartung des Servers verursacht werden.
In der folgenden Tabelle wird zusammengefasst, wie der Transport bei aktivierter Shadow-Redundanz in beiden Szenarien abläuft. Es wird hierbei angenommen, dass es sich bei dem ausgefallenen Server um Server Hub01 handelt.
Nachrichtenverarbeitung in Wiederherstellungsszenarien
| Szenario für die Wiederherstellung | Aktionen für Nachrichten, für die alternative Routen vorhanden sind | Aktionen für Nachrichten ohne alternative Routen |
|---|---|---|
Hub01 wird mit einer neuen Datenbank wieder online geschaltet. |
Wenn Hub01 nicht mehr verfügbar ist, übernimmt jeder Server, der Shadow-Nachrichten für Hub01 in die Warteschlange eingereiht hat, den Besitz für diese Nachrichten und übermittelt die Nachrichten erneut. Die Nachrichten werden über alternative Routen an ihr Ziel zugestellt. Die Gesamtverzögerung für Nachrichten entspricht dem Produkt des Timeoutintervalls für das Taktsignal und der Anzahl der Wiederholungen, die in Ihrer Organisation für das Taktsignal konfiguriert wurde. |
Diese Nachrichten verbleiben in der Shadow-Warteschlange auf jedem Server, der Shadow-Nachrichten für Hub01 in die Warteschlange eingereiht hat. Wenn Hub01 mit einer neuen Datenbank-ID wieder online geschaltet wird, erkennen die Shadow-Server die neue Datenbank und übermitteln alle Nachrichten erneut, die sich in der Shadow-Warteschlange für Hub01 befinden. Dies entspricht der Ermittlung einer alternativen Route für diese Nachrichten. Die Gesamtverzögerung für die Nachrichten richtet sich nach der Dauer des Ausfalls. |
Hub01 wird mit derselben Datenbank wieder online geschaltet. |
Hub01 stellt die Nachrichten in seinen Warteschlangen zu. Dies führt zur doppelten Zustellung dieser Nachrichten. Exchange-Postfachbenutzer erhalten aufgrund der Erkennung von Nachrichtenduplikaten keine doppelten Nachrichten. Empfänger in fremden Systemen erhalten jedoch möglicherweise doppelte Nachrichten. Die Gesamtverzögerung für Nachrichten entspricht dem Produkt des Timeoutintervalls für das Taktsignal und der Anzahl der Wiederholungen, die in Ihrer Organisation für das Taktsignal konfiguriert wurde. |
Hub01 stellt die Nachrichten in seinen Warteschlangen zu und sendet Löschbenachrichtigungen an die Shadow-Server. Die Gesamtverzögerung für die Nachrichten richtet sich nach der Dauer des Ausfalls. |
Zurück zum Seitenanfang
Erforderlichkeit erweiterter Rechte für die Shadow-Redundanz
In Exchange 2010 werden die folgenden zwei erweiterten Rechte eingeführt, die für die Shadow-Redundanz erforderlich sind:
ms-Exch-SMTP-Accept-XSHADOW
ms-Exch-SMTP-Send-XSHADOW
Wenn eine SMTP-Verbindung mit einem Exchange 2010-Transportserver eingerichtet wird, kündigt der Server die Unterstützung von Shadow-Redundanz an, wenn auf dem verwendeten Empfangsconnector das erweiterte Recht ms-Exch-SMTP-Accept-XSHADOW vorhanden ist. Zusätzlich sollte der Authentifizierungsmechanismus auf dem Empfangsconnector entweder Exchange Server-Authentifizierung oder Extern gesichert lauten.
Wenn ein Exchange 2010-Transportserver eine SMTP-Verbindung mit einem anderen Server herstellt, der die Shadow-Redundanz unterstützt, gibt er nur dann einen XSHADOW-Befehl aus, wenn der Sitzung das erweiterte Recht ms-Exch-SMTP-Send-XSHADOW gewährt wurde.
Standardmäßig werden diese erweiterten Rechte der Gruppe Exchange-Server auf allen internen Sende- und Empfangsconnectors gewährt.
Hinweis
Die Shadow-Redundanz kann über den Parameter ShadowRedundancyEnabled des Cmdlets Set-TransportConfig für die gesamte Organisation aktiviert oder deaktiviert werden. Diese Einstellung setzt die in diesem Abschnitt beschriebenen erweiterten Rechte außer Kraft. Wenn die Shadow-Redundanz für die Organisation deaktiviert wurde, kündigt Exchange keine Unterstützung für die Shadow-Redundanz an und gibt keine XSHADOW-Befehle aus – selbst dann nicht, wenn der SMTP-Sitzung die erforderlichen erweiterten Rechte gewährt wurden.
Zurück zum Seitenanfang
© 2010 Microsoft Corporation. Alle Rechte vorbehalten.