HP XP Cluster Extension Software Administrator Guide

XP Cluster Extension cancels live migration operations within the local data center when the device/
copy group is not in PAIR status. Use the LocalDCLMForNonPAIRDG property, which can be
configured in a UCF for each application, to change the setting to allow live migration to occur
within the local data center even if the device/copy group is not in PAIR status.
Hyper-V Live Migration is supported with XP Cluster Extension for Windows Server 2008 R2 and
Windows Server 2012 using only the synchronous fence levels DATA and NEVER. The asynchronous
and journal fence levels are not supported.
Using Hyper-V Live Migration with Cluster Shared Volumes is not supported with XP Cluster
Extension.
TIP: For more information about using Hyper-V Live Migration with XP Cluster Extension, see the
white paper Live Migration across data centers and disaster tolerant virtualization architecture with
HP Cluster Extension and Microsoft Hyper-VTM on the white papers website: www.hp.com/storage/
whitepapers.
Timing considerations for MSFC
XP Cluster Extension gives priority to disk array operations over cluster software operations. If XP
Cluster Extension invokes a disk pair resynchronization operation or gathers information about the
remote 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 RAID Manager instances to communicate with the remote disk array.
Depending on the setting of the RAID Manager instance timeout parameter and the number
of remote instances, the online operation could time out. This can occur if the local RAID
Manager instance cannot reach the remote RAID Manager instance.
• XP Cluster Extension tries to resynchronize disk pairs and waits until the RAID Manager device/
copy group is in PAIR state if the ApplicationStartup resource property is set to RESYNCWAIT.
RAID Manager and the XP 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 disk array cache and adjust the resource PendingTimeout
value. When measuring the copy time, measure only the slowest link used for Continuous
Access Software. This ensures that the disk array cache can be transferred from the remote
disk array, even in the event of a single surviving replication link between the 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.
36 Configuring XP Cluster Extension