Refactoring parallelizzazione per HPC

[brancomat]

La coordinazione tra arkimaps e i suoi worker che fanno rendering è praticamente tutta nel file system: i dati sono nella working directory, la descrizione di un'immagine da generare è una piccola struttura dati serializzabile.

Dato un filesystem condiviso, il rendering può essere fatto da un numero arbitrario di processi, e pure su un numero arbitrario di macchine.

Riprogettiamo la cosa in base a queste premesse?

Originally posted by @spanezz in https://github.com/ARPA-SIMC/arkimaps/issues/128#issuecomment-1350653683

[dcesari]

Per fare questo prenderei in considerazione l'integrazione con lo scheduler HPC slurm, che non è l'unico al mondo ma il più open ed usato su tutti i cluster a cui abbiamo accesso (nostro, Cineca, ECMWF).

Se ci mettiamo in questa ottica, è lo scheduler a preoccuparsi di riservare le risorse e mettere a disposizione strumenti per ditsribuire i processi tra nodi. v. ad esempio https://slurm.schedmd.com/man_index.html comandi sbatch e srun o https://slurm.schedmd.com/quickstart.html

I possibili approcci che vedo sono molteplici:

• lanciare n3 job monoprocesso e monothread (eventualmente con richiesta di riservare la memoria necessaria), ci pensa lo scheduler a compattarli su un numero congruo di nodi di calcolo multicore (i nostri sono a 16 o 32 core) eventualmente facendo aspettare in coda quelli che sono di troppo rispetto alle risorse di cpu e memoria disponibili
• lanciare n2(<n3) job monoprocesso multithread richiedendo allo scheduler un numero di core pari al numero di thread che vogliamo utilizzare, è circa come sopra, ma ogni processo ha la garanzia di avere il numero di core richiesti liberi da altri processi
• lanciare un solo megajob in cui si richiedono n3 core, che potrebbero stare anche su nodi diversi, specificando che saranno dstribuiti su n2 processi, ciascuno dei quali avrà a disposizione ~n3/n2 core sullo stesso nodo; in questo caso viene d'aiuto il comando srun per lanciare i processi sui vari nodi, e ogni processo ha a disposizione delle variabili d'ambiente, $SLURM_NODEID e $SLURM_LOCALID nello specifico, per sapere chi è e cosa deve fare.

Il primo approccio ha più overhead per lo scheduler ma secondo me è più flessibile perché usa le risorse al massimo, mentre negli altri due, soprattutto nel terzo, se non abbiamo uno scheduling interno dei thread nell'applicazione, tutte le risorse restano occupate finché non esce l'ultimo renderer e si impedisce l'esecuzione di nuovi job.

L'argomento è complesso, magari vale la pena sentirsi (ma non so quando).

[dcesari]

Aggiungo due info: nel renderer potremmo assumere di essere in ambiente batch slurm se è definita ad es. la variabile d'ambiente $SLURM_ID e in tal caso il numero di thread massimo da utilizzare per quel processo è $SLURM_CPUS_PER_TASK (+ eventuali thread di controllo che non succhiano cpu), non il numero di core della macchina, non credo che alla fine dei conti ci sia molto altro da fare.

[dcesari]

Quanto scritto in https://github.com/ARPA-SIMC/arkimaps/issues/128#issuecomment-1351423706 va nella direzione del primo approccio, che non richiede ulteriore consapevolezza dell'ambiente batch da parte di arkimaps.