This article can also be found in the Premium Editorial Download "Storage magazine: How HP is reloading its storage strategy."
Download it now to read this article plus other related content.
The process of changing storage platforms is known as a forklift upgrade because everything associated with the old storage platform has to be physically moved to the new platform. Data, connections and authorizations must travel to the new environment; servers, applications and databases also need to be redirected to the new storage devices. The procedure takes a great deal of time and Murphy's Law usually rears its ugly head: Whatever could possibly go wrong more often than not does.
The prospect of a forklift upgrade--switching from one vendor to another--discourages companies from changing storage platforms. Many storage administrators would rather push their existing storage to the max, even past the point where it becomes obvious that a change is needed, just to avoid changing vendors.
Sometimes, there's no choice. "We had gotten to the point where we simply outgrew our small EMC storage area network. We couldn't expand it any further," says Mark Rivard, network systems specialist at Johnson Health Network, which is located at Johnson Memorial Hospital, Stafford Springs, CT. A pressing need to expand its storage, combined with frustration over the cost and complexity of maintaining a Fibre Channel (FC) SAN, drove Rivard's organization to undertake a forklift upgrade to an iSCSI SAN from EqualLogic Corp.
Since vendors began focusing on scalability upgrades, much of the pain associated with an upgrade to a bigger box within the same vendor's product
Despite the challenges involved, organizations are forced to change storage platforms all the time. Storage spoke with several storage managers who've recently gone through a major storage platform change and had them identify critical "gotchas" and best practices for moving from one vendor's offering to another's.
Moving data to the new platform is just one of the challenges involved in changing platforms. "You can always use backup software to back up the data and restore it on the new array, but it's kind of a brute force solution," says Steve Jeffreys, engagement partner at GlassHouse Technologies Inc., Framingham, MA.
Jeffreys recently moved a client's storage from an IBM Corp. Shark to an EMC Corp. DMX. He used a combination of backup and restore, reconfigured Shark host bus adapters (HBAs) for the DMX and mirroring. Other challenges users will confront when changing platforms include preserving the meta data associated with the data, he says. There are also the tasks of mapping volume sizes from one platform to another, redirecting apps and databases to the new storage, configuring mirrors, RAID levels and other technical details.
Security is often overlooked, and proved to be a key issue for Johnson Health Network. "We have thousands of network shares with varying levels of security," says Rivard. The hospital turned to EMC's FullTime RepliStor (formerly Legato RepliStor) to copy all of the permissions to the new storage environment while maintaining synchronization with the old one. "It allowed me to change the location of various folders and data while maintaining security," he notes.
EMC Symmetrix to Hitachi Data Systems Thunder
The move from EMC to Hitachi Data Systems (HDS) Inc.'s storage could have been much more difficult for Drummond Co. Inc., a Birmingham, AL-based energy and coal-mining company, but it used EMC with only one application--a big, critical PeopleSoft system running on a Sybase database. To ease the transition, Drummond scheduled the change to coincide with the end of its Symmetrix lease. This gave it 60 days to experiment with the new platform before putting it into production.
"We started with a free, 30-day, onsite trial," says Kirk Pierce, Drummond's technical support manager. During the trial, the team pushed the Thunder array to find its performance limitations. It passed the performance tests and gave Pierce's team the experience it needed. Drummond then negotiated to buy the system, which gave them another 30 days to work with the storage while the negotiations and paperwork proceeded.
The key to Drummond's migration was a three-step process to prepare the new storage for production that began the moment the deal was finalized. "The first step was defining and allocating the RAID groups," says Pierce. Earlier testing had revealed that the firm wanted RAID 5 for the PeopleSoft database, using six drives for data with another drive storing parity information. HDS engineers worked onsite and set up the RAID configuration using HDS tools.
"The second step was building the actual LUNs [logical unit numbers]," Pierce says. HDS engineers worked with his team to show them how to do this. Since then, Pierce's team has added LUNs on its own.
The third step was creating the FC SAN using two Brocade switches. Previously, the company's EMC storage had been direct-attached. Again, HDS engineers helped Pierce's team to set up the initial zones; they have since added zones without outside assistance.
With the preliminaries out of the way, Drummond planned to shut down transaction activity for a weekend and move to the new storage platform. To move the bulk of the data, the team let the Sybase database do the heavy lifting. "Our DBA mapped it all out to make sure the right data would go to the right place," says Pierce. Then, using Sybase's own database dump and restore utilities, the DBA sent the PeopleSoft-Sybase data to the HDS platform using the FTP protocol.
To set up multipathing through its two Brocade switches, Drummond used Hitachi's Dynamic Link Manager (HDLM), which provides high-availability failover and limited load balancing. Using HDLM, the storage team defined the primary storage paths for each switch. From there, HDLM took over.
This was first published in July 2005