Implementing disaster recovery for HP Integrity Virtual Machines with Metrocluster and Continentalclusters on HP-UX 11i
Table Of Contents
- Executive summary
- Introduction
- Audience
- Configuring Integrity Virtual Machines as packages in HP Metrocluster
- Verifying failover of Metrocluster packages across data centers
- Troubleshooting Metrocluster VM problems
- Application startup and monitoring
- Configuring Integrity Virtual Machines as packages in HP Continentalclusters
- Overview
- Software requirements for HP VMs in Continentalclusters
- Configuring HP VM packages in Continentalclusters
- Creating VM switches in all nodes of the primary cluster
- Configuring replicated storage for VM in Continentalclusters
- Installing the operating system on the virtual machine
- Testing the virtual guest OS in all nodes of the primary cluster
- Creating VM switches in all nodes of the recovery cluster
- Preparing the replicated storage for use in the recovery cluster
- Creating the virtual machine in all nodes of the recovery cluster
- Testing the virtual guest OS in all nodes of the recovery cluster
- Resynchronizing the replicated storage
- Packaging the HP VM in the primary cluster and the recovery cluster
- Creating a Continentalclusters package
- Creating a Continentalclusters configuration with the VM packages
- Running the Continentalclusters monitoring daemon in the recovery cluster
- Recovering to the recovery cluster
- Related documentation
- Appendix I
- Appendix II
- For more information
- Call to action
31
#
#VXVM_DG[0]=""
VXVM_DG[0]=vmdatadg
…
# Note: No environmental variables will be passed to the command, this
# includes the PATH variable. Absolute path names are required for the
# service command definition. Default shell is /usr/bin/sh.
#
#SERVICE_NAME[0]=""
#SERVICE_CMD[0]=""
#SERVICE_RESTART[0]=""
SERVICE_NAME[0]="vmmetro" SERVICE_CMD[0]="/etc/cmcluster/vmmetro/hpvmkit.sh
monitor vmmetro" SERVICE_RESTART[0]=""
…
# START OF CUSTOMER DEFINED FUNCTIONS
# This function is a place holder for customer define functions.
# You should define all actions you want to happen here, before the service is
# started. You can create as many functions as you need.
function customer_defined_run_cmds
{
# ADD customer defined run commands.
/etc/cmcluster/vmmetro/hpvmkit.sh start vmmetro test_return 51
}
# This function is a place holder for customer define functions.
# You should define all actions you want to happen here, before the service is
# halted.
function customer_defined_halt_cmds
{
# ADD customer defined halt commands.
/etc/cmcluster/vmmetro/hpvmkit.sh stop vmmetro test_return 52
}
# END OF CUSTOMER DEFINED FUNCTIONS
3.
Sample environment file for the example used in this white paper:
For Metrocluster Continuous Access XP/P9000 (vmmetro_xpca.env)
AUTO_SVOLPSUE=0
AUTO_SVOLPFUS=0
AUTOPSUEPSUS=0
AUTO_FENCEDATA_SPLIT=1
AUTO_SVOLPSUS=0
AUTO_NONCURDATA=0
MULTIPLE_PVOL_OR_SVOL_FRAMES_FOR_PKG=0
WAITTIME=300
PKGDIR=/etc/cmcluster/vmmetro
FENCE=never (or data or async as the case may be)
DEVICE_GROUP=dgVM
CLUSTER_TYPE=”metro” HORCTIMEOUT=360