June 2, GrenchMark : A Framework for Analyzing, Testing, and Comparing Grids CCGrid 2006 A. Iosup, D.H.J. Epema PDS Group, ST/EWI, TU Delft

June 2, Outline Introduction and Motivation The GrenchMark Framework Past and Current Experience with GrenchMark A GrenchMark Success Story Future Work Conclusions

June 2, The Generic Problem of Analyzing, Testing, and Comparing Grids Use cases for automatically analyzing, testing, and comparing Grids Comparisons for system design and procurement Functionality testing and system tuning Performance testing/analysis of grid applications … For grids, this problem is hard ! Testing in real environments is difficult Grids change rapidly Validity of tests …

June 2, A Generic Solution to Analyzing, Testing, and Comparing Grids “ Generate and run synthetic grid workloads, based on real and synthetic applications “ Current alternatives (not covering all problems) Benchmarking with real/synthetic applications (representative?) User-defined test management (statistically sound?) Advantages of using synthetic grid workloads Statistically sound composition of benchmarks Statistically sound test management Generic: cover the use cases’ broad spectrum (to be shown)

June 2, Outline Introduction and Motivation The GrenchMark Framework Past and Current Experience with GrenchMark A GrenchMark Success Story Future Work Conclusions

June 2, GrenchMark: a Framework for Analyzing, Testing, and Comparing grids What’s in a name? grid benchmark → working towards a generic tool for the whole community: help standardizing the testing procedures, but benchmarks are too early; we use synthetic grid workloads instead What’s it about? A systematic approach to analyzing, testing, and comparing grid settings, based on synthetic workloads A set of metrics for analyzing grid settings A set of representative grid applications Both real and synthetic Easy-to-use tools to create synthetic grid workloads Flexible, extensible framework

June 2, GrenchMark: Iterative Research Roadmap

June 2, GrenchMark: Iterative Research Roadmap Simple functional system A.Iosup, J.Maassen, R.V.van Nieuwpoort, D.H.J.Epema, Synthetic Grid Workloads with Ibis, KOALA, and GrenchMark, CoreGRID IW, Nov 2005.

June 2, GrenchMark: Iterative Research Roadmap Open- GrenchMark Community Effort Complex extensible system This work

June 2, GrenchMark Overview: Generate and Run Synthetic Workloads

June 2, GrenchMark Overview: Easy to Generate and Run Synthetic Workloads

June 2, … but More Complicated Than You Think Workload structure User-defined and statistical models Dynamic jobs arrival Burstiness and self-similarity Feedback, background load Machine usage assumptions Users, VOs Metrics A(W) Run/Wait/Resp. Time Efficiency, MakeSpan Failure rate [!] (Grid) notions Co-allocation, interactive jobs, malleable, moldable, … Measurement methods Long workloads Saturated / non-saturated system Start-up, production, and cool-down scenarios Scaling workload to system Applications Synthetic Real Workload definition language Base language layer Extended language layer Other Can use the same workload for both simulations and real environments

June 2, GrenchMark Overview: Unitary and Composite Applications Composite applications Bag of tasks Chain of jobs Direct Acyclic Graph-based (Standard Task Graph Archive) Unitary applications sequential, MPI, Java RMI, Ibis, …

June 2, GrenchMark Overview: Workload Description Files Format: Combining four workloads into one Number of jobs Composition and application types Co-allocation and number of components Inter-arrival and start time Language extensions

June 2, Using GrenchMark: Grid System Analysis Performance testing: test the performance of an application (for sequential, MPI, Ibis applications) Report runtimes, waiting times, grid middleware overhead Automatic results analysis What-if analysis: evaluate potential situations System change Grid inter-operability Special situations: spikes in demand

June 2, Using GrenchMark: Functionality Testing in Grid Environments System functionality testing: show the ability of the system to run various types of applications Report failure rates [ arguably, functionality in grids is even more important than performance !  10% job failure rate in a controlled system like the DAS ] Periodic system testing: evaluate the current state of the grid Replay workloads

June 2, Using GrenchMark: Comparing Grid Settings Single-site vs. co-allocated jobs: compare the success rate of single-site and co-allocated jobs, in a system without reservation capabilities Single-site jobs 20% better vs. small co-allocated jobs (<32 CPUs), 30% better vs. large co-allocated jobs [setting and workload-dependent !] Unitary vs. composite jobs: compare the success rate of unitary and composite jobs, with and without failure handling mechanisms Both 100% with simple retry mechanism [setting and workload-dependent !]

June 2, A GrenchMark Success Story: Releasing the Koala Grid Scheduler on the DAS Koala [ ] Grid Scheduler with co-allocation capabilities DAS: The Dutch Grid, ~200 researchers Initially Koala, a tested (!) scheduler, pre-release version Test specifics 3 different job submission modules Workloads with different jobs requirements, inter-arrival rates, co-allocated v. single site jobs… Evaluate: job success rate, Koala overhead and bottlenecks Results 5,000+ jobs successfully run (all workloads); functionality tests 2 major bugs first day, 10+ bugs overall (all fixed) KOALA is now officially released on the DAS (full credit to KOALA developers, 10x for testing with GrenchMark)

June 2, A.Iosup, D.H.J.Epema (TU Delft), C. Franke, A. Papaspyrou, L. Schley, B. Song, R. Yahyapour (U Dortmund), On modeling synthetic workloads for Grid performance evaluation, 12th Workshop on Job Scheduling Strategies for Parallel Processing (JSSPP), held in conjunction with SIGMETRICS 2006, Saint Malo, France, June 2006 (accepted). GrenchMark’s Current Status: pre-”Open-GrenchMark” Already done in Python [ Workload Generator Generic Workload Submitter (Koala, Globus GRAM, option to extend for JSDL, Condor, PBS, LSF, SGE, …) Applications Unitary, 3 types: sequential, MPI, Ibis (Java) +35 real and synthetic applications Composite applications: DAG-based Extending modeling capabilities

June 2, A. Iosup, C. Dumitrescu, D.H.J. Epema (TU Delft), H. Li, L. Wolters (U Leiden), How are Real Grids Used? The Analysis of Four Grid Traces and Its Implications, (submitted). Towards Open-GrenchMark: Grid traces, Simulators, Benchmarks Distributed testing Integrate with DiPerF (C. Dumitrescu, I. Raicu, M. Ripeanu) Grid traces analysis Automatic tools for grid traces analysis Use in conjunction with simulators Ability to generate workloads which can be used in simulated environments (e.g., GangSim, GridSim, …) Grid benchmarks Analyze the requirements for domain-specific grid benchmarks

June 2, Conclusion GrenchMark generates diverse grid workloads easy-to-use, flexible, portable, extensible, … Experience used GrenchMark to test KOALA’s functionality and performance. used GrenchMark to analyze, test, and compare grid settings. 15,000+ jobs generated and run … and counting. (more) advertisement Have specific grid setting you would like to test? Test with GrenchMark!

June 2, Thank you! Questions? Remarks? Observations? All welcome! GrenchMark [10x Paulo] Alexandru IOSUP TU Delft [google: “iosup”] Many thanks to Hashim Mohamed (Koala), Jason Maassen and Rob van Nieuwpoort (Ibis).

June 2,

June 2, Outline Introduction The GrenchMark framework Experience with GrenchMark Extending GrenchMark Conclusions [here]

June 2, Representative Grid applications (1/4) Unitary applications Just one scheduling unit (otherwise recursive definition) Examples: Sequential, MPI, Java RMI, Ibis, … Composite applications Composed of several unitary or composite applications Examples: Parameter sweeps, chains of tasks, DAGs, workflows, …

June 2, Representative Grid applications (2/4) Unitary: synthetic sequential [I] read I1 data elements from stdin [O] write O1 data elements to stdout for each N steps (i) # superstep [I] read I2 data elements from stdin for each M memory locations (j) # computation step [M] get item j of size S [P] compute C computation units per memory item (fmul), and store results into temp memory location [M] put values from temp to location j [O] write O2 data elements to stdout [O] write O3 data elements to stdout > System reqs Processor (float*N*S*C) Memory (float*(M+1)*S) N+1:I1,N*I2 stdin stdout N+2:O1,N*O2,O3 Also version with computation and I/O

June 2, Representative Grid applications (2/4) Unitary: synthetic parallel [I] read I1 data from in$ProcID [O] write O1 data to out$ProcID for each N steps (i) # superstep [B] synchronize with barrier [I] read I2 data from in$ProcID for each M memory locations (j) [M] get item j of size S [P] compute C fmul/mem [M] put values from temp to j [C] communicate to all other processes X values and receive X values from every other processor [O] write O2 data elements to out$ProcID [O] write O3 data elements to out$ProcID > Machine i Processor i k (float*N*S*C) Memory (float*N*2S) N+1: I1,N*I2 app-input.iapp-output.i N+2: O1,N*O2,O3 Process i

June 2, Representative Grid applications (3/4) Unitary: Ibis jobs No modeling, just real applications [ ] physical simulation parallel rendering computational mathematics state space search bioinformatics data compression grid methods optimization

June 2, Representative Grid applications (3/4) Composite: DAG-based DAG-based applications Real DAG Chain of tools Try to model real or predicted (use) cases Input Output User task Linker Identity (one task’s output = other’s input, unmodified) App1 > Linker1 > App2 > Final result > out_1-2.dat param1.in out_1-1.dat huge-data.out perf2.dat param2.insome-list.in > out2.res l1p.dat perf1.dat