As part of its copy services function, the storage controller might take a LUN offline or suspend reads or writes. As IBM FS9100 does not recognize why this happens; therefore, it might log errors when these events occur. For this reason, if the IBM FS9100 must detect the LUN, ensure to keep that LUN in the unmanaged  state until full access is granted. 

Native back-end controller copy services can also be used for LUNs not managed by the IBM FS9100. Note that accidental incorrect configurations of the back-end controller copy services involving IBM FS9100 attached LUN can produce unpredictable results. 

For example, if you accidentally use a LUN with IBM FS9100 data on it as a point-in-time target LUN, you can corrupt that data. Moreover, if that LUN was a managed disk in a managed disk group with striped or sequential volumes on it, the managed disk group might be brought offline. This situation, in turn, makes all of the volumes that belong to that group go offline, leading to a widespread host access disruption. 

## Remote Copy and code upgrade considerations 

When you upgrade system software where the system participates in one or more intersystem relationships, upgrade only one cluster at a time. That is, do not upgrade the systems concurrently. 

Attention:  Upgrading both systems concurrently is not monitored by the software upgrade process. 

Allow the software upgrade to complete one system before it is started on the other system. Upgrading both systems concurrently can lead to a loss of synchronization. In stress situations, it can further lead to a loss of availability. 

Usually, pre-existing remote copy relationships are unaffected by a software upgrade that is performed correctly. However, always check in the target code release notes for special considerations on the copy services. 

Even if it is not a best practice, a remote copy partnership can be established, with some restriction, among systems with different IBM Spectrum Virtualize versions. For more information about a compatibility table for intersystem Metro Mirror and Global Mirror relationships between IBM Spectrum Virtualize code levels, see Spectrum Virtualize Family of Products Inter-System Metro Mirror and Global Mirror Compatibility Cross Reference: 

Spectrum Virtualize Family of Products Inter-System Metro Mirror and Global Mirror Compatibility Cross Reference 

## Volume placement considerations 

You can optimize the distribution of volumes within I/O groups at the local and remote systems to maximize performance. 

Although defined at a system level, the partnership bandwidth, and consequently the background copy rate, is evenly divided among the cluster’s I/O groups. The available bandwidth for the background copy can be used by either canister, or shared by both canisters within the I/O Group. 

This bandwidth allocation is independent from the number of volumes for which a canister is responsible. Each node, in turn, divides its bandwidth evenly between the (multiple) remote copy relationships with which it associates volumes that are performing a background copy. 

