h5765 Data Migration Open Replicator Symm Ppme Techbook

SOLUTIONS GUIDE

Data Migration: EMC Open Replicator for Symmetrixand PowerPath Migration Enabler

Version 1.2

• EMC Open Replicator for Symmetrix Features

• Open Replicator Setup and Verification

• Open Replicator and PPME Migration Examples

Donald Fried-Tanzer

2 Data Migration: EMC Open Replicator and PowerPath Migration Enabler Version 1.2

Copyright © 2008, 2010 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information issubject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKESNO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATIONIN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicablesoftware license.

For the most up-to-date regulatory document for your product line, go to the Technical Documentation andAdvisories 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.

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

Version 1.2

P/N H5765.2

Contents

Preface

Chapter 1 Introduction1.1 Introduction ........................................................................... 221.2 Data Migration definition.................................................... 221.3 EMC Open Replicator for Symmetrix................................ 22

1.3.1 Terminology: control and remote............................. 221.3.2 Control FA "host" setup requirements .................... 231.3.3 Terminology: push and pull, cold and hot ............. 231.3.4 Multipathing with hot setup requirements ............ 23

1.4 EMC PowerPath Migration Enabler (PPME).................... 241.5 Migration project steps......................................................... 241.6 When to use Open Replicator with PPME ........................ 251.7 Operational interfaces .......................................................... 27

Chapter 2 Brief EMC Foundation and Migration ProductDescriptions2.1 Introduction ........................................................................... 302.2 EMC Symmetrix storage arrays and associated software 32

2.2.1 Basic architecture ........................................................ 322.2.2 EMC Enginuity Operating Environment ................ 322.2.3 Symmetrix Logical Volumes (SLVs) ........................ 332.2.4 Symmetrix V-Max and Symmetrix DMX arraysand Open Replicator ........................................................... 332.2.5 Pre-DMX Symmetrix arrays and Open Replicator 332.2.6 Other Symmetrix software ........................................ 34

2.3 EMC CLARiiON and associated software ........................ 352.3.1 EMC MirrorView........................................................ 35

3Data Migration: Open Replicator and PowerPath Migration Enabler Version 1.2

2.3.2 SnapView ..................................................................... 362.3.3 SAN Copy .................................................................... 362.3.4 Navisphere Management Suite ................................ 36

2.4 EMC SAN products .............................................................. 372.4.1 Connectrix.................................................................... 372.4.2 Connectrix Manager ................................................... 372.4.3 SAN Manager .............................................................. 372.4.4 Invista ........................................................................... 37

2.5 EMC Host products .............................................................. 392.5.1 PowerPath Family....................................................... 392.5.2 Replication Manager .................................................. 392.5.3 EMC Solutions Enabler .............................................. 402.5.4 Symmetrix Management Console (SMC)................ 402.5.5 EMC Ionix ControlCenter.......................................... 41

2.6 Consulting and IT Services.................................................. 412.6.1 Infrastructure Consulting .......................................... 422.6.2 Implementation........................................................... 43

Chapter 3 EMC Open Replicator for Symmetrix3.1 Introduction ........................................................................... 463.2 Definitions.............................................................................. 46

3.2.1 Hot push....................................................................... 463.2.2 Cold push..................................................................... 473.2.3 Hot pull ........................................................................ 493.2.4 Cold pull....................................................................... 503.2.5 Open Replicator interaction rules with SRDF ........ 51

3.3 Basic Open Replicator migration operation flow............. 523.3.1 Setup steps ................................................................... 523.3.2 Migration steps............................................................ 563.3.3 Cleanup steps .............................................................. 61

3.4 Monitoring, troubleshooting and recovery....................... 623.5 Control interface alternatives .............................................. 63

3.5.1 Solutions Enabler CLI ................................................ 633.5.2 Symmetrix Management Console GUI.................... 633.5.3 PowerPath Migration Enabler (PPME) CLI ............ 64

3.6 Reference information .......................................................... 64

Chapter 4 Cold Push to CLARiiON Setup Example4.1 Introduction ........................................................................... 664.2 Setup step 1, identify target devices................................... 664.3 Setup step 2, configure migration SAN zones .................. 68

Data Migration: Open Replicator and PowerPath Migration Enabler Version 1.24

4.3.1 Determining Control Director WWN ...................... 684.3.2 Determining Remote Storage Array WWN(s) ........ 694.3.3 Selective or all Symmetrix FA Zoning ..................... 724.3.4 Example configuration of migration SAN zones ... 72

4.4 Setup step 3, configure migration LUN masking............. 734.4.1 Create CLARiiON storage group ............................. 734.4.2 Register host and add devices to CLARiiONstorage group........................................................................ 73

4.5 Setup step 5, prepare Open Replicator session pairs ....... 744.6 Setup step 6, verify completion of setup steps.................. 75

4.6.1 Create action is a thorough verification step .......... 754.6.2 Verify zoning with symsan -sanports .................. 754.6.3 Verify LUN masking with symsan -sanluns ........ 774.6.4 Verify zoning with symmask list logins ............ 784.6.5 Verify all with symrcopy create............................. 794.6.6 SMC Remote Report ................................................... 80

Chapter 5 Cold Push to CLARiiON Migration Example5.1 Introduction ........................................................................... 845.2 Migration step 7, BCV split.................................................. 87

5.2.1 Device Group creation ............................................... 875.2.2 Initial TimeFinder/Mirror establish......................... 895.2.3 TimeFinder/Mirror split............................................ 90

5.3 Migration step 8, symrcopy create...................................... 925.3.1 Cold control devices must be Not Ready ................ 925.3.2 Create action options.................................................. 935.3.3 Open Replication query display ............................... 945.3.4 Query -detail option ................................................... 95

5.4 Migration step 10, symrcopy activate ................................ 965.5 Migration step 12, symrcopy set ceiling ............................ 975.6 Migration step 13, symrcopy query and verify ................ 995.7 Migration step 14, iterative symrcopy recreate .............. 100

5.7.1 Incrementally update control devices fromproduction devices............................................................. 1005.7.2 Incrementally update remote devices fromcontrol devices.................................................................... 1015.7.3 Stop applications and final incremental update... 102

5.8 Migration step 15, verify migration and symrcopyterminate..................................................................................... 104

5.8.1 Hot push differences from cold push .................... 1045.9 Cleanup step 16, make source devices host inaccessible 1065.10 Cleanup step 17, make target devices ready to host .... 107


5.11 Cleanup step 18, restart applications using targets ..... 1085.12 Cleanup step 19, redeploy the source devices’ storage 110

Chapter 6 Hot Pull from CLARiiON Migration Example6.1 Introduction ......................................................................... 112

6.1.1 Hot pull setup steps.................................................. 1126.1.2 Hot pull migration steps.......................................... 1126.1.3 Hot pull cleanup step ............................................... 113

6.2 Setup step 1, identify target devices................................. 1156.3 Setup step 2, configure migration SAN zone.................. 116

6.3.1 Determining control director WWNs .................... 1166.3.2 Determining remote storage array WWNs ........... 1176.3.3 Reuse existing migration SAN zones..................... 117

6.4 Setup step 3, configure migration LUN masking........... 1186.4.1 Create CLARiiON Storage Group.......................... 118

6.5 Setup step 4, configure target zoning and LUNmasking ...................................................................................... 1196.6 Setup step 5, Prepare Open Replicator session pairs file 1216.7 Setup step 6, verify completion of setup steps ............... 124

6.7.1 Discover missing zoning with symrcopy create .. 1246.7.2 Example configuration of additional migrationSAN zone ............................................................................ 1266.7.3 Discover missing LUN masking with symrcopycreate.................................................................................... 1266.7.4 Example LUN masking for all Symmetrix V-Max(or Symmetrix DMX) FA control directors .................... 1286.7.5 Successful create verifies hot pull setup................ 128

6.8 Migration step 9, Stop the applications ........................... 1296.9 Migration step 10, symrcopy activate .............................. 1316.10 Migration step 11, Restart applications using targets.. 1326.11 Migration step 13, symrcopy query and verify ............ 1376.12 Migration step 15, verify migration and terminate...... 1386.13 Cleanup step 19, redeploy the source devices .............. 138

Chapter 7 Hot Pull from Symmetrix Migration Example7.1 Introduction ......................................................................... 140

7.1.1 Hot pull setup steps.................................................. 1407.1.2 Hot pull migration steps.......................................... 1417.1.3 Hot pull cleanup step ............................................... 141

7.2 Setup step 1, identify target devices................................. 1437.3 Setup step 2, configure migration SAN zone.................. 144


7.3.1 Determining control director World Wide PortNames (WWPNs) ............................................................... 1447.3.2 Determining Remote Storage Array WWPN(s).... 1467.3.3 Configuration of migration SAN zones................. 148

7.4 Setup step 3, configure migration device masking ........ 1497.4.1 Application source device references..................... 1497.4.2 Add Symmetrix device masking ............................ 1507.4.3 Symmetrix V-Max device masking usingAuto-provisioning Groups ............................................... 152

7.5 Setup step 4, configure target zoning and LUNmasking....................................................................................... 1657.6 Setup step 5, prepare Open Replicator session pairs file 1667.7 Setup step 6, verify completion of setup steps................ 170

7.7.1 Confirm hot pull setup with successful create ..... 1707.7.2 SMC Remote Report ................................................. 172

7.8 Migration step 9, stop the applications............................ 1747.9 Migration step 10, Open Replicator activate ................... 1777.10 Migration step 11, restart applications using targets... 1797.11 Migration step 12, tune migration ................................. 1817.12 Migration step 13, check status, wait until copied ....... 1837.13 Migration step 15, verify migration and terminate...... 1847.14 Cleanup step 19, redeploy the source devices .............. 186

Chapter 8 PowerPath Migration Enabler (PPME) Overview8.1 Introduction ......................................................................... 1888.2 Benefits of using PPME ...................................................... 1888.3 Nondisruptive migration overview ................................. 1898.4 Definitions ............................................................................ 191

8.4.1 Pseudo or Native device name migrations ........... 1918.4.2 Source and target ...................................................... 1918.4.3 PPME Migration States ............................................ 1918.4.4 PPME Abort, Cleanup, and Recover...................... 194

8.5 PPME considerations and restrictions ............................. 1958.6 PPME with Open Replicator migration operation flow 196

8.6.1 Setup steps ................................................................. 1968.6.2 Migration steps.......................................................... 1978.6.3 Cleanup steps ............................................................ 199

8.7 Reference information ........................................................ 202

Chapter 9 PPME with Open Replicator Migration Example9.1 Introduction ......................................................................... 204


9.2 PPME Setup steps 1-4 ......................................................... 2059.3 PPME Setup steps 5-6, powermig setup......................... 205

9.3.1 Identify source and target pseudo device names. 2069.3.2 PPME license required ............................................. 2079.3.3 PPME powermig setup ............................................ 208

9.4 Migration step 10, powermig sync .................................. 2109.5 Migration step 12, tune migration ................................... 2119.6 Migration step 13, query status, until SourceSelected 2129.7 Migration step 18a, powermig selectTarget ............... 2149.8 Migration step 18b, powermig commit ............................ 2159.9 Migration step 16, powermig cleanup ............................. 2179.10 Migration step 19, redeploy source devices storage .... 217

Appendix A Open Replicator Performance TuningA.1 Two goals of Open Replicator tuning............................. 220A.2 Resource conflicts............................................................... 220

A.2.1 I/O resource paths .................................................. 220A.2.2 Array I/O conflicts .................................................. 220

A.3 Limiting Open Replicator resource usage...................... 221A.3.1 Using a separate management host ...................... 221A.3.2 Limiting Symmetrix FA director competition..... 221

A.4 Migration options can impose performance delays ..... 222A.5 Tuning Open Replicator.................................................... 223

A.5.1 Static configuration limits on Open Replicatorresource use ........................................................................ 223A.5.2 Dynamic limits on Open Replicator resourceuse ........................................................................................ 223

A.6 Monitoring Open Replicator performance..................... 225A.6.1 symrcopy query ....................................................... 225A.6.2 symrcopy list ceiling................................................ 226A.6.3 symstat with -RepType rcopy................................ 227

A.7 Tuning for applications sensitive to response time ...... 230

Appendix B TroubleshootingB.1 Solutions Enabler logs........................................................ 232

B.1.1 Cold push example log entries ............................... 232B.1.2 Hot pull example log entries .................................. 237

B.2 Audit Log............................................................................. 239B.3 PowerPath Migration Enabler (PPME) logs ................... 241B.4 Reactivate Failed Session................................................... 244


Glossary

Index



Figures

1 Migration project steps ............................................................................. 252 Open Replicator hot (or live) push ......................................................... 473 Open Replicator cold (or BCV) push...................................................... 494 Open Replicator hot (or live) pull ........................................................... 505 Open Replicator cold (or point-in-time) pull ........................................ 516 Setup steps flowchart................................................................................ 537 Migration steps flowchart ........................................................................ 578 Cleanup steps flowchart........................................................................... 619 Invoking Connectivity Status for Host in a Storage Group ................ 7010 Host connectivity status for a CLARiiON storage group. .................. 7111 CLARiiON CX3-40f Storage Processor World Wide Port Names...... 7112 Connectrix Manager activate zone verification screen........................ 7213 SMC Remote Report menu selection...................................................... 8014 SMC Remote Report Remote Ports......................................................... 8115 SMC Remote Report Remote LUNs display ......................................... 8116 Create Page 3 showing CLARiiON Available Remote Devices ......... 8217 Cold push migration and cleanup flowchart ........................................ 8619 Host connectivity status for licod194 in Storage Group D194.......... 11720 Windows drive L contents .................................................................... 12121 Windows Disk Management display of drives L, M, N and O........ 12222 Activate additional zones verification screen excerpt ....................... 12623 Disk Management display of target devices additional space ......... 13324 Disk Management updated display showing 4 GB partitions ......... 13625 Symmetrix hot pull setup, migration, and cleanup flowchart ......... 14226 SMC properties for Symmetrix 000190300359 devices 95-98............ 14327 SMC Front End Paths detail for control target device 95 .................. 14428 SMC director 2C port 0 properties showing the port WWN ............ 14529 SMC director 15C port 0 properties showing the port WWN .......... 14530 SMC Front End Paths detail for remote source device 141 ................ 14631 SMC director 8C port 0 properties showing the port WWN ............ 14732 SMC director 9C port 0 properties showing the port WWN ............ 14733 Connectrix Manager activate Symmetrix hot pull zones .................. 148


34 Disk Management display of remote source drives P, Q, R, and S.. 14935 SMC Device Masking menu .................................................................. 15036 SMC add device masking for remote devices 141-144 on FA-8C:0.. 15137 SMC device masking success confirmation dialog............................. 15138 SMC add device masking for remote devices 141-144 on FA-9C:0.. 15239 SMC Tasks Masking Wizard selection ................................................. 15440 Masking Wizard step 1 welcome screen.............................................. 15541 Masking Wizard step 2 create masking view...................................... 15642 Masking Wizard step 3 click to create Initiator Group...................... 15743 Masking Wizard step 3 Initiator Group creation................................ 15944 Masking Wizard step 4 select an existing Port Group....................... 16045 Masking Wizard step 5 click to create a Storage Group.................... 16146 Storage Group creation dialog............................................................... 16247 Masking Wizard step 7 summary ......................................................... 16348 Masking Wizard success dialog ............................................................ 16449 SMC properties device detail for control target device 95. ............... 16550 SMC Open Replicator Create Copy Session menu............................. 16651 SMC Create Copy Session page 1: Set session parameters ............... 16752 SMC Create Copy Session page 2: select control devices.................. 16753 SMC Open Replicator page 3: Select remote devices......................... 16854 SMC Create Copy Session page 4: Select device pairs....................... 16955 SMC Create Copy Session page 5: Set session options and execute 17056 SMC Confirm Open Replicator create execution................................ 17157 SMC Create Copy Session success dialog box .................................... 17158 SMC Remote Report menu selection .................................................... 17259 SMC Remote Report Remote Ports tab ................................................ 17360 SMC Remote Report Remote Luns display ......................................... 17361 SMC Removing device masking for devices 141-144 for FA-8C:0 ... 17562 SMC Removing device masking for devices 141-144 for FA-9C:0 ... 17663 SMC Open Replicator session properties and control menu............ 17764 SMC Open Replicator Activate ............................................................. 17865 Open Replicator session properties after activate .............................. 17866 Disk Management display of drives P-S on the target devices ........ 18067 SMC Select Open Replicator Set Ceiling Menu .................................. 18168 SMC Open Replicator Set Ceiling ......................................................... 18269 SMC Open Replicator session properties Refresh View update ...... 18370 SMC Open Replicator session properties showing Copied state ..... 18471 Donor Update Off SMC Session Control dialog box.......................... 18572 Terminate SMC Session Control dialog box........................................ 18673 PPME Operation with pseudo-named devices and Open

Replicator.................................................................................................. 19074 PPME Migration states and commands............................................... 19275 PPME with Open Replicator setup steps flowchart ........................... 197


76 PPME migration steps flowchart.......................................................... 19877 PPME cleanup steps flowchart ............................................................. 20278 PPME with Open Replicator setup, migration, and cleanup steps . 20479 Windows Event Viewer with PPME error message selected........... 24180 Event Properties detail for missing PPME license............................. 24281 Windows Event Viewer with PPME error message selected........... 24382 Event Properties detail for missing PPME license............................. 243



Preface

As part of an effort to improve and enhance the performance and capabilitiesof its product line, EMC routinely releases revisions to its hardware andsoftware. Therefore, some functions described in this guide may not besupported by all versions of the software or hardware currently in use. For themost up-to-date information on product features, refer to the product releasenotes.

Audience This TechBook describes best practices for using EMC Open Replicatorfor Symmetrix for data migration. Advantages and proper use of EMCPowerPath Migration Enabler (PPME) together with Open Replicatorare also explained. Open Replicator features used for data mobilityand remote vaulting, but not for data migration, are not covered in thisguide.

The intended audience for this TechBook is storage administrators,system administrators, and anyone interested in migratingapplications.

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 forheterogeneous migration

◆ SAN zoning

◆ EMC Solutions Enabler SYMCLI and Symmetrix ManagementConsole (SMC)

This TechBook is divided into nine chapters and two appendices:

Data Migration: Open Replicator and PowerPath Migration Enabler Version 1.2 15

Preface

◆ Chapter 1, “Introduction,” provides an introduction to theinterfaces and potential deployment of EMC Open Replicator forSymmetrix together with PowerPath Migration Enabler or alone.Background information including Open Replicator terminologyand required setup operations are introduced.

◆ Chapter 2, “Brief EMC Foundation and Migration ProductDescriptions,” provides an introduction to EMC Symmetrixhardware and software technologies that are used to implementmigration solutions.

◆ Chapter 3, “EMC Open Replicator for Symmetrix,”defines all OpenReplicator terminology, interfaces and operations. All of the stepsfor initiating and conducting Open Replicator operations aredescribed.

◆ Chapter 4, “Cold Push to CLARiiON Setup Example,” provides anexample of the steps needed to set up a cold push migration. Thischapter also describes additional setup requirements for hotoperations and multiple methods for verifying that OpenReplicator setup is complete. The examples shown in this chapteruse a Solaris host and SYMCLI.

◆ Chapter 5, “Cold Push to CLARiiON Migration Example,” providesan example of the steps needed to initiate, monitor and conclude acold push migration. The examples shown in this chapter use aSolaris host and SYMCLI.

◆ Chapter 6, “Hot Pull from CLARiiON Migration Example,”provides an example of the steps needed to initiate, monitor andconclude a hot pull migration. This chapter also provides anexample of incomplete zoning and masking, revealing some of theerrors that may be encountered while preparing for a hot pullmigration and presents information on how to resolve those errors.The examples shown in this chapter use a Windows host andSYMCLI.

◆ Chapter 7, “Hot Pull from Symmetrix Migration Example,”provides an example of the steps needed to initiate, monitor andconclude a hot pull migration. The examples shown in this chapteruse a Windows host and the Symmetrix Management Console(SMC).

◆ Chapter 8, “PowerPath Migration Enabler (PPME) Overview,”defines all PPME terminology, interfaces and operations. All of thesteps for installing, initiating and conducting PPME OpenReplicator operations are described.

16 Data Migration: Open Replicator and PowerPath Migration Enabler Version 1.2

Preface

◆ Chapter 9, “PPME with Open Replicator Migration Example,”provides an example of the steps needed to initiate, monitor andconclude a PPME with Open Replicator migration session. Theexamples shown in this chapter use a Windows host and thepowermig command.

◆ Appendix A, “Open Replicator Performance Tuning,” consolidates,expands and elaborates on the performance tuning informationincluded within the chapters of this TechBook.

◆ Appendix B, “Troubleshooting,” provides log examples thatcorrelate with the examples in chapters 4-9, and providestroubleshooting 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 MigrationSolution for EMC Symmetrix Arrays, that explores the complexity of datamigration and how to select a data migration solution for Symmetrix inan open systems environment.

For readers who have access to EMC Powerlink®, check EMCPowerlink for new TechBooks in this Data Migration series or visit theVervante On Demand Publishing website:

http://Powerlink.EMC.com

and then Home > Support > Technical Documentation and Advisories> TechBooks

http://www.vervante.com/


http://powerlink.emc.com

http://powerlink.emc.com:80/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=homePgSecureContentBk

http://powerlink.emc.com:80/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=--NULL--&internalId=0b01406680024e1b

http://powerlink.emc.com:80/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=--NULL--&internalId=0b01406680024e23

http://powerlink.emc.com:80/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=--NULL--&internalId=0b01406680024e23

http://www.vervante.com/


http://powerlink.emc.com/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=image3&internalId=0b0140668014ac61&_irrt=true

Preface

Where to get help EMC support, product, and licensing information can be obtained asfollows:

Productinformation

For documentation, release notes, software updates, or for informationabout EMC products, licensing, and service, go to the EMC Powerlinkwebsite (registration required) at:


Technical support For technical support, go to EMC Customer Service on Powerlink. Toopen a service request through Powerlink, you must have a validsupport agreement. Please contact your EMC sales representative fordetails about obtaining a valid support agreement or to answer anyquestions about your account.

Relateddocumentation

Related documents, available on EMC Powerlink, include:

• EMC Solutions Enabler Symmetrix Open Replicator CLI ProductGuide

• EMC Solutions Enabler Installation Guide

• EMC Solutions Enabler Symmetrix Array Management CLI ProductGuide

• EMC Solutions Enabler Symmetrix Array Controls CLI ProductGuide

• EMC Solutions Enabler Symmetrix SRM CLI Product Guide

• EMC Solutions Enabler Symmetrix TimeFinder Family CLI ProductGuide

• EMC Solutions Enabler Symmetrix SRDF Family CLI Product Guide

• EMC PowerPath Migration Enabler User Guide

• Implementing PowerPath Migration Enabler in Open Replicator andInvista Environments

• Migrating Microsoft Cluster Server using EMC Open Replicator forSymmetrix Technical Note

• EMC Symmetrix LUN Expansion and UNIX Logical VolumeManagers Technical Note

• EMC Enginuity 5773 Flexible Device Geometry in a Sun SolarisEnvironment Technical Note

• Choosing a Data Migration Solution for EMC Symmetrix ArraysTechBook




Preface

• White paper: New Features in EMC Enginuity 5874 for SymmetrixOpen Systems Environments

• EMC Symmetrix Enginuity Release Notes (multiple release levelsavailable)

• EMC Solutions Enabler Version 7.0 Release Notes

• EMC Symmetrix Management Console Version 7.0 Release Notes

• Storage Provisioning With EMC Symmetrix Auto-provisioningGroups Technical Note

Typographicalconventions

EMC uses the following type style conventions in this document:

Bold • User actions (what the user, clicks, presses, or selects• Interface elements (button names, dialog box names• Names of keys, commands, programs, scripts, applications, system calls,

processes, utilities, notifications, services, applications, and utilities in text

Italic • Book titles• New terms in text• Emphasis in text

Courier • Prompts• System output• Filenames• URLs• Syntax when shown in command line or other examples

Courierbold

• User entry• Options in command-line syntax

Courieritalic

• Arguments in examples of command-line syntax• Variables in examples of screen or file output• Variables in pathnames

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


Preface

The author of this TechBook

This TechBook was written by Donald Fried-Tanzer, an employee ofEMC based at headquarters in Hopkinton, Massachusetts. Donald hasover 25 years of experience in client-server applications, fault-tolerantservers, and storage management software including: provisioning,remote replication, local replication, migration, configuration andmonitoring.

We'd like to hear from you!

Your feedback on our TechBooks is important to us! We want our booksto be as helpful and relevant as possible, so please feel free to send usyour comments, opinions and thoughts on this or any other TechBook:

[email protected]


[email protected]

Introduction

1

This chapter provides a brief executive summary of the two migrationproducts covered in this guide: EMC® Open Replicator for Symmetrix®

and EMC PowerPath® Migration Enabler (PPME). Key terminologyand setup requirements for Open Replicator are introduced. The full setof migration project steps is depicted identifying the project stepscovered in this book and where to find more information on otherproject steps. An abbreviated approach to choosing whether to useOpen Replicator with PPME concludes the chapter. The topics coveredinclude:

◆ 1.1 Introduction .................................................................................. 22◆ 1.2 Data Migration definition ........................................................... 22◆ 1.3 EMC Open Replicator for Symmetrix ....................................... 22◆ 1.4 EMC PowerPath Migration Enabler (PPME)........................... 24◆ 1.5 Migration project steps................................................................ 24◆ 1.6 When to use Open Replicator with PPME ............................... 25◆ 1.7 Operational interfaces ................................................................. 27

Introduction 21

Introduction

1.1 IntroductionEMC Open Replicator for Symmetrix enables the creation of remotepoint-in-time copies that can be used for data mobility, remote vaulting,and migration between EMC Symmetrix V-Max™ (orSymmetrix DMX™) and qualified storage arrays with full, incremental,offline (cold), and online (hot) copy capabilities. This TechBook willfocus on the use of Open Replicator for data migration only.

1.2 Data Migration definitionData Migration can be defined as the one-time movement of data froma source to a target, where the data will subsequently only be accessedat the target. The key to this definition is that for any particular piece ofdata, this is a one-time movement. This one-time movementdifferentiates Data Migration from Replication where applicationscontinue to access the source data after the target copy is created. Also,the one-time movement differentiates Data Migration from DataMobility where incremental updates to the data would continue to beapplied.

By definition data migration refers to the relocation of data. After amigration operation, applications that access the data must referencethe data in its new location. Therefore, part of the migration solution isthe methodology used to point applications to the new data location(also known as application cutover). Few if any applications have beendesigned with the ability to continue processing during the applicationcutover process. Therefore either an application outage will berequired, or the migration must be transparent to the application.

1.3 EMC Open Replicator for Symmetrix

1.3.1 Terminology: control and remoteOpen Replicator can transfer data between Symmetrix arrays(homogeneous,) or between a Symmetrix V-Max (or Symmetrix DMX)and another qualified Fibre Channel array (heterogeneous). TheSymmetrix V-Max (or Symmetrix DMX) where Open Replicator runs,and its devices, are always referred to as the control side of the copyoperation. Other Symmetrix arrays, CLARiiON® arrays, or third-partyarrays on the SAN are referred to as the remote array/devices.


Introduction

1.3.2 Control FA "host" setup requirementsOpen Replicator runs as an application in the Fibre Director (FA) of theSymmetrix V-Max (or Symmetrix DMX). The Open Replicator softwarecauses the FA to appear as an open systems host to the remote storagearray. Therefore, no special software is needed in the remote storagearray. However, zoning and LUN masking is needed to access theremote devices and must be defined (as is the case anytime a host needsto access devices on a remote storage array). Configuring the requiredzoning and LUN masking is the most common area where problemsoccur when setting up Open Replicator and will be covered thoroughlyin multiple examples. Additionally, multiple methods for verifying thatthe setup is correct will be covered in the examples.

1.3.3 Terminology: push and pull, cold and hotOpen Replicator supports two types of copy operations: push and pull.A push operation copies data from the control device to the remotedevice. A pull operation copies data to the control device from theremote device. Open Replicator has two modes of operation: cold(offline) and hot (online). These two modes refer to the state of theSymmetrix V-Max (or Symmetrix DMX) resident devices (controldevices). The terms online or offline are used to indicate the potentialstate of a host application that uses these devices. Only with a hotoperation can an application using Symmetrix V-Max (or SymmetrixDMX) based storage remain online. For data consistency reasons, theremote devices must never be written to by any host connected to theremote array. In cases where the remote device is the source of the OpenReplicator copy operation (a pull operation), it may be permissible for aremote host to have read-only access to the remote device.

1.3.4 Multipathing with hot setup requirementsTypically a Symmetrix device is visible to a host on more than one I/Opath. This is done to improve both fault tolerance (failover) andperformance (load balancing). Multipathing is accomplished byconfiguring 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 solutionin order to correctly handle the same device being presented on morethan one I/O path. A common multipathing host solution is EMCPowerPath. The combination of multipathed control devices and hot

Introduction 23

Introduction

Open Replicator operations result in the greater requirement that all FAdirectors that present the control devices, must be zoned and LUNmasked as hosts able to access the remote array devices.

1.4 EMC PowerPath Migration Enabler (PPME)PowerPath Migration Enabler (PPME) is a hybrid migration solutionthat provides the ability to perform nondisruptive migrations orencapsulations while leveraging another underlying technology, suchas Open Replicator, TimeFinder®/Clone, Invista® or Host Copy. PPMEprovides a solution with virtually no impact to host resources byutilizing array-based or SAN-based replication (except for Host Copy).PPME benefits data migrations by greatly reducing or eliminatingapplication disruption caused by the migration, reducing migrationrisk, and simplifying migration operations. PowerPath MigrationEnabler can be installed without PowerPath multipathing technology,but PowerPath multipathing is required for completely nondisruptivemigrations. This TechBook only covers PPME operation with OpenReplicator.

1.5 Migration project stepsFigure 1 summarizes the basic migration flow.


Introduction

Figure 1 Migration project steps

This TechBook is focused on operational migration examples, similar toa Migration Pilot. There is also some inclusion of the Migration andCutover step particularly in describing how PowerPath MigrationEnabler (PPME) simplifies this step. The Migration Strategy and ToolSelection step is where the decision would be made whether to useOpen Replicator alone or together with PPME. The Selection steprequires both the Business Impact Analysis and Source ConfigurationDiscovery steps to provide necessary input. These first three steps arecovered in the first volume in the Data Migration series of TechBooks,Choosing a Data Migration Solution for EMC Symmetrix Arrays. Theselection model defined for migration tool selection is conducted herein an abbreviated manner.

1.6 When to use Open Replicator with PPMEIn this case, the starting assumption is that EMC Open Replicator forSymmetrix has been selected as the main migration tool and thedecision is whether to use it alone or in conjunction with PPME. To

ICO-IMG-000440

Business Impact Analysis

Source ConfigurationDiscovery

Migration Strategy and Tool Selection

Detailed Mapping and Design

Provisioning

Skill Refreshing Migration Pilot

Migration and Cutover

Sign-off

Introduction 25

Introduction

make this determination, follow the iterative six step model shownbelow, and provide answers to the highlighted applicable key questions.How these questions are answered will determine whether OpenReplicator should be used alone, or in conjunction with PPME.

1. Define the reasons for the data migration, clearly noting mandatoryand optional objectives.Applicable key question: Is this a transformational migration in thesense of including the permanent addition of migration enablers forfuture migrations?

2. Inventory the existing environment and identify storage elementsthat must participate with the chosen data migration solution, alongwith resources that are available to support the migration itself.

3. Inventory the target environment identifying storage elements thatmust participate with the chosen data migration solution, andresources available to support the migration itself.

4. Identify potential data migration solutions that can successfullymove the data from the existing environment to the targetenvironment.Applicable key question: Is PPME and transparent migrationsupported in the existing and target environments?


Introduction

5. Identify business factors that limit potential data migrationsolutions such as budget, human resources, and application outageand verification requirements.Applicable key question: How important is avoiding applicationinterruptions now or in the future, reducing migration risk, andsimplifying migration operations?

6. Compare and evaluate the potential data migration solutionsincluding the criteria identified in steps 1-5.

The answers provided to the applicable key questions defined in steps 1, 4and 5 can identify opportunities to realize the advantages of usingPPME together with Open Replicator. PPME can greatly reduce oreliminate application disruption due to the migration. If this is a keyfactor for the current or future migrations, then it is likely that the use ofPPME will be beneficial. However, the ability of PPME to completelyeliminate any migration related interruptions is limited by the presenceof PowerPath 5.x on the migration host, the type of host, and the host'ssupport for PPME and PowerPath pseudo devices. Lastly, in step 6, therelative importance of the answer to the applicable key question in step 5must be evaluated against any offsetting factors such as cost or otherrestrictions.

1.7 Operational interfacesThere are three different interfaces available to control EMC OpenReplicator for Symmetrix: the Solutions Enabler Command LineInterface (CLI), the Symmetrix Management Console (SMC) GraphicalUser Interface (GUI), and the PowerPath Migration Enabler (PPME)CLI. Examples of using all three interfaces are included in thisTechBook. Note that the PPME CLI interface has fewer operationalsteps and provides a greater breadth with the inclusion of migrationcutover operations than is available with the Solutions Enabler CLI orSMC alone.

Introduction 27

Introduction


Brief EMC Foundationand Migration Product

Descriptions

2

This chapter provides brief descriptions of EMC Symmetrix hardwareand software technologies that may play a role in a data migrationusing Open Replicator and PPME. The topics covered include:

◆ 2.1 Introduction ..................................................................................... 30◆ 2.2 EMC Symmetrix storage arrays and associated software......... 32◆ 2.3 EMC CLARiiON and associated software .................................. 35◆ 2.4 EMC SAN products ........................................................................ 37◆ 2.5 EMC Host products ........................................................................ 39◆ 2.6 Consulting and IT Services............................................................ 41

Brief EMC Foundation and Migration Product Descriptions 29

Brief EMC Foundation and Migration Product Descriptions

2.1 IntroductionThis chapter contributes to the selection model introduced in Chapter 1,by providing brief introductions of EMC products that will be usedprimarily in selection model steps 2-4. Chapter 2 of the Choosing a DataMigration Solution for EMC Symmetrix Arrays TechBook has a morecomplete listing of EMC migration-related products. The subset ofproducts included in this chapter were chosen because they can beoperationally relevant to using Open Replicator and PPME.

Products are presented in the following groupings: Symmetrix,CLARiiON, SAN, Host and Services:

◆ Symmetrix storage arrays are present in all Open Replicatormigration configurations, because at least one Symmetrix V-Max (orSymmetrix DMX) storage array must be present as the control array.Other Symmetrix storage arrays may act as the remote array in OpenReplicator operations. The TimeFinder family of local replicationproducts may be used to create point-in-time copies for coldoperations. The SRDF® family of remote replication products mayprovide information about remote Symmetrix arrays and can beused to perform remote operations. Solutions Enabler, theSymmetrix Management Console (SMC) and EMC Ionix™

ControlCenter® Symmetrix Manager are associated managementsoftware for managing the Symmetrix.

◆ CLARiiON storage arrays may act as the remote array in OpenReplicator operations. The SAN Copy™ product is a CLARiiONbased product with functionality similar to Open Replicator. It isincluded with a short discussion of a use case where SAN Copymight be used instead of Open Replicator. Navisphere®

Management Suite is associated management software that can beused to set-up the CLARiiON to work as a remote array in OpenReplicator operations.

◆ EMC Connectrix® products are SAN switches and directors which,as part of the SAN, contain the zoning that must be properlydefined in order for Open Replicator to work. EMC ConnectrixManager and EMC Ionix ControlCenter SAN Manager™ areassociated management software capable of managing andmonitoring zoning. Invista Storage Virtualization runs in the SANand is mentioned briefly because PPME can work with Invista asthe underlying replication technology.



◆ The host grouping includes migration-related products that executesolely on a customer host system, as well as products that provide ahost-executable control interface for array or SAN-based migrationsoftware. PowerPath multipathing can effect the setuprequirements for Open Replicator. PowerPath Migration Enabler(PPME) also executes on the host. Control interfaces includeSolutions Enabler, Symmetrix Management Console (SMC) andEMC 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 andqualification. EMC Services are a key method to reduce risk andensure the success of data migrations.



2.2 EMC Symmetrix storage arrays and associated softwareThe following sections describe the Symmetrix array: basic architecture,operating environment, logical volumes, array types used with OpenReplicator, replication and management software.

2.2.1 Basic architectureSymmetrix is a high-end enterprise storage system with maximumcapacity and the highest performance, consolidating massive amountsof data and host applications and storage tiers on reliable, cost-effectivenetworked storage. Symmetrix provides broad connectivity with 4Gb/s performance, advanced security, high availability, and energyefficiency in an easy-to-operate storage system.

Symmetrix is an Integrated Cached Disk Array (ICDA). All I/Os arecached. There are three functional areas:

◆ Shared Global Memory provides cache memory

◆ Front-end directors connect to hosts and service all host I/Orequests to/from cache

◆ Back-end directors stage and destage data between cache andphysical disk drives

The Symmetrix architecture can be compared to a MPP (MassivelyParallel Processing) server with directors working simultaneouslyperforming all the tasks of the array.

2.2.2 EMC Enginuity Operating EnvironmentSymmetrix storage arrays run EMC Enginuity™, the most mature,comprehensive, stable, highly available and proven storage operatingenvironment in the industry. Enginuity is the emulation code, serviceprocessor code and other software used by a Symmetrix to implementcore functionality. Each processor in every director is loaded withspecific emulation code. Enginuity coordinates the independentdirector processors to act as one Integrated Cached Disk Array.Enginuity provides base system functionality and advanced featureslike local (TimeFinder) and remote (SRDF) replication, Open Replicatorand other optional software products.



2.2.3 Symmetrix Logical Volumes (SLVs)Symmetrix Logical Volumes (SLVs) are logical abstractions of physicaldisk drives that are presented to open system hosts as FBA (Fixed BlockArchitecture) devices. EMC and customers configure these devicesusing Symmetrix management software. More information about thissoftware is available in Section 2.2.6.3, “Symmetrix managementsoftware,” on page 35. Enginuity also provides the capability to mapSLV visibility on specific FA adapters and to limit visibility to specificHost Bus Adapters (HBAs) on a switched Fibre Channel connectionusing device masking (LUN masking). Symmetrix Access Controls canbe used as a further security feature to specifically limit the types ofactions possible on devices from specific hosts.

2.2.4 Symmetrix V-Max and Symmetrix DMX arrays and Open ReplicatorThe current Symmetrix models are the Symmetrix V-Max SE andSymmetrix V-Max Series that run Enginuity level 5874. The previousSymmetrix model family DMX-4 950/1500-4500 can run Enginuitylevels 5772 or 5773. The preceding set of Symmetrix DMX models werethe DMX-3 950/1500-4500 that can run Enginuity levels 5771, 5772 or5773. The first DMX models were the DMX-1/DMX-2800/1000/2000/3000 that can run Enginuity levels 5670 or 5671.Enginuity levels 5671 and 5771 were the first levels to include the EMCOpen Replicator for Symmetrix software. Open Replicator runs as anapplication in the Fibre Director (FA) of the Symmetrix V-Max orSymmetrix DMX. The Open Replicator software causes the FA toappear as an open systems host to the remote storage array, while itcontinues to simultaneously function as the host front-end to theSymmetrix.

2.2.5 Pre-DMX Symmetrix arrays and Open ReplicatorEarlier Symmetrix arrays cannot run Enginuity 5x71 code and thereforecannot act as the control array for Open Replicator. However, sinceprevious arrays have front-end Fibre Channel support, they can act asthe remote array for Open Replicator.



2.2.6 Other Symmetrix software

2.2.6.1 SymmetrixRemote Data

Facility (SRDF)Family

The EMC Symmetrix Remote Data Facility (SRDF) family of replicationsoftware offers various levels of Symmetrix based businesscontinuance, disaster recovery and data mobility solutions. SRDFproducts offer the capability to maintain multiple, host-independent,mirrored copies of data. The Symmetrix systems can be in the sameroom, in different buildings within the same campus, or hundreds tothousands of kilometers apart. By maintaining copies of data indifferent physical locations, SRDF is an effective mechanism for datacenter migration. SRDF is designed for Symmetrix to Symmetrixconnections through Fibre Channel, Gigabit Ethernet (GigE), andESCON. SRDF has been a part of Enginuity since 1994.

2.2.6.2 TimeFinderFamily

The EMC TimeFinder family of software is the most powerful suite oflocal storage replication solutions available. Fully leveraging theindustry-leading high-end Symmetrix hardware architecture, it offersunmatched deployment flexibility and massive scalability to deliver awide range of in-the-system data copying capabilities to meet mixedservice level requirements without operational impact. Thefield-proven TimeFinder family is the most widely deployed set ofhigh-end replication solutions in the industry, with tens of thousands ofinstallations in the most demanding environments. And, only theTimeFinder family can provide cross-volume and cross-storage systemconsistency, tight integration with industry leading applications, andsimplified usage through automated management. The EMCTimeFinder family of local replication allows users to nondisruptivelycreate and manage point-in-time copies of data to allow operationalprocesses, such as backup, reporting, and application testing to beperformed independent of the source application to maximize servicelevels without impacting performance or availability.

TimeFinder/Clone, TimeFinder/Mirror or TimeFinder/Snap can play arole in Open Replicator data migration in two ways. First, TimeFindercan be used to create a local point-in-time copy for an Open Replicatorcold push migration to a remote array. Both TimeFinder and OpenReplicator include incremental support, so this point-in-time copy canbe incrementally updated, followed by an incremental Open Replicatorupdate to quickly reach the new point-in-time. At the end of themigration, the final TimeFinder and Open Replicator incrementalupdates would be conducted after production I/O was stopped to theproduction device. Second, if the remote array is a Symmetrix,TimeFinder can be used to ensure a backup copy of the production datais available at the remote location in case there is a disruption during an



Open Replicator incremental push. This is necessary, because whenOpen Replicator performs an incremental update from the productionvolumes, the data on the remote devices is not in a consistent state untilthe update completes.

Note: Enginuity 5874 no longer supports native TimeFinder/Mirror operations.However, TimeFinder/Mirror commands are still supported using theTimeFinder/Clone emulation feature. Therefore, usually there are no changesin the operational details provided for integrating TimeFinder/Mirror withOpen Replicator. The emulation feature is not supported for virtuallyprovisioned (thin) devices; in this case new scripts using nativeTimeFinderClone commands (symclone) must be used in place of emulatedTimeFinder/Mirror commands (symmir).

2.2.6.3 Symmetrixmanagement

software

Enginuity and array-based applications like SRDF and TimeFinderreside in the Symmetrix array and can be managed by hostapplications. EMC Solutions Enabler includes a CLI interface for OpenReplicator, SRDF, TimeFinder, device configuration, device mapping,and device masking. Symmetrix Management Console (SMC) providesa browser-based GUI interface on top of Solutions Enabler. EMC IonixControlCenter Symmetrix Manager is a central feature of the EMC IonixControlCenter family of products, which provides a unified view formultiple arrays via a single-pane-of-glass interface. SymmetrixManager is used to discover, monitor, and configure Symmetrix storagefrom a single console including the ability to automate key systemmanagement, and replication tasks.

2.3 EMC CLARiiON and associated softwareCLARiiON arrays combine advanced, easy-to-use midrange networkedstorage with robust software capabilities. CLARiiON also provides thehigh availability and scalability needed to manage and consolidatemore data. CLARiiON arrays have front-end Fibre Channel supportand can act as the remote array for Open Replicator.

2.3.1 EMC MirrorViewEMC MirrorView™ provides synchronous and asynchronous remotereplication options across IP and Fibre Channel networks. MirrorViewis used for remote replication between CLARiiON arrays across IP andFibre Channel networks and can also be used for data migration.



2.3.2 SnapViewSnapView™ is used to create and manage local point-in-time snapshotsand complete data clones for testing, backup, recovery and migrationoperations. When the Open Replicator remote array is a CLARiiON,SnapView can be used to ensure a backup copy of the production datais available at the remote location in case there is a disruption during anOpen Replicator incremental push. This is necessary, because whenOpen Replicator performs an incremental update from the productionvolumes, the data on the remote devices is not in a consistent state untilthe update completes.

2.3.3 SAN CopySAN Copy copies data between multi-vendor storage systems over thehigh-speed SAN infrastructure or WAN in a manner very similar toEMC Open Replicator for Symmetrix. When using SAN Copy, theCLARiiON Storage Processor acts as a host to the remote storage array.Again, no special software is needed in the remote array. Like OpenReplicator, SAN Copy supports incremental copy capabilities for localarray-based sources. SAN Copy would likely be used instead of OpenReplicator when there is a need for incremental support while copyingdata from a CLARiiON source to a Symmetrix target.

2.3.4 Navisphere Management SuiteNavisphere provides browser-based discovery, monitoring,configuration, and reporting on multiple EMC CLARiiON storagearrays. Navisphere provides management for CLARiiON's advancedsoftware functionality including: EMC Navisphere Quality of ServiceManager, Navisphere Analyzer, SnapView, SAN Copy, and MirrorView.Navisphere also provides the mechanism to set the LUN maskingrequired to make CLARiiON LUNs accessible to the Symmetrix V-Max(or Symmetrix DMX) FA Open Replicator "host."



2.4 EMC SAN products

2.4.1 ConnectrixEMC Connectrix products are advanced directors and switches forcreating an efficient, scalable, high-availability SAN infrastructure.EMC offers a comprehensive line of Connectrix switches that scale from8 to 70 ports. Some models provide support for SAN Extension, SANRouting, and network-hosted applications such as EMC RecoverPointand EMC Invista.

2.4.2 Connectrix ManagerEMC Connectrix Manager provides an interface to the Connectrixserver, centralized management of multiple enterprise directors andswitches, and a high-level view of the enterprise storage networkwithin the local data centers or at geographically dispersed locations.Connectrix Manager can be used to configure the required zoning forthe Symmetrix V-Max (or Symmetrix DMX) FA Open Replicator "host"and the remote storage array.

2.4.3 SAN ManagerEMC Ionix ControlCenter SAN Manager streamlines and centralizesmanagement of multivendor SANs from one easy-to-use interface. SANManager can be used to configure the required zoning for theSymmetrix V-Max (or Symmetrix DMX) FA Open Replicator "host" andthe remote storage array.

2.4.4 InvistaInvista Storage Virtualization introduces a hardware abstraction layerto 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 beinterchanged as business needs dictate, resulting in the ability to move,expand, or change the storage infrastructure while the applicationremains online. Applications can be migrated between storage tiers oronto refreshed storage systems while reducing or eliminating planneddowntime. Storage Virtualization is a technology enabler forInformation Lifecycle Management (ILM). Storage Virtualization alsoprovides a common means for storage management acrossheterogeneous storage platforms, which simplifies management and



reduces operating cost for ongoing data migration needs. PowerPathMigration Enabler can use Invista as the underlying SAN-based datamigration technology.



2.5 EMC Host products

2.5.1 PowerPath FamilyThe PowerPath family enables EMC host-based solutions includingmultipathing, data migration, and host-based encryption.

◆ PowerPath Multipathing automatically tunes the storage areanetwork (SAN) and selects alternate paths for data if necessary.Residing on the server, PowerPath Multipathing enhances SANperformance and application availability. It also integrates multiplepath I/O capabilities, automatic load balancing, and path failoverfunctions for complete path management.

◆ PowerPath Migration Enabler (PPME) enables other technologies,like array-based replication, virtualization and Host Copy, toeliminate application downtime during data migrations orvirtualization implementations. PPME keeps arrays in sync duringOpen Replicator data migrations (with minimal impact to hostresources). PPME also provides ease of use for data migrations thatreduce risk and lower costs. In addition, PPME enables seamlessdeployment of Invista virtualized environments by encapsulating(or bringing under the control of) the volumes that will bevirtualized.

2.5.2 Replication ManagerReplication Manager is used to administer multiple EMC replicationtechnologies and coordinate the entire replication process -- fromdiscovery and configuration to the operation of multiple disk-basedreplicas. Replication Manager can be used to automate the discovery ofstorage arrays, applications, replication technologies, and hosts. WithReplication Manager, all information and activities for replicas can berecorded and catalogued. Replication Manager provides awizard-driven interface to create copies of information and includessupport for TimeFinder alone or integrated with SRDF, SnapView aloneor integrated with MirrorView, SAN Copy, RecoverPoint, Celerra®

SnapSure™, Celerra Replicator™, and Invista Clones.



2.5.3 EMC Solutions EnablerAn EMC Solutions Enabler installation provides the host with SYMAPI,CLARAPI, and STORAPI shared libraries for use by Solutions Enablerapplications, and the Symmetrix Command Line Interface (SYMCLI)for use by Storage Administrators and Systems Engineers. SYMCLI is aspecialized library of UNIX-formatted commands that can be invokedone at a time. It supports single command line entries and scripts tomap and perform control operations on devices and data objects. It alsocan be used to monitor device configuration and status of devices thatmake up the storage environment. The target storage environments aretypically Symmetrix, but can be CLARiiON when you have a licenseand work with the mapping SRM component.

2.5.4 Symmetrix Management Console (SMC)As a small and easy-to-implement, browser-based graphical interface,SMC can be hosted on a small Windows, Linux or Solaris server and isaccessible via a client web browser from nearly anywhere in the world.Because of this minimal infrastructure, SMC is an ideal graphicalcomplement to SYMCLI and even to full EMC Ionix ControlCenter forperforming basic device management of a Symmetrix system. SMC isalso an exceptional product for those comfortable with SYMCLI, butwho might be looking for an easy, graphical interface for controllingtheir Symmetrix arrays. Like Solutions Enabler, the SMC Server can berun from any host which has at least one Symmetrix device visible to it.The SMC Server can also be configured to remotely connect to anotherSolutions Enabler host which has at least one Symmetrix device visibleto it. With SMC, users can manage operations from device creation tovirtual provisioning to replication configuration and monitoring. Andas needs change and grow, higher-level, storage resource managementcapabilities can easily be added via the EMC Ionix ControlCenterfamily. SMC provides a wizard based interface for setting up OpenReplicator migrations including selection of control and remote devicesthrough available devices windows.



2.5.5 EMC Ionix ControlCenterEMC Ionix ControlCenter simplifies and automates key tasks, such asdiscovery, monitoring, reporting, planning, and provisioning for eventhe largest, most complex storage environments. EMC IonixControlCenter can manage storage, fabric, and hosts, providing aunified, single-pane-of-glass view for multiple arrays, switches andhosts. When performing migrations, its GUI interface is an ideal way toboth provision the target environment and to reconfigure the SAN.

EMC Ionix ControlCenter is a family of products with additionallylicensed features including SAN Manager. Base Ionix ControlCenterpackaging includes both Solutions Enabler and SymmetrixManagement Console. The key Symmetrix Management piece is theEMC Ionix ControlCenter Symmetrix Manager. CLARiiON, Celerra,and EMC Centera® management tools can be launched from within theIonix ControlCenter framework. The EMC Ionix ControlCenterinfrastructure includes one or more dedicated server hosts and agentsthat reside on managed hosts. With this infrastructure, IonixControlCenter is able to scale to support very large enterprises.

2.6 Consulting and IT ServicesThe overall data migration flow diagram introduced in Figure 1 onpage 25, included the following project steps needed to complete a datamigration:

◆ 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 movingdata, it would be correct to conclude that the challenge of a datamigration is not just moving the data. EMC has a plethora of productsavailable to address just about every type of migration scenario you canimagine. Choosing a Data Migration Solution for EMC Symmetrix Arrayscontains greater detail. In reviewing actual migrations, it becomesevident that most migration costs are associated with discovery,documentation, mapping and design, provisioning, piloting and



qualification. Therefore, when planning a migration, it is worthconsidering contracting EMC Services for assistance in many of theseareas.

2.6.1 Infrastructure Consulting

2.6.1.1 Backup, recovery, and archiveAddress the critical storage challenge of backup and archiving byanalyzing architectural alternatives and devising strategies based oncost/benefit, capabilities, and design requirements

2.6.1.2 Business continuityDevelop a high availability and disaster recovery strategy to protectcritical business functions through an end-to-end approach, addressingpeople, process, and technology.

2.6.1.3 Cloud computing strategy serviceDevelop the business case, design the optimum architecture, and createa plan for transforming the IT organization.

2.6.1.4 ComplianceImprove alignment with business policies and industry regulationswhile reducing information management costs by providingsustainable, standardized practices.

2.6.1.5 Data center networkingIncrease the operational agility of networked infrastructure.Customized engagements to help mitigate risk, improve service levels,and realize cost advantage by mapping technology needs to businessobjectives.

2.6.1.6 Green ITAlign infrastructure strategy with business, sustainability, andtechnology goals. Reduce an enterprise’s carbon footprint whileincreasing data center efficiency and enhancing overall productivity.

2.6.1.7 Information securityMap business and regulatory requirements to policies, programs, andstrategies. Reduce risk and the cost and complexity of regulatorycompliance.



2.6.1.8 Infrastructure consolidation consultingStreamline data centers to realize cost, energy, and service deliverybenefits.

2.6.1.9 IT service managementImprove the efficiency and effectiveness of IT operations to handletoday’s rapidly growing enterprise information. Define servicecatalogs, rationalize and refine processes, and redesign ITorganizations.

2.6.1.10 Managed availability servicesProvide multi-year business continuity program support to drivecontinuing improvements in service levels. EMC consultantsrecommend, implement, and manage an ongoing business continuityprogram addressing an organization’s specific requirements.

2.6.1.11 Private cloud architecture impact advisory serviceEMC, Cisco, and VMware provide an organization and its stakeholdersan approach to modeling private cloud to the organization’s specificdata center environment.

2.6.1.12 Strategy for remote office infrastructureManage risk, cost, and performance across a distributed enterprise.EMC consultants provide a strategy that encompasses people, process,and technology. Optimize remote infrastructure to meet demandingservice-level requirements.

2.6.1.13 Virtualization servicesDevelop a holistic virtualization strategy to increase asset utilization,improve operational efficiency, raise service quality, speed ROI, andreduce overall costs.

2.6.2 Implementation

2.6.2.1 Assessment servicesIdentify possible strategies for your information infrastructure-to meetyour business and technical goals and plans.

2.6.2.2 Business continuity implementation servicesGet a complete suite of services for business continuity needs.



2.6.2.3 Design and implementation servicesGet best practices recommendations and proven methodologies forhardware and software design and implementation.

2.6.2.4 Disk security servicesSecure information and support compliance initiatives.

2.6.2.5 Enterprise content management implementation servicesCombine enterprise content management with storage, virtualization,archiving, and backup and recovery.

2.6.2.6 Migration servicesEnsure safe migration of data among EMC storage systems or betweenheterogeneous systems.

2.6.2.7 Performance assessments/health check servicesMaintain high service levels by identifying factors that affectstorage-platform performance.


EMC Open Replicator forSymmetrix

3

This chapter provides definitions and descriptions of Open Replicatorcapabilities. The full set of operational steps available to control anymigration using Open Replicator is described. Specific migrationscenarios using alternate control interfaces show examples of thesesteps in subsequent chapters. The topics covered include:

◆ 3.1 Introduction ...................................................................................... 46◆ 3.2 Definitions......................................................................................... 46◆ 3.3 Basic Open Replicator migration operation flow........................ 52◆ 3.4 Monitoring, troubleshooting and recovery.................................. 62◆ 3.5 Control interface alternatives ......................................................... 63◆ 3.6 Reference information ..................................................................... 64

EMC Open Replicator for Symmetrix 45

EMC Open Replicator for Symmetrix

3.1 IntroductionEMC Open Replicator for Symmetrix enables remote point-in-timecopies to be used for data mobility, remote vaulting, and migrationbetween EMC Symmetrix V-Max (or Symmetrix DMX) and qualifiedstorage arrays with full or incremental copy capabilities. OpenReplicator can:

◆ Pull from source volumes on qualified remote arrays to aSymmetrix V-Max (or Symmetrix DMX) volume

◆ Push any live source Symmetrix V-Max (or Symmetrix DMX)volume to a target volume on a qualified array with incrementalupdates

◆ Perform online data migrations from qualified storage toSymmetrix V-Max (or Symmetrix DMX) with minimal disruption tohost applications

3.2 DefinitionsThe Symmetrix V-Max (or Symmetrix DMX), where Open Replicatorruns, and its devices are always referred to as the control side of thecopy operation. Other Symmetrix arrays, CLARiiON arrays, orthird-party arrays on the SAN are always referred to as the remotearray/devices. Open Replicator supports two types of copy operations:push and pull. A push operation copies data from the control device tothe remote device. A pull operation copies data to the control device fromthe remote device. Open Replicator has two modes of operation: cold(offline) and hot (online). Online and offline refer to the state of theSymmetrix V-Max (or Symmetrix DMX) resident devices (controldevices). For data consistency reasons, the remote devices must never bewritten to by any host connected to the remote array. In cases where theremote device is the source of the Open Replicator copy operation (a pulloperation), it may be permissible for a remote host to have read-onlyaccess to the remote device.

3.2.1 Hot pushOpen Replicator can push data volumes out from a Symmetrix-either ina live mode (hot) or from a static copy or source volume (cold). For alive push, no local point-in-time copies of the volumes are required. TheSymmetrix creates logical point-in-time copies without having toallocate additional disk space, and I/O is permitted against the sourcevolume during the transfer. If the application attempts a write to a



location whose original point-in-time data has not yet been copied tothe remote device, then Copy on First Write (COFW) applies, delayingthe host I/O until the data is safely on the remote. All FA ports for thecontrol devices must be configured (zoned and LUN masked) to see theremote devices, so that the FA which encounters the not-yet-copied datacan perform the COFW itself. The initial hot push must be a full copy,and often includes the option to save differential information. Thesaved differential information is used when the hot push is recreatedand activated, pushing only incremental changes since the previousactivate. For data migration, this type of full hot push followed byrepeated incremental pushes would be customary, with the finalincremental push occurring while the application is shut down,allowing the remote copy to be fully up-to-date. Figure 2 illustrates anOpen Replicator hot (or live) push.

Figure 2 Open Replicator hot (or live) push

To minimize the performance impact of COFW on productionapplications, Open Replicator provides a precopy option. When theprecopy option is used, copying begins immediately at create orrecreate time and runs in the background without taking a point in timeimage of the device. COFW is not invoked until the Open Replicatorsession is activated, marking the point-in-time that must be preserved.By copying most of the data before activation, COFW will occur lessfrequently because in most cases the data will have been copied to theremote before the first write.

3.2.2 Cold pushFor cold push, the control devices must be presented as "not ready" tothe host. This ensures that there will be no need for the Symmetrix topreserve the point-in-time or handle COFW. Rather than shutting

Start: 6:00 a.m.

End: 6:15 a.m.

Image: 6:00 a.m.

TargetSTD

ICO-IMG-000434



applications down to obtain a static point-in-time, it is customary to useTimeFinder/Clone, TimeFinder/Mirror or TimeFinder/Snap to makean incrementally updateable point-in-time copy of the production data.

Note: Starting with Enginuity 5874, Solutions Enabler 7.0, and SMC 7.0, aTimeFinder/Snap virtual device (VDEV) can be used as the incrementallyupdatable TimeFinder/Snap point-in-time copy of the production volume andthe source of an Open Replicator cold push. Unlike the target devices used tohold a TimeFinder/Clone or TimeFinder/Mirror copy, which must be equal (orgreater) in size than the corresponding production data devices, VDEVs can besignificantly smaller. (Best practice is for VDEVs to consume less than 30percent of the amount of space needed to store a full copy of the productionvolumes.) The ability to only partially allocate space for the copy of theproduction devices is another condition for when cold push might be used inplace of hot push for data migration.

The TimeFinder copy then serves as the control devices for the coldpush. After the Open Replicator cold push completes, the TimeFindercopy is incrementally updated from the production copy, and the OpenReplicator session is recreated and activated pushing an incrementalupdate to the remote devices. For data migration, the application wouldbe shut down before the final TimeFinder incremental establish(recreate and activate for TimeFinder/Snap), followed by the finalOpen Replicator recreate and incremental update to achieve a fullyup-to-date remote copy.

Because there is no need for COFW and no concern for delayingapplication writes, multiple remote device copies can be made from asingle control device, and not all FA ports for the control devices must beconfigured (zoned and LUN masked) to see the remote devices. For datamobility purposes, up to 16 remote copies of the local volume can bemade, and those remote copies can all be incrementally updated.Figure 3 shows an Open Replicator cold (or BCV) push with multipletargets.



Figure 3 Open Replicator cold (or BCV) push

Cold push would be used in place of hot push for data migration for thefollowing conditions:

◆ Distance to the remote storage array is greater than 200 km or theCOFW performance penalty is unacceptable to the productionapplication.

◆ Open Replicator shared use of the bandwidth for all front-end FAports which the control devices are mapped to is unacceptable forperformance reasons.

◆ There is sufficient storage available to create a BCV, Clone or VDEVcopy of the production devices.

3.2.3 Hot pullIn pull operations, the Symmetrix volume can be in a live state duringthe copy process, which makes either restoring remotely vaultedvolumes or migrating from other storage platforms very fast andefficient. Remember that for data consistency reasons, remote devicesmust always be presented as write disabled to any host connected tothe remote array. Therefore production applications cannot run on theremote array during the Open Replicator copy. However, with hot pull,hosts and applications can begin to access the data on the control arrayas soon as the session is activated, even before the data copy processhas completed. A process referred to as Copy on First Access (COFA) isused to ensure the appropriate data is available to a host operationwhen it is needed. All FA ports for the control devices must be

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



configured (zoned and LUN masked) to see the remote devices in orderto immediately perform the COFA. Figure 4 illustrates an OpenReplicator hot (or live) pull.

Figure 4 Open Replicator hot (or live) pull

3.2.3.1 Donorupdate

Since production applications are writing to the local (control) copy,there exists the potential for data loss due to a SAN failure or otherconnectivity issue during a hot pull operation. Until the OpenReplicator copy is complete, some of the not yet copied data is only onthe remote while some of the newly written data is only available locallyon the control. The donor update option can be used to protect againstthis potential for data loss. When enabled, the donor update featureenables arrays to propagate (update) writes to the control device back tothe 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 thelocal (control) device will not be lost if an Open Replicator session has tobe restarted before completing. With donor update enabled, data is firstwritten to the target device, and then propagated to the remote sourcedevice; the host I/O write completes only if both writes are successful.

3.2.4 Cold pullOf course, a pull can also be performed in cold mode to a staticSymmetrix V-Max (or Symmetrix DMX) volume. Because there is nospecial software running on the remote array, there is no mechanism toimplement an incremental pull. Therefore, it is unlikely that cold pullwould be used for a data migration unless it is acceptable to have the

STD

ICO-IMG-000436


SB0

SB1

SB2

SB3

SB4

SB5

SB6

SB7

SB8

SB9

SB10

SB11

SB12

SB13

SB14

SB15

PiTCopy

PiTCopy

STD



production applications shut down for the entire time it takes themigration to complete. Figure 5 illustrates an Open Replicator cold (orpoint-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 givenmigration activity, if infrastructure permits, consider running those sessions ashot pulls to enable more choices to handle any issues that may arise withoutcompromising downtime objectives.

3.2.5 Open Replicator interaction rules with SRDFPrior to Enginuity 5874 and Solutions Enabler 7.0, certain interactionsbetween Open Replicator and SRDF operations were blocked.

The following SRDF operations are no longer blocked when an OpenReplicator control device is in the Created or Recreated state:

◆ SRDF establish or resume when the R2 is an Open Replicatorcontrol device

◆ SRDF restore when the R1 is an Open Replicator control device

The following Open Replicator operation is no longer blocked when theSRDF link is in the RW (Read Write or Ready) state:

◆ Open Replicator pull operation

STD

Target

Target

ICO-IMG-000437


SB0

SB1

SB2

SB3

SB4

SB5

SB6

SB7

SB8

SB9

SB10

SB11

SB12

SB13

SB14

SB15

STD

STD

Target



3.3 Basic Open Replicator migration operation flowThe basic operational flow for a migration using Open Replicator can bedivided into three main phases: setup, migration and cleanup. Thissection will define 19 steps across all three phases. The migration andcleanup phase steps will continue numbering from the phase thatprecedes it, so that step numbers will be unique across the completeoperational flow, not just within a phase. Not every step is necessary forany given migration. Steps are optional based on the particular type ofmigration (e.g., cold push vs. hot push, or hot pull). The decision pointfor optional steps is indicated by a parenthetical phrase in thenumbered step listing, or a decision diamond in the flowchartrepresentation. In chapters, 4-9, which detail specific migrationexamples, optional steps that do not apply are omitted, leaving gaps inthe numbered step listings and grayed graphics in the flowchartrepresentations.

3.3.1 Setup stepsThere are up to six setup steps. They are:

1. Configure (provision) or identify the target devices.

2. Configure/connect migration SAN zones between remote portsand Symmetrix V-Max (or Symmetrix DMX) control FA "host"ports.

3. Configure LUN masking for remote devices to allow access fromSymmetrix V-Max (or Symmetrix DMX) control FA "host" ports.

4. Configure host zoning and device (LUN) masking for targetdevices (only for hot pull migrations).

5. Prepare Open Replicator session pairs file (or define pairing inSMC GUI).

6. Verify completion of setup steps up to creating the OpenReplicator session.



Figure 6 illustrates the setup steps as a flowchart.

Figure 6 Setup steps flowchart

3.3.1.1 Step 1 detail In a migration, the source devices must already exist, but that is not thecase for target devices. Therefore, the target devices of the migrationmust be configured (provisioned) if they do not already exist. For OpenReplicator the target devices must be of the same or greater size thanthe source devices. (Open Replicator actually will migrate data from alarger source to a smaller target when the -force_copy option isspecified; this option is unlikely to be used for a straight migration, butis particularly useful for restoring back to an original smaller sourcefrom a larger target.)

Note: When the Open Replicator source device is a VDEV, the relationship withthe production device does not exist until the symsnap create command isexecuted. Exactly when the symsnap create operation is performed can vary,but it must occur before setup step 6, which includes the symrcopy createcommand. A VDEV control device can participate in only one Open Replicatorsession. Multi-virtual snap VDEVs are not supported as Open Replicator sourcedevices.

3.3.1.2 Step 2 detail Because the Symmetrix V-Max (or Symmetrix DMX) FA port will act asan open systems host to the remote storage array, it is necessary to set upone or more migration SAN zones for access to the remote ports. Thisset-up includes identifying the Symmetrix V-Max (or Symmetrix DMX)control FA ports World Wide Names (WWNs). For hot operations theseWWNs must all be included in migration zone sets, for cold operationsthe WWNs can be selectively included in migration zone sets. It is alsonecessary to identify the remote storage array WWN for access to theremote devices. The actual zone definition operation can be completedwith Connectrix Manager, EMC Ionix ControlCenter SAN Manager, ornative 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 hostY

N



3.3.1.3 Step 3 detail Because the Symmetrix V-Max (or Symmetrix DMX) FA "host" isconnected to the remote storage array on a switched fibre port, it isnecessary to perform LUN masking so that the Symmetrix V-Max (orSymmetrix DMX) FA initiator is defined as having access to the remotedevices. This LUN masking is performed with tools specific to theremote storage array. Commands for performing this operation for aremote CLARiiON array are introduced in the next chapter, and device(LUN) masking for a remote Symmetrix will be shown in subsequentexamples.

3.3.1.4 Step 4 detail For Symmetrix, device masking is the term used for LUN masking (forSymmetrix V-Max with Enginuity 5874, the Auto-provisioning Groupsfeature provides an easier, faster way to provision storage replacing theold way of configuring device masking). Before a migration is completeit is always necessary to ensure that the appropriate host applicationsare able to access the target devices in place of the original sourcedevices. For hot pull migrations, this step is performed prior toinitiating the movement of data from the source (remote) to the target(control).

3.3.1.5 Step 5 detail Open Replicator requires the definition of control-remote pairs; multiplepairs 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 canalways be used for any device. The Symmetrix device name format canalways be used for the control device and in some cases for the remotedevice. If the Solutions Enabler database has discovered the remoteSymmetrix or CLARiiON array, then the Symmetrix or CLARiiONdevice format can be used for the remote device. When using the SMCGUI, the process of selecting control and remote devices is made easierwith the ability to selectively filter a list of available devices. The WWNformat can easily be selected with a click, avoiding the need to correctlyenter the lengthy WWN strings.

3.3.1.6 Step 6 detail The final setup step is to use the defined control-remote pair file (or GUIselection) to create the Open Replicator session. The create operationvalidates all necessary control FA access to remote devices and will fail ifthe pair definition, zoning or LUN masking is not defined correctly. Thecreate action can be considered part of the setup phase because itdoes not begin migration data movement in most cases (hot pushoperations that specify the -precopy option do initiate migration datamovement).



Note: In some cases, SCSI reservations for devices under cluster control or theAIX operating system will prevent the create operation from being successful.In this case alternate verification options can be used; more information aboutthese options is available in Section 4.6, “Setup step 6, verify completion ofsetup steps,” on page 75.

Note: The symrcopy create command is described to be the most thoroughtest for verifying the completion of the Open Replicator setup phase. Thealternative methods of verifying the completion of the setup phase (withoutrunning the symrcopy create action) are not sufficient when using a VDEVcontrol device. The specific order of operations requires that the symrcopy create command is executed before the symsnap activate command inmigration step 7.



3.3.2 Migration stepsA single migration will use four to seven of the eight potentialmigration steps. Note that step numbering continues at seven to followthe 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 theOpen Replicator session(only needed if the session was not created during setup and notterminated 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 productionapplication (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 toincrementally update the remote.

c. Repeat steps 14a-14b 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 finalincremental push.

15. Verify migration is complete and terminate Open Replicatorsession.

Figure 7 on page 57 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 pushfrom 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



3.3.2.1 Steps 7through 15 detail

Steps 7 through 15 consist of the following:

◆ Step 7, initialize the BCV, clone or VDEV control device with apoint-in-time copy of the production device, is necessary when thecontrol device is a BCV, clone, or VDEV device. Step 7 must precedestep 8 when the control device is a TimeFinder/Mirror BCV, becausethe split operation makes the BCV an independent device.

Note: The symsnap and symrcopy commands needed to support cold pushfrom a VDEV device must be performed in a specific order. The general rule isthat the parallel symsnap action (create, activate, or recreate) mustprecede the same symrcopy operation. The symsnap activate -not_ready command sets the TimeFinder/Snap point-in-time and mustprecede migration step 10. The -not_ready option is used to keep the VDEVin the Not Ready state, which is required while the Open Replicator session ispresent.

◆ Step 8, create the Open Replicator session, is needed if thecreate is postponed from the setup phase or if TimeFinderoperations in step 7 require that the Open Replicator session is notin the created state.

◆ Step 9, stop the applications, is necessary for pull operationsbecause the remote source data must not be changed once the pullmigration session is activated.

◆ Step 10, activate the Open Replicator session, is the key migrationphase step, setting the point-in-time for the migration copy.

◆ Step 11, restart the application pointing to the target devices is partof the migration phase only for hot pull migrations; for all othermigrations the restart is completed as part of the cleanup phase.

◆ Step 12, tune the migration, is optional; it is available to adjust themigration impact on production applications as needed.

◆ Step 13, wait and monitor for completion of the migration copy, ismost likely the step that will take the longest time.

◆ Step 14, iteratively applying incremental updates, is necessary forpush migrations to propagate production application changes to thetarget (remote) until production application changes cease when theapplications are stopped.

When using a VDEV control device, step 14a, the TimeFinderincremental update, cannot activate the recreated TimeFinder/Snapsession 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_readyoption to keep the VDEV in the Not Ready state). Therefore whenusing TimeFinder/Snap the order of operations for steps 14a-14bmust be:

1. symsnap recreate

2. symrcopy recreate

3. symsnap activate -not_ready

4. symrcopy activate

◆ Step 15, terminate the Open Replicator session, is completed oncethe migration is verified because data migration is the one-timemovement of data from source to target so the session is no longerneeded. The symrcopy terminate command must precede anysymsnap terminate commands.



Tuning Open Replicator — Typically there are two conflictingperformance goals for a data migration. First, it is necessary for themigration to complete within the planned for migration window.Second, the data migration should not cause unacceptable levels ofperformance degradation for production applications. Open Replicatorshares the processing power of the front-end fibre (FA) director and thebandwidth of the fibre path with the production applications. OpenReplicator provides three alternatives for tuning Open Replicatorperformance: the ceiling parameter which limits fibre bandwidth thatcan be used by Open Replicator, the pace parameter which definesdelays added between Open Replicator operations, and the nocopymode which suspends Open Replicator copy activity.

The primary tuning mechanism is the Open Replicator ceilingparameter. Ceiling is set to the maximum percentage of the fibrebandwidth that can be used by Open Replicator. By default this value isnot set, theoretically allowing Open Replicator to use up to 100 percentof the bandwidth. The secondary tuning mechanism is the paceparameter. Pace is a value set between 0 and 10 (default 5), whichtranslates to a position in a table that adds a delay between OpenReplicator I/O transfers. The larger the pace value, the longer the delay.

Another method of tuning is setting the mode to nocopy, which willeffectively stop all Open Replicator I/O except for copy operationsrequired when in hot mode to preserve the point-in-time (copy on firstwrite for hot push, and copy on first access for hot pull). This method ismost likely used in special circumstances when it is necessary to limitnonproduction I/Os as much as possible. It will be necessary to set themode back to copy for the copy session to complete the migration.

Ceiling is considered the best tuning mechanism because it deliversfixed, accurate, repeatable results that can be based on observed andcalculated values. Pace values greater than zero will always add OpenReplicator processing delays, even when Open Replicator I/Os wouldnot get in the way of production applications. The PPME throttlemechanism is an alternate interface to the Open Replicator paceparameter. The pace value is ignored for all participating director/portcombinations where the ceiling value is not NONE, including PPMEOpen Replicator sessions.



3.3.3 Cleanup stepsFigure 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 theoriginal source devices (needed for all but hot pull operations).

19. Redeploy the source devices storage now that the migration iscomplete.

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 instep 16 and adding the target devices as host visible devices in step 17.In the case of hot pull steps 16-18 are skipped because the productionapplications were restarted using the target devices in the migrationphase.

Note the use of the term target devices which would usually mean theremote devices in the case of a hot or cold push, or in the unusual case ofusing cold pull for a data migration it would mean the control devices.Step 19, redeploys the source devices’ storage, which is now free fornew uses.

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



These steps are identified as being in the cleanup phase because OpenReplicator actions ended with the termination of the session in themigration phase. PowerPath Migration Enabler (PPME) includesalternate commands to achieve the outcomes of step 11 and steps 15-18for hot pull operations under PPME control. These alternate commandsprovide the PPME advantages of greatly reducing or eliminatingapplication disruptions due to these steps, reducing migration risk, andsimplifying migration operations.

Note: Chapter 8, “PowerPath Migration Enabler (PPME) Overview,” introducesa more comprehensive and reordered description of these alternate cleanupsteps.

3.4 Monitoring, troubleshooting and recoveryBest practices for monitoring, troubleshooting and recovery will beshown in the examples detailed in the following chapters. The range oftools available will first be introduced here. When using OpenReplicator the vast majority of problems encountered result from errorsin setting up the initial zoning and LUN masking. This chapterintroduced the Open Replicator create action as an effective tool toverify complete setup.

Chapter 4, “Cold Push to CLARiiON Setup Example,” will go intoadditional detail for interpreting setup errors reported by create andalternatives to create for verifying correct setup. Once a migration isstarted, there are basic tools for monitoring the copy session progress.The query action will list the status of the control and remote pairs andthe progress of the copy sessions. The verify action can be used todetermine if an expected status exists, and the interval and countoptions can be set up to loop until the desired state is achieved. Thereturn code from verify operations can be used effectively within ascript to branch based on the status of the copy sessions. Besides 100percent completion of a copy operation, the other important status todeal with is a failed copy operation. Recovery from a failed operation isgenerally dealt with by simply restarting the copy operation and takinga new point-in-time. In the case of hot pull, a new point-in-time wouldonly be valid on the remote, provided the -donor_update option wasused.

Appendix B, “ Troubleshooting,” provides log information thatcorrelates with the examples presented in Chapters 4 through 9, and anexample of reactivating a failed differential push session.



3.5 Control interface alternativesThere are three different interfaces available to control EMC OpenReplicator for Symmetrix: the Solutions Enabler Command LineInterface (SYMCLI), the Symmetrix Management Console (SMC)Graphical User Interface (GUI), and the PowerPath Migration Enabler(PPME) CLI.

3.5.1 Solutions Enabler CLIThe Solutions Enabler Command Line Interface (SYMCLI) supportsEMC Open Replicator for Symmetrix operations with the symrcopycommand. The symsan command, which lists ports visible from agiven director port and LUNs visible behind a given remote port, isparticularly helpful for verifying that zoning and LUN masking hasbeen correctly configured for Open Replicator operations.Configuration of devices, mapping, and masking is also supported bythe symconfigure, symmask and symmaskdb commands. Outputavailable from symdev, sympd, and symcfg commands may also behelpful in manually verifying key Open Replicator related information.

3.5.2 Symmetrix Management Console GUIThe Symmetrix Management Console (SMC) Graphical User Interface(GUI) supports EMC Open Replicator for Symmetrix operations withthe Open Replicator create and session control wizards. The createwizard gets invoked from the control menu for the local Symmetrixarray. This five-page wizard progressively moves the user through theprocess of specifying all of the information needed to create an OpenReplicator 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, thewizard jumps from page 1 to page 5. Once created, Open Replicatorsession control is available from the Control, Replication menu. SMCalso supports Remote Report, which like symsan lists ports visiblefrom a given director and LUNs visible behind a given remote port.



3.5.3 PowerPath Migration Enabler (PPME) CLIThe PowerPath Migration Enabler (PPME) CLI supports EMC OpenReplicator for Symmetrix operations with the powermig command.Since Open Replicator will be used as the underlying technology for themigration, setup steps 1-4 are conducted in the same way as listed inSection 3.3.1, ”Setup steps,” on page 52. The powermig command hasits own setup action to configure the source and target pair devices.The Open Replicator hot pull operation is then initiated by thepowermig sync command. The rest of the powermig actions are usedto monitor progress until completion of the synchronization, and thento conduct application cutover to the target devices. These cutover stepsgo beyond the scope of the migration data movement steps available inSolutions Enabler and SMC. Without PPME, cutover steps need to beconducted in host and application specific ways.

3.6 Reference informationSpecific details of the Solutions Enabler Open Replicator commands canbe found in the Solutions Enabler Symmetrix Open Replicator CLI ProductGuide. This TechBook includes all migration-related features availablein Open Replicator at the time of publication; not all of these actions oroptions are available in earlier code releases. The EMC Solutions EnablerSymmetrix Open Replicator CLI Product Guide and the EMC SolutionsEnabler Release Notes provide details about feature availability.

Specific details of the Symmetrix Management Console OpenReplicator screens can be found in the online help within the product.

An example of special considerations for necessary steps dealing withclustered hosts can be found in the Migrating Microsoft Cluster Serverusing EMC Open Replicator for Symmetrix Technical Note.


Cold Push to CLARiiONSetup Example

4

This chapter provides an operational example of the setup phase.Together with Chapter 5, “Cold Push to CLARiiON MigrationExample,” a complete example of all the steps needed to execute a coldpush using SYMCLI on a Solaris host is provided. Alternate examplesfor verifying successful completion of the setup step is presented. Thetopics covered include:

◆ 4.1 Introduction ...................................................................................... 66◆ 4.2 Setup step 1, identify target devices.............................................. 66◆ 4.3 Setup step 2, configure migration SAN zones ............................. 68◆ 4.4 Setup step 3, configure migration LUN masking........................ 73◆ 4.5 Setup step 5, prepare Open Replicator session pairs.................. 74◆ 4.6 Setup step 6, verify completion of setup steps ............................ 75

Cold Push to CLARiiON Setup Example 65

Cold Push to CLARiiON Setup Example

4.1 IntroductionThis chapter details the setup steps for a cold push to a CLARiiONusing Solutions Enabler SYMCLI on a Solaris host. Because step 4 of thesetup steps introduced in chapter 3 is only completed for hot pullmigrations, 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 remotedevices and Symmetrix V-Max (or Symmetrix DMX) control FA"host" ports.

3. Configure LUN masking for remote devices to allow access fromSymmetrix V-Max (or Symmetrix DMX) control FA "host" ports.



4.2 Setup step 1, identify target devicesAs mentioned in Section 3.3.1.1, “Step 1 detail,” on page 53, the targetdevices of the migration must be configured (provisioned) if they donot already exist. For Symmetrix arrays, the Solutions Enablersymconfigure command, SMC's Device Configuration screens orEMC Ionix ControlCenter Symmetrix Manager can be used to configuretarget devices of an equal or greater size than the source devices. For allremote devices it is necessary to know the device world wide name(WWN). However, if the remote Symmetrix or CLARiiON device hasbeen discovered and is in the Solutions Enabler database file, then theSymmetrix or CLARiiON array ID and device number ("name") can beused in place of the WWN. Open Replicator will use the array specificidentification to obtain the WWN from the database file. This isgenerally easier to use than dealing with lengthy WWN strings.

In order to discover a CLARiiON, the symcfg authorizationcommand must first be used to associate a CLARiiON storageprocessor IP address with a username and password. The discoveroperation requires either the -clariion option to discover onlyCLARiiON arrays, or the -all option to discover both Symmetrix andCLARiiON arrays. Once discovered, information about the CLARiiONdevices can be displayed using the -clariion option. For example onpage 67:



# 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 -clariionC L A R I I O N

Firmware Num Num Phys Num ClarClarID 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 600601602b401e00148f6936d93bdd1100001 Not Visible Raid-5 4096 600601602b401e00158f6936d93bdd1100002 Not Visible Raid-5 4096 600601602b401e00168f6936d93bdd1100003 Not Visible Raid-5 4096 600601602b401e00178f6936d93bdd1100004 Not Visible Raid-5 4096 600601602b401e00188f6936d93bdd1100005 Not Visible Raid-5 4096 600601602b401e00198f6936d93bdd1100006 Not Visible Raid-5 4096 600601602b401e001a8f6936d93bdd1100007 Not Visible Raid-5 4096 600601602b401e001b8f6936d93bdd1100008 Not Visible Raid-5 4096 600601602b401e00bae08e938a47dd1100009 /dev/rdsk/emcpower3c Raid-5 4096 600601602b401e001078c2a48a47dd11

#If the remote array is not a CLARiiON or a Symmetrix, or not in thedatabase, then it is necessary to use the WWN. The Solutions Enablersyminq command and the similar inq command can be used todisplay WWN information for Symmetrix, CLARiiON and third-partyarrays. For example:

# syminq -clariion -cids -wwnDevice Device

--------------------------------- ------------------- ---------------------------------Name Num Array ID WWN--------------------------------- ------------------- ---------------------------------/dev/rdsk/c2t5006016A41E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/rdsk/c2t5006016241E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/rdsk/c4t5006016041E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/rdsk/c4t5006016841E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/rdsk/emcpower3c 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/vx/rdmp/emcpower3s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11

#



4.3 Setup step 2, configure migration SAN zonesAs the Symmetrix V-Max (or Symmetrix DMX) FA port will act as anopen systems host to the remote storage array, it is necessary to set upone or more migration SAN zones for access to the remote devices.Therefore, both the local (control) director WWN(s) and the remotefront-end WWN(s) must be determined.

4.3.1 Determining Control Director WWNThe control is always a Symmetrix device, so Solutions Enabler, SMC orEMC Ionix ControlCenter can be used. First it must be determined onwhich directors the control devices are visible. The Solutions Enablersymdev list -multiport command is one of the easiest ways toobtain this information. In the following example, the four controldevices: 80, 81, 82 and 83, are all mapped to both director 2C port 0 anddirector 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-------------------------------- ------------- ---------------------------------------

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

0080 01A:C6 2-Way BCV Mir N/Asst'd RW 4096Not Visible - 02C:0 - - - - -Not Visible - 15C:0 - - - - -

0081 16B:C6 2-Way BCV Mir N/Asst'd RW 4096Not Visible - 02C:0 - - - - -Not Visible - 15C:0 - - - - -

0082 16A:DC 2-Way BCV Mir N/Asst'd RW 4096Not Visible - 02C:0 - - - - -Not Visible - 15C:0 - - - - -

0083 15B:C7 2-Way BCV Mir N/Asst'd RW 4096Not Visible - 02C:0 - - - - -Not Visible - 15C:0 - - - - -

#Note that the -multiport option will only list devices with more thanone path. If there is only a single path, then symdev list should beused without the -multiport option.



The FA director port world wide port name (WWPN or WWN) can bedisplayed 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 PntEnabled Addressing

FA-2C 0 5006048AD5F031C1 Yes No Yes

# symcfg -sid 359 list -fa 15c -p 0



Dir Port WWN VCM Volume Set Pnt to PntEnabled Addressing

FA-15C 0 5006048AD5F031CE Yes No Yes

4.3.2 Determining Remote Storage Array WWN(s)The remote storage array can be a Symmetrix, a CLARiiON or athird-party array. For a remote Symmetrix array the procedure fordetermining the WWPN for the remote FA director is the same as theone used to obtain the WWPN for the local director on a Symmetrix.

For a remote CLARiiON array, the Navisphere GUI can be used todetermine the Storage Processor(SP) WWPNs. CLARiiON LUNmasking is accomplished using storage groups, where all devices in thesame Storage Group are defined to be accessible to all hosts in the



Storage Group. Figure 9 illustrates right-clicking on the host in theStorage Group containing the remote devices (LUNs) in order to selectthe Connectivity Status for that host.

Figure 9 Invoking Connectivity Status for Host in a Storage Group

Figure 10 on page 71 shows that four paths between the CLARiiON andhost LICOD229 can be used to access LUNs 4, 5, 6 and 7. However, theCLARiiON LUNs are owned by only one SP at one time. For faulttolerance, a LUN can trespass over to the other SP; therefore it isnecessary 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 2highlighted 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 thearray to determine the WWPNs to use in the zoning.

ICO-IMG-000533

ICO-IMG-000534



4.3.3 Selective or all Symmetrix FA ZoningFor cold operations it is not necessary to zone all possible paths. Thisallows the user to limit migration movement to selective paths. For hotoperations it is required that all Symmetrix FA ports that are mappedby the control devices be zoned and LUN masked to "see" the remotedevices.

4.3.4 Example configuration of migration SAN zonesIn this example, only a single active path and the minimum zoningnecessary for a cold operation is illustrated. Two paths must beconfigured for this case, since the remote is a CLARiiON storage array;the second path is needed to handle the condition of the remote LUNtrespassing from one SP to the other SP. Figure 12 shows an excerpt ofthe Connectrix Manager Zoning verification screen with the single pathand standby path zones defined.

Figure 12 Connectrix Manager activate zone verification screen

ICO-IMG-000535



4.4 Setup step 3, configure migration LUN masking

4.4.1 Create CLARiiON storage groupBecause the Symmetrix V-Max (or Symmetrix DMX) FA "host" isconnected to the remote storage array on a switched fibre port, it isnecessary to perform LUN masking to grant the Symmetrix V-Max (orSymmetrix DMX) FA initiator access to the remote devices. This LUNmasking is performed with tools specific to the remote storage array.Here, an example of Storage Group based LUN masking for theCLARiiON using navicli is presented.

The default location of Navisphere executables on UNIX operatingsystems is /opt/Navisphere/bin. The network hostname for theCLARiiON SPA IP address is Clar0031_SPA. First, the StorageGroup OR_Symm359 is created by executing a command that lookssomething like this:

# cd /opt/Navisphere/bin# ./navicli -h Clar0031_SPA storagegroup -create -gname OR_Symm359

4.4.2 Register host and add devices to CLARiiON storage groupNext, the Symmetrix FA "host" is manually registered for both the SPBport 0 and SPA port 0 in the storage group. Then the four remote devicesare added to the storage group. For each CLARiiON LUN devicenumber (-alu), the LUN number presented to the host (-hlu) isdefined.

# ./navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A:D5:F0:31:C1:50:06:04:8A:D5:F0:31:C1 -sp b -spport 0 -host Sym0359 -failovermode 1 -o -unitserialnumber array# ./navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A:D5:F0:31:C1:50:06:04:8A:D5:F0:31:C1 -sp a -spport 0 -host Sym0359 -failovermode 1 -o -unitserialnumber array# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname OR_Symm359 -alu 04 -hlu 00# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname OR_Symm359 -alu 05 -hlu 01# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname OR_Symm359 -alu 06 -hlu 02# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname OR_Symm359 -alu 07 -hlu 03



4.5 Setup step 5, prepare Open Replicator session pairsOpen Replicator requires the definition of control-remote pairs. Multiplepairs grouped into a single file can be managed together by OpenReplicator. The control device is identified in the first (leftmost) columnand the remote device is identified in the second (rightmost) column.

The array ID must be fully specified and is separated from thedevice/LUN name (number) by a colon. Since the CLARiiON wasdiscovered into the SYMAPI database file (Section 4.2, ”Setup step 1,identify target devices,” on page 66), the clardev= format can be usedfor the remote devices in the file:

# cat cold_orpairssymdev=000190300359:0080 clardev=HK190807410004:00004symdev=000190300359:0081 clardev=HK190807410004:00005symdev=000190300359:0082 clardev=HK190807410004:00006symdev=000190300359:0083 clardev=HK190807410004:00007#



4.6 Setup step 6, verify completion of setup steps

4.6.1 Create action is a thorough verification stepThe most thorough test for verifying the completion of the setup stepsis to create the Open Replicator session. The create operationverifies all necessary control FA access to the remote devices and willfail if the pair definition, zoning or LUN masking is not correctlydefined. Create does not begin the migration itself, except in the casewhen the -precopy option is specified for hot push operations. Insome cases, SCSI reservations for devices under cluster control willprevent the create operation from being successful. In these casesalternate verification options, presented next, can be used in place ofthe create.

Note: When the Open Replicator source device is a VDEV, the relationship withthe production device does not exist until the symsnap create command isexecuted. Exactly when the symsnap create operation is performed can vary,but it must occur before setup step 6, which includes the symrcopy createcommand.

4.6.2 Verify zoning with symsan -sanports

Solutions Enabler 6.4 with Enginuity 5772 introduced the symsancommand, which was designed explicitly for verifying the correct OpenReplicator zoning and masking. The zoneOR_Symm0359_2C0_Clar0031_SPB_0 created in the Section 4.3.4,”Example configuration of migration SAN zones,” on page 72 includedthe WWN for Symmetrix FA director 2C port 0, and the WWN forCLARiiON SP B port 0. The zoneOR_Symm0359_2C0_Clar0031_SPA_0 included the same SymmetrixFA WWN with the CLARiiON SP A port 0, in case of LUN trespassfrom SP B to SP A. The symsan -sanports command lists the WWNsthat are zoned together with the specified Open Replicator FA port. TheRemote Port WWN 5006016841E087E6 is the SP B port 0 WWN. TheRemote Port WWN 5006016041E087E6 is the SP A port 0 WWN. Thesymsan output also identifies the array as a CLARiiON, including thearray ID and also the number of LUNs visible behind each WWN. Agreater than zero Num LUNs value indicates the number of LUNs thatare successfully LUN masked. Since four LUNs were expected thiscould be interpreted as successful remote LUN masking. For example:

# symsan -sid 359 list -sanports -dir 2c -p 0




Flags NumDIR:P I Vendor Array LUNs Remote Port WWN----- ----- ------------- ---------------- ---- -------------------------------02C:0 . EMC CLARiiON HK190807410004 4 5006016841E087E602C:0 . EMC CLARiiON HK190807410004 4 5006016041E087E6

Legend:Flags: (I)ncomplete : X = record is incomplete, . = record is complete.



4.6.3 Verify LUN masking with symsan -sanluns

In order to be certain that the correct LUNs are masked, thesymsan -sanluns command can be used to list the LUN WWNsbehind the Remote Port WWN. In the output produced by thiscommand, the Dev Num (Device Number) column indicates theCLARiiON device number. Additionally each record can be checked forthe correct device Capacity.

# symsan -sid 359 list -sanluns -wwn 5006016841E087E6 -dir 2c -p 0

Symmetrix ID: 000190300359Remote Port WWN: 5006016841E087E6

STAT Flags Block Capacity LUN Dev LUN

DIR:P E ICRTHS Size (MB) Num Num WWN----- -- ------- ----- ----------- ----- ----- --------------------------------02C:0 RW ...... 512 4096 0 0004 600601602B401E00188F6936D93BDD1102C:0 RW ...... 512 4096 1 0005 600601602B401E00198F6936D93BDD1102C:0 RW ...... 512 4096 2 0006 600601602B401E001A8F6936D93BDD1102C:0 RW ...... 512 4096 3 0007 600601602B401E001B8F6936D93BDD11


(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, . = Unknownt(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 twoflags to indicate thin device and Symmetrix device. A thin device is not eligibleto be a source device for Open Replicator. Open Replicator pull support foriSeries requires the remote device to be on a Symmetrix array.



4.6.4 Verify zoning with symmask list logins

If the Solutions Enabler version is less than 6.4.2 or the SymmetrixEnginuity level is less than 5772.83, the symsan command is notavailable. In this case, the symmask list logins command can beused to determine if the zoning was successful. At the time of activatingthe zone including the OR FA port "host," all participants in the zoneshould log on to the SAN fabric. The display below shows WWNIdentifiers On Fabric, but not Logged In with the standardCLARiiON prefix 500601 (Logged Inwill change to Yes after an OpenReplicator activate action). The full WWN match the WWN for SPAport 0 and SP B port 0. For example:

# symmask -sid 359 list logins -dir 2c -p 0

Symmetrix ID : 000190300359

Director Identification : FA-2CDirector Port : 0

User-generated Logged OnIdentifier Type Node Name Port Name FCID In Fabric---------------- ----- --------------------------------- ------ ------ ------10000000c97111fc Fibre 10000000c97111fc 10000000c97111fc 6b0900 Yes Yes5006016041e087e6 Fibre NULL NULL 6167ef No Yes5006016841e087e6 Fibre NULL NULL 6177ef No Yes210000e08b927df4 Fibre 210000e08b927df4 210000e08b927df4 610613 Yes Yes

One important caveat about using the list logins command is thatthe reported state is not necessarily current. The key is the firstappearance of the WWN. However once on fabric, the informationremains on the list logins output regardless of whether the WWN iscurrently On Fabric. For Symmetrix V-Max, symaccess listlogins wouldbe used in place of symmask.



4.6.5 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 includesthe -precopy option, it is wise to fully test the setup by creating theOpen Replicator session.

Note: When the Open Replicator source device is a VDEV, the specific order ofoperations requires that the symrcopy create command is executed beforethe symsnap activate command in migration step 7. The symsnap create operation creates the relationship with the production device andmust be executed before the symrcopy create command.

Using the cold_orpairs file from Section 4.5, ”Setup step 5, prepareOpen Replicator session pairs,” on page 74 the cold push is created asfollows:

# symrcopy -file cold_orpairs -push -cold create

'Create' operation execution is in progress for the device listin device file 'cold_orpairs'. Please wait...

The device is not in a valid Ready status. Operation cannot proceed

As mentioned when first defining Section 3.2.2, “Cold push,” on page47, cold operations require the control devices to be in the Not Readystate. This can be verified as follows:

# cat cold_controldevs80818283# 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 devicesin device file 'cold_orpairs' (y/[n]) ? y


'Create' operation successfully executed for the device listin device file 'cold_orpairs'.

#The successful execution of the create operation confirms that allnecessary zoning and LUN masking is correctly in place.



4.6.6 SMC Remote ReportThe Symmetrix Management Console provides a GUI equivalent tosymsan. Figure 13 illustrates invoking the Remote Report menu froman initial right click of the control Symmetrix array, and choosingReplicationOpen ReplicatorRemote Report.

Figure 13 SMC Remote Report menu selection

ICO-IMG-000536



Remote Report has two tabs. Figure 14 illustrates the Remote Ports tabshowing information similar to the symsan -sanports display fordirector 2C port 0.

Figure 14 SMC Remote Report Remote Ports

Clicking on the Remote Luns tab and selecting director 2Cautomatically selects the first WWN displayed in the Remote Portsdisplay. 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 theavailable list with the successfully mapped remote devices. Figure 16illustrates page 3 of the Create Copy Session wizard where the availableremote devices are populated from the Remote Report information.

Figure 16 Create Page 3 showing CLARiiON Available Remote Devices

ICO-IMG-000539


Cold Push to CLARiiONMigration Example

5

This chapter details the migration and cleanup phases for a cold pushmigration example using Solutions Enabler SYMCLI on a Solaris host.The setup phase steps were already covered in Chapter 4, “Cold Pushto CLARiiON Setup Example.” The topics covered include:

◆ 5.1 Introduction ...................................................................................... 84◆ 5.2 Migration step 7, BCV split............................................................. 87◆ 5.3 Migration step 8, symrcopy create ................................................ 92◆ 5.4 Migration step 10, symrcopy activate ........................................... 96◆ 5.5 Migration step 12, symrcopy set ceiling ....................................... 97◆ 5.6 Migration step 13, symrcopy query and verify ........................... 99◆ 5.7 Migration step 14, iterative symrcopy recreate ......................... 100◆ 5.8 Migration step 15, verify migration and symrcopy terminate 104◆ 5.9 Cleanup step 16, make source devices host inaccessible ......... 106◆ 5.10 Cleanup step 17, make target devices ready to host............... 107◆ 5.11 Cleanup step 18, restart applications using targets ................ 108◆ 5.12 Cleanup step 19, redeploy the source devices’ storage .......... 110

Cold Push to CLARiiON Migration Example 83

Cold Push to CLARiiON Migration Example

5.1 IntroductionThis chapter details the migration and cleanup phases for a cold pushmigration example using Solutions Enabler SYMCLI on a Solaris host.The five setup steps required for the cold push were covered inChapter 4, “Cold Push to CLARiiON Setup Example.” This chaptercontains detailed examples of the seven migration steps introduced inSection 3.3.2, “Migration steps,” on page 56 that are applicable for acold push (steps 9 and 11 only completed for pull migrations areomitted):

7. Split the BCV or activate the clone or VDEV.

8. Open Replicator session create.


12. Tune migration to acceptable level of impact on productionapplication.


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 toincrementally update the remote.

c. Repeat steps 14a-14b until all updates have been processed,shut down the application before the last update in step 14ato 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 ofthe original source devices.




Figure 17 on page 86 illustrates the cold push migration and cleanupsteps in a flowchart. The paths from decision diamonds which is nottaken and omitted steps are grayed to show they are not conducted forthis cold push example. The step 14 detail, which includes threesubsteps (a-c) and related decision diamonds, shows all paths and stepswithout graying, because each path and step is performed at least once.



Figure 17 Cold push migration and cleanup flowchart

ICO-IMG-000540a



17. Make target devices ready to host




16. Make source devices inaccessible

15. Verify migration terminate OR 14b. OR recreate and

activate

14a. TimeFinder incremental update

14c. Stop the application


Hot pull?

Last update?

Cold push?

Need tuning?


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



or VDEV?

Y



5.2 Migration step 7, BCV split

5.2.1 Device Group creationFor a cold push, it is common to use a TimeFinder/Mirror BCV,TimeFinder/Clone BCV or target device, or TimeFinder/Snap VDEV asthe control device; this example will use a TimeFinder/Mirror BCVdevice. For this example the application uses the file system at mountpoint /cphome, a VxVM logical volume made up of 4 Symmetrixdevices: A0 - A3.

# mount. . ./cphome on /dev/vx/dsk/cpvg/cplv read/write/setuid/devices/delaylog/largefiles/ioerror=mwdisable/dev=48c80e8 on Mon Jun 30 17:39:47 2008. . .

The mount command showed /cphome as a VxVM logical volumecplv, which is part of the volume group cpvg.

# vxprint -g cpvg -htDG NAME NCONFIG NLOG MINORS GROUP-IDST NAME STATE DM_CNT SPARE_CNT APPVOL_CNTDM NAME DEVICE TYPE PRIVLEN PUBLEN STATERV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRLRL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNKCO NAME CACHEVOL KSTATE STATEVT NAME NVOLUME KSTATE STATEV NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL PREFPLEX UTYPEPL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODESD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODESV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODESC NAME PLEX CACHE DISKOFFS LENGTH [COL/]OFF DEVICE MODEDC NAME PARENTVOL LOGVOLSP NAME SNAPVOL DCO

dg cpvg default default 33000 1214852481.33.licod229

dm cpvgd0 emcpower380s2 auto 2048 8382336 -dm cpvgd1 emcpower381s2 auto 2048 8382336 -dm cpvgd2 emcpower382s2 auto 2048 8382336 -dm cpvgd3 emcpower383s2 auto 2048 8382336 -

v cplv - ENABLED ACTIVE 33529344 SELECT - fsgenpl cplv-01 cplv ENABLED ACTIVE 33529344 CONCAT - RWsd cpvgd0-01 cplv-01 cpvgd0 0 8382336 0 emcpower380 ENAsd cpvgd1-01 cplv-01 cpvgd1 0 8382336 8382336 emcpower381 ENAsd cpvgd2-01 cplv-01 cpvgd2 0 8382336 16764672 emcpower382 ENAsd cpvgd3-01 cplv-01 cpvgd3 0 8382336 25147008 emcpower383 ENA

The vxprint command for cpvg showed that the four devices thatmake up the volume group cpvg use pseudo device namesemcpower380s2 - emcpower383s2.



# sympd list -sid 359 -powerpath


P O W E R P A T H D E V I C E S

Device Name DirectorsDevice

------------------------------------- -------------------------------------------------Cap

Physical Sym SA :P DA :IT Config Attribute Sts (MB)------------------------------------- ------------ ------------------------------------. . ./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/rdsk/emcpower381c - 15C:0 - - - - -/dev/rdsk/c4t5006048AD5F031C1d145s2 - 02C:0 - - - - -/dev/rdsk/c2t5006048AD5F031CEd145s2 - 15C:0 - - - - -

/dev/vx/rdmp/emcpower382s2 00A2 15A:C4 2-Way Mir Grp'd RW 4096/dev/rdsk/emcpower382c - 15C:0 - - - - -/dev/rdsk/c4t5006048AD5F031C1d146s2 - 02C:0 - - - - -/dev/rdsk/c2t5006048AD5F031CEd146s2 - 15C:0 - - - - -

/dev/vx/rdmp/emcpower383s2 00A3 02B:DD 2-Way Mir Grp'd RW 4096/dev/rdsk/emcpower383c - 15C:0 - - - - -/dev/rdsk/c4t5006048AD5F031C1d147s2 - 02C:0 - - - - -/dev/rdsk/c2t5006048AD5F031CEd147s2 - 15C:0 - - - - -. . .#

The sympd list command output shows that Symmetrix logicalvolumes A0 - A3 correspond to pseudo device names emcpower380s2- emcpower383s2. The example below: creates the device groupcpgroup and populates it with the STD application devices A0 - A3.Since, TimeFinder/Mirror BCVs will be used as the source devices forOpen Replicator, BCV devices 80 - 83 are associated with the devicegroup.

# 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 sameway or target devices (TGT) could be added to the group with thefollowing command:symld -g cpgroup add dev NN -tgt

If TimeFinder/Snap was being used, a VDEV would be added to thegroup with the following command:symld -g cpgroup add dev NN -vdev



5.2.2 Initial TimeFinder/Mirror establishMigration step 7 is to split the BCV. Since the initial state of the BCV isNever Established, it is necessary to first synchronize the BCV withthe STD. Before the BCV can be used in a full establish operation, theOpen Replicator session created earlier as part of verifying completionof the setup phase must be terminated. Depending on the OpenReplicator state, Solutions Enabler will block TimeFinder/Mirroroperations on Open Replicator control devices to ensure that thecontents are not changed in the middle of Open Replicator operations.Here is an example of Solutions Enabler blocking theTimeFinder/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 fordevice 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 (innondata migration situations, the Restored state without donorupdate enabled is also valid). Terminating the session will also avoidany operational conflicts, and is appropriate in this case because theBCV control device needs to have the correct data before the first OpenReplicator copy session. Here is an example of first terminating theOpen Replicator session, and then seeing the TimeFinder/Mirroroperation work without being blocked:

# symrcopy -file cold_orpairs terminate

Execute 'Terminate' operation for the 4 specified devicesin device file 'cold_orpairs' (y/[n]) ? y

'Terminate' operation execution is in progress for the device listin device file 'cold_orpairs'. Please wait...

'Terminate' operation successfully executed for the device listin device file 'cold_orpairs'.

# symmir -g cpgroup establish -full -opt

Execute 'Full Establish' operation for device group'cpgroup' (y/[n]) ? y

'Full Establish' operation execution is in progress fordevice group 'cpgroup'. Please wait...

'Full Establish' operation successfully initiated for device group 'cpgroup'.

#



5.2.3 TimeFinder/Mirror splitBefore the BCV devices can be split, the synchronization must becomplete, and the verify action using the interval option(-i) is aneasy way to wait for synchronization to complete. From thesynchronized state the split action is permitted. The split actionhas multiple options for specifying a consistent split. In this case thevxfs mountpoint specified will be frozen just before the instant split isperformed 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 usedinstead. For this example and with other cold pushes using a BCV orclone, consistency is obtained using TimeFinder rather than usingsimilar consistency options with the symrcopy activate action. Forexample:

# 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'cpgroup' (y/[n]) ? y

'Split' operation execution is in progress fordevice group 'cpgroup'. Please wait...

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 splitaction to put the Open Replicator source device in the Not Ready state asrequired for a cold push. This option was left out in this example to show howto correctly overcome its omission in ”Cold control devices must be NotReady,” on page 92.



If TimeFinder/Clone was being used, the activate can be issuedimmediately after the create without waiting, however for performancereasons, it is better to verify that the precopy cycle is completed:symclone -g cpgroup verify -precopy -cycledsymclone -g cpgroup activate -vxfs /cphome -not_ready

If TimeFinder/Snap was being used, the activate can be issuedimmediately after the create without waiting. When using a VDEV, useof the -not_ready option for this command is required, as the VDEVmust remain in the Not Ready state while the Open Replicator sessionis present:symsnap -g cpgroup activate -vxfs /cphome -not_ready



5.3 Migration step 8, symrcopy create

5.3.1 Cold control devices must be Not ReadyThe first attempt at executing the create action will fail, because theTimeFinder/Mirror split operation leaves the BCV devices in theReady state, and Open Replicator control devices in a cold session mustbe in the Not Ready state. For example, here is a create attempt andthe 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 withina file used in Section 4.6.5, “Verify all with symrcopy create,” on page79, is to use the device group created for the TimeFinder operations.The -bcv option will cause the not_ready action to only be applied tothe BCV devices associated with the device group (the productiondevices A0-A3 will not be affected). For example:

# symld -g cpgroup -bcv not_ready

Execute a 'Not Ready' Device operation for all devicesin device group 'cpgroup' (y/[n]) ? y

'Not Ready' Device operation successfully completed for the device group.#



5.3.2 Create action optionsNow that the devices are Not Ready, the repeated create action willsucceed. Here is an example of a successful create:

# symrcopy -file cold_orpairs create -push -cold -differential -name cold_push -copy



'Create' operation successfully executed for the device listin device file 'cold_orpairs'.

#The create action used in this example has a number of importantoptions set:

◆ The -file cold_orpairs option defines the control and remotedevice pairs.

◆ The -push and -cold options make this copy session a cold push.

◆ The -differential option directs Open Replicator to keep trackof changes to the control devices, providing the ability to pushincremental updates to the remote.

◆ The -name cold_push option defines a session name for all thepairs defined in the cold_orpairs file, providing an alternatemethod of specifying which pairs are addressed by the symrcopycommand.

◆ The -copy option indicates that upon activate, a backgroundsequential copy from the control to the remote will begin.



5.3.3 Open Replication query displayThe query (or verify) actions can be used to show the copy session inthe Created state. Note the use of the named session cold_push torefer to the control/remote pairs of interest. The CD value for the RIflags indicate the display of the remote device using the CLARiiON IDand device name rather than the LUN WWN. Additionally the CDSHUflag 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---------------------------- ----------------------- ----- -------------- ----

ProtectedSID:symdev Tracks Identification RI CDSHU CTL <=> REM (%)------------------ --------- -------------------- -- ----- -------------- ----000190300359:0083 65535 HK190807410004:0007 CD XXX.. Created N/A000190300359:0082 65535 HK190807410004:0006 CD XXX.. Created N/A000190300359:0081 65535 HK190807410004:0005 CD XXX.. Created N/A000190300359:0080 65535 HK190807410004:0004 CD XXX.. Created N/A

Total ---------Track(s) 262140MB(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.

#



5.3.4 Query -detail optionSpecifying the -detail option with the query action reveals thedefault setting of five (5) for the pace parameter. It will also display theModified Tracks, for incremental updates, but this value is onlycalculated if the Solutions Enabler options file parameterSYMAPI_RCOPY_GET_MODIFIED_TRACKS is set to TRUE. The defaultsetting is FALSE in order to optimize performance. The session name isalso listed in this display:

# symrcopy -session cold_push query -detail


Control Device Remote Device Flags Status Done Pace Name------------------------------------ ----------------------- ----- -------- ---- ---- ---------

Protected ModifiedSID:symdev Tracks Tracks Identification RI CDSHU CTL<=>REM (%)----------------- --------- -------- -------------------- -- ----- -------- ---- ---- ---------000190300359:0083 65535 0 HK190807410004:0007 CD XXX.. Created N/A 5 cold_push000190300359:0082 65535 0 HK190807410004:0006 CD XXX.. Created N/A 5 cold_push000190300359:0081 65535 0 HK190807410004:0005 CD XXX.. Created N/A 5 cold_push000190300359:0080 65535 0 HK190807410004:0004 CD XXX.. Created N/A 5 cold_push. . .



5.4 Migration step 10, symrcopy activateActivate sets the point-in-time for the push of data from the controlto the remote. In this case of cold push, there is no need for consistencyoptions, as these were already used as part of the TimeFinder/Mirrorsplit operation. Notice that after the activate, the Status haschanged to CopyinProg(ress) and the number of Protected Tracks for each device is reduced from the starting value of 65535 astracks are copied to the remote.

# symrcopy -session_name cold_push activate

Execute 'Activate' operation for the 4 specified deviceswith session name 'cold_push' (y/[n]) ? y

'Activate' operation execution is in progress for the device listwith session name 'cold_push'. Please wait...

'Activate' operation successfully executed for the device listwith session name 'cold_push'.

# symrcopy -session cold_push query



ProtectedSID:symdev Tracks Identification RI CDSHU CTL <=> REM (%)------------------ --------- -------------------- -- ----- -------------- ----000190300359:0083 65365 HK190807410004:0007 CD XXX.. CopyInProg 0000190300359:0082 65366 HK190807410004:0006 CD XXX.. CopyInProg 0000190300359:0081 65368 HK190807410004:0005 CD XXX.. CopyInProg 0000190300359:0080 65370 HK190807410004:0004 CD XXX.. CopyInProg 0

Total ---------Track(s) 261469MB(s) 16341.8

. . .



5.5 Migration step 12, symrcopy set ceilingAs shown earlier with the query -detail, by default the paceparameter is set to five, which significantly slows copy operations byinserting delays.

As a best practice, the ceiling value should be used which moreeffectively limits the Open Replicator use of resources shared with theproduction applications. In this case, the ceiling value is set to 30%reserving 70% of the FA bandwidth for production applications. Thepace value is ignored for all participating director/port combinationswhere the ceiling value is not NONE.

Unlike the pace parameter which is session based, the ceiling value isdirector/port based and affects all sessions that use those ports. Sinceboth ports 2C:0 and 15C:0 are used by the production devices and couldbe used by Open Replicator, the ceiling is set on both ports by executingthe 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 OpenReplicator I/O taking place (i.e., before the activate). The setting ofperformance parameters is shown at this point in the operationalsequence because it is possible that active tuning might be altered atvarious points of the migration versus setting a single value that isalways in place.

Just as the detailed query can be used to show the pace setting, there isa list ceiling operation that can be used to display the ceilingvalues, and that also shows the current Open Replicator use ofbandwidth. In the following example, only director port 2C:0 showsbandwidth use, because director port 15C:0 was not zoned and LUNmasked for this cold push.

# symrcopy -sid 359 list ceiling


Symmetrix Remote Copy Bandwidth Ceiling

Max Set ActualDir:P (MB) (%) (MB)----- ---- ---- ------01C:0 150 NONE 001C:1 150 NONE 002C:0 150 30 1402C:1 150 NONE 015C:0 150 30 015C:1 150 NONE 016C:0 150 NONE 016C:1 150 NONE 0

#



5.6 Migration step 13, symrcopy query and verifyThis step consists mostly of waiting until the Open Replicator copycompletes for the point-in-time of the activate. The query actionwill report the Status, the decreasing number of Protected Tracks, and the increasing Done percent. The normal status sequencegoes from CopyInProg to Copied. Using the verify action allowsscripts to wait for a particular status. The use of the count (-c) optionlimits how long to wait and the program can check for unsuccessfulreturn status indicating an exit from the loop due to the count beingreached 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 theexample, the Copied state was reached within the three-hour time limitfor checking. It is important to specify a realistic time limit based on theamount of data to be copied and the bandwidth or other tuninglimitations that will affect how long the copy could take to complete.

# symrcopy -session cold_push querySession Name : cold_push


ProtectedSID:symdev Tracks Identification RI CDSHU CTL <=> REM (%)------------------ --------- -------------------- -- ----- -------------- ----000190300359:0083 60460 HK190807410004:0007 CD XXX.. CopyInProg 7000190300359:0082 60466 HK190807410004:0006 CD XXX.. CopyInProg 7000190300359:0081 60480 HK190807410004:0005 CD XXX.. CopyInProg 7000190300359:0080 60483 HK190807410004:0004 CD XXX.. CopyInProg 7

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

#



5.7 Migration step 14, iterative symrcopy recreate

5.7.1 Incrementally update control devices from production devicesBecause a cold push from a BCV is based on a point-in-time that doesnot include all of the application writes to the production device, itmust be incrementally updated with the writes since the activation ofthe last cold push. This is done using a combination ofTimeFinder/Mirror commands to incrementally update the BCV andOpen Replicator commands to incrementally update the remote devices.

To avoid Solutions Enabler blocks on TimeFinder interactions withOpen Replicator, the simple rule to follow is that the Open Replicatorsession should be in the Copied state when attempting TimeFinderoperations. In “Migration step 13, symrcopy query and verify”, the laststatus verified was the Copied state. In the following example,TimeFinder/Mirror is used to incrementally establish (update) theBCV, 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 asrequired for Open Replicator cold operations.

# symmir -g cpgroup establish

Execute 'Incremental Establish' operation for device group'cpgroup' (y/[n]) ? y

'Incremental Establish' operation execution is in progress fordevice group 'cpgroup'. Please wait...

'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'cpgroup' (y/[n]) ? y'Split' operation execution is in progress fordevice group 'cpgroup'. Please wait...

Freezing 1 filesystem(s)......................................Done.

Thawing 1 filesystem(s).......................................Done.

'Split' operation successfully executed for device group 'cpgroup'.

#



If TimeFinder/Clone had been used in place of TimeFinder/Mirror, thesequence would have been to consistently establish the TGT(combine incremental recreate and activate) with an updatedpoint-in-time of the production devices using the -not_ready option.It is not required to wait until the TGTs have finished copying thepoint-in-time and reached the Copied state with the verify action.

If TimeFinder/Snap had been used in place of TimeFinder/Mirror, theTimeFinder incremental update, cannot activate the recreatedTimeFinder/Snap session before the Open Replicator session is firstrecreated. Similarly, the symrcopy activate cannot precede thesymsnap activate (which again includes the -not_ready option tokeep the VDEV in the Not Ready state). Therefore when usingTimeFinder/Snap the order of operations for iterative update must be:

1. symsnap recreate

2. symrcopy recreate

3. symsnap activate -not_ready

4. symrcopy activate

5.7.2 Incrementally update remote devices from control devicesFirst, use Open Replicator recreate to set up an incremental updateusing the Symmetrix Differential Data Facility (SDDF) informationmaintained as a result of the -differential option on the originalcreate. Second, use activate to set a new point-in-time and start themovement of data. Third, wait for completion of the incremental datamovement. The Copied state indicates finishing the incrementalupdate and is required for using TimeFinder in the next iteration ofincremental updates.

# symrcopy -session cold_push recreate

Execute 'Recreate' operation for the 4 specified deviceswith session name 'cold_push' (y/[n]) ? y

'Recreate' operation execution is in progress for the device listwith session name 'cold_push'. Please wait...

'Recreate' operation successfully executed for the device listwith session name 'cold_push'.

# symrcopy -session cold_push activate

Execute 'Activate' operation for the 4 specified deviceswith session name 'cold_push' (y/[n]) ? y







#

5.7.3 Stop applications and final incremental updateIn order to end the iterative loop of incremental updates, it is necessaryto stop production applications from writing to the production devices.The file system is displayed here as a simplistic method for comparingwith the migrated copy in Section 5.8, “Migration step 15, verifymigration and symrcopy terminate,” on page 104. In this example, thechange directory (cd) away from the mounted filesystem emulatesstopping the application, and is required before the filesystem can beunmounted. Once the filesystem is unmounted, the volume group canbe deported from VxVM, and the disks can be removed from VxVM.

# cd /cphome# ls -ltotal 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_orpairsdrwxr-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# vxdisk rm emcpower381s2# vxdisk rm emcpower382s2# vxdisk rm emcpower383s2#



The last incremental synchronization is repeated almost identically asin Section 5.7.1, “Incrementally update control devices from productiondevices,” on page 100 and Section 5.7.2, “Incrementally update remotedevices from control devices,” on page 101. The count value on theverify checks is lower since there is less data to update. TheTimeFinder/Mirror split operation cannot freeze the file system sinceit is now unknown (and effectively frozen) due to the umount anddeport operations performed earlier.In the following example, the -noprompt option is used to skip thecontrol action verification queries. Since there are no new writes, aftercompletion of this last incremental update the Open Replicator remotedevices are fully synchronized with the production devices.

# symmir -g cpgroup establish -noprompt

'Incremental Establish' operation execution is in progress fordevice group 'cpgroup'. Please wait...

'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 execution is in progress fordevice group 'cpgroup'. Please wait...

'Split' operation successfully executed for device group 'cpgroup'.

# symrcopy -session cold_push recreate -noprompt

'Recreate' operation execution is in progress for the device listwith session name 'cold_push'. Please wait...

'Recreate' operation successfully executed for the device listwith session name 'cold_push'.

# symrcopy -session cold_push activate -noprompt





#



5.8 Migration step 15, verify migration and symrcopy terminateBefore terminating the Open Replication copy sessions (and losing alldifferential information), it is best to conduct some type of applicationspecific verification that the remote devices are a complete and validreplacement for the original production devices. This will be shown as acomparison with the list directory of the production devices later inSection 5.11, “Cleanup step 18, restart applications using targets,” onpage 108. In a true production data migration, best practice wouldinclude bringing the application up in a test mode using the migrateddata to verify that the application will work without fail. The depth andbreadth of this type of verification will vary depending on the businessrequirements for each data migration. Once verified, the OpenReplicator sessions are no longer needed and can be terminated asfollows:

# symrcopy -session cold_push terminate

Execute 'Terminate' operation for the 4 specified deviceswith session name 'cold_push' (y/[n]) ? y

'Terminate' operation execution is in progress for the device listwith session name 'cold_push'. Please wait...

'Terminate' operation successfully executed for the device listwith session name 'cold_push'.

# symrcopy -session cold_push queryNo sessions were found with name: cold_push

#

Note: When using TimeFinder/Snap, the symrcopy terminate commandmust precede any symsnap terminate commands.

5.8.1 Hot push differences from cold pushThis TechBook does not include an entire example of hot push, becausethe operations are very similar to those just shown for cold push. Thereis a difference in the required setup, because hot operations require allcapable ports to be zoned and LUN masked. This difference will becovered in detail in Chapter 6, “Hot Pull from CLARiiON MigrationExample.” A partial hot push example is included in Section B.4,“Reactivate Failed Session,” on page 244.



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; theactivate takes a point-in-time on the actual production devices,using Copy on First Write (COFW) to handle production write I/Os todata not yet copied to the remote devices. Second the control devices canbe in the Ready state since COFW is in effect.

Operationally, this means there is no need for the TimeFinderoperations or the not_ready device control operations. The OpenReplicator activate action will likely use the -consistent option toensure a consistent point-in-time, since this is no longer done separatelyusing TimeFinder/Mirror or TimeFinder/Clone. Additionally, thecreate and recreate actions will often use the -precopy option tominimize the COFW performance penalty on the production devices. Inorder to get the most benefit from precopy, best practice would includea time delay between the create/recreate and activate actions.The command symrcopy verify -precopy -cycled can be usedto wait for the completion of one sequential pass through all blocks ofthe production devices before activating the session.



5.9 Cleanup step 16, make source devices host inaccessibleBy definition, these cleanup steps occur after all Open Replicator stepsare complete. These host and application specific examples are includedbriefly here in order to contrast these manual steps with morefunctional actions that are included as part of PowerPath MigrationEnabler (PPME) (which is discussed in Chapter 9, “PPME with OpenReplicator Migration Example”).

Although the original source devices were made unavailable to the hostin Section 5.7.3, “Stop applications and final incremental update,” onpage 102, this change was not permanent and it is possible that upon areboot these devices may be accessed again. If the source device mountdefinitions are not removed from /etc/vfstab, upon reboot thesource devices would automatically be remounted. If an unplanneddisk rescan or reboot takes place without making these devicesinaccessible, then it is possible that the host may mistakenly use thesedevices again in place of the migrated target devices upon recognizingthe private region information on the disks. Best practice would avoidthis problem and also preserve the production volumes unchangeduntil it was certain that there was no need to revert to the data stored onthe original source devices. The following steps can be used to unmaskthe source devices from the host to ensure that the host will notinadvertently 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:000A1 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 parameters

#



5.10 Cleanup step 17, make target devices ready to hostThe target devices are presented to the host in this case, simply byremoving the remote CLARiiON devices from the OR_Symm359 storagegroup and adding the devices to the existing D229 storage group for thelocal Solaris host. In other cases it might be necessary to add newzoning or create a new storage group or use other array specific LUNmasking techniques. For example:

# ./navicli -h Clar0031_SPA storagegroup -removehlu -gname OR_Symm359 -hlu 00 -o# ./navicli -h Clar0031_SPA storagegroup -removehlu -gname OR_Symm359 -hlu 01 -o# ./navicli -h Clar0031_SPA storagegroup -removehlu -gname OR_Symm359 -hlu 02 -o# ./navicli -h Clar0031_SPA storagegroup -removehlu -gname OR_Symm359 -hlu 03 -o# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname D229 -alu 04 -hlu 01# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname D229 -alu 05 -hlu 02# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname D229 -alu 06 -hlu 03# ./navicli -h Clar0031_SPA storagegroup -addhlu -gname D229 -alu 07 -hlu 04

The SYMAPI database is updated by rediscovering the CLARiiON andthe list of CLARiiON devices now shows host pathnames for devices4-7.

# symcfg discover -clariion

This operation may take up to a few minutes. Please be patient...# symdev list -clariion


Device Device----- ----------------------- ----------------------------------------------Num Physical Name Config Cap(MB) WWN----- ----------------------- ----------------------------------------------

00000 Not Visible RAID-5 4096 600601602B401E00148F6936D93BDD1100001 Not Visible RAID-5 4096 600601602B401E00158F6936D93BDD1100002 Not Visible RAID-5 4096 600601602B401E00168F6936D93BDD1100003 Not Visible RAID-5 4096 600601602B401E00178F6936D93BDD1100004 /dev/rdsk/emcpower2c RAID-5 4096 600601602B401E00188F6936D93BDD1100005 /dev/rdsk/emcpower1c RAID-5 4096 600601602B401E00198F6936D93BDD1100006 /dev/rdsk/emcpower0c RAID-5 4096 600601602B401E001A8F6936D93BDD1100007 /dev/rdsk/emcpower4c RAID-5 4096 600601602B401E001B8F6936D93BDD1100008 Not Visible RAID-5 4096 600601602B401E00BAE08E938A47DD1100009 /dev/rdsk/emcpower3c RAID-5 4096 600601602B401E001078C2A48A47DD11

#



5.11 Cleanup step 18, restart applications using targetsThe migrated information on the target devices includes the VxVMprivate region with the disk group information which can be imported.

# vxdctl enable# vxdisk listDEVICE TYPE DISK GROUP STATUSc0t0d0s2 auto:none - - online invalidc0t1d0s2 auto:none - - online invalidemcpower0s2 auto:cdsdisk - - onlineemcpower1s2 auto:cdsdisk - - onlineemcpower2s2 auto:cdsdisk - - onlineemcpower3s2 auto:cdsdisk - - onlineemcpower4s2 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 deviceson the Symmetrix V-Max (or Symmetrix DMX) were both configured as4 GB devices, the actual size of the devices differs slightly with theCLARiiON devices being slightly larger. To get the host operatingsystem to recognize and use the additional space, it is necessary toexecute operating system and application specific steps.

On Solaris hosts, a logical unit’s disk label contains information aboutthe vendor, product, geometry, and slices. PowerPath MigrationEnabler (PPME) includes a utility called powerformat that can beused independent of PPME to safely update disk-label information,preserve partition definitions and data, and make newly available diskcapacity available for use.



For this example, vxdisk resize is used as the first step to get the OSand LVM to recognize the new space on the LUNs. The before and afteroutput from vxprint shows the change in PUBLEN from 8382336 to8385792 blocks for an increase of 3456 blocks for each disk media (DM)record:

# df -kFilesystem kbytes used avail capacity Mounted on. . ./dev/vx/dsk/cpvg/cplv

16764672 21198 15697013 1% /cphome# vxprint -g cpvg -htDG NAME NCONFIG NLOG MINORS GROUP-IDST NAME STATE DM_CNT SPARE_CNT APPVOL_CNTDM NAME DEVICE TYPE PRIVLEN PUBLEN STATERV NAME RLINK_CNT KSTATE STATE PRIMARY DATAVOLS SRLRL NAME RVG KSTATE STATE REM_HOST REM_DG REM_RLNKCO NAME CACHEVOL KSTATE STATEVT NAME NVOLUME KSTATE STATEV NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL PREFPLEX UTYPEPL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODESD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODESV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODESC NAME PLEX CACHE DISKOFFS LENGTH [COL/]OFF DEVICE MODEDC NAME PARENTVOL LOGVOLSP NAME SNAPVOL DCO


dm cpvgd0 emcpower2s2 auto 2048 8382336 -dm cpvgd1 emcpower1s2 auto 2048 8382336 -dm cpvgd2 emcpower0s2 auto 2048 8382336 -dm cpvgd3 emcpower4s2 auto 2048 8382336 -v cplv - ENABLED ACTIVE 33529344 SELECT - fsgenpl cplv-01 cplv ENABLED ACTIVE 33529344 CONCAT - RWsd cpvgd0-01 cplv-01 cpvgd0 0 8382336 0 emcpower2 ENAsd cpvgd1-01 cplv-01 cpvgd1 0 8382336 8382336 emcpower1 ENAsd cpvgd2-01 cplv-01 cpvgd2 0 8382336 16764672 emcpower0 ENAsd cpvgd3-01 cplv-01 cpvgd3 0 8382336 25147008 emcpower4 ENA# vxdisk -g cpvg resize emcpower2s2# vxdisk -g cpvg resize emcpower1s2# vxdisk -g cpvg resize emcpower0s2# vxdisk -g cpvg resize emcpower4s2# vxprint -htqDisk group: cpvg


dm cpvgd0 emcpower2s2 auto 2048 8385792 -dm cpvgd1 emcpower1s2 auto 2048 8385792 -dm cpvgd2 emcpower0s2 auto 2048 8385792 -dm cpvgd3 emcpower4s2 auto 2048 8385792 -

v cplv - ENABLED ACTIVE 33529344 SELECT - fsgenpl cplv-01 cplv ENABLED ACTIVE 33529344 CONCAT - RWsd cpvgd0-01 cplv-01 cpvgd0 0 8382336 0 emcpower2 ENA. . .



Next the vxresize command is used to expand the volume and filesystem. The expansion size specified is +13824 (4 x 3456) blocks. Thevxprint output shows the cplv logical volume length increasing by13824 blocks from 33529344 to 33543168. Similarly, the filesystemcapacity in kbytes changed from 16764672 to 16771584, an increase of6912 kbytes which matches the expected change in blocks (13824 blocks÷ 2 blocks/kbyte = 6912 kbytes). For more information on handlingLUN expansion for UNIX systems, reference the EMC Symmetrix LUNExpansion and UNIX Logical Volume Managers Technical Note available onPowerlink.

# df -kFilesystem kbytes used avail capacity Mounted on. . ./dev/vx/dsk/cpvg/cplv

16764672 21198 15697013 1% /cphome# /etc/vx/bin/vxresize -g cpvg -F vxfs cplv +13824# vxprint -g cpvg -htqdg cpvg default default 33000 1214852481.33.licod229

dm cpvgd0 emcpower2s2 auto 2048 8385792 -. . .v cplv - ENABLED ACTIVE 33543168 SELECT - fsgenpl cplv-01 cplv ENABLED ACTIVE 33543168 CONCAT - RWsd cpvgd0-01 cplv-01 cpvgd0 0 8382336 0 emcpower2 ENAsd cpvgd1-01 cplv-01 cpvgd1 0 8382336 8382336 emcpower1 ENAsd cpvgd2-01 cplv-01 cpvgd2 0 8382336 16764672 emcpower0 ENAsd cpvgd3-01 cplv-01 cpvgd3 0 8385792 25147008 emcpower4 ENAsd cpvgd2-02 cplv-01 cpvgd2 8382336 3456 33532800 emcpower0 ENAsd cpvgd1-02 cplv-01 cpvgd1 8382336 3456 33536256 emcpower1 ENAsd cpvgd0-02 cplv-01 cpvgd0 8382336 3456 33539712 emcpower2 ENA# df -kFilesystem kbytes used avail capacity Mounted on. . ./dev/vx/dsk/cpvg/cplv

16771584 21198 15703493 1% /cphome#

5.12 Cleanup step 19, redeploy the source devices’ storageExactly how the storage that was used for the original source devices isredeployed is unique to each situation, so it would not be meaningful totry to depict a best practice here. In some cases of data migration, theold storage is literally removed from the site and is not made availablefor any actual redeployment. In the example used in this chapter, it islikely that the devices would either be reused as already configured fordifferent data, or be deleted and reconfigured for different data.


Hot Pull from CLARiiONMigration Example

6

This chapter details a hot pull Open Replicator example that differsfrom the previous cold push example in the set of steps needed tocomplete the migration. This chapter also highlights a troubleshootingexample that demonstrates an initial failure to successfully completesetup step 6. The topics covered include:

◆ 6.1 Introduction ................................................................................... 112◆ 6.2 Setup step 1, identify target devices........................................... 115◆ 6.3 Setup step 2, configure migration SAN zone............................ 116◆ 6.4 Setup step 3, configure migration LUN masking..................... 118◆ 6.5 Setup step 4, configure target zoning and LUN masking....... 119◆ 6.6 Setup step 5, Prepare Open Replicator session pairs file ........ 121◆ 6.7 Setup step 6, verify completion of setup steps ......................... 124◆ 6.8 Migration step 9, Stop the applications ..................................... 129◆ 6.9 Migration step 10, symrcopy activate ........................................ 131◆ 6.10 Migration step 11, Restart applications using targets............ 132◆ 6.11 Migration step 13, symrcopy query and verify ...................... 137◆ 6.12 Migration step 15, verify migration and terminate................ 138◆ 6.13 Cleanup step 19, redeploy the source devices ........................ 138

Hot Pull from CLARiiON Migration Example 111

Hot Pull from CLARiiON Migration Example

6.1 IntroductionThis chapter details a hot pull migration example using SolutionsEnabler SYMCLI on a Windows host. The full range of migration stepswill be reviewed and steps that are different than those detailed inChapter 4, “Cold Push to CLARiiON Setup Example” and Chapter 5,“Cold Push to CLARiiON Migration Example” will be highlighted.

6.1.1 Hot pull setup stepsSince this is a hot operation, the zoning and LUN maskingrequirements are stricter than for cold operations, requiring allSymmetrix FA ports that are mapped by the control devices to be zonedand LUN masked to "see" the remote devices. In order to demonstratetroubleshooting in an example, the setup steps 2 and 3 will deliberatelymiss meeting this requirement. Additionally, because this is a hot pullmigration some of the actions completed in the previous example ascleanup phase steps, instead are completed here during the setup phasein step 4. The six hot pull setup steps are:


2. Configure/connect migration SAN zone between remote devicesand Symmetrix V-Max (or Symmetrix DMX) control FA “host”ports.

3. Configure LUN masking for remote devices to allow access fromSymmetrix V-Max (or Symmetrix DMX) control FA “host” ports.

4. Configure host zoning and device (LUN) masking for targetdevices.

5. Prepare Open Replicator session pairs file.


6.1.2 Hot pull migration stepsThis chapter will provide details of an example of the six migrationsteps applicable for a hot pull. In this example, step 8 which invokes acreate in the migration phase is not necessary. The create isexecuted at the end of the setup phase, and this time there is noTimeFinder operation which in Section 5.2.2, “InitialTimeFinder/Mirror establish,” on page 89 required exiting theCreated state through a terminate action. Step 9 needed for all pullmigrations is now included, and step 11 for hot pull migrations isincluded as well. Tuning is applicable for all migrations including hot



pull, and already completed earlier in Section 5.5, “Migration step 12,symrcopy set ceiling,” on page 97. It is not necessary to repeat thisaction in this example, because the ceiling setting applies to all sessionswhich use the same FA director ports. Step 14 is omitted becauseiteratively applying incremental updates is not applicable for pulloperations. The hot pull migration steps are:

9. Stop the production application.


11. Restart the application pointing to the target (control) devices.



6.1.3 Hot pull cleanup stepIn the case of hot pull, applications are redirected to access the datafrom the target devices before the data movement is complete.Therefore, the first three cleanup steps are actually completed in thesetup 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 114 illustrates the hot pull setup, migration, andcleanup steps in a flowchart. The nonapplicable step 14, iterativeincremental update for push sessions, and the three nonapplicablecleanup steps (steps 16-18) are omitted from the flowchart entirely toavoid unnecessary complexity.



Data114

Figure 18 Hot pull setup, migration, and cleanup flowchartICO-IMG-000541a





15. Verify migration terminate OR


Hot pull?

Need tuning?


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







N



or VDEV?

Y

Migration: Open Replicator and PowerPath Migration Enabler Version 1.2


6.2 Setup step 1, identify target devicesFor this pull example, the target devices are the controldevices on the Symmetrix DMX 000190300359 array. Theremote source devices are 2 GB in size and the target devicesare 4 GB in size. The symdev command with the -rangeoption can be used to display the control devices 91:94also revealing the Physical Device Names:

c:\>symdev -sid 359 list -range 91:94


Device Name Directors Device--------------------------- ------------ ------------------------------------

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

0091 \\.\PHYSICALDRIVE6 15C:0 15B:D6 2-Way Mir N/Grp'd RW 40960092 \\.\PHYSICALDRIVE7 15C:0 01A:CC 2-Way Mir N/Grp'd RW 40960093 \\.\PHYSICALDRIVE8 02C:0 02B:D7 2-Way Mir N/Grp'd RW 40960094 \\.\PHYSICALDRIVE9 02C:0 01A:DD 2-Way Mir N/Grp'd RW 4096

c:\>



6.3 Setup step 2, configure migration SAN zoneThis example will use the same Symmetrix and CLARiiON arrays asused in Chapter 4, “Cold Push to CLARiiON Setup Example.”Therefore the zone for the DMX FA port that acts as an open systemshost to the remote storage array is already set up. A quick check will bemade to confirm that the correct zoning and LUN masking has been setup for the devices to be used in this example.

6.3.1 Determining control director WWNsThe Solutions Enabler symdev list -multiport command is used todetermine on which directors the control devices are visible. For thisexample, all four control devices, 91-94, are mapped to both director 2Cport 0 and director 15C port 0. These are the same FA director ports thatwere eligible to be configured in the Open Replicator SAN zones inSection 4.3.1, “Determining Control Director WWN,” on page 68.

c:\>symdev -sid 359 list -range 91:94 -multiport


M U L T I - P O R T D E V I C E S

Device Name Directors Device--------------------------- ------------- -----------------------------------

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

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

c:\>



6.3.2 Determining remote storage array WWNsThe remote storage array is again CLARiiON HK190807410004.Figure 19 illustrates checking the connectivity status for Storage GroupD194 and reveals the same A-0, A2, B-0, B-2 Storage Processorconnections as those seen in Section 4.3.2, “Determining RemoteStorage Array WWN(s),” on page 69

Figure 19 Host connectivity status for licod194 in Storage Group D194

6.3.3 Reuse existing migration SAN zonesSince the same Symmetrix DMX FA and CLARiiON SPA ports arerelevant to this example and were put in place for the example inchapters 4-5, it appears that the zones already defined can be usedwithout change. However, the example in this chapter is for a hotoperation which requires all paths to be configured so each director canhandle protected track copy needs for itself. For hot pull operations,protected tracks that have not already been copied by the backgroundcopy are copied immediately as part of Copy on First Access (COFA).For hot push operations the protected track copy is Copy on First Write(COFW). The single active path zoning already defined for director 2Cport 0 alone is insufficient because director 15C port 0 is not included inany migration zone. For purposes of displaying typical error messageswhen required zoning is missing, this example will proceed withoutadding the missing zones at this time.

ICO-IMG-000542



6.4 Setup step 3, configure migration LUN masking

6.4.1 Create CLARiiON Storage GroupBecause the same DMX FA “hosts” are connected to the same remoteCLARiiON storage array, storage group OR_Symm359 defined inSection 4.4.1, “Create CLARiiON storage group,” on page 73 can bereused. However, like the zoning above, for a hot operation, all pathsmust be LUN masked and the single FA DMX port “host” in the storagegroup (corresponding to DMX FA 2C port 0, but not 15C port 0) willprove to be insufficient. For purposes of displaying typical errormessages when necessary LUN masking is missing, this example willproceed without completing all LUN masking requirements at thistime. The four remote source devices for this pull example are added tothe storage group in the example below:

c:\>navicli -h Clar0031_SPA storagegroup -addhlu -gname OR_Symm359 -alu 0 -hlu 0




c:\>



6.5 Setup step 4, configure target zoning and LUN maskingUnlike the example for setting up a cold push in Chapter 4, “Cold Pushto CLARiiON Setup Example,” the current example is a hot pull whichmoves up the step of zoning and masking the target devices fromoccurring in the cleanup phase to the setup phase, since the applicationwill be accessing the target devices from the start.

Target devices 91-94 are already correctly mapped and device maskedas shown below by the presence of a physical path displayed when thesympd list command is executed:

c:\>sympd -sid 359 list


Device Name Directors Device------------------------ ------------- --------------------------------

CapPhysical Sym SA :P DA :IT Config Attribute Sts (MB)------------------------ ------------- --------------------------------. . .\\.\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:\>



For example, a command file named map.txt that could be used forthe 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 devicemasking commands could be done by executing a command sequencelike 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 000190300359Performing Access checks...............................Allowed.Checking Device Reservations...........................Allowed.Submitting configuration changes.......................SubmittedLocking 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:010000000c971196e 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 000190300359

c:\>



6.6 Setup step 5, Prepare Open Replicator session pairs fileThe “application” for this example uses Windows drive letters L, M, Nand O which reside on the initial CLARiiON source devices. Figure 20illustrates the contents of drive L as seen with the Windows Explorer.

Figure 20 Windows drive L contents

ICO-IMG-000543



Using Disk Management, it can be seen in Figure 21 that drives L, M, Nand 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 databasefile, the CLARiiON device numbers (0-3) related to physical drives 1-4can be determined using the symdev list command with the-clariion option. For example:

c:\>symdev list -clariion


Device Device---- --------------------- -------------------------------------------------Num Physical Name Config Cap(MB) WWN---- --------------------- -------------------------------------------------

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 pairfile defining the control-remote pairs could be:

c:\>type hot_pull_orpairs.txtsymdev=000190300359:0091 clardev=HK190807410004:0symdev=000190300359:0092 clardev=HK190807410004:1symdev=000190300359:0093 clardev=HK190807410004:2symdev=000190300359:0094 clardev=HK190807410004:3c:\>




6.7.1 Discover missing zoning with symrcopy createUsing the hot_pull_orpairs file, an attempt to create the hot pullOpen Replicator session will reveal any problems with the requiredsetup:

c:\>symrcopy -file hot_pull_orpairs.txt -pull -hot create

Execute 'Create' operation for the 4 specified devicesin device file 'hot_pull_orpairs.txt' (y/[n]) ? y

'Create' operation execution is in progress for the device listin 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 createaction with the verbose option -v specified, providing similarinformation as can be obtained by examining the contents of theSYMAPI log file. In the example shown below, the first reported statusSANCOPY_DEV_SUCCESS indicates that for control device 91, director2C could see the remote device. However, the second reported statusSANCOPY_DEV_NO_REMOTE_TARGETS indicates that for the samecontrol device 91, director 15C could not see any remote devices. Thisindicates 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: 600601602B401E000CDB4E44EA4DDD11 - [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.

(Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4DDD11 - [loc_dir:02C, rem_num:0, rem_sts:0x1SANCOPY_DEV_SUCCESS ](Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4D

DD11 - [loc_dir:15C, rem_num:0, rem_sts:0xaSANCOPY_DEV_NO_REMOTE_TARGETS ](Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4D

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 missingzoning definition:

c:\>symsan list -sanports -sid 359 -dir 15c -port 0


No results found.

c:\>



6.7.2 Example configuration of additional migration SAN zoneFor the hot pull, it is necessary to define a zone for all directors mappedto the control device. However, only a path for FA 2C port 0 was zonedin Section 4.3.4, “Example configuration of migration SAN zones,” onpage 72. Now, a second active path is defined for FA 15C port 0including the standby path to accommodate trespassing in theCLARiiON. The original zone defined a path from Symmetrix 2C0 toCLARiiON SPB0 (and standby path to SPA0). The new zone defines apath from Symmetrix 15C0 to CLARiiON SPB2 (and standby path toSPA2). The definition of two independent active zones instead of onezone with all paths results in better performance due to the way OpenReplicator manages alternate paths. Figure 22 shows an excerpt of theConnectrix Manager Zoning verification screen with the additionalpath and standby path zoning defined.

Figure 22 Activate additional zones verification screen excerpt

6.7.3 Discover missing LUN masking with symrcopy createIn the example below, a repeat of the attempt to create the hot pullOpen Replicator session will produce a different error since zoning is inplace but LUN masking is still missing. The second status reported forcontrol device 91, the entry for director 15C now reportsSANCOPY_DEV_WWID_NOT_FOUND indicating that the remote deviceWWN could not be found. Since the WWN came from the SYMAPIdatabase, the cause is not a WWN entry error, but that the correct WWNcannot be seen. This is most likely the result of missing LUN masking.

c:\>symrcopy -file hot_pull_orpairs.txt -pull -hot create -v

Execute 'Create' operation for the 4 specified devicesin device file 'hot_pull_orpairs.txt' (y/[n]) ? y'Create' operation execution is in progress for the device list

ICO-IMG-000545



in device file 'hot_pull_orpairs.txt'. Please wait...STARTING a REMOTE Copy CREATE (PULL) (HOT)

SELECTING Control device - Remote devices:

(Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4DDD11 - [SELECTED]. . .STARTING a RCOPY 'CREATE' operation.

(Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4DDD11 - [loc_dir:02C, rem_num:0, rem_sts:0x1SANCOPY_DEV_SUCCESS ](Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4D

DD11 - [loc_dir:15C, rem_num:0, rem_sts:0x6SANCOPY_DEV_WWID_NOT_FOUND ](Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4D

DD11 - [SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR]





c:\>The symsan list -sanports command confirms that zoning is inplace, but when the -sanluns option is used with the symsan listcommand, there are no complete LUN records. For example:

c:\>symsan list -sanports -sid 359 -dir 15c -port 0


Flags NumDIR:P I Vendor Array LUNs Remote Port WWN----- ----- ------------- ---------------- ---- --------------------------------

15C:0 . EMC CLARiiON HK190807410004 1 5006016A41E087E6

15C:0 . EMC CLARiiON HK190807410004 1 5006016241E087E6


c:\>symsan list -sanluns -wwn 5006016241E087E6 -sid 359 -dir 15c -port 0

Symmetrix ID: 000190300359Remote Port WWN: 5006016241E087E6

STAT 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


(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:\>



6.7.4 Example LUN masking for all Symmetrix V-Max (or Symmetrix DMX) FAcontrol directors

Defining zoning is not the only thing required to provide access. In thisexample, FA 15C port 0 also needs to be properly LUN masked beforethe remote devices can be seen. For the remote CLARiiON array in thisexample, this can be accomplished by adding the FA 15C port 0 host tothe OR_symm359 storage group. Symmetrix FA “host” 15C is manuallyregistered 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:D5:F0:31:CE:50:06:04:8A:D5:F0:31:CE -sp b -spport 2 -host Sym0359 -failovermode 1 -o -unitserialnumber array

c:\>navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A:D5:F0:31:CE:50:06:04:8A:D5:F0:31:CE -sp a -spport 2 -host Sym0359 -failovermode 1 -o -unitserialnumber array

c:\>

6.7.5 Successful create verifies hot pull setupNow that the correct zoning and LUN masking is in place, the OpenReplicator create succeeds without error in the following example.Although the Open Replicator sessions are now setup, data movementhas not yet begun. The best practice for hot pull migrations is to alwaysinclude the -donor_update option if production applications will bewriting to the target devices. This is necessary to protect againstpotential data loss due to a SAN failure or other connectivity issuesduring a hot pull operation:

c:\>symrcopy -file hot_pull_orpairs.txt create -pull -hot -donor_update -namehot_pull -copy



'Create' operation successfully executed for the device listin device file 'hot_pull_orpairs.txt'.

c:\>



6.8 Migration step 9, Stop the applicationsSince this example is a pull migration, it is necessary to stop anyproduction applications that are using the remote source devices (drivesL-O), in order to fix a point-in-time for the remote array devices. This isdone at an appropriate time when a short interruption in running theproduction applications can be tolerated.

The Symmetrix Integration Utilities (SIU, available with SolutionsEnabler) integrates and extends the Windows 2003 and Windows 2008disk management functionality to better operate with EMC Symmetrixbusiness continuance storage devices. Data migration using OpenReplicator can also take advantage of this functionality with supportspecifically 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 availableto the system

The SIU includes the symntctl command to execute the neededfunctionality. Once the production applications are stopped, the remotesource volumes will no longer be used and are unmounted. The symntctl umount command:

• Obtains an exclusive lock on that volume from the operatingsystem, which will fail if another application is still using thedrive

• Performs a file system flush as part of the dismount process

• Flags the drive as “permanently dismounted” (offline) until asubsequent mount operation. This ensures that no otherapplications can access the volume while it is being unmounted,thus ensuring data integrity during migration operations.



For example, the following symntctl commands can be used tounmount 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 notbecome visible on a subsequent rescan or reboot, the LUN masking foreach volume needs to be removed. This is done by issuing a set ofcommands that look like this:

c:\>navicli -h Clar0031_SPA storagegroup -removehlu -gname D194 -hlu 00 -o




c:\>



6.9 Migration step 10, symrcopy activateThe activate action sets the point-in-time for the pull of data from theremote to the control. In this hot pull example, there is no need forconsistency options, as the applications were stopped and the diskcache was flushed thereby ensuring consistency. Notice that after theactivate, the Status changes to CopyinProg(ress) and theProtected Tracks counts decrease as tracks are copied to the control.

c:\>symrcopy -session_name hot_pull activate

Execute 'Activate' operation for the 4 specified deviceswith session name 'hot_pull' (y/[n]) ? y

'Activate' operation execution is in progress for the device listwith session name 'hot_pull'. Please wait...

'Activate' operation successfully executed for the device listwith session name 'hot_pull'.

c:\>symrcopy -session_name hot_pull query

Session Name : hot_pull

Control Device Remote Device Flags Status Done---------------------------- ------------------------- ----- -------------- ----

ProtectedSID:symdev Tracks Identification RI CDSHU CTL <=> REM (%)------------------ --------- ---------------------- -- ----- -------------- ----000190300359:0094 32757 HK190807410004:00003 CD X..XX CopyInProg 0000190300359:0093 32760 HK190807410004:00002 CD X..XX CopyInProg 0000190300359:0092 32760 HK190807410004:00001 CD X..XX CopyInProg 0000190300359:0091 32755 HK190807410004:00000 CD X..XX CopyInProg 0

Total ---------Track(s) 131032MB(s) 8189.5









c:\>



6.10 Migration step 11, Restart applications using targetsNow that the data copying has begun, production applications can berestarted immediately without waiting for the copy to complete. If anattempt is made to access data not yet copied, then it will be copied(COFA) immediately. Copying all of the data from the source devices tothe targets includes copying information about the 2 GB original size ofthe source devices. The symntctl update command can be used toupdate the partition information to include the additional space thatactually 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 inDisk Management that shows the 2.01 GB of additional unallocatedspace for each disk. Since the disks have not yet been mounted, all ofthe 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 targetdevices using the same drive letters as the source devices had used, soproduction applications that use the filesystems will now access thedata on the target devices.

c:\>symcfg discover -all

This operation may take up to a few minutes. Please be patient...

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 usethe unallocated space, so that all 4 GB of space can be used byapplications. For example:

c:\>diskpart

Microsoft DiskPart version 5.2.3790.3959Copyright (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 Managementshowing the extended 4 GB partitions (no longer the original 2 GB).

Figure 24 Disk Management updated display showing 4 GB partitions

ICO-IMG-000547



6.11 Migration step 13, symrcopy query and verifyThis step consists mostly of waiting until the Open Replicator copycompletes copying all of the tracks from the remote devices to the controldevices. Once this is done, the original source devices are no longerneeded. The query action will report the Status and the decreasingnumber 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


ProtectedSID:symdev Tracks Identification RI CDSHU CTL <=> REM (%)------------------ --------- -------------------- -- ----- -------------- ----000190300359:0094 32416 HK190807410004:00003 CD X..XX CopyInProg 1000190300359:0093 32403 HK190807410004:00002 CD X..XX CopyInProg 1000190300359:0092 32427 HK190807410004:00001 CD X..XX CopyInProg 1000190300359:0091 32413 HK190807410004:00000 CD X..XX CopyInProg 1

Total ---------Track(s) 129659MB(s) 8103.7









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:\>



6.12 Migration step 15, verify migration and terminateBecause this is a hot pull, production applications are already using thetarget devices, in effect verifying the validity of the copied data.However, if any application specific verification of the migration isdesired, it must be completed before terminating the Open Replicationcopy sessions along with the donor update feature that keeps theoriginal source updated with all changes since the productionapplications began using the targets. Once the validation is complete,the Open Replicator sessions are no longer needed and can beterminated by executing a set of commands that look something like thefollowing:

c:\>symrcopy -session hot_pull terminate

Execute 'Terminate' operation for the 4 specified deviceswith session name 'hot_pull' (y/[n]) ? y

'Terminate' operation execution is in progress for the device listwith session name 'hot_pull'. Please wait...

The specified action is not allowed without the force flag because the control device hasa 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 deviceswith session name 'hot_pull' (y/[n]) ? y

'Set Donor Update Off' operation execution is in progress for the device list with sessionname 'hot_pull'. Please wait...

'Set Donor Update Off' operation successfully executed for the device list with sessionname 'hot_pull'.

c:\>symrcopy -session hot_pull terminate

Execute 'Terminate' operation for the 4 specified deviceswith session name 'hot_pull' (y/[n]) ? y

'Terminate' operation execution is in progress for the device listwith session name 'hot_pull'. Please wait...

'Terminate' operation successfully executed for the device listwith session name 'hot_pull'.

c:\>

6.13 Cleanup step 19, redeploy the source devicesBecause this example is a hot pull, the key cleanup steps of redirectingproduction applications to access the target devices in place of thesource devices were completed in Section 6.10, “Migration step 11,Restart applications using targets,” on page 132. Step 19, redeploy thesource devices’ storage, is the only step remaining in the cleanup phase.


Hot Pull from SymmetrixMigration Example

7

This chapter details using Symmetrix Management Console (SMC) asthe management tool to manage an Open Replicator hot pull. Asanother hot pull example, the required steps match the example inChapter 6, “Hot Pull from CLARiiON Migration Example,” with thesmall difference being that the remote storage array is a Symmetrix.The topics covered include:

◆ 7.1 Introduction .................................................................................... 140◆ 7.2 Setup step 1, identify target devices............................................ 143◆ 7.3 Setup step 2, configure migration SAN zone............................. 144◆ 7.4 Setup step 3, configure migration device masking ................... 149◆ 7.5 Setup step 4, configure target zoning and LUN masking........ 165◆ 7.6 Setup step 5, prepare Open Replicator session pairs file ......... 166◆ 7.7 Setup step 6, verify completion of setup steps .......................... 170◆ 7.8 Migration step 9, stop the applications....................................... 174◆ 7.9 Migration step 10, Open Replicator activate.............................. 177◆ 7.10 Migration step 11, restart applications using targets.............. 179◆ 7.11 Migration step 12, tune migration ............................................ 181◆ 7.12 Migration step 13, check status, wait until copied.................. 183◆ 7.13 Migration step 15, verify migration and terminate................. 184◆ 7.14 Cleanup step 19, redeploy the source devices ......................... 186

Hot Pull from Symmetrix Migration Example 139

Hot Pull from Symmetrix Migration Example

7.1 IntroductionThis chapter details a hot pull migration example using SymmetrixManagement Console (SMC) on a Windows host. This example is verysimilar to the hot pull example in Chapter 6, “Hot Pull from CLARiiONMigration Example,” requiring the same steps to be completed. Thisexample 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.

7.1.1 Hot pull setup stepsSince this is a hot operation, all Symmetrix FA ports that are mapped bythe control devices must be zoned and LUN masked to "see" the remotedevices. In this example all zoning and masking requirements will bemet in the setup steps, including using SMC Remote Report to verifycompletion. The definition of Open Replicator session pairs can becompleted in an SMC wizard dialog and the actual creation of a file isoptional. The six hot pull setup steps are:


2. Configure/connect migration SAN zone between remote devicesand Symmetrix V-Max (or Symmetrix DMX) control FA “host”ports.


4. Configure host zoning and device (LUN) masking for targetdevices.

5. Prepare Open Replicator session pairs file step can becompleted by a selection process in SMC with or without thecreation of an actual file.




7.1.2 Hot pull migration stepsThis chapter will detail an example of six migration steps applicable fora hot pull. The step 12 optional tuning action, that is applicable for allmigrations types, will be detailed again in order to illustrate the SMCinterface for tuning Open Replicator. The six hot pull migration stepsdetailed 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 onproduction applications.



7.1.3 Hot pull cleanup stepIn the case of hot pull, applications are altered to access data from thetarget devices before data movement is complete. Therefore, the firstthree cleanup steps are completed in the setup phase. That leaves only asingle step in the cleanup phase, step 19: to redeploy the source devices’storage once the migration is complete.

Figure 25 on page 142 illustrates the hot pull setup, migration, andcleanup steps in a flowchart. The nonapplicable step 14, iterativeincremental update for push sessions, and the three nonapplicablecleanup steps (steps 16-18) are omitted from the flowchart entirely toavoid unnecessary complexity.



Figure 25 Symmetrix hot pull setup, migration, and cleanup flowchart

ICO-IMG-000548a





15. Verify migration terminate OR


Hot pull?

Need tuning?


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







N



or VDEV?

Y



7.2 Setup step 1, identify target devicesFor this pull example, the target (control) devices are devices 95-98 onthe Symmetrix DMX 000190300359 array. Figure 26 illustrates the useof the Device Properties display for these devices.

Figure 26 SMC properties for Symmetrix 000190300359 devices 95-98

ICO-IMG-000549



7.3 Setup step 2, configure migration SAN zoneThis example uses a different remote array than in previous examples sonew migration zones need to be set up. The zones will include thecontrol Symmetrix V-Max (or Symmetrix DMX) FA ports, that act asopen systems host initiators and the remote Symmetrix storage array FAports where the remote devices are mapped.

7.3.1 Determining control director World Wide Port Names (WWPNs)Figure 27 illustrates a display of device properties that can be used todetermine the control device FA directors. The # Paths column indicatesthat each of the control devices is mapped to two paths. Selectingdevice 95, displays the properties detail. Selecting the FBA Front EndPaths tab reveals that directors FA-2C port 0 and FA-15C port 0 are theFA 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 theWWN for the port. Figure 28 on page 145 illustrates the properties fordirector 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 device’s other mappeddirector 15C port 0.


ICO-IMG-000551

ICO-IMG-000552



7.3.2 Determining Remote Storage Array WWPN(s)The remote storage array for this example is Symmetrix000187720450. Figure 30 illustrates a display of the directors thatremote source device 141 is mapped to in the device detail FBA FrontEnd 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 theWWPN. Figure 31 on page 147 illustrates the properties for director 8Cport 0 including the WWN.

ICO-IMG-000553




Figure 32 on page 147 illustrates the properties for the remote device’sother mapped director 9C port 0.


ICO-IMG-000554

ICO-IMG-000555



7.3.3 Configuration of migration SAN zonesFor the hot pull, it is necessary to zone all directors mapped to thecontrol device due to each director handling Copy on First Access(COFA). In this example, two independent zones are defined for bestperformance: one zone between control 2C:0 and remote 8C:0, and asecond zone between control 15C:0 and remote 9C:0.

Figure 33 is an excerpt from the Connectrix Manager verification screenthat illustrates the activation of two migration zones that have beenadded to the active zoneset for the hot pull between the two Symmetrixarrays.

Figure 33 Connectrix Manager activate Symmetrix hot pull zones

ICO-IMG-000556



7.4 Setup step 3, configure migration device masking

7.4.1 Application source device referencesThe “application” for this example uses Windows drive letters P, Q, R,and S that reside on the remote Symmetrix source devices. UsingWindows Disk Management, it can be seen in Figure 34 that drives P, Q,R, and S correspond to disks 29-32.

Figure 34 Disk Management display of remote source drives P, Q, R, and S

ICO-IMG-000557



7.4.2 Add Symmetrix device maskingBecause the Symmetrix V-Max (or Symmetrix DMX) FA “hosts” areconnected to the remote storage array on switched fibre ports, it isnecessary to perform LUN masking to grant the Symmetrix V-Max (orSymmetrix DMX) FA initiator access to the remote devices. This LUNmasking is performed with tools specific to the remote storage array,that in this case is a Symmetrix and is called device masking. Since theremote Symmetrix is only remote in terms of Open Replicator but is localin the sense of presenting host visible devices, SMC can be used tocomplete the device masking. Figure 35 illustrates invoking the DeviceMasking Menu after right clicking the remote Symmetrix array (DeviceMasking and MappingMasking).

Figure 35 SMC Device Masking menu

Figure 36 on page 151 illustrates the SMC device masking dialog. Thedialog begins with the selection of the remote Director Port FA-8C:0 andthe control Director Port that is acting as the initiator WWN5006048AD5F031C1 (FA-2C0). The list of Available Devices was filteredby Dev Config = 2-Way Mir and Cap(acity) = 4096 MB. The four remotedevices 141-144 were moved to the masking Target list by clicking theAdd button. Notice the checkbox for refreshing the VCMDB after theApply/OK is checked. When checked, the refresh will occurautomatically.

ICO-IMG-000558



Figure 36 SMC add device masking for remote devices 141-144 on FA-8C:0

SMC presents a confirmation dialog that is used to report on the successof invoking control actions. Figure 37 illustrates the Successconfirmation 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 forWWN 5006048AD5F031CE (control FA-15C:0) to remote devices 141-144on remote director port FA-9C:0.

Figure 38 SMC add device masking for remote devices 141-144 on FA-9C:0

7.4.3 Symmetrix V-Max device masking using Auto-provisioning GroupsConceptually, adding Symmetrix V-Max device masking is the same asshown for Symmetrix DMX in ”Add Symmetrix device masking,” onpage 150. A parallel example using the SMC 7.1 Task Masking Wizardwill be shown in this section.

ICO-IMG-000561



7.4.3.1 Auto-provisioning GroupsThe Auto-provisioning Groups feature was introduced in SolutionsEnabler 7.0 and Symmetrix Management Console (SMC) 7.0. It providesan easier, faster way to provision storage in Symmetrix V-Max arraysrunning Enginuity 5874. Most of the applications running onSymmetrix arrays require a fault-tolerant environment with clusteredhosts as well as multiple paths to devices. Auto-provisioning Groupswas developed to make storage allocation easier and faster, especiallywith these types of configurations.

Mapping and masking devices in previous versions of SolutionsEnabler required a separate command for each initiator/portcombination through which devices would be accessed. Bothsymaccess commands in Solutions Enabler and SMC allow the user tocreate a group of devices (storage group), a group of director ports (portgroup), and a group of host initiators (initiator group), and associatethem in a masking view. When the masking view is created, the devicesare automatically mapped and masked.

After the masking view is created, any objects (devices, ports, orinitiators) added to an existing group automatically become part of anyassociated masking view(s). This means that no additional steps arenecessary to add additional devices, ports, or initiators to an existingconfiguration. All necessary operations to make them part of theconfiguration are handled automatically by Symmetrix Enginuity oncethe objects are added to the applicable group. This reduces the numberof commands needed for mapping and masking devices and allows foreasier storage allocation and de-allocation.

The examples presented in this TechBook using symmask, symmaskdband SMC Device Masking are not applicable for Symmetrix V-Maxsystems running Enginuity 5874. Solutions Enabler 7.0 introduces thesymaccess command to manage Auto-provisioning Groups andincludes parallel commands to symmask for actions like list loginsand list hba. SMC 7.0 introduces new menu items and dialogs formanaging Auto-provisioning Groups, including Storage GroupsMaintenance, Port Groups Maintenance, Initiator Groups Maintenance,and Masking Views Maintenance.

For more information and examples see the Storage Provisioning WithEMC Symmetrix Auto-provisioning Groups Technical Note.



7.4.3.2 SMC Task Masking WizardAuto-provisioning can be invoked using multiple SMC menus to createan Initiator Group, a Port Group, a Storage Group and a Masking Viewto associate the three together. SMC also now supplies task interfaces tomore easily sequence these multiple steps without having to know eachmenu to invoke and in what order. Figure 39 illustrates selecting theMasking 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 thatlists the sequence of steps that the wizard will lead you through and theinformation 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 amasking 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 Createbutton is clicked to create a new Initiator Group.

Figure 42 Masking Wizard step 3 click to create Initiator Group

Figure 43 on page 159 illustrates the create Initiator Group dialog. Thegroup is given the name OR1724_10E0_10F0 reflecting OpenReplicator, the last four digits of the Symmetrix ID and the two FAdirectors that will be acting as host HBAs to the local Symmetrix 1715.The values displayed as Available Initiators are present only after anattempt to create the Open Replicator session is invoked. The attemptcauses the FAs to log in on the fabric even though the Open Replicatorcreate 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 for10E0 and 10F0 that will be selected:

symcfg -fa all list

Symmetrix ID: 000192601724 (Local)


Dir Port WWN ACLX Volume Set Pnt toEnabled Addressing

FA-7E 0 50000972081AF118 Yes No YesFA-7E 1 50000972081AF119 Yes No YesFA-10E 0 50000972081AF124 Yes No YesFA-10E 1 50000972081AF125 No No YesFA-7F 0 50000972081AF158 Yes No YesFA-7F 1 50000972081AF159 No No YesFA-10F 0 50000972081AF164 Yes No YesFA-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 fromthe Available to the Selected display. Clicking the OK ends this dialogreturning to Masking Wizard step 3 where clicking the Next buttonmoves to step 4.

Figure 44 on page 160 illustrates Masking Wizard step 4 selecting theports. In this example, the Select button was clicked to bring up the adisplay of existing Port Groups. The Port Group 7e0_10e0_p alreadyexists for the two ports that the Open Replicator remote devices aremapped to and is highlighted when clicked on. Expanding the groupdisplays the two FA ports 7E0 and 10E0. where the Create button isclicked to create a new Initiator Group. Clicking the OK button ends theselect dialog returning to Masking Wizard step 4.

ICO-IMG-000767b



Note: Unlike the previous example for Symmetrix DMX device masking, usingAuto-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 Groupcompletes masking for all of the ports.

Figure 44 Masking Wizard step 4 select an 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 Createbutton to open a dialog to create a new Storage Group made up of theOpen Replicator remote devices.

Figure 45 Masking Wizard step 5 click to create a Storage Group

ICO-IMG-000769a



Figure 46 illustrates the Storage Group create dialog. The StorageGroup name ORremoteTO1724 is defined. After selecting the DeviceSource Type as Symmetrix, the hundreds of available devices werefiltered by clicking the filter button and selecting the specific size of4097 MB devices. The Add All button is clicked to move the the devicesfrom the Available Devices display to the Group Members display.

Figure 46 Storage Group creation dialog

Clicking OK will return to Masking Wizard step 5, where clicking theNext button will move to step 6.

Note: The value of the Auto-provisioning masking methodology can bestressed by pointing out that to add additional devices to the Masking Viewthat is being defined, the only step required will be to modify the storage groupby adding the additional devices. Once that is done the devices will be visibleon all defined ports to all of the defined initiators.

ICO-IMG-000769b



Figure 47 illustrates Masking Wizard step 7 that displays a summary ofall previous steps to define the Masking View. Clicking the Finishbutton ends the wizard and creates the Masking View completing themasking definition..

Figure 47 Masking Wizard step 7 summary

ICO-IMG-000770



Figure 48 illustrates the Masking Wizard success dialog that displaysafter the progres bar confirming successful creating of the new MaskingView.

Note: The progress dialog for the Masking View creation can take longer thanSymmetrix DMX users may be accustomed to. This is due to the fact that withEnginuity 5874, masking creation will automatically map devices to the portsthat are being masked if they are not already mapped..

Figure 48 Masking Wizard success dialog

ICO-IMG-000771



7.5 Setup step 4, configure target zoning and LUN maskingThe current example is a hot pull that moves the step of zoning andmasking the target devices from occurring in the cleanup phase to thesetup phase, since the application will be accessing the target devicesfrom the start.

Target devices 95-98 are already correctly mapped and device maskedhost visible devices as shown by the Physical Device Name displayedin the properties device detail in SMC. Figure 49 illustrates theproperties detail for control target device 95 showing host PhysicalDevice Name .\PHYSICALDRIVE15.

Figure 49 SMC properties device detail for control target device 95.

Similarly, the displays for target devices 96-98 show Physical DeviceNames .\PHYSICALDRIVE16-18.

ICO-IMG-000562



7.6 Setup step 5, prepare Open Replicator session pairs fileThe SMC Open Replicator Create Copy Session wizard consists of fivepages that include the definition of the session control-remote pairs.Figure 50 illustrates invoking the Create Copy Session menu byright-clicking the control Symmetrix in the navigation tree(ReplicationOpen ReplicatorCreate Copy Session).

Figure 50 SMC Open Replicator Create Copy Session menu

The first page of the wizard provides for the setting of sessionparameters. In this example, the parameters are defined as a hot pullsession. The Device Selection default Customize radio button optionwill use an additional three wizard pages to select the control and remotedevice pairs. If previously saved to a file, it is possible to read in a pairsfile as well as to manually edit the pair definitions and skip to page fiveof the wizard. Figure 51 on page 167 illustrates the setting of a sessionas a hot pull session using the Customize method to specify the pairdefinitions.

ICO-IMG-000563



Figure 51 SMC Create Copy Session page 1: Set session parameters

The second page provides for selecting the control devices. Figure 52illustrates the selection of devices 95-98 and filtering the AvailableDevices to see only devices that have been mapped to director FA-2Cport 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 53illustrates the selection of devices 141-144 and filtering the AvailableDevices to see only devices that have been zoned and masked onSymmetrix 000187720450 director FA-8C port 0. This page of the wizardonly presents devices that are correctly zoned and LUN maskedoffering a verification of correct setup even before invoking the OpenReplicator create action. The WWN radio button on this page can beselected to manually add WWN formatted remote devices that may notyet 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 remotedevice 144.

Figure 54 SMC Create Copy Session page 4: Select device pairs

ICO-IMG-000567




7.7.1 Confirm hot pull setup with successful createThe fifth page of the Open Replicator wizard provides for settingadditional create options including enabling background Copy andDonor Update. Before clicking the Finish button to invoke the createoperation, the Save button can be clicked to save the pair definitions ina file that can be read and edited on page one of the wizard as analternate to defining pairing on pages two through four. Figure 55illustrates setting Copy and Donor Update, and then initiating thecreate 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 theSolutions Enabler symrcopy command, there is a confirmation screenin SMC that gets displayed before any control action is invoked.Figure 56 illustrates how to confirm the execution of the OpenReplicator Create action.

Figure 56 SMC Confirm Open Replicator create execution

Figure 57 illustrates the Create Copy Session success dialog box. For therest of the control actions in this chapter, the dialogs for control actionconfirmation and success will not be shown.

Figure 57 SMC Create Copy Session success dialog box

ICO-IMG-000569

ICO-IMG-000570



7.7.2 SMC Remote ReportWith SMC, the equivalent of symsan is checked as part of selectingremote devices in the wizard. The SMC Remote Report provides anexplicit way of looking at this information from within SMC withouthaving to invoke the Create Copy Session wizard. Figure 58 illustratesinvoking the Remote Report menu with an initial right click of thecontrol Symmetrix V-Max (or Symmetrix DMX) array, and selectingReplicationOpen ReplicatorRemote Report.

Figure 58 SMC Remote Report menu selection

ICO-IMG-000571



Remote Report has two tabs. Figure 59 illustrates the Remote Ports tab,that shows information similar to the symsan -sanports display fordirector FA-2C port 0.

Figure 59 SMC Remote Report Remote Ports tab

Clicking on the Remote Luns tab then selecting control director FA-2CPort 0, and then selecting the Port WWN 5006048ACC18C087 for remoteSymmetrix 000187720450 FA-8C:0 confirms remote devices 141-144 areaccessible. Figure 60 illustrates the Remote Luns tab display:

Figure 60 SMC Remote Report Remote Luns display

ICO-IMG-000572

ICO-IMG-000573



7.8 Migration step 9, stop the applicationsSince this example is a pull migration, it is necessary to stop productionapplications that are using the remote source devices (drives P-S), inorder to fix a point-in-time for the remote array devices. This is done atthe appropriate time when a short interruption in running theproduction applications can be tolerated.

As in Section 6.8, “Migration step 9, Stop the applications,” on page 129the Symmetrix Integration Utilities (SIU) symntctl command is usedto 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:\>



Additionally, to ensure that the original source volumes will notbecome visible on a subsequent rescan or reboot, the device masking forthe volumes needs to be removed.

Figure 61 shows removing the device masking for remote source devices141-144 for Windows host HBA WWN 10000000c97111fc from directorFA-8C:0.

Figure 61 SMC Removing device masking for devices 141-144 for FA-8C:0

ICO-IMG-000574



After clicking Apply to make the masking change, and clicking OK inthe success dialog, the same change is made to the second path for thesource devices.

Figure 62 shows removing the device masking for remote source devices141-144 for WWN 10000000c971196e from director FA-9C:0.

Figure 62 SMC Removing device masking for devices 141-144 for FA-9C:0

ICO-IMG-000575



7.9 Migration step 10, Open Replicator activateOnce the Open Replicator session is created, it can be selected in theSMC navigation tree by expanding Replication Views and thenexpanding Open Replicator Sessions. The Properties view displaysstatus equivalent to the symrcopy query command. In this casecontrol devices 95-98 are paired with remote devices 141-144 and thestate is Created. Right clicking on the session name in the navigationtree can be used to bring up the Open Replicator Session Control menu.

Figure 63 illustrates the Open Replicator session navigation treeselection, properties view and Session Control menu selection(ReplicationOpen ReplicatorSession Control).

Figure 63 SMC Open Replicator session properties and control menu

The SMC Session Control dialog, provides for selection of the desiredaction. At this point, the Activate action is selected to set thepoint-in-time for the pull of data from the remote to the control. In thisexample of a hot pull, there is no need to click the Consistent checkboxoption, as the applications were stopped and the disk cache was flushedensuring consistency. Since SMC uses the same dialog to invoke anoperation on single or multiple devices, it is necessary to select thedevice pairs that should be affected by the chosen action.

ICO-IMG-000576



Figure 64 illustrates the selection of the Activate action for OpenReplicator session symm_hot_pull affecting all four devicecontrol-remote device pairs.

Figure 64 SMC Open Replicator Activate

Notice that after the activate, the State has changed to CopyinProg(ress)and the Prot(ected) Tr(ac)ks have started to be decremented as trackshave copied over to the control.

Figure 65 illustrates the change in status after an activate operation isperformed.

Figure 65 Open Replicator session properties after activate

ICO-IMG-000577

ICO-IMG-000578



7.10 Migration step 11, restart applications using targetsNow that the data copying has begun, production applications can berestarted immediately without waiting for the copy to complete. If anattempt is made to access data that has not yet been copied, then thatdata will be copied immediately (COFA). In this example the remote andcontrol devices are the same capacity, but have a different disk geometrybecause the remote Symmetrix array is a DMX-2 and the controlSymmetrix array is a DMX-3. The Windows host operating system hasno problem with this change. However, Solaris requires some extrasteps to handle this difference that can be found on Powerlink in theEMC Enginuity 5773 Flexible Device Geometry in a Sun Solaris EnvironmentTechnical Note.

As previously explained, the symntctl command is used to rescan fordevices 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 devicesusing the same drive letters that the source devices used, so productionapplications that use the filesystems will now access the data on thetarget 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 Managementshowing the volumes P-S now based on the target devices.

Figure 66 Disk Management display of drives P-S on the target devices

ICO-IMG-000579



7.11 Migration step 12, tune migrationThe ability to set and change the pace and ceiling options is equivalent inSMC as when using the symrcopy command. Figure 67 illustratesinvoking the Set Ceiling menu by first right clicking the controlSymmetrix array (the ceiling option affects all Open Replicatorsessions), and then ReplicationOpen ReplicatorSet Ceiling.

Figure 67 SMC Select Open Replicator Set Ceiling Menu

ICO-IMG-000580



The Set Ceiling dialog provides for selecting the Director and Portindividually, or selecting the ALL option for either or both (to selectmultiple ports). Figure 68 illustrates setting the Ceiling percentage to 30for Director FA-2C Port 0.

Figure 68 SMC Open Replicator Set Ceiling

ICO-IMG-000581



7.12 Migration step 13, check status, wait until copiedThis step consists mostly of waiting until the Open Replicator copycompletes copying all of the tracks from the remote devices to the controldevices. Once this is done, the original source devices will no longer beneeded. The SMC Refresh View button can be clicked to update theproperties display for the Open Replicator session. This is one way tosee the decreasing number of Protected Tracks, and the increasing% Complete.

Figure 69 illustrates clicking the Refresh View button and the OpenReplicator session properties with the default column positioningreordered to display the columns of most interest without horizontalscrolling.

Figure 69 SMC Open Replicator session properties Refresh View update

ICO-IMG-000582



7.13 Migration step 15, verify migration and terminateOnce 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



Because SMC is a GUI and is not used in scripting, there is no directequivalent of the symrcopy verify command. However, as anintelligent GUI, the available (nongrayed) drop-down menu Actionoptions displayed in the Open Replicator Session Control dialog reflectswhich actions are valid for the current session state.

Because this is a hot pull, the production applications are already usingthe target devices, in effect verifying the validity of the copied data.However, if any application specific verification of the migration isdesired, it must be completed before terminating the Open Replicationcopy sessions along with the donor update feature that keeps theoriginal source updated with all changes since the productionapplications began using the targets. Once the validation is complete,the Open Replicator sessions are no longer needed and can beterminated.

Figure 71 illustrates turning off the donor update feature (notice thatthe flags in the final U position of the CDSHU flags shows an ‘X’ forenabled donor update).

Figure 71 Donor Update Off SMC Session Control dialog box

ICO-IMG-000584



Figure 72 illustrates invoking the Terminate action from the SMCSession Control dialog. Notice that the flags in final U position of theCDSHU flags now shows an ‘.’ for disabled donor update.

Figure 72 Terminate SMC Session Control dialog box

Following the Terminate action confirmation and the Terminate successdialog, the navigation tree symm_hot_pull session disappears from theOpen Replicator Replication Views.

7.14 Cleanup step 19, redeploy the source devicesBecause this example is a hot pull, the key cleanup steps of redirectingproduction applications to access the target devices in place of thesource devices was completed in Section 7.10, “Migration step 11,restart applications using targets,” on page 179. Step 19, redeploy thesource devices storage, is the only step remaining in the cleanup phase.

ICO-IMG-000585


PowerPath MigrationEnabler (PPME) Overview

8

This chapter defines PowerPath Migration Enabler (PPME) benefits,terminology and operations. The setup, migration and cleanup phasesare described using the set of steps first defined in Section 3.3, “BasicOpen Replicator migration operation flow,” on page 52. Because thePPME interface and capabilities offer significant simplification andenhancements, some steps are reordered, skipped, merged together, orsplit apart; yet the basic flow is still fundamentally the same. The topicscovered include:

◆ 8.1 Introduction ................................................................................... 188◆ 8.2 Benefits of using PPME................................................................ 188◆ 8.3 Nondisruptive migration overview ........................................... 189◆ 8.4 Definitions...................................................................................... 191◆ 8.5 PPME considerations and restrictions ....................................... 195◆ 8.6 PPME with Open Replicator migration operation flow.......... 196◆ 8.7 Reference information .................................................................. 202

PowerPath Migration Enabler (PPME) Overview 187

PowerPath Migration Enabler (PPME) Overview

8.1 IntroductionPowerPath Migration Enabler (PPME) is a hybrid migration solutionthat provides the ability to perform nondisruptive migrations andapplication cutovers while leveraging Open Replicator to actuallymigrate the data. PPME benefits data migrations by greatly reducing oreliminating application disruption due to the migration, reducingmigration risk, and simplifying migration operations.

When migrating data with PPME, the data continues to be accessible tohost applications while the migration takes place. Therefore,application disruption is minimal or nonexistent. The level ofdisruption depends on whether data is being migrated from a pseudo- ora native-named device, and whether PowerPath is installed on the host.If PowerPath has not been installed, then a disruption may be requiredto install PowerPath.

8.2 Benefits of using PPMEEven if PPME cannot entirely eliminate application outages, it greatlyminimizes them and reduces data migration risk. Complex migrationsalmost always will require certain setup activities for the migration thatmay involve a host reboot. For example, a migration requirement toupdate HBA drivers that requires a host reboot would be executed in ascheduled maintenance window. The application interruptionnecessary for installing PowerPath 5.x (a PPME prerequisite) can alsobe scheduled to take place during normal maintenance windows priorto the actual migration process. There is a great difference betweenperforming this type of activity as part of a maintenance window andthe more risky procedures that have to be conducted when PPME is notused. One example of a risky procedure not needed when PPME is usedis the potentially catastrophic cutover outage where a machine is shutdown, a few configuration changes are made, and the machine does notcome back up without issue (note that the risk of this type of outage canalso be minimized with careful planning and by using best practices).With PPME the cutover task is fully verified before being performedand can sometimes be conducted fully online. I/O redirection allowsadministrators to preview deployment without committing to it. Andwith PPME, in all cases, the data remains accessible to host applicationsduring the migration process.

Eliminating or even just reducing application downtime during amigration 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 haveto rely on others to follow their directions, nor do they need to work offtheir shift, which is when migration data movement operations arefrequently scheduled. With PPME, the pressure to correctly completecritical and complex migration tasks during outages or off hours isreduced or eliminated.

PPME also greatly simplifies migration operations, hiding thecomplexities of underlying migration products and integrating with thehost. This simplification is even more important in providing acommon interface across heterogeneous hosts, eliminating the hostspecific knowledge required to perform key migration tasks. Thesimplicity that PPME brings to migration operations may even allowless skilled and less expensive staff to execute the work.

8.3 Nondisruptive migration overviewThe PPME powermig command is used to interface with OpenReplicator. Open Replicator hot pull does the bulk data copyingbetween the arrays through the SAN. PPME keeps source and targetdevices synchronized by cloning writes on the host. Mirroring the twodevices allows testing of the migration and returning to the initial statewith no downtime.

Figure 73 on page 190 illustrates an example of PPME Operation withpseudo-named (location independent) devices and Open Replicatorwhere PPME swaps the pseudo-named devices in the middle so thatemcpower25c points to the target device instead of the source devicewithout 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



8.4 Definitions

8.4.1 Pseudo or Native device name migrationsThe operating system creates native devices to represent and provideaccess to logical devices. A native device is path specific (as opposed topath independent) and represents a single path to a logical device. Thedevice is native in that it is provided by the operating system for usewith applications. After migrating data from a native device name,production applications must be reconfigured to use the newtarget-device name, which is a minimally disruptive process.

Pseudo device names are location-independent names that represent asingle logical device and the path set leading to it. Alocation-independent device name allows the migration of data withoutrequiring the reconfiguration of applications in order to use a newlogical unit. When data is migrated from one pseudo-named device toanother pseudo-named device, the migration can be nondisruptive. Theexample in Chapter 9, “PPME with Open Replicator MigrationExample,” illustrates a migration from one pseudo device to another.

8.4.2 Source and targetPPME uses the terms source and target to refer to the two endpoints of adata migration. When Open Replicator hot pull is used for migrations,the source LUNs are Open Replicator remote devices and the targetLUNs are control devices.

8.4.3 PPME Migration StatesA migration session transitions through a number of states aspowermig commands are executed. Figure 74 on page 192 shows theoverall migration workflow, including the sequence of powermigcommands and the corresponding migration states. Numbers onethrough eight in the graphic shown in Figure 74 depict the commandsinvolved in a normal migration workflow. The graphic also shows themigration states from which you can enter the powermig abort andpowermig cleanup commands.



Figure 74 PPME Migration states and commands

Table 1 on page 193 describes the PPME Migration states when OpenReplicator is used as the underlying technology, along with the relevantOpen Replicator states.

powermigcleanup

powermigabort

powermigcleanup

powermig undoRedirect

CommittedAndRedirected

powermig sync

powermig setup

powermig commitSource is Pseudo

powermigselectTarget

powermigselectSource

Setup

Synching

SourceSelected

TargetSelected

Committed

ICO-IMG-000586

powermig commitSource is Native

Source & targetsynchronized

1

2

3

45

6 6

87



Table 1 PPME Migration states

State Description

Setup A migration is in the Setup state after a powermig setupcommand completes successfully. Before a migration can enterthis state, synchronization prerequisites must be met. WhenOpen Replicator is the underlying technology, all requirementsfor the create action have been met and the Open Replicatorstate is Created.

Syncing A migration enters the Syncing state when the powermig sync command initiates a synchronization of the source andtarget logical units. When Open Replicator is the underlyingtechnology, the bulk copy of data from the source to the targetis done in the SAN by Open Replicator in the CopyInProgstate. Application reads are from the source, writes aremirrored to both source and target by PPME.

SourceSelected The migration enters the SourceSelected state once theOpen Replicator session has reached the Copied state (or afterpowermig selectSource completes). Application reads arestill from the source, while writes continue to be mirrored toboth source and target by PPME.

TargetSelected The migration transitions to the TargetSelected state afterthe powermig selectTarget command completes.Application reads are now from the target, writes are stillmirrored to both source and target by PPME, making itpossible to return to the SourceSelected state.

CommittedAndRedirected

The migration enters the CommittedAndRedirected stateafter the powermig commit command completes for anative-named source device. Application reads continue fromthe target via redirection, writes are no longer mirrored so it isnot possible to abort the migration. This is intended to be ashort lived temporary state, where production applicationsmust be stopped. Then the powermig undoRedirectcommand is invoked to disable the redirection. Onceapplications have been reconfigured to use the target devicepaths, they can be restarted.

Committed The migration enters the Committed state after the powermig commit command completes for a pseudo-named sourcedevice or after the powermig undoRedirect command for anative-named source device. Application reads continue fromthe target, writes are not mirrored so it is not possible to abortthe migration.



8.4.4 PPME Abort, Cleanup, and RecoverA migration can be aborted with the powermig abort commandanytime after entering powermig sync and before entering thepowermig commit command. In other words, a migration can beaborted while in the Syncing, SourceSelected, orTargetSelected state. An aborted migration session returns to theSetup 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 applicationsand/or the operating system are not confused by identical data residingon both the source and target LUNs. The powermig cleanupcommand can be run while in the Committed or the Setup state.When run while in the Committed state, selected data on the sourceLUN is removed. When run while in the Setup state (typically after anabort) selected data on the target LUN is removed. After running thiscommand the source or target LUN from which selected data has beenremoved will not mistakenly be read by the host operating system.

The powermig recover command can be used to recover a migrationafter an interruption occurs. Interruptions can result from a migrationerror, a process crash, or a device fault. This command should be runwhenever the migration is in the NeedsRecovery state. In the case of amigration error, the recovery may fail until the cause of the error isidentified and resolved. When the powermig recover commandcompletes successfully, the migration state changes to the state to whichthe session was transitioning when the interruption occurred.



8.5 PPME considerations and restrictionsThe following restrictions apply to all host platforms when usingPPME:

◆ PowerPath Migration Enabler does not support:

• Migrating paging or swapping devices.

• Migrating boot devices.

• Uninstalling or upgrading PowerPath while a migration is inprogress.

◆ The target LUN:

• Must be the same size as or larger than the source logical unit forOpen 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 thesource and target logical devices, the HBAs must be comparable inevery way (even different revisions of the same HBA are notpermitted).

◆ LUNs involved in a migration should not be used as Symmetrixgatekeeper devices because I/O redirection will cause gatekeepererrors. Use of the Solutions Enabler gkavoid or gkselect files canensure that migration LUNs are not used as gatekeepers. The EMCSolutions Enabler Symmetrix Array Management CLI Product Guidecontains more information about gatekeeper devices.

◆ When migrating data to a target LUN that is larger than the sourceLUN, the migration must be committed before gaining access tospace on the target that does not exist on the source. Attempting toaccess that space when the migration is in the TargetSelectedstate will result in I/O errors.

• For Solaris hosts the powerformat utility can be used toincrease the size of a LUN by updating the ASCII and disk labelinformation. More information about powerformat can befound in the EMC PowerPath Migration Enabler User Guide.

◆ Requires the host be running PowerPath version 5.0 or higher.



8.6 PPME with Open Replicator migration operation flowThe eight steps in the normal PPME workflow introduced in Figure 74on page 192 will be listed and flowcharted using the 19 migration stepsintroduced in Section 3.3, “Basic Open Replicator migration operationflow,” on page 52 even though steps that apply to cold or push OpenReplicator operations are not applicable. Correctly setting up theunderlying 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 pullexamples. The migration phase steps using Open Replicator are fewerand simpler because PPME provides for skipping some steps entirelyand delays other steps to the cleanup phase. The cleanup phase stepswill be significantly redefined in order to incorporate the change inorder and greater functionally of PPME in this phase.

8.6.1 Setup stepsThe first four setup steps are required in order to set up OpenReplicator for hot pull operations and therefore fully apply when usingPPME with Open Replicator. For some operating systems, it may benecessary to run explicit powermt commands to update the PowerPathconfiguration after making the target devices visible to the host. Anadditional sub-step is added to the fourth step, making the first foursetup steps now:


2. Configure/connect migration SAN zone between remote portsand Symmetrix V-Max (or Symmetrix DMX) control FA “host”ports.


4a. Configure host zoning and device (LUN) masking for targetdevices.

4b. Update and save the PowerPath configuration.

The powermig setup command effectively combines the fifth andsixth setup steps, though there is no creation of an actual pairs file nor auser made call to symrcopy create.





Figure 75 illustrates the setup steps as a flowchart.

Figure 75 PPME with Open Replicator setup steps flowchart

8.6.2 Migration stepsA PPME managed migration has fewer operational steps than a hot pullmigration solely under Open Replicator control. The ability ofPowerPath to redirect I/O allows for less impact on the productionapplications and provides more flexibility as to when the migrationchange is committed. For example, migration steps 9 and 11 that brieflystop and restart applications with them pointing to the target devicesare no longer needed prior to the migration, because during themigration copy, PPME directs all application reads from the sourcedevice, and can transparently manage the redirection of the applicationto the target devices after the data movement completes. And becausePPME provides a broader set of cleanup operations, step 15 thatconsists of the verification of the migration and termination of the OpenReplicator session is postponed to that phase. With PPME, themigration steps look like this:

10. powermig sync (activate the Open Replicator session)

12. Tune migration to acceptable level of impact on productionapplication(optional)

13. powermig query (verify Open Replicator copy session isfinished)

Figure 76 on page 198 illustrates the migration steps as a flowchart.

ICO-IMG-000587

Hot pull?

5-6. powermig setup [define source / target pair, create OR session]



1. Provision / identify target devices 4a. Zone and device mask

target devices to host

4b. Update and save PowerPath configuration

Y

N



Figure 76 PPME migration steps flowchart

8.6.2.1 Step 10 detailActivating each Open Replicator session is accomplished by thepowermig sync command that initiates the copying from source totarget. Although this operation is performed as an Open Replicator hotpull, with PPME the production applications are still reading from thesource devices rather than the targets. Additionally, the session is notcreated with the donor update option enabled because PPME mirrorsall application writes to both source and target devices.

8.6.2.2 Step 12 detailAs mentioned in “Tuning Open Replicator,” on page 60 the PPMEthrottle mechanism is an alternate interface to the Open Replicator paceparameter. However, the pace parameter is the secondary tuningmechanism for Open Replicator. In order to use the primary tuningmechanism, the ceiling value can be set using symrcopy set ceiling or SMC Set Ceiling. The pace value is ignored for allparticipating director/port combinations where the ceiling value is notNONE (including PPME Open Replicator sessions).

8.6.2.3 Step 13 detailThe powermig query command is used to report back on the progressof the background copying. Since the query action must specify asingle PPME handle, it only reports on a single source/target pair. Thepowermig info -all -query command, on the other hand can beused to report on all source/target pairs under PPME control.

ICO-IMG-000588


13. powermig query [Verify OR copy done]

Need tuning?

10. powermig sync [OR activate]

Y

N

N



8.6.3 Cleanup stepsThe cleanup steps when using PPME are simple, yet provide extensivefunctionality and flexibility that reduce migration risk. The cleanupstep descriptions and ordering are different when PPME uses OpenReplicator, than when Open Replicator is used alone. The final step ofthe migration phase and the four cleanup steps introduced in Section3.3, “Basic Open Replicator migration operation flow,” on page 52 are:

15. Verify migration is complete and terminate Open Replicatorsession.

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(optional, needed for all but hot pull operations).

18. Restart applications pointing to the target devices in place of theoriginal source devices(optional, needed for all but hot pull operations).


Even though PPME uses Open Replicator hot pull operations to do thebulk data migration copying, the desired outcomes of steps 16 and 18are part of the cleanup phase. That is because the switch to having theproduction applications read from the target devices is delayed untilthis phase.

The PPME commands that fulfill the purpose of steps 15, 16 and 18,achieves the desired outcomes in different ways that are described inthe next five sections. Step 17 is skipped when using PPME because itwas already completed as step 4 in the setup phase (the same as whenOpen Replicator hot pull is used without PPME). Step 19 is very similarfor all of the migration examples presented, though the source devicescan remain configured as visible to the host, since PPME includescommands that avoid application or operating system confusion thatcan be caused by seeing identical data residing on both the source andtarget LUNs.



8.6.3.1 PPME switch application reading from source or target devicesPPME explicitly includes cleanup operations as part of its commandset. Unlike when using Open Replicator hot pull directly, when usedwith PPME, production applications continue to read from the sourcedevice during the migration movement of data. Once the bulk copy iscomplete, mirroring to both source and target devices makes it possibleto switch back and forth between reading from source and reading fromtarget until all validation checks for the migration are complete.

The SourceSelected state defines the condition when source andtarget are synchronized and all application reads come from the source.The PPME command powermig selectTarget can be used toswitch to the TargetSelected state. The TargetSelected statedefines the condition when source and target are synchronized and allapplication reads come from the target. The best practice is to conductapplication specific migration verification while in this state (the firsthalf of step 15). The PPME command powermig selectSource canbe used to switch back to the SourceSelected state. The ability toswitch back and forth between the source and target devices isperformed transparently to the production applications.

8.6.3.2 PPME transparently committing to the target devicesWhen using pseudo-named source devices and while in theTargetSelected state, the PPME command powermig commit canbe used to switch to the Committed state. When this operation isperformed, production applications transparently continue to operateusing the target devices, that now use the pseudo-names previouslyused for the source devices. Unlike the selectTarget orSelectSource actions, the commit action is permanent because writemirroring is stopped, making the source devices no longer valid forproduction application use. This move of application processing to thetarget devices effectively completes step 18 without any applicationrestart.

8.6.3.3 PPME cleanup of the source devicesWhile 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 operatingsystem are not confused by identical data residing on both the sourceand target LUNs. Avoiding this potential confusion meets the purposeof step 16 and can make step 19, redeploying the source devices easier



because they are still configured to be visible to the host. The cleanupoperation also terminates the Open Replicator session, therebycompleting the second half of step 15.

8.6.3.4 PPME commit for native-named source devicesWhen using native-named source devices, it is not possible totransparently direct all production application I/O to the target deviceson a permanent basis. The native-names specifically reference thephysical path to the source devices and therefore cannot be used topermanently reference different paths to the target devices.

When using native-named source devices and while in theTargetSelected state, the PPME command powermig commit canbe used to switch to the CommittedAndRedirected state. With thisoperation, the production applications transparently continue tooperate using the target devices, via temporary I/O redirection. Thecommit action is permanent because write mirroring is stopped,making the source devices no longer valid to use for productionapplications. Applications can continue to run referencing the targetdevices in this manner until it is convenient to briefly stop them. Thepowermig undoRedirect command is then used to disable the I/Oredirection. Then, production applications must be reconfigured to usethe target device paths, and then be restarted. Cleanup of the sourcedevices should then be completed as described in Section 8.6.3.3,“PPME cleanup of the source devices ,” on page 200. This move ofapplication processing to the target devices effectively completes step18.

8.6.3.5 PPME abort and cleanup of the target devicesAt any time during the migration data movement or migrationvalidation testing, the powermig abort command can be executedprovided the commit operation has not been executed. The abortoperation leaves the migration in the Setup state, and from there themigration can either be restarted or cleaned up. From the Setup state,the PPME command powermig cleanup command can be used toremove selected data from the target LUN. This removal ensures thatproduction applications and/or the operating system are not confusedby identical data residing on both the source and target LUNs.



Figure 77 illustrates the PPME cleanup steps as a flowchart. Themultiple parts of step 18 and notes referring to step 15 and 16 appearout of numeric order due to representing the PPME operational flowusing the step definitions for migration steps conducted without PPMEfrom Section 3.3, “Basic Open Replicator migration operation flow,” onpage 52.

Figure 77 PPME cleanup steps flowchart

8.7 Reference informationAdditional details for PPME can be found in the EMC PowerPathMigration Enabler User Guide. Users should upgrade to the latest versionin order to get the latest features and performance improvements.Details of PPME support for pseudo and native devices can be found inthe E-Lab™ Interoperability Navigator available on the Powerlinkwebsite (http://Powerlink.EMC.com).

ICO-IMG-000589


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 ReplicatorMigration Example

9

This chapter details a PPME with Open Replicator migration examplethat 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, “PowerPathMigration Enabler (PPME) Overview,”will be clarified by a migrationexample. The topics covered include:

◆ 9.1 Introduction .................................................................................... 204◆ 9.2 PPME Setup steps 1-4 .................................................................... 205◆ 9.3 PPME Setup steps 5-6, powermig setup..................................... 205◆ 9.4 Migration step 10, powermig sync .............................................. 210◆ 9.5 Migration step 12, tune migration .............................................. 211◆ 9.6 Migration step 13, query status, until SourceSelected.............. 212◆ 9.7 Migration step 18a, powermig selectTarget............................... 214◆ 9.8 Migration step 18b, powermig commit ...................................... 215◆ 9.9 Migration step 16, powermig cleanup ........................................ 217◆ 9.10 Migration step 19, redeploy source devices storage ............... 217

PPME with Open Replicator Migration Example 203

PPME with Open Replicator Migration Example

9.1 IntroductionThis chapter details a PPME with Open Replicator migration examplethat uses the same Windows host, source devices (141-144) and targetdevices (95-98) as those used in Chapter 7. The applicable migrationsteps defined for PPME in Chapter 8 apply for this example, so the listof steps required to perform the migration is not repeated here.However, the migration steps flowchart for all three phases is shown inFigure 78 on page 204.

Figure 78 PPME with Open Replicator setup, migration, and cleanup steps

ICO-IMG-000594


18a. powermig selectTarget migration check validation (step 15, first half)

18b. powermig commit

18c. Stop applications

18d. powermig undoRedirect16. powermig cleanup avoid source device conflicts OR terminate (step 15,

Abort?

Native-namedsource devices?

N

N

Y

Y

Abort processing detail not

included in this flowchart


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


1. Provision / identify target devices 4a. Zone and device mask

target devices to host

4b. Update and save PowerPath configuration

Y

N

second half)



9.2 PPME Setup steps 1-4Since PPME will also use an Open Replicator hot pull for the bulk datacopy, the setup steps 1-4 are identical to the way they were performedin Chapter 7, “Hot Pull from Symmetrix Migration Example,” thereforethese operations will not be repeated in this example. The PPME withOpen Replicator operational flowchart adds a step 4b, to update andsave the PowerPath configuration. This step was not necessary in theexample presented here. An example of completing this step on aSolaris host is:

# powermt config# powermt save#

9.3 PPME Setup steps 5-6, powermig setup

The session concept available with symrcopy and the SMC interfacefor Open Replicator provides a convenient user interface to work withmultiple pairs of devices as a single unit. In the Symmetrix array, eachcontrol/remote pair in the same session is actually independent of eachother. The PPME interface does not provide for a way to group multiplepairs of devices as a single unit. Each source/target pair is controlledindividually with a separate handle assigned to each pair. Thereforethere is no need to create a pairs file; instead each source and targetdevice pair is defined on the command line of the setup action. Forthis example, each device must be identified using a PowerPath pseudodevice name because the Windows operating system only supportspseudo device names. In other environments, native device names canbe used as well.



9.3.1 Identify source and target pseudo device namesThe physical names for the source devices used can be displayed usingthe following Solutions Enabler command:

c:\>symdev list -sid 450 -range 141:144


Device Name Directors Device------------------------- ------------- -------------------------------

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

0141 \\.\PHYSICALDRIVE29 09C:0 02C:C3 2-Way Mir N/Grp'd RW 40960142 \\.\PHYSICALDRIVE30 09C:0 01C:C4 2-Way Mir N/Grp'd RW 40960143 \\.\PHYSICALDRIVE31 09C:0 02B:C4 2-Way Mir N/Grp'd RW 40960144 \\.\PHYSICALDRIVE32 08C:0 15C:C4 2-Way Mir N/Grp'd RW 4096

c:\>However, the PowerPath pseudo device names for Windows uses theformat harddiskXX, that can be seen when displaying the PowerPathdevices:

c:\>powermt display dev=all. . .Pseudo name=harddisk29Symmetrix ID=000187720450Logical device ID=0141state=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 12 port2\path0\tgt3\lun16 c2t3d16 FA 9cA active alive 0 04 port4\path0\tgt1\lun16 c4t1d16 FA 8cA active dead 0 14 port4\path0\tgt3\lun16 c4t3d16 FA 8cA active alive 0 0

Pseudo name=harddisk30Symmetrix ID=000187720450Logical device ID=0142. . .Pseudo name=harddisk31Symmetrix ID=000187720450Logical device ID=0143. . .Pseudo name=harddisk32Symmetrix ID=000187720450Logical device ID=0144. . .



Similarly, the target physical device names can be displayed:

c:\>symdev list -sid 359 -range 95:98


Device Name Directors Device------------------------- ------------- -------------------------------

CapSym Physical SA :P DA :IT Config Attribute Sts (MB)------------------------- ------------- -------------------------------0095 \\.\PHYSICALDRIVE15 15C:0 01B:C5 2-Way Mir N/Grp'd RW 40960096 \\.\PHYSICALDRIVE16 15C:0 16A:D8 2-Way Mir N/Grp'd RW 40960097 \\.\PHYSICALDRIVE17 15C:0 16B:CC 2-Way Mir N/Grp'd RW 40960098 \\.\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 notnecessary to use the powermt display command to see thehardiskXX format. For example, target device 95 has a physical devicename ending in 15, therefore specifying the pseudo device nameharddisk15 explicitly can yield a check that it does indeed point toSymmetrix device 95:

c:\>powermt display dev=harddisk15Pseudo name=harddisk15Symmetrix ID=000190300359Logical device ID=0095. . .

9.3.2 PPME license requiredIn addition to the Solutions Enabler Open Replicator/LM license,PowerPath Migration Enabler requires a specific license for datamigrations using Open Replicator. Issuing a valid PPME commandwithout the required license will result in an

error. The required license can be added using the PowerPath licenseregistration 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-NNNNSuccess: License added

c:\>



9.3.3 PPME powermig setupThe setup action requires the underlying technology to be specified;OR is used to signify Open Replicator. Many of the powermigcommand arguments have two and three character abbreviations: srcfor source, tgt for target, and no for noprompt. The source andtarget pseudo device names are specified to define the pair and anumeric handle is returned to use for subsequent powermigcommands:


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 allsource/target pairs under PPME control. Notice that the foursource/target pairs used in this example are in the setup state.

c:\>powermig info -all========================================Hnd Source Target Tech State=== ========== ========== ==== =====1 harddisk24 harddisk15 OR setup2 harddisk25 harddisk16 OR setup3 harddisk26 harddisk17 OR setup4 harddisk27 harddisk18 OR setup

c:\>



The setup action issues the Open Replicator create command, so thesuccessful setup state confirms that the create was successful,verifying that all of the required Open Replicator setup steps have beencompleted. Even though the powermig command is used to controlthis migration, it is still possible to view Open Replicator status directlyusing symrcopy or SMC. In the following example, notice thefollowing 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


Control Device Remote Device Flags Status Done--------------- ----------------------------- ----- -------------- ----

ProtectedSym Tracks Identification RI CDSHU CTL <=> REM (%)----- --------- -------------------------- -- ----- -------------- ----0095 65535 000187720450:0141 SD X..X. Created N/A0096 65535 000187720450:0142 SD X..X. Created N/A0097 65535 000187720450:0143 SD X..X. Created N/A0098 65535 000187720450:0144 SD X..X. Created N/A

Total ---------Tracks 262140MB(s) 16383.8









c:\>



9.4 Migration step 10, powermig sync

Activating Open Replicator sessions is accomplished by executing thepowermig sync command, that initiates the copying from source totarget.

c:\>powermig sync -handle 1 -noprompt




c:\>



9.5 Migration step 12, tune migrationThe PPME throttle mechanism is an alternate interface to the OpenReplicator pace parameter. The following example of powermig helpshows 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 OpenReplicator as the underlying technology. In this example, the ceilingvalues set for the Symmetrix control FA ports in earlier are still in effect.The throttle value is ignored for all participating director/portcombinations where the ceiling value is not NONE. The followingcommand can be used to display the current ceiling settings:

c:\>symrcopy -sid 359 list ceiling




c:\>



9.6 Migration step 13, query status, until SourceSelectedThis step consists mostly of waiting until the underlying technology,Open Replicator copy, completes copying all of the tracks from thesource devices to the target devices.

The powermig query command is used to report back on the progressof the background copying. The query action must specify a singlePPME handle, and thus can only report on a single source/target pair.In the following example, notice the PPME Migration state is nowsyncing and the Percent InSync is up to 1 percent.

c:\>powermig query -handle 1

Handle: 1Source: harddisk24Target: harddisk15Technology: ORMigration state: syncingPercent InSync: 1%Throttle Value: 5

c:\>The powermig info command has an -all option, that can be usedto list the status for all PPME source/target pairs in a single command.Additionally, the -query option can be specified to include thepercent InSync values:

c:\>powermig info -all==========================================Hnd Source Target Tech State=== ========== ========== ==== =======1 harddisk24 harddisk15 OR syncing2 harddisk25 harddisk16 OR syncing3 harddisk26 harddisk17 OR syncing4 harddisk27 harddisk18 OR syncing

c:\>powermig info -all -query==============================================Hnd Source Target Tech State=== ========== ========== ==== ===========1 harddisk24 harddisk15 OR syncing(1%)2 harddisk25 harddisk16 OR syncing(1%)3 harddisk26 harddisk17 OR syncing(1%)4 harddisk27 harddisk18 OR syncing(1%)

c:\>



After waiting long enough, the bulk Open Replicator copy willcomplete and the sessions will be in the Open Replicator Copied state.As shown in this example, the Open Replicator Copied state isreflected in the PPME sourceSelected state:

c:\>powermig info -all -query=================================================Hnd Source Target Tech State=== ========== ========== ==== ==============1 harddisk24 harddisk15 OR sourceSelected2 harddisk25 harddisk16 OR sourceSelected3 harddisk26 harddisk17 OR sourceSelected4 harddisk27 harddisk18 OR sourceSelected

c:\>When using PPME, the sourceSelected state is an indicator that thedata transfer is complete. The next set of operations are part of therobust cleanup steps introduced in Section 8.6.3, “Cleanup steps,” onpage 199. These steps are presented in a typical PPME sequence, butthe titles are not numerically in order, since the step numbers are basedon the Open Replicator examples presented previously.



9.7 Migration step 18a, powermig selectTarget

The PPME command powermig selectTarget is used to switch tothe targetSelected state. The targetSelected state defines thecondition when source and target are synchronized and all applicationreads come from the target. The following commands are used to enterthe targetSelected state and display that status:

c:\> powermig selectTarget -handle 1 -noprompt




c:\>powermig info -all=================================================Hnd Source Target Tech State=== ========== ========== ==== ==============1 harddisk24 harddisk15 OR targetSelected2 harddisk25 harddisk16 OR targetSelected3 harddisk26 harddisk17 OR targetSelected4 harddisk27 harddisk18 OR targetSelected

c:\>A best practice is to conduct application specific migration verificationwhile in this state (the first half of step 15). As part of the verificationprocess it is possible to switch back and forth between thesourceSelected and targetSelected states; such switching istransparent to the production applications. If the migration does notmeet the migration verification criteria, it can be aborted, then restartedor completely cleaned up. If the migration verification criteria are met,then it is time to commit the migration to using the target devices.



9.8 Migration step 18b, powermig commit

For this example on a Windows host, pseudo-named source devices arein use, providing for a transparent, single step commit. If native deviceswere in use, two powermig command actions would be necessary,along with stopping applications in between and reconfiguring them toreference the target devices in place of the source devices as describedin Section 8.6.3.4, “PPME commit for native-named source devices,” onpage 201.

The PPME command powermig commit can be used to switch to theCommitted state:

c:\>powermig commit -handle 1 -noprompt




c:\>powermig info -all============================================Hnd Source Target Tech State=== ========== ========== ==== =========1 harddisk24 harddisk15 OR committed2 harddisk25 harddisk16 OR committed3 harddisk26 harddisk17 OR committed4 harddisk27 harddisk18 OR committed

c:\>



The production applications can now transparently continue to operateusing the target devices on a permanent basis, because PPME hasswapped the pseudo-names used for source and target devices. Thischange in pseudo-names can be seen by comparing the powermt display output from before the commit (Section 9.3.1, ”Identifysource and target pseudo device names,” on page 206) with the outputafter the commit shown below. Previously, source devices 141-144 usedpseudo-names were hardisk29 to hardisk32. Now, the targetdevices 95-98 use pseudo-names hardisk29 to hardisk32.

c:\>powermt display dev=all. . .Pseudo name=harddisk15Symmetrix ID=000187720450Logical device ID=0141. . .Pseudo name=harddisk16Symmetrix ID=000187720450Logical device ID=0142. . .Pseudo name=harddisk17Symmetrix ID=000187720450Logical device ID=0143. . .Pseudo name=harddisk18Symmetrix ID=000187720450Logical device ID=0144. . .Pseudo name=harddisk29Symmetrix ID=000190300359Logical device ID=0095. . .Pseudo name=harddisk30Symmetrix ID=000190300359Logical device ID=0096. . .Pseudo name=harddisk31Symmetrix ID=000190300359Logical device ID=0097. . .Pseudo name=harddisk32Symmetrix ID=000190300359Logical device ID=0098. . .



9.9 Migration step 16, powermig cleanupWhile in the Committed state, the PPME command powermig cleanup should be used to remove selected data from each sourceLUN, ensuring that production applications and/or the operatingsystem are not confused by identical data residing on both the sourceand target LUNs. The help for the cleanup action shows that the-format option could be used in this example to perform a full diskformat 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 andterminates the Open Replicator session, as shown by the followingcommand actions:

c:\>powermig info -all

No migrations found.

c:\>symrcopy -sid 359 list

Symmetrix ID: 000190300359No Devices with RCopy sessions were found.

c:\>

9.10 Migration step 19, redeploy source devices storageStep 19 is very similar for all of the presented migration examples.However in this example, because of the cleanup action, the sourcedevices can remain configured as being visible to the host.




Open ReplicatorPerformance Tuning

A

The purpose of this appendix is to consolidate, expand and elaborateon the performance tuning information included in the earlier chaptersof this TechBook. The topics covered include:

◆ A.1 Two goals of Open Replicator tuning.................................... 220◆ A.2 Resource conflicts ..................................................................... 220◆ A.3 Limiting Open Replicator resource usage............................. 221◆ A.4 Migration options can impose performance delays ............ 222◆ A.5 Tuning Open Replicator........................................................... 223◆ A.6 Monitoring Open Replicator performance............................ 225◆ A.7 Tuning for applications sensitive to response time ............. 230

Open Replicator Performance Tuning 219

Open Replicator Performance Tuning

A.1 Two goals of Open Replicator tuningOpen Replicator tuning is a matter of balancing two possibly conflictinggoals. Usually, the most important goal of Open Replicator tuning is toensure that the data migration does not unacceptably impact thesimultaneously running production applications. The secondary goal isto ensure that the data migration completes within the plannedwindow for the migration. These goals will conflict when the number ofresources needed to meet the migration window goal results inundesired impact to production applications.

A.2 Resource conflictsOpen Replicator impact on production application performance ismainly a result of I/O resource conflict. There might also be some CPUimpact when Open Replicator management is executed on theapplication host.

A.2.1 I/O resource pathsThe 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 tothe Target Array.

The Open Replicator migration I/O path goes from the:

Source ArraySANTarget Array

A.2.2 Array I/O conflictsIn the case of a push migration, both the production and migrationapplications utilize resources in the source storage array (the controlSymmetrix V-Max or Symmetrix DMX array). In the case of hot pullmigration, both the production and migration applications utilizeresources in the target storage array (the control Symmetrix V-Max orSymmetrix DMX array). The key contended resource in the storagearray I/O path is the control Symmetrix V-Max (or Symmetrix DMX)front-end fibre director (FA) that connects the array to the host throughthe SAN. When the FA is used for both production and migrationresources, there is conflict when there is not enough excess capacity tomeet both demands fully. And even if there is enough capacity to meetthe dual demands, there is still queuing conflicts when competingrequests arrive simultaneously. One request will be serviced first, while



the other must wait resulting in an extended service time. Within theSymmetrix V-Max (or Symmetrix DMX) there also will be competitionfor cache memory and back-end disk I/O, however this competitionhas less impact due to the asynchronous nature of performance impactin an integrated cached disk array (ICDA). Performance tuningapproaches for Open Replicator cache memory and back-end disk I/Oare not any different than tuning for these resources with otherapplications.

A.3 Limiting Open Replicator resource usage

A.3.1 Using a separate management hostAs a SAN-based migration product, Open Replicator avoids I/Oconflicts at the production host. The command management I/O forOpen Replicator uses a very small amount of production host I/Oresources if executed on the production host. For this reason (and toavoid similarly low impact CPU utilization) sometimes OpenReplicator migration is directed from a separate management host. TheOpen Replicator management CPU and I/O resource usage is probablytoo small to have a significant impact, so the use of a separatemanagement host is typically a result of conforming to site definedpractices. Note that certain cleanup migration phase steps can only beexecuted on the production host. Correspondingly, PowerPathMigration Enabler (PPME) needs to be executed on the production host.

A.3.2 Limiting Symmetrix FA director competitionGiven that both production and migration applications are contendingfor FA resources, tuning FA performance is a matter of limiting oneapplication's I/O requests to the benefit of the other. Most migrationswill actually employ multiple strategies to achieve this.

One principle strategy involves scheduling. Often, the migrationwindow is during a lower production application resource usageperiod. Scheduling the migration at this time has the double benefit ofmore resources being available for the migration while the impact onthe production application is less critical. Depending on the length ofthe migration window, and the consequence of production applicationslowdowns during this period, it may be possible to tune the migrationto use even more resources in order to complete the migration withinthe migration window timeframe.



A second strategy involves using independent FA resources to permitboth production and migration applications to avoid resourcecontention with each other, though each still may not find itsindependent resources sufficient to avoid performance issues. OnlyOpen Replicator cold migrations can fully utilize this strategy. OpenReplicator hot migrations require all FA directors that are mapped tothe control devices to be configured to support Copy on FirstAccess/Write (COFx) operations. The ceiling setting can be used tolimit Open Replicator hot migration I/Os to only COFx I/Os.

A third strategy involves limiting one application's FA I/O requests tothe benefit of the other. Whether this can be done by productionapplications is beyond the scope of this TechBook. As introduced in”Tuning Open Replicator,” on page 60 the Open Replicator I/Orequests can be limited through setting the ceiling value, setting the pacevalue and temporarily disabling background copying.

A.4 Migration options can impose performance delaysCertain Open Replicator migration configurations result in systemicperformance delays in return for a desired feature. For example, hotmigration COFx activity means that the production I/O is delayed untilthe migration copy operation preserving the activate point-in-timecompletes first. This delay can be avoided by using a cold migrationconfiguration. This delay can be minimized in the case of hot push, byusing the -precopy option to reduce the number of tracks not yetcopied to the remote requiring COFW I/Os (Note: precopy requiresEnginuity 5772 or higher). Hot pull migrations that utilize the-donor_update option also have a systemic performance delay ofcopying the write I/Os to the remote before allowing the productionwrite to the control to complete.



A.5 Tuning Open ReplicatorOpen Replicator performance can be tuned by static configurationchoices or using dynamic commands both before and during amigration to set ceiling, pace or nocopy mode.

A.5.1 Static configuration limits on Open Replicator resource useThe goal of static configuration for performance is to separate the FAdirector resources used by Open Replicator migrations from productionapplications. If the Symmetrix V-Max (or Symmetrix DMX) has enoughFA director ports, then Open Replicator cold migrations can beconfigured to use independent FA director ports. This can be achievedby mapping the control devices to one or more FA director ports notused by production applications. Then, these migration control FAdirector ports would be zoned and LUN masked to see the remote arraydirectors and devices. If there are no free FA director ports, then coldmigrations can be configured to use a subset of the FA director portsused by production applications, thus limiting the FA director portswhere there is competition for resources.

For hot migration configurations, it is still possible to partially achievethe use of independent FA director ports. The static configuration partis the same as for cold migrations - mapping the control devices to oneor more FA director ports not used by production applications.However, hot migration configurations require all control FA directorports to be zoned and LUN masked for COFx access, thus all of theproduction application FA director ports must be configured for OpenReplicator use. Fortunately, the ceiling setting can be used to severelylimit the use of the shared FA director ports. Setting the ceiling value tozero percent means that a FA director port will not be used for anybackground copy migration operations; it will only be used for COFxactivity as needed.

A.5.2 Dynamic limits on Open Replicator resource useOpen Replicator provides three alternatives for limiting OpenReplicator use of shared FA director ports that can be changed beforeand during a migration: the ceiling parameter which limits fibrebandwidth that can be used by Open Replicator, the pace parameterwhich defines delays added between Open Replicator operations, andthe nocopy mode which suspends Open Replicator background copyactivity.



A.5.2.1 Ceiling The ceiling parameter is the primary and most predictable tuningmechanism because it directly sets a maximum FA director portbandwidth that can be used by Open Replicator. The default ceilingvalue is NONE, theoretically allowing Open Replicator to use up to 100percent of the FA port bandwidth. Setting the ceiling value to any valueless than 100 percent limits the potential Open Replicator use of the FAport, and overrides any setting of the pace value. This value can be setprior to the migration or changed at any time during the migration. Acommand can be used to set the same ceiling value for all FA ports, orthe ceiling value for each FA port can be set independently. If theproduction applications have time of day or week variations that mighttolerate or suffer more from a higher contention for resources at certaintimes, then the ceiling value can be dynamically adjusted. Note that thecommand that lists ceiling values, also displays the current OpenReplicator use of bandwidth, effectively reporting whether all thecapacity up to the current ceiling value is actually being used.

A.5.2.2 Pace The pace parameter limits the use of all FA ports used for a particularOpen Replicator session by inserting delays between Open ReplicatorI/O requests. Although this effectively limits use of the FA port, it alsoguarantees that the migration will take longer, even if there is sparecapacity in the FA port. The range of valid values is from 0 to 10, with adefault value of 5. A pace setting of zero does not insert any delay. Avalue of 10 inserts the maximum delay. The parameter value can bedisplayed using the -detail option with the query or list actions.The PPME throttle setting is an alternate interface to the OpenReplicator pace setting. The pace value is ignored for all participatingdirector/port combinations where the ceiling value is not NONE.

A.5.2.3 Nocopymode

The ability to dynamically switch an Open Replicator session intonocopy mode provides a simple way to temporarily suspend all butCOFx migration I/O requests. The most common use of nocopy mode isto initially set a hot pull session in nocopy mode so that initial highCOFA I/O is not joined by any background copy I/O. This setting hasto be temporary because it is necessary to set the mode back tobackground copy in order for the migration to complete with all trackscopied to the target. The current mode setting can be determined byinterpreting the C flag setting displayed in the output of the query orlist actions.



A.6 Monitoring Open Replicator performanceFor this monitoring session, a hot push session using the same devicesas in Section 7.6, “Setup step 5, prepare Open Replicator session pairsfile,” on page 166 was created with ceiling set to 10 percent.

A.6.1 symrcopy queryOpen Replicator performance can be monitored using the symrcopyquery command or SMC equivalent as shown in previous chapters.The change from one query output to the next can be used as aperformance measure combined with elapsed time. The decrease in thenumber of Protected Tracks, or the increase in Done % are thechanging values. For example, soon after activating the session, thequery output could look something like this:

c:\>symrcopy -session hot_push query

Session Name : hot_push

Control Device Remote Device Flags Status Done--------------------------- --------------------- ----- ---------- ----

ProtectedSID:symdev Tracks Identification RI CDSHU CTL<=>REM (%)----------------- --------- ------------------ -- ----- ---------- ----000190300359:0098 65072 000187720450:0144 SD XXXX. CopyInProg 0000190300359:0097 64862 000187720450:0143 SD XXXX. CopyInProg 1000190300359:0096 64752 000187720450:0142 SD XXXX. CopyInProg 1000190300359:0095 64862 000187720450:0141 SD XXXX. CopyInProg 1

Total ---------Track(s) 259548

. . .



A.6.2 symrcopy list ceilingThe output of symrcopy list ceiling can be used to show theactual MB/sec used by Open Replicator for each director. In theexample below, the ceiling setting for directors 2C:0 and 15C:0 is 10percent. The maximum MB/sec for each FA director port is 150MB/sec. The actual MB/sec displayed in the example is 15 and 14MB/sec, equivalent within rounding error to 10 percent of 150 MB/secor 15 MB/sec. Therefore in this case the ceiling setting is limiting theOpen Replicator throughput.

c:\>symrcopy -sid 359 list ceiling




c:\>



A.6.3 symstat with -RepType rcopyThe symstat command has three status actions that use the OpenReplicator specific -RepType rcopy option. The first example usesthe -type REQUESTS option. The short interval of 10 seconds (-i 10)and count of 3 (-c 3) quickly generate two sets of calculated deltaoutput. Best practice would use a much longer interval to both providemore meaningful data and to avoid more frequent polling forperformance data than really necessary. Notice the values for PUSHKB/sec for each of the four control devices.

c:\>symstat -type REQUESTS -sid 359 -reptype rcopy -i 10 -c 3

RCopy--------------

Device KB/sec14:19:11 PULL PUSH

14:19:21 0095 (DRIVE15) 0 89080096 (DRIVE16) 0 94140097 (DRIVE17) 0 58040098 (DRIVE18) 0 6457

14:19:31 0095 (DRIVE15) 0 96640096 (DRIVE16) 0 88570097 (DRIVE17) 0 57980098 (DRIVE18) 0 5817

c:\>The second symstat example uses the -dir ALL option, which couldalso have specified an individual director. Notice the Open Replicatorcache usage for directors 2C and 15C.

c:\>symstat -dir all -sid 359 -reptype rcopy -i 10 -c 3

RCopy Cache Requests/sec %RW14:19:38 Director MB/sec READ WRITE RW Hits

14:19:49 FA-1C 0 0 0 0 N/AFA-2C 14 283 0 283 71FA-15C 14 280 0 280 69FA-16C 0 0 0 0 N/A

------ ------ ------ ------ ---28 563 0 563 139

14:19:59 FA-1C 0 0 0 0 N/AFA-2C 15 275 0 275 45FA-15C 14 276 0 276 43FA-16C 0 0 0 0 N/A

------ ------ ------ ------ ---29 551 0 551 87

c:\>



The third symstat example uses the -type PATH option, which hastwo sorting options; -by_session is used here. Notice the total andremaining 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 RCopyStamp Name Device Destination Total Remaining Port Ceiling

14:20:49 hot_pu* 0095 000187720450:0141 65535 51048 FA-2C:0 10N/A 65535 51048 FA-15C:0 10

hot_pu* 0096 000187720450:0142 65535 50995 FA-2C:0 10N/A 65535 50995 FA-15C:0 10

hot_pu* 0097 000187720450:0143 65535 54568 FA-2C:0 10N/A 65535 54568 FA-15C:0 10

hot_pu* 0098 000187720450:0144 65535 54708 FA-2C:0 10N/A 65535 54708 FA-15C:0 10

Time Session Control Target Tracks Director RCopyStamp Name Device Destination Total Remaining Port Ceiling

14:20:59 hot_pu* 0095 000187720450:0141 65535 49689 FA-2C:0 10N/A 65535 49689 FA-15C:0 10

hot_pu* 0096 000187720450:0142 65535 49696 FA-2C:0 10N/A 65535 49696 FA-15C:0 10

hot_pu* 0097 000187720450:0143 65535 53567 FA-2C:0 10N/A 65535 53567 FA-15C:0 10

hot_pu* 0098 000187720450:0144 65535 53556 FA-2C:0 10N/A 65535 53556 FA-15C:0 10

c:\>



The fourth symstat example again uses the -type PATH option, thistime using the -by_port sorting option. In addition to the total andremaining tracks to be copied per device, the MB/sec transfer rate islisted 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 SessionStamp 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 SessionStamp 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:\>



A.7 Tuning for applications sensitive to response timeIn order to maintain the activate point-in-time, Open Replicator hotmigration COFx I/Os will occur even if background copy migrationactivity is already using the allowed ceiling percentage of FA portbandwidth. An example of a production application that is sensitive toresponse time is MicroSoft Cluster Server (MSCS). MSCS performsfrequent SCSI reservation queries on its LUNs, to ensure that the activenodes still have SCSI reservations on the LUNs in order to prevent asplit brain cluster. If a particular active MSCS node sees that it has lostits SCSI reservation, or does not receive an acknowledgement that itstill has a reservation quickly enough, it will take its resources offline toprevent data corruption due to a split brain. Excessive COFx activity onFA ports that do not have enough bandwidth can slow down these SCSIreservation responses to a point that MSCS will go offline.

The Open Replicator migration use of bandwidth can be mitigated witha number of tuning strategies. For hot push, precopy should be utilizedreducing COFW I/Os at activate time. Sessions should initially be innocopy mode, and only switched to background copy mode, once COFxactivity starts to slow down. Start with a relatively low ceiling (15-20%),and then gradually increase the ceiling, keeping a close watch on hostI/Os per second (IOPS) and response time avoiding allowing OpenReplicator to affect the production applications' response times toomuch.


Troubleshooting

B

This appendix provides log information that correlates with theexamples presented in chapters 4-9. Log examples are shown forcommands resulting in both success and failure. Also included is anexample of an Enginuity 5773 enhancement of Open Replicator thatenables reactivating a failed differential push session. The topicscovered include:

◆ B.1 Solutions Enabler logs............................................................... 232◆ B.2 Audit Log.................................................................................... 239◆ B.3 PowerPath Migration Enabler (PPME) logs .......................... 241◆ B.4 Reactivate Failed Session.......................................................... 244

Troubleshooting 231

Troubleshooting

B.1 Solutions Enabler logsThe Solutions Enabler log directory is a subdirectory of the workingsolutions enabler directory. If the default directories were used forSolutions 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 thisTechBook: symapi-YYYYMMDD.log and symntctl-YYYYMMDD.log.

B.1.1 Cold push example log entriesFor example, the log entries related to operations in Chapter 4, “ColdPush to CLARiiON Setup Example,” and Chapter 5, “Cold Push toCLARiiON Migration Example,” are displayed in the next eightsubsections.


Troubleshooting

B.1.1.1 Open Replicator create and not_ready control devicesThe following excerpt from the symapi-20080618.log andsymapi-20080619.log corresponds to the example shown in Section4.6.5, “Verify all with symrcopy create,” on page 79:

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 ondev:00A0, sid:000190300359, it is not NR06/18/2008 16:17:03.854 1896 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operationFAILED. (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: 000190300359director: 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_STATUS06/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.511 1915 1 EMC:SYMCLI SymDevListControl() symdev list: symid: 000190300359director: N/A, port: N/A ()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,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_STATUS06/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.06/18/2008 16:22:00.565 1920 STARTING a 'NOT_READY' control operation.06/18/2008 16:22:00.569 1920 1 EMC:SYMCLI SymDevListControl() symdev list: symid: 000190300359director: N/A, port: N/A ()06/18/2008 16:22:00.612 1920 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_STATUS06/18/2008 16:22:00.630 1920 Set device(s) Not Ready at local Symmetrix.................Done.06/18/2008 16:22:00.649 1920 The 'NOT_READY' control operation SUCCEEDED.. . .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:0xa006/19/2008 16:59:53.143 2545 1 EMC:SYMRCOPY doPaceOnDev Setting throttle to 0xff, dev:0xa106/19/2008 16:59:53.147 2545 1 EMC:SYMRCOPY doPaceOnDev Setting throttle to 0xff, dev:0xa206/19/2008 16:59:53.151 2545 1 EMC:SYMRCOPY doPaceOnDev Setting throttle to 0xff, dev:0xa306/19/2008 16:59:53.172 2545 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operation SUCCEEDED.

Troubleshooting 233

Troubleshooting

B.1.1.2 TimeFinder/Mirror establish and Open Replicator terminateThe following excerpt from the symapi-20080624.log correspondsto the example shown in Section 5.2.2, “Initial TimeFinder/Mirrorestablish,” on page 89:

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 state06/24/2008 18:21:30.927 4327 1 EMC:SYMMIR evaluate_dev BCV Device: 0081 (000190300359)is an RCOPY push source in created/recreated state06/24/2008 18:21:30.927 4327 1 EMC:SYMMIR evaluate_dev BCV Device: 0082 (000190300359)is an RCOPY push source in created/recreated state06/24/2008 18:21:30.927 4327 1 EMC:SYMMIR evaluate_dev BCV Device: 0083 (000190300359)is an RCOPY push source in created/recreated state 06/24/2008 18:22:20.621 4332 1 EMC:SYMRCOPYSymRemoteCopyControl STARTING a REMOTE Copy TERMINATE06/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' operationSUCCEEDED.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: MultiEstablish06/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.

B.1.1.3 TimeFinder/Mirror splitThe following excerpt from the symapi-20080624.log correspondsto the example shown in Section 5.2.3, “TimeFinder/Mirror split,” onpage 90:

06/24/2008 18:46:36.231 4347 1 EMC:SYMMIR SymDgBcvControl() dg: cpgroup, ldev: , SymID:000190300359, 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: MultiNone06/24/2008 18:46:36.284 4347 Source-Target Devices: [ 00A0-0080 00A1-0081 00A2-0082 00A3-0083 ]06/24/2008 18:46:42.755 4347 The BCV 'SPLIT' operation SUCCEEDED.

B.1.1.4 Open Replicator create and not_ready control devices repriseThe following excerpt from the symapi-20080624.log correspondsto the examples shown in Section 5.3.1, “Cold control devices must beNot Ready,” on page 92 and Section 5.3.2, “Create action options,” onpage 93:

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 ondev:0080, sid:000190300359, it is not NR06/24/2008 18:46:56.405 4350 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operationFAILED. (SYMAPI_C_INV_DEVICE_RDY_STATUS)06/24/2008 18:47:55.248 4354 STARTING a 'NOT_READY' control operation.06/24/2008 18:47:55.249 4354 1 EMC:SYMCLI SymDgControl() grp: cpgroup symid: 000190300359ldev: director: N/A, port: N/A ()06/24/2008 18:47:55.292 4354 1 EMC:SYMCLI test_dev_state() TestState: DEV_STATE_NOT_READY_DEVICE,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: NeverEstab, InvR1: 0, InvR2: 0, R2WPonR1: 0 Mode:SYN, Dom: ENB, ACp: OFF, API sts: SYMAPI_C_INV_DEVICE_RDY_STATUS06/24/2008 18:47:55.312 4354 Set device(s) Not Ready at local Symmetrix.................Done.06/24/2008 18:47:55.336 4354 The 'NOT_READY' control operation SUCCEEDED.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.


Troubleshooting

B.1.1.5 Open Replicator activate and set ceilingThe following excerpt from the symapi-20080624.log correspondsto the examples shown in Section 5.4, “Migration step 10, symrcopyactivate,” on page 96 and Section 5.5, “Migration step 12, symrcopy setceiling,” on page 97:

06/24/2008 21:45:44.987 1646 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy ACTIVATE06/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' operationSUCCEEDED.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' operationSUCCEEDED.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' operationSUCCEEDED.

B.1.1.6 TimeFinder/Mirror incremental update of control devicesThe following excerpt from the symapi-20080625.log correspondsto the example shown in Section 5.7.1, “Incrementally update controldevices from production devices,” on page 100:

06/25/2008 10:45:14.430 1991 1 EMC:SYMMIR SymDgBcvControl() dg: cpgroup, ldev: , SymID:000190300359, symdev: , bcvdev: , flags: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: MultiEstablish06/25/2008 10:45:14.491 1991 Source-Target Devices: [ 00A0-0080 00A1-0081 00A2-0082 00A3-0083 ]06/25/2008 10:45:14.873 1991 The BCV 'INCREMENTAL_ESTABLISH' operation SUCCEEDED.06/25/2008 10:55:23.813 2019 1 EMC:SYMMIR SymDgBcvControl() dg: cpgroup, ldev: , SymID:000190300359, symdev: , bcvdev: , flags: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: MultiNone06/25/2008 10:55:23.869 2019 Source-Target Devices: [ 00A0-0080 00A1-0081 00A2-0082 00A3-0083 ]06/25/2008 10:55:25.243 2019 The BCV 'SPLIT' operation SUCCEEDED.06/25/2008 10:56:21.916 2028 STARTING a 'NOT_READY' control operation.06/25/2008 10:56:21.917 2028 1 EMC:SYMCLI SymDgControl() grp: cpgroup symid: 000190300359ldev: director: N/A, port: N/A ()06/25/2008 10:56:21.969 2028 1 EMC:SYMCLI test_dev_state() TestState: DEV_STATE_NOT_READY_DEVICE,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_STATUS06/25/2008 10:56:21.987 2028 Set device(s) Not Ready at local Symmetrix.................Done.06/25/2008 10:56:22.012 2028 The 'NOT_READY' control operation SUCCEEDED.

Troubleshooting 235

Troubleshooting

B.1.1.7 Open Replicator incremental update of remote devicesThe following excerpt from the symapi-20080625.log correspondsto the example shown in Section 5.7.2, “Incrementally update remotedevices from control devices,” on page 101:

06/25/2008 10:56:36.792 2031 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy RECREATE06/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' operationSUCCEEDED.06/25/2008 10:57:05.256 2034 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy ACTIVATE06/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' operationSUCCEEDED.

B.1.1.8 Open Replicator terminate and make source devices inaccessibleThe following excerpt from the symapi-20080625.log andsymapi-20080709.log corresponds to the examples shown inSection 5.8, “Migration step 15, verify migration and symrcopyterminate,” on page 104 and Section 5.9, “Cleanup step 16, make sourcedevices host inaccessible,” on page 106:

06/25/2008 13:24:30.940 2136 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy TERMINATE06/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' operationSUCCEEDED.. . .07/09/2008 01:46:10.902 3594 1 EMC:SYMMASK emcSetupLunMaskSessi Skipping call to emcSymLockSym07/09/2008 01:56:15.452 3614 1 EMC:SYMMASK SymDevMaskSessionSta Successfully started a Symmetrixdevice masking session for Symmetrix 000190300359 with devmask handle 10007/09/2008 01:56:15.594 3614 1 EMC:SYMMASK emcAddorRemoveDevice Removing the following devicesfrom the device masking database for Symmetrix 000190300359 by WWN 210000e08b927df4 for director 34 for port 007/09/2008 01:56:15.681 3614 1 EMC:SYMMASK SymDevMaskSessionEnd Successfully ended a Symmetrixdevice masking session for Symmetrix 00019030035907/09/2008 01:57:16.415 3621 1 EMC:SYMMASK SymDevMaskSessionSta Successfully started a Symmetrixdevice masking session for Symmetrix 000190300359 with devmask handle 10007/09/2008 01:57:16.538 3621 1 EMC:SYMMASK emcAddorRemoveDevice Removing the following devicesfrom the device masking database for Symmetrix 000190300359 by WWN 210000e08b925cf5 for director 47 for port 007/09/2008 01:57:16.613 3621 1 EMC:SYMMASK SymDevMaskSessionEnd Successfully ended a Symmetrixdevice masking session for Symmetrix 00019030035907/09/2008 01:57:31.990 3624 1 EMC:SYMMASK SymDevMaskSessionSta Successfully started a Symmetrixdevice masking session for Symmetrix 000190300359 with devmask handle 10007/09/2008 01:57:33.262 3624 1 EMC:SYMMASK SymDevMaskControl Refreshing FAs with contents ofdevice masking database for Symmetrix 00019030035907/09/2008 01:57:33.319 3624 1 EMC:SYMMASK SymDevMaskSessionEnd Successfully ended a Symmetrixdevice masking session for Symmetrix 00019030035907/09/2008 01:58:34.652 3633 1 EMC:SYMMASK emcSetupLunMaskSessi Skipping call to emcSymLockSym07/09/2008 01:59:13.635 3636 1 EMC:SYMMASK emcSetupLunMaskSessi Skipping call to emcSymLockSym


Troubleshooting

B.1.2 Hot pull example log entriesThe log entries related to Chapter 6, “Hot Pull from CLARiiONMigration Example,” are very similar to the ones shown for the coldpush operation above. Therefore only the error related log entries formissing zoning and missing masking are displayed in the followingsections.

B.1.2.1 Missing zoning errorThe following excerpt from the symapi-20080717.log correspondsto the example shown in Section 6.7.1, “Discover missing zoning withsymrcopy create,” on page 124:

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_FAILED07/17/2008 09:36:21.250 2328 3852 EMC:SYMRCOPY map_discover_erro loc_dir:02C, rem_num:0,rem_sts:0x1SANCOPY_DEV_SUCCESS07/17/2008 09:36:21.250 2328 3852 EMC:SYMRCOPY map_discover_erro loc_dir:15C, rem_num:0,rem_sts:0xaSANCOPY_DEV_NO_REMOTE_TARGETS07/17/2008 09:36:21.250 2328 3852 EMC:SYMRCOPY checkForCreateFai Discover failed on dev:0091,sid:000190300359, status:1009007/17/2008 09:36:22.328 2328 3852 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operationFAILED. (SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)

B.1.2.2 Missing masking errorThe following excerpt from the symapi-20080717.log correspondsto the example shown in Section 6.7.3, “Discover missing LUN maskingwith symrcopy create,” on page 126:

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_FAILED07/17/2008 11:16:18.890 2784 2780 EMC:SYMRCOPY map_discover_erro loc_dir:02C, rem_num:0,rem_sts:0x1SANCOPY_DEV_SUCCESS07/17/2008 11:16:18.890 2784 2780 EMC:SYMRCOPY map_discover_erro loc_dir:15C, rem_num:0,rem_sts:0x6SANCOPY_DEV_WWID_NOT_FOUND07/17/2008 11:16:18.890 2784 2780 EMC:SYMRCOPY checkForCreateFai Discover failed on dev:0091,sid:000190300359, status:1009007/17/2008 11:16:19.953 2784 2780 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operationFAILED. (SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)

Troubleshooting 237

Troubleshooting

B.1.2.3 Stopping and restarting application using the targetsThe following excerpt from the symntctl-20080717.logcorresponds to the examples shown in Section 6.8, “Migration step 9,Stop the applications,” on page 129 and Section 6.10, “Migration step11, Restart applications using targets,” on page 132:

07/17/08 16:13:51InitLog Symntctl Log Opened07/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 TRUE07/17/08 16:13:51IsVolumeReady TRUE07/17/08 16:13:51IsVolumeClustered Enter IsVolumeClustered()07/17/08 16:13:51CreateFile Enter CreateFile()07/17/08 16:13:51DeviceIoControl IOCTL_VOLUME_IS_CLUSTERED07/17/08 16:13:51DeviceIoControl WIN32 Error: 1 Incorrect function.07/17/08 16:13:51IsVolumeClustered SYMNTCTL Error: 1 The operationfailed.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_VOLUME07/17/08 16:13:51FlushFileBuffers Enter FlushFileBuffers()07/17/08 16:13:51DeviceIoControl FSCTL_DISMOUNT_VOLUME07/17/08 16:13:51IoctlUnmount Successfully dismounted the volume.07/17/08 16:13:51DeviceIoControl IOCTL_VOLUME_OFFLINE07/17/08 16:13:51IoctlUnmount Successfully took the volume offline.07/17/08 16:13:51DeviceIoControl FSCTL_UNLOCK_VOLUME07/17/08 16:13:51DeleteVolumeMountPoint Enter DeleteVolumeMountPoint()07/17/08 16:13:51IoctlUnmount Successfully removed all access pathsto 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

B.2 Audit LogData is written to a common audit file during Symmetrix controloperations initiated by host applications. The common audit logcorrelates activity from all hosts into one file that is stored in theSymmetrix. The symaudit command and the SMC Symmetrix Admin- SymAudit Records display can be used to filter and display thecommon audit log file for a specified Symmetrix array.

The symaudit list example below filters for Open Replicatoractions on 07/17/2008. The records briefly listed below correspond tothe examples shown in Section 6.7.5, “Successful create verifies hot pullsetup,” on page 128 and Section 6.9, “Migration step 10, symrcopyactivate,” on page 131:

c:\>symaudit list -sid 359 -function_class rcopy -start_date 07/17 -end_date07/18

A U D I T L O G D A T A


Record Function ActionNumber Date Time Application Host Class Code------ -------- -------- ---------------- ------------ -------- ---------

8849 07/17/08 12:27:09 SYMRCOPY LICOD194 RCopy Create8850 07/17/08 12:27:09 SYMRCOPY LICOD194 RCopy Create8851 07/17/08 12:27:10 SYMRCOPY LICOD194 RCopy Create8861 07/17/08 17:21:03 SYMRCOPY LICOD194 RCopy Activate8862 07/17/08 17:21:03 SYMRCOPY LICOD194 RCopy Activate8863 07/17/08 17:21:03 SYMRCOPY LICOD194 RCopy Activate

. . .

c:\>

Troubleshooting 239

Troubleshooting

Using the -v option shows details of each audit log record. Forexample, details for the three Create audit log entries numbered8849-8851:

c:\>symaudit list -sid 359 -v -record_num 8849 -n 3

A U D I T L O G D A T ASymmetrix ID : 000190300359

Record Number : 8849Records in Seq : 2Offset in Seq : 1Time : 07/17/08 12:27:09Vendor ID : EMC CorpApplication ID : SYMRCOPYApplication Version : 6.5.1.0API Library : SEKAPI Version : V6.5.1.0 (Edit Level: 882)Host Name : LICOD194OS Name : WinNTOS Revision : 5.2.3790SeClient Host :Process ID : 00003728Task ID : 00003732Function Class : RCopyAction Code : CreateText : STARTING a RCopy 'CREATE' operation for Device List. O

ptions=(Hot, Pull, CopyMode, DonorUpdate)Username : H:LICOD194\AdministratorActivity ID : SE1ceeb91751

Record Number : 8850Records in Seq : 2Offset in Seq : 2Time : 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 ]Username : H:LICOD194\AdministratorActivity ID : SE1ceeb91751

Record Number : 8851Records in Seq : 1Offset in Seq : 1Time : 07/17/08 12:27:10

. . .Text : The Rcopy 'CREATE' operation SUCCESSFULLY COMPLETED.Username : H:LICOD194\AdministratorActivity ID : SE1ceeb91751

c:\>


Troubleshooting

B.3 PowerPath Migration Enabler (PPME) logsPowerPath Migration Enabler (PPME) can log audit and error logmessages to a common file. The PowerPath Migration Enabler User Guideincludes details on how to configure the Solaris host syslog.conf(4)file to write local0.info messages to a common log file. OnWindows hosts these messages appear in the Event Log without anyadditional configuration.

Figure 79 shows the Windows Computer Management screen with theEvent Viewer selected so that Application Events are displayed. Theselected entry is of type Error and the source is EmcpLogMsgs whichincludes PPME messages

Figure 79 Windows Event Viewer with PPME error message selected

ICO-IMG-000590

Troubleshooting 241

Troubleshooting

Double-clicking on the selected row or selecting the menu itemsActionProperties displays the details of the message in Figure 80,which shows the missing PPME license corresponding to Section 9.3.2,“PPME license required,” on page 207.

Figure 80 Event Properties detail for missing PPME license

ICO-IMG-000591


Troubleshooting

Figure 81 shows part of the Event Viewer screen with an informationalPPME message selected.

Figure 81 Windows Event Viewer with PPME error message selected

Figure 82 shows the Event Properties detail for a powermig setupcommand that was executed in Section 9.3, “PPME Setup steps 5-6,powermig setup,” on page 205.

Figure 82 Event Properties detail for missing PPME license

ICO-IMG-000592

ICO-IMG-000593

Troubleshooting 243

Troubleshooting

B.4 Reactivate Failed SessionPrior to Enginuity 5773, the state of the Open Replicator session was setto Failed if a transient network or device issue was encountered. Theonly option available from the Failed state was to terminate thesession. Enginuity version 5773 allows failed sessions to be reactivatedas long as certain criteria are met. Only sessions where no new data hasbeen written to the control device since the session failed can bereactivated.

If new data has been written, the session should be terminated. This isbecause when a hot push session fails, a write to the control devicesucceeds, as does a full track write on a failed hot pull session. Thiscould lead to a situation where data on the control device that still needsto be pulled or pushed is not part of the initial point-in-time.Reactivating the Open Replicator session in these circumstances mayresult in data being overwritten on the control device on a pull orinconsistent data being written to the remote device on a push.

In the example shown below, the same Open Replicator device pairs inChapter 7, “Hot Pull from Symmetrix Migration Example,” were usedfor a hot push. The remote devices were made not_ready to simulate atransient failure. Notice the Status in the query output belowindicates both the failed state and that the failed session is eligible to bereactivated:




ProtectedSID:symdev Tracks Identification RI CDSHU CTL<=>REM (%)----------------- --------- ------------------ -- ----- ---------- ----000190300359:0098 29861 000187720450:0144 SD XXXX. Failed (*) N/A000190300359:0097 40786 000187720450:0143 SD XXXX. Failed (*) N/A000190300359:0096 42160 000187720450:0142 SD XXXX. Failed (*) N/A000190300359:0095 28459 000187720450:0141 SD XXXX. Failed (*) N/A

Total ---------Track(s) 141266MB(s) 8829.1

. . .Flags:. . .(*): The failed session can be reactivated.

c:\>


Troubleshooting

Once the transient error condition is corrected (in this case making theremote devices ready), the session can be reactivated. The syntax toreactivate the session is the same as that used to originally activatethe session:

c:\>symrcopy -session hot_push activate -consistent

Execute 'Activate' operation for the 4 specified deviceswith session name 'hot_push' (y/[n]) ? y

'Activate' operation execution is in progress for the device listwith session name 'hot_push'. Please wait...

'Activate' operation successfully executed for the device listwith session name 'hot_push'.

c:\>After a short delay, the query action is repeated and the results showthat the Status has changed back to CopyInProg. Additionally, theProtected Tracks values have decreased and the Done % valueshave increased showing that the copy session is closer to completion:




ProtectedSID:symdev Tracks Identification RI CDSHU CTL<=>REM (%)----------------- --------- ------------------ -- ----- ---------- ----000190300359:0098 23936 000187720450:0144 SD XXXX. CopyInProg 63000190300359:0097 34565 000187720450:0143 SD XXXX. CopyInProg 47000190300359:0096 31869 000187720450:0142 SD XXXX. CopyInProg 51000190300359:0095 22604 000187720450:0141 SD XXXX. CopyInProg 65

Total ---------Track(s) 112974MB(s) 7060.9

. . .c:\>

Troubleshooting 245

Troubleshooting


Glossary

This glossary contains terms related to disk storage subsystems. Manyof these terms are used in this guide.

Aadministrator A person responsible for administrative tasks such as access

authorization and content management. Administrators can also grantlevels of authority to users.

agent A software entity that runs on endpoints and provides managementcapability 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 systemmainly to test the adequacy and effectiveness of procedures for datasecurity and data accuracy.

authority The right to access objects, resources, or functions.

Bbackup 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 computerdata that can be used to recreate data that has been lost, mislaid,corrupted or erased.

bandwidth A measure of the data transfer rate of a transmission channel.


Glossary

Ccache 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-definingrecord formats in which each record is represented by a count area thatidentifies the record and specifies its format, an optional key area thatmay be used to identify the data area contents, and a data area thatcontains the user data for the record. CKD can also refer to a set ofchannel commands that are accepted by a device that employs the CKDrecording format.

CLI See “Command Line Interface (CLI).”

client A function that requests services from a server, and makes themavailable to the user. A term used in an environment to identify amachine that uses the resources of the network. See also “client-server.”

client-server In TCP/IP, the model of interaction in distributed data processing inwhich a program at one site sends a request to a program at another siteand awaits a response. The requesting program is called a client; theanswering program is called a server.

client-serverrelationship

Any process that provides resources to other processes on a network isa server. Any process that employs these resources is a client. Amachine 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 mustbe offline to the host application. See also “hot operation.”

Command LineInterface (CLI)

A mechanism for interacting with a computer operating system orsoftware by typing commands to perform a given task, referred to as“entering” a command: the system waits for the user to conclude thesubmitting of the text command by pressing the Enter key. A commandline interpreter then receives, analyses, and launches the requestedcommand. Upon completion, the command usually returns output tothe user in the form of text lines on the CLI.


Glossary

connection In TCP/IP, the path between two protocol applications that providesreliable data stream delivery service. In Internet communications, aconnection extends from a TCP application on one system to a TCPapplication on another system.

consistent copy A copy of data entity (for example, a logical volume) that contains thecontents of the entire data entity from a single instant in time.

console A user interface to a server. That part of a computer used forcommunication between the operator or user and the computer.

control side The Symmetrix DMX, where Open Replicator runs, and its devices arealways referred to as the control side of the copy operation.

copy on firstaccess (COFA)

The Open Replicator copying of not-yet copied data from the remote tothe 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 tothe remote when an application first attempts a write to the location ofthat data.

Ddata availability Access to any and all user data by the application.

data integrity The condition that exists as long as accidental or intentionaldestruction, alteration, or loss of data does not occur.

data migration The one-time movement of data from source to target, where the datawill subsequently only be accessed at the target.

default A value, attribute, or option that is assumed when no alternative isspecified by the user.


Glossary

dependent-writeconsistency

A data state where data integrity is guaranteed by dependent-writeI/Os embedded in application logic. Database management systemsare good examples of applications that utilize the dependent-writeconsistency strategy. Database management systems must deviseprotection against abnormal termination in order to successfullyrecover from one. The most common technique used is to guaranteethat a dependent write cannot be issued until a predecessor write hascompleted. Typically the dependent write is a data or index write whilethe predecessor write is a write to the log. Because the write to the logmust be completed prior to issuing the dependent write, the applicationthread is synchronous to the log write (that is, it waits for that write tocomplete prior to continuing). The result of this kind of strategy is adependent-write consistent database.

dependent-writeI/O

An I/O that cannot be issued until a related predecessor I/O hascompleted. Most applications, and in particular database managementsystems (DBMS), have embedded dependent-write logic to ensure dataintegrity in the event of a failure in the host or server processor,software, storage subsystem, or if an environmental power failureoccurs. 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 Symmetrixto transfer data between the host channels and disk devices.

directory (1) A type of file containing the names and controlling information forother files or other directories. Directories can contain subdirectories,which can contain subdirectories of their own. (2) A file that containsdirectory entries. No two directory entries in the same directory canhave the same name. (POSIX.1). (3) A file that points to files and toother directories.

disaster recovery The process of restoring a previous copy of the data and applying logsor other necessary processes to that copy to bring it to a known point ofconsistency.

disk director The component in the Symmetrix subsystem that interfaces betweencache and the disk devices.


Glossary

EEnterprise Systems

Connection(ESCON)

A set of products and services that provides a dynamically connectedenvironment using optical cables as a transmission medium.

ESCON Enterprise Systems Connection architecture; a set of IBM and vendorproducts that connect mainframe computers with each other and withattached storage, locally attached workstations, and other devices usingoptical fiber technology and dynamically modifiable switches calledESCON directors.

Ffabric 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 usedto describe a more complex network utilizing hubs, switches, andgateways.

FBA Fixed Block Architecture, disk device data storage format usingfixed-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 ofinformation along a glass or plastic wire or fiber.

Fibre Channel A technology for transmitting data between computer devices at a datarate of up to 4 Gbps. It is especially suited for connecting computerservers to shared storage devices and for interconnecting storagecontrollers and drives.

Fibre Channelprotocol

The serial SCSI command protocol used on Fibre Channel networks.

Fibre Channelstandard

An ANSI standard for a computer peripheral interface. The I/Ointerface defines a protocol for communication over a serial interfacethat configures attached units to a communication fabric. Refer to ANSIX3.230-199x.


Glossary

FICON An I/O interface based on the Fibre Channel architecture. In this newinterface, the ESCON protocols have been mapped to the FC-4 layer,that is, the Upper Level Protocol layer, of the Fibre Channel Protocol. Itis 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 bemonitored and extended. Policy values defined at this level overridethose that might be defined at higher levels.

front-end director The component in the Symmetrix subsystem that interfaces with hostbus adapters (HBAs). It transfers data between the host and Symmetrixcache.

Ggatekeeper 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 persecond, as defined by the IEEE 802.3-2005 standard.

gigabyte (GB) 109 bytes.

Graphical UserInterface (GUI)

A type of user interface which allows people to interact with acomputer and computer-controlled devices. It presents graphical icons,used in conjunction with text, labels or text navigation to fully representthe information and actions available to a user. But instead of offeringonly text menus, or requiring typed commands, the actions are usuallyperformed through direct manipulation of the graphical elements.

GUI See ”Graphical User Interface (GUI).”

Hhardware 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 thefabric switch. Zoning can be implemented in the followingconfigurations: one to one, one to many, and many to many.

HBA See ”host bus adapter.”


Glossary

highly parallel Refers to multiple systems operating in parallel, each of which can havemultiple processors.

host Any system that has at least one Internet address associated with it. Ahost with multiple network interfaces can have multiple Internetaddresses 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 tothe SAN network.

host not ready In this state, the volume responds not ready to the host for all read andwrite operations to that volume.

hot operation Open Replicator mode where the Symmetrix DMX control device canremain online to the host application.

hypervolume A user-defined storage device allocated within a Symmetrix physicaldisk.

hyper-volumeextension

The ability to define more than one logical volume on a single physicaldisk device making use of its full formatted capacity. These logicalvolumes are user-selectable in size. The minimum volume size is onecylinder and the maximum size depends on the disk device capacityand the emulation mode selected.

II/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 anInternet environment.

KKB Kilobyte, 1024 bytes.

Llocal volumes Volumes that reside on an Symmetrix system but do not participate in

SRDF activity.

logical unit number(LUN)

A volume identifier that is unique among all storage servers. The LUNis synonymous with a physical disk drive or a SCSI device. For disksubsystems such as the IBM Enterprise Storage Server, a LUN is a


Glossary

logical disk drive (a unit of storage on the SAN which is available forassignment or unassignment to a host server). The LUNs are providedby 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. Intelligentdisk subsystems provide this kind of masking.

LUN See ”logical unit number (LUN).”

MMB Megabyte, 106 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 twodifferent physical devices.

mirroring The Symmetrix maintains two identical copies of a designated volumeon separate disks. Each volume automatically updates during a writeoperation. If one disk device fails, Symmetrix automatically uses theother disk device.

mirroring (RAID 1) The highest level of performance and availability for all mission-criticaland business-critical applications by maintaining a duplicate copy of avolume on two disk drives.

multipath device A device made visible to a host on more than one I/O path in order toimprove both fault tolerance (failover) and performance (loadbalancing).

multiprocessing The simultaneous execution of two or more computer programs orsequences of instructions. See also “parallel processing.”

multiprocessor(MP)

A CPC that can be physically partitioned to form two operatingprocessor complexes.


Glossary

Nnative device

nameA path-specific device name provided by the host operating system thatrepresents a single path to a logical device. See also “pseudo devicename.”

network topology A physical arrangement of nodes and interconnecting communicationlinks in networks based on application requirements and geographicaldistribution of users.

Oopen system A system whose characteristics comply with standards made available

throughout the industry, and therefore can be connected to othersystems that comply with the same standards.

operating system(OS)

Software that controls the execution of programs and that may provideservices such as resource allocation, scheduling, input/output control,and data management. Although operating systems are predominantlysoftware, partial hardware implementations are possible.

Pparallel processing The simultaneous processing of units of work by many servers. The

units of work can be either transactions or subdivisions of large units ofwork (batch). See also “highly parallel.”

password A unique string of characters known to a computer system and to auser, who must specify the character string to gain access to a systemand to the information stored within it.

point ofconsistency

A point in time to which data can be restored and recovered or restartedand maintain integrity for all data and applications.

port An endpoint for communication between applications, generallyreferring to a logical connection. A port provides queues for sendingand receiving data. Each port has a port number for identification.When the port number is combined with an Internet address, it is calleda socket address.

port zoning In Fibre Channel environments, the grouping together of multiple portsto form a virtual private storage network. Ports that are members of agroup or zone can communicate with each other but are isolated fromports in other zones. See also “LUN masking” and ”zoning.”


Glossary

protocol The set of rules governing the operation of functional units of acommunication system if communication is to take place. Protocols candetermine low-level details of machine-to-machine interfaces, such asthe order in which bits from a byte are sent. They can also determinehigh-level exchanges between application programs, such as filetransfer.

pseudo devicename

A location-independent name that represents a single logical deviceand the path set leading to it. See also “native device name.”

pull operation A Open Replicator pull operation copies data to the control device fromthe remote device.

push operation A Open Replicator push operation copies data from the control deviceto the remote device.

RRAID Redundant array of inexpensive or independent disks. A method of

configuring multiple disk drives in a storage subsystem for highavailability and high performance.

RAID 0 A protection method where data is striped across several disks toincrease performance. Unless combined with RAID 1, does not nativelyprovide protection from data loss due to drive failure. See also “RAID10.”

RAID 1 A protection method that provides the highest level of performance andavailability for all mission-critical and business-critical applications bymaintaining a duplicate copy of a volume on two disk drives. See also“mirroring.”

RAID 5 A protection method that provides high performance with automaticstriping across hypervolumes. Lost hypervolumes are regenerated fromremaining members. RAID 5 is configured in (3+1) and (7+1) groups.RAID 5 technology stripes data and distributes parity blocks across allthe disk drives in the RAID group.

RAID 6 A protection method that supports the ability to rebuild data in theevent that two drives within the RAID group fail.

RAID 10 A protection method that combines RAID 1 and RAID 0; used inmainframe environments.


Glossary

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 transactionsrecorded in a log.

remote operations Operation of remote sites from a host system.

remote side The array and devices at the other side of an Open Replicator controlside Symmetrix DMX is referred to as the remote side. See also “controlside.”

restore A process that reinstates a prior copy of the data.

resynchronization A track image copy from the primary volume to the secondary volumeof only the tracks which have changed since the volume was last induplex mode.

SSAN See “storage area network.”

SCSI adapter Card in the Symmetrix subsystem that provides the physical interfacebetween the disk director and the disk devices.

SCSI reservation A method to claim or free ownership of a LUN using the standard SCSIReserve/Release protocol.

server A program running on a mainframe, workstation, or file server thatprovides shared services. This is also referred to as a host.

shared storage Storage within a storage facility that is configured such that multiplehomogeneous or divergent hosts can concurrently access the storage.The storage has a uniform appearance to all hosts. The host programsthat access the storage must have a common model for the informationon a storage device. Programs must be designed to handle the effects ofconcurrent access.

small computersystem interface

(SCSI)

An ANSI standard for a logical interface to computer peripherals andfor a computer peripheral interface. The interface utilizes a SCSI logicalprotocol over an I/O interface that configures attached targets andinitiators in a multi-drop bus topology.


Glossary

software zoning Is implemented within the Simple Name Server (SNS) running insidethe fabric switch. When using software zoning, the members of thezone can be defined with a node WWN, port WWN, or physical portnumber. Usually the zoning software also allows you to create symbolicnames for the zone members and for the zones themselves.

software (1) All or part of the programs, procedures, rules, and associateddocumentation of a data processing system. (2) A set of programs,procedures, and, possibly, associated documentation concerned withthe 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 “targetdevice.”

stage The process of writing data from a disk device to cache.

storageadministrator

A person in the data processing center who is responsible for defining,implementing, and maintaining storage management policies.

storage areanetwork

A managed, high-speed network that enables any-to-anyinterconnection of heterogeneous servers and storage systems.

switch A component with multiple entry and exit points or ports that providedynamic connection between any two of these points.

switch topology A switch allows multiple concurrent connections between nodes. Therecan be two types of switches; circuit switches and frame switches.Circuit switches establish a dedicated connection between two nodes.

Frame switches route frames between nodes and establish theconnection only when needed. A switch can handle all protocols.

Ttarget 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 tocommunicate. For example, point-to-point, arbitrated loop, andswitched fabric are all Fibre Channel topologies.


Glossary

transaction A unit of work performed by one or more transaction programs,involving a specific set of input data and initiating a specific process orjob.

transactionalconsistency

Transactional consistency is a DBMS state where all in-flighttransactions are either completed or rolled back.

transmissioncontrol protocol

A communications protocol used in the Internet and in any networkthat follows the Internet Engineering Task Force (IETF) standards forInternetwork protocol. TCP provides a reliable host-to-host protocolbetween hosts in packet-switched communications networks and ininterconnected systems of such networks. It uses the Internet Protocol(IP) as the underlying protocol.

Vvirtual storage (1) The storage space that can be regarded as addressable main storage

by the user of a computer system in which virtual addresses aremapped into real addresses. The size of virtual storage is limited by theaddressing scheme of the computer system and by the amount ofauxiliary storage available, not by the actual number of main storagelocations. (2) An addressing scheme that allows external disk storage toappear as main storage.

virtualization A technique for hiding the physical characteristics of computingresources from the way in which another function interacts with thoseresources.

volume A general term referring to a storage device. In the Symmetrixsubsystem, a volume corresponds to single disk device.

Wwait state Synonymous with waiting time.

waiting time (1) The condition of a task that depends on one or more events in orderto enter the ready condition. (2) The condition of a processing unitwhen all operations are suspended.

WAN Wide area network.


Glossary

web browser A software application which enables a user to display and interactwith text, images, videos, music and other information typically locatedon a Web page at a website on the World Wide Web or a local areanetwork. Web browsers communicate with Web servers primarily usingHTTP (hypertext transfer protocol) to submit information to Webservers as well as fetch Web pages from them.

world wide name A unique number assigned to Fibre Channel devices (including hostsand adapter ports). It is analogous to a MAC address on a networkcard.

WWN See “world wide name.”

Zzoning In Fibre Channel environments, zoning allows for finer segmentation of

the switched fabric. Zoning can be used to instigate a barrier betweendifferent environments. Ports that are members of a zone cancommunicate with each other but are isolated from ports in other zones.Zoning can be implemented in two ways: hardware zoning andsoftware zoning. See also “hardware zoning” and “software zoning.”


Index

AAuto-provisioning Groups 153

CCelerra

brief description 39CLARiiON

brief description 35discover 66display information about 66remote for cold push example 66remote for hot pull example 112

cleanup stepscold push example 84definition 61flowchart 61flowchart for PPME 202for hot pull 113for PPME 199

clustered hostsspecial considerations 64

colddefinition 23

cold pulldefinition 50replace with hot pull 51

cold pushcleanup example 83definition 47migration and cleanup steps flowchart 85migration example 83setup example 65

versus hot push 49Connectrix

brief description 37Connectrix Manager

brief description 37zoning verification screen 72, 126, 148

control sidedefinition 22

ControlCentersee EMC Ionix ControlCenter

createand SCSI reservations 55

cutoverdefinition 22

Ddata migration

definition 22selection model 25TechBook series 17

device maskingSymmetrix example 119Symmetrix SMC example 150

diskpart 135donor update

example 128explanation 50off (disable) 138, 185

EEMC Ionix ControlCenter

brief description 41


Enginuitydefinition 32

Ffront-end directors

defined 32

Hhot

definition 23hot pull

definition 49from CLARiiON example 111from Symmetrix example 139setup, migration, and cleanup flowchart 114

hot pushdefinition 46differences from cold push 104versus cold push 49

IICDA

see Integrated Cached Disk ArrayIntegrated Cached Disk Array

definition 32Invista


LLUN masking

for Symmetrix see device masking 150verify with Remote Report 173verify with symsan -sanluns 77

Mmigration

project steps 24services 44

migration stepscold push example 84flowchart 57flowchart for PPME 198for PPME 197hot pull example 112

MirrorViewbrief description 35

mount 87, 108multipathing 23

PowerPath 39

Nnavicli

storagegroup operations 73, 107, 118, 128, 130Navisphere

brief description 36connectivity status example 71invoke connectivity status 70Storage Processor WWNs 71

Ooffline

definition 23online

definition 23Open Replicator

control interface alternatives 63data mobility 48-force_copy 53migration operation flow 52pair file example 74, 123Symmetrix V-Max and Symmetrix DMX

arrays 33TimeFinder interaction 89, 100tuning introduction 60

Ppowerformat 108, 195PowerPath

multipathing 39PowerPath Migration Enabler

benefits 188brief description 39description 188introduction 24migration example 204migration states 191nondisruptive migration 189role in migration operations 64when to use 25


PPMEsee PowerPath Migration Enabler

precopydefinition 47

pulldefinition 23

pushdefinition 23

Rremote device

read-only access 23remote side

definition 22Replication Manager


SSAN Copy

brief description 36incremental use case 36

SAN Managerbrief description 37

SCSI reservationscluster control 55

setup stepscold push example 65definition 52flowchart 53flowchart for PPME 197hot pull example 112PPME example 196verify completion example 75verify failure example 124

SIUsee Symmetrix Integration Utilities

SLVsee Symmetrix logical volume

SMCsee Symmetrix Management Console

SnapViewbrief description 36

Solutions Enablerbrief description 40role in migration operations 63

SRDF

see Symmetrix Remote Data FacilitySymmetrix

architecture 32logical volumes 33remote for hot pull example 139

Symmetrix Integration Utilitiesdefinition 129symntctl command 129

Symmetrix logical volumedefinition 33

Symmetrix Management Consolebrief description 40hot pull example 140Remote Report 80role in migration operations 63

Symmetrix Remote Data Facility 34symntctl

log 238mount 134, 179umount 129, 130, 174update 132, 179

TTimeFinder

initial establish 89migration role 34Open Replicator interaction 89, 100split 90

TimeFinder familybrief description 34

Uumount 102

VVxVM

vxdctl 108vxdg 102, 108vxdisk 102, 108, 109vxprint 87, 109, 110vxresize 110vxvol 108


Zzoning

verify with Remote Report 173verify with symmask list logins 78verify with symsan -sanports 75


Documents

h5765 Data Migration Open Replicator Symm Ppme Techbook