Réplication de données pour la tolérance aux pannes dans un support d'exécution distribué à base de tâches
Auteur / Autrice : | Romain Lion |
Direction : | Samuel Thibault |
Type : | Thèse de doctorat |
Discipline(s) : | Informatique |
Date : | Soutenance le 13/12/2022 |
Etablissement(s) : | Bordeaux |
Ecole(s) doctorale(s) : | École doctorale Mathématiques et informatique (Talence, Gironde ; 1991-....) |
Partenaire(s) de recherche : | Laboratoire : Laboratoire bordelais de recherche en informatique |
Jury : | Président / Présidente : Luc Giraud |
Examinateurs / Examinatrices : Camille Coti, Amina Guermouche, Leonardo BAUTISTA GOMEZ, Pierre Lemarinier | |
Rapporteur / Rapporteuse : Franck Capello, Cédric Bastoule |
Mots clés
Résumé
À mesure que la puissance de calcul des nouveaux supercalculateurs augmente, leur fiabilitédécroît inexorablement. En effet les limites sont repoussées en augmentant le nombre de composantsainsi que leur complexité, et les systèmes de calcul expérimentent des défaillances au quotidien. Laproblématique est donc de pouvoir se prémunir des pannes, tout en limitant l’impact sur les performancesqu’impose un mécanisme de tolérance aux pannes. Par ailleurs, la complexité de l’architecture dessupercalculateurs rend plus difficile leur programmation, ce à quoi tentent de répondre les supportsd’exécution à base de tâches comme StarPU. Les travaux présentés ici proposent une solution detolérance aux pannes adaptée à StarPU. Le modèle de programmation STF utilisé dans StarPU nouspermet de créer des sauvegardes asynchrones qui n’interrompent pas le calcul, et qui ne nécessitentaucune synchronisation entre les noeuds de calcul ; ce comportement est atteint en insérant statiquementdes requêtes de sauvegarde dans le code d’application, correspondant à une solution de checkpoint deniveau application. Également, gérer des sauvegardes à travers StarPU permet de mettre en communles données de calcul et les données de sauvegarde, ce qui nous permet de réduire considérablement laquantité de données qui doivent effectivement être sauvegardées. Nous avons exploité cet effet en utilisantles autres noeuds de calcul comme support de sauvegarde, ainsi qu’un mécanisme de message loggingafin de redémarrer uniquement le noeud en panne. L’efficacité de cette solution a été évaluée avec uneapplication de décomposition de Cholesky, et nous avons pu voir dans un cas idéal que notre approchepermet de tolérer les pannes considérées sans qu’aucune sauvegarde ne soit effectuée en pratique.