High Availability for Oracle ASM using HP Serviceguard Solutions, September 2010

HP Serviceguard support for ASM on HP-UX 11i v2

Overview

This document describes how to configure Oracle ASM database with HP Serviceguard for high

availability using the Oracle database Toolkit available in the Serviceguard Enterprise Cluster Master

Toolkit bundle (ECMT). For information about the supported versions of Serviceguard ECMT with

Oracle database and Serviceguard, look at the Serviceguard ECMT support matrix available at

http://www.hp.com/go/hp HP Enterprise Cluster Master Toolkit. ux-serviceguard-docs

Note that for database failover, each database should store its data in its own disk group. Refer to

Oracle documentation for limitation imposed by ASM on the number of disk groups. The disk group

members must be logical volumes managed by HP Logical Volume Manager (LVM).

Why ASM over LVM?

As mentioned above, we require ASM disk group members in HP Serviceguard configurations to be

raw logical volumes managed by LVM. We leverage existing HP-UX 11i capabilities to provide

multipathing for LVM logical volumes, using either the PV Links feature, or separate products such as

HP StorageWorks Secure Path that provide multipathing for specific types of disk arrays. Another

reason for using LVM is that, it is the responsibility of HP Serviceguard to provide the necessary I/O

fencing when it provides failover for a single instance Oracle database instance. Serviceguard

provides I/O fencing for a failover package via a feature in the volume manager: exclusive activation

of volume groups. Other advantages of the "ASM-over-LVM" configuration are as follows:

• ASM-over-LVM makes sure that the HP-UX devices used for disk group members will have the

same names (the names of logical volumes in LVM volume groups) on all nodes, easing

ASM configuration.

• ASM-over-LVM 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-LVM 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.

Configuring LVM volume groups for ASM disk groups

We require ASM disk group members in HP Serviceguard configurations to be raw logical volumes

managed by LVM. But these logical volumes presented to ASM should resemble raw disks, as far as

possible. Hence, each LVM 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 that the LV:

• Should be contiguous

• Should not be striped or mirrored

• Should not span multiple PVs

• 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.