Veritas Volume Manager 4.1 Administrator's Guide (HP-UX 11i v3, February 2007)

Chapter 13, Administering Cluster Functionality
Multi-Host Failover Configurations
369
Specifically, when a host imports a disk group, the import normally fails if any disks
within the disk group appear to be locked by another host. This allows automatic
re-importing of disk groups after a reboot (autoimporting) and prevents imports by another
host, even while the first host is shut down. If the importing host is shut down without
deporting the disk group, the disk group can only be imported by another host by
clearing the host ID lock first (discussed later).
The import lock contains a host ID (in VERITAS Volume Manager, this is the host name)
reference to identify the importing host and enforce the lock. Problems can therefore arise
if two hosts have the same host ID.
Note Since VERITAS Volume Manager uses the host name as the host ID (by default), it is
advisable to change the host name of one machine if another machine shares its host
name. To change the host name, use the vxdctl hostid new_hostname command.
Failover
The import locking scheme works well in an environment where disk groups are not
normally shifted from one system to another. However, consider a setup where two hosts,
Node A and Node B, can access the drives of a disk group. The disk group is first
imported by Node A, but the administrator wants to access the disk group from Node B if
Node A crashes. This kind of scenario (failover) can be used to provide manual high
availability to data, where the failure of one node does not prevent access to data. Failover
can be combined with a “high availability” monitor to provide automatic high availability
to data: when Node B detects that Node A has crashed or shut down, Node B imports
(fails over) the disk group to provide access to the volumes.
VERITAS Volume Manager can support failover, but it relies on the administrator or on an
external high-availability monitor to ensure that the first system is shut down or
unavailable before the disk group is imported to another system. For details on how to
clear locks and force an import, see “Moving Disk Groups Between Systems” on page 144
and the vxdg(1M) manual page.
Corruption of Disk Group Configuration
If vxdg import is used with -C (clears locks) and/or -f (forces import) to import a disk
group that is still in use from another host, disk group configuration corruption is likely to
occur. Volume content corruption is also likely if a file system or database is started on the
imported volumes before the other host crashes or shuts down.
If this kind of corruption occurs, you must probably rebuild your configuration from
scratch and reload all volumes in the disk group from a backup. To backup and rebuild
the configuration, if nothing has changed, use vxprint -mspvd and store the output