Travailler avec des clusters HPC

Dans mon université, nous avons un cluster informatique HPC. J'utilise le cluster pour former des classificateurs et ainsi de suite. Donc, généralement, pour envoyer un travail au cluster, (par exemple, script scythit-learn python), j'ai besoin d'écrire un script Bash qui contient (entre autres) une commande comme qsub script.py.

Cependant, je trouve ce processus très frustrant. Habituellement, ce qui se passe, c'est que j'écris le script python sur mon ordinateur portable, puis je me connecte au serveur et met à jour le référentiel SVN, donc j'y reçois le même script python. Ensuite, j'écris ce script Bash ou le modifie, afin de pouvoir exécuter le script bash.

Comme vous le voyez, c'est vraiment frustrant car, pour chaque petite mise à jour du script python, j'ai besoin de faire plusieurs étapes pour l'exécuter sur le cluster informatique. Bien sûr, la tâche devient encore plus compliquée lorsque je dois mettre les données sur le serveur et utiliser le chemin des jeux de données sur le serveur.

Je suis sûr que de nombreuses personnes ici utilisent des clusters informatiques pour leurs tâches de science des données. Je veux juste savoir comment vous réussissez à envoyer les emplois aux clusters?

Demandez à votre administrateur de réseau d'ajouter votre machine locale en tant qu '"hôte de soumission", et installez SGE (que nous supposons que vous utilisez, vous ne le dites pas réellement) pour pouvoir ensuite qsubpartir de votre machine.

OU....

Utilisez emacs, puis vous pouvez éditer sur votre HPC via les fonctionnalités de connexion ssh "tramp" d'emacs, et garder un shell ouvert dans une autre fenêtre emacs. Vous ne dites pas quel éditeur / système d'exploitation vous souhaitez utiliser. Vous pouvez même configurer emacs pour enregistrer un fichier à deux endroits, afin de pouvoir enregistrer sur votre ordinateur local pour exécuter des tests et sur le système de fichiers HPC simultanément pour les gros travaux.

Il existe de nombreuses solutions pour alléger le fardeau de la copie du fichier d'une machine locale vers les nœuds de calcul des clusters. Une approche simple consiste à utiliser une interface qui permet un accès multiple aux machines du cluster, comme clusterssh (cssh). Il vous permet de taper des commandes sur plusieurs machines à la fois via un ensemble d'écrans de terminal (chacun une connexion ssh à une machine différente dans le cluster).

Étant donné que votre cluster semble s'être qsubinstallé, votre problème peut être plutôt lié à la réplication des données le long des machines (autre que l'exécution d'une commande dans chaque nœud). Donc, pour résoudre ce point, vous pouvez soit écrire un scpscript, pour copier des choses vers et depuis chaque nœud du cluster (qui est sûrement mieux adressé avec SVN), ou vous pouvez configurer un NFS. Cela permettrait un accès simple et transparent aux données, et réduirait également la nécessité de répliquer des données inutiles.

Par exemple, vous pouvez accéder à un nœud, copier les données à un tel endroit et simplement utiliser les données à distance , via la communication réseau. Je ne sais pas comment configurer un NFS, mais vous y avez déjà accès (au cas où votre dossier personnel serait le même sur toutes les machines auxquelles vous accédez). Ensuite, les scripts et les données pouvaient être envoyés à un seul endroit, puis consultés par d'autres. Cela s'apparente à l'approche SVN, sauf qu'il est plus transparent / simple.

Votre approche de l'utilisation d'un référentiel de versions source est bonne et vous permet également de travailler sur le cluster, puis de tout recopier.

Si vous vous trouvez à apporter des modifications mineures à votre script Python sur votre ordinateur portable, puis à mettre à jour votre répertoire SVN sur le cluster, pourquoi ne pas travailler directement sur le frontend du cluster, effectuer toutes les modifications mineures nécessaires, puis, à la fin de la journée, valider tout et mise à jour sur votre ordinateur portable?

Tout ce dont vous avez besoin est de vous familiariser avec l'environnement (OS, éditeur, etc.) ou d'installer votre propre environnement ( j'installe généralement dans mon répertoire personnel la dernière version de Vim , Tmux , etc. avec les fichiers dot appropriés, donc je me sens à là-bas.)

De plus, vous pouvez versionner vos données et même vos résultats intermédiaires si la taille le permet. Mes référentiels comprennent souvent du code, des données (versions originales et nettoyées), de la documentation et des sources papier pour la publication (latex)

Enfin, vous pouvez créer un script pour la soumission de votre travail afin d'éviter de modifier manuellement les scripts. qsubaccepte un script de stdin et accepte également tous les #$commentaires comme arguments de ligne de commande.

D'après le libellé de votre question, je suppose que vous avez une machine locale et une machine distante où vous mettez à jour deux fichiers - un script Python et un script Bash. Les deux fichiers sont sous contrôle SVN et les deux machines ont accès au même serveur SVN.

Je suis désolé de ne pas avoir de conseils spécifiques à votre système de grille, mais permettez-moi d'énumérer certains points généraux que j'ai trouvés importants pour tout déploiement.

Limitez les modifications de production aux modifications de configuration . Vous écrivez que vous devez "utiliser le chemin des jeux de données sur le serveur"; cela me semble que vous avez les chemins codés en dur dans votre script Python. Ce n'est pas une bonne idée, précisément parce que vous devrez modifier ces chemins sur toutes les autres machines sur lesquelles vous déplacez le script. Si vous validez ces modifications dans SVN, alors sur votre machine locale, vous aurez les chemins distants, et ainsi de suite ... (Que faire s'il n'y a pas seulement des chemins, mais aussi des mots de passe? Vous ne devriez pas avoir de mots de passe de production dans un SVN serveur.)

Donc, conservez les chemins et autres informations de configuration dans un .inifichier et utilisez ConfigParser pour le lire, ou utilisez un .jsonfichier et utilisez le module json . Gardez une copie du fichier localement et une à distance, les deux sous le même chemin, les deux sans contrôle SVN, et gardez simplement le chemin vers ce fichier de configuration dans le script Python (ou obtenez-le à partir de la ligne de commande si vous ne pouvez pas garder les deux configurations sous le même chemin).

Gardez la configuration aussi petite que possible . Toute configuration est une «partie mobile» de votre application, et tout système est plus robuste, moins il a de pièces mobiles. Un bon indicateur de quelque chose qui appartient à la configuration est exactement que vous devez le modifier chaque fois que vous déplacez le code; les éléments qui n'ont pas besoin d'être modifiés peuvent rester des constantes dans le code.

Automatisez votre déploiement . Vous pouvez le faire via un script Bash sur votre machine locale; Notez que vous pouvez exécuter une commande sur une machine distante par ssh. Par exemple:

svn export yourprojectpath /tmp/exportedproject
tar czf /tmp/yourproject.tgz /tmp/exportedproject
scp /tmp/myproject.tgz youruser@remotemachine:~/dev

## Remote commands are in the right hand side, between ''
ssh youruser@remotemachine 'tar xzf ~/dev/yourproject.tgz'
ssh youruser@remotemachine 'qsub ~/dev/yourproject/script.py'

Pour que cela fonctionne, vous devez bien sûr disposer d'une connexion sans mot de passe , basée sur des clés publiques / privées, entre votre ordinateur local et l'ordinateur distant.

Si vous avez besoin de plus que cela, vous pouvez penser à utiliser le tissu Python ou la cuisine de niveau supérieur .