Prédiction des performances des opérations de sauvegarde/reprise sur cluster virtuel

RenPar 18 / SympA 2008 / CFSE 6 Fribourg, Suisse, du 11 au 13 février 2008 Prédiction des performances des opérations de sauvegarde/reprise sur cluster virtuel Yenké Blaise Omer Laboratoire LIG (équipe MESCAL), Grenoble, France ; Université de Yaoundé I, Cameroun blaise-omer.yenke@imag.fr Résumé Nous nous proposons d utiliser les ressources disponibles d un intranet d une entreprise durant les périodes d inactivité des PC (nuits, week-ends, congés). L idée est de constituer un cluster virtuel avec les postes libres de l intranet pour faire du calcul scientifique. De tels objectifs étaient la préoccupation du projet IGGI 2, et restent d actualité. Les différentes plages ainsi disponibles ne permettent pas toujours d exécuter les applications jusqu à leurs termes. Dans ce cas, les mécanismes de sauvegarde/reprise (checkpointing) permettent d exploiter efficacement ce type d infrastructure et assurent la continuité des calculs. Cependant, la sauvegarde du contexte d exécution d une application a un coût en temps et en espace disque. Ces contraintes sont encore plus fortes lorsque plusieurs applications sont en concurrence pour les accès réseau et disque. Dans cet article, nous présentons un modèle qui permet de prédire les performances du checkpointing en tenant compte des contraintes de congestion au niveau du réseau et du disque de sauvegarde. Nous illustrons l utilité du modèle dans la prédiction de la durée de sauvegarde du contexte de plusieurs applications séquentielles indépendantes. Pour notre modélisation, nous utilisons le système de checkpointing BLCR (Berkeley Linux Checkpointing Restart). Mots-clés : prédiction ; performance ; checkpointing ; BLCR 1. Introduction Les entreprises, les instituts, les universités, etc. disposent aujourd hui d intranets dotés de serveurs et d un grand nombre de postes de travail. Dans certaines de ces organisations, les postes de travail sont très peu utilisés la nuit, les week-ends et pendant les périodes de congés, libérant une grande puissance de calcul. Il serait donc judicieux d exploiter les longues périodes d inactivité des postes de travail par des applications nécessitant la ressource de calcul. L idée est donc de constituer des clusters virtuels à partir des postes non utilisés pour exploiter à bon escient les temps de jachère. Un cluster virtuel est une infrastructure de calcul constituée de ressources réparties sur un intranet de façon dynamique. Dans notre contexte, les postes de travail retenus pour le cluster virtuel, principalement sous le système Windows, seront rebootés sous Linux avec un outil tel que ComputeMode [1] et managés par un gestionnaire de ressources comme OAR [2], tout comme l avait envisagé le projet IGGI [5]. Sur ces postes, seules les ressources comme le CPU et la RAM seront utilisées. On considère que la sauvegarde des contextes d exécution des applications s exécutant sur ces postes se fait sur le disque du serveur. Cette dernière considération permet d éviter de sauvegarder localement car le poste pourrait ne plus être disponible le lendemain. Sur des infrastructures de type cluster virtuel, la volatilité des ressources est une des propriétés à prendre en compte. Les postes de travail doivent par exemple être restitués le matin au retour des employés. Il y a donc nécessité d assurer la sauvegarde d un calcul inachevé en vue d une éventuelle reprise. Dans ce cas les mécanismes de checkpointing sont une bonne solution. De nombreux travaux ont été menés sur les techniques de sauvegarde/reprise, ainsi notre objectif n est pas d en développer de nouvelles. En effet nous utilisons les fonctionnalités des systèmes de checkpointing existants pour gérer une panne de façon prévisible (arrêt voulu des machines). Une question à Financé par une bourse du Service de Coopération et d Action Culturelle, Ambassade de France au Cameroun 2 Projet RNTL démarré en 2004 et terminé en janvier 2007

laquelle nous essayerons d apporter une réponse est la suivante : A quel moment lancer le processus de sauvegarde des applications inachevées afin que les postes de travail soient disponibles avant 8h par exemple? Nous étudions donc dans cet article les insuffisances du dispositif de sauvegarde afin de pouvoir prédire dynamiquement le temps de sauvegarde du système. La suite de cet article est organisée comme suit. La section 2 décrit quelques mécanismes du checkpointing. Nous présentons à la section 3 quelques expériences qui ont été menées et qui ont conduit à l élaboration du modèle que nous présentons à la section 4. Nous évaluons le modèle à la section 5 et nous concluons en donnant quelques axes pour la suite de ce travail. 2. État de l art Les principaux intérêts du checkpointing dans les environnements de cluster sont la tolérance aux fautes, la préemption, la migration de processus. La tolérance aux fautes des applications est réalisée au moyen de points de reprise périodiques. Cette caractéristique est essentiellement importante pour les applications longues (plusieurs heures voir plusieurs jours d exécution). Dans ces longues périodes d exécution, la probabilité de l occurrence d une panne au niveau matériel, réseau, système d exploitation, ou des applications même, peu être très grande. La sauvegarde régulière des points de reprise vers un support stable est alors une nécessité. La préemption est la procédure qui consiste à stopper temporairement un processus dans le but d allouer les ressources à un autre. La préemption est nécessaire pour implémenter les fonctionnalités principales d un ordonnanceur (priorité, réservation, etc.). La migration de processus est la procédure qui consiste à déplacer un job d un noeud à un autre. Elle est spécialement utile dans le cas de la préemption. Plusieurs travaux de recherche [8, 9, 10, 13] ont contribué à améliorer les performances du checkpointing, en mettant l accent sur la totalité ou une partie des caractéristiques comme la disponibilité, la fiabilité et la maintenabilité des systèmes distribués. Toutefois, la plupart des travaux modélisant le checkpointing considèrent des sauvegardes à intervalles réguliers, sans trop se préoccuper des charges réseau et disque. 2.1. Mécanismes du checkpointing Le checkpointing est la procédure qui consiste à sauvegarder le contexte d exécution d un processus actif dans un fichier sur un support stable. Le fichier ainsi sauvegardé contient toutes les informations nécessaires à la reconstruction du processus à partir de ce point de sauvegarde. Un grand nombre de systèmes de checkpointing libres existent aujourd hui, mais aucun n est encore capable de sauvegarder le contexte de tout type d application. On dénote trois types d implémentation du checkpointing : Checkpointing de niveau système : C est l approche la plus transparente. Dans ce cas, le checkpointing est réalisé au niveau du noyau. L utilisateur n a pas besoin de recompiler son application ou d en rétablir l édition des liens. Cependant cette approche est la moins efficace car le système n a aucune connaissance de la structure de l application. Il fait tout simplement un dump sur la mémoire du processus et l enregistre dans le fichier de checkpoint. Les systèmes émergeant dans ce courant sont CRAK [18], BLCR [4], Cryopid [3]. Checkpointing de niveau bibliothèque : Dans cette approche, l utilisateur doit rétablir l édition des liens avec la bibliothèque pour préparer son code à la sauvegarde. Le checkpointing est réalisé par un envoi de signal à l application. L inconvénient dans cette approche est la recompilation de l application. Dans ce courant, on retrouve plusieurs implémentations comme Libckpt [12], Condor [9]. Checkpointing de niveau application : Réalisé par le programmeur lui-même. Le programmeur implémente des procédures pour effectuer les opérations de sauvegarde/reprise. Cette approche semble être la plus efficace car le programmeur peut décider de sauvegarder juste une partie des données de l application. Cependant elle est la moins transparente et requiert un grand effort de la part du programmeur. 2.2. Performance du checkpointing J. S. Plank et M. G. Thomason [13] ont proposé un modèle dans lequel la disponibilité moyenne A du système est ( une mesure de performance du checkpointing. Ce paramètre donné par la formule mathématique A = ) Ce (I λi e λi ) 1 e λi λe λ(r+l) est maximisé par la détermination d un intervalle I optimal entre deux sauvegardes. I est la fréquence de checkpointing qui minimise les pertes de temps pour

une application qui s exécute en présence de pannes. λ est le nombre moyen d apparition des pannes. C est le temps de continuation de l application pendant que la sauvegarde du contexte est en cours. Dans ce modèle, les temps de sauvegarde L et de reprise R sont supposés constants ; ce qui ne cadre pas avec la réalité. En fait leur modèle ne tient pas compte de l espace mémoire occupé par l application, lequel influence considérablement le temps de sauvegarde. E. Imamagic et al. [8] ont proposé une approche pour optimiser les performances du checkpointing en minimisant les temps de sauvegarde des points de reprise et la charge du réseau. Ils considèrent deux intervalles de temps. La plus courte période correspond au temps d exécution entre deux points de reprise qui doivent être sauvegardés localement. La plus longue correspond au temps d exécution entre deux points de reprise qui doivent être sauvegardés sur un support distant. L approche de sauvegarde locale permet ainsi de minimiser la charge du réseau et d accroître la vitesse des sauvegardes. Cette approche est certes efficace, mais elle n est indiquée que pour des clusters dédiés. De plus leur modèle ne prend pas en compte les conflits qui peuvent se présenter pour les accès concurrents au réseau. Dans notre cas, nous étudions la modélisation des performances du checkpointing en tenant compte des contraintes réseau et disque pour minimiser les pertes de temps de sauvegarde, et gagner en temps de calcul. Pour ce faire nous avons mené une série d expériences qui nous ont conduit au modèle présenté par la suite. 3. Experimentations Les expériences menées dans [6] montrent que le temps de sauvegarde est en général influencé par le rapport entre la mémoire virtuelle du processus et la taille de la mémoire RAM, l écriture en local ou à distance. Nous présentons ici quelques unes des expériences que nous avons effectué pour étudier les performances du dispositif de sauvegarde. Pour faire des mesures réalistes, nous considérons que les applications résident complètement en mémoire physique. Plate-forme expérimentale Nos expériences ont été menées sur l infrastructure Grid5000 3 dans laquelle le gestionnaire de travaux OAR gère les ressources de la grille. Une image a été déployée sur les noeuds réservés, l un des noeuds faisant office de serveur NFS (Network File System). Bien que des extensions de NFS comme ClusterNFS [16] sont en cours d étude pour optimiser ses performances au niveau des opérations de lecture/écriture, le standard NFS demeure largement utilisé dans les environnements de cluster. Les tests ont été menés sur le cluster de Sophia dont les noeuds sont des bi-processeurs AMD Opteron 2GHz, 2Go de RAM, disque dur 80 Go (IDE-amd74xx) dont les débits en moyenne sont 50 Mo/s. Les noeuds sont reliés par un réseau Ethernet gigabit, et partagent le /home (monté en synchrone) du serveur. Codes utilisés Code de calcul multigrilles : développé au sein du laboratoire ID-IMAG 4 pour la résolution des équations aux dérivées partielles. C est une application dont la taille mémoire physique croît considérablement lorsque l on fait accroître le nombre de points sur les grilles. Bench1 : Application synthétique dont toutes les pages de la mémoire physique sont sauvegardées. Système de checkpointing utilisé : BLCR BLCR est un mécanisme de checkpointing de niveau système. Il est basé sur la création d un fichier de point de reprise. Nous avons porté notre intérêt sur BLCR car il permet d établir des points de reprise tant pour les applications séquentielles que parallèles (multithreads). Il peut être couplé à LAM/MPI [15] pour le checkpointing des applications parallèles. Méthodologie Nous avons exécuté en parallèles des applications séquentielles identiques indépendantes sur n noeuds (de 1 à 30), en faisant varier la taille des applications. Au cours de l exécution, un script génère des fichiers de trace comportant le temps et la taille des points de reprise. Les mesures ont été considérées en analysant leur validité statistique (moyenne, écart-type).la moyenne a été le facteur clé. 3.1. Fichier de point de reprise généré par BLCR De nombreux tests effectués avec BLCR nous ont amené à nous intéresser au fichier de point de reprise généré par BLCR. C est un fichier binaire dont la structure ne se trouve pas dans la littérature. Aussi 3 http ://www.grid5000.fr/ 4 devenu LIG (Laboratoire d Informatique de Grenoble)

avons-nous modifié BLCR, principalement le module vmadump, uniquement pour tracer l écriture dans le fichier de de point de reprise. Ceci nous a permis de constater que BLCR écrit essentiellement et alternativement des blocs de taille la longueur des entêtes des pages mémoires et la taille de ces pages (resp. 4octects et 4Ko pour notre Système d Exploitation), pour les pages de la mémoire mappée du processus qui ont été modifiées au moins une fois. Nous avons émulé BLCR par un programme qui écrit des blocs dans un fichier comme le fait BLCR. Les figures 1 et 2 montrent les résultats obtenus pour une sauvegarde en local et à distance. Dans les deux cas, l écart entre les temps de sauvegarde avec BLCR et par émulation est de l ordre du centième de seconde. Ceci montre que le surcoût pris par BLCR pour traiter les pages est négligeable. Ce test nous a conduit à considérer la mémoire physique du processus comme un paramètre pour notre modélisation. FIG. 1 Temps de sauvegarde du code de FIG. 2 Temps de sauvegarde du code de calcul multigrilles avec BLCR et par émulation de BLCR, en local lation de BLCR, à calcul multigrilles avec BLCR et par ému- distance 3.2. Evolution de la bande passante La figure 3 montre l évolution de la bande passante utilisée en fonction du nombre de nœuds pour différentes tailles du code de calcul multigrilles. On constate que toutes ces courbes ont des allures paraboliques et présentent des pics. La concavité de ces courbes montre qu avant le pic, le réseau n est pas surchargé et que le disque tient la charge. Après les pics, la diminution de la bande passante utilisée indique des pertes de performance du dispositif de sauvegarde. Ceci peut être dû à la latence au niveau du disque et au système de fichier NFS qui perd en performance lorsque le nombre de clients croît. FIG. 3 Bande passante utilisée en fonction du nombre de nœuds selon la taille des applications Les expériences que nous avons menées nous ont permis de constater que la sauvegarde du contexte d une application est fortement influencée par la taille de la mémoire allouée à cette application. De plus, lors du checkpointing de plusieurs applications séquentielles indépendantes se partageant le réseau et le disque de sauvegarde, la courbe donnant la bande passante utilisée croît et décroît, en fonction du nombre de processus et de leur taille agrégée. Lorsque cette courbe décroît, cela traduit des pertes de performances, mais on ne saurait dire si cela est dû au réseau ou au support de sauvegarde. Cela nous a conduit à adopter la modélisation présentée à la section suivante.

4. Modélisation On considère p applications séquentielles indépendantes en cours d exécution dans un intranet, une application par nœud. On voudrait les sauvegarder avant un délai. Les sauvegardes doivent se faire sur le disque du serveur. A quel moment donc lancer les sauvegardes? Compte tenu des contraintes précédemment mentionnées, on sait qu on ne peut pas les sauvegarder toutes à la fois. La solution est donc de déterminer dans un premier temps le nombre n < p de processus que l on peut sauvegarder simultanément de tel sorte que le réseau et le disque tiennent la charge (on confondra nœud et application sans nuire à la généralité). Ensuite ordonnancer les sauvegardes pour prédire le temps de sauvegarde du système. Pour ce faire, on suppose que les applications sont suffisamment longues, qu elles résident entièrement en mémoire physique et que leurs tailles ne varient plus (du moins de plus d un Mo, ce qui pourrait encore être considéré comme erreur de mesure) dès le début de la prédiction. 4.1. Approche NFS effectue habituellement des lectures/écritures de blocks de taille 8Ko. Or nous avons montré à la section 3.1 que certains blocks écrits par BLCR sont de taille très inférieure à 8Ko. Lors de la sauvegarde il est donc difficile de savoir si les blocs sont immédiatement écrits sur disque ou s ils sont d abord mis en cache par NFS. De plus NFS perd en performance [11, 17] avec la croissance du nombre de clients. Compte tenu de ces contraintes, il est très difficile de déterminer séparément l impact du réseau, des bus et du disque sur les performances du checkpointing. Nous avons donc procédé par une analyse de l évolution de la bande passante utilisée. Compte tenu de l allure parabolique des courbes de la figure 3 donnant les débits en fonction du nombre de nœuds pour chaque taille considérée, nous avons approximé de façon satisfaisante chaque bande passante par une fonction polynomiale de la forme g(n) = αn 2 + βn + γ (1) En regroupant les mesures dans le tableau de la figure 4, on constate que plus les tailles des applications sont petites, plus le nombre maximal de processus que l on peut sauvegarder simultanément est grand, ainsi que la bande passante utilisée, pendant que la taille agrégée reste la plus petite. FIG. 4 Récapitulatif des mesures effectuées pour les bandes passantes maximales FIG. 5 Bande passante utilisée en fonction de la taille agrégée pour les nombres de nœuds sur les pics Au vu de la concavité de la courbe de la figure 5, nous avons donc approximé la fonction donnant la bande passante utilisée en fonction de la taille agrégée, par une fonction polynomiale de la forme h(t) = λt 2 + ν (2) le coefficient du monôme de premier degré en T s étant avéré quasiment nul. 4.2. Le modèle Ainsi, pour une taille t fixée, la bande passante utilisée peut s écrire comme une fonction du nombre de nœuds n (équation (1)). De même pour n fixé, la bande passante utilisée peut s exprimer comme une fonction de la taille agrégée des applications (équation (2)). De ce qui précède, nous déduisons une modélisation de la bande passante en fonction du nombre de nœuds n et de la taille agrégée T des applications par une approximation polynomiale : ϕ(n, T) = an 2 T 2 + bn 2 + ct 2 + dn + e

où les coefficients a, b, c, d, e sont déterminés par la méthode des moindres carrés comme suit : Soit l expression y = ϕ(n, T) de la bande passante utilisée, soit à minimiser la fonction ψ(a, b, c, d, e) = r s i ( yij an 2 ijtj 2 bn 2 ij ctj 2 dn ij e ) 2 i=1 j=1 où r est le nombre de tailles utilisées s i le nombre de mesures dans la taille t i n ij le nombre de noeuds dans la taille t i à chaque mesure j y ij les bandes passantes utilisées mesurées T i la taille agrégée obtenue à partir du pic de la courbe donnant la bande passante utilisée pour les applications de taille t i. Les coefficients a, b, c, d, e sont donc obtenus en résolvant les équations aux dérivées partielles : ψ = 0, ω {a, b, c, d, e} ω La fonction ϕ(n, T) donnant la bande passante utilisée est dès lors entièrement déterminée. Compte tenu de sa concavité, le nombre de nœuds n optimal qui rend ϕ(n, T) maximal est tel que : soit V k la taille agrégée des k applications considérées, n < n optimal, ϕ(n, V n ) < ϕ(n optimal, V noptimal ) n > n optimal, ϕ(n, V n ) < ϕ(n optimal, V noptimal ) L algorithme de calcul de n optimal repose sur ces deux propriétés. Une fois n optimal déterminé, on peut partager la bande passante entre les nœuds. Le temps estimé pour la sauvegarde d une application de taille t i, est alors t i / [ ϕ(n optimal, V noptimal )/n optimal ] On peut maintenant ordonnancer les sauvegardes. L algorithme de prédiction du temps global de sauvegarde du contexte des applications est basé sur le principe du list scheduling [7]. Ici les tâches sont les sauvegardes à effectuer. Le schéma général de l algorithme est le suivant : Trier la liste des p applications suivant les tailles décroissantes Calculer la bande passante par nœud pour les premières applications Lancer la sauvegarde des premières applications tantque cardinal {Applications_sauvegardées} < p faire si fin d une sauvegarde ou d un groupe de sauvegardes alors Noter les temps de complétion si cardinal {{Sauvegarde_en_cours} {Applications_non_encore_sauvegardées}} < n optimal alors Recalculer la bande passante fin si Lancer autant de nouvelles sauvegardes (s il en reste encore) que d achevées fin si fin tantque temps_estimé = max{temps_de_complétion} FIG. 6 Schéma de l algorithme de prédiction du temps de sauvegarde de p applications séquentielles Connaissant le temps estimé, on peut dès lors savoir à quel moment lancer le début des sauvegardes pour arrêter avant un certain délai. 5. Evaluation Pour valider notre modèle, nous comparons les temps de sauvegarde prédits aux temps mesurés. Pour obtenir les mesures, nous avons implémenté un ordonnanceur calqué sur l algorithme de prédiction. L application exécutée par chaque nœud et qui doit être sauvegardée est le code Bench1 mentionné

plus haut. Le programme de test, dont le fonctionnement est illustré à la figure 7, est une application client/serveur multithreads basée sur le modèle «un thread par client accepté» [14]. FIG. 7 Schéma du programme de validation L application serveur est démarrée sur le nœud faisant office de serveur NFS. Le module Lancement indique aux nœuds clients d exécuter l application Bench1 avec la taille spécifiée. Chaque client reçoit l ordre de lancement et crée un processus fils dont le contexte d exécution est remplacé par celui de l application qu il exécute en la préparant à la sauvegarde avec BLCR. Ceci permet à l application cliente d obtenir le PID du processus à sauvegarder. Le module Lancement communique les tailles des applications aux modules Prédiction et Ordonnancement. Le module Prédiction détermine n optimal et calcule le temps estimé pour la sauvegarde, puis communique n optimal au module Ordonnancement qui déclanche le lancement des sauvegardes. Dès qu une sauvegarde est achevée, celle du prochain processus dans la liste des applications à sauvegarder est lancée. Les temps estimés et mesurés sont enregistrés dans des fichiers de trace. Les figures 8,9,10 et 11 montrent les résultats obtenus sur quatre tests différents. FIG. 8 Temps de sauvegarde mesuré et prédit. Taille des applications suré et prédit. Taille des applications FIG. 9 Temps de sauvegarde me- 10 Mo. n optimal = 15 50 Mo. n optimal = 14 FIG. 10 Temps de sauvegarde mesuré et prédit. Taille des applications suré et prédit. Taille des applications FIG. 11 Temps de sauvegarde me- 100 Mo. n optimal = 12 200 Mo. n optimal = 7 On constate dans les différentes figures que les courbes des temps mesurés et prédits varient de façon comparable, et que le module de prédiction parvient à prédire le temps de complétion avec une erreur maximale inférieure à 25% et une erreur minimale autour de 2%.

6. Conclusion Nous avons mené un grand nombre d expérimentations qui nous on conduit dans ce travail à présenter un modèle permettant de déterminer les performances du dispositif de sauvegarde pour le checkpointing de plusieurs applications séquentielles indépendantes dans un cluster virtuel. Cela a permis ensuite de proposer un algorithme basé sur le List Scheduling pour prédire dynamiquement le temps de complétion des sauvegardes. Ce travail intéresserait un gestionnaire de travaux comme OAR qui peut être amené à préempter des jobs pour diverses raisons. Le modèle a certes été établi sur une architecture déterminée, mais il peut être une piste pour des études sur d autres architectures. Nous comptons étendre ce travail au niveau de la sauvegarde du contexte d exécution des applications parallèles, où en plus des contraintes liées à la concurrence des accès réseau et disque, il va falloir tenir compte de la synchronisation entre les processus, pour estimer le temps de sauvegarde du système. L intégration des modèles de communications concurrentes existants sera intéressant. Bibliographie 1. http ://www.icatis.com. 2. N. Capit, G. Da Costa, Y. Georgiou, G. Huard, C. Martin, G. Mounié, P. Neyron, and O. Richard. A batch scheduler with high level components. In Proceedings of Cluster Computing and Grid (CCGRID), Mai 2005. 3. Cryopid. CryoPID : A Process Freezer for Linux. http ://cryopid.berlios.de, 2005. 4. J. Duell, P. Hargrove, and E. Roman. The design and implementation of berkeley lab s linux checkpoint/restart. Technical Report Berkeley Lab LBNL-54941, November 2003. 5. F. Dupros, F. Boulahya, J. Vairon, P. Lombard, N. Capit, and J-F. Méhaut. IGGI, a computing framework for large scale parametric simulations : application to uncertainty analysis with toughreact. In In Proceedings, Tough Symposium, 2006. 6. F. Dupros and A. Carissimi. Sauvegarde et reprise d applications parallèles dans le cadre d un intranet. Ren- Par 17 / SympAAA 2006 / CFSE 5 / JC 2006 Canet en Roussillon, 4 au 6 octobre 2006. 7. L.A. Hall, D.B. Shmoys, and J. Wein. Scheduling to minimise average completion time : off-line and on-line algorithms. Proc. of the Sixth ACM-SIAM Symposium on Discrete Algorithm, January 1996. 8. E. Imamagic, D. D. Zagar, and B. Radic. Checkpointing approach for computer clusters. IIS, 2005. 9. M. Litzkow, T. Tannenbauw, J. Basney, and M. Livny. Checkpoint and migration of unix process in the condor distributed processing system. Technical Report CS-TR-1997-1346, University of Wisconsin, Madison, Apr. 1997. 10. J-M. Nlong and Y. Denneulin. Migration des processus linux sous i-cluster. RENPAR 15 / CFSE 3 / SympAAA 2003. La Colle sur Loup, France, 15 au 17 octobre 2003. 11. T. Olivares, L. Orozco-Barbosa, F. Quiles, A. Garrido, and P.J. Garcia. Performance study on nfs over myrinetbased clusters for parallel multimedia applications. TIC, 2000. 12. J.S. Plank, M. Beck, G. Kingsley, and K. Li. Libckpt : Transparent checkpointing under unix. In Proceedings of the 1995 Winter USENIX Technical Conference, 1995. 13. J.S. Plank and M. G. Thomason. The average availability of uniprocessor systems, revisited. Technical Report UT-CS-98-400, Departement of Computer Science, University of Tenesse, August 1998. 14. W. Richard Stevens. Unix Network Programming, volume 1. Prentice Hall PTR, second edition, 1998. 15. S. Sankaran, J. M. Squyres, B. Barrett, and A. Lumsdaine. The lam/mpi checkpoint/restart framework : Systeminitiated checkpointing. Proceedings, LACSI Symposium, October 2003. 16. R. Tang, J. Xiong, J. Ma, and D. Meng. A new way to high performance nfs for clusters. Proceedings of the Sixth International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT 05). IEEE, 2005. 17. T. Sterling W. Gropp, E. Lusk. Beowulf Cluster Computing with Linux. 2003. 18. H. Zhong and J. Nieh. CRAK : Linux Checkpoint/Restart as a Kernel Module. Technical Report CUCS-014-01, Department of Computer Science, Columbia University, November 2001.