Service IT Direct and COVID-19 UPDATE for more information CLICK HERE

Call NOW:

Easy storage migration in HP-UX

Large storage migration is a fact in data centers today. Older technology is slow, occupies valuable rack space, has unexpected failures and is costly to maintain. So the new storage is rolled in and you’re expected to ‘copy’ the data in a few minutes and seamlessly run on the new storage.

While data copy tools such as rsync can push data to the new storage at high speed, it can’t ensure that the original data has not changed during the copy period. Running rsync repeatedly can reduce the amount of un-synced data but only by quiescing the applications and databases can the last rsync run produce an exact copy.

But rsync is a file oriented utility. Raw databases with no files (Sybase, Informix, even Oracle) require more complex procedures. And unlike rsync, there is no off the shelf method to skip sectors that are already synced. So outages will be extended as large amounts of data (terabytes and petabytes) are copied.

What is needed is a background sync method that can maintain changes at the destination while running the bulk copy process. While there are hardware-based solutions to perform data sync between disk arrays, most of these are limited to a single manufacturer, or require a separate appliance that can connect to differing storage platforms. In most cases, these tools are extra cost and require some setup and testing.

Fortunately, HP-UX has a migration tool built into LVM. It is called MirrorDisk/UX, an optional extension used for error protection. By presenting the new storage to the host system, the new disk LUNs can be extended into the volume groups, and the logical volumes synced with lvextend. This synced relationship takes place in the background and accommodates random changes in real time.

The first step in mirroring for storage migration is to make sure the volume group will not limit the needed additional disk LUNs that must be added from the new storage. The parameter is MAX_PV and can be seen with vgdisplay. Starting with version 11.23, the vgmodify command can be used to increase this value. The second step is to make sure that MAX_LV is large enough to accommodate the new lvols on the new storage.

Once the needed LUNs have been added to the volume group, the next step to add the mirror flag to all the logical volumes. The good news is that the lvols do not have to contain a filesystem. MirrorDisk/UX works at the LVM level and is unaffected by filesystems or raw data patterns.

The usual next step is to run lvextend for each lvol in the volume group. Each lvextend -m 1 will start the sync process on the lvol and not return until the the sync is complete. For terabyte sized lvols, this can take a very long time. However, there is a feature in lvextend that can defer the sync step so that each lvextend -m 1 completes immediately. This is the -s option which drops the sync step when using -m as in: lvextend -s -m 1

Now that all the lvols are marked for mirroring, the actual mirroring step can be performed in a multi-threaded operation using lvsync -T and specifying multiple lvols on the same line. The lvols are specified on the command line. Note that synchronizing multiple lvols can place a large load on the paths to storage and may affect database and application performance. If storage is switch-connected, using the switch stats can provide insight as to the maximum load.

Once the lvols are synced, the original and new storage will remain in sync. AL that is needed now is to remove the old storage mirror. Use lvreduce -m 0 <lvol_name> <pv_name> [<more pvs>]. This is an important step to use the right physical volumes (LUN or disk paths). When reducing the old storage mirror, all the LUNs/disks for a given lvol must be specified. Note that some larger lvols may use more than one physical volume. Specify all the pv’s that are used for each lvol. Once all the old storage has been unmirrored, use vgreduce and pvremove to remove the old storage. vgreduce all of the pv’s and then pvremove to eliminate any LVM header information from the old pv’s.

Note that this migration procedure is done completely online. No applications or databases need to be stopped during the procedure.