Data migration tool purchase considerations
- Posted:
- 00:00 29 Jun 2007
ADVERTISEMENT
Determine how the data migration tool behaves. Data migration tools can differ radically in their operation. For example, some tools will copy data from the source to the destination and then mirror writes to both locations until a final "cutover" occurs. This type of behavior may be preferable if the migration will take place in phases or is intended to support the addition of a new or upgraded storage system. Other tools will simply move the data to the target and then delete that data from the source. This accomplishes data migration without using additional storage, but makes it more difficult to "undo" the migration if problems arise. Lab testing can help to identify any idiosyncrasies before the purchase.
Consider how migration impacts storage performance. Data migration will invariably have an impact on the performance of your storage subsystems or storage fabric. This, in turn, may have an unwanted influence on storage service levels or application availability. When considering a migration tool, make the effort to measure storage performance with and without the migration process running. Performance degradation will probably appear worse when moving a substantial amount of data (e.g., bringing a new or upgraded storage system online). Data that is migrated on an ongoing basis, such as daily or weekly moves, typically has a smaller overall impact. Consider where data migration will be handled. Data migration tools can be host-based, network-based or storage-based. Host-based data migration tools typically run on a dedicated server. Experts note that host-based data migration tools are typically storage agnostic and can migrate data in the background. This allows for a greater range of storage system choices in the future. Network-based data migration is generally a feature of intelligent switches, making migration a function of the storage fabric itself. This is often a more powerful approach, but potentially limits interoperability between switches and storage systems. Storage-based data migration occurs within the storage subsystem itself, such as a Hitachi Data Systems' (HDS) TagmaStore. Storage-based data migration is generally the most subtle but least interoperable approach. Evaluate file- and block-level tools. Data migration tools can operate at the file and block levels. Experts suggest the use of block-level data migration tools, but file-level data migration tools should not be ignored, especially in situations where storage is over allocated to servers. For example, a Windows server may use 300 GB of a 500 GB volume, but a block-level data migration tool sees the 500 GB volume and can only move files to another volume of equal or larger size. This can perpetuate inefficient storage provisioning. By comparison, a file-level data migration tool can move the 300 GB of files to a volume of that size or larger. Weigh the automation features. Data migration can often be performed manually, but it is not intended to be a manual process, especially if data must be moved on an ongoing basis. Automation is particularly important to keep labor/administration costs to a minimum. When considering a data migration tool, be sure to examine the automation features closely. For example, Brocade's Data Migration Manager (DMM) can automatically create migration pairs, implement automatic zoning and can use a scheduler feature to perform tasks at preset times. CA's File System Manager includes a policy simulation feature that allows administrators to understand the effectiveness of policies before actually moving data. Incipient's Network Storage Platform (NSP) provides automated provisioning. The data migration product specifications page in this chapter covers the following products:
