Planning the Volume Manager Setup

Volume managers are tools that let you create units of disk storage known as storage groups. Storage groups contain logical volumes for use on single systems and in high availability clusters. In ServiceGuard clusters, package control scripts activate storage groups.

With MC/ServiceGuard 11.13 two volume managers can now be used: the standard Logical Volume Manager (LVM) and the Veritas Volume Manager (VxVM). SGeSAP can also be used with both volume managers.

The following steps describe the standard setup for the LVM volume manager. For more details refer to the "Integrating VxVM with MC/ServiceGuard" manual that can be found on http://docs.hp.com/hpux/11i under the Veritas Volume Manager section.

Record all the minor numbers already in use on the cluster hosts. See Table 2-1 “Hosts and Device Minor Numbers”.

The device minor numbers of the shared volume groups must be the same on all cluster hosts. They must differ from all other volume group device minor numbers used on the cluster hosts.

To find these minor device numbers on each cluster hosts, type:

ll /dev/vg*/group|cut -c 44-45

Create new special files for the volume groups as needed.

Refer to Table 2-1 “Hosts and Device Minor Numbers”, check that all the minor numbers for one host are unique for that host. If any host uses the same number twice create new special files with a unique number.

Specify the needed volume groups in another table.

For the standard setup there should be at least three cluster volume groups:

Two shared volume groups would also work but this is not recommended because of lack of flexibility. If you put all logical volumes in one volume group, you will be restricted to the one package concept. You should end up with a table similar to Table 2-2 “Volume Groups Needed for MC/ServiceGuard Packages”.

	NOTE: If there is more than one SAP R/3 system in the cluster then /usr/sap/trans may be outside of this configuration.

Using the one package concept, all the volume groups will belong to one package. For reference we call this package dbci<SID> or the DBCI package.

Using the two package concept, vgsap<SID> belongs to the Central Instance package (CI). The CI package contains all logical volumes that are exclusively needed by the Central Instance. vgsapmnt<SID> and vgdb<SID> are configured to belong to the database package (DB).

If you use only two cluster volume groups, put /export/sapmnt/<SID> and /export/usr/sap/trans in the volume group which belongs to the node that runs the HA NFS server (this should be the database package). If you plan to use more than one SAP R/3 system using the same transport directory /usr/sap/trans, do not configure it with an SAP R/3 system package. If you stop the SAP R/3 system package, other systems will be affected, too. They cannot be restarted and transports are impossible. CCMS functionality should be used with care. For additional /export/usr/sap/trans security use the HP provided NFS toolkit. When using the Application server package concept you should setup a separate volume group for this package. This volume group vg<SID><INSTNR> consists of one logical volume called lvsap<SAP>. It holds the work, log and data directories for this specific instance.

If you have more than one system, place /oracle/stage/stage_nnn and /usr/sap/put on separate volume groups created on shared drives. These directories should not be added to any package. This ensures that they are independent from any SAP R/3 system and you can mount them on any host by hand if needed.

If SAP R/3 is not installed yet, specify values in the device minor column that are different from all values you identified in Step Title not available. Use Table 2-1 “Hosts and Device Minor Numbers” as a template for recording the device minor values.