Exchange Server 多站点数据复制的部署指南

  • 项目

 

上一次修改主题： 2006-09-01

复制技术可以为 Microsoft® Exchange Server 数据提供高可用性。本主题旨在帮助您更好地了解复制存储技术以及如何在 Exchange Server 环境中使用该技术。

复制通过在多个站点上提供冗余数据来支持高可用性，但是无法避免数据损坏。如果将任何有害数据写入主存储设备而导致数据库损坏，相同的有害数据也将复制到远程站点并破坏远程站点的数据库。因此，数据复制不能取代数据库维护过程（例如定期验证数据库完整性的数据库备份）。

在本主题中，所讨论的数据类型是通过运行 Exchange 服务（例如 Exchange 进程发出的任何写入 I/O 请求）访问的数据。本主题不讨论系统/操作系统的数据复制。

Microsoft 为各种类型的复制解决方案提供了支持策略。有关这些支持策略的详细信息，请参阅 Microsoft 知识库文章 895847“Multi-site data replication support for Exchange 2003 and Exchange 2000”（英文）。

note注意：
下载 Deployment Guidelines for Microsoft Exchange Server Multi-Site Data Replication（英文），以便脱机打印或阅读。

复制机制

使用数据复制的目的是为了在远程站点上维护数据的最新副本。Exchange 服务器可以使用远程站点上的副本，在主位置的存储或站点出现故障时不间断地提供电子邮件服务。可以通过同步或异步的方式传播数据复制。根据定义，如果同步复制数据，则在本地位置和远程位置同时提交 I/O 写操作时，主机将只会从存储区获得写入完成的响应。也就是说，本地存储和远程存储必须在向主机确认写操作已成功之前实施更改。在异步模式下，将写操作提交到本地存储时，主机将从存储区获得写操作完成的响应，而不必等待远程存储确认其也已更新副本。

异步复制

通常，与同步复制模式相比，在使用异步复制时，主机应用程序的写入延迟对于复制距离的增大没有那么敏感。但是，在部署异步复制时，应注意下列问题：

  • 数据丢失   根据数据复制的频率，远程站点上的数据更改可能会滞后于主站点上进行的更改。如果主站点出现故障，远程站点的副本不会完全是最新的。尽管大多数存储解决方案可以配置此延迟，但是，应注意由于此行为而可能造成的数据丢失。
  • 数据完整性（写入顺序保留）   Exchange 在数据库与其关联的事务日志之间存在写入顺序相关性。Exchange 总是先将更改写入日志文件，然后再将这些更改提交到数据库文件。处于同步复制模式时，由应用程序会控制写入顺序。但是，在异步模式下，由复制解决方案控制何时复制数据。如果解决方案在复制期间不维持写入顺序，在主站点发生灾难时，则可能会破坏数据库文件并使数据库无法装入。
  • 性能影响   许多供应商声称其异步解决方案不会影响存储性能，但实际上，运行异步复制时将降低性能。无法通过一个数字来描述对性能的预期；这取决于解决方案的实施方式。因此，客户在部署之前应仔细地测试解决方案，目标是验证解决方案是否可以为 Exchange 用户提供足够的存储性能。

某些解决方案提供商使用各种技术来解决写入顺序保留的问题。为了成功地部署异步复制解决方案，客户必须与供应商合作，以确保其异步技术满足下列要求：

  • 可以保持存储组中所有设备的写入顺序一致性，包括相互之间要持续一致；
  • 业已证明是可以恢复的，而在实验室环境和生产环境中均更容易恢复；
  • 供应商为复制数据提供了适当的支持计划。

同步复制

Exchange 部署中的同步复制主要考虑的是性能。测试已表明，客户端体验与写入延迟密切相关。使用同步复制解决方案，将减少每台 Exchange 服务器可以承载的邮箱数。性能影响主要取决于复制距离、复制链路带宽和利用率。同步复制可能使邮箱/服务器的可伸缩性下降高达 75%。在使用 Exchange 容量规划方法时，应考虑此可伸缩性下降的因素。有关详细信息，请参阅本主题后面的“同步复制的部署规划”。

通常认为同步复制解决方案可以确保不会丢失任何数据，因为副本与主存储数据文件完全同步。但是，与这种常见的看法相反，有些情况下，同步复制解决方案可能会丢失数据。下例说明了此类情况。

通常，存储数据复制解决方案通过下列两种方式之一处理复制链路故障:

  • 继续将写入 I/O 只提交到主存储设备，将对使用该复制链路的所有设备所做的所有更改记录在日志文件中，并将日志存储在主存储中。
  • 使写入操作失败，以便应用程序像磁盘出现故障一样处理该失败。

如果复制解决方案使用第一种处理方法，则可能会丢失数据。在主站点出现故障后很快发生的链路故障期间，将不会复制链路故障之后提交的数据；因此，这些数据将随着主存储的故障而一起丢失。在设计存储复制解决方案时，请记住上述故障条件的类型，以便使构建的系统可以减少此类情况的发生。在此示例中，客户可能希望考虑部署冗余复制链路，以减小丢失数据的可能性。

同步复制解决方案

同步复制解决方案按照进行复制的位置分类，分为基于主机的复制或基于存储的复制。基于主机的复制通常使用基于主机的软件（筛选器驱动程序）中断 I/O 流，以管理复制。基于存储的复制脱离主机，在存储设备级别进行。这两种复制解决方案均可以作为下列对象的一部分进行部署：

  • 地理位置分散的群集 (Geocluster)   在此类别中，属于同一群集的节点位于不同的站点中。通常，Exchange 服务器由主站点上的节点主动承载。解决方案支持将 Exchange 数据同步复制到远程站点。如果主站点发生灾难，Exchange 虚拟服务器将故障转移到远程站点上的被动节点，并使用复制的 Exchange 数据联机。
    Microsoft Windows® Server Catalog 包含一个用于地理位置分散的群集解决方案的类别。可以在 https://go.microsoft.com/fwlink/?LinkId=28572 上搜索 Windows Hardware Qualified Labs (WHQL) 认证的地理位置分散的群集解决方案。
  • 其他   此类别包含所有其他不使用地理位置分散的群集的同步复制部署类型。如果主站点出现故障，这些解决方案将依靠其他一些方法来使用远程站点上复制的 Exchange 数据（例如备用解决方案；复制与灾难恢复过程相结合）。

Microsoft 极力建议客户从复制解决方案供应商获得有关下列问题的保证：

  • 解决方案是否属于地理位置分散的群集解决方案的类别？如果是，WHQL 是否已认证？如果不属于此类解决方案，存储设备是否在 Windows Server Catalog 的“Cluster Solutions, Geographically Dispersed Clustering Solution”（英文）部分所述的解决方案中列出？
  • 复制解决方案是否可以避免所有可能的数据丢失（除了所有站点同时中断服务之外）？
  • 进行故障转移和故障回复的步骤是什么？
  • 复制解决方案和预期的延迟是否可以处理规划的 Exchange 用户负载并提供高质量的客户端体验？

要复制的 Exchange 数据

Exchange 是以数据为中心的服务器应用程序。将 Exchange 数据复制到辅助站点后，可以在发生与存储有关的故障时提供冗余。准确确定要复制的数据类型是一项商业决定。应评估您的业务容许丢失此处所述的各种数据类型的程度。

必须复制的数据

必须复制以下数据：

  • Exchange 邮箱数据库文件存储邮件数据。每个数据库由两个文件组成：
    • 数据库文件 (.edb)，用于存放邮件和 MAPI 内容。
    • 流文件 (.stm)，用于存放非 MAPI 本机内容。
  • 事务日志文件 (.log)，用于记录提交到数据库的每个事务。
  • 检查点文件 (.chk)，其中包含已写入磁盘的日志文件中的条目的有关信息。

对于客户端访问邮箱服务器以及软恢复存放在内存中、在 Exchange 服务器的存储未正常关闭（例如断电）时将丢失的数据库更改，所有这些文件都必不可少。由于这些文件的关键性，所以必须复制这些数据。数据库文件的路径在数据库属性页上指定，每个数据库都有自己的路径。事务日志文件路径和检查点文件路径在存储组属性页上指定，该存储组中的所有数据库都依赖于这些路径。

决定复制公用文件夹数据库是更加复杂的一项决定。是否要这样做部分取决于部署的 Exchange 拓扑设计。与邮箱数据不同，Exchange Server 可以直接复制公用文件夹数据。可以有多个公用文件夹存储副本，用于复制更改（内容）。不会以同步方式执行此数据复制。

Geocluster 解决方案要求同步复制群集中的公用文件夹。要使群集在辅助站点上全功能运行，需要满足此要求。群集中的邮箱数据库必须指向同样在该群集中的公用文件夹存储（“默认公用存储”），以便群集在辅助站点中可用之后，客户端能够立即登录。geocluster 中的公用文件夹只需要承载层次结构，不必承载完整内容，这样便于在出现故障时登录邮箱。选择承载完整的公用文件夹内容并同步在 geocluster 承载的公用文件夹中进行复制是一项商业决定。如果公用文件夹数据对于核心业务必不可少，则意味着只能接受最少量的数据丢失，则应考虑使用 geocluster 解决方案，而不是使用 Exchange Server 公用文件夹复制机制。如果不需要此级别的公用文件夹数据可用性，则可以将用于邮箱数据的非 geocluster 同步复制解决方案与 Exchange 公用文件夹中的复制机制组合使用。

建议复制的数据

简单邮件传输协议 (SMTP) 本地队列数据 （Mailroot 目录） 暂时存放在存储设备中，将由 Exchange Server 进行处理。此设计防止在服务器出现故障中丢失数据。例如，在目标服务器无法访问时，应路由到该服务器的邮件将存储在本地服务器队列目录中，直到可以投递。如果存储队列数据的磁盘出现故障，则队列中的所有邮件都将丢失。由于队列数据的暂时性，没有像定义备份 Exchange Server 数据库的进程一样定义备份邮件队列的进程。为存放此队列信息的存储提供容错和/或可用性解决方案可以避免可能发生的数据丢失。如果所处环境不能因为站点故障而丢失暂存邮件，则也建议复制 MTA 队列数据（MTADATA 目录）。

SMTP Mailroot 的路径（包括每个虚拟服务器实例的 Queue 和 Badmail 目录）是在 Exchange 系统管理器 (ESM) 的“SMTP 虚拟服务器”属性页的“邮件”选项卡上，以及在 MTA 队列路径的 X.400 属性页上指定的。应查看配置文件，以决定是否需要复制 Exchange 队列数据。如果有现有的 Exchange 拓扑，则可以决定是否能够容忍本地队列中的数据丢失。在负载高峰期，可以使用性能监视器 (Perfmon.msc) 中的本地队列长度，或使用 ESM 中的队列查看器，评估本地队列中预期的数据量。如果需要复制队列数据，则需要测试复制环境中的邮件处理性能，以便出现的复制延迟不会造成传输瓶颈。可以使用 Exchange Server 压力和性能 2003 工具测试复制队列数据的同步复制环境中的传输吞吐量。可以从 Exchange Server 压力和性能 2003 网站下载该工具。

可选复制的数据

邮件跟踪日志包含传输到 Exchange 服务器、由 Exchange 服务器传输以及在 Exchange 服务器内部传输的所有邮件的信息。此数据对于诊断非常重要。默认情况下不启用邮件跟踪。但是，如果此数据对您的业务非常重要，则可能会进行复制，避免在发生灾难时丢失。邮件跟踪日志的路径在 ESM 的 Exchange Server 属性页上指定。

配置复制机制的最佳实践

每个供应商都有自己专用的复制机制实现方式，为不同的复制方法提供。应与特定的供应商讨论解决方案细节，以确定提出的解决方案是否最适合对灾难恢复的组织要求以及服务级别协议 (SLA)。下列建议可能仅适用于某些复制解决方案：

note注意：
“复制点”一词定义为进行复制的位置。根据解决方案的不同，此位置可能在主机筛选器驱动程序级别上，也可能在存储阵列中的某个磁盘切片上。
  • 在逻辑/装入点卷级别配置复制。
    即使需要复制的数据存放在本主题的“要复制的 Exchange 数据”中所述的文件中，也必须确保在主机级别为复制配置逻辑/装入点卷的单元。例如，如果邮箱数据路径是 G:\MDB1\MDB1.EDB，则驱动器 G 应为执行复制的基本单元。因此，将复制驱动器 G 上的所有数据。将复制设置为在文件或子目录级别进行时容易发生人为错误，Microsoft 不支持此设置。
  • 创建许多复制点。
    为了缩短目标为同一个复制点的多个 I/O 的队列，请将存储配置为创建尽可能多的复制点。在许多复制点上平衡 I/O 的负载。根据存储/复制解决方案的不同，因为 I/O 队列的缩短，此方法可以缩短总体 I/O 读/写延迟。
  • 将事务日志保留在不同的逻辑卷上。
    在复制数据时，每个写入 I/O 请求将在复制点级别排队。Exchange 以连续模式写入日志，如果这些 I/O 的目标为同一个复制点，则每个 I/O 很可能将排队等待写入。这样会延长日志写入响应时间，可能对 Exchange 的性能/可伸缩性产生显著的负面影响。因此，Microsoft 建议您使用不同的复制点将不同存储组中的事务日志分段到不同的逻辑卷上。
  • 使用多个复制链路。
    通常，可以通过在主要站点与辅助站点之间配置多个复制链路，提高复制解决方案的性能/可伸缩性。此方法实施起来可能非常昂贵，Exchange 数据复制并不要求这样做。但是，有些部署中必须实施多个复制链路，给定的 Exchange 数据复制方案才能获得所需的性能/伸缩性。可能还需要在可用的复制链路上平衡复制点的负载，以优化复制的吞吐量。
    因为 Exchange 在数据库与其关联的事务日志之间具有写入顺序相关性，所以，需要配置一组复制点，用于支持存储组逻辑卷（包括数据库逻辑单元号码 (LUN) 和日志 LUN）使用相同的复制链路。要在存储组级别保留写入顺序，则需要此配置，为了在出现故障时（例如链路故障）维护远程站点上的数据完整性，必须这样做。
    使用多个复制链路和多个复制点可以有效地扩展 Exchange 数据复制解决方案。此方法还会减小数据丢失的可能性，这一点已在前面一节“同步复制”的示例中讨论。

为 Exchange 配置同步复制的最佳实践

在同步复制环境中部署 Exchange 时，一些配置更改将提高服务器的性能/可伸缩性。需要在规划阶段了解这些更改，以便在设计存储和复制时实施这些更改。配置的最佳建议做法如下：

  • 为每台 Exchange 服务器创建最大数量的存储组。
    通过在多个逻辑卷以及后续的多个复制点上平衡日志写入事务的负载，增大同步复制 Exchange 解决方案中的存储组数可以提高部署的性能/可伸缩性。通常，将出现更多并行处理的日志写入进程，这样可以在同步复制环境中缩短总体事务日志写入延迟（缩短 I/O 队列）。Exchange Server 2003 企业版允许每台 Exchange 服务器包含四个存储组。
  • 增大事务日志缓冲区的大小。
    Exchange 日志写入 I/O 延迟是同步复制 Exchange 解决方案中一个重要的可伸缩性因素。日志写入 I/O 是顺序单线程的，因此，日志 I/O 的延迟很可能成为系统的瓶颈。首先将日志 I/O 写入日志缓冲区，然后，通过非被动提交或容量提交清除缓冲区。非被动提交意味着立即将日志缓冲区写入磁盘。容量提交意味着在缓冲区已满时将日志缓冲区写入磁盘。
    减小日志缓冲区的大小可以降低容量刷新的频率，增大日志写入的大小，并继而缩短总体日志写入延迟。缩短日志 I/O 写入延迟是提高 Exchange 部署的性能/可伸缩性的一种重要方法。
    通常，如果通过光纤通道进行复制，则建议将缓冲区大小增大到最大值 9,000。对于低带宽链路（例如 TCP/IP 链路），则很难确定此参数的最佳值。如果链路对于增大的日志写入大小显示饱和状态，将降低复制速度，则应执行全面测试，以确定可以最大程度缩短日志写入延迟的最佳日志缓冲区大小。若要了解如何修改此参数，请参阅知识库文章 328466“ESE log buffers that are set too low can cause the Microsoft Exchange Information Store service to stop responding”（英文）。还应向解决方案提供商咨询此设置。

同步复制的部署规划

即使同步复制存储解决方案已遵循了前面的所有建议，如果在部署之前未进行全面的测试，仍可能会给 Exchange 客户端带来性能问题。为 Exchange 实施同步复制对可伸缩性/性能的负面影响没有确定的规则。每个 Exchange 复制解决方案具有不同的性能因素，可能包括但并不限于下列因素：站点之间的距离、复制传输机制、复制链路数、复制点数、Exchange 存储组数、Exchange 数据库/日志配置设置、存储和复制体系结构以及 Exchange 客户端配置文件。每个解决方案都是唯一的，需要全面地规划和测试才能成功部署。

因为同步复制解决方案造成的 I/O 写入延迟是限制 Exchange 可伸缩性的关键因素。I/O 延迟的延长增大了服务器的负载，可能会严重影响 Exchange 客户端的体验。特别是，长时间的写入延迟将延长 RPC 延迟，从而，客户端会感到速度变慢。尽管同步复制可以实现 Exchange 数据的高可用性，但是也会严重影响 I/O 性能。此 I/O 写入（有时是读取）性能的降低在确定给定平台上可以支持的最大用户数时是一个关键因素。

在规划阶段，执行下列步骤来验证设计：

  1. 要了解如何最好地设计和实施 Exchange 存储，请参阅 Optimizing Storage for Exchange 2003（英文）。
  2. 使用 Jetstress 测试来验证配置了同步复制的存储的原始吞吐量。要下载 Jetstress 工具，请访问 Microsoft Exchange Server Jetstress 工具网站。
  3. 通过运行为您的环境定制的 Exchange Server 负载模拟器 2003 (LoadSim) 测试来评估写入延迟延长对电子邮件客户端的影响。要下载 LoadSim，请访问 Microsoft Exchange Server 2003 负载模拟器 (LoadSim) 网站。
  4. 评估运行 LoadSim 时的平均磁盘吞吐量。磁盘吞吐量必须等于或高于所模拟的生产环境中预期的峰值平均吞吐量（IOPS/邮箱）。有关如何评估峰值平均磁盘吞吐量的详细信息，请参阅 Optimizing Storage for Exchange 2003（英文）。
  5. 密切注意在运行 LoadSim 测试之后，服务器上的 RPC average latency 计数器以及客户端响应时间。分析测试结果时应注意，所有三个计数器必须满足下列条件。
    RPC Average Latency
    此计数器显示处理单个远程过程调用 (RPC) 请求所需的平均时间。增大用户负载或复制距离将导致平均 RPC 延迟延长。平均的最大限制为 50ms，最大值应为 100ms。如果测试结果显示的平均值大于 50ms，客户端的总体感觉应比较缓慢。如果平均值小于 50ms，但偶尔峰值会大于 100ms，则在峰值期间，客户端会感到速度缓慢。
    Disk Latency Counters
    Microsoft Exchange 产品团队已测试多种硬件同步复制解决方案。结果表明了 RPC 平均延迟与磁盘延迟之间的关系。通常，如果数据库读取延迟的平均值小于 20ms 并且日志读/写延迟的平均值小于 20ms，该解决方案可以处理给定的负载。这些延迟的最大值应保持在 40ms 以下。如果高于这些阈值，客户端很可能会感到响应缓慢。
    Client Response Time
    可以通过在所有客户机上运行 lslog.exe 来确认总体客户端体验。此活动返回第 95 百分位的加权平均值；该值必须小于 1,000ms。lslog.exe 是 LoadSim 工具的一部分。LoadSim 文档讨论如何使用 Islog.exe 和解释提供的结果。
    有关性能的详细信息，请参阅 Troubleshooting Exchange Server 2003 Performance（英文）。
  6. 根据规划的复制距离来测试邮箱配置文件的解决方案。复制链路距离有物理限制。随着距离的增大，因为同步复制随着距离的增大会使写入延迟延长，所以，客户端/服务器响应时间也会延长。通常认为 100KM 是 Exchange Server 数据的同步存储复制的阈值。根据解决方案的实施方式，此阈值可能会有所不同。
  7. 创建备份计划，用于定期验证数据库完整性。复制无法取代备份过程。
  8. 确保拥有全面的灾难恢复计划，并且已经像解决方案的复制性能一样进行了全面的测试。可以通过不同的方法恢复 Exchange 数据、服务器和站点。应实施可以满足商业需要和服务级别协议的灾难恢复计划，万一发生灾难，可以指导您快速有效地完成恢复阶段。通过模拟在重载情况下使用同步复制的 Exchange 部署中的多种故障类型，测试并验证计划。