Managing Storage On The San With Jini.

For a moment, try to put yourself in the shoes of an automated tape library company. These companies' products are inherently multi-vendor in that they must work with other vendors' servers, network infrastructures, and software. These companies spend a lot of time and energy on interoperability.

Now, imagine that you've just discovered a problem that requires a firmware update to your flagship model. Moreover, in installations where your library is bridged to a Fibre Channel SAN, the bridge's firmware must be updated as well.

You can distribute new firmware to your customers on CD-ROM. But how can you be sure that every customer receives and installs the upgrade? Will the right components (and only the right components) be upgraded? Will the upgrades be done in the right order? Will they disrupt your customers' operations?

Jini technology offers answers to these questions. You make the upgrade available to your customer on the Internet. Your customer downloads and executes the upgrade, which registers updated Jini services on his network. Because your Jini-aware tape libraries and bridges have pre-registered for such events, the customer's Jini Lookup service notifies them of the firmware upgrade availability. The libraries and bridges that need the upgrade download the new code. The upgrade procedures themselves verify model and revision numbers before executing, request authorization to proceed from the network administrator, and interoperate to make sure that upgrades occur in the right order. Upgrades are correct, complete, non-disruptive, and largely automatic.

In a nutshell, this is the essence of Jini, the technology for composable computing originally created by Sun Microsystems and now being enhanced by industry-wide Jini communities of equipment suppliers. Jini enables loosely coupled federations of network-connected intelligent devices that offer services to each other. Traditional networks require that nodes have a prior knowledge of services offered and how and where to request them. Jim allows servers to register themselves with a Jini Lookup service and upload the Java code for the services they provide. Clients that need a particular service can use the Lookup service to locate the server and download the Java code required to interact with it (Fig 1).

The Jini technology launch emphasized networked personal devices such as PDAs and cell phones. This perhaps obscured Jini's promise for solving some of today's most acute enterprise computing and storage problems. Jini can significantly ease management of SAN and other networked storage configurations. In the longer term, it may also result in fundamental changes in the way storage is designed, configured, and used.

AN OVERVIEW OF JINI

Experienced system administrators appreciate the complexity of the setup and configuration required before a networked device can perform useful work. To utilize a new network device:

* the device must be named so that clients can refer to it

* the right device drivers must be located and loaded

* device configuration parameters must be specified

Jini automates setup by providing an infrastructure that enables "services" (e.g., storage devices or subsystems) to announce themselves on the network and potentially to supply their own drivers to clients.

Jini is Java-based. Java's "write once, run anywhere" property means that Jini services can be made available throughout heterogeneous networks with little or no porting effort. Jini runs on the small processors that are typically embedded in storage devices.

The core of Jini is its Lookup service. As Fig 1 illustrates, the Jini Lookup service is a central registry of services available on the network. Each registered service has a Service item consisting of Java code that a client would execute to invoke the service, either locally, remotely from a device on the network, or as a composite of both. Service item code is written in Java and typically uses Java Remote Method Invocation (RMI) to invoke the service from the provider.

The Jini Lookup service itself is implemented in Java so it can execute on any Java2-compatible Java Virtual Machine (JVM). When a Jini-aware device joins the network, it first multicasts a message looking for Lookup services. If none reply, the device has the option of creating a Lookup service itself. Once a Lookup service is established, the device can upload its Service Entry to the Lookup service, making its drivers and interfaces available to clients.

A Jini Lookup service can be searched for a specific Java type (object) or for a template. Templates enable searches for objects with specific values in certain fields. Using a Jini template to locate a service is conceptually similar to using the Yellow Pages. A person with a plumbing problem would look up plumbers (a type), and filter out everyone not in his local area. Similarly, a workstation on a Jini-enabled SAN that required storage capacity might query the Lookup service for storage devices with the performance and availability characteristics it required.

JIM AND STORAGE

From a storage standpoint, the two key capabilities enabled by Jini are:

* freely adding and removing devices in a loosely coupled computing federation

* devices supplying their own device drivers and interfaces

Between them, these two capabilities will ultimately greatly increase the flexibility of SAN-attached storage, both in workgroups and across the enterprise. Perhaps the most obvious Jini storage application is management of storage devices and subsystems in a SAN. Because they support large numbers of attached devices widely distributed and shared by more clients, SANs inherently increase storage management complexity.

Jini-aware storage devices can register their own management interfaces with the Jini Lookup service so that a management application can download them. Jini's distributed event notification mechanism makes management applications aware of device addition and removal. With standard interfaces like the Distributed Management Task Force (DMTF) Common Information Model (CIM), devices from multiple vendors can be managed from a single application.

Alternatively, a Jini-aware device may upload a management applet with its own Java GUI into the Lookup service. This allows a vendor to offer new and unique management capabilities to a wide variety of computing platforms.

Jini will also simplify SAN configuration management. In large distributed storage environments, asset tracking and firmware revision management are costly and error prone. As described in the hypothetical scenario that began this article, firmware upgrades can be registered with a Jini Lookup service as "upgrade services." Distributed event notification informs Jini-aware storage devices, so that they can invoke the appropriate upgrades. Accurate configuration information and consistently updated firmware can thus be achieved automatically.

With enhancements being developed today, Jini will eventually support storage device customization through dynamically downloaded Java services. SAN-attached storage devices will no longer be limited to a factory-installed firmware. For example, devices detecting undiagnosable failures might download extended diagnostics. Relational database assists could be downloaded into RAID controllers to mine data without using SAN bandwidth. Jini-aware tape drives might download backup daemons to a disk drive and provide host-free continuous backup or hierarchical storage management.

Such customizable device behavior will require some degree of interface standardization so that SAN applications and devices can interoperate. In addition to management interfaces, two types of storage interfaces must be standardized for Jini in the data path:

* A Storage Device Interface, which allows downloaded services to access and manipulate the storage device. This is the interface for reading and writing data securely in a network environment.

* A Storage Service Interface, which provides a basis for the Lookup service entries supplied by the storage devices themselves.

REALIZING JINI IN STORAGE

Of course, Jini will not become universal overnight. It will take time for the underlying facilities required by Jini to appear in storage devices.

The primary enabler for Jini is a JVM. Java-enabled devices can act as proxies or legacy devices. (For example, a server with a JVM can act as a proxy for a disk drive). The full potential of Jini will be realized, however, with devices that contain embedded JVMs so that service interface objects can be downloaded to them.

Several popular embedded kernels used in storage controllers and devices support JVMs. Devices that use these kernels could support Java and, therefore, Jini today. In addition to enabling Jini, a JVM in a storage controller would enable the controller to act as a proxy for disks or tapes attached to it.

The second requirement for Jini is a suitable protocol stack. Jini is officially "protocol neutral" and in principle can be implemented on any protocol stack that supports peer messaging. Given its universality and maturity, however, TCP/IP is clearly the protocol of choice for storage developers wishing to build Jini-enabled subsystems.

TCP/IP for Fibre Channel is in development. The first storage "devices" to support Jini, however, will probably be Ethernet-attached filers. Filers already use TCP/IP to communicate with clients and most are based on kernels for which Java Virtual Machines are available.

With few exceptions, filers support multiple disks and "smart" enclosures. A filer's processor could act as a Jini proxy, making it possible for storage devices that are not directly attached to the network to be Jini-enabled.

JINI TODAY

Jini originated with Sun Microsystems. It was apparent, however, that federated computing would only succeed if it were universally adopted. Sun has, therefore, made Jini technology publicly available and fostered the development of Jini Communities, associations of companies whose purpose is to develop Jini standards in areas of interest to them. In January of 1999, the first of these, the Jini Printer Community, was formed.

In early April, a Jini Storage Community met and decided to work together to define standard Jini interfaces for: block devices, file devices, and management.

A CALL TO ACTION FOR STORAGE DEVELOPERS

Commitment from a small number of key storage industry movers could lead to rapid widespread adoption of Jini. Storage product developers can prepare for the possibility of rapid adoption by:

* Joining the Jini Storage Community and contributing to standards for Jini SAN services. There is no monetary cost and joining makes Jini specifications and base technology reference implementations available for prototyping.

* Executing a Sun Community Source License to obtain the V1.0 Jini release and begin building Jini expertise and prototype services.

* Storage subsystem (filer, RAID controller, and tape library) developers should begin incorporating JVMs in their products and working with disk and tape drive vendors to implement proxy services for devices.

Jini offers a solution to some of the key problems facing SAN developers and users today.

Jini for storage (Fig 2) is on an adoption cusp. The Jini Storage Community has formed and is moving to define service standards. Now is the time for storage product developers to "get in on the ground floor" of this technology wave.

Paul Massiglia is the network storage strategic marketing manager of Quantum Corporation (Milpitas, CA) and Ken Gibson manages Solaris storage driver development for Sun Microsystems, Inc. (Broomfield CO).