Multicriteria approach to scheduling in Grids with QoS guarantees

1. Multicriteria approach to scheduling in Grids with QoS guarantees Krzysztof Kurowski1, Jarek Nabrzyski1, Ariel Oleksiak1, Jan Węglarz12 1Poznan Supercomputing and Networking Center 2Institute of Computing Science, Poznan University of Technology

2. Introduction Architecture and model Evaluation of multi-user schedules Search algorithms Resource provider policies Experiments and results Conclusion Outline

3. Introduction • Grids • Resource provision across administrative domains • Multiple objectives of users and providers of Grids • Requirement for guaranteed quality of service • Goals of this work • Optimization of total ‘satisfaction’ of Grid users • Scheduling with QoS

4. Easier expression of user preferences Mostly time and cost rather than technical details of resources Providing users with a priori information about waiting and execution times Essential, e.g. for interactive applications Reliable calculation of resource utilization costs Users are aware what they are charged for Realization of a quality of service (QoS) e.g. handling jobs with deadlines Scheduling with advance reservations

5. Each user may evaluate allocations using multiple criteria E.g. different preferences concerning resource usage cost, start time, resource speed, reliability, etc. Users may have different objectives and constraints depending on their available budgets and time obligations Therefore common global criteria such as makespan or mean completion time not suitable Stakeholders of the Grid resource management process have different points of view Users expects meeting their objectives such as cost, time, etc. Resource providers are interested in high income Multi-criteria multi-user scheduling

6. Architecture

7. Architecture • Users • Grid Scheduler • Resource Providers j|J|+1, j|J|+2,…

8. Scenario1: Outsourcing jobs from the so-called Virtual Organization, e.g. a community consisting of researchers from multiple universities Scenario2: Enterprise provides a facility to its employees to enable fair access to outsourced resources Scenario3: Third-party portal provides registered users equitable access to resources in the Grid Scenarios

9. Jobs Both serial and parallel (rigid) jobs Non-preemptive Do not require co-allocation however may be “big” Various length (may be “long”) Substantial number of jobs (rather hundreds than thousands) Estimated duration given by users Resources Internally homogeneous clusters Owned by resource providers Advance reservation capability available Model

10. Finite set of users U=u1, u2, …, uk Finite set of users’ jobs J = j1,j2,…, jn Jobs from set J compete for resources offered by resource providers RP = rp1, rp2,…, rpm For each job users define resource requirements and preferences Resource providers offer resources as time slots with a specified number of processors and cost Model

11. Model - Resource Offers Each offer is defined by oi = (tistart, tiend, ri, ci), where Oi = oi1,,oi2, …, oil, l=|O| ri - resource speed, ci - cost for allocation unit CPUs c1 c2 c3 O4 J11 O3 J8 O7 J9 J10 Reservations J5 J6 O5 J7 O2 J4 J5 O8 Available time slots O3 O1 J3 O10 O11 O9 J2 O6 J1 time

12. Problem Find a schedule of jobs J of users U on resource providers’ offers O maximizing total utility and fairness Hard constraints Resource requirements, e.g. operating system, CPU architecture, etc. Time requirements, e.g. deadlines, etc. Soft constraints (users’ objectives) Start time Cost Resource speed (CPU speed, GFLOPs, linpack benchmark) Solutions Sets of assignments of jobs to resources within certain time slots {(ji, Onj, tstart, tend), i=1..n, j=1..k} Model – Problem Definition

13. Usual way of formulating requirements in Grid systems in the form of hard constraints E.g. maximal cost and deadline However, this representation was not convenient since It is difficult to for users to specify exact values It gives little flexibility for a Grid scheduler Modeling preferences of a single user Resource requirements using JSDL <…> <jsdl:Resources> <jsdl:IndividualCPUCount> <jsdl:exact>2</jsdl:exact> </jsdl:IndividualCPUCount> <jsdl:IndividualCPUSpeed> <jsdl:LowerBoundedRange>1GHz </jsdl:LowerBoundedRange> </jsdl:IndividualCPUSpeed> </jsdl:Resources> <…> Advance reservation in LSF brsvadd -n 1024 -m hostA -u user1 \ -b 6:0 -e 8:0

14. Reference values used to reflect end-user’s preferences Two reference values Required: r Desired: d If a user cannot specify reference values d=0 and r=max(gi) is assumed Scaling function: Expressing preferences

15. Ordered Weighted Aggregator (OWA) Combines minimum, maximum, and arithmetic mean Particular behavior can be controlled setting proper weights Criteria Aggregation • Weights for aggregation of users’ preferences

16. If no information about preferences for every user Aggregation of criteria for multiple users time time R1 R1 R2 R2 R3 R3 R4 R4 cost cost • Then if we treat ‘satisfaction’ of particular users as criteria S1 S2 r2 U1: r1 U2: r4 r3

17. If preferences of multiple users are available utility of each user can be used as separate objective OWA can be used for the aggregation of criteria as, it allows to configure it by accurate setting of weights, e.g. For w1 = w2 = … = wn = 1/n, OWA is an arithmetic mean For w1 = 1 and w2 = … = wn = 0, OWA is a minimum The worst value is maximized OWA properties Finds Pareto-optimal solutions if weights are non-negative Finds equitable solutions if weights are strictly decreasing (if yi > yj then y - eyi + eyj is better than y for 0 < e < yi - yj) Aggregation of criteria for multiple users

18. Aggregation of criteria for multiple users - weights Quantifier “at least k%” [Yager, 1988] Can be interpreted as k% of criteria should be satisfied Formula to compute the weights proposed by [Yager, 1988] In our case a linear function used to simplify calculations and ensure strict monotonicity of weights Question: how to estimate k?

19. Motivation Quick answer to users’ requests Allowing users to confirm selected allocations May be applied developing more complex method Assumptions: Select solutions which are the best for a given user and possibly worst for others If there are more than one solution that satisfies a user choose the worst for others Prefer users that did not obtain allocations matching their preferences in the past Heuristic for search for fair allocations

20. Aggregation of criteria for multiple users - weights For each resource offer oi and user jj a relative utility u’ decreased by utilities of alternative offers (sorted and weighted according to decreasing utilities) is calculated U U’

21. Aggregation of criteria for multiple users - weights

22. Idea: like fair scheduling in queuing systems Take into account historical decisions during scheduling However if we record only utility of allocated offer user is able to cheat By submitting artificial very demanding request hi = ui* - ui, where u* was a utility of the best offer while ui of the allocated one for user i in the previous request Dynamic priority: dpi = (mean(hi) + last(hi))/2 Aggregation of criteria for multiple users - using history

23. Why EA? Useful for multicriteria optimization especially for such a big number of criteria Flexibility General approach In the first iterations very broad search to generate possible diverse Pareto-optimal solutions In the second part of optimization more focused search (OWA with set weights used to direct search towards fair solutions) Specialized operators to obtain fair solutions Optimization using evolutionary algorithm

24. Representation Vector of assignments: <oi, jj, t> Operators Mutations: Exchange of allocations: one is changed to a similar one (still Pareto-efficient) so that other job gets satisfactory solution Using heuristic described before for part of jobs Crossover: Random exchange of allocations, Exchanging allocations trying to skip the most unfair ones Optimization using evolutionary algorithm - representation & operators

25. Results Comparison with traditional methods with preferences in the form of hard constraints • MCT+ED - earliest due date + minimum completion time • GR+LSF - Largest First + Graham algorithm • MC - multi-criteria assignment of single jobs • MU- multi-user

26. The main goal is to maximize income Requests may come from more then single source Some of them are Grid schedulers Local users may submit jobs Resource providers reserve offered resources for a certain time; after that time offer is not valid Parameters of policies Fraction of resources offered to Grid scheduler(s) Expiring time of initial reservations Cost policy Policies of resource providers

27. Results Percentage of resources offered to a Grid scheduler Overbooking: offering x% of available resources to more than one consumer

28. Model for scheduling in Grids with advance reservations shown Formulation of the problem as maximizing satisfaction (total utility and fairness) of multiple users A framework for solving multicriteria problem including: Setting appropriate weights to obtain schedule satisfying more users Simple heuristic to allocate jobs to offered resources Evolutionary algorithm that optimizes aggregated satisfaction of users Experimental results Conclusion

29. More experiments and improvements of the evolutionary algorithm Theoretical analysis of heuristics and measures Dealing with imprecision of estimated runtimes Further study of resource provider policies Implementation in real environment in progress: GRMS and OpenDSP Future work