Bez tytulu slajdu

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

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

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
Scheduling with advance reservations

• 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

5
Multi-criteria multi-user scheduling

• 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

6
Architecture
7
Architecture

• Users
• Grid Scheduler
• Resource Providers

jJ1, jJ2,
8
Scenarios

• 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

9
Model

• 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

10
Model

• Finite set of users Uu1, 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

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

• 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),
  i1..n, j1..k

13
Modeling preferences of a single user
Resource requirements using JSDL

• 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

ltgt ltjsdlResourcesgt ltjsdlIndividualCPUCountgt ltj
sdlexactgt2lt/jsdlexactgt lt/jsdlIndividualCPUCount
gt ltjsdlIndividualCPUSpeedgt ltjsdlLowerBoundedR
angegt1GHz lt/jsdlLowerBoundedRangegt
lt/jsdlIndividualCPUSpeedgt lt/jsdlResourcesgt ltgt
Advance reservation in LSF
brsvadd -n 1024 -m hostA -u user1 \ -b 60 -e 80
14
Expressing preferences

• Reference values used to reflect end-users
  preferences
• Two reference values
• Required r
• Desired d
• If a user cannot specify reference values d0 and
  rmax(gi) is assumed
• Scaling function

15
Criteria Aggregation

• Ordered Weighted Aggregator (OWA)
• Combines minimum, maximum, and arithmetic mean
• Particular behavior can be controlled setting
  proper weights

• Weights for aggregation of users preferences

16
Aggregation of criteria for multiple users

• If no information about preferences for every user

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
Aggregation of criteria for multiple users

• 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 gt yj then y - eyi eyj is
  better than y for 0 lt e lt yi - yj)

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
Heuristic for search for fair allocations

• 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

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
j1 j2 j3
o1 1 1 1
o2 0 0 0
o3 0 0 0
j1 j2 j3
o1 1 0 1
o2 1 1 0
o3 0 1 1
j1 j2 j3
o1 1 0.8 0.5
o2 0.9 0.2 0.6
o3 0.2 0 0.3
U
j1 j2 j3
o1 0.5 0.7 0.13
o2 0.35 -0.2 0.28
o3 -0.53 -0.45 -0.1
j1 j2 j3
o1 0.5 0 0.5
o2 0.5 0.5 0
o3 0 0.5 0.5
j1 j2 j3
o1 1 1 1
o2 -0.5 -0.5 -0.5
o3 -0.5 -0.5 -0.5
U
21
Aggregation of criteria for multiple users -
weights
j1 j2 j3
o1 0.5 0.7 0.13
o2 0.35 -0.2 0.28
o3 -0.53 -0.45 0
j1 j2 j3
o1 0.5 0.7 0.13
o2 0.35 -0.2 0.28
o3 -0.53 -0.45 -0.1
j1 j2 j3
o1 0.5 0.7 0.13
o2 0.7 -0.2 0.5
o3 -0.53 -0.45 -0.1
j1 j2 j3
o1 0.5 0 0.5
o2 0.5 0.5 0
o3 0 0.5 0.5
j1 j2 j3
o1 1 1 1
o2 -0.5 -0.5 -0.5
o3 -0.5 -0.5 -0.5
22
Aggregation of criteria for multiple users -
using history

• 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

23
Optimization using evolutionary algorithm

• 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

24
Optimization using evolutionary algorithm -
representation operators

• Representation
• Vector of assignments ltoi, jj, tgt
• 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

25
Results
Comparison with traditional methods with
preferences in the form of hard constraints

• MCTED - earliest due date minimum completion
  time
• GRLSF - Largest First Graham algorithm
• MC - multi-criteria assignment of single jobs
• MU- multi-user

26
Policies of resource providers

• 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

27
Results
Percentage of resources offered to a Grid
scheduler
Overbooking offering x of available resources
to more than one consumer
28
Conclusion

• 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

29
Future work

• 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