HP StorageWorks XP Cluster Extension Software Administrator Guide (T1656-96035, April 2010)

In some cases, this behavior could lead to failed XP Cluster Extension resources:
• XP Cluster Extension uses XP RAID Manager instances to communicate with the remote XP disk
array. Depending on the settings of the XP RAID Manager instance timeout parameter and the
number of remote instances, the online operation could time out. This can happen if the local XP
RAID Manager instance cannot reach the remote XP RAID Manager instance.
• XP Cluster Extension tries to resynchronize disk pairs and waits until the XP RAID Manager device
group is in PAIR state if the ApplicationStartup attribute is set to RESYNCWAIT. Depending on the
XP RAID Manager version and the XP firmware version this could be a full resynchronization and
may take longer than the online timeout interval. Even if the XP RAID Manager version and the XP
firmware version allow a delta resynchronization, the delta between the primary and the secondary
could be big enough for the copy process to exceed the online timeout value.
• The ResyncWaitTimeout attribute can automatically lead to failed XP Cluster Extension resources
when set higher than the online timeout interval.
• If running in fence level ASYNC, the default value of the AsyncTakeoverTimeout can cause the
resource to fail because its value is set beyond the resource online timeout interval. This is done
because the takeover process for fence level ASYNC can take much longer when slow communic-
ations links are in place.
To prevent takeover commands from being terminated by the takeover timeout before finishing,
measure the time to copy the installed XP disk array cache and adjust the resource online timeout
interval according to the measured copy time. When measuring the copy time, measure only the
slowest link used for XP Continuous Access Software. This ensures that the XP disk array cache
can be transferred from the remote XP disk array, even in the event of a single surviving replication
link between the XP disk arrays.
Because the failover environment is dispersed into two (or more) data centers, the failover time cannot
be expected to be the same as it would be in a single data center with a single shared disk device.
Therefore, adjust the online timeout values, the monitor interval of the XP Cluster Extension resource,
and the service group using the XP Cluster Extension resource based on failover tests performed to
verify the proper configuration setup.
Enabling/disabling service groups
Based on the XP disk array status information, XP Cluster Extension can change the cluster software
behavior to automatically failover (or failback) the service group faster to the remote data center.
For example, when the remote disk state is S-VOL_SSUS and the SSWS option has been set to indicate
a prior takeover to the secondary disk set, if you have set the ApplicationStartup object to
FASTFAILBACK, XP Cluster Extension would disable the service group for all systems in the respective
data center(s) and VCS would transfer the service group back to the remote site rather than waiting
for a pair resynchronization to be finished before the service group could start on the local site.
This could happen only if you have not recovered the suspended disk pair after a prior takeover,
where the PAIR state could not be maintained because of, for example, an XP Continuous Access
Software link failure.
This feature reduces application downtime because the service group (and the application) are not
brought online on each system in the service group's system list. It is moved to the first available system
listed in the service group's system list, which is connected to the remote XP disk array, which is done
by enabling the VCS configuration file (main.cf) to be writable. The service group is disabled for
all systems contained in either the DC_A_Hosts object or DC_B_Hosts object. Then, the VCS
configuration file is saved (dumped).
This feature can be disabled. If the FastFailbackEnabled object is set to NO, the standard VCS process
is used and the XP Cluster Extension resource will fail on the local system (and so would the service
group). VCS then tries to bring the service group online on the next system in the service group's
XP Cluster Extension Software Administrator Guide 89