Trabajando con clústeres HPC

En mi universidad, tenemos un clúster de computación HPC. Yo uso el clúster para entrenar clasificadores, etc. Entonces, por lo general, para enviar un trabajo al clúster (por ejemplo, script de python scikit-learn), necesito escribir un script de Bash que contenga (entre otros) un comando como qsub script.py.

Sin embargo, este proceso me parece muy muy frustrante. Por lo general, lo que sucede es que escribo el script de Python en mi computadora portátil y luego inicio sesión en el servidor y actualizo el repositorio SVN, por lo que obtengo el mismo script de Python allí. Luego escribo ese script Bash o lo edito, para poder ejecutar el script bash.

Como puede ver, esto es realmente frustrante ya que, por cada pequeña actualización para el script de Python, necesito hacer muchos pasos para ejecutarlo en el clúster informático. Por supuesto, la tarea se vuelve aún más complicada cuando tengo que poner los datos en el servidor y usar la ruta de los conjuntos de datos en el servidor.

Estoy seguro de que muchas personas aquí están usando clústeres informáticos para sus tareas de ciencia de datos. ¿Solo quiero saber cómo logran enviar los trabajos a los grupos?

Pídale a su administrador de cuadrícula que agregue su máquina local como "host de envío" e instale SGE (que suponemos que está utilizando, en realidad no lo dice) para que pueda hacerlo qsubdesde su máquina.

O....

Use emacs, luego puede editar en su HPC a través de las instalaciones de conexión ssh "tramp" de emacs, y mantener un shell abierto en otra ventana de emacs. No dice qué editor / sistema operativo le gusta usar. Incluso puede configurar emacs para guardar un archivo en dos lugares, por lo que puede guardarlo en su máquina local para ejecutar pruebas y en el sistema de archivos HPC simultáneamente para grandes trabajos.

Hay muchas soluciones para aliviar la carga de copiar el archivo desde una máquina local a los nodos de computación en los clústeres. Un enfoque simple es utilizar una interfaz que permita el acceso múltiple a las máquinas en el clúster, como clusterssh (cssh). Le permite escribir comandos en varias máquinas a la vez a través de un conjunto de pantallas de terminal (cada una una conexión ssh a una máquina diferente en el clúster).

Dado que su clúster parece haberse qsubconfigurado, su problema puede estar relacionado con la replicación de los datos en las máquinas (además de simplemente ejecutar un comando en cada nodo). Entonces, para abordar este punto, puede escribir una scpsecuencia de comandos, copiar cosas hacia y desde cada nodo en el clúster (que seguramente se aborda mejor con SVN), o puede configurar un NFS. Esto permitiría un acceso simple y transparente a los datos, y también reduciría la necesidad de replicar datos innecesarios.

Por ejemplo, puede acceder a un nodo, copiar los datos a dicho lugar y simplemente usar los datos de forma remota , a través de la comunicación de red. No conozco cómo configurar un NFS, pero ya tiene acceso a él (en caso de que su carpeta de inicio sea la misma en todas las máquinas a las que accede). Luego, los scripts y los datos podrían enviarse a un solo lugar y luego acceder a ellos desde otros. Esto es similar al enfoque SVN, excepto que es más transparente / directo.

Su enfoque de usar un repositorio de versión de origen es bueno y en realidad le permite trabajar también en el clúster y luego copiar todo de nuevo.

Si se encuentra realizando ediciones menores en su secuencia de comandos de Python en su computadora portátil, luego actualizando su directorio SVN en el clúster, ¿por qué no trabajar directamente en la interfaz del clúster, hacer todas las ediciones menores necesarias y luego, al final del día, comprometerse todo allí y actualizar en su computadora portátil?

Todo lo que necesita es familiarizarse con el entorno allí (SO, editor, etc.) o instalar su propio entorno (generalmente instalo en mi directorio de inicio la última versión de Vim , Tmux , etc. con los archivos de puntos adecuados para que me sienta bien) a casa allí.)

Además, puede versionar sus datos e incluso sus resultados intermedios si el tamaño lo permite. Mis repositorios a menudo comprenden código, datos (versiones originales y limpias), documentación y fuentes en papel para publicación (látex)

Finalmente, puede realizar un script de su envío de trabajo para evitar modificar los scripts manualmente. qsubacepta un script de stdin y también acepta todos los #$comentarios como argumentos de línea de comandos.

A partir de la redacción de su pregunta, supongo que tiene una máquina local y una máquina remota donde actualiza dos archivos: un script de Python y un script de Bash. Ambos archivos están bajo el control de SVN y ambas máquinas tienen acceso al mismo servidor SVN.

Lamento no tener ningún consejo específico para su sistema de red, pero permítanme enumerar algunos puntos generales que he encontrado importantes para cualquier implementación.

Mantenga los cambios de producción limitados a los cambios de configuración . Escribe que tiene que "usar la ruta de los conjuntos de datos en el servidor"; Esto me parece que tienes los caminos codificados en tu script de Python. Esta no es una buena idea, precisamente porque necesitará cambiar esas rutas en cualquier otra máquina a la que mueva el script. Si devuelve esos cambios a SVN, entonces en su máquina local tendrá las rutas remotas, y así sucesivamente ... (¿Qué pasa si no solo hay rutas, sino también contraseñas? No debería tener contraseñas de producción en un SVN servidor.)

Por lo tanto, mantenga las rutas y otra información de configuración en un .iniarchivo y use ConfigParser para leerlo, o use un .jsonarchivo y use el módulo json . Mantenga una copia del archivo localmente y una remotamente, ambas bajo la misma ruta, ambas sin control SVN, y simplemente mantenga la ruta a ese archivo de configuración en el script de Python (u obténgala de la línea de comando si no puede mantener ambas configuraciones bajo la misma ruta).

Mantenga la configuración lo más pequeña posible . Cualquier configuración es una "parte móvil" de su aplicación, y cualquier sistema es más robusto cuanto menos partes móviles tenga. Un buen indicador de algo que pertenece a la configuración es exactamente que tiene que editarlo cada vez que mueve el código; las cosas que no han necesitado edición pueden permanecer como constantes en el código.

Automatiza tu despliegue . Puede hacerlo a través de un script Bash en su máquina local; en cuenta que puede ejecutar cualquier comando en una máquina remota a través ssh. Por ejemplo:

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'

Para que esto funcione, debe tener un inicio de sesión sin contraseña , basado en claves públicas / privadas, configurado entre su máquina local y la remota.

Si necesita más que esto, puede pensar en usar la tela de Python o la cocina de alto nivel .