With Sun’s new Jiro technology, you can develop sophisticated Java and Jini-based applications that manage distributed resources
These days, the management of distributed resources primarily entails status monitoring. While the increasing instrumentation of these resources has allowed administrators to view their status through a common console or management framework, today’s standard operating procedure is more reactive than anticipatory.
Even though events are generated for such problems as failures, performance crises, and capacity limitations, the sheer number of these events in any reasonably sized environment can make it difficult to understand the root cause of a problem. Event-correlation engines can help, but often themselves introduce more complexity. Considering all this, a new design model is needed to significantly reduce the costs and complexity of managing distributed resources.
In order to automate the management of these distributed resources, such automation software needs to execute on multiple platforms distributed across the enterprise. No single management station can scale to the required size for this automation or provide the robustness and reliability required. Thus, organizations more and more often turn to Java for management, not only for use in Web-based graphical user interfaces (GUIs), but also as the infrastructure for the management applications themselves. To achieve the required platform independence, Sun recently introduced its Jiro technology.
Using Jiro for management
Jiro implements an infrastructure for creating integrated and automated management software in a distributed, cross-platform environment. That infrastructure, a standard extension to the Java platform, is specified by the Federated Management Architecture (FMA). Jiro goes further than just platform independence, however, and introduces Jini-connection technology for distributed management across a network. Jini’s leasing, for example, provides a mechanism for allowing management services to come and go in the network, and provides the software that uses these services to recover the associated connections.
Moreover, Jiro introduces a middle tier of management between the thin-client Java GUIs popular today and such Java-based agent technologies as Java Management Extensions (JMX) and the Java Dynamic Management Kit (JDMK). (For more on management issues, see Max Goff’s Java management series in JavaWorld; there are links in the Resources section below). This middle tier is where the automation of management can take place, as seen in Figure 1.
The requirements for this middle tier were determined by an analysis of distributed management and the resources that need to be monitored and controlled. Each resource, whether it is a physical device or a software service, consists of a functional part and a management part. The functional part performs the functions of that resource, such as routing packets or storing data; the management part configures and controls the resource.
There may be several resources processing the data as it moves from the application to its eventual destination — a disk drive, for example. The functional part of these resources through which the data passes is called the data path.
The associated management, or control, parts of these resources can be thought of as a control path, separate from the data path that passes packets or stores blocks. If a resource is capable of being managed remotely, the control can be either in-band, competing for resources shared with the data path, or out-of-band, using a separate network and ports.
Separating the control path from the data path
Jiro is not intended to implement software that sits in the data path, but rather focuses instead on enabling the automation of control path operations. The resources, through their agents and administrative APIs, expose this control path. Jiro takes advantage of existing standards for such management interfaces as the Internet Engineering Task Force’s SNMP protocol, and the Distributed Management Task Force Common Information Model (CIM) standard for Web-Based Enterprise Management (WBEM).
Federated Management Architecture
As noted above, Jiro is an implementation of the FMA-standard Java extension. The FMA, which became a final specification in January, specifies the extensions to Java necessary to support a middle tier of management software that automates the administration of distributed system, network, and storage resources. The specification and a reference implementation of FMA are available on the Jiro Website (see Resources).
Partitioning the management environment
Jiro divides a management environment into domains. Each domain has only one logical shared management server (a Java Virtual Machine running the Jiro services) that represents the domain as a whole. Other, private management servers can host management services that are specific to their hosts (such as an application server or embedded device). The servers (including the shared server) can be replicated to achieve higher availability. Together, these servers form an intradomain federation for the management domain. The shared management servers can also communicate with each other in a strictly hierarchical fashion to form an interdomain federation; in this way, enterprise-scale management systems are possible. This federation of management servers and hosted services is the key to the scalability and reliability of the Jiro technology.
The management servers in the Jiro technology — called stations — host management services, which are network-enabled Jini services. They can easily be located through the Jini Lookup Service. Some of these services are static in nature, offering basic services that all management software needs. Most of the services, however, are dynamic, representing the management interfaces of distributed resources and higher-level management software to the network. The dynamic management services are also reusable software components that can be combined to create complete management solutions.
Static management services
Static Jiro management services — known as FederatedBeans base services — are a guaranteed part of the environment in a management domain. The base services include transaction, controller, logging, events, and scheduling. They are available for use by the clients and services belonging to a management domain, and do not depend on the dynamic services model. In other words, the services stand alone and are good Jini technology citizens in their own right (as defined by the Jini technology specification). There is only one of each type of service available in each management domain.
These base services are located with the ServiceFinder convenience class, as shown below:
public final class ServiceFinder
{
private ServiceFinder() {}
public static TransactionManager
getTransactionService()
throws ServiceNotFoundException;
public static ControllerService
getControllerService()
throws ServiceNotFoundException;
public static LogService
getLogService()
throws ServiceNotFoundException;
public static EventService
getEventService()
throws ServiceNotFoundException;
public static SchedulingService
getSchedulingService()
throws ServiceNotFoundException;
...
}
ServiceFinder‘s methods return the Jini service proxy for each of the base services, as registered in the Jini Lookup Service. Let’s look at these services in more detail:
- The Transaction service is a Jini transaction manager serving a particular management domain.
- The Controller service provides for the reservation of ownership within the management domain. This allows a single point of control for management and helps prevent inconsistent configurations.
- Management software can use the Log service to log decisions and state changes, as well as to maintain audit trails.
- The Event service provides a set of topics to which management services can post and listen. This allows management services to react to both changing conditions in the environment and decisions that other management services have made.
- The Scheduling service allows a management service to perform periodic or scheduled operations, such as polling.
Dynamic management services
The FederatedBeans dynamic services model extends Java’s Remote Method Invocation (RMI) to support the higher level of abstraction appropriate for management applications. The abstractions also reduce the time it takes to learn distributed programming, handling many of the mundane tasks normally associated with RMI. The added abstractions include:
- The propagation of contextual information, including security and controller information
- Reference fault rebinding, to allow management servers to be recovered on a host other than the one on which they were started
- Additional management capabilities (security, transaction, controller) that can be added to any Jiro-based component
- Transactional persistence
- Remote class method (procedural) invocations
- Remote object instantiation
A Proxy (class or object), created during the development process for each service, implements these abstractions. This allows a client to call methods on the Proxy in one JVM that are invoked on the referent class or object in another JVM. This Proxy is registered with the Jini Lookup Service as the Jini service Proxy for the dynamic management service. Thus, other dynamic management services can use that service from wherever they are in the domain. This is illustrated in Figure 2.
Distributed management software that takes advantage of this model can thus be more scalable — that is to say, it can be distributed over multiple machines if necessary. Higher availability can be achieved by restarting the management software on another machine in case of failure. This summer, Sun will release Jiro as a commercial product version of the FMA reference implementation; the released version will feature enhanced scalability and performance, as well as better installation and configuration capabilities.
From monolithic applications to components
Jiro introduces a new model for management software. Jiro encourages the development of reusable components, rather than the monolithic applications that are usually developed today. Jiro components can be produced by multiple vendors, who can either assemble them into solutions themselves, or allow other developers to assemble solutions that were not envisioned ahead of time.
This reusability means a shorter time to market for solutions and less repetitive work for developers; customers benefit from more functionality created in less time. It also means that more time is spent on creating higher-level management solutions and less on gluing pieces of functionality together. Furthermore, developers are freed from creating infrastructure; instead, they can devote their time to truly creating value for their customers.
A management automation example
To see how this would work in practice, let’s take an example from the management of storage resources. Often, an administrator will use volume-management software in order to expand the storage space underlying a filesystem or database. When the filesystem runs out of space, the administrator can add more by adding another disk, keeping the applications running and available. In order to have the highest application availability possible, the administrator will typically set up an alarm that pages her when an out-of-space indication occurs. This leads to a reactive management style, in which the administrator’s daily tasks consist mainly of reacting to problems in the system and initiating repairs.
Now let’s see how building a set of components in Jiro can help our administrator get beyond the reactive mode of management so that she can spend more time improving the environment. The first set of Jiro components that need to be developed for these situations are called Management Facades. These specialized components allow other components in the Jiro technology environment to monitor and control the managed resources. In addition, thin-client Web GUIs can use these components to give the administrator a complete view of her resources.
The resource vendor typically develops the Management Facades for its products that enable the products to be managed by Jiro-based software. These components, which must conform to the FMA and the standard JavaBeans conventions, are called FederatedBeans components. They will typically use a standard protocol, such as SNMP, to talk to the resource (in the case of a device or system) or native library (in the case of software). They then expose an interface with a rich set of configuration and control variables and metrics that can be used by other FederatedBeans components.
In our storage example, we’ll need Management Facades for the disks, volume manager, and filesystem. If the disks were in a storage network, we would additionally benefit from a Management Facade for a fabric switch. We’ll create two FederatedBeans components for this example. The first component maintains a pool of spare disks that can be used for multiple applications and hosts in the storage network. It is capable of allocating these disks on demand and controlling their connection to a host by using the fabric switch’s Management Facade. We will call this component the Storage Pool Bean.
The second FederatedBeans component will monitor filesystem utilization and try to predict when the filesystem will run out of space. This process could use a method as simple as a high-water mark, or as complex as an analysis of previous usage patterns. We will call this component the Infinite Disk Bean. The relationship of the FederatedBeans components to the Management Facades is shown in Figure 3.
The Storage Pool Bean
The Storage Pool Bean handles the allocation of disks between the various hosts in the storage network. It exposes an interface that allows other FederatedBeans components to request allocation of a disk to a given host for use by storage software or applications. When new disks are added to the storage network, the bean notices the new disks and adds them to its pool. It will keep its pool of disks in a special zone on the storage network by controlling the fiber channel fabric switch through its Management Facade. Finally, it exposes an interface that allows disks to be returned to the pool.
Infinite Disk Bean
The Infinite Disk Bean sees to it that an application never runs out of space. This adds to application availability without overprovisioning. Its job is to tune the capacity of the available storage to the application’s need. It accesses usage information from the filesystem’s Management Facade and tracks its usage over time. After predicting an out-of-space condition based on the history of past usage, it then calls the Storage Pool Bean to get a disk from its pool.
When the Storage Pool Bean gets the request for the disk, it calls the switch’s Management Facade to change the zone of the newly allocated disk to that of the host. It next creates a device driver entry for the disk on that host and instantiates a Disk Management Facade as a single point of control for the new disk. The bean then returns a reference to the new Management Facade back to the Infinite Disk Bean.
The Infinite Disk Bean next calls the Volume Manager Management Facade to add the new disk to the RAID stripe used by the filesystem. Lastly, the bean causes the filesystem to grow to its new size through the filesystem Management Facade. The bean could also implement a policy for reclaiming disks based on usage as well.
Conclusion
The above example shows how Jiro makes possible software that can increase availability and help reduce the cost and complexity of management. The FederatedBeans components that are created are also dynamic Jini services that are available throughout the network. The new paradigm for management software is multiple-vendor creation and reuse of these FederatedBeans components. The Storage Pool bean in our example could also be used by a component that consumes disks due to failure predictions, for example.
