The term autonomic computing applies to a system that can monitor itself and adjust to the changing demands put upon it by the business. There are four distinct characteristics of an autonomic computing system:
- Self-configuring
- Self-healing
- Self-optimizing
- Self-protecting
A comparison can be made between an autonomic computing system and the human body (see "Autonomic Manifesto" in Resources). The nervous system of the human body ensures that the right amount of light can pass through the eyes. At the same time, the body might sweat in order to keep cool. All of this happens effortlessly and without intervention from any outside sources.
An autonomic computing system should ultimately be able to run itself with minimal human intervention.
Where does the autonomic manager fit into the autonomic computing system?
One or more autonomic managers exists within every autonomic computing system. These managers continuously monitor the system and handle events that need action to be taken. Every manager has four distinct areas of functionality. First, it must monitor the environment using sensor operations and analyze what is found. The autonomic manager then plans and executes any specific actions needed. If, in the planning stage, no actions are needed, the autonomic manager returns to the monitoring state. Actions are taken through effector operations. Sensors look at the current state of the managed resources, and effectors have the ability to change the current state.
These functions, taken together, are defined as a control loop, with the following parts:
- Monitor
- Analyze
- Plan
- Execute
The four functions consume and generate knowledge. The knowledge base can be seeded with known information about the system, and can grow as the autonomic manager learns more about the characteristics of the managed resources. The knowledge is continuously shared among the four functions, leading to better-informed decisions being made by each of the functions. Figure 1 shows a common illustration of the control loop.
A managed resource touchpoint delivers the sensor and effector interfaces that the autonomic manager uses to interact with a managed resource.
Figure 1. The control loop in action
A basic autonomic manager scenario
The following section details a basic autonomic manager scenario that could be adapted into an autonomic computing system. The scenario assumes there is a control loop within a Web server system. The main goal of the scenario is to ensure that the CPU usage does not exceed 90%. If 90% is exceeded, the system needs to take action.
The monitor process is responsible for collecting and organizing data from the required sources. A large portion of the knowledge is monitored information. With the level of reporting and logging functions within software systems today, it is important to monitor data that is going to be of use to the control loop. If large amounts of log data, for example, are stored, performance might deteriorate because data is constantly being monitored when it has no relevance to the system.
The first step in the example is to monitor the CPU usage. This requires a reading, and if I were to do it in a UNIX environment I would run the "top" utility. An example output from "top" would look like:
Listing 1. Output from "top" utility
PID User PRI NICE SIZE RES STATE TIME WCPU CPU Command 57687 www 18 0 17428K 6048K lockf 2:48 0.00% 0.00% httpd |
An autonomic manager would query the system to see what the usage is, which would then deliver the data to an analyzer. The analyzer would read the data and determine if anything else needs to be done. As you can see from the above output you have little to do because the server is running normally.
The autonomic manager continues to run and monitor data. A change in the CPU usage triggers the analyzer to invoke the planning object to correct the problem.
Listing 2. CPU usage change
PID User PRI NICE SIZE RES STATE TIME WCPU CPU Command 57687 www 18 0 17428K 6048K lockf 2:48 0.00% 91.43% httpd |
Now, on to the plan and execute stages of the loop to see what would, theoretically, happen.
The control loop is policy based; if a certain condition is met then an action must be run. This is similar to the if/else statements found in high-level programming languages.
Because, in the previous example, the CPU usage has changed, there is now a need to plan and execute a response.
For this example, the planning stage of the autonomic manager must schedule an action to restart the server and see if that will correct the problem (there are other methods to correct this situation, but I will use this one for this example).
As I have already briefly mentioned, a large amount of the knowledge gained comes from the first step of the control loop -- monitoring. It is important to consider the type of data knowledge you need. It is very easy to log every transaction a Web server produces, but the processing time to extrapolate that data could be detrimental to the loop.
When putting together an autonomic computing system, you should plan out the knowledge that is to be logged, what persistence you are going to use, and any specific information you are looking for. In the basic example above, I could have stored the output data into a database with a time stamp. As well as finding out what the control loop is reporting, I could easily find trends in the data that might require the addition of more plan and execute effectors.
Not all knowledge needs, however, come from monitoring activity; it is completely acceptable for a team of experts to design a set of scenarios and add to the knowledge base of the system. It is also feasible to have a database of symptoms and corrective actions. For example, a quick lookup of a "database server is down" symptom can have "reboot the database server" as its corrective action.
Arthur Hays Sulzberger said, "A man's judgment cannot be better than the information on which he has based it." This also rings true for an autonomic computing system. In order for the system to make a decision on whether to execute an effector, the information has to be present and in good form.
Tools: Thermostat example from the Emerging Technologies ToolKit
One way of learning how a control loop works is to see one in action. This is a good way to see how all the pieces fit together within a working system. Using these examples enables you to implement your own event handlers in the future. One example is a thermostat program available in the Emerging Technologies Toolkit (see Resources).
Note: I advise you to read the documentation on installing the Emerging Technologies Toolkit; it is designed to work with IBM WebSphere® or Jakarta Tomcat (from the Apache Foundation).
Once you have installed the Toolkit, you can start the server:
Listing 3. Starting the server
C:\ettk\actk\bin>startserver.bat |
Next, you start the client, which shows the state of the thermostat. This is a small Java application that connects to the server.
Listing 4. Starting the client
C:\ettk\actk\services\grid\thermostat\client>runThermostat3.bat |
When the client runs you will see the temperature bar steadily increase until it reaches the desired temperature (set to 70° at startup).
As you can see in Figure 1. of the thermostat demo, the thermostat is fluctuating between 69° and 71° this is due to the control loop constantly monitoring the temperature. Listing 5 shows what is happening in a basic pseudo code.
Listing 5. Temperature monitoring
if temperature is less than the required temperature
then turn the heater on
if temperature is more than the required temperature
then turn the heater off
|
The console windows give a good indication of what is happening on the server side.
Listing 6. Server status
Get heater status = off Set heater status = on Get heater status = on Set heater status = off Get heater status = off Set heater status = on Get heater status = on Set heater status = off |
If the user changes the goal temperature with the slider bar, the control loop will continue as is until a policy trigger is reached (as in the pseudo code above). If I raise the bar to 100°, the client console responds to my request: Sending 100° to thermostat as new goal.
Because an effector will then set the heater to "on," the thermostat temperature will start to rise.
The thermostat example demonstrates how the control loop is utilized. The Emerging Technologies Toolkit also supplies the code for you to inspect so you can implement the control loop in your own applications.
Real life examples of autonomic managers
Currently, autonomic computing is still new and is constantly evolving. You will, however, find autonomic manager features currently available in some tools and products. For example, DB2® is available as a trial download so that you can start investigating the autonomic features right away.
- DB2 -- The relational database management system (RDBMS) uses autonomic computing for a number of features. The first is a health monitor to maintain optimum performance of the database system. If any performance issues are found, DB2 will report the findings and offer expert advice on how to correct the situation. A configuration adviser helps the novice user in configuring an expert system -- something that would have normally taken a long time to set up.
Future releases will concentrate on the self-healing and self-protecting segments of the autonomic computing system. - Tivoli® -- The Intelligent Management Software solution contains all four areas of the autonomic computing environment. Elements of the toolset can self-configure (Configuration Manager), self-optimize (Workload Scheduler), self-heal (Enterprise Console) and self-protect (Risk Manager).
- eServer -- The Enterprise Workload Manager (EWLM) component of the IBM Virtualization Engine provides hetergeneous workload management capabilities. EWLM enables you to automatically monitor and manage multi-tiered, distributed, heterogeneous or homogeneous workloads across an IT infrastructure to better achieve defined business goals for end-user services. These capabilities allow you to identify work requests based on service class definitions, track performance of those requests across server and subsystem boundaries, and manage the underlying physical and network resources to set specified performance goals for each service class.
With the nature of the article being an introduction and overview of the control loop, you are advised to view the documentation on DB2, Tivoli, and eServer from their respective Web sites.
As autonomic computing systems mature, so do their tools. The Emerging Technologies Toolkit offers tools and technologies to help you develop autonomic solutions for your applications. Within this toolkit are code samples, documentation, and many examples that you can run to help you set up an autonomic computing system.
This article described autonomic managers, and explained how they fit into the autonomic computing reference architecture. It gave an example of an autonomic manager, and provided an investigation into real world tools that currently use managed resources.
- The Autonomic Computing Manifesto makes comparisons between an autonomic computer system and the human body.
- See the Emerging Technologies Toolkit for examples of a control loop in action.
- DB2 is the database of choice for customers and partners developing and deploying critical solutions.
- The Tivoli Developer Domain is a great resource for showing how Tivoli fits into the autonomic computing architecture.
- Learn about the many autonomic capabilities of the IBM Virtualization Engine™ in this article, which describes how the autonomic features improve the availability of resources and the efficiency of systems and storage administrators.
- You can download Java 1.4.2 from the Sun Microsystems Web site.
- The Tomcat Servlet Container can be downloaded here.
- The Apache Web Server is an open source HTTP server that you can download from the Apache HTTP Server Project Web site.
- The Apache Web Services Project provides a download to AXIS.
- Check out more emerging tools on AlphaWorks.
Jason Bell, a Studio B author, is a technical architect and API documentation advocate who is based in England. He is the Core and Internals section editor of Java Developer's Journal and is also involved in a number of open source projects including RSSLibJ, a Java API for creating and reading rich site summary news feeds. He can be reached at: jaseb@jaseb.net.
