Articles : Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20
Posté par Sytoka Modon (page perso, ). Modéré le 03 décembre 2007.
0
Kerrighed 2.2.0 est sortie le 8 novembre dernier. Pour rappel, Kerrighed est un SSI, c'est à dire un système à image unique sur un cluster. En gros, un cluster Kerrighed est vu comme une seule et même machine SMP.
Cette version est basée sur un noyau Linux 2.6.20 donc un noyau plutôt récent. Rappelons que l'un des objectifs de développement de Kerrighed est d'avoir des modules noyaux relativement autonome vis à vis du c½ur Linux et un patch minimaliste afin de simplifier la cohérence et la maintenance de l'ensemble. La principale avancée de cette version est le support des machines SMP, c'est à dire de toutes les machines modernes dont le processeur est multi-coeur. Même si celui-ci n'est pas encore parfaitement stable, il fonctionne bien. Par ailleurs, une version 64 bits est en cours de finalisation.
Cette version introduit également un support complet pour les communications IPC (segment de mémoire partagée, sémaphore, files d'attente de message).
Afin de montrer que cela fonctionne sur plus de deux machines, un cluster Kerrighed de 252 CPU a été monté. Celui-ci comporte 63 n½uds bi-processeur dual-c½ur ayant chacun 1 Go de mémoire. La machine SSI affiche alors une mémoire globale de 63 Go.
![[en]](../images/en.png)
Le site de Kerrighed (895 hits)-
L'annonce de la version 2.2.0 (211 hits)
-
Le cluster de 252 coeurs (861 hits)
> Lire la suite (38 commentaires, moyenne: 3,2). [dépêche : 1104 caractères]
Vous avez demandé le commentaire #886830.
Run by 
Cette page a été générée par Templeet en 0.0568s (dont 0.0054 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Robustesse?
Est-ce que c'est possible maintenant de retirer un coeur d'un cluster 'à chaud' sans perturber le cluster?
Je crois me souvenir qu'il s'agissait d'une limitation de la version 1.0 ..
[^]Re: Robustesse?
C'est actuellement en cours d'implémentation.
Il est maintenant possible d'ajouter un noeud au cluster sans trop de problème. Pour le retrait (demandé par l'administrateur), c'est en relativement bonne voie. Tous les services ne sont cependant pas à jour à ce niveau.
Quant à la gestion de la défaillance d'une machine du cluster, c'est plus délicat. La mise au point risque d'être assez longue.
J'entends par "gestion de la défaillance" le fait que le système soit stable avec les machines restantes. La haute disponibilité des applications, c'est encore un autre défi :-)
Vous avez la liberté de choisir, choisissez la liberté!
[^]Re: Robustesse?
Quelle est la duree moyenne de survie du cluster ? Par ce que si tu extrapoles sur la frequence des incidents hardware sur des plateformes comme grid5000, Egee, Naregi ou DAS, c'est une chance si tu passes la semaine.
Ne pas gerer la tolerance aux pannes dans un environment reparti c'est faire un jouet pas un outil.
Autrement tu as des exemples d'applications reelles qui scalent sur du SSI ?
[^]Re: Robustesse?
> Ne pas gerer la tolerance aux pannes dans un environment reparti c'est faire un jouet pas un outil.
C'est bien pour ca que des le debut Kerrighed a ete architecture pour supporter simplement le checkpoint/restart d'applications et aussi l'ajout/retrai de noeuds. Gentildemon parle de quelque chose d'utilisable en production, pas d'un prototype de recherche. Le prototype de recherche de Kerrighed a deja supporte le checkpoint/restart d'applications mais ca n'etait pas utilisable en production (un jouet pour la recherche quoi).
KerLabs et ces collaborateurs tentent justement de passer de l'etat de jouet a celui d'outil. Mais comme pour tout projet, ce passage prend du temps, il faut etre patient.
> Autrement tu as des exemples d'applications reelles qui scalent sur du SSI ?
Si tu veux une reponse, je pense qu'il va te falloir etre plus precis car "applications reelles qui scalent sur du SSI", c'est un peu vague; tu as quelle echelle en tete ? qu'est ce que tu entends par application reelle ? par SSI tu sous-entends utilisant la memoire partagee ?
Un SSI c'est un ensemble de caracteristiques qui peuvent etre combinees/utilisees ou pas. Pour etre plus precis, avec SSI, tu peux utiliser la memoire partagee ou bien utiliser uniquement l'equilibrage de charge et la tolerance aux fautes, ...etc. Une application donnee "va etre interessee" par certains de ces mecanismes et pas par d'autres (ca depend toujours de l'application au final!).
Niveau plate-forme, des clusters de >1000 noeuds? non clairement ce n'est pas pour demain. Clusters de moins de 100 noeuds pour des applications standard SMP (ou legerement tuner), c'est jouable et les derniers tests semblent indiquer cela (dans le temps j'avais fais des tests avec une appli OpenMP qui allait bien, par rapport a un SMP, ca tenait la route jusque 6-8 ce qui normal pour la plupart des applis OpenMP, donc pour ce cas particulier, ca marche).
Sinon une autre solution serait de voir ce que ca donne avec les applications qui tournent sur les machines SGI, avec un reseau haute perf sous le SSI, ca devrait etre interessant.
Ensuite si ta question est de savoir si un SSI peut etre utiliser avec une application en production, a nouveau pour le moment non (enfin pas a ma connaissance). Mais les petits gars de KerLabs travaillent sur le probleme, il faut rester optimiste, je suis sur qu'ils vont bientot nous sortir une version qui va franchement tenir la route. :-)
[^]Re: Robustesse?
> tu as quelle echelle en tete ?
A priori je pense pas que que le SSI soit adapté à de grosse échelles. Disons un petit cluster classique entre 128 et 512 cores avec dans les 1Go de RAM/Core.
> qu'est ce que tu entends par application reelle ?
Souvent le SSI est présenté comme une solution pour faire tourner des applications "classiques". On a une image unique pour tout un cluster. On laisse, plus ou moins, le système gérer seul la distribution. Une application classique serait éffectivement une application avec CPU intensif et memoire partagée.
Si il n'y a que du CPU et des workers stateless, type demon httpd/dns, alors on peut en general faire du loadbalancing sur les processus. Si il n'y a que des gros besoin mémoire alors des solutions types jumbomem fonctionnent aussi. Et enfin quand on veut réellement se soucier d'écrire une application distribuée alors on utilise un middleware adéquat.
Je pense que votre cluster est justement fait pour jouer, donc ce qui sera intéressant ce sont les retours d'éxpérience.
[^]Re: Robustesse?
> A priori je pense pas que que le SSI soit adapté à de grosse échelles. Disons un petit cluster classique entre 128 et 512 cores avec dans les 1Go de RAM/Core.
Tout d'abord, ca ce n'est pas une grande echelle actuellement. :-) Plus serieusement je pense que ca devrait le faire si l'on a une application qui le permet. Car soyons serieux : connais-tu une application "classique" actuelle qui peut utiliser tant de core a elle toute seule ? Moi non.
L'avantage du SSI dans ce cas est comme pour le SMP : il est simple de voir ce qui se passe, il est simple de lancer des applications, il n'est pas trop dur d'ecrire une application parallele (memoire partagee tout ca tout ca) et si tu executes des applications en meme temps, les resources sont globalement utilisees de maniere transparentes.
A mon avis, tu ne peux pas ca aussi simplement avec les outils standards pour les systemes distribues (par exemple mais a mon avis, un systeme batch est loin d'etre naturel a utiliser).
Donc SVP, si tu as des elements pour dire que ca ne passe pas a cette echelle, peux-tu donner plus de details? Car vu les derniers tests que j'ai pu voir, ca me semble franchement faisable dans le cas d'utilisation que je decris plus haut.
> Une application classique serait éffectivement une application avec CPU intensif et memoire partagée. Si il n'y a que du CPU et des workers stateless, type demon httpd/dns, alors on peut en general faire du loadbalancing sur les processus. Si il n'y a que des gros besoin mémoire alors des solutions types jumbomem fonctionnent aussi. Et enfin quand on veut réellement se soucier d'écrire une application distribuée alors on utilise un middleware adéquat.
Heu mais la tu justifies le SSI!
- loadbalancing: transparent a l'utilisateur, il n'a rien a faire pour cela, le SSI place et deplace les processus entre les processeurs. Pas besoin de systeme de batch ni d'autres outils qui au final ne font qu'etendre de maniere artificielle ce que les systemes de type Unix font tres bien au sein d'un systeme unique.
- gros besoin en memoire : avec la DSM c'est possible et transparent encore une fois. La difference entre jumbomem et une DSM est vraiment minime pour ce que je sais, non?
- utiliser un middleware adequat : oui et alors? le SSI n'empeche pas ca. C'est meme une bonne idee pour avoir des performances.
Ensuite l'avantages du SSI c'est que tu as le choix : tu veux utiliser MPI pour avoir les perfs de la mort qui tue, pas de pbs; tu veux utiliser pthread qui faire un truc vite fait qui tourne sur quelques noeuds, pas de probleme; ...etc. Et bien sur que le SSI je repond pas a TOUS les besoins (aucune solution ne le fait de toute facon).
Bref, le SSI offre plein de possibilites. Pour certaines personnes, ca ne sera pas interessant, pour d'autres ca le sera. Par exemple, le SSI va tres bien avec le concept de "cluster sur ton bureau", i.e., une petite machines assez dense pour tenir sur ton bureau avec plusieurs processeurs/cores a l'interieur. Pour democratiser ce genre de machine, tu dois cacher la distribution des resoruces, le SSI est parfait pour ca.
> Je pense que votre cluster est justement fait pour jouer, donc ce qui sera intéressant ce sont les retours d'éxpérience.
Justement je t'ai deja dis dans le message precedent qu'avec des applications scientifiques "qui vont bien" (OpenMP dans mon cas), ca se passait plutot bien. L'idee dans ce cas est de remplacer les SMP vieillissant qui etaient utilises pour l'execution de ces applis par quelques noeuds (beaucoup moins chers) faisant tourner un SSI.