test

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

第 3 章 适用于系统管理员和应用程序开发者的关键概念

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

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

管理界面

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

群集时间

群集中的所有节点之间的时间必须同步。您是否将群集节点与任何外部时间源同步对于群集操作并不重要。Sun Cluster 系统使用网络时间协议 (Network Time Protocol, 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）》中的第 2  章 “安装和配置 Sun Cluster 软件”。

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

正常运行时，绝不需要调整群集的时间。但是，如果安装 Solaris 操作系统时该时间设置不正确，则要更改此设置，请参见《Sun Cluster 系统管理指南（适用于 Solaris OS）》中的第 7  章 “管理群集”中的相关过程。

高可用性框架

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

下表显示了 Sun Cluster 组件故障（包括硬件和软件）的种类和高可用性框架中内置的恢复方法的种类。

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

有故障的群集组件 

软件恢复 

硬件恢复 

数据服务 

HA API，HA 框架 

N/A 

公共网络适配器 

Internet 协议 (IP) 网络多路径 

多个公共网络适配卡 

群集文件系统 

主要和辅助复制 

多主机设备 

镜像多主机设备 

卷管理（Solaris 卷管理器和 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? 参数决定。您可以使用 eeprom(1M) 在 OpenBoot PROM ok 提示符处设置 auto-boot?。

群集配置库 (CCR)

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

注意 – 注意 –

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

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

全局设备

Sun Cluster 系统使用全局设备实现群集范围内的高可用性访问，您可以从任一节点对群集中的任一设备进行访问，而不用考虑设备的实际连接位置。通常情况下，如果某个节点在提供对全局设备的访问时出现故障，则 Sun Cluster 软件会自动找到该设备的其他路径并将访问重定向到此路径。Sun Cluster 全局设备包括磁盘、CD-ROM 和磁带。但是，磁盘是 Sun Cluster 软件所支持的唯一的多端口全局设备。因此，CD-ROM 和磁带在当前均非高可用性设备。每个服务器上的本地磁盘也不是多端口的，因而也不是高可用性设备。

群集自动为群集中的每个磁盘、CD-ROM 和磁带设备分配唯一的 ID。这使得从群集中任何节点访问每个设备都是一致的。全局设备名称空间保存在 /dev/global 目录下。有关更多信息，请参见全局名称空间。

多端口全局设备可为一个设备提供多个路径。因为多主机磁盘是多个节点托管的磁盘设备组的一部分，所以多主机磁盘是高可用性设备。

设备 ID 和 DID 伪驱动程序

Sun Cluster 软件使用 DID 伪驱动程序来管理全局设备。此驱动程序可自动给群集中的每个设备（包括多主机磁盘、磁带驱动器和 CD-ROM）指定的 ID。

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

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

您可以通过 scdidadm(1M) 和 scgdevs(1M) 更新和管理设备 ID。有关更多信息，请参见以下手册页：

磁盘设备组

在 Sun Cluster 系统中，所有多主机设备均必须受 Sun Cluster 软件的控制。首先，在多主机磁盘上创建卷管理器磁盘组—Solaris 卷管理器磁盘集或 VERITAS Volume Manager磁盘组（只能在基于 SPARC 的群集中使用）。然后将卷管理器磁盘组注册为磁盘设备组。磁盘设备组是一种全局设备。此外，Sun Cluster 软件还为群集中的每个磁盘和磁带设备创建一个原始磁盘设备组。然而，这些群集设备组将一直处于脱机状态，直到您将其作为全局设备访问为止。

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

注 –

磁盘设备组独立于资源组。一个节点可以控制资源组（代表一组数据服务进程），而另一个节点可以控制数据服务正在访问的磁盘组。但是，最好的做法是让存储特定应用程序数据的磁盘设备组和包含此应用程序资源（应用程序守护进程）的资源组保持在同一节点上。有关磁盘设备组和资源组之间关联的更多信息，请参阅《Sun Cluster Data Services Planning and Administration Guide for Solaris OS》中的“Relationship Between Resource Groups and Disk Device Groups”。

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

磁盘设备组故障转移

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

图 3–1 故障转移前和故障转移后的磁盘设备组

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

多端口磁盘设备组

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

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

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

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

注 –

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

设备服务缺省的所需辅助节点数为一。除非正常运行的非主供应商节点数目小于所需数目，否则由副本框架维护的实际辅助供应商节点数目就是所需数目。如果要向配置中添加或从中删除节点，则必须更改 numsecondaries 属性并重新检查节点列表。维护节点列表和所需辅助节点数目可以防止配置的辅助节点数目与框架实际允许的数目之间发生冲突。

全局名称空间

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

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

在 Sun Cluster 系统中，本地卷管理器名称空间中的每个设备节点都用 /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 卷管理器 

/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）。

使用群集文件系统

在 Sun Cluster 系统中，所有多主机磁盘都放在磁盘设备组中，这些组可以是 Solaris 卷管理器磁盘集、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 Data Services Planning and Administration Guide for Solaris OS》中的“Enabling Highly Available Local File Systems”。

HAStoragePlus 还可用于使资源及其依赖的磁盘设备组在启动时保持同步。有关更多信息，请参见资源、资源组和资源类型。

Syncdir 安装选项

您可以对使用 UFS 作为基础文件系统的群集文件系统使用 syncdir 安装选项。但是，如果不指定 syncdir，性能会有明显提高。如果指定 syncdir，可保证写入操作与 POSIX 兼容。如果不指定 syncdir，系统文件系统的行为就与 NFS 文件系统一样。例如，如果不指定 syncdir，就只能在关闭文件后才会发现空间不足。有了 syncdir（和 POSIX 行为），空间不足的情况应该在写入操作期间就已发现了。由于不指定 syncdir 而出现问题的情况很少。

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

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

磁盘路径监视

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

注 –

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

DPM 概述

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

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

地点 

组件 

后台程序 

/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 守护进程监视通过多路径驱动程序（如 Sun StorEdge Traffic Manager、HDLM 和 PowerPath）而可视的逻辑路径的可用性。由这些驱动程序管理的单独物理路径不受到监视，因为多路径驱动程序掩盖了 DPM 守护进程中的失败。

监视磁盘路径

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

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

关于故障防护

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

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

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

Sun Cluster 系统使用 SCSI 磁盘保留来实现故障防护。使用 SCSI 保留，故障节点就将与多主机设备“隔离”开来，使它们无法访问那些磁盘。

SCSI-2 磁盘保留支持一种保留形式，它或者为所有连接到磁盘的节点都授予访问权（当没有进行任何保留时），或者只允许一个节点（拥有保留的节点）具有访问权。

当群集成员检测到另一个节点不再通过群集互连进行通信时，它启动故障防护措施来避免另一个节点访问共享磁盘。当故障防护发生时，将停止使用被防护节点，并且其控制台上将显示“保留冲突”消息。

如果发现某个节点不再是群集成员，则将在此节点与其他节点所共享的所有磁盘上触发 SCSI 保留。被防护节点可能不会“意识”到它正处于防护状态，当它试图访问这些共享磁盘之中的一个时，它会检测到保留并进入停止使用状态。

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

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

属于群集成员的节点对它们可以访问的磁盘（包括仲裁磁盘）持续启用一个特定 ioctl：MHIOCENFAILFAST。该 ioctl 是针对磁盘驱动程序的指令。如果由于磁盘被某些其他节点保留而使节点无法访问磁盘，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 实用程序来设置此参数。

关于法定配置

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

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

遵守法定设备要求

您必须遵守以下要求。如果忽略这些要求，可能影响群集的可用性。

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

遵守法定设备最佳做法

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

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

建议的法定配置

本部分介绍了一些建议的法定配置的示例。有关应避免的法定配置的示例，请参见错误的法定配置。

双节点配置中的法定数目

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

图 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：NodeA-B. A/B connect to -> QD1/2. Config2:NodeA-D. A/B -> QD1/2. Config3:NodeA-C. A/B-> QD1/2 & C -> QD2.

数据服务

数据服务这个术语用来说明已配置为在群集上运行、而不是在一个单独的服务器上运行的应用程序，如 Sun Java System Web Server 或 Oracle。数据服务由应用程序、专用的 Sun Cluster 配置文件以及控制以下应用程序操作的 Sun Cluster 管理方法组成。

有关数据服务类型的信息，请参见《Sun Cluster 概述（适用于 Solaris OS）》中的“数据服务”。

图 3–4 比较了在单个应用服务器上运行的应用程序（单服务器模型）与在群集（群集服务器模型）上运行的相同应用程序。这两种配置之间的唯一区别是群集应用程序运行速度更快、可用性更高。

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

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

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

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

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

网络资源与特定的物理服务器无关。网络资源可以在物理服务器之间进行迁移。

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

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

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

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

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

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

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

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

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

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

数据服务方法

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

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

除 Sun Cluster 软件提供的方法之外，Sun Cluster 系统还提供了 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 浏览器在端口 80 使用三种不同的 TCP 连接连接到共享 IP 地址。但在服务时，这些连接将在它们之间交换缓存的会话信息。

可以将粘滞策略的本义延伸到在后台在相同实例上交换会话信息的多个可伸缩服务。当这些服务在后台在相同实例上交换会话信息时，可以说客户机相对于在不同端口上侦听的同一节点上的多个服务器实例是“粘滞的”。

例如，顾客在电子商务站点中通过在端口 80 使用 HTTP 向其购物车中添加商品。然后该顾客切换到端口 443 通过 SSL 来发送安全数据，以便通过信用卡为购物车中的商品进行支付。

通配粘滞服务使用动态分配的端口号，但仍期望客户机请求去往相同的节点。客户机就是端口（具有相同 IP 地址）上的“粘滞通配”。

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

默认情况下，对于每种粘滞策略，加权的负载平衡策略都是有效的。因此，客户的最初请求被定向到由负载平衡器指定的实例。在客户机为正运行实例的节点建立一种关联之后，以后的请求就会条件性地被定向到此实例。该节点必须可访问并且负载平衡策略未被更改。

有关特定的负载平衡策略的其他详细信息如下所示。

故障返回设置

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

如果托管资源组的原始节点再三地发生故障和重新引导，则设置故障返回可能会降低资源组的可用性。

数据服务故障监视器

每个 Sun Cluster 数据服务都具有一个故障监视器，该监视器定期探测数据服务以确定其运行情况是否良好。故障监视器将验证应用程序守护进程是否正在运行，还将验证客户机是否正接受服务。基于由探测返回的信息，可以启动一些预定义的操作，比如重新启动守护进程或引起故障转移。

开发新的数据服务

Sun 提供了配置文件和管理方法模板，使您能够在一个群集中让各种应用程序以失效转移或可伸缩服务的方式运行。如果 Sun 没有提供要作为故障转移或可伸缩服务来运行的应用程序，则您可以使用一种替代方案。您可以使用 Sun Cluster API 或 DSET API 来配置要作为故障转移或可伸缩服务运行的应用程序。但是，并非所有应用程序均可成为可伸缩服务。

可伸缩服务的特征

存在一组标准，用于确定应用程序是否可以成为可伸缩服务。要确定应用程序是否可以成为可伸缩服务，请参见《Sun Cluster 数据服务开发者指南（适用于 Solaris OS）》中的“分析应用程序的适用性”。此组标准概述如下：

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

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

《Sun Cluster Data Services Planning and Administration Guide for Solaris OS》介绍了如何安装和配置随 Sun Cluster 系统一起提供的数据服务。《Sun Cluster 3.1 9/04 Software Collection for Solaris OS (SPARC Platform Edition)》 介绍了如何设置其他应用程序以使它们在 Sun Cluster 框架下具有高可用性。

Sun Cluster API 使应用程序开发者能够开发可启动和停止数据服务实例的故障监视器和脚本。通过这些工具，应用程序就可以被实现为故障转移或可伸缩数据服务。Sun Cluster 系统提供一种“普通的”数据服务。这种普通的数据服务可以用于快速生成应用程序所需的启动和停止方法，并可以将数据服务实现为一种故障转移或可伸缩服务。

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

一群集必须有节点之间的多个网络互连，构成群集互连。Sun Cluster 软件使用多个互连以实现以下目标：

如果是内部通信（如文件系统数据或可伸缩服务数据），消息将以循环（共享）方式通过所有可用互连进行分配。群集互连对应用程序也是可用的，从而在节点间进行高可用性通信。例如，一个分布式应用程序的组件可能运行在不同的需要进行通信的节点上。通过使用群集互连而不使用公共传输，这些连接可承受单个链接失败。

要使用群集互连在节点间进行通信，应用程序必须使用安装 Sun Cluster 时配置的专用主机名。例如，如果节点 1 的专用主机名是 clusternode1-priv，则使用该名称通过群集互连与节点 1 进行通信。使用该名称打开的 TCP 套接字是通过群集互连进行路由的，而且在网络出现故障时可对其进行透明的重新路由。

由于在安装 Sun Cluster 时可以配置专用主机名，所以群集互连使用的是安装时选择的名称。要确定实际的名称，请使用 scha_cluster_get(3HA) 命令和 scha_privatelink_hostname_node 参数。

应用程序通信和内部群集通信都通过所有互连进行分配。由于应用程序与内部群集通信共享群集互连，所以应用程序可用的带宽取决于其他群集通信使用的带宽。如果出现故障，内部通信和应用程序通信将通过所有可用互连进行分配。

每个节点还分配了一个固定的单节点地址。此单节点地址由 clprivnet 驱动程序探测而得。其 IP 地址将映射到该节点的专用主机名：clusternode1-priv。有关 Sun Cluster 专用网络驱动程序的信息，请参见 clprivnet(7) 手册页。

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

资源、资源组和资源类型

数据服务利用了几种类型的资源：诸如 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.LogicalHostname 资源类型，要么是 SUNW.SharedAddress 资源类型。这两种资源类型已由 Sun Cluster 软件预先注册。

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 Data Services Planning and Administration Guide for Solaris OS》。

资源组管理器 (RGM)

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

RGM 对资源和资源组进行操作。RGM 操作将使资源和资源组在联机和脱机状态之间进行转换。有关可应用于资源和资源组的状态和设置的完整说明，请参见资源和资源组状态与设置一节。

有关如何启动 RGM 控制下的 Solaris 项目的信息，请参阅数据服务项目配置。

资源和资源组状态与设置

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

资源与资源组特性

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

标准特性用于配置那些通常独立于任何特定数据服务的资源和资源组特性。有关标准属性集，请参见《Sun Cluster Data Services Planning and Administration Guide for Solaris OS》中的附录 A “Standard Properties”。

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

数据服务项目配置

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

注 –

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

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

注 –

在叙及此功能的 Solaris 文档中，CPU 时间、进程、任务和类似的组件均称为“资源”。同时，Sun Cluster 文档使用术语“资源”来说明由 RGM 控制的实体。下一部分将使用术语“资源”指代由 RGM 控制的 Sun Cluster 实体。本部分使用术语“供应”指代 CPU 时间、进程和任务。

本部分提供了配置数据服务以在指定的 Solaris 9 project(4) 中启动进程的概念说明。本部分还介绍了用于规划的若干故障转移方案和建议以使用 Solaris 操作系统提供的管理功能。

有关管理功能的详细概念文档和过程文档，请参阅《System Administration Guide: Network Services》中的第 1  章 “Network Service (Overview)”。

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

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

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

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

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

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

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

  7. 使资源组联机。

要配置标准的 Resource_project_name 或 RG_project_name 属性，以便将 Solaris 项目 ID 与资源或资源组关联，请使用 -y 选项和 scrgadm(1M) 命令。将特性值设置为资源或资源组。有关属性定义，请参见《Sun Cluster Data Services Planning and Administration Guide for Solaris OS》中的附录 A “Standard Properties”。有关属性说明，请参阅 r_properties(5) 和 rg_properties(5)。

指定的项目名称必须存在于项目数据库 (/etc/project) 中，而超级用户必须配置为此命名项目的成员。有关项目名称数据库的概念信息，请参阅《System Administration Guide: Solaris Containers-Resource Management and Solaris Zones》中的第 2  章 “Projects and Tasks (Overview)”。有关项目文件语法的说明，请参阅 project(4)。

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

注 –

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

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

确定项目配置的要求

在 Sun Cluster 环境中配置数据服务以使用由 Solaris 提供的控制之前，必须先确定如何在切换或故障转移过程中控制和跟踪资源。配置新项目之前，请标识群集中的依赖性。例如，资源和资源组依赖于磁盘设备组。

使用通过 scrgadm(1M) 配置的 nodelist、failback、maximum_primaries 和 desired_primaries 资源组属性来标识资源组的节点列表优先级。

使用通过 scrgadm(1M) 和 scsetup(1M) 配置的 preferenced 和 failback 属性来确定磁盘设备组节点列表的优先级。

如果要对所有的群集节点进行同样的配置，则会对主节点和辅助节点强制执行同样的使用限制。对于所有节点配置文件中的所有应用程序，其项目配置参数不必相同。与应用程序相关联的所有项目至少可以在该应用程序的所有潜在主机上由项目数据库访问。假设应用程序 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) 在正常的群集操作中和切换或失效转移情况下进行分配。

以下部分是示例情况。

在 Sun Cluster 环境中，可将应用程序配置为资源的一部分。然后将资源配置为资源组 (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 时间的应用程序的份额数。

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

公共网络适配器和 Internet 协议 (IP) 网络多路径

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

Sun Cluster 中的 Solaris Internet 协议 (Internet Protocol, IP) 网络多路径软件提供了一种基本机制，用于监视公共网络适配器，并在检测到故障时将 IP 地址从一个适配器故障转移到另一个适配器。每个群集节点均有自己的 Internet 协议 (IP) 网络多路径 配置，此配置可以不同于其他群集节点上的配置。

公共网络适配器组织为 IP 多路径组（多路径组）。每个多路径组具有一个或多个公共网络适配器。多路径组中的每个适配器均可处于活动状态。此外，您也可以配置备用接口，这些接口只有在发生故障转移时才会激活。

in.mpathd 多路径守护进程使用一个测试 IP 地址进行故障检测和检修。如果多路径守护进程在某个适配器上检测到故障，则发生失效转移。所有网络访问都将从发生故障的适配器故障转移到多路径组中另一个能够正常运行的适配器。因此，该守护进程维护了节点的公共网络连通性。如果配置了备用接口，则守护进程会选择该备用接口。否则，守护进程将选择具有最小 IP 地址数目的接口。由于故障转移发生在适配器接口级，因此诸如 TCP 这样更高级别的连接，除在故障转移期间有短暂的瞬时延迟以外，将不会受影响。IP 地址的故障转移成功完成之后，将发送 ARP 广播。这样，守护进程就维护了与远程客户机的连通性。

注 –

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

多路径组为逻辑主机名和共享地址资源提供了构件。您也可以独立于逻辑主机名和共享地址资源来创建多路径组，以监视群集节点的公共网络连通性。节点上相同的多路径组可以拥有任意数目的逻辑主机名或共享地址资源。有关逻辑主机名和共享地址资源的更多信息，请参见《Sun Cluster Data Services Planning and Administration Guide for Solaris OS》。

注 –

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

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

操作系统版本 

参考 

Solaris 8 操作系统 

《IP Network Multipathing Administration Guide》

Solaris 9 操作系统 

《IP Network Multipathing Administration Guide》中的第 1  章 “IP Network Multipathing (Overview)”

Solaris 10 Operating System 

《System Administration Guide: IP Services》中的第 VI 部分, “IPMP”

SPARC: 动态重新配置支持

Sun Cluster 3.1 8/05 对动态重新配置 (DR) 软件功能的支持正在进一步的开发过程中。本部分说明了 Sun Cluster 3.1 8/05 对 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 目的，有两种内存需要加以考虑。

这两种内存仅在用法上有所不同。对于这两种内存而言，实际的硬件是相同的。内核内存箱是指 Solaris 操作系统所用的内存。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）》中的第 5  章 “管理定额”。

SPARC: 对于群集互连接口的 DR 群集考虑事项

如果 DR 删除板操作针对的板包含一个活动的群集互连接口，Sun Cluster 软件将拒绝执行此操作。并且该软件还标识出将受此操作影响的接口。要使 DR 操作成功，必须使用 Sun Cluster 管理工具禁用活动的接口。

注意 – 注意 –

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

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

SPARC: 对于公共网络接口的 DR 群集考虑事项

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

注意 – 注意 –

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

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