如下图所示，在 Exchange 2007 SP1 中，CCR 使用两台加入运行 Windows Server 2003 Service Pack 2 或 Windows Server 2008 的单个故障转移群集的计算机（称为“节点”）。故障转移群集中的节点驻留单个群集邮箱服务器。当前正在运行群集邮箱服务器的节点称为“主动”节点，未运行群集邮箱服务器、但是属于该群集且为连续复制目标的节点称为“被动”节点。由于计划维护中断和未计划中断所致，在故障转移群集的整个生存期内将节点称为主动或被动节点的标志将多次更改。

CCR 的基本部署

故障转移群集是使用群集服务以及一种特定类型的群集仲裁模型构建的：

• 对于 Windows Server 2008，推荐的仲裁称为“多数节点和文件共享”仲裁。有关如何为使用“多数节点和文件共享”仲裁模型配置故障转移群集的详细步骤，请参阅如何配置多数节点和文件共享仲裁。
  
• 对于 Windows Server 2003，推荐的仲裁称为“文件共享见证的多数节点集 (MNS) 仲裁”。此仲裁模型在 Windows Server 2003 Service Pack 2 (SP2) 中可用。它在 Windows Server 2003 SP1 的一个修补程序（在 Microsoft 知识库文章 921181 可用于向基于 Windows Server 2003 Service Pack 1 的服务器群集添加文件共享见证功能和可配置的群集检测信号功能的更新已推出中进行了介绍）中也是可用的；但是，Exchange 2007 SP1 需要 Windows Server 2003 Service Pack 2。
  

上述两种仲裁模型都将第三台计算机上的文件共享用作见证。在这些仲裁模型中，使用第三台计算机上的文件共享来避免群集中出现“网络分区”，该情形也称为“网络分区症状”。在指定用于承载内部群集通信的所有网络失败，且节点无法收到彼此的检测信号时，就会发生“网络分区症状”。始终要求两个节点和文件共享中的多数可用并处于交互状态，使群集邮箱服务器能够正常工作，这样即可防止“网络分区症状”。多数计算机正在通信时，就可以说群集拥有“仲裁”。文件共享见证的文件共享可以驻留在任何运行 Windows Server 的计算机上。不要求驻留文件共享的 Windows Server 操作系统的版本与 CCR 环境的操作系统匹配。但是，建议使用包含群集邮箱服务器的 Active Directory 目录服务站点中的集线器传输服务器驻留文件共享，因为这允许消息管理员保持对文件共享的控制。

注意：
文件共享见证所用的文件共享不能驻留在分布式文件系统 (DFS) 环境中。

文件共享见证使用群集外部的计算机上的文件共享作为两个群集节点活动的见证。两个节点使用该见证来跟踪控制群集的节点。只有两个节点无法相互通信时，才需要使用记录板。请考虑一个由 Node1 和 Node2 组成的双节点群集邮箱服务器。在此示例中，Node1 是可以控制记录板的节点，因此可以控制群集并使群集邮箱服务器联机。如果 Node2 正常运行，但是无法与 Node1 进行通信，Node2 将尝试控制记录板，但是失败。Node2 无法控制记录板，这意味着它不会使群集邮箱服务器联机。

当两个节点可以相互进行交互时，则不需要记录板，记录板可以脱机。但是，以后任何一个节点出现故障时，如果文件共享见证不可用，群集邮箱服务器将无法联机。

文件共享只会保持前面所述的状态。因此，所有群集配置信息均在两个节点之间交换。了解这一点非常重要，因为这意味着如果 Node1 可用而 Node2 不可用，Node2 在与 Node1 进行通信之前，即使其可以与文件共享见证进行通信，也无法使用。

文件共享见证支持定期对文件共享见证进行访问检查。如果访问检查失败，将生成一个事件。可以通过监视系统检测、收集和报告该事件。这样，操作人员可以在问题出现第二次并发故障而造成中断之前解决该问题。

在下列情况下访问文件共享：

• 群集节点联机并且只有一个群集节点可用时。
  
• 网络连接问题使以前可以访问的节点无法与群集进行通信时。
  
• 群集节点离开群集时。
  
• 定期进行验证。该频率是可进行配置的。
  

因为上述原因，文件共享的负担很轻。因此，一台服务器可以为多个 CCR 环境提供文件共享。但是，每个 CCR 环境应该在此服务器上具有自己的专用文件夹和共享。

文件共享见证的注意事项

事务日志复制和重播用于复制更改的数据并更新被动副本的数据库。复制利用了可扩展存储引擎 (ESE) 所产生的更改历史。此更改历史以固定大小为 1 MB 的日志文件序列来表示。在生成每个日志文件时，复制功能会将日志文件复制到被动节点。对于联机数据库来说，复制机制是异步的。当日志到达被动节点时，会检查日志是否损坏，然后将其重播到被动节点上所存储的数据库副本中。重播过程将对被动节点的数据库执行更改日志所描述的更改，这将使被动节点的数据库与生产数据库匹配，但有轻微的时间滞后。

由于在节点间复制了数据，因此，可以在任一群集节点上运行群集邮箱服务器。由于一个节点的计划中断和故障不会导致群集邮箱服务器发生扩展中断，因此该功能提供了更好的可用性。此外，一个节点上存储的服务中断不会影响另一个节点和群集邮箱服务器的可用性。假定文件共享仍可用并且可以与被动节点进行通信，则主动节点的中断将使群集邮箱服务器移动到其余节点并继续运行。

在 CCR 环境中，主动节点上的事务日志文件的文件夹使用标准 Windows 文件共享进行共享。存储组的对象全局唯一标识符 (GUID) 用作共享名，并且将美元符号 ($) 添加到共享的结尾。被动节点上的 Microsoft Exchange 复制服务连接到主动节点上的共享，并使用服务器消息块 (SMB) 协议复制（或请求）日志文件。然后，被动节点验证日志文件并将其重播到被动节点上的数据库副本中。

注意：
事务日志文件复制的 SMB 通信未加密。如果需要，可以使用 Internet 协议安全性 (IPsec) 对此通信进行加密。只有事务日志文件复制使用 SMB 协议进行。使用 ESE 备份应用程序编程接口 (API) 重新设定被动副本的种子，这种通信未进行加密。如果需要，可使用 IPsec 加密此数据。

冗余群集网络上的连续复制

在 Microsoft Exchange Server 2007 的正式发布 (RTM) 版本中，CCR 环境中的所有事务日志文件复制和种子设定都发生在公用网络上。此配置具有下列限制：

• 如果被动节点不可用达几个小时，可能会产生大量需要转输的日志。应该在被动节点可用时应尽可能快地移动这些日志。通过公用网络复制日志，日志的移动会与客户端通信争用资源。这将影响客户端通信并使重新同步变慢。
  
• 在公用网络出现故障时，即使日志数据可用，故障转移也会丢失数据。
  
• 使用孤立的网络进行日志通信时，可以为邮件数据提供安全性而无需使用加密，也不会引起与其相关的性能损失。
  
• 在某些情况下，可能出现日志风暴。出现日志风暴时，系统会遇到不同寻常的高复制负担。如果日志数据必须在用于和客户端进行通信的网络上进行通信，可能会导致客户端资源不足。
  

所有这些问题并非都会以相同频率出现。但是，由于被动节点会因定期维护活动而脱机，第一个问题实际上肯定没几个月就会发生一次。

Exchange 2007 SP1 允许管理员在群集中创建一个或多个混合网络（混合网络是支持内部群集检测信号通信和客户端通信的群集网络）来进行日志传送，最大限度地减少了上述问题的影响。Exchange 2007 SP1 还允许管理员指定用于种子设定的特定混合网络。

注意：
用于日志传送和种子设定的群集网络必须配置为混合网络。混合网络是为群集（检测信号）和客户端访问通信而配置的任何群集网络。此外，在使用连续复制主机名配置的网络适配器上，管理员必须清除“高级 TCP/IP”属性对话框中的“在 DNS 中注册此连接的地址”复选框，并在每个节点上使用静态 DNS 项或主机文件项，以便每个节点可以对新创建的主机名进行名称解析。网络适配器使用的 DNS 服务器可以位于公用或专用网络上；但是，无论其位置如何，它必须可以被两个节点访问，以便可以进行主机名解析。此外，在 Windows Server 2008 上，用于日志传送或种子设定的网络适配器要求启用 NetBIOS。

支持在混合网络上进行日志文件复制是使用一个称为 Enable-ContinuousReplicationHostName 的新 cmdlet 来配置的。与此类似，关闭此功能使用 Disable-ContinuousReplicationHostName cmdlet 来完成。

群集邮箱服务器位于 CCR 环境中之后，管理员可以在群集的两个节点上运行 Enable-ContinuousReplicationHostName 并指定其他 IP 地址和主机名，之后将在与每个节点相关的专用群集组中创建这些 IP 地址和主机名。执行此任务之后，Microsoft Exchange 复制服务将在成功配置和确认新网络正常运行之后立即开始使用新创建的网络进行日志复制。如果创建了多个新网络，Microsoft Exchange 复制服务将随机从中选择一个网络。如果指定的网络不可用，Microsoft Exchange 复制服务将自动开始使用其他复制网络，如果这些网络都不可用，它将在五分钟内开始使用公用网络进行日志传送。(（Microsoft Exchange 复制服务每五分钟进行一次网络检测。）当首选复制网络重新可用时，Microsoft Exchange 复制服务将自动恢复为使用该网络进行日志传送。

有关这些 cmdlet 的详细信息，请参阅 Enable-ContinuousReplicationHostName 和 Disable-ContinuousReplicationHostName。

支持在冗余群集网络上进行种子设定是使用 Update-StorageGroupCopy cmdlet（Exchange 2007 SP1 中已对其进行更新，包含了一个称为 DataHostNames 的新参数）进行配置的。此参数用来指定要进行种子设定的群集网络。有关 Exchange 2007 SP1 中对 Update-StorageGroupCopy cmdlet 所做更改的详细信息，请参阅 Update-StorageGroupCopy。

为连续复制创建群集网络之后，可以使用 Get-ClusteredMailboxServerStatus cmdlet 来查看已经为连续复制活动所启用的群集网络的更新信息。新的输出详细信息包括：

• OperationalReplicationHostNames:{Host1,Host2,Host3}
  
• FailedReplicationHostNames:{Host4}
  
• InUseReplicationHostNames:{Host1,Host2}
  

有关 Exchange 2007 SP1 中对 Get-ClusteredMailboxServerStatus cmdlet 所做更改的详细信息，请参阅 Get-ClusteredMailboxServerStatus。

之后，通过称为“传输 Dumpster”的中心传输服务器功能自动恢复在自动恢复期间丢失的大批数据。特定数据库的传输转储程序可能位于包含群集邮箱服务器的 Active Directory 站点中的所有集线器传输服务器上。当邮件经由集线器传输服务器传递到 CCR 环境中的群集邮箱服务器时，在经过复制窗口之前，会将副本保留在传输队列 (mail.que) 中。传输 Dumpster 是 CCR 部署必需的组件。传输 Dumpster 利用环境中的冗余回收一些受故障转移影响的数据。具体地说，中心传输服务器维护最近传递邮件的队列。此队列受邮件保留时间和占用的总空间的约束。进行无损故障转移时，群集邮箱服务器上的 CCR 自动请求 Active Directory 站点中的每台中心传输服务器重新提交传输转储程序队列中的邮件。信息存储自动删除重复的邮件，并重新传递丢失的邮件。

传输转储程序是对 CCR 启用的，在 Exchange 2007 SP1 中还是对本地连续复制 (LCR) 启用的。传输转储程序不是对 SCR 或单一副本群集 (SCC) 启用的。对于 CCR 来说，电子邮件保留在传输转储程序中的必要条件是：至少有一个收件人的邮箱在 CCR 环境中的群集邮箱服务器上，或者（在 SP1 中）在对 LCR 启用的邮箱数据库上。

传输垃圾站旨在帮助防止数据丢失，采用的方法是为管理员提供配置 CCR 的选项，使群集邮箱服务器自动在另一个节点上联机，从而使丢失的数据有限。发生这种情况时，系统将利用仍存储这些电子邮件的传输垃圾站，自动传递最近发送给此服务器上的用户的所有电子邮件。在大多数情况下，这样做有助于防止数据丢失。在 CCR 环境中，站点中所有集线器传输服务器上的传输转储程序发出的重新传递请求将自动执行。在 Exchange 2007 RTM 中，重试间隔被硬编码为七天。在 Exchange 2007 SP1 中，重试间隔等于为 MaxDumpsterTime 设置的值。在 LCR 环境中，站点中所有集线器传输服务器发出的重新传递请求将作为 Restore-StorageGroupCopy 任务的一部分进行。

传输 Dumpster 不能减少数据丢失的情况包括：

• 处于联机模式的任何 Microsoft Outlook 客户端的草稿文件夹。
  
• 约会、联系人更新、属性更新、任务和任务更新。
  
• 从客户端传输到中心传输服务器的传出邮件。其中有一个时段，电子邮件只存在于发件人的邮箱服务器上。
  

Exchange 2007 SP1 中添加了几个新的用户界面元素，它们增强了高可用性功能的管理体验，其中包括 CCR。这些改进包括：

• 传输垃圾站用户界面   已经向“组织配置”工作区域下的“集线器传输”节点添加了新的“全局设置”选项卡。此选项卡包含一个“传输设置属性”页，它可用于配置组织的传输垃圾站设置：
  
  • 每个存储组的最大大小(MB)   指定每个存储组的传输垃圾站队列的最大大小。
    
  • 最长保留时间(天)   指定电子邮件可在传输垃圾站队列中保留的时间。
    
• 连续复制   Exchange 管理控制台中添加了其他用户界面控件，管理员可以利用其管理控制台挂起、恢复、更新和还原连续复制。这些控件与使用下列 Exchange 命令行管理程序 cmdlet 是等效的：
  
  • Suspend-StorageGroupCopy
    
  • Resume-StorageGroupCopy
    
  • Update-StorageGroupCopy
    
  • Restore-StorageGroupCopy
    
  您可以在 LCR 环境和 CCR 环境中使用这些 cmdlet 及相应的 Exchange 管理控制台任务来管理连续复制。
  

Exchange 2007 SP1 还引入了许多旨在增强 Exchange 2007 可管理性的更改。这些更改改进了 Exchange 2007 RTM 中的群集报告功能，并包含为主动监视连续复制环境而设计的其他功能。具体来说，上述更改和增强功能已解决了 Get-StorageGroupCopyStatus cmdlet 存在的已知缺陷，并且还引入了一个新的名为 Test-ReplicationHealth 的 cmdlet，并为传输垃圾站所遮盖的窗口部分提供了更大的可视性。

在 Exchange 2007 RTM 中，有以下几种情况，Get-StorageGroupCopyStatus 和连续复制性能计数器所报告的状态不准确或存在错误：

• 非活动（例如，没有正在发生变化）存储组可能会在不正常时将其状态报告为正常。由于直到重播日志时才能检测到不正常的情况，因此可能会发生这种情况。
  
• 在复制的初始化期间，由于要重新评估复制状态，因此复制状态可能不准确。初始化完成后，状态得以更新。
  
• 卸除存储组中的数据库后，LastLogGenerated 字段的值可能是错误的。
  
• 当日志流中缺少一个或多个日志时，被动副本仍继续尝试恢复，从而导致复制状态会在失败状态和正常状态之间切换。当发生这种情况时，重播队列和复制队列的长度会持续增长。
  
• 在极少数情况下，可能会成功验证日志但仍然无法重播。在这种情况下，系统在尝试恢复期间将在失败状态和正常状态之间交替切换。当发生这种情况时，重播队列和复制队列的长度会持续增长。
  

Get-StorageGroupCopyStatus cmdlet 还通过为 CCR 环境添加新状态信息而得到了增强：

• 当目标计算机上的 Microsoft Exchange 复制服务不能从网络访问时，Get-StorageGroupCopyStatus cmdlet 报告 SummaryCopyStatus 为 ServiceDown。
  
• 当目标计算机上的 Microsoft Exchange 复制服务尚未完成其初始启动检查时，Get-StorageGroupCopyStatus cmdlet 报告 SummaryCopyStatus 为 Initializing。此外，还会创建一个新的性能计数器，以便将此状态表示为布尔值。
  
• 如果尚未完成增量种子设定，Get-StorageGroupCopyStatus cmdlet 将 SummaryCopyStatus 报告为 Synchronizing。
  

仅当使用 Exchange 2007 SP1 版本的 Exchange 管理工具时，才能看到 SummaryCopyStatus 值的新状态。当使用 Exchange 2007 RTM 版本的 Exchange 管理工具时，前述任何状态的状态值都报告为“失败”。

Exchange 2007 SP1 引入了一个名为 Test-ReplicationHealth 的新 cmdlet。此 cmdlet 旨在对连续复制和连续复制管道进行主动监视。Test-ReplicationHealth cmdlet 检查复制、群集服务以及存储组复制和重播状态的所有方面，以提供复制系统的完整概述。具体来说，在群集中的节点上运行时，Test-ReplicationHealth cmdlet 执行下表中所描述的测试。

由 Test-ReplicationHealth cmdlet 执行的测试

Exchange 2007 SP1 中进行的性能改进促进了高可用性部署。这些改进包括：

• 在连续复制环境中包含存储组被动副本的磁盘上减少 I/O   在 Exchange 2007 SP1 中，连续复制体系结构的设计已经修改，以便现在数据库缓存在各批次日志重播活动之间永久保留在被动节点上。各批次日志重播活动之间数据库缓存的永久性使 Microsoft Exchange 复制服务可以利用 ESE 的数据库缓存功能，而这又降低了在被动副本的逻辑单元号 (LUN) 上发生的磁盘 I/O 量。相比之下，在 Exchange 2007 RTM 中是为每批日志重播活动创建一个新的数据库缓存，这在某些情况下会使被动节点上的磁盘 I/O 活动达到主动节点上磁盘 I/O 的两倍或三倍。
  
• 加速了 CCR 环境中群集邮箱服务器在节点之间的移动   这些改进使群集邮箱服务器能在两分钟或更少的时间内在完成在节点之间的移动。这包括由管理员执行的移动（使用 Move-ClusteredMailboxServer cmdlet）以及由群集服务管理的故障转移。为了在 CCR 环境中实现快速移动，应将数据库脱机，从而无需刷新数据库缓存。这种行为降低了在群集邮箱服务器移动到其他节点时所出现的停机时间。