Jiro Jams! - Product Information

Computer Technology Review, April, 2001 by Christine Chudnow

SAN and SAN customers begin to see the payoff.

SAN vendors are responding to customer demands for vendor heterogeneity (well unless you're a well-known proprietary outfit whose initials are E-M-C). Up until now these multi-vendor solutions have focused on point-to-point connectivity or managing specific groups of devices. Sun Microsystems' Jiro technology allows a different approach to interoperability in storage area networks: it works with both hardware and software, and offers platform-independent management and connectivity to large networks of distributed resources such as SANs.

It's misleading to talk about Jiro as if it were a Sun product, for it's neither a Sun property nor a product. Jiro is a middle-tier implementation of the Federated Management Architecture (FMA) specification. Sun established the parameters and initial process, but sought to separate the specification from a vendor-specific identity, the same way it had approached the Java programming language. It turned over spec development responsibilities to the Java Community Process Program, which formed an FMA expert group including Sun, QLogic (Ancor at the time), Exabyte, Fujitsu. Hitachi, Legato, Quantum, StorageTek, and VERITAS.

The FMA spec provides a communications standard for applications, services, and devices across a heterogeneous network. This results in a dynamic services model as well as basic management services including events, logging, lookup, scheduling, and transactions using common APIs. Jiro 1.0, an implementation of FMA, was released concurrently, and is now in release 1.5. Sun and other vendors hope Jiro provides a solution to developer desperation over integrating numerous multi-vendor devices and applications into SAN management products. With Jiro-integrated components, the developer does not need to write separate routines and drivers for each device or application.

Jiro technology makes up the middle layer of a widely accepted three-tier architecture. The three tiers include the presentation or client tier, the services or management logic tier where Jiro resides, and the agent or managed resource tier. Jiro provides a set of APIs for developing FederatedBeans components, base management services, and a Runtime Environment to integrate the beans into management solutions (Figure 1).

FederatedBeans is a component type that provides both dynamic network management services as well as Management Facades (MF). Vendors write an MF for a device or application in order to offer its interface to the management domain's lookup service, making it available to all other resources and clients within the domain. Policy-based beans help interpret the lookup via the middle tier.

To demonstrate such an environment, Imation, QLogic, VERITAS, and Sun teamed to build a typical SAN configuration using a SAN switch from QLogic, StorEdge devices from Sun, and VERITAS file system and volume management software. Each SAN device or application had an attendant MF built by its respective company, and Imation provided Beans (pun alert).

The beans created and managed a virtualized environment. The first policy bean watched specified volumes and alerted the system when the volume neared its capacity. The second policy bean managed available storage by dividing it into allocated and free storage devices. Upon a capacity alert, the storage pool requested an available disk array from the QLogic switch, at which time the VERITAS MF handled data allocation and transfer.

Management Services

Jiro itself provides a basic set of beans-based management services to the istributed environment. Using FederatedBeans, developers may create and distribute additional management pieces across the network. These common additional services include backup, file monitoring, failover, and automatic configuration. The base management services include:

* Lookup service. Registers and locates the static and dynamic Jiro technology services available in the management domain.

* Transaction service. Coordinates operations and confirms correct execution.

* Event service. Supports synchronous messaging for management services.

* Logging service. Logs actions and events from distributed resources within the management domain.

* Scheduling service. Schedules one-time and repetitive event generation across the domain.

* Security service. Provides additional control over access to managed resources.

In addition to FMA, Jiro embraces other standards including the Web Based Enterprise Management (WBEM) initiative's Common Information Model (CIM). It also works with SNMP devices, and is bundled with an SNMP manager.

The WBEM initiative attempts to manage the complexity and expense of managing heterogeneous networks by standardizing management information across platforms. WBEM works with an integrated set of standard-based management tools leveraging CIM, and using such technologies as XML and HTTP. Sun-sponsored Java WBEM complements Jiro, and includes Java client APIs that enable Jiro components to request WBEM operations from the CIM Object Manager. Jiro's distributed management capability adds value to WBEM's services, and WBEM's common instrumentation model makes Jiro technology more flexible (Figure 2).