These products are used to complete the block-level movement of all data from one locally attached storage device to another, or from one server to a remote server. But don't expect them to totally eliminate the need for the application outages or server reboots that data migrations typically require. Differences in how they're installed and configured, and how they move data to the target volume, fall back to the source volume in the event of problems, and manage data flow and integrity during the migration are all factors to consider.
Softek recently conducted a data migration survey of 700 users and found that the most frequent reasons for data migrations were to replace storage or server equipment (38%), storage and server consolidations (17%) and the relocation of data (10%). The study also revealed that 39% of these users perform migrations on a weekly or monthly basis. To accomplish these types of data migrations with few or no application outages and minimal administrative intervention, block-based data migration tools support the following features to varying degrees:
On Unix operating systems, these three products don't require server reboots because they don't make modifications to the Unix kernel. These products take advantage of the better support Unix kernels provide for dynamically loaded drivers. For instance, on HP-UX systems, they use the modload command that's part of HP-UX's Dynamically Loadable Kernel Module (DLKM) to install their drivers without requiring a server reboot.
At a block level, Symantec's VolumeManager offers two choices to migrate data: volume mirrors and volume evacuations. First, users may establish a mirror between the source and target volumes. Once the mirror to the target volume is complete, users can break the mirror and allow the target volume to become the primary target for the application.
Users need to account for a few factors when using VolumeManager. First, the write is duplicated at the host bus adapter (HBA) level, so the writes are sent directly from the HBA to the storage targets to eliminate CPU consumption. However, if mirroring over Fibre Channel distances of more than 80 km, the application will need to wait for a write confirmation from both the source and target volumes before processing the next I/O. Second, if users need to fail back to the original volume once the mirror is broken, there could be a significant delay while VolumeManager syncs up the blocks on the source and target volumes.
Turning on VolumeManager's optional Dirty Region Log (DRL) feature allows users to more quickly recover back to the original state of the mirrored volumes after a mirror is broken. The DRL keeps track of blocks that have changed since the mirror was broken and is used by VolumeManager to recover only the blocks of the volume that require recovery if it's necessary to fail back to the original volume.
An alternative method VolumeManager provides allows users to evacuate specific volumes. Users can either manually select which source volume they want to migrate to the target volume or set up VolumeManager to automate the process. When this occurs, all of the data is moved from the source volume to the target volume so that when the migration is complete, no data remains on the source volume.
Obviously, manually selecting which volumes to migrate can be resource and time intensive, but it allows users to selectively migrate volumes when they're not being used by the application. Users may also automate this process with policies provided by Symantec, but volumes may be migrated when they're experiencing a heavy application load, affecting the application's ability to function. Employing this approach also makes it difficult to fail back to the source volume since all data, as opposed to individual volumes, must be migrated back to the source volume.
Softek's TDMF uses a different approach to migrate data between local storage volumes. Prior to copying a block, it places a lock on the block on the source volume, copies that block to the target volume and then releases the block. By default, copies occur every 1/100th of a second in 256KB blocks. However, Sof-tek engineers recommend increasing the block size to 4MB or 8MB and executing the migration during periods of application inactivity to complete the migration more quickly. Once the blocks are migrated, any updates to the migrated blocks are synchronously written to both the source and target volumes.
Once the migration is complete and the volumes are synchronized, TDMF provides Unix users with a command-line option to redirect the application I/O from the source volume to the target volume, or back again if there are problems. Completed without quiescing the application, the switchover command elevates the target volume to the position of primary volume, while in the background TDMF mirrors write I/Os to the old source volume. This allows users to fall back to the original configuration using the same switchover command, provides a period of time to test the new target volume with the application, and lets users choose the exact time to terminate the copies to the source volume.
Topio's TDPS also starts by copying all the data from the source volume to the target volume, although it performs a few tasks differently. First, it copies the blocks in average sizes of about 10KB. Then, instead of synchronously copying writes to both source and target volumes, it makes a copy of the write I/Os and puts them in a buffer. Finally, in the instances where a write is occurring to a block at the same time it's being copied, TDPS suspends the copy, allows the update to complete and then copies the updated block to the target volume.
Because TDPS uses copies of the write I/Os instead of write mirroring, it's necessary to quiesce the application to switch from the source to the target volume. TDPS' "freeze" feature quiesces the application, verifies that all writes have been written to the source volumes, copies the final write I/Os to the target volume and then verifies that both volumes are in sync. Once this is complete, the application can be safely repointed to the target volume.
While quiescing the application temporarily disrupts the migration, it provides a checkpoint to test the data on the target volume. By first verifying the integrity of the data on the target volume and how well it performs using another instance of the application, users can achieve some level of confidence before switching over the production application to the target volume. However, this testing requires users to resync the data on the source and target volumes before actually cutting over the production server to the new volume.
Server-to-remote server data migrations
Migrating data at a block level from the source server to a remote target server introduces a different set of issues:
- Creating the initial copy of the data on the target server
- Synching the data once the initial copy is in place
- Going forward to the target server
- Falling back to the source server
- Shutting down the application to switch between servers
How the initial copy of the data is created on the target server depends on three variables: distance, bandwidth and the amount of data. When the target server is close, there's a minimal amount of data to move and ample network bandwidth between the source and target servers; creating and synchronizing the data between the source and target servers is no big deal. However, it becomes an issue when you need to migrate a large amount of data over a limited bandwidth network connection; each product offers a way to accomplish this objective.