HPE Storage Users Group

Hi

I am setting up a pair of F400s (3.1.1) with RCFC between two sites and a predominantly ESX 4.1 host environment. Whilst it'll eventually become an SRM enviroment, there will be a period where is it going to require testing of manual failover to two possible scenarios:

1) failover and manual export of VLUNs to ESX hosts on second site with manual vcenter addition

2) failover and manual export of VLUNs back to the same ESX host with manual vcenter addition

Scenario 1 is straight forward as the newly exported VLUN(s) from the backup array should be seen as new VLUNs in Vcenter and should work as expected with a little manual intervention.

Scenario 2 is the one I have been testing for a while and which I am having difficulty recording a successful process for.

I tried this method two way. One with pre-exporting the back up array's RCG volumes and one by leaving them un-exported until after failover.

With the pre-export tmethod, ESX sees two copies of the LUN with the same LUN number but with a UID that differs because of the different WWN of the arrays. One is Read/write, the other is Read Only (as expected). However, when I 'Failover' and 'Recover' the Remote Copy group (reverse replication direction and change host access to the group's member volumes), I lose access to the test VM and I can't do anything (in the 'Add Storage...' section of ESX) with the newly active volume apart from Initialise it ('Continue with same signature' and 'Continue with new signature' are greyed out). The only way to get the VM back on line is to 'Restore' the RCG back to normal.

With the non-exported backup volume method, I did a 'Failover' and 'Recover', then un-exported the original source volume followed by export of the back up volume (to kind of simulate an array failure). This allowed me the 'Continue with same signature' and 'Continue with new signature' at the 'Add Storage..' wizard. However, when trying the 'Continue with same signature' option, Vcenter didn't like it and didn't continue. When trying the 'Continue with new signature' route, the process took about 15 minutes to complete and brought the volume online but prefixed the volume with the 'snap'. Either way, I was unable to simply continue with the original named volume/datastore.

Is there another way to allow this to work or has anyone got a document with the stepped process on how to do this properly? I appreciate thisisn't probably the usual way of doing the failover, but I need to have the option avaialble.

I look forward to hearing from you.

Regards
Mossman200

Hi,

Would anyone be able to confirm the recommended procedure for 3PAR? re: in a standard stretched cluster (Non-CLX) would it be OK to pre-export the remote Copy VLUNs, instead of having to action this step after a failover?

Previously with the HP EVA's this was do-able & supported, as the pre-presented destination (Continuous Access) LUNs were 'masked' by default as 'No Access' to the destination host. When a failover was initiated between the arrays, the destination LUNs automatically became accessible to the host(s).