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 isn’t 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.
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
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, let’s 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 SRDF’ing!!!!!

What is SRDF? It is Symmetrix Remote Data Facility (SRDF), EMC SRDF family of replication software offers
various levels of EMC Symmetrix based business continuance and disaster recovery solutions. The SRDF
products offer the capability to maintain multiple, host-independent, copies of data. The EMC Symmetrix
systems can be in the same room, in different buildings within the same campus, or hundreds to thousands of
kilometers apart.
By maintaining copies of data in different physical locations, SRDF enables you to perform the following
operations with minimal impact on normal business processing:
Disaster restart

• Disaster restart testing

• Recovery from planned outages
• Remote backup
• Data center migration
• Data replication and mobility
The SRDF family consists of three base solutions:
• SRDF/Synchronous (SRDF/S) — High-performance, host-independent, real-time synchronous remote
replication from one Symmetrix to one or more Symmetrix systems.
• SRDF/Asynchronous (SRDF/A ) — High-performance extended distance asynchronous replication using
a Delta Set architecture for optimal bandwidth utilization and minimal host performance impact.
• SRDF/Data Mobility (SRDF/DM ) — Rapid transfer of data from source volumes to remote volumes
anywhere in the world, permitting information to be shared and content to be distributed, or information
consolidated for parallel processing activities.

SRDF functional overview

EMC Symmetrix systems use local mirroring, or RAID 1, as one method of protecting data by maintaining data
on both a production volume and a mirror volume within the same storage unit. SRDF uses a method of data
protection known as remote mirroring. Remote mirroring is similar to local mirroring, except that the primary
volume resides in one storage unit while its remote mirrors (up to two remote mirrors are supported with
Concurrent SRDF) reside in a different storage unit.
When the main storage systems are down for a planned or unplanned event, SRDF enables fast switchover from
the primary data to the secondary copy. The local SRDF device, known as the primary (source, R1) device, is
configured in a pairing relationship with a secondary (target, R2) device, forming an SRDF pair. While the R2
device is mirrored with the R1 device, the R2 device is either write disabled or not ready to its host. (Not ready
means disabled for both reads and writes.) After the R2 device becomes synchronized with its R1 device, you
can halt the remote mirroring to the R2 device from the R1 device at any time, making the R2 device fully
accessible again to its host. After the remote mirroring is halted, the secondary (target, R2) device contains valid
data and is available for performing business continuance tasks through its original host connection or restoring
(copying) data to the primary (source, R1) device if there is a loss of data on that device.

Figure 1 Basic EMC SRDF configuration

Symmetrix V-Max Systems: SRDF Enhancements and Performance
So this was one of those posts that I always wanted to write related to Symmetrix V-Max and SRDF
enhancements that were incorporated with the 5874 microcode.

Yesterday morning had a chat with a friend and ended up talking about SRDF and then later in the day
had another interesting conference call on SRDF with a potential customer. So I really thought, today
was the day I should go ahead and finish this post.
Back in April 2009 when the V-Max systems were initially launched, Storagezilla had a post on V-Max
and SRDF features, he covers quite a bit of ground related to the Groups and the SRDF/EDP (Extended
Distance Protection).
Here are the highlights of SRDF for V-Max Systems
SRDF Groups:
1. 250 SRDF Groups with Symmetrix V-Max (5874) Systems. In the prior generation Symmetrix
DMX-4 (5773), it had support for 128 groups. Logically even with 2PB of storage, very seldom
do customers hit that mark of 250 groups.
2. 64 SRDF groups per FC / GigE channel. In the previous generation Symmetrix DMX-4 (5773),
there was support for 32 groups per channel.
SRDF Consistency support with 2 mirrors:
1. Each leg is placed in a separate consistency group so it can be changed separately without
affecting the other.
Active SRDF Sessions and addition/removal of devices:
1. Now customers can add or remove devices from a group without invaliding the entire group,
upon the device becoming fully synced it should be added to the consistency group (with
previous generation Symmetrix DMX-4, one device add or remove would cause the entire
group to invalidate requiring the customers to run full establish again).
SRDF Invalid Tracks:
1. The “long tail” – last few tracks search has been vastly improved. The search procedure and
methods for the “long tail’ has been completely redesigned. It is a known fact with SRDF, that
the last invalid tracks take a lot of time to sync as its going through the cache search.
2. The SRDF establish operations speed is at least improved by 10X; see the numbers below in the
performance data.
Timefinder/Clone & SRDF restores:
1. Customers can now restore Clones to R2 and R2’s to R1’s simultaneously, initially with the
DMX-4’s this was a 3-step process.
SRDF /EDP (Extended Distance Protection):
1. 3-way SRDF for long distance with secondary site as a pass through site using Cascaded SRDF.
2. For Primary to Secondary sites customers can use SRDF/S, for Secondary to Tertiary sites
customer can use SRDF/A
3. Diskless R21 pass-through device, where the data does not get stored on the drives or consume
disk. R21 is really in cache so the host is not able to access it. Needs more cache based on the
amount of data transferred.
4. R1 — S –> R21 — A –> R2 (Production site > Pass-thru Site > Out-of-region Site)
5. Primary (R1) sites can have DMX-3 or DMX-4 or V-Max systems, Tertiary (R2) sites can have
 DMX-3 or DMX-4 or V-Max systems, while the Secondary (R21) sites needs to have a V-Max
system.
R22 – Dual Secondary Devices:
1. R22 devices can act as target devices for 2 x R1 devices
2. One Source device can perform Read write on R22 devices
3. RTO improved with primary site going down
Other Enhancements:
1. Dynamic Cache Partitioning enhancements
2. QoS for SRDF/S
3. Concurrent writes
4. Linear Scaling of I/O
5. Response times equivalent across groups
6. Virtual Provisioning supported with SRDF
7. SRDF supports linking Virtual Provisioned device to another Virtual Provisioned device.
8. Much more faster dynamic SRDF operations
9. Much more faster failover and failback operations
10. Much more faster SRDF sync’s
Some very limited V-Max Performance Stats related to SRDF:
1. 36% improved FC performance
2. FC I/O per channel up to 5000 IOPS
3. GigE I/O per channel up to 4000 IOPS
4. 260 MB/sec RA channel I/O rate, with DMX-4 it was 190 MB/seconds
5. 90 MB/sec GigE channel I/O rate, with DMX-4 it was almost the same
6. 36% improvement on SRDF Copy over FC
7. New SRDF pairs can be created in 7 secs compared to 55 secs with previous generations
8. Incremental establishes after splits happen in 3 seconds compared to 6 secs with previous
generations
9. Full SRDF establishes happen in 4 seconds compared to 55 seconds with previous generations
10. Failback SRDF happen in 19 seconds compared to 47 seconds with previous generations