SRDF Star and Cascaded SRDF Solution SRG

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: List EMC SRDF Three Data Center Solutions Describe Cascaded SRDF Solutions including SRDF/ EDP 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: List SRDF three data center solutions 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

Protect against local and regional site disruptions
Continuous data availability Multiple remote-recovery sites Meet regulatory requirements Support multiple service levels with tiered storage
Enable fast recovery 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

Multi-hop SRDF/AR
Combination of SRDF/S and SRDF/DM to provide disaster restart at remote location
Concurrent SRDF
Typically a combination of SRDF/S and SRDF/A to provide two real time copies of data at different distances
Cascaded SRDF
Combination of SRDF/S and SRDF/A to achieve zero data loss at distant location
SRDF/EDP
Low cost zero data loss extended distance solution using SRDF/S and SRDF/A
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
2010 EMC Corporation. All rights reserved. SRDF/Star and Cascaded SRDF Solutions - 5
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

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
Excellent RPO
Zero data loss if primary site fails Data loss of seconds to minutes if primary and secondary sites fail
No need for BCV at tertiary site

Site A SRDF/S
WAN R1 R21 R21 R2
Site B
Site C SRDF/A
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

Single device assumes dual roles of R1 and R2 simultaneously Device must belong to two RDF groups Data received by this device as target is transferred automatically by this device as a source RPO in the order of seconds or minutes 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 Total Track(s) MB(s) R21:19 R21:79 R21:19 R21:79 RW RW RW RW 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 Synchronized Consistent Synchronized Consistent
-------- -------0 0 0.0 0.0
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
Adaptive Copy Disk Adaptive Copy Disk Adaptive Copy Write Pending Adaptive Copy Write Pending Synchronous Synchronous Asynchronous
R21 to R2 Asynchronous
Adaptive Copy Disk
Asynchronous
Adaptive Copy Disk
Asynchronous
Adaptive Copy Disk 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

Cascaded SRDF device not supported by ESCON RA The R21 device must belong to two RDF groups (like a concurrent RDF group) R21 cannot be configured on a BCV device Thin Devices cannot be R21 devices 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
Extended Distance Protection (EDP) at lower cost using Cascaded SRDF Diskless R21 devices at synchronous target provide data pass through to the out-of region site The R21 requires Enginuity 5874 with Solutions Enabler v7.0 or higher Can be better fit when Site B not desired as DR site
Site A SRDF/S
WAN R1 R21 R2
Site B
Site C SRDF/A
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

Diskless R21 devices cannot be mapped to a host Only supported on Gig-E or Fiber RAs Cannot form an RDF pair with a DLDEV or a TDEV Cannot participate in non-RDF replication viz.
TimeFinder/Snap TimeFinder/Clone Open Replicator
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
Adaptive Copy Disk Adaptive Copy Disk Adaptive Copy Write Pending Adaptive Copy Write Pending Synchronous Synchronous
R21 to R2 Asynchronous
Adaptive Copy Write Pending
Asynchronous
Asynchronous
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'. DMX800SUN2/usr/sengupta/Star/Pairs> symrdf list -sid 81 -cascaded Symmetrix ID: 000194900181 00C5 00C5 00C5 00C6 00C6 00C6 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 Synchronized Consistent Synchronized Consistent
RDFG # 20 SID: 194900181

R21
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
A form of concurrent RDF device that permits an R2 to maintain two RDF relationships Primarily intended for use in SRDF/Star
Reduces the number of steps during Star reconfiguration after a failure Makes Star more resilient
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 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 ---- ---- -------- --------- ----- ------- ------- --- ---- ------------- 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 Symmetrix ID: 000194900182 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 SA RA LNK MDATE Tracks Tracks Dev RDev Pair ---- ---- -------- --------- ----- ------- ------- --- ---- -------------
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: SRDF three data center solutions 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

Upon completion of this module, you will be able to: 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: Describe the working of SRDF/S 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
4 1
SRDF/S links
2
Source
Target
I/O write received from host/server into source cache I/O is transmitted to target cache Receipt acknowledgment is provided by target back to cache of source 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: An I/O write is received from the host/server into the source cache. The I/O is transmitted to the target cache. A receipt acknowledgment is provided by the target back to the cache of the source. 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: The maximum distance over which Synchronous SRDF can be used is limited by application timeouts and speed-of-light issues. 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
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

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

Dependent on write workload and link bandwidth Link overload can slow down transfer and delay cycle switch
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

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
SRDF/A ensures that:

A and B are in the same Delta Set
or
B is in later Delta Set
These Delta Sets (cycles) of I/Os, not the I/Os themselves, are ordered by SRDF/A 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

Upon completion of this lesson, you will be able to: 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)

System process on Unix and Windows Interacts with:
Base Daemon (storapid) Enginuity Consistency Assist (RDF-ECA) Group Name Services (GNS) daemon
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
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)

ECA is a feature that works inside the Symmetrix array Stalls write I/Os to a user-defined list of Symmetrix devices prior to splitting a source volume and its replica 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
Used with SRDF/S to hold write I/Os to a consistency group until all relevant links are suspended Interacts with RDF daemons on one or more control hosts to manage consistency Can replace PowerPath and MF Consistency Group Task to manage consistency on FBA and CKD volumes 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
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
At activation, a 30 second timer (ECA Window) starts While ECA window is open, Enginuity requests host HBAs to retry write I/Os to affected devices When the desired action (split/activate/suspend) completes, the ECA window is closed and I/O can flow again 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
Capture R1 N+1
R1
SRDF LINKS
Apply R2 N-1
R2 R2
Host I/O
RDF daemon monitoring
Transmit N R1
R1
Receive NR2
Host I/O
R1 Capture M+1 R1 R1
SRDF LINKS
R2 Apply
M-1R2
R2
Transmit M R1
Receive M R2
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
R1 R2 R1 R1 R1 R2
SRDF LINKS
Host I/O
R2 R2
Daemon suspends RDF links

R1 R1 R2 R2
SRDF LINKS
Host I/O
R1 R1
R2 R2
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
R1 R1 R1
SRDF LINKS
R2 R2 R2 R1 R2
Host I/O
R1 R1 R1 R1
SRDF LINKS
R2 R2 R2 R2
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
Upon completion of this lesson, you will be able to: Describe MSC Cleanup Describe MSC Cycle Switching
- 32
MSC Cleanup After an SRDF/A Trip

A trip can occur at different times in the SRDF/A cycle 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: The RDF daemon performs MSC cleanup automatically if it can communicate with the target arrays. The API/CLI automatically performs MSC cleanup during the processing of any RDF control command. 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

Capture N+1 Transmit N Apply N-1 Receive N
Receive Delta Set Incomplete
Host I/O
CG: MSC
SRDF LINKS
?
Capture M+1 N+1 Transmit M N Apply M-1 N-1 Receive M N
Receive Delta Set Complete
Host I/O
SRDF LINKS
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. If all Receive Delta sets were complete, it would be correct to Apply the data. However, if any of the Receive Delta sets are incomplete, then the data must be discarded. 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: The RDF daemon; Any RDF control command issued by the API/CLI; The user issues an explicit symstar cleanup command.
- 34
MSC Cleanup Logic

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?
A MSC cleanup logic decides what to do (4 possibilities)

# R2 Symm A
1 2 3 4 No Cleanup Needed No Cleanup Needed MSC Cleanup Needed A=N A=N
R2 Symm B
No Cleanup Needed -
Action
All discarded, no MSC Cleanup
MSC Cleanup MSC Cleanup Needed Symms A=N Needed must discard MSC Cleanup A=N All complete, all are committed Needed
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
Capture N+1 N Transmit N-1 N Apply N-2 N-1 Receive N-1 N
CG: MSC
SRDF LINKS
Host I/O
Capture M+1 N Transmit N-1 M
Time to perform cycle switch!

SRDF LINKS
Apply M-1 N-2 Receive N-1 M
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: The RDF Daemon verifies that each R1 Symmetrix array has completed transferring the Transmit Delta Set to the R2s and 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

Upon completion of this lesson, you will be able to: Describe SDDF Features in support of SRDF/Star Describe SRDF Features in support of Star
- 37
Symmetrix Differential Data Facility

Each Symmetrix logical volume can support up to 16 sessions SDDF sessions comprise bitmaps that flip a bit for every track that changed since the session was initiated SDDF sessions are used to monitor changes in:
Clones Snaps BCVs Change Tracker Open Replicator
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
SRDF/S
0001011100100
R11
SRDF/A
Passive Link
Site A RDF daemon from control host manages SDDF sessions

R2
000000000000
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
SRDF/S
0001011100100
IOR
R11
SRDF/A
Passive Link 1 SDDF bitmap

000000000000
R2
SDDF sessions at Site B frozen, since data flow to B stops 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
IOR
R11
Second Failure
Passive Link 1 SDDF bitmap

110011001000
IOR
R2
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
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 0001011100100
SRDF/S
R1
Passive Link SRDF/A
000000000000
Site A RDF daemon manages 2 Active SDDF sessions per each device
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
R1
Passive Link 2 SDDF bitmaps
1001011001001 0001011100100
SRDF/A 1 SDDF bitmap

000000000000
IOR
R2
If sites A and C are reconfigured in concurrent mode: 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
R1
Passive Link 2 SDDF bitmaps
1001011001001 0001011100100
SRDF/A 1 SDDF bitmap

000000000000
R2
SDDF sessions at Site A frozen 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

2-Way Mir
R1
R2
R1
Normal Configuration Suspended State
After half delete
Deletes half of the RDF pair relationship Can be used to dissolve RDF relationships if partner device is unavailable 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
Changes personality of one side of an RDF relationship After a half swap
the RDF pair configuration for the device shows up as Duplicate 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
BEFORE HALF SWAP Normal Configuration Suspended State

R1 R2
AFTER HALF SWAP Duplicate Configuration

R1 R1
AFTER HALF SWAP Normal Configuration Suspended State

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 Two forms of RDF pair creation used only in SRDF/Star 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
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
Key points covered in this module: 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
- 48
Module 2 : SRDF/Star
Upon completion of this module, you will be able to: Give an overview of Star Configurations Describe the operation of SRDF/Star using concurrent SRDF Describe a Star configuration using cascaded SRDF
- 49
Overview of Star Configurations

Upon completion of this lesson, you will be able to: List SRDF/Star Configurations using Concurrent and Cascaded SRDF Describe failure conditions and how they affect SRDF/Star operation
- 50
SRDF/Star Overview
Integration of EMC offered three-site SRDF/S and SRDF/A solutions
Concurrent and cascaded SRDF modes of operation
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

2001: Special version of SRDF/AR for a US company 2003: SRDF/A and concurrent SRDF and SRDF/A released 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
2004: Release of concurrent SRDF/Star on Mainframes 2005: Release of concurrent SRDF/Star on Open Systems 2008: Release of Cascaded SRDF/Star 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

3-site disaster recovery over extended distances
SR 20 DF 0 /S km <
Nearby Synchronous Target

Short distance Zero data lag
Concurrent SRDF: source to two concurrent targets SRDF link between two targets in standby mode Synchronous and Asynchronous targets can be differentially synchronized if Workload site fails
Sync Target SRDF/A > 200 km
Workload Site
Async Target
Remote Asynchronous Target

Extended distance Variable data lag (seconds to minutes) 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

3-site disaster recovery over extended distances Cascaded SRDF: source to two cascaded targets SRDF link between source and async target in standby mode Depending on the nature of the failure, can be reconfigured to concurrent Star
Nearby Synchronous Target

Short distance Zero data lag
<
SR 20 DF 0 /S km
SRDF/A > 200 km
Sync Target
Workload Site
Async Target
Remote Asynchronous Target

Extended distance Variable data lag (seconds to minutes) 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

Operation only possible in Cascaded mode 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 5874 required at all three sites if R22s are being used 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

Each application should be contained in a Star triangle Maximum 250 SRDF groups per Symmetrix Maximum 64 SRDF groups per director (4 6 groups recommended per director if heavy load) 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
Symmetrix 2 Site B Symmetrix 1 Site A
R11
SRDF/A
Cascaded SRDF/Star Configuration

R21
SRDF/S SRDF/A Passive Link
R2
SRDF/S Passive Link
R1
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
R11
SRDF/A
Cascaded SRDF/Star Configuration

R11
Passive Link
R21
SRDF/S Passive Link
R21
SRDF/S SRDF/A
R22
R22
Symmetrix 3 Site C
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 3
Workload Site A
B - R21 2
6 A - R1 3
Cascaded Star
Sync Target B
B - R21 2
5
C R22 4
Async Target C
5
C R22 4
Async Target C
Concurrent Star
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
A - R11 C - R22
Operation w. Reconfig
1. Link failure between A & B 2. Site B failure 3. Link failure between A & C 4. Site C failure 5. Link failure between B & C 6. Site A failure
A - R11 C - R22 A R11 B - R21
A - R11
B - R21
C - R22 A - R11 B - R21
A - R11
B - R21 C R22 B R11 B R21
OR
C R22 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 Operation w. Reconfig
A - R11 C R22
1. Link failure between A & B 2. Site B failure 3. Link failure between A & C
A R11 B - R21
A - R11 C R22
C R22
4. Site C failure 5. Link failure between B & C 6. Site A failure
A R11
B - R21
A R11
B - R21
A - R11
B - R21 C - R22
B R11
B R21
OR
C R22 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

Upon completion of this lesson, you will be able to: Describe the steps to set up a Star configuration running in concurrent mode Describe recovery steps after failure of a target site Describe recovery steps after failure of the Workload site
- 62
Star Operational Setup and Normal Operation

Star is a Solutions Enabler application the symstar command
Provides automation for underlying CLI commands
Disconnected Disconnected
Create a Composite Group whose consistency will be managed by the RDF daemon, using RDF-ECA and MSC Run setup Three principal operational commands
symstar connect (establish SRDF) symstar protect (enable CG) symstar enable (enable Star protection)
disconnect
Connected Connected
connect
unprotect
Protected Protected
protect
disable
Star Protected
enable
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

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
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 = = = = YES V70 Yes ACP
A - R11
B - R21
C R22
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 Workload Site 1st Target Site 2nd Target Site Composite Group Name Composite Group Type Workload Data Image Consistent System State: { 1st_Target_Site 2nd_Target_Site STAR Mode of Operation } : sun1starA : sun1starA : sun1starB : sun1starC : sun1star : RDF1 : Yes : : : : Disconnected State determined by RDF pair Disconnected states of the RDF devices Unprotected Result of specifying concurrent Concurrent
mode during setup Site from which query was issued
Three site names
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

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 } : : : : Connected Connected Unprotected Concurrent
connect
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
DMX800SUN1/> symstar enable -cg sun1star -nop

STAR : Protected
enable
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

Target site fault recovery is managed with the reset command
symstar reset (MSC cleanup and resets state)
connect
Connected Connected
reset
protect
Protected Protected
PathFail
enable
Star Protected
Fault occurrence
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
Query shows Site as PathFail And Star Tripped
System State: { 1st_Target_Site 2nd_Target_Site STAR Mode of Operation }
C R22
: : : :
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

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
switch
(keep local data) PathFail PathFail
connect
Connected Connected
switch
(keep remote data) Disconnected Connected
protect
Protected Protected
cleanup
PathFail PathFail CleanReq
enable
Star Protected
Fault occurrence
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

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
Switch to site, decision based on customer needs Keep data decision from symstar query output, telling if Async Target data is most current 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 PathFail PathFail sun1starB
A - R11
ConcStarA
5 6
B - R21
Query shows both sites as PathFail

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
PathFail PathFail
A - R11
ConcStarA
5 6
B - R2
20 21
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
symstar switch -site sun1starB -keep_data sun1starB
switch
R21 devices at site B become R11 devices Relationship between sites A and B become duplicate The workload is moved to site B
sun1starB
A - R11
DMX800SUN2/> symstar query -cg sun1star Site Name Workload Site 1st Target Site 2nd Target Site .. System State: { 1st_Target_Site 2nd_Target_Site STAR Mode of Operation }
5 6
B R11
ConcStarA : 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

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
connect
Disconnected Connected
protect
Disconnected Protected
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
sun1starC
Query shows that Site C is protected System State: { 1st_Target_Site 2nd_Target_Site STAR Mode of Operation }
: : : :
Disconnected Protected Unprotected Concurrent
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
sun1starA
sun1starB
B R11
A - R21
sun1starA
B R11
C - R22
sun1starC
C - R22
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

DMX800SUN2/> symstar query -cg sun1star Site Name Workload Site 1st Target Site 2nd Target Site Composite Group Name Composite Group Type Workload Data Image Consistent System State: { 1st_Target_Site 2nd_Target_Site STAR Mode of Operation } : sun1starB : sun1starB : sun1starA : sun1starC : sun1star : RDF1 : 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 protect halt Protected Protected halt enable Disconnected Disconnected halt
Halted Halted switch
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 Protected
symstar halt -cg sun1star nop
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
: : : :
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 sun1starB
A - R21
sun1starA
B R11
A - R11
sun1starA
B - R21
C - R22
sun1starC
Halted Halted
C R22
sun1starC
switch
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 Composite Group Name Composite Group Type Workload Data Image Consistent System State: { 1st_Target_Site 2nd_Target_Site STAR Mode of Operation } Last Action Performed Last Action Status Last Action Timestamp 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 }
: sun1starA : sun1starB : sun1starC : sun1star : RDF1 : Yes : : : : Disconnected Disconnected Unprotected Concurrent
: Switch_sun1starA : Successful : 11/06/2009_12:03:22
: : : : : : :
Yes NONE sun1starB sun1starC N/A N/A N/A

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

Upon completion of this lesson, you will be able to: 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 = = = = YES V70 Yes ACP
A - R11
B - R21
C R22
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 Workload Site 1st Target Site 2nd Target Site Composite Group Name Composite Group Type Workload Data Image Consistent System State: { 1st_Target_Site 2nd_Target_Site STAR Mode of Operation } Last Action Performed Last Action Status Last Action Timestamp : lin1starA : lin1starB : lin1starC : lin1star : RDF1 : Yes : : : : Disconnected Disconnected Result of specifying cascaded Unprotected mode during setup Cascaded
Site from which query was issued
Three site names
: Setup : Successful : 11/06/2009_21:53:52
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

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 Composite Group Name : lin1star Composite Group Type : RDF1 Workload Data Image Consistent : Yes System State: { 1st_Target_Site : Protected 2nd_Target_Site : PathFail STAR : Tripped Mode of Operation : Cascaded }
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 Composite Group Name Composite Group Type Workload Data Image Consistent System State: { 1st_Target_Site 2nd_Target_Site STAR Mode of Operation } : lin1starA : lin1starB : lin1starC : lin1star : RDF1 : Yes : : : : Protected Disconnected Unprotected Concurrent
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 Protect Synchronous target before asynchronous target May not unprotect synchronous target if asynchronous target is protected 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 Sites B and C have to be connected before sites A and B can be connected If the link between Sites B and C fail, SRDF will suspend the links between sites A and B Site B cannot be isolated Site C can only be isolated if the link between B and C are in the PathFail or Disconnected state The Workload will not be allowed to switch to site B 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
If one site fails, production can continue without losing remote data protection If the workload site fails, the two remaining target sites can be incrementally synchronized Though concurrent Star is more resilient, the ability to easily reconfigure concurrent to cascaded Star and vice versa provides great flexibility 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
Key points covered in this module: Overview of Star Configurations Operation of SRDF/Star using concurrent SRDF SRDF/Star configuration using cascaded SRDF
- 90
Course Summary
Key points covered in this course: SRDF Three Data Center Solutions Cascaded SRDF Solutions including SRDF/ EDP 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

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SRDF Star and Cascaded SRDF Solution SRG

Enviado por

Direitos autorais:

Formatos disponíveis

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