Generic Autonomic Management Framework (GAMF)

[overview] [features] [system architecture] [getting started] [examples] [downloads] [API]

Overview

An autonomically controlled system is a system that adapts itself to its environment without the need for a human administrator. This can be achieved by adding an autonomic manager to the unmanaged target system in order to adapt a specific tuning knob in response to some monitored events. The GAMF is a framework that allows programmers to develop an autonomic manager for any target system without having to (re)implement generic control mechanisms. Scheduling of these generic control mechanisms as well as the management of monitoring data is provided by the GAMF. The bespoken generic mechanisms are based on the autonomic control loop (see Kephart and Chess) and are derived from the autonomic nervous system. They can be described as phases of the control loop (or management cycle) and comprise:

a monitoring phase in which the target system is observed and incidents under consideration are reported as events
an analysing phase in which situations are modelled by extracting and aggregating monitoring data (events); the situations are then represented by abstract metrics
a planning phase in which an action is defined in order to address a specific situation (represented by one or more metrics) as specified by policies
an execution phase in which the determined action is applied via effectors

The GAMF was developed as part of the Autonomic Storage Architecture (ASA) project, is implemented in Java and available under the GNU general public licence.

[overview] [features] [system architecture] [getting started] [examples] [downloads] [API]

Features

Implements a generic autonomic control loop and supports the generation, storing and filtering of events, the scheduling of the extraction of metrics and the evaluation of policies (as well as the adaption of tuning knobs).
Lightweight: The GAMF is a small Java library with fundamental autonomic management functions and very little impact on the target system's runtime.
Simple: The fundamental functions allow "easy-use"; a combination of them however allows complex managers to be built with very little effort.
Generic: Due to its lightweightness and simplicity the GAMF can be used for any system regardless if the source of the system is available or not.
Free: The GAMF is available under the GPL.

[overview] [features] [system architecture] [getting started] [examples] [downloads] [API]

System Architecture

The GAMF provides generic control mechanisms based on an autonomic control loop and a set of interfaces to allow interaction between the control mechanism and system-specific management components (system adapters). System adapters are: event generators and effectors which allow interaction of the control mechanism with the target system; metric extractors and policy evaluators which provide the means for computing a specific response, determined by policies, to an observed situation, modelled by metrics. The following figure illustrates the general architecture by showing the components used for managing a target system. Additionally the flow of information between management components and target system is illustrated.

Figure 1: A target system autonomically managed using GAMF.

An autonomically managed system consists of the originally unmanaged target system and an autonomic manager (which itself comprises system adapters and the GAMF). All system adapters are registered in the GAMF’s system adapters registry. Amongst other features, this grants them permission to access the GAMF’s shared knowledge database in which events and metric values are stored.

System adapters provide operations that correspond to a specific phase of the autonomic control cycle. Their execution (metric extraction and policy evaluation) are triggered by the GAMF, as configured by a system adapter developer (for instance, periodically or at the occurrence/arrival of a specific event). The information about how a specific system adapter is triggered is held in the system adapters registry along with rudimentary access permissions to the shared knowledge database. Access to any data stored in the shared knowledge data base is concurrency-safe. The following types of system adapters are defined:

Event generators provide the GAMF with time-stamped information about specific events in the target system. An event comprises an event type, a time-stamp specifying the generation time of the event and a field for additional information, specified by the system adapter developer. In order to allow unambiguous usage of event types, the types of events generated by an individual event generator can be registered with GAMF to prevent them being used by other event generators. Examples include the un-/successful execution of some process.
Metric extractors are used to extract monitoring data from the shared knowledge database in order to represent a specific situation, modelled by the metric. The metric is specified by the system adapter developer with a metric type, a time-stamp specifying the computation time of the metric value, a field for additional information and one for a numerical metric value. An example of a metric (extraction) includes the extraction the number of events of a specific type during an observation time period.
Policy evaluators evaluate the policy specified by the system adapter programmer. A policy is used for determining which action has to be carried out in response to the target system's current situation (represented by specific metric values). An example includes the adaptation of some tuning knob if a metric is above a specific threshold.
Effectors carry out the specific action in the target system when being triggered. An effector is envisioned to be triggered by the policy evaluator to change a controlled system configuration parameter and to make the system aware of the change. An example includes the adaption of a polling interval.

GAMF includes a flexible mechanism to filter for specific events or metrics in the shared knowledge database. Filter options include filtering for events or metrics of a specific type, and metrics or events recorded within a specific time window. To allow reuse of system adapters or simply to organise them, a system adapter can be categorised as being used for managing a specific facet of the target system. Additionally different options are provided to control when metric extractors and policy evaluators are triggered:

scheduled at regular intervals;
triggered by the arrival of a specific event type (in GAMF's event sore);
triggered on an arbitrary schedule.

[overview] [features] [system architecture] [getting started] [examples] [downloads] [API]

Getting Started

Note

It is assumed here that you are using java 1.6 and eclipse.

Setting GAMF up

Create a Java project and import GAMF. This can be done either by adding the jar file or the gamf project (inc. nds) to your projects build path (see download section). Import the main GAMF interface

import gamf.framework.GenericAutonomicManagerFramework;
import gamf.interfaces.framework.IGAMF;

and create an instance of the gamf.

IGAMF gamf = new GenericAutonomicManagerFramework();

Specify a facet of the target system you'd like to manage in an autonomic manner. System adapters are associated with this facet at a later stage. Import the facet Interface.

import gamf.interfaces.framework.IManagedFacet;

Create the facet.

IManagedFacet managedFacet=gamf.registerManagedFacet("my facet");

Creating System-Adapters

Individual system adapters are associated with the tasks as described above (event generation, metric extraction, policy evaluation, and applying changes to the target system via effectors). To develop a system adapter you have to import the specific interface.

import gamf.interfaces.systemAdapter.*

and implement the envisioned functionality. Abstract system adapters which implement fundamental operations are provided in:

gamf.addons.apstractSystemAdapter;

By extending these fundamental system adapters you don't need to re-implement standard functionality. The example(s) provided in the download section use these abstract system adapters. Download the source to modify them or to use them as example. Any system adapter needs to be associated with a specific aspect when being registered with the gamf. In the case of an event generator, this can be achieved as outlined here:

// create your event generator
IEventGenerator myEventGenerator = new MyEventGenerator();
// register your event generator with the GAMF
gamf.add(myEventGenerator, managedFacet);

If the system adapter under consideration is a metric extractor or policy evaluator you can specify how it shall be triggered. For instance periodically, by specifying the interval between triggering operations.

IPolicyEvaluator myPolicyEvaluator = new MyPolicyEvaluator();
int evaluationInterval=1000;//in ms
gamf.add(myPolicyEvaluator, evaluationInterval, managedFacet);

For more options, please see the API or the provided example(s).

[overview] [features] [system architecture] [getting started] [examples] [downloads] [API]

Examples

Access to Source

A complete Java example of the following use case can be found in the [downloads] section of this webpage. When considering a use case in which an autonomic manager is added to a target system for which the source is available or if a system is built with an autonomic management form start, the GAMF can be used in the following way. A simplified use case is considered in which an application's sensor component is the target system. This component periodically gathers environmental monitoring data which is then processed. It is assumed that the data is gathered from remote sensor nodes which are also used by another application. A low interval may cause heavy usage of the sensor nodes and subsequent processing errors. Therefore it is required that the interval is increased if the error rate of increases and decreases with the rate of errors again as the amount of data gathered should be as large as possibly without jeopardising the application's correctness. An autonomic manager (based on the GAMF) is described here which adapts the data gathering interval following these requirements. As the GAMF is currently only available in Java, it is assumed that the target system is written in Java as well.

The autonomic manager consists of the GAMF and the following system adapters:

An event generator is added to the target system in order to report error-events (specified with an error-event-type) when carrying out a specific operation which relies on sensing data. An effector, is added to the target system in order to change the polling interval.

A metric evaluator is created to analyse the situation with respect to recently monitored errors. This is done by counting the number of error-event-type events reported since the last analysis (This are events stored in the GAMF's shared knowledge data base, with the corresponding event type and time-stamp.). A policy evaluator is created to determine a new polling interval if the error number is greater than a specific threshold. The policy evaluation is executed periodically and triggers the metric analysis.

Target System Without Access to Source

When considering a use case in which an autonomic manager is added to a target system for which the source is NOT available the GAMF can be used in the following way. Here the objective of the manager is to control the resource allocation of a specific web site autonomically in order to maintain free resources for other websites on the same host in the case that the website under consideration exhibits a high access rate.

The target system in this case is a web server, whose source code is not available. The web server's configuration files and the log files allow read and write access. GAMF runs in a separate address space but on the same physical machine as the web server. The website consists of an application which carries out resource consuming computations. If the number of accesses to the application per observation period exceeds a specific threshold, the configuration setting for the number of web server child processes is reduced in order to allow other services on the web server to use enough CPU.

A log file watcher which implements an event generator is developed. This log file watcher periodically searches for events in the web server's access log file which indicate that the website was accessed. The event generator sends the number of accesses as an event to the GAMF. An effector is implemented which changes the maximum number of child processes for the website under consideration in the web server configuration. After a successful change of the number of child processes, the effector restarts the web server so that the configuration change has an effect.

Customising Triggers

The internal GAMF building blocks which are used to initiate the execution of metric extractors or policy evaluators are referred to as triggers. Triggers for periodically triggering or for triggering at the arrival of a specific event are provided by the GAMF. If needed, triggers can be customised by the system adapter developer. In such cases the provided trigger-interface and system-adapter-interface need to be implemented. This can be useful if a triggering mechanism is required for handling complex scheduling, for instance, the evaluation of a policy every 100th time a specified event type is recorded; or to trigger an evaluation if, after a given time, no event of a given event type arrives.

Triggering By Combining System Adapters

If a policy evaluation is very expensive, with respect to compute resource usage, it can be configured that it is, for instance, only evaluated in specific conditions. Such conditions can be represented by specific metric values. This can be achieved without customising triggers by combining a metric extractor with an event generator. In such a case the metric extractor can generate an event when a metric value is above a certain threshold. A policy can be configured to be triggered at the arrival of a specific event type (generated by the metric).

[overview] [features] [system architecture] [getting started] [examples] [downloads] [API]

Downloads

Running the example

In the following the source code for the use-case discussed in "examples) Access to Source" is provided. The Java project "gamf examples" can be download and complied using either the gamf.jar file in its build-path or the Java projects gamf and nds as source code dependencies. To deploy the managed example system and to run DeployManagedSystem to instantiate the above described example sensing application inc. the manager in a simulation. Exceptions are thrown and written to stdout to indicate when a error is simulated. Additionally the rate with which the polling intervals are changed is printed, producing output like the following:

sensorComponent.MyTargetSystem::processData : simulating error
gamf.addons.apstractSystemAdapter.EventGenerator::publish : ERROR_EVENT published
java.lang.Exception: simulating error
	at sensorComponent.MyTargetSystem.processData(MyTargetSystem.java:115)
	at sensorComponent.MyTargetSystem.run(MyTargetSystem.java:80)
sensorComponent.MySensorComponentPolicyEvaluator::evaluatePolicy : chaning polling interval from:1000 to 1001
sensorComponent.MyTargetSystem::processData : simulating error
java.lang.Exception: simulating error
	at sensorComponent.MyTargetSystem.processData(MyTargetSystem.java:115)
	at sensorComponent.MyTargetSystem.run(MyTargetSystem.java:80)
gamf.addons.apstractSystemAdapter.EventGenerator::publish : ERROR_EVENT published
sensorComponent.MySensorComponentPolicyEvaluator::evaluatePolicy : chaning polling interval from:1001 to 1002
sensorComponent.MySensorComponentPolicyEvaluator::evaluatePolicy : chaning polling interval from:1002 to 1001
sensorComponent.MySensorComponentPolicyEvaluator::evaluatePolicy : chaning polling interval from:1001 to 1000
sensorComponent.MySensorComponentPolicyEvaluator::evaluatePolicy : chaning polling interval from:1000 to 999

Building the example

All source file archives and jars below were extracted from an eclipse workspace (this howto is written, based on the assumption you are using eclipse as well). The simplest way to run the example(s) is to download and unzip the example, create a new Java project with eclipse, choose "create project from existing source", choose the location of the unzipped archive file, and create the project. The imported project will assume that you have done the same procedure for the Java projects gamf and nds and will report a compile error until you haven't done that.

Alternatively, if you are not interested in the gamf and nds source code, you can use the provided gamf.jar file. Delete the dependencies in the gamf_example project proprieties (right click on the project name in eclipse), download the gamf.jar file and add it to the gamf_examples project's build path as external jar file.

Any of the above steps for compiling the example also applies if you plan to use the GAMF to build an autonomic manager for the system of your choice: Add either the gamf.jar file or the gamf and nds project to the build path of your autonomic manager and use it as illustrated in the examples.

GAMF was written using Java version 1.6. Above steps were tested in eclipse, version: 3.5.1.

Pages were last updated by Markus Tauber (markus [at] cs.st-andrews.ac.uk) in May 2010