This article can also be found in the Premium Editorial Download "Storage magazine: Tips for unifying storage management."
Download it now to read this article plus other related content.
|Tying the mainframe into the SMI standard|
| Storage Networking Industry
Association (SNIA) describes its Storage Management Initiative (SMI) as an industrywide effort to
"develop and standardize interoperable storage management technologies and aggressively promote
them to the storage, networking and end-user communities."
In fact, the scope is a bit narrower than that. Currently, the SMI project is focused on standards for software managing Fibre Channel-attached storage area networks (SANs) holding data from distributed platforms such as Windows and Unix. While there has been some discussion of including mainframe platforms in the SMI initiative, there is currently no plan to do so, SNIA officials say.
"There is nothing going on in the technical working groups including the mainframe," says Ray Dunn, marketing chairman for the Storage Management Forum. "There may be some mainframe guys looking at SMI and wondering what it's about, but they haven't brought those questions to us so far."
Dunn says SMI hasn't pulled the mainframe into the standards drive because doing so wouldn't solve the biggest problem faced by storage managers. "The pain point for our customers is trying to get their arms around all these storage management technologies that are out there in the rapidly growing distributed world," says Dunn. "With a single interface, SMI will be used to manage multiple arrays from different manufacturers."
The next phase of the SMI specification, Version 1.1, will expand the focus of the standard to include network-attached storage (NAS) devices and iSCSI storage networks.
The SNIA won't pull the mainframe into the SMI project unless major vendors--IBM specifically--push for it, says John Webster, senior analyst and founder of the Data Mobility Group.
IBM officials, however, say that at this time there wouldn't be much point in including the mainframe in the SMI project. That's because mainframe storage management software and processes have already matured far beyond the simple level being targeted by the SMI.
While there seems to be little chance the mainframe will become part of the SMI effort any time soon, there's a chance that down the road, storage managers could benefit from interoperability between the two environments, analysts say. If the standard is widely adopted and enhanced to support the active management of storage devices, it may then make sense for vendors to create software agents that would allow the mainframe to interoperate with SMI-enabled applications, says Brian Babineau, an analyst at Enterprise Storage Group.
"But first, you would have to see an SMI standard with increased functionality, even to the point where you could do more by supporting the SMI standard than proprietary [application programming interfaces]," says Babineau. "And that is a long, long way off."
In the enterprise storage world, users have made it crystal clear that they're tired of being required to train storage administrators to use different storage management tools for different servers, storage area networks (SANs) and arrays--none of which interoperate well. And finally, the vast majority of vendors have heard them. They've pledged support for industry efforts such as the Storage Networking Association's Storage Management Initiative Specification (SMI-S) standard that may actually deliver standard interfaces and data semantics, allowing storage managers to use a single set of tools to manage storage on any platform.
Well, just about any platform.
Even though a large chunk of the most important enterprise data still resides there, the mainframe is on the outside looking in when it comes to most discussions of heterogeneous storage management. Standards initiatives such as SMI-S are--at least for now--ignoring the mainframe. And with a few notable exceptions, vendors aren't investing much time and energy to creating products and interfaces needed to manage the worlds of mainframe and open-systems storage as one. So, for the foreseeable future, users say they'll need to continue to use different sets of tools--and in many cases, separate organizations--to manage mainframe and open-systems storage.
Is this a problem? Not a big one, according to many storage managers. It would be nice, in theory, to use the same software to manage mainframe and open-systems storage, particularly if that meant employing more mature and robust mainframe storage management tools and processes on the open-systems side.
That may some day be possible, particularly if Linux, iSCSI and IP-attached storage become common on the mainframe. Besides, storage managers say they don't need common mainframe and open-systems storage management tools to begin to leverage mature mainframe practices on the open-systems side. They can do that by using the same people to manage both mainframe and open storage, leveraging their knowledge of more mature mainframe processes to improve results on the open side.
"For us, the integration point between the open-systems side and the mainframe side is the people," says Laurence Whittaker, supervisor of enterprise storage management at retailer Hudson's Bay Company (HBC) in Toronto. "Having integrated management tools [that cover the mainframe as well as open systems] is not a high priority, as we have plenty of well-developed skills on both platforms."
Whittaker's group includes four storage analysts, all of whom are responsible for provisioning, backup and storage management on open-systems and mainframe platforms. While the group lacks tools that would analyze storage resources and automate provisioning across mainframe and open environments, they are able to apply principals such as capacity planning and hierarchical storage management (HSM) to the open-systems side.
HBC--which doesn't share disk arrays between open-systems and mainframe servers, but does share tape libraries--also uses mainframe tools and processes to track tape drive usage trends by both mainframe and open-systems servers. As a result of this cross-fertilization of storage management skills and practices, HBC has managed open-systems storage more like mainframe storage. In fact, the company's storage capacity utilization rate averages 65% on the open side. That's not up to the 80% rate that HBC sees on the mainframe side, but well above utilization rates in most open-systems shops.
"I don't anticipate anytime when we will manage both [open systems and mainframe] environments with the same set of tools, certainly not any time soon," says Whittaker. "What I do anticipate is an open-systems environment that operates very much the same way that the mainframe environment does."
Integration not urgent
Whittaker isn't alone in downplaying the need for integrated mainframe and open-systems storage management. "Attempting to manage mainframe, Unix and Linux storage using the same tools wouldn't make things easier, it would increase complexity for not much of a payoff," says Dennis Kaminski, manager of technical support at Siemens Dematic, a manufacturing equipment maker in Grand Rapids, MI.
Siemens Dematic has taken steps to integrate mainframe and open systems for archival and backup purposes. The company uses a storage appliance from Bus-Tech Inc., which emulates a mainframe tape controller and allows the company to attach open-systems storage devices such as ATA drives to a mainframe. Siemens Dematic uses Tivoli software to manage backups for both the open-systems and mainframe storage.
Attempting to go beyond that fairly narrow integration of mainframe and open-systems storage management, however, makes no sense, says Kaminski. Tools for provisioning mainframe storage are working well, he says, and he doesn't want to risk losing that. Besides, the company is likely to replace the mainframe within the next year, moving to Hewlett-Packard Co. (HP) Unix servers to run its SAP enterprise resource planning applications.
Faced with that sort of ambivalence, vendors--mostly notably IBM Corp.--say they see little reason to invest big R&D dollars into porting mainframe storage management tools to the open-systems world or even to create robust interfaces between, for example, provisioning or SAN management software running on mainframe and open-systems platforms. Vendors say they see more risk than reward involved in merging mainframe and open-systems storage management. The biggest risk--perceived by vendors and many mainframe storage managers alike--is that mainframe reliability could be compromised if users were asked to rip and replace mature mainframe storage management tools with more generalized software capable of managing storage in both environments.
"In the mainframe world, storage managers are used to being held accountable with extremely tight metrics, and everyone's very worried about doing anything that would disrupt that," says Dave Russell, in charge of technical strategy for IBM's Tivoli storage management products. "People's jobs are on the line if they can't recover volumes in a certain amount of time. And [on the mainframe] many have one or two opportunities a year to apply maintenance, much less migrate to a whole new set of products."
Russell says that over the years, IBM has considered porting mainframe tools to Unix and other open-systems platforms and migrating tools such as its Tivoli SAN Manager to the mainframe's ESCON and FICON topologies. But Russell says that while it may make sense to allow mainframe and open-systems tools to share reporting data such as allocation and utilization rates, there's not a large user demand for tools that would actively manage both mainframe and open-systems storage resources from the same console. Says Russell: "So far, that sounds like a better academic exercise than a customer-accepted one."
This was first published in February 2004