Enterprise Management Architecture

ing functions planned for Phase V First, network managers wo uld have to be able to manage a l l the Phase V components i n a consistent man ner. A method was needed to build Phase V management components that wou ld give the same general look and feel and the same model ing approach to a l l components.

Seco nd, Phase V network ma nagement would have to be extensible. The Phase V network archi­ tecture was being designed to a ll ow the use of m ul­ tiple modu les that would provide the same or similar services at each layer and to simul taneously support multiple-layer protocols in a network. Therefore, we designed the Phase V ma nage­ ment architecture to transparently assi m i late new devices and technologies. Our ma nagement archi-

Digital Technical journal Vr;t. 5 No. J Winter 1993

tecture had to become as extensible as the network architecture.

Final ly, since Phase V was designed to be an open architecture, ma nagement of Phase V components would have to be effective in a multivendor net­ work. Our design had to ensure that the ability to provide effective management of network compo­ nents was independent of the vendors supplying them.

The individual management mechanisms used in Phase IV could have been extended to accommo­ date all the changes plan ned for Phase V. However, we fel t i t was time to revisit the basic network man­ agement arch itecture to see if we cou ld find a u n i­ fied approach that wou ld provide a superior solution.

Enterprise Management

Architecture

We began our Phase V development project by examining i n deta i l the requ irements for a new network ma nagement archi tecture. Our goal was to design an open arch itecture that al lowed fo r consis­ tent management of an extensible array of network components in a multivendor environment. As we identified the specific requ i rements t ha t wou ld have to be ad dressed to meet this goal , we realized that we had the opportun ity to develop an architec­ ture that went beyond ma nagement of Phase V net­ works. We real i zed that we could provide an arch itecture fo r the ma nagement of both networks and systems. The arch i tectu re eventual ly became known as the Enterprise Management Architecture or EMA.

DECnet Open Networking

Early in the project, we recogn ized that the con­ ceptual separation of manageable components from the software that manages them was a fu nda­ mental design pri nciple.

EMA

therefore d istin­ guished entities, the basic components of the network that had to be managed, from directors, the software systems and accompanying applica­ tions used by managers to manage the components, as shown in Figure 1.

formal ly, an entity was further spl it into a ser­ vice element, a ma naged object, and an agent. The service element is the portion of the entity that per­ forms the primary function of the entity, e.g., a data l in k layer protocol module whose primary purpose is com m u nication with a peer protocol module on another machine. The managed object encapsu­ lates the software that implements the fu nctions supported by the entity for its own management. For exa mple, it responds to management requests for the current val ues of state variables or to requests for the values of certai n configuration vari­ ables to be set to n ew values. The agent is the soft­ ware that provides the interface between the director and the managed object. The agent encodes and decodes protocol messages it exchanges with the d irector and passes requests to and receives responses from the managed object.

Informally, we general ly equate the m anaged object and the entit y because the managed object defines what the manager can monitor and control in the entity.

A d irector was modeled as a layered software system that provides a management-specific envi­ ronment to management appl ications. A director was split i nto a framework, a management i nforma­ tion repository

(MIR),

and separate configurable software modu les cal led management modu les. The director kernel provides common routines usefu l for the layered software modu les, includ ing

I / / / � - - - · I KNOWLEDGE, I I POLICIES, AND I PROCEDURES 1 1 - - - - _ _ _ J

0

D I R ECTORS MONITOR ENTITIES CONTROL MANAGEMENT MANAGER _PROTOCOL I I S

Figure 1 The Basic Entity/Director Split

services such as d ispatch (location-transparent exchange of management requests and responses with enti ties), encodi ng/decod i ng, data access, data dictionary access, and event m anagement. Taken together, the director kernel and the agent provide a framework for managed objects and man­ agement appl ications to interact. The framework provides a n application programming in terface

(API) to m anaged object and management module

developers. The

M I R

contains data about particular entities as wel l as information about the structure and other properties of entity c lasses, which the director software also knows.

Management modu les were d ist ingu ished as presentation, fu nction, or access modu les. Presen­ tation modules implement user or software access to the d irector management modu les that is device i ndependent and style dependent. Function mod­ ules provide value-added management fu nctions that are partially or completely entity indepemlent, such as n etwork fau l t diagnosis, event or alarm han­ d l i ng, or h istorical data record ing. Access modu les provide a consistent i n terface to the basic manage­ ment functions performed by entities. In add ition, they i nclude one portion that maps operations on entities i n to the appropriate protocol primitives and another portion that i mplements the protocol engine for the relevan t m anagement protoco l. Figure 2 shows t he components of a director and an entity.

Although users can convenien tly interact with systems through graphical user i n terfaces (GU!s), sophisticated users wished to preserve a command line i nterface (CLI) they cou ld use to specify com­ plex management requests quickly. Therefore, we

� - - - -

� - - - -

1 MANAG I N G SYSTEM I MANAGED SYSTEM I I I MANAGEMENT I I MODULES I I (APPLICATIONS) I I API I API MANAGED OBJECT

1-r-:::_-:::_-:::_-:::_-:::_-:::_ -:::_

�_ -

_r_

-_ -_ -_ -_ -_ -_

--:;

I I FRAMEWORK _I

I I DIR ECTOR

�

GENT I

I I KERNEL _{MANAGEME NT I}

PROTOCOL

I I M I R M I R I

I I _{I I}

� �������J - - c-:::_-:::_-:::_-:::_-:::_-:::_-:::_ J

Figure 2 A Framework View ofEMA

developed a single, extensible command l anguage that wou ld al low human operators or software pro­ grams to com municate requests to management modu les and (u ltimately) entities in a consistent fashion. This work developed into the network control language (NCL). An NCL com mand specifies an entity, an operation to be performed by the entity, a l ist of arguments (if any), and a l ist of quali­ fiers (for specifying users, passwords, paths, fil ter­

ing values, etc.).

Digital's DECmcc Management Director is an i mplementation of an EMA d irector.' The DECmcc product provides a platform for the development of new management capabil it ies and offers specific Phase V management capabi lities as we l l as a nu m­ ber of generic net'work management tools. The DECmcc director supports both GUT and NCL CLI user interfaces.

In document dtj v05 01 1993 pdf (Page 119-121)