Exécution de commandes en parallèle avec ClusterShell

Posté par . Modéré par j.
Tags :
22
25
sept.
2010
Python
ClusterShell est une bibliothèque événementielle en Python qui permet d'exécuter en parallèle des commandes en local et à distance sur des noeuds d'un cluster, ferme de serveurs, stations de travail... Elle fournit également un ensemble de scripts utilitaires basés dessus (voir plus bas).

ClusterShell est développée et utilisée au CEA par les équipes système de plusieurs grands clusters Linux de stockage et de calcul (qui comptent parmi les plus puissants du monde -- dont Tera100), elle est disponible sous licence CeCILL-C (CEA - CNRS - INRIA Logiciel Libre, compatible LGPLv2+). Parmi les fonctionnalités principales on notera :
  • Exécution de commande par fenêtre glissante : N SSH sont instanciés en parallèle, dès qu'un a terminé, un nouveau est lancé sur le noeud suivant
  • Copie de fichiers en parallèle via scp
  • Aucune dépendance sur les noeuds (mis à part un serveur SSH)
  • Collecte et agrégation des sorties et codes de retour
  • Opérations sur les "nodeset", et depuis la 1.3 possibilité de s'interfacer avec une ou plusieurs sources pour résoudre des groupes de noeuds.
  • Bibliothèque "thread safe"
  • Couche d'abstraction du connecteur utilisé (par défaut SSH), qui permet d'en implémenter facilement de nouveaux.
Pour exécuter la commande "uname -r" sur les noeuds tux0, tux1 ... tux15 et tux21, quelques lignes suffisent :

$ python
>> from ClusterShell.Task import task_self
>> task = task_self()
>> task.shell("/bin/uname -r", nodes="tux[0-15,21]")
>> task.resume()


C'est là un exemple simple, il est possible de positionner ses propres gestionnaires d'événements pour réagir à chaque phase de la propagation, afficher les résultats en direct ou agrégés à l'issue de l'exécution...

Comme je le disais en introduction, trois scripts permettent de bénéficier dans vos scripts shell ou votre prompt des fonctionnalités de la bibliothèque :
  • clush : un utilitaire d'exécution de commandes en parallèle. Il permet de regrouper l'affichage des commandes exécutées, intègre la gestion des groupes de noeuds et propose en option un affichage des noeuds en couleur en fonction du flux de sortie (stdout/stderr). Il peut être utilisé en ligne de commande ou en mode interactif, comme un shell classique.
  • nodeset : un utilitaire qui implémente les méthodes de la classe NodeSet de la bibliothèque. Cet outil vous permet d'effectuer tout type d'opération sur des "nodesets", du simple "expand" pour lister les noeuds d'un "nodeset" (très pratique pour effectuer une boucle for sur les noeuds du cluster en shell), jusqu'à l'opération ou-exclusif. Bien sûr, nodeset supporte maintenant aussi les opérations sur des groupes de noeuds.

    Exemple d'exécution:
    $ nodeset -f devil[0-5],devil[8,10],devil9
    devil[0-5,8-10]

  • clubak : un agrégateur d'output, qui permet de présenter de manière synthétique un résultat d'exécution un peu trop verbeux.

ClusterShell a récemment été inclus dans les distributions EPEL 5 et 6beta ainsi que Fedora 12 à 14.
  • # super \o/

    Posté par (page perso) . Évalué à 3.

    je vais pouvoir l'utiliser à la maison sur mon cluster.
  • # avantage par rapport à pdsh ?

    Posté par . Évalué à 3.

    Quel est l'avantage d'utiliser des librairies python par rapport aux commandes classiques style pdsh [https://computing.llnl.gov/linux/pdsh.html] ou dsh [http://www.netfort.gr.jp/~dancer/software/dsh.html.en] ?

    L'empreinte mémoire n'est pas trop grosse en cas de gros cluster (fork ou thread) ?
    • [^] # Re: avantage par rapport à pdsh ?

      Posté par . Évalué à 4.

      ClusterShell se positionne justement comme concurrent de pdsh ou dsh.
      Il apporte des utilitaires en ligne de commande très largement inspirés de pdsh, pour une prise en main rapide de la part des utilisateurs, mais en apportant des nouveautés. Ces outils se basent complètement la bibliothèque pour leur implémentation.

      L'utilisation de python:
      - apporte toutes les facilités de développement qu'un langage de ce type peut amener (portabilité, facilité de code, de débugging)
      - pour un surcoût très faible par rapport à pdsh en 100% C. La grande majorité de la consommation mémoire de ce type d'outil vient des n SSH forkés, qui sont donc les mêmes dans les 2 cas. Le wrapping de ces ssh est très léger et le coût faible. C'est vraiment intéressant d'utiliser python ici vu la très faible contrepartie. ClusterShell est utilisé sur un cluster de 4200 noeuds.

      La bibliothèque permet:
      - de pouvoir développer rapidement des scripts ou utilitaires d'administration de façon rapide, sans se soucier du parallélisme et la bibliothèque fait de l'agrégation de résultats pour réduire l'empreinte mémoire et faciliter le post-traitement des résultats.
      • [^] # Re: avantage par rapport à pdsh ?

        Posté par (page perso) . Évalué à 4.

        Pourquoi sur votre cluster de 4200 noeuds, vous n'utilisez pas de gestionnaire de batch type pbs, sge ou oar ?

        Comment arrivez-vous à gérer la charge globale du cluster ?
        • [^] # Re: avantage par rapport à pdsh ?

          Posté par . Évalué à 4.

          Attention à ne pas confondre gestionnaire de ressources et exécution de commande parallèle.
          ClusterShell est principalement un outil d'administration.

          Le gestionnaire de batch, c'est Slurm (https://computing.llnl.gov/linux/slurm/) c'est lui qui s'occupe de tout ça.
          • [^] # Re: avantage par rapport à pdsh ?

            Posté par (page perso) . Évalué à 7.

            Une petite recherche sur debian lenny parce que je recherchais un projet qui me rappellait le votre et c'est taktuk développé par l'INRIA.

            http://taktuk.gforge.inria.fr/

            A noter que kanif fonctionne de pair avec taktuk http://taktuk.gforge.inria.fr/kanif/

            dish - the diligence/distributed shell for parallel sysadmin
            kanif - cluster management and administration swiss army knife
            pssh - Parallel versions of SSH-based tools
            libtaktuk2-dev - C bindings for taktuk (development files)
            libtaktuk2 - C bindings for taktuk
            taktuk - efficient, large scale, parallel remote execution of commands
            clusterssh - Administrer de multiples shells ssh ou rsh simultanément
            pconsole - parallel console shell for administering clusters

            Sinon, ne pas oublier les outils comme cfengine et dérivée (puppet, chef) d'une grande aide pour faire une partie du boulot.

            Question finale concernant le gestionnaire de batch, slurm gère-t'il les cpuset sur x86_64 ? En effet, avec les nouvelles machines à base de bi-proc 6 coeurs (hyperthréadé -> 24 coeurs), les cpuset deviennent indispensable.
            • [^] # Re: avantage par rapport à pdsh ?

              Posté par . Évalué à 1.

              Oui taktuk est un produit similaire. Quant aux autres, je laisse les gens aller les comparer, mais ce n'est pas vraiment la même chose.

              Slurm gère les cpuset, c'est mieux sur nos noeuds 48 coeurs.
              • [^] # Re: avantage par rapport à pdsh ?

                Posté par (page perso) . Évalué à 3.

                Je dois implémenter une solution de déploiement de binaires sur des dizaines de machines avec arret/redémarrage des serveur primary/backup... C'est donc avec intérêt que j'ai jeté un coup d'oeuil rapide sur les différentes man pages. Pour vous en faire profiter, voici mes notes :
                dish -e "command" host1 host2 
                    -g hostfile      script based on except command
                
                massadmin -e cmd_list -h host1,host2...  (perl + require other packages)
                
                taktuk -f machines-file   broadcast exec command
                      -m hostname                             (perl + C)
                
                clush -w hostname   command (ClusterShell en python)
                     -g group
                     -a
                
                dsh -m hostname  command	(en C)
                    -g group
                    -a
                    -f file
                
                pdsh -w host1,host2... command
                
                pssh user@site command
                (bash around ssh, require a proxy deamon on the other hosts ???)
                
                kash    -a        command
                (kanif)  -M host1,host2...
                       -n/-w nodes
                
                
                • [^] # Re: avantage par rapport à pdsh ?

                  Posté par . Évalué à 1.

                  Ton exemple est intéressant, voici ce que je peux te proposer si tu utilises ClusterShell. Ne connaissant pas ton cas en détail, je vais faire qlq suppositions. A corriger en fonction de tes besoins donc.

                  En shell, avec les outils de ligne de commandes:

                  #!/bin/bash

                  BINFILE="/my/bin/file"
                  # Il est tres pratique que le gestionnaire de groupe de ClusterShell soit configuré.
                  # Dans ce cas, il suffit de donner les noms des groups en question et la liste des
                  # machines correspondantes sera utilisé.
                  PRIMARYGROUP="@primary"
                  BACKUPGROUP="@backup"
                  # Si ce n'est pas le cas, il suffit de remplacer par la liste des machines correspondantes

                  echo "Copying new version of $BINFILE..."
                  clush -S -w $PRIMARYGROUP,$BACKUPGROUP -c $BINFILE || exit 1
                  echo "Restarting primary service..."
                  clush -S -w $PRIMARYGROUP "service primary restart" || exit 1
                  echo "Restarting backup service..."
                  clush -S -w $BACKUPGROUP "service primary restart" || exit 1
                  exit 0


                  En python, en utilisant la bibliothèque,
                  #!env python

                  import sys
                  from ClusterShell.Task import task_self()

                  BINFILE = "/my/bin/file"
                  PRIMARYGROUP = "@primary"
                  BACKUPGROUP = "@backup"

                  task = task_self()

                  # On prepare la copie
                  task.copy(BINFILE, BINFILE, "%s,%s" % (PRIMARYGROUP, BACKUPGROUP))
                  # On lance la copie parallele
                  task.resume()

                  # Si tout c'est bien passé, on continue
                  if task.max_retcode() > 0:
                  print >>sys.stderr, "Copy failed\n"
                  sys.exit(1)

                  # On prepare l'exécution des 2 commandes en même temps)
                  task.shell("service primary restart", PRIMARYGROUP)
                  task.shell("service backup restart", BACKUPGROUP)
                  # On redémarre tout en même temps
                  task.resume()

                  # Si tout c'est bien passé, on continue
                  if task.max_retcode() > 0:
                  print >>sys.stderr, "Restart failed\n"
                  sys.exit(1)

                  sys.exit(0)


                  ClusterShell est souple, donc il y a différentes façons de faire les choses selon les besoins. On peut travailler plus en détail l'output, l'analyse des résultats. On peut imaginer redémarrer les serveurs que sur les machines qui ont réussit la copie, cela de façon très simple. Ce n'est que quelques exemples. N'hésitez pas à poser des questions si vous voulez en savoir plus.

                  (Argh, j'ai fait un cross-post dans ce thread mais j'avais pas vu que la question avait été posé à deux endroits. Je pense que la réponse est plus appropriée ici après coup)
    • [^] # Re: avantage par rapport à pdsh ?

      Posté par . Évalué à 1.

      J'ai oublié de préciser que Pdsh ne fournit aucune bibliothèque basé sur son code, ce qui oblige à scripter des appels à pdsh en shell pour essayer de s'en resservir. C'est largement limité par rapport aux possibilités offertes par ClusterShell.
  • # Un autre outil connexe

    Posté par (page perso) . Évalué à 2.

    PAR: plus pour distribuer des jobs que pour de l'administration
    par contre.
    C'est par ici:
    http://savannah.nongnu.org/projects/par
    Sur quelques multi-procs ou un petit cluster, ca marche pas mal.
    Cite aussi plus haut: cluster ssh (cssh), sur peu de noeuds c'est
    extremement utile.
  • # comparaison

    Posté par (page perso) . Évalué à 1.

    Pourquoi utiliser ClusterShell plutôt que massadmin ? https://linuxfr.org/2010/09/28/27421.html

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Suivre le flux des commentaires

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