Shadow-Redundanz in Exchange 2016

[Dieses Thema gehört zur Vorabdokumentation und kann in künftigen Versionen geändert werden. Leere Themen wurden als Platzhalter hinzugefügt. Wenn Sie Feedback dazu haben, freuen wir uns über Ihre Nachricht. Senden Sie uns eine E-Mail an: ExchangeHelpFeedback@microsoft.com.]  

Gilt für:Exchange Server 2016

In diesem Artikel erfahren Sie, wie Shadow-Redundanz in Exchange 2016 die Hochverfügbarkeit von Nachrichten in der Transportpipeline verbessert.

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 unterstützt die Verbesserungen an der Shadow-Redundanz-Funktion, die mit Exchange 2013 implementiert wurden: Der Transportdienst auf einem Postfachserver erstellt jetzt von jeder empfangenen Nachricht eine redundante Kopie, bevor er dem sendenden Server den Nachrichtenempfang bestätigt. Das Vorhalten redundanter Kopien von Nachrichten während der Übermittlung ist weit mehr als nur eine Behelfslösung, die einmal funktioniert und einmal nicht. Dank dieses Ansatzes spielt es jetzt für die Bereitstellung von Shadow-Redundanz keine Rolle mehr, welche Funktionen der sendende Server unterstützt (ob er also Shadow-Redundanz unterstützt oder nicht). Damit ist nun gewährleistet, dass von allen Nachrichten in der Transportpipeline noch während der Übermittlung eine redundante Kopie erstellt wird. Erkennt Exchange, dass die ursprüngliche Nachricht während der Übermittlung verloren gegangen ist, wird stattdessen die redundante Kopie der Nachricht zugestellt.

Weitere Informationen zu den Exchange 2016-Funktionen für Hochverfügbarkeit während des Transports finden Sie unter Hohe Verfügbarkeit des Transports. Weitere Informationen zum Thema Nachrichtenredundanz nach erfolgreicher Nachrichtenzustellung finden Sie unter Sicherheitsnetz in Exchange 2016.

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.

 

Begriff Beschreibung

Grenze für Transporthochverfügbarkeit

Hierbei handelt es sich um eine Database Availability Group (DAG) in DAG-Umgebungen bzw. einen Active Directory-Standort in Umgebungen ohne DAGs. Im Falle einer DAG, die sich über mehrere Active Directory-Standorte erstreckt, ist dennoch die DAG die Grenze (nicht der Standort).

Geht eine Nachricht auf einem Postfachserver innerhalb der Grenze für Transporthochverfügbarkeit ein, versucht Exchange, zwei redundante Kopien der Nachricht auf Postfachservern innerhalb der Grenze vorzuhalten. Verlässt eine Nachricht die Grenze für Transporthochverfügbarkeit, stoppt Exchange die Shadow-Redundanz-Funktion.

Primäre Nachricht

Die Nachricht, die zur Zustellung an die Transportpipeline übermittelt wird.

Shadow-Nachricht

Die redundante Kopie der Nachricht, die der Shadow-Server beibehält, bis bestätigt wird, dass die primäre Nachricht erfolgreich durch den primären Server verarbeitet wurde.

Primärer Server

Der Postfachserver, der die primäre Nachricht aktuell verarbeitet

Shadow-Server

Der Postfachserver, der für den primären Server die Shadow-Nachricht vorhält. Ein Postfachserver kann gleichzeitig primärer Server für einige Nachrichten und Shadow-Server für andere Nachrichten sein.

Shadow-Warteschlange

Die Zustellungswarteschlange, in der der Shadow-Server die Shadow-Nachrichten speichert. Bei Nachrichten mit mehreren Empfängern erfordert jeder nächste Hop für die primäre Nachricht eine separate Shadow-Warteschlange.

Löschstatus

Auf dem Postfachserver hinterlegte Information zu einer Shadow-Nachricht, die angibt, ob die primäre Nachricht erfolgreich verarbeitet wurde

Löschbenachrichtigung

Die von einem primären Server an einen Shadow-Server gesendete Antwort, dass eine Shadow-Nachricht gelöscht werden kann.

Sicherheitsnetz

Die verbesserte Version des Transportdumpsters in Exchange 2013 oder höher. Nachrichten, die vom Transportdienst auf einem Postfachserver erfolgreich verarbeitet oder einem Postfachempfänger zugestellt wurden, werden in das Sicherheitsnetz verschoben. Weitere Informationen finden Sie unter Sicherheitsnetz in Exchange 2016.

Shadow-Redundanz-Manager

Die Transportkomponente, die die Shadow-Redundanz verwaltet.

Taktsignal

Der Prozess, der es primären und Shadow-Servern ermöglicht, ihre gegenseitige Verfügbarkeit zu überprüfen.

Die Funktion Shadow-Redundanz in Exchange 2016 erfordert 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

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.

 

Parameter Standardwert Beschreibung

ShadowRedundancyEnabled für Set-TransportConfig

$true

  • $true: Shadow-Redundanz ist auf allen Postfachservern in der Organisation aktiviert.

  • $false: Shadow-Redundanz ist auf allen Postfachservern in der Organisation deaktiviert.

RejectMessageOnShadowFailure für Set-TransportConfig

$false

  • $false: Wenn keine Shadow-Kopie einer Nachricht erstellt werden kann, wird die primäre Nachricht trotzdem von den Postfachservern in der Organisation angenommen. Von der Nachricht wird dann während der Übermittlung keine redundante Kopie erstellt.

  • $true: Nachrichten werden von den Postfachservern in der Organisation erst angenommen oder bestätigt, wenn erfolgreich eine Shadow-Kopie von ihnen erstellt wurde. Wenn von einer Nachricht keine Shadow-Kopie erstellt werden kann, wird die primäre Nachricht mit einem vorübergehenden Fehler abgelehnt. Der sendende Server kann die Nachricht jedoch erneut übermitteln. Der SMTP-Antwortcode lautet 451 4.4.0 Message failed to be made redundant. Von allen Nachrichten in der Organisation wird während der Übermittlung eine redundante Kopie vorgehalten.

    Hinweis: Sie sollten diesen Wert nur setzen, wenn in ein und derselben DAG oder an ein und demselben Active Directory-Standort mehrere Postfachserver vorhanden sind, da nur dann eine Shadow-Kopie der Nachricht erstellt werden kann.

Dieser Parameter hat nur Auswirkungen, wenn ShadowRedundancyEnabled auf $true gesetzt ist.

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.

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:

Erzeugen von Shadow-Nachrichten
  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 er eine Verbindung zu einem anderen Postfachserver in derselben DAG her. Wenn die DAG sich über mehrere Active Directory-Standorte erstreckt, wird standardmäßig ein Postfachserver an einem anderen Active Directory-Standort bevorzugt. (Der Standardwert des Parameters ShadowMessagePreference im Cmdlet Set-TransportService ist PreferRemote. Sie können diesen Wert jedoch auch auf RemoteOnly oder LocalOnly setzen.)

    • Wenn der primäre Server kein Mitglied einer DAG ist, stellt er eine Verbindung zu einem anderen Postfachserver am selben Active Directory-Standort her (unabhängig von dem für den Parameter ShadowMessagePreference festgelegten Wert).

  3. Der primäre Server übermittelt eine Kopie der Nachricht an den Transportdienst auf einem anderen Postfachserver. Dieser Transportdienst bestätigt die erfolgreiche Erstellung der Nachrichtenkopie. Die Kopie der Nachricht ist die Shadow-Nachricht. Der Postfachserver, auf dem sie gespeichert ist, ist der Shadow-Server für den primären Server. Die Nachricht befindet sich in einer Shadow-Warteschlange auf dem Shadow-Server.

  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.

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 zum Sicherheitsnetz finden Sie unter Sicherheitsnetz in Exchange 2016.

Das Nachrichtenrouting wurde optimiert: Befindet sich das endgültige Ziel in einer DAG oder an einem Active Directory-Standort, sind im Allgemeinen nicht mehrere Hops zwischen den Servern in der Ziel-DAG bzw. am Zielstandort erforderlich. Sobald die Nachricht vom Transportdienst auf einem Postfachserver in der Ziel-DAG oder im Ziel-Active Directory angenommen wurde, ist der nächste Hop für die Nachricht normalerweise das endgültige Ziel selbst (z. B. der Postfachserver mit der aktiven Kopie des Zielpostfachs). Der Sinn und Zweck der Funktion Shadow-Redundanz, während der Übermittlung zwei Kopien einer Nachricht vorzuhalten, ist erfüllt, wenn sich eine Shadow-Kopie der Nachricht an einem beliebigen Speicherort in der DAG oder am Active Directory-Standort befindet. Üblicherweise erfordern nur DAG-Failoverszenarien, in denen das Cmdlet Redirect-Message die aktiven Nachrichtenwarteschlangen auf einem Postfachserver leert, mehrere Hops innerhalb ein und derselben Grenze für Transporthochverfügbarkeit.

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.

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. Sowohl Empfangs- als auch Sendeconnectors verfügen über einen Parameter ConnectionInactivityTimeOut, der greift, wenn tatsächlich Daten über den Connector übertragen werden. Empfangsconnectors haben außerdem einen absoluten Parameter ConnectionTimeOut.

Kommt es in einer der SMTP-Sitzungen zu einem Timeout, bevor die Shadow-Kopie der Nachricht erstellt und die Erstellung bestätigt wurde, steuert der Parameter RejectMessageOnShadowFailure im Cmdlet Set-TransportConfig, was geschieht. Standardmäßig lautet der Wert dieses Parameters $false, d. h. die primäre Nachricht wird angenommen, ohne dass eine Shadow-Kopie erstellt wird. Wenn der Wert dieses Parameters $true lautet, wird die primäre Nachricht mit dem vorübergehenden Fehler 451 4.4.0 abgelehnt.

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.

 

Quelle Standardwert Beschreibung

ShadowMessagePreferenceSetting für Set-TransportConfig

PreferRemote

Dieser Parameter wird nur verwendet, wenn der primäre Server, der versucht, eine Shadow-Kopie der Nachricht zu erstellen, Mitglied einer DAG ist, die sich über mehrere Active Directory-Standorte erstreckt.

  • PreferRemote: Es wird versucht, eine Shadow-Kopie der Nachricht auf einem DAG-Mitglied an einem anderen Active Directory-Standort zu erstellen. Wie oft dies versucht wird, wird im Parameter MaxRetriesForRemoteSiteShadow festgelegt. Schlägt der Vorgang fehl, wird versucht, eine Shadow-Kopie der Nachricht auf einem DAG-Mitglied am lokalen Active Directory-Standort zu erstellen. Wie oft dies versucht wird, wird im Parameter MaxRetriesForLocalSiteShadow festgelegt.

  • LocalOnly: Die Erstellung einer Shadow-Kopie der Nachricht wird nur auf einem DAG-Mitglied am lokalen Active Directory-Standort versucht. Wie oft dies versucht wird, wird im Parameter MaxRetriesForLocalSiteShadow festgelegt.

  • RemoteOnly: Die Erstellung einer Shadow-Kopie der Nachricht wird nur auf einem DAG-Mitglied an einem anderen Active Directory-Standort versucht. Wie oft dies versucht wird, wird im Parameter MaxRetriesForRemoteSiteShadow festgelegt.

MaxRetriesForRemoteSiteShadow für Set-TransportConfig

4

Dieser Parameter legt fest, wie oft höchstens versucht wird, eine Shadow-Kopie der Nachricht auf einem anderen Server in der DAG zu erstellen, wenn der Wert des Parameters ShadowMessagePreferenceSetting auf PreferRemote (Standardwert) oder RemoteOnly gesetzt ist.

Dieser Parameter wird nur verwendet, wenn der Postfachserver Mitglied einer sich über mehrere Active Directory-Standorte erstreckenden DAG ist.

Wenn nach der angegebenen Anzahl von Versuchen keine Schattenkopie der Nachricht erstellt werden konnte, legt der Wert für den Parameter RejectMessageOnShadowFailure fest, was geschieht:

  • $true: Die primäre Nachricht wird mit einem vorübergehenden Fehler abgelehnt.

  • $false: Die primäre Nachricht wird trotzdem angenommen, es wird jedoch keine redundante Kopie vorgehalten.

MaxRetriesForLocalSiteShadow für Set-TransportConfig

2

Dieser Parameter legt fest, wie oft höchstens versucht wird, eine Shadow-Kopie der Nachricht auf einem anderen Postfachserver am lokalen Active Directory-Standort zu erstellen, wenn:

  • Der Postfachserver Mitglied einer DAG ist, die sich über mehrere Active Directory-Standorte erstreckt und der Wert des Parameters ShadowMessagePreferenceSetting auf PreferRemote (Standardwert) oder LocalOnly gesetzt ist

  • Der Postfachserver Mitglied einer DAG ist, die auf einen einzigen Active Directory-Standort begrenzt ist

  • Der Postfachserver kein Mitglied einer DAG ist

Wenn nach der angegebenen Anzahl von Versuchen keine Schattenkopie der Nachricht erstellt werden konnte, legt der Wert für den Parameter RejectMessageOnShadowFailure fest, was geschieht:

  • $true: Die primäre Nachricht wird mit einem vorübergehenden Fehler abgelehnt.

  • $false: Die primäre Nachricht wird trotzdem angenommen, es wird jedoch keine redundante Kopie vorgehalten.

ConnectionInactivityTimeout für Set-ReceiveConnector

5 Minuten für Empfangsconnectors im Transportdienst auf Postfachservern

Dieser Parameter legt fest, wie lange eine offene SMTP-Verbindung zum Quellmessagingserver höchstens im Leerlauf verbleiben darf, bevor sie beendet wird. Der Wert dieses Parameters muss größer sein als der Wert des Parameters ConnectionTimeout.

ConnectionTimeout für Set-ReceiveConnector

10 Minuten für Empfangsconnectors im Transportdienst auf Postfachservern

Dieser Parameter legt fest, wie lange eine SMTP-Verbindung zum Quellmessagingserver maximal geöffnet bleiben darf, und greift auch, wenn der Server Daten übermittelt. Der Wert dieses Parameters muss größer sein als der Wert des Parameters ConnectionInactivityTimeout.

ConnectionInactivityTimeOut für Set-SendConnector

10 Minuten

Mit diesem Parameter wird die maximale Zeit angegeben, für die eine geöffnete SMTP-Verbindung zu einem Zielmessagingserver im Leerlauf bleiben kann, bis die Verbindung geschlossen wird.

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 übertragen hat und dieser Hop den Empfang der Nachricht bestätigt hat, aktualisiert der primäre Server den Löschstatus der Nachricht in "Übertragung abgeschlossen". Beim Löschstatus handelt es sich im Grunde um eine Nachricht, die eine Liste von Nachrichten enthält, die überwacht werden. Eine erfolgreich übermittelte Nachricht muss nicht in der Shadow-Warteschlange verbleiben. Sobald der Shadow-Server also die Bestätigung erhalten hat, dass der primäre Server die Nachricht erfolgreich an den nächsten Hop übertragen hat, verschiebt der Shadow-Server die Shadow-Nachricht aus der Shadow-Warteschlange in das Sicherheitsnetz.

Der Shadow-Server ermittelt den Löschstatus der Shadow-Nachrichten in seinen Shadow-Warteschlangen, indem er den primären Server abfragt. Wenn der Shadow-Server eine SMTP-Sitzung mit dem primären Server öffnet, beispielsweise zur Übermittlung sonstiger Nachrichten, führt der Shadow-Server den Befehl XQDISCARD aus, um den Löschstatus der primären Nachrichten zu ermitteln. Andernfalls öffnet der Shadow-Server nach einem vorkonfigurierten Zeitintervall automatisch eine SMTP-Sitzung mit dem primären Server. (Das Zeitintervall wird über den Parameter ShadowHeartbeatFrequentcy im Cmdlet Set-TransportConfig festgelegt. Der Standardwert ist 2 Minuten.)

Sobald der Shadow-Server eine SMTP-Sitzung mit dem primären Server geöffnet hat, antwortet der primäre Server mit den Löschbenachrichtigungen für Nachrichten, die auf dem Shadow-Server vorgehalten werden. Löschbenachrichtigungen werden auf der Festplatte gespeichert (nicht m Arbeitsspeicher). Bei einem Neustart des Microsoft Exchange-Transportdiensts sind sie also immer noch vorhanden. Nach dem Start des Diensts stehen die Informationen zu erfolgreich verarbeiteten Nachrichten sowohl dem primären Server als auch dem Shadow-Server weiterhin 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 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.

 

Parameter Standardwert Beschreibung

ShadowHeartbeatFrequency für Set-TransportConfig

2 Minuten

Die maximale Zeitspanne, die ein Shadow-Server wartet, bevor er eine SMTP-Verbindung mit dem primären Server herstellt, um den Löschstatus von Nachrichten zu überprüfen.

ShadowResubmitTimeSpan für Set-TransportConfig

3 Stunden

Gibt an, wie lange ein Server wartet, bevor er entscheidet, dass beim primären Server ein Fehler aufgetreten ist, und den Besitz für die Shadow-Nachrichten in der Shadow-Warteschlange des nicht erreichbaren primären Servers übernimmt.

Beachten Sie: Ein Shadow-Server kann sich bereits vor Ablauf des in diesem Parameter definierten Zeitintervalls zum primären Server hochstufen, wenn er feststellt, dass sich die Datenbank-ID der Warteschlangendatenbank auf dem primären Server geändert hat.

ShadowMessageAutoDiscardInterval für Set-TransportConfig

2 Tage

Gibt an, wie lange ein Server Löschereignisse für erfolgreich übermittelte Nachrichten aufbewahrt. Ein primärer Server stellt Löschereignisse so lange in die Warteschlange, bis er vom Shadow-Server abgefragt wird. Wenn der Shadow-Server den primären Server während des in diesem Parameter festgelegten Zeitraums nicht abfragt, löscht der primäre Server die Löschereignisse in der Warteschlange.

SafetyNetHoldTime für Set-TransportConfig

2 Tage

Gibt an, wie lange erfolgreich verarbeitete Nachrichten im Sicherheitsnetz aufbewahrt werden. Unbestätigte Shadow-Nachrichten werden nach Ablauf des aus der Summe der Werte für die Parameter SafetyNetHoldTime und MessageExpirationTimeout im Cmdlet Set-TransportService gebildeten Zeitraums aus dem Sicherheitsnetz gelöscht.

MessageExpirationTimeout für Set-TransportService

2 Tage

Gibt an, wie lange eine Nachricht in einer Warteschlange verbleiben kann, bevor sie abläuft.

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“.

 

Szenario für die Wiederherstellung Durchgeführte Aktionen

Mailbox01 wird noch vor Ablauf des im Parameter ShadowResubmitTimeSpan definierten Werts (standardmäßig 3 Stunden) wieder online geschaltet, mit einer neuen Warteschlangendatenbank.

Dieses Szenario kann eintreten, wenn die Warteschlangendatenbank aufgrund von Datenbeschädigungen oder Hardwaredefekten nicht mehr wiederhergestellt werden kann.

Alle Server, die Shadow-Nachrichten für Mailbox01 in ihrer Warteschlange vorhalten, übernehmen die Verantwortung für diese Nachrichten, sobald sie erkennen, dass sich die ID der Warteschlangendatenbank auf Mailbox01 geändert hat. Anschließend übermitteln sie die Nachrichten erneut. Die Nachrichten werden dann an ihr jeweiliges Ziel zugestellt.

Wie lange die Nachrichtenübermittlung maximal hinausgezögert wird, nachdem eine neue Warteschlangendatenbank erkannt wurde, wird im Wert des Parameters ShadowHeartbeatFrequency festgelegt (standardmäßig 2 Minuten).

Mailbox01 wird nach Ablauf der im Wert des Parameters ShadowResubmitTimeSpan festgelegten Zeit (standardmäßig 3 Stunden) wieder online geschaltet, mit derselben Datenbank.

Dieses Szenario kann eintreten, wenn eine Netzwerkkarte ausfällt oder zeitaufwendige Wartungsarbeiten an einem Server erforderlich sind.

Sobald der Server Mailbox01 wieder online geschaltet wird, übermittelt er die Nachrichten in seinen Warteschlangen; diese Nachrichten wurden bereits von den Servern übermittelt, die für Mailbox01 die Schattenkopien der Nachrichten vorgehalten haben. Dadurch werden diese Nachrichten doppelt zugestellt. Empfänger mit Exchange-Postfach werden die doppelten Nachrichten dank der Funktion zur Erkennung von Nachrichtenduplikaten nicht sehen. Empfänger, die andere Messaging-Systeme benutzen, sehen die Duplikate der Nachrichten jedoch möglicherweise.

Die maximale Verzögerung für die Nachrichtenübermittlung wird im Wert des Parameters ShadowResubmitTimeSpanfestgelegt.

 
Anzeigen: