Living the Storage Consolidation Dream, Part I

Having once worked at a Fortune 500 company and watched it live the consolidation dream, I knew the reality was not necessarily the dreamy experience that vendors so earnestly promised. Yes, my company reduced its storage footprint, realized a return on investment (ROI), improved storage utilization and increased system availability - all critical components for it to justify a storage consolidation initiative. However my company only began to see some of the hidden intangible costs of consolidation once the process was under way.

A major part of the problem stemmed from expectations set prior to consolidation. Departments, business units, application owners, etc. operated and managed their storage systems in a manner similar to how they managed their servers: In a distributed fashion. Managed this way, each department or business unit often had its own servers and storage so they had the freedom to manage it in whatever manner best suited them. Those units doing development, research or testing therefore could make frequent, ad hoc changes to their storage systems.

Conversely those business units or departments that managed systems in high impact (i.e. revenue generating, public exposure, etc.) environments could only make a system change after the change was analyzed from every possible angle. Even then, the change could only take place at certain times and days after everyone and their brother knew when it was going to occur.

The practical ramifications of consolidating storage from these different departments showed up only after the consolidation occurred. Suddenly business units and applications that needed rapid changes to their storage configurations were hamstrung by these new requirements. They needed to adhere to more stringent requirements of production systems since production applications often took priority over applications in test and development.

Even in situations where consolidations of similar production systems occurred, the question of who should take ownership in the management of the storage regularly arose. Should it be the one with the most experience in storage management? Should it be the one who has done it the longest? Should the different departments share the storage management responsibility but if they do, who is responsible should something go awry?

So essentially what is emerging out of this configuration is a new set of rules for storage systems that are implemented as part of storage consolidations in distributed environments so they can deliver self-storage storage. Specifically:

• Individual application owners, departments and business units need to retain their autonomy so they can continue to manage storage themselves
• Storage systems need to provide multiple tiers of storage to meet corporate dictates to consolidate storage so capacity and energy costs can be contained
• Changes implemented by specific applications, departments or business units need to occur in such a way that they cannot impact storage assigned to other applications, departments or business units
• The storage system needs to support policies that prevent resources assigned to production systems from being impacted by testing and development applications

Companies now want it all: they want the flexibility of self service storage that they experienced while using distributed computing but they also now need and want the cost and power saving benefits that storage consolidations deliver. Meeting all of these requirements is something companies can only achieve using new storage systems such as 3PAR's InServ Storage Server. In part 2 of this series, I'll take a deeper look at how it delivers on these features and help companies not just implement storage consolidation but live the storage consolidation dream.