## Background copy considerations 

The remote copy partnership bandwidth parameter explicitly  defines the rate at which the background copy is attempted, but also implicitly  affects foreground I/O. Background copy bandwidth can affect foreground I/O latency in one of the following ways: 

GLYPH<SM590000> Increasing latency of foreground I/O 

If the remote copy partnership bandwidth parameter is set too high for the actual intersystem network capability, the background copy resynchronization writes use too much of the intersystem network. It starves the link of the ability to service synchronous or asynchronous mirrored foreground writes. Delays in processing the mirrored foreground writes increase the latency of the foreground I/O as perceived by the applications. 

GLYPH<SM590000> Read I/O overload of primary storage 

If the remote copy partnership background copy rate is set too high, the added read I/Os that are associated with background copy writes can overload the storage at the primary site and delay foreground (read and write) I/Os. 

GLYPH<SM590000> Write I/O overload of auxiliary storage 

If the remote copy partnership background copy rate is set too high for the storage at the secondary site, the background copy writes overload the auxiliary storage. Again, they delay the synchronous and asynchronous mirrored foreground write I/Os. 

Important:  An increase in the peak foreground workload can have a detrimental effect on foreground I/O. It does so by pushing more mirrored foreground write traffic along the intersystem network, which might not have the bandwidth to sustain it. It can also overload the primary storage. 

To set the background copy bandwidth optimally, consider all aspects of your environments, starting with the following biggest contributing resources: 

GLYPH<SM590000> Primary storage 

GLYPH<SM590000> Intersystem network bandwidth 

GLYPH<SM590000> Auxiliary storage 

Provision the most restrictive of these three resources between the background copy bandwidth and the peak foreground I/O workload. Perform this provisioning by calculation or by determining experimentally how much background copy can be allowed before the foreground I/O latency becomes unacceptable. 

Then, reduce the background copy to accommodate peaks in workload. In cases where the available network bandwidth is not able to sustain an acceptable background copy rate, consider alternatives to the initial copy as described in “Initial synchronization options and Offline Synchronization” on page 232. 

Changes in the environment, or loading of it, can affect the foreground I/O. IBM Spectrum Virtualize and Storwize technology provides a means to monitor, and a parameter to control, how foreground I/O is affected by running remote copy processes. IBM Spectrum Virtualize software monitors the delivery of the mirrored foreground writes. If latency or performance of these writes extends beyond a (predefined or client-defined) limit for a period, the remote copy relationship is suspended (see 5.3.5, “1920 error” on page 240). 

Finally, note that with Global Mirror Change Volume, the cycling process that transfers the data from the local to the remote system is a background copy task. For this reason, the background copy rate, as well as the relationship_bandwidth_limit , setting affects the available bandwidth not only during the initial synchronization, but also during the normal cycling process. 

