This document summarizes a joint workshop on workflow allocations and scheduling on Infrastructure as a Service (IaaS) platforms. It discusses using on-demand resources to more efficiently allocate workflows compared to static allocations. It proposes two algorithms, Eager and Deferred, to determine allocations within a given budget limit. Simulations using synthetic workflows showed Deferred guarantees budget constraints while Eager is faster. For small applications and budgets, Deferred is preferred. For larger applications and budgets approaching task parallelism saturation, Eager performs better. The document also discusses a prototype system using Nimbus, Phantom and DIET to deploy workflows on IaaS resources.

1. Workflow Allocations and Scheduling on IaaS
Platforms, from Theory to Practice
Eddy Caron1 , Fr´d´ric Desprez2 , Adrian Muresan1 , Fr´d´ric
e e , e e
Suter3 , Kate Keahey4
1 Ecole Normale Sup´rieure de Lyon, France
e
2 INRIA
3 IN2P3 Computing Center, CNRS, IN2P3
4 UChicago, Argonne National Laboratory
Joint-lab workshop

2. Outline
Context
Theory
Models
Proposed solution
Simulations
Practice
Architecture
Application
Experimentation
Conclusions and perspectives

3. Workflows are a common pattern in scientific applications
applications built on legacy code
applications built as an aggregate
use inherent task parallelism
phenomenons having inherent workflow structure
Workflows are omnipresent!

4. (a) Ramses (b) Montage
(c) Ocean current modeling (d) Epigenomics
Figure Workflow application examples

5. Classic model of resource provisioning
static allocations in a grid environment
researchers compete for resources
researchers tend to over-provision and under-use
workflow applications have a non-constant resource demand
This is inefficient, but can it be improved?

6. Classic model of resource provisioning
static allocations in a grid environment
researchers compete for resources
researchers tend to over-provision and under-use
workflow applications have a non-constant resource demand
This is inefficient, but can it be improved?
Yes!
How?

7. Classic model of resource provisioning
static allocations in a grid environment
researchers compete for resources
researchers tend to over-provision and under-use
workflow applications have a non-constant resource demand
This is inefficient, but can it be improved?
Yes!
How?
on-demand resources
automate resource provisioning
smarter scheduling strategies

8. Why on-demand resources?
more efficient resource usage
eliminate overbooking of resources
can be easily automated
unlimited resources ∗

9. Why on-demand resources?
more efficient resource usage
eliminate overbooking of resources
can be easily automated
unlimited resources ∗ =⇒ budget limit

10. Why on-demand resources?
more efficient resource usage
eliminate overbooking of resources
can be easily automated
unlimited resources ∗ =⇒ budget limit
Our goal
consider a more general model of workflow apps
consider on-demand resources and a budget limit
find a good allocation strategy

11. Related work
Functional workflows
Bahsi, E.M., Ceyhan, E., Kosar, T.: Conditional Workflow Management: A Survey and Analysis. Scientific
Programming 15(4), 283–297 (2007)
biCPA
Desprez, F., Suter, F.: A Bi-Criteria Algorithm for Scheduling Parallel Task Graphs on Clusters. In: Proc.
of the 10th IEEE/ACM Intl. Symposium on Cluster, Cloud and Grid Computing. pp. 243–252 (2010)
Chemical programming for workflow applications
Fernandez, H., Tedeschi, C., Priol, T.: A Chemistry Inspired Workflow Management System for Scientific
Applications in Clouds. In: Proc. of the 7th Intl. Conference on E-Science. pp. 39–46 (2011)
Pegasus
TMalawski, M., Juve, G., Deelman, E. and Nabrzyski, J..: Cost- and Deadline-Constrained Provisioning
for Scientific Workflow Ensembles in IaaS Clouds. 24th IEEE/ACM International Conference on
Supercomputing (SC12) (2012)

12. Outline
Context
Theory
Models
Proposed solution
Simulations
Practice
Architecture
Application
Experimentation
Conclusions and perspectives

13. 1 1 1
Loop
Or
2 3 2 3 2 3
4 4
4
(a) Classic (b) PTG (c) Functional
Figure Workflow types

14. Application model
Non-deterministic (functional) workflows
An application is a graph G = (V, E), where
V = {vi |i = 1, . . . , |V |} is a set of vertices
E = {ei,j |(i, j) ∈ {1, . . . , |V |} × {1, . . . , |V |}} is a set of edges
representing precedence and flow constraints
Vertices
a computational task [parallel, moldable]
an OR-split [transitions described by random variables]
an OR-join

15. Example workflow
Figure Example workflow

16. Platform model
A provider of on-demand resources from a catalog:
C = {vmi = (nCPUi , costi )|i ≥ 1}
nCPU represents the number of equivalent virtual CPUs
cost represents a monetary cost per running hour
(Amazon-like)
communication bounded multi-port model
Makespan
C = maxi C (vi ) is the global makespan where
C (vi ) is the finish time of task vi ∈ V
Cost of a schedule S
Cost = ∀vmi ∈S Tendi − Tstarti × costi
Tstarti , Tendi represent the start and end times of vmi
costi is the catalog cost of virtual resource vmi

17. Problem statement
Given
G a workflow application
C a provider of resources from the catalog
B a budget
find a schedule S such that
Cost ≤ B budget limit is not passed
C (makespan) is minimized
with a predefined confidence.

18. Proposed approach
1. Decompose the non-DAG workflow into DAG sub-workflows
2. Distribute the budget to the sub-workflows
3. Determine allocations by adapting an existing allocation
approach

19. Step 1: Decomposing the workflow
Figure Decomposing a nontrivial workflow

20. Step 2: Allocating budget
1. Compute the number of executions of each sub-worflow
# of transitions of the edge connecting its parent OR-split to
its start node
Described by a random variable according to a distinct normal
distribution + confidence parameter
2. Give each sub-workflow a ratio of the budget proportional to its
work contribution.
Work contribution of a sub-workflow G i
as the sum of the average execution times of its tasks
average execution time computed over the catalog C
task speedup model is taken into consideration
multiple executions of a sub-workflow also considered

21. Step 3: Determining allocations
Two algorithms based on the bi-CPA algorithm.
Eager algorithm
one allocation for each task
good trade-off between makespan and average time-cost area
fast algorithm
considers allocation-time cost estimations only

22. Step 3: Determining allocations
Two algorithms based on the bi-CPA algorithm.
Eager algorithm
one allocation for each task
good trade-off between makespan and average time-cost area
fast algorithm
considers allocation-time cost estimations only
Deferred algorithm
outputs multiple allocations for each task
good trade-off between makespan and average time-cost area
slower algorithm
one allocation is chosen at scheduling time

23. Algorithm parameters
over under average work allocated to tasks
TA , TA
TCP duration of the critical path
B estimation of the used budget when TA and TCP
meet
TA keeps increasing as we increase the
allocation of tasks and TCP keeps decreasing so
they will eventually meet.
When they do meet we have a trade-off between
the average work in tasks and the makespan.
p(vi ) number of processing units allocated to task vi

24. The eager allocation algorithm
1: for all v ∈ V i do
2: Alloc(v ) ← {minvmi ∈C CPUi }
3: end for
4: Compute B
|V i |
5: while TCP > TA ∩ j=1 cost(vj ) ≤ B i do
over
6: for all vi ∈ Critical Path do
7: Determine Alloc (vi ) such that p (vi ) = p(vi ) + 1
8: Gain(vi ) ← T (vi ,Alloc(vi )) − T (vi ,Alloc) (vi ))
p(vi ) p (vi
9: end for
10: Select v such that Gain(v ) is maximal
11: Alloc(v ) ← Alloc (v )
12: over
Update TA and TCP
13: end while
Algorithm 1: Eager-allocate(G i = (V i , E i ), B i )

25. Methodology
Simulation using SimGrid
Used 864 synthetic workflows for three types of applications
Fast Fourier Transform
Strassen matrix multiplication
Random workloads
Used a virtual resource catalog inspired by Amazon EC2
Used a classic list-scheduler for task mapping
Measured
Cost and makespan after task mapping
Name #VCPUs Network performance Cost / hour
m1.small 1 moderate 0.09
m1.med 2 moderate 0.18
m1.large 4 high 0.36
m1.xlarge 8 high 0.72
m2.xlarge 6.5 moderate 0.506
m2.2xlarge 13 high 1.012
m2.4xlarge 26 high 2.024
c1.med 5 moderate 0.186
c1.xlarge 20 high 0.744
cc1.4xlarge 33.5 10 Gigabit Ethernet 0.186
cc2.8xlarge 88 10 Gigabit Ethernet 0.744

26. Equality
1.6
1.4
Relative makespan
1.2
1
0.8
0.6
0.4
0.2
0
1 5 10 15 20 25 30 35 40 45 50
Budget limit
Eager
Figure Relative makespan ( Deferred ) for all workflow applications

27. 5
Equality
4
Relative cost
3
2
1
0
1 5 10 15 20 25 30 35 40 45
Budget limit
Eager
Figure Relative cost ( Deferred ) for all workflow applications

28. First conclusions
Eager is fast but cannot guarantee budget constraint after
mapping
Deferred is slower, but guarantees budget constraint
After a certain budget they yield to identical allocations
for small applications and small budgets Deferred should be
preferred.
When the size of the applications increases or the budget limit
approaches task parallelism saturation, using Eager is
preferable.

29. Outline
Context
Theory
Models
Proposed solution
Simulations
Practice
Architecture
Application
Experimentation
Conclusions and perspectives

30. Architecture
Send workflow Acquire/release
DIET (MADAG) resources Nimbus
Workflow engine Phantom
Receive result service
Scientist
VM1
SeD Grafic1 SeD Ramses
VM2
Phantom Phantom
...
frontend frontend VM3
VMn
Manage Autoscaling Groups
Deploy workflow tasks
Figure System architecture

31. Main components
Nimbus
open-source IaaS provider
provides low-level resources (VMs)
compatible with the Amazon EC2 interface
used a FutureGrid install

32. Main components
Phantom
auto-scaling and high availability provider
high-level resource provider
subset of the Amazon auto-scale service
part of the Nimbus platform
used a FutureGrid install
still under development

33. Main components
MADag
workflow engine
part of the DIET (Distributed Interactive Engineering Toolkit)
software
one service implementation per task
each service launches its afferent task
supports DAG, PTG and functional workflows

34. Main components
Client
describes his workflow in xml
implements the services
calls the workflow engine
no explicit resource management
selects the IaaS provider to deploy on

35. How does it work?
Send workflow Acquire/release
DIET (MADAG) resources Nimbus
Workflow engine Phantom
Receive result service
Scientist
VM1
SeD Grafic1 SeD Ramses
VM2
Phantom Phantom
...
frontend frontend VM3
VMn
Manage Autoscaling Groups
Deploy workflow tasks
Figure System architecture

36. RAMSES
n-body simulations of dark matter interactions
backbone of galaxy formations
AMR workflow application
parallel (MPI) application
can refine at different zoom levels

37. RAMSES
Figure The RAMSES workflow

38. Methodology
used a FutureGrid Nimbus installation as a testbed
measured running time for static and dynamic allocations
estimated cost for each allocation
varied maximum number of used resources

39. Figure Slice through a 28 × 28 × 28 box simulation

40. Results
25:00 Runtime (static)
VM alloc (dynamic)
Runtime (dynamic)
Running time (MM:SS) 20:00
15:00
10:00
5:00
0 2 4 6 8 10 12 14 16
Number of VMs
Figure Running times for a 26 × 26 × 26 box simulation

41. Results
Cost (static)
25 Cost (dynamic)
Cost (units) 20
15
10
5
0
0 2 4 6 8 10 12 14 16
Number of VMs
Figure Estimated costs for a 26 × 26 × 26 box simulation

42. Outline
Context
Theory
Models
Proposed solution
Simulations
Practice
Architecture
Application
Experimentation
Conclusions and perspectives

43. Conclusions
proposed two algorithms – Eager and Deferred with each their
pro and cons
on-demand resources can better model workflow usage
on-demand resources have a VM allocation overhead
allocation overhead decreases with number of VMs
for RAMSES, cost is greatly reduced

44. Perspectives
preallocate VMs
spot instances
smarter scheduling strategy
determine per application type which is the tipping point
Compare our algorithms with others

45. Perspectives
preallocate VMs
spot instances
smarter scheduling strategy
determine per application type which is the tipping point
Compare our algorithms with others
Collaborations
Continue the collaboration with the Nimbus/FutureGrid teams
On the algorithms themselves (currently too complicated for
an actual implementation)
Understanding (obtaining models) clouds and virtualized
platforms
going from theoretical algorithms to (accurate) simulations
and actual implementation

46. References
Eddy Caron, Fr´d´ric Desprez, Adrian Muresan and Fr´d´ric Suter.
e e e e
Budget Constrained Resource Allocation for Non-Deterministic
Workflows on a IaaS Cloud. 12th International Conference on
Algorithms and Architectures for Parallel Processing. (ICA3PP-12),
Fukuoka, Japan, September 04 - 07, 2012
Adrian Muresan, Kate Keahey. Outsourcing computations for galaxy
simulations. In eXtreme Science and Engineering Discovery Environment
2012 - XSEDE12, Chicago, Illinois, USA, June 15 - 19 2012. Poster
session.
Adrian Muresan. Scheduling and deployment of large-scale applications
on Cloud platforms. Laboratoire de l’Informatique du Parall´lisme (LIP),
e
ENS Lyon, France, Dec. 10th, 2012 PhD thesis.

48. Algorithm parameters
over
TA - Eager
|V i |
over 1
TA = × (T (vj , Alloc(vj )) × cost(vj )) ,
B
j=1
under
TA - Deferred
|V i |
under 1
TA = × (T (vj , Alloc(vj )) × costunder (vj ))
B
j=1

49. Budget distribution algorithm
1: ω∗ ← 0
2: for all G i = (V i , E i ) ⊆ G do
3: nExec i ← CDF −1 (D i , Confidence)
 
4: ωi ←  1 T (vj , vmk ) × nExec i
|C|
vj ∈Vi vmk ∈C
5: ω∗ ← ω∗ + ωi
6: end for
7: for all G i ⊆ G do
ωi 1
8: B i ← B × ω∗ × nExec i
9: end for
Algorithm 2: Share Budget(B, G, Confidence)

50. Absolute makespans
01:20:00
01:10:00
Makespan (HH:MM:SS)
01:00:00
00:50:00
00:40:00
00:30:00
00:20:00
00:10:00
00:00:00
1 5 10 15 20 25 30 35 40 45
Budget limit
(a) Eager for all workflow applications

51. Absolute makespans
01:20:00
01:10:00
Makespan (HH:MM:SS)
01:00:00
00:50:00
00:40:00
00:30:00
00:20:00
00:10:00
00:00:00
1 5 10 15 20 25 30 35 40 45
Budget limit
(b) Deferred for all workflow applications

52. Absolute cost
50
Budget limit
40
30
Cost
20
10
0
1 5 10 15 20 25 30 35 40 45 50
Budget limit
(c) Eager for all workflow applications

53. Absolute cost
50
Budget limit
40
30
Cost
20
10
0
1 5 10 15 20 25 30 35 40 45 50
Budget limit
(d) Deferred for all workflow applications