Solstice Enterprise Manager 4.1 Customizing Guide | ![]() ![]() ![]() ![]() ![]() |
Network Management and the Solstice EM Architecture
Network management is the ability to monitor and control network resources. A network management system should allow you to do the following:
- Detect and correct network problems
- Monitor and evaluate network activity
- Monitor, analyze, and change network configurations.
Solstice Enterprise Manager (Solstice EM) is a distributed, multi-user management platform, with a set of user tools, that allows you to accomplish the network management goals. This chapter describes the key aspects of the Enterprise Manager architecture.
This chapter describes the following topics:
- Section 2.1 The Agent/Manager Model
- Section 2.2 Client/Server Architecture
- Section 2.3 Distributed Management
- Section 2.4 Network Management Protocol Support
- Section 2.5 Simple Requests
- Section 2.6 Object Classes and Event Notification Types
2.1 The Agent/Manager Model
Solstice EM is based on the agent/manager model described in the International Organization for Standardization (ISO) network management standards. Solstice EM can exchange monitoring and control information about network resources with software processes called "agents." Any network resource that is manageable through this exchange of information is a "managed resource" which could be an NFS server such as a hub, a cellular base station, or a WAN link; or components such as a circuit, or a router interface, or software entities such as tool or a printer queue. Agents access the managed resource and collect data on behalf of managers.
Agents provide information in response to requests from managers. In addition, agents typically have the ability to issue reports, called event notifications, to managers by their initiative when they detect predefined thresholds or events on a managed resource. Agent/manager communication is illustrated in the following figure.
![]()
FIGURE 2-1 Agent/Manager Communication in Solstice EM EnvironmentA manager relies on a database of definitions and information about the properties of managed resources and the services that the agents support. In Solstice EM this information resides in the Management Information Server (MIS).
2.2 Client/Server Architecture
The management functionality of Solstice EM is based on the client/server architecture. Solstice EM is shipped with a set of tools to carry out network management tasks. For example, the Solstice EM Network Views window provides a graphical, dynamically updated display of your network topology. Colored icons indicate the fault status of devices displayed in the Network Views window. The Network Views Request window allows users to launch Nerve Center requests one-at-a-time to monitor devices for the occurrence of critical events.
In addition, Solstice EM includes an Auto Manager daemon, which you can activate to automatically launch requests to manage routers, links, or to check hosts for reachability. The Auto Manager is the most efficient method for checking thresholds on numerous devices.
Another key tool, Alarms window, allows you to view and sort incoming alarms and acknowledge or clear them. (The Alarms window, Auto Manager, and other Solstice EM core tools are documented in Managing Your Network.)
These and other user tools may be installed on machines remote from the machine that runs the MIS. Multiple users, running Solstice EM tools on one or more workstations, may be connected to the same MIS. You have access to most of the Solstice EM tools from the Solstice EM Network Tools, shown in the following figure. The launcher can be configured to include other tools in addition to those shipped with Solstice EM.
![]()
FIGURE 2-2 Solstice EM Network ToolsSolstice EM tools that are installed on the same machine as the MIS can be displayed remotely by means of an X windows session. Same machine installation differs from the installation of Solstice EM tools on a remote machine. In the latter case, Solstice EM tools connect to the MIS using a PMI connection. In general, tools running on a remote machine consume far less network bandwidth than tools that are run on the MIS machine and displayed remotely.
The multi-user capabilities of Solstice EM are based on Solstice EM's ability to provide consistent management information to components of the network management solution--operators, tools, and other management stations. Solstice EM enables management tasks to be divided across geography and organization with confidence that all users will see the same view of management data. This universal view is particularly useful in fault management scenarios where cooperation among staff members leads to prompt resolution of problems.
2.3 Distributed Management
The powerful Solstice EM platforms the ability to distribute the management information base to multiple Management Information Servers while allowing transparent access management data to users irrespective of the MIS on which the data is located. The data may reside in the local MIS to which the tools are connected or in a remote MIS in another geographical locale.
The Solstice EM MIS Connection Tool is used to set up and take down such connections. Setting up a connection from one MIS to another is analogous to using NFS to mount a file system from one workstation to another.
Access to all objects is achieved through the Management Information Tree (MIT). The MIT is the globally defined object naming or containment tree as defined in the ITU-T X.700 series standards. Every object has a name that distinguishes it from every other object in any MIS. The globally unique name of any object is its full path name from global root (the top of the naming hierarchy) to its position in the tree--analogous to the absolute path to a file in a UNIX file system.
When a connection is initiated from MIS A to MIS B, the local MIT of MIS B is "mounted" into MIS A--and becomes visible in the Navigator of a Network Views window connected to MIS A.
The user running the Network Views window connected to MIS A then has access to the views and devices represented in MIS B. These devices become manageable from the local MIS A. For example, the user could launch Nerve Center requests targeted at a device in the topology "tree" of the remote MIS, and this request will execute on the remote MIS B. Whether the request is running on the local MIS or a remote MIS is transparent to the MIS A user.
Many of the tools shipped with Solstice EM have this ability to access managed resources via MIS-to-MIS connections. However, there are some tools (such as Design Advanced Request window, Security window, and Network Discovery window) that only access data in the local MIS.
The example in the following figure illustrates a possible configuration using MIS-to-MIS communication. In this example, MIS A is a central office "manager of managers" connected to three regional MISs on Net_B, Net_C, and Net_D. The arrow direction from MIS A to MIS Net_B indicates that the MIS-to-MIS connection was initiated from MIS A.
The Network Views window connected to MIS A will see a topology like that shown in FIGURE 2-4. The topology tree for the Network Views window connected to MIS Net_B is shown in FIGURE 2-5. The Network Views window connected to the MIS on Net_D, however, sees only the local MIS, as illustrated in the FIGURE 2-5. If the user running the Network Views window on MIS A were to select the Bldg_1_Subnet view, under the MIS Net_B local root, the Network Views window accesses the data on MIS Net_B and the user sees the same view of this subnet as a user running the Network Views window connected to MIS Net_B.
![]()
FIGURE 2-3 A Sample Configuration Using MIS-to-MIS Communication
![]()
FIGURE 2-4 Topology Tree as Seen by Network Views Window Connected to MIS A
![]()
FIGURE 2-5 Topology Tree as Seen by Network Views Window Connected to MIS Net_B
![]()
FIGURE 2-6 Topology as Seen in Network Views Window Connected to MIS Net_DWhen MIS A initiates a request for data from MIS Net B, MIS A takes on the "manager role" in a MIS-to-MIS communication. As illustrated in the following figure, MIS Net B plays the agent role, responding to requests initiated by MIS A. For information about setting up MIS-to-MIS connections, refer to the Management Information Server Guide.
![]()
FIGURE 2-7 MIS-to-MIS Connection From MIS A to MIS Net B2.4 Network Management Protocol Support
A network management protocol defines the types of messages, encoding rules, and how messages are exchanged in communication between a manager and agent. The Solstice EM shipped to you offers support for four network management protocols:
- Simple Network Management Protocol (SNMP)
- Common Management Information Protocol (CMIP)
- Remote Procedure Call (RPC) protocol (as used by Site/SunNet/Domain Manager)
- Access to JDMK agents via Java PMI
SNMP and RPC are network management protocols used to manage resources in the context of an Internet (IP) network environment. When you install Solstice EM, you are asked whether you want support for IP management, CMIP management, or both. Your choice will be dictated by the types of devices used in your network, and the network management protocols that they support.
2.4.1 RPC Support
Solstice EM is shipped with a suite of agents developed for the SunNet Manager network management platform. These agents communicate with a network manager, such as Solstice EM, using Remote Procedure Call (RPC) protocol. When deployed on systems in your network, these RPC agents can be used by Solstice EM as part of your strategy for managing network resources. The resource may be a machine, a component in a machine (such as a router interface card), or some other resource. The RPC agent may be local to or remote from that resource.
As illustrated in the following figure, SNM agents use Remote Procedure Call (RPC) protocol to communicate with the MIS. However, an SNM agent may act as a "proxy" for the management station, using a different management protocol for gathering information from other agents. The RPC Management Protocol Adapter (MPA) translates requests from management tools, such as Nerve Center requests, into appropriate SNM RPC messages, which it forwards to the RPC proxy agent. RPC responses from the agent are in turn translated from SNM RPC format into the PMI format used for messages internal to the MIS. The RPC MPA may be installed on the MIS machine or it may be distributed elsewhere in your network.
![]()
FIGURE 2-8 Polling RPC AgentsStep-by-step guidance in using RPC agents as part of your network management solution is provided in Chapter 6.
An important aspect of Solstice EM's RPC support is the ability of the Solstice EM MIS to offload threshold-checking activity to RPC proxy agents, which may be distributed to various sites around your network.
SunNet Manager RPC agents have the ability to poll managed resources to check for user-configurable thresholds and send an event notification, called an SNM event, to a specified management station. This polling activity is initiated by a one-shot message from a management station, called an SNM event request. The SNM event request defines the threshold and polling interval for the agent's polling activity. The flow of information using Solstice EM's SNM event request capability is illustrated in the following figure. It illustrates a configuration where the RPC proxy agent is distributed to a machine other than the MIS. The RPC proxy agent may also be located on the MIS machine.
![]()
FIGURE 2-9 Using SNM Event Requests With Solstice EMThe RPC proxy agents, SunNet Manager Event Dispatcher and SNM Event Forwarder are installed on the MIS machine if you select the IP management option (or both CMIP and IP management) during installation. Solstice EM's Request Condition Language (RCL)--a script language used in building Nerve Center request templates--has built-in support for SNM event requests. This capability is described in Chapter 17.
2.5 Simple Requests
Simple Requests lets you create event requests. You can pick specific attributes and set threshold requests. When the threshold is exceeded, an event is generated. The Simple Request tool accepts one or more topology node IDs from the command line.
Simple request templates are used for monitoring:
- disk usage
- cpu usage
- router interface status
A Real Time Graphing capability is used to view data collected via the Data Collection system. The Data Collector can be invoked from the SNMP Browser and the Data Viewer.
2.5.1 SNMP Support
A key component of Solstice EM's Simple Network Management Protocol (SNMP) support is the SNMP Management Protocol Adapter (MPA). The SNMP MPA translates management requests into an appropriate SNMP message and translates messages from SNMP agents into the internal CMIP format used by the MIS. This is illustrated in the following figure.
![]()
FIGURE 2-10 MIS Communication With SNMP AgentsFor example, if you select a device in the Network Views window that is manageable via SNMP, and invoke Solstice EM's SNMP Data window, you can retrieve the current values of SNMP attributes or poll for selected attributes. The SNMP Data window, which connects to the MIS, sends requests for data which are translated by the MIS into SNMP requests via the SNMP MPA. The MPA may be installed on the MIS machine or distributed elsewhere in your network.
A second important aspect of Solstice EM's SNMP support is the Solstice EM SNMP trap daemon, which can be distributed to various sites in your network. SNMP agents have the ability to generate event notifications on their own initiative when certain conditions are detected; these notifications are called traps. The Solstice EM trap daemon listens for incoming SNMP traps and converts them to CMIP event notifications for forwarding to one or more MIS. Like other Solstice EM tools, the trap daemon uses a PMI connection to the MIS.
The trap daemon also has the ability to forward SNMP traps to Site/SunNet/Domain Manager Consoles or other managers. Trap daemon operation is illustrated in the following figure.
![]()
FIGURE 2-11 SNMP Trap Daemon OperationThe trap daemon has a flexible, user-configurable trap-mapping capability which allows you to customize the conversion of incoming SNMP traps to event notifications to create more meaningful alarms tailored to your network management needs. How to customize the trap daemon's mapping of SNMP traps is described in Chapter 11.
A default mapping is provided when you install the trap daemon. With this default mapping, a user who invokes the Alarms window to examine the alarm log can tell at a glance the types of traps that have been logged against devices in their network, as shown in the following figure.
![]()
FIGURE 2-12 Viewing Trap NotificationsThe SunNet Manager SNMP proxy agent, shipped with Solstice EM, provides an additional element of SNMP support. Polling of SNMP devices can be offloaded from the MIS to the SNMP proxy agent, using the Solstice EM Nerve Center's SNM event request capability. Using the RPC MPA, the MIS communicates with the SNMP proxy agent via RPC protocol (over UDP/IP), and the proxy agent talks to SNMP devices. The following figure illustrates the use of the SNMP proxy agent for offloaded polling of SNMP devices.
![]()
FIGURE 2-13 SNMP Proxy Agent Operation2.5.2 CMIP Support
The Solstice EM CMIP Management Protocol Adapter (MPA) supports communication between the Solstice EM MIS and CMIP agents. The CMIP MPA is installed if you select the CMIP management option (or mixed IP and CMIP management) during installation. The CMIP MPA may be installed on the same machine as the MIS or it can be distributed to multiple sites. This distributed scenario is illustrated in the following figure. Alternatively, if the MIS is installed on a more powerful server machine, multiple MPAs could be installed on the MIS machine to "fan out" the message-handling load in communications with large numbers of CMIP agents.
The machine on which the MPA is installed must be running SunLink CMIP 9.0. The MPA can be used with SunLink CMIP 9.0 using RFC 1006 (over TCP/IP) or SunLink CMIP 9.0 over SunLink OSI 9.0. This enables communication with conformant CMIP management entities. SunLink CMIP and SunLink OSI are not shipped with Solstice EM.
![]()
FIGURE 2-14 CMIP MPAs in Distributed ConfigurationFor information about configuring CMIP support, see Chapter 12.
2.5.2.1 Telecommunications Management Network
Solstice EM complies with the Telecommunications Management Network (TMN) standard, an extension of the Open Systems Interconnection (OSI) standards developed through the International Telecommunications Union-Telecommunications Standardization Sector (ITU-T, formerly the CCITT). A Telecommunications Management Network is a network providing surveillance and control over another network. As illustrated in the following figure, Solstice EM's CMIP Management Protocol Adapter (MPA), installed on the MIS machine, can support a TMN Q3 connection to a CMIP agent, which provides access to the managed resources.
![]()
FIGURE 2-15 TMN Q3 Connection to Solstice EM2.5.3 Other Network Management Protocols
Legacy or proprietary network management protocols can be supported by Solstice EM through the development of a custom Management Protocol Adapter (MPA). Third-party developers interested in creating such custom MPAs should refer to Chapter 11 in Developing C++ Applications.
2.5.4 Java Dynamic Management Kit Agents
Java Dynamic Management Kit (JDMK) is a set of Java classes, Java interfaces, and tools that simplifies the development of management services.
Writing object or agent behavior using JDMK allows you to add object behavior without being an expert in the fore mentioned areas. It will also allow dynamic updating of these behaviors, remote access, and a separation from the MIS process on either NT or Solaris boxes. The components necessary to allow this within Solstice EM are:
- JavaBean to Guidelines for the Definition of Managed Objects tool
- A tool that takes as input a package or set of JavaBean classes and outputs a corresponding Guidelines for the Definition of Managed Objects (GDMO) document which is then loaded into Solstice EM.
- JDMK MPA
- An MPA that maps GDMO CMIS requests into JavaBean JDMK calls. This will allow any PMI application to access JavaBeans through JDMK as GDMO objects. This will not allow Java objects to make CMIS requests back to the MIS. This may be achieved via the JMI or the PMI. A JDMK agent will be able to send M-Events to the MIS through the JDMK to CMIS Event listener.
- JDMK to CMIS Event Listener
- A daemon process that converts JDMK JavaBean events to Solstice EM CMIS notifications. JDMK agents will be able to send events through the JDMK event mechanism which will be translated into Solstice EM CMIS notifications. The type of notification generated will be transparently handled as part of the JavaBean to GDMO tool. Any JavaBean which implements the addXXXListener and removeXXXListener will cause the JavaBean to GDMO tool to generate an XXX notification type.
There are three types of users for JDMK agent behavior in Solstice EM.
- End users managing Java agents developed using JDMK.
- Solstice EM application developers using JDMK JavaBean objects to implement agent behavior.
- Solstice EM application developers using remote JDMK JavaBean objects to implement remote object behavior within Solstice EM.
2.6 Object Classes and Event Notification Types
The definition language used to represent management information internally in the MIS is the GDMO, outlined in the ITU ISO/IEC 10165-4 standard. This provides the Solstice EM management platform with an integrated, standards-based view of all managed resources.
Solstice EM is shipped with a variety of GDMO-defined object classes and event notification types that allow you to perform OSI, SNMP, and RPC JDMK network management for most common network elements and topologies. However, the system can be easily extended through the addition of new object classes and event types. All object classes and event types are defined in GDMO documents that are loaded into the MIS. Solstice EM allows you to create your own GDMO definitions, or to add new GDMO definitions that you have obtained from third-party vendors. Also, Solstice EM is shipped with tools that enable you to convert third-party SNMP MIBs and SNM schemas to GDMO documents.
For more information on adding new event types, adding new GDMO object class definitions, converting an SNMP Concise MIB to a GDMO document, or converting an SNM schema to a GDMO document, refer to Chapter 8 in Management Information Server (MIS) Guide.
Sun Microsystems, Inc. Copyright information. All rights reserved. |
Doc Set | Contents | Previous | Next | Index |