This blog has been moved to www.roundtheclockit.com on wordpress platform. Its been a while since I hv posted on this as I have been very busy with few of the stuff. In the future posts, you will see more stuff on windows, citrix and virtualization apart from the messaging posts also and we promise to be regular :-).
Please visit www.roundtheclockit.com.
Monday, August 9, 2010
Saturday, March 20, 2010
Message Redundancy - Hub Transport Servers | Shadow Redundancy vs Transport Dumpster
As we discussed in the last article, High Availability is becoming very critical for every organization, message loss is one very critical and important aspect that we cannot ignore. By message loss, we mean here the message loss that can incur at the time of failure of one or more servers.
With introduction of Microsoft Exchange Server 2007 role based model, Hub Transport Server role provided the centralized transport pipeline through which all messages had to pass, thus making it possible and very efficient to set transport rules and policies.
For standalone non clustered mailbox servers, there is no built in protection as the message loss can occur if a server fails. Here on the Hub Transport Server, the message is stored in the transport database and is deleted as soon as it is sent to the next hop.
However, the feature called Transport Dumpster was introduced in Exchange Server 2007 that protect against message loss for the mailboxes that reside on a CCR cluster. Transport Dumpster holds the messages that are sent to the recipients whose mailbox resides on a clustered mailbox server, and recent sent items are retransmitted back in the event of failure of one cluster node so that messages are not lost during failover.
In Exchange 2010, there's a new feauture Shadow Redundancy that provides redundancy for messages for the entire time they are in transit. With Shadow Redundancy in exchange 2010, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If a successful delivery is not reported, the hub server will try to resend the message.
Shadow redundancy uses the SMTP service extensions that allows the SMTP hosts to negotiate Shadow Redundancy support in Exchange 2010.
So the key points here are:
With introduction of Microsoft Exchange Server 2007 role based model, Hub Transport Server role provided the centralized transport pipeline through which all messages had to pass, thus making it possible and very efficient to set transport rules and policies.
For standalone non clustered mailbox servers, there is no built in protection as the message loss can occur if a server fails. Here on the Hub Transport Server, the message is stored in the transport database and is deleted as soon as it is sent to the next hop.
However, the feature called Transport Dumpster was introduced in Exchange Server 2007 that protect against message loss for the mailboxes that reside on a CCR cluster. Transport Dumpster holds the messages that are sent to the recipients whose mailbox resides on a clustered mailbox server, and recent sent items are retransmitted back in the event of failure of one cluster node so that messages are not lost during failover.
In Exchange 2010, there's a new feauture Shadow Redundancy that provides redundancy for messages for the entire time they are in transit. With Shadow Redundancy in exchange 2010, the deletion of a message from the transport databases is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If a successful delivery is not reported, the hub server will try to resend the message.
Shadow redundancy uses the SMTP service extensions that allows the SMTP hosts to negotiate Shadow Redundancy support in Exchange 2010.
So the key points here are:
- Transport Dumpster in Exchange 2007 only safeguards messages for the mailboxes that reside on CCR node, however Shadow Redundance is inbuilt in Exchange 2010 that can be enabled or disabled for the entire organization.
- Shadow Redundancy makes hub transport servers more resilient against message loss. Exchange Server 2007 deletes messages from the database as soon as they were sent to the next hop, however, Shadow Redundancy keeps messages in the database until Exchange confirms that they were been delivered.
- Earlier versions of Exchange were not designed to verify message delivery, however Microsoft has extended SMTP service in Exchange 2010 that allows this now.
Understand more indepth about Shadow Redundancy. Also, here's an excellent technet that explains detailed Shadow Redundancy Mail Flow Scenarios. This topic explains in detail what happens for each specific message flow scenario that can involve Exchange.
Monday, February 1, 2010
High Availability | From Exchange 2007 to Exchange 2010
High Availability is one of the most important factors considered today in almost all the messaging deployments as email is becoming the mission critcal applcation and the backbone for all the businesses.
Exchange has come a long way from its earlier versions - Exchange 2003 that uses typical Windows Clustering technologies based on a shared storage model, and then to Exchange 2007 that brought new dimensions with the introduction of log replication technology in LCR, CCR and SCR. With this new technology of continuos replication where the transaction logs are shipped from one copy of a database to another, the exchange 2007 deployment offers high availability in
various scenarios like Local Continuous Replication (LCR) on a single server deployment, Cluster Continuous Replication (CCR) available accross different servers and Standy Continuous Replication (SCR) spread across different sites.
Exchange 2010, introduces the concept of Database Availability Groups (DAG) that takes the high availability to the next level for mailbox servers. A DAG is as the name suggests a group or a collection of mailbox servers (upto a maximum of 16) that uses the continuous replication technology that was first introduced in Exchange 2007 and are effectively a combination of Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR). It also makes use of
some of the components of Windows Failover Clustering to achieve high availbility and these cluster elements are installed automatically when a mailbox server is added to a DAG and managed completely by Exchange.
To achieve full high availibility solution for all the roles, with the introduction of Exchange Server 2007 SP1, it can be achieved by deplyoing a total of minimum of 4 servers - two servers installed as a single CCR environment, giving high availability for the users’ mailboxes and the other two servers deployed as combined Hub Transport and Client Access Servers, and configured as a load-balanced pair.
But with Exchange 2010, a full high availability solution can now be deployed by using a minimum of 2 servers as it’s now possible to combine the mailbox server role with other roles such as the Hub Transport and Client Access Server role. And with futher IO reductions in Exchange 2010 and RAID-less/JBOD support, it support much larger mailboxes with reduced storage costs.
Exchange has come a long way from its earlier versions - Exchange 2003 that uses typical Windows Clustering technologies based on a shared storage model, and then to Exchange 2007 that brought new dimensions with the introduction of log replication technology in LCR, CCR and SCR. With this new technology of continuos replication where the transaction logs are shipped from one copy of a database to another, the exchange 2007 deployment offers high availability in
various scenarios like Local Continuous Replication (LCR) on a single server deployment, Cluster Continuous Replication (CCR) available accross different servers and Standy Continuous Replication (SCR) spread across different sites.
Exchange 2010, introduces the concept of Database Availability Groups (DAG) that takes the high availability to the next level for mailbox servers. A DAG is as the name suggests a group or a collection of mailbox servers (upto a maximum of 16) that uses the continuous replication technology that was first introduced in Exchange 2007 and are effectively a combination of Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR). It also makes use of
some of the components of Windows Failover Clustering to achieve high availbility and these cluster elements are installed automatically when a mailbox server is added to a DAG and managed completely by Exchange.
To achieve full high availibility solution for all the roles, with the introduction of Exchange Server 2007 SP1, it can be achieved by deplyoing a total of minimum of 4 servers - two servers installed as a single CCR environment, giving high availability for the users’ mailboxes and the other two servers deployed as combined Hub Transport and Client Access Servers, and configured as a load-balanced pair.
But with Exchange 2010, a full high availability solution can now be deployed by using a minimum of 2 servers as it’s now possible to combine the mailbox server role with other roles such as the Hub Transport and Client Access Server role. And with futher IO reductions in Exchange 2010 and RAID-less/JBOD support, it support much larger mailboxes with reduced storage costs.
To summarize Exchange 2010 high availibilty improvements:
- Combines the capabilities of CCR and SCR into one platform.
- Easier than traditional clustering to deploy and manage.
- Allows each database to have up to 16 replicated copies.
- Provides full redundancy of Exchange roles on two servers.
- Further IO reductions.
- RAID-less / JBOD support.
Subscribe to:
Posts (Atom)
