Skip to main content
Jump to: navigation, search

Difference between revisions of "Aperi Device Server Design R2"

(Main Components of the Architecture)
(Installation and Configuration)
 
(33 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
Document Author: Christoph Reichert
 
Document Author: Christoph Reichert
 +
 +
Latest Update Jan, 2007
  
 
==Introduction==
 
==Introduction==
Line 15: Line 17:
 
The former device server consists of a service manager that starts up all components defined as "services" in a services.properties file and deployed them as webservices. The service manager itself was started as a servlet during initialization within a servlet container. Using the Eclipse/OSGi infrastructure the "services" will be redefined as OSGi services. A connector component will look for these services and publish their APIs as webservices. The code belonging to the service is defined as a OSGi bundle, so the OSGi container cares about the bundle lifecycle and service starting and stopping. Defining dependencies between the OSGi bundles and assigning them to different runlevels ensures the correct startup order of the bundles.
 
The former device server consists of a service manager that starts up all components defined as "services" in a services.properties file and deployed them as webservices. The service manager itself was started as a servlet during initialization within a servlet container. Using the Eclipse/OSGi infrastructure the "services" will be redefined as OSGi services. A connector component will look for these services and publish their APIs as webservices. The code belonging to the service is defined as a OSGi bundle, so the OSGi container cares about the bundle lifecycle and service starting and stopping. Defining dependencies between the OSGi bundles and assigning them to different runlevels ensures the correct startup order of the bundles.
  
The implementations of the existing serivce and component registrations on execution of java code (e.g add object and constants to registry hashtable). With Eclipse plugin registration this should migrated to a XML-property based registration wherever possible, to support lazy service initialization.
+
The implementations of the existing service and component registrations is done by execution of java code (e.g add object and constants to registry hashtable). With Eclipse plugin registration this should migrated to a XML-property based registration wherever possible, to support lazy service initialization.
  
This document does not cover the extensibility of the Aperi common services (like logging or job handling) but refers to needed extension points that have to be available. It is assumed that similar common services from the dataserver needs to be merged into single Aperi infrastructure components. Additional, existing plugins from other eclipse projects that provide such "common services" should be reviewed and included into the base Aperi infrastructure.
+
This document does not cover the extensibility of the Aperi common services (like logging or job handling) but refers to used extension points. It is assumed that similar common services from the dataserver needs to be merged into single Aperi infrastructure components. Additional, existing plugins from other eclipse projects that provide such "common services" should be reviewed and included into the base Aperi infrastructure.
  
 
==Design Rationale==
 
==Design Rationale==
Line 25: Line 27:
 
==Open Items==
 
==Open Items==
  
*Agent: The common components between agent and device server needs to be identified for server/agent communication
+
*Component shutdown/removal: There is no common strategy to deregister device server components. How can a component or the OSGi service container know if parts are used by running jobs or required by managed devices?
*Component shutdown/removal: There is no common strategie to deregister device server components. How can a component or the OSGi service container know if parts are used by running jobs or required by managed devices?
+
 
*Detectability: Detectability service is highly dependent on the underlying database schema, so we should consider to treat it as a database component. Detectability is not designed for dynamic extensibility, there are a lot of numeric constants and if-then-else constructs that need more in-depth analysis and design.
 
*Detectability: Detectability service is highly dependent on the underlying database schema, so we should consider to treat it as a database component. Detectability is not designed for dynamic extensibility, there are a lot of numeric constants and if-then-else constructs that need more in-depth analysis and design.
  
Line 44: Line 45:
 
===Device Servers Platform Components===
 
===Device Servers Platform Components===
  
The Infrastructure components have to be moved from the Device-Server to the Aperi platform. Some main building blocks need to be defined as Eclipse Plugins that the device-server apps can use and extend. Others are just used as-is and will not be separated in different plugins in this phase.
+
The Infrastructure components have to be moved from the Device-Server to the Aperi platform. Some main building blocks need to be defined as Eclipse Plugins (OSGi Bundles) that the device-server apps can use and extend. Others are just used as-is and will not be separated in different plugins in this phase.
 +
The base code that is used together with Data server is located in the org.eclipse.aperi.common and org.eclipse.aperi.common.utils project.
 +
Some OSGi services are defined there and started by the org.eclipse.aperi.server.device bundle
 +
=====Device Server - org.eclipse.aperi.server.device=====
 +
{| border="1"
 +
!Component
 +
!Description
 +
!Comments
 +
|-
 +
|OSGi Bundle name
 +
|org.eclipse.aperi.server.device
 +
| -
 +
|-
 +
|OSGi service
 +
|org.eclipse.aperi.sanmgmt.dbconnparms.interfaces.IConfigService
 +
| included interfaces:
 +
* org.eclipse.aperi.sanmgmt.dbconnparms.interfaces.IConfigService
 +
|-
 +
|Webservice name
 +
|ConfigService
 +
| -
 +
|-
 +
|consumed Extension points
 +
| none
 +
| -
 +
|-
 +
|defined Extension points
 +
| none
 +
| -
 +
|-
 +
|}
  
====Discovery====
+
====Discovery - org.eclipse.aperi.discovery====
  
(org.eclipse.aperi.discovery)
+
Aperi Discovery is a framework to detect SAN devices and query their configuration data. The detection and identification of new devices or their providers is called "discovery", collection of the configuration data of a specific storage device is called "probe".
Aperi Discovery is a framework to detect storage devices and query their configuration data. The detection and identification of new devices or their providers is called "discovery", collection of the configuration data of a specific storage device is called "probe".
+
  
 
The abstract class DiscoverProcess is the main extension point for different process steps that has to performed for a discovery or device probe. If more than one DiscoverProcess step needs to be performed for a discovery, the IStep Interface provides a container for combining and executing different DiscoverProcess' in the required order.
 
The abstract class DiscoverProcess is the main extension point for different process steps that has to performed for a discovery or device probe. If more than one DiscoverProcess step needs to be performed for a discovery, the IStep Interface provides a container for combining and executing different DiscoverProcess' in the required order.
Line 56: Line 86:
 
Plugins that want to extend the Aperi Discovery has to implement the required DiscoverProcess and register them within the Router.
 
Plugins that want to extend the Aperi Discovery has to implement the required DiscoverProcess and register them within the Router.
  
=====Extension Points=====
+
=====Discovery plugin=====
{- border="1"
+
{| border="1"
!Component
+
!Component
!plugin
+
!Description
!Extension points
+
 
!Comments
 
!Comments
 
|-
 
|-
|Discovery
+
|OSGi Bundle name
 
+
|org.eclipse.aperi.discovery
    * SLPDiscovery
+
| -
    * SNMPScanner
+
    * DiscoverService
+
    * Query
+
|org.eclipse.aperi.discovery
+
|IStep
+
AbstractDiscoverProcess
+
Router.addProcess()
+
Router.registerProcess()
+
|Discovery and Probe functions for SLP, SNMP and G3
+
 
|-
 
|-
 +
|other OSGi service
 +
|org.eclipse.aperi.discovery.interfaces.IDiscoverRouterService
 +
| internal Router to select and run DiscoverProcess, not available as WebService
 +
|-
 +
|consumed Extension points
 +
| none
 +
| -
 +
|-
 +
|defined Extension points
 +
| DiscoveryProcessPlugin
 +
|
 +
*used for identifying of device type and collecting of basic device data
 +
*extends org.eclipse.aperi.disk.discovery.DiscoveryProcessPlugin
 +
*Extension point attributes define which registered extension to choose
 +
|-
 +
|
 +
|discoverProcess
 +
|
 +
*extends org.eclipse.aperi.DiscoverProcess used during discovery and probe of devices.
 +
*Extension point attributes defines which registered DiscoverProcess to choose
 
|}
 
|}
    * IDiscover/DiscoverService
 
    * AbstractDiscoverProcess
 
      The abstract Discover Process class provides common functionality for the Discovery framework. Derived classes implements the technology or device specific part of the discovery.
 
      A DiscoverProcess needs to be registered within the Router by Name (Router.addProcess()) or Registration data (Router.registerProcess()) which is provided by a static getRegistrationData() method. In the first case a DiscoverProcess java-object is registered, in the second case the class itself is passed. The registration can be done by a startup method of a Discovery Service-Plugin or within a registerSteps() method of a main DiscoverProcess that registers all subsequent steps.
 
      In Aperi two Interfaces INamedDiscoverProcess and a IDiscoverProcess will cover both cases. INamedDiscoverProvess is implemented by the existing abstract DiscoverProcess class the IDiscoverProcess interface adds the getRegistrationData() and registerSteps() methods.
 
  
DiscoverProcess Extension Point Definition:
+
=====Exported Classes/Interfaces=====
 +
*DiscoverProcess
 +
The abstract DiscoverProcess class provides common functionality for the Discovery framework. Derived classes implements the technology or device specific part of the discovery.
 +
*IStep
 +
Interface and basic implementations for combining the DiscoverProcess needed for a full device Discovery or probe run.
 +
*Router
 +
Picks up and registers the DiscoverProcess from the eclipse extension registry and provide API for manual DiscoverProcess registration.
 +
DiscoverProcess can also be registered with instantiated objects with name only by using the Router.addProcess() method.
 +
Available as IDiscoverRouterService from OSGi service
  
Identifier:
+
====Control - org.eclipse.aperi.control====
org.eclipse.aperi.discovery.DiscoverProcess
+
Configuration Markup:
+
<!ELEMENT extension (DiscoverProcess+)>
+
<!ATTLIST extension
+
point CDATA #REQUIRED
+
id    CDATA #IMPLIED
+
name  CDATA #IMPLIED>
+
<!ELEMENT DiscoverProcess EMPTY>
+
<!ATTLIST DiscoverProcess
+
        DiscoverProcess CDATA #REQUIRED, implements org.eclipse.aperi.discovery.IDiscoverProcess
+
Name        CDATA #REQUIRED,
+
        SMISVersion CDATA
+
        SMISProfile CDATA
+
        Vendor      CDATA
+
        Model      CDATA
+
        InstrumentationVersion CDATA>
+
  
In future, both registration mechanism should be based on eclipse plugin registration technology to allow lazy initialization and xml-based registration data. In this phase only the registerProcess()-based DiscoverProcess will be defined as DiscoverProcess extensions, while the Router will query and register the plugin registry for these DiscoverProcess. The addProcess-based DiscoverProcess are subsequent registered by calling the registerSteps() method or during startup of the device specific Discovery Service.
 
Exported Classes/Interfaces
 
 
    * IStep
 
      Interface and basic implementations for combining the DiscoverProcess needed for a full device Discovery or probe run.
 
    * Router
 
      Picks up and registers the DiscoverProcess from the eclipse extension registry and provide API for manual registration.
 
 
TODO:
 
naming of registerSteps not correct, rename to registerDiscoverProcessByName()
 
How to deregister DiscoverProcesses when plugin is stopped? Add deregisterSteps()?
 
Control
 
 
(org.eclipse.aperi.control)
 
 
Within Aperi, control functions like Volume creation on a storage subsystem are implemented using a Controller class. Plugins that want to provide control functions have to extend this abstract class, which cares for asynchronous execution of control tasks and job handling.
 
Within Aperi, control functions like Volume creation on a storage subsystem are implemented using a Controller class. Plugins that want to provide control functions have to extend this abstract class, which cares for asynchronous execution of control tasks and job handling.
Control functions API are often published as WebServices.
 
Component plugin Extension points Comments
 
Control
 
  
    * ControlEngine
+
Often Control functions APIs are additional published as WebServices.
    * Controller
+
    * ControlService
+
  
org.eclipse.aperi.control IControlEngine
+
=====Control plugin=====
IZoneControl
+
{| border="1"
IStorageSubsystemController -
+
!Component
Exported Classes/Interfaces
+
!Description
 +
!Comments
 +
|-
 +
|OSGi Bundle name
 +
|org.eclipse.aperi.control
 +
| -
 +
|-
 +
|OSGi service
 +
|org.eclipse.aperi.sanmgmt.middleware.interfaces.IService
 +
| The plain control service has no API, it just implements the ISerivce interface to report the overal control service status.
 +
|-
 +
|Webservice name
 +
|ControlService
 +
| -
 +
|-
 +
|consumed Extension points
 +
|none
 +
| -
 +
|-
 +
|defined Extension points
 +
| controller
 +
| extended by a device specific implementation of org.eclipse.aperi.interfaces.IControl which has to  define the specific control API.
 +
|-
 +
|}
  
    * Controller
+
=====Exported Classes/Interfaces=====
 +
*org.eclipse.aperi.interfaces.IController and the abstract implementation in class org.eclipse.aperi.control.Controller
 +
**provides the "management" methods of the specific control modules that extends the controller extension point.
  
Monitoring/Alerting
+
====Monitoring - org.eclipse.aperi.monitor====
  
(org.eclipse.aperi.monitor)
+
Monitoring is used to detect configuration and state changes of devices in the SAN. Aperi will register and listen for messages and indications sent by devices. These are internally distributed by JMS queues. Alerting is also part of the data server and extensability is discussed in the Aperi Phase 2 Data server design.
Monitoring is used to detect configuration and state changes of devices in the SAN. Aperi will register and listen for messages and indications sent by devices. These are internally distributed by JMS queues.
+
Alerting is also part of the data server and extensability is discussed in the Aperi Phase 2 Data server design.
+
  
Monitoring is handled by the IEventMonitorService, where the different events can be registered.
+
=====Monitoring plugin=====
Extension Points
+
{| border="1"
Component plugin Extension points Comments
+
!Component
Monitor org.eclipse.aperi.monitor IPopulator
+
!Description
EventMonitor.registerAlertPopulator(IPopulator)
+
!Comments
ICIMIndicationHandler -
+
|-
IAlertPopulator
+
|OSGi Bundle name
 
+
|org.eclipse.aperi.monitor
AlertPopulatorPlugin Extension Point Definition:
+
| -
 +
|-
 +
|OSGi service
 +
|org.eclipse.aperi.sanmgmt.sanmgr.eventcorrelator.interfaces.IEventMonitorService
 +
| included interfaces:
 +
* org.eclipse.aperi.monitor.eventcorrelator.interfaces.IEventCorrelatorFactory
 +
* org.eclipse.aperi.tape.api.ITapeCollectionService
 +
|-
 +
|Webservice name
 +
|SANEventCorrelatorFactory
 +
| -
 +
|-
 +
|OSGi service 2
 +
|org.eclipse.aperi.sanmgmt.diskmgr.hostservice.manager.interfaces.ISANDiskMgrHostService
 +
| no other interfaces included
 +
|-
 +
|Webservice name 2
 +
|SANHostMgr
 +
| -
 +
|-
 +
|consumed Extension points
 +
| none
 +
| -
 +
|-
 +
|defined Extension points
 +
| none
 +
| *new IPopulator implementations are registered with the Devicetype using the IEventMonitorService.registerAlertPopulator() method. This should turn into an Eclipse plugin extension in future.
 +
*
 +
|-
 +
|}
  
Identifier:
+
====Database Mapper====
org.eclipse.aperi.monitor.eventcorrelator.interfaces.IAlertPopulator
+
Configuration Markup:
+
<!ELEMENT extension (AlertPopultor+)>
+
<!ATTLIST extension
+
point CDATA #REQUIRED
+
id    CDATA #IMPLIED
+
name  CDATA #IMPLIED>
+
<!ELEMENT DBAttributeMapper EMPTY>
+
<!ATTLIST DBAttributeMapper
+
DeviceType  CDATA #REQUIRED
+
DBAttributeMapper CDATA #REQUIRED, implements org.eclipse.aperi.monitor.eventcorrelator.interfaces.IAlertPopulator
+
        >
+
 
+
TableToEntitiyTypeMapping
+
 
+
TableToEntitiyTypeMapping Extension Point Definition:
+
 
+
Identifier:
+
org.eclipse.aperi.monitor.eventcorrelator.TableToEntitiyTypeMapping
+
Configuration Markup:
+
<!ELEMENT extension (AlertPopultor+)>
+
<!ATTLIST extension
+
point CDATA #REQUIRED
+
id    CDATA #IMPLIED
+
name  CDATA #IMPLIED>
+
<!ELEMENT TableToEntitiyTypeMapping EMPTY>
+
<!ATTLIST TableToEntitiyTypeMapping
+
        TableName CDATA #REQUIRED
+
DeviceType  CDATA #REQUIRED
+
        >
+
 
+
Database
+
  
 
The Database definition, helper classes and utilities like "Detectability service" are described in the Aperi Database design document.
 
The Database definition, helper classes and utilities like "Detectability service" are described in the Aperi Database design document.
 +
The javacode related to database helpers and tools is located in the plugin org.eclipse.aperi.common.
  
 
The Aperi database infrastructure defines some extension points that are mainly used by the discover and probe processes to translate device specific data into database entries and group tables to logical entities like a disk storage system.
 
The Aperi database infrastructure defines some extension points that are mainly used by the discover and probe processes to translate device specific data into database entries and group tables to logical entities like a disk storage system.
 
The data translation is done by database mappers that convert device and technologie specific properties like a CIM-SMIS class to generic values and store them to one or more database table entries.
 
The data translation is done by database mappers that convert device and technologie specific properties like a CIM-SMIS class to generic values and store them to one or more database table entries.
 +
 
The Aperi DB provides basic Mapper functions like a MapperPackage that registers all Mappers and a MapperRouter that select a specific Mapper for a given object and describing attributes. Also common mapper functions are provided with the DBAttributeMapper that can be extended for each table and device specific class.
 
The Aperi DB provides basic Mapper functions like a MapperPackage that registers all Mappers and a MapperRouter that select a specific Mapper for a given object and describing attributes. Also common mapper functions are provided with the DBAttributeMapper that can be extended for each table and device specific class.
DBAttributeMapper-plugin:
 
  
AperiDBAttributeMapper Extension Point Definition:
+
=====DbAttributeMapper extension=====
 +
{| border="1"
 +
!Component
 +
!Description
 +
!Comments
 +
|-
 +
|defined Extension points
 +
| dbAttributeMapper
 +
|
 +
*implement org.eclipse.aperi.interfaces.IDBAttributeMapper
 +
*abstract DBAttributeMapper provide basic implementation
 +
*SMISMapperRegistrationData declares when to use the mapper class
 +
|-
 +
|}
  
Identifier:
+
====Other base components====
org.eclipse.aperi.infrastructure.mapping.DBAttributeMapper
+
Configuration Markup:
+
<!ELEMENT extension (DBAttributeMapper+)>
+
<!ATTLIST extension
+
point CDATA #REQUIRED
+
id    CDATA #IMPLIED
+
name  CDATA #IMPLIED>
+
<!ELEMENT DBAttributeMapperEMPTY>
+
<!ATTLIST DBAttributeMapper
+
CIMClassName  CDATA #REQUIRED
+
DBAttributeMapper CDATA #REQUIRED, implements org.eclipse.aperi.infrastructure.mapping.DBAttributeMapper
+
SMISVersion  CDATA #REQUIRED
+
DeviceType    CDATA #REQUIRED
+
InstrumentationVersion CDATA #REQUIRED
+
        Dedicated    CDATA #for top level systems only, value 0-20 accoding to SMIS
+
        >
+
  
Other base components
+
{| border="1"
Component plugin Extension points Comments
+
!Component
Other base components:
+
!plugin
 
+
!Extension points
    * Jobs
+
!Comments
    * Events
+
|-
    * Authorization
+
|Other base components:
    * Configuration
+
* Jobs
    * Alerts
+
* Events
 
+
* Authorization
org.eclipse.aperi.platform IJobMgmtService
+
* Configuration
 +
* Alerts
 +
|org.eclipse.aperi.platform
 +
|IJobMgmtService
 
SANEventService
 
SANEventService
.
 
 
ConfigService
 
ConfigService
Alert Because these base functions are unlikely extended in the first Aperi release and because they might be merged with similar services existing on the data server, a separation into different plugins may not be useful in this phase.
+
Alert
 +
|Because these base functions are unlikely extended in the first Aperi release and because they might be merged with similar services existing on the data server, a separation into different plugins may not be useful in this phase.
 +
|}
  
Standard technology Support
+
===Standard Technology Support===
  
Administration and configuration of different device types is based on the basic technologies like CIM/SMI-S or SNMP. Because Aperi platform should be extensible with additional "base technologies" and storage devices might rely on more than one of them, they are be separated in plugin-bundles.
+
Administration and configuration of different device types is based on the basic technologies like CIM/SMI-S or SNMP. Because Aperi platform should be extensible with additional "base technologies" and storage devices might rely on more than one of them, they should be separated in plugin-bundles a future release.
CIM SMI-S
+
Right now technologies are tied mainly to single technologies, therefore most part of the SMI-S code can be found in the Disk plugin whereas the Fabric plugin contains the SNMP support.
  
 +
====CIM SMI-S====
 
(org.eclipse.aperi.smis)
 
(org.eclipse.aperi.smis)
The SMI-S CIM bundle provides all basic technologies from the SMI-S/CIM standard from version 1.0.x and 1,1.
 
This includes constants for classes, names and properties defined in the SMIS standards, the sblimCIMClient and CIMOM Management.
 
The following plugins and components will be defined:
 
sblim CIMClient
 
  
Communication with the SMIS CIM Provider is done by use of the SBLIM CIM Client. It is not part of the Aperi project but bundled with the Aperi distribution, The Client API is wrapped by a CIMClientWrapper that adds more control to the communication like specific timeout values.
+
Aperi provides the basic technologies from the SMI-S/CIM standard of version 1.0.x and 1,1.
CIMOM Management
+
This includes constants for classes, names and properties defined in the SMIS standards, the sblimCIMClient and management of CIMOMs.
 +
It consists of the following components:
  
The list of known CIM Providers, their access info and additional attributes are managed by the CIMOMManager. Additional the CIMOMManager can be queried for a specific CIMOM to access a given storage device. As well a connection test is performed and faulty CIMOMs skipped.
+
=====sblim CIMClient - org.sblim.slp=====
Extension Points
+
Communication with the SMIS CIM Provider is done by use of the SBLIM CIM Client. It is not part of the Aperi project but used within the org.sblim.slp plugin. The Client API is wrapped within Aperi by a CIMClientWrapper that adds more control to the communication like specific timeout values.
  
ICIMOMManagementService extends IService
+
=====CIMOM Management=====
CIMNames class
+
The list of known CIM Providers, their access info and additional attributes are managed by the CIMOMManager, accessible through the ICIMOMMgmtService. Additional the CIMOMManager can be queried for a specific CIMOM to access a given storage device. As well a connection test is performed and faulty CIMOMs skipped.
The SMIS standard defines Constant string variables for CIM classes, objects, methods etc. These constants are defined in the CIMNames constants class.
+
Basic functionality
+
  
The Aperi framework for Discovery and Probe is based on querying device data, convert it to the database schema and persist it. The following components implements this for CIM/SMIS based data.
+
=====OSGi Services=====
Detailed description can be found in the TPC design documentation.
+
org.eclipse.aperi.common.api.ICIMOMMgmtService is part of the DiskManagerService Webservice API.
  
    * CIMScanner
+
=====Basic Functionality=====
    * Query
+
The Aperi framework for Discovery and Probe is based on querying device data, convert it to the database schema and persist it. The following components implements this for CIM/SMIS based data.  
    * CIMParser/CIMProcessor
+
    * DiscoverStep
+
    * CIM specific IStep implementations like caching of CIM elements.
+
 
+
DB Mapper
+
  
 +
=====DB Mapper=====
 
The DB Mapper associate and convert the properties from the CIM objects to Aperi DB tables and fields.
 
The DB Mapper associate and convert the properties from the CIM objects to Aperi DB tables and fields.
Mappers are registered within the MapperRouter of the DB component.
+
The mappers implement the IDBAttributeMapper interface and has to be registered to the IMapperRouterService.
CIM Monitoring/Indications
+
  
(org.eclipse.aperi.smis.monitor)
+
=====CIM Monitoring/Indications=====
 
Registers and listen to SMIS/CIM Indications.
 
Registers and listen to SMIS/CIM Indications.
It extends the Aperi Platform Monitoring and provides ICIMIndicationHandler/CIMIndicationHandler
+
It extends the Aperi Platform Monitoring and provides ICIMIndicationHandler
SMIS Discovery
+
  
(org.eclipse.aperi.smis.discovery)
+
=====SMIS Discovery=====
The discovery extends the Aperi platform discovery by querying a given CIMOM for storage devices like fabric, disk or tape devices. Device properties are retrived to identify the device and store it into the Aperi database, afterwards a device type specific probe can be run to collect the device configuration.
+
The SMIS discovery extends the Aperi platform discovery by querying a given CIMOM for SMIS SAN devices like fabric, disk or tape devices. Device properties are retrieved to identify the device and store it into the Aperi database, afterwards a device type specific probe can be run to collect the device configuration.
Extension Points
+
The DiscoverProcess is extended with the TopLevelDiscoveryProcess that provides the process for SMIS device discovery.
 +
To handle device and vendor specific properties DiscoverProcessPlugin Extensions can be created to add discovery of more SMI-S devices.
  
    * TopLevelDiscoveryProcess extends DiscoverProcess
+
The Following components allow to the probe SMIS devices:
    * ProcessPluginFactory
+
    * DiscoveryProcessPlugin
+
    * GenericNonDiskDiscoveryProcessPlugin
+
  
Other standard technologies
+
* CIMScanner - interacts directly with the CIM client that performs CIM calls
 +
* AssociatorCIMQuery - extends the DiscoverProcess to perform SMIS CIM queries
 +
* Query - defines the CIM query that is executed within the AssociatorCIMQuery
 +
* CIMParser/CIMProcessor
 +
* DiscoverStep - executes CIM queries. For each CIM object retrieved as the query result subsequent Steps can be performed.
 +
* plus other CIM specific IStep implementations like caching of CIM elements.
  
 +
====Other standard technologies====
 
Several other technologies are used by Aperi. Right now they are included within the Aperi platform or part of single devices but might be packaged in separate plugins later.
 
Several other technologies are used by Aperi. Right now they are included within the Aperi platform or part of single devices but might be packaged in separate plugins later.
SLP
 
 
SLP discovery is part of the CIM/SMIS discovery. Therfore Aperi installation includes the sblim SLP implementation.
 
SNMP
 
  
Aperi includes a module for the SNMP protocol.
+
=====SLP - org.sblim.slp=====
 +
SLP discovery is part of the CIM/SMIS discovery. Therfore Aperi uses the SBLIM SLP implementation in the org.sblim.slp bundle.
  
Device Support
+
=====SNMP - org.eclipse.aperi.snmp=====
 +
Aperi includes an client implementation for the SNMP protocol in the org.eclipse.aperi.snmp bundle.
  
 +
===Device Support===
 
Based on the Aperi platform, the device type specific components of the device-server for disk, fabric or tape devices are provided as Eclipse feature bundles. These extends the platform components for specific Discover/Probe, Configuration and Monitoring functionality and depends on the technology the device is based on. The bundles provide there own APIs for there function blocks and register them as WebService.
 
Based on the Aperi platform, the device type specific components of the device-server for disk, fabric or tape devices are provided as Eclipse feature bundles. These extends the platform components for specific Discover/Probe, Configuration and Monitoring functionality and depends on the technology the device is based on. The bundles provide there own APIs for there function blocks and register them as WebService.
Disk
 
  
 +
====Disk====
 
(org.eclipse.aperi.disk)
 
(org.eclipse.aperi.disk)
 +
 
Aperi supports Storage Subsystems that implements the Array- and InbandVirtualizer Profile with SMIS versions of SMI-S 1.0.x and 1.1. Some vendor specific funcions and fixes for non-compliant devices are already included. In future the device specific cimponents might be separated in additional plugins.
 
Aperi supports Storage Subsystems that implements the Array- and InbandVirtualizer Profile with SMIS versions of SMI-S 1.0.x and 1.1. Some vendor specific funcions and fixes for non-compliant devices are already included. In future the device specific cimponents might be separated in additional plugins.
Main Extensions
 
Component plugin Extension points Comments
 
org.eclipse.aperi.disk.ManagerService IDiskManagerService Service registration/Bundle Lifecycle
 
Disk.Discovery org.eclipse.aperi.disk.discovery IDiskCollectionService
 
ProbeGenericStorageSubsystemProcess -
 
Disk.Control org.eclipse.aperi.disk.control IDiskConfigurationService
 
IStorageConfigurationPlugin
 
StorageConfigurationPluginFactory -
 
Disk.Monitoring org.eclipse.aperi.disk.monitoring IDiskMonitorService
 
ICIMIndicationHandler
 
DiskIndicationHandlerFactory -
 
Disk.Reporting org.eclipse.aperi.disk.reporting IDiskReportingService no common plattform module
 
  
IDiskManagerService extends IService
+
=====Tape plugin=====
Extension Points and Interfaces/generic classes
+
{| border="1"
- for Discovery and Probe
+
!Component
 +
!Description
 +
!Comments
 +
|-
 +
|OSGi Bundle name
 +
|org.eclipse.aperi.disk
 +
| -
 +
|-
 +
|OSGi service
 +
|org.eclipse.aperi.disk.api.IDiskManagerService
 +
| included interfaces:
 +
* org.eclipse.aperi.disk.api.IDiskManagerService
 +
* org.eclipse.aperi.disk.api.IDiskReportingService
 +
* org.eclipse.aperi.disk.api.IDiskCollectionService
 +
* org.eclipse.aperi.disk.api.IDiskConfigurationService
 +
* org.eclipse.aperi.common.api.ICIMOMMgmtService
 +
|-
 +
|Webservice name
 +
|DiskManagerService
 +
| -
 +
|-
 +
|OSGi service 2
 +
|org.eclipse.aperi.disk.api.IDiskMonitorService
 +
| included interfaces:
 +
* org.eclipse.aperi.disk.api.IDiskMonitorService
 +
|-
 +
|Webservice 2 name
 +
|DiskMonitorService
 +
| -
 +
|-
 +
|consumed Extension points
 +
| org.eclipse.aperi.control.controller
 +
org.eclipse.aperi.discovery.discoveryProcessPlugin
 +
org.eclipse.aperi.discovery.discoverProcess
 +
org.eclipse.aperi.disk.storageConfiguration
 +
| -
 +
|-
 +
|defined Extension points
 +
| org.eclipse.aperi.disk.storageConfiguration
 +
| Control functions for different Disk devices may vary, several implementations of org.eclipse.aperi.disk.control.IStorageConfigurationManagementPlugin can be registered with the device specific attributes
 +
|-
 +
|}
  
IDiskCollectionService
 
GenericDiscoveryProcessPlugin
 
ProbeGenericSubsystemProcess extends DiscoverProcess
 
ProbeGenericMappingMaskingProcess extends DiscoverProcess
 
- for Control
 
  
IDiskConfigurationService
+
=====IDiskManagerService API=====
IStorageSubsystemControl
+
*API Interfaces/generic classes for Discovery and Probe
IStorageConfigurationPlugin/StorageConfigurationPluginFactory
+
**IDiskCollectionService
 +
**ProbeGenericSubsystemProcess extends DiscoverProcess
 +
**ProbeGenericMappingMaskingProcess extends DiscoverProcess
  
 +
*API Interfaces/generic classes for Control
 +
**IDiskConfigurationService
 +
**IStorageSubsystemControl
 +
**IStorageConfigurationPlugin/StorageConfigurationPluginFactory
 
The IStorageConfigurationPlugin is the extension point for specific implementations of control functions.
 
The IStorageConfigurationPlugin is the extension point for specific implementations of control functions.
 
The StorageConfigurationPluginFactory needs to use the extension registry to fetch the StorageConfigurationPlugins and return them based on the extensions XML-properties.
 
The StorageConfigurationPluginFactory needs to use the extension registry to fetch the StorageConfigurationPlugins and return them based on the extensions XML-properties.
  
StorageConfigurationPlugin Extension Point Definition:
+
*Extension Points and Interfaces/generic classes for Monitoring
 
+
**IDiskMonitoringService
Identifier:
+
**ICIMIndicationHandler/DiskIndicationHandlerFactory
org.eclipse.aperi.disk.control.StorageConfigurationPlugin
+
Configuration Markup:
+
<!ELEMENT extension (StorageConfigurationPlugin+)>
+
<!ATTLIST extension
+
point CDATA #REQUIRED
+
id    CDATA #IMPLIED
+
name  CDATA #IMPLIED>
+
<!ELEMENT StorageConfigurationPlugin EMPTY>
+
<!ATTLIST StorageConfigurationPlugin
+
StorageConfigurationPlugin CDATA #REQUIRED, implements org.eclipse.aperi.disk.control.IStorageConfigurationPlugin
+
SMISVersion  CDATA #REQUIRED
+
DeviceType    CDATA #REQUIRED
+
        >
+
 
+
- for Monitoring
+
 
+
IDiskMonitoringService
+
ICIMIndicationHandler/DiskIndicationHandlerFactory
+
 
+
 
The ICIMIndicationHandler is the extension point for different SMIS or device specific CIM-indications.
 
The ICIMIndicationHandler is the extension point for different SMIS or device specific CIM-indications.
DiskIndicationHandlerFactory has to dynamically register the IndicationHandlers from the plugin registry.
+
DiskIndicationHandlerFactory dynamically registers the IndicationHandlers using the registerHandler() method.
 
+
This can be changed to a Extension point is a later release.
CIMIndicationHandler Extension Point Definition:
+
 
+
Identifier:
+
org.eclipse.aperi.disk.monitor.CIMIndicationHandler
+
Configuration Markup:
+
<!ELEMENT extension (CIMIndicationHandler+)>
+
<!ATTLIST extension
+
point CDATA #REQUIRED
+
id    CDATA #IMPLIED
+
name  CDATA #IMPLIED>
+
<!ELEMENT CIMIndicationHandler EMPTY>
+
<!ATTLIST CIMIndicationHandler
+
IndicationHandler CDATA #REQUIRED, implements org.eclipse.aperi.disk.monitor.ICIMIndicationHandler
+
CIMClassName  CDATA #REQUIRED
+
IndicationClassname CDATA #REQUIRED
+
        >
+
 
+
- for Reporting
+
  
IDiskReportingService
+
*for Reporting
Other components
+
**IDiskReportingService
 +
*Other components
 +
**The disk component defines a common LogTraceHelper class for all disk related logging, encapsulating the underlying logging service.
  
The disk component defines a common LogTraceHelper class for all disk related logging, encapsulating the underlying logging service.
+
====Tape - org.eclipse.aperi.tape====
Tape
+
  
(org.eclipse.aperi.tape)
 
 
Aperi supports discovery/probe and reporting for Tape devices following the SMI-S 1.1 standard.
 
Aperi supports discovery/probe and reporting for Tape devices following the SMI-S 1.1 standard.
 
Because the structure and implementation of the Tape component is similar to Disk, there is only a list of the Extensions and interfaces provided.
 
Because the structure and implementation of the Tape component is similar to Disk, there is only a list of the Extensions and interfaces provided.
Main Extensions
 
Component plugin Extension points Comments
 
org.eclipse.aperi.tape.ManagerService ITapeManagerService Service registration/Bundle Lifecycle -
 
Tape.Discovery org.eclipse.aperi.tape.discovery ITapeCollectionService
 
ProbeGenericTapeLibraryProcess
 
Tape.Reporting org.eclipse.aperi.tape.reporting ITapeReportingService -
 
  
TapeManagerService
+
=====Tape plugin=====
Extension Points and Interfaces/generic classes
+
{| border="1"
 +
!Component
 +
!Description
 +
!Comments
 +
|-
 +
|OSGi Bundle name
 +
|org.eclipse.aperi.tape
 +
| -
 +
|-
 +
|OSGi service
 +
|org.eclipse.aperi.tape.api.ITapeManagerService
 +
| included interfaces:
 +
* org.eclipse.aperi.tape.api.ITapeReportingService
 +
* org.eclipse.aperi.tape.api.ITapeCollectionService
 +
* javax.jms.MessageListener
 +
|-
 +
|Webservice name
 +
|TapeManagerService
 +
| -
 +
|-
 +
|consumed Extension points
 +
| none
 +
| Extended DiscoverProcess registered using IDiscoverRouterService.
 +
Tape specific DBAttributeMapper still part of common-plugin.
 +
|-
 +
|Defined Extension points
 +
| none
 +
| -
 +
|-
 +
|}
  
 +
=====API Interfaces and generic classes=====
 
ITapeManagerService
 
ITapeManagerService
- for Discovery and Probe
 
  
 +
=====- for Discovery and Probe=====
 
ITapeCollectionService
 
ITapeCollectionService
 +
 
ProbeGenericTapeLibraryProcess extends DiscoverProcess
 
ProbeGenericTapeLibraryProcess extends DiscoverProcess
- for Monitoring
 
  
 +
=====- for Monitoring=====
 
TapeMonitor
 
TapeMonitor
- for Reporting
 
  
 +
=====- for Reporting=====
 
ITapeReportingService
 
ITapeReportingService
Fabric
 
  
(org.eclipse.aperi.fabric)
+
====Fabric - org.eclipse.aperi.fabric====
 +
 
 
Aperi supports Switch and Fabric discovery and configuration using SNMP and G3 protocol.
 
Aperi supports Switch and Fabric discovery and configuration using SNMP and G3 protocol.
  
 
The Fabric support includes SNMP and G3 protocol support. Only the basic plugin APIs are defined for this release and a more modular fabric application structure is introduced with the integration of the fabric SMI-S support.
 
The Fabric support includes SNMP and G3 protocol support. Only the basic plugin APIs are defined for this release and a more modular fabric application structure is introduced with the integration of the fabric SMI-S support.
Main Extensions
 
Component plugin Extension points Comments
 
org.eclipse.aperi.fabric.ManagerService IFabricManagerService Service registration/Bundle Lifecycle
 
Fabric.Discovery org.eclipse.aperi.fabrik.discovery IFabricCollectionService -
 
Fabric.Control org.eclipse.aperi.fabrik.control IFabricConfigurationService -
 
Fabric.Monitoring org.eclipse.aperi.fabrik.monitoring IFabricMonitorService -
 
Fabric.Reporting org.eclipse.aperi.fabrik.reporting IFabricReportingService -
 
  
IFabricManagerService extends IService
+
=====Fabric plugin=====
Extension Points and Interfaces/generic classes
+
{| border="1"
 +
!Component
 +
!Description
 +
!Comments
 +
|-
 +
|OSGi Bundle name
 +
|org.eclipse.aperi.fabric
 +
| -
 +
|-
 +
|OSGi service
 +
|org.eclipse.aperi.fabric.api.IFabricManagerService
 +
| included interfaces:
 +
*org.eclipse.aperi.fabric.api.IFabricManagerService
 +
*org.eclipse.aperi.fabric.api.IFabricReportingService
 +
*org.eclipse.aperi.fabric.api.IFabricCollectionService
 +
*org.eclipse.aperi.fabric.api.IFabricConfigurationService
 +
*org.eclipse.aperi.fabric.api.IAgentMgmtService
 +
*org.eclipse.aperi.common.api.IJobMgmtService
 +
* javax.jms.MessageListener
 +
|-
 +
|Webservice name
 +
|FabricManagerService
 +
| -
 +
|-
 +
|OSGi service 2
 +
|org.eclipse.aperi.snmpagent.manager.interfaces.ISNMPAgentManager
 +
| included interfaces:
 +
*org.eclipse.aperi.snmpagent.manager.interfaces.ISNMPAgentManager
 +
|-
 +
|Webservice 2 name
 +
|SNMPAgentManager
 +
| -
 +
|-
 +
|consumed Extension points
 +
| org.eclipse.aperi.control.controller
 +
| org.eclipse.aperi.control.fabric.ZoneController
 +
|-
 +
|defined Extension points
 +
| none
 +
| -
 +
|-
 +
|}
  
ISNMPAgentManager
+
=====API Interfaces/generic classes=====
- for Discovery and Probe
+
  
Scanner implements IScanner
 
SNMPScanner
 
IFabricCollectionService
 
- for Control
 
  
IZoneControl
+
*for Discovery and Probe
IFabricConfigurationService
+
**SNMPScanner
- for Monitoring
+
**IFabricCollectionService
  
IFabricMonitor
+
*for Control
- for Reporting
+
**IZoneControl
 +
**IFabricConfigurationService
  
IFabricReportingService
+
*for Monitoring
IBM SVC (SAN Volume Controller)
+
**IFabricMonitor
  
 +
*for Reporting
 +
**IFabricReportingService
 +
 +
====IBM SVC (SAN Volume Controller)====
 
(org.eclipse.aperi.disk.ibmsvc)
 
(org.eclipse.aperi.disk.ibmsvc)
 +
 
IBM SAN Volume Controller (SVC) provides some additional support that goes beyond the standard SMIS InbandStorageVirtualizer Profile. To demonstrate the Aperi Extension capabilities the SVC support resides in a separate Plugin Bundle.
 
IBM SAN Volume Controller (SVC) provides some additional support that goes beyond the standard SMIS InbandStorageVirtualizer Profile. To demonstrate the Aperi Extension capabilities the SVC support resides in a separate Plugin Bundle.
 
The SVC support will add additional API methods specific to the IBM SVC device and has to register revice specific discovery/probe and configuration modules.
 
The SVC support will add additional API methods specific to the IBM SVC device and has to register revice specific discovery/probe and configuration modules.
Main Extensions
+
 
Component plugin Extension points Comments
+
=====Main Extensions=====
org.eclipse.aperi.disk.SVCManagerService IDiskSVCManagerService Service registration/Bundle Lifecycle
+
 
Disk.Control org.eclipse.aperi.disk.control IDiskSVCConfigurationService
+
{| border="1"
 +
!Component
 +
!plugin
 +
!Extension points
 +
!Comments
 +
|-
 +
|org.eclipse.aperi.disk.SVCManagerService
 +
|IDiskSVCManagerService
 +
|Service  
 +
|registration/Bundle Lifecycle
 +
|-
 +
|Disk.Control
 +
|org.eclipse.aperi.disk.control
 +
|IDiskSVCConfigurationService
 +
| -
 +
|}
  
 
SVCManagerService extends DiskManagerService
 
SVCManagerService extends DiskManagerService
Extension Points and Interfaces/generic classes
 
- for Discovery and Probe
 
  
ProbeSVCSubsystemProcess extends ProbeGenericInbandVirtualizer
+
=====Extension Points and Interfaces/generic classes=====
ProbeSVCMappingMaskingProcess extends ProbeMappingMaskingProcess
+
=====- for Discovery and Probe=====
- for Control
+
*ProbeSVCSubsystemProcess extends ProbeGenericInbandVirtualizer
 +
*ProbeSVCMappingMaskingProcess extends ProbeMappingMaskingProcess
  
 +
=====- for Control=====
 
IDiskSVCConfigurationService
 
IDiskSVCConfigurationService
- for Monitoring
 
  
 +
=====- for Monitoring=====
 
no special Monitoring for SVC device, the base Disk Monitoring component will be used.
 
no special Monitoring for SVC device, the base Disk Monitoring component will be used.
- for Reporting
 
  
 +
=====- for Reporting=====
 
no special Reporting for SVC device, the base Disk Monitoring component will be used.
 
no special Reporting for SVC device, the base Disk Monitoring component will be used.
  
External Interfaces and Semantics
+
==Installation and Configuration==
 +
===Installation===
 +
All Device Server components are packaged as OSGi bundles/Eclipse features and installed into an OSGi Container on top of the Aperi platform. Also a Aperi database must be installed and running.
  
Programmatic Interfaces (APIs)
+
The technology support bundle requires the Aperi platform, the device support bundles require the Aperi platform and may require one or more technology support bundles.
 +
The resolving of bundle and plugin dependencies is done by the OSGi Container.
  
Document the new or modified APIs delivered with this component. Include information about their signatures, behavior, outputs, and error handling.
+
==Optional Enhancements==
 +
The following points may be useful future enhancements or new extension points that are not implemented yet.
  
Security and Authentication
+
===SMI-S support bundle===
 +
As stated abovr, SMI-S support is not a separate plugin, but mainly part of the disk plugin. With upcoming support for other device types all SMI-S functionality should be grouped into one plugin as a base for all SMI-S device support
  
The different device server components include no security or authentication mechanism.
+
===Job Management===
A user and roles concept might be added at the external (webservice) API level, but is not part of this design document
+
A single plugin for Jobmanagement should be defined, as most components are residing in the common package but the Job API is not consistent and splitted between the device API of fabric, disk and discovery.
  
Installation and Configuration
+
===Device specific enhancements===
 +
Right now in the Disk and Tape plugin the SMI-S standard implementation resides together with device specific enhancements. Separate device specific plugins may improve maintainability of code and device support.
  
Installation
+
For example a device specific plugin to provide support for a IBM SVC might look like below:
 +
====Example: IBM SVC (SAN Volume Controller) - org.eclipse.aperi.disk.ibmsvc====
  
All Device Server components are packaged as OSGi bundles/Eclipse features and installed into an OSGi Container on top of the Aperi platform. Also a Aperi database must be installed and running.
+
IBM SAN Volume Controller (SVC) provides some additional support that goes beyond the standard SMIS InbandStorageVirtualizer Profile.
The technology support bundle requires the Aperi platform, the device support bundles require the Aperi platform and may require one or more technology support bundles.
+
The SVC support will add additional API methods specific to the IBM SVC device and has to register revice specific discovery/probe and configuration modules.
The resolving of bundle and plugin dependencies is done by the OSGi Container.
+
  
Configuration
+
=====IBMSVC plugin=====
 +
{| border="1"
 +
!Component
 +
!Description
 +
!Comments
 +
|-
 +
|OSGi Bundle name
 +
|org.eclipse.aperi.ibmsvc
 +
| -
 +
|-
 +
|OSGi service
 +
|org.eclipse.aperi.tape.api.ISVCManagerService
 +
|extends the IDiskManagerService interface
 +
|-
 +
|Webservice name
 +
|SVCManagerService
 +
| -
 +
|-
 +
|consumed Extension points
 +
| same as disk with device specifics
 +
| -
 +
|-
 +
|defined Extension points
 +
| no new extension points
 +
| -
 +
|-
 +
|}
  
Identify the configuration required to utilize the components. Does this configuration occur during installation or after installation?
+
=====API Interfaces/generic classes=====
 +
*SVCManagerService extends DiskManagerService
  
Globalization
+
*for Discovery and Probe
 +
**ProbeSVCSubsystemProcess extends ProbeGenericInbandVirtualizer
 +
**ProbeSVCMappingMaskingProcess extends ProbeMappingMaskingProcess
  
Please elaborate on any globalization issues.
+
*for Control
 +
**IDiskSVCConfigurationService
  
Open Source
+
*for Monitoring
 +
**no special Monitoring for SVC device, the base Disk Monitoring component will be used.
  
Identify all open source code that is used that is not owned by Aperi. If non-Aperi open source code is used, identify the origin or the owner of the source code and any binding legal agreement.
+
*for Reporting
 +
**no special Reporting for SVC device, the base Disk Monitoring component will be used.

Latest revision as of 13:56, 15 January 2007

Document Author: Christoph Reichert

Latest Update Jan, 2007

Contents

Introduction

The primary goal of the 2nd phase of the Aperi Eclipse project is to add extensibility that is based on Eclipse technology.

This document describes the enhancements for extensibility for the Aperi device server. Because the device server is a combination of three functional blocks for disk, tape and fabric support, this document focuses on the separation and the dynamic extensibility of the functional blocks.

This document does not cover the design of the Aperi device sever itself. Changes to this design that are done because of the Aperi work will be discussed in this document.

Design Overview and Goals

A main goal for the Aperi project is to create a extensible platform where different parties can contribute by refining the existing base, adding new functions or extend specific functions. This can only be archieved by providing an extensible and modularised code base. Therefore the existing device server is split into separated plugins and features that provide base functionality like logging or generic discovery and device specific extensions like disk discovery.

The former device server consists of a service manager that starts up all components defined as "services" in a services.properties file and deployed them as webservices. The service manager itself was started as a servlet during initialization within a servlet container. Using the Eclipse/OSGi infrastructure the "services" will be redefined as OSGi services. A connector component will look for these services and publish their APIs as webservices. The code belonging to the service is defined as a OSGi bundle, so the OSGi container cares about the bundle lifecycle and service starting and stopping. Defining dependencies between the OSGi bundles and assigning them to different runlevels ensures the correct startup order of the bundles.

The implementations of the existing service and component registrations is done by execution of java code (e.g add object and constants to registry hashtable). With Eclipse plugin registration this should migrated to a XML-property based registration wherever possible, to support lazy service initialization.

This document does not cover the extensibility of the Aperi common services (like logging or job handling) but refers to used extension points. It is assumed that similar common services from the dataserver needs to be merged into single Aperi infrastructure components. Additional, existing plugins from other eclipse projects that provide such "common services" should be reviewed and included into the base Aperi infrastructure.

Design Rationale

The design follows the existing building blocks the device server consists of and provide these as extensible components with less changes to the code as possible. Some components would require a large rework to provide detailed extensibility, these will be left as larger blocks which can be reworked as needed later in the Aperi project.

Open Items

  • Component shutdown/removal: There is no common strategy to deregister device server components. How can a component or the OSGi service container know if parts are used by running jobs or required by managed devices?
  • Detectability: Detectability service is highly dependent on the underlying database schema, so we should consider to treat it as a database component. Detectability is not designed for dynamic extensibility, there are a lot of numeric constants and if-then-else constructs that need more in-depth analysis and design.

Requirements Addressed and Features Provided

Aperi Extensibility can be grouped in different categories:

  • Special Device Extensibility
    • Support for a kind of Storage Devices (like Disk Arrays) can be extended to support special features of a device or to provide a fix/workaround for a special device.
  • Additional Device Extensibility
    • Support for new kind of devices like NAS devices can be added to Aperi.
  • API Extensibility
    • The API provided by WebServices and internal Services can be extended.

Main Components of the Architecture

Device Servers Platform Components

The Infrastructure components have to be moved from the Device-Server to the Aperi platform. Some main building blocks need to be defined as Eclipse Plugins (OSGi Bundles) that the device-server apps can use and extend. Others are just used as-is and will not be separated in different plugins in this phase. The base code that is used together with Data server is located in the org.eclipse.aperi.common and org.eclipse.aperi.common.utils project. Some OSGi services are defined there and started by the org.eclipse.aperi.server.device bundle

Device Server - org.eclipse.aperi.server.device
Component Description Comments
OSGi Bundle name org.eclipse.aperi.server.device -
OSGi service org.eclipse.aperi.sanmgmt.dbconnparms.interfaces.IConfigService included interfaces:
  • org.eclipse.aperi.sanmgmt.dbconnparms.interfaces.IConfigService
Webservice name ConfigService -
consumed Extension points none -
defined Extension points none -

Discovery - org.eclipse.aperi.discovery

Aperi Discovery is a framework to detect SAN devices and query their configuration data. The detection and identification of new devices or their providers is called "discovery", collection of the configuration data of a specific storage device is called "probe".

The abstract class DiscoverProcess is the main extension point for different process steps that has to performed for a discovery or device probe. If more than one DiscoverProcess step needs to be performed for a discovery, the IStep Interface provides a container for combining and executing different DiscoverProcess' in the required order.

Depending on the Device type discovered, number and sequence of the DiscoverProcess steps may vary. Therefore the different DiscoverProcesses are registered in the Router component, which selects the DiscoverProcess based on the DiscoverProcess name and different device attributes like Vendor name, device type etc, which is provided by the DiscoverProcess RegistrationData. Plugins that want to extend the Aperi Discovery has to implement the required DiscoverProcess and register them within the Router.

Discovery plugin
Component Description Comments
OSGi Bundle name org.eclipse.aperi.discovery -
other OSGi service org.eclipse.aperi.discovery.interfaces.IDiscoverRouterService internal Router to select and run DiscoverProcess, not available as WebService
consumed Extension points none -
defined Extension points DiscoveryProcessPlugin
  • used for identifying of device type and collecting of basic device data
  • extends org.eclipse.aperi.disk.discovery.DiscoveryProcessPlugin
  • Extension point attributes define which registered extension to choose
discoverProcess
  • extends org.eclipse.aperi.DiscoverProcess used during discovery and probe of devices.
  • Extension point attributes defines which registered DiscoverProcess to choose
Exported Classes/Interfaces
  • DiscoverProcess

The abstract DiscoverProcess class provides common functionality for the Discovery framework. Derived classes implements the technology or device specific part of the discovery.

  • IStep

Interface and basic implementations for combining the DiscoverProcess needed for a full device Discovery or probe run.

  • Router

Picks up and registers the DiscoverProcess from the eclipse extension registry and provide API for manual DiscoverProcess registration. DiscoverProcess can also be registered with instantiated objects with name only by using the Router.addProcess() method. Available as IDiscoverRouterService from OSGi service

Control - org.eclipse.aperi.control

Within Aperi, control functions like Volume creation on a storage subsystem are implemented using a Controller class. Plugins that want to provide control functions have to extend this abstract class, which cares for asynchronous execution of control tasks and job handling.

Often Control functions APIs are additional published as WebServices.

Control plugin
Component Description Comments
OSGi Bundle name org.eclipse.aperi.control -
OSGi service org.eclipse.aperi.sanmgmt.middleware.interfaces.IService The plain control service has no API, it just implements the ISerivce interface to report the overal control service status.
Webservice name ControlService -
consumed Extension points none -
defined Extension points controller extended by a device specific implementation of org.eclipse.aperi.interfaces.IControl which has to define the specific control API.
Exported Classes/Interfaces
  • org.eclipse.aperi.interfaces.IController and the abstract implementation in class org.eclipse.aperi.control.Controller
    • provides the "management" methods of the specific control modules that extends the controller extension point.

Monitoring - org.eclipse.aperi.monitor

Monitoring is used to detect configuration and state changes of devices in the SAN. Aperi will register and listen for messages and indications sent by devices. These are internally distributed by JMS queues. Alerting is also part of the data server and extensability is discussed in the Aperi Phase 2 Data server design.

Monitoring plugin
Component Description Comments
OSGi Bundle name org.eclipse.aperi.monitor -
OSGi service org.eclipse.aperi.sanmgmt.sanmgr.eventcorrelator.interfaces.IEventMonitorService included interfaces:
  • org.eclipse.aperi.monitor.eventcorrelator.interfaces.IEventCorrelatorFactory
  • org.eclipse.aperi.tape.api.ITapeCollectionService
Webservice name SANEventCorrelatorFactory -
OSGi service 2 org.eclipse.aperi.sanmgmt.diskmgr.hostservice.manager.interfaces.ISANDiskMgrHostService no other interfaces included
Webservice name 2 SANHostMgr -
consumed Extension points none -
defined Extension points none *new IPopulator implementations are registered with the Devicetype using the IEventMonitorService.registerAlertPopulator() method. This should turn into an Eclipse plugin extension in future.

Database Mapper

The Database definition, helper classes and utilities like "Detectability service" are described in the Aperi Database design document. The javacode related to database helpers and tools is located in the plugin org.eclipse.aperi.common.

The Aperi database infrastructure defines some extension points that are mainly used by the discover and probe processes to translate device specific data into database entries and group tables to logical entities like a disk storage system. The data translation is done by database mappers that convert device and technologie specific properties like a CIM-SMIS class to generic values and store them to one or more database table entries.

The Aperi DB provides basic Mapper functions like a MapperPackage that registers all Mappers and a MapperRouter that select a specific Mapper for a given object and describing attributes. Also common mapper functions are provided with the DBAttributeMapper that can be extended for each table and device specific class.

DbAttributeMapper extension
Component Description Comments
defined Extension points dbAttributeMapper
  • implement org.eclipse.aperi.interfaces.IDBAttributeMapper
  • abstract DBAttributeMapper provide basic implementation
  • SMISMapperRegistrationData declares when to use the mapper class

Other base components

Component plugin Extension points Comments
Other base components:
  • Jobs
  • Events
  • Authorization
  • Configuration
  • Alerts
org.eclipse.aperi.platform IJobMgmtService

SANEventService ConfigService Alert

Because these base functions are unlikely extended in the first Aperi release and because they might be merged with similar services existing on the data server, a separation into different plugins may not be useful in this phase.

Standard Technology Support

Administration and configuration of different device types is based on the basic technologies like CIM/SMI-S or SNMP. Because Aperi platform should be extensible with additional "base technologies" and storage devices might rely on more than one of them, they should be separated in plugin-bundles a future release. Right now technologies are tied mainly to single technologies, therefore most part of the SMI-S code can be found in the Disk plugin whereas the Fabric plugin contains the SNMP support.

CIM SMI-S

(org.eclipse.aperi.smis)

Aperi provides the basic technologies from the SMI-S/CIM standard of version 1.0.x and 1,1. This includes constants for classes, names and properties defined in the SMIS standards, the sblimCIMClient and management of CIMOMs. It consists of the following components:

sblim CIMClient - org.sblim.slp

Communication with the SMIS CIM Provider is done by use of the SBLIM CIM Client. It is not part of the Aperi project but used within the org.sblim.slp plugin. The Client API is wrapped within Aperi by a CIMClientWrapper that adds more control to the communication like specific timeout values.

CIMOM Management

The list of known CIM Providers, their access info and additional attributes are managed by the CIMOMManager, accessible through the ICIMOMMgmtService. Additional the CIMOMManager can be queried for a specific CIMOM to access a given storage device. As well a connection test is performed and faulty CIMOMs skipped.

OSGi Services

org.eclipse.aperi.common.api.ICIMOMMgmtService is part of the DiskManagerService Webservice API.

Basic Functionality

The Aperi framework for Discovery and Probe is based on querying device data, convert it to the database schema and persist it. The following components implements this for CIM/SMIS based data.

DB Mapper

The DB Mapper associate and convert the properties from the CIM objects to Aperi DB tables and fields. The mappers implement the IDBAttributeMapper interface and has to be registered to the IMapperRouterService.

CIM Monitoring/Indications

Registers and listen to SMIS/CIM Indications. It extends the Aperi Platform Monitoring and provides ICIMIndicationHandler

SMIS Discovery

The SMIS discovery extends the Aperi platform discovery by querying a given CIMOM for SMIS SAN devices like fabric, disk or tape devices. Device properties are retrieved to identify the device and store it into the Aperi database, afterwards a device type specific probe can be run to collect the device configuration. The DiscoverProcess is extended with the TopLevelDiscoveryProcess that provides the process for SMIS device discovery. To handle device and vendor specific properties DiscoverProcessPlugin Extensions can be created to add discovery of more SMI-S devices.

The Following components allow to the probe SMIS devices:

  • CIMScanner - interacts directly with the CIM client that performs CIM calls
  • AssociatorCIMQuery - extends the DiscoverProcess to perform SMIS CIM queries
  • Query - defines the CIM query that is executed within the AssociatorCIMQuery
  • CIMParser/CIMProcessor
  • DiscoverStep - executes CIM queries. For each CIM object retrieved as the query result subsequent Steps can be performed.
  • plus other CIM specific IStep implementations like caching of CIM elements.

Other standard technologies

Several other technologies are used by Aperi. Right now they are included within the Aperi platform or part of single devices but might be packaged in separate plugins later.

SLP - org.sblim.slp

SLP discovery is part of the CIM/SMIS discovery. Therfore Aperi uses the SBLIM SLP implementation in the org.sblim.slp bundle.

SNMP - org.eclipse.aperi.snmp

Aperi includes an client implementation for the SNMP protocol in the org.eclipse.aperi.snmp bundle.

Device Support

Based on the Aperi platform, the device type specific components of the device-server for disk, fabric or tape devices are provided as Eclipse feature bundles. These extends the platform components for specific Discover/Probe, Configuration and Monitoring functionality and depends on the technology the device is based on. The bundles provide there own APIs for there function blocks and register them as WebService.

Disk

(org.eclipse.aperi.disk)

Aperi supports Storage Subsystems that implements the Array- and InbandVirtualizer Profile with SMIS versions of SMI-S 1.0.x and 1.1. Some vendor specific funcions and fixes for non-compliant devices are already included. In future the device specific cimponents might be separated in additional plugins.

Tape plugin
Component Description Comments
OSGi Bundle name org.eclipse.aperi.disk -
OSGi service org.eclipse.aperi.disk.api.IDiskManagerService included interfaces:
  • org.eclipse.aperi.disk.api.IDiskManagerService
  • org.eclipse.aperi.disk.api.IDiskReportingService
  • org.eclipse.aperi.disk.api.IDiskCollectionService
  • org.eclipse.aperi.disk.api.IDiskConfigurationService
  • org.eclipse.aperi.common.api.ICIMOMMgmtService
Webservice name DiskManagerService -
OSGi service 2 org.eclipse.aperi.disk.api.IDiskMonitorService included interfaces:
  • org.eclipse.aperi.disk.api.IDiskMonitorService
Webservice 2 name DiskMonitorService -
consumed Extension points org.eclipse.aperi.control.controller

org.eclipse.aperi.discovery.discoveryProcessPlugin org.eclipse.aperi.discovery.discoverProcess org.eclipse.aperi.disk.storageConfiguration

-
defined Extension points org.eclipse.aperi.disk.storageConfiguration Control functions for different Disk devices may vary, several implementations of org.eclipse.aperi.disk.control.IStorageConfigurationManagementPlugin can be registered with the device specific attributes


IDiskManagerService API
  • API Interfaces/generic classes for Discovery and Probe
    • IDiskCollectionService
    • ProbeGenericSubsystemProcess extends DiscoverProcess
    • ProbeGenericMappingMaskingProcess extends DiscoverProcess
  • API Interfaces/generic classes for Control
    • IDiskConfigurationService
    • IStorageSubsystemControl
    • IStorageConfigurationPlugin/StorageConfigurationPluginFactory

The IStorageConfigurationPlugin is the extension point for specific implementations of control functions. The StorageConfigurationPluginFactory needs to use the extension registry to fetch the StorageConfigurationPlugins and return them based on the extensions XML-properties.

  • Extension Points and Interfaces/generic classes for Monitoring
    • IDiskMonitoringService
    • ICIMIndicationHandler/DiskIndicationHandlerFactory

The ICIMIndicationHandler is the extension point for different SMIS or device specific CIM-indications. DiskIndicationHandlerFactory dynamically registers the IndicationHandlers using the registerHandler() method. This can be changed to a Extension point is a later release.

  • for Reporting
    • IDiskReportingService
  • Other components
    • The disk component defines a common LogTraceHelper class for all disk related logging, encapsulating the underlying logging service.

Tape - org.eclipse.aperi.tape

Aperi supports discovery/probe and reporting for Tape devices following the SMI-S 1.1 standard. Because the structure and implementation of the Tape component is similar to Disk, there is only a list of the Extensions and interfaces provided.

Tape plugin
Component Description Comments
OSGi Bundle name org.eclipse.aperi.tape -
OSGi service org.eclipse.aperi.tape.api.ITapeManagerService included interfaces:
  • org.eclipse.aperi.tape.api.ITapeReportingService
  • org.eclipse.aperi.tape.api.ITapeCollectionService
  • javax.jms.MessageListener
Webservice name TapeManagerService -
consumed Extension points none Extended DiscoverProcess registered using IDiscoverRouterService.

Tape specific DBAttributeMapper still part of common-plugin.

Defined Extension points none -
API Interfaces and generic classes

ITapeManagerService

- for Discovery and Probe

ITapeCollectionService

ProbeGenericTapeLibraryProcess extends DiscoverProcess

- for Monitoring

TapeMonitor

- for Reporting

ITapeReportingService

Fabric - org.eclipse.aperi.fabric

Aperi supports Switch and Fabric discovery and configuration using SNMP and G3 protocol.

The Fabric support includes SNMP and G3 protocol support. Only the basic plugin APIs are defined for this release and a more modular fabric application structure is introduced with the integration of the fabric SMI-S support.

Fabric plugin
Component Description Comments
OSGi Bundle name org.eclipse.aperi.fabric -
OSGi service org.eclipse.aperi.fabric.api.IFabricManagerService included interfaces:
  • org.eclipse.aperi.fabric.api.IFabricManagerService
  • org.eclipse.aperi.fabric.api.IFabricReportingService
  • org.eclipse.aperi.fabric.api.IFabricCollectionService
  • org.eclipse.aperi.fabric.api.IFabricConfigurationService
  • org.eclipse.aperi.fabric.api.IAgentMgmtService
  • org.eclipse.aperi.common.api.IJobMgmtService
  • javax.jms.MessageListener
Webservice name FabricManagerService -
OSGi service 2 org.eclipse.aperi.snmpagent.manager.interfaces.ISNMPAgentManager included interfaces:
  • org.eclipse.aperi.snmpagent.manager.interfaces.ISNMPAgentManager
Webservice 2 name SNMPAgentManager -
consumed Extension points org.eclipse.aperi.control.controller org.eclipse.aperi.control.fabric.ZoneController
defined Extension points none -
API Interfaces/generic classes
  • for Discovery and Probe
    • SNMPScanner
    • IFabricCollectionService
  • for Control
    • IZoneControl
    • IFabricConfigurationService
  • for Monitoring
    • IFabricMonitor
  • for Reporting
    • IFabricReportingService

IBM SVC (SAN Volume Controller)

(org.eclipse.aperi.disk.ibmsvc)

IBM SAN Volume Controller (SVC) provides some additional support that goes beyond the standard SMIS InbandStorageVirtualizer Profile. To demonstrate the Aperi Extension capabilities the SVC support resides in a separate Plugin Bundle. The SVC support will add additional API methods specific to the IBM SVC device and has to register revice specific discovery/probe and configuration modules.

Main Extensions
Component plugin Extension points Comments
org.eclipse.aperi.disk.SVCManagerService IDiskSVCManagerService Service registration/Bundle Lifecycle
Disk.Control org.eclipse.aperi.disk.control IDiskSVCConfigurationService -

SVCManagerService extends DiskManagerService

Extension Points and Interfaces/generic classes
- for Discovery and Probe
  • ProbeSVCSubsystemProcess extends ProbeGenericInbandVirtualizer
  • ProbeSVCMappingMaskingProcess extends ProbeMappingMaskingProcess
- for Control

IDiskSVCConfigurationService

- for Monitoring

no special Monitoring for SVC device, the base Disk Monitoring component will be used.

- for Reporting

no special Reporting for SVC device, the base Disk Monitoring component will be used.

Installation and Configuration

Installation

All Device Server components are packaged as OSGi bundles/Eclipse features and installed into an OSGi Container on top of the Aperi platform. Also a Aperi database must be installed and running.

The technology support bundle requires the Aperi platform, the device support bundles require the Aperi platform and may require one or more technology support bundles. The resolving of bundle and plugin dependencies is done by the OSGi Container.

Optional Enhancements

The following points may be useful future enhancements or new extension points that are not implemented yet.

SMI-S support bundle

As stated abovr, SMI-S support is not a separate plugin, but mainly part of the disk plugin. With upcoming support for other device types all SMI-S functionality should be grouped into one plugin as a base for all SMI-S device support

Job Management

A single plugin for Jobmanagement should be defined, as most components are residing in the common package but the Job API is not consistent and splitted between the device API of fabric, disk and discovery.

Device specific enhancements

Right now in the Disk and Tape plugin the SMI-S standard implementation resides together with device specific enhancements. Separate device specific plugins may improve maintainability of code and device support.

For example a device specific plugin to provide support for a IBM SVC might look like below:

Example: IBM SVC (SAN Volume Controller) - org.eclipse.aperi.disk.ibmsvc

IBM SAN Volume Controller (SVC) provides some additional support that goes beyond the standard SMIS InbandStorageVirtualizer Profile. The SVC support will add additional API methods specific to the IBM SVC device and has to register revice specific discovery/probe and configuration modules.

IBMSVC plugin
Component Description Comments
OSGi Bundle name org.eclipse.aperi.ibmsvc -
OSGi service org.eclipse.aperi.tape.api.ISVCManagerService extends the IDiskManagerService interface
Webservice name SVCManagerService -
consumed Extension points same as disk with device specifics -
defined Extension points no new extension points -
API Interfaces/generic classes
  • SVCManagerService extends DiskManagerService
  • for Discovery and Probe
    • ProbeSVCSubsystemProcess extends ProbeGenericInbandVirtualizer
    • ProbeSVCMappingMaskingProcess extends ProbeMappingMaskingProcess
  • for Control
    • IDiskSVCConfigurationService
  • for Monitoring
    • no special Monitoring for SVC device, the base Disk Monitoring component will be used.
  • for Reporting
    • no special Reporting for SVC device, the base Disk Monitoring component will be used.

Back to the top