HP Enterprise Cluster Master Toolkit User Guide (5900-2131, December 2011)

• should not span multiple PVs
• and should not share a PV with other LVs.
The idea is that ASM provides the mirroring, striping, slicing, and dicing functionality as needed
and LVM supplies the multipathing functionality not provided by ASM. Figure 2 indicates this
one-to-one mapping between LVM PVs and LVs used as ASM disk group members.
Further, the default retry behavior of LVM could result in an I/O operation on an LVM LV taking
an indefinitely long period of time. This behavior could impede ASM retry and rebalance
capabilities; hence a finite timeout must be configured for each LVM LV.
For example, the timeout could be configured to the value (total number of physical paths to the
PV * PV timeout), providing enough time for LVM to try all available paths, if needed.
The PVs used in an ASM disk group can be organized into LVM volume groups as desired by the
customer. In the example shown in Figure 2, for each ASM disk group, the PVs corresponding to
its members are organized into a separate LVM volume group.
The LVM volume groups are marked as exclusive volume groups and exported across the
Serviceguard cluster using standard Serviceguard procedures. As noted above, multiple physical
paths to each physical volume should be configured using the LVM PV Links feature or a separate
multipathing product such as HP StorageWorks Secure Path.
Figure 2 Oracle database storage hierarchy without and with ASM
Sample Command Sequence for Configuring LVM Volume Groups
Here is an example of a command sequence that can be used to prepare LVM Logical Volumes
for use by ASM to meet the requirements specified above. The scenario for the example is that we
are preparing a new volume group named vgora_asm with two PVs, each with two physical paths.
The physical paths for the first PV are /dev/dsk/c9t0d1 and /dev/dsk/c10t0d1 and those
for the second PV are /dev/dsk/c9t0d2 and /dev/dsk/c10t0d2.
30 Using the Oracle Toolkit in an HP Serviceguard Cluster