Shadow-Redundanz
Gilt für: Exchange Server 2013
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 Schattenredundanz das Löschen einer Nachricht aus der Transportdatenbank auf einem Transportserver, bis der Server den nächsten Hop im Übermittlungspfad der Nachricht überprüft hat. Wenn beim nächsten Hop ein Fehler aufgetreten ist, bevor eine erfolgreiche Übermittlung an den Transportserver gemeldet wurde, hat der Transportserver die Nachricht erneut an diesen nächsten Hop gesendet. Exchange 2010-Server haben das XSHADOW-Verb verwendet, um ihre Schattenredundanzunterstützung anzukündigen. Wenn ein SMTP-Server keine Schattenredundanz unterstützt, hat Exchange 2010 eine verzögerte Bestätigung basierend auf einem konfigurierten Zeitintervall auf dem Empfangsconnector verwendet, um eine redundante Kopie der Nachricht zu erstellen.
Die wichtigste Verbesserung der Schattenredundanz in Microsoft Exchange Server 2013 besteht darin, dass der Transportserver jetzt eine redundante Kopie aller Nachrichten erstellt, die er empfängt, bevor er bestätigt, dass die Nachricht erfolgreich an den sendenden Server zurückgeht. Die Unterstützung des sendenden Servers oder die fehlende Unterstützung 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 bei 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.
| Ausdruck | Beschreibung |
|---|---|
| Transportserver | Ein Exchange-Server, der über Nachrichtenwarteschlangen verfügt und für das Weiterleiten von Nachrichten zuständig ist. In Exchange 2013 ist ein Transportserver ein Postfachserver (der Transportdienst auf dem Postfachserver). |
| Transportdatenbank | Die Nachrichtenwarteschlangendatenbank auf einem Exchange 2013-Transportserver. Schattenwarteschlangen und Safety Net werden ebenfalls in der Transportdatenbank gespeichert. |
| Grenze für Transporthochverfügbarkeit | Eine Datenbankverfügbarkeitsgruppe (DAG) in DAG-Umgebungen oder ein Active Directory-Standort in Nicht-DAG-Umgebungen. Wenn eine Nachricht auf einem Transportserver an der Hochverfügbarkeitsgrenze des Transports eingeht, versucht Exchange, zwei redundante Kopien der Nachricht auf Transportservern innerhalb der Grenze zu verwalten. 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 Transportserver, der derzeit die primäre Nachricht verarbeitet. |
| Shadow-Server | Der Transportserver, der die Schattenmeldung für den primären Server enthält. Ein Transportserver kann gleichzeitig der primäre Server für einige Nachrichten und der Schattenserver 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 | Die Informationen, die ein Transportserver für Schattennachrichten verwaltet, die darauf hindeuten, dass 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 exchange 2013 verbesserte Version des Transportdumpsters. 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. |
| 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. |
Anforderungen für die Funktion Shadow-Redundanz
Obwohl es offensichtlich erscheint, erfordert Schattenredundanz mehrere Exchange 2013-Postfachserver. Der Postfachserver kann eigenständige Server oder Postfachserver und Clientzugriffsserver sein, 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 die DAG mehrere Active Directory-Standorte umfasst, bevorzugt die Schattenredundanz die Erstellung einer redundanten Kopie der Nachricht an einem Active Directory-Remotestandort, um standortresilienz zu erzielen.
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 ist 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 erstellt wird, indem Sie den RejectMessageOnShadowFailure-Parameter im Cmdlet Set-TransportConfig verwenden. Die Nachricht wird mit einem vorübergehenden Fehler abgelehnt, aber der sendenden Server kann die Nachricht erneut übertragen. Der SMTP-Antwortcode lautet 451 4.4.0 Message failed to be made redundant. Sie sollten Exchange 2013 so konfigurieren, dass Nachrichten abgelehnt werden, die nur dann redundant gemacht werden können, wenn In Ihrer Organisation mehrere Exchange 2013-Postfachserver verfügbar sind.
In der folgenden Tabelle werden die Parameter beschrieben, die Schattenredundanz ermöglichen.
Parameter, die Schattenredundanz ermöglichen
| Parameter | Standardwert | Beschreibung |
|---|---|---|
| ShadowRedundancyEnabled für Set-TransportConfig | $true |
|
| RejectMessageOnShadowFailure für Set-TransportConfig | $false |
Dieser Parameter ist nur sinnvoll, wenn ShadowRedundancyEnabled auf festgelegt ist |
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 hauptbestimmende Faktoren:
- Nachrichten, die von außerhalb einer Transportgrenze für Hochverfügbarkeit empfangen 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.
Eine Transportgrenze für Hochverfügbarkeit ist eine der folgenden:
- Eine DAG für Postfachserver, die Mitglieder einer DAG sind. Dies umfasst eine DAG, die mehrere Active Directory-Standorte umfasst.
- 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 über die Hochverfügbarkeitsgrenze des Transports hinweg erneute Übermittlungen von Schattennachrichten auftreten. 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 Hochverfügbarkeitsgrenze des Transports empfängt, ist der Postfachserver nicht über die Unterstützung oder fehlende Unterstützung für Schattenredundanz durch den sendenden Server besorgt. 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:
.gif "Erstellen von Schattennachrichten")
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.
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 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. Diese Einstellung wird durch den ShadowMessagePreference-Parameter im Cmdlet Set-TransportService gesteuert. Der Standardwert ist
PreferRemote, aber Sie können ihn inRemoteOnlyoderLocalOnlyändern. - 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 ShadowMessagePreference-Parameters .
- 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. Diese Einstellung wird durch den ShadowMessagePreference-Parameter im Cmdlet Set-TransportService gesteuert. Der Standardwert ist
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.
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 Hochverfügbarkeitsgrenze des Transports überträgt und der SMTP-Server auf der anderen Seite den erfolgreichen Empfang der Nachricht bestätigt, verschiebt der Transportserver die Nachricht in Safety Net. 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 ist in Exchange 2013 optimiert, sodass, wenn sich das endgültige Ziel in einem DAG- oder Active Directory-Standort befindet, in der Regel nicht mehrere Hops zwischen dem Transportdienst auf Postfachservern an diesem DAG- oder Active Directory-Standort erforderlich sind. Sobald die Nachricht vom Transportdienst auf einem Postfachserver im DAG- oder Active Directory-Standort akzeptiert wurde, der das ultimative 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 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, für die das Cmdlet Redirect-Message zum Leeren der aktiven Warteschlangen auf einem Postfachserver erforderlich ist, mehrere Hops innerhalb derselben Transportgrenze für Hochverfügbarkeit.
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 an demselben Active Directory-Standort überträgt, kündigt der Exchange 2010-Hub-Transportserver die Unterstützung für Schattenredundanz mit dem XSHADOW-Befehl an, aber der Postfachserver kündigt 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 an demselben Active Directory-Standort überträgt, überschattete 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 erhält, dass die Nachricht erfolgreich empfangen wurde, verschiebt der Exchange 2013-Postfachserver die erfolgreich verarbeitete Nachricht in Safety Net. Die erfolgreich verarbeiteten Nachrichten, die von Exchange 2013 Mailbox in Safety Net gespeichert wurden, werden jedoch nie erneut an die Exchange 2010 Hub-Transport-Server übermittelt.
SMTP-Timeouts
Beim Versuch, eine redundante Kopie der Nachricht zu erstellen, kann für die SMTP-Verbindung zwischen dem sendenden SMTP-Server und dem primären Server oder für die SMTP-Sitzung zwischen dem primären Server und dem Schattenserver ein Timeout auftreten. 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 Schattenkopie einer Nachricht erfolgreich erstellt wurde, aber die SMTP-Sitzung zwischen dem sendenden SMTP-Server und dem primären Server ein Timeout aufweist, akzeptiert und verarbeitet der primäre Server die primäre Nachricht. Der sendende SMTP-Server übermittelt die nicht bestätigten Nachrichten erneut, aber die Erkennung doppelter Nachrichten verhindert, dass Exchange-Postfachbenutzer die doppelten Nachrichten sehen. Wenn der sendenden 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 Schattenmeldungserstellung
| Source | Standardwert | Beschreibung |
|---|---|---|
| ShadowMessagePreferenceSetting für Set-TransportConfig | PreferRemote |
Dieser Parameter ist nur sinnvoll, wenn der primäre Server, der versucht, eine Schattenkopie der Nachricht zu erstellen, ein Postfachserver ist, der Mitglied einer DAG ist, die mehrere Active Directory-Standorte umfasst. |
| MaxRetriesForRemoteSiteShadow für Set-TransportConfig | 4 | Dieser Parameter wird verwendet, wenn der Postfachserver Mitglied einer DAG ist, die mehrere Active Directory-Standorte umfasst.
Wenn eine Schattenkopie der Nachricht nicht erfolgreich erstellt werden kann:
|
| MaxRetriesForLocalSiteShadow für Set-TransportConfig | 2 | Dieser Parameter wird unter folgenden Umständen verwendet:
Wenn eine Schattenkopie der Nachricht nicht erfolgreich erstellt werden kann:
|
| ConnectionInactivityTimeout für Set-ReceiveConnector | 5 Minuten im Transportdienst auf Postfachservern 5 Minuten im Front-End-Transportdienst auf Clientzugriffsservern. 1 Minute auf Edge-Transport-Servern. |
Dieser Parameter gibt die maximale Zeit an, die eine geöffnete SMTP-Verbindung mit einem Quellmessagingserver im Leerlauf bleiben kann, bevor die Verbindung geschlossen wird. Der Wert dieses Parameters muss kleiner als der durch den ConnectionTimeout-Parameter angegebene Wert sein. |
| ConnectionTimeout für Set-ReceiveConnector | 10 Minuten im Transportdienst auf Postfachservern 10 Minuten im Front-End-Transportdienst auf Clientzugriffsservern. 5 Minuten auf Edge-Transport-Servern. |
Dieser Parameter gibt die maximale Zeit an, die eine SMTP-Verbindung mit einem Quellmessagingserver geöffnet bleiben kann, auch wenn der Quellmessagingserver Daten überträgt. Der Wert dieses Parameters muss größer als der durch den ConnectionInactivityTimeout-Parameter angegebene Wert sein. |
| 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. |
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. Wenn der Schattenserver nach einem vorkonfigurierten Zeitintervall keine SMTP-Sitzung mit dem primären Server geöffnet hat, öffnet der Schattenserver eine SMTP-Sitzung mit dem primären Server und gibt den XQDISCARD-Befehl 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 geöffnet hat, antwortet der primäre Server mit den Verwerfbenachrichtigungen für Nachrichten, die für den abfragenden Schattenserver gelten. In Exchange 2013 werden Verwerfensbenachrichtigungen auf dem Datenträger und nicht im Arbeitsspeicher gespeichert. Wenn der Microsoft Exchange-Transportdienst neu gestartet wird, werden die Verwerfensbenachrichtigungen daher beibehalten. 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 Schattenserver nach einem vorkonfigurierten Zeitintervall keine SMTP-Sitzung mit dem primären Server öffnen kann oder die Transportdatenbank des primären Servers über eine andere Datenbank-ID verfügt, stuft sich der Schattenserver selbst als primären Server herauf, stuft die Schattennachrichten als primäre Nachrichten höher und überträgt die Nachrichten an den nächsten Hop. Das Zeitintervall wird durch den ShadowResubmitTimeSpan-Parameter im Cmdlet Set-TransportConfig gesteuert. Der Standardwert beträgt drei Stunden.
Shadow Redundancy Manager ist die Kernkomponente eines Exchange 2013-Transportservers, der für die Verwaltung von Schattenredundanz zuständig ist. Der Shadow-Redundanz-Manager speichert die folgenden Informationen zu allen primären Nachrichten, die ein Server aktuell verarbeitet:
- Der Schattenserver für jede primäre Nachricht, die verarbeitet wird.
- Löschstatus, der an die Shadow-Server gesendet wird
Der Schattenredundanz-Manager ist für Folgendes für alle Schattenmeldungen verantwortlich, die ein Schattenserver in seinen Schattenwarteschlangen enthält:
- 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 Nachrichtenverzweigungen und anderen Nebeneffektnachrichten wie Übermittlungsstatusbenachrichtigungen (Delivery Status Notifications, DSNs) und Journalberichten, um zu überprüfen, ob die redundante Kopie der Nachricht erst freigegeben wird, wenn alle Forks der Nachricht vollständig verarbeitet sind.
In der folgenden Tabelle werden die Parameter beschrieben, die steuern, wie Schattenmeldungen verwaltet 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. |
| 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 Warteschlangen, 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 Schattennachrichten laufen schließlich nach der Summe von SafetyNetHoldTime und MessageExpirationTime auf Set-TransportService von Safety Net ab. |
| MessageExpirationTimeout für Set-TransportService | 2 Tage | Gibt an, wie lange eine Nachricht in einer Warteschlange verbleiben kann, bevor sie abläuft. |
Nachrichtenverarbeitung nach einem Ausfall
Schattenredundanz minimiert den Verlust von Nachrichten 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 wieder online geschaltet: In diesem Szenario kann die Transportdatenbank aufgrund von Datenbeschädigungen oder Hardwarefehlern 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 konnte und ein neuer Server als Ersatz bereitgestellt wurde.
Der Server wird mit derselben Transportdatenbank wieder online geschaltet: In diesem Szenario ist der bestimmte Transportserver nicht fehlgeschlagen, sondern war lange genug offline, damit der Schattenserver den Besitz der Nachrichten übernehmen und sie erneut übermitteln konnte. Beispielsweise würde ein Netzwerkkartenfehler oder eine lange Wartung auf dem Server dieses Szenario verursachen.
In der folgenden Tabelle wird zusammengefasst, wie Schattenredundanz auf diese beiden Szenarien reagiert. Gehen Sie der Übersichtlichkeit halber davon aus, dass der Server mit einem Ausfall den Namen Mailbox01 hat.
Nachrichtenverarbeitung in Wiederherstellungsszenarien
| Szenario für die Wiederherstellung | Durchgeführte Aktionen |
|---|---|
| Mailbox01 wird mit einer neuen Datenbank wieder online geschaltet. | Wenn Mailbox01 nicht mehr verfügbar ist, übernimmt jeder Server, auf dem Schattennachrichten für Mailbox01 in die Warteschlange gestellt wurden, den Besitz dieser Nachrichten und sendet sie erneut. Die Nachrichten werden dann an ihre Ziele übermittelt. Die maximale Verzögerung für Nachrichten ist der Wert des ShadowHeartbeatFrequency-Parameters im Cmdlet Set-TransportConfig . Der Standardwert ist 2 Minuten. |
| Mailbox01 wird mit derselben Datenbank wieder online geschaltet. | 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 auf Nicht-Exchange-Messagingsystemen können jedoch doppelte Kopien von Nachrichten empfangen. Die maximale Verzögerung für Nachrichten ist der Wert des ShadowResubmitTimeSpan-Parameters im Cmdlet Set-TransportConfig . Der Standardwert beträgt drei Stunden. |