1.2 Management Architectures

Let's look now at the architectures of the management systems that were successful during this history.

The initial management systems were tightly coupled with the operating systems and resources to be managed. Typically, the resource to manage was running on the same host as the management system. In such cases the resources to be managed interacted directly with the management system. Later, management systems were developed by vendors that had not developed the operating system. These vendors had to support the management of a variety of resources that were not on the same host as the management system.

Management architectures consist of four parts :

1. Organizational model . The organizational model defines the entities and roles involved in the architecture and their composition. In this section we will discuss the manager-agent model, which contains the roles of managed resource, agent, subagent, midlevel manager, and management system.

2. Information model . The information model defines the structure of the management information so that the different entities can understand the management interfaces exposed by instrumentation to enable manageability.

3. Communication model . The communication model defines the operations and protocol for accessing the information model.

4. Functional model . The functional model defines generic management services that can be used to manage any resource.

Most management systems today use variations of a manager-agent management architecture. Let's look at the details of this particular architecture. We will then look at some management standards and the parts of this architecture that they support. As Figure 1.3 shows, this architecture always contains the managed resource, agent, and management system roles. Subagent and midlevel manager are often seen as well.

Figure 1.3. Manager-Agent Architecture

Sections 1.2.1 through 1.2.5 examine the details of each role in the manager-agent architecture.

1.2.1 Managed Resource

The computer system, network, or application component that needs to be managed is the managed resource. Not all resources in an IT environment need to be managed. Some groups of resources are managed as a functional unit rather than individually. Looking specifically at Java ^[12] technology, managed resources can be stand-alone applications, client-server applications, and Web applications. The components of these applications can be managed resources as well. Such components may include Java Virtual Machines (JVMs), containers, servlets, and Enterprise JavaBeans (EJBs) on the server, or browsers and containers on the client.

The managed resource is responsible for exposing appropriate management data for use by a management system mapped into the information model supported by that management system. At a minimum, the managed resource should expose a description of itself, its configuration data, and some performance metrics and status indicators that reflect its health.

The managed resource is also responsible for interacting with the management system via its agent using the communication model, operations, and protocol that the management system and its agent support. Such interactions include responding to requests from and sending unsolicited events to the management agent. Requests from agents may include getting data, changing configurations, or executing operations. The resource determines which requests it will support and to what degree these requests are supported. The managed resource should also recognize internal errors and log them or notify the management system. The management patterns discussed later in this chapter illustrate common types of support that managed resources can provide.

1.2.2 Agent

The management agent is provided by a management system and supports the communication model and information model of the management system. The agent communicates with both the management system and the managed resources. It is usually running on the same host as a daemon ^[13] or in the same process as the resource it is managing. The agent may support one or more managed resources. Agents embedded in a resource can support only that instance of the resource.

The agent sends data and events from the resource to the management system. It also relays data and command requests from the management system to the resource, gathers the responses, and returns them to the management system. The agent usually provides a programming interface, which may expose or wrap the communication model for the managed resource to use to communicate with it. Some management agents require that the managed resource implement a particular programming interface that the agent invokes to have a request honored.

Standards bodies have specified some standard management architectures that define information models and communication models used for the creating agents in the manager-agent architecture. The three most common are the Management Information Bases (MIBs) and SNMP, ^[14] Managed Object Format (MOF) and CMIP, ^[15] and Common Information Model (CIM) and Web-Based Enterprise Management (WBEM) ^[16] specifications. Some enterprise management systems, such as those from Tivoli and Computer Associates, depend on their own, internal proprietary agent infrastructures .

1.2.3 Subagent

Management architectures in which one agent must support many managed resources use subagents. The subagent is tightly coupled with the resource. Sometimes, it may actually be embedded within the resource. The subagent registers its presence and availability to the agent and then communicates between the resource and the agent. The subagent typically provides two programming interfaces ”one to interact with the resource, and one to interact with the agent. The subagent may transform the managed resource's data from its native format and interfaces to the information model expected by the agent and management system.

It is usually the responsibility of the resource to register its subagent with the agent. The IETF has Request for Comments (RFC) documents for three subagents for SNMP, SMUX, ^[17] DPI, ^[18] and AgentX, ^[19] although none of these are official standards.

1.2.4 Midlevel Manager

The first manager-agent architectures had problems handling the massive numbers of managed resources that could be reporting to a single management system. This became a pain point for network managers in large enterprises using SNMP. To increase their scalability, they needed to reduce the amount of incoming data and events, as well as the number of systems they had to poll directly for availability. To accomplish this they introduced intermediate systems called midlevel managers ( MLM s) into their architectures.

MLMs interact with management systems and a set, or domain, of agents and the management system. MLMs are responsible for aggregating and filtering the information from the managed resource and forwarding pertinent or summary information to the management system. They also poll the managed resources in their domain for availability and forward exceptions to the management system. MLMs increase the quality of information while reducing the rate and quantity of incoming messages that the management systems must handle.

The domaining aspect of architectures using MLMs allows resources to be managed as logical groups according to physical characteristics, like location or type, or by business characteristics, like division or business application. Sometimes architectures that use midlevel managers are called hierarchical management architectures or cascaded agent architectures.

1.2.5 Management System

The management system supports the information model and communication model ”that is, operations and protocols ”of the manager-agent management architecture. The management system may range widely in the amount of functionality it provides. Regardless of the comprehensiveness of that functionality, the management system interacts with the agents to receive and gather information about the managed resources. The management system uses the information to accomplish some of its purpose. This purpose can include all or some of the management applications described in Section 1.8. Management system “initiated requests to the managed resource go through the agent as well.

The management system can be a sophisticated enterprise manager that manages all the distributed, disparate, critical resources, like those available from Tivoli or Computer Associates. The management system may be a domain-specific management system (tightly or loosely coupled) designed to fully manage a particular resource, such as IBM's WebSphere Administration Console. ^[20] Another common type of management system is the resource-specific management system designed to manage a business system like banking, accounting, or customer management.

The management system is responsible for providing the infrastructure and user interfaces to manage the resources. A typical management system receives events from agents, displays them to operators, and takes any defined automated actions. The management system initiates a request to agents to control the resource. It requests data from the agent (which then requests it from the resource) for polling, monitoring, identifying trends, or determining problems. Advanced management systems that use pervasive standard management technologies, like SNMP, may also automatically discover resources in order to reduce management system configuration requirements and produce accurate topology and inventory information.

Management systems generally allow their resource management services to be customized. Examples of customizable features include commands, available statistics, threshold values used to indicate problems, automated actions, and operational policies. With more sophisticated management applications, service-level agreements and business system contexts can be defined as well. Let's take a look at the proprietary and standard management technologies that have developed and how they support the roles in this architecture.