在Exchange Server 2010中，微软引入了数据库可用性组（DAG）的概念。这一概念使得邮箱数据库从一台突发故障的邮件服务器转移到另一台正常的服务器成为可能。事实上，DAG确实给一些只有单个数据中心的企业带来了很好的灾备解决方案。虽然说DAG也可以跨多个数据中心进行部署，但是实战中跨站点级别的故障转移还是相当复杂的。微软在Exchange2013中对DAG做了一些功能性的提升。其中一些功能就针对跨站点的故障转移。

这些功能包括：

站点弹性（Site Resilience）

尽管这也是从Exchange Server 2010的DAG所具有的功能，但是此前版本的DAG的一些特性阻碍了组织真正实现站点级别的故障转移。对于初学者而言，站点级别的弹性设置必须在Exchange2010上线之前配置好。原因之一就是所有的DAG成员必须属于同一个活动目录域。这意味着只有当这个活动目录域跨越多个数据中心时，站点弹性功能才能实现。

另一个重要的限制是微软在设计Exchange Server 2010时，考虑到WAN是不可靠的，所以站点的故障转移不会因为一次简单的广域网故障而触发。而一旦有这种情况发生，跨站点的故障转移必须手动触发。而且，主数据中心必须拥有足够多的DAG成员，这样当WAN连接故障时，主站点才能获得仲裁优势。由于上述的这些限制，在Exchange2010中实际并不存在所谓的站点弹性。

在Exchange Server 2013中，如果前期准备够充分，就可以实现完全的站点弹性功能。一如Exchange2010所定义的，一个DAG只有通过仲裁才能被启用。维护仲裁意味着要保证超过半数的DAG成员在线并能与其他在线DAG节点保持通信。这可以通过在每个数据中心部署等量的DAG成员然后在非数据中心点部署一台见证服务器实现。

这个模型在有重大故障或者WAN链路损毁时可以实现数据中心级别的转移。然而这个站点弹性模型仍然不是对邮箱数据库完整性保护的最佳实践，因为主数据中心的DAG可能会丢失仲裁。在WAN连接失效的情况下，哪个数据中心可以连接到见证服务器，将获得仲裁从而被选为主数据中心。而此时，设想主数据中心的一个DAG成员在WAN连接修复之前又发生故障，那将导致数据中心再次丢失仲裁，进而导致DAG故障。

滞后副本（Lagged Copies）

Exchange2013的DAG的另一个重大变化是就是滞后副本。滞后副本是指推迟事务日志的重播以加快数据库副本的恢复时间。

在Exchange 2013中，微软改进了滞后副本的代码使其可以检测并修正数据库以及磁盘空间不足等故障。一旦上述情况发生，滞后效应可能就不复存在。

Exchange 2010中的滞后副本存在的一个重大问题就是在整个滞后的周期中，事务必须完整的被保留下来，这将导致磁盘空间的激增。在实际运用中，许多组织低估了滞后副本发送前，事务日志的容量而使得邮箱服务器磁盘运行空间不足。

Exchange2013会实时监控可用磁盘空间。当事务日志所在的卷空间不足时，Exchange会调用自动播放，即将事务日志提交给滞后副本这样事务日志卷的空间就能释放出来。

Exchange在发现一个损坏的数据库页时也会使用相似的日志文件自动播放功能。

微软为滞后副本所做的另一个变化是可以激活滞后副本到当前状态，即使是在事务日志不可用的情况下。这是基于一项叫‘安全网络’的新功能。安全网络取代了先前的传输转储程序（Transport Dumpster）。他负责将每一封成功送达的邮件的副本存储到一个活动的邮箱数据库。如果一个数据库的滞后副本需要被激活而事务日志又不可用时（例如处于写入的状态），Exchange会使用安全网络的数据将数据库置位到当前状态。

公用文件夹（Public Folder）

微软在新的DAG上所做的最广受好评的变化就是公用文件夹也可以启用DAG了。大家都知道，在Exchange2010中，DAG只能保护邮箱数据库，而无法作用在公用文件夹数据库上。当然在Exchange2010上没有专门的公用文件夹数据库。公用文件夹存放在邮箱数据库上，这样就可以使用DAG去保护公用文件夹了。

结论

微软在Exchange2013中对DAG做的最大变化包括数据中心级别的故障转移，通过DAG来为公用文件夹提供高可用性以及滞后副本的自动维护。此外还有一些小的改进，例如在存储故障后卫数据库自动重新设定种子（Reseeding）以及当只有一个健全的DAG副本存在时自动发布告警邮件。

  本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标系统运维之Exchange频道！