PG Omlm Data Migration Pscusprdsvc

EMC Corporation
Technology Solutions Kit
EMC Data Migration Solution for Open Migrator/LM Practitioners Guide

Date: March 3, 2011
EMC Corporation 176 South Street Hopkinton, MA 01748
Q111
EMC Corporation, Technology Solutions
T.S. Service Kit: Practitioners Guide
EMC Data Migration Solution for Open Migrator/LM 03/03/11
Page 2
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
EMC Data Migration Solution for Open Migrator/LM 03/03/11 Page 3
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
Page 4
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
Page 5
Appendix B: Applications with Open Handles ....................................................... 82
List of Figures
Figure 1. Figure 2. Figure 3. Figure 4. Figure 5. EMC Data Migration Framework ........................................................... 8 Data Migration Planning and Design.................................................... 9 Data Migration Implementation and Testing ..................................... 10 OM/LM Data Migration Sample Topology .......................................... 13 WinSCP directory location .................................................................. 24
List of Tables
Table 1. Table 2. Table 3. Table 4. Table 5. Table 6. Table 7. Table 8. Table 9. Table 10. Table 11. Table 12. Table 13. Table 14. Table 15. Open Migrator/LM Performance Impact ................................................ 39 States of Open Migrator/LM Software During a Data Migration Process .................................................................................................... 40 Capabilities and Considerations ............................................................ 40 Restrictions and Limitations .................................................................. 42 Best Practices.......................................................................................... 43 Common Risks ........................................................................................ 46 Open Migrator/LM Performance Impact ................................................ 49 States of Open Migrator/LM Software During a Data Migration Process .................................................................................................... 50 Capabilities and Considerations ............................................................ 50 Restrictions and Limitations ............................................................... 52 Best Practices ...................................................................................... 54 Common Risks ..................................................................................... 56 Example CLI Commands ..................................................................... 72 Example CLI Commands ..................................................................... 74 Glossary of Terms ............................................................................... 81
Page 6
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. 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
Overview
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 customers 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 customers business, operational, and technical requirements. Planning After a thorough analysis of the customers 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 customers 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.
Page 8
Figure 2 provides a simplified diagram of a data migration planning phase.
Figure 2. Data Migration Planning and Design
Page 9
Figure 3 is a simplified diagram of a data migration implementation phase.
Figure 3. Data Migration Implementation and Testing

During implementation, EMC Technology Solutions works closely with the customers staff and other EMC account team members to ensure minimal disruption to customer computing operations. The disruption takes place within the customers 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-andwrite 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
Page 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.
Page 12
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 customers data from directattached 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)
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) Prerequisites and 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 Assumptions working with. There are no other prerequisites for the installation of OM/LM. 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.
Page 14
Reference Documentation and Resources

About the Links Links listed in this topic are functional as of this documents 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 TSServicesMaterialSupport@emc.com. 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
Powerlink
Page 15
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
Page 16
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
Data Collection Appliance 1.0 Release Notes Data Collection Appliance 1.0 Target Host Requirements Guide Data Collection Appliance 1.0 User Notes Data Collection Appliance 1.0 Technical Notes Host Validation for Data Migration 1.0 Distributed Deployment Guide Host Validation for Data Migration 1.0 Pre Installation Checklist Host Validation for Data Migration 1.0 Stand-alone Deployment Guide Host Validation for Data Migration 1.0 Data Collection Appliance Calculator
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
Page 17
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
Page 18
Perform GRAB Collection using the Data Collection Appliance for EMC Host Validation for Data Migration Activity
Role Description Implementation Specialist 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
Role Description Implementation Specialist Validate that the customer's ESX sever supports installation of the Data Collection Appliance tool and collector. Verify ESX Server has MS Windows 2008 Server VM Created 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:
Task List Verify ESX Server has MS Windows 2008 Server VM Created Task
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
Note: Note:
Ensure that the browser accepts cookies and pop-up blockers are disabled. 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
Role Description Implementation Specialist Install the Data Collection Appliance tool on the first Virtual Machine on the customer's ESX Server. Install the Data Collection Appliance on VM1 on ESX Host 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 serverone VM for the Data Collection Appliance itself and another Windows Server 2008 for the Collector. The Data Collection Appliance discovers the customers 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 customers 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.
Task List Install the Data Collection Appliance on VM1 on ESX Host Task
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.
Page 20
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
Role Description Implementation Specialist Perform the setup work required for the first Virtual Machine, where the Data Collection Appliance is installed. 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 ! 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
Task List
Page 21
Configuring the Appliance Role Task
This task takes about 5+ minutes after you choose the role to complete. 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
Perform Data Collection Appliance Post-Installation Steps Work Plan

Role Description Implementation Specialist Perform the post-installation steps for the Data Collection Appliance on the first Virtual Machine. 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. 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 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). 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
Task List
Page 22
Set Up the Data Collection Appliance on Virtual Machine 2 (VM2) Work Plan
Role Description Implementation Specialist 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). Set Up the Data Collection Appliance Collector on VM2 on ESX Host The Windows collector unique ID is the same identifier that was defined on the aggregator side for WMI discovery. The default value is 200. 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
Task List Set Up the Data Collection Appliance Collector on VM2 on ESX Host Task
Page 23
Configure the Data Collection Appliance Virtual Machines Work Plan

Role Description Implementation Specialist 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). 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:
Task List
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
Page 24
Performing Grab Script Work on the Data Collection Appliance Work Plan
Role Description Implementation Specialist 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. 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 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 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. 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 Saving the locations of the GRAB script and output will restart the Collector. 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
Task List
Configure GRAB Directories by using GUI Task
Create an IP Discovery Policy for EMC GRAB Hosts for Data Collection Appliance Work Plan
Role Description Implementation Specialist Creation an IP Discovery policy, which uses TCP for scanning to find hosts in the environment, and initially populates the Data Collection Appliance database.
Page 25
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.
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 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.
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
Create Groups for Host Discovery by Data Collection Appliance Work Plan
Role Description Task List Create Groups by using IP Addresses or Subnets Task Implementation Specialist Create groups for host discovery with the Data Collection Appliance. Create Groups by using IP Addresses or Subnets Click on Data Collection Appliance Settings to open the window to get to Groups. 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
Page 26
Initiate Detail Discovery Policy on the Data Collection Appliance Work Plan
Role Description Implementation Specialist 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. 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). 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 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. 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 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. 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
Task List
Run the Policy Task
Page 27
Processing the Data Collection Appliance Discovery Results (collecting the GRAB Output Files) Work Plan
Role Description Implementation Specialist Collect the GRAB Output files. If there are a large number of hosts, then EMC personnel can return at a specified later time. Collect Results 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. 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
Task List Collect Results Task
Remove Data Collection Appliance from the ESX Server Work Plan
Role Description Implementation Specialist Remove the Data Collection Appliance from the two Virtual Machines on the customer's ESX Server. Remove Data Collection Appliance from the Customer Environment 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 customers ESX server environment.
Task List Remove Data Collection Appliance from the Customer Environment Task
Page 28
Discover and Correlate the Environment for Data Migrations Activity

Role Description Solutions Architect / Implementation Specialist 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 Description Solutions Architect Provide a basic review of the customer-provided information to verify that it provides the proper information for completing analysis. Perform Review of Customer Provided Data Collection Information
Task List
Manually Collect Host and Storage Data Work Plan

Role Description Solutions Architect / Implementation Specialist Perform manual collection of data in environments that lack installed tools and collection methods. Perform Manual Collection of Host and Storage Data
Task List
Collect Host Information (GRABs-Reports) Work Plan

Role Description Task List Perform Collection of Host Information Task Implementation Specialist Collect host data by using GRABs/Reports. Perform Collection of Host Information 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.
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

Role Description Implementation Specialist Collect switch and director configuration information on fabrics, zones, security, and administration requirements. Perform Collection Switch Configuration Data
Task List
Collect CLARiiON Storage Data Work Plan

Role Description Task List Implementation Specialist Collect CLARiiON storage data (performed by EMC). Perform Collection of CLARiiON Storage Data
Collect Symmetrix Storage Data Work Plan

Role Description Task List Implementation Specialist Collect Symmetrix storage data (performed by EMC). Perform Collection of Symmetrix Storage Data
Collect Non-EMC Storage Data Work Plan

Role Description Task List Solutions Architect Collect non-EMC storage data (performed by EMC). Perform Collection Non-EMC Storage Data
Page 30
Process GRABs through HEAT using HEAT-IT Work Plan

Role Description Task List Solutions Architect / Implementation Specialist Process customer data by processing it through the HEAT tool for a data migration. Perform Processing of GRABs through HEAT using HEAT-IT
Process Switch and Director Data through SWAT Work Plan

Role Description Task List Solutions Architect Process switch data through the SWAT tool. Perform Processing of Switch and Director Data through SWAT
Process CLARiiON-related HEAT-Swat HTML through SAN Summary Work Plan

Role Description Task List Solutions Architect Process CLARiiON information through EMC tools like HEAT. 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
Role Description Solutions Architect 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. Perform Processing of Symmetrix-related HEAT/SWAT HTML through EMP/SAN Summary
Task List
Page 31
Perform Processing of Symmetrixrelated 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
Role Description Task List Solutions Architect Process non-EMC storage information. Perform Processing Non-EMC Storage Array Related HEAT/SWAT HTML through SAN Summary
Page 32
Perform Environment Analysis and Validation for Data Migration Activity

Role Description Solutions Architect 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
Role Description Task List Solutions Architect Perform validation checks on standard hosts and virtual machines using e-Lab data. Conduct e-Lab Checks for Current STD Hosts and Virtual Machines
Perform e-Lab Checks for Current Switches Work Plan

Role Description Task List Solutions Architect Perform validation checks on SAN switches using e-Lab data. Conduct e-Lab Checks for Current Switches
Review Current Symmetrix-related EMP/SAN Summary Reports Work Plan

Role Description Task List Solutions Architect Review information gathered on any Symmetrix systems in the environment. Perform Review of Current Symmetrix-related EMP/SAN Summary Reports
Page 33
Review Current CLARiiON-related EMP/SAN Summary Reports Work Plan

Role Description Task List Solutions Architect Review information gathered on any CLARiiONs in the environment. Perform Review of Current CLARiiON-related EMP/SAN Summary Reports
Review the Current Analysis Findings with the Customer Work Plan
Role Description Task List Perform Review of the Current Analysis Findings with the Customer Task Solutions Architect Review the analysis findings with the customer. Perform Review of the Current Analysis Findings with the Customer 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.
Page 34
Plan and Build Out Proposed Environment for Data Migration Activity
Role Description Solutions Architect 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

Role Description Task List Solutions Architect Create a Switch/SAN layout of the customer environment with Symmetrix. Perform the Build Out of the Switch/SAN View in a Symmetrix Environment
Build Out Switch/SAN View in a CLARiiON Environment Work Plan

Role Description Task List Solutions Architect Create a Switch/SAN layout of the customer environment with CLARiiON. Perform the Build Out of the Switch/SAN View in a CLARiiON Environment
Build-out the Symmetrix Storage View of the Environment Work Plan

Role Description Task List Perform the Build Out of the Symmetrix Storage View of the Environment Task Solutions Architect Create a storage layout of the customer environment with Symmetrix. Perform the Build Out of the Symmetrix Storage View of the Environment 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.
Page 35
Build-out the CLARiiON Storage View of the Environment Work Plan

Role Description Task List Solutions Architect Create a storage layout of the customer environment with CLARiiON. Perform the Build Out of the CLARiiON Storage View of the Environment
Page 36
Perform Host-based Migration Design and Documentation Activity

Role Description Solutions Architect Define and document the host-based data migration procedures.
Define and Document Data Migration Procedures Work Plan

Role Description Solutions Architect Perform the initial data migration procedure design and develop the required documentation. Conduct the Definition and Documentation of Data Migration Procedures EMC Technology Solutions works with the customers staff to plan and design a complete solution based on the customers requirements. This solution identifies sourceto-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
Task List Conduct the Definition and Documentation of Data Migration Procedures Task
Page 37
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 EMCs 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

Role Description Task List Conduct the Design and Documentation of Open Migrator LM Migration Task Solutions Architect Design and document the migration using Open Migrator/LM. Conduct the Design and Documentation of Open Migrator LM Migration When using EMC OM/LM as a data migration tool, the golden rule to follow is: Do not impact the applications 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 applications 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
Windows
Bandwidth Usage
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. 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.
UNIX/Linux
Page 39
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
Pass Through
Version
WINDOWS UNIX/Linux
Description for Each Version

Driver is attached to the source and target devices, but not copying. Kernel module loaded, sessions active, but not copying. Migration started (copying old Source data and mirroring new Source data to Target). Sessions started (copying old Source data and mirroring new Source data to Target comparable to a dd process/operation on a UNIX host). Data copying completed, but still mirroring new Source data to Targets. Sessions done (copying, but still mirroring new Source data to Targets).
Migration
WINDOWS
UNIX/Linux
Mirroring
WINDOWS
UNIX/Linux
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
Capabilities and Considerations
Data migration to a different volume type
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. 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. Windows NT file system (NTFS) can be migrated from smaller to larger volumes, or between equalsized volumes. OM/LM adjusts the NTFS file systems automatically for the target volumes.
UNIX/Linux
Data migration to a different volume size; target volume file system extension
Windows
Page 40

Data migration to a different volume size
Version
Description
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. Both source and target volumes remain synchronized until the next restart. OM/LM does not support migration of FAT and FAT32 file systems. Both the source and target volumes remain synchronized until the session has been deactivated. 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. 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). 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.
Source and Target synchronization FAT and FAT32 file systems Source and Target synchronization Connectivity options
Windows
Windows
UNIX/Linux
UNIX/Linux
Session
UNIX/Linux
Data synchronization
UNIX/Linux
Page 41
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
Restrictions and Limitations
Ten concurrent migrations
Version
Impact
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 rightclick menu on the computer node. The default maximum number of migrations is five. 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. There are no dependencies on the versions of the EMC Enginuity operating environment. There are no dependencies on CLARiiON Navisphere software or FLARE code. This is not supported at current release of OM/LM. This is not supported at current release of OM/LM.
No physical limit on concurrent migrations
UNIX/Linux
Symmetrix Support (older Symmetrix, DMX, V-Max) CLARiiON support Celerra support Boot disk or system volume (root file system devices) migration Automatic volume expansion Migrations for Microsoft Cluster Servers (MSCS) Migrations for cluster host environments PowerPath support
Windows
Windows
All All
All
This is not supported at current release of OM/LM.
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 are not supported at current release of OM/LM. If you plan to use OM/LM with PowerPath, PowerPath must be at version 3.0.2 or later. This is not supported in the current release of OM/LM. 1 MB This can be changed before or during migration (dynamic) Note: The default is way too low, so you must change
UNIX/Linux
Windows
Microsoft Terminal Server Default rate (ceiling available bandwidth for
Windows UNIX/Linux
Page 42

OM/LM)
Version
Impact
this AFTER you determine available bandwidth for OM/LM. Best Practices, below, for more details.
Default I/O size Unmount target before migration
UNIX/Linux UNIX/Linux
64 kb Not dynamic, must be changed prior to migration. 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
Pilot or test migration
Version
All
Description
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. 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. 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.
Do the migration at the highest layer
UNIX/Linux
Total number of sessions vs. total number of devices
UNIX/Linux
Page 43
Best Practices
dd test (for available bandwidth for OM/LM)
Version
UNIX/Linux
Description
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. 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.
Offline migration
UNIX/Linux
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 customers 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.
Page 44
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
Record the bandwidth used. Take 75% of that bandwidth number. The dd command performed a Read only. 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 customers 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.
Page 45
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
Another host has write access to the target volume (shared volumes between hosts) Customer does not want to upgrade operating system to current service pack
Impact
Mitigation Options
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. 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. 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). 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. 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. Two Reads and two Writes for each transaction.
Potential issues with compatibility of OM/LM with the OS
Customer unwilling to install software on production server
Migration requires OM/LM to be installed on host with storage to be migrated.
Minimum of two system reboots required (OM/LM for Windows only)
Host I/O disruption during 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.
Running the compare feature (UNIX only)
Doubles migration time
Page 46

Using the Large Migrations procedure for running multiple sessions serially
Impact
If you migrate sets of data (like databases and logs), you want to make certain that all of this data is consistent.
Mitigation Options
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. 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).
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.
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 customers 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 customers 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.
Page 48
Design and Document Open Migrator LM Swingframe Migration Work Plan

Role Description Task List Solutions Architect Design and document all Open Migrator LM migration methods. Conduct the Design and Documentation of Open Migrator LM Swingframe Migration When using EMC OM/LM as a data migration tool, the golden rule to follow is: Do not impact the applications 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 applications 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
Windows
Conduct the Design and Documentation of Open Migrator LM Swingframe Migration Task
Bandwidth Usage
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. 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.
UNIX/Linux
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.
Table 8. States of Open Migrator/LM Software During a Data Migration Process

State
Pass Through
Version
WINDOWS UNIX/Linux
Description for Each Version

Driver is attached to the source and target devices, but not copying. Kernel module loaded, sessions active, but not copying. Migration started (copying old Source data and mirroring new Source data to Target). Sessions started (copying old Source data and mirroring new Source data to Target comparable to a dd process/operation on a UNIX host). Data copying completed, but still mirroring new Source data to Targets. Sessions done (copying, but still mirroring new Source data to Targets).
Migration
WINDOWS
UNIX/Linux
Mirroring
WINDOWS
UNIX/Linux
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 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. 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. Windows NT file system (NTFS) can be migrated from smaller to larger volumes, or between equalsized volumes. OM/LM adjusts the NTFS file systems automatically for the target volumes. 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.
UNIX/Linux
Data migration to a different volume size; target volume file system extension Data migration to a different volume size
Windows
UNIX/Linux
Page 50

Source and Target synchronization FAT and FAT32 file systems Source and Target synchronization Connectivity options
Version
Description
Windows
Both source and target volumes remain synchronized until the next restart. OM/LM does not support migration of FAT and FAT32 file systems. Both the source and target volumes remain synchronized until the session has been deactivated. 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. 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). 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.
Windows
UNIX/Linux
UNIX/Linux
Session
UNIX/Linux
Data synchronization
UNIX/Linux
Page 51
Restrictions and Limitations 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
Ten concurrent migrations
Version
Impact
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 rightclick menu on the computer node. The default maximum number of migrations is five. 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. There are no dependencies on the versions of the EMC Enginuity operating environment. There are no dependencies on CLARiiON Navisphere software or FLARE code. This is not supported at current release of OM/LM. This is not supported at current release of OM/LM.
No physical limit on concurrent migrations
UNIX/Linux
Symmetrix support (older Symmetrix, DMX, V-Max) CLARiiON support
Windows
Windows
Celerra support Boot disk or system volume (root file system devices) migration Automatic volume expansion Migrations for Microsoft Cluster Servers (MSCS) Migrations for cluster host environments PowerPath support
All All
All
This is not supported at current release of OM/LM.
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 are not supported at current release of OM/LM. If you plan to use OM/LM with PowerPath, PowerPath must be at version 3.0.2 or later. This is not supported in the current release of OM/LM. 1 MB This can be changed before or during migration (dynamic) Note: The default is way too low, so you must change
UNIX/Linux
Windows
Microsoft Terminal Server Default rate (ceiling available bandwidth for
Windows UNIX/Linux
Page 52

OM/LM)
Version
Impact
this AFTER you determine available bandwidth for OM/LM. Note: Best Practices for more details.
Default I/O size Unmount target before migration
UNIX/Linux UNIX/Linux
64 kb Not dynamic, must be changed prior to migration. You cannot activate or copy if target device is mounted.
Page 53
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
Best Practices
Pilot or Test Migration
Version
All
Description
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. 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. 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 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. 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.
Do the migration at the highest layer
UNIX/Linux
Total Number of Sessions vs. Total Number of Devices
UNIX/Linux
dd test (for available bandwidth for OM/LM)
UNIX/Linux
Offline migration
UNIX/Linux
Page 54
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 customers 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. 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
Record the bandwidth used. Take 75% of that bandwidth number.
Page 55
The dd command performed a Read only. 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 customers 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). Customer does not want to upgrade operating system to current service pack
Impact
Mitigation Options
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. 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.
Potential issues with compatibility of OM/LM with the OS
Page 56

Customer unwilling to install software on production server
Impact
Mitigation Options
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). 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. 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. Two Reads and two Writes for each transaction. 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. 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).
Minimum of two system reboots required (OM/LM for Windows only)
Host I/O disruption during 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. Doubles migration time If you migrate sets of data (like databases and logs), you want to make certain that all of this data is consistent.
Running the compare feature (UNIX only). Using the Large Migrations procedure for running multiple sessions serially
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.
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
Page 57
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 customers 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 customers 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.
Page 58
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.
Page 59
Provide EMC On-site Support Only for Customer-driven Host-based Migrations Activity
Role Description Implementation Specialist 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
Role Description Implementation Specialist 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). Provide Support for Customer-Driven Open Migrator LM Migrations On-Site
Task List
Provide On-site Support Only During Customer-driven Open Migrator LM Swingframe Migrations Work Plan
Role Description Implementation Specialist 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). Provide Support for Customer-Driven Open Migrator LM Swingframe Migrations OnSite
Task List
Page 60
Perform Additional Collection and Validation Activity

Role Description Solution Architect / Implementation Specialist 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

Role Description Solutions Architect Review the customer-provided information to verify that it meets proper analysis requirements. Perform Review of Additional Customer-provided Data Collection Information
Task List
Manually Collect Additional Host and Storage Data Work Plan

Role Description Task List Solutions Architect / Implementation Specialist Manually collect data in environments that lack installed tools and collection methods. Perform Manual Collection of Additional Host and Storage Data
Collect Additional Host Information (GRABs-Reports) Work Plan

Role Description Task List Perform Collection of Additional Host Information Task Implementation Specialist Collect additional host and storage data using GRABs/Reports (performed by EMC). Perform Collection of Additional Host Information 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.
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

Role Description Implementation Specialist Collect additional switch/director configuration information on fabrics, zones, security, and administration requirements. Perform Collection of Additional Switch Configuration Data
Task List
Collect Additional CLARiiON Storage Data Work Plan

Role Description Task List Implementation Specialist Collect additional CLARiiON storage data (performed by EMC). Perform Collection Additional CLARiiON Storage Data
Collect Additional Symmetrix Storage Data Work Plan

Role Description Task List Implementation Specialist Collect additional Symmetrix storage data (performed by EMC). Perform Collection Additional Symmetrix Storage Data
Page 62
Collect Additional Non-EMC Storage Data Work Plan

Role Description Task List Solutions Architect Collect additional non-EMC storage data (performed by EMC). Perform Collection Additional Non-EMC Storage Data
Process Additional GRABs through HEAT using HEAT-IT Work Plan

Role Description Task List Solutions Architect / Implementation Specialist Process additional customer data through the HEAT tool for a data migration. Conduct Processing of Additional GRABs through HEAT using HEAT-IT
Process Additional Switch and Director Data through SWAT Work Plan
Role Description Task List Implementation Specialist Process additional switch data through the SWAT tool (performed by EMC). 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
Role Description Task List Implementation Specialist Process additional CLARiiON information through EMC tools like HEAT. Conduct Processing of Additional CLARiiON-related HEAT/SWAT HTML through SAN Summary
Page 63
Process Additional Symmetrix-related HEAT/SWAT HTML through EMP/SAN Summary for Data Migrations Work Plan
Role Description Implementation Specialist 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. Conduct Processing of Additional Symmetrix-related HEAT/SWAT HTML through EMP/SAN Summary 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.
Task List
Perform Processing of Additional Symmetrixrelated HEAT/SWAT HTML through EMP/SAN Summary Task
Process Additional Non-EMC Storage Array Related HEAT/SWAT HTML through SAN Summary Work Plan
Role Description Task List Implementation Specialist Process additional non-EMC storage information. Conduct Processing of Additional Non-EMC Storage Array Related HEAT/SWAT HTML through SAN Summary
Page 64
Perform Pre-migration Planning for Host-based Migrations Activity

Role Description Solutions Architect / Implementation Specialist 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
Role Description Task List Solutions Architect Build out the step-by-step procedures to implement an Open Migrator LM migration. Perform the Building of Data Migration Cadence (Step-by-Step) Procedures for Open Migrator LM Migrations 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.
Perform the Building of Data Migration Cadence (Stepby-Step) Procedures for Open Migrator LM Migrations Task
Build Data Migration Cadence (Step-by-Step) Procedures for Open Migrator LM Swingframe Migrations Work Plan
Role Description Solutions Architect Build out the step-by-step procedures to implement an Open Migrator LM Swingframe migration. Perform the Building of Data Migration Cadence (Step-by-Step) Procedures for Open Migrator LM Swingframe Migrations
Task List
Page 65
Perform the Building of Data Migration Cadence (Stepby-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

Role Description Task List Solutions Architect / Implementation Specialist Conduct a pre-implementation checkpoint for an Open Migrator LM migration. Perform Pre-implementation Checkpoint for Open Migrator LM Migrations
Conduct Pre-implementation Checkpoint for Open Migrator LM Swingframe Migrations Work Plan
Role Description Solutions Architect / Implementation Specialist Conduct a checkpoint for pre-implementation for an Open Migrator LM Swingframe migration. Perform Pre-implementation Checkpoint for Open Migrator LM Swingframe Migrations
Task List
Perform Test Migrations on Hosts/Clusters Prior to Migration Cutover Date Work Plan
Role Description Task List Solutions Architect / Implementation Specialist Perform any test migrations prior to the actual migration. Conduct Test Migrations on Hosts/Clusters Prior to Migration Cutover Date
Page 66
Perform Event Window Host-based Migration Planning Activity

Role Description Solutions Architect / Implementation Specialist 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.
Perform Pre-migration Review of Source Hosts (Migration Hosts) Work Plan

Role Description Task List Solutions Architect / Implementation Specialist Do a pre-migration review of the source hosts used for the migration Conduct Pre-migration Review of Source Hosts (Migration Hosts)
Conduct PreDuring planning for event window migration, confirm that any remediation required to migration hosts, storage, or other assets involved in migration are completed. Confirm that any Review of Source infrastructural requirements such as power and connectivity are satisfied. Hosts (Migration Hosts) Task
Perform Pre-migration Review of Target Hosts (New Hosts) Work Plan

Role Description Task List Solutions Architect / Implementation Specialist Do a pre-migration review of the target hosts used for a remote migration. Conduct Pre-migration Review of Target Hosts (New Hosts)
Perform Switch Configuration Work -- Fabrics, Zoning, Zonesets -- for Migration Work Plan
Role Description Task List Implementation Specialist Configure the switch(es), including zoning, zonesets, and fabrics. Conduct Switch Configuration Work -- Fabrics, Zoning, Zonesets -- for Migration
Page 67
Perform Symmetrix Device Allocation and Host Discovery for Migration Work Plan
Role Description Task List Implementation Specialist Conduct the Symmetrix-device allocation and perform the host discovery work. Conduct Symmetrix Device Allocation and Host Discovery for Migration
Perform CLARiiON LUN Allocation and Host Discovery for Migration Work Plan
Role Description Task List Implementation Specialist Conduct the CLARiiON-device allocation and perform the host discovery work. Conduct CLARiiON Device Allocation and Host Discovery for Migration
Set up Open Migrator LM Migrations Work Plan

Role Description Task List Perform Set up of Open Migrator LM Migrations Task Solutions Architect / Implementation Specialist Set up for the Open Migrator LM migrations. Perform Set up of Open Migrator LM Migrations 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
Page 68
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

Role Description Task List Perform Set up of Open Migrator LM Swingframe Migrations Task Solutions Architect / Implementation Specialist Setup for the Open Migrator LM Swingframe migrations. Perform Set up of Open Migrator LM Swingframe Migrations 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.
Page 69
Execute Host-based Migration Cutover, Testing, and Cleanup Activity

Role Description Solutions Architect / Implementation Specialist 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

Role Description Task List Perform Execution of Open Migrator LM Migration, Testing, and Cutover Task Solutions Architect / Implementation Specialist Execution the migration with Open Migrator LM. Perform Execution of Open Migrator LM Migration, Testing, and Cutover 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
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
Page 71
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
stormigrate activate session <session_name> stormigrate copy session <session_name> stormigrate create session <session_name> file <filename> stormigrate query session <session_name> -i 30 stormigrate tune ceiling N
Information
Activates the session.
Starts copying of the session.
Creates the session, using a file that lists all source and target devices pairs. Monitoring command, running at 30 second intervals. 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) Returns when copying is completed.
stormigrate verify session <session_name> i 30
Execute Open Migrator LM Swingframe Migration, Testing, and Cutover Work Plan
Role Description Task List Solutions Architect / Implementation Specialist Execute the Swingframe migration itself with Open Migrator LM. Perform Execution of Open Migrator LM Swingframe Migration, Testing, and Cutover
Page 72
Perform Execution of Open Migrator LM Swingframe 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 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 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
Example CLI Command
stormigrate activate session <session_name> stormigrate copy session <session_name> stormigrate create session <session_name> file <filename> stormigrate query session <session_name> -i 30
Information
Activates the session.
Starts copying of the session.
Creates the session, using a file that lists all source and target devices pairs. Monitoring command, running at 30 second intervals.
Page 74
Example CLI Command

stormigrate tune ceiling N
Information
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) Returns when copying is completed.
stormigrate verify session <session_name> i 30
Page 75
Execute Migration Cutover, Testing, and Cleanup (User-determined Events) Activity

Role Description Project Manager / Solutions Architect / Implementation Specialist / MSS 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 Description Project Manager 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. Conduct PM Event-window Implementation 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.
Task List Conduct PM Event-window Implementation Task
Perform an SA Event-window Implementation for Data Migration Work Plan

Role Description Solutions Architect This work plan covers all of the SA 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. Conduct SA Event-window Implementation 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.
Task List Conduct SA Event-window Implementation Task
Page 76
Perform an IS Event-window Implementation for Data Migration Work Plan

Role Description Implementation Specialist This work plan covers all of the IS 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. Conduct IS Event-window Implementation 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.
Task List Conduct IS Event-window Implementation Task
Perform an MSS Event-window Implementation for Data Migration Work Plan

Role Description MSS This work plan covers all of the MSS 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. Conduct MSS Event-window Implementation 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.
Task List Conduct MSS Event-window Implementation Task
Page 77
De-install Hardware Activity

Role Description Implementation Specialist / MSS 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

Role Description Implementation Specialist / MSS 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. 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).
Task List
Page 78
Crate and Ship Equipment Activity

Role Description Implementation Specialist / MSS Coordinate the crating and shipping the EMC equipment to customer sites after deinstallation by EMC.
Crate Equipment Work Plan

Role Description Implementation Specialist / MSS Verify that the equipment is ready for packaging and prepare shipping containers. Pack equipment and secure for shipping. Obtain and Verify Hardware Shipping Containers Verify Equipment Status Ready for Packaging Pack and Secure Equipment
Task List
Ship Equipment Work Plan

Role Description Implementation Specialist / MSS Verify that the equipment is ready for packaging and prepare shipping containers. Pack equipment and secure for shipping. Verify Shipping Details Contact with Shipping Partner or Vendor Verify Equipment Status Ready for Shipping Review Partner or Vendor Truck Loading
Task List
Page 79
Finalize Project Deliverables by Solutions Architect and Implementation Specialist Activity

Role Description Solutions Architect and Implementation Specialist 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 Description Solutions Architect and Implementation Specialist Complete the Configuration Guide and Test Plan, and deliver the documents to the customer. 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.
Task List
Deliver Functional Overview Work Plan

Role Description Implementation Specialist Review basic operations with the customer and provide an overview of the implemented technologies. Review basic operations, configuration, and extended features that are part of the implementation.
Task List
Page 80
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
activate concurrent migrations
Definition
UNIX only. Activates an OM/LM session. 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. UNIX only: Compares source and target volume data in an activated session. UNIX only. Creates a OM/LM session 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. Windows only: OM/LM persists migrations across system reboots. Windows only: The Microsoft Management Console (MMC) snap-in user interface that OM/LM uses for its GUI. UNIX only. Query of the session produces detailed information on the OM/LM copy session. 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. UNIX only: Restarts a failed session. UNIX only: Resumes a paused session and begins the operation from where it was paused. One after the other. UNIX only: A grouping of source/target pair devices to be migrated. Allows for ease of management. UNIX only. Summary provides status information on the OM/LM copy session. UNIX only: Tunes session performance at the kernel level. The bandwidth ceiling is set with this operand. UNIX only: Verifies the existing state of a given session.
compare
create filter driver
migration persistence MMC query Remote client migrations
\restart resume
serial session
summary
tune verify
Page 81
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.
Page 82

PG Omlm Data Migration Pscusprdsvc

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PG Omlm Data Migration Pscusprdsvc

Hochgeladen von

Copyright:

Verfügbare Formate

EMC Corporation

Technology Solutions Kit

EMC Data Migration Solution for Open Migrator/LM Practitioners Guide

EMC Corporation 176 South Street Hopkinton, MA 01748

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

Appendix A: Glossary of Terms Essential Terms and Concepts....................... 81

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

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

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

EMC Data Migration with Open Migrator/LM

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

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

Figure 2. Data Migration Planning and Design

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

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

Figure 3. Data Migration Implementation and Testing

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

OM/LM for UNIX/Linux Overview

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

Reference Documentation and Resources

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide

Virtual Machine Deployment Guide

XP license and Activating Windows XP License

Additional Documents which are Required for Data Collection Appliance

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

EMC Data Migration Solution for Open Migrator/LM 03/03/11

EMC Corporation, Technology Solutions

T.S. Service Kit: Practitioners Guide