 |
» |
|
|
|
The HA Disk Monitor is designed for use with ServiceGuard to trigger package
failover if host adapters, buses, controllers, or disks fail. Here are
some examples: In a cluster where one copy of data
is shared between all nodes in the cluster, you may want to fail
a package if the host adapter has failed on the node running the
package. Because buses, controllers, and disks are shared, package
failover will not run the package successfully. ServiceGuard can then
compare the resource UP values on all nodes and fail the package over
to the node that has the correct resources available. In a cluster where each node has its own copy of
data, you may want to fail a package over to another node for any
number of reasons: Host adapter, bus, controller, or
disk failure Unprotected data (the number of copies is reduced
to one) Performance has degraded because one of the PV links
has failed
For example, in a cluster of Web servers where each node has
a copy of the data and users are distributed for load balancing,
you can fail a package over to another node with the correct resources
available.
Disk availability is based on pv_summary. See the manual Using the Event Monitoring Service (HP Part Number B7612-90015) for information
on configuring package dependencies. In addition to configuring disks as ServiceGuard package dependencies, you
may also want to have alerts sent to a system management tool such as
HP OpenView 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
to fail over, but may expose a single point of failure that you
want to know about. Therefore, it is recommended that you also configure
requests from the SAM interface to EMS.
Setting
Failover Parameters | |
When using the HA Disk Monitor with ServiceGuard, the parameters listed
in Table 2-6 “Setting Failover Parameters” should be set so that
a package failover will occur when access to a disk resource fails. Table 2-6 Setting Failover Parameters | Parameter | Setting | Notes |
|---|
RUN_SCRIPT_
TIMEOUT | non-zero timeout value | Do not leave these parameters set
to the default, NO_TIMEOUT. If you do, the run or halt script hangs the package
and will not proceed with its action. | HALT_SCRIPT_
TIMEOUT | non-zero timeout value |
Working
with Physical Volume Groups | |
The pv_summary is calculated based on the compiled results of
SCSI inquiries to all physical volumes in a volume group. To help
you determine the best way to configure your disks for monitoring,
here are the assumptions made by the monitor when calculating pv_summary: PVGs (physical volume groups) are
set up to be bus-specific sides of a mirror or redundant links,
PVGs have an equal number of physical volumes. All logical volumes within a volume group are mirrored
in the same way: all 2-way or all 3-way mirroring. If you are configuring a monitoring request through ServiceGuard,
a package depends on all logical volumes in the volume group. The SCSI inquiry will retry on devices that are BUSY. BUSY devices are not considered UP when calculating pv_summary.
These rules apply when creating a PVG. If the rules are not
followed, pv_summary will not be available for monitoring: If PVGs are used, all physical volumes
in a volume group must be in a PVG. All PVGs in a volume group must have the same number
of physical volumes.
Table 2-7 “pv_summary Calculations” is a summary of
how pv_summary is calculated where n is the number of paths for the volume group in /etc/lvmtab (physical volumes, paths, or LUNs). p is the number of PVGs (physical volume groups) in
the volume group x is the number of paths currently available from a
SCSI inquiry
Table 2-7 pv_summary Calculations Case | Conclusion | State |
|---|
x = n | All physical volumes and all data are
available. | UP | n>x>=n - (p-1) | All data is available. | PVG_UP | n/p <= x <= n-(p-1) | If there are PVGs, and one PVG has all
paths, then all data is available. | PVG_UP | If there are PVGs, and none of the PVGs
has all paths, then the HA Disk Monitor cannot determine if all data
is available. | SUSPECT | x < n/p | Some data is missing. |
DOWN
| x=0 | No data or physical volumes are available. |
To give pv_summary the most accurate picture of data availability,
you need to use PVGs to define your physical volumes as separate
access points to data. Mirroring should be PVG-strict. Arrays should
have PV links, with redundant links in a separate PVG. Note that
if you do not configure PV links into separate PVGs, p in Table 2-7 “pv_summary Calculations” will
always be equal to 1. Therefore any SCSI inquiry that does not return
a value of UP for every path will result in a calculation of
DOWN for pv_summary.
Rules
for RAID Arrays | |
RAID configurations
must be configured with PV links. PV links are redundant links attached
to separate controllers on the array. If PV links are configured,
and one fails, LVM automatically switches to the alternate controller
when one fails. To use the HA Disk Monitor with ServiceGuard, PV links must be configured
in separate PVGs (physical volume groups). This
new requirement allows pv_summary to accurately calculate data availability based
on physical volume availability, thus including both ACTIVE and INACTIVE volume groups. If PV links are not configured in separate PVGs,
the HA Disk Monitor sees all links to the array as one physical volume.
If one link fails, pv_summary will register DOWN, and your package will fail over, even if the
other link is still up and data is available. The following sections describe how to make sure your PV links
are in physical volume groups. Adding
PVGs to Existing Volume GroupsIf you have already created volume groups, you can create
PVGs and put PV links into them. Creating
Volume Groups on Disk Arrays Using PV LinksIf you will be monitoring volume groups that use mass storage
on disk arrays, you should use redundant I/O channels from each
node, and connect them to separate controllers on the array. Then
you can define alternate links to the LUNs or logical disks you
have defined on the array. Alternate links (known as PV links) to
the same disk should be assigned to different physical
volume groups. In SAM, choose the type of disk array
you want to configure, and follow the menus to define alternate
links. Be sure to specify a different physical volume group for each
link to the same disk. The following example shows how to configure alternate links
using LVM commands. In the example, the following disk configuration
is assumed: |
8/0.15.0 /dev/dsk/c0t15d0 /* I/O Channel 0 (8/0) SCSI address 15 LUN 0 */
8/0.15.1 /dev/dsk/c0t15d1 /* I/O Channel 0 (8/0) SCSI address 15 LUN 1 */
8/0.15.2 /dev/dsk/c0t15d2 /* I/O Channel 0 (8/0) SCSI address 15 LUN 2 */
8/0.15.3 /dev/dsk/c0t15d3 /* I/O Channel 0 (8/0) SCSI address 15 LUN 3 */
8/0.15.4 /dev/dsk/c0t15d4 /* I/O Channel 0 (8/0) SCSI address 15 LUN 4 */
8/0.15.5 /dev/dsk/c0t15d5 /* I/O Channel 0 (8/0) SCSI address 15 LUN 5 */
10/0.3.0 /dev/dsk/c1t3d0 /* I/O Channel 1 (10/0) SCSI address 3 LUN 0 */
10/0.3.1 /dev/dsk/c1t3d1 /* I/O Channel 1 (10/0) SCSI address 3 LUN 1 */
10/0.3.2 /dev/dsk/c1t3d2 /* I/O Channel 1 (10/0) SCSI address 3 LUN 2 */
10/0.3.3 /dev/dsk/c1t3d3 /* I/O Channel 1 (10/0) SCSI address 3 LUN 3 */
10/0.3.4 /dev/dsk/c1t3d4 /* I/O Channel 1 (10/0) SCSI address 3 LUN 4 */
10/0.3.5 /dev/dsk/c1t3d5 /* I/O Channel 1 (10/0) SCSI address 3 LUN 5 */ |
|
Assume that the disk array has been configured, and that the
following device files appear for the same LUN (logical disk) when
you run the ioscan command: /dev/dsk/c0t15d0
/dev/dsk/c1t3d0 |
Use the following steps to configure a volume group for this
logical disk: First, set up the group directory for vgdatabase: Next, create a control file named group in the directory /dev/vgdatabase, as follows: # mknod /dev/vgdatabase/group c 64 0xhh0000 |
The major number is always 64, and the hexadecimal minor number has
the form: 0xhh0000 where hh must be unique to the volume group you are creating.
Use an appropriate hexadecimal number that is available on your system,
after the volume groups are already configured. On a single system,
this might be the next hexadecimal number. On a cluster, this number
must be assigned cluster-wide, so it should be one of the hexadecimal
numbers used in the cluster. Use the following command to display
a list of existing volume groups: Use the pvcreate command on one of the device files associated with the
LUN to define the LUN to the LVM (logical volume manager) as a physical
volume. # pvcreate /dev/dsk/c0t15d0 |
It is only necessary to do this with one of the device file
names for the LUN. Use the following commands to create the volume
group itself with the first link assigned to a physical volume group
called bus1and the second link assigned to a physical volume group
called bus2: # vgcreate -g bus1 /dev/vgdatabase /dev/dsk/c0t15d0
# vgextend -g bus2 /dev/vgdatabase /dev/dsk/c0t3d0 |
LVM will now recognize the I/O channel represented by /dev/dsk/
c0t15d0 as the primary link to the disk; if the primary link
fails, LVM will automatically switch to the alternate I/O channel
represented by /dev/dsk/c1t3d0. Use the following command to create logical volumes (the example
is for /dev/vgdatabase): # lvcreate -L 120 -m 1 -s g /dev/vgdatabase |
If you are using disk arrays in RAID 1 or RAID 5 mode, omit
the -m 1 option. This command creates a 120 MB mirrored volume named lvol1. The name is supplied by default, since no name is
specified in the command. The -s g option means that mirroring is PVG-strict, that is,
the mirror copies of data will be in different physical volume groups. Rules
for Mirrored Individual Disks | |
The following rules apply to configuring mirrored disks for
use with ServiceGuard and the HA Disk Monitor: Mirroring must be PVG-strict. Mirrored volumes must reside on a different bus from the original volume
to avoid a single point of failure and to obtain the best pv_summary value for that mirror. This is done automatically
by LVM if you have created the PVGs while setting up mirroring.
See the lvextend manpage and Managing MC/ServiceGuard (HP Part Number B3936-90026) for more
information. Logical volumes that are 2-way mirrored should be
in separate volume groups from those that are 3-way mirrored. Putting differently mirrored volumes in the same volume group makes
it difficult to accurately interpret the pv_summary data. Take the example of a volume group containing
both 2- and 3-way mirroring. If 2 host adapters fail on that volume
group, it could mean no data available for the 2-way mirrored logical
volume, but one copy still available for the 3-way mirrored volume.
The pv_summary would be wrong for one of those mirrored disk
configurations. Volume groups representing the same hardware for
failover must be created with exactly the same name on all nodes. For example, a bus connecting 3 nodes to a disk array must
be defined as part of vg01 on all 3 nodes. It is also recommended that you
use the same names for PVGs containing the same
actual disks.
Mirrors that have been split off are treated the same by the HA Disk Monitor as
they are by LVM. When you split off a mirror, you will see a change
in the following resources: /vg/vgName/lv/copies/lvName will be reduced by one when the mirror is split off.
If you have created a monitoring request for that resource that
alerts you when the number of copies is changed or is reduced, you
will see an event. /vg/vgName/lv/status will have a new /lvName resource instance that represents the split-off mirror. /vg/vgName/lv_summary will change depending on the state of
the new logical volume created by the split mirror.
If you restore the split mirror normally using supported LVM
commands, the HA Disk Monitor will detect the merged mirror and report
it. |
Printable version
