Shadow-Redundanz

Gilt für: Exchange Server 2013

Die Schattenredundanz wurde in Microsoft Exchange Server 2010 eingeführt, um redundante Kopien von Nachrichten bereitzustellen, bevor sie an Postfächer übermittelt werden. In Exchange 2010 verzögerte die Schattenredundanz das Löschen einer Nachricht aus der Transportdatenbank auf einem Transportserver, bis der Server überprüfte, ob der nächste Hop im Nachrichtenübermittlungspfad die Zustellung abgeschlossen hat. Wenn der nächste Hop fehlschlug, bevor eine erfolgreiche Zustellung an den Transportserver gemeldet wurde, übermittelte der Transportserver die Nachricht erneut an den nächsten Hop. Exchange 2010-Server verwendeten das XSHADOW-Verb, um ihre Unterstützung für Schattenredundanz anzukündigen. Wenn ein SMTP-Server keine Schattenredundanz unterstützte, verwendete Exchange 2010 eine verzögerte Bestätigung basierend auf einem konfigurierten Zeitintervall für den Empfangsconnector, um eine redundante Kopie der Nachricht zu erstellen.

Die wesentliche Verbesserung der Schattenredundanz in Microsoft Exchange Server 2013 besteht darin, dass der Transportserver jetzt eine redundante Kopie aller empfangenen Nachrichten erstellt, bevor er bestätigt, dass die Nachricht erfolgreich an den sendenden Server zurückgesendet wurde. Die Unterstützung oder Nichtunterstützung des sendenden Servers für Schattenredundanz spielt keine Rolle. Dadurch wird sichergestellt, dass alle Nachrichten in der Exchange 2013-Transportpipeline während der Übertragung redundant werden. Wenn Exchange 2013 feststellt, dass die ursprüngliche Nachricht während der Übertragung verloren gegangen ist, wird die redundante Kopie der Nachricht erneut zugestellt.

Komponenten der Funktion Shadow-Redundanz

In der folgenden Tabelle werden die Komponenten der Schattenredundanz beschrieben. 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 Exchange 2013-Postfachserver. Bei den Postfachservern kann es sich um eigenständige Server oder um Postfachserver und Clientzugriffsserver handeln, die auf demselben Computer installiert sind.

• 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 anderen Postfachserver, die zur DAG gehören, können sich am lokalen Active Directory-Standort oder an einem Active Directory-Remotestandort befinden. Wenn sich die DAG über mehrere Active Directory-Standorte erstreckt, wird bei der Schattenredundanz aus Gründen der Standortresilienz bevorzugt eine redundante Kopie der Nachricht an einem Active Directory-Remotestandort erstellt.

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
• Während des gleichzeitigen Ausfalls von zwei oder mehr Transportservern, die an der Schattenredundanz einer Nachricht beteiligt sind.

Shadow-Redundanz standardmäßig aktiviert

Standardmäßig wird die Schattenredundanz global im Transportdienst auf allen Postfachservern aktiviert, indem der Parameter ShadowRedundancyEnabled im Cmdlet Set-TransportConfig verwendet wird. Wenn der Transportdienst auf einem Postfachserver keine redundante Kopie einer Nachricht erstellen kann, wird die Nachricht standardmäßig nicht abgelehnt. Sie können Exchange 2013 jedoch so konfigurieren, dass eine Nachricht abgelehnt wird, wenn keine redundante Kopie der Nachricht mithilfe des Parameters RejectMessageOnShadowFailure im Cmdlet Set-TransportConfig erstellt wird. Die Nachricht wird mit einem vorübergehenden Fehler zurückgewiesen, aber der sendende Server kann die Nachricht erneut übertragen. Der SMTP-Antwortcode lautet451 4.4.0 Message failed to be made redundant.: Sie sollten Exchange 2013 so konfigurieren, dass Nachrichten, die nicht redundant gemacht werden können, nur abgelehnt werden, wenn in Ihrer organization mehrere Exchange 2013-Postfachserver verfügbar sind.

In der folgenden Tabelle werden die Parameter beschrieben, die Schattenredundanz aktivieren.

Parameter, die Schattenredundanz aktivieren

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 davon ab, woher die Nachricht stammt und wohin die Nachricht gesendet wird. Es gibt drei wesentliche bestimmende Faktoren:

• Nachrichten, die von außerhalb einer Transport-Hochverfügbarkeitsgrenze empfangen wurden.
• 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.

Eine Transport-Hochverfügbarkeitsgrenze ist eine der folgenden:

• Eine DAG für Postfachserver, die Mitglieder einer DAG sind. Dies schließt eine DAG ein, die sich über mehrere Active Directory-Standorte erstreckt.
• Ein Active Directory-Standort für Postfachserver, die nicht zu einer DAG gehören.

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. Dies reduziert den Wartungsdatenverkehr für Schattennachrichten und verhindert, dass die Wiedervorlage von Schattennachrichten über die Transport-Hochverfügbarkeitsgrenze hinweg erfolgt. 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 Exchange 2013-Postfachserver eine Nachricht von außerhalb der Transport-Hochverfügbarkeitsgrenze empfängt, kümmert sich der Postfachserver nicht um die Unterstützung oder mangelnde Unterstützung der Schattenredundanz durch den sendenden Server. 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 SMTP-Server überträgt eine Nachricht an den Transportdienst auf einem Postfachserver. Der Postfachserver ist der primäre Server, die Nachricht ist die primäre Nachricht.

2. Während die ursprüngliche SMTP-Sitzung mit dem SMTP-Server noch aktiv ist, öffnet der Transportdienst auf dem primären Server eine neue, gleichzeitige SMTP-Sitzung mit dem Transportdienst auf einem anderen Postfachserver in der organization, 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 sich die DAG über mehrere Active Directory-Standorte erstreckt, wird standardmäßig ein Postfachserver an einem anderen Active Directory-Standort bevorzugt. Diese Einstellung wird durch den Parameter ShadowMessagePreference im Cmdlet Set-TransportService gesteuert. Der Standardwert lautet PreferRemote, Sie können ihn jedoch in RemoteOnly oder ändern LocalOnly.
   • Wenn der primäre Server kein Mitglied einer DAG ist, stellt der primäre Server unabhängig vom Wert des Parameters ShadowMessagePreference eine Verbindung mit einem anderen Postfachserver am selben Active Directory-Standort her.

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. Bei der Kopie der Nachricht handelt es sich um die Schattennachricht, und der Postfachserver, auf dem sie gespeichert ist, ist der Schattenserver für den primären Server. Die Nachricht befindet sich in einer Schattenwarteschlange auf dem Schattenserver.

4. Nachdem der primäre Server eine Bestätigung vom Schattenserver erhalten hat, bestätigt der primäre Server den Empfang der primären Nachricht an den ursprünglichen SMTP-Server in der ursprünglichen SMTP-Sitzung, und die SMTP-Sitzung wird geschlossen.

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

Wenn ein Exchange 2013-Transportserver eine Nachricht außerhalb der Transport-Hochverfügbarkeitsgrenze überträgt und der SMTP-Server auf der anderen Seite den erfolgreichen Empfang der Nachricht bestätigt, verschiebt der Transportserver 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 zum Sicherheitsnetz finden Sie unter Sicherheitsnetz.

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

Das Nachrichtenrouting wurde in Exchange 2013 optimiert, sodass mehrere Hops zwischen dem Transportdienst auf Postfachservern in dieser DAG oder diesem Active Directory-Standort in der Regel nicht erforderlich sind, wenn sich das endgültige Ziel an einem DAG- oder Active Directory-Standort befindet. Sobald die Nachricht vom Transportdienst auf einem Postfachserver am DAG- oder Active Directory-Standort akzeptiert wird, der das endgültige Ziel für die Nachricht enthält, ist der nächste Hop für die Nachricht in der Regel das endgültige Ziel selbst. Das Ziel der Schattenredundanz, zwei Kopien einer Nachricht während der Übertragung zu behalten, ist 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 Warteschlangen auf einem Postfachserver ausgleichen muss, mehrere Hops innerhalb derselben Transport-Hochverfügbarkeitsgrenze.

Shadow-Redundanz mit Exchange 2010-basierten Hub-Transport-Servern am selben Active Directory-Standort

Wenn ein Exchange 2010-Hub-Transport-Server eine Nachricht an einen Exchange 2013-Postfachserver am selben Active Directory-Standort überträgt, kündigt der Exchange 2010-Hub-Transport-Server die Unterstützung für Schattenredundanz mithilfe des XSHADOW-Befehls an, der Postfachserver kündigt jedoch keine Unterstützung für Schattenredundanz an. Dadurch wird verhindert, dass der Exchange 2010-Hub-Transport-Server eine Schattenkopie der Nachricht auf einem Exchange 2013-Postfachserver erstellt.

Wenn der Transportdienst auf einem Exchange 2013-Postfachserver eine Nachricht an einen Exchange 2010-Hub-Transport am selben Active Directory-Standort überträgt, überprüft der Exchange 2013-Postfachserver die Nachricht für den Exchange 2010-Hub-Transport-Server. Nachdem der Exchange 2013-Postfachserver vom Exchange 2010-Hub-Transport-Server die Bestätigung erhalten hat, dass die Nachricht erfolgreich empfangen wurde, verschiebt der Exchange 2013-Postfachserver die erfolgreich verarbeitete Nachricht in das Sicherheitsnetz. Die vom Exchange 2013-Postfach im Sicherheitsnetz gespeicherten erfolgreich verarbeiteten Nachrichten werden jedoch nie erneut an die Exchange 2010-Hub-Transport-Server übermittelt.

SMTP-Timeouts

Bei dem Versuch, eine redundante Kopie der Nachricht zu erstellen, kann es zu einer Zeitüberschreitung der SMTP-Verbindung zwischen dem sendenden SMTP-Server und dem primären Server oder der SMTP-Sitzung zwischen dem primären Server und dem Schattenserver kommen. Empfangsconnectors und Sendeconnectors verfügen beide über einen ConnectionInactivityTimeOut-Parameter , der angibt, wann Daten tatsächlich auf dem Connector übertragen werden. Empfangsconnectors verfügen auch über einen absoluten ConnectionTimeOut-Parameter .

Wenn bei einer der SMTP-Sitzungen eine Zeitüberschreitung auftritt, bevor die Schattenkopie der Nachricht erfolgreich erstellt und bestätigt wird, wird das Ergebnis durch den Parameter RejectMessageOnShadowFailure im Cmdlet Set-TransportConfig gesteuert. Standardmäßig lautet $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 sie mit dem vorübergehenden Fehler 451 4.4.0zurückgewiesen.

Wenn die Schattenkopie einer Nachricht erfolgreich erstellt wird, aber die SMTP-Sitzung zwischen dem sendenden SMTP-Server und dem primären Server eine Zeitüberschreitung aufweist, akzeptiert und verarbeitet der primäre Server die primäre Nachricht. Der sendende SMTP-Server stellt die nicht bestätigte Nachricht erneut zu, aber die Erkennung doppelter Nachrichten verhindert, dass Exchange-Postfachbenutzer die doppelten Nachrichten sehen. Wenn der sendende SMTP-Server die Nachricht erneut übermittelt, erstellt der primäre Server eine weitere Schattenkopie der Nachricht. Es besteht keine Beziehung zwischen den Schattennachrichten, die während der erneuten Übermittlung von Nachrichten durch den sendenden SMTP-Server erstellt wurden.

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

Parameter für die Erstellung von Schattennachrichten

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 Status "Verwerfen" der Nachricht als Zustellung abgeschlossen. Der discard-Status ist im Grunde eine Meldung, die eine Liste der Nachrichten enthält, die überwacht werden. Eine erfolgreich zugestellte Nachricht muss nicht in einer Schattenwarteschlange aufbewahrt werden. Sobald der Schattenserver 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 das Sicherheitsnetz.

Der Schattenserver ermittelt den Status der Schattennachrichten 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 zusammenhängender Nachrichten, gibt der Schattenserver den Befehl XQDISCARD aus, um die Verwerfungs status der primären Nachrichten zu ermitteln. Wenn der Schattenserver nach einem vorkonfigurierten Zeitintervall keine SMTP-Sitzung mit dem primären Server eröffnet hat, öffnet der Schattenserver eine SMTP-Sitzung mit dem primären Server und gibt den Befehl XQDISCARD aus. Das Zeitintervall wird durch den Parameter ShadowHeartbeatFrequency im Cmdlet Set-TransportConfig gesteuert. Der Standardwert ist 2 Minuten. Nachdem der Schattenserver eine SMTP-Sitzung mit dem primären Server eröffnet hat, antwortet der primäre Server mit den Verwerfungsbenachrichtigungen für Nachrichten, die für den abfragenden Schattenserver gelten. In Exchange 2013 werden Verwerfungsbenachrichtigungen auf dem Datenträger und nicht im Arbeitsspeicher gespeichert. Wenn der Microsoft Exchange-Transportdienst neu gestartet wird, werden die Verwerfungsbenachrichtigungen daher beibehalten. Nach dem Start des Diensts weiß der primäre Server immer noch über die Nachrichten, die er erfolgreich verarbeitet hat, und diese Informationen stehen dem Schattenserver zur Verfügung.

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 Schattenserver nach einem vorkonfigurierten Zeitintervall keine SMTP-Sitzung mit dem primären Server öffnen kann oder wenn die Transportdatenbank des primären Servers eine andere Datenbank-ID aufweist, stuft sich der Schattenserver selbst zum primären Server hoch, stuft die Schattennachrichten als primäre Nachrichten höher und überträgt die Nachrichten an den nächsten Hop. Das Zeitintervall wird durch den Parameter ShadowResubmitTimeSpan im Cmdlet Set-TransportConfig gesteuert. Der Standardwert beträgt drei Stunden.

Der Schattenredundanz-Manager ist die Kernkomponente eines Exchange 2013-Transportservers, der für die Verwaltung der Schattenredundanz verantwortlich ist. Der Shadow-Redundanz-Manager speichert die folgenden Informationen zu allen primären Nachrichten, die ein Server aktuell verarbeitet:

• Der Schattenserver für jede verarbeitete primäre Nachricht.
• Löschstatus, der an die Shadow-Server gesendet wird

Shadow Redundancy Manager ist für Folgendes für alle Shadow-Nachrichten verantwortlich, die ein Shadow-Server in seinen Shadow-Warteschlangen hat:

• 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.
• Verfolgen Sie Nachrichtenverzweigungen und andere Nebeneffektnachrichten wie Zustellungsstatusbenachrichtigungen (Delivery Status Notifications (DSNs) und Journalberichte, um sicherzustellen, dass die redundante Kopie der Nachricht erst freigegeben wird, wenn alle Forks der Nachricht vollständig verarbeitet wurden.

In der folgenden Tabelle werden die Parameter beschrieben, mit denen die Pflege von Schattennachrichten gesteuert wird.

Nachrichtenverarbeitung nach einem Ausfall

Schattenredundanz minimiert den Nachrichtenverlust aufgrund von Serverausfällen. Wenn ein Transportserver nach einem Ausfall wieder online ist, gibt es zwei Szenarien:

• Der Server geht mit einer neuen Transportdatenbank wieder online: In diesem Szenario kann die Transportdatenbank aufgrund von Datenbeschädigung oder Hardwarefehler nicht wiederhergestellt werden. Da der Transportserver in diesem Fall über eine neue Datenbank-ID verfügt, wird er von den anderen Transportservern in der organization als neue Route erkannt. Dies gilt auch für Situationen, in denen ein Server nicht wiederhergestellt werden konnte und ein neuer Server als Ersatz bereitgestellt wurde.

• Der Server geht mit derselben Transportdatenbank wieder online: In diesem Szenario ist der jeweilige Transportserver nicht ausgefallen, sondern war offline genug für den Schattenserver, um den Besitz der Nachrichten zu übernehmen und sie erneut zu übermitteln. Beispielsweise würde ein Netzwerkausfall Karte oder eine lange Wartung des Servers dieses Szenario verursachen.

In der folgenden Tabelle wird zusammengefasst, wie Schattenredundanz auf diese beiden Szenarien reagiert. Aus Gründen der Übersichtlichkeit wird angenommen, dass der Server, der ausgefallen ist, den Namen "Postfach01" hat.

Nachrichtenverarbeitung in Wiederherstellungsszenarien