Start a Conversation

Unsolved

This post is more than 5 years old

1592

June 16th, 2010 14:00

How to test symrecover

We are thinking about implementing symrecover to monitor our SRDF/A sessions. We need to test it on a test device group.

I think this can be done by doing a "symrdf -g test-dg suspend".

     Will this only suspend the test-dg device group and not the production device groups?

     Will symrecover now see the session suspended and re-establish it?

     Any other suggestions for testing?

Thank you

5 Practitioner

 • 

274.2K Posts

June 17th, 2010 07:00

HI,

The suspend command you list is designed to only affect the designated group. The other production grps will remain unaffected. I've not really tested this scenario in a lab but I would assume that the suspend cmd would fail due to the fact you have a srdf/a session running. You would likely have to use a "force" to to get the group to suspend. At that point the symrecover monitoring tool should attempt to recover the suspended group.  

The below is from primus article emc145829.

The SymRecover command provides the user interface to the EMC SRDF session state monitoring tool. SymRecover is a session state monitor. That means that it does not do any predictive analysis using I/O trends or cache rates. It simply monitors the state of a single device group or composite group, and when that group becomes suspended or partitioned it attempts to restart the SRDF/A or /S session for that group. SymRecover can be run from either the R1 or the R2 side; however, when concurrent RDF is used, this command must be run from the R1 side.

Tool requirements:

  • Solutions Enabler v6.3.0 or higher must be installed.
  • Solutions Enabler binaries must either be in the PATH or specified as a parameter.
  • SymRecover can only be run with the perl shipped with Solutions Enabler.
  • Either the Solutions Enabler perl must be in the PATH or fully qualified on the command line.
  • The initial group state must be consistent unless the restart_group_on_startup option is specified (not the default).
  • If consistency protection is desired it must be present at tool startup.
  • R2 gold copy use is supported and its use is the default, using either BCVs or clones using BCV emulation.
  • BCV to STD association for the R2 gold copy is dynamic using the symmir defaults.
  • If the group is concurrent then SymRecover must be run from the R1 side.

Recovery restart code for an SRDF/A session:

  1. If the group state is suspended:
    1. If user specified, create an R2 gold copy.
       

    2. Issue the symrdf disable command to remove consistency protection.
       

    3. Issue the symrdf set mode acp_disk command to place the group in adaptive copy.
      1. Establish the devices 
      2. Wait for the number of outstanding tracks to fall to 30000.

  2. Issue the ‘symrdf set mode async’ command to return the group to SRDF/A mode.
     

  3. Establish the devices.
     

  4. If this group was enabled for consistency protection at tool startup, then re-enable consistency protection.
     

  5. Wait for the group to enter the consistent state,
     

  6. If this is a composite group, and if RDF consistency was enabled at tool startup, then wait for group to become cg_consistent.
     

  7. If the restart was successful, reset gold copy to the -goldcopy_bcv_r2_mirror_state_post_restart defined state (establish or split).
     

  8. Return to main group state monitoring loop.
No Events found!

Top