On Demand Resource Provisioning for BPEL Workflows Using Amazon's EC2, IEEE CCGrid 2009, Shanghai
•
0 gostou•695 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Último
Último (20)
Destaque
Destaque (20)
On Demand Resource Provisioning for BPEL Workflows Using Amazon's EC2, IEEE CCGrid 2009, Shanghai
- 1. On‐demand Resource Provisioning for BPEL Workflows Using Amazon's EC2 Tim Dörnemann, Ernst Juhnke, Bernd Freisleben Department of Mathema<cs and Computer Science, University of Marburg {doernemt, ejuhnke, freisleb}@informa<k.uni‐marburg.de
- 2. Outline Introduc<on and Mo<va<on Design Implementa<on Evalua<on Tim Dörnemann Ernst Juhnke Bernd Freisleben 2
- 3. 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
- 4. 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
- 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 Tim Dörnemann Ernst Juhnke Bernd Freisleben 5
- 6. 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
- 7. 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
- 8. 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
- 9. 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
- 10. 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
- 11. 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
- 12. 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
- 13. 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
- 14. 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
- 15. 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 workflow's target machines Tim Dörnemann Ernst Juhnke Bernd Freisleben 6
- 16. 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 workflow's target machines ‣ increase of workflow run<me / response <me Tim Dörnemann Ernst Juhnke Bernd Freisleben 6
- 17. 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 workflow's target machines ‣ increase of workflow run<me / response <me ‣ nega<ve user experience Tim Dörnemann Ernst Juhnke Bernd Freisleben 6
- 18. 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 workflow's target machines ‣ increase of workflow run<me / response <me ‣ nega<ve user experience ‣ loss of stability Tim Dörnemann Ernst Juhnke Bernd Freisleben 6
- 19. 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 workflow's 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
- 20. 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 workflow's 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
- 21. Outline Introduc<on and Mo<va<on Design Implementa<on Evalua<on Tim Dörnemann Ernst Juhnke Bernd Freisleben 7
- 22. Desired Behavior On-demand resources node node node node node Tim Dörnemann Ernst Juhnke Bernd Freisleben 8
- 23. Desired Behavior On-demand resources node node node node node Tim Dörnemann Ernst Juhnke Bernd Freisleben 8
- 24. Desired Behavior On-demand resources node node node node node Tim Dörnemann Ernst Juhnke Bernd Freisleben 8
- 25. Desired Behavior On-demand resources node node node node node Tim Dörnemann Ernst Juhnke Bernd Freisleben 8
- 26. Desired Behavior On-demand resources node node node node node Tim Dörnemann Ernst Juhnke Bernd Freisleben 8
- 27. 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
- 28. 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
- 29. 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
- 30. Components Tim Dörnemann Ernst Juhnke Bernd Freisleben 11
- 31. 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
- 32. 2$%3/4$) -$./0#%1 Registry 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
- 33. 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
- 34. 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
- 35. Outline Introduc<on and Mo<va<on Design Implementa<on Evalua<on Tim Dörnemann Ernst Juhnke Bernd Freisleben 15
- 36. 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
- 37. 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
- 38. Implementa<on cont‘d Tim Dörnemann Ernst Juhnke Bernd Freisleben 17
- 39. Graphical Defini<on of Sejngs Tim Dörnemann Ernst Juhnke Bernd Freisleben 18
- 40. Outline Introduc<on and Mo<va<on Design Implementa<on Evalua<on Tim Dörnemann Ernst Juhnke Bernd Freisleben 19
- 41. 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
- 42. 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
- 43. Evalua<on cont'd Tim Dörnemann Ernst Juhnke Bernd Freisleben 22
- 44. Evalua<on cont'd ‣ 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
- 45. 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
- 46. Tim Dörnemann Ernst Juhnke Bernd Freisleben 24
- 47. Thank you for listening Any questions? Tim Dörnemann Ernst Juhnke Bernd Freisleben 24
Notas do Editor
- \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&#xF6;ffentlichung des Dienstes als &#x201E;Public Service&#x201C; (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 &#xFC;bersch&#xFC;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