群集连续复制
适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
上一次修改主题： 2008-03-21
群集连续复制 (CCR) 是 Microsoft Exchange Server 2007 的一项高可用性功能，它可将 Exchange 2007 内置的异步日志传送和重播技术与群集服务提供的故障转移和管理功能组合在一起。
设计 CCR 是为了通过提供满足下列条件的解决方案来为 Exchange 2007 邮箱服务器提供高可用性：
无单点故障。
无特殊硬件要求。
无共享存储要求。
可在一个或两个数据中心配置中进行部署。
可降低完全备份频率，减少备份数据卷的总数，缩短服务级别协议 (SLA) 中的从第一个故障恢复的时间。
CCR 使用了 Exchange 2007 中的数据库故障恢复功能，这样随着数据库主动副本的更改，数据库第二个副本也会得到持续和异步更新。在 CCR 环境中安装被动节点期间，会将每个存储组及其数据库从主动节点复制到被动节点。此操作称为“种子设定”，它提供了进行数据库复制的基础。执行初始种子设定后，将继续执行日志复制和重播。
在 CCR 环境中，复制功能与群集服务集成在一起，来实现高可用性解决方案。除了提供数据和服务可用性，CCR 还提供计划中断。当需要安装更新或需要执行维护时，管理员可将“群集邮箱服务器”（在以前版本的 Exchange Server 中称为 Exchange 虚拟服务器）手动移动到被动节点。完成移动操作后，管理员就可以执行所需的维护。
移动操作是使用 Exchange 命令行管理程序中的 Move-ClusteredMailboxServer cmdlet 来执行的。Microsoft Exchange Server 2007 Service Pack 1 (SP1) 还在 Exchange 管理控制台中包含一个新的管理群集邮箱服务器向导，可以用它来移动群集邮箱服务器。这些任务所使用的逻辑会执行必要的强制操作，以确保在移动过程中不丢失邮箱数据。这些任务还会在进行移动前执行检查，以确保被动节点上的复制可被快速激活。
CCR 的关键因素如下所示：
连续复制是异步的 只有在日志处于关闭状态并不再被邮箱服务器使用时，才可对其进行复制。这意味着被动节点通常不会拥有主动节点上存在的所有日志文件的副本。当管理员已启动主动节点的计划中断以应用更新或执行某些其他维护时除外。
在正常操作期间，连续复制几乎不会给主动节点带来 CPU 和输入/输出 (I/O) 负担 CCR 使用被动节点复制和重播日志。被动节点通过安全文件共享来访问日志。
群集生存期内主动和被动节点的转变是自动指定的 例如，故障转移之后，主动和被动标志会对换。这意味着复制方向的反向。反向复制不需要任何管理操作，系统自动管理复制反向。
故障转移和计划中断在功能和性能上是对称的 例如，从 Node1 故障转移到 Node2 的时间和从 Node2 故障转移到 Node1 的时间是一样的，通常在两分钟以内。在大型服务器上，计划中断通常不超过四分钟。故障转移和计划中断时间的差异，与计划中断中主动节点的受控关闭所需的时间有关。在以后的 Service Pack 中，这种性能差异会减少。
支持被动节点上的卷影复制服务 (VSS) 备份 这允许管理员从主动节点卸载备份并扩展备份窗口。此外，从性能要求的角度，并不要求大型配置必须让硬件 VSS 支持使用 VSS 备份。被动节点上的工作负荷主要是日志复制和日志重播，这两者都不像主动节点上的群集邮箱服务器那样实时受约束。例如，主动节点必须及时地响应客户端请求。因为被动节点没有实时响应约束，所以可使用更长时间的备份窗口，从而允许更大的数据库和邮箱。
减少备份媒体上的总数据量 CCR 被动副本为防止损坏和数据丢失提供了第一道防线。因此，只有出现双重故障后，才需要备份。因为不需要进行还原，所以从第一个故障恢复所需的 SLA 时间相对短些。从第二个故障恢复则需要更长的 SLA 时间。因此，可以按每周进行完全备份且每天进行增量备份的策略执行备份。这样就减少了必须要放置到备份媒体上的总数据量。
CCR 可以与备用连续复制 (SCR) 相结合 CCR 可以与 SCR 相结合，以在主数据中心本地复制存储组（使用 CCR 实现高可用性），并在辅助或备份数据中心远程复制存储组（使用 SCR 实现站点弹性）。辅助数据中心可以在 SCR 目标所在的故障转移群集中包含一个被动节点。这种类型的群集称作备用群集，因为它并不包含任何群集邮箱服务器，但是可以在恢复方案中为其快速设置一个替代群集邮箱服务器。如果主数据中心发生故障或丢失数据，可以在备用群集上快速激活驻留在该备用群集中的 SCR 目标。
CCR 核心体系结构
CCR 将下列元素组合在一起：
Microsoft 故障转移群集提供的故障转移和虚拟化功能
将文件共享用作群集活动的见证且基于多数的故障转移群集仲裁模型
Exchange 2007 中的事务日志复制和重播功能
称为传输垃圾站的集线器传输服务器邮件队列功能
Windows 故障转移群集
如下图所示，在 Exchange 2007 SP1 中，CCR 使用两台加入运行 Windows Server 2003 Service Pack 2 或 Windows Server 2008 的单个故障转移群集的计算机（称为“节点”）。故障转移群集中的节点驻留单个群集邮箱服务器。当前正在运行群集邮箱服务器的节点称为“主动”节点，未运行群集邮箱服务器、但是属于该群集且为连续复制目标的节点称为“被动”节点。由于计划维护中断和未计划中断所致，在故障转移群集的整个生存期内将节点称为主动或被动节点的标志将多次更改。
CCR 的基本部署
.gif "群集连续复制结构")
故障转移群集是使用群集服务以及一种特定类型的群集仲裁模型构建的：
对于 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 目录服务站点中的集线器传输服务器驻留文件共享，因为这允许消息管理员保持对文件共享的控制。
.gif "note") 注意： |
|---|
| 文件共享见证所用的文件共享不能驻留在分布式文件系统 (DFS) 环境中。 |
文件共享见证使用群集外部的计算机上的文件共享作为两个群集节点活动的见证。两个节点使用该见证来跟踪控制群集的节点。只有两个节点无法相互通信时，才需要使用记录板。请考虑一个由 Node1 和 Node2 组成的双节点群集邮箱服务器。在此示例中，Node1 是可以控制记录板的节点，因此可以控制群集并使群集邮箱服务器联机。如果 Node2 正常运行，但是无法与 Node1 进行通信，Node2 将尝试控制记录板，但是失败。Node2 无法控制记录板，这意味着它不会使群集邮箱服务器联机。
当两个节点可以相互进行交互时，则不需要记录板，记录板可以脱机。但是，以后任何一个节点出现故障时，如果文件共享见证不可用，群集邮箱服务器将无法联机。
文件共享只会保持前面所述的状态。因此，所有群集配置信息均在两个节点之间交换。了解这一点非常重要，因为这意味着如果 Node1 可用而 Node2 不可用，Node2 在与 Node1 进行通信之前，即使其可以与文件共享见证进行通信，也无法使用。
文件共享见证支持定期对文件共享见证进行访问检查。如果访问检查失败，将生成一个事件。可以通过监视系统检测、收集和报告该事件。这样，操作人员可以在问题出现第二次并发故障而造成中断之前解决该问题。
在下列情况下访问文件共享：
群集节点联机并且只有一个群集节点可用时。
网络连接问题使以前可以访问的节点无法与群集进行通信时。
群集节点离开群集时。
定期进行验证。该频率是可进行配置的。
因为上述原因，文件共享的负担很轻。因此，一台服务器可以为多个 CCR 环境提供文件共享。但是，每个 CCR 环境应该在此服务器上具有自己的专用文件夹和共享。
文件共享见证的注意事项
CCR 是双节点环境，它对文件共享见证使用 MNS 仲裁或“多节点和文件共享”仲裁，而不会在群集中使用第三个节点（或更多节点），而这在传统 MNS 群集中是必需的。地理位置分散的 CCR 环境是一种双数据中心部署，在这种部署中，主动节点部署在主数据中心，而被动节点部署在辅助数据中心。因此，在地理位置分散的 CCR 环境中，文件共享有两个布置选项：将其放置在主数据中心，或是将其放置在第三个数据中心。
第一个选项是在主数据中心的集线器传输服务器上配置文件共享。由于集线器传输服务器允许邮件管理员管理和监视文件共享的中断，因此推荐使用集线器传输服务器。我们的经验和客户反馈表明：大多数常见的网络服务中断类型都发生在广域网 (WAN) 拓扑中。将文件共享放置在主数据中心十分有用，因为它可以防止由于两个数据中心之间出现网络故障而引起的服务中断。使用这种配置意味着在主数据中心中断时，将不会出现自动故障转移。但它可以确保大多数故障转移群集不会受到主数据中心和辅助数据中心之间网络故障的影响。
第二个选项是在第三个物理站点内的托管服务器角色上配置文件共享。托管服务器角色是一种服务器，其受支持和维护的程度与其他对消息服务的传送十分关键的服务器类似。例如，主数据中心的集线器传输服务器就是托管服务器角色。第三个物理站点可以是分支机构或第三个数据中心。此配置的要求是：第三个站点必须拥有一个针对主数据中心和辅助数据中心的、具有低延迟和高可靠性的网络基础结构。
事务日志复制和重播
事务日志复制和重播用于复制更改的数据并更新被动副本的数据库。复制利用了可扩展存储引擎 (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 客户端的草稿文件夹。
约会、联系人更新、属性更新、任务和任务更新。
从客户端传输到中心传输服务器的传出邮件。其中有一个时段，电子邮件只存在于发件人的邮箱服务器上。
部署群集连续复制
部署 CCR 与部署独立 Exchange 服务器类似，并且与部署 SCC 类似。有关 SCC 的详细信息，请参阅单一副本群集。但是，在部署 CCR 时应注意一些重要的不同之处。建议您在环境中设计和部署 CCR 之前，先参阅下列主题：
准备好部署 CCR 之后，可以按照下列主题之一中所述，通过执行每个安装阶段中的步骤开始部署过程：
对 Exchange 2007 SP1 中 CCR 的增强
Exchange 2007 SP1 包含多项 CCR 增强功能，其中包括其他 Exchange 管理控制台用户界面元素、改进的状态和监视以及改进的性能。
Exchange 管理控制台增强
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，并为传输垃圾站所遮盖的窗口部分提供了更大的可视性。
对 Get-StorageGroupCopyStatus 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 管理工具时，前述任何状态的状态值都报告为“失败”。
Test-ReplicationHealth Cmdlet
Exchange 2007 SP1 引入了一个名为 Test-ReplicationHealth 的新 cmdlet。此 cmdlet 旨在对连续复制和连续复制管道进行主动监视。Test-ReplicationHealth cmdlet 检查复制、群集服务以及存储组复制和重播状态的所有方面，以提供复制系统的完整概述。具体来说，在群集中的节点上运行时，Test-ReplicationHealth cmdlet 执行下表中所描述的测试。
由 Test-ReplicationHealth cmdlet 执行的测试
| Test | 说明 |
|---|---|
群集网络状态 |
验证本地节点上发现的所有集群管理的网络是否正在运行。此测试只能在 CCR 环境下运行。 |
仲裁组状态 |
验证包含仲裁资源的群集组是否处于正常状态。此测试只能在 CCR 环境下运行。 |
文件共享仲裁状态 |
验证是否可以访问文件共享见证的多数节点集仲裁所使用的 FileSharePath 的值。此测试只能在 CCR 环境下运行。 |
群集邮箱服务器组状态 |
通过确认组中的所有资源是否都处于联机状态来验证群集邮箱服务器是否处于正常状态。此测试只能在 CCR 环境下运行。 |
节点状态 |
验证群集中的节点是否都未处于暂停状态。此测试只能在 CCR 环境下运行。 |
DNS 注册状态 |
验证设置了“需要注册 DNS 才能成功”的所有群集管理的网络界面是否都已通过 DNS 注册。此测试只能在 CCR 环境下运行。 |
复制服务状态 |
验证本地计算机上的 Microsoft Exchange 复制服务是否处于正常状态。 |
存储组副本挂起 |
检查连续复制是否由于为连续复制启用的任何存储组而被挂起。 |
存储组副本失败 |
检查是否有任何存储组副本处于“失败”状态。 |
存储组复制队列长度 |
检查是否有任何存储组的复制副本队列长度大于最佳实践的阀值。当前，这些阈值为：
|
故障转移后卸除数据库 |
检查发生故障转移后是否有任何数据库被卸除或失败。此测试仅检查由于故障转移而失败的数据库。 |
性能增强
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 环境中实现快速移动，应将数据库脱机，从而无需刷新数据库缓存。这种行为降低了在群集邮箱服务器移动到其他节点时所出现的停机时间。
使用带有 CCR 的备用连续复制
SCR 是 Exchange 2007 SP1 中引入的一项新功能。SCR 会扩展现有连续复制的功能，并使新数据可用于 Exchange 2007 邮箱服务器。SCR 使用的日志传送和重播技术与 LCR 和 CCR 相同，它可以提供额外的部署选项和配置。
SCR 使您可以使用连续复制从独立邮箱服务器（使用或不使用 LCR）中、或从 SCC 或 CCR 环境中的群集邮箱服务器中复制邮箱服务器数据。
激活由 SCR 创建和维护的邮箱服务器数据副本的过程是手动的，目的是在出现严重故障时使用（而不是用于那些可通过重新启动或某些其他快速的方法进行恢复的简单的服务器中断）。可以使用数据库可移植性、服务器恢复选项 (Setup /m:RecoverServer)，或者在邮箱服务器为群集邮箱服务器时使用群集邮箱服务器恢复选项 (Setup /RecoverCMS) 来激活 SCR 目标。将根据您的配置和发生故障的类型选择选项。
有关 SCR 的详细信息，请参阅备用连续复制。
详细信息
下列主题区域讨论了何时以及如何使用 CCR 作为高可用性和站点弹性计划的一部分：