Having described the main considerations to include in a DCMTI, the following diagram shows the layout of the management architecture; the following sections describe each component in detail.
FIGURE 3 Management Architecture Layout
A key point this drawing makes is the separation of process from the DCMTI. The agents collect only data to determine system status and health at all layers (facilities, network, compute and storage, application infrastructure (LDAP, RDBMS, NTP, DNS and so forth) and the business application for all aspects (FCAPS). The management servers and framework/correlation server provide filtering and automatic resolution. Only when human interaction is required (passive or active) is the information forwarded to the process management system.
The agents collect the matrix to support the views. They focus mainly on health and status. The thresholds set here are only as they relate to the system monitored. They do not include the decisions about business severity, or whether or not they conform to an SLA. That is done in the process management layer.
For example, a disk fails and, as a result, triggers a severe alarm because it should be fixed as soon as possible. However, the trouble ticket (in the process management tool) might have a medium priority because the failed disk was mirrored and no service interruption occurred. The agent triggers the first alert; the process management tool sets the ticket priority.
These are the specialized tools that accept the alerts from specific agents. A Sun_ Management Center software agent talks to the Sun Management Center software management server and determines whether the error can be fixed or should be forwarded to the framework server. A BMC Knowledge Module (KM) will do the same when monitoring the Oracle database.
These are the main tools for the respective support specialists.
Correlation and Framework Server
All relevant alerts are forwarded to this server by the management servers to allow correlation and a single view into the health of the infrastructure. Here the decision is made to automatically create a ticket and start the appropriate resolution process.
The correlation server can also be a management server for its own specific purpose. For example, Tivoli has some configuration management agents that can report to the same Tivoli server that acts as the framework server.
Almost all management servers require a proprietary console to allow management of the management server. Consoles can be started on different systems to provide specific views into the infrastructure. They enable the support specialists to "drill-down" to find more information regarding an open ticket.
Consoles are often easily distributed and more than one console can often connect to the same server to provide multiple views for different purposes.
Process Management Server
This is the server that takes the information and alerts from the DCMTI and makes decisions about priority, routing, and which process to use. It is often a Helpdesk-oriented tool like Remedy or ClearCase that has features to meet the previous described requirements.
The main objective for a process management tool is to streamline the processes and assure a closed loop to keep requests from "falling into the cracks."
With these components in place almost all IT management processes can be supported by providing timely, integrated and consolidated information, streamlining process steps, and creating good visibility in the main aspects of the managed IT environment.