While the cost of storage capacity is declining every year, the capital and operational expense of storage is increasing every year. Some of that expense is because of the increasing demand for retention of data, but a good deal of the increase is due to the proliferation of niche storage solutions. These stove-pipe storage solutions require different management tools for the same storage functions, require duplication of storage and networking resources, and limit the ability to respond to changes. A services approach to storage is required to eliminate these stove-pipe solutions.

What does a stove-pipe storage solution entail and what is a services-based approach?

We can start with the biggest niche solution, which is the Monolithic Storage Array, built by only a handful of storage vendors, but runs most of our mission critical storage applications. This type of storage has the highest availability because it can have multiple storage processors access one common cache image of the storage. The loss of one or two storage processors will not cause the loss of data or access to the data, since the remaining storage processors can still access the data image in a shared “global cache” (if it is properly configured for alternate pathing). These systems also have a robust menu of Business Continuance solutions, have the highest connectivity and cumulative I/O rates, and are the only systems that support mainframes.

The next niche solution is the two processor modular storage array. It is generally referred to as modular since the controllers come in a drawer, and are configured with other drawers which contain disk drives. The main characteristic of this solution is the lack of a global cache that is shared between the two processors in the controller. Each processor has it own cache and the writes are mirrored to the other cache to protect against data loss if one of the processors dies. If you lose one processor, you have lost half your cache, half your processing power, and all storage ports that were connected to the failed controller. If you don’t want the risk of another failure taking down the other controller and losing the data in cache, you would stop and take a maintenance window before you continue production. This storage array was designed for open systems when open systems only needed a few ports for connectivity, could afford maintenance windows, and did not require distance replication.

NAS is another niche storage solution, providing shared file access to data. In most cases the storage in NAS systems are modular arrays because it runs on Open Systems, does not require a lot of connectivity to the array, and does not need controller-based replication since it can do file replication.
Recently we have seen a proliferation of new storage solutions that address requirements for disk-to-disk backup (Virtual Tape Libraries), content archive, near-line storage, database optimization, Thin Provisioning, etc, and are built as proprietary vendor solutions and are integrated with other vendors’ modular arrays.

A services approach to storage will eliminate the need for all these niche products, by converting these storage solutions to services that can be run on a common platform with heterogeneous storage devices. For instance, instead of each solution developing its own replication capability for a particular vendor’s hardware, they could re-use a common replication service in the platform. It will also enable these solutions to work together with common management instead of in stove-pipes. Instead of a data base optimisation solution which places data on the inner and outer bands of a disk surface to minimise the arm movement, it can use the wide striping of a thin provisioning solution to get more arms in play. There would be no need to lock the platform down to a particular vendor’s disk storage, and no need to compromise availability in order to use lower-cost modular arrays.

So how do you develop a Service Oriented Storage Solution that answers all these requirements?

Hitachi’s approach started with the separation of the high availability, multiprocessor, global cache controller from the backend disk arrays in our monolithic storage array. This opened up the attachment of the enterprise class, USP control unit to virtually any vendor’s disk array that attached through standard FC interfaces. Now modular disk arrays could use all the services of a large enterprise class storage system like distance replication of consistency groups, and mainframe-attach. Next we added file service by using NAS blades and NAS heads like the HNAS solution we developed with BlueArc, VTL and de-duplication solutions with Diligent, and Content Services via the acquisition of Archivas.

Because we started with an enterprise storage control unit architecture designed for high performance and scalability, we can continue to add functionality to this platform and make it available as a service to any storage that attaches to this platform in addition to any application that attaches to it for block, file or content services. A case in point is HDP, Hitachi Dynamic Provisioning, or thin provisioning which we added to the USP V that was announced this spring. Because it is delivered on the USP platform it is available as an enterprise class solution, to any application that can benefit from it. It will work with other services like Shadow Image, and it will be available to any external storage ( due to be released in 3Q) attached to the USP V. Thin provisioning from other vendors require a niche product, with a cluster of modular storage arrays which lack enterprise functionality, scalability, and availability. Watch for other services to be added to this platform.

Virtualisation is old news. It is being replaced by services orientation. Storage virtualisation is most useful as an enabler for services orientation. Services oriented storage is part of the whole movement to services along with Services Oriented Architecture (SOA) for applications and Services Oriented Infrastructure (SOI) for the infrastructure. All three, SOA, SOI, and SOSS, will be required for a dynamic data center. While SOA can reduce the cost of application development and management, it needs an SOI so that is not tied down to a rigid infrastructure for routing and load balancing, logging, etc. It also needs an SOSS so that it is not tied down to a number of niche stove-pipe storage solutions.

Hu Yoshida is the CTO of Hitachi Data Systems