Features - Enterprise Data Insights:

A RADICAL VIEW ON VIRTUALIZATION
By Dick Benton, Senior Consultant, GlassHouse Technologies

Not so long ago, nearly every industry publication carried an article or two in each issue on virtualization's promise. What is the current state of the art and what problem does this technology really solve?

The first challenge is one of definition. The word "virtualization" has had its meaning defined and redefined by various vendors. A definition not so far from common acceptance describes virtualization provides an ability to view, allocate, access, manage and protect storage without needing to understand or know of the underlying physical storage structure. The goal of virtualization appears to be to treat storage as a utility, just like the electric or phone utility. We don't need to know about, nor understand the electrical grid to use an appliance. We just plug it in. We don't need to know how the telephone companies interconnect worldwide; we just pick up a phone and use it. With virtualization of storage, the theory is that we don't need to know where the data is nor do we need to know on what it resides, we simply consume it as required.

Certainly, the ability to view enterprise storage and its utilization is of significant benefit in understanding the needs of the business. Many virtualization solutions provide this excellent capability. The problem comes when allocation is attempted without cognizance of the underlying storage technology. Imagine an Oracle database supporting SAP. Tables need to be expanded or space made available for new tables, so we are lead to believe that virtualization can be used to allocate additional storage from the available pool.

Alas, the virtualized storage pool, by definition, includes all storage devices in the enterprise and de facto these will include devices with widely diverse metrics on performance, availability, and reliability. In our example above, the database table may conceivably end up on a large disk or a small disk, in a Raid 5 array or on mirrored disk, on a high availability box or on a low end device, on a fibre fabric or an Ethernet fabric, on a block level controller or a file level controller. Do we really want our Oracle database spread out over EMC Symmetrix, IBM's FastT and a bunch of direct attached raid devices on multiple NT file servers?

Does it make sense to utilize such a diverse range of storage classes? Perhaps so if we are simply looking for some available scratch space. Or perhaps if we are looking for additional (end user unique) file space for office productivity applications. But how can this possibly be a solution for high-end enterprise applications, for database structures, for mission critical applications that require a very specific class of service allocation?

De facto, a SAN storage device is a virtualized storage pool (available to fabric-attached servers and their applications). A NAS device is also, de facto, virtualized storage serving its LAN-attached clientele. Expanding the storage pool in this environment is done simply by adding additional storage to existing arrays. What is the real benefit of removing the "box boundary" that currently limits SAN and NAS virtualization to a single frame?

The virtualization promise of ease of allocation and deployment again fails the test when we consider the wildly disparate performance characteristics of the various components of a virtualized storage pool. While it may be possible to allocate LUNS at a logical level, we still face the issue that this is an inherently invalid approach given the need to match storage characteristics (classes of storage) to application requirements.

The virtualization promise of ease of management also founders on the proprietary nature and very unique interaction of each vendor's storage frame management software. Add to this the additional complexities of fabric zone management and the promise of virtualization seems a long way off in the future.

Expanding the virtualization of storage beyond the frame boundaries of existing SAN and NAS devices appears to add very little real functionality and this at the expense of placing intrusive and immature software/firmware/hardware components into mission critical environments. In band or out of band, NT backplane, Unix or Linux, virtualization inevitably adds complexity and additional failure points into a carefully balanced environment of mission critical applications.

Finally, an enterprise virtual solution should, by definition, be a heterogeneous solution capable of utilizing storage no matter what it is connected to. This should include mainframe storage. Most of today's virtualization products are limited substantially to the open systems side, thus making inaccessible perhaps the largest and most highly available mass storage in the enterprise.

A significant benefit delivered by current virtualization products is their ability to provide a replication capability and sometimes a snapshot capability too. This can be advantageous to those organizations where the allocated class of service would not normally provide this level of functionality and sophistication.

Nonetheless, I believe the prudent IT executive will contain virtualization solutions to a File and Print NT environment where they may indeed provide some benefit in optimizing direct attached storage across a number of file servers. Even here, this solution will soon be made obsolete by the imminent arrival of iSCSI, with TCP encapsulation on NICs and the use of NAS storage devices. This solution will be a far more elegant and a more appropriate "open systems" solution than current proprietary virtualization solutions.

Much has been written about the virtues of in-band solutions (virtualization engines in the data path itself) versus out of band solutions (virtualization engines outside the data path); however the real issue is what happens when the virtualization engine is removed from the environment. Will hosts still be able to access their data? Until recently, many virtualization products operated in such a manner that, should they be removed suddenly from the environment, hosts would not be able to find their data. This additional failure point was often of itself sufficient concern to militate against use of virtualization.

More recently, some virtualization engines can indeed be turned off. Such engines can provide the ability to look at and perhaps even manage the storage environment through an abstracted layer that removes the complexities of heterogeneous management from tedious day-to-day management and metrics gathering. Nonetheless, vendor-specific complexities, lack of industry implemented standards at this time, and a drive to "own" the storage environment are leading individual storage vendors to develop heterogeneous management platforms based on an API philosophy. (Application Program interface to competitors storage frames). While this may be less elegant than a virtualized management solution, it has the giant advantage of being supported by the storage vendor itself.

Subject to publication of industry standards and the embracing of those standards by mainstream vendors, it is the ability of virtualization to enhance the management function, rather than its original premise of abstracting physical data from the application, that we may see as the key driver of the evolution of virtualization.

Should this scenario come to pass, the industry may well benefit from a number of small startups offering "faster, better, cheaper" solutions to managing the complexities of the storage environment.

About The Author

Dick Benton is a senior consultant with GlassHouse Technologies Inc. He works with clients to analyze their needs and the options available for cost effective storage and disaster recovery infrastructures. Dick focuses on pragmatic solutions, leveraging existing infrastructure where possible, to develop solutions that are appropriate for the particular business requirements and phased to suit organizational budgets. He holds a M.Ed. from Cambridge College and is in the process of being certified by the Disaster Recovery Institute in business continuity planning.