Un pool di pc distribuiti di volontari presenta un ambiente ostile per l’esecuzione di codice parallelo a causa della variabilità ed eterogeneità dei sistemi, delle reti e anche al causa della presenza di errori. I checkpoint e la replicazione del lavoro (quorum) non sono sufficienti nel caso in cui si voglia avere una piattaforma distribuita parallela affidabile, e il progetto Volpex sta mettendo in campo alcune soluzioni innovative per cercare di ovviare ai problemi sopra descritti.
Il modello di programmazione introdotto è basato su chiamate Put/Get unilaterali per creare un ambiente globale condiviso che lavori senza soluzione di continuità con processi replicati: processi ridondanti autonomi, dove un processo può avere più repliche indipendenti simultanee che possono essere create su richiesta, rigenerate da un checkpoint o terminate, senza coordinamento con altri processi o repliche.
Una serie di tecniche sono utilizzate per rendere possibile tutto questo: selezione dei nodi, per minimizzare la possibilità di errore durante l’esecuzione; processi ridondati per fornire resistenza all’errore, checkpoint per permettere il roll-back dell’applicazione; monitoraggio dell’heartbeat e hot spares per ripartenze veloci. Checkpoint e replicazione non sono più concetti separati, ma un unico ambiente rendendo in tal modo i checkpoint cooperativi.
Il framework Volpex è stato integrato all’interno del middleware Boinc per poter utilizzare un ambiente di calcolo distribuito già consolidato e per ampliarne l’uso e le potenzialità. Il server Boinc si occupa, immagine 1, dell’esecuzione dei task come il disbrigo dei binari e dei dati agli host e la verifica e la raccolta dei dati, mentre il server Volpex è utilizzato per mandare/ricerve checkpoint e per attivare/disattivare gli host.
Gli host spare sono “reclutati” prima del tempo cosicchè l’esecuzione non si blocchi quando sia necessario un altro host e il server Boinc sia costretto ad aspettare di essere contattato da un host adeguato. Quando un numero sufficiente di nodi attivi è stato reclutato, inizia l’esecuzione del lavoro su tutti gli host e, se necessario, vengono attivati gli hot spares.
Quando un processo è considerato morto od obsoleto, viene terminato (se possibile) e viene attivato l’host spare adeguato per rimpiazzarlo.
Il progetto è, come si può intuire, ALTAMENTE sperimentale con tutte le conseguenze del caso: poco costante la quantità di lavoro, presenza di errori, ecc, ecc.
Parte scientifica
Alcuni programmi sono stati sviluppati per essere utilizzati con il framework Volpex: Sieve of Eratosthenes (SoE) e Replica Exchange Molecular Dynamics (REMD) sono i due più importanti e più usati.
Sieve of Eratosthenes è un programma per la ricerca dei numeri primi, che utilizza Volpex per distribuire un blocco di numeri primi da valutare a tutti i processori in maniera parallela. Viene utilizzato principalmente per testare la piattaforma.
Replica Exchange Molecular Dynamics (REMD) è un applicativo reale utilizzato, in collaborazione con il gruppo di ricerca Cheung (https://mynsm.uh.edu/groups/cheunggroup/) per il folding proteico: ogni nodo calcola un pezzo di simulazione molecolare a diverse temperature utilizzando il programma AMBER (http://ambermd.org/). Nell’esperimento REMD ogni temperatura replicata (termine specifico di Amber) rappresenta un processo che inizia facendo girare le simulazioni per quella determinata temperatura.
Tutti i codici (di SoE e di REMD) sono eseguiti su 32 processi (task) e solo una istanza è assegnata ad un host, quindi un totale di 32, 64 o 96 host sono impegnati in base al fattore di replica (quorum) 1, 2 o 3 rispettivamente. Se i processi nelle applicazioni comunicano regolarmente, il volume e la frequenza della comunicazione è relativamente basso e il rapporto computazione/comunicazione è alto. Per le configurazioni che sono state impostate, un calcolo standard (su buoni host senza errori) è di circa 100 secondi per SoE e di 4,5 ore per REMD.
Entrambe le applicazioni sono fatte girare 10 volte per ogni scenario e ogni scenario viene costruito basandosi su una serie di parametri (per REMD, per esempio, ogni calcolo per singolo scenario viene completato in media tra le 50 e le 100 ore). Gli scenari possibili sono combinazioni dei seguenti parametri:
- 1) REMD senza replica, con 2 repliche (2 istanze del processo) e 3 repliche
- 2) REMD con e senza soglia basata sulla selezione dei nodi
- 3) REMD con un checkpoint nominale a 15 minuti e a 1 ora.
Le simulazioni finora condotte hanno evidenziato un netto miglioramento in termini di riduzione della varianza del tempo di esecuzione e delle performance generali delle applicazioni distribuite agli host.
