AUTONOMIA : An Autonomic Computing Environment

 

 

1.       Autonomic Component

Our approach to autonomize any software module or network resource is based on augmenting the resource with two entities [6]: Component Management Interface (CMI) and Component Runtime Manager (CRM), as shown in Figure 1. It extends traditional components (e.g., CORBA and Java beans) with provisions to support autonomic features (e.g., self-configuring, self-protecting, and self-healing) and thus behave autonomically. This architecture can either be used to implement autonomic components from scratch or add autonomizing provisions to existing software modules or resources.

Figure 1: Autonomizing a software system or hardware resource

 

CMI consists of three ports: Configuration Port, Control Port and Operation Port. It is a passive module that stores all control and management policies that govern the operation of a component that can be a hardware resource or a software module and its interaction with the environment. However, CRM represents the active module that aims at enforcing the policies specified in CMI at runtime. Consequently, CRM continuously monitors and analyzes the execution of its component and interrupts its operation once it detects that the execution environment of the current component cannot meet the desired operational and functional requirements. The planning module will determine the appropriate corrective actions that will be performed by the execution module.

 

1.1 Component Management Interface (CMI)      

       CMI provides three ports to specify the control and management requirements associated with each software component and/or network resource, as briefly described below:

·  Configuration Port: It defines the configuration attributes required to automate the deployment of the component/resource and how to setup its execution environment. A component configuration attributes include its name, resource requirement, configuration parameters, and dependency specifications.

·  Control port: It consists of two modules: sensor and action modules. The senor module defines all the measurement attributes that must be monitored at runtime, while the action module defines all the actions (e.g., stop, migrate, invoke) that can be performed on the component or resource in order to force the component/resource to behave autonomically.

·  Operation port: It defines policies for normal/acceptable component/resource operations. These policies are described using two types of rules: Behavior Rules and Interaction Rules. The behavior rules describe the rules that govern the normal operations as a stand-alone component (e.g., CPU utilization, memory usage, CPU-MEM interactions), while the interaction rules specifies the rules that describe how this component should interact with its environment when it is behaving normally (e.g., when a component is compromised and started attacking its environment, such behavior should be detected by the component interaction rules). Operation port rules can be expressed as

<IF Condition1 AND Condition2 AND … Conditionm, THEN Action1 AND Action2 … Actionn>.

Each rule is expressed with a conjunction of one or more conditions and actions. Condition is the logical combination of a component/resource state and/or measurement attributes or an external event triggered by other components or resources. Action can invoke the sensor/actuator functions specified in the control port or send out events to other components.

      

1.2 Component Runtime Manager (CRM)

CRM is the local control system associated with a component that continuously monitors the component operations, analyzes the current state, plans the appropriate corrective actions if needed, and executes these actions to bring the component back to acceptable normal state of operation. The CRM control and management algorithm is shown in Figure 2.

CRM keeps checking the CMI for any changes to the current management strategies (step 2). If changes are specified, CRM will then read and parse the CMI file (steps 2~4). CRM also monitors the state of the component using all the available component sensor functions that are specified in the CMI sensor module (step 5). The monitored information is then analyzed by the analysis module to determine if there are any severe deviations from the desired state (step 7). Furthermore, the CRM also monitors any events or messages that might have been sent to this component (step 6). If the analysis module determines that the component is violating its operational and functional requirements, the planning module is called to determine the appropriate actions (step 8) that will be performed by the execution module to bring the component to normal operations (step 9 and 10). If any event is received, then the appropriate actions for this event will also be performed by the execution module (steps 12~14).

 

Text Box: CRM Algorithm 1: While (true) 2: if (any changes in CMI management polcies) 3: read and udpate CMI polcies 4: end if 5: state CRM_monitoring 6: event other components 7: state_deviation = CRM_analysis(state, DESIRED_STATE) 8: if (state_deviation is ture) 9: actions = CRM_planning(state, event) 10: CRM_Execute (actions) 11: end if 12: if (event is true) 13: CRM_execute (event) 14: end if 15: end while

Figure 2: control and management algorithm of the CRM

 

The CRM algorithm manages in an integrated approach all the component requirements with respect to performance, fault, security and configuration. For example, if the component state deviation caused by malicious attacks, the planning module will determine the appropriate protective security actions to mitigate and prevent the current attacks. Similarly, when the component state deviates from normal behavior due to failures, the planning module will determine the appropriate actions to recover from the failures and continue normal operations. Consequently, CRM can handle in a holistic way all the desired component attributes rather than having each attribute handled by separate mechanisms.

 

 

 

2.      Autonomia Architecture

Autonomia [5, 6, 7, 8] provides users with all the tools required to specify the appropriate control and management schemes and the services to configure and deploy the required software and network resources and then manage their operations to meet the overall system requirements. The main Autonomia modules include System Management Editor, Autonomic Management Web Services, Component Runtime Manager (CRM) and Compound Component Runtime Manager (CCRM).

The System Management editor is used to specify the component management policies according to the specified CMI schema. The Autonomic Management Web Services such as fault tolerant service and performance service are provided and can be invoked by the Compound Component Runtime Manager (CCRM). CRM is a runtime manager that aims at monitoring the component behavior and controls its operation in order to maintain the desired component attributes and functionalities. Several autonomic components (e.g., autonomic servers, clusters, and software systems) can be controlled and managed by one autonomic system that we refer to as an Autonomic Compound Component (ACC) (see Figure 3), and the corresponding CRM refers to compound CRM (CCRM). In a similar way, larger autonomic systems can be built by composing several autonomic compound components.

 

 

Figure 3: Autonomia Architecture