Determine Infrastructure

Determining the proper infrastructure for an SMI implementation is a critical step in the development process. The following is a list of items that need to be determined prior to designing the vendor schema or developing providers.

1. WBEM Server - SMI implementations require a WBEM Server. A WBEM Server is the main infrastructure component in the SMI Architecture. A WBEM Server is responsible for handling SMI Client requests, indication delivery (aka event delivery) to SMI Listeners, and management of SMI Providers. Open Source and Commercial WBEM Servers are available, see WBEM Servers. When evaluating a WBEM Server, the items to consider are programming language interfaces, performance, scalability, support, documentation, platform support, features, etc.
2. Embedded or Proxy - An Embedded implementation is one where all the components reside as part of the device (it may be a separate service processor, but all part of the storage device). A Proxy implementation is installed on a separate system remotely accessing the instrumentation data. There are advantages and disadvantages to each approach. For example, an embedded implementation may be limited on resources, such as memory or disk while a proxy implementation has to deal with an installation program, possible multiple platforms, configuration of the devices to manage and firewall configuration, etc. An embedded implementation is preferred as it allows the storage device to be manageable out of the box.
3. Security - Determine the authentication and/or authorization mechanism. Is it local or third party (e.g. LDAP, ...). For example, if the implementation is a proxy, it may use the third party platform authentication (e.g. Windows or PAM) to handle authentication. If the implementation is embedded, it may have local accounts or use LDAP.
4. Instrumentation API - The API(s) used to retrieve the instrumentation data from the storage device(s) (e.g. REST, language bindings, ...). Some of the features to evaluate for an instrumentation API:
   • completeness - ensure all information needed for SMI is available from the API.
   • event handling - are changes in state (e.g. a storage volume was created or deleted) dynamically provided by the API.
   • performance - responding to requests in a timely manner.
   • scalability - A provider is required to handle simultaneous requests. If the instrumentation API does not allow for simultaneous requests, the provider must be able to manage the requests efficiently (see cache). If the operation is a method invocation, the provider may be required to return a job and run the operation asynchronously. A provider may also be required to handle many instances (e.g. hundreds of thousands).
5. Cache - Do the providers need to cache data to ensure timely responses to clients? If an instrumentation API does not perform/scale sufficiently to handle the number of elements (e.g. potentially hundreds of thousands of storage volumes) that need to be retrieved, a cache may be needed to ensure that SMI clients get timely responses. If the instrumentation API requires multiple calls to retrieve SMI data, a cache may be required for performance reasons. If a cache is implemented, it will need to be in synch with the storage device.
6. Indication handling - An SMI Provider may be responsible for handling indications for a particular object. For example, if a volume is created/deleted the provider is required to deliver an indication. If the instrumentation API does not have a mechanism to notify the SMI provider when the state of an object changes, the provider may have to poll for the information. If polling for information, only one polling engine should be instantiated for all providers.