Adaptability:viewpoint from INRIA-Rennes
and the UNIPI-INRIA joint-work
CoreGrid WP3 Kraków meeting - June 2006Françoise André & Jérémy Buisson
Subtask 3.3Research group on “Performance models and adaptivity”
2
Outline
• Collaborative work UNIPI/INRIA– Leading to a common high-level model
• UNIPI’s interpretation: ASSIST
• INRIA’s interpretation: Dynaco/AFPAC
3
Dynamic adaptability
• Ability of applications to modify themselves at runtime in order to adapt to their dynamically changing context
• Many independent projects: ASSIST, Dynaco/AFPAC, GrADS , PCL, Safran, Plasma, AppLeS/AMWAT/APST, Active Harmony, …
4
Adaptability for grid computing
• Platform: availability evolves dynamically– Not only faults– But also activities of concurrent users– And planned maintenance
5
Adaptability for grid computing• Example of announced maintenance operations
– Table of planned events for the Grid5000 platform– Source: www.grid5000.fr, taken upon June the 7th
• Should applications ignore those warnings?
Notification Date of the event Site Description
07 jun 6:59 08 jun 8:00 → 08 jun 12:00 Rennes Maintenance, instable platform
05 jun 15:35 08 jun 9:00 → 08 jun 18:00 Orsay Air conditioning maybe off again, so maybe also our cluster ?!
23 may 10:46 08 jun 9:00 → 09 jun 18:00 Lille Cluster upgrade: cluster will be shutdown to install new nodes, management cards, console management
6
Adaptability for grid computing
• Applications– May experience long execution time
• Usually longer than the mean time between platform changes
– May have dynamic needs• E.g. data-driven behavior
Applications should adapt at runtime
7
Common schema
• Aims at providing a high-level abstract model– Unifies the approaches of UNIPI (ASSIST)
and INRIA-Rennes (Dynaco/AFPAC)– Applies to other approaches
• Helps developers in designing and implementing adaptability
8
Common schema
• Hierarchically splits the adaptation process in phases– Voluntarily under-specified– Two main phases at the higher level
• Decide whether the application should adapt
• Commit the decisions
9
Decide phase
• Decides whether the application should adapt– Filters the changes that occur in the platform
• Identify those that are significant enough• Discard the others
– Determines a strategy for adapting the application
• Two sub elements– Trigger: notification reception from the platform– Policy: specialization of the decide phase to the actual
application
10
Commit phase
• Applies a given strategy– Identifies the actions that should be performed– Executes those actions
• Two sub elements– Plan: creation of an implementation of the strategy– Execute: execution of the plan
• Split in turn into– Mechanisms: individual actions used to implement the strategy
– Timing: scheduling and synchronization with the execution of the application
11
Approach of UNIPI
• Compiler-based approach– Allows adaptability transparently to developers
• Adaptation points placed by the compiler• Some adaptation mechanisms automatically generated
– E.g. redistribution
• Implemented in the ASSIST development environment for grid computing– Parmod skeleton is intrinsically adaptable
• Changing the number of Virtual Processes Managers (VPM) executing the Virtual Processes (VP)
• Redistributing VPs over VPMs
– Parmod skeleton has a known performance model
12
ASSIST
• Runtime support– Reflects the common
abstract model
• Control loop– Receive feedback from the
trigger interface– Make decisions depending
on the parmod skeleton performance model
– Target only involved VPMs
13
Approach of INRIA-Rennes
• Framework-based– Allows adaptability for legacy applications– Allows developers to design their own adaptability– May provide a runtime support for compiler-based
approach/automatic adaptability generation
• Split in two parts– Dynaco: generic adaptability framework– AFPAC: SPMD adaptable components
14
Dynaco
• Defines an architecture for adaptability– Some key components
• Monitor; Decider; Planner; Executor
– Interactions and interfaces between those components
– Concerns implemented by each of those components
• Provides a reference implementation– Written in Java for the Julia implementation of Fractal
• Gives some hints for binding adaptability to components– Using Fractal’s controllers and AOP
15
Dynaco framework• Reflects the common abstract model• Contains four major components, which model the four major
phases and the four major concerns– Monitor the platform and resources– Decide whether the component should adapt– Plan how the component could be adapted– Execute the plan, which is composed of actions
16
AFPAC toolbox
• One Dynaco component that wraps an SPMD code– With one special action that triggers SPMD actions, i.e. one
action replicated in each process
• One executor local to each process– Coordinates together the execution of local actions
• Based upon developer-provided “adaptation points”
17
Connections to the GCM
• Could be used to make GCM components adaptable– ASSIST adaptable parmods can be
encapsulated into GCM components– Dynaco may allow to implement adaptability
for GCM components
18
Requirements from GCM
• Whatever the case, requires from GCM– Place-holder for adaptability
• In a customizable controller/membrane/container?
– Technology for integrating it• Aspect oriented programming?• Specialized structured programming paradigm?
19
Some web links
• Research group on “Performance models and adaptivity”: http://www.di.unipi.it/~marcod/WP3homepage/RG_adaptivity/index.html
• Assist website: http://www.di.unipi.it/Assist.html
• Dynaco website: http://dynaco.gforge.inria.fr/
• Adaptability within the PARIS team: http://www.irisa.fr/paris/web/adapt.html