In-Depth

Storage Management Issues Still Driving Us Crazy

The classic mainframe need for simpler storage administration still resonates in the open systems storage world

• By Jon William Toigo
• 04/17/2003

There are some people in this industry who carry the history of data storage in the form of an oral tradition. Nick Tabellion, CTO for Fujitsu Softek, is one such person. After 32 years with IBM, where he was a guiding force is Big Blue’s Systems Managed Storage (SMS) initiative, Tabellion landed at Fujitsu Softek, where he is bound and determined to bring SMS-style sanity and order to the distributed storage world.

Even those who work for him say that Nick is a pretty reasonable guy. Like Hu Yoshida at Hitachi Data Systems (who used to work with Tabellion at IBM), he is somewhat quiet and modest—an engineer’s engineer. Both men stand in stark contrast to Zya Aral, another IBM veteran, undisputed wild man, and CTO for Datacore Software, on whose core storage virtualization software engine code Tabellion’s own storage management platform is based.

Taken together, the three ex-IBMers share the same goal: deliver storage to an application based on a well-defined strategy combining pooled physical storage and yet-to-be-defined logical characterization of application data requirements—the essence of SMS.

Tabellion recalls that IBM confronted the same dilemma in many ways that storage vendors confront today. “In 1979,” he says, “the IBM GUIDE User Group published surveys that showed that data center operatives were not terribly productive in terms of how they managed storage. The average storage administrator could manage all of 11 gigabytes—gigabytes!—of storage. Storage utilization hovered at about 30 to 35% of capacity. And with storage growth anticipated at about 30 to 40% per year, IBM determined that this dynamic was eventually going to inhibit the sales of storage hardware.”

His observation might resonate with more than a few readers of this column. More than one IT manager has reported being on the horns of a dilemma: “Buy another array, or hire another body.” In point of fact, buying another array virtually ensures the requirement for more staff given the current limitations of storage management in most shops. In an interesting economy of scale, the average storage administrator in 2003 can manage about 300 to 500 GB of open systems storage, storage capacity utilization efficiency hovers at between 25 and 35%, and data is amassing (in gross averages) at about 70 percent per year.

Then, as now, says Tabellion, better storage management—management that simplifies storage administration and enables fewer personnel to be more productive—is the name of the game, not only for storage management software vendors but hardware vendors as well. Tabellion recalls that IBM did not develop SMS because of some earnest desire to improve quality of life for those who labored in the glass house of the corporate data center, “They did it to sell more hardware. Without SMS, [Direct Access Storage Device or DASD] sales would be inhibited.”

As with IBM in the late 70s, Tabellion (and, by extension, Datacore) first focused on volume pooling to attack the problems of performance, availability, and non-disruptive scaling. “We are trying to solve the same kinds of problems that IBM was seeking to solve then, except in the open systems storage world. To some extent, the current problem set is faster to develop and [more challenging] than the problems we confronted when SMS was created.”

One benefit that SMS developers enjoyed was a published standard for how DASD interacted with the mainframe OS and its hosted applications. Tabellion notes that such standards do not exist in the open systems world and points to proprietary storage product designs as an obstacle. “Instead of standards, we see a growing number of ‘platforms’ appearing in the market: basically, collections of host bus adapter, switch, and array vendors who join together to create [de facto standards or reference models] that can be more readily included into a general storage pooling approach.”

Tabellion says he is also watching Datacore’s “virtual addressing technology” with considerable interest. According to Datacore VP Mark Friedman, virtualized addressing refers to the mapping of volume addresses to the SCSI address space, which enables Datacore to use address tables like page tables, store them in memory cache, and speed I/O processing.

Of course, even if the physical domain is simplified through virtualization, there is another difficult nut to crack if the old SMS approach is to be realized in the open systems space. “In the mainframe world,” Tabellion notes, “we worked to separate the logical requirements of data storage from the physical aspects of the disk platform itself. We created two separate constructs: storage class, which enumerated the logical requirements, and storage group, which contained the physical attributes of the back end storage platforms. If IT managers had made the effort to define what the logical requirements were for their various applications, then storage could be allocated on the fly by simply stating that this new data belonged required storage class X and storage pool Y.”

Tabellion is the first to admit that no logical requirements definition stratagem exists today. “We have a policy engine in our product that may be adapted to do some of the logical storage class definition, but it still requires a lot of human intervention to map the elements of an application to storage classes.”

The best that can be concluded from Tabellion’s remarks, then, is that storage management in the mainframe world and in the open systems world are the same, but different. On the physical level, the open systems world continues to lack the maturity and single vendor dominance that IBM enjoyed in the 1970s and 1980s. Challenges to effective virtualization and volume pooling constantly arise from the dearth of effective standards for how physical devices interact with each other, with servers, and with all the network or fabric traffic shaping gear in between. These challenges are dwarfed, however, by the next round of hurdles: creating storage classes, then mapping applications and pooled storage devices to those classes.

We were just finding the answers to the second set of problems in the mainframe world when open systems exploded. Now, the old problems are still driving us crazy after all these years.