Will You Avoid The SAN Traps?

Admit it. Your disk utilization stinks. Unless you're a seasoned SAN (storage area network) manager, you're struggling to keep up with data growth. You're hanging direct attached disk arrays all over the place. New project ... new box. New application ... new box. More users, new box; full disks, new box ... new box, new box, new box. But, some of those boxes - particularly those sitting behind dead-in-the-water departmental projects or supporting a downsized business unit's shrinking user base - should have you questioning some of your knee-jerk "new box" reactions. And, even in organizations that have begun the move to networked storage, there's probably a lot of capacity mismanagement and hardware overpurchasing going on. "Storage is one of the more poorly utilized IT resources," says Brendan Reilly, CTO for storage solutions provider SANZ, Inc. (Castle Rock, CO). "According to Gartner, the average storage utilization in corporate America is only 35%. And, 22% of all data is duplicate."

Even if you did commit to using your existing disk space more efficiently, a good bit of it wouldn't be retrievable anyway - not for the apps and users currently needing it. Again, that's because it's stuck behind particular application servers, left literally unavailable to other, more needy applications. So, unless you enjoy configuring box after box of additional direct attached storage - and don't mind paying for more capacity even as you waste capacity - you'll be migrating data to a SAN.

But, while a SAN rollout may help you eliminate the mistakes of the past, it can also lead you to commit mistakes of the present and future. Want to overwrite key data? Go for it. Want to be crushed by new applications? Step right up. You see, when it comes to IT deployments, a SAN implementation is as ripe as any for buyer's remorse. Heeding the following cautionary advice from industry insiders should keep your organization from turning a SAN migration into a storage morass.

1. Start With Self-Discovery
There's no point in moving your storage infrastructure to a shared, networked environment unless you know what kind of data you've been storing. Bring in software tools and run discovery procedures on your existing disks. Then, get rid of the junk. Says Eric Pitcher, AVP of BrightStor solutions for storage management software vendor Computer Associates, Inc. (Islandia, NY), "You're likely to discover that 40% or 50% of your data doesn't need to be online. You can delete unnecessary copies and archive infrequently accessed data to secondary or tertiary storage."

According to Reilly, not only are some files no longer used, but they were created by users who are no longer on the network. "We did a usage assessment for a customer that had 40 TB of online disk storage," he explains. "Of that amount, 5 TB were files that hadn't been accessed in over two years, and 2 TB were allocated to 'unknown users' - temporary contractors who had come in to do projects and had been given disk space. The user names had been deleted but not the files. Intelligent reporting tools allow you to determine what data you really need to keep."

2. Don't Set Up Server Competition
If you're used to dedicating particular storage resources to particular servers, you may need to broaden your approach to allocating disk space. In the direct attached environment, you likely gave each server exclusive access to its own disk array. If you now point that server to a particular LUN (logical unit number) on a SAN, get ready for trouble. "If you let two devices share the same storage array down to the LUN level, you could have one server overwriting data written by the other," says Mark Stratton, director of marketing solutions and alliances for SAN switch vendor McDATA (Broomfield, CO). "Some server operating systems aren't aware when another server is getting into the same volume." Pitcher confirms the danger. "In a worst-case scenario, if you mount a UNIX server onto a Windows volume, or vice versa, all the data goes away. Because the file systems are so different, as soon as the second file system sees that volume, it starts making changes and corrections, destroying all of the data. You'll need allocation tools to help you keep track of the aliases for each volume on a SAN."

3. Expect To Buy Management Software
In your vigilance in monitoring and avoiding resource allocation conflicts, you'll soon tire of manually provisioning SAN storage. Says Stratton, "As you expand your SAN infrastructure, you'll eventually want to get automated provisioning tools. Otherwise, you'll struggle to maintain data integrity on a large fabric."

As your SAN infrastructure grows, it's likely to be handling storage needs for multiple platforms. That means multiple software tools. "We frequently see customers struggling to standardize their SAN reporting across all applications and operating systems," says Reilly. "So, you'll need more than one set of management tools. And, you'll need to tie the various device management tools into a centralized application layer above them. If you don't buy the software, you'll end up having to build it yourself."

4. Address (But Don't Obsess On) Apps
A key rationale for SAN implementations has always been networked storage's ability to accommodate dynamic resource allocation. As applications' needs for storage fluctuate across the enterprise, shared storage can be reallocated on the fly to meet those changing needs. That flexibility enables SAN provisioning to be, as is commonly promoted by the storage industry, 'application-centric.' But, Mark Lewis, EVP of open software operations for storage hardware and software vendor EMC Corp. (Hopkinton, MA), cautions SAN adopters not to focus too narrowly on an application-centric view. "At EMC, we have more than 300 business applications. We can't have 300 different application owners trying to set their own storage policies." Let's face it. If asked about their storage needs, most application managers would declare their apps to be mission-critical, requiring online access - probably 24/7, probably to all data.

Moreover, as Lewis sees it, there are business issues that cross IT and business boundaries that should make a SAN deployment part of broader corporate infrastructure development. "Take, for instance, any of the latest document retention and regulatory compliance initiatives - Sarbanes- Oxley, SEC, and so on," Lewis says. "Rather than developing retention and archiving strategies application by application, you should look at policies that could cut across applications. Every business unit is going to have to store databases and e-mail, for instance. You wouldn't build out your corporate networking infrastructure application by application or department by department, so why do it for storage?" Pitcher agrees. "Data doesn't live only in the storage environment. So, a SAN should not be an island within your IT infrastructure," he says. "A SAN is essentially just another network. An HBA [host bus adapter] is an HBA, a hub is a hub, a switch is a switch. From an administration standpoint, all of your networking components, including your networked storage, should be managed together."

5. Plan For A Future You Can't Envision
While SANs should help you control your storage spending, it doesn't mean your purchasing strategy shouldn't have you keeping at least one eye on future needs. Your data will grow, your storage will grow ... despite your best efforts to control it. That's why Stratton suggests always making purchases slightly ahead of current needs. After all, when organizations need to deploy new applications - and deploy them quickly, they can't delay in getting additional storage online. "Once companies have standardized their methods for provisioning storage on a SAN, they can quickly reallocate resources to bring on new applications," Stratton says. "Nonetheless, the rate of adding capacity should be a little bit ahead of the rate of application deployment."

In addition to readying their SANs for potential increases in capacity, organizations should also prepare for platform complexity and diversity. Says Lewis, "Companies tend to have a shortsighted attitude toward heterogeneity. To save money now, they buy storage solutions that are optimized for only one operating system or for particular applications. But, consider operating systems and applications that you don't currently have but might in the future. You may wish later that your storage had the flexibility to support them."