ExRAP 检测到的 Exchange 配置和操作问题

本页内容

	简介
	服务器配置问题
	体系结构和操作问题
	结论

简介

ECoE 是由 Microsoft 信息技术 (Microsoft IT) 集团发起的一个 Exchange 专家组。 ECoE 创建于 2004 年，其使命是开发用于管理大型企业中的 Exchange 的程序、资源和最佳实践。 ECoE 当前与 Microsoft Services 合作管理的计划之一是 ExRAP。

ExRAP 约定对拥有首选支持协议的 Exchange 客户可用。 在典型的 ExRAP 约定中，微软顾问执行 Exchange 部署的现场分析。 该分析不仅涉及单独的服务器，而且涉及物理基础结构、逻辑拓扑和支持 Exchange 的过程管理。 ExRAP 报告估量 Exchange 性能、可伸缩性和可恢复性以及其他许多尺度，并为任何已确定的问题提供特定的反馈和补救建议。

ECoE 到目前为止已完成了 900 多份 ExRAP 约定。 平均来讲，在已接受 ExRAP 分析的客户中，微软估计“严重问题 (CritSit) 微软客户服务和支持”案例减少了 30% 以上 。 CritSit 支持案例是指客户面临着中断最终客户服务或影响重要业务运营的问题。 强有力的证据表明，根据 ExRAP 建议做进一步的改进，能够极大地改善 Exchange 环境的操作运行状况和稳定性。

对于当前与微软签有首选支持合同的客户，技术支持客户经理是安排 ExRAP 约定的第一联络点。 对于没有 Exchange 首选支持协议的客户，或者希望了解有关首选支持服务的更多信息的客户，他们可以在以下地址找到更多信息： http://www.microsoft.com/services/microsoftservices/srv_prem.mspx.

本文档的目的是公开 ExRAP 过程所揭示的最常见问题。 本文假设读者是 Exchange 管理员，能够对 Exchange 系统做出配置和体系结构更改。 本文还假设读者熟悉 Microsoft Windows Server™ 和 Microsoft Exchange Server。

本文基于 Microsoft IT 在过去一年为若干个 Exchange 客户履行 ExRAP 约定过程中的经验和建议。它无意成为程序上的过程性指南。 每个环境都有唯一的要求；因此，每个组织都应该调整本文描述的计划和经验，以适应其特定的需要。

每个 ExRAP 约定中都使用了的工具之一是 Exchange 最佳实践分析器 (ExBPA)。 每个 Exchange 都可以下载这个免费工具，地址为 http://www.microsoft.com/exchange/downloads/2003/exbpa/default.mspx. 管理员可以针对单独的服务器、服务器组或整个 Exchange 组织运行 ExBPA。 该工具分析数百个 Exchange 服务器和 Microsoft Active Directory® 目录服务配置设置，并报告发现的所有次优设置或错误配置。

本文的各个小节有意地排除了 ExBPA 报告的特定问题。 排除这些问题并不是因为它们不重要，而是因为任何 Exchange 管理员都可以（并且应该）运行 ExBPA 来发现适用于其环境的问题。 制定行动计划以处理本文提到的问题的管理员应该结合 ExBPA 报告来进行。

服务器配置问题

本节集中于单个管理员只需很少成本或团队协作即可检查和更正的问题。 它集中于管理员能够做出的一次性更改，无需持续的管理或附加的操作基础结构。

本节识别的问题没有特定的严重度或优先级顺序。 它们全都是可能在 Exchange 环境中导致重大的、不可避免的停机或性能下降的问题。

反病毒配置

对于 Exchange，反病毒程序归入两个大类之一：

从普通文件级反病毒扫描程序中排除 Exchange 数据库和事务日志文件目录以避免改动，这是很重要的。 如果不排除这些目录，扫描程序最终会破坏 Exchange 数据，并且可能停止数据库。

在最常见的情况下，普通文件级病毒扫描程序销毁或移动当前 Exchange 事务日志文件。 此操作将停止数据库，使其处于不一致状态。 若要重新启动数据库，必须找到缺失的事务日志（如果它们仍存在），并将它们复制回原始位置。 如果当前事务日志已销毁，则存在两种恢复选择，两种选择可能都要花一些时间才能实现：

普通反病毒扫描程序还可能改动 Exchange 数据库文件，从而破坏它。 即使遭受的破坏不会阻止数据库运行，该损坏至少也会阻止数据库的在线备份成功完成。 Exchange 在在线备份期间扫描整个数据库中的损坏情况，如果发现损坏则停止备份。 此操作确保最后的数据库备份始终是良好的数据库。

错误配置的普通反病毒程序是长时间数据库停用的极常见原因，这样的停用需要完全还原或其他灾难恢复步骤。

注意： ExBPA 将检测一些（但不是全部）反病毒程序正在影响 Exchange 数据文件的情况。 请不要完全依赖 ExBPA 来检测此类问题。

有关与 Exchange 一起使用反病毒软件的详细信息，请参阅微软知识库文章“Exchange 数据库无法在 Exchange Server 2003 或 Exchange 2000 Server 中安装”，地址是http://support.microsoft.com/kb/896143.

服务器内存配置

重负荷的企业级 Exchange 服务器通常有 1 GB 以上的随机访问内存 (RAM) 并同时为 2000 个以上的用户提供服务。 在这些情况下，Exchange 同时处理海量的用户数据。 正确调整服务器内存可改进性能，防止耗尽关键 Microsoft Windows® 内存资源，并允许 Exchange 最充分地利用 32 位虚拟内存地址空间。 有关 Exchange Server 的内存调整的详细说明，请参阅下列微软知识库文章：

在线维护

繁忙的 Exchange 数据库每天由数百或数千个单独的用户访问，他们移动、复制、删除、发送和接收各种不同大小的邮件。 该数据库不断地忙于插入、删除和合并大量随机记录。 与其中正在进行大量更改的文件系统一样，数据库中的空间最终变得零碎，从而降低性能和效率。

数据库在线维护日常工作包括在线碎片整理，它扫描数据库并重新组织空间利用。 使数据库保持优化所需的其他维护任务也在在线维护期间进行，但是碎片整理是那些任务中最重要和最耗时的任务。

管理员可以单独为每个数据库计划在线维护。 默认情况下，在线维护时间为当地时间午夜和凌晨 5 点之间。 如果在线备份开始或维护时间窗口过期，在线维护将暂停直至下一个计划的维护窗口，届时它将从暂停的地方继续进行。

在线维护不需要每晚完成，但是应该为每个数据库定期完成。 Microsoft IT 根据经验相应设置在线维护窗口，使得每周至少为每个数据库完成一次维护周期。 如果维护从未完成，则不仅数据库性能会受到负面影响，而且数据库文件可能增长不必要的大小，因为它们中的空间无法得到有效的重用。

有关运行和监视在线维护的更多信息，请参阅下列微软知识库文章：

磁盘空间

Exchange 数据库根据需要增长以包含新的用户数据。 Exchange 事务日志文件在必要时生成以记录对数据库的所有更改。

在典型情况下，Exchange 数据库的大小会在一段时间的使用后稳定下来。 该数据库不会增长到更大，因为它已达到用户删除与用户插入不相上下的平衡状态。 Exchange 事务日志通常不会填满日志驱动器，因为在线备份过程或循环日志记录会自动删除它们。

但是，下列异常条件或管理疏忽可能导致事务日志加速生成，或导致数据库的大小不断增长：

以频繁的间隔监视 Exchange 数据驱动器上的空闲磁盘空间非常重要。 磁盘空间不足是数据库意外关闭的最常见原因。

如果 Microsoft Exchange Server 2003 中的驱动器空间不足，数据库通常能够提交所有未决的事务并清洁地关闭。 在前一个版本的 Exchange 中，数据库在磁盘空间已满时突然停止的情况更常见。 就其本身而言，这并不是个问题，因为事务日志恢复机制非常可靠，它将恢复数据库并将其置于清洁关闭状态。 但是，管理员在磁盘已满的情况下通常会删除所有事务日志以创建空闲空间，包括恢复数据库所需的最后几个事务日志。 在此情况下，只能通过修复或还原来恢复数据库。 有关如何安全地从用于事务日志的磁盘已满的情况下恢复的更多信息，请参阅微软知识库文章“如何删除 Exchange Server 事务日志文件”，地址为http://support.microsoft.com/kb/240145.

群集配置

Exchange 是一个 Microsoft Cluster Server 敏感的应用程序。 在群集配置中运行 Exchange 提供了附加的冗余，并且能够提供比独立环境更高的可用性。

但是，在群集中运行 Exchange 意味着 Exchange 管理员必须受到有关 Windows 群集以及有关 Exchange 的培训。 Exchange 在群集中运行时的行为是不同的，管理员必须理解差别和要求。 下列白皮书并不能代替全面的 Windows 群集培训和经验，但是它们的确概括了在群集环境中运行 Exchange 的最重要差别和要求：

备份监视

最基本的管理员职责是确保备份已完成、良好并且能够还原。 此外，由于该工作的繁琐和日常性质，即使最大和最专业的企业中的管理员有时也会忘记创建、验证和保护备份。 系统和数据故障不经常发生，而人类的天性倾向于低估缓解不经常发生的风险的重要性，即使后果是灾难性的。 需要制定大量的操作纪律才能一致地创建和测试备份。

Microsoft IT 使用 Windows 中的“备份”功能，成功地在每日夜间备份其 Exchange 邮箱服务器。 为此，Microsoft IT 必须对备份参数进行一些更明确的自定义。 有关 Microsoft IT 如何备份其 Exchange 邮箱服务器的更多信息，请参阅以下文档：

Exchange 最佳实践分析器

ExBPA 工具建立在一个基于规则的引擎基础上，该引擎经常被改进以反映 Exchange 管理员和疑难解答人员的实际问题和经验。

例如，最近用于传输控制协议/Internet 协议 (TCP/IP) 的一个热修复导致了 Exchange 服务器的 X.400 连接问题。 这个问题很快被发现，ExBPA 随即被更新以检查有问题的热修复版本，并为 Exchange 管理员提供有关临时解决该问题的指南。

每次该工具运行时，它能够检查包含有已更新的规则和测试的新配置文件。 Microsoft IT 建议至少每月对组织中的代表性 Exchange 服务器（或所有 Exchange 服务）运行一次该工具的新版本，以自动检测新问题并建议新开发的最佳实践。

此工具对每个 Exchange 管理员免费可用，并且可从以下地址下载： http://www.microsoft.com/exchange/downloads/2003/exbpa/default.mspx.

体系结构和操作问题

本节识别可能需要对新的硬件或基础结构、跨团队协作或项目规划进行投资的问题。 更正这些问题可能需要更改 Exchange、Active Directory 或网络的体系结构或拓扑。

本节识别的问题没有特定的严重度或优先级顺序。 它们全都是可能在 Exchange 环境中导致重大的、不可避免的停机或性能下降的问题。 虽然这些问题很基本，但是值得讨论它们，因为许多组织仍然没有解决它们。

存储配置

存储技术过去几年来已经历了显著的发展。 现代企业级存储设备方面可用的选择令人眼花缭乱，新的功能和协议正在以很快的节奏开发出来。 存储供应商用广泛的高级功能和专有设计区分他们的产品。 为 Exchange 存储配置定义特定的最佳实践很困难，因为任何建议很快就会因为新技术而变得过时，或不适用于跨不同供应商的产品。

不变的一个方面在于，在输入/输出 (I/O) 性能和满足客户的更大邮箱需求所需的空间方面，繁忙的 Exchange 服务器对底层存储具有很高的要求。 因此，咨询存储供应商有关配置和扩展存储系统的最佳实践，以支持特定 Exchange 组织的要求，这一点至关重要。 所有主要的存储供应商都有用于设计 Exchange 存储的详细最佳实践。

仅从磁盘空间方面考虑 Exchange 存储要求是错误的。 更重要的是存储平台在 I/O 吞吐率、独立磁盘冗余阵列 (RAID) 配置选项、冗余通道和恢复选项方面的能力和限制。

有关 Microsoft IT 如何设计其 Exchange Server 2003 群集存储配置的更多信息，请参阅标题为“微软的 Exchange Server 2003 设计和体系结构”的 IT 展示白皮书，地址为 http://www.microsoft.com/technet/itsolutions/msit/deploy/ex03atwp.mspx.

磁盘性能基准

Exchange 服务器上性能不理想的最常见原因是磁盘 I/O 不足。一般情况下，Exchange 对 I/O 的要求比对处理器的要求更密集。

组织不应该单纯依赖理论上的 I/O 计算。 存储系统中的意外瓶颈会导致它的表现与理论模型相差甚远。 微软发布了有关每个 Exchange 用户的预计平均 I/O 负荷的详细信息，以及帮助计算特定环境的 I/O 负荷的公式和电子表格。

微软提供了两个用于对 Exchange 性能建模的工具：

有关上述工具以及对 Exchange 进行调整和基准测试的更多信息，请参阅“Exchange Server 2003 性能和可伸缩性指南”，地址为 http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/perfscalguide.mspx.

服务级别协议

服务级别协议 (SLAs) 不仅驱动 Exchange 系统性能的可记帐性，而且还定义有关该电子邮件系统的性能、可伸缩性和可用性的最重要注意事项。 没有高质量的 SLA，要适当地优化资源或适当地设计 Exchange 系统是很困难的。 通常，组织要么是没有定义 SAL，要么是随意地定义它们。 设计不良的 SLA 转移和浪费资源；设计良好的 SLA 将操作和体系结构资源集中于测量和维护系统的最重要功能。

标题为“微软用 Exchange Server 实现高可用性”的展示文档解释了微软为其内部 Exchange 系统定义 SLA 的方法。 该文还提供了设计不良的 SLA 如何导致错误决策的示例。 该文可在以下地址找到： http://www.microsoft.com/technet/itsolutions/msit/operations/exchhighavailTSB.mspx.

权限和凭据策略

微软客户服务和支持部门最近响应了一个由管理员删除组织中所有公共文件夹的低级错误触发的 CritSit 案例。 该管理员认为所做的删除只影响单台服务器，但那些删除却复制到了整个组织中。 完全恢复和重新填充数据花了数天时间。

这个事故说明了做出有关谁有权更改或销毁 Exchange 配置和客户端数据的明智决策的重要性。 许多组织不跟踪谁有权访问 Exchange 系统或谁有权授予 Exchange 系统中的权限。 正如上面的事故所表明的，限制公共文件夹上的权限（尤其是层次结构顶部的文件夹）也非常重要。

有关管理员和最终用户权利和权限策略的更多信息，请参阅下列白皮书：

监视

如果组织中的 Exchange 管理员发现 Exchange 系统中的问题的通常方式是通过最终用户对帮助台的呼叫，则管理员没有对系统进行足够的监视。 有效的监视不仅允许管理员快速响应故障，而且还提供日常操作的基准和测量。 基准监视使管理员能够预测容量升级需要或在异常条件导致故障前检测到这些异常条件。

监视大型 Exchange 环境的每个方面可能是一项让人生畏的任务。 组织不仅必须监视服务器运行状况，而且还必须监视服务器之间的通信状态、可能指示病毒或垃圾邮件的消息流量峰值，以及 Exchange 对最终用户客户端的响应情况。 找到一种有效的方法来显示并管理所有这些数据很重要。 设置监视太容易不过了，然后却由于结果数据太多或太凌乱而忘了查看它们。

Microsoft IT 使用 Microsoft Operations Manager (MOM) 2005 作为其企业监视解决方案。 MOM 的 Exchange 管理包在一个中央控制台捕获、比较和解释 Exchange 数据，该控制台易于扫描并提供适当的警报。 有关 MOM 与 Exchange 的更多信息，请参阅下列白皮书：

The “Exchange Server 2003 操作指南”也提供了有关保持 Exchange 系统良好运行的宝贵信息。 管理员可从以下地址下载该指南： http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/opguide.mspx.

容量规划和负载平衡

组织应该监视的一个 Exchange 环境方面是随着新用户在线而需要的邮件存储空间增长。 如果没有为增长做计划，组织很容易会忽略这个方面。 由于服务器必须携带比预计使用量更多的容量，因此在性能下降变得明显之前可能孕育着多种问题。 如果数据库大小增长的太大，备份可能未完成或可能花太长的时间。更大的数据库还需要更大的维护时间窗口，必须将其与备份时间窗口进行平衡。 如果服务器在正常条件下已经运行在其容量附近，则突然的需求峰值可能会使服务器停机。

管理员应该为服务器负荷和容量设定清楚的目标和限制，并密切监视正在接近该容量的服务器。 平稳地将新容量置于在线需要大量的前期时间和规划。 在紧急情况或在时间压力下这样做可能导致可见的最终用户停机，并且可能导致更高的总体成本。

更改控制和服务器构建文档

如果 Exchange 管理员呼叫微软客户服务和支持部门寻求解决 Exchange 问题的技术支持，产品支持工程要问的第一个问题很可能是“最近做了什么更改？” 通常，问题是由于一个人对系统做了更改而未通知其他任何人所导致的。 了解这样的更改可显著缩短诊断和解决此类问题所需的时间。

严格的更改控制，包括制定在实施更改前取消更改的计划，在企业环境中非常重要。 遵循更改控制过程可能很麻烦，因为它们需要编制文档并在实施更改前通知其他人，而有人可能认为这样的更改是简单和无害的。 但是，似乎简单的更改可能具有意外的影响。 更改控制文档提供的有关特定环境和配置的历史和上下文很有价值。 组织需要全面的更改控制过程以实现高可用性。

与此密切相关的是服务器构建文档和过程。 组织中的系统越相似和越标准化，IT 人员管理和理解系统以及检测反常情况就越容易。 全面的服务器构建文档与严格的更改控制相结合，将允许任何受损系统的可靠重建和配置恢复。

Microsoft IT 使用 Microsoft Operations Framework (MOF) 管理其更改控制过程。 有关 MOF 的更多信息，请参阅标题为“Microsoft Operations Framework (MOF) 基础简介”的视频，地址为 http://download.microsoft.com/download/3/2/9/329a5e25-aeac-45df-9630-86c65d1e35ef/MOFTrainingMM.wmv. 有关更多信息，请参阅 MOF 网站，地址为http://www.microsoft.com/mof/.

灾难恢复计划

灾难恢复计划可在许多不同的范围和复杂性级别进行。 大型组织的灾难恢复计划是一项复杂的任务。

对于有些组织，整个灾难恢复计划由执行定期备份并将它们转移出现场组成。 对于小型企业或家庭用户，这些活动可能已经相当足够了。 灾难恢复计划的详细讨论超出了本文的范围，但是此类计划的基本原理在于，组织应该不仅确保必需的数据受到保护，而且该数据还能在灾难后在需要时迅速还原。 每个 IT 经理都必须评估灾难恢复计划是否已在组织的适当级别进行。

许多大型 Exchange 客户的灾难恢复计划的一部分是向微软客户服务和支持部门求助。 微软客户服务和支持部门由专家工程师和日常工作是响应灾难的产品专家组成。

但是，微软客户服务和支持部门以及其他专家能够帮助恢复的程度取决于组织在灾难前的准备情况。 缺乏冗余基础结构、空闲部件或理解体系结构和系统的受过培训的人员会极大地妨碍支持人员的恢复努力。 如果没有关键数据的备份，微软客户服务和支持部门无法帮助恢复它。

下列白皮书提供了有关制定 Exchange 灾难恢复计划的建议：

Active Directory 体系结构

Exchange Server 2003 必须与 Active Directory 一起使用。 事实上，如果 Exchange 无法访问 Active Directory 全局目录服务器，Exchange 的任何服务甚至无法启动。 Exchange 服务器的各个配置的绝大部分都存储在 Active Directory 中，而不是存储在 Exchange 服务器上。 这种设计选择支持被破坏的 Exchange 服务器的自动重建，通过带 /disasterrecovery 启动开关运行 Exchange 安装程序几乎能够还原所有的以前配置。

在正常操作期间，Exchange 频繁地查询和写入 Active Directory。 在大多数组织中，除客户端登录和身份验证服务外，Exchange 是 Active Directory 的最主要用户。 如果 Exchange 对 Active Directory 的请求所得到的响应变慢，Exchange 中的一切都会变慢。 到达一定程度后，这种变慢不仅成比例地影响系统性能，而且 Active Directory 的迟缓可能成为使消息传输完全停止的瓶颈。

Active Directory 设计不仅考虑到 Exchange 负荷，而且还考虑到 Exchange 服务器和客户端的布置，这很重要。 为 Exchange 正确设计 Active Directory 并不是惊人的复杂，但是有一些重要原则是组织必须遵循的，以防止 Active Directory 问题成为长期问题。 下列白皮书提供了有关 Exchange 要求的信息：

主动/主动群集

组织不应该在两节点的主动/主动群集配置中运行 Microsoft Exchange 2000 或 Exchange Server 2003。 在此配置中，正常操作情况下群集的每个节点上有一个 Exchange 虚拟服务器实例在运行。 在故障情况下，每个 Exchange 实例能够故障转移到另一个节点。 在此情况下，存活的那个群集节点必须同时运行两个 Exchange 实例。

相反，组织应该在主动/被动群集节点配置中运行 Exchange，而不管该群集是有两个还是有更多个节点。 （带有两个以上节点的群集需要 Windows Server 2003 或 Microsoft Windows 2000 Datacenter Edition。） 在主动/被动配置中，没有群集节点运行一个以上的 Exchange 实例。 故障转移只允许转移到还未运行某个 Exchange 实例的节点。

除了在紧急情况下以外，将群集中的被动节点置于空闲状态似乎很浪费。 这种认识可能导致管理员更喜欢主动/主动配置。 在 Exchange 2000 发布时，微软允许两节点主动/主动群集以应对这种客户顾虑。 但是，现实的经验表明，对 Exchange 使用主动/主动群集不是最佳做法，原因如下：

有关 Microsoft IT 如何设计其 Exchange 群集以及如何将被动节点用于除运行 Exchange 实例以外的任务的信息，请参阅“微软用于群集 Exchange Server 2003 服务器的备份过程”，地址为http://www.microsoft.com/technet/itsolutions/msit/operations/exchbkup.mspx.

有关组织能够在主动/主动群集配置中运行 Exchange 时遵循的限制和最佳实践的更多信息，请参阅微软知识库文章“在主动/主动群集上部署 Exchange 时的注意事项”，地址为http://support.microsoft.com/kb/815180.

结论

本文中的许多信息对 Exchange 管理员来说是常识。 虽然这些问题似乎显而易见，但是 ExRAP 发现甚至超大型组织也经常忽略它们。 组织可以参照本文的主题检查自己的实践和配置，以潜在地揭示其 Exchange 环境中已忽略的重要问题。