symmetrix business continuity management student guide

Symmetrix Business Continuity Management Student Guide

Education Services

August 2009

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

Module 1 - Introduction - 1

© 2009 EMC Corporation. All rights reserved.

Symmetrix Business Continuity ManagementSymmetrix Business Continuity Management

Introduction

Welcome to Symmetrix Business Continuity Management.



© 2009 EMC Corporation. All rights reserved. Module 1 - Introduction - 2

Revision History

CompleteAugust, 20091.0

RevisionsCourse DateRev Number




Symmetrix Business Continuity ManagementProgram Administration

Attendance Roster

Restrooms

Telephones / Etiquette

Attendance Rules

Fire / Evacuation Procedures

Cafeteria

Labs

Local Sites of Interest

Class Evaluations

Symmetrix Business Continuity Management program administration.




Course Objectives

Upon completion of this course, you will be able to:Describe TimeFinder/Clone and TimeFinder/Snap solutions

Use the SYMCLI command set to perform TimeFinder/Clone and TimeFinder/Snap operations

Describe and perform SRDF operations in Synchronous (SRDF/S) and Asynchronous (SRDF/A) modes, for remote replication

Describe and perform SRDF/Automated Replication (SRDF/AR) operations in a single-hop configuration

Describe and perform Open Replicator for Symmetrix (ORS) data replication in Hot/Cold, Push and Pull scenarios

Describe the use of Symmetrix Management Console (SMC) to perform local and remote replication operations

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




Course Agenda

Day 1– Module 1: Introduction and Agenda– Module 2: TimeFinder/Clone Operations– Lab Exercise 1: TimeFinder/Clone– Module 3: TimeFinder/Snap Operations– Lab Exercise 2: TimeFinder/Snap

Day 2– Review Day One Activities– Module 4: SRDF/Synchronous Operations– Lab Exercise 1: SRDF, Initial Set-up and Basic Operations– Lab Exercise 2: SRDF/S Disaster Recovery Operations– Lab Exercise 3: SRDF/S Decision Support Operations

The Agenda for the week, with general timelines for Module presentation and lab exercises is outlined.




Course Agenda

Day 3– Review Day Two Activities– Module 5: SRDF/Asynchronous Operations– Lab Exercise 4: SRDF/A Operations– Lab Exercise 5: Concurrent SRDF– Lab Exercise 6: SRDF/A Multi Session Consistency

Day 4– Review Day Three Activities– Module 6: SRDF/AR – Automated Replication– Lab Exercise 7: SRDF/AR – Single Hop– Module 7: Open Replicator for Symmetrix Operational Details





Course Agenda

Day 5– Review Day Four Activities– Lab Exercise 1: Open Replicator Set Up Lab– Lab Exercise 2: Open Replicator Hot Push– Lab Exercise 3: Open Replicator Hot Pull– Lab Exercise 4: Open Replicator Cold Push– Lab Exercise 5: Open Replicator Cold Pull– Module 8: Symmetrix Management Console (SMC)– Course Wrap-up





This slide intentionally left blank.


Module 2 - TimeFinder/Clone Operations - 1

© 2009 EMC Corporation. All rights reserved. Module 2 - TimeFinder/Clone Operations - 1

Module 2: TimeFinder/Clone Operations

Upon completion of this module, you will be able to:Describe TimeFinder/Clone and possible uses

Identify TimeFinder/Clone Operations

Describe TimeFinder/Clone Emulation mode

Describe Clone from Clone Target

Use the SYMCLI symclone command set to:– Create, Activate, Query and Terminate TimeFinder/Clone

sessions– Recreate, Establish, Restore and Split TimeFinder/Clone

copies

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




TimeFinder/CloneA TimeFinder/Clone provides instant point-in-time copies of SymmetrixDevices:

– Copying can be immediate or deferred (copy on access)

– Copy sessions are maintained on the Symmetrix unit

– Copy sessions can be: Created, Recreated, Restored, Activated, Queried, Listed, and Terminated using the symclone command.

– Data can be copied from a single source device to as many as sixteen target devices, with automatic background copying for up to four target devices simultaneously

– Remote clone is supported with -rdf

Source Host

Target Host

Target

Source

Copy

TimeFinder/Clone is a local replication solution available on the Symmetrix arrays. It allows users to create point-in-time copies of the source devices, on to target devices. The source and target devices can be either Standard or BCVs, provided they are of the emulation (FBA to FBA, CKD to CKD). Unlike TimeFinder/Mirror, the clone copies are immediately available on activation of a clone session, while actual copying of data can occur in the background.




TimeFinder/Clone OperationsCreate

– Create relationship between standard and Clone

Activate– Clone is now active and available immediately for read/write access– Production I/O is processed against standard

Recreate– Clone is re-attached to Standard for new point-in-time copy (incremental/differential)

Establish– Create/recreate and activate

Restore– Re-attached to Standard and incremental or full restore is performed

Split– You can use the symclone split command to split a clone device pair that is in the Restored state.

Terminate– Removes the pairing relationship between the Source and Target devices

The create action defines the copy session requirements and sets the track protection bitmap on the source device to detect which tracks are being accessed by the target host or written to by the source host. The target device is made Not Ready to its host and placed on hold status for copy session activity.

This prevents other control operations from using the device. The activate action makes the clone ready to the host. It also starts one of the background copying processes. The process, Copy-On-Access or Full Copy, depends on the argument used when the clone session was created.

The recreate command allows you to incrementally copy all subsequent changes made to the source device. In other words, it allows you to refresh the contents of the clone with new contents of the source since the clone session has been activated. The restore action restores contents of the clone volume to a restore target.

The establish operation creates and then immediately activates a clone session with a single command.

The terminate action terminates the Source-Target relationship.




TimeFinder/Clone – Options with CreationFull Device Copy (Default with Solutions Enabler 7.0 and above)– Full copy in the background starts after activation

Differential (Default with Solutions Enabler 7.0 and above)– Used with Full Copy or Precopy (implied Full Copy by default)– Required if recreate clone session is planned– Required if incremental restore is planned

CopyOnAccess– Only modified tracks are copied to clone target after activation

Precopy– Full copy in the background starts after creation

CopyOnWrite– Changes the behavior of CopyOnAccess to only copy when writes occur to the source or the

target deviceRecreate Before Copied– No need to wait for a clone copy to complete, before activating a new point-in-time with recreate– Symclone recreate or establish is now permitted while the session is in CopyInProg mode– Recreate is a differential copy (modified tracks copied /unmodified not)

Full Device Copy Option: When the copy session is activated, data copying begins in the background so that a full copy of the data will become available on the target device. This is the default with Solutions Enabler 7.0 and above.Differential Option: This option creates an SDDF (Symmetrix Data Differential Facility) session for maintaining changed track information. Creating a differential clone session automatically implies a Full Device Copy. This is the default with Solutions Enabler 7.0 and above.CopyOnAccess: After activating the copy session, only those tracks that have been written to the source or written/read from the target, will be copied to the target device. A full data copy to the target device will not occur unless all of device tracks are accessed or written to while participating in the active session.Precopy Option: The -precopy option can be used with the create operation to start copying tracks in the background, before the clone session is activated.CopyOnWrite: CopyOnWrite can be enabled by setting the following parameter in the options file ENABLE.SYMAPI_CLONE_COPY_ON_WRITE = ENABLE | DISABLEOnce CopyOnWrite as been enabled and activated, all reads will be handled from the source device and writes to the source device or target device during the active copy session will result in the data being copied to the target device.Recreate Before Copied: This feature allows users to recreate the symclone session before the copy finishes. In prior releases the customer had a problem if there was change in the SRC after the initial clone session. The customer had to wait until the previous copy finished in order to make differential changes. Aborting the original session with terminate would destroy the differential information and require a full copy.




TimeFinder/Clone – Create a Clone SessionTo create a Full Copy session with Differential option:symclone … create …

– Starting with Solutions Enabler 7.0, the default options when creating a clone session are –copy and -differential

To create a Precopy session:symclone … create … –precopy

– To create a –precopy which enable copy from the source to the clone device before the clone session is activated

To create a CopyOnAccess session:symclone … create -nopcopy

– To create a “CopyOnAccess” Clone session: when activated tracks that have been written to the source or written/read from the target will be copied to the target device

The symclone create command:Makes the target not ready (NR) to its hostCreates a differential clone sessionSets up the track protection bitmap to provide user access to data on the target as soon as the clone pair is activatedPuts a hold on the target to prevent other control operations (for example, TimeFinder operations)Data copy from Source to Target begins when the session is activated -precopy starts the copy immediately after the session has been created. Data is copied from the Source to the Target continuously. How ever the target device is Read/Write enabled only on session activation-nocopy creates a session with the Source-Target pair in a CopyOnAccess state




C:\>symclone –g testdg2 create DEV001 sym ld TGT005




Up to sixteen CopyOnAccess sessionsUp to eight concurrent Background Copy sessions

11

22

C:\>symclone –g testdg2 activate DEV001 sym ld TGT008

TargetDEV005

TargetDEV005

TargetDEV006

TargetDEV006 Target

DEV008

TargetDEV008

TargetDEV007

TargetDEV007

STDDEV001

STDDEV001

Controlling Host

Device Group“testdg2”

Host A

Host B

Host C

Host DClone Multiple Copies

Symclone create

Symclone activate

11

22

TimeFinder/Clone – Multiple Clone Copies

Up to 16 clone copies of a standard source device can be created. The Symmetrix array is currently limited to 16 sessions per source device, which can be used for Clone, Snap, or SDDF (Symmetrix Differential Data Facility) operations. This limits the number of available Clone copies that can be created. A total of 16 concurrent CopyOnAccess copy sessions can be created from a standard device (sessions created using the -nocopy option).

Copy sessions created using the -copy option to create full data copies are limited to eight concurrent sessions.




Session Slots Usage

One per SDDF sessionSDDF

One per snap sessionSRDF/A

Two per copy sessionSRDF/Star

One per copy non-differential copy session; two per differential copy session

Open Replicator for Symmetrix

Two per copy sessionTimeFinder/Clone Emulation mode

One per copy non-differential copy session; two per differential copy session

TimeFinder/Clone

One per snap session, and one reserved for restoreMultivirtual Snap

One per snap session, and one reserved for restoreTimeFinder/Snap

Number of sessions slots usedOperation

This slide summarizes the session slots used by the different local and remote replication operations discussed in this course.




The symclone activate command:• Places the target in the Read/Write (RW) state• Initiates data copy, as the default create options are –copy and -differential

• If the session was created with -nocopy option then data copying is deferred until tracks on the source or target are written to

• If session was created with –precopy activation will convert this to a -copy

A user on the target’s host can access data on thetarget even while copying is in progress

Activating a Copy Session

When you issue the symclone activate command, the target is made ready again. A user on the target’s host can then access data on the target immediately:

If the target host attempts to read from, or write to, the tracks on the target that have not been copied yet, those tracks are first copied from the source, preferentially.

If the source host issues a writes to tracks that are not yet copied, those tracks are copied to the target, prior to updating them with the new writes.




Major Activation OptionsNot Ready– The clone volume is placed in NR statesymclone ...activate ... –not_ready

Consistent– Create a consistent image of datasymclone ... activate –consistent

Three methods to execute Consistent Activation:– By specifying -ppath and PowerPath STD devices that hold the

database– By specifying –consistent– By specifying –vxfs for VxFS filesystem (Solaris and HP only)

Consistent activate command -both_sides– For devices with an RDF State of Synchronized– Ability to generate a consistent activate for both the local and

remote Clones at the same time

Not Ready Option: The -not_ready option can be used with the activate action to cause the target device to remain not ready to its host. The copy session will be activated and the target device will be placed in the Not Ready state. The Clone copy can later be read/write enabled to the host using the symld ready command.

Consistent Option: The symclone activate command can be used with the -consistent option to invoke the Enginuity Consistency Assist (ECA) feature. This feature can be used to create Clone copies that are consistent up to the point in time that the activation occurs. The feature suspends writes to the source devices during the activation. When the activation has completed, writes are resumed and the target device contains a consistent copy of the source device at the time of activation.




Consistent Activation using ECA

Host A

Host B

Control Host

SRC

SRC

TGT

TGT

GK

SYMCLI

For consistent activation, there should be a control host with access to only Gatekeeper (GK) devices, or a separate HBA on the production host with access only to GKs and not data devices. This is to ensure that in write intensive environments SYMAPI will be able to freeze and then thaw I/O to the production devices within the ECA window, regardless of the number of outstanding I/Os held by the host HBA accessing the data devices. A device group, composite group or a file must be created on the controlling host. If a single DG, CG or file is created to include all the devices for both Host A and B, then the copy sessions for both Host A and B can be consistently activated with a single command. Alternatively DG, CG or file can be created to include only the relevant devices for Host A and for Host B. In this case copy sessions for each of the hosts can be consistently activated, independent of each other.

A Device Group (DG) is a user created object for viewing and managing related Symmetrix devices. All devices in a device group should be on the same Symmetrix array. There are three types of device groups: REGULAR, R1, and R2. For TimeFinder/Clone and TimeFinder/Snap operations, device group of type REGULAR should be created. The device group definition is stored in the SYMAPI database (symapi_db.bin) on the host where the symdg create command was executed.

A Composite Group (CG) follows the same rules as a DG, except that the devices can span multiple local Symmetrix arrays. If an application uses Symmetrix devices from multiple local Symmetrixarrays, a CG containing all the devices must be created for consistent activation of TimeFinderoperations.

Note: This concept of consistent activation applies to TimeFinder/Snap as well. In the case of TimeFinder/Snap, the target devices (TGT) will be Virtual Devices (VDEV).




Establish a Copy Session

The establish command combines create/recreate and activate into a single command– Makes behavior more similar to TimeFinder/Mirror

Execute create followed by activate– symclone –full establish

Execute recreate followed by activate– symclone establish

Activate options (-consistent, -preaction, etc.), are performed at activate (not create) time– symclone –full establish -consistent

The symclone establish command sets the target device to Not Ready for a short time. Therefore, you may want to unmount the target volume before issuing the command.

An establish operation creates and then activates a new clone session. The clone session created by the establish operation is by default equivalent to a session created with –copy and –differentialoptions. The establish operation can also be performed on an existing differential clone session. In which case, the operation performs recreate and activate operations on the clone session.




Terminate a Copy Session

The symclone terminate command:– Stops a copy session– Removes any hold on the target– Deletes copy session information from the Symmetrix unit

Normal termination is possible whenever a copy pair is in the Created, Copied, CopyOnAccess, Split or Restore state

The syntax is:– symclone ... terminate

Terminating a copy session deletes the pairing information in the Symmetrix array and removes any hold on the target device.

Terminating a session while the device pairs are in the CopyOnAccess or CopyInProg state causes the session to end. If the application has not finished accessing all of the data, the target copy is not a full copy. The symclone terminate command is allowed for all TimeFinder/Clone pair states.

A created / activated copy session may be terminated, but the data on the target device becomes invalid (whether or not data was actually copied to the target). If the state is CopyInProg, then the -symforce option must be applied to terminate the session. This also leaves the target copy as an incomplete copy. If the pair state is Copied, then terminating the session will give a full copy of the data of the target device.




Restore can be done to other standards or the source volumeSession must be created with –copy or –precopy

Session must be activated

Wait until the clone is in a “Copied” stateIssue a symclone restore command

Restore from a TimeFinder/Clone

You can use the symclone restore command to copy target data to another device (full restore), or back to the original source device (incremental restore).

In the case of a full restore (-full), the original session terminates and a copy session to the target of the restore starts.

In the case of an incremental restore, the original session terminates and an incremental copy session back to the original source device starts.

To support this operation, the session must have been created with the default options and the device must be in a fully copied state.




symclone create -tgt

symclone activate –consistent -tgt

22

symclone query33

Source HostHost A

Target HostHost B

symdg create clonedg

set SYMCLI_DG=clonedg

symld addall dev –range 13D:13E

symld addall dev –range 0F9:0FA -tgt

11

SourceDEV001

13D

TargetTGT001

0F9

TargetTGT002

0FA

TimeFinder/Clone Operations

SourceDEV002

13E

Device Groupclonedg11

22

A SYMCLI device group – clonedg is created. Next 2 source devices (13D and 13E) are added to the group. Two target devices (0F9 and 0FA) are added. Note the use of the –tgt flag. This designates 0F9 and 0FA as Targets for the clone sessions.

Clone session is then created and activated. Again note the use of –tgt flag with the create and activate commands.

After activation the device group is queried to determine the status of the clone sessions between devices in the group.




Show Device Group

C:\>symdg show clonedg|more

Standard (STD) Devices (2):

--------------------------------------------------------------------

Sym Cap

LdevName PdevName Dev Att. Sts (MB)

--------------------------------------------------------------------

DEV001 \\.\PHYSICALDRIVE5 013D RW 1078

DEV002 \\.\PHYSICALDRIVE6 013E RW 1078

TGT Devices Locally-associated (2):

--------------------------------------------------------------------

Sym Cap


--------------------------------------------------------------------

TGT001 N/A 00F9 RW 1078

TGT002 N/A 00FA RW 1078

The command has been executed from the Source host. Hence the source devices 13D and 13E have Physical Device Names (PdevName) and the target devices 0F9 and 0FA do not. As the target devices were added with the –tgt flag, they have been given Logical Device names of TGT001 and TGT002 respectively. The output from the command has been edited to fit the slide. The complete output is more verbose than shown here. Also note that the target devices are currently in Read/Write status, as they have been just added to the device group.




Creating the Clone SessionC:\>symclone create -tgt

Execute 'Create' operation for device group

'clonedg' (y/[n]) ? y

'Create' operation execution is in progress for

device group 'clonedg'. Please wait...

'Create' operation successfully executed for device group

'clonedg'.

C:\>symdev list -held

00F9 Not Visible ***:* 08A:C3 2-Way Mir Grp'd NR

00FA Not Visible ***:* 08C:C3 2-Way Mir Grp'd NR

The symclone create action defines the clone copy session requirements and sets the track protection bitmap on the source device to detect which tracks are being accessed by the target host or written to by the source host. The target device is made Not Ready to its host and placed on hold status for clone copy session activity. This prevents other control operations from using the device. The clone copy does not become accessible to its host until the copy session is activated. The output has been edited to fit the slide. Note that the target devices have been moved to a Not Ready state (NR) upon Clone session creation. They will be in a held state until the Clone session is terminated.




Querying the Clone SessionC:\>symclone query

Device Group (DG) Name: clonedg

DG's Type : REGULAR

DG's Symmetrix ID : 000194900180

Source Device Target Device State Copy

--------------------------------- ---------------------------- ------------ ----

Protected Modified Modified

Logical Sym Tracks Tracks Logical Sym Tracks CGDP SRC <=> TGT (%)

--------------------------------- ---------------------------- ------------ ----

DEV001 013D 17250 0 TGT001 00F9 0 XXX. Created 0

DEV002 013E 17250 0 TGT002 00FA 0 XXX. Created 0

Total -------- -------- --------

Track(s) 34500 0 0

MB(s) 2156.3 0.0 0.0

Query of the clone session shows that the session has been created. No tracks have yet been copied as indicated by 0 % copied. With Solutions Enabler 7.0, the default options for the create command are –copy and –differential. This can be verified under the CGDP columns. As the legend below indicates, the sessions have been created with background copy and differential options, event though these were not explicitly specified when creating the session. The source devices and the target devices belong to the same device group in our example. Hence an X under the G column of the output. If copying at creation is required then the –precopy flag should have been entered during the create operation. If PreCopy is desired now, then symclone set mode precopy –tgt can be executed. This will start the precopy operation. After creating the clone session with the default options, the set mode precopy is the only operation possible to change the nature of the copyprocess. i.e set mode nocopy cannot be issued. Legend:

(C): X = The background copy setting is active for this pair.

. = The background copy setting is not active for this pair.

(G): X = The Target device is associated with this group.

. = The Target device is not associated with this group.

(D): X = The Clone session is a differential copy session.

. = The Clone session is not a differential copy session.

(P): X = The pre-copy operation has completed one cycle

. = The pre-copy operation has not completed one cycle




Listing the Existing Clone SessionsC:\>symclone set mode precopy –tgt -nop

C:\>symclone list

Symmetrix ID: 000194900180

Source Device Target Device Status

------------------------- ---------------------- -------------

Protected

Sym Tracks Sym CGDP SRC <=> TGT

------------------------- ---------------------- -------------

013D 0 00F9 XXXX PreCopy

013E 0 00FA XXXX PreCopy

Total --------

Tracks 0

MB(s) 0.0

The symclone list command will show all the clone session in the Symmetrix.As the symclone set mode precopy –tgt has been issued, the Status now reflects PreCopy as well.

Legend:



(G): X = The Target device is associated with a group.

. = The Target device is not associated with a group.

(D): X = The Clone session is a differential copy session.

. = The Clone session is not a differential copy session.

(P): X = The pre-copy operation has completed one cycle

. = The pre-copy operation has not completed one cycle




Activating the Clone Session

C:\>symclone activate -consistent -tgt

Execute 'Activate' operation for device group


'Activate' operation execution is in progress for


'Activate' operation successfully executed for device group

'clonedg'.

This activates the copy operation from the source device to the target device.

The symclone activate command can be used with the -consistent option to invoke the EnginuityConsistency Assist (ECA) feature. This feature can be used to create clone copies that are consistent with the database up to the point in time that the activation occurs. The feature suspends writes to the source devices during the activation.

When the activation has completed, writes are resumed and the target device contains a consistent production database copy of the source device at the time of activation.

Note:

Cloned data is made available as a point-in-time copy at the time of activation and not at the time that the session was created.




Querying the Clone SessionC:\>symclone query


DG's Type : REGULAR



--------------------------------- ---------------------------- ------------ ----



--------------------------------- ---------------------------- ------------ ----

DEV001 013D 0 0 TGT001 00F9 0 XXX. Copied 100

DEV002 013E 0 0 TGT002 00FA 0 XXX. Copied 100

Total -------- -------- --------

Track(s) 0 0 0

MB(s) 0.0 0.0 0.0

Performing the symclone query command shows the options with which the clone session has been created and activated. The current state for these pairs is “Copied”.




Recreating the Clone SessionC:\>symclone recreate -tgt

Execute 'Recreate' operation for device group


'Recreate' operation execution is in progress for


'Recreate' operation successfully initiated for device group

'clonedg'.

C:\>symclone query


--------------------------------- ---------------------------- ------------ ----



--------------------------------- ---------------------------- ------------ ----

DEV001 013D 0 0 TGT001 00F9 0 XXX. Recreated 100

DEV002 013E 0 0 TGT002 00FA 0 XXX. Recreated 100

The symclone recreate command allows you to incrementally copy all subsequent changesmade to the source device (made after the point-in-time copy initiated) to the target device.

To recreate the clone session, it should have been first created with either the -copy or -precopyoption, and the -differential option. While in the Recreated state, the target device remains Not Ready to the host. After the recreate operation, the session can be activated to initiate a new point-in-time (differential) copy of the data.

Note that the query output has been truncated to show just the relevant information.




Terminating the Clone SessionC:\>symclone terminate -tgt

Execute 'Terminate' operation for device group


'Terminate' operation execution is in progress for


'Terminate' operation successfully executed for device group

'clonedg'.

C:\>symclone query

The Source device and the Target device do not form a Copy session

Device group 'clonedg' does not have any devices that are Clone source devices

Terminating a copy session deletes the pairing information in the Symmetrix array and removes any hold on the target device. Terminating a session while the device pairs are in the CopyOnAccess or CopyInProg state causes the session to end. If the application has not finished accessing all of the data, the target copy is not a full copy. The symclone terminate command is allowed for all TimeFinder/Clone pair states.

Note:

A created and activated copy session may be terminated, but the data on the target device is not valid unless the state had previously been COPIED.




Establishing a Clone SessionC:\>symclone establish -full -tgt

Execute 'Clone Full Establish' operation for device group


'Clone Full Establish' operation execution is in progress for


'Clone Full Establish' operation successfully executed for device group

'clonedg'.

The establish command combines the create and activate steps into a single operation. The clone session is created and immediately activated. The first time an establish operation is performed, the –full option has to be specified.

Note:

The symclone establish command sets the target device to Not Ready for a short time, prior to activation. Therefore, the target volumes should be umounted from the target host, to avoid any undesired effects. Upon command completion, the target volumes can be mounted back again.




Querying an Established SessionC:\>symclone query


DG's Type : REGULAR



--------------------------------- ---------------------------- ------------ ----



--------------------------------- ---------------------------- ------------ ----

DEV001 013D 5247 0 TGT001 00F9 0 XXX. CopyInProg 69

DEV002 013E 4550 0 TGT002 00FA 0 XXX. CopyInProg 73

Total -------- -------- --------

Track(s) 9797 0 0

MB(s) 612.3 0.0 0.0

Background copy is initiated once the symclone establish command is issued.




Concurrent Multiple Clone SessionsC:\>symdg show clonedg





{

--------------------------------------------------------------------

Sym Cap


--------------------------------------------------------------------

TGT001 N/A 00F9 RW 1078

TGT002 N/A 00FA RW 1078

TGT003 N/A 00FB RW 1078

TGT004 N/A 00FC RW 1078

}

In this example, two additional devices (0FB and 0FC) have been added to the device group. Standard Devices can now be paired with two sets of Target Devices to obtain two concurrent clone copies.




Creating the First Clone SessionC:\>symclone create -tgt

Execute 'Create' operation for device group


'Create' operation execution is in progress for


'Create' operation successfully executed for device group

'clonedg'.

C:\>symclone query -multi


--------------------------------- ---------------------------- ------------ ----

DEV001 013D 17250 0 TGT001 00F9 0 XXX. Created 0

DEV002 013E 17250 0 TGT002 00FA 0 XXX. Created 0

A clone session is first created between 13D:13E and 0F9:0FA device pairs




Creating the Second Clone SessionC:\>symclone create -tgt –concurrent -nop



DG's Type : REGULAR



--------------------------------- ---------------------------- ------------ ----



--------------------------------- ---------------------------- ------------ ----

DEV001 013D 17250 0 TGT003 00FB 0 XXX. Created 0

17250 0 TGT001 00F9 0 XXX. Created 0

DEV002 013E 17250 0 TGT004 00FC 0 XXX. Created 0

17250 0 TGT002 00FA 0 XXX. Created 0

With the –concurrent option in the create operation, a second clone session is created between device pairs 13D:13E and 0FB:0FC. To list all the clone sessions for the standard devices, the –multi option is used in the query command.




Concurrent Activation of Both Clone SessionsC:\>symclone activate -consistent -tgt DEV001 sym ld TGT001 DEV001 sym ld TGT003

DEV002 sym ld TGT002 DEV002 sym ld TGT004



DG's Type : REGULAR



--------------------------------- ---------------------------- ------------ ----



--------------------------------- ---------------------------- ------------ ----

DEV001 013D 0 0 TGT001 00F9 0 XXX. Copied 100

0 0 TGT003 00FB 0 XXX. Copied 100

DEV002 013E 0 0 TGT002 00FA 0 XXX. Copied 100

0 0 TGT004 00FC 0 XXX. Copied 100

To activate all clone sessions concurrently, the device pairings have to be specified exactly in the command as shown in this example.




Restoring from a Clone TargetC:\>symclone restore -tgt

Execute 'Incremental Restore' operation for device group


'Incremental Restore' operation execution is in progress for


'Incremental Restore' operation successfully initiated for device group

'clonedg'.

C:\>symclone query


--------------------------------- ---------------------------- ------------ ----



--------------------------------- ---------------------------- ------------ ----

DEV001 013D 0 0 TGT001 00F9 0 XXX. Restored 100

DEV002 013E 0 0 TGT002 00FA 0 XXX. Restored 100

symclone restore command can be used to copy target data to another device, or back to the original source device. If data is restored to the original source devices then the operation is incremental as shown in this example.

In the case of an incremental restore, the original session terminates and an incremental copy session back to the original source device starts. To support this operation, the session must have been created with the -differential option and the device must be in a fully copied state.

If data is restored to another device, then the original clone session has to be terminated (symclone terminate –tgt) and a full restore operation to the new device should be initiated (symclone restore –full –tgt).




Recreating from a Restored StateC:\>symclone split –tgt -nop

C:\>symclone query


DG's Type : REGULAR



--------------------------------- ---------------------------- ------------ ----



--------------------------------- ---------------------------- ------------ ----

DEV001 013D 0 0 TGT001 00F9 0 XXX. Split 100

DEV002 013E 0 0 TGT002 00FA 0 XXX. Split 100

To recreate the clone session between the original source and target device pairs, the restored session should be first split. Next the clone session can be recreated and activated.

symclone recreate –tgt

symclone activate –tgt




TimeFinder/Clone Emulation ModeUnder Clone Emulation mode TimeFinder/Mirror commands are automatically converted to TimeFinder/Clone commands– symmir commands are converted

to symclone commands

With Enginuity™ Version 5874 and above, all TimeFinder/Mirror commands will run under Clone Emulation mode, regardless of BCV protection type (RAID-1, RAID-5, or RAID-6)

symmircommandssymmir

commands

symclonecommandssymclone

commands

Prior to Enginuity™ Version 5874, if TimeFinder/Mirror command is executed for a STD-BCV(RAID-5 or RAID-6) pair, the symmir commands were automatically converted to symclone commands (transparent to the user). If TimeFinder/Mirror command is executed for a STD-BCV(RAID-1) pair, and if Clone operation is desired, then the environment variable

SYMCLI_CLONE_EMULATION should be set to ENABLED. In a mixed environment with BCV (RAID-1 and RIAD-5 or RAID-6), if the environment variable is set to DISABLED (default), then TimeFinder/Mirror operations on the BCV(RAID-5) will fail.

With Enginuity™ Version 5874 and above, all TimeFinder/Mirror commands are converted to TimeFinder/Clone commands. The environment variable is not explicitly set to ENABLED any more.




INCREMENTAL RESTOREINCREMENTAL RESTORE

TimeFinder/Clone Commands

TimeFinder/Mirror Commands

ACTIVATESPLIT

TERMINATECANCEL

FULL RESTOREFULL RESTORE

RECREATE (with pre-copy)INCREMENTAL ESTABLISH

CREATE (with pre-copy)FULL ESTABLISH

Mapping of TimeFinder/Mirror Commands to TimeFinder/Clone Commands

In the Clone Emulation mode, the TimeFinder/Mirror reverse split option is not allowed (symmir split –reverse). Restore operations will always be protected. The SYMAPI_DEFAULT_BCV_SPLIT_TYPE, SYMAPI_DEFAULT_BCV_RESTORE_TYPE, SYMAPI_DEFAULT_BCV_ESTABLISH_TYPE option file settings are ignored. Also the maximum number of BCVs that can be incrementally established with a Standard device is 8, instead of the 16 allowed by TimeFinder/Mirror.




Clone Emulation ExampleC:\>symdev list –raid1

0111 Not Visible ***:* 07B:D4 2-Way BCV Mir Asst'd RW 1078

C:\>symdev list –raid5

0119 Not Visible ***:* 07B:D4 BCV+R-5 Asst'd RW 1078

C:\>symdg show mirrordg



DEV001 \\.\PHYSICALDRIVE9 0141 RW 1078


BCV Devices Locally-associated (2):

Sym Cap


--------------------------------------------------------------------

BCV001 N/A 0111 RW 1078

BCV002 N/A 0119 RW 1078

In this example two STD devices 141:142 have been added to the device group mirrordg and one BCV(RAID-1) device (111) and one BCV(RAID-5) device have been associated with the device group. Note that the output from symdg show mirrordg has been edited to show just the relevant information for our purpose.




Clone Emulation Example (continued)C:\>symmir –g mirrordg establish –full

C:\>symdev show 111

BCV Pair Information

{

BCV Device Symmetrix Name : 0111

BCV Device Serial ID : Not Visible

BCV Device Associated Group Name : mirrordg

BCV Device Associated CG Name : Not/Associated

BCV Device Status : Not Ready (NR BCV)

State of Pair ( STD ====> BCV ) : Synchronized

Percent Initiated : 100%

Time of Last BCV Action : Wed May 27 15:59:54 2009

State of BCV Mirrors : Synchronized

BCV State Flags : (CantRevSpl)(AllReady)(Emulation)

With Enginuity Version 5874, the TimeFinder/Mirror establish command is automatically converted to Clone Emulation mode even for a BCV(RAID-1). The only way to display that Emulation mode is active, is to perform a symdev show on the device(s) of interest. As can be seen in the BCV State Flags field – Emulation is in action and as mentioned earlier, one cannot perform TimeFinder/Mirror reverse split operation in Emulation mode {CantRevSpl}.




TimeFinder/Clone with Thin Devices

Source and Target Devices must be Thin

Thin clone targets may be accessed just as normally as regular clone targets

Since there is no device type “Thin BCV” clone targets are addressed by– using the –tgt option with a device group– explicit pairing via a device group or a device file

Space is not consumed on Clone target device until writes are directed to the source

TimeFinder/Clone can be used to create point-in-time copies of thin devices on other thin devices. Other than the requirement that both the source and target device be thin, creating clones of thin devices is exactly the same as creating clones of regular devices. Thin clones can be presented to a host and accessed just like regular devices or clone source devices. Thin clone targets can also be updated and the changes on the targets can be restored back to the source thin devices or to different thin devices.

Thin devices are classified as standard devices and can be added to Symmetrix device groups or put in device files. When using device groups, clone operations can be performed against devices by specifying the clone source and target when the clone pairs are created or clone targets can instead be added as targets by specifying the –tgt option when they are added to the group.




Clone from Clone Target

Then…If…

STDSTDSTD

A

BCVSTDSTD

B

STDBCVSTDC

EMULATIONCLONE

A B B CCLONE CLONE

EMULATION CLONE

With Enginuity 5874– A B (BCV) TimeFinder/Mirror commands will be Clone emulation; BCV

devices can still be created– When A B is active, changes have been made to permit B to be

Source for another Clone session – namely B C– Clone from Clone Target will be permitted in Enginuity 5874

Table: Clone and Emulation combinations under different device configurations

With the new feature, A B, and B C can be simultaneously in a Pre Copy mode. So data can flow from A B and then on from B C. Hence the term Cascaded TimeFinder/Clone. When both clone sessions have completed one precopy cycle, A B can be activated. After A B reach the copied state, B

C session can be activated.

With Enginuity 5874, all TimeFinder/Mirror commands will be in emulation mode. Native TimeFinder/Mirror functionality is removed. As the table shows, whenever a TF/Mirror functionality is called, it will be translated to emulation.




Clone from BCVC:\>symmir -g mirrordg split –consistent

C:\>symclone -g bcvclonedg create BCV001 sym ld TGT001 BCV002 sym ld TGT002

C:\>symclone -g bcvclonedg activate BCV001 sym ld TGT001 BCV002 sym ld TGT002

C:\>symclone list



------------------------- ---------------------- -------------

Protected


------------------------- ---------------------- -------------

0111 0 00FD XXX. Copied

0119 0 00FE XXX. Copied

Continuing with the previous example of Clone Emulation, the BCV devices in the device group mirrordg can be split. The BCV devices can now be used as Source devices for a Clone session. In this example BCV devices 111 and 119 act as Source for the Clone Targets 0FD and 0FE. The TimeFinder/Mirror split is equivalent to the TimeFinder/Clone activate operation. So the Emulated Clone session between the STD and BCV devices is in an “active” state when the BCV devices are used as Source for the Clone session. The clone session can now be terminated, data can be incrementally copied from the STD to the BCV (in Clone Emulation mode again). As the Clone session from the BCV devices as Source has been terminated, if the BCV devices should again be used as Clone Source, the Clone session cannot be incremental. In other words, symclone recreatecannot be used. So the sequence for iteration would be:symmir establish –full (STD: 141, 142 ; BCV: 111, 119 – in Emulation Mode)

symmir split –consistent (equivalent to symclone activate)

symclone create (BCV: 111, 119 ; TGT: 0FD, 0FE – Native Clone)

symclone terminate (BCV: 111, 119 ; TGT: 0FD, 0FE – Native Clone)

symmir establish (STD: 141, 142 ; BCV: 111, 119 – in Emulation Mode – incremental establish)symmir split –consistent (equivalent to symclone activate)

symclone create (BCV: 111, 119 ; TGT: 0FD, 0FE – Native Clone)

symclone terminate (BCV: 111, 119 ; TGT: 0FD, 0FE – Native Clone)




Clone from CloneC:\>symdg show clone_a_to_b


Sym Cap


--------------------------------------------------------------------




Sym Cap


--------------------------------------------------------------------

TGT001 N/A 00F9 RW 1078

TGT002 N/A 00FA RW 1078

The edited output of the symdg show command, shows that STD devices 13D:13E are paired with STD devices 0F9:0FA (added as targets to the device group), in the device group clone_a_to_b




Clone from Clone (continued)C:\>symdg show clone_b_to_c


Sym Cap


--------------------------------------------------------------------

DEV001 N/A 00F9 RW 1078

DEV002 N/A 00FA RW 1078


Sym Cap


--------------------------------------------------------------------

TGT001 N/A 00FB RW 1078

TGT002 N/A 00FC RW 1078

The edited output of the symdg show command, shows that the Clone targets in device group clone_a_to_b devices 0F9:0FA are now added as Source devices and are paired with STD devices 0FB:0FC (added as targets to the device group), in the device group clone_b_to_c. Note that in order to add the same set of devices to multiple device groups (on the same host), the SYMAPI variable SYMAPI_ALLOW_DEV_IN_MULT_GRPS must be set to ENABLE in the SYMAPI options file.




Creating the Clone SessionsC:\>symclone create -g clone_a_to_b -tgt –nop

C:\>symclone create -g clone_b_to_c -tgt –nop

C:\>symclone list



------------------------- ---------------------- -------------

Protected


------------------------- ---------------------- -------------

013D 17250 00F9 XXX. Created

013E 17250 00FA XXX. Created

00F9 17250 00FB XXX. Created

00FA 17250 00FC XXX. Created

Total --------

Tracks 69000

MB(s) 4312.5

As all devices involved are STD devices, the Clone sessions are all Native (not Emulation Mode). Notice that Enginuity 5874 now permits the Target of one Clone session (F9:FA) to be the Source for another Clone session, without having to terminate the first session.




Activating the Clone SessionsC:\>symclone activate -g clone_a_to_b -tgt –nop


device group 'clone_a_to_b'. Please wait...

'Activate' operation successfully executed for device group

'clone_a_to_b'.

C:\>symclone activate -g clone_b_to_c -tgt –nop


device group 'clone_b_to_c'. Please wait...

The requested action cannot be performed in the current state of one or more devices

After activating the session for devices in clone_a_to_b, if an activate is attempted for the devices in clone_b_to_c, the operation fails. This is because, while both sessions can simultaneously be in “Created” state, only on of them can be actively copying at any time. In this case we have to wait for devices in clone_a_to_b to reach a “Copied” state before successfully activating the session for devices in clone_b_to_c.




Session States When Both Sessions are Clones

Note: When A B is in a copied state, we cannot simultaneously do a C B restore. This would make B a target of two simultaneous copy sessions.

Created Precopy CopyInProgSession

B C

A B

X ( )(X)

This table indicates that both sessions can be simultaneously in Created or in Precopy mode, when both sessions are Native Clones. However, if one session is in CopyInProg, the other session cannot be simultaneously in CopyInProg as well.




Copying to Larger Targets

Requires the SYMCLI environment variable– SYMCLI_CLONE_LARGER_TGT=ENABLED

Source to larger target copying is allowed; but restore from the larger target is not allowed; useful for data migration only

Can be created and activated as full copy session only; Differential copy sessions not allowed

Concatenated metadevices are not supported

If using striped metadevices, the source and target should have the same number of meta members– Target members can be larger than the source members

This slide lists some of the considerations for cloning a source devices to larger target devices. Logical Volume Manager structures along with the data will be copied from the Source device to the larger Target device. As a result, even though the Target device is physically larger, the host may not recognize this until platform specific LVM actions are completed.




TimeFinder/Clone Restore and SRDF Restore

Allows SRDF restore to be initiated when TimeFinder/Clone restore is in progress

– SRDF restore will be allowed for both TimeFinder/Clone as well as Clone emulation

Enginuity 5874

When Clone restore to R2 is in progress, an SRDF restore could not be initiated

– Have to wait for Clone restore to complete before starting the SRDF restore

– With native TimeFinder/Mirror, an SRDF restore can be initiated when the BCV restore to R2 is in progress

Prior to Enginuity 5874

The difference in the behavior of SRDF restore between TimeFinder/Mirror and TimeFinder/Clone restores to R2, causes an incompatibility. With 5874, all TimeFinder/Mirror commands will now be Clone emulation. So, the existing functionality of concurrent TimeFinder/Mirror restore to R2 and SRDF restore, will break. Enginuity 5874 has been changed to accommodate to allow SRDF restore from R2 to R1, while the TimeFinder/Clone restore to R2 is in progress.




Module Summary

Key points covered in this module:

Described TimeFinder/Clone and possible uses

Identified TimeFinder/Clone Operations

Described TimeFinder/Clone Emulation mode

Described Clone from Clone Target

Used the SYMCLI symclone command set to:– Create, Activate, Query and Terminate TimeFinder/Clone sessions– Recreate, Establish, Restore and Split TimeFinder/Clone sessions

These are the key points covered in this module. Please take a moment to review them.


Module 3 - TimeFinder/Snap Operations - 1

© 2009 EMC Corporation. All rights reserved. Module 3 - TimeFinder/Snap Operations - 1

Module 3: TimeFinder/Snap Operations

Upon completion of this module, you will be able to:

Describe TimeFinder/Snap functionality

Describe TimeFinder/Snap “Copy on First Write” process

Describe the Create, Activate, Terminate and Restore TimeFinder/Snap operations

Identify and describe Virtual Devices used for TimeFinder/Snap operations

Describe the SYMCLI symsnap command set to Monitor, Create, Activate, and Query TimeFinder/Snap sessions





TimeFinder/Snap creates “logical”point-in-time images of a source volume

Requires only a fraction of the source volume’s capacity

Up to 128 Snap sessions can be created from a source volume and are available immediately

Complements TimeFinder/Clone and provides unmatched replication flexibility

VDEV Device

Production Host A

Target Host B

ProductionVolume

Snap SavePool

ProductionSnapshot

----Pointers onThe VDEV

TimeFinder/Snap

TimeFinder/Snap creates space-saving, logical point-in-time images. The Snaps are not a full copies of data; they are logical images of the original information, based on the time the Snap was created. A set of pointers to the source volume data tracks is created upon activation of the Snap. These pointers are stored in the Virtual Device. Target host is given access to the Virtual Device.

The default maximum number of Snaps is 16. If a restore from a Snap is planned, one session is reserved for the restore session. This reduces the default maximum number of Snaps to 15.

Setting the following SYMCLI environment variable: SYMCLI_MULTI_VIRTUAL_SNAP = ENABLED, increases the maximum number of Snap sessions to 128.




SourceR/W

R/WTargetBackupHost

Controlling Production

HostPointers from

Virtual to Original Data

Original Data Copied to Snap Pool

“CopyOnFirstWrite”

ProductionVolume

VDEV Device

Snap SavePool

Target

TimeFinder/Snap Operations Overview

TimeFinder/Snap functionality is managed via copy sessions, which pair the source and target devices. Sessions are maintained on the Symmetrix array and can be queried to verify the current state of devices.

A copy session must first be Created that defines the Snap devices in the copy operation. When the session is subsequently activated, the target virtual devices then become accessible to its host. When sessions are no longer required they can be terminated.

Snap operations are controlled from the host by using the symsnap command to create, activate, terminate, and restore the Snap copy sessions.




TimeFinder/Snap

TimeFinder/Snap captures a point-in-time view of a source volume by copying only the original data prior to it being changed on the source device or the target device:– The target is a virtual device that contains pointers to tracks on the

original source data– The target can be mounted like any other volume– Copying only occurs when there are writes to the source

or target– Only the original data that has to be changed is copied to a SAVE

device, consuming a fraction of the space required to copy the entire source

– Copying is controlled by copy sessions, which are created, activated, queried, listed, and terminated using the symsnap command

TimeFinder/Snap allows you to make copies of data simultaneously on multiple target devices from a single source device. The data is available to a target host instantly. This source device can be a Standard or a BCV device. (BCV in a Split State). A target device is a virtual device (VDEV) that consumes no physical storage.




Once the TimeFinder/Snap session is activated– The first time a track on the source is written to, the original data on the

source is copied to the save device, the VDEV pointer is changed to point to the save device; “then” the source is changed.

– “Copy on First Write” applies to writes to the VDEV as well.

Source Vol Save Device

Modified Tracks / Original Data

VDEV deviceContains Pointers to the

Original Data

0

000

1000

1

Snap SavePool

Production Host A Target

Host B

TimeFinder/Snap – Copying Data

TimeFinder/Snap uses a process called “Copy on First Write” when a Snap session is activated. When a host attempts to write to a track on the Source volume for the first time after activation, the original track is copied from the Source volume to the Save Area, the pointer is updated to reference the Save Area, then the Source volume is updated with the new write. Subsequent writes to the same track on the Source volume will not invoke a data copy. Likewise, when a write is issued to a track on the VDEV for the first time, the original data is copied from the Source volume to the Save Area, the pointer is updated, and the new write to the VDEV is stored in the Save Area.




The copy-on-write is repeated every time a different track on the source is first written to

Tracks are striped in a round-robin manner to the Save Devices to improve performance

Source Virtual Device Save Pool

Host A

Host B

VDEV

Original Data

Modified Tracks

Striping the Save Device

The save pool device is not host accessible, but accessed only through the virtual devices that point to it. Save devices provide a pool of physical space to store snap-copy data to which virtual devices point.

Tracks are striped in a round-robin manner to save devices to improve performance. When savedevs are configured across the backend, they are separated first by director, then channel, and then by disk.




Terminating a Copy Session

When a Copy Session is Terminated:– The virtual device is made not ready– Tracks on the save device(s) are reclaimed if they are not

referenced by any other copy session– The copy session structures are freed-up

Source Virtual Device Save Pool

Host A

Host B

VDEV

As sessions are terminated, the space in the Save Area is released and available for re-use by other snap sessions.




DEV001

DEV001

VDEV001

ControllingHost Source VDEV001

Host B Target

Device Group(1) ProdDB

Device Group(2) BackupDB

Host A Source

“Default” Pool

“Training” Pool

Multiple Save Device Pools

Symmetrix SAVE devices are specially configured devices (not mapped to the host) that provide pooled physical storage space used to store pre-update images or changed tracks during a virtual copy session. Multiple named SAVE device pools can be created and sessions can be specified to use a specific SAVE pool

Save Area capacity can also be allocated based on application requirements. For example:Allocate more space for Write-intensive applicationsAllocate more space for long duration snapshots

The -svp option can be used with the create action to specify which SAVE device pool to use for an operation.




Consistent ActivationFour methods to execute “Consistent Activation”Specify -ppath and PowerPath STD devices that hold the database– Specific devices; supply the device name– All devices using keyword SRCDEVS– Use –rdb for automatic mapping of DB devices

Specify –consistent

Specify –vxfs for VxFS filesystem (Solaris and HP only)

Consistent activate command -both_sides– For devices with an RDF State of Synchronized– Ability to generate a consistent activate for both the local and remote

VDEVS at the same time

There are four types of consistent activation available; each offers a restartable copy on target VDEVs: PowerPathECAVeritas File System-both_sides




Common Snap operations:– Create– Activate – Restore – Terminate– Recreate VDEV Device

Production Host A

Target Host B

ProductionVolume

Snap SavePool

Snapshot ofProduction

testdg3

symsnap Operations




Configuration Considerations

Cache– There is some additional cache required for TimeFinder Snap

snapshots– Total number of VDEVs (snapshots) must be accounted for in cache

calculations

VDEV (snapshots)– Are persistent– Cache only devices– Consume SYM device ID– Are not convertible to / from other device types

Additional Cache is required for Snap snapshots. The number of VDEVs must be included in cache calculations.

VDEVs can be configured using Symmetrix Management Console or SYMCLI. VDEVs take device IDs.




Configuration Considerations (continued)

SaveDev (Save Area)– SaveDevs should be spread over as many physical volumes as

possible

SaveDev (Save Area) Monitoring– SaveDev thresholds can be set and notifications can be sent– SaveDev can be added dynamically– When Save Area fills, sessions that require free tracks in the Save

Pool are placed in a failed stated

For best performance the Save Devices should be spread across as many physical volumes as possible. When the Save Area is full, any active session that requires a free track in the Save Pool will be placed in a failed state. This is because, the original data has to be copied to the Save Area before changing the data on the Source devices. How ever if there is no more space in the Save Area, then this operation cannot complete. Hence the session is placed in a failed state.




Save Device Space Considerations

Virtual Devices do not pre-allocate space for all potential copy-on-write tracks

It is possible to run out of free space on save devices

If Writes cannot complete due to no free space:– The target VDEV goes Not Ready (NR)– Copy-on-write is disabled and the source track is changed

Draining Save DevicesPermits a disable command to work on an active save deviceAll active tracks copied (drained) to other devices in the save poolProtections against disabling the last device or causing the pool to overflow and terminate snap session

disable dev SymDevName[:SymDevName] in pool <poolname>, type = snap

Use symsnap monitor to track the amount of available space of the save area. The symsnap monitor command can also be used to automatically run an action if a predetermined threshold for space has been crossed. Use -percent nn –action script_pathname to specify the percentage full threshold and script associated with it.




Use symsnap monitor to automatically run an action:C:\>symsnap monitor -sid 24 -percent 80 –action one_percent_script.sh

–svp DEFAULT_POOL -i 60 –c 5

The above command will monitor the default save pool (“DEFAULT_POOL”) every 60 seconds for 5 iterations. If the save pool usage reaches 80 percent, then the command will execute the one_percent_script.sh script.

Monitoring Save Device Space

You can monitor SAVE devices by using the symsnap monitor command to check the percentage full. When devices reach the specified percentage, an optional action script can be executed by the application to preserve the data or terminate sessions. The following is an example of the monitor command:

symsnap monitor -percent 80 -action SaveScript -norepeat -i 60 –svpAccounting

In the above example, the SAVE device pool “Accounting” will be monitored every minute for percentage full. When the percentage of the SAVE devices are 80 percent full, the associated action script SaveScript will be executed each time the threshold of 80 percent is met.




List Available VDEVsC:\>symdev list -vdev


Device Name Directors Device


--------------------------- ------------- -------------------------------------

Cap

Sym Physical SA :P DA :IT Config Attribute Sts (MB)

--------------------------- ------------- -------------------------------------

0131 Not Visible ***:* NA:NA VDEV N/Asst'd NR 1078





The list of available VDEVs can be obtained with the command shown.




List All the Save Pools

C:\>symsnap list -pools


S A V E D E V I C E P O O L S

--------------------------------------------------------------------------------

Dev Total Enabled Used Free Full Pool Session

Pool Name Emul Tracks Tracks Tracks Tracks (%) State Status

--------------------------------------------------------------------------------

DEFAULT_POOL FBA 276000 276000 0 276000 0 Enabled Inactive

DEFAULT_POOL 3390 0 0 0 0 0 Disabled Inactive

DEFAULT_POOL 3380 0 0 0 0 0 Disabled Inactive

DEFAULT_POOL AS400 0 0 0 0 0 Disabled Inactive

In this example there is a DEFAULT_POOL of device emulation type FBA, with a number of devices in it.




List All the Save Devices in a Save PoolC:\>symsnap list -svp DEFAULT_POOL -savedevs


S N A P S A V E D E V I C E S

---------------------------------------------------------------------

Device SaveDevice Total Used Free Full

Sym Emulation Pool Name Tracks Tracks Tracks (%)

---------------------------------------------------------------------

017D FBA DEFAULT_POOL 17250 0 17250 0

017E FBA DEFAULT_POOL 17250 0 17250 0

017F FBA DEFAULT_POOL 17250 0 17250 0

0180 FBA DEFAULT_POOL 17250 0 17250 0

-----Output Truncated-----------

Total --------- --------- --------- ----

Tracks 276000 0 276000 0

MB(s) 17250.0 0.0 17250.0

The individual Symmetrix devices that constitute the Save Pool can be listed as well.




Create New Save Pool and Add Save DevicesC:\>symconfigure –sid 80 –f create_pool.txt commit –nop

C:\>symconfigure –sid 80 –f disable_devs.txt commit –nop

C:\>symconfigure –sid 80 –f add_dev_to_pool.txt commit –nop

C:\>symsnap list -svp appn_a_pool -savedev


S N A P S A V E D E V I C E S

---------------------------------------------------------------------

Device SaveDevice Total Used Free Full

Sym Emulation Pool Name Tracks Tracks Tracks (%)

---------------------------------------------------------------------

017D FBA appn_a_pool 17250 0 17250 0

017E FBA appn_a_pool 17250 0 17250 0

017F FBA appn_a_pool 17250 0 17250 0

0180 FBA appn_a_pool 17250 0 17250 0

Total --------- --------- --------- ----

Tracks 69000 0 69000 0

MB(s) 4312.5 0.0 4312.5

The symconfigure command is used to create a new Save Pool and add Save Devices to it. The action and the devices are specified in the *.txt files. In this example we are moving devices 17D:180out of the DEFAULT_POOL, into a new Save pool – appn_a_pool.

create_pool.txt: create pool appn_a_pool, type=SAVEDEV; This creates Save Pool named appn_a_pool.

disable_devs.txt: disable dev 17D:180 in pool DEFAULT_POOL, type=SAVEDEV; This disables the devices 17D:180 currently in the DEFAULT_POOL

add_dev_to_pool.txt: add dev 17D:180 to pool appn_a_pool, type=SAVEDEV, member_state=ENABLE; This adds the devices 17D:180 to the appn_a_pool, and enables the devices as well.




Show Device GroupC:\>symdg show snapdg

Group Name: snapdg

Number of STD Devices in Group : 2

Number of Associated GK's : 0

Number of Locally-associated BCV's : 0

Number of Locally-associated VDEV's : 2


{

--------------------------------------------------------------------

Sym Cap


--------------------------------------------------------------------

DEV001 \\.\PHYSICALDRIVE7 013F RW 1078


}

A SYMCLI Device Group has been created, two STD devices have been added as Source for Snap sessions and two VDEVs have been added as Targets for Snap sessions.

symdg create snapdg

set SYMCLI_DG=snapdg

symld addall dev –range 13F:140

symld addall dev –range 131:132 –vdev




Show Device Group (continued)C:\>symdg show snapdg

VDEV Devices Locally-associated (2):

{

--------------------------------------------------------------------

Sym Cap


--------------------------------------------------------------------

VDEV001 N/A 0131 NR 1078

VDEV002 N/A 0132 NR 1078

}

Note that the VDEVs are given the Logical Devices Names VDEV001 and VDEV002 respectively.




Create Snap SessionsC:\>symsnap create -svp appn_a_pool

C:\>symsnap query

-----------Output Truncated----------


------------------------- ------------------- ---------- ------------ ----

Protected Changed

Logical Sym Tracks Logical Sym G Tracks SRC <=> TGT (%)

------------------------- ------------------- ---------- ------------ ----

DEV001 013F 17250 VDEV001 0131 X 0 Created 0

DEV002 0140 17250 VDEV002 0132 X 0 Created 0

Total -------- ----------

Track(s) 34500 0

MB(s) 2156.3 0.0

In this example, Snap sessions have been created between the source and the target VDEVs. The symsnap create command sets up the track protection bitmap. As can be seen in the output, all tracks on the Source devices have been protected. The state of the Source – Target device pair goes to Created.

Legend:

(G): X = The Target device is associated with this group,

. = The Target device is not associated with this group.




Create Snap Sessions (continued)C:\>symsnap list


Source Device Target Device Status SaveDev

------------------------- -------------------- ------------- -----------

Protected

Sym Tracks Sym G SRC <=> TGT PoolName

------------------------- -------------------- ------------- -----------

013F 17250 0131 X Created appn_a_pool

0140 17250 0132 X Created appn_a_pool

Total --------

Tracks 34500

MB(s) 2156.3

A “hold” is placed on the VDEVs and they remain in a Not Ready state. We can also see that the Save Pool named appn_a_pool is used for these Snap sessions.

C:\>symdev list -held



--------------------------- ------------- -------------------------------------

Cap


--------------------------- ------------- -------------------------------------

0131 Not Visible ***:* NA:NA VDEV Asst'd NR 1078

0132 Not Visible ***:* NA:NA VDEV Asst'd NR 1078




Activate Snap SessionsC:\>symsnap activate –consistent -nop

C:\>symsnap query

----Output Truncated-----


------------------------- ------------------- ---------- ------------ ----

Protected Changed


------------------------- ------------------- ---------- ------------ ----

DEV001 013F 17250 VDEV001 0131 X 0 CopyOnWrite 0

DEV002 0140 17250 VDEV002 0132 X 0 CopyOnWrite 0

Total -------- ----------

Track(s) 34500 0

MB(s) 2156.3 0.0

The symsnap activate command places the snap pair in the CopyOnWrite (copy-on-first-write) state and the target virtual device in a Read/Write (RW) state. The actual copying of data occurs when a track is written to either on the Source device or on the VDEV.




Querying Multiple Snap SessionsC:\>symsnap query –multi

---Output Truncated------


------------------------- ------------------- ---------- ------------ ----

Protected Changed


------------------------- ------------------- ---------- ------------ ----

DEV001 013F 17246 VDEV003 0133 X 4 CopyOnWrite 0

17121 VDEV001 0131 X 129 CopyOnWrite 0

DEV002 0140 17246 VDEV004 0134 X 4 CopyOnWrite 0

17121 VDEV002 0132 X 129 CopyOnWrite 0

Total -------- ----------

Track(s) 68734 266

MB(s) 4295.9 16.6

For this example two additional VDEVs (133:134) were added to the device group snapdg.

symsnap create –svp appn_a_pool – Creates the first Snap session between 13F:131 and 140:132

symsnap activate –consistent – Activates the first Snap session

symsnap create –svp appn_a_pool –concurrent – Creates the second Snap session between 13F:133 and 140:134

symsnap activate –consistent – Activates the second Snap session




symsnap restore

Three types of restore operations can be performed for virtual device copy sessions:– Incremental restore back to the original source device– Incremental restore to a split TimeFinder/Clone BCV or a

TimeFInder/Mirror BCV– Full restore to any standard or split TimeFinder/Clone BCV or a

TimeFinder/Mirror BCV

Three types of restore operations can be performed for virtual device copy sessions:1. Incremental restore back to the original source device.2. Incremental restore to a TimeFinder/Clone BCV or a TimeFinder/Mirror BCV, which has been

split from its original standard source device but maintains the incremental relationship with the source.

3. Full restore to any standard or split TimeFinder/Clone BCV or a TimeFinder/Mirror BCv device outside of the existing copy session. The target device of the restore must the same size and emulation type as the source device.

All original Snap copy sessions are maintained when performing a restore operation. A new restore copy session between the source device and VDEV is created. A restore operation can only be performed if an additional copy session is available for use.




Restore a Snap SessionC:\>symsnap restore -nop

C:\>symsnap query



------------------------- ------------------- ---------- ------------ ----

Protected Changed


------------------------- ------------------- ---------- ------------ ----

DEV001 013F 0 VDEV001 0131 X 0 Restored 100

DEV002 0140 0 VDEV002 0132 X 0 Restored 100

Total -------- ----------

Track(s) 0 0

MB(s) 0.0 0.0

When a restore command is issued, both the VDEVs and the Source devices are set to Not Ready. Once the restore operation starts the Source devices are automatically set to Ready. But the VDEVswill remain Not Ready. Hence it would be best practice to stop access to the VDEVs and the Source devices when initiating a restore operation. After the restore comples the VDEVs can be made ready again by symdev ready 131 –sid 80; symdev ready 132 –sid 80

The restore command initiates an incremental restore by default.




List Sessions after RestoreC:\>symsnap list


Source Device Target Device Status SaveDev

------------------------- -------------------- ------------- -----------

Protected

Sym Tracks Sym G SRC <=> TGT PoolName

------------------------- -------------------- ------------- -----------

013F 0 0131 X Restored appn_a_pool

013F 17250 0131 X CopyOnWrite appn_a_pool

0140 0 0132 X Restored appn_a_pool

0140 17250 0132 X CopyOnWrite appn_a_pool

Total --------

Tracks 34500

MB(s) 2156.3

Note that even after the restore operation, the original Snap session is still maintained. If this original session should now be recreated or terminated, the restored session should first be terminated with symsnap terminate –restored operation.




TimeFinder/Snap with Thin Devices

Thin devices can be snapped like regular devices

Thin device sources can be snapped to virtual device targets

VDEV targets can be made ready and updated

VDEVs can be restored back to the source thin devices

Thin devices can be used with TimeFinder/Snap in the same way that other types of Symmetrix devices can be used. Point-in-time snap copies of thin devices can be created on virtual devices (VDEVs), which can subsequently be presented to a host. The VDEVs can also be updated and the changes on the VDEVs can be restored back to the source thin devices or to different thin devices.

Thin devices are classified as standard devices and can be added to Symmetrix device groups or put in device files.




TimeFinder/Snap Recreate

– Create snap– Activate snap– Recreate snap– Activate snap– Repeat recreate/activate snap

Enginuity 5874

1. Create snap2. Activate snap3. Terminate snap4. Repeat the cycle

Prior to Enginuity 5874

Prior to Enginuity 5874, taking a new point-in-time TimeFinder/Snap copy required terminating the previously activated Snap session between the source volume and the target virtual volume (VDEV). Recreate operation will now be allowed with TimeFinder/Snap symsnap command. After activation of a Snap session, the session can be recreated and then activated, as and when new point-in-time image is required. As the recreate will lead to the replacement of the old image on the VDEV, all used tracks in the SAVE pool associated with the previous session will be released. The query output will show a recreated state. The recreate function is not supported with Multi-Virtual snap.




Snap of a Clone Target

Target of a Clone session can be the Source for one or more Snap sessions

The original Clone session must be in the copied state

When Snap session starts using the Clone target, the only action permitted on the original Clone session is terminate. All other actions are blocked until all the Snap sessions are terminated

The only actions permitted on the Snap session with Clone target as the source are activate and terminate. All other actions are blocked until the original Clone session is terminated

Note that with Solutions Enabler 7.0 and Enginuity 5874, a symsnap recreate operation can also be performed on the Snap session with Clone target as the source.




Module SummaryKey points covered in this module:

Described TimeFinder/Snap functionality

Described TimeFinder/Snap “Copy on First Write”process

Described the Create, Activate, Terminate and Restore TimeFinder Snap operations

Identified and described Virtual Devices used for TimeFinder/Snap operationsDescribed the SYMCLI symsnap command set to Monitor, Create, Activate, and Query TimeFinder/Snap sessions



Module 4 – SRDF/S Operations - 1

© 2009 EMC Corporation. All rights reserved. Module 4 - SRDF/S Operations - 1

Module 4: SRDF/Synchronous OperationsUpon completion of this module, you will be able to:

Identify SRDF volumes using the SYMCLI command set

Configure SRDF Device Groups

Display SRDF Device Group properties

Display and monitor the status of an SRDF Device Group

Perform operations to suspend, and resume remote mirroring

Perform disaster recovery operations to failover, update, and failback device group behavior

Perform concurrent operations to establish, split, and restore mirroring activity for specific device groups.

Create and Delete Dynamic SRDF pairs





Facility for maintaining real-time or near-real-time physically separate mirrors of selected volumes

Uses no host CPU resources• Mirroring done at the storage

level

Operating system independent• Open Systems• Mainframe

RDFLink

Open SystemsMainframe

Source Target

Symmetrix Remote Data Facility (SRDF)

Symmetrix Remote Data Facility (SRDF) is a Symmetrix system based business continuance, disaster recovery, restart, and data mobility solution. In the simplest terms, SRDF is a configuration of multiple Symmetrix units for remote replication of data. The Symmetrix units can be in the same room, in different buildings within the same campus, or hundreds and even thousands of miles apart. Data can be replicated Synchronously (SRDF/S) or Asynchronously (SRDF/A).




Identify Accessible SRDF Volumes C:\>symrdf list pd


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

---- ---- -------- --------- ----- ------- ------- --- ---- -------------

0145 0145 R1:100 RW RW RW S..1. 0 0 RW WD Synchronized




Total -------- --------

Track(s) 0 0

MB(s) 0.0 0.0

The SYMCLI command symrdf list pd gives a list of all SRDF devices accessible to the host. In this example the host has access to 4 SRDF devices (0145:0148). As can be seen under the RDF Typ:G column, the devices are of type R1 and they belong to the SRDF Group 100. The of SRDF operation is Synchronous, and currently all the R1-R2 pairs are in a Synchronized state. The local R1 devices (the Sym Dev column of the output) 0145:0148 are paired with corresponding R2 devices (the RDev column of the output) 0145:0148Legend for MODES:

M(ode of Operation) : A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy

D(omino) : X = Enabled, . = Disabled

A(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

The inquiry command syminq will give a list of all devices accessible to the host. The type of the device is will be indicated in the Type column. This command will also help in correlating the host Physical Device Names with the corresponding Symmetrix Device numbers.

The command symdev list –r1 can be used to list all the SRDF R1 devices configured on the Symmetrix to which the host is attached.




Configuring SYMCLI SRDF Device Groups Devices can be “Grouped” into “Device Groups”

All devices in a device group must be in the same Symmetrix array

All devices must be of the same type (RDF1, RDF2, RDF21or Regular)

C:\>symdg create -type R1 srdfsdg

C:\>set SYMCLI_DG=srdfsdg

C:\>symld addall dev -range 145:146

RDFLink

Source (R1) Target (R2)

R1 R20145

0146

0145

0146

srdfsdg

A device group is a user created object for viewing and managing related Symmetrix devices. All devices in a device group should be on the same Symmetrix array. There are three types of device groups: RDF1, RDF2, RDF21 or REGULAR. When creating a device group, if a type is not specified explicitly, by default a device group of type REGULAR will be created. A device group, with the type REGULAR cannot contain SRDF devices, a device group of type RDF1 cannot contain R2 devices and a device group of type RDF2 cannot contain R1 devices. When performing TimeFinder or SRDF/S operations, SYMCLI commands can be executed for ALL devices in the device group or a subset of them. For SRDF/A operations the commands should be executed for ALL devices in the SRDF Group (another construct discussed later).

Storage Administrators must create a device group with RDF1 or RDF2 for SRDF operations, as appropriate. In this example device group of type R1 (RDF1) is created, so that the R1 devices 0145 and 0146 can be added to it.

The device group definition is stored in the SYMAPI database (symapi_db.bin) on the host where the symdg create command was executed. By default a Symmetrix device can only belong to one device group on the host from which the group was created. If the device should belong in multiple device groups on the same host then the variable SYMAPI_ALLOW_DEV_IN_MULT_GRPS must be set to ENABLE in the options file.




Displaying SYMCLI Device GroupsC:\>symdg show srdfsdg

Group Name: srdfsdg

Group Type : RDF1 (RDFA)

Device Group in GNS : No

Valid : Yes

Symmetrix ID : 000194900180

Group Creation Time : Mon Jun 22 14:06:34 2009

Vendor ID : EMC Corp

Application ID : SYMCLI

Number of STD Devices in Group : 2

Number of Associated GK's : 0

Number of Locally-associated BCV's : 0

Number of Locally-associated VDEV's : 0

Number of Locally-associated TGT's : 0

---Output Truncated-------

The symdg show command displays detailed group information for any specific device group. The device group (srdfsdg), contains 2 local standard devices. The device group type is RDF1. The Symmetrix serial number is also displayed. If there are any BCVs, VDEVs, etc associated with or added to the group, this information is also displayed.




Displaying SYMCLI Device Groups (continued)Standard (STD) Devices (2):

{

--------------------------------------------------------------------

Sym Cap


--------------------------------------------------------------------



}

---Output Truncated--------

Further information on the devices in the group as well as relevant RDF information is also presented with the symdg show command. The two devices have been assigned (by default) the Logical Device Names of DEV001 and DEV002. The host (Windows OS in this example) addresses the two devices as PHYSICALDRIVE13 and PHYSICALDRIVE14.




The SRDF SYMCLI Command Syntax

c:\symrdf -g <device group> <action> [options]

Where action can be one of the following:

RDFLink

Source (R1 Side) Target (R2 Side)

R1R2

R1R2

The ControlingHost

establishset moderestorefailover

update

splitresumefailbacksuspend

Users can perform a number of Symmetrix SRDF operations using host-based SYMCLI commands. Major SRDF operations or actions include: suspend, resume, failover, failback, update, split, establish, and restore.




Verifying the SRDF Links StatusC:\>symcfg list

S Y M M E T R I X

Mcode Cache Num Phys Num Symm

SymmID Attachment Model Version Size (MB) Devices Devices

000194900180 Local VMAX-1SE 5874 12288 64 410

000194900181 Remote VMAX-1SE 5874 12288 0 423

000194900182 Remote VMAX-1SE 5874 12288 0 405

C:\>symrdf ping

Successfully pinged (Remotely) Symmetrix ID: 000194900181

Successfully pinged (Remotely) Symmetrix ID: 000194900182

The symcfg list command gives the list of all Symmetrix Arrays that are connected to the Local Symmetrix. In this example Symmetrix with ID 80 is the Local Symmetrix. It is connected via SRDF to both Symmetrix ID 81 and Symmetrix ID 82. The Num Phys Devices column indicates that the host from which the command was executed, has physical access to 64 devices on Symmetrix ID 80, and none on the other two Symmetrix Arrays.

The symrdf ping command verifies that the Local Symmetrix can communicate with the Remote Symmetrix Arrays over the SRDF Links.




Listing the Remote Adapters ConfiguredC:\>symcfg list -ra all -sid 80


S Y M M E T R I X R D F D I R E C T O R S

Remote Local Remote

Ident Symb Num Slot Type Attr SymmID RA Grp RA Grp Status

RF-7H 07H 119 7 RDF-R1 - 000194900181 121 (78) 121 (78) Online

- 000194900181 100 (63) 100 (63)

- 000194900181 100 (63) 100 (63)

RF-8H 08H 120 8 RDF-R1 - 000194900181 100 (63) 100 (63) Online

- 000194900181 100 (63) 100 (63)

This command shows that Symmetrix ID 80 has a pair of SRDF Adapters configured – 7H and 8H. SRDF group 100 (RA Group 100) has been created to use both the adapters.




Suspending the SRDF Links • Logically suspends mirror relationship between source and target volumesC:\>symrdf suspend -nop

C:\>symrdf query

----Output Truncated---

Source (R1) View Target (R2) View MODES

-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A

Logical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair

Device Dev E Tracks Tracks S Dev E Tracks Tracks MDAE STATE

-------------------------------- -- ------------------------ ----- ------------

DEV001 0145 RW 0 139 NR 0145 WD 0 0 S... Suspended

DEV002 0146 RW 0 138 NR 0146 WD 0 0 S... Suspended

Total -------- -------- -------- --------

Track(s) 0 277 0 0

MB(s) 0.0 17.3 0.0 0.0

Suspend is a singular operation. Data transfer from the Source devices to the Target devices is stopped. RA communication path is still available. New writes to the Source devices accumulate as invalid tracks to the R2 (R2 Inv Tracks). The link is set to Not Ready (NR). The R1s continue to be Read Write enabled and the R2s continue to be Write Disabled.

To invoke a suspend, the RDF pair(s) must already be in one of the following states:SynchronizedR1 Updated




Resuming the SRDF Links • Resumes mirror relationship between source and target volumesC:\>symrdf resume –nop

C:\>symrdf query

---Output Truncated----


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0145 RW 0 0 RW 0145 WD 0 0 S... Synchronized

DEV002 0146 RW 0 140 RW 0146 WD 0 0 S... SyncInProg

Total -------- -------- -------- --------

Track(s) 0 140 0 0

MB(s) 0.0 8.8 0.0 0.0

Resume is a singular operation. To invoke this operation, the RDF pair(s) must already be in the Suspended state. Data transfer from R1 to R2 is resumed. The pair state will remain in SyncInProguntil all accumulated invalid tracks for the pair have been transferred. Invalid tracks are transferred to the R2 in any order – so write serialization will not be maintained. The link is set to Read Write. The R1s continue to be Read Write enabled and the R2s continue to be Write Disabled.




Changing SRDF Operational Modes symrdf set mode <ModeVal> [skew <SkewVal>]

<ModeVal> = async|sync|acp_wp|acp_disk|acp_off

C:\>symrdf set mode acp_disk –nop

C:\>symrdf query

----Output Truncated----


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0145 RW 0 0 RW 0145 WD 0 0 C.D. Synchronized


The “symrdf set mode” command will change the SRDF operation mode. In this example the mode has been changed to Adaptive Copy Disk for these two R1-R2 pairs. This is indicated by the C in Mcolumn and D in the A column of the output.

Legend for MODES:








Failover:• Will make a copy of the data on target devices (R2s) available to the

host accessing these devices on the target array.• Invoked in the event of a disaster – Host, Symmetrix or Site failure• Can be used for maintenance operations on the source site: Will

provide data availability from the target devices, during host, Symmetrix, or Site maintenance

Update:• Begins transfer of accumulated invalid tracks from the R2s to the R1s,

while production work continues on the R2s

Failback:• Resumes operation back on the primary host accessing data on the

source devices (R1s), all changes made to the R2s when failed over will be transferred back to the source devices

• Primary host can access the R1 devices as soon as the command completes without waiting for the data transfer to complete

SRDF Disaster Recovery Operations

The SRDF disaster recovery operations are:Failover from the source side to the target side, switching data processing to the target sideUpdate the source side after a failover while the target side is still used for applications Failback from the target side to the source side by switching data processing to the source side




Update

RDFLinks“RW”

WDRW

WD RW

R1 R2

Production continues on the R2 side and invalids are copied to the R1 array

Failback

RDFLinks“RW”

RWWD

RW WD

R1 R2

Production switches back to the R1 side and any additional invalids are copied to the R1 array

WDRW

WD RW

Failover

RDFLinks“NR”

R1 R2

Production switches to the R2 side and invalids are maintained on the R2 array

SRDF Device Group

SRDF - Failover, Update, Failback Summary

Summary / Review for Failover, Update, and Failback

Failover - Once a failover has been invoked, the R1 devices become “Write Disabled” and the link becomes logically “Not Ready”. The target devices are “Read Write” enabled and the RDF Pair is now in a “Failed Over” state.

Update - When performing and update, the R1 devices are still “Write Disabled” the link becomes “Read Write” enabled because of the “Updated” state. The target devices (R2) will remain “Read Write” during the update process.

Failback - When performing a failback, the R1 devices will become “Read Write” and the link will become “Read Write” as well. The target devices become “Write Disabled” and the RDF Pair will eventually become synchronized.




SRDF Failover C:\>set SYMCLI_DG=srdfsdg

C:\>symrdf failover -nop

An RDF 'Failover' operation execution is

in progress for device group 'srdfsdg'. Please wait...

Write Disable device(s) on SA at source (R1)..............Done.

Suspend RDF link(s).......................................Done.

Read/Write Enable device(s) on RA at target (R2)..........Done.

The RDF 'Failover' operation successfully executed for

device group 'srdfsdg'.

The failover operation can be executed from the source side host or the target side. This is true for all symrdf commands. In the event of an actual disaster, this is helpful as there would be no way of communicating with the source Symmetrix. The operation assumes disaster situation - makes all effort to enable data access on target Symmetrix

Will proceed if possibleWill give message for any potential data integrity issue

As can be seen in the output, the R1 devices are write disabled, the SRDF links between the device pairs are logically suspended, and the R2 devices are read write enabled. Host accessing the R2 devices can now resume processing the application.

While in a true disaster situation when the source host/Symmetrix/site may be unreachable, the steps listed below would be recommended if performing a “graceful” failover to the target site.

If failing over for a Maintenance operation: For a clean, consistent, coherent point in time copy which can be used with minimal recovery on the target side some or all of the following steps may have to be taken on the source side:

Stop All ApplicationsUnmount file system (unmount or unassing drive letter to flush the filesystem buffers from the host memory down to the Symmetrix)Deactivate the Volume GroupA failover leads to a write disabled state of the R1 devices. If a device suddenly becomes write

disabled from a read/write state the reaction of the host can be unpredictable if the device is in use. Hence the recommendation to stop applications, unmount filesystem/unassign drive letter, prior to performing a failover for maintenance operations




Query after SRDF FailoverC:\>symrdf query


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0145 WD 0 0 NR 0145 RW 347 0 S... Failed Over

DEV002 0146 WD 0 0 NR 0146 RW 346 0 S... Failed Over

Total -------- -------- -------- --------

Track(s) 0 0 693 0

MB(s) 0.0 0.0 43.3 0.0

As seen in the output, the R1s are now Write Disabled, the links are set to Not Ready and the R2s are Read Write enabled. As application processing has been started using the R2 devices, we see that there are invalid tracks accumulating (R1 Inv Tracks) on the target Symmetrix. These are the changes that are being made to the R2 devices. When it is time to return to the source Symmetrix, these invalid tracks will be incrementally synchronized back to the source. The pair state is reflected as Failed Over.




Updating Source Volumes C:\>symrdf update -nop

An RDF 'Update R1' operation execution is



Merge device track tables between source and target.......Started.

Devices: 0145-0146 in (0180,100)......................... Merged.

Merge device track tables between source and target.......Done.

Resume RDF link(s)........................................Started.

Resume RDF link(s)........................................Done.

The RDF 'Update R1' operation successfully initiated for


While the target (R2) device is still operational (Read Write Enabled to its local host), an incremental data copy from the target (R2) device to the source (R1) device can be initiated in order to update the R1 mirror with changed tracks from the target (R2) device. After an extended outage on the R1 side, a substantial amount of invalid tracks could have accumulated on the R2. If a failback is now performed, production starts from the R1. New writes to the R1 have to be transferred to the R2 synchronously. Any track requested on the R1 that has not yet been transferred from the R2 has to be read from across the links. This could lead to performance degradation on the R1 devices. The update operation helps to minimize this impact.

When performing and update, the R1 devices are still “Write Disabled”; the links becomes “Read Write” enabled because of the “Updated” state. The target devices (R2) remain “Read Write” during the update process.

The update operation can be used with the –until flag, which represents a skew value assigned to the update process. For example, one can choose to update until the accumulated invalid tracks is down to 30000. Then a failback operation can be executed.




Query after Update

C:\>symrdf query


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0145 WD 0 0 RW 0145 RW 0 0 S... R1 Updated

DEV002 0146 WD 0 0 RW 0146 RW 0 0 S... R1 Updated

Total -------- -------- -------- --------

Track(s) 0 0 0 0

MB(s) 0.0 0.0 0.0 0.0

Note that when the update operation is performed after a failover, the links become Read/Write enabled, but the Source devices are still Write disabled. Production work continues on the R2 devices.




SRDF Failback C:\>symrdf failback -nop

An RDF 'Failback' operation execution is


Write Disable device(s) on RA at target (R2)..............Done.







Read/Write Enable device(s) on SA at source (R1)..........Done.

The RDF 'Failback' operation successfully executed for


When the source site has been restored, or if maintenance is completed, one can return production to the source site. The symrdf failback command will set the R2s Write Disabled, the link Read Write and the R1s Read Write enabled. Merge of the device track tables between the source and target is done. The SRDF links are resumed. The accumulated invalid tracks are transferred to the source devices from the target devices. So all changes made to the data when in a failed over state will be preserved. As noted earlier, the Primary host can access the R1 devices and start production work as soon as the command completes. If a track that has not yet been sent over from the R2 is required on the R1, SRDF can preferentially read that track from across the links.

As the R2s will be set to Write Disabled, it is important to shut down the applications using the R2 devices, and perform the appropriate host dependent steps to unmount filesystem/deactivate volume groups. If applications still actively access R2s when they are being set to Write Disabled, the reaction of the host accessing R2s will be unpredictable. In a true disaster, the failover process may not give an opportunity for a graceful shutdown. But a failback event should always be planned and done gracefully.




Query after a FailbackC:\>symrdf query


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------



Total -------- -------- -------- --------

Track(s) 0 0 0 0

MB(s) 0.0 0.0 0.0 0.0

As can be seen in the output the R1s are set to Read Write, R2s are set to Write Disabled and the links are set to Read Write. The pair states go into Synchronized. The accumulated invalid tracks have been transferred from the target array to the source array.




Split:• Places the Symmetrix units in a state for concurrent access• Suspends link between source (R1) and target (R2) volumes• Enables read and write operations on both source and target

volumes

Establish:• Save source data• Resume Normal SRDF operations• Preserves data on the source (R1) volumes, discarding

changes to the target (R2) volumes

• Restore:• Resumes SRDF operations• Preserves data on the target (R2) volumes, discarding

changes to the source (R1) volumes

SRDF Decision Support/Concurrent Operations

The decision support operations for SRDF devices are:Split an SRDF pair which stops mirroring for the SRDF pairs in a device group.Establish an SRDF pair by initiating a data copy from the source side to target side. The operation can be a full or incremental.Restore remote mirroring, which initiates a data copy from the target side to the source side. The operation can be full or incremental.

As noted in the slide title these are decision support operations and are not disaster recovery/business continuance operations. In these situations, both the Source and Target sites are healthy and available.




Split

RDFLinks“NR”

RWRW

RW RW

R1 R2

- Production continues on the R1 – R2 can be used for DSS operations- Invalids tracked on both sides of the RDF link

Restore

RDFLinks“RW”

RWWD

RW WD

R1 R2

Changes made to the R2 are moved across the RDF links to the R1 pairs

Concurrent Operations - Split, Establish, Restore

RWWD

RW

Establish

RDFLinks“RW”

R1 R2

Changes made to R1are moved across the RDF link to the R2 pairs

SRDF Device Group

WD

Summary / Review for Establish, Split, and Restore

Split - When performing a split the R1 and R2 devices will become “Read Write ” enabled and the links will become “Not Ready”.

Establish - When performing an establish operation. The target devices (R2) will become “Write Disabled” and the RDF pair will become fully synchronized. Links becomes Read Write and the R1 devices continue to be Read Write enabled.

Restore - When performing a restore operation. The target devices (R2) will become “Write Disabled”and the RDF pair will become fully synchronized. Links becomes Read Write and the R1 devices continue to be Read Write enabled.

Note that the final state after either an establish or a restore operation is the same. How ever, the direction of data movement is different. As in the case with the failback operation, R1 devices can be accessed immediately after the establish or restore command completes.




Concurrent Operations: Split C:\>symrdf split –nop

C:\>symrdf query

----Output Truncated


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0145 RW 0 0 NR 0145 RW 0 0 S... Split


The split command suspends the links between source (R1) and Target (R2) volumes. The source devices continue to be read write enabled. The target devices are set to read write enabled. It enables read and write operations on the and target volumes.




Concurrent Operations: Split (continued)C:\>symrdf query

----Output Truncated---------


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------



Total -------- -------- -------- --------

Track(s) 0 617 696 0

MB(s) 0.0 38.6 43.5 0.0

Changes to the source devices are marked as R2 invalids. Changes to target devices are marked as R1 invalids. SRDF does not provide Disaster Recovery in this state, as changes are being made to both R1 and R2 independently of each other and remote mirroring has been suspended.




Concurrent Operations: Establish C:\>symrdf establish -nop

An RDF 'Incremental Establish' operation execution is




Mark target (R2) devices to refresh from source (R1)......Started.

Devices: 0145-0146 in (0180,100)......................... Marked.

Mark target (R2) devices to refresh from source (R1)......Done.






The RDF 'Incremental Establish' operation successfully initiated for


Establish operation will resume SRDF remote mirroring. Changes made to the source while in a split state, will be transferred to the target. Changes made to the target are overwritten. The R2 devices are set to Write Disable. Hence applications should stop accessing the R2 devices, prior to performing an establish operation. The links are resumed.




Concurrent Operations: RestoreC:\>symrdf restore -nop

An RDF 'Incremental Restore' operation execution is


Write Disable device(s) on SA at source (R1)..............Done.



Mark source (R1) devices to refresh from target (R2)......Started.

Devices: 0145-0146 in (0180,100)......................... Marked.

Mark source (R1) devices to refresh from target (R2)......Done.






Read/Write Enable device(s) on SA at source (R1)..........Done.

The RDF 'Incremental Restore' operation successfully initiated for


Restore operation will resume SRDF remote mirroring. Changes made to the target while in a split state, will be transferred to the source. Changes made to the source are overwritten. The R2 devices are set to Write Disable. Hence applications should stop accessing the R2 devices, prior to performing an establish operation. The links are resumed. As data on the R1 devices will change without the knowledge of the host, access to R1 devices should be stopped prior to performing a restore operation. As soon as the command completes, R1 devices can be accessed again without waiting for synchronization to be completed. Any required track on the R1 that has not yet been received from the R2, will be read across the links.




Creating a Dynamic SRDF Group

To create a Dynamic SRDF group – first check to make sure both arrays have the Dynamic RDF Configuration State setting enabled

C:\>symcfg list –sid 80 –v


Symmetrix Configuration Checksum : 8CCBA389

Switched RDF Configuration State : Enabled

Concurrent RDF Configuration State : Enabled

Dynamic RDF Configuration State : Enabled

Concurrent Dynamic RDF Configuration : Enabled

RDF Data Mobility Configuration State: Disabled

Access Control Configuration State : Enabled

Device Masking (ACLX) Config State : Enabled

Dynamic RDF Configuration State is Enabled by default with Symmetrix V-Max array and Enginuity5874. Symmetrix devices can have an attribute set on them which enables them to become a R1, or a R2, or either. The combination of the ability to dynamically create SRDF groups and the dynamic device attribute enables one to create, delete and swap SRDF R1-R2 pairs.




Creating a Dynamic SRDF Group (continued)C:\>symcfg list -ra all -sid 80



Remote Local Remote


RF-7G 07G 103 7 RDF-R1 - 000194900181 9 (08) 9 (08) Online

- 000194900181 10 (09) 10 (09)

RF-8G 08G 104 8 RDF-BI-DIR - 000194900182 29 (1C) 29 (1C) Online

- 000194900182 30 (1D) 30 (1D)

RF-7H 07H 119 7 RDF-R1 - 000194900181 100 (63) 100 (63) Online

- 000194900181 100 (63) 100 (63)

RF-8H 08H 120 8 RDF-R1 - 000194900181 100 (63) 100 (63) Online

- 000194900181 100 (63) 100 (63)

SRDF groups define the relationships between the local Symmetrix SRDF director/ports and the corresponding remote Symmetrix SRDF director/ports. Any Symmetrix device that has been configured as an SRDF device must be assigned to an SRDF group. It would be convenient if the SRDF group numbers on the local and the remote Symmetrix are identical, however this is not a requirement. Static SRDF groups can be explicitly configured in the Symmetrix bin file. Storage Administrators can dynamically create SRDF groups and assign them to Fibre Channel directors or GigE directors. Dynamic SRDF group information is not written to the Symmetrix bin file, but they are persistent through power cycle and IMPL. Symmetrix SRDF groups are also referenced as RA groups or RDF groups.

Before creating a new SRDF group, some information needs to be gathered. First we need to know SRDF directors that are configured on the Symmetrix. We also need to know the number of SRDF groups (RA groups) currently configured and their corresponding group numbers. Symmetrix V-Max array with Enginuity 5874 can support up to 250 SRDF groups.




Creating a Dynamic SRDF Group (continued)C:\>symrdf addgrp -label Appn_A -sid 80 -remote_sid 81 -dir 7H,8H -remote_dir

7H,8H -rdfg 101 -remote_rdfg 101

C:\>symrdf createpair -sid 80 -file pairs.txt -type R1 -rdfg 101 -establish


Create RDF Pair in (0180,101)....................................Started.

Create RDF Pair in (0180,101)....................................Done.

Mark target device(s) in (0180,101) for full copy from source....Started.

Devices: 0149-014A in (0180,101)................................ Marked.

Mark target device(s) in (0180,101) for full copy from source....Done.

Merge track tables between source and target in (0180,101).......Started.

Devices: 0149-014A in (0180,101)................................ Merged.

Merge track tables between source and target in (0180,101).......Done.

Resume RDF link(s) for device(s) in (0180,101)...................Started.

Resume RDF link(s) for device(s) in (0180,101)...................Done.

The RDF 'Create Pair' operation successfully executed for device

file 'pairs.txt'.

The symrdf addgrp command creates an empty Dynamic SRDF group on the source and the target Symmetrix and logically links them. Note that physical link connectivity and communication between the two Symmetrix must exist for this command to succeed. Note that the SRDF group number in the command is in decimal. In the Symmetrix it is converted to hexadecimal. The decimal group numbers start at 01 but the hexadecimal group numbers start at 00. Hence the hexadecimal group numbers will be off by one. The symrdf createpair command takes the dynamic capable device pairs listed in the text file (pairs.txt) and makes them R1-R2 pairs. First we need to determine the devices that have the Dynamic attribute set on them. The command example is shown in the next slide. By specifying –establish the newly created R2 devices are synchronized with the data from the newly created R1 devices. In this example the file contains the following entries:

pairs.txt

149 149

14A 14A

The first column lists the devices on the Symmetrix on which the command is executed and the second column is the remote Symmetrix. Specifying –type R1 makes the device in the first column to be R1s and the devices in the second column will become their corresponding R2s.




Determine the Dynamic Capable DevicesC:\>symdev list –dynamic

----Output Truncated--------

0149 \\.\PHYSICALDRIVE17 08F:1 08A:D0 2-Way Mir N/Grp'd RW 1078

014A \\.\PHYSICALDRIVE18 08F:1 08C:D0 2-Way Mir N/Grp'd RW 1078

014B \\.\PHYSICALDRIVE19 08F:1 07A:C2 2-Way Mir N/Grp'd RW 1078

014C \\.\PHYSICALDRIVE20 08F:1 07C:C2 2-Way Mir N/Grp'd RW 1078

014D \\.\PHYSICALDRIVE21 08F:1 08B:D3 2-Way Mir N/Grp'd RW 1078

014E \\.\PHYSICALDRIVE22 08F:1 08D:D3 2-Way Mir N/Grp'd RW 1078

014F \\.\PHYSICALDRIVE23 08F:1 08B:C2 2-Way Mir N/Grp'd RW 1078

0150 \\.\PHYSICALDRIVE24 08F:1 08D:C2 2-Way Mir N/Grp'd RW 1078

0151 \\.\PHYSICALDRIVE25 08F:1 07B:D4 2-Way Mir N/Grp'd RW 1078

0152 \\.\PHYSICALDRIVE26 08F:1 07D:D4 2-Way Mir N/Grp'd RW 1078

0153 \\.\PHYSICALDRIVE27 08F:1 07B:C3 2-Way Mir N/Grp'd RW 1078

0154 \\.\PHYSICALDRIVE28 08F:1 07D:C3 2-Way Mir N/Grp'd RW 1078

The symdev show command will display the field shown below for Dynamic capable devices:

Dynamic RDF Capability : RDF1_OR_RDF2_Capable




Dynamic Createpair Options

Establish option:- Invalidates R2s, merges track tables, brings up RDF links, starts copy process

from R1 to R2

Restore option:- Invalidates R1s, merges track tables, brings up RDF links, starts copy process

from R2 to R1

Invalidate option:- Allows creation of dynamic SRDF pairs, but does not bring up the RDF links

and initiate data copy- To perform an establish, use -invalidate r2- To perform a restore, use -invalidate r1

c:\>symrdf createpair -establish

c:\>symrdf createpair -restore

c:\>symrdf createpair –invalidate r1|r2

Creating dynamic SRDF pairs with establish - Optionally, you can include the establish operation in the createpair command line by replacing the -invalidate r2 option described earlier with the –establish option, where the default copy path is R1 to R2 for all the device pairs: symrdf createpair -file grp5.txt -sid 97 -type RDF1 -rdfg 5 -establish

Creating dynamic SRDF pairs for a restore - One can perform a restore operation to copy data back to the R1 source devices by including the -restore option in the createpair command line as follows:symrdf createpair -file grp5.txt -sid 97 -type RDF1 -rdfg 5 -restore

Creating dynamic SRDF pairs and not bring up the SRDF links - Invalidate, allows creation of dynamic SRDF pairs, but does not bring up the SRDF links and initiate data copy:symrdf createpair -file grp5.txt -sid 97 -type RDF1 -rdfg 5 –invalidate

grp5.txt

13D 174

13E 175

The file contains the listing of the pairs of devices that should be changed to R1-R2 pairs. The first column lists the devices on array with sid 97 and the second column lists the corresponding devices on the remote array. In the examples shown as the type is specified as RDF1, device 13D and 13E on sid 97 will become R1s and devices 174 and 175 on the remote array will become R2s. If the type was specified to be RDF2, then 13D and 13E will become R2s and 174 and 175 will become the corresponding R1s.




Removes the pairing information from the Symmetrix

Must suspend RDF links using before issuing symrdf deletepair command (link state must be NR and pair state is Suspended, Split, or FailedOver):

Canceling dynamic SRDF pairings changes the type of the device group from R1 or R2 to Regular

Devices in the device group are changed from RDF devices to RDF-capable standard devices and the SYMAPI database is updated

Deleting Device Pairings

The delete SRDF pairs command cancels SRDF pairs in the device file specified. For example, to delete the SRDF pairs in an RDF group 5, enter: Before the delete pair can be invoked the pair must be suspend first.

Example c:\symrdf suspend -sid 97 -file grp5.txt -rdfg 5

c:\symrdf deletepair -sid 97 -file grp5.txt -rdfg 5




RDF - R1/R2 Personality “Swap”

1 c:\symrdf –g testdg failover -est

switch

R1R1 R2R2001 054

R2R2 R1R1001 054

Device Group <testdg>1

2

The “Source” environment Is now the “Target”

Site “A” becomes Site “B”

The above command will swap the R1/R2 personality pairs in device group “testdg”, resulting in the source environment switching from Site “A” and becoming Site “B”.

2

R1/R2 Swap functionality used forMultiple storage array load balancingData Center Relocation/Disaster Recovery drillsApplication Failover

An R1/R2 personality swap (or R1/R2 swap) refers to when the RDF personality of the RDF device designations of a specified device group are swapped so that source R1 device(s) become target R2 device(s) and target R2 device(s) become source R1 device(s).

Sample scenarios for R1/R2 Swap

Symmetrix Load Balancing

In today’s rapidly changing computing environments, it is often necessary to deploy applications and storage on a different Symmetrix without having to give up disaster protection. R1/R2 swap can enable this redeployment with minimal disruption, while offering the benefit of load balancing across two Symmetrix storage arrays.

Primary Data Center Relocation

Sometimes a primary data center needs to be relocated to accommodate business practices. For example, several financial institutions in New York City routinely relocate their primary data center across the Hudson River to New Jersey as part of their disaster drills. R1/R2 swaps allow these customers to run their primary applications in their New Jersey data centers. The Manhattan data centers now act as the disaster protection site.

Post-Failover Temporary Protection Measure

If the hosts on the source side are down for maintenance, R1/R2 swap permits the relocation of production computing to the target site without giving up the security of remote data protection. When all problems have been solved on the local Symmetrix, you have to failover again and swap the personality of the devices to go back to the original configuration.




Concurrent SRDF Devices

An SRDF device with two SRDF mirrors is referred to as a Concurrent SRDF device

There are three different types of Concurrent SRDF devices– R11 – Each R1 mirror is paired with a different R2 mirror on two

different remote Symmetrix Arrays– R21 – This device is the R2 mirror for an R1 device and also acts as

a R1 mirror for another R2 device. This device is used in the secondary site of a Cascaded SRDF configuration.

– R22 – Each R2 mirror is paired with a different R1 mirror on two different remote Symmetrix Arrays. Only one of the R2 mirrors can be Read/Write on the links at a time.

The R21 devices are configured and used for Cascaded SRDF environments. The R22 devices are used in SRDF/Star environments. An R22 device has two R1 mirrors. How ever, it can receive data from only one of the R1 mirrors at a time.




Concurrent SRDF – R11

One R1 can be paired with two R2 devices, concurrently

Each of the two concurrent mirrors must belong to different SRDF groups (RA groups)

switch

Remote Site BR11

R2

R2Host with

RDF daemon

Local Site A

Remote Site C

RDF Group 1

RDF Group 2

Concurrent SRDF allows two remote SRDF mirrors of a single R1 device, e.g. use one remote copy for disaster recovery, and another for decision support or backup. A concurrent R1 device has two R2 devices associated with it. Each of the R2 devices is in a different Symmetrix array. Any combination SRDF modes is allowed, except for Async and Async. i.e

R1 R2 (Site B) in Synchronous mode and R1 R2 (Site C) in Asynchronous mode

R1 R2 (Site B) in Synchronous mode and R1 R2 (Site C) in Adaptive Copy mode

R1 R2 (Site B) in Synchronous mode R1 R2 (Site C) in Synchronous mode

Each of the R1 R2 pairs are created in different SRDF Groups.

2 Synchronous remote mirrors :A write IO from the host at the primary device side cannot be returned as completed until both remote Symmetrix’ signal the local Symmetrix that the SRDF IO is in cache at the remote side.

1 Sync and 1 Adaptive Copy remote mirror:The SRDF / IO from the secondary device operating in Synchronous mode must present ending status to the sending Symmetrix before a second host IO can be accepted. The host I/O does not wait for the secondary device operating in Adaptive Copy mode.

Simultaneous restore from both R2s to the R1 cannot be performed. SRDF swap is not allowed in this configuration.




RDF-ECA Consistency Protection for SRDF/S

Enginuity Consistency Assist (ECA) is a feature of the Symmetrix Enginuity operating environment

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

R1R1

R2R2

R2R2

Concurrent SRDF

Holds write I/Os to a user defined list of Symmetrix devices prior to splitting a source volume and its replica

Supports Concurrent SRDF

RDF Enginuity Consistency Assist (RDF-ECA) provides consistency protection for synchronous mode devices by performing suspend operations across all SRDF/S devices in a consistency group or a named subset of all devices in a composite group. SRDF/S with RDF-ECA is supported by an RDF daemon that performs monitoring and cache recovery operations across all SRDF/S sessions in the group. If one or more source (R1) devices in an SRDF/S consistency group cannot propagate data to their corresponding target (R2) devices, the RDF daemon suspends data propagation from all R1 devices in the consistency group, halting all data flow to the R2 targets. This ensures that a consistent R2 data copy of the database exists at the point-in-time any interruption occurs. The RDF daemon monitors data copy operations and coordinates the suspension of R1 to R2 data propagation if the consistency group is tripped.

A Composite group must be created using the RDF consistency protection option (-rdf_consistency) and must be enabled using the symcg enable command for the RDF daemon to begin monitoring and managing the RDF-ECA consistency group. A Composite group follows the same rules as a Device group, except that the devices can span multiple local Symmetrix arrays, as well as multiple SRDF groups (RA groups). An SRDF Consistency group is a Composite group created with special properties to allow SRDF devices in separate SRDF groups to maintain dependent write consistency. Starting with Enginuity 5874, SRDF/S consistency is only supported with RDF-ECA. SRDF/S consistency using PowerPath is no longer supported.




Concurrent SRDF/S Consistency with Enginuity5874

Enginuity 5874 allows a concurrent R1 device to have:One RDF mirror in a consistency group

with SRDF/S consistency protectionOne RDF mirror in a consistency group

with SRDF/S consistency protection

One RDF mirror in a different consistency groupwith SRDF/S consistency protection

One RDF mirror in a different consistency groupwith SRDF/S consistency protection

ANDAND

Label each leg of the concurrent RDF mirrors with a different name3

Step Description

1 Create a composite group with RDF Consistency attribute

2 Add all the devices to the composite group

4 Enable consistency using the name of the relevant leg

To manage the consistency protection of the two RDF mirrors independently:

With Enginuity 5874, the two mirrors of a concurrent SRDF/S device can be managed independently.




SRDF with Thin Devices

Source and Target devices must be thin

Modes of RDF supported– SRDF/S, – SRDF/A– SRDF/Adaptive

Space is not consumed on RDF target device until writes are directed to the source

SRDF/Synchronous, SRDF/Asynchronous, or SRDF/Adaptive Copy can be used to perform replication of thin devices to thin devices on a remote Symmetrix array. Other than the requirement that both the source and target device be thin, creating and managing thin SRDF devices is exactly the same as creating and managing SRDF using regular devices.

Additional considerations if using Thin Devices for SRDF are:− Thin devices cannot be Concurrent SRDF (i.e. R11, R21, R22)− Thin devices can not be used for SRDF Cg Consistency (SRDF/S – RDF-ECA, and SRDF/A –

MSC )−DSE is not supported for SRDF/A




Module SummaryKey Points covered in this module

Identified RDF volumes using the SYMCLI command set

Configured SRDF Device Groups

Displayed SRDF Device Group properties

Displayed and monitor the status of an SRDF Device Group

Performed operations to suspend, and resume remote mirroring

Performed disaster recovery operations to failover, update, and failback device group behavior

Performed concurrent operations to establish, split, and restoremirroring activity for specific device groups.

Created and Deleted Dynamic SRDF pairs



Module 5 - SRDF/A Operations - 1

© 2009 EMC Corporation. All rights reserved.Module 5 - SRDF/A Operations - 1

Module 5: SRDF/A OperationsUpon completion of this module, you will be able to:

Describe SRDF/A “Asynchronous” Replication

List and describe the “Delta Set” Cycles within an SRDF/A environment

Describe SRDF behavior when transitioning to SRDF/A mode

Create and control an SRDF/A device group utilizing the SYMCLI command set

Describe “Consistent Deactivation” from SRDF/A to SRDF/S

Enabling and disabling “Consistency” within an SRDF/A session

Discuss Transmit Idle and DSE (Delta Set Extension)

Define Multi Session Consistency (MSC)





What is SRDF/A (Asynchronous)

Asynchronous remote mirroring• Minimal impact to

production applications• Extended distance• Always consistent image on

R2Efficient bandwidth usageSupports Mainframe and Open SystemsComplements other SRDF solutions• Meet a wide range of RPO

and RTO service level requirements

SRRD/A’s unique architecture delivers a remote mirroring solution that has no impact on production applications over extended distance because I/O requests from the host are acknowledged locally. Changes made to the same data blocks are periodically sent only once to the remote Symmetrix. This enables significant operational savings through reduced bandwidth requirements. Moreover, SRDF/A provides an alternative Disaster Recovery solution, in addition to SRDF/S, by maintaining a consistent image of a RDBMS (Relational DataBase Management System) on the R2 volumes at all times.

SRDF/A is a single solution supporting both Mainframe and Open Systems. It also compliments SRDF solutions to meet mixed service level requirements.




Industry’s Traditional Write Ordering

Host I/O Writes to cacheEvery write must be time stamped, ordered and sent to the target sideWrites must be re-ordered before de-staging to diskWrites de-staged to disk

write # 1

write # 2

write # 3

write # 4

write # 5

write # 6

write # 7

Cache

write # 7

write # 6

write # 2

write # 4

write # 3

write # 5

write # 1

Cache

Source Location Target Location

1

2

3

4

1

2

3

4

Traditional approaches to asynchronous mirroring have their architectural shortfalls. Uses a combination of cache and files to perform mirroring Timestamps or sequence numbers are applied to each and every incoming write Each write must have a timestamp applied to it before sending it to the remote side

That means every single write MUST be sent to the remote side, and because they do not necessarily arrive in order, they must be re-sequenced before being applied to disk. If you have writes number 100-200 pending at the remote side, all waiting for write number 99 to arrive, the system must re-sequence and wait for number 99 to arrive before committing writes 100-200.

This creates a significant amount of overhead and data management activity in both the source and target systems as they scramble to time-stamp, send, re-order, wait for a dependant time-stamp, and then eventually commit the writes to disk at the target side.




SRDF/A Architecture / Delta Sets

Target Sym

Source HostSite A

Target HostSite B

Source(R1)

Target(R2)

CycleN

CycleN-1

CycleN-1

CycleN-2

SRDF/A Delta Set Begins

Source Sym Capture Transmit

Apply Receive

SRDF/A Device Pair

Active Session

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

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.




Dependent Write 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 been acknowledged to

the host, must be dependent on ‘A’– Implemented by the application, such as RDBMS’s

SRDF/A ensures that:– ‘A’ and ‘B’ are in the same Delta Set or– ‘B’ is in later Delta Set

Delta Sets

ApplyN-2

CaptureN

TransmitN-1

ReceiveN-1

Source Target

All commonly used database management systems are inherently dependent write consistent. For instance, a DBMS (DataBase Management System) will not perform a log write, indicating that a transaction is complete, until it has received an acknowledgement from the storage subsystem that the log data pertaining to the transaction itself was completely written to disk. Symmetrix honors this logic in SRDF/A by treating any successor I/O, which arrives after a predecessor I/O as a dependent I/O.




List the configuration of the Symmetrix to verify that relevant System Attributes have been set– symcfg list –sid 80 -v

List the Remote Adapters configured on the Symmetrix and verify their status– symcfg list –ra all –sid 80

List the RDF Groups that have been created on the Symmetrix– symcfg list –rdfg all

– symcfg list –rdfg 101

Verifying the SRDF/A Environment




System AttributesC:\>symcfg list –sid 80 -v


---Output Truncated-----

Product Model : VMAX-1SE



Switched RDF Configuration State : Enabled

Concurrent RDF Configuration State : Enabled

Dynamic RDF Configuration State : Enabled

Concurrent Dynamic RDF Configuration : Enabled


SRDF/A Maximum Host Throttle (Secs) : 0

SRDF/A Maximum Cache Usage (Percent) : 94

As noted in the SRDF/S module, the RDF Configuration States are all Enabled by default on the Symmetrix V-Max array with Enginuity 5874. The use of Host Throttle, and Maximum Cache Usage attributes will be explained later in this module.




List of All SRDF GroupsC:\>symcfg list -rdfg all -sid 80 -rdfa


S Y M M E T R I X R D F A G R O U P S

-------- ----------- -------- ------ --- --- ---------

RA-Grp Group Flags Cycle Pri Thr Transmit

Name CSRM TDA time Idle Time

-------- ----------- -------- ------ --- --- ---------

41 (28) lin1asyn41 -IS- XI. 30 33 50 000:00:00

42 (29) lin1asyn42 -IS- XI. 30 33 50 000:00:00

43 (2A) lin2asyn43 -IS- XI. 30 33 50 000:00:00

44 (2B) lin2asyn44 -IS- XI. 30 33 50 000:00:00

100 (63) win1sync -IS- XI. 30 33 50 000:00:00

101 (64) win1async -IS- XI. 30 33 50 000:00:00

A partial listing of the output is shown in the slide. None of the groups are in SRDF/A mode at this point in time. Notice that Transmit Idle is enabled by default when the SRDF Groups (RA groups) are created. The Minimum Cycle Time for SRDF/A is the default 30 seconds. The default priority for the SRDF groups is 33. More about the group priority later in the module.

Legend:

RDFA Flags :

(C)onsistency : X = Enabled, . = Disabled, - = N/A

(S)tatus : A = Active, I = Inactive, - = N/A

(R)DFA Mode : S = Single-session, M = MSC, - = N/A

(M)sc Cleanup : C = MSC Cleanup required, - = N/A

(T)ransmit Idle : X = Enabled, . = Disabled, - = N/A

(D)SE Status : A = Active, I = Inactive, - = N/A

DSE (A)utostart : X = Enabled, . = Disabled, - = N/A




List of an Individual RDF GroupC:\>symrdf list -rdfg 101


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

---- ---- -------- --------- ----- ------- ------- --- ---- -------------


014A 014A R1:101 RW RW RW S..1. 0 0 RW WD Synchronized

Total -------- --------

Track(s) 0 0

MB(s) 0.0 0.0

The list of devices in SRDF Group 101 is displayed here. The two devices 149 and 14A are R1 devices on the local Symmetrix 80. They are in Synchronous mode of SRDF operations, and they are currently Synchronized with their remote mirrors.

Legend for MODES:




(Mirror) T(ype) : 1 = R1, 2 = R2





Transitioning to SRDF/A Mode

From Synchronous– If the devices are in Synchronized state, then by definition the R2

devices have a consistent image. Enabling SRDF/A immediately provides consistent data on the R2

From Adaptive Copy Disk– Any invalid tracks owed to the R2 are synchronized. Two cycle

switches after Synchronization, SRDF/A provides consistent data on the R2

From Adaptive Copy Write Pending– Write pending slots are merged into the Active SRDF/A cycles.

When there are no more write pending slots, it takes an additional two cycle switches before R2 data is consistent

SRDF/A can be enabled when the device pairs are operating in any of the listed modes. In the case of Adaptive Copy to SRDF/A transitions, it takes two additional cycle switches after resynchronization of data for the R2 devices to be consistent.




Enabling SRDF/AC:\>set SYMCLI_DG=srdfadg

C:\>symrdf set mode async –nop

C:\>symrdf enable –nop

C:\>symrdf query –rdfa

Device Group (DG) Name : srdfadg

DG's Type : RDF1

DG's Symmetrix ID : 000194900180 (Microcode Version: 5874)

RDFA Session Number : 100

RDFA Cycle Number : 5

RDFA Session Status : Active

RDFA Consistency Exempt Devices : No

RDFA Minimum Cycle Time : 00:00:30

RDFA Avg Cycle Time : 00:00:40

Duration of Last cycle : 00:00:30

RDFA Session Priority : 33

Any SRDF/A operation (with the exception of consistency exempt, discussed later in the module) must be performed on ALL devices in an SRDF group (RA group). This means that all devices in an SRDF group must be in the same SRDF Device group as well. This is in contrast with SRDF/S, where operations can be performed on a subset of devices in an SRDF group.

The mode of SRDF operation is set to Asynchronous for the device pairs in the device group srdfadg. SRDF/A consistency is enabled. symrdf query –rdfa gives detailed information about the SRDF/A state of the device group. As can be seen, the SRDF/A session has been assigned a number 100. Five cycle switches have completed and the SRDF/A session is active.




Enabling SRDF/A (continued)Tracks not Committed to the R2 Side: 0

Time that R2 is behind R1 : 00:00:52

R2 Image Capture Time : Tue Jun 30 13:55:08 2009


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A


Device Dev E Tracks Tracks S Dev E Tracks Tracks MDACE STATE

-------------------------------- -- ------------------------ ----- ------------

DEV001 0149 RW 0 0 RW 0149 WD 0 0 A..X. Consistent

DEV002 014A RW 0 0 RW 014A WD 0 0 A..X. Consistent

Transition to SRDF/A is immediate (A…X.) and the pair state is immediately Consistent.

Legend for MODES:




C(onsistency State) : X = Enabled, . = Disabled, M = Mixed, - = N/A





Example: ACP_Disk to SRDF/AC:\>symrdf query


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------


DEV002 014A RW 0 0 RW 014A WD 0 0 C.D. Synchronized

Total -------- -------- -------- --------

Track(s) 0 0 0 0

MB(s) 0.0 0.0 0.0 0.0

In this example, the device pairs are operating in SRDF Adaptive Copy Disk Pending Mode (C.D.)




Enabling SRDF/A

C:\>symrdf set mode async –nop

C:\>symrdf enable

C:\>symrdf query –rdfa


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0149 RW 0 0 RW 0149 WD 0 0 A..X. SyncInProg

DEV002 014A RW 0 0 RW 014A WD 0 0 A..X. SyncInProg

Note that the transition into SRDF/A is immediate (A..X.), and the group has been enabled for consistency. However, the pair state is SyncInProg. R2 device does not have consistent data until at least two cycle switches have occurred.




SRDF/A Consistent Deactivation from Async to Sync

C – CaptureT – TransmitR – ReceiveA - Apply

Phase 3

R1R1

T

CR2R2

A

R

AsyncTransition request

Phase 1

Switch

R1R1

T

CR2R2

A

RPhase 2

SyncSwitch

R1R1

T

CR2R2

A

R

CacheCache

The transition takes two cycle switches to complete and may not be possible to do if there isn’t enough cache on the R2 side. When the request to transition from SRDF/A to SRDF/S is received, the Consistent Deactivation transition happens in three phases.

In the first phase, SRDF/A operates normally. Then at the next cycle switch, which guarantees an empty capture cycle at the R1 side, the second phase occurs.

In the second phase, new writes at the R1 side are sent directly in synchronous mode to the R2 side, with one key exception. As these write arrive at the R2, they are stored in receive delta set at the R2 side. The transmit delta set data from the R1 side also flows into the receive delta set on the R2 side. At the next cycle switch (two switches into the process), a transition to the third phase occurs.

When all data from the transmit delta set has been received on the R2 side, that data as well as the accumulated writes that came across in synchronous mode are applied to the R2. If a failure occurs before that final cycle switch, data in the incomplete receive delta set is converted to invalid tracks but not written to disk. Extra cache is needed on the R2 side to hold the additional synchronous data that needs to be stored on the R2 Symmetrix.




SRDF/A – Transmit Idle

Transmit Idle is enabled by default when Dynamic SRDF Groups are created

After links fail – Data transmission from source to target stops – SRDF/A remains active and the capture cycle grows in cache– Session is suspended if cache fills up

After links are revived, cycle switching continues

Should be used if using Delta Set Extension

SRDF/A Transmit Idle is a feature of SRDF/A that provides it with the capability of dynamically and transparently extending the Capture, Transmit, and Receive phases of the SRDF/A cycle while masking the effects of an “all SRDF links lost” event.

Without the SRDF/A Transmit Idle feature, an “all SRDF links lost” event would normally result in the abnormal termination of SRDF/A. SRDF/A would become inactive. The SRDF/A Transmit Idle feature has been specifically designed to prevent this event from occurring. Transmit Idle is enabled by default when dynamic SRDF groups are created. When all SRDF links are lost, SRDF/A still stays active. The capture cycle grows in cache. Eventually if and when a cache full condition occurs, then SRDF/A will become inactive. A further feature called Delta Set Extension (DSE) discussed later can enable paging-out and paging-in of data from/to cache, in the event cache threshold is reached.




Query after a Temporary Link LossC:\>symrdf query -rdfa





-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0149 RW 0 0 RW 0149 NA NA NA A..X- TransIdle

DEV002 014A RW 0 0 RW 014A NA NA NA A..X- TransIdle

Note that the session is still active, and that the RDF pair state has become TransIdle.




SRDF/A – Delta Set ExtensionAllows offloading of SRDF/A delta sets from cache to specially configured device pools – Delta Set Extension Pools

Intended to make SRDF/A resilient to temporary increases in write workloads or loss of link– Should be used in conjunction with Transmit Idle

SymmCache

R1 R2

SymmCache

Local Symm Remote Symm

DSE Pool

Transmit Idle enabled on both sides

SRDF/A Delta Set Extension (DSE) provides a mechanism for augmenting the cache-based Delta Set buffering mechanism of SRDF/A with a disk-based buffering ability. This extended Delta Set buffering ability may allow SRDF/A to ride through larger and/or longer SRDF/A throughput imbalances than would be possible with cache-based Delta Set buffering alone.

Delta Set Extension (DSE), extends the cache space available for SRDF/A session cycles by off loading some or all of its cycle data from cache to preconfigured disk storage, or pools, which are similar to SAVE device pools.

Using SRDF/A DSE pools provide a safety net for running SRDF/A sessions; however, SRDF/A will continue to operate normally with this feature disabled.




SRDF/A – Delta Set Extension (continued)

Save Pools are designated as DSE pools at creation– Contains SAVE devices of a single emulation

CKD, FBA or AS400

Pools can be associated (shared) with multiple SRDF/A SRDF groups

Must have at least one DSE pool configured with a type that matches one of the device types in the SRDF/A group in order to activate DSE

Pools can optionally start automatically when SRDF/A is enabled

SRDF/A DSE Pools and Save devices are managed in the same way as TimeFinder/Snap pools.A SRDF group can have at most one pool of each emulation.A single rdfa_dse pool can be associated with more than one SRDF group, similar to snap pools shared by multiple snap sessions.SRDF/A DSE Threshold sets the percentage of cache used for SRDF/A that will start offloading cache to disk.DSE must be enabled on both the source and target arrays. Extension on only one side of the links would lead to failure of the SRDF/A recovery with SRDF/A dropping because the R2 side would fail to have enough cache to hold the large and extended Transmit cycle.




How DSE Fits Into SRDF/A Data Flow

Traditional SRDF/A data flows continue to interact directly with the cache buffer

Separate DSE Task monitors Delta Set cache utilization and transfers Delta Set data between cache and disk

Transmit Idle must be enabled on both sides

Cache Buffer

DSE Task

DSE Pool


SRDF/A has always buffered Delta Set data in cache. However, a buffer full condition causes SRDF/A to drop. With SRDF/A DSE, delta set data is offloaded to disk buffers (DSE Pools) by the DSE task.





SRDF/A DSE solves abnormal and temporary problems– Unexpected host load– Link bandwidth issues– Temporary link loss (use with Transmit Idle)

Increases resilience for SRDF/A

DSE is not designed to solve any permanent and persistent problems:– Wrong configurations such as:

Unbalanced cache or unbalanced device protection types between the source and the target SymmetrixInsufficient cacheInsufficient bandwidth

– Host writes consistently exceeding SRDF link bandwidth– Prolonged link outages

When Can DSE Help You?

SRDF/A DSE should be used with the Transmit Idle feature. Thus, SRDF/A can ride through a temporary link loss. Once the DSE threshold is reached, data is paged out to the DSE Pools.




Recovering after Loss of Links

It is recommended to make a “Gold Copy” of the R2 prior to starting any resynchronization

In the event of an extended loss of link, a large number of R2 invalid tracks can build up on the R1 side

It is advisable to enable SRDF/A after the two sides are synchronized

Resynchronization prior to enabling SRDF/A can be performed by:– Setting SRDF mode to Adaptive Copy Disk Mode

As noted earlier, during resynchronization, R2 does not have consistent data. A copy of the consistent R2 data prior to resynchronization can safeguard against unexpected failures during the resynchronization process. When the link is resumed, if there are a large number of invalid tracks owed by the R1 to its R2, it is recommended that SRDF/A not be enabled right away. Enabling SRDF/A right after link resumption causes a surge of traffic on the link due to (a) shipping of accumulated invalid tracks, and (b) the new data added to the SRDF/A cycles. This would lead to SRDF/A consuming more cache and reaching the System Write Pending limit. If this happens, SRDF/A would drop again. Like with SRDF/S, resynchronization should be performed during periods of relatively low production activity.

Resynchronization in Adaptive Copy Disk mode minimizes the impact on the production host. New writes are buffered and these, along with the R2 invalids, are sent across the link. The time it takes to resynchronize is elongated.

Resynchronization in Synchronous mode impacts the production host. New writes have to be sent preferentially across the link while the R2 invalids are also shipped. Switching to Synchronous is possible only if the distances and other factors permit. For instance, if the norm is to run in SRDF/S and toggle into SRDF/A for batch processing (due to higher bandwidth requirement). In this case, if a loss of links occurs during the batch processing, it might be possible to resynchronize in SRDF/S.

In either case, R2 data is inconsistent until all the invalid tracks are sent over. Therefore, it is advisable to enable SRDF/A after the two sides are completely synchronized.




Recovery ExampleC:\>symrdf query -rdfa


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0149 RW 0 103 NR 0149 NA NA NA A..X- Partitioned

DEV002 014A RW 0 104 NR 014A NA NA NA A..X- Partitioned

Total -------- -------- -------- --------

Track(s) 0 207 NA NA

MB(s) 0.0 12.9 NA NA

In this example there is a workload on the devices in SRDF/A enabled state. A permanent loss of link place the devices in a Partitioned state. Production work continues on the R1 devices and the new writes arriving for the R1 devices are marked as invalid or owed to the R2. SRDF/A is dropped and session is Inactive.




Recovery Example (continued)C:\>symrdf query –rdfa



RDFA Session Status : Inactive


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0149 RW 0 103 NR 0149 WD 0 0 A..X. Suspended

DEV002 014A RW 0 104 NR 014A WD 0 0 A..X. Suspended

When the links are active again, note that the pair state has moved to Suspended. Even though the Mode indicates SRDF/A (A..X.), SRDF/A session is inactive.




Recovery Example – Set Mode to Adaptive CopyC:\>symrdf disable –nop

C:\>symrdf set mode acp_disk -nop


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0149 RW 0 103 NR 0149 WD 0 0 C.D.. Suspended

DEV002 014A RW 0 104 NR 014A WD 0 0 C.D.. Suspended

As mentioned, we will next place the device group in Adaptive Copy Disk mode (C.D..). As consistency was enabled when the links were lost, we have to first disable consistency before changing the mode to Adaptive Copy Disk. The RDF pair state is still Suspended. Changes made to the R1s accumulate as R2 invalid tracks.

The pair state can now be resumed (symrdf resume). Once the RDF pair state goes to Synchronized, the mode can be changed to Asynchronous and consistency enabled.

symrdf set mode async

symrdf enable




SRDF Session Recovery ToolEMC SRDF session recovery utility is initiated by the symrecover command

Runs in the background and monitors the state of SRDF/A or SRDF/S sessions

If failure is detected, automatic recovery and restart is attempted based on symrecover options file (pre-configured)The symrecover command can be run from the R1 or R2 side

As long as all the devices making up the group being monitored are fully viewable from the hostWhen concurrent RDF is used, this command must be run from the R1 side

The symrecover command can be run manually from the command line, but more commonly will be setup to run continuously in the background by using the Windows Scheduled Tasks, the UNIX CRON/scheduled. The symrecover command can be run from either the R1 or the R2 side, as long as all the devices in the monitored group are fully viewable from the execution host.

However, when concurrent RDF is used, this command must be run from the R1 side. To manually start symrecover for an SRDF/A composite group named RDFAmon, using the options file named cg_mon_opts, enter: symrecover start -cg RDFAmon -mode async -options cg_mon_opts

The following is an example of the cg_mon_opts option file:

# Option file for symrecover#######################################################goldcopy_type_r2 = bcvgoldcopy_bcv_r2_mirror_state_startup = establishgoldcopy_bcv_r2_mirror_state_post_restart = splitgoldcopy_max_wait_bcv = 3600log_level = 3monitor_cycle_time = 600monitor_only = 0rdfg = name:London ...




Failover/Failback with SRDF/A

If the primary site fails, data on R2 is consistent up to the last Apply cycle (N-2)– Partial data in the Receive cycle is discarded

SRDF failover procedure can then be executed and the workload can be started on the R2 devices– Consistency protection should be disabled prior to issuing symrdf

failover without the –force option

Failback procedure after the primary site has been restored is identical to Synchronous SRDF– After symrdf failback command completion, workload can be

restarted on the R1 devices. SRDF/A can be enabled

Again, it is advisable to make a copy of the R2 prior to executing a failback operation. When workload is resumed on the R1 devices immediately after a failback, accumulated invalid tracks have to be synchronized from the R2 to the R1, and new writes must be shipped from the R1 to R2. If there is an interruption now, data on the R2 is not consistent. Even though SRDF/A can be enabled right after a failback, for reasons stated earlier, it should be enabled after the SRDF pairs entered the Synchronized state.




Multiple Independent SRDF/A GroupsC:\>symcfg list –ra all –sid 80



Remote Local Remote


RF-7G 07G 103 7 RDF-R1 - 000194900181 9 (08) 9 (08) Online

- 000194900181 102 (65) 102 (65)

RF-8G 08G 104 8 RDF-BI-DIR - 000194900182 29 (1C) 29 (1C) Online

- 000194900181 102 (65) 102 (65)

RF-7H 07H 119 7 RDF-R1 - 000194900181 100 (63) 100 (63) Online

- 000194900181 101 (64) 101 (64)

RF-8H 08H 120 8 RDF-R1 - 000194900181 100 (63) 100 (63) Online

- 000194900181 101 (64) 101 (64)

SRDF group 102 is configured to use RF-7G and 8G, SRDF group 101 is configured to use RF-7H and 8H.




Multiple Independent SRDF/A Groups (continued)C:\>symrdf –g srdfadg query –rdfa





-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0149 RW 0 0 RW 0149 WD 0 0 A..X. Consistent

DEV002 014A RW 0 0 RW 014A WD 0 0 A..X. Consistent

Devices in SRDF group 101 are in asynchronous mode and are consistent. Note that the current cycle number for this SRDF/A session is 155.









-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 014B RW 0 0 RW 014B WD 0 0 A..X. Consistent

DEV002 014C RW 0 0 RW 014C WD 0 0 A..X. Consistent

Devices in SRDF group 102 are in asynchronous mode and are consistent. Note that the current cycle number for this SRDF/A session is 28. Cycle switches for the two SRDF groups occur independent of each other.







RDFA Session Status : Inactive


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 0149 RW 0 0 NR 0149 NA NA NA A..X- Partitioned

DEV002 014A RW 0 0 NR 014A NA NA NA A..X- Partitioned

Loss of link for RF-7H and RF-8H causes the devices in the SRDF group 101 to go into a partitioned state. SRDF/A is dropped and the session status is Inactive.




Multiple Independent SRDF/A Groups (continued)

C:\>symrdf –g srdfadg2 query –rdfa





-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

DEV001 014B RW 0 0 RW 014B WD 0 0 A..X. Consistent

DEV002 014C RW 0 0 RW 014C WD 0 0 A..X. Consistent

How ever as links for RF-7G and RF-8G are still available, the SRDF group 102 continues to be in SRDF/A and proceed with its cycle switches.




What is SRDF/A Multi Session Consistency (MSC)Manages multiple SRDF/A sessions logically as if they were a single session – RDF Daemon for Open System

support – Sessions can be within or across

Symmetrix arrays– Ensures a complete, restartable

point-in-time copy on the remote side

DeltaSet

DeltaSet

MSC

Since Enginuity 5671, consistency protection for SRDF/Asynchronous devices is provided using Multi Session Consistency (MSC). If one or more source (R1) devices in an SRDF/A MSC enabled SRDF consistency group cannot propagate data to their corresponding target (R2) devices. The MSC process suspends data propagation from all R1 devices in the consistency group, halting all data flow to the R2 targets. RDF daemon (storrdfd) performs cycle-switching and cache recovery operations across all SRDF/A sessions in the group. This ensures that a consistent R2 data copy of the database exists at the point-in-time any interruption occurs. If a session has devices from multiple Symmetrix arrays, then the host running storrdfd must have access to all the arrays to coordinate cycle switches. It would be recommended to have more than one host with access to all the arrays running the storrdfd daemon. In the event one host fails, the surviving host can continue with MSC cycle switches.

A composite group must be created using the RDF consistency protection option (-rdf_consistency) and must be enabled using the symcg enable command before the RDF daemon begins monitoring and managing the MSC consistency group.




What is SRDF/A Multi Session Consistency (cont)RDF Daemon coordinates cycle switching of the SRDF/A MSC group sessions as a single entity– Responsible for detecting ‘failure’

conditions that would cause data on the R2 side to become inconsistent

– When a ‘failure’ condition is detected, the cycle switching for all SRDF/A sessions in the group are stopped in a manner that leaves the R2 side with a consistent data image

DeltaSet

DeltaSet

MSC

The RDF process daemon maintains consistency for enabled composite groups across multiple Symmetrix arrays for SRDF/A with MSC. For the MSC option (-rdf_consistency) to work in an RDF consistency-enabled environment, each locally-attached host performing management operations must run an instance of the RDF daemon (storrdfd). Each host running storrdfd must also run an instance of the base daemon (storapid).. Optionally, if the Group Naming Services (GNS) daemon is also running, it communicates the composite group definitions back to the RDF daemon. If the GNS daemon is not running, the composite group must be defined on each host individually.

How does Multi Session Consistency work?

In single session, SRDF/A cycle switch occurs when the Transmit cycle on the R1 side AND the Apply cycle on the R2 side are both empty. The switch is controlled by Enginuity.

In MSC, the Transmit cycles on the R1 side of all participating sessions must be empty, and also the corresponding Apply cycles on the R2 side. The switch is coordinated and controlled by the RDF Daemon.

All host writes are held for the duration of the cycle switch. This ensures dependent write consistency. If one or more sessions in MSC complete their Transmit and Apply cycles ahead of other sessions, they have to wait for all sessions to complete, prior to a cycle switch.




SRDF/A MSC OperationsSet SYMAPI_USE_RDFD = ENABLE in options configuration file

Create a Composite Group (CG) with the -rdf_consistency option• Group definition is passed to the RDF Daemon as a ‘candidate group’• If the Daemon is not already running, it is started automatically

Add all of the devices in the multiple SRDF/A sessions to the CG

Put all CG devices into Async modesymrdf -cg <CGname> set mode async

Enable CG devices for consistency protectionsymcg -cg <CGname> enable

• The RDF Daemon is notified that the group should now be monitored• Enable command must be done after the devices are put into Async mode

When the devices become RW on the link, the RDF Daemon:• Starts performing cycle switching • Actively monitors the health of the group to maintain R2 data consistency

There are three ways the RDF daemon can be started. If the RDF daemon is enabled, the daemon is started automatically by the Solutions Enabler libraries the first time they attempt to connect with it, which can cause a slight delay in performance on that initial connection while the daemon starts and builds its cache.




Managing RDF DaemonModify the SYMAPI options file

SYMAPI_USE_RDFD=ENABLE

Start Daemonstordaemon start storrdfd

Stop Daemonstordaemon shutdown storrdfd

DeltaSet

DeltaSet

MSC

Prior to starting storrdfd, ensure that your default SYMAPI configuration database is up-to-date, since storrdfd uses the stored information to establish contact with your Symmetrix arrays.

There are three ways the RDF daemon can be started. First, if the RDF daemon is enabled, the daemon is started automatically by the Solutions Enabler libraries the first time they attempt to connect with it, which can cause a slight delay in performance on that initial connection while the daemon starts and builds its cache.

Second, the daemon can be started manually via the stordaemon command line utility as follows:

stordaemon start storrdfd [-wait Seconds]

By default, the stordaemon command waits 30 seconds to verify the daemon is running. To override this, use the -wait option.

Third, the daemon can be set to start automatically every time the local host is booted using the following command line:

stordaemon install storrdfd -autostart

Pre-starting the daemon, either manually or via the automatic option, is useful because the daemon may take a while to initially construct its cache - depending on the number of groups and Symmetrix arrays it has to load.




SRDF/A with MSC: ExampleC:\>symrdf -cg srdfacg query –rdfa


-------------------------------- ------------------------- ----- ------------

ST LI ST

Standard A N A

Logical Sym T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair


-------------------------------- -- ----------------------- ----- ------------

DEV001 0149 RW 0 0 NR NA NA NA NA A..X- Partitioned

DEV002 014A RW 0 0 NR NA NA NA NA A..X- Partitioned

---Output Truncated-------

Logical Sym T R1 Inv R2 Inv R1 Inv R2 Inv RDF Pair

Device Dev E Tracks Tracks Dev E Tracks Tracks MDACE STATE

-------------------------------- -- ----------------------- ----- ------------

DEV003 014B RW 0 0 NR 014B WD 0 0 A..X. Suspended

DEV004 014C RW 0 0 NR 014C WD 0 0 A..X. Suspended

We wish to control SRDF groups 101 and 102 as one entity. A composite group has been created and enabled using the following commands:

•symrdf –g srdfadg disable•symrdf –g srdfadg2 disable•symdg dg2cg srdfadg srdfacg –rdf_consistency•symdg dg2cg srdfadg2 srdfacg –rdf_consistency -rename•symcg –cg srdfacg enable

The cycle numbers for both the SRDF groups are now reset to the same value. Loss of link for one group suspends propagation of data for the other group as well. When the links are restored, recovering from this state can be accomplished as usual:

symrdf –cg srdfacg establish

Once the invalid tracks are marked, merged, and synchronized, MSC protection is automatically re-instated; i.e., user does not have to issue symcg –cg srdfacg enable again.




MSC Cleanup

There are three possible cleanup scenarios in case of a failure in MSC:

• All Receive cycles are marked as complete. In this case, the Receive cycles are committed – i.e. promoted to Apply

• Some Receive cycles are marked as complete and others are marked as incomplete. In this case, ALL Receive cycles are discarded

• Some Receive cycles have been promoted to Apply, where as some of them have not. In this case, the promoted Receive cycles and those not yet promoted are committed

11

22

33

The first scenario is easy to understand. In this instance, the Receive cycles contain the most recent and consistent data.

The second situation arises if there is a failure when some Receive cycles are complete while the others are in transit. In this case, clearly it is only the Apply cycles of all sessions that contain the consistent data. Therefore, ALL Receive cycles are discarded.

To understand the third scenario, keep in mind the following: For a cycle switch to be initiated, ALL Transmits must be empty and all Apply’s must be empty. This means that the failure has occurred DURING the cycle switch process in this case. Receive can only be promoted to Apply on a cycle switch. In MSC, cycle switch is sent to all sessions at once. So each of them is in the process of executing a cycle switch. For example, failure occurred prior to promoting some Receives to Apply. Therefore, the Receives not yet promoted should be committed along with those that have already been promoted.




MSC Cleanup

Cleanup is automatically performed by the RDF Daemon on the R1 side, if the link to the R2 side is available

If the link is unavailable (total site failure on the R1 side), then invocation of any SRDF command, such as symrdf failover or split, from the R2 side performs the automatic cleanup




SRDF/A Configuration Parameters

Two SRDF/A Symmetrix Array-wide parameters• Maximum SRDF/A Cache Usage• Maximum Host Throttle Time

Two SRDF Group (aka SRDF/A Session) level settings• Minimum Cycle Time• Session Priority

Settable via the SYMCLI symconfigure command– Set Symmetrix Metrics for Symmetrix level attributes

set symmetrix rdfa_cache_percent = 94;

set symmetrix rdfa_host_throttle_time = 0;

– Set RDF Group Metrics for Group level attributesset rdf group 3, session_priority = 33;

set rdf group 3, minimum_cycle_time = 30;




SRDF/A System Configuration Parametersrdfa_cache_percent• Defaults to 94, with a range of valid values from 0 to 100 percent • It is the percentage of the Max# of System Write Pending Slots available

to SRDF/A. The purpose is to ensure that other applications can utilize some of the WP limit

• When SRDF/A hits its WP cache limit it will be forced to drop SRDF/A sessions to free up cache

• Setting it lower reserves WP limit for non-SRDF/A cache usage. Setting it higher, allows SRDF/A to potentially use more of the cache WP limit, potentially creating performance problems for other applications

rdfa_host_throttle_time• Defaults to 0, with a range of valid values from 0 to 65535• If >0, this value overrides the rdfa_cache_percent and session_priority

settings• When the System WP Limit is reached, throttling will delay a write from

the host until a cache slot becomes free• The value is the number of seconds to throttle host writes before dropping

SRDF/A sessions. A value of 65535 means wait forever

Each Symmetrix has an array-wide Max # of System Write Pending Slots limit (generally calculated as 80% of available cache slots). The purpose of this limit is to ensure that cache is not filled with Write Pending (WP) tracks, potentially preventing fast writes from hosts, because there is no place to put the I/O in cache.SRDF/A creates WP tracks as part of each cycle.




SRDF/A Group Level Parameterssession_priority– Number between 1 and 64 where 1 is highest (default is 33)– Lower priority sessions drop first when cache becomes scarce

minimum_cycle_time– settable from 1 to 59 secs. (default is 30); For MSC the range is 3 – 60

seconds

rdfa_transmit_idle– enable or disable

rdfa_dse_pool– specify name and emulation

rdfa_dse_threshold– expressed as a percent

rdfa_dse_autostart– enable or disable

session_priority = The priority used to determine which SRDF/A sessions to drop if cache becomes full. Values range from 1 to 64, with 1 being the highest priority (last to be dropped).

minimum_cycle_time = The minimum time to wait before attempting an SRDF/A cycle switch. Values range from 1 to 59 seconds, minimum is 3 for MSC.

rdfa_transmit_idle = Indicates whether this group has transmit idle support enabled.

rdfa_dse_pool = The name of a collection of SAVE devices used for SRDF/A DSE.

emulation = The pool emulation type.

rdfa_dse_threshold = Specifies the percentage of the Symmetrix array’s write pending limit. Once the cache usage of all active groups in the Symmetrix array exceeds this limit, data tracks for this group start to spill over to disks. Valid values are from 20 to 100. The default value is 50.

rdfa_dse_autostart = Specifies whether SRDF/A DSE is automatically activated when SRDF/A session is activated for the group. Valid values are ENABLE or DISABLE. DISABLE is the default.




Monitoring SRDF/A

Using the symstat command optionssymstat –type cycle –reptype rdfa –rdfg all –i <interval>

symstat –type cache –reptype rdfa –rdfg all –i <interval>

symstat –type request –reptype rdfa –rdfg all –i <interval>

Using the symevent commandsymevent list -error

Examples are displayed in the next several slides.




Monitoring SRDF/A (continued)C:\>symstat -type cycle -reptype rdfa -rdfg all -i 60

SRDF/A Session Cycle Summary Information

Symmetrix Id : 000194900180

Timestamp : 15:07:26

Session Cycle Time (sec) Cycle Size

------------------ ------------------- ---------------

RA Active Last

Device Group Name Grp Type Number Cycle# Min Avg Last Switch Active Inactive

----------------- --- ---- ------ ------ --- --- ---- ------ ------ --------

RaGrpNum_102 102 RDF1 101 158 30 30 30 15 0 0

RaGrpNum_101 101 RDF1 100 158 30 30 30 15 0 0

This output was captured from the R1 side. As displayed, the Minimum cycle time for each of the SRDF/A session is at the default of 30 seconds. The Active Cycle is the Capture and the Inactive is the Transmit, as this output is from the R1 (source) perspective.

From the R2 prospective the Active Cycle is Apply and the Inactive is Receive.

Legend for the Attribute of Cycle Size:

RDF1: Active = Capture Inactive = Transmit

RDF2: Active = Apply Inactive = Receive




Monitoring SRDF/A (continued)C:\>symstat -type cache -reptype rdfa -rdfg all -i 60

SRDF/A Session Cache Summary Information

Symmetrix Id : 000194900180

Timestamp : 15:12:55

System Write Pending Limit : 129419 (7.90 GB)

Cache Slots available for all SRDF/A sessions : 121653 (7.43 GB)

Total Local Write Pending Count : 0

Total System Write Pending Count : 0

Session Rdfa DSE Cache Cache

RA --------------------- --------------- Slots Full

Device Group Name Grp Type Num Pri Status Thr UsedTrks In Use (%)

----------------- --- ---- --- --- -------- --- ----------- ----------- -----

RaGrpNum_102 102 RDF1 101 33 Active 50 0 0 0.0

RaGrpNum_101 101 RDF1 100 33 Active 50 0 0 0.0

Note that the Cache Slots available for all SRDF/A sessions is 94% of the System Write Pending Limit (121653/129419). Both the sessions have a default priority value of 33.




Monitoring SRDF/A (continued)C:\>symevent list -error


Time Zone : Eastern Daylight Time

Detection time Dir Src Category Severity Error Num

------------------------ ------ ---- ------------ ------------ ----------

Thu Jul 02 11:54:38 2009 RF-8H Symm RDF (101) Error 0x0074

SRDF/A Session dropped, no online RAs

Thu Jul 02 13:42:27 2009 RF-8H Symm RDF (101) Error 0x0074

SRDF/A Session dropped, no online RAs

The dropping of the SRDF/A session can also be displayed via the symevent command.




Adding/Removing Devices to/from an Active SRDf/A Group

Prior to SE 7.0 and Enginuity 5874, when adding or removing devices to/from an active SRDF/A session – All devices currently in the SRDF/A session have to be suspended,

causing the session to become inactive– If there are writes to the current devices in the session, these will

build up as invalid tracks– After adding/removing devices they can be resumed, which will make

the session active again– All devices, including the existing ones, will be in SyncInProg until all

the invalid tracks are cleared, and two cycle switches occur– If during this time, there is a failure in the primary site, the R2’s will

not be consistent – resulting in a DR exposure

This process can be cumbersome if the application is growing rapidly and more devices have to be added to an active SRDF/A group frequently.




The SRDF/A Consistency Exempt FeatureIt is a feature of Enginuity 5874 that allows devices to be exempt from the Dependent Write Consistency calculation– Requires Enginuity 5874 and above, as well as SE 7.0

Consistency Exempt attribute is maintained at an SRDF mirror level. Once set by the user, it is persistent until Enginuity clears it. The attribute is removed under the following conditions:– Deleting SRDF pairs– Moving SRDF pairs to another SRDF group– Resuming SRDF pairs

After all invalid tracks for the resumed pairs are synchronized -and-

Two cycle switches have occurred

Consistency Exempt feature requires Enginuity 5874 and above, as well as Solutions Enabler 7.0. Consistency exempt can be set from either side. R2 will report the consistency exempt state if R1 is not available. Note that the attribute can only be removed by Enginuity. There is no CLI command to remove this attribute. Solutions Enabler 7.0 provides a flag to set the consistency exempt attribute, but none for removing the attribute. With consistency exempt, the existing devices in an active SRDF/A session need not be suspended when adding new devices to the session. Consistency is maintained for the existing devices. The new devices are excluded from the consistency calculation until they are synchronized, move into a consistent state, and the consistency exempt attribute has been removed.

Moving the device will clear the Consistency Exempt indicator from the SRDF mirror in the group from which it is moved. However, if the –cons_exempt flag is used with movepair operation, then the Consistency Exempt indicator will be set when the device is moved into the new SRDF group.




SRDF Operations Allowed with Consistency Exempt

The following operations are allowed with the Consistency Exempt flag (-cons_exempt). These can be performed on a Device Group (-g), Device file (-f), or on a Consistency Group (-cg)– symrdf createpair

The SRDF pair(s) become consistency exempt in the SRDF group in the current SRDF/A group in which they are created

– symrdf movepairThe SRDF pair(s) become consistency exempt in the target SRDF group into which they are moved

– symrdf suspendDevice pair(s) become consistency exempt in their current SRDF group

For example, if the device pair has to be moved from the current and active SRDF/A group, this device pair alone can be suspended with consistency exempt, without affecting all the other devices

Operations such as suspend, resume, and establish can now be performed on a subset of devices in a SRDF/A session, by using the consistency exempt flag. How ever, operations such as split, failover cannot be performed on a subset of devices.




Adding Devices to an Active SRDF/A Session1. Create a new device pair into a temporary SRDF group and

synchronize themSynchronization can be done with the –establish option with the createpair operation

2. Verify synchronization and suspend the device pair3. Move the device pair from the temporary SRDF group into the active

SRDF/A groupIt is in this step that the –cons_exempt flag should be used with the movepair operation

4. Resume the suspended device pairs that have just been moved5. Wait for the pair state to change from Consistency Exempt to

Consistent

It is critical to wait for the new devices to go into a Consistent RDF Pair state, before using the R1 device for application data. As long as the Consistency Exempt attribute is set, data on the R2 is not guaranteed to be consistent with the primary data on the R1.




Removing Devices from an Active SRDF/A Session1. Suspend the relevant device pair(s) in the current SRDF/A session

• This requires the –cons_exempt flag • If consistency is enabled for the RDF group, a –force will also be

necessary for the suspend operation to succeed

2. Verify that the devices are suspended, and the Consistency Exempt flag is set for them

3. Move the pair(s) to a different RDF group• The device pair(s) can be moved to a different RDF group using the

movepair operationmovepair operation also requires the –cons_exempt flag, only if the device is moved to another active SRDF/A group

With Solutions Enabler 7.0 and Enginuity 5874, a subset of the devices in the SRDF/A session can be suspended. This requires the use of the Consistency Exempt flag. The device pairs can then be moved to a different RDF Group. The movepair operation also requires the Consistency Exempt flag, if the device is moved to another active SRDF/A group. Otherwise, Consistency Exempt flag is not required.




Query the Existing SRDF/A Session C:\> symrdf query -sid 84 -rdfg 9 -rdfa -f pairs.txt

Remote Symmetrix ID : 000194900083 (Microcode Version: 5874)

RDF (RA) Group Number : 9 (08)


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

N/A 0150 RW 0 0 RW 0150 WD 0 0 A..X. Consistent


C:\> symrdf query -sid 84 -rdfg 9 -rdfa -f pairs.txt




-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------



RDF Group number 9 contains two devices in an active SRDF/A session. The device pairs are consistent and the SRDF Group is enabled for SRDF Consistency. There is a new field added to the Modes –(Consistency) (E)xempt

Legend for MODES:




C(onsistency State) : X = Enabled, . = Disabled, M = Mixed, - = N/A





Create a New Device PairC:\> symrdf createpair -sid 84 -rdfg 10 -f newpair.txt -type r1 –establish

C:\> symrdf query -sid 84 -rdfg 10 -f newpair.txt

Symmetrix ID : 000194900084 (Microcode Version: 5874)




-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

N/A 0152 RW 0 0 RW 0152 WD 0 0 S... Synchronized

C:\> symrdf createpair -sid 84 -rdfg 10 -f newpair.txt -type r1 –establish

C:\> symrdf query -sid 84 -rdfg 10 -f newpair.txt





-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------

N/A 0152 RW 0 0 RW 0152 WD 0 0 S... Synchronized

A new SRDF device pair is created into a different SRDF Group, Group number 10 in this example.




Move the New Device Pair into the SRDF/A Session

C:\> symrdf suspend -sid 84 -rdfg 10 -f newpair.txt

Suspend RDF link(s) for device(s) in (0084,010)..................Done.

C:\> symrdf movepair -sid 84 -rdfg 10 -new_rdfg 9 -cons_exempt -f newpair.txt

Move RDF Pair from (0084,010) to (0084,009).....................Started.

Move RDF Pair from (0084,010) to (0084,009).....................Done.

C:\> symrdf suspend -sid 84 -rdfg 10 -f newpair.txt

Suspend RDF link(s) for device(s) in (0084,010)..................Done.

C:\> symrdf movepair -sid 84 -rdfg 10 -new_rdfg 9 -cons_exempt -f newpair.txt

Move RDF Pair from (0084,010) to (0084,009).....................Started.

Move RDF Pair from (0084,010) to (0084,009).....................Done.

After synchronization, the new device pair is suspended and then moved from the current SRDF Group 10, to the existing SRDF/A session (SRDF Group number 9), with the consistency exempt flag.




Query the SRDF/A SessionC:\> symrdf query -sid 84 -rdfg 9 -rdfa -f pairs.txt





RDFA Consistency Exempt Devices : Yes


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------



N/A 0152 RW 0 0 NR 0152 WD 0 0 A..XX Suspended






RDFA Consistency Exempt Devices : Yes


-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------



N/A 0152 RW 0 0 NR 0152 WD 0 0 A..XX Suspended

Querying the SRDF/A session shows that the new device (device 0152) has the Consistency Exempt flag set. There is a new field in the output of the query command – RDFA Consistency Exempt Devices : Yes. Note that the existing devices continue to be Consistent. Adding a new device does not compromise the Disaster Recovery capability.




Verify Consistency

C:\> symrdf resume -sid 84 -rdfg 9 -f newpair.txt



-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------




C:\> symrdf resume -sid 84 -rdfg 9 -f newpair.txt



-------------------------------- ------------------------ ----- ------------

ST LI ST

Standard A N A



-------------------------------- -- ------------------------ ----- ------------




With the consistency exempt flag set, the new device pair alone can be resumed in the SRDF/A session. Once synchronization is complete, and two cycle switches have occurred, Enginuity removes the Consistency Exempt flag. The SRDF Pair State moves to Consistent. Only now it is safe to use the R1 device for production work.





Described SRDF/A “Asynchronous” Replication.

Listed and describe the “Delta Set” Cycles within an SRDF/A environment

Described SRDF behavior when transitioning to SRDF/A mode

Created an controlled an SRDF/A device group utilizing the SYMCLI command set

Described “Consistent Deactivation” from SRDF/A to SRDF/S

Enabled and disabled “Consistency” within an SRDF/A session

Discussed Transmit Idle and DSE (Delta Set Extension)

Defined Multi Session Consistency (MSC)

Described the SRDF/A Consistency Exempt feature



Module 6 - SRDF/AR - Automated Replication - 1

© 2009 EMC Corporation. All rights reserved. Module 6 - SRDF/AR - Automated Replication - 1

Module 6: SRDF/AR - Automated Replication Upon completion of this module, you will be able to:

Describe the benefits of integrating EMC’s SRDF and TimeFinder applications

List business needs and requirements using an SRDF single or multi-Hop Symmetrix configuration

Define all the steps required in setting up a “SRDF/AR” single hop environment

Describe the symcli symreplicate command set

List all the SRDF/AR configuration requirements

Describe the purpose of the symreplicate options file

List the replication cycle steps for a single-hop SRDF/AR environment





Symmetrix Remote Data Facility / Automated Replication

Allows business restart site to be any distance away from source

Collaboration of “SRDF” and “TimeFinder” commands

Minimizes network costs R1or

STD

R1/BCV

R2

BCV

1

1 SRDF (Adaptive Copy)

SRDF/AR allows users to automate the sequence of SRDF and TimeFinder mirror operations. The automated sequence - cycle - is performed on a user-defined interval called cycle time.

The replication cycles automatically loop indefinitely or to the number of cycles specified by the users. Users perform all SRDF/AR operations, setup, start, stop, restart, and query, through the symreplicate command. Even though the SRDF link can be set to all SRDF operational mode, except Asynchronous, it is usually set to operate in Adaptive Copy mode due to the long distance between local and remote sites. This allows the users to save on network bandwidth, thus minimizing the network costs without compromising the integrity of the data.




SRDF/AR Single-Hop ConfigurationUses 2 Symmetrix Arrays

– Uses STD, R1-BCV, R2 and BCV device types– SRDF Mode of Operation

Adaptive copy– Controlled data loss

Remote BCV can be used for disaster restart

R1or

STD

R1/BCV

R2

BCV

21

3

Local Array

Remote ArrayControlling

Host

The copy path for a single-hop configuration is from the local R1/BCV pair (1) to the SRDF pair (2) to the remote BCV pair (3). The remotely associated BCV holds the DBMS restartable copy. The amount of data loss is a function of the replication cycle time (period of time between the start of one copy cycle and the start of another copy cycle). Copy cycle time is affected by distance, bandwidth, I/O update rate, and locality of reference for the updates. Update rate and locality of reference tend to equate to changed tracks. The maximum data loss would be one copy cycle, this makes the RPO ~ Twice the Cycle Time.

Single Hop benefits include:The ability to perform incremental resynchronization between the intermediate SRDF target site and the final SRDF target site, reducing required network bandwidthReduction in communication link cost and improved resynchronization time for long-distance SRDF implementations




SRDF/AR Multi-Hop ConfigurationUses 3 Symmetrix Arrays:

– Local site, Hop1 bunker site, and Hop2 target site– Uses R1, R2, R1-BCV, and BCV (optional) device types– SRDF Mode of Operation

Local to Hop 1 Bunker: SynchronousHop 1 Bunker to Hop 2 Target: Adaptive Copy

– Zero data loss at Bunker site– One cycle data loss at Target site

R14

1

3

Local Array Remote Array

ControllingHost R2 BCV

R2R1/BCV2

Bunker Array

The copy path for a multi-hop configuration is from the local SRDF pair (1) to the remote BCV pair (2) to the remote SRDF pair (3) to the Target BCV (4). If your configuration does not include Target BCVs, the path stops at (3).

Automated replication with the BCVs at Target is applicable if you want a zero data loss solution but cannot risk the loss of both the Local site and Bunker site at the same time. With this configuration, there are two possible disaster restart possibilities:

If only the Local site is lost, the result is zero data loss at the Target restart site. If both the Local and Bunker site are lost, the result is a DBMS restartable copy at the Target restart site with controlled data loss. The amount of data loss is a function of the replicate copy cycle time between the Bunker site and the Target restart site.

Multi-Hop benefits include:The ability to perform incremental resynchronization between the intermediate SRDF target site and the final SRDF target (Multi-Hop) site, reducing required network bandwidthReduction in communication link cost and improved resynchronization time for long-distance SRDF implementationsThe ability to use the SRDF Multi-Hop site to provide disaster recovery testing, point-in-time backups, decision support operations, third-party software testing, and application upgrade testing or the testing of new applications




Single Hop Set-up

Create device group– C:\>symdg create srdfardg

– C:\>set SYMCLI_DG=srdfardg

Add STD devices– C:\>symld addall dev –range 139:13A

Associate R1/BCV devices– C:\>symbcv associateall dev –range 155:156

Associate remote BCV devices– C:\>symbcv associateall dev –range 155:156 –rdf -bcv

Standard devices 139:13A are added to the device group srdfardg. Local R1/BCV devices 155:156 are then associated with this device group. Remote BCV devices 155:156 are then associated with this device group. Note the use of –rdf and –bcv flags for this operation.

Shown below is an extract from the symdg show srdfardg command. Note that the remote BCV devices are given the Logical Device Name of BRBCV.

BCV Devices Remotely-associated (BCV RDF) (2):

{

--------------------------------------------------------------------

Sym Cap


--------------------------------------------------------------------

BRBCV001 N/A 0155 RW 1078

BRBCV002 N/A 0156 RW 1078

}




Single Hop Set-up: Initialize Mirrors1. Establish STD – R1/BCV pairs

C:\>symmir establish –full

2. Split STD – R1/BCV pairsC:\>symmir split –consistent

3. Resume R1/BCV – R2 pairsC:\>symrdf resume –bcv

4. Establish R2 – BRBCV pairsC:\>symmir establish –rdf –bcv –full

5. Split R2 – BRBCV pairsC:\>symmir split –rdf –bcv –consistent

6. Establish STD – R1/BCV pairsC:\>symmir establish

There are six steps to prepare the state of all the mirrors involved in SRDF/AR Single Hop prior to running the symreplicate command.

To begin a replication session in the single-hop configuration, the mirrors must be in the following states:

The local STD/BCV pairs must be fully synchronizedThe RDF pairs must be in a suspended stateThe remote BCV pairs must be in a split state

Note: The user must wait and check for full synchronization before proceeding to the next step and issuing the next command.

In step (1), if it is the first time that the STD devices are paired with these R1/BCV devices, a full establish operation is required. The establish operation in step (1) automatically suspends the RDF links between the R1/BCV – R2 device pairs. After verifying that the STD – R1/BCV pairs are in a synchronized state, they can be split in step (2). The RDF link between R1/BCV – R2 device pairs is resumed in step (3). After R1/BCV – R2 device pairs are synchronized, the R2 – BCV device pairs can be established in step (4). Again as this is the first time these devices are paired, a full establish operation has to be performed. After synchronization of R2 – BRBCV pairs, they can be split in step (5). Finally the STD – BCV device pairs can now be incrementally established in step (6).




The symreplicate CommandSYMCLI binary that integrates symmir and symrdf commands with the appropriate arguments and options depending on the configuration

Used to propagate automated data copies– Incremental (changed tracks only)– Behavior is based on pre-defined parameters (symreplicate options file)

When used with TimeFinder consistent split, ensures a remotely-associated BCV contains a DBMS restartable copy of data– Requires PowerPath or ECA

Used in both single-hop and multi-hop configurations

Used to start, stop, restart, or query SRDF/AR replication sessions

Executed on the local host

The symreplicate command set invokes a session that generates automated, recurrent background copies of the standard data across an RDF link and cascading BCVs. The symreplicate command set will start, stop, and restart SRDF/AR session.




The symreplicate Options FileUser created, named, and configurable text file that defines and controls replication behavior

#Comment

SYMCLI_REPLICATE_HOP_TYPE=<RepType>

SYMCLI_REPLICATE_CYCLE=<CycleTime>

SYMCLI_REPLICATE_CYCLE_OVERFLOW=<OvfMethod>

SYMCLI_REPLICATE_CYCLE_DELAY=<Delay>

SYMCLI_REPLICATE_NUM_CYCLES=<NumCycles>

SYMCLI_REPLICATE_USE_FINAL_BCV=<TRUE|FALSE>

SYMCLI_REPLICATE_LOG_STEP=<TRUE|FALSE>

SYMCLI_REPLICATE_GEN_TIME_LIMIT=<TimeLimit>

SYMCLI_REPLICATE_GEN_SLEEP_TIME=<SleepTime>

SYMCLI_REPLICATE_RDF_TIME_LIMIT=<TimeLimit>

SYMCLI_REPLICATE_RDF_SLEEP_TIME=<SleepTime>

SYMCLI_REPLICATE_BCV_TIME_LIMIT=<TimeLimit>

The option file is a text file that contains parameters such as SRDF/AR hop type and cycle time. This file is required and is used in conjunction with the symreplicate command to start a replication session.

This slide lists a subset of parameters that can be specified. There are a minimum of two parameters that must specified for proper session behavior. They are: SYMCLI_REPLICATE_HOP_TYPE =<single|multi> and one of SYMCLI_REPLICATE_CYCLE or SYMCLI_REPLICATE_CYCLE_DELAY (a non-zero value must be specified).

Refer to EMC® Solutions Enabler Symmetrix® SRDF® Family CLI, Version 7.0. Product Guide P/N 300-000-877 REV A11 for all the possible options and their descriptions.




SYMCLI_REPLICATE_HOP_TYPE=[SINGLE|MULTI]

** Must be specifiedSYMCLI_REPLICATE_CYCLE=[minutes|hh:mm]

- Defines the period to wait between copy operations if more than 1 cycle- Can be specified in total minutes or hours and minutes- Defaults to 0; when one cycle ends another begins

**Either CycleTime or Delay is a required parameterSYMCLI_REPLICATE_CYCLE_DELAY=[minutes]

- Specifies the minimum time to wait between the end of one cycle and the beginning of the next cycle

- Defaults to 0** Either CycleTime or Delay is a required variable

The symreplicate Options File (continued)

SYMCLI_REPLICATE_HOP_TYPE is self explanatory and is directly dependent on the configuration.

SYMCLI_REPLICATE_CYCLE or SYMCLI_REPLICATE_CYCLE_DELAY requires a time interval for its value.

Example – SRDF/AR Options file: #Comment

SYMCLI_REPLICATE_HOP_TYPE=single

SYMCLI_REPLICATE_CYCLE=10

SYMCLI_REPLICATE_CYCLE_OVERFLOW=next

SYMCLI_REPLICATE_NUM_CYCLES=3

SYMCLI_REPLICATE_LOG_STEP=TRUE

A simple options file (above) specifies a single-hop cycle time of 10 minutes, to be repeated 3 times, log each step of the cycle and wait for the next cycle time boundary to start a new cycle if the prior cycle over runs the cycle time.




Cycle, Delay and Overflow Parameters

Start 1 2 3 4 5 6 7

Example 1 Cycle Time = 2, Delay Time = 0, Overflow = Next

Overflow ACT NCS

Start 1 2 3 4 5 6 7

Example 2 Cycle Time = 2, Delay Time = 0, Overflow = Immediate

ACT, NCS

Legend ACT = Actual Completion TimeNCS = Next Cycle Start

MDT = Minimum Delay Time

Start 1 2 3 4 5 6 7

Example 3 Cycle Time = 3, Delay Time = 2, Overflow = Next

ACT MDT NCS

Start 1 2 3 4 5 6 7

Example 4 Cycle Time = 0, Delay Time = 3, Overflow = Next or Immediate

ACT MDT,NCS

The three parameters SYMCLI_REPLICATE_CYCLE, SYMCLI_REPLICATE_CYCLE_OVERFLOW, and SYMCLI_REPLICATE_CYCLE_DELAY significantly contribute to how the next replication cycle starts after the current cycle.

This slide show different combinations of cycle time, delay time, and overflow behavior to achieve various results. Reference points on the cycle time lines are marked ACT (actual completion time), NCS (next cycle start), and MDT (minimum delay time). Short cycle and delay times (in minutes) were chosen for illustration purposes only.

Copy cycles #1 and #2 have the same cycle time (2) and no delay time. When copy cycle #1 runs longer than two minutes, the overflow setting of “Next” results in a new copy cycle beginning at the four-minute mark.

Copy cycle #3 finishes before its scheduled cycle time of three minutes, waits two minutes, and begins copying again at the next scheduled copy cycle (the six-minute mark).

Copy cycle #4 performs continuous copy cycles when its cycle time is set to zero. At the end of a cycle, the system waits three minutes and then begins another copy cycle, regardless of the overflow setting.




Defining and Adjusting Parameters

EMC recommends starting with loose time constraints for cycle time parameters

Adjust parameters once basic information is gathered or determined from initial cycles

Data sizeSRDF throughputOperation timings

Session progress can be monitored using the query argument for the symreplicate command and settings can be adjusted as required

The symreplicate stats command will provide statistics on your SRDF/AR sessions

It is recommended to be generous with time parameters for cycles, and adjust once more information is collected for various cycles. The times configured in the options file should be configured for worst case scenarios.

Beginning with Solutions Enabler 6.1, you can display statistical information for cycle time and invalid tracks by using the symreplicate stats command. The command can be issued by device group (-g) or composite group (-cg) for a specified Symmetrix (-sid) and information can optionally be written to a specified log file (-log).

The -all option is the default and will display both the cycle time and invalid tracks statistics. The following example will display both cycle time and invalid track for device group srdfardg on Symmetrix 80, and will output the result to a log file

symreplicate -g srdfardg -sid 80 -all stats –log c:\temp\srdfardg.log




Execute one cycle to prepare the mirror states

Prepare the mirror states and start the session

Automatic Initialization to Required Mirror States

C:\>symreplicate setup -options srdfar_opt.txt -nop

Checking for valid group configuration...

Checking for valid initial group state...

The symreplicate session was successfully launched.

C:\>symreplicate start –setup -options srdfar_opt.txt –consistent -nop




The setup command:Sets-up required pair states−Options file indicates single or multi hop type setup − Same options file used for setup and subsequent start command

Executes one cycle, which may take some time, and then exits− Setup command executes just one cycle, regardless of the number of cycles specified in the

options file

The start command with the -setup option:Sets-up the required pair statesIf successful, begins the symreplicate session−Options file defines the hop type and the copy cycle parameters that you have chosen for the

session




When Devices are Not in the Required StateC:\>symreplicate start -options srdfar_opt.txt

Execute a symreplicate 'Start' operation

for device group 'srdfardg' (y/[n]) ? y



Some local BCV pairs are not SYNCHRONIZED, including BCV:155 and STD:139

on SymID:000194900180 and setup was not specified.

The group state does not match the state required

for a SINGLE type operation; make sure the local BCV pairs

are established, the RDF pairs are suspended, and the remote

BCV pairs are split.

You can correct the problem manually, or, specify -setup on the

command line and symreplicate will attempt to correct the problem

for you.

The start operation fails in the devices are not in a valid initial state. We can specify the –setup option as noted in the previous slide to automatically correct the problem.




Stopping and Restarting a Single-Hop SessionC:\>symreplicate stop

Execute a symreplicate 'Stop' operation


Stop operation underway.

C:\>symreplicate restart -recover

Execute a symreplicate 'Restart' operation



A stopped session can be restarted with the –recover option. The “-recover” option is used to recover the device locks from the previously started session.




symreplicate StatisticsC:\>symreplicate -all stats

Group name: srdfardg

Host name: DMX800WIN1

Cycle Time (HH:MM:SS):

---------------------------------------

Last Cycle Time: 00:00:06

Max Cycle Time: 00:00:13

Avg Cycle Time: 00:00:07

Invalid Tracks:

---------------------------------------

Last Cycle : 0 ( 0.0 MB)

Maximum : 0 ( 0.0 MB)

Average : 0 ( 0.0 MB)

The -all option is the default and will display both the cycle time and invalid tracks statistics.




When a failure occurs in the primary site, we can have one of the three situations on the target site• All BCVs on the target are split from their corresponding R2

devices• All BCVs on the target are established with their corresponding

R2 devices• Some of the BCVs on the target are split from their

corresponding R2 devices, while others are still established with their corresponding R2 devices

Recovery/Restart involves identifying devices with the most current and consistent copy of data

11

22

33

Failure/Recovery: Single Hop

Determination of the states of the devices and deducing the cycle step using the states can be performed from a host on the target side, using appropriate device files. These operations can be performed from a different host on the source side, if the failure only affected the primary host, and the array and site are still available and accessible.




C:\>symreplicate start –log srdfardg.log –sid 80

Host A

Host B

STDSTD R2R2

BCVSFSSFS

Local Remote

SFS = “Symmetrix File System”

Clustered SRDF/AR

R1BCV

Since Enginuity 5669, Symmetrix arrays support clustered SRDF/AR environments for multiple node (host) capability. Clustered SRDF/AR provides the capability to start, stop, and restart replication sessions from any host connected to any local Symmetrix array participating in the replication session.

The clustered SRDF/AR environment allows the replication log file to be written directly to the Symmetrix File System (SFS) instead of the local host directory of the node that began the session. If the primary node should fail, then any locally attached host to the Symmetrix array containing the log file would then be able to restart the SRDF/AR session from where it left off. If you begin a session and specify a user log file name (-log), you must specify the -log option for all other commands in the session sequence.

To write the log file to the SFS, you must specify the ID of the Symmetrix array (-sid) where the log file is to be stored at the start of the replication session, along with a group name (-g, -cg) and an optional user log filename (-log).

For example:

symreplicate start -log srdfardg.log -sid 80

Note:

Not specifying the Symmetrix ID (-sid) at the start of the session causes the log file to be written to local disk using the default SYMAPI log directory, which is not restartable from another node.




General Recovery ProceduresOnce the R2 devices on the target site are populated with the most recent and consistent data, they must be RW enabled for the host

Application restart times must be factored in to the overall Recovery Time Objective

Availability of necessary device file definitions at the target site can help in reducing the RTO. Device files must be updated on any configuration changes – adding more Standard devices or R1s

It is preferable to restart/recover from the R2 devices– Facilitates easier return home– BCVs can be used to preserve previous cycle’s data

RW enabling of R2s can be performed via the symrdf failover command with the appropriate device file definitions.





Described the benefits of integrating EMC’s SRDF and TimeFinder applications

Listed business needs and requirements using an SRDF single or multi-Hop Symmetrix configuration

Defined all the steps required in setting up a “SRDF/AR” single hop environment

Described the symcli symreplicate command set

Listed all the SRDF/AR configuration requirements

Described the purpose of the symreplicate options file

Listed the replication cycle steps for a single-hop SRDF/AR environment



Module 7 – Open Replicator Operational Details - 1

© 2009 EMC Corporation. All rights reserved. Module 7 - Open Replicator Operational Details - 1

Module 7: Open Replicator for Symmetrix Operational DetailsUpon completion of this module, you will be able to:

Perform Open Replicator Push and Pull Operations

Describe how to throttle Open Replicator data transfer rates

Explain how incremental push and restore work

Describe zoning and LUN masking requirements for ORS

Explain the considerations when performing ORS data transfer to/from non-EMC arrays





Open Replicator for Symmetrix is Fast, Simple and Open

FastUses the SAN / WAN to make copiesFull or incremental copiesNo server or LAN impact

SimpleUtilize existing infrastructureSymmetrix-based controlsCan be used for ad-hoc or routine operationsPush or pull data, live or BCV-based

OpenEMC CLARiiON, SymmetrixApplication and host independentEMC E-Lab qualified non-EMC platforms

SAN/WAN

Hitachi

SymmetrixCLARiiON

HPIBM

Open Replicator for Symmetrix delivers key requirements for platform-independent replication by being fast, simple, and open. Since it is based on the Symmetrix system, management is common across all connected hosts, and performance and scalability are superior.

With Open Replicator for Symmetrix, you can create point-in-time copies of local Symmetrix volumes and transfer them to or from any qualified storage array. Open Replicator offers live and incremental update capabilities. When migrating data from older arrays to a new Symmetrix, you don’t need to wait for the data to complete the copy before accessing it locally on the Symmetrix.




Hot PushAt creation all Control tracks are marked as protected– Track copying starts immediately if –precopy option is used

After activation the protected tracks are moved when a write is issued to a track (without use of the –copy action)– Copy occurs in the background if –copy option is used

Protected track copied to Remote first before Control host can modify it (Copy on First Write)

Control may be host read/write accessible (hot)

Remote should not be modified or read by any host during the copy process

Remote may be larger than Control

Each FA port mapped to the local Control device must be able to reach the Remote device

A protected track is a track that must be moved before a write to that track is allowed. This term is used for Snaps, Clones and Open Replicator.

All tracks on the control device are protected after creation of an Open Replicator session.

Use of the -precopy option with the create or recreate commands initiate a data copy immediately in the background, before the session is activated.

If the background copy option was specified at time of creation, copying of protected tracks starts directly after activation. Otherwise, copying is deferred until a protected track is written to by the local host.

During a hot push, the control device can stay available for reads and writes. There is a delay in completing a write to a protected track until it has been moved to the remote device. This penalty, paid for the first write to a protected track only, is referred to as the COFW (Copy on First Write). Subsequent writes to the control device occur without delays.

As in every Open Replicator data transfer, the data on the remote device should not be altered until data copy has finished. Note that most operating systems alter data on a device, even when the file system is opened for reads.

Since each FA port on the DMX through which I/Os may arrive to the control devices must act to move protected tracks over to the remote array, each FA port on the local array to which the control devices are mapped must be able to access the corresponding remote device on the remote array.




Hot Push (continued)Up to 15 sessions can be created and activated, one after the other, with one being active (i.e. CopyInProg) at a time per LUN

1024 sessions per Symmetrix are allowed

Upon link failure between Control and Remote, the session fails

CLI examplessymrcopy -file <filename> -push -hot create

symrcopy -file <filename> activate

symrcopy -file <filename> terminate

CLI File format:Control (Hot) Remote (Cold ) symdev=<symid>:<dev> wwn=<LUN WWN>symdev=000194900180:13D wwn=60000970000194900182533030313344

A device is limited to 16 total SDDF sessions:The active (CREATED, RECREATE, COPYINPROG) session uses an SDDF session for the protection bitmap.Differential sessions use an additional SDDF session to track changes since ACTIVATE.The 15 limit is reached with 15 differential sessions, with one currently active (protection bitmap is the 16th device SDDF session).By default the number of allowed sessions is 128 but you can set the SYMAPI_RCOPY_SESSION_LIMIT value to 512 in the SYMAPI options file (/var/symapi/config/options or \Program Files\EMC\SYMAPI\CONFIG\options). The 512 session value works for only later versions of 5x71 and above.If links fail and communication is lost between the two sites, the session fails because you do not want to hold up production on the local host.




Cold PushIf –copy option is specified, track copying starts and continues until complete after activation

Control must be User Not Ready to host

Remote should be host inaccessible

One Control may have up to 16 targets (in a single session)

Up to 15 sessions can be created sequentially for a single device, but only one can be actively copying at one time

1024 sessions permitted per Symmetrix

Remote volumes should be accessible to local FA ports for the duration of copy

Remember to use the –copy option. Otherwise, no tracks are transferred and the session will sit there forever.

Although it may be typical to use a BCV as the control device in a cold push, this is not an absolute requirement. As long as the Control volume is write-disabled (WD or NR) to the host, it can participate as the source for a cold push. Another option is for the Cold Push device to be a Clone Target volume, which can be incrementally updated like a BCV from the application volume.

Since there is no COFW penalty paid by incoming host writes during a Cold Push Sessions, up to 16 targets are supported in a single session.

A device is limited to 16 total SDDF sessions:The active (CREATED, RECREATE, COPYINPROG) session uses an SDDF session for the protection bitmap.Differential sessions use an additional SDDF session to track changes since ACTIVATE.The 15 limit is reached with 15 differential sessions, with one currently active (protection bitmap is the 16th device SDDF session).




Cold Push (continued)Not all local FA ports (mapped to the control volume) are required to have access to the Remote volumes

Upon loss of links between Control and Remote– Session stalls– Symmetrix keeps retrying until link recovers or session is terminated

CLI examplessymrcopy -file <filename> -push -cold create



CLI File format:Control (Cold) Remote (Cold) symdev=000194900180:13D wwn=60000970000194900182533030313344

symdev=000194900180:13E wwn=60000970000194900182533030313345

Only difference in CLI syntax is -cold instead of –hot.




Incremental Push

The session is recreated instead of terminated after the initial push is complete

Presuming that the copy is complete before the recreate command is issued, changes between 10:00 and 11:05 are propagated after the second activate command

symrcopy create –differentialsymrcopy activate

symrcopy verify –copied

symrcopy recreatesymrcopy activate

Let us say an Open Replicator push is activated at 10 a.m. and the copy takes an hour to complete. At 11:05 a.m. you issue a recreate followed by an activate command. This has the effect of propagating the changes made to the control device between 10 and 11:05 a.m. to the remote side. Since only changes are transmitted, the data transfer does not take as much time.

For the purpose of data integrity, the remote device has to stay untouched by a remote side host between 10 and whenever the second data transfer finishes.

The operation described above is known as an incremental push.




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 changes since the session was initiated

SDDF sessions are used to monitor changes in– Clones– Snaps– BCVs– Change Tracker– Open Replicator

Each Symmetrix logical volume is allotted a quota of 16 SDDF sessions. These sessions allow the Symmetrix to track changes by using bitmaps which flip from a zero to a one whenever a track that is being monitored changes.

SDDF sessions are used to monitor changes in BCVs, Clones, Snaps, Change Tracker, Open Replicator and SRDF/Star.




Incremental Push DetailsUpon creation of an OR Session, two bitmaps get set-up

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Protection Bitmap

SDDF Bitmap

As each track gets copied, the 1 in the protection bitmap becomes a zero and the track becomes unprotected

When the host writes to a track, the corresponding bit in the SDDF bitmap is changed to a 1

When copying completes, all tracks in the protection map are 0s,changed tracks in the SDDF bitmap are 1s, as shown in example:

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

1 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0

Protection Bitmap

SDDF Bitmap




Incremental Push Details (continued)

When the recreate / activate commands are issued, the SDDF bitmap gets copied to the protection bitmap and the SDDF bits are zeroed out

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Protection Bitmap

SDDF Bitmap

Again, the protected tracks (i.e. the changes since last time) are propagated

Once the changes are finished propagating, the protection bitmapis again set to zero

While the changes are going across, the SDDF bitmap continues to keep track of new changes so that subsequent recreate/activate commands are possible

1 1 0 0 0 0 0 0 0 1 0 0 0 0 1 0




Incremental Restore after Incremental Push

Instead of pushing changed data Open Replicator pulls tracks from remote corresponding to changed tracks

Overwrites changed data with old data using hot pull

CLI example:symrcopy -file <filename> restore

For incremental push operations only, data can be restored back to the control device by pulling back only the changed tracks from the remote device. The session must have been created using the -differential option and must be in the copied state. Hot or cold differential push sessions can be restored.

For example, if you copied all data from the control device to the remote device(s) and then made changes to the control device, you could then recover the original data from the remote device by using the symrcopy restore command. When the command is issued, the session is recreated in restore mode and automatically activated. At the start of the restore operation, all control devices are set to Not Ready status. If running a hot session, control devices are returned to Ready status at the end of the operation (as the data begins copying). If running a cold session, the control devices remain in Not Ready status.

If a restore is being performed to a hot push session, new writes to the control are only allowed after the appropriate track has been restored.




Hot PullControl Symmetrix is host accessible – Can be larger than Remote

Remote should not be modified or read by any host during transfer

At activation, all Control tracks are marked protected– Background copy initiated between Remote and Control– A read or write from the control device causes the track to be pulled

over before access is permitted (CopyOnAccess behavior)

Copying continues until complete if –copy option specified

All FAs with access to Control devices must have access to Remote devices

Hot pull is a way to perform migrations with minimal application down time. However, there is a risk of data loss if the hot pull session is prematurely terminated before the data transfer is complete, because the writes to the local control volumes are not written back to the remote side. There is a separate license required for hot pulls.

If the target of the copy is larger than the source, the extra tracks are not copied. If the target is smaller, the copy fails. However, the –force_copy option can be used to override this limitation. In that case, only as many tracks as the target can hold are copied.

While the Hot Push exhibits Copy on First Write behavior, Hot Pull exhibits Copy on Access behavior. A read or a write to the control volume triggers the track to be moved from the remote to the control volume. There is a performance penalty that is paid the first time a track is accessed.




Hot Pull (continued)

If communication between Control and Remote is lost, the session stalls indefinitely– Application could stall or crash, but data integrity is preserved if

session can be revived

Session should be terminated after completion of copy

CLI examplessymrcopy -file <filename> -pull -hot create



CLI File formatControl (Hot) Remote (Cold) symdev=000194900180:13D wwn=60000970000194900182533030313344

Upon loss of links, host I/O could stall and cause the application to crash or stall. However, the session persists unless explicitly terminated. When the links come back, copy proceeds where it left off.




Hot Pull Data Protection through Donor UpdateUse of –donor_update option during hot pull protects new data written to the control device

Whether during or after data transfer, all new writes are sent to the remote device(s)

If a link fails during a hot pull, it is OK to terminate the session

Upon restarting, the remote device contains the most recent data

CLI examplessymrcopy -file <filename> -donor_update –hot –create –pull -copy

To protect against potential data loss due to a SAN failure or other connectivity issue during a hot pull operation, you can use the donor update option. When enabled, this feature also causes all writes to the control device from the host to be immediately copied to the remote device. Because the data is fully copied to the remote and control devices, if a failure occurs, the session can safely be terminated and created again to fully recover from any mid-copy failure.




Cold Pull

Control is Not Ready to host – Can be larger than Remote

Remote should be host inaccessible during transfer

At activation, all Control tracks are marked protected

If the –copy option is specified:– Background copy initiated between Remote and Control– Track copying continues until complete

All Remote volumes should be accessible to local FA for the duration of the copy

Not all FAs with access to Control devices must have access to Remote devices

Remember to specify the –copy option with cold pulls. Otherwise, no tracks are transferred.




Cold Pull (continued)Upon loss of links between Control and Remote– Session stalls– Symmetrix keeps retrying until link recovers or session is terminated

One Control and one Remote only

Session should be terminated after completion of copy

CLI examplessymrcopy -file <filename> -pull -cold create



CLI File format:Control (Cold) Remote (Cold) symdev=000194900180:13D wwn=60000970000194900182533030313344

Data transfer is suspended if the links go down, and resumed after they come back.




Throttling Open Replicator Data Transfer

If not restricted, Open Replicator can consume all the bandwidth of a SAN, causing host I/O deterioration

Pace parameter inserts delays between tracks of transmitted data

Ceiling restricts the maximum amount of bandwidth that can be used on a director and port level

Throttling is relevant for hot data transfers where FAs must time share between host I/O and Open Replicator I/O. It is also relevant for cold transfers if FA bandwidth is being shared. However, in the case of cold transfers, a separate FA can be set aside for the transfer so production I/O is not affected.

The Pace parameter inserts milliseconds of delay between each track write.

The ceiling value limits the Open Replicator throughput for a port of a specific director.




Pace of an Open Replicator SessionSet at the Open Replicator session level

Pace = 0 (fastest)– No inserted delays– Greater use of system resources– Replication as fast as possible

Pace between 1 and 9 (slowest)– Adds delays into the replication process – Uses fewer system resources– Takes longer to complete

Default: Pace = 5

Syntaxsymrcopy –file <filename> set pace 0

If you really want to go as fast as possible, remember to set the pace to 0 at creation time or thereafter, since the default pace is 5.




Ceiling: Setting the Maximum Bandwidth

Ceiling caps bandwidth of an FC port used by Open Replicator – Set at the Symmetrix director port level

Set as a percentage (0-100) or NONE of the maximum bandwidth for a Symmetrix director port

Ceiling setting (except NONE) takes precedence over the Pace value

Syntaxsymrcopy set ceiling 80 –sid 80 –dir 7F –port 1

Ceiling is more practical in real life because this way, you can reserve a fraction of available bandwidth for host I/O.




Mode Summary

As above for hot/cold

push

Changes since last activation; COFW if hot

As above for hot/cold

push

As above for hot/cold push

Incremental Push

Session stalls

All tracks copied1:1Ctrl: Not Ready

Rem: NHDC

Cold Pull

Session stalls

All tracks copied; CopyOnAccess

as needed

1:1Ctrl: Read/Write to Host

Rem: NHDC

Hot Pull

Session stalls

All tracks copied 1:n

(n<= 16)

Ctrl: Not Ready

Rem: NHDC

Cold Push

Session fails

All tracks copied; COFW for

protected tracks

1:1Ctrl: Read/Write to Host

Rem: No Host access during copy (NHDC)

Hot Push

When Links Fail

Copy TypeControl Remote

Ratio

State of Control and Remote

Action

The only case where the session is failed after a loss of links is a hot push. This is because you do not want to hold up production work at the control site waiting for network connectivity to be re-established.




SYMCLI_RCOPY_COPY_MODE Environment Variable - 1COPY_DIFF

– Sets background copy mode; when session is activated, it transitions into ‘CopyInProgress’– Sets default mode for create as differential, allowing for subsequent recreate– Do not use with Online or Offline Pull

NOCOPY_DIFF– Does not set the background copy mode; when session is activated, it is ‘CopyOnAccess’– Sets differential mode as default for create, allowing for subsequent recreate– Do not use with Online or Offline Pull

COPY_NODIFF– Sets background copy mode; when session is activated, it transitions into ‘CopyInProgress’– Session is not differential at create time; recreate fails

NOCOPY_NODIFF– Does not set the background copy mode; when session is activated, it is ‘CopyOnAccess’– Session is not differential at create time; recreate fails




SYMCLI_RCOPY_COPY_MODE Environment Variable - 2

PRECOPY_DIFF– Sets precopy mode; after creation or recreation, session is in ‘Precopy’ state – Sets default mode for create as differential, allowing for subsequent recreate– Use only for hot push

PRECOPY_NODIFF– Sets precopy mode; after creation or recreation, session is in ‘Precopy’ state – Session is not differential at create time; recreate fails– Use only for hot push




Zoning: Hot Push or Pull

Host

FA Port 1

FA Port 2

HBA 1

Storage Port 1

Storage Port 2

Control Symmetrix Remote Symmetrix

Zone 1 Host Access

Zone 2 Host Access

Zone 3 Open Replicator Access

Zone 4 Open Replicator AccessHBA 2

In the case of a hot pull or push, each FA that has access to the control devices must have access to the corresponding remote devices. This is because the FA is responsible for pulling or pushing a track from the remote in case there is a write to the protected track by the control side host.




Zoning: Cold Push or Pull

Host

FA Port 1

FA Port 2

FA Port 3

FA Port 4

HBA 1

Storage Port 1

Storage Port 2

Control Symmetrix Remote Symmetrix

Zone 1 Host Access

Zone 2 Host Access

Zone 3 Open Replicator Access

Zone 4 Open Replicator AccessHBA 2

In the case of a cold pull or push, each FA that has access to the control devices need not have access to the corresponding remote devices. As long as one FA from the control device can reach the remote devices, the cold push works.




Zone and Mask 2 Symmetrix ArraysOn controlling Symmetrix Array– Identify FA ports with access to control devices– Get the WWN of the FA ports

On remote Symmetrix Array– Identify FA port numbers– Mask WWN of the controlling FA ports to the remote FA ports

Create a zone between controlling and remote FAs using a tool of your choice

Mask remote devices to the controlling FA– symmask – if Symmetrix DMX Array– symaccess (Initiator Group; Port Group; Storage Group; and

Masking View) – if Symmetrix V-Max Series Array

The steps outlined here are a suggested way to zone two Symmetrix arrays. If you are adept at zoning and masking, you can certainly deviate from this order and still be successful.




symaccess commandC:\>symaccess list view -sid 82


Masking View Name Initiator Group Port Group Storage Group

------------------- ------------------- ------------------- -------------------

WIN3_MaskingView WIN3_Initiators WIN3_Ports WIN3_StorageGroup

hp3_MaskingView hp3_Initiators hp3_Ports hp3_StorageGroup

ibm3_MaskingView ibm3_Initiators ibm3_Ports ibm3_StorageGroup

sun3_MaskingView sun3_Initiators sun3_Ports sun3_StorageGroup

lin3_MaskingView lin3_Initiators lin3_Ports lin3_StorageGroup

hp3_OR_MaskingView hpControl_Ports_IG hp3_Ports hp3_OR_SG

ibm3_OR_MaskingView ibmControl_Ports_IG ibm3_Ports ibm3_OR_SG

sun3_OR_MaskingView sunControl_Ports_IG sun3_Ports sun3_OR_SG

lin3_OR_MaskingView linControl_Ports_IG lin3_Ports lin3_OR_SG

win3_OR_MaskingView winControl_Ports_IG WIN3_Ports win3_OR_SG

Starting with Symmetrix V-Max series array with Enginuity 5874 and Solutions Enabler version 7.0, host access to devices is set up using Auto Provisioning Groups, using the symaccess command. This example shows the list of Masking Views that have been created on the Remote Symmetrix (sid 82). A Masking View consists of one Initiator Group, one Port Group and one Storage Group.




symaccess command – Viewing Initiator GroupC:\>symaccess show winControl_Ports_IG -type initiator -sid 82


Last updated at : 08:20:41 AM on Thu May 21,2009

Initiator Group Name : winControl_Ports_IG

Host Initiators

{

IG :linControl_Ports_IG

}

Masking View Names

{

win3_OR_MaskingView

}

Parent Initiator Groups

{

None

}

The Initiator Group winControl_Ports_IG contains yet another Initiator Group – linControl_Ports_IG . The WWN of the Control Array FA dir:p should be placed in an Initiator Group on the Remote Array (sid 82) in this case. In effect the Control Array FA dir:p acts as a “hba”, accessing devices on the Remote Array FA dir:p




symaccess command – Viewing Initiator GroupC:\>symaccess show winControl_Ports_IG -type initiator -sid 82



Host Initiators

{

WWN :50000972c002d159

WWN :50000972c002d15d

WWN :50000972c002d559

WWN :50000972c002d55d

}

Masking View Names

{

lin3_OR_MaskingView

win3_OR_MaskingView *

}

Parent Initiator Groups

{

winControl_Ports_IG

}

* Denotes Masking Views through a cascaded group

As can be seen from the output below, 50000972C002D159 is the WWN of FA 7F Port 1 of the Control Array (sid 80). This FA DIR:P has been placed in the Initiator Group on the Remote Array (sid 82).

C:\>symcfg list -fa 7F -p 1 -sid 80


S Y M M E T R I X F I B R E D I R E C T O R S

Dir Port WWN ACLX Volume Set Pnt to Pnt

Enabled Addressing

FA-7F 1 50000972C002D159 Yes No Yes




symaccess command – Viewing Port GroupC:\>symaccess show WIN3_Ports -type port -sid 82


Last updated at : 01:14:04 PM on Tue May 19,2009

Port Group Name : WIN3_Ports

Director Identification

{

FA-8F:1

FA-7F:1

}

Masking View Names

{

WIN3_MaskingView

win3_OR_MaskingView

}

FA 7F: Port 1 on Remote Array is included in the Port Group.




symaccess command – Viewing Storage GroupC:\>symaccess show win3_OR_SG -type storage -sid 82


Last updated at : 08:20:40 AM on Thu May 21,2009

Storage Group Name : win3_OR_SG

Devices : 013D:0144

Masking View Names

{

win3_OR_MaskingView

}

Devices 13D:144 mapped to the Front Director 7F Port 1 are included in the storage group.




SYMAPI_RCOPY_GET_MODIFIED_TRACKS Option

Options File variable affects all sessions

Counts modified tracks if you write to control device after pushactivation

Similar to other modified track counters

DMX800SUN1/> grep MODIFIED_TRACKS /var/symapi/config/options

# Parameter: SYMAPI_TF_COUNT_MODIFIED_TRACKS

#SYMAPI_TF_COUNT_MODIFIED_TRACKS = FALSE

# Parameter: SYMAPI_SNAP_COUNT_MODIFIED_TRACKS

#SYMAPI_SNAP_COUNT_MODIFIED_TRACKS = FALSE

# Parameter: SYMAPI_RCOPY_GET_MODIFIED_TRACKS

#SYMAPI_RCOPY_GET_MODIFIED_TRACKS = FALSE

TF_COUNT_MODIFIED tracks show modified tracks, while a BCV and standard are split and after a clone has been activated. SNAP_MODIFIED_TRACKS counts modified tracks after activation is for clones. It shows how many tracks have changed on the source since clone activation.




Devices to Use for OR TransferC:\>symdev list -sid 80 pd



--------------------------- ------------- -------------------------------------

Cap


--------------------------- ------------- -------------------------------------

013D \\.\PHYSICALDRIVE5 07F:1 07A:C4 2-Way Mir N/Grp'd RW 1078

013E \\.\PHYSICALDRIVE6 07F:1 07C:C4 2-Way Mir N/Grp'd RW 1078

Devices 13D and 13E will be used for the Hot Push operation. These will be the Control devices and they are mapped to Front End director 7F, Port 1. Symmetrix with sid 80 is the Controlling array.




symsan Command in 5772 and Later

Lists Port and LUN WWNs seen from a specific Symmetrix Director and Port

Benefits– Can validate zoning between the port and intended OR target

(remote device)– Does not require the OR session to be created

Examples:– Display Remote Ports WWNs:

symsan –sanports –sid <Symid> -dir <# | ALL> -port <# | ALL>

– Display LUNs WWN seen behind a Remote Port WWNsymsan -sanluns –wwn <san_port_wwn> –sid <Symid> -dir <# | ALL> -port <# | ALL>

– Display HBAs:symsan -hba –sid <Symid> -dir <# | ALL> -port <# | ALL>

The symsan command lists ports visible from a given director, and LUNs visible behind a given remote port. It allows a user to make sure that the remote devices intended for use with Open Replicator are reachable through the SAN.




Command to View Remote Director Port WWNC:\>symsan list -sid 80 -sanports -dir 7F -port 1 -detail


Flags Num Remote

DIR:P I Vendor Array LUNs Remote Port WWN DIR:P

----- ----- ------------- ---------------- ---- -------------------------------- -----

07F:1 . EMC Symmetrix 000194900182 17 50000972C002D959 07F:1

07F:1 . EMC CLARiiON APM00034100394 21 500601681020A060 N/A

Legend:

Flags: (I)ncomplete : X = record is incomplete, . = record is complete.

The display indicates that two different arrays are accessible through director 7F port 1. The WWN of FA 7F:1 on Symmetrix 82 and that of the service processor on the CLARiiON are displayed.




Command to View Remote LUNs on one ArrayC:\>symsan list -sid 80 -dir 7F -p 1 -wwn 50000972C002D959 -sanluns


Remote Port WWN: 50000972C002D959

ST

A

T Flags Block Capacity LUN Dev LUN

DIR:P E ICRTHS Size (MB) Num Num WWN

----- -- ------- ----- ----------- ----- ----- --------------------------------

07F:1 RW ...F.X 512 1078 9 013D 60000970000194900182533030313344

07F:1 RW ...F.X 512 1078 A 013E 60000970000194900182533030313345

07F:1 RW ...F.X 512 1078 B 013F 60000970000194900182533030313346

07F:1 RW ...F.X 512 1078 C 0140 60000970000194900182533030313430

07F:1 RW ...F.X 512 1078 D 0141 60000970000194900182533030313431

07F:1 RW ...F.X 512 1078 E 0142 60000970000194900182533030313432

After identifying the WWNs of the remote ports that can be accessed through the control Symmetrixfibre port 7F:1, the symsan command can be used to identify the LUNs that are accessible through the remote FA. As is evident from these two displays, the symsan command vastly simplifies the verification and troubleshooting of SAN connectivity through the use of one simple command.

Legend:

Flags: (I)ncomplete : X = record is incomplete, . = record is complete.

(C)ontroller : X = record is controller, . = record is not controller.

(R)eserved : X = record is reserved, . = record is not reserved.

(T)ype : A = AS400, F = FBA, C = CKD, . = Unknown

t(H)in : X = record is a thin dev, . = record is not a thin dev.

(S)ymmtrix : X = Symmetrix device, . = not Symmetrixdevice.




Device File and Environment VariableC:\>symcfg list

S Y M M E T R I X

Mcode Cache Num Phys Num Symm

SymmID Attachment Model Version Size (MB) Devices Devices

000194900180 Local VMAX-1SE 5874 12288 64 401

000194900181 Remote VMAX-1SE 5874 12288 0 401

000194900182 Remote VMAX-1SE 5874 12288 0 401

C:\>cat rsym.txt

# Control Remote

symdev=80:13D symdev=82:13D

symdev=80:13E symdev=82:13E

C:\>set SYMCLI_RCOPY_COPY_MODE=COPY_DIFF

We could have used WWNs, but since the remote Symmetrix was discovered through SRDF, using Symmetrix device numbers is allowed. The environment variable specifies a differential, background copy for the OR session.




Hot Push CreationC:\>symrcopy create -f rsym.txt -push -hot -nop

'Create' operation execution is in progress for the device list

in device file 'rsym.txt'. Please wait...

'Create' operation successfully executed for the device list

in device file 'rsym.txt'.

Without the environment variable, we would have had to use –copy –diff options.




Query after Hot Push Creation

C:\>symrcopy -f rsym.txt query

Device File Name : rsym.txt

Control Device Remote Device Flags Status Done

---------------------------- ----------------------------------- ----- -------------- ----

Protected

SID:symdev Tracks Identification RI CDSHU CTL <=> REM (%)

------------------ --------- -------------------------------- -- ----- -------------- ----

000194900180:013D 17250 000194900182:013D SD XXXX. Created N/A

000194900180:013E 17250 000194900182:013E SD XXXX. Created N/A

Total ---------

Track(s) 34500

MB(s) 2156.3

Note that all tracks on the two devices are marked as protected, as this is the first time a ORS hot push session has been created for these two devices. From the legend shown below, we see that a hot push (S=X, H=X) session has been created with differential (D=X) and background copy (C=X) options

Flags:



(D): X = The session is a differential copy session.

. = The session is not a differential copy session.

(S): X = The session is pushing data to the remote device(s).

. = The session is pulling data from the remote device(s).

(H): X = The session is a hot copy session.

. = The session is a cold copy session.

(U): X = The session has donor update enabled.

. = The session does not have donor update enabled.

(*): The failed session can be reactivated.




Activate Hot PushC:\>symrcopy -f rsym.txt activate -consistent –nop




---------------------------- ----------------------------------- ----- -------------- ----

Protected


------------------ --------- -------------------------------- -- ----- -------------- ----

000194900180:013D 16988 000194900182:013D SD XXXX. CopyInProg 1

000194900180:013E 16978 000194900182:013E SD XXXX. CopyInProg 1

Total ---------

Track(s) 33966

MB(s) 2122.9

Note that the background copy is progressing. The default copy pace is 5. This can be increased if so desired by using the command symrcopy –f rsym.txt set pace 0 (0 being the highest pace possible). Also note the use of –consistent flag. As this is a hot push operation, the control devices are pushing data to remote devices and the control devices are currently online for host I/O operations. Including the Enginuity Consistency Assist (ECA) option (–consistent) in the command line. temporarily prevents host I/O while the Open Replicator copy session begins. This begins a consistent point-in-time copy to the remote devices using an ECA window. As seen earlier with TimeFinder/Clone and TimeFinder/Snap, this temporarily freezes host I/O to the control devices.After the activation is completed for all devices, the host I/O is thawed.




Recreate Hot Push SessionC:\>symrcopy -f rsym.txt recreate –nop




---------------------------- ----------------------------------- ----- -------------- ----

Protected


------------------ --------- -------------------------------- -- ----- -------------- ----

000194900180:013D 2050 000194900182:013D SD XXXX. Recreated N/A

000194900180:013E 624 000194900182:013E SD XXXX. Recreated N/A

Total ---------

Track(s) 2674

MB(s) 167.1

When the session is recreated, the changes made to the Control devices after the initial activation are reflected as protected tracks. As the session was created with –copy –diff flags, subsequent activation will only move these changed tracks (incremental/differential operation).




Restore from a Recreated Hot Push SessionC:\>symrcopy -f rsym.txt restore –nop




---------------------------- ----------------------------------- ----- -------------- ----

Protected


------------------ --------- -------------------------------- -- ----- -------------- ----

000194900180:013D 0 000194900182:013D SD XXXX. Restored 100

000194900180:013E 0 000194900182:013E SD XXXX. Restored 100

Total ---------

Track(s) 0

MB(s) 0.0

The incremental restore action was introduced with Enginuity 5772. It copies the contents of the remote device to the control device incrementally. For restore to work, the initial OR session must have been created as an incremental push session. Also, the remote device cannot have changed between the last push and the restore.




Terminate SessionC:\>symrcopy -f rsym.txt terminate

Execute 'Terminate' operation for the 2 specified devices

in device file 'rsym.txt' (y/[n]) ? y

'Terminate' operation execution is in progress for the device list


'Terminate' operation successfully executed for the device list



The device list in device file 'rsym.txt' does not have any session information.

A restored session can be recreated or terminated.




Create Hot Push with PrecopyC:\>set SYMCLI_RCOPY_COPY_MODE=PRECOPY_DIFF

C:\>symrcopy -f rsym.txt create -hot -push -nop




---------------------------- ----------------------------------- ----- -------------- ----

Protected


------------------ --------- -------------------------------- -- ----- -------------- ----

000194900180:013D 11489 000194900182:013D SD XXXX. Precopy 33

000194900180:013E 11498 000194900182:013E SD XXXX. Precopy 33

Total ---------

Track(s) 22987

MB(s) 1436.7

The creation of a hot push session with the –precopy option starts data copy right after session creation. This cuts down on the time to finish copying protected tracks after the session is activated. Note that the number of protected tracks is lower than on page 37. This is because 33% of the protected tracks have already been copied to the remote devices when the query was issued.

After the session is activated, only a few tracks must be copied to the remote devices.




Terminate Hot Push Session after CompletionC:\>symrcopy -f rsym.txt verify

All device(s) in the list are in 'Copied' state.

C:\>symrcopy -f rsym.txt terminate -nop

'Terminate' operation execution is in progress for the device list


'Terminate' operation successfully executed for the device list


The verify action checks whether the copying of data has finished. An interval can be specified with verify, such as –i 10, which will check every 10 seconds. Once the copy completes and the devices are in Copied state, the verification stops.




Hot Pull CreationC:\>set SYMCLI_RCOPY_COPY_MODE=COPY_NODIFF

C:\>symrcopy -f rsym.txt create -hot –pull –donor_update -nop




---------------------------- ----------------------------------- ----- -------------- ----

Protected


------------------ --------- -------------------------------- -- ----- -------------- ----

000194900180:013D 17250 000194900182:013D SD X..XX Created N/A

000194900180:013E 17250 000194900182:013E SD X..XX Created N/A

Total ---------

Track(s) 34500

MB(s) 2156.3

Without the COPY_NODIFF environment variable, we would have seen an error:

“The requested feature is not supported for this microcode or SYMAPI version”

The donor update feature was introduced in a later release of 5x71. The X in the U column of the query indicates that donor update is turned on. As mentioned earlier, this option transmits newly created data from the control to the remote device during and after a hot pull, as long as the session is still in existence.




Hot Pull ActivationC:\>symrcopy -f rsym.txt activate -nop




---------------------------- ----------------------------------- ----- -------------- ----

Protected


------------------ --------- -------------------------------- -- ----- -------------- ----

000194900180:013D 13975 000194900182:013D SD X..XX CopyInProg 18

000194900180:013E 13978 000194900182:013E SD X..XX CopyInProg 18

Total ---------

Track(s) 27953

MB(s) 1747.1

After the status has reached Copied, the session can be terminated. How ever as the session was created with –donor_update option, the –force flag is required to terminate. Or donor update can be turned off and then the session can be terminated.

C:\>symrcopy –f rsym.txt set donor_update off

C:\>symrcopy –f rsym.txt terminate




Preparing for Cold PushC:\>set SYMCLI_RCOPY_COPY_MODE=COPY_NODIFF

C:\>symdev list -sid 80 -range 13D:13E



--------------------------- ------------- -------------------------------------

Cap


--------------------------- ------------- -------------------------------------

013D \\.\PHYSICALDRIVE5 07F:1 07A:C4 2-Way Mir N/Grp'd RW 1078

013E \\.\PHYSICALDRIVE6 07F:1 07C:C4 2-Way Mir N/Grp'd RW 1078

C:\>symdev not_ready -sid 80 13D –nop

C:\>symdev not_ready -sid 80 13E -nop

If the devices were not set to NR, cold push creation would fail with the following error message “The device is not in a valid Ready status. Operation cannot proceed”.




Create and Activate a Cold Push SessionC:\>symrcopy -f rsym.txt create –cold -push –pace 0 -nop

C:\>symrcopy –r rsym.txt activate –nop




---------------------------- ----------------------------------- ----- -------------- ----

Protected


------------------ --------- -------------------------------- -- ----- -------------- ----

000194900180:013D 15299 000194900182:013D SD X.X.. CopyInProg 11

000194900180:013E 15297 000194900182:013E SD X.X.. CopyInProg 11

Total ---------

Track(s) 30596

MB(s) 1912.3

You can set the pace on the create command line. Note that the session flags (S and H) reflect that this is a Cold Push.




Create and Activate a Cold Pull SessionC:\>symrcopy -f rsym.txt create –cold –pull -nop

C:\>symrcopy –r rsym.txt activate –nop




---------------------------- ----------------------------------- ----- -------------- ----

Protected


------------------ --------- -------------------------------- -- ----- -------------- ----

000194900180:013D 17044 000194900182:013D SD X.... CopyInProg 1

000194900180:013E 17044 000194900182:013E SD X.... CopyInProg 1

Total ---------

Track(s) 34088

MB(s) 2130.5

The commands to create and activate Cold Pull are similar to the commands for other actions. The Control devices again have to be set to Not Ready, else the create operation will fail.




ORS with VDEVs as Control Devices

7E0

1

8E0

1

7F0

1

8F0

1

7E0

1

8E0

1

7F0

1

8F0

1VDEV

Snap Session

Prior to Enginuity 5874, cold push operations from a BCV, were only allowed from full volume copies such as a TimeFinder/Mirror or TimeFinder/Clone control volumes or by making the standard volume not ready. With Enginuity 5874, an Open Replicator cold push can be performed using TimeFinder/Snap snapshot volume (VDEV) as the control device. This allows users to perform ORS push operations without requiring equal amount of space, when they do not want or require a local replica of their data. The applications can remain on line, and the push can be performed from the VDEV. The VDEV has to be mapped to the front end directors and ports that will participate in the ORS session. In principle for a cold push, the VDEV needs to be mapped to just one front end director port.




7E0

1

8E0

1

7F0

1

8F0

1

7E0

1

8E0

1

7F0

1

8F0

1

ORS Steps using VDEV1. Create TimeFinder/Snap session

2. Create ORS session

3. Activate TimeFInder/Snap session

PIT

4. Activate ORS session

VDEV

Cold Push Only

The steps listed here have to be performed in the exact order. The Snap session should be activated with –not_ready flag, to set the VDEV Not Ready. If the ORS session is not created with a –copy flag, then both the states of the SRC Target for the Snap session, and the CTL RMT for the ORS session will be in CopyOnWrite state. A symrcopy set mode copy operation is required to start copying the data. If the ORS session is created with the –copy flag, then copy operations start immediately on activating the ORS session.

These are the steps for performing a Virtual ORS Cold Push operation.1) Create the TimeFinder/Snap session.2) Create the ORS session3) Activate the Snap session

This creates a point-in-time copy4) Activate the ORS session

ORS copy begins at the time of activation5) Wait for ORS session copy to complete




7E0

1

8E0

1

7F0

1

8F0

1

7E0

1

8E0

1

7F0

1

8F0

1

Repeating the ORS Operations using VDEV

1. Recreate TimeFinder/Snap session

2. Recreate ORS session

3. Activate TimeFinder/Snap session

PIT

4. Activate ORS session

VDEV

Cold Push Only

To repeat the cycle, the Snap session can first be recreated. Enginuity 5874 now supports recreating TimeFinder/Snap sessions. Then the ORS session can be recreated, followed by the activation of the Snap session and then the activation of the ORS session.

These are the steps for performing a Virtual ORS Cold Push operation.Recreate the SnapSessionRecreate the ORS sessionActivate the Snap sessionActivate the ORS SessionTerminate the ORS sessionTerminate the Snap session




Consideration for VDEVs as Control Devices– The VDEV must remain Not Ready to the user while the ORS

session is present– ORS session can only be created as a cold differential or non-

differential push– There can only be one ORS session for a given VDEV control device– ORS Restore to a ORS TimeFinder/Snap session is not supported– Multi-Virtual snap will not be supported– ORS Precopy is not supported

In general, the idea of a Snap is to make the VDEV ready at activation. This ensures that the Business Continuity host can access data from either the Source device or the Save Pool, as might be necessary. How ever for ORS session with VDEV, the TimeFinder/Snap activate is performed with a –not_ready flag. This is a cold push, and there should be no changes to the VDEV when the push session is in progress. Open Replicator supports multiple cold pushes from a single source. But if the control device is a VDEV, as in this case, there can be only one ORS session per VDEV.




Zone and Mask a Symmetrix and CLARiiON

On controlling Symmetrix– Identify FA ports with access to control devices – Get the WWN of the FA ports– Get the block size of the control devices

On remote CLARiiON– Discover CLARiiON over network (optional)– Verify the size of the CLARiiON devices– Register the Symmetrix FAs as hosts on the CLARiiON– Create Open Replicator Storage Group on CLARiiON if needed– Mask the Symmetrix FAs as hosts with access to this Storage Group

Create a zone between controlling FAs and a Service Processor port using any applicable tool

While this is one suggested order of completing the tasks of zoning and masking between a Symmetrix and a CLARiiON, if you are experienced with zoning and masking, you are free to perform the steps in a different order that works for you.




Device File Options for Use with CLARiiONDevice file for an “undiscovered” CLARiiON

############################################################################# Controlling Symmetrix: 000194900180 (5874)# Remote CLARiiON : APM00034100394 (CX700)############################################################################symdev=000194900180:13D wwn=600601608A990C00F4602D8E87FDDB11 symdev=000194900180:13E wwn=600601608A990C00F5602D8E87FDDB11

Device file for a “discovered” CLARiiON############################################################################# Controlling Symmetrix: 000194900180 (5874)# Remote CLARiiON : APM00034100394 (CX700)############################################################################symdev=000194900180:13D clardev=APM00034100394:0051symdev=000194900180:13E clardev=APM00034100394:0052

If you do not discover the CLARiiON using SYMCLI, you must find out the WWNs from a CLARiiON based tool such as Navisphere Manager. Since WWNs tend to be longer and more difficult to enter, it is often more convenient to “discover” the CLARiiON over the network and get the LUNs through SYMCLI.




Non-Symmetrix Array Considerations

Supported list of Arrays– Available in the current e-lab Navigator

Obtaining WWN of storage devices– inq utility distributed by EMC– Array vendor’s tools

Sizing remote array volumes– Symmetrix control array volumes are created by cylinders– If remote volume is smaller only pulls allowed *– If remote volume is larger only pushes allowed*– If the volume sizes are exactly matched, pulls and pushes allowed

* symrcopy –force_copy can be used to overcome restriction

Transferring data between a DMX and non-Symmetrix arrays is not significantly different from transferring data between two Symmetrix arrays. The arrays, which have been qualified by engineering, can be found documented in the e-lab navigator available on PowerLink. The principal challenge is to find the WWNs of the devices on the remote array. Once the WWNs are known, the Open Replicator sessions can be created over the SAN.

While Symmetrix volumes are configured using the number of cylinders as the lowest unit of measure, other arrays size their LUNs in 512 byte blocks. Open Replicator pays attention to the size of the remote and the control array measured in 512 byte blocks. Hence, care must be taken to size the LUNs appropriately if bi-directional data transfer is planned between remote and control arrays.

When the remote smaller than the control device, you cannot push to the remote device without the force_copy option. If that option is used, extra tracks on the control are not copied to remote. However, a pull works because the extra tracks on the control device are simply left untouched.

When the remote device is bigger than the control device, you cannot pull data from the remote device without the force_copy option. If that option is used, extra tracks on the remote are not copied to control. However, a push works because the extra tracks on the remote device are simply not written to.




Entries in /var/symapi/log/symapi-YYYYmmdd.log07/10/2009 12:45:37.046 1620 4848 EMC:SYMRCOPY map_discover_erro loc_dir:07F, rem_num:0,

rem_sts:0x13SANCOPY_DEV_REMOTE_DEVICE_TOO_LARGE

An excerpt from the log file shows the error message related to the device size discrepancy during an attempted pull from a larger remote device to a smaller control device.




Open Replicator and Thin Devices

Thin Devices can be used as control or remote devices

Push from unused sections of Thin Devices sends 0s

As data copy occurs, Thin Device targets become allocated i.e.– Control Device in an OR pull– Remote Device in an OR push

If a smaller device sends data to a larger thin device only as much space will be allocated as the size of the smaller device

Open Replicator can be used to perform remote replication between thin devices or between thin and regular devices. Managing thin device replication with Open Replicator is exactly the same as managing the replication of regular devices.

Thin devices can be used as control devices for hot and cold pull and cold push Open Replicator copy operations. If a push operation is done using a thin device as the source, zeroes will be sent for any regions of the thin device that have not been allocated, or that have been allocated but have not been written to.

Open Replicator can also be used to copy data from a regular device to a thin device. If a pull or push operation is initiated from a regular device that targets a thin device, then a portion of the target thin device, equal in size to the reported size of the source volume, will become allocated.




Module Summary

Key points covered in this module are:

Performing Open Replicator Push and Pull Operations

Controlling the rate of data transfer and the amount of front end port bandwidth used by Open Replicator

Performing incremental push and restore operations

Verifying zoning and LUN masking requirements for ORS

Considerations when performing ORS data transfer to/from non-EMC arrays



Module 8 - Symmetrix Management Console - 1

© 2009 EMC Corporation. All rights reserved. Module 8 - Symmetrix Management Console - 1

Module 8: Symmetrix Management Console (SMC)

Upon completion of this module, you will be able to:

Identify basic SMC functionality for EMC Replication Solutions

Describe Device Group creation using SMC

Describe the steps for managing local and remote replication solutions using EMC





TimeFinder– Mirror– Clone– Snap– SAVE Device Pool

Management

SRDF– Synchronous– Asynchronous– Adaptive Copy– SRDF Configuration

Open Replicator

Replication Operations Supported by SMC

Almost all replication technologies available on the Symmetrix Arrays can be monitored and managed via SMC. At the present time, SRDF/Star cannot be managed via SMC.




Device Groups

SRDF and TimeFinder operations in SMC require Device Groups

All device groups in the default symapi_db.bin or GNS (if active) are available in SMC

Device Groups can be created, deleted, renamed and devices can be added and removed as needed

SRDF and TimeFinder operations are invoked by selecting a device group and using the Replication option

SRDF and TimeFinder operation in SMC require the use of Device Groups. SMC has visibility to all the device groups that exist in the symapi_db of the SMC Server host and to all device groups, if GNS is in use. The Device Group Wizard allows the creation of new device groups. Device groups can be deleted and renamed and devices can be added or removed as necessary.




Device Types in Device Groups

Local SymmetrixStandard (STD)

BCV (BCV)Clone Target (TGT)Virtual Dev (VDEV)

Remote SymmetrixRemote BCV (RBCV)

BCV Remote BCV (BRBCV)Remote Target (RTGT)Remote Virt. (RVDEV)

Remote Symmetrix(Hop 2)

Remote BCV (RRBCV)

The Devices types supported in SMC are shown on the slide. The STD Devices can be Regular (non SRDF Devices), SRDF R1s, or SRDF R2. Devices can be added as Clone Target devices on the local or the remote array, and remote Virtual devices can be added. The device group dialog displays only valid devices when choosing a device type. For instance, when adding remote Clone Target devices, only eligible devices configured on the remote array display in the dialog.




Creating Device Groups and Adding Devices

SMC Device Group creation is a multi-step process, similar to creating SYMCLI device groups using symdg, symld, and symbcv. The wizard is launched by right clicking the Device Group Folder and choosing the Device Group Management Create Device Group option.





1

Drop-down to the Symmetrix ID where the devices reside. In this example SID 80. Click on Device Type STD and select the devices for Source of Clone session. In this example devices 13D and 13E. Then click Add. Name the device group, such as clonedg in this slide. The group type has been chosen to be Regular as we are preparing for a TimeFinder/Clone operation





Next select TGT for the device type and add the two devices which will be Clone targets. Note the Device Group Summary which reflects the selection. In this case device 0F9 and 0FA have been added as local Clone targets. Then click OK and the message show will be displayed if Device Group creation succeeds.




Creating the Clone Session

Right-click on the device group and select Replication then TimeFinder/Clone.




Creating the Clone Session

1 2

3

On Page 1 of 2, select Local TGT from the menu, Create for the Action and in this example we have selected Optimize pairs. Local TGT allows you to pair STD device in the DG/CG with the associated TGT devices in the group. Device pairs can also be defined by using the Edit Pairs button or by using Set Exact pair. With Edit pairs, the device pairs can be defined in the Add/Remove Clone pairs dialog. Then click on Next. In Page 2 of 2, we can see that the –copy and –differential options (default with Solutions Enabler 7.0, as discussed earlier) are automatically selected by default. Clicking Finish now will create the Clone session. A message is displayed to that effect. For other Clone operations such as Activate, right-click on the device group Replication TimeFinder/Clone and then select the desired command from the Action drop down – such as Activate for the next step in starting a Clone copy session.




Snap Operations

Like in the Clone example, a device group named snapdg has been created. Two STD devices 13F and 140, as well as two VDEVs 131 and 132 have been added to the device group.




Snap Operations

12

Right-click on the device group snapdg brings up page 1 of Snap operations. The create action and the SAVE device pool have been selected from the drop-down menus. Exact pairs have been set as well. Clicking on the Next button brings up page 2. Clicking Finish on this page will create the Snap session. For other Snap operations such as Activate, right-click on the device group Replication TimeFinder/Snap and then select the desired command from the Action drop down – such as Activate for the next step in starting a Snap copy session.




SRDF Modes

1

2

A device group srdfdg has been created. Right-click on the device group and navigate to Replication, then SRDF Settings to set mode of remote replication for the device pair. The options are shown in the drop-down menu for Set Mode. Choose the desired mode of operation and click OK




SRDF Operations

12

Right-click on the device group and navigate to Replication, then SRDF Control to perform SRDF operations. The options are shown in the drop-down menu for Action. Choose the desired Action such as Fail Over and then proceed to the next page by clicking on Next. This will bring up the next page were other option can be selected.




Open Replicator Operations

Right-click on the Symmetrix and cascade down to Replication Open Replicator Create Copy Session menu option.





12

Select Hot or Cold, Push or Pull radio buttons. Hot-Push operation has been selected for this example. This is page 1 of 5 pages to complete the ORS create operation. In the next page select the Control FA:Port and the Control device. In this example, FA 7F:1 and device 0141 has been selected.





1

2

On page 3, select the remote device. Clicking on Next brings up page 4 where the Control and Remote can be selected. Then click on Add.





On page 5, select the Action (Create), optionally name the session (smc_ors), set the pace value (default=5, it has been changed to 0 for this example), select create options (copy and differential in this example). Once finished, a ORS session will be created.





After session creation, right-click on the session name and navigate to Replication Open Replicator Session Control, to Activate the session.




Monitoring Replication

1

2

3

SRDF and TimeFinder/Snap sessions can be monitored via the use of Replication Monitor. Replication Monitoring has to be enabled on a per Device or Composite Group basis and thresholds (on a per Symmetrix basis) set for SRDF/A Cache usage, cycle time, and for the TimeFinder/Snap and SRDF DSE Pool Utilization. CG and DF Replication Monitoring has to be enabled from the Tasks view. Click on the “Config DG Replication Monitor” or “Config CG Replication Monitor” to enable Replication Monitoring. Set the Monitor Policy “Polling Interval”, and check the “enable” box.




Replication Monitor View

Select on the Device Group and switch to Replication Monitor View to monitor the status of replication.




Module Summary

Key points covered in this module:

Identified basic SMC functionality for EMC Replication Solutions

Described Device Group creation using SMC

Described the steps for managing local and remote replication solutions using EMC





Course SummaryKey points covered in this course:

Described TimeFinder/Clone and TimeFinder/Snap solutions

Performed TimeFinder/Clone and TimeFinder/Snap operations

Described and performed SRDF operations in Synchronous (SRDF/S) and Asynchronous (SRDF/A) modes, for remote replication

Described and performed SRDF/Automated Replication (SRDF/AR) operations in a single-hop configuration

Described and performed Open Replicator for Symmetrix (ORS) data replication in Hot/Cold, Push and Pull scenarios

Described the use of Symmetrix Management Console (SMC) to perform local and remote replication operations

These are the key points covered in this training. Please take a moment to review them.

This concludes the training.




Closing Slide

symmetrix business continuity management student guide

Documents