Schattenredundanz in Exchange Server

Die Funktion Shadow-Redundanz wurde in Exchange 2010 eingeführt, um redundante Kopien von Nachrichten bereitzustellen, bevor diese an Postfächer zugestellt werden. In Exchange 2010 führte die Shadow-Redundanz dazu, dass Nachrichten erst aus der Warteschlangendatenbank eines Hub-Transport-Servers gelöscht werden konnten, nachdem der Server festgestellt hatte, dass der nächste Hop auf dem Nachrichtenübermittlungspfad die Zustellung abgeschlossen hat. Kam es auf dem nächsten Hop zu einem Fehler, bevor er eine erfolgreiche Zustellung an den Hub-Transport-Server melden konnte, übermittelte der Server die Nachricht erneut an diesen Hop. Hub-Transport-Server unter Exchange 2010 verwendeten das Verb XSHADOW, um bekannt zu machen, dass sie Shadow-Redundanz unterstützen. Unterstützte ein Quellmessagingserver Shadow-Redundanz nicht, verzögerte Exchange 2010 die Bestätigung um ein auf dem Empfangsconnector konfiguriertes Zeitintervall, um eine redundante Kopie der Nachricht zu erstellen.

Exchange 2016 und Exchange 2019 verfügen über die gleichen Verbesserungen wie bei der Schattenredundanz in Exchange 2013: Der Transportdienst auf einem Postfachserver erstellt jetzt eine redundante Kopie aller Nachrichten, die er empfängt, bevor der Empfang der Nachricht an den sendenden Server bestätigt wird. Das Verwalten redundanter Kopien von Nachrichten während der Übertragung ist mehr als ein bestmöglicher Aufwand, der möglicherweise funktioniert oder nicht, da schattenredundanz jetzt nicht von den unterstützten Features des sendenden Servers abhängt (Unterstützung oder fehlende Unterstützung für Schattenredundanz spielt keine Rolle). Dadurch wird sichergestellt, dass alle Nachrichten in der Transportpipeline während der Übertragung redundant werden. Wenn Exchange feststellt, dass die ursprüngliche Nachricht während der Übertragung verloren gegangen ist, wird die redundante Kopie der Nachricht erneut zugestellt.

Weitere Informationen zu Hochverfügbarkeitsfeatures für den Transport in Exchange Server finden Sie unter Transport von Hochverfügbarkeit in Exchange Server. Weitere Informationen zur Nachrichtenredundanz nach erfolgreicher Zustellung einer Nachricht finden Sie unter Safety Net in Exchange Server.

Komponenten der Funktion Shadow-Redundanz

In dieser Tabelle sind die Komponenten der Shadow-Redundanz-Funktion im Transportdienst auf Postfachservern aufgeführt. Alle diese Begriffe werden im weiteren Verlauf des Artikels verwendet.

Anforderungen für die Funktion Shadow-Redundanz

Obwohl es offensichtlich erscheinen mag, erfordert Schattenredundanz mehrere Postfachserver:

• Wenn der Postfachserver kein Mitglied einer DAG ist, müssen sich die anderen Postfachserver am lokalen Active Directory-Standort befinden.

• Wenn der Postfachserver Mitglied einer DAG ist, müssen die anderen Postfachserver zu derselben DAG gehören. Die übrigen Mitglieder der DAG dürfen sich am lokalen Active Directory-Standort oder an einem Remotestandort befinden. Wenn sich die DAG über mehrere Active Directory-Standorte erstreckt, erstellt die Funktion Shadow-Redundanz die redundante Kopie der Nachricht aus Gründen der Standortausfallsicherheit standardmäßig bevorzugt an einem Remotestandort.

In folgenden Situationen bietet Shadow-Redundanz keinen Schutz für Nachrichten während der Übermittlung:

• In Umgebungen mit lediglich einem einzigen Exchange-Server

• In DAGs mit unzureichenden Ressourcen

• Beim gleichzeitigen Ausfall von zwei oder mehr Postfachservern, die Shadow-Redundanz für eine Nachricht bereitstellen

Shadow-Redundanz standardmäßig aktiviert

Die Funktion Shadow-Redundanz ist standardmäßig global im Transportdienst jedes Postfachservers aktiviert. In der folgenden Tabelle sind die Parameter beschrieben, über die die Funktion Shadow-Redundanz aktiviert wird.

Erstellen von Shadow-Nachrichten

Der Hauptzweck von Shadow-Redundanz besteht darin, während der Übermittlung einer Nachricht zu jedem Zeitpunkt zwei Kopien der Nachricht innerhalb der Grenze für Transporthochverfügbarkeit vorzuhalten. Wo und wann die redundante Kopie der Nachricht erstellt wird, hängt vom Absender und vom Empfänger der Nachricht ab. Es gibt drei Nachrichtentypen, die jeweils bedingen, wie Shadow-Nachrichten erstellt werden:

• Nachrichten, die von Absendern außerhalb einer Grenze für Transporthochverfügbarkeit (DAG oder Active Directory-Standort [in Umgebungen ohne DAGs]) gesendet werden

• Nachrichten, die an Empfänger außerhalb einer Transportgrenze für Hochverfügbarkeit gesendet werden.

• Nachrichten, die vom Dienst für die Postfachtransportübermittlung von einem Postfachserver innerhalb der Transportgrenze für Hochverfügbarkeit empfangen werden.

Die Funktion Shadow-Redundanz verfolgt niemals Shadow-Nachrichten, die die Grenze für Transporthochverfügbarkeit verlassen. Sobald eine Nachricht die Grenze für Transporthochverfügbarkeit überschreitet, wird die Funktion Shadow-Redundanz angestoßen oder erneut gestartet. Dadurch wird einerseits der zum Vorhalten von Shadow-Nachrichten erforderliche Datenverkehr reduziert und andererseits eine erneute Übermittlung von Shadow-Nachrichten über die Grenze für Transporthochverfügbarkeit hinweg verhindert. Exchange 2010-basierte Hub-Transport-Server stellen einen Sonderfall dar und werden später in diesem Artikel behandelt.

Nachrichten, die von Absendern außerhalb einer Grenze für Transporthochverfügbarkeit gesendet werden

Wenn der Transportdienst auf einem Postfachserver eine Nachricht von einem Absender außerhalb der Grenze für Transporthochverfügbarkeit empfängt, spielt es für den Postfachserver keine Rolle, ob der sendende Server Shadow-Redundanz unterstützt oder nicht. Solange die Funktion Shadow-Redundanz aktiviert ist, erstellt der Postfachserver, der die Nachricht empfängt, eine redundante Kopie der Nachricht auf einem anderen Postfachserver innerhalb der Grenze für Transporthochverfügbarkeit und bestätigt dann dem sendenden Server den Empfang der Nachricht. Hier ein Beispiel für den Prozess:

1. Ein Messagingserver übermittelt eine Nachricht an den Transportdienst auf einem Postfachserver. Der Postfachserver ist der primäre Server, die Nachricht ist die primäre Nachricht.

2. Noch während die ursprüngliche SMTP-Sitzung mit dem Messagingserver aktiv ist, öffnet der Transportdienst auf dem primären Server simultan eine neue SMTP-Sitzung mit dem Transportdienst auf einem anderen Postfachserver in der Organisation, um eine redundante Kopie der Nachricht zu erstellen.

   • Wenn der primäre Server Mitglied einer DAG ist, stellt der primäre Server eine Verbindung mit einem anderen Postfachserver in derselben DAG her. Wenn die DAG mehrere Active Directory-Standorte umfasst, wird standardmäßig ein Postfachserver an einem anderen Active Directory-Standort bevorzugt (der Standardwert des ShadowMessagePreferenceSetting-Parameters im Cmdlet Set-TransportConfig lautet PreferRemote, sie können jedoch in RemoteOnly oder LocalOnlygeändert werden.

   • Wenn der primäre Server kein Mitglied einer DAG ist, stellt der primäre Server eine Verbindung mit einem anderen Postfachserver am gleichen Active Directory-Standort her (unabhängig vom Wert des ShadowMessagePreferenceSetting-Parameters ).

3. Der primäre Server überträgt eine Kopie der Nachricht an den Transportdienst auf einem anderen Postfachserver, und der Transportdienst auf dem anderen Postfachserver bestätigt, dass die Kopie der Nachricht erfolgreich erstellt wurde. Die Kopie der Nachricht ist die Schattennachricht, und der Postfachserver, der sie enthält, ist der Schattenserver für den primären Server. Die Nachricht befindet sich in einer Schattenwarteschlange auf dem Schattenserver.

4. Sobald der primäre Server die Bestätigung vom Shadow-Server erhalten hat, bestätigt er dem ursprünglichen Messagingserver in der ursprünglichen SMTP-Sitzung den Erhalt der primären Nachricht, und die SMTP-Sitzung wird geschlossen.

Nachrichten, die an Empfänger außerhalb einer Grenze für Transporthochverfügbarkeit gesendet werden

Wenn ein Postfachserver eine Nachricht an einen Empfänger außerhalb der Grenze für Transporthochverfügbarkeit übermittelt und der Messagingserver auf der Gegenseite den Erhalt der Nachricht bestätigt, verschiebt der Postfachserver die Nachricht in das Sicherheitsnetz. Die Nachricht kann aus dem Sicherheitsnetz nicht erneut übermittelt werden, nachdem die primäre Nachricht erfolgreich über die Grenze für Transporthochverfügbarkeit hinweg übermittelt wurde. Weitere Informationen zu Safety Net finden Sie unter Safety Net in Exchange Server.

Nachrichten, die innerhalb einer Grenze für Transporthochverfügbarkeit übermittelt werden

Das Nachrichtenrouting ist so optimiert, dass mehrere Hops zwischen Servern innerhalb der Ziel-DAG oder des Zielstandorts in der Regel nicht erforderlich sind, wenn sich das endgültige Ziel in einer DAG oder einem Active Directory-Standort befindet. Nachdem die Nachricht vom Transportdienst auf einem Postfachserver in der Ziel-DAG oder Active Directory akzeptiert wurde, ist der nächste Hop für die Nachricht in der Regel das endgültige Ziel selbst (z. B. der Postfachserver, der die aktive Kopie des Zielpostfachs enthält). Das Ziel der Schattenredundanz, zwei Kopien einer Nachricht während der Übertragung beizubehalten, wird erfüllt, wenn eine Schattenkopie der Nachricht an einer beliebigen Stelle innerhalb der DAG oder des Active Directory-Standorts vorhanden ist. In der Regel erfordern nur Failoverszenarien in einer DAG, bei denen das Cmdlet Redirect-Message die aktiven Nachrichtenwarteschlangen auf einem Postfachserver leeren muss, mehrere Hops innerhalb derselben Transportgrenze für Hochverfügbarkeit.

Schattenredundanz mit Exchange 2010 Hub-Transport-Servern am gleichen Active Directory-Standort in Exchange 2016-Organisationen

Wenn ein Exchange 2010-Hub-Transport-Server eine Nachricht an einen Exchange 2016-Postfachserver am gleichen Active Directory-Standort überträgt, kündigt der Exchange 2010-Hub-Transport-Server über den XSHADOW-Befehl Unterstützung für die Shadow-Redundanz an, der Postfachserver kündigt jedoch keine Unterstützung für die Shadow-Redundanz an. Dies verhindert, dass der Exchange 2010-Hub-Transport-Server eine Shadow-Kopie der Nachricht auf einem Exchange 2016-Postfachserver erstellt.

Wenn der Transportdienst auf einem Exchange 2016-Postfachserver eine Nachricht an einen Exchange 2010-basierten Hub-Transport-Server am selben Active Directory-Standort übermittelt, erstellt der Exchange 2016-Postfachserver eine Shadow-Kopie der Nachricht für den Exchange 2010-basierten Hub-Transport-Server. Nachdem der Exchange 2016-Postfachserver die Bestätigung über den Empfang der Nachricht vom Exchange 2010-basierten Hub-Transport-Server erhalten hat, verschiebt der Exchange 2016-Postfachserver die erfolgreich verarbeitete Nachricht in das Sicherheitsnetz. Die erfolgreich verarbeiteten Nachrichten, die vom Exchange 2016-Postfachserver im Sicherheitsnetz gespeichert werden, werden jedoch niemals erneut an den Exchange 2010-basierten Hub-Transport-Server übertragen.

SMTP-Timeouts

Während des Versuchs, eine redundante Kopie einer Nachricht zu erstellen, könnte es bei der SMTP-Verbindung zwischen dem sendenden Server und dem primären Server oder zwischen dem primären Server und dem Shadow-Server zu einem Timeout kommen. Empfangsconnectors und Sendeconnectors verfügen beide über einen ConnectionInactivityTimeOut-Parameter für den Zeitpunkt, an dem Daten tatsächlich auf dem Connector übertragen werden. Empfangsconnectors verfügen auch über einen absoluten ConnectionTimeOut-Parameter .

Wenn bei einer der SMTP-Sitzungen ein Timeout vor der erfolgreichen Erstellung und Bestätigung der Schattenkopie der Nachricht erfolgt, wird das Ergebnis durch den RejectMessageOnShadowFailure-Parameter des Cmdlets Set-TransportConfig gesteuert. Standardmäßig ist $falseder Wert dieses Parameters , was bedeutet, dass die primäre Nachricht akzeptiert wird, ohne dass eine Schattenkopie erstellt wird. Wenn der Wert dieses Parameters die primäre Nachricht ist $true , wird mit dem vorübergehenden Fehler 451 4.4.0abgelehnt.

Wenn die Shadow-Kopie einer Nachricht erfolgreich erstellt wurde, aber ein Timeout in der SMTP-Sitzung zwischen dem sendenden Server und dem primären Server auftritt, nimmt der primäre Server die primäre Nachricht an und verarbeitet sie. Der sendende Server übermittelt die unbestätigte Nachricht erneut, die Funktion zur Erkennung von Nachrichtenduplikaten verhindert jedoch, dass den Benutzern von Exchange-Postfächern die Nachricht doppelt angezeigt wird. Wenn der sendende Server die Nachricht erneut übermittelt, erstellt der primäre Server eine weitere Shadow-Kopie der Nachricht. Es besteht keine Beziehung zwischen den Shadow-Nachrichten, die erstellt werden, wenn der sendende Server Nachrichten erneut übermittelt.

In der folgenden Tabelle werden die Parameter beschrieben, die die Erstellung von Shadow-Nachrichten steuern.

Verwalten von Shadow-Nachrichten

Nachdem eine Shadow-Nachricht erstellt wurde, müssen verschiedene weitere Aufgaben ausgeführt werden. Der primäre Server und der Shadow-Server müssen in Kontakt bleiben, um den Fortschritt der Nachricht nachzuverfolgen.

Wenn der primäre Server die Nachricht erfolgreich an den nächsten Hop überträgt und der nächste Hop den Empfang der Nachricht bestätigt, aktualisiert der primäre Server den Verwerfensstatus der Nachricht nach Abschluss der Zustellung. Der Verwerfensstatus ist im Grunde eine Nachricht, die eine Liste der überwachten Nachrichten enthält. Eine erfolgreich zugestellte Nachricht muss nicht in einer Schattenwarteschlange aufbewahrt werden. Sobald der Schattenserver also weiß, dass der primäre Server die Nachricht erfolgreich an den nächsten Hop übertragen hat, verschiebt der Schattenserver die Schattennachricht aus der Schattenwarteschlange in Safety Net.

Der Schattenserver bestimmt den Verwerfensstatus der Schattenmeldungen in seinen Schattenwarteschlangen, indem er den primären Server abfragt. Wenn der Schattenserver aus irgendeinem Grund eine SMTP-Sitzung mit dem primären Server öffnet (einschließlich der Übertragung anderer nicht verwandter Nachrichten), gibt der Schattenserver den Befehl XQDISCARD aus, um den Verwerfensstatus der primären Nachrichten zu bestimmen. Andernfalls öffnet der Schattenserver automatisch eine SMTP-Sitzung mit dem primären Server nach einem vorkonfigurierten Zeitintervall (der Parameter ShadowHeartbeatFrequency im Cmdlet Set-TransportConfig ; der Standardwert ist 2 Minuten).

Nachdem der Schattenserver eine SMTP-Sitzung mit dem primären Server geöffnet hat, antwortet der primäre Server mit den Verwerfbenachrichtigungen für Nachrichten, die für den abfragenden Schattenserver gelten. Verwerfen-Benachrichtigungen werden auf dem Datenträger (nicht im Arbeitsspeicher) gespeichert. Wenn der Microsoft Exchange-Transportdienst also neu gestartet wird, bleiben die Verwerfbenachrichtigungen erhalten. Nachdem der Dienst gestartet wurde, weiß der primäre Server immer noch über die Meldungen, die er erfolgreich verarbeitet hat, und diese Informationen sind für den Schattenserver verfügbar.

Die SMTP-Kommunikation zwischen dem Shadow-Server und dem primären Server wird als Heartbeat herangezogen, der die Verfügbarkeit der Server bestimmt. Wenn der Shadow-Server nach einem vorkonfigurierten Zeitintervall (festgelegt im Parameter ShadowResubmitTimeSpan im Cmdlet Set-TransportConfig; Standardwert = 3 Stunden) keine SMTP-Sitzung mit dem primären Server öffnen kann, stuft sich der Shadow-Server selbst zum primären Server herauf, stuft die Shadow-Nachrichten zu primären Nachrichten herauf und übermittelt die Nachrichten an den nächsten Hop. Auch wenn der Shadow-Server erkennt, dass sich die ID der Warteschlangendatenbank auf dem primären Server geändert hat, stuft er sich selbst zum primären Server herauf, stuft die Shadow-Nachrichten zu primären Nachrichten herauf und übermittelt die Nachrichten an den nächsten Hop. Das kann deutlich vor dem Ablauf des im Parameter ShadowResubmitTimeSpan festgelegten Zeitintervalls eintreten.

Der Shadow-Redundanz-Manager ist die wichtigste Komponente auf einem Postfachserver, der Shadow-Redundanz bereitstellt. Der Shadow-Redundanz-Manager speichert die folgenden Informationen zu allen primären Nachrichten, die ein Server aktuell verarbeitet:

• Shadow-Server jeder primären Nachricht, die aktuell verarbeitet wird

• Löschstatus, der an die Shadow-Server gesendet wird

Der Shadow-Redundanz-Manager übernimmt für alle Shadow-Nachrichten, die ein Shadow-Server in seiner Shadow-Warteschlange vorhält, die folgenden Aufgaben:

• Verwalten der Liste primärer Server für jede Shadow-Nachricht.

• Vergleichen der ursprünglichen Datenbank-ID mit der aktuellen Datenbank-ID für die Warteschlangendatenbank, in der primäre Kopie der Nachricht gespeichert ist.

• Ü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 den Shadow-Warteschlangen, 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.

• Nachverfolgen von Nachrichtengabelungen und sonstigen Nachrichten wie beispielsweise Benachrichtigungen über den Zustellungsstatus (auch DSNs [Delivery Status Notifications], Unzustellbarkeitsberichte, NDRs [Non-Delivery Reports] oder Unzustellbarkeitsnachrichten genannt) oder Journalberichten, um sicherzustellen, dass die redundante Nachrichtenkopie erst freigegeben wird, wenn alle Kopien der Nachricht vollständig verarbeitet wurden

In der folgenden Tabelle werden die Parameter beschrieben, die steuern, wie Shadow-Nachrichten vorgehalten werden.

Nachrichtenverarbeitung nach einem Ausfall

In dieser Tabelle wird beschrieben, wie mittels Shadow-Redundanz der Nachrichtenverlust während Serverausfällen auf ein Minimum reduziert wird. Zum einfacheren Verständnis nennen wir den ausgefallenen Server „Mailbox01“.