Stovepipes to Services – SOSS
by Hu Yoshida on Sep 21, 2007
IT has traditionally operated in stove pipes. These stove pipes operate separately and each consists of a group of applications that are assigned to run on a host server that in turn is connected to a set of storage devices. This stove pipe approach results in the inefficient use of IT resources. Applications have to rewrite the same function over and over again and information can not be easily shared between them. Servers have to be configured for peak utilization but usually run at only 10% or 15% of capacity and storage is grossly over allocated to avoid the disruption of out of space conditions. Server cycles and storage capacity are isolated and can not be moved or shared across stove pipe boundaries.
In storage there are many additional stove pipes which separate storage systems. Mainframes require ESCON/FICON devices and can not use lower cost SATA storage systems. Open Systems can not share monolithic storage arrays with Mainframes, since the mainframe channel processors can drive I/O much faster than open systems Host Bus Adapters and will dominate the cache resources. Open systems shops often have many products from different storage vendors that require different management tools and processes, even when they are connected with expensive SANs.
Recently there has been a proliferation of new storage products to address niche requirements like disk to disk (VTL), archive, NAS, Nearline, data base disk performance (Pillar), Thin Provisioning (3ParData), etc, all from different vendors with proprietary disk arrays, separate management tools, and built on midrange storage platforms that lack a large global cache for availability and scalability. In the archiving space, we see additional stove pipes where the archive of different applications requires a separate storage solution, which prevents the ability to do a common search across these separate archives. If we are to cope with the exploding growth of data we can not afford to continue with this stove pipe approach to storage and to IT.
The IT industry is beginning to address these stove pipes with a shift to a Services Orientation. In the application space we are seeing the movement to Services Oriented Architecture, SOA, by the application vendors, and in the Infrastructure space we see the movement to Services Oriented Infrastructure, SOI, by vendors like VMWare and CISCO.
Hitachi believes that Services Orientation is also the right approach for storage. Instead of a proliferation of niche, stand alone, stove pipe storage products which don’t work together, we need a common storage platform that can support heterogeneous storage systems and heterogeneous storage applications, with a reusable set of block, file, and content storage services. Storage vendors must provide a Services Oriented approach to storage in order to cope with the growing volume and complexity of data. Hitachi is meeting this requirement with Services Oriented Storage Solutions, or SOSS.
The basic principals that we use are similar to SOA and SOI. The first principal is the use of an abstraction or virtualization layer which hides the complexity of the underlying heterogeneous structures. In SOA the abstraction layer is XML or web services. In a SOI, it could be the VMWare operating system that enables other operating system to run concurrently on the same server. In SOSS it is the USP V Storage Controller based virtualization platform which masks the use of different storage devices by presenting them as USP V cache images to the host servers.
The second principal is the reuse of common services. In SOA an example of a reusable service could be a billing module that can be reused by many applications through the XML abstraction layer. In SOI, VMWare can provide common network and device services for its hosted operating systems for example. In SOSS our services are control unit based functions like virtualization of external storage for mainframes and open systems, thin provisioning, wide device striping pools, tiered storage, copy on write, distance replication, etc. In addition we can add high performance file virtualization services to this platform with our HNAS solution, and content services with our HCAP solution. Further more, with HCAP we provide a common meta data repository for ingestion by different types of content archiving applications. This eliminates the need for separate archive repositories and enables a common search and management capability. Unlike niche storage solutions where an archive solution can not leverage the thin provisioning of another storage product, SOSS can enable all these functions to operate together.
This platform enables us to add new storage services over time. The proof point for this is HDP, our thin provisioning service. Instead of building a separate niche product like a 3ParData system for thin provisioning of proprietary internal storage, we deliver HDP on our enterprise class platform and make it available in synergy with other block, file and content services, to heterogeneous storage systems that are behind the USP V and to server applications that attach to the USP V. (availability of HDP for external storage will be year end).
Service Orientation is a requirement for eliminating the stove pipe approach to IT. We already see this in the application and infrastructure space. The time is right for a Services Oriented approach to storage, SOSS. Ask you storage vendor for their plans for SOSS.
Comments (2 )
I would like to open another discussion, on the performance of ASM1000 UPS and MS exchange 2000.
Presently we are struglling to get any reasonable performace out of the HDS storage solution. The Jet tests are all failing and we performing all kinds of reconfiguring to try and improve the response and latency times.
We have many AMS1000,500 and USP. We bought USP-Vs to use HDP but most systems cant be thin prov due to metadata not being written to first block. (eg IBM AIX JFS and Sun UFS)