【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在高可用性和站点弹性方面有哪些重大改进或变化呢?
Exchange 2010中高可用性的变化
在Exchange 2010中，LCR、SCC、CCR以及SCR等概念不复存在。LCR和SCC功能已经从Exchange Server产品中删除。CCR与SCR合并，并已发展成为一个更加统一的高可用性架构，这其中，DAG(Database Availability Group，数据库可用性组)成为基本的组成部分。也就是说，不论是部署本地级还是站点级的高可用性和灾难可恢复解决方案，都要用到DAG。在Exchange 2010中，保护邮箱数据库的唯一方法也是使用DAG。
图1: DAG保护的邮箱数据库
DAG的主要组成部分是一种称为“主动管理器”(Active Manager)的新组件。Exchange 2007及早期版本中的Exchange群集资源DLL(exres.dll)和相关的群集服务资源，如今已被取代。现在，Exchange 2010使用主动管理器来管理DAG中邮箱服务器间的数据交换和故障切换。主动管理器运行在给定的DAG中的所有邮箱服务器上，它有两个角色：主主动管理器(Primary Active Manager，PAM)和备用主动管理器(Standby Active Manager，SAM)。
DAG具有以下几个特点：
·对Windows故障转移群集的有限依赖：DAG仅使用了Windows故障转移群集组件提供的有限的一部分群集功能。DAG使用群集数据库、群集心跳(Cluster heartbeat)及文件共享见证(File Share Witness，FSW)功能。在Exchange 2007及早期版本中，Exchange是一个由Windows故障转移群集操作的应用程序。而在Exchange 2010中，情况发生了变化，Windows故障转移群集注册时所创建的Exchange群集资源DLL及所有群集资源，已从Exchange 2010代码中移除。
图2: DAG 仍依赖于群集数据库及Windows 故障转移群集组件的复制功能
图3: Windows 故障转移群集中没有Exchange 群集资源
·增量部署：DAG仍使用Windows故障转移群集组件(如群集数据库、心跳和文件共享见证功能)，因此需要Windows Server 2008 SP2版或R2企业版环境，以便能够对DAG中的Exchange 2010邮箱服务器进行配置。但Exchange 2010支持增量部署方式，也就是说不需要在安装Exchange 2010之前形成群集。用户可以安装Exchange 2010邮箱服务器，然后创建一个DAG并在必要时将数据库和服务器添加到其中。
·与其他Exchange角色共存：使用CCR时，用户不能在邮箱服务器(群集节点)上安装受CCR保护的Exchange服务器。使用DAG时，DAG中的邮箱服务器还可以安装其他Exchange角色。这个特点对于小型组织非常有利。这是因为受DAG保护的邮箱服务器可以与其他Exchange角色并存。这也意味着用户可以使用两台机器作为专用Exchange服务器，以提供一个完全的冗余解决方案。当然，这需要配置文件共享见证，这一点在用户环境中很容易实现。文件共享见证不需要运行相同版本的Windows，只要运行Windows Server 2003或更高版本即可。另外一点需要注意的是：如果用户使用两台Exchange 2010服务器，并且希望得到一个完全的冗余解决方案，则必须使用基于负载均衡解决方案的外部硬件或软件，以便提供客户端访问服务。
·完全通过Exchange工具管理：在Exchange 2007中使用CCR时，必须使用Exchange和群集管理组合工具来配置和管理CCR群集。在Exchange 2010中使用DAG时，不必使用群集管理工具进行任何初始配置和管理，企业内部的Exchange管理员也不再需要有群集管理的经验。
图4: 通过Exchange 工具管理DAG、复制网络及FSW设置等
·数据库级的复制：为了支持DAG的新功能，Exchange 2010数据库已迁移到组织级，而不是Exchange 2007或早期版本的服务器级。Exchange 2010中不存在存储组的概念。现在，每个数据库都有一个日志流与数据库相关联。CCR的一个缺点是：如果主动节点的一个数据库出现故障，群集邮箱服务器上现有的所有活动数据库的故障都将转移到被动CCR节点。如果这个节点上的用户有邮箱存储于各自的群集邮箱服务器(Cluster Mailbox Server，CMS)，他们都将受到影响。
图5: 组织级数据库
·每个DAG支持多达16个成员：同Exchange 2007相比，Exchange 2010可以支持更多的邮箱数据库，用户最多可以添加16个邮箱服务器到一个DAG，并可能保存16个邮箱数据库副本。因此，Exchange 2010企业版支持的邮箱数据库最高限额已从50个上调至100个。但标准版目前仍然只支持每个邮箱服务器最多5个数据库。
·切换/故障转移较以前更为快速：有赖于Exchange 2010 DAG的改进，现在，邮箱数据库副本间的切换/故障转移更为快速。同Exchange 2007下采用CCR动辄就需要数分钟相比，目前所用时间往往在30称之内。此外，由于Outlook MAPI客户端连接客户端访问服务器的RPC客户端访问服务，因此最终用户很少会注意到切换或故障转移的发生。
·3个以上数据库副本时无需备份：当一个邮箱数据库拥有3个或更多副本时，程序设计为无需用户备份。也就是说当依次循环登录受DAG保护的邮箱数据库时，不再需要执行备份操作。
·支持位于不同活动目录站点的DAG成员：与CCR群集节点不同，DAG成员服务器可以位于不同的活动目录站点。但是应当注意，不能把受同一个DAG保护的邮箱服务器放置在活动目录森林的不同域内。
·通过TCP传送日志：在Exchange2007中，Microsoft Exchange复制服务通过服务器消息块将日志文件复制到被动数据库副本(LCR)、被动群集节点(CCR)或SCR目标，这就意味着用户需要打开CCR群集节点(通常是在部署多站点CCR群集时)与SCR源或SCR目标之间防火墙的445端口。利用Exchange 2010 DAG，异步复制技术不再依赖服务器管理块。Exchange 2010使用TCP / IP协议进行日志文件复制和播种(注：播种，即Seed。在 CCR 环境中安装被动节点时，每个存储组及其数据库都将从主动节点复制到被动节点，该操作称为“播种”)，甚至可以指定端口用于日志文件复制。默认情况下，DAG使用64327端口，当然，也可另外指定其他端口。
·日志文件压缩：利用Exchange 2010 DAG，在一个DAG内的一个或多个网络间播种或复制时可以启用压缩功能。这是DAG本身的特性，而不是DAG网络的特性。默认设置为“InterSubnetOnly”，进行网络加密属性设置时也使用相同的值。
·日志文件加密：Exchange 2010 DAG增加了对加密的支持，而在Exchange 2007中，除非已配置IPsec，否则日志文件将通过一个非加密通道复制。具体地说， DAG使用Windows Server 2008的加密功能，也就是说，DAG使用每个邮箱服务器成员之间的Kerberos身份验证。网络加密是对DAG本身而言的，而不是针对DAG网络。DAG网络加密属性选项有：禁用(不使用网络加密)，启用(网络加密用于DAG中所有网络的播种和复制)，InterSubnetOnly(默认设置，网络加密用于同一子网内的DAG网络)，以及SeedOnly(网络加密用于DAG中所有网络的播种)。
·副本最多允许滞后14天：Exchange 2007 SP1的备用连续复制引入了滞后数据库副本的概念。有了这项功能，用户可以指定在重播已复制到 SCR 目标计算机的日志文件之前，Microsoft Exchange 复制服务应等待的时间。用户还可以使用另一个参数“截断滞后时间” (Truncation Lag Time)，用于指定在截断已复制到 SCR 目标计算机并已重播到数据库副本的日志文件之前，Microsoft Exchange 复制服务应等待的时间。利用这两个选项，我们可以指定一个长达7天的时间差距。 而通过Exchange 2010 DAG，用户可以指定最多14天的截断滞后时间。
·从数据库副本播种：与Exchange 2007中的CCR不同，现在，用户可以通过指定一个数据库副本作为源数据库来执行播种。这就意味着，现有邮箱数据库的播种或重播操作不再对活动数据库副本产生影响。
图6: 从选定的资源服务器播种
·公用文件夹数据库不受DAG保护：与Exchange 2007的CCR不同，用户不能使用DAG保护公用文件夹数据库，而必须使用传统的公共文件夹的复制机制对其加以保护。但在这方面也做了一些改进：如果公用文件夹存储于DAG成员服务器上，Exchange 组织中只有一个公用文件夹存储的限制被取消。
·改进的传输转储程序：传输转储程序也有所改进，甚至受损数据库在位于不同活动目录站点的数据库副本间进行故障转移时，信息都可以重新递送。除此之外，当所有信息都被复制到数据库副本时，它们将从传输转储程序中被删除。
在本系列文章的第二部分，我们将在实验室环境部署DAG，并介绍DAG的各项具体设置。
