The HA Database Monitor with ServiceGuard provides package failover if
database servers fail or if the usage or number of connections exceeds specified
levels. For example:
In a cluster where a database is accessed
by multiple database servers on the same host, you may want to fail
a package over if the database servers on that host are stopped
for some reason, such as shutting down the instance or if one or
more of the server processes aborts.
In a cluster where database access is limited by
a maximum number of connections, you may want to fail a package
over when this maximum number is reached, to a host where there
is no limit set.
In a cluster where the host cache is not being effectively
utilized, you may want to fail a package over to a host that is
less busy.
Database availability is based on database status and database
server status. See the manual Using the Event Monitoring Service (B7609-90021) for information on configuring
package dependencies.
In addition to configuring databases as ServiceGuard package dependencies,
you may also want to send notifications about events to a system
management tool such as HP Open View IT/Operations or Network Node
Manager. Although ServiceGuard and EMS work together to provide package
failover, they do not send events or log the source of the failure.
Also, failures may not cause a package failover, but may expose
a single point of failure that you wish to know about. Therefore, it
is recommended that you also configure resource monitoring requests from
the SAM interface through the Resource Management icon to EMS.
 |
 |  |
 |
 | NOTE: The following sections provide an example of the parameters
and settings for the vendor database software from Oracle Corporation. Currently
this is the only vendor database that can be configured as a ServiceGuard package
dependency. |
 |
 |  |
 |
Setting
Failover Parameters |
 |
When using the HA Database Monitor with ServiceGuard, the ServiceGuard parameters
listed in Table 3-3 “Setting Failover Parameters” should be set
so that a package failover will occur when access to the database
resource fails.
Table 3-3 Setting Failover Parameters
| Parameter | Recommended Setting | File Location | Notes |
|---|
RUN_ SCRIPT_ TIMEOUT | non-zero timeout value | ServiceGuard package configuration file | Do not leave these parameters
set to the default, NO_TIMEOUT. If you do and if the run or halt script hangs for
some reason, the package will not fail over successfully to another
node. |
HALT_ SCRIPT_ TIMEOUT | non-zero timeout value |
RESOURCE_ START | DEFERRED | ServiceGuard package configuration file | This means that the resource will not be checked
for accessibility by the ServiceGuard daemon until after the cmstartres command is issued by the control script. cmstartres verifies that ServiceGuard will initialize successfully
and the database resources are ready to be monitored before any
dependency checking begins. |
RESOURCE_ NAME | database resource | ServiceGuard package configuration file | The name of the database or database resource
to be monitored, for example, /rdbms/server/ status/database_server_name |
| RESOURCE_UP_VALUE | UP value | ServiceGuard package configuration file | The condition that defines the UP state, for example, RESOURCE_UP_VALUE=UP |
RESOURCE_ POLLING_ INTERVAL | number of seconds | ServiceGuard package configuration file | Specify how often ServiceGuard will check the resource,
for example once every 30 seconds |
DEFERRED_ RESOURCE_ NAME | database resource | ServiceGuard package control script | The name of the database resource that must
be started prior to monitoring, for example, /rdbms/server/status/ database_server_name |
Sample
File Settings |
 |
The following is an example of how you might set up an ServiceGuard cluster, mycluster, with two nodes, nestle and whitman, to monitor the availability of a database, db_1, that is defined on a volume group, VG01, that can be
accessed in exclusive mode by either nestle or whitman. Figure 3-2 “Two
Node Cluster with HA Database Monitor Failover” shows the
sample cluster setup.
This sample illustrates a single database failover situation.
You can also configure failover for multiple databases, for example:
Configure two
different packages where each has a dependency on the status of
two different databases
Configure one package with
multiple dependencies
In the above scenario, ServiceGuard handles the activation and mounting
of the Oracle database, as well as starting the database instance
for you.
Setting
Up the ServiceGuard Package |
 |
This section provides an example, based on Figure 3-2 “Two
Node Cluster with HA Database Monitor Failover”, of setting the parameters in the ServiceGuard package
configuration file. The sample lists the parameters for the HA Database Monitor,
not all the parameters needed to set up ServiceGuard. For a complete
listing and explanation of all the parameters, refer to your Managing MC/ServiceGuard (B3936-90024) book. Table 3-4 “Some ServiceGuard Package Configuration File
Parameters” lists the ServiceGuard package
configuration file parameters that are used to configure the sample
two-node called mycluster that is depicted in Figure 3-2 “Two
Node Cluster with HA Database Monitor Failover”.
Table 3-4 Some ServiceGuard Package Configuration File
Parameters
| Parameter | Sample Data |
|---|
| PACKAGE_NAME | SG_pkg1 |
| NODE_NAME | nestle |
| NODE_NAME | whitman |
RUN_SCRIPT_TIMEOUT | 60 |
| HALT_SCRIPT_TIMEOUT | 60 |
| RESOURCE_NAME | /rdbms/server/status/db_1 |
| RESOURCE_POLLING_INTERVAL | 30 |
| RESOURCE_START | DEFERRED |
| RESOURCE_UP_VALUE | =UP |
Table 3-5 “Some ServiceGuard Package Control Script Parameters” lists the ServiceGuard package
control script parameters for the shared volume group, VG01.
Table 3-5 Some ServiceGuard Package Control Script Parameters
| Parameter | Sample Data |
|---|
| LV[0] | /dev/VG01/lv_ora_2 |
| LV[1] | /dev/VG01/lv_ora_3 |
| LV[2] | /dev/VG01/lv_ora_4 |
| FS[0] | /U02 |
| FS[1] | /U03 |
| FS[2] | /U04 |
| FS_MOUNT_OPT[0] | -o rw |
FS_MOUNT_OPT[1] | -o rw |
| FS_MOUNT_OPT[2] | -o rw |
| FS_UMOUNT1 | =3 |
| DEFERRED_RESOURCE_NAME | /rdbms/server/status/db_1 |
FS_UMOUNT is optional. It specifies how many additional times
the package shutdown script can attempt to deactivate the filesystem where
Oracle is mounted. The default number of retry attempts is 1. The
mounting and activation of the volume group where the Oracle database
resides is controlled by ServiceGuard.
ServiceGuard Sample
Run/Halt Scripts |
 |
The following is a sample of the run and halt portion of the ServiceGuard package
control script.
In the section for customer-defined run commands, type:
function customer_defined_run_cmds { export ORACLE_HOME=<oracle_home_directory> export ORACLE_SID=<oracle_sid> PFILE=$ORACLE_HOME/dbs/init<sid>.ora su oracle -c $ORACLE_HOME/bin/svrmgrl <<EOF connect internal startup pfile=${PFILE} exit EOF test_run 51 } |
In the section for customer-defined halt commands, type:
function customer_defined_run_cmds { export ORACLE_HOME=<oracle_home_directory> export ORACLE_SID=<oracle_sid> PFILE=$ORACLE_HOME/dbs/init<sid>.ora su oracle -c $ORACLE_HOME/bin/svrmgrl <<EOF connect internal shutdown exit EOF test_run 52 } |
Points to consider:
Because Oracle can take some time
to shutdown, consider whether to change shutdown to shutdown immediate in the halt portion of the script.
Be sure to code values for RUN_SCRIPT_TIMEOUT and HALT_SCRIPT_
TIMEOUT. This prevents the script from hanging in the event
that Oracle cannot start or stop in a timely manner.
The RESOURCE_START value must be set to DEFERRED so that ServiceGuard will
bypass checking for the existence of the Oracle resources until
after Oracle has successfully started up.
By adding the Oracle commands into the run and halt portions
of the configuration control script, you allow ServiceGuard to start
up and shut down the Oracle instance for you.