An organic computer is defined to be a self organizing system that adapts ... Self healing in the context of cluster computers can be understood in the sense of fault tolerance. In case that a physical communication link fails, then the whole system should ..... http://www.ti.informatik.uni-frankfurt.de/Papers/Adarc/mantova.pdf. 9.
Cluster Computing with organic behavior Bernd Klauer, Klaus Waldschmidt, Jan Haase, and Frank Eschmann J.W.Goethe-University, Technical Computer Sc. Dep., Box 11 19 32, D-60054 Frankfurt, Germany? {klauer|waldsch|haase|eschmann}@ti.informatik.uni-frankfurt.de
Abstract. Future Computing systems will mainly be characterized by the so-called self-X features, where X represents items like organization, configuration, parallelization, protection, healing, etc. The first part of the paper briefly discusses the self-X features with respect to cluster computing. The second part of the paper is dedicated to the Self Distributing Virtual Machine (SDVM). The SDVM is a parallel virtual machine implemented as a UNIX daemon. It provides programmers with a convenient infrastructure to design concurrent applications with organic behavior on cluster computers. The structure of the SDVM, her functions and some first performance results are presented.
1
Introduction An organic computer is defined to be a self organizing system that adapts dynamically to its environmental requirements. Organic computers are self configuring, self optimizing, self healing and self protective. Translated from [1] [in German]
The complexity of computers and and systems is expected to follow Moore’s prediction [2] in the next five to ten years. It will on one hand be important for the convenience of users and administrators to have systems with the so called self-X features as explained above. On the other hand it is the increasing chip space itself, that provides the computing power to implement such features. The following subsections will briefly discuss the four basic self-X features in the context of cluster computing. 1.1
Self protection
Two major cases of self protection can be distinguished in the area of cluster computing: – Computing clusters need to be protected from intrusion and attacks especially if they can be publically accessed. – User programs and data must be protected against manipulation or unauthorized reading. ? Parts of this work have been supported by the Deutsche Forschungsgemeinschaft (DFG).
1.2
Self healing
Self healing in the context of cluster computers can be understood in the sense of fault tolerance. In case that a physical communication link fails, then the whole system should try to replace the link be rerouting the logical connections. In case that a node fails, then all the computations that it had been responsible for should be carried out on a backup node. All meta information on the cluster that had been stored on the node should be available redundantly. Logical repairing procedures like rebooting or restarting the node should be started. A self healing process in the sense of repairing physically hardware components seems to be unrealistic in cluster computing environments. 1.3
Self configuration and self optimization
Both issues are tightly related. Optimization is usually the target of configuration. Modern computer clusters contain a variety of features to be configured. Therefore we should distinguish two types of computer clusters: 1. Fixed Architecture/Fixed Problem: Computer clusters purchased to solve one problem for their lifetime. 2. Dynamic Architecture/Multiple Problems: Dynamic clusters of logically coupled computers with appearing and vanishing resources used to solve a variety of problems with the following intention: – The efficiency of the computers that participate in the cluster can be increased by filling their idle times. – The Safety of critical applications can be increased as they migrate from one resource to another in case of failures. – Applications can be accelerated by parallelism.r In the following sections we will put our focus on the second class of clusters as they offer a great potential of configurability.
2
(Re)Configuring Cluster Computers
The subjects of configuration in cluster computers are the nodes, the communication links and the applications. A suitable configuration of a cluster depends strongly on the available resources (nodes and links) and on the application to be run on the cluster. The application itself is also subject to configuration as it has to be partitioned before it can be parallelized. A partitioning pattern with data dependencies between the fragments is a configuration of the application. Configuring the application also means to solve the binding and scheduling problem for the fragments. After solving the partitioning problem we have fragments of the application. These fragments are pieces of code and the information of the data dependencies. Now if we assume each node in the cluster can be configurable on the small grain level (e.g. by FPGAs) then we can decide if we want to run our piece of code as Software on a von Neumann type computer or as configware on the FPGA. The FPGA must therefore be configured to compute the problem of our code fragment.
3
A Self Configuring Virtual Machine
Computer clusters as described above are physically more or less stable. They are usually not (re)configured day by day by their admins. But their providers may decide from time to time if one of their machine participates in a virtual cluster or not. This is e.g. the case in the Seti@home project [3] where each computer in the internet may join or leave the Seti assembly. One solution to provide such a machine with the above mentioned self-X features is a virtual machine. Generally virtual machines are implemented as a software layer, which emulates the functionality of a certain machine or processor on a perhaps different machine. As computer clusters can be polymorph it would be nice to have a virtual machine (VM) that emulates a stable environment. A VM can release programmers from the task of writing code that decides what to do in case that the cluster changes. It can can release users from interactions in case of a changing computing environment. A virtual machine can hide the physical and logical structure from applications and provides programmers (and users) with the convenience of the self-X features.
4
The SDVM
The SDVM is (like the well known PVM [4]) a daemon that provides a convenient transparent platform for programmers and users to program and run their programms on computer clusters. Additional to the communication and control mechanisms of the PVM the SDVM provides threads to be programmed by the programmer which are automatically bound to and automatically scheduled for a suitable resource. Suitability means in this case suitable by special features of the resource or suitable by load balancing criteria. As self configuration in virtual machines is mainly driven by these automatic distribution mechanisms we called it: Self Distributing Virtual Machine (SDVM). It was our target with the development of the SDVM to provide the following features for computer clusters: – self scaling: The system should adapt itself to different environments. Signing in and signing off at runtime should be available for all machines in the cluster. – adaptivity: The cluster should cope with heterogeneous computer systems, so computers with different speeds and even different operating systems can participate in an SDVM controlled cluster. – self distribution: Intelligent distributed scheduling and migration schemata should provide that data and instruction code is distributed among the cluster engines automatically at a minimum cost of machine time. – self healing: Crashes should be detected, handled and corrected by the SDVM automatically without terminating running applications. – automatic parallelization: Hidden parallelism in programs should be detected and exploited.
– self protection and protection of others: For a cluster working within an open network it is important to consider safety aspects. The authenticity of users and data has to be ensured, and sabotage, spying and corruption has to be prevented. – accounting: Mechanisms and cost functions for measuring and accounting of provided and consumed computing time of providers and clients will be provided. Corresponding to the state of the implementation of the SDVM prototype we will focus on the first three of the above mentioned goals. 4.1
The granularity of the fragments
As mentioned above the SDVM to be described in the next sections needs fragmented applications. Fragmentation is necessary to allow code to be distributed among resources with the target of parallelization or safety or configurability reasons. The granularity of the fragments used in the SDVM are Microthreads following Nikhils [5] definition of microthreads with some minor changes. In simple words: A Microthread is a piece of code that terminates its calculations in a predictable time. The partitioning itself is not performed by the SDVM. Partitioning remains in the responsibility of the programmer - or a compiler [6]. 4.2
The architectural concept of the SDVM
The SDVM is based on the concept of the Cache Only Memory Architectures (COMAs) [7]. COMA architectures consist of a processor and a so called attraction memory. An attraction memory can be seen as a large cache — or a main memory together with a cache controller. The cache controller checks its local memory for the data that is needed by the processor. If it is available it performs like a standard cache. In case of a cache-miss the requested address is sent to the other caches in the assembly to be resolved. From the fact that there is no memory hierarchy beyond the attraction memory the architecture got her name. As result the COMA mechanisms provide a physically distributed logically shared memory where the data migrates to the site where it is needed. The SDVM extends this concept by introducing a code migration mechanism. The principles of the combined data/code migration have been published under the acronym SDAARC (Self Distributing Associative Architecture) [8–10]. The SDVM can be seen as one possible implementation of the SDAARC architecture as basic concept. 4.3
Microthreads and Microframes and the dataflow principle
As we already learned: A microthread is a piece of code performing a specific task. A microframe is a container holding the data that a microthread needs to do its job. Additionally each microframe has a pointer pointing to the specific
input parameters ...
ID
ID target addresses ...
MicroFrame
[...] double romberg(double a, double b, int N){ double sum; int i, j; double res; double T[25][25]; if (N>25)return 0; T[0][0] = (b-a) * (f1(a) + f1(b)) /2; if (N > 25)return 0; for(i=1;i
