Crash di un nodo server che ospita una tabella :

 

 

Se le tabelle sono presenti nel sistema in unica copia, la tabella allocata sul nodo che ha subito un fault sarà irrecuperabile (almeno finché il nodo non sarà stato ripristinato) e un agente che vuole interrogarla fallirà.

 

Per garantire una fault tollerance si prevede una duplicazione delle tabelle: il n° delle copie di ogni tabella varierà in base all'importanza, alla dimensione e/o ad altre caratteristiche particolari della singola tabella.

 

Questa scelta comporta naturalmente una maggiore occupazione delle risorse del sistema (le copie di una stessa tabella saranno allocate su nodi distinti del sistema).

 

 

Si possono avere 2 possibili casi relativi alla gestione delle tabelle duplicate:

 

  1. "Copia principale" à MASTER e "copie fredde" à SLAVE :

 

Emerge la necessità di coordinamento, che comporta una continua osservazione del sistema per poter cogliere informazioni relative a guasti del sistema.

 

Il problema principale è quello relativo al forte traffico di comunicazione , al carico di monitoraggio continuo del sistema e di coordinamento tra gli "Slave" che si vuole evitare per non appesantire troppo il sistema.   

 

 

 

 

2. Copie tutte ATTIVE

 

Le copie di una stessa tabella presenti nel sistema sono tutte attive, quindi possono essere consultate indifferentemente. Più agenti che operano nel sistema in un certo istante hanno quindi la possibilità di interrogare contemporaneamente copie diverse della stessa tabella (localizzate su nodi distinti).

Questo comporta da una parte l'esigenza di un coordinamento tra le varie copie, che devono essere sempre consistenti; dall'altra parte si ha una velocizzazione nella ricerca di una tabella (più copie attive presenti sul sistema aumentano la possibilità di trovare una copia con una ricerca più breve).

La nostra scelta ricade sulla seconda possibilità, considerando l'obiettivo di semplicità di organizzazione del sistema.

 

 

 

 

 

 

    CASI DI FAULT