UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II

Transcript

1 UNIVERSITÀ DEGLI STUDI DI NAPOLI FEDERICO II FACOLTÀ DI INGEGNERIA CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA INFORMATICA (CLASSE DELLE LAUREE SPECIALISTICHE IN INGEGNERIA INFORMATICA N.35/S) DIPARTIMENTO DI INFORMATICA E SISTEMISTICA ELABORATO DI LAUREA Analisi sperimentale di RELATORE Ch.mo Prof. Stefano Russo CANDIDATO Berniero Volzone Matr.: 885/288 CORRELATORI Ing. Roberto Natella Ing. Roberto Pietrantuono ANNO ACCADEMICO 2008/2009

2 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica Tesi di laurea specialistica Analisi sperimentale di Anno Accademico 2008/09 Relatore Ch.mo Prof. Stefano Russo Correlatori Ing. Roberto Natella Ing. Roberto Pietrantuono Candidato Berniero Volzone matr.: 885/288

3 Indice Introduzione 1 Capitolo 1 Dependable Computing e software aging Dependability dei sistemi informatici Fallimenti, errori e guasti Fallimenti Errori Guasti Guasti software Metodi per migliorare la dependability del software Software aging Metodi per l analisi dell aging Analytical modeling Measurement-Based Approach Software rejuvenation 36 Capitolo 2 Software aging nei sistemi operativi Sistemi operativi e dependability Studi correlati 43 Capitolo 3 Instrumentazione del sistema operativo Linux Struttura del sistema operativo Linux 50 I

4 3.1.1 Sottosistemi del kernel Process management Memory management File system e device control Networking Process file system Tracepoint nel kernel Linux Individuazione delle informazioni di interesse Instrumentazione dei tracepoint e definizione del tracer Rappresentazione dei dati relativi al tempo di latenza Scrittura delle informazioni di sistema su file: mytracer-rep 78 Capitolo 4. Procedura sperimentale Design of Experiments (DoE) Software aging nel kernel Linux: procedura sperimentale Progettazione degli esperimenti Analisi di software aging Raccolta dei dati e preprocessing Test di Mann-Kendall e metodo di Sen Principal component analysis 97 Capitolo 5. Sperimentazione ed analisi dei risultati Esecuzione del test Individuazione dei trend di aging Principal component analysis Valutazione dei risultati 110 Conclusioni e sviluppi futuri 115 Bibliografia 118 II

5 Indice delle figure Figura 1.1: diagramma di stato failure-repair. 6 Figura 1.2: diagramma di stato failure-repair con politica di tolleranza ai guasti. 9 Figura 1.3: relazione fra MTTF, MTBF ed MTTR. 10 Figura 1.4: relazione fra fallimenti, errori e guasti. 11 Figura 1.5: tassonomia di fallimenti. 15 Figura 1.6: classi di fault elementari. 17 Figura 1.7: classi di fault combinate. 18 Figura 1.8: metodi di fault tolerance. 24 Figura 1.9: aging-related bugs. 27 Figura 1.10: modello semi-markoviano. 30 Figura 1.11: modello semi-markoviano modificato. 31 Figura 1.12: confronto tra i modelli semi-markoviano e semi-markoviano modificato. 32 Figura 1.13: modello MRSPN di software rejuvenation. 33 Figura 1.14: esempio di approccio measurement-based. 35 Figura 1.15: approcci di software rejuvenation. 38 Figura 2.1: albero MIB per il modulo PFM del tool di monitoring SNMP. 44 Figura 2.2: monitoring delle informazioni UNIX tramite SNMP. 45 Figura 3.1: architettura fondamentale del SO Linux. 52 Figura 3.2: esempio di system call nel SO Linux. 53 Figura 3.3: transizione tra user e kernel mode per l esecuzione di due processi. 55 Figura 3.4: accesso alla memoria nella commutazione tra user e kernel mode. 56 III

6 Figura 3.5: sottosistemi del kernel Linux. 57 Figura 3.6 strumento di monitoring. 72 Figura 3.7 istogramma della latenza della system call open catturata in un unico evento. 75 Figura 3.8 istogramma della latenza della system call open catturata in eventi successivi. 76 Figura 3.9a formattazione dei dati contenuti nel file mem.txt. 79 Figura 3.9b formattazione dei dati contenuti nel file proc.txt. 79 Figura 3.9c formattazione dei dati contenuti nel file disk.txt. 80 Figura 3.9d formattazione dei dati contenuti nel file net.txt. 80 Figura 3.9e formattazione dei dati contenuti nel file filesys.txt. 80 Figura 4.1 modello procedurale per lo studio del software aging. 88 Figura 4.2 processo di elaborazione delle informazioni di sistema. 91 Figura 5.1 procedura sperimentale. 101 Figura 5.2 procedura di analisi dei dati. 102 Figura 5.3: variazione della memoria fisica libera disponibile. 104 Figura 5.4: trend relativo all indicatore di memory depletion. 105 Figura 5.5: trend relativo all indicatore di throughput loss del sottosistema memory management. 106 Figura 5.6: trend relativo all indicatore di time loss del sottosistema memory management. 106 Figura 5.7: composizione della prima e della terza PC relative al sottosistema file system I/O. 111 Figura 5.8: composizione della prima e della seconda PC relative al sottosistema disk I/O driver. 111 Figura 5.9: composizione della prima e della seconda PC relative al sottosistema memory management. 112 Figura 5.10: composizione della prima PC relativa al sottosistema process management. 112 IV

7 Indice delle tabelle Tabella 1.1: metriche per la valutazione della dependability. 10 Tabella 3.1: informazioni di tracing per i sottosistemi di memory management e process management. 69 Tabella 3.2: informazioni di tracing per i sottosistemi di network I/O e file system I/O. 69 Tabella 3.3: informazioni di tracing per il sottosistema disk I/O driver. 70 Tabella 5.1: sintesi dei risultati ottenuti. 107 Tabella 5.2: coefficienti delle componenti principali relative al sottosistema disk I/O driver. 109 Tabella 5.3: coefficienti delle componenti principali relative al sottosistema process management. 109 Tabella 5.4: coefficienti delle componenti principali relative al sottosistema file system I/O. 110 Tabella 5.5: coefficienti delle componenti principali relative al sottosistema memory management. 110 Tabella 5.6: parametri di workload più significativi per ogni trend e per ogni sottosistema. 113 V

8 Introduzione Il presente lavoro di tesi è frutto di un attività di ricerca e sperimentazione, svoltasi presso il laboratorio CINI (Consorzio Interuniversitario Nazionale per l Informatica) della Federico II, con lo scopo di analizzare il fenomeno di aging nel sistema operativo Linux. Il software aging può essere definito come il graduale accumulo di potenziali condizioni di fault durante l esecuzione di un programma, che conduce ad una degradazione nelle prestazioni del sistema ed eventualmente al crash [1]. Per tale ragione, lo studio approfondito di soluzioni che assicurino elevata affidabilità non può prescindere dall analisi dell invecchiamento software, che è stata così incoraggiata dal diffondersi delle applicazioni mission/business critical. Gli studi sul software aging e sulle correlate tecniche di rejuvenation sono relativamente recenti. Essi risalgono, infatti, alla metà degli anni 90 e si concentrano, per la maggior parte, su modelli analitici e statistici atti alla descrizione del fenomeno. Negli ultimi anni, tuttavia, si sono diffuse una miriade di applicazioni aventi esigenze sempre più critiche in termini di affidabilità. Mentre le tecniche di fault tolerance hardware appaiono ormai ben consolidate, i fallimenti software continuano a configurarsi come un problema solo parzialmente risolto, che costituisce una minaccia per le applicazioni con requisiti di elevata dependability. Nonostante l evoluzione delle tecniche di ingegneria del software, l eliminazione di tutti i bug durante le fasi di progettazione e di testing resta un concetto ideale. Basti pensare che taluni fault, per loro stessa natura, non emergono nell ambiente di 1

9 test ma solo in quello di reale funzionamento (ad esempio, perché sono dovuti all integrazione con sistemi di notevole dimensione e complessità). Bisogna poi tener presente che le cause più comuni dell aging (memory leaking, memory bloating, lock su file non rilasciati, frammentazione dei dischi, accumulo di errori di round-off, ecc.) non sono facilmente individuabili con il testing poiché l applicazione ne esibisce le conseguenze solo dopo un lungo periodo di funzionamento. Tali caratteristiche peculiari conferiscono al problema dell aging una particolare difficoltà, la quale risulta amplificata nel caso si intenda studiare l invecchiamento di un sistema operativo (SO). Infatti, quest ultimo è un applicazione di notevole complessità che offre gli strumenti per la corretta gestione di tutte le risorse di un calcolatore [2]. Tale definizione implica diversi problemi nello studio dell aging. In primo luogo, poiché il SO supervisiona l utilizzo di tutte le risorse del sistema di calcolo (processi, memoria centrale e di massa, dispositivi di I/O, ecc.), risulta notevolmente difficile definire un modello esaustivo, analitico o statistico, che consideri le cause e gli effetti dell aging nei diversi sottosistemi. In secondo luogo, l utilizzo di strumenti di benchmark per la valutazione di indicatori di aging può influenzare la misura stessa rendendo falsata l analisi. Ciò è inevitabile per due ragioni. Innanzitutto, poiché lo strumento di benchmark è esso stesso un processo che richiede risorse al sistema operativo, un analisi dell aging che abbia l obiettivo di misurare l esaurimento delle risorse computazionali dovrebbe effettuare anche una stima precisa di quelle che lo strumento di benchmark richiede per funzionare. Inoltre, essendo lo strumento stesso un applicazione software, non è escluso a priori che esso possa causare involontariamente una porzione dell invecchiamento che si ha lo scopo di misurare. Questi concetti sono approfonditi nel corso della tesi, che si propone di analizzare il SO Linux al fine di determinare se esso risulti affetto da aging. Vengono tracciate le linee guida per l applicazione di una procedura utile: - alla rilevazione dell aging; - all individuazione delle porzioni del kernel che risultino maggiormente legate al 2

10 fenomeno; - alla stima del Time To Exhaustion (TTE) delle risorse. Lo scopo di siffatta analisi consiste, in primo luogo, nel fornire agli sviluppatori del SO un insieme di valutazioni utili a ridurre i tempi ed i costi per le operazioni di debugging, mirate al miglioramento generale delle future versioni del kernel. Inoltre, la proposta di una procedura finalizzata alla stima del TTE delle risorse è rivolta principalmente agli amministratori dei sistemi Linux long running, i quali possono determinare il periodo di tempo tra opportuni interventi di ripristino, in considerazione delle particolari condizioni medie di carico del sistema che gestiscono. Nello specifico, la tesi si propone di illustrare lo sviluppo ed il funzionamento di uno strumento in grado di monitorare lo stato di salute del SO Linux, attraverso l introduzione di sonde per il tracciamento delle informazioni di sistema. Nel lavoro svolto, tale strumento viene adoperato per lo studio del software aging ma ciò non preclude un suo utilizzo per fini diversi, che coinvolgano il monitoraggio dello stato delle risorse di sistema. La struttura della tesi può essere schematizzata come segue. Il primo capitolo introduce le definizioni generali inerenti all affidabilità dei sistemi informatici, per poi focalizzare l attenzione sull aging. Dopo averne descritte le cause, si passano in rassegna le varie tecniche proposte in letteratura per l analisi del fenomeno e per la sua prevenzione (rejuvenation). Nel secondo capitolo sono invece esposte le problematiche riguardanti lo studio dell invecchiamento dei sistemi operativi. L analisi qui condotta parte della descrizione delle vulnerabilità dei SO in generale e presenta alcune metodologie proposte in letteratura per lo studio del software aging in ambienti UNIX e Linux. Lo scopo principale consiste nel comprendere lo stato dell arte riguardo agli studi condotti sull invecchiamento dei SO, in modo da costituire un background di conoscenza da cui partire nella proposta di una nuova procedura. Il terzo capitolo descrive la struttura di Linux di cui viene presentata l architettura e la 3

11 suddivisione in sottosistemi. Tale analisi è mirata alla comprensione delle ragioni che inducono il kernel ad invecchiare, nonché all identificazione delle porzioni più vulnerabili e delle informazioni che possono essere monitorate per controllare lo stato di salute del SO. Viene quindi descritto un meccanismo di tracciamento che consenta di reperire i dati sensibili riguardo alle singole componenti. Il quarto ed il quinto capitolo presentano, rispettivamente, la procedura sperimentale adottata per l analisi dell aging nel kernel Linux ed i risultati delle misurazioni effettuate, relativamente ad un sottoinsieme di indicatori precedentemente individuati. A tale scopo, viene descritta una serie di strumenti statistici utili all analisi dei dati che, opportunamente adattati, consentono di ottenere i risultati illustrati, attraverso grafici e tabelle, nell ultimo capitolo. 4

12 Capitolo 1 Dependable Computing e software aging Negli ultimi quarant anni, grazie alla diffusione capillare dell ICT nei più svariati campi d applicazione, le aspettative nei confronti dei sistemi informatici, e particolarmente del software, sono mutate radicalmente. Internet, il web e la multimedialità appartengono, ormai, alle abitudini quotidiane di ciascuno e, parallelamente, i sistemi informatici sono utilizzati in scenari critici sia dal punto di vista economico (business critical) che in termini di affidabilità e sicurezza (mission critical). Si pensi, ad esempio, ad applicazioni quali il controllo del traffico ferroviario ed aereo, il controllo remoto di veicoli senza conducente, le missioni aerospaziali, i software di monitoraggio della apparecchiature mediche, nonché alle applicazioni bancarie e di e-commerce. In siffatti scenari viene spontaneo chiedersi se ci si può fidare dei computer, quali siano i rischi che si corrono e come sia possibile prevenirli o porvi rimedio. L affidabilità di un sistema informatico, come si vedrà in seguito, è definita come un macroattributo, cioè un insieme di indicatori di qualità. Per tale ragione, moltissime sono le cause capaci di degradare la dependability di un servizio, fino a farla scendere al di sotto di livelli ritenuti accettabili. Questo capitolo si propone, allora, di introdurre i concetti generali inerenti all affidabilità dei sistemi informatici, per poi focalizzare l attenzione su un particolare fenomeno in grado di inficiare la dependability del software: l aging. Dopo la definizione dell invecchiamento del software, ne varranno chiarite le cause e gli effetti e si farà una 5

13 breve panoramica sui vari approcci proposti in letteratura per l analisi e la soluzione del fenomeno. 1.1 Dependability dei sistemi informatici Introduciamo di seguito la terminologia ed i concetti di base riguardanti l affidabilità dei sistemi informatici [3]. Prima di spiegare cosa si intende per dependability, è necessario fornire alcune definizioni fondamentali. Un sistema è una qualsiasi entità in grado di interagire con altre entità (sistemi o utenti umani). Per servizio si intende il comportamento del sistema percepito dall utente attraverso una cosiddetta interfaccia che rappresenta, appunto, il confine fra sistema ed utente. Un servizio si dice corretto se è conforme alle specifiche, mentre si parla di failure quando il servizio fornito dal sistema non è corretto. Più precisamente un fallimento è, come esemplifica la figura 1, una transizione dall erogazione di un servizio corretto a quella di un servizio scorretto; la transizione opposta viene detta comunemente restoration (o riparazione). Figura 1.1: diagramma di stato failure-repair. Poiché un servizio è una sequenza di stati esterni del sistema, un service failure consiste nella deviazione di uno o più stati esterni dalle specifiche. La singola deviazione è indicata con il termine errore mentre la causa di un errore si dice fault (ossia guasto). È possibile che un fault generi più di un errore all interno del sistema: in tal caso si parla di multiple 6

14 related error. Un errore è, quindi, quella parte dello stato del sistema che può indurre lo stesso ad un fallimento. Se il sistema è composto da più componenti, un errore può condurre ad un fallimento in uno di questi che a sua volta, poiché i componenti interagiscono, può introdurre uno o più fault nelle altre parti. È importante notare che, comunque, non tutti gli errori raggiungono lo stato esterno del sistema scatenando un fallimento, cioè non tutti gli errori esibiscono conseguenze percepibili dall utente. A questo punto è possibile fornire due definizioni alternative di dependability: - la capacità del sistema di erogare un servizio che può essere ritenuto legittimamente fidato; - la capacità del sistema di evitare che un servizio fallisca più frequentemente e con conseguenze più severe rispetto ad un certo grado di accettabilità. Le due definizioni mettono in evidenza che, per decidere se un servizio può essere ritenuto affidabile, è sempre necessario fissare prima un concetto di fiducia oppure di accettabilità. La nozione di dependability è associata a quella di dependence: la dipendenza di un sistema A da un sistema B rappresenta il punto fin cui la dependability di A è (o potrebbe essere) influenzata da quella di B. Si può così definire la fiducia come il grado di dipendenza ammessa. Più nello specifico, si ritiene che la dependability sia un macroattributo, ossia un insieme dei seguenti indicatori di qualità: - availability; - reliability; - safety; - performability; - maintainability. L availability è la disponibilità di un certo servizio, ossia la probabilità che non ci sia un fallimento al tempo t. In altre parole, si dice che un sistema è available in un certo istante se in quell istante è in grado di fornire un servizio corretto. Poiché l availability è interpretata come un valore medio, ossia come la probabilità che in un dato istante il 7

15 sistema sia disponibile o meno, un sistema indisponibile, ad esempio, 2 secondi al minuto ed uno indisponibile per un intero giorno ogni anno hanno lo stesso valore di availability. La reliability è la misura della durata dell intervallo di tempo durante il quale il sistema fornisce, in maniera continuativa, un servizio corretto. In termini probabilistici, si può definire la reliability nell istante t come la probabilità che non ci sia un fallimento nell intervallo di tempo (0, t). La safety è l assenza di condizioni di funzionamento del sistema che possano provocare danni a persone o cose. Essa è cioè la probabilità che non occorra un fallimento cosiddetto catastrofico nell intervallo di tempo (0, t). Per dichiarare un failure catastrofico si ricorre ad una valutazione soggettiva dei rischi. La performability è una metrica introdotta per valutare le prestazioni del sistema anche in caso di guasti. In pratica, le definizioni di availability e reliability presuppongono che lo stato del sistema sia binario, cioè che possa essere erogato al tempo t un servizio corretto (stato up) o scorretto (stato down). Tale assunzione è vera per quei sistemi che non implementano politiche di tolleranza ai guasti ma, nei casi fault tolerant, possono essere definiti più stati. In pratica, quando la specifica funzionale del sistema descrive un insieme di funzioni da erogare, un fallimento in uno o più servizi può lasciare il sistema in uno stato degenere (ad esempio servizio lento, servizio limitato, servizio di emergenza, ecc.) in cui viene fornito all utente solo un insieme ristretto di funzionalità (figura 1.2): in tal caso si parla di fallimento parziale. La performability è allora una metrica necessaria a misurare la degradazione delle performance in un sistema che ammette stati di funzionamento intermedi fra quello di up e down. La maintainability, infine, è la capacità di un sistema di essere facilmente sottoposto a modifiche e riparazioni. In termini probabilistici, essa è definita come la probabilità di effettuare una riparazione con successo in un certo tempo. La maintainability misura, quindi, il grado di velocità con cui il sistema può essere ripristinato dopo l occorrenza di un fallimento. 8

16 Figura 1.2: diagramma di stato failure-repair con politica di tolleranza ai guasti. Per una stima quantitativa del grado di dependability di un sistema vengono utilizzate, nella pratica, metriche di tipo statistico. Alcune di esse sono abbastanza generali per essere applicate a qualsiasi servizio e sono basate sui parametri mostrati in tabella 1.1. Queste misure sono utili a valutare gli attributi di dependability descritti precedentemente. Ad esempio, si può definire l availability come: MTTF MTTF A = =. MTTF + MTTR MTBF A titolo di esempio, si consideri un sistema che fallisce, in media, una volta all ora ma si ripristina automaticamente in 10 ms. In base alla definizione precedente, il sistema in questione risulta notevolmente available poiché si ha: 9

17 MTTF = 1h = 3600s MTTR = 10ms = 0,01s 3600 A = = 0, ,01 PARAMETRO ACRONIMO DESCRIZIONE Mean Time To Crash MTTC tempo medio di occorrenza di un crash Mean Time Between tempo medio tra due crash MTBC Crashes successivi Mean Time To Failure MTTF tempo medio di occorrenza di un failure Mean Time Between tempo medio tra due failure MTBF Failure successivi Mean Number of numero medio di istruzioni per il MNIR Instruction to Restart ripristino del sistema Mean Time To Repair MTTR tempo medio necessario per riparare il sistema Mean Down Time MDT tempo medio durante il quale il sistema non è funzionante Mean Time Between Errors MRBE tempo medio fra due errori successivi Tabella 1.1: metriche per la valutazione della dependability. La figura 1.3 esemplifica la relazione fra le metriche MTTF, MTBF ed MTTR. Figura 1.3: relazione fra MTTF, MTBF ed MTTR. 1.2 Fallimenti, errori e guasti Come accennato precedentemente, un failure può essere definito come l evento in corrispondenza del quale il sistema cessa di fornire un servizio corretto. Un servizio può in generale non essere corretto se non è conforme alle specifiche funzionali oppure se la sua 10

18 specifica, in fase di analisi dei requisiti, non ha descritto adeguatamente le funzionalità del sistema. Un errore è la parte dello stato di un sistema che può indurre lo stesso al fallimento (unproper service). Se l errore è opportunamente rilevato esso si dice detected error, viceversa se l errore esiste ma non è rilevato si parla di latent error. La causa di un errore è un fault (guasto), che può derivare dall avaria di un componente hardware, da fenomeni di interferenza o da errori di progettazione. La figura 1.4 schematizza le relazioni fra failure, error e fault. In particolare, l attivazione di un guasto provoca la transizione del sistema da uno stato di corretto funzionamento (correct behavior) ad uno stato improprio (errore). Un errore può poi degenerare in un fallimento mediante propagazione all interfaccia utente che rende visibile l anomalia attraverso la scorrettezza del servizio fornito. La rilevazione di un errore e le opportune operazioni di ripristino possono in seguito riportare il sistema ad operare in maniera corretta. Figura 1.4: relazione fra fallimenti, errori e guasti. Un sistema può portarsi in uno stato incoerente in ogni fase del suo ciclo di vita a causa di guasti hardware, errori in fase di progettazione, errati interventi di manutenzione ecc.. Il ciclo di vita di un sistema può essere suddiviso in due macrofasi: lo sviluppo e l uso. La fase di sviluppo include tutte quelle attività necessarie affinché il concetto iniziale del committente si concretizzi in un sistema finale, in grado di fornire il servizio richiesto nell ambiente reale di utilizzo. A partire dallo stato embrionale, il sistema interagisce con 11

19 l ambiente di sviluppo ed è soggetto ai cosiddetti fault di sviluppo che possono essere causati da uno degli elementi che costituisce l ambiente: - il mondo fisico, con i suoi fenomeni naturali; - gli sviluppatori umani; - i tool di sviluppo, produzione e testing. La fase di utilizzo ha inizio quando il sistema viene accettato dall utente e comincia a fornire i suoi servizi. L uso consiste, in particolare, in periodi alternati di corretto funzionamento, di deviazione dalle specifiche e di spegnimento volontario finalizzato ad attività di manutenzione. Durante la fase d utilizzo il sistema interagisce con l ambiente d uso, il quale può introdurre guasti attraverso una delle sue entità: - il mondo fisico, con i suoi fenomeni naturali; - gli amministratori, cioè le entità (persone o altri sistemi) che hanno l autorizzazione ad usare, gestire, manutenere e riparare il sistema; - gli utenti, ossia le entità (persone o altri sistemi) che fruiscono dei servizi del sistema attraverso le sue interfacce; - i provider (persone o altri sistemi) che forniscono a loro volta servizi al sistema; - l infrastruttura, costituita da entità in grado di procurare servizi specializzati come fonti di informazione (ad esempio, clock, GPS, ecc.), link di comunicazione, sorgenti di potenza, sistemi di raffreddamento, ecc.; - gli intrusi, ossia entità (persone o altri sistemi) che cercano di alterare i servizi forniti dal sistema, di renderlo indisponibile o di degradarne le prestazioni. Nei tre paragrafi seguenti si espongono alcune tassonomie di failure, error e fault dettagliate in [3] Fallimenti L occorrenza di un fallimento va definita in relazione alla funzione del sistema desiderata dall utente finale e non rispetto alla specifica funzionale fissata in fase di analisi. 12

20 Ciò significa che un servizio conforme alle specifiche può essere inaccettabile per un utilizzatore, ad esempio a causa di omissioni, cattive interpretazioni, assunzioni indesiderate o inconsistenze. In tal caso, il fatto che un evento è indesiderato può essere rilevato solo allorché l evento stesso si presenta, scatenando una serie di conseguenze più o meno severe. Questa natura soggettiva dei fallimenti fa sì che, generalmente, un sistema possa fallire in modalità differenti, denominate failure mode, le quali implicano la non correttezza del servizio secondo quattro diversi punti di vista: dominio, rilevabilità, percezione e rilevanza del fallimento. Dal punto di vista del dominio è possibile distinguere: - timing failure o fallimenti nel tempo, che causano la non conformità di un servizio alle specifiche in termini di tempo (cioè il verificarsi di un evento nel momento sbagliato). Fallimenti di questo tipo possono essere poi specializzati in early timing failure, se il servizio è fornito in anticipo, e late timing failure, se in ritardo; - content failure o fallimenti nel valore, a seguito dei quali il contenuto informativo del servizio perviene all interfaccia in maniera non conforme alle specifiche. Qualora un sistema fallisca sia nel tempo che nel valore, esso può fornire non correttamente il servizio in diverse modalità, tra cui: - halted, quando il sistema permane in uno stato bloccato senza che l output riesca a pervenire all interfaccia. Un particolare fallimento di questo tipo è l omission failure, che si ha quando il servizio assume un valore nullo ed un ritardo infinito. Un omission failure permanente prende il nome di crash; - erratic, quando il servizio fornisce all interfaccia informazioni incoerenti. Dal punto di vista della rilevabilità del fallimento si distinguono: - signaled failure o fallimenti rilevati, segnalati a livello utente da un opportuno messaggio di errore; - unsignaled failure o fallimenti non rilevati, cioè non segnalati a livello utente. I meccanismi stessi di rilevazione possono fallire in due modi: 13

21 - segnalando la perdita di una funzionalità quando in realtà non c è stato alcun fallimento (si parla in tal caso di falso allarme); - omettendo la segnalazione di una mancanza di funzionalità (si ha, cioè, un fallimento non rilevato). In taluni sistemi i fallimenti di specifiche funzionalità implicano la riduzione del servizio ed il sistema stesso è in grado di segnalare agli utenti che la modalità di funzionamento risulta degradata. Questo approccio può essere utile per ridurre l emergenza di alcune situazioni o per consentire, ad esempio, uno spegnimento sicuro degli apparati con finalità di manutenzione. Dal punto di vista della percezione del fallimento si distinguono: - consistent failure o fallimenti consistenti, che inducono tutti gli utenti del sistema ad avere la stessa percezione del failure; - unconsistent failure o fallimenti inconsistenti, che possono essere percepiti in maniera diversa dagli utenti del sistema. Fallimenti di questo tipo sono generalmente indicati come bizantini. La stima quantitativa delle conseguenze provocate dal failure sull ambiente induce alla definizione di severità del fallimento, legata al costo necessario per il ripristino. I failure mode possono quindi essere ordinati secondo livelli di severità cui sono associati, di solito, valori di probabilità di occorrenza massimi accettabili. Il numero e la definizione dei livelli di severità, così come le probabilità associate, dipendono dall applicazione considerata nonché dagli attributi di dependability che risultano più appropriati alla caratterizzazione del sistema in questione. Ad un alto livello di astrazione, si possono definire due valori limite di severità, considerando la relazione fra i benefici erogati dal sistema in assenza di fallimenti e le conseguenze di un singolo failure: - catastrophic failure o fallimenti catastrofici, che provocano conseguenze al sistema più gravi di molti ordini di grandezza rispetto al beneficio prodotto dal servizio fornito in assenza di fallimento; 14

22 - minor failure o fallimenti benigni, che ingenerano conseguenze dello stesso ordine di grandezza (valutato in termini di costo) del beneficio prodotto dal servizio fornito in assenza di fallimento. Una schematizzazione di quanto appena esposto è riportata in figura 1.5. Figura 1.5: tassonomia di fallimenti. I sistemi che sono progettati ed implementati in modo da fallire solamente in specifiche modalità ed entro certi limiti accettabili (descritti nelle specifiche sull affidabilità e la sicurezza) sono detti fail-controlled. Ad esempio, siffatti componenti possono essere tali da bloccare l output invece di presentare valori errati, oppure possono essere in grado di fallire solo in modo consistente. Si definisce allora sistema fail-halt o fail-stop un componente in grado di fallire solo in modalità halted. Ciò di solito ha lo scopo di evitare quanto più possibile qualsiasi conseguenza negativa su altri sistemi o operatori umani. Un sistema fail-safe, infine, dovrebbe garantire che i fallimenti e le loro conseguenze siano quanto più ridotti possibile. Fail-safe devono essere, ad esempio, le applicazioni il cui fallimento implica il sorgere di situazioni pericolose per gli utenti (come applicazioni radar per il controllo del traffico aereo o software per apparecchiature mediche). 15

23 1.2.2 Errori Un errore è la parte dello stato totale di un sistema che può (o meno) determinare l insorgere di un fallimento, nel caso la situazione anomala riesca a propagarsi sino all interfaccia utente. Poiché i sistemi sono costituiti da una serie di componenti interagenti, lo stato totale può essere definito come la combinazione degli stati delle singole unità. Questa definizione implica che: - un guasto all interno di uno specifico componente può generare errori in più unità del sistema. In tal caso si parla di multiple related error mentre, se il fault riguarda un unico componente, gli errori provocati si definiscono single error; - un fault può originare un errore all interno dello stato di un componente senza che occorra un fallimento nel servizio ad alto livello. Ciò avviene quando lo stato esterno dell unità compromessa non fa parte dello stato esterno del sistema. L occorrenza di un fallimento in presenza di un errore dipende, in particolare, da due fattori: - la struttura del sistema e, soprattutto, la natura di ogni forma di ridondanza; - il comportamento del sistema. Per quanto concerne il primo punto, si deve tener presente che non esiste soltanto la cosiddetta ridondanza protettiva (introdotta per fornire una certa tolleranza ai guasti) ma anche una forma di ridondanza non intenzionale (perché è spesso difficile, se non impossibile, progettare un sistema senza alcuna ridondanza) che può avere effetti simili alla prima. Riguardo al secondo punto, invece, può accadere che la parte dello stato che contiene l errore non divenga mai necessaria al servizio o che l errore stesso sia sovrascritto prima che ingeneri il fallimento. Una classificazione conveniente degli errori può essere basata sulle categorie di fallimenti che essi sono in grado di provocare. È cioè possibile distinguere errori: - di tempo e di valore; - rilevati e latenti; 16

24 - consistenti ed inconsistenti - catastrofici e benigni Guasti Come mostra la figura 1.6, tutti i guasti che possono interessare un sistema durante il suo intero ciclo di vita sono classificati in [3] in base ad otto punti di vista, detti classi di fault elementari. Figura 1.6: classi di fault elementari. Se fossero possibili tutte le combinazioni delle 8 classi, potrebbero essere derivate ben 256 differenti classi di fault combinate. Ovviamente, però, non tutti i criteri sono applicabili ad ognuna delle classi di guasti (ad esempio, i fault naturali non possono essere classificati in 17

25 base ad obiettivi, intenti e capacità). È così possibile identificare solo un sottoinsieme di tutte le combinazioni, come le 31 mostrate in figura 1.7 con i relativi esempi. Figura 1.7: classi di fault combinate. Le classi combinate appartengono a tre gruppi parzialmente sovrapposti: - guasti di sviluppo, che includono tutti quei fault nati in fase di sviluppo del sistema; - guasti fisici, cioè quelli che riguardano l hardware; - guasti di interazione, che includono tutti i fault esterni. I fault naturali sono guasti fisici (cioè hardware) causati da fenomeni naturali e senza la partecipazione umana. Ad esempio, i difetti fisici sono fault naturali che si originano durante lo sviluppo. Durante la fase operativa, i fault naturali possono essere sia interni, 18

26 cioè dovuti al deterioramento fisico di alcuni componenti, che esterni, ossia causati da processi naturali. Questi ultimi si originano al di fuori dei confini del sistema e riescono a penetrarvi, ad esempio attraverso radiazioni elettromagnetiche, picchi di potenza elettrica, cambiamenti di temperatura, ecc.. La definizione dei fault dovuti all uomo (che possono essere sia hardware che software) include quelli causati dalla mancanza di intervento quando quest ultimo sarebbe necessario, cioè i cosiddetti guasti per omissione. Inoltre, i suddetti fault possono essere classificati in due gruppi, a seconda dello scopo dell intervento umano: - guasti maliziosi, introdotti volontariamente durante l uso del sistema o anche durante il suo sviluppo (allo scopo di far nascere situazioni di emergenza in fase operativa) per alterarne lo stato, provocare una sospensione del servizio o per accedere a informazioni riservate; - guasti non maliziosi, causati in maniera inconsapevole. I fault non maliziosi possono poi essere ulteriormente classificati, a seconda della consapevolezza degli attori, in: - guasti non deliberati, dovuti ad errori o ad azioni di sviluppatori, utenti e manutentori di cui questi ultimi ignorano le conseguenze; - guasti deliberati, che sono causati da decisioni sbagliate ma volontarie. Un ulteriore particolarizzazione dei fault non maliziosi può essere fatta considerando le capacità di sviluppatori ed utenti che possono provocare: - guasti accidentali, cioè originati da incidenti e senza l esplicita volontà della persona coinvolta; - guasti da incompetenza, dovuti alla poca conoscenza che gli sviluppatori o gli utilizzatori hanno del dominio del problema e del sistema stesso, oppure alla scarsa attenzione che questi pongono su taluni fattori (che, ad esempio, conducono a scelte di progetto infelici). I fault di interazione sono guasti operativi (cioè che occorrono durante il normale funzionamento del sistema) che possono essere sia dovuti all uomo che a cause naturali. 19

27 Essi sono comunque ingenerati da alcuni elementi dell ambiente d uso che interagiscono con l apparato (quindi si tratta di guasti esterni) in maniera scorretta. A volte possono essere definiti di interazione i cosiddetti errori di configurazione dovuti al settaggio sbagliato di parametri in grado di influenzare la sicurezza, la gestione della memoria e delle reti, la comunicazione fra le varie componenti del sistema, ecc.. Una caratteristica comune dei guasti di interazione è che essi sono favoriti dalla presenza intrinseca di una qualche vulnerabilità, cioè di un fault interno capace di abilitarne uno esterno in grado di danneggiare il sistema. Un ultima classificazione dei fault riguarda la loro persistenza. Relativamente ai guasti hardware è possibile distinguere: - guasti permanenti, stabili e continui nel tempo; - guasti transienti, legati a momentanee condizioni ambientali e che scompaiono definitivamente senza la necessità di alcuna operazione di ripristino; - guasti intermittenti, che si verificano in corrispondenza di particolari condizioni ambientali e scompaiono senza alcuna azione di riparazione per poi ricomparire. Per quanto concerne il software, non esiste la distinzione tra guasti intermittenti e transienti poiché tutti i guasti software si attivano in corrispondenza di precise condizioni, più o meno complesse. Ne deriva che questi fault sono permanenti, nel senso che ciascun bug rimane nel codice (finché non è eventualmente corretto) anche se viene attivato (e quindi percepito dall utente) solo da precise condizioni Guasti software Gray [4], al fine di definire un meccanismo di fault tolerance, presenta preliminarmente un modello di fallimenti software basato sulla cosiddetta ipotesi Bohrbug/Heisenbug. È noto che molti guasti hardware sono soft, cioè di natura transitoria, e che ad essi si può (in qualche misura) porre rimedio con metodi standard basati su checksum, correzione degli errori di memoria, ritrasmissione ecc.. Tali tecniche riescono ad innalzare il MTBF di una 20

28 quantità che si stima vari fra 5 e 100 unità temporali. Gray afferma che, similmente a ciò che avviene per l hardware, anche molti fault software sono soft: è infatti esperienza comune che, riavviando semplicemente un operazione dopo un crash, questa spesso non fallisce una seconda volta. Tale ipotesi, apparentemente paradossale, discende dal fatto che i bug sistematici vengono tipicamente identificati e risolti durante le fasi di debugging e testing del software. Guasti di quest ultimo tipo vengono chiamati Bohrbug. Essi (il cui nome deriva dall atomo di Bohr) sono hard, cioè solidi : si tratta spesso di fault permanenti di progetto che hanno natura abbastanza deterministica. Tale caratteristica implica che i Bohrbug sono facili da identificare con tecniche standard durante le fasi di debugging e collaudo (oppure addirittura di deployment). Se si considera un software industriale, dopo il progetto, le revisioni, la fase di quality assurance, i test di tipo alpha e beta, ecc., si può ritenere che la maggior parte dei Bohrbug siano stati eliminati. I guasti residui, tipicamente rari se le fasi precedenti sono state condotte con rigore, saranno allora correlati a condizioni hardware (fault hardware rari o transienti, problemi di incompatibilità, questioni legate ai driver, ecc.), condizioni limite (overflow e underflow, carichi eccessivi, ecc.) o race condition 1. In siffatte circostanze, il riavvio del programma ricrea tipicamente un ambiente molto diverso da quello del fallimento che, in numerosi casi, conduce al normale funzionamento dell applicazione. Ai fault che esibiscono il comportamento appena descritto si dà il nome di Heisenbug (dal principio di indeterminazione omonimo). Essi possono eludere i sistemi di collaudo per anni poiché, a differenza dei Bohrbug, una stessa operazione di testing può perturbare l ambiente operativo al punto da far sparire l Heisenbug. Le condizioni di attivazione di un Heisenbug si presentano, infatti, in maniera molto rara e sono difficilmente riproducibili proprio perché questi fault sono fortemente dipendenti dall ambiente operativo. Recenti studi hanno evidenziato che il 70% degli errori sono di tipo transiente e sono causati 1 Si ha una race condition, o corsa critica, quando in un programma, in cui due o più processi condividono delle risorse comuni, l esecuzione del programma stesso è influenzata dal modo in cui i processi vengono schedulati. Questo problema viene gestito mediante la mutua esclusione (si permette ad un solo processo alla volta di accedere alla risorsa condivisa). 21

29 principalmente da race condition e da problemi di sincronizzazione. Taluni autori definiscono gli Heisenbug come un sottoinsieme di un classe di fault ben più vasta, i Mandelbug [5, 6]. Questi sono fault che possono indurre il software ad esibire un comportamento caotico e non deterministico rispetto all occorrenza e non occorrenza di fallimenti. La loro attivazione e le modalità di propagazione seguono dinamiche complesse in almeno uno dei seguenti modi: - con lunghi ritardi tra l attivazione del fault e l occorrenza finale del fallimento. Se il sistema attraversa differenti stati di failure durante la propagazione dell errore, diventa difficile identificare le azioni dell utente che realmente hanno attivato il fault e causato il fallimento. La semplice ripetizione dei passi eseguiti in breve tempo, prima dell occorrenza del fallimento, può non condurre alla sua riproduzione; - con un comportamento che dipende fortemente da alcuni elementi dell ambiente, quali il sistema operativo, l interazione con altre applicazioni, o l hardware. Poiché gli Heisenbug sono guasti software che cambiano il proprio comportamento quando vengono esaminati o isolati (cioè quando muta l ambiente operativo), essi risultano un sottotipo di Mandelbug. Per quel che riguarda le tecniche utili per la correzione dei bug software [5, 6] è stato già detto che metodi di progettazione, debugging e testing robusti conducono quasi sempre all eliminazione dei Bohrbug. Per i Mandelbug si può sfruttare l assunto che il reboot del sistema risolve spesso il problema, accoppiando quest ultimo con approcci di checkpointing, ossia tecniche che consentono il salvataggio periodico dello stato dell applicazione in memoria stabile. Con metodi siffatti, dopo il fallimento è possibile riavviare l applicazione, portandola nell ultimo stato senza errori memorizzato. Un secondo approccio consiste nell utilizzare la replicazione, ossia nel ridondare le risorse del sistema. Due applicazioni identiche che girano su diverse istallazioni dello stesso sistema operativo possono, infatti, non esibire gli stessi fallimenti. Se si suppone che tutti i Bohrbug risultano eliminati dopo il testing, allora i guasti dei due programmi replicati possono ritenersi legati all ambiente operativo e saranno, dunque, dei Mandelbug. Il 22

30 confronto fra le configurazioni hardware e software dei due sistemi, al momento di un fallimento in uno dei due, può così aiutare a comprendere le cause del problema. 1.3 Metodi per migliorare la dependability del software Durante le fasi del ciclo di vita del software si può cercare di assicurare una maggiore affidabilità al prodotto finale, seguendo differenti approcci per la gestione dei guasti [3]: - fault prevention; - fault tolerance; - fault removal; - fault forecasting. La prevenzione dei guasti, considerata come un miglioramento del processo di sviluppo che ha il fine di ridurre il numero di fault introdotti nel sistema prodotto, è una parte importante dell ingegneria in generale. La prevenzione dei bug software si attua, ad esempio, applicando le buone regole imposte dall ingegneria del software, quali l information hiding, la modularità, l uso di linguaggi di programmazione tipizzati, ecc.. La tolleranza ai guasti (figura 1.8), che ha lo scopo di evitare i fallimenti, si basa sulla rilevazione degli errori e sul ripristino del sistema. Per quel che riguarda la prima fase, essa può essere espletata in maniera concorrente (cioè durante la normale erogazione del servizio) o preventiva (quando il servizio viene sospeso alla ricerca dei guasti latenti). Il ripristino, invece, si basa sulla gestione degli errori (error handling), che ha lo scopo di eliminare gli errori dallo stato del sistema, e sulla gestione dei guasti (fault handling), che serve ad evitare che uno stesso fault sia nuovamente attivato. Questa seconda fase è seguita di solito dalla cosiddetta manutenzione correttiva, che ha lo scopo di rimuovere i fault isolati nella fase di handling. La gestione degli errori può essere implementata attraverso forme di rollback (si porta il sistema all ultimo checkpoint, ossia all ultimo stato senza errori salvato), rollforward (si assegna al nuovo stato del sistema l ultimo stato senza errori) o compensazione (ci si serve della ridondanza per mascherare un errore corrente). 23

31 Le prime due tecniche vengono invocate on demand, dopo la fase di rilevazione degli errori. La compensazione, invece, può essere applicata sia on demand che sistematicamente, ad intervalli di tempo predefiniti o scanditi da eventi, ed indipendentemente dall occorrenza di un errore. L error handling on demand seguita dalla fault handling formano la strategia di tolleranza ai guasti chiamata brevemente detection and recovery, mentre la cosiddetta fault masking deriva dall uso sistematico della compensazione. Figura 1.8: metodi di fault tolerance. Tra le tecniche per la gestione degli errori va annoverata anche la software rejuvenation (cfr. paragrafo 1.6). Nel caso dell aging, in particolare, la rilevazione è effettuata solitamente misurando la disponibilità delle risorse (ad esempio il livello di memoria libera) e stimando il loro tempo di esaurimento (TTE cfr. paragrafo 1.5.2). In molti casi, comunque, la rejuvenation avviene senza la rilevazione degli errori (cioè periodicamente) al fine di rimuovere questi ultimi, se presenti, soltanto sulla base del TTE stimato. 24

32 La gestione dei guasti, infine, si può comporre delle seguenti fasi: - diagnosi, che consiste nell identificare e registrare le cause degli errori in termini di locazione e tipologia; - isolamento, che implementa l esclusione logica o fisica del componente difettoso, in modo da mascherare il guasto; - riconfigurazione, che si occupa di ridistribuire i compiti dei componenti guasti ad unità di riserva non fallite; - reinizializzazione, che consiste nell aggiornamento e nella registrazione della nuova configurazione. La rimozione dei guasti può avvenire durante la fase di sviluppo o durante quella operativa. Nel primo caso, essa consiste di tre passi: la verifica, la diagnosi e la correzione. La verifica serve a controllare che il sistema soddisfi alcune proprietà di interesse. In caso negativo si passa alla diagnosi, per identificare le cause dell anomalia, e successivamente alla correzione dell errore. Dopo quest ultima fase, dovrebbe essere ripetuto lo step di verifica, per assicurarsi di non aver introdotto altri fault con la correzione. La validazione può essere statica o dinamica, a seconda del fatto che avvenga in maniera formale o coinvolga il funzionamento reale del sistema. L eliminazione dei guasti durante l uso consiste nella cosiddetta manutenzione correttiva o preventiva. La prima cerca di rimuovere i guasti che hanno condotto ad un errore rilevato, mentre la seconda ha lo scopo di identificare ed eliminare quei fault non segnalati che possono risultare in un errore durante il normale funzionamento del sistema. La fault forecasting, infine, è condotta per implementare una valutazione del comportamento del sistema per quel che riguarda l occorrenza dei guasti. Tale stima consta di due aspetti: - la valutazione qualitativa o ordinale, che cerca di identificare e classificare i failure mode oppure le combinazioni di eventi in grado di condurre il sistema al fallimento; - la valutazione quantitativa o probabilistica, che prova a determinare il punto fin dove alcune proprietà di interesse (dette misure) sono soddisfatte. 25

33 La valutazione quantitativa si può basare su cosiddetti benchmark di affidabilità, ossia su procedure di misura del comportamento di un sistema in presenza di fault. Il fine di tali metodologie consiste nella caratterizzazione degli attributi di dependability, nonché nella scelta comparativa delle possibili soluzioni. 1.4 Software aging Come precedentemente affermato, non è possibile produrre software bug-free. Ne deriva che assicurare una certa dependability alle applicazioni implica la necessità di impiegare tecniche di fault tolerance in fase operazionale. Per sistemi caratterizzati da requisiti critici di affidabilità, queste possono includere metodologie per l analisi dell aging e per la relativa rejuvenation. A tal proposito, si definisce software aging [7] quel fenomeno che riduce l affidabilità del software, determinandone una lenta e progressiva degradazione delle prestazioni oppure improvvisi stalli o crash, causato nella maggior parte dei casi da esaurimento delle risorse del sistema operativo, frammentazione, corruzione di dati ed accumulo di errori numerici durante un lungo periodo di tempo. La definizione di software aging può sembrare un assurdità se si considera il software un prodotto matematico: un teorema, infatti, se risulta errato oggi, doveva necessariamente esserlo anche al momento della sua produzione. In realtà moltissimi sono gli aspetti che rendono il comportamento delle applicazioni più diverse variabile del tempo e, a volte, non predicibile. I sistemi maggiormente colpiti da tale fenomeno risultano quelli long running, cioè quelli che restano in esecuzione per lunghi periodi di tempo e tendono a mostrare un tasso di fallimenti via via crescente. Per tale motivo, il software aging non si osserva quasi mai in programmi di utilizzo comune ma in applicazioni specializzate, che spesso sono caratterizzate da requisiti critici di affidabilità e sicurezza. Bisogna sottolineare che i fault causati dall aging non riguardano l obsolescenza dei sistemi software (dovuta ai cambiamenti apportati nel tempo al sistema stesso oppure ad 26