Intrasystem versus intersystem  Metro Mirror functional overview Although remote copy services are available for intrasystem, it has no functional value for  production use. Intrasystem Metro Mirror provides the same capability with less overhead.  However, leaving this function in place simplifies testing and allows for experimentation and  testing. For example, you can validate server failover on a single test system. Intrasystem remote copy:  Intrasystem Global Mirror is not supported on IBM Spectrum  Virtualize based systems that run V6 or later. Metro Mirror provides synchronous replication. It is designed to ensure that updates are  committed to both the primary and secondary volumes before sending an acknowledgment  (Ack) of the completion to the server.  If the primary volume fails completely for any reason, Metro Mirror is designed to ensure that  the secondary volume holds the same data as the primary did immediately before the failure. Metro Mirror provides the simplest way to maintain an identical copy on both the primary and  secondary volumes. However, as with any synchronous copy over long distance, there can be  a performance impact to host applications due to network latency. Metro Mirror supports relationships between volumes that are up to 300 km apart. Latency is  an important consideration for any Metro Mirror network. With typical fiber optic round-trip  latencies of 1 ms per 100 km, you can expect a minimum of 3 ms extra latency, due to the  network alone, on each I/O if you are running across the 300 km separation. Figure 6-15 shows the order of Metro Mirror write operations. A write into mirrored cache on an IBM Spectrum Virtualize based system is all that is required  for the write to be considered as committed. De-staging to disk is a natural part of I/O  management, but it is not generally in the critical path for a Metro Mirror write  acknowledgment. Figure 6-15 Metro Mirror write sequence Chapter 6. Copy services  173