VNX5600 mirroring cause latency

Setting up MirrorView/Asynchronous

• On the destination array, the Snapshot is there to allow the secondary LUN to be rolled back to its consistent state prior to the synchronization start, in the event that the synchronization does not fully complete.
• As the MV/A performance is heavily dependent on the RLP, it is important to follow RLP best practice.  See article 469257.
• The source LUNs also retain some metadata on the RLP and so there will always be one RLP LUN reserved for each MV/A mirror on the primary array.  If the RLP needs to be completely destroyed and reconfigured for any reason (to move it to other drives for example), then each mirror would have to be removed.  This would not lead to any loss of data on the source or destination, but when the mirror is created again, a full synchronization would be needed.
• The amount of RLP available allocated should be monitored, keeping in mind that there will need to be one RLP LUN per mirror, plus additional RLP which may be needed when the size of the Snapshot exceeds the first RLP LUN:
  • Allocating too much RLP will waste capacity and unnecessarily consume SP resources.
  • Allocating too little RLP can cause synchronizations to fail when the assigned RLP LUNs are filled up and no more RLP LUNs are available.

Setting up individual mirrors

• While it is possible to use a thin destination LUN for a thick source LUN, this would fully allocate the thin LUN, which defeats the objective for using a thin LUN.  Therefore, thick LUNs should be mirrored to thick LUNs and thin LUNs mirrored to thin LUNs.
• The destination LUN will trespass to match the source LUNs SP owner and so the same default (all LUNs) and allocation owner (pool LUNs only), should be used for each mirrored pair.  See article 461661 for more information about LUN ownership.
• The update frequency of mirrors can be set when they are created and this can be changed again later.  However, the update frequency can also be set by adding MV/A mirrors into a consistency group and it is the settings in the consistency group that takes precedence over the individual mirrors settings.  To avoid confusion, the synchronization frequency settings on the consistency group and individual mirrors should match.
• Mirrors can be set to update using either the time difference since the start of the previous synchronization or the time difference since the end of the last synchronization.
• It is recommended that there should be no less than five minutes between each synchronization.
• A rule of thumb (or general guideline), for setting up asynchronous mirrors is either:
  • 15 minutes start to start (assuming an average of 5 minutes for all the synchronizations and an upper limit of 10 minutes).
  • 10 minutes end to start for LUNs for best performance.
  • 5 minutes end to start for best availability (5 minutes from the end of a synchronization to the start of the next synchronization).
• If even 5 minutes between updates (the end of one sync to the start of the next), is too infrequent then synchronous replication should be considered, but that does have more of an impact on the source LUN performance. This is because all synchronous writes have to be sent and acknowledged by the secondary array, before write acknowledgement is sent to the host; which is not the case for asynchronous replication.

For further reference, see the following VNX Series whitepapers on https://dell.to/3pX5snI:

• MirrorView Knowledgebook - A Detailed Review
• VNX Unified Best Practices for Performance