If either of the backend storage systems corrupts the data, the host is at risk of reading that corrupted data in the same way as for any other volume. Therefore, before you perform maintenance on a storage system that might affect the data integrity of one copy, it is important to check that both volume copies are synchronized. Then, remove that volume copy before you begin the maintenance. For example, the scenario applies if you must zero the data on the disks that the storage system is providing. 

Use cases: SAN Volume Controller volume mirroring with FlashSystem Depending on the storage system that is chosen for each of the two volume mirror copies, certain details must be considered to meet the high performance and low latency expectations of the solution. 

This section describes usage scenarios for the SAN Volume Controller volume mirroring when virtualizing one or more FlashSystem storage systems. Also described is the potential benefits and preferred practices for each scenario. 

Use case 1: Volume mirroring between two FlashSystem storage systems This case is the basic scenario for SAN Volume Controller volume mirroring because both copies are on the same type of storage systems. In this scenario, performance is not expected to be affected in a failure if the two subsystems are close to the SAN Volume Controller nodes. 

This scenario indicates a non-stretched cluster setup. In this case, FC link latency is not likely to present an issue. The default configuration for preferred node, primary copy, and mirroring priority is simplified. 

Note:  Volume mirroring does not contribute to host-side latency on the front end. Volume mirroring destaging is handled by the back end and is transparent to hosts. The time that it takes to cache mirror write I/Os must be considered if the nodes of a stretched cluster are far apart. For more information, see IBM System Storage SAN Volume Controller and Storwize V7000 Best Practices and Performance Guidelines , SG24-7521. 

http://www.redbooks.ibm.com/abstracts/sg247521.html?Open 

Use case 2: Volume mirroring between a FlashSystem and a non-flash storage system 

In this scenario, which is often adopted for cost-reduction reasons, plan to avoid the penalty that is represented by the slowest subsystem to the overall I/O latency. Consider the following suggestions: 

GLYPH<SM590000> The primary copy of each mirrored volume must be set for the copy that is in the FlashSystem subsystem so that all the reads are directed to it by SAN Volume Controller. This configuration is commonly referred to as a preferred read  configuration. See sections 6.5, “FlashSystem 900 preferred read and configuration examples” on page 172 and 11.3, “Preferred read” on page 401. 

GLYPH<SM590000> If both subsystems are close to the SAN Volume Controller nodes, which is a non-Stretched Cluster  setup, the -mirrorwritepriority  flag for the mirrored volume must be set to latency . Therefore, destaging to the volume copy in the slowest subsystem does not introduce a negative effect in the overall write latency and to cache usage. 

