During the writing of the SRM 5.0 book I did have access to internal build of the EMC SRA. As you might know I have both an EMC NS-20 and NS-120. The NS-20 is the slightly older type of area which is based on 32-bit and would have been managed with the older “NaviSphere” software, where as the NS-120 is the new model managed by “UniSphere”. In my configuration I setup the
new NS-120 as the “Protected Site” array, with the older NS-20 as the “Recovery Site” array – as the target for MirrorView replication.
Due to publishing constraints the book shipped with information which was true at the time, but after the EMC formally released their SRA there was some changes that I want to outline here. Unfortunately, the book was already at the printing presses so I wasn’t able to include this update at that time.
Firstly, in all previous releases of the SRA for MirrorView – you were required to manually create a snapshot and present that to the ESX hosts in NaviSphere/UniSphere with a particular string in the name. This snapshot would be mounted and used by the ESX host whenever you carried out a test of your SRM Recovery Plan. So something like “SRM_TEST_FAILOVER_SNAPSHOT_LUN100″ would have a been viable name (albeit not a brilliant one!). This snapshot would have taken its storage from the “Reserved LUN Pool” or RLP configured. The main update is that is no longer the case that you have to give these snapshots a special name to work with the MirrorView SRA. Nor do you need to manually make the snapshot and present it to the ESX hosts – all that’s need is that you have SnapView installed and the RPL configured.
Secondly, there’s another interesting experience that occurs when you run your Recovery Plan for real, as opposed to just a test. When you do this for most arrays – the SRA stops the replication from the Protected Site to the Recovery Site – and promotes the read-only LUN or volume in the Recovery Site to be primary and read-writable. Replication is only inverted – and changes sent back to the Protected Site – when you run the “Reprotect” process in SRM and carry out a failback.
Now. Depending on how you configure MirrorView and context of how the plan is run – this is not the case. Let say you were doing a Planned Migration. In this case both the Protected Site and Recovery Site are up, and running your recovery plan – as either data center move exercise or preemptively using SRM to avoid an impending disaster that’s on its way – but yet to hit landfall. In this scenario MirrorView can be configured to automatically invert the replication, and establish replication automatically – before you even carry out the reprotect process – such that replication path from NYC >>> NJ, automatically becomes NYC <<< NJ without any intercession from SRM or the SRA.
The interesting thing about this scenario – is that SRM reports this information as if this process hasn’t happened at all. In the SRM interface you would see the “broken link” icon even though replication is happening and going in the opposite direction. It’s not until you run the “reprotect” process from SRM that this icon is cleared, and updated.
The situation is somewhat more different if the recovery plan is run in the event of a true disaster. In this case is the New York site was dead, the automatic re-establishment of MirrorView replication and inversion of the direction cannot happen – because the array at the Recovery Site cannot communicate to the Protected Site. In this case the replication would be marked in UniSphere as “fractured”. If the settings in MirrorView were setup for “manual” recovery – it would be the reprotect process in SRM that would fix up the relationships correctly.
It’s perhaps important to state here that only if you were looking closely at both SRM and UniSphere would see this anomaly, and it doesn’t alter great the workflow managed by SRM. If you want to do a failback with SRM, you have to carry out a reprotect whatever the scenario.