Les codes que nous lançons sont souvent des gros bousins monothread (avec moults paramètres, lancés via des script bash/csh/python/etc), mélange de C et de Fortran, qui bouclent sur x fichiers à traiter. Il y'a bien sûr des cas différents, comme ouvrir plusieurs fichiers pour en générer un qui soit une synthèse du tout, et j'en passe.
Je n'ai pas beaucoup approfondi hadoop, mais il semblerait que pour en tirer correctement parti, il faudrait modifier les algos (par exemple pour faire que le traitement se fasse sur des parties de l'image). Voire modifier les scripts de lancement pour lancer plusieurs traitements en même temps. J'ai peut-être tort, mais en tout cas, on a déjà bien assez de boulot sur la partie scientifique du code pour devoir s'amuser à le parralléliser d'une manière ou d'une autre.
Sans compter qu'il faut qu'il reste portable afin que lorsque nous livrons le code il fonctionne sur une machine classique ou presque.
Il serait effectivement possible de se baser sur ton soft, le problème principal étant la consommation mémoire...il n'est pas rare que nous swappions avec un seul process et 8 go de ram. Mais je vais tout de même m'y pencher un peu plus.
Le but principal de la grille/grappe serait d'éviter à chacun de chercher (via munin pour l'instant) une machine « libre » pour y éxecuter du code, ou de chercher les machines dispos pour pouvoir lancer 20 ou 30 fois un code de type monte-carlo (qui lui ne prend quasiment rien en mémoire, mais qui bouffe du cpu comme pas permis).
Sans parler d'arrêter les galères du type: « il me faut 2 To pour pouvoir stocker les résultats que vont générer les calculs, je peux les mettre sur quelle machine ? ». Et ils n'aiment pas la réponse « 1to là, et l'autre là », tu te doutes :)
Bref, l'organisation d'origine était pas mal...avec 4/5 serveurs. Il est grand temps que nous passions à une solution plus évolutive, plus adaptée à nos besoins...et ce n'est guère évident de la trouver.
[^] # Re: Hadoop, pourquoi pas
Posté par laurent wandrebeck (site web personnel) . En réponse au journal Quelles solutions adopter pour améliorer un parc existant ?. Évalué à 2.
Je n'ai pas beaucoup approfondi hadoop, mais il semblerait que pour en tirer correctement parti, il faudrait modifier les algos (par exemple pour faire que le traitement se fasse sur des parties de l'image). Voire modifier les scripts de lancement pour lancer plusieurs traitements en même temps. J'ai peut-être tort, mais en tout cas, on a déjà bien assez de boulot sur la partie scientifique du code pour devoir s'amuser à le parralléliser d'une manière ou d'une autre.
Sans compter qu'il faut qu'il reste portable afin que lorsque nous livrons le code il fonctionne sur une machine classique ou presque.
Il serait effectivement possible de se baser sur ton soft, le problème principal étant la consommation mémoire...il n'est pas rare que nous swappions avec un seul process et 8 go de ram. Mais je vais tout de même m'y pencher un peu plus.
Le but principal de la grille/grappe serait d'éviter à chacun de chercher (via munin pour l'instant) une machine « libre » pour y éxecuter du code, ou de chercher les machines dispos pour pouvoir lancer 20 ou 30 fois un code de type monte-carlo (qui lui ne prend quasiment rien en mémoire, mais qui bouffe du cpu comme pas permis).
Sans parler d'arrêter les galères du type: « il me faut 2 To pour pouvoir stocker les résultats que vont générer les calculs, je peux les mettre sur quelle machine ? ». Et ils n'aiment pas la réponse « 1to là, et l'autre là », tu te doutes :)
Bref, l'organisation d'origine était pas mal...avec 4/5 serveurs. Il est grand temps que nous passions à une solution plus évolutive, plus adaptée à nos besoins...et ce n'est guère évident de la trouver.
Merci pour tes lumières en tout cas.