• Código abierto.
• Tolerante de fallos.
• Seguro.
• Altamente escalable.
• Altamente configurable: dispone de una gran cantidad de plugins fácilmente usables.
• Es el gestor de colas instalado en muchos de los súper computadores del TOP500.
• Relativamente autónomo.
• Amigable para el administrador.

Mirando la ilustración 1, tenemos que SLURM consiste en un demonio central(slurmctdl) que se ejecuta en un nodo de administración, y se encarga de monitorizar los recursos y el trabajo. Puede existir otro demonio exactamente igual, que será un demonio de respaldo para asumir esa responsabilidad ante posibles fallos.

En cada nodo de cómputo se ejecuta un demonio(slurmd), cuyo cometido es: esperar trabajos, ejecutar esos trabajos, devolver el resultado de ejecución de esos trabajos y esperar más trabajos. Estos demonios proporcionan comunicaciones jerárquicas tolerantes de fallos.

Existe otro demonio (slurmdbd), que es opcional y que puede usarse para registrar la información relativa a la contabilidad de varios clústeres que estén administrados por SLURM en una única base de datos.

Como ya dijimos anteriormente los usuarios interactúan con SLURM mediante un conjunto de comandos simples, los cuales son:

Ver más

Otro concepto que utiliza SLURM en cuanto a la arquitectura es el de las particiones( ilustración 2). Una partición es una agrupación de nodos que tienen una “conexión fuerte entre ellos”, es decir, que tienen alguna especie de característica en común, por ejemplo: mismo conjunto de funciones hardware o software.

Como norma, cada nodo debe de estar incluido en al menos una partición, y nada limita que un nodo pueda estar incluido en varias particiones.

1. Srun manda una solicitud a slurmctld para iniciar un trabajo, que requiere que se reserven ciertos recursos.
2. Slurmctld le responde con el identificador del trabajo, la lista de los recursos reservados y la credencial del trabajo.
3. Srun abre los sockets de E/S.
4. Srun envía la credencial del trabajo, junto con la información de la tarea a slurmd.
5. Slurmd reenvía la petición según sea necesario (en función de los nodos que tengamos reservados).
6. Slurmd crea hilos (slurmstepd) mediante forks/execs.
7. Slurmstepd conecta con los sockets de E/S de srun e inicia tareas.
8. Cuando el trabajo termine slurmstepd notifica a srun.
9. Srun notifica a slurmctld la terminación del trabajo.
10. Slurmctld verifica la terminación de todos los procesos a través de slurmd y libera recursos para el próximo trabajo.

Ilustración 3:Secuencia de ejecución de un trabajo (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última).

Una vez visto cómo se ejecuta un trabajo, es interesante ver los estados por los que puede pasar cada uno de ellos.

1. Pending: Trabajo en cola.
2. Running: Recursos asignados y trabajo en ejecución.
3. Suspended: Recursos asignados y trabajo suspendido.
4. Completing:
   1. Cancelled: Trabajo cancelado por el usuario.
   2. Completed: Trabajo finalizado correctamente.
   3. Failed: Ejecución finalizada incorrectamente.
   4. NodeFail: Terminado por fallo en el nodo.
   5. TimeOut: Terminado por alcanzar el TimeOut.

De manera predeterminada SLURM utiliza una política FIFO (First In First Out), para gestionar la prioridad de los trabajos.

Si se quiere modificar esta política para gestionar la prioridad de los trabajos, se debe de modificar el parámetro “PriorityType” en el fichero de configuración “slurm.conf”, que por defecto su valor es “priority/basic”, que es lo que permite la programación FIFO.

Multi-factor Job Priority:

En SLURM existe una política muy versátil para ordenar la cola de trabajos en espera, esta es “Multi-factor Job Priority”, y para usarla debemos de modificar el parámetro “PriorityType” en el archivo “slurm.conf” de la siguiente manera: “PriorityType=priority/multifactor”. Hay seis factores en esta política que influyen en la prioridad del trabajo:

• Age: tiempo que un trabajo lleva esperando en la cola. En general cuanto más tiempo lleve esperando mayor prioridad.

• Fair-share: diferencia entre los recursos asignados y los ya consumidos

• Job size: cantidad de nodos o CPU que el trabajo ha solicitado. Este factor se puede configurar para favorecer o bien a los trabajos más grandes o a los más pequeños, para ello en el parámetro PriorityFavorSmall de slurm.conf:
  • PriorityFavorSmall = NO, prioriza a los trabajos grandes.
  • PriorityFavorSmall = YES, prioriza a los trabajos pequeños.

• Partition: A cada partición se le puede asignar una prioridad. Cuanto mayor sea, mayor será la prioridad de los trabajos que se ejecuten en esa partición.

• QOS (Calidad de servicio): Asociado a la calidad de servicio. Cuanto mayor sea, mayor será la prioridad del trabajo.

• TRES (Recursos rastreables): número de recursos TRES solicitados/asignados en una partición dada. Cuanto mayor número de solicitudes/asignaciones, más prioridad.

La prioridad de los trabajos será la suma ponderada de todos los factores que se le hayan indicado en el archivo “slurm.conf”. Además, podemos asignar un peso a cada uno de los factores para dar más prioridad a unos factores sobre otros.

La programación de los recursos va a depender del tipo de trabajo que se va mandar a ejecución o del complemento de programación que se vaya a elegir.

Trabajos interactivos:

SLURM va despachando los trabajos en función de su prioridad, esto depende totalmente de la política de prioridad que se vaya a utilizar.

Cuando llega una petición de ejecución de un trabajo, SLURM intenta asignarle los recursos que necesita, si es posible le asigna los recursos y comienza la ejecución, si no, se quedará esperando en la petición de inicio de trabajo hasta que los recursos que necesite estén disponibles.

Este método hace que la utilización del sistema y su capacidad de respuesta sea baja. Para ello se puede utilizar el complemento de programación Backfill Scheduling, que viene activado por defecto. Esto hará que se puedan iniciar trabajos de menor prioridad si al hacerlo no se retrasa la hora de inicio de ningún trabajo de mayor prioridad.

Reservas:

Por otra parte, debemos de destacar que SLURM tiene la capacidad de reservar recursos. Los recursos que se pueden reservar incluyen núcleos, nodos, búferes de ráfaga…etc. Una reserva identificará los recursos que están reservados y el periodo de tiempo en el que la reserva estará disponible. En la respuesta de creación de una reserva se incluye el nombre de la misma, que es generado de forma automática por SLURM. Para poder utilizar una reserva, en la solicitud de envío de trabajo se debe de especificar el nombre de la reserva. Por defecto cuando llegue la hora de finalización de una reserva, si el trabajo asociado a la misma no ha terminado este se cancelará. A medida que se acerca la hora de inicio de una reserva, solo se iniciarán los trabajos que se puedan completar antes de que se alcance dicha hora.

El uso de una reserva mejora la prioridad de un trabajo, es decir, cualquier trabajo con una reserva asociada se considera antes para la programación de recursos que cualquier otro trabajo no asociado a una reserva.

Por defecto las reservas no pueden solaparse. Es decir, no pueden existir a la vez dos reservas que incluyan el mismo nodo. Si en una reserva no se especifican los nodos de forma explícita, es SLURM quien se encargará de seleccionarlos de manera que se evite esa superposición y poder garantizar que los nodos estarán disponibles cuando comience la reserva.

Las reservas pueden ser creadas, actualizadas o destruidas solo por el usuario root.

Programación de pandillas:

SLURM permite la programación en grupo, es decir, en la que dos o más trabajos se asignan a los mismos recursos. En este caso, los trabajos se suspenden de manera alternativa para que ambos puedan acceder de manera exclusiva a los recursos durante un período de tiempo previamente configurado (Scheduler Timeslice).

Este tipo de programación mejora la capacidad de respuesta y la utilización del sistema al permitir que más trabajos puedan ejecutarse antes. Los trabajos de ejecución más corta ya no tienen que esperar en una cola detrás de los trabajos más largos, ya que mediante esta ejecución de manera alternativa se les permitirá empezar y terminar antes.

• Documentación oficial de SLURM
• Morris Jette and Mark Grondona SLURM: Simple Linux Utility for Resource
• SLURM Primer (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). Northeastern University Research Computing: Nilay K Roy, MS Computer Science, Ph.D Computational Physics