test

Sun Cluster 概念指南（适用于 Solaris OS）

第 3 章 关键概念 – 管理和应用程序开发

本章说明与 SunPlex 系统的软件组件相关的关键概念。包括下列主题：

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

管理接口

可以选择如何通过若干用户界面来安装、配置和管理 SunPlex 系统。通过 SunPlex Manager 图形用户界面 (GUI) 或文档化的命令行界面都可以完成系统管理任务。在命令行界面的顶部是若干实用程序（如 scinstall 和 scsetup），可以简化选定的安装和配置任务。SunPlex 系统还有一个模块，作为 Sun Management Center（可向特定群集任务提供 GUI）的一部分来运行。此模块只能在基于 SPARC 的群集中使用。有关管理接口的完整说明，请参阅《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“管理工具”。

群集时间

群集中的所有节点之间的时间必须同步。您是否将群集节点与任何外部时间源同步对于群集操作并不重要。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 软件安装指南（适用于 Solaris OS）》中的“安装和配置 Sun Cluster 软件”。

或者您也可以在群集之外设置一个或多个 NTP 服务器，并更改 ntp.conf 文件使之能反映出这一配置。

正常运行时，绝不需要调整群集的时间。不过，如果在安装 Solaris 操作环境时未正确设置时间并要更改时间，请参见《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“管理群集”中的步骤来进行更改。

高可用性框架

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

下表显示了各种 SunPlex 组件故障（包括硬件故障和软件故障），以及高可用性框架中内置的各种恢复。

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

有故障的群集组件 

软件恢复 

硬件恢复 

数据服务 

HA API，HA 框架 

N/A 

公共网络适配器 

IP Network Multipathing 

多个公共网络适配卡 

群集文件系统 

主要和辅助复制 

多主机设备 

镜像多主机设备 

卷管理（Solaris Volume Manager 和 VERITAS Volume Manager，只能在基于 SPARC 的群集中使用） 

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

全局设备 

主要和辅助复制 

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

专用网 

HA 传输软件 

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

节点 

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

多个节点 

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

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

群集成员监视器

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

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

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

与 Sun Cluster 软件以前的发行版不同，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

出现应急状态之后，节点可能重新引导并尝试重新加入群集；或者，如果群集是由基于 SPARC 的系统组成的，则停留在 OpenBootTM PROM (OBP) 提示符处。所采取的操作取决于 auto-boot? 参数的设置。可以在 OpenBoot PROM ok 提示符处使用eeprom(1M) 设置 auto-boot?。

群集配置系统信息库 (CCR)

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

Caution – Caution –

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

CCR 靠 CMM 来保证群集只有在仲裁建立后才能运行。CCR 负责跨群集验证数据的一致性，需要时执行恢复，并为数据更新提供工具。

全局设备

SunPlex 系统使用全局设备实现群集范围内的高可用性访问，使您可以从任一节点对群集中的任一设备进行访问，而不用考虑设备的实际连接位置。在通常情况下，如果某个节点在提供对全局设备的访问时出现故障，则 Sun Cluster 软件会自动找到该设备的其他路径并将访问重定向到该路径。SunPlex 全局设备包括磁盘、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 软件的控制。首先，在多主机磁盘上创建卷管理器磁盘组 — Solaris Volume Manager 磁盘集或 VERITAS Volume Manager 磁盘组（只能在基于 SPARC 的系统中使用）。然后将卷管理器磁盘组注册为磁盘设备组。磁盘设备组是一种全局设备。此外，Sun Cluster 软件还为群集中的每个磁盘和磁带设备创建一个原始磁盘设备组。然而，这些群集设备组将一直处于脱机状态，直到您将其作为全局设备访问为止。

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

注意 –

磁盘设备组独立于资源组。一个节点可以控制资源组（代表一组数据服务进程），而另一个节可以控制正被数据服务访问的磁盘组。不过最好的做法是，让存储特定应用程序数据的磁盘设备组和包含此应用程序资源（应用程序守护程序）的资源组保持在同一节点上。有关磁盘设备组和资源组之间的关联的更多信息，请参阅《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》中的“资源组和磁盘设备组之间的关系”。

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

磁盘设备组失效转移

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

图 3–1 磁盘设备组失效转移

说明：上文介绍了此图形。

多端口磁盘设备组

本部分介绍了使您能够在多端口磁盘配置中协调性能和可用性的磁盘设备组特性。Sun Cluster 软件提供了两个用于进行多端口磁盘配置的特性：preferenced 和 numsecondaries 。您可以使用 preferenced 特性控制发生失效转移时节点尝试取得控制的顺序。使用 numsecondaries 特性设置设备组所需的辅助节点数目。

当主节点出现故障，而又没有适当的辅助节点能够升级为主节点时，则认为高可用服务停止。如果服务发生失效转移，且 preferenced 特性为 true，则节点将按照节点列表中的顺序选择一个辅助节点。设置的节点列表定义了节点尝试取得主控制的顺序，或从空闲节点变为辅助节点的顺序。您可以使用scsetup(1M) 实用程序动态更改设备服务的首选项。与相应的服务供应商关联的首选项（例如，全局文件系统）将成为该设备服务的首选项。

在正常操作过程中，主节点将对辅助节点进行节点检查。在多端口磁盘配置中，对每个辅助节点的检查会导致群集性能下降并会额外占用内存。实现空闲节点支持可以减小节点检查造成的性能下降和内存的额外占用。缺省情况下，磁盘设备组具有一个主节点和一个辅助节点。其余的可用供应商节点将以空闲状态联机。如果发生了失效转移，辅助节点将成为主节点，而节点列表中优先级最高的节点将成为辅助节点。

所需辅助节点的数目可以设置为一到设备组中非主供应商有效节点的数目之间的任意整数。

注意 –

如果正在使用 Solaris 卷管理器，则必须先创建磁盘设备组，然后将numsecondaries 特性设置为缺省值以外的数目。

设备服务缺省的所需辅助节点数为一。除非有效的非主供应商数目小于所需数目，否则由复本框架维护的实际辅助供应商数目就是所需数目。如果正在配置中增加或删除节点，您可能希望更改 numsecondaries 特性并重新检查节点列表。维护节点列表和所需辅助节点数目可以防止配置的辅助节点数目和框架实际允许的数目之间发生冲突。对于 Solaris Volume Manager 设备组，请使用metaset(1M) 命令；或者，如果使用的是 Veritas Volume Manager，请将用于 VxVM 磁盘设备组的scconf(1M) 命令与 preferenced 和 numsecondaries 特性设置一起使用来管理在配置中添加和删除节点。有关更改磁盘设备组特性的过程信息，请参阅《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“群集文件系统管理概述”。

全局名称空间

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

对于 Solaris Volume Manager，卷管理器名称空间通常位于 /dev/md/diskset/dsk（和 rdsk）目录中。对于 Veritas VxVM，卷管理器名称空间位于 /dev/vx/dsk/ disk-group 和 /dev/vx/rdsk/ disk-group 目录中。这些名称空间分别由整个群集中引入的各 Solaris Volume Manager磁盘集和各 VxVM 磁盘组的目录组成。每一个这样的目录中都有此磁盘集或磁盘组中每个元设备或卷的设备节点。

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

全局名称空间的优点有：

本地和全局名称空间示例

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

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

组件/路径 

本地节点名称空间 

全局名称空间 

Solaris 逻辑名称 

/dev/dsk/c0t0d0s0

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

DID 名称 

/dev/did/dsk/d0s0

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

Solaris Volume Manager 

/dev/md/diskset/dsk/d0

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

SPARC: VERITAS Volume Manager 

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

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

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

群集文件系统

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

在全局设备上，您可以使用 mount -g 进行全局装载或使用 mount 进行本地装载。

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

群集文件系统装载在所有的群集成员上。不可以在群集成员的子集上装载群集文件系统。

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

使用群集文件系统

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

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

与一般的文件系统相同，您可以通过以下两种方式装载群集文件系统：

注意 –

Sun Cluster 软件并不强制要求在群集文件系统中使用一种命名策略，所以您可以在同一目录下（如 /global/disk-device-group）为所有群集文件系统创建一个装载点，从而简化管理。有关更多信息，请参见《Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition)》和《Sun Cluster 系统管理指南（适用于 Solaris OS）》。

HAStoragePlus 资源类型

HAStoragePlus 资源类型设计的目的是使诸如 UFS 和 VxFS 之类的非全局文件系统配置具有高可用性。使用 HAStoragePlus 可将本地文件系统集成到 Sun Cluster 环境中，并使该文件系统具有高可用性。HAStoragePlus 提供了诸如校验、装载和强制卸载之类附加的文件系统功能，使得 Sun Cluster 能对本地文件系统进行失效转移。为了进行失效转移，本地文件系统必须驻留在启用了相似性切换功能的全局磁盘组中。

有关如何使用 HAStoragePlus 资源类型的信息，请参见《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》中的“启用具有高可用性的本地文件系统”。

也可以使用 HAStoragePlus 使资源的启动和这些资源所依赖的磁盘设备组的启动同步。有关详细信息，请参见资源、资源组和资源类型。

Syncdir 装载选项

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

如果使用的是基于 SPARC 的群集，Veritas VxFS 没有与 UFS 的 syncdir 装载选项等价的装载选项。未指定 syncdir 装载选项时，VxFS 的行为与 UFS 的行为相同。

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

磁盘路径监视

Sun Cluster 软件的当前版本支持磁盘路径监视 (DPM)。本部分介绍了有关 DPM、DPM 守护程序和用来监视磁盘路径的管理工具的概念信息。有关如何监视、取消监视和检查磁盘路径状况的过程信息，请参考《Sun Cluster 系统管理指南（适用于 Solaris OS）》。

注意 –

运行 Sun Cluster 3.1 4/04 软件之前发行的版本的节点不支持 DPM。进行轮询升级时，请不要使用 DPM 命令。所有节点均升级后，必须使这些节点处于联机状态以便使用 DPM 命令。

概述

通过监视辅助磁盘路径可用性，DPM 总体上提高了失效转移和切换的可靠性。在切换资源之前，使用 scdpm 命令验证该资源所使用的磁盘路径的可用性。由 scdpm 命令提供的选项使您能够监视单个节点或群集中所有节点的磁盘路径。有关命令行选项的详细信息，请参阅 scdpm(1M) 手册页。

DPM 组件是通过 SUNWscu 软件包安装的。SUNWscu 软件包是通过 Sun Cluster 标准安装过程安装的。有关安装界面的详细信息，请参见 scinstall (1M) 手册页。下表说明 DPM 组件的缺省安装位置。

\u4f4d\u7f6e 

组件 

守护程序 

/usr/cluster/lib/sc/scdpmd

命令行界面 

/usr/cluster/bin/scdpm

共享库 

/user/cluster/lib/libscdpm.so

守护程序状况文件（运行时创建） 

/var/run/cluster/scdpm.status

每个节点上都运行一个多线程 DPM 守护程序。当节点引导时，rc.d 脚本将启动 DPM 守护程序 (scdpmd)。出现问题时，守护程序将由 pmfd 管理并自动重启。以下列表说明 scdpmd 如何处理初始启动。

注意 –

启动时，每个磁盘路径的状况都被初始化为 UNKNOWN。

  1. DPM 守护程序从早期的状况文件或 CCR 数据库中收集磁盘路径和节点名称信息。有关 CCR 的详细信息，请参见群集配置系统信息库 (CCR)。启动 DPM 守护程序后，您可以强制该守护程序从指定文件名读取受监视的磁盘列表。

  2. DPM 守护程序对通信接口进行初始化，以回应来自守护程序外部的组件（如命令行界面）的请求。

  3. 每隔 10 分钟，DPM 守护程序会使用 scsi_inquiry 命令对监视列表中的各个磁盘路径执行一次强制回应操作。每个条目均被锁定，以防止对正在进行修改的内容进行通信接口访问。

  4. DPM 守护程序将通知 Sun Cluster Event Framework，并通过 UNIX syslogd (1M) 机制记录该路径的新状况。

注意 –

pmfd (1M) 将报告与守护程序相关的所有错误。如果成功，API 的所有函数返回 0，否则返回 -1。

DPM 守护程序监视借助多路径驱动程序（如 MPxIO、HDLM 和 PowerPath）而可视的逻辑路径的可用性。由这些驱动程序管理的单独物理路径不受到监视，因为多路径驱动程序掩盖了 DPM 守护程序中的失败。

监视磁盘路径

本部分介绍了用来监视群集中磁盘路径的两种方法。第一种方法由 scdpm 命令提供。使用此命令监视、取消监视或显示群集中磁盘路径的状况。此命令也用于打印故障磁盘列表和监视文件的磁盘路径。

监视群集中磁盘路径的第二种方法是由 SunPlex Manager 图形用户界面 (GUI) 提供的。SunPlex Manager 提供了群集中受监视磁盘路径的拓扑视图。该视图每 10 分钟更新一次，以提供有关失败的强制回应数目的信息。使用 SunPlex Manager GUI 提供的信息和 scdpm(1M) 命令来管理磁盘路径。有关 SunPlex Manager 的信息，请参阅《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“使用图形用户界面管理 Sun Cluster”。

使用 scdpm 命令监视磁盘路径

scdpm(1M) 命令提供了使您可以执行以下任务的 DPM 管理命令：

使用 scdpm(1M) 命令和任何活动节点的磁盘路径参数对群集执行 DPM 管理任务。磁盘路径参数通常由一个节点名称和一个磁盘名称组成。如果不需要节点名称，它将缺省为 all（如果未指定任何节点名称）。下表说明了磁盘路径的命名惯例。

注意 –

全局磁盘路径名称在整个群集中是一致的，因此，建议使用全局磁盘路径名称。UNIX 磁盘路径名称在整个群集中不一致。一个磁盘的 UNIX 磁盘路径会根据群集节点的不同而有所差别。一个节点上的磁盘路径可能是 c1t0d0，而另一个节点上的磁盘路径则可能是 c2t0d0。如果使用的是 UNIX 磁盘路径名称，请在发出 DPM 命令前使用 scdidadm -L 命令将 UNIX 磁盘路径名称映射为全局磁盘路径名称。请参阅 scdidadm( 1M) 手册页。

表 3–3 磁盘路径名称样例

名称类型 

样例磁盘路径名 

说明 

全局磁盘路径 

schost-1:/dev/did/dsk/d1

schost-1 节点上的磁盘路径 d1

all:d1

群集中所有节点上的磁盘路径 d1

UNIX 磁盘路径 

schost-1:/dev/rdsk/c0t0d0s0

schost-1 节点上的磁盘路径 c0t0d0s0

schost-1:all

schost-1 节点上的所有磁盘路径

所有磁盘路径 

all:all

群集中所有节点上的所有磁盘路径 

使用 SunPlex Manager 监视磁盘路径

SunPlex Manager 使您能够执行以下基本的 DPM 管理任务：

有关如何使用 SunPlex Manager 执行磁盘路径管理的过程信息，请参见 SunPlex Manager 联机帮助。

法定和法定设备

本节包含以下主题：

注意 –

要获得 Sun Cluster 软件支持作为法定设备的特定设备的列表，请与 Sun 服务提供商联系。

由于群集节点共享数据和资源，因此决不能将一个群集分割为多个同时处于活动状态的独立分区，因为多个活动分区可能会导致数据损坏。群集成员监视器 (CMM) 和法定算法可保证：即使群集互连已进行分区，同一群集在任何时刻最多有一个实例可运行。

有关 CMM 的更多信息，请参见《Sun Cluster 概述（适用于 Solaris OS）》中的“群集成员”。

群集分区会引起两类问题：

当群集因节点间的群集互连丢失而分割成多个子群集时，即会出现记忆分裂。由于一个分区中的节点无法与其他分区中的节点进行通信，因此每个分区均认为自身为仅有的分区。

当群集在关闭后使用比关闭时旧的群集配置数据重新启动时，即会出现失忆。在节点上启动群集，而此节点不在最后运行的群集分区中时会发生此问题。

Sun Cluster 软件可以通过以下方法避免群集分割和失忆：

获得多数选票的分区达到法定数目，因此允许其运行。此多数选票机制可避免在一个群集中配置两个以上节点时发生群集分割和失忆。但是，在一个群集中配置两个以上节点时，只计算节点选票是不够的。在双节点群集中，多数为二。如果一个此类双节点群集分为多个分区，则每个分区均需要外部选票才能达到法定数目。此外部选票由法定设备提供。

关于法定选票计数

使用 scstat -q 命令可以确定以下信息：

有关此命令的更多信息，请参见 scstat(1M)。

节点和法定设备均可为群集投选票以达到法定数目。

节点投选票取决于节点的状态：

法定设备将基于连接至此设备的选票数目投选票。配置法定设备时，Sun Cluster 软件将法定设备的选票计数指定为 N-1，其中 N 为已连接至法定设备的选票数目。例如，连接到选票计数不为零的两个节点的法定设备具有的法定计数为一（二减一）。

如果以下两个条件之一为真，法定设备将投选票：

您可以在安装群集的过程中配置法定设备，也可以稍后按照《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“管理定额”中说明的步骤进行配置。

关于故障防护

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

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

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

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 磁盘，故障快速防护机制的工作方式都是一样的。

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

出现应急状态之后，节点可能重新引导并尝试重新加入群集；或者，如果群集是由基于 SPARC 的系统组成的，则停留在 OpenBootTM PROM (OBP) 提示符处。所采取的操作取决于 auto-boot? 参数的设置。您可以在基于 SPARC 的群集中的 OpenBoot PROM ok 提示符处使用eeprom(1M) 来设置 auto-boot?，也可以在基于 x86 的群集中，在 BIOS 引导之后选择运行 SCSI 实用程序来设置 auto-boot?。

关于法定配置

以下内容包含了有关法定配置的一些实际情况：

有关应避免的法定配置的示例，请参见错误的法定配置。有关建议的法定配置的示例，请参见建议的法定配置。

遵守法定设备要求

您必须遵守以下要求。否则，可能影响群集的可用性。

有关应避免的法定配置的示例，请参见错误的法定配置。有关建议的法定配置的示例，请参见建议的法定配置。

遵守法定设备最佳配置

使用以下信息可为拓扑评估最佳法定配置：

有关应避免的法定配置的示例，请参见错误的法定配置。有关建议的法定配置的示例，请参见建议的法定配置。

建议的法定配置

有关应避免的法定配置的示例，请参见错误的法定配置。

双节点配置中的法定数目

组成双节点群集需要两个法定选票。这两个选票可以来自于两个群集节点，或者只来自一个节点和一个仲裁设备。

图 3–2 双节点配置

说明：说明节点 A 和节点 B 有一个连接至两个节点的法定设备。

双节点以上配置中的法定数目

配置没有法定设备的多于两个节点的群集是有效的。不过，如果这样做，则无法在群集中没有大多数节点时启动群集。

说明：配置 1：节点 A-D。A/B 连接至 (->) QD1。C/D -> QD2。配置 2：节点 A-C。A/C -> QD1。B/C -> QD2。配置 3：节点 A-C -> 一个 QD。

非典型法定配置

图 3–3 假定正在节点 A 和节点 B 上运行任务紧要的应用程序（例如 Oracle 数据库）。如果节点 A 和节点 B 不可用并且无法访问共享数据，您可能需要关闭整个群集。否则，此配置不是最佳配置，因为它不能提供高可用性。

有关与此例外情况相关的最佳配置的信息，请参见遵守法定设备最佳配置。

图 3–3 非典型配置

说明：节点 A-D。节点 A/B 连接至 QD1-4。节点 C 连接至 QD4。节点 D 连接至 QD4。全部选票 = 10。法定数目所需选票 = 6。

错误的法定配置

有关建议的法定配置的示例，请参见建议的法定配置。

说明：配置 1：节点 A/B 连接至 QD1/2。配置 2：节点 A-D。A/B 连接至 QD1/2。配置 3：节点 A-C。A/B 连接至 QD1/2。C 连接至 QD2。

数据服务

术语数据服务指被配置为在群集而不是在单一服务器上运行的第三方应用程序，如 Sun Java System Web Server（以前的 Sun Java System Web Server），以及基于 SPARC 的群集上的 Oracle。数据服务包括应用程序、专用的 Sun Cluster 配置文件，以及控制下列应用程序操作的 Sun Cluster 管理方法。

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

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

说明：以下内容说明了该图形。

在单服务器模型中，您可以将应用程序配置为通过特定的公共网络接口（一个主机名）访问服务器。主机名与物理服务器有关。

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

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

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

网络资源初始与一个节点（主节点）相关联。如果主节点发生故障，网络资源和应用程序资源将失效转移至另一个群集节点（辅助节点）上。进行网络资源故障转移后，经过短暂延迟，应用程序资源就可以在辅助节点上继续正常运行。

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

图 3–5 固定主机名与逻辑主机名

说明：上文介绍了此图形。

共享地址初始与一个节点相关联。这个节点被称为全局接口节点。共享地址被用作群集的单个网络接口。这就是全局接口。

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

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

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

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

说明：上文介绍了此图形。

数据服务方法

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

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

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

失效转移数据服务

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

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

可伸缩数据服务

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

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

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

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

注意 –

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

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

图 3–7 SPARC: 失效转移和可伸缩资源组示例

说明：上文介绍了此图形。

负载平衡策略

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

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

纯粹服务使用加权的负载平衡策略。在这种负载平衡策略下，客户机请求按缺省方式被均衡地分配到群集内的服务器实例之上。例如，在一个三节点群集中，让我们来假设每个节点的加权为 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 文件锁定，从而如愿实现同步。

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

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

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

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

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

《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》介绍了如何安装和配置随 SunPlex 系统提供的数据服务。Sun Cluster 3.1 9/04 Software Collection for Solaris OS（SPARC 平台版）介绍了如何用工具装备其他应用程序使其在 Sun Cluster 框架下具有高度可用性。

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

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

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

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

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

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

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

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

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

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

请注意，通过群集互连接受连接、然后出于安全原因检验 IP 地址的应用程序，必须检查 gethostbyname 返回的所有 IP 地址，而不仅仅检查第一个 IP 地址。

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

资源、资源组和资源类型

数据服务利用了几种类型的资源：Sun Java System Web Server（以前的 Sun Java System Web Server）或 Apache Web Server 等应用程序使用这些应用程序依赖的网络地址（逻辑主机名和共享地址）。应用程序和网络资源组成由 RGM 管理的一个基本单元。

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

注意 –

资源类型 SUNW.oracle-server 仅在基于 SPARC 的群集中使用。

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

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

SUNW.HAStorage 和 HAStoragePlus 资源类型用于使资源的启动和这些资源所依赖的磁盘设备组的启动同步。它可确保在数据服务启动时，到群集文件系统装载点、全局设备和设备组名称的路径可用。有关详细信息，请参见《Data Services Installation and Configuration Guide》中的“Synchronizing the Startups Between Resource Groups and Disk Device Groups”。（HAStoragePlus 资源类型在 Sun Cluster 3.0 5/02 中就已可用并且增加了另一功能，从而使本地文件系统具有高可用性。有关此功能的详细信息，请参阅HAStoragePlus 资源类型。）

RGM 所管理的资源被放入一个称作资源组的组中，这样就可将它们作为一个单元来进行管理。如果对资源组启动失效转移或切换，那么该资源组就将作为单元移植。

注意 –

当您使一个包含应用程序资源的资源组联机时，应用程序便启动。数据服务启动方法会一直等待，直到应用程序在成功退出前启动并运行。决定何时应用程序启动并运行的方法，与数据服务故障监视器决定数据服务是否正在服务于客户机所采用的方法相同。有关此过程的更多信息，请参阅《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》。

Resource Group Manager (RGM)

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

RGM 对资源和资源组进行操作。RGM 操作导致资源和资源组在联机和脱机状态之间进行转换。有关可应用于资源和资源组的状态和设置的完整说明，请参阅资源和资源组状态和设置一节。有关如何启动 RGM 控制下的资源管理项目的信息，请参见资源、资源组和资源类型。

资源和资源组状态和设置

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

资源和资源组特性

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

标准特性用于配置那些通常独立于任何特定数据服务的资源和资源组特性。有关标准特性集，请参见《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》中的“标准特性”。

RGM 扩展特性提供应用程序二进制文件和配置文件的位置等信息。当您配置数据服务时，就修改了扩展特性。扩展特性集在有关数据服务的单独的指南中进行了说明。

数据服务项目配置

当通过 RGM 联机时，数据服务可以配置为在 Solaris 项目名称下启动。该配置将 RGM 管理的资源或资源组与 Solaris 项目 ID 相关联。从资源或资源组到项目 ID 的映射使您能够使用 Solaris 环境中提供的高级控制来管理群集中的工作量和消耗量。

注意 –

只有运行具有 Solaris 9 的 Sun Cluster 软件的当前版本时，才能执行此配置。

通过在群集环境中使用 Solaris 管理功能，可以确保大多数重要的应用程序在与其他应用程序共享一个节点时具有优先权。如果采用统一服务，或者由于应用程序发生失效转移，则多个应用程序可能共享一个节点。使用此处介绍的管理功能，可以防止其他优先级较低的应用程序过多地消耗系统供应（如 CPU 时间），从而提高重要应用程序的可用性。

注意 –

有关此功能的 Solaris 文档介绍了 CPU 时间、进程、任务和类似的组件（如资源）。同时，Sun Cluster 文档采用术语“资源”来说明由 RGM 控制的实体。以下部分将采用术语“资源”指代由 RGM 控制的 Sun Cluster 实体，并采用术语“供应”指代 CPU 时间、进程和任务。

本部分介绍了将数据服务配置为在指定的 Solaris 9 project(4) 中启动的进程的概念说明。本部分还介绍了若干失效转移情况，以及规划使用 Solaris 环境提供的管理功能的建议。有关管理功能的详细概念文档和过程文档，请参见 Solaris 9 System Administrator Collection 中的《System Administration Guide: Resource Management and Network Services》。

当在群集中将资源和资源组配置为使用 Solaris 管理功能时，请考虑使用以下高级进程：

  1. 将应用程序配置为资源的一部分。

  2. 将资源配置为资源组的一部分。

  3. 启用资源组中的资源。

  4. 使资源组处于管理状态。

  5. 为资源组创建一个 Solaris 项目。

  6. 配置标准特性，使资源组名称与步骤 5 中创建的项目相关联。

  7. 使资源组联机。

要配置标准的 Resource_project_name 或 RG_project_name 特性，以便将 Solaris 项目 ID 与资源或资源组相关联，请使用 -y 选项和scrgadm(1M) 命令。将特性值设置为资源或资源组。有关特性定义，请参阅《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》中的“标准特性”。有关特性的说明，请参阅 r_properties(5) 和 rg_properties(5)。

指定的项目名称必须存在于项目数据库 ( /etc/project) 中，而 root 用户必须被配置为此命名项目的成员。有关项目名称数据库的概念信息，请参见 Solaris 9 System Administrator Collection 中《System Administration Guide: Resource Management and Network Services》中的 “Projects and Tasks”。有关项目文件语法的说明，请参见 project( 4)。

当 RGM 将资源或资源组联机时，它将启动项目名称下的相关进程。

注意 –

用户可以随时将资源或资源组与项目相关联。但是，必须使用 RGM 将资源或资源组脱机，然后再联机，新的项目名称才有效。

通过启动项目名称下的资源和资源组，您可以配置以下功能，以便在群集中管理系统供应。

确定项目配置的要求

在 Sun Cluster 环境中配置数据服务以使用由 Solaris 提供的控制之前，必须确定要如何在切换或失效转移过程中控制和跟踪资源。配置新项目之前请考虑标识群集中的依赖性。例如，资源和资源组依赖于磁盘设备组。使用通过 scrgadm (1M) 配置的 nodelist、failback 、maximum_primaries 和 desired_primaries 资源组特性来标识资源组的节点列表优先级。有关资源组和磁盘设备组之间的节点列表依赖性的简要讨论，请参阅《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》中的“资源组和磁盘设备组之间的关系”。有关特性的详细说明，请参见 rg_properties (5)。

使用通过 scrgadm( 1M) 和 scsetup( 1M) 配置的 preferenced 和 failback 特性来确定磁盘设备组节点列表的优先级。有关过程信息，请参见《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“管理磁盘设备组”中的“如何更改磁盘设备特性”。有关节点配置以及失效转移和可伸缩数据服务方式的概念信息，请参见SunPlex 系统硬件和软件组件。

如果要对所有的群集节点进行同样的配置，则会对主节点和辅助节点强制执行同样的使用限制。对于所有节点配置文件中的所有应用程序，其项目配置参数不必相互一致。与应用程序相关联的所有项目必须至少可以在该应用程序的所有潜在主控主机上由项目数据库访问。假设应用程序 1 由 phys-schost-1 控制，但是可以切换或失效转移到 phys-schost-2 或 phys-schost-3。那么必须在这三个节点 (phys-schost-1 、phys-schost-2 和 phys-schost-3) 上都能访问与应用程序 1 关联的项目。

注意 –

项目数据库信息可以是本地 /etc/project 数据库文件，也可以存储在 NIS 映射或 LDAP 目录服务中。

Solaris 环境允许对使用参数进行灵活配置，而且 Sun Cluster 的限制很少。配置选项取决于站点的需求。在对系统进行配置之前，请考虑以下部分中的一般原则。

设置每个进程的虚拟内存限制

设置 process.max-address-space 控制，以便限制以每个进程为基础的虚拟内存。有关设置 process.max-address-space 值的详细信息，请参见 rctladm( 1M)。

当对 Sun Cluster 使用管理控制时，请正确配置内存限制，以防止不必要的应用程序失效转移和应用程序的“乒乓”效果。通常情况下：

失效转移情况

可以对管理参数进行配置，以便项目配置 (/etc/project) 在正常的群集操作中和切换或失效转移情况下进行分配。

以下部分是示例情况。

在群集环境中，应用程序配置为资源的一部分，而资源配置为资源组 (RG) 的一部分。当发生失效转移时，资源组及其关联的应用程序将进行失效转移，切换到另一个节点。以下示例中没有明确显示资源。假设每个资源仅有一个应用程序。

注意 –

按照 RGM 中设置的首选节点列表顺序进行失效转移。

以下示例的约束包括：

虽然分配的份额数相同，但是在失效转移后，分配给每个应用程序的 CPU 时间的比例将发生变化。此比例取决于节点上运行的应用程序数，以及分配给每个活动的应用程序的份额数。

在以上情况下，假设采用了以下配置。

具有两个应用程序的双节点群集

您可以对双节点群集上的两个应用程序进行配置，以确保每个物理主机（phys-schost-1 和 phys-schost-2）都充当一个应用程序的缺省主控主机。每个物理主机都充当另一个物理主机的辅助节点。两个节点上的项目数据库文件中必须表示与应用程序 1 和应用程序 2 关联的所有项目。当群集正常运行时，每个应用程序均运行在各自的缺省主控主机上，在其中管理设备为其分配了所有的 CPU 时间。

发生失效转移或切换后，两个应用程序均运行在一个节点上，在该节点上，应用程序会分配到配置文件中所指定的相应份额。例如，/etc/project 文件中的相应条目指定应用程序 1 分配到 4 份份额，应用程序 2 分配到 1 份份额。 

Prj_1:100:project for App-1:root::project.cpu-shares=(privileged,4,none)
Prj_2:101:project for App-2:root::project.cpu-shares=(privileged,1,none)

下图说明了此配置的正常操作和失效转移操作。分配的份额数不变。但是，根据分配给每个请求 CPU 时间的进程的份额数不同，每个应用程序可用的 CPU 时间比例可能发生变化。

说明：上文介绍了此图形。

具有三个应用程序的双节点群集

在具有三个应用程序的双节点群集上，可以将一个物理主机 (phys-schost-1) 配置为一个应用程序的缺省主控主机，将第二个物理主机 (phys-schost-2 ) 配置为其余两个应用程序的缺省主控主机。假设在每个节点上采用以下示例项目数据库文件。当发生失效转移或切换时，该项目数据库文件不发生变化。 

Prj_1:103:project for App-1:root::project.cpu-shares=(privileged,5,none)
Prj_2:104:project for App_2:root::project.cpu-shares=(privileged,3,none) 
Prj_3:105:project for App_3:root::project.cpu-shares=(privileged,2,none)

当群集正常运行时，应用程序 1 在其缺省主控主机（phys-schost-1）上分配到 5 份份额。此份额数相当于 100% 的 CPU 时间，因为应用程序1 是该节点上唯一一个请求 CPU 时间的应用程序。应用程序 2 和应用程序 3 分别在缺省主控主机（phys-schost-2 ）上分配到 3 份和 2 份份额。正常操作过程中，应用程序 2 将分配到 60% 的 CPU 时间，而应用程序 3 将分配到 40% 的 CPU 时间。

如果发生了失效转移或切换，且应用程序 1 切换到 phys-schost-2，则三个应用程序的份额都相同。但是，CPU 资源的比例将根据项目数据库文件重新进行分配。

下图说明了此配置的正常操作和失效转移操作。

说明：上文介绍了此图形。

仅限资源组的失效转移

在多个资源组具有相同的缺省主控主机的配置中，资源组（及其关联的应用程序）可以进行失效转移或切换到辅助节点。同时，缺省主控主机运行于群集中。

注意 –

失效转移过程中，发生失效转移的应用程序分配到的资源与辅助节点上的配置文件所指定的资源相同。在此示例中，主节点和辅助节点上的项目数据库文件具有相同的配置。

例如，此样例配置文件指定应用程序 1 分配到 1 份份额，应用程序 2 分配到 2 份份额，应用程序 3 分配到 2 份份额。 

Prj_1:106:project for App_1:root::project.cpu-shares=(privileged,1,none)
Prj_2:107:project for App_2:root::project.cpu-shares=(privileged,2,none)
Prj_3:108:project for App_3:root::project.cpu-shares=(privileged,2,none)

下图说明了此配置的正常操作和失效转移操作，其中包含应用程序 2 的 RG-2 进行失效转移，切换到 phys-schost-2。请注意，分配的份额数不变。但是，根据分配给每个请求 CPU 时间的应用程序的份额数不同，每个应用程序可用的 CPU 时间比例可能发生变化。

说明：上文介绍了此图形。

公共网络适配器和 IP Network Multipathing

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

Sun Cluster 中的 Solaris 网际协议 (IP) 网络多路径软件提供了一个基本机制，用于监视公共网络适配器，以及监视检测到故障时一个适配器到另一个适配器的失效转移 IP 地址。每个群集节点有它自己的 IP Network Multipathing 配置，该配置可以与其他群集节点不同。

公共网络适配器组织为 IP 多路径组（多路径组）。每个多路径组具有一个或多个公共网络适配器。多路径组中的每个适配器都可能处于活动状态，也可以配置备用接口，这些接口只有在发生失效转移时才会激活。in.mpathd 多路径守护程序使用一个测试 IP 地址检测故障和检修。如果多路径守护程序在某个适配器上检测到故障，则发生失效转移。所有的网络访问均进行失效转移，从发生故障的适配器切换到多路径组中的另一个功能适配器，从而维护该节点的公共网络连通性。如果配置了备用接口，则守护程序会选择该备用接口。否则，in.mpathd 将选择具有最小 IP 地址数目的接口。由于失效转移发生在适配器接口级，像 TCP 这样的更高级别的连接则不受影响，仅在失效转移期间有短暂的瞬时延迟。一旦 IP 地址的失效转移成功完成之后，就会发送未经请求的 ARP 广播。通过这种方法保持了与远程客户机的连通性。

注意 –

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

多路径组为逻辑主机名和共享地址资源提供了构件。您也可以独立于逻辑主机名和共享地址资源来创建多路径组，以监视群集节点的公共网络连通性。节点上相同的多路径组可以拥有任意数目的逻辑主机名或共享地址资源。有关逻辑主机名和共享地址资源的更多信息，请参见《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》。

注意 –

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

有关 IP 网络多路径的 Solaris 实现的详细信息，请参见群集中安装的 Solaris 操作环境的相应文档。

操作环境发行版 

有关说明，请转到... 

Solris 8 操作环境 

《IP Network Multipathing Administration Guide》

Solris 9 操作环境 

《System Administration Guide: IP Services》中的 “IP Network Multipathing Topics”

SPARC: 动态重新配置支持

Sun Cluster 3.1 4/04 对动态重新配置 (DR) 软件功能的支持正在进一步开发过程中。本部分说明了 Sun Cluster 3.1 4/04 对 DR 功能的支持所涉及的一些概念和注意事项。

请注意：相关文档中适用于 Solaris DR 功能的所有要求、步骤和限制同样适用于 Sun Cluster DR 支持（唯一的区别是操作环境静态操作）。因此，在通过 Sun Cluster 软件使用 DR 之前，须查阅有关 Solaris DR 功能的文档。您特别要注意那些在执行 DR 分离操作时将影响非网络 IO 设备的问题。可以从 http://docs.sun.com 下载 《Sun Enterprise 10000 Dynamic Reconfiguration User Guide》 和 《Sun Enterprise 10000 Dynamic Reconfiguration Reference Manual》（包含在 Solaris 8 on Sun Hardware Collection 或 Solaris 9 on Sun Hardware Collection 中）。

SPARC: 动态重新配置一般描述

DR 功能允许在运行的系统中进行各项操作，如删除系统硬件。DR 进程的设计旨在确保系统操作的连续性，而不必使系统停机或中断群集的使用。

DR 操作在板级别进行。因此，DR 操作会影响板上的所有组件。每块板可以包含多个组件，如 CPU、内存以及用于磁盘驱动器、磁带机和网络连接的外部接口。

删除包含活动组件的板将导致系统错误。删除板之前，DR 子系统对其他子系统（如 Sun Cluster）进行查询，以确定是否使用该板中的组件。如果 DR 子系统发现板正在使用中，则不执行 DR 删除板操作。因此，发布 DR 删除板操作始终是安全的，因为 DR 子系统能够拒绝对包含活动组件的板的操作。

DR 增加板操作也始终是安全的。系统自动将新增加到板上的 CPU 和内存投入使用。不过，系统管理员必须手动配置群集，然后才可随意使用新增加的板上的组件。

注意 –

DR 子系统包含若干个级别。如果较低的级别报错，则较高的级别同样也会报错。不过，较低的级别报告具体错误，而较高的级别报告“未知错误”。系统管理员应该忽略较高的级别所报告的“未知错误”。

下面各节说明了对于不同设备类型的 DR 考虑事项。

SPARC: 有关 CPU 设备的 DR 群集的注意事项

因为存在 CPU 设备，所以 Sun Cluster 软件将不拒绝 DR 删除板操作。

当 DR 增加板操作成功后，增加的板上的 CPU 设备会自动并入系统操作中。

SPARC: 有关内存的 DR 群集注意事项

基于 DR 目的，有两种内存需要加以考虑。这两种内存仅在用法上有所不同。对于这两种内存而言，实际的硬件是相同的。

操作系统所用的内存称作内核内存箱。Sun Cluster 软件不支持对包含内核内存箱的板执行删除操作，并将拒绝执行这样的操作。当 DR 删除板操作针对除内核内存箱以外的内存时，Sun Cluster 将不拒绝此操作。

当针对内存的 DR 增加板操作成功后，增加的板上的内存将自动并入系统操作。

SPARC: 有关磁盘和磁带机的 DR 群集注意事项

Sun Cluster 拒绝在主节点中的活动驱动器上进行 DR 删除板操作。可以对主节点中非活动状态的驱动器和辅助节点的任何驱动器执行 DR 删除板操作。DR 操作之后，对群集数据的访问象以前一样继续。

注意 –

Sun Cluster 拒绝进行影响仲裁设备可用性的 DR 操作。有关定额设备的考虑事项以及对其执行 DR 操作的过程，请参阅SPARC: 仲裁设备的 DR 群集注意事项。

有关如何执行这些操作的详细说明，请参见《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“任务对应关系：动态重新配置定额设备”。

SPARC: 仲裁设备的 DR 群集注意事项

如果 DR 删除板操作针对的板包含一个配置为仲裁设备的接口，则 Sun Cluster 将拒绝执行此操作，并标识出可能受此操作影响的仲裁设备。只有将仲裁设备进行处理使之不再是仲裁设备之后，您才能对其执行 DR 删除板操作。

有关如何执行这些操作的详细说明，请参见《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“任务对应关系：动态重新配置定额设备”。

SPARC: 群集互连接口的 DR 群集注意事项

如果 DR 删除板操作针对的板包含一个活动的群集互连接口，则 Sun Cluster 将拒绝执行此操作，并标识出可能受此操作影响的接口。在 DR 操作成功之前，必须使用 Sun Cluster 管理工具来禁用活动的接口。（另请参见下面的注意事项）。

有关如何执行这些操作的详细说明，请参见《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“管理群集互连”。

Caution – Caution –

Sun Cluster 要求每个节点与群集中的其他节点之间至少有一个有效路径。如果某个专用互连接口支持到任何群集节点的最后一条路径，则请勿禁用它。

SPARC: 公共网络接口的 DR 群集注意事项

如果 DR 删除板操作针对的板包含一个活动的公共网络接口，则 Sun Cluster 将拒绝执行此操作，并标识出可能受此操作影响的接口。删除包含活动的网络接口的板之前，必须先使用 if_mpadm(1M) 命令将该接口上的所有通信切换到多路径组中的另一个功能接口上。

Caution – Caution –

如果在已禁用的网络适配器上执行 DR 删除操作时，其余网络适配器发生故障，可用性将受到影响。另一个适配器在执行 DR 操作期间无法进行失效转移。

有关如何在公共网络接口上执行 DR 删除操作的详细说明，请参见《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的“管理公共网络”。