EMC Symmetrix / DMX SRDF Setup

January 26th, 2009 Devang Panchigar Leave a comment Go to comments

TO SUBSCRIBE TO STORAGENERVE BLOG

This blog talks about setting up basic SRDF related functionality on the
Symmetrix / DMX machines using EMC Solutions Enabler Symcli.
For this setup, lets have two different host, our local host will be R1
(Source) volumes and our remote host will be R2 (Target) volumes.
A mix of R1 and R2 volumes can reside on the same symmetrix, in short you
can configure SRDF between two Symmetrix machines to act as if one was
local and other was remote and vice versa.
Step 1
Create SYMCLI Device Groups. Each group can have one or more Symmetrix
devices specified in it.
SYMCLI device group information (name of the group, type, members, and
any associations) are maintained in the SYMAPI database.
In the following we will create a device group that includes two SRDF
volumes.
SRDF operations can be performed from the local host that has access to the source volumes or
the remote host that has access to the target volumes. Therefore, both hosts should have device
groups defined.
Complete the following steps on both the local and remote hosts.
a) Identify the SRDF source and target volumes available to your assigned hosts. Execute the
following commands on both the local and remote hosts.
# symrdf list pd (execute on both local and remote hosts)
or

# syminq
b) To view all the RDF volumes configured in the Symmetrix use the following
# symrdf list dev
c) Display a synopsis of the symdg command and reference it in the
following steps.
# symdg h
d) List all device groups that are currently defined.
# symdg list
e) On the local host, create a device group of the type of RDF1. On the remote host, create a
device group of the type RDF2.
# symdg type RDF1 create newsrcdg (on local host)
# symdg type RDF2 create newtgtdg (on remote host)
f) Verify that your device group was added to the SYMAPI database on both the local and remote
hosts.
# symdg list
g) Add your two devices to your device group using the symld command. Again use (h) for a
synopsis of the command syntax.
On local host:
# symld h
# symld g newsrcdg add dev ###
or
# symld g newsrcdg add pd Physicaldrive#
On remote host:
# symld g newtgtdg add dev ###
or

# symld g newtgtdg add pd Physicaldrive#

h) Using the syminq command, identify the gatekeeper devices. Determine if it is currently
defined in the SYMAPI database, if not, define it, and associate it with your device group.
On local host:
# syminq
# symgate list (Check SYMAPI)
# symgate define pd Physicaldrive# (to define)
# symgate -g newsrcdg associate pd Physicaldrive# (to associate)
On remote host:
# syminq
# symgate list (Check SYMAPI)
# symgate define pd Physicaldrive# (to define)
# symgate -g newtgtdg associate pd Physicaldrive# (to associate)
i) Display your device groups. The output is verbose so pipe it to more.
On local host:
# symdg show newsrcdg |more
On remote host:
# symdg show newtgtdg | more
j) Display a synopsis of the symld command.
# symld -h
k) Rename DEV001 to NEWVOL1
On local host:

# symld g newsrcdg rename DEV001 NEWVOL1

On remote host:
# symld g newtgtdg rename DEV001 NEWVOL1
l) Display the device group on both the local and remote hosts.
On local host:
# symdg show newsrcdg |more
On remote host:
# symdg show newtgtdg | more
Step 2
Use the SYMCLI to display the status of the SRDF volumes in your device
group.
a) If on the local host, check the status of your SRDF volumes using the following command:
# symrdf -g newsrcdg query
Step 3
Set the default device group. You can use the Environmental Variables
option.
# set SYMCLI_DG=newsrcdg (on the local host)
# set SYMCLI_DG=newtgtdg (on the remote host)
a) Check the SYMCLI environment.
# symcli def (on both the local and remote hosts)
b) Test to see if the SYMCLI_DG environment variable is working properly by performing a
query without specifying the device group.
# symrdf query (on both the local and remote hosts)
Step 4

Changing Operational mode. The operational mode for a device or group of

devices can be set dynamically with the symrdf set mode command.
a) On the local host, change the mode of operation for one of your SRDF volumes to enable
semi-synchronous operations. Verify results and change back to synchronous mode.
# symrdf set mode semi NEWVOL1
# symrdf query
# symrdf set mode sync NEWVOL1
# symrdf query
b) Change mode of operation to enable adaptive copy-disk mode for all devices in the device
group. Verify that the mode change occurred and then disable adaptive copy.
# symrdf set mode acp disk
# symrdf query
# symrdf set mode acp off
# symrdf query
Step 5
Check the communications link between the local and remote Symmetrix.
a) From the local host, verify that the remote Symmetrix is alive. If the host is attached to
multiple Symmetrix, you may have to specify the Symmetrix Serial Number (SSN) through the
sid option.
# symrdf ping [ -sid xx ] (xx=last two digits of the remote SSN)
b) From the local host, display the status of the Remote Link Directors.
# symcfg RA all list
c) From the local host, display the activity on the Remote Link Directors.
# symstat -RA all i 10 c 2
Step 6

Create a partition on each disk, format the partition and assign a filesystem
to the partition. Add data on the R1 volumes defined in the newsrcdg device
group.
Step 7
Suspend RDF Link and add data to filesystem. In this step we will suspend
the SRDF link, add data to the filesystem and check for invalid tracks.
a) Check that the R1 and R2 volumes are fully synchronized.
# symrdf query
b) Suspend the link between the source and target volumes.
# symrdf suspend
c) Check link status.
# symrdf query
d) Add data to the filesystems.
e) Check for invalid tracks using the following command:
# symrdf query
f) Invalid tracks can also be displayed using the symdev show command.
Execute the following command on one of the devices in your device group.
Look at the Mirror set information.
On the local host:
# symdev show ###
g) From the local host, resume the link and monitor invalid tracks.
# symrdf resume
# symrdf query
In the next upcoming blogs, we will setup some flags for SRDF and
Director types, etc.
Happy SRDFing!!!!!

SRDF Commands
December 2nd, 2008 Devang Panchigar Leave a comment Go to comments

The following are SRDF Commands and what they are used for.
Composite SRDF commands
1. Failover:
1. Actions:
1. Write disables (WD) R1
2. Sets link to Not Ready (NR)
3. Write enables R2
2. Command:
symrdf -g ${group} failover
2. Update: Helps to speed up the failback operation by copying invalid tracks before write
disabling any disks.
1. Actions:
1. Leaves service state as is.
2. Merges the tracks
3. Copies invalid tracks
2. Command:
symrdf -g ${group} update
3. Failback:
1. Actions:
1. Write disables R2
2. Suspends RDF link
3. Merges the disk tracks.
4. Resumes the link
5. Write enables R1
6. Copies the changed data
2. Command:
symrdf -g ${group} failback
4. Split: Leaves both R1 & R2 in write enabled state.
1. Actions:
1. Suspends the rdf link.
2. Write enables R2
2. Command:

symrdf -g ${group} split

5. Establish:
1. Actions:
1. Write disables R2
2. Suspends the rdf link
3. Copies data from R1 to R2
4. Resumes the rdf link.
2. Command:
symrdf -g ${group} [ -full ] establish
6. Restore: Copies data from R2 to R1
1. Actions:
1. Write disables both R1 & R2
2. Suspends the rdf link.
3. Merges the track tables
4. Resumes the rdf link.
5. Write enables R1
2. Command:
symrdf -g ${group} [ -full ] restore
Singular SRDF commands
1. Suspend: symrdf -g ${group} suspend
2. Resume: symrdf -g ${group} resume
3. Set mode: symrdf -g ${group} set mode sync
symrdf -g ${group} set domino on
symrdf -g ${group} set acp_disk skew 1000

EMC SRDF Basics

December 3rd, 2008 Devang Panchigar Leave a comment Go to comments

Conceptually and operationally, SRDF is designed to work in a

WAN/Internet/Cloud/SAN environment with multiple Symms involved, while
Timefinder is local to a Symm, but performs the same functions.
The difference, SRDF can be performed without Geographic boundaries, while Timefinder is
local. The following are various different forms of SRDF that can be used by a customer to
perform SRDF operations.
Synchronous mode

With Synchronous mode, the remote symm must have I/O in cache before the application
receives the acknowledgement. Depending on distance where these Symmetrix machines are
located, this may have a significant impact on performance. This form of SRDF is suggested to
be implemented in a campus environment.
If you want to ensure that the data is replicated real time without dirty tracks from one
symmetrix to the other, you might want to enable Domino effect. With Domino effect, your R1
devices will become not ready if the R2 devices cant be reached.
Semi-synchronous mode
With Semi-synchronous mode, the I/O between the R1 and R2 devices are
always out of sync. The application receives the acknowledgement from the
first write I/O to the local cache. The second I/O isnt acknowledged until the
first is in the remote cache. This form of SRDF is faster than the previous
mentioned Synchronous mode.
Adaptive Copy-Write Pending

With Adaptive Copy-Write Pending, all the R2 volumes are copied over
without the delay of acknowledgement from the application. With this mode,
we can setup a skew parameter that will allow max number of dirty tracks.
Once that number is reached, the system switches to a preconfigured mode
like the semi-synchronous mode until the remote data is all synced. Once
this is hit, SRDF is switched back to Adaptive Copy-Write Pending mode.

EMC Timefinder Commands

December 2nd, 2008 Devang Panchigar Leave a comment Go to comments

The following are the Timefinder Procedural Commands

It outlines everything that needs to be done from start to finish. Realize that for routine
operations, some of these steps wont be needed; however, for the sake of completeness.
Prepare EMC structures
1. Create a Symmetrix disk group
symdg -t [ Regular | RDF1 | RDF2 ] create ${group}
2. Add devices to the disk group

symld -g ${group} add pd /dev/dsk/c#t#d#

symld -g ${group} add dev 01a
3. Associate BCV devices to the disk group
symbcv -g ${group} associate pd ${bcv_ctd}
symbcv -g ${group} associate dev ${bcv_dev}
Establish BCV mirrors
1. ID the logical device names: Timefinder defaults to using the logical device names. You can id
the logical device names by:
symmir -g ${group} query
2. First time establish, execute a full establish:
symmir -g ${group} -full establish ${std_log_dev} bcv ${bcv_log_dev}
3. Use symmir query to monitor progress.
symmir -g ${group} query
Break BCV mirrors
1. Types of splits:
1. Instant split: Split is performed in the background after the completion of the split I/O request.
2. Force split: Splits the pair during establish or restore operations; invalid tracks may exist.
3. Reverse split: Resyncs the BCV with the full data copy from its local or remote mirror.
4. Reverse differential split: Enables a copy of only out-of-sync tracks to the BCV from its
mirror.
5. Differential split: Enables a copy of only the updated tracks to the BCVs mirror.
2. Commands:
symmir -g ${group} split
symmir -g ${group} split -instant
symmir -g ${group} split -differential
symmir -g ${group} reverse split -differential
Reestablish or restore BCV mirrors
1. Restore copies data from BCV back to standard pair. >Reestablish, on the other hand, does a
differential update of the BCV from the standard device.

2. Commands:
symmir -g ${group} establish Differential reestablish from standard device to BCV
symmir -g ${group} -full restore Full restore of all tracks on BCV to standard device.
symmir -g ${group} restore Differential restore of BCV data to standard device.
The Timefinder Strategies are as follows
1. Maintain BCV mirrors with the standard device; break the mirrors when you want to backup,
test, or develop on a copy of the original.
This is probably the most common way of running Timefinder. The advantage is that the split
operation will happen almost instantly as the mirrors are fully synced all the time. The
disadvantage is that anything towards that happens to the standard device will be reflected in the
BCV mirror.
2. Maintain the BCV as a split device to keep an online backup of the original data.