In this section, we outline the architectural blueprint for building autonomic systems. In subsequent sections, using the conceptual architecture, we point out the touch points where standards play a critical role and highlight existing standards as well as point out gaps. Figure 1 depicts [2] the details of a single autonomic manager. The components and functions of a single autonomic manager often referred to as the "MAPE loop" for Monitor, Analyze, Plan, and Execute, supplemented by a Knowledge base are briefly described below.

Figure 1: Single-node autonomic manager
click image for larger view
 

Monitor

An autonomic manager monitors instrumentation data from multiple sensors in a system. The sensors "sense" various aspects of the state of the monitored computing system. This can include aspects of the hardware instrumentation (such as temperatures at various points within the hardware platform), ambient information (such as the environmental temperature, physical intrusion of the device), and aspects of the software components (such as various performance-monitoring counters of the operating system and specific counters for application monitoring). Data can be acquired from sensors by polling at specified intervals or can be collected asynchronously when specified thresholds are exceeded.

Analyze

This component of the autonomic manager contains the intelligence required to interpret and correlate the above mentioned instrumentation data. This component usually has the ability to consult historical data and to compare them with current state to detect significant changes. Optionally, in conjunction with the knowledge base component, it may predict the likely future states of the system and use them, as appropriate, for performance adjustment or to work around anticipated faults. System topology, data, and control flows may be captured in formal models to facilitate this analysis. For example, this component may be able to examine patterns of service requests presented to a Web farm and, based on known patterns, conclude that it is likely to result in a spike in such requests in the near future.

Plan

Once an analysis report of the situation is completed, the planning component can define a series of control actions that should bring the system to a normal operating range. Note that in devising these actions; the planning component is guided by the applicable management policies that are in effect. These policies may be defined by the operator or by the next level in the autonomic hierarchy. For example, in the situation of a likely overload of the Web farm, this component may detect that the maximum response time for the client, specified by the Service-Level Agreement (SLA) in effect, will be violated by the predicted surge in load. Using this information, the Plan component decides that the right course of action is to supplement the Web farm with additional front-end Web servers to avoid this SLA violation.

Execute

This component receives the series of action steps from the planning component, and puts the plan into action. It activates appropriate control points, or effectors, on the managed platform following the proper sequence and timing. For example, given the solution of supplementing the front-end Web servers with additional resources, this component could activate additional physical or virtual machines, provision them as Web servers, and add them to the Web farm.

Knowledge base

This serves as a repository of knowledge, such as historical data and policies, which can be utilized by the other components in their operation. Knowledge can be obtained from multiple sources: from peer autonomic managers, a management console and operator, or can be obtained using machine-learning techniques from prior observations of system states and corrective changes that were found to be effective.