73873740 Srdf Star and Cascaded Srdf Solution Srg

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

SRDF/Star and Cascaded SRDF Solutions - 1

© 2010 EMC Corporation. All rights reserved.

SRDF/Star and Cascaded SRDF SolutionsSRDF/Star and Cascaded SRDF Solutions

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.



© 2010 EMC Corporation. All rights reserved. SRDF/Star and Cascaded SRDF Solutions - 2

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

The objectives for this course are shown here. Please take a moment to read them.




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.




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 EMC’s 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.




Three Data Center SRDF SolutionsMulti-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

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 out-of-region site. Using cascaded SRDF combined with diskless R21 devices in the intermediate (Pass-Thru) 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.




Cascaded SRDF OverviewCombination 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

R1 R2R21

SRDF/A

SRDF/SWAN

Site A Site CSite B

R21

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 BCVsat the tertiary site, as would be the case with SRDF/AR.




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 multi-session 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.




View of Cascaded SRDF Device# symrdf list -sid 81 -cascadedSymmetrix 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 R21:19 RW WD RW S..2. 0 0 WD RW Synchronized 00BD R21:79 RW RW RW A..1. 0 0 RW WD Consistent

00BE 00BE R21:19 RW WD RW S..2. 0 0 WD RW Synchronized 00BE R21:79 RW RW RW A..1. 0 0 RW WD Consistent

Total -------- --------Track(s) 0 0MB(s) 0.0 0.0

Legend for MODES:

M(ode of Operation) : A = Async, S = Sync, E = Semi-sync, C = Adaptive CopyD(omino) : X = Enabled, . = DisabledA(daptive Copy) : D = Disk Mode, W = WP Mode, . = ACp off(Mirror) T(ype) : 1 = R1, 2 = R2(Consistency) E(xempt): X = Enabled, . = Disabled, M = Mixed, - = N/A

Devices BD and BE in Symmetrix 81are R2 devices in group 19 and R1

devices in group 79

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.




Permitted Modes for Disk Based R21s

Adaptive Copy DiskAsynchronous

Adaptive Copy DiskSynchronousAsynchronousSynchronous

Adaptive Copy DiskAdaptive Copy Write PendingAsynchronousAdaptive Copy Write Pending

Adaptive Copy DiskAdaptive Copy DiskAsynchronousAdaptive Copy Disk

R21 to R2R1 to R21

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.




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.




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

R1 R2

SRDF/A

SRDF/SWAN

Site A Site CSite B

R21

Production Site Pass Thru Site Out of Region Site

Cache-only R21 devices

Available with Enginuity 5874, SRDF/EDP is a lower cost solution to achieve no data loss at an out-of-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.




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.




Permitted Modes for Diskless R21s

Adaptive Copy Write PendingSynchronousAsynchronousSynchronous

Adaptive Copy Write PendingAdaptive Copy Write PendingAsynchronousAdaptive Copy Write Pending

Adaptive Copy Write PendingAdaptive Copy DiskAsynchronousAdaptive Copy Disk

R21 to R2R1 to R21

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.




Sequence of Synchronization Matters with SRDF/EDPDMX800SUN1/ symrdf establish -file pairs -sid 80 -rdfg 20 -nop

An RDF 'Incremental Establish' operation execution is in progress for devicefile 'pairs'. Please wait...

The other pair of the R21 is not in a valid RDF state for this operation. Operation can not be performed

DMX800SUN1/ symrdf establish -file pairs -sid 81 -rdfg 80 –nop……………………………………………………………………………………………………………………………………………………………………………………………The RDF 'Incremental Establish' operation successfully initiated for devicefile 'pairs'.

DMX800SUN1/ symrdf establish -file pairs -sid 80 -rdfg 20 -nop……………………………………………………………………………………………………………………………………………………………………………………………The RDF 'Incremental Establish' operation successfully initiated for devicefile 'pairs'.

DMX800SUN2/usr/sengupta/Star/Pairs> symrdf list -sid 81 -cascaded

Symmetrix ID: 000194900181……………………………………………………………………………………………………………………………………………………………………………………………

00C5 00C5 R21:20 ?? WD RW S..2. 0 0 WD RW Synchronized 00C5 R21:80 ?? RW RW A..1. 0 0 RW WD Consistent

00C6 00C6 R21:20 ?? WD RW S..2. 0 0 WD RW Synchronized 00C6 R21:80 ?? RW RW A..1. 0 0 RW WD Consistent R2

R1

R21

RDFG # 20

RDFG # 20

RDFG # 80

RDFG # 80

SID: 194900180

SID: 194900181

SID: 194900182

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.




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.




R22s at Asynchronous SiteDMX800SUN1/usr/sengupta/Star/Pairs> symrdf list -conc -sid 81Symmetrix ID: 000194900181

Local Device View----------------------------------------------------------------------------

STATUS MODES RDF S T A T E SSym RDF --------- ----- R1 Inv R2 Inv ----------------------Dev RDev Typ:G SA RA LNK MDATE Tracks Tracks Dev RDev Pair---- ---- -------- --------- ----- ------- ------- --- ---- -------------

00BD 00BD R21:19 RW WD RW S..2. 0 0 WD RW Synchronized00BD R21:79 RW RW NR C.D1. 0 17250 RW WD Suspended

00BE 00BE R21:19 RW WD RW S..2. 0 0 WD RW Synchronized00BE R21:79 RW RW NR C.D1. 0 17250 RW WD Suspended

DMX800SUN1/usr/sengupta/Star/Pairs> symrdf list -conc -sid 82Symmetrix ID: 000194900182

Local Device View----------------------------------------------------------------------------

STATUS MODES RDF S T A T E SSym RDF --------- ----- R1 Inv R2 Inv ----------------------Dev RDev Typ:G SA RA LNK MDATE Tracks Tracks Dev RDev Pair---- ---- -------- --------- ----- ------- ------- --- ---- -------------

00BD 00BD R2:49 RW WD RW A..2. 0 0 WD RW Consistent00BD R2:79 RW WD NR C.D2. 0 0 WD RW Suspended

00BE 00BE R2:49 RW WD RW A..2. 0 0 WD RW Consistent00BE R2:79 RW WD NR C.D2. 0 0 WD RW Suspended R22

R11

RDFG # 19

RDFG # 19

RDFG # 79

RDFG # 79

SID: 194900180

SID: 194900181

SID: 194900182

R21

# 49

# 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.




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.




Module 2: Underlying Technologies for SRDF/Star


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





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.




SRDF/S Architecture

I/O write received from host/server into source cacheI/O is transmitted to target cache

Receipt acknowledgment is provided by target back to cache of source

Ending status is presented to host/server

SRDF/S links

Source Target

1

4

2

3

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.




SRDF/A Architecture

SRDF/A performs Write Folding, which only sends Transmits of the final writes from the Capture Delta Set

Repeat

Source Target

CaptureTransmitReceiveApply

CAPTURE (N)Collects

application write I/O

TRANSMIT (N-1)Sends final set of writes to target

RECEIVE (N-1)Receives writes from Transmit

Delta Set

APPLY (N-2)Once Receive is complete, data is

applied to disk

SRDF/A’s 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.




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 N-2 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 SymmetrixConfiguration 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.




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. EMC’s 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.




Synchronous SRDF Consistency Groups


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.




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 daemon’s services are necessary. Such a configuration provides redundancy in case one of the daemons stops unexpectedly.




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 splitTF/Clone consistent activationTF/Snap consistent activation

Enginuity Consistency Assist is a feature introduced with Enginuity 5x67. It stalls write I/O to a user-provided 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.




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.




ECA WindowECA 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.




CaptureN+1

TransmitN

CaptureM+1

TransmitM

ReceiveM

ApplyM-1

ReceiveN

ApplyN-1

RDF Daemon and SRDF/S Consistency - 1

A link failure causes Symmetrix to pauses writes to the CG devices in that Symmetrix

Host I/O

Host I/O

Host I/O

Host I/OSRDF LINKS

SRDF LINKS

CG

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

RDF daemon

monitoring

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.





Next, the RDF daemon requests logical link suspension of the remaining devices…

Host I/O

Host I/O

Host I/O

Host I/OSRDF LINKS

SRDF LINKS

CG

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

Daemonsuspends RDF links

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.





leaving the R2 devices dependent-write consistent

Host I/O

Host I/O

Host I/O

Host I/O

SRDF LINKS

SRDF LINKS

CG

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

R1 R2

RDF daemon

monitoring

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.




MSC Cleanup


Describe MSC Cleanup

Describe MSC Cycle Switching





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 discardedNo MSC Cleanup needed

– The receive delta set is completeSymmetrix marks the session as Needing MSC CleanupDisposition 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 it’s all right to commit the delta setIf 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.




RDF Daemon and MSC Cleanup

MSC Cleanup is needed in the bottom Symmetrix only

SRDF LINKS

CaptureN+1

TransmitN

ReceiveN

ApplyN-1Host I/O

SRDF LINKS

CaptureM+1

TransmitM

ReceiveM

ApplyM-1Host I/O

SRDF LINKS

CaptureN+1

TransmitN

ReceiveN

ApplyN-1

SRDF LINKS

CaptureN+1

TransmitN

ReceiveN

ApplyN-1

CG: MSCHost I/O

Host I/O ReceiveDelta SetComplete

ReceiveDelta Set

Incomplete

?RDF

daemonmonitoring

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.




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)

MSC Cleanup Needed Symms must discardA=NMSC Cleanup

NeededA=NNo Cleanup Needed2

A=N-1R=N

A=N

-

B

A=NR=N+1

A=N

A

4

3

1

#

Failure occurred during a cycle switch, all are committed

MSC Cleanup Needed

No Cleanup Needed

All complete, all are committedMSC Cleanup Needed

MSC Cleanup Needed

All discarded, no MSC CleanupNo Cleanup Needed

No Cleanup Needed

ActionR2 SymmR2 Symm

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.




RDF Daemon and MSC Cycle Switching

SRDF LINKS

CaptureN+1

TransmitN

ReceiveN

ApplyN-1Host I/O

SRDF LINKS

CaptureM+1

TransmitM

ReceiveM

ApplyM-1Host I/O

SRDF LINKS

CaptureN

TransmitN-1

ReceiveN-1

ApplyN-2

SRDF LINKS

CaptureN

TransmitN-1

ReceiveN-1

ApplyN-2

CG: MSCHost I/O

Host I/OTime to perform

cycle switch!

RDF daemon

monitoring

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 andthat 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.




Special SRDF and SDDF Features for SRDF/Star


Describe SDDF Features in support of SRDF/Star

Describe SRDF Features in support of Star





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.




SDDF Session Usage in Concurrent Star

R2

R2

R11

Site B – 2 Active SDDF Sessions per each device

SRDF/A

SRDF/S

Passive Link

1001011001001…

0001011100100…

000000000000…

Site C – 1 Inactive SDDF Session per each device

Site A – RDF daemon from control host manages SDDF sessions

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.




Concurrent STAR - When Site A Fails

R2

R2

R11SRDF/A

SRDF/S

Passive Link

1001011001001…

0001011100100…

000000000000…

IOR

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

2 SDDF bitmaps

1 SDDF bitmap

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.




Concurrent STAR – Rolling Disaster

R2

R2

R11

First Failure

Passive Link

1001011001001…

0001011100100…

110011001000…

IOR

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

Second Failure

2 SDDF bitmaps

1 SDDF bitmap IOR

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.




SDDF Session Usage in Cascaded Star

R2

R2

R1

Site B

SRDF/A

SRDF/S

Passive Link

1001011001001…

0001011100100…

000000000000…

Site C – 1 Inactive SDDF Session per each device

Site A – RDF daemon manages 2 Active SDDF sessions 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.




Cascaded STAR - When Site B Fails

R2

R21

R1 SRDF/A

SRDF/S

Passive Link

1001011001001…

0001011100100…

000000000000…

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

2 SDDF bitmaps 1 SDDF bitmap

IOR

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.




Cascaded STAR - When Site A Fails

R2

R21

R1 SRDF/A

SRDF/S

1001011001001…

0001011100100…

000000000000…

SDDF sessions at Site A frozen

Since B and C already have a track table relationship there is no need for SDDF sessions

2 SDDF bitmaps 1 SDDF bitmapPassive Link

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.




Half Delete SRDF Pair

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

Normal Configuration Suspended State

R1 2-WayMir

After half delete

R2R1

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.




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 SWAPNormal Configuration – Suspended State

R1R1

R2R1

AFTER HALF SWAPDuplicate Configuration

R2R1

R1R1

BEFORE HALF SWAPR1and R2 are in duplicate pair state

AFTER HALF SWAPNormal Configuration – Suspended State

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.




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/Star’s ability to switch workload sites without a full refresh.




Module Summary


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





: SRDF/StarModule 2


Give an overview of Star Configurations

Describe the operation of SRDF/Star using concurrent SRDF

Describe a Star configuration using cascaded SRDF





Overview of Star Configurations


List SRDF/Star Configurations using Concurrent and Cascaded SRDF

Describe failure conditions and how they affect SRDF/Star operation





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 industry’s first solution to enable organizations to satisfy those requirements.




The History of SRDF/Star2001: 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 EMC’s 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.




SRDF/Star Using Concurrent SRDF Mode3-site disaster recovery over extended distances

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

SRDF/S< 2

00 km

SRDF/A > 200 km

Workload Site

Nearby Synchronous Target

Short distanceZero data lag

Remote Asynchronous Target

Extended distanceVariable data lag (seconds to minutes)No performance impact

Async Target

Sync Target

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.




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 asynctarget in standby mode

Depending on the nature of the failure, can be reconfigured to concurrent Star

SRDF/S< 2

00 km

SRDF/A > 200 km

Workload Site

Nearby Synchronous Target

Short distanceZero data lag

Remote Asynchronous Target

Extended distanceVariable data lag (seconds to minutes)No performance impact

Async Target

Sync Target

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.




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.




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.




Older Star ConfigurationsConcurrent SRDF/Star Configuration

R2

R2

R11

Symmetrix 1Site A

Symmetrix 3Site C

Symmetrix 2Site B

SRDF/A

SRDF/S

Passive Link

R2

R21

R1

Symmetrix 1Site A

Symmetrix 3Site C

Symmetrix 2Site B

SRDF/A

SRDF/S

Passive Link

Cascaded SRDF/Star Configuration

• 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.




Star Configuration using 5874 and latest 5773Concurrent SRDF/Star Configuration

R22

R21

R11

Symmetrix 1Site A

Symmetrix 3Site C

Symmetrix 2Site B

SRDF/A

SRDF/S

Passive Link

R22

R21

R11

Symmetrix 1Site A

Symmetrix 3Site C

Symmetrix 2Site B

SRDF/A

SRDF/S

Passive Link

Cascaded SRDF/Star Configuration

• 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.




SRDF/Star Failure Scenarios

A - R11 B - R21

C – R22

1 2

4

3 5

6 A - R1 B - R21

C – R22

1 2

4

3 5

6

1. Link failure between A and B2. Site B failure3. Link failure between A and C4. Site C failure5. Link failure between B and C6. Site A failure

Workload Site A Sync Target B

Async Target C

Workload Site A Sync Target B

Async Target C

Concurrent Star Cascaded Star

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.




Concurrent Star Operations After Failure

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

Failure Cases Operation w/o Reconfig Operation w. Reconfig

A - R11

C - R22

A - R11

C - R22

A - R11 B - R21 A – R11 B - R21

C - R22A - R11 B - R21

A - R11

C – R22

B - R21

B – R11

C – R22

B – R21

C – R11

OR

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.




Cascaded Star Operations After Failure

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

C – R22

A – R11 B - R21

A – R11 B - R21

C – R22

A – R11 B - R21

A - R11

C - R22

B - R21

B – R21

C – R11

ORB – R11

C – R22

Failure Cases Operation w/o Reconfig Operation w. Reconfig

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.




Operation of SRDF/Star using Concurrent SRDF


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





Protected

Connected

Disconnected

Star Operational Setup and Normal OperationStar is a Solutions Enabler application – the symstar command

– Provides automation for underlying CLI commands

Create a Composite Group whose consistency will be managed by the RDF daemon, using RDF-ECA and MSCRun setup Three principal operational commands

– symstar connect (establish SRDF)– symstar protect (enable CG)– symstar enable (enable Star protection)

symstar query provides state information – connected, protected, enabled – just like the

commands

Disconnected

connect

Connected

Protected

Star Protected

protect

enable

disconnect

unprotect

disable

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.




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 sitesSpecifying parameters that govern SRDF/Star behaviorCreating the SRDF/Star internal definitions file with help of symstarsetup 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.




Option File on Host at Workload Site - Site AFile sun1star.optSYMCLI_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 = YES

SYMCLI_STAR_COMPATIBILITY_MODE = V70

SYMCLI_STAR_AUTO_DISTRIBUTE_INTERNAL_FILE = Yes

SYMCLI_STAR_SYNCTARGET_RDF_MODE = 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.




Excerpt from Star QueryDMX800SUN1/> symstar query -cg sun1starSite Name : sun1starA

Workload Site : sun1starA1st Target Site : sun1starB2nd Target Site : sun1starC

Composite Group Name : sun1starComposite Group Type : RDF1

Workload Data Image Consistent : YesSystem State:{1st_Target_Site : Disconnected2nd_Target_Site : DisconnectedSTAR : UnprotectedMode of Operation : Concurrent}

Site from which query was issued

Three site names

State determined by RDF pairstates of the RDF devices

Result of specifying concurrentmode during setup

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.




Protected

ConnectedConnected

DisconnectedConnect – Protect – Enable DMX800SUN1/> symstar connect -site sun1starB -cg sun1star -nopDMX800SUN1/> symstar connect -site sun1starC -cg sun1star –nop……………………………………………

System State:{1st_Target_Site : Connected2nd_Target_Site : ConnectedSTAR : UnprotectedMode of Operation : Concurrent}

……………………………………………

DMX800SUN1/> symstar protect -site sun1starB -cg sun1star -nopDMX800SUN1/> symstar protect -site sun1starC -cg sun1star –nop……………………………………………

System State:{1st_Target_Site : Protected2nd_Target_Site : ProtectedSTAR : UnprotectedMode of Operation : Concurrent}

……………………………………………

DMX800SUN1/> symstar enable -cg sun1star -nop……………………………………………

STAR : Protected……………………………………………

Disconnected

connect

Protected

Star Protected

protect

enable

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.




Protected

Connected

Disconnected

Target site fault recovery is managed with the reset command

– symstar reset (MSC cleanup and resets state)

Star Operation after Target Site Transient Fault

PathFail

Star Protected

Disconnected

Connected

Protected

connect

protect

enable

reset

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.




Recovery from Loss of Synchronous Target

After the site returns to service: 1. Issue a site “Reset” 2. Take BCV copies at site B # symstar -cg sun1star reset -site sun1starB –nopromptSystem State:{1st_Target_Site : Disconnected2nd_Target_Site : ProtectedSTAR : UnprotectedMode 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

A - R11 B - R21

C – R22

Query shows Site as PathFail And Star TrippedSystem State:

{1st_Target_Site : PathFail2nd_Target_Site : ProtectedSTAR : TrippedMode of Operation : Concurrent}

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.




Disconnected

DisconnectedDisconnected

Connected

Protected

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

Star Operation After Workload Site Fault

PathFail

PathFail

Star Protected

Disconnected

Connected

Protected

connect

protect

enableFault occurrence

cleanup

Disconnected

Connected

switch(keep local data)

switch(keep remote data)

PathFailCleanReq

PathFail

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.




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 customer’s 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.




Query shows both sites as PathFailSystem State:{1st_Target_Site : PathFail2nd_Target_Site : PathFailSTAR : TrippedMode of Operation : Concurrent}

PathFail

Workload Site Fault: Synch Site More Current

siteloss

A - R11 B - R21

C – R22

ConcStarA

sun1starC

sun1starB

5

6PathFail

Star Protected

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.




Workload Site Disaster: Cleanup Asynch Target

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

cleanupA - R11 B - R2

C - R2

ConcStarA

ConcStarC

ConcStarB

5

6 20

21

PathFail

PathFailCleanReq

PathFail

PathFail

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.




Workload Site Fault: Switch To Synch TargetSwitch production to remote site, sun1starB, keeping local datasymstar 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

switch

PathFailPathFail


A - R11 B – R11

C - R22

ConcStarA

sun1starC

sun1starB

5

6DMX800SUN2/> symstar query -cg sun1starSite Name : sun1starB

Workload Site : sun1starB1st Target Site : sun1starA2nd Target Site : sun1starC……………………………………………………………………………………………..System State:{1st_Target_Site : Disconnected2nd_Target_Site : DisconnectedSTAR : UnprotectedMode of Operation : 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.




Disconnected

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

Wait for invalid track count to reach thresholdSet SRDF mode to asynchronousEnable MSC protection

symstar protect -site sun1starC -nop -cg sun1star

Query shows that Site C is protectedSystem State:{1st_Target_Site : Disconnected2nd_Target_Site : ProtectedSTAR : UnprotectedMode of Operation : Concurrent}

protect


DisconnectedConnected

Protected

connect

B – R11

C - R22sun1starC

sun1starB

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.




Workload Site Problem Resolved: Bring Online

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

A - R11 B – R11

C - R22

sun1starA

sun1starC

sun1starB

A - R21 B – R11

C - R22

sun1starA

sun1starC

sun1starB

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.




Query After Connect - Workload at sun1starBDMX800SUN2/> symstar query -cg sun1starSite Name : sun1starB

Workload Site : sun1starB1st Target Site : sun1starA2nd Target Site : sun1starC


Workload Data Image Consistent : YesSystem State:{1st_Target_Site : Connected2nd_Target_Site : ProtectedSTAR : UnprotectedMode of Operation : 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.




Planned Switch Operation: Command Flow


ConnectedConnected

connect

ProtectedProtected

protect

Star Protected

enable

HaltedHalted

switch

DisconnectedDisconnectedhalt

halt

halt

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.




Planned Switch to sun1starA: Halt Replication

Shutdown applications at Site B, then execute:

symstar halt -cg sun1star –nop

• 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 : Halted2nd_Target_Site : HaltedSTAR : UnprotectedMode of Operation : Concurrent}

halt

Connected

Protected

Halted

Halted

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.




Planned Switch Back to site A

Halt Command issued at sun1starA cause RDF swap between devices at A & B

symstar –cg ConcStar switch –site ConcStarA

switch

A - R11 B - R21

C – R22

sun1starA

sun1starC

sun1starB


Halted

Halted

A - R21 B – R11

C - R22

sun1starA

sun1starC

sun1starB

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.




Query from sun1starA After SwitchDMX800SUN1/usr/sengupta> symstar query -cg sun1starSite Name : sun1starA

Workload Site : sun1starA1st Target Site : sun1starB2nd Target Site : sun1starC


Workload Data Image Consistent : YesSystem State:

{1st_Target_Site : Disconnected2nd_Target_Site : DisconnectedSTAR : UnprotectedMode of Operation : Concurrent}

Last Action Performed : Switch_sun1starALast Action Status : SuccessfulLast Action Timestamp : 11/06/2009_12:03:22

STAR Information:{STAR Consistency Capable : YesSTAR Consistency Mode : NONESynchronous Target Site : sun1starBAsynchronous Target Site : sun1starCDifferential Resync Available : N/AR2 Recoverable : N/AAsynchronous Target Site Data most Current : 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.




SRDF/Star using Cascaded SRDF


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.




Option File on Host at Worklod Site - Site AFile sun1star.optSYMCLI_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 = YES

SYMCLI_STAR_COMPATIBILITY_MODE = V70

SYMCLI_STAR_AUTO_DISTRIBUTE_INTERNAL_FILE = Yes

SYMCLI_STAR_SYNCTARGET_RDF_MODE = 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.




Cascaded Star QueryDMX800LIN1/usr/sengupta/Star> symstar query -cg lin1starSite Name : lin1starA

Workload Site : lin1starA1st Target Site : lin1starB2nd Target Site : lin1starC

Composite Group Name : lin1starComposite Group Type : RDF1

Workload Data Image Consistent : YesSystem State:{1st_Target_Site : Disconnected2nd_Target_Site : DisconnectedSTAR : UnprotectedMode of Operation : Cascaded}

Last Action Performed : SetupLast Action Status : SuccessfulLast Action Timestamp : 11/06/2009_21:53:52

Site from which query was issued

Three site names

Result of specifying cascadedmode during setup

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.




Reconfiguring Cascaded to ConcurrentExample 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 lin1starSite Name : lin1starAWorkload Site : lin1starA1st Target Site : lin1starB2nd Target Site : lin1starCComposite Group Name : lin1starComposite Group Type : RDF1Workload Data Image Consistent : YesSystem State:{1st_Target_Site : Protected2nd_Target_Site : PathFailSTAR : TrippedMode of Operation : Cascaded}

Reconfigure Cascaded Star to Concurrent Starsymstar -cg lin1star reconfigure -reset -site lin1starC -path lin1starA:lin1starC

A – R11 B - R21

C – R22

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.




Concurrent Config can be Star ProtectedDMX800LIN1/usr/sengupta> symstar query –cg lin1starSite Name : lin1starA

Workload Site : lin1starA1st Target Site : lin1starB2nd Target Site : lin1starC

Composite Group Name : lin1starComposite Group Type : RDF1

Workload Data Image Consistent : YesSystem State:

{1st_Target_Site : Protected2nd_Target_Site : DisconnectedSTAR : UnprotectedMode of Operation : 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.




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.




Restrictions for SRDF/Star with EDPWith 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.




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.




Module Summary


Overview of Star Configurations

Operation of SRDF/Star using concurrent SRDF

SRDF/Star configuration using cascaded SRDF





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.

73873740 Srdf Star and Cascaded Srdf Solution Srg

Documents

dev rdev typ

cascaded srdf

providing

key points

reconfigure

dynamic rdf

resolve track

lower cost