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. 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 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.  Volume placement considerations Remote Copy and code upgrade considerations 192  IBM FlashSystem 9200 and 9100 Best Practices and Performance Guidelines