Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP-UX   >  Knowledge-on-Demand

HP Serviceguard クラスター構築手順

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む

9. パッケージの作成

最後にServiceguardパッケージを作成します。パッケージとは、アプリケーションをServiceguardクラスター管理下に置くためのリソースの集まりです。つまり、アプリケーションが使用する共有ボリューム、IPアドレス、サービス(個々のアプリケーションプロセスのようなイメージです)などがまとまったものです。ここでは、xclockをサービスとして持つ簡単なServiceguardパッケージを作成します。

Serviceguard A.11.18から、モジュラーパッケージの概念が導入されました。モジュラーパッケージにおいては、必要なモジュールを選択してパッケージを作成します。従来からのパッケージはレガシーパッケージと呼ばれます。以下では、最初に従来の方法、つまりレガシーパッケージを使用したパッケージの作成方法を説明します。次に新しいモジュラーパッケージを使用したパッケージの作成方法を説明します。
HP Serviceguard クラスター構築手順
はじめに
1.システム構成
2.OSのインストール
3.OSボリュームのミラー化
4.データディスクの設定
5.Serviceguard クラスターの構築
6.ネットワークタイムプロトコルの使用
7.共有ディスク上のファイルシステムの作成
8.クラスターの構成
9.パッケージの作成
10.クラスターの管理
11.リソースの場所

9.1. レガシーパッケージによるパッケージの作成

従来からの方法でパッケージを構築するためには、次の2つのファイルが必要です。
  1. パッケージ構成ファイル
    パッケージ名、パッケージタイプ(1ノード上で動作するパッケージか、複数ノードで動作するパッケージか)、フェイルオーバーのポリシー、パッケージが動作するノード、パッケージコントロールスクリプトの場所、サービス名(パッケージコントロールスクリプト内のサービス名と対応しています)などを記述します。
  2. パッケージコントロールスクリプト
    PATH環境変数、LVMボリューム名、LVMボリュームをマウントするポイント、マウントオプション、パッケージが使用するIPアドレス(パッケージIPもしくはリロケータブルIPと呼ばれます)、サブネット、サービス名、サービスを起動するコマンド、サービスを再起動する方法などを記述します。
この 2 つのファイルを作成した後でクラスター構築時のようにcmcheckconfコマンドによりパッケージ構成ファイルの整合性を検証し、最後にcmapplyconfコマンドにより、パッケージをクラスターに組み込みます。クラスター構成ファイルを作成したときと同様に、作業はノードfred上で行うものとします。

9.1.1. パッケージ構成ファイルの作成

パッケージ構成ファイルは、まずcmmakepkgコマンドを使用してパッケージ構成ファイルのテンプレートを作成し、後からこれを修正するという方法で作成します。以下に手順を示します。

パッケージ名をpkg1とすることにし、/etc/cmcluster以下にpkg1という名前のディレクトリを作成します(実際には任意の場所、任意の名前でよいのですが管理を簡単にするためにこのようにします)。また、ディレクトリパーミッションは 755 に設定します。

# mkdir /etc/cmcluster/pkg1
# chmod 755 /etc/cmclusger/pkg1
# cmmakepkg -p /etc/cmcluster/pkg1/pkg1.conf

これで/etc/cmcluster/pkg1/pkg1.confという名前でパッケージ構成ファイルのテンプレートが作成されます。このファイルを編集して以下のようにします。太字で示した行が編集した部分です。

# **********************************************************************
# ****** HIGH AVAILABILITY PACKAGE CONFIGURATION FILE (template) *******
# **********************************************************************
# ******* Note: This file MUST be edited before it can be used. ********
# * For complete details about package parameters and how to set them, *
# * consult the Serviceguard manual. 
# **********************************************************************
# 
# "PACKAGE_NAME" is the name that is used to identify the package.
#     
# This name will be used to identify the package when viewing or
# manipulating it. Package names must be unique within a cluster.
# 
#     
# Legal values for PACKAGE_NAME:
#   Any string that starts and ends with an alphanumeric character, and 
#   contains only alphanumeric characters, dot(.), dash(-), or underscore(_) 
#   in between.
#   Maximum length is 39 characters. 
#       

PACKAGE_NAME			pkg1

# "PACKAGE_TYPE" is the type of package.
#     
# The PACKAGE_TYPE attribute specifies the desired behavior for this
# package. Legal values and their meaning are described below:
# 
#     FAILOVER     package runs on one node at a time and if a failure
#                  occurs it can switch to an alternate node.
# 
#     MULTI_NODE   package runs on multiple nodes at the same time and
#                  can be independently started and halted on
#                  individual nodes. Failures of package components such
#                  as services, EMS resources  or subnets, will cause
#                  the package to be halted only on the node on which the
#                  failure occurred. Relocatable IP addresses cannot be
#                  assigned to "multi_node" packages.
# 
#     SYSTEM_MULTI_NODE
#                  package runs on all cluster nodes at the same time.
#                  It cannot be started and halted on individual nodes.
#                  Both "NODE_FAIL_FAST_ENABLED" and "AUTO_RUN" 
#                  must be set to "YES" for this type of package. All 
#                  "SERVICES" must have "SERVICE_FAIL_FAST_ENABLED" set 
#                  to "YES". SYSTEM_MULTI_NODE packages are only
#                  supported for use by applications provided by
#                  Hewlett-Packard.
# 
# 
#       Since "MULTI_NODE" and "SYSTEM_MULTI_NODE" packages can run on more
#       than one node at a time and do not failover in the event of a
#       package failure, the following parameters cannot be
#       specified when configuring packages of these types:
# 
#          FAILOVER_POLICY
#          FAILBACK_POLICY
# 
#       Since an IP address cannot be assigned to more than one node at
#       a time, relocatable IP addresses cannot be assigned to
#       "MULTI_NODE" packages. If volume groups are used in a
#       "MULTI_NODE" package, they must be activated in shared mode,
#       leaving the application responsible for data integrity.
# 
#       Shared access requires a shared volume manager.
# 
#       The default value for "PACKAGE_TYPE" is "FAILOVER".
#     
# Legal values for PACKAGE_TYPE: FAILOVER, MULTI_NODE, SYSTEM_MULTI_NODE.

PACKAGE_TYPE			FAILOVER

# "NODE_NAME" specified which nodes this package can run on.
#     
# Enter the names of the nodes configured to run this package, repeat
# this line for each cluster member node configured to run this package. 
# 
# NOTE: The order in which the nodes are specified here determines the
# order of priority when Serviceguard is deciding where to run the
# package.
#        
# Example : NODE_NAME  first_priority_node
#           NODE_NAME  second_priority_node
# 
# If all nodes in the cluster can run the package, and order is not
# important, specify "NODE_NAME *".
# 
# Example : NODE_NAME  *
#     
# Legal values for NODE_NAME:
#   "*", or any node name in the cluster.
#   Node name is any string that starts and ends with an alphanumeric 
#   character, and contains only alphanumeric characters, dot(.), dash(-), 
#   or underscore(_) in between.
#   Maximum name length is 39 characters. 
#       

NODE_NAME			fred
NODE_NAME			ginger

# "AUTO_RUN" defines whether the package is to be started when the
# cluster is started, and if it will fail over automatically.
#     
# Possible values are "YES" and "NO".
# The default for "AUTO_RUN" is "YES", meaning that the package will be
# automatically started when the cluster is started, and that, in the
# event of a failure the package will be started on an adoptive node. If
# "AUTO_RUN" is "NO", the package is not started when the cluster
# is started, and must be started with the cmrunpkg command.
# 
# "AUTO_RUN" replaces "PKG_SWITCHING_ENABLED".
#     
# Legal values for AUTO_RUN: YES, NO.

AUTO_RUN			YES

# "NODE_FAIL_FAST_ENABLED" will cause node to fail if package fails.
#     
# Possible values are "YES" and "NO".
# The default for "NODE_FAIL_FAST_ENABLED" is "NO".  In the event of
# failure, if "NODE_FAIL_FAST_ENABLED" is set to "YES", Serviceguard
# will halt the node on which the package is running. All
# "SYSTEM_MULTI_NODE" packages must have "NODE_FAIL_FAST_ENABLED" set to
# "YES".
# 
#     
# Legal values for NODE_FAIL_FAST_ENABLED: YES, NO.

NODE_FAIL_FAST_ENABLED			NO

# "RUN_SCRIPT" is the script that starts a package.
# "HALT_SCRIPT" is the script that stops a package.
#     
# Enter the complete path for the run and halt scripts. The scripts must
# be located in directory with "cmcluster" in the path name. In most cases
# the run script and halt script specified here will be the same script,
# the package control script generated by the cmmakepkg command.  This
# control script handles the run(ning) and halt(ing) of the package.
#     
# Legal values for RUN_SCRIPT:
#   Full path name for the run script with "cmcluster" in the path name.
#   The maximum length for the path name is MAXPATHLEN characters long.
#   

RUN_SCRIPT			/etc/cmcluster/pkg1/pkg1.sh

# Legal values for HALT_SCRIPT:
#   Full path name for the halt script with "cmcluster" in the path name.
#   The maximum length for path name MAXPATHLEN characters long.
#   

HALT_SCRIPT			/etc/cmcluster/pkg1/pkg1.sh

# "RUN_SCRIPT_TIMEOUT" is the number of seconds allowed for the package to start.
# "HALT_SCRIPT_TIMEOUT" is the number of seconds  allowed for the package to halt.
#     
# 
# If the start or halt function has not completed in the specified
# number of seconds, the function will be terminated. The default for
# each script timeout is "NO_TIMEOUT". Adjust the timeouts as necessary
# to permit full execution of each function.
# 
# Note: The "HALT_SCRIPT_TIMEOUT" should be greater than the sum of
# all "SERVICE_HALT_TIMEOUT" values specified for all services.
#     
# Legal values for RUN_SCRIPT_TIMEOUT: NO_TIMEOUT, (value > 0).

RUN_SCRIPT_TIMEOUT			NO_TIMEOUT

# Legal values for HALT_SCRIPT_TIMEOUT: NO_TIMEOUT, (value > 0).

HALT_SCRIPT_TIMEOUT			NO_TIMEOUT

# "SUCCESSOR_HALT_TIMEOUT" limits the amount of time Serviceguard waits
# for packages that depend on this package ("successor packages") to
# halt, before running the halt script of this package.
#      
# SUCCESSOR_HALT_TIMEOUT limits the amount of time
# Serviceguard waits for successors of this package to
# halt, before running the halt script of this package.
# This is an optional parameter.
# Permissible values are 0 - 4294 (specifying the maximum
# number of seconds Serviceguard will wait).
# The default value is "NO_TIMEOUT", which means Serviceguard
# will wait for as long as it takes for the successor package to halt.
# The timeout of 0 indicates, that this package will halt without
# waiting for successors packages to halt
# Example: \n"
# SUCCESSOR_HALT_TIMEOUT   NO_TIMEOUT
# SUCCESSOR_HALT_TIMEOUT   60
#      
# Legal values for SUCCESSOR_HALT_TIMEOUT: NO_TIMEOUT, ( (value >= 0) && (value <= 4294) ).

SUCCESSOR_HALT_TIMEOUT			NO_TIMEOUT

# "SCRIPT_LOG_FILE" is the full path name for the package control script
# log file. The maximum length of the path name is MAXPATHLEN characters long.
#     
# If not set, the script output is sent to a file named by appending
# ".log" to the script path.
#     
# Legal values for SCRIPT_LOG_FILE: 

#SCRIPT_LOG_FILE			

# "FAILOVER_POLICY" is the policy to be applied when package fails.
#     
# This policy will be used to select a node whenever the package needs
# to be started or restarted.  The default policy is "CONFIGURED_NODE".
# This policy means Serviceguard will select nodes in priority order
# from the list of "NODE_NAME" entries.
# 
# 
# The alternative policy is "MIN_PACKAGE_NODE". This policy means
# Serviceguard will select from the list of "NODE_NAME" entries the
# node, which is running fewest packages when this package needs to
# start.
#     
# Legal values for FAILOVER_POLICY: CONFIGURED_NODE, MIN_PACKAGE_NODE.

FAILOVER_POLICY			CONFIGURED_NODE

# "FAILBACK_POLICY" is the action to take when a package is not running
# on its primary node.
#     
# This policy will be used to determine what action to take when a
# package is not running on its primary node and its primary node is
# capable of running the package. The default policy is "MANUAL".  The
# "MANUAL" policy means no attempt will be made to move the package back
# to its primary node when it is running on an adoptive node.
# 
# The alternative policy is "AUTOMATIC". This policy means Serviceguard
# will attempt to move the package back to its primary node as soon as
# the primary node is capable of running the package.
# 
#     
# Legal values for FAILBACK_POLICY: MANUAL, AUTOMATIC.

FAILBACK_POLICY			MANUAL

# "PRIORITY" specifies the PRIORITY of the package.
#     
# This is an optional parameter. Valid values are a number between
# 1 and 3000 or NO_PRIORITY.  Default is NO_PRIORITY.
# A smaller number indicates higher priority. A package with a
# numerical priority has higher priority than a package with NO_PRIORITY.
# 
# If a number is specified, it must be unique in the cluster.
# To help assign unique priorities, HP recommends you use
# priorities in increments of 20. This will allow you
# to add new packages without having to reassign priorities.
# 
# Multi-node and System multi node packages cannot be assigned a priority. 
# 
# This parameter is used only when a package depends on other packages,
# or other packages depend on this package, but can be specified even
# when no dependencies have yet been configured.
# If priority is not configured, the package is assigned the default
# priority value, NO_PRIORITY.
# 
# Serviceguard gives preference to running the higher priority package.
# This means that, if necessary and if package switching is enabled,
# Serviceguard will halt a lower priority package which is already
# running, and restart it on another node, in order to run a higher
# priority package that directly or indirectly depends on it.
# 
# For example, suppose package pkg1 depends on package pkg2
# to be up on the same node, both have package switching enabled
# and both are currently up on node node1. If pkg1 needs to
# fail over to node2, it will also need pkg2 to move to node2.
# If pkg1 has higher priority than pkg2, it can force pkg2 to 
# move to node2. Otherwise, pkg1 cannot fail over because pkg2 is
# running on node1.
# Examples of package priorities and failover results:
# 
#        pkg1 priority     pkg2 priority    results
#        20                40               pkg1 is higher; fails over
#        40                20               pkg1 is lower; will not fail over
#        any number        NO_PRIORITY      pkg1 is higher; fails over
#        NO_PRIORITY       NO_PRIORITY      equal priority; will not fail over
#        NO_PRIORITY       any number       pkg1 is lower; will not fail over
#     
# Legal values for PRIORITY: NO_PRIORITY, ( (value >= 1) && (value <= 3000) ).

PRIORITY			NO_PRIORITY

# The package dependency parameters are "DEPENDENCY_NAME",
# "DEPENDENCY_CONDITION" and "DEPENDENCY_LOCATION".
#     
#  Dependencies are used to describe the relationship between packages
#  To define a dependency, all three attributes are required.
# 
#  "DEPENDENCY_NAME" must have a unique identifier for the dependency.
# 
#  "DEPENDENCY_CONDITION"
#           This is an expression describing what must be true for
#           the dependency to be satisfied.
# 
#           The syntax is:  = up, where 
#           depends on the type of the predecessor.
# 
# 	  A multi-node package can depend on another multi-
#           node or system multi-node package.
# 
#           A failover package with the FAILOVER_POLICY with
#           MIN_PACKAGE_NODE can depend on a multi-node or
#           system multi-node package.
# 
#           A failover package with the FAILOVER_POLICY with
#           CONFIGURED_NODE can depend on a multi-node, system
#           multi-node or another failover package with the
#           FAILOVER_POLICY set to CONFIGURED_NODE.
# 
#  "DEPENDENCY_LOCATION"
#           This describes where the condition must be satisfied.
#           The only possible value for this attribute is "same_node"
# 
#  NOTE: 
#  If dependencies are used on a CFS cluster, these are automatically
#  setup in the system_multi_node and multi_node packages created for
#  disk groups and mount points.
# 
#  Example : 
#            DEPENDENCY_NAME         SG-CFS-MP-1_dep 
#            DEPENDENCY_CONDITION    SG-CFS-MP-1=up
#            DEPENDENCY_LOCATION     same_node
#     
# Legal values for DEPENDENCY_NAME:
#   Any string that starts and ends with an alphanumeric character, and 
#   contains only alphanumeric characters, dot(.), dash(-), or underscore(_) 
#   in the middle.
#   Maximum string length is 39 characters. 
#       
# Legal values for DEPENDENCY_CONDITION: 
# Legal values for DEPENDENCY_LOCATION: same_node.

#DEPENDENCY_NAME			
#DEPENDENCY_CONDITION			
#DEPENDENCY_LOCATION			

# "LOCAL_LAN_FAILOVER_ALLOWED" will allow LANs to be switched locally.
#     
# Possible values are "YES" and "NO".
# The default for "LOCAL_LAN_FAILOVER_ALLOWED" is "YES".  In the event of a
# failure, this permits the Serviceguard to switch LANs locally
# (transfer to a standby LAN card).  Adjust as necessary.
# 
# "LOCAL_LAN_FAILOVER_ALLOWED" replaces "NET_SWITCHING_ENABLED".
#     
# Legal values for LOCAL_LAN_FAILOVER_ALLOWED: YES, NO.

LOCAL_LAN_FAILOVER_ALLOWED			YES

# "MONITORED_SUBNET" specifies the addresses of subnets that are to be 
#  monitored for this package.
#     
# Enter the network subnet name that is to be monitored for this package.
# Repeat this line as necessary for additional subnet names.  If any of
# the subnets defined goes down, the package will be switched to another
# node that is configured for this package and has all the defined subnets
# available.
# 
# "MONITORED_SUBNET" replaces "SUBNET".
# 
# The MONITORED_SUBNET names can be IPv4 or IPv6, or a mix of both.
# 
#  Example : 
#     MONITORED_SUBNET           192.10.25.0    # (netmask=255.255.255.0)
#     MONITORED_SUBNET           2001::/64      # (netmask=ffff:ffff:ffff:ffff::)
#     MONITORED_SUBNET           2001::         # (netmask=ffff:ffff:ffff:ffff::)
#     
# Legal values for MONITORED_SUBNET: 

MONITORED_SUBNET			192.39.48.0

# "CLUSTER_INTERCONNECT_SUBNET" specifies subnets that are to be monitored for 
#  a SGERAC multi-node package.
#     
# 
# This parameter requires an IPV4 address. CLUSTER_INTERCONNECT_SUBNETs 
# can be configured only for multi_node packages in SGeRAC configurations.
# 
# 
# Legal values for CLUSTER_INTERCONNECT_SUBNET: 

#CLUSTER_INTERCONNECT_SUBNET			

# "SERVICE_NAME" is a long lived (daemon) executable which
# Serviceguard will monitor while the package is up.
# 
# "SERVICE_NAME", "SERVICE_FAIL_FAST_ENABLED" and "SERVICE_HALT_TIMEOUT" 
# specify a service for this package.
#     
# The value for "SERVICE_FAIL_FAST_ENABLED" can be either "yes" or 

# "no".  The default is "no". If "SERVICE_FAIL_FAST_ENABLED" is set to
# "yes", and the service fails, Serviceguard will halt the node on which
# the service is running.
# 
# 
# "SERVICE_HALT_TIMEOUT" is a number of seconds. This timeout is used
# to determine the length of time the Serviceguard will wait for the
# service to halt before a SIGKILL signal is sent to force the
# termination of the service. In the event of a service halt,
# Serviceguard will first send a SIGTERM signal to terminate the
# service.  If the service does not halt, Serviceguard will wait for the
# specified "SERVICE_HALT_TIMEOUT", then send the SIGKILL signal to
# force the service to terminate. This timeout value should be large
# enough to allow all cleanup processes associated with the service to
# complete. If the "SERVICE_HALT_TIMEOUT" is not specified, a zero
# timeout will be assumed, meaning the cluster software will not wait at
# all before sending the SIGKILL signal to halt the service.
#    
# 
# Example: 
#     SERVICE_NAME               service_1a           
#     SERVICE_FAIL_FAST_ENABLED  no                   
#     SERVICE_HALT_TIMEOUT       300                  
# 
#     SERVICE_NAME               service_1b
#     SERVICE_FAIL_FAST_ENABLED  no                   
#     SERVICE_HALT_TIMEOUT       300                  
# 
#     SERVICE_NAME               service_1c
#     SERVICE_FAIL_FAST_ENABLED  no                   
#     SERVICE_HALT_TIMEOUT       300                  
# 
# Note: No environmental variables will be passed to the service command, this
# includes the PATH variable. Absolute path names are required for the
# service command definition. Default shell is /usr/bin/sh.
#     
# Legal values for SERVICE_NAME:
#   Any string that starts and ends with an alphanumeric character, and 
#   contains only alphanumeric characters, dot(.), dash(-), or underscore(_) 
#   in between.
#   Maximum string length is 39 characters. 
#       
# Legal values for SERVICE_FAIL_FAST_ENABLED: yes, no.
# Legal values for SERVICE_HALT_TIMEOUT: (value >= 0).

SERVICE_NAME			xclock
SERVICE_FAIL_FAST_ENABLED	NO
SERVICE_HALT_TIMEOUT		300

# Event Monitoring Service Resource Dependencies
# 
# Event monitoring service resource dependencies are specified with the
# following parameters: "RESOURCE_NAME", "RESOURCE_POLLING_INTERVAL", 
# "RESOURCE_START" and "RESOURCE_UP_VALUE".
#     
# To define a package resource dependency, a "RESOURCE_NAME" line with 
# a fully qualified resource path name, and one or more 
# "RESOURCE_UP_VALUE" lines are required. "RESOURCE_POLLING_INTERVAL" and
# the "RESOURCE_START" are optional, and will default as described
# below if not specified.     
# 
# The "RESOURCE_POLLING_INTERVAL" indicates how often, in seconds, the   
# resource is to be monitored.  The default is 60 seconds.
# 
# The "RESOURCE_START" option can be set to either "automatic" or "deferred".
# The default is "automatic". "automatic" means Serviceguard will 
# start up resource monitoring for this resource automatically when the 
# node starts up. If "deferred" is specified, Serviceguard will not 
# attempt to start this resource at node start up.  User  
# should specify all the "deferred" resources in the package run script  
# so that these "deferred" resources will be started up from the package 
# run script during package run time.                                  
# 
# "RESOURCE_UP_VALUE" requires an operator and a value.  This defines    
# the resource 'UP' condition.  The operators are =, !=, >, <, >=,     
# and <=, depending on the type of value.  Values can be string or     
# numeric.  If the type is string, then only = and != are valid        
# operators.  If the string contains white space, it must be enclosed   
# in quotes.  String values are case sensitive.  For example,          
# 
#                                       Resource is up when its value is
#                                       --------------------------------
#     RESOURCE_UP_VALUE  = UP           "UP"
#     RESOURCE_UP_VALUE  != DOWN        Any value except "DOWN"
#     RESOURCE_UP_VALUE  = "On Course"  "On Course"
# 
# If the type is numeric, then it can specify a threshold, or a range to
# define a resource up condition.  If it is a threshold, then any operator
# may be used.  If a range is to be specified, then only > or >= may be used
# for the first operator, and only < or <= may be used for the second operator.
# For example,
#                                       Resource is up when its value is
#                                       --------------------------------
#     RESOURCE_UP_VALUE  = 5            5                   (threshold)
#     RESOURCE_UP_VALUE  > 5.1          greater than 5.1    (threshold)
#     RESOURCE_UP_VALUE  > -5 and <     10       between -5 and 10   (range)
# 
# Note that "and" is required between the lower limit and upper limit to
# specify a range.  The upper limit must be greater than the lower
# limit.  If "RESOURCE_UP_VALUE" is repeated within a "RESOURCE_NAME"
# block, then they are inclusively OR'd together.  (Additional package
# resource dependencies are defined by repeating the entire
# "RESOURCE_NAME" block.)
# 
# Example : RESOURCE_NAME               /net/interfaces/lan/status/lan0
#           RESOURCE_POLLING_INTERVAL   120
#           RESOURCE_START              automatic
#           RESOURCE_UP_VALUE           = running 
#           RESOURCE_UP_VALUE           = online 
# 
#           Means that the value of resource /net/interfaces/lan/status/lan0
#           will be checked every 120 seconds, and is considered to
#           be 'up' when its value is "running" or "online".
# 
# Uncomment the following lines to specify package resource dependencies.
#     
# Legal values for RESOURCE_NAME: 
# Legal values for RESOURCE_POLLING_INTERVAL: ( (value > 0) && (value <= 86400) ).
# Legal values for RESOURCE_START: automatic, deferred.
# Legal values for RESOURCE_UP_VALUE: 

#RESOURCE_NAME			
#RESOURCE_POLLING_INTERVAL			
#RESOURCE_START			
#RESOURCE_UP_VALUE			

# "STORAGE_GROUP" specifies CVM specific disk group used in this package.
#      
# Enter the names of the storage groups configured for this package.
# Repeat this line as necessary for additional storage groups.
# 
# Storage groups are only used with CVM disk groups. Neither
# VxVM disk groups or LVM volume groups should be listed here.
# By specifying a CVM disk group with the "STORAGE_GROUP" keyword
# this package will not run until the CVM system multi node package is
# running and thus the CVM shared disk groups are ready for
# activation.
# 
# Example : STORAGE_GROUP "dg01"
#           STORAGE_GROUP "dg02"
#           STORAGE_GROUP "dg03"
#           STORAGE_GROUP "dg04"
#      
# Legal values for STORAGE_GROUP:
#   Any string that starts and ends with an alphanumeric character, and 
#   contains only alphanumeric characters, dot(.), dash(-), or underscore(_) 
#   in the middle.
#   Maximum string length is 39 characters. 
#       

#STORAGE_GROUP			

# Access Control Policy Parameters.
# 
# "USER_NAME", "USER_HOST" and "USER_ROLE" specify who can administer 
# this package.
#     
# Three entries set the access control policy for the package: the
# first line must be "USER_NAME", the second "USER_HOST", and the third "USER_ROLE".
# Enter a value after each. 
# 
# 1. "USER_NAME" can either be "ANY_USER", or a maximum of 
#     8 login names from the /etc/passwd file on user host.
# 2. "USER_HOST" is where the user can issue Serviceguard commands. 
#     Choose one of these three values: "ANY_SERVICEGUARD_NODE", 
#     or (any) "CLUSTER_MEMBER_NODE", or a specific node. For node, 
#     use the name portion of the official hostname supplied by the 
#     domain name server, not the IP addresses or fully qualified name.
# 3. "USER_ROLE" must be "PACKAGE_ADMIN". This role grants permission
#     to "monitor", plus for administrative commands for the package.
# 
# These policies do not affect root users. Access Policies defined in
# this file must not conflict with policies defined in the cluster
# configuration file.
# 
# Example: to configure a role for user john from node noir to
# administer the package, enter:
#    USER_NAME  john
#    USER_HOST  noir
#    USER_ROLE  package_admin
#     
# Legal values for USER_NAME:
#   A string of tokens each of which starts with an alphanumeric character and contains
#   only alphanumeric and underscore(_) characters. The tokens must be separated by a space 
#   or a tab character. 
#   Maximum length of each user_name is 39 character. 
#       
# Legal values for USER_HOST:
#   Any string that starts and ends with an alphanumeric character, and 
#   contains only alphanumeric characters, dot(.), dash(-), or underscore(_) 
#   in the middle.
#   Maximum length is 39 character. 
#   
# Legal values for USER_ROLE: package_admin.

#USER_NAME			
#USER_HOST			
#USER_ROLE			


パッケージ名はpkg1なので、パラメータPACKAGE_NAMEはpkg1に設定します。pkg1は通常はノードfred上で動作し、fredにノード障害が発生した場合はgingerにフェイルオーバーするものとします。したがって、PACKAGE_TYPEはデフォルトのFAILOVERを使用します。FAILOVER_POLYCYはパッケージのフェイルオーバーの仕方を指定するものです。パッケージ構成ファイルの中で指定したNODE_NAMEの順にフェイルオーバーさせたい場合はCONFIGURED_NODEを、動作しているパッケージ数が最も少ないノードにフェイルオーバーさせたい場合はMIN_PACKAGE_NODEを指定します。ここでは、NODE_NAMEのならび(fred、ginger)の順番にフェイルオーバーさせることとし、CONFIGURED_NODEを選択しています。MIN_PACKAGE_NODEはパッケージ数の多い大規模なクラスターで使用すると効果的な場合があります。FAILBACK_POLICYはフェイルオーバーしたパッケージの元のノードへの切り戻しを行う際に、手動(MANUAL)で行うか、自動(AUTOMATIC)で行うかを指定するパラメータです。ここでは手動、つまりMANUALを選択しています。NODE_NAMEの行がfredとgingerと2行存在します。これはこのパッケージが通常はノードfredで動作し、fred上でパッケージが動作できなくなった場合(fredのノード障害など)にはgingerにフェイルオーバーするという指定になっています(FAILOVER_POLICYをCONFIGURED_NODEとしているためです)。クラスター起動時にパッケージも一緒に起動するようにパラメータAUTO_RUNをYESに設定しています。このパッケージのデータLAN用のLANカードは二重化してあり、Serviceguardのローカルスイッチを有効にするためにパラメータLOCAL_LAN_FAILOVERをYESに設定しています。パラメータNODE_FAIL_FAST_ENABLEDがNOに設定してありますが、このように設定しておくと、パッケージ内のアプリケーションになんらかの障害が発生した場合、後述するパッケージコントロールスクリプト内で指定されたパッケージ停止の処理を行ってから代替ノードへのフェイルオーバーを行います。このパラメータをYESに設定すると、パッケージ内のアプリケーションになんらかの障害が発生した場合、そのノードはただちにTOCにより停止します。つまり、フェイルオーバーの時間を短くすることができます。RUN_SCRIPTとHALT_SCRIPTでパッケージを起動させるスクリプトと停止させるスクリプトを指定しています。ここではどちらもパッケージコントロールスクリプトを指定しています。それぞれのスクリプトのタイムアウト時間を指定するRUN_SCRIPT_TIMEOUTとHALT_SCRIPT_TIMEOUTはここではデフォルトのNO_TIMEOUT(タイムアウトなし)にしています。

パラメータ MONITORED_SUBNET は pkg1 が使用しているネットワークのサブネットアドレスです。

パラメータSERVICE_NAMEにはxclockを指定しています。この名前は任意に指定できますが、pkg1がxclockをサービスとして持つパッケージなのでこの名前を使用しています。SERVICE_FAIL_FAST_ENABLEDはNOに指定しています。このパラメータをYESに指定すると、サービス(この場合 xclockプロセス) に障害(ダウンなど)が発生した場合にServiceguardはTOCを発生させて当該ノードをただちに停止させます。また、パラメータSERVICE_HALT_TIMEOUTを300秒に指定しています。Serviceguardはサービスを停止させる際、最初にSIGTERMシグナルをそのサービスのプロセスに送付します。SERVICE_HALT_TIMEOUTで指定した300秒を過ぎてもサービスプロセスが停止していない場合、Serviceguardは当該プロセスにSIGKILLシグナルを送付します。

その他のパラメータはServiceguardとEMS(Event Monitoring Services)との統合、パッケージの依存関係設定のためのパラメータです。ここではこれらの説明は省きます。詳細はServiceguardのマニュアルを参照してください。

9.1.2. パッケージコントロールスクリプトの作成

パッケージコントロールスクリプトも、パッケージ構成ファイルと同様、cmmakepkgコマンドで作成したテンプレートを元に修正するという方法で作成します。管理の簡便性を考慮して、パッケージコントロールスクリプトもパッケージ構成ファイルと同じ/etc/cmcluster/pkg1ディレクトリに置くことにします。

# cmmakepkg -s /etc/cmcluster/pkg1/pkg1.sh

これで/etc/cmcluster/pkg1/pkg1.shというパッケージコントロールスクリプトのテンプレートが作成されます。これを以下のように編集します。パッケージコントロールスクリプトは長いので、必要な部分のみ抜き出しています。太字で示した行が編集した部分です。

# @(#) A.11.18.00 Date: 09/19/07 PHSS_36998 $
# **********************************************************************
# *                                                                    * 
# *        HIGH AVAILABILITY PACKAGE CONTROL SCRIPT (template)         * 
# *                                                                    *
# *       Note: This file MUST be edited before it can be used.        *
# *                                                                    *
# **********************************************************************

# The environment variables PACKAGE, NODE, SG_PACKAGE, 
# SG_NODE and SG_SCRIPT_LOG_FILE are set by Serviceguard 
# at the time the control script is executed.
# Do not set these environment variables yourself!
# The package may fail to start or halt if the values for
# these environment variables are altered.

# NOTE: Starting from 11.17, all environment variables set by 
# Serviceguard implicitly at the time the control script is
# executed will contain the prefix "SG_". Do not set any variable
# with the defined prefix, or the control script may not
# function as it should.

. ${SGCONFFILE:=/etc/cmcluster.conf}

# UNCOMMENT the variables as you set them.

# Set PATH to reference the appropriate directories.
PATH=$SGSBIN:/usr/bin:/usr/sbin:/etc:/bin

# VOLUME GROUP ACTIVATION: 
# Specify the method of activation for volume groups.
# Leave the default (VGCHANGE="vgchange -a e") if you want volume
# groups activated in exclusive mode. This assumes the volume groups have
# been initialized with 'vgchange -c y' at the time of creation.
#
# Uncomment the first line (VGCHANGE="vgchange -a e -q n"), and comment 
# out the default, if you want to activate volume groups in exclusive mode
# and ignore the disk quorum requirement. Since the disk quorum ensures 
# the integrity of the LVM configuration, it is normally not advisable
# to override the quorum.
#
# Uncomment the second line (VGCHANGE="vgchange -a e -q n -s"), and comment 
# out the default, if you want to activate volume groups in exclusive mode,
# ignore the disk quorum requirement, and disable the mirror 
# resynchronization. Note it is normally not advisable to override the 
# quorum.
#
# Uncomment the third line (VGCHANGE="vgchange -a s"), and comment
# out the default, if you want volume groups activated in shared mode. 
# This assumes the volume groups have already been marked as sharable
# and a part of a Serviceguard cluster with 'vgchange -c y -S y'.
#
# Uncomment the fourth line (VGCHANGE="vgchange -a s -q n"), and comment 
# out the default, if you want to activate volume groups in shared mode
# and ignore the disk quorum requirement. Note it is normally not 
# advisable to override the quorum.
#
# Uncomment the fifth line (VGCHANGE="vgchange -a y") if you wish to 
# use non-exclusive activation mode. Single node cluster configurations
# must use non-exclusive activation.
#
# VGCHANGE="vgchange -a e -q n"
# VGCHANGE="vgchange -a e -q n -s"
# VGCHANGE="vgchange -a s"
# VGCHANGE="vgchange -a s -q n"
# VGCHANGE="vgchange -a y"
VGCHANGE="vgchange -a e"		# Default

# CVM DISK GROUP ACTIVATION: 
# Specify the method of activation for CVM disk groups.
# Leave the default
# (CVM_ACTIVATION_CMD="vxdg -g \$DiskGroup set activation=exclusivewrite")
# if you want disk groups activated in the exclusive write mode.
#
# Uncomment the first line
# (CVM_ACTIVATION_CMD="vxdg -g \$DiskGroup set activation=readonly"),
# and comment out the default, if you want disk groups activated in
# the readonly mode.
#
# Uncomment the second line
# (CVM_ACTIVATION_CMD="vxdg -g \$DiskGroup set activation=sharedread"),
# and comment out the default, if you want disk groups activated in the
# shared read mode.
#
# Uncomment the third line
# (CVM_ACTIVATION_CMD="vxdg -g \$DiskGroup set activation=sharedwrite"),
# and comment out the default, if you want disk groups activated in the
# shared write mode.
#
# CVM_ACTIVATION_CMD="vxdg -g \$DiskGroup set activation=readonly"
# CVM_ACTIVATION_CMD="vxdg -g \$DiskGroup set activation=sharedread"
# CVM_ACTIVATION_CMD="vxdg -g \$DiskGroup set activation=sharedwrite"
CVM_ACTIVATION_CMD="vxdg -g \$DiskGroup set activation=exclusivewrite" 
	       
# VOLUME GROUPS
# Specify which volume groups are used by this package. Uncomment VG[0]="" 
# and fill in the name of your first volume group. You must begin with 
# VG[0], and increment the list in sequence.
#
# For example, if this package uses your volume groups vg01 and vg02, enter:
#         VG[0]=vg01
#         VG[1]=vg02
#
# The volume group activation method is defined above. The filesystems
# associated with these volume groups are specified below.
#
VG[0]="vgdata"

# CVM DISK GROUPS
# Specify which cvm disk groups are used by this package. Uncomment
# CVM_DG[0]="" and fill in the name of your first disk group. You must 
# begin with CVM_DG[0], and increment the list in sequence.
#
# For example, if this package uses your disk groups dg01 and dg02, enter:
#         CVM_DG[0]=dg01
#         CVM_DG[1]=dg02
#
# The cvm disk group activation method is defined above. The filesystems
# associated with these volume groups are specified below in the CVM_*
# variables.
#
#CVM_DG[0]=""

# NOTE: Do not use CVM and VxVM disk group parameters to reference
# devices used by CFS (cluster file system).  CFS resources are
# controlled by the Disk Group and Mount Multi-node packages.
# 
# VxVM DISK GROUPS
# Specify which VxVM disk groups are used by this package. Uncomment
# VXVM_DG[0]="" and fill in the name of your first disk group. You must 
# begin with VXVM_DG[0], and increment the list in sequence.
#
# For example, if this package uses your disk groups dg01 and dg02, enter:
#         VXVM_DG[0]=dg01
#         VXVM_DG[1]=dg02
#
# The cvm disk group activation method is defined above.
#
#VXVM_DG[0]=""

#
# NOTE: A package could have LVM volume groups, CVM disk groups and VxVM 
#       disk groups.
#
# NOTE: When VxVM is initialized it will store the hostname of the
#       local node in its volboot file in a variable called 'hostid'.
#       The Serviceguard package control scripts use both the values of
#       the hostname(1m) command and the VxVM hostid. As a result
#       the VxVM hostid should always match the value of the
#       hostname(1m) command.
#
#       If you modify the local host name after VxVM has been
#       initialized and such that hostname(1m) does not equal uname -n,
#       you need to use the vxdctl(1m) command to set the VxVM hostid
#       field to the value of hostname(1m). Failure to do so will
#       result in the package failing to start.

# VOLUME GROUP AND DISK GROUP DEACTIVATION RETRY COUNT
# Specify the number of deactivation retries for each disk group and volume
# group at package shutdown. The default is 2.
DEACTIVATION_RETRY_COUNT=2


# RAW DEVICES
# If you are using raw devices for your application, this parameter allows
# you to specify if you want to kill the processes that are accessing the
# raw devices at package halt time. If raw devices are still being accessed
# at package halt time, volume group or disk group deactivation can fail,
# causing the package halt to also fail. This problem usually happens when
# the application does not shut down properly.
# Note that if you are using Oracle's Cluster Ready Service, killing this
# service could cause the node to reboot.
# The legal values are "YES" and "NO". The default value is "NO".
# The value that is set for this parameter affects all raw devices associated
# with the LVM volume groups and CVM disk groups defined in the package.
KILL_PROCESSES_ACCESSING_RAW_DEVICES="NO"

# FILESYSTEMS
# Filesystems are defined as entries specifying the logical volume, the
# mount point, the mount, umount and fsck options and type of the file system.
# Each filesystem will be fsck'd prior to being mounted. The filesystems 
# will be mounted in the order specified during package startup and will 
# be unmounted in reverse order during package shutdown. Ensure that 
# volume groups referenced by the logical volume definitions below are 
# included in volume group definitions above.
#
# Specify the filesystems which are used by this package. Uncomment 
# LV[0]=""; FS[0]=""; FS_MOUNT_OPT[0]=""; FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""
# FS_TYPE[0]="" and fill in the name of your first logical volume, 
# filesystem, mount, umount and fsck options and filesystem type 
# for the file system. You must begin with LV[0], FS[0],
# FS_MOUNT_OPT[0], FS_UMOUNT_OPT[0], FS_FSCK_OPT[0], FS_TYPE[0]
# and increment the list in sequence.
#
# Note: The FS_TYPE parameter lets you specify the type of filesystem to be 
# mounted. Specifying a particular FS_TYPE will improve package failover time.  
# The FSCK_OPT and FS_UMOUNT_OPT parameters can be used to include the 
# -s option with the fsck and umount commands to improve performance for 
# environments that use a large number of filesystems. (An example of a 
# large environment is given below following the decription of the 
# CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS parameter.)
#
# Example: If a package uses two JFS filesystems, pkg01a and pkg01b, 
# which are mounted on LVM logical volumes lvol1 and lvol2 for read and 
# write operation, you would enter the following:
#      LV[0]=/dev/vg01/lvol1; FS[0]=/pkg01a; FS_MOUNT_OPT[0]="-o rw";
#      FS_UMOUNT_OPT[0]=""; FS_FSCK_OPT[0]=""; FS_TYPE[0]="vxfs"
#
#      LV[1]=/dev/vg01/lvol2; FS[1]=/pkg01b; FS_MOUNT_OPT[1]="-o rw"
#      FS_UMOUNT_OPT[1]=""; FS_FSCK_OPT[1]=""; FS_TYPE[1]="vxfs"
#
LV[0]="/dev/vgdata/lvol1"
FS[0]="/mnt1"
FS_MOUNT_OPT[0]=""
FS_UMOUNT_OPT[0]=""
FS_FSCK_OPT[0]=""
FS_TYPE[0]="vxfs"
#
# VOLUME RECOVERY
#
# When mirrored VxVM volumes are started during the package control
# bring up, if recovery is required the default behavior is for
# the package control script to wait until recovery has been
# completed.
#
# To allow mirror resynchronization to ocurr in parallel with
# the package startup, uncomment the line
# VXVOL="vxvol -g \$DiskGroup -o bg startall" and comment out the default.
#
# VXVOL="vxvol -g \$DiskGroup -o bg startall"
VXVOL="vxvol -g \$DiskGroup startall"      # Default

# FILESYSTEM UNMOUNT COUNT
# Specify the number of unmount attempts for each filesystem during package
# shutdown.  The default is set to 1.
FS_UMOUNT_COUNT=1

# FILESYSTEM MOUNT RETRY COUNT.
# Specify the number of mount retrys for each filesystem. 
# The default is 0. During startup, if a mount point is busy 
# and FS_MOUNT_RETRY_COUNT is 0, package startup will fail and 
# the script will exit with 1.  If a mount point is busy and
# FS_MOUNT_RETRY_COUNT is greater than 0, the script will attempt 
# to kill the user responsible for the busy mount point 
# and then mount the file system.  It will attempt to kill user and
# retry mount, for the number of times specified in FS_MOUNT_RETRY_COUNT.
# If the mount still fails after this number of attempts, the script
# will exit with 1.
# NOTE: If the FS_MOUNT_RETRY_COUNT > 0, the script will execute
# "fuser -ku" to freeup busy mount point.
FS_MOUNT_RETRY_COUNT=0

#
# Configuring the concurrent operations below can be used to improve the 
# performance for starting up or halting a package.  The maximum value for 
# each concurrent operation parameter is 1024.  Set these values carefully.  
# The performance could actually decrease if the values are set too high 
# for the system resources available on your cluster nodes.  Some examples 
# of system resources that can affect the optimum number of concurrent 
# operations are: number of CPUs, amount of available memory, the kernel 
# configuration for nfile and nproc. In some cases, if you set the number 
# of concurrent operations too high, the package may not be able to start
# or to halt.  For example, if you set CONCURRENT_VGCHANGE_OPERATIONS=5 
# and the node where the package is started has only one processor, then 
# running concurrent volume group activations will not be beneficial. 
# It is suggested that the number of concurrent operations be tuned 
# carefully, increasing the values a little at a time and observing the 
# effect on the performance, and the values should never be set to a value 
# where the performance levels off or declines.  Additionally, the values 
# used should take into account the node with the least resources in the 
# cluster, and how many other packages may be running on the node.  
# For instance, if you tune the concurrent operations for a package so 
# that it provides optimum performance for the package on a node while 
# no other packages are running on that node, the package performance 
# may be significantly reduced, or may even fail when other packages are 
# already running on that node.
#
# CONCURRENT VGCHANGE OPERATIONS
# Specify the number of concurrent volume group activations or
# deactivations to allow during package startup or shutdown. 
# Setting this value to an appropriate number may improve the performance
# while activating or deactivating a large number of volume groups in the
# package. If the specified value is less than 1, the script defaults it 
# to 1 and proceeds with a warning message in the package control script 
# logfile. 
CONCURRENT_VGCHANGE_OPERATIONS=1

# CONCURRENT FSCK OPERATIONS
# Specify the number of concurrent fsck to allow during package startup. 
# Setting this value to an appropriate number may improve the performance
# while checking a large number of file systems in the package. If the
# specified value is less than 1, the script defaults it to 1 and proceeds 
# with a warning message in the package control script logfile. 
CONCURRENT_FSCK_OPERATIONS=1

# CONCURRENT MOUNT AND UMOUNT OPERATIONS
# Specify the number of concurrent mounts and umounts to allow during 
# package startup or shutdown. 
# Setting this value to an appropriate number may improve the performance
# while mounting or un-mounting a large number of file systems in the package.
# If the specified value is less than 1, the script defaults it to 1 and
# proceeds with a warning message in the package control script logfile. 
CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS=1

# Example:  If a package uses 50 JFS filesystems, pkg01aa through pkg01bx,
# which are mounted on the 50 logical volumes lvol1..lvol50 for read and write 
# operation, you may enter the following:
#
#      CONCURRENT_FSCK_OPERATIONS=50
#      CONCURRENT_MOUNT_AND_UMOUNT_OPERATIONS=50
#
#      LV[0]=/dev/vg01/lvol1; FS[0]=/pkg01aa; FS_MOUNT_OPT[0]="-o rw";
#      FS_UMOUNT_OPT[0]="-s"; FS_FSCK_OPT[0]="-s"; FS_TYPE[0]="vxfs"
#
#      LV[1]=/dev/vg01/lvol2; FS[1]=/pkg01ab; FS_MOUNT_OPT[1]="-o rw"
#      FS_UMOUNT_OPT[1]="-s"; FS_FSCK_OPT[1]="-s"; FS_TYPE[0]="vxfs"
#         :           :          :
#         :           :          :
#         :           :          :
#      LV[49]=/dev/vg01/lvol50; FS[49]=/pkg01bx; FS_MOUNT_OPT[49]="-o rw"
#      FS_UMOUNT_OPT[49]="-s"; FS_FSCK_OPT[49]="-s"; FS_TYPE[0]="vxfs"
#
# IP ADDRESSES
# Specify the IP and Subnet address pairs which are used by this package.
# You could specify IPv4 or IPv6 IP and subnet address pairs.
# Uncomment IP[0]="" and SUBNET[0]="" and fill in the name of your first
# IP and subnet address. You must begin with IP[0] and SUBNET[0] and 
# increment the list in sequence.
#
# For example, if this package uses an IP of 192.10.25.12 and a subnet of 
# 192.10.25.0 enter:
#          IP[0]=192.10.25.12 
#          SUBNET[0]=192.10.25.0
#          (netmask=255.255.255.0)
#
# Hint: Run "netstat -i" to see the available subnets in the Network field.
#
# For example, if this package uses an IPv6 IP of 2001::1/64 
# The address prefix identifies the subnet as 2001::/64 which is an available
# subnet.
# enter:
#          IP[0]=2001::1
#          SUBNET[0]=2001::/64
#          (netmask=ffff:ffff:ffff:ffff::)
# Alternatively the IPv6 IP/Subnet pair can be specified without the prefix 
# for the IPv6 subnet.
#          IP[0]=2001::1
#          SUBNET[0]=2001::
#          (netmask=ffff:ffff:ffff:ffff::)
#
# Hint: Run "netstat -i" to see the available IPv6 subnets by looking
# at the address prefixes
# IP/Subnet address pairs for each IP address you want to add to a subnet 
# interface card.  Must be set in pairs, even for IP addresses on the same
# subnet.
#
IP[0]="192.39.51.100"
SUBNET[0]="192.39.48.0"

# SERVICE NAMES AND COMMANDS.
# Specify the service name, command, and restart parameters which are 
# used by this package. Uncomment SERVICE_NAME[0]="", SERVICE_CMD[0]="",
# SERVICE_RESTART[0]="" and fill in the name of the first service, command,
# and restart parameters. You must begin with SERVICE_NAME[0], SERVICE_CMD[0],
# and SERVICE_RESTART[0] and increment the list in sequence.
#
# For example:
#          SERVICE_NAME[0]=pkg1a 
#          SERVICE_CMD[0]="/usr/bin/X11/xclock -display 192.10.25.54:0"
#          SERVICE_RESTART[0]=""  # Will not restart the service.
#
#          SERVICE_NAME[1]=pkg1b
#          SERVICE_CMD[1]="/usr/bin/X11/xload -display 192.10.25.54:0"
#          SERVICE_RESTART[1]="-r 2"   # Will restart the service twice.
#
#          SERVICE_NAME[2]=pkg1c
#          SERVICE_CMD[2]="/usr/sbin/ping"
#          SERVICE_RESTART[2]="-R" # Will restart the service an infinite 
#                                    number of times.
#
# Note: No environmental variables will be passed to the command, this 
# includes the PATH variable. Absolute path names are required for the
# service command definition.  Default shell is /usr/bin/sh.
#
SERVICE_NAME[0]="xclock"
SERVICE_CMD[0]="/usr/bin/X11/xclock -display 192.39.51.96:0.0"
SERVICE_RESTART[0]=""

# DEFERRED_RESOURCE NAME
# Specify the full path name of the 'DEFERRED' resources configured for
# this package.  Uncomment DEFERRED_RESOURCE_NAME[0]="" and fill in the
# full path name of the resource.
#
#DEFERRED_RESOURCE_NAME[0]=""
       
# DTC manager information for each DTC.
# Example: DTC[0]=dtc_20
#DTC_NAME[0]=
       
# HA_NFS_SCRIPT_EXTENSION
# If the package uses HA NFS, this variable can be used to alter the
# name of the HA NFS script.  If not set, the name of this script is
# assumed to be "hanfs.sh".  If set, the "sh" portion of the default
# script name is replaced by the value of this variable.  So if
# HA_NFS_SCRIPT_EXTENSION is set to "package1.sh", for example, the name
# of the HA NFS script becomes "hanfs.package1.sh".  In any case,
# the HA NFS script must be placed in the same directory as the package
# control script.  This allows multiple packages to be run out of the
# same directory, as needed by SGeSAP.
#HA_NFS_SCRIPT_EXTENSION=""
 
# Setting the log file
log_file=${SG_SCRIPT_LOG_FILE:-$0.log}

# START OF CUSTOMER DEFINED FUNCTIONS

# This function is a place holder for customer define functions.
# You should define all actions you want to happen here, before the service is
# started.  You can create as many functions as you need.  

function customer_defined_run_cmds
{
# ADD customer defined run commands.
: # do nothing instruction, because a function must contain some command.

	test_return 51
}
       
# This function is a place holder for customer define functions.
# You should define all actions you want to happen here, after the service is
# halted.

function customer_defined_halt_cmds
{
# ADD customer defined halt commands.
: # do nothing instruction, because a function must contain some command.
	test_return 52
}
       
# END OF CUSTOMER DEFINED FUNCTIONS

変更点について説明します。

本来、xclock自体は共有ディスク上のデータを必要としなくとも動作するのですが、今回は共有ボリュームグループもパッケージの一部にすることとして、あらかじめ作成しておいたボリュームグループ/dev/vgdataがアクティブ化されるように指定します。

VG[0]="vgdata"

また、パッケージの起動時に論理ボリューム/dev/vgdata/lvol1上のファイルシステムが/mnt1にマウントされるような指定をします。

LV[0]="/dev/vgdata/lvol1"
FS[0]="/mnt1"
FS_MOUNT_OPT[0]=""
FS_UMOUNT_OPT[0]=""
FS_FSCK_OPT[0]=""
FS_TYPE[0]="vxfs"

パッケージに付与する一意的なIPアドレス(リロケータブルIP)と、パッケージが使用するデータLANのサブネットアドレスを指定します。このリロケータブルIPは、パッケージpkg1がフェイルオーバーすると一緒に代替ノードに移動します。

IP[0]="192.39.51.100"
SUBNET[0]="192.39.48.0"

最後にパッケージ構成ファイルで指定したサービスxclockを起動させるコマンドを指定します。

SERVICE_NAME[0]="xclock"
SERVICE_CMD[0]="/usr/bin/X11/xclock -display 192.39.51.96:0.0"
SERVICE_RESTART[0]=""

SERVICE_RESTART[0]はここでは何も指定していません。これは、xclockが通常稼動しているノードfred上でダウンした場合、同一ノードfred上で何回までxclockの再起動を試みさせるかの指定を行うパラメータです。何も指定していなければ(今回のケース)、xclockがノードfred上でダウンするとただちに代替ノードgingerにフェイルオーバーします。SERVICE_RESTART[0]="-r 3"のように指定すると同一ノード上で3回まで再起動を試み、4回目にダウンしたときに初めて代替ノードgingerにフェイルオーバーします。さらに、SERVICE_RESTART[0]="-R"と指定すると同一ノード上で何回でも再起動を試みます。


9.1.3. パッケージコントロールスクリプトの配布

パッケージ構成ファイルの整合性の検証が行われたら、パッケージコントロールスクリプトをクラスターの各ノードに配布します。今回の場合、ここまでの作業はノードfred上で行っているため、/etc/cmcluster/pkg1/pkg1.shはfred上にのみ存在します。これをノードgingerにコピーします。

まずginger上に/etc/cmcluster/pkg1というディレクトリを作成して、ディレクトリパーミッションを 755 に設定します。

# mkdir /etc/cmcluster/pkg1
# chmod 755 /etc/cmcluster/pkg1

次にfred上からgingerにパッケージコントロールスクリプトをコピーします。

# rcp /etc/cmcluster/pkg1/pkg1.sh ginger:/etc/cmcluster/pkg1/pkg1.sh

なお、パッケージ構成ファイルはクラスター内の各ノードに存在する必要はありません。しかし、バックアップという意味で、あるいはginger上でもパッケージの構築操作を行えるようにしておきたいという場合には、パッケージ構成ファイルもgingerにコピーしておくとよいでしょう。

9.1.4. パッケージ構成ファイルの整合性の検証

cmcheckconf コマンドにより、パッケージ構成ファイルの整合性の検証を行います。

# cmcheckconf -v -P /etc/cmcluster/pkg1/pkg1.conf

ここで、整合性の検証が行われているのがパッケージ構成ファイルのみであり、パッケージコントロールスクリプトについては検証は行われないことに注意してください。パッケージコントロールスクリプトの記述に問題がある場合には、パッケージが正しく起動しなかったりといった問題が発生します。その場合には、パッケージコントロールスクリプトのデバッグを行うわけですが、その際、パッケージコントロールスクリプトのログファイル (今回の場合、/etc/cmcluster/pkg1/pkg1.sh.log という名前で作成されます) の内容が参考になります。

9.1.5. パッケージの構築

最後にcmapplyconfコマンドによりパッケージを構築してクラスターに組み込みます。

# cmapplyconf -v -P /etc/cmcluster/pkg1/pkg1.conf

以上でパッケージの構築作業は終了です。クラスターを cmruncl コマンドによって起動すると、パッケージが自動的に起動します。

# cmruncl -v

9.2. モジュラーパッケージによるパッケージの作成

9.2.1. パッケージモジュール

モジュラーパッケージでは、各々のパッケージは、パッケージモジュールとして管理されます。Serviceguardが提供しているモジュールには、パッケージを作成する場合に使用するcmmakepkgコマンド実行時に必ず指定しなければならない基本モジュールと、必要に応じて指定するオプショナルモジュールがあります。基本モジュールには以下のものがあります。
  • failover
    作成するパッケージがフェイルオーバパッケージであることを指定します。
  • multi_node
    作成するパッケージがマルチノードパッケージであることを指定します。
  • system_multi_node
    作成するパッケージがシステムマルチノードパッケージであることを指定します。
オプショナルモジュールには以下のものがあります。
  • dependency
    作成するパッケージが、他の1個または複数個のパッケージに依存する場合に指定します。
  • monitor_subnet
    作成するパッケージに対して監視するサブネットが存在する場合に指定します。
  • package_ip
    作成するフェイルオーバパッケージに対して与えるリロケータブルIPアドレスが存在する場合に指定します。
  • service
    作成するパッケージ内でアプリケーションプログラムを実行する場合に、そのアプリケーションのサービスを指定します。
  • resource
    作成するパッケージに対して、EMS(Event Monitoring Service)を使用してリソースを監視する場合に指定します。
  • volume_group
    作成するパッケージがLVMまたはVxVM上のファイルシステムをマウントする場合、あるいはCVMを使用し、かつCFSを使用しない場合に指定します。
  • filesystem
    作成するパッケージが使用するファイルシステムに対するパラメータ(ファイルシステム名、マウントポイントなど)を指定します。
  • pev
    作成するパッケージが使用する外部スクリプトに渡す環境変数を指定します。
  • external_pre
    作成するパッケージの起動中にはボリュームグループおよびディスクグループがアクティブ化される直前に、停止中にはボリュームグループおよびディスクグループが非アクティブ化された直後に実行されるスクリプトを指定します。
  • external
    作成するパッケージの起動時、および停止時に実行される外部スクリプトを指定します。
  • acp
    作成するパッケージに対するアクセスコントロールポリシーを指定します。
  • all
    作成するパッケージに対するすべてのパラメータを設定可能にしたい場合に指定します。
  • default
    cmmakepkgコマンドを基本モジュールを指定せずに実行する場合に指定します。このモジュールはallモジュールへのシンボリックリンクとなっています。
モジュラーパッケージにおいては、cmmakepkgコマンドの実行時に必要なパッケージのモジュールを選択してパッケージ構成ファイルのテンプレートを作成した後に、これを編集し、cmcheckconfコマンドとcmapplyconfコマンドによって実際にパッケージを作成すればいいことになります。

9.2.2. パッケージ構成ファイルの作成

xclockをサービスとして持つパッケージをpkg1という名前で作成します。パッケージ構成ファイルは上述のレガシーパッケージの場合と同様に、まず cmmakepkgコマンドを使用してパッケージ構成ファイルのテンプレートを作成し、後からこれを修正するという方法で作成します。以下に手順を示します。

/etc/cmcluster 以下に pkg1 という名前のディレクトリを作成してディレクトリパーミッションを 755 に設定します。

# mkdir /etc/cmcluster/pkg1
# chmod 755 /etc/cmcluster/pkg1

パッケージ構成ファイルのテンプレートを作成します。パッケージ pkg1 はフェイルオーバタイプのパッケージなので基本モジュールとして failover を指定します。また、以下のオプショナルモジュールを指定します。
  • package_ip
    パッケージ IP アドレスを使用するために指定します。
  • monitor_subnet
    使用するサブネットを監視するために指定します。
  • service
    サービス用のアプリケーションプログラムxclockを使用するために指定します。
  • volume_group
    パッケージ用のデータのためのボリュームグループを使用するために指定します。
  • filesystem
    共有データをファイルシステム上に置くために指定します。
以上のモジュールを指定して、cmmakepkgによりパッケージ構成ファイルのテンプレートを作成します。

# cmmakepkg -n pkg1 \
-m sg/failover \
-m sg/package_ip \
-m sg/monitor_subnet \
-m sg/service \
-m sg/volume_group \
-m sg/filesystem /etc/cmcluster/pkg1/pkg1.conf

これで/etc/cmcluster/pkg1/pkg1.confという名前でパッケージ構成ファイルのテンプレートが作成されます。このファイルを編集して以下のようにします。太字で示した行が編集した部分です。

# **********************************************************************
# ****** HIGH AVAILABILITY PACKAGE CONFIGURATION FILE (template) *******
# **********************************************************************
# ******* Note: This file MUST be edited before it can be used. ********
# * For complete details about package parameters and how to set them, *
# * consult the Serviceguard manual. 
# **********************************************************************
# 
# "package_name" is the name that is used to identify the package.
#     
# Package names must be unique within a cluster.
#     
# Legal values for package_name:
#   Any string that starts and ends with an alphanumeric character, and 
#   contains only alphanumeric characters, dot(.), dash(-), or underscore(_) 
#   in between.
#   Maximum length is 39 characters. 
#       

package_name			pkg1

# "module_name" specifies the package module from which 
# this package was created. Do not change the module_name. 
# 
# "module_version" indicates the version of the module included in the
# package configuration file. Do not change "module_version".
#     
# Legal values for module_name: 
# Legal values for module_version: (value >=  0).

module_name			sg/basic
module_version			1
module_name			sg/failover
module_version			1
module_name			sg/priority
module_version			1
module_name			sg/package_ip
module_version			1
module_name			sg/monitor_subnet
module_version			1
module_name			sg/service
module_version			1
module_name			sg/volume_group
module_version			1
module_name			sg/filesystem
module_version			1

# "package_type" is the type of package.
#     
# The package_type attribute specifies the behavior for this
# package. Legal values and their meanings are:
# 
#     failover     package runs on one node at a time and if a failure
#                  occurs it can switch to an alternate node.
# 
#     multi_node   package runs on multiple nodes at the same time and
#                  can be independently started and halted on
#                  individual nodes. Failures of package components such
#                  as services, EMS resources  or subnets, will cause
#                  the package to be halted only on the node on which the
#                  failure occurred. Relocatable IP addresses cannot be
#                  assigned to "multi_node" packages.
# 
#     system_multi_node
#                  package runs on all cluster nodes at the same time.
#                  It cannot be started and halted on individual nodes.
#                  Both "node_fail_fast_enabled" and "auto_run" 
#                  must be set to "yes" for this type of package. All 
#                  "services" must have "service_fail_fast_enabled" set 
#                  to "yes". system_multi_node packages are only
#                  supported for use by applications provided by
#                  Hewlett-Packard.
# 
# 
#       Since "multi_node" and "system_multi_node" packages can run on more
#       than one node at a time and do not failover in the event of a
#       package failure, the following parameters cannot be
#       specified when configuring packages of these types:
# 
#          failover_policy
#          failback_policy
# 
#       Since an IP address cannot be assigned to more than one node at a
#       time, relocatable IP addresses cannot be assigned to "multi_node"
#       packages.  If volume groups are used in a "multi_node" package,
#       they must be activated in a shared mode, leaving the application
#       responsible for data integrity. 
# 
#       Shared access requires a shared volume manager.
# 
#       The default value for "package_type" is "failover".
#     
# Legal values for package_type: failover, multi_node, system_multi_node.

package_type			failover

# "node_name" specified which nodes this package can run on.
#     
# Enter the names of the nodes configured to run this package, repeat
# this line for each cluster member node configured to run this package. 
# 
# NOTE: The order in which the nodes are specified here determines the
# order of priority when Serviceguard is deciding where to run the
# package.
#        
# Example : node_name  first_priority_node
#           node_name  second_priority_node
# 
# If all nodes in the cluster can run the package, and order is not
# important, specify "node_name *".
# 
# Example : node_name  *
#     
# Legal values for node_name:
#   "*", or any node name in the cluster.
#   "node name" is any string that starts and ends with an alphanumeric 
#   character, and contains only alphanumeric characters, dot(.), dash(-), 
#   or underscore(_) in between.
#   Maximum name length is 39 characters. 
#       

node_name			fred
node_name			ginger

# "auto_run" defines whether the package is to be started when the
# cluster is started, and if it will fail over automatically.
#     
# Possible values are "yes" and "no".
# The default for "auto_run" is "yes", meaning that the package will be
# automatically started when the cluster is started, and that, in the
# event of a failure the package will be started on an adoptive node.
# If "auto_run is "no", the package is not started when the cluster
# is started, and must be started with the cmrunpkg command.
# 
# "auto_run" replaces "pkg_switching_enabled".
#     
# Legal values for auto_run: yes, no.

auto_run			yes

# "node_fail_fast_enabled" will cause the node to fail if the package fails.
#     
# Possible values are "yes" and "no".  The default for
# "node_fail_fast_enabled" is "no".  In the event of failure, if
# "node_fail_fast_enabled" is set to "yes", Serviceguard will halt the
# node on which the package is running. All system multi-node packages
# must have "node_fail_fast_enabled" set to "yes".
#  
#     
# Legal values for node_fail_fast_enabled: yes, no.

node_fail_fast_enabled			no

# "run_script_timeout" is the number of seconds allowed for the package to start.
# "halt_script_timeout" is the number of seconds  allowed for the package to halt.
#     
# If the start or halt function has not completed in the specified
# number of seconds, the function will be terminated. The default is
# "no_timeout".  Adjust the timeouts as necessary to permit full
# execution of each function.
# 
# Note: The "halt_script_timeout" should be greater than the sum of
# all "service_halt_timeout" values specified for all services.
#     
# Legal values for run_script_timeout: no_timeout, (value > 0).

run_script_timeout			no_timeout

# Legal values for halt_script_timeout: no_timeout, (value > 0).

halt_script_timeout			no_timeout

# "successor_halt_timeout" limits the amount of time
# Serviceguard waits for packages that depend on this package 
# ("successor packages") to halt, before running the halt script of this 
# package.
#      
# Permissible values are 0 - 4294 (specifying the maximum
# number of seconds Serviceguard will wait).
# The default value is "no_timeout", which means Serviceguard
# will wait as long as it takes for the successor packages to halt.
# A timeout of 0 indicates that this package will halt without
# waiting for successors packages to halt
# Example: 
# successor_halt_timeout   no_timeout
# successor_halt_timeout   60
#      
# Legal values for successor_halt_timeout: no_timeout, ( (value >= 0) && (value <= 4294) ).

successor_halt_timeout			no_timeout

# "script_log_file" is the full path name for the package control script log 
# file. The maximum length of the path name is MAXPATHLEN characters long.
#     
# If this parameter is not set, script output is sent to
# $SGRUN/log/.log.
# 
#     
# Legal values for script_log_file: 

script_log_file			$SGRUN/log/$SG_PACKAGE.log

# "operation_sequence" defines the order in which the individual script 
# programs will be executed in the package start action. The package halt action
# will be executed in the reverse order.
# 
# This attribute or list must not be modified. It is not supported if modified. 
#     
# Legal values for operation_sequence: 

operation_sequence			$SGCONF/scripts/sg/volume_group.sh
operation_sequence			$SGCONF/scripts/sg/filesystem.sh
operation_sequence			$SGCONF/scripts/sg/package_ip.sh
operation_sequence			$SGCONF/scripts/sg/service.sh

# "log_level" controls the amount of information printed
# during validation and package startup or shutdown time. 
#      
# "log_level" controls the amount of information printed to stdout when
# the package configuration is validated, and to the script_log_file
# when the package starts up and shuts down. Legal values are 0 through
# 5, where 0 is the least amount of logging and 5 is the most. log_level
# 5 includes all information from level 0 to 5.  The default value is 0.
# 
# 
#      Level 0 : user visible informative messages
#      Level 1 : slightly more detail user visible informative messages
#      Level 2 : messages provide logic flow
#      Level 3 : messages provide detailed data structure information
#      Level 4 : debugging information that provides detailed data
#      Level 5 : function call flow
#     
# Legal values for log_level: ( (value >= 0) && (value <= 5) ).

#log_level			

# "failover_policy" is the policy to be applied when package fails.
#     
# This policy will be used to select a node whenever the package needs
# to be started or restarted.  The default policy is "configured_node".
# This policy means Serviceguard will select nodes in priority order
# from the list of "node_name" entries.
# 
# The alternative policy is "min_package_node". This policy means
# Serviceguard will select from the list of "node_name" entries the
# node, which is running fewest packages when this package needs to
# start.
#     
# Legal values for failover_policy: configured_node, min_package_node.

failover_policy			configured_node

# "failback_policy" is the action to take when a package is not running
# on its primary node.
#     
# This policy will be used to determine what action to take when a
# package is not running on its primary node and its primary node is
# capable of running the package. The default policy is "manual".  The
# "manual" policy means no attempt will be made to move the package back
# to its primary node when it is running on an adoptive node.
# 
# The alternative policy is "automatic". This policy means Serviceguard
# will attempt to move the package back to its primary node as soon as
# the primary node is capable of running the package.
# 
#     
# Legal values for failback_policy: manual, automatic.

failback_policy			manual

# The "priority" parameter specifies the priority of the package.
#     
# This is an optional parameter. Valid values are a number between
# 1 and 3000 or no_priority.  Default is no_priority.
# A smaller number indicates higher priority. A package with a
# numerical priority has higher priority than a package with no_priority.
# 
# If a number is specified, it must be unique in the cluster.
# To help assign unique priorities, HP recommends you use
# priorities in increments of 20. This will allow you
# to add new packages without having to reassign priorities.
# 
# Multi-node and System multi-node package cannot be assigned a priority. 
# 
# This parameter is used only when a package depends on other packages,
# or other packages depend on this package, but can be specified even
# when no dependencies have yet been configured.
# If priority is not configured, the package is assigned the default
# priority value, no_priority.
# 
# Serviceguard gives preference to running the higher priority package.
# This means that, if necessary and if package switching is enabled,
# Serviceguard will halt a lower priority package which is already
# running, and restart it on another node, in order to run a
# higher priority package that directly or indirectly depends on it.
# 
# For example, suppose package pkg1 depends on package pkg2 to
# be up on the same node, both have package switching enabled
# and both are currently up on node node1. If pkg1 needs to
# fail over to node2, it will also need pkg2 to move to node2.
# If pkg1 has higher priority than pkg2, it can force pkg2 to 
# move to node2. Otherwise, pkg1 cannot fail over because pkg2 is
# running on node1.
# Examples of package priorities and failover results:
# 
#        pkg1 priority     pkg2 priority    results
#        20                40               pkg1 is higher; fails over
#        40                20               pkg1 is lower; will not fail over
#        any number        no_priority      pkg1 is higher; fails over
#        no_priority       no_priority      equal priority; will not fail over
#        no_priority       any number       pkg1 is lower; will not fail over
#     
# Legal values for priority: no_priority, ( (value >= 1) && (value <= 3000) ).

priority			no_priority

# ip subnets and addresses
# 
# "ip_subnet" and "ip_address" specify subnets and 
# IP addresses used by this package.
#      
# Enter the network subnet name that is to be used by this package,
# along with all the relocatable IP addresses on this subnet to be used 
# by this package. Repeat these lines as necessary for additional subnet 
# names and relocatable IP addresses. The subnets and relocatable 
# addresses can be IPv4 or IPv6, or a mix of both.
# 
# For example, if this package uses a subnet 192.10.25.0 and 2 IP 
# addresses 192.10.25.12 and 192.10.25.13 enter:
#     ip_subnet           192.10.25.0
#     # (netmask=255.255.255.0)
#     ip_address          192.10.25.12
#     ip_address          192.10.25.13
# 
# Hint: Run "netstat -i" and look at the Network field to see the 
# available subnets.
# 
# For example, if this package uses two IPv6 addresses 2001::1/64 and 2001::2/64, 
# the address prefix identifies the subnet as 2001::/64, which is an available
# subnet.
# Enter:
#     ip_subnet           2001::/64
#     # (netmask=ffff:ffff:ffff:ffff::)
#     ip_address          2001::1
#     ip_address          2001::2
# 
# Alternatively the IPv6 IP/Subnet pair can be specified without the prefix 
# for the IPv6 subnet.
# Enter:
#     ip_subnet           2001:: 
#     # (netmask=ffff:ffff:ffff:ffff::)
#     ip_address          2001::1
#     ip_address          2001::2
# 
# Hint: In this case, run "netstat -i" and look at the address prefixes
# to find the available IPv6 subnets.
# 
# Note that "ip_address" specifies a relocatable IP address, which will 
# be added and removed when the package starts and halts.
# 
# "ip_subnet" replaces the legacy package control script parameter "subnet".
# "ip_address" replaces the legacy package control script parameter "ip".
#      
# Legal values for ip_subnet: <Any String>
# Legal values for ip_address: <Any String>

ip_subnet			192.39.48.0
ip_address			192.39.51.100

# "local_lan_failover_allowed" will allow LANs to be switched locally.
#     
# Possible values are "yes" and "no".
# The default for "local_lan_failover_allowed" is "yes".  In the event of a
# failure, this permits the Serviceguard to switch LANs locally
# (transfer to a standby LAN card).  Adjust as necessary.
# 
# "local_lan_failover_allowed" replaces "net_switching_enabled".
#     
# Legal values for local_lan_failover_allowed: yes, no.

local_lan_failover_allowed			yes

# "monitored_subnet" specifies the addresses of subnets that are to be
#  monitored for this package.
#     
# Enter the network subnet name that is to be monitored for this package.
# Repeat this line as necessary for additional subnet names.  If any of
# the subnets defined goes down, the package will be switched to another
# node that is configured for this package and has all the defined subnets
# available.
# 
# "monitored_subnet" replaces "subnet".
# 
# The monitored_subnet names can be IPv4 or IPv6, or a mix of both.
# 
#  Example : 
#     monitored_subnet           192.10.25.0    # (netmask=255.255.255.0)
#     monitored_subnet           2001::/64      # (netmask=ffff:ffff:ffff:ffff::)
#     monitored_subnet           2001::         # (netmask=ffff:ffff:ffff:ffff::)
#     
# Legal values for monitored_subnet: 

monitored_subnet			192.39.48.0

# "cluster_interconnect_subnet" specifies subnets that are to be monitored for 
#  a SGeRAC multi-node package.
#     
# This parameter requires an IPV4 address. cluster_interconnect_subnets 
# can be configured only for multi_node packages in SGeRAC configurations.
# 
# Legal values for cluster_interconnect_subnet: 

#cluster_interconnect_subnet			

# Services: A service is an long lived (daemon) executable which
# Serviceguard will monitor while the package is up.
# 
# "service_name", "service_cmd", "service_restart", "service_fail_fast_enabled" 
# and "service_halt_timeout" specify a service for this package.
#     
# "service_cmd" is the command line to be executed to start the service.
# 
# The value for "service_restart" can be "unlimited", "none" or any
# positive integer value. If the value is "unlimited" the service will be
# restarted an infinite number of times. If the value is "none", the
# service will not be restarted. If the value is a positive integer,
# the service will be restarted the specified number of times
# before failing. The default is "none".
# 
# The value for "service_fail_fast_enabled" can be either "yes" or 
# "no".  The default is "no". If "service_fail_fast_enabled" is set to 
# "yes", and the service fails, Serviceguard will halt the node on which
# the service is running.
# 
# "service_halt_timeout" is a number of seconds.
# This timeout is used to determine the length of time     
# Serviceguard will wait for the service to halt before a SIGKILL signal 
# is sent to force the termination of the service.  In the event of a 
# service halt, Serviceguard will first send a SIGTERM signal to 
# terminate the service.  If the service does not halt, Serviceguard will
# wait for the specified "service_halt_timeout", then send
# the SIGKILL signal to force the service to terminate. 
# This timeout value should be large enough to allow all cleanup
# processes associated with the service to complete.  If the   
# "service_halt_timeout" is not specified, a zero timeout will be
# assumed, meaning the cluster software will not wait at all   
# before sending the SIGKILL signal to halt the service.       
# 
# Example: 
#     service_name               service_1a           
#     service_cmd                "/usr/bin/X11/xclock -display 192.10.25.54:0"
#     service_restart            none
#     service_fail_fast_enabled  no                   
#     service_halt_timeout       300                  
# 
#     service_name               service_1b
#     service_cmd                "/usr/bin/X11/xload -display 192.10.25.54:0"
#     service_restart            2
#     service_fail_fast_enabled  no                   
#     service_halt_timeout       300                  
# 
#     service_name               service_1c
#     service_cmd                "/usr/sbin/ping node_a"
#     service_restart            unlimited
#     service_fail_fast_enabled  no                   
#     service_halt_timeout       300                  
# 
# Note: Default shell is /usr/bin/sh.
#     
# Legal values for service_name:
#   Any string that starts and ends with an alphanumeric character, and 
#   contains only alphanumeric characters, dot(.), dash(-), or underscore(_) 
#   in between.
#   Maximum string length is 39 characters. 
#       
# Legal values for service_cmd: 
# Legal values for service_restart: none, unlimited, (value > 0).
# Legal values for service_fail_fast_enabled: yes, no.
# Legal values for service_halt_timeout: (value >= 0).

service_name			xclock
service_cmd			"/usr/bin/X11/xclock -display 192.39.51.96:0.0"
service_restart			none
service_fail_fast_enabled		no
service_halt_timeout		300

# "concurrent_vgchange_operations" is the number of concurrent volume 
# group operations allowed.
#      
# Volume, CVM disk and VxVM disk groups
# 
# concurrent vgchange operations
# Specify the number of concurrent volume group activations or
# deactivations to allow during package startup or shutdown. The default
# is 1.  Setting this value to an appropriate number may improve
# performance when the package needs to activate or deactivate a large
# number of volume groups.
#      
# Legal values for concurrent_vgchange_operations: (value > 0).

concurrent_vgchange_operations			1

# "vgchange_cmd" is the method of activation for LVM volume groups.
#      
# volume group activation: 
# Specify the method of activation for volume groups.
# Leave the default (vgchange_cmd  "vgchange -a e") if you want volume
# groups activated in exclusive mode. This assumes the volume groups have
# been initialized with "vgchange -c "' at the time of creation.
# 
# Uncomment the first line (vgchange_cmd  "vgchange -a e -q n"), and comment 
# out the default, if your disks are mirrored on separate physical paths,
# 
# Uncomment the second line (vgchange_cmd  "vgchange -a e -q n -s"), and 
# comment out the default, if your disks are mirrored on separate physical
# paths, and you want the mirror resynchronization to occur in parallel
# with the package startup.
# 
# Uncomment the third line (vgchange_cmd  "vgchange -a s"), and comment
# out the default, if you want volume groups activated in shared mode. 
# 
# Uncomment the fourth line (vgchange_cmd  "vgchange -a s -q n"), and comment 
# out the default, if you want volume groups activated in shared mode, 
# and your disks are mirrored on separate physical paths,
# 
# Uncomment the fifth line (vgchange_cmd  "vgchange -a y") if you wish to 
# use non-exclusive activation mode. Single node cluster configurations
# must use non-exclusive activation.
# 
# vgchange_cmd              "vgchange -a e -q n"
# vgchange_cmd              "vgchange -a e -q n -s"
# vgchange_cmd              "vgchange -a s"
# vgchange_cmd              "vgchange -a s -q n"
# vgchange_cmd              "vgchange -a y"
# 
# "vgchange_cmd" replaces the legacy package control script parameter "vgchange".
#      
# Legal values for vgchange_cmd: 

vgchange_cmd			"vgchange -a e"

# "cvm_activation_cmd" is the method of activation for CVM disk groups.
#      
# CVM disk group activation: 
# Specify the method of activation for CVM disk groups.
# Leave the default
# (cvm_activation_cmd  vxdg -g \${DiskGroup} set activation=exclusivewrite)
# if you want disk groups activated in the exclusive write mode.
# 
# Uncomment the first line
# (cvm_activation_cmd  vxdg -g \${DiskGroup} set activation=readonly),
# and comment out the default, if you want disk groups activated in
# the readonly mode.
# 
# Uncomment the second line
# (cvm_activation_cmd  vxdg -g \${DiskGroup} set activation=sharedread),
# and comment out the default, if you want disk groups activated in the
# shared read mode.
# 
# Uncomment the third line
# (cvm_activation_cmd  vxdg -g \${DiskGroup} set activation=sharedwrite),
# and comment out the default, if you want disk groups activated in the
# shared write mode.
# 
# cvm_activation_cmd  "vxdg -g \${DiskGroup} set activation=readonly"
# cvm_activation_cmd  "vxdg -g \${DiskGroup} set activation=sharedread"
# cvm_activation_cmd  "vxdg -g \${DiskGroup} set activation=sharedwrite"
#      
# Legal values for cvm_activation_cmd: 

cvm_activation_cmd			"vxdg -g \${DiskGroup} set activation=exclusivewrite"

# Volume Recovery
# 
# "vxvol_cmd" is the method of recovery for mirrored VxVM volumes.
#      
# When mirrored VxVM volumes are started during the package control
# startup, and mirror resynchronization is required, the default behavior is for
# the package control script to wait until the resynchronization has been
# completed.
# 
# To allow mirror resynchronization to occur in parallel with
# the package startup, uncomment the line
# vxvol_cmd  "vxvol -g \${DiskGroup} -o bg startall" and comment 
# out the default.
# 
# vxvol_cmd  "vxvol -g \${DiskGroup} -o bg startall"
# 
# "vxvol_cmd" replaces the legacy package control script parameter "vxvol".
#      
# Legal values for vxvol_cmd: 

vxvol_cmd			"vxvol -g \${DiskGroup} startall"

# "vg" is used to specify which volume groups are used by this package.
#      
# volume groups
# 
# Specify which volume groups are used by this package that do not yet 
# have file systems mounted on them. Copy one of the example vg configuration
# line and change the name of the volume group. Add additional VG 
# specifications for additional volume groups.
# 
# For example, if this package uses your volume groups vg01 and vg02, enter:
#     vg       vg01
#     vg       vg02
# 
# The volume group activation method is defined above. Use the parameters
# in the filesystem module (fs_name, etc.) to specify the filesystems
# associated with these volume groups.
#      
# Legal values for vg: /^[0-9A-Za-z\/][0-9A-Za-z_.\-\/]*[0-9A-Za-z]$/, /^[0-9A-Za-z]$/.

vg			vgdata

# CVM disk groups
# 
# "cvm_dg" is to specify which cvm disk groups are used by this package.
#      
# Specify which CVM disk groups are used by this package. Copy the one
# of the line from the example and change the name to be your first 
# disk group. You must specify cvm disk groups whether file systems 
# are mounted or not.  Add additional "cvm_dg" specifications for 
# additional cvm disk groups.
# 
# For example, if this package uses your disk groups dg01 and dg02, enter:
#     cvm_dg    dg01
#     cvm_dg    dg02
# 
# The CVM disk group activation method is defined above. The filesystems
# associated with these volume groups can be specified with the filesystem
# module.
#      
# Legal values for cvm_dg: /^[0-9A-Za-z][0-9A-Za-z_.\-]*[0-9A-Za-z]$/, /^[0-9A-Za-z]$/.

#cvm_dg			

# VxVM disk groups
# 
# "vxvm_dg" is used to specify which VxVM disk groups are used by this package.
#      
# Enter the name of VxVM disk group that is used by this package and
# that does not have file systems mounted on it. Repeat this line for
# each additional VxVM disk group.
# 
# For example, if this package uses your disk groups dg01 and dg02, enter:
#     vxvm_dg    dg01
#     vxvm_dg    dg02
# 
# The cvm disk group activation method is defined above.
# 
# NOTE: A package can have a mix of LVM volume groups, CVM disk groups and VxVM 
#       disk groups.
# 
# NOTE: When VxVM is initialized it will store the hostname of the
#       local node in its volboot file in a variable called 'hostid'.
#       The Serviceguard package control scripts use both 
#       the hostname(1m) command and the VxVM hostid. This means you 
#       must make sure that the VxVM hostid matches the output of the
#       hostname(1m) command.
# 
#       If you modify the local host name after VxVM has been
#       initialized and such that hostname(1m) does not equal the
#       name returned by uname -n, you need to use the vxdctl(1m) 
#       command to set the VxVM hostid field to the value of 
#       hostname(1m). Failure to do so will result in the package 
#       failing to start.
#      
# Legal values for vxvm_dg: /^[0-9A-Za-z][0-9A-Za-z_.\-]*[0-9A-Za-z]$/, /^[0-9A-Za-z]$/.

#vxvm_dg			

# "deactivation_retry_count" specifies the number of deactivation retries
# at package shutdown..
#      
# volume group and disk group deactivation retry count
# 
# Specify the number of deactivation retries for each disk group and volume 
# group.
# 
# The default is 2. 
#     
# Legal values for deactivation_retry_count: (value >= 0).

deactivation_retry_count			2

# "kill_processes_accessing_raw_devices" specifies whether to kill processes 
# accessing raw devices at package halt time.
#      
# Raw Devices
# 
# If raw devices are still being accessed at package halt time, volume
# group or disk group deactivation can fail, causing the package halt to
# also fail. This problem usually happens when the application does not
# shut down properly.
# 
# Note that if you are using Oracle's Cluster Ready Service, killing this 
# service could cause the node to reboot. 
# 
# The value that is set for this parameter affects all raw devices associated 
# with the LVM volume groups and CVM disk groups defined in the package. 
# 
# The default is "no". 
#     
# Legal values for kill_processes_accessing_raw_devices: yes, no.

kill_processes_accessing_raw_devices			no

# "concurrent_fsck_operations" specifies the number of concurrent fsck
# operations.
#      
# FILESYSTEMS
# 
# Filesystems are defined by entries specifying the logical volume, the
# mount point, the options for mount, umount and fsck, and the type of
# the file system.
# Each filesystem will be fsck'd prior to being mounted. The filesystems 
# will be mounted in the order specified during package startup and will 
# be unmounted in reverse order during package shutdown. Ensure that 
# volume groups referenced by the logical volume definitions below are 
# included in volume group definitions ("vg") above.
# 
# concurrent_fsck_operations
# 
# Specify the number of concurrent fsck operation to allow during
# package startup.  Setting this value to an appropriate number may
# improve performance if a large number of file systems need to be
# checked. The default is 1.
#      
# Legal values for concurrent_fsck_operations: (value > 0).

concurrent_fsck_operations			1

# "concurrent_mount_and_umount_operations" specifies
# the number of concurrent mounts and umounts to allow during
# package startup and shutdown.
#      
# Setting this value to an appropriate number may improve the performance
# if the package needs to mount and un-mount a large number of file
# systems. The default is 1.
# 
# Example:  If a package uses 50 JFS filesystems, pkg01aa through pkg01bx,
# which are mounted on the 50 logical volumes lvol1..lvol50 for read and write
# operation, you may enter the following:
# 
#      concurrent_fsck_operations 50
#      concurrent_mount_and_umount_operations 50
# 
#      fs_name /dev/vg01/lvol1
#      fs_directory /pkg01aa
#      fs_mount_opt "-o rw"
#      fs_umount_opt "-s"
#      fs_fsck_opt "-s"
#      fs_type "vxfs"
# 
#      fs_name /dev/vg01/lvol2
#      fs_directory /pkg01ab
#      fs_mount_opt "-o rw"
#      fs_umount_opt "-s"
#      fs_fsck_opt "-s"
#      fs_type "vxfs"
# 
#      :
#      :
#      :
# 
#      fs_name /dev/vg01/lvol50
#      fs_directory /pkg01bx
#      fs_mount_opt "-o rw"
#      fs_umount_opt "-s"
#      fs_fsck_opt "-s"
#      fs_type "vxfs"
#      
# Legal values for concurrent_mount_and_umount_operations: (value > 0).

concurrent_mount_and_umount_operations			1

# "fs_mount_retry_count" specifies the number of mount retries.
#      
# The default is 0. During startup, if a mount point is busy 
# and "fs_mount_retry_count" is 0, package startup will fail and 
# the script will exit with 1.  If a mount point is busy and
# "fs_mount_retry_count" is greater than 0, the script will attempt 
# to kill the user process responsible for the busy mount point 
# ("fuser -ku") and then mount the file system.  It will 
# do this the number of times specified in "fs_mount_retry_count".
# If the mount still fails after this number of attempts, the script
# will exit with 1.
# 
#      
# Legal values for fs_mount_retry_count: (value >= 0).

fs_mount_retry_count			0

# "fs_umount_retry_count" specifies the number of unmount retries for
# each filesystem during package shutdown.
#      
# The default is 1.  During package halt time, if a mount point is busy
# the script will attempt to kill the user responsible for the busy
# mount point and then umount the file system.  It will attempt to kill
# user and retry umount, for the number of times specified in
# "fs_umount_retry_count".  If the umount still fails after this number
# of attempts, the script will exit with 1.
# 
# NOTE: The script will execute "fuser -ku" to free up busy mount point by
# default.
# 
# "fs_umount_retry_count" replaces the legacy package control script
# parameter "fs_umount_count".
#      
# Legal values for fs_umount_retry_count: (value > 0).

fs_umount_retry_count			1

# "fs_name", "fs_directory", "fs_mount_opt", "fs_umount_opt", "fs_fsck_opt", and 
# "fs_type" specify the filesystems which are used by this package.
#      
# Note: The "fs_type" parameter lets you specify the type of filesystem to be 
# mounted. Specifying a particular "fs_type" will improve package failover time.  
# The "fsck_opt" and "fs_umount_opt" parameters can be used to include the 
# -s option with the fsck and umount commands to improve performance for 
# environments that use a large number of filesystems. (An example of a 
# large environment is given below following the description of the 
# "concurrent_mount_and_umount_operations" parameter.)
# 
# Example: If a package uses two JFS filesystems, pkg01a and pkg01b, 
# which are mounted on LVM logical volumes lvol1 and lvol2 for read and 
# write operation, you would enter the following:
# 
#     fs_name          /dev/vg01/lvol1
#     fs_directory     /pkg01a
#     fs_type          "vxfs"
#     fs_mount_opt     "-o rw"
#     fs_umount_opt    ""
#     fs_fsck_opt      ""
# 
#     FS_NAME          /dev/vg01/lvol2
#     FS_DIRECTORY     /pkg02a
#     FS_TYPE          "vxfs"
#     FS_MOUNT_OPT     "-o rw"
#     FS_UMOUNT_OPT    ""
#     FS_FSCK_OPT      ""
# 
# "fs_name" replaces the legacy package control script parameter "lv".
# 
# "fs_directory" replaces the legacy package control script parameter "fs".
#      
# Legal values for fs_name: /^[^"|]+$/.
# Legal values for fs_directory: /^[^"|]+$/.
# Legal values for fs_type: 
# Legal values for fs_mount_opt: 
# Legal values for fs_umount_opt: 
# Legal values for fs_fsck_opt: 

fs_name			/dev/vgdata/lvol1
fs_directory		/mnt1
fs_type			"vxfs"
fs_mount_opt		"-o rw"
fs_umount_opt		""
fs_fsck_opt		""

パッケージ名pkg1は cmmakepkg コマンドの実行時に指定したとおりpkg1に設定されています。pkg1は通常はノードfred上で動作し、fredにノード障害が発生した場合はgingerにフェイルオーバーするものとします。したがって、package_typeはfailoverを使用します。faioover_policyはパッケージのフェイルオーバーの仕方を指定するものです。パッケージ構成ファイルの中で指定したnode_nameの順にフェイルオーバーさせたい場合はconfigured_nodeを、動作しているパッケージ数が最も少ないノードにフェイルオーバーさせたい場合はmin_package_nodeを指定します。ここでは、node_nameのならび(fred、ginger)の順番にフェイルオーバーさせることとし、configured_nodeを選択しています。failback_policyはフェイルオーバーしたパッケージの元のノードへの切り戻しを行う際に、手動(manual)で行うか、自動(automatic)で行うかを指定するパラメータです。ここでは手動、つまりmanualを選択しています。クラスター起動時にパッケージも一緒に起動するようにパラメータauto_runをyesに設定しています。このパッケージのデータLAN用のLANカードは二重化してあり、Serviceguardのローカルスイッチを有効にするためにパラメータlocal_lan_failoverをyesに設定しています。パラメータnode_fail_fast_enabledがnoに設定してありますが、このように設定しておくと、パッケージ内のアプリケーションになんらかの障害が発生した場合、後述するパッケージコントロールスクリプト内で指定されたパッケージ停止の処理を行ってから代替ノードへのフェイルオーバーを行います。このパラメータをyesに設定すると、パッケージ内のアプリケーションになんらかの障害が発生した場合、そのノードはただちにTOCにより停止します。つまり、フェイルオーバーの時間を短くすることができます。

モジュラーパッケージの場合は、パッケージの起動は /etc/cmcluster/scripts/mscripts 以下に存在するマスターコントロールスクリプトによって行われます (これを編集する必要はありません)。このスクリプトのタイムアウト時間を指定するrun_script_timeoutとhalt_script_timeoutはここではデフォルトのno_timeout(タイムアウトなし)にしています。

パッケージに付与する一意的な IP アドレス (リロケータブル IP) と、パッケージが使用するデータ LAN のサブネットアドレスを指定します。このリロケータブル IP は、パッケージ pkg1 がフェイルオーバーすると一緒に代替ノードに移動します。

ip_subnet			192.39.48.0
ip_address		192.39.51.100

pkg1 が使用するサブネットを monitored_subnet パラメータに設定して Serviceguard により監視が行われるようにします。

monitored_subnet		192.39.48.0

サービスを定義します。パッケージ構成ファイルで指定したサービスxclockを起動させるコマンドを指定します。

service_name			xclock
service_cmd			"/usr/bin/X11/xclock -display 192.39.51.96:0.0"
service_restart			none
service_fail_fast_enabled		no
service_halt_timeout		300

パラメータservice_nameにはxclockを指定しています。この名前は任意に指定できますが、pkg1がxclockをサービスとして持つパッケージなのでこの名前を使用しています。service_restart にはここでは none を指定しています。これは、xclock が通常稼動しているノード fred 上でダウンした場合、同一ノード fred 上で何回まで xclock の再起動を試みさせるかの指定を行うパラメータです。none を指定した場合 (今回のケース)、xclock がノード fred 上でダウンするとただちに代替ノード ginger にフェイルオーバーします。service_restart を 3 のように指定すると同一ノード上で 3 回まで再起動を試み、4 回目にダウンしたときに初めて代替ノード ginger にフェイルオーバーします。さらに、service_restart を unlimited と指定すると同一ノード上で何回でも再起動を試みます。service_fail_fast_enabledはnoに指定しています。このパラメータをyesに指定すると、サービス(この場合 xclockプロセス)に障害(異常終了など)が発生した場合にServiceguardはTOCを発生させて当該ノードをただちに停止させます。また、パラメータservice_halt_timeoutを300秒に指定しています。Serviceguardはサービスを停止させる際、最初にSIGTERMシグナルをそのサービスのプロセスに送付します。service_halt_timeoutで指定した300秒を過ぎてもサービスプロセスが停止していない場合、Serviceguardは当該プロセスにSIGKILLシグナルを送付します。

本来、ここで作成するパッケージ自体は共有ディスク上のデータを必要としなくとも動作するのですが、今回は共有ボリュームグループもパッケージの一部にすることとして、あらかじめ作成しておいたボリュームグループ /dev/vgdata がアクティブ化されるように指定します。

vg			vgdata

また、パッケージの起動時に論理ボリューム /dev/vgdata/lvol1 上のファイルシステムが /mnt1 にマウントさせるような指定をします。

fs_name			/dev/vgdata/lvol1
fs_directory		/mnt1
fs_type			"vxfs"
fs_mount_opt		"-o rw"	
fs_umount_opt		""
fs_fsck_opt		""

その他のパラメータはServiceguardとEMS(Event Monitoring Services)との統合のためのパラメータ、パッケージ依存関係設定のパラメータです。ここではこれらの説明は省きます。詳細はServiceguardのマニュアルを参照してください。

9.2.3. パッケージ構成ファイルの整合性の検証

cmcheckconfコマンドにより、パッケージ構成ファイルの整合性の検証を行います。

# cmcheckconf -v -P /etc/cmcluster/pkg1/pkg1.conf

ここで、整合性の検証が行われているのがパッケージ構成ファイルのみであり、パッケージコントロールスクリプトについては検証は行われないことに注意してください。パッケージコントロールスクリプトの記述に問題がある場合には、パッケージが正しく起動しなかったりといった問題が発生します。その場合には、パッケージコントロールスクリプトのデバッグを行うわけですが、その際、パッケージコントロールスクリプトのログファイル (今回の場合、/var/adm/cmcluster/log/pkg1/pkg1.sh.log という名前で作成されます) の内容が参考になります。

9.2.4. 外部スクリプトの配布

今回の例では外部スクリプトのモジュールexternal_scriptは指定していませんが、サービスの起動などを外部スクリプトで行っている場合には、そのためのスクリプトファイルをクラスターの各ノードに配布します。

なお、パッケージ構成ファイルはクラスター内の各ノードに存在する必要はありません。しかし、バックアップという意味で、あるいはginger上でもパッケージの構築操作を行えるようにしておきたいという場合には、パッケージ構成ファイルもgingerにコピーしておくとよいでしょう。

9.2.5. パッケージの構築

最後にcmapplyconfコマンドによりパッケージを構築してクラスターに組み込みます。

# cmapplyconf -v -P /etc/cmcluster/pkg1/pkg1.conf

以上でパッケージの構築作業は終了です。クラスターを cmruncl コマンドによって起動すると、パッケージも自動的に起動します。

# cmruncl -v
トップへ戻る 前のページへ 次のページへ

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項