群集服务是一项 Microsoft Windows 服务,可在特定版本的 Windows 操作系统上使用。Microsoft Windows Server 2003 企业版、Windows Server 2003 数据中心版、Windows 2000 Advanced Server 以及 Windows 2000 Datacenter Server 操作系统支持群集。Windows NT Server 4.0 企业版自 Service Pack 3 (SP3) 开始支持群集,但是本文不介绍有关 Windows NT Server 4.0 群集的详细内容。
从总体上看,排查群集服务器上的 Exchange Server 问题时应遵循的准则与排查运行 Exchange Server 的非群集服务器时基本相同。
我们假定您拥有一个双节点群集。我们介绍的准则同样适用于两个节点以上的群集,但是随着节点数量的增加,问题的复杂性也会随之增加。所以,在本例中,我们从节点 A 和节点 B 开始。
资源和资源组
在微软的群集实施过程中,节点 A 和节点 B 都必须连接到某种类型的共享存储。该共享存储必须位于 SCSI 总线上,既可以是直接连接存储,也可以是存储局域网 (SAN)。在工作正常的群集中,在同一时刻,只有 1 个节点能够完全访问任意一个共享磁盘。所以,如果节点 A 拥有共享存储,节点 B 将无法看到同一块磁盘。在这种模式下,两个节点间不能共享资源,因此被称作
无共享群集模型。
资源可以相互依赖(有时是必须的)。例如,以 Microsoft Exchange Information Store (MSExchangeIS) 资源为例,该资源依赖于 Microsoft Exchange System Attendant (MSExchangeSA) 资源。如果 MSExchangeSA 资源变为脱机,那么 MSExchangeIS 资源也会随之脱机,因为 MSExchangeIS 无法离开 MSExchangeSA 单独运行。注意,MSExchangeSA 位于一台非群集服务器上。此外还要注意的是,资源不能依赖于那些在不同资源组中创建的资源。
这一点很重要,因为将资源组移动到其他群集节点需要花费时间,而在此期间为客户端提供的服务也将中断。这就是让不同应用程序的资源属于各个不同资源组的重要原因,因为我们不希望某个资源的故障影响到其他资源。例如,如果您有一个 Microsoft SQL Server 组和一个 Exchange Server 组,其中一个组发生的故障不会影响到另一个组。
群集服务的一项主要功能便是确保活动群集成员关系的所有节点都拥有配置数据库的一致视图。由于节点是真实的物理计算机,它们可能会安装不同的 Windows 操作系统。这意味着它们具有各自单独的注册表。对于群集服务来说,它需要花费时间确保所有群集节点上的注册表都能正确得到同步,同时所有更改还被记录到仲裁磁盘中。
对群集配置的更新会通过称为“全局更新“的过程在节点间复制。但是如果某个应用程序没有将其配置写入群集注册表又会怎样呢?例如,Exchange Server 和 SQL Server 将它们的信息写入诸如
HKLM\System\CurrentControlSet\Services 这样的位置下的其他位置。因此,必须有一种机制,复制在这些键下进行的任何更改,例如,有关 Exchange 组件的诊断日志级别。这里正是
检查点大展身手的地方。当资源在其他节点上恢复联机时,例如在节点 B 上,它必须拥有相同的注册表信息,以便能够与在先前节点上一样工作。群集服务的 Checkpoint Manager(检查点管理器)组件便可完成此工作。
如果 Exchange Server 安装在群集服务器上,安装程序默认仅将 Exchange Server 的二进制文件复制到硬盘驱动器并对群集注册表执行一些修改。甚至在群集的所有节点上安装了 Exchange Server 之后,您仍然不会像在非群集服务器上那样在 Exchange System Manager 中看到任何变化。非群集化的安装程序会在 Active Directory 目录服务中创建 Exchange 服务器对象,但是群集化的安装程序不会这样做。
如果已在所有节点上安装了 Exchange Server,必须在 Exchange 资源组中手动创建 MSExchangeSA 资源。创建 MSExchangeSA 之后,它将为您自动创建所有其他 Exchange 资源,例如 MSExchangeIS、消息传输代理 (MTA) 以及 HTTP 虚拟服务器。此时,服务器对象才会在 Active Directory 的配置分区中添加到 Active Directory,因此从现在开始,您将能够从 Exchange System Manager 之中看到服务器对象。
所有这些已创建的 Exchange 资源通常都被称作 Exchange Virtual Server (EVS)。以下示例展示了它们在 Cluster Administrator 中的样子。
现在,Microsoft Office Outlook 2003 客户端实际上应连接到该 EVS 名称,而不是连接到某个群集节点的名称。如果在
Exchange 组中选中
网络名称的
属性,则可以找到 EVS 名称。如果客户端连接到 EVS 名,无论当前哪一个群集节点拥有
Exchange 组,客户端都只需访问同一个名称即可。这是 Exchange Server 实现群集的要点所在。如果群集节点发生故障,其他群集节点之一将获得 EVS 的所有权,因此客户端仍可连接到相同的 Exchange 服务器。例如,如果客户端以前一直连接到节点 A 而不是 Exchange Server,然后节点 A 发生故障,那么客户端的 Exchange 服务器将变得不可用。
下图展示了虚拟服务器的概念以及它与实际的群集节点的关系。用户将打开他们的 Outlook 客户端并通过网络连接到当前被节点 A 拥有的 Exchange 虚拟服务器。节点 A 是控制包含 Exchange 2000 Server 数据库的共享磁盘的节点。
例如,如果节点 A 发生硬件故障,节点 B 会发现节点 A 出现故障,然后接管 Exchange 虚拟服务器及所有相关资源的所有权。节点 B 获取了网络名称、IP 地址、磁盘、系统助理以及所有其他 Exchange 资源的所有权。使用 Outlook 客户端登录的用户并不知道此次故障,因为他们是连接到 EVS 而不是连接到某个特定的物理服务器。他们不关心当前哪一个节点拥有虚拟服务器。
问题与 Exchange Server 还是与 Windows Advanced Server 相关?
在大多数情况下,排查群集中的 Exchange Server 故障与排查非群集化服务器上的 Exchange Server 故障并无二致。在群集上,不直接涉及操纵 Exchange 资源的任何问题都可以按照非群集服务器上的做法进行解决。
作为一条通用原则,如果 Exchange Server 资源出现问题,例如 MSExchangeSA 或 MSExchangeIS 没有联机,那么问题很可能出现在 Exchange Server 上。如果核心群集资源之一没有联机(例如,某个网络名称或磁盘),那么问题应该属于 Windows 平台的群集问题。故障转移问题通常遵循相同的指导原则。