Automatic Load Balancing of ProActive Applications... with Fault Tolerance Javier Bustos, José Piquer, Universidad de Chile, Santiago, Chile Sebastien Boukhalfa, University Nice Sophia Antipolis Wednesday November th, 2006

Active Objects Migration migrateTo(…)

Dynamic Load Balancing 2 mechanisms working in parallel: Sender initiated: a quick reaction against overloading Receiver initiated: clustering active objects on the best machines

Sender Initiated

Receiver Initiated

Fault Tolerance Periodic record of active object states and incomming request (from the request queue) = checkpointing Using FT servers to store the information.

Union of ¿disjoint? schemes DYNAMIC LOAD BALANCING FAULT TOLERANCE FORWARDER

What is a forwarder? migrateTo(…) forwarder Active Object is not here anymore, it’s there 

… a forwarder Is not stored on Fault Tolerance servers because it is stateless (is not a part of the application, is part of the infrastructure) Has limited time to live Is created after each migration

Forwarder problem If the new location machine fails, how to update the forwarder? What if the last checkpoint is from the last location? If the forwarder machine fails, how to update the active object references? forwarder

… a forwarder Is not stored on Fault Tolerance servers because it is stateless (is not a part of the application, is part of the infrastructure) Has limited time to live Is created after each migration Update the references … but we have a FTServer which can do that!

Solution… Store the location of active objects on the FT Server, updating the location after each migration Using a hybrid scheme: forwarders and migration server (the FT server) “in case of an inconsistent reference, please consult the FT Server”

Conclusions and Future Work Dynamic load balancing and fault tolerance can live together Forwarder problem solved using the FT infrastructure of ProActive Future Work: Using the Dynamic Load Balancing infrastructure to find a suitable location after a fault.