程序包配置规划

程序包的规划涉及有关每组高可用性服务的组合信息。




	注释：从 Serviceguard A.11.18 开始，有一种更简便的新增方法可以配置程序包。通过此方法可以基于更小的模块构建程序包，并且不必使用单独的程序包控制脚本，也不必手动分发此脚本；有关完整说明，请参阅第 6 章“配置程序包及其服务”。本手册将新方法生成的程序包称为模块化程序包，将旧方法生成的程序包称为旧程序包。本手册的余下部分假设您将使用模块化方法。有关创建和维护旧程序包的信息和说明，请参阅“配置旧程序包”。

逻辑卷和文件系统规划




	注释：还必须在群集配置文件中将由程序包激活的 LVM 卷组定义为群集可识别卷组。请参阅“群集配置规划 ”。必须在程序包配置文件中定义由程序包激活的磁盘组（针对 Veritas Volume Manager），如下所述。

您可能需要将卷组中的逻辑卷用作群集中程序包操作基础结构的一部分。当程序包从一个节点移至另一节点时，它必须能像原节点那样，访问驻留在相同磁盘上的数据。可以通过激活卷组，并挂接驻留在其上的文件系统，来实现这一目标。

在 Serviceguard 中，将高可用性应用程序、服务和数据，安排在共享总线的卷组中。当节点出现故障时，包含故障节点的应用程序、服务和数据的卷组，就在故障节点上停用，并在代管节点上激活。要做到这一点，必须将卷组配置为可从故障节点转移到代管节点。

作为规划的一部分，必须确定以下几点：

需要什么卷组？
需要多大的磁盘空间，磁盘空间在逻辑卷中如何分配？
需要为每个程序包挂接什么文件系统？
哪些节点需要导入哪些逻辑卷配置？
如果程序包移至代管节点，将会对性能产生什么影响？

请按程序包创建由卷组、逻辑卷和文件系统组成的列表。指明哪些节点需要在不同时间访问公共文件系统。

HP 建议使用不同于缺省逻辑卷名（lvol1、lvol2 等）的定制逻辑卷名。选择代表与其相关的高可用性应用程序的逻辑卷名（如 lvoldatabase），可以简化群集管理。

要进一步说明每个节点上的程序包相关卷组、逻辑卷和文件系统，可以在 /etc/fstab 文件中添加注释行。下面是一个数据库应用程序的示例：

# /dev/vg01/lvoldb1 /applic1 vxfs defaults 0 1   # These six entries are
# /dev/vg01/lvoldb2 /applic2 vxfs defaults 0 1   # for information purposes
# /dev/vg01/lvoldb3 raw_tables ignore ignore 0 0 # only. They record the
# /dev/vg01/lvoldb4 /general vxfs defaults 0 2   # logical volumes that
# /dev/vg01/lvoldb5 raw_free ignore ignore 0 0   # exist for Serviceguard's
# /dev/vg01/lvoldb6 raw_free ignore ignore 0 0   # HA package. Do not uncomment.

请为每个逻辑卷创建一个项，指明其是用于文件系统还是用于原始设备。请记住使用如上所示的 # 字符将这些行注释掉。




	注释：请不要使用 `/etc/fstab` 挂接供 Serviceguard 程序包使用的文件系统。

规划 Veritas Cluster Volume Manager (CVM) 和 Cluster File System (CFS)




	注释：有关支持 CVM 和 CFS 的最新信息，请查阅《Serviceguard, SGeRAC, and SMS Compatibility and Feature Matrix》以及您的 Serviceguard 版本所对应的最新发行说明：`http://www.docs.hp.com -> High Availability -> Serviceguard`。

对于使用 CVM 或 CFS 的故障切换程序包，应配置系统多节点程序包来处理卷组和文件系统。




	注意：Serviceguard 通过系统多节点程序包管理 Veritas 进程，特别是 gab 和 LLT。因此，Veritas 管理命令（如 gabconfig、llthosts 和 lltconfig）仅应在显示模式下使用，例如 gabconfig -a。如果使用 Veritas 命令（如 gab* 或 llt* 命令）来配置这些组件或影响其运行时行为，则会使节点或整个群集崩溃。

CVM 3.5

Veritas Cluster Volume Manager 3.5 使用系统多节点程序包 VxVM-CVM-pkg 来管理群集的卷。

请为 CVM 3.5 和 VxVM-CVM-pkg 配置一个心跳线网络。不支持多个心跳线。不支持将 APA、Infiniband 或 VLAN 接口用作心跳线网络。

不支持 CFS 的 CVM 4.1 和更高版本

Veritas Cluster Volume Manager 4.1 和更高版本使用系统多节点程序包 SG-CFS-pkg 来管理群集的卷。

CVM 4.1 和更高版本以及 SG-CFS-pkg 要求配置多个心跳线网络，或一个具有备用心跳线网络的心跳线网络。不支持将 APA、Infiniband 或 VLAN 接口用作心跳线网络。

支持 CFS 的 CVM 4.1 和更高版本

支持将 CFS (Veritas Cluster File System) 与 Veritas Cluster Volume Manager 4.1 和更高版本配合使用。

系统多节点程序包 SG-CFS-pkg 管理群集的卷。还使用两组多节点程序包：CFS 挂接程序包 SG-CFS-MP-id# 和 CFS 磁盘组程序包 SG-CFS-DG-id#。使用 cfs 系列命令创建多节点程序包；请不要编辑配置文件。

对于应用程序故障切换程序包和非故障切换程序包，可以创建一系列程序包相关性：

除非挂接点程序包已经运行，否则，故障切换程序包的应用程序不应该在节点上运行。
在程序包配置文件中，填充 DEPENDENCY 参数，以指定条件为 SG-CFS-MP-id# =UP、位置为 SAME_NODE。
除非磁盘组程序包正在运行，否则，挂接点程序包不应该运行。
可以使用 cfsmntadm 和 cfsmount 命令创建挂接点程序包。Serviceguard 将挂接点程序包命名为 SG-CFS-MP-id#，并自动递增其 ID 号。在其配置文件中，Serviceguard 指定与磁盘组程序包的相关性。

除非 CFS 系统多节点程序包 (SG-CFS-pkg) 正在运行来管理卷，否则，磁盘组程序包不应该运行。

可以使用 cfsdgadm 命令创建磁盘组程序包。Serviceguard 将磁盘组程序包命名为 SG-CFS-DG-id#，并自动递增其 ID 号。在其配置文件中，Serviceguard 指定 CFS 系统多节点程序包 (SG-CFS-pkg) 的相关性。




	注意：创建磁盘组和挂接点程序包后，使用 cfs 命令（包括 cfsdgadm、cfsmntadm、cfsmount 和 cfsumount）来管理群集是非常关键的。如果使用常规命令（如 mount 和 umount），则会导致严重问题，如向本地文件系统而不是群集文件系统写入。在 HP Serviceguard Storage Management Suite 环境中，如果安装了 CFS，则在使用除 cfsmount 或 cfsumount 之外的任何格式的 mount 命令（例如 mount -o cluster、dbed_chkptmount 或 sfrac_chkptmount）时，一定要小心。这些非 cfs 命令会导致与在文件系统或 Serviceguard 程序包上执行的后续命令操作发生冲突。使用这些其他格式的 mount 不会创建适当的多节点程序包，这意味着群集程序包无法识别文件系统更改。




	注释：磁盘组 (DG) 和挂接点 (MP) 多节点程序包（`SG-CFS-DG_ID#` 和 `SG-CFS-MP_ID#`）不监视磁盘组和挂接点的运行状况。它们所检查的应用程序程序包取决于这些程序包对磁盘组和挂接点是否有访问权限。如果相关的应用程序程序包缺少访问权限，并且不能读取和写入磁盘，则它会失败；但这不会导致 DG 或 MP 多节点程序包失败。

使用 cfscluster 命令创建 CFS 程序包 SG-CFS-pkg。它是系统多节点程序包，可用于管理供 CVM 4.1 和更高版本使用的卷。系统多节点程序包不能依赖于任何其他程序包。

扩展规划

可以向正在运行的群集添加程序包。此过程将在第 7 章“群集和程序包维护”中进行介绍。

添加程序包时，请确保不要超过群集配置文件中定义的 max_configured_packages 值（请参阅“群集配置参数 ”）。如果需要，可以在群集运行时修改此参数。

选择切换和故障切换行为

要确定故障切换程序包的故障切换行为（请参阅“程序包类型”），请定义故障切换策略，用于控制 Serviceguard 将自动启动未运行的程序包的位置。另外，可以定义故障返回策略，用于确定程序包在可能时是否自动返回到其主节点。

下表说明了不同类型的故障切换行为，以及程序包配置文件中确定每种行为的设置。有关详细信息，请参阅“程序包参数说明”。

表 4-2 程序包故障切换行为

切换行为	配置文件中的参数
通常在检测到服务、网络或 EMS 故障后，或者不满足已配置的资源附属件时，进行程序包切换。暂停脚本在切换发生之前运行（缺省值）。	`node_fail_fast_enabled` 设置为 `no`（缺省值）。对于所有服务，`service_fail_fast_enabled` 均设置为 `NO`（缺省值）。对于程序包，`auto_run` 设置为 `yes`（缺省值）。
程序包故障切换到活动程序包最少的节点。	`failover_policy` 设置为 `min_package_node`。
程序包故障切换到节点列表中的下一个节点（缺省值）。	`failover_policy` 设置为 `configured_node`（缺省值）。
如果主节点可用且程序包在非主节点上运行，则程序包将自动暂停并在其主节点上重新启动。	`failback_policy` 设置为 `automatic`。
如果程序包在非主节点上运行，则必要时必须手动将程序包返回其主节点。	failback_policy 设置为 `manual`（缺省值）。 failover_policy 设置为 `configured_node`（缺省值）。
当特定的服务出现故障时，节点上的所有程序包将在系统复位（即立即暂停，而不执行正常的关闭过程）后进行切换。暂停脚本未运行。	对于特定服务，`service_fail_fast_enabled` 设置为 `yes`。对于所有程序包，`auto_run` 均设置为 `yes`。
当任何服务出现故障时，节点上的所有程序包将在系统复位后进行切换。执行系统复位前会先尝试重新引导系统。	对于所有服务，`service_fail_fast_enabled` 均设置为 `yes`。对于所有程序包，`auto_run` 均设置为 `yes`。

还可以配置故障切换程序包，以便 IP 地址从出现故障的局域网卡切换到同一节点和同一物理子网上的备用局域网卡。要管理该行为，请使用程序包配置文件中的参数“local_lan_failover_allowed”(缺省值为 yes，表示已启用）。

配置 EMS 资源的参数




	注释：模块化程序包配置文件中的参数名和文本值的缺省格式为小写；对于旧程序包，缺省格式为大写。不存在兼容性问题；对于参数，Serviceguard 区分大小写。除非相关参数仅用于旧程序包，或上下文特指旧程序包，否则本手册将使用小写。

Serviceguard 提供了一组配置 EMS（Event Monitoring Service，事件监视服务）资源的参数。它们是 resource_name、resource_polling_interval、resource_start 和 resource_up_value。请在程序包配置文件中，为程序包依赖的每个资源配置这些参数。

resource_start 参数用于确定 Serviceguard 何时启动对 EMS 资源的资源监视。resource_start 可设置为 automatic 或 deferred。

Serviceguard 将在节点上的 Serviceguard 群集守护程序启动时自动启动对 automatic 资源的资源监视。

Serviceguard 不会在节点启动过程中尝试启动 deferred 资源监视，但会在程序包运行时启动对这些资源的监视。

下面是如何配置 deferred 和 automatic 资源的示例。

resource_name /net/interfaces/lan/status/lan0
resource_polling_interval 60
resource_start deferred
resource_up_value = up
 
resource_name /net/interfaces/lan/status/lan1
resource_polling_interval 60
resource_start deferred
resource_up_value = up
 
resource_name /net/interfaces/lan/status/lan0
resource_polling_interval 60
resource_start automatic
resource_up_value = up

注释：对于旧程序包，请在程序包控制脚本中，使用 DEFERRED_RESOURCE_NAME 参数再次指定延迟资源：

DEFERRED_RESOURCE_NAME[0]="/net/interfaces/lan/status/lan0"
DEFERRED_RESOURCE_NAME[1]="/net/interfaces/lan/status/lan1"

如果在旧配置文件中将资源配置为 AUTOMATIC，则不必在程序包控制脚本中定义 DEFERRED_RESOURCE_NAME。

关于程序包相关性

从 Serviceguard A.11.17 开始，一个程序包可以具有与其他程序包的相关性，也就是说，除非该程序包的相关程序包在节点上运行，否则该程序包不会在该节点上启动。

在 Serviceguard A.11.17 中，仅支持将程序包相关性用于 HP 指定的特定应用程序，例如，HP 提供的多节点及系统多节点程序包可用于支持其系统上的 Veritas Cluster File System (CFS)。

从 Serviceguard A.11.18 开始，程序包相关性已不再受限制；可以使某个程序包依赖于在同一群集节点上运行的一个或多个不同的程序包，但受第 6 章中的“dependency_condition”的限制。

如果第一个程序包在没有第二个程序包提供的服务时无法（或者不应）运行，则可以使这两个程序包彼此相关。例如，pkg1 可能运行一个由 pkg2 管理的数据库的实时 Web 接口，在这种情况下，应使 pkg1 依赖于 pkg2。

在考虑是否要在程序包之间创建相关性时，请考虑下面的“规则”和“准则”。

规则

假设要使 pkg1 依赖于 pkg2。




	注释：`pkg1` 可能依赖于多个其他程序包，`pkg2` 也可能依赖于另一个或另一些程序包，但为了尽量清楚地阐述规则，假设只存在两个程序包。

除非 pkg2 在某个节点上运行，否则不会在该节点上启动 pkg1。
pkg1 的“package_type”和“failover_policy”限制 pkg2 的类型和特征，如下所示：
- 如果 pkg1 是多节点程序包，则 pkg2 必须是多节点程序包或系统多节点程序包（请注意，系统多节点程序包不能用于一般用途）。
- 如果 pkg1 是故障切换程序包，并且其 failover_policy 是 min_package_node，则 pkg2 必须是多节点程序包，或系统多节点程序包。
- 如果 pkg1 是故障切换程序包，并且其 failover_policy 是 configured_node，则 pkg2 必须是：
  多节点程序包或系统多节点程序包，或
  其 failover_policy 是 configured_node 的故障切换程序包
pkg2 不能是 failover_policy 为 min_package_node 的故障切换程序包。
pkg2 的节点列表（请参阅“node_name”中的 node_name）必须包含 pkg1 上的所有节点。
- 如果 failover_policy 为 configured_node 的程序包之间存在相关性，则应按相同顺序列出节点；否则 cmcheckconf 和 cmapplyconf 将发出警告。
程序包不能直接或间接依赖于其自身。
也就是说，不但 pkg1 不能在“dependency_condition”中指定其自身，而且 pkg1 不能指定与 pkg2 的相关性（如果 pkg2 依赖于 pkg1，或者如果 pkg2 依赖于 pkg3，而 pkg3 又依赖于 pkg1，依此类推）。
如果 pkg1 是故障切换程序包，同时 pkg2 是一个多节点程序包或系统多节点程序包，并且 pkg2 出现故障，则 pkg1 将暂停并故障切换到其 node_name 列表中正在运行 pkg2（并且满足任何其他相关性，如资源相关性或与第三个程序包的相关性）的下一个节点。
对于使用 configured_node failover_policy 的故障切换程序包，有一组规则控制在哪些情况下 pkg1 可以强制 pkg2 在给定节点上启动。这称为拖动并由每个程序包的“priority”确定。请参阅
“拖动规则”。
如果 pkg2 出现故障，Serviceguard 将暂停 pkg1 以及任何其他直接或间接依赖于 pkg2 的程序包。
缺省情况下，Serviceguard 将按相关性顺序暂停程序包，即，首先暂停相关程序包，然后暂停原程序包。在本示例中，将首先暂停 pkg1，然后暂停 pkg2。如果存在第三个依赖于 pkg1 的程序包 pkg3，则首先将暂停 pkg3，然后暂停 pkg1，最后暂停 pkg2。
如果任何相关程序包的暂停脚本挂起，则缺省情况下被依赖的程序包将始终处于等待状态（pkg2 将始终等待 pkg1，如果存在一个依赖于 pkg1 的程序包 pkg3，则 pkg1 将始终等待 pkg3）。不能通过 successor_halt_timeout 参数修改此行为（请参阅“successor_halt_timeout”）（程序包的后续程序包依赖于此程序包；在本示例中， pkg1 是 pkg2 的后续程序包；相反，pkg2 可以称为 pkg1 的前导程序包）。

拖动规则

对于一组具有 configured_node failover_policy 的故障切换程序包，当其中的一个或多个程序包依赖于另一个或另一些程序包时，可以使用 priority 参数控制这些程序包的启动、故障切换和故障返回行为。

一种广泛适用的规则是，优先级较高的程序包可以拖动优先级较低的程序包，即强制该程序包在一个适合于高优先级程序包的节点上启动，或移动到这样的节点。




	注释：仅当程序包自动启动（启用了程序包切换）时，此规则才适用；cmrunpkg 永远不会强制程序包暂停。

请注意，即使一个或多个程序包依赖于另一个程序包，也不必设置 priority。缺省值 no_priority 通常会产生所需的行为。例如，如果 pkg1 依赖于 pkg2，并且这两个程序包的 priority 均设置为 no_priority，同时根据本节的建议设置了其他参数（如 node_name 和 auto_run），则 pkg1 通常会随 pkg2 移动到两者均可运行的位置，这是常见的结果，可能也是所需要的结果。

下列示例诠释了以上规则，这些示例适用于两个“failover_policy”为 configured_node 的故障切换程序包。假定 pkg1 依赖于 pkg2，并且在每个程序包配置文件的“node_name”下指定了 node1、node2 和 node3，同时还假定每个程序包的“failback_policy”设置为 automatic。




	注释：在查看下列示例以及实际配置优先级时，请注意下列事项：所有相关程序包的“`auto_run`”均应设置为 `yes`；下列示例假定已设置该值。优先级表示级别顺序，因此数值越小，级别越高（例如，10 的优先级高于 30）。 HP 建议以 20 为增量进行赋值，以便在级别顺序中留出间隔；否则，在向新程序包分配优先级时，可能必须打乱所有现有的优先级。缺省值 `no_priority` 被视为一个低于任何数值的优先级。根据定义，具有 `no_priority` 的所有程序包的优先级相同，并且无法通过其他方法分配相同优先级；数值优先级在群集中必须唯一。有关详细信息，请参阅 `priority`（“`priority`”）。

如果 pkg1 依赖于 pkg2，并且 pkg1 的优先级低于或等于 pkg2 的优先级，则 pkg2 的节点顺序将起决定作用。假定 pkg2 的节点顺序为 node1、node2、node3，则：

在启动时：
- pkg2 将在 node1 上启动，如果 node1 不可用或当前不满足其所有相关性等，则将在 node2 上启动。
  pkg1 将在启动了 pkg2 的任何节点上启动（无论该节点在 pkg1 的 node_name 列表中处于任何位置），前提是该节点满足 pkg1 的所有其他相关性。
  如果启动了 pkg2 的节点不满足 pkg1 的所有相关性，pkg1 将不会启动。
在故障切换时：
- 如果 pkg2 在 node1 上出现故障，则 pkg2 将故障切换到 node2（如果 node2 不可用或当前不满足其所有相关性等，则故障切换到 node3）。
  pkg1 将故障切换到启动了 pkg2 的任何节点（无论该节点在 pkg1 的 node_name 列表中处于任何位置），前提是该节点满足 pkg1 的所有相关性。
  如果启动了 pkg2 的节点不满足 pkg1 的所有相关性，pkg1 将不会启动。
- 如果 pkg1 出现故障，pkg1 将不会进行故障切换。
  这是因为 pkg1 无法在任何代管节点上重新启动（除非 pkg2 正在某个代管上运行），并且 pkg2 将仍在原始节点上运行。pkg1 无法拖动 pkg2，因为其优先级无法使其执行此操作。
在故障返回时：
- 如果这两个程序包已经从 node1 移动到 node2，并且 node1 不可用，则仅当 pkg2 的优先级高于 pkg1 时，pkg2 才会故障返回到 node1。
  如果优先级相同，则这两个程序包均不会故障返回（除非 pkg1 正在运行，此种情况下 pkg2 可以故障返回）。
  如果 pkg2 的优先级高于 pkg1，pkg2 将故障返回到 node1；只要 node1 满足 pkg1 的所有其他相关性，pkg1 便会故障返回到此节点；
  如果 pkg2 已经故障返回到 node1，并且 node1 不满足 pkg1 的所有相关性，pkg1 将暂停。

如果 pkg1 依赖于 pkg2，并且 pkg1 的优先级高于 pkg2，则 pkg1 的节点顺序将起决定作用。假定 pkg1 的节点顺序为 node1、node2、node3，则：

在启动时：
- pkg1 将选择在 node1 上启动。
- pkg2 将在 node1 上启动，前提是它可以在该节点上运行（无论 node1 在 pkg2 的 node_name 列表中处于任何位置）。
  如果 pkg2 已经在另一个节点上运行，则它将被拖动到 node1，前提是它可以在该节点上运行。
- 如果 pkg2 无法在 node1 上启动，两个程序包将尝试在 node2（依此类推）上启动。
请注意，pkg2 将尝试按照 pkg1 的 node_name 列表中的顺序来访问节点，并且无论它当前是否在其他节点上运行，均会被拖动到该列表上的第一个合适节点中。
在故障切换时：
- 如果 pkg1 在 node1 上出现故障，则 pkg1 将选择故障切换到 node2（或 node3，如果它可以在该节点上运行，且 node2 不可用或不满足其所有相关性等）。
- pkg2 将被拖动到 pkg1 选择的任何节点，并在该节点上重新启动；然后，pkg1 将在该节点上重新启动。
在故障返回时：
- 如果已将这两个程序包移动到 node2，并且 node1 不可用，则 pkg1 将故障返回到 node1，前提是这两个程序包可以在该节点上运行；
  否则，这两个程序包均不会故障返回。

准则

如“拖动规则”所述，如果 pkg1 依赖于 pkg2，有时最好向 pkg1 分配一个更高的优先级，这是因为是当 pkg1 出现故障时，此方法更有利于成功进行故障切换（和故障返回）。

但同时还应权衡程序包的相对重要性。如果 pkg2 运行的数据库对于业务至关重要，则可能希望该数据库在无干扰的状态下运行，而不管依赖它的应用程序包出现什么情况。这种情况下，数据库程序包应具有最高的优先级。

请注意，如果未设置优先级，则拖动规则会将原程序包故障切换到从属程序包。

如果从属程序包的实际重要性与它所依赖的程序包相同，请考虑将更高的优先级分配给从属程序包；否则，请将更高优先级分配给更重要的程序包，或将这两个程序包的优先级设置为缺省值。

还需要考虑当某个程序包出现故障时的情况。如果其他程序包依赖于此程序包，则 Serviceguard 会暂停这些程序包（以及依赖于这些程序包的任何程序包等）。无论出现故障的程序包的优先级如何，均会出现此情况。

缺省情况下，程序包将按启动顺序的相反顺序暂停；如果任何从属程序包的暂停脚本挂起，则出现故障的程序包将无限期等待，以完成其自身的暂停进程。这种情况非常有利于所有从属程序包完全暂停，但这可能并不是所需的行为。可以通过 successor_halt_timeout 参数（请参阅“successor_halt_timeout”）更改此行为。

如果将 successor_halt_timeout 设置为 0，Serviceguard 会同时暂停从属程序包和出现故障的程序包；如果将该参数设置为正数，Serviceguard 会按启动顺序的相反顺序暂停程序包，但将使出现故障的程序包在 successor_halt_timeout 秒之后暂停，而不管从属程序包是否完成了它们的暂停脚本。

关于外部脚本

模块化脚本的程序包配置模板显式提供了外部脚本。这些脚本取代了旧脚本中的 CUSTOMER DEFINED FUNCTIONS，并可以在：

程序包启动和关闭时运行，此时外部脚本实际上用作程序包执行的第一个和最后一个函数。这些脚本通过参数“external_pre_script”调用或
在程序包执行过程中，在激活卷组和文件系统并分配 IP 地址之后并在执行服务和资源函数之前运行；并在程序包关闭时按相反顺序再次运行。这些脚本由“external_script”调用。

外部脚本还会在 cmcheckconf 和 cmapplyconf 验证程序包时运行，并且必须具有验证入口点，如下所示。

程序包可以同时使用此两种类型的脚本，并可以启动每种类型的多个脚本；这种情况下，脚本将按它们在程序包配置文件中列出的顺序执行（而在程序包关闭时则按相反顺序执行）。

每个外部脚本必须有三个入口点：start、stop 和 validate，并应在退出时返回下列值之一：

0 －表示成功。
1 －表示由于此脚本失败，因此将暂停而不会重新启动程序包。
2 －表示程序包将在另一个节点上重新启动，如果没有可用的其他任何节点，则暂停。




	注释：对于 `validate` 入口点，退出值 `1` 和 `2` 将被视为相同；可以使用这两个值中的任何一个指示验证失败。

外部脚本可以使用由程序包管理器或运行程序包的主控制脚本导出的一组标准环境变量（包括程序包名称 SG_PACKAGE 和本地节点名称 SG_NODE），还可以调用日志记录函数和其他实用函数中的源函数。其中的一个函数 sg_source_pkg_env() 可用于访问为此程序包配置的所有参数，包括通过 pev_ 参数（请参阅“pev_”）配置的程序包特定的环境变量。

有关详细信息，请参阅 $SGCONF/examples/external_script.template 中的模板。

以下是一个示例脚本。该脚本假定还有一个名为 monitor.sh 的脚本，后者将通过 Serviceguard 服务进行配置以监视某个应用程序。 monitor.sh 脚本（此处并不包含）使用程序包配置文件中定义的参数 PEV_MONITORING_INTERVAL 来定期轮询要监视的应用程序，例如：

PEV_MONITORING_INTERVAL 60

验证时，该示例脚本将确保 PEV_MONITORING_INTERVAL 和监视服务已经过正确配置；在启动和停止时，该示例脚本将向日志文件输出时间间隔。

#!/bin/sh# Source utility functions. if [[ -z $SG_UTILS ]]then    . /etc/cmcluster.conf    SG_UTILS=$SGCONF/scripts/mscripts/utils.shfiif [[ -f ${SG_UTILS} ]]; then    . ${SG_UTILS}    if (( $? != 0 ))    then        echo "ERROR: Unable to source package utility functions file: ${SG_UTILS}"        exit 1    fielse    echo "ERROR: Unable to find package utility functions file: ${SG_UTILS}"    exit 1fi# Get the environment for this package through utility function# sg_source_pkg_env().sg_source_pkg_env $*function validate_command{    typeset -i ret=0    typeset -i i=0    typeset -i found=0    # check PEV_ attribute is configured and within limits    if [[ -z PEV_MONITORING_INTERVAL ]]    then        sg_log 0 "ERROR: PEV_MONITORING_INTERVAL attribute not configured!"        ret=1    elif (( PEV_MONITORING_INTERVAL < 1 ))    then        sg_log 0 "ERROR: PEV_MONITORING_INTERVAL value ($PEV_MONITORING_INTERVAL) not within legal limits!"        ret=1    fi    # check monitoring service we are expecting for this package is configured    while (( i < ${#SG_SERVICE_NAME[*]} ))    do        case ${SG_SERVICE_CMD[i]} in            *monitor.sh*) # found our script                          found=1                          break                          ;;                       *)                          ;;        esac        (( i = i + 1 ))    done    if (( found == 0 ))    then        sg_log 0 "ERROR: monitoring service not configured!"        ret=1    fi    if (( ret == 1 ))    then        sg_log 0 "Script validation for $SG_PACKAGE_NAME failed!"    fi    return $ret}function start_command{    sg_log 5 "start_command"    # log current PEV_MONITORING_INTERVAL value, PEV_ attribute can be changed    # while the package is running    sg_log 0 "PEV_MONITORING_INTERVAL for $SG_PACKAGE_NAME is $PEV_MONITORING_INTERVAL"    return 0}function stop_command{    sg_log 5 "stop_command"    # log current PEV_MONITORING_INTERVAL value, PEV_ attribute can be changed    # while the package is running    sg_log 0 "PEV_MONITORING_INTERVAL for $SG_PACKAGE_NAME is $PEV_MONITORING_INTERVAL"    return 0}typeset -i exit_val=0case ${1} in     start)           start_command $*           exit_val=$?           ;;     stop)           stop_command $*           exit_val=$?           ;;     validate)           validate_command $*           exit_val=$?           ;;     *)               sg_log 0 "Unknown entry point $1"           ;;esacexit $exit_val

有关将应用程序与 Serviceguard 集成的详细信息，请参阅白皮书《Framework for HP Serviceguard Toolkits》，其中包含了一套可自定义的脚本。此白皮书包含在 Serviceguard Developer's Toolkit 中，可以从 http://www.hp.com/go/softwaredepot 免费下载此工具包。

在外部脚本中使用 Serviceguard 命令

可以在程序包中运行的外部脚本中使用 Serviceguard 命令（如 cmmodpkg）。这些命令不能与该程序包（即运行外部脚本的程序包）本身进行交互操作，但可以与其他程序包进行交互。同时，请注意编码这些交互操作的方式。

如果 Serviceguard 命令与其他程序包进行交互，请注意避免命令循环。例如，下列情况下可能会发生命令循环。假定 pkg1 运行的某个脚本对 pkg2 执行 cmmodpkg -d，而 pkg2 运行的某个脚本对 pkg1 执行 cmmodpkg -d。如果 pkg1 和 pkg2 同时启动，pkg1 脚本会立即尝试对 pkg2 执行 cmmodpkg。但是，cmmodpkg 命令必须等到 pkg2 启动之后才能完成。而 pkg2 脚本在启动时也会尝试对 pkg1 执行 cmmodpkg，但 pkg2 也必须等到 pkg1 启动之后才能完成，这样就造成了命令循环。

为了避免出现这种情况，最好为所有程序包指定 run_script_timeout 和 halt_script_timeout，特别是那些在外部脚本中使用 Serviceguard 命令的程序包。如果没有指定超时时间，并且配置中存在如上所述的命令循环，则会出现不一致的结果，包括挂起群集。

确定程序包关闭的原因

可以使用外部脚本（或旧程序包控制脚本的 CUSTOMER DEFINED FUNCTIONS 区域）来查明程序包关闭的原因。

在程序包暂停时，Serviceguard 会将程序包控制脚本中的环境变量 SG_HALT_REASON 设置为下列值之一：

failure －如果程序包因为其依赖的子网、资源或者服务出现故障而暂停，则设置为此值
user_halt －如果 cmhaltpkg 或 cmhaltnode 命令，或者 Serviceguard Manager 中的相应操作暂停了程序包，则设置为此值
automatic_halt －如果程序包因为其依赖的某个程序包出现故障而自动进行故障切换，或者自动故障返回到其主节点 (failback_policy = automatic)，则设置为此值

您可以向程序包添加定制代码，以便询问此变量、确定此程序包暂停的原因，以及采取相应的操作。对于旧程序包，请将 customer_defined_halt_cmds() 函数中的代码放置在程序包控制脚本的 CUSTOMER DEFINED FUNCTIONS 区域中（请参阅“在程序包控制脚本中添加客户定义的函数 ”）；对于模块化程序包，请将该代码放在程序包的外部脚本（请参阅“关于外部脚本”）中。

例如，如果管理员正暂停数据库程序包（将 SG_HALT_REASON 设置为 user_halt），您可能希望定制代码，以便按顺序关闭数据库；另一方面，如果将 SG_HALT_REASON 设置为 failure（说明此程序包被异常暂停，例如由于其依赖的服务出现故障而暂停），则可能需要执行强制关闭。

last_halt_failed

cmviewcl -v -f line 将显示一个 last_halt_failed 标志。




	注释：`last_halt_failed` 只出现在 cmviewcl 的输出行中，并且不显示为缺省的表格格式；必须使用 `-v` 和`-f line` 选项查看此内容。

如果暂停脚本运行成功，或者自从该节点加入群集以来未运行暂停脚本或自从将该程序包配置为在该节点上运行以来未运行暂停脚本，则 last_halt_failed 的值为 no；否则，其值为 yes。

关于跨子网故障切换

可以将群集配置为跨多个子网，这些子网通过路由器连接在一起，一些节点使用其中一个子网，而另外一些节点则使用另一个子网。这就是所谓的跨子网配置（请参阅“跨子网配置”）。在此环境中，可以将程序包配置为从一个子网的某个节点故障切换到另一子网的某个节点上。

配置程序包进行跨子网故障切换的实现方法如下：

对于模块化程序包，必须在程序包配置文件中配置两个新的参数，以使程序包在子网之间进行故障切换：
- “ip_subnet_node ” －指示子网在哪些节点上配置
- “monitored_subnet_access” －指示受监视的子网是配置在所有节点上 (FULL) 还是仅配置在部分节点上 ( PARTIAL) （对于受监视的子网，不配置 monitored_subnet_access 等效于 FULL 选项）。
（有关旧程序包，请参阅“配置跨子网故障切换”）。
请不要在程序包配置文件的 node_name 部分使用通配符 (*)，因为这样做可能会在同一子网上的节点符合条件的情况下使程序包跨子网进行故障切换。取而代之的是，请按照喜好的顺序列出节点。
程序包所使用的每个子网接口在本地桥接网上必须有一个备用接口。
该独立接口必须能够在子网之间共享。
在此环境中部署应用程序需要认真考虑；请参阅“应用程序部署的实现”。
如果为程序包配置文件中的 PARTIAL monitored_subnet_access 配置了 monitored_subnet，则必须至少在该程序包的 node_name 列表中的一个节点上配置该参数。
相反，如果为该程序包监视的所有子网都配置为 PARTIAL 访问，则 node_name 列表中的每个节点都必须至少配置其中一个子网。
- 与其他群集配置一样，除非已在节点上配置并在程序包配置文件中指定为受监视子网的子网处于打开状态，否则程序包不会在该节点上启动。

应用程序部署的实现

由于可重新定位的 IP 地址在程序包故障切换到另一子网上的节点时将发生变化，因此必须确保下列操作：

程序包使用的主机名已正确重新映射到新的可重新定位的 IP 地址。
必须配置程序包运行的应用程序，以便客户端可以重新连接到程序包的新的可重新定位的 IP 地址。
在最坏的情况下（运行应用程序的服务器已关机），客户端可以继续重试旧的 IP 地址，直至达到 TCP 的 tcp_timeout 值（通常大约为 10 分钟），此时客户端将会检测故障，并重置连接。

有关详细信息，请参阅《Technical Considerations for Creating a Serviceguard Cluster that Spans Multiple IP Subnets》白皮书，该书可从 http://docs.hp.com -> High Availability 获得。

配置程序包跨子网故障切换：示例

要将程序包配置为跨子网进行故障切换，需要对程序包配置文件完成一些其他编辑。




	注释：该节提供了模块化程序包的示例；有关旧程序包，请参阅“配置跨子网故障切换”。

假定您要配置一个程序包 pkg1，使其能够在某个群集中的所有节点之间进行故障切换（该群集由 NodeA、NodeB、NodeC 和 NodeD 组成）。

NodeA 和 NodeB 使用子网 15.244.65.0，而 NodeC 和 NodeD 不使用该子网；NodeC 和 NodeD 使用子网 15.244.56.0，而 NodeA 和 NodeB 不使用该子网（有关 cmquerycl 的输出示例，请参阅“获取跨子网信息”）。

配置 node_name

首先，需要确保 pkg1 只有在必要的时候才切换到另一个子网上的某个节点。例如，如果该程序包正在 NodeA 上运行，并需要故障切换，而在产生跨子网故障切换到 NodeC 或 NodeD 的开销之前，用户希望其尝试同一个子网上的 NodeB。

假定 nodeA 是 pkg1 的主节点（即通常情况下启动该程序包的节点），请按如下所示在程序包配置文件中创建 node_name 条目：

node_name nodeA

node_name nodeB

node_name nodeC

node_name nodeD

配置 monitored_subnet_access

要监视子网 15.244.65.0 或 15.244.56.0，根据 pkg1 运行的位置需要按如下所示在 pkg1 的程序包配置文件中配置 monitored_subnet 和 monitored_subnet_access：

monitored_subnet 15.244.65.0

monitored_subnet_access PARTIAL

monitored_subnet 15.244.56.0

monitored_subnet_access PARTIAL




	注释：对于其中任何一个子网，将 `monitored_subnet_access` 配置为 `FULL`（或者不配置 `monitored_subnet_access`），都会使程序包配置出现问题，因为这两个子网并非在所有节点上都可用。

配置 ip_subnet_node

此时需要指定哪个子网配置在哪些节点上。在此示例中，需要使用程序包配置文件中的如下条目执行该操作：

ip_subnet 15.244.65.0

ip_subnet_node nodeA

ip_subnet_node nodeB

ip_subnet 15.244.65.82

ip_address 15.244.65.83

ip_subnet 15.244.56.0

ip_subnet_node nodeC

ip_subnet_node nodeD

ip_subnet 15.244.56.100

ip_subnet 15.244.56.101

配置程序包：后续步骤

准备开始配置程序包后，请继续执行第 6 章“配置程序包及其服务”；然后开始执行“选择程序包模块” （如果发现它十分有用，则可以提前将每个程序包的配置数据分别填写在一份工作表中；空白工作表在附录 F “空白规划工作表” 中提供。