Automatic disk provisioning: the real story.

Automatic storage provisioning is getting a lot of attention lately. It's not clear exactly how this is going to be accomplished in all storage environments, nor who will be involved in provisioning, but one thing is certain--there will be products of some sort. The market driver for automatic disk provisioning is the need to provide needed online disk capacity to users and applications from places where capacity isn't being used. This will increase efficiency of storage utilization and, if truly successful, will take place with a minimum of human involvement. If glowingly successful, it will be done inline with preset guidelines and in accordance with an intelligently defined policy. If even marginally successful, however, it will not require reboot of OS's or unmount and remount for file systems or reinitialization of applications.

Not the First Time

About a decade ago, it was deemed important or even critical to be able to add disk capacity to online, in use, fully functional disk arrays and even to disk arrays in a diminished capacity, but in-use and online. This was called OCE (Online Capacity Expansion). The goal then, much as now, was to add disk storage capacity dynamically for applications and users that required it. This technology was created and deployed by more than one vendor and it never really took off. It was a check off competitive item on RFPs, but was it ever really used? Not for the most part.

Why didn't companies use the technology? The principal reason was that systems and applications and users had to go down anyway for the file system, application, memory managers, etc., to recognize that a change that they could manage had taken place. Reboot was the answer. Restart the application was another. CIOs questioned the value of doing so much work to achieve the desired benefit.

Fortunately, a lot has changed in the computer and storage world to better support the value of provisioning without administrative trade-offs. We now have the technology to not only add capacity to one place, but to take it from one or more other places to create this added capacity. And we can do it virtually, without actually moving hardware around and re-cabling, hot plugging and so forth. Furthermore, we can schedule and automate this according to rules that we create, and we can span transport technologies, drive interfaces, and vendor-uniqueness as we do so.

The graphic below illustrates today's storage network components that can help change the provisioning value equation including:

* SAN

* NAS 

* Fibre Channel Fabric (beyond loop)

* Truly Fast Ethernet 

* IP Storage

* Commercial Global File Systems

* Partitioned computers and memory systems

* Virtual disks (outside of the file system and disk arrays)

* Intelligent Switches

* Approaching Seamless Fabric and Bus Bridges

* Intelligent Policy Logic

* Work Flow Engines and Schedulers

Close, but No Cigar

The one nagging problem, however, is that we still need to reboot, re-initialize, and restart all of the entities that were affected by provisioning changes--not just the servers that had capacity added, but those where it was removed as well.

The reasons for this are pretty clear. Memory management expects its virtual memory to be consistent in size and persistent in availability. Change virtual memory characteristics and watch the systems crash mightily.

File systems, for the most part, have similar expectations. They expect the capacity of their mounted (or cooked) storage to be consistent and available, too. When e_nospace hits, when the mounted file system thinks there is still 10GB available, it will cause problems. Further, even though capacity is added, the file system will not know about it and will probably provide e_nospace errors even if there has been capacity added. There is no way to dynamically inform, change and adapt.

Applications that do not do I/O through a file system still have the concept of available blocks or capacity. They get this from the pre-boot environment or from other system facilities provided by the OS or other tools. They are not used to changing and certainly (as with the above examples) do not want to add complexity and almost certainly heinous bugs to their products that will crash them, the OS, and possibly other entities attached to the fabric.

The Cost/Benefit

Why do dynamic provisioning then? The answer, believe it or not, is efficiency. If it would be possible to provision for more efficient disk capacity utilization in an uptime environment, changes can be made over the network from a central location. If the systems, storage and network were not up, this would mean lots of walking around, using many differing tools for many differing OS's, devices, management tools, array configurators and so on.

[FIGURE 1 OMITTED]

So, if I can configure all of these changes in a up environment from a single convenient location across heterogeneous fabrics and networks, then commit to a single, global type of reboot, reinitialize and restart, then I've saved time, downtime and headaches. This is the promise, the Holy Grail, the Nirvana of every System Administrator, Database Administrator and CIO. Halfway there is not good enough. It would be like jumping halfway across the Grand Canyon. You're dead, unless you can make it all the way.

Call to Action

Here is where the industry needs a broadly adopted standard that everyone can use in providing the automatic provisioning so that it works with all OS's, all transports and all device types. Then this would actually be valuable! We must take it the entire way, deploy the standard, or else we have created more havoc and destruction for our customers.

Meantime, maybe we are stuck with the same tools we've used for years to solve this. Management by walking around takes on new meaning in Networked Storage environments.

OR ...

Maybe we need to make better use of the management tools available now. Maybe we need to plan better using design and modeling tools. We can look at SRM reports to anticipate and plan for expansion and contraction. We need to understand that not all data need be on expensive disks and that it can be placed elsewhere. The interim step is not nothing, but rather to use the tools currently available to use in their best practices mode. There is a great deal of capability, and incomplete automation is not the right answer.

To solve interim needs, essentially "bridging the canyon," an integrated suite of management software is needed, and it must address all key storage resources:

* A Portal to give a "single pane of glass" complete and intelligent view

* SRM to gather key usage data to drive policy management

* SAN design & management to deploy, manage and reconfigure SANs

* Integrated departmental & enterprise backup managed through the portal

Ultimately, the solution should offer customizable operational best practices driven by an automation engine. The engine should be fed by information from the management toolset. Then we'll be ready to think about jumping all the way across the canyon.

It's these realities, as expressed by our customers, which has led CA to focus its development efforts on both building the bridge and then enabling the cross-canyon jump.

Mark W. Bradley is senior technology strategist, BrightStor, at Computer Associates, Inc.

www.ca.com