SLURM

L'article necessita alguna millora en el contingut o l'estil. Cal millorar la redacció. Sembla tret d'un manual per aprendre a fer-lo servir, o d'uns apunts de classe. I cal eliminar expressions com "és interessant la idea..."

Aquest article o secció no és enciclopèdic i sembla un currículum. Si us plau, reescriviu l'article de manera que el redactat sigui enciclopèdic. Vegeu Viquipèdia:Llibre d'estil i Viquipèdia:Allò que la Viquipèdia no és.

Aquest article podria incomplir els criteris generals d'admissibilitat. Milloreu-lo amb referències que demostrin que es tracta d'un tema admissible o bé podria entrar en un procés d'esborrament o fusió. (2020)

SLURM

Tipus	programari lliure
Versió estable	23.11.6.1 (16 abril 2024)
Llicència	GNU General Public License
Característiques tècniques
Sistema operatiu	Linux
Escrit en	C
Equip
Desenvolupador(s)	Danny Auble (en) i Morris A. Jette (en)
Fonts de codi  Codi font Codi font Gentoo sys-cluster/slurm
Més informació
Lloc web	slurm.schedmd.com

SLURM (de l'anglès Simple Linux Utility for Resources Management), és un sistema de planificació de tasques i gestió de clústers. Es caracteritza per ser portable, tolerant a errors, de codi obert i amb una escalabilitat molt alta. Com a sistema de gestió té tres processos claus:

1. Assignar nodes de còmput durant un temps determinat perquè els usuaris puguin executar tasques.
2. Gestionar les tasques mitjançant un framework que permet iniciar, executar i supervisar-les.
3. Administrar una cua de tasques pendents per tal d'assignar els recursos de còmput per ordre de prioritat.

Existeixen dos tipus de Daemons que interactuen entre ells. Slurmctld, l'administrador del sistema, i Slurmd. El primer s'executa en un únic node actiu i unifica la visió del Clúster gestionant nodes i planificacant els treballs. Slurmd, en canvi, resideix en tots els nòdes de còmput i s'encarrega d'acceptar treballs i executar-los.

Els usuaris interaccionen amb el sistema mitjançant ordres. Les més freqüents són sinfo, srun, sbatch, squeue, scancel i scontrol.^[1]

Arquitectura

SLURM està format per dos tipus de daemons: slurmd, que s'executa a cada node i té com a missió executar tasques, i l'slurmctld, que s'executa a un node i s'encarrega de monitorar recursos i tasques. Aquesta eina de Linux té la capacitat de gestionar:

• Nodes: unitats de còmput
• Particions: agrupació lògica de nodes o set de recursos assignats a un usuari per una quantitat determinada de temps. Cada node ha de pertànyer a almenys una partició però el mateix node no té per què pertànyer a una sola. Les particions poden ser considerades com a cues, cadascuna de les quals té una sèrie de restriccions o condicions, com per exemple: el límit de temps de la tasca, els usuaris als quals es garanteix accés, mida de la tasca, etc.
• Tasques: dins d'una partició l'assignació de tasques es fa en ordre de prioritat fins que s’esgoten els recursos de la partició.
• Subtasques: processos que conformen o una tasca, normalment s’executen en paral·lel.

Slurmd

Aquest daemon s'executa en paral·lel a tots els nodes membres del clúster. El seu funcionament es compara amb el d'un daemon de terminal remota; és a dir, llegeix els arxius de configuració comuns d'SLURM, notifica al controlador que és actiu, espera a rebre una tasca, executa les tasques que rep, retorna l'estatus de sortida de la tasca i llavors torna a esperar una altra tasca.

El fet que SLURM executi tasques per diversos usuaris fa que hagi de ser executat com usuari root o administrador.

Slurmd té quatre components o serveis principals que posa a disposició del node central:

• Serveis d'estatus de màquina i tasques: respon a les peticions del controlador quan sol·licita el seu estat i envia respostes asíncrones quan canvia d'estat, per exemple, quan slurmd s'inicia.
• Execució remota: executa, gestiona i neteja l'entorn una vegada un procés s'hagi finalitzat, allotjat els recursos amb dependències, inicialitza l'stdio, etc.
• Fil de servei de copia: permet la gestió de stderr, stdout i stdin de tasques remotes.
• Control de tasca: permet la comunicació asíncrona entre el node i l'entorn remot des de del qual s'executa una tasca.

Slurmctld

Slurmctld és el node central del clúster. Aquest daemon té, per cada estructura de dades, bloquejos d'escriptura i lectura independents entre si. Aquest factor proporciona escalabilitat al sistema.

Quan slurmctld arrenca llegeix l'arxiu de configuració i tota dada d'estatus guardada. Periòdicament va guardant a disc dades del seu propi estat.

Aquest controlador pot estar en funcionament o en pausa, depenent de l'estat del seu daemon bessó, en cas de tenir-ne.

Al contrari que el slurmd, no s'ha d'aixecar amb un usuari arrel, de fet s'aconsella la creació d'un usuari únicament dedicat a l'execució i la gestió del controlador d'SLURM.

Com succeeix en el cas de l'slurmd aquí també tenim components o serveis principals, en aquest cas tres:

• Administrador de nodes: Monitora l'estat de cada node membre del clúster, això inclou assegurar-se que cada node té una determinada configuració abans de ser considerats disponibles per la presa de tasques.
• Administrador de particions: agrupa els nodes en sets lògics anomenats particions. Aquest administrador també s'encarrega de repartir les tasques en funció de la configuració de cada partició així com del seu estat.
• Administrador de tasques: Accepta les tasques d'usuari i les introdueix a una cua de tasques ordenada per prioritat. Aquest administrador no només es crida de forma periòdica sinó que també s'invoca cada vegada que hi ha algun canvi que podria permetre que una tasca es comenci a executar.

Slurmdbd

Existeixen més daemons complementaris a SLURM. N'és un exemple slurmdbd que s'utilitza com interfície per una base de dades per SLURM.

Com funciona?

Ordres

El sistema proporciona unes ordres a l'usuari per enviar treballs a la cua i que s'executin. Les més comunes són:^[2]

Modes d'execució

Cada tasca té el seu propi identificador numèric, nom, temps límit i mida d'especificacions. D'aquesta manera el controlador pot saber quin és l'estat de la seva tasca en cada moment. Abans d'enviar una tasca, s’ha de tenir en compte que el fet d'augmentar la quantitat de recursos que es sol·licita pot disminuir el temps que comporta l'execució però pot augmentar el temps d'espera a la cua de Slurm. La principal causa d'això és perquè altres usuaris també han de poder utilitzar aquests mateixos recursos.

Hi ha 3 modes d'executar tasques. El primer i més simple, anomenat Interactive Mode, permet la comunicació interactiva entre el terminal de l'usuari i la tasca en temps real. El segon és el Queued Mode, on les tasques esperen la disponibilitat dels recursos necessaris en una llista per ser executats remotament sense interacció externa. En l'últim, Allocate Mode, la tasca i la gestió dels recursos s’assigna a l'usuari el qual programa manualment les execucions.

Interactive Mode (srun)

1. L'usuari executa l'ordre srun indicant les opcions desitjades de l'execució. Slurmctld tracta d'assignar-li els recursos necessaris demanats i envia la resposta de la sol·licitud al node des d'on s’ha executat l'ordre srun.
2. El node usuari es comunica amb el deamon slurmd dels diferents recursos sol·licitats per tal d'iniciar el procés. Slurmd crea un socket de comunicació entrada/sortida entre el port del node extern de l'usuari i els recursos. D’aquesta manera els processos es comuniquen amb l'usuari mitjançant stdout, stdin i stderr.
3. Una vegada establerta la connexió s’executa la tasca. A través del canal de comunicació l'usuari té la possibilitat d'enviar ordres mitjançant la terminal i els nodes d'execució poden respondre. Depenent de l'especificació del programa les ordres seran unes o unes altres. Quan l'usuari indica la finalització del procés, els diferents nodes de còmput envien un missatge de sortida conforme la tasca ha finalitzat correctament i s’alliberen.
4. El node de l'usuari envia a slurmctld que el recursos ja estan disponibles per acceptar noves tasques. Slurmctld envia un procés d'epíleg on s’especifica com ha anat l'execució i els nodes utilitzats responen.

Un exemple per enviar una tasca és:

$ srun -N 2 -n 48 -t 30 -A xz0123 ./tasca

Queued Mode (sbatch)

1. L'usuari executa l'ordre sbatch indicant les opcions desitjades de l'execució en un guió. Slurmctld crea un directori de treball, amb fitxer de sortida per poder gestionar les E/S estàndards stdout, stdin i stderr, i envia la resposta de la sol·licitud. En aquest moment el treball sol·licitat es posa a la cua esperant recursos disponibles.
2. Quan els recursos estan disponibles i la prioritat del treball és superior a altres, slurmcltd envia les variables d'entorn, el directori de treball i el guió a un node slurmd.
3. Aquest slurmd farà la gestió dels recursos a utilitzar en l'execució de la tasca. Fent ús d'una o varies crides de l'ordre srun, indicada al guió, enviarà treballs paral·lels a altres slurmd. Farà una funció similar a la funcionalitat Interactive Mode.
4. A diferencia del mètode anterior, les comunicacions d'E/S es realitzen de slurmd a slurmctld. Així doncs, cada subtasca comunica directament amb slurmctld. Una vegada finalitzada la tasca, el node slrumd que gestiona l'execució envia a slurmctld que els recursos ja estan disponibles per acceptar noves tasques. Slurmctld envia un procés d'epíleg on s’especifica com ha anat l'execució i els nodes utilitzats responen.

L'ús de guions és útil a l'hora de llençar les tasques al clúster, els quals estan basats en ordres bash d'execució anomenades Scheduler directives. Un exemple podria ser:

#!/bin/bash 
#SBATCH --job-name=test #nom de la tasca
#SBATCH --output=resultat.txt #fitxer de sortida
#SBATCH –N 1 #numero de nodes
#SBATCH -n 8 #numero de cores
#SBATCH --exclusive #recursos exclusius

gcc <arxiu>.c -o tasca # compilar 
srun ./tasca # executar

Per tal d'executar-lo s'ha de realitzar la comanda:

$ sbatch <fitxer_script>

Allocation Mode (salloc)

1. L'usuari executa l'ordre salloc indicant els recursos que requereix. Slurmctld, quan disposa dels recursos sol·licitats, respon a l'usuari amb la credencial d'identificació i la llista de nodes. En aquest punt, els recursos s’assignen a l'usuari però no tenen una tasca assignada. Quan l'usuari executa l'ordre srun s’inicia un procés similar a Interactive Mode. Es fa una petició de treball a Slurmctld, el qual retorna la resposta dels requeriments i permet inicialitzar la tasca.
2. El deamon slurmd del node usuari envia a slurmd els diferents recursos assignats per tal d'iniciar la tasca i es creen els sockets de comunicació per les entrades i sortides estàndards.
3. Una vegada establerta la connexió s’executa la tasca. Els diferents nodes realitzen la computació pertinent i es realitza la comunicació establerta. Quan els nodes acaben la feina assignada s’envia un missatge de finalització. Encara que hi hagi treballs en cua els recursos es mantenen assignats a l'usuari.
4. El node de l'usuari ha d'especificar a slurmctld l'alliberament dels recursos implícitament mitjançant scancel i el número de credencial (en el cas que l'ordre srun s’hagi indicat posteriorment de la salloc). Una vegada finalitzat el procés s’alliberen els recursos i Slurmctld requereix l'epíleg als nodes.

Exemple d'execució:

$ salloc -N5 
$ srun -n10 ./tasca
$ exit

SLURM té la seva pròpia sintaxis per sol·licitar recursos informàtics. Per obtenir una llista complerta d'aquesta sintaxis s’ha d'executar l'ordre: “man <ordre a consultar>”.^[3] A continuació es mostra una petita part de la sintaxis més utilitzada per norma general:^[4]

Estats d'un treball

1. Pending: Treball en cua.
2. Running: Recursos assignats i treball en execució.
3. Suspended: Recursos assignats i treball suspès.
4. Completing:
   1. Cancelled: Treball cancel·lat per l'usuari.
   2. Completed: Treball finalitzat correctament.
   3. Failed: Execució finalitzada incorrectament.
   4. NodeFail: Acabat per fallada en el node.
   5. TimeOut: Acabat per aconseguir el TimeOut.

Prioritat dels treballs

Per a la gestió de la prioritat de treballs SLURM utilitza dues polítiques. La primera de totes és la que ve configurada per defecte FIFO (First In First Out). L'altre alternativa és Multi-factor Job Priority.

FIFO (First In First Out)

Aquesta política de gestió dels treballs consisteix en l'execució del primer treball que li arriba a la cua, per tant, s’executen en funció de l'ordre d'arribada, sense tenir en compte cap altre aspecte.

Per canviar de política de gestió de la prioritat dels treballs, s’ha de modificar del fitxer de configuració el paràmetre PriorityType, que per defecte el seu valor és priority/basic, per tant, cosa que permet la programació de tipus FIFO.

Multi-factor Job Priority

L'altra política que té SLURM per a la gestió de la prioritat dels treballs és molt versàtil. Aquesta política s’anomena Multi-factor Job Priority, per a poder utilitzar-la s’ha de fer modificant el paràmetre mencionat anteriorment, PriorityType de la següent manera: PriorityType=priority/multifactor. Hi ha nou factors en aquesta política que influeixen en la prioritat del treball:

• Age: representa el temps que un treball porta esperant a la cua a ser escollit per a ser executat. En general, com més temps porta un treball a la cua, més gran és aquest factor. Tot i això, un treball que depèn d'un altre, el seu factor no canviarà mentre estigui a l'espera de la finalització del treball del qual té dependència.
• Fair-share: influeix en l'ordre en el qual els treballs d'un usuari són inserits a la cua segons la quantitat de recursos que se li han assignat a l'usuari i els que ja ha consumit.
• Job size: és un factor que està relacionat amb el nombre de nodes o CPU que ha sol·licitat el treball. Es pot configurar per afavorir aquells treballs que siguin més grans, o bé, als més petits a través del booleà PriorityFavorSmall que trobem al fitxer de configuració slurm.conf.
  • PriorityFavorSmall = NO, prioritza als treballs més grans. Com més gran sigui el treball, més gran serà el factor Job size.
  • PriorityFavorSmal = YES, prioritza als treballs més petits. Com menys nodes necessiti, més gran serà el valor del factor, és a dir, aquell treball que només sol·liciti un node, obtindrà el valor màxim, 1.0.
• Partition: a cada partició se li pot assignar una prioritat. Com més gran sigui, major serà la prioritat dels treballs que s'executen en aquesta partició.
• QOS (Qualitat del Servei): associat a la qualitat del servei. Com més gran sigui, major serà la prioritat del treball.
• TRES (Recursos rastrejables): número de recursos TRES sol·licitats/assignats en una partició donada. Com més gran sigui el número de sol·licituds/assignacions, més prioritat.
• Association: factor associat amb cada associació. Com més gran sigui el valor, més prioritat tindrà aquest per a la petició d'aquesta associació.
• Nice: factor que el poden modificar els usuaris per a donar prioritat als seus propis treballs amb un valor positiu. Només aquells usuaris que siguis privilegiats podran assignar un valor negatiu a un treball.
• Site: és un factor que es pot configurar mitjançant scontrol, o bé, a través dels complements job_sunbit i site_factor.

La prioritat dels treballs serà la suma ponderada de tots els factors que se li han indicat al fitxer de configuració "slurm.conf". A més a més, es pot assignar un pes a cada un dels factors per donar més prioritat a un dels factors sobre els altres.

Arxius de configuració

Aquesta pàgina de Viquipèdia mostra Slurm des d'un mode de vista d'usuari. La instal·lació d'Slurm es pot fer de manera automatitzada, on els arxius de configuració contindran valors predeterminats, o manualment. Per tal de fer una configuració adient es recomana entendre el funcionament del Kernel y les característiques del sistema que volem.

Els fitxer que internament Slurm gestiona són utilitzats, en alguns casos, pels dos daemons i altres únicament per Slurmctld. S’utilitzen per gestionar particions, polítiques, plugins, cgrups… El fitxer principal és slurm.conf, el qual defineix característiques com les polítiques de cues, el mètode predeterminat d'executar una tasca, la gestió dels nodes… Altres arxius són burst_buffer.conf, el qual gestiona les opcions específiques de Burst Buffer (emmagatzemen compartit de recursos d'alta velocitat), i acct_gather.conf, que gestiona les opcions dels plugins instal·lats dins el cluster.

Història

Slurm va sorgir de la col·laboració entre Lawrence Livermore National Laboratory, SchedMD, Linux NetworX, Hewlett-Packard i Groupe Bull per resoldre la necessitat de gestionar la càrrega de treball en els entorns de computació d'alt rendiment (HPC).  D’aquesta manera es va començar el desenvolupament de recursos de programari lliure basant-se en la sintaxis i el codi tancat Quadrics RMS. Actualment és un sofisticat gestor de càrrega de treball capaç de satisfer els requisits de molts grans centres informàtics.

Com a dada curiosa es pot destacar que el nom Slurm és una referència al refresc de la sèrie televisiva Futurama.

Alternatives a Slurm

Pels programadors de tasques és important administrar la cua de treballs per cada grup de computadors. Normalment el planificador programarà tasques des de la cua a mesura que els recursos es troben inactius. Alguns sistemes de gestió de cues que poden ser alternativa a Slurm són:

• Portable Batch System (PBS):^[6] PBS optimitza la programació de tasques i la gestió de la càrrega de treball en els entorns de computació d'alt rendiment (HPC), com són els clústers, clouds, i supercomputadors. És un software ràpid, escalable, segur i resistent, a més, és compatible amb totes les infraestructures modernes, middleware i aplicacions.
• IBM Spectrum LSF:^[7] Anteriorment anomenat Platform LSF. Una solució de gestió de càrregues de treball complerta que simplifica HPC amb una millor experiència de l'usuari i administrador, fiabilitat i rendiment a escala.
• Univa Grid Engine:^[8] Anteriorment anomenat Grid Engine d'Oracle Corporation, fins que Univa ho va comprar. Univa Grid Engine ajuda a les organitzacions a millorar el rendiment de les aplicacions, contenidors i serveis, i maximitzar els recursos informàtics compartits en les infraestructures locals, híbrides i a cloud.
• Moab:^[9] De Adaptive Computing, el Moab® HPC Suite es una plataforma de distribució de càrrega de treball que automatitza la programació, la gestió, el monitoratge i la generació d'informes de las càrregues de treball de HPC a gran escala.
• Tivoli Workload Scheduler:^[10] De IBM, el Trivoli Workload Scheduler és un software que planifica, executa i rastreja treballs en varies plataformes i entorns. Té l'objectiu d'administrar els recursos informàtics en grups de computadores per permetre que diversos usuaris els puguin compartir de manera eficient al executar programes paral·lels.
• HTCondor:^[11] Anteriorment anomenat Condor, de la University of Winsconsin-Madison. Es centra en el desenvolupament i implementació de mecanismes per la informàtica d'alt rendiment (HTC).

Referències