SRDF/A - SYMRDF Commands and Confusion!

This is depend this might be true in your environment becasue if you want to do real DR test then this means you do not have access to PROD server means PROD is gone and you want to run your production from DR side in this case you will run failover, once your PROD is back you will failback to PROD with changes. If you are doing split both sides are RW enable and this does not satisfy the requirement for real DR test.

Add to the answer above...

When we run DR test we just do the split/establish to prevent anything from the DR test getting written back to the R1s. This is somewhat defined by the scope of our DR testing (we don't actually test running production in our DR environment... at least not yet).

If you want to bring back the changes from DR server then you need to do failover/failback. Split will not bring back the changes, restore is full resynch from DR to PROD.

I hope this will help.

Best regards,

Majid Ali

And again I say "that depends on the SCOPE of the DR test". If your scope is a FULL DR test then that doesn't meet the requirements, but there are many different kinds of DR tests.

We even have DR tests that don't involve anything beyond calling everyone and verifying that all the contact info we have is correct to get everyone engaged.

Majid:

Thanks for your reply, however, I'm not sure I agree that a Split followed by a Restore is a full resync. Can you elaborate in this regard?

Additionally, when I execute a symrdf -g split, the default RDF state is "Failed over". Therefore, my only options at that point are failback, restore, or establish. Given that Establish nulls any changes at R2, I guess my main confusion is what the difference is between Failback and Restore.

Thanks!

Please note that establish, split, restore and a lot of other useful symrdf commands are sort of "macro" commands since they will issue multiple low level commands.
If you look at Symcli manuals (I'm looking at Solution Enabler 6.5 documentation CD, available here, in powerlink) you'll find so called "Composite commands" (sort of macro commands) and "Singular commands" (the building blocks).

Also note that symrdf will report a "status" that depends on various details .. It depends on the status of R1 and R2 volumes (RW, WD), the status of the link (RW, NR) and invalid tracks. If you issued a split, subsequent queries shouldn't report status as Failed Over. Can you please show the output of the commands you issued ??

We issue restore in situation when we have corrupted data at R1 side and we want R2 data. As far as state is FAILEDOVER after split. Normally you will see state SPLIT instead of FAILDOVER, you will see FAILEDOVER if your devices are not mapped to any front end adaptor or if you are dealing with mainfram devices. Before DR test you have to do some homework what is teh goal of DR test? They are just testing the application at DR site or they want real DR test. If you still need further help then open service request with EMC support, they will look at logs and advice you accordingly.

Thanks for everybody's suggestions. For DR tests, and to get as close to possible for running actual commands without overwriting R1 data, we are going to do a failover then a swap. Then when the test is complete, the idea is to issue a split and run a establish which will force the R2 data to be overwritten by R1.

Documentation / planning for the commands to run in a graceful failover, appear to be very straightforward and textbook. However, if the link were to be cut in a real dr, and the link goes partitioned - what are the device states at the R2 side? (RW, WD?) Thanks!

No - a failback moves production from the R2 side to the R1 side. It makes the R2 write disabled (WD), the R1 read/write enabled (RW), invalidates the R1 tracks which have been updated on the R2, then makes the logical RDF link RW.

The R1 then "realises" it has local invalid tracks and begins to read them across the link to sync up the R1. In theory you can re-start production as soon as the links have been make RW, because host reads for tracks which have not yet been copied back will be done (at a performance penalty) across the RDF link. In practice you should consider SRDF "update"(s) prior to the failback to shift over the bulk of the data. (NB: An SRDF "update" always makes the data on the R1 inconsistient, until the failback is complete).

Once the failback is complete the SRDF state will be "Synchronised" and writes to the R1 will be synchronously mirrored to the R2 as usual.

Hope that helps!
Marc

I'm always confused with this... So a failback startes replicating from R2 to R1 ? So when the R1's and R2's are sync'd you need to resume the replication again to get the normal replication process going again from R1 to R2 ?

Clear, so I only need a failback and that's it ! (plus the update for a little while)
It's even easier than I thought !

Rob I gave a simplified "translation" of "srdf failback" .. Marc gave a better and deeper explanation of what "failback" is

I theory I know what it all does, but I've never tested it... yet. I know, I should be ashamed of myself, but I've never had the time.

So I just ran a LINK failure test (simply disabled the port on the Cisco) to simulate a link failure. I noticed the R2 side shows up as NA / Partitioned. In that state, what would be the proper steps to get the R2 side in business? Ie. How would I ready and write enable?