Data migration can be a complicated process. It involves a lot more than just ripping out one data storage cabinet and plugging in another. In order to properly move your
1. Understand your mapping
Before migrating any data to new storage arrays, be sure you understand how your servers are currently mapped to storage so you can re-create those mappings in the new environment. Otherwise, servers may not reboot correctly after the migration.
2. Gather metrics
Measuring network bandwidth needs before performing data migration is a chore that can be easily overlooked, said Greg Schulz, founder and senior analyst at StorageIO Group, Stillwater, MN. "Unless you know for sure, go out and doublecheck to see what the impact is going to be," he said. Once an administrator is sure how much bandwidth should be allocated to the migration and when it will be available, the bandwidth can be managed with tools such as optimization technologies, replication optimizers and traffic shapers, he added.
3. Utilize downtime
Some vendors claim they can migrate data without causing any downtime for applications. But some observers, such as Gary Fox, director of national services, data center and storage solutions at Dimension Data, recommend building in some downtime. It can be tricky to migrate data and ensure its consistency while doing a data migration during regular production hours. Fox recommends performing data migrations during non-business hours "so you're not under so much pressure" in case something goes wrong.
4. Watch for security leaks
When migrating data among arrays from various vendors, permissions and security settings can be left behind, making the data vulnerable to theft, corruption or misuse. Even moving data among file systems--say, from NTFS to NFS--can result in a loss of permission and security settings, said Ashish Nadkarni, principal consultant with GlassHouse Technologies Inc. "If you're moving ... from Windows to Unix or Unix to Windows, you have to be very, very cautious because more often than not the user permissions are completely destroyed," he said.
5. Virtualize carefully
Host-based storage virtualization, which is available from a number of vendors, is a fairly reliable way to accomplish cross-vendor migrations. But remember that not all virtualization is created alike. Some virtualization appliances can add to the work administrators have to do, or cause application outages while administrators update drivers or the volume managers used to manage the storage, said Nadkarni. For example, he said, a virtualization appliance can cause problems by changing the SCSI Inquiry String used to identify a specific array. If the appliance changes the inquiry string, the volume manager that is used to manage the storage must be reconfigured to recognize the new string, or applications that depend on that volume may not run properly. Nadkarni also said that storage administrators should ask virtualization vendors whether their products are "completely transparent," or whether their installation will require changes to servers or other components that could cause application outages.
Nadkarni also suggests staying away from virtualization appliances that require an array or entire storage network to be taken out of service to virtualize (or unvirtualize) storage resources. Some appliances "may require you to take an outage to reconfigure your network or to take an outage on the entire storage array, to insert the appliance," he said. They can also require the administrator "to change things on the host" such as drivers, multipathing software or volume managers.
6. Consider thin provisioning
Thin provisioning helps preserve storage space by only taking up space on a disk when data is actually written to it, not when the volume is first set aside for use by an application or user. This eliminates waste when the application or user doesn't wind up needing the disk space. However, many data migration tools write "from block zero through to the very last block" of a volume on the target system regardless of which blocks are actually being used, nullifying the benefits of the thin provisioning a user had applied on the source array, said Sean Derrington, director of storage management and high availability at Symantec Corp.
File-system utilities or host-based volume managers "that are intelligent enough to figure out if the block is being accessed or not" before deciding to write to it can help circumvent this problem, said Nadkarni. Block-level migration techniques that are good for preserving the security around data aren't good for preserving thin provisioning, he said, "because they write to the entire volume."
7. Pay attention to software details
Something as simple as different patch levels applied to software in the old and new environments can cause server crashes after a data migration. Nadkarni said migrating data among storage arrays also requires uninstalling the previous vendor's software from servers and installing the new vendor's. Not only does this require time, but it could cause instability if components left behind by the incomplete uninstall of older software conflict with other applications.
8. Build in enough learning time
If there's a common theme to these tips, it's that data storage migration is complex and full of risks that can compromise application uptime, reliability or security. "The key to a successful data migration is not having any unknowns in your environment," said Nadkarni. "The more unknowns," he adds, "the bigger the risk." Storage administrators often underestimate the time required to learn their new storage environment and what it takes to migrate data to it successfully.
This article originally appeared in Storage magazine.
About this author: Robert L. Scheier is a frequent contributor to "Storage" magazine.
This was first published in October 2009