Dell EMC Solutions Enabler 9.2 SRDF Family CLI User Guide

Unplanned workload switch to asynchronous target site: concurrent SRDF/Star

1. From a Star control host at the asynchronous target site (London), issue the symstar cleanup command to clean up any internal metadata or cache remaining at the asynchronous site.

   To clean up the London site:

   symstar -cg StarGrp cleanup -site London

   NOTE:

   After a workload site failure, splitting the remote BCVs maintains a consistent image of the data at the remote site until it is safe to reestablish the BCVs with the R2 devices.

   The next step varies depending on whether SRDF/Star data at the remote site are protected with TimeFinder BCVs:

   • If SRDF/Star data at the remote site are protected with TimeFinder BCVs, proceed to Step 2.
   • If not, skip to Step 3.
2. If SRDF/Star data are protected with TimeFinder BCVs at the NewJersey site, perform the appropriate TimeFinder actions.

   Prior to the switch and resynchronization between NewJersey and London, there is no existing SRDF relationship between the synchronous and asynchronous target sites.

   BCV control operation must be performed with a separate device file instead of the composite group.

   In the following example, the device file (StarFileNewJersey) defines the BCV pairs on array 13 in London.

   To split off a consistent restartable image of the data volumes during the resynchronization process using the device file:

   symmir -f StarFileNewJersey split -star -sid 16

3. From a Star control host at the asynchronous target site (London), issue the symstar switch command to start the workload at the specified site. The following command:
   • Specifies London as the new workload site (-site NewJersey)
   • Retains the data at the NewJersey data instead of the London data (-keep_data NewJersey):

   symstar -cg StarGrp switch -site London -keep_data NewJersey

   The workload site switches to London and the R2 devices at London become R1 devices.

   The London site connects to the NewJersey site and retrieves the NewJersey data.

   NOTE:

   The connect action is not required because the switch action specified that SRDF retrieve the remote data from the NewJersey site.

   The following image shows the resulting SRDF/Star state:

   

4. From a Star control host at the asynchronous target site (London), issue the protect command to protect London to NewJersey:

   symstar -cg StarGrp protect -site NewJersey

   The following image shows the resulting SRDF/Star state:

   

   NOTE:

   London is now using the NewJersey data. You cannot start the application workload in London until the switch action completes. This ensures that all of the SRDF pairs are synchronized prior to starting the workload. The symstar switch command blocks other action until it completes.

   The next step varies depending on whether SRDF/Star data at the remote site are protected with TimeFinder BCVs:

   • If SRDF/Star data at the remote site are protected with TimeFinder BCVs, proceed to Step 5.
   • If not, skip to Step 6.
5. Reestablish any BCV pairs at the NewJersey site.
   Use either:

   • The device file syntax (-f StarFileNewJersey), or
   • The -cg syntax (if you have associated the NewJersey BCV pairs with the StarGrp composite group on the Star control host).

   To reestablish NewJersey BCV pairs in the composite group StarGrp using the -cg syntax:

   symmir -cg StarGrp establish -star -rdf -rdfg name:NewJersey

6. The London site is at asynchronous distance from both NewYork and NewJersey. SRDF/Star supports only one asynchronous site.

   When the NewYork site is repaired, you cannot connect and protect NewYork without switching the workload back to a configuration that has only one asynchronous site (NewYork or NewJersey).

   However, you can connect to NewYork. The connect action sets the mode to adaptive copy disk and brings the devices to RW on the SRDF links.

   To connect to NewYork, issue the connect command from the London site:

   symstar -cg StarGrp connect -site NewYork

   The following image shows the resulting SRDF/Star state:

   

   If the workload remains at the asynchronous London site, you can perform a protect action on NewYork only if you first unprotect NewJersey.

   The protect action transitions the link from adaptive copy mode to asynchronous mode and enables SRDF consistency protection.

   The symstar enable action is blocked because there is already one asynchronous link in the Star.

   NOTE:

   Using SYMCLI to Implement SRDF/Star Technical Note provides expanded operational examples for SRDF/Star.