Reconfigured HP Data Replication Group not showing up as an SRM Datastore Group

[Bob_Humber]

Hello there,

I have SRM configured in two Datacentres with an EVA4000 at the source site, and an EVA4400 at the destination site, replicated with Continuous Access EVA.

I had two Replicated EVA Virtual Disks (and ESX Datastores) on the Source EVA4000 called EXCHANGE01 and EXCHANGE02 which were configured in separate Data Replication groups (EXCHANGE01-GROUP and EXCHANGE02-GROUP) in HP Command View EVA. These were picked up correctly by SRM as replicated Datastores.

I then decided that it would be better to fail the two Datastores over as one Unit, and so re-configured Continuous Access by removing the EXCHANGE02 Virtual Disk from its Data Replication Group, and adding it as a member of the EXCHANGE01-GROUP. After this, the EXCHANGE01-GROUP is the unit of fail-over in Command View EVA, and contains both Virtual Disks EXCHANGE01 and EXCHANGE02. The problem is that when I use the 'Rescan Replicated Datastores' option in SRM, it still sees the two Datastores EXCHANGE01 and EXCHANGE02. As it stands I have to create two Protection Groups, one per Datastore, when in reality Continuous Access will fail the two over as one Unit. The SRM server has been restarted, the Arrays rescanned a number of times, and in fact the EVA4000 has been restarted.

Two things, I suppose. Am I correct in thinking that SRM should pick up the HP Data Replication Group (despite the fact that it refers to it as a\ Datastore Group)? If I am, is there any way I can fix it (preferably short of deleting all replication groups in Command View EVA, rescanning in SRM, and re-replicating the disks?

I attach two screenshots - one from SRM showing the list of Datastore Groups after a rescan, and one from Command View EVA, showing the Data Recovery Group

Ax

[jbloo2 · Accepted solution]

Hi Bob -

The SRM term Datastore Group is intentionally generic because SRM supports many different array vendors, and not all of them might use a term "Replication Group" like EVA does. If SRM can match a datastore which was created on a LUN that is returned by the adapter as being replicated, it considers the datastore as replicated. It is up to the storage vendor to code the adapter to return LUN information that is appropriate for their array -- if you look at the SRM logs you'll see that the EVA adapter returns each replicated LUN individually with no information about Replication Group relationships at all, so it would be impossible for SRM to have any knowledge of this relationship as well.

Though the LUNs in a Replication Group might failover as a single group, they can be snapshotted individually for use during the SRM test, so that may be one reason why HP choice to list each LUN separately.

In any case, you have several alternatives:one is to keep your existing environment and configure two protection groups; on the recovery side you can configure a single recovery plan to fail over both of those protection groups; also, you might configure 2 other recovery plans, one for each protection group, that would only be used for test, and which would test each LUN and the VMs on it individually -- this might reduce the load on the DR ESX servers during test rather than testing all simultaneously. Of course you could create a single LUN as well, and that of course would make the above discussion moot -- this might be better if your VMs have to be tested all together because of application dependencies.

You might consider following up with HP if you want more insight as to the relationship of EVA "Replication Groups" viz SRM, i.e. why they chose not to expose Replication Group information.

[Bob_Humber]

Thanks jbloo2 - that is probably the best considered answer I have ever read in a forum!

It points out two things that (to my shame) I had not taken into consideration. First, the fact that you can have multiple Protection Groups in a Recovery Plan, which gets around my problem completely with some proper planning and configuration. Second, the fact an Array Snapshot is applied at the disc level regardless of Data Recovery Groups, which means that an SRM test Recovery can take part on a constituent LUN in a Group.

Thanks again

Ax