tesi di laurea Rilevazione dei fallimenti nel sistema operativo open source Linux per applicazioni critiche Anno Accademico 2006/2007 relatori Ch.mo prof. Stefano Russo Ch.mo prof. Domenico Cotroneo candidato Roberto Natella Matr. 885/99
1/12 Cos è un fallimento? Un sistema complesso è tipicamente costituito da più sottocomponenti, anche di terze parti (COTS( Component Off The Shelf), da cui viene a dipenderne l affidabilitl affidabilità COTS Sistema Interfaccia COTS Errato! Servizio Progettazione scorretta, errori nella programmazione o nella configurazione, documentazione disallineata Sotto determinate condizioni la porzione di codice guasta,, se eseguita, può portare un sistema a non comportarsi come richiesto dalle sue specifiche Un guasto software nel codice (un bug!) int main() {... } Il sistema fallisce
2/12 Perché rilevare i fallimenti? 1. Le condizioni di attivazione di un guasto possono essere così complesse da sfuggire al testing (guasti transienti) 2. Occorre ridurre l incidenzal dei guasti per le applicazioni particolarmente critiche, che ricorrano a COTS non affidabili 3. La rilevazione della presenza di un fallimento è il presupposto per qualunque tecnica di recupero del sistema E necessario un meccanismo di rilevazione che possa essere utilizzato zato per sistemi complessi,, tale che: Permetta di incrementare la capacità dei meccanismi di logging standard del sistema Non siano richieste sostanziali modifiche al sistema, nén interferisca con il suo funzionamento Sia sufficientemente generale
3/12 Quali sono i sintomi di un fallimento? Idea: determinare la presenza di fallimenti osservando le variazioni da essi indotte su variabili significative del sistema operativo Utilizzo di CPU Frequenza chiamate di sistema Segnali UNIX Letture e scritture su disco Trasmissione e ricezione di pacchetti Il confronto tra più esecuzioni senza e con fallimenti ha evidenziato che (in media) i fallimenti incidono sulle operazioni di I/O Numero medio di eventi Senza fallimenti Con fallimenti Ampiezza della finestra temporale
4/12 Una strategia per la rilevazione 1. Un fallimento potrebbe essere rilevato confrontando il numero medio di eventi osservato su una finestra abbastanza piccola col numero atteso (sconosciuto!) che si avrebbe se l esecuzione fosse corretta 2. Il numero medio di eventi atteso per una finestra piccola può essere approssimato con quello su una finestra più ampia che la contiene 3. Il numero medio di eventi su una finestra ampia è uguale in ambo i casi con e senza fallimenti 4. Le osservazioni su una finestra piccola e grande sono confrontabili per effettuare la rilevazione Numero medio di eventi Senza fallimenti 1 Con fallimenti Ampiezza della finestra temporale 2 4 3
5/12 Un algoritmo per la rilevazione 1. Periodicamente, ad intervalli temporali di ampiezza T,, viene valutato il numero medio di eventi (throughput( throughput) ) X(t i ) di un certo tipo occorso in quell intervallo 2. Il valore atteso per l intervallol corrente è stimato considerando la media degli N campioni precedenti 3. Il throughput campionato viene confrontato con il valore atteso 4. Se il confronto supera di k volte la deviazione standard per l intervallol corrente (anch essa stimata dai campioni precedenti) un fallimento viene rilevato 5. In tal caso, viene generata una segnalazione di fallimento
6/12 La taratura dell algoritmo Ricerca di parametri T, N e k ottimi Una procedura euristica; si determina prima il T tale che: riduca le oscillazioni dovute a fattori secondari (e.g. scheduling I/O e processi) il campionamento non sia troppo grossolano (variazioni repentine tra campioni successivi) Si vagliano diversi valori di N: per ciascun N si valuta, per ogni campione X(t i ), di quante volte k i la dev. std. è stata superata scelta del valore N che riduce il massimo k i ottenuto T=0.1s N=10 k>6 k i t T=1s T=5s throughput N=30 k=5 t
7/12 Dependability benchmarking Utilizzo di una applicazione distribuita, su una piattaforma middleware per applicazioni critiche (CARDAMOM) Il middleware fornisce funzionalità per la tolleranza ai guasti (ridondanza, monitoraggio) Faultload a livello del sistema operativo e dell applicazione presso il server primario Dalla letteratura esistente, si è assunto come modello dei guasti del S.O. il passaggio di valori errati dai driver al resto del kernel Dall analisi analisi delle specifiche del servizio di fault tolerance del middleware,, sono dedotti i fallimenti attesi a livello applicativo Valutazione di coverage e latenza dei log Client1 Client2 Client3 Server (primario) Server (backup) Server (backup) Middleware monitoring Alterazione dei parametri delle funzioni nella interfaccia tra il kernel e i driver mediante bit-flip Mutazioni in diversi punti del codice sorgente che inducono: 1. Crash di un processo 2. Hang di un processo
8/12 Valutazione sperimentale (1) Coverage: : la percentuale di fallimenti correttamente rilevati Faultload a livello del S.O. Esistono dei casi in cui l algoritmo rileva dei fallimenti non loggati dal S.O. L incremento relativo della coverage è maggiore se si considerano i fallimenti che producono un diniego del servizio (+20%) Nella maggior parte dei casi non loggati,, il fallimento del S.O. ha comportato il blocco completo dell esecuzione esecuzione Senza failure detector Senza failure detector Tutti i fallimenti Diniego di servizio Con failure detector Con failure detector
9/12 Faultload di livello applicativo Valutazione sperimentale (2) L algoritmo di rilevazione ha consentito di rilevare la gran parte dei fallimenti dovuti alla applicazione I risultati e l osservazione diretta confermano la ipotesi iniziale sull incidenza dei fallimenti sulle operazioni di I/O throughput Senza failure detector Crash del processo Con failure detector Hang di un thread t
10/12 Valutazione sperimentale (3) Latenza: : il ritardo tra l occorrenzal e la rilevazione di un fallimento In tutti i casi in cui un fallimento è stato rilevato dall algoritmo, algoritmo, la latenza è risultata in media nell ordine di un secondo La latenza del S.O. e della piattaforma middleware,, laddove è stata inferiore al secondo (low( log latency), è risultata in media migliore dell algoritmo Esistono diversi casi in cui la latenza del S.O. e del middleware sono state estremamente più elevate (high( log latency) La latenza dell algoritmo è anche legata al periodo di campionamento T Failure detector S.O. 0.403760 s 0.036916 s Failure detector Middleware 0.654069 s 0.205902 s
11/12 Valutazione sperimentale (4) L algoritmo e l applicazionel sono stati eseguiti in assenza di fallimenti per un lungo periodo di tempo (64h) Un elevato tasso di falsi positivi è stato riscontrato (35.5 f.p./h)./h) Numerosi falsi positivi si ripetono ad intervalli regolari multipli esatti di un minuto (e.g. 1min, 5min, 10min); è possibile presupporre l esistenzal di fattori sistematici che innescano l algoritmo l (e.g. variazioni del carico) 200 150 100 50 0 1s Istogramma dei tempi di interarrivo dei falsi positivi rispetto alle letture dal disco 1m 2m 5m10m 160 140 120 100 80 60 40 20 0 1s Istogramma dei tempi di interarrivo dei falsi positivi rispetto alla ricezione di pacchetti 1m 2m 5m 10m
12/12 Conclusioni L algoritmo sviluppato è in grado di sfruttare la conoscenza a priori che abbiamo sui più comuni modi di fallimento (e.g. crash, hang, )) per sopperire alle lacune dei meccanismi di logging standard Permette di incrementare la coverage sia rispetto ai fallimenti del sistema operativo che delle applicazioni La rilevazione dei fallimenti avviene in tempo contenuto, consentendo eventualmente di intervenire sul sistema Sviluppi futuri Integrazione dell algoritmo di rilevazione in meccanismi di recupero e trattamento dei fallimenti (e.g. software diagnosis) Introduzione di tecniche per il filtraggio dei falsi positivi Automatizzazione della taratura dell algoritmo