(Environment: Two VNX5300)
We recently started using MirrorView to setup a DR solution in our environment.
We were told to use the MirrorView Wizard, because it would be easier to setup all the mirrors since we had quite a few. The wizard would create the LUNs needed on the secondary array with the correct size etc.
We used the wizard and it was indeed easy to setup.
After a week or so we noticed that many of our LUNs in the secondary array had trespassed. When we started to look into why they had trespassed we noticed that the MV LUNs on the secondary array had been created on the opposite SP than the primary MV LUNs in the primary array. The secondary arrayed then trespassed the LUNs to match the SP in the primary array. The CMI redirectors in the secondary array were then heavily used and we noticed performance issues. In the SP logs we also noted that the mirrors occasionally had to be fractured and later resumed due to this performance issue. This also caused problem to our ESX servers.
We then started to migrate the secondary MV LUNs that had wrong Allocation Owner. But the problem does not stop here. Since the secondary MV LUNs were trespassed, the internal private LUNs on the secondary array started to use slices from both SPs. This is something you do not see until you notice a trespassed private LUN. There is no easy way to resolve this trespass. The array should take care of it, but since the private LUNs started to use a lot of slices from both SPs it do not really belong to any of the SPs. The private LUN stay trespassed even after we fixed all the MV LUNs.
EMC engineering started to investigate the private LUN with RBA traces, MLUDISPLAYSLICE etc. There seems to be no really simple solution to solve this issue. We have got suggestions like disable FastCache, destroying FastCache, rebuild the FastVP pool. This is nothing that you would easily do without a large impact on your environment.
MirrorView has been available from EMC for a long time, my question is if anyone else had these issues? The MirrorView Wizard, trespassed private LUNs?
Is this MV/A? Remember that MV/A is really a combination of incremental sancopy, snapview and some code to glue the whole thing together. IF this is MV/A I suspect the problem you are seeing is somehow related to the differences in both the underlying layered products handle LUN ownership.
Well, this is how we first noticed the problem. When the timeout (due to the MV problem) of the array were too much for our ESX servers, the ESX servers change the status on the current path to "Dead path" and tried to connect to the LUN via other paths/fabrics. That caused other LUNs to also trespass.