Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
 Managing Serviceguard Fifteenth Edition > Chapter 6 Configuring Packages and Their Services

Editing the Configuration File
» 

Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Index

spacerspacerspacer
spacer
spacer
  		 
 

When you have generated the configuration file that contains the modules your package needs (see “Generating the Package Configuration File”), you need to edit the file to set the package parameters to the values that will make the package function as you intend.

IMPORTANT: Do not edit the package configuration file of a Veritas Cluster Volume Manager (CVM) or Cluster File System (CFS) multi-node or system multi-node package.

Create VxVM-CVM-pkg or SG-CFS-pkg by means of the cmapplyconf command. Create and modify SG-CFS-DG-id# and SG-CFS-MP-id# using the cfs commands listed in Appendix A “Serviceguard Commands”.

It is a good idea to configure complex failover packages in stages, as follows:

  1. Configure volume groups and mount points only.

  2. Check and apply the configuration; see “Verifying and Applying the Package Configuration”.

  3. Run the package and ensure that it can be moved from node to node.

    NOTE: cmcheckconf and cmapplyconf check for missing mount points, volume groups, etc.

  4. Halt the package.

  5. Configure package IP addresses and application services.

  6. Run the package and ensure that applications run as expected and that the package fails over correctly when services are disrupted. See “Testing the Package Manager ”.

Use the following bullet points as a checklist, referring to the “Package Parameter Explanations”, and the comments in the configuration file itself, for detailed specifications for each parameter.

NOTE: Optional parameters are commented out in the configuration file (with a # at the beginning of the line). In some cases these parameters have default values that will take effect unless you uncomment the parameter (remove the #) and enter a valid value different from the default. Read the surrounding comments in the file, and the explanations in this chapter, to make sure you understand the implications both of accepting and of changing a given default.

In all cases, be careful to uncomment each parameter you intend to use and assign it the value you want it to have.

  • package_name. Enter a unique name for this package. Note that there are stricter formal requirements for the name as of A.11.18.

  • package_type. Enter failover, multi_node, or system_multi_node. (system_multi_node is reserved for special-purpose packages supplied by HP.) Note that there are restrictions if another package depends on this package; see “About Package Dependencies”.

    See “Types of Package: Failover, Multi-Node, System Multi-Node” for more information.

  • node_name. Enter the name of each cluster node on which this package can run, with a separate entry on a separate line for each node.

  • auto_run. For failover packages, enter yes to allow Serviceguard to start the package on the first available node specified by node_name, and to automatically restart it later if it fails. Enter no to keep Serviceguard from automatically starting the package.

  • node_fail_fast_enabled. Enter yes to cause the node to be halted (system reset) if the package fails; otherwise enter no.

    For system multi-node packages, you must enter yes.

  • run_script_timeout and halt_script_timeout. Enter the number of seconds Serviceguard should wait for package startup and shutdown, respectively, to complete; or leave the default, no_timeout; see “run_script_timeout”.

  • successor_halt_timeout. Used if other packages depend on this package; see “About Package Dependencies”.

  • script_log_file. See “script_log_file”.

  • log_level. See “log_level”.

  • failover_policy. Enter configured_node or min_package_node. See “failover_policy” for more information.

    (This parameter can be set for failover packages only.)

  • failback_policy. Enter automatic or manual. See “failback_policy” for more information.

    (This parameter can be set for failover packages only.)

  • If this package will depend on another package or packages, enter values for dependency_name, dependency_condition, dependency_location, and optionally priority.

    See “About Package Dependencies” for more information.

    NOTE: The package(s) this package depends on must already be part of the cluster configuration by the time you validate this package (via cmcheckconf (1m); see “Verifying and Applying the Package Configuration”); otherwise validation will fail.

  • local_lan_failover_allowed. Enter yes to permit switching of the package IP address to a standby LAN card on the local node, or no to keep the package address from switching locally.

    For multi-node packages, you must enter no.

  • Use the monitored_subnet parameter to specify a subnet that is to be monitored for this package. If there are multiple subnets, repeat the parameter as many times as needed, on a new line each time.

    In a cross-subnet configuration, configure the additional monitored_subnet_access parameter for each monitored_subnet as necessary; see “About Cross-Subnet Failover” for more information.

  • If this is a Serviceguard Extension for Oracle RAC (SGeRAC) installation, you can use the cluster_interconnect_subnet parameter (see “cluster_interconnect_subnet”).

  • If your package will use relocatable IP addresses, enter the ip_subnet and ip_address. addresses. ip_subnet must be specified in the cluster configuration file as a STATIONARY_IP.

    In a cross-subnet configuration, configure the additional ip_subnet_node parameter for each ip_subnet as necessary; see “About Cross-Subnet Failover” for more information.

  • For each service the package will run, enter values for the following parameters (see “service_name”):

    • service_name (for example, a daemon or long-running process)

    • service_cmd (for example, the command that starts the process)

    • service_fail_fast_enabled and service_halt_timeout if you need to change them from their defaults.

    • service_restart if you want the package to restart the service if it exits. (A value of unlimited can be useful if you want the service to execute in a loop, rather than exit and halt the package.)

  • To configure the package to monitor a registered EMS resource, enter values for the following parameters (see “resource_name”):

    • resource_name

    • resource_polling_interval

    • resource_up_value

    • resource_start

    See “Parameters for Configuring EMS Resources” for more information and an example.

  • If the package needs to mount LVM volumes to filesystems, use the vg parameters to specify the names of the volume groups to be activated, select the appropriate vgchange_cmd, and use the fs_ options in the FILESYSTEMS portion of the configuration file to specify the options for mounting and unmounting the filesystems. Do not use the vxvm_dg or cvm_dg parameters for LVM volume groups. Enter each volume group on a separate line, for example:

    vg vg01

    vg vg02

  • If you are using CVM, use the cvm_dg parameters to specify the names of the disk groups to be activated, and select the appropriate cvm_activation_cmd. You can use the fs_ commands in the FILESYSTEMS portion of the configuration file to specify options for mounting and unmounting file systems to these disk groups, but note that you must specify the disk groups whether the package mounts file systems to them or not.

    Do not use the vxvm_dg or vg parameters for CVM disk groups. See also “Configuring Veritas System Multi-node Packages” and “Configuring Veritas Multi-node Packages”.

    Do not include CFS-based disk groups in the package configuration file; they are activated by the CFS multi-node packages before standard packages are started. See “Configuring Veritas Multi-node Packages”.

  • If you are using VxVM disk groups without CVM, enter the names of VxVM disk groups that will be imported using vxvm_dg parameters. See “How Control Scripts Manage VxVM Disk Groups”.

  • If you are using mirrored VxVM disks, use “vxvol_cmd” to specify the mirror recovery option to be used by vxvol.

  • Specify the filesystem mount retry and unmount count options (see “fs_mount_retry_count”).

  • You can specify a deactivation_retry_count for LVM, CVM, and VxVM volume groups. See “deactivation_retry_count”.

  • You can specify whether or not to kill processes activating raw devices on shutdown; see “kill_processes_accessing_raw_devices ”.

  • If your package uses a large number of volume groups or disk groups, or mounts a large number of file systems, consider increasing the values of the following parameters:

    You can also use the fsck_opt and fs_umount_opt parameters to specify the -s option of the fsck and mount/umount commands (see “fs_umount_opt”).

  • You can use the pev_ parameter to specify a variable to be passed to external scripts. Make sure the variable name begins with the upper-case or lower-case letters pev and an underscore ( _). You can specify more than one variable. See “About External Scripts”, and the comments in the configuration file, for more details.

  • If you want the package to run an external “pre-script” during startup and shutdown, use the external_pre_script parameter (see “external_pre_script”) to specify the full pathname of the script, for example /etc/cmcluster/pkg1/pre_script1.

  • If the package will run an external script, use the external_script parameter (see “external_script”) to specify the full pathname of the script, for example /etc/cmcluster/pkg1/script1.

    See “About External Scripts”, and the comments in the configuration file, for more information.

  • To coordinate the startup and shutdown of database software with cluster node startup and shutdown, you can use the database template files provided with the separately purchasable Enterprise Cluster Master Toolkit product.

    These files are in /opt/cmcluster/toolkit/DB/. Separate toolkits are available for Oracle, Informix, and Sybase.

    In addition to the standard package script, you use the special script that is provided for the database. To set up these scripts, follow the instructions in the README file provided with each toolkit.

  • Configure the Access Control Policy for up to eight specific users or any_user.

    The only user role you can configure in the package configuration file is package_admin for the package in question. Cluster-wide roles are defined in the cluster configuration file. See “Setting up Access-Control Policies” for more information.



Generating the Package Configuration File
  		 


Verifying and Applying the Package Configuration  
Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© Hewlett-Packard Development Company, L.P.