1

A Study of Deadline Scheduling for Client-Server Systems on the Computational Grid

Atsuko Takefusa, Henri Casanova, Satoshi Matsuoka, Francine Berman

Presenter: Pushpinder Kaur Chouhan

2

Outline

Computational Grid & NES Overview of Bricks A Deadline-scheduling algorithm

Load Correction mechanism Fallback mechanism

Experiments Failure rates Resource cost Multiple Fallbacks

Conclusion Future work View

3

The Computational Grid

A promising platform for the deployment of HPC applications

Effective use of resources A crucial issue is Scheduling

4

NES: Network-Enabled Server Grid software which provides a

service on the network Client-server architecture RPC-style programming model Many high-profile applications from

science and engineering are amenable

Scheduling in multi-client multi-server scenario?

5

Scheduling for NES Resource economy model

Grid currency allow owners to “charge” for usage

$$$$$$$$$$$ Choice?

No actual economical model is implemented Deadline-scheduling algorithm

Users specify deadlines for the task of their apps.

6

Approach Goal is to minimize

The overall occurrences of deadline misses The reduction of resource cost

Assumptions Each request comes with a deadline

requirement Resources are priced proportionally to their

performance Simulation framework

Bricks: Performance evaluating system

7

The Bricks Architecture

Scheduler

NetworkMonitor ServerMonitor

ClientNetwork

NetworkServer

Scheduling UnitScheduling Unit

Global Computing EnvironmentGlobal Computing Environment

ResourceDB

NetworkPredictorServerPredictor

Predictor

8

Scheduler

Predictor

NetworkMonitorServerMonitor

ClientNetwork

NetworkServer

ResourceDB

Grid Computing Environment Client

Represents the user machine, upon which global computing tasks are initiated by the user program.

Server Represents computational resources

Network Represents the network interconnecting the Client and the Server

Represented using queues

9

An Example of the Global Computing Environment Model

10

Communication/Server Models using queues in Bricks

Extraneous data/job modelCongestion represented by adjusting the amount of arrival data/jobs from other nodes/users

Trace modelBandwidth/performance at each step = trace data such as observed parameters of real environment.

Need to specify several parametersGreater accuracy requires larger simulation cost

Network/Server behaves as if real network/serverSimulation cost lower than the previous modelNeed to accumulate the measurements

11

Scheduler

Predictor

NetworkMonitorServerMonitor

ClientNetwork

NetworkServer

ResourceDB

Scheduling Unit Network/ServerMonitor

Measures/monitors network/server status on the Grid

ResourceDBServes as scheduling-specific database, storing the values of various measurements.

PredictorReads the measured resource information from ResourceDB, and predicts availability of resources.

SchedulerAllocates a new task invoked by a client

on suitable server machine(s)

12

Overview of Grid Computing Simulation with Bricks

Scheduler

NetworkMonitor ServerMonitor

ClientNetwork

NetworkServer

Scheduling UnitScheduling Unit

Grid Computing EnvironmentGrid Computing Environment

ResourceDB

Monitor periodically

Store observed informationInquire

suitable server

Query available servers

Query predictions

Execute taskReturn results

NetworkPredictor

Invoke task

ServerPredictor

Return scheduling info

Predictor

Send the task

Predictions Perform Predictions

13

Deadline-Scheduling

Many NES scheduling strategies Greedy assigns requests to the server that completes

it the earliest Deadline-scheduling:

Aims at meeting user-supplied job deadline specifications

Server 1

Server 2

Server 3

Job execution time

Deadline$

$$$$$

$$

14

A Deadline-Scheduling Algorithm for multi-client/server NES

1 Estimate job processing timeTsi on each server Si ：Tsi = Wsend/Psend + Wrecv/Precv + Ws/Pserv (0 i < n)Wsend, Wrecv, Ws: send/recv data size, and logical comp. costPsend, Precv, Pserv: estimated send/recv throughput, and performance

2 Compute Tuntil deadline:Tuntil deadline = Tdeadline - now

Server 1Server 2Server 3

Comp.

Estimated job execution time

Send Recv

now Tuntil deadlineDeadline

15

A Deadline-Scheduling Algorithm (cont.)

3 Compute target processing time Ttarget:Ttarget = Tuntil deadline x Opt (0 < Opt 1)

4 Select suitable server Si:Conditions ： MinDiff=Min(Diff si) where Diff si=Ttarget–Tsi0

Min(|Diff|) otherwise

now

Tuntil deadline

Ttarget

Server 1Server 2Server 3

Comp.

Estimated job execution time

Send Recv

16

Factors in Deadline-Scheduling Failures

Accuracy of predictions is not guaranteed Monitoring systems do not perceive, load

change instantaneously Tasks might be out-of-order in FCFS

queues

17

Ideas to improve schedule performance Scheduling decisions will result in an

increase in load of scheduled nodes

Server can estimate whether it will be able to complete the task by the deadline

Load Correction: Use corrected load values

Fallback: Transfered a scheduling functionality to server

18

The Load Correction Mechanism Modify load predictions from monitoring system, Loa

dSi, as follows:LoadSi corrected = LoadSi + Njobs Si x ploadNjobs Si: the number of scheduled and unfinished jobs on the

server Si

Pload (= 1): arbitrary value that determines the magnitude

Scheduler

NetworkMonitor ServerMonitor

ResourceDB

NetworkPredictorServerPredictor

PredictorCorrected prediction

19

The Fallback Mechanism Server can estimate whether it will be able to complet

e the task by the deadline Fallback happens when:

Tuntil deadline < Tsend + ETexec + ETrecv

Nmax. fallbacks NfallbacksTsend : Comm. duration (send)ETexec, ETrecv: Estimated comm. (recv) and comp. duration Nfallbacks, Nmax. fallbacks : Total/Max. number of fallbacks

Client Server

SchedulerServer

FallbackRe-submit

20

Experiments Performance criteria:

Failure rate: Percentage of requests that missed their deadline

Resource cost: Avg. resource cost over all requestscost = machine performanceE.g. select 100 Mops/s and 300 Mops/s

servers Resource cost=200

Multiple Fallbacks: Resubmission of the request

21

Scheduling Algorithms

Greedy: Typical NES scheduling strategy Deadline (Opt = 0.5, 0.6, 0.7, 0.8, 0.9) Load Correction (on/off) Fallback (Nmax fallbacks = 0/1/2/3/4/5)

22

Configurations of the Bricks Simulation Grid Computing Environment (75 nodes, 5

Grids) # of local domain: 10, # of local domain nodes: 5-10 Avg. LAN bandwidth: 50-100[Mbits/s] Avg. WAN bandwidth: 500-1000[Mbits/s] Avg. server performance: 100-500[Mops/s] Avg. server Load: 0.1

Characteristics of client jobs Send/recv data size: 100-5000[Mbits] # of instructions: 1.5-1080[Gops] Avg. intervals of invoking:

60(high load), 90(medium load), 120(low load) [min]

23

Simulation Environment The Presto II cluster:

128PEs at Matsuoka Lab., Tokyo Institute of Technology. Dual Pentium III 800MHz Memory: 640MB Network: 100Base/TX

Use APST[Casanova ’00] to deploy Bricks simulations

24 hour simulation x 2,500 runs(1 sim. takes 30-60 [min] with Sun JVM 1.3.0+HotSpot)

24

Comparison of Failure Rates(load: medium)

0

10

20

30

40

50

60

70

Greedy D-0.5 D-0.6 D-0.7 D-0.8 D-0.9

Failu

re R

ate

[%]

x/x

L/xx/F

L/F

Typical NES scheduling

Fallback leads tosignificant reductions

Load Correctionis NOT useful

25

Comparison of Failure Rates(Load: high, medium, low)

“Low” load leads to improved failure rates All show similar characteristics

0

10

20

30

40

50

60

70

Greedy D-0.5 D-0.6 D-0.7 D-0.8 D-0.9

Failu

re R

ate[

%] x/x

L/x

x/F

L/F

0

10

20

30

40

50

60

70

Greedy D-0.5 D-0.6 D-0.7 D-0.8 D-0.9

Failu

re R

ate

[%] x/x

L/x

x/F

L/F

0

10

20

30

40

50

60

70

Greedy D-0.5 D-0.6 D-0.7 D-0.8 D-0.9

Failu

re R

ate

[%]

x/x

L/x

x/F

L/F

High LowMedium

26

Comparison of Resource Costs

0

50

100

150

200

250

300

350

400

450

500

Greedy D-0.5 D-0.6 D-0.7 D-0.8 D-0.9

Avg

. Re

sou

rce

Co

st

x/x

L/x

x/F

L/F

Greedy leads to higher costs

Costs decrease when the algorithm becomes less conservative

27

Comparison of Failure Rates(x/F, Nmax. fallbacks = 0-5)

0

10

20

30

40

50

60

70

Greedy D-0.5 D-0.6 D-0.7 D-0.8 D-0.9

Failu

re R

ate

[%]

0

1

2

3

4

5

Multiple fallbacks causesignificant improvement

28

Comparison of Resource Costs(x/F, Nmax. fallbacks = 0-5)

0

50

100

150

200

250

300

350

400

450

500

Greedy D-0.5 D-0.6 D-0.7 D-0.8 D-0.9

Avg

. Res

ourc

e C

ost

0

1

2

3

4

5

Multiple fallbacks lead to“small” increases in costs

29

Conclusions Proposed a deadline-scheduling algorithm

for multi-client/server NES systems, and Load Correction and Fallback mechanisms

Investigated performance in multi-client multi-server scenarios with the improved Bricks

The experiments showed It is possible to make a trade-off between

failure-rate and resource cost Load correction mechanism may not be useful NES systems should use deadline-scheduling

with multiple fallbacks

30

Future Work

Make Bricks support more sophisticated economy models

Investigate their feasibility and improve deadline-scheduling algorithms

Implement the deadline-scheduling algorithm within actual NES systems

31

Views Deadline scheduling is a good

approach. Overall performance can be

increased. Resource cost can be decreased. Load correction mechanism is light. Real implementation is difficult.

32

Scheduling Framework

client

serverclient

client

server

WAN

task

result

34

Performance of a Deadline Scheduling Scheme Traditional scheduling deadline

scheduling Charging mechanisms will be adopted.

The Grids consists of various resources. The resources are shared by various users.

Grid Users want the lowest cost machines which process jobs in a fixed period of time

Deadline scheduling meets a deadline for returning the results of

jobs

35

A Hierarchical Network Topology on Bricks

Client

ServerClient

Server

Client

Server

Client

Server

Client

ClientServer

Client

Server

Client

Server

Client

Server

Client

Server

Server

Client

WAN

LAN

Local Domain

NetworkNetwork

trace