This month we look at consolidation, which is right at the top of many storage managers' to-do lists. Like a lot of seemingly no-brainers, consolidation is often harder than it looks, as you'll find out by reading the story.
Slogging through all of those obstacles is a necessary step. But a step toward what? Where are you ultimately headed and how is what you're doing now helping you get there? What's the end-game for consolidation? The wall-of-drives storage utility? Low-risk functional islands? OK, but built along application lines, operating system lines, crooked lines?
I'm not suggesting that you go on a retreat and meditate until a vision of a perfect storage world appears before you. Go forth and consolidate, if imperfectly. There's no way to gauge perfection until you experience imperfection, which is certainly easy enough to do these days.
But don't you find it troubling how easy it is to simply re-create the stove pipes of the pre-networked storage world even as you jump full force into storage networking? Got too many Unix servers with direct-attached storage (DAS)? Consolidate the storage for your Unix apps onto their own SAN. Tired of trying to back up dozens of scattered Exchange servers? Consolidate Exchange onto its own fabric. Are you going to put SAP/R3 onto your Unix SAN or give it its own? Should you have a manufacturing SAN because organizing SANs by business unit makes it easier to charge back for services?
This issue was brought home to me recently when a really smart storage manager I know told me that his company had one SAN for mainframes and one for open systems. He sheepishly admitted that there was no technical justification for this--it's just the way it had always been done. So all that fiber and fabric just winds up being little more than a really fancy SCSI or bus-and-tag cable. Now that's progress!
I'm sure many other people are in the same boat. We're years away from a true utility storage pool for many years, so I don't think these are academic or short-term questions. And they all have implications: How do you control utilization and security? When you finally get a real storage operations center, how does the staff have to be organized? Can you accommodate the idiosyncratic demands of different operating environments and applications while still realizing the benefits of new ways of doing things?
The answers to those questions will go a long way toward determining how far and how fast you're able to scale up today's typically small and isolated SAN deployments toward a more universal facility. Yet with all of the yak-yak from vendors, I've heard exactly zilch from them on these issues. Perhaps there's no glamour in selling the whole notion of intermediate steps to the Promised Land. But I know that some of you are thinking about this issue and beginning to see what storage networks should or could look like in five or ten years. I'd love to hear from you on how you see this whole transitional process.