Clúster Casper disponible
0
jatorre
Clúster Casper disponible

Tras meses de trabajo, hemos desplegado completamente el nuevo clúster Casper, que sustituye a Alice. Este nuevo clúster incorpora mejoras significativas tanto de hardware como de software. Por un lado, hemos actualizado el nodo de login (front-end) a un nuevo servidor de altas prestaciones con procesadores de última generación, sustituyendo el anterior que databa de 2008. Todo el sistema de almacenamiento se ha reconstruido con cuatro servidores dedicados (dos de metadatos y dos de almacenamiento) basados en BeeGFS, sobre una red 10 GbE que sustituye a la anterior red de 1 Gb. Se han instalado también dos nuevas redes de comunicación entre nodos para permitir el uso tanto diario como de administración en redes independientes. Hemos actualizado también el hardware de todos los nodos para homogeneizar la infraestructura, incorporando discos NVMe de alta velocidad para el sistema operativo, un sistema de doble scratch SSD y HDD para trabajos con baja o alta demanda de escritura, y al menos 128 GB de RAM en todos los nodos.

En el apartado de software, hemos sustituido toda la infraestructura de Rocks Cluster (basada en Centos 7.4, que databa de 2017) por Rocky Linux, que cuenta con un ciclo de vida hasta 2029. Se ha reestructurado el sistema de gestión del clúster por Warewulf y se ha sustituido el gestor de colas por OpenPBS, integrado todo en la suite OpenHPC. Se han instalado también versiones estables actualizadas tanto de compiladores (libres y propietarios) como del software de investigación disponible.

Los nodos de cálculos existentes en Alice se han migrado satisfactoriamente a Casper, manteniendo las colas de trabajo alpha, beta, gamma, epsilon y dseta. A nivel de administración, la numeración de los nodos se ha modificado para facilitar la identificación nodo-cola y permitir futuras ampliaciones con comodidad.

Las pruebas de rendimiento muestran mejoras de hasta un 40% respecto de Alice, por lo que confiamos en que estas actualizaciones sean de utilidad para todos los investigadores del CCAR.

Logs de salida en Casper
0
jatorre
Logs de salida en Casper

En el clúster Casper, por defecto, los logs de salida (tanto de salida estándar como de error) no se generan en el directorio de trabajo del usuario, sino en el nodo de cálculo en el que se está ejecutando el trabajo. Solo cuando finaliza el trabajo los logs se redirigen al directorio de trabajo, permitiendo que se muestre el contenido tanto de la salida estándar como de la salida de error.

Si es necesario hacer un seguimiento de la evolución de un trabajo, siempre es posible redirigir la salida estándar de un programa al directorio de trabajo, concatenando con una tubería la ruta a ese directorio:

lmp -in input.lmp -log $PBS_O_WORKDIR/$PBS_JOBID.log
mpirun -np 4 ./ejecutable > $PBS_O_WORKDIR/$PBS_JOBID.log
./ejecutable > $PBS_O_WORKDIR/$PBS_JOBID.log

Cualquiera de estos ejemplos creará en el directorio desde el que se lanza el trabajo ($PBS_O_WORKDIR) un archivo que coincide con el número de trabajo ($PBS_JOBID.log), lo que posibilita ver la evolución del ejecutable. Con relación a la eficiencia, es importante que la salida de los ejecutables no sea continua, sino que se muestre dejando pasar un tiempo razonable entre mensaje y mensaje, de al menos 10 minutos.

En caso de utilizar fortran, es importante desactivar el buffering con la variable de entorno GFORTRAN_UNBUFFERED_ALL dentro del job de trabajo:

export GFORTRAN_UNBUFFERED_ALL=yes 
./ejecutable > $PBS_O_WORKDIR/$PBS_JOBID.log

Independientemente de estas redirecciones, los logs de salida se seguirán generando a partir de la información del job:

# Nombre del log de salida
#PBS -o prueba.out
# Nombre del log de error
#PBS -e prueba.err

Si deseamos que cada job genere un log distinto, basta comentar esas líneas. De este modo, PBS generará automáticamente los siguientes archivos de salida:

$PBS_JOBNAME.o$PBS_JOBID # Archivo de salida estándar
$PBS_JOBNAME.e$PBS_JOBID # Archivo de salida de error