Walter Binder Giovanna Di Marzo Serugendo Jarle Hulaas Towards a Secure and Efficient model for Grid Computing using Mobile Code Walter Binder Giovanna Di Marzo Serugendo Jarle Hulaas This presentation is about Grid computing and I will discuss a mobile agent-based model that addresses the issues of : - application distribution - security - billing and accounting of computations MOS’02 / June 2002 Giovanna Di Marzo Serugendo

Introduction Grid Computing Resources Grid Projects “Controlled and coordinated resource sharing and problem solving in virtual organisations” -- The Globus Project Resources Computational, Storage, Network Tools, Software, Data, CPU, Disk Storage Grid Projects DataGrid: CERN High-Energy Physics, Biology, Earth Observation Globus Toolkit What is Grid computing? Grid Computing is concerned with the distributed computations realised on world scale. Several organisations, wishing to collaborate, decide to share their resources. Resources are of different nature: related to computation, storage or network. For instance, there is a sharing of tools, software, data, cpu, or disks. Among Grid projects, I can mention the DataGrid project from the CERN in Geneva, which is concerned with three kinds of applications: hep, biology, and earth observation The Globus project aims at providing a complete toolkit which takes which encompasses: localisation and reservation of resources, sequence of calculus, handling of code, fault-tolerance, security, and access control customizable on each site.

Grid Data1 R Data2 Code Code(Data1,Data2) Here is a small example of a possible Grid computation. We can see the different actors of the computation: - Client wishing to perform some computation - Donators that provide some resource: here we have one donator which holds the computing power (CPU), several other donators storing the input data, and the code which has to be executed - We can notice that: data, code, and computation are located at 3 different sites. During the computation: Input Data and Code are sent to the cpu donator. The computation takes place there, and the result is then sent to the client.

Agent-Based Model Single Operator Mobile Agent Business Model Downloading of the application security and accounting preparation Distribution scheme of application Mobile Agent Distribution of application and input data Monitoring of computation (resource report) Integration of computed results Business Model Micro-payments The Agent-based model that we propose involves several parties: - Client and Donators (as we have seen in the previous example), and also ... - A single operator which is responsible for first downloading the application and preparing it for security and accounting operations, and second for choosing a distribution scheme for the application (choice of the donators) - A mobile agent (one per application), which is responsible for actually realising the distribution by dispatching the input data and the different parts of the code to the donators. He must also monitor the execution of the computation, look at resource consumption, inform the operator if resources become scarce. Finally, at the end of the computation, the agent collects and integrates the results. - The model encompasses a business model, where clients pay the operator for the resources they consume, and donators are paid by the operator for the resources they provide. The business model consists in micro-payments for CPU, memory usage, and data transfer over the network.

Addressed Issues Distribution of Computation Security Deployment descriptor code, data, result location / composition of computation Mobile Agent agent platform at client and donators sites Security Operator downloads and signs the code (filter) Secure Java environment for computations Billing and Accounting Operator reifies (rewrites) the code Execution tickets The issues addressed by the model are the following: - First, the distribution the computation, second the security aspect, and finally billing and accounting of resources consumption. Regarding the distribution of the computation: the client sends to the operator a deployment descriptor which explains where to find the code, the input data, and where to store the final results. It describes also how to perform the combination of computations (a sequence of operations, several computations on diverse data input, etc) The second aspect, the security is ensured first by the operator which operates as a kind of filter: it downloads the code, and prepares it for security. Second, the donators run a secure Java environment where the computations take place. Finally, regarding the billing and accounting issue, the operator after downloading the code, rewrites it for resource accounting. It prepares the bytecode, in order to enable run-time accounting of CPU and memory consumption. The business model completes this scheme, by employing execution tickets that clients have to buy to the operator.

Deployment 1 5 3 2 7 4 6 9 8 Mobile Agent I will now sketch the distribution of an application, its execution, and the collection of the results in this model. In this example client, donators, input data, and results are all located at different sites. First, the distribution of the application: 1. Donators and clients register to the operator. Donators inform the operator about the available resources 2. The client sends the deployment descriptor 3. On the basis of the deployment descriptor and the availability of the donators the operator chooses a distribution scheme. It creates also a mobile agent dedicated to the coordination of the application execution. 4. The operator downloads the code from its location 5. It reifies it for resource accounting 6. It deploys the different parts of the application to the donators 7. It dispatches the agent to some location, where it can monitor the execution 8+9. The agent starts the computation by informing the donators where they can find their respective input data Finally, the different parts of the computation start. 8

Monitoring 12 13 14 11 This was the preparation of the computation distribution, and the start of the computations. During the execution, the agent performs several monitoring tasks: 10. It receives regular starus report from the donators. It looks at the progress of computations, and may detect problems. 11. Status reports are forwarded to the operator 12. On the basis of the status report, the operator may decide to ask the client for more credit 13. The client buys some more execution tickets 14. The operator passes the tickets to the agents 15. Which forwards them to the donators. 15 10

Results 17 Mobile Agent 16 Once the different computation parts are finished: 16. the agent may move to the destination place, where results will be stored. 17. It will then receive, and assemble the different flows of data.

Platform Platform Requirements J-Seal2 Extensions Portability, performance, security J-Seal2 Java-based, Seal computations Extended bytecote verification Secure environment for Grid computing Resource control Extensions Control execution of applications: installation, access to resources Monitoring: overloading detection The platform where the computations occur (applications and mobile agents) must satisfy the requirements of : - portability: code to execute may be executed to any donator; - performance: clients do not want to pay to much; and - security: both clients and donators must receive security assurances: integrity of computations, results, confidentiality The chosen platform, is the J-Seal2 platform which is a micro-kernel implemented in Java, supporting the Seal calculus model. J-Seal2 manages a tree hierarchy of nested but separated tasks. Each task is subject to verification by its supervisor task. Extended bytecode verification is performed before a class is loaded, thus preventing untrusted code to access certain system services. J-Seal2 supports resource control for physical and logical resources. It relies on bytecode rewriting. It reifies memory and cpu consumption. However, J-Seal2 is not ready for Grid computing. It needs some extensions, in order to allow full implementation of the model. A component responsible for installing terminating untrusted applications, and for the access to resources. A monitoring system detecting if a machine is busy or idle

Conclusion Open Questions Future Work Efficiency of model Precise description of the business model Donators discovery: Jini-style ? Integration into a complete Grid solution (Globus-like) Future Work JSeal2 extension Mobile Agent implementation There are several open issues, and open questions: - the actual efficiency of the whole model, that cannot be determined before complete implementation of all control mechanisms - we need also to precise the business model, how to avoid faking of execution tickets? - regarding the discovery of idle donators should we follow a Jini-style of discovery? - finally, how this technique could be integrated into a whole toolkit such as the Globus toolkit? Future work: naturally are related to the implementation of the JSeal2 extensions discussed before, and to the implementation of the mobile agent responsible for application distribution and execution.