 |
» |
|
|
|
The disk monitor is designed especially for use with MC/ServiceGuard
to provide package failover if host adapters, busses, controllers,
or disks fail. Here are some examples: In
a cluster where one copy of data is shared between all nodes in
a cluster, you may want to fail over a package if the host adapter
has failed on the node running the package. Because busses, controllers,
and disks are shared, package fail over to another node because
of bus, controller, or disk failure would not successfully run the
package. To make sure you have proper failover in a shared data
environment, you must create identical package dependencies on all
nodes in the cluster. MC/ServiceGuard can then compare the resource
"UP" values on all nodes and fail 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 over a package 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 over a package to another node with the correct resources
available. Again, the package resource dependencies should be configured
the same on all nodes.
Disk availability is based on pv_summary. See "Configuring
MC/ServiceGuard Package Dependencies" in Chapter 1 for
information on configuring package dependencies. In addition
to configuring disks as MC/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 MC/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 you also configure requests from the SAM
interface to EMS. 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 when calculating pv_summary: PVGs (physical volume groups) are
set up to be bus-specific sides of a mirror or redundant links and
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. 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 PVGs, if they 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-6 “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.
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 and 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-6 “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. Table 2-6 pv_summary
Calculations Case | Conclusion | State |
|---|
x = n | All physical volumes and all data are
available. | UP | 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 disk monitor cannot determine if all data
is available. | SUSPECT | x <
n/p | Missing some data. |
DOWN
| x=0 | No data or physical volumes are available. |
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, LVM automatically
switches to the alternate controller when one fails. To use the EMS disk monitor with MC/ServiceGuard, PV links
must be configured in a 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 disk
monitor sees all links to the array as one physical volume, so 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, connecting
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 wish 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 both
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 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 that are
already configured. On a single system, this might be the next hexadecimal
number, on a cluster, these 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 LVM 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. Rules for Mirrored
Individual Disks | |
The following rules apply to configuring mirrored disks for
use with MC/ServiceGuard and EMS monitoring: 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 created the PVGs while setting up mirroring. See the
lvextend man page and Managing MC/ServiceGuard
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. We also recommend using
the same names for PVGs containing the same actual
disks.
Mirrors that have been split
off are treated the same by the disk monitor as they are by LVM.
When you split off a mirror you may 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 created
a monitoring request for that resource that alerts you when the
number of copies changes or is reduced, you may see an event. /vg/vgName/lv/status
will have a new /lvName resource instance
that represents the split off mirror. /vg/vgName/lv_summary
many 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 disk monitor will detect the merged mirror and reports |
Printable version
