> 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.
[^] # Re: Robustesse?
Posté par gvallee . En réponse à la dépêche Un cluster Kerrighed de 252 coeurs basé sur un noyau Linux 2.6.20. Évalué à 3.
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.