Solstice Enterprise Manager 4.1 Management Information Server (MIS) Guide Doc Set ContentsPreviousNextIndex

Chapter 1

Introduction

This chapter introduces the Solstice Enterprise Manager (Solstice EM) Management Information Server (MIS) and its components. If you are a new user, read this chapter to understand the MIS concepts and components.
 This chapter describes the following topics:

1.1 What is the MIS?

In the Solstice EM environment, a Management Information Server (MIS) is a machine hosting an object-oriented Structured Query Language (SQL) database containing information about every component on your network that is managed by Solstice EM. In this model, physical network components are represented as managed objects in the MIS database.

The MIS is considered as the "heart" of Solstice EM. The MIS is not owned or launched by applications that use its services. Rather, the MIS contributes a pool of UNIX processes, often called daemons. These run continuously as background tasks on one or more workstations.

In general terms, the MIS provides the following services:

Functionally, the resources on the MIS can be divided into four general categories:

For data security or logical convenience, you can use multiple MIS databases, with one MIS database on each host. Multiple MIS databases can be linked so that all appear as one database to a given user. For more information about linking multiple MIS databases refer to Chapter 1 in Customizing Guide.


FIGURE 1-1   MIS Architecture

In the above figure, a multiple MIS implementation distributes the management information and processing, making the network more efficient. You can see, from this example, how the MIS is the key module that enables users and applications to deal with the scale and complexity of a large network systems environment.

That's the big picture. To fully understand the MIS, read the following sections that describe the concepts and components of the MIS.

If you are an experienced network administrator, engineer, or technical support user, you are probably familiar with the MIS concepts and components. The information most interesting to you may be the architecture and implementations within
Solstice EM. For users who are less experienced, the detailed information about concepts and components is crucial for understanding what the MIS contributes to Solstice EM.

1.2 MIS Concepts

This section briefly describes the following concepts of the MIS:

1.2.1 Network Resources as Objects

One of the most important MIS concepts relates to how it manages resources. The MIS keeps track of all resources by considering them as objects. The term managed objects is used throughout Solstice EM to refer to objects managed by the MIS.

Graphical objects represent objects that reside in agents (remote objects). They include hardware, software, static, and dynamic icons. The following figure illustrates an example of these objects for a network.

A managed object refers to a physical device such as a workstation, a router, or a hub. It can also represent logical entities such as a Local Area Network (LAN) or an alarm log.


FIGURE 1-2   Network Views Window

Considering network resources as objects, the MIS manages activities and information sent through the network. Also, the MIS manages information about logical entities such as routing tables and printer queues. Objects include servers, clients, hubs, routers, and other hardware and software resources that are part of your network.

Because the MIS is a repository for all management data and functions, it makes data about managed objects available to its clients, both applications and services.

The MIS provides an extensible set of management functions and an environment for implementing and manipulating managed objects in your network.

1.2.2 Objects and Applications

Applications access the MIS object services by connecting to the MIS through a Portable Management Interface (PMI), as shown in the following figure. The MIS then makes data about managed objects available to applications.

From applications, users can create, delete, update, initiate action, register for events, and request data about local or remote objects.


FIGURE 1-3   How Applications Access the MIS Data

1.2.3 Agents

Solstice EM manages one or more managed objects, each containing an agent. The agent is the software that Solstice EM communicates with in order to manage the managed object. Agents report the status of resources and respond to inquiries about resources. The MIS communicates with these agents to monitor and manage network resources.

1.2.4 Management Requests

The MIS receives management requests through the PMI, causing management applications to direct activities to and from managed objects. The MIS then returns the results of commands to management applications through the PMI.

A request contains an operation, target object, and parameters. Through requests, management applications can:

For more information about requests, refer to Chapter 4 in Managing Your Network.

1.2.5 Remote or Collaborating MISs

Depending upon your network and resources, you may want to implement a multiple MIS architecture. One MIS does not duplicate another; each manages a different portion of the network (often called a domain). This configuration allows Solstice EM to be a true distributed system.

The following are common reasons for having more than one MIS:

Each remote or collaborating MIS routes management information to the managing MIS. In an environment where two or more MISs need to exchange information, transfer information, or act on behalf of one another, one MIS assumes the role of manager when requesting information from another MIS.

There is no explicit MIS-MIS interface. One MIS communicates with another through a PMI. The MIS locates the managed information and executes the request. Solstice EM applications are multi-MIS aware, so that a user can access and manipulate remote objects.

1.3 Components

This section briefly describes the major components of the MIS. To make data about network resources (managed objects) available to clients, the MIS uses the following components:

1.3.1 Event Distribution System

The Event Distribution System (EDS) provides event distribution to the Solstice EM components. The EDS has three components:

EDS enables an event source to send events to the event listener. The event sources send the events to the event distribution component. The event distribution component performs the discriminator evaluation (a filter) of the events and forwards the event listeners, if the events match the discriminator of the event listeners.

The event distribution component maintains a list of discriminators for a list of event listeners.

The event flow mechanism is illustrated in the following figure.

FIGURE 1-4   Event Flow

The event distribution component has two entities:

The EA is an event repeater that recieves events and forwards it to a number of event sinks . Each event sink maintains a list of discriminators and listeners.

Each event listener which asks for events gets assigned to one of the event sinks. For every event the event sink receives it goes through its set of discriminators, performs discriminator evaluation, and then sends the event to the listeners if the discrimination matches the event.

1.3.2 Naming Service

EDS relies on the Naming Service (NS) to provide for proper translation of AE-title representing the `listeners' to their address. NS allows the unique identification of Solstice EM processing entities via Application Entity Title (AE-title) names. It provides an AE-title data storage of records that are indexed based on AE-title names. NS has two components:

The AE-title interface provides a uniform and simple way for NS users to access the Name Server from their process space. The NS provides the central data repository support of the AE-title names. The following figure illustrates the AE-title interface and NS.


FIGURE 1-5   Name Service Components

Requests are sent to the NS to query or modify AE-title name entries. These requests may contain actions and action parameters for the NS Generalized Definition for Managed Objects (GDMO) object to perform. The NS will send back only a response for a simple query. The request causes a modification to the NS data base, the NS will issue a change message in addition to a response.

The AE-title interface in the PMI is equipped to handle changes issued by the NS. The following figure illustrates the request message flow and change message flow of the NS.


FIGURE 1-6   Name Services Message Flows

1.3.3 New Application Entity Title Format

In releases prior to Solstice EM 3.0, the MIS Manager uses a non-specific format to represent the Application Entity title (AE-title) of the MIS that is stored in the managed objects it creates (such as the EFD object and the Agent entry object). In Solstice EM 3.0 and above, the AE-title of the MIS assumes a new format that is Sun-specific.

The following table provides an example of both the old and new AE-title formats for an MIS hosted on node 129.146.75.88.

TABLE 1-1   AE-title Formats
Format Example
Old
 1.2.129.146.75.88
New
 1.3.6.1.4.1.42.2.2.2.14.129.146.75.88.3.0.1.0.


The fields contained in this new format are described in the following table.

TABLE 1-2   AE-title Fields
Field Number string from example AE-title "1.3.6.1.4.1.42.2.2.2.14.129.146.75.88.3. 0.1.0"
Sun Product ID
 1.3.6.1.4.1.42.2.2.2.14
IP
 129.146.75.88
Version
 3.0
Type and Application Entity Qualifier
 1.0


If a Solstice EM MIS is connected to an MIS of a previous release (managing it), the AE-title of the agent objects and the Event Forwarding Discriminator (EFD) will have the new format in both the MISs.

If an MIS of a previous release is connected to a Solstice EM MIS (managing it), the agent objects and the EFD will have the old AE-title format in both of the MISs.

1.3.4 Portable Management Interface

Although there are potentially many interfaces to Solstice EM, only one is required by the architecture. This is the high-level use of the PMI.

The PMI defines the management protocol, management services, and transport mechanism for all components of the Solstice EM platform. The MIS uses the PMI to communicate with applications and agents through Management Protocol Adapters (MPAs).

Management applications direct managed resources through requests transmitted to the MIS through the PMI. Subsequently, the MIS returns the results of commands to applications through the PMI.

The PMI provides the following:

1.3.5 Management Protocol Adaptors

MPAs translate information between managed objects and the MIS. For example, if you have a network resource that uses the Simple Network Management Protocol (SNMP), then the SNMP MPA receives data from an SNMP agent, translates the data into the PMI, and sends the data to the MIS.

In Solstice EM, the following three MPAs are standard:

To enhance performance and scalability, you can distribute MPAs and add other MPAs.

1.3.5.1 CMIP MPA

The CMIP MPA is a separate UNIX process which uses the PMI to fulfill CMIP requests sent by the MIS. For more detailed information, refer to Chapter 4 in Managing Your Network.

1.3.5.2 SNMP MPA

The SNMP MPA is a separate UNIX process that uses the PMI to fulfill SNMP requests sent by the MIS. The Solstice EM now supports SNMP and SNMP v2c. For more detailed information, refer to Chapter 4 in Managing Your Network.

1.3.5.3 RPC Management Protocol Adaptor

The RPC MPA is a separate UNIX process that uses the PMI to fulfill RPC requests sent by the MIS. For more detailed information, refer to Chapter 4 in Managing Your Network.

1.3.5.4 Other Management Protocol Adaptors

Solstice EM accommodates other MPAs. For information on how to add an MPA, refer to Chapter 11 in Developing C++ Applications.

1.3.6 Management Information Tree

The Management Information Tree (MIT) is a software representation of the structure that organizes access to all information stored in the MIS, as shown in the following figure.

.

FIGURE 1-7   Management Information Tree

Every network resource (managed object) known to the MIS is represented in the MIT. The objects in the MIT include network devices such as routers and hosts, virtual objects such as queues, filters, and events, and objects that the MIS itself or applications create.

Even when you implement a multiple MIS architecture, one global MIT provides a single naming scheme for all managed objects, as shown in the following figure.


FIGURE 1-8   Naming Schema in Multiple MIS Architecture

In addition to providing object management services for managed objects, the MIT represents managed objects in a way that takes advantage of object oriented programming.

Using Solstice EM administration tools and the PMI, you can add new objects as descendents of existing objects or as entirely new objects.

1.3.6.1 MIT Object Naming

All access to managed objects is achieved through the MIT. It is the globally defined object naming or containment tree as defined in the ITU-T X.700 series of standards. Every object in the MIT is defined in terms of its superior object in the tree. The ultimate superior of the MIT or the top of the containment tree is the root, similar to root in the UNIX file system.

All managed objects must be named unambiguously within the framework of inter-operable management. That is, every managed object must have a name which distinguishes it from all other object names in the world or global name space. The globally unique name of any object in the MIT is its full path name from the root to where it lives in the tree. This standard is defined in the ITU-T X.700 series of documents as the Distinguished Name (DN) of the object in global form.

The MIT or containment tree spans all managed systems. For example, if all management systems in the global name space were connected, and a management application submitted a request starting at the global root, that application would be able to see every object defined in the global name space. This global name space would include thousands of management systems from many different companies.

For every object class defined, there is an attribute that is defined as the naming attribute. That attribute and its value make up what is referred to as an Attribute Value Assertion (AVA). Each managed object instance in the MIT is identified within the scope of its superior object by its AVA. Therefore, the type of name you give an object determines the position of the object within the MIT hierarchy.

1.3.6.2 Name Binding

A containment relationship is an object class. That means an instance of class X can be created as a subordinate to an instance of class Y only if a name binding exists that specifies that class X can be a subordinate class to class Y. Therefore, when the instance of class X is created it will be named using the attribute identifier specified in the WITH ATTRIBUTE clause of the name binding and that attribute's value. The following code example shows a name binding.

CODE EXAMPLE 1-1   Name Binding Example 1
	 SUBORDINATE OBJECT CLASS contact

	 	 AND SUBCLASSES;

NAMED BY SUPERIOR OBJECT CLASS customer

	 	 AND SUBCLASSES;

WITH ATTRIBUTE contactID;

REGISTERED AS

	 	 {forum-NameBinding 93};

In the above code example, the managed object class exampleClass has been previously defined and one of the properties specified for the class is an attribute named objectName. The attribute exampleID is registered as 0.1.2.3.4.5.6 and is defined as being an ASN.1 INTEGER.

The example name binding dictates that instances of the managed object class, exampleClass, can be created under system (system is defined in the ISO DMI) using exampleID as the naming attribute.

If additional name bindings exist for a subordinate class, they can specify other superior classes and different naming attributes. The following code example shows a second name binding.

CODE EXAMPLE 1-2   Name Binding Example 2
	 SUBORDINATE OBJECT CLASS	 	 	
 	 	 	 	 	 	 	 	
 exampleClass ;

	 NAMED BY SUPERIOR OBJECT CLASS root ;

	 WITH ATTRIBUTE	 	 	 	 	
 	 	 	 	 	 	 exampleID ;

REGISTERED AS { 0 1 2 3 4 2 } ;

The code example specifies that instances of exampleClass can be created under root, and those instances will be named using exampleID. The naming attribute is specified in a name binding provided by the name binding designer. A naming attribute other than exampleID could easily be used in this second name binding example.

For the following discussion, the value is 10 for the naming attribute, exampleID.

1.3.6.3 Name Types

Following are the name types for object instances:

1.3.6.4 MIT Organization and Standards

The MIT is organized into parts:

The standards-based object definitions are specified in OMNIPoint I, which is a set of standards, implementation specifications, and tools developed by the Network Management Forum. These are based on:

Solstice EM objects define and control the behavior of the MIS.

1.3.7 Metadata Repository

Within the MIS, the Metadata Repository (MDR) is a storage area holding the descriptions of managed objects. A description for every object known to the MIS is stored in the MDR. This data encompasses everything from the syntax referring to an attribute, to the composition of an object package.

The MDR is initialized and updated by using the GDMO and ASN.1 compilers. The MIS allows dynamic updates to the MDR, so you do not need to shut down the MIS for updates to occur. The following figure illustrates the relationship between the MDR and compilers.


FIGURE 1-9   GDMO and ANS1 Compilers Update the MDR

The definitions on how the MIT is constructed, based on containment relationships, are in the MDR. Other components of Solstice EM use the MDR as follows:

1.3.8 Nerve Center

The Nerve Center is the portion of the MIS that detects conditions in a network and takes actions based on those conditions.

The Nerve Center provides a Nerve Center Interface (NCI) library, that supports user-defined instructions for detecting and responding to conditions and events in the network.

Applications and users create request templates, then have the MIS apply the templates to a set of managed objects. The MIS creates manager objects that poll managed objects in a network, or listen for event notifications, based on request templates.

For more information about the Nerve Center and request templates, refer to the Customizing Guide.

1.3.9 Alarm Service Module

The Alarm Service module updates and stores the state of managed objects in the MIS. All alarms arrive at the MIS as event notifications, regardless of their origin.

The Alarm Service module provides a view of live alarms in the Alarm Log, contrasted to the Log Entries module, which shows a historical view of alarms in the Alarm Log.

The severity of each alarm in the Alarm Log is indicated by an icon with a corresponding color--for example, red for the highest severity alarm.

1.3.10 Data Logging and Storage Module

Data local to the MIS is stored in a database. This local data consists of all objects that are configured to be persistent and are created in the MIS by the PMI. The persistent storage of MIS objects allows for restarting an MIS without data or configuration loss.

The MIS receives, processes, and stores event notifications as log records in the database. Using the Event Logs module, you can retrieve, update, or purge records from the database.

1.3.11 Compilers

Compilers provide a method for you to add new managed object definitions to the MIS. If your application refers only to object classes already known to the MIS, you will not need the compilers.

For more information about adding new object classes, see Chapter 8.

1.3.12 Message Routing Module

The Message Routing Module (MRM) manages switching and transaction processing. The MRM routes messages to other modules such as protocol driver modules, management protocol adaptors, client applications, object instances, and event management.

The MRM performs scoping, including atomic operations, on local objects. It requests routing information from the MIT.

The MRM receives and sends messages through a low-level portable management interface (PMI), the Object Access Module (OAM), and the Event Management Module (EMM).

1.3.13 Object Access Module

Much of the MIS's power comes from the ability to specify what objects can do and how they behave. The OAM processes management requests from the MRM on a per-request basis. The MRM provides the object framework for creating and maintaining the MIT.

Applications and users do not need to know where managed objects are in the network, because the OAM distinguishes between local and remote objects. If a managed object is local to the MIS, the OAM accesses the object directly. If an object is remotely located, then the OAM routes requests through the PMI to the agent that contains the object.

1.3.14 UNIX Processes (Daemons)

The following table contains the names of the MIS processes (daemons) in a UNIX environment.

TABLE 1-3   Processes in a UNIX Environment 
Process Description
em_autoexd
Automatically extends database tables when they get full.
em_autod
 Monitors creation and deletion of objects in the MIS, starts requests for new objects and stops requests when objects are deleted.
em_cmip
 Implements CMIP MPA functions; starts during product installation.
em_datad
 Collects performance and accounting data.
em_eds
 Represents an EA or an event sink that handles Event distribution.
em_log
Implements log server MPA functions.
em_log2hist
 Saves logs in historical files; see Chapter 6.
em_login
 Listens to connection requests for password authentication.
em_mis
 Implements the majority of MIS functions; starts when em_services command is run.
em_mpa_jdmk
 Allows users to create agents in Java.
em_mpa_snmp
 Implements SNMP MPA functions.
em_mpa_rpc
 Implements RPC MPA functions.
em_ncam
 Handles Nerve Center actions; starts when em_services is run.
em_nnmpa
 Starts the global nickname (FDN translation) server. Alarms and Event Logs use the global nickname server.
em_ns_server
 Naming services.
em_purged
 Purges old alarms from the Alarm Log.
em_sim
 Simple Request Manager.
em_snmfwd
 Forwards SunNet Manager events to the MIS for processing. Registers with the SNM 2.x na.event daemon, receives events as would an SNM console. Forwards events as snmAlarmEvents and traps as snmAlarmTraps. No data reports are forwarded. em_snmfwd has effect only if na.event is running. em_snmfwd starts when the em_services command is run.
em_snmp-trap
Listens on port 162 for SNMP traps; is a separate process from the MIS. Traps are converted according to a user-defined mapping to CMIP notifications and forwarded to the MIS. This daemon can be distributed to other hosts.
em_srm
 Simple Request Manager.
em_toposrv
 Handles operations related to topology objects.
oninit
 Database daemon.


Sun Microsystems, Inc.
Copyright information. All rights reserved.
 		Doc Set  |   Contents   |   Previous   |   Next   |   Index