High availability for Microsoft Exchange Server 2007 using CCR with HP StorageWorks EVA8000 is a new white paper sponsored by HP.

About this White Paper
Cluster continuous replication (CCR) is a high-availability feature of Microsoft Exchange Server 2007 that combines the asynchronous log shipping and replay technology built into Exchange 2007 with the failover and management features provided by the Microsoft Windows Cluster service. This paper provides enterprise-level customers with the data required to effectively understand the options, as well as the limitations, of implementing this replication-based high-availability solution into their infrastructure. Includes lab data, performance information, and best practices based on HP Customer Focused Testing.

Key findings
Testing shows that the network link latency between the active and passive servers is the deciding factor in determining the suitability of an Exchange 2007 CCR deployment. Together with the available network bandwidth, this factor determines replication performance and, consequently, also the recovery database concurrency. A properly sized network will ensure the best possible performance. In a CCR environment, having low latency is more important than having adequate bandwidth. However, do not conclude that bandwidth is not important; an undersized network link can exacerbate performance degradation.
The CCR solution tested a 5,000-user load over an OC-3 link (155 Mbps). The key findings were:

• Best Exchange replication performance is achieved with network round-trip latencies of up to 30 ms.
• Network latencies higher than 50 ms cause the number of unshipped transaction logs to grow, which negatively affects recovery time and possibly affects the recovery point objective.
• Log replay is a significant generator of both read and write disk I/Os on the passive node storage subsystem. Testing shows three to five times the disk I/O as the active LUNs.
• Effects of latency can be partially mitigated, and replication performance can be significantly improved, by tuning the Windows Server TCP/IP settings.
• Failover and recovery to the passive node can be achieved within a 1-hour recovery time objective (RTO).