76 Implementing the IBM Storwize V7000 with IBM Spectrum Virtualize V8.2.1
Copy services topology
One or more clusters can participate in a copy services relationship. One typical and simple 
use case is disaster recovery, where one site is active and another performs only a disaster 
recovery function. In such a case, the solution topology is simple, with one cluster per site and 
uniform replication direction for all volumes. However, multiple other topologies are possible 
that allow you to design a solution that optimally fits your set of requirements. For more 
information about examples of valid relationships between systems, search for “Metro Mirror 
and Global Mirror partnerships” at this IBM Knowledge Center web page.
Global Mirror versus Metro Mirror
Decide which type of copy service you are going use. This decision should be requirements 
driven. Metro Mirror allows you to prevent any data loss during a system failure, but has more 
stringent requirements, especially regarding intercluster link bandwidth and latency, and 
remote site storage performance. Also, it incurs performance penalty because writes are not 
confirmed to host until data reception confirmation is received from the remote site. 
Because of finite data transfer speeds, this remote write penalty grows with the distance 
between the sites. A point-to-point dark fiber-based link typically incurs a round-trip latency of 
1 ms per 100 km (62.13 miles). Other technologies provide longer round-trip latencies. 
Inter-site link latency defines the maximum distance for any performance level.
Global Mirror allows you to relax constraints on system requirements at the cost of using 
asynchronous replication, which allows the remote site to lag behind the local site. Choice of 
the replication type has major effects on all other aspects of the copy services planning.
The use of Global Mirror and Metro Mirror between the same two clustered systems is 
supported.
If you plan to use copy services to realize some application function (for example, disaster 
recovery orchestration software), review the requirements of the application you plan to use. 
Verify that the complete solution is going to fulfill supportability criteria of both IBM and the 
application vendor.
Intercluster link
The local and remote clusters can be connected by FC, FCoE, or IP network. The IP network 
can be used as a carrier for FCoIP solution or as a native data carrier. 
Each of the technologies has its own requirements concerning supported distance, link 
speeds, bandwidth, and vulnerability to frame or packet loss. For the most current information 
regarding requirements and limitations of each of supported technologies, see this website.
The two major parameters of a link are its bandwidth and latency. Latency might limit 
maximum bandwidth available over IP links, depending on the details of the technology that is 
used.
When planning the Intercluster link, consider the peak performance that is required. This 
consideration is especially important for Metro Mirror configurations.
When Metro Mirror or Global Mirror is used, a certain amount of bandwidth is required for the 
IBM Storwize V7000 intercluster heartbeat traffic. The amount of traffic depends on how 
many nodes are in each of the two clustered systems.