Exchange Server 2007 Service Pack 1 中的备用连续复制

Service Pack 1 提供了多项针对 Exchange 2007 的新增功能和增强功能。其中一项新增功能称为备用连续复制 (SCR)，旨在为组织提供数据中心内的冗余和站点恢复功能。顾名思义，SCR 主要针对

使用或能够使用备用恢复服务器的方案而设计。

如果您非常熟悉 Exchange 2007 的批量生产 (RTM) 版本，就会发现，它还通过自身的日志传送功能和对 Windows^® 故障转移群集的支持提供了数据中心内的冗余和站点恢复功能。在 RTM 版本中，提供了两种形式的日志传送（正式名称为连续复制）：本地连续复制 (LCR)，如图 1 所示；群集连续复制 (CCR)，如图 2 所示。

Figure 1 Local continuous replication

Figure 2 CCR is log shipping to a second server in a Windows failover cluster

连续复制允许管理员在线启用和维护每个邮箱数据库的另一个副本，从而提供了数据可用性和冗余。此数据库副本代表防御生产数据库故障、丢失或损坏的第一道防线。这样，只需花费几分钟便可激活数据库副本并将其转换为生产数据库，您就无需浪费时间为恢复数据查找备份磁带了。

SCR 扩展了该方案，在其中您可以实现组织的数据和服务可用性。通过新方案，您可以将高可用性拓扑和站点恢复拓扑区分开来，还可以在各个区域部署根据组织的特定需求量身定制的配置。

Exchange 2007 的 RTM 版本提供了数据中心内的冗余和站点恢复，但由于 LCR 和 CCR 针对每个数据库仅提供了一个额外副本，因此您必须在恢复和冗余之间进行选择。例如，考虑一下 CCR 提供的数据和服务可用性功能。在一个数据中心部署主动节点和被动节点可提供数据中心内的服务和数据可用性，但不提供站点恢复（因为这两种节点位于同一个物理站点中）。在某个数据中心部署主动节点而在另一个数据中心部署被动节点可提供站点恢复，但不提供数据中心内的可用性（因为提供这些功能的被动节点位于另一个数据中心）。

使用 Service Pack 1 中的 SCR，能够针对每个数据库创建更多副本，这意味着高可用性和站点恢复不再互相排斥，您可以同时实现两者。例如，如图 3 所示，您可以结合使用 SCR 与 CCR 在主数据中心内本地复制存储组（使用 CCR 获得高可用性），而在另一个数据中心或备份数据中心远程复制存储组（使用 SCR 获得站点恢复）。在站点恢复方案中，第二个数据中心包含可激活和快速设置替换群集邮箱服务器的备用群集。

Figure 3 CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter (单击该图像获得较小视图)

Figure 3 CCR deployed in Redmond datacenter and SCR deployed in Quincy datacenter (单击该图像获得较大视图)

图 3 描述了针对两个数据中心的企业部署，其中每个数据中心都有自己的 Active Directory^® 站点：Redmond 和 Quincy。Redmond 站点位于主（生产）数据中心，Quincy 站点位于另一个（备份）数据中心。在 Redmond 中部署 CCR 以获得数据中心内的冗余。借助 Exchange 2007 所需的基础结构要素，在 Quincy 中的备用群集上配置 SCR 目标可获得站点恢复。这些附加的基础结构要素包括客户端访问服务器和集线器传输服务器、Active Directory 服务器和 DNS 服务器以及 Internet 访问，它们可以是专用资源，也可以是非专用资源。专用资源是指明只支持资源所在数据中心的用户的资源。非专用资源是指既支持本地数据中心的用户也支持其他位置的用户的资源。您必须根据组织的需要，确定资源是专用还是非专用。有关专用和非专用资源的详细信息，请参见 Exchange Server 2007 帮助文件主题“站点恢复配置”，网址为：technet.microsoft.com/bb201662.aspx。您还要注意新类型多数节点集 (MNS) 仲裁的使用。在 Exchange Server 2007 中，CCR 使用 MNS 仲裁进行文件共享见证 (FSW)，而不使用传统的投票节点，如图 3 所示。

在图 4 中，具有恢复功能的 CCR 和 SCR 环境为服务器 EXCLUS1 上承载的邮箱和服务提供了若干层冗余，从而保护这些邮箱以防止出现各种规模的灾难性故障。

Figure 4 Standalone mailbox servers using SCR to replicate storage groups to each other (单击该图像获得较小视图)

Figure 4 Standalone mailbox servers using SCR to replicate storage groups to each other (单击该图像获得较大视图)

中小型组织也可以从 SCR 中受益。例如，如图 4 所示，组织可以部署两个独立的邮箱服务器（EXMBX1 和 EXMBX2），然后使用 SCR 将一个邮箱服务器中的部分或全部存储组复制到另一个邮箱服务器。

在本例中，EXMBX1 和 EXMBX2 都是具有五个活动存储组的生产服务器。每个存储组都是一个 SCR 源，对应于其他服务器上的 SCR 目标。如果出现存储故障或导致配置为 SCR 源的活动存储组不可用的其他情况，可使用 Exchange 命令行管理程序中的几项管理任务快速激活 SCR 目标副本。使用 Microsoft^® Office Outlook^® 2007 和 Exchange 2007 中的数据库可移植性和自动发现功能，则由活动存储组丢失（或者，是丢失了多个活动存储组）而导致的停机时间仅仅几分钟而已。

在 LCR 和 CCR 中，SCR 也使用存储组主动副本和被动副本的概念，但它们分别称为 SCR 源和 SCR 目标。不过，SCR 源和 SCR 目标都是存储组副本。（无法针对 SCR 使用恢复存储组。）

SCR 的起点（SCR 源）是单一副本群集或 CCR 环境中独立的邮箱服务器或群集邮箱服务器上的任意存储组。不过请注意，尽管 SCR 源可以是群集邮箱服务器，但 SCR 本身不是群集解决方案，也不需要使用 Windows 群集服务，这一点很重要。SCR 的终点（SCR 目标）既可以是独立邮箱服务器，也可以是故障转移群集中的节点，群集中已安装邮箱角色但尚未配置群集邮箱服务器。

每个 SCR 源存储组拥有的 SCR 目标数都不受限制。例如，一个源可以在其所在的数据中心拥有一个目标，在其他数据中心拥有另一个目标。但是，Microsoft 建议每个源对应的目标不要超过四个。如果您决定使用四个以上的目标，则必须相应地针对内存、CPU、磁盘资源和规划来评估可能会对 SCR 源服务器造成的影响。每个 SCR 目标计算机可以具有多个源服务器。源计算机和目标计算机都必须运行 Exchange 2007 Service Pack 1。操作系统必须受 Exchange 2007 Service Pack 1 支持（例如，Windows Server^® 2008 或 Windows Server 2003 SP2）。不过，无论您使用哪种操作系统，SCR 都不支持跨操作系统，所以它要求 SCR 源上的操作系统与该源对应的所有 SCR 目标上的操作系统匹配。因此，如果 SCR 源运行 Windows Server 2003，则该源的所有 SCR 目标也必须运行 Windows Server 2003。

SCR 在 Exchange 2007 Standard Edition 中提供。如果将 SCC 或 CCR 环境中的群集邮箱服务器用作 SCR 源，则需要使用 Exchange 2007 企业版。使用企业版时，每个 SCR 目标最多支持 50 个实例（50 个复制的存储组）；使用标准版时，最多支持 5 个实例。

SCR 目标也有一些必须满足的要求。首先，源计算机和目标计算机必须位于同一个 Active Directory 域中，不过它们可以位于相同或不同的 Active Directory 站点中。此外，源及其所有目标上的数据库和日志文件路径必须与 SCR 正在复制的各个存储组相匹配。最后，将某个节点或服务器配置为 SCR 目标后，将无法为 SCR 目标计算机上的任何存储组启用 LCR，并且无法将任何群集邮箱服务器添加到备用故障转移群集。

SCR（如图 5 所示）与 LCR 和 CCR 使用相同的日志传送和重播技术来提供新的部署选项和配置。在 LCR 和 CCR 中，启用 SCR 的存储组最多只能包含一个数据库。同样，如果 Exchange 组织中存在多个公用文件夹数据库，则 SCR 也无法用于公用文件夹数据库。

Figure 5 SCR is log shipping to another server or a passive node in a failover cluster

SCR 的一个主要区别在于它支持每个存储组使用多个目标，而 LCR 和 CCR 均仅支持一个目标（被动副本）。另一个主要区别是您无法备份 SCR 副本，这与 CCR 和 LCR 不同。使用 SCR 时，如果针对 SCR 源存储组执行受支持的备份（在 CCR 和 LCR 中，则是针对 SCR 源存储组的主动副本或被动副本执行备份操作），则会更新 SCR 目标的数据库标题并截断日志文件。

与 LCR 和 CCR 一样，SCR 的日志传送是连续的并使用一种“拉”模型。新的日志文件关闭并使用下一代日志文件序列号命名后，SCR 目标计算机上运行的 Microsoft Exchange 复制服务就会从 SCR 源计算机中拉出已关闭的事务日志文件，检查并验证这些文件，然后将其移动到 SCR 目标计算机上对应的存储组日志文件文件夹。

将日志文件复制到 SCR 目标计算机后，SCR 会执行一些 LCR 和 CCR 不执行的操作。SCR 不会立即将日志文件重播到数据库副本，而是强制实施 50 个日志文件的内置重播延迟外加 24 小时。SCR 还允许您在这些内置延迟以外指定附加的时间延迟。延迟重播活动在很多情况下都非常有用。例如，在活动数据库出现逻辑损坏的情况下，延迟可以防止 SCR 目标数据库出现逻辑损坏。

管理员控制的重播延迟使用参数 ReplayLagTime 进行设置，该参数指示 Exchange 复制服务在重播已复制到 SCR 目标计算机的日志文件前应等待的时间量。格式为 Days.Hours:Minutes:Seconds，默认值为 24 小时。该值最大可设置为 7 天，最小可设置为 0 秒，将该值设置为 0 秒可有效消除日志重播活动中除默认延迟 50 个日志文件之外的任何延迟。

除 ReplayLagTime 外，Exchange 还具有 50 个日志文件的内置硬编码延迟，与 ReplayLagTime 的值设置无关。为了确定重播日志文件的时间，Exchange 使用较大的 ReplayLagTime 值或 x 个日志文件，其中 x=50。上述设置针对需要为某个存储组重新设定种子的情形提供了一层额外的保护，即如果使用连续复制的 SCR 源（例如 CCR 环境中的群集邮箱服务器）遇到故障转移，并且需要使用 Restore-StorageGroupCopy cmdlet 使一个或多个存储组联机。（种子设定的过程是：使用可扩展存储引擎 (ESE) 流备份 API 为 SCR 目标计算机上的 SCR 源数据库制作联机副本。）通过延迟 SCR 目标上的重播活动，当 SCR 源的故障转移遭受损失时，需要为 SCR 副本重新设定种子的概率会降至最低，因为 SCR 源上数据丢失本身的特点可及时将两个副本紧密联系在一起。

在 Exchange 2007 的 RTM 版本中，会在连续复制环境中强制执行一些规则，这样日志文件在得到备份并重播到数据库前不会被删除。使用 SCR 时，此规则做了一些改动。SCR（引入了多个数据库副本的概念）允许在所有 SCR 目标计算机检测完日志文件后，立即在 SCR 源计算机上截断日志文件。SCR 源服务器上的日志截断不会等待所有日志都重播到所有 SCR 目标后才执行，因为 SCR 目标副本的日志重播延迟时间可以配置为很大的值。

您还可以使用名为 TruncationLagTime 的新参数为日志截断添加额外延迟，该参数指定在截断已复制到 SCR 目标计算机并重播到数据库副本的日志文件前，Exchange 复制服务应等待的时间（格式为 Days.Hours:Minutes:Seconds）。该时间段在日志文件成功重播到数据库副本后立即开始计算。该值最大可设置为 7 天，最小可设置为 0 秒，后者会有效消除日志截断活动中的任何延迟。

在 SCR 环境中，每三分钟运行一次后台线程，以确定是否存在需要截断的日志文件。如果日志文件生成顺序低于存储组的日志文件检查点，并且日志文件的存在时间早于 ReplayLagTime + TruncationLagTime，则会截断 SCR 目标上的日志文件。

在使用 SCR 扩展的 LCR 或 CCR 环境中，如果满足以下四个条件，则会截断 SCR 目标上的日志文件：日志文件已备份，日志文件生成顺序低于存储组的日志文件检查点，存储组的被动副本处于允许截断日志文件的状态，并且所有 SCR 目标均已对日志文件进行检测。

在 Exchange 命令行管理程序中，使用 Enable-StorageGroupCopy cmdlet（在 SP1 中已使用一些新参数进行了更新）启用 SCR。如前文所述，您可以使用 ReplayLagTime 和 TruncationLagTime 控制某些 SCR 目标行为。另一参数 SeedingPostponed 可用于跳过 SCR 目标的初始种子设定。延迟种子设定在很多情况下也很有用。例如，假定存储组中要为 SCR 启用的数据库为 100GB。在生产高峰期间，您可能不希望 100GB 的数据都来遍历网络。此时，您可以通过 SeedingPostponed 参数立即启用 SCR，而在稍后执行种子设定任务。准备好后，即可使用 Update-StorageGroupCopy cmdlet 手动为 SCR 目标设定种子。

尽管前面提到的参数是可选的，但 Enable-StorageGroupCopy 是 SCR:StandbyMachine 的必选参数。该参数用于指定将包含 SCR 目标的计算机名。该参数的值作为为 SCR 启用的存储组的 msExchStandbyCopyMachines 属性值的一部分进行设置。MsExchStandbyCopyMachines 属性是一个多值 Unicode 字符串。当 Exchange 组织引入 Exchange 2007 SP1 时，该字符串被添加到 Active Directory 架构，这是 SP1 要求为 Active Directory 更新架构的原因之一。

StandbyMachine 参数是 SCR 的核心，SP1 已为使用该参数启用和管理 SCR 目标而更新了多个 cmdlet。更新后的 cmdlet 如图 6 所示。

SCR 提供了一个或多个最新数据副本，如果原始数据丢失或不可用，则可使用这些副本。获取 SCR 目标副本并将其重新设置为生产数据库的过程称为激活。激活是恢复过程的一部分，采用的形式为数据库可移植性或两个设置恢复选项之一（/m:RecoverServer 用来恢复独立的服务器，/RecoverCMS 用来恢复群集邮箱服务器）。

让我们虚构一个公司，看一下如何使用 SCR 和数据库可移植性从邮箱数据库故障中进行恢复。发现生产数据库受到损坏后，管理员将使用数据库可移植性激活 SCR 目标数据库。

组织已部署 Exchange 2007 和 SP1 并决定利用 SCR 提供远程邮箱服务器上某个存储组的副本。源邮箱服务器和目标邮箱服务器位于同一个 Active Directory 站点，并配置为使用与 Active Directory 集成的 DNS 服务器。Active Directory 复制间隔配置为 15 分钟。

配置 SCR，以便为单个存储组 SG1（包含一个数据库 MBX1）复制事务日志文件。存储组文件和数据库文件的路径分别为 C:\SG1 和 C:\SG1\MBX1.EDB。此时，EXMBX1 为 SCR 源，EXMBX2 为 SCR 目标。按照如下所示进行配置：

Enable-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

启用 SCR 后，使用 Get-StorageGroupCopyStatus cmdlet 验证 SG1 的 SCR 运行状况和状态：

Get-StorageGroupCopyStatus EXMBX1\SG1 -StandbyMachine EXMBX2

为节省 SCR 目标激活过程的时间，可为 EXMBX2 预配置存储组 SG1PORT 和数据库 MBX1PORT，在数据库可移植性操作中会用到。SG1PORT 和 MBX1PORT 与 SCR 目标的存储组和数据库文件是相互独立的。因此，应为 SG1PORT 和 MBX1PORT 配置与 SCR 目标路径不冲突的临时路径。SG1PORT 和 MBX1PORT 仅用作数据库可移植性对象；无需提供 SG1PORT 的实际存储组和数据库文件。因此，管理员可卸载 MBX1PORT 并删除存储组中的所有文件。存储组和数据库对象保留在 Active Directory 中，因为在稍后的恢复过程中，它们将用于数据库可移植性。

某个应用程序事件日志条目指示 SCR 源数据库已出现物理损坏。由于已为 SG1 启用了 SCR，所以决定为 SG1 手动激活 SCR 目标数据库，并使用数据库可移植性恢复数据可用性。要激活 SCR 目标副本，应首先使用以下 cmdlet 卸载 SG1 中的 MBX1：

Dismount-Database EXMBX1\SG1\MBX1

然后，使 SCR 目标数据库可用于装载，而原来在 MBX1 上的邮箱将被重新连接到 MBX1PORT。

禁用 SCR 并使 SCR 目标数据库可用于装载的过程需要运行 Restore-StorageGroupCopy cmdlet。此任务将存储组的数据库标记为可装载，并提供关于在存储组中装载数据库可能会导致数据丢失的报告（如果有）。该任务还会验证存储组主动副本生成的所有日志文件是否都位于存储组被动副本的存储组文件位置。如果丢失了任何日志文件，该操作还会尝试复制它们。以下 cmdlet 用于使 SCR 目标数据库可用于装载：

Restore-StorageGroupCopy EXMBX1\SG1 -StandbyMachine EXMBX2

在本例中，SCR 源存储组的日志文件可用于复制。如果这些文件不可用（例如，因为 SCR 源计算机处于关机状态），则必须将 Force 参数添加到 Restore-StorageGroupCopy 任务。否则，Restore-StorageGroupCopy 将一直尝试连接到 SCR 源以复制所有丢失的日志文件；如果 SCR 源不可用，则 Restore-StorageGroupCopy 任务将失败，数据库将不能用于装载。添加 Force 参数，向 Restore-StorageGroupCopy 任务告知源文件不可用，此时将跳过连接尝试，继续前进使 SCR 目标数据库可用于装载。

完成 Restore-StorageGroupCopy 命令后，管理员必须验证数据库是否处于干净关闭状态。如果数据库处于异常关闭状态（请参阅technet.microsoft.com/aa996757.aspx），则必须使其处于干净关闭状态。如果 SCR 源 (EXMBX1\SG1) 的存储组与将用于数据库可移植性 (EXMBX2\SG1PORT) 的 SCR 目标 (SG1PORT) 的存储组的日志文件前缀（例如，E00 或 E01）相同，则无需在恢复模式下运行 Eseutil，并且最后的数据库装入操作会在重播完复制的所有日志文件后使数据库处于干净关闭状态。如果数据库未处于干净关闭状态，则必须对数据库运行 Exchange Server 数据库实用程序 (Eseutil) 恢复模式 (Eseutil /r)。

数据库处于干净关闭状态后，就可以运行两个命令，用存储组文件和数据库文件的新位置来更新 Active Directory。这些命令将 SG1PORT 和 MBX1 的原始路径更改为暂存存储组和数据库（SG1PORT 和 MBX1PORT）的路径：

Move-StorageGroupPath EXMBX2\SG1PORT -SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnlyMove-DatabasePath EXMBX2\SG1PORT\MBX1PORT -EdbFilePath C:\SG1\MBX1PORT.EDB –ConfigurationOnly

上述命令中必须包括 –ConfigurationOnly 参数，以便在 Active Directory 中仅更新这些对象的配置设置。该命令不会移动任何数据或文件，也无需这样做，因为 SCR 已将数据复制到了 EXMBX2 上的 C:\SG1。

下一步是配置数据库 (MBX1PORT) 以允许它在还原操作过程中被覆盖。您可以通过两种方式完成此操作：一种是在 Exchange 管理控制台中，选中数据库对象属性上的“还原时可以覆盖此数据库”设置的复选框；另一种是在 Exchange 命令行管理程序中使用以下命令：

Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT -AllowFileRestore:$true

将数据库配置为允许覆盖自己后，接下来要使用以下命令装载该数据库：

Mount-Database EXMBX2\SG1PORT\MBX1PORT

装载数据库后，必须重新连接 SCR 源数据库 (SG1\MBX1) 上驻留的邮箱，使其指向 EXMBX2 上的 MBX1PORT。只需运行 Get-Mailbox cmdlet，并将输出通过管道传输到 Move-Mailbox cmdlet 即可。在此过程中，通过管道传输到 Move-Mailbox cmdlet 的 Get-Mailbox cmdlet 输出中不包含 Exchange 系统助理和系统邮箱，这一点很重要。无需重新连接这些邮箱对象，也不应重新连接。运行以下命令以重新连接所有用户邮箱，并排除系统邮箱：

Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox| ExOleDbSystemMailbox)'}|Move-Mailbox-ConfigurationOnly -TargetDatabase EXMBX2
\SG1PORT\MBX1PORT

现在，客户端可以访问 MBX1PORT 了。不过，在将邮箱从 EXMBX1\SG1\MBX1 移动到 EXMBX2\SG1PORT\MBX1PORT 后，用户是否能够真正访问其邮箱要取决于 Active Directory 复制延迟；也就是说，取决于目录服务器的数目，因为将更新应用于整个环境可能需要一段时间。此外，客户端访问方法也很重要。在使用新路径更新用户的客户端服务器使用的目录服务器后，运行 Outlook 2007 的消息客户端和非 Outlook 客户端都可以访问用户的邮箱。运行 Outlook 2003 和早期版本的消息客户端需要使用新服务器名更新用户的桌面消息配置文件。

在客户端都能够访问其邮箱和邮箱数据后，最后一步是重新启用 SCR 以建立冗余。删除 EXMBX1 中剩余的所有存储组和数据库文件，即可完成此操作。删除这些文件后，可将 EXMBX1\SG1\MBX1 的路径移动到临时位置，而 EXMBX1 即成为 EXMBX2 的 SCR 目标。