Jiro Jams!

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).

Market Outlook

Denise Shiffman, vice president of marketing for Sun Network Storage said, "From the inception of Jiro where we pulled together a group of eight or nine storage vendors to write the spec, we've now got a handful of vendors who have completed their work and gotten certified." Although she felt this was good market acceptance, some analysts believe acceptance has gone more slowly than Sun would have liked. Michael Karp, director of Storage Management Services at the HurwitzGroup said, "It's building slowly, not moving as quickly as they'd like it to. But it's gaining momentum."

Business customers reacted in a similar way to Java's introduction, which started off slowly in business circles while gaining momentum in the developer community. It eventually reached wide acceptance. Sun has introduced Jiro the same way with similar slow results, arguably not the best marketing decision. Certainly Sun is not the only vendor to encounter decision-makers' confusion when offering a highly technical solution. As Shiffman commented, "The biggest roadblock to acceptance is the amount of confusion and complexity out there, and the customer being able to interpret what's being told them and to make the right choices."

However, Karp commented, "The value proposition is simply not clear. In fact, the value proposition is probably not nearly as good a document as the technology deserves. In fairness, I'm raising the point about their lack of market visibility. However, they haven't over-hyped it, and that I think speaks to the integrity of the effort. Like all new standards Jiro is evolving."

If Jiro follows Java's lead, it will gain good market acceptance in the future, and perhaps prove instrumental in easing the pressures of developing for heterogeneous SANs. In the meantime, developers and SAN customers should be watching this space with interest.