了解数据库可用性组

 

适用于： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上一次修改主题： 2015-03-09

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

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

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

目录

数据库可用性组生命周期

使用数据库可用性组实现高可用性

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

使用数据库可用性组时的客户端体验

数据库可用性组生命周期

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

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

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

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

在创建过程中，会为 DAG 指定一个唯一名称，并分配一个或多个静态 IP 地址，或配置为使用动态主机配置协议 (DHCP)。您可以通过使用 DatabaseAvailabilityGroupIPAddresses 参数指定单个 IP 地址或逗号分隔的 IP 地址列表。

本示例显示具有三台服务器的 DAG。其中两台服务器（EX1 和 EX2）位于同一个子网 (10.0.0.0) 中，第三台服务器 (EX3) 位于另一个子网 (192.168.0.0) 中。

New-DatabaseAvailabilityGroup -Name DAG1 -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

注意：
将 DatabaseAvailabilityGroupIPAddresses 参数配置为值 0.0.0.0 会将 DAG（群集）配置为将 DHCP 用作其 IP 地址或 IP 地址资源。

将 EX1 添加到 DAG 后会为 DAG1 创建群集。在创建群集期间，Add-DatabaseAvailabilityGroupServer cmdlet 将检索为 DAG 配置的 IP 地址，并忽略与在 EX1 上找到的任何子网不匹配的 IP 地址。在此示例中，将使用 IP 地址 10.0.0.5 创建 DAG1 的群集，而忽略 192.168.0.5。

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

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

当网络名称资源进入联机状态时，Windows 故障转移群集会在域名系统 (DNS) 中注册群集的 IP 地址。此外，还会在 Active Directory 中创建群集名称对象 (CNO)。群集的名称、IP 地址和 CNO 将只由系统在内部使用，以保护 DAG 安全以及进行内部通信。管理员和最终用户不需要出于任何原因对接或连接 DAG 名称或 IP 地址。

除了配置名称以及一个或多个 IP 地址，还会将 DAG 配置为使用见证服务器和见证目录。见证服务器和见证目录可以由系统自动指定，还可以由管理员手动指定。

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

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

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

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

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

数据库可用性组仲裁模式

每个 DAG 下均有一个 Windows 故障转移群集。故障转移集群使用仲裁概念，即利用投票者的共识来确保一次只有一部分群集成员（这可以指所有成员或大部分成员）在运行。仲裁在 Exchange 2010 中并不是一个新概念。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 的以下方案，其中说明了对多个数据库故障和服务器故障的弹性。

最初，所有数据库和服务器都正常运行。您需要在 EX2 上安装某些操作系统更新。您执行服务器切换，这会激活其他邮箱服务器上的 DB4 副本。服务器切换将所有主动邮箱数据库副本从其当前服务器移至 DAG 中的一个或多个其他邮箱服务器，以应对当前服务器的计划中断。您可以通过运行 Exchange 命令行管理程序中的以下命令快速执行服务器切换。

Move-ActiveMailboxDatabase -Server EX2

在此示例中，EX2 (DB4) 上只有一个活动的邮箱数据库，所以仅移动了一个活动邮箱数据库副本。通过省略上述命令中的 ActivateOnServer 参数，您选择使系统尽可能选择最佳的新活动副本，系统选择了 EX5 上的副本，如下图所示。

有一台服务器因维护而脱机的 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 位于单个数据中心和单个 Active Directory 站点中。增量部署可用于将此 DAG 扩展到第二个数据中心（第二个 Active Directory 站点），方法是部署邮箱服务器和所需的支持资源（一个或多个 Active Directory 服务器以及一个或多个集线器传输和客户端访问服务器）。然后将邮箱服务器添加到 DAG，如下图所示。

跨两个 Active Directory 站点扩展的 DAG

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

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

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

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

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

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

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

返回顶部

使用数据库可用性组时的客户端体验

DAG 可用于提供高可用性和站点恢复。使用 DAG 时的客户端体验取决于客户端的类型和版本以及客户端用于访问邮箱数据的协议。例如，如果发生跨站点数据库故障转移，则 POP3 和 IMAP4 客户端使用的行为和重新连接逻辑与 Microsoft Outlook 2010 客户端使用的行为和重新连接逻辑不同。

以下部分介绍各种情况下的客户端行为和逻辑。对于介绍的行为，假定以下条件：

• 每个 Active Directory 站点的环境中包含单个客户端访问服务器阵列，且每个站点至少包含两个客户端访问服务器。

• 在客户端访问服务器阵列的前端安装并配置了相应的基于硬件或软件的负载平衡器。

• 适当的命名空间、证书规划及配置已完成，包括必需的 DNS 记录。

Microsoft Outlook 行为与逻辑

通常情况下，Outlook 的所有版本针对单个数据中心和单个 Active Directory 站点内发生的数据库故障转移采取相同的行为。与 Exchange 的早期版本不同，在 Exchange 2010 中，Outlook 不再直接连接到邮箱服务器上的 Exchange 存储。Outlook（以及任何其他 MAPI 客户端）会连接到客户端访问服务器角色上的 RPC 客户端访问和通讯簿服务，并且用户的 Outlook 将配置为连接到客户端访问服务器阵列，该阵列随后将客户端连接到单个客户端访问服务器。将 Outlook 连接从邮箱服务器中抽离提供了以下好处：

• 发生数据库故障转移时，Outlook 仍然保持与客户端访问服务器阵列中相同服务器的连接。出现此情况时，客户端访问服务器上运行的活动管理器客户端从 DAG 的活动管理器获知托管主动数据库副本的 DAG 成员。然后，客户端访问服务器连接到此邮箱服务器，并且 Outlook 会指示其已连接到 Exchange 服务器。

• 如果由于计划中断或非计划中断，客户端访问服务器阵列中的一个客户端访问服务器不可用，则将由此阵列中的其余客户端访问服务器处理客户端负载。由于 Outlook 配置为连接到客户端访问服务器阵列而非单个客户端访问服务器，因此客户端访问服务器阵列中的成员可以独自承受故障或手动使其脱机，而不会影响用户的 Outlook 配置文件。这可以自动进行（例如，基于阵列前端的负载平衡器解决方案所执行的监视自动重新配置阵列），您也可以手动执行此过程。

Outlook 的所有版本同样会针对两个数据中心和两个 Active Directory 站点间发生的数据中心切换采取相同的行为。数据中心切换包括更改客户端访问命名空间（例如，Microsoft OfficeOutlook Web App、SMTP、POP3、IMAP4、Autodiscover、Exchange Web Services 或 RPC 客户端访问）使用的的 IP 地址，包括从主数据中心中的 IP 地址到辅助数据中心中的 IP 地址。因此，用户的 Outlook 配置文件中使用的命名空间并未更改，并且自动发现服务继续将客户端指向相同的客户端访问服务器阵列命名空间。

跨站点数据库故障转移之后的 Outlook 行为与其在单个 Active Directory 站点发生数据库故障转移或数据中心切换之后的行为不同。

Outlook 版本的示例行为

以下示例说明发生跨站点数据库故障转移之后，Outlook 2010、Office Outlook 2007 和 OfficeOutlook 2003 的行为。每个示例中使用的拓扑是一个扩展到两个 Active Directory 站点（Redmond 和 Portland）的四成员 DAG。用户的邮箱托管在已复制到每个服务器的 DB1。在每个示例中，DB1 的主动副本从 MBX2 故障转移到 MBX3。

说明跨站点故障转移之后的 Outlook 行为的示例拓扑

每个客户端已配置为将 CAS1 作为其主服务器，使 Redmond 成为“Outlook 配置文件站点”。由于客户端位于 Redmond 中，因此为 CAS1 配置了 DB1 的 RPCClientAccessServer 属性，使 Redmond 成为“首选数据库站点”。由于 DB1 在 MBX2 上出现故障，并在 MBX3 上变为活动状态，因此 Portland 是“已装入数据库站点”。

Outlook 2010 和 Outlook 2007 示例

如果 Redmond 站点中有客户端访问服务器可用，则 Outlook 2010 和 Outlook 2007 会继续连接到 Redmond 站点中的 RPC 客户端访问阵列。客户端使用的客户端访问服务器会使用 MAPI RPC 与 Portland 站点中的用户邮箱服务器通信。

如果 Redmond 站点中没有客户端访问服务器可用，则必须执行从 Redmond 到 Portland 的数据中心切换，才能还原对服务和数据的访问。有关执行数据中心切换的详细步骤，请参阅执行服务器切换。

Outlook 2003 示例

当 Outlook 2003 尝试连接到 CAS1 时，同样会收到 ecWrongServer 消息响应。与 Outlook 2010 和 Outlook 2007 不同，Outlook 2003 不包含自动发现功能，因此必须使用其他方法来更新用户的配置文件。MAPI 配置文件重定向是 Outlook 2003 使用的机制。MAPI 配置文件重定向要求初始的源服务器必须处于联机状态。如果 CAS1 不可用并且阵列中的所有其他客户端访问服务器都不可用（或阵列仅包含 CAS1），则在没有手动干预的情况下，Outlook 2003 无法执行 MAPI 重定向或连接到用户的邮箱数据库。

使用公用文件夹时 Outlook 的行为与逻辑

尽管公用文件夹数据库可以托管在属于 DAG 成员的邮箱服务器上，但公用文件夹数据库不使用连续复制，而是依赖公用文件夹复制获取高可用性。邮箱数据库故障转移之后，Outlook 客户端重新连接到公用文件夹数据库的行为不但取决于故障的性质，还取决于公用文件夹复制配置设置以及公用文件夹数据库的运行状况和当前状态。由于连续复制不能用于公用文件夹数据库，因此公用文件夹数据库的高可用性是通过部署多个公用文件夹数据库并将其配置为相互复制来实现的。我们建议您配置每个文件夹的多个副本。

非 Outlook 客户端行为与逻辑

通常情况下，客户端和协议（除了 Outlook 和 MAPI）的行为根据使用的应用程序和故障情况而有所不同。通常与 Outlook 相同，典型的 Exchange 应用程序和客户端（例如，Outlook Web App、Microsoft Exchange ActiveSync、POP3、IMAP4 和 Exchange Web Services）针对单个数据中心和单个 Active Directory 站点内发生的数据库故障转移采取相同的行为。与此类似，所有这些客户端和协议（包括 SMTP 和 Windows PowerShell）在数据中心切换后采取的行为与 Outlook 相同。

如果发生跨站点数据库故障转移，这些客户端和协议的行为将会不同。下表列出了这些客户端的行为。

典型 Exchange 客户端的跨站点数据库故障转移行为

客户端或协议	行为
Outlook Web App	手动重定向。在此情况下，客户端命名空间从 http://mailred.contoso.com 更改为 http://mailpdx.contoso.com。用户输入登录凭据后，通过手动重定向页面将用户重定向到 Portland 站点中的 CAS2，这说明使用的 URL 不正确，正确的 URL 为 ttps://mailpdx.contoso.com/owa。
Exchange ActiveSync	代理或重定向。在此情况下，客户端行为取决于客户端设备上实施的 Exchange ActiveSync 协议及其版本。
POP3 和 IMAP4	代理。此情况始终包含客户端访问服务器到客户端访问服务器的代理机制。
Exchange Web 服务	使用自动发现来确定新的连接终结点。

返回顶部

 © 2010 Microsoft Corporation。保留所有权利。