The background copy bandwidth determines the rate
at which the background copy for Copy Services are attempted.
The background copy bandwidth can affect foreground
I/O latency in one of three ways:
- If the background copy bandwidth is set too high for the intersystem
link capacity, the following results can occur:
- The intersystem link is not able to process the background copy
I/Os fast enough, and the I/Os can back up (accumulate).
- For Metro Mirror and HyperSwap, there is a delay in the synchronous secondary write operations
of foreground I/Os.
- For Global Mirror, the work is backlogged, which delays the processing of write
operations and causes the relationship to stop. For Global Mirror in multiple-cycling mode, a backlog in the intersystem link
can congest the local fabric and cause delays to data transfers.
- The foreground I/O latency increases as detected by applications.
- If the background copy bandwidth is set too high for the storage
at the primary site, background copy read I/Os overload
the primary storage and delay foreground I/Os.
- If the background copy bandwidth is set too high for the storage
at the secondary site, background copy write operations
at the secondary overload the secondary storage. As result, the synchronous
secondary write operations of foreground I/Os are again delayed.
- For Global Mirror without cycling mode, the work is backlogged and again the
relationship is stopped
To set the background copy bandwidth optimally,
you must consider all three resources (primary storage, intersystem
link bandwidth, and secondary storage). Provision the most restrictive
of these three resources between the background copy bandwidth and
the peak foreground I/O workload. You must also consider concurrent
host I/O. If other write operations arrive at the primary system for
copy to the remote site, these write operations can be delayed by
a high level of background copy. As a result, the hosts at the primary
site receive poor write-operation response times.
The provisioning for optimal bandwidth for the background
copy can also be calculated by determining how much background copy
can be allowed before the performance of host I/O becomes unacceptable.
The background copy bandwidth can be decreased slightly to accommodate
peaks in workload and provide a safety margin for host I/O.
Example
Consider the following example. The bandwidth setting at the primary site for the secondary
clustered
system is set to
200 MBps (megabytes per second) and the relationships are not synchronized. The system
attempts to resynchronize
the relationships at a maximum rate of 200 MBps with a 25 MBps restriction for each individual
relationship.
The following items can restrict throughput:
- The read response time of back-end storage at the primary system
- The write response time of the back-end storage at the secondary site
- Intersystem link latency