Storage too complex, your customers say: listen to them

Computer Technology Review,  August, 2004  by Michael Peterson

• E-mail
• Print
• Link

It's good that we are now hearing a lot more about where the IT community is having 'storage pain' or problems with its storage infrastructure. This is healthy introspection. Yet, on one hand, I'm concerned that the information being collected and talked about is misleading and potentially defocusing; and on the other, I've researched this area for the last 14 years and see an important shift taking place that must become broadly recognized.

From 1990 to 2000, I reported multiple times annually on the top storage problems based on surveys and custom research. Listening to IT professionals, we consistently categorized the top problems during this period as "managing disk space, running out of disk space, hard disk errors, capacity planning, and of course the list always included the ubiquitous backup demon in the number two spot." It wasn't until the early 2000s that I began hearing these pleas in a different context, as "storage complexity". As operating environments continue the path of consolidating and centralizing, they get bigger. The operating problem has elevated from a small number of servers and network devices to hundreds of thousands of unique networked elements in large datacenters. Yes, this is also what we call a datacenter operations complexity problem, not just a storage problem. But, let's talk about the smaller storage complexity dilemma first.

Today, the number one storage complaint (in frequency and in money allocated to fix it) is described by customers as "adding disk space". What does that mean? Is it hard to add disks? No, of course not. So, when you dig into this complaint you begin to hear the real issues--which is always the case in research. The surface data is usually misleading and not the real issue. There are many examples of this in recent history. In 1992, I began publishing the first large-scale research on the Cost of Managing Storage which included IT operations downtime from storage sources. Then, the number one storage downtime problem was reported by IT administrators initially as "processor failures"--which didn't make sense. So, digging in, we discovered that processor failures meant, "Oh, those are my disk drives" and that a disk failure had a profound effect on servers, operations and costs. Until about 1998, disk failures and errors were very high on the problem list. This problem has now faded into ancient history with the broad adoption of RAID. (RAID was a classic solution to a complexity problem. The solution wasn't to make disk drives more reliable, but to change the architecture to transparently cope with disk reliability problems.)

In the late 1990s, we began hearing words from IT that caused many to think provisioning and storage management were top problems. The industry responded with solutions such as virtualization and a plethora of point management tools such as SRM and auto-provisioning. Have these solved the problem? No, all of them are point solutions. Unfortunately, these vendors didn't hear the core problems. Why is that? I can only suggest that people didn't really study how IT operated. For example, it wasn't until 2002 that we even recognized that Visio drawings and Excel spreadsheets were (and still are) the top management tools in the datacenter because we weren't asking the right questions. (And a datacenter today averages 20-30 management tools.) It is not about "How does IT manage storage?" but "How do they operate storage?" and "What are their operating practices?" The differences are profound and the process workflow usually kept in a spreadsheet, thus its dominance.

Today's top storage problems are similar. I'm placing them into a category I call "Storage Complexity" on purpose because we need to look at the solutions to this category of problems in an operations context. IT doesn't naturally use this term so we're only just now beginning to hear it; but listen closely to what they say. When told that the big problem is some variant of "adding disk space," ask "What does that mean to you?" and "Why is it hard to add disk?" They will recant the statement and declare some string of problems and difficulties that flow from the continual fires and relentless process of expanding disk capacity. Figure 1 gives some examples of how this pain gets voiced.

[FIGURE 2 OMITTED]

I define storage complexity as the chaos of owning and operating thousands of storage elements. That sounds too vague to address, but is exactly the point. We need a new approach to solving complexity problems. Just as RAID solved the "disk error" problem of the early '90s, and 'data protection' will solve the backup problem that persists, so to will 'workflow-based process automation' (operations management) solutions pave the way to solving the storage complexity problem of the 2000s. Why? First, look at what makes up storage complexity. It contains the components listed in Figure 2 and more. The process generally goes "add disk then provision it (those 40-100 steps can take weeks of planned downtime), expand backup, maintain existing systems and operations while doing all this, establish data management services, deal with staffing shortages and expertise to do this work, load balance and tune the systems and applications, zone, recover and reallocate unused space," and on-and-on it goes. These are complex operational processes that cross all boundaries, including business and ownership domains, and are not addressed by a toolkit of traditional management tools. What happens if and when you skip a step such as expanding the backup?