Managing HP Serviceguard A.12.00.00 for Linux, June 2014

Table 14 Modules affected during online deletion (continued)
To unmount the mount point mnt1:
#umount /mnt1
To delete the hostags from the
vg_dd0 on node test1.ind.hp.com:
#vgchange --deltag
test1.ind.hp.com vg_dd1
To remove the persistent reservation
from the disk /dev/sde:
#pr_cleanup -lun /dev/sde
If storage deleted from the
package has failed or not
attempted, ensure the following:
• The mount point is
unmounted.
• Delete the hosttagss from the
disk.
• Volume group is de-activated
with hosttags.
• Persistent reservation is
removed from the disk.
For more information, see
sg_persist(1m),
vgchange(1m),
pr_cleanup(1m),
multipath(1m), and
mount(1m) manpage.
sg/filesystem
(filesystem.sh)
sg/volume_group
(volume_group.sh)
sg/pr_cntl
(pr_cntl.sh)
Removing
storage from
the package
To halt the external pre script:
#extern_pre_script.sh stop
If an external pre script which is
deleted from the package
configuration failed or not
attempted to stop, run the script
with stop option.
script_name stop
sg/external_pre_script
(external.sh)
Removing
external pre
script from the
package
—You cannot rectify the failures in
XDC module manually and must
restart the package.
ext/xdc
(xdc.sh)
Removing MD
from the
package (for
XDC
packages)
7.8 Responding to Cluster Events
Serviceguard does not require much ongoing system administration intervention. As long as there
are no failures, your cluster will be monitored and protected. In the event of a failure, those packages
that you have designated to be transferred to another node will be transferred automatically. Your
ongoing responsibility as the system administrator will be to monitor the cluster and determine if
a transfer of package has occurred. If a transfer has occurred, you have to determine the cause
and take corrective actions.
The typical corrective actions to take in the event of a transfer of package include:
• Determining when a transfer has occurred.
• Determining the cause of a transfer.
• Repairing any hardware failures.
• Correcting any software problems.
• Restarting nodes.
• Transferring packages back to their original nodes.
• Enabling package switching.
7.9 Single-Node Operation
In a multi-node cluster, you could have a situation in which all but one node has failed, or you
have shut down all but one node, leaving your cluster in single-node operation. This remaining
7.8 Responding to Cluster Events 255