特定于群集的配置

上一次修改主题： 2006-06-20

以下几个部分描述当运行在 Exchange 群集中时为了支持某些组件的操作而必须进行的配置更改。当 Exchange 安装在群集环境中时，必须执行某些不同于安装在非群集环境中的 Exchange 服务器的公用 Exchange 任务。

Exchange MTA

默认情况下，Exchange 2003 服务器监视 MTA 服务。在群集环境中，MTA 仅在其中一个物理节点（计算机）上运行。结果，监视进程将报告任何未运行 MTA 服务的节点都将处于错误状态。如果 Exchange 2003 安装在具有两个或多个 Exchange 虚拟服务器的群集中，则又会引起问题。

若要防止监视过程错误地报告没有运行 MTA 服务的 Exchange 虚拟服务器处于错误状态，应该在群集的第二个 Exchange 虚拟服务器（如果有，还应包括任何其他附加的 Exchange 虚拟服务器）上禁用 MTA 监视。有关详细步骤，请参阅如何在 Exchange 虚拟服务器上禁用 MTA 监视。

注意：
不必在群集中的第一个 Exchange 虚拟服务器上禁用 MTA 监视。

IIS SMTP 日志记录

IIS SMTP 协议虚拟服务器创建并填充用来收集服务器使用情况的统计数据的日志文件。默认情况下不启用 SMTP 日志记录，因为它会降低 Exchange 性能。启用后，IIS 将在本地计算机的系统驱动器上（例如，C:\Windows\System32\Logfiles，其中，C 是系统驱动器的驱动器号）创建日志文件。

若要可靠地配置 IIS SMTP 日志记录，必须指定共享磁盘上的文件夹。有关详细说明，请参阅如何启用 SMTP 日志记录并将文件记录到共享磁盘。

AntiAffinityClassNames

基于 Windows 2000 服务器群集的一个局限性是它们没有用于实现条件故障转移的机制。例如，无法将 Exchange 虚拟服务器配置为当发生一个失败时转移到一个节点，而在发生另一个失败时则转移到其他节点。也无法将 Exchange 虚拟服务器配置为如果第一个节点太忙则故障转移到第二个节点。在 Windows Server 2003 群集中，由于采用了名为 AntiAffinityClassNames 的新群集组属性，从而使该局限性得以消除。该属性的值是任何任意的字符串。但是，该字符串通常是特定于程序的。例如，Exchange 2003 将该值设置为“Microsoft Exchange Virtual Server”。

AntiAffinityClassNames 用于将某个节点指定为在包含三个或更多个节点的群集中的特定资源组的可能所有者。在 Windows Server 2003 群集中，如果发生影响资源组的资源失败，则故障转移管理器将检查 AntiAffinityClassNames 的值。例如，当 Exchange 虚拟服务器资源失败时，群集故障转移管理器将确定在任何一个其他节点上的资源组（被指定为 Exchange 虚拟服务器的可能的所有者）是否将“Microsoft Exchange Virtual Server”设置为 AntiAffinityClassNames 属性的值。只有那些当前包含 Exchange 虚拟服务器的节点才会设置该值。因此，没有该值的节点将是包含失败资源的组的最有可能的目标。

以下方案演示如何使用 AntiAffinityClassNames 属性：

• 该属性可以在 N+1 Exchange 服务器群集中使用。这种情况下，Exchange 应当将 AntiAffinityClassNames 属性设置为特定于 Exchange 的值（每个组均使用相同值）来设置每个支持分区的组。如果有失败，则故障转移管理器可以通过选择不包含具有相同 AntiAffinityClassNames 值 (Exchange Virtual Server) 的组的节点来尝试使分区保持分开。
• 该属性可以在其中有多个应当保持分开的程序的服务器合并中使用。在这些情况中，应当通过在 AntiAffinityClassNames 属性中设置相同的值来手动修改代表各种程序的组。

只能通过使用 CLUSTER.EXE 命令行工具来配置该属性。在前面第一个方案中列出的示例的正确语法示例是：

cluster group "Name of Group" /prop AntiAffinityClassNames="Microsoft Exchange Virtual Server"

该命令将创建以下注册表项：

设置该属性之后，请在群集管理器中使用“最佳”选项来配置故障转移和故障回复策略，而不要为策略指定特定节点。有关详细信息，请参阅 Microsoft 知识库文章 299631，“Failover Behavior on Clusters of Three or More Nodes”（英文）。

MAPI 公用存储

在 Service Pack 1 之前，每个 Exchange 2003 群集只能容纳一个公用 MAPI 信息存储，它也称为公用文件夹数据库。这种设计是为了防止在主动/主动群集中群集故障转移到另一个服务器时将会出现的问题。由于群集中只要存在两个以上的节点，那么 Exchange 2003 必须运行在主动/被动配置中，因此，您无法遇到这样的情形：单个 Store.exe 进程必须应付来自相同 TLH 的多个公用 MAPI 信息存储。因此，使用 Exchange 2003 Service Pack 1，群集中现有的公用 MAPI 信息存储限制被删除。运行 SP1 或更高版本的安装所受限制为：每个 Exchange 虚拟服务器只能有一个公用 MAPI 信息存储（这与独立 Exchange 2003 服务器所受限制相同）。

Eseutil

在使用 /CC 开关运行 Eseutil 数据库完整性实用程序时，必须给予特殊的考虑。这个开关用来对 Exchange 信息存储执行硬恢复。硬恢复是用来将事务日志和数据库修补程序文件应用于已从联机备份还原的数据库的过程。有关详细信息，请参阅 Microsoft 知识库文章 266689，“XADM:The 'ESEUTIL /CC' Command Does Not Work on Cluster Server”（英文）。

安装更新

在 Exchange 群集节点上安装任何更新之前，请阅读 Service Pack、修补程序或更新所附带的 README 文件。大多数情况下，首先更新群集的被动节点。之后，Exchange 虚拟服务器转移到该被动节点，然后更新其他节点。应当永远不要在多个节点上同时安装任何更新。