MPICH-V : MPI tolérant aux fautes

MPI, dans sa spécication [75] et dans ses implantations les plus déployées (i.e MPICH

[35]) suit la sémantique fail stop (les specications et implantations ne fournissent pas de

mécanismes pour la détection de fautes et la reprise après apparition de fautes). Ainsi,

les applications MPI exécutées sur un cluster de grande échelle peuvent être stoppées à

tout instant pendant leur exécution à cause d'une défaillance du système.

Le besoin d'implantation de MPI tolérant aux fautes a récemment réactivé la recherche

dans ce domaine. Plusieurs projets de recherche explore la tolérance aux fautes à diérents

niveaux : réseau [67], système [11], applicatif [30]. Diérentes stratégies ont été proposées

pour implanter la tolérance aux fautes dans MPI : a) détection et gestion par

l'utilisa-teur/programmeur, b) pseudo-automatique guidée par le programmeur et c)

complète-ment automatique et transparente. Pour cette dernière catégorie, plusieurs protocoles

ont été étudiés dans la litérature. En conséquence, pour l'utilisateur et l'administrateur

fautes, mais aussi sur plusieurs protocoles de tolérance aux fautes pour chacun des types

d'approche.

Choisir le meilleur protocole de tolérance aux fautes dépend grandement du nombre

de composants, du schéma de communication pour l'application parallèle et du

comporte-ment du système en présence de fautes. Dans ces travaux, nous avons mis sous tension

l'implantation du protocole de Chandy-Lamport du projet MPICH-V [38] avec un taux

de fautes très important pour pouvoir dénir son niveau de tolérance aux fautes.

L'algorithme de Chandy-Lamport [21] propose d'implanter la tolérance aux fautes à

travers un mécanisme de reprise à partir d'un snapshot cohérent. Pendant l'exécution,

les composants peuvent déclencher des vagues de checkpoint, qui construisent une vue

co-hérente de l'application distribuée. Chaque processus enregistre son image sur un média

able lors de la prise d'une vue cohérente. Quand un processus est sujet à une

défail-lance, l'application distribuée est interrompue, des ressources de calcul sont allouées pour

remplacer les processus défaillants et tous les processus rollback (i.e tous les processus

chargent leur dernier checkpoint qui est la partie d'une vue complète cohérente). Comme

une vue construit une conguration distribuée possible de l'application, l'exécution de

l'application peut continuer à partir de ce point comme si aucune défaillance ne s'était

produite.

Le projet MPICH-V [38] a pour but de comparer les performances de diérents

pro-tocoles de tolérance aux fautes dans l'implantation de MPI : MPICH-1 [35]. Un des

protocoles implanté est l'algorithme de Chandy-Lamport non bloquant optimisé. Il

ex-iste deux implantations possibles de l'algorithme de Chandy-Lamport : bloquante ou

non bloquante. L'implantation bloquante utilise des marqueurs pour purger les canaux

de communication et stopper les communications pendant une vague de checkpoint. Au

contraire, l'implantation non bloquante laisse l'application continuer ses communications

pendant une vague de checkpoint et enregistre les messages émis dans l'image de

check-point. Nous allons, par la suite, décrire plus précisément le protocole et son implantation,

mais il faut noter qu'un processus MPI est implanté par deux composants séparés pour

permettre l'enregistrement des messsages en transit. Ces deux composants sont exécutés

dans des processus unix séparés : un processus de calcul (MPI) et un processus de

com-munication (daemon). Le processus de comcom-munication est utilisé pour enregistrer les

messages en transit et pour rejouer ces messages quand un relancement du processus est

exécuté.

Fig. 7.16 Exécution d'une application MPI sur MPICH-Vcl avec une faute

reçoit initialement le marqueur du checkpoint scheduler (1), enregistre son état local (2)

et envoie un marqueur à tous les autres processus (2). A partir de cet instant, tous les

messages (représentés par un mdans la gure) reçus après le checkpoint local mais avant

d'avoir reçu le marker de leur expéditeur, sont enregistrés par le processus daemon. Quand

le processus MPI 0 reçoit le marqueur, il commence son checkpoint local et envoie un

marqueur à tous les autres processus (3). La réception de ce marqueur par le processus

1 marque la complétion de son checkpoint local. Si une défaillance se produit, tous les

processus sont relancés à partir de leur checkpoint le plus récent (4) et le processus

daemon rejoue l'envoie des messages enregistrés (5). On peut noter que le message m

′

peut ne pas être réenvoyé dans la nouvelle exécution.

MPICH implante une bibliothèque complète MPI à partir d'un canal. Un tel canal

implante les routines de communication de base pour un matériel specique ou pour

un nouveau protocole de communication. MPICH-V est un framework générique pour

comparer diérents protocoles de tolérance aux fautes pour des applications MPI. Ce

framework implante un canal pour la bibliothèque MPICH 1.2.7, basé sur le canal par

défaut ch_p4.

MPICH-V est composé d'un ensemble de composants et d'un canal appelé ch_v. Ce

canal s'appuie sur une séparation entre l'application MPI et le système de

communica-tion eectif. Les démons de communicacommunica-tion (Vdaemon) fournissent toutes les routines de

communication entre les diérents composants de MPICH-V. La tolérance aux fautes est

assurée en implantant des hooks dans les routines de communication. Cet ensemble de

Fig. 7.17 Architecture de MPICH-V

hooks est appelé un V-protocol. Le V-protocol nous intéressant est Vcl, qui est une

implantation non bloquante de l'algorithme de Chandy-Lamport.

Daemon Un démon gère les communications entre les noeuds (i.e envoi, réception,

réordonnancement de messages et établissement des connexions). Il ouvre une socket

TCP par processus MPI et une socket par type de serveur (le dispatcher et un serveur

de checkpoint pour l'implantation Vcl). Il est implanté en tant que processus

mono-thread qui multiplexe les communications à travers des appels à select. Pour limiter le

nombre d'appels systèmes, toutes les communications sont empaquetées en utilisant des

techniques iovec. La communication avec le processus MPI local est faite en utilisant des

envois bloquants et des réceptions sur une socket Unix.

Dispatcher Le dispatcher est responsable du lancement de l'application MPI. Il lance

les diérents processus et les serveurs en premier, ensuite les processus MPI, en utilisant

ssh pour lancer les processus distants. Le dispatcher est aussi responsable de la détection

de défaillances et du relancement des noeuds. Une défaillance est supposée s'être produite

après toute fermeture de socket non prévue.

La détection de défaillances s'appuie sur le paramètre TCP keep-live du système

d'exploitation. Les congurations Linux typiques dénissent la détection d'une défaillance

après 9 pertes consécutives de sondes keep-alive, où les sondes keep-alive sont prévues

toutes les 75 secondes. Ces paramètres peuvent être changés pour fournir plus de réactivité

lorsque des défaillances du système se produisent. Dans les expériences, les fautes sont

émulées en interrompant une tâche, et non pas le système d'exploitation, ce qui implique

que la détection de défaillances est déclenchée par la fermeture d'une connexion, qui est

eectuée dès que la tâche est interrompue par le système d'exploitation.

Serveur de checkpoint et mécanisme de checkpoint Les deux implantations

utilisent le même mécanisme abstrait de checkpointing. Ce mécanisme fournit une API

uniée pour adresser trois biliothèques de checkpointing de tâches système : Condor

Stan-dalone Checkpointing Library [53], libckpt [86] et the Berkeley Linux Checkpoint/Restart

[47, 67]. Toutes ces bibliothèques peuvent donc être utilisées pour la prise d'une image

d'un processus unix, son enregistrement sur un disque et le relancement de ce processus

sur une même architecture. Par défault, BLCR, qui est la bibliothèque la plus à jour, est

utilisée.

Les serveurs de checkpoint sont responsables de la collecte des checkpoints locaux de

tous les processus MPI. Quand un processus MPI démarre un checkpoint, il duplique

la bibliothèque de checkpoint pour créer le chier de checkpoint pendant que le

proces-sus MPI initial peut continuer son exécution. Le démon associé avec le procesproces-sus MPI

se connecte au serveur de checkpoint et lui transmet, à travers un algorithme

produc-teur/consommateur, le chier de checkpoint généré par le processus ls. Quand le chier

de checkpoint a été complètement envoyé, le ls du processus MPI se termine et le démon

envoie alors tous les messages, devant être enregistrés suivant l'algorithme de Chandy

Lamport, qui ont été temporairement stockés sur une memoire volatile du démon. En

utilisant cette technique, le calcul global n'est jamais interrompu pendant une phase de

checkpoint.

Quand un checkpoint global est complété, il n'est pas nécessaire de maintenir le

stock-age des anciens checkpoints globaux. Ainsi, les serveurs de checkpoint ne stockent

seule-ment qu'un checkpoint global complet à la fois, stockant alors au plus deux images de

checkpoint par noeud de calcul.

Si une défaillance intervient, tous les processus MPI se relancent à partir du checkpoint

local stocker sur le disque s'il existe, sinon ils l'obtiennent grâce au serveur de checkpoint.

Ordonnanceur de Checkpoint L'ordonnanceur de checkpoint gère les diérentes

vagues de checkpoint. Il envoie regulièrement des marqueurs à tous les processus MPI.

La fréquence des checkpoints est un paramètre déni par l'utilisateur. Il attend alors un

accusé de réception de n de checkpoint de tous les processus MPI avant de conrmer

la n du checkpoint global aux serveurs de checkpoint. L'ordonnanceur de checkpoint

commence une nouvelle vague de checkpoint seulement après la n de la précédente.

Dans le document INJECTION DE FAUTES DANS LES SYSTEMES DISTRIBUES (Page 127-132)