24-12-2010, 10:21 AM
[attachment=7603]
INTRODUCTION
Today's sciences and businesses depend on information a vast mountain of information. As the demand for storage to hold all of this continues to grow at phenomenal rates, the management challenges are growing too . In fact, the diversity of installed storage
systems and the wide distribution of those systems are on the verge of creating a crisis in
management, sometimes described as a “nightmare.”
The amount of management that needs to be done is also increasing . The cost of
management is one of the significant areas of rising cost in using computer systems. Since management is a continuing cost, it has a large influence on the assessment of “return on investment” (ROI). All aspects of a system need management: software, processors boards, options, network connections, storage devices and networks, modems, printers, and all the other pieces that are put together to make a “system.” Management, includes installation, configuration, asset deployment and inventory, performance monitoring, error and failure detection, upgrade and replacement; as well as more difficult things like capacity planning, service level contracts, load balancing, all of which may be controlled by policy decisions made by the owning organization. Because storage and storage subsystems are amongst the most complex parts of the management problem, as the storage systems often including processors, switches, and storage area networks, effective solutions to storage management problems are urgently required. Thus, the initiative surrounding the Jiro technology focuses its attention on storage management.
Developers lack standard middleware infrastructures for efficiently building capable
solutions for heterogeneous management tools, applications, and services. Further
complicating this situation, to provide storage solutions, developers must port their
products to multiple proprietary platforms, a costly, time consuming process.
THE JIRO TECHNOLOGY SOLUTION
The need for the Jiro technology is acute due to a storage landscape dominated by point products that do not interoperate, creating large islands of information that are difficult to integrate, complex to manage, or that actually prohibit cross-platform information management. The intent of the Jiro technology is to bring the benefits of community source processes to the development of storage management solutions. This platform, together with basic services and a component model, brings an order to the creation of the software that can automate or add intelligence to all management functions. The elements and their relationship are defined in the Federated Management Architecture (FMA)
The history of the Jiro technology activities starts with proposal made to Java language extension designed to make it easier for the developer to create new storage management applications, enable faster design cycles, lower development costs, and offer a wider market potential. It is further intended to alleviate the need to conform to multiple API’s and interface specifications. Following the requirements of the Java Community ProcessSM (JCP), a call for experts (CAFE) was issued, followed by the formation of the Expert Group, a work group made up of representatives from a number of interested industry leaders. The Group was convened under the terms of the Process, and the FMA Specification is the result of the work of that Group.
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).
APPLICATIONS
management automation
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 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.
