Implementing disaster recovery for HP Integrity Virtual Machines with Metrocluster and Continentalclusters on HP-UX 11i

5
After creating the VM switches, enter the following commands on each node to start the virtual switch:
# hpvmnet –b –S vs1
# hpvmnet –b –S vs2
The virtual switches vs1 and vs2 are active now, and hpvmnet displays the new states along with the
MAC address of the physical device:
#hpvmnet
For more details, see the Designing High Availability Solutions with HP Serviceguard and HP Integrity
Virtual Machines white paper at
www.hp.com/go/hpux-serviceguard-docs.
Configuring VM storage
Before creating the virtual machine, you need to set up the VM guest storage. In a Metrocluster
environment, the following types of storage units can be used as virtual storage by virtual machines:
• Files inside logical volumes (LVM, VxVM)
• Raw logical volumes (LVM, VxVM)
• Whole disk
Note: Whole disk as backing storage is supported when a modular style Metrocluster package is created for the VM
guest.
For this example, VxVM logical volumes are used for guest storage. However, LVM managed volumes
can also be used for guest storage, if required.
The VM guest OS image can be on either local storage (not replicated to the remote site) or shared
storage (replicated to the remote site). In a local configuration, the guest OS storage is not managed
by Metrocluster. In a shared configuration, the guest OS storage can be configured to be managed
by Metrocluster. The advantage of having a shared configuration is that all the VM guest instances of
a VM package share the same OS image, so there is no need to keep them in sync or incur the
expense of multiple copies of the OS. But the disadvantage is that it exposes the shared storage to a
single point of failure (SPOF) within a data center.
For this example, the guest OS image and application binaries are locally configured, and only the
application data is on replicated storage.
On all the nodes on the primary side (Node1 and Node2), create three VxVM disk groups—
vmpriosdg, vmpriexedg, and vmdatadg—for guest storage. Of these three disk groups, the first two
are local and are not mirrored to the remote site. The last disk group, vmdatadg, is created on
Continuous Access XP devices and is mirrored to the remote site.
On the secondary side (Node3 and Node4), the VM guest resides on VxVM disk groups vmsecosdg,
vmsecexedg, and vmdatadg. Of these three disk groups, the first two are local and are not mirrored
to the remote site. Thus, these disk groups need to be created newly on all secondary site nodes. The
last disk group vmdatadg already exists on the primary site; it just needs to be imported here when
needed.
Because only the disk group vmdatadg is created on Continuous Access XP devices, this disk group
alone must be configured to be managed by Metrocluster. The steps for setting up the XP device
Name Number State Mode PPA MAC address IP address
localnet 1 Up Shared N/A N/A N/A
vs1 2 Up Shared lan0 0x00306ea70bb3 16.89.140.178
vs2 3 Up Shared Lan1 0x00306e4a28a4 192.244.64.73