高可用性策略

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

上一次修改主题： 2007-08-31

本主题多方面概述 Microsoft Exchange Server 2007 中的高可用性。本主题还为选择适合您的组织的可用性解决方案提供了建议的决策过程。

根据使用环境以及所涉及的用户的不同，“可用性”和“高可用性”两个术语的含义可能会有明显的不同。这两个术语可以用于描述不同的业务目标和技术要求，从纯硬件可用性目标到关键任务目标（应用于整个邮件服务）。

通常，组织相对比较容易对可用性目标有一个不适当的预期。组织还很容易对可用性级别提出更高的要求，超出他们在了解了涉及的成本后实际愿意支付的成本。

大多数可用性解决方案所涉及的成本包括但不限于：

• 硬件

• 软件

• 网络基础结构

• 培训

• 可服务性

• 营运成本

可服务性是指与第三方服务提供商进行的合同性安排或与组织中的信息技术部门达成的营运级协议，以提供或维护信息技术服务或信息技术组件。

可用性

可用性是指由应用程序、服务或系统提供的服务的级别。高可用性系统的计划或非计划的停机时间均最短。可用性通常以某个服务或系统的可用时间百分比来表示，例如，每年有 8.75 小时不可用的服务的可用性为 99.9%。

为了提高可用性，必须实现容错机制，以避免或尽量减小组件故障的影响以及对服务的依赖性。容错通过对单点故障组件实现冗余来实现。

在规划 Microsoft Exchange 可用性时，应考虑组成邮件基础结构的所有组件。有些组件还可能是包含子组件的其他服务。邮件服务可用性由组成基础结构的每个组件的可用性决定。

定义可用性要求

服务的可用性是一个非常复杂的问题，涉及许多学科。可以采用许多不同的方法来实现所需的可用性级别，每种方法有各自所涉及的成本。

但是，客户经常会使用相对简单的术语来表达可用性要求，而他们并不完全了解真正的含义。这种情况可能导致客户与信息技术组织之间产生误解，导致投资水平不合适，最终由于无法达到相应的预期而造成客户不满意。

一个表示为 99.5% 可用性的要求可能不同于另一个 99.5% 可用性的要求。一个要求可能是单独讨论硬件平台的可用性，而另一个要求可能是讨论整个端到端服务的可用性。即使是整个端到端服务的可用性的定义，也会有明显的不同。　重要的是要准确地了解如何评估任何可用性要求。例如：

• 如果主服务器上的所有硬件和软件都运行正常并且应用程序准备好接受用户连接，是否认为该解决方案是 100% 可用？

• 如果有 100 个用户，但是 25% 的用户由于本地网络故障而无法连接，是否仍认为该解决方案是 100% 可用？

• 如果 100 个用户中只有一个用户可以连接并处理工作，是否认为该解决方案只有 1% 可用？

• 如果全部 100 个用户都可以连接，但是服务水平下降，只有三分之二的客户事务可用，或性能很差，这对可用性评估有什么影响？

评估可用性的期间也会对可用性的定义产生明显影响。如果在一年内要求 99.9% 的可用性，则允许 8.75 小时的停机时间。如果在四周的滚动时间窗要求 99.9% 的可用性，则每个期间只允许 40 分钟的停机时间。

为了规划维护活动、Service Pack 更新和软件更新，还需要确定并协商停机时间的期间。可以容忍的规划停机时间对可用性要求的定义会产生明显的影响。

Microsoft Exchange Server 2007 的正式发布 (RTM) 版本包括一些可以降低成本并延长运行时间的新功能：

• 本地连续复制   本地连续复制 (LCR) 是一个单服务器解决方案，它使用内置技术在所连接服务器与生产存储组相同的辅磁盘集上创建和维护存储组副本。LCR 提供异步日志传送、日志重播以及到数据副本的快速手动切换。有关 LCR 的详细信息，请参阅本地连续复制。

• 群集连续复制   群集连续复制 (CCR) 将 Exchange 2007 中的复制和重播功能与 Microsoft 群集服务中的故障转移功能组合在一起。CCR 解决方案可以在没有单点故障的单个数据中心中或两个数据中心之间部署。有关 CCR 的详细信息，请参阅群集连续复制。CCR 在多个方面要优于以前版本的 Exchange Server 中的群集以及 Exchange 2007 中的单一副本群集。有关这些优点的详细信息，请参阅与单一副本群集相比，群集连续复制的优点。

• 单一副本群集   Exchange 2007 中的单一副本群集 (SCC) 在以前版本的 Exchange Server 中称为共享存储群集，在某些方面进行了显著的更改和改进。有关 SCC 的详细信息，请参阅单一副本群集。

Microsoft Exchange Server 2007 Service Pack 1 (SP1) 增加了一项用于提供站点弹性的功能：

• 备用连续复制   备用连续复制 (SCR) 是 Exchange 2007 SP1 中引入的一项新功能。正如其名称所示，SCR 用于使用或启用备用恢复服务器的方案。SCR 扩展了现有的连续复制功能，并为 Exchange 2007 邮箱服务器启用新的数据可用性方案。SCR 使用的日志传送和重播技术与 LCR 和 CCR 相同，以增加部署选项和配置。SCR 可以用于从独立邮箱服务器和群集邮箱服务器复制数据。有关 SCR 的详细信息，请参阅备用连续复制。

这些功能增强了恢复的几率，从而满足了不同的可用性要求。下表列出了不同的可用性要求，并对 Exchange 2007 解决方案和 Exchange Server 2003 中的灾难恢复解决方案进行了比较。有关 Exchange 2007 的高可用性配置的详细信息，请参阅高可用性部署。

基于可用性要求的高可用性解决方案比较

选择适当的可用性解决方案

可以使用多种配置来提高 Exchange 2007 部署的可用性。选择正确的可用性解决方案的重要一步是需要对所选的一组解决方案进行分析，确定能够满足业务目标和可用性要求的最佳解决方案。一种方法是创建包含多个部分的表，每种类型的失败对应一个部分。在表的每个部分中，使用一行列出提供满足针对相应故障的可用性要求的恢复策略的每种解决方案。列中记录解决方案的重要因素。典型因素包括：

• 恢复时间

• 数据对恢复的影响

• 相关的硬件和软件成本

• 相关的资源成本

• 事件概率

• 与业务相关的方面

• 复杂性风险

• 第三方解决方案

• 优点

• 缺点

完成这些表后，选择几个解决方案进行成本分析。对于每个选定的解决方案，应计算出邮箱的单位估计成本（也可以用表的形式表示）。在成本表中，确保有一行描述相应解决方案对于实现业务目标达到的质量。应确保评估几个解决方案。至少选择一个能够满足要求但与组织可能选择的典型解决方案不同的解决方案。

最后，重新审视业务目标、可用性要求、可能的解决方案以及成本分析结果，选择适当的解决方案。在此过程中，要做出正确决策，关键的考虑事项包括：

• 明确多个业务目标的优先级顺序 由于不同目标很可能会相互冲突，因此优先级顺序很重要。

• 质疑以前适用但现在可能不再适用的方式   确保在设计和评估阶段充分利用 Exchange 2007 的各种功能。经验表明，最具成本效益的解决方案可能需要采用新的备份、存储和操作方法。

• 检查邮件系统中的单点故障   在单个存储区域网络 (SAN) 上存储单个邮箱数据副本意味着无法充分应对数据的损坏和出错。多种情况会导致数据的单个副本损坏或出错，这与 SAN 提供的冗余量无关。在使用 SCC 时，如果出现 SAN 故障，会导致在服务中出现丢失数小时数据和中断数天的情况。CCR 是一种可用性解决方案，在服务器出现故障时可能会丢失某些数据，但它另外维护了两个数据副本。CCR 使用称为“传输转储程序”的集线器传输服务器功能，避免了在服务器出现故障时丢失数据的大多数情况。 因此，对于大多数硬件故障，邮箱数据可以保留下来。

• 研究可用于每个解决方案的多种存储方式   CCR 让组织可以选择众多存储解决方案，例如直接连接存储。CCR 不要求采用 SAN 构造，这样可以降低相关的复杂性和成本。无论是 SAN 还是某个低成本的存储解决方案，直接连接存储更加容易部署与操作。

• 考虑 CCR 和 LCR 让您可以将备份策略从典型的每日完整备份更改为不常进行的完整备份以及每日增量备份策略   CCR 和 LCR 还可以支持较短的服务级别协议 (SLA)，以便从初次故障中恢复。如果需要从双重故障（两个副本都出错或损坏）中恢复，可能需要在当前还原 SLA 的基础上延长 SLA。这样的变化可以显著降低总拥有成本 (TCO)，因为备份成本通常是 TCO 的主要组成部分。同时，转为采用基于磁盘的备份策略还可以降低备份成本。

• 调查连续复制技术在 Exchange 2007 中的使用以创建解决方案   CCR 不再需要第三方复制技术。当前，CCR 支持双节点群集，每个节点维护一个数据副本。基于此项技术的站点弹性解决方案的好处如下：

  • 确保备份数据中心的邮箱数据可供客户端使用。

  • 连续复制移动的数据少于大多数第三方解决方案移动的数据。

  • 需要较少的集成即可创建站点弹性解决方案。

• 创建列出与各种方案关联的恢复行为和成本的表。   对于成本表，确保其包含一些与现有做法有所不同的方案。使用所创建的表中的事实来设计达到以下要求的解决方案：

  • 提供满足业务要求的最佳解决方案。

  • 满足成本要求。

  • 体现了组织可以支持的部署和操作复杂性级别。

基础产品和组件

产品和组件的部署应当基于其是否能够满足严格的可用性和可靠性要求。应当将这些要求视为可用性设计的基石。如果这些基础产品和组件不可靠并且容易出现故障，则会浪费为了获得更高级别的可用性而需要的其他投资，并且无法达到相应的可用性级别。

服务管理过程

有效的服务管理过程有助于实现更高级别的可用性。在邮件服务的总体管理中，诸如可用性管理、意外事件管理、问题管理以及更改管理这样的过程扮演了重要角色。

系统管理

系统管理应当提供监视、诊断和自动错误恢复，以实现对潜在及实际的故障的快速检测和解决。

使用完整冗余的特殊解决方案

为了实现 100% 的连续可用性，需要采用包含完整冗余的高成本解决方案。冗余是一项通过使用重复的组件来提高可用性的技术。为了满足严格的可用性要求，这些组件需要能够并行地独立工作。

建立可用性目标和 SLA 要求

若要获得高级别的可用性，首先需要部署质量良好的产品和组件。但是，仅有这些产品和组件还不太可能持续实现所需的可用性级别。在开发中尽可能早的阶段，就应当在设计过程中考虑可用性目标。此方法可以避免与返工相关的成本增加的可能性、满足必需可用性所需的非计划升级、监视基础结构的非计划工具，以及为了消除基础结构、可维护性和可服务性中的单点故障而导致的非计划支出。

在实现高可用性的前几个步骤中，有一个步骤是复查已为组织建立的 SLA。建立 SLA 之后，可以确定最适合该协议的 Exchange 2007 部署和服务器配置。

以下是获得高可用性时需要考虑的关键因素，因为它们与灾难恢复有关：

• 允许的停机时间   根据组织的 Exchange 服务可用性定义考虑组织可接受的最长允许停机时间。根据组织的停机时间定义，您也许能够使用邮件拨号音恢复策略满足组织的 SLA。邮件拨号音恢复策略包括为您的用户提供临时邮箱，以便他们可以在灾难过后立即发送和接收电子邮件。此策略可在恢复历史邮箱数据之前迅速地还原电子邮件服务。通常，可通过最终合并历史邮箱数据和临时邮箱数据来完成恢复。

• 允许的恢复时间   考虑每种类型的灾难恢复操作的最长允许时间。例如，您应指定恢复一个邮箱、单个数据库或正在运行 Exchange 2007 的整个服务器所用的近似时间段。

• 数据丢失容限   考虑组织对 Exchange 数据的临时或永久丢失的容限。例如，组织也许能够允许邮箱数据自上一次备份后临时丢失 24 小时，只要用户在 4 小时的时段内能够发送和接收邮件即可。在其他情况下，您可能要考虑更严格的要求，例如要求达到故障点的所有 Exchange 数据在 4 小时内恢复。

在考虑停机时间对组织的影响并确定要在邮件环境下实现的正常运行时间级别之后，就可以建立 SLA 了。SLA 需求决定了存储、群集以及备份和恢复等组件如何影响您的组织。

评估 SLA 时，应首先确定正常运行时间和在计划的停机时间方面的期望。然后，应确定您的公司在可用性、性能和可恢复性方面的期望，包括邮件传递时间、服务器正常运行时间百分比、所需的存储量，以及恢复 Exchange 数据库所需的时间。

此外，应确定计划外停机时间的估计成本，以便可以在邮件系统内占用适当的容错量。

Exchange 2007 和 Windows Server 2003 中的功能可能会影响您将组织设计为满足 SLA 的方式。例如，LCR、CCR、SCC、卷影复制服务 (VSS)、恢复存储组、数据库可移植性和拨号音可移植性功能使您可以突破 SLA 以前产生的限制。

下表列出了您可能要包括在自己的 SLA 中的部分类别和特定元素。

典型的企业级别 SLA 中的类别和元素

在 SLA 中包括多种性能衡量方式有助于确保满足用户的特定性能要求。例如，如果在客户端和邮箱服务器之间存在高延迟或低可用带宽问题，则用户与系统管理员对性能级别的看法是不同的。具体地说，即使系统管理员认为性能可接受，用户也可能会认为性能级别较低。因此，请确保监视磁盘输入/输出 (I/O) 延迟级别。

注意：
对于每个 SLA 元素，还必须确定要与可用性目标结合使用来衡量性能的特定性能基准。另外，必须确定为信息技术管理和其他管理提供统计信息的频率。

与供应商建立服务级别协议

许多对高可用性解决方案较为重视的公司，使用第三方供应商的服务来实现高可用性目标。在这种情况下，实现高可用的邮件系统需要外部硬件和软件供应商提供服务。如果供应商响应速度缓慢、工作人员培训不到位，则会降低邮件系统的可用性。

确保与每位主要的供应商就 SLA 进行协商。与供应商建立 SLA，将有助于保证邮件系统按照规范执行操作，支持所需的增长态势，并可用于特定标准。如果没有 SLA，则会大大延长邮件系统不可用的时间。

要点：
请确保您的工作人员了解每个 SLA 的条款。例如，许多硬件供应商 SLA 包含如下条款：只允许来自供应商的支持人员或您的组织内经过认证的工作人员打开服务器包装。如果不遵守这一条款，则会违反 SLA，并可能会导致供应商保修或责任条款无效。

除了与主要的供应商建立 SLA 之外，还应该通过进行支持请求训练来定期测试升级过程。为了确认您获得了最新的联系信息，请确保您还测试了寻呼和电话树。

可用性的考虑事项

建议您在确定可用性要求时考虑以下问题：

• 了解所建议的基础结构设计的故障薄弱点。应当确保没有单点故障。单点故障是邮件基础结构中没有冗余功能并且在发生故障后会影响用户的任何组件。解决方案的建议技术设计应当涉及完整的端到端配置。

• 考虑邮件服务的业务所必需的最低可用性级别，以及邮件基础结构的每个组件的最低可靠性、可维护性和可服务性级别。

• 考虑为确保新组件满足指定的要求而对它们进行测试或模拟的能力。若要评估设计中的新组件是否可以满足所声明的要求，务必让您建立的测试团队确保可以达到期望的可用性。同时，还应当在维修组件时执行测试。应当认真考虑对生成新信息技术服务产生预期用户需求的模拟工具，确保组件在工作量和压力条件下仍然能够继续工作。

高可用性的考虑事项

高可用性邮件解决方案需要您投资并部署监视解决方案、服务管理过程、系统管理工具和冗余。对于高可用性部署，很重要的一点是此端到端配置中不存在任何单点故障。高可用性的设计必须考虑到消除单点故障和供应替代组件，以尽可能减小发生组件故障后对业务运营的干扰。该设计还必须消除或尽可能减小为了适应维护活动而正常需要的计划内中断（例如，实现对基础结构的更改）对业务运营产生的影响。恢复条件应当将迅速恢复和服务复原定义为设计过程中设计恢复阶段的关键目标。

在制定邮件解决方案的部署计划时，必须确定解决方案的目标。这在设计解决方案的可用性特性时尤为重要。通常，企业的多个目标间会产生矛盾。例如，您的可用性目标可能要求 100％ 可用性，同时还要求在一周内应用最新的安全升级。成本通常是部署规划所面临的另一个挑战因素。遵循如下计划方法论是为您的企业确立正确的解决方案的最佳途径：确定所有业务要求并针对这些要求评估可用选项。

为了成功实现高可用性，要求持之以恒地关注组织的运作实践。需要了解导致中断的所有原因。对于通过改变过程可防止的中断，需要着手进行适当的过程改变。

主动监视 Exchange 环境是最大程度地提高可用性的另一个关键因素。通过主动监视，可以在出现故障和中断之前发现系统内的问题区域。另外，监视功能还可以就系统不能自动恢复的问题向操作人员发出警报。这种情况下，及时地做出响应可以缩短中断时间，从而提高可用性。

Exchange 2007 与数据中心中的基础结构之间存在依存关系。因此，Exchange 的可用性受其依赖项提供的可用性的约束。建议组织针对每个依赖项建立 SLA。SLA 必须指定所提供服务的可用性以及发生故障时需要的恢复时间。例如，Active Directory 目录服务是 Exchange 的主要依赖项。如果 Active Directory 的可用性低于 Exchange 可用性目标，那么 Exchange 不大可能达到其目标。

Exchange 2007 的可用性依赖于信息技术基础结构中其他服务的可用性。诸如 Active Directory 和联网等服务必须正常运行，Exchange 才能正常运行。这些服务的可用性直接影响 Exchange 的可用性。因此，应确保 Exchange 可用性要求不高于其依赖项的可用性要求。以下是典型的依赖项列表：

• Active Directory

• 域名系统

• TCP/IP 网络

• 存储子系统

• 备份服务

• 监视服务

• 数据中心基础结构（电源和空调）

为 Exchange 依赖项建立业务目标和 SLA 后，建议您为邮件服务制定可用性要求的初始列表。该列表应包括每种常规类故障以及预期的恢复时间目标 (RTO)。对于与数据相关的故障，此列表应包括故障对数据产生的影响的指示。通过指明恢复点目标 (RPO) 可以进行指定。RPO 通过指定一个时间（定义恢复后可供使用的数据的级别）来标识数据影响。应考虑的故障包括：

• 单个邮件项丢失

• 单个邮箱丢失

• 数据库丢失或损坏

• 磁盘故障

• 磁盘卷故障或损坏

• 存储单元故障

• 服务器故障

• 网络连接丢失

• 数据中心故障

在许多组织中，建立的可用性要求随用户类型的不同而异。例如，一些用户可能使用邮件系统跟踪运输或销售，而其他用户可能将其用于非关键邮件。关键进程依赖于邮件系统的用户的 RTO 和 RPO 需要尽可能短，而将邮件系统用于非关键进程的用户可以容许更长的 RTO 和 RPO。

详细信息

有关 Exchange 2007 站点弹性的详细信息，请参阅Site Resilience Configurations。