Dependability: concetti fondamentali

Transcript

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
1.1 Il concetto di dependability nel tempo . . . . . . . . . . . . .
1.1.1 Sistema, servizio, interfaccia . . . . . . . . . . . . . . .
1.1.2 Gli attributi di dependability . . . . . . . . . . . . . .
1.1.3 Dependability measures . . . . . . . . . . . . . . . . .
1.2 Dependability threats . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Faults . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Errors . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3 Failures . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4 Propagazione delle minacce: la catena fault, error,
failure . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Dependability means . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Fault avoidance . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Fault tolerance . . . . . . . . . . . . . . . . . . . . . .
1.3.2.1 Tecniche di fault tolerance . . . . . . . . . .
1.3.2.2 Stati di un sistema fault tolerant . . . . . . .
1.3.3 Fault removal . . . . . . . . . . . . . . . . . . . . . . .
1.3.4 Fault forecasting . . . . . . . . . . . . . . . . . . . . .
1.4 La failure data analysis . . . . . . . . . . . . . . . . . . . . .
1.4.1 Field failure data analysis . . . . . . . . . . . . . . . .
1.5 Un caso di studio: Windows NT . . . . . . . . . . . . . . . .
Bibliografia
1
1
2
2
8
9
9
12
13
17
19
19
19
22
23
24
25
26
28
31
40
i
Elenco delle figure
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
Andamento del failure rate di un componente . . .
Binary state model . . . . . . . . . . . . . . . . . .
Attributi di dependability . . . . . . . . . . . . . .
MTTF,MTBF,MTTR . . . . . . . . . . . . . . . .
Tassonomia dei faults (Laprie, 2004) . . . . . . . .
Tassonomia dei fallimenti (Laprie, 2004) . . . . . .
Patologia dei guasti . . . . . . . . . . . . . . . . .
Propagazione esterna dei guasti . . . . . . . . . . .
Strategie di tolleranza ai guasti (Laprie, 2004) . . .
Diagramma degli stati di un sistema fault tolerant
Strategie di verifica (Laprie, 2004) . . . . . . . . .
Fault Removal During Development . . . . . . . .
Fasi della field failure data anlysis (Iyer, 2000) . .
Esempio di log entr y . . . . . . . . . . . . . . . . .
Modello a stati finiti di un singolo host (Iyer, 2000)
Modello a stati finiti del dominio (Iyer, 2000) . . .
Distribuzione dei tempi di inter-reboot . . . . . . .
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
6
8
9
13
16
17
18
20
23
25
26
28
29
36
37
38
Elenco delle tabelle
1.1
1.2
1.3
1.4
1.5
1.6
Dependability Measures . . . . . . . . . . . . . . . . . . . . .
Parametri del test . . . . . . . . . . . . . . . . . . . . . . . .
Breakup dei reboot in base ai prominent events (Iyer, 2000) .
Statistiche sui tempi di up e down . . . . . . . . . . . . . . .
Statistiche sulle percentuali di Availability . . . . . . . . . . .
Interpretazione degli stati del modello del dominio (Iyer, 2000)
iii
8
31
33
35
35
37
Capitolo 1
Dependability e metodologie
di failure data analysis
L’evolversi delle tecnologie ed il fiorire di scenari applicativi sempre nuovi e complessi ha indotto negli anni numerose rivisitazioni del concetto di dependability
nella sua accezione più completa. Nel presente capitolo è riportata una breve ricostruzione storica delle diverse interpretazioni oltre che la descrizione dei concetti
fondamentali legati all’idea di dependability. Ad una prima parte meramente descrittiva in cui si illustrano gli attributi di dependability, le minacce all’affidabilità
di un sistema e le tecniche di dependability improvement, segue una seconda parte
incentrata sull’analisi dei dati (failure data analysis) per la valutazione dell’affidabilità di un sistema. Il capitolo si conclude con un caso di studio -presente in
letteratura- sull’analisi, quantitativa e qualitativa, della dependability di un sistema
networked.
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 justifiably 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 termini 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’ambiente (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
(1.2)
otherwise
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 interpretazione del concetto di disponibilità:
1. un sistema potrebbe non essere totalmente disponibile ma comunque 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 funzione della qualità del servizio offerta dal sistema nel tempo e non
4
come un valore medio: secondo la (1.1) un sistema indisponibile per due secondi al minuto ed uno indisponibile per un intero 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 (proper 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 fallimento (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
λ(t)
Infant mortality
Normal Lifetime
Wear Out Period
Approximatively constant
t
Figura 1.1: Andamento del failure rate di un componente
Una tra le relazioni esistenti tra la funzione di distribuzione dell’affidabilità 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 funzionamento che possano portare il sistema a danneggiare gli utenti e/o l’ambiente in cui opera; secondo Laprie safety è ’ the absence of catastrophic 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 dall’assunzione che durante il suo ciclo di vita un sistema possa permanere esclusivamente in due stati: il sistema può essere non disponibile (DOWN) oppure può essere disponibile e correttamente funzionante
(UP & PROPERLY RUNNING) (cfr. Figura 1.2).
Failure
Repair
Figura 1.2: Binary state model
Questa visione semplicistica dei fatti perde di validità qualora si abbia a che fare con sistemi tolleranti ai guasti (fault-tolerant systems):
sistemi del genere infatti, seppure in condizioni di performance degradate, 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 almeno 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 performability 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 sistema. Più in dettaglio un sistema sicuro è un sistema in cui coesistano
più attributi:
– availability , opportunamente reinterpretata come la disponibilità 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
DEPENDABILITY
Reliability
Performability
Safety
Maintainability
SECURITY
Availability
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
Mean Time To Crash
Mean Time Between Crashes
Mean Time to Failure
Mean Time Between Failures
Mean Number of Instruction to Restart
Mean Time to Repair
Mean Down Time
Mean Time Between Errors
Acronimo
MTTC
MTBC
MTTF
MTBF
MNIR
MTTR
MDT
MTBE
Descrizione
Tempo medio per avere un crash del sistema
Tempo medio tra due crash successivi del sistema
Tempo medio per il verificarsi di un failure
Tempo medio tra due failures successivi
Numero medio di istruzioni per il ripristino del sistema
Tempo medio necessario a riparare il sistema
Tempo medio per cui il sistema non è funzionante
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
MTBF
MTTF
MTTR
failed
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:
M T T F = R(t)
M T T R = 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 classificati in:
◦ Physical faults, ovvero guasti del sistema derivanti da problemi
all’hardware, dunque interni, oppure da cambiamenti nelle condizioni ambientali (interferenze, temperatura..), dunque esterni;
◦ Human faults, ovvero guasti derivanti da errori umani commessi 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 componente 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 corrispondenza di particolari condizioni ambientali (ad esempio per un
certo valore del carico). Scompaiono senza alcuna azione di riparazione 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 nella possibilità di applicare eventuali azioni di recupero: alla base di
guasti intermittenti vi sono solitamente anomalie hardware che possono 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 diversi siano stati i tentativi di formularne un modello, ad oggi non esiste 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 determinata 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 sospensione del servizio o anche di accedere ad informazioni riservate;
◦ Non malicious faults, ovvero guasti introdotti inconsapevolmente 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 condizioni esterne che si ripercuotono sul sistema (ad esempio interferenze 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 early 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 detectability ) 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 consistency ) si distinguono:
◦ Consistent Failures (fallimenti consistenti), per cui tutti gli
utenti del sistema hanno la stessa percezione del fallimento;
◦ Inconsistent Failures (fallimenti inconsistenti), ovvero fallimenti 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 fallimenti 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 generalmente 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 fallimenti induce alla definizione di severità del fallimento, failure severity, strettamente legata al costo necessario per il ripristino, dipendente
dal contesto e generalmente espressa in termini della massima probabilità di occorrenza del fallimento stesso che il sistema è in grado di
sopportare.
Una schematizzazione di quanto appena esposto è riportata in Figura 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 letteratura 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 improprio (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’interfaccia utente (EPR); un errore che non porta il sistema nello stato failure è un
errore latente (LE).
!"#"$%
& '()
Correct
Behavior
@$ !"#AB
&@ )
++$+ ,+$-."$%
* & ,/)
*
Error
0123456
74896: ;07<
CAA!AB %B
,+$!ADDAB
& C,)
*
Failure
6 6
=4 >5; ?<
?2212:
=
@$ !"#AB
&@ )
Figura 1.7: Patologia dei guasti
Un fallimento si ha dunque per propagazione di un errore e si verifica 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 propagation), si intende invece la generazione di errori a cascata all’interno di uno
stesso componente.
Nell’economia generale dello studio della dependability di sistemi distribuiti, i fenomeni di propagazione esterna assumono un peso rilevante
in quanto rendono spesso difficile l’individuazione del sistema remoto responsabile del fallimento. In Figura 1.8 è illustrato il meccanismo della propagazione con riferimento al caso particolare di sistemi in cascata.
STUVWX
ZW[\Y Y EFGHFIJIKLM
j EFGHFIJIKLN
npojm
]^_`ab_`cd
lki
PQQRQ
xy kijfi |y
PQQRQ q _ t PQQRQ
d
r
sdb
h
uscvbwb_`cd
g
ef
z{_rsdbtuscvbwb_`cd
System A
xy }c~vcdrd_b`tsr
SF
_r~b`tsr
Ef
System interface
L’attivazione di un fault dormiente nel sistema A risveglia un errore, prima
SF
EFGHFIJIKOM
Ef
z{_rsdb_`t
uscvbwb
cd
z{_rsdbtbt_
PQQRQ
PQQRQ
SF
…
System B
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 fallimento (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). Attraverso 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 esclusivamente 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 capillari 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 verifichino 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 fallimenti (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 sistema e alla loro segnalazione. Laprie et al. [AL04] individuano due possibili
strategie di detection:
◦ Concurrent Detection che ha luogo durante il normale funzionamento del sistema e dunque durante il delivering dei servizi;
◦ Preemptive Detection che ha luogo durante i periodi di sospensione 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 locazione 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 momento dell’errore a componenti integri;
◦ Reinitialization, ovvero il ripristino totale del normale comportamento del sistema mediante l’aggioramento delle informazioni modificate 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’utilizzo 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 operazioni -o di sequenze di operazioni- particolarmente utile nel caso di
guasti transienti.
La più elementare forma di ridondanza spaziale è certamente la replicazione 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 decisioni 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’attuazione 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’organizzazione 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 durante 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 comportamento 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 reali, 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 stabilire 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”, forniscono 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 comprendere 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 presuppone un’adeguata conoscenza del comportamento del sistema: la caratterizzazione statistica dei failure modes, accanto alla formulazione di modelli
realistici, incrementa la predicibilità del sistema stesso facilitando l’applicazione 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 costituito 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 sistema può essere condotto utilizzando software di simulazione: il sistema
viene volontariamente sottoposto a situazioni di errore (simulated faultinjection) con il duplice obiettivo di individuare eventuali dependability bottlenecks 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 attività 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 (detection 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 consente 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 esclusivamente agli errori rilevati durante il periodo di osservazione e la caratterizzazione 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 networked 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 dell’analisi assumano rilevanza statistica: in altre parole, vista la bassa
29
¦¢£§¨
¢©¤ª¥§
¡¢ £¡¤¥
¦§§§
£¨«¥
¬¥¡®¥
¡¯
¦§§§
¯¥°®§¡«£¡¢
Figura 1.14: Esempio di log entr y
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 processing, 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 particolare 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 universale 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̀ opportuni, è possibile in questa fase cominciare ad individuare il modello del
sistema e a valutarne i parametri pure se in via preliminare. I modelli generalmente più utilizzati in questa fase sono le catene di Markov,
modelli ciclostazionari che evidenziano la dipendenza dal carico e modelli statistici di correlazione error/failure. I valori tipicamente stimati
fanno riferimento alla frequenza di errori e fallimenti (T T E, T T F ) e
all’availability del sistema; strumenti di calcolo statistico (ad esempio SAS 1 ) risultano particolarmente utili a questo punto dell’analisi. 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 valutazione delle performance (ad esempio SHARP E [Tri02]). Per sistemi networked assume importanza centrale l’analisi della propagazione
1
http://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 Paragrafo 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
Numero di macchine
Periodo di raccolta
Fallimenti rilevati
Mail Servers , Windows NT 4.0
68
6 mesi
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 WindowsNT, è gestito da un apposito Event Logging Subsystem. Per la cattura di
eventi generati da applicazioni di utente sono disponibili apposite API (Application 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 WindowsNT (ad esempio il NETLOGON service...);
3. Security events, ovvero gli eventi generati da operazioni di login/logout 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 esclusivamente ai reboots delle workstations, l’operazione di estrazione dei dati
consiste nell’individuare le voci relative al reboot in senso stretto ma anche 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 descrizione 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 collassate 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
Total Reboots
Hardware or firmware problems
Connectivity problems
Crucial Application failures
Problem with a sw component
Normal shutdowns
Normal reboots
Unknown
Frequenza
1100
105
241
152
42
63
178
319
Percentuale
100
9
22
14
4
6
16
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 considerazioni 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 problemi di connettività: questo comportamento era prevedibile dal momento che il workload in esecuzione sulla rete è fortemente I/O intensive. E’importante però notare che problemi di questo tipo potrebbero
34
derivare dalla propagazione di errori propri di altre macchine del dominio: 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 comportamento 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:
U pT ime[i] =
TRi − TE[n−1]
∀i = 1...nReboots
DownT ime[i] =
TE[m−1] − TRi
∀i = 1...nReboots
U pT ime =
PnReboots
U pT ime[i]
DownT ime =
PnReboots
DownT ime[i]
i=1
i=1
In Tabella 1.4 sono riportati i valori dei tempi di up e down.
35
Item
Number of entries
Maximum
Minimum
Average
Standard deviation
Up time
Value
616
85.2 days
1 hour
11.82 days
15.656 days
Down time
Value
682
15.76 days
1 second
11.43 minutes
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=
U pT ime
U pT ime + DownT ime
Item
Number of machines
Maximum
Minimum
Average
Standard deviation
(1.12)
Value
66
99.9
89.39
99.35
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 alla comprensione delle interazioni tra i singoli hosts e all’individuazione di
eventuali bottlenecks all’interno della rete. Per reboot del dominio si intende 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
X
P (Ri )
(1.13)
i=1
Analogamente a quanto visto con riferimento ad un singolo host, anche 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 Tabella 1.6.
State Name
PDC
BDC
MDBC
PDC+BDC
PDC+MBDC
F
Meaning
Primary Domain Controller rebooted
One of Backup Domain Controller rebooted
Many Backup Domain Controller rebooted
PDC+ 1 BDC rebooted
PDC+ many BDC rebooted
Functional
Tabella 1.6: Interpretazione degli stati del modello del dominio (Iyer, 2000)
Osservando le probabilità di transizione riportate sul diagramma di Figura 1.16 è possibile trarre alcune importanti conclusioni:
◦ Una percentuale significativa di transizioni avvengono dallo stato F allo stato M DBC 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 P DC 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 evidenziare 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 macchina 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 verificatisi 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 singoli 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.
software.
The n-version approach to fault tolerant
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 computing. IEEE Transactions on Dependable and Secure Computing, 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 collection & 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 medical image transmission. 4th National Conference on Telecommunication 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 measurements 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
[D.C03]
S.Garg D.Chen.
, Giugno,7 2005.
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. International Conference on Dependable Systems and Networks
(DSN 2003), Proceedings, June 2003.
[DDDD04]
M. Elangovan D. D. Deavours and J. E. Dawkins.
perceived interoperability of bluetooth devices.
User-
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 International Conference on Wereable Computers, Proceedings, Ottobre
1998.
[E.F04]
M.Lampe M.Strassner E.Fleisch. A ubiquitous computing environment for aircraft maintenance. 2004 ACM Symposium
on Applied Computing Proceedings, pages 1586–1592, March
14-17 2004.
[Hel96]
A.Heddaya A. Helal.
ity andperformability:
as
Reliability, availability, dependabilA user-centered view.
Available
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 disabilities. Proceedings of the First Workshop on Human Computer
Interaction with Mobile Devices, May 1998.
[IG05]
K.Stordahl I.G. Gjerde, R.Venturin. Forecasting mobile market development. 8th International Conference on Telecommunications , 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 International Workshop on Trust, Privacy, Deception, and Fraud in
Agent Societies (AAMAS 2003), 2003.
[MC05]
D. Cotroneo C. Pirro S. Russo M. Cinque, F. Cornevilli.
Bluetooth field failure data
nical
report,
FIRB
Technical
analysis.
Report,
CINI
TechNapoli,
https://web-minds.consorzio-cini.it/servizi/intranet/
/buro/docs/BT_Field_Failure_Analysis.pdf,
[MEC96]
January 2005.
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. Proceedings of the 12th Tyrrhenian International Workshop on Digital 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. Kyllonen 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 resources. Adjunct Proceedings of the 2nd European Symposium 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 Conference 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) specification.
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/,
[SMMM02]
November, 5 2003.
G. Votta S. M. Matz and M. Malkawi. Analysis of failure recovery rates in a wireless telecommunication system. 2002 International Conference on Dependable Systems and Networks
(DSN 2002), Proceedings, 2002.
[SP]
A. Bondavalli M. Barbera and I. Mura. S. Porcarelli, F.
Di Giandomenico.
gprs.
Service-level availability estimation of
IEEE Transactions on Mobile Computing, 2(3),
July-September 2003.
46
[SS03]
A.Sekmen A.B.Koku S.Zein-Sabatto. Human robot interaction 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 automated 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 Transportation Systems Conference Proceedings - Oakland (CA), USA August 25-29,2001, pages 10–15, August 25-29 2001.