新的高可用性和站点恢复功能

**适用于：**Exchange Server 2010

**上一次修改主题：**2009-12-08

Microsoft Exchange Server 2010 可降低部署电子邮件解决方案的成本和复杂性，并提供最高级别的服务器可用性和站点恢复功能。Exchange 2010 中新的高可用性体系结构建立在 Exchange Server 2007 中引入的本机复制功能基础上，它为高可用性和灾难恢复提供了简化的统一框架。Exchange 2010 将高可用性集成到 Exchange 的核心体系结构中，使各种规模的客户和所有部门中的客户都能够在其组织中经济地部署邮件连续性服务。

Exchange Server 2007 学习课程

Exchange 2007 通过引入新技术（如本地连续复制 (LCR)、群集连续复制 (CCR) 和备用连续复制 (SCR)）降低了高可用性成本，使站点恢复变得更加经济。但是，这种情况下仍将面临一些挑战：

• 一些管理员无力应对复杂的 Windows 故障转移群集。
• 实现高级别的运行时间可能需要高级别的管理员干预。
• 每种类型的连续复制都使用不同的方式单独管理。
• 在大型邮箱服务器上执行单个数据库的故障恢复可能导致该邮箱服务器上所有用户的服务都发生临时中断。
• 站点恢复解决方案并非完美无缺。
• 集线器传输服务器的传输转储程序功能只能在 LCR 或 CCR 环境中保护发往邮箱的邮件。如果在处理邮件时集线器传输服务器发生故障，且无法恢复，则可能导致数据丢失。

Exchange 2010 包括一些重要的核心更改，在其体系结构中深度集成了高可用性，对于所有客户而言，它的成本比 Exchange 2007 更低，更易于部署和维护。组织现在仅使用两个服务器就可以部署完全冗余的 Exchange 组织，并获得数据库级故障转移的好处。客户无需成为 Windows 故障转移群集方面的专家，就可以从自动化数据库级故障转移功能中受益。此外，还可以非常简单地将站点恢复功能添加到现有的高可用性部署。

Exchange 2007 引入了许多新的体系结构更改，从而能够为 Exchange 更快、更简单地部署高可用性和站点恢复解决方案。这些改进包括集成的安装程序体验、优化的现成配置设置和使用本机 Exchange 管理工具管理大部分高可用性解决方案的能力。

管理 Exchange 2007 高可用性解决方案仍需要管理员掌握一些群集概念，如移动网络标识和管理群集资源的概念。此外，当排除与群集邮箱服务器相关的问题时，管理员必须使用 Exchange 工具和群集工具从两个不同的源检查并关联日志和事件：一个是 Exchange，另一个是群集。

此外，还根据客户的反馈对 Exchange 2007 体系结构的两个局限性进行了重新评估和重新设计：

• 群集 Exchange 2007 服务器需要专用的硬件。在群集的节点上只能安装邮箱服务器角色。这意味着至少需要四个 Exchange 服务器才能实现一个部署的主组件（即核心服务器角色：邮箱、集线器传输和客户端访问）的完整冗余。
• 在 Exchange 2007 中，群集邮箱服务器的故障转移发生在服务器级别。因此，如果发生单个数据库故障，管理员必须将整个群集邮箱服务器故障切换到群集中的另一个节点（这将导致该服务器上所有用户短暂停机，不只是在受影响的数据库上具有邮箱的那些用户），或者在从备份还原数据库时使故障数据库上的用户保持脱机（可能持续数小时）。

邮箱恢复

Exchange 2010 已围绕“邮箱恢复”这一概念进行了重新设计，在重新设计中对体系结构进行了更改，现在可以在单个邮箱数据库级别（而非服务器级别）提供自动故障转移保护。在 Exchange 2010 中，这称为“数据库移动性”。通过上述更改以及其他数据库缓存体系结构更改，现在故障转移操作比在以前版本的 Exchange 中完成的速度更快。例如，在运行 Exchange 2007 Service Pack 2 (SP2) 的 CCR 环境中，对群集邮箱服务器进行故障转移大约需要 2 分钟。而在 Exchange 2010 环境中，对邮箱数据库进行故障转移只需 30 秒或更短的时间即可完成（从检测到发生故障时算起到装入数据库副本时为止，假定可用副本能够正常运行并使用日志重播功能更新）。数据库级故障转移的组合和更快的故障转移时间可显著改进组织的总体正常运行时间。

内置于 Exchange 2010 的邮箱恢复体系结构可以为组织及其邮件管理员提供新的好处：

• 多个服务器角色可以在能提供高可用性的服务器上共存。这使小型组织能够部署可提供邮箱数据和服务冗余的双服务器配置，同时还提供冗余的客户端访问和集线器传输服务。
• 管理员不再需要构建故障转移群集即可实现高可用性。Exchange 2010 现在将以管理员不可见的方式创建故障转移群集。与以前版本的 Exchange 群集使用 Exchange 提供的名为 ExRes.dll 的群集资源 DLL 不同，Exchange 2010 不再需要或使用群集资源 DLL。Exchange 2010 不是群集应用程序，它仅使用故障转移群集组件的一小部分（即检测信号功能和群集数据库）来提供数据库移动性。
• 部署 Exchange 之后，管理员无须卸载 Exchange 即可将高可用性添加到其 Exchange 2010 环境，随后可在高可用性配置中进行重新部署。
• Exchange 2010 提供事件流视图，该视图将来自操作系统的事件与来自 Exchange 的事件合并在一起。
• 因为 Exchange 2010 中不再有存储组对象，并且邮箱数据库可以跨所有 Exchange 2010 邮箱服务器进行迁移，所以可以非常容易地根据需要移动数据库。

有关详细信息，请参阅高可用性和站点恢复。

灵活的邮箱保护

Exchange 2010 包括几个新功能和核心更改，在正确部署和配置后，这些功能和更改可提供灵活的邮箱保护，无需进行传统的数据备份。使用 Exchange 2010 内置的高可用性功能，可以在发生灾难时最大限度地减少停机时间和数据丢失，还可以减少邮件系统的总拥有成本。通过将这些功能与其他内置功能（如合法保留）组合在一起，组织可以减少或消除对传统时间点备份的依赖和减少这些操作的成本。

除确定 Exchange 2010 是否能够脱离传统时间点备份外，我们还建议您评估当前备份基础结构的成本。尝试使用现有备份基础结构从灾难中恢复时，考虑最终用户停机和数据损失的成本。还包括硬件、安装和许可成本，以及与恢复数据和维护备份相关的管理成本。具有至少三个邮箱数据库副本的纯 Exchange 2010 环境所需的总拥有成本很可能比具有备份的环境低，具体取决于组织的需求。

有关灵活邮箱保护的详细信息，请参阅了解备份、还原和灾难恢复。

对 Exchange 早期版本的高可用性的更改

Exchange 2010 对其核心体系结构进行多处更改。Exchange 2010 将 CCR 和 SCR 的关键可用性和恢复功能组合到处理现场数据复制和非现场数据复制的单一高可用性解决方案中。可以将邮箱服务器定义为数据库可用性组 (DAG) 的一部分，从而在单个邮箱数据库级别（而不是服务器级别）提供自动恢复。每个邮箱数据库最多可以有 16 个副本。Exchange 2010 中引入了其他新的高可用性概念，如“数据库移动性”和“增量部署”。在 Exchange 2010 中还将引入没有备份和 RAID 的组织概念。

总之，邮箱服务器角色和邮箱数据库的数据和服务可用性的重要方面是：

• Exchange 2010 使用了在 Exchange 2007 中引入的同一连续复制技术的增强版本。有关详细信息，请参见此主题稍后的对 Exchange Server 2007 连续复制的更改。
• Exchange 2010 中不再有存储组，仅存在邮箱数据库、邮箱数据库副本和公用文件夹数据库。在 Exchange 管理控制台中，Exchange 数据库的主管理界面从“服务器配置”下的邮箱节点移动到了“组织配置”****下的邮箱节点。
• 某些 Windows 故障转移群集技术由 Exchange 2010 使用，但是现在完全由 Exchange 管理。管理员在部署高可用邮箱服务器时，不需要安装、生成或配置故障转移群集的任何方面。
• 每个邮箱服务器可以承载 100 个数据库，每个数据库最多可以具有 16 个副本。
• 除传输转储程序功能外，还添加了一个名为“卷影冗余”**的新集线器传输服务器功能。卷影冗余可为邮件在整个传送过程中提供冗余。该解决方案采用了类似于传输转储程序的技术。使用卷影冗余，可延迟从传输数据库中删除邮件，直到传输服务器验证该邮件的所有后续跃点已完成传递为止。在回报成功传递之前，如果任何后续跃点发生故障，系统都会将传递的邮件重新提交到该后续跃点。有关卷影冗余的详细信息，请参见了解卷影冗余。

增量部署

在以前版本的 Exchange 中，邮箱服务器角色的服务可用性是通过在 Windows 故障转移群集中部署 Exchange 实现的。若要在群集中部署 Exchange，必须首先构建故障转移群集，然后安装 Exchange 程序文件。此过程创建了一个特殊邮箱服务器，称为群集邮箱服务器（在以前版本的 Exchange 中称为 Exchange 虚拟服务器）。如果在非群集服务器上已经安装 Exchange 程序文件，并确定需要一个群集邮箱服务器，则必须使用新硬件构建一个群集，或从现有服务器中删除 Exchange，安装故障转移群集并重新安装 Exchange。

Exchange 2010 引入了增量部署的概念，您可以在安装 Exchange 之后为所有邮箱服务器和数据库部署服务和数据可用性。通过使用 Exchange 2010 中的新功能（如 DAG 和数据库副本）可实现服务和数据冗余。

数据库可用性组

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

有关 DAG 的详细信息，请参见了解数据库可用性组。

邮箱数据库副本

高可用性和站点恢复功能在 Exchange 2007 中首次引入，这些功能在 Exchange 2010 中用于创建和维护数据库副本，因此使您能够在 Exchange 2010 中实现可用性目标。Exchange 2010 还引入了数据库移动性这一新概念，它是 Exchange 托管的数据库级故障转移。

数据库移动性将数据库从服务器断开，增加了对单一数据库的支持，最多可以支持 16 个副本，并提供将数据库副本添加到数据库的本机体验。在 Exchange 2007 中，还可以使用名为数据库可移植性这一功能在服务器之间移动邮箱数据库。不过，数据库可移植性和数据库移动性之间的重要区别是，对于数据库移动性，数据库的所有副本都具有相同的 GUID。

数据库移动性的其他关键特征为：

• 因为已从 Exchange 2010 中删除存储组，所以连续复制现在在数据库级别操作。在 Exchange 2010 中，事务日志复制到一个或多个邮箱服务器，并重播到在这些服务器上存储的邮箱数据库的一个副本中。
• 故障转移是可以在数据库级别或服务器级别发生的自动激活过程。切换是可以在数据库、服务器或数据中心（站点）级别执行的手动激活过程。
• Exchange 2010 的数据库名称必须在 Exchange 组织中是唯一的。
• 使用一个或多个数据库副本配置了邮箱数据库时，所有数据库副本的完整路径在承载副本的所有邮箱服务器上必须完全相同。
• 使用感知 Exchange 的、基于卷影复制服务 (VSS) 的备份应用程序可以备份任何邮箱数据库副本（主动副本或任何被动副本）。

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

对 Exchange Server 2007 连续复制的更改

以前在 CCR 和 SCR 中提供的基本连续复制技术在 Exchange 2010 仍然保留，并且得到了改进，可以支持新的高可用性功能，如数据库副本、数据库移动性和 DAG。以下简要描述了一些新的体系结构更改：

• 因为已从 Exchange 2010 中删除存储组，所以连续复制现在在数据库级别操作。Exchange 2010 仍然使用可扩展存储引擎 (ESE) 数据库生成事务日志，并将这些事务日志复制到一个或多个其他位置，然后重播到邮箱数据库的一个或多个副本中。
• 因为由 Exchange 2007 中的 Microsoft Exchange 复制服务执行的日志重播功能已移动到 Exchange 2010 版的 Microsoft Exchange 信息存储服务 (store.exe) 中，所以与故障转移和切换相关的性能影响已不复存在（因为使用了新的数据库缓存）。发生故障转移或切换时，激活的数据库有一个随时可用的暖缓存。
• 日志传送和种子设定不再使用服务器消息块 (SMB) 进行数据传输。Exchange 2010 连续复制使用单一管理员定义的 TCP 端口进行数据传输。此外，Exchange 2010 包括一些用于数据流的网络加密和压缩的内置选项。
• 日志传送不再使用“拉入”模式（该模式通过被动副本从活动副本拉入关闭的日志文件），而使用活动副本将日志文件推送到每个配置的被动副本。
• 播种设定不再受限于仅使用数据库的活动副本。现在可以将邮箱数据库的被动副本指定为数据库副本种子设定和重新种子设定的源。
• 数据库副本仅适用于邮箱数据库。若要实现公用文件夹数据库的冗余和高可用性，我们建议使用公用文件夹复制。与 CCR 不同，公用文件夹数据库的多个副本无法存在于同一群集中，您可以使用公用文件夹复制在 DAG 中的服务器之间复制公用文件夹数据库。

Exchange 2007 连续复制中使用的几个概念在 Exchange 2010 中仍予以保留。其中包括以下概念：“故障转移管理”、“分歧”、“自动数据库装入拨号”**的使用，以及公用和专用网络的使用。

更改集线器传输和邮箱在 DAG 中共存时的路由行为

当集线器传输服务器与作为 DAG 成员的邮箱服务器共存时，为确保这两个服务器角色中的恢复功能为该服务器上的用户发送和接收的邮件提供必要的保护，已对路由行为进行了一些更改。对集线器传输服务器的角色进行了修改，如果集线器传输服务器也是 DAG 成员，并且具有本地装入的邮箱数据库的副本，现在可以尝试将本地邮箱服务器的邮件重新路由到同一站点中的另一个集线器传输服务器。添加这一额外跃点是为了将邮件放入不同集线器传输服务器上的传输转储程序中。

例如，EX1 承载集线器传输和邮箱角色，并且是 DAG 的成员。当邮件到达指向 EX1 的传输时（收件人的邮箱也在 EX1 上），该传输会将邮件重新路由到该站点中另一个集线器传输服务器（例如，EX2），并由该服务器将邮件传递到 EX1 上的邮箱。

对于 Microsoft Exchange 邮件提交服务，也进行了类似的行为更改。修改此服务之后，当邮箱和集线器传输服务器是 DAG 的成员时，就不会首先选择将邮件提交到本地集线器传输角色。在此情况下，传输的行为是跨同一 Active Directory 站点中的其他集线器传输服务器负载平衡提交请求，如果在同一站点中没有其他可用集线器传输服务器，则回退到本地集线器传输服务器。

端到端可用性

Exchange 2010 还包括许多为增加系统的端对端可用性而设计的功能。这些功能包括：

• 传输恢复
• 联机移动邮箱
• Exchange 本机数据保护
• 增量重新同步
• 第三方复制 API

传输恢复

Exchange 2007 引入了集线器传输服务器的传输转储程序功能。传输转储程序维护向收件人传递的邮件队列，收件人的邮箱位于 CCR（在 Exchange 2007 SP1 中位于 LCR）环境中。此功能旨在帮助防止数据丢失，采用的方法是为管理员提供选项，使群集邮箱服务器自动在另一个节点上联机，从而使丢失的数据有限。此方法称为有耗故障转移。发生有耗故障转移时，系统将使用其中仍然存储电子邮件的传输转储程序，将最近发送的电子邮件自动重新传递给发生故障的群集邮箱服务器上的用户。尽管此解决方案有助于减少有耗故障转移中的数据丢失，但是该解决方案只能防止站点内的数据丢失，对传输过程中的邮件不提供保护。

Exchange 2010 引入了可解决这两种问题的核心体系结构更改。因为 DAG 可以跨 Active Directory 站点扩展，所以单个邮箱数据库能够在 Active Directory 站点之间移动。由于这种设计更改，在有耗数据库故障转移时，传输转储程序重新传递请求现在发送给数据库的原始和新的 Active Directory 站点中的集线器传输服务器。

传输转储程序的一个其他重要更改是现在可以从复制管道接收反馈。当传输转储程序中的邮件已复制到所有邮箱数据库副本时，将从传输转储程序删除它们。这确保了只有非复制数据保留在传输转储程序中。

除传输转储程序功能外，还添加了一个名为“卷影冗余”**的新集线器传输服务器功能。卷影冗余可为邮件在整个传送过程中提供冗余。该解决方案采用了类似于传输转储程序的技术。使用卷影冗余，可延迟从传输数据库中删除邮件，直到传输服务器验证该邮件的所有后续跃点已完成传递为止。在回报成功传递之前，如果任何后续跃点发生故障，系统都会将传递的邮件重新提交到该后续跃点。有关卷影冗余的详细信息，请参见了解卷影冗余。

联机移动邮箱

Exchange 2010 包括使您能够以异步方式移动邮箱的新功能。在 Exchange 2007 中，当使用 Move-Mailbox cmdlet 移动邮箱时，cmdlet 同时登录到源数据库和目标数据库，并将内容从一个邮箱移动到另一个邮箱。让 cmdlet 执行移动操作存在以下几个缺点：

• 邮箱移动通常需要数小时，在移动过程中用户无法访问他们的邮箱。
• 如果关闭用于运行 Move-Mailbox cmdlet 的命令窗口，则移动会终止，并且必须从头开始重新启动。
• 用于执行该移动的计算机参与数据传输。如果管理员从其工作站运行 cmdlet，则邮箱数据会从源服务器流到管理员的工作站，然后流到目标服务器。

Exchange 2010 中的新移动请求 cmdlet 可用于执行异步移动。与 Exchange 2007 不同，该 cmdlet 不执行实际移动。该移动由 Microsoft Exchange 邮箱复制服务（在客户端访问服务器上运行的新服务）执行。New-MoveRequest cmdlet 将请求发送到邮箱复制服务。有关联机移动邮箱的详细信息，请参见了解移动请求。

Exchange 本机数据保护

对 Exchange 2010 的核心体系结构进行了几处更改，这些更改直接影响保护邮箱数据库及其包含的邮箱的方式。

一项重大更改是删除了存储组。在 Exchange 2010 中，每个数据库都与单一日志流关联，由一系列 1 MB 的日志文件表示。每个服务器可以承载最多 100 个数据库。

Exchange 2010 的另一个重要更改是数据库不再与特定的邮箱服务器密切相关。通过将数据库复制到多个不同的服务器，数据库移动性扩展了系统对连续复制的使用。这对数据库提供了更好的保护并提高了可用性。在发生故障的情况下，拥有数据库副本的其他服务器可以装入数据库。

可以将多个数据库副本驻留在多个服务器上，这意味着如果有充足的数据库副本，可以将这些副本用作备份。有关此策略的详细信息，请参见了解备份、还原和灾难恢复。

增量重新同步

Exchange 2007 引入了丢失日志恢复 (LLR) 和增量种子重新设定的概念。LLR 是 ESE 的内部组件，即使丢失或损坏一个或多个最近生成的事务日志文件，该组件也能够恢复 Exchange 邮箱数据库。即使最近生成的日志文件不可用，LLR 也能够装入邮箱数据库。LLR 的工作原理是延迟对数据库的写入操作，直到创建了指定数目的日志。LLR 会短时间延迟对数据库文件的最新更新。延迟写入的时间长度取决于生成日志的速度。

增量重新设定种子通过依靠 LLR 的延迟重播功能，在源存储组和目标存储组之间提供纠正事务日志流中分歧的能力。在分歧日志重播之后，增量重新设定种子不提供纠正数据库的被动副本中分歧的方法，这会强制需要完整的重新设定种子。

在 Exchange 2010 中，“增量重新同步”**是在以下条件下自动纠正数据库副本中分歧的功能的新名称：

• 对配置的所有数据库副本进行自动故障转移之后
• 启用新副本时并且该副本位置已经存在一些数据库和日志文件时
• 在恢复挂起的复制或重新启动 Microsoft Exchange 复制服务时

检测到活动数据库和该数据库的副本之间的分歧时，增量重新同步执行以下任务：

• 在日志文件流中进行历史搜索，查找分歧点。
• 在分歧副本上查找更改的数据库页。
• 从活动副本读取更改页，然后从活动副本复制必要的日志文件。
• 将数据库页更改应用到分歧副本。
• 在分歧副本上运行恢复，并将必要的日志文件重播到数据库副本中。

第三方复制 API

Exchange 2010 还包括一个新的第三方复制 API，使组织能够使用第三方同步复制解决方案，而不是内置的连续复制功能。有关 Exchange 2010 的合作伙伴产品的信息，请参阅 Exchange 2010 合作伙伴网站。如果您是合作伙伴，需要在第三方复制 API 上查找信息，请与 Microsoft 代表联系。

从 Exchange Server 2007 中去除的功能

Exchange 2007 和 Exchange 2007 SP1 中的以下功能在 Exchange 2010 中不再提供。表中说明了它们的替代项。