Today, the Exchange team released details of Exchange 14, now to be known as Exchange Server 2010. [download here]. There’s plenty of new stuff in the box, but I’m just going to look at one: high availability & data replication.
[My previous missives on Exchange 2007 HA are here, here and here]
There are some interesting differences between 2007 and 2010, particularly in the way databases are handled and what that means for clustering.
THERE IS NO SINGLE COPY CLUSTER ANY MORE.
Single Copy Clusters, or the traditional way of deploying Exchange onto a Windows Cluster with several nodes sharing a copy of the data held in a central SAN, have quite a few downsides … like there being that Single Copy, or the fact that the storage hardware is typically complex and expensive.
There are other pretty major changes, like storage groups going away (it’s just a database now, a move that Exchange 2007 previewed by the advice that you should only have a single DB per SG), or the fact that databases are now the unit of failover (rather than the whole server…), or the ability now to install multiple roles on servers providing high availability – so you could deploy highly available, clustered/replicated environment to a small number of users, without having lots of boxes or VMs.
Oh, Local Continuous Replication goes away too…
Well, reading the documentation explains a bit more about how Exchange 2010 will change the way that high availability can be achieved – no more the need for a MSCS cluster to be set up first should make it simpler, for one. From that site:
Changes to High Availability from Previous Versions of Exchange
Exchange 2010 includes many changes to its core architecture. Two prominent features from Exchange 2007, namely CCR and SCR, have been combined and evolved into a single framework called a database availability group (DAG). The DAG handles both on-site data replication and off-site data replication, and forms a platform that makes operating a highly available Exchange environment easier than ever before. Other new high availability concepts are introduced in Exchange 2010, such as database mobility, and incremental deployment. The concepts of a backup-less and RAID-less organization are also being introduced in Exchange 2010.
In a nutshell, the key aspects to data and service availability for the Mailbox server role and mailbox databases are:
- Exchange 2010 uses an enhanced version of the same continuous replication technology introduced in Exchange 2007. See the section below entitled “Changes to Continuous Replication from Exchange Server 2007” for more information.
- Storage groups no longer exist in Exchange 2010. Instead, there are simply mailbox databases and mailbox database copies, and public folder databases. The primary management interfaces for Exchange databases has moved within the Exchange Management Console from the Mailbox node under Server Configuration to the Mailbox node under Organization Configuration.
- Some Windows Failover Clustering technology is used by Exchange 2010, but it is now completely managed under-the-hood by Exchange. Administrators do not need to install, build or configure any aspects of failover clustering when deploying highly available Mailbox servers.
- Each Mailbox server can host as many as 100 databases. In this Beta release of Exchange 2010, each Mailbox server can host a maximum of 50 databases. The total number of databases equals the combined number of active and passive databases on a server.
- Each mailbox database can have as many as 16 copies.
- In addition to the transport dumpster feature, a new Hub Transport server feature named shadow redundancy has been added. Shadow redundancy provides redundancy for messages for the entire time they are in transit. The solution involves a technique similar to the transport dumpster. With shadow redundancy, the deletion of a message from the transport database is delayed until the transport server verifies that all of the next hops for that message have completed delivery. If any of the next hops fail before reporting back successful delivery, the message is resubmitted for delivery to that next hop. For more information about shadow redundancy, see Understanding Shadow Redundancy.
