520 Implementing the IBM Storwize V7000 with IBM Spectrum Virtualize V8.2.1
Intercluster links
All Storwize V7000 nodes maintain a database of other devices that are visible on the fabric. 
This database is updated as devices appear and disappear.
Devices that advertise themselves as Storwize V7000 nodes or IBM SAN Volume Controller 
are categorized according to the system to which they belong. Nodes that belong to the same 
system establish communication channels between themselves and begin to exchange 
messages to implement clustering and the functional protocols of IBM Spectrum Virtualize.
Nodes that are in separate systems do not exchange messages after initial discovery is 
complete, unless they are configured together to perform a remote copy relationship.
The intercluster link carries control traffic to coordinate activity between two systems. The link 
is formed between one node in each system. The traffic between the designated nodes is 
distributed among logins that exist between those nodes.
If the designated node fails (or all of its logins to the remote system fail), a new node is 
chosen to carry control traffic. This node change causes the I/O to pause, but it does not put 
the relationships in a ConsistentStopped state.
11.6.5  Metro Mirror overview
Metro Mirror establishes a synchronous relationship between two volumes of equal size. The 
volumes in a Metro Mirror relationship are referred to as the master (primary) volume and the 
auxiliary (secondary) volume. Traditional FC Metro Mirror is primarily used in a metropolitan 
area or geographical area, up to a maximum distance of 300 km (186.4 miles) to provide 
synchronous replication of data. 
With synchronous copies, host applications write to the master volume, but they do not 
receive confirmation that the write operation completed until the data is written to the auxiliary 
volume. This action ensures that both the volumes have identical data when the copy 
completes. After the initial copy completes, the Metro Mirror function always maintains a fully 
synchronized copy of the source data at the target site.
Metro Mirror has the following characteristics:
/SM590000Zero recovery point objective (RPO)
/SM590000Synchronous
/SM590000Production application performance that is affected by round-trip latency
Increased distance directly affects host I/O performance because the writes are synchronous. 
Use the requirements for application performance when you are selecting your Metro Mirror 
auxiliary location.
Consistency groups can be used to maintain data integrity for dependent writes, which is 
similar to FlashCopy Consistency Groups.
Alerts: You can configure the system to raise Simple Network Management Protocol 
(SNMP) traps to the enterprise monitoring system to alert on events that indicate an 
interruption in internode communication occurred. 
Note: Use chsystem with -partnerfcportmask to dedicate several FC ports only to 
system-to-system traffic to ensure that remote copy is not affected by other traffic, such as 
host-to-node traffic or node-to-node traffic within the same system.