Exchange Server 中的高可用性和站点复原能力

可以通过配置 Exchange 服务器和数据库以实现高可用性和站点复原来保护Exchange Server邮箱数据库及其包含的数据。 Exchange Server可最大程度地降低部署高度可用且可复原的邮件传送解决方案的成本和复杂性，同时提供高水平的服务和数据可用性，并支持非常大的邮箱。

Exchange Server使各种规模和所有细分市场的客户能够通过构建 Exchange 2010 中引入的本机复制功能和高可用性体系结构，在其组织中经济地部署消息传递连续性服务。 有关自 Exchange 2010 起的更改列表，请参阅与之前版本相比对高可用性和站点恢复的更改。

关键术语

以下关键术语对于了解高可用性或站点恢复十分重要：

Active Manager

在 Microsoft Exchange 复制服务中运行的内部 Exchange 组件，负责进行故障监视及通过数据库可用性组 (DAG) 中的故障转移进行纠正操作。

AutoDatabaseMountDial

邮箱服务器的属性设置，用于根据要装入的副本所缺少的日志文件数确定是否将被动数据库副本作为新的主动副本自动装入。

连续复制 - 块模式

在块模式中，随着将每次更新写入主动数据库副本的主动日志缓冲区，也会在块模式中将其传送到每个被动邮箱副本上的日志缓冲区。 如果日志缓冲区已满，每个数据库副本将在生成序列中构建、检查并创建下一个日志文件。

连续复制 - 文件模式

在文件模式中，会将关闭的事务日志文件从主动数据库副本推送到一个或多个被动数据库副本中。

数据库可用性组

一组最多 16 台 Exchange 服务器，用于托管一组复制的数据库。

数据库移动性

Exchange Server邮箱数据库复制到其他 Exchange 服务器并装载到的功能。

数据中心版

通常这指 Active Directory 站点；但是，它还可以指物理站点。 在本文档上下文中，数据中心等同于 Active Directory 站点。

数据中心激活协调模式

DAG 设置的属性，当启用时，会强制 Microsoft Exchange 复制服务获取在启动时装入数据库的权限。

灾难恢复

用于手动从故障中恢复的任何进程。 它可以是影响单个项目的故障，也可以是影响整个物理位置的故障。

Exchange 第三方复制 API

Exchange 提供的 API，可以对 DAG 使用第三方同步复制而不是连续复制。

高可用性

一种解决方案，可提供服务可用性、数据可用性以及从影响服务或数据的故障（如网络、存储或服务器故障）中自动恢复的能力。

增量部署

安装Exchange Server后，能够部署高可用性和站点复原能力。

滞后的邮箱数据库副本

日志重播延迟时间大于 0 的被动邮箱数据库副本。

邮箱数据库副本

主动或被动的邮箱数据库（.edb 文件和日志）。

邮箱恢复

Exchange Server中统一的高可用性和站点复原解决方案的名称。

托管可用性

由探测器、监视器和响应程序组成的一组内部进程，跨所有服务器角色和所有协议整合了监视和高可用性。

*超过 (发音为“star over”)

“切换”和“故障转移”的缩写。 切换是指手动激活一个或多个数据库副本。 故障转移是指在出现故障后自动激活一个或多个数据库副本。

安全网络

这以前称为传输转储程序，是传输服务中用于将所有邮件的副本存储 X 天的功能。 默认设置为 2 天。

卷影冗余

可为邮件在整个传送过程中提供冗余的传输服务器功能。

站点恢复

一个配置，可将邮件基础结构扩展为多个 Active Directory 站点，以便在发生影响某个站点的故障时为邮件系统提供运行连续性。

数据库可用性组

DAG 是内置于 Exchange Server 中的高可用性和站点复原框架的基础组件。 DAG 是一组最多 16 个 Exchange 服务器，这些服务器托管一组数据库，并提供数据库级自动恢复，从影响单个数据库、网络或服务器的故障中恢复。 DAG 中的任何服务器可以承载来自 DAG 中任何其他服务器的邮箱数据库副本。 添加到 DAG 的服务器可与 DAG 中的其他服务器协同工作，让用户能够从影响邮箱数据库的故障（如磁盘故障或服务器故障）中自动恢复。 若要详细了解 DAG，请参阅数据库可用性组 (DAG)。

邮箱数据库副本

exchange 2010 中首次引入的高可用性和站点复原功能用于Exchange Server创建和维护数据库副本。 Exchange Server还利用了数据库移动性的概念，即 Exchange 托管的数据库级故障转移。

数据库移动性可断开数据库与服务器的连接，并增加对单个数据库多达 16 个副本的支持。 它还提供为数据库创建副本的本机体验。

将数据库副本设置为主动邮箱数据库的过程称为“切换”。 当发生影响数据库或数据库访问的故障，并且新数据库成为活动副本时，此过程称为 故障转移。 此过程还称为服务器故障，其中一台或多台服务器使先前在故障服务器上处于联机状态的数据库处于联机状态。 发生切换或故障转移时，其他 Exchange 服务器几乎立即意识到切换，并将客户端和消息流量重定向到新的活动数据库。

例如，如果 DAG 中的活动数据库由于基础存储故障而失败，活动管理器会将故障转移到 DAG 中其他服务器上的数据库副本，从而自动恢复。 在 Exchange Server 中，托管可用性提供从失去对数据库的协议访问权限中恢复的行为，包括回收应用程序辅助角色池、重启服务和服务器以及启动数据库故障转移。

若要详细了解邮箱数据库副本，请参阅邮箱数据库副本。

活动管理器

Exchange Server利用 Active Manager 来管理数据库和数据库复制运行状况、状态、连续复制以及高可用性的其他方面。 若要详细了解活动管理器，请参阅活动管理器。

站点恢复

在 Exchange 2010 中，您可以跨两个数据中心部署 DAG，并在第三个数据中心托管见证，然后为这些数据中心的邮箱服务器角色启用故障转移。 但是，由于仍需要手动更改非邮箱服务器角色的命名空间，因此你未获得解决方案本身的故障转移。

在 Exchange 2016 和 Exchange 2019 中，命名空间不需要随 DAG 一起移动。 Exchange 可通过多 IP 地址和负载平衡利用内置到命名空间中的容错功能（如果需要，还可以启动和停止服务器）。 现代 HTTP 客户端可以自动使用此冗余。 HTTP 堆栈可以接受完全限定域名 (FQDN) 的多个 IP 地址，并且，如果它试用的第一个 IP 地址出现硬故障（即无法连接），则需要尝试列表中的下一个 IP 地址。 在软故障（在建立会话之后连接断开，可能是因为服务中出现间歇性故障，例如，设备掉包，需要终止服务）中，用户可能需要刷新其浏览器。

这意味着命名空间不再是单一故障点（Exchange 2010 中便是这样）。 在 Exchange 2010 中，邮件系统中的最大单一故障点可能是向用户提供的 FQDN，因为它会告知用户将要到达的位置。 在 Exchange 2010 范例中，更改 FQDN 到达的位置不是那么容易，因为必须更改 DNS，然后处理 DNS 延迟，这在世界上某些地区具有挑战性。 而且在浏览器中有名称缓存，这些缓存通常大约为 30 分钟或更长，也必须进行处理。

在 Exchange Server 中，客户端有多个位置要去。 Exchange Server中几乎所有的客户端访问协议都基于 HTTP。 例如，Outlook、EAS、EWS、Outlook 网页版和 EAC。 所有受支持的 HTTP 客户端都可以使用多个 IP 地址，因此用户能够在客户端进行故障转移。 可以将 DNS 配置为，在名称解析过程中将多个 IP 地址传递给客户端。 例如，客户端会请求 mail.contoso.com 并取回两个 IP 地址（或四个 IP 地址）。 无论客户端收到多少个 IP 地址，客户端都能够可靠地使用。 这样一来，客户端的性能提升许多，因为如果其中一个 IP 地址失败，客户端还可以尝试连接到一个或多个备用 IP 地址。 如果客户端尝试连接到的地址失败，它会等待大约 20 秒，再尝试连接到列表中的下一个地址。 因此，如果丢失客户端访问服务器阵列的 VIP，客户端恢复会在大约 21 秒后自动执行。

具体优势如下：

• 在Exchange Server中，如果主站点中的负载均衡器丢失，只需 (关闭它，或者关闭 VIP) 并修复或更换它。 没有使用辅助数据中心中的 VIP 的客户端将自动故障切换到辅助 VIP，不需要更改任何命名空间，也不需要在 DNS 中进行任何更改。 这不仅意味着您不再需要执行切换，而且意味着不需要花费与数据中心切换恢复相关的所有时间。 在 Exchange 2010 中，必须处理 DNS 延迟（因此，建议将生存时间 (TTL) 设置为 5 分钟，并引入故障回复 URL）。 在 Exchange 2016 和 Exchange 2019 中，无需执行此操作，因为在 VIP (数据中心) 之间的命名空间) 20 秒 (快速故障转移。

• 由于可在数据中心之间进行命名空间故障切换，实现数据中心故障切换所需的操作就是实现跨数据中心进行邮箱服务器角色故障切换的机制。 要实现 DAG 自动故障切换，您只要构建一个解决方案，使 DAG 平均拆分到两个数据中心，然后将见证服务器置于第三个位置，以便由这两个数据中心内的 DAG 成员对其仲裁，不论包含 DAG 成员的数据中心之间的网络状态如何。 如果您仅有两个数据中心且第三个物理位置不可用，可以将见证服务器放置在 Microsoft Azure 虚拟机上。 有关详细信息，请参阅使用 Microsoft Azure VM 作为 DAG 见证服务器。

• 在这种情况下，管理员的工作就转向仅解决问题，而不需要在还原服务上花费时间。 在服务已运行并且保持数据完整性时，您只需修复失败的项目。 在修复损坏设备时感到的紧迫度和压力水平与在还原服务时感到的紧迫度和压力水平完全不一样。 对于最终用户而言更加轻松，对于管理员而言压力更小。

无需执行切换回复（有时误称为"故障回复"），即可进行故障转移。 如果在主数据中心内丢失服务器，导致客户端中断 20 秒，可能甚至不会关注故障回复。 此时，首要关注的是修复核心问题（例如，替换故障的负载均衡器）。 在该故障设备重新联机并正常运行之后，一些客户端会开始使用它，而其他客户端可以保持通过第二个数据中心运行。

Exchange Server还提供了使管理员能够处理间歇性故障的功能。 举例而言，间歇性故障是可以建立初始 TCP 连接，但是在此之后未进行任何操作的情况。 间歇性故障需要执行某种额外的管理操作，因为它可能是将更换设备投入运行的结果。 在此修复过程进行期间，设备可能已打开并接受一些请求，但实际上，如果没有执行必需的配置步骤，无法为客户端提供服务。 在此情况下，管理员只需从 DNS 中删除要更换的设备的 VIP，即可执行命名空间切换。 然后，在该服务期间，不会有任何客户端尝试连接到它。 在更换过程完成之后，管理员可以将 VIP 添加回 DNS，客户端会最终开始使用它。

有关规划和部署站点复原的详细信息，请参阅规划高可用性和站点复原和部署高可用性和站点复原。

第三方复制 API

Exchange Server包括第三方复制 API，使组织能够使用第三方同步复制解决方案，而不是内置的连续复制功能。 Microsoft 支持使用该 API 的第三方解决方案，前提是该解决方案提供了必需功能以替换所有由于使用 API 而禁用的自有连续复制功能。 仅当在 DAG 内使用 API 管理和激活邮箱数据库副本时才支持此类解决方案。 不支持在这些边界外部使用 API。 此外，该解决方案必须满足适用的 Windows 硬件支持要求。 （进行支持不需要测试验证）。

部署使用内置第三方复制 API 的解决方案时，请注意解决方案供应商负责解决方案的主要支持。 Microsoft 支持复制和非复制解决方案的 Exchange 数据。 使用数据复制的解决方案必须遵守 Microsoft 数据复制支持策略。 此外，使用 Windows 故障转移群集资源模型的解决方案必须满足 Windows 群集支持要求，如 Microsoft 知识库文章 943984 Windows Server 2008 或 Windows Server 2008 R2 故障转移群集的 Microsoft 支持策略 或 Windows Server 2012 故障转移群集的 Microsoft 支持策略中所述。

Microsoft 对于使用基于第三方复制 API 的解决方案部署的备份和恢复支持策略与自有连续复制部署的策略相同。

如果您是正在寻找有关第三方 API 的信息的合作伙伴，请与您的 Microsoft 代表联系。

高可用性和站点恢复文档

下表包含指向有助于了解和管理 DAG、邮箱数据库副本以及备份和还原Exchange Server的主题的链接。