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.