Safety Net? Transportdumpster? – Was ist denn das?

Microsoft hat mit Exchange 2007 den Transportdumpster für CCR-/LCR-Umgebungen eingeführt. Der Tranportdumpster gehört zur Hub-Transportrolle, da alle ein- und ausgehende Mails den Hub-Transport passieren müssen. Die Aufgabe des Transportdumpsters ist es, eine Mail in einer Warteschlage (mail.que) zu halten, bis diese in die aktive Datenbank geschrieben worden ist. Sollte es vorher zum Failover kommen, sendet der Transportdumpster die Mail erneut, sobald eine Datenbank mit dem entsprechenden Postfach aktiv wird.

In Exchange 2010 wurde CCR durch die DAG abgelöst. Auch hier existiert der Transportdumpster, der die Mail so lange vorhält, bis diese in eine Datenbank geschrieben worden ist. Jedoch hat Microsoft den Transportdumpster erweitert, um eine Mailverlust bei einem Failover zu reduzieren. In Exchange 2010 wird die Mail aus dem Transportdumpster erst gelöscht, wenn sichergestellt worden ist, dass die Mail in alle Datenbankkopien repliziert wurde. Dies geschieht über die Komponenten Shadow Redundancy, die die Löschung aus der Transportdatenbank bzw. Warteschlange so lange verzögert, bis eine positive Rückmeldung der Replikation eintrifft. Trifft die Rückmeldung nicht ein, wird Mail erneut vom Transportdumpster versendet.

Die Konfiguration des Transportdumpster kann mit folgendem Befehl abgerufen werden:

Get-TransportConfig |  fl *Dumpster* 

Per Default beträgt die Größe des Transportdumpsters 18 MB pro Datenbank. Der maximale Aufbewahrungszeitraum beträgt 7 Tage.

In Exchange 2013 wurde der Transportdumpster von Safety Net abgelöst.
Safety Net wurde jedoch erweitert, um Datenverlust bei Ausfall eines Knotens zu vermeiden.
Der aus Exchange 2010 bekannte Shadow Redundancy ist nun ein Teil von Safety Net. Der Unterschied von Shadow Redundancy in Safety Net zu Exchange 2010 ist, dass die Komponente nun selbst eine redundante Kopie der Mail hält. Wurde die Mail erfolgreich an den nächsten Hop in der Replikationskette übergeben, wird ebenfalls eine Kopie an die Datenbank von Safety Net übergeben. Dies geschieht auf jedem Mailboxserver, der innerhalb der Replikationskette eine Datenbankkopie hält.

Safety Net auf dem ersten Server in dieser Replikationskette wird auch Primary Safety Net genannt.

Parallelen von Transportdumpster in Exchange 2010 und in Safety Net:

  • Safety Net ist eine Warteschlange die mit dem Transportdienst (hier Bestandteil der Mailboxserverrolle) verbunden ist. In der Warteschlange werden Mails aufbewahrt, die erfolgreich verarbeitet wurden.
  • Die Dauer in der Nachrichten in der Warteschlange verweilen können, kann manuell angepasst werden SafetyNetHoldTime in der TransportConfig.

Neu bei Safety Net:

  • Das Safety Net erfordert, anders als bei Exchange 2010, keine DAG mehr. Für Postfachserver die nicht zur DAG gehören, speichert Safety Net Kopien auf anderen Postfachservern am lokalen AD-Standort.
  • Das Safety Net speichert nun selbst die Mails redundant. Sollte das Primary Safety Net für mehr als 12 Stunden nicht erreichbar sein, werden Neuübermittlungsanforderungen an die redundanten Kopien des Safety Nets (Shadow Safety Net) geleitet.
  • Es ist nicht möglich die maximale Größenbeschränkung des Safety Nets anzupassen. Es kann nur Einfluss auf den maximalen Aufbewahrungszeitraum genommen werden.
  • Die Replikation der Public Folder werden nun ebenfalls überwacht – bedingt durch die Integration der Public Folder in den Postfachdatenbanken.

Eine erneute Nachrichtenübermittlung aus dem Safety Net wird im Gegensatz zum Transportdumpster in Exchange 2010 nicht mehr eingeleitet weil keine Rückmeldung der Replizierung erfolgt, sondern vom der Active Manager Komponente des Exchange Replikationsdienstes, der DAGs und Postfachdatenbankkopien verwaltet.

Es gibt zwei Gründe, wieso eine Nachricht aus dem Safety Net erneut übermittelt werden muss:

  • Nach einem manuellen oder automatischen Failover deiner Postfachdatenbank in einer DAG
  • Nachdem eine lagged copy einer Postfachdatenbank aktiviert worden ist (ReplayLagTime in MailboxDatabaseCopy)

Bei erneuten Mailzustellungen durch Safety Net an Postfachservern außerhalb der Exchange Organisation, kann es zu doppelter Zustellung von Mails kommen. Besonders in großen Exchange Organisationen mit mehreren Postfachservern werden mehrere Safety Net Mail Kopien vorgehalten. Innerhalb der Organisation verhindern Exchange Mechanismen, dass Mails doppelt zugestellt werden.

Einige wichtige Parameter:

SafetyNetHoldTime für Set-TransportConfig
Standardwert: 2 Tage
Anzahl der Tage in der Nachrichten im Safety Net gespeichert werden

ShadowMessagePreferenceSetting für Set-TransportConfig
Standardwert: PreferRemote
Gibt den bevorzugten Speicherort zur Erstellung einer Schattenkopie an.

  • LocalOnly: Shadow-Kopie werden nur am lokalen AD-Standort erstellt
  • RemoteOnly: Shadow-Kopie werden nur an anderen AD-Standorten erstellt
  • PreferRemote: Versucht an einem anderen AD-Standort eine Shadow-Kopie zu erstellen. Schlägt des fehl, wird am lokalen Standort eine Shadow-Kopie erstellt.

MaxRetriesForRemoteSiteShadow für Set-TransportConfig
(Parameter wird genutzt wenn die DAG über mehrere Sites gespannt ist (stretched DAG))
Standardwert: 4
Gibt die maximale Anzahl der Versuche an, eine Shadow-Kopie in eine andere Site zu schreiben.

MaxRetriesForLocalSiteShadow für Set-TransportConfig
Standardwert: 2
Gibt die maximale Anzahl der Versuche an, eine Shadow-Kopie in der gleichen Site zu schreiben.

Beispiel: Der Parameter bei ShadowMessagePreferenceSetting steht auf  PreferRemote: Wie in MaxRetriesForRemoteSiteShadow definiert, wird vier Mal versucht werden eine Shadow-Kopie an einem anderen Site abzulegen. Sollte dies fehlschlagen, wird wie in  MaxRetriesForLocalSiteShadow definiert, zwei Mal versucht die Shadow-Kopie in der gleichen Sites abzulegen. Sollte auch dies fehlschlagen, greift die Einstellung im Parameter RejectMessageOnShadowFailure.

ShadowRedundancyEnabled für Set-TransportConfig
Standardwert: $true
Aktivieren und deaktivieren von Shadow Redundacy für die ganze Organisation

RejectMessageOnShadowFailure für Set-TransportConfig (hat nur einen Effekt wenn ShadowRedundancyEnabled auf true steht)
Standardwert: $false

  • $false   Wenn keine Shadow-Kopie der Nachricht erstellt werden kann, wird die primäre Nachricht trotzdem von den Transportservern in der Organisation akzeptiert. Diese Nachrichten werden nicht dauerhaft redundant beibehalten, während sie übermittelt werden.
  • $true   Nachrichten werden von keinem Transportserver in der Organisation akzeptiert oder bestätigt, bis eine Shadow-Kopie der Nachricht erstellt wurde. Wenn keine Shadow-Kopie der Nachricht erstellt werden kann, wird die primäre Nachricht mit einem vorübergehenden Fehler zurückgewiesen. Alle Nachrichten in der Organisation werden dauerhaft redundant beibehalten, während sie übermittelt werden.
    Sie sollten diesen Wert nur auf $true festlegen, wenn Sie über mehrere Exchange 2013-Postfachserver in einer DAG oder an einem Active Directory-Standort verfügen, in der bzw. an dem eine Shadow-Kopie der Nachricht erstellt werden kann.

ShadowHeartbeatFrequency für Set-TransportConfig
Standardwert: 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
Standardwert: 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.

ShadowMessageAutoDiscardIntervafür Set-TransportConfig
Standardwert: 2 Tage
Gibt an, wie lange ein Server Löschereignisse für erfolgreich übermittelte Nachrichten beibehält. 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 jedoch nicht während des in diesem Parameter festgelegten Zeitraums abfragt, löscht der primäre Server die Löschereignisse in der Warteschlange.

MessageExpirationTimeout für Set-TransportService
Standardwert: 2 Tage
Verweildauer einer Mail in einer Warteschlange bevor sie abläuft

Quellen:

http://technet.microsoft.com/de-de/library/dd351027(v=exchg.150)
http://technet.microsoft.com/de-de/library/bb124151(v=exchg.150)
Tagged with: , , ,
Veröffentlicht in Exchange

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

DeBugIT Autoren

Gib deine E-Mail-Adresse ein, um diesem Blog zu folgen und per E-Mail Benachrichtigungen über neue Beiträge zu erhalten.

Follow DeBugIT – IT Blog on WordPress.com
%d Bloggern gefällt das: