In this last part of Jerome Wendt's "The best way to move data" article, he looks at array and network data migrations. He also offers his data movement recommendations.
Array migrations
For users who want to avoid the pain of installing and configuring software on each server and whose arrays are all from a single vendor, look no further than the utilities natively offered by array vendors. EMC, Hewlett-Packard Co. (HP), Hitachi Data Systems Inc. (HDS) and IBM Corp. enable data migrations between their arrays with minimal intervention on the hosts. These products enable the movement of data between like-arrays while applications are running, regardless of the OS accessing the storage. Yet none of these array-based operations should be confused with point-and-click operations.
Administrators still must do the upfront work. For instance, prior to using EMC's SRDF, administrators must complete a number of tasks, such as verifying that the microcode levels in each array are the same. The SRDF software must be purchased and licensed for both the existing and the new array. The LUN sizes on the new array must be configured to exactly match that of the existing array. Also, as a rule of thumb, almost every array-based approach requires that the source and destination array must be from the same vendor and of the same product line.
But there are a growing number of exceptions to this rule. For instance, data migrations may be done between different generations of EMC Symmetrix arrays as long as each generation's microcode is the same. A migration may also be done from an EMC Symmetrix to an EMC Clariion using Clariion's SAN Copy utility. The SAN Copy utility also enables Clariion arrays to pull or push data to or from any vendor's array. HDS is unique among storage vendors in that it offers the ability to migrate data between its Lightning and Thunder models because they both ship with the same family of code, even though the array models differ.
Monitoring and managing the progress of the migration requires the use of a console provided by each array's vendor. For example, an EMC Symmetrix requires use of its ControlCenter product; for EMC's Clariion arrays, its Navisphere Management Suite must be used. Similarly, on HP arrays, the OpenView Storage Operations Manager is used to manage and monitor the progress of its Continuous Access Data Migration software.
EMC's SAN Copy and HP's Continuous Access reflect an emerging trend toward heterogeneous array support. Even though the software runs on a specific vendor's array, it reflects an increasing willingness by traditional hardware companies to migrate data to and from other vendor's arrays.
Network migrations
Despite the maturity and success of host- and array-based solutions, setting them up is time-consuming. So some companies are experimenting with network-based solutions to simplify and expedite the migration process. Using a network-based appliance requires the same amount of effort as using either an array- or host-based approach. But once the network appliance is firmly entrenched, the pain of future data migrations is eased considerably.
In reality, most users aren't ready to abandon their current storage infrastructure design and move to a network-based solution until standards are firmly established and widely adopted. Also, because virtualization products are relatively new, many companies are hesitant to get locked into a single vendor's solution.
Setting up a server to become a migration appliance is a multistep process. For instance, to use FalconStor's IPStor, the storage administrator needs to designate the hardware to host it. This is usually a general-purpose, off-the-shelf server that supports Linux. Next, a user needs to install and configure the FalconStor software on the server, which is now a migration appliance. Once complete, the appliance needs to be configured to see the existing and new arrays, and then must be enabled to perform the migration. Once the migration is done, the servers and storage infrastructure need to be reconfigured to permit the servers to see the storage on the new arrays. Only after all of the servers can access the new storage can the migration appliance be pulled out. It's a long, tedious process, but it only has to be done once.
Recommendations
Users in homogeneous storage environments should continue to use the utilities provided by their vendors. Users in heterogeneous environments would be well-advised to continue to rely upon host-based methods and give preference to those solutions that offer a central interface to manage the data migrations. In the longer term, all users should be watching and testing the maturity of network-based solutions because these solutions will transform how future migrations will be done. Network migration solutions will decrease a user's dependence upon any single vendor's storage products and will simplify migration management.
For more information
The best way to move data, part one
Pros, cons of host-based technology for data migration
This article first appeared in Storage magazine
About the author:
Jerome Wendt is an independent writer specializing in the field of open systems storage and storage area networks. He has managed storage for small and large organizations in this capacity.
