• Save
On Demand Resource Provisioning for BPEL Workflows Using Amazon's EC2, IEEE CCGrid 2009, Shanghai
Upcoming SlideShare
Loading in...5
×
 

On Demand Resource Provisioning for BPEL Workflows Using Amazon's EC2, IEEE CCGrid 2009, Shanghai

on

  • 494 views

BPEL is the de facto standard for business process modeling in today's enterprises and is a promising candidate for the integration of business and Grid applications. Current BPEL implementations do ...

BPEL is the de facto standard for business process modeling in today's enterprises and is a promising candidate for the integration of business and Grid applications. Current BPEL implementations do not provide mechanisms to schedule service calls with respect to the load of the target hosts.

In this presentation (as well as in the corresponding publication), a solution that automatically schedules workflow steps to underutilized hosts and provides new hosts using Cloud computing infrastructures in peak-load situations is presented.
The proposed approach does not require any changes to the BPEL standard. An implementation based on the ActiveBPEL engine and Amazon's Elastic Compute Cloud is presented.

Statistics

Views

Total Views
494
Views on SlideShare
494
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • Classical outline:\n- very brief introduction to BPEL, then Problem Statement/Motivation\n- Design introduces main components of architecture\n- Impl: no details\n- Evaluation w/ respect to performance\n
  • - BPEL = Business Process Execution Language\n
  • - All elements within a flow are executed in parallel unless the control flow is explicitly defined (arrows/connection)\n- Receive is starting point, receives input\n- Sequences are executed in parallel, then execution branches merge\n- Work is done in invoke operations -> external web services\n- Reply to user\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • Example: \n- Group of researchers shares infrastructure\nCompany offers web-based service that run BPEL in background -> Flash crowd effect\n\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • - Description (portType) of services in Workflow, not concrete target address\n- LoadBalancer determines the target service when invoke operation is executed\n- If no machine with low load is found => launch new instance using Provisioner\n
  • Hosting Environment = Middleware-Container in virtual/physical machine\n\nIMPORTANT: XML-snippet is in deployment descriptor which is not standardized/not part of BPEL\n
  • - add/update operation triggers WSDL parsing\n
  • WIPS = Whetstone Instructions per Second (mainly floating point)\nc_m = Capacity of m\n
  • - Sample: Nimbus/Virtual Workspaces uses WSRF and WS-Notification\n- EC2 offers plain Web Services with pulling mechanism\n
  • \n
  • Needed information is stored within partnerLink description of deployment descriptor (non-standardized, so no break in compatibility to BPEL standard)\n
  • Needed information is stored within partnerLink description of deployment descriptor (non-standardized, so no break in compatibility to BPEL standard)\n
  • Needed information is stored within partnerLink description of deployment descriptor (non-standardized, so no break in compatibility to BPEL standard)\n
  • Needed information is stored within partnerLink description of deployment descriptor (non-standardized, so no break in compatibility to BPEL standard)\n
  • \n
  • \n
  • \n
  • Problemstellung: \n- Veröffentlichung des Dienstes als „Public Service“ (Web Service). \n- A priori ist nicht bekannt, wieviele Nutzer es geben wird. \n- Bei einer hohen -Nutzeranzahl kommt es zur Verlangsamung oder gar Abbruch\n-> Einsatz von EC2, damit Skalierbarkeit gegeben ist und keine überschüssige Hardware vorhanden sein muss\n\n
  • - Only runs shown where VMs where booted\n- ECU = EC2-Compute Unit\n- Expected speedup: 4-5 times, reality: only 2-2,5 (single threaded library)\n- Fluctuations are due to number of VM boots\n
  • \n
  • \n
  • RW: \nDi Penta, WS-Binder (Policy)\nTRAP/BPEL, Proxy-Pattern\nfind_bind, Leymann, Language Extension\nMa et al., LoadBalancing of Engine, not Services\n
  • Frage: wie kommt man denn eigentlich zu den VM-Images? Unsere Tools benutzen ...\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

On Demand Resource Provisioning for BPEL Workflows Using Amazon's EC2, IEEE CCGrid 2009, Shanghai On Demand Resource Provisioning for BPEL Workflows Using Amazon's EC2, IEEE CCGrid 2009, Shanghai Presentation Transcript

  • On‐demand
Resource
Provisioning
for
BPEL
Workflows
Using
Amazons
EC2 Tim
Dörnemann,
Ernst
Juhnke,
Bernd
FreislebenDepartment
of
Mathema<cs
and
Computer
Science,
University
of
Marburg {doernemt,
ejuhnke,
freisleb}@informa<k.uni‐marburg.de
  • Outline Introduc<on
and
Mo<va<on Design Implementa<on Evalua<on Tim
Dörnemann Ernst Juhnke Bernd Freisleben 2
  • Business
Process
Execu<on
Lang‣ BPEL
is
the
de
facto
(OASIS)
standard
for
workflow
/
 business
process
modeling
in
the
web
service
area
‣ Programming
in
the
large:
complex
applica<ons
are
built
 by
composing
exis<ng
components
(web
services)
‣ the
composed
process
is
exposed
as
a
web
service
itself
 and
integrates
perfectly
into
SOAs Tim
Dörnemann Ernst Juhnke Bernd Freisleben 3
  • Business
Process
Execu<on
Lang <?xml
version="1.0"
encoding="UTF‐8"?> <process
...
"
name="processname"
suppressJoinFailure="no"
 targetNamespace="hfp://namespace.de/target"> 

<variables> 



...
 



<variable
name="inVar"
messageType="sns:inputMsg"
/> 



<variable
name="outVar"
messageType="sns:outMsg"
/> 

</variables> 

<partnerLinks> 



<partnerLink
name="startPL"





 







partnerLinkType="sns:startProcessPLT"

 







myRole="startRole"
/> 


... 

</partnerLinks> 

<flow
name="Flow1"> 



<links>
...
</links> 







<receive
name="receiveVideoFile"
createInstance="yes"
 






opera<on="startProcess"
partnerLink="startPL" 






portType="sns:invokePT"
variable="inVar"> 





<source
linkName="Connec<on2"
/> 





<source
linkName="Connec<on3"
/> 



</receive> 



<sequence
name="faceSequence"> 





<assign
name="Vid2FaceDet"
...
/> 





<invoke
name="FaceDetec<on"
partnerLink="gsPL"
 








portType="gs:FaceDetPort"
opera<on="doFaceDet" 








inputVariable="inVar"
outputVariable="outVar"
/> 





<assign
name="face2MP7"
.../> 





<source
linkName="Connec<on4"
/> 





<target
linkName="Connec<on2"
/> 



</sequence> 
... 
<reply
name="replyToUser"
opera<on="startProcess" 







partnerLink="startPL"
portType="sns:invokePT"



 







variable="outVar"> Tim
Dörnemann 





<target
linkName="Connec<on1"
/> Ernst Juhnke 

</reply> Bernd Freisleben 4
  • Business
Process
Execu<on
Lang‣ Des<na<ons
of
invoke
opera<ons
are
typically
set
at
 design
<me ‣ sejng
at
run<me
possible,
but
complicated
 Tim
Dörnemann Ernst Juhnke Bernd Freisleben 5
  • Business
Process
Execu<on
Lang <assign>‣ Des<na<ons
of
invoke
opera<ons
are
typically
set
at
 <copy> 
<from> design
<me 

<literal> 


<wsa:EndpointReference
xmlns:ns="NSPACE"> ‣ sejng
at
run<me
possible,
but
complicated
 



<wsa:Address> 





hfp://FQDN:PORT/SERVICE‐ADDRESS 



</wsa:Address> 



<wsa:ServiceName
PortName="Port"> 




ns:SERVICE‐NAME 



</wsa:ServiceName> 



<wsa:ReferenceParameters> 




<wsa:To>...</wsa:To> 




<wsa:Ac<on>...</wsa:Ac<on> 



</wsa:ReferenceParameters> 


</wsa:EndpointReference> 

</literal> 
</from> 
<to
variable="targetEPR"/> </copy> <copy> 
<from
variable="targetEPR"
/> 
<to
partnerLink="targetPL"
/> </copy> </assign> Tim
Dörnemann Ernst Juhnke Bernd Freisleben 5
  • Business
Process
Execu<on
Lang‣ Des<na<ons
of
invoke
opera<ons
are
typically
set
at
 design
<me ‣ sejng
at
run<me
possible,
but
complicated
 ‣ mixup
of
business
logic
and
 <assign> <copy> infrastructural
sejngs 
<from> 

<literal> 


<wsa:EndpointReference
xmlns:ns="NSPACE"> 



<wsa:Address> 





hfp://FQDN:PORT/SERVICE‐ADDRESS 



</wsa:Address> 



<wsa:ServiceName
PortName="Port"> 




ns:SERVICE‐NAME 



</wsa:ServiceName> 



<wsa:ReferenceParameters> 




<wsa:To>...</wsa:To> 




<wsa:Ac<on>...</wsa:Ac<on> 



</wsa:ReferenceParameters> 


</wsa:EndpointReference> 

</literal> 
</from> 
<to
variable="targetEPR"/> </copy> <copy> 
<from
variable="targetEPR"
/> 
<to
partnerLink="targetPL"
/> Tim
Dörnemann </copy> Ernst Juhnke </assign> Bernd Freisleben 5
  • Business
Process
Execu<on
Lang‣ Des<na<ons
of
invoke
opera<ons
are
typically
set
at
 design
<me ‣ sejng
at
run<me
possible,
but
complicated
 ‣ mixup
of
business
logic
and
 <assign> <copy> infrastructural
sejngs 
<from> 

<literal> 


<wsa:EndpointReference
xmlns:ns="NSPACE"> ‣ very
high
modeling
overhead
for
 



<wsa:Address> 





hfp://FQDN:PORT/SERVICE‐ADDRESS dynamic
resource
selec<on 



</wsa:Address> 



<wsa:ServiceName
PortName="Port"> 




ns:SERVICE‐NAME 



</wsa:ServiceName> 



<wsa:ReferenceParameters> 




<wsa:To>...</wsa:To> 




<wsa:Ac<on>...</wsa:Ac<on> 



</wsa:ReferenceParameters> 


</wsa:EndpointReference> 

</literal> 
</from> 
<to
variable="targetEPR"/> </copy> <copy> 
<from
variable="targetEPR"
/> 
<to
partnerLink="targetPL"
/> Tim
Dörnemann </copy> Ernst Juhnke </assign> Bernd Freisleben 5
  • Peak
Load
Scenario‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ ‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel invoked
many
<mes
in
parallel Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ ‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel invoked
many
<mes
in
parallel ‣ leads
to
high
load
on
workflows
target
machines Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ ‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel invoked
many
<mes
in
parallel ‣ leads
to
high
load
on
workflows
target
machines ‣ increase
of
workflow
run<me
/
response
<me Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ ‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel invoked
many
<mes
in
parallel ‣ leads
to
high
load
on
workflows
target
machines ‣ increase
of
workflow
run<me
/
response
<me ‣ nega<ve
user
experience Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ ‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel invoked
many
<mes
in
parallel ‣ leads
to
high
load
on
workflows
target
machines ‣ increase
of
workflow
run<me
/
response
<me ‣ nega<ve
user
experience ‣ loss
of
stability Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ ‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel invoked
many
<mes
in
parallel ‣ leads
to
high
load
on
workflows
target
machines ‣ increase
of
workflow
run<me
/
response
<me ‣ nega<ve
user
experience ‣ loss
of
stability ‣ worst
case:
abandonment
of
workflow Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Peak
Load
Scenario‣ ‣ Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 Scenario:
sta<c/pre‐defined
target
hosts,
workflow
is
 invoked
many
<mes
in
parallel invoked
many
<mes
in
parallel ‣ leads
to
high
load
on
workflows
target
machines ‣ increase
of
workflow
run<me
/
response
<me ‣ nega<ve
user
experience ‣ loss
of
stability ‣ worst
case:
abandonment
of
workflow ‣ waste
of
CPU
hours
(lost
intermediate
results) Tim
Dörnemann Ernst Juhnke Bernd Freisleben 6
  • Outline Introduc<on
and
Mo<va<on Design Implementa<on Evalua<on Tim
Dörnemann Ernst Juhnke Bernd Freisleben 7
  • Desired
Behavior On-demand resources node node node node node Tim
Dörnemann Ernst Juhnke Bernd Freisleben 8
  • Desired
Behavior On-demand resources node node node node node Tim
Dörnemann Ernst Juhnke Bernd Freisleben 8
  • Desired
Behavior On-demand resources node node node node node Tim
Dörnemann Ernst Juhnke Bernd Freisleben 8
  • Desired
Behavior On-demand resources node node node node node Tim
Dörnemann Ernst Juhnke Bernd Freisleben 8
  • Desired
Behavior On-demand resources node node node node node Tim
Dörnemann Ernst Juhnke Bernd Freisleben 8
  • Cloud
Compu<ng‣ New
paradigm
for
distributed
compu<ng ‣ On‐demand
resource
provisioning
/
 Infrastructure
as
a
Service
(IaaS) ‣ (Illusion
of)
unlimited
resources
 ‣ Pay‐as‐you‐go
business
model Tim
Dörnemann Ernst Juhnke Bernd Freisleben 9
  • Cloud
Compu<ng‣ New
paradigm
for
distributed
compu<ng ‣ On‐demand
resource
provisioning
/
 Infrastructure
as
a
Service
(IaaS) ‣ (Illusion
of)
unlimited
resources
 ‣ Pay‐as‐you‐go
business
model‣ Implementa<ons
open
use
virtualiza<on ‣ Full
(root)
access
to
machines ‣ No
batch
system
(exclusive
use
of
resources) ‣ User
may
prepare
VM
image
with
required
 sopware ‣ Easy
reuse
&
deployment Tim
Dörnemann Ernst Juhnke Bernd Freisleben 9
  • Dynamic
BPEL
execu<on‣ Target
hosts
for
service
calls
are
determined
at
run<me
 instead
of
design
<me ‣ Scheduling
with
respect
to
load
of
target
hosts‣ Dynamic
resource
provisioning Tim
Dörnemann Ernst Juhnke Bernd Freisleben 10
  • Components Tim
Dörnemann Ernst Juhnke Bernd Freisleben 11
  • Components<partnerLink name="decoderPL"> <partnerRole endpointReference="dynamic" invokeHandler="java:LoadBalancer ?threshold=1.0;accessID=***;secretKey=***; imageID=ami-95cc28fc;availZone=us-east-1c"/> Tim
Dörnemann Ernst Juhnke Bernd Freisleben 11
  • 2$%3/4$) -$./0#%1Registry 56&&$4#6% !"#$%&()*++,) -$./0#%1‣ stores
informa<on
about
available
hosts
and
 their
services
‣ opera<ons
to
add,
update,
remove
machines‣ query
for
services
via
portType
QNames‣ UDDI
connector
to
integrate
external
service
 databases‣ implements
locking
mechanisms
to
prevent
on‐ demand
resources
from
shutdown
while
in
use‣ persistence
mechanism
 Tim
Dörnemann Ernst Juhnke Bernd Freisleben 12
  • Scheduler‣ uses
informa<on
about
infrastructure
to
make
 scheduling
decisions‣ invokes
Provisioner
when
no
suitable
machine
is
found‣ automa<c
deprovisioning
of
unused
machines ‣ stores
startup
<me
of
virtual
machine
and
their
accoun<ng
 model ‣ cost‐efficient
scheduling‣ scheduling
algorithms
are
pluggable‣ Prototype:
For
all
machines
with
threshold
<
t,
calculate
 cm = W IP Sm and
select
the
minimum max(loadm , 0.01) Tim
Dörnemann Ernst Juhnke Bernd Freisleben 13
  • Provisioner !"#$%&()*+,-)*+ !"#$%&%#("‣ provides
one
infrastructure‐independent
 interface
to
manage
startup,
shutdown
and
 configura<on
of
different
types
of
on‐demand
 resources ‣ configura<on:
firewall
rules,
sopware
installa<on
‣ automa<cally
(de‐)registers
machines
and
 their
services
within
registry Tim
Dörnemann Ernst Juhnke Bernd Freisleben 14
  • Outline Introduc<on
and
Mo<va<on Design Implementa<on Evalua<on Tim
Dörnemann Ernst Juhnke Bernd Freisleben 15
  • Implementa<on‣ No
changes
to
the
BPEL
standard
required‣ Makes
use
of
Ac<veBPEL‘s
extensibility
mechanisms
 (Interfaces
and
observers)‣ Prototype
uses
Typica‐Library
to
manage
EC2
instances
 (developed
by
Xerox) Tim
Dörnemann Ernst Juhnke Bernd Freisleben 16
  • Implementa<on‣ No
changes
to
the
BPEL
standard
required‣ Makes
use
of
Ac<veBPEL‘s
extensibility
mechanisms
 (Interfaces
and
observers)‣ Prototype
uses
Typica‐Library
to
manage
EC2
instances
 (developed
by
Xerox)‣ Features: ‣ On‐demand
provisioning
and
deprovisioning
of
virtual
 machines
(cost
efficient) ‣ Framework
supports
exchangeability
of
scheduling
 algorithms
and
provisioning
components Tim
Dörnemann Ernst Juhnke Bernd Freisleben 16
  • Implementa<on
cont‘d Tim
Dörnemann Ernst Juhnke Bernd Freisleben 17
  • Graphical
Defini<on
of
Sejngs Tim
Dörnemann Ernst Juhnke Bernd Freisleben 18
  • Outline Introduc<on
and
Mo<va<on Design Implementa<on Evalua<on Tim
Dörnemann Ernst Juhnke Bernd Freisleben 19
  • Usage
Example‣ Video
analysis
workflow
with
 na<ve
C/C++
code
libraries ‣ needs
to
be
recompiled
for
 every
machine
type‣ Easy
to
use
with
Cloud
 infrastructure ‣ compile
once,
embed
in
VM
 image‣ Prototypical
implementa<on
 for
Amazon
EC2 Tim
Dörnemann Ernst Juhnke Bernd Freisleben 20
  • Evalua<on‣ Small
instance:
Intel
Xeon
1.2
GHz
(1ECU),
160
GB
disk,
1.7
GB
RAM,
 network
250
MBit/sec,
$0.10/hour‣ High
CPU
instance:
as
above,
but
2
x
2.5ECU,
350
GB
disk,
$0.20/ hour Tim
Dörnemann Ernst Juhnke Bernd Freisleben 21
  • Evalua<on
contd Tim
Dörnemann Ernst Juhnke Bernd Freisleben 22
  • Evalua<on
contd‣ System
needs
between
60
and
90
seconds
to
scale
up‣ EC2
has
proven
to
be
very
reliable Tim
Dörnemann Ernst Juhnke Bernd Freisleben 22
  • Conclusions‣ Standard‐compliant
extension
of
BPEL
to
model
dynamic
 target
service
selec<on‣ Target
machines
are
chosen
with
respect
to
their
load‣ On‐demand
provisioning
of
resources
in
peak‐load
 situa<ons‣ Future
Work ‣ Fault‐tolerant
workflow
execu<on
(Cloud‐backed) ‣ Data
flow
op<miza<on
in
workflows ‣ Integrate
with
Eucalyptus Tim
Dörnemann Ernst Juhnke Bernd Freisleben 23
  • Tim
Dörnemann Ernst JuhnkeBernd Freisleben 24
  • Thank you for listening Any questions? Tim
Dörnemann Ernst Juhnke Bernd Freisleben 24