本地连续复制的计划

项目
08/07/2014

适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

上一次修改主题： 2008-01-04

本地连续复制 (LCR) 的计划包括设计存储组和数据库拓扑，并确保提供足够的存储解决方案支持以及足够的 LCR 监视。

LCR 的存储要求和建议

LCR 包括一些存储要求和建议。设计 LCR 存储解决方案时，包括 LCR 的其他输入/输出 (I/O) 用法，因为 LCR 环境涉及由主动副本负责的日志更新和类似的由依靠被动副本的日志读取。建议设计存储，以便被动副本具有与主动副本相似的功能和性能。使用 LCR 时，建议您采用以下最佳做法：

每个存储组使用一个数据库 为 LCR 启用存储组后，存储组只能包含一个数据库。此外，如果现有存储组包含多个数据库，则将无法为该存储组启用 LCR，直到删除至只有一个数据库为止。此方法将创建一个更加容易管理的 Microsoft Exchange 存储拓扑，可以提高可恢复性。
使用卷装入点 可使用 Exchange 数据逻辑单元号 (LUN) 或磁盘的驱动器号或卷装入点来指定数据库文件和事务日志文件的存储位置。建议您使用 NTFS 文件系统卷装入点功能超出每个 Exchange Server 上存在的 26 个驱动器号的限制。使用卷装入点可以将目标分区接到（或装入）另一个物理磁盘的某个文件夹中。卷装入点对程序（包括 Exchange Server）是透明的。如果在生产事务日志或数据库文件中检测到损坏，则使用卷装入点可以快速更改驱动器号分配和路径，从而简化恢复过程。有关从生产事务日志或数据库文件的损坏中恢复的详细信息，请参阅管理本地连续复制。
为提高性能和恢复能力对数据进行分区 通常，对跨多个硬盘的数据进行分区可提高性能并减少需要恢复的数据量。根据故障类型的不同，将数据库和事务日志文件放在不同的磁盘上可显著减少数据丢失。例如，如果将 Exchange 数据库和事务日志文件保存到同一物理硬盘，当磁盘出现故障时，只能恢复那些存在于上次备份中的数据。或者，考虑将日志文件和数据库文件放到不同的磁盘上。如果包含数据库文件的磁盘出现故障，则可从存在于不同磁盘上的日志文件中恢复数据。若要实现最佳性能，提高容错能力，同时更易于进行故障排除，应该对数据进行分区，以便使下列文件位于不同的磁盘上：
- Microsoft Windows 操作系统文件
- Exchange Server 应用程序文件
- 主动副本上的 Exchange 数据库文件
- 主动副本上的 Exchange 事务日志文件
- 被动副本上的 Exchange 数据库文件
- 被动副本上的 Exchange 事务日志文件
此外，应该将启用 LCR 的存储组的被动副本放到与其主动副本所在磁盘不同的磁盘上。而且，应确保包含 LCR 文件的磁盘与包含生产存储组的磁盘具有相同的性能。只有二者性能相同，才允许 LCR 副本支持故障转移时的负载。
确保充足的磁盘空间 包含 LCR 文件的磁盘的大小应与生产卷相当。被动副本使用的存储应等于主动副本使用的存储。此外，这两个存储解决方案都需要有足够的空间，用于容纳现有数据库以及任何可预见的数据库大小的增长。
对 LCR 使用 iSCSI 存储时确保具有足够的带宽和低延迟 尽管不建议这样做，但是它支持使用通过局域网 (LAN) 或广域网 (WAN) 链接连接到邮箱服务器的 Internet SCSI (iSCSI) 存储配置 LCR。在此配置中，将在同一个存储网络上发生日志传送和日志重播活动。不鼓励此配置的主要原因是由于日志传送生成网络通信。若要使 LCR 提供所期望级别的保护，保持日志传送最新以及与日志传送关联的网络通信不占用大量带宽（这样会妨碍与日志重播活动关联的网络通信）非常重要。没有办法对复制通信划分优先级。此外，还必须考虑某些存储要求：
- 在 Microsoft Exchange Server 2007 的正式发布 (RTM) 版本中，数据库被动副本的存储必须提供用于数据库主动副本的存储的两到三倍的每秒 I/O (IOPS)。
- 在 Microsoft Exchange Server 2007 Service Pack 1 (SP1) 中，被动副本的存储可以等效于主动副本的存储。

注意：
可以使用 Microsoft Exchange Server Jetstress 工具先验证您的存储解决方案，然后再投入使用。建议您首先验证用于数据库主动副本的存储，然后再验证用于数据库被动副本的存储。有关 Jetstress 的详细信息，请参阅存储验证中的“与存储相关的工具”。

LCR 的处理器和内存建议

如果启用了 LCR 的邮箱服务器的所有 Microsoft Exchange Server 2007 邮箱服务器角色服务以及 Microsoft Exchange 复制服务都在同一台服务器上运行，则需要额外的硬件资源来处理此额外负载。此额外资源占用的绝大部分来自启用了 LCR 的邮箱服务器上的日志文件验证和日志文件重播。这种额外处理开销大约是 20%（超过了规划处理器配置中列出的处理器指导要求），在确定 LCR 邮箱服务器大小时，应考虑此因素。另外，根据提供的内存资源，Microsoft Exchange 复制服务会在 LCR 服务器上正常运行。但是，为确保可扩展存储引擎 (ESE) 数据库缓存在 LCR 环境下保持最佳效率，建议为 Exchange 邮箱服务器和多角色服务器额外提供 1 GB 物理 RAM（超过了规划内存配置中列出的内存指导要求）。

LCR 的数据库大小建议

LCR 为从灾难性数据丢失中进行恢复提供了很大的灵活性。对于使用 LCR 时发生的灾难性存储故障或物理数据库损坏，第一道防线是激活数据的被动副本，而不是从备份进行任何还原。请记住，LCR 可提供快速数据恢复，但它不是备份解决方案。LCR 使得拥有较短的还原时间目标 (RTO)（基于从存档或磁带进行还原）的重要性大大降低。激活了被动副本（而不是从磁带进行还原）后，这些数据会在数分钟内（而不是数小时内）即可供客户端使用。从这种意义上说，LCR 可被认为是一种快速恢复机制，可归入与使用 Exchange Server 2003 中的卷影复制服务 (VSS) 创建的基于硬件的克隆相同的类别。

对于管理员而言，由于进行了不良备份而必须执行脱机数据库操作（如修复）是很常见的。（例如，磁带已损坏或还原失败。）虽然发生必须进行修复的情况的百分比应显著降低，但是，有些时候仍然必须要进行修复。请确保在决定数据库大小时考虑您对最坏情况停机时间的容忍程度。

LCR 允许您基于存储组的被动副本生成备份，这将允许您在主动副本上扩展联机维护窗口。在许多情况下，您可使联机维护窗口扩展一倍，从而使您拥有更大的邮箱和数据库。

从这一点来看，使用 LCR 似乎可以随心所欲地增大数据库而不会产生风险；但是，实际情况并非如此。对于每个数据库而言，应在合理的时间量内完成的联机维护仍然是数据库大小的限制因素。使用 LCR 时，需要将数据库重新设定为种子的可能性也是一个限制因素。LCR 提供了数据库冗余，因此，如果数据库的主动副本丢失或损坏，则可通过手动激活数据库的被动副本来快速完成恢复。

激活发生后，仍只保留数据库的一个副本，该副本是新的主动副本。由于被动副本已不再存在，因此数据库回弹可能会出现问题。但是，您应该还有备份。若要启用回弹，需要将丢失或损坏的数据库删除，并需要创建数据库的新被动副本并从主动副本将该新副本重新设定为种子。这些任务可能需要很长时间，具体取决于数据库的大小。最坏情况就是丢失或损坏了所有主动副本，在此情况下，必须将所有被动副本重新设定为种子。

使用连续复制时可以使用更大的最大数据库大小。建议 Exchange 2007 使用以下最大数据库大小：

不使用 LCR 时邮箱服务器上驻留的数据库：100 GB

使用 LCR 时邮箱服务器上驻留的数据库：200 GB

要点：
数据库实际的最大大小应由您的组织已有的服务级别协议 (SLA) 决定。确定可在组织的 SLA 中指定的时间段内备份和还原的最大大小的数据库，就是确定数据库最大大小的方法。

LCR 和公用文件夹数据库

LCR 和公用文件夹复制是内置到 Exchange 中的两种非常不同的复制形式。由于连续复制和公用文件夹复制之间的互操作性限制，如果 Exchange 组织中的多个邮箱服务器具有公用文件夹数据库，则启用公用文件夹复制，因此不应将公用文件夹数据库驻留在为 LCR 启用的存储组中。

以下是在 Exchange 组织中使用公用文件夹数据库和 LCR 的建议配置：

如果 Exchange 组织中只有一个邮箱服务器，而且该邮箱服务器是独立服务器，则邮箱服务器可以在为 LCR 启用的存储组中驻留公用文件夹数据库。在此配置中，Exchange 组织中只有一个公用文件夹数据库。因此，禁用公用文件夹复制。
如果具有多个邮箱服务器，且其中只有一个邮箱服务器包含公用文件夹数据库，则邮箱服务器可以在为 LCR 启用的存储组中驻留公用文件夹数据库。在此配置中，Exchange 组织中只有一个公用文件夹数据库。因此，禁用公用文件夹复制。
如果要将公用文件夹数据迁移到为 LCR 启用的存储组中，则可以使用公用文件夹复制将公用文件夹数据库的内容移动到为 LCR 启用的存储组中的公用文件夹数据库。在启用 LCR 的存储组中创建公用文件夹数据库后，其他公用文件夹数据库仅应在您的公用文件夹数据完全复制到启用 LCR 的存储组中的公用文件夹数据库之前存在。复制成功完成后，应该删除已启用 LCR 的存储组之外的所有公用文件夹数据库，且不应在 Exchange 组织中驻留任何其他公用文件夹数据库。
如果要将公用文件夹数据迁移到为 LCR 启用的存储组之外，则可以使用公用文件夹复制将公用文件夹数据库的内容移动到为 LCR 启用的存储组中的公用文件夹数据库之外。在为 LCR 启用的存储组之外创建其他公用文件夹数据库后，为 LCR 启用的存储组中的公用文件夹数据库应仅在您的公用文件夹数据完全复制到其他公用文件夹数据库之前存在。复制成功完成后，应该删除已启用 LCR 的所有存储组内部的所有公用文件夹数据库，且不应在为连续复制启用的存储组中驻留所有后续公用文件夹数据库。

在 Exchange 组织中存在多个公用文件夹数据库且一个或多个公用文件夹数据库驻留在为 LCR 启用的存储组中的任何期间内，如果 LCR 主动存储组出现故障且需要激活包含公用文件夹数据库的存储组的被动副本，则仅当驻留公用文件夹数据库的存储组的所有日志都可用时才可以使它成为可装入的存储组。如果由于主动副本出现故障而导致任何日志丢失或不可用，则将无法激活公用文件夹数据库的被动副本。在这种情况下，必须使主动副本联机才能确保数据不会丢失，或者必须在存储组的主动副本中重新创建公用文件夹数据库，且必须使用公用文件夹复制从被动副本之外的公用文件夹数据库恢复其内容。

LCR 的监视建议

LCR 是一个数据可用性解决方案。需要主动监视。Exchange 2007 会发布 LCR 副本的各种状态信息。为存储组启用 LCR 之后，可以使用 Exchange 管理控制台和 Exchange 命令行管理程序查看 LCR 副本的状态和配置设置。有关如何查看状态和配置信息的详细步骤，请参阅如何查看本地连续复制副本的状态。

若要进行主动和自动监视，我们建议您使用 Microsoft Operations Manager (MOM) 以及 MOM Exchange 2007 管理包。有关监视 LCR 的详细信息，请参阅监视和操作管理。

在 Exchange 2007 SP1 中，您还可以使用一个名为 Test-ReplicationHealth 的新 cmdlet 来验证启用了 LCR 的存储组的运行状况和状态。有关 Test-ReplicationHealth cmdlet 的详细信息，请参阅Test-ReplicationHealth。

备份、还原和 LCR

LCR 提供日志传送、日志重播以及到辅数据副本的快速手动切换。这些功能缩短了数据级灾难所需的恢复时间。LCR 还减少了充分保护数据所需的备份数。尽管 LCR 仍然需要建立备份，但它降低了每天进行的完整备份数。另外，利用 LCR 还可以使卷影复制服务 (VSS) 备份从主动存储组转移到被动存储组。所有四种备份类型（完整、副本、增量和差异）都可以在被动副本位置进行，这样可以保留主动副本的 LUN 上的重要磁盘 I/O，以便为客户端提供服务。

与以前的备份解决方案相比，除了降低总拥有成本 (TCO) 以外，LCR 还具有其他优势。使用 LCR 还可以拥有其他的 Exchange 数据库副本，这提供了以下优点：

降低数据库的备份频率 LCR 副本是生产数据库故障的第一道防线。在需要备份副本之前，生产存储组和存储组副本均可能会出现故障。因此，在这种情况下建议采用更长的服务级别协议 (SLA)。如果采用较长的 SLA，建议每周进行完整备份且每天进行增量备份。
快速从灾难中恢复 通常，该恢复过程只需要不到 10 分钟时间，并且几乎不会或完全不会出现数据丢失现象。
支持更大的邮箱配额 此支持是快速恢复的结果，与数据库大小无关。

有关备份和还原的详细信息和特定指南，请参阅灾难恢复。

Exchange 备份和 LCR

主动存储组和数据库以及被动数据库副本都支持 Exchange 感知备份。

注意：
Exchange 感知备份期间的一项常见任务是，在备份成功完成之后截断事务日志文件。LCR 中的复制功能可以确保尚未复制的日志不会被删除。因此，如果在日志复制足够晚的阶段运行复制，则在删除日志的模式下运行备份实际上可能不会释放空间。

在此配置中，Exchange 感知备份可以使用流式备份解决方案或 VSS 备份解决方案执行。流式备份只能对主动副本执行，而 VSS 备份可以对主动副本或被动副本执行。

Exchange 还原和 LCR

Exchange 感知还原可以使用流式备份解决方案或 VSS 备份解决方案执行。还原可以以活动数据库和日志文件位置为目标。本身不支持通过 Exchange 感知的还原将数据库备份直接还原到被动副本位置。可以通过文件级别的还原，手动还原到被动副本位置。

从为 LCR 配置的存储组还原数据库之前，应挂起该存储组的 LCR。还原完成后，可以恢复 LCR。所还原的数据库的 LCR 应挂起。

将数据库从备份还原到启用 LCR 的存储组后，必须分别使用 Suspend-StorageGroupCopy 和 Resume-StorageGroupCopy 来挂起并恢复存储组的连续复制。该过程需要使用正确的日志生成信息更新 Microsoft Exchange 复制服务。如果不挂起和恢复连续复制，则 Microsoft Exchange 复制服务将包含过时的日志生成信息，并将停止复制日志文件。

通过