DR Questions / SYMRDF

Question

Hi. I could use some help in understanding what to expect when we perform a DR test, and how best to handle the environment once we break our link. The document "Performing Failover and Failback Disaster Recovery Operations Using EMC Cascaded SRDF" is an excellent resource, but it's detailing a cascaded config, and that is not how we're set up. We're simply a site A and a site B.

At the moment, I've been putting together end-user failover scripts that have been tested in controlled scenarios. Basic layout is:

unmount volumes on host

symrdf disable

symrdf failover

symrdf swap

symrdf enable

mount volumes on host (new R1)

symrdf establish

We chose to go this route (in lieu of failover / failback) so that we can use the exact same scripts from either side of the network.

As I mentioned, up until now, everything has been in a controlled environment. However, formal full-blown DR testing is part of our exercises. With EMC being an entirely new platform to us, it would be a great help if I could get some insight to what I should expect when we cut the cable. I read on in some of the other discussions that the status will change to "partitioned", which is not something I've seen. It's not feasable for us to simply break the link at any given time for testing. But, we do have a formal (full) DR drill coming up. Some of what I've been reading indicated that it would be as simple as performing a failover on the R2 side, and then a failback when we re-establish the link. I doubt it's that simple. Obviously, I don't want to run the risk of corrupting any data when we do bring the original R1 back to life. But, the R2 site will become "active". Whatever data is collected from that point will need to be replicated back to the R1 site when it's "restored".

Thanks.

ZepHead · Answer

Check out the SRDF Product Guide from PowerLink.. See if this answers your questions and addresses your concerns..

bcidern · Answer

Thanks. I have been through that, but having not had the opportunity to test/validate what I would expect to see, and then how to action upon a DR scenario, I wanted to get some input from people who have been though this before.

However, about an hour ago, our Infrastructure team simulated a DR by blocking ports. Immediately, we did see the "Partitioned" state.

And, in accordance with the documentation I found, and what had been produced by the Procedure Generator, our initial approach will be:

Begin DR:

SYMRDF failover

State should be "split"

Recover from DR:

SYMRDF write_disable R1

SYMRDF update

SYMRDF failback

I think myself and the Infra guys are in agreement with these steps and we may attempt a dry run tomorrow. We have a formal DR this coming weekend and my goal is to minimize the bumps and bruises we'll suffer. Again, this SAN is new to us, having come from a Hitachi.

ZepHead · Answer

Appreciate coming to the EMC side..

Partitioned is basically the inability to reach "the other side", so that is what I would expect.

If the documentation provided (or even the testing), doesn't really satisfy what you are trying to achieve, please reach out to your Service Manager so that the local team can take a look, advise, etc., in order to help get the most out of EMC products.

Yes, lets see if anyone else can share their experiences as well

sauravrohilla · Answer

HI,

Blocking a port is not a good way to test DR as it would break the RDF communication to your remote Symm and thus give you the partition state. In partition state you can make R2 RW manually. You have also mentioned:

Begin DR:

SYMRDF failover

State should be "split"

When you do a Symrdf failover, the state would be "Failed Over" (R1 will be WD and R2 RW) not "Split". And "Recover from DR" steps, you really dont require to make R1 write disable as it would already be in write_disabled state after fail over. Rest all looks good...

Thanks,

Saurabh

Symmetrix

DR Questions / SYMRDF

Was this post helpful?