SRDF REMOTE MIGRATION (VMAX TO VMAX)

Stefano Del Corno

Thanks for the detailed steps! That will really help us understand the SRDF steps involved in migration.

can you be more specific like giving an example?

When you say create SRDF pair,device group, set& establish dg's pairs. What do they actually look like, do they contain source/target device.

Could you explain with an example?I'm not familiar with the srdf pairs,DG's terms.

Thanks.

Once upon a time I had plenty of storages to play with ... And I used to paste lots of examples straight from my CLI instead of simply explaining concepts without providing examples :-/

You can either find examples in other previous threads (unfortunatly I can't search examples right now) or trust that someone else (probably Dynamox but maybe also someone else) will provide examples... :-)

John,

Looking at Stefano's steps ..which ones do you need examples for ?

It would be helpful if you could give me examples for steps 4 to 8 and 10th step.

Thanks.

ok so once systems have been shutdown you can split srdf (which will make target devices read/write enabled)

symrdf  -f filename split -sid -rdfg xx

at this point if you know where servers will be connected and which HBA will connect to which fabric you can go ahead and pre-create zones, map and mask devices (while servers are in transit). At some point you will need delete SRDF relationship before somebody on source side accidentally re-establishesh RDF pairs and blows away your new production.

what i typically do first is set rdf attributes on device first, this gives me a little protection (you will see why later on).  So first i set attributes on the source devices, create a file that contains these lines:

set  device XXXX attribute=dyn_rdf1_only;

set  device XXXX attribute=dyn_rdf1_only;

run "symconfigure -sid 123 -f filename.txt commit". These can be done online even if devices are already in use by the host

2) perform the same thin only on target devices

set  device XXXX attribute=dyn_rdf2_only;

set  device XXXX attribute=dyn_rdf2_only;

and then symconfigure

This is where i would do things differently from Stevano, i use files to create relationships.

3) Create a "pair" file where first column in the file are your source devices and second column are your target devices. The order is very important (it's more important if you did not do step 1 and 2 as you could reverse rdf and blow away production data

0239 1568
0238 1569
0237 156A

4) Create RDF relationship, here you will need to specify RDF group number (rdfg) that either you created or EMC created for you. You can run "symcfg list -RA ALL to see rdfg groups)

symrdf createpair -file file_fromstep3.txt -sid -rdfg xx -type rdf1 -invalidate  r2 -rdf_mode acp_disk

5) Begin actual synchronization

symrdf -f file_fromstep3.txt establish -sid -rdfg xx

to monitor progress

symrdf -f file_fromstep3.txt query -sid -rdfg xx

6) when you see that synchronization is almost done, change mode to synchronous

symrdf -f file_fromstep3.txt -sid set mode sync -rdfg xx

I guess the next steps depends on what you are doing, is this just a DR test or system is being migrated to DR site ?

Dynamox,

Thanks for the examples. Looks like your method of approach is different from Stefanos.

Its not a DR, all Servers will be shipped to target site.

Hi john121. You have to map my steps to the ones Dynamox outlined...

My step #3 is the sum of steps 1 and 2.

My step #4 is the sum of steps 3 and 4.

I suggested DGs to manage the pairs. Dynamox choose to avoid devicegroups (DGs) at all.

It's simply a matter of taste. I often use pairfiles instead of device groups. :-)

My step #5 doesn't map (as explaned above)

My step #6 maps again to step 4 (Dynamox creates pairs AND put them in ACP_DISK mode at the same time, no practical differences: the pairs are in acp_disk BEFORE you establish them )

My step #7 maps to step 5 in Dynamox's perspective

My step #8 maps -again- to step 5

My step #10 maps to step 6.

Thus no great differences... ;-)

Siddu,

You can enable the dyn_rdf attributes (and issue createpair operations, turning devices into R1s) online without affecting production data integrity or data access.

Thanks,

- Sean

Hi,

Currently I have Critical Data which I want to Migrate from Source VMAX to Target VMAX. If I set attributes on the source devices will it problem for the Data.

Regards,

Siddu

Setting the R1 attribute doesnt affect the data

Regards,
Ugin

Thanks a ton Sean and Ugin for your valuable inputs..definitely it will help me a lot.

Below is my scenario

Currently Server A is Running with VMAX A and I want to Migrate the Server A with Same WWN to VMAX B
i.e Relocating the Blade to Another location where it can see VMAX b
I want to Migrate the Data using SRDF. In this Situation how to handle the Target Server with the same wwn as Source.

Regards,

Siddu

what do you mean target server with the same WWN ? Typically blade server these days get their WWN from a pool, it's not the hardcoded WWN on the mezzanine/CNA itself. Either way you will need to redo your zoning and masking on VMAX b.

If you want to server to communicate with vmax B then you can zone them.

seems like you want to remove your source server from vmax A and then want to zone with vmax B ?
please brief your question again, for clear solution