了解高可用性和站点恢复

 

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

上一次修改主题： 2016-11-28

邮箱数据库及其包含的数据是任何 Exchange 组织最重要的组件（可能是最重要的组件）之一。在 Microsoft Exchange Server 2010 中，您可以通过配置邮箱数据库以实现高可用性和站点恢复来保护邮箱数据库及其包含的数据。Exchange 2010 在提供更高级别的端到端可用性和支持较大的邮箱的同时，还可以减少部署具有高可用性和站点恢复的邮件解决方案的成本和复杂性。Exchange 2010 中新的高可用性体系结构建立在 Exchange Server 2007 中引入的本机复制功能基础上，它为高可用性和站点恢复提供了简化的统一框架。Exchange 2010 将高可用性集成到 Exchange 的核心体系结构中，使各种规模的客户和所有部门中的客户都能够在其组织中经济地部署邮件连续性服务。

若要了解与高可用性和站点恢复相关的管理任务，请查看管理高可用性和站点恢复。

目录

关键术语

Exchange Server 2010 解决方案的关键特征

数据库移动性

增量部署

数据库可用性组

邮箱数据库副本

活动管理器

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

非邮箱服务器角色的高可用性

站点恢复

端到端可用性

关键术语

下列术语适用：

• 通讯簿服务
  客户端访问服务器上为 Microsoft Outlook 客户端提供目录访问终结点的服务。

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

• 连续复制 - 文件模式
  在 Exchange 2010 的正式发布 (RTM) 版中连续复制的原始形式的名称，该形式会将关闭的事务日志文件从主动数据库副本推送到一个或多个被动数据库副本中。

• 数据库可用性组 (DAG)
  一个最多包含 16 个 Exchange 2010 邮箱服务器的组，可承载一组复制的数据库。

• 数据库移动性
  将一个 Exchange 2010 邮箱数据库复制并装入到其他 Exchange 2010 邮箱服务器的能力。

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

• Exchange 第三方复制 API
  Exchange 提供的 API，可以对数据库可用性组使用第三方同步复制而不是连续复制。

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

• 增量部署
  安装 Exchange 2010 后部署高可用性和站点恢复的能力。

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

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

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

• RPC 客户端访问服务
  客户端访问服务器上为 Microsoft Outlook 客户端提供 MAPI 终结点的服务。

• 站点恢复
  一种手动灾难恢复过程，在主数据中心不再能提供足够的服务级别以满足组织需求时，用于激活替代或备用的数据中心。此外还包括重新激活已恢复、还原或重新创建的主数据中心的过程。您可以使用 Exchange 2010 中的内置特性和功能配置邮件解决方案以实现高可用性并启用站点恢复。

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

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

返回顶部

Exchange Server 2010 解决方案的关键特征

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

• Windows 故障转移群集可能会因其复杂性而令人产生混淆。

• 实现高级别的运行时间可能需要高级别的管理员干预。

• 每种类型的连续复制都使用不同的方式单独管理。

• 在大型邮箱服务器上执行单个数据库的故障恢复可能导致该邮箱服务器上所有用户的服务都发生临时中断。

• 集线器传输服务器的传输转储程序功能只能在 CCR 环境中保护发往邮箱的邮件。如果在处理邮件时集线器传输服务器发生故障，且无法恢复，则可能导致数据丢失。

Exchange 2010 包括一些重要的核心更改，在其体系结构中集成了高可用性，使其与 Exchange 的早期版本相比成本更低、更易于部署和维护。Exchange 2010 包括一个适用于高可用性和站点恢复的新统一平台。

对 Exchange 2010 进行了重要的核心改进后，使用连续复制时建议的最大邮箱数据库大小已从 Exchange 2007 中的 200 GB 增加为 Exchange 2010 中的 2 TB。伴随着更多公司意识到大型邮箱中的较大值（从 2 GB 到 10 GB），引人注意的更大的数据库大小迅速变成现实。支持较大的数据库意味着弃用旧版恢复机制，如备份和还原，而采用更新、更快的保护形式，如数据复制和服务器冗余。最终，您的邮箱数据库的大小取决于您在 Exchange 2010 规划过程中派生的因素的数量。有关邮箱和邮箱服务器的详细规划指南，请参阅邮箱服务器存储设计。

Exchange 2010 将 CCR 和 SCR 的关键可用性和恢复功能组合到处理现场数据复制和非现场数据复制的单一解决方案中。可以将邮箱服务器定义为 DAG 的一部分，从而在邮箱数据库级别（而不是服务器级别）提供自动恢复。Exchange 2010 中引入了其他新的高可用性概念，如“数据库移动性”和“增量部署”。

返回顶部

数据库移动性

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

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

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

• 群集 Exchange 2007 服务器需要专用的硬件。在群集的节点上只能安装邮箱服务器角色。这意味着至少需要四个 Exchange 服务器才能实现一个部署的主组件（例如核心服务器角色：邮箱、集线器传输和客户端访问）的完整冗余。

• 在 Exchange 2007 中，群集邮箱服务器的故障转移发生在服务器级别。因此，如果发生单个数据库故障，管理员必须将整个群集邮箱服务器故障切换到群集中的另一个节点（这将导致该服务器上所有用户短暂停机，不只是在受影响的数据库上具有邮箱的那些用户），或者在从备份还原数据库时使故障数据库上的用户保持脱机（可能持续数小时）。

Exchange 2010 在设计时采用了数据库移动性的概念设计。通过将数据库复制到组合到一起的多个不同服务器，数据库移动性扩展了系统对连续复制的使用。该模型对数据库提供了更好的保护并提高了可用性。在此模型中，在邮箱数据库级别（而非服务器级别）提供自动故障转移保护和手动切换控制。

在发生故障的情况下，拥有数据库副本的其他服务器可以装入数据库。通过上述更改以及其他体系结构更改，现在故障转移操作比在以前版本的 Exchange 中完成的速度更快。例如，在运行 Exchange 2007 Service Pack 1 的 CCR 环境中，对群集邮箱服务器进行故障转移大约需要 2 分钟（假设在其 IP 地址未更改的群集邮箱服务器中出现站点内故障）。而在 Exchange 2010 环境中，对邮箱数据库进行故障转移只需在 30 秒内即可完成（从检测到发生故障时算起到装入数据库副本时为止，假定副本能够正常运行并使用日志重播功能更新）。数据库级故障转移的组合和更快的故障转移时间可改进组织的总体正常运行时间。

返回顶部

增量部署

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

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

返回顶部

数据库可用性组

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

Exchange 2007 引入了一种内置数据复制技术，名为连续复制。连续复制有以下三种形式：本地、群集和备用，大大减少了部署高可用性 Exchange 基础结构的成本，并提供了对 Exchange 的以前版本来说具有明显改进的部署和管理体验。但是，即使有了这些成本节省和改进，运行高可用性 Exchange 2007 基础结构仍然需要大量时间和专业技能，因为 Exchange 和 Windows 故障转移群集之间的集成不是无缝的。此外，客户需要一种更简单的方法将其电子邮件数据复制到远程位置，以保护其 Exchange 环境不受站点级灾难的危害。

Exchange 2010 使用 Exchange 2007 中提供的同一连续复制技术。Exchange 2010 将现场数据复制 (CCR) 和非现场数据复制 (SCR) 组合到名为“数据库可用性组”(DAG) 的单一框架中。将服务器添加到 DAG 后，您可以以递增的方式添加复制的数据库副本（最多添加 16 个），Exchange 2010 在这些副本之间自动切换，以保持可用性。

与 Exchange 2007（其中群集邮箱服务器要求使用专用硬件）不同，DAG 中的邮箱服务器可以承载其他 Exchange 角色（客户端访问、集线器传输和统一消息），仅使用两台服务器即可提供 Exchange 服务和数据的完整冗余。

这种新的高可用性体系结构还简化了从各种故障（磁盘级别、服务器级别和数据中心级别）恢复的过程，并且可以在各种存储类型上部署此体系结构。

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

返回顶部

邮箱数据库副本

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

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

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

例如，如果 DAG 中的主动数据库由于基础存储故障而失败，活动管理器会通过将故障转移到 DAG 中的其他邮箱服务器上的数据库副本来执行自动恢复。如果数据库不符合自动装入条件而无法自动装入，您可以手动执行数据库故障转移。

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

返回顶部

活动管理器

在 Exchange 2007 和以前版本中，Exchange 使用群集资源管理模型来安装、实现和管理邮箱服务器高可用性解决方案。一直以来，构建高可用邮箱服务器首先涉及构建 Windows 故障转移群集，然后在群集模式下运行 Exchange 安装程序。在此模式下，将注册 Exchange 群集资源 DLL 文件 exres.dll，并允许创建群集邮箱服务器（在旧版本中称为 Exchange 虚拟服务器）。部署旧版共享存储群集或单一副本群集时，形成故障转移群集前后及形成群集邮箱服务器和存储组之后需要执行配置存储的其他步骤。

Exchange 2010 包括一个新组件，称为“活动管理器”，它提供了一种功能，该功能可替换通过其与 Exchange 中的群集服务集成提供的资源模型和故障转移管理功能。有关 Active Manager 的详细信息，请参阅了解活动管理器。

返回顶部

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

对 Exchange 2010 的核心体系结构进行了几处更改，这些更改直接影响配置 Exchange 以实现高可用性以及执行站点恢复的方式。一项重大更改是删除了群集邮箱服务器并使用了 Windows 故障转移群集资源模型。其他重要更改包括数据库的全局化以及在 Exchange 2007 中首次引入的内置连续复制技术的增强功能。

删除群集邮箱服务器

在 Exchange 2010 中，Exchange 不再是群集应用程序，并且群集资源模型不再用于 Exchange 高可用性。Exres.dll 及其提供的所有 Exchange 群集资源也不再存在，包括群集邮箱服务器。而 Exchange 2010 使用其自己的内部高可用性模型。Windows 故障转移群集的一些组件仍在使用，但是现在 Exchange 2010 已将其集成到其他功能。

数据库的全局化

在 Exchange 2010 中，每个数据库都与单一日志流关联，由一系列按顺序命名的 1 MB 大小的日志文件表示。存储组的概念也已从 Exchange 2010 中删除。由于这些更改，Exchange 数据库拥有了专用的日志流，不再与其他数据共享日志流。

与在 Exchange 的以前版本中不同，数据库不再与特定的邮箱服务器密切相关。此外，数据库不再由其所驻留的邮箱服务器来进行标识，并且服务器名称也不再是数据库标识的一部分。由于这些更改，数据库现在是 Active Directory 和每个 Exchange 组织中的全局对象。现在，在使用 Exchange 管理控制台时，从“组织配置”节点下的“邮箱”节点来管理数据库。

每个邮箱服务器最多可以承载 100 个数据库（主动数据库和被动数据库的总和）。数据库的总数等于服务器上主动数据库和被动数据库之和。恢复数据库不受 100 个数据库的限制。

Exchange 2010 RTM 中对连续复制的更改

Exchange 2010 也提供了 Exchange 2007 中引入的连续复制技术。然而，该功能已得到很大改进，可支持新的高可用性功能，并提高了可伸缩性。其中一些体系结构更改包括：

• 由于已从 Exchange 2010 中删除存储组，因此现在连续复制在数据库级别上进行。Exchange 2010 仍然使用可扩展存储引擎 (ESE) 数据库生成事务日志，并将这些事务日志复制到一个或多个其他位置，然后重播到一个或多个邮箱数据库副本中。每个邮箱数据库最多可以拥有 16 个副本。

• 日志传送不再使用服务器消息块 (SMB) 和 Windows 文件系统通知。日志传送不再使用“拉入”模式（该模式通过被动副本从活动副本拉入关闭的日志文件），相反，被动副本使用基于 TCP 的通知来通知主动副本被动副本需要哪些日志文件。然后，主动副本通过 TCP 套接字将日志文件推送到每个配置的被动副本。

• Exchange 2010 连续复制使用一个管理员定义的 TCP 端口进行数据传输。此外，Exchange 2010 包括一些用于数据流的网络加密和压缩的内置选项。

• 播种设定不再受限于仅使用数据库的活动副本。现在可以将邮箱数据库的被动副本指定为数据库副本种子设定和重新种子设定的源。

• 数据库副本仅适用于邮箱数据库。若要实现公用文件夹数据库的冗余和高可用性，我们建议使用公用文件夹复制。与 CCR 不同，公用文件夹数据库的多个副本无法存在于同一群集中，您可以使用公用文件夹复制在 DAG 中的服务器之间复制公用文件夹数据库。

• 在 Exchange 2007 中，Microsoft Exchange 复制服务负责将日志重播到被动数据库副本中。激活被动副本后，Microsoft Exchange 信息存储服务装入数据库时，Microsoft Exchange 复制服务由于重播活动而构建的数据库缓存将丢失。这会将数据库缓存置于一种称为“冷状态”的状态中。在此期间，数据库缓存（用于缓存读/写操作）的大小很小（冷）。因此，其减少读取 I/O 操作的能力显著削弱。在 Exchange 2010 中，以前由 Microsoft Exchange 复制服务执行的被动副本重播功能已移动到 Microsoft Exchange 信息存储服务中。因此，热数据库缓存出现，并在发生故障转移或切换后立即可用。

Exchange 2007 连续复制中使用的几个概念在 Exchange 2010 中仍予以保留。其中包括故障转移、分歧的概念，包括自动数据库装入拨号的使用以及复制和客户端访问 (MAPI) 网络的使用。

Exchange 2010 SP1 中对连续复制的更改

在 RTM 版本的 Exchange 2010 和所有版本的 Exchange Server 2007 中，通过将主动数据库副本生成的日志文件副本传送给被动数据库副本来运行连续复制。从 Exchange 2010 SP1 开始，这种形式的连续复制被称为“连续复制 - 文件模式”。SP1 也引入了新形式的连续复制，称为“连续复制 - 块模式”。在块模式中，随着将每次更新写入主动数据库副本的主动日志缓冲区，也会将其传送到每个被动邮箱副本上的日志缓冲区。如果日志缓冲区已满，每个数据库副本将在生成序列中构建、检查并创建下一个日志文件。如果故障对主动副本造成影响，则将使用大多数或全部最新更新来更新被动副本。主动副本会在复制完成之前就开始排除复制问题对客户端体验的影响。

块模式明显减少了从对主动副本做出更改到更改复制到被动副本之间的时间延迟。除了复制每个日志文件写入，块模式还更改被动副本的激活过程。如果发生故障时副本处于块模式，系统会使用激活过程中所有可用的部分日志内容。这样可避免主动副本上的当前日志文件成为单一故障点。

操作的初始模式始终为文件模式。仅当文件模式下连续复制为最新时块模式才会处于活动状态。日志复制程序自动执行切换进入块模式和从块模式切换出的操作。当被动副本请求当前日志文件时，表明连续复制为最新（复制队列长度为 0），系统应自动从文件模式切换为块模式。

可以通过监视 MSExchange Replication 性能对象下的 Continuous replication – block mode Active 性能计数器来确定被动数据库副本是否处于块模式。对于此计数器，每个数据库副本都有其自己的实例。被动副本处于块模式时该计数器值设置为 1，而被动副本处于文件模式时则设置为 0。还可以使用 Get-Counter 或 Get-WMIObject cmdlet 确定此计数器的值，如以下示例中所示：

Get-Counter -ComputerName <DAGMemberName> -Counter "\MSExchange Replication(*)\Continuous replication - block mode Active"
Get-WMIObject -ComputerName <DAGMemberName> Win32_PerfRawData_MSExchangeReplication_MSExchangeReplication | Where-Object {$_.ContinuousReplicationBlockModeActive -eq "1"} | Where-Object {$_.name -ne "_total"} | format-table Name,ContinuousReplicationBlockModeActive

Exchange 2007 中对传输垃圾站的更改

Exchange 2010 集线器传输服务器角色包括一种称为传输垃圾站的功能，该功能在 Exchange 2007 中首次引入。该传输垃圾站旨在帮助防止数据丢失，采用的方法是维护其邮箱受 CCR 或 LCR 保护的用户最近收到的所有电子邮件的队列。如果在这些环境中发生有耗故障，传输垃圾站会自动恢复通常由于此故障而丢失的大批数据。

传输垃圾站仅用于复制的邮箱数据库。它不会保护发送到公用文件夹的邮件，也不会保护发送给未复制的邮箱数据库中的收件人的邮件。特定邮箱数据库的传输垃圾站队列位于包含 DAG 的 Active Directory 站点中的所有集线器传输服务器上。

在 Exchange 2007 中，邮件将保留在传输垃圾站中，直到达到管理员定义的时间限制或大小限制。在 Exchange 2010 中，现在传输垃圾站会从复制管道接收反馈来确定已传递和复制的邮件。当邮件通过集线器传输服务器传递到 DAG 中的复制邮箱数据库时，副本会保留在传输队列 (mail.que) 中，直到代表邮件的事务日志已成功复制到邮箱数据库的所有副本并通过了这些副本的检查。在日志被复制到所有数据库副本并通过其检查后，会从传输垃圾站中将这些日志中的邮件截断。此操作通过仅保留其事务日志尚未复制的邮件副本，会使传输垃圾站队列更小。

每个 DAG 的活动管理器跟踪每个被动数据库副本上上次日志检查时间的值。集线器传输服务器上运行的活动管理器客户端从 DAG 的备用活动管理器 (SAM) 获取此信息，并将此信息转换为基于时间的水印。然后，集线器传输服务器将传输转储程序中邮件的传递时间与该水印进行比较。如果邮件的传递时间早于水印，则从传输转储程序中截断该邮件。

传输垃圾站也已增强为说明对邮箱服务器角色进行的更改，这些更改可以使单个邮箱数据库在 Active Directory 站点之间移动。DAG 可以扩展到多个 Active Directory 站点，因此，一个 Active Directory 站点中的单个邮箱数据库可以故障转移到另一个 Active Directory 站点。发生这种情况时，会将任何传输垃圾站重新传递请求发送到这两个 Active Directory 站点：原始站点和新站点。

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

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

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

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

返回顶部

非邮箱服务器角色的高可用性

集线器传输、边缘传输、客户端访问和统一消息服务器角色的高可用性是通过服务器冗余、负载平衡、域名系统 (DNS) 轮循机制以及主动服务器、服务和基础结构管理的结合实现的。通常，通过使用下列策略和技术，可以实现客户端访问服务器角色、集线器传输服务器角色、边缘传输服务器角色和统一消息服务器角色的高可用性：

• 边缘传输 可以部署多个边缘传输服务器，并使用多个 DNS MX 资源记录来平衡这些服务器的活动负载。您也可以使用网络负载平衡 (NLB) 为边缘传输服务器提供负载均衡和高可用性。

• 客户端访问   可以使用 NLB 或基于第三方硬件的网络负载平衡设备，以实现客户端访问服务器的高可用性。

• 集线器传输 可以部署多个集线器传输服务器，以实现内部传输高可用性。在集线器传输服务器角色中按下列方式设计了弹性机制：

  • 集线器传输服务器到集线器传输服务器（组织内）   组织内集线器传输服务器到集线器传输服务器的通信可在目标 Active Directory 站点中的可用集线器传输服务器之间自动实现负载平衡。

  • 邮箱服务器到集线器传输服务器（Active Directory 内站点）   邮箱服务器上的 Microsoft Exchange 邮件提交服务可在同一 Active Directory 站点中的所有可用集线器传输服务器之间自动实现负载平衡。

  • 统一消息服务器到集线器传输服务器   统一消息服务器可对同一 Active Directory 站点中所有可用集线器传输服务器之间的连接自动实现负载平衡。

  • 边缘传输服务器到集线器传输服务器   边缘传输服务器自动实现至向其订阅边缘传输服务器的 Active Directory 站点中所有集线器传输服务器的入站 SMTP 流量的负载平衡。

  对于其他冗余（例如，需要 SMTP 中继的应用程序），可以创建 DNS 记录（例如 relay.company.com），分配 IP 地址，然后使用硬件负载平衡器将该 IP 地址重定向到多个集线器传输服务器。还可以对集线器传输服务器上的客户端连接器使用 NLB。使用硬件负载平衡器时，需要确认组织内的  流量没有经过硬件负载平衡器，因为组织内流量使用内置的负载平衡算法（如前所述）。

• 统一消息   通过部署单个拨号计划中两个或更多统一消息服务器，可使统一消息部署更容易恢复。统一消息支持的 IP 语音 (VoIP) 网关可配置为以轮循机制方式将呼叫路由到统一消息服务器。此外，这些网关还可以检索 DNS 中拨号计划的服务器列表。无论哪种情况，VoIP 网关都将向统一消息服务器发出呼叫，如果未接受呼叫，则该呼叫将提交给建立呼叫时提供冗余的另一台服务器。

返回顶部

站点恢复

Exchange 2010 包括用于高可用性和站点恢复的统一平台。通过综合使用 Exchange 2010 中的本机站点恢复支持和正确的规划，可以迅速激活第二个数据中心，从而服务于发生故障的数据中心的客户端。数据中心或站点故障的管理方式不同于可能引起服务器或数据库故障转移的故障类型的管理方式。在高可用性配置中，自动恢复将由系统启动，故障通常会使邮件系统处于全功能状态。相比之下，数据中心故障被认为是灾难恢复事件。必须手动执行和完成恢复才能还原客户端服务并结束中断。您执行的过程称为“数据中心切换”。与很多灾难恢复方案一样，数据中心切换的前期规划和准备工作可简化恢复过程并缩短中断的持续时间。

有关规划和部署站点恢复的详细信息，请参阅规划高可用性和站点恢复、部署高可用性和站点恢复和数据中心切换。

返回顶部

端到端可用性

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

• 卷影冗余

• 联机移动邮箱

• 灵活的邮箱保护

• 增量重新同步

• 第三方复制 API

卷影冗余

除前面介绍的传输转储程序和路由行为改进外，还添加了一个名为“卷影冗余”的新集线器传输服务器功能。卷影冗余可为邮件在整个传送过程中提供冗余。该解决方案涉及一项类似于传输转储程序的技术。使用卷影冗余，可延迟从传输数据库中删除邮件，直到传输服务器验证该邮件的所有后续跃点已完成传递为止。如果在报告成功传递之前任何下一跃点失败，则会重新提交该邮件，以便传递到该下一跃点。有关卷影冗余的详细信息，请参见了解卷影冗余。

联机移动邮箱

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

• 邮箱移动通常需要数小时，在移动过程中用户无法访问他们的邮箱。

• 如果关闭用于运行 Move-Mailbox cmdlet 的命令提示符窗口，则移动会终止，并且必须重新启动。

• 用于执行该移动的计算机参与数据传输。如果管理员从其工作站运行 cmdlet，则邮箱数据会从源服务器流到管理员的工作站，然后流到目标服务器。

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

灵活的邮箱保护

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

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

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

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

增量重新同步

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

Exchange 2007 也引入了增量种子重新设定的概念，它通过依靠丢失日志弹性的延迟重播功能，在源存储组和目标存储组之间提供纠正事务日志流中的分歧的能力。在分歧日志重播之后，增量重新设定种子不提供纠正数据库的被动副本中分歧的方法，这会强制需要完整的重新设定种子。与 Exchange 2007 不同，Exchange 2010 中丢失任何数量的日志都不需要完整的重新设定种子。

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

• 对配置的所有数据库副本进行自动故障转移之后

• 启用新副本时并且该副本位置已经存在一些数据库和日志文件时

• 在恢复挂起的复制或重新启动 Microsoft Exchange 复制服务时

由于这些更改，丢失日志弹性现在已硬编码到所有 Exchange 2010 邮箱数据库的一个日志文件中。

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

• 在日志文件流中进行历史搜索，查找分歧点。

• 在分歧副本上查找更改的数据库页。

• 从活动副本读取更改页，然后从活动副本复制必要的日志文件。

• 将数据库页更改应用到分歧副本。

• 在分歧副本上运行恢复，并将必要的日志文件重播到数据库副本中。

第三方复制 API

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

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

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

如果您是正在寻找有关第三方 API 的信息的合作伙伴，请与您的 Microsoft 代表联系。有关 Exchange 2010 的合作伙伴产品的信息，请参阅 Microsoft Exchange Partners（英文）网站。

返回顶部

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