通过

数据库可用性组 (DAG)

  • 项目

适用于：Exchange Server 2013

了解有关 Exchange Server 2013 中的 Exchange DAG 的信息。 本文讨论了数据库可用性组 (DAG) 生命周期，以及使用 DAG 实现高可用性和站点恢复的信息。

数据库可用性组 (DAG) 是内置于 Microsoft Exchange Server 2013 中的邮箱服务器高可用性和站点恢复框架的基础组件。 DAG 是一组邮箱服务器（最多可包含 16 个邮箱服务器），其中承载了一组数据库，可提供从影响单个服务器或数据库的故障中自动执行数据库级恢复的功能。

DAG 是邮箱数据库复制、数据库和服务器切换和故障转移以及名为“活动管理器”的内部组件的边界。 运行于每个邮箱服务器上的活动管理器，在 DAG 中管理切换和故障转移。 有关 Active Manager 的详细信息，请参阅活动管理器。

DAG 中的任何服务器可以承载来自 DAG 中任何其他服务器的邮箱数据库副本。 将服务器添加到 DAG 后，此服务器与 DAG 中的其他服务器协同工作，提供从影响邮箱数据库的故障（如磁盘、服务器或网络故障）中自动执行恢复的功能。

数据库可用性组 (DAG) 生命周期

DAG 利用 增量部署的概念，即能够在安装 Exchange 后为所有邮箱服务器和数据库部署服务和数据可用性。 在部署 Exchange 2013 邮箱服务器后，您可以创建 DAG，将邮箱服务器添加到 DAG，然后在 DAG 成员之间复制邮箱数据库。

注意

支持创建包含物理邮箱服务器和虚拟化邮箱服务器组合的 DAG，前提是服务器和解决方案符合 Exchange 2013 系统要求 和 Exchange 2013 虚拟化中设定的要求。 对于所有 Exchange 高可用性配置，必须确保 DAG 中所有邮箱服务器大小均已经过适当调整，可以处理计划中断和非计划中断过程中的必要工作负载。

通过使用 New-DatabaseAvailabilityGroup cmdlet 创建 DAG。 DAG 最初创建时是 Active Directory 中的一个空对象。 该目录对象用于存储 DAG 的相关信息，比如服务器成员身份信息和某些 DAG 配置设置。 将第一个服务器添加到 DAG 时，将为 DAG 自动创建故障转移群集。 此故障转移群集由 DAG 独占使用，并且此群集必须专用于 DAG。 不支持将此群集用于任何其他用途。

除了创建故障转移群集外，还将启动监视服务器的网络或服务器故障的基础结构。 然后，使用故障转移群集检测信号机制和群集数据库来跟踪和管理有关 DAG 可能快速更改的信息，比如数据库装入状态、复制状态和最后装入位置。

在创建过程中，会为 DAG 指定一个唯一名称，并分配一个或多个静态 IP 地址，或配置为使用动态主机配置协议 (DHCP)，或者创建为不包含群集管理访问点。 不包含管理访问点的 DAG 只能在以下服务器中创建：在 Windows Server 2012 R2 Standard 或 Datacenter 版本上运行 Exchange 2013 Service Pack 1 或更高版本。 不包含群集管理访问点的 DAG 有以下特征：

  • 没有为群集/DAG 分配 IP 地址，因此群集核心资源组中没有 IP 地址资源。
  • 没有为群集分配网络名称，因此群集核心资源组中没有网络名称资源。
  • 群集/DAG 的名称未在 DNS 中注册，并且无法在网络上进行解析。
  • 未在 Active Directory 中创建群集名称对象 (CNO)。
  • 无法使用故障转移群集管理工具管理群集。 群集必须使用 Windows PowerShell 进行管理，并且必须针对每个群集成员运行 PowerShell cmdlet。

本例显示如何使用命令行管理程序创建包含群集管理访问点并包含三个服务器的 DAG。 其中两台服务器（EX1 和 EX2）位于同一个子网 (10.0.0.0) 中，第三台服务器 (EX3) 位于另一个子网 (192.168.0.0) 中。

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

用于创建不包含群集管理访问点的 DAG 的命令非常相似：

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

将 EX1 添加到 DAG 后会为 DAG1 创建群集。 在创建群集期间， Add-DatabaseAvailabilityGroupServer cmdlet 将检索为 DAG 配置的 IP 地址，并忽略与在 EX1 上找到的任何子网不匹配的 IP 地址。 在上述第一个示例中，将使用 IP 地址 10.0.0.5 创建 DAG1 的群集，而忽略 192.168.0.5。 在上述第二个示例中，DatabaseAvailabilityGroupIPAddresses 参数的值指示任务为不包含群集管理访问点的 DAG 创建故障转移群集。 因此，将使用核心群集资源组中的 IP 地址或网络名称资源创建群集。

然后，添加 EX2， Add-DatabaseAvailabilityGroupServer cmdlet 再次检索为 DAG 配置的 IP 地址。 群集的 IP 地址没有更改，因为在 EX2 中与 EX1 位于同一子网中。

然后，添加 EX3， Add-DatabaseAvailabilityGroupServer cmdlet 再次检索为 DAG 配置的 IP 地址。 由于 EX3 上存在与 192.168.0.5 匹配的子网，因此会将 192.168.0.5 地址添加为群集组中的 IP 地址资源。 此外，会自动配置每个 IP 地址资源的网络名称资源的 OR 依赖项。 群集核心资源组移动到 EX3 时，群集将使用 192.168.0.5 地址。

对于包含群集管理访问点的 DAG，当网络名称资源进入联机状态时，Windows 故障转移群集会在域名系统 (DNS) 中注册群集的 IP 地址。 此外，当 EX1 被添加到群集中时，会在 Active Directory 中创建群集名称对象 (CNO)。 群集的网络名称、IP 地址和 CNO 不用于 DAG 功能。 管理员和最终用户不需要出于任何原因对接或连接群集/DAG 名称或 IP 地址。 某些第三方应用程序连接到群集管理访问点以执行管理任务，例如备份或监视。 如果不使用任何需要群集管理访问点的第三方应用程序，并且 DAG 在 Windows Server 2012 R2 上运行 Exchange 2013 SP1 或更高版本，则建议创建不使用管理访问点的 DAG。 这可以简化 DAG 配置，消除一个或多个 IP 地址的需求，并降低 DAG 受攻击的可能性。

此外，还将 DAG 配置为使用见证服务器和见证目录。 见证服务器和见证目录可以由系统自动配置，还可以由管理员手动配置。 在上面的示例中，手动将 EX4（不是也不会是 DAG 成员的服务器）配置为 DAG 的见证服务器。

默认情况下，DAG 旨在使用内置连续复制功能在 DAG 中的服务器之间复制邮箱数据库。 如果在 Exchange 2013 中使用支持第三方复制 API 的第三方数据复制，则必须使用具有 ThirdPartyReplication 参数的 New-DatabaseAvailabilityGroup cmdlet 在第三方复制模式下创建 DAG。 启用此模式后不能将其禁用。

创建 DAG 后，可以将邮箱服务器添加到 DAG 中。 将第一个服务器添加到 DAG 后，将形成群集以供 DAG 使用。 DAG 使用 Windows 故障转移群集技术，例如群集检测信号、群集网络以及群集数据库（用于存储更改的数据，例如数据库状态从活动更改为被动或相反的情况，或从装入更改为卸除或相反的情况）。 每个后续服务器在添加到 DAG 时，都会加入到基础群集，Exchange 会自动调整群集的仲裁模型，并且服务器会添加到 Active Directory 中的 DAG 对象。

在将邮箱服务器添加到 DAG 后，可以配置各种 DAG 属性，例如对 DAG 中的数据库复制使用网络加密还是使用网络压缩。 您还可以配置 DAG 网络和创建附加 DAG 网络。

将成员添加到 DAG 并配置 DAG 后，可以将每个服务器上的活动邮箱数据库复制到其他 DAG 成员中。 在创建邮箱数据库副本后，可以使用各种内置监视工具监视副本的运行状况和状态。 此外，还可以执行数据库和服务器切换。

有关创建 DAG、管理 DAG 成员身份、配置 DAG 属性、创建和监视邮箱数据库副本以及执行切换的详细信息，请参阅管理高可用性和站点恢复。

数据库可用性组 (DAG) 仲裁模型

每个 DAG 下均有一个 Windows 故障转移群集。 故障转移集群使用仲裁概念，即利用投票者的共识来确保一次只有一部分群集成员（这可以指所有成员或大部分成员）在运行。 仲裁在 Exchange 2013 中并不是一个新概念。 Exchange 早期版本中的高可用性邮箱服务器同样使用故障转移群集及其仲裁概念。 仲裁代表一个成员和资源的共享视图，仲裁一词也用于描述代表在所有群集成员间共享的群集中的配置的物理数据。 因此，所有 DAG 都要求其基础故障转移群集具有仲裁。 如果群集丢失仲裁，则所有 DAG 操作都将终止，DAG 中托管的所有装入数据库都将卸除。 在这种情况下，需要管理员干预以更正仲裁问题并恢复 DAG 操作。

仲裁对于确保一致性，充当用于避免分区的关系断开裁判，以及确保群集响应能力而言非常重要：

  • 确保一致性：Windows 故障转移群集的主要要求是每个成员始终具有与其他成员一致的群集视图。 群集配置单元充当了与群集相关的所有配置信息的权威性存储库。 如果 DAG 成员无法本地加载群集配置单元，则群集服务将不会启动，因为无法保证成员始终与该群集中其他成员保持一致这一要求。

  • 充当连接中断者：仲裁见证资源在成员数量偶数的 DAG 中使用，以避免拆分脑部综合症方案，并确保 DAG 中只有一个成员集合被视为正式成员。 当仲裁需要见证服务器时，DAG 中任何能与见证服务器通信的成员均可以在见证服务器的 witness.log 文件上设置一个服务器消息块 (SMB) 锁定。 锁定见证服务器 (称为 锁定节点 的 DAG 成员) 出于仲裁目的保留额外的投票。 与锁定节点通信的 DAG 成员占多数，因此保留仲裁权。 无法与锁定节点通信的所有 DAG 成员占少数，因此会失去仲裁权。

  • 确保响应能力：为确保响应能力，仲裁模型确保每当群集运行时，分布式系统的足够成员是可操作的和通信的，并且至少可以保证群集当前状态的一个副本。 无需额外时间来为成员建立通信，或确定特定副本是否得到保证。

具有偶数个成员的 DAG 使用故障转移群集的节点和文件共享多数仲裁模式，该模式采用外部见证服务器充当关系断开裁判。 在此仲裁模式中，每个 DAG 成员都将获得一票。 此外，还将使用见证服务器向某个 DAG 成员提供一份权重投票（例如，获得两投票而不是一份）。 默认情况下，群集仲裁数据存储在每个 DAG 成员的系统磁盘中，并且在这些磁盘间保持一致。 但是，仲裁数据的副本并不存储在见证服务器上。 见证服务器上的一个文件用于记录哪个成员拥有最新的数据副本，但见证服务器没有群集仲裁数据的副本。 在此模式中，大多数的投票者（DAG 成员加上见证服务器）必须工作正常并且能够相互通信以保留仲裁权。 如果大多数投票者不能相互通信，则 DAG 基础群集将失去仲裁权，并且 DAG 需要管理员干预才能恢复正常工作。

具有奇数个成员的 DAG 使用故障转移群集的节点多数仲裁模式。 在此模式中，每个成员将获得一票，且每个成员的本地系统磁盘用于存储群集仲裁数据。 如果 DAG 配置发生更改，此更改将反映在不同磁盘上。 仅当更改发生在一半（向下舍入）加一数目的成员的磁盘上，该更改才会被视为已提交并永久保存。 例如，在五个成员的 DAG 中，更改必须发生在二加一个成员上，即共三个成员上。

仲裁要求大多数投票者能够相互通信。 请考虑具有四个成员的 DAG。 因为此 DAG 具有偶数个成员，所以使用外部见证服务器向其中一个群集成员提供第五个决定性投票。 为了保留大多数投票者（进而保留仲裁权），至少必须有三个投票者能够相互通信。 任何时候，在不中断服务以及数据访问的前提下，最多有两个投票者可以处于脱机状态。 如果有三个或更多个投票者脱机，DAG 将失去仲裁权，且服务和数据访问将中断，直至问题解决。

使用数据库可用性组 (DAG) 实现高可用性

为了说明 DAG 如何提供邮箱数据库的高可用性，请考虑以下示例，其中使用的 DAG 有五个成员。 下图说明了此 DAG 。

数据库可用性组 (DAG) 。

在上图中，绿色数据库为活动邮箱数据库副本，而蓝色数据库为被动邮箱数据库副本。 在此示例中，数据库副本没有跨每个服务器进行镜像，而是分布到多个服务器。 这可以确保 DAG 中不存在两个包含同一组数据库副本的服务器，为 DAG 提供了更大的故障应对能力，包括其他组件因定期维护而不可用时发生的故障。

请考虑使用前面的示例 DAG 的以下方案，其中说明了对多个数据库故障和服务器故障的弹性。

最初，所有数据库和服务器都正常运行。 您需要在 EX2 上安装一些操作系统更新，以便将服务器置于维护模式。 此操作将导致服务器切换，这会激活其他邮箱服务器上的 DB4 副本。 服务器切换将所有主动邮箱数据库副本从其当前服务器移至 DAG 中的一个或多个其他邮箱服务器，以应对当前服务器的计划中断。 在此示例中，EX2 (DB4) 上只有一个活动的邮箱数据库，所以仅移动了一个活动邮箱数据库副本。

数据库可用性组 (DAG) 服务器脱机。

当您在 EX2 上执行维护时，EX3 会遭遇灾难性硬件故障并脱机。 在脱机之前，EX3 将承载 DB2 的活动副本。 为了从故障恢复，系统会在 30 秒内自动激活在 EX1 上承载的 DB2 副本。 下图对此进行了说明。

服务器处于脱机状态且服务器发生故障的 DAG。

对 EX2 完成预定的维护后，可以将服务器联机，并离开维护模式。 在 EX2 可用后，会通知 DAG 的其他成员，并且承载在 EX2 上的 DB1、DB4 和 DB5 的副本会自动与每个数据库的活动副本进行同步。 下图对此进行了说明。

已还原服务器重新同步数据库的 DAG。

在将 EX3 中出现故障的硬件组件替代为新组件后，EX3 将恢复联机。 EX3 可用后，会通知 DAG 的其他成员，并且托管在 EX3 上的 DB2、DB3 和 DB4 的副本会自动与每个数据库的主动副本保持同步。 下图对此进行了说明。

具有成员重新同步数据库副本的 DAG。

使用数据库可用性组 (DAG) 实现站点恢复

除在数据中心中提供高可用性之外，DAG 还可以在为一个或多个数据中心提供站点恢复的配置中扩展到一个或多个数据中心。 在前面的示例图中，DAG 位于单个数据中心和单个 Active Directory 站点中。 增量部署可用于将此 DAG 扩展到第二个数据中心（第二个 Active Directory 站点），方法是部署邮箱服务器和所需的支持资源（一个或多个 Active Directory 服务器以及 DNS 服务）。 然后将邮箱服务器添加到 DAG，如下图所示。

跨两个 Active Directory 站点扩展的 DAG。

在此示例中，Redmond 数据中心中的每个活动数据库的被动副本都是在都 Dublin 数据中心中的 EX6 上配置的。 但是，提供站点恢复的 DAG 配置有很多其他示例。 例如：

  • EX6 并非仅托管被动数据库副本，它还可以托管所有主动副本，或同时托管主动副本和被动副本。

  • 除了 EX6 之外，Dublin 数据中心中还可以部署多个 DAG 成员，以抵御其他故障。 该配置还可以提供更大的容量，以便 Redmond 数据中心出现故障时，Dublin 数据中心可以支持更大的用户群。

使用多个数据库可用性组 (DAG) 实现站点恢复

在上述示例中，单个 DAG 跨两个数据中心进行扩展，为一个或同时为两个数据中心提供站点恢复。 在 DAG 扩展到的每个数据中心均有一个活动用户群的环境中使用单个 DAG 提供站点恢复时，广域网 (WAN) 连接中存在单一故障点。 这是因为仲裁要求多数投票者处于活动状态且能够相互通信。

在上述示例中，多数投票者位于 Redmond 数据中心。 如果 Dublin 数据中心托管主动邮箱数据库并且具有本地用户群，则 WAN 中断可能会导致 Dublin 用户的邮件服务中断。 当 WAN 连接中断时，只有 Redmond 数据中心的 DAG 成员保留仲裁权并继续提供邮件服务。

为了避免 WAN 成为单一故障点，在需要为多个具有活动用户群的数据中心提供站点恢复时，应当部署多个 DAG，其中每个 DAG 的大多数投票者分别位于单独的数据中心。 发生 WAN 中断时，将阻止复制，直至恢复连接。 由于每个 DAG 继续服务其本地用户群，因此用户仍然可以使用邮件服务。