Hub Transport and Mailbox Server Roles Coexistence When Using DAGs
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Microsoft Exchange Server 2007 doesn't support Hub Transport and Mailbox server roles on the same server hardware when high availability features such as single copy cluster (SCC) or cluster continuous replication (CCR) are used. A minimum high availability deployment in Exchange 2007 requires four servers: two nodes for mailbox high availability and two Hub Transport servers for message transfer redundancy.
To reduce the number of servers required to provide a high availability solution, Exchange Server 2010 supports Hub Transport and Mailbox server roles on the same server hardware when using database availability groups (DAGs). Exchange 2010 provides a feature called shadow redundancy, which protects against data loss while messages are in transit. When used together, DAGs and shadow redundancy offer a highly resilient messaging infrastructure.
This topic focuses on how the Exchange 2010 Hub Transport server role behaves when deployed on the same server hardware as a Mailbox server that participates in a DAG. To learn more about DAGs, see Understanding Database Availability Groups.
Message Submission and Delivery
Shadow redundancy prevents data loss while messages are in transit by keeping a duplicate copy of the message along the message path. If a message is lost in transit due to a failure, the shadow copy of the message is resubmitted by the Transport component. For detailed information about how shadow redundancy is implemented, see Understanding Shadow Redundancy.
Mailbox servers are involved during initial message submission, when a user clicks Send, and during final delivery, when the message is saved to the Inbox of the recipient. When a message is submitted to Transport, the primary copy of that message is in the queues of the Hub Transport server to which the message was submitted. The shadow copy of that message is the item stored in the Sent Items folder of the sender. When a message is delivered, the primary copy is in the recipient's Inbox and the shadow copy of the message is stored in the transport dumpster.
In a high availability scenario where Hub Transport and Mailbox server roles coexist on the same server hardware, it's crucial to try to avoid having both copies of a message reside on the same server. Consider the deployment scenario shown in the following figure. The topology consists of two Exchange servers participating in a DAG with the Hub Transport server role installed. The databases DB1 and DB2 are part of the DAG. Active databases are shown in green, and passive databases are shown in blue.
Two server high availability topology with Hub Transport and Mailbox server roles
In this topology, assume that a user whose mailbox is on DB1 sends a message. If that message is submitted to the Hub Transport server role on Server1, both the primary and shadow messages will be physically stored on Server1. The primary messages will be in the Hub Transport server queues, and the shadow messages will be in the Sent Items folder of the sender, as shown in the following figure.
Undesirable submission path
Similarly, if the Hub Transport server role on Server1 receives a message destined to a user on DB1, the message is delivered directly, and both the primary and shadow messages will be physically stored on Server1. The primary messages will be in the Inbox of the recipient, and the shadow messages will be in the transport dumpster, as shown in the following figure. If a server failure occurs at either of those instances, there's a chance that the message can be lost.
Undesirable delivery path
To avoid these scenarios where message loss can occur, Exchange attempts to submit or deliver messages over a route that ensures that the primary and shadow copies of messages are stored on different physical servers. The modified message submission and delivery behaviors are discussed in the following section.
Message Submission Behavior
When a user whose mailbox is in a database that's a member of a DAG sends a message, the mail submission service gives preference to remote Hub Transport servers if it detects that the Hub Transport server is also installed on the local server. As shown in the figure "Two server high availability topology with Hub Transport and Mailbox server roles", if a user whose mailbox is on DB1 sends a message, the mail submission service will attempt to use the Hub Transport server installed on Server2 for message submission. The following figure shows this preferred message submission path.
Preferred submission path
In the case where no other Hub Transport servers are available in the site (for example, if Server2 is unavailable due to scheduled maintenance), the message submission service will fall back to submitting the message to the local Hub Transport server. Even though this is an undesirable submission path for redundancy, Exchange won't delay delivery of messages. This fallback submission path is desirable for availability and low delivery latency.
Message Delivery Behavior
The message routing and delivery behavior doesn’t change in most cases. For example, if Server1 shown in the figure "Two server high availability topology with Hub Transport and Mailbox server roles" receives a message for a recipient on DB2, it will deliver the message normally because that database is active on a different server. The only scenario when a Hub Transport server will process an incoming message differently is when the target mailbox is on a database that's part of a DAG and is also active on the local server. Because a direct delivery in this situation would result in both the delivered message and the copy in the transport dumpster being on the same server, the Hub Transport server will instead reroute this message to another Hub Transport server within the same site. The following figure shows the message delivery path in this scenario.
Preferred delivery path
In the case where no other Hub Transport servers are available in the site, the Hub Transport server will fall back to local delivery even though it's an undesirable delivery path for redundancy. Again, this fallback delivery path is desirable for availability and low delivery latency.
Message Flow Scenarios
This section explains in detail what happens in various message flow scenarios when Hub Transport and Mailbox server roles coexist on the same server. The topology shown in the following figure is used to illustrate various possible message flow scenarios.
Sample topology for message flow scenarios
The following table shows how the Hub Transport server role on Server1 processes messages in various scenarios. In all of these cases, Server1 is considered the entry point.
Sender location | Recipient location | Normal message path | High availability scenarios |
---|---|---|---|
DB1, active on Server1 |
DB1, active on Server1 |
|
|
DB1, active on Server1 |
DB2, active on Server2 |
|
|
External |
DB1, active on Server1 |
|
|
External |
DB2, active on Server2 |
|
|
The preceding table focuses on the minimum scenario where there are only two Hub Transport servers in a site that both coexist with Mailbox server roles that participate in DAGs. In more complex deployments where additional dedicated Hub Transport servers are available, those servers are also used when making routing decisions. However, if you have a large enough deployment where you can employ dedicated Hub Transport servers, it's a best practice to not install the Hub Transport server role on Mailbox servers that participate in a DAG.
© 2010 Microsoft Corporation. All rights reserved.