Back to Reality

Given the deals that are currently being struck between switch makers and virtualization vendors , one might have the erroneous impression that the virtualization issue is close to being resolved. This is far from true.

Technically, porting virtualization software to a certain vendor's switch platform is a nontrivial task. Doubtless that with sufficient resources vested in research and analysis, the ways and means could be found to equip a switch platform with the kind of LUN aggregation capability currently represented as virtualization. However, this alone will not solve the problem.

Standards do not exist for disk virtualization and vendors of both virtualization solutions and storage arrays are no closer today to closing ranks on a universal approach than they were two decades ago. As a result, storage architects within IT shops will still confront the same problems going forward. They will have to check to see which hardware they own (or are considering purchasing) will work with a given virtualization solution. Moreover, they will need to undertake substantial due diligence testing to determine whether the virtualization products that they are considering for their shop are compatible with software that they already use. In short, little, if anything, changes.

Many are still pondering the question of whether virtualization is worth the problems that it might introduce. Some vendors argue that you need to virtualize storage to simplify its management and to lower cost of ownership. Others say that virtualization is required to enable scaling and increase storage fault tolerance.

In fact, none of the arguments are true. The best that can be said of virtualization is that it is an enabling technology. If some sort of standards-based virtualization scheme appears (or one vendor's approach becomes dominant), it is possible that virtualization will set the stage for simplifying storage management and reducing the number of persons required to manage storage.

Similarly, with a standardized virtualization engine, it may be possible to add and subtract storage from virtual volumes in response to application storage capacity requirements, thus optimizing capacity allocation efficiency to some extent and reducing downtime for storage reallocation.

However, none of these benefits is a function of virtualization itself, but of additional layers of software that may be added atop a standardized virtualization layer. In the absence of standards that allow virtualization to be compatible with the broadest possible range of software tools, storage management software options are bound to be limited. In cases today where vendors offer virtualization platforms that include a suite of storage management software tools ”a sort of " one-stop -shop" ”consumers tend to shy away. Common complaints include that the suite includes inferior tools that they do not want or need.

The truth about storage virtualization is that it does not deliver fully on any of its value proposition. No virtualization technique enables cross-platform LUN aggregation that array vendors themselves do not permit.

Moreover, LUN aggregation addresses only part of the capacity allocation efficiency requirement. To achieve allocation efficiency, you need the ability to "carve" the unused portion of storage behind one application and "splice" it to the storage allocated to an application that is consistently running out of room. See Figure 7-6.

Figure 7-6. Storage is allocated inefficiently, but virtualization (LUN aggregation) can't resolve the problem.

LUN carving and splicing technology is almost completely missing from current external virtualization solutions, though, arguably, it does exist inside arrays from certain vendors such as Xiotech, and in utilities provided in Microsoft Server 2000 for dealing with "basic disks." In its absence, according to industry insiders, disk capacity is only allocated to about 40 percent of efficiency in UNIX and Microsoft environments, to 20 to 30 percent of efficiency in Linux environments, and to only about 60 percent of efficiency in the case of mainframe DASD. ^[11]

Using a blunt tool like LUN aggregation to deal with the capacity allocation problem confronting most shops today is only effective if all LUNs are defined at the smallest possible size. That way, virtual volumes can be assembled in very small increments (think "Leggo building blocks"). Otherwise, a lot of disk capacity is going to go to waste.

While wasteful , capacity allocation inefficiency isn't as costly as its evil twin, capacity utilization inefficiency. If we consider the amount of space on expensive storage arrays occupied by junk files, duplicate files, and rarely accessed data that could be stored on less expensive arrays or archived to tape, the utilization efficiency of most storage infrastructures today would be abysmally low: somewhere in the 30 percent range. Even at $1.50 per GB for storage, that is a significant cost to your organization. Given RAID mirrors and mirror- splits that seem to be appearing in nearly every shop today as a data protection measure, the problem is multiplying geometrically . ^[12]

It is to this issue that we turn our attention next . For now, this dissertation on virtualization needs an ending.

Figure 7-7 provides a comparison of two images. The one at left shows the nine circles of hell as described in Dante's Inferno in the early 1300s. For each type of sinful behavior, according to the text, there is accorded a special place in the underworld.

Figure 7-7. Dante was a storage manager.

The image at left shows a simplified view of virtualization from the perspective of the disk, building out to the array, then the FC SAN. There are many layers of virtualization, from the original mapping of bit domains on a disk surface, to the superimposition of a file system, to the creation of RAID sets, to the definition of LUNs, then to SAN Zones.

And at the bottom of the model, for those of us who have been very misbehaved in our lives and have much for which to atone, there is something we have come to call "virtualization."

Maybe Dante was a storage manager in another life.