【IT168专稿】回顾一下Exchange的发展历史，不难发现，在之前的Exchange 2007中，Exchange Server产品的高可用性和灾难恢复功能相当有限。Exchange 2003和更早的版本能够利用微软群集服务(Microsoft Cluster Services，MSCS)的优势，但由于各个节点共享同一个存储子系统，因此只能提供硬件级的冗余。如果活动群集节点突然变得不可用，Exchange虚拟服务器(Exchange Virtual Server，EVS)及其他有关群集资源只要将故障转移到被动节点，最终用户便可以继续工作。

　　有时，用户不希望存储子系统失败而成为一个单点故障。为了实现存储级冗余，用户被迫向第三方软件供应商或存储硬件供应商投资，以获得复制解决方案。由于第三方解决方案得不到微软支持，且实施起来非常昂贵，因此Exchange 产品开发团队希望在Exchange Server产品中提供更好的高可用性和灾难恢复功能。

　　Exchange 2007为用户提供了一整套高可用性和灾难恢复功能，如针对小型组织的LCR(Local Continuous Replication ，本地连续复制)，以及面向中型和大型组织的CCR(Cluster Continuous Replication ，群集连续复制)。后来，在Exchange 2007 SP1基础上，又推出适用任何规模组织的SCR(Standby Continuous Replication ，备用连续复制)。上述这三个功能均采用了一种新的异步复制技术，该技术将日志文件输送到一个被动存储组副本中，待检查过后重新置入被动副本。

　　尽管LCR提供了存储级冗余，但这一功能并未真正得到重视。根本原因在于存储组副本必须在邮箱服务器的本地卷保存，这一点成为一个硬件级的单点故障。自Exchange 2007发布后，CCR取得了巨大成功。它将Exchange 2007新引入的异步复制技术同Windows故障转移群集技术相结合，既在硬件级又在存储级实现了冗余，从而为用户提供了一个没有单点故障的、真正的高可用性解决方案。

　　CCR群集节点可以设在单独的数据中心，以提供场地级冗余，但多站点CCR群集解决方案涉及太多复杂的细节，不符合网站的弹性发展考虑。这就使得Exchange 产品开发团队不得不考虑在Exchange 2007中提供一个内置功能，以实现站点的弹性目标。

　　Exchange 2007 SP1发布之后，SCR使用户能够将日志文件传送到另一台Exchange 2007邮箱服务器。由于SCR不需要Windows故障转移群集，所以日志文件既可以从群集邮箱服务器也可以从非群集邮箱服务器(源SCR)传输到群集和非群集邮箱服务器(目标SCR)。用户可以为日志指定一个长达7天的滞后时间，这使得它在到达位于另一个数据中心的目标SCR之前，可以修复大多数的数据库或存储问题。

　　注：Exchange 2007 SP2是一个为Exchange 2007组织部署Exchange 2010而准备的服务包，所以在高可用性或网站的弹性功能方面没有什么改进。

　　既然用户已经掌握了CCR和SCR，那么 Exchange 2010在高可用性和站点弹性方面有哪些重大改进或变化呢?