Distributed Management

The distributed management scheme implemented in our prototype allows access to the cluster from any node within the system. Having no need for a centralised point of information enables the support for fault tolerant operation. This is achieved through the replication of the task information to every node on which the task executes. Here we can see a drawback of the taken approach. The total memory consumption in the cluster grows roughly with $O(N^2)$. For each task $O(N)$ resources are used, if started on $n$ nodes. Each node has to keep $O(N)$ entries for the tasks in the worst case: that is, if each task is started on each and every node. Thus the memory consumption exhibits $O(N \times N)$ behaviour. We argue however that this additional overhead does not affect the system performance. In the prototype we had to store about 30 Bytes of management information for each task clone. Suppose the task is started on 500 computers, rather than on each of the 500 nodes, we have to store $500 \times 30 \approx 15 KBytes$ of information. Estimating that about 50 tasks are under the control of the framework on each node the amount of management data grows to 750 KBytes. The image size of the execution environment on each of the nodes was about 5 MBytes. Logging data and information that is pending for output from the tasks will be orders of magnitude larger than the amount of information needed for management in a fully distributed control approach. Allowing access to the cluster services from any node raises another problem. That is synchronisation of operations. For addressing this issue we first have to ask ourselves when at all synchronisation problems can occur. The following cases have to be distinguished:

• Task creation When a task create command is sent from different originators, the task will be assigned a unique task capsule identifier on each starting place, thus resulting in two different application images running in the cluster. This does not pose a problem. For avoiding that multiple applications are started that do the same job, a list of running applications can be retrieved by the operators first.

• Task suspension and termination If two operators suspend the same task, but the operation has been issued from different places, no interference will occur. Eventually the application will be suspended on all nodes. The same is true for removing a running application from the cluster. A problem however exists if one operator decides to suspend a task whereas another chooses to terminate the same task. In this case, synchronisation has to take place.

• Task resume If a task shall be resumed no problem occurs when issuing the operation from different sources. A logical discrepancy exists, if one operator resumes a task from one place whereas another one wishes to remove it from the system. Synchronisation has to take place then.

• Information exchange Sending data to the tasks ( stuff) or retrieving information ( dump) does not pose a problem if no sequential order of the operations is required for all nodes. If it is required, synchronisation has to take place as well.

It is indeed necessary to provide a scheme for command synchronisation in the distributed system. One solution that we developed for the prototype of the task control system is presented in the following section.