Most of us are interested in finding new ways to make our Exchange servers more mission-critical. One technique that has started to surface more and more in Exchange Server deployments is data replication. Let's look at how this technology provides additional availability to Exchange.
It's important that I make one statement up front: As with data replication's storage technology relatives—Business Continuance Volumes (BCVs) and Network Attached Storage (NAS)—Microsoft does NOT directly support data replication for Exchange. That being said, you can leverage this technology, provided your data replication vendor supports it for Exchange servers.
Two types of data replication products are currently on the market: software-based and hardware-based. Software-based data replication products use a filter driver layered on top of the OS to mirror I/O operations at the OS I/O subsystem layer. Software-based solutions available include NSI's DoubleTake and Veritas' Vinca.
Hardware-based solutions are essentially the same except that I/Os are mirrored at the controller level (in hardware) and are independent of the OS. Products include EMC's Synchronous Remote Data Facility (SRDF), Compaq's Data Replication Manager (DRM), and Marathon's Endurance. In truth, all of the hardware solutions are partially software-based, as they typically have controller firmware support and require device drivers and services running on the system to function.
You can use data replication for your Exchange servers by mirroring to a remote copy set I/O that occurs to Exchange databases and transaction logs. The remote copy set is an exact copy of the production data. If an Exchange database is lost or corrupted, you can remap these copy sets to the production data set and restart the server (Exchange 5.5) or mount the database (Exchange 2000). In addition, you can combine data replication technology with technologies such as clustering to further enhance availability. In the case of clustering, because you can store remote copy sets nearby or many kilometers away (via storage area network—SAN, LAN, or WAN), you can stretch the cluster across the distance. Even without clustering, you can locate remote copy sets at hot standby sites that provide catastrophe protection for Exchange data.
The challenge with data replication for Exchange comes in the area of transactional integrity. The main reason that Microsoft can't support this technology is that the mirroring operations that occur at the I/O level have no relation to actual database transactions. Also, because remote I/Os may or may not be committed synchronously (depending on the vendor and configuration) or in the same order as they occur at the transaction level, this technology is difficult to embrace from a supportability point of view. Recovery to remote copy sets is also not trivial or automatic. You must map the remote copy set as the production disk unit, and you must check database integrity to properly mount databases. Although you can script and automate this process, it must be done with care and is open to operator error.
I don't want to sell you on data replication for your Exchange deployments, but I do think it's worth a look. Recently, I've talked to more and more organizations that are considering this as a potential solution for more availability for Exchange and other applications. If you choose to look at this technology for your own deployment, factor in the points above, test it, and ensure your vendor of choice can carry the support burden when Microsoft won't.