SZTAKI Desktop Grid

1. SZTAKI Desktop Grid P. Kacsuk MTA SZTAKI www.lpds.sztaki.hu

2. Work package distribution Desktop Grid model Dynamic resource donation Company/univ. server Donor: Company/Univ.orprivatePC Application Internet/Intranet Donor: Company/univ.orprivatePC Donor: Company/univ. orprivatePC

3. Characteristics of the desktop Grid model • Anybody can donate resources • Heterogeneousresources, that dynamically join and leave • One or a small number of projectscan use theresources • Asymmetric relationship between donors and users: U << D • Advantage: • Donating a PC is extremely easy • Setting up and maintaining a DG server is much easier than installing the server sw of utility grids • Disadvantage: • Dynamic job submission is not supported • Supported application is static (typically very long running application)

4. Master/slaveparallelismand parameter studies DG Server Internet

5. Types of Desktop Grids • Global Desktop Grid • Aim is to collect resources world-wide for grand-challenge scientific problems • Examples: • SETI@home • SZTAKI Desktop Grid global version at: http://szdg.lpds.sztaki.hu/szdg/ • Local Desktop Grid • Aim is to enable the quick and easy creation of grid for any community (company, univ. city, etc.) to solve their own applications • Example: • SZTAKI Desktop Grid local version

6. Firewall Firewall Global Desktop Grids NAT NAT • clients join the server voluntarily • public resources and a public project • resources can be attached to more Desktop Grid projects • resources are mostly behind Firewalls or NAT • resources come and go, fluctuating performance

7. Firewall Local Desktop Grids Institute/ Dept. • private (dedicated) resources, private project(s) • more freedom for applications choice and administration • oriented for companies and institutes • more predictable performance

8. SZTAKI Desktop Grid: Global version • Main objective: • Demonstrate the usage of DG systems for any community • Supported application: searching 12-dimension binary number systems • Number of registered donors: >19000 • Number of registered PCs: > 35000 • How to register a PC? http://www.lpds.sztaki.hu/szdg/

9. SZTAKI Desktop Gridglobalversion

10. SZTAKI Desktop Gridperformance TOP 500 entry performance: 1645 GFlops

11. SZTAKI Desktop Griddonors (users)

14. SZTAKI Desktop Gridlocalversion • Main objective: • Enable the creation of a local DG for any community • Demonstrate how to create such a system • Building production service Grids requires huge effort and represents a privilege for those organizations where high Grid expertise is available • Using the local SZDG package • Any organization can build a local DG in a day with minimal effort and with minimal cost • The applications of the local community will be executed by the spare PC cycles of the local community • There is no limitation for the applied PCs, all the PCs of the organization can be exploited (heterogeneous Grid)

15. Usage of Sztaki Desktop Grid

16. The speedup DSP size Production SZDG Sequential 20 ~35min ~1h 44min ~3h 33min ~5h 4min ~41h 53min 22 ~7h 23min ~724h 24 ~141h ~46h 46min DSP application on a local SZDG in the Univ. of Westminster • Digital Signal Processing Appl.: Designing optimal periodic nonuniform sampling sequences • Currently more than 100 PCs connected from Westminster and planned to extend over 1000 PCs

17. Usage of local SZDG in industry • Comgenex Ltd. -> AMRI Hungary • Drug discovery application • Creating enterprise Grid for prediction of ADME/Tox parameters • Millions of molecules to test according to potential drug criteria • Hungarian Telecom • Creating enterprise Grid for supporting large data mining applications where single computer performance is not enough • OMSZ (Hungarian Meteorology Service) • Creating enterprise Grid for climate modeling

18. Components of SZDG • Normal Desktop Grid (the current SZDG, available as package) • Desktop Gridwith cluster extension (available as package) • Goal is to include clusters in an SZDG (EU CancerGrid Project) • Hierarchical Desktop Grid(available as prototype) • Goal is to build larger DGs from smaller ones in a hierarchical way • E.g. Enterprise DG can be built exploiting PCs of the dept. DGs • Expected release by October 2007 (Hungarian DG project)

19. LocalDEG LocalDEG Normal Desktop Grid • Each local DG runs the applications of the local community (univ. dept., faculty, enterprise, etc.) Enterprise DG University Dept. DG University Faculty DG LocalDEG

20. LocalDEG LocalDEG Mixed Desktop Grid Local DGs can be extended with local clusters Enterprise DG University Dept. DG University Faculty DG LocalDEG

21. LocalDEG LocalDEG LocalDEG LocalDEG Hierarchical Desktop Grid • Local DGs at the lower level of hierarchy can be used to solve the applications of the higher level DGs. • E.g. univ. dept. and faculty DGs contribute to the university level DG University DG Enterprise DG University Faculty DG University Dept. DG LocalDEG Enterprise Dept. DG

22. Hierarchy • DG projects need modifications only for app registration

23. Challenges • based on the prototype we implemented redundant workunits workunit deadlines trust application representation application registration

24. Redundant workunits • redundancy can be enabled only on the highest level • it is automatically disabled on every other level

25. Workunit deadlines • deadlines ensure that no workunit can be hijacked • deadline is set when downloaded • problem in hierarchy • workunits transferred to lower levels have the deadline “timer” ticking • workunit download management required

26. Trust • public/private keypair for code signing and workunit signing • that’s not enough for the hierarchy From where should I accept applications and work ? How can I trust the work provider ? Who/ what guarantees that the app does no harm ?

27. Trust • to solve the problem we introduce X.509 certificates • not just for code signing and wu signing, but also for distinguishing the Application Developer the Server the Project the Client

28. Application representation • the application has a name and a version • the Application Developer signs the application • the application is identified by the name, version, signature

29. Application registration

30. Application registration • If we trust the Application Developer, we also trust the application signed by her • the project has a CA List with the list of trusted Application Developers and Projects • if the Application Developer istrusted, the application is deployed • The Project may sign the application

31. deploy The application registration process sign wu query install wu query get app download cert, CA list contact attach

32. Conclusions of hierarchical SZDG • Hierarchy is possible with minimal modification of existing projects • For increased security or industrial usage certificates provide a good solution • By introducing certificates most of the limitations can be solved • The hierarchical version of SZDG works at prototype level and will be released during this year

33. Application development support in SZDG • DC API: available in the current SZDGas package (Hungarian DG project) • Goal is to provide an easy-to-use library for generating Master/worker type Grid applications both for DG and SG systems • See the next lecture by Gabor Gombas • Portal access to SZDG:(in planning phase within the EU CancerGrid project) • Goal is to provide a high-level, graphical workflow level portal to generate and run SZDG applications

34. Portal support for SZDG • Disadvantage of BOINC: • Creation BOINC applications is a difficult task • A BOINC application is static, not submittable • Our goal: • Enable the dynamic submission of workflow and parameter sweep applications into the SZDG system • Make it easy to create and submit workflow and parameter sweep applications for SZDG

35. Generator job Generator job An example CancerGrid workflow N = 20e-30e, M = 100 => very large number of executions and files x1 NxM x1 xN xN xN NxM x1 xN xN xN NxM NxM

36. P-GRADE Portal Submitter Service • A web service component of the portal • Receives job submission requests from the portal workflow manager • Must be prepared to do the following tasks: • Submit the job • Check the submitted job’s status • Get the job’s output • Abort the job

37. Submitter - Overview GRID P-GRADE Portal WF Manager Report status change Submitter Service B Submit, Check stat, Abort, Get output A Submit B B C D

38. Portal – SZDG integration tasks • Create a special submitter for BOINC • Manipulate BOINC database: workunit creation, result status query, … • Glue together short-running algorithm instances • Consider job and job owner priorities if needed • Goal: minimize overhead of BOINC, minimize network traffic, but do not increment response time to users

39. Portal + SZDG (BOINC) CancerGrid DB MS SQL Donor BOINC Szerver Portal BOINC DB - MySQL Portal Storage Donor WU WU WU Submitter Queue Manager + Scheduler Q1 2D3D Q2 Mopac Donor Qn • The submitter stores the jobs sent by the portal in algorithm queues • Once a queue contains „enough” jobs, a BOINC workunit is created

40. Solution – Short-running jobs • Instances of algorithms running for a short time should be glued together in order to • increase computation time • and minimize BOINC overhead • Sheduling questions: • How many jobs are „enough”? • How long should we wait for new jobs? • What about algorithm/user priorities? • Detect „bad” donors? • A Queue Manager takes care of algorithm queues

41. Enabling Desktop Grids for e-Science(EDGeS) • New FP7 project to be started on the 01/01/2008 • Goals of the project: To integrate Service Grids (SG) and Desktop Grids (DG) to attract new scientific communities that needs very large number of computing resources To involve new type of user and resource provider communities beyond the scientific communities (school students, citizens of cities, companies) To provide APIs and Grid application development tools for the new scientific user communities in order to adapt their applications for the integrated SG-DG e-infrastructure To adapt the identified applications for the integrated SG-DG e-infrastructure To provide new trust mechanisms for the integrated SG-DG e-infrastructure To establish international collaborations, procedures and standards To contribute to the establishment of a sustainable Grid infrastructure in Europe • The infrastructure to be established: • Integrated Service Grid – Desktop Grid system

42. Sevice Grid (EGEE) The EDGeS infrastructure BOINC based DGs XtremWeb based DGs Public DG EGEE-BOINC Planned 10.000 PCs Local DG UoW Grid 1.500 PCs Public DG EGEE-XtremWeb 1.000 PCs Public DG IN2P3 Grid 300 PCs Public DG SZDG 30.000 PCs Public DG Extremadura Grid 70.000 PCs Local DG IN2P3 Grid 200 PCs Public DG AlemereGrid 3.000 PCs

43. Public DG LocalDEG LocalDEG LocalDEG LocalDEG Variety of DG systems within EDGeS Production Grid EGEE University DG Enterprise DG LocalDEG

44. Public DG Public DG Public DG Public DG SG (EGEE) Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Interoperability of EGEE with DG systems

45. Public DG Public DG Public DG Public DG SG (EGEE) SG (SEE-Grid) SG (EELA) Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Local DG Towards unlimited Grid resources

46. Assessment of SZDG • Advantages • Easy to create and maintain • Any organization can quickly and cheaply install it • Easy to program and hence no steep learning curve • Robust technology • Industry can use it as enterprise Grid • It extends BOINC with: • Clusters as donated client systems • Hierarchy of DG systems • DC-API and portal access for easy generation of DG applications

47. Conclusions • Desktop Grids are here for any community (universities, companies , etc.). They can • access and/or • build Grid systems • SZTAKI Desktop Grid technology enables • easy creation and programming of global and local desktop Grids • SZTAKI is ready to help any organization • to set up its local DG(s) • to port applications on local DGs • to train people how to build and use local DGs • More information on: http://www.desktopgrid.hu/ http://www.lpds.sztaki.hu/szdg/