本地连续复制
适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
上一次修改主题： 2008-01-17
本地连续复制 (LCR) 是一种单服务器解决方案，它通过使用内置异步日志传送和日志重播技术，在与生产存储组所在的服务器相连接的另一个磁盘集上创建并维护存储组的副本。生产存储组称为“主动”副本，在独立的磁盘组上维护的存储组副本称为“被动”副本。下图介绍了 LCR 的基本部署。
LCR 的基本部署
.gif "本地连续复制的基本结构")
LCR 提供日志传送、日志重播以及到辅助数据副本的快速手动切换（称为“激活”）。LCR 可以通过下列方式降低 Microsoft Exchange Server 2007 的总拥有成本：
允许快速切换到数据辅助联机副本，从而缩短了数据级灾难的恢复时间。
减少了数据保护所需的定期完全备份次数。发生灾难时，数据备份非常重要。尽管 LCR 仍需要进行备份，但确实明显减少了每天定期执行完全备份的需要。
还能够减少从存储组的主动副本到存储组的被动副本的卷影复制服务 (VSS) 备份数。所有四种 VSS 备份类型（完整、副本、增量和差异）都可以在被动副本位置进行，减少从主动副本到被动副本的备份数可以保留主动副本逻辑单元号 (LUN) 上宝贵的磁盘输入/输出 (I/O)。
LCR 允许配置、运行、验证、删除和激活存储组副本。必要时，可以作为生产数据库激活被动副本，然后装入并使其可用于客户端。通常，能够以更改配置的形式执行此任务：更改主动存储组和数据库路径或进行较低级别的操作系统操作（例如，更改与日志或数据库卷关联的装入点）。
LCR 没有任何特殊的存储要求。Windows Server 2003 或 Windows Server 2008 所支持的任何类型的存储都可用于 LCR，包括直接连接存储、串行连接 SCSI 和 Internet SCSI (iSCSI)。有关经过验证的存储解决方案列表，请参阅 Windows Server Catalog of Tested Products（Windows Server 已测试产品编录）。
对于需要从邮箱数据失败或损坏中快速恢复但允许服务器由于计划或未计划的原因中断的用户，LCR 是一个极好的选项。LCR 具有以下功能：
从生产数据库损坏或失败中快速恢复（两步）。
对最需要保护的用户提供保护。
对生产数据库和日志磁盘 I/O 的影响最小。
将 VSS 备份卸载到数据库和日志的被动副本的能力。
减少移动到备份媒体的总数据量，同时扩展备份窗口的能力。
可通过 Exchange 管理控制台或 Exchange 命令行管理程序进行管理。
对 Exchange 2007 SP1 中 LCR 的增强
Microsoft Exchange Server 2007 Service Pack 1 (SP1) 包含 LCR 的几项改进，包括使用传输垃圾站、增加了 Exchange 管理控制台用户界面元素、改进了状态和监视并且提高了性能。
对 LCR 启用传输垃圾站
在 Exchange 2007 SP1 中扩展了集线器传输服务器角色的传输垃圾站功能以便支持 LCR。在正式发布 (RTM) 版本的 Microsoft Exchange Server 2007 中，传输垃圾站只能用于群集连续复制 (CCR) 环境。与 CCR 不同，在 CCR 中请求传输垃圾站重新发送是恢复过程的自动部分，但在 LCR 环境中，该过程是手动的。在 Exchange 2007 SP1 中，Restore-StorageGroupCopy cmdlet 已经更新为包含传输垃圾站重新提交请求。因此，当管理员在 LCR 环境中使用 Restore-StorageGroupCopy cmdlet 激活存储组的被动副本时，作为激活过程的一部分，需要提出传输垃圾站提交请求。
传输 Dumpster 利用环境中的冗余回收一些受故障转移影响的数据。具体地说，中心传输服务器维护最近传递邮件的队列。此队列受邮件保留时间和占用的总空间的约束。已经向 Restore-StorageGroup 任务中添加了新的功能，以便当管理员使用该任务激活存储组的被动副本时，Microsoft Exchange 复制服务请求从邮箱服务器站点中的每个集线器传输服务器重新发送传输垃圾站中的邮件。信息存储会自动删除重复的邮件，并重新传递丢失的邮件。
在 Exchange 2007 SP1 中，将电子邮件保留在传输垃圾站中的必要条件是：至少有一个收件人的邮箱位于 CCR 环境的群集邮箱服务器上，或者位于已经配置为 LCR 的存储组中的单独服务器上。
传输 Dumpster 不能减少数据丢失的情况包括：
处于联机模式的任何 Microsoft Outlook 客户端的草稿文件夹。
约会、联系人更新、属性更新、任务和任务更新。
从客户端传输到中心传输服务器的传出邮件。其中有一个时段，电子邮件只存在于发件人的邮箱服务器上。
有关如何配置传输垃圾站设置的详细步骤，请参阅如何为本地连续复制配置传输转储程序。
Exchange 管理控制台增强
在 Exchange 2007 SP1 中已经添加了几个新的用户界面元素，这些元素改进了高可用性功能（包括 LCR）的管理体验。这些改进包括：
传输垃圾站用户界面 已经向“组织配置”工作区域下的“集线器传输”节点添加了新的“全局设置”选项卡。此选项卡包含一个“传输设置属性”页，它可用于配置组织的传输垃圾站设置：
每个存储组的最大大小 (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 进行了增强：
当目标计算机上的 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 中，为每批日志重播活动创建了一个新的数据库缓存，在某些情况下使被动 LUN 上的磁盘 I/O 活动两倍或三倍于主动 LUN。
对 LCR 使用备用连续复制
备用连续复制 (SCR) 是 Exchange 2007 SP1 中引入的一个新功能。SCR 会扩展现有连续复制的功能，并使新数据可用于 Exchange 2007 邮箱服务器。SCR 使用与本地连续复制 (LCR) 和群集连续复制 (CCR) 相同的日志传送和重播技术，以提供更多的部署选项和配置。
SCR 使您能够使用连续复制从单一副本群集 (SCC) 或 CCR 环境中的单独邮箱服务器（使用 LCR 或不使用 LCR）或者群集邮箱服务器复制邮箱服务器数据。
激活由 SCR 创建和维护的邮箱服务器数据副本的过程是手动过程，设计用于在发生重大故障时使用。该过程不用于可以通过重新启动或某些其他快速方法恢复的简单服务器中断。可以使用数据库可移植性、服务器恢复选项 (Setup /m:RecoverServer) 或者群集邮箱服务器恢复选项 (Setup /RecoverCMS)（如果邮箱服务器是群集服务器）激活 SCR 目标。将根据您的配置和发生故障的类型选择选项。
有关 SCR 的详细信息，请参阅备用连续复制。
详细信息
下列主题讨论了何时以及如何使用 CCR 作为高可用性和数据复原计划的一部分：