 OK ! Good morning everybody ! I will talk about flexible distributed checkpoint restart in Kerrigade, This is a French way to pronounce it. OK ! So this work is done in the context of two research projects, one French national project, pittacticity on one European projects XTREMO-S. OK ! So what is Kerrigade ? C'est un système image operating system cluster. C'est un système operating system cluster. Alors, qu'est-ce que ça veut dire ? Ça veut dire que vous avez l'illusion d'un virtual S&P computer sur le top de votre cluster. Vous avez un public de votre processus. Vous pouvez le faire, vous pouvez le monitorer avec PS, avec PégreApp, avec ce que vous voulez. C'est juste comme une boxe standard. Vous avez la mémoire globale, donc vous avez la mémoire shared IPC, et vous pouvez avoir un processus qui utilise plus de mémoire que la mémoire en 1 node. Nous sommes currently working on node addition and removal. Nous espérons avoir ça avant la fin de l'année, ou avant la fin de l'année. Et il y a aussi l'application check pointing. C'est la main partie de mon talk. Caregad est implémenté comme une grande patch de kernel. Il y a aussi des modules, principalement pour cadier, et un petit set d'applications user-learn. La version de développement est currently basée sur Linux 2.6.30. Et maintenant, dans cette version de développement, Caregad est implémentée comme un contenu de light weight. Qu'est-ce que l'application check point est ? L'application check point est l'obligation de sauver le state de l'application sur le disque. Ensuite, vous pouvez restarter votre application. Vous restartez votre application de votre check point et vous avez exactement l'application dans le même state que l'avant. Mais en même temps, vous avez peut-être fermé votre cluster, fermé votre computer, etc. Qu'est-ce que c'est utile ? C'est utile. C'est utile pour faute-tolerance parce que votre cluster n'aura pas de longs-running jobs. Vous aurez une faillite sur votre cluster. Donc, ça peut être utile. C'est aussi utile pour cadier, parce que quand vous commencez des longs-running jobs, peut-être que vous devez les arrêter parce que vous avez un autre job pour rouler. C'est utile aussi pour la maintenance hardware et pour la débugging. OK. Alors, qu'est-ce que le step de check point ? C'est le commandement pour tous les check pointers, tous les check pointers du système. Tout d'abord, vous devez frisier votre application. Ensuite, vous devez tomber le data, vous devez tomber les souvenirs du process, votre registre, etc. et tous les states internes de l'application. Et enfin, vous devez laisser votre application résumer. Bien, ces step sont nécessaires au niveau kernel pour la consistance. Parce que si vous check point le processus sans arrêter l'application, votre application ne sera pas... Vous ne pourrez pas OK. Mais c'est nécessaire au niveau kernel, mais c'est aussi utile au niveau user. Pourquoi ? Parce que le kernel ne peut pas faire tout pour vous. Donc, pour exemple, généralement, le système file n'est pas sauvé automatiquement quand vous check point votre application. Cela signifie que vous devez le faire pour vous-même. Vous devez sélectionner le file que vous voulez pour l'instant avec votre check point. Donc, vous devez à un moment, pour sélectionner votre application, vous devez couper l'application, pour exemple, et puis, pour vraiment check point votre application. OK. Maintenant, à restart, c'est un peu plus simple. Donc, premièrement, vous devez sélectionner votre application. Vous devez sélectionner votre application. Et puis, vous devez se sélectionner. Donc, encore une fois, c'est nécessaire au niveau kernel pour la consistance. Parce que vous ne pouvez pas laisser un processus résumer avant que l'autre processus de votre application soit resté. Mais, ceci est aussi utile au niveau user. OK. Maintenant, c'est simple. Donc, qu'est-ce que l'application ? Tout le check point ne peut pas avoir le même concept de l'application. Pour tous les check pointeurs, l'application n'est qu'un processus. Dans Kregad, l'application n'est pas un processus. Ce n'est pas un processus, mais c'est un processus. Donc, pour exemple, si vous imaginez cette application, ici vous avez 3 processus, 1 processus, 2 processus, 3 processus. Si ce processus s'arrête, et ces processus sont réparés dans l'application, cela ne signifie pas qu'ils ne sont pas dans l'application. Dans Kregad, ces processus sont encore vus dans l'application. Ce n'est généralement pas le cas dans d'autres check pointeurs. OK. Vous avez une application, c'est-à-dire les processus. Il y a aussi des files. Vous avez besoin de files pour votre application. Ces files sont principalement les terminaux, mais ce sont peut-être des files opales, ce sont des files maps, etc. Et bien sûr, votre processus va probablement communiquer ensemble avec 5 sockets, IPC-objects, etc. Donc, les limites d'une application vont être réformées avec X8, avec Open, avec M-Map, etc. OK. Le premier exemple. C'est un exemple d'application qui traite les données d'un message IPC. Vous commencez votre application avec la ligne suivante. Si vous êtes dans votre cellule, cela crée un processus, peut-être un processus multistralien. Vous avez des données d'un message IPC et vous writez des données dans ces files. OK. Avant de commencer votre application dans K-Regard, vous avez besoin d'informer le kernel que ce sera une application qui sera check pointable. Si vous ne faites pas ça, nous n'avons pas de savoir que vous ne faites pas ça. Vous n'aurez pas besoin de faire ça. Vous avez juste ajouté ceci au début de votre command line. Comme BLCR check pointer, ce n'est pas de faire du jacquement de votre processus. Dans BLCR, pour exemple, il y a un moyen similaire de faire votre application, mais le but est de faire votre application de savoir cela. OK. Maintenant, vous voulez check point votre application. D'abord, vous vous demandez de freeze votre application. Vous vous identifiez votre application avec une PID de l'application. Si vous freezez votre application et que vous n'avez pas sûr que votre application n'a pas de données du message, vous pouvez check point le message. Vous pouvez sauver le contenu du message avec le suivi command. Puis, peut-être que vous avez besoin de sauver le contenu de ce file. Peut-être pas, mais peut-être que vous avez besoin. Donc, si vous avez besoin, vous pouvez simplement copier cela par vous-même. Quand vous avez fait tous ces tableaux préliminaires, vous pourrez check point votre application. Donc, ici, c'est juste de dire OK, maintenant je vais check point. Donc, votre application va continuer, mais vous avez un point de safe que vous pouvez restarter. Donc, maintenant, si pour des raisons vous avez rebuté votre computer ou je ne sais pas, et vous voulez restarter votre application. D'abord, vous copiez le file et vous restartez le message et puis vous restartez votre application. OK. Maintenant, l'application complexe. Donc, une application OpenMPI. OK. Nous l'avons utilisé pour la computation physique et pour la dynamique chroma OK. C'est pour les jobs longues, bien sûr. OK. L'application MPI avec un file host qui dit, OK, j'ai envie de gérer mon application sur ces nodes et sur celui-là. Et ici, c'est votre application. Donc, c'est standard OpenMPI. Puis, dans OpenMPI, vous avez un moyen de check point votre application. Donc, vous vous identifiez votre application avec l'ID MPI. OK. Vous n'oubliez pas d'expliquer comment l'application a commencé exactement. OK. Donc, vous roulez l'MPI-RUN. Puis, l'MPI-RUN a établi la communication SSH pour les différents nodes spécifiés dans le file host. Et les autres nodes, un processus hôteur sera sorti. Puis, l'MPI-RUN et votre processus hôteur sera discuté par l'MPI-LAYER. Donc, c'est plus sur les circuits mais probablement votre processus sera sorti sur des files. Ces files peuvent être partagées avec l'MPI-RUN ou avec hôteur, ou peut-être pas. Et il y a des papiers entre l'MPI-RUN et votre processus hôteur et aussi avec hôteur. OK. Vous avez demandé de vérifier votre application. Je vais juste y aller. OK. Dans l'OPEN-MPI-RUN, l'OMPI-RUN est juste un rappeur pour l'MPI-RUN. C'est utilisé pour l'OMPI-RUN sur peut-être plus de nodes ou moins de nodes. Donc, en fait, l'OMPI-RUN sera utilisé pour vérifier votre processus hôteur et l'OMPI-RUN l'OMPI-RUN est responsable pour réopérer les circuits et tout. Donc, OK. Non, ce n'est pas ceci. OK. Pour commencer, comme vous le voyez, vous spécifiez l'OMPI-RUN et vous identifiez votre checkpoint. Donc, en fait, depuis l'OMPI-RUN crée l'OMPI-RUN dans la communication des circuits, vous n'avez pas à faire ça dans votre checkpoint et vous devez le remplacer. Vous devez le remplacer par l'OMPI-RUN ou l'OMPI-RUN et vous devez le remplacer. L'OMPI-RUN est basicement un checkpoint openMPI qui est créé pour l'OMPI-RUN au début. Nous avons essayé d'avoir un meilleur interface que l'OMPI-RUN parce que l'OMPI-RUN de l'OMPI-RUN n'est pas très bon. OK. C'est rapide. Pourquoi est le checkpoint dans l'OMPI-RUN flexible ? Parce que vous pouvez vérifier un set de processus. Ce processus peut être multistrédit ou pas. Vous avez un freeze comme d'autres checkpointeurs, comme je le dis, mais pour l'OMPI-RUN dans le checkpoint dans le checkpoint dans le checkpoint dans l'OMPI-RUN on peut résoudre l'OMPI-RUN comme le message queue mais aussi le sceau de la saison ou le semaphore. Vous pouvez résoudre l'OMPI-RUN indépendant. Vous devez le connaître au background ou au foreground. On peut faire une substitution à 3-START, pour relancer votre application à un nouveau socket. Finalement, on peut faire un processus en substitution de session ID. Il a été nécessité dans l'OMPI-RUN. Pourquoi est le checkpoint 3-START distribué dans le QRIGAT ? Parce que QRIGAT est un système d'opérations pour l'OMPI-RUN. C'est-à-dire que la processus simple peut être distribué sur l'OMPI-RUN. Donc, votre application peut être distribuée mais peut-être vous pouvez aussi faire des applications pour l'OMPI-RUN comme l'OMPI-RUN dans l'OMPI-RUN. On peut vérifier. C'est à la fin de mon talk, il y a quelques secondes si vous avez peut-être une question, je ne sais pas. Ou si vous avez plus, probablement on peut parler de ça. OK. Oui. Bien sûr. Le checkpoint 3-START, c'est-à-dire le QRIGAT déployement ? Je pense qu'il y a un système de production dans l'OMPI-RUN. Oui. Est-ce que je vous propose que vous rencontrez la speakers à l'arrivée ?