This article can also be found in the Premium Editorial Download "Storage magazine: Five companies on their storage virtualization projects."
Download it now to read this article plus other related content.
Controlling the migration process
During data migrations, it's important to control the rate at which data is moved and to be able to fail back to the source disks if there's an issue with the migration. Products should monitor data throughput and, through the use of preset policies, dynamically increase throughput during periods of low application activity and throttle back data flow during periods of peak application performance. The ability and speed at which users can fall back to the source disk is important if the target volume doesn't perform or isn't configured as anticipated.
|Host-level, block-based data migration|
|Click here for a comprehensive list of host-level, block-based data migration options (PDF).|
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.
This was first published in August 2006