for specific types of disk arrays. Other advantages of the "ASM-over-SLVM" configuration are as follows:

•ASM-over-SLVM ensures that the HP-UX devices used for disk group members will have the same names (the names of logical volumes in SLVM volume groups) on all nodes, easing ASM configuration.

•ASM-over-SLVM protects ASM data against inadvertent overwrites from nodes inside/outside the cluster. If the ASM disk group members are raw disks, there is no protection currently preventing these disks from being incorporated into LVM or VxVM volume/disk groups.

The disadvantages of the ASM-over-SLVM configuration are as follows:

•Additional configuration and management tasks are imposed by the extra layer of volume management (administration of volume groups, logical volumes, physical volumes).

•There is a small performance impact from the extra layer of volume management.

•SLVM has some restrictions in the area of online reconfiguration, the impact of which will be examined later in this chapter.

Configuring SLVM Volume Groups for ASM Disk Groups

Ideally, ASM disk group members should be raw disks or array logical units, but due to the lack of built-in multipathing we require them to be SLVM raw logical volumes in SGeRAC configurations. But we would still like these logical volumes presented to ASM to resemble raw disks, as far as possible.

Hence, each SLVM logical volume (LV) used as a member of an ASM disk group is required to be laid out to occupy the usable space, in contiguous fashion, of exactly one single physical volume (PV). This implies the following about LV:

•Contiguous

•Not striped or mirrored

•Does not span multiple PVs

•Does not share a PV with other LVs

The idea is that ASM provides the mirroring, striping, slicing, and dicing functionality as needed and SLVM supplies the multipathing functionality not provided by ASM. Figure 13 indicates this 1-1 mapping between SLVM PVs and LVs used as ASM disk group members.

Further, the default retry behavior of SLVM could result in an I/O operation on an SLVM 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 SLVM 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 SLVM to try all available paths, if needed.4

The PVs used in an ASM disk group can be organized into SLVM volume groups as desired by the customer. In the example shown in Figure 13, for each ASM disk group, the PVs corresponding to its members are organized into a separate SLVM volume group.

70 Support of Oracle RAC ASM with SGeRAC