Conocimiento sobre la evaluación

3.1

Autonomic Management

Autonomic Management has been a very active field of research in the past decade [20, 36, 17] and a variety of research challenges have been raised in this area [19]. It is used for service level guarantees [28], aggregated information monitoring [26, 25] and many other applications [27]. However, the main idea behind autonomic man- agement is to build systems that are self-configuring, self-healing, self-optimizing and self-protecting and it is inspired from the human body’s Autonomous Nervous System (ANS) [39].

The ANS gives our bodies the ability to adapt to dynamic changes in the environment around us automatically by sensing these changes, deciding what actions the body should take and enforcing those ac- tions. Similarly, an autonomic manager which is responsible for mon- itoring and management of one or more elements of a computing system (i.e. Managed Elements - MEs) should be able to sense the changes in those elements, decide what actions need to be taken and enforce those actions, to adapt the whole system automatically.

The general architecture of an autonomic manager looks like Fig- ure 3.1. In this architecture [33], the managed element provides some sensors and effectors/actuators to the manager. The auto- nomic manager can then monitor available metrics through these sensors and analyse the monitored information. It can then plan for a series of actions that needs to be executed, if any, and then execute those actions through the provided effectors. The manager will then keep monitoring those metrics to see the effects of its decisions in the previous management interval. This process is a feedback loop

24 _{Chapter 3. Scope and Challenges}

called Monitor-Analyze-Plan-Execute (MAPE) loop.

There are various ways a manager can choose the best actions, but we use policy-based management in this thesis. Policy-based man- agement assumes that the knowledge base in the autonomic man- ager includes defined policies and therefore it can look into those provided policies to pick the appropriate actions that need to be enforced. Policy-based management is explained in more detail in section 3.1.1. The autonomic manager combined with one or more managed elements is called Autonomic Element (AE). Therefore, in order to be able to manage an AE itself, the AE can provide sen- sors and effectors to the outside world. This will help forming multi layers of autonomic management in a system.

Figure 3.1: Autonomic Manager Architecture (from [33])

In this work, we use the same basic architecture for building au- tonomic managers and the MAPE loop can be configured to run on

3.1. Autonomic Management 25

different management intervals. That is, one manager can run its MAPE loop every 100 millisecond whereas another manager can run the loop every 10 minutes. This is useful for enforcing management at different levels of the hierarchy while trying to minimize over- head. At the lowest levels, monitoring is required more often as the changes are very dynamic and happen more frequently, while man- agers at higher levels need less frequent monitoring and therefore can in principle operate at higher management intervals. This will result in less traffic and processing overhead in the management system.

3.1.1 Policy-Based Management

Policy-based management is a well-known technique in the auto- nomic management area. An overview of policy-based management along with relevant standards and implementation techniques can be found in [3, 6]. Many languages have been developed to express policies however only some of them support Event-Condition-Action paradigm [16]. Ponder [11] is one of the most famous policy lan- guages that supports this paradigm.

An autonomic manager can have different types of policies which can be useful for certain purposes. For example, it might rely on configuration policies for self-configuration of managed elements, or might utilize expectation policies for optimization of the system or for ensuring that service level agreements (SLAs) are met. Elastic- ity policies [15] can also be used to automatically add or remove resources in a computing environment.

26 _{Chapter 3. Scope and Challenges}

In this work, we use policies expressed as event, condition, action (ECA) policies. In general, all of our policies are of the form:

OnEvent: E

if Set of Conditions then

Set of ordered actions

end if

Upon raising an event inside the autonomic manager, then any policy which matches the event will get evaluated. If the conditions in the policy are met, then the policy actions get triggered. We pro- vide examples of policies in the following sections.

At AM start-up there are configuration policies that set up the autonomic manager environment, identify the appropriate managed elements and configure them. It is however possible to automatically perform policy mapping [35] at start-up time and configure elements based on other types of policies. A sample configuration policy ex- plicitly defined in the policy set of an autonomic manager would look like:

OnEvent: VMConfigurationEvent

if true then

VirtualMachineMEI.setRefreshInterval(4000ms)

end if

This policy happens on AM start-up and configures the refresh interval for this AM. If we assume that this AM is responsible for