26.8 Creating and Updating an ASCII Application Configuration File (cmmakepkg p)

     

26.8 Creating and Updating an ASCII Application Configuration File ( cmmakepkg “p )

Serviceguard is great at giving us tools to establish the configuration of our cluster as well as our application packages. In some ways, cmmakepkg is similar to cmquerycl in that it will create a basic template that we can fill in. Like cmquerycl , cmmakepkg uses a number of reasonable defaults that allow us to configure our package with the minimum of trouble. We look at some of the alternate settings for the parameters within the package configuration file. I have already created a subdirectory under /etc/cmcluster where I put my application monitoring script “ /etc/cmcluster/ clockwatch . The package configuration file is a large file. I list its default content and then show you the lines that I modified:

 

 root@hpeos001[charlesk] #  cd /etc/cmcluster/clockwatch  root@hpeos001[clockwatch] #  cmmakepkg -p clockwatch.conf  Package template is created. This file must be edited before it can be used. root@hpeos001[clockwatch] #  vi clockwatch.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 ServiceGuard OPS Edition manuals ******* # ********************************************************************** # Enter a name for this package. This name will be used to identify the # package when viewing or manipulating it. It must be different from # the other configured package names. PACKAGE_NAME # Enter the package type for this package. PACKAGE_TYPE indicates # whether this package is to run as a FAILOVER or SYSTEM_MULTI_NODE # package. # #    FAILOVER     package runs on one node at a time and if a failure #                 occurs it can switch to an alternate node. # #    SYSTEM_MULTI_NODE #                 package runs on multiple nodes at the same time. #                 It can not 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. # # NOTE: Packages which have a PACKAGE_TYPE of SYSTEM_MULTI_NODE are #       not failover packages and should only be used for applications #       provided by Hewlett-Packard. # #       Since SYSTEM_MULTI_NODE packages run on multiple nodes at #       one time, following parameters are ignored: # #          FAILOVER_POLICY #          FAILBACK_POLICY # #       Since an IP address can not be assigned to more than node at a #       time, relocatable IP addresses can not be assigned in the #       package control script for multiple node packages. If #       volume groups are assigned to multiple node packages they must #       activated in a shared mode and data integrity is left to the #       application. Shared access requires a shared volume manager. # # # Examples : PACKAGE_TYPE   FAILOVER (default) #            PACKAGE_TYPE   SYSTEM_MULTI_NODE # PACKAGE_TYPE                    FAILOVER # Enter the failover policy for this package. This policy will be used # to select an adoptive node whenever the package needs to be started. # The default policy unless otherwise specified is CONFIGURED_NODE. # This policy will select nodes in priority order from the list of # NODE_NAME entries specified below. # # The alternative policy is MIN_PACKAGE_NODE. This policy will select # the node, from the list of NODE_NAME entries below, which is # running the least number of packages at the time this package needs # to start. FAILOVER_POLICY                 CONFIGURED_NODE # Enter the failback policy for this package. 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 unless otherwise specified 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 will attempt to # move the package back to its primary node whenever the primary node # is capable of running the package. FAILBACK_POLICY                 MANUAL # Enter the names of the nodes configured for this package. Repeat # this line as necessary for additional adoptive nodes. # # NOTE:   The order is relevant. #         Put the second Adoptive Node after the first one. # # Example : NODE_NAME  original_node #           NODE_NAME  adoptive_node # # If all nodes in cluster is to be specified and order is not # important, "NODE_NAME *" may be specified. # # Example : NODE_NAME  * NODE_NAME # Enter the value for AUTO_RUN. Possible values are YES and NO. # The default for AUTO_RUN is YES. When the cluster is started the # package will be automatically started. In the event of a failure the # package will be started on an adoptive node. Adjust as necessary. # # AUTO_RUN replaces obsolete PKG_SWITCHING_ENABLED. AUTO_RUN                        YES # Enter the value for LOCAL_LAN_FAILOVER_ALLOWED. # Possible values are YES and NO. # The default for LOCAL_LAN_FAILOVER_ALLOWED is YES. In the event of a # failure, this permits the cluster software to switch LANs locally # (transfer to a standby LAN card). Adjust as necessary. # # LOCAL_LAN_FAILOVER_ALLOWED replaces obsolete NET_SWITCHING_ENABLED. LOCAL_LAN_FAILOVER_ALLOWED      YES # Enter the value for NODE_FAIL_FAST_ENABLED. # Possible values are YES and NO. # The default for NODE_FAIL_FAST_ENABLED is NO. If set to YES, # in the event of a failure, the cluster software will halt the node # on which the package is running. All SYSTEM_MULTI_NODE packages must have # NODE_FAIL_FAST_ENABLED set to YES. Adjust as necessary. NODE_FAIL_FAST_ENABLED          NO # Enter the complete path for the run and halt scripts. 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. # Enter the timeout, specified in seconds, for the run and halt scripts. # If the script has not completed by the specified timeout value, # it will be terminated. The default for each script timeout is # NO_TIMEOUT. Adjust the timeouts as necessary to permit full # execution of each script. # Note: The HALT_SCRIPT_TIMEOUT should be greater than the sum of # all SERVICE_HALT_TIMEOUT specified for all services. RUN_SCRIPT RUN_SCRIPT_TIMEOUT              NO_TIMEOUT HALT_SCRIPT HALT_SCRIPT_TIMEOUT             NO_TIMEOUT # 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 VxVM-CVM-pkg package is # running and thus the CVM shared disk groups are ready for # activation. # # NOTE: Should only be used by applications provided by #       Hewlett-Packard. # # Example : STORAGE_GROUP  dg01 #           STORAGE_GROUP  dg02 #           STORAGE_GROUP  dg03 #           STORAGE_GROUP  dg04 # # Enter the SERVICE_NAME, the SERVICE_FAIL_FAST_ENABLED and the # SERVICE_HALT_TIMEOUT values for this package. Repeat these # three lines as necessary for additional service names. All # service names MUST correspond to the service names used by # cmrunserv and cmhaltserv commands in the run and halt scripts. # # The value for SERVICE_FAIL_FAST_ENABLED can be either YES or # NO. If set to YES, in the event of a service failure, the # cluster software will halt the node on which the service is # running. If SERVICE_FAIL_FAST_ENABLED is not specified, the # default will be NO. # # SERVICE_HALT_TIMEOUT is represented in the number of seconds. # This timeout is used to determine the length of time (in # seconds) the cluster software 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, the cluster # software will first send a SIGTERM signal to terminate the # service. If the service does not halt, after waiting for the # specified SERVICE_HALT_TIMEOUT, the cluster software will send # out the SIGKILL signal to the service to force its termination. # 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                   DB_SERVICE #          SERVICE_FAIL_FAST_ENABLED      NO #          SERVICE_HALT_TIMEOUT           300 # # To configure a service, uncomment the following lines and # fill in the values for all of the keywords. # #SERVICE_NAME                   <service name> #SERVICE_FAIL_FAST_ENABLED      <YES/NO> #SERVICE_HALT_TIMEOUT           <number of seconds> # 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. #SUBNET # The keywords RESOURCE_NAME, RESOURCE_POLLING_INTERVAL, # RESOURCE_START, and RESOURCE_UP_VALUE are used to specify Package # Resource Dependencies. 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. The # RESOURCE_POLLING_INTERVAL and the RESOURCE_START are optional. # # The RESOURCE_POLLING_INTERVAL indicates how often, in seconds, the # resource is to be monitored. It will be defaulted to 60 seconds if # RESOURCE_POLLING_INTERVAL is not specified. # # The RESOURCE_START option can be set to either AUTOMATIC or DEFERRED. # The default setting for RESOURCE_START is AUTOMATIC. If AUTOMATIC # is specified, ServiceGuard will start up resource monitoring for # these AUTOMATIC resources automatically when the node starts up. # If DEFERRED is selected, ServiceGuard will not attempt to start # resource monitoring for these resources during 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 whitespace, 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 # when specifying 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. Package Resource Dependencies may be # 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. # #RESOURCE_NAME              <Full_path_name> #RESOURCE_POLLING_INTERVAL  <numeric_seconds> #RESOURCE_START             <AUTOMATIC/DEFERRED> #RESOURCE_UP_VALUE          <op> <string_or_numeric> [and <op> <numeric>] 

You can find a complete description of all the fields within this file at the end of this chapter.

As mentioned previously, a large number of the configuration parameters have sensible default values. Here are the lines I modified to get my package up and running:

 

 PACKAGE_NAME                    clockwatch 

Here's a unique name for the package within the cluster:

 

 NODE_NAME                       hpeos001 NODE_NAME                       hpeos002 

This is the list of nodes the package will run on. The order of the nodes listed is important, because it is the order in which the application will be run on.

 

 RUN_SCRIPT  /etc/cmcluster/clockwatch/clockwatch.cntl HALT_SCRIPT /etc/cmcluster/clockwatch/clockwatch.cntl 

This is the next Serviceguard configuration file ”the application control script. We will create this in the next step. This script will detail all the components of our application.

 

 SERVICE_NAME                   clock_mon SERVICE_FAIL_FAST_ENABLED      NO SERVICE_HALT_TIMEOUT           300 

The SERVICE_NAME is simply a name to associate with my service process. If I were to set SERVICE_FAIL_FAST_ENABLED to YES , this would mean that in the event of this service process failing, Serviceguard would instigate a Transfer Of Control (TOC) of this node. The SERVICE_HALT_TIMEOUT is the time Serviceguard will give the halt script to complete before sending it a SIGKILL signal. If we have more than one service process, we will repeat these three lines for each service process.

 

 SUBNET                  192.168.0.0 

This is the network address ( netstat “in ) of all the subnets via which this application will be accessed. That is to say the subnets where our clients are located. If we have multiple subnets for this application, we would list them on separate lines.

Later, we compile this ASCII file into the binary cluster configuration file and in turn distribute it to all nodes in the cluster. The next configuration file is the package control script. In our example, that is the file listed above as /etc/cmcluster/clockwatch/clockwatch.cntl .



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net