Exchange 群集的概念

资源和资源组

在微软的群集实施过程中，节点 A 和节点 B 都必须连接到某种类型的共享存储。该共享存储必须位于 SCSI 总线上，既可以是直接连接存储，也可以是存储局域网 (SAN)。在工作正常的群集中，在同一时刻，只有 1 个节点能够完全访问任意一个共享磁盘。所以，如果节点 A 拥有共享存储，节点 B 将无法看到同一块磁盘。在这种模式下，两个节点间不能共享资源，因此被称作无共享群集模型。

共享磁盘对于群集服务来说是一项非常重要的资源。资源将位于某个资源组中。

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 而不是连接到某个特定的物理服务器。他们不关心当前哪一个节点拥有虚拟服务器。