Journal Linux, cluster, beowulf, allocation

Posté par  (site web personnel, Mastodon) .
Étiquettes :
0
4
jan.
2008
J'ai à disposition un ensemble de machines identiques qui partagent du disque via NFS. Je les utilisent pour lancer des programmes qui prennent un temps fou et une empreinte mémoire de dingue pour faire des calculs de tarés.

Bref, j'ai un cluster pour faire du calcul scientifique.

Mon problème c'est que j'ai pleins de processus à lancer (au fur et à mesure de mes envies) et qu'il faut les répartir en fonction de la charge des machines.

Ma première idée fut de demander à mon adminsys local si on pouvait installer Kerrighed, histoire de m'éviter du travail idiot qui freinerait ma productivité. Pas fou, il m'a gentillement expliqué que s'il fallait tout réinstaller pour avoir un noyau spécifique, je pouvais toujours le faire moi-même, plutôt que de déléguer la basse besogne aux honnêtes gens. Bref, en l'état, je réparti mes processus à la main.

Donc, je me demande s'il existerait une espèce d'Allocation Manager pour répartir a priori des processus sur un cluster (type Beowulf très simple, donc, puisqu'on a même pas de master, juste un disque commun).

J'ai commencé à faire un script python qui récupère les infos sur les processus en cours sur un ensemble de machines, mais avant de continuer je voudrais être certains de ne pas réinventer la roue (je n'aime pas la mécanique).

Or, c'est vraiment le bordel sur le web quand on cherche ça, tellement ça part dans tout les sens avec tous ces types de clusters différents... une idée ?

  • # Mauvais admin changer admin

    Posté par  . Évalué à 1.

    Ca a l'air d'être une sacrée grosse faignasse ton admin, parce qu'installer Kerrighed, ça demande pas de tout réinstaller...

    http://www.kerrighed.org/wiki/index.php/Installing_Kerrighed(...)

    • [^] # Re: Mauvais user changer user

      Posté par  . Évalué à 1.

      Ca a l'air d'être une sacrée grosse faignasse ton admin, parce qu'installer Kerrighed, ça demande pas de tout réinstaller...

      Mouais, sur le papier, ça a l'air simple, mais en pratique...

      Étant admin et gérant des serveurs de calcul scientifiques, je dirais que pour le moment Kerrighed c'est bien pour les grappes expérimentales, mais de là à le mettre en prod (surtout avec des vrais utilisateurs (=pas informaticiens mais scientifiques) faisant des calculs scientifiques de la vrai vie)...

      Perso, je ne l'installerai pas dans ce cadre (et pourtant je l'ai déjà testé), d'autant que ce n'est pas forcement adapté au besoin : il s'agit "juste" de répartir des jobs, pas de monter un super-calculateur SMP virtuel avec des dizaines de CPU et des centaines de Go de RAM.

      • [^] # Re: Mauvais user changer user

        Posté par  . Évalué à 1.

        Que ce soit adapté au besoin ou pas, honnêtement j'en sais fichtre rien, je n'y connais rien dans le domaine. Ce qui me fait tiquer, c'est que l'admin botte en touche sous un prétexte foireux alors que visiblement il a même pas lu la FAQ du produit. Il ne parle pas de l'adéquation au besoin ou pas.

        • [^] # Re: Mauvais user changer user

          Posté par  . Évalué à 1.

          Mais honnètement, même si ce n'est pas "obligatoire" d'après la FAQ, j'aurai vraiment tendance à partir d'une machine propre pour tester ce genre de chose,plutot que d'une machine dont je ne connais pas vraiment l'état...

          Après, savoir s'il n'a pas pris le temps de bien expliquer ou s'il a juste voulu jouer son BOFH, je ne sais pas ;)

  • # une idée à la con

    Posté par  . Évalué à 1.

    J'ai pas tout compris, alors pas taper !!

    Etat actuel :
    Ton cluster n'est pas vraiment un cluster, juste des machines identiques
    Tu lances tes processus à la main suivant la charge, que tu évalues avec les outils "classique" (ps, top... ???)

    Pourquoi pas :
    Faire un script simple en bash, csh, ksh... qui fait ce boulot à ta place, tu seras toujours à temps de le faire évoluer !

    voilà, c'était ma super participation !

  • # Grid...?

    Posté par  . Évalué à 1.

    En gros, ce que tu cherches, ce sont des "scheduler" pour grappes de calcul, non ?

    Alors pourquoi ne pas utiliser les outils de type SunGridEngine ou OpenPBS/Torque ?

    Nous utilisons le premier pour répartir de l'ordre de 2millions de jobs par mois en moyenne vers un certain nombre de machines. Et cela comprend aussi des programmes interactif/graphique via tunnel ssh (juste que la gestion des signaux est un poil pénible dans ce cas).

    Il faut juste définir un noeud comme étant maitre SGE, et un (des) autre(s) comme noeuds de soumissions, mais ce ne sont pas forcement des machines distinctes.

  • # Condor ?

    Posté par  . Évalué à 1.

    condor c'est le bien !

    http://www.cs.wisc.edu/condor/

    my 2 cents !

  • # Slurm

    Posté par  . Évalué à 1.

    Ce que tu cherches s'appelle un gestionnaire de ressource, et y'en a plein, comme précédemment cité.

    Pour ma part, je proposerai Slurm, le gestionnaire développé au LLNL (Labo qui a la 1ere machine au Top 500 depuis des années, http://www.top500.org ).

    Il a le mérite d'être facile à utiliser dans des configurations basiques et de pouvoir passer à l'échelle jusqu'à des milliers de noeuds. Il est libre et les développeurs sont assez ouvert.

    https://computing.llnl.gov/linux/slurm/

    Je l'utilise depuis un moment avec satisfaction.

    • [^] # Re: Slurm

      Posté par  . Évalué à 1.

      J'oubliais, t'amuses vraiment pas à réinventer la roue, y'a vraiment ce qu'il faut de disponible en libre, qui font ça très bien.

      Ce qui m'étonne c'est que tu as l'air de faire du clustering sans vraiment en faire. C'est un ensemble de stations que tu utilises pour calculer ou vraiment un ensemble de machines dédiées ? Dans ce dernier cas, c'est étrange que tu n'ai pas une vraiment suite d'outils de clustering installé, partage de ressources, souche MPI, gestionnaire de jobs, gestionnaire de batch, etc...
      Dis à ton admin de regarder du côté d'Oscar ou Rocks pour les trucs tout-en-1.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.