- Get link
- X
- Other Apps
Transport Dumpsters and its evolution in Exchange Server
To better understanding for myself and to compare it with the different version of an exchange I have put them all together.Exchange 2007
Transport Dumpster feature was introduced on the Hub Transport role in Exchange 2007It was only enabled for continuous cluster replication (CCR) and local continuous replication (LCR).
Messages were retained in the transport dumpster until the administrator-defined time limit or size limit is reached
Get-TransportConfig |fl *Dumpster*
MaxDumpsterSizePerStorageGroup (E2K7) 18 Days Default
MaxDumpsterTime 7 Days
The transport dumpsters now receive feedback from the replication pipeline to determine which messages have been delivered and replicated. As a message goes through Hub Transport servers on its way to a replicated mailbox database in a DAG, a copy is kept in the transport queue (mail.que) until the replication pipeline has notified the Hub Transport server that the transaction logs representing the message have been successfully replicated to and inspected by all copies of the mailbox database. After the logs have been replicated to and inspected by all database copies, they are truncated from the transport dumpster. This keeps the transport dumpster queues smaller by maintaining only copies of messages whose transactions logs haven't yet been replicated.
In the event of a lossy failover (where the server or database goes offline due to some reason), the “MSExchangeRepl” (MSExchange replication service) will set the “DumpsterRedeliveryRequired” Attribute to True for the database which just became Active after the failover. This is done with the help of the “LastLogInspected” marker which is set on every database. Hub servers will then redeliver the missing messages from the mail.que file depending upon the MaxDumpsterSizePerDatabase or MaxDumpsterTime whichever is latest.
Presently active settings can be viewed using the following command
Get-TransportConfig |fl *Dumpster*
Exchange 2013
The transport dumpster has been revamped in Exchange 2013 and is now known as the Safety Net.
MaxDumpsterSizePerStorageGroup (E2K7) 18 Days Default
MaxDumpsterTime 7 Days
Exchange 2010
It now works with Database availability groups (DAGs), When a message is sent from the hub transport server to a DAG, the message is stored in the transport dumpster so in case of failure, messages can still be sent to usersThe transport dumpsters now receive feedback from the replication pipeline to determine which messages have been delivered and replicated. As a message goes through Hub Transport servers on its way to a replicated mailbox database in a DAG, a copy is kept in the transport queue (mail.que) until the replication pipeline has notified the Hub Transport server that the transaction logs representing the message have been successfully replicated to and inspected by all copies of the mailbox database. After the logs have been replicated to and inspected by all database copies, they are truncated from the transport dumpster. This keeps the transport dumpster queues smaller by maintaining only copies of messages whose transactions logs haven't yet been replicated.
In the event of a lossy failover (where the server or database goes offline due to some reason), the “MSExchangeRepl” (MSExchange replication service) will set the “DumpsterRedeliveryRequired” Attribute to True for the database which just became Active after the failover. This is done with the help of the “LastLogInspected” marker which is set on every database. Hub servers will then redeliver the missing messages from the mail.que file depending upon the MaxDumpsterSizePerDatabase or MaxDumpsterTime whichever is latest.
Presently active settings can be viewed using the following command
Get-TransportConfig |fl *Dumpster*
Exchange 2013
The transport dumpster has been revamped in Exchange 2013 and is now known as the Safety Net.
Similarities between Safety Net and Transport Dumpster
- Safety Net is a queue that's associated with the Transport service on a Mailbox server. This queue stores copies of messages that were successfully processed by the server.
- You can specify how long Safety Net stores copies of the successfully processed messages before they expire and are automatically deleted. The default is 2 days
- Safety Net doesn't require DAGs. For Mailbox servers that don't belong to a DAGs, Safety Net stores copies of the delivered messages on other Mailbox servers in the local Active Directory site.
- Safety Net itself is now redundant and is no longer a single point of failure. This introduces the concept of the Primary Safety Net and the Shadow Safety Net. If the Primary Safety Net is unavailable for more than 12 hours, resubmit requests become shadow resubmit requests, and messages are re-delivered from the Shadow Safety Net.
- Safety Net takes over some responsibility from shadow redundancy in DAG environments. Shadow redundancy doesn't need to keep another copy of the delivered message in a shadow queue while it waits for the delivered message to replicate to the passive copies of mailbox database on the other Mailbox servers in the DAG. The copy of the delivered message is already stored in Safety Net so the message can be resubmitted from Safety Net if necessary.
- In Exchange 2013, transport high availability is more than just the best effort for message redundancy. Exchange 2013 attempts to guarantee message redundancy.
- You can't specify a maximum size limit for Safety Net. You can only specify how long Safety Net stores messages before they're automatically deleted.
- Get link
- X
- Other Apps
Comments
Post a Comment