pg omlm data migration pscusprdsvc

EEMMCC CCoorrppoorraattiioonn TTeecchhnnoollooggyy SSoolluuttiioonnss KKiitt

EMC Data Migration Solution for Open Migrator/LM Practitioner’s Guide

Date: March 3, 2011

EMC Corporation 176 South Street

Hopkinton, MA 01748

Q111

EMC Corporation, Technology Solutions T.S. Service Kit: Practitioner’s Guide

EMC Data Migration Solution for Open Migrator/LM

03/03/11



03/03/11

Table of Contents EMC Data Migration with Open Migrator/LM............................................................. 7

Reference Documentation and Resources ............................................................. 15

Perform GRAB Collection using the Data Collection Appliance for EMC Host Validation for Data Migration Activity ............................................................................... 19

Validate Customer ESX Server is Ready for Data Collection Appliance Installation Work Plan .................................................................................................................................................. 19

Install the Data Collection Appliance on the Virtual Machine One (VM1) on ESX Host Work Plan........................................................................................................................................ 20

Set Up the Data Collection Appliance Virtual Machine 1 (VM1) Work Plan ......................... 21

Perform Data Collection Appliance Post-Installation Steps Work Plan ................................. 22

Set Up the Data Collection Appliance on Virtual Machine 2 (VM2) Work Plan.................... 23

Configure the Data Collection Appliance Virtual Machines Work Plan ................................. 24

Performing Grab Script Work on the Data Collection Appliance Work Plan ........................ 25

Create an IP Discovery Policy for EMC GRAB Hosts for Data Collection Appliance Work Plan .................................................................................................................................................. 25

Create Groups for Host Discovery by Data Collection Appliance Work Plan....................... 26

Initiate Detail Discovery Policy on the Data Collection Appliance Work Plan ...................... 27

Processing the Data Collection Appliance Discovery Results (collecting the GRAB Output Files) Work Plan............................................................................................................................. 28

Remove Data Collection Appliance from the ESX Server Work Plan ................................... 28

Discover and Correlate the Environment for Data Migrations Activity.......................... 29

Review Customer Provided Data Collection Information Work Plan ..................................... 29

Manually Collect Host and Storage Data Work Plan................................................................ 29

Collect Host Information (GRABs-Reports) Work Plan............................................................ 29

Collect Switch Configuration Data Work Plan ........................................................................... 30

Collect CLARiiON Storage Data Work Plan .............................................................................. 30

Collect Symmetrix Storage Data Work Plan .............................................................................. 30

Collect Non-EMC Storage Data Work Plan ............................................................................... 30

Process GRABs through HEAT using HEAT-IT Work Plan .................................................... 31

Process Switch and Director Data through SWAT Work Plan................................................ 31

Process CLARiiON-related HEAT-Swat HTML through SAN Summary Work Plan ........... 31

Process Symmetrix-related HEAT/SWAT HTML through EMP/SAN Summary for Data Migrations Work Plan .................................................................................................................... 31

Process Non-EMC Storage Array Related HEAT/SWAT HTML through SAN Summary Work Plan........................................................................................................................................ 32

Perform Environment Analysis and Validation for Data Migration Activity .................. 33



03/03/11

Perform e-Lab Checks for Current STD Hosts and Virtual Machines Work Plan ................ 33

Perform e-Lab Checks for Current Switches Work Plan ......................................................... 33

Review Current Symmetrix-related EMP/SAN Summary Reports Work Plan ..................... 33

Review Current CLARiiON-related EMP/SAN Summary Reports Work Plan ...................... 34

Review the Current Analysis Findings with the Customer Work Plan ................................... 34

Plan and Build Out Proposed Environment for Data Migration Activity........................ 35

Build Out Switch/SAN View in a Symmetrix Environment Work Plan ................................... 35

Build Out Switch/SAN View in a CLARiiON Environment Work Plan.................................... 35

Build-out the Symmetrix Storage View of the Environment Work Plan ................................. 35

Build-out the CLARiiON Storage View of the Environment Work Plan ................................. 36

Perform Host-based Migration Design and Documentation Activity ............................. 37

Define and Document Data Migration Procedures Work Plan ............................................... 37

Design and Document Open Migrator LM Migration Work Plan ............................................ 39

Design and Document Open Migrator LM Swingframe Migration Work Plan ...................... 49

Provide EMC On-site Support Only for Customer-driven Host-based Migrations Activity .............................................................................................................. 60

Provide On-site Support Only During Customer-driven Open Migrator LM Migrations Work Plan .................................................................................................................................................. 60

Provide On-site Support Only During Customer-driven Open Migrator LM Swingframe Migrations Work Plan .................................................................................................................... 60

Perform Additional Collection and Validation Activity.................................................... 61

Review Additional Customer-provided Data Collection Information Work Plan................... 61

Manually Collect Additional Host and Storage Data Work Plan ............................................. 61

Collect Additional Host Information (GRABs-Reports) Work Plan ......................................... 61

Collect Additional Switch Configuration Data Work Plan......................................................... 62

Collect Additional CLARiiON Storage Data Work Plan............................................................ 62

Collect Additional Symmetrix Storage Data Work Plan ........................................................... 62

Collect Additional Non-EMC Storage Data Work Plan............................................................. 63

Process Additional GRABs through HEAT using HEAT-IT Work Plan.................................. 63

Process Additional Switch and Director Data through SWAT Work Plan ............................. 63

Process Additional CLARiiON-related HEAT/SWAT HTML through SAN Summary for Data Migrations Work Plan........................................................................................................... 63

Process Additional Symmetrix-related HEAT/SWAT HTML through EMP/SAN Summary for Data Migrations Work Plan ..................................................................................................... 64

Process Additional Non-EMC Storage Array Related HEAT/SWAT HTML through SAN Summary Work Plan ..................................................................................................................... 64



03/03/11

Perform Pre-migration Planning for Host-based Migrations Activity ............................ 65

Build Data Migration Cadence (Step-by-Step) Procedures for Open Migrator LM Migrations Work Plan .................................................................................................................... 65

Build Data Migration Cadence (Step-by-Step) Procedures for Open Migrator LM Swingframe Migrations Work Plan .............................................................................................. 65

Conduct Pre-Implementation Checkpoint for Open Migrator LM Migrations Work Plan .... 66

Conduct Pre-implementation Checkpoint for Open Migrator LM Swingframe Migrations Work Plan........................................................................................................................................ 66

Perform Test Migrations on Hosts/Clusters Prior to Migration Cutover Date Work Plan ... 66

Perform Event Window Host-based Migration Planning Activity................................... 67

Perform Pre-migration Review of Source Hosts (Migration Hosts) Work Plan .................... 67

Perform Pre-migration Review of Target Hosts (New Hosts) Work Plan.............................. 67

Perform Switch Configuration Work -- Fabrics, Zoning, Zonesets -- for Migration Work Plan .................................................................................................................................................. 67

Perform Symmetrix Device Allocation and Host Discovery for Migration Work Plan .......... 68

Perform CLARiiON LUN Allocation and Host Discovery for Migration Work Plan............... 68

Set up Open Migrator LM Migrations Work Plan ...................................................................... 68

Set up Open Migrator LM Swingframe Migrations Work Plan ................................................ 69

Execute Host-based Migration Cutover, Testing, and Cleanup Activity........................ 70

Execute Open Migrator LM Migration, Testing, and Cutover Work Plan .............................. 70

Execute Open Migrator LM Swingframe Migration, Testing, and Cutover Work Plan ........ 72

Execute Migration Cutover, Testing, and Cleanup (User-determined Events) Activity 76

Perform a PM Event-window Implementation for Data Migration Work Plan ....................... 76

Perform an SA Event-window Implementation for Data Migration Work Plan ..................... 76

Perform an IS Event-window Implementation for Data Migration Work Plan ....................... 77

Perform an MSS Event-window Implementation for Data Migration Work Plan .................. 77

De-install Hardware Activity............................................................................................... 78

Power System Down, Remove Cables, and De-install Work Plan ........................................ 78

Crate and Ship Equipment Activity ................................................................................... 79

Crate Equipment Work Plan......................................................................................................... 79

Ship Equipment Work Plan .......................................................................................................... 79

Finalize Project Deliverables by Solutions Architect and Implementation Specialist Activity ................................................................................................................................. 80

Complete Final Configuration Guide and Test Plan Work Plan ............................................. 80

Deliver Functional Overview Work Plan ..................................................................................... 80 Appendix A: Glossary of Terms – Essential Terms and Concepts....................... 81



03/03/11

Appendix B: Applications with Open Handles ....................................................... 82

List of Figures Figure 1. ........................................................... 8 EMC Data Migration FrameworkFigure 2. .................................................... 9 Data Migration Planning and DesignFigure 3. ..................................... 10 Data Migration Implementation and TestingFigure 4. .......................................... 13 OM/LM Data Migration Sample TopologyFigure 5. .................................................................. 24 WinSCP directory location

List of Tables Table 1. ................................................ 39 Open Migrator/LM Performance ImpactTable 2.

.................................................................................................... 40 States of Open Migrator/LM Software During a Data Migration

ProcessTable 3. ............................................................ 40 Capabilities and ConsiderationsTable 4. .................................................................. 42 Restrictions and LimitationsTable 5. .......................................................................................... 43 Best PracticesTable 6. ........................................................................................ 46 Common RisksTable 7. ................................................ 49 Open Migrator/LM Performance ImpactTable 8.

.................................................................................................... 50 States of Open Migrator/LM Software During a Data Migration

ProcessTable 9. ............................................................ 50 Capabilities and ConsiderationsTable 10. ............................................................... 52 Restrictions and LimitationsTable 11. ...................................................................................... 54 Best PracticesTable 12. ..................................................................................... 56 Common RisksTable 13. ..................................................................... 72 Example CLI CommandsTable 14. ..................................................................... 74 Example CLI CommandsTable 15. ............................................................................... 81 Glossary of Terms


EMC Data Migration with Open Migrator/LM

Description The focus of the EMC® Data Migration with Open Migrator/LM offering is to leverage storage consolidation, high availability, and server consolidation in coordination with data storage migration opportunities.

The service ranges from very small efforts, such as replicating production data into a data warehouse environment, to very large efforts such as a major database migration, or migrating data center operations to a new facility. Whether large or small, migrations can be accomplished with EMC Technology Solutions using this document and associated materials.

Overview

Proper planning and design are critical to the success of any data migration project. Customers have experienced data migration problems with:

Incomplete design and planning for data migrations, resulting in poor execution.

Lack of project management and loss of data migration project control.

No tools standardization, templates, or methodologies to ensure successful data migrations.

Cumbersome and lengthy data migration process if done manually.

Prolonged service outages causing strategic business operations to stop.

Inexperienced implementers in IS organizations because storage migration occurs infrequently; storage migration expertise is gained only through time-consuming education, and ongoing experience in many different storage environments.

The high risk of errors or problems in performing data migration causing catastrophic business impact.

Complexity issues causing storage migration work to be avoided or delayed, impacting strategic organizational operational functions and hardware/systems implementation schedules.

The EMC data migration solutions were created to address these issues. EMC Technology Solutions provides significant value by mitigating major business, technical, and operational risks associated with performing data migrations. EMC has always strived to meet and exceed customers’ expectations, and providing an excellent migration offering continues along those lines. The EMC Data Migration with Open Migrator/LM service helps our consultants prepare, plan, design, and implement critical data migration solutions.

EMC Data Migration with Open Migrator/LM uses a suite of migration planning tools to provide end-to-end data migration implementation. The tools used in the delivery of the service include:

Host Environment Analysis Tool (HEAT)

VMware HEAT (VMHEAT)

EMCGrab utilities

EMC Migration Planning (EMP)

Data Collection Appliance (DCA)

Data Migration Framework


03/03/11


The service delivery follows the EMC Data Migration framework shown below.

Figure 1. EMC Data Migration Framework

Discovery and Correlation

Using automated tools to gather information about the customer’s environment to be migrated, EMC engagement personnel build a data migration plan for the assets in scope of migration. The plan identifies all the actionable items consistent with the customer’s business, operational, and technical requirements.

Planning

After a thorough analysis of the customer’s current environment, EMC designs a solution including step-by-step migration plan. The plan clarifies the sequence of events and the timetable for migrating data.

Remediation and Validation

During the environment analysis and validation of customer’s environment, EMC addresses interoperability gaps and the outcomes are validated to ensure the correct assets are migrated and interoperability and performance is assured.

Data Movement and Auditing

Data migration commences as per the defined migration plan and schedule. EMC conducts procedural testing and validates the configuration.

Documentation and Acceptance

EMC reviews the data migration results, delivers the final documentation, and completes any necessary cleanup, and equipment decommission before considering the project is complete.


03/03/11


Figure 2 provides a simplified diagram of a data migration planning phase.

Figure 2. Data Migration Planning and Design


03/03/11


Figure 3 is a simplified diagram of a data migration implementation phase.

Figure 3. Data Migration Implementation and Testing


03/03/11


During implementation, EMC Technology Solutions works closely with the customer’s staff and other EMC account team members to ensure minimal disruption to customer computing operations. The disruption takes place within the customer‘s defined windows. Depending on the criticality of current operations, maintenance or cutover windows may be small, and therefore require a lengthier deployment. Ensure that backup plans are prepared in the event that we must back-out of an implementation.

This phase should be a matter of following and managing the plan developed during the previous phase. Of course, planning can only go so far to mitigate risk and ensure a smooth project. Surprises and changes are likely. Some general best practices to follow during implementation include:

Ensure that support is available and that back-out plans are as well understood as the data migration plans.

Ensure that the customer has completed the required backups.

Conduct a pilot migration or do some advanced testing whenever possible. A small test before a scheduled event can be extremely valuable.

Double check what you were told; everyone makes mistakes. It is easier to deal with a server that is the wrong revision before you start, than after it creates a problem.

Pay close attention to throughput rates early in the project. If the migration timing is based on certain throughput estimates, and you see a significant difference early in the project, there may still be time to adjust schedules, performance, or methodology before the project goes red.

Watch the scope. If the customer decides, for example, to add a volume or share to the migration mid-stream, only agree to the extra work after performing an impact analysis and discussing it with the Project Manager and the Solution Architect. It may be perfectly fine to go ahead, but it does introduce risk.

Follow the Test Plan and document everything.

The highest risk in moving production data online is a data integrity problem that EMC or the customer introduces, without being able to determine how it was introduced.

If we follow and document our Test Plan, and the customer follows his Test Plan, this risk can usually be mitigated.

It is critical to keep the discipline of having the customer sign-off on each migrated and tested data source before moving to the next data source.

Escalate issues promptly. It is easy to wait to call for help, thinking you should be able to figure it out on your own, but if you sense things not within plan, contact your support system to ensure that you get help when you need it, especially if this is the first time you are performing a data migration.

OM/LM for Windows Overview

OM/LM operates at the filter-driver level to manage and move data from a source to a target volume with minimal disruption to the server or applications. OM/LM requires at least one and possibly two restarts of the server: one potential disruption to install the application, and a second definite disruption for file resizing and drive letter adjustment.

OM/LM allows a maximum of ten concurrent migrations while allowing full read-and-write access to the source volume. It does this by performing a byte-by-byte copy of the source volume to the target volume in a granularity based on the size of a track on the source volume. During and after migration, OM/LM captures all I/O to the source volume and writes it to both the source and the target volumes. OM/LM synchronizes the source


03/03/11


volume and target volume until the next reboot by filtering I/O requests to the volume manager (FTDisk or LDM).

After the source and target volumes are synchronized, you can choose to verify the migration operation. To verify, the software checks to make sure that the source and target volumes are identical at the physical level.

After you have completed data movement for all volumes, a reboot is required for standalone and 2003 MSCS migrations to complete them, while clicking “complete migration” is required for every 2008 MSCS migration.

Note: Users must close all local service/applications that access the source volume before completing a 2008 MSCS migration.

When the migration is completed, the software does the following:

Moves the source's drive letter, and all other mount points, to the target.

Expands the file system to match the size of the target, if necessary.

You can decide when to schedule the brief outage or “complete migration” operations that are required.

OM/LM uses a client/server model where the server is installed on the system hosting the volumes to be migrated. The source and target volumes must be on the same system. The client can be located anywhere in the network on any system in the same domain or in a trusted domain. Volumes are not migrated across the network.

Note: The information above is an excerpt from the EMC Open Migrator/LM for Windows Product Guide. Refer to the latest version of the guide for updates.

OM/LM for UNIX/Linux Overview

OM/LM is implemented as a host-based kernel driver and CLI, and is used to migrate data from source to target volumes with only a single disruption to the server or applications. Because the OM/LM device driver is dynamically loaded and unloaded there is no required system reboot.

OM/LM provides mirroring and background copy functions between two storage arrays that are used to synchronize data images on one or more source and target volumes, LUNs, or LUN partitions. Data can be migrated between source and target volumes of any block device type. During the migration, the source volume can remain available for input/output (I/O) to production host applications. However, the target volume must be set to read/write disabled.

The target volume must also be set as “not ready” to prevent any additional hosts from accessing the volume. OM/LM operates in sessions to manage multiple volume pairs uniformly as a group.

Control operations are performed using the stormigrate CLI command. Source and target pairs can be added to a created session or a device file option (-file) can be used to define device pairs.

Data can be compared between source and target volumes in an activated session. When comparing, OM/LM checks if the source and target volumes are identical. Once the data has been migrated, mirroring continues to keep the source and target volumes synchronized until the session is deactivated. When volumes have been successfully migrated and the session has been deactivated, OM/LM must be uninstalled from the kernel I/O subsystem and the production host.


03/03/11


OM/LM allows for multiple concurrent migrations, while allowing full read and write access to the source volumes. Data synchronization is maintained by capturing and mirroring all I/O to the source volumes in coordination with background copy process I/O.

Due to the complexity of a data storage environment, which might include various applications for file systems, volume managers, and multi-path capability, it is necessary to understand the I/O subsystem (I/O stack layers) within the UNIX operating system (OS) kernel. For best results, source volumes for data migration must always be accessed at the level in the I/O stack that is closest to the application. This avoids certain common problems experienced with LUN level migration underneath logical volumes.

OM/LM is installed on the production host and is designed to operate as a stand alone product. Any volumes visible the production host can be compared and migrated. The source and target volumes can be on the same array or separate arrays.

Note: The information above is an excerpt from the EMC Open Migrator/LM for UNIX/Linux CLI Product Guide. Refer to the latest version of the guide for updates.

Operational Environments

Figure 4 shows two operational environments moving the customer’s data from direct-attached or SAN-attached third-party storage to EMC storage arrays using OM/LM.

Figure 4. OM/LM Data Migration Sample Topology

EMC Data Migration Solution for Open Migrator/LM uses a suite of migration planning tools to provide end-to-end data migration implementation. The tools used in the delivery of the service include:

Host Environment Analysis Tool (HEAT)

VMware HEAT (VMHEAT)


03/03/11


EMC GRAB utilities

EMC Migration Planning (EMP)

Skills Requirements This document is for internal EMC personnel and ASN partner use only. This document

assumes that the reader is an experienced practitioner in data migration. It does not attempt to provide introductory materials for the basic data migration techniques, nor does it provide basic delivery methodology information. This document focuses on Solutions Architect (SA) and Implementation Specialist (IS) audiences with the following skills:

Open Migrator/LM

Microsoft Windows disk management

SAN configuration (EMC, McData, Brocade, CISCO, and others)

Native UNIX disk management for Solaris, HP, and IBM hardware platforms

Native Linux disk management

VERITAS Volume Manager

PowerPath®

EMC Migration Planning (EMP) tool

Environment discovery tools (HEAT, GRAB, and SAN Summary)

Data Collection Appliance (Tool)

You must ensure that your host is supported and has the correct revision/patch levels installed. Refer to the latest release notes for the current requirements for the OS you are working with. There are no other prerequisites for the installation of OM/LM.

Prerequisites and Assumptions

Licensing There is no licensing for the product. Refer to the latest release notes for details.

Note: Remember that the EMC OM/LM software can be used as a tool for a Data Migration service for a customer without requiring the customer to purchase the tool. The software must be removed entirely after the migration is complete.


03/03/11


Reference Documentation and Resources

Links listed in this topic are functional as of this document’s publication date. Over time, the location of reference material may change. A navigation description is included to assist in those cases. If you are having difficulty locating referenced material, email TS Services Material Support at [email protected].

About the Links

Powerlink Refer to the following documents for Solution/Product/Technology information:

Refer to Powerlink® (http://powerlink.emc.com) for EMC documents.

EMC Data Migration Assessment and Planning service

PATH: Home > Services > TS Service Kits and Service Offering Index > Networked Storage Offerings > Data Migration > Data Migration Assessment and Planning

Open Migrator/LM Product Documentation

PATH: Home > Resources/Tools > CS Support > Document Library > Software E-P > Open Migrator/LM

TechBooks and Whitepapers

PATH: Home > Support > Technical Documentation and Advisories > TechBooks Solutions Guides

PATH: Home > Support > Technical Documentation and Advisories > Whitepapers

Other Vendor Documentation

Refer to the vendor websites for specific product documentation, such as disk management in Solaris/HP-UX/AIX/Linux and Microsoft Windows.

EMC Migration Planning Installation and Getting Started Guide

eRoom: EMC TS Applied Technologies > Applied Technology Practice Areas > GS Tools > Applied Technology Practice Tools > Data Migration > EMC Total Migrator (ETM).Other Vendor Documentation

Training Refer to Education Services for training available related to Open Migrator/LM and data

migration in general:

Open Migrator for Windows Overview - IMPACT

Open Migrator/LM for Unix/Linux – IMPACT

Open Migrator/LM v3.9 Train-the-Trainer – Recorded Centra

Data Migration Introduction – IMPACT

Data Migration Solutions Design Concepts V2 – IMPACT

EMC Total Migrator (ETM) for Symmetrix® – IMPACT


03/03/11

http://powerlink.emc.com/

http://powerlink.emc.com/km/appmanager/km/secureDesktop?internalId=0b014066800243b7

http://powerlink.emc.com/km/appmanager/km/secureDesktop?internalId=0b01406680024faa

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/H4380-choosing-data-migtn-sol-emc-symmetrix-sol-gde.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tTZWFyY2hSZXN1bHRzRXZlbnQsZG9jdW1lbnRJZD0wOTAxNDA2NjgwMzRjODViLGRhdGFTb3VyY2U9RENUTV9lbl9V

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/Technical_Documentation/H4380-choosing-data-migtn-sol-emc-symmetrix-sol-gde.pdf?mtcs=ZXZlbnRUeXBlPUttQ2xpY2tTZWFyY2hSZXN1bHRzRXZlbnQsZG9jdW1lbnRJZD0wOTAxNDA2NjgwMzRjODViLGRhdGFTb3VyY2U9RENUTV9lbl9V

http://powerlink.emc.com/km/appmanager/km/secureDesktop?internalId=0b01406680177d96

http://ctseroom02.corp.emc.com/eRoom/tsfuncprac/TSTools/0_51a9c



Software

Download Refer to the following location to download Open Migrator/LM software:

Open Migrator/LM for Windows

PATH: Home > Support > Software Downloads and Licensing > Downloads J-O > Open Migrator/LM for Windows

Open Migrator/LM for UNIX

PATH: Home > Support > Software Downloads and Licensing > Downloads J-O > Open Migrator/LM for UNIX

Open Migrator/LM for Linux

PATH: Home > Support > Software Downloads and Licensing > Downloads J-O > Open Migrator/LM for Linux

Refer to the licensing section of this document for more details on using OM/LM as a tool for a data migration engagement without customer purchase of it.

Tools Tools to assist with proper design of storage allocation for Microsoft applications are listed below:

Refer to the following location to download tools to assist in migration planning:

EMC Migration Planning (EMP) tool

eRoom: EMC TS Applied Technologies > Applied Technology Practice Areas > GS Tools > Applied Technology Practice Tools > Data Migration > EMC Total Migrator (ETM)

Host Environment Analysis tool (HEAT)

PATH: Home > Support > Product and Diagnostic Tools > Environment Analysis Tools > Host Environment Analysis Tool (HEAT)

VMware Host Environment Analysis Tool (VMHEAT)

Path: Home > Support > Product and Diagnostic Tools > Environment Analysis Tools > VMware Host Environment Analysis Tool (VMHEAT)

EMCGrab

PATH: Home > Support > Product and Diagnostic Tools > Grab Utilities


03/03/11

http://powerlink.emc.com/km/appmanager/km/secureDesktop?internalId=0b014066800863ef

http://powerlink.emc.com/km/appmanager/km/secureDesktop?internalId=0b014066800bc83d

http://powerlink.emc.com/km/appmanager/km/secureDesktop?internalId=0b014066801b4aa2



http://powerlink.emc.com/km/appmanager/km/secureDesktop?internalId=0b014066803007f0

http://powerlink.emc.com/km/appmanager/km/secureDesktop?internalId=0b014066803fca3a

http://powerlink.emc.com/km/appmanager/km/secureDesktop?internalId=0b014066800251e6



03/03/11

Data Collection Appliance Documentation

PATH: Support > Product and Diagnostic Tools > Data Collection Appliance (Data Collection Appliance)

1.2 Documentation

EMC Ionix™ Data Collection Appliance v1.2 Release Notes

EMC Ionix Data Collection Appliance v1.2 Host Validation for Data Migration Virtual Machine Deployment Guide

Note: More documentation will be available at this location on Powerlink after release of v1.2

1.1 Documentation

Ionix Data Collection Appliance 1.1 Target Host Requirements Guide

Ionix Data Collection Appliance 1.1 Release Notes

Ionix Data Collection Appliance Downgrading Windows Vista License to Windows XP license and Activating Windows XP License

Data Collection Appliance 1.0 to 1.1 Upgrade Kit

Ionix Data Collection Appliance 1.1 User Notes

Ionix Data Collection Appliance 1.1 Technical Notes

Ionix Host Validation for Data Migration 1.1 Distributed Deployment Guide

Ionix Host Validation for Data Migration 1.1 Pre Installation Checklist

Ionix Host Validation for Data Migration 1.1 Stand-alone Deployment Guide

Ionix Host Validation for Data Migration 1.1 Data Collection Appliance Calculator

1.0 Documentation

pliance 1.0 Release Notes

quirements Guide

tes

ted Deployment Guide

uide

lator

Data Collection Ap

Data Collection Appliance 1.0 Target Host Re

Data Collection Appliance 1.0 User Notes

Data Collection Appliance 1.0 Technical No

Host Validation for Data Migration 1.0 Distribu

Host Validation for Data Migration 1.0 Pre Installation Checklist

Host Validation for Data Migration 1.0 Stand-alone Deployment G

Host Validation for Data Migration 1.0 Data Collection Appliance Calcu

Additional Documents which are Required for Data Collection Appliance

GRAB Script Legal Notice is located to the Grab zip file for UNIX at: ftp://ftp.emc.com/pub/emcgrab/Unix/

GRAB Script Legal Notice is located to the Grab zip file for Windows at: ftp://ftp.emc.com/pub/emcgrab/Windows/

SVC Qualifier located at http://gig.corp.emc.com

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


ftp://ftp.emc.com/pub/emcgrab/Windows/



03/03/11

Data Collection Appliance Tool used for Host Validation for Data Migrations.

Refer to the document entitled EMC Host Validation for Data Migrations Contingency Ordering Data Migrations Deployment Guide for Distributed Data Collection Appliance

Global Services must order the Data Collection Appliance software DVD through CS Logistics. You can find ordering process details in a form called the SDMS / SRDFf® / Data Collection Appliance MIGRATION PRESITE FORM at: http://www.cs.isus.emc.com/csweb2/sdm/sdms.htm

Note: If a hardware version of the Data Collection Appliance is required, you can obtain it by using the same form as mentioned above. The server must be installed, utilized, then removed, and returned. Please note that you must use the Virtual Machine version of the Data Collection Appliance in order to have full features and functionality of the tool.

PATH: one.emc.com>clearspace>docs>DOC-16492

http://www.cs.isus.emc.com/csweb2/sdm/sdms.htm


http://one.emc.com/clearspace/docs/DOC-16492


Perform GRAB Collection using the Data Collection Appliance for EMC Host Validation for Data Migration Activity

Role Implementation Specialist

Description Use the Data Collection Application to deploy EMC GRAB and retrieve EMC GRABsIT,

which is used for analysis in the data migration services.

Validate Customer ESX Server is Ready for Data Collection Appliance Installation Work Plan


Description Validate that the customer's ESX sever supports installation of the Data Collection

Appliance tool and collector.

Task List Verify ESX Server has MS Windows 2008 Server VM Created

Verify ESX Server has MS Windows 2008 Server VM Created Task

The customer must provide an ESX server with two virtual machines. The requirements are:

Bare-metal virtual machine for Data Collection Appliance core software and Linux operating system

4 GB memory

80 GB hard drive

4 vCPUs

4 NIC ports

Fully-configured Windows Server 2008 R2 virtual appliance for Data Collection Appliance windows probe application

2 GB memory

20 GB hard drive

1 vCPU

1 NIC port

Note: The bare-metal VM will be created by the OVF file when deployed from within vCenter.

The software requirements are:

VMware ESX server version 3.5 or later

VMware vSphere Client must be installed on the machine from where the Data Collection Appliance installation is performed

Microsoft Internet Explorer version 6.0 or higher with Flash


03/03/11


Note: Ensure that the browser accepts cookies and pop-up blockers are disabled.

Note: Data Collection Appliance does not require a dedicated ESX server for two VMs. You can also have other VMs installed on the server.

See the latest EMC Data Collection Appliance Host Validation for Data Migration Virtual Machine Deployment Guide for the current requirement information – located on Powerlink: Support > Product and Diagnostic Tools > Data Collection Appliance (Data Collection Appliance) > 1.2

Install the Data Collection Appliance on the Virtual Machine One (VM1) on ESX Host Work Plan


Description Install the Data Collection Appliance tool on the first Virtual Machine on the customer's

ESX Server.

Task List Install the Data Collection Appliance on VM1 on ESX Host

Install the Data Collection Appliance on VM1 on ESX Host Task

The Data Collection Appliance used with EMC Host Validation for Data Migrations is a tool that can be used as part of an EMC Migration Service engagement to reduce the time and cost of a migration. EMC customers typically spend their time and resources deploying EMC grabs in their environments. Using the Data Collection Appliance tool minimizes the effort required by our customers by shortening the time to deploy the Grab Utility and ultimately reducing the duration of the data gathering phase of the data migration.

EMC Global Services installs and configures the standalone Data Collection Appliance on two customer Virtual Machines on an ESX server—one VM for the Data Collection Appliance itself and another Windows Server 2008 for the Collector. The Data Collection Appliance discovers the customer’s SAN-attached hosts, pushes out and runs EMC Grab, and then retrieves the data to be analyzed as a part of the data migration data gathering process. At the end of the data migration, the Data Collection Appliance and Collector are removed from the customer’s ESX servers.

When using the Data Collection Appliance for a Data Migration, Global Services must order the Data Collection Appliance software DVD through CS Logistics. You can find ordering process details in a form called the SDMS / SRDFf® / Data Collection Appliance MIGRATION PRESITE FORM at: http://www.cs.isus.emc.com/csweb2/sdm/sdms.htm.

Note: If a hardware version of the Data Collection Appliance is required, you can obtain it by using the same form as mentioned above. The server must be installed, utilized, then removed, and returned. Please note that you must use the Virtual Machine version of the Data Collection Appliance in order to have full features and functionality of the tool.

The OVF file will create the first Virtual Machine as part of the upload and deployment within VMware vSphere. This VM does not need to be created by the customer.


03/03/11





The iso file needs to be burned onto a DVD or opened in WinRAR to get to the files (.ovf and .vmdk files).

There is no software download for the Virtual Machine version of the Data Collection Appliance. A DVD will be sent after the SDMS / SRDF / Data Collection Appliance MIGRATION PRESITE FORM is completed and submitted. It is available at: http://www.cs.isus.emc.com/csweb2/sdm/sdms.htm

The standalone Data Collection Appliance requires two Virtual Machines running on an ESX server in the customer environment. It is only supported for VMware environments. The two VMs required:

Bare-metal virtual machine for Data Collection Appliance core software and Linux operating system (VM, OS, and appliance is a part of the installer.)

Windows Server 2008 R2 virtual machine for Data Collection Appliance Collector (VM must be provided by customer with the Windows OS, licensed by the customer.)

See the latest EMC Data Collection Appliance Host Validation for Data Migration Virtual Machine Deployment Guide for the current information – located on Powerlink: Support > Product and Diagnostic Tools > Data Collection Appliance (Data Collection Appliance) > 1.2

Set Up the Data Collection Appliance Virtual Machine 1 (VM1) Work Plan


Description Perform the setup work required for the first Virtual Machine, where the Data Collection

Appliance is installed.

Task List Launching the First Boot Configuration Tool

Configuring Appliance Administrators

Configuring Static Network Setting

Configuring the Timezone and Time

Configuring the Appliance Role

Configuring Appliance Administrators Tasks

Create a password for the username “root”. The password must contain a minimum of eight characters and include all of the following character types:

numeric

uppercase

lowercase

non-alphanumeric such as # or !



03/03/11








Configuring the Appliance Role Task

This task takes about 5+ minutes after you choose the role to complete.


Perform Data Collection Appliance Post-Installation Steps Work Plan


Description Perform the post-installation steps for the Data Collection Appliance on the first Virtual

Machine.

Task List Log in to the ADM Console

Upload the License Key

Log in to the ADM Console Task

Launch Internet Explorer (the only browser that will work – you will get an error if you try another one) and enter the IP address of VM1.

Use the "admin" login & password given in the EMC Data Collection Appliance Host Validation for Data Migration Deployment Guide. The “root” password for the Data Collection Appliance will not work.


Upload the License Key Task

Enter the license key provided in the LICENSE.txt file on the iso file (or DVD, if you burned it).



03/03/11








Set Up the Data Collection Appliance on Virtual Machine 2 (VM2) Work Plan


Description Install and perform the initial setup of the the Data Collection Appliance Collector on the

second Virtual Machine that has Windows Server 2008 installed on it (licensed by the customer).

Task List Set Up the Data Collection Appliance Collector on VM2 on ESX Host

Set Up the Data Collection Appliance Collector on VM2 on ESX Host Task

The Windows collector unique ID is the same identifier that was defined on the aggregator side for WMI discovery. The default value is 200.



03/03/11




Configure the Data Collection Appliance Virtual Machines Work Plan


Description Configure the Data Collection Appliance on the first Virtual Machine and the Collector

on the second Virtual Machine that has Windows Server 2008 installed on it (licensed by the customer).

Task List Configure VM1

Configure VM2

Configure VM1 Task

If you do not see the "/home" directory, type the following command in the Address field in WinSCP before you login: /home/nlayers/Seneca/ActiveProbe/conf Figure 5 shows where to enter this command:

Figure 5. WinSCP directory location

Put the IP address of VM1 (the aggregator / bare metal VM) in the IPfile.txt file. See the latest EMC Data Collection Appliance Host Validation for Data Migration Virtual Machine Deployment Guide for the current information – located on Powerlink: Support > Product and Diagnostic Tools > Data Collection Appliance (Data Collection Appliance) > 1.2


03/03/11




Performing Grab Script Work on the Data Collection Appliance Work Plan


Description Download GRAB scripts onto the Data Collection Appliance in order to push them out to

the various hosts on which they are to be to run.

Task List Download GRAB Scripts from EMC

Upload GRAB Scripts by using GUI

Configure GRAB Directories by using GUI

Download GRAB Scripts from EMC Task

The locations of GRAB Scripts:

UNIX systems: ftp://ftp.emc.com/pub/emcgrab/Unix

Windows systems: ftp://ftp.emc.com/pub/emcgrab/Windows

ESX systems: ftp://ftp.emc.com/pub/emcgrab/ESX


Upload GRAB Scripts by using GUI Task

The upload of the GRAB scripts restarts the ADM collector services. The upload might take several minutes to complete.


Saving the locations of the GRAB script and output will restart the Collector. Configure GRAB

Directories by using GUI Task


Create an IP Discovery Policy for EMC GRAB Hosts for Data Collection Appliance Work Plan


Description Creation an IP Discovery policy, which uses TCP for scanning to find hosts in the

environment, and initially populates the Data Collection Appliance database.


03/03/11

ftp://ftp.emc.com/pub/emcgrab/Unix

ftp://ftp.emc.com/pub/emcgrab/Windows

ftp://ftp.emc.com/pub/emcgrab/ESX








Task List Restart Discovery

Create IP Discovery Policy

Restart Discovery Task

Prior to deployment, review the requirements for the target hosts with the customer system administration team. If the requirements are not met prior to implementation of the Data Collection Appliance, an increased implementation effort might be required to mitigate the issues, and such effort is considered out-of-scope for the deployment.

Performing a “Restart Discovery” forces Data Collection Appliance out of the setup mode, so you do not have to wait to run your discovery policies.

Note: Restart Discovery erases all the discovered data in the database.


Create IP Discovery Policy Task

The policy is created and will run automatically. The results begin to appear after approximately 10 minutes. The total time required to complete IP discovery will depend on the number of hosts in the scope.

Note: Refresh the inventory screen manually. To refresh the inventory, select Discover > Inventory.


Create Groups for Host Discovery by Data Collection Appliance Work Plan


Description Create groups for host discovery with the Data Collection Appliance.

Task List Create Groups by using IP Addresses or Subnets

Create Groups by using IP Addresses or Subnets Task

Click on Data Collection Appliance Settings to open the window to get to Groups.



03/03/11








Initiate Detail Discovery Policy on the Data Collection Appliance Work Plan


Description Perform the Detail Discovery (Active Discovery) for the SAN-attached hosts. The Detail

Discovery is used to manage the GRAB scripts by pushing the GRAB script to host, running the GRAB script, and retrieving the results from each host.

Task List Create Detail Discovery Policy

Run the Policy

View the Results

Create Detail Discovery Policy Task

Create a policy for each protocol type (SSH, WMI, and so on).


Run the Policy Task

Initiate the start of the collection only - EMC does not stay for collections longer than 2 hours (roughly 64 hosts per hour).

When the Data Collection Appliance is initially configured, it goes into “setup” mode and will not do any discovery for the first 24 hours. However, you can manually force the discovery by running the policy.


View the Results Task

This is a spot check to ensure that the started collection is working correctly. This is NOT the final collection of all results.



03/03/11








Processing the Data Collection Appliance Discovery Results (collecting the GRAB Output Files) Work Plan


Description Collect the GRAB Output files. If there are a large number of hosts, then EMC personnel

can return at a specified later time.

Task List Collect Results

Collect Results Task

If the host amount will create an extended period for the Data Collection Appliance to run to get the GRABs, EMC may leave and return to collect the results of the GRAB collection.


Remove Data Collection Appliance from the ESX Server Work Plan


Description Remove the Data Collection Appliance from the two Virtual Machines on the customer's

ESX Server.

Task List Remove Data Collection Appliance from the Customer Environment

Remove Data Collection Appliance from the Customer Environment Task

Destroy the VM Built by Data Collection Appliance and Remove Data Collection Appliance Collector from the Customer's MS Windows 2008 Server VM

The Data Collection Appliance is EMC Global Services property and can not be purchased by the customer.

The DVD must be returned after the standalone Data Collection Appliance Virtual Machines are removed from the customer’s ESX server environment.


03/03/11




Discover and Correlate the Environment for Data Migrations Activity

Role Solutions Architect / Implementation Specialist

Description Collect customer-environment information using GRABs and other manual methods.

(Collection can also be done by the customer and given to EMC.) It also covers processing the information through EMC tools such as HEAT and SWAT.

Review Customer Provided Data Collection Information Work Plan

Role Solutions Architect

Description Provide a basic review of the customer-provided information to verify that it provides the

proper information for completing analysis.

Task List Perform Review of Customer Provided Data Collection Information

Manually Collect Host and Storage Data Work Plan


Description Perform manual collection of data in environments that lack installed tools and collection

methods.

Task List Perform Manual Collection of Host and Storage Data

Collect Host Information (GRABs-Reports) Work Plan


Description Collect host data by using GRABs/Reports.

Task List Perform Collection of Host Information

Perform Collection of Host Information Task

To develop a migration plan, be sure to first collect information on the environment to be migrated. This engagement uses EMC GRAB and HEAT tools to establish the baseline. The location of these two tools is included in the Reference Documentation and Resources section of this document. For details or help on either tool refer to the tool help guide.

To gather the information on environment to be migrated, do the following:

Collect EMCGrab data from the customer environment.

Upload all of the EMCGrab information to the HEAT tool for processing.


03/03/11


Note: HEAT only processes the uncorrupted, unaltered output of the EMCGrab.

The input files must not have spaces in the filename.

When you run ftp, ensure that the HEAT file is transferred in binary mode.

Document the current hardware and software configuration for all Symmetrix systems included in migration.

Process switch data through SWAT.

Collect Switch Configuration Data Work Plan


Description Collect switch and director configuration information on fabrics, zones, security, and

administration requirements.

Task List Perform Collection Switch Configuration Data

Collect CLARiiON Storage Data Work Plan


Description Collect CLARiiON storage data (performed by EMC).

Task List Perform Collection of CLARiiON Storage Data

Collect Symmetrix Storage Data Work Plan


Description Collect Symmetrix storage data (performed by EMC).

Task List Perform Collection of Symmetrix Storage Data

Collect Non-EMC Storage Data Work Plan


Description Collect non-EMC storage data (performed by EMC).

Task List Perform Collection Non-EMC Storage Data


03/03/11


Process GRABs through HEAT using HEAT-IT Work Plan


Description Process customer data by processing it through the HEAT tool for a data migration.

Task List Perform Processing of GRABs through HEAT using HEAT-IT

Process Switch and Director Data through SWAT Work Plan


Description Process switch data through the SWAT tool.

Task List Perform Processing of Switch and Director Data through SWAT

Process CLARiiON-related HEAT-Swat HTML through SAN Summary Work Plan


Description Process CLARiiON information through EMC tools like HEAT.

Task List Perform Processing of CLARiiON-related HEAT/SWAT HTML through SAN

Summary

Process Symmetrix-related HEAT/SWAT HTML through EMP/SAN Summary for Data Migrations Work Plan


Description Process Symmetrix information through EMC tools like HEAT. This work plan also

allows for the efficiencies gained through the use of the EMP Tool, if used as part of the engagement.

Task List Perform Processing of Symmetrix-related HEAT/SWAT HTML through

EMP/SAN Summary


03/03/11


Perform Processing of Symmetrix-related HEAT/SWAT HTML through EMP/SAN Summary Task

EMP provides a report on any required or recommended remediation of the assets. This report is similar to one produced by the SAN Summary tool. Review this report with the customer to plan for any remediation required. The following are tasks performed in this step:

Map and build-out the Switch and SAN view in a Symmetrix environment.

Map and build out the Symmetrix storage view of the environment.

Process Non-EMC Storage Array Related HEAT/SWAT HTML through SAN Summary Work Plan


Description Process non-EMC storage information.

Task List Perform Processing Non-EMC Storage Array Related HEAT/SWAT HTML through

SAN Summary


03/03/11


Perform Environment Analysis and Validation for Data Migration Activity


Description Perform e-Lab checks, reviewing the data collected on EMC hardware, and reviewing

findings with the customer.

Perform e-Lab Checks for Current STD Hosts and Virtual Machines Work Plan


Description Perform validation checks on standard hosts and virtual machines using e-Lab data.

Task List Conduct e-Lab Checks for Current STD Hosts and Virtual Machines

Perform e-Lab Checks for Current Switches Work Plan


Description Perform validation checks on SAN switches using e-Lab data.

Task List Conduct e-Lab Checks for Current Switches

Review Current Symmetrix-related EMP/SAN Summary Reports Work Plan


Description Review information gathered on any Symmetrix systems in the environment.

Task List Perform Review of Current Symmetrix-related EMP/SAN Summary Reports


03/03/11


Review Current CLARiiON-related EMP/SAN Summary Reports Work Plan


Description Review information gathered on any CLARiiONs in the environment.

Task List Perform Review of Current CLARiiON-related EMP/SAN Summary Reports

Review the Current Analysis Findings with the Customer Work Plan


Description Review the analysis findings with the customer.

Task List Perform Review of the Current Analysis Findings with the Customer

Perform Review of the Current Analysis Findings with the Customer Task

After discovering the assets, select assets in scope for migration. Then, do a detailed analysis to create a baseline, or current state of the assets. Import the results of the discovery into EMP and log it as a Persistent Baseline. This is the anchor point for the project. Refer to the tool help guide for instructions on how to use the tool. It is not in the scope of this document to provide guidance on the tool.

The following are steps for analysis and validation:

Use e-Lab to check for current STD hosts and virtual machines.

Use e-Lab to check for current switches.

Review the current Symmetrix-related EMP/SAN summary reports.

Review the current report with the customer.


03/03/11


Plan and Build Out Proposed Environment for Data Migration Activity


Description Build out the switch/SAN view and the storage view of the environment (for Symmetrix

and/or CLARiiON).

Build Out Switch/SAN View in a Symmetrix Environment Work Plan


Description Create a Switch/SAN layout of the customer environment with Symmetrix.

Task List Perform the Build Out of the Switch/SAN View in a Symmetrix Environment

Build Out Switch/SAN View in a CLARiiON Environment Work Plan


Description Create a Switch/SAN layout of the customer environment with CLARiiON.

Task List Perform the Build Out of the Switch/SAN View in a CLARiiON Environment

Build-out the Symmetrix Storage View of the Environment Work Plan


Description Create a storage layout of the customer environment with Symmetrix.

Task List Perform the Build Out of the Symmetrix Storage View of the Environment

Perform the Build Out of the Symmetrix Storage View of the Environment Task

You can assign assets from the baseline to the planned environment at a high level. For example, host A is mapped to planned array 1. This is only a map and does not include details of migration. If you import the data correctly into EMP, you can perform this mapping to all assets in scope for migration. After the mapping is done, you can import details on the assets into EMP and array level configuration requirements will begin. This includes creation of planned devices, zoning of FA ports, performing volume control management, bandwidth, and so on. At this point, a capacity check is also performed to determine if there is enough disk capacity for the migration.

EMP also provides a report on any required/recommended remediation of the assets. This report is similar to one found in the SAN Summary Tool. Review this report with the customer to plan for any remediation required.


03/03/11


Build-out the CLARiiON Storage View of the Environment Work Plan


Description Create a storage layout of the customer environment with CLARiiON.

Task List Perform the Build Out of the CLARiiON Storage View of the Environment


03/03/11


Perform Host-based Migration Design and Documentation Activity


Description Define and document the host-based data migration procedures.

Define and Document Data Migration Procedures Work Plan


Description Perform the initial data migration procedure design and develop the required

documentation.

Task List Conduct the Definition and Documentation of Data Migration Procedures

Conduct the Definition and Documentation of Data Migration Procedures Task

EMC Technology Solutions works with the customer’s staff to plan and design a complete solution based on the customer’s requirements. This solution identifies source-to-target mapping, and the steps necessary to replicate all data within the scope of the engagement.

For complex migrations, it is essential to characterize the environment completely to understand performance limitations. The following all have an impact on the amount of data that can be replicated from one platform to another:

Operational schedules

Server load

Source and target storage performance

Network bandwidth, load, and so on.

The Planning and Design phase is focused on developing a migration plan, the Configuration Guide, and the Test Plan. It is critical to understand all technical considerations of the equipment at hand, as well as any operational considerations and application issues. Do not make any assumptions regarding:

Connectivity

Transfer rates

Schedules

You must get buy-in from all project participants (technical and management).

The designated EMC Project Manager is solely responsible for ensuring that the plan comes together, and that all parties adhere to their tasks and project schedules.

After all of the baseline information is collected and analyzed, you can focus on the design and documentation of the plan. The following are tasks performed in this step:

Define and Document Data Migration Procedures

Design and Document Array-based Migration


03/03/11



03/03/11

The design includes creating migration groups and event windows. A migration group is one or more assets that use the same migration technology and are migrating during one event window. This migration group is then assigned to an event window. That group may be moved in whole to another event window if necessary.

If only one asset in the group is moving, it must be removed from the current group and assigned to another group. If the migration method changes for one asset in the group, the asset must to be re-assigned to another group that is set to use the new method. If an asset is moved, all of its properties move with it.

There can be multiple migration groups assigned to an event window and there can be multiple event windows. An event window is the timeframe in which the customer configures and executes the migration of the asset(s) in the migration group(s) assigned to the event window (N to N+1, where N is current environment and N+1 is the planned environment).

Typically, the customer has short windows to accomplish any upgrade work requiring downtime. Also, the customer may be under tight time restrictions to perform the actual migration work. Setting proper expectations is critical. You must:

Review all information collected or created in this phase to ensure accuracy. This is especially important as project decisions, such as migration timing and sequencing, are based on this information.

Define all physical connections and cabling from the host processor to the storage subsystems. Have the CE (and the customer) lay these cables to EMC Symmetrix prior to the migration.

Note: Customer is responsible for any connections to non-EMC storage.

Determine a software configuration plan, if necessary. Some migrations require the implementation of custom software packages.

For data center relocation or disaster recovery engagements, your plan must include:

Physical layout and verification of environmental factors.

When deploying a new Symmetrix, data-center floor space and power must be reallocated.

Ensure the frames can be physically moved in and out of the planned positions.

Plan to have a phone line installed so EMC’s Call Home feature can be used.

Although a Symmetrix frame is in place, this does not mean it can be removed, as new customer equipment may have been added later that inhibit relocation.

Design for new cable infrastructure, if necessary.

Note: New data centers are being provisioned with under-floor cable trays and patch panels to expedite wiring new equipment.

Verify other conditions, such as length of cables; consider maximum cable runs; and consider actual cable path rather than straight-line distances.

Design for logical topology diagram of the new infrastructure. This helps to ensure that you properly plan for simple things like connections.

Important! Improperly sized links severely impact the performance of migrations and disaster recovery implementations.


Design and Document Open Migrator LM Migration Work Plan


Description Design and document the migration using Open Migrator/LM.

Task List Conduct the Design and Documentation of Open Migrator LM Migration

Conduct the Design and Documentation of Open Migrator LM Migration Task

When using EMC OM/LM as a data migration tool, the golden rule to follow is:

Do not impact the application’s workload I/O.

It is an obvious and yet overly simplistic statement. To do the migration using a tool that is run on the host, there will always be some kind of impact on the host application as EMC performs the actual migration. Perhaps a better way to make this statement apply is to say:

Try to lessen the impact on the application’s workload I/O.

With this statement you can begin to address planning and design, starting with the different ways that the two versions of OM/LM deal with bandwidth usage, and the relative impact on performance. Table 1 illustrates these versions.

Table 1. Open Migrator/LM Performance Impact

Version Bandwidth Usage

Windows

OM/LM for Windows automatically prioritizes any other I/O occurring on the host over migration I/O.

For example, if application I/O is high during the migration, OM/LM for Windows lowers the available bandwidth for the migration to allow more bandwidth for the application.

This means that OM/LM for Windows does not compete with the application on the host and should not adversely affect its performance.

This also means that migrations could take longer if the I/O activity is high for the server being used or migrated.

UNIX/Linux OM/LM for UNIX/Linux takes a different approach, allowing the user to control I/O allocation for the migration and the applications.

A user can give migration processes lower or higher priority, based on the available I/O capacity of the server. This tuning can be dynamically adjusted throughout the migration by the user (or via scripting).

For this reason you must determine the available bandwidth and tune OM/LM for UNIX appropriately, as it competes with the application for that bandwidth.

Once determined, the user can throttle the amount of bandwidth that will be used by OM/LM for UNIX during the migration (“tuning a ceiling”)

Best Practices.for more details.


03/03/11



03/03/11

The EMC Open Migrator/LM software can be in three states throughout a data migration process. Each state has an effect on the host, but it is important to note which one of the three has the biggest impact and when. Table 2 describes the three states.

Table 2. States of Open Migrator/LM Software During a Data Migration Process

State Version Description for Each Version

WINDOWS Driver is attached to the source and target devices, but not copying. Pass Through

UNIX/Linux Kernel module loaded, sessions active, but not copying.

WINDOWS Migration started (copying old Source data and mirroring new Source data to Target).

Migration

UNIX/Linux Sessions started (copying old Source data and mirroring new Source data to Target — comparable to a dd process/operation on a UNIX host).

WINDOWS Data copying completed, but still mirroring new Source data to Targets.

Mirroring

UNIX/Linux Sessions done (copying, but still mirroring new Source data to Targets).

The Migration state is the period where the impact to the application workload IO can be at its greatest, as this is the actual migration period.

Capabilities and Considerations

Table 3 lists capabilities and considerations in planning and design. For updates to this information, refer to the most recent release notes and other sources as listed in the Reference Documentation and Resources section.

Table 3. Capabilities and Considerations


Version Description

Data migration to a different volume type

Windows OM/LM supports migration of both basic and dynamic disks, as well as any fault-tolerant type. Source and destination volumes can be of dissimilar types and fault-tolerance levels. For example, OM/LM allows migration from a basic to a dynamic disk or from a striped disk to a spanned disk.


UNIX/Linux OM/LM supports data migration from any type of source block devices to any type of target block devices. In other words, the software allows data migration at the block I/O level between all types of volumes, LUNs, LUN partitions, and devices.

Data migration to a different volume size; target volume file system extension

Windows Windows NT file system (NTFS) can be migrated from smaller to larger volumes, or between equal-sized volumes. OM/LM adjusts the NTFS file systems automatically for the target volumes.



03/03/11


Version Description

Data migration to a different volume size

UNIX/Linux OM/LM can migrate data between source and target volumes or meta volumes of different sizes. The target volume must be of equal or larger size than the source volume.

Source and Target synchronization

Windows Both source and target volumes remain synchronized until the next restart.

FAT and FAT32 file systems

Windows OM/LM does not support migration of FAT and FAT32 file systems.


UNIX/Linux Both the source and target volumes remain synchronized until the session has been deactivated.

Connectivity options UNIX/Linux Can be to any storage platform and can be direct, through the Enterprise Storage Network, or on the SAN, operating over SCSI or Fibre Channel.

Session UNIX/Linux This is similar to consistency groups in concept (putting a DB instance (data/logs) all together.

This is also useful from an administrative standpoint (for larger migrations with lots of devices to move – group them into easier to manage “chunks” of source/target pairs).

Data synchronization UNIX/Linux OM/LM provides high availability data synchronization during your data migration operations. While a migration is in progress, the source volume remains fully available for both reads and writes.

OM/LM captures all writes to the source and copies them to the target during the migration process. The target volume is set as read/write disabled to the production host and should be unmounted or set as not ready to any additional host(s) having access to the volume to guarantee the volume cannot change during the migration session.



03/03/11

Restrictions and Limitations

Table 4 lists the restrictions and limitations to consider in the planning and design phase. For updates to this information, refer to the most recent release notes and other sources as listed in the Reference Documentation and Resources section.

Table 4. Restrictions and Limitations


Version Impact

Ten concurrent migrations

Windows You can run up to ten migrations of source/target pairs in the Windows version. You can adjust the number of concurrent migrations from the GUI through the right-click menu on the computer node.

The default maximum number of migrations is five.

No physical limit on concurrent migrations

UNIX/Linux There is no physical limit of the source/target pairs that can be run concurrently. The actual number of sessions that can be operated is limited by the availability of your operating system resources at the time of migration.

Note: Engineering has added that the practical limit is “about 128 source/target pairs per concurrent migration/session.” But available bandwidth will always be the deciding factor in any case.

Symmetrix® Support (older Symmetrix’, DMX, V-Max)

Windows There are no dependencies on the versions of the EMC Enginuity™ operating environment.

CLARiiON® support Windows There are no dependencies on CLARiiON Navisphere® software or FLARE code.

Celerra® support All This is not supported at current release of OM/LM.

Boot disk or system volume (root file system devices) migration

All This is not supported at current release of OM/LM.

Automatic volume expansion


Migrations for Microsoft Cluster Servers (MSCS)

Windows Migrations with Microsoft Cluster Servers (MSCS) are supported. OM/LM can only be installed on a single node of a cluster.

Migrations for cluster host environments

UNIX/Linux Migrations for cluster host environments are not supported at current release of OM/LM.

PowerPath support Windows If you plan to use OM/LM with PowerPath, PowerPath must be at version 3.0.2 or later.

Microsoft Terminal Server

Windows This is not supported in the current release of OM/LM.

Default rate (ceiling — available bandwidth for

UNIX/Linux 1 MB — This can be changed before or during migration (dynamic)

Note: The default is way too low, so you must change



03/03/11


Version Impact

OM/LM)

this AFTER you determine available bandwidth for OM/LM.

Best Practices, below, for more details.

Default I/O size UNIX/Linux 64 kb — Not dynamic, must be changed prior to migration.

Unmount target before migration

UNIX/Linux You cannot activate or copy if target device is mounted.

Best Practices

Table 5 lists best practices in planning and design. For updates to this information always refer to the most recent release notes and other sources as listed in the Reference Documentation and Resources section.

Table 5. Best Practices

Best Practices Version Description

Pilot or test migration All This is a common practice for Data Migrations. Ask the customer for an opportunity to run a pilot migration on a host to determine available bandwidth. For more information on a Pilot Migration, refer to the Perform Pre-migration Planning for Host-based Migrations Activity, and the Perform Test Migrations on Hosts/Clusters Prior to Migration Cutover Date Work Plan.

For OM/LM for UNIX, this is vital because it will compete with the application for bandwidth. See the “dd test” information below.

Do the migration at the highest layer

UNIX/Linux Always do the migration at the highest layer LVM (volume) MPIO (multi-pathing - try not to do it here) LUN (raw device)

Note: The layer is determined by path name you choose.

Total number of sessions vs. total number of devices

UNIX/Linux Testing determined that the total number of devices migrated concurrently has the greatest effect on performance (understandably so).

However, the total number of sessions does not have an effect. So you cannot create a more efficient migration by taking the same number of devices and dividing them up into multiple sessions.

The bottom line is that your performance will be affected by the total amount of devices being concurrently migrated.



03/03/11


dd test (for available bandwidth for OM/LM)

UNIX/Linux dd is a copy process on a UNIX host, which is comparable to the “migration” state of OM/LM (copying).

Using dd is the best way to determine the effective bandwidth available (for application and OM/LM – Reads & Writes).

See more information below.

Offline migration UNIX/Linux If the host will be offline for the OM/LM migration, then there is no problem with host application I/O performance/competition. Tune the “ceiling” to max in that situation ONLY.

Determining Available Bandwidth (UNIX/Linux)

Due to the fact that OM/LM competes with the host application for available bandwidth, it is extremely important that you determine how much available bandwidth OM/LM should use, and tune a “ceiling” with that parameter prior to starting the migration.

Since the “migration” state of OM/LM is when it is in its copying mode, a dd process on UNIX or Linux servers is comparable to the bandwidth/performance impact of the actual migration. (Generally, the variance between them is less than 10% difference, with no application load during the dd test and the OM/LM migration.)

For this reason, determining the available bandwidth for an OM/LM migration is essential. Consult with your customer’s System Administrators to see if they have tools that can show how much bandwidth is being used by an application during peak periods (assuming the migration will run into those times as well) and how much is available for OM/LM for a migration operation during those times.

dd Test Procedure

You can perform an alternative test to determine available bandwidth on the host using a dd command prior to the migration.

The recommended steps to performing a dd test against the source device are as follows:

While the host application is running, start an I/O monitoring program.

Example utilities: iorate, sar, iostat

Run a dd commands to read against multiple source devices simultaneously, copying to /dev/null.

By doing multiple devices, you can simulate a subset of the entire migration.

Example: dd if=/dev/rdsk/c2t0d0s2 of=/dev/null bs=131072 skip=1 seek=1

Record the bandwidth used.

Take 25% of that bandwidth number.

The dd command performed a Read only.

You must allow for Reads and Writes to the source from the host application.



03/03/11

You must also need to allow for any mirroring operations occurring during the copying process.

Next, run a similar set of tests against the target device:

Run a dd commands against the source copying to the target device:

This assumes that the target device is not in use or has any data on it (of course).

Again by doing multiple devices, you can simulate a subset of the entire migration.

Example: dd if=/dev/rdsk/c2t0d6s2 of=/dev/rdsk/c6t0d6s2 bs=131072 skip=1 seek=1




You must allow for some Reads and Writes from any mirroring that might occur during the copying process.

You might consider running the test again on a different subset of data to be migrated; perhaps a larger amount to see how much it changes the bandwidth numbers.

Now that you have two bandwidth numbers calculated, use the lesser of the two for your final “ceiling” (available bandwidth) to tune/allocate to OM/LM on the host with data to be migrated.

Some Caveats

When you run these tests, consider the following factors which will skew your results:

Is this the peak I/O load period for the application?

Is it the slowest time?

You want to run this test when the migration will be performed, but if there is a large amount of data to be migrated, the data could run through different periods of I/O flow. Try to choose the peak periods to do the test, as you want to allocate the least amount of available bandwidth to OM/LM for those times.

If someone is capable of scripting in the customer’s environment, you could create a cron job to run the tuning command to change the ceiling in those fluctuations of I/O activity. Of course, you will need to know what to change the “ceiling” to for each period, which may require running the dd test in different times of day.



03/03/11

Common Risks

Table 6 identifies the common solution risks, their potential impact, and some ways to help mitigate risk.

Table 6. Common Risks

Common Solution Risks

Impact Mitigation Options

Another host has write access to the target volume (shared volumes between hosts)

Data corruption may be possible during a copy operation

If this is a concern, we recommend that the target volume be unmounted or marked as not ready to any other hosts to guarantee that the volume cannot change while the copying is in process.

Customer does not want to upgrade operating system to current service pack

Potential issues with compatibility of OM/LM with the OS

It would not be wise, from a support standpoint, to start a major project like attaching new storage without being on the most current revision of the operating system.

If the installation includes drivers for HBAs, that is another reason to be on the most current service pack.

Customer unwilling to install software on production server

Migration requires OM/LM to be installed on host with storage to be migrated.

Suggest running a pilot or test migration. This can give the customer a comfort level with “new” software and also gain the implementer valuable information on performance characteristics.

Ask if they can afford to use tape restore (time and reliability issues).

Minimum of two system reboots required (OM/LM for Windows only)

Host I/O disruption during reboots.

Unavoidable. One reboot is required for tool installation; the second reboot is for the resizing, drive letter re-assignment, and tool de-installation.

Note: OM/LM for UNIX does not require reboots.

Tuning/setting the “ceiling” to max (UNIX only)

OM/LM competes with the host application for available bandwidth if the host is kept online.

Use this setting ONLY if the migration will be performed offline (the host is “taken down” for the duration of the migration).

Determine the available bandwidth and tune the “ceiling” parameter to that amount.

Best Practices – dd test, below, for more details.

Running the “compare” feature (UNIX only)

Doubles migration time

Two Reads and two Writes for each transaction.



03/03/11



Using the “Large Migrations” procedure for running multiple sessions serially

If you migrate sets of data (like databases and logs), you want to make certain that all of this data is consistent.

Even if you run the sessions serially (one after the other), do not stop the sessions until you complete all of the other sessions.

You want to run a session, have it complete its copying, and then let it stay in “mirroring” mode when you run the rest of the sessions. This way, at the end of the entire migration, you can stop the application after all sessions are copied and mirrored successfully. This keeps all data consistent.

After running the pilot migration or dd test, the available bandwidth for OM/LM is very low.

This means that OM/LM will take longer than anticipated to perform the migration.

See if there are any opportunities to add more paths to the device on the host. Are there any opportunities to add more HBAs to the host (assuming the PCI bus is not already saturated)?

Look at the SAN and see if there are any bottlenecks, like ISLs between switches that are being traversed by the host and storage. Are there any opportunities to add more ISLs? (assuming there are available ports on both switches)

Look at the storage and see if there is contention on the storage port itself (fan-in ratios are not too high).

The detailed design in the Configuration Guide goes beyond general information, such as types and sizes, to specifying actual software and hardware requirements. The software requirements include the specific software selected as well as the systems to which the software is deployed. The hardware requirements include the assignment of customer logical units or devices to specific devices and the selection of the required supporting processes.

Summarize the existing hardware environment and obtain:

The network configurations schematics to help understand connectivity issues. This is necessary to plan the details.

For Symmetrix, make sure there are FA ports available. You may need to move boards around or make room some other way to squeeze a new board into a nearly full Symmetrix.

The system layout information to comprehend application to hardware interdependencies. Obtain network (FC and IP) layout schematics to help understand connectivity issues. Scheduling will be influenced by how servers and applications impact each other. It may be necessary to move applications A and B one weekend, then C and D on the next weekend. Trying to do everything in one weekend may not be possible and mixing A and C also may not be possible.

An inventory of all platforms and storage capacities, and gain an understanding of the customer’s growth issues if the project will be long in duration. Determine the system configuration (volume sizes, block sizes, I/O transfer rates, and data read/write ratios).

Collect system and channel performance information to determine performance impact to project.



03/03/11

Determine the maintenance window schedules. It is critical to understand the impact to the customer’s environment and then map that into the project plan and tool selection. A short window on Saturday or Sunday nights may be difficult to accomplish enough work, especially with other pressures.

Source and Target Data Representation

As part of the Interview Guide, you are asked to gather information on current and planned migration environments using the tables in the Configuration Guide. Using DM tools, collect the server and storage information needed to estimate the data migration effort and to serve as a check list for the actual migration service.

To complete the information gathering:

1. Complete the Current Environment Information discovery.

2. Correlate the information gathered from all the tools.

3. Perform the analysis of the current environment.

4. Validate the assets in scope of data migration.

5. Complete the planned environment information using EMP tool.

6. Resolve any interoperability issues identified to ensure the correct assets are migrated successfully.

Review the Test Plan

Customer and EMC personnel should review the Test Plan in detail. The components of the plan are provided in the Test Plan document. With a clear understanding of the detail involved in the standard Test Plan, the customer is assured that the engagement will be installed properly and thoroughly tested.

Tests included in the Test Plan in this TS Service Kit do not provide Command Line Interface (CLI) instructions. If that level of detail is required, refer to the product documentation and the Test Plan within the TS Service Kit.

Evaluate Additional Customer Requirements

The customer may have their own test and acceptance criteria. If this is the case, evaluate these criteria carefully. Make every attempt to assign specific customer testing issues to corresponding items in the standard test plan. Those items that the customer feels are unique and not covered by the standard test plan should then be evaluated for level of effort, risk, and other factors. Items that can not be accommodated within the SOW should be referred to project management to resolve.


Design and Document Open Migrator LM Swingframe Migration Work Plan


Description Design and document all Open Migrator LM migration methods.

Task List Conduct the Design and Documentation of Open Migrator LM Swingframe

Migration

Conduct the Design and Documentation of Open Migrator LM Swingframe Migration Task

When using EMC OM/LM as a data migration tool, the golden rule to follow is:

Do not impact the application’s workload I/O.

It is an obvious and yet overly simplistic statement. To do the migration using a tool that is run on the host, there will always be some kind of impact on the host application as we perform the actual migration. Perhaps a better way to make this statement apply is to say:

Try to lessen the impact on the application’s workload I/O.

With this statement you can begin to address planning and design, starting with the different ways that the two versions of OM/LM deal with bandwidth usage, and the relative impact on performance. Table 7 identifies these versions.

Table 7. Open Migrator/LM Performance Impact

Version Bandwidth Usage

Windows

OM/LM for Windows automatically prioritizes any other I/O occurring on the host over migration I/O.

For example, if application I/O is high during the migration, OM/LM for Windows lowers the available bandwidth for the migration to allow more bandwidth for the application.

This means that OM/LM for Windows does not compete with the application on the host and should not adversely affect its performance.

This also means that migrations could take longer if the I/O activity is high for the server being used or migrated.

UNIX/Linux OM/LM for UNIX/Linux takes a different approach, allowing the user to control I/O allocation for the migration and the applications.

A user can give migration processes lower or higher priority, based on the available I/O capacity of the server. This tuning can be dynamically adjusted throughout the migration by the user (or via scripting).

For this reason you must determine the available bandwidth and tune OM/LM for UNIX appropriately, as it competes with the application for that bandwidth.

Once determined, the user can throttle the amount of bandwidth that will be used by OM/LM for UNIX during the migration (“tuning a ceiling”).

Best Practices for more details.

The EMC Open Migrator/LM software can be in three states throughout a data migration process. Each state has an effect on the host, but it is important to note which one of the three has the biggest impact and when. Table 8 describes the three states.


03/03/11



03/03/11

Table 8. States of Open Migrator/LM Software During a Data Migration Process

State Version Description for Each Version

WINDOWS Driver is attached to the source and target devices, but not copying. Pass Through

UNIX/Linux Kernel module loaded, sessions active, but not copying.

WINDOWS Migration started (copying old Source data and mirroring new Source data to Target).

Migration

UNIX/Linux Sessions started (copying old Source data and mirroring new Source data to Target — comparable to a dd process/operation on a UNIX host).

WINDOWS Data copying completed, but still mirroring new Source data to Targets.

Mirroring

UNIX/Linux Sessions done (copying, but still mirroring new Source data to Targets).

The Migration state is the period where the impact to the application workload IO can be at its greatest, as this is the actual migration period.


Table 9 lists capabilities and considerations in planning and design. For updates to this information, refer to the most recent release notes and other sources as listed in the Reference Documentation and Resources section.

Table 9. Capabilities and Considerations


Version Description


Windows OM/LM supports migration of both basic and dynamic disks, as well as any fault-tolerant type. Source and destination volumes can be of dissimilar types and fault-tolerance levels. For example, OM/LM allows migration from a basic to a dynamic disk or from a striped disk to a spanned disk.


UNIX/Linux OM/LM supports data migration from any type of source block devices to any type of target block devices. In other words, the software allows data migration at the block I/O level between all types of volumes, LUNs, LUN partitions, and devices.

Data migration to a different volume size; target volume file system extension

Windows Windows NT file system (NTFS) can be migrated from smaller to larger volumes, or between equal-sized volumes. OM/LM adjusts the NTFS file systems automatically for the target volumes.

Data migration to a different volume size

UNIX/Linux OM/LM can migrate data between source and target volumes or meta volumes of different sizes. The target volume must be of equal or larger size than the source volume.



03/03/11


Version Description


Windows Both source and target volumes remain synchronized until the next restart.

FAT and FAT32 file systems

Windows OM/LM does not support migration of FAT and FAT32 file systems.


UNIX/Linux Both the source and target volumes remain synchronized until the session has been deactivated.

Connectivity options UNIX/Linux Can be to any storage platform and can be direct, through the Enterprise Storage Network, or on the SAN, operating over SCSI or Fibre Channel.

Session UNIX/Linux This is similar to consistency groups in concept (putting a DB instance (data/logs) all together.

This is also useful from an administrative standpoint (for larger migrations with lots of devices to move – group them into easier to manage “chunks” of source/target pairs).

Data synchronization UNIX/Linux OM/LM provides high availability data synchronization during your data migration operations. While a migration is in progress, the source volume remains fully available for both reads and writes.

OM/LM captures all writes to the source and copies them to the target during the migration process. The target volume is set as read/write disabled to the production host and should be unmounted or set as not ready to any additional host(s) having access to the volume to guarantee the volume cannot change during the migration session.



03/03/11


Table 10 lists known restrictions and limitations for consideration in planning and design. For updates to this information, refer to the most recent release notes and other sources as listed in the Reference Documentation and Resources section.

Table 10. Restrictions and Limitations


Version Impact

Ten concurrent migrations

Windows You can run up to ten migrations of source/target pairs in the Windows version. You can adjust the number of concurrent migrations from the GUI through the right-click menu on the computer node.

The default maximum number of migrations is five.

No physical limit on concurrent migrations

UNIX/Linux There is no physical limit of the source/target pairs that can be run concurrently. The actual number of sessions that can be operated is limited by the availability of your operating system resources at the time of migration.

Note: Engineering has added that the practical limit is “about 128 source/target pairs per concurrent migration/session.” But available bandwidth will always be the deciding factor in any case.

Symmetrix support (older Symmetrix’, DMX, V-Max)

Windows There are no dependencies on the versions of the EMC Enginuity™ operating environment.

CLARiiON support Windows There are no dependencies on CLARiiON Navisphere® software or FLARE code.

Celerra support All This is not supported at current release of OM/LM.

Boot disk or system volume (root file system devices) migration


Automatic volume expansion


Migrations for Microsoft Cluster Servers (MSCS)

Windows Migrations with Microsoft Cluster Servers (MSCS) are supported. OM/LM can only be installed on a single node of a cluster.

Migrations for cluster host environments

UNIX/Linux Migrations for cluster host environments are not supported at current release of OM/LM.

PowerPath support Windows If you plan to use OM/LM with PowerPath, PowerPath must be at version 3.0.2 or later.

Microsoft Terminal Server

Windows This is not supported in the current release of OM/LM.

Default rate (ceiling — available bandwidth for

UNIX/Linux 1 MB — This can be changed before or during migration (dynamic)

Note: The default is way too low, so you must change



03/03/11


Version Impact

OM/LM)

this AFTER you determine available bandwidth for OM/LM.

Note: Best Practices for more details.

Default I/O size UNIX/Linux 64 kb — Not dynamic, must be changed prior to migration.

Unmount target before migration

UNIX/Linux You cannot activate or copy if target device is mounted.



03/03/11

Best Practices

Table 11 lists best practices in planning and design. For updates to this information always refer to the most recent release notes and other sources as listed in the Reference Documentation and Resources section.

Table 11. Best Practices


Pilot or Test Migration All This is a common practice for Data Migrations. Ask the customer for an opportunity to run a pilot migration on a host to determine available bandwidth. For more information on a Pilot Migration, refer to the Perform Pre-migration Planning for Host-based Migrations Activity, and the Perform Test Migrations on Hosts/Clusters Prior to Migration Cutover Date Work Plan.

For OM/LM for UNIX, this is vital because it will compete with the application for bandwidth. See the “dd test” information below.

Do the migration at the highest layer

UNIX/Linux Always do the migration at the highest layer LVM (volume) MPIO (multi-pathing - try not to do it here) LUN (raw device)

Note: The layer is determined by path name you choose.

Total Number of Sessions vs. Total Number of Devices

UNIX/Linux Testing determined that the total number of devices migrated concurrently has the greatest effect on performance (understandably so).

However, the total number of sessions does not have an effect. So you cannot create a more efficient migration by taking the same number of devices and dividing them up into multiple sessions.

The bottom line is that your performance will be affected by the total amount of devices being concurrently migrated.

dd test (for available bandwidth for OM/LM)

UNIX/Linux dd is a copy process on a UNIX host, which is comparable to the “migration” state of OM/LM (copying).

Using dd is the best way to determine the effective bandwidth available (for application and OM/LM – Reads & Writes).

See more information below.

Offline migration UNIX/Linux If the host will be offline for the OM/LM migration, then there is no problem with host application I/O performance/competition. Tune the “ceiling” to max in that situation ONLY.



03/03/11

Determining Available Bandwidth (UNIX/Linux)

Due to the fact that OM/LM competes with the host application for available bandwidth, it is extremely important that you determine how much available bandwidth OM/LM should use and tune a “ceiling” with that parameter prior to starting the migration.

Since the “migration” state of OM/LM is when it is in its copying mode, a dd process on UNIX or Linux servers is comparable to the bandwidth/performance impact of the actual migration. (Generally, the variance between them is less than 10% difference, with no application load during the dd test and the OM/LM migration.)

For this reason, determining the available bandwidth for an OM/LM migration is essential. Consult with your customer’s System Administrators to see if they have tools that can show how much bandwidth is being used by an application during peak periods (assuming the migration will run into those times as well) and how much is available for OM/LM for a migration operation during those times.

dd Test Procedure

You can perform an alternative test to determine available bandwidth on the host using a dd command prior to the migration.

The recommended steps to performing a dd test against the source device are as follows:

While the host application is running, start an I/O monitoring program.

Example utilities: iorate, sar, iostat

Run a dd commands to read against multiple source devices simultaneously, copying to /dev/null.

By doing multiple devices, you can simulate a subset of the entire migration.

Example: dd if=/dev/rdsk/c2t0d0s2 of=/dev/null bs=131072 skip=1 seek=1




You must allow for Reads and Writes to the source from the host application.

You must also need to allow for any mirroring operations occurring during the copying process.

Next, run a similar set of tests against the target device:

Run a dd commands against the source copying to the target device:

This assumes that the target device is not in use or has any data on it (of course).

Again by doing multiple devices, you can simulate a subset of the entire migration.

Example: dd if=/dev/rdsk/c2t0d6s2 of=/dev/rdsk/c6t0d6s2 bs=131072 skip=1 seek=1





03/03/11


You must allow for some Reads and Writes from any mirroring that might occur during the copying process.

You might consider running the test again on a different subset of data to be migrated; perhaps a larger amount to see how much it changes the bandwidth numbers.

Now that you have two bandwidth numbers calculated, use the lesser of the two for your final “ceiling” (available bandwidth) to tune/allocate to OM/LM on the host with data to be migrated.

Some Caveats

When you run these tests, consider the following factors which will skew your results:

Is this the peak I/O load period for the application?

Is it the slowest time?

You want to run this test when the migration will be performed, but if there is a large amount of data to be migrated, the data could run through different periods of I/O flow. Try to choose the peak periods to do the test, as you want to allocate the least amount of available bandwidth to OM/LM for those times.

If someone is capable of scripting in the customer’s environment, you could create a cron job to run the tuning command to change the ceiling in those fluctuations of I/O activity. Of course, you will need to know what to change the “ceiling” to for each period, which may require running the dd test in different times of day.

Common Risks

Table 12 identifies the common solution risks, their potential impact, and some ways to help mitigate risk.

Table 12. Common Risks



Another host has write access to the target volume (shared volumes between hosts).

Data corruption may be possible during a copy operation

If this is a concern, we recommend that the target volume be unmounted or marked as not ready to any other hosts to guarantee that the volume cannot change while the copying is in process.

Customer does not want to upgrade operating system to current service pack

Potential issues with compatibility of OM/LM with the OS

It would not be wise, from a support standpoint, to start a major project like attaching new storage without being on the most current revision of the operating system.

If the installation includes drivers for HBAs, that is another reason to be on the most current service pack.



03/03/11



Customer unwilling to install software on production server

Migration requires OM/LM to be installed on host with storage to be migrated.

Suggest running a pilot or test migration. This can give the customer a comfort level with “new” software and also gain the implementer valuable information on performance characteristics.

Ask if they can afford to use tape restore (time and reliability issues).

Minimum of two system reboots required (OM/LM for Windows only)

Host I/O disruption during reboots.

Unavoidable. One reboot is required for tool installation; the second reboot is for the resizing, drive letter re-assignment, and tool de-installation.

Note: OM/LM for UNIX does not require reboots.

Tuning/setting the “ceiling” to max (UNIX only)

OM/LM competes with the host application for available bandwidth if the host is kept online.

Use this setting ONLY if the migration will be performed offline (the host is “taken down” for the duration of the migration).

Determine the available bandwidth and tune the “ceiling” parameter to that amount.

Best Practices – dd test, for more details.

Running the “compare” feature (UNIX only).

Doubles migration time

Two Reads and two Writes for each transaction.

Using the “Large Migrations” procedure for running multiple sessions serially

If you migrate sets of data (like databases and logs), you want to make certain that all of this data is consistent.

Even if you run the sessions serially (one after the other), do not stop the sessions until you complete all of the other sessions.

You want to run a session, have it complete its copying, and then let it stay in “mirroring” mode when you run the rest of the sessions. This way, at the end of the entire migration, you can stop the application after all sessions are copied and mirrored successfully. This keeps all data consistent.

After running the pilot migration or dd test, the available bandwidth for OM/LM is very low.

This means that OM/LM will take longer than anticipated to perform the migration.

See if there are any opportunities to add more paths to the device on the host. Are there any opportunities to add more HBAs to the host (assuming the PCI bus is not already saturated)?

Look at the SAN and see if there are any bottlenecks, like ISLs between switches that are being traversed by the host and storage. Are there any opportunities to add more ISLs? (assuming there are available ports on both switches)

Look at the storage and see if there is contention on the storage port itself (fan-in ratios are not too high).

The detailed design in the Configuration Guide goes beyond general information, such as types and sizes, to specifying actual software and hardware requirements. The software requirements include the specific software selected as well as the systems to which the



03/03/11

software is deployed. The hardware requirements include the assignment of customer logical units or devices to specific devices and the selection of the required supporting processes.

Summarize the existing hardware environment and obtain:

The network configurations schematics to help understand connectivity issues. This is necessary to plan the details.

For Symmetrix, make sure there are FA ports available. You may need to move boards around or make room some other way to squeeze a new board into a nearly full Symmetrix.

The system layout information to comprehend application to hardware interdependencies. Obtain network (FC and IP) layout schematics to help understand connectivity issues. Scheduling will be influenced by how servers and applications impact each other. It may be necessary to move applications A and B one weekend, then C and D on the next weekend. Trying to do everything in one weekend may not be possible and mixing A and C also may not be possible.

An inventory of all platforms and storage capacities, and gain an understanding of the customer’s growth issues if the project will be long in duration. Determine the system configuration (volume sizes, block sizes, I/O transfer rates, and data read/write ratios).

Collect system and channel performance information to determine performance impact to project.

Determine the maintenance window schedules. It is critical to understand the impact to the customer’s environment and then map that into the project plan and tool selection. A short window on Saturday or Sunday nights may be difficult to accomplish enough work, especially with other pressures.

Source and Target Data Representation

As part of the Interview Guide, you are asked to gather information on current and planned migration environments using the tables in the Configuration Guide. Using DM tools, collect the server and storage information needed to estimate the data migration effort and to serve as a check list for the actual migration service.

To complete the information gathering:

1. Complete the Current Environment Information discovery.

2. Correlate the information gathered from all the tools.

3. Perform the analysis of the current environment.

4. Validate the assets in scope of data migration.

5. Complete the planned environment information using EMP tool.

6. Resolve any interoperability issues identified to ensure the correct assets are migrated successfully.

Review the Test Plan

Customer and EMC personnel should review the Test Plan in detail. The components of the plan are provided in the Test Plan document. With a clear understanding of the detail involved in the standard Test Plan, the customer is assured that the engagement will be installed properly and thoroughly tested.



03/03/11

Test plans included in the Test Plan in this TS Service Kit do not provide Command Line Interface (CLI) instructions. If that level of detail is required, refer to the product documentation and the Test Plan within the TS Service Kit.

Evaluate Additional Customer Requirements

The customer may have their own test and acceptance criteria. If this is the case, evaluate these criteria carefully. Make every attempt to assign specific customer testing issues to corresponding items in the standard test plan. Those items that the customer feels are unique and not covered by the standard test plan should then be evaluated for level of effort, risk, and other factors. Items that can not be accommodated within the SOW should be referred to project management to resolve.


Provide EMC On-site Support Only for Customer-driven Host-based Migrations Activity


Description Deliver the on-site support for customer-driven migrations. EMC personnel will not

perform any migration work, only provide support as necessary.

Provide On-site Support Only During Customer-driven Open Migrator LM Migrations Work Plan


Description Provide online support of customer-driven Open Migrator LM migrations on a

Symmetrix. This does not include EMC effort to do the actual migration work (only support).

Task List Provide Support for Customer-Driven Open Migrator LM Migrations On-Site

Provide On-site Support Only During Customer-driven Open Migrator LM Swingframe Migrations Work Plan


Description Provide online support of customer-driven Open Migrator LM Swingframe migrations on

a Symmetrix. This does not include EMC effort to do the actual migration work (only support).

Task List Provide Support for Customer-Driven Open Migrator LM Swingframe Migrations On-

Site


03/03/11


Perform Additional Collection and Validation Activity

Role Solution Architect / Implementation Specialist

Description Collect additional customer environmental information using GRABs and manual

methods. (Collection can also be done by the customer and given to EMC.) You can also process information through EMC tools such as HEAT and SWAT. This usually occurs when an entire migration's duration is over 2-3 months, increasing the possibility that the data collected and analyzed early in the engagement is out-of-date.

Review Additional Customer-provided Data Collection Information Work Plan


Description Review the customer-provided information to verify that it meets proper analysis

requirements.

Task List Perform Review of Additional Customer-provided Data Collection Information

Manually Collect Additional Host and Storage Data Work Plan


Description Manually collect data in environments that lack installed tools and collection methods.

Task List Perform Manual Collection of Additional Host and Storage Data

Collect Additional Host Information (GRABs-Reports) Work Plan


Description Collect additional host and storage data using GRABs/Reports (performed by EMC).

Task List Perform Collection of Additional Host Information

Perform Collection of Additional Host Information Task

To develop a migration plan, be sure to first collect information on the environment to be migrated. This engagement uses EMCGrab and HEAT tools for establishing the baseline. The location for both these tools is included in the References section of this document. For details or help on either tool refer to the tool help guide.

To gather the information on environment to be migrated, do the following:

Collect EMCGrab data from the customer environment.


03/03/11


Upload all of the EMCGrab information to the HEAT tool for processing.

Note: HEAT only processes the uncorrupted, unaltered output of the EMCGrab.

The input files should not have spaces in the filename.

When you run ftp, ensure that the HEAT file is transferred in binary mode.

Document the current hardware and software configuration for all Symmetrix systems included in migration.

Process switch data through SWAT.

During the migration events, it is important to re-assess the assets being migrated to ensure changes did not happen since the initial discovery and planning. This assures that the correct assets are migrated and interoperable after migration completes. As a best practice, validate the assets of each migration group during the migration event window, and remedy any issues identified.

Collect Additional Switch Configuration Data Work Plan


Description Collect additional switch/director configuration information on fabrics, zones, security,

and administration requirements.

Task List Perform Collection of Additional Switch Configuration Data

Collect Additional CLARiiON Storage Data Work Plan


Description Collect additional CLARiiON storage data (performed by EMC).

Task List Perform Collection Additional CLARiiON Storage Data

Collect Additional Symmetrix Storage Data Work Plan


Description Collect additional Symmetrix storage data (performed by EMC).

Task List Perform Collection Additional Symmetrix Storage Data


03/03/11


Collect Additional Non-EMC Storage Data Work Plan


Description Collect additional non-EMC storage data (performed by EMC).

Task List Perform Collection Additional Non-EMC Storage Data

Process Additional GRABs through HEAT using HEAT-IT Work Plan


Description Process additional customer data through the HEAT tool for a data migration.

Task List Conduct Processing of Additional GRABs through HEAT using HEAT-IT

Process Additional Switch and Director Data through SWAT Work Plan


Description Process additional switch data through the SWAT tool (performed by EMC).

Task List Conduct Processing of Additional Switch and Director Data through SWAT

Process Additional CLARiiON-related HEAT/SWAT HTML through SAN Summary for Data Migrations Work Plan


Description Process additional CLARiiON information through EMC tools like HEAT.

Task List Conduct Processing of Additional CLARiiON-related HEAT/SWAT HTML through

SAN Summary


03/03/11


Process Additional Symmetrix-related HEAT/SWAT HTML through EMP/SAN Summary for Data Migrations Work Plan


Description Process additional Symmetrix information through EMC tools like HEAT. This work plan

also allows for the efficiencies gained through the use of the EMP Tool, if used as part of the engagement.

Task List Conduct Processing of Additional Symmetrix-related HEAT/SWAT HTML

through EMP/SAN Summary

Perform Processing of Additional Symmetrix-related HEAT/SWAT HTML through EMP/SAN Summary Task

EMP provides a report on any required or recommended remediation of the assets. This report is similar to one produced by the SAN Summary tool. Review this report with the customer to plan for any remediation required. The following are tasks performed in this step:

Map and build out the Switch and SAN view in a Symmetrix environment.

Map and build out the Symmetrix storage view of the environment.

Process Additional Non-EMC Storage Array Related HEAT/SWAT HTML through SAN Summary Work Plan


Description Process additional non-EMC storage information.

Task List Conduct Processing of Additional Non-EMC Storage Array Related HEAT/SWAT

HTML through SAN Summary


03/03/11


Perform Pre-migration Planning for Host-based Migrations Activity


Description Create step-by-step procedures and perform any pre-migration work necessary, including

test migrations if required.

Build Data Migration Cadence (Step-by-Step) Procedures for Open Migrator LM Migrations Work Plan


Description Build out the step-by-step procedures to implement an Open Migrator LM migration.

Task List Perform the Building of Data Migration Cadence (Step-by-Step) Procedures for

Open Migrator LM Migrations

Perform the Building of Data Migration Cadence (Step-by-Step) Procedures for Open Migrator LM Migrations Task

Do the pre-migration planning and testing, including the creation of planned environment devices and their assignment and mapping to source devices. Also, generate any scripts (mapping, masking, replication associations, and so on) to be part of the migration. Perform a test or pilot migration as a pre-cutover test to identify any issues with migration plan. The tasks in this step include:

Build data migration cadence (step-by-step) procedures.

Pre-implementation checkpoint for array-based migration.

Perform test migrations on hosts and clusters prior to the migration cutover date.

The customer is responsible for pre-migration testing and must sign off that the migration is acceptable prior to putting each system into production.

Build Data Migration Cadence (Step-by-Step) Procedures for Open Migrator LM Swingframe Migrations Work Plan


Description Build out the step-by-step procedures to implement an Open Migrator LM Swingframe

migration.

Task List Perform the Building of Data Migration Cadence (Step-by-Step) Procedures for

Open Migrator LM Swingframe Migrations


03/03/11


Perform the Building of Data Migration Cadence (Step-by-Step) Procedures for Open Migrator LM Swingframe Migrations Task

Do the pre-migration planning and testing, including the creation of planned environment devices and their assignment and mapping to source devices. Also, generate any scripts (mapping, masking, replication associations, and so on) to be part of the migration. Perform a test or pilot migration as a pre-cutover test to identify any issues with migration plan. The tasks in this step include:

Build data migration cadence (step-by-step) procedures.

Pre-implementation checkpoint for array-based migration.

Perform test migrations on hosts and clusters prior to the migration cutover date.

The customer is responsible for pre-migration testing and must sign off that the migration is acceptable prior to putting each system into production.

Conduct Pre-Implementation Checkpoint for Open Migrator LM Migrations Work Plan


Description Conduct a pre-implementation checkpoint for an Open Migrator LM migration.

Task List Perform Pre-implementation Checkpoint for Open Migrator LM Migrations

Conduct Pre-implementation Checkpoint for Open Migrator LM Swingframe Migrations Work Plan


Description Conduct a checkpoint for pre-implementation for an Open Migrator LM Swingframe

migration.

Task List Perform Pre-implementation Checkpoint for Open Migrator LM Swingframe

Migrations

Perform Test Migrations on Hosts/Clusters Prior to Migration Cutover Date Work Plan


Description Perform any test migrations prior to the actual migration.

Task List Conduct Test Migrations on Hosts/Clusters Prior to Migration Cutover Date


03/03/11


Perform Event Window Host-based Migration Planning Activity


Before the migration, review the source and target hosts, and perform any switch/SAN or storage configuration work necessary, and the data migration tools required for set up. This work is performed for event windows, in some cases each time per event window.

Description

Perform Pre-migration Review of Source Hosts (Migration Hosts) Work Plan


Description Do a pre-migration review of the source hosts used for the migration

Task List Conduct Pre-migration Review of Source Hosts (Migration Hosts)

Conduct Pre-migration Review of Source Hosts (Migration Hosts) Task

During planning for event window migration, confirm that any remediation required to hosts, storage, or other assets involved in migration are completed. Confirm that any infrastructural requirements such as power and connectivity are satisfied.

Perform Pre-migration Review of Target Hosts (New Hosts) Work Plan


Description Do a pre-migration review of the target hosts used for a remote migration.

Task List Conduct Pre-migration Review of Target Hosts (New Hosts)

Perform Switch Configuration Work -- Fabrics, Zoning, Zonesets -- for Migration Work Plan


Description Configure the switch(es), including zoning, zonesets, and fabrics.

Task List Conduct Switch Configuration Work -- Fabrics, Zoning, Zonesets -- for Migration


03/03/11


Perform Symmetrix Device Allocation and Host Discovery for Migration Work Plan


Description Conduct the Symmetrix-device allocation and perform the host discovery work.

Task List Conduct Symmetrix Device Allocation and Host Discovery for Migration

Perform CLARiiON LUN Allocation and Host Discovery for Migration Work Plan


Description Conduct the CLARiiON-device allocation and perform the host discovery work.

Task List Conduct CLARiiON Device Allocation and Host Discovery for Migration

Set up Open Migrator LM Migrations Work Plan


Description Set up for the Open Migrator LM migrations.

Task List Perform Set up of Open Migrator LM Migrations

Perform Set up of Open Migrator LM Migrations Task

If the EMC Open Migrator/LM software was not purchased by the customer, download the version required from the Web site.

Note: Remember that the EMC Open Migrator/LM software can be used as a tool for the data migration service for a customer without requiring the customer to purchase the software. You must remove the software entirely after the migration is complete.

Migrate system/boot partitions prior to the general data migration. This gives EMC the opportunity to ensure that the HBAs, drivers, and so on, are all configured correctly with the least effort required for fallback. Simultaneous migration of system/boot partitions and data migration increases the project risk.

For Windows environments, you must have administrative privileges to install the server package installation version of OM/LM. Administrative privileges are not required to run OM/LM or to install the client package installation version of OM/LM.

When installing OM/LM you need to select where you want your log files to reside. This is the only chance you have to choose where you want to store them unless you de-install


03/03/11


OM/LM and re-install the product. The default path displayed in the install dialog box is the system root volume.

Set up Open Migrator LM Swingframe Migrations Work Plan


Description Setup for the Open Migrator LM Swingframe migrations.

Task List Perform Set up of Open Migrator LM Swingframe Migrations

Perform Set up of Open Migrator LM Swingframe Migrations Task

If the EMC Open Migrator/LM software was not purchased by the customer, download the version required from the Web site.

Note: Remember that the EMC Open Migrator/LM software can be used as a tool for the data migration service for a customer without requiring the customer to purchase the software. You must remove the software entirely after the migration is complete.

Migrate the system/boot partitions prior to the general data migration. This gives EMC the opportunity to ensure that the HBAs, drivers, and so on, are all configured correctly with the least effort required for fallback. Simultaneous migration of system/boot partitions and data migration increases the project risk.

For Windows environments, you must have administrative privileges to install the server package installation version of OM/LM. Administrative privileges are not required to run OM/LM or to install the client package installation version of OM/LM.

When installing OM/LM you must select where you want your log files to reside. This is the only chance you have to choose where you want to store them unless you de-install OM/LM and re-install the product. The default path displayed in the install dialog box is the system root volume.


03/03/11


Execute Host-based Migration Cutover, Testing, and Cleanup Activity


Description Perform the actual migration cutover work, any necessary testing after the migration, and

the cleanup of any migration tools that must be removed.

Execute Open Migrator LM Migration, Testing, and Cutover Work Plan


Description Execution the migration with Open Migrator LM.

Task List Perform Execution of Open Migrator LM Migration, Testing, and Cutover

Perform Execution of Open Migrator LM Migration, Testing, and Cutover Task

In this step, you physically and/or logically migrate assets from the current to the planned environment. After you complete the migration, you perform the tests documented in the Test Plan which is included in this TS Service Kit.

OM/LM for Windows Implementation Tips

The following list provides implementation tips for an OM/LM for Windows migration:

OM/LM requires a system reboot to install and de-install the filter driver. Plan this to coincide with other system reboot activity if possible (for example, HBA, PowerPath, installations, and so on).

The filter driver must be attached to each volume before migration. Depending on the state of the volume, OM/LM may require a reboot. If a reboot is necessary, OM/LM informs the user through a dialog box.

EMC Engineering strongly recommends that you perform a reboot after attaching the filter to all source and target volumes before you start the migration.

If the customer wants to abort the migration while it in progress, there is a cancel option for OM/LM that will stop the migration.

Note: You must format the destination volume before you reboot the system! If you do not format the destination volume, Windows will have to verify the entire volume during system initialization. This might take several hours, depending on the number of files and size of the volume.

In the event that a volume has already been migrated and the customer wants to fall back to the original configuration after system reboot — applications must be halted. Using Disk Manager, you can change the drive letter of the migrated volume to a temporary drive letter. Then you can re-assign the original disk volume to its original drive letter assignment.

Do not use Terminal Server sessions to operate the OM/LM Microsoft Management Console (MMC).

You must “Rescan disks and volumes” for disk changes any time you launch OM/LM MMC. This will ensure that OM/LM for Windows has the correct drive information. If


03/03/11



03/03/11

you close out of the OM/LM MMC while a migration is going and later open the OM/LM MMC you must do a “Rescan disks and volumes” in order to get the correct migration percentages.

When performing a migration with OM/LM for Windows on a newly created volume you will still receive a dialog box informing you that the destination is not empty. You must ensure that you have selected the correct destination volume. You will receive this error since there are hidden files that are created when formatting a volume in Windows.

It is important to hide columns in the OM/LM MMC before you run Parallel migrations. This improves performance.

OM/LM for UNIX/Linux Implementation Tips

The following list provides implementation tips for an OM/LM for UNIX migration:

Use sessions to group together devices that logically go together (like databases and logs).

If large amounts of devices must be migrated, consider dividing them up into sessions and running them serially (see more information on this in the “Planning and Design: Best Practices” section of this document).

Use the standard location/commands to find and view necessary logs on a UNIX host:

OM/LM Logs: /var/EMCom/log

System Logs: Sun: /var/adm/messages

System Logs: HP: /var/adm/syslog/syslog.log

System Logs: AIX: errpt –a

System Logs: Linux /var/log

The CLI operands -pause and -resume can be put in a cron job to pause a copy job during busy times and resume them during slow times (such as overnight).

The CLI operand –tune is used to change the ceiling rate, which can be done prior to migrations or dynamically (during them).

The CLI operand –restart should be used only after an error.

Note: After a reboot, OM/LM automatically runs and restarts any existing (unfinished) copy jobs.

You must deactivate sessions before uninstalling the product.

If you upgrade a Sun box from 32-bit to 64-bit, the bit is set at installation so you must do the following:

Remove OM/LM first

Migrate OS (32->64)

Delete leftover files under /etc/opt/EMCom/properties

Reinstall OM/LM after upgrade


Table 13 provides example CLI commands. Refer to the Open Migrator/LM CLI Product Guide for more details and more commands.

Table 13. Example CLI Commands

Example CLI Command Information

stormigrate activate –session <session_name>

Activates the session.

stormigrate copy –session <session_name>

Starts copying of the session.

stormigrate create –session <session_name> –file <filename>

Creates the session, using a file that lists all source and target devices pairs.

stormigrate query –session <session_name> -i 30

Monitoring command, running at 30 second intervals.

stormigrate tune –ceiling N Throttle maximum bandwidth used by OM/LM

N = MBs/second of sessions (default is 1)

Monitor data rate of sessions. stormigrate query –session omtest –i 30

symstat, iostat, sar, etc. as well

stormigrate tune –iosize N Used to change the transfer size used by OM/LM.

N = I/O transfer size in KBs (default is 64)

stormigrate verify –session <session_name> –i 30

Returns when copying is completed.

Execute Open Migrator LM Swingframe Migration, Testing, and Cutover Work Plan


Description Execute the Swingframe migration itself with Open Migrator LM.

Task List Perform Execution of Open Migrator LM Swingframe Migration, Testing, and

Cutover


03/03/11


Perform Execution of Open Migrator LM Swingframe Migration, Testing, and Cutover Task


OM/LM for Windows Implementation Tips

The following list provides implementation tips for an OM/LM for Windows migration:

OM/LM requires a system reboot to install and de-install the filter driver. Plan this to coincide with other system reboot activity if possible (for example, HBA, PowerPath, installations, and so on).

The filter driver must be attached to each volume before migration. Depending on the state of the volume, OM/LM may require a reboot. If a reboot is necessary, OM/LM informs the user through a dialog box.

EMC Engineering strongly recommends that you perform a reboot after attaching the filter to all source and target volumes before you start the migration.

If the customer wants to abort the migration while it in progress, there is a cancel option for OM/LM that will stop the migration.

Note: You must format the destination volume before you reboot the system! If you do not format the destination volume, Windows will have to verify the entire volume during system initialization. This might take several hours, depending on the number of files and size of the volume.

In the event that a volume has already been migrated and the customer wants to fall back to the original configuration after system reboot — applications must be halted. Using Disk Manager, you can change the drive letter of the migrated volume to a temporary drive letter. Then you can re-assign the original disk volume to its original drive letter assignment.

Do not use Terminal Server sessions to operate the OM/LM Microsoft Management Console (MMC).

You must “Rescan disks and volumes” for disk changes any time you launch OM/LM MMC. This will ensure that OM/LM for Windows has the correct drive information. If you close out of the OM/LM MMC while a migration is going and later open the OM/LM MMC you must do a “Rescan disks and volumes” in order to get the correct migration percentages.

When performing a migration with OM/LM for Windows on a newly created volume you will still receive a dialog box informing you that the destination is not empty. You must ensure that you have selected the correct destination volume. You will receive this error since there are hidden files that are created when formatting a volume in Windows.

It is important to hide columns in the OM/LM MMC before you run Parallel migrations. This improves performance.

OM/LM for UNIX/Linux Implementation Tips

The following list provides implementation tips for an OM/LM for UNIX migration:

Use sessions to group together devices that logically go together (like databases and logs).

If large amounts of devices must be migrated, consider dividing them up into sessions and running them serially (see more information on this in the “Planning and Design: Best Practices” section of this document).


03/03/11



03/03/11

Use the standard location/commands to find and view necessary logs on a UNIX host:

OM/LM Logs: /var/EMCom/log

System Logs: Sun: /var/adm/messages

System Logs: HP: /var/adm/syslog/syslog.log

System Logs: AIX: errpt –a

System Logs: Linux /var/log

The CLI operands -pause and -resume can be put in a cron job to pause a copy job during busy times and resume them during slow times (such as overnight).

The CLI operand –tune is used to change the ceiling rate, which can be done prior to migrations or dynamically (during them).

The CLI operand –restart should be used only after an error.

Note: After a reboot, OM/LM automatically runs and restarts any existing (unfinished) copy jobs.

You must deactivate sessions before uninstalling the product.

If you upgrade a Sun box from 32-bit to 64-bit, the bit is set at installation so you must do the following:

Remove OM/LM first

Migrate OS (32->64)

Delete leftover files under /etc/opt/EMCom/properties

Reinstall OM/LM after upgrade

Table 14 provides example CLI commands. Refer to the Open Migrator/LM CLI Product Guide for more details and more commands.

Table 14. Example CLI Commands


stormigrate activate –session <session_name>

Activates the session.

stormigrate copy –session <session_name>

Starts copying of the session.

stormigrate create –session <session_name> –file <filename>

Creates the session, using a file that lists all source and target devices pairs.

stormigrate query –session <session_name> -i 30

Monitoring command, running at 30 second intervals.



03/03/11


stormigrate tune –ceiling N Throttle maximum bandwidth used by OM/LM

N = MBs/second of sessions (default is 1)

Monitor data rate of sessions. stormigrate query –session omtest –i 30

symstat, iostat, sar, etc. as well

stormigrate tune –iosize N Used to change the transfer size used by OM/LM.

N = I/O transfer size in KBs (default is 64)

stormigrate verify –session <session_name> –i 30

Returns when copying is completed.


Execute Migration Cutover, Testing, and Cleanup (User-determined Events) Activity

Role Project Manager / Solutions Architect / Implementation Specialist / MSS

Description Perform the actual migration cutover work, any necessary testing after the migration, and

cleanup of any migration tools that must be removed. The user determines the effort based on the number of data migration events entered, the roles chosen and the average hours per role by event.

Perform a PM Event-window Implementation for Data Migration Work Plan

Role Project Manager

Description This work plan covers all of the PM effort for the migration events. This is used in

conjunction with the number of event windows. All of this is manually determined by a local SME.

Task List Conduct PM Event-window Implementation

Conduct PM Event-window Implementation Task


Perform an SA Event-window Implementation for Data Migration Work Plan


Description This work plan covers all of the SA effort for the migration events. This is used in


Task List Conduct SA Event-window Implementation

Conduct SA Event-window Implementation Task



03/03/11


Perform an IS Event-window Implementation for Data Migration Work Plan


Description This work plan covers all of the IS effort for the migration events. This is used in


Task List Conduct IS Event-window Implementation

Conduct IS Event-window Implementation Task


Perform an MSS Event-window Implementation for Data Migration Work Plan

Role MSS

Description This work plan covers all of the MSS effort for the migration events. This is used in


Task List Conduct MSS Event-window Implementation

Conduct MSS Event-window Implementation Task



03/03/11


De-install Hardware Activity

Role Implementation Specialist / MSS

Description De-install and removal of SAN equipment as part of a technology refresh or replacement.

Power System Down, Remove Cables, and De-install Work Plan


Description Verify that all I/O is stopped on the equipment and data is stored on another location.

Powerdown and remove all cables from system cabinet/device.

Task List Verify that All Data is Removed and/or Backed Up (Storage Systems Only)

Verify All I/O is Stopped on the Devices

Power Down Systems

Remove All System Cables

Remove from System Rack (if Rack is to Remain)

Verify Serial Numbers of Removed Hardware

Verify that All Data is Removed and/or Backed Up (Storage Systems Only) Task

In addition, the audit report indicates any potential clean-up work that is required. This work includes:

Deleting old zones.

Unmasking and unmapping of devices.

Deletion of devices.

Decommissioning of asset(s).


03/03/11


Crate and Ship Equipment Activity


Description Coordinate the crating and shipping the EMC equipment to customer sites after de-

installation by EMC.

Crate Equipment Work Plan


Description Verify that the equipment is ready for packaging and prepare shipping containers. Pack

equipment and secure for shipping.

Task List Obtain and Verify Hardware Shipping Containers

Verify Equipment Status Ready for Packaging

Pack and Secure Equipment

Ship Equipment Work Plan


Description Verify that the equipment is ready for packaging and prepare shipping containers. Pack

equipment and secure for shipping.

Task List Verify Shipping Details

Contact with Shipping Partner or Vendor

Verify Equipment Status Ready for Shipping

Review Partner or Vendor Truck Loading


03/03/11


Finalize Project Deliverables by Solutions Architect and Implementation Specialist Activity

Role Solutions Architect and Implementation Specialist

Description Complete and submit an as-built Configuration Guide to CSI, close the call, review the

test results of the Test Plan with the customer, and deliver the functional overview (if included).

Complete Final Configuration Guide and Test Plan Work Plan

Role Solutions Architect and Implementation Specialist

Description Complete the Configuration Guide and Test Plan, and deliver the documents to the

customer.

Task List Provide final copy of the Configuration Guide to the customer.

Run any configuration utilities to gather final configuration information. Import the configuration information into the final project documentation. Finalize all project documentation.

Submit configuration to CSI and close the CSI call. Provide a copy of the completed Test Plan to the customer.

Deliver Functional Overview Work Plan


Description Review basic operations with the customer and provide an overview of the implemented

technologies.

Task List Review basic operations, configuration, and extended features that are part of the

implementation.


03/03/11



03/03/11

Appendix A: Glossary of Terms – Essential Terms and Concepts

This glossary contains essential terms and concepts for Open Migrator/LM technology. For more terms and definitions, please refer to the EMC Open Migrator/LM Product Guide and documentation on Powerlink.

Refer to Table 15 for definitions of terms used in this document.

Table 15. Glossary of Terms

Term Definition

activate UNIX only. Activates an OM/LM session.

concurrent migrations

Windows only: A maximum of ten migrations of source/target volume pairs may be executed at one time. You can adjust the number of concurrent migrations from the GUI by right-clicking the menu on the computer node. The default maximum number of migrations is five.

compare UNIX only: Compares source and target volume data in an activated session.

create UNIX only. Creates a OM/LM session

filter driver Windows only: Driver attached to devices to be migrated (both source and target). It must be done prior to the migration and must be removed after it is completed.

migration persistence

Windows only: OM/LM persists migrations across system reboots.

MMC

Windows only: The Microsoft Management Console (MMC) snap-in user interface that OM/LM uses for its GUI.

query UNIX only. Query of the session produces detailed information on the OM/LM copy session.

Remote client migrations

Windows only: You can launch, monitor, and verify migrations from the remote system. You can configure the server to allow launch and access privileges to desired security principals that are able to access the server from a remote client.

\restart UNIX only: Restarts a failed session.

resume UNIX only: Resumes a paused session and begins the operation from where it was paused.

serial One after the other.

session UNIX only: A grouping of source/target pair devices to be migrated. Allows for ease of management.

summary UNIX only. Summary provides status information on the OM/LM copy session.

tune UNIX only: Tunes session performance at the kernel level. The bandwidth ceiling is set with this operand.

verify UNIX only: Verifies the existing state of a given session.



03/03/11

Appendix B: Applications with Open Handles

You can log what applications have open handles to the source and target volumes. The best practice would ideally have cluster services or other application services disabled for the post-migration reboot in which mount points are transferred; however, that is not always possible. When cluster services or other application services have not been disabled, an issue can occur where another service starts before Open Migrator/LM and prevents the mountpoint transfer. Determining what applications have open handles allows you to determine which services must be disabled to allow the mountpoint transfer to occur. Also, refer to EMC Knowledgebase solution emc134844.