PowerPath/Migration Enabler

Introduction:
Performing data migrations is something every systems and storage administrator has had to deal with at some juncture in his/her career. Many migration techniques require downtime for the application. Block-level techniques like SAN Copy (CLARiiON/VNX) or Open Replicator (Symmetrix) require bringing the application down in order to perform the cutover. There are other techniques that do not require downtime. Some examples of this are host-based volume manager or filter driver techniques – Veritas Volume Manager (VxVM), PowerPath/Migration Enabler (PP/ME), or something like Federated Live Migration between two Symmetrix arrays (uses both PowerPath and Open Replicator).

In this blog, I’ll cover some basics and gotchas for PP/ME.

PowerPath Migration Enabler takes advantage of the multi-pathing capabilities within PowerPath. PowerPath functions as a filter driver within the I/O stack on a server. When an application writes down to a volume, it will take the following path down to storage:

• File system (Windows drive letter or Unix/Linux mounted file system) or Database raw partition
• Logical volume manager
• PowerPath (pseudo devices)
• SCSI driver (native devices)
• SCSI controller or HBA
• Storage controller via SAN or direct connection

For a Symmetrix volume, you will typically have two paths for a single device. The server will then have a native device for each of those two paths. From a server perspective, it looks like two different physical devices, but we know that they represent the same device. PowerPath then creates a pseudo device that then encapsulates those native devices as a single device. Note: on a Unix/Linux server you could technically still address a native device, but PowerPath will still intercept the I/O and intelligently load balance as is appropriate.

Why the explanation on PowerPath native and pseudo devices? It’s because PP/ME takes advantage of its position in the I/O stack to copy data to new devices in the background, by copying/mirroring data from one native device to a new native device (similar to VxVM plex mirroring). That activity is transparent to the file system above it. This is why you can perform a migration/cutover to a new storage array while keeping the application online.

The rest of the blog will focus on specifics within a Windows environment, but the same concepts can be applied to Unix/Linux servers.

Pre-requisites:
Below are some of the requirements prior to migrating with PP/ME.

• PowerPath 5.3.1 at minimum must be installed.
  • If you already have this version or later but did a typical install, you likely won’t have PP/ME installed.
  • To get PP/ME installed, just run the installer again, choose the custom installation option and then select the PP/ME option.
  • In the case where you already had PowerPath installed and are just getting the PP/ME feature added, a reboot is not required but it is recommended. I’ve seen some weird issues with the service without that reboot.
• You will also require the HostCopy license for PP/ME. It can be obtained for free from EMC, assuming you already have the base PowerPath license and a current maintenance contract.
• Once all of these are complete, you can verify that you have it by running the powermig command in Command Prompt.

Setting up the Source/Target Mapping:
Next you need to know what the source and destination LUNs should be. The main way would be via the PowerPath Console. In the illustration below, I’ve moved the columns to make it easier to see. You’ll also note that the 3rd device is failed. That was an old CX4 LUN that was reclaimed but not yet cleaned up, which enabled me to at least get a view of both Symmetrix and CLARiiON LUNs in PowerPath.

Disk Number – will correlate to the physical drive in Windows disk management
Device – for Symmetrix devices, it will give you the symdev and for CLARiiON/VNX devices, it will give you the UID.
LUN Name – for Symmetrix devices, it will give you nothing and for CLARiiON/VNX devices, it will give you the name of the LUN. If you have the ALU in the name, then it becomes easy to map.

Host Resources and Throttling:
During the synchronization process, host resources will be used to perform the copy. Depending on what is going on with the server, you may want to throttle the host resources that PP/ME is allowed to use. Below are some of the settings that you can use. The percentage represents the percentage of time the host spends copying data.

• 0: 100%
• 1: 60%
• 2: 36% (default)
• 3: 22%
• 4: 13%
• 5: 7.8%
• 6: 4.7%
• 7: 2.8%
• 8: 1.7%
• 9: 1.0%

Migration Process:
And now the process. As stated earlier, the migration process does not require bringing the application down. While the migration should still be done in a maintenance window with appropriate notice to the user/business community, the application will take no downtime.

• Present the new target storage
• Setup the PP/ME sessions using the mapping technique above
• Perform initial synchronization prior to the migrations with the appropriate throttle settings
• During a maintenance window:
  • Switch targets to the new storage and commit the changes
  • Remove the old storage
  • Perform UAT

Below are commands required for setting up, executing and cleaning up PP/ME.

# create a session, will return a handle #
powermig setup -src harddiskXX -tgt harddiskYY -techType hostcopy

# start the background copy, will enter sourceSelected state when complete
powermig sync -handle 1

# monitor status of the session
powermig query -handle 1

# set the throttle per the settings stated above
powermig throttle -throttleValue 0 -handle 1

# switch over to the new storage, still mirrors back to the original
# will enter targetSelected state
powermig selectTarget -handle 1

# stop mirroring to the original, will enter committed state
powermig commit -handle 1

# cleanup/delete the session
powermig cleanup -handle 1

Gotchas:
Below are some gotchas that I’ve seen in my experience with PP/ME:

• For Windows servers, you need to make sure that the syntax of the source and target devices are “harddiskXX” where XX maps to the PHYSICALDRIVE number, found in PowerPath or Disk Management. The symdev, LUN name, LUN ID, or LUN UID will not work.
• The synchronization time is largely dependent on host resources and the underlying storage. You could set throttle to 0 (allowing 100% host resources), but if there is a lot going on the box, PP/ME will be competing with other activity to perform the background copies. Hence, you need to find appropriate times to perform the initial synchronization.
• PP/ME is supported with MSCS clusters. However, it is critical that no resource failovers happen at any point during a PP/ME session. Why? Because once the new LUN is mirrored, it not only has the same data on it, it also has the same disk signature. In the event of a cluster failover, the secondary node will not know about the PP/ME source/target relationship. Therefore, the cluster node will think that the server has two different LUNs with the same disk signature. Because the target LUN is write-disabled (locked by PP/ME on the other node), Windows will then re-signature the source LUN. With a new signature on the source LUN, the cluster will no longer recognize that LUN in the cluster, and therefore the cluster will fail to come back online. You will need to use tools like diskmap and dumpcfg to manually resignature the source LUN back to the original disk signature.