Aperi Storage Management Project

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare the intent and scope of a proposed Technology PMC Project called the Aperi Storage Management Project, or Aperi. In addition, this proposal is written to solicit additional participation and inputs from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.aperi newsgroup.

Introduction

The Eclipse Platform has not only proven effective for rich client-side applications, but it has also captured the attention of the server-side development community. Its extensible, layered component model and clean interfaces are quickly evolving into a framework for enterprise application development. The success of Eclipse as an enterprise application framework, however, is largely tied to the success of the applications that exploit it.

Leveraging the Eclipse Platform, the Aperi project intends to develop an extensible storage management application framework and an initial set of exemplary, exploiting applications. The framework will include standards-based services for control, discovery, and monitoring of storage resources. Initial candidate exploiters include file system, fabric, tape, and disk management applications.

Enterprise management applications face unique deployment, scalability, and serviceability challenges (among others). The Aperi project seeks to overcome these challenges and further advance the enterprise readiness of the Eclipse Platform.

Background

The mission of the Aperi project is to create a vendor-neutral, open, storage management framework and to cultivate both an open-source community and an ecosystem for complementary products, capabilities, and services around the framework to promote greater consumer choice and foster competition. One goal of the Aperi project is to promote interoperability, eliminate complexity and incompatibility, foster greater opportunity for innovation, and provide a greater choice and added-value functionality for end-users.

The Aperi project will fulfill its mission by:

• Developing a set of representative applications that use this storage management framework to enhance the availability of tools and solutions for storage management;
• Promoting the vision of an open, standards-based, common storage management framework within the storage industry;
• Promoting compliance of this framework to the latest SMI-S standard specification and other appropriate standards;
• Providing test suites for compatibility verification of the framework and vendor-developed applications to help ensure multi-vendor application interoperability;
• Fostering projects that enhance or extend the framework and promote open standards;
• Enhancing the reach of the technology by recruiting companies to join the community.

The scope of Aperi covers the creation of:

• The Aperi Storage Management Framework architecture including the discovery of host, storage, and infrastructure components through SMI-S; maintenance of a coordinated database; a set of services including configuration, event and performance management; and to formalize the interfaces between the applications and the storage management framework.
• The Aperi software project:
  • An open source implementation of the Storage Management Framework;
  • Implementations of representative applications that utilize the framework and deliver end-user functionality for enhanced storage management;
  • Additional functionality in the storage management framework.

Architecture

The Aperi runtime environment consists of four process types:

• Management Server
• Management Console (GUI)
• Host Agent (Endpoints)
• Repository

Each process type extends the Eclipse Platform. Standards are leveraged whenever possible, including storage industry standards like SMI-S. Other communication standards like Web Services and SSL are also included. Extensibility, via the Eclipse extension registry is implemented throughout Aperi. Aperi’s commitment to open standards, an extensible component model, and component layering permits deployment as a standalone application or consumption & customization by various applications vendors.

Management Server

The management server maintains two functional layers:

• Aperi Framework Layer
• Aperi Applications Layer

Between the two layers exists the application-framework contract, a collection of well-defined interfaces – a potential standard.

The Framework Layer is based on technologies from the Eclipse Platform such as the OSGi implementation, the plug-in model, and the Extension Registry, and extends these technologies to include services that are fundamental to storage management, such as

• Discovery
• Monitoring
• Control
• Alert management
• Database interface

The Applications Layer consists of collections of features that provide coherent functionality in a specific area to users. The ‘applications’ are provided as plug-ins to the Framework Layer. The basic Aperi project will include applications that provide basic functionality in key functional areas for storage management:

• Storage subsystem management
• Tape library management
• Storage Area Network fabric management
• Basic file system capacity reporting

These applications provide a useful set of fundamental storage management functions, and are a base that can be extended to produce more advanced storage management applications.

Host Agent

Aperi uses agent-less management wherever possible, but can use a variety of agents to extend its capabilities. Foremost among these are CIMOMs implementing the SMI standard for storage management (http://www.snia.org/smi/home), which allow Aperi to manage storage hardware devices. The Aperi framework does not include SMI agents; instead, SMI agents are used as discovered in the managed environment. However, Aperi does include a host-based agent framework, and two subagents that run in this framework. The 'File system' subagent is deployed on hosts to provide reporting and discovery services for file systems visible to each host. The 'Fabric' subagent is deployed on hosts attached to Fibre Channel Storage Area Networks (SANs) and uses Fibre Channel protocols to provide additional discovery and management capabilities for SAN fabrics. The overall host agent framework is extensible via the Eclipse plug-in model so that additional subagents can be deployed in a single instance of the framework. The intention is not for Aperi to force a particular agent infrastructure on its users, but to be flexible about using what is discovered in the user's environment.

GUI Console

A shared, extensible GUI for storage management is an essential component of the Aperi project. We intend to evolve the user interface over time to an Eclipse Rich Client Platform (RCP) application, to better exploit the Eclipse extensibility model on the client side and to have a consistent extensibility model between the client and the server. The Aperi project will be seeded with a complete GUI covering all functions included in the initial donation to Aperi. This GUI is developed using Swing and includes secure login, role-based authorization, reporting and charting (using the Eclipse Chart Engine), and a graphical topology viewer for displaying storage area networks. The evolution of the GUI to a full implementation of the Eclipse RCP will likely center on the Aperi topology viewer and the BIRT reporting engine. There may also be interest from the community in developing alternative user interfaces, for example a CLI or web-based interface.

Data Repository

Aperi's database access routines are not specific to a particular RDBMS and it is expected that software vendors could provide support for commercial RDBMS used with Aperi. Aperi defines extension points for database integration. An initial implementation of this extension includes Derby – a pure Java, open source RDBMS.

The initial Aperi framework contains its own database access layer and its own extension points for connecting to alternative RDBMS. We are investigating the Eclipse Data Tools Project to see how we can transition to that framework.

Extensibility

The Aperi framework is intended to provide a fundamental level of storage management functionality to its users. These capabilities are useful in themselves for discovering, monitoring, and basic management needs, but are even more useful as building blocks for constructing higher-level management functions. We expect users to extend the Aperi framework at each layer of the architecture (GUI, server, and agent). By using the Eclipse plug-in model, higher-level management functions can extend the framework vertically. Users can also extend the framework horizontally. Examples of vertical add-ons include new features like performance management. Examples of horizontal add-ons include the broadening of existing features (ex: adding a new discovery protocol to the discovery feature). We expect that some of these areas may be filled by open source offerings contributed to Aperi in the future or by extensions that are developed and sold commercially. Our intention is to provide a common platform for storage management that allows many partners to come together and extend, creating a richer offering for users than any single vendor could provide on its own.

Organization

Equinox, Corona, and Enterprise Component Framework are projects intersecting “Eclipse as an enterprise platform” and “Eclipse on the server.” We will communicate with these projects and any others identified as within the Aperi scope.

The Aperi project will initially be a sub-project of the Technology Project.

Interested Parties and Committers

This section captures the list of organizations that have expressed interest in the project and/or its components, and as such will be updated periodically to reflect the growing interest in this project.

Rather than canvas the Eclipse community at large, the submitters of this proposal welcome interested parties to post to the eclipse.technology.aperi newsgroup and ask to be added to the list as interested parties or to suggest changes to this document.

Initial Set of Committers

Interested Parties