高可用性和网站恢复

适用于：Exchange Server 2013

您可以通过配置邮箱服务器和数据库以实现高可用性和站点恢复来保护 Exchange Server 2013 邮箱数据库及其包含的数据。 Exchange 2013 在提供高级别的服务和数据可用性和支持很大的邮箱的同时，还可以减少部署具有高可用性和恢复能力的邮件解决方案的成本和复杂性。

Exchange 2010 构建于 Exchange 2013 中的本机复制功能和高可用性体系结构上，使各个市场中各种规模的客户都可以在组织中经济高效地部署邮件连续性服务。 有关 Exchange 2010 和 Exchange 2007 的更改列表，请参阅与之前版本相比对高可用性和站点恢复的更改。

关键术语

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

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

• AutoDatabaseMountDial：邮箱服务器的一种属性设置，根据要装载的副本缺少的日志文件数，确定被动数据库副本是否自动装载为新的主动副本。

• 连续复制 - 块模式：在块模式下，由于每次更新都写入活动数据库副本的活动日志缓冲区，因此也会以块模式将其传送到每个被动邮箱副本上的日志缓冲区。 如果日志缓冲区已满，每个数据库副本将在生成序列中构建、检查并创建下一个日志文件。

• 连续复制 - 文件模式：在文件模式下，关闭的事务日志文件从活动数据库副本推送到一个或多个被动数据库副本。

• 数据库可用性组：最多包含 16 个 Exchange 2013 邮箱服务器的组，用于托管一组复制的数据库。

• 数据库移动性：Exchange 2013 邮箱数据库可以复制到其他 Exchange 2013 邮箱服务器并装载到其他 Exchange 2013 邮箱服务器。

• 数据中心：通常指 Active Directory 站点;但是，它也可以引用物理站点。 在本文档上下文中，数据中心等同于 Active Directory 站点。

• 数据中心激活协调模式：DAG 设置的一个属性，启用后，将强制 Microsoft Exchange 复制服务获取在启动时装载数据库的权限。

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

• Exchange 第三方复制 API：Exchange 提供的 API，允许对 DAG 使用第三方同步复制，而不是连续复制。

• 高可用性：提供服务可用性、数据可用性以及从影响服务或数据 (（例如网络、存储或服务器故障) ）故障时自动恢复的解决方案。

• 增量部署：安装 Exchange 2013 后部署高可用性和站点复原能力。

• 滞后邮箱数据库副本：日志重播滞后时间大于零的被动邮箱数据库副本。

• 邮箱数据库副本：邮箱数据库 (.edb 文件和日志) （主动或被动）。

• 邮箱复原：Exchange 2013 中统一的高可用性和站点复原解决方案的名称。

• 托管可用性：一组内部流程，由探测、监视器和响应程序组成，这些进程包含跨所有服务器角色和所有协议的监视和高可用性。

• *over (发音为“star over”) ： 切换 和 故障转移的缩写。 切换是指手动激活一个或多个数据库副本。 故障转移是指在出现故障后自动激活一个或多个数据库副本。

• 安全网：以前称为传输转储器，这是传输服务的一项功能，用于存储 X 天的所有消息的副本。 默认设置为 2 天。

• 卷影冗余：一种传输服务器功能，为邮件在传输过程中的整个时间提供冗余。

• 站点复原能力：一种配置，可将消息传送基础结构扩展到多个 Active Directory 站点，以便在发生影响其中一个站点的故障时为消息传送系统提供操作连续性。

数据库可用性组

DAG 是内置于 Exchange 2013 中的高可用性和站点恢复框架的基础组件。 DAG 是一组邮箱服务器（最多可包含 16 个邮箱服务器），其中承载了一组数据库，可提供从影响各个数据库、网络或服务器的故障中自动执行数据库级恢复的功能。 DAG 中的任何服务器可以承载来自 DAG 中任何其他服务器的邮箱数据库副本。 将服务器添加到 DAG 后，此服务器与 DAG 中的其他服务器协同工作，提供从影响邮箱数据库的故障（如磁盘故障或服务器故障）中自动执行恢复的功能。 有关 DAG 的详细信息，请参阅数据库可用性组 (DAG)。

邮箱数据库副本

Exchange 2010 中首次引入并使用的高可用性和站点恢复功能在 Exchange 2013 中用于创建和维护数据库副本。 Exchange 2013 还使用了数据库移动性这一概念，它是 Exchange 托管的数据库级故障转移。

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

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

例如，如果 DAG 中的主动数据库由于基础存储故障而失败，Active Manager 会通过将故障转移到 DAG 中的其他邮箱服务器上的数据库副本来执行自动恢复。 在 Exchange 2013 中，托管可用性增加了从丢失数据库协议访问权限的情况中恢复的新行为，包括回收应用程序工作线程池、重新启动服务和服务器以及启动数据库故障转移。

有关邮箱数据库副本的详细信息，请参阅邮箱数据库副本。

活动管理器

Exchange 2013 利用 Exchange 2010 中引入的 Active Manager 组件来管理数据库和数据库副本运行状况、状态、连续复制及邮箱服务器高可用性的其他方面。 有关 Active Manager 的详细信息，请参阅活动管理器。

站点恢复

虽然 Exchange 2013 继续使用 DAG 和 Windows 故障转移群集实现邮箱服务器角色高可用性和站点恢复，但是 Exchange 2013 中的站点恢复有所不同。 Exchange 2013 中的站点恢复要好得多，因为它进行了简化。 在 Exchange 2013 中进行的基础体系结构更改会显著影响站点恢复配置的恢复方面。

在 Exchange 2010 中，邮箱 (DAG) 和客户端访问（客户端访问服务器阵列）恢复绑定在一起。 如果失去所有客户端访问服务器、阵列的 VIP 或 DAG 的重要部分，则在这种情况下需要执行数据中心切换。 这是进行了良好记录并且通常很容易理解的过程，虽然需要一段时间来执行，并且需要人员干预以便开始该过程。

在 Exchange 2013 中，如果由于任何原因（例如，负载平衡器出现故障等）而失去客户端访问服务器阵列，则无需执行数据中心切换。 借助正确的配置，故障转移会在客户端级别进行，并且客户端会自动重定向到正在运行客户端访问服务器的另一个数据中心，这些正在运行的客户端访问服务器会将通信代理发送回用户的邮箱服务器，因而该邮箱服务器不会受中断影响（因为您未执行切换）。 服务会自行恢复并且您可以将精力集中于修复核心问题（例如，替换故障负载平衡器），而不是致力于恢复服务。

而且，由于进行了命名空间简化、服务器角色合并、Active Directory 站点服务器角色需求分离、客户端访问服务器阵列和 DAG 恢复分离以及负载平衡更改，因此 Exchange 2013 中存在一些更改，现在使客户端访问服务器和 DAG 恢复可以在站点间分离并自动进行，从而可在您具有三个位置时提供数据中心故障转移方案。

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

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

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

Exchange 2013 中的更改之一是使客户端可以获得多个可访问的位置。 假设客户端能够使用多个可访问的位置（Exchange 2013 中的几乎所有客户端访问协议都基于 HTTP（示例包括 Outlook、Outlook 无处不在、EAS、EWS、OWA、EAC 等），并且所有受支持的 HTTP 客户端都能够使用多个 IP 地址），因而可在客户端提供故障转移。 可以配置 DNS 以在名称解析过程中将多个 IP 地址传递给客户端。 例如，客户端会请求 mail.contoso.com 并取回两个 IP 地址（或四个 IP 地址）。 不过，客户端可以可靠地使用客户端取回的许多 IP 地址。 这使客户端的情况可显著好转，因为如果某个 IP 地址失败，则客户端可以尝试连接一个或多个其他地址。 如果客户端尝试一个地址但是该地址失败，则它会等待大约 20 秒，然后尝试列表中的下一个地址。 因此，如果失去客户端访问服务器阵列的 VIP，则客户端的恢复会在大约 21 秒后自动进行。

优势包括：

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

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

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

可以允许进行故障转移，而不必执行还原切换（有时错误地称为故障回复）。 如果失去主数据中心内的客户端访问服务器并且导致客户端中断 20 秒，则您甚至可以无需处理故障回复。 此时，您主要考虑的是修复核心问题（例如，替换故障负载平衡器）。 在该故障设备重新联机并正常运行之后，一些客户端会开始使用它，而其他客户端可以保持通过第二个数据中心运行。

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

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

第三方复制 API

Exchange 2013 还包括一个第三方复制 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 代表联系。

高可用性和站点恢复文档

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