Exchange Server 2007 连续复制深度解析 ( 续 2)

 考虑这样的一个CCR环境，NodeA  拥有群集邮箱服务器，NodeB 是被动节点。NodeA  产生和关闭日志文件，NodeB  拷贝关闭的日志文件并重播它们到数据库的被动副本中。

NodeA 产生日志并发送它们到NodeB

如图1所示。

现在假设NodeA 出现故障，在上面的图中，我们看到NodeA 创建了第4个日志，并正在生成第五个日志文件对于存储组1来说，但是这两个日志在NodeA 发生故障之前都没有拷贝到NodeB。

NodeA 发生故障，NodB作为新的活动节点开始生成日志文件，从第4个日志开始。如图2所示：

作为故障的结果，在NodeB上将发生下面的事情：

1.       复制服务将企图从NodeA拷贝丢失的日志来阻止存储组的有损耗激活。

2.       如果拷贝企图失败，复制服务将计算日志丢失通过从LastLogGenerated 减去LastLogInspected  为每个存储组，并将该值和群集邮箱服务器的AutoDatabaseMountDial  值做比较。如果结果小于AutoDatabaseMountDial  值，那么存储组将加载。如果结果大于AutoDatabaseMountDial 值，那么存储组将不加载。

注意：根据丢失的日志如 果数据库在AutoDatabaseMountDial 值之外，它们将不会自动加载。在这种情况下，复制服务将每隔30秒钟尝试联系被动节点（发生故障的原来的主动节点）来拷贝丢失日志文件。如果它能够拷贝足 够多的日志文件来减少损耗到一个可接受的值，那么数据库将被加载上线。另外，有一个选项可以指定强制加载数据库的一个时间，通过设置 ForcedDatabaseMountAfter ，然而，使用该特性要多加小心因为它能引起数据分歧。

对于加载的每个存储组，复制服务将初识化一个传输转储程序重新传递请求，用来恢复在故障之前即刻被提交到群集邮箱服务器的消息。我们将在传输转储程序中详细讲述这个。

也 要注意存储组1被加载到NodeB上的结果，存储组将生成日志文件并将继续产生日志流，从第4个日志开始。可以从上述的图中看出，存储组1生成第4个到第 6个日志文件。当NodeA返回，Exchange 如何处理已经存在于NodeA 和NodeB上的日志流，这部分将在增加的重设种子部分讨论。

传输转储程序

传输转储程序是Exchange 2007 内置的一个特性，设计用来减少数据丢失通过重新传递最近提交给邮箱服务器的邮件在一个有损耗故障之后。

如 果我们返回到我们的NodeA/NodeB环境中，日志1、2和3已经被提交到NodeA上的数据库中。这些日志已经被复制到NodeB并且它们已经被重 播到它自己的数据库。接着，NodeA 发生故障，日志4和5没有被复制到NodeB。NodeB接管了群集邮箱服务器，将存储组加载上线并初始化这部分讨论的传输转储程序重新传递进程。 NodeA上生成的日志4和5，没有复制到NodeB可能包含实际的数据。例如，他们可能包含下面的信息：

1.       数据提交到传输服务器 (邮件或会议邀请)

2.       非传输相关的用户数据 (日历条目、联系人、任务、便签、草稿、属性更新等)

3.       数据库维护记录 (在线维护)

4.       日志回滚

现在我们将重点集中在第一个关键点。在Exchange 2007中，所有的邮件都必须经过中心传输服务器。这主要是为了满足遵从性（规定和要求），但是也提供了数据恢复的方法。

在Exchange 2007中，不管什么时候一个中心传输服务器接收到一个邮件，它要经过分类。分类进程的一部分涉及到查询活动目录来决定包含收件人邮箱的目的存储组是否启 用了LCR或CCR。一旦邮件被传递到所有的收件人，该邮件被提交到中心传输服务器上mail.que 文件，并存储在mail.que 文件中的传输转储程序中。传输转储程序对于每个启用LCR或者CCR的活动目录站点中的每个存储组是可用的。有两个设置可以定义传输转储程序中邮件的周 期。它们是：

1.       MaxDumpsterSizePerStorageGroup   定义中心传输服务器上每个存储组可用的大小。建议是设置为平均邮件大小的1.5倍。缺省值为18MB。
2.       MaxDumpsterTime   定义消息保留在传输转储程序中的时间的长短如果转储程序限制还没有达到。缺省值为7天。

如果时间或大小限制达到的话，邮件将根据先进先出的规则从传输转储程序中删除。

当故障（非计划中断）发生的时候，复制服务将企图拷贝丢失的日志文件。如果拷贝企图失败，那么这就叫着有损耗故障转移，将执行下面的步骤。

注意：在RTM中，传输转储程序只对CCR可用。在SP1中，传输转储程序被扩展到LCR带有一些警告，下面会将讲述这些。

1.       如果数据库在AutoDatabaseMountDial 值的范围内，它们将自动加载。对于LCR，转储程序触发会初始化当Restore-StorageGroupCopy 被执行。

2.       通过设置DumpsterRedeliveryRequired  为true，复制服务将记录群集数据库中存储组要求的传输转储程序重新传递（或在LCR的情况下在注册表中）。

3.       复制服务将记录在群集邮箱服务器的活动目录站点的群集数据库中心传输服务器（或在LCR的情况下在注册表中）的DumpsterRedeliveryServers设置。

4.       复制服务将计算丢失的窗口。这是通过使用LastLogInspected 标记作为起始时间和当前时间作为终止时间。由于传输转储程序是基于邮件传递时间，我们慷慨地通过向后展开12个小时向前展开4个小时来填充丢失的窗口。起 始时间记录在DumpsterRedeliveryStartTime终止时间记录在DumpsterRedeliveryEndTime中。

5.       复制服务生成一个RPC调用给列在DumpsterRedeliveryServers的中心传输服务器请求转储程序重新投递给对于特定的丢失时间窗口。 如果中心传输服务器不可用，CCR将每隔30秒发送同样的请求直到配置的MaxDumpsterTime 达到。对于LCR，该请求只发送一次。

 

注意：在RTM中，重新投递请求是硬编码的，重试达到7天。SP1基于MaxDumpsterTime 的基础使它不同。

6.       中心传输服务器将回应第一个重新投递请求通过一个重试响应。

7.       中心传输服务器将重新传递它自己的传输转储程序中拥有的邮件在指定的时间窗口。一旦邮件被重新提交用于传递，该邮件将从传输转储程序中删除。

8.       复制服务生成一个RPC调用给列在DumpsterRedeliveryServers的中心传输服务器请求转储程序重新投递给对于特定的丢失时间窗口。

9.       已经成功重新传递转储程序邮件的中心传输服务器将通过一个成功的响应来回应重新传递请求。在这点复制服务将从DumpsterRedeliveryServers中删除这些中心传输服务器。

10.   该过程将继续直到要么所有的中心传输服务器已经重新传递邮件或MaxDumpsterTime  已经到达。再一次，在LCR环境中，请求只会发送一次，因此那些不可用的中心传输服务器在Restore-StorageGroupCopy 被执行的时候将从不会重新传递转储程序条目对于这个丢失的窗口。

注意：如果多个有损耗故障发生，新的丢失窗口被添加到前一个中。

在这点，有一个问题传递转储程序能够处理多少丢失的数据。让我们看一个例子。

考虑一个环境使用15MB的转储程序，活动目录站点中有8个中心传输服务器，每个邮箱生成20MB的流量10个小时，每个存储组有100个邮箱。

15MB * 8 = 120MB per storage group

[20MB / 10 hours] * 100 mailboxes/SG = 200MB message traffic in 1 hour

60 minutes * 120MB/200MB = 36 minutes worth of data

在36分钟里，服务器上的每个存储组生成120+ 日志。

其 他的问题是传递转储程序是否在保证的时间窗口到来。如果您的组织中没有消息大小限制（如果您没有参照 MaxDumpsterSizePerStorageGroup 的最佳设置为您的环境），一个18MB的邮件将清除其他的邮件对于指定的中心传输服务器上的指定存储组。

增量式重新设定种子

考 虑前面的场景：NodeA 在关闭出去的第4个日志并开始记录第5个日志后意外中断，但第4个日志之前的日志都复制到NodeB。NodeB 接管了群集邮箱服务器，将存储组上线，初始化传递转储程序重新传递进程来恢复在故障期间已经提交给群集邮箱服务器邮件。此外，由于存储组在线，它服务请求 并生成它自己的第4个和第5个日志文件。

最终，管理员修复NodeA 上的问题，并使它重新在线。NodeA 将和群集通信并知道NodeB 拥有群集邮箱服务器。NodeA上的复制服务接着判断分歧发生在什么地方。分歧检测逻辑相对比较简单。复制服务将它自己的最高日志和源上的最高日志做比 较，并比较头来决定它们是否是同一个日志文件。如果它们是相同的，没有分歧发生。如果它们不是相同的日志文件，接着复制服务将继续比较日志文件直到它找到 一个日志文件和源上的日志文件匹配，这被称为分歧点。

查找分歧点

如图3所示：

在我们的场景中，NodeA上的复制服务将比较第5个日志，发现它与NodeB 上的不匹配。接着它发现第4个日志是相同的，但是它将判断第3个日志是否匹配。

现 在复制服务知道对于这个存储组来说分歧发生在哪个地方，我们需要决定任何纠正它。对NodeA 上的副本重设种子将纠正分歧。然而，这是很昂贵的对于大型数据库从网络的角度、存储I/0和吞吐量以及从SLA角度。为了减少执行数据库重设种子的需 要，Exchange 团队集中在通用的案例：当一个有损耗故障发生的时候，每个存储组只有少量的日志文件被丢失，同时有故障的节点将很快被修复。

对于通用的案例来说该团队的Exchange 2007解决方案分两个部分：

1.       事务日志文件从5MB减少到1MB。日志大小的减少确保对于每个日志文件来说只有很少量的数据丢失。

2.       LLR 被增加到ESE中。

如 果分歧点大于或等于waypoint （意味着分歧的日志高于列在数据库头中的“Logs Required” 部分），那么日志文件会被丢弃由于日志分歧只在日志文件中不在数据库中。记住被丢弃的日志确实包含数据，那些数据可能会丢失在这种情况下。如果分歧点小于 waypoint （意味着分歧的日志位于列在数据库头中的“Logs Required” 部分中），那么会发生数据库分歧并需要重设种子。

如 果我们在回到我们的NodeA，NodeB场景中，日志1、2和3已经被提交到NodeA上的数据库。这些日志也已经被复制到NodeB，并已经被重播到 它自己的数据库。接着，NodeA 发生故障，日志4和5都没有复制到NodeB。NodeB接管了群集邮箱服务器，并将存储组加载上线，开始生成它自己的日志4和5，除了生成日志6以外。 NodeA 重新上线，它自己的复制检查了分歧发生在第4个日志文件。NodeA上的复制服务咨询数据库头并判断日志4和5不在需要，它丢弃它们因为它们高于 waypoint 标记。如果我们检查数据库头的话，我们将看到下面这些：

Initiating FILE DUMP mode...

Database: priv1.edb
...

State: Dirty Shutdown

Log Required: 2-3 (0x2-0x3)

Log Committed: 0-5 (0x0-0x5)
...

1.       提交的是第5个日志 (最后生成的日志列在 “Log Committed”).

2.       检查点是第2个日志 (第一个生成的日志列在 “Log Required”).

3.       Waypoint 是第3个日志 （最后一个生成的日志列在 “Log required”).

4.       第4个和第5个日志在waypoint 之外。

复制服务接着从NodeB（参考日志发送和重播部分）拷贝新的日志文件（第4个和第5个）并将它自己的数据库副本更新到最新。

复制服务检查分歧点、删除对于数据库重播来说不需要的日志、并从主动实例拷贝需要的日志文件的过程被称为增量式重新设定种子。

 

数据库重新设定种子场景

在讨论哪些场景要求数据库重新设定种子之前，注意下面的场景不需要数据库重新设定种子。

1.       在计划中断场景中，主动日志文件被关闭所有要求的日志文件被发送到目标数据库副本确保副本激活是无损耗的。

2.       非计划中断，日志发送是健康的同时与主动节点上的日志生成是一致的，数据库副本没有产生分歧。这种情况能够被纠正通过增量式重新设定种子作为LLR 的结果强制数据库落后以更新的日志流能够刚好被应用和向前回滚。对于利用连续复制的环境来说，确保日志发送是健康的是很关键的。

3.       网络中断不需要数据库重新设定种子只要源节点上的日志流没有被截断。日志截断不会自动发生当连续复制处于不健康的状态或其他不可操作的状态。

4.       有多个群集复制主机名称被定义的网络中断不需要数据库重新设定种子，因为在定义的网络中将发生自动切换，这样会确保日志流被成功地拷贝到被动节点。

下面的场景需要重新设定种子：

1.       管理员执行脱机维护 (ESEUTIL 碎片整理, ISINTEG, ESEUTIL 硬修复) 对生产数据库。脱机维护操作像脱机碎片整理更改了数据库的结构并且这些更改不会被记录，因此，数据库需要重新设定种子。

2.       日志流中的一个日志文件损坏或被意外删除在它被拷贝到被动节点之前。在这种情况下，为副本传递该日志的唯一的方法就是执行数据库重新设定种子。

3.       数据库副本产生显著的分歧的时候发生切换。对于这种情况，数据库必须被加载上线要么通过管理员手动设置要么通过设置 ForcedDatabaseMountAfter  值在群集邮箱服务器上。回忆当有损耗切换发生的时候，复制服务计算损失根据日志文件和将它和AutoDatabaseMountDial 值做比较。如果这个损失大于LLR 深度，那么节点之间的数据库分歧已经发生，并且这只能通过执行数据库重新设定种子来纠正。

4.       CCR安装会自动指派群集邮箱服务器的拥有者对于主动和被动节点来说。然而，如果被动节点发生故障或其他原因不可用，被动节点能够从群集邮箱服务器的 RedundantMachines  列表中删除来允许主动实例上的日志截断发生。然而，一旦被动节点被修复或重新加载上线，并被添加到RedundantMachines 列表，被动节点上的数据库将需要重新设定种子因为在日志序列中有一个间隙。

5.       使用 Failover Cluster Management 工具、 Cluster Administrator或 Cluster.exe 来管理CCR环境中的储存组资源能导致数据库分歧。Cluster Administrator 不包含在有损耗故障期间Exchange cmdlets 必须阻止和警告管理员注意的数据库分歧问题的任何逻辑。

6.       在RTM中，如果您启用页面清零功能，这只在联机流备份期间执行。作为结果，页面清零是不会记录操作，因此您将必须执行数据库重新设定种子来传播这些更改。这个问题在SP1中已经被纠正，通过允许页面清零成为联机维护任务的一个内置的选项。

备用连续复制

备用连续复制是一个灾难恢复特性它通过连续复制来创建和维护一个存储组的多个副本。它提供了管理站点弹性的功能。SCR利用与CCR和LCR一样的连续复制技术。下面是SCR和LCR或CCR几个关键的不同之处：

1.       SCR目标上的有损耗激活将从不会调用传输转储程序。

2.       LCR和CCR只支持1:1的复制模型。SCR支持多: 多（1:1、多:1和1:多）的复制模型。（一个源存储组能够被复制到多个SCR目标，尽管我们建议不要超过4个副本）

a)      当计划多:1的复制模型的时候，记住SCR有像CCR或LCR一样的相同路径要求。每个数据库必须被复制到对应的相同的驱动器和路径。当设计源服务器的时候，确保每个文件夹路径是唯一的。

3.       日志拷贝到SRC目标是连续的，然而SCR支持日志重播滞后和日志截断滞后。

a)      重播滞后被设计用来减少需要重设种子的机会当源也使用连续复制并且经历了有损耗故障。在缺省情况下，重播之后被设置为1天。

b)      截断滞后被设计以便目标上的日志能够从源上的损失中恢复。在缺省情况下，截断滞后被禁用。

c)       尽管有重播滞后选项存在，在恢复/激活期间，所有的日志文件都被重播（除非这些日志文件被手动从日志路径中删除）。

4.       对SCR目标初始化数据库重设种子不是立即发生的。在缺省情况下，数据库将不会被重设种子直到50个日志文件被复制后和重播滞后时间已经超过。然而，这个能够被覆盖通过执行Update-StorageGroupCopy 。

5.       没有Exchange 感知的备份机制来备份SCR目标存储组。那就是说，您能够挂起复制，然后对SCR目标上的数据库和日志文件执行平坦的文件备份。

6.       日志截断是SCR感知的。

连续复制和备份

使 用连续复制的一个好处就是减少从活动存储组到被动存储组基于卷影复制服务的备份。在主动和被动存储组和数据库上Exchange 感知的VSS备份是支持的。微软提供的被动副本备份解决方法只是VSS。流备份只在主动存储组上被支持。您不能使用流备份API 来备份被动节点上的数据库。您也需要使用支持Exchange VSS的第三方备份应用程序，因为Windows Server 备份不是Exchange VSS感知的。

当您对被动副本执行VSS备份的时候，事务日志会发生什么情况呢？在Exchange 感知的备份期间一个通用的任务就是截断事务日志文件在备份被成功执行后。连续复制功能保证还没有复制的日志不会被删除。

 

在被动副本上执行备份的挑战是备份修改了数据库的头。例如，它们增加关于数据库上次备份的时间的信息。VSS备份通过复制服务中的Exchange Replica VSS Writer是可能的，复制服务有数据的副本，但是它只能得到它自己的数据和从存储中修改。它不能独立地修改数据库的副本，那将产生分歧。因此，它不能修 改它自己数据库副本的头。

方法是让复制服务通过存储协调它自己的备份。只要您在被动节点上的开始备份，复制服务联系主动节点上存储并告诉它备份将要开始。通过执行它来阻止在主动和被动节点上相同的存储组被同时备份。一旦备份完成，复制服务将联系存储并告知备份已经完成。

从备份导致的数据库头修改接着在主动节点上的存储被修改。这个动作生成一个日志记录，它通过连续复制被拷贝到被动节点。当它被重播的时候，被动节点上的数据库头接着被更新。

这比传统的备份有疑点复杂，并且它还有一些有趣的影响。例如，如果您备份被动节点并在备份完成之后立即检查被动节点上的数据库，它将不会反映备份。然而主动节点上的数据库将反映它。

因此，如果您在连续复制的环境中备份数据库，判断上一次备份的最准确的方法是检查主动节点上的数据库。

另一个影响是，如果信息存储没有运行的话，您不能备份被动节点。运行信息存储是必须的以便备份能够被相互联系起来，并且数据库头能够被更新。

日志截断

日 志截断如何发生，尤其当涉及到连续复制？在Exchange 中，信息存储服务有义务在主动数据库上截断日志文件要么通过ESE.DLL 要么通过ESEBACK.DLL 。使用哪个DLL取决于是否启用连续复制和是否启用循环日志。如果连续复制没有被启用，ESE.DLL有责任执行日志截断当循环日志被启用。否 则，ESEBACK.DLL用于日志截断。

当连续复制被启用，ESE以“不执行循环日志”标记被初始化，不管存储组的循环日志设定。执行这个是因为基于ESE的循环日志是不知道连续复制的。为了让连续复制生效，日志连续性是必须的。因此，日志不能被覆盖直到它们不在被复制引擎所需要了。然而，您

可 以将循环日志记录和连续复制组合使用。在此配置中，将获得称为连续复制循环日志记录 (CRCL) 的新型循环日志记录，它不同于 ESE 循环日志记录。ESE 循环日志记录由 Microsoft Exchange Information Store 服务执行和管理，而 CRCL 由 Microsoft Exchange 复制服务执行和管理。

复制服务（目的节点上如果CCR或SCR部署的话）和信息存储服务通过RPC通信关于哪些日志文件能够被删除在源节点上，ESEBACK.DLL  接着执行日志截断。复制服务负责为数据库副本截断日志。

在LCR或CCR环境中，为了让日志能够被截断，下面的条件必须满足：

1.       日志文件已经被备份（如果循环日志被启用的话忽略）。

2.       日志文件生成序列位于存储组的检查点日志文件之下。

3.       存储组的被动副本允许日志文件被截断（换句话说，被动副本必须已经重播过这些日志文件）。

此外，如果LCR或CCR是SCR目标的源，下面的额外条件必须满足：

1.       所有的SCR目标已经检查过日志文件。

在SCR环境中，如果下面的条件满足的话，SCR目标上的日志文件将被截断。

a)      日志文件生成序列位于存储组的日志文件检查点之下。

b)      日志文件比 ReplayLagTime + TruncationLagTime 旧。

c)       日志文件必须在源上已经被删除。

注 意：有一个已知的问题，日志截断不会发生在SCR目标上如果TruncationLagTime大于ReplayLagTime （即使TruncationLagTime过去之后）。这将影响SCR目标机器的日志驱动器的容量分配。只有两种规避的方法。要么删除不需要的日志文件 （这有一点复杂因为您必须确保它们在ReplayLagTime和 TruncationLagTime之外），要么确保TruncationLagTime小于ReplayLagTime（或禁用它）。为了改变这两个参 数中的任何一个您需要先禁用SCR然后接着重新启用它使用新的值。该问题期望在将来的SP1的汇总更新中被修复。

将连续复制和其他复制方法做比较

微软建议为邮箱数据库可用性使用连续复制而不是其他的复制方法。对于第三芳复制方法要仔细考虑下面这些问题。

1.       因为第三方复制方法不是Exchange 感知的，它们不知道如何在应用层去验证被拷贝的数据来确保它们是可用的。此外，因为该方法不是Exchange 感知的，它们要求更复杂的特别的步骤来激活。

2.       为了被Exchange 支持第三方复制方法必须是同步的。同步方案要求活动和被动副本之间有好的延迟。

3.       第三方复制方法也许要维护两个并不是相互独立的副本。这意味着在硬件（Exchange 、操作系统、存储组件等）上执行的许多层中有一层出现损坏的话将被复制到第二个副本中，导致很高的恢复点目标（RPO）因为两个副本最终都损坏了。

通过对比，连续复制提供了下面这些方案。

1.       连续复制被集成到Exchange 服务器中提供了一个完整的Exchange 感知的副本通过集成的cmdlets和过程来激活、管理和监视副本。例如，当将复制和群集技术结合起来，CCR提供了集成的服务器和数据冗余，提供了自动 服务器和数据同时切换。

2.       使用异步复制来发送关闭的事务日志到第二个副本，使它非常有效率同时对延迟问题有很好地弹性。

3.       使用的是相互独立的副本，因此像第三方解决方法复制的故障问题不会被连续复制复制。例如，如果主动数据库上产生-1018错误，被动副本将不会遇到相同的问题（假设独立的存储解决方案）。

 

4.       数据库副本的日志被单独验证在它们被重播到数据库副本中之前。

5.       数据库副本的激活是相当地快。例如，在CCR环境中，数据库副本切换到被动节点被集成到Exchange 中，大约只要花两分钟。

6.       对于LCR和CCR场景来说，当发生有损耗故障，唯一丢失能够被丢失的数据是没有经过中心传输服务器的数据。这些数据的小集合只包含联系人、任务、私人邀 请、便签和草稿。任何已经经过中心传输的数据被保存在传输转储程序中以一段可配置的时间，并被重新提交到邮箱服务器。

结论
 
连续复制通过异步复制或日志发送维护数据的副本来为Exchange 2007 提供数据可用性。复制是基于ESE日志，关闭的日志文件被复制、验证然后接着被重播到数据库的副本中。

由 于连续复制是异步日志复制模型，Exchange 2007 中的ESE被增强用于减少要求数据库重新设定种子的可能性在非计划中断事件中。丢失的日志弹回延迟提交更改到数据库直到一个或多个日志文件被复制后，因此 减少了需要执行数据库重新设定种子的需要如果两个副本出现分歧。


此外，连续复制也通过传输转储程序来重新传递那些最近被提交给邮箱服务器在故障事件之前的邮件。这允许邮箱服务器恢复那些可能被记录但还没有复制到被动副本的电子邮件数据。