China
快速链接 
|微软中文主页|全球站点
Microsoft
在 Microsoft.com 中搜索:
Microsoft 
搜索目标

TechNet知识库文章
中文速递邮件

Exchange 群集的概念

本文介绍了一些群集的基本概念,以及群集与 Microsoft Exchange Server 之间的关系。本文的主要目的在于加深您对群集的理解和认识。

什么是 Cluster Service(群集服务)?

群集服务是一项 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 将无法看到同一块磁盘。在这种模式下,两个节点间不能共享资源,因此被称作 无共享群集模型。
共享磁盘对于群集服务来说是一项非常重要的资源。资源将位于某个资源组中。
资源 - 资源是一个可以在群集上进行管理的单元。群集资源包括物理硬件设备(例如磁盘驱动器和网卡),以及逻辑项目(例如互联网协议 (IP) 地址、应用程序和应用程序数据库)。群集中的每个节点都拥有自己的本地资源,例如独立服务器。但是,群集也拥有公共资源,例如公共数据存储阵列和专有群集网络。群集中的所有节点都可以访问这些公共资源。资源可以联机或脱机。当资源可用并且向群集提供其服务时,我们说资源是联机的。
资源是具有以下特征的物理或逻辑实体:
可以进行联机或脱机。
可以在服务器中接受管理。
在给定时间可仅由一个节点拥有。
资源可以相互依赖(有时是必须的)。例如,以 Microsoft Exchange Information Store (MSExchangeIS) 资源为例,该资源依赖于 Microsoft Exchange System Attendant (MSExchangeSA) 资源。如果 MSExchangeSA 资源变为脱机,那么 MSExchangeIS 资源也会随之脱机,因为 MSExchangeIS 无法离开 MSExchangeSA 单独运行。注意,MSExchangeSA 位于一台非群集服务器上。此外还要注意的是,资源不能依赖于那些在不同资源组中创建的资源。
资源组 - 即由群集服务作为单个逻辑单元进行管理的资源集合。可以从逻辑上将相关资源划分到资源组中,从而实现对应用程序资源和群集实体的轻松管理。如果某个群集服务操作在资源组级别上执行,该操作将影响该组包含的所有资源。通常,创建资源组的目的是为了包含特定应用程序服务器和客户端所需的所有元素,以实现应用程序成功运行。
例如,在运行 Exchange Server 的群集服务器上,您应创建一个 Microsoft Exchange 资源组,在其中包含 MSExchangeIS、MSExchangeSA、网络名、IP 地址和磁盘这样的 Exchange 资源。独立服务器通常应该拥有的所有元素都应该位于该资源组中。注意,组的名称并不是硬编码的,所以可以根据您的喜好和创建时间为 Exchange 组使用其他名称。关键之处在于该组包含所有 Exchange 资源。
此外,请注意,资源组是可以在群集节点间移动(或故障转移到其他群集节点)的最小单位。默认情况下,一个组资源的故障可能影响到整个组。如果某个资源的失败次数达到指定次数,整个组将被转移到其他节点。默认设置为在 15 分钟内失败 4 次。
这一点很重要,因为将资源组移动到其他群集节点需要花费时间,而在此期间为客户端提供的服务也将中断。这就是让不同应用程序的资源属于各个不同资源组的重要原因,因为我们不希望某个资源的故障影响到其他资源。例如,如果您有一个 Microsoft SQL Server 组和一个 Exchange Server 组,其中一个组发生的故障不会影响到另一个组。

Cluster Administrator

可使用名为 Cluster Administrator (Cluadmin.exe) 的工具管理群集。下面是工具界面示例。

群集注册表

群集服务的一项主要功能便是确保活动群集成员关系的所有节点都拥有配置数据库的一致视图。由于节点是真实的物理计算机,它们可能会安装不同的 Windows 操作系统。这意味着它们具有各自单独的注册表。对于群集服务来说,它需要花费时间确保所有群集节点上的注册表都能正确得到同步,同时所有更改还被记录到仲裁磁盘中。
在一台群集服务器上,有一个称作 Cluster 的注册表单元,该单元位于 HKeyLocalMachine 之下。
群集服务在这个单元中保存群集配置信息。注册表的这个特定部分会通过称作 全局更新的过程,在群集节点间复制。如果更改了群集配置——例如,创建了新资源——群集服务将确保此更改被复制到所有群集节点(或者不向任何群集节点进行复制)。通过这种方式,要么所有节点都能了解到此更改,要么在更新某一个节点并出现问题时回滚更改。

仲裁磁盘资源

每个群集还有一个称为“仲裁磁盘资源”的特殊资源。
配额磁盘资源通常是一个物理磁盘资源,该资源被配置为管理仲裁日志和群集数据库检查点,它们包含了群集恢复所需的配置数据。
如果更改了群集配置,群集服务会确保群集中的所有其他节点都知道该更改,同时也会确保仲裁磁盘资源的当前所有者更新仲裁驱动器上的仲裁日志。该日志是一组事务,展示了群集配置中的不同更改。这对于群集的生存至关重要。如果仲裁驱动器无法访问或损坏,群集服务将无法启动。
下图展示了双节点群集中仲裁磁盘资源的情况。每个群集都有一个仲裁磁盘资源,而且在一个时间仅有一个节点能够访问该资源。该节点(即该时刻的仲裁磁盘资源所有者)将负责更新仲裁驱动器上的仲裁日志。

检查点

对群集配置的更新会通过称为“全局更新“的过程在节点间复制。但是如果某个应用程序没有将其配置写入群集注册表又会怎样呢?例如,Exchange Server 和 SQL Server 将它们的信息写入诸如 HKLM\System\CurrentControlSet\Services 这样的位置下的其他位置。因此,必须有一种机制,复制在这些键下进行的任何更改,例如,有关 Exchange 组件的诊断日志级别。这里正是 检查点大展身手的地方。当资源在其他节点上恢复联机时,例如在节点 B 上,它必须拥有相同的注册表信息,以便能够与在先前节点上一样工作。群集服务的 Checkpoint Manager(检查点管理器)组件便可完成此工作。
检查点被写入 MSCS 文件夹中的仲裁驱动器。将出现一个以资源 GUID 命名的文件夹。此外,由于每个资源在群集注册表中都有一个条目,您可以精确地看到复制了哪些注册表路径。例如,下面展示了为演示 MSExchangeSA 资源而复制的注册表键。注意,注册表编辑器窗口右侧窗格中列出了注册表路径。

综合运用

如果 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 之中看到服务器对象。
在 MSExchangeSA 资源安装过程中,步骤之一便是提供 Exchange 数据库的位置。在此步骤中提供共享磁盘资源的路径十分重要。
所有这些已创建的 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 虚拟服务器。两个节点都同时运行一个或一个以上的虚拟服务器。“主动/被动”表明只有一个 Exchange 虚拟服务器,并且如果其中一个节点运行了 Exchange,则另一个节点将不再运行它。注意:“主动/主动”群集具有许多问题。因此,我们并不建议您将其用作一个可伸缩解决方案。有关更多信息,请参见“更多信息”部分。
问题:如何启动或停止群集上的 Exchange Server 组件?
回答:在管理群集化的 Exchange Server 时,应总是使用 Cluster Administrator 而不是使用 Services 程序,除非微软知识库文章对管理操作提出了特殊要求。使用 Services 程序而不是使用 Cluster Administrator 会造成不可预测的结果。

问题与 Exchange Server 还是与 Windows Advanced Server 相关?

在大多数情况下,排查群集中的 Exchange Server 故障与排查非群集化服务器上的 Exchange Server 故障并无二致。在群集上,不直接涉及操纵 Exchange 资源的任何问题都可以按照非群集服务器上的做法进行解决。
作为一条通用原则,如果 Exchange Server 资源出现问题,例如 MSExchangeSA 或 MSExchangeIS 没有联机,那么问题很可能出现在 Exchange Server 上。如果核心群集资源之一没有联机(例如,某个网络名称或磁盘),那么问题应该属于 Windows 平台的群集问题。故障转移问题通常遵循相同的指导原则。
可通过群集日志肯定地确定问题的来源。有关更多信息,请参见“更多信息”部分。

更多信息

有关更多信息,请参见如下 Exchange 资源以及微软知识库文章: