The evolution of Exchange has brought with it numerous changes, improvements and features throughout the years. One thing that has always remained a challenge is high availability and site resiliency. In the most recent versions of Exchange a great deal more attention has be afforded these topics and the results have certainly been welcome. In Exchange 2010 Microsoft has delivered a nearly autonomous solution for ensuring the availability and performance of your Exchange servers.
In Exchange 2007 high availability came in the form of newly developed features LCR, CCR and SCR. While these improvements certainly improved the availability of mailbox databases, implementation was complicated and expensive, requiring at least four servers for high availability. Exchange needed an evolution in efficiency and simplicity.
There are number of improvements in Exchange 2010 and high availability takes center stage. Microsoft has addressed this in the three main areas of service, mailbox, transport and access. Let’s start by taking a look at the mailbox and database high availability improvements.
As discussed in my previous article Exchange 2010 employs Database Availability Groups as the primary mechanism for Mailbox high availability. There are a number of advantages to this architecture,
- Automatic failover and recovery at the database level (as opposed to the server level)
- Freedom from clustering hardware and additional cluster configuration
- Cluster resources are now managed directly from the Exchange Management Console
- Replication occurs at the database level and uses a push rather than a pull method for logs files
- DAGs can be extended cross site allowing a single database to move between sites
- Active and passive copies can be specified as a seeding source.
Additionally Microsoft made improvements to message transport. Exchange 2007 introduced the notion of a transport dumpster which ensured that the transport servers maintained a copy of messages delivered to a LCR or CCR destinations. This feature allowed for messages to be available to the new target mailbox server in the event of a failover. What it didn’t address however is messages lost in transit between Hub and Edge servers. In Exchange 2010 Microsoft addressed transport by both making it more efficient as well as making it truly highly available.
- Shadow redundancy- Ensures messages are delivered to each next hop reaching their destinations before they are deleted.
- Incremental EdgeSync- Reducing network traffic and increasing efficiency Incremental EdgeSync only synchronize the changes since the last replication cycle.
- Message throttling improvements-Allows the configuration of a receive connector for monitoring message submissions ensuring that users don’t exceed the message rate allowed.
- Latency management- ability to measure latencies for each hop, as well as end-to-end latency.
Finally Exchange 2010 brings changes to client access that allows users to connect to their mailbox database regardless of its server location. This change is a feature known as the RPC Client Access Service. In Exchange 2007 MAPI was the only service left out of client access connectivity. In Exchange 2010 this would pose a problem as user mailboxes don’t have a fixed mailbox server location. As a result Microsoft introduces the RPC Client access Service. This introduction of this service means that now all client connections are made through servers with the client access role installed allowing for near seamless database failover. The MAPI client connects to the NSPI endpoint on the Client Access Server which then communicates with Active Directory via the AD Driver. This functionality coupled with a Client Access Server array will help ensure the performance and availability of your Exchange environment.
In Exchange 2010 Microsoft has made great improvements in high availability. Hopefully I’ve provided a good introduction to these features. If you’d like further information please check the links below, they cover the topics further in depth.