Alors que les superordinateurs deviennent toujours plus puissants, ils sont également plus vulnérables aux défaillances, et cela à cause de l'augmentation du nombre de leurs composants. Lors de la récente conférence SC12 (http://sc12.supercomputing.org/) qui s'est tenue la semaine dernière à Salt Lake City, des chercheurs ont proposé des solutions pour remédier à ce problème qui risque s'amplifier.

Certains systèmes de calcul haute performance (HPC) actuels peuvent comporter jusqu'à 100 000 noeuds et plus, chaque noeud étant lui-même la somme de plusieurs composants mémoires, processeurs, bus et d'autres circuits. « Statistiquement parlant, tous ces composants sont susceptibles de tomber en panne à un moment ou un autre, et tous les calculs peuvent être interrompus si cela arrive », a déclaré David Fiala, étudiant en doctorat à l'Université de l'État de Caroline du Nord, présent à la conférence. Le problème n'est pas nouveau, bien sûr. Quand le superordinateur 600 noeuds ASCI (Accelerated Strategic Computing Initiative) White du Lawrence Livermore National Laboratory  a été mis en service en 2001, le temps moyen entre deux pannes (MTBF) dues à des défaillances de composants était de cinq heures seulement. « Par la suite, grâce à de meilleurs réglages, ce temps MTBF moyen est passé à 55 heures », a ajouté le chercheur.

Avec l'exascale les pannes vont aussi se multiplier

Mais, plus le nombre de noeuds augmente dans le supercalculateur, plus le problème grandit. « Nous devons faire quelque chose pour cela, car il ne fait pas de doute que le problème va s'aggraver quand nous passerons à l'exascale », a ajouté David Fiala. On pense que les superordinateurs de la prochaine décennie seront capables de délivrer 10 fois plus de puissance de calcul que les supercalculateurs actuels. « Les techniques disponibles pour faire face à une défaillance du système ne sont pas forcément bien adaptées », a ajouté le doctorant chercheur. Par exemple, le point de reprise du traitement, c'est à dire le moment où un programme en cours est temporairement arrêté et que son état est sauvegardé sur le disque. Si le programme se plante, le système est capable de relancer la tâche depuis le dernier point de reprise enregistré.

Selon David Fiala, « le problème avec les points de reprise, c'est que le temps système nécessaire pour effectuer le point de reprise augmente avec le nombre de noeuds et croît de façon exponentielle ». Par exemple, dans un supercalculateur de 100 000 noeuds, seuls 35 % de son activité environ est mobilisée pour les tâches. « Le reste est affecté aux points de reprise et, si un système tombe en panne, aux opérations de récupération », a estimé le doctorant. « Un système exascale a besoin d'un nombre beaucoup plus élevé de composants, un million et plus, si bien que la fiabilité du système devrait être améliorée d'un facteur 100 pour maintenir un MTBF équivalant à celui des superordinateurs actuels », a expliqué David Fiala.

Des copies travaillant en parallèle pour comparer les réponses

Ce dernier a présenté une technologie qu'il a développée avec d'autres collègues chercheurs, laquelle pourrait aider à améliorer la fiabilité. Celle-ci s'attaque au problème de la corruption invisible des données, à savoir que les systèmes commettent des erreurs d'écriture de données sur un disque sans qu'elles soient détectées. Fondamentalement, l'approche des chercheurs consiste à exécuter plusieurs copies, ou «clones» d'un programme, en même temps, et de comparer les réponses. Le logiciel, appelé RedMPI, tourne en même temps qu'une bibliothèque nommée Message Passing Interface (MPI), qui répartit l'exécution des applications sur plusieurs serveurs, ce qui revient à exécuter différentes portions du programme en parallèle.

RedMPI intercepte et copie chaque message MPI envoyé par une application et transmets une copie du message au clone (ou aux clones) du programme. Si les différents clones donnent des réponses différentes, les résultats peuvent être recalculés à la volée, ce qui permet de gagner du temps et des ressources, plutôt que de faire exécuter à nouveau la totalité du calcul. «Ça ne coûte pas cher d'implémenter la redondance. Le nombre d'accès processeurs est peut-être élevé, mais il évite la réécriture à partir du point de reprise », a déclaré le chercheur. «L'alternative c'est, évidemment, de relancer simplement la tâche jusqu'à ce que l'on estime avoir la bonne réponse ».

[[page]]

David Fiala recommande de faire tourner deux copies de sauvegarde de chaque programme, pour une triple redondance. Certes, en faisant tourner plusieurs copies d'un programme, on utilise davantage de ressources, mais dans le temps, cela peut s'avérer plus efficace, du fait que les programmes n'ont pas besoin d'être réexécutés pour vérifier les réponses. En outre, le point de reprise n'est peut-être pas nécessaire quand on exécute plusieurs copies, ce qui permettrait également d'économiser des ressources système. « De mon point de vue, l'idée de faire une redondance est excellente. Pour les calculs d'envergure, impliquant des centaines de milliers de noeuds, il y a certainement une chance que des erreurs apparaissent », a estimé pour sa part Ethan Miller, professeur d'informatique à l'Université de Santa Cruz, Californie, qui a assisté à la présentation. Mais selon lui, l'approche n'est peut-être pas adaptée, étant donnée la quantité de trafic réseau que pourrait générer une telle redondance. Celui-ci suggère de faire tourner toutes les applications sur le même ensemble de noeuds, de façon à réduire le trafic.

Analyse des logs pour prédire les défaillances

Dans une autre présentation, Ana Gainaru, une étudiante en doctorat à l'Université Urbana-Champaign, Illinois, a présenté une technique d'analyse des fichiers de log pour prédire les défaillances du système. L'idée ici est de combiner l'analyse du signal avec le data mining. L'analyse du signal est utilisée pour caractériser un comportement normal, donc, quand une panne survient, elle peut être facilement repérée. L'exploration des données cherche des corrélations entre les différentes défaillances. « D'autres chercheurs ont montré que des défaillances multiples sont parfois corrélées les unes avec les autres, parce que l'échec d'une technologie peut affecter la performance d'une autre technologie », a déclaré Ana Gainaru. Par exemple, si une carte réseau tombe en panne, elle va entraver d'autres processus système qui reposent sur la communication réseau.

Les chercheurs ont constaté que 70 % des pannes corrélées ouvrent une fenêtre d'opportunité de plus de 10 secondes. En d'autres termes, lorsque le premier signe de panne est détecté, le système peut avoir jusqu'à 10 secondes pour enregistrer son travail, ou déplacer la tâche vers un autre noeud, avant qu'une panne plus grave ne se produise. Selon Ana Gainaru, « la prédiction des pannes peut être associée à d'autres techniques de tolérance de panne ».