Un fallimento, failure, è definito come l’evento in corrispondenza del quale il sistema cessa di fornire un servizio corretto.
In generale un sistema non fallisce sempre alla stessa maniera: le modalità di fallimento prendono il nome di failure modes ed implicano la non correttezza del servizio secondo diversi punti di vista.
Classificazione dei failures
FAILURES
FAILURES
FAILURES
Un sistema in cui si verificano esclusivamente fallimenti benigni (minor failures) è un sistema fail-safe.
L’attivazione di un guasto provoca la transizione del sistema da uno stato di corretto funzionamento (correct behavior) ad uno stato improprio (error);
La rilevazione di un errore e le opportune operazioni di ripristino riportano il sistema ad operare in maniera corretta.
Un errore può degenerare in un fallimento mediante propagazione all’interfaccia utente.
Esistono diversi approcci per incrementare il grado di dependability di un sistema: la scelta di una particolare tecnica è legata alla natura del sistema e al particolare attributo di dependability che si è interessati a massimizzare.
Le tecniche di fault avoidance sono orientate a minimizzare la probabilità di occorrenza dei fallimenti.
Le tecniche di fault tolerance mirano alla minimizzazione delle conseguenze dei guasti sul sistema e dunque ad evitare che essi possano degenerare in fallimenti (failure avoidance).
Un sistema fault tolerant è un sistema in grado di continuare ad essere operativo, pur se in condizioni degradate, nonostante l’occorrenza di guasti.
Rimozione dell’errore
Fault handling
Alle procedure di fault handling seguono operazioni di manutenzione correttiva, corrective maintainance, per riparare -offline- i componenti isolati perchè guasti.
Le tecniche di fault removal mirano all'individuazione degli errori ed alla rimozione di eventuali guasti.
Ha l’obiettivo di stimare il numero corrente, la futura incidenza e le conseguenze dei fault.
Fault forecasting approaches
*nel caso di fallimenti indipendenti delle repliche. L’isolamento fisico ed elettrico dei processori in un sistema distribuito assicura l’indipendenza dei fallimenti delle repliche.
Introduce nuove problematiche
RM: mantiene le copie fisiche degli oggetti replicati. FE: gestisce le richieste dei client e contatta gli RM Failure model: Crashes only.
There is at any time a single primary RM and one or more secondary (backup, slave) RMs.
FEs communicate with the primary which executes the operation and sends copies of the updated data to the result to backups.
if the primary fails, one of the backups is promoted to act as the primary.
Se la replica primaria fallisce, il sistema è ancora consistente se una delle repliche diventa primaria
La replicazione passiva non è scalabile. La replica primaria costituisce un “bottleneck” dell’intero sistema.
Alcune strategie di miglioramento delle prestazioni consistono nel ridurre il carico della replica primaria inviando le richieste di read direttamente alle repliche di backup.
Ogni replica deve avere un comportamento deterministico.
Tutte partono dallo stesso stato ed eseguono le stesse richieste nello stesso ordine.all start in the same state and perform the same in the same order so that their state remains identical.
Un fallimento di un replica non ha alcun effetto sulle prestazioni del sistema poiché le altre continuano normalmente la loro esecuzione.
Gli FE possono implmentare strategie di aggiudicazione (voting), potendo tollerare fault bizantini.
Un metodo generale per l’implementazione di servizi tolleranti ai guasti nei sistemi distribuiti
Si basa sull’assunzione che ogni replica possa essere modellata come una state machine.
Una state machine consiste di un insieme di variabili di stato e di un insieme di comandi. Ogni comando è implementato da un programma deterministico. L’esecuzione di un comando è atomica rispetto agli altri.
Dalla definizione segue:
L’output di una state machine è completamente determinato dalla sequenza di richieste che essa processa in maniera indipendente dal tempo e da altre attività nel sistema.
In altre parole, il comportamento di una state machine è deterministico (e quindi indipendente dal carico del sistema e dal tempo di trasmissione delle richieste).
Si considerano due tipologie di fallimento di un componente del sistema distribuito:
Nei sistemi distribuiti è difficile esprimere la capacità di un sistema di tollerare i guasti attraverso misure quali MTBF, MTTF ed altre misure statistiche [Sieworek and Swarz 1982].
Per tali sistemi si utilizza un modo alternativo. In particolare un sistema distribuito su un insieme di componenti si dirà t fault tolerant se esso soddisfa le sue specifiche anche nel caso in cui si verifichi il fallimento di t componenti in un dato intervallo di tempo.
Un versione t fault tolerant di una state machine(sm) può essere realizzata mediante l’utilizzo della replicazione (si parla in questi casi quasi sempre di replicazione attiva);
Al fine di tollerare fallimenti Bizantini, una t fault tolerant sm dovrà essere costituita da almeno 2t+1 repliche (3t+1 nei sistemi parzialmente sincroni). A tal uopo si utilizzerà un algoritmo di voting di maggioranza;
Se i componenti esibiscono solamente fail-stop failure, allora saranno necessarie t+1 repliche.
Al fine di implementare un sm t fault tolerant bisogna assicurare il seguente requisito:
L’Agreement governa il comportamento di un client nell’interazione con le repliche.
L’Order governa, invece, il comportamento delle repliche nel processare le richieste dei client.
Si noti che:
L’agreement può essere realizzato da un qualunque protocollo che permette ad un Transmitter di inviare ad un insieme di Processor dei messaggi rispettando i seguenti vincoli:
Esempi
L’Order può essere assicurato assegnando un identificativo unico a tutte le richieste ed assicurando che le richieste vengano processate mediante lo ordine relativo agli ID. Inoltre bisogna assicurare che o tutte le repliche ricevono una richiesta o nessuna (atomicità).
Tecniche implementative
Sebbene l’approccio delle state machine costituisca una pietra miliare nel campo della fault tolerance dei sistemi distribuiti esso è di difficile applicazione.
È applicabile solo a programmi (repliche) relativamente semplici che sono eseguiti in Sistemi Operativi “scariche” o comunque da caratterizzati da un comportamento deterministico.
Sfortunatamente Il comportamento puramente deterministico è difficilmente riscontrabile nella pratica. Sorgenti di non determinismo possono trovarsi nell’utilizzo di timer locali, system call di SO, funzioni specifiche di un processore, primitive di condivisione della memoria, multithreading… [Felber and Narasimhan 2003].
Sebbene l’approccio delle state machine costituisca una pietra miliare nel campo della fault tolerance dei sistemi distribuiti esso è di difficile applicazione.
È applicabile solo a programmi (repliche) relativamente semplici che sono eseguiti in Sistemi Operativi “semplici” o comunque caratterizzati da un comportamento deterministico.
Sfortunatamente Il comportamento puramente deterministico è difficilmente riscontrabile nella pratica. Sorgenti di non determinismo possono trovarsi nell’utilizzo di timer locali, system call di SO, funzioni specifiche di un processore, primitive di condivisione della memoria, multithreading… [Felber and Narasimhan 2003].
Il non determinismo è un problema inevitabile e “challenging” per la realizzazione di sistemi fault tolerant.
Per la replicazione attiva esso è di cruciale importanza al fine di mantenere consistente lo stato delle repliche.
La replicazione passiva è quella che spesso viene percepita come la soluzione da applicare al caso di applicazioni non deterministiche (ma ciò non è sempre possibile soprattutto se il comportamento dei componenti dipende da eventi esterni alle repliche).
1. Caratterizzazione dei sistemi distribuiti
2. Modelli di sistemi distribuiti
3. Tempo e sincronizzazione nei Sistemi Distribuiti
4. Stato globale nei Sistemi Distribuiti
5. Problemi di consenso nei sistemi distribuiti
7. Algoritmi di mutua esclusione nei sistemi distribuiti
8. Algoritmi di elezione nei sistemi distribuiti
10. Il Network File System di SUN Microsystems
11. AFS (Andrew File System) e GFS (Google File System)
12. Transazioni e controllo di concorrenza
13. Transazioni
15. Affidabilità (dependability) dei sistemi software distribuiti
16. Affidabilità dei sistemi software distribuiti
17. Software Faults
18. Classificazione e analisi dei difetti software