Inside Jiro storage management

Posted on February 02, 2000

RssImageAltText

Jiro technology is one way for developers and administrators to simplify storage management in heterogeneous environments.

By Tad Lebeck

You can't pick up a trade magazine-particularly this one-without reading about storage area networks (SANs). However, for heterogeneous SANs to proliferate as quickly as pundits predict, standards are necessary. Jiro management technology is one step in that direction. It enables the network not only to "see" heterogeneous storage, but also to interact with and react to other components and services on the network based on predefined conditions.

"System and network administrators are starting to include SANs in their budgets," says Paul Mason, vice president of infrastructure software research at International Data Corp. (www.idc.com), "but there are still challenges in Fibre Channel interoperability standards and in the management of heterogeneous devices. It all comes down to manageability. Jiro technology has the potential to unlock the door to new possibilities for SAN management."

Click here to enlarge image

The Jiro Expert Group-comprised of vendors who support the Jiro management specification-demonstrated a network-centric approach to dynamically manage heterogeneous storage networks at last year's Jiro Developer Forum and Storage Networking World conference, which was co-sponsored by the Storage Networking Industry Association (SNIA).

The demonstration, which was developed in less than a week, consisted of a variety of vendors' disk arrays and tape libraries; Unix and NT servers; volume management code; and backup software. The two disk arrays were mirrored, and an error was simulated in the first array. The volume manager reacted automatically by initiating a backup, bringing a new array online. The backup software was then instructed to back up the array with the "good" data, and the volume manager requested the new array to be zoned and to replace the now disabled array as the new mirror.

The Jiro environment acts as the middle tier, or management logic layer, in a three-tiered architecture. It interacts with resources via existing, emerging, or proprietary interfaces, eliminating the need for a common interface language among the components (see above figure).

At the managed resource layer, the Jiro environment references the Common Information Model (CIM), a Distributed Management Task Force (DMTF) standard that provides a method for modeling computer-related entities such as storage resources. The CIM standard specifies rules for an information model and defines managed objects and their associations.

"We find it very interesting to put Jiro technologies and CIM together," says Walt Hinton, chief strategist at StorageTek. "We're exploring new products that leverage Jiro technology to simplify integration with external components and for faster time to market."

Communication between resources and the Jiro environment occur through the Web-based Enterprise Management Protocol (WBEM), a DMTF standard that defines a protocol for talking to CIM-based object implementations, or through Simple Network Management Protocol (SNMP), the standard agent-layer communication protocol. (For more information, see "Using CIM and WBEM for enterprise storage management," InfoStor, December 1999, pp. 32-34.)

Like CIM-based products, SNMP-managed resources can use Jiro technology when SNMP traps indicate a state change, retrieving the information across the network. Devices based on standard management information bases (MIBs) are suited to automation because they can be represented as an abstract class instead of a proprietary object. Devices using proprietary protocols can also run in the Jiro environment.

"Because Jiro technology is based on Java technology, it runs on all Unix and NT platforms. We want to be able to make our products available to end users on whatever environment they need," says Ben Preece, lead engineer for network and systems management products at Ancor Communications. "We reused classes in the Jiro environment that we had already written in for Java-based applications. This reduces the amount of effort that we have to put in."

"Jiro technologies represent an exciting opportunity to solve some serious storage management issues in an elegant, easy, and quick way, and to solve them in cooperation with other vendors who have the same goal," says Robert Edwards, principal engineer at Hitachi Computer Products. "Because of the potential, Hitachi is currently investigating how to best migrate to Jiro technologies."

The Jiro runtime enables components in the middle tier to run across a network of distributed Java virtual machines, dynamically distributing management functionality while providing an organized federation of devices that appear as a single, logical unit. FederatedBeans components (commonly called components or beans) are groups of objects written in Java that are network-centric and are designed to work together to deliver and control management services across a network.

Vendors, regardless of their resource-level strategy or software framework, can create FederatedBeans components, providing users with added functionality, as well as interoperability with other products.

A management console or application can interface with and gain access to all of the resources in the Jiro-enabled storage network. Jiro technologies take consoles past a centralized view of management, allowing management functions to be distributed and controlled across the network. The Jiro environment isn't a management console, but it allows consoles to utilize the Jiro services and interoperate with all components in the Jiro environment.

Jiro technologies allow developers to focus on adding functionality to their products, rather than spending time developing pieces of infrastructure that end users never see. Management functions such as logic, scheduling, fault notification and other events are services provided in the Jiro environment. Developers can use these functions to enable their solutions. It is also relatively easy to enable a storage resource to work in the Jiro environment. Vendors need only develop a managed object (a FederatedBean component) that provides a representation of the resource or application, allowing the resource or application to be managed in the Jiro environment.

The promise of easy control and efficient management of storage-most importantly, a simple way of monitoring and backing up heterogeneous storage devices-is one of the reasons SANs are so appealing. Jiro technology solves this problem and makes it possible to enable decisions before a system administrator is informed of a potential error.

Today, similar functionality would be an array with an SNMP agent managed by a console that might send an SNMP trap as an error/warning event when a detectable reading crosses a predetermined threshold. An icon might change color showing the error, but the system administrator would have to drill down to discover the problem.

In the Jiro technology demonstration, a heterogeneous storage network included a disk from Fujitsu; disk arrays from Hitachi, StorageTek and Sun; tape libraries from Exabyte and StorageTek; a Fibre Channel switch from Ancor; Sun Solaris and Microsoft Windows NT servers; Veritas volume manager software; and backup software from Legato and Veritas. A disk failure scenario was incorporated into the demonstration to show how Jiro-enabled hardware and software can collaborate to respond automatically to failures in the storage environment.


Example shows a health-monitoring bean initiating events once predefined thresholds are crossed. Other components, such as an emergency backup bean, can subscribe to these events and react as necessary.
Click here to enlarge image

The demonstration illustrates how vendors can build FederatedBean components that understand devices at the resource level, observing the environmental conditions of the array (see figure).

For example, a health monitor bean can initiate events once predefined thresholds are crossed. Another component, such as an emergency backup management bean, can subscribe to these events and react as necessary.

For example, the health monitor bean would detect if the temperature of the array crosses 100°F (the pre-defined threshold). The emergency backup bean logs that it received this event and uses the reference to the array that is contained within the event to determine the capacity of the array. It also uses the lookup service to discover a tape library with sufficient unassigned capacity and a backup utility to back up the array. Throughout this process, each step is logged and an event is received by the system administrator notifier bean and sent as an e-mail or a page to anyone-or any other "bean"-that subscribes to that type of event.

A rise in system temperature is a rare but critical event. By the time a system administrator using today's management consoles checks the temperature in the server room and starts the backup process, it is too late because the system administrator would have to manually perform all of the steps: look for a backup utility, find a tape library, etc. Even if the administrator did recognize there was going to be a failure, there wouldn't be enough time to do a one-time backup.

Configuration beans like the "health bean" in this example make the interface standard across the network-the Holy Grail for administrators that manage large information centers. Components of a similar type present a common interface to the network, enabling automated, enterprise-class solutions.

Backup windows, failure procedures, and the lack of dynamic backup scheduling are issues that continue to plague system administrators. Jiro technology is one way to take control of management logic, enable more modular storage solutions, and provide simpler "best-of-breed" solutions. As the demonstration proved, the Jiro environment can enable automatic failure handling, scheduling based on usage patterns or priorities, and many other procedures high on a system administrator's wish list.

In the classic definition, the Jiro-enabled demonstration was a SAN, but the distributed, network-centric Java object technology provided by the Jiro architecture promises to go beyond what we think of SANs today. It is robust enough to accommodate the "next big thing" in storage technology, whatever that may be.

Tad Lebeck is chief technical officer at Legato Systems Inc. (www.legato.com), in Palo Alto, CA.


Comment and Contribute
(Maximum characters: 1200). You have
characters left.