每个 DAG 下均有一个 Windows
故障转移群集
。故障转移集群使用仲裁概念，即利用投票者的共识来确保一次只有一部分群集成员（这可以指所有成员或大部分成员）在运行。仲裁并不是
Exchange Server
的新概念。Exchange 早期版本中的高可用性邮箱服务器同样使用故障转移群集及其仲裁概念。仲裁代表一个成员和资源的共享视图，
仲裁
一词也用于描述代表在所有群集成员间共享的群集中的配置的物理数据。因此，所有 DAG 都要求其基础故障转移群集具有仲裁。如果群集丢失仲裁，则所有 DAG 操作都将终止，DAG 中托管的所有装入数据库都将卸除。在这种情况下，需要管理员干预以更正
仲裁
问题并恢复 DAG 操作。
具有偶数个成员的 DAG 使用故障转移群集的节点和文件共享多数仲裁模式，该模式采用外部见证服务器充当关系断开裁判。在此仲裁模式中，每个 DAG 成员都将获得一票。此外，还将使用见证
服务器
向某个 DAG 成员提供一份权重投票（例如，获得两投票而不是一份）。默认情况下，群集仲裁数据存储在每个 DAG 成员的系统磁盘中，并且在这些磁盘间保持一致。但是，仲裁数据的副本并不存储在见证服务器上。见证服务器上的一个文件用于记录哪个成员拥有最新的数据副本，但见证
服务器
没有群集仲裁数据的副本。在此模式中，大多数的投票者（DAG 成员加上见证服务器）必须工作正常并且能够相互通信以保留仲裁权。如果大多数投票者不能相互通信，则 DAG 基础群集将失去仲裁权，并且 DAG 需要
管理员
干预才能恢复正常工作。
仲裁要求大多数投票者能够相互通信。请考虑具有四个成员的 DAG。因为此 DAG 具有偶数个成员，所以使用外部见证服务器向其中一个群集成员提供第五个决定性投票。为了保留大多数投票者（进而保留仲裁权），至少必须有三个投票者能够相互通信。任何时候，在不中断服务以及数据访问的前提下，最多有两个投票者可以处于脱机状态。如果有三个或更多个投票者脱机，DAG 将失去仲裁权，且服务和数据访问将中断，直至问题解决。
DAG仅使用了Windows故障转移群集组件提供的有限的一部分群集功能。DAG使用群集数据库、群集心跳（Cluster heartbeat）及文件共享见证（File Share Witness，FSW）功能。在Exchange 2007及早期版本中，Exchange是一个由Windows故障转移群集操作的应用程序。而在Exchange 2010中，情况发生了变化，Windows故障转移群集注册时所创建的Exchange群集资源DLL及所有群集资源，已从Exchange 2010代码中移除。
增量部署：
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管理员也不再需要有群集管理的经验。
数据库级的复制：
为了支持DAG的新功能，Exchange 2010数据库已迁移到组织级，而不是Exchange 2007或早期版本的服务器级。Exchange 2010中不存在存储组的概念。现在，每个数据库都有一个日志流与数据库相关联。CCR的一个缺点是：如果主动节点的一个数据库出现故障，群集邮箱服务器上现有的所有活动数据库的故障都将转移到被动CCR节点。如果这个节点上的用户有邮箱存储于各自的群集邮箱服务器（Cluster Mailbox Server，CMS），他们都将受到影响。
每个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个或更多副本时，程序设计为无需用户备份。也就是说当依次循环登录受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不同，现在，用户可以通过指定一个数据库副本作为
源数据库
来执行播种。这就意味着，现有邮箱数据库的播种或重播操作不再对活动数据库副本产生影响。
公用文件夹数据库不受DAG保护：
与
Exchange 2007
的CCR不同，用户不能使用DAG保护公用文件夹数据库，而必须使用传统的公共文件夹的复制机制对其加以保护。但在这方面也做了一些改进：如果公用文件夹存储于DAG成员服务器上，Exchange 组织中只有一个公用文件夹存储的限制被取消。
改进的传输转储程序：
传输转储程序也有所改进，甚至受损数据库在位于不同
活动目录
站点的数据库副本间进行故障转移时，信息都可以重新递送。除此之外，当所有信息都被复制到数据库副本时，它们将从传输转储程序中被删除。
DAG 创建方法是在
Exchange
管理中心 (EAC) 中使用"新建数据库可用性组"向导，或在 Exchange 命令行管理程序中运行
New-DatabaseAvailabilityGroupcmdlet
。
创建 DAG 时，请提供 DAG 名称、可选见证服务器和见证目录设置。此外，还可以为 DAG 分配一个或多个 IP 地址，方法为使用
静态IP地址
，或使用
动态主机配置协议
(DHCP) 为 DAG 自动分配必要的 IP 地址。 可以使用
_DatabaseAvailabilityGroupIpAddresses_
参数将 IP 地址手动分配给 DAG。如果省略此参数，DAG 会尝试使用网络中的
DHCP服务器
来获取 IP 地址。
创建 DAG 时，将在
Active Directory
中创建一个空对象，以代表具有指定名称且对象类为msExchMDBAvailabilityGroup的 DAG。
Dag 使用
Windows Server 2008
R2 或更高版本中的 Windows 故障转移群集技术的子集，如群集检测信号、群集网络和群集数据库（用于存储更改或可以快速更改的数据，例如数据库状态从活动更改为被动或反向，或从已安装到已卸除或反向。因此，只能在包含 Windows 故障转移群集的受支持的 Windows 版本上安装的 Exchange 邮箱服务器上创建 Dag。
DAG
见证服务器和见证目录
创建 DAG 时，需要为 DAG 指定一个不超过 15 个字符且在
Active Directory
林中唯一的名称。此外，每个 DAG 都会配置有见证服务器和见证目录。仅当 DAG 中成员数为偶数时，才使用见证服务器及其目录，且只能用于仲裁目的。无需提前创建见证目录。
Exchange
会在见证服务器上自动创建并保护见证目录。见证目录不得用于除 DAG 见证服务器之外的其他任何目的。
-
见证服务器不能是 DAG 的成员。
-
见证服务器必须与 DAG 位于同一个 Active Directory 林中。
-
见证服务器必须运行 Windows Server 2008 或更高版本。
-
单个服务器可以充当多个 DAG 的见证。但是，每个 DAG 都需要其自己的见证目录。
无论将哪个服务器用作见证服务器，如果在预期的见证服务器上启用了 Windows 防火墙，必须为文件和打印机共享启用 Windows 防火墙例外。见证服务器使用 SMB 端口 445。
DAG
见证服务器放置注意事项
DAG 的见证服务器放置将取决于业务需求和组织的可用选项。Exchange 现在包含对在 Exchange 2010 中不建议或无法使用的新 DAG 配置选项的支持。这些选项包括使用第三个位置，如第三个数据中心、分支机构或 Microsoft Azure
虚拟网络
。
下表列出了不同部署方案中见证服务器放置的常规建议。
|
部署方案
|
推荐
|
|
在单个数据中心部署单个 DAG
|
查找相同数据中心中的见证服务器作为 DAG 成员
|
|
在两个数据中心部署单个 DAG；没有其他可用位置
|
在 Microsoft Azure 虚拟网络上查找见证服务器来启用自动数据中心故障转移，或
在主数据中心查找见证服务器
|
|
在单个数据中心部署多个 DAG
|
查找相同数据中心中的见证服务器作为 DAG 成员。其他选项包括：
·对多个 Dag 使用相同的见证服务器
·使用 DAG 成员充当不同 DAG 的见证服务器
|
|
在两个数据中心中部署多个 DAG
|
在 Microsoft Azure 虚拟网络上查找见证服务器来启用自动数据中心故障转移，或
在数据中心查找视为每个 DAG 的主服务器的见证服务器。其他选项包括：
·对多个 Dag 使用相同的见证服务器
·使用 DAG 成员充当不同 DAG 的见证服务器
|
|
在两个以上数据中心部署单个或多个 DAG
|
在此配置中，见证服务器应位于您希望大多数仲裁投票位于其中的数据中心。
|
在两个数据中心内部署 DAG 后，现在可以使用第三个位置来承载见证服务器。如果组织具有带有网络基础结构的第三个位置，且该网络基础结构与影响部署了 DAG 的两个数据中心的网络故障分离开来，则可以在此第三个位置部署 DAG 的见证服务器，从而将 DAG 配置为可以自动将数据库故障转移到其他数据中心，以响应数据中心级别的故障事件。如果您的组织只有两个物理位置，则可以使用 Microsoft Azure
虚拟网络
作为放置见证服务器的第三个位置。
数据库可用性组 (DAG) 是一组（最多 16 台）Microsoft Exchange Server 2010 邮箱服务器，提供从数据库、服务器或网络故障中自动执行数据库级恢复的功能。DAG 使用连续复制和 Windows 故障转移
群集技术
的子集以提供高可用性和站点恢复。DAG 中的邮箱服务器相互进行故障监视。邮箱服务器添加到 DAG 后，它会与 DAG 中的其他服务器协同工作，提供从数据库故障中自动执行数据库级恢复的功能。
