2008年（909）
分类：
2008-05-06 21:01:31
本章介绍了 Sun 群集配置的软件组件的一些相关的重要概念。包括下列主题：
管理接口
群集时间
高可用性框架
全局设备
磁盘设备组
全局名称空间
群集文件系统
定额和定额设备
卷管理器
数据服务
开发新的数据服务
资源和资源类型
公共网络管理 (PNM) 和网络适配器失败切换 (NAFO)
此信息主要面向使用 Sun Cluster API 和 SDK 的系统管理员和应用程序开发人员。系统管理员可以将此信息作为 安装、配置和管理群集软件的背景知识。应用程序开发人员可以通过此信息来了解他们工作的群集环境。
下图从较高的层次上显示了群集管理概念与群集体系结构之间的映射关系。
您可以从几个用户界面中选择一个来安装、配置和管理 Sun Cluster 和 Sun Cluster 数据服务。还可以通过命令行接口来 完成系统管理任务。在命令行接口顶部有一些实用程序可用来简化选定的配置任务。Sun Cluster 还有一个模块作为 Sun Management Center 的一部分 运行，可为某些群集任务提供 GUI。关于管理接口的完整说明，可参见 Sun Cluster 3.0 系统管理指南 中包括介绍性内容的一章。
群集中的所有节点之间的时间必须同步。是否让群集节点与外部时间源同步对群集运行来说并不重要。Sun Cluster 采用 “网络时间协议 (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 安装指南 中。
或者您也可以在群集之外设置一个或多个 NTP 服务器，并更改 ntp.conf 文件使之能反映出这一配置。
正常运行时，绝不需要调整群集的时间。然而，如果安装 Solaris 操作环境时时间设置不正确，现在想更改时间，可在 Sun Cluster 3.0 系统管理指南 中 找到操作步骤。
Sun Cluster 使用户和数据间“路径”上的所有组件都高度可用，这些组件包括网络接口、应用程序本身、文件系统和 多主机磁盘。一般情况下，如果一个群集组件可从系统中的任何单一（软件或硬件）故障中恢复，则它是高度可用的。
下表显示了 Sun Cluster 组件故障种类（硬件和软件）和高可用性框架中建立的恢复种类。
软件恢复 | 硬件恢复 |
HA API，HA 框架 | N/A |
|---|---|---|
公共网络适配器 | 网络适配器失败切换 (NAFO) | 多个公共网络适配器卡 |
群集文件系统 | 主要和辅助复制 | 多主机磁盘 |
镜像多主机磁盘 | 卷管理（Solstice DiskSuite 和 VERITAS 卷管理器） | 硬件 RAID-5（例如 Sun StorEdge A3x00） |
全局设备 | 主要和辅助复制 | 到设备、群集传输结点的多个路径 |
专用网 | HA 传输软件 | 多个专用硬件独立网络 |
节点 | CMM，失败快速保护驱动程序 | 多个节点 |
Sun Cluster 高可用性框架可迅速检测到节点故障，并在群集中的其余节点上为该框架资源创建一个新的 等效服务器。不会出现所有框架资源都不可用的情况。在恢复期间，未受崩溃节点影响的框架资源是完全可用的。而且，故障节点 的框架资源一恢复就立即可用。已恢复的框架资源不必等待其他所有框架资源都完全恢复。
可用性最高的框架资源恢复过程对于使用它的应用程序（数据服务）来说是透明的。框架资源访问的语义在整个节点 故障期间得到全面的保护。应用程序根本不知道框架资源已转移到另一节点。单个节点的故障对于在使用着该节点上的 文件、设备和磁盘卷的其他节点上的程序来说，是完全透明的。多主机磁盘的使用就是一个例证，这些磁盘具有连接多个节点的端口。
群集成员监视器 (CMM) 是一个分布式代理程序集，每个群集成员有一个代理程序。这些代理程序在群集互连中交换信息，以便：
在所有节点上保持一致的成员视图（定额）
使用注册的回叫来驱动同步重新配置，以响应成员更改
处理群集划分（群集分割，失忆）
保证所有群集成员间的充分连通性
与 Sun Cluster 的上一发行版不同，CMM 是完全在内核中运行的。
CMM 的主要功能是，在任一给定时间加入群集的节点集上建立一个群集范围的协议。Sun Cluster 将此约束称作群集成员。
为确定群集成员并最终保证数据的完整性，CMM：
说明群集成员的更改，如某个节点加入或脱离群集
保证“故障”节点脱离群集
保证“故障”节点在修复前不进入群集
防止群集将自身划分一些节点子集
有关群集如何防止自身划分多个独立群集的详细信息，请参见 定额和定额设备。
为确保数据免遭破坏，所有节点必须在群集成员上达成一致协议。需要时，CMM 将协调群集服务（应用程序）的群集重新配置， 以作为对故障的响应。
CMM 会从群集传输层接收到关于与其他节点连通性的信息。CMM 使用群集互连在重新配置期间交换状态信息。
检测到群集成员有更改后，CMM 执行群集的同步配置，这时群集资源可能会按群集新的成员被重新分配。
群集配置库 (CCR) 是专用的群集范围的数据库，用于保存与群集的配置和状态有关的信息。CCR 是一个分布式数据库。每个节点 上都有该数据库的完整副本。CCR 可保证所有节点都有该群集“世界”的一致视图。为避免破坏数据，每个节点都要知道 群集资源的当前状态。
CCR 是在内核中实现的，是一种高度可用的服务。
CCR 使用两阶段提交算法用于更新：更新必须在所有群集成员上都成功完成，否则此更新将被回退。CCR 使用群集互连 来应用分布式更新。
尽管 CCR 是由文本文件组成的，但也绝不要手动编辑 CCR 文件。每个文件都有一个校验和 来保证一致性。手动更新 CCR 文件可能会导致某个节点或整个群集不能工作。
CCR 靠 CMM 来保证群集只有在定额建立后才能运行。CCR 负责跨群集验证数据的一致性，需要时执行恢复，并为数据更新提供工具。
Sun Cluster 使用全局设备提供群集范围内的高可用性访问，这种访问可以是对群集中的 任一设备，自任意节点，而不用考虑设备的物理连接位置。通常，如果一个节点未能提供到某一全局设备的访问，则 Sun Cluster 自动 找到到该设备的另一路径，并将访问重定向到此路径。Sun Cluster 全局设备包括磁盘、CD-ROM 和磁带。不过，磁盘是唯一 支持的多端口全局设备。这意味着 CD-ROM 和磁带设置目前还不是高可用性的设备。每个服务器上的本地磁盘也不是多端口的，因而 也不是高可用性设备。
群集会给群集中的每个磁盘、CD-ROM 和磁带设备分配唯一的标识。这种分配使得从群集中任何节点到每个设备的访问 都保持一致性。全局设备名称空间保存在 /dev/global 目录下。有关详细信息请参见 全局名称空间。
多端口全局设备可为一个设备提供多个路径。至于多主机磁盘，因为这些磁盘是以一个以上节点作为主机的磁盘设备组的一部分， 所以它们是高可用性设备。
Sun Cluster 通过一种叫做设备标识 (DID) 伪驱动程序的结构来管理全局设备。此驱动程序可自动给群集中的每个设备 分配唯一的标识，包括多主机磁盘、磁带驱动器和 CD-ROM。
设备标识 (DID) 伪驱动程序是群集的全局设备访问功能的基本构成部分。DID 驱动程序探测群集中的所有节点并建立 唯一磁盘设备列表，给每个磁盘设备分配唯一的主/次编号，这些编号在群集中所有节点上都是一致的。执行对全局设备的访问 时使用的是 DID 驱动程序分配的唯一设备标识，而非传统的 Solaris 设备 ID（如某一磁盘的标识 c0t0d0）。
这一措施可保证任何使用磁盘设备的应用程序（如卷管理器或使用原始设备的应用程序）都可使用一致的路径 访问设备。此一致性对多主机磁盘尤为重要，因为每个设备的本地主/次编号在各节点上都可能不相同，因而也就改变 了 Solaris 设备命名约定。例如，节点 1 可能将一个多主机磁盘看作 c1t2d0，而节点 2 可能会完全不同， 将同一磁盘看作是 c3t2d0。DID 驱动程序则会分配一个全局名称，如 d10，供节点使用，这样就为每个节点 提供了到多主机磁盘的一致映射。
您可以通过 scdidadm(1M) 和 scgdevs(1M) 更新和管理设备标识。有关详细 信息，请参见相应的手册页。
在 Sun Cluster 中，所有多主机磁盘都必须受 Sun Cluster 框架的控制。您首先在多主机磁盘上创建卷管理器 磁盘组--或者是 Solstice DiskSuite 磁盘集，或者是 VERITAS 卷管理器 磁盘组。然后将卷管理器磁盘组注册 为 Sun Cluster 磁盘设备组。磁盘设备组是一种全局设备。此外，Sun Cluster 将每一个单个磁盘注册为一个磁盘设备组。
磁盘设备组独立于资源组。一个节点可以控制资源组（代表一组数据服务进程），而另一个节点可以控制正被 数据服务访问的磁盘组。不过最好的做法是，让存储特定应用程序数据的磁盘设备组和包含此应用程序资源（应用程序守护程序）的 资源组保持在同一节点上。有关磁盘设备组和资源组之间关系的详细信息，请参见 Sun Cluster 3.0 Data Services Installation and Configuration Guide 中包含概述性内容的那一章。
有了磁盘设备组，卷管理器磁盘组就成了“全局”的，因为它对基础磁盘提供了多路径支持。物理连接到多主机磁盘 的每个群集节点都提供了一条到磁盘设备组的路径。
如果全局设备是以一个以上群集节点为主机的设备组的一部分，则它是高可用的。
因为磁盘群组连接着一个以上的节点，所以群组中的所有磁盘设备组在当前控制它的节点出现故障时，都可以通过备用 路径访问。控制设备组的节点出现故障不会影响对此设备组的访问，但在执行恢复和一致性检查时除外。在这段时间，所有 请求都被阻挡（对应用程序是透明的），直到系统使该设备组可用为止。
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 磁盘组的目录组成。每一个这样的目录中都有此磁盘集 或磁盘组中每个元设备或卷的设备节点。
在 Sun Cluster 中，本地卷管理器名称空间中的每个设备节点都被替换成 /global/.devices/node@nodeID 系统文件 中到某个设备节点的符号链接，其中 nodeID 是一个整数，代表群集中的节点。Sun Cluster 还会将卷管理器设备在标准位置显示为符号链接。全局名称空间和标准卷管理器名称空间两者在任何群集节点上都可以找到。
全局名称空间的优点有：
每个节点可保持相当的独立性，不需要对设备管理模型做什么改动。
可以有选择地使设备变成全局设备。
第三方链接产生器可继续工作。
只要给出本地设备名称，就会有一个简单的映射用以获得其全局名称。
下表显示的是一个多主机磁盘 c0t0d0s0 的本地名称空间和全局名称空间之间的映射关系。
本地节点名称空间 | 全局名称空间 |
/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 卷管理器 | /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），从群集中的任意节点访问群集文件系统中的文件。 所有群集成员上都安装了一个群集文件系统。不可以在群集成员的子集上安装群集文件系统。
在 Sun Cluster 中，所有多主机磁盘都配置为磁盘设备组，这些多主机磁盘可以是 Solstice DiskSuite 磁盘集、VxVM 磁盘组或不受基于软件的 卷管理器控制的独立磁盘。另外，本地磁盘都配置为磁盘设备组：从每个节点引向每个本地磁盘的路径。此设置并不意味着一个 磁盘上的数据必须能被所有节点访问。只有在磁盘上的文件系统安装为全局性的群集文件系统时，这些数据才能被所有节点访问。
成为群集文件系统的本地文件系统与磁盘存储器只有单一的连接。如果与磁盘存储器有物理连接的节点出现故障， 则其他节点就不再能够访问群集文件系统。您可以在一个节点上创建不能由其他节点直接访问的本地文件系统。
HA 数据服务经过设置后，服务所用的数据存储在群集文件系统中的磁盘设备组上。这种设置有几个优点。首先，数据是高可用的； 也就是说，因为磁盘是多主机的，如果当前主节点的路径出现问题，访问就切换到可直接访问这些磁盘的另一节点。其次，因为数据 在群集文件系统上，所以可以从任何群集节点上直接查看它--不必登录到当前控制着该磁盘设备组的节点来查看数据。
群集文件系统基于代理文件系统 (PXFS)，后者有下列功能：
PXFS 使文件访问位置透明。一个进程可打开位于系统中任何位置的文件，而且所有节点上的进程 都可以使用同样的路径名定位文件。
PXFS 使用相关协议来保留 UNIX 文件访问的语义，即使从多个节点并行访问文件时也是如此。
PXFS 可提供大范围的高速缓存和零复制批量 I/O 移动，以便有效地移动大数据对像。
PXFS 可提供对数据的连续访问，即使发生故障时也是如此。只要到磁盘的路径仍然有效， 应用程序就检测不到故障。对于原始磁盘访问和所有文件系统操作，也可保证。
PXFS 独立于基础文件系统和卷管理软件。PXFS 使所有磁盘上文件系统具有全局性。
PXFS 是在 vnode 接口处建立在现有 Solaris 文件系统之上的。此接口使得不用进行大量的内核修改就可以实现 PXFS。
PXFS 不是一种独特的文件系统类型。也就是说，客户机看到的是基础文件系统（如 UFS）。
群集文件系统独立于基础文件系统和卷管理器。目前，您可以用 Solstice DiskSuite 或 VERITAS 卷管理器 在 UFS 上建立群集文件系统。
与一般的文件系统一样，您可以以两种方式安装群集文件系统：
手动 -- 使用 mount 命令 和 -g 选项从命令行安装群集文件系统，例如：
|
自动 -- 在 /etc/vfstab 文件中 用 global 安装选项创建一个条目，以在引导时建立群集文件系统。接着就可以 在所有节点上的 /global 目录下创建一个安装点。目录 /global 是推荐 的位置，不是必需的。下面是 /etc/vfstab 文件中一个群集文件系统的实例行：
|
Sun Cluster 不强制使用群集文件系统的命名策略，所以您可以通过在同一目录 下（如 /global/disk-device-group）为所有群集文件系统创建一个安装点 来使管理更容易。有关详细信息，请参见 Sun Cluster 3.0 安装指南 和 Sun Cluster 3.0 系统管理指南。
群集文件系统可使用 syncdir 安装选项。不过，如果不指定 syncdir， 性能会有明显提高。如果您指定 syncdir，则保证写入的数据符合 POSIX 标准。如果不指定， 您会看到与 UFS 文件系统一样的行为。例如，在某些情况下，如果不指定 syncdir，就只能在关闭一个文件后 才发现空间不足。有了 syncdir（和 POSIX 行为），空间不够的情况应该在写入操作期间就已发现了。在不指定 syncdir 时出现问题的情形是很少见的，所以我们建议您不指定它，以便在性能方面受益。
有关全局设备和群集文件系统的常见问题，请参见 文件系统 FAQ。
因为群集节点共享数据和资源，所以群集必须采取措施保持数据和资源的完整性。当一个节点不符合群集的成员规则时， 群集必须禁止该节点加入群集。
在 Sun Cluster 中，决定节点是否可加入群集的机制叫做定额。Sun Cluster 采用一种多数票算法 来实现定额机制。群集节点和定额设备（两个或更多节点间共享的磁盘）都参加投票， 形成定额。一个定额设备可以包含用户数据。
定额算法自动执行：当群集事件触发其计算时，计算结果在群集的生命周期内会发生变化。 定额可防止发生两种潜在的群集问题 -- 群集分割和失忆 -- 二者均可造成使不一致的数据提供 给客户机。下表描述了这两种问题以及它们是如何解决的。
描述 | 定额的解决方案 |
在节点间失去群集互连并且群集划分为若干子群集时发生，每个分区都认为自己是唯一分区 | 仅允许获得多数选票的分区（子群集）作为群集（其中最多仅能有一个拥有多数选票的分区） |
|---|---|---|
失忆 | 群集关闭后又重新启动时，此时的群集数据比关闭时旧 | 在群集引导时，保证至少有一个节点是最新的群集成员之一（因而有最新的配置数据） |
群集节点和定额设备（在两个或更多节点之间共享的磁盘）两者都通过投票来形成定额。缺省情形下，群集节点在 引导并成为群集成员时获取其中一个的定额投票计数。节点的投票数可以是零，例如当正在安装节点时，或当管理员将节点置于维护状态时。
定额设备获取定额投票计数基于设备的节点连接数。在设置定额设备时，它需获取一个最大投票 数 N-1，其中 N 是有非零投票数的节点数，并且这些节点有到 定额设备端口。例如，连接到两个投票数非零的节点的定额设备有其中一个的定额数（二减一）。
您要在在群集安装期间，或以后通过使用在 Sun Cluster 3.0 系统管理指南 中描述的过程来配置定额设备。
仅在当前连接的节点中至少有一个是群集成员时，定额设备才对投票数起作用。同时，在群集引导期间，仅在当前 连接的至少一个节点正在引导，并且在关闭时它是最近刚刚引导的群集成员的情况下，定额设备才对投票数起作用。
定额配置依赖于群集中节点的数目：
双节点群集 - 要形成双节点群集， 需要两个定额投票。这两个投票可以来自于两个群集节点，或者只来自一个节点和一个定额设备。然 而，在双节点群集中，必须配置一个定额设备，以确保在一个节点发生故障时另一单个节点可以继续工作。
多于两个节点的群集 - 您应在共享对磁盘存储器群组访问 的每对节点间指定一个定额设备。例如，假定您有一个由三个节点组成的群集，类似于 8中展示的群集那样。在此图中，nodeA 和 nodeB 共享对同 一磁盘群组的访问权，而 nodeB 和 nodeC 共享对另一磁盘群组的访问权。总共会有五个定额选票，其中三个来自节点，两个来自节点共享的定额设备。一个群集需要多数定额投票，即三个，才能形成。
Sun Cluster 不要求也不强迫在共享对磁盘存储器群组访问的每对节点间指定一个定额设备。但是，对于 N 1 配置降级为一个双节点群集并且 紧接着对两个磁盘群组都有访问权的节点也发生故障的情况，它可以提供所需要的定额选票。如果您在每对节点之间配置了定额设备，则其余的节点仍可作为一个群集来运行。
关于这些配置的实例请参见 8。
在设置定额设备时，请使用下列准则：
在连接相同共享磁盘存储器群组的所有节点间建立定额设备。在共享群组内添加一个磁盘 作为定额设备以确保在任何节点发生故障时，其他节点可以维持定额并可以控制共享群组上的磁盘设备组。
必须将定额设备连接到至少两个节点上。
定额设备可以是用作双端口定额设备的任何 SCSI-2 或 SCSI-3 磁盘。连接到超过两个节点的磁盘必须 支持 SCSI-3 持久性组保留 (PGR)，而不论磁盘是否用为作定额设备。有关详细信息，请参见 Sun Cluster 3.0 安装指南 中有关计划的章节。
您可以使用包含用户数据的磁盘作为定额设备。
在节点集之间配置一个以上定额设备。使用来自不同群组的磁盘，并在每个节点集之间配置奇数的定额设备。这可以避免在单个定额设备发生故障。
群集的一个主要问题是引起群集分区的故障（称作群集分割）。当此故障发生时，并不是所有 节点都可以通信，所以个别节点或节点子集可能会尝试组成个体或群集子集。每个子集或分区都可能以为它对多主机磁盘的 唯一访问权和所有权。多个节点试图写入磁盘会导致数据损坏。
故障防护通过以物理方式防止对磁盘的访问，限制了节点对多主机磁盘的访问。当节点脱离群集时（它或是发生故障， 或是分区），故障防护确保了该节点不再能访问磁盘。只有当前成员节点有权访问磁盘，以保持数据的完整性。
磁盘设备服务为使用多主机磁盘的服务提供了失败切换能力。在当前担当磁盘设备组主节点（属主）的群集成员发生 故障或变得无法访问时，一个新的主节点会被选中，使得对磁盘设备组的访问得以继续，而只有微小的 中断。在此过程中，旧的主节点必须放弃对设备的访问，然后新的主节点才能启动。然而， 当一个成员从群集断开并变得无法访问时，群集无法通知那个节点释放那些将该节点作为主节点的设备。因而，您需要一种方法 来使幸存的成员能够从失败的成员那里控制并访问全局设备。
Sun Cluster 使用 SCSI 磁盘保留来实现故障防护。使用 SCSI 保留，故障节点被与多主机磁盘“隔离”起来，使它们 无法访问那些磁盘。
SCSI-2 磁盘保留支持一种保留形式，它或者授权给所有连接到磁盘的节点访问权（当没有保留上时），或者 限制对单个节点（即拥有该保留的节点）的访问权。
当群集成员检测到另一个节点不再通过群集互连进行通信时，它启动故障防护措施来避免另一个节点访问 共享磁盘。当发生此故障防护时，通常将防护的节点处于应急状态，并在其控制台上显示“保留冲突”的消息。
发生保留冲突是因为在节点已被检测到不再是群集成员后，一个 SCSI 保留被置于在此节点与其他节点间共享 的所有磁盘上。防护节点可能不会意识到它正在被防护，并且如果它试图访问这些共享磁盘之中的一个，它会检测到保留和应急状态。
Sun Cluster 使用卷管理软件通过镜像和热备份磁盘来增加数据的可用性，并处理磁盘故障和更换。
Sun Cluster 没有它自己的内部卷管理器组件，而依赖于下面的卷管理器：
Solstice DiskSuite
VERITAS 卷管理器
群集中的卷管理软件提供对如下功能的支持：
节点故障的失败切换处理
来自不同节点的多路径支持
对磁盘设备组的远程透明访问
当在 Sun Cluster 中设置卷管理器时，您将多主机磁盘配置作为 Sun Cluster 磁盘设备，它是卷管理器磁盘组 的一个包装。设备既可以是一个 Solstice DiskSuite 磁盘集，也可以是一个 VxVM 磁盘组。
您必须将磁盘组配置为用于数据服务，以镜像映射来使该群集内的磁盘变得高可用。
您可以使用元设备或复用设备作为一个原始设备（数据库应用程序），或者保持 UFS 文件系统。
卷管理对像 -- 元设备和卷 -- 来自群集的控制之下，从而成为磁盘设备组。例如，在 Solstice DiskSuite 中， 当您在群集中创建磁盘集时（通过使用 metaset(1M) 命令），会创建一个相应的同名 磁盘设备组。接着，当您在该磁盘集中创建元设备时，他们变成了全局设备。因而，磁盘集是磁盘设备（DID 设备）和主机 的集合，集合中的所有设备都移植到主机中。群集中的所有磁盘集在创建时都需要在集合中有一个以上的主机， 以便归档 HA。在使用 VERITAS 卷管理器 也时会发生相同的情况。设置每个卷管理器的详细信息包含在 Sun Cluster 3.0 安装指南 的附录中。
在规划磁盘集或磁盘组时一个重要的考虑事项就是要了解他们的关联磁盘设备组是如何在群集内与应用程序 资源（数据）相联系的。关于这些问题的讨论，请参考 Sun Cluster 3.0 安装指南 和 Sun Cluster 3.0 Data Services Installation and Configuration Guide。
术语数据服务是用来描述诸如 Apache Web Server 之类的第三方应用 程序，该应用程序已被配置在群集上运行，而不是在一个单独的服务器上运行。数据服务包括启动、关闭和监视应用程序的应用程序软件和 Sun Cluster 软件。
Sun Cluster 提供在群集内控制和监视应用程序的数据服务方法。这些方法在 Resource Group Manager (RGM) 的控制下 运行，RGM 使用它们来启动、停止和监视群集节点上的应用程序。这些方法在与群集框架软件和多主机磁盘一起时，使应用程序 能够成为高可用性的数据服务。作为高可用性的数据服务，它们防止了在群集内任何单独的故障后发生显著的 应用程序中断。故障可能发生在一个节点上、一个接口组件上，或者发生在应用程序本身。
RGM 也管理群集中的资源，包括应用程序实例和网络资源（逻辑主机名和共享地址）。
Sun Cluster 也提供了 API 和数据服务开发工具，使应用程序编程人员能够开发所需要的数据服务方法， 以使其他应用程序作为高可用性的数据服务与 Sun Cluster 一起运行。
Sun Cluster 提供使应用程序变得高可用性和可伸缩的环境。RGM 作为资源运行，资源是具有下面特性的逻辑组件：
进入联机、脱机断开（切换）
由 RGM 框架管理
在单独节点（失败切换方式）或多个节点（可伸缩方式）上作为主机
RGM 将数据服务（应用程序）作为资源控制，资源是由资源类型实现所管理 的。这些实现或者由 Sun 提供，或者由具有一个类属数据服务模板、数据服务开发 库 API (DSDL API) 或 Sun Cluster 资源管理 API (RMAPI) 的开发者创建。群集管理员在 称为资源组的容器中创建和管理资源，这些容器形成失败切换和切换的基本单元。RGM 根据群集成员 关系的变化来停止或启动选定节点上的资源组。
如果正在运行数据服务的节点（主节点）发生故障，那么该服务会被移植到另一个工作节点而无需用户干预。失败切换服务利用 了失败资源组，它是一个应用程序实例资源和网络资源（逻辑主机名）容器。逻辑主机名是 一些可以配置到节点上的 IP 地址，然后自动在原始节点解除配置，并配置到另一节点上。
对于失败切换数据服务，应用程序实例仅在一个单独的节点上运行。如果故障监视器检测到一个故障，它或者试图在同一节点 上重新启动该实例，或者在另一个节点上启动实例（失败切换），这取决于该数据服务是如何配置的。
可伸缩数据服务对多个节点上的活动实例有潜能。可伸缩服务利用可伸缩资源组来保持应用程序 资源，利用失败切换资源组来保持可伸缩服务所依赖的网络资源（共享地址）。可伸缩资源组可以在 多个节点上联机，因此服务的多个实例可以立刻运行。以共享地址为主机的失败切换资源组每次只在一个节点上联机。以可伸缩服务做 主机的所有节点使用相同的共享地址来主持该服务。
服务请求通过一个单独的网络接口（全局接口 或 GIF）进入群集，并依 据由负载平衡策略设置的几个预定义算法之一来将这些请求分发到 节点。群集可以使用负载平衡策略来平衡几个节点间的服务负载。注意，在不同的节点上可能有 多个 GIF 以其他共享地址为主机。
对于可伸缩服务来说，应用程序实例在几个节点上同时运行。如果拥有全局接口的节点出现故障，全局接口将切换 到其他节点。如果一个正在运行的应用程序实例发生故障，则该实例尝试在同一节点上重新启动。
如果应用程序实例不能在同一节点上重新启动，而另一个未使用的节点被配置运行该服务，那么该服务会切换到 这个未使用的节点。否则，它继续运行在那些剩余节点上，并且很可能会降低服务吞吐量。
每个应用程序实例的 TCP 状态与该实例一起保存在此节点上，而不是在 GIF 节点上。因此，GIF 节点上的故障不影响连接。
9显示了失败切换和可伸缩资源组的一个实例，以及在它们之间存在的对于可伸缩服务 的依赖性。此实例显示了三个资源组。失败切换资源组包括高可用性的 DNS 应用程序资源和，以及由高可用的 DNS 和 Apache Web 服务器 共同使用的网络资源。可伸缩资源组仅包括 Apache Web 服务器应用程序实例。注意，资源组在可伸缩和失败切换资源组（实线）之间 存在依赖性，而所有的 Apache 应用程序资源都依赖于网络资源 schost-2，这是一个共享地址（虚线）。
群集联网的主要目标是为数据服务提供可伸缩性。可伸缩性意味着随着提供给服务的负载的增加，在新的节点被添加到 群集并运行新的服务器实例的同时，数据服务面对这种增加的工作负载能保持一个不变的响应时间。我们将这样的服务称为 可伸缩数据服务。Web 服务是可伸缩数据服务的一个很好的实例。通常，可伸缩数据服务由几个实例组成，每一个示例运行在 群集的不同节点上。这些实例在一起，作为来自该服务远程客户机的基准点的一个单独的服务，并实现该服务的功能。比如， 我们可能会有一个由几个 httpd 守护程序组成的 Web 服务，并且这些守护程序在不同的节点上 运行。任何 httpd 守护程序都服务于一个客户请求。服务于请求的守护程序依赖于负载 平衡策略。对客户机的回复看起来是来自该服务，而不是服务于请求的特定守护程序，从而保留单个服务的外观。
可伸缩服务由以下功能组成：
对可伸缩服务的联网基础结构支持
负载平衡
对联网和数据服务的 HA 支持（使用 Resource Group Manager）
下图描绘了可伸缩服务的体系结构。
当前不作为全局接口主机的节点（代理节点）与它们的回送接口共享地址。进入到 GIF 的软件包被分发到基于可配置 负载平衡策略的其他群集节点上。可能的负载平衡策略在下一步说明。
负载平衡在响应时间和吞吐量上同时提高了可伸缩服务的性能。
有两类可伸缩数据服务：纯粹和粘滞。纯粹服务 就是它的任何实例都可以对客户机的请求作出响应的服务。粘滞服务是客户机发送请求到相同实例的那种服务。那些请求不被重定向到其他实例。
纯粹服务使用加权的负载平衡策略。在这种负载平衡策略下，客户机请求按缺省方式被均衡地分配到群集内的 服务器实例之上。例如，在一个三节点群集中，让我们来假设每个节点的加权为 1。每个节点将代表该服务对所有客户机请求 的 1/3 进行服务。加权可以在任何时候由管理员通过 scrgadm(1M) 命令接口进行修改。
粘滞服务有两种风格，普通粘滞和通配粘滞。粘滞服务允许多个 TCP 连接 上并行的应用程序级会话来共享“状态内”内存（应用程序会话状态）。
普通粘滞服务允许客户机在多个并行的 TCP 连接之间共享状态。相对于正在监听单个端口的服务器实例，可以该客户机 说成是“粘滞的”。假定实例保持打开状态并可访问，并且在服务处于联机状态时负载平衡策略不 更改，将保证该客户机的所有服务请求都传给相同的服务器实例。
例如，客户机的 Web 浏览器连接到使用三种不同 TCP 连接，连接到端口为 80 的共享 IP 址，但连接在服务时正在它们之间 交换已缓存的会话信息。
粘滞策略的普遍化延伸到在相同实例场景后面交换会话信息的多个可伸缩服务。当这些服务在相同实例场景后面交换 会话信息时，相对于在不同端口上监听的相同节点上的多个服务器实例来说，可以说客户机是“粘滞的”。
例如在一个电子商务站点上，顾客使用端口 80 上的普通 HTTP 购买了许多商品并放入到购物车中，但是要切换到 端口 443 上的 SSL，以发送安全数据，使用信用卡付款。
通配粘滞服务使用动态分配的端口号，但仍期望客户机请求去往相同的节点。相对于相同的 IP 地址来说，客户机就是端口 上的“粘滞通配”。
被动模式 FTP 是这一策略的一个好例子。客户机连接到端口 21 上的 FTP 服务器，并接着被服务器通知须连接回到动态 端口范围中的收听器端口服务器。此 IP 地址的所有请求都被转发到服务器通过控制信息通知客户的相同节点上。
请注意，对于每个粘滞策略，加权的负载平衡策略都缺省生效的，从而使客户的最初请求被定向到由负载平衡程序指定的 实例。在客户机已经为正运行着实例的节点建立一种亲密关系 之后，只要该节点可访问并且负载平衡策略未更改，以后的请求就会定向到此实例。
关于特定的负载平衡策略的补充详细信息在下面进行讨论。
加权的. 根据指定的加权值在各种节点间分配负载。此策略是 使用 Load_balancing_weights 属性的 LB_WEIGHTED 值设 置的。如果一个节点的加权未明显地设置，则会使用此节点的缺省加权值 1。
注意这一策略不是循环共享的。循环共享策略总是会使来自客户机的每个请求到达不同的节点：第一个请求到达 节点 1，第二个请求到达节点 2，以此类推。这种加权策略保证了来自客户机的一定比例的流量直接到达特定的节点。此策略不对个别 请求寻址。
粘滞的. 在此策略中，端口的设置在配置应用程序资源时就已经知道了。此策 略是使用 Load_balancing_policy 资源属性的 LB_STICKY 值设置的。
粘滞通配符. 此策略是普通“粘滞”策略的超集。对于由 IP 地址识别的可伸缩服务，端口由服务器来 分配（并且事先不知道）。端口可能会变化。此策略是使用 Load_balancing_policy 资源属性 的 LB_STICKY_WILD 值设置的。
资源组从一个节点失败切换到另一个。您可以指定，如果一个资源组失败切换到另一个节点，在它先前在上面运行的那个节点 回到群集以后，它就会“失败返回”到原始的节点。这一选项是使用 Failback 资源组属性设置进行设定的。
在某些情况下，例如，如果以资源组为主机的原始节点正在重复地发生故障并重新引导，设置失败返回可能会导致资源组减少可用性。
每个 Sun Cluster 数据服务都提供一个故障监视器来定期探测数据服务，确定其是否完好。故障监视器检验应用程序守护程序 是否在运行并且客户机正在接受服务。基于由探测返回的信息，可以启动一些预定义的操作，比如重新启动守护程序或引起失败切换。
Sun 提供了软件使您能够使各种应用程序作为群集内的高可用数据服务运行。如果您想使之 作为一个高可用性服务运行的应用程序不是 Sun 当前提供的应用程序，则可以使用一个 API 或 DSDL API 来接受应用程序并 加以配置，使之作为一个高可用性应用程序运行。有两种数据服务风格，失败切换和可伸缩。有一套标准可以用来确定您的应用程序是否使用这些数据服务风格 中的一种。特定的标准在 Sun Cluster 文档中进行了描述，该文档说明您的应用程序可使用的 API。
这里，我们提出一些准则来帮助您了解您的服务是否可受益于可伸缩数据服务体系结构。有关可伸缩服务的更多基本信息， 请阅读 可伸缩数据服务。
满足下列准则的新服务可以利用可伸缩服务。如果现有的服务不完全符合这些准则，则可能 需要重写一些部分，使服务符合这些准则。
可伸缩数据服务具有以下特点。首先，这样的服务是由一个或多个 服务器实例组成的。每个实例运行在群集的不同节点上。同一服务的两个或更多实例不能在相同的 节点上运行。
其次，如果服务提供外部逻辑数据存储，那么从多个服务器实例对此存储的并行访问必须同步，以避免 丢失更新信息或在数据更改时读取数据。请注意，我们讲“外部的”是为了区分存储与“内存内”的状态，而讲“逻辑的”是 因为存储看起来象单独的实体，尽管它本身可能是复制的。此外，这种逻辑数据存储有这样的 属性，不论何时任何服务器实例更新该存储，其他实例会立即看到该更新。
Sun Cluster 通过它的群集文件系统和全局原始分区来提供这样一个外部存储器。又比如，假定一项服务将新数据写入外部日志文件，或修改在适当位置的现有数据。当此服务的多个实例运行 时，每个都可以访问此外部日志，并且可能会同时访问这一日志。每个实例必须同步其对日志的访问，否则这些实例就 会彼此干扰。此服务可以通过 fcntl(2) 和 lockf(3C) 来 使用普通的 Solaris 文件锁定，从而获取期望的同步。
关于这样存储的另一个实例是像高可用 Oracle 或 Oracle Parallel Server 那样的后端数据库。请注意，这样的后端数据库 服务器使用数据库查询或更新事务提供内置的同步，因此多个服务器实例不需要实现它们自己的同步。
Sun 的 IMAP 服务器是当前并不体现为可伸缩服务的一种服务实例。该服务更新一个存储，但那个存储是专用的，并且 当多个 IMAP 实例写入到这一存储时，它们因为更新没有被同步而相互覆盖。IMAP 服务器必须被重写以使并行访问同步。
最终，要注意一些实例可能会有从其他实例中脱离出来的专用数据。在此情况下，服务不需要关心它自身是否可以 使并行访问同步，因为数据是专用的，而且只有该实例可以操纵它。此时，您必须小心不要在群集文件系统下存储此 专用数据，因为它有变为全局访问的可能性。
Sun Cluster 提供以下组件以使应用程序具有高可用性：
作为 Sun Cluster 部件提供的数据服务
一个数据服务 API
一个数据服务开发库 API
一种“普通的”数据服务
Sun Cluster 3.0 Data Services Installation and Configuration Guide 介绍了如何安装和配置与 Sun Cluster 一起提供的数据服务。Sun Cluster 3.0 Data Services Developers' Guide 介绍了如何装备其他应用程序 以使它们在 Sun Cluster 框架下高度可用。
Sun Cluster API 和数据服务开发库 API 使应用程序编程人员能够开发故障监视器及编写启动和停止数据服务实例的脚本。有了这些 工具，应用程序就可以被装备成为一种失败切换或可伸缩的数据服务。另外，Sun Cluster 提供一 种“普通的”数据服务，这种服务可以用于快速生成应用程序所需的启动和停止方法，从而使它作为一种 高可用性的数据服务运行。
数据服务利用了几种类型的资源：诸 如 Apache Web Server 或 iPlanet Web Server 之类的应用程序利用它们所依赖的网络 地址（逻辑主机名和共享地址）。应用程序和网络资源组成由 RGM 管理的一个基本单元。
资源就是群集范围内定义的资源类型的实例化。有数种已定义的资源类型。
数据服务是资源类型。例如，Sun Cluster HA for Oracle 是 资源类型 SUNW.oracle，而 Sun Cluster HA for Apache 是资源类型 SUNW.apache。
网络资源或者是 SUNW.LogiclaHostname 资源类型，或者 是 SUNW.SharedAddress 资源类型。这两种资源类型已由 Sun Cluster 产品预注册。
SUNW.HAStorage 资源类型用于同步化资源和资源所依赖的磁盘设备组的 启动。它可确保在数据服务启动时，到群集文件系统安装点、全局设备和设备组名称的路径可用。
RGM 管理的资源被放入称作资源组的组中，因此他们可以作为一个单元管理。如果失败切换或 切换在资源组上启动，那么资源组就作为单元移植。
当您使一个包含应用程序资源的资源组联机时，应用程序便启动。数据服务启动方法会一直等待，直到 应用程序在成功退出前启动并运行。决定何时应用程序启动并运行的方法，与数据服务故障监视器决定数据服务是否正在 服务于客户机所采用的方法相同。有关此过程的详细信息，请参考 Sun Cluster 3.0 Data Services Installation and Configuration Guide。
您可以为您的 Sun Cluster 数据服务配置资源和资源组的属性值。标准属性集对所有数据服务是公共的，而扩展 属性集对每个数据服务是特定的。一些标准和扩展属性已配置为缺省值，因此您不必去修改它们。其他属性作为创建 和配置资源进程的一部分，需要进行设置。每个数据服务的文档指定了资源类型使用什么属性及如何配置它们。
标准属性用于配置那些通常独立于任何特定数据服务的资源和资源组属性。标准属性集在 Sun Cluster 3.0 Data Services Installation and Configuration Guide 的附录中有说明。
扩展属性提供应用程序二进制文件和配置文件的位置等信息。当您配置数据服务时，就修改 了扩展属性。扩展属性集在 Sun Cluster 3.0 Data Services Installation and Configuration Guide 中有关数据服务的单独的章节中说明。
客户机通过公共网络向群集提出数据请求。每个群集节点通过公共网络适配器至少连接到一个公共网络。
Sun Cluster 公共网络管理 (PNM) 软件提供了基本的机制来监视公共网络适配器，并在检测到故障时将 IP 地址从 一个适配器切换到另一个。每个群集节点有它自己的 PNM 配置，该配置可以与其他群集节点上的不同。
公共网络适配器被编入到 Network Adapter Failover 组（NAFO 组）。每个 NAFO 组有一个 或多个公共网络适配器。而在任何时候只有一个适配器对给定的 NAFO 组是活动的，在同一组中的更多适配器作为备份 适配器使用，活动适配器上的 PNM 守护程序一旦检测到故障，在适配器失败切换期间就使用这些备份适配器。失败切换使与 活动适配器相关联的 IP 地址被转移到备份适配器上，从而维持该节点的公共网络连通性。由于失败切换发生在适配器 接口级，像 TCP 这样的更高级别的连接则不受影响，仅在失败切换期间有短暂的瞬时延迟。
由于 TCP 的拥塞恢复特性，TCP 端点可以在成功的失败切换后经受更长的延迟，同时一些段可能会在 失败切换期间丢失，激活了 TCP 中的拥塞控制机制。
NAFO 组为逻辑主机名和共享地址资源提供了构件。scrgadm(1M) 命令在必要时自动 为您创建 NAFO 组。您也可以独立于逻辑主机名和共享地址资源来创建 NAFO 组，以监视群集节点的公共网络连通性。节点上相同 的 NAFO 组可以拥有任意数目的逻辑主机名或共享地址资源。有关逻辑主机名和共享地址的详细信息，请参见 Sun Cluster 3.0 Data Services Installation and Configuration Guide。
NAFO 机制的设计着意于检测和屏蔽适配器故障。该设计并不旨在使用 ifconfig(1M) 从 管理员那里恢复，以删除一个逻辑（或共享的）IP 地址。Sun Cluster 的设计将逻辑和共享 IP 地址视为由 RGM 管理 的资源。对于管理员来说，添加或删除 IP 地址的正确方法是使用 scrgadm(1M) 修改包含 资源的资源组。
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 系统管理指南 中关于更改 公共网络参数的步骤。
在 NAFO 组的活动适配器上检测到故障后，如果没有备份适配器可用，该组就被宣告“关闭”，同时继续对其所有备份 适配器的测试。然而，如果有备份适配器可用，就会进行失败切换，切换到该适配器。当故障活动适配器被关闭并且 不可查明时，逻辑地址和它们相关的标志被“转移”到备份适配器上。
当 IP 地址的失败切换成功完成时，就发送出无必要的 ARP 广播。因而也保持与远程客户机的连通。
