|
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.
|
 |
|
