Yesterday, I stumbled upon a tweet from Johan Veldhuis pointing to the following KB-article: http://support.microsoft.com/kb/895847/
The article provides more information on the supported configurations for multi-site data replication for Exchange Server. Even though Exchange Server 2010 has its own built-in replication mechanism (DAG) to ensure data consistency and high availability. Because it’s not always clear what type of configurations are and are not supported, I’ll try to capture the essence of the KB-article below.
There are two “types” of replication:
You can also have host-based replication. This is where the replications relies on a piece of software instead of hardware. Although I’m sure there is some pretty nifty software out there, I have yet to see this implemented on an Exchange Server (especially Exchange Server 2010). With the latter, I would rather use the built-in capabilities of the DAG which is – in fact – also a host-based (software) replication mechanism.
The support that Microsoft offers is – based on the two types of replication I mentioned earlier – divided into two categories:
Geographically dispersed solutions
Non-Geographically dispersed solutions
Note a geographically dispersed solution is one where the remote end (storage) is not within the same geographical location of the local (storage) end: e.g. a remote geographical site. In such deployments, synchronization usually happens over WAN links.
Asynchronous replication (storage- or host-based)
Microsoft does not support asynchronous replication for Exchange Servers. This is solely supported by the storage vendor. Additionally, Microsoft makes the following statements about the level of support if you are running such a configuration:
They will only troubleshoot Exchange-specific issues up to the point where the sources of the problem can be attributed to the replication mechanism
You do not have to remove the asynchronous replication feature in order to be eligible for support. However; it might become a requirement if troubleshooting demands (especially if the problem cannot be solved by either your storage vendor or Microsoft, you might have to revert to a fully supported configuration)
Synchronous replications (Geographical Dispersed storage-based, host-based)
Microsoft fully supports a synchronous geographical configuration, for as long as the hardware that is used in the configuration is certified and is fully supported by your (storage) vendor. To verify whether your storage solutions is on the WHQL list, do the following:
Visit the following Microsoft Web site:
Click Cluster Solutions.
In the left panel, click Geographically Dispersed Cluster Solution under Product category.
If your solutions is not WHQL qualified, Microsoft will revert to the same support policy as for asynchronous replication.
Synchronous Replications (Non-Geographical Dispersed storage-based, host-based)
The same support policy applies as for geographical dispersed solutions: fully supported, for as long as the hardware that is used in the configuration is certified and is fully supported by your (storage) vendor.
For more information on the support policy, I invite you to take a look at the KB-article here.
In my opinion (and when we’re talking about Exchange Server 2010), you should stick with the built-in capabilities of a DAG. DAGs have proven their value and offer some distinct benefits over 3rd-party replication mechanisms. On the other hand, if you rely heavily on an underlying form of replication (e.g. storage-based replication in a virtual environment), you should – at all times – stick with a certified hardware solution, replicating synchronously.
Also, don’t forget to take a look at the Disk Timeout Values for your Exchange Servers. Relying on a 3rd party replication mechanism might require you to change some of the recommended values. More information can be found here:
Michael Van Horenbeeck