HP StorageWorks XP Remote Web Console Software - Manual (Page 169)

A XP Continuous Access Load Balancing and Sidefile
Management and Control
Asynchronous Remote Copy solutions, as applicable to Disaster Recovery (DR), protect operational
environments by assuring data integrity and rapid recovery at an alternate location should the
operational environment at the home site be disrupted. As with any implemented application or
solution, impact to the operational environment must be minimal.
In an environment with a stable workload and a network (paths, channel extension, secondary
capability) properly sized and implemented to support the workload requirement, solution success
is virtually assured. Workload requirements, however, are not always fixed or predictable.
Workloads change, coincidental application demands occur, and workload additions to satisfy
growth requirements are usually inevitable.
Workload demand profiles consist of a series of peaks and valleys that are unpredictable in both
magnitude and duration. It becomes very important that measures and methodologies be put in
place to minimize the impact of these anomalies.
Caching usage is the prime method of buffering peaks when demand exceeds network capacity
and the prime method of unloading when valleys occur. Cache availability is mandatory for these
sequences to occur and the quantity of available cache dictates the size and duration of the peaks
that can be accommodated. Cache is a shared resource in that it is the prime host access facility.
It must also serve additional functions such as DFW, CFW, Concurrent Copy Sidefile, and in this
case, Remote Copy Sidefile buffering.
Rules of Thumb (ROT) based on past experiences are used to provide a best effort recommendation
as to the amount of cache required to sustain the environment with minimal impact to host
applications. With undersized cache to accommodate these demands, probable negative effects
are decreased cache hit ratios, inability to start CC sessions, busy states to Write Pending
operations, and so on.
HP’s offerings for Asynchronous Remote Copy include XP Continuous Access Asynchronous (XP
Continuous Access Asynchronous Open and TrueCopy Asynchronous for Mainframe) and
Compatible XRC. Each is unique in both operational structure and capability. Different ROTs are
used for cache sizing recommendations. For XP Continuous Access Asynchronous, one and a half
times the current, none DR, amount of cache is recommended. For Compatible XRC, two times the
current, none DR, amount of cache is recommended. An additional methodology called device
blocking is used to sustain the environment and is implemented for both XP Continuous Access
Asynchronous and Compatible XRC.
This methodology is interchangeably referred to as device blocking whether it is at the channel or
device level, flow control, or device throttling. All are methods of controlling application demand,
thus allowing the DR solution to sustain, and each is tuned to minimize impact on host operations.
With XP Continuous Access Asynchronous, a graduated level of retry delay to application host
operations is induced dependent upon the amount of residual DR data not yet serviced by the
secondary. This is a device-level operation, and devices deemed critical may be excluded from
this algorithm via host control.
With Compatible XRC, device level blocking under threshold control by the System Data Mover is
the preferred method of flow control. Devices deemed critical may be excluded.
It is essential that all components of a DR solution be sized correctly, implemented accordingly,
and expectations be realized.
This design concept is considered a best practice for a Disaster Recovery/Business Continuation
(DR/BC) environment. This concept depends upon the capability of a network implemented to
support the demand of host write update activity to devices associated with the DR/BC environment
without induced delay impact to host performance.
Operational requirements must dictate the direction and design of the delivered solution. The
following options are recommended to lessen the host impact of the best practice solution.
169