Open Migrator/LM for UNIX and Linux CLI - Dell EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103 1-508-435-1000 EMC Open Migrator/LM for UNIX and Linux CLI Version 3.12

EMC Open Migrator/LMfor UNIX and Linux CLI

Version 3.12

PRODUCT GUIDEP/N 300-011-592

REV A01

®

EMC CorporationCorporate Headquarters:

Hopkinton, MA 01748-9103

1-508-435-1000www.EMC.com

2

Copyright © 2005 - 2010 EMC Corporation. All rights reserved.

Published September, 2010

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

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

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

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

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

EMC Open Migrator/LM for UNIX and Linux Version 3.12 CLI Product Guide

Contents

Preface ................................................................................................... 11

Chapter 1 Product OverviewOverview............................................................................................ 16Requirements and considerations .................................................. 19

Requirements ..............................................................................19Considerations ............................................................................19

Open Migrator/LM functions......................................................... 22Concurrent migrations...............................................................22Data migration to a different volume type .............................22Data migration to a different volume size ..............................22Data synchronization .................................................................22Migration persistence and mirror synchronization...............23Thin Device Migration ...............................................................24Data migration for failover cluster...........................................24Log files ........................................................................................24

Migration planning........................................................................... 26I/O stack layers...........................................................................26Disk space considerations .........................................................27Migration with a volume manager ..........................................27Provisioning target volumes .....................................................27Migration with a file system .....................................................28Application performance considerations................................28

Open Migrator/LM command summary ..................................... 30

Chapter 2 InstallationPreinstallation tasks.......................................................................... 32Installing Open Migrator/LM on HP-UX ..................................... 33

EMC Open Migrator/LM for UNIX and Linux Version 3.12 CLI Product Guide 3

Contents

Disk space considerations ......................................................... 33Files added during install.......................................................... 34Session activation ....................................................................... 35Removing the software from HP-UX ...................................... 36

Installing Open Migrator/LM on IBM AIX.................................. 39Disk space considerations ......................................................... 40Files added during install.......................................................... 40ODM modifications................................................................... 41Removing the software from IBM AIX ................................... 41

Installing Open Migrator/LM on Sun Solaris .............................. 44Disk space considerations ......................................................... 44Files added during install.......................................................... 45Removing the software from Sun Solaris ............................... 46

Installing Open Migrator/LM on Linux ....................................... 49Disk space considerations ......................................................... 51Files added during install.......................................................... 51Removing the software from Linux......................................... 52

Chapter 3 Open Migrator/LM Control OperationsSession overview .............................................................................. 56

Migrating data between storage arrays................................... 56Control operations............................................................................ 58

Creating a device file.................................................................. 58Creating a session....................................................................... 61Adding devices to a session...................................................... 64Listing sessions .......................................................................... 65Showing session data................................................................. 66Activating a session.................................................................... 67Start device copying................................................................... 68Pausing the session .................................................................... 68Deleting a session ....................................................................... 70Restarting a failed session ......................................................... 70Tuning session performance..................................................... 71Verifying session states.............................................................. 77Querying session status............................................................. 78Comparing session data ............................................................ 80Setting environmental variables............................................... 80Display session properties ........................................................ 81Clean up old session data.......................................................... 81Postmigration procedures ......................................................... 82

Control operations - Data migration for failover cluster ............ 83Solution I: Migration with cluster failover disabled ............ 85

EMC Open Migrator/LM for UNIX and Linux Version 3.12 CLI Product Guide4

Contents

Solution II: Migration with cluster failover enabled.............86Add Open Migrator/LM plugin for cluster............................87Remove Open Migrator/LM plugin for cluster .....................91Post migration procedure for cluster migrations ...................92Special rules for defining session for cluster migration ........93Special notes for cluster migrations .........................................94

Special considerations for z/Linux migration .............................. 97DASD device blocksize and application I/O size on z/Linux ...................................................................................97DASD device partitions and whole disk support on z/Linux ...................................................................................98

Appendix A Command ReferenceConventions ..................................................................................... 102stormigrate ....................................................................................... 103

Appendix B ExamplesMigrating Oracle databases ........................................................... 114

Identifying devices to migrate ............................................... 114Creating volume groups and logical volumes on target devices ........................................................................................120Setting up EMC Open Migrator/LM.....................................123Creating the session..................................................................125Activating the session...............................................................126Managing the session ...............................................................127Completing the migration .......................................................130Conclusion .................................................................................134

Migrating HP Serviceguard shared logical volumes ................. 135Migration Steps Summary.......................................................136Before Migration .......................................................................137Start Migration ..........................................................................141After Migration .........................................................................142

Migrating IBM HACMP shared logical volumes ....................... 146Basic LVM migration................................................................146Migration Steps Summary.......................................................146Before Migration .......................................................................147Start Migration ..........................................................................151After Migration .........................................................................152Cross-site LVM mirroring........................................................157Migration Steps Summary.......................................................157Before Migration .......................................................................158Start Migration ..........................................................................168

5EMC Open Migrator/LM for UNIX and Linux Version 3.12 CLI Product Guide

Contents

After Migration ......................................................................... 169Migrating Veritas VCS shared logical volumes on Solaris ....... 173

Migration Steps Summary ...................................................... 174Before Migration....................................................................... 179Start Migration.......................................................................... 187After Migration ......................................................................... 188

EMC Open Migrator/LM for UNIX and Linux Version 3.12 CLI Product Guide6

Title Page

Tables

1 Open Migrator/LM stormigrate command summary .............................. 302 Open Migrator/LM use with VTOC blocks................................................ 633 MIOT task state table ...................................................................................... 76


8

Tables


Title Page

Figures

1 Open Migrator/LM copy session ................................................................ 182 I/O stack layers .............................................................................................. 263 Data migration using the stormigrate command ...................................... 574 Migration in a clustered environment ........................................................ 845 General procedure for cluster migration .................................................... 866 Using Solutions Enabler to determine the schema of Oracle database 1157 Determining database files to be migrated ............................................... 1168 Detail showing the location of database file ............................................. 1179 Determining disk groups associated with Oracle database ................... 11810 Identify logical volumes and file system with schema SYS ................... 11911 Identify logical volumes and file system with schema TPCB ................ 11912 Configuration details of logical volume tpcb01 in schema TPCB ......... 12013 Creating target volume groups using EMC CLARiiON devices .......... 12114 Comparing source and target logical volume pairs ................................ 12215 Device file listing the source and target logical volumes ....................... 12316 Setting environmental variables ................................................................ 12417 Creating the Open Migrator/LM session ................................................. 12518 I/O activity on source logical volumes ..................................................... 12619 Activating and starting the copy process for the session ....................... 12720 Increased IO activity due to copy in process ........................................... 12821 Tuning IO size for the session .................................................................... 12922 Pausing and resuming the session ............................................................. 13023 Verify and stop Oracle database before completing the migration ...... 13124 Unmount source devices and deactivate the session .............................. 13225 Starting Oracle on target devices ............................................................... 13326 Testing the integrity of the Oracle database on target devices .............. 134


10

Figures


Preface

As part of its effort to continuously improve and enhance the performance and capabilities of the EMC product line, EMC periodically releases revisions of its hardware and software. Therefore, some functions described in this document may not be supported by all versions of the software and hardware currently in use. For the most up-to-date information on product features, refer to your product release notes.

If an Open Migrator/LM for UNIX and Linux feature does not function properly or does not function as described in this guide, please contact the EMC Customer Support Center for assistance.

Audience This document describes the functionality and use of the Open Migrator/LM for UNIX and Linux software, version 3.12, and provides both guide and reference information for command line users and script programmers.

This document is intended for system administrators who are tasked with a large data migration effort where system availability and data integrity is critical. Prerequisite knowledge includes familiarity with the following topics:

◆ Data volume migration

◆ UNIX and your specific operating system environment

◆ Linux and your specific operating system environment


12

Preface

Relateddocumentation

Related documents include:

◆ EMC Open Migrator/LM for UNIX Version 3.12 Release Notes.

◆ EMC Open Migrator/LM for Linux Version 3.12 Release Notes.

Conventions used inthis document

EMC uses the following conventions for special notices.

Note: A note presents information that is important, but not hazard-related.

CAUTION!A caution contains information essential to avoid data loss or damage to the system or equipment. The caution may apply to hardware or software.

IMPORTANT!An important notice contains information essential to operation of the software. The important notice applies only to software.


Preface

Typographical conventionsEMC uses the following type style conventions in this document:

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

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

buttons, DQL statements, keywords, clauses, environment variables, filenames, functions, utilities

• URLs, pathnames, filenames, directory names, computer names, links, groups, service keys, file systems, notifications

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

processes, services, applications, utilities, kernels, notifications, system call, man pages

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

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

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

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

shown outside of running text.

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

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

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

[ ] Square brackets enclose optional values

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

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

... Ellipses indicate nonessential information omitted from the example


14

Preface

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

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

http://Powerlink.EMC.com

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

Your commentsYour suggestions will help us continue to improve the accuracy, organization, and overall quality of the user publications. Please send your opinion of this document to:

[email protected]


http://powerlink.emc.com

1Invisible Body Tag

This chapter provides a functional overview of the EMC® Open Migrator/LM for UNIX and Linux, describes the data migration process, and introduces the stormigrate command line interface.

◆ Overview............................................................................................. 16◆ Requirements and considerations ................................................... 19◆ Open Migrator/LM functions.......................................................... 22◆ Migration planning............................................................................ 26◆ Open Migrator/LM command summary ...................................... 30

Product Overview

Product Overview 15

16

Product Overview

OverviewEMC Open Migrator/LM (Live Migration) for UNIX and Linux provides an online data migration and comparison tool for high availability data centers, where data copying between storage arrays is performed from the production host. Open Migrator/LM is implemented as a host-based kernel driver and command line interface (CLI), and is used to migrate data from source to target volumes with only a single disruption to the server or applications. Because the Open Migrator/LM device driver is dynamically loaded and unloaded, there is no required system reboot.

Note: The name Open Migrator/LM as used throughout this guide refers only to the UNIX and Linux operating system version of this software product. For information on Open Migrator/LM for a Microsoft Windows operating environment, refer to the EMC Open Migrator/LM for Windows Product Guide.

Open Migrator/LM provides mirroring and background copy functions between storage arrays 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 migration the source volume can remain available for input/output (I/O) to production host applications. The target volume is set to read/write disabled. The target volume should also be set as not ready to any additional hosts having access to the volume to guarantee that the volume cannot change while copying is in progress. Open Migrator/LM operates in sessions to manage multiple volume pairs uniformly as a group. Control operations are performed by 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. Refer to Table 1 on page 30 for a list of the command line arguments and actions.

Data can also be compared between source and target volumes in an activated session. When comparing, Open Migrator/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.


Product Overview

When volumes have been successfully migrated and the session has been deactivated, Open Migrator/LM can be uninstalled from the kernel I/O subsystem and the production host. Open Migrator/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 may include various applications for file systems, volume managers and multipath capability, it is necessary to understand the I/O subsystem (I/O stack layers) within the operating system (OS) kernel. For best results, source volumes for data migration should 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. For an explanation of the I/O stack layers within a UNIX/Linux OS kernel, refer to “Migration planning” on page 26.

Open Migrator/LM is installed on the production host. Any volumes visible to the production host can be compared and migrated. The source and target volumes can be on the same array or separate arrays. Refer to Figure 1 on page 18.

Overview 17

18

Product Overview

Figure 1 Open Migrator/LM copy session

Volumec2t0d55s2

Volumec2t0d56s3

StorageArray 4

Volumeora1_src_vg/rvol2



Data Migration

Copy Session

Note: Data migration is performed through the Production Host, which is running EMC Open Migrator/LM for UNIX and Linux. The host must be able to see all devices in the session.

StorageArray 2

Volumeora1_tgt_vg/rvol1



StorageArray 1

Volumec1t6d0s2

Volumec1t1d3s2

Volumec1t4d2s2

StorageArray 3

Application

EMC Open Migrator/LM

Device Control

SourceDevices

TargetDevices

Data Migration

Data Migration Data Migration Source

Devices

TargetDevices

Volumec2t0d55s4

# A device file contains a list of the copy session volume pairs# The source volume is listed in the first column, target volume is in second column/dev/rdsk/c1t1d3s2 /dev/rdsk/c2t0d55s2/dev/rdsk/c1t6d0s2 /dev/rdsk/c2t0d55s4/dev/rdsk/c1t4d2s2 /dev/rdsk/c2t0d56s3/dev/ora1_src_vg/rvol1 /dev/ora1_tgt_vg/rvol1/dev/ora1_src_vg/rvol2 /dev/ora1_tgt_vg/rvol2/dev/ora1_src_vg/rvol3 /dev/ora1_tgt_vg/rvol3# End file

ProductionHost

{{

{{


Product Overview

Requirements and considerationsOpen Migrator/LM software is based on the functionality and features of associated hardware and software in an EMC Enterprise Storage environment.

RequirementsYou must have one of the following supported operating environments:

◆ HP-UX

◆ IBM AIX

◆ Sun Solaris

◆ Red Hat Enterprise Linux

◆ Novell SuSE Linux Enterprise Server

Note: For detailed information on supported UNIX and Linux operating systems and kernel versions, refer to EMC Open Migrator/LM in the E-Lab™ Navigator at http://Powerlink.EMC.com.

Accessed from the Powerlink home page, move the cursor over the Support > Interoperability/Compatibility/Configuration > E-Lab Interoperability Navigator, and click Launch E-Lab Interoperability Navigator.

Note: For information on supported file systems, volume managers and multipath I/O managers, refer to your EMC Open Migrator/LM for UNIX version 3.12 Release Notes or EMC Open Migrator/LM for Linux version 3.12 Release Notes as applicable.

ConsiderationsNote the following considerations for Open Migrator/LM:

◆ Open Migrator/LM has no dependencies on the versions of the EMC Enginuity™ operating environment, EMC Solutions Enabler software, or EMC CLARiiON® Navisphere® software.

◆ Both the source and target volumes remain synchronized until the session has been deactivated.

Requirements and considerations 19

20

Product Overview

◆ Open Migrator/LM cannot be used with EMC Celerra® systems.

◆ Open Migrator/LM does not support the following:

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

• Automatic volume expansion

◆ With the exception of character devices of the raw(8) driver, Open Migrator/LM for Linux does not support character devices. The software checks that character devices named in add and create commands are raw(8) driver character device special file nodes.

◆ EMC strongly recommends that you do not migrate jfs/jfs2 log volumes on IBM AIX hosts. The log data is only used for recovery and is not needed to mount the target volume cleanly when the copy/compare session has completed.

Open Migrator checks the LV State of all target (native) logical volumes at the time of session activation. If the LV State is open (in use) for shared volumes that are mounted, then session activation is blocked.

CAUTION!Note that if the target loglv is closed (not in use) but volumes sharing the target loglv are either not mounted or not part of the migration, data loss could occur when the source loglv volume is migrated to the target loglv. The file system log for volumes not being migrated could be overwritten.

As a result, file systems that share the target jfs/jfs2 log volume could become inaccessible.

Furthermore, data loss could occur if a target loglv is included in the session, and volumes that are not part of the migration share the target loglv are mounted after the migration starts. Open Migrator exclusively locks the volume when the session begins.

For these reasons, do not include the loglv volumes as part of an OM migration.


Product Overview

◆ Data corruption to volumes may be possible during a copy operation if another host (other than the Open Migrator/LM production host) has write access to the target volume. If this is a concern, it is recommended 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.

◆ During peak application I/O load times, user applications may experience a decrease in the response time. Refer to the section titled “Application performance considerations” on page 28 for recommendations on how to improve migration performance.

◆ Data migration for failover cluster is supported. The following clusters, when configured in failover mode, are supported:

• IBM HACMP for AIX

• HP Serviceguard for HP-UX

• Veritas Cluster Server for Sun Solaris

Requirements and considerations 21

22

Product Overview

Open Migrator/LM functionsOpen Migrator/LM allows you to perform various types of data migration operations between storage arrays.

Concurrent migrationsOpen Migrator/LM migrates source and target volume pairs concurrently. Multiple migrations of volume pairs may be executed at one time. The actual number of sessions is limited by the availability of your operating system resources at the time of migration.

Data migration to a different volume typeOpen Migrator/LM supports data migration from any type of source block devices to any type of target block devices. In other words, the software allows data migration at the block I/O level between all types of volumes, LUNs, LUN partitions, and devices.

Data migration to a different volume sizeOpen Migrator/LM can migrate data between source and target volumes or metavolumes of different sizes. The target volume must be of equal or larger size than the source volume.

Data synchronizationOpen Migrator/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. Open Migrator/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 hosts to guarantee the volume cannot change during the migration session. Data corruption may be possible during a copy operation if another host has write access to the target volume.


Product Overview

Migration persistence and mirror synchronizationBecause the source volume remains available for I/O to production host applications during a migration, the mirror write consistency of volumes in active sessions cannot be guaranteed if there is an unplanned reboot or system crash. Open Migrator/LM depends on the orderly shutdown of applications to guarantee mirror synchronization and relies on the execution of an init(8) rc command script at certain run levels to indicate an orderly shutdown.

At system boot time, if an orderly shutdown is not indicated, Open Migrator/LM assumes that pending mirrored writes may have existed at the time of the outage, and that mirror synchronization may have been lost. If mirror synchronization cannot be guaranteed at boot time, Open Migrator/LM will abort the recovery of sessions that were active at the time of the outage.

Active sessions will only be resumed and mirror synchronization guaranteed if the system has been explicitly shut down by using the appropriate system shutdown command (shutdown(8)). The shutdown(8) command is the only reboot or power off method that invokes the init(8) rc command script. Using other methods may cause Open Migrator/LM to abort the recovery of sessions active at the time of the outage.

If the system experiences an unplanned outage or system crash during a data migration, those affected sessions must be activated again and device copying must be started over.

Note: Additionally, when resuming a session, if a session contains tasks with source devices that have VFS mounted filesystems, the recovery will abort because mirror synchronization cannot be guaranteed at boot time.

Note: Migration persistence across reboot is not guaranteed for cluster migrations.

Open Migrator/LM functions 23

24

Product Overview

Thin Device MigrationOpen Migrator/LM supports migrations to and from thin devices. Migration from thick to thin will result in a fully allocated thin device.

CAUTION!When performing migration to thin devices, you must make sure that the storage pool for the thin devices has enough free space.

Data migration for failover clusterData volumes of failover cluster can be migrated. Share volumes working in Active-Passive mode can be viewed by Open Migrator/LM and migrated to cluster-capable and available volumes. Open Migrator/LM must be installed on only one cluster node, preferably the primary active node or group node owner of the volumes to be migrated.

Open Migrator/LM must maintain exclusive control over all devices involved throughout the duration of the migration. Migrations will fail immediately when any migrating disks (source or target) are no longer online.

Note: Open Migrator/LM does not support migrating share logical volumes which are read/write by multiple cluster nodes simultaneously.

Log filesOpen Migrator/LM is supported by a log file, which can be used to examine and troubleshoot data migration activities.

A separate log file is created on the system where the Open Migrator/LM service is installed. The log file records all the volume properties. The file is located in the following directory: /var/EMCom/log.

The /var/EMCom/log file can be viewed by using the standard UNIX display commands for concatenate (cat) and more. The


Product Overview

/var/EMCom/log file contains a record of all the command line log messages. The following is an example excerpt from a log file.

2007-06-20 10:10:08.275 15750 CLI command stormigrate create -se cpysess1 was submitted2007-06-20 10:10:08.277 15750 Starting a EMCOM Session Create on cpysess1.2007-06-20 10:10:08.291 15750 The EMCOM session cpysess1 was created successfully.2007-06-20 10:10:25.794 15763 CLI command stormigrate add -se cpysess1 /dev/rdsk/c2t2d100s2 /dev/rdsk/c2t2d102s2 -skip was submitted2007-06-20 10:10:25.810 15763 Starting a EMCOM Session Add on cpysess1.2007-06-20 10:10:25.838 15763 /dev/rdsk/c2t2d100s2 and /dev/rdsk/c2t2d102s2 were successfully added to session cpysess1.2007-06-20 10:10:33.529 15766 CLI command stormigrate act -se cpysess1 was submitted2007-06-20 10:10:33.535 15766 Starting a EMCOM 'Activate' operation on session cpysess1.2007-06-20 10:10:33.569 15766 The EMCOM 'Activate' operation on session cpysess1 was started successfully.2007-06-20 10:10:43.126 15769 CLI command stormigrate copy -se cpysess1 was submitted2007-06-20 10:10:43.135 15769 Starting a EMCOM 'Copy' operation on session cpysess1.2007-06-20 10:10:43.153 15769 The EMCOM 'Copy' operation on session cpysess1 was started successfully.2007-06-20 10:11:22.091 15791 CLI command stormigrate query -se cpysess1 -k -v -i 30 was submitted2007-06-20 10:11:24.201 15800 CLI command stormigrate tune -nt 64 was submitted2007-06-20 10:11:25.449 15800 Starting a EMCOM tune operation.2007-06-20 10:11:25.476 15800 Iosize set to 655362007-06-20 10:11:25.476 15800 Throttle set to 1002007-06-20 10:11:25.476 15800 Nthreads set to 642007-06-20 10:11:25.476 15800 CheckPointSize set to 2562007-06-20 10:11:25.477 15800 Mirror I/O Throttle Performance Ratio set to 2002007-06-20 10:11:25.477 15800 Mirror I/O Throttle Recovery Action set to Terminate2007-06-20 10:11:25.477 15800 The EMCOM tune operation was successful.2007-06-20 10:11:42.476 15801 CLI command stormigrate tune -nt 64 was submitted2007-06-20 10:13:14.662 15840 CLI command stormigrate pause -se cpysess1 was submitted2007-06-20 10:13:14.666 15840 Starting a EMCOM 'Pause' operation on session cpysess1.2007-06-20 10:13:14.686 15840 The EMCOM 'Pause' operation on session cpysess1 was started successfully.

Open Migrator/LM functions 25

26

Product Overview

Migration planningThis section provides some basic guidelines for data migration planning with Open Migrator/LM.

I/O stack layersWhen planning a data migration project that uses Open Migrator/LM software for UNIX or Linux, it is important to understand the architecture of your I/O subsystem (or I/O stack) within the server operating system (OS) kernel. This architecture defines the mapping of application data volumes onto physical media. Because data is copied from a source volume I/O stack to a target volume I/O stack, data can be copied at a number of possible levels. Best practice dictates that the user copy data from the source volume I/O stack level that is closest to the application layer. Refer to Figure 2 for a depiction of the various I/O stack levels at which data can be copied.

Figure 2 I/O stack layers

Physical Layer LUN and PartitionSlices

Multi Path I/O Layer

Operating SystemDrivers

Logical VolumeManager Layer Logical Volumes

Mount Points

Application Data

File System Layer

Application Layer


Product Overview

Open Migrator/LM directs RAID1 and copy I/O requests to the source and target volumes by inserting data into the applicable underlying drivers in the volume manager, multipath I/O, and physical layers. The I/O stack level chosen for data migration depends on whether your application’s data volumes are logical volumes or LUNS. Data should always be copied at the highest possible layer in the I/O stack nearest to the application.

Disk space considerationsIn addition to the free disk space required for the installation of Open Migrator/LM on your host system, there should be sufficient space reserved in the /etc file system to store properties files created by the stormigrate utility at run-time. Additional recommended free disk space should be equivalent to 10 KB per device pair in each defined session.

Note: Refer to Chapter 2, ”Installation,” for the amount of free disk space recommended for installation on your specific operating system.

Migration with a volume managerWhen a volume manager is present in the I/O stack, migration should take place at the logical volume level and not at the underlying LUN level. This practice avoids complications that occur with logical volume managers and duplicate disk signatures. Even though, Open Migrator/LM can be used to copy logical volume data at the LUN volume level, this practice is discouraged.

Provisioning target volumesTarget volumes must be provisioned at the level in the I/O stack where the data will be accessed by the application after the migration completes. If target volumes are logical volumes, the target volumes must be created and made ready for data access by Open Migrator/LM prior to creating the session. This is accomplished by using the volume manager’s administrative tools.

Migration planning 27

28

Product Overview

Migration with a file systemIf a file system is part of the I/O stack, the resulting target file system must be the same type as the source. You cannot alter the file system type since migration takes place under the file system in the I/O stack.

Application performance considerationsOpen migrator/LM may have the following affects in your environment:

◆ Increased read I/O load on the source volume/array

◆ Increased write I/O load on the target volume/array

◆ Increased overall I/O load on the Storage Area Network (SAN)

◆ Decreased response time of user applications

The level to which the above affects occur can generally be controlled by setting the tuning I/O ceiling parameter (-ceiling megabytes per second). By default, this value is preset to a conservative 1 Mb/s, which causes no noticeable affect in the performance of most configurations. Extreme care should be used when adjusting this value. When performing online migrations of critical applications, performance of those applications should be monitored closely when increasing the I/O ceiling value.

You must be aware of and take into account your peak application I/O load times when adjusting this value. The I/O ceiling parameter only controls I/O load during the actual copy and compare operations and has no affect on volumes in the mirroring or paused state. When migrating volumes from a faster array to a slower array, write performance on the host will be limited to that of the slower array as long as the session is active in either the copy/compare or mirroring/paused states.

When performing migrations on multiple hosts within a SAN environment, you should monitor for any potential I/O bottlenecks (for example, Inter-switch links (ISLs) and remote storage connections). Exceeding the bandwidth on these links could have a detrimental affect on the performance of your applications that could result in application outages.


Product Overview

Prior to performing online migrations, EMC recommends the following guidelines to help avoid I/O load issues and decreased application response times:

◆ Review the system and hardware logs to identify any potential hardware issues.

◆ Verify any vendor-specified I/O time-out settings for both your source and target device.

◆ Avoid migrating temporary data files, such as page/swap or database redo logs, because these will add an unnecessary I/O load to the system. Generally, files of these types will not be needed once a clean transition is made to the migrated volumes.

Note: Refer to “Tuning session performance” on page 71 for information on the available stormigrate tuning parameters.

Migration planning 29

30

Product Overview

Open Migrator/LM command summaryThe Open Migrator/LM command (stormigrate) allows you to perform copy, control and comparison operations between volumes that are accessible to the production host within a session.

Note: For a more comprehensive description of the stormigrate command and its functionality, refer to Appendix A, “Command Reference.”

Table 1 Open Migrator/LM stormigrate command summary

Command Argument Action

stormigrate activate Activates the session.

add Associates source and target volumes with a created session.

cleanup Cleans up old session data to restore system to a clean state.

compare Compares source and target volume data in an activated session.

complete Change cluster migration state to Complete.

copy Begins the copying process for volume pairs in an activated session.

create Defines a new session and assigns a session name.

deactivate Deactivates an activated session.

delete Deletes the session.

list Lists all currently defined sessions.

pause Pauses a session and temporarily stops the operation.

props Displays properties for defined sessions.

query Queries for the status of a given session.

restart Restarts a failed session.

resume Resumes a paused session and begins the operation from where it was paused.

show Displays current configuration data for a given session.

tune Tunes session performance at the kernel level.

verify Verifies the existing state of a given session.


2Invisible Body Tag

This chapter describes how to install and remove Open Migrator/LM for UNIX and Linux on the various supported platforms.

◆ Preinstallation tasks........................................................................... 32◆ Installing Open Migrator/LM on HP-UX ...................................... 33◆ Installing Open Migrator/LM on IBM AIX ................................... 39◆ Installing Open Migrator/LM on Sun Solaris ............................... 44◆ Installing Open Migrator/LM on Linux......................................... 49

Installation

Installation 31

32

Installation

Preinstallation tasksBefore you run the installation program, be sure to do the following:

❑ Review the requirements listed in Chapter 1, ”Product Overview” and in the EMC Open Migrator/LM for UNIX and Linux Release Notes.

❑ Check the operational platform support for your system.

Note: Accessed from the Powerlink home page, move the cursor over the Support > Interoperability/Compatibility/Configuration > E-Lab Interoperability Navigator, and click Launch E-Lab Interoperability Navigator.

Note: For detailed information on supported UNIX and Linux operating systems and kernel versions, refer to EMC Open Migrator/LM in the E-Lab Navigator at http://Powerlink.EMC.com

❑ Verify that you have administrative privileges, as they are required to install and run Open Migrator/LM in the kernel.

❑ Install the software according to the instructions provided for your specific operating system (HP-UX, IBM AIX, Sun Solaris, Red Hat Enterprise Linux, or Novell SuSE Linux Enterprise Server).

❑ If a previous version of Open Migrator/LM for UNIX/ Linux software is currently installed, you must first remove it before installing the new version. Refer to the software removal instructions for your specific operating system located in this chapter.


Installation

Installing Open Migrator/LM on HP-UXThis section describes how to install Open Migrator/LM for UNIX software on a HP-UX host.

Note: If an existing version of Open Migrator/LM for UNIX software is currently installed, it must first be removed before installing another version. Refer to “Removing the software from HP-UX” on page 36.

Note: EMC recommends that the HP-UX kernel tunable parameter for nflocks be set to 1024 before installation.

Perform the following steps to install Open Migrator/LM software on a HP-UX host:

1. Log in to the host system as root.

2. Copy the installation image .tar file to the /tmp directory. For example, type the following command:

cp EMComlm.HPUX.tar /tmp

3. To install the software, type:

swinstall -s /tmp/EMComlm.HPUX.tar EMCom

Note: If this is a reinstall, note that all of the previously set tuning option parameters (-ceiling, -iosize, -checkpointsize, -nthreads, -mio_perf_ratio, and -mio_recover_action) must be manually reset. Refer to “Tuning session performance” on page 71.

Disk space considerationsRecommended free disk space for installation on a HP-UX host is 14 MB. In addition to the install footprint outlined in “Files added during install” on page 34, there should be sufficient space reserved in the /etc file system to store properties files created by the stormigrate utility at run-time. Additional recommended free disk space should be equivalent to 10 KB per device pair in each defined session.

Installing Open Migrator/LM on HP-UX 33

34

Installation

Files added during installThe following files are added during the installation:

/etc/opt/EMCom/etc/opt/EMCom/bin/etc/opt/EMCom/bin/stormigrate_11_00_32/etc/opt/EMCom/bin/stormigrate_11_00_64/etc/opt/EMCom/bin/stormigrate_11_11_32/etc/opt/EMCom/bin/stormigrate_11_11_64/etc/opt/EMCom/bin/omx_11_00_32/etc/opt/EMCom/bin/omx_11_00_64/etc/opt/EMCom/bin/omx_11_11_32/etc/opt/EMCom/bin/omx_11_11_64/etc/opt/EMCom/driver/etc/opt/EMCom/driver/emcom_11_00_32/etc/opt/EMCom/driver/emcom_11_00_64/etc/opt/EMCom/driver/emcom_11_11_32/etc/opt/EMCom/driver/emcom_11_11_64/etc/opt/EMCom/driver/drivers_emcom.tx/etc/opt/EMCom/driver/emcom.conf/etc/opt/EMCom/driver/master.emcom/etc/opt/EMCom/driver/system/etc/opt/EMCom/log/etc/opt/EMCom/properties/etc/opt/EMCom/properties/session.bounds,a/etc/opt/EMCom/properties/session.bounds,b/etc/opt/EMCom/properties/session.dfltparms,a/etc/opt/EMCom/properties/session.dfltparms,b/etc/opt/EMCom/properties/sessions,a/etc/opt/EMCom/properties/sessions,b/etc/opt/EMCom/share/etc/opt/EMCom/share/man/etc/opt/EMCom/share/man/man1/etc/opt/EMCom/share/man/man1/stormigrate.1/etc/opt/EMCom/share/man/man7/etc/opt/EMCom/share/man/man7/emcom.7

/etc/opt/EMCom/cluster/hpsg/emcom.0/etc/opt/EMCom/cluster/hpsg/emcom.sh

/dev/emcom

/sbin/stormigrate/sbin/init.d/emcom/sbin/init.d/emcom_resume

/stand/build/mod_wk.d/emcom/stand/build/mod_wk.d/emcom/_mod.o/stand/build/mod_wk.d/emcom/_mod_sec.o/stand/build/mod_wk.d/emcom/lmod.o


Installation

/stand/build/mod_wk.d/emcom/mod.o/stand/build/mod_wk.d/emcom/mod_conf.c/stand/build/mod_wk.d/emcom/mod_conf.o/stand/build/mod_wk.d/emcom/mod_sec.c/stand/build/mod_wk.d/emcom/mod_sec.o/stand/system.d/emcom/stand/dlkm/mod.d/emcom/stand/dlkm/system.d/emcom

/usr/conf/km.d/emcom/mod.o/usr/conf/master.d/emcom

/var/adm/sw/products/EMCom/var/adm/sw/products/EMCom/EMCom/var/adm/sw/products/EMCom/EMCom/INDEX/var/adm/sw/products/EMCom/EMCom/INFO

/var/adm/sw/products/EMCom/pfiles/var/adm/sw/products/EMCom/pfiles/INDEX/var/adm/sw/products/EMCom/pfiles/INFO/var/adm/sw/products/EMCom/pfiles/checkinstall/var/adm/sw/products/EMCom/pfiles/checkremove/var/adm/sw/products/EMCom/pfiles/configure/var/adm/sw/products/EMCom/pfiles/postinstall/var/adm/sw/products/EMCom/pfiles/postremove/var/adm/sw/products/EMCom/pfiles/preinstall/var/adm/sw/products/EMCom/pfiles/unconfigure

/var/EMCom/log/var/EMCom/lic

Note: Installation automatically creates binary links in the /sbin directory that point to the appropriate executable for your specific operating platform.

Session activationThe following is an example of an Open Migrator/LM session activation and the resulting properties files that are created:

# stormigrate create -session foo# stormigrate add -session foo /dev/vg1/rlv0 /dev/vg1/rlv1# stormigrate activate -session foo# ls -al /etc/opt/EMCom/properties

total 352drwxr-xr-x 2 root sys 8192Feb 7 16:01 .dr-xr-xr-x 8 bin bin 8192Feb 7 14:52 ..-rw-r--r-- 1 root sys 72 Feb 7 16:01 mvrcfg.FOO.t0000.m0000,a


36

Installation

-rw-r--r-- 1 root sys 72 Feb 7 16:01 mvrcfg.FOO.t0000.m0000,b-rw-r--r-- 1 root sys 104 Feb 7 16:01 mvrstat.FOO.t0000.m0000,a-rw-r--r-- 1 root sys 104 Feb 7 16:01 mvrstat.FOO.t0000.m0000,b-rw-r--r-- 1 root sys 88 Feb 7 16:01 sesscfg.FOO,a-rw-r--r-- 1 root sys 88 Feb 7 16:01 sesscfg.FOO,b-rw-r--r-- 1 root sys 24 Jan 10 14:19 session.bounds,a-rw-r--r-- 1 root sys 24 Jan 10 14:19 session.bounds,b-rw-r--r-- 1 root sys 40 Jan 24 11:59 session.dfltparms,a-rw-r--r-- 1 root sys 40 Jan 24 11:59 session.dfltparms,b-rw-r--r-- 1 root sys 32 Feb 7 16:01 sessions,a-rw-r--r-- 1 root sys 32 Feb 7 16:01 sessions,b-rw-r--r-- 1 root sys 56 Feb 7 16:01 sessstat.FOO,a-rw-r--r-- 1 root sys 56 Feb 7 16:01 sessstat.FOO,b-rw-r--r-- 1 root sys 48 Feb 7 16:01 tskcfg.FOO.t0000,a-rw-r--r-- 1 root sys 48 Feb 7 16:01 tskcfg.FOO.t0000,b-rw-r--r-- 1 root sys 56 Feb 7 16:01 tskstat.FOO.t0000,a-rw-r--r-- 1 root sys 56 Feb 7 16:01 tskstat.FOO.t0000,b-rw-r--r-- 1 root sys 2144 Feb 7 16:01 volcfg.FOO.t0000,a-rw-r--r-- 1 root sys 2144 Feb 7 16:01 volcfg.FOO.t0000,b

Removing the software from HP-UXThis section describes how to remove the software from an HP-UX host. Follow the removal instructions for the version you are removing (v3.7 or v3.8 and later).

Removing Open Migrator/LM version 3.7 from HP-UXPerform the following steps to uninstall the Open Migrator/LM for UNIX software version 3.7 from a HP-UX host:


2. Ensure that all sessions have been deactivated by using the stormigrate deactivate command.

3. To remove the software, type:

swremove EMCom

The following directories and contents are retained on the host after removal of the software:

/etc/opt/EMCom/clirep/etc/opt/EMCom/log/etc/opt/EMCom/properties/var/emcom/log


Installation

Note: The /etc/opt/EMCom/clirep and /etc/opt/EMCom/log directories are only retained if they contain data. If empty of contents, they will be deleted when the software is removed.

4. Ensure that the directories noted in step 3 are manually deleted before attempting to install any new or previous version of Open Migrator/LM.

Note: Only remove the /var/emcom/log directory if you are completely finished using the product, as it contains necessary information used for troubleshooting.

Removing Open Migrator/LM versions 3.8 and later from HP-UXPerform the following steps to uninstall the Open Migrator/LM for UNIX software versions 3.8 and later from a HP-UX host:



3. Delete all defined sessions on the system to restore to a clean state by using the stormigrate cleanup command.


swremove EMCom


/etc/opt/EMCom/log/etc/opt/EMCom/properties/var/EMCom/log

Note: The /etc/opt/EMCom/log, /etc/opt/EMCom/properties and the /var/EMCom/log directories are only retained if they contain data. If empty of contents, they will be deleted when the software is removed.



38

Installation

Note: Only remove the /var/EMCom/log directory if you are completely finished using the product, as it contains necessary information used for troubleshooting.


Installation

Installing Open Migrator/LM on IBM AIXThis section describes how to install Open Migrator/LM for UNIX software on an IBM AIX host.

Note: If an existing version of Open Migrator/LM for UNIX software is currently installed, it must first be removed before installing another version. Refer to “Removing the software from IBM AIX” on page 41.

Perform the following steps to install the software on an IBM AIX host:


2. Copy the installation image .tar file to the /tmp directory and extract (untar) the .tar file. For example, type the following commands:

cp EMComlm.AIX.tar /tmpcd /tmptar -xvf EMComlm.AIX.tar


installp -ad ./EMCom_install EMCom

Note: Refer to the installp man page for a list of optional flags.

The screen displays information about the installation, ending with the Installation Summary:

Installation SummaryName Level Part Event Result--------------------------------------------EMCom.base 3.12.0.8 USR APPLY SUCCESS


Installing Open Migrator/LM on IBM AIX 39

40

Installation

Disk space considerationsRecommended free disk space for installation on an IBM AIX host is 5 MB. In addition to the install footprint outlined in “Files added during install”, there should be sufficient space reserved in the /etc file system to store properties files created by the stormigrate utility at run-time. Additional recommended free disk space should be equivalent to 10 KB per device pair in each defined session.


/dev/emcom0/etc/opt/EMCom/etc/opt/EMCom/bin/etc/opt/EMCom/bin/stormigrate_32/etc/opt/EMCom/bin/stormigrate_64/etc/opt/EMCom/bin/omload.sh/etc/opt/EMCom/bin/omx_32/etc/opt/EMCom/bin/omx_64/etc/opt/EMCom/log/etc/opt/EMCom/properties/session.bounds,a/etc/opt/EMCom/properties/session.bounds,b/etc/opt/EMCom/properties/session.dfltparms,a/etc/opt/EMCom/properties/session.dfltparms,b/etc/opt/EMCom/properties/sessions,a/etc/opt/EMCom/properties/sessions,b

/etc/opt/EMCom/cluster/hacmp/cl_deactivate_emcom/etc/opt/EMCom/cluster/hacmp/cl_deactivate_vgs

/etc/rc.emcom

/usr/lib/methods/cfgom/usr/lib/methods/ucfgom/usr/lib/methods/defom/usr/lib/methods/udefom/usr/lib/nls/msg/en_US/emcom.cat/usr/lib/drivers/emcom/usr/lib/drivers/emcom.conf/usr/sbin/stormigrate/usr/share/man/man1/stormigrate.1/usr/share/man/man7/emcom.7



Installation

Note: The /etc/inittab file will be modified by the installation.

Note: For an example of an Open Migrator/LM session activation, refer to “Session activation” on page 35.

Note: Installation automatically creates binary links in the /usr/sbin directory that point to the appropriate executable for your specific operating platform.

ODM modifications The following ODM modifications are caused by the install:

Additions to PdDv and CuDv for emcom0 control device.Addition of Config_Rule to configure software after a reboot.

Removing the software from IBM AIXThis section describes how to remove the software from an IBM AIX host. Follow the removal instructions for the version you are removing (v3.7 or v3.8 and later).

Removing Open Migrator/LM version 3.7 from IBM AIXPerform the following steps to uninstall the Open Migrator/LM for UNIX version 3.7 software from an IBM AIX host:




installp -u EMCom

The screen displays information about the uninstall, ending with the Installation Summary:

Installation SummaryName LevelPartEventResult------------------------------------------------EMCom.base3.7.0.0USRDEINSTALLSUCCESS



42

Installation





Removing Open Migrator/LM versions 3.8 and later from IBM AIXPerform the following steps to uninstall the Open Migrator/LM for UNIX software versions 3.8 and later from an IBM AIX host:



3. Delete all sessions and associated log files on the system to restore to a clean state by using the stormigrate cleanup command.


installp -u EMCom

The screen displays information about the uninstall and ends with the Installation Summary:

Installation SummaryName LevelPartEventResult------------------------------------------------EMCom.base3.8.0.0USRDEINSTALLSUCCESS




Installation





44

Installation

Installing Open Migrator/LM on Sun SolarisThis section describes how to install Open Migrator/LM for UNIX software on a Sun Solaris host.

Note: If an existing version of Open Migrator/LM for UNIX software is currently installed, it must first be removed before installing another version. Refer to “Removing the software from Sun Solaris” on page 46.

Perform the following steps to install Open Migrator/LM on a Sun Solaris host:


2. Copy the installation image .tar file to the /tmp directory. For example, type the following commands:

cp EMComlm.SUN.tar /tmpcd /tmptar -xvf EMComlm.SUN.tar

3. Change directories to the directory on the installation media that contain the package appropriate for your system:

cd /tmp/system

where system is 580, 590 or 510, for Solaris 8, 9 and 10, respectively.


pkgadd -d .


Disk space considerationsRecommended free disk space for installation on a Sun Solaris host is 5 MB. In addition to the install footprint outlined in “Files added during install” on page 45, there should be sufficient space reserved in the /etc file system to store properties files created by the stormigrate utility at run-time. Additional recommended free disk


Installation

space should be equivalent to 10 KB per device pair in each defined session.


/etc/opt/EMCom/bin/sparcv8/stormigrate/etc/opt/EMCom/bin/sparcv8/omx/etc/opt/EMCom/bin/sparcv9/stormigrate/etc/opt/EMCom/bin/sparcv9/omx/etc/opt/EMCom/man/man7d/emcom.7d/etc/opt/EMCom/man/man7d/stormigrate.1m/etc/opt/EMCom/module/adddrv.ksh.EMCom/etc/opt/EMCom/module/addrcinit.ksh.EMCom/etc/opt/EMCom/module/addsymlink.ksh.EMCom/etc/opt/EMCom/module/remdrv.ksh.EMCom/etc/opt/EMCom/module/remrcinit.ksh.EMCom/etc/opt/EMCom/module/remsymlink.ksh.EMCom/etc/opt/EMCom/module/init.ksh.EMCom/etc/opt/EMCom/properties/session.bounds,a/etc/opt/EMCom/properties/session.bounds,b/etc/opt/EMCom/properties/session.dfltparms,a/etc/opt/EMCom/properties/session.dfltparms,b/etc/opt/EMCom/properties/sessions,a/etc/opt/EMCom/properties/sessions,b

/etc/opt/EMCom/vcs/EMCom/clean/etc/opt/EMCom/vcs/EMCom/EMComAgent/etc/opt/EMCom/vcs/EMCom/EMCom.xml/etc/opt/EMCom/vcs/EMCom/monitor/etc/opt/EMCom/vcs/EMCom/offline/etc/opt/EMCom/vcs/EMCom/online/etc/opt/EMCom/vcs/EMCom/util.sh

/etc/rc2.d/S86emcomrc.ksh

/kernel/drv/emcom/kernel/drv/emcom.conf/kernel/drv/sparcv9/emcom

/usr/sbin/stormigrate



Installing Open Migrator/LM on Sun Solaris 45

46

Installation

Note: Installation automatically creates binary links in the /usr/sbin directory that points to the appropriate executable for your specific operating platform as follows: /etc/opt/EMCom/bin/sparcv8 for 32 bit kernel or /etc/opt/EMCom/bin/sparcv9 for 64 bit kernel.

Removing the software from Sun SolarisThis section describes how to remove the software from a Sun Solaris host. Follow the removal instructions for the version you are removing (v3.7 or v3.8 and later).

Removing Open Migrator/LM version 3.7 from Sun SolarisPerform the following steps to uninstall the Open Migrator/LM for UNIX version 3.7 from a Sun Solaris host:




pkgrm EMCom







Installation

Note: Under certain conditions the kernel module could have busy text, in which case the software cannot be removed unless the daemon processes are stopped. Refer to “Stopping daemon processes” on page 48 for further instructions.

Removing Open Migrator/LM versions 3.8 and later from Sun SolarisPerform the following steps to uninstall the Open Migrator/LM for UNIX software versions 3.8 and later from a Sun Solaris host:





pkgrm EMCom






Installing Open Migrator/LM on Sun Solaris 47

48

Installation

Stopping daemon processesUnder certain conditions the kernel module could have busy text, in which case the software cannot be removed unless the daemon processes are stopped. For instance, if the Volume Management daemon vold(1M) has made a blocking call ioctl(2) to monitor removable media events in floppy disks or CD-ROM drivers, the vold(1M) daemon must be manually stopped. The software can then be removed, and the daemon can be restarted. This will allow the software to be removed without requiring a system reboot.

Note: Refer to your Sun Solaris package documentation for information regarding the availability of specific commands that can be used to collect and sort out process kernel stack traces to detect running daemon processes, which may cause the package remove command to fail.


Installation

Installing Open Migrator/LM on LinuxThis section describes how to install Open Migrator/LM for Linux software on a Red Hat Enterprise Linux (RHEL) Server or SuSE Linux Enterprise Server (SLES) host.

Please refer to Open Migrator/LM in E-Lab Navigator at http://Powerlink.EMC.com for supported platform and kernel version information prior to attempting installation. You should also refer to your EMC Open Migrator/LM for UNIX and Linux Version 3.12 Release Notes for specific environment and system requirements.

Note: Accessed from the Powerlink home page, move the cursor over the Support > Interoperability/Compatibility/Configuration > E-Lab Interoperability Navigator, and click Launch E-Lab Interoperability Navigator.

Note: If an existing version of Open Migrator/LM for Linux software is currently installed, it must first be removed before installing another version. Refer to “Removing the software from Linux” on page 52.

Perform the following steps to install Open Migrator/LM on a Linux host:


2. Copy the installation image .tar file to the /tmp directory and extract (untar) the .tar file. For example, type the following commands:

cp EMComlm.LINUX.tar /tmpcd /tmptar -xvf EMComlm.LINUX.tar

3. To install the software, for RHEL type:rpm --install EMCom-V3.12.0.x-rhel-y-z-as.rpm

(Where x is the actual EMCom version number, y is the OS version, z is the target hardware platform),

and for SLES type:rpm --install EMCom-V3.12.0.x-sles-10-spy-z.rpm

(Where x is the actual EMCom version number, y is the OS service pack number, z is the target hardware platform).

Installing Open Migrator/LM on Linux 49

50

Installation

For example, to install the software for RHEL version 5 on an i386 platform, type:

rpm --install EMCom-V3.12.0.x-rhel-5-i386-as.rpm

For example, to install the software for SLES version 10, SP 2 on s390x platform (z/Linux), type:

rpm --install EMCom-V3.12.0.x-sles-10-sp2-s390x.rpm

Note: The term “z/Linux” in this document is a short form of the official product name, Linux on System z.

Note: Insert the appropriate file name after the rpm --install command, according to your selected OS versions, updates and hardware platforms (i386, x86_64 or s390x).



Installation

Disk space considerationsRecommended free disk space for installation on a Linux host is 20 MB. In addition to the install footprint outlined below, there should be sufficient space reserved in the /etc file system to store properties files created by the stormigrate utility at run-time. Additional recommended free disk space should be equivalent to 10 KB per device pair in each defined session.


/etc/opt/EMCom/etc/opt/EMCom/bin/etc/opt/EMCom/omx/etc/opt/EMCom/bin/stormigrate/etc/opt/EMCom/driver/etc/opt/EMCom/driver/emcom.conf/etc/opt/EMCom/driver/emcom_hugemem/etc/opt/EMCom/driver/emcom_smp/etc/opt/EMCom/driver/emcom_up/etc/opt/EMCom/log/etc/opt/EMCom/man/etc/opt/EMCom/man/man4/etc/opt/EMCom/man/man4/emcom.4.gz/etc/opt/EMCom/man/man8/etc/opt/EMCom/man/man8/stormigrate.8.gz/etc/opt/EMCom/properties/etc/opt/EMCom/properties/session.bounds,a/etc/opt/EMCom/properties/session.bounds,b/etc/opt/EMCom/properties/session.dfltparms,a/etc/opt/EMCom/properties/session.dfltparms,b/etc/opt/EMCom/properties/sessions,a/etc/opt/EMCom/properties/sessions,b/etc/opt/EMCom/scripts/etc/opt/EMCom/scripts/addmod.sh/etc/opt/EMCom/scripts/addrcinit.sh/etc/opt/EMCom/scripts/addsymlink.sh/etc/opt/EMCom/scripts/copyright.emc/etc/opt/EMCom/scripts/initdb.sh/etc/opt/EMCom/scripts/remmod.sh/etc/opt/EMCom/scripts/remrcinit.sh/etc/opt/EMCom/scripts/remsymlink.sh

/var/EMCom/lic/var/EMCom/log


52

Installation


Removing the software from LinuxPerform the following steps to uninstall the Open Migrator/LM for Linux versions 3.8 and later software from a Red Hat Enterprise Linux Server or SuSE Linux Enterprise Server host:





rpm -qa|grep EMCom

Note: This entry returns the version number to be inserted in the next line (for example: EMCom-V3.11.0.12).

rpm --erase EMCom-<insert version #>





Installation




54

Installation


3Invisible Body Tag

This chapter provides instructions for using the Open Migrator/LM stormigrate command to manage data migration and comparison operations between data volumes.

◆ Session overview................................................................................ 56◆ Control operations ............................................................................. 58◆ Control operations - Data migration for failover cluster ............. 83◆ Special considerations for z/Linux migration............................... 97

Open Migrator/LMControl Operations

Open Migrator/LM Control Operations 55

56

Open Migrator/LM Control Operations

Session overviewData migration and comparison operations that use the stormigrate command are performed from a production host and are completed in sessions. Volume pairs consisting of source and target devices can be located on the same array or separate arrays. A device file can be used to specify a list of the volume pairs for the operation at the time the session is created, or pairs can be added to the session after it is created. The production host for the kernel driver must have access to the volumes for the session, and is responsible for controlling data migration between the volume pairs.

A session is first defined by using the stormigrate create command and specifying a session name. An additional option parameter (-file) can be used to define volume pairs by attaching a separate device file to the create command. Volume pairs listed in the device file can be identified by:

◆ physical device name (for example, /dev/rvol2)

◆ raw disk name (for example, /dev/rdsk/c1t1d3s2)

◆ database application volume pathname (for example, /dev/emc/ora3_tgt_9/rvol6).

Refer to “Creating a device file” on page 58 for instructions on how to create a device file for the session.

Note: With the exception of character devices of the raw(8) driver, Open Migrator/LM for Linux does not support character devices (rdsk).

Migrating data between storage arraysRefer to Figure 3 for a depiction and syntax example of an Open Migrator/LM session that has been created, activated, and is currently copying (migrating) data between the source and target volumes.

A device file (-file devpairfile) titled volume_pairs contains the pairing information for the source and target volumes. Volumes are specified by the raw disk and volume pathnames as follows:

/dev/rdsk/c3t0d44s2 /dev/rdsk/c4t0d22s2/dev/vx/rdsk/ora1_src_vg/rvol1 /dev/vx/rdsk/ora1_tgt_vg/rvol1/dev/ora2_src_vg/rvol2 /dev/ora2_tgt_vg/rvol2



Figure 3 Data migration using the stormigrate command

Data Migration

Copy Session

StorageArray 2

Volumec4t0d22s2



StorageArray 1


Volumec3t0d44s2


Application

EMC Open Migrator/LM

Device Control

SourceDevices

TargetDevices

Data Migration

ProductionHost

stormigrate create -session session1 -file volume_pairsstormigrate activate -session session1stormigrate copy -session session1

{ {

Session overview 57

58


Control operationsThe stormigrate command allows you to perform Open Migrator/LM control operations on a collection of volumes in a session. By using this command, you can do the following:

◆ Create a session to migrate or compare data between storage arrays.

◆ Add source and target volumes to a created session.

◆ Activate or deactivate a session.

◆ Pause or resume the copying or comparing of a session.

◆ Restart a failed session.

◆ Tune session performance at the kernel level.

◆ List, query, show, and verify sessions for current status.

◆ Set frequently used environmental variables.

◆ Delete a session.

◆ Clean up old session data to restore system to a clean state.

◆ Display session properties.

Note: For detailed syntax of the stormigrate command, refer to Appendix A, “Command Reference”.

Creating a device fileBefore creating a session, you can create a device file that contains a list of the source and target volume pairs for the operation. The device file must contain two columns (one for source devices and one for target devices) separated by spaces or tabs. Volumes listed in the device file can be specified either by their unique physical device name (for example, /dev/rvol2), raw disk name (for example, /dev/rdsk/c16t0d1), or database application volume pathname (for example, /dev/emc/ora3_tgt_9/rvol6).

Following is an example of various source and target volume pairing names:

/dev/rdsk/c16t0d0 /dev/emc/rdsk/ora1_tgt_9/vol4/dev/rdsk/c16t0d1 /dev/emc/rdsk/ora2_tgt_9/vol5/dev/rdsk/c16t0d2 /dev/emc/ora3_tgt_9/rvol6



/dev/ora4_src_9/rtpcb01_src_9 /dev/rvol16/dev/vx/rdsk/ora2_src_2/vol11 /dev/rvol2

Note: With the exception of character devices of the raw(8) driver, Open Migrator/LM for Linux does not support character devices (rdsk).

The source volume must always be listed in the first column of the device file. Lines in the device file that begin with a pound sign (#) will be ignored. The device filename (-file devpairfile) will be inserted into the command line for control operations.

If the device file contains blank lines, do not include spaces or tabs on that line. When the file is input to create the session, if spaces or tabs are encountered on a blank line, the following error message returns: "No source filespec on line x" (where x is the line number). This is because the line is not really empty and the parser expects a device name to be specified on that line.

Note: The file containing the device pair information cannot be empty. Comment lines must be preceded with a pound sign (#).

Example of a device fileA device text file that lists pairs of source and target volumes is shown in the following example:

Although the above example shows device pairs that migrate data from one distinct volume group to another volume group, this is not a requirement. Open Migrator/LM can be used to migrate data from source to target volumes within the same volume group or between separate volume groups.

# file name: volume_pairs_1# source and target volume pairs for migration session1# first column lists source devices# second column lists target devices# BEGIN/dev/ora1_src/rvol1 /dev/vx/rdsk/ora1_tgt/vol1/dev/vx/rdsk/ora2_src/vol2 /dev/ora2_tgt/rvol2/dev/ora3_src/rvol3 /dev/ora3_tgt/rvol3#/dev/vx/rdsk/ora4_src/tpcb01 /dev/vx/rdsk/ora4_tgt/tpcb01/dev/vx/rdsk/ora4_src/tpcb02 /dev/vx/rdsk/ora4_tgt/tpcb02/dev/vx/rdsk/ora4_src/tpcb03 /dev/vx/rdsk/ora4_tgt/tpcb03/dev/vx/rdsk/ora4_src/tpcb04 /dev/vx/rdsk/ora4_tgt/tpcb04/dev/vx/rdsk/ora4_src/tpcb05 /dev/vx/rdsk/ora4_tgt/tpcb05# END

Control operations 59

60


Note: If a new target volume group has been created for migrating logical volume data to, it is recommended that you export the original volume group and then import the new volume group with the same name as the original. The import and export should be done after the data has been migrated and validated for completion.

Guidelines for choosing volume pairsWhen choosing your source and target volumes for a copy session, use the following guidelines:

◆ If possible, choose source volumes that are closest to the application layer in the I/O stack. Refer to “I/O stack layers” on page 26 for an explanation of the I/O stack layers.

◆ Choose target volumes that are not already mounted.

◆ Ensure that the target volume is of the same size or larger than the source volume.

◆ If the storage environment includes additional hosts that have access to the target volume, set the target volume as not ready to those hosts.

◆ With the exception of character devices of the raw(8) driver, Open Migrator/LM for Linux does not support character devices. The software checks that character devices named in add and create commands are raw(8) driver character device special file nodes.

◆ A device pair cannot be added to a session if either of the devices in the device pair is part of another session that is active.

Note: When choosing target volumes within a Solaris environment, if devices are previously unused devices, they should be labeled.

Provisioning target volumesTarget volumes must be provisioned at the level in the I/O stack layer where the data will be accessed by the application after the migration has completed. If target volumes are logical volumes, the target volumes must be created and made ready for data access by Open Migrator/LM prior to creating the session. This is accomplished by using the volume manager’s administrative tools. For an explanation of the I/O stack layers within a UNIX/Linux OS kernel, refer to “I/O stack layers” on page 26.



Creating a sessionA session is first created by using the stormigrate create command to define a new session. The -session name option is used to define the session name. Optionally, you can specify a device text filename (-file devpairfile) that contains volume pairs for the operation. Refer to “Creating a device file” on page 58 for instructions on how to create the device file.

The session can be used to migrate data or to compare data on specific volumes. A session name is defined when creating the session. The session name can be any alphabetical or numeric character and cannot exceed 32 characters in length. Once the session has been created, volume pairs can be added to populate the session or additional pairs can be included beyond those identified in the device file. To define a session by using the stormigrate command for a device pair file, use the following example:

stormigrate create -session session1 -file volume_pairs_1

In the above example, the name of the session is identified as session1. The name of the device text file to be used for the session is specified as volume_pairs_1.

Note: With the exception of character devices of the raw(8) driver, Open Migrator/LM for Linux does not support character devices. The software checks that character devices named in add and create commands are raw(8) driver character device special file nodes.

Skipping the label sector on Sun SolarisWhen planning migrations for Sun Solaris systems, it is important to consider the possible presence of the Solaris disk label. If migrating to a target volume that includes a disk label sector, the application must share the space on the volume occupied by the disk label with the operating system. Because the Solaris default partitions s0 and s2 include a disk label sector, which is addressable by application programs, including Open Migrator/LM, they are vulnerable to being overwritten.

CAUTION!The consequences of overwriting a disk label can include data loss or data corruption.


62


If creating a session or adding devices to a session on a Sun Solaris host, you may need to skip the sector of the device that contains the device label (disk label block) during the migration process. Generally, the first cylinder (cylinder 0) contains the device label. Open Migrator/LM can detect session configurations that would result in an overwrite of the disk label on a SCSI target volume and will prompt the user to reissue either the create or add command to include the -skip_label_sector or -noskip_label_sector option to make any overwrite intentional.

If disks are formatted with Solstice Disk Suite or Solaris Logical Volume Manager metadevice disk partitions, you can use the -skip_label_sector option with the stormigrate create or add commands to exclude the label sector of the source metadevice from being copied to the target.

In Open Migrator/LM session configurations that include Solstice Disk Suite metadevices (md) 7 driver volumes, the md(7) driver will refuse any write request to the target volume disk label sector made by Open Migrator/LM. Without soft partitions or disk sets, the Solstice Disk Suite metadevice driver attempts to write to cylinder 0 of the target device, causing a target write error.

Open Migrator/LM performs a device validation process to determine if partitions s0 and s2 include a disk label sector. During this process, a notice is generated and logged by the Sun Solaris operating system with the device number (for example, "NOTICE: md:d13; write to label"). Note that despite the reporting of this operating system notification, no data was actually written to the disk label.

For Solstice one-on-one concatenated volumes, EMC recommends always including the -skip_label_sector option to avoid attempting to migrate the disk label block.

To include the disk label block to be copied in the migration, use the -noskip_label_sector option.



Table 2 shows the various device configurations for source and target devices including VTOC blocks, lists whether or not a warning message is generated, and describes any applied default action.

Note: EMC recommends including the -skip_label_sector option when you do not want the disk label block on the target to be overwritten.

For example, if you are migrating from a Solaris UFS partition without a disk label block (such as partition s3) to a Solaris UFS on partition cxtxdxs0 or s2, the -skip_label_sector option will ensure that the target device is still accessible. If you use -noskip_label_sector option, the target's disk label block would be overwritten, rendering the data inaccessible.

Likewise, if you were migrating from a partition with a disk label block to another partition with a disk label block (such as s2 to s2), you probably do not want to overwrite the target partition's label with the label from the source, so the -skip_label_sector option is the appropriate choice.

Note: If the device pairs to be migrated contain a mix of devices (some with a disk label block and some without), it is recommended that you do not include the devices within the same device file. This is because the -skip_label_sector and the -noskip_label_sector command options act globally on all device pairs contained within the device file.

Note: After EMC PowerPath is installed, you need know which devices in Solaris map to the emcpower devices if you would migrate emcpower devices with Open Migrator/LM. It depends on which Solaris native slice

Table 2 Open Migrator/LM use with VTOC blocks

Source device Target device Warning Default action

No disk label block No disk label block No -noskip_label_sector

No disk label block Disk label block Yes User decidesa

Disk label block No disk label block No -noskip_label_sector

Disk label block Disk label block Yes User decidesa

a. It is the user’s responsibility to decide whether to intentionally overwrite the disk label sector on the target device.


64


device which the emcpower device maps to determine whether whether -skip or -noskip should be used. Refer to EMC PowerPath manual for detailed instructions to find the mapping relationship.

Adding devices to a sessionThe stormigrate add command is used to associate volume pairs with a session. Volume pairs can be associated with a session in addition to those volumes that may have been defined with a device file at the time the session was created. The session must first be deactivated to associate volume pairs by using the add command. The source device is always listed first, followed by the target device.

To associate volume pairs with a session, use the following example:

stormigrate add -session session1 /dev/rdsk/c3t0d50s2 /dev/rdsk/c4t0d28s2stormigrate add -session session1 /dev/rdsk/c3t0d51s2 /dev/rdsk/c4t0d29s2stormigrate add -session session1 /dev/vx/rdsk/src_vg/vol3 /dev/vx/rdsk/tgt_vg/vol3

In the above example, three additional volume pairs were added to the session (session1). Volume pairs can be defined by either physical device name, database application volume pathname, or raw disk name.

Note: Using the stormigrate add command to add additional volume pairs does not modify the existing device file.

Note: The session must be activated before the kernel driver can establish the session for a copy or compare command action.

Note: A device pair cannot be added to a session if either of the devices in the device pair is part of another session that is active.

Note: With the exception of character devices of the raw(8) driver, Open Migrator/LM for Linux does not support character devices. The software checks that character devices named in add and create commands are raw(8) driver character device special file nodes.

If adding devices on a Sun Solaris host, refer to “Skipping the label sector on Sun Solaris” on page 61.



If adding share devices in cluster environment, refer to “Special rules for defining session for cluster migration” on page 93 .

Listing sessions You can list all of the currently defined sessions by using the stormigrate list command. This command returns status information for each session created from the operating host. The following example of the stormigrate list command displays a list of four current session names and their state.

stormigrate list

Session State-----------------------session1 Inactivesession2 Inactivesession3 Activesession4 Active

4 sessions found.


66


Showing session data You can display session configuration information for a specific session by using the stormigrate show command and specifying the session name. The following example displays the output from the stormigrate show -session command.

stormigrate show -session session1

MBSource Size Target ---------------------- ------ -----------------------/dev/rdsk/c3t0d44s2 10780 /dev/rdsk/c4t0d22s2/dev/rdsk/c3t0d45s2 10780 /dev/rdsk/c4t0d23s2/dev/rdsk/c3t0d46s2 10780 /dev/rdsk/c4t0d24s2/dev/rdsk/c3t0d47s2 10780 /dev/rdsk/c4t0d25s2/dev/rdsk/c3t0d48s2 10780 /dev/rdsk/c4t0d26s2/dev/rdsk/c3t0d49s2 10780 /dev/rdsk/c4t0d27s2/dev/rdsk/c3t0d50s2 10780 /dev/rdsk/c4t0d28s2/dev/rdsk/c3t0d51s2 10780 /dev/rdsk/c4t0d29s2*x/rdsk/src_vg/vol3 35920 *x/rdsk/tgt_vg/vol3

Session Name: session1Session State: ActiveAction Plan: CopyTask States: RunningNumber of Pairs: 9Total Source Size: 122160

Note: By default, source and target volume pathnames that are too long for the display are truncated to the left of the name. Truncated pathnames are identified by an asterisk (*) in the first character space. Use the -v option to display the complete pathname.

Note: Including the -summary option will display only the session summary data.

Note: Including the -cluster option will display the cluster migration state of share volumes in the cluster environment.



Activating a sessionThe stormigrate activate command is used to activate a session. When a session is activated, it becomes established in the kernel driver under the defined session name. To activate a session, one or more volume pairs (source/target) must have been previously added to the session or defined in a device file at the time the session was created.

To activate a session, use the following example:

stormigrate activate -session session1

Note: Target volumes should not be mounted when the session is activated.

Note: For data migration of share data volumes in cluster environment, Open Migrator/LM plugin-module should be added to cluster correctly before activating the session.

Note: Once a session has been activated, target volumes for the session will not be visible to the host operating system disk managers (for example, Solaris format utility, HP-UX SAM) or other third-party disk polling software (for example, syminq) until the session has been deactivated.

Deactivating a session To deactivate a session and remove it from the kernel driver, use the stormigrate deactivate command and specify the session name.

To deactivate a session, use the following example:

stormigrate deactivate -session session1

Note: Information for a session will be retained until the session is deleted.

Note: If the data volumes are still busy with application I/Os or mounted by filesystem, a prompt will be displayed to warn user of possible unsynchronized data between source and target volumes after session deactivation. Including the -noprompt option will bypass the prompt.

Note: No need to deactivate sessions explicitly for cluster migrations. Session is deactivated by Open Migrator/LM plugin during postmigration procedure.


68


Start device copyingTo begin volume copying for an activated session, use the stormigrate copy command. The copy command begins the transfer of data between the source and target devices associated with the session. The session must be activated before copying can begin. To begin transferring data from the source to target devices, use the following example:

stormigrate copy -session session1

Data copying operations are processed in the kernel driver for each task comprised in the session. When all subsequent copy tasks have completed, session volumes continue to be mirrored for as long as the session remains in an activated session state. You can check the session status for copy completion by using the stormigrate show, query or verify commands.

During copy operations, source volumes remain operational for I/O to its host and target volumes are read/write disabled. Target volumes should also be set as not ready to any additional attached hosts with access to volumes.

You can use the stormigrate query command to monitor the transfer copy rate of a session. The transfer copy rate by default is set to 1Mb/s. This transfer rate can be adjusted by setting the stormigrate tune -ceiling value. Refer to “Setting the target bandwidth” on page 71 for instructions.

Pausing the sessionA session that is currently copying or comparing data can be paused to temporarily stop task processing and can later be resumed from the point where it was paused. This feature can be useful if it becomes necessary to conserve system resources by resuming data copying at a later time. While the session is paused, session volumes continue to be mirrored to keep the source and target volumes synchronized for as long as the session remains in an activated session state. While the session is paused, the data blocks that have already been copied will continue to be mirrored and updated. This is similar to when a session completes and enters into mirror mode.

Additionally, from a paused state, you may choose to change the action state from a compare operation to begin copying or vice versa



from the beginning of the session. Refer to “Forcing a copy or compare action” on page 69.

To pause an active session to temporarily stop task processing, use the following example:

stormigrate pause -session session1

When a session is paused, all tasks for the identified session in the kernel driver are suspended at their current data volume offsets and saved.

Resuming the sessionResuming a paused session causes the kernel driver to continue any task from its paused data volume offsets. To resume a paused session, use the following example:

stormigrate resume -session session1

If the session was copying data when it was paused, the resume command will continue the copying of data from the point where it was paused.

Forcing a copy or compare action When a session is in a paused state, you may change the action to begin a copy or compare action from the beginning of the session. For example, to force a session to begin copying from the source to target devices from the beginning of the session, use the following example:

stormigrate copy -force -session session1

Alternately, you may choose to begin a compare operation to compare source and target data. The following example will force the session to begin a compare action between the source and target devices in the session.

stormigrate compare -force -session session1

CAUTION!Forcing a compare action on a session that was paused while actively copying could result in an incomplete volume copy between some or all source and target volumes in the session.


70


Deleting a sessionTo delete an existing session and remove it from the kernel driver, use the stormigrate delete command. If the session is currently activated, you must include the -force option to stop session tasks and force the deletion of the session. To delete an active session, use the following example:

stormigrate delete -session session1 -force

CAUTION!Forcing the deletion of an active session could result in an incomplete volume copy between some or all source and target volumes in the session.

Note: When migration completes, the session information can be preserved or deleted. You can preserve the session information by only deactivating the session.

Restarting a failed sessionA failed session can be restarted by using the stormigrate restart command to resume session tasks in the kernel driver from the beginning data volume offsets. Any failed session tasks with an error status or Mirror I/O Throttling (MIOT) status will begin operations again. To restart a failed session, use the following example:

stormigrate restart -session session1

Note: A restart operation should only be done after all other tasks in the session have completed.

Note: A restart operation may fail when there is any pending application I/O on source volume. Messages similar to the following are printed to syslog: Command DRU_IOC_SESS_RSTRT failed, session: session1; reason: data movers have pending i/o

Please try again later and this problem may disappear.

Note: For information on MIOT status, refer to “Setting the write performance ratio for mirrored pairs” on page 73.



Tuning session performanceThe system parameters for sessions can be tuned at the kernel level by using the stormigrate tune command. Tuning the session system parameters allows you to set data migration rates by adjusting the impact of I/O loading and mirroring performance. The tune command can be used to preserve system bandwidth for data migration during peak hours of operation. To view the tune parameters currently in effect, specify the tune command without any options. The tune command includes the following options: -iosize , -ceiling, -checkpointsize, -nthreads, -mio_perf_ratio, and -mio_recover_action.

Setting the I/O buffer sizeYou can set the input/output buffer size (in kilobytes) to be used for data transfers in a session by using the -iosize option. Values can range from 64 K to 128 K. The default setting is 64 K. Use the following example to set the I/O transfer buffer rate:

stormigrate tune -iosize 128

Note: Parameter changes made with the -iosize command affect only new sessions that have not yet been activated in the kernel driver.

Note: The parameter setting for the -iosize option must be reset in the event that the Open Migrator/LM software is removed and reinstalled.

Setting the target bandwidthYou can set the operating bandwidth (in megabytes) for target devices in all sessions by using the -ceiling option. Setting the bandwidth allows the software to throttle all data transfer operations so that the aggregate bandwidth remains at or below the set ceiling value. Values can range from 1 to 10,000 megabytes per second, depending on your system, with the default value being 1 MB.

To set the operating bandwidth for all sessions to 30 MB, type:

stormigrate tune -ceiling 30

You can set the maximum allowed bandwidth for your system by using the max qualifier. This will apply the maximum amount of bandwidth available for your system to all sessions.


72


Note: Setting the ceiling parameter to max may impact the performance of other programs running on the system.

Note: Refer to “Application performance considerations” on page 28 for additional information regarding I/O load and user application response time when setting the ceiling parameter.

To set the maximum allowed bandwidth for your system, type:

stormigrate tune -ceiling max

Note: Parameter changes made with the -ceiling option take effect immediately for all running sessions and will be in effect for all sessions that have not yet been activated in the kernel driver.

Note: The parameter setting for the -ceiling option must be reset in the event that the Open Migrator/LM software is removed and reinstalled.

Setting the property records update intervalYou can set the interval (in megabytes) at which the data mover’s property records are updated by using the -checkpointsize option. Setting this value allows you to control the frequency of the data mover’s data transfer offsets between updates to the task’s properties records. It also affects where to resume for persistency across reboot after a clean system shutdown.

Values can range from 32 to MAXINT. The default value is 256. Setting the value to NONE indicates that the data movers will not update the properties records. This parameter can be updated at any time and will have an immediate effect.

To set the update interval for property records for all sessions to 128 MB, type:

stormigrate tune -checkpointsize 128

Note: Parameter changes made with the -checkpointsize option take effect immediately for all running sessions and will be in effect for all sessions that have not yet been activated in the kernel driver.

Note: The parameter setting for the -checkpointsize option must be reset in the event that the Open Migrator/LM software is removed and reinstalled.



Disable Reboot PersistencyYou can disable reboot persistency by using the following command to set zero checkpoint size.

stormigrate tune -checkpointsize NONE -nop

For data migration for cluster, reboot persistency must be disabled before migration starts.

Setting the number of data mover threadsYou can set the size of the kernel module’s number of available threads that are used to process data mover tasks by using the -nthreads option. Setting this value allows you to control how many data mover threads are available in a fixed size cache allocated from the operating system. The value can be set from 1 to 64. The default value is 16. This parameter can be updated at any time and will have an immediate effect if increased. If the number of threads is decreased, the effect may be deferred until threads are idled. You may temporarily pause a session by using the stormigrate pause and resume commands to effectively idle the threads.

Open migrator tasks are queued for available thread use. Tasks are added to the queue in the order that they appear in their session definition. Once a thread is associated with a task, the association lasts until the task completes its action (copy or compare) or until the task is interrupted by a delete or pause command. When a task completes or is paused, its thread is returned to the cache and made available to any task waiting for an available thread. Sessions are added to the queue in the order in which they are activated.

To set the number of available data mover threads to 32, type:

stormigrate tune -nthreads 32

Note: Parameter changes made with the -nthreads option take effect immediately for all running sessions and will be in effect for all sessions that have not yet been activated in the kernel driver.

Note: The parameter setting for the -nthreads option must be reset in the event that the Open Migrator/LM software is removed and reinstalled.

Setting the write performance ratio for mirrored pairsThis feature (also called Mirror I/O Throttling or MIOT for short) provides you the capability to set the write performance ratio


74


between mirrored pairs, in order to lesson the impact of operating with a slower target device.

The performance ratio is the maximum allowable difference for operation between mirrored volumes in device pairs. The set ratio can range between 110 percent and 500 percent. A default value of 200 percent allows Open Migrator to tolerate copying and mirroring to target devices that are one half the speed of the source device.

You set the write performance ratio for mirrored pairs by using the -mio_perf_ratio option. This option works in conjunction with the recovery action option (-mio_recover_action), which allows you to apply a specific course of action if the ratio threshold is exceeded. Refer to “Setting a recovery action for mirrored pairs” below for more information.

If the operating threshold on some device pairs in an activated session are exceeded, then the copy, compare, or mirroring operation of those pairs can be terminated and the operation restarted at another time.

To set the performance ratio (MIOT) to 200 percent, type:

stormigrate tune -mio_perf_ratio 200

Note: Parameter changes made with the -mio_perf_ratio option take effect immediately for all running sessions and will be in effect for all sessions that have not yet been activated in the kernel driver.

Note: The parameter setting for the -mio_perf_ratio option must be reset in the event that the Open Migrator/LM software is removed and reinstalled.

For information on how to check the current MIOT performance ratio of device pairs in a session, refer to “Displaying performance statistics” on page 79.

Setting a recovery action for mirrored pairsYou can set a course of action for device pairs in a session that exceed the set performance ratio (-mio_perf_ratio) by using the (-mio_recover_action) option. The value can be set to either ignore, log, or terminate. If set to ignore, no action is taken. If set to log, a warning message is written to the system log. If set to terminate and Open Migrator is actively copying or comparing, the action is suspended but mirroring continues. If set to terminate and



Open Migrator is only mirroring, the mirroring will be disabled. The default setting is terminate.

When the threshold set in the -mio_perf_ratio has been exceeded while copy or compare operations are active, the task state for the affected device pair changes to MIOT1. The copy or compare task data mover is suspended, stopping the copy or compare action but continuing to mirror data. When the set threshold has been exceeded while copy or compare operations are not active, the task state for the affected device pair changes to MIOT2. The I/O mirroring function for the device pair is disabled. After all other session tasks have completed, the stormigrate restart command may be used to continue the session for incomplete MIOT tasks. All MIOT control events are recorded to the system log for future reference.

To set the MIOT recovery action for device pairs to log warning messages to the system log, type

stormigrate tune -mio_recover_action log

Note: Parameter changes made with the -mio_recover_action option take effect immediately for all running sessions and will be in effect for all sessions that have not yet been activated in the kernel driver.

Note: The parameter setting for the -mio_recover_action option must be reset in the event that the Open Migrator/LM software is removed and reinstalled.

Note: The throttling ratio check is conducted every two mintues. It reflects the accumlated state in last two minutes, but not real time state. Sometimes it may run into MIOT but there is no mirror I/O happening at that point of time. That's a known behavior.


76


Checking for MIOT task statesIt is important that you query all sessions for existing MIOT task states immediately before committing the migrated data. Note that active sessions which have completed copying and are left in a mirroring state could still encounter the MIOT task state. When all other session tasks have completed, use the stormigrate restart command to continue the session for incomplete MIOT tasks.

Table 3 MIOT task state table

MIOT state encountered

During task operation MIOT effect Upon restart operation

MIOT1 Copy • Copying suspended• Mirroring continues

• Mirroring continues• Copying resumes from point of suspension

MIOT2 Copy • Copying and mirroring suspended

• Copying and mirroring resumes from beginning of the volume

MIOT1 Compare • Compare suspended• Mirroring continues

• Mirroring continues• Compare resumes from point of suspension

MIOT2 Compare • Compare and mirroring suspended

• Mirroring restarts• Copying restarts from beginning of volume• When copying is complete, compare restarts

from the beginning of volume• Mirroring continues



To check the status of device pairs for tripped MIOT task states, use the stormigrate query command as shown in the following example.

stormigrate query -session session1 S D y o Current Task n Rate n KBSource Target Action State c KB/s % e Left----------------------- ----------------------- -------- ----- - ---- --- -------/dev/rdsk/c3t2d37s2 /dev/rdsk/c3t2d38s2 Copy MIOT1 N 0 1 4358144 ---- --- -------Total Copy: 0 1 4358144Total Compare: 0 0 0

Session Name: 123Session State: ActiveAction Plan: CopyTask States: MIOTMoverSuspendedNumber of Pairs: 1Total Source Size: 4417920 KBSystem I/O Processing: MIRRORINGTarget Devices State: NRTime: 14:45:23

Warning: Mirror I/O throttling (MIOT) controls have beenapplied to tasks of this session. The task state MIOT1indicates that MIOT has suspended the task data mover.The task state MIOT2 indicates that MIOT has disabled thetask I/O mirroring function. The restart command may beused to continue this session. Check system logs forMIOT control event notifications. Refer to the productdocumentation for more information concerning MIOT.

The above example shows that the device pair in session1 has tripped the MIOT1 task state and that the data mover for the task has been suspended.

Verifying session statesYou can use the stormigrate verify command to poll for the completion status of an activated session. The command returns completion status information once, or in intervals (-i) for a defined count (-c). If the session encounters an error, the command returns a non-zero exit code. To poll the session status every 60 seconds for a total of 10 times, use the following example:

stormigrate verify -session session1 -int 60 -c 10


78


The session status information displays whether the copy or compare operation is completed.

Note: If the (-c) option is not specified and an interval (-i) is specified, the program continuously displays status information until the session either completes or returns an error status.

Querying session statusTo query the status of a kernel driver session, use the stormigrate query command. Optionally, the session can be queried in intervals (-i) for a specified count (-c).


stormigrate query -session session1

s Dy o

Current Task n Rate n MBSource Target Action State c MB/s %e Left------------------- ------------------- ------- ----- -- ----- --- -----/dev/rdsk/c3t0d44s2 /dev/rdsk/c4t0d22s2 Copy Run N 18 16 9055/dev/rdsk/c3t0d45s2 /dev/rdsk/c4t0d23s2 Copy Run N 7 10 9702/dev/rdsk/c3t0d46s2 /dev/rdsk/c4t0d24s2 Copy Run N 18 20 8624/dev/rdsk/c3t0d47s2 /dev/rdsk/c4t0d25s2 Copy Run N 15 15 9163/dev/rdsk/c3t0d48s2 /dev/rdsk/c4t0d26s2 Copy Run N 10 15 9163/dev/rdsk/c3t0d49s2 /dev/rdsk/c4t0d27s2 Copy Run N 14 10 9702/dev/rdsk/c3t0d50s2 /dev/rdsk/c4t0d28s2 Copy Run N 5 20 8624/dev/rdsk/c3t0d51s2 /dev/rdsk/c4t0d29s2 Copy Run N 12 16 9055*x/rdsk/src_vg/vol3 *x/rdsk/tgt_vg/vol3 Copy Run N 16 10 32328

--- --- -----Total Copy: 115 15 76680Total Compare: 0 0 0

Session Name: session1Session State: ActiveAction Plan: CopyTask States: RunningNumber of Pairs: 9Total Source Size: 122160System I/O Processing: MirroringTarget Devices State: NR



Note: Including the -summary option displays only the cumulative summary data for the session.

Displaying performance statisticsTo query statistical performance data for device pairs in your session, use the stormigrate query command with the -miostats option. This option displays the current mirror I/O performance percent (%) ratio of device pairs in migration.

If the target device is operating at a slower pace than the source device, then a percentage is displayed in the MIO Performance Ratio column. For example, the target device shown in the first device pair is operating 9 percent slower than the source device.

stormigrate query -session ombig -miostat

Current Performance Ratio for Task Pairs are

Source Target MIO Perf. %----------------------- ----------------------- ---------------*x/rdsk/ora1_src_3/vol1 /dev/ora1_TGT_1/rvol1 9 /dev/ora2_src_3/rvol2 *x/rdsk/ora2_TGT_1/vol2 43 /dev/rdsk/c4t0d4 /dev/rdsk/c10t1d0 46 /dev/ora5_src_3/rvol5 *x/rdsk/ora5_TGT_1/vol5 26 *x/rdsk/ora6_src_3/vol6 /dev/ora6_TGT_1/rvol6 21 *x/rdsk/ora7_src_3/vol7 *x/rdsk/ora7_TGT_1/vol7 15 *rdsk/ora4_src_3/tpcb01 *rdsk/ora4_TGT_1/tpcb01 30 *rdsk/ora4_src_3/tpcb02 *rdsk/ora4_TGT_1/tpcb02 28 *rdsk/ora4_src_3/tpcb03 *rdsk/ora4_TGT_1/tpcb03 43 *rdsk/ora4_src_3/tpcb04 *rdsk/ora4_TGT_1/tpcb04 31 *rdsk/ora4_src_3/tpcb05 *rdsk/ora4_TGT_1/tpcb05 26 *rdsk/ora4_src_3/tpcb06 *rdsk/ora4_TGT_1/tpcb06 27 *rdsk/ora4_src_3/tpcb07 *rdsk/ora4_TGT_1/tpcb07 34 *rdsk/ora4_src_3/tpcb08 *rdsk/ora4_TGT_1/tpcb08 34

stormigrate query -session session1 -summary

Session Name: session1Session State: ActiveAction Plan: CopyTask States: RunningNumber of Pairs: 9Total Source Size: 122160System I/O Processing: MirroringTarget Devices State: NRAction Summary: MB MB MB/s %

Action Size Left Rate Done------- ------- ------ ---- ----Copy 122160 76680 99 37


80


*rdsk/ora4_src_3/tpcb09 *rdsk/ora4_TGT_1/tpcb09 41 *rdsk/ora4_src_3/tpcb10 *rdsk/ora4_TGT_1/tpcb10 11 *dsk/ora4_src_3/tpcb100 *dsk/ora4_TGT_1/tpcb100 0 *dsk/ora4_src_3/tpcb101 *dsk/ora4_TGT_1/tpcb101 0 *dsk/ora4_src_3/tpcb102 *dsk/ora4_TGT_1/tpcb102 -*dsk/ora4_src_3/tpcb103 *dsk/ora4_TGT_1/tpcb103 -*dsk/ora4_src_3/tpcb104 *dsk/ora4_TGT_1/tpcb104 0

If the performance ratio displays as 0, this means that the target device is operating at a pace that is faster or equal to that of the source device. If the performance ratio displays as a dash (-), this means that at the present time there is not enough I/O being generated to accurately calculate the performance percentage ratio for the device pair.


Comparing session dataThe stormigrate compare command is used to verify source and target volume synchronization. The compare command can be used to compare data between source and target volumes before or after using the copy command to migrate data. To compare source and target volumes in a session, use the following example:

stormigrate compare -session session1

Note: To view the comparison data for a given session, use the stormigrate query or show commands.

Setting environmental variablesYou can view the available environmental variables that can be set for a session by using the stormigrate -env command. Variables can be defined for the session name (-session name), filename (-file devpairfile), interval (-i) and count (-c) options to default to a user-specified value. The syntax for setting environmental variables depends on your specific command shell (for example, csh, ksh, sh). The current setting of these variables can be displayed by using the stormigrate -def command.



Display session propertiesTo display the various properties of all defined sessions on the system, use the stormigrate props command. Displayed properties include session, task, and action information. When used with the -session name option, displays the properties of a particular session.

To display the properties of all sessions on the system, type:

stormigrate props

To display the properties of a named session, use the following example:

stormigrate props -session session1

The following example displays the output from the stormigrate props-session command.

stormigrate props -session session1session:session ID :session1session creator uid/euid: 0/0session creator gid/egid: 1/1session create time: Tue Jan 17 12:12:17 2006session action: Passthrusession tasks:

Clean up old session dataYou can delete all defined sessions from the system including any configuration files that are maintained as part of the sessions by using the stormigrate cleanup command. This command is used to initialize the state of the system to a clean state. When used with the -all option, any log files residing in the /var/EMCom/log will also be deleted.

To delete all sessions on the system, including the log files and return the system to a clean state, type:

stormigrate cleanup -all

WARNING: Cleanup will delete all defined sessions and log filesAre you sure you want to cleanup the configuration[Y/N]?YThe configuration was removed successfully

Note: It is recommended you use the cleanup command before removing the Open Migrator/LM software from the system.


82


Note: For selective deletion capability and to maintain certain log files, use the delete command to select individual sessions for deletion.

Postmigration proceduresOnce volumes have been successfully migrated, applications can be redirected to use the new target volumes. The only point of disruption in the migration process is re-pointing the application to use the new target volumes so that the source volumes could potentially be re-purposed.

Note: For cluster migrations, refer to “Post migration procedure for cluster migrations” on page 92. The following example is for standalone environment only.

For example, in the case of migrating under a file system application, a basic process would include the following steps:

1. Quiesce/stop the application.

2. Ensure that all buffers have been written out to disk by running the sync command (that is, sync;sync;sync).

3. Unmount the source devices.

4. Deactivate the Open Migrator/LM session (that is, stormigrate deactivate -session name).

5. Change the device special file section designating mount specification (that is, /etc/fstab) from the source volume to the target volume.

6. Mount the target devices.

If satisfied with the integrity of the file system and data on the target volume, the old source volume could now be re-purposed and the session deleted.

Note: Once data has been migrated, it is the responsibility of the user to determine the best process for re-pointing their database management application to the new devices.



Control operations - Data migration for failover clusterThis section provides general guidelines for data migration for failover cluster planning with Open Migrator/LM. If no cluster name is specified, the term "cluster", mentioned below, means all supported cluster platforms including HP Serviceguard, IBM HACMP and Veritas Cluster Server for Solaris.

All those clusters support applications running on one node at a time(a.k.a failover cluster, active-passive cluster) or on multiple nodes at the same time(a.k.a parallel cluster, active-active cluster). However, Open Migration/LM support is for failover cluster only.

As a prerequisite, EMC recommends that the user posses a thorough understanding of cluster environment and their special configuration before attempting to migrate data.

Note: For specific HP Serviceguard product information and relevant articles on clustering, troubleshooting, installation, and management, refer to the HP website at http://www.hp.com.

Note: For specific IBM HACMP product information and relevant articles on clustering, troubleshooting, installation, and management, refer to the IBM website at http://www.ibm.com.

Note: For specific Veritas Cluster Server for Sun Solaris product information and relevant articles on clustering, troubleshooting, installation, and management, refer to the Symantec website at http://www.symantec.com.

Migration in cluster environment requires that both source volumes and target volumes are cluster-capable and available to all cluster nodes. Source and target volumes can reside in one array or different arrays. Open Migration/LM only needs to be installed on the active node, which has full control of source and target volumes.

Control operations - Data migration for failover cluster 83

84


Figure 4 Migration in a clustered environment

Generally Open Migrator/LM provides two solutions for data migration for failover cluster. You can select either one to migrate data volumes in cluster environment.

Data Migration

Copy Session

Storage Array 2

Volume c4t0d22s2

Volume ora1_tgt_ vg/rvol1

Volume ora2_tgt_ vg/rvol2

Storage Array 1

Volume ora1_src_ vg/rvol1

Volume c3t0d44s2

Volume ora2_src_ vg/rvol2

Application

EMC Open Migrator/LMDevice Control

Source Devices

Target Devices

Data Migration

Active Node

{ {

Passive Node

FailoverCluster



Solution I: Migration with cluster failover disabledThis solution is to disable cluster auto-failover functionality during the whole migration process. Open Migrator/LM is installed on the active node, which has exclusive access to the data volumes of the cluster until auto-failover enabled again after migration done. Migration can be executed on the active node just as standalone (non-cluster) host environment.

As one step of the postmigration procedure, applications need be shutdown for repointing to target volumes. This step may fail with errors or warnings, which can be ignored, because the cluster is unable to deactivate volume group since Open Migrator/LM is still active and holds the migration volumes. You should look at cluster and system logs to verify that is the only issue and to verify that file systems are unmounted before deactivating the active OM session, the cluster/application is reconfigured to use the target volumes and restarted with failover functionality enabled.

Note: Before starting data migration, reboot persistency must be disabled for cluster migrations. Refer to “Disable Reboot Persistency” on page 73 in Control Operations

Note: To disable auto-failover of a package on HP Serviceguard, the following command can be used (for example: package name is "pkg"):# cmmodpkg -d pkg

Note: To disable cluster failover on IBM HACMP cluster, you need stop cluster services on all passive cluster nodes.# smitty hacmp System Management (C-SPOC) -> Manage HACMP Services -> Stop Cluster Services

Note: To disable auto-failover of service group on Veritas Cluster Server for Sun Solaris, the following command can be used(for example: service group name is "grp"):# hagrp -modify grp AutoFailOver 0


86


Solution II: Migration with cluster failover enabledThis solution introduces a new Open Migration/LM plugin for cluster so that you can do data migration with cluster failover enabled. Although the solution I is easy and simple to deployment, it sacrifices high-availability of cluster during migration. Solution II improves this and allows planned or unplanned cluster failover during data migration. Migration stops if cluster failover happens and the applications can still switch to another node of the cluster. When failover happens, you need to reschedule the migration again from the beginning.

The following illustration is a general procedure for cluster migration using solution II.

Figure 5 General procedure for cluster migration

Add Open Migrator/LM plugin for cluster

Disable reboot persistency

Create sesson for data volumes of cluster

Activate session

Start device copying

Verify migration completion

Post migration procedure



With solution II, the differences for migrations in cluster environment comparing with standalone environment include:

◆ Pre-migration

For migration in cluster environment, an Open Migrator/LM plugin need be added into cluster software. Refer to "“Add Open Migrator/LM plugin for cluster” on page 87" for detailed steps.

◆ Defining a session

Refer to "“Special rules for defining session for cluster migration” on page 93" for more information.

◆ Disable reboot persistency

Before starting data migration, reboot persistency must be disabled for cluster migrations. Refer to "“Disable Reboot Persistency” on page 73" for more information.

◆ Post Migration

The post migration steps are different for migration in cluster and standalone environment. Refer to "“Post migration procedure for cluster migrations” on page 92" for details.

Note: With solution II, Open Migrator/LM does not support migrating share physical disks, raw disks etc with failover cluster. Only logical volumes are supported.

Add Open Migrator/LM plugin for cluster

Note: This procedure is only needed for migrations in cluster environment based solution II.

Note: This procedure brings no interruption to the cluster. The plugin can be effective immediately after being added to the cluster.

The Open Migrator/LM plugin for cluster is provided to release Open Migrator/LM's references to volumes when the application is shutdown, so that application failover can be executed without unexpected device busy issues. Since cluster programming interfaces are different, the Open Migrator/LM plugin for different clusters are different and the procedures are cluster-dependent.


88


Add plugin for HP ServiceguardTo add the plugin for HP Serviceguard cluster:

1. On the active node:

# mkdir /etc/cmcluster/modules/emcom# cp /etc/opt/EMCom/cluster/hpsg/emcom.0 /etc/cmcluster/modules/emcom/# ln -s /etc/cmcluster/modules/emcom/emcom.0 /etc/cmcluster/modules/emcom/emcom# mkdir /etc/cmcluster/scripts/emcom # cp /etc/opt/EMCom/cluster/hpsg/emcom.sh /etc/cmcluster/scripts/emcom/

2. Check if the module is added successfully to ServiceGuard:

# cmmakepkg -l….

emcom/emcom (0) Volume migration support provided by EMC Open Migrator

….

3. Copy emcom.0 and emcom.sh to other nodes and add the module as the first node.

4. Add dependency of Open Migrator plugin to packages:

For example, the package name is "testpkg" and you are going to migrate data volumes which the package depends on.

Note: The package should be modular package introduced by HP Serviceguard since A11.18. Legacy packages generated by earlier versions are not supported.

Note: The package type should be "failover". Packages with "multi_node" or "system_multi_node" type are not supported.

4.1 Generate package configuration file:

# cmgetconf -p testpkg /etc/cmcluster/pkg/testpkg/testpkg1.conf



4.2 Generate new package configure file:

# cmmakepkg -i /etc/cmcluster/pkg/testpkg /testpkg.conf -m emcom/emcom/etc/cmcluster/pkg/ testpkg/testpkg2.conf

Note: Do not overwrite the original package conf file. We would use the original package conf file to revert it back after migration completion.

4.3 Validate and apply the configuration changes

# cmcheckconf -v -P /etc/cmcluster/pkg/testpkg/testpkg2.conf# cmapplyconf -P /etc/cmcluster/pkg/testpkg/testpkg2.conf

Add plugin for IBM HACMPTo add the plugin for IBM HACMP cluster only on active node:

# mv /usr/es/sbin/cluster/events/utils/cl_deactivate_vgs /usr/es/sbin/cluster/events/utils/cl_deactivate_vgs.orig# cp /etc/opt/EMCom/cluster/hacmp/cl_deactivate_emcom /usr/es/sbin/cluster/events/utils/# cp /etc/opt/EMCom/cluster/hacmp/cl_deactivate_vgs /usr/es/sbin/cluster/events/utils/

Add plugin for Veritas Cluster ServerTo add the plugin for Veritas Cluster Server cluster for Sun Solaris:

1. Add EMCom plug module files under cluster directory (/opt/VRTSvcs/bin/) on all cluster nodes. Run the following commands on active node. The example cluster includes two nodes, the active node named "node1" and the passive node named "node2":

# cp -rf /etc/opt/EMCom/cluster/vcs/EMCom /opt/VRTSvcs/bin/# scp -r /opt/VRTSvcs/bin/EMCom node2:/opt/VRTSvcs/bin/

2. On active node, add new agent named EMCom, which has attributes of "Volumes" and "DiskGroup":

# haconf -makerw# hatype -add EMCom# hatype -modify EMCom SourceFile "./emcom.cf"# haattr -add EMCom Volume -string -scalar# haattr -add EMCom DiskGroup -string -scalar# hatype -modify EMCom ArgList Volume DiskGroup


90


3. Add dependency of Open Migrator/LM plugin for service groups

For example, the service group name is "grp" which is online on node1. The service group has one disk group named "src_dg" and it includes a Mount resource named "res_mnt" and a Volume resource named "res_vol" on the disk group.

3.1 Add a new "emcom" resource of above EMCom type with the "DiskGroup" attribute being specified as the disk group (here is "src_dg" for example). Each disk group requires a new resource of EMCom type.

# hares -add emcom EMCom grp# hares -modify emcom DiskGroup src_dg# hares -modify emcom Critical 0# hares -modify emcom Enabled 1# hares -online emcom -sys node1

Note: By default, the EMCom type resource ("emcom") works at the disk group level where only the "DiskGroup" attribute is specified for the "emcom" resource and the single "emcom" resource for the disk group depends on all the volume resources in the disk group. The EMCom type resource can also work at the volume level where both "DiskGroup" and "Volume" attributes are specified and the "emcom" resource just depends on the single volume resource specified by the corresponding "Volume" attribute. See the notes about the "DiskGroup" and "Volume" attributes in the section “Special notes for cluster migrations” on page 94 for more details.

3.2 Link the new "emcom" resource between each filesystem mount and logical volume resources pair corresponding to the disk group specified as the "DiskGroup" attribute of the new EMCom type resource. If there is no filesystem mount resource, link EMCom between application/service and logical volume resources. Generally, the dependency tree resembles: Application -> Mount -> EMCom -> Volume -> DiskGroup.

# hares -unlink res_mnt res_vol# hares -link res_mnt emcom# hares -link emcom res_vol# haconf -dump -makero



Note: If there are multiple volumes resources that belong to the same disk group, link the "emcom" resource for all the Mount and Volume resources pair. See also the notes about the "DiskGroup" and "Volume" attributes in the section “Special notes for cluster migrations” on page 94.

3.3 Check the cluster and service group state, and make sure the service group is still online on the active node node1.

# hastatus -sum

Remove Open Migrator/LM plugin for clusterSince cluster programming interfaces are different, the Open Migrator/LM plugin for different clusters are different and the removal procedures are cluster-dependent.

Note: This procedure is only needed for migrations in cluster environments based on solution II.

Remove plugin for HP Serviceguard clusterTo remove the plugin for HP Serviceguard cluster:

1. Remove files of the plugin:

On all cluster nodes:

# rm /etc/cmcluster/modules/emcom/# rm /etc/cmcluster/scripts/emcom/

2. Remove the dependency of Open Migrator/LM plugin from the package

Restore the package configuration from the original package configuration file generated by section "Add Open Migrator/LM plugin to cluster"

# cmcheckconf -v -P /etc/cmcluster/pkg/testpkg/testpkg1.conf# cmapplyconf -P /etc/cmcluster/pkg/testpkg/testpkg1.conf


92


Remove plugin for IBM HACMP clusterTo remove the plugin for IBM HACMP cluster:

# cd /usr/es/sbin/cluster/events/utils/# mv cl_deactivate_vgs.orig cl_deactivate_vgs# rm cl_deactivate_emcom

Remove plugin for Veritas Cluster Server for Sun SolarisTo remove the plugin for Veritas Cluster Server for Sun Solaris:

1. Remove the emcom resource and its agent

# haconf -makerw# hares -delete emcom# hatype -delete EMCom

2. Restore the dependency tree

# hares -link res_mnt res_vol

3. Remove OM module files from /opt/VRTSvcs/bin/ on all cluster nodes

# rm -rf /opt/VRTSvcs/bin/EMCom

Post migration procedure for cluster migrations

Note: This procedure is only for migrations in cluster environments based on solution II.

The post migration procedure for cluster migrations includes:

1. Verify migration completes successfully.

2. Run the stormigrate complete -s <session name> command to mark the migration success for the cluster.

3. Halt the package on HP Serviceguard(or resource group on IBM HACMP or service group on Veritas Cluster Server on Sun Solaris) using cluster specific tools. The Open Migrator/LM plugin will automatically deactivate the session which is migrating the corresponding volumes



4. Check Open Migrator/LM cluster log (e.g. /var/EMCom/log/EMCom-cluster-V3.12.0.8-2010-06-09.log) to make sure migration is completed successfully.

2010-06-09 05:09:50 INFO Deactivating OM session t ...2010-06-09 05:09:51 INFO Session t completed successfully for the cluster

5. Remove the Open Migrator/LM plugin from cluster.

6. Reconfigure the package on HP Serviceguard(or resource group for IBM HACMP, or server group for Veritas Cluster Server on Sun Solaris) to use the target volumes by using cluster specific tools.

7. Restart the package on HP Serviceguard(or resource group for IBM HACMP, or server group for Veritas Cluster Server on Sun Solaris) with failover enabled using cluster specific tools.

Most cluster specific tools and commands are needed for above post migration procedure. Refer to "Appendix B, “Examples,”" on how to do that for HP-UX ServiceGuard, IBM HACMP and Veritas Cluster Support on Sun Solaris.

Special rules for defining session for cluster migration

Note: This information is only for migrations in cluster environments based on solution II.

To migrate shared volumes in failover cluster environment, there are some special considerations that need be noticed when defining the session. Violation of those rules may result to unexpected data migration failure.

◆ It is not allowed to add shared data volumes and non-shared data volumes (only visible at local node) to one session.

◆ It is not allowed to add shared data volumes addressed by different applications in one session.


94


Special notes for cluster migrations

Note: This information is only for migrations in cluster environments based on solution II.

Special notes for cluster migration include:

◆ To prevent auto-failover after migration completes, which will cause the migration fail for the cluster, the system administrator can disable the auto-failover functionality to "lock" the volumes to the migrating node after verifying the migration completes and before marking the migration session complete successfully for the cluster.

To disable failover on HP Serviceguard:

# cmmodpkg -d test_pkg1

To disable failover of some service group(e.g name "om_grp") for Veritas Cluster Server on Sun Solaris:

# hagrp -modify om_grp AutoFailOver 0

To disable cluster failover on IBM HACMP cluster, you need stop cluster services on all passive cluster nodes:

# smitty hacmp System Management (C-SPOC) -> Manage HACMP Services -> Stop Cluster Services

◆ The following warning messages will be logged in the package log file if the running package is in failover status to the other nodes or is down for some other reasons while doing migration:

2010-06-09 06:09:50 WARN Session t migration failed for cluster due to application failure and/or auto failover

If the migration completed and was marked as "complete" via stormigrate complete -session t, the warning message will be similar to the following:

2010-06-09 06:09:50 WARN Session t migration failed for the cluster due to application failure and/or auto failover although completed



◆ For HP Serviceguard cluster, Open Migrator/LM supports modular failover package in SG A11.19 and does not support the legacy packages.

◆ For IBM HACMP cluster, Open Migrator/LM only supports non-concurrent (failover) resource group in HACMP (PowerHA) 5.5 and does not support concurrent resource group. OM does NOT support HACMP/XD (extended distance) software solutions for disaster recovery (either for GLVM or for Metro Mirror).

◆ For Veritas Cluster Server on Sun Solaris, Open Migrator/LM supports only failover service group, where each resource like volume can only be available to (active on) one node at a time. Open Migrator/LM supports only Veritas Logical Volume as the migration source since physical disks or multiple path (DMP or PowerPath) disks are outside of VCS control.

◆ For HP Serviceguard or IBM HACMP cluster, any Open Migrator/LM session will be deactivated as long as it contains any logical volumes (regardless source or target) configured in the cluster package (or resource group for HACMP). As a result, to ensure data consistency, all the volumes contained in an Open Migrator/LM session must belong to only one cluster package (or resource group for HACMP). In practice, there is one Open Migrator/LM session for each cluster package (or resource group for HACMP), though each package (or resource group for HACMP) can have multiple migration sessions.

◆ For Veritas Cluster Server on Sun Solaris, any session will be deactivated as long as they contain any logical volumes (regardless source or target) configured in the cluster service group, since by default only "DiskGroup" attribute can be specified for the "emcom" resource and the single "emcom" resource for a disk group depends on all the volumes in the disk group. As a result, to ensure data consistency, all the volumes contained in an Open Migrator/LM session must belong to only one disk group in a cluster service group. In practice, there is one Open Migrator/LM session for each cluster service group with one disk group, though each service group can have multiple migration sessions (e.g. for multiple disk groups in a service group).

There is only EMCom agent (resource type) in the whole cluster, and there is an emcom resource of EMCom type for each disk group in a service group.


96


However sometimes the "Volume" attribute of "emcom" resource has to be specified too along with the "DiskGroup" attribute. The followings are two typical scenarios:

• The user is concerned about the potential SPOF (single point of failure) by introducing a new "emcom" resource for multiple volumes in a disk group, since the single new "emcom" resource depends on all the volumes to be migrated. To avoid this problem, just create a new "emcom" resource for each volume and specify the "Volume" attribute of the "emcom" resource too besides the "DiskGroup" attribute. As a result, a "emcom" resource only depends on a volume. Each volume must be put into an independent separate Open Migrator/LM migration session in such case.

• If two service groups share a disk group, the dependent (parent) group must create a separate new "emcom" resourece for each volume in the disk group and the service group and specify the "Volume" attribute of the "emcom" resource too besides the "DiskGroup" attribute. Each volume in the dependent (parent) group must be put into an independent separate Open Migrator/LM migration session in such case.

◆ For IBM HACMP cluster, an AIX node crash happens with the message "RSCT Dead Man Switch Timeout for PSSP" when the system load is too high, preventing the heartbeat thread to be scheduled for a period of time. It is documented by IBM as a known behavior.

Refer to the IBM Cluster information center (http://publib.boulder.ibm.com/infocenter/clresctr/vxrx/topi/com.ibm.cluster.infocenter.doc/infocenter.html) RSCT Library -> Diagnosis Guide -> Error symptoms, responses, and recoveries -> Action 9: investigate an AIX node crash

To solve this problem, you can adjust the timeout setting as below:

# smit hacmpExtended Configuration > Extended Topology Configuration > Configure HACMP Network Modules

Change the parameters "Failure Cycle" and "Hearbeat Rate" to your own chosen values.



Special considerations for z/Linux migration

Note: The term “z/Linux” in this document is a short form of the official product name, Linux on System z.

DASD device blocksize and application I/O size on z/LinuxOn z/Linux, DASD devices can be formatted via dasdfmt(8) to have blocksize from 512 to 4096 bytes, and the recommended blocksize is 4096 bytes. The blocksize is the hardware sector size of the DASD devices and is the smallest I/O unit. Any low level I/O size to disk hardware (either DASD devices or SCSI devices) must be hardware sector size alignment. For example, a 512-bytes I/O cannot be issued to a disk with 4096-bytes hardware sector size.

On the other hand, applications (e.g. filesystem or database) have their own logical block size which has to be equal to or multiple of disk hardware sector size.

There is a migration limitation in nature for any migration tools, not specific to EMC Open Migrator/LM for Linux. That is, a filesystem on the source disk can NOT work on the target disk if the hardware sector size of the source disk is less than the hardware sector size of the target disk (e.g. 512-bytes for source and 4096-bytes for target) AND the logical block size (e.g. 1024-bytes) of the file system is less than the hardware sector size of the target disk, even if we can successfully migrate it. It is a migration limitation in nature because the file system logical block size must be equal to or greater than the underlying disk hardware sector size.

Fortunately, most times, the file system logical block size is 4096 bytes. Thus migration tools are able to support most common migration configurations, e.g. from a SCSI (512) to DASD (4096) as long as the filesystem also has 4096 bytes logical block size.

Migration configurations supported by Open Migrator/LM for Linux are:

1. Migrations between disks with same hardware sector sizes, such as from DASD (4096) to DASD (4096); SCSI (512) to SCSI (512).

Special considerations for z/Linux migration 97

98


2. Migrations from source disks to target disks when the hardware sector size of source disks is greater than that of target disks, such as from DASD (4096) to SCSI (512); from DASD (4096) to DASD (512).

3. Migrations from source disks to target disks when the hardware sector size of source disks is less than that of target disks and applications I/O must also meet all the following conditions:

• The file system block size (or database record size) is greater than or equal to the hardware sector size of target disks;

• The file system is already created on source disks before migration (it means that you can NOT make a filesystem while migration is going on in this case);

• Direct I/O (if any) size must be greater than or equal to the hardware sector size of target disks.

For example, when going from SCSI (512) to DASD (4096), and the filesystem block size on source disk is also 4096 bytes; from DASD (1024) to DASD (4096), and the filesystem block size on source disk is also 4096 bytes.

On the other hand, the following unsupported migration configurations and operations will fail and system log will have I/O errors:

1. Migrations from DASD (512) to DASD (4096) is running, then making a filesystem on the source DASD disk.

2. Migrations from SCSI (512) to DASD (4096) where the filesystem on source SCSI disk have logical block size of 1024 bytes.

3. Migrations from DASD (512) to DASD (4096) where a direct I/O with size of 1024 is issued to source DASD disk.

DASD device partitions and whole disk support on z/LinuxDASD disk can support three kinds of partitions (CDL, LDL, CMS), which are all supported by Open Migrator/LM for Linux. The whole disk, which is formatted with CDL/CMS disk layout, is NOT supported to be configured as the migration device (source or target). The whole disk, which is formatted with LDL disk layout, can be configured to the migration device (source or target), though it's not recommended.



Refer to IBM Document SC33-8411-01 Device Drivers, Features, and Commands for Linux on System z for detailed information on dasdfmt(8), and additional information on disk layout.

Special considerations for z/Linux migration 99

100



A

This appendix describes the stormigrate command for data migration operations.

◆ Conventions ...................................................................................... 102◆ stormigrate ........................................................................................ 103

Command Reference

Command Reference 101

102

Command Reference

ConventionsThe categories of information shown below (similar to UNIX man pages) are listed for the stormigrate command, where applicable.

◆ Command name appears in bold typeface at the top of a page followed by a brief description of what the function does.

◆ SYNTAX lists the arguments and options for each command.

◆ DESCRIPTION provides a description of the command.

◆ ARGUMENTS explains the command arguments.

◆ OPTIONS explains the command options.

◆ PARAMETERS explains the command parameters.

◆ RETURN STATUS specifies the primary success and failure codes for each command.

◆ EXAMPLES provides examples of the syntax for various commands.


Command Reference

stormigrateThe EMC Open Migrator/LM command (stormigrate) for UNIX performs data migration and comparison control operations from a host to copy data from a source volume to a target volume.

SYNTAX

stormigrate [-def][-env][-help]

stormigrate -session name

create [-file devpairfile] [-skip_label_sector][-noskip_label_sector]

delete [-force]add sourcedev targetdev [-skip_label_sector]

[-noskip_label_sector]activatedeactivate [-noprompt]pauseresumerestartverify [-i Interval] [-c Count] [-v]query [-i Interval] [-c Count] [-summary] [-cluster][-v]

[-blocks | -kbytes | -mbytes | -gbytes][-miostat]

show [-summary] [-v] [-cluster][-blocks | -kbytes | -mbytes | -gbytes]

copy [-force]compare [-force]propscomplete

stormigratetune [-iosize kilobytes] [-ceiling megabytespersec]

[-checkpointsize megabytes] [-nthreads number of mover threads] [-mio_perf_ratio percentage] [-mio_recover_action action] [-noprompt]

listcleanup [-all][-noprompt]

DESCRIPTION The stormigrate command performs data migration control operations on pairs of volumes (source/target) added to a session or defined in a device file. Operating from a production host, Open Migrator/LM software is implemented as a host-based kernel driver that can copy data at the block level for volumes mounted (active) to the host. During migration, the source volume can remain

stormigrate 103

104

Command Reference

operational for I/O to its source and the target volume is set as not ready to the production host. Additionally, the target volume should be set as not ready or read/write disabled to any other attached hosts that can access the volume.

The stormigrate command provides mirroring and background copy functions that can be used to synchronize data images on one or more source and target volumes, LUNs or LUN partitions. Open Migrator/LM operates in sessions to manage multiple image pairs uniformly as a group.

ARGUMENTS activate

Activates a defined session and establishes the session in the kernel driver. To activate a session, one or more volume pairs (source/target) must have been previously added or volume pairs must have been provided in a device file (-file) at the time the session was created.

add

Adds a source volume (source dev) and target volume (target dev) to a created session.

cleanup

Deletes all defined sessions on the system including any configuration files that are maintained as part of the sessions. Used with the -all option to additionally clean up any log files associated with the sessions. Command is used to initialize the state of the system to a clean state. If the optional -noprompt argument is used then the command does not prompt the user with a question.

compare

Compares source and target volume data in the session. The session must have been previously activated to begin comparing.

copy

Begins the copying process for volume pairs (source to target) in the session. The session must have been previously activated to begin copying.


Command Reference

create

Defines a new session and assigns a session name.

deactivate

Deactivates an activated session. Effectively ends the kernel driver for the specified session. When deactivated, the session will be in an inactive session state.

If the data volumes are still busy with application I/Os or mounted by filesystem, a prompt will be displayed to warn user of possible unsynchronized data between source and target volumes after session deletion. Including the -noprompt option will bypass the prompt.

delete

Deletes a session. The -force option must be used if the session is active. Persistent configuration and status records of the session are deleted.

CAUTION!Forcing the deletion of a session could result in an incomplete volume copy or compare if the operation is in process.

list

Lists all currently defined sessions. Displays session names and status information for each.

pause

Pauses a session and temporarily stops the copying or comparing of volumes. Suspends the kernel driver tasks at their current data volume offsets.

props

Displays the various properties for all defined sessions on the system, including session, task, and action information. When used with the -session name option, displays the properties of a particular session.

stormigrate 105

106

Command Reference

query

Queries the status of a given session. Reports state and status information for each volume pair, followed by a summary for the entire session. Information can be displayed in various units by specifying the following options: -blocks, -mbytes, -gbytes, or -kbytes.

restart

Restarts any failed tasks having an error or MIOT status in a session.

resume

Resumes a paused session and continues the operation from where the tasks suspended.

show

Displays current configuration data for each volume pair in a given session, followed by a summary for the entire session. Information can be displayed in various units by specifying the following options: -blocks, -mbytes, -gbytes, or -kbytes.

complete

Marks the migration success for the cluster. The command is only needed for shared logical volume migration in failover cluster environment. The cluster state can be checked using the show or query command with -cluster argument.

tune

Tunes session performance at the kernel level. Allows the modification of certain parameters. Can be used to preserve system bandwidth for data migration during peak hours of operation. To view the tune parameters currently in effect, specify the tune command without options. Used with the following options: -iosize, -ceiling, -checkpointsize and -nthreads.

If the optional -noprompt argument is used then the command does not prompt the user with a question.

verify

Verifies the existing state of a given session. Used to poll the completion status of an activated kernel driver session.


Command Reference

OPTIONS -all

Cleans up the log files associated with the sessions when used with the cleanup command.

-bl[ocks]

Displays volume unit output in operating system blocks.

-c[ount]

Specifies the number (count) of times to display.

-ceiling

Sets the maximum bandwidth (in megabytes per second) for the target device to be used when copying data. The software throttles all data transfer operations so that the aggregate bandwidth remains at or below the specified ceiling value. Value can be between 1 and 10,000 megabytes. The default value is 1 megabyte. When used with the max qualifier, applies the maximum amount of bandwidth available for your system to all sessions.

Note: Setting the ceiling parameter to max may impact the performance of other programs running on the system.

-checkpointsize

Sets the size of the interval (in megabytes) between updates to the data mover’s property records. This parameter can be updated at any time and will have an immediate effect. Values range from 32 to MAXINT. The default value is 256. Setting the value to NONE indicates that the data movers will only update the properties records for a final status update.

-cluster

Displays the migration state in cluster environment for a given session.

stormigrate 107

108

Command Reference

-def

Displays the values of any environmental variables that have been set for a specified session name, file, interval or count. Optional environmental variables must be specified as follows:

STORMIGRATE_SESSIONSTORMIGRATE_FILESTORMIGRATE_INTERVALSTORMIGRATE_COUNT

-env

Displays available environmental variables that can be set.

-force

Forces the deletion of an activated session when used with the delete command.

When a session is paused using the pause command, can be used with the copy or compare command to force the session to start the intended action from the beginning of the session.

-gb[ytes]

Displays volume unit output in gigabytes.

-help

Provides brief, online help (-h) information.

-i[nterval]

Specifies the interval of time (in seconds) to repeat the command. The command will sleep for the specified number of seconds between reports.

Note: If the (-c) option is not specified and an interval (-i) is specified, the program loops continuously to produce infinite displays.

-iosize

Sets the input/output buffer size (in kilobytes) to be used for data transfers. Used with the stormigrate tune command. Values range from 64 K to 128 K. The default value is 64 K.

-kb[ytes]


Command Reference

Displays volume unit output in kilobytes.

-mb[ytes]

Displays volume unit output in megabytes.

-mio_perf_ratio

Sets the write performance ratio between mirrored pairs. Used with the stormigrate tune command. The write performance ratio is the maximum allowable difference for operations between device pairs. Values range from 110 percent to 500 percent. The default value of 200 percent allows Open Migrator to copy and mirror to target devices operating at one half the speed of the source device before triggering a recovery action.

-mio_recover_action

Sets a recovery action in the event that the performance ratio threshold (-mio-perf_ratio) between device pairs has been exceeded. Used with the stormigrate tune command. Values are either: ignore, log, or terminate. If set to ignore, no action is taken. If set to log, a warning message is written to the system log file. If set to terminate and Open Migrator is actively copying or comparing, the action is suspended but mirroring continues. If set to terminate and Open Migrator is only mirroring, the mirroring will be disabled. The default setting is terminate. The session may be restarted again using the restart command after all other task have finished.

Note: Refer to “Setting a recovery action for mirrored pairs” on page 74 for additional information.

-miostat

Displays the current write performance ratio of device pairs in migration. Used with the stormigrate query command.

-noskip_label_sector

Migrates the sector (VTOC block) that contains the label on a Solaris device during migration. Used with the create or add arguments.

stormigrate 109

110

Command Reference

-nthreads

Sets the size of the kernel module’s number of available threads that are used to process data mover tasks. This parameter can be updated at any time and will have an immediate effect. Value can be set between 1 and 64. The default value is 16.

-se[ssion]

Identifies the session name. The session name can be any alphabetical or numeric character and cannot exceed 32 characters in length.

-skip_label_sector

Skips the sector (VTOC block) that contains the label on a Solaris device during migration. Used with the create or add arguments.

-summ[ary]

Displays only the summary information for a given session.

-v

Displays the full volume pathname. Used with the query, show and verify commands.


Command Reference

PARAMETERS devpairfile

The name of the text file that contains the source and target volume pairs for the session. The device pair file must specify one volume pair (source dev and target dev) per line, separated by spaces. Lines beginning with a pound sign are ignored.

name

The name assigned to the session.

sourcedev

The physical or raw device name of the source volume.

targetdev

The physical or raw device name of the target volume.

RETURN STATUS The following are possible statuses that can be returned by this command (for example, in a UNIX C shell, returned using echo $status):

Code Description

0 STORMIGRATE_RC_SUCCESSIndicates that the session operation was successful.

1 STORMIGRATE_RC_SESSION_DOES_NOT_EXISTIndicates that the specified session does not exist.

2 STORMIRATE_RC_SESSION_ACTIVATEDIndicates that the session is currently activated.

3 STORMIGRATE_RC_SESSION_DEACTIVATEDIndicates that the session is not currently activated.

4 STORMIGRATE_RC_SESSION_ERRORIndicates that the session encountered an error during session operation.

5 STORMIGRATE_RC_SESSION_NOT_COMPLETEIndicates that the session operation has not completed.

STORMIGRATE_RC_<status_code>Indicates that the session operation has failed. Identifies other status codes that specify why a function could fail.

stormigrate 111

112

Command Reference

EXAMPLE The following brief example shows an Open Migrator/LM session for volume pairs defined in a device file (devfile1). Additional volume pairs are added to the session. The session (copyses1) is paused and is then resumed to continue data migration. The session is then queried, verified for completion and compared before being deleted.

stormigrate create -session copyses1 -file devfile1 -noskip_label_sectorstormigrate add -session copyses1 /dev/rdsk/c1t6d0s6 /dev/rdsk/c2t6d0s6 -noskip_label_sectorstormigrate activate -session copyses1stormigrate props -session copyses1stormigrate copy -session copyses1stormigrate pause -session copyses1stormigrate resume -session copyses1stormigrate query -session copyses1 -i 10 -c 3stormigrate compare -session copyses1stormigrate verify -session copyses1 -i 15 -c 3stormigrate deactivate -session copyses1stormigrate delete -session copyses1stormigrate cleanup -all


B

This appendix provides examples using the stormigrate command for data migration operations.

◆ Migrating Oracle databases............................................................. 114◆ Migrating HP Serviceguard shared logical volumes...................135◆ Migrating IBM HACMP shared logical volumes......................... 146◆ Migrating Veritas VCS shared logical volumes on Solaris.......... 173

Examples

Examples 113

114

Examples

Migrating Oracle databasesThe following CLI examples show how you can use Open Migrator/LM to migrate an Oracle database from an EMC Symmetrix® storage array to an EMC CLARiiON storage array. The database is Oracle 8i running on a Hewlett Packard (HP) PA-RISC system. The operating system is HP-UX 11iv1 (version 11.11).

In this scenario, the application using the Oracle database is a mission critical application, which can have very limited, planned outages. Unplanned outages of the application or any activities that impact the application’s performance cannot be tolerated.

The environment setup hosting the Oracle database uses an EMC Symmetrix array to provide storage for the database engine. Furthermore, instead of the native logical volume manager available on HP-UX systems, Veritas Storage Foundation for Databases is used as the platform for managing the storage on the server.

Due to an application redesign, the Oracle database environment is now less critical and can be migrated from one storage array to another for consolidation purposes. In addition to migrating the Oracle database, the administrator would like to eliminate the use of Veritas Storage Foundation for Databases. Although the criticality of the database has been reduced, it still plays an important role in the day to day business activities. Hence, the administrator would like to have minimal performance impact and small planned outages during the migration.

Identifying devices to migrate

Data migrations are performed for a number of reasons. These include, but are not limited to, server consolidation, storage technology upgrades, performance tuning and application balancing to optimize IT storage resources. When applications are migrated to optimize storage utilization, it is critical to identify all devices that are associated with the application. Failure to do so can result in unplanned application outages and data corruption when the original storage resources are redeployed.

The requirements discussed in the above section clearly define the reason for the migration of the Oracle database and optimization of IT resources. Therefore, as a first step to the migration, it is critical to properly identify all host devices associated with the application.


Examples

This can be achieved in a number of ways:

◆ The database administrator normally maintains a list of all devices that are allocated to databases. If you do not have the information available, simple SQL queries to the database can be used to obtain the information.

◆ Storage administrators managing the environment can use tools at their disposal to determine the storage devices that have been allocated to the hosts.

◆ Storage resource management tools such as EMC ControlCenter® and EMC StorageScope™ can provide reports that detail the storage allocation to various databases and applications.

◆ The Storage Resource Management (SRM) component of EMC Solutions Enabler can be utilized to determine both the host and storage devices associated with a number of applications and databases.

In this example, the EMC Solutions Enabler command line interface (CLI) is utilized to determine which devices need to be migrated from the Symmetrix array to the CLARiiON array. Figure 6 shows all schemas that are associated with the Oracle database to be migrated. It can be seen from the figure that two environmental variables, SYMCLI_RDB_NAME and SYMCLI_RDB_CONNECT, are necessary for EMC Solutions Enabler to provide the information. A database object SRM CLI command (symrdb) is used to list the schema of the Oracle database.

Figure 6 Using Solutions Enabler to determine the schema of Oracle database

Migrating Oracle databases 115

116

Examples

Once the schemas associated with the Oracle database have been identified, all files constituting the database need to be determined. The SRM component of EMC Solutions Enabler can provide that information. Figure 7 shows a partial listing of the Oracle database files associated with the database to be migrated. It is important to note that the filename returned by the command could be a symbolic link pointing to a file in a different file system. Further examination of the database structure is essential to determine the logical volumes associated with the database files.

The symrdb command can also provide detailed information about the data file associated with supported applications. The output from execution of this command on one of the database files is shown in Figure 8 on page 117.

Figure 7 Determining database files to be migrated


Examples

It can be seen from Figure 8 that the file under scrutiny is an object on a Veritas file system.

Figure 8 Detail showing the location of database file

The output from the symrdb show FILE command also provides information about the physical devices, volume groups (in case of Veritas volume manager, disk groups) and the logical volume hosting the database file. Refer to Figure 9 on page 118.


118

Examples

The logical volume identified in Figure 9 will be provided at a later time to Open Migrator/LM as one of the devices for migration.

Figure 9 Determining disk groups associated with Oracle database

All of the devices associated with the Oracle database can be identified using the process previously described. EMC Solutions Enabler also offers an option for collapsing the process of identifying database files, and obtaining its details into a single step.

The symrdb command line shown on page 119 leverages this option to identify the logical volumes and file systems associated with the SYS schema. Repeating the process for every schema that needs to be migrated will provide a complete listing of the logical volumes that need to be migrated. The logical volumes associated with the schema TPCB are shown in Figure 11 on page 119.


Examples

Figure 10 Identify logical volumes and file system with schema SYS

Figure 11 Identify logical volumes and file system with schema TPCB


120

Examples

Creating volume groups and logical volumes on target devicesThe architectural details of the logical volumes identified in the previous section need to be determined in order to create the appropriate structures on the target devices. The method to do this is presented using one of the logical volumes constituting the schema TPCB. Figure 12 shows how to obtain the configuration details of logical volume tpcb01 using the vxprint command. It can be seen from the figure that the logical volume is 2200 MB in size and is spread across six sub-disks (oracle004-01 through oracle009-01). Once the configuration details of all of the logical volumes to be migrated has been determined, the appropriate devices can be configured on the CLARiiON storage array and presented to the host.

Figure 12 Configuration details of logical volume tpcb01 in schema TPCB

Figure 13 on page 121 shows how the vgdisplay command is used to present the details of one of the target volume groups (/dev/ora_TGT_1), which will be used for the migration. It is important to note that the target volume group is created using the native logical volume manager (HP-UX LVM) and not the Veritas volume manager.

The appropriate target logical volumes can be created by obtaining information from the source logical volumes. The configuration of the target logical volume does not need to match that of the source logical volume. Although changes may be needed due to the performance characteristics of the target devices or to address architectural flaws present in the original configuration.


Examples

Figure 13 Creating target volume groups using EMC CLARiiON devices

Figure 14 on page 122 displays details of target logical volume that will be used to migrate the Veritas volume discussed earlier (tpcb01).


122

Examples

Figure 14 clearly shows the differences between the source and target logical volumes. The target logical volume is not only larger than the source logical volume, but also has a different stripe size. Once all the target logical volumes have been configured, Open Migrator/LM can be configured to initiate the migration.

Figure 14 Comparing source and target logical volume pairs


Examples

Setting up EMC Open Migrator/LMEMC Open Migrator/LM software contains two components, a kernel driver and a management interface. The kernel driver is responsible for the copying of the data from the source devices to the target devices. The management interface is used to instruct the kernel driver about the pairing of devices. The management of migration is performed using a construct known as a "session." A session is a logical grouping of device pairs that enables migrations to be performed in a consistent fashion. For example, a session could include all logical volumes used by an application or database.

The source and logical volumes identified in the previous section are listed in a device file. The device file will be used as the input to the management interface of EMC Open Migrator/LM. The logical volumes that need to be migrated are listed individually on a separate line. The contents of the file that will be used for the Oracle database migration is shown in Figure 15.

Figure 15 Device file listing the source and target logical volumes


124

Examples

Open Migrator/LM performs migrations by copying data at a block level. However, as shown in Figure 15 on page 123, character devices are listed in the device file to be used as input to Open Migrator/LM.

Note: Refer to “Creating a device file” on page 58 for more information.

The management interface for Open Migrator/LM is accessed using the stormigrate CLI command. The command uses four optional environmental variables (if set)- EMCOM_SESSION, EMCOM_FILE, EMCOM_INTERVAL and EMCOM_COUNT. These variables provide a convenient mechanism used to reduce the risk of typographical errors when executing commands that control and manipulate Open Migrator/LM.

The set value for any of the environmental variables can be overridden by providing new values when executing the stormigrate command. The environmental variables that are set for the migration in this example and are shown in Figure 16.

Figure 16 Setting environmental variables


Examples

Creating the sessionFigure 17 shows how the migration session (session name VxVM2LVM) is created using the stormigrate create command. The session is created using the device file shown in Figure 15 on page 123 as input. Because a session name and a filename are not identified in the command line, the session is created using the definitions that were set in the environmental variables (refer to Figure 16 on page 124). The stormigrate show command is then used to list the current session information.

When the session is created, the structures necessary for managing the session are created. The kernel driver component of Open Migrator/LM is not yet involved at this point.

Figure 17 Creating the Open Migrator/LM session

Figure 18 on page 126 shows which I/Os are being actively processed by the physical devices associated with the source logical volumes but not the target logical volume.


126

Examples

Figure 18 I/O activity on source logical volumes

Activating the sessionWhen the session is activated using the stormigrate activate command, the kernel driver inserts itself into the I/O path. However, it is in a pass-through mode in which the I/Os to the devices are not manipulated by the kernel driver.

EMC Open Migrator/LM can be left in this state until an appropriate time to start the copy process is reached. The stormigrate copy command then instructs the Open Migrator/LM kernel driver to start the copy. Refer to Figure 19 on page 127.


Examples

Figure 19 Activating and starting the copy process for the session

Managing the sessionThe Open Migrator/LM kernel driver actively reads data from the source device and copies it to the target devices for all sessions executing the stormigrate copy command. Furthermore, any new writes generated by the applications to the source devices will be mirrored to both the source and target devices. These activities, as shown in Figure 20 on page 128, results in increased CPU, memory and I/O workload. The increased workload can severely impact the performance characteristics of the Oracle database being migrated.


128

Examples

Figure 20 Increased IO activity due to copy in process

The tuning of the performance characteristics of Open Migrator/LM is managed using the stormigrate tune command. Open Migrator/LM provides six different mechanisms (options) to minimize the impact of the copy activities. Some of these mechanisms will need to be leveraged to satisfy the migration requirements described on page 114.

Open Migrator/LM allows users to determine the maximum rate at which the copy from the source to target device can take place. This is implemented using the -ceiling option. The ceiling value, by default, is set to 1 MB per second. This parameter needs to be slowly ramped to a value that will not cause any performance impact in the system environment. Furthermore, during the periods of extremely heavy workload, the copy process can be completely stopped by using the stormigrate pause command.


Examples

Note: Parameter changes made using the -ceiling option take effect immediately for all running sessions.

Refer to “Setting the target bandwidth” on page 71 for more information.

The stormigrate tune command when used with the -iosize option allows users to set the I/O transfer buffer rate. Refer to Figure 21.

Note: Parameter changes made using the -iosize option affect only new sessions that have not yet been activated in the kernel.

Figure 21 Tuning IO size for the session

Refer to “Tuning session performance” on page 71 for information on all of the available tuning parameters.


130

Examples

The copy session can be paused and resumed at any point by executing the stormigrate pause and stormigrate resume commands.

Figure 22 shows a pause and resume of the copy process for the session (VxVM2LVM).

Figure 22 Pausing and resuming the session

Completing the migrationThe status of the copy process can be verified by executing the stormigrate command with either the query or verify option. The query option provides detailed information about the progress of each device pair for the interrogated session. The verify command, on the other hand, returns a non-zero value if any of the device pairs is still being copied, which makes this option appropriate for use in command line scripts.


Examples

EMC Open Migrator/LM also supports a compare operation (instead of a copy operation). When the kernel driver is sent the stormigrate compare command, it performs a block by block comparison of the source and target devices. The compare operation can be used before or after a copy operation. To test the progress of the compare operation, you can use the stormigrate query or verify options.

Once the copy or compare process from the source devices to the target devices has completed, Open Migrator/LM will continue to maintain the synchronicity between the source and target devices. This enables the actual cutover to the target devices to be scheduled and performed at a convenient time. For the example migration, this will need to be carried out during a planned maintenance window.

The Oracle database needs to be shutdown before the migration from the source devices to the target devices can complete. If the application provides tools to test the validity and integrity of the data, they should be run just before the process to switch over the applications is started. The Oracle database, as shown in Figure 23, does provide a mechanism to verify the integrity of the data. After the completion of the migration, the same procedure needs to be executed to ensure that the migration was successful.

Figure 23 Verify and stop Oracle database before completing the migration


132

Examples

The Open Migrator/LM session needs to be deactivated after the Oracle database has been successfully stopped and the file systems associated with the database have been unmounted. The target device can be then mounted to either the same location as the original source devices or to new location. The symbolic links associated with the Oracle database will need to be updated if the target devices are mounted at a new location. These steps are shown in Figure 24.

Figure 24 Unmount source devices and deactivate the session

The Oracle database, as displayed in Figure 25 on page 133, can now be started on the target devices. However, before end-users access the database, the integrity of the data should be checked using the tools provided by the application (if any).


Examples

Figure 25 Starting Oracle on target devices


134

Examples

Figure 26 displays the results from the verification tests conducted on the database. A quick comparison of the results displayed in Figure 26 with those in Figure 23 on page 131, clearly show that the migration was completed successfully.

Figure 26 Testing the integrity of the Oracle database on target devices

ConclusionThe use case shown throughout these examples clearly show the powerful capabilities of EMC Open Migrator/LM for migrating Oracle databases. It is important to note that the procedure described in this example can be used for migrating other applications and databases on various supported operating systems. Furthermore, the procedure can be modified to accommodate other volume managers, and also different source and target storage arrays.


Examples

Migrating HP Serviceguard shared logical volumesThe following operations example shows how you can use EMC Open Migrator/LM to migrate the data repository of an HP Serviceguard cluster NFS package from a current VERITAS logical volume to a new one.

The operations example is based on the configuration in the table below:

Also, the configuration info (disk group and file system) of the NFS shared directory can be found in the running time as below:

clus212# cmviewcl

CLUSTER STATUShpiaclus up

NODE STATUS STATEclus212 up running

PACKAGE STATUS STATE AUTO_RUN NODEnfs_doc up running disabled clus212

NODE STATUS STATEclus214 up running

clus212# cmgetconf -p nfs_doc……vxvm_dg vxdg_nfs……fs_name /dev/vx/dsk/vxdg_nfs/vxvol_nfsfs_directory /shared/nfs_1fs_type ""

Configuration items

Operating System HP-UX 11.31 IA64 Update 5, installed on the 2 nodes

Serviceguard Cluster (T1905CA) A11.19.00 2-node failover cluster, named as hpiaclus

Serviceguard NFS Toolkit (B5140BA) A11.31.05 2-node failover package, named as nfs_doc

Cluster Node clus212#1 Hostname as clus212, the migration node

Cluster Node clus212#2 Hostname as clus214

VERITAS Volume Manager Bundle 5.0 for HP-UX B.05.00.01

VERITAS File System Bundle 5.0 for HP-UX B.05.00.01

NFS shared directory /dev/vx/dsk/vxdg_nfs/vxvol_nfs (formatted as vxfs)

VERITAS disk group for NFS shared directory vxdg_nfs

VERITAS volume for NFS shared directory vxvol_nfs

VERITAS file system for NFS shared directory /shared/nfs_1

Migrating HP Serviceguard shared logical volumes 135

136

Examples

fs_mount_opt "-o rw"fs_umount_opt ""fs_fsck_opt ""……clus212# mount……/shared/nfs_1 on /dev/vx/dsk/vxdg_nfs/vxvol_nfs …………

Migration Steps Summary

The following table summarizes the migration steps for this operation.

Step # Operations Before Migration

1 Identify the volumes to be migrated.2 Prepare shared target volume among all the cluster nodes.

3 Install the Open Migrator/LM package.

4 Disable reboot persistence on the migration node.5 Add the Open Migrator/LM module on all the cluster nodes.

6 Add the Open Migrator/LM scripts on all the cluster nodes.

7 Check if the Open Migrator/LM module is successfully added and identified by MC/SG.8 Get the latest configuration file for NFS package.

9 Add Open Migrator/LM module into the dependency stack of NFS package.

10 Apply the new dependency stack into the running package.Start Migration

11 Create migration session and add source and target volumes into the session.

12 Activate the session and start copying.13 Compare the session.

After Migration14 Complete the session.15 Halt the package and execute the rest steps to apply target volume in use.

16 Check the cluster package log and Open Migrator/LM cluster log to ensure no error happened.

17 Check the data integrity between original source and new target volumes.18 Manually edit the configuration file to get target volume in use.

19 Apply new package configuration file.

20 Re-Start the package and ensure everything work as expected.21 Delete the migration session and remove the Open Migrator/LM software if required.

22 Remove the Open Migrator/LM module and scripts from all the cluster nodes.


Examples

Before MigrationSteps for the Before Migration phase include:

1. Identify volumes to be migrated.

clus212# cmgetpkgenv nfs_doc | grep 'SG_FS_NAME'SG_FS_NAME[0]="/dev/vx/dsk/vxdg_nfs/vxvol_nfs"

For this example, only one source volume (VERITAS Volume in VERITAS Disk group) shown above will be migrated, so retrieve the volume size (in units of kb) for creating a valid target. Also please check with the product guide to ensure the disk group and volume types in customers' cluster environment are supported by EMC Open Migrator/LM.

clus212# vxprint -hDisk group: vxdg_nfs

TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0dg vxdg_nfs vxdg_nfs - - - - - -

dm c515t0d28 c515t0d28 - 2175104 - - - -

v vxvol_nfs fsgen ENABLED 2175104 - ACTIVE - -pl vxvol_nfs-01 vxvol_nfs ENABLED 2175104 - ACTIVE - -sd c515t0d28-01 vxvol_nfs-01 ENABLED 2175104 0 - - -

2. Prepare shared target volume among all the cluster nodes.

For VxVM volume, get a spare disk (c515t0d27) with command below, and ensure it's not used in any disk group.

clus212# vxdisk -o alldgs listDEVICE TYPE DISK GROUP STATUS……c515t0d27 auto:cdsdisk - - onlinec515t0d28 auto:cdsdisk c515t0d28 vxdg_nfs online

Now create disk group and volume with required size (2175104 kb) on the spare disk.

clus212# vxdg init vxdg_nfs2 c515t0d27clus212# vxassist -g vxdg_nfs2 make vxvol_nfs2 2175104clus212# vxprint -h……Disk group: vxdg_nfs2

TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0dg vxdg_nfs2 vxdg_nfs2 - - - - - -

dm c515t0d27 c515t0d27 - 2175104 - - - -

v vxvol_nfs2 fsgen ENABLED 2175104 - ACTIVE - -pl vxvol_nfs2-01 vxvol_nfs2 ENABLED 2175104 - ACTIVE - -sd c515t0d27-01 vxvol_nfs2-01 ENABLED 2175104 0 - - -


138

Examples

Create file system and try to mount the new target volume to ensure the device workable.

clus212# mkfs -F vxfs /dev/vx/dsk/vxdg_nfs2/vxvol_nfs2 version 7 layout 2175104 sectors, 2175104 blocks of size 1024, log size 16384 blockslargefiles supportedclus212# mount /dev/vx/dsk/vxdg_nfs2/vxvol_nfs2 /mnt

Check if the device can be shared among all the cluster nodes, umount the target volume, stop the volume and deport the disk group from the migration node clus212, then login on the clus214 and try to import the disk group, then check if the target volume can be started and mounted on the clus214.

On clus212, execute the following commands.

clus212# umount /mntclus212# vxvol -g vxdg_nfs2 stopallclus212# vxdg deport vxdg_nfs2

On clus214, use the commands below to check the target device workable and sharable.

clus214# vxdg import vxdg_nfs2clus214# vxvol -g vxdg_nfs2 startallclus214# mount /dev/vx/dsk/vxdg_nfs2/vxvol_nfs2 /mntclus214# vxprint -hDisk group: vxdg_nfs2

TY NAME ASSOC KSTATE LENGTH PLOFFS STATE TUTIL0 PUTIL0dg vxdg_nfs2 vxdg_nfs2 - - - - - -

dm c515t0d27 c515t0d27 - 2175104 - - - -

v vxvol_nfs2 fsgen ENABLED 2175104 - ACTIVE - -pl vxvol_nfs2-01 vxvol_nfs2 ENABLED 2175104 - ACTIVE - -sd c515t0d27-01 vxvol_nfs2-01 ENABLED 2175104 0 - - -

The target should still be stopped and deported from clus214, and moved back to clus212, the migration node. This is required by the Open Migrator/LM cluster migration feature.

Stop the target volume and deport the disk group on clus214

clus214# umount /mntclus214# vxvol -g vxdg_nfs2 stopallclus214# vxdg deport vxdg_nfs2

Import the target back to clus212, the migration node, the target should not be mounted.

clus212# vxdg import vxdg_nfs2clus212# vxvol -g vxdg_nfs2 startall


Examples

Now, a valid and cluster sharable target is ready for the migration

For more details about how to create the storage infrastructure for an HP-UX Serviceguard cluster, please refer to the section Creating the Storage Infrastructure and Filesystems with LVM, VxVM and CVM in the latest version of Managing Serviceguard. The steps mentioned above are referenced from the Managing Serviceguard Seventeenth Edition.

3. Install the Open Migrator/LM package.

clus212# swinstall -s /home/guest/EMCom.HP.V3.12.0.8.tar EMCom

4. Disable reboot persistence on the migration node.

clus212# stormigrate tune -checkpointsize NONE -nop

5. Add the Open Migrator/LM module on all the cluster nodes.

On the migration node, for clus212, use the following:

clus212# mkdir /etc/cmcluster/modules/emcomclus212# cp /etc/opt/EMCom/cluster/hpsg/emcom.0 /etc/cmcluster/modules/emcom/clus212# ln -s /etc/cmcluster/modules/emcom/emcom.0 /etc/cmcluster/modules/emcom/emcom

Add the Open Migrator/LM module for the clus214 (the commands below are also executed on clus212):

clus212# ssh clus214 'mkdir /etc/cmcluster/modules/emcom'clus212# scp /etc/opt/EMCom/cluster/hpsg/emcom.0 clus214:/etc/cmcluster/modules/emcom/clus212# ssh clus214 'ln -s /etc/cmcluster/modules/emcom/emcom.0 /etc/cmcluster/modules/emcom/emcom'

6. Add the Open Migrator/LM scripts on all the cluster nodes.

On the migration node, for clus212:

clus212# mkdir /etc/cmcluster/scripts/emcomclus212# cp /etc/opt/EMCom/cluster/hpsg/emcom.sh /etc/cmcluster/scripts/emcom/

Add the Open Migrator/LM scripts for the clus214 (commands below also executed on clus212):

clus212# ssh clus214 'mkdir /etc/cmcluster/scripts/emcom'

Source volume Target volume

/dev/vx/dsk/vxdg_nfs/vxvol_nfs /dev/vx/dsk/vxdg_nfs2/vxvol_nfs2


140

Examples

clus212# scp /etc/opt/EMCom/cluster/hpsg/emcom.sh clus214:/etc/cmcluster/scripts/emcom/

7. Check if the Open Migrator/LM module is successfully added and identified by MC/SG.

clus212# cmmakepkg -l……emcom/emcom (0) Volume migration support provided by EMC Open Migrator/LM

8. Get the latest configuration file for NFS package.

Generate the configuration file for the NFS package, in case it's not the latest or not existent

clus212# cmgetconf -p nfs_doc /etc/cmcluster/pkg/nfs_doc/nfs_doc.conf

9. Add Open Migrator/LM module into the dependency stack of NFS package.

clus212# cmmakepkg -i /etc/cmcluster/pkg/nfs_doc/nfs_doc.conf -m emcom/emcom /etc/cmcluster/pkg/nfs_doc/nfs_doc_emcom.conf

Package template is created. This file must be edited before it can be used.

Also, it's better to backup the original configuration file without Open Migrator/LM module added in, in case it's useful in later future.

10. Apply the new dependency stack into the running package.

clus212# cmapplyconf -P /etc/cmcluster/pkg/nfs_doc/nfs_doc_emcom.conf/etc/cmcluster/pkg/nfs_doc/nfs_doc_emcom.conf:528: service_halt_timeout value of 0 is equivalent to 1 sec.Attempting to validate nfs_doc.

The specified run script timeout is NO_TIMEOUT; using 1200 seconds as the timeout value. Cmapplyconf will wait for this amount of time for the script to complete before giving up.Validation for package nfs_doc succeeded via /etc/cmcluster/scripts/mscripts/master_control_script.sh.

One or more of the specified packages are running. Any error in the proposed configuration change could cause these packages to fail.

Ensure configuration changes have been tested before applying them.Modify the package configuration ([y]/n)? yCompleted the cluster update.


Examples

Start MigrationSteps for the Start Migration phase include:

11. Create the migration session and add source and target volumes into the session.

Note: Raw devices should be used for Open Migrator/LM migration on HP-UX platform.

clus212# stormigrate create -se nfsclus212# stormigrate add -se nfs /dev/vx/rdsk/vxdg_nfs/vxvol_nfs /dev/vx/rdsk/vxdg_nfs2/vxvol_nfs2clus212# stormigrate show -se nfs

MBSource Size Target---------------------------------- --------- ----------------------------------/dev/vx/rdsk/vxdg_nfs/vxvol_nfs 2124 /dev/vx/rdsk/vxdg_nfs2/vxvol_nfs2

Session Name: nfsSession State: InactiveAction Plan: N/ATask States: N/ANumber of Pairs: 1Total Source Size: 2124 MB

12. Activate the session and start copying.

clus212# stormigrate act -se nfsclus212# stormigrate copy -se nfs

13. Compare the session.

When the copying percentage reaching to 100%, compare the session, and the expected result is comparing session reaching to 100% without any error.

clus212# stormigrate compare -se nfs


142

Examples

After MigrationSteps for the After Migration phase include:

14. Complete the session.

When the copy and compare done for the session, complete the session

clus212# stormigrate complete -se nfsclus212# stormigrate show -se nfs -cluster

MBSource Size Target---------------------------------- --------- ----------------------------------/dev/vx/rdsk/vxdg_nfs/vxvol_nfs 2124 /dev/vx/rdsk/vxdg_nfs2/vxvol_nfs2

Session Name: nfsSession State: ActiveCluster State: CompleteAction Plan: CompareTask States: DoneNumber of Pairs: 1Total Source Size: 2124 MB

15. Halt the package and execute the steps to apply target volume in use.

clus212# cmhaltpkg nfs_docHalting package nfs_docSuccessfully halted package nfs_docOne or more packages or package instances have been halted.The failover packages have AUTO_RUN disabled and no new instance can start automatically. To allow automatic start, enable AUTO_RUN via cmmodpkg -e <package_name>cmhaltpkg: Completed successfully on all packages specified

Since Open Migrator/LM module plug-in configured in the dependency stack already, the migration session will be automatically deactivated when running 'cmhaltpkg nfs_doc'.

clus212# stormigrate list

Session State-------------------------------- -----------nfs Inactive

1 session found.

16. Check the cluster package log and Open Migrator/LM cluster log to ensure no error happened.


Examples

In cluster package log (/var/adm/cmcluster/log/<package>.log), similar message is reported as below

Aug 12 06:53:16 root@clus212 emcom.sh[26708]: Session nfs completed successfully for the cluster

In EMCom cluster log (/var/EMCom/log/emcom-cluster-<version>-<datetime>.log)

2010-08-12 06:53:15 INFO sg_stop_om: Stopping package 'nfs_doc'2010-08-12 06:53:16 INFO Deactivating session nfs ...2010-08-12 06:53:16 INFO Session nfs completed successfully for the cluster

17. Check the data integrity between original source and new target volumes.

The source disk group and volume should be manually imported and started, since cmhaltpkg make them deported and stopped

clus212# vxdg import vxdg_nfsclus212# vxvol -g vxdg_nfs startallclus212# mount /dev/vx/dsk/vxdg_nfs/vxvol_nfs /tmp/svolclus212# mount /dev/vx/dsk/vxdg_nfs2/vxvol_nfs2 /tmp/tvolclus212# diff -r /tmp/svol /tmp/tvol

After checking the data integrity, stop the source volume and deport the source disk group.

clus212# umount /tmp/svolclus212# vxvol -g vxdg_nfs stopallclus212# vxdg deport vxdg_nfs

18. Manually edit the configuration file to get target volume in use, the original mount point is still in used.

Make a copy of the original package configuration file, and edit the copy to get target volume in use.

clus212# cp nfs_doc.conf nfs_doc_target.conf

Edit the nfs_doc_target.conf and replace all those occurrences of orig-inal source info with new target info, including VxVM disk group and volume information.

Configuration for original source Configuration for new target

vxdg_nfs vxdg_nfs2

vxvol_nfs vxvol_nfs2


144

Examples

clus212# cat /etc/cmcluster/pkg/nfs_doc/nfs_doc_target.conf……vxvm_dg vxdg_nfs2……fs_name /dev/vx/dsk/vxdg_nfs2/vxvol_nfs2fs_directory /shared/nfs_1fs_type ""fs_mount_opt "-o rw"fs_umount_opt ""fs_fsck_opt ""……

19. Apply new package configuration file.

The step will get the new target volume into the cluster configuration

clus212# cmapplyconf -P nfs_doc_target.confnfs_doc_target.conf:476: service_halt_timeout value of 0 is equivalent to 1 sec.Attempting to validate nfs_doc.The specified run script timeout is NO_TIMEOUT; using 1200 seconds as timeout value.cmapplyconf will wait for this amount of time for thescript to complete before giving up.Validation for package nfs_doc succeeded via /etc/cmcluster/scripts/mscripts/master_control_script.sh.

Modify the package configuration ([y]/n)? yCompleted the cluster update

Now the new target volume gets into the cluster configuration.

clus212# cmgetpkgenv nfs_doc | grep 'SG_FS_NAME'SG_FS_NAME[0]="/dev/vx/dsk/vxdg_nfs2/vxvol_nfs2"

20. Re-start the package and ensure everything works as expected.

clus212# cmrunpkg nfs_docRunning package nfs_doc on node clus212Successfully started package nfs_doc on node clus212cmrunpkg: All specified packages are runningclus212# cmviewcl -p nfs_doc

PACKAGE STATUS STATE AUTO_RUN NODEnfs_doc up running disabled clus212clus212# mount……/shared/nfs_1 on /dev/vx/dsk/vxdg_nfs2/vxvol_nfs2 …………

21. Delete the migration session and remove the Open Migrator/LM software, if required.

clus212# stormigrate delete -se nfsclus212# swremove EMCom

22. Remove the Open Migrator/LM module and scripts from all the cluster nodes.


Examples

Actually they can be left there since not impact on the logic, as long as they are not referenced in the package configuration file.

Ensure there is no package referring the Open Migrator/LM module and scripts, and then execute the commands below on all the cluster nodes to remove the Open Migrator/LM module and scripts.

clus212# cd /etc/cmcluster/modulesclus212# rm -r emcomclus212# cd /etc/cmcluster/scriptsclus212# rm -r emcom


146

Examples

Migrating IBM HACMP shared logical volumes The following examples use Open Migrator /LM to migrate an NFS server to another storage location within a HACMP non-concurrent (failover) cluster.

Two examples are provided:◆ A basic LVM◆ A cross-site LVM mirroring operation

Basic LVM migrationThe resource group(nfs_rg) uses basic LVM (No cross-site LVM mirroring). The example migrates the original logical volume to another logical volume.

Migration Steps SummaryThe following tables summarizes the basic LVM migration steps:


1 Identify the logical volumes to be migrated2 Create the target shared volume group

3 Create the target logical volume and file system

4 Varyon and verify the target volume group5 Install Open Migrator package and add Open Migrator plug-in module

Start Migration6 Identify the source and target7 Create the session

8 copy and compare

After Migration9 Verify migration completes successfully

10 Complete the session

11 Offline the resource group12 Check cluster state and EMCom cluster log

13 Remove Open Migrator module from cluster

14 Reconfigure the application and resource group to use the target volumes15 Verify and synchronize the cluster

16 Bring the resource group online

17 Clean up Open Migrator and uninstall Open Migrator package


Examples

Before MigrationThe operations example is based on the configuration in the table below:

1. Identify the logical volumes to be migrated.

Example is NFS v4 resource group(nfs_rg). The source volume is lv01.

aixnode1# clRGinfo nfs_rg-----------------------------------------------------------------------------Group Name Group State Node -----------------------------------------------------------------------------nfs_rg ONLINE aixnode1

OFFLINE aixnode2

aixnode1# clshowres -g nfs_rg Resource Group Name nfs_rg Participating Node Name(s) aixnode1 aixnode2 Startup Policy Online On Home Node Only Fallover Policy Fallover To Next Priority Node In The List Fallback Policy Never Fallback Site Relationship ignore Node Priority Service IP Label nfs-ip Filesystems ALL Filesystems Consistency Check fsckFilesystems Recovery Method parallelFilesystems/Directories to be exported (NFSv3)

Configuration items

Operating System AIX 6.1 TL4

PowerHA 5.5 sp6

Cluster Name omtesting

Active node aixnode1

Passive node aixnode2

Resource Group nfs_rg

Source Volume Group nfs_vg1

Source Logical Volume lv01

Source File System /mnt/server/nfs_vg1_fs1

Target Volume Group tgt_vg

Target Logical Volume lv20

Target File System /mnt/server/tgt_vg_fs1

Migrating IBM HACMP shared logical volumes 147

148

Examples

Filesystems/Directories to be exported (NFSv4) /mnt/server/nfs_vg1_fs1 Filesystems to be NFS mounted /mnt/client/nfs_vg1_fs1;/mnt/server/nfs_vg1_fs1 Network For NFS Mount Filesystem/Directory for NFSv4 Stable Storage /.SS/nfs_vg1 Volume Groups nfs_vg1 Concurrent Volume Groups Use forced varyon for volume groups, if necessary false Disks GMVG Replicated Resources GMD Replicated Resources PPRC Replicated Resources ERCMF Replicated Resources SVC PPRC Replicated Resources AIX Connections Services AIX Fast Connect Services Shared Tape Resources Application Servers clas_nfsv4 Highly Available Communication Links Primary Workload Manager Class Secondary Workload Manager Class Delayed Fallback Timer Miscellaneous Data Automatically Import Volume Groups false Inactive Takeover SSA Disk Fencing false Filesystems mounted before IP configured trueWPAR Name Run Time Parameters: Node Name aixnode1Debug Level high Format for hacmp.out Standard Node Name aixnode2Debug Level high Format for hacmp.out Standard

aixnode1# lsvg -l nfs_vg1nfs_vg1:LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINTloglv01 jfs2log 1 1 1 open/syncd N/Alv01 jfs2 250 250 1 open/syncd /mnt/server/nfs_vg1_fs1lv02 jfs2 250 250 1 open/syncd /mnt/server/nfs_vg1_fs2lv06 jfs2 128 128 1 open/syncd /.SS/nfs_vg1

2. Create the target shared volume group (tgt_vg).

1. Enter smitty hacmp -> System Management (C-SPOC) -> HACMP Logical Volume Management ->Shared Volume Groups -> Create a Shared Volume Group.

2. Select the cluster nodes that will share the volume group.

Example is aixnode1 and aixnode2.

3. Select the shared disk(s) that will be part of the volume group.


Examples

Example shows the PVID of physical volumes that are seen as hdisk30 and hdisk31 by aixnode1 or hdisk28 and hdisk29 by aixnode2.

00cb12a5a5804a29 ( hdisk6 on node aixnode2 ) 00cb12a5a5804a29 ( hdisk8 on node aixnode1 ) 00cb12a5a9219625 ( hdisk7 on node aixnode2 ) 00cb12a5a9219625 ( hdisk9 on node aixnode1 ) > 00cb12a5e9255c03 ( hdisk29 on node aixnode2 ) > 00cb12a5e9255c03 ( hdisk31 on node aixnode1 ) > 00cb12a5e92e8fba ( hdisk28 on node aixnode2 ) > 00cb12a5e92e8fba ( hdisk30 on node aixnode1 ) 00cb17b5cda75261 ( hdisk31 on node aixnode2 ) 00cb17b5cda75261 ( hdisk33 on node aixnode1 )

4. Select volume group type as Original.

5. Fill in the name of the shared volume group.

Example shows the volume group is named tgt_vg. Leave the Resource Group Name as blank.

Create a Shared Volume Group Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Node Names aixnode1,aixnode2 Resource Group Name [] PVID 00cb12a5e9255c03 00cb12a5e92e8fba VOLUME GROUP name [tgt_vg] Physical partition SIZE in megabytes 4 Volume group MAJOR NUMBER [55] Enable Cross-Site LVM Mirroring Verification false Enable Volume Group for Fast Disk Takeover? true Volume Group Type Original

3. Create the target logical volume and file system.

1. Enter smitty hacmp -> System Management (C-SPOC) -> HACMP Logical Volume Management -> Shared File Systems -> Enhanced Journaled File Systems -> Add an Enhanced Journaled File System

2. Select the newly created target volume group.

Example is tgt_vg.

3. Fill in the size of file system and mount point.Add an Enhanced Journaled File System

Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Resource Group <None> Node Names aixnode1,aixnode2 Volume group name tgt_vg


150

Examples

SIZE of file system Unit Size Megabytes Number of units [1024] MOUNT POINT [/mnt/server/tgt_vg_fs1] PERMISSIONS read/write Mount OPTIONS [] Block Size (bytes) 4096 Inline Log? no Inline Log size (MBytes) [] Logical Volume for Log Extended Attribute Format Version 1 ENABLE Quota Management? no

4. For NFS v4, it needs Stable Storage, so create another file system.

Add an Enhanced Journaled File System Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Resource Group <None> Node Names aixnode1,aixnode2 Volume group name tgt_vg SIZE of file system Unit Size Megabytes Number of units [512] MOUNT POINT [/mnt/server/tgt_vg_stable] PERMISSIONS read/write Mount OPTIONS [] Block Size (bytes) 4096 Inline Log? no Inline Log size (MBytes) [] Logical Volume for Log Extended Attribute Format Version 1 ENABLE Quota Management? no

4. Varyon and verify the target volume group.

aixnode1# varyonvg tgt_vg

aixnode1# lsvg -p tgt_vgtgt_vg:PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTIONhdisk31 active 538 409 108..00..86..107..108hdisk30 active 538 282 108..00..00..66..108

aixnode1# lsvg -l tgt_vgtgt_vg:LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINTloglv08 jfs2log 1 1 1 closed/syncd N/Alv20 jfs2 256 256 1 closed/syncd /mnt/server/tgt_vg_fs1lv21 jfs2 128 128 1 closed/syncd /mnt/server/tgt_vg_stable

The target file system, if any, must be unmounted manually before starting migration.

aixnode1# umount /mnt/server/tgt_vg_fs1aixnode1# umount /mnt/server/tgt_vg_stable


Examples

5. Install the Open Migrator package and add the Open Migrator plug-in module into the running cluster.

1. Install Open Migrator package.aixnode1# installp -ad ./EMCom_install EMCom

2. Disable reboot persistency in cluster environments.aixnode1# stormigrate tune -checkpointsize NONE -nop

3. Add the Open Migrator plug-in module into the running cluster’

Put Open Migrator module (/etc/opt/EMCom/cluster/hacmp/cl_deactivate_*) under /usr/es/sbin/cluster/events/utils/ only on the migration active node

aixnode1# cd /usr/es/sbin/cluster/events/utils/aixnode1# mv cl_deactivate_vgs cl_deactivate_vgs.origaixnode1# cp /etc/opt/EMCom/cluster/hacmp/cl_deactivate_emcom .aixnode1# cp /etc/opt/EMCom/cluster/hacmp/cl_deactivate_vgs .

Start Migration6. Identify the source and target.

aixnode1# clshowres -g nfs_rg|grep exportFilesystems/Directories to be exported (NFSv3) Filesystems/Directories to be exported (NFSv4) /mnt/server/nfs_vg1_fs1

aixnode1# lsvg -l nfs_vg1 nfs_vg1:LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINTloglv01 jfs2log 1 1 1 open/syncd N/Alv01 jfs2 250 250 1 open/syncd /mnt/server/nfs_vg1_fs1lv02 jfs2 250 250 1 open/syncd /mnt/server/nfs_vg1_fs2lv06 jfs2 128 128 1 open/syncd /.SS/nfs_vg1

aixnode1# lsvg -l tgt_vg tgt_vg:LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINTloglv08 jfs2log 1 1 1 closed/syncd N/Alv20 jfs2 256 256 1 closed/syncd /mnt/server/tgt_vg_fs1lv21 jfs2 128 128 1 closed/syncd /mnt/server/tgt_vg_stable

So the source is lv01 and the target is lv20.

Create the migration session and start migration as before in non-clustered environments.


152

Examples

7. Create the session.

aixnode1# stormigrate create -session taixnode1# stormigrate add -session t /dev/rlv01 /dev/rlv20aixnode1# stormigrate show -s t MB Source Size Target ---------------------------------- --------- ----------------------------------/dev/rlv01 0 /dev/rlv20 Session Name: tSession State: InactiveAction Plan: N/ATask States: N/ANumber of Pairs: 1Total Source Size: 0 MB

8. Copy and compare.

aixnode1# stormigrate activate -session taixnode1# stormigrate copy -session taixnode1# stormigrate compare -session t

After MigrationWhen the migration completes successfully, the system adminstrator will perform the following steps.

9. Verify migration completes successfully;

aixnode1# stormigrate query -session t


aixnode1# stormigrate complete -session t

11. Offline the resource group.

The Open Migrator plug-in module will automatically deactivate the completed sessions for the cluster.

smitty hacmp -> System Management (C-SPOC) -> HACMP Resource Group and Application Management -> Bring a Resource Group Offline

Bring a Resource Group Offline Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields]Resource Group to Bring Offline nfs_rgNode On Which to Bring Resource Group Offline aixnode1

12. Check cluster state and EMCom cluster log.


Examples

If the resource group/application has been successfully offlined and there are no any I/O errors, the Open Migrator plug-in module will log a "migration completed successfully for the cluster" message.

The example log file is /var/EMCom/log/emcom-cluster-V3.12.0.8-20100609.log.


Otherwise, a migration failure message will be logged.

2010-06-09 04:48:00 WARN Session t migration failed for the cluster

13. Remove Open Migrator module from cluster.

aixnode1# cd /usr/es/sbin/cluster/events/utils/aixnode1# mv cl_deactivate_vgs.orig cl_deactivate_vgsaixnode1# rm cl_deactivate_emcom

14. Reconfigure the application and resource group to use the target volumes.

1. Update/restore the label for migrated logical volume if there is a filesystem on top it and its device subtype is not DS_LVZ

aixnode1# chlv -L /mnt/server/tgt_vg_fs1 lv20

2. Mount the source and target, verify the source and target is identical.

aixnode1# varyonvg nfs_vg1aixnode1# mount /mnt/server/nfs_vg1_fs1aixnode1# mount /mnt/server/tgt_vg1_fs1aixnode1# diff -r /mnt/server/nfs_vg1_fs1 /mnt/server/tgt_vg_fs1

There is no any difference reported by diff.

Then varyoff source and target volume group.

aixnode1# umount /dev/lv01aixnode1# umount /dev/lv20 aixnode1# varyoffvg nfs_vg1aixnode1# varyoffvg tgt_vg

3. Update application to use target volumes and filesystems.

For example, the application may want to use new target mount point instead of the original source mount point.


154

Examples

If the application still wants to use the original files ystem mount point, the original file system (/mnt/server/nfs_vg1_fs1) must be renamed to a temporary name and then rename the target filesystem (/mnt/server/tgt_vg1_fs1) to original filesystem (/mnt/server/nfs_vg1_fs1).

In this example the original mount point is used.

1. Rename the original filesystem to a temporary name.Enter smitty hacmp -> System Management (C-SPOC) -> HACMP Logical Volume Management -> Shared File Systems -> Enhanced Journaled File Systems -> Change / Show Characteristics of a Shared Enhanced Journaled File System

Change/Show Characteristics of a Shared Enhanced Journaled File System Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Resource Group Name nfs_rg File system name /mnt/server/nfs_vg1_fs1 Node Names aixnode1,aixnode2 NEW mount point [/mnt/server/nfs_vg1_tmp] Volume group name nfs_vg1 SIZE of file system Unit Size 512bytes Number of units [2048000] Mount GROUP [] Mount AUTOMATICALLY at system restart? no PERMISSIONS read/write Mount OPTIONS [] Start Disk Accounting? no Block Size (bytes) 4096 Inline Log? no Inline Log size (MBytes) [0] Extended Attribute Format [v1] ENABLE Quota Management? no Allow Small Inode Extents? [yes]

2. Rename the target filesystem to source.Enter smitty hacmp -> System Management (C-SPOC) -> HACMP Logical Volume Management -> Shared File Systems -> Enhanced Journaled File Systems -> Change / Show Characteristics of a Shared Enhanced Journaled File System

Change/Show Characteristics of a Shared Enhanced Journaled File System Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Resource Group Name <None> File system name /mnt/server/tgt_vg_fs1 Node Names aixnode2,aixnode1 NEW mount point [/mnt/server/nfs_vg1_fs1] Volume group name tgt_vg SIZE of file system Unit Size 512bytes Number of units [2048000]


Examples

Mount GROUP [] Mount AUTOMATICALLY at system restart? no PERMISSIONS read/write Mount OPTIONS [] Start Disk Accounting? no Block Size (bytes) 4096 Inline Log? no Inline Log size (MBytes) [0] Extended Attribute Format [v1] ENABLE Quota Management? no Allow Small Inode Extents? [yes]

4. Update the source resource group (nfs_rg).

Replace the source volume group (nfs_vg1) with target volume group (tgt_vg). Update "Filesystems" field , "Stable Storage Path", "Filesystems/Directories to NFS Mount" if required.

Enter smit hacmp -> Extended Configuration -> Extended Resource Configuration -> HACMP Extended Resource Group Configuration -> Change/Show Resources and Attributes for a Resource Group

Change/Show All Resources and Attributes for a Custom Resource Group Type or select values in entry fields.Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name nfs_rg Participating Nodes (Default Node Priority) aixnode1 aixnode2 Startup Policy Online On Home Node Only Fallover Policy Fallover To Next Priority Node In The List Fallback Policy Never Fallback Service IP Labels/Addresses [nfs-ip] Application Servers [clas_nfsv4]

Volume Groups [tgt_vg] Use forced varyon of volume groups, if necessary false Automatically Import Volume Groups alse

Filesystems (empty is ALL for VGs specified) [ ] Filesystems Consistency Check fsck Filesystems Recovery Method parallel Filesystems mounted before IP configured true Filesystems/Directories to Export (NFSv2/3) [] Filesystems/Directories to Export (NFSv4) [/mnt/server/nfs_vg1_fs1] Stable Storage Path (NFSv4) [/mnt/server/tgt_vg_stable] Filesystems/Directories to NFS Mount

[/mnt/client/nfs_vg1_fs1;/mnt/server/nfs_vg1_fs1] Network For NFS Mount []


156

Examples

15. Verify and synchronize the cluster.

Make sure there is no any error after verify and synchronize.

Enter smit hacmp -> Extended Configuration -> Extended Verification and Synchronization

16. Bring the resource group online.

# smitty hacmp -> System Management (C-SPOC) -> HACMP Resource Group and Application Management -> Bring a Resource Group online

Bring a Resource Group Online Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields]Resource Group to Bring Online nfs_rgNode on Which to Bring Resource Group Online aixnode1

17. Clean up Open Migrator and uninstall Open Migrator package.

aixnode1# stormigrate cleanup -nopaixnode1# installp -u EMCom


Examples

Cross-site LVM mirroringThe resource group(nfs_rg) uses cross-site LVM mirroring. The example migrates the original cross-site volume to another logical volume.

Migration Steps SummaryThe following table summarizes the cross-site LVM mirroring migra-tion steps.


1 Identify the logical volumes to be migrated

2 Assign new physical volumes to corresponding sites

3 Create the target volume group4 Create the target logical volume and file system

5 Varyon and verify the target volume group

6 Install Open Migrator package and add Open Migrator plug-in moduleStart Migration

7 Identify the source and target

8 Create the session

9 copy and compareAfter Migration

10 Verify migration completes successfully

11 Complete the session12 Offline the resource group

13 Check cluster state and EMCom cluster log

14 Remove Open Migrator module from cluster 15 Reconfigure the application and resource group to use the target volumes

16 Verify and synchronize the cluster

17 Bring the resource group online18 Clean up Open Migrator and uninstall Open Migrator package


158

Examples

Before Migration

The following tables lists the basic configuration of the cluster.

1. Identify the logical volumes to be migrated.

The example is NFS v4 resource group(nfs_rg).

lhmss104# cllssite ---------------------------------------------------Sitename Site Nodes Dominance Protection Type ---------------------------------------------------UTC_site lhmss074 no NONE UTM_site lhmss104 yes NONE

lhmss104# clRGinfo nfs_rg-----------------------------------------------------------------------------Group Name Group State Node -----------------------------------------------------------------------------nfs_rg ONLINE lhmss104

OFFLINE lhmss074

lhmss104# clshowres -g nfs_rg Resource Group Name nfs_rg Participating Node Name(s) lhmss104 lhmss074 Startup Policy Online On Home Node Only Fallover Policy Fallover To Next Priority Node In The List Fallback Policy Fallback To Higher Priority Node In The List Site Relationship ignore Node Priority Service IP Label lhmss105 Filesystems ALL

Configuration Items

Operating System AIX 6.1 TL4

PowerHA 5.5 sp6

Cluster Name om_cluster

Active node lhmss104

Passive node lhmss074

Resource Group nfs_rg

Source Volume Group cross_vg1

Source Logical Volume cross_vg1_lv1

Source File System /mnt/server/vg1_lv1

Target Volume Group vg2

Target Logical Volume lv2

Target File System /mnt/server/lv2


Examples

Filesystems Consistency Check fsckFilesystems Recovery Method sequentialFilesystems/Directories to be exported (NFSv3) Filesystems/Directories to be exported (NFSv4) /mnt/server/vg1_lv1 Filesystems to be NFS mounted /mnt/client/vg1_lv1;/mnt/server/vg1_lv1 Network For NFS Mount Filesystem/Directory for NFSv4 Stable Storage /.SS/cross_vg1 Volume Groups cross_vg1 Concurrent Volume Groups Use forced varyon for volume groups, if necessary true Disks GMVG Replicated Resources GMD Replicated Resources PPRC Replicated Resources ERCMF Replicated Resources SVC PPRC Replicated Resources AIX Connections Services AIX Fast Connect Services Shared Tape Resources Application Servers clas_nfsv4 Highly Available Communication Links Primary Workload Manager Class Secondary Workload Manager Class Delayed Fallback Timer Miscellaneous Data Automatically Import Volume Groups false Inactive Takeover SSA Disk Fencing false Filesystems mounted before IP configured trueWPAR Name Run Time Parameters: Node Name lhmss104Debug Level high Format for hacmp.out Standard Node Name lhmss074Debug Level high Format for hacmp.out Standard

lhmss104# lsvg -l cross_vg1cross_vg1:LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINTloglv01 jfs2log 1 1 1 open/syncd N/Across_vg1_lv1 jfs2 200 400 2 open/syncd /mnt/server/vg1_lv1lv02 jfs2 128 128 1 open/syncd /.SS/cross_vg1cross_vg1_lv2 jfs2 200 400 2 open/syncd /mnt/server/vg1_lv2vg1_lv3 jfs 94 188 2 open/syncd /mnt/server/vg1_lv3vg1_jfslog jfslog 1 2 2 open/syncd N/A

lhmss104# lsvg -p cross_vg1cross_vg1:PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTIONhdiskpower8 active 222 20 00..00..00..00..20hdiskpower120 active 222 21 00..01..00..00..20hdiskpower119 active 222 0 00..00..00..00..00hdiskpower9 active 222 128 00..44..44..40..00hdiskpower123 active 222 22 00..00..00..00..22hdiskpower13 active 222 22 00..00..00..00..22


160

Examples

lhmss104# mount |grep cross_vg1_lv1 /dev/cross_vg1_lv1 /mnt/server/vg1_lv1 jfs2 Aug 12 01:05 rw,log=/dev/loglv01

2. Assign new physical volumes to corresponding sites to configure cross-site LVM mirroring site dependencies.

smitty hacmp -> System Management (C-SPOC) -> HACMP PhysicalVolume Management -> Configure Disk/Site Locations for Cross-SiteLVM Mirroring -> Add Disk/Site Definition for Cross-Site LVM Mirroring

First add disk to UTM site.

Move cursor to desired item and press Enter. UTC_site UTM_site

Disks PVID | Move cursor to desired item and press F7. ONE OR MORE items can be selected. Press Enter AFTER making all selections. [MORE...11] > 00cdcc4d18532f6d hdiskpower124 lhmss104 > 00cdcc4d185bec95 hdiskpower125 lhmss104 00cdcc4d1868251e hdiskpower126 lhmss104 00cdcc4d39b75269 hdisk370 lhmss104 00cdcc4d185ae361 hdiskpower30 lhmss074 00cdcc4d185de7cb hdiskpower31 lhmss074 00cdcc4d026c5632 hdiskpower48 lhmss074 > 00cdcc4d18532f6d hdiskpower55 lhmss074 > 00cdcc4d185bec95 hdiskpower56 lhmss074

Then add the disks to the UTC site.

Move cursor to desired item and press Enter. UTC_site UTM_site

Disks PVID Move cursor to desired item and press F7. ONE OR MORE items can be selected. Press Enter AFTER making all selections. [MORE...5] > 00cdcc4d185ae361 hdiskpower14 lhmss104 > 00cdcc4d185de7cb hdiskpower15 lhmss104 00cdcc4dfde55a76 hdiskpower84 lhmss104 00cdcc4d5cb9c105 hdiskpower99 lhmss104 00cdcc4d5cb2a65c hdiskpower100 lhmss104 00cdcc4d026c5632 hdiskpower117 lhmss104 00cdcc4d1868251e hdiskpower126 lhmss104 00cdcc4d39b75269 hdisk370 lhmss104 > 00cdcc4d185ae361 hdiskpower30 lhmss074 > 00cdcc4d185de7cb hdiskpower31 lhmss074

3. Create the target volume group.


Examples

Create the share target volume group, being part of a new resource group (rg2), with cross-site LVM mirror.

1. Enter smitty hacmp -> System Management (C-SPOC) -> HACMP Logical Volume Management -> Shared Volume Groups -> Create a Shared Volume Group

2. Select the cluster nodes that will share the volume group.

Example is lhmss104 and lhmss074.

3. Select the shared disk(s) from both sites that will consist of the volume group.

Physical Volume Names Move cursor to desired item and press F7. ONE OR MORE items can be selected. Press Enter AFTER making all selections. > 00cdcc4d18532f6d ( hdiskpower55 on node lhmss074 at site UTM_site ) > 00cdcc4d18532f6d ( hdiskpower124 on node lhmss104 at site UTM_site ) > 00cdcc4d185ae361 ( hdiskpower30 on node lhmss074 at site UTC_site ) > 00cdcc4d185ae361 ( hdiskpower14 on node lhmss104 at site UTC_site ) > 00cdcc4d185bec95 ( hdiskpower56 on node lhmss074 at site UTM_site ) > 00cdcc4d185bec95 ( hdiskpower125 on node lhmss104 at site UTM_site ) > 00cdcc4d185de7cb ( hdiskpower31 on node lhmss074 at site UTC_site ) > 00cdcc4d185de7cb ( hdiskpower15 on node lhmss104 at site UTC_site ) F1=Help F2=Refresh F3=Cancel F7=Select F8=Image F10=Exit Enter=Do /=Find n=Find Next

4. Fill in the name of the shared volume group and the resource group that will contain the volume group.

The example shows the volume group named vg2, being part of resource group rg2. And ensure that we set the Enable Cross-Site LVM Mirroring Verification option to true.

Create a Shared Volume Group Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Node Names lhmss074,lhmss104 Resource Group Name [rg2] PVID 00cdcc4d18532f6d 00cdcc4d185ae361 00cdcc4d185bec95 00cdcc4d185de7cb VOLUME GROUP name [vg2] Physical partition SIZE in megabytes 4 Volume group MAJOR NUMBER [78] Enable Cross-Site LVM Mirroring Verification true Enable Volume Group for Fast Disk Takeover? true Volume Group Type original F1=Help F2=Refresh F3=Cancel F4=ListF5=Reset F6=Command F7=Edit F8=ImageF9=Shell F10=Exit Enter=Do


162

Examples

The volume group (vg2) are now present on both nodes as shown below:

lhmss104# lspv|grep " vg2"hdiskpower14 00cdcc4d185ae361 vg2 hdiskpower15 00cdcc4d185de7cb vg2 hdiskpower124 00cdcc4d18532f6d vg2 hdiskpower125 00cdcc4d185bec95 vg2

lhmss074# lspv|grep " vg2"hdiskpower30 00cdcc4d185ae361 vg2 hdiskpower31 00cdcc4d185de7cb vg2 hdiskpower55 00cdcc4d18532f6d vg2 hdiskpower56 00cdcc4d185bec95 vg2

5. Enable "Use forced varyon for volume groups, if necessary true" for the resource group rg2.

smitty hacmp -> Extended Configuration -> Extended Resource Configuration -> HACMP Extended Resource Group Configuration -> Change/Show Resources and Attributes for a Resource Group

Change/Show All Resources and Attributes for a Custom Resource Group Type or select values in entry fields.Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name rg2 Inter-site Management Policy ignore Participating Nodes from Primary Site lhmss074 Participating Nodes from Secondary Site lhmss104 Startup Policy Online On Home Node Only Fallover Policy Fallover To Next Priority Node In The List Fallback Policy Never Fallback Service IP Labels/Addresses [] Application Servers []

Volume Groups [vg2 ] Use forced varyon of volume groups, if necessary true Automatically Import Volume Groups false

4. Create the target logical volume (lv2) and file system

1. Enter the following:smitty hacmp -> System Management (C-SPOC) -> HACMP Logical Volume Management -> Shared Logical Volumes -> Add a Shared Logical Volume

2. Select the newly created target volume group (vg2).


Examples

3. Select the physical disk for the logical volume (Do not use the Auto-select option.)

Physical Volume Names

Move cursor to desired item and press F7. ONE OR MORE items can be selected. Press Enter AFTER making all selections. Auto-select > lhmss104 hdiskpower14 UTC_site lhmss104 hdiskpower15 UTC_site > lhmss104 hdiskpower124 UTM_site lhmss104 hdiskpower125 UTM_site F1=Help F2=Refresh F3=Cancel F7=Select F8=Image F10=Exit Enter=Do /=Find n=Find Next

4. Fill in the name of the shared logical volume, number of logical partitions and other info. Specify two copies for the number copies of each logical partition and set the Allocate each logical partition copy on a SEPARATE physical volume? to superstrict

Add a Shared Logical Volume Type or select values in entry fields.Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name rg2 VOLUME GROUP name vg2 Reference node lhmss104* Number of LOGICAL PARTITIONS [200] PHYSICAL VOLUME names hdiskpower14 hdiskpower124 Logical volume NAME [lv2] Logical volume TYPE [jfs2] POSITION on physical volume middle RANGE of physical volumes minimum MAXIMUM NUMBER of PHYSICAL VOLUMES [] to use for allocation Number of COPIES of each logical 2 partition Mirror Write Consistency? active Allocate each logical partition copy superstrict on a SEPARATE physical volume? RELOCATE the logical volume during reorganization? yes Logical volume LABEL [] MAXIMUM NUMBER of LOGICAL PARTITIONS [512] Enable BAD BLOCK relocation? yes SCHEDULING POLICY for reading/writing parallel logical partition copies Enable WRITE VERIFY? no File containing ALLOCATION MAP [] Stripe Size? [Not Striped]


164

Examples

Verify the lv2 mirror

lhmss104# lslv -m lv2lv2:/mnt/server/lv2LP PP1 PV1 PP2 PV2 PP3 PV30001 0001 hdiskpower14 0046 hdiskpower124 0002 0002 hdiskpower14 0047 hdiskpower124 0003 0003 hdiskpower14 0048 hdiskpower124 0004 0004 hdiskpower14 0049 hdiskpower124 0005 0005 hdiskpower14 0050 hdiskpower124 0006 0006 hdiskpower14 0051 hdiskpower124 0007 0007 hdiskpower14 0052 hdiskpower124

5. If there is filesystem on source logical volume, repeat 3 to create a log logical volume (log_lv2).

Add a Shared Logical Volume Type or select values in entry fields.Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name rg2 VOLUME GROUP name vg2 Reference node lhmss104* Number of LOGICAL PARTITIONS [1] PHYSICAL VOLUME names hdiskpower14 hdiskpower124 Logical volume NAME log_lv2] Logical volume TYPE [jfs2log] POSITION on physical volume middle RANGE of physical volumes minimum MAXIMUM NUMBER of PHYSICAL VOLUMES [] to use for allocation Number of COPIES of each logical 2 partition Mirror Write Consistency? active Allocate each logical partition copy superstrict on a SEPARATE physical volume? RELOCATE the logical volume during reorganization? yes Logical volume LABEL [] MAXIMUM NUMBER of LOGICAL PARTITIONS [512] Enable BAD BLOCK relocation? yes SCHEDULING POLICY for reading/writing parallel logical partition copies Enable WRITE VERIFY? no File containing ALLOCATION MAP [] Stripe Size? [Not Striped]


Examples

6. If there is filesystem on source logical volume, create a target file system(/mnt/server/lv2) on the above logical volumes (lv2 and log_lv2).

IMPORTANT!Important: Always add a file system by creating the logical volume first, then create the file system on a previously defined logical volume. Reason: If you allow the creation of the logical volume at the time of file system creation, the cross-site logical volume mirroring will not created.

Enter smitty hacmp -> System Management (C-SPOC) -> HACMP Logical Volume Management -> Shared File Systems -> Enhanced Journaled File Systems -> Add an Enhanced Journaled File System on a Previously Defined Logical Volume

Add an Enhanced Journaled File System on a Previously Defined Logical Volume Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Resource Group rg2 Node Names lhmss074,lhmss104 LOGICAL VOLUME name lv2 Volume Group vg2* MOUNT POINT [/mnt/server/lv2] PERMISSIONS read/write Mount OPTIONS [] Block Size (bytes) 4096 Inline Log? no Inline Log size (MBytes) [] Logical Volume for Log Extended Attribute Format Version 1 ENABLE Quota Management? no

7. For NFS v4, it needs a Stable Storage, so create another file system (/mnt/server/stable) using above steps.

Physical Volume Names ||| Move cursor to desired item and press F7. | ONE OR MORE items can be selected. | Press Enter AFTER making all selections. | | Auto-select | lhmss104 hdiskpower14 UTC_site | > lhmss104 hdiskpower15 UTC_site | lhmss104 hdiskpower124 UTM_site | > lhmss104 hdiskpower125 UTM_site | F1=Help F2=Refresh F3=Cancel | F7=Select F8=Image F10=Exit | Enter=Do /=Find n=Find Next


166

Examples

Add a Shared Logical Volume Type or select values in entry fields.Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name rg2 VOLUME GROUP name vg2 Reference node lhmss104* Number of LOGICAL PARTITIONS [128] PHYSICAL VOLUME names hdiskpower15 hdiskpower125 Logical volume NAME [stable] Logical volume TYPE [jfs2] POSITION on physical volume middle RANGE of physical volumes minimum MAXIMUM NUMBER of PHYSICAL VOLUMES [] to use for allocation Number of COPIES of each logical 2 partition Mirror Write Consistency? active Allocate each logical partition copy superstrict on a SEPARATE physical volume? RELOCATE the logical volume during reorganization? yes Logical volume LABEL [] MAXIMUM NUMBER of LOGICAL PARTITIONS [512] Enable BAD BLOCK relocation? yes

SCHEDULING POLICY for reading/writing parallel logical partition copies Enable WRITE VERIFY? no File containing ALLOCATION MAP [] Stripe Size? [Not Striped]

Add an Enhanced Journaled File System on a Previously Defined Logical Volume Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Resource Group rg2 Node Names lhmss074,lhmss104 LOGICAL VOLUME name stable Volume Group vg2* MOUNT POINT [/mnt/server/stable] PERMISSIONS read/write Mount OPTIONS [] Block Size (bytes) 4096 Inline Log? no Inline Log size (MBytes) [] Logical Volume for Log Extended Attribute Format Version 1 ENABLE Quota Management? no


Examples

5. Varyon and verify the target volume group.

The resource group (rg2) including the target volume group (vg2) is automatically brought online.

Enter smitty hacmp -> Extended Configuration -> Extended Verification and Synchronization

lhmss104# clRGinfo rg2-----------------------------------------------------------------------------Group Name Group State Node -----------------------------------------------------------------------------rg2 ONLINE lhmss074

OFFLINE lhmss104

lhmss104# lsvg -l vg2vg2:LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINTlv2 jfs2 200 400 2 closed/syncd /mnt/server/lv2log_lv2 jfs2log 1 2 2 closed/syncd N/Astable jfs2 128 256 2 closed/syncd /mnt/server/stable

The target file system, if any, must be unmounted manually before starting migration.

lhmss104# umount /mnt/server/lv2lhmss104# umount /mnt/server/stable

6. Install Open Migrator package and add the Open Migrator plug-in module.

1. Install Open Migrator packagelhmss104# installp -ad ./EMCom_install EMCom

2. Disable reboot persistency in cluster environments.lhmss104# stormigrate tune -checkpointsize NONE -nop

3. Add the Open Migrator plug-in module into the running cluster.

Put Open Migrator module (/etc/opt/EMCom/cluster/hacmp/cl_deactivate_*) under /usr/es/sbin/cluster/events/utils/ only on the migration active node

lhmss104# cd /usr/es/sbin/cluster/events/utils/lhmss104# mv cl_deactivate_vgs cl_deactivate_vgs.origlhmss104# cp /etc/opt/EMCom/cluster/hacmp/cl_deactivate_emcom .lhmss104# cp /etc/opt/EMCom/cluster/hacmp/cl_deactivate_vgs .


168

Examples

Start Migration7. Identify the source and target.

lhmss104# clshowres -g nfs_rg|grep exportFilesystems/Directories to be exported (NFSv3) Filesystems/Directories to be exported (NFSv4) /mnt/server/vg1_lv1

lhmss104# lsvg -l cross_vg1cross_vg1:LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINTloglv01 jfs2log 1 1 1 open/syncd N/Across_vg1_lv1 jfs2 200 400 2 open/syncd /mnt/server/vg1_lv1lv02 jfs2 128 128 1 open/syncd /.SS/cross_vg1cross_vg1_lv2 jfs2 200 400 2 open/syncd /mnt/server/vg1_lv2vg1_lv3 jfs 94 188 2 open/syncd /mnt/server/vg1_lv3vg1_jfslog jfslog 1 2 2 open/syncd N/A

lhmss104# lsvg -l vg2vg2:LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINTlv2 jfs2 200 400 2 open/syncd /mnt/server/lv2log_lv2 jfs2log 1 2 2 open/syncd N/Astable jfs2 128 256 2 open/syncd /mnt/server/stable

So the source is cross_vgl_lvl and the target is lv2.

8. Create the migration session

lhmss104# stormigrate create -session tlhmss104# stormigrate add -session t /dev/rcross_vg1_lv1 /dev/rlv2lhmss104# stormigrate show -s t MB Source Size Target ---------------------------------- --------- ----------------------------------/dev/rcross_vg1_lv1 0 /dev/rlv2 Session Name: tSession State: InactiveAction Plan: N/ATask States: N/ANumber of Pairs: 1Total Source Size: 0 MB

9. Copy and compare the session.

lhmss104# stormigrate activate -session tlhmss104# stormigrate copy -session tlhmss104# stormigrate compare -session t


Examples

After Migration10. Verify migration completes successfully.

lhmss104# stormigrate query -session t

11. Complete the migration.

lhmss104# stormigrate complete -session t

12. Offline the resource group: nfs_rg.

The Open Migrator plug-in module will automatically deactivate the completed sessions for the cluster.


Bring a Resource Group OfflineType or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Resource Group to Bring Offline nfs_rg Node On Which to Bring Resource Group Offline lhmss104

13. Check cluster state and EMCom cluster log

If the resource group/application has been successfully offlined and there are no any I/O errors, the Open Migrator plug-in module will log a "migration completed successfully for the cluster" message.

The example log file is /var/EMCom/log/emcom-cluster-V3.12.0.8-20100812.log


Otherwise, a migration failure message will be logged.

2010-08-12 04:48:00 WARN Session t migration failed for the cluster

EMCom cluster log resides at /var/EMCom/log. The log file name is in format "emcom-cluster-<yyyymmdd>.log" - e.g. emcom-cluster-20100609.log.

14. Remove the Open Migrator module from the cluster.

lhmss104# cd /usr/es/sbin/cluster/events/utils/lhmss104# mv cl_deactivate_vgs.orig cl_deactivate_vgslhmss104# rm cl_deactivate_emcom


170

Examples

15. Reconfigure the application and resource group to use the target volumes.

1. Update/restore the label for migrated logical volume if there is a filesystem on top it and its device subtype is not DS_LVZ .

lhmss104# chlv -L /mnt/server/lv2 lv2

2. Mount the source and target, verify the source and target is identical.

lhmss104# varyonvg cross_vg1lhmss104# mount /mnt/server/vg1_lv1lhmss104# mount /mnt/server/lv2 lhmss104# diff -r /mnt/server/vg1_lv1 /mnt/server/lv2

Make sure there is no any difference reported by diff.

Then varyoff source and target volume group.

lhmss104# umount /mnt/server/vg1_lv1lhmss104# umount /mnt/server/lv2 lhmss104# varyoffvg cross_vg1

3. Bring the target resource group(rg2) including the target volume group offline.


Bring a Resource Group Offline Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields] Resource Group to Bring Offline rg2 Node On Which to Bring Resource Group Offline lhmss104

4. Remove the target resource group (rg2).Enter smit hacmp -> Extended Configuration -> Extended Resource Configuration -> HACMP Extended Resource Group Configuration -> Remove a Resource Group

5. Update application to use target volumes and filesystems.

If the application still wants to use the original filesystem mount point, the original filesystem (/mnt/server/vg1_lv1) must be renamed to a temporary name and then rename the target filesystem (/mnt/server/lv2) to original filesystem (/mnt/server/vg1_lv1).

This example use the new target mount point (/mnt/server/lv2).


Examples

6. Update source resource group(nfs_rg) and replace the source volume group (cross_vg1) with target volume group (vg2). Update "Filesystems" field , "Stable Storage Path", "Filesystems/Directories to NFS Mount", if required.

Enter smit hacmp -> Extended Configuration -> Extended Resource Configuration -> HACMP Extended Resource Group Configuration -> Change/Show Resources and Attributes for a Resource Group

Change/Show All Resources and Attributes for a Resource Group Type or select values in entry fields. Press Enter AFTER making all desired changes. [TOP] [Entry Fields] Resource Group Name nfs_rg Inter-site Management Policy ignore Participating Nodes from Primary Site lhmss104 Participating Nodes from Secondary Site lhmss074 Startup Policy Online On Home Node OnlyFallover Policy Fallover To Next Priority Node In The List Fallback Policy Fallback To Higher Priority Node In The List Fallback Timer Policy (empty is immediate) [] Service IP Labels/Addresses [lhmss105] Application Servers [clas_nfsv4] Volume Groups [vg2] Use forced varyon of volume groups, if necessary true Automatically Import Volume Groups false Filesystems (empty is ALL for VGs specified) [ ] Filesystems Consistency Check fsck Filesystems Recovery Method sequential Filesystems mounted before IP configured true Filesystems/Directories to Export (NFSv2/3) [] Filesystems/Directories to Export (NFSv4) [/mnt/server/lv2] Stable Storage Path (NFSv4) [/mnt/server/stable] Filesystems/Directories to NFS Mount [/mnt/client/vg1_lv1;/mnt/server/lv2]

16. Verify and synchronize the cluster.

Make sure there is no any error after verify and synchronize.

Enter smit hacmp -> Extended Configuration -> Extended Verification and Synchronization

17. Online the resource group.

smitty hacmp -> System Management (C-SPOC) -> HACMP Resource Group and Application Management -> Bring a Resource Group Online

Bring a Resource Group Online Type or select values in entry fields.Press Enter AFTER making all desired changes.

[Entry Fields]Resource Group to Bring Online nfs_rgNode on Which to Bring Resource Group Online lhmss104


172

Examples

18. Clean up Open Migrator and uninstall Open Migrator package.

lhmss104# stormigrate cleanup -noplhmss104# installp -u EMCom


Examples

Migrating Veritas VCS shared logical volumes on SolarisThe following example shows how Open Migrator/LM migrates from a source Volume to a target Volume in a running cluster, which includes the failover service group on two nodes. The active node will do the migration.

Note: All the following example commands are executed on the active node.

The following table lists the basic configuration of the Veritas cluster environment.

Configuration Item

Operating System Solaris 10 Update 8

Veritas Cluster 5.0mp3

Veritas Volume Manager 5.0mp3

Cluster Name sparc-cluster

Active node sparc220

Passive node sparc222

Failover Service Group NFS

Source Volume Group nfs_src3_dg nfs_src4_dg

Source Logical Volume nfs_src3_vol1 nfs_src3_vol2nfs_src4_vol1 nfs_src4_vol2

Source File System /nfsshare1 /nfsshare2/nfsshare3 /nfsshare4

Target Volume Group nfs_tgt3_dg nfs_tgt4_dg

Target Logical Volume nfs_tgt3_vol1 nfs_tgt3_vol2nfs_tgt4_vol1 nfs_tgt4_vol2

Migrating Veritas VCS shared logical volumes on Solaris 173

174

Examples

Migration Steps SummaryThe following table summarizes the steps for Veritas VCS shared logical volume migration.

VCS provides several ways to configure a service group:

◆ Configuring the service group using cluster manager (Java console)

◆ Configuring the service group using the command-line


1 Identify the devices to be migrated

2 Prepare shared target volume among all the cluster nodes

3 Install the EMCom package on Solaris4 Disable reboot persistency in cluster environments

5 Add Open Migrator/LM plug-in module into the running cluster (service group)

6 Add new EMCom agent (resource type), which has the attributes of “Volume” and “DiskGroup7 Add new emcom resource of above EMCom type configured in the service group

8 Link new emcom resource between each filesystem mount and logical volume resources pair

9 Check the cluster and service group state, and make sure the service group is still online on the active node

Start Migration10 Creating the session11 Activating the session

12 Copy and Compare the session

After Migration13 Verify migration completes successfully

14 Completing the session

15 Offline Service group16 Check the cluster package log and EMCom cluster log to ensure no error happened

17 Remove Open Migrator/LM resource and agent from running cluster

18 Restore the dependency tree19 Remove Open Migrator/LM module files from /opt/VRTSvcs/bin/ on all cluster nodes

20 Check the data integrity between original source and new target volumes

21 Reconfigure the application and cluster service group to use the target volumes (and disk group).22 Restart (online) the application and service group

23 Clean up Open Migrator/LM and uninstall Open Migrator/LM package


Examples

During this example, we use the command line to modify cluster configuration.

The following is the Veritas Cluster configuration file "main.cf" of the running cluster before installing Open Migrator/LM:

sparc220# cat /etc/VRTSvcs/conf/config/main.cfinclude "types.cf"include "VProNFSMountTypes.cf"cluster sparc-omcluster (UserNames = { admin = HMNfMHmJNiNNlVNhMK }Administrators = { admin })system sparc220 ()

system sparc222 ()

group NFS (SystemList = { sparc220 = 0, sparc222 = 1 }AutoStartList = { sparc220, sparc222 })

DiskGroup vNFS1_DiskGroup (DiskGroup = nfs_src3_dgPanicSystemOnDGLoss = 1)

DiskGroup vNFS2_DiskGroup (DiskGroup = nfs_src4_dg)

IP vNFS_IP (Device = e1000g0Address = "10.32.70.150"NetMask = "255.255.255.128")

Mount vNFS1_Mount1 (MountPoint = "/nfsshare1"BlockDevice = "/dev/vx/dsk/nfs_src3_dg/nfs_src3_vol1"FSType = vxfsMountOpt = rwFsckOpt = "-y -o full")




176

Examples


NFSRestart vNFS_NFSRestart (NFSRes = vNFS_IPLocksPathName = "/opt/VRTSvcs/lock")

NIC vNFS_NIC (Device = e1000g0NetworkType = ether)

Share vNFS1_Share1 (PathName = "/nfsshare1"Options = rw)




Volume vNFS1_volume1 (Volume = nfs_src3_vol1DiskGroup = nfs_src3_dg)




vNFS1_Mount1 requires vNFS1_volume1vNFS1_Mount2 requires vNFS1_volume2vNFS1_Share1 requires vNFS1_Mount1vNFS1_Share2 requires vNFS1_Mount2vNFS1_volume1 requires vNFS1_DiskGroupvNFS1_volume2 requires vNFS1_DiskGroupvNFS2_Mount1 requires vNFS2_volume1


Examples

vNFS2_Mount2 requires vNFS2_volume2vNFS2_Share1 requires vNFS2_Mount1vNFS2_Share2 requires vNFS2_Mount2vNFS2_volume1 requires vNFS2_DiskGroupvNFS2_volume2 requires vNFS2_DiskGroupvNFS_IP requires vNFS1_Share1vNFS_IP requires vNFS1_Share2vNFS_IP requires vNFS2_Share1vNFS_IP requires vNFS2_Share2vNFS_IP requires vNFS_NICvNFS_NFSRestart requires vNFS_IP

// resource dependency tree////group NFS//{//NFSRestart vNFS_NFSRestart// {// IP vNFS_IP// {// Share vNFS1_Share1// {// Mount vNFS1_Mount1// {// Volume vNFS1_volume1// {// DiskGroup vNFS1_DiskGroup// }// }// }// Share vNFS1_Share2// {// Mount vNFS1_Mount2// {// Volume vNFS1_volume2// {// DiskGroup vNFS1_DiskGroup// }// }// }// Share vNFS2_Share1// {// Mount vNFS2_Mount1// {// Volume vNFS2_volume1// {// DiskGroup vNFS2_DiskGroup// }// }// }// Share vNFS2_Share2// {// Mount vNFS2_Mount2// {// Volume vNFS2_volume2// {// DiskGroup vNFS2_DiskGroup// }// }// }// NIC vNFS_NIC// }// }//}


178

Examples

Note: For VCS 5.0 MP3 (Solaris), By default the PanicSystemOnDGLoss attribute is set to 1 (true). The attribute will cause VCS to panic the system on sudden loss of the diskgroup, when imported by VCS. The resource will also need to be marked as "Critical" for the panic to occur. VCS will not panic the system if the resource is not marked critical. See the http://seer.entsupport.symantec.com/docs/328799.htm

The following is Veritas Cluster Service Group "NFS" resource view as below before installing Open Migrator/LM.


Examples

Before Migration1. Identifying devices to migrated.

For this example, the devices are used in the "NFS" service group as following: nfs_src3_vol1, nfs_src3_vol2, nfs_src4_vol1, nfs_src4_vol2.

sparc220# vxprint -vit -g nfs_src3_dgV NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL PREFPLEX UTYPE v nfs_src3_vol1 - ENABLED ACTIVE 2048000 SELECT - fsgenv nfs_src3_vol2 - ENABLED ACTIVE 2048000 SELECT - fsgensparc220# vxprint -vit -g nfs_src4_dgV NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL PREFPLEX UTYPE v nfs_src4_vol1 - ENABLED ACTIVE 2048000 SELECT - fsgenv nfs_src4_vol2 - ENABLED ACTIVE 2048000 SELECT - fsgen

sparc220# hares -display vNFS1_volume1|grep sparc220vNFS1_volume1 LastOnline global sparc220vNFS1_volume1 ArgListValues sparc220 Volume 1 nfs_src3_vol1 DiskGroup 1 nfs_src3_dg vNFS1_volume1 ConfidenceLevel sparc220 100vNFS1_volume1 Flags sparc220 vNFS1_volume1 IState sparc220 not waitingvNFS1_volume1 Probed sparc220 1vNFS1_volume1 Start sparc220 1vNFS1_volume1 State sparc220 ONLINEvNFS1_volume1 MonitorTimeStats sparc220 Avg 0 TS sparc220# hares -display vNFS1_volume2|grep sparc220vNFS1_volume2 LastOnline global sparc220vNFS1_volume2 ArgListValues sparc220 Volume 1 nfs_src3_vol2 DiskGroup 1 nfs_src3_dgvNFS1_volume2 ConfidenceLevel sparc220 100vNFS1_volume2 Flags sparc220 vNFS1_volume2 IState sparc220 not waitingvNFS1_volume2 Probed sparc220 1vNFS1_volume2 Start sparc220 1vNFS1_volume2 State sparc220 ONLINEvNFS1_volume2 MonitorTimeStats sparc220 Avg 0 TS sparc220# hares -display vNFS2_volume1|grep sparc220vNFS2_volume1 LastOnline global sparc220vNFS2_volume1 ArgListValues sparc220 Volume 1 nfs_src4_vol1 DiskGroup 1 nfs_src4_dgvNFS2_volume1 ConfidenceLevel sparc220 100vNFS2_volume1 Flags sparc220 vNFS2_volume1 IState sparc220 not waitingvNFS2_volume1 Probed sparc220 1vNFS2_volume1 Start sparc220 1vNFS2_volume1 State sparc220 ONLINEvNFS2_volume1 MonitorTimeStats sparc220 Avg 0 TS sparc220# hares -display vNFS2_volume2|grep sparc220vNFS2_volume2 LastOnline global sparc220vNFS2_volume2 ArgListValues sparc220 Volume 1 nfs_src4_vol2 DiskGroup 1 nfs_src4_dgvNFS2_volume2 ConfidenceLevel sparc220 100vNFS2_volume2 Flags sparc220 vNFS2_volume2 IState sparc220 not waitingvNFS2_volume2 Probed sparc220 1vNFS2_volume2 Start sparc220 1vNFS2_volume2 State sparc220 ONLINEvNFS2_volume2 MonitorTimeStats sparc220 Avg 0 TS


180

Examples

2. Prepare shared target volume among all the cluster nodes

1. On Active Node: sparc220#Create DiskGroup nfs_tgt3_dg and nfs_tgt4_dg#Create Volume nfs_tgt3_vol1, nfs_tgt3_vol2, nfs_tgt4_vol1 ,nfs_tgt4_vol2sparc220# /etc/vx/bin/vxdisksetup -ifv emcpower45sparc220# /etc/vx/bin/vxdisksetup -ifv emcpower46sparc220# /etc/vx/bin/vxdisksetup -ifv emcpower47sparc220# /etc/vx/bin/vxdisksetup -ifv emcpower48sparc220# vxdg init nfs_tgt3_dg emcpower45 emcpower46 emcpower47 emcpower48sparc220# vxdg -g nfs_tgt3_dg set autoimport=nosparc220# vxassist -g nfs_tgt3_dg make nfs_tgt3_vol1 1000msparc220# vxassist -g nfs_tgt3_dg make nfs_tgt3_vol2 1000m

sparc220# /etc/vx/bin/vxdisksetup -ifv emcpower56sparc220# /etc/vx/bin/vxdisksetup -ifv emcpower57sparc220# /etc/vx/bin/vxdisksetup -ifv emcpower58sparc220# vxdg init nfs_tgt4_dg emcpower56 emcpower57 emcpower58sparc220# vxdg -g nfs_tgt4_dg set autoimport=nosparc220# vxassist -g nfs_tgt4_dg make nfs_tgt4_vol1 1000msparc220# vxassist -g nfs_tgt4_dg make nfs_tgt4_vol2 1000m

2. Moving Disk Groups Between Systems back and forth

On Active Node :sparc220:

sparc220# vxvol -g nfs_tgt3_dg stopallsparc220# vxdg flush nfs_tgt3_dgsparc220# vxdg deport nfs_tgt3_dg

sparc220# vxvol -g nfs_tgt4_dg stopallsparc220# vxdg flush nfs_tgt4_dgsparc220# vxdg deport nfs_tgt4_dg

On Passive Node :sparc222:

sparc222# vxdg -t import nfs_tgt3_dgsparc222# vxrecover -g nfs_tgt3_dg -ssparc222# vxdg -t import nfs_tgt4_dgsparc222# vxrecover -g nfs_tgt4_dg -s

Note: Before migration, move the Diskgroup back to Active Node.

3. Install Open Migrator/LM package on Solaris.

sparc220# pkgadd -d /tmp/EMCom.strm EMCom

4. Disable reboot persistency in cluster environments

sparc220# stormigrate tune -checkpointsize NONE -nop

5. Add the Open Migrator/LM plug-in module into the running cluster (service group)

For the active node:

sparc220# cp -rf /etc/opt/EMCom/cluster/vcs/EMCom /opt/VRTSvcs/bin/


Examples

For the passive node:

sparc220# scp -r /opt/VRTSvcs/bin/EMCom sparc222:/opt/VRTSvcs/bin/

6. Add new a EMCom agent (resource type), which has the attributes of "Volume" and "DiskGroup".

sparc220# haconf -makerwsparc220# hatype -add EMCom sparc220# hatype -modify EMCom SourceFile "./emcom.cf"sparc220# haattr -add EMCom Volume -string -scalarsparc220# haattr -add EMCom DiskGroup -string -scalarsparc220# hatype -modify EMCom ArgList Volume DiskGroup

7. Add two new emcom resources of above EMCom type with the "DiskGroup" attribute being specified as the disk group name ("nfs_src3_dg" and "nfs_src4_dg" in the example) configured in the service group ("NFS" in the example). Each disk group requires a new resource of EMCom type.

Resource "emcom1" for disk group "nfs_src3_dg":

sparc220# hares -add emcom1 EMCom NFSsparc220# hares -modify emcom1 Critical 0sparc220# hares -modify emcom1 DiskGroup nfs_src3_dgsparc220# hares -modify emcom1 Enabled 1sparc220# hares -online emcom1-sys sparc220

Resource "emcom2" for disk group "nfs_src4_dg":

sparc220# hares -add emcom2 EMCom NFSsparc220# hares -modify emcom2 Critical 0sparc220# hares -modify emcom2 DiskGroup nfs_src4_dgsparc220# hares -modify emcom2 Enabled 1sparc220# hares -online emcom2 -sys sparc220

8. Link the two new emcom resource between each filesystem mount and logical volume resources pair, corresponding to the disk group ("nfs_src3_dg" and "nfs_src4_dg" in the example) as specified as the "DiskGroup" attribute of the new emcom resources.

For the volumes in disk group of "nfs_src3_dg":

sparc220# hares -unlink vNFS1_Mount1 vNFS1_volume1sparc220# hares -link vNFS1_Mount1 emcom1 sparc220# hares -link emcom1 vNFS1_volume1

sparc220# hares -unlink vNFS1_Mount2 vNFS1_volume2sparc220# hares -link vNFS1_Mount2 emcom1 sparc220# hares -link emcom1 vNFS1_volume2

For the volumes in disk group of "nfs_src4_dg":

sparc220# hares -unlink vNFS2_Mount1 vNFS2_volume1sparc220# hares -link vNFS2_Mount1 emcom2


182

Examples

sparc220# hares -link emcom2 vNFS2_volume1

sparc220# hares -unlink vNFS2_Mount2 vNFS1_volume2sparc220# hares -link vNFS2_Mount2 emcom2 sparc220# hares -link emcom2 vNFS2_volum2

sparc220# haconf -dump -makero

The following is the Veritas Cluster configuration file "main.cf" after adding Open Migrator/LM plug-in module:

sparc220# cat /etc/VRTSvcs/conf/config/main.cfinclude "types.cf"include "emcom.cf"include "VProNFSMountTypes.cf"

cluster sparc-omcluster (UserNames = { admin = HMNfMHmJNiNNlVNhMK }Administrators = { admin })

system sparc220 ()

system sparc222 ()

group NFS (SystemList = { sparc220 = 0, sparc222 = 1 }AutoStartList = { sparc220, sparc222 })

DiskGroup vNFS1_DiskGroup (DiskGroup = nfs_src3_dgPanicSystemOnDGLoss = 1)

DiskGroup vNFS2_DiskGroup (DiskGroup = nfs_src4_dg)

EMCom emcom1 (DiskGroup = nfs_src3_dg)

EMCom emcom2 (DiskGroup = nfs_src4_dg)

IP vNFS_IP (Device = e1000g0Address = "10.32.70.150"NetMask = "255.255.255.128")


Mount vNFS1_Mount2 (


Examples

MountPoint = "/nfsshare2"BlockDevice = "/dev/vx/dsk/nfs_src3_dg/nfs_src3_vol2"FSType = vxfsMountOpt = rwFsckOpt = "-y -o full")



NFSRestart vNFS_NFSRestart (NFSRes = vNFS_IPLocksPathName = "/opt/VRTSvcs/lock")

NIC vNFS_NIC (Device = e1000g0NetworkType = ether)







Volume vNFS2_volume1 (Volume = nfs_src4_vol1


184

Examples

DiskGroup = nfs_src4_dg)


emcom1 requires vNFS1_volume1emcom1 requires vNFS1_volume2emcom2 requires vNFS2_volume1emcom2 requires vNFS2_volume2vNFS1_Mount1 requires emcom1vNFS1_Mount2 requires emcom1vNFS1_Share1 requires vNFS1_Mount1vNFS1_Share2 requires vNFS1_Mount2vNFS1_volume1 requires vNFS1_DiskGroupvNFS1_volume2 requires vNFS1_DiskGroupvNFS2_Mount1 requires emcom2vNFS2_Mount2 requires emcom2vNFS2_Share1 requires vNFS2_Mount1vNFS2_Share2 requires vNFS2_Mount2vNFS2_volume1 requires vNFS2_DiskGroupvNFS2_volume2 requires vNFS2_DiskGroupvNFS_IP requires vNFS1_Share1vNFS_IP requires vNFS1_Share2vNFS_IP requires vNFS2_Share1vNFS_IP requires vNFS2_Share2vNFS_IP requires vNFS_NICvNFS_NFSRestart requires vNFS_IP

// resource dependency tree////group NFS//{//NFSRestart vNFS_NFSRestart// {// IP vNFS_IP// {// Share vNFS1_Share1// {// Mount vNFS1_Mount1// {// EMCom emcom1// {// Volume vNFS1_volume1// {// DiskGroup vNFS1_DiskGroup// }// Volume vNFS1_volume2// {// DiskGroup vNFS1_DiskGroup// }// }// }// }// Share vNFS1_Share2// {// Mount vNFS1_Mount2// {// EMCom emcom1// {// Volume vNFS1_volume1// {


Examples

// DiskGroup vNFS1_DiskGroup// }// Volume vNFS1_volume2// {// DiskGroup vNFS1_DiskGroup// }// }// }// }// Share vNFS2_Share1// {// Mount vNFS2_Mount1// {// EMCom emcom2// {// Volume vNFS2_volume1// {// DiskGroup vNFS2_DiskGroup// }// Volume vNFS2_volume2// {// DiskGroup vNFS2_DiskGroup// }// }// }// }// Share vNFS2_Share2// {// Mount vNFS2_Mount2// {// EMCom emcom2// {// Volume vNFS2_volume1// {// DiskGroup vNFS2_DiskGroup// }// Volume vNFS2_volume2// {// DiskGroup vNFS2_DiskGroup// }// }// }// }// NIC vNFS_NIC// }// }//}


186

Examples

See Veritas Cluster Service Group NFS resource view as below After adding Open Migrator/LM module into the service group (NFS)

9. Check the cluster and service group state, and make sure the service group is still online on the active node (sparc220).

sparc220# hastatus -sum -- SYSTEM STATE-- System State Frozen A sparc220 RUNNING 0 A sparc222 RUNNING 0 -- GROUP STATE-- Group System Probed AutoDisabled State B NFS sparc220 Y N ONLINE B NFS sparc222 Y N OFFLINE


Examples

Start Migration10. Creating the session.

The sessionfile contains the logical volumes being used by the cluster application that are to be migrated.

Note: All the volumes contained in an Open Migrator/LM session must belong to only one disk group in a cluster service group.

sparc220# cat sessionfile1/dev/vx/rdsk/nfs_src3_dg/nfs_src3_vol1 /dev/vx/rdsk/nfs_tgt3_dg/nfs_tgt3_vol1/dev/vx/rdsk/nfs_src3_dg/nfs_src3_vol2 /dev/vx/rdsk/nfs_tgt3_dg/nfs_tgt3_vol2 sparc220# cat sessionfile2 /dev/vx/rdsk/nfs_src4_dg/nfs_src4_vol1 /dev/vx/rdsk/nfs_tgt4_dg/nfs_tgt4_vol1/dev/vx/rdsk/nfs_src4_dg/nfs_src4_vol2 /dev/vx/rdsk/nfs_tgt4_dg/nfs_tgt4_vol2

sparc220# stormigrate create -s nfs1 -file ./sessionfile1sparc220# stormigrate create -s nfs2 -file ./sessionfile2

11. Activating the session.

sparc220# stormigrate act -s nfs1sparc220# stormigrate act -s nfs2

12. Managing the session.

sparc220# stormigrate copy -s nfs1sparc220# stormigrate compare -s nfs1sparc220# stormigrate copy -s nfs2sparc220# stormigrate compare -s nfs2


188

Examples

After Migration13. Verify migration completes successfully.

sparc220# stormigrate q -s nfs1 -v S D y o Current Task n Rate n MBSource Target Action State c MB/s % e Left----------------------- ----------------------- -------- ----- - ---- --- -----/dev/vx/rdsk/nfs_src3_dg/nfs_src3_vol1 /dev/vx/rdsk/nfs_tgt3_dg/nfs_tgt3_vol1 Compare Done Y 0 100 0/dev/vx/rdsk/nfs_src3_dg/nfs_src3_vol2 /dev/vx/rdsk/nfs_tgt3_dg/nfs_tgt3_vol2 Compare Done Y 0 100 0 ---- --- -----Total Copy: 0 0 0Total Compare: 0 100 0 Session Name: nfs1Session State: ActiveAction Plan: CompareTask States: DoneNumber of Pairs: 2Total Source Size: 2000 MBSystem I/O Processing: MIRRORINGTarget Devices State: NRTime: 17:04:46

sparc220# stormigrate q -s nfs2 -v S D y o Current Task n Rate n MBSource Target Action State c MB/s % e Left----------------------- ----------------------- -------- ----- - ---- --- -----/dev/vx/rdsk/nfs_src4_dg/nfs_src4_vol1 /dev/vx/rdsk/nfs_tgt4_dg/nfs_tgt4_vol1 Compare Done Y 0 100 0/dev/vx/rdsk/nfs_src4_dg/nfs_src4_vol2 /dev/vx/rdsk/nfs_tgt4_dg/nfs_tgt4_vol2 Compare Done Y 0 100 0 ---- --- -----Total Copy: 0 0 0Total Compare: 0 100 0 Session Name: nfs2Session State: ActiveAction Plan: CompareTask States: DoneNumber of Pairs: 2Total Source Size: 2000 MBSystem I/O Processing: MIRRORINGTarget Devices State: NRTime: 17:07:01


Examples


Run "stormigrate complete -s session_name" subcommand to mark the migration success for the cluster.

sparc220# stormigrate complete -s nfs1sparc220# stormigrate complete -s nfs2sparc220# stormigrate q -s nfs1 -clus S D y o Current Task n Rate n MBSource Target Action State c MB/s % e Left----------------------- ----------------------- -------- ----- - ---- --- -----*_src3_dg/nfs_src3_vol1 *_tgt3_dg/nfs_tgt3_vol1 Compare Done Y 0 100 0*_src3_dg/nfs_src3_vol2 *_tgt3_dg/nfs_tgt3_vol2 Compare Done Y 0 100 0 ---- --- -----Total Copy: 0 0 0Total Compare: 0 100 0

Session Name: nfs1Session State: ActiveCluster State: CompleteAction Plan: CompareTask States: DoneNumber of Pairs: 2Total Source Size: 2000 MBSystem I/O Processing: MIRRORINGTarget Devices State: NRTime: 17:23:45

sparc220# stormigrate q -s nfs2 -clus S D y o Current Task n Rate n MBSource Target Action State c MB/s % e Left----------------------- ----------------------- -------- ----- - ---- --- -----*_src4_dg/nfs_src4_vol1 *_tgt4_dg/nfs_tgt4_vol1 Compare Done Y 0 100 0*_src4_dg/nfs_src4_vol2 *_tgt4_dg/nfs_tgt4_vol2 Compare Done Y 0 100 0 ---- --- -----Total Copy: 0 0 0Total Compare: 0 100 0 Session Name: nfs2Session State: ActiveCluster State: CompleteAction Plan: CompareTask States: DoneNumber of Pairs: 2Total Source Size: 2000 MBSystem I/O Processing: MIRRORINGTarget Devices State: NRTime: 17:24:27

15. Offline the service group.

The Open Migrator/LM plug-in module will automatically deactivate the completed sessions for the cluster.

sparc220# hagrp -offline NFS -sys sparc220


190

Examples

16. Check cluster state and engine log for any errors. The service group should be in "offline" state on all cluster nodes. If the service group has been successfully offline and there are no any I/O errors, the Open Migrator/LM plug-in module will log a "cluster migration completed successfully" message.

sparc220# hastatus -sum -- SYSTEM STATE-- System State Frozen A sparc220 RUNNING 0 A sparc222 RUNNING 0 -- GROUP STATE-- Group System Probed AutoDisabled State B NFS sparc220 Y N OFFLINE B NFS sparc222 Y N OFFLINE

sparc220# vi /var/VRTSvcs/log/engine_A.log 2010/08/12 17:26:51 VCS INFO V-16-1-10305 Resource vNFS2_Mount1 (Owner: unknown, Group: NFS) is offline on sparc220 (VCS initiated)2010/08/12 17:26:51 VCS NOTICE V-16-1-20001 (sparc220) EMCom:emcom1:offline:Deactivating session nfs1 ...2010/08/12 17:26:51 VCS INFO V-16-1-10305 Resource vNFS2_Mount2 (Owner: unknown, Group: NFS) is offline on sparc220 (VCS initiated)2010/08/12 17:26:51 VCS NOTICE V-16-1-10300 Initiating Offline of Resource emcom2 (Owner: unknown, Group: NFS) on System sparc2202010/08/12 17:26:51 VCS NOTICE V-16-1-20002 (sparc220) EMCom:emcom1:offline:Session nfs1 completed successfully for the cluster2010/08/12 17:26:52 VCS NOTICE V-16-1-20001 (sparc220) EMCom:emcom2:offline:Deactivating session nfs2 ...2010/08/12 17:26:52 VCS NOTICE V-16-1-20002 (sparc220) EMCom:emcom2:offline:Session nfs2 completed successfully for the cluster

Also check the session status

sparc220# stormigrate list|grep nfs[1-2]nfs1 Inactive nfs2 Inactive

Note: The Open Migrator/LM related log messages are also available at: /var/EMCom/log/emcom-cluster-V3.12.0.8-20100812.log

17. Remove the Open Migrator/LM module from the cluster.

Remove the emcom resource and its agent.

sparc220# haconf -makerwsparc220# hares -delete emcom1sparc220# hares -delete emcom2sparc220# hatype -delete EMCom


Examples

18. Restore the dependency tree.

sparc220# hares -link vNFS1_Mount1 vNFS1_volume1sparc220# hares -link vNFS1_Mount2 vNFS1_volume2

sparc220# hares -link vNFS2_Mount1 vNFS2_volume1sparc220# hares -link vNFS2_Mount2 vNFS1_volume2


19. Remove Open Migrator/LM module files from /opt/VRTSvcs/bin/ on all cluster nodes.

For the active node:

sparc220# rm -rf /opt/VRTSvcs/bin/EMCom

For the passive node:

sparc220# ssh sparc222 rm -rf /opt/VRTSvcs/bin/EMCom

20. Check the data integrity between original source and new target volumes.

The source disk group and volume should be manually imported and started.

Mount the source and target, verify the source and target is identical.

sparc220# vxdg import nfs_src3_dg sparc220# vxdg import nfs_src4_dg sparc220# vxvol -g nfs_src3_dg startallsparc220# vxvol -g nfs_src4_dg startall

sparc220# mount -F vxfs /dev/vx/dsk/nfs_tgt3_dg/nfs_tgt3_vol1 /mnt3_tgt1sparc220# mount -F vxfs /dev/vx/dsk/nfs_src3_dg/nfs_src3_vol1 /mnt3_src1sparc220# mount -F vxfs /dev/vx/dsk/nfs_tgt3_dg/nfs_tgt3_vol2 /mnt3_tgt2sparc220# mount -F vxfs /dev/vx/dsk/nfs_src3_dg/nfs_src3_vol2 /mnt3_src2sparc220# mount -F vxfs /dev/vx/dsk/nfs_tgt4_dg/nfs_tgt4_vol1 /mnt4_tgt1 sparc220# mount -F vxfs /dev/vx/dsk/nfs_src4_dg/nfs_src4_vol1 /mnt4_src1sparc220# mount -F vxfs /dev/vx/dsk/nfs_tgt4_dg/nfs_tgt4_vol2 /mnt4_tgt2sparc220# mount -F vxfs /dev/vx/dsk/nfs_src4_dg/nfs_src4_vol2 /mnt4_src2sparc220# diff -r /mnt3_src1 /mnt3_tgt1sparc220# diff -r /mnt3_src2 /mnt3_tgt2sparc220# diff -r /mnt4_src1 /mnt3_tgt1sparc220# diff -r /mnt4_src2 /mnt3_tgt2

21. Reconfigure the application and cluster service group to use the target volumes (and disk group).

sparc220# hares -modify vNFS1_DiskGroup DiskGroup nfs_tgt3_dgsparc220# hares -modify vNFS1_volume1 Volume nfs_tgt3_vol1sparc220# hares -modify vNFS1_volume2 Volume nfs_tgt3_vol2sparc220# hares -modify vNFS1_Mount1 BlockDevice /dev/vx/dsk/nfs_tgt3_dg/nfs_tgt3_vol1sparc220# hares -modify vNFS1_Mount2 BlockDevice /dev/vx/dsk/nfs_tgt3_dg/nfs_tgt3_vol2


192

Examples

sparc220# hares -modify vNFS2_DiskGroup DiskGroup nfs_tgt4_dgsparc220# hares -modify vNFS2_volume1 Volume nfs_tgt4_vol1sparc220# hares -modify vNFS2_volume2 Volume nfs_tgt4_vol2sparc220# hares -modify vNFS2_Mount BlockDevice /dev/vx/dsk/nfs_tgt4_dg/nfs_tgt4_vol1sparc220# hares -modify vNFS1_Mount1 BlockDevice /dev/vx/dsk/nfs_tgt4_dg/nfs_tgt4_vol2


22. Restart the application (online) and the service group.

sparc220# hagrp -online NFS -sys sparc220sparc220# hastatus -sum

-- SYSTEM STATE-- System State Frozen

A sparc220 RUNNING 0A sparc222 RUNNING 0

-- GROUP STATE-- Group System Probed AutoDisabled State

B NFS sparc220 Y N ONLINE B NFS sparc222 Y N OFFLINE

23. Clean up Open Migrator/LM and uninstall the Open Migrator/LM package.

sparc220# stormigrate cleanup -nopsparc220# pkgrm EMCom


Documents

Open Migrator/LM for UNIX and Linux CLI - Dell EMC Corporation Corporate Headquarters: Hopkinton, MA 01748-9103 1-508-435-1000 EMC Open Migrator/LM for UNIX and Linux CLI Version 3.12