532 Implementing the IBM Storwize V7000 with IBM Spectrum Virtualize V8.2.1
11.6.18  Practical use of Global Mirror
The practical use of Global Mirror is similar to the Metro Mirror as described in 11.6.9, 
“Practical use of Metro Mirror” on page 523. The main difference between the two remote 
copy modes is that Global Mirror and Global Mirror with Change Volumes are mostly used on 
much larger distances than Metro Mirror. Weak link quality or insufficient bandwidth between 
the primary and secondary sites can also be a reason to prefer asynchronous Global Mirror 
over synchronous Metro Mirror. Otherwise, the use cases for MM/GM are the same.
11.6.19  IBM Spectrum Virtualize HyperSwap topology
The IBM HyperSwap topology is based on IBM Spectrum Virtualize Remote Copy 
mechanisms. It is also referred to as an “active-active relationship” in this document.
You can create an HyperSwap topology system configuration where each I/O group in the 
system is physically on a different site. These configurations can be used to maintain access 
to data on the system when power failures or site-wide outages occur.
In a HyperSwap configuration, each site is defined as an independent failure domain. If one 
site experiences a failure, then the other site can continue to operate without disruption. You 
must also configure a third site to host a quorum device or IP quorum application that 
provides an automatic tie-break in case of a link failure between the two main sites. The main 
site can be in the same room or across rooms in the data center, buildings on the same 
campus, or buildings in different cities. Different kinds of sites protect against different types of 
failures.
For more information about HyperSwap implementation and best practices, see IBM Storwize 
V7000, Spectrum Virtualize, HyperSwap, and VMware Implementation, SG24-8317.
11.6.20  Consistency Protection for Global Mirror and Metro Mirror
Metro Mirror, Global Mirror, Global Mirror with change volumes, and HyperSwap Copy 
Services functions create remote copy or remote replication relationships between volumes 
or Consistency Groups. If the secondary volume in a Copy Services relationship becomes 
unavailable to the primary volume, the system maintains the relationship. However, the data 
might become out of sync when the secondary volume becomes available.
Since V7.8, it is possible to create a FlashCopy mapping (Change Volume) for a remote copy 
target volume to maintain a consistent image of the secondary volume. The system 
recognizes it as a Consistency Protection and a link failure or an offline secondary volume 
event is handled differently now.
When Consistency Protection is configured, the relationship between the primary and 
secondary volumes does not stop if the link goes down or the secondary volume is offline. 
The relationship does not go in to the consistent stopped status. Instead, the system uses the 
secondary change volume to automatically copy the previous consistent state of the 
secondary volume. The relationship automatically moves to the consistent copying status as 
the system resynchronizes and protects the consistency of the data. 
Important: Failure to perform these steps correctly can cause MM/GM to report the 
relationship as consistent when it is not, possibly causing a data loss or data integrity 
exposure for hosts accessing data on the auxiliary volume.