Dependability: concetti fondamentali
Domenico Cotroneo, Stefano Russo
Dipartimento di Informatica e Sistemistica
Universita’ degli Studi di Napoli Federico II
Dispensa Didattica del corso di Sistemi Distribuiti
9 dicembre 2005
Indice
1 Dependability e metodologie di failure data analysis 11.1 Il concetto di dependability nel tempo . . . . . . . . . . . . . 1
1.1.1 Sistema, servizio, interfaccia . . . . . . . . . . . . . . . 21.1.2 Gli attributi di dependability . . . . . . . . . . . . . . 21.1.3 Dependability measures . . . . . . . . . . . . . . . . . 8
1.2 Dependability threats . . . . . . . . . . . . . . . . . . . . . . . 91.2.1 Faults . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.2 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2.3 Failures . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2.4 Propagazione delle minacce: la catena fault, error,
failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.3 Dependability means . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1 Fault avoidance . . . . . . . . . . . . . . . . . . . . . . 191.3.2 Fault tolerance . . . . . . . . . . . . . . . . . . . . . . 19
1.3.2.1 Tecniche di fault tolerance . . . . . . . . . . 221.3.2.2 Stati di un sistema fault tolerant . . . . . . . 23
1.3.3 Fault removal . . . . . . . . . . . . . . . . . . . . . . . 241.3.4 Fault forecasting . . . . . . . . . . . . . . . . . . . . . 25
1.4 La failure data analysis . . . . . . . . . . . . . . . . . . . . . 261.4.1 Field failure data analysis . . . . . . . . . . . . . . . . 28
1.5 Un caso di studio: Windows NT . . . . . . . . . . . . . . . . 31
Bibliografia 40
i
Elenco delle figure
1.1 Andamento del failure rate di un componente . . . . . . . . . 51.2 Binary state model . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Attributi di dependability . . . . . . . . . . . . . . . . . . . . 81.4 MTTF,MTBF,MTTR . . . . . . . . . . . . . . . . . . . . . . 91.5 Tassonomia dei faults (Laprie, 2004) . . . . . . . . . . . . . . 131.6 Tassonomia dei fallimenti (Laprie, 2004) . . . . . . . . . . . . 161.7 Patologia dei guasti . . . . . . . . . . . . . . . . . . . . . . . 171.8 Propagazione esterna dei guasti . . . . . . . . . . . . . . . . . 181.9 Strategie di tolleranza ai guasti (Laprie, 2004) . . . . . . . . . 201.10 Diagramma degli stati di un sistema fault tolerant . . . . . . 231.11 Strategie di verifica (Laprie, 2004) . . . . . . . . . . . . . . . 251.12 Fault Removal During Development . . . . . . . . . . . . . . 261.13 Fasi della field failure data anlysis (Iyer, 2000) . . . . . . . . 281.14 Esempio di log entry . . . . . . . . . . . . . . . . . . . . . . . 291.15 Modello a stati finiti di un singolo host (Iyer, 2000) . . . . . . 361.16 Modello a stati finiti del dominio (Iyer, 2000) . . . . . . . . . 371.17 Distribuzione dei tempi di inter-reboot . . . . . . . . . . . . . 38
ii
Elenco delle tabelle
1.1 Dependability Measures . . . . . . . . . . . . . . . . . . . . . 81.2 Parametri del test . . . . . . . . . . . . . . . . . . . . . . . . 311.3 Breakup dei reboot in base ai prominent events (Iyer, 2000) . 331.4 Statistiche sui tempi di up e down . . . . . . . . . . . . . . . 351.5 Statistiche sulle percentuali di Availability . . . . . . . . . . . 351.6 Interpretazione degli stati del modello del dominio (Iyer, 2000) 37
iii
Capitolo 1
Dependability e metodologie
di failure data analysis
L’evolversi delle tecnologie ed il fiorire di scenari applicativi sempre nuovi e com-plessi ha indotto negli anni numerose rivisitazioni del concetto di dependabilitynella sua accezione piu completa. Nel presente capitolo e riportata una breve ri-costruzione storica delle diverse interpretazioni oltre che la descrizione dei concettifondamentali legati all’idea di dependability. Ad una prima parte meramente de-scrittiva in cui si illustrano gli attributi di dependability, le minacce all’affidabilitadi un sistema e le tecniche di dependability improvement, segue una seconda parteincentrata sull’analisi dei dati (failure data analysis) per la valutazione dell’affid-abilita di un sistema. Il capitolo si conclude con un caso di studio -presente inletteratura- sull’analisi, quantitativa e qualitativa, della dependability di un sistemanetworked.
1.1 Il concetto di dependability nel tempo
Requisiti di affidabilita sono diventati negli anni di primaria importanza per
un numero sempre crescente di sistemi sottoponendo a continue rivisitazioni
l’interpretazione del concetto di dependability . Nel 1982 Laprie definiva
la dependability come “...the ability of a system to accomplish the
tasks (or,equivalently, to provide the service) which are expected
to it”; in [A.A85] (1985) Avizienis si riferiva alla dependability come “...
the quality of the delivered service such that reliance can justifi-
ably be placed on the service it delivers”. Nel 2001 ancora Laprie et
al. [A.A01] sintetizzavano il concetto in “...the ability to deliver ser-
1
2
vice that can justifiably be trusted” per poi renderlo piu generale nel
2004 [AL04] definendo la dependability come “...ability to avoid service
failures that are more frequent and more severe than acceptable”.
1.1.1 Sistema, servizio, interfaccia
Prima di procedere nella trattazione e necessario chiarire il significato di ter-
mini ricorrentemente utilizzato nell’arco del presente capitolo quali sistema
(1), servizio (2) ed interfaccia (3).
1. Per sistema si intende una qualsiasi entita in grado di interagire con
altre entita, siano esse altri sistemi o utenti umani. L’insieme di entita
con cui un sistema e in grado di interagire ne costituiscono l’ambi-
ente (environment). Il comportamento (behavior) di un sistema
e l’insieme delle azioni che esso compie per implementare le funzioni
richieste ed e costituito da una successione di stati;
2. Il servizio fornito da un sistema e il suo comportamento cosı come
e percepito da un utente, ovvero da una qualsiasi altra entita che
usufruisce del servizio stesso. Un servizio corretto, proper service, e
un servizio fornito dal sistema conformemente alle specifiche. Qualora
il servizio dovesse deviare da esse si parla di service failure, o piu
sinteticamente failure (cfr. Paragrafo 1.2.3);
3. L’interfaccia di un sistema e il confine dello stesso percepibile da un
utente. L’interfaccia su cui viene fornito il servizio prende il nome di
service interface.
1.1.2 Gli attributi di dependability
Dalle definizioni di cui al Paragrafo 1.1 emerge che la di dependability di
un sistema non e un concetto semplice a formalizzarsi. In realta essa e
3
un insieme di attributi di qualita (dependability attributes) che assumono
singolarmente un’enfasi relativa alla natura del sistema cui si riferiscono e
al particolare contesto applicativo:
◦ Availability
L’Availability (o anche disponibilita) e sinteticamente definita come la
probabilita che un sistema sia pronto in un certo istante t, in formule:
A=P(!Failure at t) (1.1)
Piu esplicitamente, un sistema e available in un dato istante t se e
in grado di fornire un servizio corretto. Matematicamente quindi la
funzione A(t) e del tipo:
A(t) =
1 if proper service at t
0 otherwise
(1.2)
e dunque la 1.1 si riferisce al suo valore atteso, E(A(t)).
Una serie di interessanti critiche sono state mosse ad una simile inter-
pretazione del concetto di disponibilita:
1. un sistema potrebbe non essere totalmente disponibile ma co-
munque continuare ad essere operativo: l’availability potrebbe
dunque essere interpretata come uno spettro di valori e non in
chiave binaria (up or down);
2. la disponibilita di un sistema dovrebbe essere intesa quale fun-
zione della qualita del servizio offerta dal sistema nel tempo e non
4
come un valore medio: secondo la (1.1) un sistema indisponi-
bile per due secondi al minuto ed uno indisponibile per un in-
tero giorno ogni anno sono caratterizzati dal medesimo valore di
availability pur avendo un comportamento sensibilmente diverso.
◦ Reliability
La Reliability R(t) e la misura della continuita di un servizio ovvero la
misura dell’intervallo di tempo in cui viene fornito un servizio corretto:
R(t)=P(!Failure in (0,t)) (1.3)
Piu in generale, la distribuzione dell’affidabilita di un sistema R(t,τ) e
la probabilita condizionale che il sistema funzioni correttamente (prop-
er service) nell’intervallo [t,t+ τ ], ammesso che fosse correttamente
operativo al tempo t [D.P]:
R(t , τ ) = P(no failures in [t , τ ]|corretto funzionamento in t)
(1.4)
Detta F(t) la funzione di distribuzione cumulativa del tempo di fal-
limento (CDF -Cumulative Distribution Function), unreliability , la
funzione R(t) puo essere riscritta come
R(t)=1-F(t) (1.5)
Il numero di fallimenti di un sistema per unita di tempo e definito come
tasso di fallimento, e generalmente indicato con λ(t) e misurato
in numero di fallimenti per ora. L’andamento tipico del tasso dai
fallimento per un componente e riportato in Figura 1.1.
5
Wear Out Period
t
λ(t) Infant mortality
Normal Lifetime
Approximatively constant
Wear Out Period
t
λ(t) Infant mortality
Normal Lifetime
Approximatively constant
Figura 1.1: Andamento del failure rate di un componente
Una tra le relazioni esistenti tra la funzione di distribuzione dell’affid-
abilita ed il tempo e del tipo:
R(t)=e−λt (1.6)
La 1.6 e nota come legge di fallimento esponenziale ed afferma
che in un sistema a tasso di fallimento costante l’affidabilita decresce
in maniera esponenziale nel tempo.
◦ Safety
Per safety si intende generalmente l’assenza di condizioni di funziona-
mento che possano portare il sistema a danneggiare gli utenti e/o l’am-
biente in cui opera; secondo Laprie safety e ’ the absence of catas-
trophic consequences on the users(s) and the environment..’
[AL04]. Matematicamente la funzione safety S(t) e la probabilita che
non vi siano guasti catastrofici in [0, t] .
6
S(t) = P(!CatastrophicFailures in [0 , t ]) (1.7)
Sebbene una simile definizione sia universalmente accettata in quanto
ben evidenzia gli effetti che potrebbe sortire l’utilizzo di un sistema
unsafe, nel tempo il concetto di safety ha assunto sempre piu i tratti
di un concetto relativo in quanto legato alla soggettiva valutazione dei
rischi e dell’entita dei danni provocati dal sistema.
◦ Performability
Le definizioni di availability e reliability appena discusse, partono dal-
l’assunzione che durante il suo ciclo di vita un sistema possa per-
manere esclusivamente in due stati: il sistema puo essere non disponi-
bile (DOWN) oppure puo essere disponibile e correttamente funzionante
(UP & PROPERLY RUNNING) (cfr. Figura 1.2).
���������������� ����Failure
Repair
���������������� ����Failure
Repair
Figura 1.2: Binary state model
Questa visione semplicistica dei fatti perde di validita qualora si ab-
bia a che fare con sistemi tolleranti ai guasti (fault-tolerant systems):
sistemi del genere infatti, seppure in condizioni di performance degra-
date, riescono ad operare anche in presenza di fallimenti. Il diagramma
7
degli stati per un sistema fault-tolerant sara allora caratterizzato da
un numero di stati superiore a due ovvero da un numero di stati al-
meno pari al numero dei failure che il sistema e in grado di mascherare.
La metrica introdotta per valutare le performance del sistema anche
a valle dell’occorrenza di un fallimento prende il nome di performa-
bility a sottolineare il suo legame con aspetti sia di PERFORMance
evaluation sia di dependABILITY.
◦ Maintainability
La Maintainability, M(t), e generalmente definita come la capacita di
un sistema di poter essere sottoposto a modifiche e riparazioni [AL04]:
un sistema manutenibile e, infatti, un sistema che deve poter esser
facilmente ripristinato in seguito al verificarsi di un guasto.
◦ Security
Sinteticamente la security e definita da Laprie et al. in [J.C00] come
l’assenza di manipolazioni improprie e accessi non autorizzati al sis-
tema. Piu in dettaglio un sistema sicuro e un sistema in cui coesistano
piu attributi:
– availability , opportunamente reinterpretata come la disponi-
bilita del sistema esclusivamente ad utenti autorizzati;
– confidentiality , intesa come la prevenzione di diffusione non
autorizzata di informazioni;
– integrity , ovvero la prevenzione di alterazioni improprie dello
stato del sistema.
La Figura 1.3 sintetizza quanto appena descritto.
8
Maintainability
PerformabilityReliability
Safety
Availability
DEPENDABILITY
SECURITY �����������������������Maintainability
PerformabilityReliability
Safety
Availability
DEPENDABILITY
SECURITY �����������������������Figura 1.3: Attributi di dependability
1.1.3 Dependability measures
Una stima quantitativa del grado di dependability di un sistema puo essere
ottenuta procedendo al calcolo di parametri sintetici tra cui quelli riportati
e descritti in Tabella 1.1
Parametro Acronimo Descrizione
Mean Time To Crash MTTC Tempo medio per avere un crash del sistema
Mean Time Between Crashes MTBC Tempo medio tra due crash successivi del sistema
Mean Time to Failure MTTF Tempo medio per il verificarsi di un failure
Mean Time Between Failures MTBF Tempo medio tra due failures successivi
Mean Number of Instruction to Restart MNIR Numero medio di istruzioni per il ripristino del sistema
Mean Time to Repair MTTR Tempo medio necessario a riparare il sistema
Mean Down Time MDT Tempo medio per cui il sistema non e funzionante
Mean Time Between Errors MTBE Tempo medio tra due errori successivi
Tabella 1.1: Dependability Measures
MTTF ed MTTR - graficamente rappresentati in Figura 1.4- risultano
utili, ad esempio, al calcolo dell’availability secondo la 1.8.
A(t) =MTTF
MTTF + MTTR(1.8)
Con riferimento agli attributi discussi al Paragrafo 1.1.3 e possibile an-
9
MTTFMTTR
MTBF
failedfailedfailedfailed Operating state
MTTFMTTR
MTBF
failedfailedfailedfailed Operating state
Figura 1.4: MTTF,MTBF,MTTR
che fornire un’ulteriore interpretazione del tempo di fallimento e del tempo
di ripristino in termini rispettivamente di reliability e maintainability media:
MTTF = R(t)
MTTR = M(t)
1.2 Dependability threats
Le cause per cui un sistema puo portarsi in uno stato incoerente, e dunque
fallire, sono molteplici e possono manifestarsi in ogni fase del suo ciclo di
vita: guasti hardware, errori in fase di progettazione hardware e/o software
ed errati interventi di manutenzione sono soltanto alcune tra le possibili
sources of failure.
1.2.1 Faults
Un guasto, fault, e uno stato improprio dell’hardware e/o del software del
sistema derivante dal guasto di un componente, da fenomeni di interferenza
o da errori di progettazione. E’ possibile formulare diverse classificazioni dei
10
faults basandosi sulla loro causa (1) (Avizienis 1985 [A.A85]), persistenza
(2), intenzionalita (3) ed origine (4).
1. A seconda della causa che li ha generati i faults possono essere classi-
ficati in:
◦ Physical faults, ovvero guasti del sistema derivanti da problemi
all’hardware, dunque interni, oppure da cambiamenti nelle con-
dizioni ambientali (interferenze, temperatura..), dunque esterni;
◦ Human faults, ovvero guasti derivanti da errori umani commes-
si sia in fase di progettazione (design faults) sia in fase di utilizzo
(interaction faults) del sistema.
2. A seconda della loro persistenza i faults possono essere classificati in:
◦ Permanent (hard) faults, ovvero guasti stabili e continui nel
tempo. Detto t0 l’istante di occorrenza del guasto e tr l’istante
di ripristino, l’intervallo di permanenza in stato failed del com-
ponente affetto dal guasto e [t0, tr];
◦ Transient (soft) faults, ovvero guasti legati a momentanee
condizioni ambientali e che scompaiono definitivamente senza la
necessita di alcuna operazione di ripristino. Detto t0 l’istante di
occorrenza del guasto, l’intervallo di permanenza del componente
corrotto in stato failed e [t0, x] con x non prevedibile;
◦ Intermittent faults, ovvero guasti che si verificano in corrispon-
denza di particolari condizioni ambientali (ad esempio per un
certo valore del carico). Scompaiono senza alcuna azione di ri-
parazione per poi ricomparire. Detto t0 l’istante di occorrenza
del guasto, l’intervallo di permanenza del componente corrotto in
11
stato failed e [t0, x] con x distribuito secondo una determinata
variabile aleatoria strettamente legata al tipo di guasto.
La linea di confine tra guasti intermittenti e guasti transienti sta nel-
la possibilita di applicare eventuali azioni di recupero: alla base di
guasti intermittenti vi sono solitamente anomalie hardware che pos-
sono essere eliminate grazie ad azioni di riparazione o riprogettazione
del componente, mentre alla base di guasti transienti vi sono situazioni
non recuperabili in tal senso in quanto generalmente l’hardware non
risulta danneggiato. Guasti non permanenti si sono rivelati spesso
la maggiore fonte di fallimento per numerosi sistemi; sebbene diver-
si siano stati i tentativi di formularne un modello, ad oggi non es-
iste una soluzione universalmente accettata. Siewiorek [D.P] riporta
i risultati di studi (Andrew file systems, VAX-11780,Tandem TNS-II)
basati sulla data collection e sui conseguenti goodness-of-fit test al fine
di valutare la conformita dell’andamento dei guasti ad una determina-
ta distribuzione statistica: per guasti intermittenti si ottengono buoni
risultati per una distribuzione esponenziale mentre i guasti transienti
sembrano meglio seguire la distribuzione di Weibull.
3. A seconda della loro intenzionalita i faults possono essere classificati
in:
◦ Malicious faults, ovvero guasti introdotti deliberatamente nel
sistema con la volonta di alterarne lo stato provocando una sospen-
sione del servizio o anche di accedere ad informazioni riservate;
◦ Non malicious faults, ovvero guasti introdotti inconsapevol-
mente all’interno del sistema.
12
4. A seconda della loro origine i faults possono essere classificati in:
◦ Internal faults, ovvero guasti riconducibili a cause interne al
sistema (ad esempio l’usura di un componente);
◦ External faults, ovvero guasti riconducibili a particolari con-
dizioni esterne che si ripercuotono sul sistema (ad esempio inter-
ferenze o radiazioni).
Laprie et al. in [AL04] propongono una classificazione dei faults che
racchiude tutte le precedenti e basata sull’individuazione di tre macroclassi
parzialmente sovrapposte (cfr. Figura 1.5)
◦ Development faults class: include tutte le classi di guasto che possono
verificarsi in fase di sviluppo;
◦ Physical faults class: include tutte le classi di guasto legate a guasti
fisici dell’hardware;
◦ Interaction faults class: include tutte le classi di guasto derivanti
dall’interazione del sistema con l’abiente esterno.
1.2.2 Errors
Un errore e la parte dello stato di un sistema che puo indurre lo stesso al
fallimento ovvero a fornire un servizio non conforme alle specifiche (unproper
service). La causa di un errore e un fault (cfr. Paragrafo 1.2.1). Se l’errore
e opportunamente rilevato esso si dice detected, viceversa se l’errore esiste
ma non e rilevato si parla di latent error. Laprie et al. [AL04] propongono
una classificazione degli errori basata sulle categorie di fallimenti che essi
sono in grado di provocare: errori di tempo e di valore, errori catastrofici e
13
Figura 1.5: Tassonomia dei faults (Laprie, 2004)
non catastrofici, errori consistenti ed inconsistenti. E’possibile che un fault
all’interno di uno specifico componente generi errori in piu di un componente
del sistema: in tal caso si parla di multiple related errors.
1.2.3 Failures
Un fallimento, failure, e definito come l’evento in corrispondenza del quale il
sistema cessa di fornire un servizio corretto. Generalmente un sistema non
fallisce sempre alla stessa maniera: le modalita con cui esso puo fallire sono
definite failure modes ed implicano la non correttezza del servizio secondo
diversi punti di vista [AL04]: dominio (1), rilevabilita (2), percezione (3) e
severita del fallimento (4).
1. Un servizio s si ritiene conforme alle specifiche se, detto V l’insieme
dei valori ammissibili e T l’intervallo di tempo in cui esso deve essere
14
fornito (deadline), si ha:
s = s(v, t) : v ∈ V e t ∈ T (1.9)
Dal punto di vista del dominio del fallimento e possibile distinguere:
◦ Timing Failures (fallimenti nel tempo), ovvero fallimenti per
cui un servizio non e conforme alle specifiche in termini di tempo,
ovvero se
s = s(v, t) : v ∈ V e t /∈ T (1.10)
Fallimenti di questo tipo possono essere poi specializzati in ear-
ly timing failures se il servizio e fornito in anticipo, late timing
failures se in ritardo;
◦ Content Failures (fallimenti nel valore), ovvero fallimenti in
seguito ai quali il contenuto informativo del servizio perviene
all’interfaccia in maniera non conforme alle specifica:
s = s(v, t) : v /∈ V e t ∈ T (1.11)
Qualora un sistema fallisca sia nel tempo sia nel valore esso puo fornire
non correttamente il servizio in diverse modalita, tra cui:
◦ halted, il sistema risulta bloccato e dunque il servizio non perviene
all’interfaccia; lo stato esterno del sistema e costante, pari ad
esempio all’ultimo valore. Un particolare fallimento di questo
tipo e il fallimento per omissione del servizio, omission failure,
15
per cui il servizio e a valore nullo e ritardo infinito. Un omission
failure permanente prende il nome di crash failure.
◦ erratic, il servizio perviene all’interfaccia (delivered service) ma
fornisce informazioni incoerenti.
2. Dal punto di vista della rilevabilita del fallimento (failure detectabil-
ity) si distinguono:
◦ Signaled Failures (fallimenti rilevati) ovvero fallimenti segnalati
a livello utente da un opportuno messaggio di errore;
◦ Unsignaled Failures (fallimenti non rilevati) ovvero fallimenti
non segnalati a livello utente.
3. Dal punto di vista della percezione del fallimento (failure consisten-
cy) si distinguono:
◦ Consistent Failures (fallimenti consistenti), per cui tutti gli
utenti del sistema hanno la stessa percezione del fallimento;
◦ Inconsistent Failures (fallimenti inconsistenti), ovvero falli-
menti che possono essere percepiti in maniera diversa dagli utenti
del sistema. Fallimenti di questo tipo sono generalmente indicati
come fallimenti bizantini, Byzantine failures.
4. Dal punto di vista della gravita del fallimento (failure consequences)
si distinguono:
◦ Catastrophic Failures (fallimenti catastrofici), ovvero fallimen-
ti le cui conseguenze sono incommensurabilmente piu grandi del
beneficio prodotto dal servizio fornito in assenza di fallimento;
16
◦ Minor Failures (fallimenti benigni), ovvero fallimenti le cui
conseguenze sono dello stesso ordine di grandezza (valutato gen-
eralmente in termini di costo) del beneficio prodotto dal servizio
fornito in assenza di fallimento.
Un sistema in cui si manifestano esclusivamente fallimenti benigni e un
sistema fail-safe. Una stima quantitativa delle conseguenze dei falli-
menti induce alla definizione di severita del fallimento, failure sever-
ity, strettamente legata al costo necessario per il ripristino, dipendente
dal contesto e generalmente espressa in termini della massima proba-
bilita di occorrenza del fallimento stesso che il sistema e in grado di
sopportare.
Una schematizzazione di quanto appena esposto e riportata in Figu-
ra 1.6.
Figura 1.6: Tassonomia dei fallimenti (Laprie, 2004)
17
1.2.4 Propagazione delle minacce: la catena fault, error,
failure
Fault, error e failure sono legati da una precisa relazione definita in let-
teratura come patologia del guasto [AL04] e schematizzata in Figura 1.7.
Un fault puo degenerare in un errore mediante attivazione (fault activation,
ACT): in tal caso il guasto si dice attivo (active), altrimenti e dormiente
(dormant , DF). Un guasto attivo puo essere un guasto interno oppure un
guasto esterno. L’attivazione di un guasto provoca la transizione del sistema
da uno stato di corretto funzionamento (correct behavior) ad uno stato im-
proprio (error); la rilevazione di un errore e le opportune operazioni di
ripristino (EDP) riportano il sistema ad operare in maniera corretta. Un
errore puo degenerare in un fallimento mediante propagazione all’interfac-
cia utente (EPR); un errore che non porta il sistema nello stato failure e un
errore latente (LE).
CorrectBehavior Error Failure
����� !�"#��"$%& '() *++$+ ,+$-�.��"$%&*,/)012345674896: ;07< =46>56?2212: ;=?<@$� !�"#��AB&@ ) CA�A!�AB�%B,+$!ADDAB&*C,)
@$� !�"#��AB&@ )CorrectBehavior Error Failure
����� !�"#��"$%& '() *++$+ ,+$-�.��"$%&*,/)012345674896: ;07< =46>56?2212: ;=?<@$� !�"#��AB&@ ) CA�A!�AB�%B,+$!ADDAB&*C,)
@$� !�"#��AB&@ )Figura 1.7: Patologia dei guasti
Un fallimento si ha dunque per propagazione di un errore e si verifi-
ca allorquando l’errore si manifesta all’interfaccia del sistema alterando la
correttezza del servizio: per un qualsiasi altro sistema o componente che
usufruisca del servizio corrotto, il fallimento cosı generato si configura quale
18
guasto esterno (external fault) e si parla, piu precisamente, di propagazione
esterna (external propagation). Per propagazione interna, (internal propa-
gation), si intende invece la generazione di errori a cascata all’interno di uno
stesso componente.
Nell’economia generale dello studio della dependability di sistemi dis-
tribuiti, i fenomeni di propagazione esterna assumono un peso rilevante
in quanto rendono spesso difficile l’individuazione del sistema remoto re-
sponsabile del fallimento. In Figura 1.8 e illustrato il meccanismo del-
la propagazione con riferimento al caso particolare di sistemi in cascata.
L’attivazione di un fault dormiente nel sistema A risveglia un errore, prima
…
System A System B
EFGHFIJIKLM EFGHFIJIKLN EFGHFIJIKOMSy
stem
inter
facePQQRQSTUVWXYZW[\Y] _ab_cd efghfijiklikjmnopjPQQRQqd_rsdbtuscvbwb_cd xy PQQRQ SF PQQRQEf
z{_rsdbtuscvbwb_cd|yz{_rsdbtuscvbwb_cd PQQRQ SF
Efxy }c~vcdrd_�bt�sr SF ���_r~�bt�sr z{_rsdbt�b�t_…
System A System B
EFGHFIJIKLM EFGHFIJIKLN EFGHFIJIKOMSy
stem
inter
facePQQRQSTUVWXYZW[\Y] _ab_cd efghfijiklikjmnopjPQQRQqd_rsdbtuscvbwb_cd xy PQQRQ SF PQQRQEf
z{_rsdbtuscvbwb_cd|yz{_rsdbtuscvbwb_cd PQQRQ SF
Efxy }c~vcdrd_�bt�sr SF ���_r~�bt�sr z{_rsdbt�b�t_Figura 1.8: Propagazione esterna dei guasti
latente, nel componente A1; per via di fenomeni di propagazione interna,
l’errore perviene all’interfaccia del componente stesso portandolo al fallimen-
to (CF, Component Failure) ed inducendo - a mezzo di una propagazione
esterna- l’alterazione del servizio offerto al componente a valle (A2) a cui
detto fallimento si presenta quale guasto esterno (EF,External Fault). At-
traverso A2 le minacce raggiungono l’interfaccia del sistema A provocandone
il fallimento (SF, System Failure) e ripercuotendosi sul sistema B per via di
fenomeni di propagazione esterna sotto forma di guasto esterno (EF).
19
1.3 Dependability means
Le tecniche per incrementare il grado di dependability di un sistema sono
diverse e si differenziano per il modo con cui si relazionano all’occorrenza di
un fault. La scelta della particolare strategia da utilizzare e inesorabilmente
influenzata dalla natura del sistema e dunque da quale sia il dependability
attribute che si e interessati a massimizzare.
1.3.1 Fault avoidance
La fault avoidance, o anche fault intolerance, e una tecnica orientata esclu-
sivamente a minimizzare la probabilita di occorrenza dei fallimenti. Le piu
elementari tecniche di fault avoidance si basano sull’utilizzo di componenti
altamente affidabili -con riferimento all’hardware- e sulla conduzione di cap-
illari attivita di testing -con riferimento al software- inducendo un sensibile
aumento dei costi di messa in esercizio del sistema. In alcuni casi possono
essere utilizzate tecniche di fault avoidance per scongiurare un particolare
tipo di fallimento: ad esempio la riduzione del fan-out delle porte logiche
riduce la dissipazione di potenza e dunque riduce la probabilita che si ver-
ifichino hard failures. Ad ogni modo anche la piu complessa strategia di
fault avoidance non puo scongiurare del tutto l’occorrenza di fallimenti che
quindi non saranno tollerati dal sistema, da qui fault intolerance.
1.3.2 Fault tolerance
Le tecniche di fault tolerance mirano alla minimizzazione delle conseguenze
dei guasti sul sistema e dunque ad evitare che essi possano degenerare in fal-
limenti (failure avoidance). Un sistema fault tolerant e dunque un sistema
in grado di continuare ad essere operativo, pur se eventualmente in con-
20
dizioni degradate, nonostante l’occorrenza di guasti. Strategie di tolleranza
ai guasti sono generalmente articolate in due passi (cfr. Figura 1.9):
1. Error detection ;
2. Error treatment e System recovery.
Figura 1.9: Strategie di tolleranza ai guasti (Laprie, 2004)
Nella prima fase si procede alla scoperta di eventuali errori nel sis-
tema e alla loro segnalazione. Laprie et al. [AL04] individuano due possibili
strategie di detection:
◦ Concurrent Detection che ha luogo durante il normale funziona-
mento del sistema e dunque durante il delivering dei servizi;
◦ Preemptive Detection che ha luogo durante i periodi di sospen-
sione del servizio e mira all’individuazione di eventuali errori latenti
nel sistema.
Il secondo passo consiste nel ripristino del normale funzionamento del
sistema attraverso la rimozione dell’errore dal sistema, error treatment, ed un
21
insieme di operazioni mirate ad evitare che lo stesso possa attivare dei fault
oppure che faults gia verificatisi possano essere riattivati, fault handling.
Come illustrato in Figura 1.9, la rimozione dell’errore puo avvenire in tre
diverse modalita:
◦ Rollback : consiste nel riportare il sistema all’ultimo stato stabile in
cui permaneva prima dell’individuazione dell’errore, chekpoint ;
◦ Rollforward : consiste nel riportare il sistema senza errori in un nuovo
stato;
◦ Compensation : si utilizza quando il sistema e dotato di componenti
ridondanti a sufficienza per poter mascherare l’errore.
Il fault handling, ancora secondo Laprie [AL04], si articola invece nei
seguenti passi:
◦ Diagnosis, ovvero l’individuazione dell’errore sia in termini di lo-
cazione sia di istante di occorrenza;
◦ Isolation , ovvero la procedura di esclusione del componente fallito dal
resto del sistema in modo da evitare che possa corrompere la fornitura
di altri servizi;
◦ Reconfiguration , ovvero la riassegnazione dei task in corso al mo-
mento dell’errore a componenti integri;
◦ Reinitialization , ovvero il ripristino totale del normale comporta-
mento del sistema mediante l’aggioramento delle informazioni modifi-
cate dalle operazioni precedenti.
22
Generalmente alle procedure di fault handling seguono operazioni di
manutenzione correttiva, corrective maintainance, per riparare -off-line- i
componenti isolati perche guasti.
1.3.2.1 Tecniche di fault tolerance
La tolleranza ai guasti e nella maggior parte dei casi ottenuta grazie all’uti-
lizzo di tecniche di ridondanza nelle sue due possibili realizzazioni:
◦ ridondanza spaziale, ossia l’utilizzo di componenti hardware e software
replicati in grado di sostituire il componente guasto;
◦ ridondanza temporale, ossia l’esecuzione ripetuta di determinate oper-
azioni -o di sequenze di operazioni- particolarmente utile nel caso di
guasti transienti.
La piu elementare forma di ridondanza spaziale e certamente la repli-
cazione che prevede l’utilizzo di componenti gemelli e la valutazione della
correttezza dello stato del sistema mediante aggiudicazione. Una strategia
di questo tipo consente di rilevare gran parte dei guasti relativi ai singoli
componenti del sistema ma non quelli del componente “aggiudicatore” che
viene dunque definito un single point of failure. E’evidente che al crescere del
numero N delle repliche (N-modular redundancy, NMR), si assiste ad una
proporzionale crescita dei costi ma anche una maggiore affidabilita nelle de-
cisioni che, per ogni valore di N (per N = 3 l’architettura e nota con il nome
di Triple Modular Redundancy, TMR), sono prese a maggioranza secondo
la politica del N − 1 out-of-N) da un voter V . Per N comunque elevato V
resta pero il single point of failure dell’intero sistema: il problema e noto in
letteratura come il ’Who shall watch over the guardians?’ e resta un prob-
23
lema mai completamente risolvibile. Una stima quantitativa dell’efficacia
delle tecniche di tolleranza ai guasti prende il nome di coverage.
1.3.2.2 Stati di un sistema fault tolerant
Dal Paragrafo 1.3.2 emerge che un sistema tollerante ai guasti e un sistema
che e in grado di funzionare anche al manifestarsi di guasti. A seconda del
modo in cui esso reagisce ad un fault puo pervenire ad una serie di diverse
condizioni di funzionamento che sono sintetizzate nel diagramma degli stati
di Figura 1.10.
Figura 1.10: Diagramma degli stati di un sistema fault tolerant
Il diagramma evidenzia due stati principali, operational e failed, a loro
volta organizzati in maniera gerarchica. Lo stato operational consiste di
due sottostati: recovering, in cui il sistema e attivo ma impegnato nell’at-
tuazione di procedure di recovery, oppure ready ovvero funzionante. Un
sistema funzionante puo a sua volta essere accessible se e in grado di rispon-
24
dere alle richieste degli utenti, o inacessible se, ad esempio, e funzionante
ma guasti della rete gli impediscono di soddisfare le richieste. Un’organiz-
zazione analoga e prevista per lo stato failed : un sistema puo essere dead,
se non e stato in grado di ripristinare il suo funzionamento in seguito ad un
guasto, oppure under repair se e al momento sottoposto a manutenzione.
Se dopo le azioni di riparazione e possibile ripristinare lo stato del sistema
antecedente al fallimento allora esso si dice in stato recoverable, altrimenti
unrecoverable.
1.3.3 Fault removal
Le tecniche di fault removal mirano all’individuazione degli errori ed alla
rimozione di eventuali guasti. Esse possono essere messe in opera sia du-
rante lo sviluppo del sistema, Fault removal during development (1),
sia durante il suo normale utilizzo, Fault removal during use (2).
1. La rimozione dei guasti in fase di sviluppo si articola in tre fasi :
◦ verification, in cui si procede a valutare la conformita del com-
portamento del sistema a specifiche preassegnate;
◦ diagnosis, in cui si procede ad identificare la natura di eventuali
errori;
◦ correction, in cui si procede alla correzione degli errori evidenziati
in fase di diagnosi e dopo la quale si ripete la fase di verifica per
accertarsi dell’avvenuta rimozione (validation).
Il problema della verifica puo essere affrontato in diversi modi come
sintetizzato nello schema di Figura 1.11.
Se la verifica viene effettuata sul sistema non in esercizio si parla di
static verification, al contrario di dynamic verification. La verifica
25
Figura 1.11: Strategie di verifica (Laprie, 2004)
dinamica avviene fornendo al sistema degli input, reali o simbolici,
ed osservando la conformita delle uscite alle specifiche preassegnate:
una verifica di questo tipo prende generalmente il nome di testing .
E’ evidente che qualora si voglia sottoporre il sistema ad input re-
ali, non e possibile effettuare un testing completamente esaustivo e
pertanto si procede alla generazione dei casi di test (test patterns)
in maniera deterministica, ovvero selezionando a priori gli ingressi da
fornire al sistema, oppure in maniera random. In quest’ultimo caso la
distribuzione ed il numero degli ingressi da fornire al sistema e scelto
in accordo al fault model del sistema stesso. Osservare gli output e sta-
bilire se il comportamento del sistema e conforme o meno alle specifiche
costituisce il problema dell’oracolo (oracle problem, cfr. Figura 1.12).
2. La rimozione dei guasti durante il normale utilizzo del sistema consiste
in azioni di manutenzione preventiva e/o correttiva.
1.3.4 Fault forecasting
Le tecniche di fault-forecasting, letteralmente “previsione dei guasti”, for-
niscono mezzi per aumentare il livello di confidenza che puo essere riposto
nella capacita del sistema di fornire un servizio conforme alle sue speci-
26
����� �� �����������������������
������������������������ �����������������
����� �� �����������������������
������������������������ �����������������
�� �����������������������
������������������������ �����������������
Figura 1.12: Fault Removal During Development
fiche [J.C95]. Esistono due diversi approcci, non in contrasto tra loro, per
realizzare fault-forecasting :
◦ approccio deterministico o qualitativo, i cui metodi mirano a com-
prendere quali siano gli effetti dei guasti sul malfunzionamento del
sistema;
◦ approccio probabilistico o quantitativo, i cui metodi mirano a stimare
gli attributi di dependability del sistema.
Generalmente e necessario combinare i due approcci per ottenere stime
affidabili soprattutto nel caso di sistemi complessi.
1.4 La failure data analysis
L’efficacia delle tecniche di dependability enhancement descritte finora pre-
suppone un’adeguata conoscenza del comportamento del sistema: la carat-
terizzazione statistica dei failure modes, accanto alla formulazione di modelli
realistici, incrementa la predicibilita del sistema stesso facilitando l’appli-
cazione di mirate azioni preventive e/o correttive. La failure data analysis,
attraverso l’esame di dati relativi ai fallimenti, si configura quale strumento
27
per la valutazione della dependability di un sistema fornendo informazioni
utili sia alla costruzione di un modello di riferimento sia alla progettazione
di nuovi sistemi. R.Iyer et al. in [R.K00] evidenziano come ai fini dell’analisi
della dependability di un sistema assuma rilevante importanza il binomio cos-
tituito dalla fase del ciclo di vita in cui si e scelto di operare e dal particolare
strumento di valutazione utilizzato.
In fase di progettazione, design phase, lo studio dell’affidabilita del sis-
tema puo essere condotto utilizzando software di simulazione: il sistema
viene volontariamente sottoposto a situazioni di errore (simulated fault-
injection) con il duplice obiettivo di individuare eventuali dependability bot-
tlenecks e di stimare la coverage dei meccanismi di fault tolerance. I feedback
derivanti dallo studio delle reazioni del sistema risultano particolarmente
utili ai system designers in un’ottica di riprogettazione cost-effective.
A progettazione ultimata, viene generalmente rilasciata una versione
prototipale del sistema affinche esso possa essere sottoposto alle dovute at-
tivita di testing. In questa fase il sistema viene sollecitato con profili di carico
ad hoc (controlled workloads) per poter studiare le sue reazioni a faults reali
(physical fault-injection), le sue capacita di recupero in seguito a situazioni
di errore (recovery capabilities) e l’efficacia delle tecniche di detection (de-
tection coverage). Uno studio di questo tipo fornisce informazioni circa il
failure process del sistema (cioe la sequenza di stati che esso attraversa dal
momento in cui si verifica l’errore fino all’eventuale recovery) ma non con-
sente di valutare misure di dependability quali MTTF, MTTR dal momento
che saranno stati considerati esclusivamente fault artificiali. E’ importante
sottolineare che, a differenza di quanto accade in fase di progettazione, in
fase prototipale e possibile iniettare guasti anche a livello software.
In fase di normale utilizzo del sistema, e dunque quando esso e ormai
28
completamente operativo, e possibile valutarne la dependability mediante
un’analisi sul campo ovvero analizzandone il comportamento in risposta a
profili di traffico reali: un approccio di questo tipo, noto in letteratura come
field failure data analysis, consente di ottenere informazioni relative esclusi-
vamente agli errori rilevati durante il periodo di osservazione e la caratteriz-
zazione statistica che se ne puo dedurre pecca in termini di generalita vista
l’infinita varieta di situazioni reali in cui il sistema puo trovarsi. Ad ogni
modo, secondo R.Iyer [R.K00] “...there is no better way to understand
dependabilty characteristics of computer systems (including net-
worked systems) than by direct measurements and analysis...”: il
Paragrafo 1.4.1 illustra i dettagli di un simile approccio.
1.4.1 Field failure data analysis
L’analisi della dependability di un sistema basata su un approccio di tipo
measurement-based si articola in quattro fasi successive: elaborazione dei
dati (1), identificazione del modello e stima dei parametri (2), soluzione del
modello (3), analisi del modello e misure (4) (cfr. Figura 1.13).
Figura 1.13: Fasi della field failure data anlysis (Iyer, 2000)
1. Per consentire l’elaborazione dei dati e necessario che essi siano stati
preventivamente raccolti mediante operazioni di logging (automatico
o manuale) in una quantita tale da poter far sı che i risultati del-
l’analisi assumano rilevanza statistica: in altre parole, vista la bassa
29�� ¡¢ £¡¤¥¦¢£§¨¢©¤ª¥§ ¦§§�§£ «¥ ¬¥¡®¥¡¯ ¦§§�§¯¥°®§¡«£¡�¢�� ¡¢ £¡¤¥¦¢£§¨¢©¤ª¥§ ¦§§�§£ «¥ ¬¥¡®¥¡¯ ¦§§�§¯¥°®§¡«£¡�¢Figura 1.14: Esempio di log entry
frequenza di fallimento dei moderni sistemi, e necessario che le attivita
di misurazione siano condotte su un arco temporale sufficientemente
lungo. La fase di elaborazione dei dati in senso stretto, data process-
ing, consiste nella opportuna manipolazione del file di log (a), nella
classificazione degli errori (b), nell’estrazione dei dati di interesse e
nell’applicazione di algoritmi di coalescenza (c).
1.a. Generalmente le informazioni contenute nei file di log (in parti-
colare nel caso di logging automatico on-line) sono ridondanti e
riportate in formati differenti che e bene uniformare al fine di
facilitare le successive operazioni di calcolo;
1.b. La classificazione degli errori non e una classificazione univer-
sale ma varia a seconda del sistema in esame. Con riferimento
ad un networked system, ad esempio, e possibile classificare gli
errori in base alla loro origine e quindi individuare errori legati
alle singole macchine (machine-related) o a problemi della rete
(network-related).
1.c. I dati necessari all’analisi vengono estratti dal file di log e riscritti
in un flat format in modo tale che ogni entry contenga soltanto
le informazioni necessarie all’analisi; un esempio e riportato in
Figura 1.14.
Per evitare poi che l’analisi sia polarizzata da piu entry relative
allo stesso errore e riportate sul log file a distanza ravvicinata
30
e necessario applicare algoritmi di coalescenza ovvero algoritmi
in grado di compattare in un unico evento (tupla) le entry il cui
timestamp rientri in un certo intervallo ∆, piu esplicitamente:
if((errorType)==(typeOfPreviousError)&&(timeAwayFromPreviousError)<Delta)
put this entry in tuple being built;
else start a new tuple;
La scelta del valore di ∆ e critica in quanto puo generare fenomeni
di collisione se troppo piccolo, di troncamento altrimenti.
2. Avendo a disposizione i dati nel formato e nella quantita opportu-
ni, e possibile in questa fase cominciare ad individuare il modello del
sistema e a valutarne i parametri pure se in via preliminare. I model-
li generalmente piu utilizzati in questa fase sono le catene di Markov,
modelli ciclostazionari che evidenziano la dipendenza dal carico e mod-
elli statistici di correlazione error/failure. I valori tipicamente stimati
fanno riferimento alla frequenza di errori e fallimenti (TTE, TTF ) e
all’availability del sistema; strumenti di calcolo statistico (ad esem-
pio SAS 1) risultano particolarmente utili a questo punto dell’anal-
isi. Va detto poi che per sistemi networked e in questa fase che si
procede alla differenziazione del comportamento dei singoli host dal
comportamento dell’intero dominio (cfr. Paragrafo 1.5).
3. In questa fase si procede, se necessario, alla soluzione del modello
al fine di ottenere risultati precisi relativamente alla reliability e all’
availability del sistema con l’ausilio di strumenti di modellazione e val-
utazione delle performance (ad esempio SHARPE [Tri02]). Per siste-
mi networked assume importanza centrale l’analisi della propagazione
1http://www.sas.com/
31
dei guasti all’interno della rete e la valutazione dei parametri ad essa
correlati.
4. A valle del calcolo dei parametri piu significativi si procede, in questa
fase, all’interpretazione dei risultati adottando metodi di analisi che
possono significativamente variare a seconda del sistema e degli scopi
dell’analisi stessa.
1.5 Un caso di studio: Windows NT
In questa sezione si riporta l’applicazione delle metodologie discusse al Para-
grafo 1.4 ad una rete locale (LAN, Local Area Network) di 68 workstations
WindowsNT [R.K00]. In Tabella 1.2 sono sintetizzati i parametri relativi
alla sessione di test.
Tipo di macchine Mail Servers , Windows NT 4.0
Numero di macchine 68
Periodo di raccolta 6 mesi
Fallimenti rilevati Reboots
Tabella 1.2: Parametri del test
Raccolta dei dati: event logging in WindowsNT
La modalita di raccolta dei dati per cui si e optato in questa sessione di test e
la modalita di logging automatico e dunque utilizza il meccanismo di cattura
degli eventi offerto dal sistema operativo (S.O.) che, nel caso di Windows-
NT, e gestito da un apposito Event Logging Subsystem. Per la cattura di
eventi generati da applicazioni di utente sono disponibili apposite API (Ap-
plication Programming Interface) mentre per eventi generati dall’Executive
(componente del S.O. WindowsNT che viene eseguito in modalita privilegia-
32
ta) la cattura e ad opera di un apposito I/O manager. WindowsNT prevede
la classificazione degli eventi in tre gruppi:
1. Application events, ovvero gli eventi generati dalle applicazioni in
esecuzione su macchine NT (ad esempio MTA, message transfer Agent);
2. System events, ovvero gli eventi generati dai componenti di Win-
dowsNT (ad esempio il NETLOGON service...);
3. Security events, ovvero gli eventi generati da operazioni di login/l-
ogout degli utenti o di verifica dei diritti di accesso.
Il sistema di logging associa ad ogni evento le seguenti informazioni:
◦ Date and time;
◦ Event Severity ;
◦ Event id ;
◦ Event Source;
◦ Machine name;
◦ Event specific information.
Estrazione dei dati, classificazione degli errori e coalescenza
Dal momento che i dati di interesse per il test in esame sono relativi esclu-
sivamente ai reboots delle workstations, l’operazione di estrazione dei dati
consiste nell’individuare le voci relative al reboot in senso stretto ma an-
che agli eventi ad esso correlati, prominent events. La selezione di eventi di
questo tipo avviene isolando le voci relative ad eventi che precedono il reboot
nell’arco di un’ora; una scelta di questo genere e nella maggior parte dei casi
33
sufficiente a spiegare dettagliatamente la causa del reboot ma in determinate
circostanze il numero di eventi selezionato basta a fornire soltanto una de-
scrizione di alto livello del problema. Nel caso in cui fossero stati registrati
piu eventi di reboot nell’arco di un’ora le voci ad essi relative vengono collas-
sate nell’unica tupla corrispondente all’ultimo evento (reboot piu giovane).
In Tabella 1.3 sono riportati i risultati relativi alla suddivisione degli eventi
di reboot in base alla natura dei prominent events:
Categoria Frequenza Percentuale
Total Reboots 1100 100
Hardware or firmware problems 105 9
Connectivity problems 241 22
Crucial Application failures 152 14
Problem with a sw component 42 4
Normal shutdowns 63 6
Normal reboots 178 16
Unknown 319 29
Tabella 1.3: Breakup dei reboot in base ai prominent events (Iyer, 2000)
Sulla scorta dei risultati in Tabella 1.3 e possibile fare interessanti con-
siderazioni preliminari sul comportamento del sistema:
1. Nel 29% dei casi i reboots non possono essere classificati (unknown):
cio a dire che non si dispone di informazioni sufficenti a risalire alla
causa del problema;
2. Gli errori legati a problemi hardware sono in piccola percentuale (circa
10%) e dunque gran parte dei fallimenti e software related ovvero da
imputarsi a problemi di natura software;
3. Una percentuale significativa degli errori (circa il 22%) e lagata a prob-
lemi di connettivita: questo comportamento era prevedibile dal mo-
mento che il workload in esecuzione sulla rete e fortemente I/O inten-
sive. E’importante pero notare che problemi di questo tipo potrebbero
34
derivare dalla propagazione di errori propri di altre macchine del do-
minio: una stima piu precisa della quantita di errori ‘riflessi ’ non e
ancora ottenibile in questa fase di valutazione preliminare.
Analisi e modellazione del comportamento di un host
Nell’ambito di un sistema networked e bene riuscire a comprendere il com-
portamento dei singoli host al fine di poter valutare parametri locali quali
ad esempio Down times, Up times (1) e l’Availability(2).
1. Detti
◦ Ri la i − sima istanza di reboot registrata sul log;
◦ TRi il timestamp relativo al reboot i − simo;
◦ E[j] la j − sima istanza di un evento generico registrata sul log;
◦ TE[j] il timestamp relativo all’evento j − simo;
◦ Event[n] il vettore degli eventi compresi tra Ri ed R(i+1) ;
◦ Event[m] il vettore degli eventi compresi tra R(i−1) ed R(i) ;
i tempi di attivita ed inattivita sono stati calcolati come segue:
UpTime[i] = TRi − TE[n−1] ∀i = 1...nReboots
DownTime[i] = TE[m−1] − TRi ∀i = 1...nReboots
UpTime =∑nReboots
i=1 UpTime[i]
DownTime =∑nReboots
i=1 DownTime[i]
In Tabella 1.4 sono riportati i valori dei tempi di up e down.
35
Up time Down time
Item Value Value
Number of entries 616 682
Maximum 85.2 days 15.76 days
Minimum 1 hour 1 second
Average 11.82 days 11.43 minutes
Standard deviation 15.656 days 15.86 hours
Tabella 1.4: Statistiche sui tempi di up e down
2. La percentuale di tempo per cui un host e available e stata calcolata
secondo la 1.12.
A =UpTime
UpT ime + DownTime(1.12)
Item Value
Number of machines 66
Maximum 99.9
Minimum 89.39
Average 99.35
Standard deviation 1.52
Tabella 1.5: Statistiche sulle percentuali di Availability
I risultati relativi all’availability (cfr. Tabella 1.5) sono coerenti con
l’interpretazione della stessa di cui alla 1.2 ossia indicano la percentuale
di tempo per cui il sistema e operativo ma non assicurano che per l’intera
durata dell’intervallo il sistema abbia fornito un servizio corretto. Al fine
ottenere una stima piu accurata dell’availability si procede alla formulazione
di un modello del sistema (nella fattispecie un singolo host) pervenendo al
diagramma degli stati di Figura 1.15 in cui ogni stato rappresenta un livello
di funzionalita della macchina. I valori riportati sugli archi del diagramma
indicano le probabilita di transizione tra gli stati e sono state valutate effet-
36
tuando la suddivisione del file di log in finestre temporali di ampiezza pari
a un’ora.
Figura 1.15: Modello a stati finiti di un singolo host (Iyer, 2000)
Analisi e modellazione del comportamento del dominio
L’analisi del sistema dal punto di vista del’intero dominio e finalizzata al-
la comprensione delle interazioni tra i singoli hosts e all’individuazione di
eventuali bottlenecks all’interno della rete. Per reboot del dominio si in-
tende il reboot di almeno una delle macchine che ne fanno parte e dunque
la probabilita che esso si verifichi e data dalla 1.13
P (Rdomain) =nmachines
∑
i=1
P (Ri) (1.13)
Analogamente a quanto visto con riferimento ad un singolo host, an-
che nel caso dell’intero dominio e stato necessario formulare un modello
37
(cfr. Figura 1.16) per ottenere stime sufficientemente accurate dei parametri
di dependability.
Figura 1.16: Modello a stati finiti del dominio (Iyer, 2000)
L’interpretazione degli stati individuati dal modello e riportata in Tabel-
la 1.6.
State Name Meaning
PDC Primary Domain Controller rebooted
BDC One of Backup Domain Controller rebooted
MDBC Many Backup Domain Controller rebooted
PDC+BDC PDC+ 1 BDC rebooted
PDC+MBDC PDC+ many BDC rebooted
F Functional
Tabella 1.6: Interpretazione degli stati del modello del dominio (Iyer, 2000)
Osservando le probabilita di transizione riportate sul diagramma di Figu-
ra 1.16 e possibile trarre alcune importanti conclusioni:
◦ Una percentuale significativa di transizioni avvengono dallo stato F al-
lo stato MDBC ed e dunque ragionevole pensare che vi sia correlazione
tra i guasti dei vari BDC (Backup Domain Controller);
38
◦ La maggior parte delle transizioni in uscita dallo stato PDC sono
indirizzate allo stato F a significare che il PDC (Primary Domain
Controller) riesce a concludere le azioni di ripristino prima che possano
verificarsi fenomeni di propagazione e/o che i problemi relativi al PDC
non vengono per loro natura propagati ai BDCs.
Da quanto appena discusso e dall’analisi del grafico di Figura 1.17,
che illustra la distribuzione dei tempi di inter reboot, e possibile eviden-
ziare l’entita dei fenomeni di propagazione all’interno del sistema nel suo
complesso.
Figura 1.17: Distribuzione dei tempi di inter-reboot
Lo studio di detti fenomeni e stato condotto effettuando la seguente
classificazione dei prominent events che hanno generato reboot del dominio
( e dunque di almeno uno dei singoli host):
◦ local machine related problems, ovvero problemi relativi solo alla macchi-
na che e stata riavviata;
◦ remote machine related problems, ovvero problemi di connettivita legati
ad errori su una macchina remota;
39
◦ general network related problems, ovvero problemi di rete di cui non si
conoscono ulteriori dettagli.
Informazioni circa gli eventi di reboot sono state scritte sul file di log
di un singolo in maniera tale da contenere i dettagli di tutti gli eventi ver-
ificatisi all’interno del dominio nell’arco di un’ora: in altre parole, il file
di log di un singolo host contiene non solo informazioni riguardanti l’host
stesso ma anche relative a tutte le altre macchine del dominio e alla loro
attivita nelle ore che hanno preceduto e seguito il reboot. Per i dettagli sul
formato utilizzato per la registrazione delle informazioni si veda [R.K00] al
Paragrafo 9.
A valle della processazione delle informazioni cosı raccolte si evince che
la maggior parte dei fallimenti del dominio e dovuta a problemi dei sin-
goli host e non a fenomeni di propagazione sebbene vi sia una discreta
percentuale di fallimenti la cui fonte e risultata non classificabile (unknown).
Bibliografia
[A.A85] A.Avizienis. The n-version approach to fault tolerant
software. IEEE Transaction on Software Engineering,
(12):1491–1501, 1985.
[A.A01] B. Randell A.Avizienis, J.C. Laprie. Fundamental concepts of
computer system dependability. IARP/IEEE-RAS Workshop
on Robot Dependability, May 21-22 2001.
[AL04] J.C. Laprie B.Randell A.Avizienis and C. Landwehr. Basic
concepts and taxonomy of dependable and secure comput-
ing. IEEE Transactions on Dependable and Secure Comput-
ing, VOL. 1, NO. 1, JANUARY-MARCH 2004, 1(1):11–33,
January-March 2004 2004.
[AT96] R.Iyer A. Thakur. Analyze-now - an environment for col-
lection & analysis of failures in a network of workstations.
IEEE Transactions on Reliability, VOL. 45, NO. 4, 1996
DECEMBER, 45(4):561–570, December 1996.
[Bar04] J.E. Bardram. Applications of context aware comput-
ing in hospital work.examples and design principles. 2004
ACM Symposium on Applied Computing Proceedings, pages
1574–1579, March 14-17 2004.
40
41
[Bes03] A. Abdul Aziz R. Besar. Application of mobile phone in med-
ical image transmission. 4th National Conference on Telecom-
munication Technology Proceedings, Shah Alam, Malaysia,
pages 80–83, 2003.
[CF03] B. Lyles C. Cotton M. Khan D. Moll R. Rockell T. Seely
S.C. Diot C. Fraleigh, S. Moon. Packet-level traffic measure-
ments from the sprint ip backbone. IEEE Network, 17:6–16,
2003.
[C.P05] C.Pagliara.La nuova convergenza
http://www.pec-forum.com/letture/TELECOM.pdf , Giugno,7 2005.
[D.C03] S.Garg D.Chen. Dependability enhancement for ieee
802.11wireless lan with redundancy techniques. Proceedings
of the 2003 International Conference on Dependable Systems
and Networks (DSN 2003), 2003.
[DCT03] C. Kintala D. Chen, S. Garg and K. S. Trivedi. Dependability
enhancement for ieee 802.11 with redundancy techniques. In-
ternational Conference on Dependable Systems and Networks
(DSN 2003), Proceedings, June 2003.
[DDDD04] M. Elangovan D. D. Deavours and J. E. Dawkins. User-
perceived interoperability of bluetooth devices. Technical
report, The University of Kansas 2335 Irving Hill Road,
Lawrence, KS 66045-7612, June 2004.
[D.P] R.S.Swarz D.P.Siewiorek. Reliable Computer Systems. A K
Peters, 3th edition.
42
[D.S98] L. Bass J. Siegel R. Martin B. Bennington D.Siewiorek,
A.Smailagic. Adtranz: A mobile computing system for
maintenance and collaboration. Second IEEE Internation-
al Conference on Wereable Computers, Proceedings, Ottobre
1998.
[E.F04] M.Lampe M.Strassner E.Fleisch. A ubiquitous computing en-
vironment for aircraft maintenance. 2004 ACM Symposium
on Applied Computing Proceedings, pages 1586–1592, March
14-17 2004.
[Hel96] A.Heddaya A. Helal. Reliability, availability, dependabil-
ity andperformability: A user-centered view. Available
as hhttp://www.cs.bu.edu/techreports/97-011-reliability-def.ps.Zi,
December 4 1996.
[HP98] S. Furner T. Strothotte H. Petrie, V. Johnson. Design
lifecycles and wearable computers for users with disabili-
ties. Proceedings of the First Workshop on Human Computer
Interaction with Mobile Devices, May 1998.
[IG05] K.Stordahl I.G. Gjerde, R.Venturin. Forecasting mobile mar-
ket development. 8th International Conference on Telecom-
munications , ConTEL 2005, Proceedings, pages 219–224,
June,15-17 2005.
[J.C95] J.C.Laprie. Dependability, Its Attributes, Impariments and
Means, volume Predictably Dependable Computing Systems,
Randell B., Laprie J.C., Kopetz H.andLittlewood B., pages
3–24. Springer-Verlag, 1995.
43
[J.C00] B.Randell J.C.Laprie, A.Avizienis. Fundamental Concepts
of Dependability,. Third Information Survivability Workshop
Proceedings, Oct, 24-26 2000.
[JJ99] A.Elmagarmid J. Jing, A. Helal. Client-server computing in
mobile environments. ACM Computing Surveys, 31(2):118–
157, June 1999.
[MB03] S. Lo Presti D. Allsopp P. Beautement C. Booth M. Cusack
M. Kirton M. Butler, M. Leuschel. Towards a trust analysis
framework for pervasive computing scenarios. 6th Interna-
tional Workshop on Trust, Privacy, Deception, and Fraud in
Agent Societies (AAMAS 2003), 2003.
[MC05] D. Cotroneo C. Pirro S. Russo M. Cinque, F. Cornevil-
li. Bluetooth field failure data analysis. Tech-
nical report, FIRB Technical Report, CINI Napoli,
https://web-minds.consorzio-cini.it/servizi/intranet/
/buro/docs/BT_Field_Failure_Analysis.pdf, January 2005.
[MEC96] A. Bestavros M. E. Crovella. Self-similarity in world wide web
traffic: evidence and possible causes. Proc. of the 1996 ACM
SIGMETRICS international conference on Measurement and
modeling of computer systems, 1996.
[M.G00] R.Kapoor F.Vatalaro M.Gerla, P.Johnssen. Bluetooth: ’last
meter’ technology for nomadic wireless internetting. Proceed-
ings of the 12th Tyrrhenian International Workshop on Dig-
ital Communications (TIWDC 20000) 14. - 17. September
2000, September, 14-17 2000.
44
[PL] R. Beale M. Sharples C. Baber P. Lonsdale, W.Byrne. Spatial
and context awareness for mobile learning in a museum. KAL
CSCL Workshop on ’Spatial Awareness and Collaboration’,
Proceedings.
[PS04] H.Hulkko T.Ihme J. Jaalinoja M. Korkala J. Koskela P. Kyllo-
nen P.Abrahamsson, A.Hanhineva and O. Salo. Mobile-d: An
agile approach for mobile application development. OOPSLA
2004, British Columbia, Canada. Oct. 24-28, 2004.
[R.G03] R.Ghandi. Tolerance to access-point failures in dependable
wireless lan. Proc. of the 9th Int. Workshop on Object-
Oriented Real-Time dependable Systems (WORDS 2003),
June 2003.
[RJ04] A. Lafuente M. Larrea A. Uribarren R. Jimeno, Z. Salvador.
An architecture for the personalized control of domotic re-
sources. Adjunct Proceedings of the 2nd European Sympo-
sium on Ambient Intelligence, EUSAI 2004, pages 51–53,
November 2004.
[R.K00] M.Kalyanakrishnan R.K.Iyer, Z.Kalbarczyk. Measurement
based analysis of networked system availability. Lecture Notes
In Computer Science, Vol. 1769:161 – 199, 2000.
[RKSZ04] M. S. Squillante R. K. Sahoo, A. Sivasubramaniam and
Y. Zhang. Failure data analysis of a large-scale heterogeneous
server environment. proc. of the 2004 International Confer-
ence on Dependable Systems and Networks (DSN 2004), June
2004.
45
[rndBncsd04] Dati IDC 2004 resi noti da Belkin nel comunicato stampa del
29/10/2004.
http://web.belkin.com/presspage/Releases/29.10.04_IT_PR_Bluetooth1.htm,
October, 29 2004.
[SCS04] L. Lin S. Bagchi S. Cabuk, N.Mahlotra and N. Shroff. Analysis
and evaluation of topological and application characteristics of
unreliable mobile wireless ad-hoc network. 10th IEEE Pacific
Rim International Symposium, Proceedings, 2004.
[SIG01a] Bluetooth SIG.
Bluetooth network encapsulation protocol (bnep) specifica-
tion. http://grouper.ieee.org/groups/802/15/Bluetooth/BNEP.pdf, June
2001.
[SIG01b] Bluetooth SIG.Personal area networking profile.
http://grouper.ieee.org/groups/802/15/Bluetooth/PAN-Profile.pdf,
June 2001.
[SIG03] Bluetooth SIG. Bluetooth core specification v1.2.
https://www.bluetooth.org/spec/, November, 5 2003.
[SMMM02] G. Votta S. M. Matz and M. Malkawi. Analysis of failure re-
covery rates in a wireless telecommunication system. 2002 In-
ternational Conference on Dependable Systems and Networks
(DSN 2002), Proceedings, 2002.
[SP] A. Bondavalli M. Barbera and I. Mura. S. Porcarelli, F.
Di Giandomenico. Service-level availability estimation of
gprs. IEEE Transactions on Mobile Computing, 2(3),
July-September 2003.
46
[SS03] A.Sekmen A.B.Koku S.Zein-Sabatto. Human robot interac-
tion via cellular phones. 2003.
[T.K01] M.Sugisaka T.Kubik. Use of a cellular phone in mobile robot
voice control. SICE 2001 Proceedings, pages 106–111, July
2001.
[Tri02] K. S. Trivedi. Sharpe 2002: Symbolic hierarchical automat-
ed reliability and performance evaluator. 2002 International
Conference on Dependable Systems and Networks (DSN 2002)
Bethesda MD, USA, Proceedings, page 544, June, 23-26 2002.
[V.A01] M.Floriun V.Astarita. The use of mobile phones in traffic
management and control. 2001 IEEE intelligent Transporta-
tion Systems Conference Proceedings - Oakland (CA), USA -
August 25-29,2001, pages 10–15, August 25-29 2001.