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

Timing considerations for MSCS
XP Cluster Extension gives priority to XP disk array operations over cluster software operations. If XP
Cluster Extension invokes a disk pair resynchronization operation or gathers information about the
remote XP disk array, XP Cluster Extension waits until the requested status information is reported.
This ensures the priority of data integrity over cluster software failover processes. This behavior can
lead to failed XP Cluster Extension resources as described below:
• XP Cluster Extension uses XP RAID Manager instances to communicate with the remote XP disk
array. Depending on the setting of the XP RAID Manager instance timeout parameter and the
number of remote instances, the online operation could time out. This can occur 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 resource property is set to RESYNCWAIT. XP RAID
Manager and the XP firmware fully support delta resynchronization; however, the delta between
the primary and secondary disks could be large enough for the copy process to exceed the resource
PendingTimeout value.
• The ResyncWaitTimeout object can cause XP Cluster Extension resources to fail if its value is
higher than the resource PendingTimeout value.
• If running in fence level ASYNC, the default value of AsyncTakeoverTimeout can cause the resource
to fail because its value exceeds the resource PendingTimeout value. The takeover process for
fence level ASYNC can take much longer when slow communications links are in place.
To prevent takeover commands from being terminated by the resource PendingTimeout, measure
the time required to copy the installed XP disk array cache and adjust the resource PendingTimeout
value. 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.
In general, because the failover environment is dispersed into two (or more) data centers, the failover
time cannot be expected to be the same as that in a single data center with a single shared disk
device. Therefore, the following values of the XP Cluster Extension resource and the service and
application using that resource must be adjusted, based on failover tests performed to verify the proper
configuration setup: FailoverPeriod, RestartPeriod, PendingTimeout, LookAlive, and IsAlive.
In addition, the service or application's FailoverPeriod value must be higher than the resource’s
RestartPeriod value, and both must be higher than the resource’s PendingTimeout value.
MSCS provides two parameters to adjust state change recognition/resolution:
• IsAlive
• LookAlive
XP Cluster Extension automatically calls the IsAlive function whenever the cluster service calls the
LookAlive function. Therefore, both functions must be set to the same value.
Bouncing service or application
XP Cluster Extension will alternate (start and fail) between local nodes if the ApplicationStartup property
has been set to FASTFAILBACK and no remote system is available until the service or application
restart limit has been reached. For more information, see ApplicationStartup on page 129.
The FastFailbackEnabled property is not used by the XP Cluster Extension integration with MSCS.
Configuring XP Cluster Extension for Windows72