This article can also be found in the Premium Editorial Download "Storage magazine: Salaries rise, but storage jobs get tougher."
Download it now to read this article plus other related content.
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, says GlassHouse Technologies' Nadkarni. "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 says.
The easiest way to avoid security issues is to do a block-level rather than a file-level migration. That way, the migration is performed at "a level below the file system, so the host doesn't even see the difference" in the data, says Nadkarni.
It's possible to maintain security settings in a file-based migration, he notes, if the source and target systems lie within the same authentication or authorization domain in a service such as Microsoft's Active Directory. Some file-based migration tools also have the intelligence required to maintain such security settings, he notes.
Digging into the details of how a file copy utility
| works is important, says StorageIO's Schulz. "What does it copy? How does it copy? Does it simply copy the file, or copy the file as well as all other attributes, meta data and associated information? Those could be the real gotchas if you haven't brought along all of the extra permissions and access information. Dig into the documentation, talk to the vendor or service provider, and understand what type of data is being moved, and how it is to be moved."
host-based storage virtualization, which is available from a number of vendors, is a fairly reliable way to accomplish such cross-vendor migration. Future Electronics' Falsafi says the host-based virtualization provided by the FalconStor software made the actual migration painless. "We zoned the XP with a Fibre Channel switch so [it] came up as another set of hard disks to the IPStor. We created a mirrored LUN on the HP StorageWorks XP24000 array and did synchronization. Once the primary array and the backup LUNs were synchronized ... all we did was flip the switch from the primary to the backup, and the backup became the primary," he says.
But 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, says Nadkarni. For example, he says, 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 used to manage the storage must be reconfigured to recognize the new string, he says, or applications that depend on that volume may not run properly. Storage admins should ask virtualization vendors whether their products are "completely transparent," says Nadkarni, 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 says. They can also require the administrator "to change things on the host" such as drivers, multipathing software or volume managers.
This was first published in November 2008