第 2 章 开发数据服务

本章介绍了有关开发数据服务的详细信息。

本章包含以下主题：

• 分析应用程序的适用性

• 确定要使用的接口

• 设置用来编写数据服务的开发环境

• 设置资源和资源类型特性

• 实现回调方法

• 普通数据服务

• 控制应用程序

• 监视资源

• 向资源添加消息日志

• 提供进程管理

• 提供资源的管理支持

• 实现故障转移资源

• 实现可伸缩资源

• 编写和测试数据服务

分析应用程序的适用性

创建数据服务的第一步是确定目标应用程序是否满足具有高可用性或可伸缩性的要求。如果该应用程序不满足所有要求，您可以修改应用程序的源代码，使其满足要求。

下表列出了要具有高可用性或可伸缩性的应用程序需要满足的要求。如果需要详细信息或需要修改应用程序源代码，请参见附录 B，数据服务样例代码列表。

要具有高可用性，可伸缩服务必须满足以下所有条件，同时还需满足一些附加条件。

• 在 Sun Cluster 环境中，支持网络（客户机服务器模型）的应用程序和不支持网络（无客户机）的应用程序都可以设置为具有高可用性或可伸缩性。但是在分时环境中，Sun Cluster 无法提供增强的可用性；在该环境中，应用程序在通过 telnet 或 rlogin 访问的服务器上运行。

• 该应用程序必须具有崩溃容限能力。也就是说，如果在节点发生意外毁坏的情况后启动应用程序，该应用程序必须能够在启动时恢复磁盘数据（如果有必要）。而且，崩溃后的恢复时间必须在限定范围内。崩溃容限是使应用程序具有高可用性的前提条件，因为恢复磁盘和重启应用程序的功能实质上是为了保持数据的完整性。不要求数据服务可以恢复连接。

• 应用程序不能依赖于它在其上运行的节点的物理主机名。有关其他信息，请参见主机名。

• 应用程序必须在配置为启用了多个 IP 地址的环境下正确操作。该环境可以是具有多头主机的环境，在该环境中节点位于多个公共网络中；或者是包含多个节点的环境，在节点上，一个硬件接口上配置启用多个逻辑接口。

• 要具有高可用性，应用程序数据必须驻留在群集文件系统中。请参见多主机数据。

  如果应用程序为该数据的位置使用硬连线路径名，您可以将该路径更改为指向群集文件系统中某个位置的符号链接，而无需更改应用程序源代码。有关其他信息，请参见将符号链接用于多主机数据放置。

• 应用程序二进制数和库都可以驻留在本地的每个节点上或群集文件系统上。将其驻留在群集文件系统上的优点在于进行单个安装就已足够。缺点在于滚动升级将成为问题，因为当应用程序在 RGM 的控制下运行时，二进制数正在使用。

• 客户机应该具有在首次查询尝试超时后自动重试的功能。如果应用程序和协议已经处理了单个服务器崩溃和重新引导的问题，则接下来将处理有关资源组进行故障转移或切换的问题。有关其他信息，请参见客户机重试。

• 应用程序在群集文件系统中不能具有 UNIX® 域套接字或命名管道。

此外，可伸缩服务还必须满足以下要求。

• 应用程序必须具有运行多个实例的能力，所有实例都在群集文件系统中相同的应用程序数据上进行操作。

• 应用程序必须保持数据一致性，以便从多个节点同时进行访问。

• 应用程序必须通过全局可视机制（例如群集文件系统）实现充分锁定。

对于可伸缩服务，应用程序的特征也可以确定负载平衡策略。例如，允许任意实例对客户机请求作出反应的负载平衡策略 LB_WEIGHTED 不适用于使用服务器内存中的缓存进行客户机连接的应用程序。在这种情况下，您应该指定一个负载平衡策略，以限制指定客户机到应用程序的一个实例的通信。负载平衡策略 LB_STICKY 和 LB_STICKY_WILD 将反复把客户机发出的所有请求发送到同一应用程序实例，在该实例中请求可以使用内存中的缓存。请注意，如果传入的多个客户机请求来自不同的客户机，RGM 将在服务的实例中分配这些请求。有关设置可伸缩数据服务的负载平衡策略的详细信息，请参见实现故障转移资源。

确定要使用的接口

Sun Cluster 开发者支持软件包 (SUNWscdev) 提供了两组用来对数据服务方法进行编码的接口：

• 资源管理 API (RMAPI)，一组低层次的例行程序（位于 libscha.so 库中）。

• 数据服务开发库 (DSDL)，一组较高层次的函数（位于 libdsdev.so 库中），用来封装 RMAPI 功能并提供一些附加功能。

Sun Cluster 开发者支持软件包中还提供了一个用来自动创建数据服务的工具 SunPlex Agent Builder。

建议在开发数据服务时采用的方法有：

1. 决定是在 C shell 中还是在 Korn shell 中进行编码。如果决定使用 Korn shell，则不能使用仅提供 C 接口的 DSDL。

2. 运行 Agent Builder，指定所请求的输入并生成数据服务，该服务中包括源代码和可执行代码、一个 RTR 文件和一个软件包。

3. 如果需要定制生成的数据服务，您可以向生成的源文件添加 DSDL 代码。Agent Builder 将通过注释指明源文件中可添加用户自己的代码的特定位置。

4. 如果需要进一步定制代码以支持目标应用程序，您可以向现有源代码添加 RMAPI 函数。

在实际情况中，您可以采用多种方法来创建数据服务。例如，除了向 Agent Builder 生成的代码中的特定位置添加自己代码的方法，您还可以用一个您使用 DSDL 或 RMAPI 函数从头编写的程序，完全替换所生成的方法之一或生成的监视程序。但是，无论采用哪种方法，绝大多数情况下都要使用 Agent Builder 开始进行操作，采用这种方法比较好，原因如下：

• Agent Builder 生成的代码（本质上是通用的）已在多种数据服务中进行测试。

• Agent Builder 将生成 RTR 文件、make 程序的描述文件和资源的软件包以及数据服务的其他支持文件。即使您没有使用任何数据服务代码，使用上述的其他文件也可以减少您相当一部分的工作量。

• 您可以修改生成的代码。

与 RMAPI 提供一组用于脚本的 C 函数和命令不同，DSDL 仅提供了一个 C 函数接口。因此，如果在 Agent Builder 中指定 Korn shell (ksh) 输出，生成的源代码将调用 RMAPI，因为没有 DSDL ksh 命令。

设置用来编写数据服务的开发环境

在开始进行数据服务开发之前，必须先安装 Sun Cluster 开发软件包 (SUNWscdev)，以便可以访问 Sun Cluster 头文件和库文件。虽然此软件包已安装在所有群集节点上，但是通常却在独立的非群集开发机器上进行开发，而不是在群集节点上进行。在通常情况下，您必须使用 pkgadd 在开发机器上安装 SUNWscdev 软件包。

当编译和链接代码时，您必须设置特定选项来标识头文件和库文件。

不可在 Solaris 操作系统和 Sun Cluster 产品中同时使用兼容模式编译的 C++ 代码和标准模式编译的 C++ 代码。因此，如果要创建在 Sun Cluster 上使用的基于 C++ 的数据服务，则必须按以下要求编译该数据服务：

• 对于 Sun Cluster 3.0 和早期版本，请使用兼容模式。

• 对于 Sun Cluster 3.1 和更高版本，请使用标准模式。

在非群集节点上完成开发后，您可以将完整的数据服务传送到群集，以便运行和测试。

请确保使用的是 Solaris 5.8 或更高版本的 Solaris 操作系统的开发者或完整分发软件组。

请使用本小节中的各个步骤执行以下操作：

• 安装 Sun Cluster 开发软件包 (SUNWscdev) 并设置相应的编译器和链接程序选项

• 将数据服务传送到群集

设置开发环境

此步骤介绍了如何安装 SUNWscdev 软件包和设置用于数据服务开发的编译器和链接程序选项。

1. 成为超级用户或采用等效角色并将目录更改为所需的 CD-ROM 目录。

   # cd CD-ROM_directory

2. 在当前目录下安装 SUNWscdev 软件包。

   # pkgadd -d . SUNWscdev

3. 在 Makefile 中，指定用于标识数据服务代码的包含文件和库文件的编译器和链接程序选项。

   指定 -I 选项，用于标识 Sun Cluster 头文件；指定 -L 选项，用于指定开发系统上的编译时库搜索路径；指定 -R 选项，用于指定指向群集上运行时链接程序的库搜索路径。

   # Makefile for sample data service
   ... 
   
   -I /usr/cluster/include
   
   -L /usr/cluster/lib
   
   -R /usr/cluster/lib
   ... 

将数据服务传送到群集

在开发机器上完成数据服务的开发后，您必须将其传送到群集以进行测试。要降低发生错误的几率，最好是先将数据服务代码和 RTR 文件打包，然后再将软件包安装在群集的所有节点上来完成此传送过程。

无论是使用 pkgadd 还是其他方法来安装数据服务，都必须将数据服务安装在所有群集节点上。Agent Builder 将自动把 RTR 文件和数据服务代码打包。

设置资源和资源类型特性

Sun Cluster 提供了一组用来定义数据服务静态配置的资源类型特性和资源特性。资源类型特性用来指定资源的类型及其版本、API 的版本等，还可以用来指定指向每个回调方法的路径。资源类型特性中列出了所有的资源类型特性。

资源特性（例如，Failover_mode、Thorough_probe_interval）和方法超时也定义该资源的静态配置。动态资源特性（例如 Resource_state 和 Status）反映被管理资源的活动状态。资源特性中介绍了各种资源特性。

资源类型和资源特性在资源类型注册 (RTR) 文件中声明，该文件是数据服务的基本组件。RTR 文件用来在群集管理员使用 Sun Cluster 注册数据服务时定义数据服务的初始配置。

建议您使用 Agent Builder 生成数据服务的 RTR 文件，因为 Agent Builder 声明了一组对于任何数据服务来说既有用又必需的特性。例如，有些特性（如 Resource_type）必须在 RTR 文件中声明，否则数据服务的注册将失败。其他特性尽管没有此方面的要求，但如果不在 RTR 文件中声明，系统管理员也还是无法使用它们；而某些特性无论是否进行了声明都可以使用，这是因为 RGM 对它们进行了定义并为其提供了缺省值。要避免发生这种复杂的情况，您只需使用 Agent Builder，以确保生成适当的 RTR 文件。如果需要，今后您可以编辑该 RTR 文件，以更改具体值。

本小节的其余内容介绍了 Agent Builder 创建的 RTR 文件样例 。

声明资源类型特性

群集管理员无法配置您在 RTR 文件中声明的资源类型特性。这些特性将成为永久资源类型配置中的一部分。

资源类型特性 Installed_nodes 可由系统管理员配置。实际上，此特性只能由系统管理员配置，而您无法在 RTR 文件中对其进行声明。

资源类型声明的语法为：

property_name = value;

RGM 认为特性名是不区分大小写的。由 Sun 提供的 RTR 文件中的特性名称约定是将名称的首字母大写，其余字母小写（方法名除外）。方法名以及特性的属性中包含的都是大写字母。

下面是 (smpl) 数据服务样例 的 RTR 文件中的资源类型声明：

# Sun Cluster Data Services Builder template version 1.0
# Registration information and resources for smpl
#
#NOTE: Keywords are case insensitive, i.e., you can use
#any capitalization style you prefer.
#
Resource_type = "smpl";
Vendor_id = SUNW;
RT_description = "Sample Service on Sun Cluster";

RT_version ="1.0"; 
API_version = 2;
Failover = TRUE;

Init_nodes = RG_PRIMARIES;

RT_basedir=/opt/SUNWsmpl/bin;

Start           =    smpl_svc_start;
Stop            =    smpl_svc_stop;

Validate        =    smpl_validate;
Update          =    smpl_update;

Monitor_start   =    smpl_monitor_start;
Monitor_stop    =    smpl_monitor_stop;
Monitor_check   =    smpl_monitor_check;

您必须将 Resource_type 特性声明为 RTR 文件中的第一个条目。否则，资源类型的注册将失败。

第一组资源类型声明可提供有关资源类型的基本信息，如下所示：

Resource_type 和 Vendor_id

提供资源类型的名称。您可以仅使用 Resource_type 特性指定资源类型名称 (smpl)，或者使用 Vendor_id 作为前缀，并与资源类型之间用“.”分隔 (SUNW.smpl)，如样例中所示。如果使用 Vendor_id，请将其设置为用来定义资源类型的公司的股票代号。在群集中资源类型的名称必须唯一。

---

注意 –

按照约定，资源类型名称 (Resource_typeVendor_id) 用作软件包名称。尽管 RGM 没有强制要求进行限制，但因为软件包名称的字符数不能超过九个，因此将这两个特性的字符总数限制在九个或更少字符数以内不失为一种好方法。另一方面，Agent Builder 将明确地根据该资源类型名称生成软件包名称，因此它要强制执行九个字符数限制。

---

RT_version

用于标识数据服务样例的版本。

API_version

用于标识 API 的版本。例如，API_version = 2 表明数据服务在 Sun Cluster 3.0 版本中运行。

Failover = TRUE

表明数据服务无法在可同时在多个节点上联机的资源组中运行，即指定了一个故障转移数据服务。有关详细信息，请参见将数据服务传送到群集。

Start、Stop、Validate 等

提供指向由 RGM 调用的各个回调方法程序的路径。这些路径是基于 RT_basedir 所指定的目录的相对路径。

其余的资源类型声明用于提供配置信息，如下所示：

Init_nodes = RG_PRIMARIES

指定 RGM 仅对可以控制数据服务的节点调用 Init、Boot、Fini 和 Validate 方法。由 RG_PRIMARIES 指定的节点是安装有数据服务的所有节点的一个子集。将值设置为 RT_INSTALLED_NODES 可指定 RGM 对安装有数据服务的所有节点调用这些方法。

RT_basedir

指向 /opt/SUNWsample/bin，作为指向完整相对路径（例如回调方法路径）的目录路径。

Start、Stop、Validate 等

提供指向由 RGM 调用的各个回调方法程序的路径。这些路径是基于 RT_basedir 所指定的目录的相对路径。

声明资源特性

与资源类型特性一样，资源特性也在 RTR 文件中声明。按照约定，在 RTR 文件中资源特性声明位于资源类型声明之后。资源声明的语法是一组用花括号括起来的属性值对：

{
    Attribute = Value;
    Attribute = Value;
             .
             .
             .
    Attribute = Value;
}

对于由 Sun Cluster 提供的资源特性，即所谓系统定义的特性，您可以在 RTR 文件中更改具体属性。例如，Sun Cluster 为每个回调方法提供方法超时特性，并指定缺省值。在 RTR 文件中，您可以指定各种缺省值。

您也可以使用一组由 Sun Cluster 提供的特性属性，在 RTR 文件中定义新的资源特性，即所谓的扩展特性。资源特性属性中列出了用于更改和定义资源特性的属性。在 RTR 文件中，扩展特性声明位于系统定义的特性声明之后。

第一组系统定义的资源特性用于指定回调方法的超时值：

...

# Resource property declarations appear as a list of bracketed
# entries after the resource type declarations. The property 
# name declaration must be the first attribute after the open
# curly bracket of a resource property entry.
#
# Set minimum and default for method timeouts.
{
        PROPERTY = Start_timeout;
        MIN=60;
        DEFAULT=300;
}

{
        PROPERTY = Stop_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Validate_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Update_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Start_timeout;
        MIN=60;
        DEFAULT=300;
}
{
        PROPERTY = Monitor_Stop_timeout;
        MIN=60;
        DEFAULT=300;
{
        PROPERTY = Monitor_Check_timeout;
        MIN=60;
        DEFAULT=300;
}

特性的名称 (PROPERTY = value) 必须是所有资源特性声明中的第一个属性。您可以在根据 RTR 文件中的特性属性定义的限制范围内配置资源特性。例如，样例中每个方法超时的缺省值都是 300 秒。管理员可以更改此值；但是 MIN 属性指定的最小允许值为 60 秒。资源特性属性中包含一个资源特性属性的列表。

下一组资源特性用于定义在数据服务中有特定用法的特性。

{
        PROPERTY = Failover_mode;
        DEFAULT=SOFT;
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Thorough_Probe_Interval;
        MIN=1;
        MAX=3600;
        DEFAULT=60;
        TUNABLE = ANYTIME;
}

# The number of retries to be done within a certain period before concluding 
# that the application cannot be successfully started on this node.
{
        PROPERTY = Retry_Count;
        MAX=10;
        DEFAULT=2;
        TUNABLE = ANYTIME; 
}

# Set Retry_Interval as a multiple of 60 since it is converted from seconds
# to minutes, rounding up. For example, a value of 50 (seconds)
# is converted to 1 minute. Use this property to time the number of 
# retries (Retry_Count).
{
        PROPERTY = Retry_Interval;
        MAX=3600;
        DEFAULT=300;
        TUNABLE = ANYTIME;
}

{
        PROPERTY = Network_resources_used;
        TUNABLE = WHEN_DISABLED;
        DEFAULT = "";
}
{
        PROPERTY = Scalable;
        DEFAULT = FALSE;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_policy;
        DEFAULT = LB_WEIGHTED;
        TUNABLE = AT_CREATION;
}
{
        PROPERTY = Load_balancing_weights;
        DEFAULT = "";
        TUNABLE = ANYTIME;
}
{
        PROPERTY = Port_list;
        TUNABLE = AT_CREATION;
        DEFAULT = ;
}

这些资源特性声明将添加 TUNABLE 属性，该属性用于限制系统管理员在什么情况下可以更改特性值。AT_CREATION 表明管理员只能在创建资源时指定该值，并且今后无法进行更改。

对于其中大多数特性，您可以接受当 Agent Builder 生成这些特性时所具有的缺省值，除非您有理由进行更改。以下是有关这些特性的信息（其他信息请参见资源特性或 r_properties(5) 手册页）：

Failover_mode

表明在 Start 或 Stop 方法失败的情况下，RGM 是应该重定位资源组还是应该终止该节点。

Thorough_probe_interval、Retry_count、Retry_interval

用于故障监视器。如果 Tunable 的值等于 ANYTIME，则系统管理员可以在故障监视器不能达到最佳工作效果时调整这些特性。

Network_resources_used

数据服务使用的逻辑主机名或共享地址资源的列表。Agent Builder 将声明此特性，因此配置数据服务时，系统管理员可以指定资源列表（如果有）。

Scalable

设置为 FALSE 可表明此资源不使用群集联网（共享地址）工具。此设置与设为 TRUE 的资源类型 Failover 特性相符，用来表明故障转移服务。有关如何使用此特性的其他信息，请参见将数据服务传送到群集和实现回调方法。

Load_balancing_policy、Load_balancing_weights

将自动声明这些特性，但是在故障转移资源类型中不能发挥作用。

Port_list

标识服务器侦听的端口的列表。Agent Builder 将声明此特性，因此系统管理员可以在配置数据服务时指定端口列表。

声明扩展特性

位于 RTR 文件样例结尾处的是扩展特性，如下所示：

# Extension Properties
#

# The cluster administrator must set the value of this property to point to the 
# directory that contains the configuration files used by the application. 
# For this application, smpl, specify the path of the configuration file on 
# PXFS (typically named.conf).
{
        PROPERTY = Confdir_list;
        EXTENSION;
        STRINGARRAY;
        TUNABLE = AT_CREATION;
        DESCRIPTION = "The Configuration Directory Path(s)";
}

# The following two properties control restart of the fault monitor.
{
        PROPERTY = Monitor_retry_count;
        EXTENSION;
        INT;
        DEFAULT = 4;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Number of PMF restarts allowed for fault monitor.";
}
{
        PROPERTY = Monitor_retry_interval;
        EXTENSION;
        INT;
        DEFAULT = 2;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time window (minutes) for fault monitor restarts.";
}
# Time out value in seconds for the probe.
{
        PROPERTY = Probe_timeout;
        EXTENSION;
        INT;
        DEFAULT = 120;
        TUNABLE = ANYTIME;
        DESCRIPTION = "Time out value for the probe (seconds)";
}

# Child process monitoring level for PMF (-C option of pmfadm).
# Default of -1 means to not use the -C option of pmfadm.
# A value of 0 or greater indicates the desired level of child-process.
# monitoring.
{
        PROPERTY = Child_mon_level;
        EXTENSION;
        INT;
        DEFAULT = -1;
        TUNABLE = ANYTIME;
        DESCRIPTION = “Child monitoring level for PMF";
}
# User added code -- BEGIN VVVVVVVVVVVV
# User added code -- END   ^^^^^^^^^^^^

Agent Builder 创建了一些对大多数的数据服务都有用的扩展特性，如下所示。

Confdir_list

指定应用程序配置目录的路径，这对于很多应用程序是有用的信息。配置数据服务时，系统管理员可以提供此目录的位置。

Monitor_retry_count、Monitor_retry_interval、Probe_timeout

用于控制故障监视器本身的重启操作，而不是服务器守护程序的重启操作。

Child_mon_level

用于设置 PMF 要完成的监视操作的级别。有关详细信息，请参见 pmfadm(1M)。

您可以在以 User added code 注释分隔的区域内创建其他扩展特性。

实现回调方法

本小节介绍了有关实现回调方法的信息。

访问资源和资源组特性信息

一般情况下，回调方法需要对资源的特性进行访问。RMAPI 同时提供了可在回调方法中使用的 shell 命令和 C 函数，以访问系统定义的资源特性和扩展资源特性。请参见 scha_resource_get(1HA) 和 scha_resource_get(3HA) 手册页。

DSDL 提供了一组用来访问系统定义的特性的 C 函数（一种特性对应一种函数），还提供了一种用来访问扩展特性的函数。请参见 scds_property_functions(3HA) 和 scds_get_ext_property(3HA) 手册页。

您无法使用特性机制来存储数据服务的动态状态信息，因为没有可用于设置资源特性（除了 Status 和 Status_msg）的 API 函数。您应该将动态状态信息存储在全局文件中。

使用 scrgadm 命令，或者通过可用的图形管理命令或图形管理界面，群集管理员可以设置某些资源特性。但是，请勿从任何回调方法中调用 scrgadm，因为 scrgadm 将在重新配置群集过程中（即当 RGM 调用方法时）失败。

方法的幂等性

通常情况下，RGM 不会使用相同的参数对同一资源连续多次调用某个方法。但是，如果 Start 方法失败了，即使从未启动过该资源，RGM 也会对其调用 Stop 方法。同样地，如果资源守护程序主动停止运行，RGM 可能仍会对该程序调用 Stop 方法。相同的情况也适用于 Monitor_start 和 Monitor_stop 方法。

因为这些原因，您必须在 Stop 和 Monitor_stop 方法中内置幂等性。使用相同参数对同一资源重复调用 Stop 或 Monitor_stop 的结果与进行单一调用的结果相同。

幂等性的一个含义是使 Stop 和 Monitor_stop 必须返回 0（成功），即使这时资源或监视器已经停止并且无工作要完成。

Init、Fini、Boot 和 Update 方法也必须具有幂等性。Start 方法无需具有幂等性。

普通数据服务

普通数据服务 (GDS) 是一种使简单的应用程序具有高可用性或可伸缩性的机制，方法是将应用程序插入到 Sun Cluster 资源组管理器框架中。此机制不需要为代理编写代码，而编写代码是使应用程序具有高可用性或可伸缩性的通常做法。

GDS 模型依赖于预先编译的资源类型 SUNW.gds，以与 RGM 框架进行交互操作。

有关其他信息，请参见第 10 章，普通数据服务。

控制应用程序

每当节点加入或退出群集时，回调方法将启用 RGM 来控制基础资源（应用程序）。

启动和停止资源

资源类型实现至少需要使用 Start 方法和 Stop 方法。RGM 将以适当的次数对适当的节点调用资源类型的方法程序，以使资源组脱机或联机。例如，群集节点崩溃后，RGM 将把该节点控制的所有资源组移到新的节点上。您必须实现 Start 方法，以通过重启未崩溃主机节点上每个资源的方法来提供 RGM。

在资源启动并可用于本地节点之前不能返回 Start方法。请确保需要较长初始化时间的资源类型在其 Start 方法中设置了足够的超时值（在资源类型注册文件中设置 Start_timeout 特性的缺省值和最小值）。

在 RGM 使资源组脱机的情况下，您必须实现 Stop 方法。例如，假设某个资源组在 Node1 上脱机，在 Node2 上恢复联机。当使资源组脱机时，RGM 对组中的资源调用 Stop 方法以停止 Node1 上的所有活动。当在 Node1 上对所有资源执行完 Stop 方法后，RGM 将使资源组在 Node2 上恢复联机。

在资源完全停止本地节点上的所有活动并完全关闭之前，Stop 方法不能返回。Stop 方法的最安全实现操作将终止与该资源相关的本地节点上的所有进程。应该在需要较长时间进行关闭的资源类型的 Stop 方法中为其设置足够的超时值。在资源类型注册文件中设置 Stop_timeout 特性。

Stop 方法的失败和超时将导致资源组进入需要操作员介入的错误状态。要避免进入这种状态，Stop 和 Monitor_stop 方法实现应该尝试从所有可能出错的情况下恢复。理想的情况是，成功地停止本地节点上的资源及其监视器的所有活动之后，这些方法将在 0（成功）错误状态下退出。

决定使用哪种 Start 或 Stop 方法

本节将对照 Prenet_start 和 Postnet_stop 方法的使用，介绍一些有关何时使用 Start 和 Stop 方法的提示。要正确决定要使用的方法，您必须对客户机和数据服务的客户机服务器网络协议有深入的了解。

使用网络地址资源的服务可能需要按照与逻辑主机名地址配置相关的特定顺序来执行启动或停止步骤。可选的回调方法 Prenet_start 允许资源类型实现在将同一资源组中的网络地址配置为启用之前执行特定的启动操作，而可选的回调方法 Postnet_stop 允许资源类型实现在将同一资源组中的网络地址配置为关闭之后执行特定的关闭操作。

在调用数据服务的 Prenet_start 方法之前，RGM 调用检测网络地址（但不将网络地址配置为启用）的方法。在调用数据服务的 Postnet_stop 方法之后，RGM 调用不检测网络地址的方法。RGM 使资源组联机的顺序如下。

1. 检测网络地址。

2. 调用数据服务的 Prenet_start 方法（如果有）。

3. 将网络地址配置为启用。

4. 调用数据服务的 Start 方法（如果有）。

RGM 使资源组脱机时采用相反的顺序：

1. 调用数据服务的 Stop 方法（如果有）。

2. 将网络地址配置为关闭。

3. 调用数据服务的 Postnet_stop 方法（如果有）。

4. 取消检测网络地址。

当决定是否使用 Start、Stop、Prenet_start 或 Postnet_stop 方法时，首先要考虑服务器端。当使同时包含数据服务应用程序资源和网络地址资源的资源组联机时，RGM 将在调用该数据服务资源的 Start 方法之前，调用用来将网络地址配置为启用的方法。因此，如果数据服务需要在启动时将网络地址配置为启用，请使用 Start 方法启动该数据服务。

同样，当使同时包含数据服务资源和网络地址资源的资源组脱机时，RGM 将在调用数据服务资源的 Stop 方法之后，调用用来将网络地址配置为关闭的方法。因此，如果数据服务需要在停止时将网络地址配置为关闭，请使用 Stop 方法来停止该数据服务。

例如，要启动或停止数据服务，您可能需要调用该数据服务的管理实用程序或库。有时，数据服务具有使用客户机服务器网络接口进行管理的管理实用程序或库。即管理实用程序将调用服务器守护程序，因此可能需要将网络地址配置为启用来使用管理实用程序或库。在这种情况下请使用 Start 和 Stop 方法。

如果数据服务需要在启动和停止时将网络地址配置为关闭，请使用 Prenet_start 和 Postnet_stop 方法来启动和停止该数据服务。请考虑在进行群集重新配置（带有 SCHA_GIVEOVER 参数的 scha_control() 或带有 scswitch 命令的切换）之后，网络地址还是数据服务首先联机的不同情况会不会使客户机软件作出不同反应。例如，客户机实现可能进行最小限度的重试，当确定数据服务端口不可用后将立即放弃重试。

如果数据服务不需要在启动时将网络地址配置为启用，请在将网络接口配置为启用之前启动该数据服务。这样可以确保数据服务在完成将网络地址配置为启用后，立刻对客户机的请求作出反应，并且客户机不太可能停止重试。在这种情况下，请不要使用 Start 方法，最好使用 Prenet_start 方法来启动数据服务。

如果使用 Postnet_stop 方法，在将网络地址配置为关闭时，数据服务资源仍然可用。只有在网络地址配置为关闭后，才会调用 Postnet_stop 方法。结果是，数据服务的 TCP 或 UDP 服务端口或其 RPC 程序号似乎始终可以供网路上的客户机使用（除了该网络地址也未作出反应的情况）。

如果在群集上安装 RPC 服务，则此服务不能使用以下程序编号：100141、100142 和 100248。这些编号分别专用于 Sun Cluster 守护进程 rgmd_receptionist、fed 和 pmfd。如果您安装的 RPC 服务使用了以上这些程序编号之一，则必须将 RPC 服务更改为使用不同于以上编号的其他程序编号。

与使用 Prenet_start 和 Postnet_stop 方法相比，决定使用 Start 和 Stop 方法时，或决定同时使用这两套方法时，必须将服务器和客户机的要求和行为方式都考虑在内。

Init、Fini 和 Boot 方法

Init、Fini 和 Boot 这三种可选方法可启用 RGM 对资源执行初始化和终止代码。当资源处于被管理状态时（一种情况是该资源所在的资源组从非管理状态切换为被管理状态时，另一种情况是该资源在已处于被管理状态下的资源组中创建时），RGM 将调用 Init 方法对该资源执行一次性初始化。

当资源处于非管理状态时（一种情况是该资源所在的资源组切换为非管理状态时，另一种情况是该资源从被管理资源组中删除时），RGM 将调用 Fini 方法清除该资源。清除操作必须具有幂等性，即如果已执行了清除操作，Fini 将在返回 0（成功）的情况下退出。

RGM 将对新加入群集的节点（即已对该节点进行了引导或重新引导操作）调用 Boot 方法。

使用 Boot 方法执行的初始化操作通常与使用 Init 执行的初始化操作相同。此初始化操作必须具有幂等性，即如果该资源已在本地节点上进行了初始化，Boot 和 Init 将在返回 0（成功）的情况下退出。

监视资源

通常需要使用监视器，以对资源运行周期性故障探测程序来检测所测的资源是否工作正常。如果故障探测程序失败，监视器可尝试在本地进行重启，或通过调用 scha_control () RMAPI 函数或 scds_fm_action() DSDL 函数请求对受影响的资源组进行故障转移。

您也可以监视资源的性能并进行调节或报告性能。是否编写特定于资源类型的故障监视器完全是可选的操作。即使您选择不编写故障监视器，Sun Cluster 本身进行的基本群集监视操作也会为资源类型带来好处。Sun Cluster 将检测主机硬件的故障、主机操作系统的严重故障以及主机的故障，以便可以在其公共网络上进行通信。

尽管 RGM 并不直接调用资源监视器，但它为资源提供了自动启动的监视器。当使资源脱机时，RGM 将在停止资源本身之前，调用 Monitor_stop 方法来停止该资源在本地节点上的监视器。当使资源联机时，RGM 将在启动资源本身之后调用 Monitor_start 方法。

scha_control() RMAPI 函数和 scds_fm_action() DSDL 函数（它调用 scha_control()）允许资源监视器向其他节点发出资源组的故障转移请求。作为一种合理性检查，scha_control() 将调用 Monitor_check（如果进行了定义）来确定被请求节点在控制包含该资源的资源组方面是否可靠。如果 Monitor_check 报告该节点不可靠或方法超时，RGM 将寻找其他节点来接受故障转移请求。如果 Monitor_check 在所有节点上都失败，将取消故障转移。

资源监视器可以设置 Status 和 Status_msg 特性来反映监视器所检测到的资源状态。请使用 RMAPI scha_resource_setstatus() 函数或 scha_resource_setstatus 命令或 DSDL scds_fm_action() 函数来设置这些特性。

尽管对于资源监视器来说，Status 和 Status_msg 具有特定的作用，但是也可以使用任意程序来设置这些特性。

要获得使用 RMAPI 实现的故障监视器实例，请参见定义故障监视器。要获得使用 DSDL 实现的故障监视器实例，请参见SUNW.xfnts 故障监视器。有关在 Sun 提供的数据服务中内置的故障监视器的信息，请参见《Sun Cluster 数据服务规划和管理指南（适用于 Solaris OS）》。

向资源添加消息日志

如果您希望将状态消息记录到记录其他群集消息的同一个日志文件中，请使用方便的函数 scha_cluster_getlogfacility() 来检索用来记录群集消息的工具号。

使用此工具号和常规的 Solaris syslog() 函数将消息写入群集日志。您也可以通过普通的 scha_cluster_get() 接口访问群集日志工具信息。

提供进程管理

RMAPI 和 DSDL 提供了进程管理工具来实现资源监视器及资源控制回调。RMAPI 定义了以下工具（有关其中每一个命令和程序的详细信息，请参见手册页）：

进程监视工具：pmfadm 和 rpc.pmfd

进程监视工具 (PMF)，提供了一种用来监视进程及其子进程以及在失败后重启进程的方法。该工具由 pmfadm 命令（用于启动和控制被监视的进程）和 rpc.pmfd 守护程序组成。

halockrun

一种用于在保留文件锁定时运行子程序的程序。此命令在 shell 脚本中使用很方便。

hatimerun

一种用于在超时控制下运行子程序的程序。此命令在 shell 脚本中使用很方便。

DSDL 提供了用于实现 hatimerun 功能的 scds_hatimerun 函数。

DSDL 提供了一组用来实现 PMF 功能的函数 (scds_pmf_*)。有关 DSDL PMF 功能的概述和各种函数的列表，请参见PMF 函数。

提供资源的管理支持

对资源进行的管理操作包括设置和更改资源特性。API 定义了 Validate 和 Update 回调方法，因此您可以钩住这些管理操作。

当创建资源时以及通过管理操作更新资源特性或其包含的资源组时，RGM 将调用可选的 Validate 方法。RGM 将把该资源及其资源组的特性值传送到 Validate 方法。RGM 将对由该资源类型的 Init_nodes 特性指定的那组群集节点调用 Validate。（有关 Init_nodes 的信息，请参见资源类型特性或 rt_properties(5) 手册页）。在进行创建或更新之前，RGM 将调用 Validate，而来自位于任意节点上的方法的故障出口代码将导致创建或更新操作失败。

仅当通过管理操作更改资源或组特性时（而不是在 RGM 设置特性时或监视器设置资源特性 Status 和 Status_msg 时），RGM 才调用 Validate。

RGM 将调用可选的 Update 方法来通知运行的资源已对特性进行了更改。在设置资源及其组的特性过程中成功地执行了管理操作后，RGM 将调用 Update。RGM 将对资源处于联机状态的节点调用此方法。此方法可用来通过 API 访问函数读取可能会影响活动资源的特性值，并相应地调整运行资源。

实现故障转移资源

故障转移资源组中包含网络地址（例如内置资源类型逻辑主机名和共享地址）和故障转移资源（例如故障转移数据服务的数据服务应用程序资源）。当数据服务发生故障转移或进行切换时，网络地址资源及其相关的数据服务资源将在群集节点间移动。RGM 提供了多个支持故障转移资源实现的特性。

将布尔资源类型特性 Failover 设置为 TRUE 可以限制资源，避免它在可同时在多个节点上处于联机状态的资源组中进行配置。此特性缺省为 FALSE，因此您必须在 RTR 文件中将其声明为 TRUE，以用于故障转移资源。

Scalable 资源特性用来确定该资源是否使用群集共享地址工具。对于故障转移资源，请将 Scalable 设置为 FALSE，因为故障转移资源不使用共享地址。

RG_mode 资源组特性允许群集管理员将资源组标识为故障转移或可伸缩。如果 RG_mode 的值为 FAILOVER，RGM 将把该组的 Maximum_primaries 特性设置为 1，并将该资源组限制为由单个节点控制。RGM 不允许在 RG_mode 的值为 SCALABLE 的资源组中创建 Failover 特性是 TRUE 的资源。

Implicit_network_dependencies 资源组特性用来指定 RGM 应该对组内所有网络地址资源（逻辑主机名和共享地址）强制执行非网络地址资源的隐含强依赖性。这意味着将组中的网络地址配置为启用之前，组中的非网络地址（数据服务）资源不会调用其 Start 方法。Implicit_network_dependencies 特性值缺省为 TRUE。

实现可伸缩资源

可伸缩资源可以同时在多个节点上处于联机状态。可伸缩资源包括数据服务，例如，Sun Cluster HA for Sun Java System Web Server（以前称为 Sun Cluster HA for Sun ONE Web Server）和 Sun Cluster HA for Apache。

RGM 提供了许多支持可伸缩资源实现的特性。

相应地将布尔资源类型特性 Failover 设置为 FALSE，允许在可同时在多个节点上处于联机状态的资源组中配置资源。

Scalable 资源特性用来确定该资源是否使用群集共享地址工具。请将此特性设置为 TRUE，因为可伸缩服务使用共享地址资源，以将该可伸缩服务的多个实例作为单个服务向客户机显示。

RG_mode 特性使群集管理员可以将资源组标识为故障转移或可伸缩。如果 RG_mode 的值是 SCALABLE，RGM 允许 Maximum_primaries 的值大于 1，这意味着该组可同时由多个节点控制。RGM 允许 Failover 特性值是 FALSE 的资源在 RG_mode 的值是 SCALABLE 的资源组中实例化。

群集管理员将创建一个用来包含可伸缩服务资源的可伸缩资源组，还会创建一个用来包含可伸缩资源所依赖的共享地址资源的单独故障转移资源组。

群集管理员使用 RG_dependencies 资源组特性来指定在节点上使资源组联机和脱机的顺序。此顺序对于可伸缩服务很重要，因为可伸缩资源和其依赖的共享地址资源位于不同的资源组中。可伸缩数据服务需要在启动前将其网络地址（共享地址）资源配置为启用。因此，管理员必须设置包含可伸缩服务的资源组的 RG_dependencies 特性，以包括含有共享地址资源的资源组。

当您在 RTR 文件中为资源声明 Scalable 特性时，RGM 将自动为该资源创建以下一组可伸缩特性：

Network_resources_used

用来标识此资源使用的共享地址资源。此特性缺省为空字符串，因此群集管理员在创建资源时，必须提供可伸缩服务所使用的共享地址的实际列表。scsetup 命令和 SunPlex Manager 为可伸缩服务提供了自动设置所需资源和组的功能。

Load_balancing_policy

用来指定资源的负载平衡策略。您可以在 RTR 文件中明确地设置该策略（或使用缺省值 LB_WEIGHTED）。在每一种情况下，群集管理员都可以在创建资源时更改该值（除非您在 RTR 文件中将 Load_balancing_policy 的 Tunable 设置为 NONE 或 FALSE）。有效值为：

LB_WEIGHTED

根据在 Load_balancing_weights 特性中设置的权重在不同的节点间分配负载。

LB_STICKY

可伸缩服务的指定客户机（由客户机的 IP 地址标识）总是发送到群集的相同节点。

LB_STICKY_WILD

连接到通配符粘性服务的 IP 地址的给定客户机（由客户机的 IP 地址标识）总是发送到同一群集节点，而不管其定向到哪个端口号。

对于使用 Load_balancing_policy LB_STICKY 或 LB_STICKY_WILD 的可伸缩服务，在服务联机时更改 Load_balancing_weights 可能造成复位现有客户机关系。在这种情况下，一个不同的节点可能会处理后面的客户机请求（即使原来是由该群集中另一个节点处理客户机请求）。

同样地，在群集上启动该服务的新实例可能也会重置现有的客户机关系。

Load_balancing_weights

用来指定要分配给每个节点的负载。格式为 weight@node,weight@node，其中 weight 是一个反映分配到指定 node 的相对负载部分的整数。分配到某个节点的负载部分是此节点的权重除以活动实例的所有权重的和。例如，1@1,3@2 表明节点 1 接收到 1/4 的负载，而节点 2 接收到 3/4 的负载。

Port_list

用来标识服务器所侦听的端口。此特性缺省为空字符串。您可以在 RTR 文件中提供端口列表。否则，群集管理员在创建资源时必须提供实际端口列表。

您可以创建可由管理员配置为可伸缩或故障转移的数据服务。要进行此操作，请在数据服务的 RTR 文件中将 Failover 资源类型特性和 Scalable 资源特性都声明为 FALSE。创建时请将 Scalable 特性指定为可调。

Failover 特性值 (FALSE) 允许将资源配置到可伸缩资源组中。通过在创建资源时将 Scalable 的值更改为 TRUE，管理员可以启用共享地址，这样便创建了可伸缩服务。

从另一方面来说，即使将 Failover 的值设置为 FALSE，管理员也可以将资源配置到故障转移资源组中，以实现故障转移服务。管理员无需更改值为 FALSE 的 Scalable。要支持此操作，您必须对 Scalable 特性的 Validate 方法进行检查。如果 Scalable 的值是 FALSE，请检验是否已将该资源配置到故障转移资源组中。

《Sun Cluster 概念指南（适用于 Solaris OS）》中包含了有关可伸缩资源的其他信息。

可伸缩服务的验证检查

每当在将可伸缩特性值设置为 TRUE 的情况下创建资源或更新资源时，RGM 都将验证各种资源特性。如果特性值未正确配置，RGM 将拒绝更新或创建尝试。RGM 将执行以下方面的检查：

• Network_resources_used 特性必须非空且包含现有共享地址资源的名称。包含可伸缩资源的资源组的 Nodelist 中的每个节点都必须显示在每个已命名共享地址资源的 NetIfList 特性或 AuxNodeList 特性中。

• 包含可伸缩资源的资源组的 RG_dependencies 特性必须包含所有共享地址资源（列在该可伸缩资源的 Network_resources_used 特性中）所属的资源组。

• Port_list 特性必须非空，并且包含端口协议对列表（协议可以是 TCP 或 UDP）。例如，

  Port_list=80/tcp,40/udp

编写和测试数据服务

本节介绍一些有关编写和测试数据服务的信息。

使用持续连接机制

对于服务器端，使用 TCP 持续连接机制可以保护服务器，使其避免为关闭的（或网络分区的）客户机浪费系统资源。如果在持续运行了足够长时间的服务器中不清除这些资源，当客户机崩溃或重新引导时，会导致浪费的资源量无限增长。

如果客户机和服务器使用 TCP 流进行通信，则它们都应该启用 TCP 持续连接机制。这也适用于非 HA 单服务器情况。

其他面向连接的协议可能也需要具有持续连接机制。

对于客户机端，使用 TCP 持续连接机制，可以使该客户机在网络地址资源发生故障转移或从一个物理主机切换到另一个物理主机时收到通知。网络地址资源的这种传送将中断 TCP 连接。但是，除非该客户机已启用了持续连接机制，否则当连接中断而当时该连接又正处于静止状态时，该客户机不一定会收到关于此情况的通知。

例如，假设客户机正在等待服务器对长时间运行请求的反应，且该客户机的请求消息已发送到服务器并已在 TCP 层得到了确认。在这种情况下，客户机的 TCP 模块无需不断重新发送请求，并且客户机应用程序处于阻塞状态，等待对该请求的反应。

在适当的情况下，客户机应用程序除了使用 TCP 持续连接机制以外，还必须在其级别上执行自己的周期性持续连接机制，因为 TCP 持续连接机制并不是在处理所有可能的边界问题上都是完美的。使用应用程序级别的持续连接机制通常要求客户机服务器协议支持一个空操作，或者至少支持一个有效的只读操作（例如状态操作）。

测试 HA 数据服务

本节给出有关如何在 HA 环境中测试数据服务实现的建议。测试情况只是一些建议，并不很全面。您需要访问测试平台的 Sun Cluster 配置，以免测试工作影响生产机器。

测试 HA 数据服务在资源组在物理主机之间移动的所有情况下是否运行正常。这些情况包括系统崩溃以及使用 scswitch 命令的情况。测试客户机在这些情况下是否可以继续获取服务。

测试方法的幂等性。例如，用可多次调用原始方法的简短 shell 脚本暂时替换所有方法。

协调资源间的依赖性

有时一个客户机服务器数据服务在满足某个客户机请求的同时，会向其他客户机服务器数据服务发出请求。用非正式的语言描述就是，如果数据服务 A 依赖于数据服务 B，则当 A 提供其服务时，B 也必须提供其服务。为了满足此要求，Sun Cluster 允许在资源组内配置资源的依赖性。这些依赖性会影响 Sun Cluster 启动和停止数据服务的顺序。有关详细信息，请参见 scrgadm(1M) 手册页。

如果您的资源类型的资源依赖于其他类型的资源，则您必须指导用户适当地配置资源和资源组，或提供脚本或工具对其进行正确配置。如果依赖资源必须和被依赖资源在同一节点上运行，则必须在同一资源组中配置这两种资源。

决定是使用明确的资源依赖性，还是忽略它们，并对用您的 HA 数据服务自身代码编写的其他数据服务的可用性进行论询。如果依赖资源和被依赖资源可以在不同节点上运行，则可以在不同的资源组中对它们进行配置。在这种情况下，需要进行轮询，因为无法跨组配置资源依赖性。

有些数据服务自己不直接存储数据，而是依赖其他后端数据服务存储其全部数据。这样的数据服务将所有只读和更新请求转送到对后端数据服务的调用中。例如，假设有一个客户机服务器日程日历服务，该服务将其全部数据存储在 SQL 数据库（例如 Oracle）中。日程日历服务具有自己的客户机服务器网络协议。例如，它可能已使用 RPC 规范语言（例如 ONC RPC）定义了自己的协议。

在 Sun Cluster 环境中，您可以使用 HA-ORACLE 使后端 Oracle 数据库具有高可用性。这样您就可以编写用于启动或停止日程日历守护程序的简单方法。您的最终用户将使用 Sun Cluster 注册日程日历资源类型。

如果该日程日历应用程序必须和 Oracle 数据库在同一个节点上运行，则最终用户可以在配置 HA-ORACLE 资源的同一个资源组中配置日程日历资源，并使日程日历资源依赖于 HA-ORACLE 资源。这种依赖性是用 scrgadm 中的 Resource_dependencies 特性标记来指定的。

如果 HA-ORACLE 资源可以和日程日历资源运行在不同的节点上，则最终用户可以在两个不同的资源组中对它们进行配置。最终用户可以配置日历资源组对 Oracle 资源组的资源组依赖性。但是仅当在同一节点上同时启动或停止两个资源组时，资源组依赖性才有效。因此，日历数据服务守护程序在启动后可能进行轮询，以等待 Oracle 数据库成为可用的数据库。在这种情况下，日历资源类型的 Start 方法通常仅返回成功消息，因为如果 Start 方法无限期地处于阻塞状态，它将使其资源组处于忙碌状态，这样会阻止对该组进行进一步的状态更改（例如进行编辑、故障转移或切换）。但是，如果日历资源的 Start 方法超时或在非零的情况下退出，则可能会导致该资源组在两个或多个节点间交替切换，而这时 Oracle 数据库仍然不可用。