SRDF (W2K)

Advanced SRDF Operations: Disaster Recovery

Summary:

In the previous lab exercise, a Volume Group was created using SRDF R1 volumes and a Logical Volume and filesystem were added.  The previous exercise also demonstrated how to suspend and resume SRDF links, and how to check for invalid tracks using the SYMCLI monitoring tools.  This exercise will build on this understanding and demonstrate how SRDF can be used as part of a disaster recovery plan.

Objectives:

a)     Make the target (R2) volumes active, using SRDF failover procedures.

b)     Make the source (R1) volumes active, using SRDF failback procedures.

c)     Understand the process of exporting a Volume Group from one host and importing it on another host.

This exercise builds on the previous exercise.  So first we will confirm that the hosts are properly configured for SRDF and that the SRDF volumes are in the proper state.  Next, this exercise will set up a scenario where the local host or source  Symmetrix ICDA has failed (site failure) and the SRDF target volumes and the data contained in them, are made available to the remote host attached to the target Symmetrix.

1)  Verify that SRDF is properly configured on both the local and remote hosts.

a)     Use the following SYMCLI commands to list and verify the device groups you created in the previous exercise.
   # symdg list  (on both the local and remote hosts)
 # symdg show mysrcdg (on the local host)

 # symdg show mytgtdg (on the remote host)

b)     Check the environment variables for SYMCLI and if necessary set the SYMCLI_DG variable to your device group.
# symcli –def
# SYMCLI_DG=mysrcdg  (on the local host)
# set SYMCLI_DG

# SYMCLI_DG=mytgtdg  (on the remote host)
# set SYMCLI_DG

c)      Verify the status of the devices in your device group. The local host should have RW access to the source (R1) volumes, the remote host should see the target (R2) volumes as being WD, the SRDF link should be enabled (RW), and there should be no invalid tracks.
# symrdf query  (on the local host)

2)   Verify that drive letters are assigned and available for use.  Perform this step on the local host.

a)     Add more data files to your filesystems in Windows Explorer.

3)   Pass control of the SRDF volume and associated data to the remote host.  Before we test disaster failover, we will do a normal failover to verify the procedure.  This step not only involves passing control of the SRDF volumes to the remote host, it also requires that the remote host understand how the volumes are configured. If the local host has created volume partitions and filesystems on the SRDF source volumes, then the Volume information must be imported to the remote host, after a failover. In Windows 2000 drive letter assignments to Basic disks should be automatic after a failover.

a)     While in a disaster situation it is not possible to ”gracefully” shutdown applications and unassign drive letters, it is always less risky to do so when ever possible.  Before passing control of the SRDF volume to the remote host, we will first unassign the drive letters on the local host to deactivate the Volume.

i)        Unassign the drive letters in “Disk Management” by right clicking on the correct disk and selecting the option to “change drive letter and path”, then click on the drive and select “remove”. If you have the SIU/CLI then use the following command strings:

# symntctl openhandle –drive “drive_letter” (on the local host)     -  to verify that no processes are using the R1 volume

# symntctl umount –drive “drive_letter” –fs              (to dismiss cache buffers)

# symntctl umount –drive “drive_letter”

b)     Initiate failover of the SRDF volumes by executing the following command from the remote host.  The failover command can be executed from the local host.  How ever, in a true disaster situation, we may not have access to the local host.
# symrdf failover (on the remote host)
Note the verbose output from the failover command.  Each step is displayed as it is executed.  The output could be piped to a file and saved for future study or reference.  More detailed information is logged in the /var/symapi/log directory.

c)      View the status of both the R1 and R2 volumes.
# symrdf query (on the remote host)
What level of access does the local host have to the source (R1) volumes?
_________________________________________
What level of access does the remote host have to the target (R2) volumes? _________________________________
The source volumes should be Write Disabled (WD) and the target volumes Read/Write (RW).  Even though the local host has read access to the source volumes, use caution when accessing it as integrity cannot be guaranteed. 

d)     Before the remote W2K host can use the data on the SRDF target volumes, the Volume definition information must be ”imported”. At the remote host, find the drive letters assigned to the R2 copies. In the Windows Explorer program, select the assigned drive letters to verify that the copied data is available.

4)   Resume activities on the target host. The remote host now has full access to the SRDF volumes and associated data. To simulate production after a failover, we will make some changes to the filesystem.

a)  While at the remote host, add some data on the R2 mirrored volumes at that server.

b)     While changes are being made to the SRDF (R2) volumes from the remote host, the link between the source and target volumes is disabled.  Check to see how many invalid tracks have accumulated, using the appropriate command.
# symrdf query
How many invalid tracks are there? ___________________________
How many MB does this represent? ___________________________
Are the invalid tracks on the R1 or R2 Volumes? ____________________

5)   Pass control of the SRDF volumes and data back to the local host.

a)     The remote host should not have the drive letters of the R2 volumes mounted while control is being passed back to the local host because the remote host’s access to the target volumes will change to Read Only (WD).   Attempting to write to the filesystem while the volumes are Write Disabled will cause unpredictable results.

i)        Unassign the drive letters in “Disk Management” by right clicking on the correct disk and selecting the option to “change drive letter and path”, then click on the drive and select “remove”. If you have the SIU/CLI then use the following command strings:

# symntctl openhandle –drive “drive_letter” (on the local host)     -  to verify that no processes are using the R1 volume

# symntctl umount –drive “drive_letter” –fs              (to dismiss cache buffers)

# symntctl umount –drive “drive_letter”

b)     Make the source volumes active by executing the following command.
# symrdf failback  (on the remote host)

c)      View the status of both the source (R1) and the target  (R2) volumes.
# symrdf query  (on the remote host)
What level of access does the local host have to the source volumes?
________________________________

What level of access does the remote host have to the target volumes? _________________________________
Is the link enabled? _________________

d)     On the local host, ensure the drive letters of the R1 volumes are mounted and verify that the  files that were created while the remote host had control of the SRDF volumes are there. 

Note:  If the structure of the logical volume (represented by the drive letter) changed while the remote host was controlling the Volume, the volume definition on the source host would no longer be current.  In that case, the Volume definition on the local host would no longer be current.  In that case, the definitions have to be recreated on the local host.  There are no native tools in W2k to redefine the volume definition for basic disks. It would have to be done through another method. If the volume definition is on dynamic disks created with Veritas, then the import/deport process can be controlled with the EMC Resource Paks’ - symntctl.exe utility command.

6)  Exercise Complete.  This concludes SRDF Lab 2.  We have explored the use of SRDF for disaster recovery applications.  Unless otherwise directed by the instructor, continue with SRDF Lab 3 where you will explore using SRDF for Decision Support Applications.

Exercise Wrap-up:

symrdf failover ________________

symrdf failback ________________

What are the Volume Management considerations prior to a failover or a failback?

 ___________________________________