Data Migration: EMC Open Replicator for Symmetrix ... · PDF fileData Migration: EMC Open Replicator for Symmetrix, PowerPath Migration Enabler, ... Symmetrix VMAX and Symmetrix DMX

Data Migration: EMC Open Replicator for Symmetrix, PowerPath Migration Enabler, and Federated Live Migration

Version 2.0

• Migration Product Features

• Migration Setup and Verification

• Migration Examples

Donald Fried-Tanzer

Data Migration: EMC Open Replicator, PowerPath Migration Enabler, and Federated Live Migration2

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

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

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

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

For the most up-to-date regulatory document for your product line, go to the Technical Documentation and Advisories section on EMC Powerlink.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

All other trademarks used herein are the property of their respective owners.

Part number H5765.3

Contents

Preface

Chapter 1 IntroductionIntroduction ....................................................................................... 22Data Migration definition................................................................ 22EMC Open Replicator for Symmetrix............................................ 22

Terminology: Control and remote ...........................................22Control FA "host" setup requirements ....................................23Terminology: Push and pull, cold and hot .............................23Multipathing with hot setup requirements ............................24

EMC PowerPath Migration Enabler .............................................. 24Federated Live Migration ................................................................ 24Migration project steps..................................................................... 25When to use Open Replicator with PPME .................................... 26When to use Federated Live Migration ......................................... 27Operational interfaces ...................................................................... 28

Chapter 2 Brief EMC Foundation and Migration Product DescriptionsIntroduction ....................................................................................... 30EMC Symmetrix storage arrays and associated software........... 32

Basic architecture ........................................................................32EMC Enginuity Operating Environment ................................32Symmetrix Logical Volumes .....................................................33Symmetrix VMAX and Symmetrix DMX arrays and Open Replicator .....................................................................................33Pre-DMX Symmetrix arrays and Open Replicator ................33Other Symmetrix software ........................................................34

Data Migration: EMC Open Replicator, PowerPath Migration Enabler, and Federated Live Migration 3

Contents

EMC CLARiiON and associated software .................................... 35EMC MirrorView........................................................................ 36SnapView..................................................................................... 36SAN Copy.................................................................................... 36Navisphere Management Suite ................................................ 36

EMC SAN products.......................................................................... 38Connectrix ................................................................................... 38Connectrix Manager................................................................... 38SAN Manager.............................................................................. 38Invista........................................................................................... 38

EMC Host products.......................................................................... 40PowerPath Family ...................................................................... 40Replication Manager .................................................................. 40EMC Solutions Enabler.............................................................. 41Symmetrix Management Console ............................................ 41EMC Ionix ControlCenter ......................................................... 42

Consulting and IT Services.............................................................. 42Application Consulting ............................................................. 43Business Consulting ................................................................... 43Industry Consulting ................................................................... 43Infrastructure Consulting.......................................................... 43Private Cloud & Virtualization Consulting............................ 44IT Services.................................................................................... 44Managed services ....................................................................... 45

Chapter 3 EMC Open Replicator for SymmetrixIntroduction....................................................................................... 48Definitions ......................................................................................... 48

Hot push ...................................................................................... 48Cold push .................................................................................... 50Hot pull ........................................................................................ 51Cold pull ...................................................................................... 53Open Replicator interaction rules with SRDF........................ 53

Basic Open Replicator migration operation flow......................... 55Setup steps................................................................................... 55Migration steps ........................................................................... 59Cleanup steps.............................................................................. 64

Monitoring, troubleshooting and recovery................................... 65Control interface alternatives.......................................................... 67

Solutions Enabler CLI ................................................................ 67Symmetrix Management Console GUI ................................... 67PowerPath Migration Enabler CLI .......................................... 68


Contents

Reference information ...................................................................... 68

Chapter 4 Cold Push to CLARiiON Setup ExampleIntroduction ....................................................................................... 70Setup step 1: Identify target devices............................................... 71Setup step 2: Configure migration SAN zones ............................. 73

Determining Control Director WWN ......................................73Determining Remote Storage Array WWN(s)........................74Selective or all Symmetrix FA Zoning .....................................77Example configuration of migration SAN zones ...................77

Setup step 3: Configure migration LUN masking........................ 78Create CLARiiON storage group .............................................78Register host and add devices to CLARiiON storage group78

Setup step 5: Prepare Open Replicator session pairs ................... 79Setup step 6: Verify completion of setup steps ............................. 80

Create action is a thorough verification step ..........................80Verify zoning with symsan -sanports ..................................80Verify LUN masking with symsan -sanluns........................82Verify zoning with symmask list logins ............................83Verify all with symrcopy create.............................................84SMC Remote Report ...................................................................86

Chapter 5 Cold Push to CLARiiON Migration ExampleIntroduction ....................................................................................... 90Migration step 7: BCV split.............................................................. 93

Device Group creation ...............................................................93Initial TimeFinder/Mirror establish ........................................95TimeFinder/Mirror split............................................................96

Migration step 8: symrcopy create.................................................. 98Cold control devices must be Not Ready................................98Create action options..................................................................99Open Replication query display .............................................100Query -detail option .................................................................101

Migration step 10: symrcopy activate .......................................... 102Migration step 12: symrcopy set ceiling ...................................... 103Migration step 13: symrcopy query and verify .......................... 105Migration step 14: Iterative symrcopy recreate .......................... 106

Incrementally update control devices from production devices ........................................................................................106Incrementally update remote devices from control devices ........................................................................................107

5Data Migration: EMC Open Replicator, PowerPath Migration Enabler, and Federated Live Migration

Contents

Stop applications and final incremental update .................. 108Migration step 15: Verify migration and symrcopy terminate. 110

Hot push differences from cold push.................................... 110Cleanup step 16: Make source devices host inaccessible.......... 112Cleanup step 17: Make target devices ready to host ................. 113Cleanup step 18: Restart applications using targets .................. 114Cleanup step 19: Redeploy the source devices’ storage............ 116

Chapter 6 Hot Pull from CLARiiON Migration ExampleIntroduction..................................................................................... 118

Hot pull setup steps ................................................................. 118Hot pull migration steps.......................................................... 118Hot pull cleanup step............................................................... 119

Setup step 1: Identify target devices ............................................ 121Setup step 2: Configure migration SAN zone ............................ 122

Determining control director WWNs.................................... 122Determining remote storage array WWNs........................... 123Reuse existing migration SAN zones .................................... 123

Setup step 3: Configure migration LUN masking ..................... 125Create CLARiiON Storage Group.......................................... 125

Setup step 4: Configure target zoning and LUN masking ....... 126Setup step 5: Prepare Open Replicator session pairs file .......... 128Setup step 6: Verify completion of setup steps........................... 131

Discover missing zoning with symrcopy create .................. 131Example configuration of additional migration SAN zone133Discover missing LUN masking with symrcopy create ..... 133Example LUN masking for all Symmetrix VMAX (or Symmetrix DMX) FA control directors ................................. 135Successful create verifies hot pull setup ............................... 135

Migration step 9: Stop the applications ....................................... 136Migration step 10: symrcopy activate.......................................... 138Migration step 11: Restart applications using targets ............... 139Migration step 13: symrcopy query and verify .......................... 144Migration step 15: Verify migration and terminate ................... 145Cleanup step 19: Redeploy the source devices........................... 146

Chapter 7 Hot Pull from Symmetrix Migration ExampleIntroduction..................................................................................... 148

Hot pull setup steps ................................................................. 148Hot pull migration steps.......................................................... 149Hot pull cleanup step............................................................... 149


Contents

Setup step 1: Identify target devices............................................. 151Setup step 2: Configure migration SAN zone............................. 152

Determining control director World Wide Port Names (WWPNs) ...................................................................................152Determining Remote Storage Array WWPN(s) ...................154Configuration of migration SAN zones.................................156

Setup step 3: Configure migration device masking ................... 157Application source device references ....................................157Add Symmetrix device masking ............................................158Symmetrix VMAX device masking using Auto-provisioning groups .......................................................160

Setup step 4: Configure target zoning and LUN masking ........ 173Setup step 5: Prepare Open Replicator session pairs file .......... 174Setup step 6: Verify completion of setup steps ........................... 178

Confirm hot pull setup with successful create .....................178SMC Remote Report .................................................................180

Migration step 9: Stop the applications ....................................... 182Migration step 10: Open Replicator activate ............................... 185Migration step 11: Restart applications using targets ................ 187Migration step 12: Tune migration .............................................. 189Migration step 13: Check status, wait until copied .................... 191Migration step 15: Verify migration and terminate.................... 192Cleanup step 19: Redeploy the source devices ........................... 194

Chapter 8 PowerPath Migration Enabler OverviewIntroduction ..................................................................................... 196Benefits of using PPME .................................................................. 196Nondisruptive migration overview ............................................. 197Definitions ........................................................................................ 199

Pseudo or Native device name migrations ...........................199Source and target ......................................................................199PPME Migration States ............................................................199PPME Abort, Cleanup, and Recover......................................202

PPME considerations and restrictions ......................................... 203PPME with Open Replicator migration operation flow............ 204

Setup steps .................................................................................204Migration steps..........................................................................205Cleanup steps ............................................................................207

Reference information .................................................................... 211


Contents

Chapter 9 PPME with Open Replicator Migration ExampleIntroduction..................................................................................... 214PPME Setup steps 1–4 .................................................................... 215PPME Setup steps 5–6: powermig setup.................................... 215

Identify source and target pseudo device names ................ 216PPME license required............................................................. 217PPME powermig setup............................................................ 218

Migration step 10: powermig sync .............................................. 220Migration step 12: Tune migration .............................................. 221Migration step 13: query status, until SourceSelected .......... 222Migration step 18a: powermig selectTarget........................... 224Migration step 18b: powermig commit........................................ 225Migration step 16: powermig cleanup........................................ 227Cleanup step 19: Redeploy source devices storage ................... 228

Chapter 10 Federated Live Migration (FLM) OverviewIntroduction..................................................................................... 230Benefits of using FLM .................................................................... 230FLM Nondisruptive migration overview ................................... 231FLM Definitions .............................................................................. 233

Source and target, old and new.............................................. 233Device external identity........................................................... 233Active and passive host access modes .................................. 234

FLM basic operation sequence...................................................... 235FLM failback, set NO identity, and host_active................... 235

FLM considerations and restrictions............................................ 237FLM migration using Open Replicator operation flow ............ 238

Setup steps................................................................................. 238Migration steps ......................................................................... 239Cleanup steps............................................................................ 241

Chapter 11 FLM with Open Replicator Migration ExampleIntroduction..................................................................................... 244

Management or application host location for commands.. 244FLM Setup steps 1–6....................................................................... 246Setup step 1: Identify target devices ............................................ 246Setup step 2: Configure migration SAN zone ............................ 246

Determining target VMAX director WWNs......................... 247Determining source DMX director WWNs .......................... 248Example configuration of migration SAN zones................. 249

Setup step 3: Configure migration device masking................... 250


Contents

Setup step 4: Configure target zoning to the application host . 251Setup step 5: Prepare FLM session pairs...................................... 252Setup step 6: Verify setup completion, FLM create .................... 253

Displaying the pre-create FLM status....................................253Creating the FLM session ........................................................254

Migration step 10a: Mask the VMAX target devices ................. 256Displaying the post-create FLM status ..................................256Mask the VMAX target devices ..............................................260Displaying the post-create and target masking MPIO status ...........................................................................................261

Migration step 10b: Activate the FLM session............................ 262Displaying the post-activate FLM status...............................263

Migration step 12: Tune migration .............................................. 264Migration step 13: Verify FLM session copy is done ................. 264Migration step 15: Verify migration and FLM terminate .......... 265Cleanup step 19: Redeploy source devices storage.................... 266

Federated identity removal .....................................................268

Appendix A Open Replicator Performance TuningTwo goals of Open Replicator tuning........................................... 270Resource conflicts............................................................................ 271

I/O resource paths................................................................... 271Array I/O conflicts .................................................................. 271

Limiting Open Replicator resource usage ................................... 272Using a separate management host....................................... 272Limiting Symmetrix FA director competition...................... 272

Migration options can impose performance delays................... 274Tuning Open Replicator ................................................................. 275

Static configuration limits on Open Replicator resource use .............................................................................................. 275Dynamic limits on Open Replicator resource use ............... 275

Monitoring Open Replicator performance.................................. 278symrcopy query........................................................................ 278symrcopy list ceiling................................................................ 278symstat with -RepType rcopy................................................. 279

Tuning for applications sensitive to response time.................... 282


Contents

Appendix B TroubleshootingSolutions Enabler logs.................................................................... 284

Cold push example log entries .............................................. 284Hot pull example log entries.................................................. 287

Audit Log......................................................................................... 290PowerPath Migration Enabler logs .............................................. 292Reactivate Failed Session............................................................... 295

Glossary

Index


Title Page

Figures

1 Migration project steps.................................................................................. 252 Open Replicator hot (or live) push .............................................................. 493 Open Replicator cold (or BCV) push........................................................... 514 Open Replicator hot (or live) pull ................................................................ 525 Open Replicator cold (or point-in-time) pull ............................................. 536 Setup steps flowchart..................................................................................... 567 Migration steps flowchart ............................................................................. 608 Cleanup steps flowchart................................................................................ 649 Invoking Connectivity Status for Host in a Storage Group ..................... 7510 Host connectivity status for a CLARiiON storage group. ....................... 7611 CLARiiON CX3-40f Storage Processor World Wide Port Names........... 7612 Connectrix Manager activate zone verification screen............................. 7713 SMC Remote Report menu selection........................................................... 8614 SMC Remote Report Remote Ports.............................................................. 8715 SMC Remote Report Remote LUNs display .............................................. 8716 Create Page 3 showing CLARiiON Available Remote Devices .............. 8817 Cold push migration and cleanup flowchart ............................................. 9218 Hot pull setup, migration, and cleanup flowchart.................................. 12019 Host connectivity status for licod194 in Storage Group D194............... 12320 Windows drive L contents ......................................................................... 12821 Windows Disk Management display of drives L, M, N and O ............. 12922 Activate additional zones verification screen excerpt ............................ 13323 Disk Management display of target devices additional space .............. 14024 Disk Management updated display showing 4 GB partitions .............. 14325 Symmetrix hot pull setup, migration, and cleanup flowchart .............. 15026 SMC properties for Symmetrix 000190300359 devices 95–98 ................ 15127 SMC Front End Paths detail for control target device 95 ....................... 15228 SMC director 2C port 0 properties showing the port WWN ................. 15329 SMC director 15C port 0 properties showing the port WWN ............... 15330 SMC Front End Paths detail for remote source device 141...................... 154


Figures

31 SMC director 8C port 0 properties showing the port WWN................. 15532 SMC director 9C port 0 properties showing the port WWN................. 15533 Connectrix Manager activate Symmetrix hot pull zones ....................... 15634 Disk Management display of remote source drives P, Q, R, and S ...... 15735 SMC Device Masking menu ....................................................................... 15836 SMC add device masking for remote devices 141–144 on FA-8C:0...... 15937 SMC device masking success confirmation dialog ................................. 15938 SMC add device masking for remote devices 141–144 on FA-9C:0...... 16039 SMC Tasks Masking Wizard selection...................................................... 16240 Masking Wizard step 1 welcome screen................................................... 16341 Masking Wizard step 2 create masking view .......................................... 16442 Masking Wizard step 3 click to create Initiator Group........................... 16543 Masking Wizard step 3 Initiator Group creation .................................... 16744 Masking Wizard step 4 select existing Port Group................................. 16845 Masking Wizard step 5 click to create Storage Group............................ 16946 Storage Group creation dialog box............................................................ 17047 Masking Wizard step 7 summary.............................................................. 17148 Masking Wizard success dialog................................................................. 17249 SMC properties device detail for control target device 95..................... 17350 SMC Open Replicator Create Copy Session menu ................................. 17451 SMC Create Copy Session page 1: Set session parameters .................... 17552 SMC Create Copy Session page 2: select control devices....................... 17553 SMC Open Replicator page 3: Select remote devices.............................. 17654 SMC Create Copy Session page 4: Select device pairs............................ 17755 SMC Create Copy Session page 5: Set session options and execute..... 17856 SMC Confirm Open Replicator create execution .................................... 17957 SMC Create Copy Session success dialog box ......................................... 17958 SMC Remote Report menu selection......................................................... 18059 SMC Remote Report Remote Ports tab ..................................................... 18160 SMC Remote Report Remote Luns display.............................................. 18161 SMC Removing device masking for devices 141–144 for FA-8C:0 ....... 18362 SMC Removing device masking for devices 141–144 for FA-9C:0 ....... 18463 SMC Open Replicator session properties and control menu................. 18564 SMC Open Replicator activate ................................................................... 18665 Open Replicator session properties after activate ................................... 18666 Disk Management display of drives P–S on the target devices ............ 18867 SMC Select Open Replicator Set Ceiling Menu ....................................... 18968 SMC Open Replicator Set Ceiling.............................................................. 19069 SMC Open Replicator session properties Refresh View update........... 19170 SMC Open Replicator session properties showing Copied state.......... 19271 Donor Update Off SMC Session Control dialog box .............................. 19372 Terminate SMC Session Control dialog box ............................................ 19473 PPME Operation with pseudo-named devices and Open Replicator.. 198


Figures

74 PPME Migration states and commands .................................................... 20075 PPME with Open Replicator setup steps flowchart ................................ 20576 PPME migration steps flowchart................................................................ 20677 PPME cleanup steps flowchart ................................................................... 21178 PPME with Open Replicator setup, migration, and cleanup steps ....... 21479 FLM operation overview............................................................................. 23280 FLM with Open Replicator setup steps flowchart................................... 23981 FLM migration steps flowchart .................................................................. 24082 FLM with Open Replicator setup, migration, and cleanup steps.......... 24583 Connectrix Manager activate zone verification screen ........................... 24984 Windows Event Viewer with PPME error message selected................. 29285 Event Properties detail for missing PPME license................................... 29386 Windows Event Viewer with PPME error message selected................. 29487 Event Properties detail for missing PPME license................................... 294


Figures


Preface

This TechBook describes best practices for using EMC Open Replicator for Symmetrix for data migration. Advantages and proper use of EMC PowerPath Migration Enabler (PPME) and Federated Live Migration (FLM) using Open Replicator as the underlying technology are comprehensively explained. Open Replicator features used for data mobility and remote vaulting, but not for data migration, are not covered in this guide.

As part of an effort to improve and enhance the performance and capabilities of its product line, EMC routinely releases revisions of its hardware and software. Therefore, some functions described in this guide may not be supported by all revisions of the software or hardware currently in use. For the most up-to-date information on product features, refer to the product release notes. If a product does not function properly or does not function as described in this document, please contact your EMC representative.

Note: This document was accurate as of the time of publication. However, as information is added, new versions of this document may be released to the EMC Powerlink website. Check the Powerlink website to ensure that you are using the latest version of this document.

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

Readers of this TechBook are expected to be familiar with:

◆ EMC Symmetrix Logical Volumes (SLVs) including masking

◆ CLARiiON or third-party array LUNs and masking for heterogeneous migration


16

Preface

◆ SAN zoning

◆ EMC Solutions Enabler SYMCLI and Symmetrix Management Console (SMC)

Organization This TechBook is divided into eleven chapters and two appendices:

◆ Chapter 1, “Introduction,” provides an introduction to the interfaces and potential deployment of EMC Open Replicator for Symmetrix together with PowerPath Migration Enabler, Federated Live Migration, or alone. Background information including Open Replicator terminology and required setup operations are introduced.

◆ Chapter 2, “Brief EMC Foundation and Migration Product Descriptions,” provides an introduction to EMC Symmetrix hardware and software technologies that are used to implement migration solutions.

◆ Chapter 3, “EMC Open Replicator for Symmetrix,”defines all Open Replicator terminology, interfaces and operations. All of the steps for initiating and conducting Open Replicator operations are described.

◆ Chapter 4, “Cold Push to CLARiiON Setup Example,” provides an example of the steps needed to set up a cold push migration. This chapter also describes additional setup requirements for hot operations and multiple methods for verifying that Open Replicator setup is complete. The examples shown in this chapter use a Solaris host and SYMCLI.

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

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

Data Migration: EMC Open Replicator, PowerPath Migration Enabler, and Federated Live Migration

Preface

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

◆ Chapter 8, “PowerPath Migration Enabler Overview,” defines all PPME terminology, interfaces and operations. All of the steps for installing, initiating and conducting PPME Open Replicator operations are described.

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

◆ Chapter 10, “Federated Live Migration (FLM) Overview,” defines all FLM terminology, interfaces, and operations. All of the steps for initiating and conducting FLM operations are described.

◆ Chapter 11, “FLM with Open Replicator Migration Example,” provides an example of the steps needed to initiate, monitor, and conclude a Federated Live Migration session. The examples shown in this chapter use a Windows host and SYMCLI.

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

◆ Appendix B, “Troubleshooting,” provides log examples that correlate with the examples in chapters 4–9, and provides troubleshooting not covered in the chapter examples.

This TechBook is the second in a series of Data Migration TechBooks. Readers should reference the first volume, Choosing a Data Migration Solution for EMC Symmetrix Arrays, that explores the complexity of data migration and how to select a data migration solution for Symmetrix in an open systems environment.

For readers who have access to EMC Powerlink, check EMC Powerlink for new TechBooks in this Data Migration series at:

http://Powerlink.EMC.com

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

Alternatively, you can visit the Vervante On Demand Publishing website at:



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

18

Preface

http://www.vervante.com/

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

Product information For documentation, release notes, software updates, or for information about EMC products, licensing, and service, go to the EMC Powerlink website (registration required) at:


Technical support For technical support, go to EMC Customer Service on Powerlink. To open a service request through Powerlink, you must have a valid support agreement. Please contact your EMC sales representative for details about obtaining a valid support agreement or to answer any questions about your account.

Relateddocumentation

Related documents, available on EMC Powerlink, include:

• EMC Solutions Enabler Symmetrix Open Replicator CLI Product Guide

• EMC Solutions Enabler Installation Guide

• EMC Solutions Enabler Symmetrix Array Management CLI Product Guide

• EMC Solutions Enabler Symmetrix Array Controls CLI Product Guide

• EMC Solutions Enabler Symmetrix SRM CLI Product Guide

• EMC Solutions Enabler Symmetrix TimeFinder Family CLI Product Guide

• EMC Solutions Enabler Symmetrix SRDF Family CLI Product Guide

• EMC PowerPath Migration Enabler User Guide

• Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

• Migrating Microsoft Cluster Server using EMC Open Replicator for Symmetrix Technical Note

• EMC Symmetrix LUN Expansion and UNIX Logical Volume Managers Technical Note

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

• EMC Federated Live Migration Technical Overview Technical Notes


http://www.vervante.com/

http://powerlink.emc.com


Preface

• EMC Federated Live Migration Simple Support Matrix

• Choosing a Data Migration Solution for EMC Symmetrix Arrays TechBook

• White paper: New Features in EMC Enginuity 5875 for Symmetrix Open Systems Environments

• EMC Symmetrix Enginuity Release Notes (multiple release levels available)

• EMC Solutions Enabler Version 7.2 Release Notes

• EMC Symmetrix Management Console Version 7.2 Release Notes

• Storage Provisioning With EMC Symmetrix Auto-provisioning Groups Technical Note

• Implementing Fully Automated Storage Tiering with Virtual Pools (FAST VP) for EMC Symmetrix VMAX Series Arrays Technical Notes

Typographicalconventions

EMC uses the following type style conventions in this document:

Normal Used in running (nonprocedural) text for:• Names of interface elements (such as names of windows, dialog boxes, buttons,

fields, and menus)• Names of resources, attributes, pools, Boolean expressions, buttons, DQL

statements, keywords, clauses, environment variables, functions, utilities• URLs, pathnames, filenames, directory names, computer names, filenames, links,

groups, service keys, file systems, notifications

Bold Used in running (nonprocedural) text for:• Names of commands, daemons, options, programs, processes, services,

applications, utilities, kernels, notifications, system calls, man pages

Used in procedures for:• Names of interface elements (such as names of windows, dialog boxes, buttons,

fields, and menus)• What user specifically selects, clicks, presses, or types

Italic Used in all text (including procedures) for:• Full titles of publications referenced in text• Emphasis (for example a new term)• Variables

Courier Used for:• System output, such as an error message or script • URLs, complete paths, filenames, prompts, and syntax when shown outside of

running text


20

Preface

The author of this TechBook

This TechBook was written by Donald Fried-Tanzer, an employee of EMC based at headquarters in Hopkinton, Massachusetts. Donald has over 30 years of experience in client-server applications, fault-tolerant servers, and storage management software including: provisioning, remote replication, local replication, migration, configuration, and monitoring.

We'd like to hear from you!

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

[email protected]

Courier bold Used for:• Specific user input (such as commands)

Courier italic Used in procedures for:• Variables on command line• User input variables

< > Angle brackets enclose parameter or variable values supplied by the user

[ ] Square brackets enclose optional values

| Vertical bar indicates alternate selections - the bar means “or”

{ } Braces indicate content that you must specify (that is, x or y or z)

... Ellipses indicate nonessential information omitted from the example


[email protected]

1

This chapter provides a brief summary of the three migration products covered in this guide: EMC Open Replicator for Symmetrix, EMC PowerPath Migration Enabler (PPME), and Federated Live Migration (FLM). Key terminology and setup requirements for Open Replicator are introduced. The full set of migration project steps is depicted identifying the project steps covered in this book and where to find more information on other project steps. An abbreviated approach to choosing whether to use Open Replicator with PPME or Federated Live Migration concludes the chapter. The topics covered include:

◆ Introduction ........................................................................................ 22◆ Data Migration definition ................................................................. 22◆ EMC Open Replicator for Symmetrix ............................................. 22◆ EMC PowerPath Migration Enabler................................................ 24◆ Federated Live Migration ................................................................. 24◆ Migration project steps...................................................................... 25◆ When to use Open Replicator with PPME ..................................... 26◆ When to use Federated Live Migration .......................................... 27◆ Operational interfaces ....................................................................... 28

Introduction

Introduction 21

22

Introduction

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

Data Migration definitionData Migration can be defined as the one time movement of data from a source to a target, where the data will subsequently only be accessed at the target. The key to this definition is that for any particular piece of data, this is a one time movement. This one time movement differentiates Data Migration from Replication where applications continue to access the source data after the target copy is created. Also, the one time movement differentiates Data Migration from Data Mobility where incremental updates to the data would continue to be applied.

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

EMC Open Replicator for Symmetrix

Terminology: Control and remote

Open Replicator can transfer data between Symmetrix arrays (homogeneous,) or between a Symmetrix VMAX (or Symmetrix DMX) and another qualified Fibre Channel array (heterogeneous). The Symmetrix VMAX (or Symmetrix DMX) where


Introduction

Open Replicator runs, and its devices are always referred to as the control side of the copy operation. Other Symmetrix arrays, CLARiiON® arrays, or third-party arrays on the SAN are referred to as the remote array/devices.

Control FA "host" setup requirements

Open Replicator runs as an application in the Fibre Director (FA) of the Symmetrix VMAX (or Symmetrix DMX). The Open Replicator software causes the FA to appear as an open systems host to the remote storage array. Therefore, no special software is needed in the remote storage array. However, zoning and LUN masking is needed to access the remote devices and must be defined (as is the case anytime a host needs to access devices on a remote storage array). Configuring the required zoning and LUN masking is the most common area where problems occur when setting up Open Replicator and will be covered thoroughly in multiple examples. Additionally, multiple methods for verifying that the setup is correct will be covered in the examples.

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

EMC Open Replicator for Symmetrix 23

24

Introduction

Multipathing with hot setup requirementsTypically a Symmetrix device is visible to a host on more than one I/O path. This is done to improve both fault tolerance (failover) and performance (load balancing). Multipathing is accomplished by configuring the Symmetrix to present Symmetrix Logical Volumes (SLVs) as being visible to the application host on more than one FA port. The application host must use some type of multipathed I/O solution in order to correctly handle the same device being presented on more than one I/O path. A common multipathing host solution is EMC PowerPath®. The combination of multipathed control devices and hot Open Replicator operations result in the greater requirement that all FA directors that present the control devices, must be zoned and LUN masked as hosts able to access the remote array devices. When using Open Replicator hot pull as the underlying technology for Federated Live Migration (FLM), all FA directors that present the new VMAX devices, must be zoned and LUN masked as hosts able to access the donor array devices.

EMC PowerPath Migration EnablerPowerPath Migration Enabler (PPME) is a hybrid migration solution that provides the ability to perform nondisruptive migrations or encapsulations while leveraging another underlying technology, such as Open Replicator, TimeFinder/Clone, Invista®, or Host Copy. PPME provides a solution with virtually no impact to host resources by utilizing array-based or SAN-based replication (except for Host Copy). PPME benefits data migrations by greatly reducing or eliminating application disruption caused by the migration, reducing migration risk, and simplifying migration operations. PowerPath Migration Enabler can be installed without PowerPath multipathing technology, but PowerPath multipathing is required for completely nondisruptive migrations. This TechBook only covers PPME operation with Open Replicator.

Federated Live MigrationFederated Live Migration (FLM) is a method by which a user can move data from older storage into a new VMAX array nondisruptively. The host application cutover to use the new VMAX devices is made transparent by a combination of presenting the


Introduction

VMAX devices as additional paths to the old devices and managing which paths are active through a multipath I/O (MPIO) driver on the host. FLM supports PowerPath as the application MPIO driver, and will support additional MPIO drivers in the future. FLM supports moving the data with Open Replicator SAN-based replication, and will support other underlying technologies in the future. Unlike application host-based PPME, control of the migration and cutover is managed through the VMAX array. FLM greatly simplifies migrations requiring no remediation when migrating pre-qualified stacks.

Migration project stepsFigure 1 summarizes the basic migration flow.

Figure 1 Migration project steps

This TechBook is focused on operational migration examples, similar to a Migration Pilot. There is also some inclusion of the Migration and Cutover step particularly in describing how PowerPath Migration

ICO-IMG-000440

Business Impact Analysis

Source ConfigurationDiscovery

Migration Strategy and Tool Selection

Detailed Mapping and Design

Provisioning

Skill Refreshing Migration Pilot

Migration and Cutover

Sign-off

Migration project steps 25

26

Introduction

Enabler (PPME) and Federated Live Migration (FLM) each simplify this step. The Migration Strategy and Tool Selection step is where the decision would be made whether to use Open Replicator alone or together with PPME or FLM. The Selection step requires both the Business Impact Analysis and Source Configuration Discovery steps to provide necessary input. These first three steps are covered in the first volume in the Data Migration series of TechBooks, Choosing a Data Migration Solution for EMC Symmetrix Arrays. The selection model defined for migration tool selection is conducted here in an abbreviated manner.

When to use Open Replicator with PPMEIn this case, the starting assumption is that EMC Open Replicator for Symmetrix has been selected as the main migration tool and the decision is whether to use it alone or in conjunction with PPME. To make this determination, follow the iterative six step model shown below, and provide answers to the highlighted applicable key questions. How these questions are answered will determine whether Open Replicator should be used alone, or in conjunction with PPME.

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

2. Inventory the existing environment and identify storage elements that must participate with the chosen data migration solution, along with resources that are available to suppo?t the migration itself.

3. Inventory the target environment identifying storage elements that must participate with the chosen data migration solution, and resources available to support the migration itself.

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


Introduction

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

6. Compare and evaluate the potential data migration solutions including the criteria identified in steps 1–5.

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

When to use Federated Live MigrationFederated Live Migration (FLM) currently best fits cases of data center consolidation and technology refresh when the old donor array will be removed from sharing the same SAN as the new VMAX. The iterative six step model and applicable key questions can be used to determine whether FLM should be used:

1. Define the reasons for the data migration, clearly noting mandatory and optional objectives. Applicable key question: Is this a data center consolidation or technology refresh which will remove the old donor array?

2. Inventory the existing environment and identify storage elements that must participate with the chosen data migration solution, along with resources that are available to support the migration itself. Applicable key question: Is the existing environment an FLM pre-qualified stack?

When to use Federated Live Migration 27

28

Introduction

3. Inventory the target environment identifying storage elements that must participate with the chosen data migration solution, and resources available to support the migration itself. Applicable key question: Is the target storage array a VMAX running Enginuity™ 5875 or later?

4. Identify potential data migration solutions that can successfully move the data from the existing environment to the target environment. Applicable key question: Is FLM supported in the existing and target environments?

5. Identify business factors that limit potential data migration solutions such as budget, human resources, and application outage and verification requirements.Applicable key question: How important is avoiding application interruptions, avoiding application host operations, reducing migration risk, and simplifying migration operations?

6. Compare and evaluate the potential data migration solutions including the criteria identified in steps 1–5.

The answers provided to the applicable key questions can identify opportunities to realize the advantages of using FLM. FLM can eliminate application disruption due to the migration without operations on the application host. If this is a key factor for migrations, then it is likely that the use of FLM will be beneficial.

Operational interfacesThere are three different interfaces available to control EMC Open Replicator for Symmetrix: the Solutions Enabler Command Line Interface (CLI), the Symmetrix Management Console (SMC) Graphical User Interface (GUI), and the PowerPath Migration Enabler (PPME) CLI. Examples of using all three interfaces are included in this TechBook. Note that the PPME CLI interface has fewer operational steps and provides a greater breadth with the inclusion of migration cutover operations than is available with the Solutions Enabler CLI or SMC alone.

Federated Live Migration (FLM) can be performed using the existing CLI and SMC interfaces for Open Replicator with additional options specifically for FLM. CLI and SMC interfaces for Auto-provisioning groups is also used at a specific time as part of FLM. SMC also supports a specific FLM wizard.


2

This chapter provides brief descriptions of EMC Symmetrix hardware and software technologies that may play a role in a data migration using Open Replicator, PPME, and FLM. The topics covered include:

◆ Introduction ........................................................................................ 30◆ EMC Symmetrix storage arrays and associated software............ 32◆ EMC CLARiiON and associated software ..................................... 35◆ EMC SAN products ........................................................................... 38◆ EMC Host products ........................................................................... 40◆ Consulting and IT Services............................................................... 42

Brief EMC Foundationand Migration Product

Descriptions

Brief EMC Foundation and Migration Product Descriptions 29

30

Brief EMC Foundation and Migration Product Descriptions

IntroductionThis chapter contributes to the selection model introduced in Chapter 1, by providing brief introductions of EMC products that will be used primarily in selection model steps 2–4. Chapter 2 of the Choosing a Data Migration Solution for EMC Symmetrix Arrays TechBook has a more complete listing of EMC migration-related products. The subset of products included in this chapter were chosen because they can be operationally relevant to using Open Replicator, PPME, and FLM.

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

◆ Symmetrix storage arrays are present in all Open Replicator or Federated Live Migration configurations, because at least one Symmetrix VMAX (or Symmetrix DMX) storage array must be present as the control array or new FLM array. Other Symmetrix storage arrays may act as the remote array in Open Replicator operations or old/donor array for FLM. The TimeFinder® family of local replication products may be used to create point-in-time copies for cold operations. The SRDF® family of remote replication products may provide information about remote Symmetrix arrays and can be used to perform remote operations. Solutions Enabler, the Symmetrix Management Console (SMC), and EMC Ionix™ ControlCenter® Symmetrix Manager are associated management software for managing the Symmetrix.

◆ CLARiiON storage arrays may act as the remote array in Open Replicator operations. The SAN Copy™ product is a CLARiiON based product with functionality similar to Open Replicator. It is included with a short discussion of a use case where SAN Copy might be used instead of Open Replicator. Navisphere® Management Suite is an associated management software that can be used to set up the CLARiiON to work as a remote array in Open Replicator operations.

Note: EMC Unisphere™ is the next generation of mid-tier storage management that provides a single, integrated, and simple user interface for EMC CLARiiON, EMC Celerra® and EMC RecoverPoint SE systems. Unisphere replaces Navisphere as the management interface for CLARiiON starting with the FLARE® 30 release.



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

◆ The host grouping includes migration related products that execute solely on a customer host system, as well as products that provide a host-executable control interface for array or SAN-based migration software. PowerPath multipathing can affect the setup requirements for Open Replicato? and supported application host multipathing is required for FLM. PowerPath Migration Enabler (PPME) also executes on the host. Control interfaces include Solutions Enabler, Symmetrix Management Console (SMC), and EMC Ionix ControlCenter.

◆ Services are very often a key component of actual data migrations. In many cases, a majority of the migration costs are in discovery, documentation, mapping and design, provisioning, piloting and qualification. EMC Services are a key method to reduce risk and ensure the success of data migrations.

Introduction 31

32


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

Basic architecture

Symmetrix is a high-end enterprise storage system with maximum capacity and the highest performance, consolidating massive amounts of data and host applications and storage tiers on reliable, cost-effective networked storage. Symmetrix provides broad connectivity with 4 Gb/s performance, advanced security, high availability, and energy efficiency in an easy-to-operate storage system.

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

◆ Shared Global Memory provides cache memory

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

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

The Symmetrix architecture can be compared to a MPP (Massively Parallel Processing) server with directors working simultaneously performing all the tasks of the array.

EMC Enginuity Operating Environment

Symmetrix storage arrays run EMC Enginuity™, the most mature, comprehensive, stable, highly available, and proven storage operating environment in the industry. Enginuity is the emulation code, service processor code and other software used by a Symmetrix to implement core functionality. Each processor in every director is loaded with specific emulation code. Enginuity coordinates the independent director processors to act as one Integrated Cached Disk Array. Enginuity provides base system functionality and advanced features like local (TimeFinder) and remote (SRDF) replication, Open Replicator and other optional software products.



Symmetrix Logical VolumesSymmetrix Logical Volumes (SLVs) are logical abstractions of physical disk drives that are presented to open system hosts as FBA (Fixed Block Architecture) devices. EMC and customers configure these devices using Symmetrix management software. More information about this software is available in “Symmetrix management software” on page 35. Enginuity also provides the capability to map SLV visibility on specific FA adapters and to limit visibility to specific Host Bus Adapters (HBAs) on a switched Fibre Channel connection using device masking (LUN masking). Symmetrix Access Controls can be used as a further security feature to specifically limit the types of actions possible on devices from specific hosts.

Symmetrix VMAX and Symmetrix DMX arrays and Open ReplicatorThe current Symmetrix models Symmetrix VMAX SE and Symmetrix VMAX Series run Enginuity level 5875. The previous Symmetrix model family DMX-4 950/1500–4500 can run Enginuity levels 5772 or 5773. The third set of Symmetrix DMX models were the DMX-3 950/1500–4500 and can run Enginuity levels 5771, 5772 or 5773. The first DMX models were the DMX-1/DMX-2 800/1000/2000/3000 and can run Enginuity levels 5670 or 5671. Enginuity levels 5671 and 5771 were the first levels to include the EMC Open Replicator for Symmetrix software. Open Replicator runs as an application in the Fibre Director (FA) of the Symmetrix VMAX or Symmetrix DMX. The Open Replicator software causes the FA to appear as an open systems host to the remote storage array, while it continues to simultaneously function as the host front-end to the Symmetrix. Enginuity level 5875 is the first level to include Federated Live Migration (FLM) software. Donor DMX arrays for FLM need to have Enginuity levels 5671 or 5773 that include FLM support.

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

EMC Symmetrix storage arrays and associated software 33

34


Other Symmetrix software

Symmetrix RemoteData Facility (SRDF)

Family

The EMC Symmetrix Remote Data Facility (SRDF) family of replication software offers various levels of Symmetrix based business continuance, disaster recovery and data mobility solutions. SRDF products offer the capability to maintain multiple, host-independent, mirrored copies of data. The Symmetrix systems can be in the same room, in different buildings within the same campus, or hundreds to thousands of kilometers apart. By maintaining copies of data in different physical locations, SRDF is an effective mechanism for data center migration. SRDF is designed for Symmetrix to Symmetrix connections through Fibre Channel, Gigabit Ethernet (GigE), and ESCON. SRDF has been a part of Enginuity since 1994.

TimeFinder Family The EMC TimeFinder family of software is the most powerful suite of local storage replication solutions available. Fully leveraging the industry-leading high-end Symmetrix hardware architecture, it offers unmatched deployment flexibility and massive scalability to deliver a wide range of in-the-system data copying capabilities to meet mixed service level requirements without operational impact. The field-proven TimeFinder family is the most widely deployed set of high-end replication solutions in the industry, with tens of thousands of installations in the most demanding environments. And, only the TimeFinder family can provide cross-volume and cross-storage system consistency, tight integration with industry leading applications, and simplified usage through automated management. The EMC TimeFinder family of local replication allows users to nondisruptively create and manage point-in-time copies of data to allow operational processes, such as backup, reporting, and application testing to be performed independent of the source application to maximize service levels without impacting performance or availability.

TimeFinder/Clone, TimeFinder/Mirror or TimeFinder/Snap can play a role in Open Replicator data migration in two ways. First, TimeFinder can be used to create a local point-in-time copy for an Open Replicator cold push migration to a remote array. Both TimeFinder and Open Replicator include incremental support, so this point-in-time copy can be incrementally updated, followed by an incremental Open Replicator update to quickly reach the new point-in-time. At the end of the migration, the final TimeFinder and Open Replicator incremental updates would be conducted after



production I/O was stopped to the production device. Second, if the remote array is a Symmetrix, TimeFinder can be used to ensure a backup copy of the production data is available at the remote location in case there is a disruption during an Open Replicator incremental push. This is necessary, because when Open Replicator performs an incremental update from the production volumes, the data on the remote devices is not in a consistent state until the update completes.

Note: Enginuity 5874 and later no longer support native TimeFinder/Mirror operations. However, TimeFinder/Mirror commands are still supported using the TimeFinder/Clone emulation feature. Therefore, usually there are no changes in the operational details provided for integrating TimeFinder/Mirror with Open Replicator. The emulation feature is not supported for virtually provisioned (thin) devices; in this case new scripts using native TimeFinderClone commands (symclone) must be used in place of emulated TimeFinder/Mirror commands (symmir).

Symmetrixmanagement

software

Enginuity and array-based applications like SRDF and TimeFinder reside in the Symmetrix array and can be managed by host applications. EMC Solutions Enabler includes a CLI interface for Open Replicator, SRDF, TimeFinder, device configuration, device mapping, and device masking. Symmetrix Management Console (SMC) provides a browser-based GUI interface on top of Solutions Enabler. Ionix ControlCenter Symmetrix Manager is a central feature of the Ionix ControlCenter family of products, which provides a unified view for multiple arrays via a single-pane-of-glass interface. Symmetrix Manager is used to discover, monitor, and configure Symmetrix storage from a single console including the ability to automate key system management, and replication tasks.

EMC CLARiiON and associated softwareCLARiiON arrays combine advanced, easy-to-use midrange networked storage with robust software capabilities. CLARiiON also provides the high availability and scalability needed to manage and consolidate more data. CLARiiON arrays have front-end Fibre Channel support and can act as the remote array for Open Replicator.

EMC CLARiiON and associated software 35

36


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

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

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

Navisphere Management SuiteNavisphere provides browser-based discovery, monitoring, configuration, and reporting on multiple EMC CLARiiON storage arrays. Navisphere provides management for CLARiiON's advanced software functionality including: EMC Navisphere Quality of Service Manager, Navisphere Analyzer, SnapView, SAN Copy, and MirrorView. Navisphere also provides the mechanism to set the LUN



masking required to make CLARiiON LUNs accessible to the Symmetrix VMAX (or Symmetrix DMX) FA Open Replicator "host." For CLARiiONs running FLARE 30 or later EMC Unisphere replaces Navisphere, Unisphere Quality of Service Manager replaces Navisphere Quality of Service Manager, and Unisphere Analyzer replaces Navisphere Analyzer.

EMC CLARiiON and associated software 37

38


EMC SAN products

Connectrix

EMC Connectrix products are advanced directors and switches for creating an efficient, scalable, high-availability SAN infrastructure. EMC offers a comprehensive line of Connectrix switches and directors that scale from 8 to 528 ports. Some models provide support for SAN Extension, SAN Routing, and network-hosted applications such as EMC RecoverPoint and EMC Invista.

Connectrix Manager

EMC Connectrix Manager provides an interface to the Connectrix server, centralized management of multiple enterprise directors and switches, and a high-level view of the enterprise storage network within the local data centers or at geographically dispersed locations. Connectrix Manager can be used to configure the required zoning for the Symmetrix VMAX (or Symmetrix DMX) FA Open Replicator "host" and the remote storage array for using Open Replicator alone or with PPME or FLM.

SAN Manager

Ionix ControlCenter SAN Manager streamlines and centralizes management of multivendor SANs from one easy-to-use interface. SAN Manager can be used to configure the required zoning for the Symmetrix VMAX (or Symmetrix DMX) FA Open Replicator "host" and the remote storage array for using Open Replicator alone or with PPME or FLM.

Invista

Invista Storage Virtualization introduces a hardware abstraction layer to storage infrastructure, decoupling storage from operating systems. The storage device that is visible to a host is no longer array specific, but is a virtual entity that allows the arrays providing the capacity to be interchanged as business needs dictate, resulting in the ability to move, expand, or change the storage infrastructure while the application remains online. Applications can be migrated between



storage tiers or onto refreshed storage systems while reducing or eliminating planned downtime. Storage Virtualization is a technology enabler for Information Lifecycle Management (ILM). Storage Virtualization also provides a common means for storage management across heterogeneous storage platforms, which simplifies management and reduces operating cost for ongoing data migration needs. PowerPath Migration Enabler can use Invista as the underlying SAN-based data migration technology.

EMC SAN products 39

40


EMC Host products

PowerPath Family

The PowerPath family enables EMC host-based solutions including multipathing, data migration, and host-based encryption.

◆ PowerPath Multipathing automatically tunes the storage area network (SAN) and selects alternate paths for data if necessary. Residing on the server, PowerPath Multipathing enhances SAN performance and application availability. It also integrates multiple path I/O capabilities, automatic load balancing, and path failover functions for complete path management. PowerPath multipathing is qualified to correctly support the changing status of active and passive paths key to FLM operations.

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

Replication Manager

Replication Manager is used to administer multiple EMC replication technologies and coordinate the entire replication process, from discovery and configuration to the operation of multiple disk-based replicas. Replication Manager can be used to automate the discovery of storage arrays, applications, replication technologies, and hosts. With Replication Manager, all information and activities for replicas can be recorded and catalogued. Replication Manager provides a wizard-driven interface to create copies of information and includes support for TimeFinder alone or integrated with SRDF, SnapView alone or integrated with MirrorView, SAN Copy, RecoverPoint, Celerra® SnapSure™, Celerra Replicator™, and Invista Clones.



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

Symmetrix Management ConsoleAs a small and easy-to-implement, browser-based graphical interface, SMC can be hosted on a small Windows, Linux or Solaris server and is accessible via a client web browser from nearly anywhere in the world. Because of this minimal infrastructure, SMC is an ideal graphical complement to SYMCLI and even to full Ionix ControlCenter for performing basic device management of a Symmetrix system. SMC is also an exceptional product for those comfortable with SYMCLI, but who might be looking for an easy, graphical interface for controlling their Symmetrix arrays. Like Solutions Enabler, the SMC Server can be run from any host which has at least one Symmetrix device visible to it. With the introduction of the VMAX, the SMC Server can also be setup to run on the Symmetrix Service Processor providing an out of band management path for the Symmetrix. The SMC Server can also be configured to remotely connect to another Solutions Enabler host which has at least one Symmetrix device visible to it. With SMC, users can manage operations from device creation to virtual provisioning to replication configuration and monitoring. And as needs change and grow, higher-level, storage resource management capabilities can easily be added through the Ionix ControlCenter family. SMC provides a wizard based interface for setting up Open Replicator migrations including selection of control and remote devices through available devices windows. SMC also provides a wizard for Federated Live Migration (FLM).

EMC Host products 41

42


EMC Ionix ControlCenter EMC Ionix ControlCenter simplifies and automates key tasks, such as discovery, monitoring, reporting, planning, and provisioning for even the largest, most complex storage environments. Ionix ControlCenter can manage storage, fabric, and hosts, providing a unified, single-pane-of-glass view for multiple arrays, switches and hosts. When performing migrations, its GUI interface is an ideal way to both provision the target environment and to reconfigure the SAN.

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

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

◆ Business Impact Analysis◆ Source Configuration Discovery◆ Migration Strategy and Tool Selection◆ Detailed Mapping and Design◆ Provisioning◆ Skill Refreshing◆ Migration Pilot◆ Migration and Cutover

From this list of eight steps where only one is directly related to moving data, it would be correct to conclude that the challenge of a data migration is not just moving the data. EMC has a plethora of products available to address just about every type of migration scenario you can imagine. Choosing a Data Migration Solution for EMC Symmetrix Arrays contains greater detail. In reviewing actual migrations, it becomes evident that most migration costs are associated with discovery, documentation, mapping and design,



provisioning, piloting and qualification. Therefore, when planning a migration, it is worth considering contracting EMC Services for assistance in many of these areas.

Application Consulting

Create intuitive digital experiences and use information to collaborate, make decisions, and automate processes.

Business Consulting

Drive product leadership, differentiated customer experience, and operational excellence.

Industry Consulting

Leverage our deep industry expertise and broad technology competencies to achieve market leadership.

Infrastructure ConsultingTransform infrastructure and operations into IT services that support business growth and change.

Application infrastructure optimizationLower the cost of ongoning operations, simplify administrative tasks, and imporve the security and reliability of your appplication infrastructure.

Data center transformationAccelerate your data center’s strategic business value, leveraging EMC’s best practices and infrastructure expertise.

Data protection and availabilityEnsure secure and predictable access to critical business data and systems with the architectures, systems, and strategies that provide availaility and recoverability.

Consulting and IT Services 43

44


Infrastructure strategy and architectureTurn your IT organization into a service provider to your business by balancing service-level needs and costs with a service-based infrastructure stategy and architecture.

IT process optimizationOptimize your IT data center operational processes. Leverage EMC best practices as well as Information Technology Infrastructure Libary (ITIL) and other international standards.

Security strategy and developmentDevelop a strategic IT security road map that reduces security risks in a durable manner and meets compliance and business requirements.

Service-oriented infrastructureDeliver information infrastructure strategies tailored to your specific business requirements that balance cost and service-level requirements.

Private Cloud & Virtualization ConsultingDeliver business agility and IT flexibility and efficiency at enterprise scale.

IT Services

Assessment ServicesIdentify possible strategies for your information infrastructure to meet your business and technical goals.

Business Continuity Services Obtain a complete suite of services for your business continuity needs.

Design and Implementation ServicesGet best practices recommendations and proven methodologies for hardware and software design and implementation.



Disk Security ServicesSecure information and support your compliance initiatives.

Enterprise Content Management Implementation ServicesCombine enterprise content management with storage, virtualization, archiving, and backup and recovery.

Migration ServicesEnsure safe migration of all your data among EMC storage systems or between heterogeneous systems.

Performance Assessments and Health ChecksMaintain high service levels by identifying factors that affect storage platform performance.

Services for VMware EnvironmentsUnlock the full spectrum of your virtualization efficiencies and benefits with EMC Global Services.

VMware, Cisco, and EMC ServicesIntegrate Vblock into your IT operations with the help of Virtual Computing Environment Coalition (VCE) consultants, who apply best practices and multidomain experience.

Managed services

Meet your specific needs at every phase of your journey to the private cloud with EMC Managed Services. Augment or complement your existing resources with EMC residents who offer short-term, day-to-day technology, operational, and architectural support. You can also obtain longer-term support to help you implement and optimize specific storage processes and operations. In addition, EMC can manage some or all of your storage assets.

Managed Availability Gain multi-year business continuity support for a wide range of recovery solutions, including internal and third-party recovery site options.

Consulting and IT Services 45

46


Remote Managed Services Manage your information infrastructure through cost-effective, 24x7 intelligent remote monitoring and management based on defined service level objectives.

Residency ServicesFulfill short-term storage resource or skill gaps, accelerate integration of new information infrastructure assets, and streamline administrative and support processes.

Storage Managed Services Meet your service-level agreements and address your most critical budget, storage management, and control challenges.


3

This chapter provides definitions and descriptions of Open Replicator capabilities. The full set of operational steps available to control any migration using Open Replicator is described. Specific migration scenarios using alternate control interfaces show examples of these steps in subsequent chapters. The topics covered include:

◆ Introduction ........................................................................................ 48◆ Definitions........................................................................................... 48◆ Basic Open Replicator migration operation flow.......................... 55◆ Monitoring, troubleshooting and recovery .................................... 65◆ Control interface alternatives ........................................................... 67◆ Reference information ....................................................................... 68

EMC Open Replicatorfor Symmetrix

EMC Open Replicator for Symmetrix 47

48


IntroductionEMC Open Replicator for Symmetrix enables remote point-in-time copies to be used for data mobility, remote vaulting, and migration between EMC Symmetrix VMAX (or Symmetrix DMX) and qualified storage arrays with full or incremental copy capabilities. Open Replicator can:

◆ Pull from source volumes on qualified remote arrays to a Symmetrix VMAX (or Symmetrix DMX) volume

◆ Push any live source Symmetrix VMAX (or Symmetrix DMX) volume to a target volume on a qualified array with incremental updates

◆ Perform online data migrations from qualified storage to Symmetrix VMAX (or Symmetrix DMX) with minimal disruption to host applications

DefinitionsThe Symmetrix VMAX (or Symmetrix DMX), where Open Replicator runs, and its devices are always referred to as the control side of the copy operation. Other Symmetrix arrays, CLARiiON arrays, or third-party arrays on the SAN are always referred to as the remote array/devices. Open Replicator supports two types of copy operations: push and pull. A push operation copies data from the control device to the remote device. A pull operation copies data to the control device from the remote device. Open Replicator has two modes of operation: cold (offline) and hot (online). Online and offline refer to the state of the Symmetrix VMAX (or Symmetrix DMX) resident devices (control devices). For data consistency reasons, the remote devices must never be written to by any host connected to the remote array. In cases where the remote device is the source of the Open Replicator copy operation (a pull operation), it may be permissible for a remote host to have read-only access to the remote device.

Hot push

Open Replicator can push data volumes out from a Symmetrix-either in a live mode (hot) or from a static copy or source volume (cold). For a live push, no local point-in-time copies of the volumes are required. The Symmetrix creates logical point-in-time copies without having to



allocate additional disk space, and I/O is permitted against the source volume during the transfer. If the application attempts a write to a location whose original point-in-time data has not yet been copied to the remote device, then Copy on First Write (COFW) applies, delaying the host I/O until the data is safely on the remote. All FA ports for the control devices must be configured (zoned and LUN masked) to see the remote devices, so that the FA which encounters the not-yet-copied data can perform the COFW itself. The initial hot push must be a full copy, and often includes the option to save differential information. The saved differential information is used when the hot push is recreated and activated, pushing only incremental changes since the previous activate. For data migration, this type of full hot push followed by repeated incremental pushes would be customary, with the final incremental push occurring while the application is shut down, allowing the remote copy to be fully up-to-date. Figure 2 illustrates an Open Replicator hot (or live) push.

Figure 2 Open Replicator hot (or live) push

To minimize the performance impact of COFW on production applications, Open Replicator provides a precopy option. When the precopy option is used, copying begins immediately at create or recreate time and runs in the background without taking a point in time image of the device. COFW is not invoked until the Open Replicator session is activated, marking the point-in-time that must be preserved. By copying most of the data before activation, COFW will occur less frequently because in most cases the data will have been copied to the remote before the first write.

Start: 6:00 a.m.

End: 6:15 a.m.

Image: 6:00 a.m.

TargetSTD

ICO-IMG-000434

Definitions 49

50


Cold pushFor cold push, the control devices must be presented as "not ready" to the host. This ensures that there will be no need for the Symmetrix to preserve the point-in-time or handle COFW. Rather than shutting applications down to obtain a static point-in-time, it is customary to use TimeFinder/Clone, TimeFinder/Mirror or TimeFinder/Snap to make an incrementally updateable point-in-time copy of the production data.

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

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

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



Figure 3 Open Replicator cold (or BCV) push

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

◆ Distance to the remote storage array is greater than 200 km or the COFW performance penalty is unacceptable to the production application.

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

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

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

Target

STD

BCV

ICO-IMG-000435

PS0 PS1 PS2 PS3 PS4 SMB0 SMB1

SB0

SB1

SB2

SB3

SB4

SB5

SB6

SB7

SB8

SB9

SB10

SB11

SB12

SB13

SB14

SB15

Target

Target

Definitions 51

52


must be configured (zoned and LUN masked) to see the remote devices in order to immediately perform the COFA. Open Replicator hot pull is a technology that supports Federated Live Migration (FLM). Figure 4 illustrates an Open Replicator hot (or live) pull.

Figure 4 Open Replicator hot (or live) pull

Donor update Since production applications are writing to the local (control) copy, there exists the potential for data loss due to a SAN failure or other connectivity issue during a hot pull operation. Until the Open Replicator copy is complete, some of the not yet copied data is only on the remote while some of the newly written data is only available locally on the control. The donor update option can be used to protect against this potential for data loss. When enabled, the donor update feature enables arrays to propagate (update) writes to the control device back to the remote device (donor) as data is being pulled from the remote device. When used, donor update ensures that the data on the local (control) and remote devices are consistent. As a result, new data written to the local (control) device will not be lost if an Open Replicator session has to be restarted before completing. With donor update enabled, data is first written to the target device, and then propagated to the remote source device; the host I/O write completes only if both writes are successful. Federated Live Migration (FLM) sessions using Open Replicator hot pull always use donor update.

Zero SpaceReclamation

When the target (control device) of a pull operation is a virtually provisioned (VP) device, zero space reclamation provides for improved storage space allocation and capacity utilization. If the incoming data is all zero and would cause an entire extent on the VP

STD

ICO-IMG-000436


SB0

SB1

SB2

SB3

SB4

SB5

SB6

SB7

SB8

SB9

SB10

SB11

SB12

SB13

SB14

SB15

PiTCopy

PiTCopy

STD



device to be written with zeros, that extent will be de-allocated instead of written with the data. Reclamation is a user selectable option when creating Open Replicator copy sessions.

Cold pull

Of course, a pull can also be performed in cold mode to a static Symmetrix VMAX (or Symmetrix DMX) volume. Because there is no special software running on the remote array, there is no mechanism to implement an incremental pull. Therefore, it is unlikely that cold pull would be used for a data migration unless it is acceptable to have the production applications shut down for the entire time it takes the migration to complete. Figure 5 illustrates an Open Replicator cold (or point-in-time) pull.

Figure 5 Open Replicator cold (or point-in-time) pull

Note: In the unlikely event that a cold pull is chosen to facilitate a given migration activity, if infrastructure permits, consider running those sessions as hot pulls to enable more choices to handle any issues that may arise without compromising downtime objectives.

Open Replicator interaction rules with SRDF

Prior to Enginuity 5874 and Solutions Enabler 7.0, certain interactions between Open Replicator and SRDF operations were blocked.

STD

Target

Target

ICO-IMG-000437


SB0

SB1

SB2

SB3

SB4

SB5

SB6

SB7

SB8

SB9

SB10

SB11

SB12

SB13

SB14

SB15

STD

STD

Target

Definitions 53

54


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

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

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

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

◆ Open Replicator pull operation



Basic Open Replicator migration operation flowThe basic operational flow for a migration using Open Replicator can be divided into three main phases: setup, migration and cleanup. This section will define 19 steps across all three phases. The migration and cleanup phase steps will continue numbering from the phase that precedes it, so that step numbers will be unique across the complete operational flow, not just within a phase. Not every step is necessary for any given migration. Steps are optional based on the particular type of migration (e.g., cold push vs. hot push, or hot pull). The decision point for optional steps is indicated by a parenthetical phrase in the numbered step listing, or a decision diamond in the flowchart representation. In chapters, 4–11, which detail specific migration examples, optional steps that do not apply are omitted, leaving gaps in the numbered step listings and grayed graphics in the flowchart representations. Chapters 8–9 provide details specific to using PPME with Open Replicator. Chapters 10–11 provide details specific to using FLM with Open Replicator.

Setup steps

There are up to six setup steps. They are:

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

2. Configure/connect migration SAN zones between remote ports and Symmetrix VMAX (or Symmetrix DMX) control FA "host" ports.

3. Configure LUN Masking for remote devices to allow access from Symmetrix VMAX (or Symmetrix DMX) control FA "host" ports.

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

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

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

Basic Open Replicator migration operation flow 55

56


Figure 6 illustrates the setup steps as a flowchart.

Figure 6 Setup steps flowchart

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

Note: When the Open Replicator source device is a VDEV, the relationship with the production device does not exist until the symsnap create command is executed. Exactly when the symsnap create operation is performed can vary, but it must occur before setup step 6, which includes the symrcopy create command. A VDEV control device can participate in only one Open Replicator session. Support for multi-virtual snap VDEV devices as Open Replicator source devices begins with Enginuity 5875.

Step 2 detail Because the Symmetrix VMAX (or Symmetrix DMX) FA port will act as an open systems host to the remote storage array, it is necessary to set up one or more migration SAN zones for access to the remote ports. This setup includes identifying the Symmetrix VMAX (or Symmetrix DMX) control FA ports World Wide Names (WWNs). For hot operations these WWNs must all be included in migration zone sets, for cold operations the WWNs can be selectively included in migration zone sets. It is also necessary to identify the remote storage array WWN for access to the remote devices. The actual zone definition operation can be completed with Connectrix Manager, Ionix ControlCenter SAN Manager, or native switch zoning tools.

ICO-IMG-000529

Hot pull?

6. Verify setup configuration, create

5. Define OR session pairs (file)

3. LUN mask remote devices to DMX FA

2. Zone DMX FA control to remote array

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

target devices to hostY

N



Step 3 detail Because the Symmetrix VMAX (or Symmetrix DMX) FA "host" is connected to the remote storage array on a switched fibre port, it is necessary to perform LUN masking so that the Symmetrix VMAX (or Symmetrix DMX) FA initiator is defined as having access to the remote devices. This LUN masking is performed with tools specific to the remote storage array. Commands for performing this operation for a remote CLARiiON array are introduced in the next chapter, and device (LUN) masking for a remote Symmetrix will be shown in subsequent examples.

Step 4 detail For Symmetrix, device masking is the term used for LUN masking (for Symmetrix VMAX arrays, the Auto-provisioning Groups feature provides an easier, faster way to provision storage replacing the old way of configuring device masking). Before a migration is complete it is always necessary to ensure that the appropriate host applications are able to access the target devices in place of the original source devices. For hot pull migrations, this step is performed prior to initiating the movement of data from the source (remote) to the target (control).

Step 5 detail Open Replicator requires the definition of control-remote pairs; multiple pairs are grouped into a single file in?order to be managed together. There are three formats for specifying devices in this file: device WWN, Symmetrix device name or CLARiiON device ID. Device WWN can always be used for any device. The Symmetrix device name format can always be used for the control device and in some cases for the remote device. If the Solutions Enabler database has discovered the remote Symmetrix or CLARiiON array, then the Symmetrix or CLARiiON device format can be used for the remote device. When using the SMC GUI, the process of selecting control and remote devices is made easier with the ability to selectively filter a list of available devices. The WWN format can easily be selected with a click, avoiding the need to correctly enter the lengthy WWN strings.

Step 6 detail The final setup step is to use the defined control-remote pair file (or GUI selection) to create the Open Replicator session. The create operation validates all necessary control FA access to remote devices and will fail if the pair definition, zoning or LUN masking is not defined correctly. The create action can be considered part of the setup phase because it does not begin migration data movement in most cases (hot push operations that specify the -precopy option do initiate migration data movement).


58


Note: In some cases, SCSI reservations for devices under cluster control or the AIX operating system will prevent the create operation from being successful. In this case alternate verification options can be used; more information about these options is available in “Setup step 6: Verify completion of setup steps” on page 80.

Note: The symrcopy create command is described to be the most thorough test for verifying the completion of the Open Replicator setup phase. The alternative methods of verifying the completion of the setup phase (without running the symrcopy create action) are not sufficient when using a VDEV control device. The specific order of operations requires that the symrcopy create command is executed before the symsnap activate command in migration step 7.



Migration stepsA single migration will use four to seven of the eight potential migration steps. Note that step numbering continues at seven to follow the last setup step. The migrations steps are:

7. Split the BCV or activate the clone or VDEV(optional for cold push migrations from a BCV, clone or VDEV).

8. Move all resources to a single cluster node, and create the Open Replicator session(only needed if the session was not created during setup and not terminated as part of step 7).

9. Stop the application (only for pull migrations).

10. Activate the Open Replicator session.

11. Restart the application pointing to the target (control) devices,(only for hot pull migrations).

12. Tune migration to an acceptable level of impact on production application (optional).

13. Verify Open Replicator copy session is finished.

14. Iteratively apply incremental updates (customary for push migrations).

a. Use TimeFinder to incrementally update the control devices (only for cold push).

b. Recreate and activate the Open Replicator session to incrementally update the remote.

c. Repeat steps 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 final incremental push.

15. Verify migration is complete and terminate Open Replicator session.

Figure 7 on page 60 illustrates the migration steps as a flowchart.


60


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



Steps 7 through 15detail

Steps 7 through 15 consist of the following:

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

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

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

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

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

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

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

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

◆ Step 14, iteratively applying incremental updates, is necessary for push migrations to propagate production application changes to the target (remote) until production application changes cease when the applications are stopped.


62


When using a VDEV control device, step 14a, the TimeFinder incremental update, cannot activate the recreated TimeFinder/Snap session before the Open Replicator session is first recreated. Similarly, the symrcopy activate in step 14b cannot precede the symsnap activate (which again includes the -not_ready option to keep the VDEV in the Not Ready state). Therefore when using TimeFinder/Snap the order of operations for steps 14a-14b must be:

1. symsnap recreate 2. symrcopy recreate 3. symsnap activate -not_ready

4. symrcopy activate

◆ Step 15, terminate the Open Replicator session, is completed once the migration is verified because data migration is the one time movement of data from source to target so the session is no longer needed. The symrcopy terminate command must precede any symsnap terminate commands.



Tuning Open Replicator — Typically there are two conflicting performance goals for a data migration. First, it is necessary for the migration to complete within the planned for migration window. Second, the data migration should not cause unacceptable levels of performance degradation for production applications. Open Replicator shares the processing power of the front-end fibre (FA) director and the bandwidth of the fibre path with the production applications. Open Replicator provides three alternatives for tuning Open Replicator performance: the ceiling parameter which limits fibre bandwidth that can be used by Open Replicator, the pace parameter which defines delays added between Open Replicator operations, and the nocopy mode which suspends Open Replicator copy activity.

The primary tuning mechanism is the Open Replicator ceiling parameter. Ceiling is set to the maximum percentage of the fibre bandwidth that can be used by Open Replicator. By default this value is not set, theoretically allowing Open Replicator to use up to 100 percent of the bandwidth. The secondary tuning mechanism is the pace parameter. Pace is a value set between 0 and 10 (default 5), which translates to a position in a table that adds a delay between Open Replicator I/O transfers. The larger the pace value, the longer the delay.

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

Ceiling is considered the best tuning mechanism because it delivers fixed, accurate, repeatable results that can be based on observed and calculated values. Pace values greater than zero will always add Open Replicator processing delays, even when Open Replicator I/Os would not get in the way of production applications. The PPME throttle mechanism is an alternate interface to the Open Replicator pace parameter. The pace value is ignored for all participating director/port combinations where the ceiling value is not NONE, including PPME and FLM Open Replicator sessions.


64


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 the original source devices (needed for all but hot pull operations).

19. Redeploy the source devices storage now that the migration is complete.

Figure 8 Cleanup steps flowchart

Step 18, restart production applications to reference the target devices, is the main task in the cleanup phase.

Steps 16 and 17 prepare for this step by removing the source devices in step 16 and adding the target devices as host visible devices in step 17. In the case of hot pull steps 16–18 are skipped because the production applications were restarted using the target devices in the migration phase.

ICO-IMG-000531

19. Redeploy source devices storage

18. Restart applications using target devices

17. Make target devices ready to host

16. Make source devices inaccessible to host

Hot pull?Y

N



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

These steps are identified as being in the cleanup phase because Open Replicator actions ended with the termination of the session in the migration phase. PowerPath Migration Enabler (PPME) includes alternate commands to achieve the outcomes of step 11 and steps 15–18 for hot pull operations under PPME control. These alternate commands provide the PPME advantages of greatly reducing or eliminating application disruptions due to these steps, reducing migration risk, and simplifying migration operations.

Note: Chapter 8, “PowerPath Migration Enabler Overview,” introduces a more comprehensive and reordered description of these alternate cleanup steps.

Monitoring, troubleshooting and recoveryBest practices for monitoring, troubleshooting and recovery will be shown in the examples detailed in the following chapters. The range of tools available will first be introduced here. When using Open Replicator the vast majority of problems encountered result from errors in setting up the initial zoning and LUN masking. This chapter introduced the Open Replicator create action as an effective tool to verify complete setup.

Chapter 4, “Cold Push to CLARiiON Setup Example,” will go into additional detail for interpreting setup errors reported by create and alternatives to create for verifying correct setup. Once a migration is started, there are basic tools for monitoring the copy session progress. The query action will list the status of the control and remote pairs and the progress of the copy sessions. The verify action can be used to determine if an expected status exists, and the interval and count options can be set up to loop until the desired state is achieved. The return code from verify operations can be used effectively within a script to branch based on the status of the copy sessions. Besides 100 percent completion of a copy operation, the other important status to deal with is a failed copy operation. Recovery from a failed operation is generally dealt with by simply

Monitoring, troubleshooting and recovery 65

66


restarting the copy operation and taking a new point-in-time. In the case of hot pull, a new point-in-time would only be valid on the remote, provided the -donor_update option was used.

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



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

Solutions Enabler CLI

The Solutions Enabler Command Line Interface (SYMCLI) supports EMC Open Replicator for Symmetrix operations with the symrcopy command. The symsan command, which lists ports visible from a given director port and LUNs visible behind a given remote port, is particularly helpful for verifying that zoning and LUN masking has been correctly configured for Open Replicator operations. Configuration of devices, mapping, and masking is also supported by the symconfigure, symmask and symmaskdb commands. Output available from symdev, sympd, and symcfg commands may also be helpful in manually verifying key Open Replicator related information.

Symmetrix Management Console GUI

The Symmetrix Management Console (SMC) Graphical User Interface (GUI) supports EMC Open Replicator for Symmetrix operations with the Open Replicator create and session control wizards. The create wizard gets invoked from the control menu for the local Symmetrix array. This five-page wizard progressively moves the user through the process of specifying all of the information needed to create an Open Replicator session:

1. Set session parameters

2. Select control devices

3. Select remote devices

4. Select device pairs

5. Set create options, and execute

If device pairs definitions are available from a previously saved file, the wizard jumps from page 1 to page 5. Once created, Open Replicator session control is available from the Control, Replication

Control interface alternatives 67

68


menu. SMC also supports Remote Report, which like symsan lists ports visible from a given director and LUNs visible behind a given remote port.

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

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

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

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


4

This chapter provides an operational example of the setup phase. Together with Chapter 5, “Cold Push to CLARiiON Migration Example,” a complete example of all the steps needed to execute a cold push using SYMCLI on a Solaris host is provided. Alternate examples for verifying successful completion of the setup step is presented. The topics covered include:

◆ Introduction ........................................................................................ 70◆ Setup step 1: Identify target devices................................................ 71◆ Setup step 2: Configure migration SAN zones .............................. 73◆ Setup step 3: Configure migration LUN masking......................... 78◆ Setup step 5: Prepare Open Replicator session pairs.................... 79◆ Setup step 6: Verify completion of setup steps .............................. 80

Cold Push to CLARiiONSetup Example

Cold Push to CLARiiON Setup Example 69

70

Cold Push to CLARiiON Setup Example

IntroductionThis chapter details the setup steps for a cold push to a CLARiiON using Solutions Enabler SYMCLI on a Solaris host. Because step 4 of the setup steps introduced in chapter 3 is only completed for hot pull migrations, it is omitted from the listing of numbered steps below:

1. Configure (provision) or identify the target devices

2. Configure/connect migration SAN zone between remote devices and Symmetrix VMAX (or Symmetrix DMX) control FA "host" ports.

3. Configure LUN Masking for remote devices to allow access from Symmetrix VMAX (or Symmetrix DMX) control FA "host" ports.





Setup step 1: Identify target devicesAs mentioned in “Step 1 detail” on page 56, the target devices of the migration must be configured (provisioned) if they do not already exist. For Symmetrix arrays, the Solutions Enabler symconfigure command, SMC's Device Configuration screens or Ionix ControlCenter Symmetrix Manager can be used to configure target devices of an equal or greater size than the source devices. For all remote devices it is necessary to know the device world wide name (WWN). However, if the remote Symmetrix or CLARiiON device has been discovered and is in the Solutions Enabler database file, then the Symmetrix or CLARiiON array ID and device number ("name") can be used in place of the WWN. Open Replicator will use the array specific identification to obtain the WWN from the database file. This is generally easier to use than dealing with lengthy WWN strings.

In order to discover a CLARiiON, the symcfg authorization command must first be used to associate a CLARiiON storage processor IP address with a username and password. The discover operation requires either the -clariion option to discover only CLARiiON arrays, or the -all option to discover both Symmetrix and CLARiiON arrays. Once discovered, information about the CLARiiON devices can be displayed using the -clariion option. An example is given on page 72.

Setup step 1: Identify target devices 71

72


# symcfg authorization add -hostname nnn.nnn.nnn.nnn -username name -password password

# symcfg discover -all

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

# symcfg list -clariionC L A R I I O N

Firmware Num Num Phys Num Clar ClarID Model Version Disks Devices Devices

HK190807410004 CX3_40_F 3.24.40.5.014 15 4 10

# symdev list -clariion

Clariion ID: HK190807410004

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

00000 Not Visible Raid-5 4096 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 the database, then it is necessary to use the WWN. The Solutions Enabler syminq command and the similar inq command can be used to display WWN information for Symmetrix, CLARiiON and third-party arrays. For example:

# syminq -clariion -cids -wwn Device Device--------------------------------- ------------------- ---------------------------------Name Num Array ID WWN--------------------------------- ------------------- ---------------------------------/dev/rdsk/c2t5006016A41E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/rdsk/c2t5006016241E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/rdsk/c4t5006016041E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/rdsk/c4t5006016841E087E6d0s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/rdsk/emcpower3c 0009 HK190807410004 600601602B401E001078C2A48A47DD11/dev/vx/rdmp/emcpower3s2 0009 HK190807410004 600601602B401E001078C2A48A47DD11

#



Setup step 2: Configure migration SAN zonesAs the Symmetrix VMAX (or Symmetrix DMX) FA port will act as an open systems host to the remote storage array, it is necessary to set up one or more migration SAN zones for access to the remote devices. Therefore, both the local (control) director WWN(s) and the remote front-end WWN(s) must be determined.

Determining Control Director WWN

The control is always a Symmetrix device, so Solutions Enabler, SMC or Ionix ControlCenter can be used. First it must be determined on which directors the control devices are visible. The Solutions Enablersymdev list -multiport command is one of the easiest ways to obtain this information. In the following example, the four control devices: 80, 81, 82 and 83, are all mapped to both director 2C port 0 and director 15C port 0.

# symdev -sid 359 list -range 80:83 -multiport

Symmetrix ID: 000190300359

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

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

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 than one path. If there is only a single path, then symdev list should be used without the -multiport option.

Setup step 2: Configure migration SAN zones 73

74


The FA director port world wide port name (WWPN or WWN) can be displayed using the symcfg list command. For example:

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


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

Dir Port WWN VCM Volume Set Pnt to Pnt Enabled Addressing

FA-2C 0 5006048AD5F031C1 Yes No Yes

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



Dir Port WWN VCM Volume Set Pnt to Pnt Enabled Addressing

FA-15C 0 5006048AD5F031CE Yes No Yes

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

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



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

Figure 9 Invoking Connectivity Status for Host in a Storage Group

Figure 10 on page 76 shows that four paths between the CLARiiON and host LICOD229 can be used to access LUNs 4, 5, 6 and 7. However, the CLARiiON LUNs are owned by only one SP at one time. For fault tolerance, a LUN can trespass over to the other SP; therefore it is necessary to define paths for the currently passive SP as well.

ICO-IMG-000532


76


Figure 10 Host connectivity status for a CLARiiON storage group.

Figure 11 shows all of the Front End Port WWPNs, with ports 0 and 2 highlighted for both SPA and SPB.

Figure 11 CLARiiON CX3-40f Storage Processor World Wide Port Names

For a remote third-party array, it is necessary to use tools specific to the array to determine the WWPNs to use in the zoning.

ICO-IMG-000533

ICO-IMG-000534



Selective or all Symmetrix FA ZoningFor cold operations it is not necessary to zone all possible paths. This allows the user to limit migration movement to selective paths. For hot operations it is required that all Symmetrix FA ports that are mapped by the control devices be zoned and LUN masked to "see" the remote devices.

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

Figure 12 Connectrix Manager activate zone verification screen

ICO-IMG-000535


78


Setup step 3: Configure migration LUN masking

Create CLARiiON storage group

Because the Symmetrix VMAX (or Symmetrix DMX) FA "host" is connected to the remote storage array on a switched fibre port, it is necessary to perform LUN masking to grant the Symmetrix VMAX (or Symmetrix DMX) FA initiator access to the remote devices. This LUN masking is performed with tools specific to the remote storage array. Here, an example of Storage Group based LUN masking for the CLARiiON using navicli is presented.

The default location of Navisphere executables on UNIX operating systems is /opt/Navisphere/bin. The network hostname for the CLARiiON SPA IP address is Clar0031_SPA. First, the Storage Group OR_Symm359 is created by executing a command that looks something like this:

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

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

# ./navicli -h Clar0031_SPA storagegroup -setpath -gname OR_Symm359 -hbauid 50:06:04:8A: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



Setup step 5: Prepare Open Replicator session pairsOpen Replicator requires the definition of control-remote pairs. Multiple pairs grouped into a single file can be managed together by Open Replicator. The control device is identified in the first (leftmost) column and the remote device is identified in the second (rightmost) column.

The array ID must be fully specified and is separated from the device/LUN name (number) by a colon. Since the CLARiiON was discovered into the SYMAPI database file (“Setup step 1: Identify target devices” on page 71), the clardev= format can be used for the remote devices in the file:

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

Setup step 5: Prepare Open Replicator session pairs 79

80


Setup step 6: Verify completion of setup steps

Create action is a thorough verification step

The most thorough test for verifying the completion of the setup steps is to create the Open Replicator session. The create operation verifies all necessary control FA access to the remote devices and will fail if the pair definition, zoning or LUN masking is not correctly defined. Create does not begin the migration itself, except in the case when the -precopy option is specified for hot push operations. In some cases, SCSI reservations for devices under cluster control will prevent the create operation from being successful. In these cases alternate verification options, presented next, can be used in place of the create.

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

Verify zoning with symsan -sanportsSolutions Enabler 6.4 with Enginuity 5772 introduced the symsan command, which was designed explicitly for verifying the correct Open Replicator zoning and masking. The zone OR_Symm0359_2C0_Clar0031_SPB_0 created in the “Example configuration of migration SAN zones” on page 77 included the WWN for Symmetrix FA director 2C port 0, and the WWN for CLARiiON SP B port 0. The zone OR_Symm0359_2C0_Clar0031_SPA_0 included the same Symmetrix FA WWN with the CLARiiON SP A port 0, in case of LUN trespass from SP B to SP A. The symsan -sanports command lists the WWNs that are zoned together with the specified Open Replicator FA port. The Remote Port WWN 5006016841E087E6 is the SP B port 0 WWN. The Remote Port WWN 5006016041E087E6 is the SP A port 0 WWN. The symsan output also identifies the array as a CLARiiON, including the array ID and also the number of LUNs visible behind each WWN. A greater than zero Num LUNs value



indicates the number of LUNs that are successfully LUN masked. Since four LUNs were expected this could be interpreted as successful remote LUN masking. For example:

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


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

Setup step 6: Verify completion of setup steps 81

82


Verify LUN masking with symsan -sanlunsIn order to be certain that the correct LUNs are masked, the symsan -sanluns command can be used to list the LUN WWNs behind the Remote Port WWN. In the output produced by this command, the Dev Num (Device Number) column indicates the CLARiiON device number. Additionally each record can be checked for the correct device Capacity.

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

Symmetrix ID: 000190300359Remote Port WWN: 5006016841E087E6

ST A T Flags Block Capacity LUN Dev LUNDIR: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

Legend: Flags: (I)ncomplete : X = record is incomplete, . = record is complete. (C)ontroller : X = record is controller, . = record is not controller. (R)eserved : X = record is reserved, . = record is not reserved. (T)ype : A = AS400, F = FBA, C = CKD, . = Unknown

t(H)in : X = record is a thin dev, . = record is not a thin dev. (S)ymmetrix : X = Symmetrix device, . = not Symmetrix device

Note: Beginning with Solutions Enabler 7.0, the symsan command added two flags to indicate thin device and Symmetrix device. The indicator is helpful if running with a release before Enginuity 5875 which added support for virtual provisioned (thin) devices to be source devices for Open Replicator. Open Replicator pull support for iSeries requires the remote device to be on a Symmetrix array.



Verify zoning with symmask list loginsIf the Solutions Enabler version is less than 6.4.2 or the Symmetrix Enginuity level is less than 5772.83, the symsan command is not available. In this case, the symmask list logins command can be used to determine if the zoning was successful. At the time of activating the zone including the OR FA port "host," all participants in the zone should log on to the SAN fabric. The display below shows WWN Identifiers On Fabric, but not Logged In with the standard CLARiiON prefix 500601 (Logged In will change to Yes after an Open Replicator activate action). The full WWN match the WWN for SPA port 0 and SP B port 0. For example:

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

Symmetrix ID : 000190300359

Director Identification : FA-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 that the reported state is not necessarily current. The key is the first appearance of the WWN. However once on fabric, the information remains on the list logins output regardless of whether the WWN is currently On Fabric. For Symmetrix VMAX, symaccess list logins would be used in place of symmask.


84


Verify all with symrcopy createUnless working in a special case dealing with device reservations (e.g., windows clustering) or not wanting to begin a hot push which includes the -precopy option, it is wise to fully test the setup by creating the Open Replicator session.

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

Using the cold_orpairs file from “Setup step 5: Prepare Open Replicator session pairs” on page 79 the cold push is created as follows:

# symrcopy -file cold_orpairs -push -cold create

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

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

As mentioned when first defining “Cold push” on page 50, cold operations require the control devices to be in the Not Ready state. This can be verified as follows:

# cat cold_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 all necessary zoning and LUN masking is correctly in place.


86


SMC Remote ReportThe Symmetrix Management Console provides a GUI equivalent to symsan. Figure 13 illustrates invoking the Remote Report menu from an initial right click of the control Symmetrix array, and choosing Replication Open Replicator Remote Report.

Figure 13 SMC Remote Report menu selection

ICO-IMG-000536



Remote Report has two tabs. Figure 14 illustrates the Remote Ports tab showing information similar to the symsan -sanports display for director 2C port 0.

Figure 14 SMC Remote Report Remote Ports

Clicking on the Remote Luns tab and selecting director 2C automatically selects the first WWN displayed in the Remote Ports display. Figure 15 illustrates the Remote Luns tab display:

Figure 15 SMC Remote Report Remote LUNs display

ICO-IMG-000537

ICO-IMG-000538


88


Additionally, the GUI selection of remote devices populates the available list with the successfully mapped remote devices. Figure 16 illustrates page 3 of the Create Copy Session wizard where the available remote devices are populated from the Remote Report information.

Figure 16 Create Page 3 showing CLARiiON Available Remote Devices

ICO-IMG-000539


5

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

◆ Introduction ........................................................................................ 90◆ Migration step 7: BCV split............................................................... 93◆ Migration step 8: symrcopy create .................................................. 98◆ Migration step 10: symrcopy activate ........................................... 102◆ Migration step 12: symrcopy set ceiling ....................................... 103◆ Migration step 13: symrcopy query and verify ........................... 105◆ Migration step 14: Iterative symrcopy recreate ........................... 106◆ Migration step 15: Verify migration and symrcopy terminate .. 110◆ Cleanup step 16: Make source devices host inaccessible ........... 112◆ Cleanup step 17: Make target devices ready to host................... 113◆ Cleanup step 18: Restart applications using targets ................... 114◆ Cleanup step 19: Redeploy the source devices’ storage ............. 116

Cold Push to CLARiiONMigration Example

Cold Push to CLARiiON Migration Example 89

90

Cold Push to CLARiiON Migration Example

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

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

8. Open Replicator session create.


12. Tune migration to acceptable level of impact on production application.


14. Iteratively apply incremental updates.

a. Use TimeFinder to incrementally update the control devices (only for cold push).

b. Recreate and activate the Open Replicator session to incrementally update the remote.

c. Repeat steps 14a–14b until all updates have been processed, shut down the application before the last update in step 14a to eliminate changes during the final incremental push.

15. Terminate Open Replicator session.

Also briefly covered will be the four applicable cleanup steps:

16. Make the source devices inaccessible to the host.

17. Make the target devices ready to the host.

18. Restart the application pointing to the target devices in place of the original source devices.




Figure 17 on page 92 illustrates the cold push migration and cleanup steps in a flowchart. The paths from decision diamonds which is not taken and omitted steps are grayed to show they are not conducted for this cold push example. The step 14 detail, which includes three substeps (a–c) and related decision diamonds, shows all paths and steps without graying, because each path and step is performed at least once.

Introduction 91

92


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



Migration step 7: BCV split

Device Group creation

For a cold push, it is common to use a TimeFinder/Mirror BCV, TimeFinder/Clone BCV or target device, or TimeFinder/Snap VDEV as the control device; this example will use a TimeFinder/Mirror BCV device. For this example the application uses the file system at mount point /cphome, a VxVM logical volume made up of 4 Symmetrix devices: 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 volume cplv, 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 that make up the volume group cpvg use pseudo device names emcpower380s2 – emcpower383s2.

Migration step 7: BCV split 93

94


# sympd list -sid 359 -powerpath


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

Device Name Directors Device------------------------------------- ------------------------------------------------- CapPhysical 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 logical volumes A0–A3 correspond to pseudo device names emcpower380s2–emcpower383s2. The example below: creates the device group cpgroup and populates it with the STD application devices A0–A3. Since, TimeFinder/Mirror BCVs will be used as the source devices for Open Replicator, BCV devices 80–83 are associated with the device group.

# symdg create cpgroup# symld -g cpgroup addall -sid 359 -range a0:a3# symbcv -g cpgroup associateall -range 80:83

#If TimeFinder/Clone was being used, a BCV could be used in the same way or target devices (TGT) could be added to the group with the following command: symld -g cpgroup add dev NN -tgt

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



Initial TimeFinder/Mirror establishMigration step 7 is to split the BCV. Since the initial state of the BCV is Never Established, it is necessary to first synchronize the BCV with the STD. Before the BCV can be used in a full establish operation, the Open Replicator session created earlier as part of verifying completion of the setup phase must be terminated. Depending on the Open Replicator state, Solutions Enabler will block TimeFinder/Mirror operations on Open Replicator control devices to ensure that the contents are not changed in the middle of Open Replicator operations. Here is an example of Solutions Enabler blocking the TimeFinder/Mirror operation:

# symmir -g cpgroup establish -full -opt

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

'Full Establish' operation execution is in progress 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 (in nondata migration situations, the Restored state without donor update enabled is also valid). Terminating the session will also avoid any operational conflicts, and is appropriate in this case because the BCV control device needs to have the correct data before the first Open Replicator copy session. Here is an example of first terminating the Open Replicator session, and then seeing the TimeFinder/Mirror operation work without being blocked:

# symrcopy -file cold_orpairs terminate

Execute 'Terminate' operation for the 4 specified 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'.


96


#

TimeFinder/Mirror splitBefore the BCV devices can be split, the synchronization must be complete, and the verify action using the interval option(-i) is an easy way to wait for synchronization to complete. From the synchronized state the split action is permitted. The split action has multiple options for specifying a consistent split. In this case the vxfs mountpoint specified will be frozen just before the instant split is performed and thawed as soon as the foreground split completes. The -vxfs option can only be used when running on the production host; when using a control host the -consistent option can be used instead. For this example and with other cold pushes using a BCV or clone, consistency is obtained using TimeFinder rather than using similar consistency options with the symrcopy activate action. For example:

# symmir -g cpgroup verify -synched -i 30

Not All devices in the group 'cpgroup' are in 'Synchronized' state.

Not All devices in the group 'cpgroup' are in 'Synchronized' state.

All devices in the group 'cpgroup' are in 'Synchronized' state.

# symmir -g cpgroup split -instant -vxfs /cphome

Execute 'Split' operation for device group'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 split action to put the Open Replicator source device in the Not Ready state as required for a cold push. This option was left out in this example to show how to correctly overcome its omission in ”Cold control devices must be Not Ready,” on page 98.

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

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


98


Migration step 8: symrcopy create

Cold control devices must be Not Ready

The first attempt at executing the create action will fail, because the TimeFinder/Mirror split operation leaves the BCV devices in the Ready state, and Open Replicator control devices in a cold session must be in the Not Ready state. For example, here is a create attempt and the corresponding error message:

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



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

#An alternate way to control this group of devices, besides the list within a file used in “Verify all with symrcopy create” on page 84, is to use the device group created for the TimeFinder operations. The -bcv option will cause the not_ready action to only be applied to the BCV devices associated with the device group (the production devices 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.#



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

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



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

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

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

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

◆ The -differential option directs Open Replicator to keep track of changes to the control devices, providing the ability to push incremental updates to the remote.

◆ The -name cold_push option defines a session name for all the pairs defined in the cold_orpairs file, providing an alternate method of specifying which pairs are addressed by the symrcopy command.

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

Migration step 8: symrcopy create 99

100


Open Replication query displayThe query (or verify) actions can be used to show the copy session in the Created state. Note the use of the named session cold_push to refer to the control/remote pairs of interest. The CD value for the RI flags indicate the display of the remote device using the CLARiiON ID and device name rather than the LUN WWN. Additionally the CDSHU flag settings indicate the use of -copy, -differential, -push, and -cold options for this copy session.

# symrcopy -session cold_push query

Session Name : cold_push

Control Device Remote Device Flags Status Done---------------------------- ----------------------- ----- -------------- ---- 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) 262140 MB(s) 16383.8

Legend:R: (Remote Device Vendor Identification) S = Symmetrix, C = Clariion, . = Unknown.

I: (Remote Device Specification Identifier) D = Device Name, W = LUN WWN, World Wide Name.

Flags:(C): X = The background copy setting is active for this pair. . = The background copy setting is not active for this pair.(D): X = The session is a differential copy session. . = The session is not a differential copy session.(S): X = The session is pushing data to the remote device(s). . = The session is pulling data from the remote device(s).(H): X = The session is a hot copy session. . = The session is a cold copy session.(U): X = The session has donor update enabled. . = The session does not have donor update enabled.(*): The failed session can be reactivated.

#



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

# symrcopy -session cold_push query -detail


Control Device Remote Device Flags Status Done Pace Name------------------------------------ ----------------------- ----- -------- ---- ---- --------- Protected 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. . .

Migration step 8: symrcopy create 101

102


Migration step 10: symrcopy activateActivate sets the point-in-time for the push of data from the control to the remote. In this case of cold push, there is no need for consistency options, as these were already used as part of the TimeFinder/Mirror split operation. Notice that after the activate, the Status has changed to CopyinProg(ress) and the number of Protected Tracks for each device is reduced from the starting value of 65535 as tracks are copied to the remote.

# symrcopy -session_name cold_push activate

Execute 'Activate' operation for the 4 specified 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


Control Device Remote Device Flags Status Done---------------------------- ----------------------- ----- -------------- ---- 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) 261469 MB(s) 16341.8. . .



Migration step 12: symrcopy set ceilingAs shown earlier with the query -detail, by default the pace parameter is set to five, which significantly slows copy operations by inserting delays.

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

Unlike the pace parameter which is session based, the ceiling value is director/port based and affects all sessions that use those ports. Since both ports 2C:0 and 15C:0 are used by the production devices and could be used by Open Replicator, the ceiling is set on both ports by executing the following commands:

# symrcopy set ceiling 30 -sid 359 -dir 2c -port 0

Execute 'Set Ceiling' operation (y/[n]) ? y

'Set Ceiling' operation execution is in progress'Set Ceiling' operation successfully executed# symrcopy set ceiling 30 -sid 359 -dir 15c -port 0

Execute 'Set Ceiling' operation (y/[n]) ? y

'Set Ceiling' operation execution is in progress'Set Ceiling' operation successfully executed

#

Migration step 12: symrcopy set ceiling 103

104


In actual practice, it would be better to set the ceiling prior to any Open Replicator I/O taking place (i.e., before the activate). The setting of performance parameters is shown at this point in the operational sequence because it is possible that active tuning might be altered at various points of the migration versus setting a single value that is always in place.

Just as the detailed query can be used to show the pace setting, there is a list ceiling operation that can be used to display the ceiling values, and that also shows the current Open Replicator use of bandwidth. In the following example, only director port 2C:0 shows bandwidth use, because director port 15C:0 was not zoned and LUN masked for this cold push.

# symrcopy -sid 359 list ceiling


Symmetrix Remote Copy Bandwidth Ceiling

Max Set Actual Dir:P (MB) (%) (MB) ----- ---- ---- ------ 01C:0 150 NONE 0 01C:1 150 NONE 0 02C:0 150 30 14 02C:1 150 NONE 0 15C:0 150 30 0 15C:1 150 NONE 0 16C:0 150 NONE 0 16C:1 150 NONE 0#



Migration step 13: symrcopy query and verifyThis step consists mostly of waiting until the Open Replicator copy completes for the point-in-time of the activate. The query action will report the Status, the decreasing number of Protected Tracks, and the increasing Done percent. The normal status sequence goes from CopyInProg to Copied. Using the verify action allows scripts to wait for a particular status. The use of the count (-c) option limits how long to wait and the program can check for unsuccessful return status indicating an exit from the loop due to the count being reached rather than reaching the waited for status.

In the following example, the interval (-i) of 300 seconds (5 minutes) with a count of 36 means waiting for three hours (180 minutes). In the example, the Copied state was reached within the three-hour time limit for checking. It is important to specify a realistic time limit based on the amount of data to be copied and the bandwidth or other tuning limitations that will affect how long the copy could take to complete.

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

#

Migration step 13: symrcopy query and verify 105

106


Migration step 14: Iterative symrcopy recreate

Incrementally update control devices from production devices

Because a cold push from a BCV is based on a point-in-time that does not include all of the application writes to the production device, it must be incrementally updated with the writes since the activation of the last cold push. This is done using a combination of TimeFinder/Mirror commands to incrementally update the BCV and Open Replicator commands to incrementally update the remote devices.

To avoid Solutions Enabler blocks on TimeFinder interactions with Open Replicator, the simple rule to follow is that the Open Replicator session should be in the Copied state when attempting TimeFinder operations. In “Migration step 13: symrcopy query and verify”, the last status verified was the Copied state. In the following example, TimeFinder/Mirror is used to incrementally establish (update) the BCV, verify the BCVs are synchronized with the production devices, and then consistently split the BCVs. Also included here is the -not_ready option to keep the BCVs in the Not Ready state as required for Open Replicator cold operations.

# symmir -g cpgroup establish

Execute 'Incremental Establish' operation for device group'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.




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

If TimeFinder/Snap had been used in place of TimeFinder/Mirror, the TimeFinder incremental update, cannot activate the recreated TimeFinder/Snap session before the Open Replicator session is first recreated. Similarly, the symrcopy activate cannot precede the symsnap activate (which again includes the -not_ready option to keep the VDEV in the Not Ready state). Therefore when using TimeFinder/Snap the order of operations for iterative update must be:

5. symsnap recreate 6. symrcopy recreate 7. symsnap activate -not_ready

8. symrcopy activate

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

# symrcopy -session cold_push recreate

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

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

Migration step 14: Iterative symrcopy recreate 107

108


'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





#

Stop applications and final incremental updateIn order to end the iterative loop of incremental updates, it is necessary to stop production applications from writing to the production devices. The file system is displayed here as a simplistic method for comparing with the migrated copy in “Migration step 15: Verify migration and symrcopy terminate” on page 110. In this example, the change directory (cd) away from the mounted filesystem emulates stopping the application, and is required before the filesystem can be unmounted. Once the filesystem is unmounted, the volume group can be deported from VxVM, and the disks can be removed from VxVM.

# cd /cphome# ls -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 as in “Incrementally update control devices from production devices” on page 106 and “Incrementally update remote devices from control devices” on page 107. The count value on the verify checks is lower since there is less data to update. The TimeFinder/Mirror split operation cannot freeze the file system since it is now unknown (and effectively frozen) due to the umount and deport operations performed earlier. In the following example, the -noprompt option is used to skip the control action verification queries. Since there are no new writes, after completion of this last incremental update the Open Replicator remote devices are fully synchronized with the production devices.

# symmir -g cpgroup establish -noprompt

'Incremental Establish' operation execution is in progress 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...


# 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





#

Migration step 14: Iterative symrcopy recreate 109

110


Migration step 15: Verify migration and symrcopy terminateBefore terminating the Open Replication copy sessions (and losing all differential information), it is best to conduct some type of application specific verification that the remote devices are a complete and valid replacement for the original production devices. This will be shown as a comparison with the list directory of the production devices later in “Cleanup step 18: Restart applications using targets” on page 114. In a true production data migration, best practice would include bringing the application up in a test mode using the migrated data to verify that the application will work without fail. The depth and breadth of this type of verification will vary depending on the business requirements for each data migration. Once verified, the Open Replicator sessions are no longer needed and can be terminated as follows:

# symrcopy -session cold_push terminate

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 command must precede any symsnap terminate commands.

Hot push differences from cold pushThis TechBook does not include an entire example of hot push, because the operations are very similar to those just shown for cold push. There is a difference in the required setup, because hot operations require all capable ports to be zoned and LUN masked. This difference will be covered in detail in Chapter 6, “Hot Pull from CLARiiON Migration Example.” A partial hot push example is included in “Reactivate Failed Session” on page 295.



There are two key operational differences between a hot and cold push. First, with a hot push there is no need for BCV or Clone devices; the activate takes a point-in-time on the actual production devices, using Copy on First Write (COFW) to handle production write I/Os to data not yet copied to the remote devices. Second the control devices can be in the Ready state since COFW is in effect.

Operationally, this means there is no need for the TimeFinder operations or the not_ready device control operations. The Open Replicator activate action will likely use the -consistent option to ensure a consistent point-in-time, since this is no longer done separately using TimeFinder/Mirror or TimeFinder/Clone. Additionally, the create and recreate actions will often use the -precopy option to minimize the COFW performance penalty on the production devices. In order to get the most benefit from precopy, best practice would include a time delay between the create/recreate and activate actions. The command symrcopy verify -precopy -cycled can be used to wait for the completion of one sequential pass through all blocks of the production devices before activating the session.

Migration step 15: Verify migration and symrcopy terminate 111

112


Cleanup step 16: Make source devices host inaccessibleBy definition, these cleanup steps occur after all Open Replicator steps are complete. These host and application specific examples are included briefly here in order to contrast these manual steps with more functional actions that are included as part of PowerPath Migration Enabler (PPME) (which is discussed in Chapter 9, “PPME with Open Replicator Migration Example”).

Although the original source devices were made unavailable to the host in “Stop applications and final incremental update” on page 108, this change was not permanent and it is possible that upon a reboot these devices may be accessed again. If the source device mount definitions are not removed from /etc/vfstab, upon reboot the source devices would automatically be remounted. If an unplanned disk rescan or reboot takes place without making?these devices inaccessible, then it is possible that the host may mistakenly use these devices again in place of the migrated target devices upon recognizing the private region information on the disks. Best practice would avoid this problem and also preserve the production volumes unchanged until it was certain that there was no need to revert to the data stored on the original source devices. The following steps can be used to unmask the source devices from the host to ensure that the host will not inadvertently use these devices.

# symmaskdb -sid 359 list assignment -dev a0:a3


Device Identifier Type Dir:P------ ---------------- ----- ----------------00A0 210000e08b927df4 FIBRE FA-2C:0 210000e08b925cf5 FIBRE FA-15C:000A1 210000e08b927df4 FIBRE FA-2C:0 210000e08b925cf5 FIBRE FA-15C:000A2 210000e08b927df4 FIBRE FA-2C:0 210000e08b925cf5 FIBRE FA-15C:000A3 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

#



Cleanup step 17: Make target devices ready to hostThe target devices are presented to the host in this case, simply by removing the remote CLARiiON devices from the OR_Symm359 storage group and adding the devices to the existing D229 storage group for the local Solaris host. In other cases it might be necessary to add new zoning or create a new storage group or use other array specific LUN masking techniques. For example:

# ./navicli -h Clar0031_SPA storagegroup -removehlu -gname OR_Symm359 -hlu 00 -o# ./navicli -h Clar0031_SPA storagegroup -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 and the list of CLARiiON devices now shows host pathnames for devices 4–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

#

Cleanup step 17: Make target devices ready to host 113

114


Cleanup step 18: Restart applications using targetsThe migrated information on the target devices includes the VxVM private 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 devices on the Symmetrix VMAX (or Symmetrix DMX) were both configured as 4 GB devices, the actual size of the devices differs slightly with the CLARiiON devices being slightly larger. To get the host operating system to recognize and use the additional space, it is necessary to execute operating system and application specific steps.

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



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

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

Cleanup step 18: Restart applications using targets 115

116


Next the vxresize command is used to expand the volume and file system. The expansion size specified is +13824 (4 x 3456) blocks. The vxprint output shows the cplv logical volume length increasing by 13824 blocks from 33529344 to 33543168. Similarly, the filesystem capacity in kbytes changed from 16764672 to 16771584, an increase of 6912 kbytes which matches the expected change in blocks (13824 blocks ÷ 2 blocks/kbyte = 6912 kbytes). For more information on handling LUN expansion for UNIX systems, reference the EMC Symmetrix LUN Expansion and UNIX Logical Volume Managers Technical Note available on Powerlink®.

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

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


6

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

◆ Introduction ...................................................................................... 118◆ Setup step 1: Identify target devices.............................................. 121◆ Setup step 2: Configure migration SAN zone.............................. 122◆ Setup step 3: Configure migration LUN masking....................... 125◆ Setup step 4: Configure target zoning and LUN masking......... 126◆ Setup step 5: Prepare Open Replicator session pairs file ........... 128◆ Setup step 6: Verify completion of setup steps ............................ 131◆ Migration step 9: Stop the applications ........................................ 136◆ Migration step 10: symrcopy activate ........................................... 138◆ Migration step 11: Restart applications using targets................. 139◆ Migration step 13: symrcopy query and verify ........................... 144◆ Migration step 15: Verify migration and terminate .................... 145◆ Cleanup step 19: Redeploy the source devices ............................ 146

Hot Pull from CLARiiONMigration Example

Hot Pull from CLARiiON Migration Example 117

118

Hot Pull from CLARiiON Migration Example

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

Hot pull setup steps

Since this is a hot operation, the zoning and LUN masking requirements are stricter than for cold operations, requiring all Symmetrix FA ports that are mapped by the control devices to be zoned and LUN masked to "see" the remote devices. In order to demonstrate troubleshooting in an example, the setup steps 2 and 3 will deliberately miss meeting this requirement. Additionally, because this is a hot pull migration some of the actions completed in the previous example as cleanup phase steps, instead are completed here during the setup phase in step 4. The six hot pull setup steps are:


2. Configure/connect migration SAN zone between remote devices and Symmetrix VMAX (or Symmetrix DMX) control FA “host” ports.

3. Configure LUN masking for remote devices to allow access from Symmetrix VMAX (or Symmetrix DMX) control FA “host” ports.

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

5. Prepare Open Replicator session pairs file.


Hot pull migration steps

This chapter will provide details of an example of the six migration steps applicable for a hot pull. In this example, step 8 which invokes a create in the migration phase is not necessary. The create is executed at the end of the setup phase, and this time there is no



TimeFinder operation which in “Initial TimeFinder/Mirror establish” on page 95 required exiting the Created state through a terminate action. Step 9 needed for all pull migrations is now included, and step 11 for hot pull migrations is included as well. Tuning is applicable for all migrations including hot pull, and already completed earlier in “Migration step 12: symrcopy set ceiling” on page 103. It is not necessary to repeat this action in this example, because the ceiling setting applies to all sessions which use the same FA director ports. Step 14 is omitted because iteratively applying incremental updates is not applicable for pull operations. The hot pull migration steps are:

9. Stop the production application.


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



Hot pull cleanup stepIn the case of hot pull, applications are redirected to access the data from the target devices before the data movement is complete. Therefore, the first three cleanup steps are actually completed in the setup phase. That leaves only a single step in the cleanup phase, step 19: to redeploy the source devices storage once the migration is complete.

Figure 18 on page 120 illustrates the hot pull setup, migration, and cleanup steps in a flowchart. The non-applicable step 14, iterative incremental update for push sessions, and the three non-applicable cleanup steps (steps 16–18) are omitted from the flowchart entirely to avoid unnecessary complexity.

Introduction 119

120


Figure 18 Hot pull setup, migration, and cleanup flowchart

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



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

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


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


122


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

Determining control director WWNs

The Solutions Enabler symdev list -multiport command is used to determine on which directors the control devices are visible. For this example, all four control devices, 91–94, are mapped to both director 2C port 0 and director 15C port 0. These are the same FA director ports that were eligible to be configured in the Open Replicator SAN zones in “Determining Control Director WWN” on page 73.

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



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

Determining remote storage array WWNs

The remote storage array is again CLARiiON HK190807410004. Figure 19 illustrates checking the connectivity status for Storage Group D194 and reveals the same A-0, A2, B-0, B-2 Storage Processor connections as those seen in “Determining Remote Storage Array WWN(s)” on page 74

Figure 19 Host connectivity status for licod194 in Storage Group D194

Reuse existing migration SAN zonesSince the same Symmetrix DMX FA and CLARiiON SPA ports are relevant to this example and were put in place for the example in Chapters 4–5, it appears that the zones already defined can be used without change. However, the example in this chapter is for a hot operation which requires all paths to be configured so each director can handle protected track copy needs for itself. For hot pull operations, protected tracks that have not already been copied by the background copy are copied immediately as part of Copy on First Access (COFA). For hot push operations the protected track copy is

ICO-IMG-000542

Setup step 2: Configure migration SAN zone 123

124


Copy on First Write (COFW). The single active path zoning already defined for director 2C port 0 alone is insufficient because director 15C port 0 is not included in any migration zone. For purposes of displaying typical error messages when required zoning is missing, this example will proceed without adding the missing zones at this time.



Setup step 3: Configure migration LUN masking

Create CLARiiON Storage Group

Because the same DMX FA “hosts” are connected to the same remote CLARiiON storage array, storage group OR_Symm359 defined in “Create CLARiiON storage group” on page 78 can be reused. However, like the zoning above, for a hot operation, all paths must be LUN masked and the single FA DMX port “host” in the storage group (corresponding to DMX FA 2C port 0, but no? 15C port 0) will prove to be insufficient. For purposes of displaying typical error messages when necessary LUN masking is missing, this example will proceed without completing all LUN masking requirements at this time. The four remote source devices for this pull example are added to the storage group in the example below:

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




c:\>

Setup step 3: Configure migration LUN masking 125

126


Setup step 4: Configure target zoning and LUN maskingUnlike the example for setting up a cold push in Chapter 4, “Cold Push to CLARiiON Setup Example,” the current example is a hot pull which moves up the step of zoning and masking the target devices from occurring in the cleanup phase to the setup phase, since the application will be accessing the target devices from the start.

Target devices 91–94 are already correctly mapped and device masked as shown below by the presence of a physical path displayed when the sympd list command is executed:

c:\>sympd -sid 359 list


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 for the mapping operation would look something like this:

map dev 91:94 to dir 2C:0 starting lun=81;map dev 91:94 to dir 15C:0 starting lun=81;

And invoking the mapping operation and specifying the device masking commands could be done by executing a command sequence like this:

c:\>symconfigure -sid 359 -f map.txt commit

Execute a symconfigure operation for symmetrix '000190300359' (y/[n]) ? y

A Configuration Change operation is in progress. Please wait...

Establishing a configuration change session............Established. Processing symmetrix 000190300359 Performing Access checks...............................Allowed. Checking Device Reservations...........................Allowed. Submitting configuration changes.......................Submitted Locking devices........................................Locked. Validating configuration changes.......................Validated. Initiating PREPARE of configuration changes............Prepared. Initiating COMMIT of configuration changes.............Queued. COMMIT requesting required resources...................Obtained. Step 012 of 012 steps..................................Executing. Local: COMMIT.........................................Done. Terminating the configuration change session...........Done.

The configuration change session has successfully completed.

c:\>symmask list hba

Identifier Type Adapter Physical Device Path Dir:P---------------- ----- ---------------- --------------------- -----10000000c97111fc Fibre 10000000c97111fc \\.\PHYSICALDRIVE33 02C: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:\>

Setup step 4: Configure target zoning and LUN masking 127

128


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

Figure 20 Windows drive L contents

ICO-IMG-000543



Using Disk Management, it can be seen in Figure 21 that drives L, M, N and O correspond to disks 1-4. Note that the size of each drive is 2 GB.

Figure 21 Windows Disk Management display of drives L, M, N and O

ICO-IMG-000544

Setup step 5: Prepare Open Replicator session pairs file 129

130


Because the CLARiiON has been discovered in the SYMAPI database file, the CLARiiON device numbers (0–3) related to physical drives 1–4 can 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 pair file 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:\>




Discover missing zoning with symrcopy create

Using the hot_pull_orpairs file, an attempt to create the hot pull Open Replicator session will reveal any problems with the required setup:

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

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


132


Detailed error messages can be displayed by re-executing the create action with the verbose option -v specified, providing similar information as can be obtained by examining the contents of the SYMAPI log file. In the example shown below, the first reported status SANCOPY_DEV_SUCCESS indicates that for control device 91, director 2C could see the remote device. However, the second reported status SANCOPY_DEV_NO_REMOTE_TARGETS indicates that for the same control device 91, director 15C could not see any remote devices. This indicates that a zoning error exists.

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



STARTING a REMOTE Copy CREATE (PULL) (HOT)

SELECTING Control device - Remote devices:

(Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4DDD11 - [SELECTED] (Ctl)Sym: 000190300359 Device: 00092 - LUN WWN: 600601602B401E000DDB4E44EA4DDD11 - [SELECTED] (Ctl)Sym: 000190300359 Device: 00093 - LUN WWN: 600601602B401E000EDB4E44EA4DDD11 - [SELECTED] (Ctl)Sym: 000190300359 Device: 00094 - LUN WWN: 600601602B401E000FDB4E44EA4DDD11 - [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: 600601602B401E000CDB4E44EA4DDD11 - [loc_dir:15C, rem_num:0, rem_sts:0xaSANCOPY_DEV_NO_REMOTE_TARGETS ] (Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4DDD11 - [SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR]

The Rcopy 'CREATE' operation FAILED. (SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)


c:\>The symsan list -sanports command confirms the missing zoning definition:

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


No results found.

c:\>



Example configuration of additional migration SAN zoneFor the hot pull, it is necessary to define a zone for all directors mapped to the control device. However, only a path for FA 2C port 0 was zoned in “Example configuration of migration SAN zones” on page 77. Now, a second active path is defined for FA 15C port 0 including the standby path to accommodate trespassing in the CLARiiON. The original zone defined a path from Symmetrix 2C0 to CLARiiON SPB0 (and standby path to SPA0). The new zone defines a path from Symmetrix 15C0 to CLARiiON SPB2 (and standby path to SPA2). The definition of two independent active zones instead of one zone with all paths results in better performance due to the way Open Replicator manages alternate paths. Figure 22 shows an excerpt of the Connectrix Manager Zoning verification screen with the additional path and standby path zoning defined.

Figure 22 Activate additional zones verification screen excerpt

Discover missing LUN masking with symrcopy createIn the example below, a repeat of the attempt to create the hot pull Open Replicator session will produce a different error since zoning is in place but LUN masking is still missing. The second status reported for control device 91, the entry for director 15C now reports SANCOPY_DEV_WWID_NOT_FOUND indicating that the remote device WWN could not be found. Since the WWN came from the SYMAPI database, the cause is not a WWN entry error, but that the correct WWN cannot be seen. This is most likely the result of missing LUN masking.

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

ICO-IMG-000545


134


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...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: 600601602B401E000CDB4E44EA4DDD11 - [loc_dir:15C, rem_num:0, rem_sts:0x6SANCOPY_DEV_WWID_NOT_FOUND ] (Ctl)Sym: 000190300359 Device: 00091 - LUN WWN: 600601602B401E000CDB4E44EA4DDD11 - [SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR]





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

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


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

15C:0 . EMC CLARiiON HK190807410004 1 5006016A41E087E6

15C:0 . EMC CLARiiON HK190807410004 1 5006016241E087E6

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

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

Symmetrix ID: 000190300359Remote Port WWN: 5006016241E087E6

ST A T Flags Block Capacity LUN Dev LUNDIR:P E ICRT Size (MB) Num Num WWN----- -- ----- ----- ----------- ----- ----- --------------------------------15C:0 NR X... N/A 1 0 N/A 50060160C1E087E650060160C1E087E6

Legend: Flags: (I)ncomplete : X = record is incomplete, . = record is complete. (C)ontroller : X = record is controller, . = record is not controller. (R)eserved : X = record is reserved, . = record is not reserved. (T)ype : A = AS400, F = FBA, C = CKD, . = Unknown

c:\>



Example LUN masking for all Symmetrix VMAX (or Symmetrix DMX) FA control directors

Defining zoning is not the only thing required to provide access. In this example, FA 15C port 0 also needs to be properly LUN masked before the remote devices can be seen. For the remote CLARiiON array in this example, this can be accomplished by adding the FA 15C port 0 host to the OR_symm359 storage group. Symmetrix FA “host” 15C is manually registered for both the SPB port 2 and SPA port 2 in the storage group:

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

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

c:\>

Successful create verifies hot pull setup

Now that the correct zoning and LUN masking is in place, the Open Replicator create succeeds without error in the following example. Although the Open Replicator sessions are now setup, data movement has not yet begun. The best practice for hot pull migrations is to always include the -donor_update option if production applications will be writing to the target devices. This is necessary to protect against potential data loss due to a SAN failure or other connectivity issues during a hot pull operation:

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



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

c:\>


136


Migration step 9: Stop the applicationsSince this example is a pull migration, it is necessary to stop any production applications that are using the remote source devices (drives L–O), in order to fix a point-in-time for the remote array devices. This is done at an appropriate time when a short interruption in running the production applications can be tolerated.

The Symmetrix Integration Utilities (SIU, available with Solutions Enabler) integrates and extends the Windows 2003 and Windows 2008 disk management functionality to better operate with EMC Symmetrix business continuance storage devices. Data migration using Open Replicator can also take advantage of this functionality with support specifically for Windows servers by extending their ability to:

◆ Mount and unmount hard disks and their associated file systems

◆ Flush file system cache buffers to disk

◆ Manipulate disk signatures

◆ Scan the drive connections and discover any new disks available to the system

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

◆ Obtains an exclusive lock on that volume from the operating system, which will fail if another application is still using the drive

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

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



For example, the following symntctl commands can be used to unmount drives L through 0:

c:\>symntctl umount -drive L:

Successfully unmounted the volume.

c:\>symntctl umount -drive M:


c:\>symntctl umount -drive N:


c:\>symntctl umount -drive O:


c:\>Additionally, to ensure that the original source volumes will not become visible on a subsequent rescan or reboot, the LUN masking for each volume needs to be removed. This is done by issuing a set of commands that look like this:

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




c:\>

Migration step 9: Stop the applications 137

138


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

c:\>symrcopy -session_name hot_pull activate

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) 131032 MB(s) 8189.5




c:\>



Migration step 11: Restart applications using targetsNow that the data copying has begun, production applications can be restarted immediately without waiting for the copy to complete. If an attempt is made to access data not yet copied, then it will be copied (COFA) immediately. Copying all of the data from the source devices to the targets includes copying information about the 2 GB original size of the source devices. The symntctl update command can be used to update the partition information to include the additional space that actually exists on the target devices:

c:\>symntctl rescan

Device rescan in progress... Device rescan completed successfully.

c:\>symntctl update -pd \\.\PHYSICALDRIVE6

Successfully updated device partitions.







c:\>

Migration step 11: Restart applications using targets 139

140


Figure 23 illustrates the updated partition information presented in Disk Management that shows the 2.01 GB of additional unallocated space for each disk. Since the disks have not yet been mounted, all of the allocated partition information is shown as being Free Space.

Figure 23 Disk Management display of target devices additional space

ICO-IMG-000546



The symntctl mount command is used now to mount the target devices using the same drive letters as the source devices had used, so production applications that use the filesystems will now access the data on the target devices.

c:\>symcfg discover -all


c:\>symntctl mount -drive L: -sid 359 -symdev 91

Successfully mounted the volume.

c:\>symntctl mount -drive M: -sid 359 -symdev 92


c:\>symntctl mount -drive N: -sid 359 -symdev 93


c:\>symntctl mount -drive N: -sid 359 -symdev 94


c:\>


142


The DiskPart utility is used to extend the allocated disk partition to use the unallocated space, so that all 4 GB of space can be used by applications. For example:

c:\>diskpart

Microsoft DiskPart version 5.2.3790.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 Management showing the extended 4 GB partitions (no longer the original 2 GB).

Figure 24 Disk Management updated display showing 4 GB partitions

ICO-IMG-000547


144


Migration step 13: symrcopy query and verifyThis step consists mostly of waiting until the Open Replicator copy completes copying all of the tracks from the remote devices to the control devices. Once this is done, the original source devices are no longer needed. The query action will report the Status and the decreasing number of Protected Tracks, and the increasing Done percent. Using the verify action allows scripts to wait for a particular status:

c:\>symrcopy -session hot_pull query

Session Name : hot_pull

Control Device Remote Device Flags Status Done---------------------------- ----------------------- ----- -------------- ---- 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) 129659 MB(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:\>



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

c:\>symrcopy -session hot_pull terminate

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 has a session with donor update enabled

c:\>symrcopy -session hot_pull set donor_update off -consistent

Execute 'Set Donor Update Off' operation for the 4 specified deviceswith session name 'hot_pull' (y/[n]) ? y

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

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

c:\>symrcopy -session hot_pull terminate

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

Migration step 15: Verify migration and terminate 145

146


Cleanup step 19: Redeploy the source devicesBecause this example is a hot pull, the key cleanup steps of redirecting production applications to access the target devices in place of the source devices were completed in “Migration step 11: Restart applications using targets” on page 139. Step 19, redeploy the source devices’ storage, is the only step remaining in the cleanup phase.


7

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

◆ Introduction ...................................................................................... 148◆ Setup step 1: Identify target devices.............................................. 151◆ Setup step 2: Configure migration SAN zone.............................. 152◆ Setup step 3: Configure migration device masking .................... 157◆ Setup step 4: Configure target zoning and LUN masking......... 173◆ Setup step 5: Prepare Open Replicator session pairs file ........... 174◆ Setup step 6: Verify completion of setup steps ............................ 178◆ Migration step 9: Stop the applications ........................................ 182◆ Migration step 10: Open Replicator activate................................ 185◆ Migration step 11: Restart applications using targets................. 187◆ Migration step 12: Tune migration ............................................... 189◆ Migration step 13: Check status, wait until copied..................... 191◆ Migration step 15: Verify migration and terminate .................... 192◆ Cleanup step 19: Redeploy the source devices ............................ 194

Hot Pull from SymmetrixMigration Example

Hot Pull from Symmetrix Migration Example 147

148

Hot Pull from Symmetrix Migration Example

IntroductionThis chapter details a hot pull migration example using Symmetrix Management Console (SMC) on a Windows host. This example is very similar to the hot pull example in Chapter 6, “Hot Pull from CLARiiON Migration Example,” requiring the same steps to be completed. This example will highlight the use of SMC for the completion of the steps; the remote storage array is a Symmetrix, so all the required device (LUN) masking can also be completed from within SMC.

Hot pull setup steps

Since this is a hot operation, all Symmetrix FA ports that are mapped by the control devices must be zoned and LUN masked to "see" the remote devices. In this example all zoning and masking requirements will be met in the setup steps, including using SMC Remote Report to verify completion. The definition of Open Replicator session pairs can be completed in an SMC wizard dialog and the actual creation of a file is optional. The six hot pull setup steps are:


2. Configure/connect migration SAN zone between remote devices and Symmetrix VMAX (or Symmetrix DMX) control FA “host” ports.

3. Configure LUN masking for remote devices to allow access from Symmetrix VMAX (or Symmetrix DMX) control FA “host” ports.

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

5. Prepare Open Replicator session pairs file step can be completed by a selection process in SMC with or without the creation of an actual file.




Hot pull migration stepsThis chapter will detail an example of six migration steps applicable for a hot pull. The step 12 optional tuning action, which is applicable for all migrations types, will be detailed again in order to illustrate the SMC interface for tuning Open Replicator. The six hot pull migration steps detailed are:

9. Stop the production application.


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

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



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

Figure 25 on page 150 illustrates the hot pull setup, migration, and cleanup steps in a flowchart. The non-applicable step 14, iterative incremental update for push sessions, and the three non-applicable cleanup steps (steps 16–18) are omitted from the flowchart entirely to avoid unnecessary complexity.

Introduction 149

150


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



Setup step 1: Identify target devicesFor this pull example, the target (control) devices are devices 95–98 on the Symmetrix DMX 000190300359 array. Figure 26 illustrates the use of the Device Properties display for these devices.

Figure 26 SMC properties for Symmetrix 000190300359 devices 95–98

ICO-IMG-000549


152


Setup step 2: Configure migration SAN zoneThis example uses a different remote array than in previous examples so new migration zones need to be set up. The zones will include the control Symmetrix VMAX (or Symmetrix DMX) FA ports, that act as open systems host initiators and the remote Symmetrix storage array FA ports where the remote devices are mapped.

Determining control director World Wide Port Names (WWPNs)

Figure 27 illustrates a display of device properties that can be used to determine the control device FA directors. The # Paths column indicates that each of the control devices is mapped to two paths. Selecting device 95, displays the properties detail. Selecting the FBA Front End Paths tab reveals that directors FA-2C port 0 and FA-15C port 0 are the FA control ports.

Figure 27 SMC Front End Paths detail for control target device 95

Navigating to the first FA director 2C port 0 provides the display of the WWN for the port. Figure 28 on page 153 illustrates the properties for director 2C port 0 including the WWN.

ICO-IMG-000550



Figure 28 SMC director 2C port 0 properties showing the port WWN

Figure 29 illustrates the properties for the control device’s other mapped director 15C port 0.


ICO-IMG-000551

ICO-IMG-000552


154


Determining Remote Storage Array WWPN(s)The remote storage array for this example is Symmetrix 000187720450. Figure 30 illustrates a display of the directors that remote source device 141 is mapped to in the device detail FBA Front End Paths tab.

Figure 30 SMC Front End Paths detail for remote source device 141

Navigating to the first FA director 8C port 0 provides the display of the WWPN. Figure 31 on page 155 illustrates the properties for director 8C port 0 including the WWN.

ICO-IMG-000553




Figure 32 on page 155 illustrates the properties for the remote device’s other mapped director 9C port 0.


ICO-IMG-000554

ICO-IMG-000555


156


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

Figure 33 is an excerpt from the Connectrix Manager verification screen that illustrates the activation of two migration zones that have been added to the active zoneset for the hot pull between the two Symmetrix arrays.

Figure 33 Connectrix Manager activate Symmetrix hot pull zones

ICO-IMG-000556



Setup step 3: Configure migration device masking

Application source device references

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

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

ICO-IMG-000557

Setup step 3: Configure migration device masking 157

158


Add Symmetrix device maskingBecause the Symmetrix VMAX (or Symmetrix DMX) FA “hosts” are connected to the remote storage array on switched fibre ports, it is necessary to perform LUN masking to grant the Symmetrix VMAX (or Symmetrix DMX) FA initiator access to the remote devices. This LUN masking is performed with tools specific to the remote storage array, that in this case is a Symmetrix and is called device masking. Since the remote Symmetrix is only remote in terms of Open Replicator but is local in the sense of presenting host visible devices, SMC can be used to complete the device masking. Figure 35 illustrates invoking the Device Masking Menu after right clicking the remote Symmetrix array (Device Masking and Mapping > Masking).

Figure 35 SMC Device Masking menu

Figure 36 on page 159 illustrates the SMC device masking dialog. The dialog begins with the selection of the remote Director Port FA-8C:0 and the control Director Port that is acting as the initiator WWN 5006048AD5F031C1 (FA-2C0). The list of Available Devices was filtered by Dev Config = 2-Way Mir and Cap(acity) = 4096 MB. The four remote devices 141–144 were moved to the masking Target list by clicking the Add button. Notice the checkbox for refreshing the VCMDB after the Apply/OK is checked. When checked, the refresh will occur automatically.

ICO-IMG-000558



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

SMC presents a confirmation dialog that is used to report on the success of invoking control actions. Figure 37 illustrates the Success confirmation for the device masking operation.

Figure 37 SMC device masking success confirmation dialog

ICO-IMG-000559

ICO-IMG-000560


160


Because this is a hot pull, masking must be defined on all paths. Figure 38 illustrates the SMC device masking dialog adding access for WWN 5006048AD5F031CE (control FA-15C:0) to remote devices 141–144 on remote director port FA-9C:0.

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

Symmetrix VMAX device masking using Auto-provisioning groups

Conceptually, adding Symmetrix VMAX device masking is the same as shown for Symmetrix DMX in ”Add Symmetrix device masking,” on page 158. A parallel example using the SMC 7.1 Task Masking Wizard will be shown in this section.

ICO-IMG-000561



Auto-provisioning Groups The Auto-provisioning Groups feature was introduced in Solutions Enabler 7.0 and Symmetrix Management Console (SMC) 7.0. It provides an easier, faster way to provision storage in Symmetrix VMAX arrays running Enginuity 5874. Most of the applications running on Symmetrix arrays require a fault-tolerant environment with clustered hosts as well as multiple paths to devices. Auto-provisioning Groups was developed to make storage allocation easier and faster, especially with these types of configurations.

Mapping and masking devices in previous versions of Solutions Enabler required a separate command for each initiator/port combination through which devices would be accessed. Both the symaccess command in Solutions Enabler and SMC allow the user to create a group of devices (storage group), a group of director ports (port group), and a group of host initiators (initiator group), and associate them in a masking view. When the masking view is created, the devices are automatically mapped and masked.

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

The examples presented in this TechBook using symmask, symmaskdb and SMC Device Masking are not applicable for Symmetrix VMAX systems running Enginuity 5874. Solutions Enabler 7.0 introduces the symaccess command to manage Auto-provisioning Groups and includes parallel commands to symmask for actions like list logins and list hba. SMC 7.0 introduces new menu items and dialogs for managing Auto-provisioning Groups, including Storage Groups Maintenance, Port Groups Maintenance, Initiator Groups Maintenance, and Masking Views Maintenance.

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


162


SMC Task Masking WizardAuto-provisioning can be invoked using multiple SMC menus to create an Initiator Group, a Port Group, a Storage Group and a Masking View to associate the three together. SMC also now supplies task interfaces to more easily sequence these multiple steps without having to know each menu to invoke and in what order. Figure 39 illustrates selecting the Masking Wizard from the Tasks view.

Figure 39 SMC Tasks Masking Wizard selection

ICO-IMG-000764



Figure 40 illustrates the Masking Wizard step 1 welcome screen that lists the sequence of steps that the wizard will lead you through and the information that you will need to provide.

Figure 40 Masking Wizard step 1 welcome screen

ICO-IMG-000765


164


Figure 41 illustrates the Masking Wizard step 2 that is used to create a masking view for the selected Symmetrix.

Figure 41 Masking Wizard step 2 create masking view

ICO-IMG-000766



Figure 42 illustrates part of Masking Wizard step 3 where the Create button is clicked to create a new Initiator Group.

Figure 42 Masking Wizard step 3 click to create Initiator Group

Figure 43 on page 167 illustrates the create Initiator Group dialog. The group is given the name OR1724_10E0_10F0 reflecting Open Replicator, the last four digits of the Symmetrix ID and the two FA directors that will be acting as host HBAs to the local Symmetrix 1715. The values displayed as Available Initiators are present only after an attempt to create the Open Replicator session is invoked. The attempt causes the FAs to log in on the fabric even though the Open Replicator create fails due to the missing LUN masking that is still being set up.

ICO-IMG-000767a


166


The FA WWN display on the control Symmetrix shows the WWNs for 10E0 and 10F0 that will be selected:

symcfg -fa all list

Symmetrix ID: 000192601724 (Local)


Dir Port WWN ACLX Volume Set Pnt to Enabled Addressing

FA-7E 0 50000972081AF118 Yes No Yes FA-7E 1 50000972081AF119 Yes No Yes

FA-10E 0 50000972081AF124 Yes No Yes FA-10E 1 50000972081AF125 No No Yes FA-7F 0 50000972081AF158 Yes No Yes FA-7F 1 50000972081AF159 No No Yes

FA-10F 0 50000972081AF164 Yes No Yes FA-10F 1 50000972081AF165 No No Yes



Figure 43 Masking Wizard step 3 Initiator Group creation

After the Add button is clicked, the two selected initiators move from the Available to the Selected display. Clicking the OK ends this dialog returning to Masking Wizard step 3 where clicking the Next button moves to step 4.

Figure 44 on page 168 illustrates Masking Wizard step 4 selecting the ports. In this example, the Select button was clicked to bring up the a display of existing Port Groups. The Port Group 7e0_10e0_p already exists for the two ports that the Open Replicator remote devices are mapped to and is highlighted when clicked on. Expanding the group displays the two FA ports 7E0 and 10E0. where the Create button is clicked to create a new Initiator Group. Clicking the OK button ends the select dialog returning to Masking Wizard step 4.

ICO-IMG-000767b


168


Note: Unlike the previous example for Symmetrix DMX device masking, using Auto-provisioning groups, it is not necessary to repeat the dialog for a second (or third, or fourth etc.) port. Simply adding multiple ports to the Port Group completes masking for all of the ports.

Figure 44 Masking Wizard step 4 select existing Port Group

Clicking the Next button moves on to the next step in the wizard.

ICO-IMG-000768



Figure 45 illustrates part of Masking Wizard step 5. Click the Create button to open a dialog box to create a new Storage Group made up of the Open Replicator remote devices.

Figure 45 Masking Wizard step 5 click to create Storage Group

ICO-IMG-000769a


170


Figure 46 illustrates the Storage Group create dialog. The Storage Group name ORremoteTO1724 is defined. After selecting the Device Source Type as Symmetrix, the hundreds of available devices were filtered by clicking the filter button and selecting the specific size of 4097 MB devices. The Add All button is clicked to move the devices from the Available Devices display to the Group Members display.

Figure 46 Storage Group creation dialog box

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

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

ICO-IMG-000769b



Figure 47 illustrates Masking Wizard step 7 that displays a summary of all previous steps to define the Masking View. Clicking the Finish button ends the wizard and creates the Masking View completing the masking definition.

Figure 47 Masking Wizard step 7 summary

ICO-IMG-000770


172


Figure 48 illustrates the Masking Wizard success dialog that displays after the progress bar confirming successful creating of the new Masking View.

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

Figure 48 Masking Wizard success dialog

ICO-IMG-000771



Setup step 4: Configure target zoning and LUN maskingThe current example is a hot pull. A hot pull moves the zoning and masking the target devices step from the cleanup phase to the setup phase, because the application will be accessing the target devices from the start.

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

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

Similarly, the displays for target devices 96–98 show Physical Device Names .\PHYSICALDRIVE16–18.

ICO-IMG-000562

Setup step 4: Configure target zoning and LUN masking 173

174


Setup step 5: Prepare Open Replicator session pairs fileThe SMC Open Replicator Create Copy Session wizard consists of five pages that include the definition of the session control-remote pairs. Figure 50 illustrates invoking the Create Copy Session menu by right-clicking the control Symmetrix in the navigation tree (Replication > Open Replicator > Create Copy Session).

Figure 50 SMC Open Replicator Create Copy Session menu

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

ICO-IMG-000563



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

The second page provides for selecting the control devices. Figure 52 illustrates the selection of devices 95–98 and filtering the Available Devices to see only devices that have been mapped to director FA-2C port 0 and have a capacity of 4096 MB.

Figure 52 SMC Create Copy Session page 2: select control devices

ICO-IMG-000564

ICO-IMG-000565


176


The third page provides for selecting the remote devices. Figure 53 illustrates the selection of devices 141–144 and filtering the Available Devices to see only devices that have been zoned and masked on Symmetrix 000187720450 director FA-8C port 0. This page of the wizard only presents devices that are correctly zoned and LUN masked offering a verification of correct setup even before invoking the Open Replicator create action. The WWN radio button on this page can be selected to manually add WWN formatted remote devices that may not yet be correctly zoned and LUN masked.

Figure 53 SMC Open Replicator page 3: Select remote devices

ICO-IMG-000566



The fourth page provides for pairing the control and remote devices. Figure 54 illustrates adding the pairing of control device 98 with remote device 144.

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

ICO-IMG-000567


178



Confirm hot pull setup with successful create

The fifth page of the Open Replicator wizard provides for setting additional create options including enabling background Copy and Donor Update. Before clicking the Finish button to invoke the create operation, the Save button can be clicked to save the pair definitions in a file that can be read and edited on page one of the wizard as an alternate to defining pairing on pages two through four. Figure 55 illustrates setting Copy and Donor Update, and then initiating the create operation.

Figure 55 SMC Create Copy Session page 5: Set session options and execute

ICO-IMG-000568



Similar to the prompt confirmation encountered when using the Solutions Enabler symrcopy command, there is a confirmation screen in SMC that gets displayed before any control action is invoked. Figure 56 illustrates how to confirm the execution of the Open Replicator Create action.

Figure 56 SMC Confirm Open Replicator create execution

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

Figure 57 SMC Create Copy Session success dialog box

ICO-IMG-000569

ICO-IMG-000570


180


SMC Remote ReportWith SMC, the equivalent of symsan is checked as part of selecting remote devices in the wizard. The SMC Remote Report provides an explicit way of looking at this information from within SMC without having to invoke the Create Copy Session wizard. Figure 58 illustrates invoking the Remote Report menu with an initial right click of the control Symmetrix VMAX (or Symmetrix DMX) array, and selecting Replication > Open Replicator > Remote Report.

Figure 58 SMC Remote Report menu selection

ICO-IMG-000571



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

Figure 59 SMC Remote Report Remote Ports tab

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

Figure 60 SMC Remote Report Remote Luns display

ICO-IMG-000572

ICO-IMG-000573


182


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

As in “Migration step 9: Stop the applications” on page 136 the Symmetrix Integration Utilities (SIU) symntctl command is used to unmount the source drives.

c:\>symntctl umount -drive P:


c:\>symntctl umount -drive Q:


c:\>symntctl umount -drive R:


c:\>symntctl umount -drive S:


c:\>



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

Figure 61 shows removing the device masking for remote source devices 141–144 for Windows host HBA WWN 10000000c97111fc from director FA-8C:0.

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

ICO-IMG-000574

Migration step 9: Stop the applications 183

184


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

Figure 62 shows removing the device masking for remote source devices 141–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



Migration step 10: Open Replicator activateOnce the Open Replicator session is created, it can be selected in the SMC navigation tree by expanding Replication Views and then expanding Open Replicator Sessions. The Properties view displays status equivalent to the symrcopy query command. In this case control devices 95–98 are paired with remote devices 141–144 and the state is Created. Right clicking on the session name in the navigation tree can be used to bring up the Open Replicator Session Control menu.

Figure 63 illustrates the Open Replicator session navigation tree selection, properties view and Session Control menu selection (Replication > Open Replicator > Session Control).

Figure 63 SMC Open Replicator session properties and control menu

The SMC Session Control dialog, provides for selection of the desired action. At this point, the Activate action is selected to set the point-in-time for the pull of data from the remote to the control. In this example of a hot pull, there is no need to click the Consistent checkbox option, as the applications were stopped and the disk cache

ICO-IMG-000576

Migration step 10: Open Replicator activate 185

186


was flushed ensuring consistency. Since SMC uses the same dialog to invoke an operation on single or multiple devices, it is necessary to select the device pairs that should be affected by the chosen action.

Figure 64 illustrates the selection of the Activate action for Open Replicator session symm_hot_pull affecting all four device control-remote device pairs.

Figure 64 SMC Open Replicator activate

After the activate, the State has changed to CopyinProg(ress) and the Prot(ected) Tr(ac)ks have started to be decremented as tracks have copied over to the control. Figure 65 illustrates the change in status after an activate operation is performed.

Figure 65 Open Replicator session properties after activate

ICO-IMG-000577

ICO-IMG-000578



Migration step 11: Restart applications using targetsNow that the data copying has begun, production applications can be restarted immediately without waiting for the copy to complete. If an attempt is made to access data that has not yet been copied, then that data will be copied immediately (COFA). In this example the remote and control devices are the same capacity, but have a different disk geometry because the remote Symmetrix array is a DMX-2 and the control Symmetrix array is a DMX-3. The Windows host operating system has no problem with this change. However, Solaris requires some extra steps to handle this difference that can be found on Powerlink in the EMC Enginuity 5773 Flexible Device Geometry in a Sun Solaris Environment Technical Note.

As previously explained, the symntctl command is used to rescan for devices and update the control target device partitions:

c:\>symntctl rescan

Device rescan in progress... Device rescan completed successfully.









c:\>The symntctl mount command is used to mount the target devices using the same drive letters that the source devices used, so production applications that use the filesystems will now access the data on the target devices.

c:\>symntctl mount -drive P: -sid 359 -symdev 95



188


c:\>symntctl mount -drive Q: -sid 359 -symdev 96


c:\>symntctl mount -drive R: -sid 359 -symdev 97


c:\>symntctl mount -drive S: -sid 359 -symdev 98


c:\>Figure 66 illustrates the updated display from Disk Management showing the volumes P–S now based on the target devices.

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

ICO-IMG-000579



Migration step 12: Tune migration The ability to set and change the pace and ceiling options is equivalent in SMC as when using the symrcopy command. Figure 67 illustrates invoking the Set Ceiling menu by first right clicking the control Symmetrix array (the ceiling option affects all Open Replicator sessions), and then Replication > Open Replicator > Set Ceiling.

Figure 67 SMC Select Open Replicator Set Ceiling Menu

ICO-IMG-000580

Migration step 12: Tune migration 189

190


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

Figure 68 SMC Open Replicator Set Ceiling

ICO-IMG-000581



Migration step 13: Check status, wait until copiedThis step consists mostly of waiting until the Open Replicator copy completes copying all of the tracks from the remote devices to the control devices. Once this is done, the original source devices will no longer be needed. The SMC Refresh View button can be clicked to update the properties display for the Open Replicator session. This is one way to see the decreasing number of Protected Tracks, and the increasing % Complete.

Figure 69 illustrates clicking the Refresh View button and the Open Replicator session properties with the default column positioning reordered to display the columns of most interest without horizontal scrolling.

Figure 69 SMC Open Replicator session properties Refresh View update

ICO-IMG-000582

Migration step 13: Check status, wait until copied 191

192


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 direct equivalent of the symrcopy verify command. However, as an intelligent GUI, the available (non-grayed) drop-down menu Action options displayed in the Open Replicator Session Control dialog reflects which actions are valid for the current session state.

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

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

Figure 71 Donor Update Off SMC Session Control dialog box

ICO-IMG-000584

Migration step 15: Verify migration and terminate 193

194


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

Figure 72 Terminate SMC Session Control dialog box

Following the Terminate action confirmation and the Terminate success dialog, the navigation tree symm_hot_pull session disappears from the Open Replicator Replication Views.

Cleanup step 19: Redeploy the source devicesBecause this example is a hot pull, the key cleanup steps of redirecting production applications to access the target devices in place of the source devices was completed in “Migration step 11: Restart applications using targets” on page 187. Step 19, redeploy the source devices storage, is the only step remaining in the cleanup phase.

ICO-IMG-000585


8

This chapter defines the benefits, terminology and operation of PowerPath Migration Enabler (PPME). The setup, migration, and cleanup phases are described using the set of steps first defined in “Basic Open Replicator migration operation flow” on page 55. Because the PPME interface and capabilities offer significant simplification and enhancements, some steps are reordered, skipped, merged together, or split apart; yet the basic flow is still fundamentally the same. The topics covered include:

◆ Introduction ...................................................................................... 196◆ Benefits of using PPME................................................................... 196◆ Nondisruptive migration overview .............................................. 197◆ Definitions......................................................................................... 199◆ PPME considerations and restrictions .......................................... 203◆ PPME with Open Replicator migration operation flow............. 204◆ Reference information ..................................................................... 211

PowerPath MigrationEnabler Overview

PowerPath Migration Enabler Overview 195

196

PowerPath Migration Enabler Overview

IntroductionPowerPath Migration Enabler (PPME) is a hybrid migration solution that provides the ability to perform nondisruptive migrations and application cutovers while leveraging Open Replicator to actually migrate the data. PPME benefits data migrations by greatly reducing or eliminating application disruption due to the migration, reducing migration risk, and simplifying migration operations.

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

Benefits of using PPMEEven if PPME cannot entirely eliminate application outages, it greatly minimizes them and reduces data migration risk. Complex migrations almost always will require certain setup activities for the migration that may involve a host reboot. For example, a migration requirement to update HBA drivers that requires a host reboot would be executed in a scheduled maintenance window. The application interruption necessary for installing PowerPath 5.x (a PPME prerequisite) can also be scheduled to take place during normal maintenance windows prior to the actual migratio? process. There is a great difference between performing this type of activity as part of a maintenance window and the more risky procedures that have to be conducted when PPME is not used. One example of a risky procedure not needed when PPME is used is the potentially catastrophic cutover outage where a machine is shut down, a few configuration changes are made, and the machine does not come back up without issue (note that the risk of this type of outage can also be minimized with careful planning and by using best practices). With PPME the cutover task is fully verified before being performed and can sometimes be conducted fully online. I/O redirection allows administrators to preview deployment without committing to it. And with PPME, in all cases, the data remains accessible to host applications during the migration process.



Eliminating or even just reducing application downtime during a migration greatly simplifies the planning for large-scale migrations. Migration window flexibility is important to administrators because it simplifies the migration planning process. Administrators do not have to rely on others to follow their directions, nor do they need to work off their shift, which is when migration data movement operations are frequently scheduled. With PPME, the pressure to correctly complete critical and complex migration tasks during outages or off hours is reduced or eliminated.

PPME also greatly simplifies migration operations, hiding the complexities of underlying migration products and integrating with the host. This simplification is even more important in providing a common interface across heterogeneous hosts, eliminating the host specific knowledge required to perform key migration tasks. The simplicity that PPME brings to migration operations may even allow less skilled and less expensive staff to execute the work.

Nondisruptive migration overviewThe PPME powermig command is used to interface with Open Replicator. Open Replicator hot pull does the bulk data copying between the arrays through the SAN. PPME keeps source and target devices synchronized by cloning writes on the host. Mirroring the two devices allows testing of the migration and returning to the initial state with no downtime.

Figure 73 on page 198 illustrates an example of PPME Operation with pseudo-named (location independent) devices and Open Replicator where PPME swaps the pseudo-named devices in the middle so that emcpower25c points to the target device instead of the source device without any change required in the application.

Nondisruptive migration overview 197

198


Figure 73 PPME Operation with pseudo-named devices and Open Replicator

Application

emcpower25c

Data RAID 1

Application

Data RAID 1

Data RAID 5

PowerPath Filter Driver

emcpower25c emcpower37c

SAN

Configure target

pseudo devices

Application

emcpower25c

Data RAID 5

Complete migration

and remove old storage

OR Copy

ICO-IMG-000452



Definitions

Pseudo or Native device name migrations

The operating system creates native devices to represent and provide access to logical devices. A native device is path specific (as opposed to path independent) and represents a single path to a logical device. The device is native in that it is provided by the operating system for use with applications. After migrating data from a native device name, production applications must be reconfigured to use the new target-device name, which is a minimally disruptive process.

Pseudo device names are location-independent names that represent a single logical device and the path set leading to it. A location-independent device name allows the migration of data without requiring the reconfiguration of applications in order to use a new logical unit. When data is migrated from one pseudo-named device to another pseudo-named device, the migration can be nondisruptive. The example in Chapter 9, “PPME with Open Replicator Migration Example,” illustrates a migration from one pseudo device to another.

Source and target

PPME uses the terms source and target to refer to the two endpoints of a data migration. When Open Replicator hot pull is used for migrations, the source LUNs are Open Replicator remote devices and the target LUNs are control devices.

PPME Migration States

A migration session transitions through a number of states as powermig commands are executed. Figure 74 on page 200 shows the overall migration workflow, including the sequence of powermig commands and the corresponding migration states. Numbers one through eight in the graphic shown in Figure 74 depict the commands involved in a normal migration workflow. The graphic also shows the migration states from which you can enter the powermig abort and powermig cleanup commands.

Definitions 199

200


Figure 74 PPME Migration states and commands

Table 1 on page 201 describes the PPME Migration states when Open Replicator is used as the underlying technology, along with the relevant Open Replicator states.

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 setup command completes successfully. Before a migration can enter this state, synchronization prerequisites must be met. When Open Replicator is the underlying technology, all requirements for the create action have been met and the Open Replicator state is Created.

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

SourceSelected The migration enters the SourceSelected state once the Open Replicator session has reached the Copied state (or after powermig selectSource completes). Application reads are still from the source, while writes continue to be mirrored to both source and target by PPME.

TargetSelected The migration transitions to the TargetSelected state after the powermig selectTarget command completes. Application reads are now from the target, writes are still mirrored to both source and target by PPME, making it possible to return to the SourceSelected state.

CommittedAndRedirected

The migration enters the CommittedAndRedirected state after the powermig commit command completes for a native-named source device. Application reads continue from the target via redirection, writes are no longer mirrored so it is not possible to abort the migration. This is intended to be a short lived temporary state, where production applications must be stopped. Then the powermig undoRedirect command is invoked to disable the redirection. Once applications have been reconfigured to use the target device paths, they can be restarted.

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

Definitions 201

202


PPME Abort, Cleanup, and RecoverA migration can be aborted with the powermig abort command anytime after entering powermig sync and before entering the powermig commit command. In other words, a migration can be aborted while in the Syncing, SourceSelected, or TargetSelected state. An aborted migration session returns to the Setup state; from this state the migration can either be restarted (powermig sync) or it can be cleaned up (powermig cleanup).

The purpose of cleanup is to ensure that production applications and/or the operating system are not confused by identical data residing on both the source and target LUNs. The powermig cleanup command can be run while in the Committed or the Setup state. When run while in the Committed state, selected data on the source LUN is removed. When run while in the Setup state (typically after an abort) selected data on the target LUN is removed. After running this command, the source or target LUN from which selected data has been removed will not mistakenly be read by the host operating system.

The powermig recover command can be used to recover a migration after an interruption occurs. Interruptions can result from a migration error, a process crash, or a device fault. This command should be run whenever the migration is in the NeedsRecovery state. In the case of a migration error, the recovery may fail until the cause of the error is identified and resolved. When the powermig recover command completes successfully, the migration state changes to the state to which the session was transitioning when the interruption occurred.



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

◆ PowerPath Migration Enabler does not support:

• Migrating paging or swapping devices.

• Migrating boot devices.

• Uninstalling or upgrading PowerPath while a migration is in progress.

◆ The target LUN:

• Must be the same size as or larger than the source logical unit for Open Replicator migrations.

• Cannot be under the control of a volume manager.

• Cannot have I/O directed to it.

◆ If the Migration Enabler host uses different HBAs to access the source and target logical devices, the HBAs must be comparable in every way (even different revisions of the same HBA are not permitted).

◆ LUNs involved in a migration should not be used as Symmetrix gatekeeper devices because I/O redirection will cause gatekeeper errors. Use of the Solutions Enabler gkavoid or gkselect files can ensure that migration LUNs are not used as gatekeepers. The EMC Solutions Enabler Symmetrix Array Management CLI Product Guide contains more information about gatekeeper devices.

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

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

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

PPME considerations and restrictions 203

204


PPME with Open Replicator migration operation flowThe eight steps in the normal PPME workflow introduced in Figure 74 on page 200 will be listed and flowcharted using the 19 migration steps introduced in “Basic Open Replicator migration operation flow” on page 55 even though steps that apply to cold or push Open Replicator operations are not applicable. Correctly setting up the underlying technology is crucial to the successful use of PPME.

For this example using Open Replicator as the underlying technology, the setup phase steps will directly parallel the previous hot pull examples. The migration phase steps using Open Replicator are fewer and simpler because PPME provides for skipping some steps entirely and delays other steps to the cleanup phase. The cleanup phase steps will be significantly redefined in order to incorporate the change in order and greater functionally of PPME in this phase.

Setup steps

The first four setup steps are required in order to set up Open Replicator for hot pull operations and therefore fully apply when using PPME with Open Replicator. For some operating systems, it may be necessary to run explicit powermt commands to update the PowerPath configuration after making the target devices visible to the host. An additional sub-step is added to the fourth step, making the first four setup steps now:


2. Configure/connect migration SAN zone between remote ports and Symmetrix VMAX (or Symmetrix DMX) control FA “host” ports.

3. Configure LUN Masking for remote devices to allow access from Symmetrix VMAX (or Symmetrix DMX) control FA “host” ports.

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

4b. Update and save the PowerPath configuration.



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




Figure 75 PPME with Open Replicator setup steps flowchart

Migration stepsA PPME managed migration has fewer operational steps than a hot pull migration solely under Open Replicator control. The ability of PowerPath to redirect I/O allows for less impact on the production applications and provides more flexibility as to when the migration change is committed. For example, migration steps 9 and 11 that briefly stop and restart applications with them pointing to the target devices are no longer needed prior to the migration, because during the migration copy, PPME directs all application reads from the source device, and can transparently manage the redirection of the application to the target devices after the data movement completes. And because PPME provides a broader set of cleanup operations, step 15 that consists of the verification of the migration and termination of the Open Replicator session is postponed to that phase. With PPME, the migration steps look like this:

10. powermig sync (activate the Open Replicator session)

ICO-IMG-000587

Hot pull?

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



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

target devices to host

4b. Update and save PowerPath configuration

Y

N

PPME with Open Replicator migration operation flow 205

206


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

13. powermig query (verify Open Replicator copy session is finished)


Figure 76 PPME migration steps flowchart

Step 10 detailActivating each Open Replicator session is accomplished by the powermig sync command that initiates the copying from source to target. Although this operation is performed as an Open Replicator hot pull, with PPME the production applications are still reading from the source devices rather than the targets. Additionally, the session is not created with the donor update option enabled because PPME mirrors all application writes to both source and target devices.

Step 12 detailAs mentioned in “Tuning Open Replicator,” on page 63 the PPME throttle mechanism is an alternate interface to the Open Replicator pace parameter. However, the pace parameter is the secondary tuning mechanism for Open Replicator. In order to use the primary tuning mechanism, the ceiling value can be set using symrcopy set ceiling or SMC Set Ceiling. The pace value is ignored for all participating director/port combinations where the ceiling value is not NONE (including PPME Open Replicator sessions).

ICO-IMG-000588


13. powermig query [Verify OR copy done]

Need tuning?

10. powermig sync [OR activate]

Y

N

N



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

Cleanup steps

The cleanup steps when using PPME are simple, yet provide extensive functionality and flexibility that reduce migration risk. The cleanup step descriptions and ordering are different when PPME uses Open Replicator, than when Open Replicator is used alone. The final step of the migration phase and the four cleanup steps introduced in “Basic Open Replicator migration operation flow” on page 55 are:

15. Verify migration is complete and terminate Open Replicator session.

16. Make the source devices inaccessible to the host (optional, needed for all but hot pull operations).

17. Make the target devices ready to the host (optional, needed for all but hot pull operations).

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


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

The PPME commands that fulfill the purpose of steps 15, 16 and 18, achieves the desired outcomes in different ways that are described in the next five sections. Step 17 is skipped when using PPME because it was already completed as step 4 in the setup phase (the same as when Open Replicator hot pull is used without PPME). Step 19 is very similar for all of the migration examples presented, though the source devices can remain configured as visible to the host, since PPME


208


includes commands that avoid application or operating system confusion that can be caused by seeing identical data residing on both the source and target LUNs.



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

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

PPME transparently committing to the target devices When using pseudo-named source devices and while in the TargetSelected state, the PPME command powermig commit can be used to switch to the Committed state. When this operation is performed, production applications transparently continue to operate using the target devices, that now use the pseudo-names previously used for the source devices. Unlike the selectTarget or SelectSource actions, the commit action is permanent because write mirroring is stopped, making the source devices no longer valid for production application use. This move of application processing to the target devices effectively completes step 18 without any application restart.

PPME cleanup of the source devices While in the Committed state, the PPME command powermig cleanup can be used to remove selected data from the source LUN. This removal ensures that production applications or the operating system are not confused by identical data residing on both the source and target LUNs. Avoiding this potential confusion meets the purpose of step 16 and can make step 19, redeploying the source


210


devices easier because they are still configured to be visible to the host. The cleanup operation also terminates the Open Replicator session, thereby completing the second half of step 15.

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

When using native-named source devices and while in the TargetSelected state, the PPME command powermig commit can be used to switch to the CommittedAndRedirected state. With this operation, the production applications transparently continue to operate using the target devices, via temporary I/O redirection. The commit action is permanent because write mirroring is stopped, making the source devices no longer valid to use for production applications. Applications can continue to run referencing the target devices in this manner until it is convenient to briefly stop them. The powermig undoRedirect command is then used to disable the I/O redirection. Then, production applications must be reconfigured to use the target device paths, and then be restarted. Cleanup of the source devices should then be completed as described in “PPME cleanup of the source devices ” on page 209. This move of application processing to the target devices effectively completes step 18.

PPME abort and cleanup of the target devices At any time during the migration data movement or migration validation testing, the powermig abort command can be executed provided the commit operation has not been executed. The abort operation leaves the migration in the Setup state, and from there the migration can either be restarted or cleaned up. From the Setup state, the PPME command powermig cleanup command can be used to remove selected data from the target LUN. This removal ensures that production applications and/or the operating system are not confused by identical data residing on both the source and target LUNs.



Figure 77 illustrates the PPME cleanup steps as a flowchart. The multiple parts of step 18 and notes referring to step 15 and16 appear out of numeric order due to representing the PPME operational flow using the step definitions for migration steps conducted without PPME from “Basic Open Replicator migration operation flow” on page 55.

Figure 77 PPME cleanup steps flowchart

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

ICO-IMG-000589


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)

Reference information 211


212



9

This chapter details a PPME with Open Replicator migration example that uses the same arrays, hosts and devices as those used in Chapter 7, “Hot Pull from Symmetrix Migration Example.” The setup, migration, and cleanup steps defined for PPME in Chapter 8, “PowerPath Migration Enabler Overview,”will be clarified by a migration example. The topics covered include:

◆ Introduction ...................................................................................... 214◆ PPME Setup steps 1–4 ..................................................................... 215◆ PPME Setup steps 5–6: powermig setup.................................. 215◆ Migration step 10: powermig sync ............................................ 220◆ Migration step 12: Tune migration ............................................... 221◆ Migration step 13: query status, until SourceSelected ....... 222◆ Migration step 18a: powermig selectTarget ....................... 224◆ Migration step 18b: powermig commit ..................................... 225◆ Migration step 16: powermig cleanup ..................................... 227◆ Cleanup step 19: Redeploy source devices storage..................... 228

PPME with OpenReplicator Migration

Example

PPME with Open Replicator Migration Example 213

214

PPME with Open Replicator Migration Example

IntroductionThis chapter details a PPME with Open Replicator migration example that uses the same Windows host, source devices (141–144) and target devices (95–98) as those used in Chapter 7. The applicable migration steps defined for PPME in Chapter 8 apply for this example, so the list of steps required to perform the migration is not repeated here. However, the migration steps flowchart for all three phases is shown in Figure 78 on page 214.

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

ICO-IMG-000594


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)



PPME Setup steps 1–4Since PPME will also use an Open Replicator hot pull for the bulk data copy, the setup steps 1–4 are identical to the way they were performed in Chapter 7, “Hot Pull from Symmetrix Migration Example,” therefore these operations will not be repeated in this example. The PPME with Open Replicator operational flowchart adds a step 4b, to update and save the PowerPath configuration. This step was not necessary in the example presented here. An example of completing this step on a Solaris host is:

# powermt config# powermt save#

PPME Setup steps 5–6: powermig setupThe session concept available with symrcopy and the SMC interface for Open Replicator provides a convenient user interface to work with multiple pairs of devices as a single unit. In the Symmetrix array, each control/remote pair in the same session is actually independent of each other. The PPME interface does not provide for a way to group multiple pairs of devices as a single unit. Each source/target pair is controlled individually with a separate handle assigned to each pair. Therefore there is no need to create a pairs file; instead each source and target device pair is defined on the command line of the setup action. For this example, each device must be identified using a PowerPath pseudo device name because the Windows operating system only supports pseudo device names. In other environments, native device names can be used as well.

PPME Setup steps 1–4 215

216


Identify source and target pseudo device namesThe physical names for the source devices used can be displayed using the 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 the format harddiskXX, that can be seen when displaying the PowerPath devices:

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 1 2 port2\path0\tgt3\lun16 c2t3d16 FA 9cA active alive 0 0 4 port4\path0\tgt1\lun16 c4t1d16 FA 8cA active dead 0 1 4 port4\path0\tgt3\lun16 c4t3d16 FA 8cA active alive 0 0

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 not necessary to use the powermt display command to see the hardiskXX format. For example, target device 95 has a physical device name ending in 15, therefore specifying the pseudo device name harddisk15 explicitly can yield a check that it does indeed point to Symmetrix device 95:

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

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

error. The required license can be added using the PowerPath license registration command emcpreg:

c:\>powermig setup -techType OR -src harddisk24 -tgt harddisk15 -noprompt

PPME error(15): Required license is missing or expired

c:\>emcpreg -add NN#N-NNN#-NNNN-NN#N-NNNN-NNNNSuccess: License added

c:\>

PPME Setup steps 5–6: powermig setup 217

218


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


Migration Handle = 1

c:\>powermig setup -techType OR -src harddisk25 -tgt harddisk16 -no


c:\>powermig setup -techType OR -src harddisk26 -tgt harddisk17 -no




c:\>

The powermig info -all command can be used to report on all source/target pairs under PPME control. Notice that the four source/target pairs used in this example are in the setup state.

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

c:\>



The setup action issues the Open Replicator create command, so the successful setup state confirms that the create was successful, verifying that all of the required Open Replicator setup steps have been completed. Even though the powermig command is used to control this migration, it is still possible to view Open Replicator status directly using symrcopy or SMC. In the following example, notice the following flag values: C(opy) is set, (pu)S(h) is reset indicating a pull, H(ot) is set, and (donor)U(pdate) is reset:

c:\>symrcopy -sid 359 list


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 262140 MB(s) 16383.8




c:\>

PPME Setup steps 5–6: powermig setup 219

220


Migration step 10: powermig syncActivating Open Replicator sessions is accomplished by executing the powermig sync command, that initiates the copying from source to target:

c:\>powermig sync -handle 1 -noprompt




c:\>



Migration step 12: Tune migration The PPME throttle mechanism is an alternate interface to the Open Replicator pace parameter. The following example of powermig help shows how to get the syntax detail for the throttle action:

c:\>powermig help throttle

throttle - used for altering the speed of a migration

Usage: powermig throttle -handle <handle> -throttleValue <value> -suspendTime <valu e>

c:\>The -suspendTime option is not applicable when using Open Replicator as the underlying technology. In this example, the ceiling values set for the Symmetrix control FA ports in earlier are still in effect. The throttle value is ignored for all participating director/port combinations where the ceiling value is not NONE. The following command can be used to display the current ceiling settings:

c:\>symrcopy -sid 359 list ceiling



Max Set Actual Dir:P (MB) (%) (MB) ----- ---- ---- ------ 01C:0 150 NONE 0 01C:1 150 NONE 0 02C:0 150 30 0 02C:1 150 NONE 0 15C:0 150 30 0 15C:1 150 NONE 0 16C:0 150 NONE 0 16C:1 150 NONE 0

c:\>

Migration step 12: Tune migration 221

222


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 the source devices to the target devices.

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

c:\>powermig query -handle 1

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

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

c:\>powermig info -all==========================================Hnd Source Target Tech State=== ========== ========== ==== ======= 1 harddisk24 harddisk15 OR syncing 2 harddisk25 harddisk16 OR syncing 3 harddisk26 harddisk17 OR syncing 4 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 will complete and the sessions will be in the Open Replicator Copied state. As shown in this example, the Open Replicator Copied state is reflected in the PPME sourceSelected state:

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

c:\>When using PPME, the sourceSelected state is an indicator that the data transfer is complete. The next set of operations are part of the robust cleanup steps introduced in “Cleanup steps” on page 207. These steps are presented in a typical PPME sequence, but the titles are not numerically in order, since the step numbers are based on the Open Replicator examples presented previously.

Migration step 13: query status, until SourceSelected 223

224


Migration step 18a: powermig selectTargetThe PPME command powermig selectTarget is used to switch to the targetSelected state. The targetSelected state defines the condition when source and target are synchronized and all application reads come from the target. The following commands are used to enter the targetSelected state and display that status:

c:\> powermig selectTarget -handle 1 -noprompt




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

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



Migration step 18b: powermig commitFor this example on a Windows host, pseudo-named source devices are in use, providing for a transparent, single step commit. If native devices were in use, two powermig command actions would be necessary, along with stopping applications in between and reconfiguring them to reference the target devices in place of the source devices as described in “PPME commit for native-named source devices” on page 210.

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

c:\>powermig commit -handle 1 -noprompt




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

c:\>

Migration step 18b: powermig commit 225

226


The production applications can now transparently continue to operate using the target devices on a permanent basis, because PPME has swapped the pseudo-names used for source and target devices. This change in pseudo-names can be seen by comparing the powermt display output from before the commit (“Identify source and target pseudo device names” on page 216) with the output after the commit shown below. Previously, source devices 141–144 used pseudo-names were hardisk29 to hardisk32. Now, the target devices 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. . .



Migration step 16: powermig cleanupWhile in the Committed state, the PPME command powermig cleanup should be used to remove selected data from each source LUN, ensuring that production applications and/or the operating system are not confused by identical data residing on both the source and target LUNs. The help for the cleanup action shows that the -format option could be used in this example to perform a full disk format on the source LUN.

c:\>powermig help cleanup

cleanup - Cleanup after a migration.

Usage: powermig cleanup -handle <handle> [-format] [-force]

c:\>powermig cleanup -handle 1 -noprompt




c:\>The cleanup action deletes the PPME migration information and terminates the Open Replicator session, as shown by the following command actions:

c:\>powermig info -all

No migrations found.

c:\>symrcopy -sid 359 list

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

c:\>

Migration step 16: powermig cleanup 227

228


Cleanup 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 source devices can remain configured as being visible to the host.


10

This chapter defines the benefits, terminology and operations of Federated Live Migration (FLM). The setup, migration, and cleanup phases are described using the set of steps first defined in “Basic Open Replicator migration operation flow” on page 55. Because the FLM interface and capabilities offer significant simplification and enhancements, some steps are reordered, skipped, merged together, or split apart; yet the basic flow is still fundamentally the same. The topics covered include:

◆ Introduction ...................................................................................... 230◆ Benefits of using FLM...................................................................... 230◆ FLM Nondisruptive migration overview..................................... 231◆ FLM Definitions ............................................................................... 233◆ FLM basic operation sequence ....................................................... 235◆ FLM considerations and restrictions............................................. 237◆ FLM migration using Open Replicator operation flow.............. 238

Federated LiveMigration (FLM)

Overview

Federated Live Migration (FLM) Overview 229

230

Federated Live Migration (FLM) Overview

IntroductionFederated Live Migration (FLM) is a method by which a user can move data from older storage into a new Symmetrix VMAX array nondisruptively. The host application cutover to use the new VMAX devices is made transparent by a combination of presenting the VMAX devices as additional paths to the old devices and managing which paths are active through a MPIO driver on the host. FLM supports PowerPath as the application MPIO driver, and will support additional MPIO drivers in the future. FLM supports moving the data with Open Replicator SAN-based replication, and will support other underlying technologies in the future. Unlike application host-based PPME, control of the migration and cutover is managed through the Symmetrix VMAX array. FLM greatly simplifies migrations requiring no remediation when migrating pre-qualified stacks.

Note: For information on supported operating systems, file systems, and logical volume managers, refer to the EMC Federated Live Migration Simple Support Matrix available at http://Powerlink.EMC.com.

Benefits of using FLMFLM greatly reduces migration complexity and risk by eliminating the need for operational migration steps on applications hosts. Support for pre-qualified stacks including older versions typical in a migration scenario can eliminate remediation steps. FLM also eliminates the need for a traditional cutover step, and provides the ability to failback from the migration without data loss.

Eliminating application downtime during a migration greatly simplifies the planning for large-scale migrations. Migration window flexibility is important to administrators because it simplifies the migration planning process. Administrators do not have to rely on others to follow their directions, nor do they need to work off their shift, which is when migration data movement operations are frequently scheduled. With FLM, the pressure to correctly complete critical and complex migration tasks during outages or off hours is eliminated.





FLM also greatly simplifies migration operations by limiting required application host operations to a SCSI bus scan at times when device visibility to the host is changed, and configuration, cleanup, and verification of the multipath configuration throughout the migration process. Detailed procedures have been developed to help the migration administrator identify host states that are safe to proceed on each supported platform. Following these FLM procedures exactly brings simplicity to migration operations and may even allow less skilled and less expensive staff to execute the work.

Data migrations are often complex operations and require careful planning and execution of predetermined procedures. Failure to identify and perform necessary steps or work within supported configurations can result in data unavailability or loss.

FLM Nondisruptive migration overviewFLM uses standard Open Replicator commands with additional options specific to Federated Live Migration sessions. Using Open Replicator as the underlying technology, the hot pull does the bulk data copying between the arrays through the SAN, and donor update keeps source and target devices synchronized. Mirroring the devices allows testing of the migration and the option to return to the initial state with no downtime. Standard auto-provisioning command(s) between the FLM create and activate operations enable the new VMAX devices to be presented with the identity of the old DMX devices. The PowerPath MPIO driver sees paths for the same device on both the old DMX and new VMAX. FLM controls which set of paths are active to the MPIO driver. Figure 79 on page 232 illustrates an overview of FLM operation.

FLM Nondisruptive migration overview 231

232


Figure 79 FLM operation overview

Application

Data RAID 1

Application

Data RAID 1

Data RAID 5

Application

Data RAID 5

ICO-IMG-000906

Create andactivate FLM

session

TerminateFLM sessionremove DMX

DMX WWN &geometry

DMX WWN &geometry

DMX WWN &geometry

DMX WWN &geometry

PowerPath MPIO PowerPath MPIO PowerPath MPIO

Open Replicator

Old DMX Old DMX New VMAX New VMAX

Donor update



FLM Definitions

Source and target, old and new

FLM migrates data in a single direction, therefore the terms source and target unambiguously refers to the two endpoints of an FLM data migration. These terms can be used both for the arrays and devices in a migration. Because FLM is used in data center consolidation and technology refresh cases, the terms old and new can also be used to refer to the two endpoints of an FLM data migration. With initial support only for DMX source arrays and VMAX target arrays, the terms DMX and VMAX also provide unambiguous reference to the FLM migration endpoints. The term donor can also be used for the source array. When Open Replicator hot pull is used as the underlying technology, the source LUNs are Open Replicator remote devices and the target LUNs are Open Replicator control devices.

Device external identity

Symmetrix arrays present a unique device identity for each host visible Symmetrix Logical Volume (SLV). Therefore the presented host identity for the DMX source device and the VMAX target device would normally appear different to the application host. FLM achieves nondisruptive migration by causing the VMAX target device to present a device external identity which is identical to the DMX source device. The key components of this identity is the device WWN and geometry. The presentation of the device external identity is dependent on conducting the FLM migration operations in an exact order as in “FLM migration using Open Replicator operation flow” on page 238 and shown in “FLM with Open Replicator Migration Example” on page 243.

Federated Live Migration examples are specific to each pre-qualified stack. The exact steps and order required for one stack cannot be applied to a different stack. For current steps for all pre-qualified stacks, consult the Symmetrix Customer Procedure Generator available at http://Powerlink.EMC.com

FLM Definitions 233



234


FLM also includes operations to stop using the device external identity after an FLM migration failback, or at some time after the migration is complete and the user wants to switch the application to use the native VMAX device identity.

Active and passive host access modesFLM introduces new device host access modes. Active mode is the normal device host access mode with the device fully visible to the host. Passive mode is what FLM uses to make an otherwise Ready device not visible to the host. Supported host MPIO drivers recognize FLM toggling between the active and passive modes.

FLM source devices are in active mode until the FLM activate operation and then remain in passive mode during and after the migration. FLM target devices are put in passive mode as part of the FLM create operation and are switched to active mode with the FLM activate operation. The active and passive modes are used such that the old source device and the new target device, presenting with the old source device identity, are never both active to the host at the same time.

After the migration is complete, the old source device remains in the passive host access mode. If the old source array is moved to a different SAN than the new target array, then it may be safe to make these old source devices visible to hosts again by contacting EMC customer service.



FLM basic operation sequenceFLM operations are very simple and can be completed in six basic steps:

1. Set up the underlying technology migration environment, currently Open Replicator

2. Create the FLM session

3. Mask the new VMAX target devices to the application host

4. Activate the FLM session

5. Wait for the FLM migration to complete

6. Terminate the FLM session and remove the old source storage

Data migrations are often complex operations and require careful planning and execution of predetermined procedures. Failure to identify and perform necessary steps or work within supported configurations can result in data unavailability or loss.

At the completion of these steps, the application continues to run using only the new VMAX target devices which continue to present device external identities equal to the old source devices. All of the old source devices remain in passive mode to the host. EMC Customer Service can be contacted to return these devices to active mode only after the old source array is removed from sharing the same SAN to ensure that the VMAX device external identities are unique on the SAN.

An FLM migration can be aborted between steps 4 and 6 as described in “FLM failback, set NO identity, and host_active.”

FLM failback, set NO identity, and host_activeAn FLM migration session can be aborted with the failback action anytime after activating the session and before terminating the session. A FailedBack FLM migration session returns the old source devices to active mode and the new target VMAX devices to passive mode. The underlying technology for the migration is also aborted, leaving the FLM session reporting its FailedBack state, with the only permissible action being to terminate the session.

FLM basic operation sequence 235

236


Once the FLM session is created, the new target VMAX devices will always present themselves using the device external identity copied from the old source devices. There are two scenarios when a command can be issued to return the new target devices to using their own original identity. First, after an FLM session is FailedBack and will be abandoned permanently, returning to the original identity is necessary in order to use these devices. Second, after a successful FLM migration, the user may decide that persisting the old source device identities is operationally confusing, especially after the old source array is has been removed for a long time. In this second case, it is necessary to stop the host application and restart it using the original VMAX device identities. The command to stop using the device external identity is a Symmetrix configuration command with command syntax:

set dev <SymDevName> identity = NO identity;

Because the external identity of the new target VMAX devices is identical to the old source devices, it is necessary to leave the old source devices in passive mode to prevent both the old and new devices from being visible with the same identity outside of an active FLM session. If the old source array is moved to a different SAN, then this is not a concern and it is valid to make these old source devices visible to hosts again by contacting EMC customer service.



FLM considerations and restrictionsThe following restrictions apply when performing FLM migrations:

◆ Only explicitly supported stacks can be used for FLM migrations.

Note: For information on supported operating systems, file systems, and logical volume managers, refer to the EMC Federated Live Migration Simple Support Matrix available at http://Powerlink.EMC.com.

◆ When using Open Replicator as the underlying technology:

• The source device cannot be a boot device

• The target device must be the same size or larger than the source device

◆ Devices involved in a migration should not be used as Symmetrix gatekeeper devices because switches to passive host active mode will cause gatekeeper errors. Use of the Solutions Enabler gkavoid or gkselect files can ensure that migration devices are not used as gatekeepers. The EMC Solutions Enabler Symmetrix Array Management CLI Product Guide contains more information about gatekeeper devices.

◆ When migrating data to a target device that is larger than the source device, the migration must be complete and terminated before gaining access to space on the target that does not exist on the source. Attempting to access that space before the migration session is complete and terminated will remove the possibility of valid FailBack.

FLM considerations and restrictions 237



238


FLM migration using Open Replicator operation flowThe six steps in the FLM workflow introduced in “FLM basic operation sequence,” on page 235 will be listed and flowcharted using the 19 migration steps introduced in “Basic Open Replicator migration operation flow” on page 55 even though steps that apply to cold or push Open Replicator operations are not applicable. Correctly setting up the underlying technology is crucial to the successful use of FLM.

For this example using Open Replicator as the underlying technology, the setup phase steps will directly parallel the previous hot pull examples, with the essential difference to wait to complete the target device masking until after creating the FLM session. The migration phase steps using Open Replicator are fewer and simpler because FLM provides for skipping some steps entirely and other steps are not applicable for a hot pull migration. The cleanup phase steps are entirely optional and only apply if redeploying source devices in a separate SAN or electively choosing to reset the identity of the VMAX target devices to using their own native identity.

Setup steps

The six setup steps used for native Open Replicator hot pull operations are performed with two important differences when using FLM with Open Replicator. First, step 4 still includes the zoning for target devices, but must not include the device (LUN) masking step, which is moved to the Migration steps. Second, step 6 must include successfully creating the FLM session:


2. Configure/connect migration SAN zone between source array ports and Symmetrix VMAX target FA “host” ports.

3. Configure LUN Masking for source devices to allow access from Symmetrix VMAX target (control) FA “host” ports.

4. Configure host zoning for target devices.

Do not perform device (LUN) masking at this time!




6. Verify setup configuration and create the FLM session.


Figure 80 FLM with Open Replicator setup steps flowchart

Migration stepsAn FLM managed migration has fewer operational steps than a hot pull migration solely under Open Replicator control. For example, migration steps 9 and 11 that briefly stop and restart applications with them pointing to the target devices are no longer needed prior to the migration, because FLM presents the new VMAX target devices as alternate paths to the old source devices nondisruptively to the host. The masking step that was postponed from setup step 4, is performed now(step 10a) before the FLM activate step.

With FLM, the migration steps look like this:

10a. Mask the new VMAX target devices

10b.Activate the FLM session

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

13. Verify Open Replicator copy session is finished

15. Terminate Open Replicator session


ICO-IMG-000907

6. Verify pre-migration configuration, create

5. Define FLM OR session pairs (file)

4. Zone target devices to the application host

3. LUN mask source devices to VMAX FA

2. Zone VMAX FA target to source array

1. Provision / identify target devices

FLM migration using Open Replicator operation flow 239

240


Figure 81 FLM migration steps flowchart

Step 10a detailThe target device (LUN) masking step postponed from the setup steps must be performed between the FLM create and the FLM activate. The FLM create, copies the identity from the source devices to the device external identity for the target devices. With the FLM session created, the VMAX auto-provisioning masking operation presents the target devices as new paths to the host MPIO driver, but the paths are in passive host access mode, so cannot be used for I/O yet.

Step 10b detailThe FLM activate using Open Replicator uses the additional -migrate flag. FLM sets the old source device paths to host access passive mode and the new VMAX target device paths to active mode.

Step 12 detailAny Open Replicator tuning is performed in the same way as described in “Migration step 12: symrcopy set ceiling,” on page 103.

Step 13 detailThe Open Replicator query and verify commands are used to wait until the FLM migration completes as described in “Migration step 13: symrcopy query and verify,” on page 105.

ICO-IMG-000908


15. Verify migration terminate FLM

13. Verify FLM copy done

Need tuning?

10a. Auto-provision the VMAX target devices

10b. FLM activate

Y

N



Step 15 detailIt is important to test and verify the migration success before terminating the FLM session. Failing back to the old source devices will no longer be available once the session is terminated. The FLM terminate using Open Replication uses the additional -migrate flag.

Cleanup steps

As explained earlier, the cleanup phase steps are entirely optional when using FLM. However, with FLM it is not permitted to continue to deploy the source array in the same SAN as the new VMAX target array. Since FLM is a hot pull migration, the only step to complete is:


If the old source array is going to continue operation in another SAN, it will be necessary to contact EMC Customer Service to make the devices again visible to a host as described in “FLM failback, set NO identity, and host_active,” on page 235.

FLM migration using Open Replicator operation flow 241

242



11

This chapter details an FLM with Open Replicator migration example that uses a donor DMX array and target VMAX array both visible to a single Windows host array. Steps will be performed using SYMCLI including brief explanations for Open Replicator operations. Additional explanations for Open Replicator hot pull using SYMCLI can be found in Chapter 6, “Hot Pull from CLARiiON Migration Example.” Additional explanations for Open Replicator hot pull from a source Symmetrix can be found in Chapter 7, “Hot Pull from Symmetrix Migration Example.” This migration example will detail the setup, migration, and cleanup steps defined for FLM in Chapter 10, “Federated Live Migration (FLM) Overview.”

The topics covered include:

◆ Introduction ...................................................................................... 244◆ FLM Setup steps 1–6........................................................................ 246◆ Setup step 1: Identify target devices.............................................. 246◆ Setup step 2: Configure migration SAN zone.............................. 246◆ Setup step 3: Configure migration device masking .................... 250◆ Setup step 4: Configure target zoning to the application host .. 251◆ Setup step 5: Prepare FLM session pairs ...................................... 252◆ Setup step 6: Verify setup completion, FLM create..................... 253◆ Migration step 10a: Mask the VMAX target devices .................. 256◆ Migration step 10b: Activate the FLM session............................. 262◆ Migration step 12: Tune migration ............................................... 264◆ Migration step 13: Verify FLM session copy is done .................. 264◆ Migration step 15: Verify migration and FLM terminate ........... 265◆ Cleanup step 19: Redeploy source devices storage..................... 266

FLM with OpenReplicator Migration

Example

FLM with Open Replicator Migration Example 243

244

FLM with Open Replicator Migration Example

IntroductionThis chapter details a FLM with Open Replicator example using Solutions Enabler SYMCLI on a Windows host with PowerPath. The applicable migration steps defined for FLM in Chapter 10 apply for this example, so the list of steps required to perform the migration is not repeated here. However, the migration steps flowchart for all three phases is shown in Figure 82 on page 245. This example will also include extra SYMCLI and PowerPath display commands to exhibit the way in which FLM works.

Federated Live Migration examples are specific to each pre-qualified stack. The exact steps and order required for one stack cannot be applied to a different stack. The example listed here was correct for the example stack at the time of publishing. For current steps for all pre-qualified stacks, consult the Symmetrix Customer Procedure Generator available at http://Powerlink.EMC.com

Management or application host location for commandsOne of the key benefits of FLM is eliminating the need for operational migration steps on applications hosts. However, the best practices included in predetermined procedures include application host operations: a SCSI bus scan at times when device visibility to the host is changed, and configuration, cleanup, and verification of the multipath configuration throughout the migration process. These steps help the migration administrator identify host states that are safe to proceed on each supported platform.

The following example performs all steps on the application host, even though only the SCSI bus scan, multipath driver, and other physical path related operations (for example, sympd list) must be performed on the application host. All of the core FLM migration steps can be performed on a separate management host.





Figure 82 FLM with Open Replicator setup, migration, and cleanup steps

ICO-IMG-000909


6. Verify pre-migration configuration, create

5. Define FLM OR session pairs (file)

3. LUN mask source devices to VMAX FA

2. Zone VMAX FA control to source array

1. Provision / identify target devices 4. Zone target devices to

the application host


15. Verify migration terminate FLM

13. Verify FLM copy done

Need tuning?

10a. Auto-provision the VMAX target devices

10b. FLM activate

Y

N

Introduction 245

246


FLM Setup steps 1–6Since FLM in this example will also use an Open Replicator hot pull for the bulk data copy, the setup steps 1–6 are almost identical to the way they were performed in Chapter 6, “Hot Pull from CLARiiON Migration Example,”and Chapter 7, “Hot Pull from Symmetrix Migration Example.” The operations will be repeated in this example to illustrate delaying masking the target devices until after creating the FLM session.

Setup step 1: Identify target devicesFor this pull example, four devices on Symmetrix VMAX 000192601662 array will be the new target devices. The symdev command with the -range option can be used to display the new target devices 4D4:4D7. The Physical Device Name must be Not Visible at this time, if this command is run from the application host.

c:\>symdev -sid 62 list -range 4d4:4d7


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

04D4 Not Visible ***:* 08A:C7 2-Way Mir N/Grp'd RW 409604D5 Not Visible ***:* 11A:D7 2-Way Mir N/Grp'd RW 409604D6 Not Visible ***:* 09B:D6 2-Way Mir N/Grp'd RW 409604D7 Not Visible ***:* 06B:D5 2-Way Mir N/Grp'd RW 4096

c:\>

Setup step 2: Configure migration SAN zoneSince FLM will use an Open Replicator hot pull, all FA ports that the new target devices are mapped to, must be zoned to access the source DMX devices.



Determining target VMAX director WWNsThe Solutions Enabler symdev list -multiport command is used to determine on which directors the target (Open Replicator control) devices are mapped. For this example, all four target devices 4D4–4D7, are mapped to both director 7F port 0 and director 10F port 0.

c:\>symdev -sid 62 list -range 4d4:4d7 -multiport



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

04D4 08A:C7 2-Way Mir N/Grp'd RW 4096Not Visible - 07F:0 - - - - -Not Visible - 10F:0 - - - - -

04D5 11A:D7 2-Way Mir N/Grp'd RW 4096Not Visible - 07F:0 - - - - -Not Visible - 10F:0 - - - - -

04D6 09B:D6 2-Way Mir N/Grp'd RW 4096Not Visible - 07F:0 - - - - -Not Visible - 10F:0 - - - - -

04D7 06B:D5 2-Way Mir N/Grp'd RW 4096Not Visible - 07F:0 - - - - -Not Visible - 10F:0 - - - - -

c:\>Note that the -multiport option will only list devices with more than one path. If there is only a single path, then symdev list should be used without the -multiport option.


248



c:\>symcfg -sid 62 list -fa 7f -p 0



Dir Port WWN ACLX Volume Set Pnt to Pnt Enabled Addressing

FA-7F 0 500009720819F958 Yes No Yes

c:\>symcfg -sid 62 list -fa 10f -p 0. . .

FA-10F 0 500009720819F964 Yes No Yes

Determining source DMX director WWNsSince the source array is also a Symmetrix, the same SYMCLI commands are used to determine the WWNs for DMX directors the source (Open Replicator remote) devices are mapped. For this example, all four source devices 481–487, are mapped to both director 4Aport 0 and director 13A port 0.

c:\>symdev -sid 89 list -range 484:487 -multiport




0484 05C:D3 2-Way Mir N/Grp'd RW 4096\\.\PHYSICALDRIVE12 - 04A:0 - - - - -Not Visible - 13A:0 - - - - -

0485 15D:C7 2-Way Mir N/Grp'd RW 4096\\.\PHYSICALDRIVE13 - 13A:0 - - - - -Not Visible - 04A:0 - - - - -

0486 01C:C2 2-Way Mir N/Grp'd RW 4096\\.\PHYSICALDRIVE14 - 13A:0 - - - - -



Not Visible - 04A:0 - - - - -

0487 05A:C0 2-Way Mir N/Grp'd RW 4096\\.\PHYSICALDRIVE15 - 13A:0 - - - - -Not Visible - 04A:0 - - - - -


c:\>symcfg -sid 89 list -fa 4a -p 0. . . Dir Port WWN VCM Volume Set Pnt to Pnt Enabled Addressing

FA-4A 0 50060482D52FA543 Yes No Yes

c:\>symcfg -sid 89 list -fa 13a -p 0. . . FA-13A 0 50060482D52FA54C Yes No Yes

Example configuration of migration SAN zonesIn this example, zones are defined to include both source DMX director WWNs and both target VMAX director WWNs. Figure 83 shows an excerpt of the Connectrix Manager Zoning verification screen with the two zones defined.

Figure 83 Connectrix Manager activate zone verification screen

ICO-IMG-000910


250


Setup step 3: Configure migration device maskingBecause the target (Open Replicator control) Symmetrix VMAX FA “hosts” are connected to the source DMX (Open Replicator remote) storage array on switched fibre ports, it is necessary to perform LUN masking to grant the Symmetrix VMAX FA initiator access to the source devices. This LUN masking is performed with tools specific to the source storage array, that in this case is a Symmetrix DMX, using the Solutions Enabler symmask command.

c:\>symmask -sid 89 -wwn 500009720819F958 -dir 4a -p 0 add devs 484:487 -dynamic_lun -noprompt

c:\>symmask -sid 89 -wwn 500009720819F964 -dir 13a -p 0 add devs 484:487 -dynamic_lun -noprompt

c:\>symmask -sid 89 refresh -noprompt

Symmetrix FA/SE directors updated with contents of SymMask Database 000190103189

c:\>



Setup step 4: Configure target zoning to the application hostFor a Federated Live Migration (FLM), this step only includes zoning the target devices to the application host. It must not include the LUN masking step at this time. In this example, the application host was already able to see gatekeeper devices on the Symmetrix, proving that this zoning is already in place for both director 7F port 0 and director 10F port 0. The Symmetrix mapping step presenting the target devices to specific director ports was displayed in “Determining target VMAX director WWNs” on page 247. The sympd list command can be used to show all host visible devices for a specified Symmetrix. In this example, only gatekeeper devices are host visible and the target devices are not listed:

c:\>sympd -sid 62 list



\\.\PHYSICALDRIVE24 0220 10F:0 11A:D7 2-Way Mir N/Grp'd ACLX RW 2\\.\PHYSICALDRIVE25 00E4 10F:0 12C:D2 2-Way Mir N/Grp'd RW 3\\.\PHYSICALDRIVE26 00E5 10F:0 07D:D2 2-Way Mir N/Grp'd RW 3\\.\PHYSICALDRIVE27 00E6 10F:0 10B:D5 2-Way Mir N/Grp'd RW 3\\.\PHYSICALDRIVE28 00E7 10F:0 06B:D5 2-Way Mir N/Grp'd RW 3\\.\PHYSICALDRIVE29 0220 07F:0 11A:D7 2-Way Mir N/Grp'd ACLX RW 2

c:\>

Setup step 4: Configure target zoning to the application host 251

252


Setup step 5: Prepare FLM session pairsFLM using Open Replicator requires the definition of FLM target-source (Open Replicator control-remote) pairs. Multiple pairs grouped into a single file can be managed together by Open Replicator. The FLM target (Open Replicator control) device is identified in the first (leftmost) column and the FLM source (Open Replicator remote) device is identified in the second (rightmost) column.

The array ID must be fully specified and is separated from the device/LUN name (number) by a colon:

c:\>echo symdev=000192601662:4d4 symdev=000190103189:484 > FLMpairs.txt

c:\>echo symdev=000192601662:4d5 symdev=000190103189:485 >> FLMpairs.txt



c:\>type FLMpairs.txtsymdev=000192601662:4d4 symdev=000190103189:484symdev=000192601662:4d5 symdev=000190103189:485symdev=000192601662:4d6 symdev=000190103189:486symdev=000192601662:4d7 symdev=000190103189:487

c:\>



Setup step 6: Verify setup completion, FLM createAll required zoning and masking for the hot pull FLM session will be verified when creating the session. Using the Solutions Enabler symrcopy command, the -migrate option is specified to make this an FLM session. This includes the very important step of passing the DMX source device identity to the VMAX target device to be used as the device external identity. This example will include extra display steps to exhibit this mechanism. Many of these informational display steps are part of the predetermined procedures, and are used to verify status before initiating operations that could result in data unavailability or even data loss if errors were made in performing all necessary steps correctly.

Displaying the pre-create FLM status

The physical device number of the source devices was displayed by the symdev list command in“Determining source DMX director WWNs” on page 248; the source devices are devices 12–15. The PowerPath CLI powermt display for device 12 shows two paths alive for this device from source DMX FA interfaces 4aA and 13aA (where the capital A indicates port 0):

c:\>powermt display dev=12Pseudo name=harddisk12Symmetrix ID=000190103189Logical device ID=0484state=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============================================================================== 3 port3\path0\tgt2\lun6 c3t2d6 FA 4aA active alive 0 0 5 port5\path0\tgt1\lun7 c5t1d7 FA 13aA active alive 0 0

Setup step 6: Verify setup completion, FLM create 253

254


Two new FLM related options for the symdev list command are:

◆ -host_passive lists devices with host access mode set to passive mode

◆ -identity_set lists devices which will present their device external identity instead of their original identity

Prior to the FLM create command the target devices are still in the default active mode presenting their own identity:

c:\>symdev -sid 62 list -host_passive


Could not select any Symmetrix devices to list.

c:\>symdev -sid 62 list -identity_set


Could not select any Symmetrix devices to list.

c:\>

Creating the FLM session

The FLM session using Open Replicator uses the -migrate, -host_type, -hba_type, and -mp_type options. Depending on the -host_type some of the other options may not be required. Querying the Open Replicator session shows the status as Created and the flags showing a (H)ot, donor (U)pdate, (M)igration (T)ype session. The -migrate option implicitly enables donor update.

c:\>symrcopy -f FLMpairs.txt create -pull -migrate -host_type Windows -hba_type E mulex -mp_type PPath_45 -name flm -noprompt

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

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

c:\>



Querying the Open Replicator session shows the status as created and the flags showing a (H)ot, donor (U)pdate, (M)igration (T)ype session.

c:\>symrcopy -sid 62 -session_name flm query

Session Name : flm

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

ProtectedSID:symdev Tracks Identification RI CDSHUTZ CTL <=> REM (%)------------------ --------- --------------------- -- ------- -------------- ----000192601662:04D7 65535 000190103189:0487 SD ...XXM. Created N/A000192601662:04D6 65535 000190103189:0486 SD ...XXM. Created N/A000192601662:04D5 65535 000190103189:0485 SD ...XXM. Created N/A000192601662:04D4 65535 000190103189:0484 SD ...XXM. Created N/A

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



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.(T): M = The session is a migration session. S = The session is a standard ORS session.(Z): X = The session has front-end zero detection enabled. . = The session does not have front-end zero detection enabled.(*): The failed session can be reactivated.

c:\>

Setup step 6: Verify setup completion, FLM create 255

256


Migration step 10a: Mask the VMAX target devicesThe presentation of the VMAX target devices was delayed from the setup phase to the migration phase. After the FLM create is complete, the VMAX target devices have the device external identity of the source DMX devices and can now be presented to the application host.

Displaying the post-create FLM status

Repeating the symdev list command with the new FLM options now show the VMAX target devices in host access passive mode and having their device external identity in force:

c:\>symdev -sid 62 list -host_passive




c:\>symdev -sid 62 list -identity_set




c:\>



Note: The VMAX target devices using their own identity are Not Visible. They are only application host visible as additional paths to the original source device.

The symdev list command using the -identity option can be used to display the Device External Identity defined for a FLM target device:

c:\>symdev -sid 62 list -range 4d4:4d7 -identity


Device FLG External Identity---------------------------------- --- ----------------------------------------Sym Physical Config Sts IG Array ID Num Ser Num Cap (MB)---------------------------------- --- ----------------------------------------

04D4 Not Visible 2-Way Mir RW X. 000190103189 00484 8900484000 409604D5 Not Visible 2-Way Mir RW X. 000190103189 00485 8900485000 409604D6 Not Visible 2-Way Mir RW X. 000190103189 00486 8900486000 409604D7 Not Visible 2-Way Mir RW X. 000190103189 00487 8900487000 4096

Legend: Flags: (I)dentity : X = The device has a non-native external identity set . = The device does not have an external identity set (G)eometry : X = The device has a user defined geometry . = The device does not have a user defined geometry

The -details option can be used to display the WWN that will be presented. For example:

c:\>symdev -sid 62 list -range 4d4:4d7 -identity -detail


Device FLG External Identity----------------------------- --- ---------------------------------------------------------------------Sym Physical Config Sts IG Array ID Num Ser Num Cap (MB) WWN----------------------------- --- ---------------------------------------------------------------------

04D4 Not Visible 2-Way Mir RW X. 000190103189 00484 8900484000 4096 6006048000019010318953303034383404D5 Not Visible 2-Way Mir RW X. 000190103189 00485 8900485000 4096 6006048000019010318953303034383504D6 Not Visible 2-Way Mir RW X. 000190103189 00486 8900486000 4096 6006048000019010318953303034383604D7 Not Visible 2-Way Mir RW X. 000190103189 00487 8900487000 4096 60060480000190103189533030343837

Legend: Flags: (I)dentity : X = The device has a non-native external identity set . = The device does not have an external identity set (G)eometry : X = The device has a user defined geometry . = The device does not have a user defined geometry

c:\>

Migration step 10a: Mask the VMAX target devices 257

258


The symdev show command can also be used to display the Device External Identity defined for a FLM target device. The middle portion of the original Device WWN includes the VMAX Symmetrix ID, while the Device External Identity Device WWN includes the source DMX Symmetrix ID, and is identical to the Device WWN for the source DMX device. After all the normal and Ready device states, a new field for the Host Access Mode is set to PASSIVE. There is also a new field in the Remote Copy Device Information (Open Replicator session information) which shows that this is an FLM session Federated Live Migration : True.

c:\>symdev -sid 62 show 4d4

Device Physical Name : Not Visible

Device Symmetrix Name : 04D4 Device Serial ID : N/A Symmetrix ID : 000192601662. . .

Product Revision : 5875 Device WWN : 60000970000192601662533030344434. . .

Device Block Size : 512

Device Capacity { Cylinders : 4369 Tracks : 65535 512-byte Blocks : 8388480 MegaBytes : 4096 KiloBytes : 4194240 }

Device External Identity { Device WWN : 60060480000190103189533030343834

Front Director Paths (2): { ----------------------------------- DIRECTOR PORT LUN ---------- ---- -------- --------- Type Num Sts VBUS TID SYMM Host ----------------------------------- FA 07F:2 RW 000 00 069 N/A FA 10F:2 RW 000 00 033 N/A }

Geometry : Native {



Sectors/Track : 128 Tracks/Cylinder : 15 Cylinders : 4369 512-byte Blocks : 8388480 MegaBytes : 4096 KiloBytes : 4194240 } }. . .

Device Service State : Normal

Device Status : Ready (RW) Device SA Status : Ready (RW) Device User Pinned : FALSE Host Access Mode : PASSIVE

Extent Based Clone : None

Front Director Paths (2): { ---------------------------------------------------------------------- POWERPATH DIRECTOR PORT LUN --------- ---------- ---- -------- --------- PdevName Type Type Num Sts VBUS TID SYMM Host ---------------------------------------------------------------------- Not Visible N/A FA 07F:0 RW 000 00 069 N/A Not Visible N/A FA 10F:0 RW 000 00 033 N/A }. . .

Remote Copy Device Information { Remote Copy Session Name : flm Session State : Created Pull : True Offline Copy : False Differential Copy : Disabled Background Copy : Disabled Incremental Copy : False Donor Update : True

Federated Live Migration : True Frontend Zero Detection : False Starting Block : 0 Total Blocks : 8388480 Percent Copied : N/A Remote Devices [1] { --------------------------------------------------------------------- Array:Dev WWN Starting Block --------------------- -------------------------------- -------------- 000190103189:0484 60060480000190103189533030343834 0 } }


260


Mask the VMAX target devicesMasking the target VMAX devices with Auto-provisioning is as simple as adding the target devices to a storage group. The view that includes that storage group will automatically map and mask the new devices to the initiators and ports defined in the view as described in “Auto-provisioning Groups ” on page 161.

c:\>symaccess -sid 62 -name d096sg -type storage add devs 4d4:4d7

The new VMAX devices must be discovered on the application host and then configured into PowerPath. Since the new VMAX devices are now reporting the external identity of the DMX devices, PowerPath will configure the new VMAX devices as new paths to the existing old DMX devices. The EMC Host Connectivity Guide for Windows provides the appropriate procedure for adding devices online. In this example, the DiskPart utility is used to rescan and add additional device paths. In Windows, PowerPath is automatically configured when new devices or device paths are discovered.

c:\>diskpart

Microsoft DiskPart version 5.2.3790.3959Copyright (C) 1999-2001 Microsoft Corporation.On computer: SVCTAG-GNTFLH1

DISKPART> rescan

Please wait while DiskPart scans your configuration...

DiskPart has finished scanning your configuration.

DISKPART> exit

Leaving DiskPart...

c:\>



Displaying the post-create and target masking MPIO statusAfter the rescan, repeating the PowerPath CLI powermt display for device 12 now shows two additional paths to logical device 0484 on Symmetrix 000190103189. These new paths are actually the VMAX target devices as reflected in the reported FA interfaces 7fC and 10fC. The capital C indicates non-existent FA port 2; the Symmetrix adds the total number of the FA ports per director (in this example two for ports 0 and 1) to the actual port number when using device external identity, therefore representing port 0. This corresponds to the target device ports reported in “Determining target VMAX director WWNs” on page 247.

With Windows and PowerPath 4.5, the I/O Path State for host_passive devices will be marked dead in PowerPath displays. This is expected and required so that I/O is redirected properly during the FLM Migration. With Windows and PowerPath 4.6 and later, host_passive devices will not be marked dead in PowerPath displays, but I/O will still be properly redirected during the FLM Migration. Powerpath 4.5 is used in this example.

c:\>powermt display dev=12Pseudo name=harddisk12Symmetrix ID=000190103189Logical device ID=0484state=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============================================================================== 3 port3\path0\tgt2\lun6 c3t2d6 FA 4aA active alive 0 2 3 port3\path0\tgt3\lun5 c3t3d5 FA 10fC active dead 0 2 5 port5\path0\tgt0\lun5 c5t0d5 FA 7fC active dead 0 2 5 port5\path0\tgt1\lun7 c5t1d7 FA 13aA active alive 0 1

IMPORTANT

Do not proceed unless all the new VMAX devices have been configured as new paths to each of the old DMX devices involved in FLM migration. The next step in the process will set the old DMX devices to host_passive and I/O will fail unless the new VMAX paths are configured properly.

When all paths to the new VMAX devices have been discovered, save the running PowerPath configuration.

c:\>powermt save


262


Migration step 10b: Activate the FLM sessionFLM activate starts the Open Replicator background copy of data from the DMX source devices to the VMAX target device. It also switches the active and passive host access modes, so that the VMAX target devices will be in active mode and the DMX source devices will be in passive mode.

c:\>symrcopy -sid 62 -session_name flm activate -migrate -noprompt

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

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

c:\>The Open Replicator query output now shows CopyInProg(ress) state.

c:\>symrcopy -sid 62 -session_name flm query

Session Name : flm

Control Device Remote Device Flags Status Done---------------------------- ----------------------- ------- -------------- ---- ProtectedSID:symdev Tracks Identification RI CDSHUTZ CTL <=> REM (%)------------------ --------- --------------------- -- ------- -------------- ----000192601662:04D7 65528 000190103189:0487 SD X..XXM. CopyInProg 0000192601662:04D6 65528 000190103189:0486 SD X..XXM. CopyInProg 0000192601662:04D5 65528 000190103189:0485 SD X..XXM. CopyInProg 0000192601662:04D4 65528 000190103189:0484 SD X..XXM. CopyInProg 0

Total --------- Track(s) 262112 MB(s) 16382.0



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



Displaying the post-activate FLM statusRepeating, the PowerPath CLI powermt display for device 12 now shows the swap of alive (active) and dead (passive) paths.

c:\>powermt display dev=12Pseudo name=harddisk12Symmetrix ID=000190103189Logical device ID=0484state=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============================================================================== 3 port3\path0\tgt2\lun6 c3t2d6 FA 4aA active dead 0 3 3 port3\path0\tgt3\lun5 c3t3d5 FA 10fC active alive 0 2 5 port5\path0\tgt0\lun5 c5t0d5 FA 7fC active alive 0 2 5 port5\path0\tgt1\lun7 c5t1d7 FA 13aA active dead 0 2

If the application host is running Solutions Enabler, a symcfg discover command should be run to update the physical device (pdev) information in the SYMAPI database. Device Special Files previously associated with the old DMX will now be associated with the new VMAX.

c:\>symcfg discover


Monitor the ORS session until all devices reach a 'Copied' state.

c:\>

Migration step 10b: Activate the FLM session 263

264


Migration step 12: Tune migration The underlying Open Replicator session used for FLM can be tuned as described in “Migration step 12: symrcopy set ceiling” on page 103.

Migration step 13: Verify FLM session copy is doneThis step consists mostly of waiting until the Open Replicator copy completes. The query action will report the Status, the decreasing number of Protected Tracks, and the increasing Done percent. The normal status sequence goes from CopyInProg to Copied. Using the verify action allows scripts to wait for a particular status. The use of the count (-c) option limits how long to wait and the program can check for unsuccessful return status indicating an exit from the loop due to the count being reached rather than reaching the waited for status.

In the following example, the interval (-i) of 300 seconds (5 minutes) with a count of 6 means waiting for one half hour (30 minutes). In the example, the Copied state was reached within the one-hour time limit for checking. It is important to specify a realistic time limit based on the amount of data to be copied and the bandwidth or other tuning limitations that will affect how long the copy could take to complete.

c:\>symrcopy -sid 62 -session_name flm verify -copied -i 300 -c 6

None of the session(s) with name 'flm' are in 'Copied' state.

None of the session(s) with name 'flm' are in 'Copied' state.

. . .

All session(s) with name 'flm' are in 'Copied' state.



Migration step 15: Verify migration and FLM terminateBecause this is a hot pull, production applications are already using the VMAX target devices, in effect verifying the validity of the copied data. However, if any application specific verification of the migration is desired, it must be completed before terminating the FLM session along with the donor update feature that keeps the original source updated with all changes since the production applications began using the targets. Once the validation is complete, the FLM session is no longer needed and can be terminated by executing a command that looks something like the following:

c:\>symrcopy -sid 62 -session_name flm terminate -migrate -noprompt

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

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

Migration step 15: Verify migration and FLM terminate 265

266


Cleanup step 19: Redeploy source devices storageGiven the consolidation and technology refresh use cases common for FLM, the source arrays are often not redeployed. As long as the new VMAX devices continue to use the device external identity of the source devices, the old source array devices cannot be present in the same SAN. FLM ensures that this will not happen accidentally by leaving the donor array devices in passive host access mode.

The old DMX devices should be removed from the application host by changing the zoning and masking.

c:\>symmask -sid 89 -dir 4a -p 0 -wwn 10000000c977eae0 remove devs 484:487 -noprompt

c:\>symmask -sid 89 -dir 13a -p 0 -wwn 10000000c977eb7c remove devs 484:487 -noprompt

c:\>symmask -sid 89 refresh

Symmetrix FA/SE directors updated with contents of SymMask Database 000190103189

c:\> Once the devices are no longer host accessible, they must be removed from PowerPath. A host rescan is necessary for Windows to recognize that the devices have been removed. PowerPath will not allow devices to be removed if the operating system believes they are still accessible.

c:\>diskpart

Microsoft DiskPart version 5.2.3790.3959Copyright (C) 1999-2001 Microsoft Corporation.On computer: SVCTAG-GNTFLH1

DISKPART> rescan

Please wait while DiskPart scans your configuration...

DiskPart has finished scanning your configuration.

DISKPART> exit

Leaving DiskPart...

c:\>The rescan forces Windows to recognize that the old DMX devices have been removed and are no longer accessible. PowerPath can now remove the dead device paths to the old storage. The command



powermt remove dev=all should be used to remove dead paths which are no longer accessible. This command will only remove paths which Windows recognizes are not allocated and will not have any impact on active and available paths.

c:\>powermt remove dev=allCannot remove device that is in use: c3t2d0Cannot remove device that is in use: c3t2d10Cannot remove device that is in use: c3t2d11Cannot remove device that is in use: c3t2d12Cannot remove device that is in use: c3t2d13Cannot remove device that is in use: c3t2d14. . .Cannot remove device that is in use: c5t3d4

The old DMX devices paths have been removed and the application host is now using only the new VMAX devices.

c:\>powermt display dev=12Pseudo name=harddisk12Symmetrix ID=000190103189Logical device ID=0484state=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============================================================================== 3 port3\path0\tgt2\lun6 c3t2d6 FA 4aA active alive 0 1

5 port5\path0\tgt1\lun7 c5t1d7 FA 13aA active alive 0 1

The errors are records of the path state changes. These can be cleared with powermt restore which performs a path check and reports nothing if all paths are alive and available.

c:\>powermt restore

c:\>powermt display dev=12Pseudo name=harddisk12Symmetrix ID=000190103189Logical device ID=0484state=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============================================================================== 3 port3\path0\tgt2\lun6 c3t2d6 FA 4aA active alive 0 0

5 port5\path0\tgt1\lun7 c5t1d7 FA 13aA active alive 0 0

When all paths to the old DMX devices have been removed, save the running PowerPath configuration

c:\>powermt save

Cleanup step 19: Redeploy source devices storage 267

268


Federated identity removalAt some future time when it is desirable to no longer have the old source array device identities continue to be used, the target VMAX devices can be set to stop using the device external identity. This will require stopping the application and setting it to point correctly to the target device native identity.

The process is performed in three steps with careful attention to cleaning up the operating system and multipath software to avoid identity confusion:

◆ Allocation removal of new VMAX devices with device external identity in effect

◆ Removal of device external identity

◆ Allocation of new VMAX devices with native identity

IMPORTANT

Application I/O should be halted on the application host to avoid data unavailability when the device allocation is removed. Drive Mounts and/or Mount points can be removed using the Windows mountvol or Solutions Enabler symntctl utility to guarantee there is no additional I/O to the new VMAX volumes.

An example of the middle step to reset the identity would look something like the following:

c:\>symconfigure -sid 62 -cmd "set dev 4d4:4d7 identity = NO identity;" commit -noprompt

A Configuration Change operation is in progress. Please wait...

Establishing a configuration change session...............Established. Processing symmetrix 000192601662 Performing Access checks..................................Allowed. Checking Device Reservations..............................Allowed. Locking devices...........................................Locked. Committing configuration changes..........................Started. Committing configuration changes..........................Committed. Terminating the configuration change session..............Done.

The configuration change session has successfully completed.

c:\>


A

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

◆ Two goals of Open Replicator tuning ........................................... 270◆ Resource conflicts............................................................................. 271◆ Limiting Open Replicator resource usage .................................... 272◆ Migration options can impose performance delays.................... 274◆ Tuning Open Replicator .................................................................. 275◆ Monitoring Open Replicator performance................................... 278◆ Tuning for applications sensitive to response time..................... 282

Open ReplicatorPerformance Tuning

Open Replicator Performance Tuning 269

270

Open Replicator Performance Tuning

Two goals of Open Replicator tuningOpen Replicator tuning is a matter of balancing two possibly conflicting goals. Usually, the most important goal of Open Replicator tuning is to ensure that the data migration does not unacceptably impact the simultaneously running production applications. The secondary goal is to ensure that the data migration completes within the planned window for the migration. These goals will conflict when the number of resources needed to meet the migration window goal results in undesired impact to production applications.



Resource conflictsOpen Replicator impact on production application performance is mainly a result of I/O resource conflict. There might also be some CPU impact when Open Replicator management is executed on the application host.

I/O resource paths

The production application I/O path goes from the:

Production Host I/O Queue HBA SAN Source Array

except in the case of a hot pull, when the production I/O is redirected to the Target Array.

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

Source Array SAN Target Array

Array I/O conflicts

In the case of a push migration, both the production and migration applications utilize resources in the source storage array (the control Symmetrix VMAX or Symmetrix DMX array). In the case of hot pull migration, both the production and migration applications utilize resources in the target ?torage array (the control Symmetrix VMAX or Symmetrix DMX array). The key contended resource in the storage array I/O path is the control Symmetrix VMAX (or Symmetrix DMX) front-end fibre director (FA) that connects the array to the host through the SAN. When the FA is used for both production and migration resources, there is conflict when there is not enough excess capacity to meet both demands fully. And even if there is enough capacity to meet the dual demands, there is still queuing conflicts when competing requests arrive simultaneously. One request will be serviced first, while the other must wait resulting in an extended service time. Within the Symmetrix VMAX (or Symmetrix DMX) there also will be competition for cache memory and back-end disk I/O, however this competition has less impact due to the asynchronous nature of performance impact in an integrated cached disk array (ICDA). Performance tuning approaches for Open Replicator cache memory and back-end disk I/O are not any different than tuning for these resources with other applications.

Resource conflicts 271

272


Limiting Open Replicator resource usage

Using a separate management host

As a SAN-based migration product, Open Replicator avoids I/O conflicts at the production host. The command management I/O for Open Replicator uses a very small amount of prod? ction host I/O resources if executed on the production host. For this reason (and to avoid similarly low impact CPU utilization) sometimes Open Replicator migration is directed from a separate management host. The Open Replicator management CPU and I/O resource usage is probably too small to have a significant impact, so the use of a separate management host is typically a result of conforming to site defined practices. Note that certain cleanup migration phase steps can only be executed on the production host. Correspondingly, PowerPath Migration Enabler (PPME) needs to be executed on the production host. Federated Live Migration (FLM) is designed to be executed on a separate management host, limiting application host operations to the minimum.

Limiting Symmetrix FA director competition

Given that both production and migration applications are contending for FA resources, tuning FA performance is a matter of limiting one application's I/O requests to the benefit of the other. Most migrations will actually employ multiple strategies to achieve this.

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

A second strategy involves using independent FA resources to permit both production and migration applications to avoid resource contention with each other, though each still may not find its independent resources sufficient to avoid performance issues. Only



Open Replicator cold migrations can fully utilize this strategy. Open Replicator hot migrations require all FA directors that are mapped to the control devices to be configured to support Copy on First Access/Write (COFx) operations. The ceiling setting can be used to limit Open Replicator hot migration I/Os to only COFx I/Os.

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

Limiting Open Replicator resource usage 273

274


Migration options can impose performance delaysCertain Open Replicator migration configurations result in systemic performance delays in return for a desired feature. For example, hot migration COFx activity means that the production I/O is delayed until the migration copy operation preserving the activate point-in-time completes first. This delay can be avoided by using a cold migration configuration. This delay can be minimized in the case of hot push, by using the -precopy option to reduce the number of tracks not yet copied to the remote requiring COFW I/Os (Note: precopy requires Enginuity 5772 or higher). Hot pull migrations that utilize the -donor_update option also have a systemic performance delay of copying the write I/Os to the remote before allowing the production write to the control to complete.



Tuning Open ReplicatorOpen Replicator performance can be tuned by static configuration choices or using dynamic commands both before and during a migration to set ceiling, pace or nocopy mode.

Static configuration limits on Open Replicator resource use

The goal of static configuration for performance is to separate the FA director resources used by Open Replicator migrations from production applications. If the Symmetrix VMAX (or Symmetrix DMX) has enough FA director ports, then Open Replicator cold migrations can be configured to use independent FA director ports. This can be achieved by mapping the control devices to one or more FA director ports not used by production applications. Then, these migration control FA director ports would be zoned and LUN masked to see the remote array directors and devices. If there are no free FA director ports, then cold migrations can be configured to use a subset of the FA director ports used by production applications, thus limiting the FA director ports where there is competition for resources.

For hot migration configurations, it is still possible to partially achieve the use of independent FA director ports. The static configuration part is the same as for cold migrations - mapping the control devices to one or more FA director ports not used by production applications. However, hot migration configurations require all control FA director ports to be zoned and LUN masked for COFx access, thus all of the production application FA director ports must be configured for Open Replicator use. Fortunately, the ceiling setting can be used to severely limit the use of the shared FA director ports. Setting the ceiling value to zero percent means that a FA director port will not be used for any background copy migration operations; it will only be used for COFx activity as needed.

Dynamic limits on Open Replicator resource use

Open Replicator provides three alternatives for limiting Open Replicator use of shared FA director ports that can be changed before and during a migration: the ceiling parameter which limits fibre bandwidth that can be used by Open Replicator, the pace parameter

Tuning Open Replicator 275

276


which defines delays added between Open Replicator operations, and the nocopy mode which suspends Open Replicator background copy activity.

Ceiling The ceiling parameter is the primary and most predictable tuning mechanism because it directly sets a maximum FA director port bandwidth that can be used by Open Replicator. The default ceiling value is NONE, theoretically allowing Open Replicator to use up to 100 percent of the FA port bandwidth. Setting the ceiling value to any value less than 100 percent limits the potential Open Replicator use of the FA port, and overrides any setting of the pace value. This value can be set prior to the migration or changed at any time during the migration. A command can be used to set the same ceiling value for all FA ports, or the ceiling value for each FA port can be set independently. If the production applications have time of day or week variations that might tolerate or suffer more from a higher contention for resources at certain times, then the ceiling value can be dynamically adjusted. Note that the command that lists ceiling values, also displays the current Open Replicator use of bandwidth, effectively reporting whether all the capacity up to the current ceiling value is actually being used.

PaceThe pace parameter limits the use of all FA ports used for a particular Open Replicator session by inserting delays between Open Replicator I/O requests. Although this effectively limits use of the FA port, it also guarantees that the migration will take longer, even if there is spare capacity in the FA port. The range of valid values is from 0 to 10, with a default value of 5. A pace setting of zero does not insert any delay. A value of 10 inserts the maximum delay. The parameter value can be displayed using the -detail option with the query or list actions. The PPME throttle setting is an alternate interface to the Open Replicator pace setting. The pace value is ignored for all participating director/port combinations where the ceiling value is not NONE.

Nocopy modeThe ability to dynamically switch an Open Replicator session into nocopy mode provides a simple way to temporarily suspend all but COFx migration I/O requests. The most common use of nocopy mode is to initially set a hot pull session in nocopy mode so that initial high COFA I/O is not joined by any background copy I/O. This setting has to be temporary because it is necessary to set the mode back to



background copy in order for the migration to complete with all tracks copied to the target. The current mode setting can be determined by interpreting the C flag setting displayed in the output of the query or list actions.

Tuning Open Replicator 277

278


Monitoring Open Replicator performanceFor this monitoring session, a hot push session using the same devices as in “Setup step 5: Prepare Open Replicator session pairs file” on page 174 was created with ceiling set to 10 percent.

symrcopy query

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

c:\>symrcopy -session hot_push query

Session Name : hot_push

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

symrcopy list ceiling

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



c:\>symrcopy -sid 359 list ceiling



Max Set Actual Dir:P (MB) (%) (MB) ----- ---- ---- ------ 01C:0 150 NONE 0 01C:1 150 NONE 0 02C:0 150 10 15 02C:1 150 NONE 0 15C:0 150 10 14 15C:1 150 NONE 0 16C:0 150 NONE 0 16C:1 150 NONE 0

c:\>

symstat with -RepType rcopyThe symstat command has three status actions that use the Open Replicator specific -RepType rcopy option. The first example uses the -type REQUESTS option. The short interval of 10 seconds (-i 10) and count of 3 (-c 3) quickly generate two sets of calculated delta output. Best practice would use a much longer interval to both provide more meaningful data and to avoid more frequent polling for performance data than really necessary. Notice the values for PUSH KB/sec for each of the four control devices.

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

RCopy -------------- Device KB/sec14:19:11 PULL PUSH

14:19:21 0095 (DRIVE15) 0 8908 0096 (DRIVE16) 0 9414 0097 (DRIVE17) 0 5804 0098 (DRIVE18) 0 6457

14:19:31 0095 (DRIVE15) 0 9664 0096 (DRIVE16) 0 8857 0097 (DRIVE17) 0 5798 0098 (DRIVE18) 0 5817

c:\>

Monitoring Open Replicator performance 279

280


The second symstat example uses the -dir ALL option, which could also have specified an individual director. Notice the Open Replicator cache usage for directors 2C and 15C.

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

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

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

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

c:\>The third symstat example uses the -type PATH option, which has two sorting options; -by_session is used here. Notice the total and remaining tracks to be copied per device.

c:\>symstat -type path -sid 359 -reptype rcopy -i 10 -c 2 -by_session

Time Session Control Target Tracks Director RCopyStamp Name Device Destination Total Remaining Port Ceiling

14:20:49 hot_pu* 0095 000187720450:0141 65535 51048 FA-2C:0 10 N/A 65535 51048 FA-15C:0 10 hot_pu* 0096 000187720450:0142 65535 50995 FA-2C:0 10 N/A 65535 50995 FA-15C:0 10 hot_pu* 0097 000187720450:0143 65535 54568 FA-2C:0 10 N/A 65535 54568 FA-15C:0 10 hot_pu* 0098 000187720450:0144 65535 54708 FA-2C:0 10 N/A 65535 54708 FA-15C:0 10

Time Session Control Target Tracks Director RCopyStamp Name Device Destination Total Remaining Port Ceiling

14:20:59 hot_pu* 0095 000187720450:0141 65535 49689 FA-2C:0 10 N/A 65535 49689 FA-15C:0 10 hot_pu* 0096 000187720450:0142 65535 49696 FA-2C:0 10 N/A 65535 49696 FA-15C:0 10 hot_pu* 0097 000187720450:0143 65535 53567 FA-2C:0 10 N/A 65535 53567 FA-15C:0 10 hot_pu* 0098 000187720450:0144 65535 53556 FA-2C:0 10 N/A 65535 53556 FA-15C:0 10

c:\>



The fourth symstat example again uses the -type PATH option, this time using the -by_port sorting option. In addition to the total and remaining tracks to be copied per device, the MB/sec transfer rate is listed for each director port.

c:\>symstat -type path -sid 359 -reptype rcopy -i 10 -c 2 -by_port

Time Director RCopy Port RCopy Control Tracks 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:\>

Monitoring Open Replicator performance 281

282


Tuning for applications sensitive to response timeIn order to maintain the activate point-in-time, Open Replicator hot migration COFx I/Os will occur even if background copy migration activity is already using the allowed ceiling percentage of FA port bandwidth. An example of a production application that is sensitive to response time is MicroSoft Cluster Server (MSCS). MSCS performs frequent SCSI reservation queries on its LUNs, to ensure that the active nodes still have SCSI reservations on the LUNs in order to prevent a split brain cluster. If a particular active MSCS node sees that it has lost its SCSI reservation, or does not receive an acknowledgement that it still has a reservation quickly enough, it will take its resources offline to prevent data corruption due to a split brain. Excessive COFx activity on FA ports that do not have enough bandwidth can slow down these SCSI reservation responses to a point that MSCS will go offline.

The Open Replicator migration use of bandwidth can be mitigated with a number of tuning strategies. For hot push, precopy should be utilized reducing COFW I/Os at activate time. Sessions should initially be in nocopy mode, and only switched to background copy mode, once COFx activity starts to slow down. Start with a relatively low ceiling (15–20%), and then gradually increase the ceiling, keeping a close watch on host I/Os per second (IOPS) and response time avoiding allowing Open Replicator to affect the production applications' response times too much.


B

This appendix provides log information that correlates with the examples presented in Chapters 4–9. Log examples are shown for commands resulting in both success and failure. Also included is an example of an Enginuity 5773 enhancement of Open Replicator that enables reactivating a failed differential push session. The topics covered include:

◆ Solutions Enabler logs ..................................................................... 284◆ Audit Log .......................................................................................... 290◆ PowerPath Migration Enabler logs ............................................... 292◆ Reactivate Failed Session ................................................................ 295

Troubleshooting

Troubleshooting 283

284

Troubleshooting

Solutions Enabler logsThe Solutions Enabler log directory is a subdirectory of the working solutions enabler directory. If the default directories were used for Solutions Enabler installation, the logs can be found in:

• UNIX: /var/symapi/log

• Windows C:\Program Files\EMC\SYMAPI\log

Inside the log directory, there are two log file types related to this TechBook: symapi-YYYYMMDD.log and symntctl-YYYYMMDD.log.

Cold push example log entriesFor example, the log entries related to operations in Chapter 4, “Cold Push to CLARiiON Setup Example,” and Chapter 5, “Cold Push to CLARiiON Migration Example,” are displayed in the next eight subsections.

Open Replicator create and not_ready control devicesThe following excerpt from the symapi-20080618.log and symapi-20080619.log corresponds to the example shown in “Verify all with symrcopy create” on page 84:

06/18/2008 16:17:03.854 1896 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy CREATE (PUSH) (COLD)06/18/2008 16:17:03.854 1896 1 EMC:SYMRCOPY validateCreate Cannot CREATE (COLD) session on dev:00A0, sid:000190300359, it is not NR06/18/2008 16:17:03.854 1896 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operation FAILED. (SYMAPI_C_INV_DEVICE_RDY_STATUS)06/18/2008 16:20:08.434 1907 STARTING a 'NOT_READY' control operation.06/18/2008 16:20:08.435 1907 1 EMC:SYMCLI SymDevListControl() symdev list: symid: 000190300359 director: N/A, port: N/A ()06/18/2008 16:20:08.488 1907 1 EMC:SYMCLI test_dev_state() TestState: DEV_STATE_NOT_READY_DEVICE, SymID: 000190300359 Dev: (00A3) Remote: 0, Src: 0, BCV: 0, cfg: Inv Dev sts: RW, SA: RW, RA: RW, DA: RW, Link: RW, Consistency: DIS, Susp Pend: 0, BCV: 0, BCV Paired: 0 BCV State: NeverEstab, InvR1: 0, InvR2: 0, R2WPonR1: 0 Mode: SYN, Dom: ENB, ACp: OFF, API sts: SYMAPI_C_INV_DEVICE_RDY_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: 000190300359 director: 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: 000190300359 director: 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.


Troubleshooting

. . .06/19/2008 16:59:45.664 2545 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy CREATE (PUSH) (COLD)06/19/2008 16:59:45.665 2545 STARTING a RCOPY 'CREATE' operation.06/19/2008 16:59:53.138 2545 1 EMC:SYMRCOPY doPaceOnDev Setting throttle to 0xff, dev: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.

TimeFinder/Mirror establish and Open Replicator terminateThe following excerpt from the symapi-20080624.log corresponds to the example shown in “Initial TimeFinder/Mirror establish” on page 95:

06/24/2008 18:21:30.926 4327 1 EMC:SYMMIR evaluate_dev BCV Device: 0080 (000190300359) is an RCOPY push source in created/recreated 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:SYMRCOPY SymRemoteCopyControl 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' operation SUCCEEDED.06/24/2008 18:22:33.929 4335 1 EMC:SYMMIR SymDgBcvControl() dg: cpgroup, ldev: , SymID: 000190300359, symdev: , bcvdev: , flags: (exact)06/24/2008 18:22:33.933 4335 STARTING a BCV 'ESTABLISH' operation for 4 [SRC-TGT] Pairs:06/24/2008 18:22:33.977 4335 Symm 000190300359 Number of Pairs: 4 Operation Flags: 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.

TimeFinder/Mirror splitThe following excerpt from the symapi-20080624.log corresponds to the example shown in “TimeFinder/Mirror split” on page 96:

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.

Open Replicator create and not_ready control devices repriseThe following excerpt from the symapi-20080624.log corresponds to the examples shown in “Cold control devices must be Not Ready” on page 98 and “Create action options” on page 99:

06/24/2008 18:46:56.404 4350 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy CREATE (PUSH) (COLD) (DIFFERENTIAL)06/24/2008 18:46:56.405 4350 1 EMC:SYMRCOPY validateCreate Cannot CREATE (COLD) session on dev:0080, sid:000190300359, it is not NR06/24/2008 18:46:56.405 4350 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'CREATE' operation FAILED. (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: 000190300359 ldev: 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.

Solutions Enabler logs 285

286

Troubleshooting

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.

Open Replicator activate and set ceilingThe following excerpt from the symapi-20080624.log corresponds to the examples shown in “Migration step 10: symrcopy activate” on page 102 and “Migration step 12: symrcopy set ceiling” on page 103:

06/24/2008 21:45:44.987 1646 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy 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' operation SUCCEEDED.06/24/2008 21:47:09.376 1662 1 EMC:SYMRCOPY SymDirectorQosSet STARTING a QOS 'SymDirectorQosSet' operation - symid: 000190300359, start dev: 0x0000, num devs: 0. LRU set: F , Pace: BCV(F), RDF(F), BCS(F), MIR(F), SNAP(F)06/24/2008 21:47:09.385 1662 1 EMC:SYMRCOPY SymDirectorQosSet QOS 'SymDirectorQosSet' operation SUCCEEDED.06/24/2008 21:47:26.422 1665 1 EMC:SYMRCOPY SymDirectorQosSet STARTING a QOS 'SymDirectorQosSet' operation - symid: 000190300359, start dev: 0x0000, num devs: 0. LRU set: F , Pace: BCV(F), RDF(F), BCS(F), MIR(F), SNAP(F)06/24/2008 21:47:26.442 1665 1 EMC:SYMRCOPY SymDirectorQosSet QOS 'SymDirectorQosSet' operation SUCCEEDED.

TimeFinder/Mirror incremental update of control devicesThe following excerpt from the symapi-20080625.log corresponds to the example shown in “Incrementally update control devices from production devices” on page 106:

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: 000190300359 ldev: 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.

Open Replicator incremental update of remote devicesThe following excerpt from the symapi-20080625.log corresponds to the example shown in “Incrementally update remote devices from control devices” on page 107:

06/25/2008 10:56:36.792 2031 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy 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' operation SUCCEEDED.06/25/2008 10:57:05.256 2034 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy ACTIVATE


Troubleshooting

06/25/2008 10:57:05.256 2034 STARTING a RCOPY 'ACTIVATE' operation.

06/25/2008 10:57:05.513 2034 1 EMC:SYMRCOPY SymRemoteCopyControl The Rcopy 'ACTIVATE' operation SUCCEEDED.

Open Replicator terminate and make source devices inaccessibleThe following excerpt from the symapi-20080625.log and symapi-20080709.log corresponds to the examples shown in “Migration step 15: Verify migration and symrcopy terminate” on page 110 and “Cleanup step 16: Make source devices host inaccessible” on page 112:

06/25/2008 13:24:30.940 2136 1 EMC:SYMRCOPY SymRemoteCopyControl STARTING a REMOTE Copy 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' operation SUCCEEDED.. . .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 Symmetrix device masking session for Symmetrix 000190300359 with devmask handle 10007/09/2008 01:56:15.594 3614 1 EMC:SYMMASK emcAddorRemoveDevice Removing the following devices from the device masking database for Symmetrix 000190300359 by WWN 210000e08b927df4 for director 34 for port 007/09/2008 01:56:15.681 3614 1 EMC:SYMMASK SymDevMaskSessionEnd Successfully ended a Symmetrix device masking session for Symmetrix 00019030035907/09/2008 01:57:16.415 3621 1 EMC:SYMMASK SymDevMaskSessionSta Successfully started a Symmetrix device masking session for Symmetrix 000190300359 with devmask handle 10007/09/2008 01:57:16.538 3621 1 EMC:SYMMASK emcAddorRemoveDevice Removing the following devices from the device masking database for Symmetrix 000190300359 by WWN 210000e08b925cf5 for director 47 for port 007/09/2008 01:57:16.613 3621 1 EMC:SYMMASK SymDevMaskSessionEnd Successfully ended a Symmetrix device masking session for Symmetrix 00019030035907/09/2008 01:57:31.990 3624 1 EMC:SYMMASK SymDevMaskSessionSta Successfully started a Symmetrix device masking session for Symmetrix 000190300359 with devmask handle 10007/09/2008 01:57:33.262 3624 1 EMC:SYMMASK SymDevMaskControl Refreshing FAs with contents of device masking database for Symmetrix 00019030035907/09/2008 01:57:33.319 3624 1 EMC:SYMMASK SymDevMaskSessionEnd Successfully ended a Symmetrix device 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

Hot pull example log entriesThe log entries related to Chapter 6, “Hot Pull from CLARiiON Migration Example,” are very similar to the ones shown for the cold push operation above. Therefore only the error related log entries for missing zoning and missing masking are displayed in the following sections.

Missing zoning errorThe following excerpt from the symapi-20080717.log corresponds to the example shown in “Discover missing zoning with symrcopy create” on page 131:

07/17/2008 09:36:20.703 2328 3852 STARTING a RCOPY 'CREATE' operation.

07/17/2008 09:36:21.250 2328 3852 EMC:SYMRCOPY checkForCreateFai Create failed on dev:0091, sid:000190300359, status:loc_sts:0x8 SYSC_SESSION_DISCOVER_FAILED07/17/2008 09:36:21.250 2328 3852 EMC:SYMRCOPY map_discover_erro loc_dir:02C, rem_num:0, rem_sts:0x1SANCOPY_DEV_SUCCESS 07/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_TARGETS


288

Troubleshooting

07/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' operation FAILED. (SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)

Missing masking errorThe following excerpt from the symapi-20080717.log corresponds to the example shown in “Discover missing LUN masking with symrcopy create” on page 133:

07/17/2008 11:16:18.265 2784 2780 STARTING a RCOPY 'CREATE' operation.

07/17/2008 11:16:18.875 2784 2780 EMC:SYMRCOPY checkForCreateFai Create failed on dev:0091, sid:000190300359, status:loc_sts:0x8 SYSC_SESSION_DISCOVER_FAILED07/17/2008 11:16:18.890 2784 2780 EMC:SYMRCOPY map_discover_erro loc_dir:02C, rem_num:0, rem_sts:0x1SANCOPY_DEV_SUCCESS 07/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_FOUND 07/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' operation FAILED. (SYMAPI_C_RCOPY_MULT_SESS_DEF_ERR)

Stopping and restarting application using the targetsThe following excerpt from the symntctl-20080717.log corresponds to the examples shown in “Migration step 9: Stop the applications” on page 136 and “Migration step 11: Restart applications using targets” on page 139:

07/17/08 16:13:51InitLog Symntctl Log 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 operation failed.07/17/08 16:13:51GetVdsVolumeByName Enter GetVdsVolumeByName()07/17/08 16:13:51IoctlUnmount Enter IoctlUnmount()07/17/08 16:13:51CreateFile Enter CreateFile()07/17/08 16:13:51DeviceIoControl FSCTL_LOCK_VOLUME


Troubleshooting

07/17/08 16:13:51FlushFileBuffers Enter FlushFileBuffers()07/17/08 16:13:51DeviceIoControl FSCTL_DISMOUNT_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 paths to the volume.07/17/08 16:13:51SymapiDisconnect Enter SymapiDisconnect()07/17/08 16:13:51Action Complete, exiting...07/17/08 16:13:51EndEventLog Enter EndEventLog()07/17/08 16:13:51EndLog Symntctl Log Closed. . .07/17/08 17:33:38ProcessInput symntctl.exe rescan. . .07/17/08 17:55:53ProcessInput symntctl.exe update -sid 359 -symdev 91. . .07/17/08 18:00:42ProcessInput symntctl.exe mount -drive L: -sid 359 -symdev 91. . .


290

Troubleshooting

Audit LogData is written to a common audit file during Symmetrix control operations initiated by host applications. The common audit log correlates activity from all hosts into one file that is stored in the Symmetrix. The symaudit command and the SMC Symmetrix Admin - SymAudit Records display can be used to filter and display the common audit log file for a specified Symmetrix array.

The symaudit list example below filters for Open Replicator actions on 07/17/2008. The records briefly listed below correspond to the examples shown in “Successful create verifies hot pull setup” on page 135 and “Migration step 10: symrcopy activate” on page 138:

c:\>symaudit list -sid 359 -function_class rcopy -start_date 07/17 -end_date 07/18

A U D I T L O G D A T A


Record Function Action Number Date Time Application Host Class Code ------ -------- -------- ---------------- ------------ -------- ---------

8849 07/17/08 12:27:09 SYMRCOPY LICOD194 RCopy Create 8850 07/17/08 12:27:09 SYMRCOPY LICOD194 RCopy Create 8851 07/17/08 12:27:10 SYMRCOPY LICOD194 RCopy Create 8861 07/17/08 17:21:03 SYMRCOPY LICOD194 RCopy Activate 8862 07/17/08 17:21:03 SYMRCOPY LICOD194 RCopy Activate 8863 07/17/08 17:21:03 SYMRCOPY LICOD194 RCopy Activate. . .

c:\>


Troubleshooting

Using the -v option shows details of each audit log record. For example, details for the three Create audit log entries numbered 8849-8851:

c:\>symaudit list -sid 359 -v -record_num 8849 -n 3

A U D I T L O G D A T ASymmetrix ID : 000190300359

Record Number : 8849 Records in Seq : 2 Offset in Seq : 1 Time : 07/17/08 12:27:09 Vendor ID : EMC Corp Application ID : SYMRCOPY Application Version : 6.5.1.0 API Library : SEK API Version : V6.5.1.0 (Edit Level: 882) Host Name : LICOD194 OS Name : WinNT OS Revision : 5.2.3790Se Client Host : Process ID : 00003728 Task ID : 00003732 Function Class : RCopy Action Code : Create Text : STARTING a RCopy 'CREATE' operation for Device List. Options=(Hot, Pull, CopyMode, DonorUpdate) Username : H:LICOD194\Administrator Activity ID : SE1ceeb91751

Record Number : 8850 Records in Seq : 2 Offset in Seq : 2 Time : 07/17/08 12:27:09. . . Text : Symm 000190300359 Ctrl-Rem Devices: [ 0091-HK190807410004:0 0092-HK190807410004:1 0093-HK190807410004:2 0094-HK190807410004:3 ] Username : H:LICOD194\Administrator Activity ID : SE1ceeb91751

Record Number : 8851 Records in Seq : 1 Offset in Seq : 1 Time : 07/17/08 12:27:10. . . Text : The Rcopy 'CREATE' operation SUCCESSFULLY COMPLETED. Username : H:LICOD194\Administrator Activity ID : SE1ceeb91751

c:\>

Audit Log 291

292

Troubleshooting

PowerPath Migration Enabler logsPowerPath Migration Enabler (PPME) can log audit and error log messages to a common file. The PowerPath Migration Enabler User Guide includes details on how to configure the Solaris host syslog.conf(4) file to write local0.info messages to a common log file. On Windows hosts these messages appear in the Event Log without any additional configuration.

Figure 84 shows the Windows Computer Management screen with the Event Viewer selected so that Application Events are displayed. The selected entry is of type Error and the source is EmcpLogMsgs which includes PPME messages

Figure 84 Windows Event Viewer with PPME error message selected

ICO-IMG-000590


Troubleshooting

Double-clicking on the selected row or selecting the menu items Action > Properties displays the details of the message in Figure 85, which shows the missing PPME license corresponding to “PPME license required” on page 217.

Figure 85 Event Properties detail for missing PPME license

ICO-IMG-000591

PowerPath Migration Enabler logs 293

294

Troubleshooting

Figure 86 shows part of the Event Viewer screen with an informational PPME message selected.

Figure 86 Windows Event Viewer with PPME error message selected

Figure 87 shows the Event Properties detail for a powermig setup command that was executed in “PPME Setup steps 5–6: powermig setup” on page 215.

Figure 87 Event Properties detail for missing PPME license

ICO-IMG-000592

ICO-IMG-000593


Troubleshooting

Reactivate Failed Session Prior to Enginuity 5773, the state of the Open Replicator session was set to Failed ?f a transient network or device issue was encountered. The only option available from the Failed state was to terminate the session. Enginuity version 5773 allows failed sessions to be reactivated as long as certain criteria are met. Only sessions where no new data has been written to the control device since the session failed can be reactivated.

If new data has been written, the session should be terminated. This is because when a hot push session fails, a write to the control device succeeds, as does a full track write on a failed hot pull session. This could lead to a situation where data on the control device that still needs to be pulled or pushed is not part of the initial point-in-time. Reactivating the Open Replicator session in these circumstances may result in data being overwritten on the control device on a pull or inconsistent data being written to the remote device on a push.

In the example shown below, the same Open Replicator device pairs in Chapter 7, “Hot Pull from Symmetrix Migration Example,” were used for a hot push. The remote devices were made not_ready to simulate a transient failure. Notice the Status in the query output below indicates both the failed state and that the failed session is eligible to be reactivated:



Control Device Remote Device Flags Status Done--------------------------- --------------------- ----- ---------- ---- 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) 141266 MB(s) 8829.1. . .Flags:. . .(*): The failed session can be reactivated.

c:\>

Reactivate Failed Session 295

296

Troubleshooting

Once the transient error condition is corrected (in this case making the remote devices ready), the session can be reactivated. The syntax to reactivate the session is the same as that used to originally activate the session:

c:\>symrcopy -session hot_push activate -consistent

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 show that the Status has changed back to CopyInProg. Additionally, the Protected Tracks values have decreased and the Done % values have increased showing that the copy session is closer to completion:



Control Device Remote Device Flags Status Done--------------------------- --------------------- ----- ---------- ---- 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) 112974 MB(s) 7060.9. . .c:\>


This glossary contains terms related to disk storage subsystems. Many of these terms are used in this guide.

Aadministrator A person responsible for administrative tasks such as access

authorization and content management. Administrators can also grant levels of authority to users.

agent A software entity that runs on endpoints and provides management capability for other hardware or software.

allocate To assign a resource for use in performing a specific task.

allocated storage The space that is allocated to volumes, but not assigned.

audit To review and examine the activities of a data processing system mainly to test the adequacy and effectiveness of procedures for data security and data accuracy.

authority The right to access objects, resources, or functions.

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 computer data that can be used to recreate data that has been lost, mislaid, corrupted or erased.

Glossary


298

Glossary

bandwidth A measure of the data transfer rate of a transmission channel.

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-defining record formats in which each record is represented by a count area that identifies the record and specifies its format, an optional key area that may be used to identify the data area contents, and a data area that contains the user data for the record. CKD can also refer to a set of channel commands that are accepted by a device that employs the CKD recording format.

CLI See ”Command Line Interface (CLI).”

client A function that requests services from a server, and makes them available to the user. A term used in an environment to identify a machine that uses the resources of the network. See also ”client-server.”

client-server In TCP/IP, the model of interaction in distributed data processing in which a program at one site sends a request to a program at another site and awaits a response. The requesting program is called a client; the answering program is called a server.

client-serverrelationship

Any process that provides resources to other processes on a network is a server. Any process that employs these resources is a client. A machine can run client and server processes at the same time.

COFA See ”copy on first access (COFA).”

COFW See ”copy on first access (COFA).”

cold operation Open Replicator mode where the Symmetrix DMX control device must be offline to the host application. See also ”hot operation.”

Command LineInterface (CLI)

A mechanism for interacting with a computer operating system or software by typing commands to perform a given task, referred to as “entering” a command: the system waits for the user to conclude the submitting of the text command by pressing the Enter key. A


Glossary

command line interpreter then receives, analyses, and launches the requested command. Upon completion, the command usually returns output to the user in the form of text lines on the CLI.

connection In TCP/IP, the path between two protocol applications that provides reliable data stream delivery service. In Internet communications, a connection extends from a TCP application on one system to a TCP application on another system.

consistent copy A copy of data entity (for example, a logical volume) that contains the contents of the entire data entity from a single instant in time.

console A user interface to a server. That part of a computer used for communication between the operator or user and the computer.

control side The Symmetrix DMX, where Open Replicator runs, and its devices are always referred to as the control side of the copy operation.

copy on first access(COFA)

The Open Replicator copying of not-yet copied data from the remote to the control when an application first attempts to read that data.

copy on first write(COFW)

The Open Replicator copying of not-yet copied data from the control to the remote when an application first attempts a write to the location of that data.

Ddata availability Access to any and all user data by the application.

data integrity The condition that exists as long as accidental or intentional destruction, alteration, or loss of data does not occur.

data migration The one time movement of data from source to target, where the data will subsequently only be accessed at the target.

default A value, attribute, or option that is assumed when no alternative is specified by the user.


300

Glossary

dependent-writeconsistency

A data state where data integrity is guaranteed by dependent-write I/Os embedded in application logic. Database management systems are good examples of applications that utilize the dependent-write consistency strategy. Database management systems must devise protection against abnormal termination in order to successfully recover from one. The most common technique used is to guarantee that a dependent write cannot be issued until a predecessor write has completed. Typically the dependent write is a data or index write while the predecessor write is a write to the log. Because the write to the log must be completed prior to issuing the dependent write, the application thread is synchronous to the log write (that is, it waits for that write to complete prior to continuing). The result of this kind of strategy is a dependent-write consistent database.

dependent-write I/O An I/O that cannot be issued until a related predecessor I/O has completed. Most applications, and in particular database management systems (DBMS), have embedded dependent-write logic to ensure data integrity in the event of a failure in the host or server processor, software, storage subsystem, or if an environmental power failure occurs. See also ”dependent-write consistency.”

device type The general name for a kind of device; for example, standard, BCV, VDEV, or Clone.

director The component in the Symmetrix subsystem that allows the Symmetrix to transfer data between the host channels and disk devices.

directory (1) A type of file containing the names and controlling information for other files or other directories. Directories can contain subdirectories, which can contain subdirectories of their own. (2) A file that contains directory entries. No two directory entries in the same directory can have the same name. (POSIX.1). (3) A file that points to files and to other directories.

disaster recovery The process of restoring a previous copy of the data and applying logs or other necessary processes to that copy to bring it to a known point of consistency.

disk director The component in the Symmetrix subsystem that interfaces between cache and the disk devices.


Glossary

EEnterprise Systems

Connection (ESCON)A set of products and services that provides a dynamically connected environment using optical cables as a transmission medium.

ESCON Enterprise Systems Connection architecture; a set of IBM and vendor products that connect mainframe computers with each other and with attached storage, locally attached workstations, and other devices using optical fiber technology and dynamically modifiable switches called ESCON directors.

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 used to describe a more complex network utilizing hubs, switches, and gateways.

FBA Fixed Block Architecture, disk device data storage format using fixed-size data blocks.

FC See ”Fibre Channel.”

FCP See ”Fibre Channel protocol.”

FCS See ”Fibre Channel standard.”

fiber optic The medium and the technology associated with the transmission of information along a glass or plastic wire or fiber.

Fibre Channel A technology for transmitting data between computer devices at a data rate of up to 4 Gbps. It is especially suited for connecting computer servers to shared storage devices and for interconnecting storage controllers and drives.

Fibre Channelprotocol

The serial SCSI command protocol used on Fibre Channel networks.

Fibre Channelstandard

An ANSI standard for a computer peripheral interface. The I/O interface defines a protocol for communication over a serial interface that configures attached units to a communication fabric. Refer to ANSI X3.230-199x.


302

Glossary

FICON An I/O interface based on the Fibre Channel architecture. In this new interface, the ESCON protocols have been mapped to the FC-4 layer, that is, the Upper Level Protocol layer, of the Fibre Channel Protocol. It is used in the S/390 and z/Series environments.

file system An individual file system on a host. This is the smallest unit that can be monitored and extended. Policy values defined at this level override those that might be defined at higher levels.

front-end director The component in the Symmetrix subsystem that interfaces with host bus adapters (HBAs). It transfers data between the host and Symmetrix cache.

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 per second, 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 a computer and computer-controlled devices. It presents graphical icons, used in conjunction with text, labels or text navigation to fully represent the information and actions available to a user. But instead of offering only text menus, or requiring typed commands, the actions are usually performed through direct manipulation of the graphical elements.

GUI See ”Graphical User Interface (GUI).”

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 the fabric switch. Zoning can be implemented in the following configurations: one to one, one to many, and many to many.


Glossary

HBA See ”host bus adapter.”

highly parallel Refers to multiple systems operating in parallel, each of which can have multiple processors.

host Any system that has at least one Internet address associated with it. A host with multiple network interfaces can have multiple Internet addresses associated with it. This is also referred to as a server.

host bus adapter A Fibre Channel HBA connection that allows a workstation to attach to the SAN network.

host not ready In this state, the volume responds not ready to the host for all read and write operations to that volume.

hot operation Open Replicator mode where the Symmetrix DMX control device can remain online to the host application.See also ”Open Replicator mode where the Symmetrix DMX control device can remain online to the host application..”

hypervolume A user-defined storage device allocated within a Symmetrix physical disk.

hyper-volumeextension

The ability to define more than one logical volume on a single physical disk device making use of its full formatted capacity. These logical volumes are user-selectable in size. The minimum volume size is one cylinder and the maximum size depends on the disk device capacity and the emulation mode selected.

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 an Internet environment.

KKB Kilobyte, 1024 bytes.

Llocal volumes Volumes that reside on an Symmetrix system but do not participate in

SRDF activity.


304

Glossary

logical unit number(LUN)

A volume identifier that is unique among all storage servers. The LUN is synonymous with a physical disk drive or a SCSI device. For disk subsystems such as the IBM Enterprise Stora?e Server, a LUN is a logical disk drive (a unit of storage on the SAN which is available for assignment or unassignment to a host server). The LUNs are provided by the storage devices attached to the SAN.

logical volume A user-defined storage device.

Exclusive OR (XOR) of the accumulated bytes in the data record.

LUN masking Allows or blocks access to the storage devices on the SAN. Intelligent disk subsystems provide this kind of masking.

LUN See ”logical unit number (LUN).”

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 two different physical devices.

mirroring The Symmetrix maintains two identical copies of a designated volume on separate disks. Each volume automatically updates during a write operation. If one disk device fails, Symmetrix automatically uses the other disk device.

mirroring (RAID 1) The highest level of performance and availability for all mission-critical and business-critical applications by maintaining a duplicate copy of a volume on two disk drives.

multipath device A device made visible to a host on more than one I/O path in order to improve both fault tolerance (failover) and performance (load balancing).

multiprocessing The simultaneous execution of two or more computer programs or sequences of instructions. See also ”parallel processing.”


Glossary

multiprocessor (MP) A CPC that can be physically partitioned to form two operating processor complexes.

Nnative device name A path-specific device name provided by the host operating system

that represents a single path to a logical device. See also ”pseudo device name.”

network topology A physical arrangement of nodes and interconnecting communication links in networks based on application requirements and geographical distribution of users.

Oopen system A system whose characteristics comply with standards made

available throughout the industry, and therefore can be connected to other systems that comply with the same standards.

operating system (OS) Software that controls the execution of programs and that may provide services such as resource allocation, scheduling, input/output control, and data management. Although operating systems are predominantly software, partial hardware implementations are possible.

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 of work (batch). See also ”highly parallel.”

password A unique string of characters known to a computer system and to a user, who must specify the character string to gain access to a system and to the information stored within it.

point of consistency A point in time to which data can be restored and recovered or restarted and maintain integrity for all data and applications.

port An endpoint for communication between applications, generally referring to a logical connection. A port provides queues for sending and receiving data. Each port has a port number for identification. When the port number is combined with an Internet address, it is called a socket address.


306

Glossary

port zoning In Fibre Channel environments, the grouping together of multiple ports to form a virtual private storage network. Ports that are members of a group or zone can communicate with each other but are isolated from ports in other zones. See also ”LUN masking” and ”zoning.”

protocol The set of rules governing the operation of functional units of a communication system if communication is to take place. Protocols can determine low-level details of machine-to-machine interfaces, such as the order in which bits from a byte are sent. They can also determine high-level exchanges between application programs, such as file transfer.

pseudo device name A location-independent name that represents a single logical device and the path set leading to it. See also ”native device name.”

pull operation A Open Replicator pull operation copies data to the control device from the remote device.

push operation A Open Replicator push operation copies data from the control device to the remote device.

RRAID Redundant array of inexpensive or independent disks. A method of

configuring multiple disk drives in a storage subsystem for high availabi?ity and high performance.

RAID 0 A protection method where data is striped across several disks to increase performance. Unless combined with RAID 1, does not natively provide protection from data loss due to drive failure. See also ”RAID 10.”

RAID 1 A protection method that provides the highest level of performance and availability for all mission-critical and business-critical applications by maintaining a duplicate copy of a volume on two disk drives. See also ”mirroring.”

RAID 5 A protection method that provides high performance with automatic striping across hypervolumes. Lost hypervolumes are regenerated from remaining members. RAID 5 is configured in (3+1) and (7+1) groups. RAID 5 technology stripes data and distributes parity blocks across all the disk drives in the RAID group.


Glossary

RAID 6 A protection method that supports the ability to rebuild data in the event that two drives within the RAID group fail.

RAID 10 A protection method that combines RAID 1 and RAID 0; used in mainframe environments.

read access Permission to read information.

ready volume A state indicating the volume is available for read/write operations.

recovery The process of rebuilding data after it has been damaged or destroyed, often by using a backup copy of the data or by reapplying transactions recorded in a log.

remediation The process of upgrading elements of the host I/O stack to supported levels. Often required as part of migration in order to meet required levels for the newer target storage array.

remote operations Operation of remote sites from a host system.

remote side The array and devices at the other side of an Open Replicator control side Symmetrix DMX is referred to as the remote side. See also ”control side.”

restore A process that reinstates a prior copy of the data.

resynchronization A track image copy from the primary volume to the secondary volume of only the tracks which have changed since the volume was last in duplex mode.

SSAN See ”storage area network.”

SCSI adapter Card in the Symmetrix subsystem that provides the physical interface between the disk director and the disk devices.

SCSI reservation A method to claim or free ownership of a LUN using the standard SCSI Reserve/Release protocol.

server A program running on a mainframe, workstation, or file server that provides shared services. This is also referred to as a host.


308

Glossary

shared storage Storage within a storage facility that is configured such that multiple homogeneous or divergent hosts can concurrently access the storage. The storage has a uniform appearance to all hosts. The host programs that access the storage must have a common model for the information on a storage device. Programs must be designed to handle the effects of concurrent access.

small computersystem interface

(SCSI)

An ANSI standard for a logical interface to computer peripherals and for a computer peripheral interface. The interface utilizes a SCSI logical protocol over an I/O interface that configures attached targets and initiators in a multi-drop bus topology.

software zoning Is implemented within the Simple Name Server (SNS) running inside the fabric switch. When using software zoning, the members of the zone can be defined with a node WWN, port WWN, or physical port number. Usually the zoning software also allows you to create symbolic names for the zone members and for the zones themselves.

software (1) All or part of the programs, procedures, rules, and associated documentation of a data processing system. (2) A set of programs, procedures, and, possibly, associated documentation concerned with the operation of a data processing system. For example, compilers, library routines, manuals, circuit diagrams. See also ”hardware.”

source device The device which is read from in a data migration. See also ”target device.”

stage The process of writing data from a disk device to cache.

storage administrator A person in the data processing center who is responsible for defining, implementing, and maintaining storage management policies.

storage area network A managed, high-speed network that enables any-to-any interconnection of heterogeneous servers and storage systems.

switch A component with multiple entry and exit points or ports that provide dynamic connection between any two of these points.

switch topology A switch allows multiple concurrent connections between nodes. There can be two types of switches; circuit switches and frame switches. Circuit switches establish a dedicated connection between two nodes.


Glossary

Frame switches route frames between nodes and establish the connection only when needed. A switch can handle all protocols.

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 to communicate. For example, point-to-point, arbitrated loop, and switched fabric are all Fibre Channel topologies.

transaction A unit of work performed by one or more transaction programs, involving a specific set of input data and initiating a specific process or job.

transactionalconsistency

Transactional consistency is a DBMS state where all in-flight transactions are either completed or rolled back.

transmission controlprotocol

A communications protocol used in the Internet and in any network that follows the Internet Engineering Task Force (IETF) standards for Internetwork protocol. TCP provides a reliable host-to-host protocol between hosts in packet-switched communications networks and in interconnected systems of such networks. It uses the Internet Protocol (IP) as the underlying protocol.

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 are mapped into real addresses. The size of virtual storage is limited by the addressing scheme of the computer system and by the amount of auxiliary storage available, not by the actual number of main storage locations. (2) An addressing scheme that allows external disk storage to appear as main storage.

virtualization A technique for hiding the physical characteristics of computing resources from the way in which another function interacts with those resources.


310

Glossary

volume A general term referring to a storage device. In the Symmetrix subsystem, 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 order to enter the ready condition. (2) The condition of a processing unit when all operations are suspended.

WAN Wide area network.

web browser A software application which enables a user to display and interact with text, images, videos, music and other information typically located on a Web page at a website on the World Wide Web or a local area network. Web browsers communicate with Web servers primarily using HTTP (hypertext transfer protocol) to submit information to Web servers as well as fetch Web pages from them.

world wide name A unique number assigned to Fibre Channel devices (including hosts and adapter ports). It is analogous to a MAC address on a network card.

WWN See ”world wide name.”

Zzoning In Fibre Channel environments, zoning allows for finer segmentation

of the switched fabric. Zoning can be used to instigate a barrier between different environments. Ports that are members of a zone can communicate with each other but are isolated from ports in other zones. Zoning can be implemented in two ways: hardware zoning and software zoning. See also ”hardware zoning” and “software zoning.”


Index

AAuto-provisioning Groups 161

CCLARiiON

brief description 35discover 71display information about 71remote for cold push example 70remote for hot pull example 118

cleanup stepscold push example 90definition 64flowchart 64flowchart for PPME 211for hot pull 119for PPME 207

clustered hostsspecial considerations 68

colddefinition 23

cold pulldefinition 53replace with hot pull 53

cold pushcleanup example 89definition 50migration and cleanup steps flowchart 91migration example 89setup example 69versus hot push 51

Connectrixbrief description 38

Connectrix Managerbrief description 38zoning verification screen 77, 133, 156, 249

control sidedefinition 23

ControlCentersee EMC Ionix ControlCenter

createand SCSI reservations 58

cutoverdefinition 22

Ddata migration

definition 22selection model 26TechBook series 17

device maskingSymmetrix example 126Symmetrix SMC example 158

diskpartextend disk partition 142rescan 260, 266

donor updateexample 135explanation 52off (disable) 145, 193

EEMC Ionix ControlCenter

brief description 42Enginuity

definition 32


312

Index

FFederated Live Migration

benefits 230description 230Device external identity 233introduction 24nondisruptive migration 231pair file example 252

FLMsee Federated Live Migration

front-end directorsdefined 32

Hhot

definition 23hot pull

definition 51from CLARiiON example 117from Symmetrix example 147setup, migration, and cleanup flowchart 120

hot pushdefinition 48differences from cold push 110versus cold push 51

IICDA

see Integrated Cached Disk ArrayIntegrated Cached Disk Array

definition 32Invista

brief description 38

LLUN masking

for Symmetrix see device masking 158, 250verify with Remote Report 181verify with symsan -sanluns 82

Mmigration

project steps 25migration steps

cold push example 90flowchart 60flowchart for FLM 240flowchart for PPME 206for FLM 239for PPME 205hot pull example 118

MirrorViewbrief description 36

mount 93, 114multipathing 24

PowerPath 40

Nnavicli

storagegroup operations 78, 113, 125, 135, 137

Navispherebrief description 36connectivity status example 76invoke connectivity status 75Storage Processor WWNs 76

Ooffline

definition 23online

definition 23Open Replicator

control interface alternatives 67data mobility 50-force_copy 56migration operation flow 55pair file example 79, 130Symmetrix VMAX and Symmetrix DMX

arrays 33TimeFinder interaction 95, 106tuning introduction 63

Ppowerformat 114, 203PowerPath

family 40multipathing 40

PowerPath Migration Enabler


Index

benefits 196brief description 40description 196introduction 24migration example 214migration states 199nondisruptive migration 197role in migration operations 68when to use 26

PPMEsee PowerPath Migration Enabler

precopydefinition 49

pulldefinition 23

pushdefinition 23

Rremote device

read-only access 23remote side

definition 23Replication Manager

brief description 40

SSAN Copy

brief description 36incremental use case 36

SAN Managerbrief description 38

SCSI reservationscluster control 58

setup stepscold push example 69definition 55FLM example 238flowchart 56flowchart for FLM 239flowchart for PPME 205hot pull example 118PPME example 204verify completion example 80verify failure example 131

SIU

see Symmetrix Integration UtilitiesSLV

see Symmetrix logical volumeSMC

see Symmetrix Management ConsoleSnapView

brief description 36Solutions Enabler

brief description 41role in migration operations 67

SRDFsee Symmetrix Remote Data Facility

Symmetrixarchitecture 32logical volumes 33remote for hot pull example 147

Symmetrix Integration Utilitiesdefinition 136symntctl command 136

Symmetrix logical volumedefinition 33

Symmetrix Management Consolebrief description 41hot pull example 148Remote Report 86role in migration operations 67

Symmetrix Remote Data Facility 34symntctl

log 288mount 141, 187umount 136, 137, 182update 139, 187

TTimeFinder

initial establish 95migration role 34Open Replicator interaction 95, 106split 96

TimeFinder familybrief description 34

Uumount 108Unisphere 37


314

Index

VVxVM

vxdctl 114vxdg 108, 114vxdisk 108, 114, 115vxprint 93, 115, 116vxresize 116vxvol 114

Zzero space reclamation

definition 52zoning

verify with Remote Report 181verify with symmask list logins 83verify with symsan -sanports 80


Documents

Data Migration: EMC Open Replicator for Symmetrix ... · PDF fileData Migration: EMC Open Replicator for Symmetrix, PowerPath Migration Enabler, ... Symmetrix VMAX and Symmetrix DMX