h5765 Data Migration Open Replicator Symm Ppme Techbook

Data Migration: EMC Open Replicator for
Symmetrix, PowerPath Migration Enabler,

and Federated Live Migration
Version 2.0
Migration Product Features
Migration Setup and Verification
Migration Examples
Donald Fried-Tanzer
Data Migration: EMC Open Replicator, PowerPath Migration Enabler, and Federated Live Migration
2
Copyright 2008, 2009, 2010 EMC Corporation. All rights reserved.
EMC believes the information in this publication is accurate as of its publication date. The information is
subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS
PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable
software license.
For the most up-to-date regulatory document for your product line, go to the Technical Documentation and
Advisories section on EMC Powerlink.
For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.
All other trademarks used herein are the property of their respective owners.
Part number H5765.3
Data Migration: EMC Open Replicator, PowerPath Migration Enabler, and Federated Live Migration 3
Preface
Chapter 1 Introduction
Introduction....................................................................................... 22
Data Migration definition................................................................ 22
EMC Open Replicator for Symmetrix............................................ 22
Terminology: Control and remote ........................................... 22
Control FA "host" setup requirements .................................... 23
Terminology: Push and pull, cold and hot ............................. 23
Multipathing with hot setup requirements ............................ 24
EMC PowerPath Migration Enabler .............................................. 24
Federated Live Migration................................................................ 24
Migration project steps..................................................................... 25
When to use Open Replicator with PPME.................................... 26
When to use Federated Live Migration......................................... 27
Operational interfaces ...................................................................... 28
Chapter 2 Brief EMC Foundation and Migration Product
Descriptions
Introduction....................................................................................... 30
EMC Symmetrix storage arrays and associated software........... 32
Basic architecture........................................................................ 32
EMC Enginuity Operating Environment ................................ 32
Symmetrix Logical Volumes ..................................................... 33
Symmetrix VMAX and Symmetrix DMX arrays and Open
Replicator ..................................................................................... 33
Pre-DMX Symmetrix arrays and Open Replicator ................ 33
Other Symmetrix software ........................................................ 34
Contents
4
Contents
EMC CLARiiON and associated software.................................... 35
EMC MirrorView........................................................................ 36
SnapView..................................................................................... 36
SAN Copy.................................................................................... 36
Navisphere Management Suite ................................................ 36
EMC SAN products.......................................................................... 38
Connectrix ................................................................................... 38
Connectrix Manager................................................................... 38
SAN Manager.............................................................................. 38
Invista........................................................................................... 38
EMC Host products.......................................................................... 40
PowerPath Family ...................................................................... 40
Replication Manager .................................................................. 40
EMC Solutions Enabler.............................................................. 41
Symmetrix Management Console............................................ 41
EMC Ionix ControlCenter ......................................................... 42
Consulting and IT Services.............................................................. 42
Application Consulting ............................................................. 43
Business Consulting................................................................... 43
Industry Consulting................................................................... 43
Infrastructure Consulting.......................................................... 43
Private Cloud & Virtualization Consulting............................ 44
IT Services.................................................................................... 44
Managed services ....................................................................... 45
Chapter 3 EMC Open Replicator for Symmetrix
Introduction....................................................................................... 48
Definitions ......................................................................................... 48
Hot push ...................................................................................... 48
Cold push .................................................................................... 50
Hot pull ........................................................................................ 51
Cold pull ...................................................................................... 53
Open Replicator interaction rules with SRDF........................ 53
Basic Open Replicator migration operation flow......................... 55
Setup steps................................................................................... 55
Migration steps ........................................................................... 59
Cleanup steps.............................................................................. 64
Monitoring, troubleshooting and recovery................................... 65
Control interface alternatives.......................................................... 67
Solutions Enabler CLI ................................................................ 67
Symmetrix Management Console GUI ................................... 67
PowerPath Migration Enabler CLI .......................................... 68
5 Data Migration: EMC Open Replicator, PowerPath Migration Enabler, and Federated Live Migration
Contents
Reference information ...................................................................... 68
Chapter 4 Cold Push to CLARiiON Setup Example
Introduction ....................................................................................... 70
Setup step 1: Identify target devices............................................... 71
Setup step 2: Configure migration SAN zones ............................. 73
Determining Control Director WWN......................................73
Determining Remote Storage Array WWN(s) ........................74
Selective or all Symmetrix FA Zoning .....................................77
Example configuration of migration SAN zones ...................77
Setup step 3: Configure migration LUN masking........................ 78
Create CLARiiON storage group .............................................78
Register host and add devices to CLARiiON storage group78
Setup step 5: Prepare Open Replicator session pairs ................... 79
Setup step 6: Verify completion of setup steps ............................. 80
Create action is a thorough verification step ..........................80
Verify zoning with symsan -sanports ..................................80
Verify LUN masking with symsan -sanluns........................82
Verify zoning with symmask list logins............................83
Verify all with symrcopy create.............................................84
SMC Remote Report ...................................................................86
Chapter 5 Cold Push to CLARiiON Migration Example
Introduction ....................................................................................... 90
Migration step 7: BCV split.............................................................. 93
Device Group creation ...............................................................93
Initial TimeFinder/Mirror establish ........................................95
TimeFinder/Mirror split............................................................96
Migration step 8: symrcopy create.................................................. 98
Cold control devices must be Not Ready................................98
Create action options..................................................................99
Open Replication query display.............................................100
Query -detail option .................................................................101
Migration step 10: symrcopy activate .......................................... 102
Migration step 12: symrcopy set ceiling ...................................... 103
Migration step 13: symrcopy query and verify .......................... 105
Migration step 14: Iterative symrcopy recreate .......................... 106
Incrementally update control devices from production
devices ........................................................................................106
Incrementally update remote devices from control
devices ........................................................................................107
6
Contents
Stop applications and final incremental update .................. 108
Migration step 15: Verify migration and symrcopy terminate. 110
Hot push differences from cold push.................................... 110
Cleanup step 16: Make source devices host inaccessible.......... 112
Cleanup step 17: Make target devices ready to host ................. 113
Cleanup step 18: Restart applications using targets.................. 114
Cleanup step 19: Redeploy the source devices storage............ 116
Chapter 6 Hot Pull from CLARiiON Migration Example
Introduction..................................................................................... 118
Hot pull setup steps ................................................................. 118
Hot pull migration steps.......................................................... 118
Hot pull cleanup step............................................................... 119
Setup step 1: Identify target devices ............................................ 121
Setup step 2: Configure migration SAN zone ............................ 122
Determining control director WWNs.................................... 122
Determining remote storage array WWNs........................... 123
Reuse existing migration SAN zones .................................... 123
Setup step 3: Configure migration LUN masking ..................... 125
Create CLARiiON Storage Group.......................................... 125
Setup step 4: Configure target zoning and LUN masking ....... 126
Setup step 5: Prepare Open Replicator session pairs file.......... 128
Setup step 6: Verify completion of setup steps........................... 131
Discover missing zoning with symrcopy create.................. 131
Example configuration of additional migration SAN zone133
Discover missing LUN masking with symrcopy create ..... 133
Example LUN masking for all Symmetrix VMAX (or
Symmetrix DMX) FA control directors ................................. 135
Successful create verifies hot pull setup ............................... 135
Migration step 9: Stop the applications....................................... 136
Migration step 10: symrcopy activate.......................................... 138
Migration step 11: Restart applications using targets ............... 139
Migration step 13: symrcopy query and verify.......................... 144
Migration step 15: Verify migration and terminate ................... 145
Cleanup step 19: Redeploy the source devices........................... 146
Chapter 7 Hot Pull from Symmetrix Migration Example
Introduction..................................................................................... 148
Hot pull setup steps ................................................................. 148
Hot pull migration steps.......................................................... 149
Hot pull cleanup step............................................................... 149
Contents
Setup step 1: Identify target devices............................................. 151
Setup step 2: Configure migration SAN zone............................. 152
Determining control director World Wide Port Names
(WWPNs) ...................................................................................152
Determining Remote Storage Array WWPN(s) ...................154
Configuration of migration SAN zones.................................156
Setup step 3: Configure migration device masking................... 157
Application source device references ....................................157
Add Symmetrix device masking ............................................158
Symmetrix VMAX device masking using
Auto-provisioning groups.......................................................160
Setup step 4: Configure target zoning and LUN masking........ 173
Setup step 5: Prepare Open Replicator session pairs file .......... 174
Setup step 6: Verify completion of setup steps ........................... 178
Confirm hot pull setup with successful create .....................178
SMC Remote Report .................................................................180
Migration step 9: Stop the applications ....................................... 182
Migration step 10: Open Replicator activate............................... 185
Migration step 11: Restart applications using targets ................ 187
Migration step 12: Tune migration .............................................. 189
Migration step 13: Check status, wait until copied.................... 191
Migration step 15: Verify migration and terminate.................... 192
Cleanup step 19: Redeploy the source devices ........................... 194
Chapter 8 PowerPath Migration Enabler Overview
Introduction ..................................................................................... 196
Benefits of using PPME.................................................................. 196
Nondisruptive migration overview............................................. 197
Definitions ........................................................................................ 199
Pseudo or Native device name migrations ...........................199
Source and target ......................................................................199
PPME Migration States ............................................................199
PPME Abort, Cleanup, and Recover......................................202
PPME considerations and restrictions ......................................... 203
PPME with Open Replicator migration operation flow............ 204
Setup steps .................................................................................204
Migration steps..........................................................................205
Cleanup steps ............................................................................207
Reference information .................................................................... 211
8
Contents
Chapter 9 PPME with Open Replicator Migration Example
Introduction..................................................................................... 214
PPME Setup steps 14.................................................................... 215
PPME Setup steps 56: powermig setup.................................... 215
Identify source and target pseudo device names ................ 216
PPME license required............................................................. 217
PPME powermig setup............................................................ 218
Migration step 10: powermig sync.............................................. 220
Migration step 13: query status, until SourceSelected .......... 222
Migration step 18a: powermig selectTarget........................... 224
Migration step 18b: powermig commit........................................ 225
Migration step 16: powermig cleanup........................................ 227
Cleanup step 19: Redeploy source devices storage ................... 228
Chapter 10 Federated Live Migration (FLM) Overview
Introduction..................................................................................... 230
Benefits of using FLM.................................................................... 230
FLM Nondisruptive migration overview ................................... 231
FLM Definitions .............................................................................. 233
Source and target, old and new.............................................. 233
Device external identity........................................................... 233
Active and passive host access modes .................................. 234
FLM basic operation sequence...................................................... 235
FLM failback, set NO identity, and host_active................... 235
FLM considerations and restrictions............................................ 237
FLM migration using Open Replicator operation flow............ 238
Setup steps................................................................................. 238
Migration steps ......................................................................... 239
Cleanup steps............................................................................ 241
Chapter 11 FLM with Open Replicator Migration Example
Introduction..................................................................................... 244
Management or application host location for commands.. 244
FLM Setup steps 16....................................................................... 246
Setup step 1: Identify target devices ............................................ 246
Setup step 2: Configure migration SAN zone ............................ 246
Determining target VMAX director WWNs......................... 247
Determining source DMX director WWNs .......................... 248
Example configuration of migration SAN zones................. 249
Setup step 3: Configure migration device masking................... 250
Contents
Setup step 4: Configure target zoning to the application host . 251
Setup step 5: Prepare FLM session pairs...................................... 252
Setup step 6: Verify setup completion, FLM create.................... 253
Displaying the pre-create FLM status....................................253
Creating the FLM session ........................................................254
Migration step 10a: Mask the VMAX target devices ................. 256
Displaying the post-create FLM status ..................................256
Mask the VMAX target devices ..............................................260
Displaying the post-create and target masking MPIO
status ...........................................................................................261
Migration step 10b: Activate the FLM session............................ 262
Displaying the post-activate FLM status...............................263
Migration step 13: Verify FLM session copy is done ................. 264
Migration step 15: Verify migration and FLM terminate .......... 265
Cleanup step 19: Redeploy source devices storage.................... 266
Federated identity removal .....................................................268
Appendix A Open Replicator Performance Tuning
Two goals of Open Replicator tuning........................................... 270
Resource conflicts............................................................................ 271
I/O resource paths................................................................... 271
Array I/O conflicts .................................................................. 271
Limiting Open Replicator resource usage ................................... 272
Using a separate management host....................................... 272
Limiting Symmetrix FA director competition...................... 272
Migration options can impose performance delays................... 274
Tuning Open Replicator ................................................................. 275
Static configuration limits on Open Replicator resource
use .............................................................................................. 275
Dynamic limits on Open Replicator resource use............... 275
Monitoring Open Replicator performance.................................. 278
symrcopy query........................................................................ 278
symrcopy list ceiling................................................................ 278
symstat with -RepType rcopy................................................. 279
Tuning for applications sensitive to response time.................... 282
10
Contents
Appendix B Troubleshooting
Solutions Enabler logs.................................................................... 284
Cold push example log entries .............................................. 284
Hot pull example log entries.................................................. 287
Audit Log......................................................................................... 290
PowerPath Migration Enabler logs .............................................. 292
Reactivate Failed Session............................................................... 295
Glossary
Index
Title Page

1 Migration project steps.................................................................................. 25
2 Open Replicator hot (or live) push .............................................................. 49
3 Open Replicator cold (or BCV) push........................................................... 51
4 Open Replicator hot (or live) pull ................................................................ 52
5 Open Replicator cold (or point-in-time) pull ............................................. 53
6 Setup steps flowchart..................................................................................... 56
7 Migration steps flowchart ............................................................................. 60
8 Cleanup steps flowchart................................................................................ 64
9 Invoking Connectivity Status for Host in a Storage Group..................... 75
10 Host connectivity status for a CLARiiON storage group. ....................... 76
11 CLARiiON CX3-40f Storage Processor World Wide Port Names........... 76
12 Connectrix Manager activate zone verification screen............................. 77
13 SMC Remote Report menu selection........................................................... 86
14 SMC Remote Report Remote Ports.............................................................. 87
15 SMC Remote Report Remote LUNs display .............................................. 87
16 Create Page 3 showing CLARiiON Available Remote Devices .............. 88
17 Cold push migration and cleanup flowchart ............................................. 92
18 Hot pull setup, migration, and cleanup flowchart.................................. 120
19 Host connectivity status for licod194 in Storage Group D194............... 123
20 Windows drive L contents ......................................................................... 128
21 Windows Disk Management display of drives L, M, N and O............. 129
22 Activate additional zones verification screen excerpt ............................ 133
23 Disk Management display of target devices additional space .............. 140
24 Disk Management updated display showing 4 GB partitions .............. 143
25 Symmetrix hot pull setup, migration, and cleanup flowchart .............. 150
26 SMC properties for Symmetrix 000190300359 devices 9598 ................ 151
27 SMC Front End Paths detail for control target device 95....................... 152
28 SMC director 2C port 0 properties showing the port WWN................. 153
29 SMC director 15C port 0 properties showing the port WWN............... 153
30 SMC Front End Paths detail for remote source device 141...................... 154
Figures
Figures
33 Connectrix Manager activate Symmetrix hot pull zones ....................... 156
34 Disk Management display of remote source drives P, Q, R, and S ...... 157
35 SMC Device Masking menu....................................................................... 158
36 SMC add device masking for remote devices 141144 on FA-8C:0...... 159
37 SMC device masking success confirmation dialog ................................. 159
38 SMC add device masking for remote devices 141144 on FA-9C:0...... 160
39 SMC Tasks Masking Wizard selection...................................................... 162
40 Masking Wizard step 1 welcome screen................................................... 163
41 Masking Wizard step 2 create masking view.......................................... 164
42 Masking Wizard step 3 click to create Initiator Group........................... 165
43 Masking Wizard step 3 Initiator Group creation .................................... 167
44 Masking Wizard step 4 select existing Port Group................................. 168
45 Masking Wizard step 5 click to create Storage Group............................ 169
46 Storage Group creation dialog box............................................................ 170
47 Masking Wizard step 7 summary.............................................................. 171
48 Masking Wizard success dialog................................................................. 172
49 SMC properties device detail for control target device 95. .................... 173
50 SMC Open Replicator Create Copy Session menu ................................. 174
51 SMC Create Copy Session page 1: Set session parameters .................... 175
52 SMC Create Copy Session page 2: select control devices....................... 175
53 SMC Open Replicator page 3: Select remote devices.............................. 176
54 SMC Create Copy Session page 4: Select device pairs............................ 177
55 SMC Create Copy Session page 5: Set session options and execute..... 178
56 SMC Confirm Open Replicator create execution .................................... 179
57 SMC Create Copy Session success dialog box......................................... 179
58 SMC Remote Report menu selection......................................................... 180
59 SMC Remote Report Remote Ports tab..................................................... 181
60 SMC Remote Report Remote Luns display.............................................. 181
61 SMC Removing device masking for devices 141144 for FA-8C:0....... 183
62 SMC Removing device masking for devices 141144 for FA-9C:0....... 184
63 SMC Open Replicator session properties and control menu................. 185
64 SMC Open Replicator activate ................................................................... 186
65 Open Replicator session properties after activate................................... 186
66 Disk Management display of drives PS on the target devices ............ 188
67 SMC Select Open Replicator Set Ceiling Menu....................................... 189
68 SMC Open Replicator Set Ceiling.............................................................. 190
69 SMC Open Replicator session properties Refresh View update........... 191
70 SMC Open Replicator session properties showing Copied state.......... 192
71 Donor Update Off SMC Session Control dialog box .............................. 193
72 Terminate SMC Session Control dialog box ............................................ 194
73 PPME Operation with pseudo-named devices and Open Replicator.. 198
Figures
74 PPME Migration states and commands .................................................... 200
75 PPME with Open Replicator setup steps flowchart ................................ 205
76 PPME migration steps flowchart................................................................ 206
77 PPME cleanup steps flowchart ................................................................... 211
78 PPME with Open Replicator setup, migration, and cleanup steps....... 214
79 FLM operation overview............................................................................. 232
80 FLM with Open Replicator setup steps flowchart................................... 239
81 FLM migration steps flowchart .................................................................. 240
82 FLM with Open Replicator setup, migration, and cleanup steps.......... 245
83 Connectrix Manager activate zone verification screen ........................... 249
84 Windows Event Viewer with PPME error message selected................. 292
85 Event Properties detail for missing PPME license................................... 293
86 Windows Event Viewer with PPME error message selected................. 294
87 Event Properties detail for missing PPME license................................... 294
Figures
Preface
This TechBook describes best practices for using EMC Open Replicator for
Symmetrix for data migration. Advantages and proper use of EMC
PowerPath Migration Enabler (PPME) and Federated Live Migration
(FLM) using Open Replicator as the underlying technology are
comprehensively explained. Open Replicator features used for data mobility
and remote vaulting, but not for data migration, are not covered in this
guide.
As part of an effort to improve and enhance the performance and capabilities
of its product line, EMC routinely releases revisions of its hardware and
software. Therefore, some functions described in this guide may not be
supported by all revisions of the software or hardware currently in use. For
the most up-to-date information on product features, refer to the product
release notes. If a product does not function properly or does not function as
described in this document, please contact your EMC representative.
Note: This document was accurate as of the time of publication. However, as
information is added, new versions of this document may be released to the
EMC Powerlink website. Check the Powerlink website to ensure that you are
using the latest version of this document.
Audience The intended audience for this TechBook is storage administrators,
system administrators, and anyone interested in migrating
applications.
Readers of this TechBook are expected to be familiar with:
EMC Symmetrix Logical Volumes (SLVs) including masking
CLARiiON or third-party array LUNs and masking for
heterogeneous migration
Preface
SAN zoning
EMC Solutions Enabler SYMCLI and Symmetrix Management
Console (SMC)
Organization This TechBook is divided into eleven chapters and two appendices:
Chapter 1, Introduction, provides an introduction to the
interfaces and potential deployment of EMC Open Replicator for
Symmetrix together with PowerPath Migration Enabler,
Federated Live Migration, or alone. Background information
including Open Replicator terminology and required setup
operations are introduced.
Chapter 2, Brief EMC Foundation and Migration Product
Descriptions, provides an introduction to EMC Symmetrix
hardware and software technologies that are used to implement
migration solutions.
Chapter 3, EMC Open Replicator for Symmetrix,defines all
Open Replicator terminology, interfaces and operations. All of
the steps for initiating and conducting Open Replicator
operations are described.
Chapter 4, Cold Push to CLARiiON Setup Example, provides
an example of the steps needed to set up a cold push migration.
This chapter also describes additional setup requirements for hot
operations and multiple methods for verifying that Open
Replicator setup is complete. The examples shown in this chapter
use a Solaris host and SYMCLI.
Chapter 5, Cold Push to CLARiiON Migration Example,
provides an example of the steps needed to initiate, monitor and
conclude a cold push migration. The examples shown in this
chapter use a Solaris host and SYMCLI.
Chapter 6, Hot Pull from CLARiiON Migration Example,
conclude a hot pull migration. This chapter also provides an
example of incomplete zoning and masking, revealing some of
the errors that may be encountered while preparing for a hot pull
migration and presents information on how to resolve those
errors. The examples shown in this chapter use a Windows host
and SYMCLI.
Preface
Chapter 7, Hot Pull from Symmetrix Migration Example,
conclude a hot pull migration. The examples shown in this
chapter use a Windows host and the Symmetrix Management
Console (SMC).
Chapter 8, PowerPath Migration Enabler Overview, defines all
PPME terminology, interfaces and operations. All of the steps for
installing, initiating and conducting PPME Open Replicator
operations are described.
Chapter 9, PPME with Open Replicator Migration Example,
conclude a PPME with Open Replicator migration session. The
examples shown in this chapter use a Windows host and the
powermig command.
Chapter 10, Federated Live Migration (FLM) Overview, defines
all FLM terminology, interfaces, and operations. All of the steps
for initiating and conducting FLM operations are described.
Chapter 11, FLM with Open Replicator Migration Example,
provides an example of the steps needed to initiate, monitor, and
conclude a Federated Live Migration session. The examples
shown in this chapter use a Windows host and SYMCLI.
Appendix A, Open Replicator Performance Tuning,
consolidates, expands and elaborates on the performance tuning
information included within the chapters of this TechBook.
Appendix B, Troubleshooting, provides log examples that
correlate with the examples in chapters 49, and provides
troubleshooting not covered in the chapter examples.
This TechBook is the second in a series of Data Migration TechBooks.
Readers should reference the first volume, Choosing a Data Migration
Solution for EMC Symmetrix Arrays, that explores the complexity of
data migration and how to select a data migration solution for
Symmetrix in an open systems environment.
For readers who have access to EMC Powerlink, check EMC
Powerlink for new TechBooks in this Data Migration series at:
http://Powerlink.EMC.com
and then Home > Support > Technical Documentation and
Advisories > TechBooks
Alternatively, you can visit the Vervante On Demand Publishing
website at:
Preface
http://www.vervante.com/
Where to get help EMC support, product, and licensing information can be obtained as
follows:
Product information For documentation, release notes, software updates, or for
information about EMC products, licensing, and service, go to the
EMC Powerlink website (registration required) at:
Technical support For technical support, go to EMC Customer Service on Powerlink. To
open a service request through Powerlink, you must have a valid
support agreement. Please contact your EMC sales representative for
details about obtaining a valid support agreement or to answer any
questions about your account.
Related
documentation
Related documents, available on EMC Powerlink, include:
EMC Solutions Enabler Symmetrix Open Replicator CLI Product
Guide
EMC Solutions Enabler Installation Guide
EMC Solutions Enabler Symmetrix Array Management CLI
Product Guide
EMC Solutions Enabler Symmetrix Array Controls CLI Product
Guide
EMC Solutions Enabler Symmetrix SRM CLI Product Guide
EMC Solutions Enabler Symmetrix TimeFinder Family CLI
Product Guide
EMC Solutions Enabler Symmetrix SRDF Family CLI Product
Guide
EMC PowerPath Migration Enabler User Guide
Implementing PowerPath Migration Enabler in Open Replicator
and Invista Environments
Migrating Microsoft Cluster Server using EMC Open Replicator for
Symmetrix Technical Note
EMC Symmetrix LUN Expansion and UNIX Logical Volume
Managers Technical Note
EMC Enginuity 5773 Flexible Device Geometry in a Sun Solaris
Environment Technical Note
EMC Federated Live Migration Technical Overview Technical Notes
Preface
EMC Federated Live Migration Simple Support Matrix
Choosing a Data Migration Solution for EMC Symmetrix Arrays
TechBook
White paper: New Features in EMC Enginuity 5875 for Symmetrix
Open Systems Environments
EMC Symmetrix Enginuity Release Notes (multiple release levels
available)
EMC Solutions Enabler Version 7.2 Release Notes
EMC Symmetrix Management Console Version 7.2 Release Notes
Storage Provisioning With EMC Symmetrix Auto-provisioning
Groups Technical Note
Implementing Fully Automated Storage Tiering with Virtual Pools
(FAST VP) for EMC Symmetrix VMAX Series Arrays Technical
Notes
Typographical
conventions
EMC uses the following type style conventions in this document:
Normal Used in running (nonprocedural) text for:
Names of interface elements (such as names of windows, dialog boxes, buttons,
fields, and menus)
Names of resources, attributes, pools, Boolean expressions, buttons, DQL
statements, keywords, clauses, environment variables, functions, utilities
URLs, pathnames, filenames, directory names, computer names, filenames, links,
groups, service keys, file systems, notifications
Bold Used in running (nonprocedural) text for:
Names of commands, daemons, options, programs, processes, services,
applications, utilities, kernels, notifications, system calls, man pages
Used in procedures for:
Names of interface elements (such as names of windows, dialog boxes, buttons,
fields, and menus)
What user specifically selects, clicks, presses, or types
Italic Used in all text (including procedures) for:
Full titles of publications referenced in text
Emphasis (for example a new term)
Variables
Courier Used for:
System output, such as an error message or script
URLs, complete paths, filenames, prompts, and syntax when shown outside of
running text
Preface
The author of this TechBook
This TechBook was written by Donald Fried-Tanzer, an employee of
EMC based at headquarters in Hopkinton, Massachusetts. Donald
has over 30 years of experience in client-server applications,
fault-tolerant servers, and storage management software including:
provisioning, remote replication, local replication, migration,
configuration, and monitoring.
We'd like to hear from you!
Your feedback on our TechBooks is important to us! We want our
books to be as helpful and relevant as possible, so please feel free to
send us your comments, opinions, and thoughts on this or any other
TechBook:
TechBooks@emc.com
Courier bold Used for:
Specific user input (such as commands)
Courier italic Used in procedures for:
Variables on command line
User input variables
< > Angle brackets enclose parameter or variable values supplied by the user
[ ] Square brackets enclose optional values
| Vertical bar indicates alternate selections - the bar means or
{ } Braces indicate content that you must specify (that is, x or y or z)
... Ellipses indicate nonessential information omitted from the example
Introduction 21
1
This chapter provides a brief summary of the three migration
products covered in this guide: EMC Open Replicator for Symmetrix,
EMC PowerPath Migration Enabler (PPME), and Federated Live
Migration (FLM). Key terminology and setup requirements for Open
Replicator are introduced. The full set of migration project steps is
depicted identifying the project steps covered in this book and where
to find more information on other project steps. An abbreviated
approach to choosing whether to use Open Replicator with PPME or
Federated Live Migration concludes the chapter. The topics covered
include:
Introduction ........................................................................................ 22
Data Migration definition................................................................. 22
EMC Open Replicator for Symmetrix............................................. 22
EMC PowerPath Migration Enabler................................................ 24
Federated Live Migration ................................................................. 24
Migration project steps...................................................................... 25
When to use Open Replicator with PPME ..................................... 26
When to use Federated Live Migration.......................................... 27
Operational interfaces ....................................................................... 28
Introduction
Introduction
Introduction
EMC
Open Replicator for Symmetrix
enables the creation of

remote point-in-time copies that can be used for data mobility, remote
vaulting, and migration between EMC Symmetrix VMAX
(or
Symmetrix DMX
)

and qualified storage arrays with full,
incremental, offline (cold), and online (hot) copy capabilities. This
TechBook will focus on the use of Open Replicator for data migration
only.
Data Migration definition
Data Migration can be defined as the one time movement of data
from a source to a target, where the data will subsequently only be
accessed at the target. The key to this definition is that for any
particular piece of data, this is a one time movement. This one time
movement differentiates Data Migration from Replication where
applications continue to access the source data after the target copy is
created. Also, the one time movement differentiates Data Migration
from Data Mobility where incremental updates to the data would
continue to be applied.
By definition data migration refers to the relocation of data. After a
migration operation, applications that access the data must reference
the data in its new location. Therefore, part of the migration solution
is the methodology used to point applications to the new data
location (also known as application cutover). Few if any applications
have been designed with the ability to continue processing during the
application cutover process. Therefore either an application outage
will be required, or the migration must be transparent to the
application.
EMC Open Replicator for Symmetrix
Terminology: Control and remote
Open Replicator can transfer data between Symmetrix arrays
(homogeneous,) or between a Symmetrix VMAX (or
Symmetrix DMX) and another qualified Fibre Channel array
(heterogeneous). The Symmetrix VMAX (or Symmetrix DMX) where
EMC Open Replicator for Symmetrix 23
Introduction
Open Replicator runs, and its devices are always referred to as the
control side of the copy operation. Other Symmetrix arrays,
CLARiiON
arrays, or third-party arrays on the SAN are referred to

as the remote array/devices.
Control FA "host" setup requirements
Open Replicator runs as an application in the Fibre Director (FA) of
the Symmetrix VMAX (or Symmetrix DMX). The Open Replicator
software causes the FA to appear as an open systems host to the
remote storage array. Therefore, no special software is needed in the
remote storage array. However, zoning and LUN masking is needed
to access the remote devices and must be defined (as is the case
anytime a host needs to access devices on a remote storage array).
Configuring the required zoning and LUN masking is the most
common area where problems occur when setting up Open
Replicator and will be covered thoroughly in multiple examples.
Additionally, multiple methods for verifying that the setup is correct
will be covered in the examples.
Terminology: Push and pull, cold and hot
Open Replicator supports two types of copy operations: push and
pull. A push operation copies data from the control device to the
remote device. A pull operation copies data to the control device from
the remote device. Open Replicator has two modes of operation: cold
(offline) and hot (online). These two modes refer to the state of the
Symmetrix VMAX (or Symmetrix DMX) resident devices (control
devices). The terms online or offline are used to indicate the potential
state of a host application that uses these devices. Only with a hot
operation can an application using Symmetrix VMAX (or Symmetrix
DMX) based storage remain online. For data consistency reasons, the
remote devices must never be written to by any host connected to the
remote array. In cases where the remote device is the source of the
Open Replicator copy operation (a pull operation), it may be
permissible for a remote host to have read-only access to the remote
device.
Introduction
Multipathing with hot setup requirements
Typically a Symmetrix device is visible to a host on more than one
I/O path. This is done to improve both fault tolerance (failover) and
performance (load balancing). Multipathing is accomplished by
configuring the Symmetrix to present Symmetrix Logical Volumes
(SLVs) as being visible to the application host on more than one FA
port. The application host must use some type of multipathed I/O
solution in order to correctly handle the same device being presented
on more than one I/O path. A common multipathing host solution is
EMC PowerPath
. The combination of multipathed control devices

and hot Open Replicator operations result in the greater requirement
that all FA directors that present the control devices, must be zoned
and LUN masked as hosts able to access the remote array devices.
When using Open Replicator hot pull as the underlying technology
for Federated Live Migration (FLM), all FA directors that present the
new VMAX devices, must be zoned and LUN masked as hosts able to
access the donor array devices.
EMC PowerPath Migration Enabler
PowerPath Migration Enabler (PPME) is a hybrid migration solution
that provides the ability to perform nondisruptive migrations or
encapsulations while leveraging another underlying technology, such
as Open Replicator, TimeFinder/Clone, Invista
, or Host Copy.
PPME provides a solution with virtually no impact to host resources
by utilizing array-based or SAN-based replication (except for Host
Copy). PPME benefits data migrations by greatly reducing or
eliminating application disruption caused by the migration, reducing
migration risk, and simplifying migration operations. PowerPath
Migration Enabler can be installed without PowerPath multipathing
technology, but PowerPath multipathing is required for completely
nondisruptive migrations. This TechBook only covers PPME
operation with Open Replicator.
Federated Live Migration
Federated Live Migration (FLM) is a method by which a user can
move data from older storage into a new VMAX array
nondisruptively. The host application cutover to use the new VMAX
devices is made transparent by a combination of presenting the
Migration project steps 25
Introduction
VMAX devices as additional paths to the old devices and managing
which paths are active through a multipath I/O (MPIO) driver on the
host. FLM supports PowerPath as the application MPIO driver, and
will support additional MPIO drivers in the future. FLM supports
moving the data with Open Replicator SAN-based replication, and
will support other underlying technologies in the future. Unlike
application host-based PPME, control of the migration and cutover is
managed through the VMAX array. FLM greatly simplifies
migrations requiring no remediation when migrating pre-qualified
stacks.
Migration project steps
Figure 1 summarizes the basic migration flow.
Figure 1 Migration project steps
This TechBook is focused on operational migration examples, similar
to a Migration Pilot. There is also some inclusion of the Migration and
Cutover step particularly in describing how PowerPath Migration
ICO-IMG-000440
Business Impact
Analysis
Source Configuration
Discovery
Migration Strategy
and Tool Selection
Detailed Mapping
and Design
Provisioning
Skill Refreshing Migration Pilot
Migration and
Cutover
Sign-off
Introduction
Enabler (PPME) and Federated Live Migration (FLM) each simplify
this step. The Migration Strategy and Tool Selection step is where the
decision would be made whether to use Open Replicator alone or
together with PPME or FLM. The Selection step requires both the
Business Impact Analysis and Source Configuration Discovery steps
to provide necessary input. These first three steps are covered in the
first volume in the Data Migration series of TechBooks, Choosing a
Data Migration Solution for EMC Symmetrix Arrays. The selection
model defined for migration tool selection is conducted here in an
abbreviated manner.
When to use Open Replicator with PPME
In this case, the starting assumption is that EMC Open Replicator for
Symmetrix has been selected as the main migration tool and the
decision is whether to use it alone or in conjunction with PPME. To
make this determination, follow the iterative six step model shown
below, and provide answers to the highlighted applicable key questions.
How these questions are answered will determine whether Open
Replicator should be used alone, or in conjunction with PPME.
1. Define the reasons for the data migration, clearly noting
mandatory and optional objectives.
Applicable key question: Is this a transformational migration in the
sense of including the permanent addition of migration enablers
for future migrations?
2. Inventory the existing environment and identify storage elements
that must participate with the chosen data migration solution,
along with resources that are available to suppo?t the migration
itself.
3. Inventory the target environment identifying storage elements
and resources available to support the migration itself.
4. Identify potential data migration solutions that can successfully
move the data from the existing environment to the target
environment.
Applicable key question: Is PPME and transparent migration
supported in the existing and target environments?
When to use Federated Live Migration 27
Introduction
5. Identify business factors that limit potential data migration
solutions such as budget, human resources, and application
outage and verification requirements.
Applicable key question: How important is avoiding application
interruptions now or in the future, reducing migration risk, and
simplifying migration operations?
6. Compare and evaluate the potential data migration solutions
including the criteria identified in steps 15.
The answers provided to the applicable key questions defined in steps 1,
4 and 5 can identify opportunities to realize the advantages of using
PPME together with Open Replicator. PPME can greatly reduce or
eliminate application disruption due to the migration. If this is a key
factor for the current or future migrations, then it is likely that the use
of PPME will be beneficial. However, the ability of PPME to
completely eliminate any migration related interruptions is limited
by the presence of PowerPath 5.x on the migration host, the type of
host, and the host's support for PPME and PowerPath pseudo
devices. Lastly, in step 6, the relative importance of the answer to the
applicable key question in step 5 must be evaluated against any
offsetting factors such as cost or other restrictions.
When to use Federated Live Migration
Federated Live Migration (FLM) currently best fits cases of data
center consolidation and technology refresh when the old donor
array will be removed from sharing the same SAN as the new VMAX.
The iterative six step model and applicable key questions can be used to
determine whether FLM should be used:
1. Define the reasons for the data migration, clearly noting
mandatory and optional objectives.
Applicable key question: Is this a data center consolidation or
technology refresh which will remove the old donor array?
2. Inventory the existing environment and identify storage elements
along with resources that are available to support the migration
itself.
Applicable key question: Is the existing environment an FLM
pre-qualified stack?
Introduction
3. Inventory the target environment identifying storage elements
and resources available to support the migration itself.
Applicable key question: Is the target storage array a VMAX
running Enginuity
5875 or later?
4. Identify potential data migration solutions that can successfully
move the data from the existing environment to the target
environment.
Applicable key question: Is FLM supported in the existing and target
environments?
5. Identify business factors that limit potential data migration
solutions such as budget, human resources, and application
outage and verification requirements.
Applicable key question: How important is avoiding application
interruptions, avoiding application host operations, reducing
migration risk, and simplifying migration operations?
6. Compare and evaluate the potential data migration solutions
including the criteria identified in steps 15.
The answers provided to the applicable key questions can identify
opportunities to realize the advantages of using FLM. FLM can
eliminate application disruption due to the migration without
operations on the application host. If this is a key factor for
migrations, then it is likely that the use of FLM will be beneficial.
Operational interfaces
There are three different interfaces available to control EMC Open
Replicator for Symmetrix: the Solutions Enabler Command Line
Interface (CLI), the Symmetrix Management Console (SMC)
Graphical User Interface (GUI), and the PowerPath Migration
Enabler (PPME) CLI. Examples of using all three interfaces are
included in this TechBook. Note that the PPME CLI interface has
fewer operational steps and provides a greater breadth with the
inclusion of migration cutover operations than is available with the
Solutions Enabler CLI or SMC alone.
Federated Live Migration (FLM) can be performed using the existing
CLI and SMC interfaces for Open Replicator with additional options
specifically for FLM. CLI and SMC interfaces for Auto-provisioning
groups is also used at a specific time as part of FLM. SMC also
supports a specific FLM wizard.
Brief EMC Foundation and Migration Product Descriptions 29
2
This chapter provides brief descriptions of EMC Symmetrix
hardware and software technologies that may play a role in a data
migration using Open Replicator, PPME, and FLM. The topics
covered include:
Introduction ........................................................................................ 30
EMC Symmetrix storage arrays and associated software............ 32
EMC CLARiiON and associated software ..................................... 35
EMC SAN products ........................................................................... 38
EMC Host products ........................................................................... 40
Consulting and IT Services............................................................... 42
Brief EMC Foundation
and Migration Product
Descriptions
Brief EMC Foundation and Migration Product Descriptions
Introduction
This chapter contributes to the selection model introduced in
Chapter 1, by providing brief introductions of EMC products that
will be used primarily in selection model steps 24. Chapter 2 of the
Choosing a Data Migration Solution for EMC Symmetrix Arrays TechBook
has a more complete listing of EMC migration-related products. The
subset of products included in this chapter were chosen because they
can be operationally relevant to using Open Replicator, PPME, and
FLM.
Products are presented in the following groupings: Symmetrix,
CLARiiON, SAN, Host, and Services:
Symmetrix storage arrays are present in all Open Replicator or
Federated Live Migration configurations, because at least one
Symmetrix VMAX (or Symmetrix DMX) storage array must be
present as the control array or new FLM array. Other Symmetrix
storage arrays may act as the remote array in Open Replicator
operations or old/donor array for FLM. The TimeFinder
family
of local replication products may be used to create point-in-time
copies for cold operations. The SRDF
family of remote
replication products may provide information about remote
Symmetrix arrays and can be used to perform remote operations.
Solutions Enabler, the Symmetrix Management Console (SMC),
and EMC Ionix

ControlCenter
Symmetrix Manager are

associated management software for managing the Symmetrix.
CLARiiON storage arrays may act as the remote array in Open
Replicator operations. The SAN Copy
product is a CLARiiON
based product with functionality similar to Open Replicator. It is
included with a short discussion of a use case where SAN Copy
might be used instead of Open Replicator. Navisphere

Management Suite is an associated management software that
can be used to set up the CLARiiON to work as a remote array in
Open Replicator operations.
Note: EMC Unisphere
is the next generation of mid-tier storage

management that provides a single, integrated, and simple user interface for
EMC CLARiiON, EMC Celerra
and EMC RecoverPoint SE systems.

Unisphere replaces Navisphere as the management interface for CLARiiON
starting with the FLARE
30 release.
Introduction 31
EMC Connectrix
products are SAN switches and directors

which, as part of the SAN, contain the zoning that must be
properly defined in order for Open Replicator and FLM to work.
EMC Connectrix Manager and Ionix ControlCenter SAN
Manager
are associated management software capable of

managing and monitoring zoning. Invista Storage Virtualization
runs in the SAN and is mentioned briefly because PPME can
work with Invista as the underlying replication technology.
The host grouping includes migration related products that
execute solely on a customer host system, as well as products that
provide a host-executable control interface for array or
SAN-based migration software. PowerPath multipathing can
affect the setup requirements for Open Replicato? and supported
application host multipathing is required for FLM. PowerPath
Migration Enabler (PPME) also executes on the host. Control
interfaces include Solutions Enabler, Symmetrix Management
Console (SMC), and EMC Ionix ControlCenter.
Services are very often a key component of actual data
migrations. In many cases, a majority of the migration costs are in
discovery, documentation, mapping and design, provisioning,
piloting and qualification. EMC Services are a key method to
reduce risk and ensure the success of data migrations.
EMC Symmetrix storage arrays and associated software
The following sections describe the Symmetrix array: basic
architecture, operating environment, logical volumes, array types
used with Open Replicator, replication and management software.
Basic architecture
Symmetrix is a high-end enterprise storage system with maximum
capacity and the highest performance, consolidating massive
amounts of data and host applications and storage tiers on reliable,
cost-effective networked storage. Symmetrix provides broad
connectivity with 4 Gb/s performance, advanced security, high
availability, and energy efficiency in an easy-to-operate storage
system.
Symmetrix is an Integrated Cached Disk Array (ICDA). All I/Os are
cached. There are three functional areas:
Shared Global Memory provides cache memory
Front-end directors connect to hosts and service all host I/O
requests to/from cache
Back-end directors stage and destage data between cache and
physical disk drives
The Symmetrix architecture can be compared to a MPP (Massively
Parallel Processing) server with directors working simultaneously
performing all the tasks of the array.
EMC Enginuity Operating Environment
Symmetrix storage arrays run EMC Enginuity
, the most mature,

comprehensive, stable, highly available, and proven storage
operating environment in the industry. Enginuity is the emulation
code, service processor code and other software used by a Symmetrix
to implement core functionality. Each processor in every director is
loaded with specific emulation code. Enginuity coordinates the
independent director processors to act as one Integrated Cached Disk
Array. Enginuity provides base system functionality and advanced
features like local (TimeFinder) and remote (SRDF) replication, Open
Replicator and other optional software products.
EMC Symmetrix storage arrays and associated software 33
Symmetrix Logical Volumes
Symmetrix Logical Volumes (SLVs) are logical abstractions of
physical disk drives that are presented to open system hosts as FBA
(Fixed Block Architecture) devices. EMC and customers configure
these devices using Symmetrix management software. More
information about this software is available in Symmetrix
management software on page 35. Enginuity also provides the
capability to map SLV visibility on specific FA adapters and to limit
visibility to specific Host Bus Adapters (HBAs) on a switched Fibre
Channel connection using device masking (LUN masking).
Symmetrix Access Controls can be used as a further security feature
to specifically limit the types of actions possible on devices from
specific hosts.
Symmetrix VMAX and Symmetrix DMX arrays and Open Replicator
The current Symmetrix models Symmetrix VMAX SE and Symmetrix
VMAX Series run Enginuity level 5875. The previous Symmetrix
model family DMX-4 950/15004500 can run Enginuity levels 5772 or
5773. The third set of Symmetrix DMX models were the DMX-3
950/15004500 and can run Enginuity levels 5771, 5772 or 5773. The
first DMX models were the DMX-1/DMX-2 800/1000/2000/3000 and
can run Enginuity levels 5670 or 5671. Enginuity levels 5671 and 5771
were the first levels to include the EMC Open Replicator for
Symmetrix software. Open Replicator runs as an application in the
Fibre Director (FA) of the Symmetrix VMAX or Symmetrix DMX. The
Open Replicator software causes the FA to appear as an open systems
host to the remote storage array, while it continues to simultaneously
function as the host front-end to the Symmetrix. Enginuity level 5875
is the first level to include Federated Live Migration (FLM) software.
Donor DMX arrays for FLM need to have Enginuity levels 5671 or
5773 that include FLM support.
Pre-DMX Symmetrix arrays and Open Replicator
Earlier Symmetrix arrays cannot run Enginuity 5x71 code and
therefore cannot act as the control array for Open Replicator.
However, since previous arrays have front-end Fibre Channel
support, they can act as the remote array for Open Replicator.
Other Symmetrix software
Symmetrix Remote
Data Facility (SRDF)
Family
The EMC Symmetrix Remote Data Facility (SRDF) family of
replication software offers various levels of Symmetrix based
business continuance, disaster recovery and data mobility solutions.
SRDF products offer the capability to maintain multiple,
host-independent, mirrored copies of data. The Symmetrix systems
can be in the same room, in different buildings within the same
campus, or hundreds to thousands of kilometers apart. By
maintaining copies of data in different physical locations, SRDF is an
effective mechanism for data center migration. SRDF is designed for
Symmetrix to Symmetrix connections through Fibre Channel, Gigabit
Ethernet (GigE), and ESCON. SRDF has been a part of Enginuity
since 1994.
TimeFinder Family The EMC TimeFinder family of software is the most powerful suite of
local storage replication solutions available. Fully leveraging the
industry-leading high-end Symmetrix hardware architecture, it offers
unmatched deployment flexibility and massive scalability to deliver a
wide range of in-the-system data copying capabilities to meet mixed
service level requirements without operational impact. The
field-proven TimeFinder family is the most widely deployed set of
high-end replication solutions in the industry, with tens of thousands
of installations in the most demanding environments. And, only the
TimeFinder family can provide cross-volume and cross-storage
system consistency, tight integration with industry leading
applications, and simplified usage through automated management.
The EMC TimeFinder family of local replication allows users to
nondisruptively create and manage point-in-time copies of data to
allow operational processes, such as backup, reporting, and
application testing to be performed independent of the source
application to maximize service levels without impacting
performance or availability.
TimeFinder/Clone, TimeFinder/Mirror or TimeFinder/Snap can
play a role in Open Replicator data migration in two ways. First,
TimeFinder can be used to create a local point-in-time copy for an
Open Replicator cold push migration to a remote array. Both
TimeFinder and Open Replicator include incremental support, so this
point-in-time copy can be incrementally updated, followed by an
incremental Open Replicator update to quickly reach the new
point-in-time. At the end of the migration, the final TimeFinder and
Open Replicator incremental updates would be conducted after
EMC CLARiiON and associated software 35
production I/O was stopped to the production device. Second, if the
remote array is a Symmetrix, TimeFinder can be used to ensure a
backup copy of the production data is available at the remote location
in case there is a disruption during an Open Replicator incremental
push. This is necessary, because when Open Replicator performs an
incremental update from the production volumes, the data on the
remote devices is not in a consistent state until the update completes.
Note: Enginuity 5874 and later no longer support native TimeFinder/Mirror
operations. However, TimeFinder/Mirror commands are still supported
using the TimeFinder/Clone emulation feature. Therefore, usually there are
no changes in the operational details provided for integrating
TimeFinder/Mirror with Open Replicator. The emulation feature is not
supported for virtually provisioned (thin) devices; in this case new scripts
using native TimeFinderClone commands (symclone) must be used in place
of emulated TimeFinder/Mirror commands (symmir).
Symmetrix
management
software
Enginuity and array-based applications like SRDF and TimeFinder
reside in the Symmetrix array and can be managed by host
applications. EMC Solutions Enabler includes a CLI interface for
Open Replicator, SRDF, TimeFinder, device configuration, device
mapping, and device masking. Symmetrix Management Console
(SMC) provides a browser-based GUI interface on top of Solutions
Enabler. Ionix ControlCenter Symmetrix Manager is a central feature
of the Ionix ControlCenter family of products, which provides a
unified view for multiple arrays via a single-pane-of-glass interface.
Symmetrix Manager is used to discover, monitor, and configure
Symmetrix storage from a single console including the ability to
automate key system management, and replication tasks.
EMC CLARiiON and associated software
CLARiiON arrays combine advanced, easy-to-use midrange
networked storage with robust software capabilities. CLARiiON also
provides the high availability and scalability needed to manage and
consolidate more data. CLARiiON arrays have front-end Fibre
Channel support and can act as the remote array for Open Replicator.
EMC MirrorView
EMC MirrorView
provides synchronous and asynchronous remote

replication options across IP and Fibre Channel networks.
MirrorView is used for remote replication between CLARiiON arrays
across IP and Fibre Channel networks and can also be used for data
migration.
SnapView
SnapView
is used to create and manage local point-in-time

snapshots and complete data clones for testing, backup, recovery and
migration operations. When the Open Replicator remote array is a
CLARiiON, SnapView can be used to ensure a backup copy of the
production data is available at the remote location in case there is a
disruption during an Open Replicator incremental push. This is
necessary, because when Open Replicator performs an incremental
update from the production volumes, the data on the remote devices
is not in a consistent state until the update completes.
SAN Copy
SAN Copy copies data between multi-vendor storage systems over
the high-speed SAN infrastructure or WAN in a manner very similar
to EMC Open Replicator for Symmetrix. When using SAN Copy, the
CLARiiON Storage Processor acts as a host to the remote storage
array. Again, no special software is needed in the remote array. Like
Open Replicator, SAN Copy supports incremental copy capabilities
for local array-based sources. SAN Copy would likely be used
instead of Open Replicator when there is a need for incremental
support while copying data from a CLARiiON source to a Symmetrix
target.
Navisphere Management Suite
Navisphere provides browser-based discovery, monitoring,
configuration, and reporting on multiple EMC CLARiiON storage
arrays. Navisphere provides management for CLARiiON's advanced
software functionality including: EMC Navisphere Quality of Service
Manager, Navisphere Analyzer, SnapView, SAN Copy, and
MirrorView. Navisphere also provides the mechanism to set the LUN
EMC CLARiiON and associated software 37
masking required to make CLARiiON LUNs accessible to the
Symmetrix VMAX (or Symmetrix DMX) FA Open Replicator "host."
For CLARiiONs running FLARE 30 or later EMC Unisphere replaces
Navisphere, Unisphere Quality of Service Manager replaces
Navisphere Quality of Service Manager, and Unisphere Analyzer
replaces Navisphere Analyzer.
EMC SAN products
Connectrix
EMC Connectrix products are advanced directors and switches for
creating an efficient, scalable, high-availability SAN infrastructure.
EMC offers a comprehensive line of Connectrix switches and
directors that scale from 8 to 528 ports. Some models provide support
for SAN Extension, SAN Routing, and network-hosted applications
such as EMC RecoverPoint and EMC Invista.
Connectrix Manager
EMC Connectrix Manager provides an interface to the Connectrix
server, centralized management of multiple enterprise directors and
switches, and a high-level view of the enterprise storage network
within the local data centers or at geographically dispersed locations.
Connectrix Manager can be used to configure the required zoning for
the Symmetrix VMAX (or Symmetrix DMX) FA Open Replicator
"host" and the remote storage array for using Open Replicator alone or
with PPME or FLM.
SAN Manager
Ionix ControlCenter SAN Manager streamlines and centralizes
management of multivendor SANs from one easy-to-use interface.
SAN Manager can be used to configure the required zoning for the
Symmetrix VMAX (or Symmetrix DMX) FA Open Replicator "host"
and the remote storage array for using Open Replicator alone or with
PPME or FLM.
Invista
Invista Storage Virtualization introduces a hardware abstraction layer
to storage infrastructure, decoupling storage from operating systems.
The storage device that is visible to a host is no longer array specific,
but is a virtual entity that allows the arrays providing the capacity to
be interchanged as business needs dictate, resulting in the ability to
move, expand, or change the storage infrastructure while the
application remains online. Applications can be migrated between
EMC SAN products 39
storage tiers or onto refreshed storage systems while reducing or
eliminating planned downtime. Storage Virtualization is a
technology enabler for Information Lifecycle Management (ILM).
Storage Virtualization also provides a common means for storage
management across heterogeneous storage platforms, which
simplifies management and reduces operating cost for ongoing data
migration needs. PowerPath Migration Enabler can use Invista as the
underlying SAN-based data migration technology.
EMC Host products
PowerPath Family
The PowerPath family enables EMC host-based solutions including
multipathing, data migration, and host-based encryption.
PowerPath Multipathing automatically tunes the storage area
network (SAN) and selects alternate paths for data if necessary.
Residing on the server, PowerPath Multipathing enhances SAN
performance and application availability. It also integrates
multiple path I/O capabilities, automatic load balancing, and
path failover functions for complete path management.
PowerPath multipathing is qualified to correctly support the
changing status of active and passive paths key to FLM
operations.
PowerPath Migration Enabler (PPME) enables other
technologies, like array-based replication, virtualization and Host
Copy, to eliminate application downtime during data migrations
or virtualization implementations. PPME keeps arrays in sync
during Open Replicator data migrations (with minimal impact to
host resources). PPME also provides ease of use for data
migrations that reduce risk and lower costs. In addition, PPME
enables seamless deployment of Invista virtualized environments
by encapsulating (or bringing under the control of) the volumes
that will be virtualized.
Replication Manager
Replication Manager is used to administer multiple EMC replication
technologies and coordinate the entire replication process, from
discovery and configuration to the operation of multiple disk-based
replicas. Replication Manager can be used to automate the discovery
of storage arrays, applications, replication technologies, and hosts.
With Replication Manager, all information and activities for replicas
can be recorded and catalogued. Replication Manager provides a
wizard-driven interface to create copies of information and includes
support for TimeFinder alone or integrated with SRDF, SnapView
alone or integrated with MirrorView, SAN Copy, RecoverPoint,
Celerra
SnapSure, Celerra Replicator, and Invista Clones.

EMC Host products 41
EMC Solutions Enabler
An EMC Solutions Enabler installation provides the host with
SYMAPI, CLARAPI, and STORAPI shared libraries for use by
Solutions Enabler applications, and the Symmetrix Command Line
Interface (SYMCLI) for use by Storage Administrators and Systems
Engineers. SYMCLI is a specialized library of UNIX-formatted
commands that can be invoked one at a time. It supports single
command line entries and scripts to map and perform control
operations on devices and data objects. It also can be used to monitor
device configuration and status of devices that make up the storage
environment. The target storage environments are typically
Symmetrix, but can be CLARiiON when you have a license and work
with the mapping SRM component.
Symmetrix Management Console
As a small and easy-to-implement, browser-based graphical
interface, SMC can be hosted on a small Windows, Linux or Solaris
server and is accessible via a client web browser from nearly
anywhere in the world. Because of this minimal infrastructure, SMC
is an ideal graphical complement to SYMCLI and even to full Ionix
ControlCenter for performing basic device management of a
Symmetrix system. SMC is also an exceptional product for those
comfortable with SYMCLI, but who might be looking for an easy,
graphical interface for controlling their Symmetrix arrays. Like
Solutions Enabler, the SMC Server can be run from any host which
has at least one Symmetrix device visible to it. With the introduction
of the VMAX, the SMC Server can also be setup to run on the
Symmetrix Service Processor providing an out of band management
path for the Symmetrix. The SMC Server can also be configured to
remotely connect to another Solutions Enabler host which has at least
one Symmetrix device visible to it. With SMC, users can manage
operations from device creation to virtual provisioning to replication
configuration and monitoring. And as needs change and grow,
higher-level, storage resource management capabilities can easily be
added through the Ionix ControlCenter family. SMC provides a
wizard based interface for setting up Open Replicator migrations
including selection of control and remote devices through available
devices windows. SMC also provides a wizard for Federated Live
Migration (FLM).
EMC Ionix ControlCenter
EMC Ionix ControlCenter simplifies and automates key tasks, such as
discovery, monitoring, reporting, planning, and provisioning for
even the largest, most complex storage environments. Ionix
ControlCenter can manage storage, fabric, and hosts, providing a
unified, single-pane-of-glass view for multiple arrays, switches and
hosts. When performing migrations, its GUI interface is an ideal way
to both provision the target environment and to reconfigure the SAN.
Ionix ControlCenter is a family of products with additionally licensed
features including SAN Manager. Base ControlCenter packaging
includes both Solutions Enabler and Symmetrix Management
Console. The key Symmetrix Management piece is the Ionix
ControlCenter Symmetrix Manager. CLARiiON, Celerra, and EMC
Centera
management tools can be launched from within the

ControlCenter framework. The Ionix ControlCenter infrastructure
includes one or more dedicated server hosts and agents that reside on
managed hosts. With this infrastructure, ControlCenter is able to
scale to support very large enterprises.
Consulting and IT Services
The overall data migration flow diagram introduced in Figure 1 on
page 25, included the following project steps needed to complete a
data migration:
Business Impact Analysis
Source Configuration Discovery
Migration Strategy and Tool Selection
Detailed Mapping and Design
Provisioning
Skill Refreshing
Migration Pilot
Migration and Cutover
From this list of eight steps where only one is directly related to
moving data, it would be correct to conclude that the challenge of a
data migration is not just moving the data. EMC has a plethora of
products available to address just about every type of migration
scenario you can imagine. Choosing a Data Migration Solution for EMC
Symmetrix Arrays contains greater detail. In reviewing actual
migrations, it becomes evident that most migration costs are
associated with discovery, documentation, mapping and design,
Consulting and IT Services 43
provisioning, piloting and qualification. Therefore, when planning a
migration, it is worth considering contracting EMC Services for
assistance in many of these areas.
Application Consulting
Create intuitive digital experiences and use information to
collaborate, make decisions, and automate processes.
Business Consulting
Drive product leadership, differentiated customer experience, and
operational excellence.
Industry Consulting
Leverage our deep industry expertise and broad technology
competencies to achieve market leadership.
Infrastructure Consulting
Transform infrastructure and operations into IT services that support
business growth and change.
Application infrastructure optimization
Lower the cost of ongoning operations, simplify administrative tasks,
and imporve the security and reliability of your appplication
infrastructure.
Data center transformation
Accelerate your data centers strategic business value, leveraging
EMCs best practices and infrastructure expertise.
Data protection and availability
Ensure secure and predictable access to critical business data and
systems with the architectures, systems, and strategies that provide
availaility and recoverability.
Infrastructure strategy and architecture
Turn your IT organization into a service provider to your business by
balancing service-level needs and costs with a service-based
infrastructure stategy and architecture.
IT process optimization
Optimize your IT data center operational processes. Leverage EMC
best practices as well as Information Technology Infrastructure
Libary (ITIL) and other international standards.
Security strategy and development
Develop a strategic IT security road map that reduces security risks in
a durable manner and meets compliance and business requirements.
Service-oriented infrastructure
Deliver information infrastructure strategies tailored to your specific
business requirements that balance cost and service-level
requirements.
Private Cloud & Virtualization Consulting
Deliver business agility and IT flexibility and efficiency at enterprise
scale.
IT Services
Assessment Services
Identify possible strategies for your information infrastructure to
meet your business and technical goals.
Business Continuity Services
Obtain a complete suite of services for your business continuity
needs.
Design and Implementation Services
Get best practices recommendations and proven methodologies for
hardware and software design and implementation.
Consulting and IT Services 45
Disk Security Services
Secure information and support your compliance initiatives.
Enterprise Content Management Implementation Services
Combine enterprise content management with storage,
virtualization, archiving, and backup and recovery.
Migration Services
Ensure safe migration of all your data among EMC storage systems
or between heterogeneous systems.
Performance Assessments and Health Checks
Maintain high service levels by identifying factors that affect storage
platform performance.
Services for VMware Environments
Unlock the full spectrum of your virtualization efficiencies and
benefits with EMC Global Services.
VMware, Cisco, and EMC Services
Integrate Vblock into your IT operations with the help of Virtual
Computing Environment Coalition (VCE) consultants, who apply
best practices and multidomain experience.
Managed services
Meet your specific needs at every phase of your journey to the private
cloud with EMC Managed Services. Augment or complement your
existing resources with EMC residents who offer short-term,
day-to-day technology, operational, and architectural support. You
can also obtain longer-term support to help you implement and
optimize specific storage processes and operations. In addition, EMC
can manage some or all of your storage assets.
Managed Availability
Gain multi-year business continuity support for a wide range of
recovery solutions, including internal and third-party recovery site
options.
Remote Managed Services
Manage your information infrastructure through cost-effective, 24x7
intelligent remote monitoring and management based on defined
service level objectives.
Residency Services
Fulfill short-term storage resource or skill gaps, accelerate integration
of new information infrastructure assets, and streamline
administrative and support processes.
Storage Managed Services
Meet your service-level agreements and address your most critical
budget, storage management, and control challenges.
EMC Open Replicator for Symmetrix 47
3
This chapter provides definitions and descriptions of Open
Replicator capabilities. The full set of operational steps available to
control any migration using Open Replicator is described. Specific
migration scenarios using alternate control interfaces show examples
of these steps in subsequent chapters. The topics covered include:
Introduction ........................................................................................ 48
Definitions........................................................................................... 48
Basic Open Replicator migration operation flow.......................... 55
Monitoring, troubleshooting and recovery.................................... 65
Control interface alternatives ........................................................... 67
Reference information....................................................................... 68
EMC Open Replicator
for Symmetrix
Introduction
EMC Open Replicator for Symmetrix enables remote point-in-time
copies to be used for data mobility, remote vaulting, and migration
between EMC Symmetrix VMAX (or Symmetrix DMX) and qualified
storage arrays with full or incremental copy capabilities. Open
Replicator can:
Pull from source volumes on qualified remote arrays to a
Symmetrix VMAX (or Symmetrix DMX) volume
Push any live source Symmetrix VMAX (or Symmetrix DMX)
volume to a target volume on a qualified array with incremental
updates
Perform online data migrations from qualified storage to
Symmetrix VMAX (or Symmetrix DMX) with minimal disruption
to host applications
Definitions
The Symmetrix VMAX (or Symmetrix DMX), where Open Replicator
runs, and its devices are always referred to as the control side of the
copy operation. Other Symmetrix arrays, CLARiiON arrays, or
third-party arrays on the SAN are always referred to as the remote
array/devices. Open Replicator supports two types of copy
operations: push and pull. A push operation copies data from the
control device to the remote device. A pull operation copies data to the
control device from the remote device. Open Replicator has two modes
of operation: cold (offline) and hot (online). Online and offline refer to
the state of the Symmetrix VMAX (or Symmetrix DMX) resident
devices (control devices). For data consistency reasons, the remote
devices must never be written to by any host connected to the remote
array. In cases where the remote device is the source of the Open
Replicator copy operation (a pull operation), it may be permissible for
a remote host to have read-only access to the remote device.
Hot push
Open Replicator can push data volumes out from a Symmetrix-either
in a live mode (hot) or from a static copy or source volume (cold). For
a live push, no local point-in-time copies of the volumes are required.
The Symmetrix creates logical point-in-time copies without having to
Definitions 49
allocate additional disk space, and I/O is permitted against the
source volume during the transfer. If the application attempts a write
to a location whose original point-in-time data has not yet been
copied to the remote device, then Copy on First Write (COFW) applies,
delaying the host I/O until the data is safely on the remote. All FA
ports for the control devices must be configured (zoned and LUN
masked) to see the remote devices, so that the FA which encounters
the not-yet-copied data can perform the COFW itself. The initial hot
push must be a full copy, and often includes the option to save
differential information. The saved differential information is used
when the hot push is recreated and activated, pushing only
incremental changes since the previous activate. For data migration,
this type of full hot push followed by repeated incremental pushes
would be customary, with the final incremental push occurring while
the application is shut down, allowing the remote copy to be fully
up-to-date. Figure 2 illustrates an Open Replicator hot (or live) push.
Figure 2 Open Replicator hot (or live) push
To minimize the performance impact of COFW on production
applications, Open Replicator provides a precopy option. When the
precopy option is used, copying begins immediately at create or
recreate time and runs in the background without taking a point in
time image of the device. COFW is not invoked until the Open
Replicator session is activated, marking the point-in-time that must
be preserved. By copying most of the data before activation, COFW
will occur less frequently because in most cases the data will have
been copied to the remote before the first write.
Start: 6:00 a.m.
End: 6:15 a.m.
Image: 6:00 a.m.
Target STD
ICO-IMG-000434
Cold push
For cold push, the control devices must be presented as "not ready" to
the host. This ensures that there will be no need for the Symmetrix to
preserve the point-in-time or handle COFW. Rather than shutting
applications down to obtain a static point-in-time, it is customary to
use TimeFinder/Clone, TimeFinder/Mirror or TimeFinder/Snap to
make an incrementally updateable point-in-time copy of the
production data.
Note: Starting with Enginuity 5874, Solutions Enabler 7.0, and SMC 7.0, a
TimeFinder/Snap virtual device (VDEV) can be used as the incrementally
updatable TimeFinder/Snap point-in-time copy of the production volume
and the source of an Open Replicator cold push. Unlike the target devices
used to hold a TimeFinder/Clone or TimeFinder/Mirror copy, which must be
equal (or greater) in size than the corresponding production data devices,
VDEVs can be significantly smaller. (Best practice is for VDEVs to consume
less than 30 percent of the amount of space needed to store a full copy of the
production volumes.) The ability to only partially allocate space for the copy
of the production devices is another condition for when cold push might be
used in place of hot push for data migration.
The TimeFinder copy then serves as the control devices for the cold
push. After the Open Replicator cold push completes, the TimeFinder
copy is incrementally updated from the production copy, and the
Open Replicator session is recreated and activated pushing an
incremental update to the remote devices. For data migration, the
application would be shut down before the final TimeFinder
incremental establish (recreate and activate for TimeFinder/Snap),
followed by the final Open Replicator recreate and incremental
update to achieve a fully up-to-date remote copy.
Because there is no need for COFW and no concern for delaying
application writes, multiple remote device copies can be made from a
single control device, and not all FA ports for the control devices must
be configured (zoned and LUN masked) to see the remote devices. For
data mobility purposes, up to 16 remote copies of the local volume
can be made, and those remote copies can all be incrementally
updated. Figure 3 shows an Open Replicator cold (or BCV) push with
multiple targets.
Definitions 51
Figure 3 Open Replicator cold (or BCV) push
Cold push would be used in place of hot push for data migration for
the following conditions:
Distance to the remote storage array is greater than 200 km or the
COFW performance penalty is unacceptable to the production
application.
Open Replicator shared use of the bandwidth for all front-end FA
ports which the control devices are mapped to is unacceptable for
performance reasons.
There is sufficient storage available to create a BCV, Clone or
VDEV copy of the production devices.
Hot pull
In pull operations, the Symmetrix volume can be in a live state during
the copy process, which makes either restoring remotely vaulted
volumes or migrating from other storage platforms very fast and
efficient. Remember that for data consistency reasons, remote devices
must always be presented as write disabled to any host connected to
the remote array. Therefore production applications cannot run on
the remote array during the Open Replicator copy. However, with hot
pull, hosts and applications can begin to access the data on the
control array as soon as the session is activated, even before the data
copy process has completed. A process referred to as Copy on First
Access (COFA) is used to ensure the appropriate data is available to a
host operation when it is needed. All FA ports for the control devices
Target
STD
BCV
ICO-IMG-000435
PS0 PS1 PS2 PS3 PS4 SMB0 SMB1 SB0
SB1
SB2
SB3
SB4
SB5
SB6
SB7
SB8
SB9
SB10
SB11
SB12
SB13
SB14
SB15
Target
Target
must be configured (zoned and LUN masked) to see the remote
devices in order to immediately perform the COFA. Open Replicator
hot pull is a technology that supports Federated Live Migration
(FLM). Figure 4 illustrates an Open Replicator hot (or live) pull.
Figure 4 Open Replicator hot (or live) pull
Donor update Since production applications are writing to the local (control) copy,
there exists the potential for data loss due to a SAN failure or other
connectivity issue during a hot pull operation. Until the Open
Replicator copy is complete, some of the not yet copied data is only
on the remote while some of the newly written data is only available
locally on the control. The donor update option can be used to protect
against this potential for data loss. When enabled, the donor update
feature enables arrays to propagate (update) writes to the control
device back to the remote device (donor) as data is being pulled from
the remote device. When used, donor update ensures that the data on
the local (control) and remote devices are consistent. As a result, new
data written to the local (control) device will not be lost if an Open
Replicator session has to be restarted before completing. With donor
update enabled, data is first written to the target device, and then
propagated to the remote source device; the host I/O write completes
only if both writes are successful. Federated Live Migration (FLM)
sessions using Open Replicator hot pull always use donor update.
Zero Space
Reclamation
When the target (control device) of a pull operation is a virtually
provisioned (VP) device, zero space reclamation provides for
improved storage space allocation and capacity utilization. If the
incoming data is all zero and would cause an entire extent on the VP
STD
ICO-IMG-000436
SB1
SB2
SB3
SB4
SB5
SB6
SB7
SB8
SB9
SB10
SB11
SB12
SB13
SB14
SB15
PiT
Copy
PiT
Copy
STD
Definitions 53
device to be written with zeros, that extent will be de-allocated
instead of written with the data. Reclamation is a user selectable
option when creating Open Replicator copy sessions.
Cold pull
Of course, a pull can also be performed in cold mode to a static
Symmetrix VMAX (or Symmetrix DMX) volume. Because there is no
special software running on the remote array, there is no mechanism
to implement an incremental pull. Therefore, it is unlikely that cold
pull would be used for a data migration unless it is acceptable to have
the production applications shut down for the entire time it takes the
migration to complete. Figure 5 illustrates an Open Replicator cold
(or point-in-time) pull.
Figure 5 Open Replicator cold (or point-in-time) pull
Note: In the unlikely event that a cold pull is chosen to facilitate a given
migration activity, if infrastructure permits, consider running those sessions
as hot pulls to enable more choices to handle any issues that may arise
without compromising downtime objectives.
Open Replicator interaction rules with SRDF
Prior to Enginuity 5874 and Solutions Enabler 7.0, certain interactions
between Open Replicator and SRDF operations were blocked.
STD
Target
Target
ICO-IMG-000437
SB1
SB2
SB3
SB4
SB5
SB6
SB7
SB8
SB9
SB10
SB11
SB12
SB13
SB14
SB15
STD
STD
Target
The following SRDF operations are no longer blocked when an Open
Replicator control device is in the Created or Recreated state:
SRDF establish or resume when the R2 is an Open Replicator
control device
SRDF restore when the R1 is an Open Replicator control device
The following Open Replicator operation is no longer blocked when
the SRDF link is in the RW (Read Write or Ready) state:
Open Replicator pull operation
Basic Open Replicator migration operation flow 55
Basic Open Replicator migration operation flow
The basic operational flow for a migration using Open Replicator can
be divided into three main phases: setup, migration and cleanup.
This section will define 19 steps across all three phases. The migration
and cleanup phase steps will continue numbering from the phase that
precedes it, so that step numbers will be unique across the complete
operational flow, not just within a phase. Not every step is necessary
for any given migration. Steps are optional based on the particular
type of migration (e.g., cold push vs. hot push, or hot pull). The
decision point for optional steps is indicated by a parenthetical
phrase in the numbered step listing, or a decision diamond in the
flowchart representation. In chapters, 411, which detail specific
migration examples, optional steps that do not apply are omitted,
leaving gaps in the numbered step listings and grayed graphics in the
flowchart representations. Chapters 89 provide details specific to
using PPME with Open Replicator. Chapters 1011 provide details
specific to using FLM with Open Replicator.
Setup steps
There are up to six setup steps. They are:
1. Configure (provision) or identify the target devices.
2. Configure/connect migration SAN zones between remote
ports and Symmetrix VMAX (or Symmetrix DMX) control FA
"host" ports.
3. Configure LUN Masking for remote devices to allow access
from Symmetrix VMAX (or Symmetrix DMX) control FA
"host" ports.
4. Configure host zoning and device (LUN) masking for target
devices (only for hot pull migrations).
5. Prepare Open Replicator session pairs file (or define pairing in
SMC GUI).
6. Verify completion of setup steps up to creating the Open
Replicator session.
Figure 6 illustrates the setup steps as a flowchart.
Figure 6 Setup steps flowchart
Step 1 detail In a migration, the source devices must already exist, but that is not
the case for target devices. Therefore, the target devices of the
migration must be configured (provisioned) if they do not already
exist. For Open Replicator the target devices must be of the same or
greater size than the source devices. (Open Replicator actually will
migrate data from a larger source to a smaller target when the
-force_copy option is specified; this option is unlikely to be used
for a straight migration, but is particularly useful for restoring back to
an original smaller source from a larger target.)
Note: When the Open Replicator source device is a VDEV, the relationship
with the production device does not exist until the symsnap create
command is executed. Exactly when the symsnap create operation is
performed can vary, but it must occur before setup step 6, which includes the
symrcopy create command. A VDEV control device can participate in
only one Open Replicator session. Support for multi-virtual snap VDEV
devices as Open Replicator source devices begins with Enginuity 5875.
Step 2 detail Because the Symmetrix VMAX (or Symmetrix DMX) FA port will act
as an open systems host to the remote storage array, it is necessary to
set up one or more migration SAN zones for access to the remote
ports. This setup includes identifying the Symmetrix VMAX (or
Symmetrix DMX) control FA ports World Wide Names (WWNs). For
hot operations these WWNs must all be included in migration zone
sets, for cold operations the WWNs can be selectively included in
migration zone sets. It is also necessary to identify the remote storage
array WWN for access to the remote devices. The actual zone
definition operation can be completed with Connectrix Manager,
Ionix ControlCenter SAN Manager, or native switch zoning tools.
ICO-IMG-000529
Hot pull?
6. Verify setup
configuration, create
5. Define OR session
pairs (file)
3. LUN mask remote
devices to DMX FA
2. Zone DMX FA control
to remote array
1. Provision / identify
target devices
4. Zone and device mask
target devices to host
Y
N
Step 3 detail Because the Symmetrix VMAX (or Symmetrix DMX) FA "host" is
connected to the remote storage array on a switched fibre port, it is
necessary to perform LUN masking so that the Symmetrix VMAX (or
Symmetrix DMX) FA initiator is defined as having access to the
remote devices. This LUN masking is performed with tools specific to
the remote storage array. Commands for performing this operation for
a remote CLARiiON array are introduced in the next chapter, and
device (LUN) masking for a remote Symmetrix will be shown in
subsequent examples.
Step 4 detail For Symmetrix, device masking is the term used for LUN masking
(for Symmetrix VMAX arrays, the Auto-provisioning Groups feature
provides an easier, faster way to provision storage replacing the old
way of configuring device masking). Before a migration is complete it
is always necessary to ensure that the appropriate host applications
are able to access the target devices in place of the original source
devices. For hot pull migrations, this step is performed prior to
initiating the movement of data from the source (remote) to the target
(control).
Step 5 detail Open Replicator requires the definition of control-remote pairs;
multiple pairs are grouped into a single file in?order to be managed
together. There are three formats for specifying devices in this file:
device WWN, Symmetrix device name or CLARiiON device ID.
Device WWN can always be used for any device. The Symmetrix
device name format can always be used for the control device and in
some cases for the remote device. If the Solutions Enabler database has
discovered the remote Symmetrix or CLARiiON array, then the
Symmetrix or CLARiiON device format can be used for the remote
device. When using the SMC GUI, the process of selecting control and
remote devices is made easier with the ability to selectively filter a list
of available devices. The WWN format can easily be selected with a
click, avoiding the need to correctly enter the lengthy WWN strings.
Step 6 detail The final setup step is to use the defined control-remote pair file (or
GUI selection) to create the Open Replicator session. The create
operation validates all necessary control FA access to remote devices
and will fail if the pair definition, zoning or LUN masking is not
defined correctly. The create action can be considered part of the
setup phase because it does not begin migration data movement in
most cases (hot push operations that specify the -precopy option do
initiate migration data movement).
Note: In some cases, SCSI reservations for devices under cluster control or
the AIX operating system will prevent the create operation from being
successful. In this case alternate verification options can be used; more
information about these options is available in Setup step 6: Verify
completion of setup steps on page 80.
Note: The symrcopy create command is described to be the most
thorough test for verifying the completion of the Open Replicator setup
phase. The alternative methods of verifying the completion of the setup
phase (without running the symrcopy create action) are not sufficient
when using a VDEV control device. The specific order of operations requires
that the symrcopy create command is executed before the symsnap
activate command in migration step 7.
Migration steps
A single migration will use four to seven of the eight potential
migration steps. Note that step numbering continues at seven to
follow the last setup step. The migrations steps are:
7. Split the BCV or activate the clone or VDEV
(optional for cold push migrations from a BCV, clone or
VDEV).
8. Move all resources to a single cluster node, and create the
Open Replicator session
(only needed if the session was not created during setup and
not terminated as part of step 7).
9. Stop the application (only for pull migrations).
10. Activate the Open Replicator session.
11. Restart the application pointing to the target (control) devices,
(only for hot pull migrations).
12. Tune migration to an acceptable level of impact on production
application (optional).
13. Verify Open Replicator copy session is finished.
14. Iteratively apply incremental updates
(customary for push migrations).
a. Use TimeFinder to incrementally update the control
devices (only for cold push).
b. Recreate and activate the Open Replicator session to
incrementally update the remote.
c. Repeat steps 14a14b until all updates have been
processed, shut down the application before the last
update in step 14a, so there will be no changes generated
during the final incremental push.
15. Verify migration is complete and terminate Open Replicator
session.
Figure 7 on page 60 illustrates the migration steps as a flowchart.
Figure 7 Migration steps flowchart
ICO-IMG-000530a
12. Tune OR to acceptable
impact level
8. Move resources to single
cluster, create
9. Stop the application
15. Verify migration
terminate OR
14b. OR recreate and
activate
14a. TimeFinder
incremental update
14c. Stop the application
13. Verify OR copy
done
Last update?
Cold push?
Need tuning?
11. Restart application using
target devices
7. Split the BCV
or activate the clone or VDEV
10. OR activate
Pull?
Hot pull?
Push?
Create not run?
Cold push
from BCV, clone
or VDEV?
Application
still running?
Y
Y
Y
Y
Y
Y
Y
Y
Y
N
N
N
N
N
N
N
N
N
Steps 7 through 15
detail
Steps 7 through 15 consist of the following:
Step 7, initialize the BCV, clone or VDEV control device with a
point-in-time copy of the production device, is necessary when
the control device is a BCV, clone, or VDEV device. Step 7 must
precede step 8 when the control device is a TimeFinder/Mirror
BCV, because the split operation makes the BCV an
independent device.
Note: The symsnap and symrcopy commands needed to support cold push
from a VDEV device must be performed in a specific order. The general rule
is that the parallel symsnap action (create, activate, or recreate) must
precede the same symrcopy operation. The symsnap activate
-not_ready command sets the TimeFinder/Snap point-in-time and must
precede migration step 10. The -not_ready option is used to keep the
VDEV in the Not Ready state, which is required while the Open Replicator
session is present.
Step 8, create the Open Replicator session, is needed if the
create is postponed from the setup phase or if TimeFinder
operations in step 7 require that the Open Replicator session is
not in the created state.
Step 9, stop the applications, is necessary for pull operations
because the remote source data must not be changed once the pull
migration session is activated.
Step 10, activate the Open Replicator session, is the key migration
phase step, setting the point-in-time for the migration copy.
Step 11, restart the application pointing to the target devices is
part of the migration phase only for hot pull migrations; for all
other migrations the restart is completed as part of the cleanup
phase.
Step 12, tune the migration, is optional; it is available to adjust the
migration impact on production applications as needed.
Step 13, wait and monitor for completion of the migration copy, is
most likely the step that will take the longest time.
Step 14, iteratively applying incremental updates, is necessary for
push migrations to propagate production application changes to
the target (remote) until production application changes cease
when the applications are stopped.
When using a VDEV control device, step 14a, the TimeFinder
incremental update, cannot activate the recreated
TimeFinder/Snap session before the Open Replicator session is
first recreated. Similarly, the symrcopy activate in step 14b
cannot precede the symsnap activate (which again includes
the -not_ready option to keep the VDEV in the Not Ready
state). Therefore when using TimeFinder/Snap the order of
operations for steps 14a-14b must be:
1. symsnap recreate
2. symrcopy recreate
3. symsnap activate -not_ready
4. symrcopy activate
Step 15, terminate the Open Replicator session, is completed
once the migration is verified because data migration is the one
time movement of data from source to target so the session is no
longer needed. The symrcopy terminate command must
precede any symsnap terminate commands.
Tuning Open Replicator Typically there are two conflicting
performance goals for a data migration. First, it is necessary for the
migration to complete within the planned for migration window.
Second, the data migration should not cause unacceptable levels of
performance degradation for production applications. Open
Replicator shares the processing power of the front-end fibre (FA)
director and the bandwidth of the fibre path with the production
applications. Open Replicator provides three alternatives for tuning
Open Replicator performance: the ceiling parameter which limits fibre
bandwidth that can be used by Open Replicator, the pace parameter
which defines delays added between Open Replicator operations,
and the nocopy mode which suspends Open Replicator copy activity.
The primary tuning mechanism is the Open Replicator ceiling
parameter. Ceiling is set to the maximum percentage of the fibre
bandwidth that can be used by Open Replicator. By default this value
is not set, theoretically allowing Open Replicator to use up to 100
percent of the bandwidth. The secondary tuning mechanism is the
pace parameter. Pace is a value set between 0 and 10 (default 5), which
translates to a position in a table that adds a delay between Open
Replicator I/O transfers. The larger the pace value, the longer the
delay.
Another method of tuning is setting the mode to nocopy, which will
effectively stop all Open Replicator I/O except for copy operations
required when in hot mode to preserve the point-in-time (copy on
first write for hot push, and copy on first access for hot pull). This
method is most likely used in special circumstances when it is
necessary to limit nonproduction I/Os as much as possible. It will be
necessary to set the mode back to copy for the copy session to
complete the migration.
Ceiling is considered the best tuning mechanism because it delivers
fixed, accurate, repeatable results that can be based on observed and
calculated values. Pace values greater than zero will always add Open
Replicator processing delays, even when Open Replicator I/Os
would not get in the way of production applications. The PPME
throttle mechanism is an alternate interface to the Open Replicator
pace parameter. The pace value is ignored for all participating
director/port combinations where the ceiling value is not NONE,
including PPME and FLM Open Replicator sessions.
Cleanup steps
Figure 8 illustrates the following cleanup steps in a flowchart:
16. Make the source devices inaccessible to the host
(needed for all but hot pull operations).
17. Make the target devices ready to the host
(needed for all but hot pull operations).
18. Restart applications pointing to the target devices in place of
the original source devices (needed for all but hot pull
operations).
19. Redeploy the source devices storage now that the migration is
complete.
Figure 8 Cleanup steps flowchart
Step 18, restart production applications to reference the target
devices, is the main task in the cleanup phase.
Steps 16 and 17 prepare for this step by removing the source devices
in step 16 and adding the target devices as host visible devices in step
17. In the case of hot pull steps 1618 are skipped because the
production applications were restarted using the target devices in the
migration phase.
ICO-IMG-000531
19. Redeploy source devices
storage
18. Restart applications using
target devices
17. Make target devices ready
to host
16. Make source devices
inaccessible to host
Hot pull?
Y
N
Monitoring, troubleshooting and recovery 65
Note the use of the term target devices which would usually mean the
remote devices in the case of a hot or cold push, or in the unusual case
of using cold pull for a data migration it would mean the control
devices. Step 19, redeploys the source devices storage, which is now
free for new uses.
These steps are identified as being in the cleanup phase because
Open Replicator actions ended with the termination of the session in
the migration phase. PowerPath Migration Enabler (PPME) includes
alternate commands to achieve the outcomes of step 11 and steps
1518 for hot pull operations under PPME control. These alternate
commands provide the PPME advantages of greatly reducing or
eliminating application disruptions due to these steps, reducing
migration risk, and simplifying migration operations.
Note: Chapter 8, PowerPath Migration Enabler Overview, introduces a
more comprehensive and reordered description of these alternate cleanup
steps.
Monitoring, troubleshooting and recovery
Best practices for monitoring, troubleshooting and recovery will be
shown in the examples detailed in the following chapters. The range
of tools available will first be introduced here. When using Open
Replicator the vast majority of problems encountered result from
errors in setting up the initial zoning and LUN masking. This chapter
introduced the Open Replicator create action as an effective tool to
verify complete setup.
Chapter 4, Cold Push to CLARiiON Setup Example, will go into
additional detail for interpreting setup errors reported by create
and alternatives to create for verifying correct setup. Once a
migration is started, there are basic tools for monitoring the copy
session progress. The query action will list the status of the control
and remote pairs and the progress of the copy sessions. The verify
action can be used to determine if an expected status exists, and the
interval and count options can be set up to loop until the desired
state is achieved. The return code from verify operations can be
used effectively within a script to branch based on the status of the
copy sessions. Besides 100 percent completion of a copy operation,
the other important status to deal with is a failed copy operation.
Recovery from a failed operation is generally dealt with by simply
restarting the copy operation and taking a new point-in-time. In the
case of hot pull, a new point-in-time would only be valid on the
remote, provided the -donor_update option was used.
Appendix B, Troubleshooting, provides log information that
correlates with the examples presented in Chapters 4 through 9, and
an example of reactivating a failed differential push session.
Control interface alternatives 67
Control interface alternatives
There are three different interfaces available to control EMC Open
Replicator for Symmetrix: the Solutions Enabler Command Line
Interface (SYMCLI), the Symmetrix Management Console (SMC)
Graphical User Interface (GUI), and the PowerPath Migration
Enabler (PPME) CLI.
Solutions Enabler CLI
The Solutions Enabler Command Line Interface (SYMCLI) supports
EMC Open Replicator for Symmetrix operations with the symrcopy
command. The symsan command, which lists ports visible from a
given director port and LUNs visible behind a given remote port, is
particularly helpful for verifying that zoning and LUN masking has
been correctly configured for Open Replicator operations.
Configuration of devices, mapping, and masking is also supported
by the symconfigure, symmask and symmaskdb commands.
Output available from symdev, sympd, and symcfg commands may
also be helpful in manually verifying key Open Replicator related
information.
Symmetrix Management Console GUI
The Symmetrix Management Console (SMC) Graphical User
Interface (GUI) supports EMC Open Replicator for Symmetrix
operations with the Open Replicator create and session control
wizards. The create wizard gets invoked from the control menu for
the local Symmetrix array. This five-page wizard progressively
moves the user through the process of specifying all of the
information needed to create an Open Replicator session:
1. Set session parameters
2. Select control devices
3. Select remote devices
4. Select device pairs
5. Set create options, and execute
If device pairs definitions are available from a previously saved file,
the wizard jumps from page 1 to page 5. Once created, Open
Replicator session control is available from the Control, Replication
menu. SMC also supports Remote Report, which like symsan lists
ports visible from a given director and LUNs visible behind a given
remote port.
PowerPath Migration Enabler CLI
The PowerPath Migration Enabler (PPME) CLI supports EMC Open
Replicator for Symmetrix operations with the powermig command.
Since Open Replicator will be used as the underlying technology for
the migration, setup steps 1-4 are conducted in the same way as listed
in Setup steps on page 55. The powermig command has its own
setup action to configure the source and target pair devices. The
Open Replicator hot pull operation is then initiated by the powermig
sync command. The rest of the powermig actions are used to
monitor progress until completion of the synchronization, and then
to conduct application cutover to the target devices. These cutover
steps go beyond the scope of the migration data movement steps
available in Solutions Enabler and SMC. Without PPME, cutover
steps need to be conducted in host and application specific ways.
Reference information
Specific details of the Solutions Enabler Open Replicator commands
can be found in the Solutions Enabler Symmetrix Open Replicator CLI
Product Guide. This TechBook includes all migration-related features
available in Open Replicator at the time of publication; not all of these
actions or options are available in earlier code releases. The EMC
Solutions Enabler Symmetrix Open Replicator CLI Product Guide and the
EMC Solutions Enabler Release Notes provide details about feature
availability.
Specific details of the Symmetrix Management Console Open
Replicator screens can be found in the online help within the product.
An example of special considerations for necessary steps dealing
with clustered hosts can be found in the Migrating Microsoft Cluster
Server using EMC Open Replicator for Symmetrix Technical Note.
Cold Push to CLARiiON Setup Example 69
4
This chapter provides an operational example of the setup phase.
Together with Chapter 5, Cold Push to CLARiiON Migration
Example, a complete example of all the steps needed to execute a
cold push using SYMCLI on a Solaris host is provided. Alternate
examples for verifying successful completion of the setup step is
presented. The topics covered include:
Introduction ........................................................................................ 70
Setup step 1: Identify target devices................................................ 71
Setup step 2: Configure migration SAN zones.............................. 73
Setup step 3: Configure migration LUN masking......................... 78
Setup step 5: Prepare Open Replicator session pairs.................... 79
Setup step 6: Verify completion of setup steps .............................. 80
Cold Push to CLARiiON
Setup Example
Cold Push to CLARiiON Setup Example
Introduction
This chapter details the setup steps for a cold push to a CLARiiON
using Solutions Enabler SYMCLI on a Solaris host. Because step 4 of
the setup steps introduced in chapter 3 is only completed for hot pull
migrations, it is omitted from the listing of numbered steps below:
1. Configure (provision) or identify the target devices
2. Configure/connect migration SAN zone between remote
devices and Symmetrix VMAX (or Symmetrix DMX) control
FA "host" ports.
"host" ports.
SMC GUI).
Replicator session.
Setup step 1: Identify target devices 71
Setup step 1: Identify target devices
As mentioned in Step 1 detail on page 56, the target devices of the
migration must be configured (provisioned) if they do not already
exist. For Symmetrix arrays, the Solutions Enabler symconfigure
command, SMC's Device Configuration screens or Ionix
ControlCenter Symmetrix Manager can be used to configure target
devices of an equal or greater size than the source devices. For all
remote devices it is necessary to know the device world wide name
(WWN). However, if the remote Symmetrix or CLARiiON device has
been discovered and is in the Solutions Enabler database file, then the
Symmetrix or CLARiiON array ID and device number ("name") can
be used in place of the WWN. Open Replicator will use the array
specific identification to obtain the WWN from the database file. This
is generally easier to use than dealing with lengthy WWN strings.
In order to discover a CLARiiON, the symcfg authorization
command must first be used to associate a CLARiiON storage
processor IP address with a username and password. The discover
operation requires either the -clariion option to discover only
CLARiiON arrays, or the -all option to discover both Symmetrix
and CLARiiON arrays. Once discovered, information about the
CLARiiON devices can be displayed using the -clariion option.
An example is given on page 72.
# symcfg authorization add -hostname nnn.nnn.nnn.nnn -username name -password password
# symcfg discover -all
This operation may take up to a few minutes. Please be patient...
# symcfg list -clariion
C L A R I I O N
Firmware Num Num Phys Num Clar
ClarID Model Version Disks Devices Devices
HK190807410004 CX3_40_F 3.24.40.5.014 15 4 10
# symdev list -clariion
Clariion ID: HK190807410004
Device Device
---- ----------------------------------- ----------------------------------------------
Num Physical Name Config Cap(MB) WWN
---------------------------------------------------------------------------------------
00000 Not Visible Raid-5 4096 600601602b401e00148f6936d93bdd11
00006 Not Visible Raid-5 4096 600601602b401e001a8f6936d93bdd11
00007 Not Visible Raid-5 4096 600601602b401e001b8f6936d93bdd11
00008 Not Visible Raid-5 4096 600601602b401e00bae08e938a47dd11
00009 /dev/rdsk/emcpower3c Raid-5 4096 600601602b401e001078c2a48a47dd11
#
If the remote array is not a CLARiiON or a Symmetrix, or not in the
database, then it is necessary to use the WWN. The Solutions Enabler
syminq command and the similar inq command can be used to
display WWN information for Symmetrix, CLARiiON and
third-party arrays. For example:
# syminq -clariion -cids -wwn
Device Device
--------------------------------- ------------------- ---------------------------------
Name Num Array ID WWN
--------------------------------- ------------------- ---------------------------------
/dev/rdsk/c2t5006016A41E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11
/dev/rdsk/c2t5006016241E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11
/dev/rdsk/emcpower3c 0009 HK190807410004 600601602B401E001078C2A48A47DD11
/dev/vx/rdmp/emcpower3s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11
#
Setup step 2: Configure migration SAN zones 73
Setup step 2: Configure migration SAN zones
As the Symmetrix VMAX (or Symmetrix DMX) FA port will act as an
open systems host to the remote storage array, it is necessary to set up
one or more migration SAN zones for access to the remote devices.
Therefore, both the local (control) director WWN(s) and the remote
front-end WWN(s) must be determined.
Determining Control Director WWN
The control is always a Symmetrix device, so Solutions Enabler, SMC
or Ionix ControlCenter can be used. First it must be determined on
which directors the control devices are visible. The Solutions Enabler
symdev list -multiport command is one of the easiest ways to
obtain this information. In the following example, the four control
devices: 80, 81, 82 and 83, are all mapped to both director 2C port 0
and director 15C port 0.
# symdev -sid 359 list -range 80:83 -multiport
Symmetrix ID: 000190300359
M U L T I - P O R T D E V I C E S
Device Name Directors Device
-------------------------------- ------------- ---------------------------------------
Cap
Physical Sym SA :P DA :IT Config Attribute Sts (MB)
-------------------------------- ------------- ---------------------------------------
0080 01A:C6 2-Way BCV Mir N/Asst'd RW 4096
Not Visible - 02C:0 - - - - -
Not Visible - 15C:0 - - - - -
0081 16B:C6 2-Way BCV Mir N/Asst'd RW 4096
Not Visible - 02C:0 - - - - -
Not Visible - 15C:0 - - - - -
0082 16A:DC 2-Way BCV Mir N/Asst'd RW 4096
Not Visible - 02C:0 - - - - -
Not Visible - 15C:0 - - - - -
0083 15B:C7 2-Way BCV Mir N/Asst'd RW 4096
Not Visible - 02C:0 - - - - -
Not Visible - 15C:0 - - - - -
#
Note that the -multiport option will only list devices with more
than one path. If there is only a single path, then symdev list
should be used without the -multiport option.
The FA director port world wide port name (WWPN or WWN) can be
displayed using the symcfg list command. For example:
# symcfg -sid 359 list -fa 2c -p 0
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 VCM Volume Set Pnt to Pnt
Enabled Addressing
FA-2C 0 5006048AD5F031C1 Yes No Yes
# symcfg -sid 359 list -fa 15c -p 0
Enabled Addressing
FA-15C 0 5006048AD5F031CE Yes No Yes
Determining Remote Storage Array WWN(s)
The remote storage array can be a Symmetrix, a CLARiiON or a
third-party array. For a remote Symmetrix array the procedure for
determining the WWPN for the remote FA director is the same as the
one used to obtain the WWPN for the local director on a Symmetrix.
For a remote CLARiiON array, the Navisphere GUI can be used to
determine the Storage Processor(SP) WWPNs. CLARiiON LUN
masking is accomplished using storage groups, where all devices in
the same Storage Group are defined to be accessible to all hosts in the
Storage Group. Figure 9 illustrates right clicking on the host in the
Storage Group containing the remote devices (LUNs) in order to select
the Connectivity Status for that host.
Figure 9 Invoking Connectivity Status for Host in a Storage Group
Figure 10 on page 76 shows that four paths between the CLARiiON
and host LICOD229 can be used to access LUNs 4, 5, 6 and 7.
However, the CLARiiON LUNs are owned by only one SP at one
time. For fault tolerance, a LUN can trespass over to the other SP;
therefore it is necessary to define paths for the currently passive SP as
well.
ICO-IMG-000532
Figure 10 Host connectivity status for a CLARiiON storage group.
Figure 11 shows all of the Front End Port WWPNs, with ports 0 and 2
highlighted for both SPA and SPB.
Figure 11 CLARiiON CX3-40f Storage Processor World Wide Port Names
For a remote third-party array, it is necessary to use tools specific to
the array to determine the WWPNs to use in the zoning.
ICO-IMG-000533
ICO-IMG-000534
Selective or all Symmetrix FA Zoning
For cold operations it is not necessary to zone all possible paths. This
allows the user to limit migration movement to selective paths. For
hot operations it is required that all Symmetrix FA ports that are
mapped by the control devices be zoned and LUN masked to "see"
the remote devices.
Example configuration of migration SAN zones
In this example, only a single active path and the minimum zoning
necessary for a cold operation is illustrated. Two paths must be
configured for this case, since the remote is a CLARiiON storage array;
the second path is needed to handle the condition of the remote LUN
trespassing from one SP to the other SP. Figure 12 shows an excerpt of
the Connectrix Manager Zoning verification screen with the single
path and standby path zones defined.
Figure 12 Connectrix Manager activate zone verification screen
ICO-IMG-000535
Setup step 3: Configure migration LUN masking
Create CLARiiON storage group
Because the Symmetrix VMAX (or Symmetrix DMX) FA "host" is
connected to the remote storage array on a switched fibre port, it is
necessary to perform LUN masking to grant the Symmetrix VMAX
(or Symmetrix DMX) FA initiator access to the remote devices. This
LUN masking is performed with tools specific to the remote storage
array. Here, an example of Storage Group based LUN masking for the
CLARiiON using navicli is presented.
The default location of Navisphere executables on UNIX operating
systems is /opt/Navisphere/bin. The network hostname for the
CLARiiON SPA IP address is Clar0031_SPA. First, the Storage
Group OR_Symm359 is created by executing a command that looks
something like this:
# cd /opt/Navisphere/bin
# ./navicli -h Clar0031_SPA storagegroup -create -gname OR_Symm359
Register host and add devices to CLARiiON storage group
Next, the Symmetrix FA "host" is manually registered for both the
SPB port 0 and SPA port 0 in the storage group. Then the four remote
devices are added to the storage group. For each CLARiiON LUN
device number (-alu), the LUN number presented to the host (-hlu)
is defined.
# ./navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A:D
5:F0:31:C1:50:06:04:8A:D5:F0:31:C1 -sp b -spport 0 -host Sym0359 -failovermode 1 -o -unit
serialnumber array
# ./navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A:D
5:F0:31:C1:50:06:04:8A:D5:F0:31:C1 -sp a -spport 0 -host Sym0359 -failovermode 1 -o -unit
serialnumber array
# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname OR_Symm359 -alu 04 -hlu 00
Setup step 5: Prepare Open Replicator session pairs 79
Setup step 5: Prepare Open Replicator session pairs
Open Replicator requires the definition of control-remote pairs.
Multiple pairs grouped into a single file can be managed together by
Open Replicator. The control device is identified in the first (leftmost)
column and the remote device is identified in the second (rightmost)
column.
The array ID must be fully specified and is separated from the
device/LUN name (number) by a colon. Since the CLARiiON was
discovered into the SYMAPI database file (Setup step 1: Identify
target devices on page 71), the clardev= format can be used for the
remote devices in the file:
# cat cold_orpairs
symdev=000190300359:0080 clardev=HK190807410004:00004
#
Setup step 6: Verify completion of setup steps
Create action is a thorough verification step
The most thorough test for verifying the completion of the setup
steps is to create the Open Replicator session. The create
operation verifies all necessary control FA access to the remote
devices and will fail if the pair definition, zoning or LUN masking is
not correctly defined. Create does not begin the migration itself,
except in the case when the -precopy option is specified for hot
push operations. In some cases, SCSI reservations for devices under
cluster control will prevent the create operation from being
successful. In these cases alternate verification options, presented
next, can be used in place of the create.
Note: When the Open Replicator source device is a VDEV, the relationship
with the production device does not exist until the symsnap create
command is executed. Exactly when the symsnap create operation is
performed can vary, but it must occur before setup step 6, which includes the
symrcopy create command.
Verify zoning with symsan -sanports
Solutions Enabler 6.4 with Enginuity 5772 introduced the symsan
command, which was designed explicitly for verifying the correct
Open Replicator zoning and masking. The zone
OR_Symm0359_2C0_Clar0031_SPB_0 created in the Example
configuration of migration SAN zones on page 77 included the
WWN for Symmetrix FA director 2C port 0, and the WWN for
CLARiiON SP B port 0. The zone
OR_Symm0359_2C0_Clar0031_SPA_0 included the same
Symmetrix FA WWN with the CLARiiON SP A port 0, in case of LUN
trespass from SP B to SP A. The symsan -sanports command lists
the WWNs that are zoned together with the specified Open
Replicator FA port. The Remote Port WWN 5006016841E087E6 is
the SP B port 0 WWN. The Remote Port WWN 5006016041E087E6
is the SP A port 0 WWN. The symsan output also identifies the array
as a CLARiiON, including the array ID and also the number of LUNs
visible behind each WWN. A greater than zero Num LUNs value
Setup step 6: Verify completion of setup steps 81
indicates the number of LUNs that are successfully LUN masked.
Since four LUNs were expected this could be interpreted as
successful remote LUN masking. For example:
# symsan -sid 359 list -sanports -dir 2c -p 0
Flags Num
DIR:P I Vendor Array LUNs Remote Port WWN
----- ----- ------------- ---------------- ---- -------------------------------
02C:0 . EMC CLARiiON HK190807410004 4 5006016841E087E6
Legend:
Flags: (I)ncomplete : X = record is incomplete, . = record is complete.
Verify LUN masking with symsan -sanluns
In order to be certain that the correct LUNs are masked, the
symsan -sanluns command can be used to list the LUN WWNs
behind the Remote Port WWN. In the output produced by this
command, the Dev Num (Device Number) column indicates the
CLARiiON device number. Additionally each record can be checked
for the correct device Capacity.
# symsan -sid 359 list -sanluns -wwn 5006016841E087E6 -dir 2c -p 0
Remote Port WWN: 5006016841E087E6
ST
A
T Flags Block Capacity LUN Dev LUN
DIR:P E ICRTHS Size (MB) Num Num WWN
----- -- ------- ----- ----------- ----- ----- --------------------------------
02C:0 RW ...... 512 4096 0 0004 600601602B401E00188F6936D93BDD11
02C:0 RW ...... 512 4096 1 0005 600601602B401E00198F6936D93BDD11
02C:0 RW ...... 512 4096 2 0006 600601602B401E001A8F6936D93BDD11
02C:0 RW ...... 512 4096 3 0007 600601602B401E001B8F6936D93BDD11
Legend:
(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)ymmetrix : X = Symmetrix device, . = not Symmetrix device
Note: Beginning with Solutions Enabler 7.0, the symsan command added
two flags to indicate thin device and Symmetrix device. The indicator is
helpful if running with a release before Enginuity 5875 which added support
for virtual provisioned (thin) devices to be source devices for Open
Replicator. Open Replicator pull support for iSeries requires the remote
device to be on a Symmetrix array.
Verify zoning with symmask list logins
If the Solutions Enabler version is less than 6.4.2 or the Symmetrix
Enginuity level is less than 5772.83, the symsan command is not
available. In this case, the symmask list logins command can be
used to determine if the zoning was successful. At the time of
activating the zone including the OR FA port "host," all participants
in the zone should log on to the SAN fabric. The display below shows
WWN Identifiers On Fabric, but not Logged In with the standard
CLARiiON prefix 500601 (Logged In will change to Yes after an
Open Replicator activate action). The full WWN match the WWN
for SPA port 0 and SP B port 0. For example:
# symmask -sid 359 list logins -dir 2c -p 0
Symmetrix ID : 000190300359
Director Identification : FA-2C
Director Port : 0
User-generated Logged On
Identifier Type Node Name Port Name FCID In Fabric
---------------- ----- --------------------------------- ------ ------ ------
10000000c97111fc Fibre 10000000c97111fc 10000000c97111fc 6b0900 Yes Yes
5006016041e087e6 Fibre NULL NULL 6167ef No Yes
5006016841e087e6 Fibre NULL NULL 6177ef No Yes
210000e08b927df4 Fibre 210000e08b927df4 210000e08b927df4 610613 Yes Yes
One important caveat about using the list logins command is
that the reported state is not necessarily current. The key is the first
appearance of the WWN. However once on fabric, the information
remains on the list logins output regardless of whether the WWN is
currently On Fabric. For Symmetrix VMAX, symaccess list
logins would be used in place of symmask.
Verify all with symrcopy create
Unless working in a special case dealing with device reservations
(e.g., windows clustering) or not wanting to begin a hot push which
includes the -precopy option, it is wise to fully test the setup by
creating the Open Replicator session.
Note: When the Open Replicator source device is a VDEV, the specific order
of operations requires that the symrcopy create command is executed
before the symsnap activate command in migration step 7. The symsnap
create operation creates the relationship with the production device and
must be executed before the symrcopy create command.
Using the cold_orpairs file from Setup step 5: Prepare Open
Replicator session pairs on page 79 the cold push is created as
follows:
# symrcopy -file cold_orpairs -push -cold create
'Create' operation execution is in progress for the device list
in device file 'cold_orpairs'. Please wait...
The device is not in a valid Ready status. Operation cannot proceed
As mentioned when first defining Cold push on page 50, cold
operations require the control devices to be in the Not Ready state.
This can be verified as follows:
# cat cold_controldevs
80
81
82
83
# symdev -sid 359 -file cold_controldevs not_ready
Execute a 'Not Ready' operation for devices in file 'cold_controldevs' (y/[n]) ? y
'Not Ready' operation succeeded for devices in file 'cold_controldevs'.
# symrcopy -file cold_orpairs -push -cold create
Execute 'Create' operation for the 4 specified devices
in device file 'cold_orpairs' (y/[n]) ? y
'Create' operation successfully executed for the device list
in device file 'cold_orpairs'.
#
The successful execution of the create operation confirms that all
necessary zoning and LUN masking is correctly in place.
SMC Remote Report
The Symmetrix Management Console provides a GUI equivalent to
symsan. Figure 13 illustrates invoking the Remote Report menu from
an initial right click of the control Symmetrix array, and choosing
ReplicationOpen ReplicatorRemote Report.
Figure 13 SMC Remote Report menu selection
ICO-IMG-000536
Remote Report has two tabs. Figure 14 illustrates the Remote Ports
tab showing information similar to the symsan -sanports display
for director 2C port 0.
Figure 14 SMC Remote Report Remote Ports
Clicking on the Remote Luns tab and selecting director 2C
automatically selects the first WWN displayed in the Remote Ports
display. Figure 15 illustrates the Remote Luns tab display:
Figure 15 SMC Remote Report Remote LUNs display
ICO-IMG-000537
ICO-IMG-000538
Additionally, the GUI selection of remote devices populates the
available list with the successfully mapped remote devices. Figure 16
illustrates page 3 of the Create Copy Session wizard where the
available remote devices are populated from the Remote Report
information.
Figure 16 Create Page 3 showing CLARiiON Available Remote Devices
ICO-IMG-000539
Cold Push to CLARiiON Migration Example 89
5
This chapter details the migration and cleanup phases for a cold push
migration example using Solutions Enabler SYMCLI on a Solaris
host. The setup phase steps were already covered in Chapter 4, Cold
Push to CLARiiON Setup Example. The topics covered include:
Introduction ........................................................................................ 90
Migration step 7: BCV split............................................................... 93
Migration step 8: symrcopy create .................................................. 98
Migration step 10: symrcopy activate ........................................... 102
Migration step 12: symrcopy set ceiling ....................................... 103
Migration step 13: symrcopy query and verify ........................... 105
Migration step 14: Iterative symrcopy recreate ........................... 106
Migration step 15: Verify migration and symrcopy terminate.. 110
Cleanup step 16: Make source devices host inaccessible ........... 112
Cleanup step 17: Make target devices ready to host................... 113
Cleanup step 18: Restart applications using targets ................... 114
Cleanup step 19: Redeploy the source devices storage............. 116
Cold Push to CLARiiON
Migration Example
Cold Push to CLARiiON Migration Example
Introduction
This chapter details the migration and cleanup phases for a cold push
migration example using Solutions Enabler SYMCLI on a Solaris
host. The five setup steps required for the cold push were covered in
Chapter 4, Cold Push to CLARiiON Setup Example. This chapter
contains detailed examples of the seven migration steps introduced
in Migration steps on page 59 that are applicable for a cold push
(steps 9 and 11 only completed for pull migrations are omitted):
7. Split the BCV or activate the clone or VDEV.
8. Open Replicator session create.
12. Tune migration to acceptable level of impact on production
application.
14. Iteratively apply incremental updates.
a. Use TimeFinder to incrementally update the control
devices (only for cold push).
b. Recreate and activate the Open Replicator session to
incrementally update the remote.
c. Repeat steps 14a14b until all updates have been
processed, shut down the application before the last
update in step 14a to eliminate changes during the final
incremental push.
15. Terminate Open Replicator session.
Also briefly covered will be the four applicable cleanup steps:
16. Make the source devices inaccessible to the host.
17. Make the target devices ready to the host.
18. Restart the application pointing to the target devices in place
of the original source devices.
complete.
Introduction 91
Figure 17 on page 92 illustrates the cold push migration and cleanup
steps in a flowchart. The paths from decision diamonds which is not
taken and omitted steps are grayed to show they are not conducted
for this cold push example. The step 14 detail, which includes three
substeps (ac) and related decision diamonds, shows all paths and
steps without graying, because each path and step is performed at
least once.
Figure 17 Cold push migration and cleanup flowchart
ICO-IMG-000540a
storage
target devices
17. Make target devices ready
to host
impact level
cluster, create
16. Make source devices
inaccessible
terminate OR
14b. OR recreate and
activate
14a. TimeFinder
incremental update
14c. Stop the application
13. Verify OR copy
done
Hot pull?
Last update?
Cold push?
Need tuning?
target devices
10. OR activate
Pull?
Hot pull?
Push?
Create not run?
Application
still running?
Y
Y
Y
Y
Y
Y
Y
Y
Y
N
N
N
N
N
N
N
N
N
N
7. Split the BCV
Cold push
from BCV, clone
or VDEV?
Y
Migration step 7: BCV split 93
Migration step 7: BCV split
Device Group creation
For a cold push, it is common to use a TimeFinder/Mirror BCV,
TimeFinder/Clone BCV or target device, or TimeFinder/Snap VDEV
as the control device; this example will use a TimeFinder/Mirror BCV
device. For this example the application uses the file system at mount
point /cphome, a VxVM logical volume made up of 4 Symmetrix
devices: A0A3.
# mount
. . .
/cphome on /dev/vx/dsk/cpvg/cplv read/write/setuid/devices/delaylog/largefiles/i
oerror=mwdisable/dev=48c80e8 on Mon Jun 30 17:39:47 2008
. . .
The mount command showed /cphome as a VxVM logical volume
cplv, which is part of the volume group cpvg.
# vxprint -g cpvg -ht
DG NAME NCONFIG NLOG MINORS GROUP-ID
ST NAME STATE DM_CNT SPARE_CNT APPVOL_CNT
DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE
RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL
RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK
CO NAME CACHEVOL KSTATE STATE
VT NAME NVOLUME KSTATE STATE
V NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL PREFPLEX UTYPE
PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE
SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE
SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE
SC NAME PLEX CACHE DISKOFFS LENGTH [COL/]OFF DEVICE MODE
DC NAME PARENTVOL LOGVOL
SP NAME SNAPVOL DCO
dg cpvg default default 33000 1214852481.33.licod229
dm cpvgd0 emcpower380s2 auto 2048 8382336 -
v cplv - ENABLED ACTIVE 33529344 SELECT - fsgen
pl cplv-01 cplv ENABLED ACTIVE 33529344 CONCAT - RW
sd cpvgd0-01 cplv-01 cpvgd0 0 8382336 0 emcpower380 ENA
The vxprint command for cpvg showed that the four devices that
make up the volume group cpvg use pseudo device names
emcpower380s2 emcpower383s2.
# sympd list -sid 359 -powerpath
P O W E R P A T H D E V I C E S
Device Name Directors
Device
------------------------------------- -------------------------------------------------
Cap
------------------------------------- ------------ ------------------------------------
. . .
/dev/vx/rdmp/emcpower380s2 00A0 02A:C9 2-Way Mir Grp'd RW 4096
/dev/rdsk/emcpower380c - 15C:0 - - - - -
/dev/rdsk/c4t5006048AD5F031C1d144s2 - 02C:0 - - - - -
/dev/rdsk/c2t5006048AD5F031CEd144s2 - 15C:0 - - - - -
/dev/vx/rdmp/emcpower381s2 00A1 15B:DA 2-Way Mir Grp'd RW 4096
/dev/vx/rdmp/emcpower382s2 00A2 15A:C4 2-Way Mir Grp'd RW 4096
/dev/vx/rdmp/emcpower383s2 00A3 02B:DD 2-Way Mir Grp'd RW 4096
. . .
#
The sympd list command output shows that Symmetrix logical
volumes A0A3 correspond to pseudo device names
emcpower380s2emcpower383s2. The example below: creates the
device group cpgroup and populates it with the STD application
devices A0A3. Since, TimeFinder/Mirror BCVs will be used as the
source devices for Open Replicator, BCV devices 8083 are
associated with the device group.
# symdg create cpgroup
# symld -g cpgroup addall -sid 359 -range a0:a3
# symbcv -g cpgroup associateall -range 80:83
#
If TimeFinder/Clone was being used, a BCV could be used in the
same way or target devices (TGT) could be added to the group with
the following command:
symld -g cpgroup add dev NN -tgt
If TimeFinder/Snap was being used, a VDEV would be added to the
group with the following command:
symld -g cpgroup add dev NN -vdev
Initial TimeFinder/Mirror establish
Migration step 7 is to split the BCV. Since the initial state of the BCV is
Never Established, it is necessary to first synchronize the BCV
with the STD. Before the BCV can be used in a full establish
operation, the Open Replicator session created earlier as part of
verifying completion of the setup phase must be terminated.
Depending on the Open Replicator state, Solutions Enabler will block
TimeFinder/Mirror operations on Open Replicator control devices to
ensure that the contents are not changed in the middle of Open
Replicator operations. Here is an example of Solutions Enabler
blocking the TimeFinder/Mirror operation:
# symmir -g cpgroup establish -full -opt
Execute 'Full Establish' operation for device group
'cpgroup' (y/[n]) ? y
'Full Establish' operation execution is in progress for
device group 'cpgroup'. Please wait...
A specified device is involved in a Remote Copy session and cannot be modified
#
The simplest rule is that the Open Replicator state must be Copied
(in nondata migration situations, the Restored state without donor
update enabled is also valid). Terminating the session will also avoid
any operational conflicts, and is appropriate in this case because the
BCV control device needs to have the correct data before the first
Open Replicator copy session. Here is an example of first terminating
the Open Replicator session, and then seeing the TimeFinder/Mirror
operation work without being blocked:
# symrcopy -file cold_orpairs terminate
Execute 'Terminate' operation for the 4 specified devices
'Terminate' operation execution is in progress for the device list
'Terminate' operation successfully executed for the device list
# symmir -g cpgroup establish -full -opt
Execute 'Full Establish' operation for device group
'Full Establish' operation execution is in progress for
'Full Establish' operation successfully initiated for device group 'cpgroup'.
#
TimeFinder/Mirror split
Before the BCV devices can be split, the synchronization must be
complete, and the verify action using the interval option(-i) is an
easy way to wait for synchronization to complete. From the
synchronized state the split action is permitted. The split action
has multiple options for specifying a consistent split. In this case the
vxfs mountpoint specified will be frozen just before the instant split is
performed and thawed as soon as the foreground split completes.
The -vxfs option can only be used when running on the production
host; when using a control host the -consistent option can be used
instead. For this example and with other cold pushes using a BCV or
clone, consistency is obtained using TimeFinder rather than using
similar consistency options with the symrcopy activate action.
For example:
# symmir -g cpgroup verify -synched -i 30
Not All devices in the group 'cpgroup' are in 'Synchronized' state.
Not All devices in the group 'cpgroup' are in 'Synchronized' state.
All devices in the group 'cpgroup' are in 'Synchronized' state.
# symmir -g cpgroup split -instant -vxfs /cphome
Execute 'Split' operation for device group
'Split' operation execution is in progress for
Freezing 1 filesystem(s)......................................Done.
Thawing 1 filesystem(s).......................................Done.
'Split' operation successfully executed for device group
'cpgroup'.
#
Note: It would actually be better to use the -not_ready option on the
split action to put the Open Replicator source device in the Not Ready
state as required for a cold push. This option was left out in this example to
show how to correctly overcome its omission in Cold control devices must
be Not Ready, on page 98.
If TimeFinder/Clone was being used, the activate can be issued
immediately after the create without waiting, however for
performance reasons, it is better to verify that the precopy cycle is
completed:
symclone -g cpgroup verify -precopy -cycled
symclone -g cpgroup activate -vxfs /cphome
-not_ready
If TimeFinder/Snap was being used, the activate can be issued
immediately after the create without waiting. When using a VDEV,
use of the -not_ready option for this command is required, as the
VDEV must remain in the Not Ready state while the Open
Replicator session is present:
symsnap -g cpgroup activate -vxfs /cphome
-not_ready
Migration step 8: symrcopy create
Cold control devices must be Not Ready
The first attempt at executing the create action will fail, because the
TimeFinder/Mirror split operation leaves the BCV devices in the
Ready state, and Open Replicator control devices in a cold session
must be in the Not Ready state. For example, here is a create
attempt and the corresponding error message:
# symrcopy -file cold_orpairs create -push -cold -differential -name cold_push -copy
The device is not in a valid Ready status. Operation cannot proceed
#
An alternate way to control this group of devices, besides the list
within a file used in Verify all with symrcopy create on page 84,
is to use the device group created for the TimeFinder operations. The
-bcv option will cause the not_ready action to only be applied to
the BCV devices associated with the device group (the production
devices A0A3 will not be affected). For example:
# symld -g cpgroup -bcv not_ready
Execute a 'Not Ready' Device operation for all devices
in device group 'cpgroup' (y/[n]) ? y
'Not Ready' Device operation successfully completed for the device group.
#
Migration step 8: symrcopy create 99
Create action options
Now that the devices are Not Ready, the repeated create action
will succeed. Here is an example of a successful create:
# symrcopy -file cold_orpairs create -push -cold -differential -name cold_push -copy
#
The create action used in this example has a number of important
options set:
The -file cold_orpairs option defines the control and
remote device pairs.
The -push and -cold options make this copy session a cold
push.
The -differential option directs Open Replicator to keep
track of changes to the control devices, providing the ability to
push incremental updates to the remote.
The -name cold_push option defines a session name for all the
pairs defined in the cold_orpairs file, providing an alternate
method of specifying which pairs are addressed by the
symrcopy command.
The -copy option indicates that upon activate, a background
sequential copy from the control to the remote will begin.
Open Replication query display
The query (or verify) actions can be used to show the copy session
in the Created state. Note the use of the named session cold_push
to refer to the control/remote pairs of interest. The CD value for the
RI flags indicate the display of the remote device using the
CLARiiON ID and device name rather than the LUN WWN.
Additionally the CDSHU flag settings indicate the use of -copy,
-differential, -push, and -cold options for this copy session.
# symrcopy -session cold_push query
Session Name : cold_push
Control Device Remote Device Flags Status Done
---------------------------- ----------------------- ----- -------------- ----
Protected
SID:symdev Tracks Identification RI CDSHU CTL <=> REM (%)
------------------ --------- -------------------- -- ----- -------------- ----
000190300359:0083 65535 HK190807410004:0007 CD XXX.. Created N/A
Total ---------
Track(s) 262140
MB(s) 16383.8
Legend:
R: (Remote Device Vendor Identification)
S = Symmetrix, C = Clariion, . = Unknown.
I: (Remote Device Specification Identifier)
D = Device Name, W = LUN WWN, World Wide Name.
Flags:
(C): X = The background copy setting is active for this pair.
. = The background copy setting is not active for this pair.
(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.
#
Migration step 8: symrcopy create 101
Query -detail option
Specifying the -detail option with the query action reveals the
default setting of five (5) for the pace parameter. It will also display
the Modified Tracks, for incremental updates, but this value is only
calculated if the Solutions Enabler options file parameter
SYMAPI_RCOPY_GET_MODIFIED_TRACKS is set to TRUE. The
default setting is FALSE in order to optimize performance. The
session name is also listed in this display:
# symrcopy -session cold_push query -detail
Control Device Remote Device Flags Status Done Pace Name
------------------------------------ ----------------------- ----- -------- ---- ---- ---------
Protected Modified
SID:symdev Tracks Tracks Identification RI CDSHU CTL<=>REM (%)
----------------- --------- -------- -------------------- -- ----- -------- ---- ---- ---------
000190300359:0083 65535 0 HK190807410004:0007 CD XXX.. Created N/A 5 cold_push
. . .
Migration step 10: symrcopy activate
Activate sets the point-in-time for the push of data from the control
to the remote. In this case of cold push, there is no need for
consistency options, as these were already used as part of the
TimeFinder/Mirror split operation. Notice that after the
activate, the Status has changed to CopyinProg(ress) and
the number of Protected Tracks for each device is reduced from
the starting value of 65535 as tracks are copied to the remote.
# symrcopy -session_name cold_push activate
Execute 'Activate' operation for the 4 specified devices
with session name 'cold_push' (y/[n]) ? y
'Activate' operation execution is in progress for the device list
with session name 'cold_push'. Please wait...
'Activate' operation successfully executed for the device list
with session name 'cold_push'.
---------------------------- ----------------------- ----- -------------- ----
Protected
------------------ --------- -------------------- -- ----- -------------- ----
000190300359:0083 65365 HK190807410004:0007 CD XXX.. CopyInProg 0
Total ---------
Track(s) 261469
MB(s) 16341.8
. . .
Migration step 12: symrcopy set ceiling 103
Migration step 12: symrcopy set ceiling
As shown earlier with the query -detail, by default the pace
parameter is set to five, which significantly slows copy operations by
inserting delays.
As a best practice, the ceiling value should be used which more
effectively limits the Open Replicator use of resources shared with
the production applications. In this case, the ceiling value is set to 30%
reserving 70% of the FA bandwidth for production applications. The
pace value is ignored for all participating director/port combinations
where the ceiling value is not NONE.
Unlike the pace parameter which is session based, the ceiling value is
director/port based and affects all sessions that use those ports. Since
both ports 2C:0 and 15C:0 are used by the production devices and
could be used by Open Replicator, the ceiling is set on both ports by
executing the following commands:
# symrcopy set ceiling 30 -sid 359 -dir 2c -port 0
Execute 'Set Ceiling' operation (y/[n]) ? y
'Set Ceiling' operation execution is in progress
'Set Ceiling' operation successfully executed
# symrcopy set ceiling 30 -sid 359 -dir 15c -port 0
Execute 'Set Ceiling' operation (y/[n]) ? y
'Set Ceiling' operation execution is in progress
'Set Ceiling' operation successfully executed
#
In actual practice, it would be better to set the ceiling prior to any
Open Replicator I/O taking place (i.e., before the activate). The
setting of performance parameters is shown at this point in the
operational sequence because it is possible that active tuning might
be altered at various points of the migration versus setting a single
value that is always in place.
Just as the detailed query can be used to show the pace setting, there
is a list ceiling operation that can be used to display the ceiling
values, and that also shows the current Open Replicator use of
bandwidth. In the following example, only director port 2C:0 shows
bandwidth use, because director port 15C:0 was not zoned and LUN
masked for this cold push.
# symrcopy -sid 359 list ceiling
Symmetrix Remote Copy Bandwidth Ceiling
Max Set Actual
Dir:P (MB) (%) (MB)
----- ---- ---- ------
01C:0 150 NONE 0
01C:1 150 NONE 0
02C:0 150 30 14
02C:1 150 NONE 0
15C:0 150 30 0
15C:1 150 NONE 0
16C:0 150 NONE 0
16C:1 150 NONE 0
#
Migration step 13: symrcopy query and verify 105
Migration step 13: symrcopy query and verify
This step consists mostly of waiting until the Open Replicator copy
completes for the point-in-time of the activate. The query action
will report the Status, the decreasing number of Protected
Tracks, and the increasing Done percent. The normal status
sequence goes from CopyInProg to Copied. Using the verify
action allows scripts to wait for a particular status. The use of the
count (-c) option limits how long to wait and the program can check
for unsuccessful return status indicating an exit from the loop due to
the count being reached rather than reaching the waited for status.
In the following example, the interval (-i) of 300 seconds (5 minutes)
with a count of 36 means waiting for three hours (180 minutes). In the
example, the Copied state was reached within the three-hour time
limit for checking. It is important to specify a realistic time limit
based on the amount of data to be copied and the bandwidth or other
tuning limitations that will affect how long the copy could take to
complete.
---------------------------- ----------------------- ----- -------------- ----
Protected
------------------ --------- -------------------- -- ----- -------------- ----
# symrcopy -session cold_push verify -copyinprog
All session(s) with name 'cold_push' are in 'CopyInProg' state.
# symrcopy -session cold_push verify -copied -i 300 -c 36
None of the session(s) with name 'cold_push' are in 'Copied' state.
None of the session(s) with name 'cold_push' are in 'Copied' state.
. . .
All session(s) with name 'cold_push' are in 'Copied' state.
#
Migration step 14: Iterative symrcopy recreate
Incrementally update control devices from production devices
Because a cold push from a BCV is based on a point-in-time that does
not include all of the application writes to the production device, it
must be incrementally updated with the writes since the activation of
the last cold push. This is done using a combination of
TimeFinder/Mirror commands to incrementally update the BCV and
Open Replicator commands to incrementally update the remote
devices.
To avoid Solutions Enabler blocks on TimeFinder interactions with
Open Replicator, the simple rule to follow is that the Open Replicator
session should be in the Copied state when attempting TimeFinder
operations. In Migration step 13: symrcopy query and verify, the
last status verified was the Copied state. In the following example,
TimeFinder/Mirror is used to incrementally establish (update) the
BCV, verify the BCVs are synchronized with the production
devices, and then consistently split the BCVs. Also included here is
the -not_ready option to keep the BCVs in the Not Ready state as
required for Open Replicator cold operations.
# symmir -g cpgroup establish
Execute 'Incremental Establish' operation for device group
'Incremental Establish' operation execution is in progress for
'Incremental Establish' operation successfully initiated for device group
'cpgroup'.
# symmir -g cpgroup verify -synched -i 30
# symmir -g cpgroup split -instant -vxfs /cphome -not_ready
Execute 'Split' operation for device group
Freezing 1 filesystem(s)......................................Done.
Thawing 1 filesystem(s).......................................Done.
Migration step 14: Iterative symrcopy recreate 107
'Split' operation successfully executed for device group 'cpgroup'.
#
If TimeFinder/Clone had been used in place of TimeFinder/Mirror,
the sequence would have been to consistently establish the TGT
(combine incremental recreate and activate) with an updated
point-in-time of the production devices using the -not_ready
option. It is not required to wait until the TGTs have finished copying
the point-in-time and reached the Copied state with the verify
action.
If TimeFinder/Snap had been used in place of TimeFinder/Mirror,
the TimeFinder incremental update, cannot activate the recreated
TimeFinder/Snap session before the Open Replicator session is first
recreated. Similarly, the symrcopy activate cannot precede the
symsnap activate (which again includes the -not_ready option
to keep the VDEV in the Not Ready state). Therefore when using
TimeFinder/Snap the order of operations for iterative update must
be:
5. symsnap recreate
6. symrcopy recreate
7. symsnap activate -not_ready
8. symrcopy activate
Incrementally update remote devices from control devices
First, use Open Replicator recreate to set up an incremental update
using the Symmetrix Differential Data Facility (SDDF) information
maintained as a result of the -differential option on the original
create. Second, use activate to set a new point-in-time and start
the movement of data. Third, wait for completion of the incremental
data movement. The Copied state indicates finishing the incremental
update and is required for using TimeFinder in the next iteration of
incremental updates.
# symrcopy -session cold_push recreate
Execute 'Recreate' operation for the 4 specified devices
'Recreate' operation execution is in progress for the device list
'Recreate' operation successfully executed for the device list
# symrcopy -session cold_push activate
#
Stop applications and final incremental update
In order to end the iterative loop of incremental updates, it is
necessary to stop production applications from writing to the
production devices. The file system is displayed here as a simplistic
method for comparing with the migrated copy in Migration step 15:
Verify migration and symrcopy terminate on page 110. In this
example, the change directory (cd) away from the mounted
filesystem emulates stopping the application, and is required before
the filesystem can be unmounted. Once the filesystem is unmounted,
the volume group can be deported from VxVM, and the disks can be
removed from VxVM.
# cd /cphome
# ls -l
total 8
-rw-r--r-- 1 root root 12 Jun 30 17:43 cold_controldevs
-rw-r--r-- 1 root root 216 Jun 30 17:43 cold_orpairs
-rw-r--r-- 1 root root 12 Jun 30 17:43 controldevs
-rw-r--r-- 1 root root 216 Jun 30 17:43 hot_orpairs
drwxr-xr-x 2 root root 96 Jun 30 17:14 lost+found
-rw------- 1 root root 0 Jun 30 17:40 sh2256.1
# cd /
# umount /cphome
# vxdg deport cpvg
# vxdisk rm emcpower380s2
#
Migration step 14: Iterative symrcopy recreate 109
The last incremental synchronization is repeated almost identically as
in Incrementally update control devices from production devices
on page 106 and Incrementally update remote devices from control
devices on page 107. The count value on the verify checks is lower
since there is less data to update. The TimeFinder/Mirror split
operation cannot freeze the file system since it is now unknown (and
effectively frozen) due to the umount and deport operations
performed earlier.
In the following example, the -noprompt option is used to skip the
control action verification queries. Since there are no new writes, after
completion of this last incremental update the Open Replicator remote
devices are fully synchronized with the production devices.
# symmir -g cpgroup establish -noprompt
'Incremental Establish' operation execution is in progress for
'Incremental Establish' operation successfully initiated for device group
'cpgroup'.
# symmir -g cpgroup verify -synched -i 30 -c 6
# symmir -g cpgroup split -not_ready -noprompt
'Split' operation successfully executed for device group 'cpgroup'.
# symrcopy -session cold_push recreate -noprompt
'Recreate' operation execution is in progress for the device list
'Recreate' operation successfully executed for the device list
# symrcopy -session cold_push activate -noprompt
#
Migration step 15: Verify migration and symrcopy terminate
Before terminating the Open Replication copy sessions (and losing all
differential information), it is best to conduct some type of
application specific verification that the remote devices are a complete
and valid replacement for the original production devices. This will
be shown as a comparison with the list directory of the production
devices later in Cleanup step 18: Restart applications using targets
on page 114. In a true production data migration, best practice would
include bringing the application up in a test mode using the migrated
data to verify that the application will work without fail. The depth
and breadth of this type of verification will vary depending on the
business requirements for each data migration. Once verified, the
Open Replicator sessions are no longer needed and can be terminated
as follows:
# symrcopy -session cold_push terminate
No sessions were found with name: cold_push
#
Note: When using TimeFinder/Snap, the symrcopy terminate command
must precede any symsnap terminate commands.
Hot push differences from cold push
This TechBook does not include an entire example of hot push,
because the operations are very similar to those just shown for cold
push. There is a difference in the required setup, because hot
operations require all capable ports to be zoned and LUN masked.
This difference will be covered in detail in Chapter 6, Hot Pull from
CLARiiON Migration Example. A partial hot push example is
included in Reactivate Failed Session on page 295.
Migration step 15: Verify migration and symrcopy terminate 111
There are two key operational differences between a hot and cold
push. First, with a hot push there is no need for BCV or Clone
devices; the activate takes a point-in-time on the actual production
devices, using Copy on First Write (COFW) to handle production
write I/Os to data not yet copied to the remote devices. Second the
control devices can be in the Ready state since COFW is in effect.
Operationally, this means there is no need for the TimeFinder
operations or the not_ready device control operations. The Open
Replicator activate action will likely use the -consistent option
to ensure a consistent point-in-time, since this is no longer done
separately using TimeFinder/Mirror or TimeFinder/Clone.
Additionally, the create and recreate actions will often use the
-precopy option to minimize the COFW performance penalty on
the production devices. In order to get the most benefit from precopy,
best practice would include a time delay between the
create/recreate and activate actions. The command
symrcopy verify -precopy -cycled can be used to wait for
the completion of one sequential pass through all blocks of the
production devices before activating the session.
Cleanup step 16: Make source devices host inaccessible
By definition, these cleanup steps occur after all Open Replicator
steps are complete. These host and application specific examples are
included briefly here in order to contrast these manual steps with
more functional actions that are included as part of PowerPath
Migration Enabler (PPME) (which is discussed in Chapter 9, PPME
with Open Replicator Migration Example).
Although the original source devices were made unavailable to the
host in Stop applications and final incremental update on page 108,
this change was not permanent and it is possible that upon a reboot
these devices may be accessed again. If the source device mount
definitions are not removed from /etc/vfstab, upon reboot the
source devices would automatically be remounted. If an unplanned
disk rescan or reboot takes place without making?these devices
inaccessible, then it is possible that the host may mistakenly use these
devices again in place of the migrated target devices upon
recognizing the private region information on the disks. Best practice
would avoid this problem and also preserve the production volumes
unchanged until it was certain that there was no need to revert to the
data stored on the original source devices. The following steps can be
used to unmask the source devices from the host to ensure that the
host will not inadvertently use these devices.
# symmaskdb -sid 359 list assignment -dev a0:a3
Device Identifier Type Dir:P
------ ---------------- ----- ----------------
00A0 210000e08b927df4 FIBRE FA-2C:0
210000e08b925cf5 FIBRE FA-15C:0
00A1 210000e08b927df4 FIBRE FA-2C:0
210000e08b925cf5 FIBRE FA-15C:0
00A2 210000e08b927df4 FIBRE FA-2C:0
210000e08b925cf5 FIBRE FA-15C:0
00A3 210000e08b927df4 FIBRE FA-2C:0
210000e08b925cf5 FIBRE FA-15C:0
# symmask -sid 359 -wwn 210000e08b927df4 remove -g cpgroup -std -dir 2c -p 0
# symmask -sid 359 -wwn 210000e08b925cf5 remove -g cpgroup -std -dir 15c -p 0
# symmask -sid 359 refresh -noprompt
Symmetrix FA directors updated with contents of SymMask Database 000190300359
#
# symmaskdb -sid 359 list assignment -dev a0:a3
No device masking database records could be found for the specified input para
meters
#
Cleanup step 17: Make target devices ready to host 113
Cleanup step 17: Make target devices ready to host
The target devices are presented to the host in this case, simply by
removing the remote CLARiiON devices from the OR_Symm359
storage group and adding the devices to the existing D229 storage
group for the local Solaris host. In other cases it might be necessary to
add new zoning or create a new storage group or use other array
specific LUN masking techniques. For example:
# ./navicli -h Clar0031_SPA storagegroup -removehlu -gname OR_Symm359 -hlu 00 -o
# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname D229 -alu 04 -hlu 01
The SYMAPI database is updated by rediscovering the CLARiiON
and the list of CLARiiON devices now shows host pathnames for
devices 47.
# symcfg discover -clariion
# symdev list -clariion
Device Device
----- ----------------------- ----------------------------------------------
----- ----------------------- ----------------------------------------------
00000 Not Visible RAID-5 4096 600601602B401E00148F6936D93BDD11
00004 /dev/rdsk/emcpower2c RAID-5 4096 600601602B401E00188F6936D93BDD11
00005 /dev/rdsk/emcpower1c RAID-5 4096 600601602B401E00198F6936D93BDD11
00006 /dev/rdsk/emcpower0c RAID-5 4096 600601602B401E001A8F6936D93BDD11
00007 /dev/rdsk/emcpower4c RAID-5 4096 600601602B401E001B8F6936D93BDD11
00008 Not Visible RAID-5 4096 600601602B401E00BAE08E938A47DD11
00009 /dev/rdsk/emcpower3c RAID-5 4096 600601602B401E001078C2A48A47DD11
#
Cleanup step 18: Restart applications using targets
The migrated information on the target devices includes the VxVM
private region with the disk group information which can be
imported.
# vxdctl enable
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
c0t0d0s2 auto:none - - online invalid
c0t1d0s2 auto:none - - online invalid
emcpower0s2 auto:cdsdisk - - online
. . .
# vxdg import cpvg
# vxvol -g cpvg start cplv
# mount -F vxfs /dev/vx/dsk/cpvg/cplv /cphome
#
Although the remote devices on the CLARiiON and the control devices
on the Symmetrix VMAX (or Symmetrix DMX) were both configured
as 4 GB devices, the actual size of the devices differs slightly with the
CLARiiON devices being slightly larger. To get the host operating
system to recognize and use the additional space, it is necessary to
execute operating system and application specific steps.
On Solaris hosts, a logical units disk label contains information about
the vendor, product, geometry, and slices. PowerPath Migration
Enabler (PPME) includes a utility called powerformat that can be
used independent of PPME to safely update disk-label information,
preserve partition definitions and data, and make newly available
disk capacity available for use.
Cleanup step 18: Restart applications using targets 115
For this example, vxdisk resize is used as the first step to get the
OS and LVM to recognize the new space on the LUNs. The before and
after output from vxprint shows the change in PUBLEN from
8382336 to 8385792 blocks for an increase of 3456 blocks for each disk
media (DM) record:
# df -k
Filesystem kbytes used avail capacity Mounted on
. . .
/dev/vx/dsk/cpvg/cplv
16764672 21198 15697013 1% /cphome
# vxprint -g cpvg -ht
DG NAME NCONFIG NLOG MINORS GROUP-ID
ST NAME STATE DM_CNT SPARE_CNT APPVOL_CNT
DM NAME DEVICE TYPE PRIVLEN PUBLEN STATE
RV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRL
RL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNK
CO NAME CACHEVOL KSTATE STATE
VT NAME NVOLUME KSTATE STATE
V NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL PREFPLEX UTYPE
PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE
SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE
SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE
SC NAME PLEX CACHE DISKOFFS LENGTH [COL/]OFF DEVICE MODE
DC NAME PARENTVOL LOGVOL
SP NAME SNAPVOL DCO
# vxdisk -g cpvg resize emcpower2s2
# vxprint -htq
Disk group: cpvg
. . .
Next the vxresize command is used to expand the volume and file
system. The expansion size specified is +13824 (4 x 3456) blocks. The
vxprint output shows the cplv logical volume length increasing by
13824 blocks from 33529344 to 33543168. Similarly, the filesystem
capacity in kbytes changed from 16764672 to 16771584, an increase of
6912 kbytes which matches the expected change in blocks (13824
blocks 2 blocks/kbyte = 6912 kbytes). For more information on
handling LUN expansion for UNIX systems, reference the EMC
Symmetrix LUN Expansion and UNIX Logical Volume Managers Technical
Note available on Powerlink
.
# df -k
. . .
16764672 21198 15697013 1% /cphome
# /etc/vx/bin/vxresize -g cpvg -F vxfs cplv +13824
# vxprint -g cpvg -htq
. . .
# df -k
. . .
16771584 21198 15703493 1% /cphome
#
Cleanup step 19: Redeploy the source devices storage
Exactly how the storage that was used for the original source devices
is redeployed is unique to each situation, so it would not be
meaningful to try to depict a best practice here. In some cases of data
migration, the old storage is literally removed from the site and is not
made available for any actual redeployment. In the example used in
this chapter, it is likely that the devices would either be reused as
already configured for different data, or be deleted and reconfigured
for different data.
Hot Pull from CLARiiON Migration Example 117
6
This chapter details a hot pull Open Replicator example that differs
from the previous cold push example in the set of steps needed to
complete the migration. This chapter also highlights a
troubleshooting example that demonstrates an initial failure to
successfully complete setup step 6. The topics covered include:
Introduction ...................................................................................... 118
Setup step 1: Identify target devices.............................................. 121
Setup step 2: Configure migration SAN zone.............................. 122
Setup step 3: Configure migration LUN masking....................... 125
Setup step 4: Configure target zoning and LUN masking......... 126
Setup step 5: Prepare Open Replicator session pairs file ........... 128
Setup step 6: Verify completion of setup steps ............................ 131
Migration step 9: Stop the applications ........................................ 136
Migration step 10: symrcopy activate ........................................... 138
Migration step 11: Restart applications using targets................. 139
Migration step 13: symrcopy query and verify ........................... 144
Migration step 15: Verify migration and terminate .................... 145
Cleanup step 19: Redeploy the source devices............................ 146
Hot Pull from CLARiiON
Migration Example
Hot Pull from CLARiiON Migration Example
Introduction
This chapter details a hot pull migration example using Solutions
Enabler SYMCLI on a Windows host. The full range of migration
steps will be reviewed and steps that are different than those detailed
in Chapter 4, Cold Push to CLARiiON Setup Example and
Chapter 5, Cold Push to CLARiiON Migration Example will be
highlighted.
Hot pull setup steps
Since this is a hot operation, the zoning and LUN masking
requirements are stricter than for cold operations, requiring all
Symmetrix FA ports that are mapped by the control devices to be
zoned and LUN masked to "see" the remote devices. In order to
demonstrate troubleshooting in an example, the setup steps 2 and 3
will deliberately miss meeting this requirement. Additionally,
because this is a hot pull migration some of the actions completed in
the previous example as cleanup phase steps, instead are completed
here during the setup phase in step 4. The six hot pull setup steps are:
FA host ports.
3. Configure LUN masking for remote devices to allow access
host ports.
devices.
5. Prepare Open Replicator session pairs file.
Replicator session.
Hot pull migration steps
This chapter will provide details of an example of the six migration
steps applicable for a hot pull. In this example, step 8 which invokes a
create in the migration phase is not necessary. The create is
executed at the end of the setup phase, and this time there is no
Introduction 119
TimeFinder operation which in Initial TimeFinder/Mirror establish
on page 95 required exiting the Created state through a terminate
action. Step 9 needed for all pull migrations is now included, and step
11 for hot pull migrations is included as well. Tuning is applicable for
all migrations including hot pull, and already completed earlier in
Migration step 12: symrcopy set ceiling on page 103. It is not
necessary to repeat this action in this example, because the ceiling
setting applies to all sessions which use the same FA director ports.
Step 14 is omitted because iteratively applying incremental updates is
not applicable for pull operations. The hot pull migration steps are:
9. Stop the production application.
11. Restart the application pointing to the target (control) devices.
Hot pull cleanup step
In the case of hot pull, applications are redirected to access the data
from the target devices before the data movement is complete.
Therefore, the first three cleanup steps are actually completed in the
setup phase. That leaves only a single step in the cleanup phase, step
19: to redeploy the source devices storage once the migration is
complete.
Figure 18 on page 120 illustrates the hot pull setup, migration, and
cleanup steps in a flowchart. The non-applicable step 14, iterative
incremental update for push sessions, and the three non-applicable
cleanup steps (steps 1618) are omitted from the flowchart entirely to
avoid unnecessary complexity.
Figure 18 Hot pull setup, migration, and cleanup flowchart
ICO-IMG-000541a
storage
impact level
cluster, create
terminate OR
13. Verify OR copy
done
Hot pull?
Need tuning?
target devices
10. OR activate
Pull?
Hot pull?
Hot pull?
Push?
Create not run?
Y
Y
Y
Y
Y
Y
N
N
N
N
N
N
N
6. Verify setup
pairs (file)
3. LUN mask remote
devices to DMX FA
2. Zone DMX FA
control to remote array
target devices
Y
N
7. Split the BCV
Cold push
from BCV, clone
or VDEV?
Y
For this pull example, the target devices are the control devices on the
Symmetrix DMX 000190300359 array. The remote source devices
are 2 GB in size and the target devices are 4 GB in size. The symdev
command with the -range option can be used to display the control
devices 91:94 also revealing the Physical Device Names:
c:\>symdev -sid 359 list -range 91:94
--------------------------- ------------ ------------------------------------
Cap
Sym Physical SA :P DA :IT Config Attribute Sts (MB)
--------------------------- ------------ ------------------------------------
0091 \\.\PHYSICALDRIVE6 15C:0 15B:D6 2-Way Mir N/Grp'd RW 4096
0092 \\.\PHYSICALDRIVE7 15C:0 01A:CC 2-Way Mir N/Grp'd RW 4096
0093 \\.\PHYSICALDRIVE8 02C:0 02B:D7 2-Way Mir N/Grp'd RW 4096
0094 \\.\PHYSICALDRIVE9 02C:0 01A:DD 2-Way Mir N/Grp'd RW 4096
c:\>
Setup step 2: Configure migration SAN zone
This example will use the same Symmetrix and CLARiiON arrays as
used in Chapter 4, Cold Push to CLARiiON Setup Example.
Therefore the zone for the DMX FA port that acts as an open systems
host to the remote storage array is already set up. A quick check will
be made to confirm that the correct zoning and LUN masking has
been set up for the devices to be used in this example.
Determining control director WWNs
The Solutions Enabler symdev list -multiport command is used
to determine on which directors the control devices are visible. For
this example, all four control devices, 9194, are mapped to both
director 2C port 0 and director 15C port 0. These are the same FA
director ports that were eligible to be configured in the Open
Replicator SAN zones in Determining Control Director WWN on
page 73.
c:\>symdev -sid 359 list -range 91:94 -multiport
--------------------------- ------------- -----------------------------------
Cap
--------------------------- ------------- ----------------------------------
0091 15B:D6 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE6 - 15C:0 - - - - -
Not Visible - 02C:0 - - - - -
0092 01A:CC 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE7 - 15C:0 - - - - -
Not Visible - 02C:0 - - - - -
0093 02B:D7 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE8 - 02C:0 - - - - -
Not Visible - 15C:0 - - - - -
0094 01A:DD 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE9 - 02C:0 - - - - -
Not Visible - 15C:0 - - - - -
Setup step 2: Configure migration SAN zone 123
c:\>
Determining remote storage array WWNs
The remote storage array is again CLARiiON HK190807410004.
Figure 19 illustrates checking the connectivity status for Storage
Group D194 and reveals the same A-0, A2, B-0, B-2 Storage Processor
connections as those seen in Determining Remote Storage Array
WWN(s) on page 74
Figure 19 Host connectivity status for licod194 in Storage Group D194
Reuse existing migration SAN zones
Since the same Symmetrix DMX FA and CLARiiON SPA ports are
relevant to this example and were put in place for the example in
Chapters 45, it appears that the zones already defined can be used
without change. However, the example in this chapter is for a hot
operation which requires all paths to be configured so each director
can handle protected track copy needs for itself. For hot pull
operations, protected tracks that have not already been copied by the
background copy are copied immediately as part of Copy on First
Access (COFA). For hot push operations the protected track copy is
ICO-IMG-000542
Copy on First Write (COFW). The single active path zoning already
defined for director 2C port 0 alone is insufficient because director
15C port 0 is not included in any migration zone. For purposes of
displaying typical error messages when required zoning is missing,
this example will proceed without adding the missing zones at this
time.
Setup step 3: Configure migration LUN masking 125
Setup step 3: Configure migration LUN masking
Create CLARiiON Storage Group
Because the same DMX FA hosts are connected to the same remote
CLARiiON storage array, storage group OR_Symm359 defined in
Create CLARiiON storage group on page 78 can be reused.
However, like the zoning above, for a hot operation, all paths must be
LUN masked and the single FA DMX port host in the storage
group (corresponding to DMX FA 2C port 0, but no? 15C port 0) will
prove to be insufficient. For purposes of displaying typical error
messages when necessary LUN masking is missing, this example will
proceed without completing all LUN masking requirements at this
time. The four remote source devices for this pull example are added
to the storage group in the example below:
c:\>navicli -h Clar0031_SPA storagegroup -addhlu -gname OR_Symm359 -alu 0 -hlu 0
c:\>
Setup step 4: Configure target zoning and LUN masking
Unlike the example for setting up a cold push in Chapter 4, Cold
Push to CLARiiON Setup Example, the current example is a hot pull
which moves up the step of zoning and masking the target devices
from occurring in the cleanup phase to the setup phase, since the
application will be accessing the target devices from the start.
Target devices 9194 are already correctly mapped and device
masked as shown below by the presence of a physical path displayed
when the sympd list command is executed:
c:\>sympd -sid 359 list
------------------------ ------------- --------------------------------
Cap
------------------------ ------------- --------------------------------
. . .
\\.\PHYSICALDRIVE6 0091 02C:0 15B:D6 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE7 0092 15C:0 01A:CC 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE8 0093 02C:0 02B:D7 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE9 0094 02C:0 01A:DD 2-Way Mir N/Grp'd RW 4096
. . .
c:\>
Setup step 4: Configure target zoning and LUN masking 127
For example, a command file named map.txt that could be used for
the mapping operation would look something like this:
map dev 91:94 to dir 2C:0 starting lun=81;
map dev 91:94 to dir 15C:0 starting lun=81;
And invoking the mapping operation and specifying the device
masking commands could be done by executing a command
sequence like this:
c:\>symconfigure -sid 359 -f map.txt commit
Execute a symconfigure operation for symmetrix '000190300359' (y/[n]) ? y
A Configuration Change operation is in progress. Please wait...
Establishing a configuration change session............Established.
Processing symmetrix 000190300359
Performing Access checks...............................Allowed.
Checking Device Reservations...........................Allowed.
Submitting configuration changes.......................Submitted
Locking devices........................................Locked.
Validating configuration changes.......................Validated.
Initiating PREPARE of configuration changes............Prepared.
Initiating COMMIT of configuration changes.............Queued.
COMMIT requesting required resources...................Obtained.
Step 012 of 012 steps..................................Executing.
Local: COMMIT.........................................Done.
Terminating the configuration change session...........Done.
The configuration change session has successfully completed.
c:\>symmask list hba
Identifier Type Adapter Physical Device Path Dir:P
---------------- ----- ---------------- --------------------- -----
10000000c97111fc Fibre 10000000c97111fc \\.\PHYSICALDRIVE33 02C:0
10000000c971196e Fibre 10000000c971196e \\.\PHYSICALDRIVE5 15C:0
c:\>symmask -sid 359 -wwn 10000000c97111fc -dir 2c -p 0 add devs 91:94 -dynamic_lun
c:\>symmask -sid 359 -wwn 10000000c971196e -dir 15c -p 0 add devs 91:94 -dynamic_lun
The following devices are already assigned in at least one entry:
0091 0092 0093 0094
Would you like to continue (y/[n])?y
c:\>symmask -sid 359 refresh -noprompt
Symmetrix FA directors updated with contents of SymMask Database 000190
300359
c:\>
Setup step 5: Prepare Open Replicator session pairs file
The application for this example uses Windows drive letters L, M,
N and O which reside on the initial CLARiiON source devices.
Figure 20 illustrates the contents of drive L as seen with the Windows
Explorer.
Figure 20 Windows drive L contents
ICO-IMG-000543
Setup step 5: Prepare Open Replicator session pairs file 129
Using Disk Management, it can be seen in Figure 21 that drives L, M,
N and O correspond to disks 1-4. Note that the size of each drive is 2
GB.
Figure 21 Windows Disk Management display of drives L, M, N and O
ICO-IMG-000544
Because the CLARiiON has been discovered in the SYMAPI database
file, the CLARiiON device numbers (03) related to physical drives
14 can be determined using the symdev list command with the
-clariion option. For example:
c:\>symdev list -clariion
Device Device
---- --------------------- -------------------------------------------------
---- --------------------- -------------------------------------------------
00000 \\.\PHYSICALDRIVE1 RAID-5 2048 600601602B401E000CDB4E44EA4DDD11
00001 \\.\PHYSICALDRIVE2 RAID-5 2048 600601602B401E000DDB4E44EA4DDD11
00002 \\.\PHYSICALDRIVE3 RAID-5 2048 600601602B401E000EDB4E44EA4DDD11
00003 \\.\PHYSICALDRIVE4 RAID-5 2048 600601602B401E000FDB4E44EA4DDD11
. . .
c:\>
Therefore, for this example hot pull session, the Open Replicator pair
file defining the control-remote pairs could be:
c:\>type hot_pull_orpairs.txt
c:\>
Discover missing zoning with symrcopy create
Using the hot_pull_orpairs file, an attempt to create the hot pull
Open Replicator session will reveal any problems with the required
setup:
c:\>symrcopy -file hot_pull_orpairs.txt -pull -hot create
in device file 'hot_pull_orpairs.txt' (y/[n]) ? y
in device file 'hot_pull_orpairs.txt'. Please wait...
The ORS create operation failed, see the SYMAPI log file for more information
c:\>
Detailed error messages can be displayed by re-executing the
create action with the verbose option -v specified, providing
similar information as can be obtained by examining the contents of
the SYMAPI log file. In the example shown below, the first reported
status SANCOPY_DEV_SUCCESS indicates that for control device 91,
director 2C could see the remote device. However, the second
reported status SANCOPY_DEV_NO_REMOTE_TARGETS indicates that
for the same control device 91, director 15C could not see any remote
devices. This indicates that a zoning error exists.
c:\>symrcopy -file hot_pull_orpairs.txt -pull -hot create -v
STARTING a REMOTE Copy CREATE (PULL) (HOT)
SELECTING Control device - Remote devices:
(Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4D
DD11 - [SELECTED]
(Ctl)Sym: 000190300359 Device: 00092 - LUN WWN: 600601602B401E000DDB4E44EA4D
DD11 - [SELECTED]
(Ctl)Sym: 000190300359 Device: 00093 - LUN WWN: 600601602B401E000EDB4E44EA4D
DD11 - [SELECTED]
(Ctl)Sym: 000190300359 Device: 00094 - LUN WWN: 600601602B401E000FDB4E44EA4D
DD11 - [SELECTED]
STARTING a RCOPY 'CREATE' operation.
DD11 - [loc_dir:02C, rem_num:0, rem_sts:0x1SANCOPY_DEV_SUCCESS ]
DD11 - [loc_dir:15C, rem_num:0, rem_sts:0xaSANCOPY_DEV_NO_REMOTE_TARGETS ]
DD11 - [SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR]
The Rcopy 'CREATE' operation FAILED. (SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)
c:\>
The symsan list -sanports command confirms the missing
zoning definition:
c:\>symsan list -sanports -sid 359 -dir 15c -port 0
No results found.
c:\>
Example configuration of additional migration SAN zone
For the hot pull, it is necessary to define a zone for all directors
mapped to the control device. However, only a path for FA 2C port 0
was zoned in Example configuration of migration SAN zones on
page 77. Now, a second active path is defined for FA 15C port 0
including the standby path to accommodate trespassing in the
CLARiiON. The original zone defined a path from Symmetrix 2C0 to
CLARiiON SPB0 (and standby path to SPA0). The new zone defines a
path from Symmetrix 15C0 to CLARiiON SPB2 (and standby path to
SPA2). The definition of two independent active zones instead of one
zone with all paths results in better performance due to the way
Open Replicator manages alternate paths. Figure 22 shows an excerpt
of the Connectrix Manager Zoning verification screen with the
additional path and standby path zoning defined.
Figure 22 Activate additional zones verification screen excerpt
Discover missing LUN masking with symrcopy create
In the example below, a repeat of the attempt to create the hot pull
Open Replicator session will produce a different error since zoning is
in place but LUN masking is still missing. The second status reported
for control device 91, the entry for director 15C now reports
SANCOPY_DEV_WWID_NOT_FOUND indicating that the remote device
WWN could not be found. Since the WWN came from the SYMAPI
database, the cause is not a WWN entry error, but that the correct
WWN cannot be seen. This is most likely the result of missing LUN
masking.
c:\>symrcopy -file hot_pull_orpairs.txt -pull -hot create -v
ICO-IMG-000545
STARTING a REMOTE Copy CREATE (PULL) (HOT)
SELECTING Control device - Remote devices:
DD11 - [SELECTED]
. . .
STARTING a RCOPY 'CREATE' operation.
DD11 - [loc_dir:02C, rem_num:0, rem_sts:0x1SANCOPY_DEV_SUCCESS ]
DD11 - [loc_dir:15C, rem_num:0, rem_sts:0x6SANCOPY_DEV_WWID_NOT_FOUND ]
DD11 - [SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR]
c:\>
The symsan list -sanports command confirms that zoning is in
place, but when the -sanluns option is used with the symsan
list command, there are no complete LUN records. For example:
c:\>symsan list -sanports -sid 359 -dir 15c -port 0
Flags Num
DIR:P I Vendor Array LUNs Remote Port WWN
----- ----- ------------- ---------------- ---- --------------------------------
15C:0 . EMC CLARiiON HK190807410004 1 5006016A41E087E6
Legend:
c:\>symsan list -sanluns -wwn 5006016241E087E6 -sid 359 -dir 15c -port 0
Remote Port WWN: 5006016241E087E6
ST
A
T Flags Block Capacity LUN Dev LUN
DIR:P E ICRT Size (MB) Num Num WWN
----- -- ----- ----- ----------- ----- ----- --------------------------------
15C:0 NR X... N/A 1 0 N/A 50060160C1E087E650060160C1E087E6
Legend:
(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
c:\>
Example LUN masking for all Symmetrix VMAX (or Symmetrix DMX) FA control
directors
Defining zoning is not the only thing required to provide access. In
this example, FA 15C port 0 also needs to be properly LUN masked
before the remote devices can be seen. For the remote CLARiiON
array in this example, this can be accomplished by adding the FA 15C
port 0 host to the OR_symm359 storage group. Symmetrix FA host
15C is manually registered for both the SPB port 2 and SPA port 2 in
the storage group:
c:\>navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A:D
5:F0:31:CE:50:06:04:8A:D5:F0:31:CE -sp b -spport 2 -host Sym0359 -failovermode 1 -o -unit
serialnumber array
c:\>navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A:D
5:F0:31:CE:50:06:04:8A:D5:F0:31:CE -sp a -spport 2 -host Sym0359 -failovermode 1 -o -unit
serialnumber array
c:\>
Successful create verifies hot pull setup
Now that the correct zoning and LUN masking is in place, the Open
Replicator create succeeds without error in the following example.
Although the Open Replicator sessions are now setup, data
movement has not yet begun. The best practice for hot pull
migrations is to always include the -donor_update option if
production applications will be writing to the target devices. This is
necessary to protect against potential data loss due to a SAN failure
or other connectivity issues during a hot pull operation:
c:\>symrcopy -file hot_pull_orpairs.txt create -pull -hot -donor_update -name
hot_pull -copy
in device file 'hot_pull_orpairs.txt'.
c:\>
Migration step 9: Stop the applications
Since this example is a pull migration, it is necessary to stop any
production applications that are using the remote source devices
(drives LO), in order to fix a point-in-time for the remote array
devices. This is done at an appropriate time when a short
interruption in running the production applications can be tolerated.
The Symmetrix Integration Utilities (SIU, available with Solutions
Enabler) integrates and extends the Windows 2003 and Windows
2008 disk management functionality to better operate with EMC
Symmetrix business continuance storage devices. Data migration
using Open Replicator can also take advantage of this functionality
with support specifically for Windows servers by extending their
ability to:
Mount and unmount hard disks and their associated file systems
Flush file system cache buffers to disk
Manipulate disk signatures
Scan the drive connections and discover any new disks available
to the system
The SIU includes the symntctl command to execute the needed
functionality. Once the production applications are stopped, the
remote source volumes will no longer be used and are unmounted.
The symntctl umount command:
Obtains an exclusive lock on that volume from the operating
system, which will fail if another application is still using the
drive
Performs a file system flush as part of the dismount process
Flags the drive as permanently dismounted (offline) until a
subsequent mount operation. This ensures that no other
applications can access the volume while it is being unmounted,
thus ensuring data integrity during migration operations.
Migration step 9: Stop the applications 137
For example, the following symntctl commands can be used to
unmount drives L through 0:
c:\>symntctl umount -drive L:
Successfully unmounted the volume.
c:\>symntctl umount -drive M:
c:\>symntctl umount -drive N:
c:\>symntctl umount -drive O:
c:\>
Additionally, to ensure that the original source volumes will not
become visible on a subsequent rescan or reboot, the LUN masking
for each volume needs to be removed. This is done by issuing a set of
commands that look like this:
c:\>navicli -h Clar0031_SPA storagegroup -removehlu -gname D194 -hlu 00 -o
c:\>
Migration step 10: symrcopy activate
The activate action sets the point-in-time for the pull of data from
the remote to the control. In this hot pull example, there is no need for
consistency options, as the applications were stopped and the disk
cache was flushed thereby ensuring consistency. Notice that after the
activate, the Status changes to CopyinProg(ress) and the
Protected Tracks counts decrease as tracks are copied to the
control.
c:\>symrcopy -session_name hot_pull activate
with session name 'hot_pull' (y/[n]) ? y
with session name 'hot_pull'. Please wait...
with session name 'hot_pull'.
c:\>symrcopy -session_name hot_pull query
Session Name : hot_pull
---------------------------- ------------------------- ----- -------------- ----
Protected
------------------ --------- ---------------------- -- ----- -------------- ----
000190300359:0094 32757 HK190807410004:00003 CD X..XX CopyInProg 0
Total ---------
Track(s) 131032
MB(s) 8189.5
Legend:
Flags:
c:\>
Migration step 11: Restart applications using targets 139
Migration step 11: Restart applications using targets
Now that the data copying has begun, production applications can be
restarted immediately without waiting for the copy to complete. If an
attempt is made to access data not yet copied, then it will be copied
(COFA) immediately. Copying all of the data from the source devices
to the targets includes copying information about the 2 GB original
size of the source devices. The symntctl update command can be
used to update the partition information to include the additional
space that actually exists on the target devices:
c:\>symntctl rescan
Device rescan in progress...
Device rescan completed successfully.
c:\>symntctl update -pd \\.\PHYSICALDRIVE6
Successfully updated device partitions.
c:\>
Figure 23 illustrates the updated partition information presented in
Disk Management that shows the 2.01 GB of additional unallocated
space for each disk. Since the disks have not yet been mounted, all of
the allocated partition information is shown as being Free Space.
Figure 23 Disk Management display of target devices additional space
ICO-IMG-000546
The symntctl mount command is used now to mount the target
devices using the same drive letters as the source devices had used,
so production applications that use the filesystems will now access
the data on the target devices.
c:\>symcfg discover -all
c:\>symntctl mount -drive L: -sid 359 -symdev 91
Successfully mounted the volume.
c:\>symntctl mount -drive M: -sid 359 -symdev 92
c:\>symntctl mount -drive N: -sid 359 -symdev 93
c:\>symntctl mount -drive N: -sid 359 -symdev 94
c:\>
The DiskPart utility is used to extend the allocated disk partition to
use the unallocated space, so that all 4 GB of space can be used by
applications. For example:
c:\>diskpart
Microsoft DiskPart version 5.2.3790.3959
Copyright (C) 1999-2001 Microsoft Corporation.
On computer: LICOD194
DISKPART> select disk 6
Disk 7 is now the selected disk.
DISKPART> list partition
Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 Primary 2039 MB 32 KB
DISKPART> select partition 1
Partition 1 is now the selected partition.
DISKPART> extend
DiskPart successfully extended the volume.
DISKPART> extend
DISKPART> extend
DISKPART> extend
DISKPART> exit
Leaving DiskPart...
c:\>
Figure 24 illustrates the updated display from Disk Management
showing the extended 4 GB partitions (no longer the original 2 GB).
Figure 24 Disk Management updated display showing 4 GB partitions
ICO-IMG-000547
Migration step 13: symrcopy query and verify
completes copying all of the tracks from the remote devices to the
control devices. Once this is done, the original source devices are no
longer needed. The query action will report the Status and the
decreasing number of Protected Tracks, and the increasing Done
percent. Using the verify action allows scripts to wait for a
particular status:
c:\>symrcopy -session hot_pull query
Session Name : hot_pull
---------------------------- ----------------------- ----- -------------- ----
Protected
------------------ --------- -------------------- -- ----- -------------- ----
Total ---------
Track(s) 129659
MB(s) 8103.7
Legend:
Flags:
c:\>symrcopy -session hot_pull verify -copied -i 300 -c 36
None of the session(s) with name 'hot_pull' are in 'Copied' state.
None of the session(s) with name 'hot_pull' are in 'Copied' state.
. . .
All session(s) with name 'hot_pull' are in 'Copied' state.
c:\>
Migration step 15: Verify migration and terminate 145
Migration step 15: Verify migration and terminate
Because this is a hot pull, production applications are already using
the target devices, in effect verifying the validity of the copied data.
However, if any application specific verification of the migration is
desired, it must be completed before terminating the Open
Replication copy sessions along with the donor update feature that
keeps the original source updated with all changes since the
production applications began using the targets. Once the validation
is complete, the Open Replicator sessions are no longer needed and
can be terminated by executing a set of commands that look
something like the following:
c:\>symrcopy -session hot_pull terminate
The specified action is not allowed without the force flag because the control device has a
session with donor update enabled
c:\>symrcopy -session hot_pull set donor_update off -consistent
Execute 'Set Donor Update Off' operation for the 4 specified devices
'Set Donor Update Off' operation execution is in progress for the device list with session
name 'hot_pull'. Please wait...
'Set Donor Update Off' operation successfully executed for the device list with session name
'hot_pull'.
c:\>symrcopy -session hot_pull terminate
with session name 'hot_pull'.
c:\>
Cleanup step 19: Redeploy the source devices
Because this example is a hot pull, the key cleanup steps of
redirecting production applications to access the target devices in
place of the source devices were completed in Migration step 11:
Restart applications using targets on page 139. Step 19, redeploy the
source devices storage, is the only step remaining in the cleanup
phase.
Hot Pull from Symmetrix Migration Example 147
7
This chapter details using Symmetrix Management Console (SMC) as
the management tool to manage an Open Replicator hot pull. As
another hot pull example, the required steps match the example in
Chapter 6, Hot Pull from CLARiiON Migration Example, with the
small difference being that the remote storage array is a Symmetrix.
The topics covered include:
Introduction ...................................................................................... 148
Setup step 3: Configure migration device masking.................... 157
Setup step 4: Configure target zoning and LUN masking......... 173
Setup step 5: Prepare Open Replicator session pairs file ........... 174
Setup step 6: Verify completion of setup steps ............................ 178
Migration step 9: Stop the applications ........................................ 182
Migration step 10: Open Replicator activate................................ 185
Migration step 11: Restart applications using targets................. 187
Migration step 12: Tune migration ............................................... 189
Migration step 13: Check status, wait until copied..................... 191
Migration step 15: Verify migration and terminate .................... 192
Cleanup step 19: Redeploy the source devices............................ 194
Hot Pull from Symmetrix
Migration Example
Hot Pull from Symmetrix Migration Example
Introduction
This chapter details a hot pull migration example using Symmetrix
Management Console (SMC) on a Windows host. This example is
very similar to the hot pull example in Chapter 6, Hot Pull from
CLARiiON Migration Example, requiring the same steps to be
completed. This example will highlight the use of SMC for the
completion of the steps; the remote storage array is a Symmetrix, so all
the required device (LUN) masking can also be completed from
within SMC.
Hot pull setup steps
Since this is a hot operation, all Symmetrix FA ports that are mapped
by the control devices must be zoned and LUN masked to "see" the
remote devices. In this example all zoning and masking requirements
will be met in the setup steps, including using SMC Remote Report to
verify completion. The definition of Open Replicator session pairs
can be completed in an SMC wizard dialog and the actual creation of
a file is optional. The six hot pull setup steps are:
FA host ports.
3. Configure LUN masking for remote devices to allow access
host ports.
devices.
5. Prepare Open Replicator session pairs file step can be
completed by a selection process in SMC with or without the
creation of an actual file.
Replicator session.
Introduction 149
Hot pull migration steps
This chapter will detail an example of six migration steps applicable
for a hot pull. The step 12 optional tuning action, which is applicable
for all migrations types, will be detailed again in order to illustrate
the SMC interface for tuning Open Replicator. The six hot pull
migration steps detailed are:
9. Stop the production application.
11. Restart the application pointing to the target (control) devices.
12. (optional) Tune migration to acceptable level of impact on
production applications.
Hot pull cleanup step
In the case of hot pull, applications are altered to access data from the
target devices before data movement is complete. Therefore, the first
three cleanup steps are completed in the setup phase. That leaves
only a single step in the cleanup phase, step 19: to redeploy the source
devices storage once the migration is complete.
Figure 25 on page 150 illustrates the hot pull setup, migration, and
cleanup steps in a flowchart. The non-applicable step 14, iterative
incremental update for push sessions, and the three non-applicable
cleanup steps (steps 1618) are omitted from the flowchart entirely to
avoid unnecessary complexity.
Figure 25 Symmetrix hot pull setup, migration, and cleanup flowchart
ICO-IMG-000548a
storage
impact level
cluster, create
terminate OR
13. Verify OR copy
done
Hot pull?
Need tuning?
target devices
10. OR activate
Pull?
Hot pull?
Hot pull?
Push?
Create not run?
Y
Y
Y
Y
Y
Y
N
N
N
N
N
N
N
6. Verify setup
pairs (file)
3. LUN mask remote
devices to DMX FA
2. Zone DMX FA
control to remote array
target devices
Y
N
7. Split the BCV
Cold push
from BCV, clone
or VDEV?
Y
For this pull example, the target (control) devices are devices 9598 on
the Symmetrix DMX 000190300359 array. Figure 26 illustrates the
use of the Device Properties display for these devices.
Figure 26 SMC properties for Symmetrix 000190300359 devices 9598
ICO-IMG-000549
This example uses a different remote array than in previous examples
so new migration zones need to be set up. The zones will include the
control Symmetrix VMAX (or Symmetrix DMX) FA ports, that act as
open systems host initiators and the remote Symmetrix storage array
FA ports where the remote devices are mapped.
Determining control director World Wide Port Names (WWPNs)
Figure 27 illustrates a display of device properties that can be used to
determine the control device FA directors. The # Paths column
indicates that each of the control devices is mapped to two paths.
Selecting device 95, displays the properties detail. Selecting the FBA
Front End Paths tab reveals that directors FA-2C port 0 and FA-15C
port 0 are the FA control ports.
Figure 27 SMC Front End Paths detail for control target device 95
Navigating to the first FA director 2C port 0 provides the display of
the WWN for the port. Figure 28 on page 153 illustrates the
properties for director 2C port 0 including the WWN.
ICO-IMG-000550
Figure 28 SMC director 2C port 0 properties showing the port WWN
Figure 29 illustrates the properties for the control devices other
mapped director 15C port 0.
ICO-IMG-000551
ICO-IMG-000552
Determining Remote Storage Array WWPN(s)
The remote storage array for this example is Symmetrix
000187720450. Figure 30 illustrates a display of the directors that
remote source device 141 is mapped to in the device detail FBA Front
End Paths tab.
Figure 30 SMC Front End Paths detail for remote source device 141
Navigating to the first FA director 8C port 0 provides the display of
the WWPN. Figure 31 on page 155 illustrates the properties for
director 8C port 0 including the WWN.
ICO-IMG-000553
Figure 32 on page 155 illustrates the properties for the remote devices
other mapped director 9C port 0.
ICO-IMG-000554
ICO-IMG-000555
Configuration of migration SAN zones
For the hot pull, it is necessary to zone all directors mapped to the
control device due to each director handling Copy on First Access
(COFA). In this example, two independent zones are defined for best
performance: one zone between control 2C:0 and remote 8C:0, and a
second zone between control 15C:0 and remote 9C:0.
Figure 33 is an excerpt from the Connectrix Manager verification
screen that illustrates the activation of two migration zones that have
been added to the active zoneset for the hot pull between the two
Symmetrix arrays.
Figure 33 Connectrix Manager activate Symmetrix hot pull zones
ICO-IMG-000556
Setup step 3: Configure migration device masking 157
Setup step 3: Configure migration device masking
Application source device references
The application for this example uses Windows drive letters P, Q,
R, and S that reside on the remote Symmetrix source devices. Using
Windows Disk Management, it can be seen in Figure 34 that drives P,
Q, R, and S correspond to disks 2932.
Figure 34 Disk Management display of remote source drives P, Q, R, and S
ICO-IMG-000557
Add Symmetrix device masking
Because the Symmetrix VMAX (or Symmetrix DMX) FA hosts are
connected to the remote storage array on switched fibre ports, it is
necessary to perform LUN masking to grant the Symmetrix VMAX
(or Symmetrix DMX) FA initiator access to the remote devices. This
LUN masking is performed with tools specific to the remote storage
array, that in this case is a Symmetrix and is called device masking.
Since the remote Symmetrix is only remote in terms of Open Replicator
but is local in the sense of presenting host visible devices, SMC can be
used to complete the device masking. Figure 35 illustrates invoking
the Device Masking Menu after right clicking the remote Symmetrix
array (Device Masking and Mapping > Masking).
Figure 35 SMC Device Masking menu
Figure 36 on page 159 illustrates the SMC device masking dialog. The
dialog begins with the selection of the remote Director Port FA-8C:0
and the control Director Port that is acting as the initiator WWN
5006048AD5F031C1 (FA-2C0). The list of Available Devices was
filtered by Dev Config = 2-Way Mir and Cap(acity) = 4096 MB. The
four remote devices 141144 were moved to the masking Target list by
clicking the Add button. Notice the checkbox for refreshing the
VCMDB after the Apply/OK is checked. When checked, the refresh
will occur automatically.
ICO-IMG-000558
Figure 36 SMC add device masking for remote devices 141144 on FA-8C:0
SMC presents a confirmation dialog that is used to report on the
success of invoking control actions. Figure 37 illustrates the Success
confirmation for the device masking operation.
Figure 37 SMC device masking success confirmation dialog
ICO-IMG-000559
ICO-IMG-000560
Because this is a hot pull, masking must be defined on all paths.
Figure 38 illustrates the SMC device masking dialog adding access
for WWN 5006048AD5F031CE (control FA-15C:0) to remote devices
141144 on remote director port FA-9C:0.
Figure 38 SMC add device masking for remote devices 141144 on FA-9C:0
Symmetrix VMAX device masking using Auto-provisioning groups
Conceptually, adding Symmetrix VMAX device masking is the same
as shown for Symmetrix DMX in Add Symmetrix device masking,
on page 158. A parallel example using the SMC 7.1 Task Masking
Wizard will be shown in this section.
ICO-IMG-000561
Auto-provisioning Groups
The Auto-provisioning Groups feature was introduced in Solutions
Enabler 7.0 and Symmetrix Management Console (SMC) 7.0. It
provides an easier, faster way to provision storage in Symmetrix
VMAX arrays running Enginuity 5874. Most of the applications
running on Symmetrix arrays require a fault-tolerant environment
with clustered hosts as well as multiple paths to devices.
Auto-provisioning Groups was developed to make storage allocation
easier and faster, especially with these types of configurations.
Mapping and masking devices in previous versions of Solutions
Enabler required a separate command for each initiator/port
combination through which devices would be accessed. Both the
symaccess command in Solutions Enabler and SMC allow the user
to create a group of devices (storage group), a group of director ports
(port group), and a group of host initiators (initiator group), and
associate them in a masking view. When the masking view is created,
the devices are automatically mapped and masked.
After the masking view is created, any objects (devices, ports, or
initiators) added to an existing group automatically become part of
any associated masking view(s). This means that no additional steps
are necessary to add additional devices, ports, or initiators to an
existing configuration. All necessary operations to make them part of
the configuration are handled automatically by Symmetrix Enginuity
once the objects are added to the applicable group. This reduces the
number of commands needed for mapping and masking devices and
allows for easier storage allocation and de-allocation.
The examples presented in this TechBook using symmask,
symmaskdb and SMC Device Masking are not applicable for
Symmetrix VMAX systems running Enginuity 5874. Solutions
Enabler 7.0 introduces the symaccess command to manage
Auto-provisioning Groups and includes parallel commands to
symmask for actions like list logins and list hba. SMC 7.0
introduces new menu items and dialogs for managing
Auto-provisioning Groups, including Storage Groups Maintenance,
Port Groups Maintenance, Initiator Groups Maintenance, and
Masking Views Maintenance.
For more information and examples see the Storage Provisioning With
EMC Symmetrix Auto-provisioning Groups Technical Note.
SMC Task Masking Wizard
Auto-provisioning can be invoked using multiple SMC menus to
create an Initiator Group, a Port Group, a Storage Group and a
Masking View to associate the three together. SMC also now supplies
task interfaces to more easily sequence these multiple steps without
having to know each menu to invoke and in what order. Figure 39
illustrates selecting the Masking Wizard from the Tasks view.
Figure 39 SMC Tasks Masking Wizard selection
ICO-IMG-000764
Figure 40 illustrates the Masking Wizard step 1 welcome screen that
lists the sequence of steps that the wizard will lead you through and
the information that you will need to provide.
Figure 40 Masking Wizard step 1 welcome screen
ICO-IMG-000765
Figure 41 illustrates the Masking Wizard step 2 that is used to create a
masking view for the selected Symmetrix.
Figure 41 Masking Wizard step 2 create masking view
ICO-IMG-000766
Figure 42 illustrates part of Masking Wizard step 3 where the Create
button is clicked to create a new Initiator Group.
Figure 42 Masking Wizard step 3 click to create Initiator Group
Figure 43 on page 167 illustrates the create Initiator Group dialog.
The group is given the name OR1724_10E0_10F0 reflecting Open
Replicator, the last four digits of the Symmetrix ID and the two FA
directors that will be acting as host HBAs to the local Symmetrix
1715. The values displayed as Available Initiators are present only
after an attempt to create the Open Replicator session is invoked. The
attempt causes the FAs to log in on the fabric even though the Open
Replicator create fails due to the missing LUN masking that is still
being set up.
ICO-IMG-000767a
The FA WWN display on the control Symmetrix shows the WWNs
for 10E0 and 10F0 that will be selected:
symcfg -fa all list
Symmetrix ID: 000192601724 (Local)
Dir Port WWN ACLX Volume Set Pnt to
Enabled Addressing
FA-7E 0 50000972081AF118 Yes No Yes
FA-7E 1 50000972081AF119 Yes No Yes
FA-10E 0 50000972081AF124 Yes No Yes
FA-10E 1 50000972081AF125 No No Yes
FA-7F 0 50000972081AF158 Yes No Yes
FA-7F 1 50000972081AF159 No No Yes
FA-10F 0 50000972081AF164 Yes No Yes
FA-10F 1 50000972081AF165 No No Yes
Figure 43 Masking Wizard step 3 Initiator Group creation
After the Add button is clicked, the two selected initiators move from
the Available to the Selected display. Clicking the OK ends this dialog
returning to Masking Wizard step 3 where clicking the Next button
moves to step 4.
Figure 44 on page 168 illustrates Masking Wizard step 4 selecting the
ports. In this example, the Select button was clicked to bring up the a
display of existing Port Groups. The Port Group 7e0_10e0_p
already exists for the two ports that the Open Replicator remote
devices are mapped to and is highlighted when clicked on.
Expanding the group displays the two FA ports 7E0 and 10E0. where
the Create button is clicked to create a new Initiator Group. Clicking
the OK button ends the select dialog returning to Masking Wizard
step 4.
ICO-IMG-000767b
Note: Unlike the previous example for Symmetrix DMX device masking,
using Auto-provisioning groups, it is not necessary to repeat the dialog for a
second (or third, or fourth etc.) port. Simply adding multiple ports to the Port
Group completes masking for all of the ports.
Figure 44 Masking Wizard step 4 select existing Port Group
Clicking the Next button moves on to the next step in the wizard.
ICO-IMG-000768
Figure 45 illustrates part of Masking Wizard step 5. Click the Create
button to open a dialog box to create a new Storage Group made up
of the Open Replicator remote devices.
Figure 45 Masking Wizard step 5 click to create Storage Group
ICO-IMG-000769a
Figure 46 illustrates the Storage Group create dialog. The Storage
Group name ORremoteTO1724 is defined. After selecting the Device
Source Type as Symmetrix, the hundreds of available devices were
filtered by clicking the filter button and selecting the specific size of
4097 MB devices. The Add All button is clicked to move the devices
from the Available Devices display to the Group Members display.
Figure 46 Storage Group creation dialog box
Clicking OK will return to Masking Wizard step 5, where clicking the
Next button will move to step 6.
Note: The value of the Auto-provisioning masking methodology can be
stressed by pointing out that to add additional devices to the Masking View
that is being defined, the only step required will be to modify the storage
group by adding the additional devices. Once that is done the devices will be
visible on all defined ports to all of the defined initiators.
ICO-IMG-000769b
Figure 47 illustrates Masking Wizard step 7 that displays a summary
of all previous steps to define the Masking View. Clicking the Finish
button ends the wizard and creates the Masking View completing the
masking definition.
Figure 47 Masking Wizard step 7 summary
ICO-IMG-000770
Figure 48 illustrates the Masking Wizard success dialog that displays
after the progress bar confirming successful creating of the new
Masking View.
Note: The progress dialog for the Masking View creation can take longer than
Symmetrix DMX users may be accustomed to. This is due to the fact that with
Enginuity 5874, masking creation will automatically map devices to the ports
that are being masked if they are not already mapped.
Figure 48 Masking Wizard success dialog
ICO-IMG-000771
Setup step 4: Configure target zoning and LUN masking 173
Setup step 4: Configure target zoning and LUN masking
The current example is a hot pull. A hot pull moves the zoning and
masking the target devices step from the cleanup phase to the setup
phase, because the application will be accessing the target devices
from the start.
Target devices 9598 are already correctly mapped and device
masked host visible devices as shown by the Physical Device Name
displayed in the properties device detail in SMC. Figure 49 illustrates
the properties detail for control target device 95 showing host Physical
Device Name .\PHYSICALDRIVE15.
Figure 49 SMC properties device detail for control target device 95.
Similarly, the displays for target devices 9698 show Physical Device
Names .\PHYSICALDRIVE1618.
ICO-IMG-000562
Setup step 5: Prepare Open Replicator session pairs file
The SMC Open Replicator Create Copy Session wizard consists of
five pages that include the definition of the session control-remote
pairs. Figure 50 illustrates invoking the Create Copy Session menu by
right-clicking the control Symmetrix in the navigation tree
(Replication > Open Replicator > Create Copy Session).
Figure 50 SMC Open Replicator Create Copy Session menu
The first page of the wizard provides for the setting of session
parameters. In this example, the parameters are defined as a hot pull
session. The Device Selection default Customize radio button option
will use an additional three wizard pages to select the control and
remote device pairs. If previously saved to a file, it is possible to read
in a pairs file as well as to manually edit the pair definitions and skip
to page five of the wizard. Figure 51 on page 175 illustrates the
setting of a session as a hot pull session using the Customize method
to specify the pair definitions.
ICO-IMG-000563
Figure 51 SMC Create Copy Session page 1: Set session parameters
The second page provides for selecting the control devices. Figure 52
illustrates the selection of devices 9598 and filtering the Available
Devices to see only devices that have been mapped to director FA-2C
port 0 and have a capacity of 4096 MB.
Figure 52 SMC Create Copy Session page 2: select control devices
ICO-IMG-000564
ICO-IMG-000565
The third page provides for selecting the remote devices. Figure 53
illustrates the selection of devices 141144 and filtering the Available
Devices to see only devices that have been zoned and masked on
Symmetrix 000187720450 director FA-8C port 0. This page of the
wizard only presents devices that are correctly zoned and LUN
masked offering a verification of correct setup even before invoking
the Open Replicator create action. The WWN radio button on this
page can be selected to manually add WWN formatted remote devices
that may not yet be correctly zoned and LUN masked.
Figure 53 SMC Open Replicator page 3: Select remote devices
ICO-IMG-000566
The fourth page provides for pairing the control and remote devices.
Figure 54 illustrates adding the pairing of control device 98 with
remote device 144.
Figure 54 SMC Create Copy Session page 4: Select device pairs
ICO-IMG-000567
Confirm hot pull setup with successful create
The fifth page of the Open Replicator wizard provides for setting
additional create options including enabling background Copy and
Donor Update. Before clicking the Finish button to invoke the create
operation, the Save button can be clicked to save the pair definitions
in a file that can be read and edited on page one of the wizard as an
alternate to defining pairing on pages two through four. Figure 55
illustrates setting Copy and Donor Update, and then initiating the
create operation.
Figure 55 SMC Create Copy Session page 5: Set session options and execute
ICO-IMG-000568
Similar to the prompt confirmation encountered when using the
Solutions Enabler symrcopy command, there is a confirmation
screen in SMC that gets displayed before any control action is
invoked. Figure 56 illustrates how to confirm the execution of the
Open Replicator Create action.
Figure 56 SMC Confirm Open Replicator create execution
Figure 57 illustrates the Create Copy Session success dialog box. For
the rest of the control actions in this chapter, the dialogs for control
action confirmation and success will not be shown.
Figure 57 SMC Create Copy Session success dialog box
ICO-IMG-000569
ICO-IMG-000570
SMC Remote Report
With SMC, the equivalent of symsan is checked as part of selecting
remote devices in the wizard. The SMC Remote Report provides an
explicit way of looking at this information from within SMC without
having to invoke the Create Copy Session wizard. Figure 58
illustrates invoking the Remote Report menu with an initial right
click of the control Symmetrix VMAX (or Symmetrix DMX) array, and
selecting
Replication > Open Replicator > Remote Report.
Figure 58 SMC Remote Report menu selection
ICO-IMG-000571
Remote Report has two tabs. Figure 59 illustrates the Remote Ports
tab, which shows information similar to the symsan -sanports
display for director FA-2C port 0.
Figure 59 SMC Remote Report Remote Ports tab
Clicking on the Remote Luns tab then selecting control director FA-2C
Port 0, and then selecting the Port WWN 5006048ACC18C087 for
remote Symmetrix 000187720450 FA-8C:0 confirms remote devices
141144 are accessible. Figure 60 illustrates the Remote Luns tab
display:
Figure 60 SMC Remote Report Remote Luns display
ICO-IMG-000572
ICO-IMG-000573
Migration step 9: Stop the applications
Since this example is a pull migration, it is necessary to stop
production applications that are using the remote source devices
(drives PS), in order to fix a point-in-time for the remote array
devices. This is done at the appropriate time when a short
interruption in running the production applications can be tolerated.
As in Migration step 9: Stop the applications on page 136 the
Symmetrix Integration Utilities (SIU) symntctl command is used to
unmount the source drives.
c:\>symntctl umount -drive P:
c:\>symntctl umount -drive Q:
c:\>symntctl umount -drive R:
c:\>symntctl umount -drive S:
c:\>
Migration step 9: Stop the applications 183
Additionally, to ensure that the original source volumes will not
become visible on a subsequent rescan or reboot, the device masking
for the volumes needs to be removed.
Figure 61 shows removing the device masking for remote source
devices 141144 for Windows host HBA WWN 10000000c97111fc
from director FA-8C:0.
Figure 61 SMC Removing device masking for devices 141144 for FA-8C:0
ICO-IMG-000574
After clicking Apply to make the masking change, and clicking OK in
the success dialog, the same change is made to the second path for
the source devices.
Figure 62 shows removing the device masking for remote source
devices 141144 for WWN 10000000c971196e from director FA-9C:0.
Figure 62 SMC Removing device masking for devices 141144 for FA-9C:0
ICO-IMG-000575
Migration step 10: Open Replicator activate 185
Migration step 10: Open Replicator activate
Once the Open Replicator session is created, it can be selected in the
SMC navigation tree by expanding Replication Views and then
expanding Open Replicator Sessions. The Properties view displays
status equivalent to the symrcopy query command. In this case
control devices 9598 are paired with remote devices 141144 and the
state is Created. Right clicking on the session name in the navigation
tree can be used to bring up the Open Replicator Session Control
menu.
Figure 63 illustrates the Open Replicator session navigation tree
selection, properties view and Session Control menu selection
(Replication > Open Replicator > Session Control).
Figure 63 SMC Open Replicator session properties and control menu
The SMC Session Control dialog, provides for selection of the desired
action. At this point, the Activate action is selected to set the
point-in-time for the pull of data from the remote to the control. In
this example of a hot pull, there is no need to click the Consistent
checkbox option, as the applications were stopped and the disk cache
ICO-IMG-000576
was flushed ensuring consistency. Since SMC uses the same dialog to
invoke an operation on single or multiple devices, it is necessary to
select the device pairs that should be affected by the chosen action.
Figure 64 illustrates the selection of the Activate action for Open
Replicator session symm_hot_pull affecting all four device
control-remote device pairs.
Figure 64 SMC Open Replicator activate
After the activate, the State has changed to CopyinProg(ress) and the
Prot(ected) Tr(ac)ks have started to be decremented as tracks have
copied over to the control. Figure 65 illustrates the change in status
after an activate operation is performed.
Figure 65 Open Replicator session properties after activate
ICO-IMG-000577
ICO-IMG-000578
Migration step 11: Restart applications using targets
Now that the data copying has begun, production applications can be
restarted immediately without waiting for the copy to complete. If an
attempt is made to access data that has not yet been copied, then that
data will be copied immediately (COFA). In this example the remote
and control devices are the same capacity, but have a different disk
geometry because the remote Symmetrix array is a DMX-2 and the
control Symmetrix array is a DMX-3. The Windows host operating
system has no problem with this change. However, Solaris requires
some extra steps to handle this difference that can be found on
Powerlink in the EMC Enginuity 5773 Flexible Device Geometry in a Sun
Solaris Environment Technical Note.
As previously explained, the symntctl command is used to rescan
for devices and update the control target device partitions:
c:\>symntctl rescan
Device rescan in progress...
Device rescan completed successfully.
c:\>
The symntctl mount command is used to mount the target devices
using the same drive letters that the source devices used, so
production applications that use the filesystems will now access the
data on the target devices.
c:\>symntctl mount -drive P: -sid 359 -symdev 95
c:\>symntctl mount -drive Q: -sid 359 -symdev 96
c:\>symntctl mount -drive R: -sid 359 -symdev 97
c:\>symntctl mount -drive S: -sid 359 -symdev 98
c:\>
Figure 66 illustrates the updated display from Disk Management
showing the volumes PS now based on the target devices.
Figure 66 Disk Management display of drives PS on the target devices
ICO-IMG-000579
Migration step 12: Tune migration 189
Migration step 12: Tune migration
The ability to set and change the pace and ceiling options is equivalent
in SMC as when using the symrcopy command. Figure 67 illustrates
invoking the Set Ceiling menu by first right clicking the control
Symmetrix array (the ceiling option affects all Open Replicator
sessions), and then Replication > Open Replicator > Set Ceiling.
Figure 67 SMC Select Open Replicator Set Ceiling Menu
ICO-IMG-000580
The Set Ceiling dialog provides for selecting the Director and Port
individually, or selecting the ALL option for either or both (to select
multiple ports). Figure 68 illustrates setting the Ceiling percentage to
30 for Director FA-2C Port 0.
Figure 68 SMC Open Replicator Set Ceiling
ICO-IMG-000581
Migration step 13: Check status, wait until copied 191
Migration step 13: Check status, wait until copied
completes copying all of the tracks from the remote devices to the
control devices. Once this is done, the original source devices will no
longer be needed. The SMC Refresh View button can be clicked to
update the properties display for the Open Replicator session. This is
one way to see the decreasing number of Protected Tracks, and
the increasing
% Complete.
Figure 69 illustrates clicking the Refresh View button and the
Open Replicator session properties with the default column
positioning reordered to display the columns of most interest without
horizontal scrolling.
Figure 69 SMC Open Replicator session properties Refresh View update
ICO-IMG-000582
Migration step 15: Verify migration and terminate
Once the replication is complete, the State will change to Copied.
Figure 70 illustrates all pairs in the session in the Copied state.
Figure 70 SMC Open Replicator session properties showing Copied state
ICO-IMG-000583
Migration step 15: Verify migration and terminate 193
Because SMC is a GUI and is not used in scripting, there is no direct
equivalent of the symrcopy verify command. However, as an
intelligent GUI, the available (non-grayed) drop-down menu Action
options displayed in the Open Replicator Session Control dialog
reflects which actions are valid for the current session state.
Because this is a hot pull, the production applications are already
using the target devices, in effect verifying the validity of the copied
data. However, if any application specific verification of the
migration is desired, it must be completed before terminating the
Open Replication copy sessions along with the donor update feature
that keeps the original source updated with all changes since the
production applications began using the targets. Once the validation
is complete, the Open Replicator sessions are no longer needed and
can be terminated.
Figure 71 illustrates turning off the donor update feature (notice that
the flags in the final U position of the CDSHU flags shows an X for
enabled donor update).
Figure 71 Donor Update Off SMC Session Control dialog box
ICO-IMG-000584
Figure 72 illustrates invoking the Terminate action from the SMC
Session Control dialog. Notice that the flags in final U position of the
CDSHU flags now shows an . for disabled donor update.
Figure 72 Terminate SMC Session Control dialog box
Following the Terminate action confirmation and the Terminate
success dialog, the navigation tree symm_hot_pull session
disappears from the Open Replicator Replication Views.
Cleanup step 19: Redeploy the source devices
Because this example is a hot pull, the key cleanup steps of
redirecting production applications to access the target devices in
place of the source devices was completed in Migration step 11:
Restart applications using targets on page 187. Step 19, redeploy the
source devices storage, is the only step remaining in the cleanup
phase.
ICO-IMG-000585
PowerPath Migration Enabler Overview 195
8
This chapter defines the benefits, terminology and operation of
PowerPath Migration Enabler (PPME). The setup, migration, and
cleanup phases are described using the set of steps first defined in
Basic Open Replicator migration operation flow on page 55.
Because the PPME interface and capabilities offer significant
simplification and enhancements, some steps are reordered, skipped,
merged together, or split apart; yet the basic flow is still
fundamentally the same. The topics covered include:
Introduction ...................................................................................... 196
Benefits of using PPME................................................................... 196
Nondisruptive migration overview.............................................. 197
Definitions......................................................................................... 199
PPME considerations and restrictions .......................................... 203
PPME with Open Replicator migration operation flow............. 204
Reference information..................................................................... 211
PowerPath Migration
Enabler Overview
PowerPath Migration Enabler Overview
Introduction
PowerPath Migration Enabler (PPME) is a hybrid migration solution
that provides the ability to perform nondisruptive migrations and
application cutovers while leveraging Open Replicator to actually
migrate the data. PPME benefits data migrations by greatly reducing
or eliminating application disruption due to the migration, reducing
migration risk, and simplifying migration operations.
When migrating data with PPME, the data continues to be accessible
to host applications while the migration takes place. Therefore,
application disruption is minimal or nonexistent. The level of
disruption depends on whether data is being migrated from a pseudo-
or a native-named device, and whether PowerPath is installed on the
host. If PowerPath has not been installed, then a disruption may be
required to install PowerPath.
Benefits of using PPME
Even if PPME cannot entirely eliminate application outages, it greatly
minimizes them and reduces data migration risk. Complex
migrations almost always will require certain setup activities for the
migration that may involve a host reboot. For example, a migration
requirement to update HBA drivers that requires a host reboot would
be executed in a scheduled maintenance window. The application
interruption necessary for installing PowerPath 5.x (a PPME
prerequisite) can also be scheduled to take place during normal
maintenance windows prior to the actual migratio? process. There is
a great difference between performing this type of activity as part of a
maintenance window and the more risky procedures that have to be
conducted when PPME is not used. One example of a risky procedure
not needed when PPME is used is the potentially catastrophic
cutover outage where a machine is shut down, a few configuration
changes are made, and the machine does not come back up without
issue (note that the risk of this type of outage can also be minimized
with careful planning and by using best practices). With PPME the
cutover task is fully verified before being performed and can
sometimes be conducted fully online. I/O redirection allows
administrators to preview deployment without committing to it. And
with PPME, in all cases, the data remains accessible to host
applications during the migration process.
Nondisruptive migration overview 197
Eliminating or even just reducing application downtime during a
migration greatly simplifies the planning for large-scale migrations.
Migration window flexibility is important to administrators because
it simplifies the migration planning process. Administrators do not
have to rely on others to follow their directions, nor do they need to
work off their shift, which is when migration data movement
operations are frequently scheduled. With PPME, the pressure to
correctly complete critical and complex migration tasks during
outages or off hours is reduced or eliminated.
PPME also greatly simplifies migration operations, hiding the
complexities of underlying migration products and integrating with
the host. This simplification is even more important in providing a
common interface across heterogeneous hosts, eliminating the host
specific knowledge required to perform key migration tasks. The
simplicity that PPME brings to migration operations may even allow
less skilled and less expensive staff to execute the work.
Nondisruptive migration overview
The PPME powermig command is used to interface with Open
Replicator. Open Replicator hot pull does the bulk data copying
between the arrays through the SAN. PPME keeps source and target
devices synchronized by cloning writes on the host. Mirroring the
two devices allows testing of the migration and returning to the
initial state with no downtime.
Figure 73 on page 198 illustrates an example of PPME Operation with
pseudo-named (location independent) devices and Open Replicator
where PPME swaps the pseudo-named devices in the middle so that
emcpower25c points to the target device instead of the source device
without any change required in the application.
Figure 73 PPME Operation with pseudo-named devices and Open Replicator
Application
emcpower25c
Data
RAID 1
Application
Data
RAID 1
Data
RAID 5
PowerPath Filter Driver
emcpower25c emcpower37c
SAN
Configure
target
pseudo
devices
Application
emcpower25c
Data
RAID 5
Complete
migration
and remove
old storage
OR Copy
ICO-IMG-000452
Definitions 199
Definitions
Pseudo or Native device name migrations
The operating system creates native devices to represent and provide
access to logical devices. A native device is path specific (as opposed
to path independent) and represents a single path to a logical device.
The device is native in that it is provided by the operating system for
use with applications. After migrating data from a native device
name, production applications must be reconfigured to use the new
target-device name, which is a minimally disruptive process.
Pseudo device names are location-independent names that represent a
single logical device and the path set leading to it. A
location-independent device name allows the migration of data
without requiring the reconfiguration of applications in order to use a
new logical unit. When data is migrated from one pseudo-named
device to another pseudo-named device, the migration can be
nondisruptive. The example in Chapter 9, PPME with Open
Replicator Migration Example, illustrates a migration from one
pseudo device to another.
Source and target
PPME uses the terms source and target to refer to the two endpoints of
a data migration. When Open Replicator hot pull is used for
migrations, the source LUNs are Open Replicator remote devices and
the target LUNs are control devices.
PPME Migration States
A migration session transitions through a number of states as
powermig commands are executed. Figure 74 on page 200 shows the
overall migration workflow, including the sequence of powermig
commands and the corresponding migration states. Numbers one
through eight in the graphic shown in Figure 74 depict the
commands involved in a normal migration workflow. The graphic
also shows the migration states from which you can enter the
powermig abort and powermig cleanup commands.
Figure 74 PPME Migration states and commands
Table 1 on page 201 describes the PPME Migration states when Open
Replicator is used as the underlying technology, along with the
relevant Open Replicator states.
powermig
cleanup
powermig
abort
powermig
cleanup
powermig undoRedirect
CommittedAndRedirected
powermig sync
powermig setup
powermig commit
Source is Pseudo
powermig
selectTarget
powermig
selectSource
Setup
Synching
SourceSelected
TargetSelected
Committed
ICO-IMG-000586
powermig commit
Source is Native
Source & target
synchronized
1
2
3
4 5
6
6
8
7
Definitions 201
Table 1 PPME Migration states
State Description
Setup A migration is in the Setup state after a powermig setup
command completes successfully. Before a migration can enter
this state, synchronization prerequisites must be met. When
Open Replicator is the underlying technology, all requirements
for the create action have been met and the Open Replicator
state is Created.
Syncing A migration enters the Syncing state when the powermig
sync command initiates a synchronization of the source and
target logical units. When Open Replicator is the underlying
technology, the bulk copy of data from the source to the target
is done in the SAN by Open Replicator in the CopyInProg
state. Application reads are from the source, writes are
mirrored to both source and target by PPME.
SourceSelected The migration enters the SourceSelected state once the
Open Replicator session has reached the Copied state (or after
powermig selectSource completes). Application reads are
still from the source, while writes continue to be mirrored to
both source and target by PPME.
TargetSelected The migration transitions to the TargetSelected state after
the powermig selectTarget command completes.
Application reads are now from the target, writes are still
mirrored to both source and target by PPME, making it
possible to return to the SourceSelected state.
CommittedAndRedi
rected
The migration enters the CommittedAndRedirected state
after the powermig commit command completes for a
native-named source device. Application reads continue from
the target via redirection, writes are no longer mirrored so it is
not possible to abort the migration. This is intended to be a
short lived temporary state, where production applications
must be stopped. Then the powermig undoRedirect
command is invoked to disable the redirection. Once
applications have been reconfigured to use the target device
paths, they can be restarted.
Committed The migration enters the Committed state after the powermig
commit command completes for a pseudo-named source
device or after the powermig undoRedirect command for a
native-named source device. Application reads continue from
the target, writes are not mirrored so it is not possible to abort
the migration.
PPME Abort, Cleanup, and Recover
A migration can be aborted with the powermig abort command
anytime after entering powermig sync and before entering the
powermig commit command. In other words, a migration can be
aborted while in the Syncing, SourceSelected, or
TargetSelected state. An aborted migration session returns to the
Setup state; from this state the migration can either be restarted
(powermig sync) or it can be cleaned up (powermig cleanup).
The purpose of cleanup is to ensure that production applications
and/or the operating system are not confused by identical data
residing on both the source and target LUNs. The powermig
cleanup command can be run while in the Committed or the
Setup state. When run while in the Committed state, selected data
on the source LUN is removed. When run while in the Setup state
(typically after an abort) selected data on the target LUN is removed.
After running this command, the source or target LUN from which
selected data has been removed will not mistakenly be read by the
host operating system.
The powermig recover command can be used to recover a
migration after an interruption occurs. Interruptions can result from a
migration error, a process crash, or a device fault. This command
should be run whenever the migration is in the NeedsRecovery
state. In the case of a migration error, the recovery may fail until the
cause of the error is identified and resolved. When the powermig
recover command completes successfully, the migration state
changes to the state to which the session was transitioning when the
interruption occurred.
PPME considerations and restrictions 203
PPME considerations and restrictions
The following restrictions apply to all host platforms when using
PPME:
PowerPath Migration Enabler does not support:
Migrating paging or swapping devices.
Migrating boot devices.
Uninstalling or upgrading PowerPath while a migration is in
progress.
The target LUN:
Must be the same size as or larger than the source logical unit
for Open Replicator migrations.
Cannot be under the control of a volume manager.
Cannot have I/O directed to it.
If the Migration Enabler host uses different HBAs to access the
source and target logical devices, the HBAs must be comparable
in every way (even different revisions of the same HBA are not
permitted).
LUNs involved in a migration should not be used as Symmetrix
gatekeeper devices because I/O redirection will cause gatekeeper
errors. Use of the Solutions Enabler gkavoid or gkselect files
can ensure that migration LUNs are not used as gatekeepers. The
EMC Solutions Enabler Symmetrix Array Management CLI Product
Guide contains more information about gatekeeper devices.
When migrating data to a target LUN that is larger than the
source LUN, the migration must be committed before gaining
access to space on the target that does not exist on the source.
Attempting to access that space when the migration is in the
TargetSelected state will result in I/O errors.
For Solaris hosts the powerformat utility can be used to
increase the size of a LUN by updating the ASCII and disk
label information. More information about powerformat can
be found in the EMC PowerPath Migration Enabler User Guide.
Requires the host be running PowerPath version 5.0 or higher.
PPME with Open Replicator migration operation flow
The eight steps in the normal PPME workflow introduced in
Figure 74 on page 200 will be listed and flowcharted using the 19
migration steps introduced in Basic Open Replicator migration
operation flow on page 55 even though steps that apply to cold or
push Open Replicator operations are not applicable. Correctly setting
up the underlying technology is crucial to the successful use of
PPME.
For this example using Open Replicator as the underlying
technology, the setup phase steps will directly parallel the previous
hot pull examples. The migration phase steps using Open Replicator
are fewer and simpler because PPME provides for skipping some
steps entirely and delays other steps to the cleanup phase. The
cleanup phase steps will be significantly redefined in order to
incorporate the change in order and greater functionally of PPME in
this phase.
Setup steps
The first four setup steps are required in order to set up Open
Replicator for hot pull operations and therefore fully apply when
using PPME with Open Replicator. For some operating systems, it
may be necessary to run explicit powermt commands to update the
PowerPath configuration after making the target devices visible to
the host. An additional sub-step is added to the fourth step, making
the first four setup steps now:
ports and Symmetrix VMAX (or Symmetrix DMX) control FA
host ports.
host ports.
4a. Configure host zoning and device (LUN) masking for target
devices.
4b. Update and save the PowerPath configuration.
PPME with Open Replicator migration operation flow 205
The powermig setup command effectively combines the fifth and
sixth setup steps, though there is no creation of an actual pairs file nor
a user made call to symrcopy create.
SMC GUI).
Replicator session.
Figure 75 PPME with Open Replicator setup steps flowchart
Migration steps
A PPME managed migration has fewer operational steps than a hot
pull migration solely under Open Replicator control. The ability of
PowerPath to redirect I/O allows for less impact on the production
applications and provides more flexibility as to when the migration
change is committed. For example, migration steps 9 and 11 that
briefly stop and restart applications with them pointing to the target
devices are no longer needed prior to the migration, because during
the migration copy, PPME directs all application reads from the
source device, and can transparently manage the redirection of the
application to the target devices after the data movement completes.
And because PPME provides a broader set of cleanup operations,
step 15 that consists of the verification of the migration and
termination of the Open Replicator session is postponed to that
phase. With PPME, the migration steps look like this:
10. powermig sync (activate the Open Replicator session)
ICO-IMG-000587
Hot pull?
5-6. powermig setup
[define source / target
pair, create OR session]
3. LUN mask remote
devices to DMX FA
to remote array
target devices
4a. Zone and device mask
4b. Update and save
PowerPath configuration
Y
N
application(optional)
13. powermig query (verify Open Replicator copy session is
finished)
Figure 76 PPME migration steps flowchart
Step 10 detail
Activating each Open Replicator session is accomplished by the
powermig sync command that initiates the copying from source to
target. Although this operation is performed as an Open Replicator
hot pull, with PPME the production applications are still reading
from the source devices rather than the targets. Additionally, the
session is not created with the donor update option enabled because
PPME mirrors all application writes to both source and target
devices.
Step 12 detail
As mentioned in Tuning Open Replicator, on page 63 the PPME
throttle mechanism is an alternate interface to the Open Replicator
pace parameter. However, the pace parameter is the secondary tuning
mechanism for Open Replicator. In order to use the primary tuning
mechanism, the ceiling value can be set using symrcopy set
ceiling or SMC Set Ceiling. The pace value is ignored for all
participating director/port combinations where the ceiling value is
not NONE (including PPME Open Replicator sessions).
ICO-IMG-000588
impact level
13. powermig query
[Verify OR copy done]
Need tuning?
10. powermig sync
[OR activate]
Y
N
N
Step 13 detail
The powermig query command is used to report back on the
progress of the background copying. Since the query action must
specify a single PPME handle, it only reports on a single
source/target pair. The powermig info -all -query command,
on the other hand can be used to report on all source/target pairs
under PPME control.
Cleanup steps
The cleanup steps when using PPME are simple, yet provide
extensive functionality and flexibility that reduce migration risk. The
cleanup step descriptions and ordering are different when PPME
uses Open Replicator, than when Open Replicator is used alone. The
final step of the migration phase and the four cleanup steps
introduced in Basic Open Replicator migration operation flow on
page 55 are:
15. Verify migration is complete and terminate Open Replicator
session.
16. Make the source devices inaccessible to the host
(optional, needed for all but hot pull operations).
17. Make the target devices ready to the host
18. Restart applications pointing to the target devices in place of
the original source devices
complete.
Even though PPME uses Open Replicator hot pull operations to do
the bulk data migration copying, the desired outcomes of steps 16
and 18 are part of the cleanup phase. That is because the switch to
having the production applications read from the target devices is
delayed until this phase.
The PPME commands that fulfill the purpose of steps 15, 16 and 18,
achieves the desired outcomes in different ways that are described in
the next five sections. Step 17 is skipped when using PPME because it
was already completed as step 4 in the setup phase (the same as when
Open Replicator hot pull is used without PPME). Step 19 is very
similar for all of the migration examples presented, though the source
devices can remain configured as visible to the host, since PPME
includes commands that avoid application or operating system
confusion that can be caused by seeing identical data residing on both
the source and target LUNs.
PPME switch application reading from source or target devices
PPME explicitly includes cleanup operations as part of its command
set. Unlike when using Open Replicator hot pull directly, when used
with PPME, production applications continue to read from the source
device during the migration movement of data. Once the bulk copy is
complete, mirroring to both source and target devices makes it
possible to switch back and forth between reading from source and
reading from target until all validation checks for the migration are
complete.
The SourceSelected state defines the condition when source and
target are synchronized and all application reads come from the
source. The PPME command powermig selectTarget can be
used to switch to the TargetSelected state. The
TargetSelected state defines the condition when source and
target are synchronized and all application reads come from the
target. The best practice is to conduct application specific migration
verification while in this state (the first half of step 15). The PPME
command powermig selectSource can be used to switch back to
the SourceSelected state. The ability to switch back and forth
between the source and target devices is performed transparently to
the production applications.
PPME transparently committing to the target devices
When using pseudo-named source devices and while in the
TargetSelected state, the PPME command powermig commit
can be used to switch to the Committed state. When this operation is
performed, production applications transparently continue to
operate using the target devices, that now use the pseudo-names
previously used for the source devices. Unlike the selectTarget or
SelectSource actions, the commit action is permanent because
write mirroring is stopped, making the source devices no longer valid
for production application use. This move of application processing
to the target devices effectively completes step 18 without any
application restart.
PPME cleanup of the source devices
While in the Committed state, the PPME command powermig
cleanup can be used to remove selected data from the source LUN.
This removal ensures that production applications or the operating
system are not confused by identical data residing on both the source
and target LUNs. Avoiding this potential confusion meets the
purpose of step 16 and can make step 19, redeploying the source
devices easier because they are still configured to be visible to the
host. The cleanup operation also terminates the Open Replicator
session, thereby completing the second half of step 15.
PPME commit for native-named source devices
When using native-named source devices, it is not possible to
transparently direct all production application I/O to the target
devices on a permanent basis. The native-names specifically reference
the physical path to the source devices and therefore cannot be used
to permanently reference different paths to the target devices.
When using native-named source devices and while in the
TargetSelected state, the PPME command powermig commit
can be used to switch to the CommittedAndRedirected state. With
this operation, the production applications transparently continue to
operate using the target devices, via temporary I/O redirection. The
commit action is permanent because write mirroring is stopped,
making the source devices no longer valid to use for production
applications. Applications can continue to run referencing the target
devices in this manner until it is convenient to briefly stop them. The
powermig undoRedirect command is then used to disable the
I/O redirection. Then, production applications must be reconfigured
to use the target device paths, and then be restarted. Cleanup of the
source devices should then be completed as described in PPME
cleanup of the source devices on page 209. This move of application
processing to the target devices effectively completes step 18.
PPME abort and cleanup of the target devices
At any time during the migration data movement or migration
validation testing, the powermig abort command can be executed
provided the commit operation has not been executed. The abort
operation leaves the migration in the Setup state, and from there the
migration can either be restarted or cleaned up. From the Setup
state, the PPME command powermig cleanup command can be
used to remove selected data from the target LUN. This removal
ensures that production applications and/or the operating system are
not confused by identical data residing on both the source and target
LUNs.
Reference information 211
Figure 77 illustrates the PPME cleanup steps as a flowchart. The
multiple parts of step 18 and notes referring to step 15 and16 appear
out of numeric order due to representing the PPME operational flow
using the step definitions for migration steps conducted without
PPME from Basic Open Replicator migration operation flow on
page 55.
Figure 77 PPME cleanup steps flowchart
Reference information
Additional details for PPME can be found in the EMC PowerPath
Migration Enabler User Guide. Users should upgrade to the latest
version in order to get the latest features and performance
improvements. Details of PPME support for pseudo and native
devices can be found in the E-Lab Interoperability Navigator
available on the Powerlink website (http://Powerlink.EMC.com).
ICO-IMG-000589
storage
18a. powermig selectTarget
migration check validation
(step 15, first half)
18b. powermig commit
18c. Stop applications
18d. powermig undoRedirect
16. powermig cleanup
avoid source device conflicts
OR terminate (step 15,

Abort?
Native-named
source devices?
N
N
Y
Y
Abort processing
detail not
included in this
flowchart
second half)
PPME with Open Replicator Migration Example 213
9
This chapter details a PPME with Open Replicator migration example
that uses the same arrays, hosts and devices as those used in
Chapter 7, Hot Pull from Symmetrix Migration Example. The
setup, migration, and cleanup steps defined for PPME in Chapter 8,
PowerPath Migration Enabler Overview,will be clarified by a
migration example. The topics covered include:
Introduction ...................................................................................... 214
PPME Setup steps 14 ..................................................................... 215
PPME Setup steps 56: powermig setup.................................. 215
Migration step 10: powermig sync ............................................ 220
Migration step 13: query status, until SourceSelected....... 222
Migration step 18a: powermig selectTarget....................... 224
Migration step 18b: powermig commit ..................................... 225
Migration step 16: powermig cleanup..................................... 227
Cleanup step 19: Redeploy source devices storage..................... 228
PPME with Open
Replicator Migration
Example
PPME with Open Replicator Migration Example
Introduction
This chapter details a PPME with Open Replicator migration example
that uses the same Windows host, source devices (141144) and target
devices (9598) as those used in Chapter 7. The applicable migration
steps defined for PPME in Chapter 8 apply for this example, so the
list of steps required to perform the migration is not repeated here.
However, the migration steps flowchart for all three phases is shown
in Figure 78 on page 214.
Figure 78 PPME with Open Replicator setup, migration, and cleanup steps
ICO-IMG-000594
storage
18a. powermig selectTarget
migration check validation
(step 15, first half)
18b. powermig commit
18c. Stop applications
18d. powermig undoRedirect
16. powermig cleanup
avoid source device conflicts
OR terminate (step 15,

Abort?
Native-named
source devices?
N
N
Y
Y
Abort processing
detail not
included in this
flowchart
impact level
13. powermig query
[Verify OR copy done]
Need tuning?
10. powermig sync
[OR activate]
Y
N
N
Hot pull?
5-6. powermig setup
[define source / target
pair, create OR session]
3. LUN mask remote
devices to DMX FA
to remote array
target devices
4a. Zone and device mask
4b. Update and save
PowerPath configuration
Y
N
second half)
PPME Setup steps 14 215
PPME Setup steps 14
Since PPME will also use an Open Replicator hot pull for the bulk
data copy, the setup steps 14 are identical to the way they were
performed in Chapter 7, Hot Pull from Symmetrix Migration
Example, therefore these operations will not be repeated in this
example. The PPME with Open Replicator operational flowchart
adds a step 4b, to update and save the PowerPath configuration. This
step was not necessary in the example presented here. An example of
completing this step on a Solaris host is:
# powermt config
# powermt save
#
PPME Setup steps 56: powermig setup
The session concept available with symrcopy and the SMC interface
for Open Replicator provides a convenient user interface to work
with multiple pairs of devices as a single unit. In the Symmetrix
array, each control/remote pair in the same session is actually
independent of each other. The PPME interface does not provide for a
way to group multiple pairs of devices as a single unit. Each
source/target pair is controlled individually with a separate handle
assigned to each pair. Therefore there is no need to create a pairs file;
instead each source and target device pair is defined on the command
line of the setup action. For this example, each device must be
identified using a PowerPath pseudo device name because the
Windows operating system only supports pseudo device names. In
other environments, native device names can be used as well.
Identify source and target pseudo device names
The physical names for the source devices used can be displayed
using the following Solutions Enabler command:
c:\>symdev list -sid 450 -range 141:144
------------------------- ------------- -------------------------------
Cap
------------------------- ------------- -------------------------------
0141 \\.\PHYSICALDRIVE29 09C:0 02C:C3 2-Way Mir N/Grp'd RW 4096
0143 \\.\PHYSICALDRIVE31 09C:0 02B:C4 2-Way Mir N/Grp'd RW 4096
c:\>
However, the PowerPath pseudo device names for Windows uses the
format harddiskXX, that can be seen when displaying the
PowerPath devices:
c:\>powermt display dev=all
. . .
Pseudo name=harddisk29
Symmetrix ID=000187720450
Logical device ID=0141
state=alive; policy=SymmOpt; priority=0; queued-IOs=0
=======================================================================
--------------- Host ----------- - Stor - - I/O Path - -- Stats ---
### HW Path I/O Paths Interf. Mode State Q-IOs Errors
=======================================================================
2 port2\path0\tgt1\lun16 c2t1d16 FA 9cA active dead 0 1
2 port2\path0\tgt3\lun16 c2t3d16 FA 9cA active alive 0 0
4 port4\path0\tgt1\lun16 c4t1d16 FA 8cA active dead 0 1
4 port4\path0\tgt3\lun16 c4t3d16 FA 8cA active alive 0 0
. . .
. . .
PPME Setup steps 56: powermig setup 217
. . .
Similarly, the target physical device names can be displayed:
c:\>symdev list -sid 359 -range 95:98
------------------------- ------------- -------------------------------
Cap
------------------------- ------------- -------------------------------
0095 \\.\PHYSICALDRIVE15 15C:0 01B:C5 2-Way Mir N/Grp'd RW 4096
0096 \\.\PHYSICALDRIVE16 15C:0 16A:D8 2-Way Mir N/Grp'd RW 4096
0097 \\.\PHYSICALDRIVE17 15C:0 16B:CC 2-Way Mir N/Grp'd RW 4096
0098 \\.\PHYSICALDRIVE18 15C:0 16A:CD 2-Way Mir N/Grp'd RW 4096
c:\>
Since the format of the pseudo device names is known, it is not
necessary to use the powermt display command to see the
hardiskXX format. For example, target device 95 has a physical
device name ending in 15, therefore specifying the pseudo device
name harddisk15 explicitly can yield a check that it does indeed
point to Symmetrix device 95:
c:\>powermt display dev=harddisk15
. . .
PPME license required
In addition to the Solutions Enabler Open Replicator/LM license,
PowerPath Migration Enabler requires a specific license for data
migrations using Open Replicator. Issuing a valid PPME command
without the required license will result in an
error. The required license can be added using the PowerPath license
registration command emcpreg:
c:\>powermig setup -techType OR -src harddisk24 -tgt harddisk15 -noprompt
PPME error(15): Required license is missing or expired
c:\>emcpreg -add NN#N-NNN#-NNNN-NN#N-NNNN-NNNN
Success: License added
c:\>
PPME powermig setup
The setup action requires the underlying technology to be specified;
OR is used to signify Open Replicator. Many of the powermig
command arguments have two and three character abbreviations:
src for source, tgt for target, and no for noprompt. The source
and target pseudo device names are specified to define the pair and a
numeric handle is returned to use for subsequent powermig
commands:
Migration Handle = 1
c:\>powermig setup -techType OR -src harddisk25 -tgt harddisk16 -no
c:\>powermig setup -techType OR -src harddisk26 -tgt harddisk17 -no
c:\>
The powermig info -all command can be used to report on all
source/target pairs under PPME control. Notice that the four
source/target pairs used in this example are in the setup state.
c:\>powermig info -all
========================================
Hnd Source Target Tech State
=== ========== ========== ==== =====
1 harddisk24 harddisk15 OR setup
c:\>
PPME Setup steps 56: powermig setup 219
The setup action issues the Open Replicator create command, so
the successful setup state confirms that the create was successful,
verifying that all of the required Open Replicator setup steps have
been completed. Even though the powermig command is used to
control this migration, it is still possible to view Open Replicator
status directly using symrcopy or SMC. In the following example,
notice the following flag values: C(opy) is set, (pu)S(h) is reset
indicating a pull, H(ot) is set, and (donor)U(pdate) is reset:
c:\>symrcopy -sid 359 list
--------------- ----------------------------- ----- -------------- ----
Protected
Sym Tracks Identification RI CDSHU CTL <=> REM (%)
----- --------- -------------------------- -- ----- -------------- ----
0095 65535 000187720450:0141 SD X..X. Created N/A
0096 65535 000187720450:0142 SD X..X. Created N/A
0097 65535 000187720450:0143 SD X..X. Created N/A
0098 65535 000187720450:0144 SD X..X. Created N/A
Total ---------
Tracks 262140
MB(s) 16383.8
Legend:
Flags:
c:\>
Migration step 10: powermig sync
Activating Open Replicator sessions is accomplished by executing
the powermig sync command, that initiates the copying from
source to target:
c:\>powermig sync -handle 1 -noprompt
c:\>
Migration step 12: Tune migration 221
The PPME throttle mechanism is an alternate interface to the Open
Replicator pace parameter. The following example of powermig
help shows how to get the syntax detail for the throttle action:
c:\>powermig help throttle
throttle - used for altering the speed of a migration
Usage:
powermig throttle -handle <handle> -throttleValue <value> -suspendTime <valu e>
c:\>
The -suspendTime option is not applicable when using Open
Replicator as the underlying technology. In this example, the ceiling
values set for the Symmetrix control FA ports in earlier are still in
effect. The throttle value is ignored for all participating
director/port combinations where the ceiling value is not NONE. The
following command can be used to display the current ceiling
settings:
c:\>symrcopy -sid 359 list ceiling
Max Set Actual
Dir:P (MB) (%) (MB)
----- ---- ---- ------
01C:0 150 NONE 0
01C:1 150 NONE 0
02C:0 150 30 0
02C:1 150 NONE 0
15C:0 150 30 0
15C:1 150 NONE 0
16C:0 150 NONE 0
16C:1 150 NONE 0
c:\>
Migration step 13: query status, until SourceSelected
This step consists mostly of waiting until the underlying technology,
Open Replicator copy, completes copying all of the tracks from the
source devices to the target devices.
The powermig query command is used to report back on the
progress of the background copying. The query action must specify
a single PPME handle, and thus can only report on a single
source/target pair. In the following example, notice the PPME
Migration state is now syncing and the Percent InSync is
up to 1 percent.
c:\>powermig query -handle 1
Handle: 1
Source: harddisk24
Target: harddisk15
Technology: OR
Migration state: syncing
Percent InSync: 1%
Throttle Value: 5
c:\>
The powermig info command has an -all option, that can be
used to list the status for all PPME source/target pairs in a single
command. Additionally, the -query option can be specified to
include the percent InSync values:
==========================================
=== ========== ========== ==== =======
1 harddisk24 harddisk15 OR syncing
c:\>powermig info -all -query
==============================================
=== ========== ========== ==== ===========
1 harddisk24 harddisk15 OR syncing(1%)
Migration step 13: query status, until SourceSelected 223
c:\>
After waiting long enough, the bulk Open Replicator copy will
complete and the sessions will be in the Open Replicator Copied
state. As shown in this example, the Open Replicator Copied state is
reflected in the PPME sourceSelected state:
c:\>powermig info -all -query
=================================================
=== ========== ========== ==== ==============
1 harddisk24 harddisk15 OR sourceSelected
c:\>
When using PPME, the sourceSelected state is an indicator that
the data transfer is complete. The next set of operations are part of the
robust cleanup steps introduced in Cleanup steps on page 207.
These steps are presented in a typical PPME sequence, but the titles
are not numerically in order, since the step numbers are based on the
Open Replicator examples presented previously.
Migration step 18a: powermig selectTarget
The PPME command powermig selectTarget is used to switch
to the targetSelected state. The targetSelected state defines
the condition when source and target are synchronized and all
application reads come from the target. The following commands are
used to enter the targetSelected state and display that status:
c:\> powermig selectTarget -handle 1 -noprompt
=================================================
=== ========== ========== ==== ==============
1 harddisk24 harddisk15 OR targetSelected
c:\>
A best practice is to conduct application specific migration
verification while in this state (the first half of step 15). As part of the
verification process it is possible to switch back and forth between the
sourceSelected and targetSelected states; such switching is
transparent to the production applications. If the migration does not
meet the migration verification criteria, it can be aborted, then
restarted or completely cleaned up. If the migration verification
criteria are met, then it is time to commit the migration to using the
target devices.
Migration step 18b: powermig commit 225
Migration step 18b: powermig commit
For this example on a Windows host, pseudo-named source devices
are in use, providing for a transparent, single step commit. If native
devices were in use, two powermig command actions would be
necessary, along with stopping applications in between and
reconfiguring them to reference the target devices in place of the
source devices as described in PPME commit for native-named
source devices on page 210.
The PPME command powermig commit can be used to switch to
the Committed state:
c:\>powermig commit -handle 1 -noprompt
============================================
=== ========== ========== ==== =========
1 harddisk24 harddisk15 OR committed
c:\>
The production applications can now transparently continue to
operate using the target devices on a permanent basis, because PPME
has swapped the pseudo-names used for source and target devices.
This change in pseudo-names can be seen by comparing the
powermt display output from before the commit (Identify
source and target pseudo device names on page 216) with the
output after the commit shown below. Previously, source devices
141144 used pseudo-names were hardisk29 to hardisk32. Now,
the target devices 9598 use pseudo-names hardisk29 to
hardisk32.
c:\>powermt display dev=all
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
Migration step 16: powermig cleanup 227
Migration step 16: powermig cleanup
While in the Committed state, the PPME command powermig
cleanup should be used to remove selected data from each source
LUN, ensuring that production applications and/or the operating
system are not confused by identical data residing on both the source
and target LUNs. The help for the cleanup action shows that the
-format option could be used in this example to perform a full disk
format on the source LUN.
c:\>powermig help cleanup
cleanup - Cleanup after a migration.
Usage:
powermig cleanup -handle <handle> [-format] [-force]
c:\>powermig cleanup -handle 1 -noprompt
c:\>
The cleanup action deletes the PPME migration information and
terminates the Open Replicator session, as shown by the following
command actions:
No migrations found.
c:\>symrcopy -sid 359 list
No Devices with RCopy sessions were found.
c:\>
Cleanup step 19: Redeploy source devices storage
Step 19 is very similar for all of the presented migration examples.
However in this example, because of the cleanup action, the source
devices can remain configured as being visible to the host.
Federated Live Migration (FLM) Overview 229
10
This chapter defines the benefits, terminology and operations of
Federated Live Migration (FLM). The setup, migration, and cleanup
phases are described using the set of steps first defined in Basic
Open Replicator migration operation flow on page 55. Because the
FLM interface and capabilities offer significant simplification and
enhancements, some steps are reordered, skipped, merged together,
or split apart; yet the basic flow is still fundamentally the same. The
topics covered include:
Introduction ...................................................................................... 230
Benefits of using FLM...................................................................... 230
FLM Nondisruptive migration overview..................................... 231
FLM Definitions ............................................................................... 233
FLM basic operation sequence....................................................... 235
FLM considerations and restrictions............................................. 237
FLM migration using Open Replicator operation flow.............. 238
Federated Live
Migration (FLM)
Overview
Federated Live Migration (FLM) Overview
Introduction
Federated Live Migration (FLM) is a method by which a user can
move data from older storage into a new Symmetrix VMAX array
nondisruptively. The host application cutover to use the new VMAX
devices is made transparent by a combination of presenting the
VMAX devices as additional paths to the old devices and managing
which paths are active through a MPIO driver on the host. FLM
supports PowerPath as the application MPIO driver, and will support
additional MPIO drivers in the future. FLM supports moving the
data with Open Replicator SAN-based replication, and will support
other underlying technologies in the future. Unlike application
host-based PPME, control of the migration and cutover is managed
through the Symmetrix VMAX array. FLM greatly simplifies
migrations requiring no remediation when migrating pre-qualified
stacks.
Note: For information on supported operating systems, file systems, and
logical volume managers, refer to the EMC Federated Live Migration Simple
Support Matrix available at http://Powerlink.EMC.com.
Benefits of using FLM
FLM greatly reduces migration complexity and risk by eliminating
the need for operational migration steps on applications hosts.
Support for pre-qualified stacks including older versions typical in a
migration scenario can eliminate remediation steps. FLM also
eliminates the need for a traditional cutover step, and provides the
ability to failback from the migration without data loss.
Eliminating application downtime during a migration greatly
simplifies the planning for large-scale migrations. Migration window
flexibility is important to administrators because it simplifies the
migration planning process. Administrators do not have to rely on
others to follow their directions, nor do they need to work off their
shift, which is when migration data movement operations are
frequently scheduled. With FLM, the pressure to correctly complete
critical and complex migration tasks during outages or off hours is
eliminated.
FLM Nondisruptive migration overview 231
FLM also greatly simplifies migration operations by limiting required
application host operations to a SCSI bus scan at times when device
visibility to the host is changed, and configuration, cleanup, and
verification of the multipath configuration throughout the migration
process. Detailed procedures have been developed to help the
migration administrator identify host states that are safe to proceed
on each supported platform. Following these FLM procedures exactly
brings simplicity to migration operations and may even allow less
skilled and less expensive staff to execute the work.
Data migrations are often complex operations and require careful
planning and execution of predetermined procedures. Failure to
identify and perform necessary steps or work within supported
configurations can result in data unavailability or loss.
FLM Nondisruptive migration overview
FLM uses standard Open Replicator commands with additional
options specific to Federated Live Migration sessions. Using Open
Replicator as the underlying technology, the hot pull does the bulk
data copying between the arrays through the SAN, and donor update
keeps source and target devices synchronized. Mirroring the devices
allows testing of the migration and the option to return to the initial
state with no downtime. Standard auto-provisioning command(s)
between the FLM create and activate operations enable the new VMAX
devices to be presented with the identity of the old DMX devices. The
PowerPath MPIO driver sees paths for the same device on both the
old DMX and new VMAX. FLM controls which set of paths are active
to the MPIO driver. Figure 79 on page 232 illustrates an overview of
FLM operation.
Figure 79 FLM operation overview
Application
Data
RAID 1
Application
Data
RAID 1
Data
RAID 5
Application
Data
RAID 5
ICO-IMG-000906
Create and
activate FLM
session
Terminate
FLM session
remove DMX
DMX WWN &
geometry
DMX WWN &
geometry
DMX WWN &
geometry
DMX WWN &
geometry
PowerPath MPIO PowerPath MPIO PowerPath MPIO
Open Replicator
Old DMX Old DMX New VMAX New VMAX
Donor update
FLM Definitions 233
FLM Definitions
Source and target, old and new
FLM migrates data in a single direction, therefore the terms source
and target unambiguously refers to the two endpoints of an FLM data
migration. These terms can be used both for the arrays and devices in
a migration. Because FLM is used in data center consolidation and
technology refresh cases, the terms old and new can also be used to
refer to the two endpoints of an FLM data migration. With initial
support only for DMX source arrays and VMAX target arrays, the
terms DMX and VMAX also provide unambiguous reference to the
FLM migration endpoints. The term donor can also be used for the
source array. When Open Replicator hot pull is used as the
underlying technology, the source LUNs are Open Replicator remote
devices and the target LUNs are Open Replicator control devices.
Device external identity
Symmetrix arrays present a unique device identity for each host
visible Symmetrix Logical Volume (SLV). Therefore the presented
host identity for the DMX source device and the VMAX target device
would normally appear different to the application host. FLM
achieves nondisruptive migration by causing the VMAX target
device to present a device external identity which is identical to the
DMX source device. The key components of this identity is the device
WWN and geometry. The presentation of the device external identity
is dependent on conducting the FLM migration operations in an exact
order as in FLM migration using Open Replicator operation flow
on page 238 and shown in FLM with Open Replicator Migration
Example on page 243.
Federated Live Migration examples are specific to each
pre-qualified stack. The exact steps and order required for one
stack cannot be applied to a different stack. For current steps for all
pre-qualified stacks, consult the Symmetrix Customer Procedure
Generator available at http://Powerlink.EMC.com
FLM also includes operations to stop using the device external
identity after an FLM migration failback, or at some time after the
migration is complete and the user wants to switch the application to
use the native VMAX device identity.
Active and passive host access modes
FLM introduces new device host access modes. Active mode is the
normal device host access mode with the device fully visible to the
host. Passive mode is what FLM uses to make an otherwise Ready
device not visible to the host. Supported host MPIO drivers recognize
FLM toggling between the active and passive modes.
FLM source devices are in active mode until the FLM activate
operation and then remain in passive mode during and after the
migration. FLM target devices are put in passive mode as part of the
FLM create operation and are switched to active mode with the FLM
activate operation. The active and passive modes are used such that the
old source device and the new target device, presenting with the old
source device identity, are never both active to the host at the same
time.
After the migration is complete, the old source device remains in the
passive host access mode. If the old source array is moved to a
different SAN than the new target array, then it may be safe to make
these old source devices visible to hosts again by contacting EMC
customer service.
FLM basic operation sequence 235
FLM basic operation sequence
FLM operations are very simple and can be completed in six basic
steps:
1. Set up the underlying technology migration environment,
currently Open Replicator
2. Create the FLM session
3. Mask the new VMAX target devices to the application host
4. Activate the FLM session
5. Wait for the FLM migration to complete
6. Terminate the FLM session and remove the old source storage
Data migrations are often complex operations and require careful
planning and execution of predetermined procedures. Failure to
identify and perform necessary steps or work within supported
configurations can result in data unavailability or loss.
At the completion of these steps, the application continues to run
using only the new VMAX target devices which continue to present
device external identities equal to the old source devices. All of the
old source devices remain in passive mode to the host. EMC
Customer Service can be contacted to return these devices to active
mode only after the old source array is removed from sharing the
same SAN to ensure that the VMAX device external identities are
unique on the SAN.
An FLM migration can be aborted between steps 4 and 6 as described
in FLM failback, set NO identity, and host_active.
FLM failback, set NO identity, and host_active
An FLM migration session can be aborted with the failback action
anytime after activating the session and before terminating the session.
A FailedBack FLM migration session returns the old source
devices to active mode and the new target VMAX devices to passive
mode. The underlying technology for the migration is also aborted,
leaving the FLM session reporting its FailedBack state, with the only
permissible action being to terminate the session.
Once the FLM session is created, the new target VMAX devices will
always present themselves using the device external identity copied
from the old source devices. There are two scenarios when a
command can be issued to return the new target devices to using
their own original identity. First, after an FLM session is
FailedBack and will be abandoned permanently, returning to the
original identity is necessary in order to use these devices. Second,
after a successful FLM migration, the user may decide that persisting
the old source device identities is operationally confusing, especially
after the old source array is has been removed for a long time. In this
second case, it is necessary to stop the host application and restart it
using the original VMAX device identities. The command to stop
using the device external identity is a Symmetrix configuration
command with command syntax:
set dev <SymDevName> identity = NO identity;
Because the external identity of the new target VMAX devices is
identical to the old source devices, it is necessary to leave the old
source devices in passive mode to prevent both the old and new
devices from being visible with the same identity outside of an active
FLM session. If the old source array is moved to a different SAN, then
this is not a concern and it is valid to make these old source devices
visible to hosts again by contacting EMC customer service.
FLM considerations and restrictions 237
FLM considerations and restrictions
The following restrictions apply when performing FLM migrations:
Only explicitly supported stacks can be used for FLM migrations.
Note: For information on supported operating systems, file systems, and
logical volume managers, refer to the EMC Federated Live Migration Simple
Support Matrix available at http://Powerlink.EMC.com.
When using Open Replicator as the underlying technology:
The source device cannot be a boot device
The target device must be the same size or larger than the
source device
Devices involved in a migration should not be used as Symmetrix
gatekeeper devices because switches to passive host active mode
will cause gatekeeper errors. Use of the Solutions Enabler
gkavoid or gkselect files can ensure that migration devices
are not used as gatekeepers. The EMC Solutions Enabler Symmetrix
Array Management CLI Product Guide contains more information
about gatekeeper devices.
When migrating data to a target device that is larger than the
source device, the migration must be complete and terminated
before gaining access to space on the target that does not exist on
the source. Attempting to access that space before the migration
session is complete and terminated will remove the possibility of
valid FailBack.
FLM migration using Open Replicator operation flow
The six steps in the FLM workflow introduced in FLM basic
operation sequence, on page 235 will be listed and flowcharted
using the 19 migration steps introduced in Basic Open Replicator
migration operation flow on page 55 even though steps that apply to
cold or push Open Replicator operations are not applicable. Correctly
setting up the underlying technology is crucial to the successful use
of FLM.
For this example using Open Replicator as the underlying
technology, the setup phase steps will directly parallel the previous
hot pull examples, with the essential difference to wait to complete
the target device masking until after creating the FLM session. The
migration phase steps using Open Replicator are fewer and simpler
because FLM provides for skipping some steps entirely and other
steps are not applicable for a hot pull migration. The cleanup phase
steps are entirely optional and only apply if redeploying source
devices in a separate SAN or electively choosing to reset the identity
of the VMAX target devices to using their own native identity.
Setup steps
The six setup steps used for native Open Replicator hot pull
operations are performed with two important differences when using
FLM with Open Replicator. First, step 4 still includes the zoning for
target devices, but must not include the device (LUN) masking step,
which is moved to the Migration steps. Second, step 6 must include
successfully creating the FLM session:
2. Configure/connect migration SAN zone between source array
ports and Symmetrix VMAX target FA host ports.
3. Configure LUN Masking for source devices to allow access
from Symmetrix VMAX target (control) FA host ports.
4. Configure host zoning for target devices.
Do not perform device (LUN) masking at this time!
SMC GUI).
FLM migration using Open Replicator operation flow 239
6. Verify setup configuration and create the FLM session.
Figure 80 FLM with Open Replicator setup steps flowchart
Migration steps
An FLM managed migration has fewer operational steps than a hot
pull migration solely under Open Replicator control. For example,
migration steps 9 and 11 that briefly stop and restart applications
with them pointing to the target devices are no longer needed prior to
the migration, because FLM presents the new VMAX target devices
as alternate paths to the old source devices nondisruptively to the
host. The masking step that was postponed from setup step 4, is
performed now(step 10a) before the FLM activate step.
With FLM, the migration steps look like this:
10a. Mask the new VMAX target devices
10b.Activate the FLM session
application(optional)
13. Verify Open Replicator copy session is finished
15. Terminate Open Replicator session
ICO-IMG-000907
6. Verify pre-migration
5. Define FLM OR
session pairs (file)
4. Zone target devices
to the application host
3. LUN mask source
devices to VMAX FA
2. Zone VMAX FA
target to source array
target devices
Figure 81 FLM migration steps flowchart
Step 10a detail
The target device (LUN) masking step postponed from the setup
steps must be performed between the FLM create and the FLM
activate. The FLM create, copies the identity from the source devices
to the device external identity for the target devices. With the FLM
session created, the VMAX auto-provisioning masking operation
presents the target devices as new paths to the host MPIO driver, but
the paths are in passive host access mode, so cannot be used for I/O
yet.
Step 10b detail
The FLM activate using Open Replicator uses the additional
-migrate flag. FLM sets the old source device paths to host access
passive mode and the new VMAX target device paths to active mode.
Step 12 detail
Any Open Replicator tuning is performed in the same way as
described in Migration step 12: symrcopy set ceiling, on page 103.
Step 13 detail
The Open Replicator query and verify commands are used to
wait until the FLM migration completes as described in Migration
step 13: symrcopy query and verify, on page 105.
ICO-IMG-000908
impact level
terminate FLM
13. Verify FLM copy
done
Need tuning?
10a. Auto-provision the
VMAX target devices
10b. FLM activate
Y
N
FLM migration using Open Replicator operation flow 241
Step 15 detail
It is important to test and verify the migration success before
terminating the FLM session. Failing back to the old source devices
will no longer be available once the session is terminated. The FLM
terminate using Open Replication uses the additional -migrate
flag.
Cleanup steps
As explained earlier, the cleanup phase steps are entirely optional
when using FLM. However, with FLM it is not permitted to continue
to deploy the source array in the same SAN as the new VMAX target
array. Since FLM is a hot pull migration, the only step to complete is:
complete.
If the old source array is going to continue operation in another SAN,
it will be necessary to contact EMC Customer Service to make the
devices again visible to a host as described in FLM failback, set NO
identity, and host_active, on page 235.
FLM with Open Replicator Migration Example 243
11
This chapter details an FLM with Open Replicator migration example
that uses a donor DMX array and target VMAX array both visible to a
single Windows host array. Steps will be performed using SYMCLI
including brief explanations for Open Replicator operations.
Additional explanations for Open Replicator hot pull using SYMCLI
can be found in Chapter 6, Hot Pull from CLARiiON Migration
Example. Additional explanations for Open Replicator hot pull from
a source Symmetrix can be found in Chapter 7, Hot Pull from
Symmetrix Migration Example. This migration example will detail
the setup, migration, and cleanup steps defined for FLM in
Chapter 10, Federated Live Migration (FLM) Overview.
The topics covered include:
Introduction ...................................................................................... 244
FLM Setup steps 16........................................................................ 246
Setup step 3: Configure migration device masking.................... 250
Setup step 4: Configure target zoning to the application host .. 251
Setup step 5: Prepare FLM session pairs ...................................... 252
Setup step 6: Verify setup completion, FLM create..................... 253
Migration step 10a: Mask the VMAX target devices .................. 256
Migration step 10b: Activate the FLM session............................. 262
Migration step 13: Verify FLM session copy is done .................. 264
Migration step 15: Verify migration and FLM terminate........... 265
Cleanup step 19: Redeploy source devices storage..................... 266
FLM with Open
Replicator Migration
Example
FLM with Open Replicator Migration Example
Introduction
This chapter details a FLM with Open Replicator example using
Solutions Enabler SYMCLI on a Windows host with PowerPath. The
applicable migration steps defined for FLM in Chapter 10 apply for
this example, so the list of steps required to perform the migration is
not repeated here. However, the migration steps flowchart for all
three phases is shown in Figure 82 on page 245. This example will
also include extra SYMCLI and PowerPath display commands to
exhibit the way in which FLM works.
Federated Live Migration examples are specific to each
pre-qualified stack. The exact steps and order required for one
stack cannot be applied to a different stack. The example listed
here was correct for the example stack at the time of publishing. For
current steps for all pre-qualified stacks, consult the Symmetrix
Customer Procedure Generator available at
Management or application host location for commands
One of the key benefits of FLM is eliminating the need for operational
migration steps on applications hosts. However, the best practices
included in predetermined procedures include application host
operations: a SCSI bus scan at times when device visibility to the host
is changed, and configuration, cleanup, and verification of the
multipath configuration throughout the migration process. These
steps help the migration administrator identify host states that are
safe to proceed on each supported platform.
The following example performs all steps on the application host,
even though only the SCSI bus scan, multipath driver, and other
physical path related operations (for example, sympd list) must be
performed on the application host. All of the core FLM migration
steps can be performed on a separate management host.
Introduction 245
Figure 82 FLM with Open Replicator setup, migration, and cleanup steps
ICO-IMG-000909
19. Redeploy source
devices storage
6. Verify pre-migration
5. Define FLM OR
session pairs (file)
3. LUN mask source
devices to VMAX FA
2. Zone VMAX FA
control to source array
target devices 4. Zone target devices to
the application host
impact level
terminate FLM
13. Verify FLM copy
done
Need tuning?
10a. Auto-provision the
VMAX target devices
10b. FLM activate
Y
N
FLM Setup steps 16
Since FLM in this example will also use an Open Replicator hot pull
for the bulk data copy, the setup steps 16 are almost identical to the
way they were performed in Chapter 6, Hot Pull from CLARiiON
Migration Example,and Chapter 7, Hot Pull from Symmetrix
Migration Example. The operations will be repeated in this example
to illustrate delaying masking the target devices until after creating
the FLM session.
For this pull example, four devices on Symmetrix VMAX
000192601662 array will be the new target devices. The symdev
command with the -range option can be used to display the new
target devices 4D4:4D7. The Physical Device Name must be Not
Visible at this time, if this command is run from the application
host.
c:\>symdev -sid 62 list -range 4d4:4d7
--------------------------- ------------- -------------------------------------
Cap
--------------------------- ------------- -------------------------------------
04D4 Not Visible ***:* 08A:C7 2-Way Mir N/Grp'd RW 4096
04D5 Not Visible ***:* 11A:D7 2-Way Mir N/Grp'd RW 4096
04D6 Not Visible ***:* 09B:D6 2-Way Mir N/Grp'd RW 4096
c:\>
Since FLM will use an Open Replicator hot pull, all FA ports that the
new target devices are mapped to, must be zoned to access the source
DMX devices.
Determining target VMAX director WWNs
The Solutions Enabler symdev list -multiport command is used
to determine on which directors the target (Open Replicator control)
devices are mapped. For this example, all four target devices
4D44D7, are mapped to both director 7F port 0 and director 10F port
0.
c:\>symdev -sid 62 list -range 4d4:4d7 -multiport
--------------------------- ------------- -------------------------------------
Cap
--------------------------- ------------- -------------------------------------
04D4 08A:C7 2-Way Mir N/Grp'd RW 4096
Not Visible - 07F:0 - - - - -
Not Visible - 10F:0 - - - - -
04D5 11A:D7 2-Way Mir N/Grp'd RW 4096
Not Visible - 07F:0 - - - - -
Not Visible - 10F:0 - - - - -
04D6 09B:D6 2-Way Mir N/Grp'd RW 4096
Not Visible - 07F:0 - - - - -
Not Visible - 10F:0 - - - - -
04D7 06B:D5 2-Way Mir N/Grp'd RW 4096
Not Visible - 07F:0 - - - - -
Not Visible - 10F:0 - - - - -
c:\>
Note that the -multiport option will only list devices with more
than one path. If there is only a single path, then symdev list
should be used without the -multiport option.
c:\>symcfg -sid 62 list -fa 7f -p 0
Dir Port WWN ACLX Volume Set Pnt to Pnt
Enabled Addressing
FA-7F 0 500009720819F958 Yes No Yes
c:\>symcfg -sid 62 list -fa 10f -p 0
. . .
FA-10F 0 500009720819F964 Yes No Yes
Determining source DMX director WWNs
Since the source array is also a Symmetrix, the same SYMCLI
commands are used to determine the WWNs for DMX directors the
source (Open Replicator remote) devices are mapped. For this
example, all four source devices 481487, are mapped to both director
4Aport 0 and director 13A port 0.
c:\>symdev -sid 89 list -range 484:487 -multiport
--------------------------- ------------- -------------------------------------
Cap
--------------------------- ------------- -------------------------------------
0484 05C:D3 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE12 - 04A:0 - - - - -
Not Visible - 13A:0 - - - - -
0485 15D:C7 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE13 - 13A:0 - - - - -
Not Visible - 04A:0 - - - - -
0486 01C:C2 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE14 - 13A:0 - - - - -
Not Visible - 04A:0 - - - - -
0487 05A:C0 2-Way Mir N/Grp'd RW 4096
\\.\PHYSICALDRIVE15 - 13A:0 - - - - -
Not Visible - 04A:0 - - - - -
c:\>symcfg -sid 89 list -fa 4a -p 0
. . .
Enabled Addressing
FA-4A 0 50060482D52FA543 Yes No Yes
c:\>symcfg -sid 89 list -fa 13a -p 0
. . .
FA-13A 0 50060482D52FA54C Yes No Yes
Example configuration of migration SAN zones
In this example, zones are defined to include both source DMX
director WWNs and both target VMAX director WWNs. Figure 83
shows an excerpt of the Connectrix Manager Zoning verification
screen with the two zones defined.
Figure 83 Connectrix Manager activate zone verification screen
ICO-IMG-000910
Setup step 3: Configure migration device masking
Because the target (Open Replicator control) Symmetrix VMAX FA
hosts are connected to the source DMX (Open Replicator remote)
storage array on switched fibre ports, it is necessary to perform LUN
masking to grant the Symmetrix VMAX FA initiator access to the
source devices. This LUN masking is performed with tools specific to
the source storage array, that in this case is a Symmetrix DMX, using
the Solutions Enabler symmask command.
c:\>symmask -sid 89 -wwn 500009720819F958 -dir 4a -p 0 add devs 484:487 -dynamic
_lun -noprompt
c:\>symmask -sid 89 -wwn 500009720819F964 -dir 13a -p 0 add devs 484:487 -dynami
c_lun -noprompt
c:\>symmask -sid 89 refresh -noprompt
Symmetrix FA/SE directors updated with contents of SymMask Database 000190103189
c:\>
Setup step 4: Configure target zoning to the application host 251
Setup step 4: Configure target zoning to the application host
For a Federated Live Migration (FLM), this step only includes zoning
the target devices to the application host. It must not include the LUN
masking step at this time. In this example, the application host was
already able to see gatekeeper devices on the Symmetrix, proving
that this zoning is already in place for both director 7F port 0 and
director 10F port 0. The Symmetrix mapping step presenting the
target devices to specific director ports was displayed in
Determining target VMAX director WWNs on page 247. The
sympd list command can be used to show all host visible devices
for a specified Symmetrix. In this example, only gatekeeper devices
are host visible and the target devices are not listed:
c:\>sympd -sid 62 list
--------------------------- ------------- -------------------------------------
Cap
--------------------------- ------------- -------------------------------------
\\.\PHYSICALDRIVE24 0220 10F:0 11A:D7 2-Way Mir N/Grp'd ACLX RW 2
\\.\PHYSICALDRIVE25 00E4 10F:0 12C:D2 2-Way Mir N/Grp'd RW 3
\\.\PHYSICALDRIVE26 00E5 10F:0 07D:D2 2-Way Mir N/Grp'd RW 3
\\.\PHYSICALDRIVE27 00E6 10F:0 10B:D5 2-Way Mir N/Grp'd RW 3
\\.\PHYSICALDRIVE28 00E7 10F:0 06B:D5 2-Way Mir N/Grp'd RW 3
\\.\PHYSICALDRIVE29 0220 07F:0 11A:D7 2-Way Mir N/Grp'd ACLX RW 2
c:\>
Setup step 5: Prepare FLM session pairs
FLM using Open Replicator requires the definition of FLM
target-source (Open Replicator control-remote) pairs. Multiple pairs
grouped into a single file can be managed together by Open
Replicator. The FLM target (Open Replicator control) device is
identified in the first (leftmost) column and the FLM source (Open
Replicator remote) device is identified in the second (rightmost)
column.
The array ID must be fully specified and is separated from the
device/LUN name (number) by a colon:
c:\>echo symdev=000192601662:4d4 symdev=000190103189:484 > FLMpairs.txt
c:\>echo symdev=000192601662:4d5 symdev=000190103189:485 >> FLMpairs.txt
c:\>type FLMpairs.txt
symdev=000192601662:4d4 symdev=000190103189:484
symdev=000192601662:4d5 symdev=000190103189:485
symdev=000192601662:4d6 symdev=000190103189:486
symdev=000192601662:4d7 symdev=000190103189:487
c:\>
Setup step 6: Verify setup completion, FLM create 253
Setup step 6: Verify setup completion, FLM create
All required zoning and masking for the hot pull FLM session will be
verified when creating the session. Using the Solutions Enabler
symrcopy command, the -migrate option is specified to make this
an FLM session. This includes the very important step of passing the
DMX source device identity to the VMAX target device to be used as
the device external identity. This example will include extra display
steps to exhibit this mechanism. Many of these informational display
steps are part of the predetermined procedures, and are used to verify
status before initiating operations that could result in data
unavailability or even data loss if errors were made in performing all
necessary steps correctly.
Displaying the pre-create FLM status
The physical device number of the source devices was displayed by
the symdev list command inDetermining source DMX director
WWNs on page 248; the source devices are devices 1215. The
PowerPath CLI powermt display for device 12 shows two paths
alive for this device from source DMX FA interfaces 4aA and 13aA
(where the capital A indicates port 0):
c:\>powermt display dev=12
==============================================================================
---------------- Host --------------- - Stor - -- I/O Path - -- Stats ---
==============================================================================
3 port3\path0\tgt2\lun6 c3t2d6 FA 4aA active alive 0 0
Two new FLM related options for the symdev list command are:
-host_passive lists devices with host access mode set to
passive mode
-identity_set lists devices which will present their device
external identity instead of their original identity
Prior to the FLM create command the target devices are still in the
default active mode presenting their own identity:
c:\>symdev -sid 62 list -host_passive
Could not select any Symmetrix devices to list.
c:\>symdev -sid 62 list -identity_set
Could not select any Symmetrix devices to list.
c:\>
Creating the FLM session
The FLM session using Open Replicator uses the -migrate,
-host_type, -hba_type, and -mp_type options. Depending on
the -host_type some of the other options may not be required.
Querying the Open Replicator session shows the status as Created
and the flags showing a (H)ot, donor (U)pdate, (M)igration (T)ype
session. The -migrate option implicitly enables donor update.
c:\>symrcopy -f FLMpairs.txt create -pull -migrate -host_type Windows -hba_type E
mulex -mp_type PPath_45 -name flm -noprompt
in device file 'FLMpairs.txt'. Please wait...
in device file 'FLMpairs.txt'.
c:\>
Setup step 6: Verify setup completion, FLM create 255
Querying the Open Replicator session shows the status as created
and the flags showing a (H)ot, donor (U)pdate, (M)igration (T)ype
session.
c:\>symrcopy -sid 62 -session_name flm query
Session Name : flm
---------------------------- ------------------------ ------- -------------- ----
Protected
SID:symdev Tracks Identification RI CDSHUTZ CTL <=> REM (%)
------------------ --------- --------------------- -- ------- -------------- ----
000192601662:04D7 65535 000190103189:0487 SD ...XXM. Created N/A
Total ---------
Track(s) 262140
MB(s) 16383.8
Legend:
Flags:
(T): M = The session is a migration session.
S = The session is a standard ORS session.
(Z): X = The session has front-end zero detection enabled.
. = The session does not have front-end zero detection enabled.
c:\>
Migration step 10a: Mask the VMAX target devices
The presentation of the VMAX target devices was delayed from the
setup phase to the migration phase. After the FLM create is complete,
the VMAX target devices have the device external identity of the
source DMX devices and can now be presented to the application
host.
Displaying the post-create FLM status
Repeating the symdev list command with the new FLM options
now show the VMAX target devices in host access passive mode and
having their device external identity in force:
c:\>symdev -sid 62 list -host_passive
--------------------------- ------------- -------------------------------------
Cap
--------------------------- ------------- -------------------------------------
c:\>symdev -sid 62 list -identity_set
--------------------------- ------------- -------------------------------------
Cap
--------------------------- ------------- -------------------------------------
c:\>
Migration step 10a: Mask the VMAX target devices 257
Note: The VMAX target devices using their own identity are Not Visible.
They are only application host visible as additional paths to the original
source device.
The symdev list command using the -identity option can be
used to display the Device External Identity defined for a FLM target
device:
c:\>symdev -sid 62 list -range 4d4:4d7 -identity
Device FLG External Identity
---------------------------------- --- ----------------------------------------
Sym Physical Config Sts IG Array ID Num Ser Num Cap (MB)
---------------------------------- --- ----------------------------------------
04D4 Not Visible 2-Way Mir RW X. 000190103189 00484 8900484000 4096
Legend:
Flags:
(I)dentity : X = The device has a non-native external identity set
. = The device does not have an external identity set
(G)eometry : X = The device has a user defined geometry
. = The device does not have a user defined geometry
The -details option can be used to display the WWN that will be
presented. For example:
c:\>symdev -sid 62 list -range 4d4:4d7 -identity -detail
Device FLG External Identity
----------------------------- --- ---------------------------------------------------------------------
Sym Physical Config Sts IG Array ID Num Ser Num Cap (MB) WWN
----------------------------- --- ---------------------------------------------------------------------
04D4 Not Visible 2-Way Mir RW X. 000190103189 00484 8900484000 4096 60060480000190103189533030343834
Legend:
Flags:
(I)dentity : X = The device has a non-native external identity set
. = The device does not have an external identity set
(G)eometry : X = The device has a user defined geometry
. = The device does not have a user defined geometry
c:\>
The symdev show command can also be used to display the Device
External Identity defined for a FLM target device. The middle portion
of the original Device WWN includes the VMAX Symmetrix ID,
while the Device External Identity Device WWN includes the source
DMX Symmetrix ID, and is identical to the Device WWN for the
source DMX device. After all the normal and Ready device states, a
new field for the Host Access Mode is set to PASSIVE. There is
also a new field in the Remote Copy Device Information (Open
Replicator session information) which shows that this is an FLM
session Federated Live Migration : True.
c:\>symdev -sid 62 show 4d4
Device Physical Name : Not Visible
Device Symmetrix Name : 04D4
Device Serial ID : N/A
. . .
Product Revision : 5875
Device WWN : 60000970000192601662533030344434
. . .
Device Block Size : 512
Device Capacity
{
Cylinders : 4369
Tracks : 65535
512-byte Blocks : 8388480
MegaBytes : 4096
KiloBytes : 4194240
}
Device External Identity
{
Device WWN : 60060480000190103189533030343834
Front Director Paths (2):
{
-----------------------------------
DIRECTOR PORT LUN
---------- ---- -------- ---------
Type Num Sts VBUS TID SYMM Host
-----------------------------------
FA 07F:2 RW 000 00 069 N/A
FA 10F:2 RW 000 00 033 N/A
}
Geometry : Native
{
Sectors/Track : 128
Tracks/Cylinder : 15
Cylinders : 4369
512-byte Blocks : 8388480
MegaBytes : 4096
KiloBytes : 4194240
}
}
. . .
Device Service State : Normal
Device Status : Ready (RW)
Device SA Status : Ready (RW)
Device User Pinned : FALSE
Host Access Mode : PASSIVE
Extent Based Clone : None
Front Director Paths (2):
{
----------------------------------------------------------------------
POWERPATH DIRECTOR PORT LUN
--------- ---------- ---- -------- ---------
PdevName Type Type Num Sts VBUS TID SYMM Host
----------------------------------------------------------------------
Not Visible N/A FA 07F:0 RW 000 00 069 N/A
Not Visible N/A FA 10F:0 RW 000 00 033 N/A
}
. . .
Remote Copy Device Information
{
Remote Copy Session Name : flm
Session State : Created
Pull : True
Offline Copy : False
Differential Copy : Disabled
Background Copy : Disabled
Incremental Copy : False
Donor Update : True
Federated Live Migration : True
Frontend Zero Detection : False
Starting Block : 0
Total Blocks : 8388480
Percent Copied : N/A
Remote Devices [1]
{
---------------------------------------------------------------------
Array:Dev WWN Starting Block
--------------------- -------------------------------- --------------
000190103189:0484 60060480000190103189533030343834 0
}
}
Mask the VMAX target devices
Masking the target VMAX devices with Auto-provisioning is as
simple as adding the target devices to a storage group. The view that
includes that storage group will automatically map and mask the
new devices to the initiators and ports defined in the view as
described in Auto-provisioning Groups on page 161.
c:\>symaccess -sid 62 -name d096sg -type storage add devs 4d4:4d7
The new VMAX devices must be discovered on the application host
and then configured into PowerPath. Since the new VMAX devices
are now reporting the external identity of the DMX devices,
PowerPath will configure the new VMAX devices as new paths to the
existing old DMX devices. The EMC Host Connectivity Guide for
Windows provides the appropriate procedure for adding devices
online. In this example, the DiskPart utility is used to rescan and
add additional device paths. In Windows, PowerPath is
automatically configured when new devices or device paths are
discovered.
c:\>diskpart
On computer: SVCTAG-GNTFLH1
DISKPART> rescan
Please wait while DiskPart scans your configuration...
DiskPart has finished scanning your configuration.
DISKPART> exit
Leaving DiskPart...
c:\>
Displaying the post-create and target masking MPIO status
After the rescan, repeating the PowerPath CLI powermt display
for device 12 now shows two additional paths to logical device 0484
on Symmetrix 000190103189. These new paths are actually the
VMAX target devices as reflected in the reported FA interfaces 7fC
and 10fC. The capital C indicates non-existent FA port 2; the
Symmetrix adds the total number of the FA ports per director (in this
example two for ports 0 and 1) to the actual port number when using
device external identity, therefore representing port 0. This
corresponds to the target device ports reported in Determining
target VMAX director WWNs on page 247.
With Windows and PowerPath 4.5, the I/O Path State for
host_passive devices will be marked dead in PowerPath displays.
This is expected and required so that I/O is redirected properly
during the FLM Migration. With Windows and PowerPath 4.6 and
later, host_passive devices will not be marked dead in PowerPath
displays, but I/O will still be properly redirected during the FLM
Migration. Powerpath 4.5 is used in this example.
==============================================================================
==============================================================================
3 port3\path0\tgt3\lun5 c3t3d5 FA 10fC active dead 0 2
5 port5\path0\tgt0\lun5 c5t0d5 FA 7fC active dead 0 2
IMPORTANT
Do not proceed unless all the new VMAX devices have been
configured as new paths to each of the old DMX devices involved
in FLM migration. The next step in the process will set the old
DMX devices to host_passive and I/O will fail unless the new
VMAX paths are configured properly.
When all paths to the new VMAX devices have been discovered, save
the running PowerPath configuration.
c:\>powermt save
Migration step 10b: Activate the FLM session
FLM activate starts the Open Replicator background copy of data
from the DMX source devices to the VMAX target device. It also
switches the active and passive host access modes, so that the VMAX
target devices will be in active mode and the DMX source devices
will be in passive mode.
c:\>symrcopy -sid 62 -session_name flm activate -migrate -noprompt
with session name 'flm'. Please wait...
with session name 'flm'.
c:\>
The Open Replicator query output now shows CopyInProg(ress)
state.
c:\>symrcopy -sid 62 -session_name flm query
Session Name : flm
---------------------------- ----------------------- ------- -------------- ----
Protected
SID:symdev Tracks Identification RI CDSHUTZ CTL <=> REM (%)
------------------ --------- --------------------- -- ------- -------------- ----
000192601662:04D7 65528 000190103189:0487 SD X..XXM. CopyInProg 0
Total ---------
Track(s) 262112
MB(s) 16382.0
Legend:
Flags:
. . .
Migration step 10b: Activate the FLM session 263
Displaying the post-activate FLM status
Repeating, the PowerPath CLI powermt display for device 12 now
shows the swap of alive (active) and dead (passive) paths.
==============================================================================
==============================================================================
3 port3\path0\tgt2\lun6 c3t2d6 FA 4aA active dead 0 3
3 port3\path0\tgt3\lun5 c3t3d5 FA 10fC active alive 0 2
5 port5\path0\tgt0\lun5 c5t0d5 FA 7fC active alive 0 2
5 port5\path0\tgt1\lun7 c5t1d7 FA 13aA active dead 0 2
If the application host is running Solutions Enabler, a symcfg
discover command should be run to update the physical device
(pdev) information in the SYMAPI database. Device Special Files
previously associated with the old DMX will now be associated with
the new VMAX.
c:\>symcfg discover
Monitor the ORS session until all devices reach a 'Copied' state.
c:\>
The underlying Open Replicator session used for FLM can be tuned
as described in Migration step 12: symrcopy set ceiling on
page 103.
Migration step 13: Verify FLM session copy is done
completes. The query action will report the Status, the decreasing
number of Protected Tracks, and the increasing Done percent.
The normal status sequence goes from CopyInProg to Copied.
Using the verify action allows scripts to wait for a particular status.
The use of the count (-c) option limits how long to wait and the
program can check for unsuccessful return status indicating an exit
from the loop due to the count being reached rather than reaching the
waited for status.
In the following example, the interval (-i) of 300 seconds (5 minutes)
with a count of 6 means waiting for one half hour (30 minutes). In the
example, the Copied state was reached within the one-hour time
limit for checking. It is important to specify a realistic time limit
based on the amount of data to be copied and the bandwidth or other
tuning limitations that will affect how long the copy could take to
complete.
c:\>symrcopy -sid 62 -session_name flm verify -copied -i 300 -c 6
None of the session(s) with name 'flm' are in 'Copied' state.
None of the session(s) with name 'flm' are in 'Copied' state.
. . .
All session(s) with name 'flm' are in 'Copied' state.
Migration step 15: Verify migration and FLM terminate 265
Migration step 15: Verify migration and FLM terminate
Because this is a hot pull, production applications are already using
the VMAX target devices, in effect verifying the validity of the copied
data. However, if any application specific verification of the
migration is desired, it must be completed before terminating the
FLM session along with the donor update feature that keeps the
original source updated with all changes since the production
applications began using the targets. Once the validation is complete,
the FLM session is no longer needed and can be terminated by
executing a command that looks something like the following:
c:\>symrcopy -sid 62 -session_name flm terminate -migrate -noprompt
with session name 'flm'. Please wait...
with session name 'flm'.
Cleanup step 19: Redeploy source devices storage
Given the consolidation and technology refresh use cases common
for FLM, the source arrays are often not redeployed. As long as the
new VMAX devices continue to use the device external identity of the
source devices, the old source array devices cannot be present in the
same SAN. FLM ensures that this will not happen accidentally by
leaving the donor array devices in passive host access mode.
The old DMX devices should be removed from the application host
by changing the zoning and masking.
c:\>symmask -sid 89 -dir 4a -p 0 -wwn 10000000c977eae0 remove devs 484:487 -noprom
pt
c:\>symmask -sid 89 -dir 13a -p 0 -wwn 10000000c977eb7c remove devs 484:487 -noprom
pt
c:\>symmask -sid 89 refresh
Symmetrix FA/SE directors updated with contents of SymMask Database 000190103189
c:\>
Once the devices are no longer host accessible, they must be removed
from PowerPath. A host rescan is necessary for Windows to recognize
that the devices have been removed. PowerPath will not allow
devices to be removed if the operating system believes they are still
accessible.
c:\>diskpart
On computer: SVCTAG-GNTFLH1
DISKPART> rescan
Please wait while DiskPart scans your configuration...
DiskPart has finished scanning your configuration.
DISKPART> exit
Leaving DiskPart...
c:\>
The rescan forces Windows to recognize that the old DMX devices
have been removed and are no longer accessible. PowerPath can now
remove the dead device paths to the old storage. The command
Cleanup step 19: Redeploy source devices storage 267
powermt remove dev=all should be used to remove dead paths
which are no longer accessible. This command will only remove
paths which Windows recognizes are not allocated and will not have
any impact on active and available paths.
c:\>powermt remove dev=all
Cannot remove device that is in use: c3t2d0
. . .
The old DMX devices paths have been removed and the application
host is now using only the new VMAX devices.
==============================================================================
==============================================================================
The errors are records of the path state changes. These can be cleared
with powermt restore which performs a path check and reports
nothing if all paths are alive and available.
c:\>powermt restore
==============================================================================
==============================================================================
When all paths to the old DMX devices have been removed, save the
running PowerPath configuration
c:\>powermt save
Federated identity removal
At some future time when it is desirable to no longer have the old
source array device identities continue to be used, the target VMAX
devices can be set to stop using the device external identity. This will
require stopping the application and setting it to point correctly to the
target device native identity.
The process is performed in three steps with careful attention to
cleaning up the operating system and multipath software to avoid
identity confusion:
Allocation removal of new VMAX devices with device external
identity in effect
Removal of device external identity
Allocation of new VMAX devices with native identity
IMPORTANT
Application I/O should be halted on the application host to avoid
data unavailability when the device allocation is removed. Drive
Mounts and/or Mount points can be removed using the Windows
mountvol or Solutions Enabler symntctl utility to guarantee there
is no additional I/O to the new VMAX volumes.
An example of the middle step to reset the identity would look
something like the following:
c:\>symconfigure -sid 62 -cmd "set dev 4d4:4d7 identity = NO identity;" commit -
noprompt
A Configuration Change operation is in progress. Please wait...
Establishing a configuration change session...............Established.
Processing symmetrix 000192601662
Performing Access checks..................................Allowed.
Checking Device Reservations..............................Allowed.
Locking devices...........................................Locked.
Committing configuration changes..........................Started.
Committing configuration changes..........................Committed.
Terminating the configuration change session..............Done.
The configuration change session has successfully completed.
c:\>
Open Replicator Performance Tuning 269
A
The purpose of this appendix is to consolidate, expand and elaborate
on the performance tuning information included in the earlier
chapters of this TechBook. The topics covered include:
Two goals of Open Replicator tuning ........................................... 270
Resource conflicts............................................................................. 271
Limiting Open Replicator resource usage .................................... 272
Migration options can impose performance delays.................... 274
Tuning Open Replicator .................................................................. 275
Monitoring Open Replicator performance................................... 278
Tuning for applications sensitive to response time..................... 282
Open Replicator
Performance Tuning
Open Replicator Performance Tuning
Two goals of Open Replicator tuning
Open Replicator tuning is a matter of balancing two possibly
conflicting goals. Usually, the most important goal of Open
Replicator tuning is to ensure that the data migration does not
unacceptably impact the simultaneously running production
applications. The secondary goal is to ensure that the data migration
completes within the planned window for the migration. These goals
will conflict when the number of resources needed to meet the
migration window goal results in undesired impact to production
applications.
Resource conflicts 271
Resource conflicts
Open Replicator impact on production application performance is
mainly a result of I/O resource conflict. There might also be some
CPU impact when Open Replicator management is executed on the
application host.
I/O resource paths
The production application I/O path goes from the:
Production Host I/O Queue HBA SAN Source Array
except in the case of a hot pull, when the production I/O is redirected
to the Target Array.
The Open Replicator migration I/O path goes from the:
Source ArraySANTarget Array
Array I/O conflicts
In the case of a push migration, both the production and migration
applications utilize resources in the source storage array (the control
Symmetrix VMAX or Symmetrix DMX array). In the case of hot pull
migration, both the production and migration applications utilize
resources in the target ?torage array (the control Symmetrix VMAX or
Symmetrix DMX array). The key contended resource in the storage
array I/O path is the control Symmetrix VMAX (or Symmetrix DMX)
front-end fibre director (FA) that connects the array to the host
through the SAN. When the FA is used for both production and
migration resources, there is conflict when there is not enough excess
capacity to meet both demands fully. And even if there is enough
capacity to meet the dual demands, there is still queuing conflicts
when competing requests arrive simultaneously. One request will be
serviced first, while the other must wait resulting in an extended
service time. Within the Symmetrix VMAX (or Symmetrix DMX)
there also will be competition for cache memory and back-end disk
I/O, however this competition has less impact due to the
asynchronous nature of performance impact in an integrated cached
disk array (ICDA). Performance tuning approaches for Open
Replicator cache memory and back-end disk I/O are not any different
than tuning for these resources with other applications.
Limiting Open Replicator resource usage
Using a separate management host
As a SAN-based migration product, Open Replicator avoids I/O
conflicts at the production host. The command management I/O for
Open Replicator uses a very small amount of prod? ction host I/O
resources if executed on the production host. For this reason (and to
avoid similarly low impact CPU utilization) sometimes Open
Replicator migration is directed from a separate management host.
The Open Replicator management CPU and I/O resource usage is
probably too small to have a significant impact, so the use of a
separate management host is typically a result of conforming to site
defined practices. Note that certain cleanup migration phase steps
can only be executed on the production host. Correspondingly,
PowerPath Migration Enabler (PPME) needs to be executed on the
production host. Federated Live Migration (FLM) is designed to be
executed on a separate management host, limiting application host
operations to the minimum.
Limiting Symmetrix FA director competition
Given that both production and migration applications are
contending for FA resources, tuning FA performance is a matter of
limiting one application's I/O requests to the benefit of the other.
Most migrations will actually employ multiple strategies to achieve
this.
One principle strategy involves scheduling. Often, the migration
window is during a lower production application resource usage
period. Scheduling the migration at this time has the double benefit
of more resources being available for the migration while the impact
on the production application is less critical. Depending on the length
of the migration window, and the consequence of production
application slowdowns during this period, it may be possible to tune
the migration to use even more resources in order to complete the
migration within the migration window timeframe.
A second strategy involves using independent FA resources to permit
both production and migration applications to avoid resource
contention with each other, though each still may not find its
independent resources sufficient to avoid performance issues. Only
Limiting Open Replicator resource usage 273
Open Replicator cold migrations can fully utilize this strategy. Open
Replicator hot migrations require all FA directors that are mapped to
the control devices to be configured to support Copy on First
Access/Write (COFx) operations. The ceiling setting can be used to
limit Open Replicator hot migration I/Os to only COFx I/Os.
A third strategy involves limiting one application's FA I/O requests
to the benefit of the other. Whether this can be done by production
applications is beyond the scope of this TechBook. As introduced in
Tuning Open Replicator, on page 63 the Open Replicator I/O
requests can be limited through setting the ceiling value, setting the
pace value and temporarily disabling background copying.
Migration options can impose performance delays
Certain Open Replicator migration configurations result in systemic
performance delays in return for a desired feature. For example, hot
migration COFx activity means that the production I/O is delayed
until the migration copy operation preserving the activate
point-in-time completes first. This delay can be avoided by using a
cold migration configuration. This delay can be minimized in the case
of hot push, by using the -precopy option to reduce the number of
tracks not yet copied to the remote requiring COFW I/Os (Note:
precopy requires Enginuity 5772 or higher). Hot pull migrations that
utilize the -donor_update option also have a systemic performance
delay of copying the write I/Os to the remote before allowing the
production write to the control to complete.
Tuning Open Replicator 275
Tuning Open Replicator
Open Replicator performance can be tuned by static configuration
choices or using dynamic commands both before and during a
migration to set ceiling, pace or nocopy mode.
Static configuration limits on Open Replicator resource use
The goal of static configuration for performance is to separate the FA
director resources used by Open Replicator migrations from
production applications. If the Symmetrix VMAX (or Symmetrix
DMX) has enough FA director ports, then Open Replicator cold
migrations can be configured to use independent FA director ports.
This can be achieved by mapping the control devices to one or more
FA director ports not used by production applications. Then, these
migration control FA director ports would be zoned and LUN masked
to see the remote array directors and devices. If there are no free FA
director ports, then cold migrations can be configured to use a subset
of the FA director ports used by production applications, thus
limiting the FA director ports where there is competition for
resources.
For hot migration configurations, it is still possible to partially
achieve the use of independent FA director ports. The static
configuration part is the same as for cold migrations - mapping the
control devices to one or more FA director ports not used by
production applications. However, hot migration configurations
require all control FA director ports to be zoned and LUN masked for
COFx access, thus all of the production application FA director ports
must be configured for Open Replicator use. Fortunately, the ceiling
setting can be used to severely limit the use of the shared FA director
ports. Setting the ceiling value to zero percent means that a FA
director port will not be used for any background copy migration
operations; it will only be used for COFx activity as needed.
Dynamic limits on Open Replicator resource use
Open Replicator provides three alternatives for limiting Open
Replicator use of shared FA director ports that can be changed before
and during a migration: the ceiling parameter which limits fibre
bandwidth that can be used by Open Replicator, the pace parameter
which defines delays added between Open Replicator operations,
and the nocopy mode which suspends Open Replicator background
copy activity.
Ceiling
The ceiling parameter is the primary and most predictable tuning
mechanism because it directly sets a maximum FA director port
bandwidth that can be used by Open Replicator. The default ceiling
value is NONE, theoretically allowing Open Replicator to use up to 100
percent of the FA port bandwidth. Setting the ceiling value to any
value less than 100 percent limits the potential Open Replicator use of
the FA port, and overrides any setting of the pace value. This value
can be set prior to the migration or changed at any time during the
migration. A command can be used to set the same ceiling value for
all FA ports, or the ceiling value for each FA port can be set
independently. If the production applications have time of day or
week variations that might tolerate or suffer more from a higher
contention for resources at certain times, then the ceiling value can be
dynamically adjusted. Note that the command that lists ceiling values,
also displays the current Open Replicator use of bandwidth,
effectively reporting whether all the capacity up to the current ceiling
value is actually being used.
Pace
The pace parameter limits the use of all FA ports used for a particular
Open Replicator session by inserting delays between Open Replicator
I/O requests. Although this effectively limits use of the FA port, it
also guarantees that the migration will take longer, even if there is
spare capacity in the FA port. The range of valid values is from 0 to
10, with a default value of 5. A pace setting of zero does not insert any
delay. A value of 10 inserts the maximum delay. The parameter value
can be displayed using the -detail option with the query or list
actions. The PPME throttle setting is an alternate interface to the Open
Replicator pace setting. The pace value is ignored for all participating
director/port combinations where the ceiling value is not NONE.
Nocopy mode
The ability to dynamically switch an Open Replicator session into
nocopy mode provides a simple way to temporarily suspend all but
COFx migration I/O requests. The most common use of nocopy mode
is to initially set a hot pull session in nocopy mode so that initial high
COFA I/O is not joined by any background copy I/O. This setting
has to be temporary because it is necessary to set the mode back to
Tuning Open Replicator 277
background copy in order for the migration to complete with all
tracks copied to the target. The current mode setting can be
determined by interpreting the C flag setting displayed in the output
of the query or list actions.
Monitoring Open Replicator performance
For this monitoring session, a hot push session using the same
devices as in Setup step 5: Prepare Open Replicator session pairs
file on page 174 was created with ceiling set to 10 percent.
symrcopy query
Open Replicator performance can be monitored using the symrcopy
query command or SMC equivalent as shown in previous chapters.
The change from one query output to the next can be used as a
performance measure combined with elapsed time. The decrease in
the number of Protected Tracks, or the increase in Done % are
the changing values. For example, soon after activating the session,
the query output could look something like this:
c:\>symrcopy -session hot_push query
Session Name : hot_push
--------------------------- --------------------- ----- ---------- ----
Protected
SID:symdev Tracks Identification RI CDSHU CTL<=>REM (%)
----------------- --------- ------------------ -- ----- ---------- ----
000190300359:0098 65072 000187720450:0144 SD XXXX. CopyInProg 0
Total ---------
Track(s) 259548
. . .
symrcopy list ceiling
The output of symrcopy list ceiling can be used to show the
actual MB/sec used by Open Replicator for each director. In the
example below, the ceiling setting for directors 2C:0 and 15C:0 is 10
percent. The maximum MB/sec for each FA director port is 150
MB/sec. The actual MB/sec displayed in the example is 15 and 14
MB/sec, equivalent within rounding error to 10 percent of 150
MB/sec or 15 MB/sec. Therefore in this case the ceiling setting is
limiting the Open Replicator throughput.
Monitoring Open Replicator performance 279
c:\>symrcopy -sid 359 list ceiling
Max Set Actual
Dir:P (MB) (%) (MB)
----- ---- ---- ------
01C:0 150 NONE 0
01C:1 150 NONE 0
02C:0 150 10 15
02C:1 150 NONE 0
15C:0 150 10 14
15C:1 150 NONE 0
16C:0 150 NONE 0
16C:1 150 NONE 0
c:\>
symstat with -RepType rcopy
The symstat command has three status actions that use the Open
Replicator specific -RepType rcopy option. The first example uses
the -type REQUESTS option. The short interval of 10 seconds (-i
10) and count of 3 (-c 3) quickly generate two sets of calculated
delta output. Best practice would use a much longer interval to both
provide more meaningful data and to avoid more frequent polling for
performance data than really necessary. Notice the values for PUSH
KB/sec for each of the four control devices.
c:\>symstat -type REQUESTS -sid 359 -reptype rcopy -i 10 -c 3
RCopy
--------------
Device KB/sec
14:19:11 PULL PUSH
14:19:21 0095 (DRIVE15) 0 8908
0096 (DRIVE16) 0 9414
0097 (DRIVE17) 0 5804
0098 (DRIVE18) 0 6457
14:19:31 0095 (DRIVE15) 0 9664
0096 (DRIVE16) 0 8857
0097 (DRIVE17) 0 5798
0098 (DRIVE18) 0 5817
c:\>
The second symstat example uses the -dir ALL option, which
could also have specified an individual director. Notice the Open
Replicator cache usage for directors 2C and 15C.
c:\>symstat -dir all -sid 359 -reptype rcopy -i 10 -c 3
RCopy Cache Requests/sec %RW
14:19:38 Director MB/sec READ WRITE RW Hits
14:19:49 FA-1C 0 0 0 0 N/A
FA-2C 14 283 0 283 71
FA-15C 14 280 0 280 69
FA-16C 0 0 0 0 N/A
------ ------ ------ ------ ---
28 563 0 563 139
14:19:59 FA-1C 0 0 0 0 N/A
FA-2C 15 275 0 275 45
FA-15C 14 276 0 276 43
FA-16C 0 0 0 0 N/A
------ ------ ------ ------ ---
29 551 0 551 87
c:\>
The third symstat example uses the -type PATH option, which has
two sorting options; -by_session is used here. Notice the total and
remaining tracks to be copied per device.
c:\>symstat -type path -sid 359 -reptype rcopy -i 10 -c 2 -by_session
Time Session Control Target Tracks Director RCopy
Stamp Name Device Destination Total Remaining Port Ceiling
14:20:49 hot_pu* 0095 000187720450:0141 65535 51048 FA-2C:0 10
N/A 65535 51048 FA-15C:0 10
hot_pu* 0096 000187720450:0142 65535 50995 FA-2C:0 10
N/A 65535 50995 FA-15C:0 10
hot_pu* 0097 000187720450:0143 65535 54568 FA-2C:0 10
N/A 65535 54568 FA-15C:0 10
hot_pu* 0098 000187720450:0144 65535 54708 FA-2C:0 10
N/A 65535 54708 FA-15C:0 10
Time Session Control Target Tracks Director RCopy
Stamp Name Device Destination Total Remaining Port Ceiling
14:20:59 hot_pu* 0095 000187720450:0141 65535 49689 FA-2C:0 10
N/A 65535 49689 FA-15C:0 10
hot_pu* 0096 000187720450:0142 65535 49696 FA-2C:0 10
N/A 65535 49696 FA-15C:0 10
hot_pu* 0097 000187720450:0143 65535 53567 FA-2C:0 10
N/A 65535 53567 FA-15C:0 10
hot_pu* 0098 000187720450:0144 65535 53556 FA-2C:0 10
N/A 65535 53556 FA-15C:0 10
c:\>
Monitoring Open Replicator performance 281
The fourth symstat example again uses the -type PATH option,
this time using the -by_port sorting option. In addition to the total
and remaining tracks to be copied per device, the MB/sec transfer
rate is listed for each director port.
c:\>symstat -type path -sid 359 -reptype rcopy -i 10 -c 2 -by_port
Time Director RCopy Port RCopy Control Tracks Session
Stamp Port Ceiling MB/sec MB/sec Device Total Remaining Name
14:21:04 FA-2C:0 10 - - 0095 65535 49153 hot_pu*
0096 65535 49054 hot_pu*
0097 65535 53014 hot_pu*
0098 65535 53000 hot_pu*
FA-15C:0 10 - - 0095 65535 49153 hot_pu*
0096 65535 49054 hot_pu*
0097 65535 53014 hot_pu*
0098 65535 53000 hot_pu*
Time Director RCopy Port RCopy Control Tracks Session
Stamp Port Ceiling MB/sec MB/sec Device Total Remaining Name
14:21:14 FA-2C:0 10 11 15 0095 65535 47598 hot_pu*
0096 65535 47818 hot_pu*
0097 65535 52000 hot_pu*
0098 65535 51978 hot_pu*
FA-15C:0 10 12 14 0095 65535 47598 hot_pu*
0096 65535 47818 hot_pu*
0097 65535 52000 hot_pu*
0098 65535 51978 hot_pu*
c:\>
Tuning for applications sensitive to response time
In order to maintain the activate point-in-time, Open Replicator hot
migration COFx I/Os will occur even if background copy migration
activity is already using the allowed ceiling percentage of FA port
bandwidth. An example of a production application that is sensitive
to response time is MicroSoft Cluster Server (MSCS). MSCS performs
frequent SCSI reservation queries on its LUNs, to ensure that the
active nodes still have SCSI reservations on the LUNs in order to
prevent a split brain cluster. If a particular active MSCS node sees that
it has lost its SCSI reservation, or does not receive an
acknowledgement that it still has a reservation quickly enough, it will
take its resources offline to prevent data corruption due to a split
brain. Excessive COFx activity on FA ports that do not have enough
bandwidth can slow down these SCSI reservation responses to a
point that MSCS will go offline.
The Open Replicator migration use of bandwidth can be mitigated
with a number of tuning strategies. For hot push, precopy should be
utilized reducing COFW I/Os at activate time. Sessions should
initially be in nocopy mode, and only switched to background copy
mode, once COFx activity starts to slow down. Start with a relatively
low ceiling (1520%), and then gradually increase the ceiling, keeping
a close watch on host I/Os per second (IOPS) and response time
avoiding allowing Open Replicator to affect the production
applications' response times too much.
Troubleshooting 283
B
This appendix provides log information that correlates with the
examples presented in Chapters 49. Log examples are shown for
commands resulting in both success and failure. Also included is an
example of an Enginuity 5773 enhancement of Open Replicator that
enables reactivating a failed differential push session. The topics
covered include:
Solutions Enabler logs ..................................................................... 284
Audit Log .......................................................................................... 290
PowerPath Migration Enabler logs ............................................... 292
Reactivate Failed Session ................................................................ 295
Troubleshooting
Troubleshooting
Solutions Enabler logs
The Solutions Enabler log directory is a subdirectory of the working
solutions enabler directory. If the default directories were used for
Solutions Enabler installation, the logs can be found in:
UNIX: /var/symapi/log
Windows C:\Program Files\EMC\SYMAPI\log
Inside the log directory, there are two log file types related to this
TechBook: symapi-YYYYMMDD.log and
symntctl-YYYYMMDD.log.
Cold push example log entries
For example, the log entries related to operations in Chapter 4, Cold
Push to CLARiiON Setup Example, and Chapter 5, Cold Push to
CLARiiON Migration Example, are displayed in the next eight
subsections.
Open Replicator create and not_ready control devices
The following excerpt from the symapi-20080618.log and
symapi-20080619.log corresponds to the example shown in
Verify all with symrcopy create on page 84:
06/18/2008 16:17:03.854 1896 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy CREATE (PUSH) (COLD)
06/18/2008 16:17:03.854 1896 1 EMC:SYMRCOPY validateCreate Cannot CREATE (COLD) session on
dev:00A0, sid:000190300359, it is not NR
06/18/2008 16:17:03.854 1896 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operation FAILED.
(SYMAPI_C_INV_DEVICE_RDY_STATUS)
06/18/2008 16:20:08.434 1907 STARTING a 'NOT_READY' control operation.
06/18/2008 16:20:08.435 1907 1 EMC:SYMCLI SymDevListControl() symdev list: symid: 000190300359
director: N/A, port: N/A ()
06/18/2008 16:20:08.488 1907 1 EMC:SYMCLI test_dev_state() TestState: DEV_STATE_NOT_READY_DEVICE,
SymID: 000190300359 Dev: (00A3) Remote: 0, Src: 0, BCV: 0, cfg: Inv Dev sts: RW, SA: RW, RA: RW, DA: RW, Link: RW,
Consistency: DIS, Susp Pend: 0, BCV: 0, BCV Paired: 0 BCV State: NeverEstab, InvR1: 0, InvR2: 0, R2WPonR1: 0 Mode: SYN,
Dom: ENB, ACp: OFF, API sts: SYMAPI_C_INV_DEVICE_RDY_STATUS
06/18/2008 16:20:08.508 1907 Set device(s) Not Ready at local Symmetrix.................Done.
06/18/2008 16:20:08.527 1907 The 'NOT_READY' control operation SUCCEEDED.
06/18/2008 16:21:43.511 1915 STARTING a 'READY' control operation.
06/18/2008 16:21:43.559 1915 1 EMC:SYMCLI test_dev_state() TestState: DEV_STATE_READY_DEVICE,
SymID: 000190300359 Dev: (00A3) Remote: 0, Src: 0, BCV: 0, cfg: Inv Dev sts: NR, SA: RW, RA: RW, DA: RW, Link: RW,
06/18/2008 16:21:43.579 1915 Set device(s) Ready at local Symmetrix....................Done.
06/18/2008 16:21:43.598 1915 The 'READY' control operation SUCCEEDED.
SymID: 000190300359 Dev: (00A3) Remote: 0, Src: 0, BCV: 0, cfg: Inv Dev sts: RW, SA: RW, RA: RW, DA: RW, Link: RW,
Solutions Enabler logs 285
Troubleshooting
. . .
06/19/2008 16:59:45.664 2545 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy CREATE (PUSH) (COLD)
06/19/2008 16:59:45.665 2545 STARTING a RCOPY 'CREATE' operation.
06/19/2008 16:59:53.138 2545 1 EMC:SYMRCOPY doPaceOnDev Setting throttle to 0xff, dev:0xa0
06/19/2008 16:59:53.172 2545 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operation SUCCEEDED.
TimeFinder/Mirror establish and Open Replicator terminate
The following excerpt from the symapi-20080624.log
corresponds to the example shown in Initial TimeFinder/Mirror
establish on page 95:
06/24/2008 18:21:30.926 4327 1 EMC:SYMMIR evaluate_dev BCV Device: 0080 (000190300359) is
an RCOPY push source in created/recreated state
an RCOPY push source in created/recreated state 06/24/2008 18:22:20.621 4332 1 EMC:SYMRCOPY
SymRemoteCopyControl STARTING a REMOTE Copy TERMINATE
06/24/2008 18:22:20.621 4332 STARTING a RCOPY 'TERMINATE' operation.
06/24/2008 18:22:21.219 4332 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'TERMINATE' operation SUCCEEDED.
06/24/2008 18:22:33.929 4335 1 EMC:SYMMIR SymDgBcvControl() dg: cpgroup, ldev: , SymID: 000190300359,
symdev: , bcvdev: , flags: (exact)
06/24/2008 18:22:33.933 4335 STARTING a BCV 'ESTABLISH' operation for 4 [SRC-TGT] Pairs:
06/24/2008 18:22:33.977 4335 Symm 000190300359 Number of Pairs: 4 Operation Flags: MultiEstablish
06/24/2008 18:22:33.986 4335 Source-Target Devices: [ 00A0-0080 00A1-0081 00A2-0082 00A3-0083 ]
06/24/2008 18:22:34.409 4335 The BCV 'ESTABLISH' operation SUCCEEDED.
TimeFinder/Mirror split
corresponds to the example shown in TimeFinder/Mirror split on
page 96:
symdev: , bcvdev: , flags:
06/24/2008 18:46:36.231 4347 STARTING a BCV 'SPLIT' operation for 4 [SRC-TGT] Pairs:
06/24/2008 18:46:36.266 4347 Symm 000190300359 Number of Pairs: 4 Operation Flags: MultiNone
06/24/2008 18:46:42.755 4347 The BCV 'SPLIT' operation SUCCEEDED.
Open Replicator create and not_ready control devices reprise
corresponds to the examples shown in Cold control devices must be
Not Ready on page 98 and Create action options on page 99:
06/24/2008 18:46:56.404 4350 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy CREATE (PUSH)
(COLD) (DIFFERENTIAL)
06/24/2008 18:46:56.405 4350 1 EMC:SYMRCOPY validateCreate Cannot CREATE (COLD) session on
dev:0080, sid:000190300359, it is not NR
(SYMAPI_C_INV_DEVICE_RDY_STATUS)
06/24/2008 18:47:55.249 4354 1 EMC:SYMCLI SymDgControl() grp: cpgroup symid: 000190300359
ldev: director: N/A, port: N/A ()
SymID: 000190300359 Dev: (0080) Remote: 0, Src: 0, BCV: 1, cfg: Inv Dev sts: RW, SA: RW, RA: RW, DA: RW, Link: RW,
Troubleshooting
06/24/2008 18:48:20.104 4357 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy CREATE (PUSH)
(COLD) (DIFFERENTIAL)
06/24/2008 18:48:20.104 4357 STARTING a RCOPY 'CREATE' operation.
06/24/2008 18:48:27.841 4357 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operation SUCCEEDED.
Open Replicator activate and set ceiling
corresponds to the examples shown in Migration step 10: symrcopy
activate on page 102 and Migration step 12: symrcopy set ceiling
on page 103:
06/24/2008 21:45:44.987 1646 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy ACTIVATE
06/24/2008 21:45:44.987 1646 STARTING a RCOPY 'ACTIVATE' operation.
06/24/2008 21:45:45.033 1646 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'ACTIVATE' operation SUCCEEDED.
06/24/2008 21:47:09.376 1662 1 EMC:SYMRCOPY SymDirectorQosSet STARTING a QOS 'SymDirectorQosSet'
operation - symid: 000190300359, start dev: 0x0000, num devs: 0. LRU set: F , Pace: BCV(F), RDF(F), BCS(F), MIR(F), SNAP(F)
06/24/2008 21:47:09.385 1662 1 EMC:SYMRCOPY SymDirectorQosSet QOS 'SymDirectorQosSet' operation
SUCCEEDED.
06/24/2008 21:47:26.422 1665 1 EMC:SYMRCOPY SymDirectorQosSet STARTING a QOS 'SymDirectorQosSet'
operation - symid: 000190300359, start dev: 0x0000, num devs: 0. LRU set: F , Pace: BCV(F), RDF(F), BCS(F), MIR(F), SNAP(F)
06/24/2008 21:47:26.442 1665 1 EMC:SYMRCOPY SymDirectorQosSet QOS 'SymDirectorQosSet' operation
SUCCEEDED.
TimeFinder/Mirror incremental update of control devices
corresponds to the example shown in Incrementally update control
devices from production devices on page 106:
06/25/2008 10:45:14.430 1991 STARTING a BCV 'INCREMENTAL_ESTABLISH' operation for 4 [SRC-TGT] Pairs:
06/25/2008 10:45:14.482 1991 Symm 000190300359 Number of Pairs: 4 Operation Flags: MultiEstablish
06/25/2008 10:45:14.873 1991 The BCV 'INCREMENTAL_ESTABLISH' operation SUCCEEDED.
06/25/2008 10:55:23.814 2019 STARTING a BCV 'SPLIT' operation for 4 [SRC-TGT] Pairs:
06/25/2008 10:55:23.859 2019 Symm 000190300359 Number of Pairs: 4 Operation Flags: MultiNone
06/25/2008 10:55:25.243 2019 The BCV 'SPLIT' operation SUCCEEDED.
06/25/2008 10:56:21.917 2028 1 EMC:SYMCLI SymDgControl() grp: cpgroup symid: 000190300359
ldev: director: N/A, port: N/A ()
SymID: 000190300359 Dev: (0080) Remote: 0, Src: 0, BCV: 1, cfg: Inv Dev sts: RW, SA: RW, RA: RW, DA: RW, Link: RW,
Consistency: DIS, Susp Pend: 0, BCV: 1024, BCV Paired: 1 BCV State: Synchronized, InvR1: 0, InvR2: 0, R2WPonR1: 0 Mode:
SYN, Dom: ENB, ACp: OFF, API sts: SYMAPI_C_INV_DEVICE_RDY_STATUS
Open Replicator incremental update of remote devices
corresponds to the example shown in Incrementally update remote
devices from control devices on page 107:
06/25/2008 10:56:36.792 2031 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy RECREATE
06/25/2008 10:56:36.792 2031 STARTING a RCOPY 'RECREATE' operation.
06/25/2008 10:56:37.207 2031 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'RECREATE' operation SUCCEEDED.
06/25/2008 10:57:05.256 2034 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy ACTIVATE
Troubleshooting
06/25/2008 10:57:05.256 2034 STARTING a RCOPY 'ACTIVATE' operation.
06/25/2008 10:57:05.513 2034 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'ACTIVATE' operation SUCCEEDED.
Open Replicator terminate and make source devices inaccessible
The following excerpt from the symapi-20080625.log and
symapi-20080709.log corresponds to the examples shown in
Migration step 15: Verify migration and symrcopy terminate on
page 110 and Cleanup step 16: Make source devices host
inaccessible on page 112:
06/25/2008 13:24:30.940 2136 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy TERMINATE
06/25/2008 13:24:30.941 2136 STARTING a RCOPY 'TERMINATE' operation.
06/25/2008 13:24:31.543 2136 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'TERMINATE' operation SUCCEEDED.
. . .
07/09/2008 01:46:10.902 3594 1 EMC:SYMMASK emcSetupLunMaskSessi Skipping call to emcSymLockSym
07/09/2008 01:56:15.452 3614 1 EMC:SYMMASK SymDevMaskSessionSta Successfully started a Symmetrix
device masking session for Symmetrix 000190300359 with devmask handle 100
07/09/2008 01:56:15.594 3614 1 EMC:SYMMASK emcAddorRemoveDevice Removing the following devices from
the device masking database for Symmetrix 000190300359 by WWN 210000e08b927df4 for director 34 for port 0
07/09/2008 01:56:15.681 3614 1 EMC:SYMMASK SymDevMaskSessionEnd Successfully ended a Symmetrix device
masking session for Symmetrix 000190300359
07/09/2008 01:57:16.538 3621 1 EMC:SYMMASK emcAddorRemoveDevice Removing the following devices from
the device masking database for Symmetrix 000190300359 by WWN 210000e08b925cf5 for director 47 for port 0
07/09/2008 01:57:33.262 3624 1 EMC:SYMMASK SymDevMaskControl Refreshing FAs with contents of device
masking database for Symmetrix 000190300359
Hot pull example log entries
The log entries related to Chapter 6, Hot Pull from CLARiiON
Migration Example, are very similar to the ones shown for the cold
push operation above. Therefore only the error related log entries for
missing zoning and missing masking are displayed in the following
sections.
Missing zoning error
corresponds to the example shown in Discover missing zoning with
symrcopy create on page 131:
07/17/2008 09:36:20.703 2328 3852 STARTING a RCOPY 'CREATE' operation.
07/17/2008 09:36:21.250 2328 3852 EMC:SYMRCOPY checkForCreateFai Create failed on dev:0091,
sid:000190300359, status:loc_sts:0x8 SYSC_SESSION_DISCOVER_FAILED
07/17/2008 09:36:21.250 2328 3852 EMC:SYMRCOPY map_discover_erro loc_dir:02C, rem_num:0,
rem_sts:0x1SANCOPY_DEV_SUCCESS
rem_sts:0xaSANCOPY_DEV_NO_REMOTE_TARGETS
Troubleshooting
07/17/2008 09:36:21.250 2328 3852 EMC:SYMRCOPY checkForCreateFai Discover failed on dev:0091,
sid:000190300359, status:10090
(SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)
Missing masking error
corresponds to the example shown in Discover missing LUN
masking with symrcopy create on page 133:
07/17/2008 11:16:18.265 2784 2780 STARTING a RCOPY 'CREATE' operation.
07/17/2008 11:16:18.875 2784 2780 EMC:SYMRCOPY checkForCreateFai Create failed on dev:0091,
sid:000190300359, status:loc_sts:0x8 SYSC_SESSION_DISCOVER_FAILED
rem_sts:0x1SANCOPY_DEV_SUCCESS
rem_sts:0x6SANCOPY_DEV_WWID_NOT_FOUND
07/17/2008 11:16:18.890 2784 2780 EMC:SYMRCOPY checkForCreateFai Discover failed on dev:0091,
sid:000190300359, status:10090
(SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)
Stopping and restarting application using the targets
The following excerpt from the symntctl-20080717.log
corresponds to the examples shown in Migration step 9: Stop the
applications on page 136 and Migration step 11: Restart
applications using targets on page 139:
07/17/08 16:13:51InitLog Symntctl Log Opened
07/17/08 16:13:51GetEnvVar Enter GetEnvVar()
07/17/08 16:13:51GetEnvVar Enter GetEnvVar()
07/17/08 16:13:51InitEventLog Enter InitEventLog()
07/17/08 16:13:51SymapiConnect Enter SymapiConnect()
07/17/08 16:13:51ProcessInput Enter ProcessInput()
07/17/08 16:13:51RebuildInputCommand Enter RebuildInputCommand()
07/17/08 16:13:51ProcessInput symntctl.exe umount -drive L:
07/17/08 16:13:51ProcessUnmount Enter ProcessUnmount()
07/17/08 16:13:51VdsServiceInit Enter VdsServiceInit()
07/17/08 16:13:51CoCreateInstance Enter CoCreateInstance()
07/17/08 16:13:51GetVolumeNameFromVolumeGuid Enter GetVolumeNameFromVolumeGuid()
07/17/08 16:13:51IsVolumeReady Enter IsVolumeReady()
07/17/08 16:13:51GetVdsVolumeByName Enter GetVdsVolumeByName()
07/17/08 16:13:51GetVolumeExtentInfo Enter GetVolumeExtentInfo()
07/17/08 16:13:51GetDiskNumFromDiskGuid Enter GetDiskNumFromDiskGuid()
07/17/08 16:13:51SymPdevShow Enter SymPdevShow()
07/17/08 16:13:51IsDiskReady Enter IsDiskReady()
07/17/08 16:13:51GetDisk Enter GetDisk()
07/17/08 16:13:51SymPdevShow Enter SymPdevShow()
07/17/08 16:13:51GetDiskVolumeInfo Enter GetDiskVolumeInfo()
07/17/08 16:13:51SplitVolumeName Enter SplitVolumeName()
07/17/08 16:13:51IsDiskReady TRUE
07/17/08 16:13:51IsVolumeReady TRUE
07/17/08 16:13:51IsVolumeClustered Enter IsVolumeClustered()
07/17/08 16:13:51CreateFile Enter CreateFile()
07/17/08 16:13:51DeviceIoControl IOCTL_VOLUME_IS_CLUSTERED
07/17/08 16:13:51DeviceIoControl WIN32 Error: 1 Incorrect function.
07/17/08 16:13:51IsVolumeClustered SYMNTCTL Error: 1 The operation failed.
07/17/08 16:13:51GetVdsVolumeByName Enter GetVdsVolumeByName()
07/17/08 16:13:51IoctlUnmount Enter IoctlUnmount()
07/17/08 16:13:51CreateFile Enter CreateFile()
07/17/08 16:13:51DeviceIoControl FSCTL_LOCK_VOLUME
Troubleshooting
07/17/08 16:13:51FlushFileBuffers Enter FlushFileBuffers()
07/17/08 16:13:51DeviceIoControl FSCTL_DISMOUNT_VOLUME
07/17/08 16:13:51IoctlUnmount Successfully dismounted the volume.
07/17/08 16:13:51DeviceIoControl IOCTL_VOLUME_OFFLINE
07/17/08 16:13:51IoctlUnmount Successfully took the volume offline.
07/17/08 16:13:51DeviceIoControl FSCTL_UNLOCK_VOLUME
07/17/08 16:13:51DeleteVolumeMountPoint Enter DeleteVolumeMountPoint()
07/17/08 16:13:51IoctlUnmount Successfully removed all access paths to
the volume.
07/17/08 16:13:51SymapiDisconnect Enter SymapiDisconnect()
07/17/08 16:13:51Action Complete, exiting...
07/17/08 16:13:51EndEventLog Enter EndEventLog()
07/17/08 16:13:51EndLog Symntctl Log Closed
. . .
07/17/08 17:33:38ProcessInput symntctl.exe rescan
. . .
07/17/08 17:55:53ProcessInput symntctl.exe update -sid 359 -symdev 91
. . .
07/17/08 18:00:42ProcessInput symntctl.exe mount -drive L: -sid 359
-symdev 91
. . .
Troubleshooting
Audit Log
Data is written to a common audit file during Symmetrix control
operations initiated by host applications. The common audit log
correlates activity from all hosts into one file that is stored in the
Symmetrix. The symaudit command and the SMC Symmetrix
Admin - SymAudit Records display can be used to filter and display
the common audit log file for a specified Symmetrix array.
The symaudit list example below filters for Open Replicator
actions on 07/17/2008. The records briefly listed below correspond to
the examples shown in Successful create verifies hot pull setup on
page 135 and Migration step 10: symrcopy activate on page 138:
c:\>symaudit list -sid 359 -function_class rcopy -start_date 07/17 -end_date 07/18
A U D I T L O G D A T A
Record Function Action
Number Date Time Application Host Class Code
------ -------- -------- ---------------- ------------ -------- ---------
8849 07/17/08 12:27:09 SYMRCOPY LICOD194 RCopy Create
8861 07/17/08 17:21:03 SYMRCOPY LICOD194 RCopy Activate
. . .
c:\>
Audit Log 291
Troubleshooting
Using the -v option shows details of each audit log record. For
example, details for the three Create audit log entries numbered
8849-8851:
c:\>symaudit list -sid 359 -v -record_num 8849 -n 3
A U D I T L O G D A T A
Record Number : 8849
Records in Seq : 2
Offset in Seq : 1
Time : 07/17/08 12:27:09
Vendor ID : EMC Corp
Application ID : SYMRCOPY
Application Version : 6.5.1.0
API Library : SEK
API Version : V6.5.1.0 (Edit Level: 882)
Host Name : LICOD194
OS Name : WinNT
OS Revision : 5.2.3790Se
Client Host :
Process ID : 00003728
Task ID : 00003732
Function Class : RCopy
Action Code : Create
Text : STARTING a RCopy 'CREATE' operation for Device List. O
ptions=(Hot, Pull, CopyMode, DonorUpdate)
Username : H:LICOD194\Administrator
Activity ID : SE1ceeb91751
Records in Seq : 2
Offset in Seq : 2
Time : 07/17/08 12:27:09
. . .
Text : Symm 000190300359 Ctrl-Rem Devices: [ 0091-HK190807410
004:0 0092-HK190807410004:1 0093-HK190807410004:2 0094-HK190807410004:3 ]
Records in Seq : 1
Offset in Seq : 1
Time : 07/17/08 12:27:10
. . .
Text : The Rcopy 'CREATE' operation SUCCESSFULLY COMPLETED.
c:\>
Troubleshooting
PowerPath Migration Enabler logs
PowerPath Migration Enabler (PPME) can log audit and error log
messages to a common file. The PowerPath Migration Enabler User
Guide includes details on how to configure the Solaris host
syslog.conf(4) file to write local0.info messages to a
common log file. On Windows hosts these messages appear in the
Event Log without any additional configuration.
Figure 84 shows the Windows Computer Management screen with
the Event Viewer selected so that Application Events are displayed.
The selected entry is of type Error and the source is EmcpLogMsgs
which includes PPME messages
Figure 84 Windows Event Viewer with PPME error message selected
ICO-IMG-000590
PowerPath Migration Enabler logs 293
Troubleshooting
Double-clicking on the selected row or selecting the menu items
Action > Properties displays the details of the message in Figure 85,
which shows the missing PPME license corresponding to PPME
license required on page 217.
Figure 85 Event Properties detail for missing PPME license
ICO-IMG-000591
Troubleshooting
Figure 86 shows part of the Event Viewer screen with an
informational PPME message selected.
Figure 86 Windows Event Viewer with PPME error message selected
Figure 87 shows the Event Properties detail for a powermig setup
command that was executed in PPME Setup steps 56: powermig
setup on page 215.
Figure 87 Event Properties detail for missing PPME license
ICO-IMG-000592
ICO-IMG-000593
Reactivate Failed Session 295
Troubleshooting
Reactivate Failed Session
Prior to Enginuity 5773, the state of the Open Replicator session was
set to Failed ?f a transient network or device issue was encountered.
The only option available from the Failed state was to terminate
the session. Enginuity version 5773 allows failed sessions to be
reactivated as long as certain criteria are met. Only sessions where no
new data has been written to the control device since the session
failed can be reactivated.
If new data has been written, the session should be terminated. This
is because when a hot push session fails, a write to the control device
succeeds, as does a full track write on a failed hot pull session. This
could lead to a situation where data on the control device that still
needs to be pulled or pushed is not part of the initial point-in-time.
Reactivating the Open Replicator session in these circumstances may
result in data being overwritten on the control device on a pull or
inconsistent data being written to the remote device on a push.
In the example shown below, the same Open Replicator device pairs
in Chapter 7, Hot Pull from Symmetrix Migration Example, were
used for a hot push. The remote devices were made not_ready to
simulate a transient failure. Notice the Status in the query output
below indicates both the failed state and that the failed session is
eligible to be reactivated:
--------------------------- --------------------- ----- ---------- ----
Protected
----------------- --------- ------------------ -- ----- ---------- ----
000190300359:0098 29861 000187720450:0144 SD XXXX. Failed (*) N/A
000190300359:0097 40786 000187720450:0143 SD XXXX. Failed (*) N/A
000190300359:0096 42160 000187720450:0142 SD XXXX. Failed (*) N/A
000190300359:0095 28459 000187720450:0141 SD XXXX. Failed (*) N/A
Total ---------
Track(s) 141266
MB(s) 8829.1
. . .
Flags:
. . .
c:\>
Troubleshooting
Once the transient error condition is corrected (in this case making
the remote devices ready), the session can be reactivated. The syntax
to reactivate the session is the same as that used to originally
activate the session:
c:\>symrcopy -session hot_push activate -consistent
with session name 'hot_push' (y/[n]) ? y
with session name 'hot_push'. Please wait...
with session name 'hot_push'.
c:\>
After a short delay, the query action is repeated and the results show
that the Status has changed back to CopyInProg. Additionally, the
Protected Tracks values have decreased and the Done % values
have increased showing that the copy session is closer to completion:
--------------------------- --------------------- ----- ---------- ----
Protected
----------------- --------- ------------------ -- ----- ---------- ----
Total ---------
Track(s) 112974
MB(s) 7060.9
. . .
c:\>
This glossary contains terms related to disk storage subsystems.
Many of these terms are used in this guide.
A
administrator A person responsible for administrative tasks such as access
authorization and content management. Administrators can also
grant levels of authority to users.
agent A software entity that runs on endpoints and provides management
capability for other hardware or software.
allocate To assign a resource for use in performing a specific task.
allocated storage The space that is allocated to volumes, but not assigned.
audit To review and examine the activities of a data processing system
mainly to test the adequacy and effectiveness of procedures for data
security and data accuracy.
authority The right to access objects, resources, or functions.
B
backup A copy of computer data that is used to recreate data that has been
lost, mislaid, corrupted, or erased. The act of creating a copy of
computer data that can be used to recreate data that has been lost,
mislaid, corrupted or erased.
Glossary
Glossary
bandwidth A measure of the data transfer rate of a transmission channel.
C
cache A random access electronic storage in selected storage controls used
to retain frequently used data for faster access by the channel.
CKD Count Key Data, a data recording format employing self-defining
record formats in which each record is represented by a count area
that identifies the record and specifies its format, an optional key area
that may be used to identify the data area contents, and a data area
that contains the user data for the record. CKD can also refer to a set
of channel commands that are accepted by a device that employs the
CKD recording format.
CLI See Command Line Interface (CLI).
client A function that requests services from a server, and makes them
available to the user. A term used in an environment to identify a
machine that uses the resources of the network. See also
client-server.
client-server In TCP/IP, the model of interaction in distributed data processing in
which a program at one site sends a request to a program at another
site and awaits a response. The requesting program is called a client;
the answering program is called a server.
client-server
relationship
Any process that provides resources to other processes on a network
is a server. Any process that employs these resources is a client. A
machine can run client and server processes at the same time.
COFA See copy on first access (COFA).
COFW See copy on first access (COFA).
cold operation Open Replicator mode where the Symmetrix DMX control device
must be offline to the host application. See also hot operation.
Command Line
Interface (CLI)
A mechanism for interacting with a computer operating system or
software by typing commands to perform a given task, referred to as
entering a command: the system waits for the user to conclude the
submitting of the text command by pressing the Enter key. A
Glossary
command line interpreter then receives, analyses, and launches the
requested command. Upon completion, the command usually returns
output to the user in the form of text lines on the CLI.
connection In TCP/IP, the path between two protocol applications that provides
reliable data stream delivery service. In Internet communications, a
connection extends from a TCP application on one system to a TCP
application on another system.
consistent copy A copy of data entity (for example, a logical volume) that contains the
contents of the entire data entity from a single instant in time.
console A user interface to a server. That part of a computer used for
communication between the operator or user and the computer.
control side The Symmetrix DMX, where Open Replicator runs, and its devices
are always referred to as the control side of the copy operation.
copy on first access
(COFA)
The Open Replicator copying of not-yet copied data from the remote
to the control when an application first attempts to read that data.
copy on first write
(COFW)
The Open Replicator copying of not-yet copied data from the control
to the remote when an application first attempts a write to the
location of that data.
D
data availability Access to any and all user data by the application.
data integrity The condition that exists as long as accidental or intentional
destruction, alteration, or loss of data does not occur.
data migration The one time movement of data from source to target, where the data
will subsequently only be accessed at the target.
default A value, attribute, or option that is assumed when no alternative is
specified by the user.
Glossary
dependent-write
consistency
A data state where data integrity is guaranteed by dependent-write
I/Os embedded in application logic. Database management systems
are good examples of applications that utilize the dependent-write
consistency strategy. Database management systems must devise
protection against abnormal termination in order to successfully
recover from one. The most common technique used is to guarantee
that a dependent write cannot be issued until a predecessor write has
completed. Typically the dependent write is a data or index write
while the predecessor write is a write to the log. Because the write to
the log must be completed prior to issuing the dependent write, the
application thread is synchronous to the log write (that is, it waits for
that write to complete prior to continuing). The result of this kind of
strategy is a dependent-write consistent database.
dependent-write I/O An I/O that cannot be issued until a related predecessor I/O has
completed. Most applications, and in particular database
management systems (DBMS), have embedded dependent-write
logic to ensure data integrity in the event of a failure in the host or
server processor, software, storage subsystem, or if an environmental
power failure occurs. See also dependent-write consistency.
device type The general name for a kind of device; for example, standard, BCV,
VDEV, or Clone.
director The component in the Symmetrix subsystem that allows the
Symmetrix to transfer data between the host channels and disk
devices.
directory (1) A type of file containing the names and controlling information
for other files or other directories. Directories can contain
subdirectories, which can contain subdirectories of their own. (2) A
file that contains directory entries. No two directory entries in the
same directory can have the same name. (POSIX.1). (3) A file that
points to files and to other directories.
disaster recovery The process of restoring a previous copy of the data and applying
logs or other necessary processes to that copy to bring it to a known
point of consistency.
disk director The component in the Symmetrix subsystem that interfaces between
cache and the disk devices.
Glossary
E
Enterprise Systems
Connection (ESCON)
A set of products and services that provides a dynamically connected
environment using optical cables as a transmission medium.
ESCON Enterprise Systems Connection architecture; a set of IBM and vendor
products that connect mainframe computers with each other and
with attached storage, locally attached workstations, and other
devices using optical fiber technology and dynamically modifiable
switches called ESCON directors.
F
fabric Fibre Channel employs a fabric to connect devices. A fabric can be as
simple as a single cable connecting two devices. The term is often
used to describe a more complex network utilizing hubs, switches,
and gateways.
FBA Fixed Block Architecture, disk device data storage format using
fixed-size data blocks.
FC See Fibre Channel.
FCP See Fibre Channel protocol.
FCS See Fibre Channel standard.
fiber optic The medium and the technology associated with the transmission of
information along a glass or plastic wire or fiber.
Fibre Channel A technology for transmitting data between computer devices at a
data rate of up to 4 Gbps. It is especially suited for connecting
computer servers to shared storage devices and for interconnecting
storage controllers and drives.
Fibre Channel
protocol
The serial SCSI command protocol used on Fibre Channel networks.
Fibre Channel
standard
An ANSI standard for a computer peripheral interface. The I/O
interface defines a protocol for communication over a serial interface
that configures attached units to a communication fabric. Refer to
ANSI X3.230-199x.
Glossary
FICON An I/O interface based on the Fibre Channel architecture. In this new
interface, the ESCON protocols have been mapped to the FC-4 layer,
that is, the Upper Level Protocol layer, of the Fibre Channel Protocol.
It is used in the S/390 and z/Series environments.
file system An individual file system on a host. This is the smallest unit that can
be monitored and extended. Policy values defined at this level
override those that might be defined at higher levels.
front-end director The component in the Symmetrix subsystem that interfaces with host
bus adapters (HBAs). It transfers data between the host and
Symmetrix cache.
G
gatekeeper A small logical volume on a Symmetrix storage subsystem used to
pass commands from a host to the Symmetrix storage subsystem.
Gatekeeper devices are configured on standard Symmetrix disks.
Gigabit Ethernet Technologies for transmitting Ethernet frames at a rate of a gigabit
per second, as defined by the IEEE 802.3-2005 standard.
gigabyte (GB) 10
9
bytes.
Graphical User
Interface (GUI)
A type of user interface which allows people to interact with a
computer and computer-controlled devices. It presents graphical
icons, used in conjunction with text, labels or text navigation to fully
represent the information and actions available to a user. But instead
of offering only text menus, or requiring typed commands, the
actions are usually performed through direct manipulation of the
graphical elements.
GUI See Graphical User Interface (GUI).
H
hardware Physical equipment, as opposed to the computer program or method
of use; for example, mechanical, magnetic, electrical, or electronic
devices. See also software.
hardware zoning The members of a hardware zone are based on the physical ports on
the fabric switch. Zoning can be implemented in the following
configurations: one to one, one to many, and many to many.
Glossary
HBA See host bus adapter.
highly parallel Refers to multiple systems operating in parallel, each of which can
have multiple processors.
host Any system that has at least one Internet address associated with it. A
host with multiple network interfaces can have multiple Internet
addresses associated with it. This is also referred to as a server.
host bus adapter A Fibre Channel HBA connection that allows a workstation to attach
to the SAN network.
host not ready In this state, the volume responds not ready to the host for all read
and write operations to that volume.
hot operation Open Replicator mode where the Symmetrix DMX control device can
remain online to the host application.See also Open Replicator mode
where the Symmetrix DMX control device can remain online to the
host application..
hypervolume A user-defined storage device allocated within a Symmetrix physical
disk.
hyper-volume
extension
The ability to define more than one logical volume on a single
physical disk device making use of its full formatted capacity. These
logical volumes are user-selectable in size. The minimum volume size
is one cylinder and the maximum size depends on the disk device
capacity and the emulation mode selected.
I
I/O device An addressable input/output unit, such as a disk device.
internet protocol
(IP)
A protocol used to route data from its source to its destination in an
Internet environment.
K
KB Kilobyte, 1024 bytes.
L
local volumes Volumes that reside on an Symmetrix system but do not participate in
SRDF activity.
Glossary
logical unit number
(LUN)
A volume identifier that is unique among all storage servers. The
LUN is synonymous with a physical disk drive or a SCSI device. For
disk subsystems such as the IBM Enterprise Stora?e Server, a LUN is
a logical disk drive (a unit of storage on the SAN which is available
for assignment or unassignment to a host server). The LUNs are
provided by the storage devices attached to the SAN.
logical volume A user-defined storage device.
Exclusive OR (XOR) of the accumulated bytes in the data record.
LUN masking Allows or blocks access to the storage devices on the SAN. Intelligent
disk subsystems provide this kind of masking.
LUN See logical unit number (LUN).
M
MB Megabyte, 10
6
bytes.
media The disk surface on which data is stored.
microprocessor A processor implemented on one or a small number of chips.
mirrored pair A logical volume with all data recorded twice, once on each of two
different physical devices.
mirroring The Symmetrix maintains two identical copies of a designated
volume on separate disks. Each volume automatically updates
during a write operation. If one disk device fails, Symmetrix
automatically uses the other disk device.
mirroring (RAID 1) The highest level of performance and availability for all
mission-critical and business-critical applications by maintaining a
duplicate copy of a volume on two disk drives.
multipath device A device made visible to a host on more than one I/O path in order to
improve both fault tolerance (failover) and performance (load
balancing).
multiprocessing The simultaneous execution of two or more computer programs or
sequences of instructions. See also parallel processing.
Glossary
multiprocessor (MP) A CPC that can be physically partitioned to form two operating
processor complexes.
N
native device name A path-specific device name provided by the host operating system
that represents a single path to a logical device. See also pseudo
device name.
network topology A physical arrangement of nodes and interconnecting
communication links in networks based on application requirements
and geographical distribution of users.
O
open system A system whose characteristics comply with standards made
available throughout the industry, and therefore can be connected to
other systems that comply with the same standards.
operating system (OS) Software that controls the execution of programs and that may
provide services such as resource allocation, scheduling,
input/output control, and data management. Although operating
systems are predominantly software, partial hardware
implementations are possible.
P
parallel processing The simultaneous processing of units of work by many servers. The
units of work can be either transactions or subdivisions of large units
of work (batch). See also highly parallel.
password A unique string of characters known to a computer system and to a
user, who must specify the character string to gain access to a system
and to the information stored within it.
point of consistency A point in time to which data can be restored and recovered or
restarted and maintain integrity for all data and applications.
port An endpoint for communication between applications, generally
referring to a logical connection. A port provides queues for sending
and receiving data. Each port has a port number for identification.
When the port number is combined with an Internet address, it is
called a socket address.
Glossary
port zoning In Fibre Channel environments, the grouping together of multiple
ports to form a virtual private storage network. Ports that are
members of a group or zone can communicate with each other but
are isolated from ports in other zones. See also LUN masking and
zoning.
protocol The set of rules governing the operation of functional units of a
communication system if communication is to take place. Protocols
can determine low-level details of machine-to-machine interfaces,
such as the order in which bits from a byte are sent. They can also
determine high-level exchanges between application programs, such
as file transfer.
pseudo device name A location-independent name that represents a single logical device
and the path set leading to it. See also native device name.
pull operation A Open Replicator pull operation copies data to the control device
from the remote device.
push operation A Open Replicator push operation copies data from the control
device to the remote device.
R
RAID Redundant array of inexpensive or independent disks. A method of
configuring multiple disk drives in a storage subsystem for high
availabi?ity and high performance.
RAID 0 A protection method where data is striped across several disks to
increase performance. Unless combined with RAID 1, does not
natively provide protection from data loss due to drive failure. See
also RAID 10.
RAID 1 A protection method that provides the highest level of performance
and availability for all mission-critical and business-critical
applications by maintaining a duplicate copy of a volume on two
disk drives. See also mirroring.
RAID 5 A protection method that provides high performance with automatic
striping across hypervolumes. Lost hypervolumes are regenerated
from remaining members. RAID 5 is configured in (3+1) and (7+1)
groups. RAID 5 technology stripes data and distributes parity blocks
across all the disk drives in the RAID group.
Glossary
RAID 6 A protection method that supports the ability to rebuild data in the
event that two drives within the RAID group fail.
RAID 10 A protection method that combines RAID 1 and RAID 0; used in
mainframe environments.
read access Permission to read information.
ready volume A state indicating the volume is available for read/write operations.
recovery The process of rebuilding data after it has been damaged or
destroyed, often by using a backup copy of the data or by reapplying
transactions recorded in a log.
remediation The process of upgrading elements of the host I/O stack to supported
levels. Often required as part of migration in order to meet required
levels for the newer target storage array.
remote operations Operation of remote sites from a host system.
remote side The array and devices at the other side of an Open Replicator control
side Symmetrix DMX is referred to as the remote side. See also
control side.
restore A process that reinstates a prior copy of the data.
resynchronization A track image copy from the primary volume to the secondary
volume of only the tracks which have changed since the volume was
last in duplex mode.
S
SAN See storage area network.
SCSI adapter Card in the Symmetrix subsystem that provides the physical interface
between the disk director and the disk devices.
SCSI reservation A method to claim or free ownership of a LUN using the standard
SCSI Reserve/Release protocol.
server A program running on a mainframe, workstation, or file server that
provides shared services. This is also referred to as a host.
Glossary
shared storage Storage within a storage facility that is configured such that multiple
homogeneous or divergent hosts can concurrently access the storage.
The storage has a uniform appearance to all hosts. The host programs
that access the storage must have a common model for the
information on a storage device. Programs must be designed to
handle the effects of concurrent access.
small computer
system interface
(SCSI)
An ANSI standard for a logical interface to computer peripherals and
for a computer peripheral interface. The interface utilizes a SCSI
logical protocol over an I/O interface that configures attached targets
and initiators in a multi-drop bus topology.
software zoning Is implemented within the Simple Name Server (SNS) running inside
the fabric switch. When using software zoning, the members of the
zone can be defined with a node WWN, port WWN, or physical port
number. Usually the zoning software also allows you to create
symbolic names for the zone members and for the zones themselves.
software (1) All or part of the programs, procedures, rules, and associated
documentation of a data processing system. (2) A set of programs,
procedures, and, possibly, associated documentation concerned with
the operation of a data processing system. For example, compilers,
library routines, manuals, circuit diagrams. See also hardware.
source device The device which is read from in a data migration. See also target
device.
stage The process of writing data from a disk device to cache.
storage administrator A person in the data processing center who is responsible for
defining, implementing, and maintaining storage management
policies.
storage area network A managed, high-speed network that enables any-to-any
interconnection of heterogeneous servers and storage systems.
switch A component with multiple entry and exit points or ports that
provide dynamic connection between any two of these points.
switch topology A switch allows multiple concurrent connections between nodes.
There can be two types of switches; circuit switches and frame
switches. Circuit switches establish a dedicated connection between
two nodes.
Glossary
Frame switches route frames between nodes and establish the
connection only when needed. A switch can handle all protocols.
T
target device The device which is written to in a data migration. See also source
device.
TCP See transmission control protocol.
TCP/IP Transmission Control Protocol/Internet Protocol.
topology An interconnection scheme that allows multiple Fibre Channel ports
to communicate. For example, point-to-point, arbitrated loop, and
switched fabric are all Fibre Channel topologies.
transaction A unit of work performed by one or more transaction programs,
involving a specific set of input data and initiating a specific process
or job.
transactional
consistency
Transactional consistency is a DBMS state where all in-flight
transactions are either completed or rolled back.
transmission control
protocol
A communications protocol used in the Internet and in any network
that follows the Internet Engineering Task Force (IETF) standards for
Internetwork protocol. TCP provides a reliable host-to-host protocol
between hosts in packet-switched communications networks and in
interconnected systems of such networks. It uses the Internet Protocol
(IP) as the underlying protocol.
V
virtual storage (1) The storage space that can be regarded as addressable main
storage by the user of a computer system in which virtual addresses
are mapped into real addresses. The size of virtual storage is limited
by the addressing scheme of the computer system and by the amount
of auxiliary storage available, not by the actual number of main
storage locations. (2) An addressing scheme that allows external disk
storage to appear as main storage.
virtualization A technique for hiding the physical characteristics of computing
resources from the way in which another function interacts with
those resources.
Glossary
volume A general term referring to a storage device. In the Symmetrix
subsystem, a volume corresponds to single disk device.
W
wait state Synonymous with waiting time.
waiting time (1) The condition of a task that depends on one or more events in
order to enter the ready condition. (2) The condition of a processing
unit when all operations are suspended.
WAN Wide area network.
web browser A software application which enables a user to display and interact
with text, images, videos, music and other information typically
located on a Web page at a website on the World Wide Web or a local
area network. Web browsers communicate with Web servers
primarily using HTTP (hypertext transfer protocol) to submit
information to Web servers as well as fetch Web pages from them.
world wide name A unique number assigned to Fibre Channel devices (including hosts
and adapter ports). It is analogous to a MAC address on a network
card.
WWN See world wide name.
Z
zoning In Fibre Channel environments, zoning allows for finer segmentation
of the switched fabric. Zoning can be used to instigate a barrier
between different environments. Ports that are members of a zone
can communicate with each other but are isolated from ports in other
zones. Zoning can be implemented in two ways: hardware zoning
and software zoning. See also hardware zoning and software
zoning.
A
Auto-provisioning Groups 161
C
CLARiiON
brief description 35
discover 71
display information about 71
remote for cold push example 70
remote for hot pull example 118
cleanup steps
cold push example 90
definition 64
flowchart 64
flowchart for PPME 211
for hot pull 119
for PPME 207
clustered hosts
special considerations 68
cold
definition 23
cold pull
definition 53
replace with hot pull 53
cold push
cleanup example 89
definition 50
migration and cleanup steps flowchart 91
migration example 89
setup example 69
versus hot push 51
Connectrix
Connectrix Manager
zoning verification screen 77, 133, 156, 249
control side
definition 23
ControlCenter
see EMC Ionix ControlCenter
create
and SCSI reservations 58
cutover
definition 22
D
data migration
definition 22
selection model 26
TechBook series 17
device masking
Symmetrix example 126
Symmetrix SMC example 158
diskpart
extend disk partition 142
rescan 260, 266
donor update
example 135
explanation 52
off (disable) 145, 193
E
EMC Ionix ControlCenter
Enginuity
definition 32
Index
Index
F
Federated Live Migration
benefits 230
description 230
Device external identity 233
introduction 24
nondisruptive migration 231
pair file example 252
FLM
see Federated Live Migration
front-end directors
defined 32
H
hot
definition 23
hot pull
definition 51
from CLARiiON example 117
from Symmetrix example 147
setup, migration, and cleanup flowchart 120
hot push
definition 48
differences from cold push 110
versus cold push 51
I
ICDA
see Integrated Cached Disk Array
Integrated Cached Disk Array
definition 32
Invista
L
LUN masking
for Symmetrix see device masking 158, 250
verify with Remote Report 181
verify with symsan -sanluns 82
M
migration
project steps 25
migration steps
flowchart 60
flowchart for FLM 240
for FLM 239
for PPME 205
hot pull example 118
MirrorView
mount 93, 114
multipathing 24
PowerPath 40
N
navicli
storagegroup operations 78, 113, 125, 135,
137
Navisphere
connectivity status example 76
invoke connectivity status 75
Storage Processor WWNs 76
O
offline
definition 23
online
definition 23
Open Replicator
control interface alternatives 67
data mobility 50
-force_copy 56
migration operation flow 55
pair file example 79, 130
Symmetrix VMAX and Symmetrix DMX
arrays 33
TimeFinder interaction 95, 106
tuning introduction 63
P
powerformat 114, 203
PowerPath
family 40
multipathing 40
PowerPath Migration Enabler
Index
benefits 196
description 196
introduction 24
migration example 214
migration states 199
nondisruptive migration 197
role in migration operations 68
when to use 26
PPME
see PowerPath Migration Enabler
precopy
definition 49
pull
definition 23
push
definition 23
R
remote device
read-only access 23
remote side
definition 23
Replication Manager
S
SAN Copy
incremental use case 36
SAN Manager
SCSI reservations
cluster control 58
setup steps
definition 55
FLM example 238
flowchart 56
flowchart for FLM 239
PPME example 204
verify completion example 80
verify failure example 131
SIU
see Symmetrix Integration Utilities
SLV
see Symmetrix logical volume
SMC
see Symmetrix Management Console
SnapView
Solutions Enabler
SRDF
see Symmetrix Remote Data Facility
Symmetrix
architecture 32
logical volumes 33
remote for hot pull example 147
Symmetrix Integration Utilities
definition 136
symntctl command 136
Symmetrix logical volume
definition 33
Symmetrix Management Console
Remote Report 86
Symmetrix Remote Data Facility 34
symntctl
log 288
mount 141, 187
umount 136, 137, 182
update 139, 187
T
TimeFinder
initial establish 95
migration role 34
Open Replicator interaction 95, 106
split 96
TimeFinder family
U
umount 108
Unisphere 37
Index
V
VxVM
vxdctl 114
vxdg 108, 114
vxdisk 108, 114, 115
vxprint 93, 115, 116
vxresize 116
vxvol 114
Z
zero space reclamation
definition 52
zoning
verify with Remote Report 181
verify with symmask list logins 83
verify with symsan -sanports 80

h5765 Data Migration Open Replicator Symm Ppme Techbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

h5765 Data Migration Open Replicator Symm Ppme Techbook

Uploaded by

Copyright:

Available Formats

Data Migration: EMC Open Replicator for

Symmetrix, PowerPath Migration Enabler,

Open Replicator for Symmetrix

enables the creation of

arrays, or third-party arrays on the SAN are referred to

. The combination of multipathed control devices

Symmetrix Manager are

is the next generation of mid-tier storage

and EMC RecoverPoint SE systems.

products are SAN switches and directors

are associated management software capable of

, the most mature,

provides synchronous and asynchronous remote

is used to create and manage local point-in-time

SnapSure, Celerra Replicator, and Invista Clones.

management tools can be launched from within the

You might also like