Altre proposte: considerazioni .1 Fault tolerance per guasti di tipo crash

Per la rilevazione e la gestione del crash di peer o superpeer si devono considerare in modo accurato le numerose interazioni che avvengono tra i singoli agenti, anche quando appartengono allo stesso peer. Infatti è necessario che lo stato complessivo del sistema venga preservato e che il crash di un nodo non si ripercuota sugli altri.

Per la rilevazione di questo tipo di guasto potrebbe essere utilizzata la tecnica del gossiping in quanto più scalabile e più efficiente all’aumentare delle dimensioni del sistema, mentre per la gestione si dovrebbe valutare caso per caso; per quanto riguarda il ripristino si potrebbe ricorrere, in funzione della causa che ha provocato il crash, alle primitive resetP e resetR che operano a livello di container e main container e che riuscirebbero, quindi, a ripristinare anche la piattaforma JADE e le connessioni da essa utilizzate15. Tuttavia bisognerebbe porre la massima attenzione nell’analisi dei rapporti che intercorrono fra il nodo che ha subito il crash e gli altri nodi.

Ad esempio, nel caso si tratti di un superpeer, bisognerà innanzitutto considerare come debba avvenire il rilevamento del crash e, in secondo luogo, come gestire la struttura della overlay network. Il rilevamento potrebbe avvenire a cura dei due superpeer delle regioni adiacenti e la ristrutturazione della overlay network a cura del server.

Caso particolare è rappresentato dal crash del server che lascerebbe il sistema attuale senza un coordinatore. Nello specifico, sempre a titolo esemplificativo, si potrebbe decidere di implementare una gestione distribuita della struttura della overlay network in modo che il crash del server comporti, eventualmente, solo l’impossibilità di aggiungere nuove regioni alla overlay network16 senza pregiudicare la gestione del guasto di una o più regioni già connesse al sistema.

Un’altra considerazione riguarda il caso che vede una semplice disconnessione temporanea di una regione (del suo superpeer) dalla overlay network. In tal caso si potrebbe prevedere un “bypass” temporaneo della regione che, mentre proseguono le attività locali alla regione stessa, dovrebbe essere aggiunta nuovamente al sistema appena possibile.

Se, poi, si volesse prevedere la possibilità di nominare un nuovo superpeer per la regione, si dovrebbero affrontare diversi aspetti.

Innanzitutto sarebbe utile aver precedentemente provveduto a replicare il main container ed il database del superpeer su almeno un altro peer della regione; altrimenti sarebbe un po’ più complicato per i peer raggiungere un

15 Tutto questo a patto che il nodo attualmente non connesso al sistema sia ancora operativo e raggiungibile.

16 Infatti si presume che un superpeer debba conoscere l’indirizzo ip pubblico di almeno uno dei superpeer che compongono l’overlay network e, nel caso specifico, si suppone che tale superpeer sia il server.

accordo. La replicazione del main container è una funzionalità che viene

offerta da JADE tramite il servizio

jade.core.replication.MainReplicationService - cfr. (Bellifemine, et al., 2004 p. 173-179) - che provvede a mantere costantemente aggiornata ciascuna copia di backup del main container (master). In questo modo, usando la replicazione del main container, la topologia di una regione verrebbe modificata come mostrato nella Figura 4-4.

Poi si dovrebbero considerare alcuni aspetti, fra cui:

- elaborare ed implementare, se necessario, un algoritmo di elezione per la scelta del nuovo superpeer;

- strutturare tutti i peer affinchè siano in grado di aggiornare dinamicamente l’identità del superpeer della propria regione; - risolvere i problemi associati alla presenza del NAT17.

Figura 4-4 – MainReplicationService: topologia di una piattaforma JADE senza (sinistra) e con (destra) la replicazione del main container.

4.5.2 Backward recovery

Il ripristino dello stato di un sistema rappresenta un argomento davvero molto complesso che non può certo essere affrontato se non con una trattazione molto accurata. Pertanto in questo breve paragrafo si

17 Il NAT, infatti, considera costante nel tempo l’identità IP locale del superpeer della regione ed è proprio verso tale IP che inoltra (port forwarding) le comunicazioni in ingresso dirette a questo particolare peer. Nel caso in cui ne venga eletto un altro, sarebbe necessario che il port forwarding venga ridefinito o che sia stata prevista la presenza di un sottoinsieme di peer della regione che possono candidarsi a superpeer.

riportano solo alcune idee che potranno o meno convergere in una futura realizzazione.

Affinchè un sistema sia tollerante ai guasti (e ciò non significa che sia possibile garantire una completa trasparenza ai guasti) è necessario che i componenti che verificano una situazione di fallimento possano tornare in un precedente stato stabile (backward recovery) o portarsi in un nuovo stato da cui riprendere l’esecuzione (forward recovery)18.

Nel caso del backward recovery è necessario, quindi, memorizzare lo stato dei componenti tramite checkpoint e log in modo da poterne tentare il ripristino19 (non è sempre possibile ripristinare uno stato precedente).

Dal momento che di solito i componenti di un sistema sono molto interconnessi, è necessario individuare e memorizzare uno stato consistente a livello globale che tenga conto delle comunicazioni interocorse fra i componenti.

In (Araragi, 2005), ad esempio, si fa riferimento all’algoritmo di Chandy e Lamport (Chandy, February 1985) e si propone un approccio leggermente diverso asserendo che, nonostante questo algoritmo non interferisca col funzionamento del sistema durante il salvataggio dello stato globale, tuttavia non sia applicabile a sistemi dinamici (in cui gli agenti vengono creati e terminati dinamicamente) né a sistemi troppo estesi (dal momento che il salvataggio coinvolge tutti gli agenti del sistema).

Il metodo proposto suggerisce la definizione di “partial snapshot” (salvataggio dello stato di un sottoinsieme degli agenti del sistema) e di “comunication dependecy set” (cDS) di un agente (l’insieme degli agenti con cui ha comunicato dopo l’ultimo salvataggio dello stato). Quindi si spiega che, dal momento in cui viene avviato il processo che si occupa periodicamente di salvare lo stato del sistema, vengono salvati dei partial snapshot. Nel momento in cui un agente subisce un guasto, vengono

18 Un esempio, cfr. (Tanenbaum p. 356-357), di backward recovery è la richiesta di ritrasmettere un pacchetto perso durante una comunicazione; un esempio di forward recovery è l’utilizzo di un metodo (erasure correction) con cui si effettua la ricostruzione di un pacchetto perso a partire da un insieme di pacchetti ricevuti correttamente (a patto di utilizzare una codifica opportuna come, per esempio, quella di Reed-Solomon).

19 Si ricorda che nel CAPITOLO 3 sono stati introdotti degli elementi utili ad un miglioramento del sistema in questa direzione: ad esempio gli stati pFAILURE e rFAILURE, le primitive downP e downR (a livello di peer e regioni), le primitive resetP e resetR (a livello di container e main container) e l’add-on Persistence (primitive SaveAgent e LoadAgent a livello dei singoli agenti).

ripristinati individualmente solo gli stati di quegli agenti che sono direttamente o indirettamente correlati (a livello di comunicazioni) all’agente fallito (Figura 4-6).

Figura 4-5 – Backward recovery per tutti gli agenti.

Figura 4-6 – Backward recovery di un cDS.

Per quanto riguarda il sistema che si sta progettando, si noti comunque che, a prescindere da quale strategia di recovery si scelga, non rappresenta certo una situazione poco problematica voler introdurre allo stato attuale di realizzazione un meccanismo del genere: infatti la situazione ideale avrebbe voluto che tale meccanismo venisse previsto fin dalle fasi primordiali del progetto.

CAPITOLO 5

Scelte

implementative

In questo capitolo viene presentato il nuovo sistema prima da una prospettiva abbastanza ampia e poi molto più dettagliatamente: a partire dai componenti che sono stati realizzati, fino alle interazioni che avvengono fra di essi; dalle soluzioni adottate per l’implementazione delle primitive di amministrazione, alle strutture che ne gestiscono l’esecuzione; dai protocolli di comunicazione per il trasferimento extra-regione delle tranche, ad alcune considerazioni sul collaudo e sugli sviluppi futuri del nuovo sistema