Aperi Device Server R2 Extensibility

Device Server Extensibility for Aperi R0.2

Aperi R0.2 offers full extensibility support for storage devices. This article provides a brief overview of the extension points available. As an example for adding a vendor specific storage device to Aperi, the extensions for the IBM Storage Virtualization Controller (SVC) is discussed and a walk through to the code extensions provided. Because the SVC support is included in the existing Aperi code, the extensions and code separation is not as strict as it will be with an device extension created from scratch. There is no separate bundle for the SVC created and the specific classes does not reside in separate packages and some SVC specific API methods and Constants are mixed in other classes. Device specific GUI extensions or additions to the database layout are not part of the device server extensibility and not covered in this article.

Extent Device Discovery

The Aperi device discovery tries to identify SAN devices and collect the basic device data, like vendor, machine type and serial number but also the functional type of the device like disk array, inband storage virtualizer, switch or fabric.

Extension org.eclipse.aperi.discovery.discoveryProcessPlugin

The Interface org.eclipse.aperi.disk.discovery.DiscoveryProcessPlugin defines methods to initialize the Discovery Request and to collect the data for device discovery. The discoveryProcessPlugin Extension point takes an implementation of this interface for a specific device, all devices of the same kind or a generic discovery implementation. For SMI-S devices generic implementations of the DiscoveryProcessPlugin are available in the abstract class org.eclipse.aperi.disk.discovery.ProcessPlugin and the class org.eclipse.aperi.disk.discovery.GenericDiscoveryProcessPlugin. For the SVC device most data is discovered correct by the GenericDiscoveryProcessPlugin, but some settings need correction, therefore the GenericDiscoveryProcessPlugin class is extended by SVCDiscoveryProcessPlugin. This class needs to be defined as a discoveryProcessPluginextension point.The “impl” extension point attribute takes the device specific implementation class, for the SVC the SVCDiscoveryProcessPlugin. The other extension point attributes are optional, however some need to be set because they define the conditions for which this plugin has to be selected for device discovery. For the SVC the condition is that the device CIMOM provides a server profile (no_server_profile = false) and the SMIS attribute property “element_name” starts with the String “SVC”.

Extent Device Probe

During the device probe all entities of a SAN device are collected and stored into the Aperi database. For SMIS enabled devices the SMIS class association are traversed and the CIM objects and their relations are retrieved and persisted with database mappers. The main building blocks for the probe process are the DiscoverProcess and the Istep. The different DiscoverProcess and their process sequence is maintained by the IStep interface that maintains a list of subsequent ISteps which are processed sequentially afterwards. The abstract class org.eclipse.aperi.DiscoverProcess represents a single step in the probe. This might reach from a complete device discovery by invoking subsequent DiscoverProcess' or basic steps like executing a single SMIS-CIM call, like the AssociatorCIMQuery DiscoverProcess. Because the DiscoverProcess implementations can be used in such different ways there are different options to extent the probe with customized DiscoverProcess classes.

Service org.eclipse.aperi.discovery.interfaces.IDiscoverRouterService

To perform a special SMIS CIM-call it would be a large overhead to create a unique DiscoverProvess class. Instead, the AssociatorCIMQuery can be instantiated with several parameters, defining the CIM query and names for the new CIMQuery-Process and the result objects. The name of this customized instance must be unique and extends the probe by registering with the IDiscoverRouterService.addProcess() method. This registration has to be done actively during runtime, so during DiskManager service startup() the static method ProbeSVCSubsystemProcess.registerSteps() is called. In the future for the DiscoverProcesses that needs to be instantiated before registering, individual Extension Points can be defined that take all required parameters and this way supports lazy initialisation.

Extension org.eclipse.aperi.discovery.discoverProcess

The discoverProcess extension takes a discoverProcess implementation and a name for this process. Duplicate names are allowed, because additional extension attributes define which extension to choose out of several DiscoverProcess with the same name. In Aperi the main probe DiscoverProcesses that define complete device probes are defined through this extension point. For the SVC device a ProbeSVCSubsystemProcess extends the ProbeGenericInBandVirtualizerProcess. Furthermore different versions of the SVC CIMOM behaves in different ways, so special probe processes are needed for older and never SVC CIMOMs. The ProbeSVCLegacySubsystemProcess for older CIMOMs is registered with the attributes DiscoverProcessName “collectDataFromStorageSubsystem”, the SMIS Profile “In Band Virtualization”, the Vendor “IBM” and all legacy CIMOM version strings. The newer SVC CIMOMs are handled by the ProbeSVCNonLegacySubsystemProcess class, which is registered without a CIMOM version. The same is for probing the Mapping and Masking data. The ProbeGenericMaskingMappingProcess is extended for SVC with the class ProbeSVCLegacyMaskingMappingProcess for old CIMOMs and the class ProbeSVCMaskingMappingProcess for newer SVC CIMOM versions. Additional DiscoverProcesses are used that are summarized as ProbePostProcessing. Here are no further CIM calls done, but the collected data is analyzed. For example the SVCExtentUpdatePostProcess maps the SVCs Mdisk (stored as Extents) to already probed Volumes of the SVCs backend Disk Devices. The SVC specific probe processes are defining probe step sequences that uses the SVC specific DiscoverProcesses that are registered with unique names to the IDiscoverRouterService, as described in the the previous section.

Extent Database Mapper

Extension org.eclipse.aperi.common.dbAttributeMapper

Device Discovery and Probe are using database Mappers to persist the CIM Object attributes to the database. Device specific attribute names or the format of the values often requires special mappers. These can be defined by implementing the interface org.eclipse.aperi.interfaces.IDBAttributeMapper or by extending an existing mapper class. For the new class a dbAttributeMapper Extension needs to be defined that includes the SMISRegistration attributes to select the new mapper class. For the SVC device the generic mapper classes are extended but they are registered directly using the legacy MapperPackage and not through the Extension, which should be corrected in a later release.