Scheduling Parameter Sweep Workflow in the Grid

1. Faculty of Information TechnologyMonash UniversitySuchaSmanchatSupervisors: Dr Maria Indrawan and Dr Chris (Sea) Ling Scheduling Parameter Sweep Workflow in the Grid

2. Content • Background & Motivation • Grid Workflow Scheduling • Objective & Definitions • The Proposed Algorithm • Scheduler Implementation • Simulation Results • Conclusion & Future Work

3. Background • The Grid has become an important infrastructure to support e-Science due to its ability to provide a high-performance computing environment. • Workflow technology is used to automate scientific processes which are then executed by scientific workflow management systems e.g. Kepler [1]. • Scientific workflows used in e-Science usually require high computation power which the Grid infrastructure can provide.

4. Background • To execute a Grid workflow, tasks need to be scheduled onto Grid resources. • Scheduling workflow tasks in the Grid is necessary to improve performance. • Makespan (overall execution time) • Cost • Resource Utilisation • Reliability • Security

5. Motivation • Parameter Sweep Workflows • Workflows for parametric studies • Are repeatedly executed numerous times varying input parameters to study or optimise such parameters • Execution • One by one / Loop • Parallel using Nimrod/K [3] • E.g. Quantum Chemical Calculations experiment [2]

6. Motivation • Executing multiple parameter sweep workflow instances in parallel raises new scheduling challenges. • Every instance is derived from the same workflow definition • Hence, causing resource competition among concurrent task instances of the same definition • Scheduling algorithm needs to manage multiple workflow instances

7. Nimrod/K • A tool for parametric study being developed by MeSsAGE Lab, Monash University [3] • Built on top of Kepler [1] • Allow workflows in Kepler to execute in the Grid/Cloud via Nimrod toolset. • Feature the ability to clone a workflow into multiple copies (instances) and execute them in parallel. • Also provides many different parameter tools for various e-Research experiments • sweeping, optimising and experimental design techniques http://www.messagelab.monash.edu.au/Nimrod

8. Existing Grid Workflow Scheduling Algorithms • Batch Mode • Dependency Mode • Meta-heuristics based scheduling • Most algorithms are divided into two phases • Task Prioritising Phase • Resource Selection Phase Classification based on Yu et al. [4]

9. Examples of Batch Mode Algorithms • Min-Min, Max-Min, Sufferage [5] • XSufferage [6] • QoS-guided Min-Min [7] • Selective Min-Min Max-Min [8] • Min-Min Average [9] • Support multiple instances but does not consider resource competition.

10. Examples of Dependency Mode Algorithms • HEFT [10] • Hybrid HEFT [11] • SDC [12] • Tasks with “scarce capable resources” - the tasks that fewer resources are able to execute - are given higher priority (rank)

11. What is missing? • Most existing Grid workflow scheduling algorithms do not consider the dependencies of the tasks on resources, leading to resource competition problem • They are designed mainly for Directed Acyclic Graph (DAG) and rely on loop unrolling to handle loop structure. • Need to know (or predict) the number of loop iteration

12. Scheduling Objective • Given a Grid workflow, our objective is to schedule tasks across multiple instances of the Grid workflow to Grid resources based on resource scarcity and resource competition to minimises the makespan of the entire execution.

13. Parameter Sweep Workflow Model • PS = (V,E,R,P) where • V is a set of nodes representing tasks in the workflow; • E is a set of edges representing the precedence dependencies between tasks or nodes in the workflow; • R is a set of resources for executing tasks in the workflow; • P is a set of parameter combinations which is used to determine the total number of workflow instances

14. Grid Resource • We assume that each task can only be executed by certain resources as in [12] and each node can only execute one task at a time • A set of Capable Resources that can execute task tiis denoted as CR(ti). • E.g. CR(t2) = {r2,r3}

15. Resource Nodes • In the Grid, a resource may refer to a cluster which governs multiple compute nodes. • We define a function to retrieve the number of available nodes in a resource r as • We denote the total number of nodes in all capable resource CR(ti) as CRN(ti) (2) nodes(r) = number of available nodes in r (1)

16. Resource Scarcity • Directly adopted from [12] • The resource scarcity (RS) a task t is defined as (3) • Resource scarcity is the ratio between the number of capable resource nodes for t and the number of all resource nodes.

17. Resource Competition • Resource competition is calculated from the proportion of unscheduled task instances in the workflow instance that requires each Grid resource to execute. • We define a function to count the number of unscheduled instances of a task that have been instantiated as unschdInst(t) = number of unscheduled instances of t (4)

18. Resource Competition • The resource competition (RC) of a Grid resource r is defined as (5) • where ti is a member of RT(r) and tj is a member of V • RT(r) is the set of tasks that can be executed by r

19. Resource Competition • The numerator represents the contention over the Grid resource • The denominator represents the total number of unscheduled task instances across all workflow instances that have been instantiated • Resource competition is used in order to reserve resources in high demand for the tasks that are dependent on such resources to avoid bottleneck

20. Resource Metrics: EET • EET (Estimated Execution Time) The time taken for a resource to execute a task • Most important to scheduling algorithms • Use history • Assume to be zero if no previous history recorded to populate the history

21. Resource Metrics: EWT • EWT (Estimated Wait Time) The time until a resource can start executing a task • Calculated from the task instances waiting in the queue of the resource

22. Resource Metrics: ETT • ETT (Estimated Transfer Time) The time taken to transfer the required files to the allocated resource. • Use history • Multiple file servers • Select the server with minimum transfer time • Multiple files - how to determine ETT? • Sum all ETTs (worst case, sequential transfers) • Maximum of all ETTs (best case, all parallel transfers) • Max of Sums of ETTs originating from each file source

23. Resource Metric: ECT • Estimated Completion Time (ECT) used in Ranking Function. • The ECT of a task t when executed by a resource r is calculated using the following equation [2] ECT(r, t) = EET(r, t) + maximum( EWT(r), ETT(r) )(6)

24. Ranking Function • The rank of each resource rj executing a task ti is calculated by (7) • K constant is used to control the effect of RC on the rank value [14] • A lower rank is better since it means the resource has lower competition and can also execute the task faster.

25. The Besom Algorithm • Designed as a batch mode scheduling so the scheduler can gather and schedule ready tasks from multiple workflow instances. • Separated into three phases in order to support multiple instances • Instance Generation Phase • Task Prioritising Phase • Resource Selection Phase Image from http://www.hecatescauldron.org/Besom%20Chants.htm

26. Besom Algorithm Overview Instance Generation Iteration Control Task Prioritising Resource Selection

27. Instance Generation Phase • Threshold is used to limit the number of task instances in each scheduling round • More task instances in the scheduling pool leads to better load balancing. • Too many task instances may lead to a useless schedule

28. Task Prioritising Phase • Find ready task instances and use Resource Scarcity to prioritise them

29. Resource Selection Phase

30. Iteration Control • After the three phases, the scheduler waits for the next scheduling round which is triggered by • a certain period of time elapses • a new resource joins the grid • a task instance finishes execution • Repeat the three phases in each scheduling round while • there are more workflow instances to schedule OR • set of unscheduled tasks T is not empty

31. Scheduling Loop • To handle single-level feedback loop structure • Utilise the mechanism from scientific workflow management systems of scheduling tasks during run-time • Invoke scheduling algorithm as a task instance becomes ready for execution • Avoid loop unrolling

32. An Approach to Loop Scheduling • t2 of the second iteration cannot start until t4 of the first iteration finishes • Only need to consider the task instances in the next loop iteration • Resource Competition need to be modified

33. Resource Competition (Revised) • We define U to be the set of task instances across all instantiated workflow instances. • To represent task instances in the next iteration, members of the set U are • the unscheduled task instances outside loop structure • all task instances inside the loop structure when the execution have not exited the loop. • We define a function to count the instances of a task t that are also members of U as inst(t,U) = number of instances of t that are members of U (8)

34. Resource Competition (Revised) • The resource competition (RC) of a Grid resource r is redefined as (9) • where ti is a member of RT(r) and tj is a member of V • RT(r) is the set of tasks that can be executed by r

35. The Extended Besom Algorithm • Management of the member of the set U • Task instances are added to U as new workflow instance is generated (unchanged) • Task instances outside loop are removed after being scheduled (unchanged) • Different from the original version, instances of the tasks inside loop are removed when the execution of that particular workflow instance exit loop • E.g. Instances of t2, t3 and t4 are removed when t5 becomes ready for execution

36. The Extended Besom Algorithm • Instance Generation phase and Iteration Control remain identical to the original version • Task Prioritising Phase and Resource Selection Phase are modified to accommodate the management of set U

37. Task Prioritising Phase

38. Resource Selection Phase

39. Implementing Scheduler Iteration Control Generator Executor Instance Generation Executor is the same for any algorithms but require workflow system functionality to execute tasks Generator may implement different scheduling algorithms Task Prioritising Resource Selection

40. SchedulerOverview

41. Schedule Generator • Implement scheduling algorithms to generate schedule • Besom • Min-Min, Max-Min, Xsufferage • A separate package which can be used by any workflow management system • Additional scheduling algorithm can be added with minimal modification

42. Schedule Executor • Uses Nimrod/K API to provides the algorithm with information required to generate a Grid workflow schedule • Start tasks in the workflow according to the generated schedule • Specific to Nimrod/K

43. Evaluation • Performance (makespan) against Min-Min, Max-Min and XSufferage algorithms • Three goals • Minimise bottleneck • Manage multiple workflow instances • Incorporate loop scheduling without loop unrolling • K constant that controls the effect of resource competition • Threshold for instance generation

44. Simulation Setup • Simulation environment is implemented into Nimrod/K • Parameter Sweep Actor (PS) is used to generate instances and does not require Grid execution. • Dummy actor which sleeps for a period of time equal to the ECT as if it is executed by a particular resource. • File transfer is also simulated using sleeps • Three different workflow structure: sequential, parallel, and mixed structure. • Three different execution settings featuring different degrees of resource competition.

45. TheThree Workflow Structures Sequential (S) Parallel (P) Mixed Structure (M)

46. The Three Execution Settings • Setting (1), the resource r2has a very high resource competition(RC) value as it is the only resource that can run t2, t3 and t4 • Simulation (2) and (3), RC of r2 is distributed to r1 and r3

47. Simulation Scenarios • Total 9 scenarios • S1, S2, S3 • P1, P2, P3 • M1, M2, M3 (e.g. S1 is the sequential workflow using the first execution setting) • Transfer rates between Grid resources are assumed to be static

48. Base-Run • Use all 9 scenarios • Threshold in Instance Generation phase is defined using the number of unscheduled task instances and the number of free resource nodes • “Threshold Multiplier” is set to 2 • Workflow instance is generated until the number of unscheduled instances is at least twice the number of free nodes • K constant is set to 2.4 • Execute 1, 5, 10, 20, 50, and 100 workflow instances

49. Improvement in Sequential Scenarios

50. Result: Sequential Scenarios • In S1 and S2 only little improvement can be observed since r2 become a bottleneck. No resource selection actually takes place for t2, t3 and t4. • Slight improvement gained at the beginning and near the end due to consideration of Resource Competition and transfer time • S2 shows a weakness inherent to the XSufferage • The Besom algorithm improves the performance over Min-Min in S3 by avoiding allocating the r2, r3, and r4to tasks t1 and t5which can run on other resources.