In 2001, IBM proposed a new vision of self managing computer systems inspired by the human autonomic nervous system [98]. This new area, termed autonomic computing, was proposed as a remedy to the increasing complexity and scale of software systems by having systems manage themselves [107]. When autonomic computing was first proposed, large scale systems necessitated large teams of administrators and engineers to ensure its continued correct operation and this largely remains the case today. In lieu of human staff, autonomic computing proposes that systems maintain and alter their themselves as appropriate, in a manner similar to biological systems, vastly reducing the manpower requirements. The goal of self management is comprise of four sub-goals:
2.6. AUTONOMIC COMPUTING 29
Self Configuration: Newly instantiated components are automatically configured and
the rest of the system adjusts appropriately.
Self Optimisation: Components will continuously seek opportunities to improve their
performance and reduce costs.
Self Healing: the system will detect, diagnose and recover from all failure modes.
Self Protection: the system proactively detect and mitigates attacks.
The most common autonomic architecture in literature is still that which was initially proposed by IBM in 2001. The architecture of autonomic systems, as proposed by IBM, is oriented aroundautonomic elements- individual, self managed system components which host related resources or services. An autonomic systems consists of a number of autonomic elements which communicate and cooperate to provide systemwide self management. Each autonomic elements contains anautonomic managerwhich manages the components within that element and communicates with the managers in other elements. Management within an autonomic component and between components is conducted according to a series of predefined goals provided by the developer. The
managed element is the conventional component within the autonomic element which the manager manages. The managed element can be anything ranging from physical systems such as workstations, printers or sensor nodes to abstract systems such as VMs, containers and applications. The sole prerequisite of the managed component is the need for interfaces to obtain monitoring state and to enact configuration change, something which the vast majority of modern systems provide. This scheme is depicted in figure 2.1.
At the core of the autonomic manager is a control loop. IBM has suggested a reference model for autonomic computing, often referred to as the MAPE-K (Monitor, Analyse, Plan, Execute, Knowledge) model [107] and depicted in figure 2.1. In this modelsensors
(also referred to as probes in literature) hook into the managed element and export monitoring data to the autonomic manager. This monitoring data is used to determine the need for and the nature of changes to the managed system which are enacted via effectors, a further hook into the managed element. The autonomic manager uses state obtained from sensors in order to plan and execute actions pursuant to a set of high level goals and desirable states defined by human administrators (and referred to in the model as knowledge). Goals are typically defined by the user using a domain specific language and expressed in the form of event-condition-action (ECA) rules [59]. This
M
A
P
E
K
Goals, Thresholds, Conditions etcAggregated
Monitoring
Data
Analysis
Results
Planned
Alteration
Managed System
Sensor
Effector
Obtain State
Enact Chages
2.6. AUTONOMIC COMPUTING 31 A Monitor Analyse Plan Execute Knowlege Managed Element Sensor Effector Autonomic Manager Autonomic Element
Figure 2.2: The structure of an autonomic element (containing the MAPE-K Autonomic Control Loop) orchestrated within an autonomic system
allows human administrators to define a set of goals and prioritise that goal and then have an autonomic system achieve those goals, without further human intervention. There are a number of implementations of the MAPE-K model. These include the IBM Autonomic Toolkit [101], ABLE [61] and Kinesthetics eXtreme [105].
While significant progress had been made within autonomic computing, the end goal of self management is far from idealised [79]. The intersection of cloud and autonomic computing has, to date, been somewhat ad hoc; cloud researchers have certainly made use of autonomic research but little autonomic research has been done in the cloud domain. As such there are many examples of autonomic properties being embodied throughout cloud computing, however within the cloud domain (as elsewhere) there is still the need for continuous human involvement. No cloud systems come at all close to embodying the ideal of human free, autonomic computing. Examples of common autonomic behaviour in cloud computing includes:
based on a number of factors. The canonical example of this is the instantiation of additional VMs to handle peaks in load, followed by the termination of those VMs when load recedes. Another common use cases include the automatic termination of VMs which exhibit poor performance, high CPU steal or other undesirable qualities in order to achieve an optimum price-performance ratio.
• Several tools including Puppet[39], Chef[8] and Salt[42] provide the means to automatically configure new VMs and Apache Zookeeper [3] and etcd [16] provide a programatic means to modify configuration.
• Most commercial cloud providers ofter a firewall with a programatic interface, enabling software agents to dynamically block malicious hosts and IP addresses and update ACLs as necessary .