300-003-978_a01_elccnt_0

8/8/2019 300-003-978_a01_elccnt_0

1/98

1

This document provides best practices and advice for using EMC PowerPath Migration Enabler.

Topics include: Executive summary.............................................................................. 2 Introduction........................................................................................... 3 Overview of PowerPath Migration Enabler ..................................... 4 Open Replicator scenario 1: Pseudo device to pseudo device....... 6 Open Replicator scenario 2: Native device to pseudo device...... 14 Invista encapsulation scenario ......................................................... 30 VERITAS volume management........................................................ 45 Tips and best practices....................................................................... 65 Conclusion........................................................................................... 75 References............................................................................................ 76 Appendix: Scripts ............................................................................... 77

Implementing PowerPath MigrationEnabler in Open Replicator and

Invista Environments

P/N 300-003-978Rev A01

August 30, 2006

8/8/2019 300-003-978_a01_elccnt_0

2/98

2 Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments

Executive summary

Executive summaryEMC PowerPath Migration Enabler is a tool designed to leverageexisting EMC replication technologies and allow faster and easierdata migrations. PowerPath Migration Enabler is also designed tosignificantly decrease application downtime and provide enhanceddata protection. As a new product, there is a need for a deeperunderstanding of how to best perform a successful implementation.

In its initial release, PowerPath Migration Enabler enhances thecapabilities of EMC Open Replicator by maintaining both source andtarget devices in a consistent state. Mirroring the two devices allowsauditioning the migration and returning to the initial state with nodowntime. Additional benefits will be provided to users of EMCInvista, through transparent encapsulation of existing storagedevices. This functionality allows hosts that are using devicespresented through an existing array/SAN a potentially

nondistruptive method of accessing the same devices.This offering will be released with PowerPath version 5.0 for eachsupported operating system.

To aid in the deployment of the new offering, these technical notesfocus on use case scenarios, as well as tips and best practices to followduring implementations.

This document contains some information that is specific to theSolaris operating system used to implement the use cases. However,the majority of the information is generic, and focuses on thePowerPath Migration Enabler and the underlying replicationtechnologies.

8/8/2019 300-003-978_a01_elccnt_0

3/98

Implementing PowerPath Migration Enabler in Open Replicator and Invista Environments 3

Introduction

Introduction This document provides best practice guidelines for PowerPathMigration Enabler. To highlight these capabilities, the documentexamines the following use case scenarios: Perform a migration between PowerPath pseudo devices with no

disruption, using Open Replicator as the underlying replicationtechnology.

Perform a migration from native devices to PowerPath pseudodevices with minimum disruption, using Open Replicator as theunderlying replication technology.

Demonstrate the ability to increase file system size withoutdisruption after migration is complete. This scenario highlightsthe case of performing capacity uplift migrations.

Provide the steps necessary to complete a transparent,

nondisruptive Invista encapsulation of devices on a system that iscurrently accessing PowerPath pseudo devices.

This document also provides some tips and best practices not coveredin the use case scenarios. Many focus on environmental issues.

PowerPath Migration Enabler leverages the I/O filter of PowerPathand existing EMC replication technologies. Proper setup andfunctioning of these offerings is the key to success when using

PowerPath Migration Enabler.These technical notes are not a substitute for PowerPath MigrationEnabler training and user documentation. These notes assume thatthe reader has a basic understanding of PowerPath, PowerPathMigration Enabler commands, the underlying replication technologyinvolved, and any volume management software (such as VERITASVolume Manager or Solstice DiskSuite) referenced herein.

Note: Most importantly, this document is not a replacement for the PowerPath Migration Enabler User's Guide or the release notes. Be sure to read andunderstand both documents, as well as the documentation for any asoociatedproduct, before proceeding with implementation.

Audience

This document is intended for customers who are interested inmaximizing their Open Replicator environment or who areinvestigating implementing Invista storage virtualization product.

8/8/2019 300-003-978_a01_elccnt_0

4/98


Overview of PowerPath Migration Enabler

Overview of PowerPath Migration EnablerPowerPath Migration Enabler is a host-based migration tool thatallows migration of data between storage systems. This isaccomplished by using PowerPath technology in conjunction withother underlying technologies, such as Open Replicator or Invista.

PowerPath Migration Enabler is independent of PowerPathmultipathing technology, and requires a separate license to activate.

PowerPath Migration Enabler does not require that PowerPath formultipathing be enabled.

When data is being migrated by PowerPath Migration Enabler, thedata continues to be accessible to the host application. This greatlyreducesand potentially eliminatesdowntime. The level ofdisruption necessary to complete a migration depends on whetherthe data is referenced by a PowerPath pseudo device or a hostsystems native device, and on whether PowerPath is installed on thehost. If PowerPath has not been installed, a reboot may be necessaryto completely configure the host.

The possible scenarios for performing migrations in the currentrelease of PowerPath Migration Enabler for Solaris include: Pseudo-to-pseudo devices Native-to-native devices Native-to-pseudo devices

PowerPath pseudo devices are location-independent devices thatrepresent a single logical device accessible over one or more paths.Also, a pseudo device is named in a location-independent way. Thisability to access data without the use of a pointer to any of thephysical devices associated with the data allows migrations that donot require reconfiguration of the application. When a migration is

performed from one pseudo device to another, the migration isnondisruptive.

Native devices are operating system-specific, location-dependentnames for devices that are presented to the host, and may reference asingle path or multiple paths to a logical device. When migrating datafrom a native device, the application requires an outage so that accessto the new target device can be properly configured. This may be aone-time disruption if the application is reconfigured to use a pseudodevice. In this event, future migration performed to pseudo deviceswould be nondisruptive.

8/8/2019 300-003-978_a01_elccnt_0

5/98


Overview of PowerPath Migration Enabler

PowerPath Migration Enabler is designed to work in conjunction

with an underlying technology, such as Open Replicator for EMCSymmetrix systems. Future releases may access other migrationengines. Generally, differences in how the underlying technologiesinteract with PowerPath Migration Enabler are transparent to theuser. Some pre/post-migration steps might differ depending on theunderlying technology; however, the goal is to provide a commonuser interface for performing migrations.

When using Open Replicator as the underlying technology, data iscopied from the source device through the fabric to the target device.Software on the Symmetrix system where the target device residescontrols the data movement. The mirroring of I/O to keep the sourceand target devices synchronized throughout the migration process isperformed by PowerPath Migration Enabler on the host.

In an Invista migration, Invista encapsulates the source device; noactual data is copied. Invista provides a method for nondisruptively

migrating devices from their original source into the virtualizedenvironment when EMC pseudo devices are involved. Whenmigrating data to an Invista Virtual Volume, the device is presentedthrough a parallel path to Invista, and the Virtual Volume is alsopresented to the host as the target device. The original device as seenon the host is the source device. The migration is then performedusing the standard PowerPath Migration Enabler commands.

The specific steps required for each migration depend on theunderlying technology involved. This is a critical point tounderstand; the setup of the underlying technology is key to thesuccess of PowerPath Migration Enabler. Most challenges lie inproper implementation of the underlying technology. Once this has been thoroughly verified, PowerPath Migration Enabler is simple touse, and very effective.

8/8/2019 300-003-978_a01_elccnt_0

6/98


Open Replicator scenario 1: Pseudo device to pseudo device

Open Replicator scenario 1: Pseudo device to pseudo deviceThe first use case scenario is the nondisruptive migration of pseudodevice pairs. In the example presented here, PowerPath 5.0 has beeninstalled as an upgrade to a system that had been using PowerPath4.5, and the application was configured to use pseudo devices. Thismigration requires an outage for the application so PowerPath 4.5 can be removed from the Solaris system and PowerPath 5.0 installed. Thecommand emcpreg -add was used to install the PowerPath MigrationEnabler license.

Open Replicator was also installed in the environment. To verify thatthe Open Replicator setup was properly configured, some minormigrations were performed to a Symmetrix DMX system from anEMC CLARiiON array.

For this use case scenario, the mounted file system /u01, which iscurrently using emcpower10c, will be migrated to emcpower27c.

We use powermt display commands to verify the configurationinformation that will be used in the migration. As Figure 1 on page 7 shows, the output from the powermt display commands for thesource (emcpower10c) and target (emcpower27c) identifies thecorrect emcpower device and verifies the array LUN.

8/8/2019 300-003-978_a01_elccnt_0

7/98



Figure 1 Listing the source/target pair

This method can be repeated or scripted to generate the source/targetpairings that will be needed to perform the migration. Once all of thepairs have been identified, each pair can be used to generate aPowerPath Migration Enabler session.

The migration steps are as follows:1. Type the following command to specify Open Replicator as the

technology type and establish the source/target pair: powermig setup -tt OR -src emcpower10c -tgt emcpower27c

2. To verify the setup, we type powermig info -all (as shown inFigure 2 on page 8 ).

8/8/2019 300-003-978_a01_elccnt_0

8/98



Figure 2 Establishing a source/target pair

The session for the first migration is ready to proceed and is in thesetup state.

3. To initiate the movement of data from the source to the target, wemust synchronize the source and target devices (using the handlethat was specified in the powermig setup output):

powermig sync -handle 4 -no

Note: The -no is short for -noprompt , which causes the command to beexecuted without requiring a user response.

4. To display a detailed progress of the migration, we type a query: powermig query -hd 4

Figure 3 on page 9 shows an output example.

8/8/2019 300-003-978_a01_elccnt_0

9/98



Figure 3 Displaying the migration progress

5. As Figure 3 shows, the output from powermig query includes aThrottle Value , which is a performance/resource utilizationsetting that is used to adjust the performance of Open Replicator.The default value of 5 is a conservative, middle-speed setting thatattempts to balance the speed of the data migration against the

load that Open Replicator will place on the arrays involved.The throttle value is passed on to the Open Replicator software,and adjusts the throughput for the particular session. The OpenReplicator parameter set ceiling can be applied directly to theOpen Replicator software to globally control throughput of all migration sessions managed by PowerPath Migration Enabler.

To accelerate the migration, a throttle setting is available. ( 0 is the

fastest, but creates the highest demand for resources; 9 is theslowest, but requires fewer resources.) Using the default value,the migration of the 8 GB device used in this example on a systemwith a light load took 64 minutes. The same migration with athrottle value of 0 took only three minutes. In EMC testing, theimpact to the application is negligible with the fastest speedsetting; however, performing a large number of migrations in anI/O-intensive environment could cause some impact. The only

8/8/2019 300-003-978_a01_elccnt_0

10/98



way to know for sure is through experimentation in the actualenvironment, as the number of possible variables are too many todocument.

For this example, we chose to accelerate the migration by settingthe throttle value to 0:

powermig throttle -hd 4 -tv 0 -no

A query (shown in Figure 4 ) displays the new throttle value.

Figure 4 Accelerating the migration

When the data transfer is complete, a query shows that thesession is in the sourceSelected state (as shown in Figure 5 on

page 11 ). This indicates that, while both the source and targetLUNs are being mirrored and the data is current on both, all readsare being performed from the source LUN.

6. Before the migration can be completed, the session must be set touse the LUN onto which the data was migrated:

powermig selectTarget -hd 4 -no

The lower portion of Figure 5 shows the output from a query sentafter selecting the target.

8/8/2019 300-003-978_a01_elccnt_0

11/98



Figure 5 Setting the LUN to be used

For further testing of the environment to reverse the migration,we can type powermig selectSource -hd 4 to make the systemresume all read activity to the source LUN. We can toggle between the source and target multiple times; this state ofmirroring will remain, even through system reboots.

7. Once the data synchronization is complete, we must set thesession to selectTarget state and execute powermig commit -hd 4 ,as shown in Figure 6 .

Figure 6 Committing the migration

8/8/2019 300-003-978_a01_elccnt_0

12/98



8. To clear the informational status, we type powermig cleanup -hd4, as shown in Figure 7 .

Figure 7 Clearing the informational status

9. An investigation of the results ( Figure 8 on page 13 ) shows thatthe file system is still active and mounted on the host, and isavailable for use by any application the host is configured tosupport. However, an investigation of the devices associated withthe source/target pair involved shows that while the pseudodevice in use remains the same, the underlying native devices

have been migrated.

8/8/2019 300-003-978_a01_elccnt_0

13/98



Figure 8 Displaying the migration results

8/8/2019 300-003-978_a01_elccnt_0

14/98


Open Replicator scenario 2: Native device to pseudo device

Open Replicator scenario 2: Native device to pseudo deviceIn this scenario, we migrate a Solstice DiskSuite metadevice (builtfrom two native devices) to PowerPath pseudo devices, withminimum disruption. Studies have indicated that when migrationsoccur, the opportunity is often taken to expand the capacity for theapplication. To address this opportunity, a procedure is provided forincreasing the volume size after the migration is complete.

In this example, PowerPath 5.0 was installed on the host for the firsttime. This procedure requires a reboot of the system for thePowerPath 5.0 installation.

Open Replicator was also installed in the environment. To verify thatthe Open Replicator setup was properly configured, some minormigrations were performed to a Symmetrix DMX system from anearlier Symmetrix model.

The major advantage of this scenario is that after the firstimplementation all future migrations on this system should notrequire an outage unless the metadevice is migrated to larger devicesand is to be increased again. As long as the operating system candiscover the newly added disk devices, and the applications that hadpreviously used native names to access data are now using thepseudo devices defined during this initial migration, PowerPathMigration Enabler can migrate data transparently to the system and

applications.

Note: The brief outage is required only for reconfiguring the SolsticeDiskSuite device, not for the operating system. If this migration wereperformed using PowerPath pseudo devices that were formatted with UFSand no volume manager was involved, the file system could be migrated andincreased without interruption.

8/8/2019 300-003-978_a01_elccnt_0

15/98



Identifying the devices

To identify the devices to be migrated:

1. As Figure 9 shows, we start by confirming the native devicesused for the DiskSuite metadevice to be migrated.

Figure 9 Confirming native devices used for migratation

Typing df -k displays the mounted file system, as shown inFigure 10 .

Figure 10 Displaying the mounted file system

8/8/2019 300-003-978_a01_elccnt_0

16/98



2. Next we type powermt display dev= device_nameto verify thedevices. (This is considered a best practice.)

Figure 11 below and Figure 12 on page 17 are output for thedevices that have been identified for use in this migration.

Figure 11 powermt display output for emcpower14a

8/8/2019 300-003-978_a01_elccnt_0

17/98



Figure 12 powermt display output for emcpower16a

PowerPath Migration Enabler acts on devices in a one-to-onerelationship. After the pairs have been confirmed, the procedure isnearly the same for each migration. Variations occur when nativedevices are involved. The difference is based on the fact that for

migrations that involved pseudo device names, the underlyingoperating system-defined native device names are shuffled toassociate with the pseudo name and the application can continuereferencing the data as it always has.

When native device names are used for the migration, the data istransferred in the same manner as the pseudo device migration, andthe application remains active and online, using the original sourcedevice name. The difference here is that when the migration iscommited, the I/O map redirection supplied by PowerPathMigration Enabler, which allows the application to access the data

8/8/2019 300-003-978_a01_elccnt_0

18/98



from the defined target device by calling the original source devicename, is stopped, and the application must be reconfigured to use thetarget device's native device name.

Performing the migration

To perform the migration:

1. We type a powermig setup command:

powermig setup -tt TechType -src device -tgt device

Figure 13 shows the output.

Figure 13 Confirming the setup

2. Once the setup has been confirmed, we can begin thesynchronization by typing the following command for eachdevice:

powermig sync -hd handle

Figure 14 on page 19 shows the output.

8/8/2019 300-003-978_a01_elccnt_0

19/98



Figure 14 Performing the synchronization

3. As Figure 14 also shows, we can adjust the throttle value for eachdevice:

powermig throttle -hd handle -tv value

4. When the data synchronization is complete, the displayed state issourceSelected (as shown in Figure 15 on page 20 ). We can toggle between the source and target devices by typing powermigselectTarget -hd handle and ' powermig selectSource -hd handle asmany times as necessary to confirm that the new target devicesare functioning as desired. The state is maintained throughreboots of the host.

When verification is complete and a brief outage window is availablefor the host, we perform the following steps to reconfigure themetadevice, increase the size of the file system, and complete the

migration.

8/8/2019 300-003-978_a01_elccnt_0

20/98

8/8/2019 300-003-978_a01_elccnt_0

21/98



devices so that the I/O now goes to the selected target devices,that all reads are performed from the new target devices,andmost importantlythe mirroring relationship between thesource/target pair has ended. Any change now made to theselected device will not be replicated.

Note: As a best practice, do not run in the the committedAndRedirectedstate for very long unless necessary. In this state, the system cannot bereverted to its previous setup state, and confusion is possible concerningexactly what data is on which device. This issue exists because the sourcedevice name is accessing the target device. To avoid potentialmismanagement of resources, stop the application(s) involved, typepowermig undoRedirect -hd handle to complete the commit, andperform all required application reconfiguration.

7. Lastly, we type powermig cleanup -hd handle to update the diskheader information on the original source devices. This requiresthat a format label be placed on the devices before they can bereused.

8/8/2019 300-003-978_a01_elccnt_0

22/98



Figure 16 Updating the disk header information

8/8/2019 300-003-978_a01_elccnt_0

23/98



Growing the Solstice DiskSuite metadevice after a native-to-pseudo migration

Now we can perform the steps required to reconfigure the SolsticeDiskSuite metadevice to use the new target devices. When this iscomplete, we can proceed to expanding the associated file system:

1. First we identify the slices used by the Solstice DiskSuitedatabase, as shown in Figure 17 . To change the configuration, wemust rebuild the database. The process is quick and easy.

Figure 17 Identifying the slices used by the Solstice DiskSuite database

2. With the information for the metadb ready, we clear themetadevice that we want to reconfigure, and then flush the metadatabase, as shown in Figure 18 .

With the system now in a clean slate, we update the configurationinformation for the metadevice, so that the information will point

to the new target devices.

Figure 18 Clearing the metadevice and flushing the meta database

8/8/2019 300-003-978_a01_elccnt_0

24/98



Figure 19 is an example of md.tab entry for the metadevice.

Figure 19 Example of md.tab entry

3. Before the metadb can be recreated and the metadeviceinitialized, we must perform the most critical step. Thepowerformat command is a new tool provided with PowerPath5.0. The command enables the ability to update disk headerinformation so the operating system can now recognizeandmore importantlyuse the proper disk geometry.

4. The next step in our example is to type the command

powerformat -gx /dev/rdsk/ device_namefor each new targetdevice.

When PowerPath Migration Enabler with Open Replicatorperforms a migration, Open Replicator does a block copy of thesourceincluding header informationto the target. When thetarget device is viewed by executing the Solaris format commandafter the commit and cleanup, the display includes the geometry

of the source device, including the LUNs size and partitioninformation. The host is unaware of the LUNs true capacity. Thepowerformat command provides the correct information.

8/8/2019 300-003-978_a01_elccnt_0

25/98



Figure 20 shows powerformat usage; Figure 21 on page 26 andFigure 22 on page 27 are examples of output.

Figure 20 powerformat command usage

8/8/2019 300-003-978_a01_elccnt_0

26/98



Figure 21 powerformat example for emcpower26c

O R li t i 2 N ti d i t d d i

8/8/2019 300-003-978_a01_elccnt_0

27/98



Figure 22 powerformat example for emcpower27c

5. Now that the operating system has the correct information for thedisk layout, we re-establish the metadb and perform the metainit .

As Figure 23 on page 28 shows, the system is still unaware of thenew capacity, but the metadevice is back and functional.


8/8/2019 300-003-978_a01_elccnt_0

28/98



Figure 23 Example of metainit output

6. The last step to expand the volume to use the new capacity is totype the Solaris growfs command, as shown in Figure 24 onpage 29 . This can be done with the file system mounted; however,I/O to this disk will be halted while the newfs portion of thecommand is executed, so this step should be performed just before restarting the application that requires access to the filesystem.


8/8/2019 300-003-978_a01_elccnt_0

29/98



Figure 24 Example of growfs output

Note: When performing any operations with Soltice Disksuite or any othervolume management software, carefully review the release notes foradditional information.

Invista encapsulation scenario

8/8/2019 300-003-978_a01_elccnt_0

30/98


p

Invista encapsulation scenarioThe scenario of Invista encapsulation is designed to aid in theadoption of Invista technology by providing a method of migratingexisting host devices into an Invista instance seamlessly, with little orno disruption of services. This can be achieved for systems alreadyconfigured to use PowerPath pseudo devices presented through aSAN or direct-attached to storage arrays. The same LUNs arepresented as Storage Elements to an Invista instance and back to the

host system as Invista Virtual Volumes.The environment for this use case consists of a system on whichPowerPath 5.0 was previously installed and the applications wereconfigured to leverage emcpowerdevices as presented from storagearrays through a SAN. These same storage array LUNs must bepresented to the Invista instance.

All of the devices the system is using from the SAN must be

presented to the Invista instance as Storage Elements, which must beset to a Not Ready state (preventing the volumes from being used inother operations) and imported into the Invista instance. InvistaVirtual Volumes are created from the Storage Elements and assigned toVirtual Frames , which are connected to the host(s). The last step beforethe encapsulation process is to refresh the device list on the system sothese LUNs can be seen, and the associated PowerPath pseudodevices built so the proper source/target pairs can be identified.

One of the major issues with this scenario is understanding thetopographical layout of the devices in the SAN and their access fromthe host system through both the SAN and the Invista instance, aswell as their presentation as Storage Elements into the Invistaenvironment.

Here are the steps in this scenario:

1. The first step in any data migration is identifying the resource to be moved. For this use case, we will use Symmetrix device8200198491 and PowerPath pseudo device/dev/dsk/emcpower7c (shown in Figure 25 on page 31 ).


8/8/2019 300-003-978_a01_elccnt_0

31/98


Figure 25 Identifying the device to be moved

2. The first step in the creation of a target device is to identify the back-end device as an Invista Storage Element and import it intothe Invista instance. On the Invista Element Manager GUI(graphical user interface), we select the Unimported folder, asshown in Figure 26 on page 32 . In the Unique ID column in theright pane, we find the associated device. (The Storage Elementused for this example is SE_0_5_2.)


8/8/2019 300-003-978_a01_elccnt_0

32/98


Figure 26 Listing unimported Invista Storage Elements

3. Now we open the Unimported folder, right-click the desiredStorage Element, and select Set Not Ready (Reserve) from thepop-up menu that appears.This step is very important because, when the device is presentedto the system, the ability to maintain data consistency is critical.Allowing access to the same data over multiple paths presents apossibility for data corruption.

4. Now we right-click the Storage Element, and select Import fromthe pop-up menu.


8/8/2019 300-003-978_a01_elccnt_0

33/98


The Storage Element moves from the Unimported folder to theImported folder.

5. To create a Virtual Volume, we right-click the Storage Element inthe Imported folder, and select Create Virtual Volume from thepop-up menu.

6. In the Create Virtual Volume dialog box ( Figure 27 ), we acceptthe default Virtual Volume Name or give the volume amore-useful name. To match to the current mount point, the nameppme_u01 was selected for this example.

Notice in Figure 27 that the Number of Virtual Volumes toCreate and Virtual Volume Size fields are not accessible becausethe Set Not Ready (Reserve) option was enabled. Whenperforming a PowerPath Migration Enabler encapsulation, theLUN layout is predetermined, and this process is designed toprotect the existing data.

Figure 27 Creating an Invista Virtual Volume

Clicking OK saves any changes and closes the dialog box.


8/8/2019 300-003-978_a01_elccnt_0

34/98


7. To make the Virtual Volume available to the system, we mustassign it to a Virtual Frame. After creating the Virtual Volume, we

expand the Virtual Frames folder, right-click the Virtual Frameassociated with the host, and select Select Virtual Volumes fromthe pop-up menu.

This displays a Virtual Frame Properties window ( Figure 28 ),which allows us to add the Virtual Volume to the Virtual Frame.

Figure 28 Adding an Invista Virtual Volume to a Virtual Frame: Before

8. Double-clicking the Virtual Volume in the left pane moves it tothe right pane, as shown in Figure 29 on page 35 .


8/8/2019 300-003-978_a01_elccnt_0

35/98


Figure 29 Adding an Invista Virtual Volume to a Virtual Frame: After

9. As Figure 29 shows, we now select the volume and assign a LUN

to it.Clicking OK saves any changes and closes the dialog box.

This completes the work required on the Invista instance to presentthe LUN to the host. Now we return to the host system for the nextphase of the encapsulation:

1. The device that is to become the target of the migration has been

presented to the system. Now we must make the device visible tothe host.


8/8/2019 300-003-978_a01_elccnt_0

36/98


The command devfsadm -C updates the operating system tocreate the proper device files. The commands powermt config

and powermt save create the desired PowerPath pseudo deviceentry.

The syminq command (shown in Figure 30 ) starts the process ofverifying that this is the correct device.

Figure 30 Example of syminq output

2. The verification process requires investigating the information on both the host system and the Invista instance. First, we typepowermt display dev= Invista_target_device, as shown in Figure 31

on page 37 .


8/8/2019 300-003-978_a01_elccnt_0

37/98


Figure 31 Example of powermt display outputNote the Logical device ID (60001440906024E40148C31020000023) in Figure 31 .

3. On the Invista Element Manager GUI, we display the propertiesof the Virtual Volume from within the Virtual Frame (as shown inFigure 32 on page 38 ).

Note that the logical device ID from the powermt display outputis the same as the Unique ID for the selected Virtual Volume.

Note: New with the PowerPath 5.0 release is the command powermtdisplay nonvirtual [dev=device|all] . The output from this commandlists the devices presented to the host by the Invista instance. The man page on powermt contains more details.


8/8/2019 300-003-978_a01_elccnt_0

38/98


Figure 32 Displaying the Invista Virtual Volume properties

Note: PowerPath Migration Enabler perform this same logical device IDverification when an attempt is made to execute powermig setup . If theincorrect source/target pair is selected, an error occurs. This step is used

to save time and prevent wasted efforts in attempting to generate correctsource/target pairs.

With the information for generating the source/target pairs available,the procedure is the same as with any PowerPath Migration Enablermigration: establish the source/target pair, synchronize (which forInvista encapsulation entails no actual data movement), select thetarget, and commit the migration. The only major difference is in thecleanup procedure, which is described later in this document.4. Begin the process by establishing the source/target pairs:

powermig setup -tt INVE -src device -tgt device

5. Verify that the setup was successful; then perform thesynchronization for the encapsulation to occur:

powermig sync -hd handle


8/8/2019 300-003-978_a01_elccnt_0

39/98


Since no data is actually being migrated, this is merely a step toredirect I/O to use the selected target/source path. As Figure 33

indicates, the query should show that the migration is in thesourceSelected state almost immediately.

Figure 33 Redirecting the I/O

6. With the device in the selectSource state, typing the followingcommands (as shown in Figure 34 on page 40 ) completes the

encapsulation: powermig selectTarget -hd handle

powermig commit -hd handle


8/8/2019 300-003-978_a01_elccnt_0

40/98


Figure 34 Completing the encapsulation

After the commit, the display of the mounted file system showsthat the mount point has not changed, and any I/O that had beenaccessing this device continued without interruption.

Figure 35 on page 41 and Figure 36 on page 42 are powermt displays of the emcpower devices used before and after this

encapsulation. Notice that only the native paths that were used toconstruct the pseudo device names changed; the pseudo devicenames themselves did not change.


8/8/2019 300-003-978_a01_elccnt_0

41/98


Figure 35 Devices before migration


8/8/2019 300-003-978_a01_elccnt_0

42/98


Figure 36 Devices after migration

7. The final step to complete this migration involves executing apowermig cleanup for this migration. Because the encapsulateddevice is actually the same LUN, the cleanup cannot act in thesame manner as in the Open Replicator migration and alter thedisk header information. Therefore, before the cleanup can becompleted successfully, the source LUN involved must beremoved from view of the operating system.

This can be accomplished by physically removing the cables fromthe HBAs that had provided access to this LUN (althoughnormally this is not an option) or through the use of zoning thedevice so that it is removed effectively. The method used toperform this zoning update is optional; use whatever method ismost familiar and comfortable; for example, Volume Logix,


8/8/2019 300-003-978_a01_elccnt_0

43/98


Access Logix or any other tool available. For the example inFigure 37 , a simple script containing symmask commands was

used.

Figure 37 Removing the source LUN from the operating systems view

8. With the device no longer visible to the system, the remainingcleanup can be performed by typing the following commands, asshown in Figure 38 on page 44 :

powermig cleanup -hd handle

powermt remove dev= target_device

Also, as whenever configuration changes are made in PowerPath,save the changes:

powermt save

Note: The pseudo device name removed from PowerPath was the target.The original source device name is still in use, but the logical units thatwere referenced by it have changed. Therefore, as displayed in theAftermig.lis, the pseudo device name to be cleared is the one thatreferences the original devices.


8/8/2019 300-003-978_a01_elccnt_0

44/98


Figure 38 Finishing the cleanup

Much of the work that is needed to perform Invista encapsulation ismanual, but could be scripted. The Invista Element Manager GUIalso facilitates implementation. The major benefit of thisencapsulation is thatwith proper planning, forethought, andconfigurationit can be executed without downtime to the host orapplication.

VERITAS volume management

8/8/2019 300-003-978_a01_elccnt_0

45/98


VERITAS volume managementMany environments looking to use a migration tool areenterprise-level solutions that often implement volume managementsoftware. VERITAS Volume Manager is one of the most commonsolutions used by customers who perform data migrations. Thissection is provided to help with the adoption of PowerPath MigrationEnabler in such an environment.

Using native-to-native migration to expand VERITAS VxVm 4.0 volumes

VxVM 4.0 volumes can be expanded after performing a powermig , but only when the volumes were constructed using native devices. Ifemcpower devices were used, you should migrate to like-size devicesand expand by adding LUNs to the Volume Group. This sectiondescribes the process to expand if native devices were used.

Note: This is a disruptive procedure, since the Volume Group must bedeported/imported for the new devices to be recognized.

In this example, we will use a handle of 27. As Figure 39 shows, theoutput from powermig commit -hd 27 shows the new state ascommittedAndRedirected .

Figure 39 Displaying the device state

The output shown in Figure 39 indicates that while the host system isstill calling source device c4t0d34s0, PowerPath is providingredirection to new target c3t0d34s0. This state can be held as long asis necessary to find a maintenance window during which the finalreconfiguration steps can be performed to allow the application(VxVM 4.0 in this case) the opportunity to be resized.


8/8/2019 300-003-978_a01_elccnt_0

46/98


1. When the application is available, we begin by unmounting anyfile systems associated with the Volume Group, as shown in

Figure 40 on page 46 .

Figure 40 Unmounting file systems

2. Now we type vxdg deport jpmc_ppmefs , as shown in Figure 41 .This allows the Volume Group to be brought back onto the hostutilizing the new devices.

Figure 41 Output from vxdg deport jpmc_ppmefs

3. With the Volume Group removed, we end the redirection process by typing powermig undoRedirect -hd 27 -no , as shown inFigure 42 on page 47 .


8/8/2019 300-003-978_a01_elccnt_0

47/98


Figure 42 Ending the redirection process

4. With the migration now in the committed state, we return theVolume Group to the system.

5. The next step is to bring the Volume Group back by typing vxdgimport jpmc_ppmefs , and verifying that the proper devices arepresent, as shown in Figure 43 .

Figure 43 Verifying that the correct devices are present


6 N di k j f i 3 0d34 2 (

8/8/2019 300-003-978_a01_elccnt_0

48/98


6. Next, we type vxdisk -g jpmc_ppmefs resize c3t0d34s2 (asshown in Figure 44 ) so the Volume Group can recognize the

additional capacity.

Figure 44 Allowing the Volume Group to recognize the additional capacity

7. Now that the additional capacity is available, we type vxvol -gjpmc_ppmefs startall to restart the Volume Group, and thenmount the devices as before, as shown in Figure 45 on page 49 .


8/8/2019 300-003-978_a01_elccnt_0

49/98


Figure 45 Restarting the Volume Group

8. To make the extra capacity available to the system, we type theVxVm commands shown in Figure 46 on page 50 . We use vxassist to identify and expand the underlying device, and fsadm toexpand the actual file system.


8/8/2019 300-003-978_a01_elccnt_0

50/98


Figure 46 Expanding the file system

9. Finally, we type powermig cleanup -hd 27 to flush the table ofhistorical information.


8/8/2019 300-003-978_a01_elccnt_0

51/98


Using pseudo-to-pseudo migration to expand VERITAS VxVm 4.1 volumes

In this example, a VxVM Volume Group was created using two 8 GBPowerPath pseudo devices. Three 5 GB UFS file systems were thenpresented to the system. Using PowerPath Migration Enabler, thesetwo devices will be migrated to two 16 GB devices, and the usablespace of one of the file systems will be expanded. This will beperformed without disruption:

1. First we examinine the devices that will be involved in the

migration, as shown in Figure 47 and Figure 48 .

Figure 47 Displaying mounted file systems


8/8/2019 300-003-978_a01_elccnt_0

52/98


Figure 48 Displaying VxVM volume information

2. We have identified emcpower28s2 and emcpower33s2 as thetarget devices to use for this migration. As displayed in the VxVMVolume information ( Figure 48 ), emcpower17s2 andemcpower18s2 will be the source devices.

We can save the information for the source and target devices to afile by typing powermt display dev=emcpowerXX . Figure 49 onpage 53 and Figure 50 on page 54 show the output from thecommand.


8/8/2019 300-003-978_a01_elccnt_0

53/98


Figure 49 Source device information from powermt display command


8/8/2019 300-003-978_a01_elccnt_0

54/98


Figure 50 Target device information from powermt display command

3. With the file systems mounted and the application continuing toprocess data, we perform the migration as described underUsing pseudo-to-pseudo migration to expand VERITAS VxVm4.1 volumes on page 51 (and as shown in Figure 51 on page 55 ).


8/8/2019 300-003-978_a01_elccnt_0

55/98


Figure 51 Performing setup and initiating migration

4. As was demonstrated in the previous use case scenarios, we canadjust the throttle value. Figure 52 on page 56 displays a query ofthe current setting for the default synchronization that wasstarted and the process of adjusting the throttle to accelerate themigration.


8/8/2019 300-003-978_a01_elccnt_0

56/98


Figure 52 Identifying and adjusting the migration throttle setting

5. Once the data synchronization is complete and has entered thesourceSelected state, we type powermig selectTarget andpowermig commit (as shown in Figure 53 on page 57 ), and finishthe migration by typing powermig cleanup . The VxVM 4.1volume is now ready to be expanded.


8/8/2019 300-003-978_a01_elccnt_0

57/98


Figure 53 Completing the migration

6. Before proceeding, we execute powermt display to verify eachdevice. As Figure 54 on page 58 and Figure 55 on page 59 show,while the emcpower devices are still attached and in use by theVxVM 4.1 Volume Group, the underlying native devicesreferenced by these pseudo names have changed to reflect thesource/target migration.


8/8/2019 300-003-978_a01_elccnt_0

58/98


Figure 54 Source device information from powermt display command


8/8/2019 300-003-978_a01_elccnt_0

59/98


Figure 55 Target device information from powermt display command

With the migration complete and verified as successful, we canexamine the VxVM Volume Group and see that nothing has changed.Using the following steps, we can expand the Volume Group andincrease the usable disk capacity of the file system withoutinterruption:

1. The first step is to update the VxVM Volume Group withinformation that the capacity of the associated devices has indeed

increased. This is accomplished by typing vxdisk -g group resize device(as shown in Figure 56 on page 60 ) and verifying that thecapacity has changed.


8/8/2019 300-003-978_a01_elccnt_0

60/98


Figure 56 Resizing and verifying a device

2. As Figure 56 shows, the length associated with the emcpower17s2device has increased from 17669376 to 35348736. To access theremaining capacity, we type vxdisk -g group resize devicefor eachremaining device in the migration.

3. Once the Volume Group has been configured to use the increasedcapacity, we type vxassist -g group maxsize to query the VolumeGroup for the exact amount that can be expanded.

4. To see the potential for the file system, we type vxassist -g group maxgrow vg_filesystem.

5. With the information we got from step 4, we type vxassist -g group growto vg_filesystem size to expand the VxVM file system tothe desired size, as shown in Figure 57 on page 61 .


8/8/2019 300-003-978_a01_elccnt_0

61/98


Figure 57 vxassist commands for expanding a VxVM file system

6. As Figure 58 on page 62 shows, a quick verification of the vxassistgrow process reveals that the ppmefs_1 file system has grownfrom 10485760 to 32045056.


8/8/2019 300-003-978_a01_elccnt_0

62/98


Figure 58 Display of increased capacity for ppmefs_1 file system

7. The last step to increase the usable size of the UFS file systemwhile that system continues to use the device is to execute theSolaris growfs command (shown in Figure 59 on page 63 ).

Note: I/O to the file system will stop for the time required to completethe newfs portion of growfs . This very short time is not a disruption ofservice, but creates a temporary performance degradation.


8/8/2019 300-003-978_a01_elccnt_0

63/98


Figure 59 growfs command output

8. To verify the success of the operation, we type df -k , as shown inFigure 60 .

Figure 60 Display of increased capacity for ppmefs_1 file system

The system has now expanded the usable capacity of the ppmefs_1

file system without disruption of service.


Summary The process of performing migrations with PowerPath MigrationEnabler is clean, straightforward, and, with the use of emcpowerdevices nondisruptive For larger scale jobs you can construct

8/8/2019 300-003-978_a01_elccnt_0

64/98


devices, nondisruptive. For larger-scale jobs, you can constructintelligent scripts that can set up, synchronize, and commit sessions,with testing performed along the way to verify success. And,throughout the migration process, the state of the data is continuallyprotected.

Tips and best practices


8/8/2019 300-003-978_a01_elccnt_0

65/98


The vast majority of issues involving successful use of the PowerPathMigration Enabler are those that concern the underlyingtechnologies, rather than the product itself. PowerPath MigrationEnabler is a simple tool; any complications reside in the underlyingtechnologies. This section focuses on a few issues that have beendiscovered as potential challenges, and attempts to aid in thedeployment of PowerPath Migration Enabler.

Open Replicator setup

The key to using PowerPath Migration Enabler in the OpenReplicator environment is proper establishment of the OpenReplicator infrastructure. Most of the issues uncovered during theinitial beta testing of the product involved the procedure for settingup the first migration. Once these problems were resolved, the

product functioned smoothly and effectively.The key to implementing Open Replicator successfully is theunderstanding of the access required between the storage arrayinitiators that will be performing the Open Replicator hot pull. EachSymmetrix Fibre Channel director (FA) port that can view a LUN thatis seen as the target of the migration within an array must be viewed by the source array as a host system. This is not intuitive to thenormal practice of SAN management, since ports on arrays are notthought of as host systems.


Figure 61 demonstrates the access necessary.

8/8/2019 300-003-978_a01_elccnt_0

66/98


Figure 61 Open Replicator SAN configuration

In Figure 61 , the host system can see the source LUN through bothHBAs. The target LUN is seen through both HBAs, but is presentedto the system through only two of the Symmetrix FA ports. Tocorrectly configure the SAN for Open Replicator performing a hotpull, all FA ports presenting the target LUN require access to the

CLARiiON SPs that are presenting the source device as if those FAswere host initiators accessing the CLARiiON LUN.

In a Symmetrix-to-Symmetrix environment, all FA ports presenting atarget device require access to all FA ports presenting the sourcedevice.

The final point of interest is that the host system has to see the sourceand target devices only down a single path; no extra consideration is

needed.

IVA-000016

SAN

SP A

SP B

SourceLUN

CLARiiON Symmetrix

TargetLUN

FA-1

FA-2

FA-3

FA-4

Source device (CLARiiON)c1t1d0s2 / c2t1d0s2 / emcpower2c

Target device (Symmetrix)c1t5d5s2 / c2t5d5s2 / emcpower12c

HBA 1 HBA 2


Solutions Enabler setup

8/8/2019 300-003-978_a01_elccnt_0

67/98


Correct installation of Open Replicator is critical for the success ofPowerPath Migration Enabler. The following is a refresher for thecomponents of the Solutions Enabler required for proper operation:

Note: PowerPath Migration Enabler requires Solutions Enabler Version 6.2.xor higher.

1. Download, uncompress, and untar the software onto the system.

2. Perform the installation. Figure 62 on page 68 through Figure 64on page 70 are from a typical installation.


8/8/2019 300-003-978_a01_elccnt_0

68/98


Figure 62 Installing Solutions Enabler: Screen 1


8/8/2019 300-003-978_a01_elccnt_0

69/98




8/8/2019 300-003-978_a01_elccnt_0

70/98



3. Once Solutions Enabler has been installed, it must be licensed.The licenses required for proper operation of Open Replicatorwith PowerPath Migration Enabler are Base, Symapi Server, andRcopyonlinePull. (Additional licenses should also be installed atthis time.)


Here are some sample commands to install the licenses:

=> symlmf XXXE-YYY0-ZZZC-CCCD

l f

8/8/2019 300-003-978_a01_elccnt_0

71/98


=> symlmf 3A33-6444-CDEF-01AB

=> symlmf A999-1666-F111-666A

=> more /var/symapi/config/symapi_license.dat

The sample license keys are:

XXXE-YYY0-ZZZC-CCCDSYMAPI Feature: BASE /

Symmetrix 3A33-6444-CDEF-01ABSYMAPI Feature: SERVER /

Symmetrix A999-1666-F111-666ASYMAPI Feature: RcopyOnlinePull /

Symmetrix4. Discover the arrays and populate the Solutions Enabler database:

=> symcfg discover

This completes the requirements for Solutions Enabler withPowerPath Migration Enabler.

Invista encapsulation SAN management

There are two major issues when performing Invista encapsulation

using PowerPath Migration Enabler. The first is to identify the sourceand target pairs of LUNs as viewed by the system from both the SANand the Invista instance. Invista encapsulation scenario on page 30 contains an example of the steps to complete this process.

The second issue involves successful execution of powermigcleanup , which is the final step of the encapsulation procedure. Tosuccessfully perform the cleanup of the migration, the host can nolonger physically see the LUN that is being acted upon.

The PowerPath Migration Enabler User's Guide recommendsdisconnecting the cable from the host system, to ensure that the hostcan no longer see the LUN nor access the data on it. Unfortunately,there are many valid reasons for maintaining the physical connectionto the SAN/storage array that had been used for access to themigrated LUN; particularly the probability that the host is still usingother LUNs that are not, and might not ever be, encapsulated.


Invista encapsulation scenario on page 30 contains an example ofhow to isolate a LUN after migration and perform the requiredpowermig cleanup .

8/8/2019 300-003-978_a01_elccnt_0

72/98


Performance results for various ThrottleValues for Open Replicator

PowerPath Migration Enabler contains a parameter calledThrottleValue that can be used to adjust the rate of data movementagainst the array resources used. (A setting of 0 is the fastest, butcreates the greatest demand for resources; 9 is the slowest, but

requires fewer resources.) The PowerPath Migration Enabler User'sGuide provides more detail on this parameter, as well as informationon using the Open Replicator command symrcopy set ceiling toadjust the global performance of Open Replicator migration. (TheOpen Replicator User's Guide provides more details about the OpenReplicator application.)

Note: If the Open Replicator parameter set ceiling is set, Open Replicator

disables the PowerPath Migration Enabler throttle command.

Using the default ThrottleValue setting of 5, the migration of the 8GB device used in this example on a system with a light load was 64minutes. The same migration with a throttle value of 0 wascompleted in only three minutes. In the testing done by EMC, theimpact to the application is negligible with the fastest speed setting;however, it is possible that with a large number of migrations beingperformed, or in a very I/O-intensive environment, some impactmay be noticed.

As a best practice recommendation, schedule migration for a time ofreduced I/O activity, and use the fastest possible setting. PowerPathMigration Enabler is nondisruptive while the data migration isoccurring, and migration could be performed safely during the busiest peaks of I/O activity. However, it is generally considered best

for overall performance of applications and migrations to wait for aslower I/O activity period.

The following table compares the times required on a host withminimal activity while an 8 GB migration was underway for each ofpossible ThrottleValue setting. The performance that can be achieved


in every environment will vary; these numbers are provided as anoverall guideline for expectations and, more importantly, as ademonstration of the large-scale differences between settings.

8/8/2019 300-003-978_a01_elccnt_0

73/98


Scripts

PowerPath Migration Enabler is designed to function on one pair ofdevices at a time. However, there may be times when many devicesmust be migrated at the same time. To aid in such a scenario, thiswhite paper contains some templates for scripts that were designedto aid in large-scale migrations.

Appendix: Scripts on page 77 contains a series of scripts that can beedited and tailored to assist in performing a migration usingPowerPath Migration Enabler.

Be aware that these scripts are not production code, and are providedonly to aid in understanding the process and to assist in the effectiveuse of PowerPath Migration Enabler.

Note: The final PowerPath Migration Enabler step of executing a cleanup ofthe committed pairs is not provided. This step can be added or performedmanually.

ThrottleValue Time to sourceSelected

0 3 minutes

1 8 minutes

2 12 minutes

3 15 minutes

4 38 minutes

5 1 hour 4 minutes

6 1 hour 39 minutes

7 2 hours 6 minutes

8 4 hours 4 minutes

9 12 hours 23 minutes


Identifying devicepairs

The key to any successful migration, regardless of the tool used toperform the task, is proper planning. Before performing a migration,the LUNs to be migrated must be identified, and the informationconcerning these devices should be viewable from both the host

8/8/2019 300-003-978_a01_elccnt_0

74/98


concerning these devices should be viewable from both the hostsystem and the arrays involved. The script VerifyPairsTSPairs.sh uses this information to verify the migration pairs of source andtarget devices on which PowerPath Migration Enabler will act.VerifyTSPairs.sh on page 77 contains the script.

Setting up a group ofpairs

If the migration to be performed involves only a small number ofLUNs, executing the series of commands manually is probablypreferable. If the task is of a larger scale, however, or if the migrationrequires automation, the script SetupPairs.sh can be used to set up aselected list of source/target migration pairs. SetupPairs.sh onpage 82 contains the script.

Synchronizing data Once the source/target migration pairs are established within thePowerPath Migration Enabler framework, the next step is to beginthe data transfer, while maintaining the consistency of theinformation between the devices involved. The script SyncPairs.sh can be used to initiate the data migration between the establishedsource/target pairs and report when complete. SyncPairs.sh onpage 87 contains the script.

Selecting targets andcommiting the

migration

The last template script is supplied to provide a method for finishingthe migration in an automated fashion. PowerPath Migration Enablerprovides the ability to switch continually between the source and

target devices for testing purposes, and maintains consistentmirrored copies of data on both devices (even through systemreboots). Once the powermig commit is executed, that consistency is broken, and the data on the source device will be, for all intents andpurposes, unusable. Use caution when automating the final step ofany migration. Also be aware that once the commit is performed, youcannot revert to the pre-migration configuration.

The scriptSelTargComPairs.sh

is built to perform aselectTarget

onall pairs currently in the selectSource state. A variable in the scriptcan be set to perform the commit for these pairs.SelTargComPairs.sh on page 93 contains the script.

8/8/2019 300-003-978_a01_elccnt_0

75/98

References

References

The following documents, available on EMC Powerlink, containdditi l i f ti N t th t ll b t th l t t it

8/8/2019 300-003-978_a01_elccnt_0

76/98


g , ,additional information. Note that all but the last two items areavailable in the Powerlink Documentation and White Papers Library : PowerPath Version 5.0 Product Guide PowerPath for Solaris Version 5.0 Installation and Administration

Guide PowerPath for Solaris Version 5.0 Migration Enabler Users Guide PowerPath for Solaris Version 5.0 Release Notes PowerPath for Solaris Version 5.0 Migration Enabler Release Notes Invista 1.0 Element Manager Administration Guide EMC Invista Deployment Scenarios (Powerlink EMC World

presentation) TS Kit: Open Replicator for Symmetrix Implementation Service

Send any comments or questions concerning this document [email protected].

Appendix: Scripts

Appendix: Scripts

This appendix contains four scripts that can be tailored to assist inperforming a migration using PowerPath Migration Enabler Be
http://powerlink.emc.com/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=image7b&internalId=0b01406680024e23&_irrt=truehttp://powerlink.emc.com/km/appmanager/km/secureDesktop?_nfpb=true&internalId=0b01406680024320http://powerlink.emc.com/km/appmanager/km/secureDesktop?_nfpb=true&internalId=0b01406680024320http://powerlink.emc.com/km/appmanager/km/secureDesktop?_nfpb=true&internalId=0b01406680024320http://powerlink.emc.com/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=image7b&internalId=0b01406680024e23&_irrt=true

8/8/2019 300-003-978_a01_elccnt_0

77/98


pp pperforming a migration using PowerPath Migration Enabler. Beaware that these scripts are not production code, and are providedonly to aid in understanding the process and to assist in the effectiveuse of PowerPath Migration Enabler.

VerifyTSPairs.sh#!/usr/bin/sh##---------------------------------------------------------------------## File Name: VerifyTSPairs.sh## Script Description: Script to supply detailed information# about the source/target devices selected# for a PowerPath Migration Enabler migration

##---------------------------------------------------------------------## Author Identification## SRT Steven R Thellen EMC##---------------------------------------------------------------------## Revision History## REV Who Date Comment# --- --- ---- -------# 000 SRT 13-JUL-2006 Initial Release##---------------------------------------------------------------------################################ Script-specific variables

DAT=`date +%y%m%d_%H%M%S`Sysn=`hostname`

############# OUTF -> location and name of output file

Appendix: Scripts

OUTF="PPmigVerf_${DAT}.out"

##############

f f

8/8/2019 300-003-978_a01_elccnt_0

78/98


# WATCHERS -> If using the 'send_email_alarm' function,# set this variable to contain list of recipients# Example:# WATCHERS="[email protected] [email protected]"

WATCHERS=""

## ENBmail -> Value 0 / 1# 0 = No emails will be sent using the send_email_alarm function# 1 = emails will be sent using the send_email_alarm function

ENBmail=0 ############# DISPLAY -> Value 0 / 1# 0 = No additional messages or information displayed# 1 = Additional information and OUTF file displayed#

DISPLAY=1############################################################# dlist -> Populate the variable below with pairs of# : separated by spaces# Example:# dlist="c4t0d16s2:c3t0d16s2 c4t0d17s2:c3t0d17s2"## If this program is supplied with an additional file name# on the command line, and populated with# :# in the format of one per line, then that will be the set# acted upon.# Example of file format:# c4t0d16s2:c3t0d16s2# c4t0d17s2:c3t0d17s2# emcpower2a:emcpower21a############################# Edit the Variable below if you wish to execute using the "dlist"

variable

dlist=""

# Test is file name was supplied

Appendix: Scripts

SupFile=$1if [ "${SupFile}X" = "X" ]then

# No file was supplied / Test is dlist is validif [ "${dlist}X" = "X" ]th

8/8/2019 300-003-978_a01_elccnt_0

79/98


then# Ok, no file and no dlist. We are exitingecho " "echo " "echo " Sorry, but either a file with"echo " the properly format info -or- "echo " The 'dlist' variable must be set"echo " Please try again with correct info"

echo " Thank You"echo " "echo " "

exit 1else

# Ok, we have something in the dlist variable# Lets attempt to proceed.

GO=3fi

else# Ok, let's test if file is validif test -f ${SupFile}then

# Ok, found path to file, do quick test and populate dlistQTest=`grep ":" ${SupFile} | wc -l`if test $QTest -ge 1then

# Passed quick test, attempt to populatedlist=`grep -v "#" ${SupFile}`GO=3else# No ":" found in SupFile, format can not be correct

echo " "echo " "echo " Sorry, but file is not in the"echo " proper format "echo " Please try again with correct info"echo " Thank You"echo " "echo " "

exit 1fi

else# Path to the SupFile is not valid

echo " "echo " "echo " Sorry, but file: ${SupFile}"echo " Not Found "echo " Please try again with correct info"

Appendix: Scripts


exit 1fi

fi

8/8/2019 300-003-978_a01_elccnt_0

80/98


fi #################################### --> Subroutines /dev/null 2>&1;;"HP-UX")

MAIL=/usr/bin/elmcat $SEA_FILE | $MAIL -s "$SEA_SUBJECT" $SEA_TO 1>/dev/null 2>&1;;esac

}##########################

Appendix: Scripts

# Main########

# Parse pair info as provided

8/8/2019 300-003-978_a01_elccnt_0

81/98


echo " " > $OUTFecho "Beginning run at `date` " >> $OUTF

for n in $dlistdo

src=`echo $n | sed s:s0:s2:g | awk -F: '{ print $1 }'`tgt=`echo $n | sed s:s0:s2:g | awk -F: '{ print $2 }'`

# Populate header infoecho " ############################################# " >> $OUTF

echo " " >> $OUTF

if test $DISPLAY -ge 1then

echo " src: $src " >> $OUTFecho " src: $src "

elseecho " src: $src " >> $OUTF

fi# Populate output file with $src device info

powermt display dev=${src} >> $OUTF

## .... proceed to target info for this pair

echo " " >> $OUTF

if test $DISPLAY -ge 1thenecho " tgt: $tgt " >> $OUTFecho " tgt: $tgt "

elseecho " tgt: $tgt " >> $OUTF

fi# Populate output file with $tgt device info

powermt display dev=${tgt} >> $OUTF

echo " " >> $OUTF# --> Repeat process till listed pairs completedone## Display output if selected#if test $DISPLAY -ge 1then

cat $OUTFfi

Appendix: Scripts

if test $ENBmail -ge 1then

send_email_alarm "VerifyPair information for ${Sysn}"fi

8/8/2019 300-003-978_a01_elccnt_0

82/98


SetupPairs.sh#!/usr/bin/sh##---------------------------------------------------------------------## File Name: SetupPairs.sh## Script Description: Script to establish PowerPath Migration# Enabler device pairs and report when complete##---------------------------------------------------------------------## Author Identification#

# SRT Steven R Thellen EMC##---------------------------------------------------------------------## Revision History## REV Who Date Comment# --- --- ---- -------# 000 SRT 13-JUL-2006 Initial Release##---------------------------------------------------------------------################################ Script-specific variables

DAT=`date +%y%m%d_%H%M%S`Sysn=`hostname`#

############ OUTF -> location and name of output file

OUTF="PPmigSetupinfo_${DAT}.out"############### TechType -> Select either OR for OpenReplicator or INVE for Invista# (default: OR)

TechType=OR

Appendix: Scripts

############### WATCHERS -> If using the 'send_email_alarm' function,# set this variable to contain list of recipients# Example:

8/8/2019 300-003-978_a01_elccnt_0

83/98


p# WATCHERS="[email protected] [email protected]"

WATCHERS="" ## ENBmail -> Value 0 / 1# 0 = No emails will be sent using the send_email_alarm

# function# 1 = emails will be sent using the send_email_alarm# function

ENBmail=0

############# DISPLAY -> Value 0 / 1# 0 = No additional messages or information displayed# 1 = Additional information and OUTF file displayed#

DISPLAY=0############################################################# dlist -> Populate the variable below with pairs of# : separated by spaces

# Example:# dlist="c4t0d16s2:c3t0d16s2 c4t0d17s2:c3t0d17s2"## If this program is supplied with an additional file name# on the command line, and populated with# :# in the format of one per line, then that will be the set# acted upon.# Example of file format:# c4t0d16s2:c3t0d16s2# c4t0d17s2:c3t0d17s2# emcpower2a:emcpower21a############################ Edit the Variable below if you wish to execute using# the "dlist" variable

dlist=""

# Test is file name was supplied

Appendix: Scripts

SupFile=$1if [ "${SupFile}X" = "X" ]then

# No file was supplied / Test is dlist is validif [ "${dlist}X" = "X" ]then

8/8/2019 300-003-978_a01_elccnt_0

84/98


# Ok, no file and no dlist. We are exitingecho " "echo " "echo " Sorry, but either a file with"echo " the properly format info -or- "echo " The 'dlist' variable must be set"echo " Please try again with correct info"


exit 1else

# Ok, we have something in the dlist variable# Lets attempt to proceed.

GO=3fi

else# Ok, let's test if file is validif test -f ${SupFile}then

# Ok, found path to file, do quick test and populate dlistQTest=`grep ":" ${SupFile} | wc -l`if test $QTest -ge 1then

# Passed quick test, attempt to populatedlist=`grep -v "#" ${SupFile}`

GO=3else# No ":" found in SupFile, format can not be correct

echo " "echo " "echo " Sorry, but file is not in the"echo " proper format "echo " Please try again with correct info"echo " Thank You"echo " "echo " "

exit 1fi

else# Path to the SupFile is not valid

echo " "echo " "echo " Sorry, but file: ${SupFile}"echo " Not Found "

echo " Please try again with correct info"

Appendix: Scripts


exit 1fi

fi

8/8/2019 300-003-978_a01_elccnt_0

85/98


#################################### --> Subroutines

8/8/2019 300-003-978_a01_elccnt_0

86/98


MAIL=/usr/ucb/mail$MAIL -s "$SEA_SUBJECT" $SEA_TO < $SEA_FILE 1>/dev/null 2>&1;;"HP-UX")

MAIL=/usr/bin/elmcat $SEA_FILE | $MAIL -s "$SEA_SUBJECT" $SEA_TO 1>/dev/null 2>&1;;

esac}########################### Main########

# Parse pair info as provided


for n in $dlistdo

src=`echo $n | sed s:s0:s2:g | awk -F: '{ print $1 }'`tgt=`echo $n | sed s:s0:s2:g | awk -F: '{ print $2 }'`

# Populate header infoecho " ###################################################### " >>$OUTFecho " " >> $OUTF


echo " src: $src " >> $OUTFecho " src: $src "

elseecho " src: $src " >> $OUTF

fi## .... proceed to target info for this pair


echo " tgt: $tgt " >> $OUTF

echo " tgt: $tgt "

Appendix: Scripts

elseecho " tgt: $tgt " >> $OUTF

fiecho " " >> $OUTF

## Now we setup the src/tgt pairs for execution

8/8/2019 300-003-978_a01_elccnt_0

87/98


# Now, we setup the src/tgt pairs for execution

powermig setup -tt ${TechType} -src ${src} -tgt ${tgt} -no 1>>${OUTF}2>&1

# --> Repeat process till listed pairs completedone

##################### Now place info in OUTF#

powermig info -query -all >> $OUTF##################### Lastly, verify that no errors were encountered#TERR=`grep -i err $OUTF | wc -l`if test $TERR -ge 1then


send_email_alarm "PPMigration Setup Error ${Sysn}"else

echo " "

echo " ---> PPMigration Setup Error ! ! !

8/8/2019 300-003-978_a01_elccnt_0

88/98


# Additionally, will provide control of the# powermig throttle_value to aid in management of# the Open Replicator resources and performance# of migration## Lastly, if desired, will report when all

# migrations are complete# Note:(additional configuration required)##---------------------------------------------------------------------## Author Identification## SRT Steven R Thellen EMC##---------------------------------------------------------------------## Revision History## REV Who Date Comment# --- --- ---- -------# 000 SRT 13-JUL-2006 Initial Release##---------------------------------------------------------------------#

############################### Script-specific variables

DAT=`date +%y%m%d_%H%M%S`Sysn=`hostname`############# OUTF -> location and name of output file

OUTF="PPmigSyncinfo_${DAT}.out"############### ThrottleValue -> Select value between 0 and 9# 0 = Fastest/Most resources consumed# 9 = Slowest/Least resources consumed# (default: 5)

Appendix: Scripts

ThrottleValue=0############### MonTillDone -> Value 0 -or- 1# This variable will enable the Monitoring till done# functionality. If set to '1', this script will

8/8/2019 300-003-978_a01_elccnt_0

89/98


y p# continue to execute and wait till ALL migrations# have completed before sending a report.## Set to '0' (default) and a report will be generated# immediately#

MonTillDone=0## RepInt -> This is the report interval in seconds to wait to check on# progress of migrations monitored

RepInt=180################ WATCHERS -> If using the 'send_email_alarm' function,# set this variable to contain list of recipients# Example:# WATCHERS="[email protected] [email protected]"#

WATCHERS=""#

# ENBmail -> Value 0 / 1# 0 = No emails will be sent using the send_email_alarm# function# 1 = emails will be sent using the send_email_alarm# function

ENBmail=0############# DISPLAY -> Value 0 / 1# 0 = No additional messages or information displayed# 1 = Additional information and OUTF file displayed#

DISPLAY=0############################################################

# --> Subroutines

8/8/2019 300-003-978_a01_elccnt_0

90/98


# INPUTS: none## OUTPUTS: :::#################################################################

InfoPPmig (){MigInfo=`powermig info -query -all |grep -v Source| grep -v "=" \| awk '{ print $1":"$2":"$3":"$NF }'|grep -v "::"`}######################################################### FUNCTION NAME: send_email_alarm# DESCRIPTION: send an alarm via email## INPUTS: 1 - Subject of email# 2 - who to send message to# 3 - log file to mail# OUTPUTS: None########################################################SEA_FILE=$OUTFSEA_TO=$WATCHER

send_email_alarm(){# Give passed arguments meaningful names#SEA_SUBJECT=$1#SEA_TO=$2#SEA_FILE=$3if [ "${SEA_FILE}" = "" ]; then

SEA_FILE=/dev/nullfi# Figure out which mailer to used based on the OS_TYPEcase ${OS_TYPE} in"Linux")

MAIL=/bin/mail;;"SunOS")

MAIL=/usr/ucb/mail$MAIL -s "$SEA_SUBJECT" $SEA_TO < $SEA_FILE 1>/dev/null 2>&1;;"HP-UX")

MAIL=/usr/bin/elm

Appendix: Scripts

cat $SEA_FILE | $MAIL -s "$SEA_SUBJECT" $SEA_TO 1>/dev/null 2>&1;;esac

#}#########################

8/8/2019 300-003-978_a01_elccnt_0

91/98


######################### Main######### Parse pair info as provided


## First, get the current list of setup jobs#

InfoPPmig

for n in $MigInfodo

# Check if handle is in 'setup' statestate=ècho $n | awk -F: '{ print $NF }'ìf [ "${state}X" = "setupX" ]then

# Get 'handle' and start sync with preset ThrottleValuehandle=ècho $n | awk -F: '{ print $1 }'`

powermig sync -hd ${handle} -noPrompt 1>>${OUTF} 2>&1

powermig throttle -hd ${handle} -tv ${ThrottleValue} -no 1>>${OUTF} 2>&1fi

# --> Repeat process till listed pairs completedone##################### Now place info in OUTF#

powermig info -query -all >> $OUTF##################### Lastly, verify that no errors were encountered#TERR=`grep -i err $OUTF | wc -lìf test $TERR -ge 1then

# Error(s) encounter alert - uncomment to send email alarm

Appendix: Scripts


send_email_alarm "PPMigration Setup Error"else

echo " "echo " ---> PPMigration Setup Error ! ! !

8/8/2019 300-003-978_a01_elccnt_0

92/98


fifi################## If MonTillDone enabled, commence loop

#if test $MonTillDone -ge 1then

WT=1until [ ${WT} -eq 0 ]do

Tsync=0

InfoPPmig

for n in $MigInfodo

Tstate=ècho $n | grep sync | wc -l`Tsync=ècho $Tsync $Tstate`

doneTst=ècho $Tsync | grep 1 | wc -lìf test $Tst -eq 0then

# No jobs currently in 'sync' state - send report

powermig info -query -all >> $OUTFecho " " >> $OUTFecho " Jobs completed: `date` " >> $OUTFecho " " >> $OUTF

WT=0else

# Someone still running, update log fileecho "##############################################" >> $OUTF

echo " Still executing at: `date` " >> $OUTFpowermig info -query -all >> $OUTF

echo "##############################################" >> $OUTF

sleep $RepIntfi

doneelse

# Send status nowif test $ENBmail -ge 1

then

Appendix: Scripts

send_email_alarm "Status of PPMig on ${Sysn}"else


cat $OUTFfi

fifi

8/8/2019 300-003-978_a01_elccnt_0

93/98


fi# End

SelTargComPairs.sh#!/usr/bin/sh##---------------------------------------------------------------------## File Name: SelTargComPairs.sh## Script Description: Script to will examine current state of PowerPath# Migration Enabler database and perform a# 'selectTarget' on ALL devices in the# 'sourceSelected' state.## In addition, if desired, a 'commit' will be# performed on ALL devices in the 'targetSelected'# state.## PLEASE USE EXTREME CAUTION!!!## Once a device pair has been commited, the data on

# the 'source' device will no longer be readily# available.## Lastly, if desired, will report when all migrations# are complete (additional configuration required)##---------------------------------------------------------------------## Author Identification## SRT Steven R Thellen EMC##---------------------------------------------------------------------## Revision History## REV Who Date Comment# --- --- ---- -------# 000 SRT 13-JUL-2006 Initial Release

#

Appendix: Scripts

#----------------------------------------------------------------

300-003-978_a01_elccnt_0

Documents