Chapter 5 Using DMI
5.1 Using DMI Overview
This chapter provides an introduction to the Desktop Management Task
Force (DMTF) special interest group, manageability, and the Desktop Management
Interface (DMI).
5.2 What is DMTF?
The DMTF was formed in May of 1992 as a cooperative effort of eight
companies: Digital Equipment CorporationTM, Hewlett-PackardTM, IBMTM, IntelTM, MicrosoftTM, NovellTM, SunTM, and SynOpticsTM. The objective of the
DMTF was to provide a simple solution for desktop manageability.
The DTMF created a standard interface that handles communication between
any management application and all the manageable products on -- or attached
to -- a desktop PC or server.
This standard is called the DMI. For more information on the DMI, refer
to the DMI Specification Version 2.0 at http://www.dmtf.org
The DMI is:
-
Independent of any specific operating system, hardware platform,
or management protocol
-
Easy for vendors to adopt
-
Scalable, to accommodate a wide range of products
from very simple to very complex and extensible
-
Mappable to existing management and remote protocols
5.3 DMI Functionality
DMI functionality for the SEA includes the following:
-
Dynamic installation and removal of component instrumentations
and management application
-
Responsibility for all runtime access to the MIF
data
-
Assurance that at least one group (the component
ID group) is in each MIF file
-
Responsibility for launching the component instrumentation,
if necessary
-
Slicing commands. When a management application
requests more than one attribute value from a component in a single command,
the SP sends commands to the component instrumentation for each attribute
-
Assurance that commands serialize to a component
instrumentation and ensure that commands are allowed to run to completion.
Multiple requests for a particular component instrumentation must be queued
-
Provide event/indication subscription and filtering
-
Forward indications based on subscription and filters
to each registered management application and timestamp incoming indications
before forwarding them
-
Send indications to all registered management applications
that subscribe to receive indications when components are installed or removed
from the MIF database
-
Appear to management applications as a component
with ID 1 (one). As a component, it must support the standard ComponentID
group. Additionally, the DMI SP must support the subscription and filter standard
group. Also, similar to a component, it may define additional groups beyond
the ComponentID group
5.4 Architecture of DMI
Customers may use the DMI-based solution included in the SEA product
in several ways. For example, it may act as another SNMP subagent. Additionally,
DMI-based management applications may be written to directly interact with
SP.
In the SNMP subagent mode, the SNMP requests are mapped to DMI requests
and are communicated with DMI SP. In the direct mode, the management applications
may directly interact with the SP using DMI.
Figure 5-1 illustrates
the overall architecture of how the DMI solution relates to the Enterprise
Agents.
Figure 5-1 DMI and Enterprise Agents
5.4.1 DMI Service Provider
The DMI SP is the core of the DMI solution. Management applications
and Component instrumentations communicate with each other through the SP.
The SP coordinates and arbitrates requests from the management application
to the specified component instrumentations. SP handles runtime management
of the Component Interface (CI) and the Management Interface (MI), including
component installation, registration at the MI and CI level, request serialization
and synchronization, event handling for CI, and general flow control and housekeeping.
Figure 5-2 illustrates
the elements that exist within a single system, or are directly attached.
The management application may be used as a DMI browser.
Figure 5-2 DMI Service Provider
The DMI SP consists of four modules:
-
SP process
-
MI (an interface used by the management application
to communicate with DMI SP)
-
Component Interface (the SP interface for component
instrumentation code use)
-
MIF database associated with the SP
5.4.1.1 Management Interface
The MI functionality for the SEA includes the following:
-
A management application communicates with the DMI through
the MI. A management application requests information about components in
the system by issuing the DMI Get, Set, and List commands. It also registers
with the SP for event notifications and proper filtering capabilities.
-
When an event is generated, the DMI SP looks into
its subscription and filtering table. DMI SP forwards the event in case it
passes through the filtering process. The event is then forwarded to all management
applications that have subscribed with the SP to receive such events.
5.4.1.2 Component Interface
The components communicate with the DMI through the CI. The components'
subagents are created by end users to manage the respective components (devices/applications,
etc.). The following functions are provided by the CI:
-
Registration - Components register with the DMI SP.
-
Sending Events - Component instrumentation
sends an indication block to the SP for processing. The DMI mapper translates
the DMI indication an SNMP trap.
-
Components respond to the DMI SP requests to Get
and Set various attributes instrumented by the component subagent.
5.4.1.3 MIF Database
The MIF database functionality for the SEA includes the following:
-
There is one MIF database associated with the SP. Each component
has a MIF file to describe its manageable characteristics. When the component
is initially installed into the system, the MIF is added to the MIF database.
SP controls all access to the MIF database.
-
No MIF modification mechanism the to MIF database
is provided. If the MIF needs to change, it must be uninstalled and modified
using regular text editor tools, and then installed again.
-
Upon installation and removal of a MIF from the
MIF database, the SP must issue an indication to all registered management
applications.
5.4.2 Invoking DMI Service Provider
After installing, a script file invokes the DMI SP at boot time.The
DMI SP is invoked using the following options:
dmispd [-h] [-c config_dir] [-d debug_level]
Table 5-1 Invoking DMI SP Arguments
|
Argument
|
Definition
|
|
-h
|
Displays the command line usage
|
|
-c confid_dir
|
The full path of the directory containing
the dmispd.conf configuration file
|
|
-d debug_level
|
In debug mode, the process does not run as
a daemon and it displays trace messages on the display screen; depending on
the debug_level (1-5), it prints a specific amount of information
|
5.5 DMI API Libraries
The DMI API library provided with the SEA package is a C library containing
procedures for developing management applications using DMI. The library also
provides a component interface for users to create subagents, including component
instrumentation for the management of components. Additionally, DMI APIs simplify
the processes of installing components in the MIF database and invoking the
SP's component interface.
5.6 MIF-to-MIB Compiler
This utility translates DMI MIF files to SNMP format and generates a map configuration file. The Network Management application (Sun
Net Manager, Enterprise Manager, etc.) may use the MIB to manage the DMI-based
component MIF. The mapper process uses the map file. The map file helps in
mapping SNMP-based MIB variables to the DMI-based MIF attributes.
miftomib "[mifname=] [value value ...]" mifpathname [mibpathname]
Table 5-2 MIF-to-MIB Compiler Arguments
|
Argument
|
Definition
|
|
mifname
|
The name of the mib object generated
|
|
value
|
One or more integers separated by a space
|
|
mifpathname
|
The mif file
|
|
mibpathname
|
The mib file generated
|
5.7 Mapper
The mapper is an SNMP subagent acting as a DMI management application.
It sends management requests to the DMI SP using the management interface.
It also processes events from the component through the SP and passes them
on to the Master Agent. Thus, the DMI-enabled component looks like any other
SNMP-managed component. Figure 5-3illustrates
the mapper and component communication.
Figure 5-3 DMI Mapper and DMI Components
The following sections describe the subagent tasks during the life cycle.
5.7.1 Subagent Initialization/Reinstallation
-
Registers itself with SP, so the SP may provide services,
such as access to the MIF database and indications from components.
-
Builds a translation table for mapping. This is
done by reading the map files created for each component. The translation
table is built when the mapper initially comes up. Later, when a new component
is installed and registered with the SP, the DMI SP sends an event to the
mapper. The mapper then adds the new map file entry into its mapping table.
-
Establishes a connection between the Master Agent
and subagent; it also registers itself with the Master Agent.
-
Builds up the translation table used for SNMP/DMI
mapping and translating SNMP OIDs to DMI objects dynamically.
5.7.2 Invoking the Mapper
The mapper is invoked using the following options:
snmpXdmid -s hostname [-h] [-c config_dir] [-d debug_level]
Table 5-3 Invoking DMI SP Arguments
|
Argument
|
Definition
|
|
-h
|
Displays the command line usage
|
|
-s hostname
|
The name of the host where the SP is running;
by default it is the local host
|
|
-c config_dir
|
The full path of the directory containing
the snmpXdmid.conf configuration file
|
|
-d debug_level
|
In debug mode, the
process does not run as a daemon and it displays trace messages on the display
screen; depending on the debug_level (1-5), it
prints a specific amount of information
|
以 PDF 格式下载本书 (194 KB)