SRDF Star and Cascaded SRDF Solution SRG PDF

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.
SRDF/Star and Cascaded SRDF Solutions
2010 EMC Corporation. All rights reserved.
Welcome to SRDF/Star and Cascaded Star Solutions.

The AUDIO portion of this course is supplemental to the material and is not a replacement for the
student notes accompanying this course.
EMC recommends downloading the Student Resource Guide from the Supporting Materials tab, and
reading the notes in their entirety.
These materials may not be copied without EMC's written consent.
EMC believes the information in this publication is accurate as of its publication date. The
information is subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION
MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE
INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an
applicable software license.
EMC is a registered trademark and SRDF/Star is a trademark of EMC Corporation.
All other trademarks used herein are the property of their respective owners.
-1
Course Objectives
Upon completion of this course, you will be able to:
y List EMC SRDF Three Data Center Solutions
y Describe Cascaded SRDF Solutions including SRDF/
EDP
y Describe SRDF/Star Solutions
SRDF/Star and Cascaded SRDF Solutions - 2
The objectives for this course are shown here. Please take a moment to read them.
-2
Module 1: Cascaded SRDF and SRDF/EDP

Upon completion of this module, you will be able to:
y List SRDF three data center solutions
y Describe Cascaded SRDF and SRDF/EDP
The objectives for this module are shown here. Please take a moment to read them.
-3
Rationale for Three Data Center SRDF Solutions

y Protect against local and
regional site disruptions
Continuous data availability
Multiple remote-recovery sites
Meet regulatory requirements
Support multiple service levels
with tiered storage
y Enable fast recovery

y Provide fast failback
The right remote replication solution can limit your exposure to planned and unplanned downtime,
enabling fast application recovery and fast failback. Data protection and faster business restart in the
event of a disaster or unplanned outage are critical across the organization.
EMC offers the largest number of choices for insuring data availability with its portfolio of three site
replication solutions. Customers deploying EMCs three site solutions can enable fast application
restart in the event of local or regional disasters, along with having fast site failback using SRDF based
data resynchronization.
-4
Three Data Center SRDF Solutions

y Multi-hop SRDF/AR
Combination of SRDF/S and SRDF/DM to provide disaster restart at remote
location
y Concurrent SRDF
Typically a combination of SRDF/S and SRDF/A to provide two real time
copies of data at different distances
y Cascaded SRDF
Combination of SRDF/S and SRDF/A to achieve zero data loss at distant
location
y SRDF/EDP
Low cost zero data loss extended distance solution using SRDF/S and
SRDF/A
y SRDF/Star
Premier 3 data center zero data loss solution that permits two target sites to
continue working with remote data protection after loss of Workload site
SRDF/AR is an automated remote replication solution that uses both SRDF and TimeFinder to provide
a periodic asynchronous remote replication of a restartable data image for UNIX and Windows
environments. It is the least expensive of the listed solutions, because it can be configured to run on
lower bandwidth networks than the other solutions. It offers a typical RPO of hours.
Concurrent SRDF permits the maintenance of two data copies. Usually one copy is running SRDF/S is
maintained at a nearby location and offers zero data loss if the primary site fails. The second copy
operating in SRDF/A mode offers an out of region recovery site with an RPO of seconds to minutes
Cascaded SRDF is a 3 site disaster recovery configuration in which data from a primary site is
synchronously replicated to a secondary site, and then asynchronously replicated to a tertiary site. The
major benefit provided with a cascading configuration is its inherent capability to continue
replicating from the secondary site to the tertiary sites in the event that the primary site goes down.
Available with Enginuity 5874, SRDF/EDP is a lower cost solution to achieve no data loss at an outof-region site. Using cascaded SRDF combined with diskless R21 devices in the intermediate (PassThru) site, data passes through the intermediate to the out-of-region site. Symmetrix cache at the
intermediate site buffers the synchronous I/O and converts it to asynchronous SRDF/A traffic.
EMC SRDF/Star is a three-site disaster-restart solution that can enable resumption of SRDF/A with no
data loss between two remaining sites, providing continued remote-data replication and preserving
disaster-restart capabilities. It offers a combination of continuous protection, changed-data
resynchronization, and enterprise consistency between two remaining sites in the event of the
Workload Site going offline due to a site failure.
-5
Cascaded SRDF Overview

y Combination of SRDF/S and SRDF/A for 3-site disaster restart
solution
Data from primary site is replicated to secondary site with SRDF/S
Data is continuously replicated from the secondary site with SRDF/A to a tertiary
site
y Excellent RPO
Zero data loss if primary site fails
Data loss of seconds to minutes if primary and secondary sites fail
y No need for BCV at tertiary site

Site C
Site B
Site A
SRDF/A
SRDF/S
WAN
R1
R21
R21
R2
Cascaded SRDF uses a dual role SRDF R1/R2 device (referred to as SRDF R21 device) on the
secondary site which acts as both an R2 to the primary site and an R1 to the tertiary site.
The major benefit provided with a cascading configuration is its inherent capability to continue
replicating from the secondary site to the tertiary sites in the event that the primary site goes down.
If the primary site fails, production can continue at either site with no data loss, since the copy at the
secondary site is up to date. If both the primary and secondary sites fail, the tertiary site can effect a
disaster restart with data that is at most two SRDF/A cycles behind.
Since at least two copies of production data are always accessible, there is no need to provision BCVs
at the tertiary site, as would be the case with SRDF/AR.
-6
R21 Cascaded Device

y Single device assumes dual roles of R1 and R2
simultaneously
y Device must belong to two RDF groups
y Data received by this device as target is transferred
automatically by this device as a source
y RPO in the order of seconds or minutes
y Synchronous consistency group protection and multisession consistency (MSC) protection available
Cascaded SRDF introduces the concept of the dual role R1/R2 device, referred to as an R21 device.
The R21 device is both an R1 mirror and an R2 mirror.
The underlying technology of cascaded SRDF devices is the same as concurrent RDF. The only
difference is that one mirror is an R2 and the other an R1. Like a concurrent RDF device, each mirror
of a cascaded RDF device must belong to a different RDF (RA) group.
-7
View of Cascaded SRDF Device

# symrdf list -sid 81 -cascaded
Symmetrix ID: 000194900181
Local Device View
---------------------------------------------------------------------------STATUS
MODES
RDF S T A T E S
Sym
RDF
--------- ----- R1 Inv
R2 Inv ---------------------Dev RDev Typ:G
SA RA LNK MDATE Tracks
Tracks Dev RDev Pair
---- ---- -------- --------- ----- ------- ------- --- ---- ------------00BD 00BD
00BD
00BE 00BE
00BE
R21:19
R21:79
R21:19
R21:79
RW
RW
RW
RW
WD
RW
WD
RW
RW
RW
RW
RW
Total
Track(s)
MB(s)
S..2.
A..1.
S..2.
A..1.
0
0
0
0
0
0
0
0
-------- -------0
0
0.0
0.0
WD
RW
WD
RW
RW
WD
RW
WD
Synchronized
Consistent
Synchronized
Consistent
Devices BD and BE in Symmetrix 81

are R2 devices in group 19 and R1
devices in group 79
Legend for MODES:

M(ode of Operation)
:
D(omino)
:
A(daptive Copy)
:
(Mirror) T(ype)
:
(Consistency) E(xempt):
A
X
D
1
X
=
=
=
=
=
Async, S =
Enabled, .
Disk Mode,
R1, 2 = R2
Enabled, .
Sync, E = Semi-sync, C = Adaptive Copy

= Disabled
W = WP Mode, . = ACp off
= Disabled, M = Mixed, - = N/A
The command symrdf list -sid 81 cascaded lists the cascaded SRDF devices
configured on Symmetrix 81. The output lists two devices BD and BE.
Note that these two devices belong to groups 19 and 79 simultaneously. The way to identify the
personality of the devices in a particular relationship is to read the flags under the T column.
The entry S..2. in the line reporting on RDF group 19 indicates that the RDF devices in Symmetrix 81
in group 19 are running in synchronous mode and are operating as R2 devices. The entry A..1.
indicates that the devices are running in asynchronous mode as R1 devices in group 79.
-8
Permitted Modes for Disk Based R21s

R1 to R21
R21 to R2
Adaptive Copy Disk
Asynchronous
Adaptive Copy Disk
Adaptive Copy Disk
Adaptive Copy Write Pending
Asynchronous
Adaptive Copy Disk
Synchronous
Asynchronous
Synchronous
Adaptive Copy Disk
Asynchronous
Adaptive Copy Disk
These are the SRDF modes permitted in cascaded SRDF when the R21 is a disk based device. While
the source site can run any mode of SRDF, the R21 site is limited to asynchronous or adaptive copy
disk mode. If the source is running in asynchronous mode, the R21 cannot be running in asynchronous
mode.
-9
Constraints for Disk Based R21 Devices

y Cascaded SRDF device not supported by ESCON RA
y The R21 device must belong to two RDF groups (like a
concurrent RDF group)
y R21 cannot be configured on a BCV device
y Thin Devices cannot be R21 devices
y An R21 device cannot be paired with an R21 device
R1->R21->R21->R2 is not allowed
Please take a moment to review the restrictions that apply to cascaded SRDF devices. The restrictions
shown here pertain to disk based R21 devices. Additional restrictions apply to diskless R21 devices.
These are covered in the SRDF/EDP section.
- 10
SRDF/EDP Overview
y Extended Distance Protection (EDP) at lower cost using
Cascaded SRDF
y Diskless R21 devices at synchronous target provide data
pass through to the out-of region site
y The R21 requires Enginuity 5874 with Solutions Enabler
v7.0 or higher
y Can be better fit when Site B not desired as DR site
Site B
Site A
Site C
SRDF/A
SRDF/S
WAN
R1
R21
R2
Cache-only R21 devices

Production Site
Pass Thru Site
Out of Region Site

Available with Enginuity 5874, SRDF/EDP is a lower cost solution to achieve no data loss at an outof-region site. Cascaded SRDF mode of operation is used as the building block for this solution. By
using diskless R21 device in the intermediate site, the intermediate site provides data pass through to
the out-of-region site.
SRDF/EDP supports SRDF/Star for continuous remote data replication protection. In the event that the
intermediate site goes offline due to a disaster, SRDF/Star permits the production and out-of-region
sites to establish an asynchronous link with minimal resynchronization between sites A and C.
- 11
Rules for SRDF/EDP

y Diskless R21 devices cannot be mapped to a host
y Only supported on Gig-E or Fiber RAs
y Cannot form an RDF pair with a DLDEV or a TDEV
y Cannot participate in non-RDF replication viz.
TimeFinder/Snap
TimeFinder/Clone
Open Replicator
y Create using binfile or Config Manager, e.g.

# symconfigure sid 80 commit cmd create dev count=10, size=17250,
emulation=fba, config=DLDEV, dynamic_capability=dyn_rdf;
A diskless R21 device can offer a cache buffer external to the source Symmetrix. This buffer makes it
possible to create a zero data loss SRDF/A solution as contrasted with traditional SRDF/A which offers
an RPO of seconds to minutes.
A diskless device cannot be mapped to the host. Therefore, no host will be able to directly access a
diskless device for read or write. Diskless RDF devices are only supported on GIGE and Fiber RAs All
Symmetrix replication technologies other than RDF (TimeFinder/Snap, TimeFinder/Clone, and Open
Replicator) will not work with diskless devices as either the source or the target of the operation.
Creation of the diskless devices can be done by the Customer Engineer via the bin file or by using
Config Manager. A sample of the syntax is shown on this page.
- 12
Permitted Modes for Diskless R21s

R1 to R21
R21 to R2
Adaptive Copy Disk
Asynchronous
Adaptive Copy Disk
Asynchronous
Synchronous
Asynchronous
Synchronous
These are the SRDF modes permitted in cascaded SRDF when the R21 is a diskless device. While the
source site can run any mode of SRDF, the R21 site is limited to asynchronous or adaptive copy write
pending mode. If the source is running in asynchronous mode, the R21 cannot be running in
asynchronous mode.
- 13
Sequence of Synchronization Matters with SRDF/EDP

DMX800SUN1/ symrdf establish -file pairs -sid 80 -rdfg 20 -nop
An RDF 'Incremental Establish' operation execution is in progress for device
file 'pairs'. Please wait...
The other pair of the R21 is not in a valid RDF state for this operation.
be performed
Operation can not
SID: 194900180
DMX800SUN1/ symrdf establish -file pairs -sid 81 -rdfg 80 nop
The RDF 'Incremental Establish' operation successfully initiated for device

R1
file 'pairs'.
RDFG # 20
DMX800SUN1/ symrdf establish -file pairs -sid 80 -rdfg 20 -nop
The RDF 'Incremental Establish' operation successfully initiated for device

file 'pairs'.
R21:20
R21:80
R21:20
R21:80
??
??
??
??
WD
RW
WD
RW
RW
RW
RW
RW
S..2.
A..1.
S..2.
A..1.
0
0
0
0
0
0
0
0
WD
RW
WD
RW
RW
WD
RW
WD
SID: 194900181
R21
DMX800SUN2/usr/sengupta/Star/Pairs> symrdf list -sid 81 -cascaded
00C5 00C5
00C5
00C6 00C6
00C6
RDFG # 20
Synchronized
Consistent
Synchronized
Consistent
RDFG # 80
RDFG # 80
SID: 194900182
R2
The diagram shows a configuration where the R1 devices in Symmetrix 80 are paired with diskless
R21s in Symmetrix 81. The RDF group connecting the devices is number 20. The same devices are
acting as R1 devices for R2 devices in Symmetrix 82. The group to which these devices belong is
number 80. The pair state for both sets of relationships is Suspended.
The order in which the links are brought up is significant when using SRDF/EDP. Since the diskless
devices cannot store data, the link between the R21 and the R2 has to be brought up first. Here an
attempt to synchronize the R1 to R21 device pair before synchronizing the R21 to R2 device pair fails.
Performing the synchronization by synchronizing the R21 to R2 pair first and the R1 to R21 pair
second succeeds.
- 14
R22 Devices
y A form of concurrent RDF device that permits an R2 to
maintain two RDF relationships
y Primarily intended for use in SRDF/Star
Reduces the number of steps during Star reconfiguration after a
failure
Makes Star more resilient
y Cascaded RDF configuration can be swapped after

primary site failure without affecting the source to
synchronous target relationship
Released with 5874 R22 devices are a form of concurrent RDF device. They have two R2
relationships, only one of which can be active at a time. The main purpose of R22 devices is their use
in SRDF/Star configurations. They make Star more resilient and easier to reconfigure after a failure.
They can also be used in cascaded SRDF configurations when the R1 site fails and production is
moved to the remote site.
All Star examples later in this course use R22 devices.
- 15
R22s at Asynchronous Site

DMX800SUN1/usr/sengupta/Star/Pairs> symrdf list -conc -sid 81
Local Device View
---------------------------------------------------------------------------STATUS
MODES
RDF S T A T E S
Sym
RDF
--------- ----- R1 Inv
R2 Inv ---------------------Dev RDev Typ:G
---- ---- -------- --------- ----- ------- ------- --- ---- ------------- SID: 194900180
00BD 00BD
00BD
00BE 00BE
00BE
R21:19
R21:79
R21:19
R21:79
RW
RW
RW
RW
WD
RW
WD
RW
RW
NR
RW
NR
S..2.
C.D1.
S..2.
C.D1.
0
0
0
0
0
17250
0
17250
WD
RW
WD
RW
RW
WD
RW
WD
Synchronized
Suspended
Synchronized
Suspended
# 49
R11
RDFG # 19
RDFG # 19
DMX800SUN1/usr/sengupta/Star/Pairs> symrdf list -conc -sid 82

SID: 194900181
Local Device View
---------------------------------------------------------------------------R21
STATUS
MODES
RDF S T A T E S
Sym
RDF
--------- ----- R1 Inv
R2 Inv ---------------------RDFG # 79
Dev RDev Typ:G
---- ---- -------- --------- ----- ------- ------- --- ---- -------------
RDFG # 79
00BD 00BD
00BD
00BE 00BE
00BE
R2:49
R2:79
R2:49
R2:79
RW
RW
RW
RW
WD
WD
WD
WD
RW
NR
RW
NR
A..2.
C.D2.
A..2.
C.D2.
0
0
0
0
0
0
0
0
WD
WD
WD
WD
RW
RW
RW
RW
Consistent
Suspended
Consistent
Suspended
SID: 194900182
R22 # 49
This is a setup that is intended to support SRDF/Star. The two symrdf list commands show that
devices BD and BE belong to group 19 and 79 on Symmetrix 81, 49 and 79 in Symmetrix 82.
- 16
Module Summary
Key points covered in this module:
y SRDF three data center solutions
y Cascaded SRDF and SRDF/EDP
These are the key points covered in this module. Please take a moment to review them.
- 17
Module 2: Underlying Technologies for SRDF/Star

y Describe SRDF technologies that support Star:
SRDF/Synchronous and SRDF/Asynchronous
Synchronous SRDF consistency groups managed by the SRDF
daemon
Cycle switching in an SRDF/A Multi-session consistency (MSC)
environment
MSC cleanup
Special use of SDDF sessions in tracking changes
Half delete, half swap and special pair creation commands
- 18
SRDF/S and SRDF/A Basics

Upon completion of this lesson, you will be able to:
y Describe the working of SRDF/S
y Describe the working of single session SRDF/S
The objectives for this lesson are shown here. Please take a moment to read them.
- 19
SRDF/S Architecture
SRDF/S links
2
Source
Target
n I/O write received from host/server into source cache

o I/O is transmitted to target cache
p Receipt acknowledgment is provided by target back to cache of source
q Ending status is presented to host/server
Synchronous SRDF mode is primarily used in campus environments. In this mode, Symmetrix
maintains a real-time mirror image of the data from remotely mirrored volumes.
Data on the source (R1) volumes and target (R2) volumes are always fully synchronized. Data
movement is at the block level.
The sequence of operations is:
y An I/O write is received from the host/server into the source cache.
y The I/O is transmitted to the target cache.
y A receipt acknowledgment is provided by the target back to the cache of the source.
y An ending status is presented to the host/server.
Synchronous mode is one of three modes in which SRDF can operate. The other modes are
Asynchronous and Adaptive copy. Unlike competitive products, SRDF can be dynamically switched to
operate in another mode without interrupting host I/O.
Like all synchronous replication solutions, synchronous SRDF has architectural limitations that must
be understood:
y The maximum distance over which Synchronous SRDF can be used is limited by application
timeouts and speed-of-light issues.
y Link bandwidth must be sized for peak workload at all times.
- 20
SRDF/A Architecture
Capture
Transmit
Receive
Apply
Repeat
CAPTURE (N)
Collects
application write
I/O
APPLY (N-2)
Once Receive is
complete, data is
applied to disk
TRANSMIT (N-1)
Sends final set of
writes to target
RECEIVE (N-1)
Receives writes
from Transmit
Delta Set
Source
Target
y SRDF/A performs Write Folding, which only sends

Transmits of the final writes from the Capture Delta Set
SRDF/As architecture delivers replication over extended distances with no performance impact.
SRDF/A uses Delta Sets to maintain a group of writes over a short period of time. Delta Sets are
discrete buckets of data that reside in different sections of the Symmetrix cache. Starting at 1, each
Delta Set is assigned a numerical value that is one more than the preceding one.
There are four types of Delta Sets to manage the data flow process.
The Capture Delta Set in the source Symmetrix (numbered N in this example), captures (in cache) all
incoming writes to the source volumes in the SRDF/A group.
The Transmit Delta Set in the source Symmetrix (numbered N-1 in this example), contains data from
the immediately preceding Delta Set. This data is being transferred to the remote Symmetrix.
The Receive Delta Set in the target system is in the process of receiving data from the transmit Delta
Set N-1.
The target Symmetrix contains an older Delta Set, numbered N-2, called the Apply Delta Set. Data
from the Apply Delta set is being assigned to the appropriate cache slots ready for de-staging to disk.
The data in the Apply Delta set is guaranteed to be consistent and restartable should there be a failure
of the source Symmetrix.
- 21
Necessary Conditions for a Cycle Switch

y Minimum Cycle Timer Expired
User definable for each RDF group
Default value is 30 secs.
y Transmit Delta Set completely transferred

Dependent on write workload and link bandwidth
Link overload can slow down transfer and delay cycle switch
y Apply Delta set completely applied

Depends on amount of data to be applied and disk infrastructure
Slower disks and hot volumes can slow down apply cycle
The Symmetrix performs a cycle switch once data in the N-1 set is completely received, data in the N2 set is completely applied, and the 30 second minimum cycle time elapsed. During the cycle switch, a
new delta set (N+1) becomes the capture set, N is promoted to the transmit/receive set and N-1
becomes the apply Delta Set.
The minimum cycle timer can be set on a per RDF group basis by the user through Symmetrix
Configuration component. Shorter minimum cycle timer settings increase bandwidth requirements.
The time that the transmit data needs to go across depends on the volume of writes and the link
bandwidth. Overloading of the link can cause SRDF/A cycles to be extended beyond the minimum
cycle time.
The speed of the Apply cycle depends on the volume of data that needs to be applied. Slower disks and
hot volumes can slow down the Apply cycle and cause a delay in cycle switching. This is why from a
performance engineering viewpoint, it is always a good idea to use balanced Symmetrix configurations
for SRDF/A. This means that the infrastructure of the target Symmetrix should be at least as fast as the
infrastructure of the source Symmetrix so as not to create a bottleneck during the Apply cycle.
- 22
Dependent Writes Ensure Data Consistency

y Dependent write logic:
If A is a predecessor and B is a dependent write:
Any I/O B that arrives after I/O A has completed, must be dependent
on A
y SRDF/A ensures that:

A and B are in the same Delta Set
or
B is in later Delta Set
y These Delta Sets (cycles) of I/Os, not the I/Os

themselves, are ordered by SRDF/A
y Symmetrix ensures that dependent write relationships are
honored during Delta Set switch or Write Folding
Database application consistency forms the backbone of SRDF/A design. Inherently, all database
applications are consistent, which means that a database application does not issue a dependent write
unless a predecessor write is completed. For example, a DBMS does not issue a dependent data write
unless a predecessor write to the log was successfully completed. EMCs consistency technology
honors this dependent write logic. By honoring write ordering at the time of the Delta Set switch,
SRDF/A guarantees dependent write consistency.
- 23
Synchronous SRDF Consistency Groups

y Describe SRDF/S Consistency groups and how they are
managed using the RDF daemon and RDF-ECA
The objective for this lesson is shown here. Please take a moment to read it.
- 24
SRDF Daemon (storrdfd)

y System process on Unix and Windows
y Interacts with:
Base Daemon (storapid)
Enginuity Consistency Assist (RDF-ECA)
Group Name Services (GNS) daemon
y Maintains Consistency
On SRDF/S composite groups with consistency enabled
Performs cycle switching in SRDF/A when MSC is active
Performs MSC Cleanup in SRDF/A
y Cooperates with daemons running on other hosts
Storrdfd (pronounced store R-D-F-D) is a process that runs as a daemon on Unix systems and as a
service in Windows. It is referred to as the SRDF daemon and uses the base daemon for all its
communications with the Symmetrix, such as the issuing of syscalls.
In an SRDF/S environment, the RDF daemon cooperates with RDF-ECA to maintain consistency for
composite groups.
If GNS is enabled on the host, the SRDF daemon interacts with the GNS daemon to acquire composite
group definitions. Otherwise, it gets definitions from the SYMAPI database.
In an SRDF/A environment, the SRDF daemon is responsible for cycle switching when Multi-Session
Consistency is enabled.
The RDF daemon is designed for full cooperation with other RDF daemons. Any task for which the
daemon is responsible, such as an MSC cycle switch, can be initiated by one RDF daemon and
completed by another RDF daemon. At no time is there a single point of failure if there are two or
more RDF daemons monitoring the same processes.
It is therefore advisable to have more than one host running the SRDF daemon in an environment
where the daemons services are necessary. Such a configuration provides redundancy in case one of
the daemons stops unexpectedly.
- 25
Enginuity Consistency Assist (ECA)

y ECA is a feature that works inside the Symmetrix array
y Stalls write I/Os to a user-defined list of Symmetrix
devices prior to splitting a source volume and its replica
y Used for:
Open Replicator consistent activation
TimeFinder consistency
TF/Mirror consistent split
TF/Clone consistent activation
TF/Snap consistent activation
Enginuity Consistency Assist is a feature introduced with Enginuity 5x67. It stalls write I/O to a userprovided list of devices prior to a consistent TimeFinder split or a consistent activation of Open
Replicator, TimeFinder Clone or TimeFinder Snap. Reads are allowed to continue during this time.
Once the split or activation is complete, I/O is allowed to flow again. The stalling of write I/Os
guarantee that the copy of data being split or activated is dependent write consistent.
- 26
RDF-ECA
y Used with SRDF/S to hold write I/Os to a consistency
group until all relevant links are suspended
y Interacts with RDF daemons on one or more control
hosts to manage consistency
y Can replace PowerPath and MF Consistency Group Task
to manage consistency on FBA and CKD volumes
y Supports synchronous consistency in concurrent and
cascaded RDF composite groups
RDF ECA is an extension to ECA released in Enginuity 71. It interacts with the RDF daemon to
manage consistency of a user-defined RDF consistency group. RDF ECA can manage consistency for
CKD and FBA devices.
- 27
ECA Window
y ECA is activated by Enginuity when:
Host issues a TimeFinder consistent split or activate command
Host issues an Open Replicator consistent activation command
An SRDF/S I/O directed at a consistency group fails to complete on the
remote side
y At activation, a 30 second timer (ECA Window) starts

y While ECA window is open, Enginuity requests host HBAs to retry
write I/Os to affected devices
y When the desired action (split/activate/suspend) completes, the
ECA window is closed and I/O can flow again
y If the action fails to complete within 30 seconds, I/O is allowed to
flow again, but an error message is logged
In the context of TimeFinder, ECA Window is the name given to a 30 second timer that starts when a
consistent split or consistent activation is initiated.
In the context of RDF-ECA, the 30 second timer is started by the Symmetrix after it determines that a
write I/O to a device in a consistency group cannot complete on the remote array.
Once the ECA timer starts, Enginuity does not accept write I/Os to the affected devices. Instead, it asks
the host HBAs to retry the I/O. When the required action completes, the ECA window is closed and
I/O is permitted to flow again.
If, for some unexpected reason, the required action does not complete before 30 seconds are up,
Enginuity closes the ECA window. It allows I/O to flow again while recording an error message in the
host-based log file.
- 28
RDF Daemon and SRDF/S Consistency - 1

CG
Host I/O
Capture
R1
N+1
R1
R2Apply
N-1
R2
SRDF LINKS
R2
R1
Transmit
N R1
RDF
daemon
monitoring
Host I/O
Receive
NR2
R1
Capture
M+1 R1
R1
Transmit
M R1
R2Apply
M-1R2
SRDF LINKS
R2
Receive
M R2
y A link failure causes Symmetrix to pauses writes to the

CG devices in that Symmetrix
When synchronous RDF consistency is enabled for a consistency group, the RDF daemon polls the
Symmetrix every second to monitor the health of the con-group.
Assume that the links connecting one of the Symmetrix pairs fail. When the source Symmetrix fails to
complete writes to the remote devices, it starts the ECA timer window. All subsequent writes to the
devices belonging to the composite group in that Symmetrix are turned back with retry requests issued
to the host HBA. During this time no dependent writes are issued by the application, because the host
database application has not been notified of the completion of the predecessor write.
- 29

CG
R2
R1
R1
Host I/O
R2
SRDF LINKS
R2
R1
R2
R1
Daemon
suspends
RDF links
R2
R1
R2
R1
Host I/O
SRDF LINKS
R1
R1
R2
R2
y Next, the RDF daemon requests logical link suspension

of the remaining devices
When the RDF daemon recognizes that one of the Symmetrix pairs have lost connectivity, it requests
the remaining Symmetrix arrays to open an ECA window which will hold incoming writes as well.
Once all ECA windows are open and write I/O is stopped to the entire consistency group, the daemon
logically suspends the remaining communication links.
- 30

CG
Host I/O
R2
R1
R1
R2
SRDF LINKS
R2
R1
RDF
daemon
monitoring
Host I/O
R2
R1
R2
R1
R2
R1
SRDF LINKS
R1
R1
R2
R2
y leaving the R2 devices dependent-write consistent

Once all the links have been suspended, the ECA windows are closed and the writes to the local arrays
are allowed to complete. Note that writes to the first group of devices were held as soon as the links
failed and the remote writes did not complete. Thus, if the host was running a database application, no
dependent write could have been issued by the host application between the time that links on the first
Symmetrix failed and I/O flow was restored by the RDF daemon to all devices. This makes the target
site data consistent.
- 31
MSC Cleanup
y Describe MSC Cleanup
y Describe MSC Cycle Switching
- 32
MSC Cleanup After an SRDF/A Trip

y A trip can occur at different times in the SRDF/A cycle
y From the viewpoint of a single R2 Symmetrix, there are
only 2 possible states for a receive delta set:
The receive delta set is incomplete
Symmetrix knows it is incomplete, so it is automatically discarded
No MSC Cleanup needed
The receive delta set is complete

Symmetrix marks the session as Needing MSC Cleanup
Disposition of delta set depends on status of other R2 Symmetrix arrays
in the same SRDF/A MSC protected CG group
If all are complete, then its all right to commit the delta set
If all are not complete, then delta set must be discarded
The third and final function of the RDF daemon is to manage SRDF/A multi-session consistency in the
event of a failure of communication between source and target.
When there are multiple Symmetrix arrays or SRDF groups participating in a multi-session consistency
group, the Symmetrix sets the MSC cleanup required flag if the receive Delta Set was completely
received at the time the failure occurred.
A single Symmetrix, with the SRDF/A MSC flag set, cannot determine the correct action to take for a
completely received Delta Set without information from other Symmetrix arrays in the SRDF/A MSC
protected consistency group.
MSC Cleanup can be invoked by any of the following methods:
y The RDF daemon performs MSC cleanup automatically if it can communicate with the target
arrays.
y The API/CLI automatically performs MSC cleanup during the processing of any RDF control
command.
y User can manually execute MSC cleanup through CLI.
The MSC Cleanup Needed status is exported to user-visible displays such as query output. MSC
Cleanup commits receive cycle data in case of failure during cycle switch instead of discarding it
unnecessarily.
- 33
RDF Daemon and MSC Cleanup
Host I/O
RDF
daemon
monitoring
Host I/O
Capture
N+1
Transmit
N
CG: MSC
SRDF LINKS
Apply
N-1
Receive
Delta Set
Incomplete
Receive
N
?
Capture
M+1
N+1
Transmit
M
N
Apply
M-1
N-1
SRDF LINKS
Receive
Delta Set
Complete
Receive
M
N
y MSC Cleanup is needed in the bottom Symmetrix only

Assume that the links between the source and target arrays have tripped. The Receive Delta set in the
top array is incomplete while the Receive delta set in the bottom array is complete.
In the top case, because the Receive Delta set is incomplete, the only valid choice for the Symmetrix is
to discard it because the dependent write principle only works for complete Delta Sets.
For the bottom case, the Receive Delta set is complete. Since this is an MSC protected group, the
Symmetrix cannot decide what to do on its own.
y If all Receive Delta sets were complete, it would be correct to Apply the data.
y However, if any of the Receive Delta sets are incomplete, then the data must be discarded.
y The Symmetrix sets the MSC Cleanup Needed flag.
In the example displayed on this slide, MSC cleanup is undertaken by one of the three methods
mentioned earlier:
y The RDF daemon;
y Any RDF control command issued by the API/CLI;
y The user issues an explicit symstar cleanup command.
- 34
MSC Cleanup Logic

y All SRDF/A MSC sessions in the CG are inventoried
Is the MSC Cleanup Needed flag set?
What are the Apply and Receive Delta set cycle numbers?
y A MSC cleanup logic decides what to do (4 possibilities)

# R2 Symm A
R2 Symm B
No Cleanup
Needed
No Cleanup
Needed
A=N
MSC Cleanup
MSC Cleanup Needed Symms
A=N
Needed
must discard
MSC Cleanup
Needed
A=N
MSC Cleanup
A=N All complete, all are committed
Needed
No Cleanup
Needed
Action
-
All discarded, no MSC Cleanup
No Cleanup
A=N MSC Cleanup A=N-1 Failure occurred during a cycle
Needed
R=N+1
Needed
R=N switch, all are committed
Once the RDF daemon on the source side notices a trip event, it runs the MSC cleanup logic on the
target arrays if it can communicate with them. The legend A=N means the Apply Delta set is numbered
N. Similarly, R=N+1 means that the number of the Receive Delta Set is N+1. Though the table shown
here uses two Symmetrix units, the logic works for larger numbers of arrays.
1. In this case, none of the SRDF/A sessions have the MSC Cleanup Needed flag set. This occurs
when all the Receive Delta sets were incomplete and all were automatically discarded. There is no
Cleanup action to take and it is not invoked automatically.
2. Only some Symmetrix arrays have the MSC Cleanup Needed flag raised. Also, ALL Apply
delta set numbers are the same. This means that some Symmetrixes had to discard their incomplete
Receive Delta Sets. Consequently, all the Symmetrixes needing MSC Cleanup must discard their
completely received Delta Sets.
3. All Symmetrixes have the MSC Cleanup Needed flag raised. In this case, ALL Apply Delta
Set numbers must be the same. This indicates that all Receive Delta Sets are complete and all the
Receive Delta Sets can be applied.
4. Only some Symmetrix units have their flag raised. Also, one or more Symmetrixes with the flag
raised has a Receive Delta Set number that matches the Apply cycle number for a Symmetrix which
discarded its incomplete Receive cycle. This indicates a failure in the middle of a cycle switch. So, all
the completely received Receive Delta Sets in the Symmetrix arrays with the flag raised are applied.
- 35
RDF Daemon and MSC Cycle Switching

Host I/O
RDF
daemon
monitoring
Host I/O
Capture
N+1
N
Transmit
N-1
N
Capture
M+1
N
Transmit
N-1
M
CG: MSC
SRDF LINKS
Time to perform
cycle switch!
SRDF LINKS
Apply
N-1
N-2
Receive
N-1
N
Apply
M-1
N-2
Receive
N-1
M
y Daemon monitors RDF devices that belong to MSC group

A second function of the RDF Daemon is to maintain Multi-Session Consistency (MSC) in an SRDF/A
environment. MSC is important when consistency must be maintained between multiple production
applications running on multiple SRDF groups. The example on this slide illustrates how the RDF
daemon maintains consistency while cycle switching during normal MSC operations.
The RDF Daemon (or daemons) monitors all groups and manages cycle switching for all R1
Symmetrix arrays whose sessions are managed by MSC.
When the minimum cycle time, which by default is set to 30 seconds, has elapsed:
y The RDF Daemon verifies that each R1 Symmetrix array has completed transferring the Transmit
Delta Set to the R2s and
y that each R2 Symmetrix has completed applying the apply delta sets.
Until the conditions above are satisfied for each RDF group in each Symmetrix array, the cycle
switching is not initiated and the present cycle gets elongated.
Once all RDF groups indicate their readiness to switch, the RDF daemon briefly holds writes to the
source arrays and switches the cycles first on the source and then on the target arrays. The cycle
switching is an asynchronous process so all the source and target boxes do not switch in the same
instant, they switch one after the other. Host writes are allowed to flow into the source array as soon as
the source array has switched, whereas transmit data is allowed to flow into the target array as soon as
the target array has switched.
- 36
Special SRDF and SDDF Features for SRDF/Star

y Describe SDDF Features in support of SRDF/Star
y Describe SRDF Features in support of Star
- 37
Symmetrix Differential Data Facility

y Each Symmetrix logical volume can support up to 16
sessions
y SDDF sessions comprise bitmaps that flip a bit for every
track that changed since the session was initiated
y SDDF sessions are used to monitor changes in:
Clones
Snaps
BCVs
Change Tracker
Open Replicator
y Was enhanced to support SRDF/Star

Each Symmetrix logical volume is allotted a quota of 16 SDDF sessions. These sessions allow the
Symmetrix to track changes using bitmaps, which flip from a zero to a one whenever a monitored track
changes.
SDDF sessions are used to monitor changes in BCVs, Clones, Snaps, Change Tracker, Open
Replicator.
SDDF functionality was enhanced for SRDF/Star to enable differential resynchronization between two
target sites. Once Star is enabled, two sessions are created and activated at the Synchronous target site,
and one SDDF session is created at the Asynchronous target site.
- 38
SDDF Session Usage in Concurrent Star
Site B 2 Active SDDF Sessions per each device

1001011001001
R2
0001011100100
SRDF/S
Passive Link
R11
SRDF/A
Site A RDF daemon from control

host manages SDDF sessions
000000000000
R2
Site C 1 Inactive SDDF Session per each device
When Star Protection is enabled, two SDDF sessions are created at site B and one SDDF bitmap is
created at site C. The bitmaps at site B are always active during normal Star operation. They are
alternately marked and cleared after every two or more SRDF/A MSC cycles elapse between sites A
and C.
The bitmap at site C stays inactive during normal Star operation.
- 39
Concurrent STAR - When Site A Fails

2 SDDF bitmaps
1001011001001
R2
0001011100100
SRDF/S
IOR
Passive Link
R11
SRDF/A
1 SDDF bitmap
000000000000
R2
y SDDF sessions at Site B frozen, since data flow to B

stops
y Inclusive OR of 2 SDDF bitmaps at B used to resolve
track differences between B and C
If the primary site fails, data transmission to both sites stop simultaneously.
Under these circumstances, the data at Synchronous Target B is more recent than the data at
Asynchronous target C.
In the course of recovery, an inclusive OR of the two bitmaps is performed at site B. This operation
marks all tracks updated in the current bitmap and all tracks updated in the previous bitmap as owed to
site C. Since the bitmap initialization at site B occurs every two plus cycles, it is possible that the
inclusive OR will result in more than the minimum required tracks being marked as invalid. This is not
a problem since by copying a few more tracks than needed, we err on the side of caution.
MSC cleanup needs to be run at site C if needed.
If a business decision is made to run production at site B, the RDF devices at site B are turned into R1
volumes and paired with corresponding R2 volumes at site C. An RDF establish now copies the invalid
tracks from site B to site C.
If the decision is to run at site C, the devices at B are turned into R2s and those at site C into R1s. An
RDF restore updates the C site with tracks owed by B to C.
- 40
Concurrent STAR Rolling Disaster

2 SDDF bitmaps
First Failure
1001011001001
R2
0001011100100
R11
IOR
Passive Link
Second Failure
1 SDDF bitmap
IOR
110011001000
R2
y When link to Site B fails

SDDF bitmaps at Site B are frozen since data flow to B stops
SDDF bitmap and Token Counter at C (not shown in diagram) activated at
SRDF/A cycle boundary
Token counter at Site C counts elapsed cycles since activation
y After failure of site A inclusive OR of both SDDF bitmaps at B and

bitmap at C used to resolve track differences between B and C
The failure described here is often referred to as a rolling disaster, where the first failure is succeeded
by a second one. Here the first fault disrupts the links between A and B. This causes the synchronous
consistency group to trip, leaving the data at site B consistent. The SDDF sessions at site B are frozen
for later conversion to invalid tracks. Data processing continues at site A, and Site C continues to get
updated.
When the synchronous link fails, the SDDF session at site C is activated on a cycle boundary just prior
to the next cycle switch. This SDDF session records new writes coming into site C. Additionally, a
token counter is started at C. It starts counting the number of cycle switches after activation.
Shortly after the first failure, the primary site fails, causing data transmission to stop at site C. If the
second failure occurs more than two SRDF/A cycle switches after the first failure (as recorded by the
token counter), site C will be more current than site B.
A Star query after the final primary site failure indicates which side is more current.
An inclusive OR between the two SDDF bitmaps at site B and an inclusive OR between the resulting
bitmap and the bitmap at site C, creates the invalid track table that must be resolved when the two sides
are synchronized.
If data at site C is more current, the synchronization should cause tracks to flow from C to B. If the
token counter indicates that B is more current than C, new data flows from B to C.
- 41
SDDF Session Usage in Cascaded Star

Site B
R2
1001011001001
SRDF/S
0001011100100
R1
Passive Link
SRDF/A
Site A RDF daemon manages

2 Active SDDF sessions per each device
000000000000
R2
Site C 1 Inactive SDDF Session per each device
When Star Protection is enabled, two SDDF sessions are created at site A and one SDDF bitmap is
created at site C. The bitmaps at site A are always active during normal Star operation. They are
alternately marked and cleared after every two or more SRDF/A MSC cycles elapse between sites A
and C.
The bitmap at site C stays inactive during normal Star operation.
- 42
Cascaded STAR - When Site B Fails

R21
SRDF/S
SRDF/A
R1
Passive Link
2 SDDF bitmaps
1 SDDF bitmap
1001011001001
0001011100100
000000000000
IOR
R2
If sites A and C are reconfigured in concurrent mode:

y Inclusive OR of 2 SDDF bitmaps at A used to resolve
track differences between A and C at reconfiguration time
The failure of site B in Cascaded Star is a major failure, since reconfiguration from cascaded to
concurrent Star must be undertaken in order to provide remote data protection. When the link between
A and C is activated, the SDDF bitmaps at site A are used to determine the invalid tracks that must be
moved from A to C.
- 43
Cascaded STAR - When Site A Fails

R21
SRDF/S
SRDF/A
R1
Passive Link
2 SDDF bitmaps
1 SDDF bitmap
1001011001001
0001011100100
000000000000
R2
y SDDF sessions at Site A frozen

y Since B and C already have a track table relationship
there is no need for SDDF sessions
If the workload site fails in a cascaded star environment and the decision is made to switch production
to either target site, the SDDF sessions are not needed because the differences between the B and C
sites are recorded in the track tables.
- 44
Half Delete SRDF Pair
R1
R2
Normal Configuration Suspended State
2-Way
Mir
R1
After half delete
y Deletes half of the RDF pair relationship

y Can be used to dissolve RDF relationships if partner
device is unavailable
y RDF Pair relationship shows up as half
A half delete operation can be executed on a dynamic RDF pair using SYMCLI commands. After the
half delete command is executed, the device in the Symmetrix on the left turns into a regular device,
and the one on the right retains its identity. A SYMCLI query shows it as a half pair. The SRDF pair
state must be suspended, failed over, split or partitioned before a half delete can be performed.
The half delete of SRDF pairs is used by SRDF/Star in a disaster situation.
The command is also available for general use, but only in special cases. If an existing RDF
relationship is rendered null and void by the physical removal of one of the Symmetrix arrays, without
the termination of the SRDF relationships, the half delete command can be used to dissolve remaining
RDF volumes.
Do not use the half delete command when both arrays in an RDF relationship have visibility to each
other.
- 45
Half Swap
y Changes personality of one
side of an RDF relationship
y After a half swap
the RDF pair configuration for the
device shows up as Duplicate
BEFORE HALF SWAP

R1
R2
AFTER HALF SWAP

Duplicate Configuration
R1
R1
OR
the RDF pair configuration shows up
as normal if one of the pair state
was Duplicate
BEFORE HALF SWAP

R1and R2 are in duplicate pair state
R1
R1
AFTER HALF SWAP

R1
R2
The half swap operation changes the personality of one SRDF volume, irrespective of whether the
other RDF volume is visible or not.
There are two uses for the half swap command while reconfiguring devices during a Star action:
1. Sometimes during a site reconfiguration an R2 device is half swapped so it becomes an R1 device.
This makes the pair relationship duplicate since there are now two R1 devices in the pair pointing at
each other.
2. At other times in the course of a site reconfiguration a half swap converts a duplicate device pair
into a normal device pair by turning one member of the duplicate pair from an R1 to an R2.
- 46
Special Create Pair Options

Note: These commands are not available to users
y Two forms of RDF pair creation used only in SRDF/Star
y createpair with nocopy option
Creates a dynamic RDF pair without copying data
Declares both sides equal without any tracks being moved
Used during a planned switch from one workload site to another
y createpair with refresh option

Uses SDDF sessions at synchronous and asynchronous targets to
perform an incremental resynchronization
The two functions described on this slide were created for the purpose of Star and are not available to
users.
Creation of a dynamic RDF pair without copying data is an action that risks data corruption if it was
not 100% certain that the devices in the pair did, in fact, contain identical data. This function is used in
the case of a planned workload site switch when applications are halted and all three sites are made
equal prior to a switch.
Creation of a dynamic RDF pair with an incremental refresh is only possible based on the SDDF
bitmaps at the synchronous and asynchronous target sites. This is the key behind SRDF/Stars ability to
switch workload sites without a full refresh.
- 47
Module Summary
y SRDF/Synchronous and SRDF/Asynchronous
y Synchronous SRDF consistency groups managed by the
SRDF daemon
y Cycle switching in an SRDF/A Multi-session consistency
(MSC) environment
y MSC cleanup
y Special use of SDDF sessions in tracking changes
y Half delete, half swap and special pair creation
commands
- 48
Module 2 : SRDF/Star
y Give an overview of Star Configurations
y Describe the operation of SRDF/Star using concurrent
SRDF
y Describe a Star configuration using cascaded SRDF
- 49
Overview of Star Configurations

y List SRDF/Star Configurations using Concurrent and
Cascaded SRDF
y Describe failure conditions and how they affect
SRDF/Star operation
- 50
SRDF/Star Overview
y Integration of EMC offered three-site SRDF/S and
SRDF/A solutions
Concurrent and cascaded SRDF modes of operation
y Maintains remote data protection if primary Workload Site

becomes inoperable
Changed-data resynchronization between remaining SRDF/S and
SRDF/A Sites allows for restart with no data loss at either target
EMC SRDF/Star is a three-site disaster-restart solution that can enable resumption of SRDF/A with no
data loss between two remaining sites, providing continued remote-data replication and preserving
disaster-restart capabilities. It offers a combination of continuous protection, changed-data
resynchronization, and enterprise consistency between two remaining sites in the event of the
Workload Site going offline due to a site failure.
As more businesses require solutions to provide the highest levels of disaster restart capabilities,
SRDF/Star is the industrys first solution to enable organizations to satisfy those requirements.
- 51
The History of SRDF/Star

y 2001: Special version of SRDF/AR for a US company
y 2003: SRDF/A and concurrent SRDF and SRDF/A released
y 2003: A European company in a similar business visited the
American company
After their visit, the Europeans met with EMC Engineering and requested
features that led to concurrent Star
y 2004: Release of concurrent SRDF/Star on Mainframes

y 2005: Release of concurrent SRDF/Star on Open Systems
y 2008: Release of Cascaded SRDF/Star
y 2009: Release of cascaded SRDF/Star with EDP
In the year 2001, EMC built a special version of a multi-hop Mainframe SRDF/AR for a New York
based financial services company. This version of Mainframe SRDF/AR maintained a differential
relationship between the source (site A) and remote site (site C). If the bunker site (site B) failed, a full
resynchronization between A and C was no longer necessary. By virtue of using DeltaMark (SDDF)
sessions, an incremental relationship was maintained between sites A and C.
In 2003, SRDF/A was released and concurrent SRDF/A and SRDF/S became possible. So, when a
large European company (in the same line of business as the American company), paid a visit to their
friends in New York, they got the idea for a product with the functionality of Star. Late in 2003, the
Europeans came to Hopkinton and had a meeting with Engineering in which they outlined their
requirements.
EMC decided to implement a product as desired by the European customers and call it STAR which
was supposed to be an acronym for Symmetrix Triangulated Automated Replication. It took 2 years
from the first conversation with the customer and 18 months of development to produce a version of
Star on Mainframe in 2004. The Open Systems version was released in 2005. To conform to EMCs
naming architecture for the SRDF products, the name SRDF/Star was chosen.
In 2008 when Cascaded SRDF was released, Star functionality was enhanced to support this feature. In
2009 when SRDF/Extended Distance Protection was released, Star was enhanced to support
SRDF/EDP.
- 52
SRDF/Star Using Concurrent SRDF Mode

y 3-site disaster
recovery over
extended distances
y Short distance
SR
20 DF
0 /S
km
y Zero data lag
y SRDF link between

two targets in standby
mode
<
y Concurrent SRDF:
source to two
concurrent targets
Nearby Synchronous
Target
y Synchronous and
Asynchronous targets
can be differentially
synchronized if
Workload site fails
Workload Site
Sync Target
SRDF/A > 200 km
Async Target
Remote Asynchronous
Target
y Extended distance
y Variable data lag (seconds
to minutes)
y No performance impact
Concurrent SRDF/Star enables concurrent SRDF/S and SRDF/A operations from the same source
volumes.
The primary business benefit of Star is that in the event of a workload site outage, it is possible to
undertake a differential resynchronization between the two remaining sites, followed by the resumption
of production at either site.
- 53
SRDF/Star Using Cascaded SRDF Mode

y 3-site disaster
recovery over
extended distances
y Short distance
y Zero data lag
SR
20 DF
0 /S
km
SRDF/A > 200 km
<
y Cascaded SRDF:
source to two
cascaded targets
Nearby Synchronous
Target
Sync Target
y SRDF link between

source and async
target in standby
mode
y Depending on the
nature of the failure,
can be reconfigured to
concurrent Star
Workload Site
Async Target
Remote Asynchronous
Target
y Extended distance
y Variable data lag (seconds
to minutes)
y No performance impact
Cascaded SRDF/Star was introduced in 2008 with the release of Enginuity 5773. Cascaded RDF
allows a synchronous R2 target to also act as a source for SRDF/A. The long distance site in cascaded
RDF uses this source to receive its data feed. In the event of a failure of the workload site, the
synchronous target has up to date data. The asynchronous target data is not more than two SRDF/A
cycles behind the source site data.
- 54
SRDF/Star with Extended Distance Protection

y Operation only possible in Cascaded mode
y Concurrent configuration possible if there is no data flow
and only as a temporary step, e.g. if link between sites A
and B fail and the link between sites A and C are
activated
y 5874 required at all three sites if R22s are being used
y Constraints related to diskless R21s apply
Primarily, EDP is available for cascaded Star mode. Concurrent Star with diskless R21s has limited
functionality. Star with Extended Distance Protection can be built either with R2 devices or R22
devices at the Asynchronous target site.
- 55
Recommendations and Constraints

y Each application should be contained in a Star triangle
y Maximum 250 SRDF groups per Symmetrix
y Maximum 64 SRDF groups per director (4 6 groups
recommended per director if heavy load)
y Equal number of Symmetrix arrays at each site
It is possible to configure more than one Star triangle per Symmetrix. It is also possible to include
more than one Symmetrix in a Star triangle.
Each application, or group of applications, that would fail over together should be in one Star triangle.
Applications or application groups designed to fail over separately should be in their own Star
triangles.
A maximum of 250 SRDF groups are allowed in a Symmetrix V-Max. Though the theoretical
maximum number of SRDF directors that an RDF director can support is 64, an RDF director should
only be assigned a maximum of 4 6 SRDF groups if the workload is heavy.
- 56
Older Star Configurations

Concurrent SRDF/Star Configuration
Cascaded SRDF/Star Configuration

Symmetrix 2
Site B
Symmetrix 2
Site B
Symmetrix 1
Site A
Symmetrix 1
Site A
R2
SRDF/S
Passive Link
R11
R21
SRDF/S
R1
SRDF/A
SRDF/A
Passive Link
R2
R2
Symmetrix 3
Site C
Symmetrix 3
Site C
Only one site has a concurrent (R11) or

cascaded(R21) volume
Prior to the release of Solutions Enabler 7.0 there was no support for R22 devices. All Star
configurations were set up with an R2 device at the asynchronous target. The source site had a
concurrent source or R11 device if Star was running in concurrent mode. Otherwise the synchronous
target had a cascaded R21 device if Star was running in cascaded mode.
- 57
Star Configuration using 5874 and latest 5773

Concurrent SRDF/Star Configuration
Cascaded SRDF/Star Configuration

Symmetrix 2
Site B
Symmetrix 2
Site B
Symmetrix 1
Site A
R21
SRDF/S
Passive Link
R11
SRDF/A
Symmetrix 1
Site A
R21
SRDF/S
R11
SRDF/A
Passive Link
R22
Symmetrix 3
Site C
R22
Symmetrix 3
Site C
Every site has a concurrent (R11), (R21) or R22 volume

NOTE: ALL examples in this course use the newer
configuration with R22 devices.
With V7.0 of Solutions Enabler and Enginuity 5874 support R22 devices. These devices can maintain
a target relationship with two R1 devices, though not at the same time. The big advantage of using R22
devices is during Star reconfigurations after a Workload site failure. R22 devices make
reconfigurations more resilient in case there is a link failure while the reconfiguration is in progress.
Along with R22 devices, newer Star configurations employ R11s at the source site and R21s at the
synchronous target. In a concurrent Star setup the R21 to R22 link between B and C is passive. In a
cascaded Star configuration the R11 to R22 link between A and C is passive.
- 58
SRDF/Star Failure Scenarios

Workload Site A
Sync Target B
6 A - R11
B - R21 2
Workload Site A
6 A - R1
Concurrent Star
C R22 4
B - R21 2
3
Cascaded Star
Async Target C
Sync Target B
C R22 4
Async Target C
1. Link failure between A and B

2. Site B failure
3. Link failure between A and C
4. Site C failure
5. Link failure between B and C
6. Site A failure
There are 6 possible fault conditions that can arise in a Star setup. These comprise the failure of the
three sites and failure of the three links. Depending on whether Star was operating in Concurrent or
Cascaded mode, the response to the failures will be different.
- 59
Concurrent Star Operations After Failure

Failure Cases
Operation w/o Reconfig
1. Link failure between A & B
Operation w. Reconfig
A - R11
C - R22
2. Site B failure
A - R11
C - R22
3. Link failure between A & C
A - R11
B - R21
4. Site C failure
A - R11
B - R21
5. Link failure between B & C
A - R11
B - R21
A R11
B - R21
C - R22
C R22
B R11
OR
6. Site A failure
C R22
B R21
C R11
This is a list of possible actions after a failure occurs in a concurrent Star setup.
1. If the link between A and B fails, it is still possible to run production at A with remote protection
available at site C.
2. The same holds true if site B fails.
3. If the link between A and C fails, there are two possibilities. The first is to continue running
production at A with remote protection at B. The second is to reconfigure concurrent Star to
cascaded Star and run in Star protected mode.
4. If site C fails, the only option is to continue running at site A with remote protection at B.
5. If the link between B and C fails there is no effect on Star operations because the standby links
between B and C are not used unless there is a failure of site A.
6. If site A fails, production has to be switched to site B or site C. This necessitates a reconfiguration
of the RDF devices. The devices at the site to which production was switched become R1 devices
and the remaining site is reconfigured to become R2 targets to the new production site.
The choice of which location to fail over to depends on customer needs and the location of customer
resources.
- 60
Cascaded Star Operations After Failure

Failure Cases
Operation w/o Reconfig
1. Link failure between A & B
Operation w. Reconfig
A - R11
C R22
2. Site B failure
A - R11
C R22
3. Link failure between A & C
A R11
B - R21
C R22
4. Site C failure
A R11
B - R21
5. Link failure between B & C
A R11
B - R21
B - R21
A - R11
C - R22
B R11
6. Site A failure
OR
C R22
B R21
C R11
This is a list of possible actions after a failure occurs in a cascaded Star setup.
1. If the link between A and B fails, it is still possible to run production at A with remote protection
available at site C but only after a reconfiguration.
2. The same holds true if site B fails.
3. If the link between A and C fails there is no effect on Star operations because the standby links
between A and C are not used unless there is a failure of site A.
4. If site C fails, the only option is to continue running at site A with remote protection at B.
5. If the link between B and C fails, there are two possibilities. The first is to continue running
production at A with remote protection at B. The second is to reconfigure cascaded Star to
concurrent Star and run in Star protected mode.
6. If site A fails, production has to be switched to site B or site C. This necessitates a reconfiguration
of the RDF devices. The devices at the site to which production was switched become R1 devices
and the remaining site is reconfigured to become R2 targets to the new production site.
The choice of which location to fail over to depends on customer needs and the location of customer
resources. As is obvious from this diagram, if you ignore case 5 where reconfiguration is optional,
3 of the 6 failure scenarios require an RDF reconfiguration in Cascaded Star if you want to retain
remote data protection after the failure.
- 61
Operation of SRDF/Star using Concurrent SRDF

y Describe the steps to set up a Star configuration running
in concurrent mode
y Describe recovery steps after failure of a target site
y Describe recovery steps after failure of the Workload site
- 62
Star Operational Setup and Normal Operation

y Star is a Solutions Enabler application the
symstar command
Provides automation for underlying CLI
commands
y Create a Composite Group whose

consistency will be managed by the RDF
daemon, using RDF-ECA and MSC
y Run setup
Disconnected
Disconnected
disconnect
Connected
Connected
unprotect
y Three principal operational commands

symstar connect (establish SRDF)
symstar protect (enable CG)
symstar enable (enable Star protection)
connect
protect
Protected
Protected
disable
enable
Star Protected
y symstar query provides state information

connected, protected, enabled just like the
commands
The symstar command in Solutions Enabler is responsible for managing Star. It issues the SRDF commands needed to
perform all Star actions.
The symstar setup action marks the RDF groups to which the devices in the CG belong as groups intended for use by Star
commands. Similarly the devices in the CG are identified as devices participating in a Star configuration.
A Star configuration can be in several states as shown above. Each state is clearly defined and transitioning from one to the
other is achieved by the use of the actions shown.
The Disconnected, Connected and Protected states refer to the relationship between the Workload site, connecting path and
either target site. This is why there are two rectangles in the Disconnected, Connected and Protected states. The Star
Protected state refers to all three sites as a complete entity.
A Disconnected state between the Workload site and either remote site indicates there is no data flow between the sites.
The RDF relationship may not be properly defined, e.g. after a Workload site failure and a work load switch. The remote
site does not contain a copy of the production data, hence there is no remote data protection. The connect action has to be
issued to transition from the Disconnected to the Connected state
A Connected state between the Workload site and either target indicates there is data flow between the sites. The RDF
relationship is properly defined. The target site in question is not necessarily synchronized with the Workload site. There is
no consistency protection for the remote data. The protect action transitions the Workload site and remote site in question
from the Connected to the Protected state.
In the Protected state there is data flow between the Workload site and remote site. The RDF relationship is properly
defined. Dependent write consistency of the data at the synchronous target site is assured through RDF-ECA. Dependent
write consistency at the asynchronous target is assured through MSC. The enable action transitions all three sites into the
Star Protected state.
In the Star Protected state there is data flow and consistency protection at each individual target site. Additionally, the
differential relationship between the Synchronous and Asynchronous target sites is defined. If the Workload site were to
fail, a differential resynchronization between the two surviving sites would be possible.
- 63
Star Options and Internal Definitions Files

y Star Options File
Created with text editor on a host at Workload site
Used for:
Defining site names for the 3 sites
Specifying parameters that govern SRDF/Star behavior
Creating the SRDF/Star internal definitions file with help of symstar
setup command
y Star Internal Definitions File

Created from Star options file
Copied from Workload site to target sites
Automated copying can be enabled on hosts running V7.0 of Solutions
Enabler
Used by the symstar command

The Star options file is created by the user with a text editor. It specifies parameters shown on the next
page. The setup command translates the contents of the options file and writes them into the Star
internal definitions file. This file is used by the symstar command for all its actions.
The internal definitions file is created as a result of executing the symstar setup action. It should
not be modified by users. Any changes should be instituted through the options file.
- 64
Option File on Host at Workload Site - Site A

File sun1star.opt
SYMCLI_STAR_WORKLOAD_SITE_NAME
= sun1starA
SYMCLI_STAR_SYNCTARGET_SITE_NAME = sun1starB
SYMCLI_STAR_ASYNCTARGET_SITE_NAME = sun1starC
SYMCLI_STAR_ADAPTIVE_COPY_TRACKS = 30000
SYMCLI_STAR_ACTION_TIMEOUT = 1800
SYMCLI_STAR_TERM_SDDF = YES
SYMCLI_STAR_ALLOW_CASCADED_CONFIGURATION
SYMCLI_STAR_COMPATIBILITY_MODE
SYMCLI_STAR_AUTO_DISTRIBUTE_INTERNAL_FILE
SYMCLI_STAR_SYNCTARGET_RDF_MODE
=
=
=
=
A - R11
B - R21
C R22
YES
V70
Yes
ACP
Create a Concurrent Star configuration using the composite group sun1star

# symstar -cg sun1star -opt sun1star.opt setup -opmode concurrent -nop
A detailed description of all the parameters in the options file is out of scope for this course and can be
found in the Solutions Enabler SRDF manual. The important ones are the three site names, where site
specific names such as Singapore or London can be chosen. Here the names sun1starA, sun1starB and
sun1starC have been chosen because they made sense in the lab where the screen captures were taken.
The adaptive copy tracks value is an invalid track threshold value.
If a symstar protect command is issued for the synchronous target, there will be a wait until the
number of invalid tracks are below this number before the SRDF mode of the target being protected is
switched from adaptive copy to synchronous.
If a symstar protect command is issued for the asynchronous target, there will be a wait until
the number of invalid tracks are below this number before the SRDF mode of the target being
protected is switched from adaptive copy to asynchronous.
The SYMCLI_STAR_ACTION_TIMEOUT value specifies in seconds the length of time that a
symstar protect or a symstar enable command will wait to complete before timing out.
The SYMCLI_STAR_COMPATIBILITY_MODE = V70 specifies that features introduced in Version
7 of Solutions Enabler such as state tracking and Star with EDP are permitted.
The setup command shown here sets up a concurrent Star configuration using the composite group
sun1star.
- 65
Excerpt from Star Query

DMX800SUN1/> symstar query -cg sun1star
Site Name
: sun1starA
Site from which query was issued
Workload Site
1st Target Site
2nd Target Site
: sun1starA
: sun1starB
: sun1starC
Three site names
Composite Group Name

Composite Group Type
: sun1star
: RDF1
Workload Data Image Consistent

System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
: Yes
:
:
:
:
Disconnected State determined by RDF pair

Disconnected states of the RDF devices
Unprotected
Result of specifying concurrent
Concurrent
mode during setup
z z z
After symstar setup is run the symstar query output identifies the site from which the query
was executed. It identifies the Workload site as sun1starA. The first target or the Synchronous site is
sun1starB. The second target or the asynchronous site is sun1starC. Both targets are in the
Disconnected state indicating that the SRDF links are in the suspended state. The Mode of operation is
concurrent, because the opmode concurrent option was indicated during the setup step.
- 66
Connect Protect Enable
Disconnected
Disconnected
DMX800SUN1/> symstar connect -site sun1starB -cg sun1star -nop

DMX800SUN1/> symstar connect -site sun1starC -cg sun1star nop
System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
:
:
:
:
connect
Connected
Connected
Unprotected
Concurrent
DMX800SUN1/> symstar protect -site sun1starB -cg sun1star -nop

DMX800SUN1/> symstar protect -site sun1starC -cg sun1star nop
System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
:
:
:
:
Protected
Protected
Unprotected
Concurrent
Connected
Connected
protect
Protected
Protected
enable
DMX800SUN1/> symstar enable -cg sun1star -nop
STAR
: Protected
Star Protected
The connect action starts the data flow between the source and the two target sites in adaptive copy
mode. Each target site must be connected individually. The protect action switches the mode to
Synchronous or Asynchronous depending on the target site after the invalid tracks are below the
threshold value specified in SYMCLI_STAR_ADAPTIVE_COPY_TRACKS. Finally the enable
action enables Star protection.
- 67
Star Operation after Target Site Transient Fault

y Target site fault recovery is managed with the reset
command
symstar reset (MSC cleanup and resets state)
Disconnected
Disconnected
connect
reset
Connected
Connected
protect
PathFail
Protected
Protected
enable
Fault occurrence
Star Protected
A transient target site fault in a Star configuration is defined by the loss of a site other than the
Workload site. The target site could become unavailable because a loss of network communications or
problem at the site itself such as a power failure. It does not affect production at the workload site.
After a transient fault, the site state changes from Synchronized or Consistent to Pathfail or
PathFail;CleanReq. At this point there is no data flow between the Workload and the failed target site.
The data at the target site is consistent, since consistency protection was in force.
- 68
Recovery from Loss of Synchronous Target

A - R11
B - R21
C R22
Query shows Site as PathFail And Star Tripped

System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
:
:
:
:
PathFail
Protected
Tripped
Concurrent
After the site returns to service: 1. Issue a site Reset 2. Take BCV copies at site B
# symstar -cg sun1star reset -site sun1starB noprompt
System State:
{
1st_Target_Site
: Disconnected
2nd_Target_Site
: Protected
STAR
: Unprotected
Mode of Operation
: Concurrent
}
Connect Protect Enable

# symstar -cg sun1star connect -site sun1starB noprompt
# symstar -cg sun1star protect -site sun1starB noprompt
# symstar cg sun1star enable -noprompt
After the connection between the Workload and target sites are reinstated, the reset action performs
the necessary cleanup at the target site. Since the failure occurred on the Synchronous Target, MSC
cleanup was not necessary. reset disables consistency group protection and sets the RDF mode to
adaptive copy, but does not resume the RDF links. It also transitions the target site in question to the
Disconnected state.
If the target site has BCVs, this is the time to take a gold copy of the data at the target site before
resynchronization begins and data consistency at the target is destroyed.
Finally, the connect protect enable sequence reinstates Star protection.
- 69
Star Operation After Workload Site Fault

y Workload site fault necessitates a symstar switch to a
target site
Enables the workload to run at a different site; performed at the
target site
Updates target as required incrementally and with no data loss
Performs SRDF functions to change pairs and personalities
Disconnected
Disconnected
connect
Connected
Connected
protect
Protected
Protected
enable
switch
Disconnected
Disconnected
(keep local data)

PathFail
PathFail
switch
(keep remote data)
cleanup
PathFail
PathFail
CleanReq
Disconnected
Connected
Fault occurrence
Star Protected
An Unplanned Switch Operation becomes necessary when the Workload site disaster warrants a move
of the production workload to the Synchronous or Asynchronous target site. After the disaster, the
system transitions from the Star Protected to Star Tripped state. The Synchronous target transitions
to the PathFail state, the Asynchronous Target to the PathFail or PathFail;CleanReq state.
Recovery operations must be undertaken to start production at one of the target sites.
The distinction between PathFail and PathFail;CleanReq states is the need for MSC
cleanup at the Asynchronous Target site.
If it is decided to switch to a remote site and preserve data at that site, the switch command transitions
the sites to the Disconnected state. From that state it is necessary to issue a connect command to
arrive at the Connected state.
If the decision is made to switch to a remote site and preserve the data of the other remote site, then the
switch command transitions the remaining sites to the Connected state.
- 70
Workload Site Failure, Switch Variations

y There are 4 main variations for Unplanned Workload
Switch
Switch to Sync Target Site, Keep Sync Target data
Switch to Sync Target Site, Keep Async Target data
Switch to Async Target Site, Keep Async Target data
Switch to Async Target Site, Keep Sync Target data
y Switch to site, decision based on customer needs

y Keep data decision from symstar query output, telling if
Async Target data is most current
y Best practice is to save "Gold" copy before initiating
synchronization
The decision about which site to switch depends on the customers infrastructure capabilities and the
nature of the disaster which may have effected the campus Synchronous Target Site.
The Asynchronous Target site can be more up-to-date than the Synchronous target in the case of a
rolling disaster. This can happen if the links to the Synchronous target site fail first and the
Asynchronous target continues to receive data for a while. Then the Workload site fails completely.
The symstar query command can assist to make the decision about which data is most recent and
must be preserved.
In the example that follows, Workload is switched to the Synchronous target site while keeping the
data of the Synchronous target site.
- 71
Workload Site Fault: Synch Site More Current

Star Protected
site
loss
sun1starB
PathFail
PathFail
A - R11
ConcStarA
B - R21
Query shows both sites as PathFail

System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
C R22
:
:
:
:
PathFail
PathFail
Tripped
Concurrent
sun1starC
In the example shown here, the Workload site has failed. Assume that the query reveals that the data at
the Synchronous Target is more recent.
The system state is StarTripped.
The Synchronous Target site transitions to the PathFail state.
The Asynchronous target site transitions to the PathFail; CleanReq state if the failure occurred in the
middle of a Delta Set switch. Otherwise, it transitions to the PathFail state.
- 72
Workload Site Disaster: Cleanup Asynch Target

PathFail
CleanReq
PathFail
ConcStarB
cleanup
A - R11
ConcStarA
B - R2
20
PathFail
21
PathFail
C - R2
ConcStarC
If 2nd Target had been PathFail;CleanReq MSC cleanup would have been run as shown below
# symstar -cg sun1star cleanup -site sun1starC -nop
Cleans up internal meta data and Symmetrix cache at ConcStarC

Transitions 2nd target site from PathFail;CleanReq to PathFail
Allows for Gold copy capture prior to resynchronization
The cleanup step is necessary only if the state of the Asynchronous target site was PathFail;
CleanReq after the failure of the Workload site.
The cleanup command can be issued from either remaining site. This performs MSC Cleanup at the
Asynchronous target site.
After cleanup is performed, a BCV copy of the data should be taken to preserve a consistent data copy
from the point of time of the failure.
- 73
Workload Site Fault: Switch To Synch Target

Switch production to remote site, sun1starB, keeping local data
PathFail
PathFail
switch
Disconnected
Disconnected
symstar switch -site sun1starB -keep_data sun1starB
R21 devices at site B become R11 devices

Relationship between sites A and B become duplicate
The workload is moved to site B

Site Name
Workload Site
1st Target Site
2nd Target Site
..
System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
sun1starB
A - R11
ConcStarA
B R11
: sun1starB
: sun1starB
: sun1starA
: sun1starC
:
:
:
:
C - R22
sun1starC
Disconnected
Disconnected
Unprotected
Concurrent
In the example shown here, the Workload site is being moved from sun1starA to sun1starB, while
retaining data in sun1starB. Note that this represents the Keep Local Data option on the Unplanned
Switch state flow diagram shown earlier.
The switch command reconfigures the RDF devices at sun1starB and turns them into R11 devices. The
RDF pair relationship between B and A is now duplicate.
- 74
Workload Site Fault: Connect and Protect Async Target

Disconnected
Disconnected
connect
Disconnected
Connected
protect
Disconnected
Protected
Initiate data flow between sites B and C in Adaptive Copy

(Remember to take BCV copies prior to connection)
symstar connect -cg sun1star -site sun1starC nop
Wait for invalid track count to reach threshold

Set SRDF mode to asynchronous
Enable MSC protection
symstar protect -site sun1starC -nop -cg sun1star
sun1starB
B R11
C - R22
Query shows that Site C is protected

System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
:
:
:
:
Disconnected
Protected
Unprotected
Concurrent
sun1starC
Before issuing the connect command, BCV golden copies should be taken at site C, whose data
consistency will be destroyed during the differential synchronization between sites B and C. The
connect action activates the link between sites B and C. Since we are using R22s, the work to
connect Site C is significantly less than in 5773 and earlier. At the end of the connect step Sites B and
C have an active relationship such that data can flow in adaptive copy mode.
The protect action enables MSC protection between sun1starB and sun1starC. Star protection is not
possible because three sites are not available.
An excerpt from the symstar query output shows that the second target site is in the Protected
state.
- 75
Workload Site Problem Resolved: Bring Online

sun1starB
A - R11
sun1starB
B R11
sun1starA
A - R21
B R11
sun1starA
C - R22
C - R22
sun1starC
sun1starC
Propagate data back to sun1starA

symstar -cg sun1star connect -site sun1starA -nop
Performs half swap at site A turning them into R21 devices

Establishes RDF devices in Adaptive Copy Disk Mode
Transitions sun1starA to a Connected state
Continuing the example shown earlier, let us assume that the problem that caused the Workload site at
sun1starA to be shut down has been resolved. When the connect command is used at sun1starB, the
RDF volumes in sun1starA are reconfigured so that they become R21devices. An adaptive copy
synchronization is initiated between sun1starB and sun1starA.
- 76
Query After Connect - Workload at sun1starB

Site Name
: sun1starB
Workload Site
1st Target Site
2nd Target Site
: sun1starB
: sun1starA
: sun1starC

: sun1star
: RDF1

System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
z z z
: Yes
:
:
:
:
Connected
Protected
Unprotected
Concurrent
A Star query shows that the Workload is running at sun1starB. The async target site sun1starC is
protected while the new sync target site sun1starA is connected.
- 77
Planned Switch Operation: Command Flow
Disconnected
Disconnected
connect
Connected
Connected
Halted
Halted
protect
halt
switch
halt
Protected
Protected
halt
Disconnected
Disconnected
enable
Star Protected
This example shows the steps to switch the Workload site back to the original site ConcStarA in a
planned fashion. The key command here is halt. A planned workload switch is typically used either
to move back home after the resolution of a Workload site failure or in the course of a disaster drill.
All site moves are allowed as long as the sites are functional and the RDF connectivity is present.
- 78
Planned Switch to sun1starA: Halt Replication

Shutdown applications at Site B, then execute:
Connected
symstar halt -cg sun1star nop
Protected
halt
Halted
Halted
Completely synchronizes both remote target sites

Allows all invalid tracks and cycles to drain
WD or NR the R1 devices
Results in all 3 sites having the same data
Query shows Halted State
System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
:
:
:
:
Halted
Halted
Unprotected
Concurrent
The halt command ensures that all three sites are identical and write disables the R1 devices if they
are mapped to an FA. The query shows that the halt was successful. The Workload site still remains at
sun1starB.
- 79
Planned Switch Back to site A

sun1starB
A - R21
sun1starB
B R11
A - R11
sun1starA
B - R21
sun1starA
C - R22
sun1starC
Halted
C R22
Halted
sun1starC
switch
Disconnected
Disconnected
Halt Command issued at sun1starA cause RDF swap between devices at A & B
symstar cg ConcStar switch site ConcStarA
The switch command now resets the RDF relationships so that sun1StarA devices have the RDF11
attribute and are concurrently connected to sun1starB and sun1starC. Both targets transition to the
Disconnected state. Now, the connect protect - enable action sequence transitions
the system to the Star protected state.
- 80
Query from sun1starA After Switch

DMX800SUN1/usr/sengupta> symstar query -cg sun1star
Site Name
: sun1starA
Workload Site
1st Target Site
2nd Target Site
: sun1starA
: sun1starB
: sun1starC

: sun1star
: RDF1

System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
Last Action Performed
Last Action Status
Last Action Timestamp
: Yes
STAR Information:
{
STAR Consistency Capable
STAR Consistency Mode
Synchronous Target Site
Asynchronous Target Site
Differential Resync Available
R2 Recoverable
Asynchronous Target Site Data most Current
}
:
:
:
:
Disconnected
Disconnected
Unprotected
Concurrent
: Switch_sun1starA
: Successful
: 11/06/2009_12:03:22
:
:
:
:
:
:
:
Yes
NONE
sun1starB
sun1starC
N/A
N/A
N/A
z zz
The query command shows the result of the switch action. The workload is back to sun1starA and
the two target sites are in their original state. The sites are in the disconnected state.
- 81
SRDF/Star using Cascaded SRDF

y Describe the steps to set up a Star configuration that
uses cascaded SRDF
The objective for this lesson is shown here. Please take a moment to read it.
- 82
Option File on Host at Worklod Site - Site A

File sun1star.opt
SYMCLI_STAR_WORKLOAD_SITE_NAME
= lin1starA
SYMCLI_STAR_SYNCTARGET_SITE_NAME = lin1starB
SYMCLI_STAR_ASYNCTARGET_SITE_NAME = lin1starC
SYMCLI_STAR_ADAPTIVE_COPY_TRACKS = 30000
SYMCLI_STAR_ACTION_TIMEOUT = 1800
SYMCLI_STAR_TERM_SDDF = YES
SYMCLI_STAR_ALLOW_CASCADED_CONFIGURATION
SYMCLI_STAR_COMPATIBILITY_MODE
SYMCLI_STAR_AUTO_DISTRIBUTE_INTERNAL_FILE
SYMCLI_STAR_SYNCTARGET_RDF_MODE
=
=
=
=
A - R11
B - R21
C R22
YES
V70
Yes
ACP
Create a Concurrent Star configuration using the composite group sun1star

# symstar -cg sun1star -opt lin1star.opt setup -opmode cascaded -nop
Since we are using R11s, R21s and R22s, the setup of the composite group for cascaded Star is the
same as that of concurrent Star. The only difference was during the setup step. The value of the
parameter opmode in this case has been set to cascaded.
- 83
Cascaded Star Query

DMX800LIN1/usr/sengupta/Star> symstar query -cg lin1star
Site Name
: lin1starA
Site from which query was issued
Workload Site
1st Target Site
2nd Target Site
: lin1starA
: lin1starB
: lin1starC
Three site names

: lin1star
: RDF1

System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
: Yes
Last Action Performed

Last Action Status
Last Action Timestamp
: Setup
: Successful
: 11/06/2009_21:53:52
:
:
:
:
Disconnected
Disconnected Result of specifying cascaded
Unprotected mode during setup
Cascaded
z z z
After symstar setup is run, the symstar query output identifies the site from which the query
was executed. It identifies the Workload site as sun1starA. The first target or the Synchronous site is
sun1starB. The second target or the asynchronous site is sun1starC. Both targets are in the
Disconnected state indicating that the SRDF links are in the suspended state. The Mode of operation is
cascadedt, because the opmode cascaded option was indicated during the setup step.
- 84
Reconfiguring Cascaded to Concurrent

y Example below up lin1star makes following assumptions
Links to site C have failed, i.e. System state is: Protected, PathFail,
Tripped
All three sites are healthy
A to C links still work
DMX800LIN1/usr/sengupta> symstar query -cg lin1star
Site Name
: lin1starA
Workload Site
: lin1starA
1st Target Site
: lin1starB
2nd Target Site
: lin1starC
: lin1star
: RDF1
: Yes
System State:
{
1st_Target_Site
: Protected
2nd_Target_Site
: PathFail
STAR
: Tripped
Mode of Operation
: Cascaded
}
z z z
A R11
B - R21
C R22
Reconfigure Cascaded Star to Concurrent Star

symstar -cg lin1star reconfigure -reset -site lin1starC -path lin1starA:lin1starC
SRDF/Star offers the ability of dynamically reconfiguring Star from concurrent to cascaded mode and
vice versa.
A practical need for reconfiguration might arise when the link between sites B and C fail. As long as
the sites themselves are in working order, a reconfiguration of Star from cascaded to concurrent would
allow the three sites to continue running in Star protected mode.
During the reconfiguration of site C replication between sites A and B continues without interruption.
- 85
Concurrent Config can be Star Protected

DMX800LIN1/usr/sengupta> symstar query cg lin1star
Site Name
: lin1starA
Workload Site
1st Target Site
2nd Target Site
: lin1starA
: lin1starB
: lin1starC

: lin1star
: RDF1

System State:
{
1st_Target_Site
2nd_Target_Site
STAR
Mode of Operation
}
: Yes
:
:
:
:
Protected
Disconnected
Unprotected
Concurrent
y Now Issue Commands:

DMX800LIN1/> symstar connect -site lin1starC -cg lin1star -nop
DMX800LIN1/> symstar protect -site lin1starC -cg lin1star -nop
DMX800LIN1/> symstar -cg lin1star enable nop
The reconfiguration leaves the asynchronous target in disconnected state. The connect, protect and
enable actions can now enable Star protection, though the link between B and C is down.
Obviously, if the Workload site fails before the B to C links are restored, production cannot be brought
up with remote protection.
- 86
Differences Between Cascaded and Concurrent Star
Since the integrity of the asynchronous data depends on

the data at the synchronous target
y Protect Synchronous target before asynchronous target
y May not unprotect synchronous target if asynchronous
target is protected
y May not connect synchronous target if synchronous
target is disconnected and the asynchronous target is
protected
There are a few important differences between the normal operating conditions of Concurrent Star and
Cascaded Star.
1. Since the consistency of the asynchronous site data is dependent on the consistency of the
synchronous site data, the asynchronous target can only be protected if the synchronous target is
protected as well. Consequently, after the two sites have been connected, the synchronous target
must be protected first.
2. While both the synchronous and asynchronous targets are in the protected state, an unprotect action
on the synchronous site will not be permitted.
3. If the synchronous target is disconnected while the asynchronous target is protected (as can happen
after a failure of the links between the workload site and the synchronous target), a connect action
will not be permitted on the synchronous target. The asynchronous target must be tripped or
unprotected before the connect with the synchronous target is allowed.
4. Since only the asynchronous site can be taken out of service without disrupting remote data
protection, it is only permissible to isolate the asynchronous target from the Protected,
Protected state.
- 87
Restrictions for SRDF/Star with EDP

With the workload at Site A
y Sites B and C have to be connected before sites A and B
can be connected
y If the link between Sites B and C fail, SRDF will suspend
the links between sites A and B
y Site B cannot be isolated
y Site C can only be isolated if the link between B and C
are in the PathFail or Disconnected state
y The Workload will not be allowed to switch to site B
y After site A fails a switch to Site C will require the option
keep_data SiteC
The SRDF manual has a detailed table that describes the actions that can be performed on a diskless
Star configuration. Some of the significant restrictions are provided here.
- 88
Benefits of SRDF/Star
y If one site fails, production can continue without losing
remote data protection
y If the workload site fails, the two remaining target sites
can be incrementally synchronized
y Though concurrent Star is more resilient, the ability to
easily reconfigure concurrent to cascaded Star and vice
versa provides great flexibility
y Cascaded Star allows the cache intensive SRDF/A
operations to be moved to the secondary site
The events of Sep. 11, 2001 made businesses more aware of the critical need to recover their data after
a disaster. A few years ago at Share, a major bank from New York did a presentation entitled The
Effects of 9/11. After the attacks on Sep. 11, this bank failed their data processing over to their New
Jersey site. Later that week they were asked by federal regulators, How are you protected now?
As the importance of information continues to increase, companies are increasingly interested in
protecting their data and minimizing their down time after a failure. SRDF/Star offers customers the
business benefits that are a high priority for institutions with mission critical data.
Both cascaded and concurrent Star have their uses, depending on the application environment. If the
loss of the primary data center is the principal concern, cascaded Star is a good choice.
If there is a risk of losing the synchronous target as well as the workload site, concurrent Star would be
a better choice.
- 89
Module Summary
y Overview of Star Configurations
y Operation of SRDF/Star using concurrent SRDF
y SRDF/Star configuration using cascaded SRDF
- 90
Course Summary
Key points covered in this course:
y SRDF Three Data Center Solutions
y Cascaded SRDF Solutions including SRDF/ EDP
y SRDF/Star Solutions
These are the key points covered in this course. Please take a moment to review them.
This concludes the training. Please proceed to the Course Completion slide to take the assessment.
- 91

SRDF Star and Cascaded SRDF Solution SRG PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

SRDF Star and Cascaded SRDF Solution SRG PDF

Cargado por

Copyright:

Formatos disponibles

Copyright 2010 EMC Corporation. Do not Copy - All Rights Reserved.