test

Sun Cluster 3.0 U1 概念

群集管理和应用程序开发

此信息主要面向使用 SunPlex API 和 SDK 的系统管理员和应用程序开发者。系统管理员可以将此信息作为安装、配置和管理群集软件的背景知识。应用程序开发者可以通过此信息来了解他们工作的群集环境。

下图从较高的层次上显示了群集管理概念与群集体系结构之间的对应关系。

图形 3-1 Sun Cluster 软件体系结构

Graphic

管理界面

您可以从若干用户界面中选择如何安装、配置和管理 SunPlex 系统。还可以通过命令行接口来完成系统管理任务。在命令行接口的上部有一些实用程序，用于简化选定的配置任务。SunPlex系统还有一个模块，作为 Sun Management Center（可向某些群集任务提供 GUI）的一部分来运行。关于管理接口的完整说明，可参见《Sun Cluster 3.0 U1 系统管理指南》中包括介绍性内容的一章。

群集时间

群集中的所有节点之间的时间必须同步。您是否将群集节点与任何外部时间源同步对于群集操作并不重要。SunPlex 系统使用网络时间协议 (NTP) 在节点间保持时钟同步。

通常，系统时钟一秒钟的时间改变不会有任何问题。然而，如果要在活动的群集中运行 date(1)、rdate(1M) 或 xntpdate(1M)（以交互方式或在 cron 脚本内）命令，就会强制执行远远超过一秒钟的时间改变，以使系统时钟与时间源同步。这一强制改变会给文件修改时间戳记带来问题，或造成 NTP 服务混乱。

在每个群集节点上安装 Solaris 操作环境时，您可以改变节点的缺省时间和日期设置。一般情况下，可以接受出厂缺省设置。

使用 scinstall(1M) 来安装 Sun Cluster 软件时，其中有一步是配置群集的 NTP。Sun Cluster 软件提供了一个模板文件 ntp.cluster（请参见已安装的群集节点上的 /etc/inet/ntp.cluster），它在所有群集节点间建立一种对等的关系，其中有一个节点是"首选"节点。节点由它们的专用主机名标识，时间同步会在群集互连系统中进行。关于如何配置群集的 NTP 的说明，可从《Sun Cluster 3.0 U1 安装指南》中获得。

或者您也可以在群集之外设置一个或多个 NTP 服务器，并更改 ntp.conf 文件来体现此配置。

正常运行时，绝不需要调整群集的时间。然而，如果安装 Solaris 操作环境时时间设置不正确，现在想更改时间，可在《Sun Cluster 3.0 U1 系统管理指南》中找到操作步骤。

高可用性框架

SunPlex 系统使用户和数据间的"路径"上的所有组件都具有高度可用性，这些组件包括网络接口、应用程序本身、文件系统和多主机磁盘。一般情况下，如果一个群集组件可从系统中的任何单一（软件或硬件）故障中恢复，则它是高度可用的。

下表显示了 SunPlex 组件故障种类（硬件和软件）和高可用性框架内置的恢复种类。

表 3-1 SunPlex 故障检测和恢复级别

发生故障的群集组件 

软件恢复 

硬件恢复 

数据服务 

HA API，HA 框架 

无 

公共网络适配器 

网络适配器故障转移 (NAFO) 

多个公共网络适配卡 

群集文件系统 

主要和辅助复制 

多主机磁盘 

被镜像的多主机磁盘 

卷管理（Solstice DiskSuite 和 VERITAS Volume Manager） 

硬件 RAID-5（例如 Sun StorEdge A3x00） 

全局设备 

主要和辅助复制 

到设备、群集传输结点的多个路径 

专用网 

HA 传输软件 

多个专用硬件独立网络节点 

节点 

CMM，故障快速防护驱动程序 

多个节点 

Sun Cluster 软件的高可用性框架可迅速检测到节点故障，并在群集中的其余节点上为该框架资源创建一个新的等效服务器。不会出现所有框架资源都不可用的情况。在恢复期间，未受崩溃节点影响的框架资源是完全可用的。而且，故障节点的框架资源一经恢复就立即可用。已恢复的框架资源不必等待其他所有框架资源完全恢复。

可用性最高的框架资源的恢复对于使用它的应用程序（数据服务）来说是透明的。框架资源访问的语义在整个节点故障期间得到全面的保护。应用程序根本不知道框架资源已转移到另一节点。只要存在从另一节点到磁盘的替换路径，单个节点的故障对使用连接到此节点的文件、设备和磁盘卷的其他节点上的程序来说就是完全透明的。多主机磁盘的使用就是一个样例，这些磁盘具有连接多个节点的端口。

群集成员监视器

群集成员监视器 (CMM) 是一个分布式代理程序集，每个群集成员有一个代理程序。这些代理程序通过群集互连交换信息，来实现以下功能：

与 Sun Cluster 软件以前的发行版不同，CMM 完全运行在内核中。

群集成员

CMM 的主要功能是针对在任一给定时间加入群集的节点集合建立一个群集范围内的协议。这种约束称为群集成员。

为确定群集成员并最终保证数据的完整性，CMM：

有关群集如何防止自身划分为多个独立群集的详细信息，请参见 "定额和定额设备"。

群集成员监视器重新配置

为确保数据免遭破坏，所有节点必须在群集成员上达成一致协议。需要时，CMM 将协调群集服务（应用程序）的群集重新配置，以作为对故障的响应。

CMM 会从群集传输层接收到关于与其他节点连通性的信息。CMM 使用群集互连在重新配置期间交换状态信息。

检测到群集成员有更改后，CMM 执行群集的同步配置，这时群集资源可能会按群集的新的成员关系被重新分配。

故障快速防护机制

如果 CMM 检测到节点上存在严重的问题，它会要求群集框架来强制关闭该节点（应急状态）并将其从群集成员中删除。实现这种功能的机制称为故障快速防护。故障快速防护会使节点以两种方式关闭。

当群集守护程序中止而导致应急状态时，该节点的控制台上将显示类似以下内容的信息。


panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

应急状态过后，节点可能重新引导，试图重新连接群集或停留在 OpenBoot PROM (OBP) 提示符下。所采取的措施取决于 OBP 中 auto-boot? 参数的设置。

群集配置库 (CCR)

群集配置库 (CCR) 是专用的群集范围的数据库，用于保存与群集的配置和状态有关的信息。CCR 是一个分布式数据库。每个节点上都有该数据库的完整副本。CCR 可确保所有节点看到的群集世界都一样。要避免损坏数据，各个节点都需要知道群集资源的当前状态。

CCR 使用两阶段提交算法进行更新：更新必须在所有群集成员上均成功完成，否则更新将被转返。CCR 使用群集互连来应用分布式更新。

小心：小心：

尽管 CCR 是由文本文件组成的，但也绝不要手动编辑 CCR 文件。每个文件都包含一个校验和记录来保证节点间的一致性。手动更新 CCR 文件可能会导致某个节点或整个群集不能工作。

CCR 靠 CMM 来保证群集只有在定额建立后才能运行。CCR 负责验证数据在整个群集范围内的一致性，需要时执行恢复，并协助进行数据更新。

全局设备

SunPlex 系统使用全局设备提供群集范围内的高可用性访问，这种访问可以是对群集中的任一设备，自任意节点，而不用考虑设备的物理连接位置。如果一个节点在提供对某个全局设备的访问时出现故障，则 Sun Cluster 软件会自动找到指向该设备的另一路径，并将访问重定向到此路径。Sun Cluster 全局设备包括磁盘、CD-ROM 和磁带。不过，磁盘是唯一支持的多端口全局设备。这意味着 CD-ROM 和磁带设置目前还不是高可用性的设备。每个服务器上的本地磁盘也不是多端口的，因而也不是高可用性设备。

群集会给群集中的每个磁盘、CD-ROM 和磁带设备分配唯一的 ID。这种分配使得从群集中任何节点到每个设备的访问都保持一致性。全局设备名称空间保存在 /dev/global 目录下。有关详细信息，请参见"全局名称空间"。

多端口全局设备可为一个设备提供多个路径。至于多主机磁盘，因为这些磁盘是以一个以上节点作为主机的磁盘设备组的一部分，所以它们是高可用性设备。

设备 ID (DID)

Sun Cluster 软件通过一种称为设备 ID (DID) 伪驱动程序的结构来管理全局设备。此驱动程序可自动给群集内的每个设备（包括多主机磁盘、磁带驱动器和 CD-ROM）分配唯一的 ID。

设备 ID (DID) 伪驱动程序是群集的全局设备访问功能的基本构成部分。DID 驱动程序探测群集中的所有节点并建立唯一磁盘设备列表，给每个磁盘设备分配唯一的主/次编号，这些编号在群集中所有节点上都是一致的。执行对全局设备的访问时使用的是 DID 驱动程序分配的唯一设备 ID，而非传统的 Solaris 设备 ID（如某一磁盘的标识 c0t0d0）。

这一措施可确保任何访问磁盘的应用程序（如卷管理器或使用原始设备的应用程序）都能在群集上使用一致的路径。此一致性对多主机磁盘尤为重要，因为每个设备的本地主/次编号在各节点上都可能不相同，因而也就改变了 Solaris 设备命名惯例。例如，节点 1 可能将一个多主机磁盘看作 c1t2d0，而节点 2 可能会完全不同，将同一磁盘看作是 c3t2d0。DID 驱动程序会分配一个全局名称（如 d10）供节点使用，这样就为每个节点提供了到多主机磁盘的一致映射。

您可以通过 scdidadm(1M) 和 scgdevs(1M) 更新和管理设备 ID。有关详细信息，请参见相应的手册页。

磁盘设备组

在 SunPlex 系统中，所有多主机磁盘都必须由 Sun Cluster 软件进行控制。首先在多主机磁盘上创建卷管理器磁盘组（Solstice DiskSuite 磁盘集或 VERITAS Volume Manager 磁盘组）。然后将卷管理器磁盘组注册为磁盘设备组。磁盘设备组是一种全局设备。此外，Sun Cluster 软件会将每一个磁盘都注册为磁盘设备组。

注册提供了有关各个节点连接到卷管理器磁盘组的路径的 SunPlex 系统信息。此时，在群集范围内可以对卷管理器磁盘组进行全局访问。如果多个节点均可写入（控制）磁盘设备组，存储在该磁盘设备组中的数据将具有高度可用性。此高度可用的磁盘设备组可用于存储群集文件系统。

注意：

磁盘设备组独立于资源组。一个节点可以控制资源组（代表一组数据服务进程），而另一个节点可以控制正被数据服务访问的磁盘组。不过最好的做法是，让存储特定应用程序数据的磁盘设备组和包含此应用程序资源（应用程序守护程序）的资源组保持在同一节点上。有关磁盘设备组和资源组之间关系的详细信息，请参见《Sun Cluster 3.0 U1 Data Services Installation and Configuration Guide》中包含概述性内容的一章。

通过磁盘设备组，卷管理器磁盘组成为"全局"组，因为它为基础磁盘提供了多路径支持。物理连接到多主机磁盘的每个群集节点都提供了一条到磁盘设备组的路径。

磁盘设备组故障转移

因为磁盘群组连接着一个以上的节点，所以群组中所有磁盘设备组在当前控制它的节点出现故障时，都可以通过备用路径访问。控制设备组的节点出现故障不会影响对此设备组的访问，但在执行恢复和一致性检查时除外。在这段时间，所有请求都被阻挡（对应用程序是透明的），直到系统使该设备组可用为止。

图形 3-2 磁盘设备组故障转移

Graphic

全局名称空间

启用全局设备的 Sun Cluster 软件机制是全局名称空间。全局名称空间包括 /dev/global/ 分层结构和卷管理器名称空间。全局名称空间可以反映多主机磁盘和本地磁盘（及所有其他群集设备，如 CD-ROM 和磁带），并提供指向多主机磁盘的多条故障转移路径。物理连接到多主机磁盘的每个节点都为群集中的任何节点提供了到存储器的路径。

正常情况下，卷管理器名称空间的驻留位置是：对于 Solstice DiskSuite，在 /dev/md/diskset/dsk（和 rdsk）目录下；对于 VxVM，在 /dev/vx/dsk/disk-group 和 /dev/vx/rdsk/disk-group 目录下。这些名称空间分别由整个群集中引入的各 Solstice DiskSuite 磁盘集和各 VxVM 磁盘组的目录组成。每一目录中都有此磁盘集或磁盘组中每个元设备或卷的设备节点。

在 SunPlex 系统中，本地卷管理器名称空间中的每个设备节点都被替换为指向 /global/.devices/node@nodeID 系统文件的某个设备节点的符号链接，其中 nodeID 是一个整数，代表群集中的节点。Sun Cluster 软件还会在卷管理器设备的标准位置上将其显示为符号链接。全局名称空间和标准卷管理器名称空间两者在任何群集节点上都可以找到。

全局名称空间的优点有：

本地和全局名称空间示例

下表显示的是一个多主机磁盘 c0t0d0s0 的本地名称空间和全局名称空间之间的映射关系。

表 3-2 本地和全局名称空间映射

组件/路径 

本地节点名称空间 

全局名称空间 

Solaris 逻辑名称 

/dev/dsk/c0t0d0s0

/global/.devices/node@ID /dev/dsk/c0t0d0s0

DID 名称 

/dev/did/dsk/d0s0

/global/.devices/node@ID /dev/did/dsk/d0s0

Solstice DiskSuite 

/dev/md/diskset/dsk/d0

/global/.devices/node@ID /dev/md/diskset/dsk/d0

VERITAS Volume Manager 

/dev/vx/dsk/disk-group /v0

/global/.devices/node@ID /dev/vx/dsk/disk-group/v0

全局名称空间在安装时自动生成，并在每次重新配置后重新引导时自动更新。也可以运行 scgdevs(1M) 命令来生成全局名称空间。

群集文件系统

群集文件系统是一个节点上的内核和某个与磁盘进行了物理连接的节点上运行的基础文件系统及卷管理器之间的代理。

群集文件系统依赖于和一个或多个节点进行了物理连接的全局设备（磁盘、磁带、CD-ROM）。全局设备可从群集中任何节点上通过同一个文件名称（如 /dev/global/）访问，而不用管此节点与存储设备是否有物理连接。可以像常规设备那样使用全局设备，也就是说，可在该设备上面可以用 newfs 和/或 mkfs 命令创建文件系统。

对于全局设备上的文件系统，可以使用 mount -g 进行全局安装，也可使用 mount 进行本地安装。

通过相同的文件名称（例如 /global/foo），程序可以从群集中的任何节点访问群集文件系统中的文件。

群集文件系统安装在所有的群集成员上。不能在群集成员的子集上安装群集文件系统。

群集文件系统不是特殊的文件系统类型。也就是说，客户机看到的是基础文件系统（如 UFS）。

使用群集文件系统

在 SunPlex 系统中，所有多主机磁盘都放在磁盘设备组中，这些组可以是 Solstice DiskSuite 磁盘集、VxVM 磁盘组或不受基于软件的卷管理器控制的独立磁盘。

要使群集文件系统具有高可用性，基础磁盘存储器必须连接到一个以上的节点。因此，群集文件系统中的本地文件系统（存储在节点的本地磁盘上的文件系统）不具有高可用性。

与一般的文件系统一样，您可以通过两种方式安装群集文件系统：

注意：

Sun Cluster 软件不强制使用群集文件系统的命名策略，所以可以通过在同一目录下（如 /global/disk-device-group）为所有群集文件系统创建一个安装点，以便于进行管理。有关详细信息，请参见《Sun Cluster 3.0 U1 安装指南》和《Sun Cluster 3.0 U1 系统管理指南》。

群集文件系统的特性

群集文件系统具有以下特性：

Syncdir 安装选项

syncdir 安装选项可用于将 UFS 用作基础文件系统的群集文件系统。不过，如果不指定 syncdir，性能会有明显提高。如果您指定 syncdir，则保证写入的数据符合 POSIX 标准。如果不指定，则会遇到 NFS 文件系统中通常会发生的问题。例如，在某些情况下，如果不指定 syncdir，就只能在关闭一个文件后才发现空间不足。指定了 syncdir（和 POSIX 行为），在写入操作过程中系统就能发现空间不足的问题。不指定 syncdir 很少会出现问题，所以我们建议最好不要指定该选项，这样做有助于提高系统性能。

有关全局设备和群集文件系统的常见问题，请参见"文件系统常见问题"。

定额和定额设备

由于群集节点能共享数据和资源，所以千万不要将群集分割为同时处于活动状态的独立分区。CMM 保证任何时候最多只有一个群集是有效的，即使已对群集互连进行了分区。

群集分区会引起两类问题：群集分割和失忆。如果在节点间失去群集互连并且将群集划分为若干子群集，每个分区都认为自己是唯一分区，此时即会发生群集分割。这是由群集节点之间的通信问题引起的。在群集关闭后又重新启动的情况下会发生失忆，此时的群集数据的版本要早于群集关闭时记录的信息的版本。如果磁盘上存储有多个版本的框架数据，而在尚未获得最新的版本的情况下启动新的群集，则可能发生这种情况。

可以通过以下方法来避免群集分割和失忆的发生：赋予每个节点一个选票，并规定只有获得多数选票才能成为有效群集。获得多数选票的分区拥有 定额，因此允许其运行。只要群集中有两个以上的节点，这种多数选票机制就非常有效。在双节点群集中，多数为二。如果这样的群集分为两个分区，则需要使用外部选票才能使其中一个分区获得定额。此外部选票由 定额设备提供。定额设备可以是这两个节点所共享的任一磁盘。用作定额设备的磁盘可以包含用户数据。

表 3-3 说明 Sun Cluster 软件如何使用定额来避免群集分割和失忆。

表 3-3 群集定额及群集分割和失忆问题

分区类型 

定额解决方案 

群集分割 

仅允许获得多数选票的分区（子群集）作为群集（其中最多仅能有一个拥有多数选票的分区） 

失忆 

在群集引导时，保证至少有一个节点是最新的群集成员之一（因而有最新的配置数据） 

定额算法动态执行：当群集事件触发计算时，计算的结果可以随群集生存期的不同而改变。

定额选票计数

群集节点和定额设备都会获得选票以形成定额。缺省情形下，群集节点在引导并成为群集成员时获取其中一个的定额选票计数。节点的选票数可以是零，例如当正在安装节点或管理员将节点置于维护状态时便是如此。

定额设备获取定额选票计数基于设备的节点连接数。在设置定额设备时，它需获取一个最大选票数 N-1，其中 N 是有非零选票数的节点数，并且这些节点有到定额设备的端口。例如，连接到两个选票数非零的节点的定额设备有其中一个的定额数（二减一）。

您要在群集安装期间，或以后通过使用在《Sun Cluster 3.0 U1 系统管理指南》中描述的过程来配置定额设备。

注意：

仅在当前连接的节点中至少有一个是群集成员时，定额设备才对选票数起作用。同时，在群集引导期间，仅在当前连接的至少一个节点正在引导，并且在关闭时它是最近刚刚引导的群集成员的情况下，定额设备才对选票数起作用。

定额配置

定额配置依赖于群集中节点的数目：

图形 3-3 定额设备配置示例

Graphic

定额准则

在设置定额设备时，请使用下列准则：

提示：

要防止个别定额设备出现故障，请在节点集之间配置一个以上的定额设备。使用来自不同群组的磁盘，并在每个节点集之间配置奇数的定额设备。

故障防护

群集的一个主要问题是引起群集分区的故障（称作群集分割）。当此故障发生时，并不是所有节点都可以通信，所以个别节点或节点子集可能会尝试组成个体或群集子集。每个子集或分区都可能以为它对多主机磁盘具有唯一访问权和所有权。多个节点试图写入磁盘会导致数据损坏。

故障防护通过以物理方式防止对磁盘的访问，限制了节点对多主机磁盘的访问。当节点脱离群集时（它或是发生故障，或是分区），故障防护确保了该节点不再能访问磁盘。只有当前成员节点有权访问磁盘，以保持数据的完整性。

磁盘设备服务为使用多主机磁盘的服务提供了故障转移能力。在当前担当磁盘设备组主节点（属主）的群集成员发生故障或变得无法访问时，一个新的主节点会被选中，在极短时间的中断后重又恢复对磁盘设备组的访问，。在此过程中，旧的主节点必须放弃对设备的访问，然后新的主节点才能启动。然而，当一个成员从群集断开并变得无法访问时，群集无法通知该节点释放那些将它作为主节点的设备。因而，需要一种方法来使群集中存活的成员能够接替发生故障的成员来控制并访问全局设备。

SunPlex 系统使用 SCSI 磁盘保留来实现故障防护。使用 SCSI 保留，可将故障节点与多主机磁盘"隔离"，使其无法访问那些磁盘。

SCSI-2 磁盘保留支持一种保留形式，它或者授予客户机对连接到磁盘的所有节点的访问权限（当没有保留上时），或者只授予客户机对某一单个节点（即拥有该保留的节点）的访问权限。

当群集成员检测到另一个节点不再通过群集互连进行通信时，它启动故障防护措施来阻止另一个节点访问共享磁盘。当发生此故障防护时，通常将防护的节点处于应急状态，并在其控制台上显示"保留冲突"的消息。

发生保留冲突是因为在节点已被检测到不再是群集成员后，一个 SCSI 保留被置于在此节点与其他节点间共享的所有磁盘上。防护节点可能不会意识到它正在被防护，并且如果它试图访问这些共享磁盘之中的一个，它会检测到保留和应急状态。

故障防护的故障快速防护机制

群集框架通过一种机制确保故障节点无法重新引导并开始写入共享存储器，这种机制被称为故障快速防护。

属于群集成员的节点对它们可以访问的磁盘（包括定额磁盘）持续启用一个特定 ioctl，MHIOCENFAILFAST。该 ioctl 是对磁盘驱动程序的指令，如果某磁盘被其它节点保留而无法由该节点访问，该指令使该节点能够将自身处于应急状态。

MHIOCENFAILFAST ioctl 指示驱动程序检查节点对磁盘发出的每个读写操作所返回的错误，查看是否返回 Reservation_Conflict 错误代码。ioctl 定期在后台向磁盘发出一个测试操作，检查是否出现 Reservation_Conflict。如果系统返回 Reservation_Conflict 消息，前台和后台控制流路径均进入应急状态。

对于 SCSI-2 磁盘，保留不是永久性的－它们无法免于节点重新引导。对于具有持久性组保留 (PGR) 的 SCSI-3 磁盘，保留信息存储在磁盘上，并在多次节点重新引导后仍保持有效。无论使用 SCSI-2 磁盘还是 SCSI-3 磁盘，故障快速防护机制的工作方式都是一样的。

如果某节点与群集中其它节点失去连接，并且它不属于可获取定额的分区的一部分，它将被另一节点强行从该群集中删除。属于可获取定额的分区一部分的另一节点将保留放置在共享磁盘上，当不具备定额的节点试图访问共享磁盘时，它将接到保留冲突消息，并在故障快速防护机制的作用下进入应急状态。

进入应急状态之后，节点可能重新引导，试图重新连接群集；也可能停留在 OpenBoot PROM (OBP) 提示符状态下。所采取的措施取决于 OBP 中 auto-boot? 参数的设置。

卷管理器

SunPlex 系统使用卷管理软件通过镜像和热备份磁盘来增加数据的可用性，并处理磁盘故障和更换。

SunPlex 系统没有它自己的内部卷管理器组件，而依赖于下面的卷管理器：

群集中的卷管理软件提供对如下功能的支持：

一旦卷管理对象受控于群集，它们就成为磁盘设备组。有关卷管理器的信息，请参见卷管理器软件文档。

注意：

在规划磁盘集或磁盘组时一个重要的考虑事项就是要了解它们的关联磁盘设备组是如何在群集内与应用程序资源（数据）相联系的。关于这些问题的讨论，请参考《Sun Cluster 3.0 U1 安装指南》和《Sun Cluster 3.0 U1 Data Services Installation and Configuration Guide》。

数据服务

术语数据服务是用来描述诸如 Oracle 或 iPlanet Web Server 之类的第三方应用程序，该应用程序已配置为在群集上运行，而不是在一个单独的服务器上运行。 数据服务包括应用程序、专用的 Sun Cluster 配置文件，以及控制下列应用程序操作的 Sun Cluster 管理方法。

图形 3-4 将运行于单个应用程序服务器（单服务器模型）之上的应用程序与运行于群集（群集服务器模型）之上的同一应用程序进行比较。注意：从用户的观点来看，这两种配置没有任何区别，只是群集的应用程序可能运行速度更快、可用性更高而已。

图形 3-4 标准与群集客户机/服务器配置

Graphic

在单服务器模型中，可以对应用程序进行配置，以便通过公共网络接口（主机名）来访问该服务器。 主机名与物理服务器有关。

在群集服务器模型中，公共网络接口为逻辑主机名或共享地址。术语网络资源是指逻辑主机名和共享地址。

某些数据服务要求指定逻辑主机名或共享地址作为网络接口－它们不可互换。其它数据服务允许您指定逻辑主机名或共享地址。有关必须指定的接口类型的详细信息，请参见每项数据服务的安装与配置信息。

网络资源与具体的物理服务器无关－它可以在物理服务器之间进行移植。

最初，网络资源仅与一个节点，即主节点有关联。如果主节点出现故障，网络资源及应用程序资源将切换到另一群集节点（辅助节点）。进行网络资源故障切换后，经过短暂延迟，应用程序资源就可以在辅助节点上继续正常运行。

图形 3-5 将单服务器模型与群集服务器模型进行比较。注意：在群集服务器模型中，网络资源（即本例中的逻辑主机名）可以在两个或多个群集节点之间移动。该应用程序已配置为使用这一逻辑主机名，而不使用与特定服务器相关的主机名。

图形 3-5 固定主机名与逻辑主机名

Graphic

共享地址最初也仅与一个节点相关联。这个节点被称为全局接口节点 (GIN)。共享地址被用作与群集之间的单一网络接口,这就是全局接口。

逻辑主机名模型与可伸缩服务模型之间的区别在于，在后一种模型中，每个节点在其回送接口上还配置有共享地址。这种配置使同一数据服务的多个实例可以同时在几个节点上使用。术语"可伸缩服务"是指可以通过添加额外的群集节点，为应用程序增添 CPU 能量，从而增强性能。

如果 GIN 出现故障，将在另一个也在运行该应用程序的实例的节点上启用共享地址（因此这个节点就成为新的 GIN）。或者，可以将共享地址故障切换到之前未运行该应用程序的另一个群集节点上。

图形 3-6 将单服务器配置与可伸缩群集服务配置进行比较。注意：在可伸缩服务配置中，共享地址出现在所有节点上。与逻辑主机名用于故障转移数据服务的方式类似，应用程序已配置为使用这个共享地址，而不使用与特定服务器相关联的主机名。

图形 3-6 固定主机名与共享地址

Graphic

数据服务方法

Sun Cluster 软件提供了一套服务管理方法。这些方法在 Resource Group Manager (RGM) 的控制下运行，RGM 使用它们来启动、停止和监视群集节点上的应用程序。这些方法连同群集框架软件和多主机磁盘一起，使应用程序能够实现故障转移或可伸缩的数据服务。

RGM 也管理群集中的资源，包括应用程序实例和网络资源（逻辑主机名和共享地址）。

除 Sun Cluster 软件提供的方法之外，SunPlex 系统还提供一个 API 和多种数据服务开发工具。这些工具使应用程序编程人员能够开发所需要的数据服务方法，以使其它应用程序作为高度可用的数据服务与 Sun Cluster软件一起运行。

Resource Group Manager (RGM)

RGM 将数据服务（应用程序）作为资源控制，资源是由资源类型实现所管理的。这些实现或者由 Sun 提供，或者由具有一个普通数据服务模板、数据服务开发库 API (DSDL API) 或资源管理 API (RMAPI) 的开发者创建。 群集管理员在称为资源组的容器中创建和管理资源。RGM 根据群集成员关系的变化停止和启动所选节点上的资源组。

RGM 可用于资源和资源组。RGM 操作导致资源和资源组在联机和脱机状态之间进行转换。 "资源和资源组状态与设置" 中提供适用于资源和资源组的各种状态与设置的完整说明。

故障转移数据服务

如果正在运行数据服务的节点（主节点）发生故障，那么该服务会被移植到另一个工作节点而无需用户干预。故障转移服务利用了故障转移资源组，它是一个用于应用程序实例资源和网络资源（逻辑主机名）的容器。逻辑主机名是一些可以配置到节点上的 IP 地址，然后自动在原始节点解除配置，并配置到另一节点上。

对于故障转移数据服务，应用程序实例仅在一个单独的节点上运行。如果故障监视器检测到一个故障，它或者试图在同一节点上重新启动该实例，或者在另一个节点上启动实例（故障转移），这取决于该数据服务是如何配置的。

可伸缩数据服务

可伸缩数据服务对多个节点上的活动实例有潜能。可伸缩服务使用两个资源组：利用可伸缩资源组来保存应用程序资源，利用故障转移资源组来保存可伸缩服务所依赖的网络资源（ 共享地址）。可伸缩资源组可以在多个节点上联机，因此服务的多个实例可以立刻运行。以共享地址为主机的故障转移资源组每次只在一个节点上联机。以可伸缩服务做主机的所有节点使用相同的共享地址来主持该服务。

服务请求通过一个单独的网络接口（全局接口）进入群集，并依据由负载平衡策略设置的几个预定义算法之一来将这些请求分发到节点。群集可以使用负载平衡策略来平衡几个节点间的服务负载。注意：在不同节点上可以有多个全局接口以其它共享地址为主机。

对于可伸缩服务来说，应用程序实例在几个节点上同时运行。如果拥有全局接口的节点出现故障，全局接口将切换到其他节点。如果一个正在运行的应用程序实例发生故障，则该实例尝试在同一节点上重新启动。

如果应用程序实例不能在同一节点上重新启动，而另一个未使用的节点被配置运行该服务，那么该服务会切换到这个未使用的节点。否则，它继续运行在那些剩余节点上，并且很可能会降低服务吞吐量。

注意：

每个应用程序实例的 TCP 状态与该实例一起保存在此节点上，而不是在全局接口节点上。因此，全局接口节点上的故障不影响连接。

图形 3-7 显示了故障转移和可伸缩资源组的一个示例，以及在它们之间存在的对于可伸缩服务的依赖性。此示例显示了三个资源组。故障转移资源组包括高可用性的 DNS 应用程序资源，以及由高可用的 DNS 和 Apache Web 服务器共同使用的网络资源。可伸缩资源组仅包括 Apache Web 服务器应用程序实例。注意，资源组在可伸缩和故障转移资源组（实线）之间存在依赖性，而所有的 Apache 应用程序资源都依赖于网络资源 schost-2，这是一个共享地址（虚线）。

图形 3-7 故障转移与可伸缩资源组示例

Graphic

可伸缩服务体系结构

群集联网的主要目标是为数据服务提供可伸缩性。可伸缩性意味着随着提供给服务的负载的增加，在新的节点被添加到群集并运行新的服务器实例的同时，数据服务面对这种增加的工作负载能保持一个不变的响应时间。我们将这样的服务称为可伸缩数据服务。Web 服务是可伸缩数据服务的一个很好的示例。通常，可伸缩数据服务由几个实例组成，每一个示例运行在群集的不同节点上。这些实例在一起，作为来自该服务远程客户机的基准点的一个单独的服务，并实现该服务的功能。例如，我们可能会有一个由几个 httpd 守护程序组成的 Web 服务，并且这些守护程序在不同的节点上运行。任何 httpd 守护程序都服务于一个客户请求。服务于请求的守护程序依赖于 负载平衡策略。对客户机的回复看起来是来自该服务，而不是服务于请求的特定守护程序，从而保留单个服务的外观。

可伸缩服务由以下功能组成：

下图描绘了可伸缩服务的体系结构。

图形 3-8 可伸缩服务体系结构

Graphic

当前不作为全局接口主机的节点（代理节点）与它们的回送接口共享地址。进入到全局接口的软件包被分发到基于可配置负载平衡策略的其它群集节点上。可能的负载平衡策略在下一步说明。

负载平衡策略

负载平衡在响应时间和吞吐量上同时提高了可伸缩服务的性能。

可伸缩数据服务有两类：纯粹服务和粘滞服务。纯粹服务就是它的任何实例都可以对客户机的请求作出响应的服务,粘滞服务是客户机发送请求到相同实例的那种服务,那些请求不被重定向到其他实例。

纯粹服务使用加权的负载平衡策略。在这种负载平衡策略下，客户机请求按缺省方式被均衡地分配到群集内的服务器实例之上。例如，在一个三节点群集中，让我们来假设每个节点的加权为 1。 每个节点将代表该服务对所有客户机请求的 1/3 进行服务。加权可以在任何时候由管理员通过 scrgadm(1M) 命令界面或通过 SunPlex Manager GUI 进行修改。

粘滞服务有两种风格，普通粘滞和通配粘滞。粘滞服务允许多个 TCP 连接上并行的应用程序级会话，来共享状态内内存（应用程序会话状态）。

普通粘滞服务允许客户机在多个并行的 TCP 连接之间共享状态。相对于正在监听单个端口的服务器实例，可以把该客户机说成是"粘滞的"。假定实例保持打开状态并可访问，并且在服务处于联机状态时负载平衡策略不更改，将保证该客户机的所有服务请求都传给相同的服务器实例。

例如，客户机的 Web 浏览器连接到使用三种不同 TCP 连接，连接到端口为 80 的共享 IP 地址，但连接在服务时正在它们之间交换已缓存的会话信息。

粘滞策略的普遍化延伸到在相同实例场景后面交换会话信息的多个可伸缩服务。当这些服务在相同实例场景后面交换会话信息时，相对于在不同端口上监听的相同节点上的多个服务器实例来说，可以说客户机是"粘滞的"。

例如在一个电子商务站点上，顾客使用端口 80 上的普通 HTTP 购买了许多商品并放入到购物车中，但是要切换到端口 443 上的 SSL，以发送安全数据，使用信用卡付款。

通配粘滞服务使用动态分配的端口号，但仍期望客户机请求去往相同的节点。相对于相同的 IP 地址来说，客户机就是端口上的"粘滞通配"。

被动模式 FTP 是这一策略的一个好例子。客户机连接到端口 21 上的 FTP 服务器，并接着被服务器通知须连接回动态端口范围中的收听器端口服务器。此 IP 地址的所有请求都被转发到服务器通过控制信息通知客户的相同节点上。

请注意，对于每个粘滞策略，加权的负载平衡策略都是缺省生效的，从而使客户的最初请求被定向到由负载平衡程序指定的实例。在客户机已经为正运行着实例的节点建立一种亲密关系之后，只要该节点可访问并且负载平衡策略未更改，以后的请求就会定向到此实例。

关于特定的负载平衡策略的补充详细信息在下面进行讨论。

故障返回设置

资源组在一个节点出现故障时转移到另一个节点。出现这种情况时，原始的辅助节点成为新的主节点。故障返回设置指定了在原始主节点恢复联机状态时将进行的操作。选项包括使原始的主节点重新恢复为主节点（故障返回）或仍保留当前的主节点。使用 故障返回资源组特性设置指定需要的选项。

在某些情况下，如果以资源组为主机的原始节点正在重复地发生故障并重新引导，设置故障返回可能会导致资源组减少可用性。

数据服务故障监视器

每个 SunPlex 数据服务都提供一个故障监视器来定期探测数据服务，确定其是否完好。故障监视器检验应用程序守护程序是否在运行并且客户机正在接受服务。基于由探测返回的信息，可以启动一些预定义的操作，比如重新启动守护程序或引起故障转移。

开发新的数据服务

Sun 提供了配置文件和管理方法模板，使您能够在一个群集中让各种应用程序以故障转移或可伸缩服务的方式运行。如果您想使之作为一个故障转移或可伸缩服务来运行的应用程序不是 Sun 当前提供的，则可以使用一个 API 或 DSDL API 来配置该应用程序，使之作为一个故障转移或可伸缩服务运行。

有一套标准可用于确定一个应用程序是否可以成为故障转移服务。特定的标准在 SunPlex 文档中进行了描述，该文档说明您的应用程序可使用的 API。

这里，我们提出一些准则来帮助您了解您的服务是否可受益于可伸缩数据服务体系结构。有关可伸缩服务的更多基本信息，请阅读"可伸缩数据服务"。

满足下列准则的新服务可以利用可伸缩服务。如果现有的服务不完全符合这些准则，则可能需要重写一些部分，使服务符合这些准则。

可伸缩数据服务具有以下特点。首先，这样的服务是由一个或多个服务器实例组

成的。每个实例运行在群集的不同节点上。同一服务的两个或更多实例不能在相同的节点上运行。

其次，如果服务提供外部逻辑数据存储，那么从多个服务器实例对此存储的并行访问必须同步，以避免丢失更新信息或在数据更改时读取数据。请注意，我们讲"外部的"是为了区分存储与内存内的状态，而讲"逻辑的"是因为存储看起来象单独的实体，尽管它本身可能是复制的。此外，这种逻辑数据存储有这样的特性，不论何时任何服务器实例更新该存储，其他实例会立即看到该更新。

SunPlex 系统通过它的群集文件系统和全局原始分区来提供这样一个外部存储器。又比如，假定一项服务将新数据写入外部日志文件，或修改在适当位置的现有数据。当此服务的多个实例运行时，每个都可以访问此外部日志，并且可能会同时访问这一日志。每个实例必须同步其对日志的访问，否则这些实例就会彼此干扰。此服务可以通过 fcntl(2) 和 lockf(3C)来使用普通的 Solaris 文件锁定，从而获取期望的同步。

关于这种存储类型的另一个示例是像高可用 Oracle 或 Oracle Parallel Server 那样的后端数据库。请注意，这种类型的后端数据库服务器使用数据库查询或更新事务提供内置的同步，因此多个服务器实例不需要实现它们自己的同步。

Sun 的 IMAP 服务器是当前并不体现为可伸缩服务的一个服务示例。该服务更新一个存储，但那个存储是专用的，并且当多个 IMAP 实例写入到这一存储时，它们因为更新没有被同步而相互覆盖。IMAP 服务器必须被重写以使并行访问同步。

最后要注意的一点是，实例可能具备一些专用数据，这些数据未与其它实例的数据相连接。在这种情况下，该服务不必关心自己与并行访问是否同步，因为数据是专用的，只有这个实例才可对其进行处理。此时，您必须小心不要在群集文件系统下存储此专用数据，因为它有变为全局访问的可能性。

数据服务 API 和 数据服务服务开发库 API

SunPlex 系统提供以下组件以使应用程序具有高可用性：

《Sun Cluster 3.0 U1 Data Services Installation and Configuration Guide》介绍了如何安装和配置与 SunPlex 系统一起提供的数据服务。《Sun Cluster 3.0 U1 Data Services Developer's Guide》介绍了如何装备其它应用程序以使它们在 Sun Cluster框架下高度可用。

Sun Cluster API 使应用程序开发者能够开发可启动和停止数据服务实例的故障监视器和脚本。有了这些工具，应用程序就可以被装备成为一种故障转移或可伸缩的数据服务。另外，SunPlex系统提供一种"普通的"数据服务，这种服务可以用于快速生成应用程序所需的启动和停止方法，从而使它作为一种故障转移或可伸缩的服务运行。

使用群集互连进行数据服务通信

一群集必须有节点之间的多个网络互连，构成群集互连。群集软件使用多个互连来提高可用性并改善性能。对内部通信（如文件系统数据或可伸缩服务数据），消息是以循环方式在所有可用的互连间条带化的。

群集互连对应用程序也是可用的，从而在节点间进行高可用性通信。例如，一个分布式应用程序的组件可能运行在不同的需要进行通信的节点上。通过使用群集互连而不使用公共传输，这些连接可承受单个链接失败。

要使用群集互连来在节点间进行通信，应用程序必须使用安装群集时配置的专用主机名。例如，如果节点 1 的专用主机名是 clusternode1-priv，请使用此名称在到节点 1 的群集互连上进行通信。 使用此名称打开的 TCP 套接字通过该群集互连进行路由，并且在发生网络故障时可以透明地重新路由。

注意，由于在安装时可以配置专用主机名，所以群集互连可使用此时选择的任何名称。可以使用 scha_privatelink_hostname_node 变量从 scha_cluster_get(3HA) 获取实际的名称。

对于应用程序级别的群集互连使用，在每对节点之间使用单独的一个互连，但如果可能，不同的节点对会使用不同的互连。例如，试想一个运行在三个节点上的应用程序通过群集互连进行通信。在节点 1 和 2 之间的通信可能会在接口 hme0 上进 行，而节点 1 和 3 之间的通信可能会在接口 qfe1 上进行。即，任何两个节点间的应用程序通信仅限于单个互连，而内部群集通信则在所有的互连中条带化。

注意，应用程序共享与内部群集通信的互连，所以对该应用程序可用的带宽取决于用于其他群集通信的带宽。如果出现故障，内部通信会在仍正常运行的互连上循环，而失败的互连上的应用程序连接可切换到一个正常互连上。

两种类型的地址支持群集互连，且专用主机名上的 gethostbyname(3N) 通常会返回两个 IP 地址。第一个地址称为 逻辑成对地址，第二个地址称为逻辑单节点地址。

每对节点各分配了一个逻辑成对地址。此小型逻辑网络支持连接故障转移。每个节点还分配了一个固定的单节点地址。即，clusternode1-priv 的逻辑成对地址因节点而异，而 clusternode1-priv 的逻辑成对地址在各个节点上相同。但是，一个节点对它自身来说并没有成对地址，所以节点 1 上 的 gethostbyname(clusternode1-priv) 仅返回逻辑单节点地址。

注意，在群集互连上接受连接并为安全起见验证 IP 地址的应用程序必须检查 从 gethostbyname 中返回的所有 IP 地址，而不应只检查第一个 IP 地址。

如果需要使 IP 地址在所有点上的应用程序中保持一 致，请配置应用程序，使单节点地址同时绑定到客户端和服务器端，从而使所有的连接看起来是通过单节点地址出入。

资源、资源组和资源类型

数据服务利用了几种类型的资源：诸如 Apache Web Server 或 iPlanetWeb Server 之类的应用程序利用它们所依赖的网络地址（逻辑主机名和共享地址）。应用程序和网络资源组成由 RGM 管理的一个基本单元。

数据服务是资源类型。例如，Sun Cluster HA for Oracle 是资源类型 SUNW.oracle，而 Sun Cluster HA for Apache是资源类型 SUNW.apache。

资源就是群集范围内定义的资源类型的实例化。有数种已定义的资源类型。

网络资源或者是 SUNW.LogicalHostname 资源类型，或者是 SUNW.SharedAddress 资源类型。这两种资源类型已由 Sun Cluster 软件预注册。

SUNW.HAStorage 资源类型用于同步化资源和资源所依赖的磁盘设备组的启动。它可确保在数据服务启动时，到群集文件系统安装点、全局设备和设备组名称的路径可用。

RGM 管理的资源被放入称作资源组的组中，因此它们可以作为一个单元管理。如果故障转移或切换在资源组上启动，那么资源组就作为单元移植。

注意：

当您使一个包含应用程序资源的资源组联机时，应用程序便启动。数据服务启动方法会一直等待，直到应用程序在成功退出前启动并运行。决定何时应用程序启动并运行的方法，与数据服务故障监视器决定数据服务是否正在服务于客户机所采用的方法相同。有关此过程的详细信息，请参见《Sun Cluster 3.0 U1 Data Services Installation and Configuration Guide》。

资源和资源组状态与设置

管理员在资源和资源组上应用静态设置。这些设置只能通过管理员操作来进行更改。RGM 在各种动态"状态"之间移动资源组。下表列出了这些设置和状态。

资源与资源组特性

您可以为您的 SunPlex 数据服务配置资源和资源组的特性值。标准特性对于所有数据服务都是通用的。扩展特性是每个服务的特定特性。一些标准和扩展特性已配置为缺省值，因此您不必去修改它们。其他特性作为创建和配置资源进程的一部分，需要进行设置。每个数据服务的文档都指定了哪些资源特性可以进行设置，以及如何设置这些特性。

标准特性用于配置那些通常独立于任何特定数据服务的资源和资源组特性。标准特性集的说明可见于《Sun Cluster 3.0 U1 Data Services Installation and Configuration Guide》的附录。

扩展特性提供应用程序二进制文件和配置文件的位置等信息。当您配置数据服务时，就修改了扩展特性。扩展特性集在《Sun Cluster 3.0 U1 Data Services Installation and Configuration Guide》中有关数据服务的单独的章节中说明。

公共网络管理 (PNM) 和网络适配器故障转移 (NAFO)

客户机通过公共网络向群集提出数据请求。每个群集节点通过公共网络适配器至少连接到一个公共网络。

Sun Cluster 公共网络管理 (PNM) 软件提供了基本的机制来监视公共网络适配器，并在检测到故障时将 IP 地址从一个适配器故障转移到另一个适配器。每个群集节点有它自己的 PNM 配置，该配置可以与其他群集节点上的不同。

公共网络适配器被编入到 Network Adapter Failover 组（NAFO 组）。每个 NAFO 组有一个或多个公共网络适配器。而在任何时候只有一个适配器对给定的 NAFO 组是活动的，在同一组中的更多适配器作为备份适配器使用，活动适配器上的 PNM 守护程序一旦检测到故障，在适配器故障转移期间就使用这些备份适配器。故障转移使与活动适配器相关联的 IP 地址被转移到备份适配器上，从而维持该节点的公共网络连通性。由于故障转移发生在适配器接口级，像 TCP 这样的更高级别的连接则不受影响，仅在故障转移期间有短暂的瞬时延迟。

注意：

由于 TCP 的拥塞恢复特性，TCP 端点可以在成功的故障转移后经受更长的延迟，同时一些段可能会在故障转移期间丢失，激活了 TCP 中的拥塞控制机制。

NAFO 组为逻辑主机名和共享地址资源提供了构件。<command>scrgadm(1M) 命令在必要时自动为您创建 NAFO 组。您也可以独立于逻辑主机名和共享地址资源来创建 NAFO 组，以监视群集节点的公共网络连通性。节点上相同的 NAFO 组可以拥有任意数目的逻辑主机名或共享地址资源。有关逻辑主机名和共享地址的详细信息，请参见《Sun Cluster 3.0 U1 Data Services Installation and Configuration Guide》。

注意：

NAFO 机制的设计着意于检测和屏蔽适配器故障。该设计并不旨在使用 ifconfig(1M) 从管理员那里恢复，以删除一个逻辑（或共享的）IP 地址。Sun Cluster 软件将逻辑和共享 IP 地址视为由 RGM 管理的资源。对于管理员来说，添加或删除 IP 地址的正确方法是使用 scrgadm(1M) 修改包含资源的资源组。

PNM 故障检测和故障转移过程

PNM 有规律地检查活动适配器的包计数，并假定运行良好的适配器的包计数会因通过适配器的正常网络流量而变化。如果一段时间包计数没有变化，那么 PNM 就进入一个 ping 序列，它加强了该通过活动适配器的流量。PNM 在每个序列结束时检查包计数的任何变化，并且如果在 ping 序列重复几次后包计数仍保持不变，就宣告适配器出现故障。这些事件触发了备份适配器的故障转移，只要有一个备份适配器可用，就转移到它。

输入和输出包计数由 PNM 监视，因此当两者之一或两者在一段时间内保持不变，则启动 ping 序列。

ping 序列由对 ALL_ROUTER 多址广播地址 (224.0.0.2)、ALL_HOST 多址广播地址 (224.0.0.1) 和本地子网广播地址的 ping 组成。

Ping 是以最低成本优先的方式构建的，因此如果有一个较低成本的 ping 可以成功运行，就不会运行较高成本的 ping。而且，ping 只作为在适配器上产生流量的一种方法使用。它们的退出状态不会影响对适配器功能或故障的判定。

在这一算法中有四个可以微调的参数：inactive_time、ping_timeout、repeat_test 和 slow_network。这些参数在故障检测的速度和正确性之间提供了一种可调整的平衡。有关参数及如何更改它们的详细信息，请参见《Sun Cluster 3.0 U1 系统管理指南》中关于更改公共网络参数的步骤。

在 NAFO 组的活动适配器上检测到故障后，如果没有备份适配器可用，该组就被宣告关闭，同时继续对其所有备份适配器的测试。然而，如果有备份适配器可用，就会进行故障转移，切换到该适配器。当故障活动适配器被关闭并且不可查明时，逻辑地址和它们相关的标志被"转移"到备份适配器上。

一旦 IP 地址的故障转移成功完成之后，就会发送未经请求的 ARP 广播。从而保持与远程客户机的连通性。