The autonomic manager is an embedded computer application that runs continuously, responding to changes in a system being managed and acting on behalf of a user. Autonomic Managers are examples of embots. An autonomic manager has the following characteristics:
- operates on the management plane
- lightweight
- autonomous; can operate without human involvement
- social; it communicates with other autonomic managers
- mobile; can move when resources move
Autonomic managers--embots--are trusted applications, designed to manage specific aspects of an operating system (e.g. services, processes or files in the file system) or its hosted applications (e.g. Microsoft Exchange). Embots run on top of an Embot Application Framework (EAF), which executes within the management plane (See Figure 2). Embots implement one or more policies designed to manage some aspect of an application, operating system, device driver or hardware. Embots are lightweight and achieve their expressive power through properties of self-organization and communication with other embots. Embots reason about changes observed within the managed element and can act autonomously; i.e. can take actions without system administrator involvement.
In some cases, embots may ask a system administrator to confirm that an action should be taken; establishing the right level of trust being a straightforward matter of corporate policy. Finally, embots are mobile; this being necessary in order to support migrating virtual machines. If a virtual machine migrates from one physical machine to another, the embot collective managing it does too! So, what is a management plane?
A management plane is a computing environment in which management functionality runs; e.g. embots. A management plane can be physical or virtual. An example of a physical management plane would be an Open Platform Management Architecture (OPMA) card running a framework hosting embots. An example of a virtual management plane would be a privileged virtual machine such as Xen's domain 0. The service plane represents the applications, operating system and hardware being managed. In Figure 1, the service plane is represented by the Managed Element.
The management lifecycle
Figure 3 provides an overview of the lifecycle of an autonomic manager. The environment supporting the lifecycle consists of several important components: the Autonomic Controller Engine (ACE), the Management Console (MC), the Module Development Environment (MDE) and Management Modules (MM). ACE is an example of an autonomic manager shown in Figure 1 and consists of the Embot Application Framework and Embot Execution Environment shown in Figure 2.
The MC is a secure web portal through which all deployed ACEs are centrally managed. The MC centralizes notification and escalation of problems that the ACE cannot solve (e.g. hardware failures). The MC also acts as the integration point for enterprise management consoles such as Microsoft's Operation Manager (MOM) and HP OpenView. The MC is also the point through which group deployment of software to ACEs is coordinated.
The MDE is used to create and edit management modules. A management module is the unit of deployment of autonomic management. As such, it consists of embots that assist in managing the server and its applications along with utilities to support them. Management modules are deployed to one or more ACEs via the MC. One or more management modules can be deployed to an ACE. A module is instantiated in a module archive, similar in structure and intent to a web archive used by application servers. Simply put, a module archive is a directory structure of a standard format that contains managed element models, classes and resources that encode a management scenario of interest. A module archive may also contain dynamic link libraries that may be required in order to augment the low level instrumentation on the host and HTML documents that allow a user to interact with the run time version of the module for purposes of configuration.
From an autonomic manager's perspective, a module is comprised of a set of scenarios related on a conceptual level--for example there might be a module designed to manage printers, another to audit host performance in order to establish normal levels of resource consumption, and a third to enforce security.
A scenario encompasses data and host information to be monitored, as well as the processing of this information: conditions, filters and thresholds to be satisfied, and actions to be taken, for instance events to be logged and alarms to be raised. Modules are completely pluggable, meaning that they can be installed, updated or reconfigured at runtime, and require no modifications to the engine framework.
