Strategie di Analisi dei dati di malfunzionamenti per reti Bluetooth

Università degli studi di Napoli “Federico II”
Facoltà di Ingegneria
Corso di laurea specialistica in Ingegneria delle
Telecomunicazioni
Tesi di Laurea
Strategie di Analisi dei dati di
malfunzionamenti per reti Bluetooth
Relatori
Candidato
Ch. mi Prof.
Giulio Virnicchi
Stefano Russo
Matricola 887/17
Domenico Cotroneo
ANNO ACCADEMICO 2004 – 2005
Ai miei Cari
Ringraziamenti
E’ strano accorgersi di quanto un’esperienza che si è già vissuta
possa ancora rivelarsi tanto sorprendente. A pochi giorni dalla conclusione
di questo secondo capitolo della mia carriera universitaria, sono contento di
essere riuscito a ritagliare un piccolo spazio per dare ascolto ai miei
pensieri, riconsiderare la mia vita e quanto il sostegno delle persone care
sia stato sempre presente in ogni sua fase.
E’ a loro che dedico questo lavoro, nessuna parola potrà mai rendere la
riconoscenza e l’affetto che provo per voi.
In particolare un ringraziamento speciale va alla mia famiglia, i miei
genitori, mio fratello Giorgio ed i miei adorabili nonni per avere sempre
dimostrato la fiducia che provano per me e per avermi regalato una vita
sempre serena e felice. Alla mia dolce Laura, con la quale ho condiviso le
difficoltà ed i momenti più belli di questi anni. I loro sorrisi, il loro affetto,
il loro sostegno sono stati per me una continua fonte di energia.
Ringrazio il Professore Stefano Russo per avermi offerto la possibilità di
esser parte del suo gruppo, un ambiente piacevole e stimolante, in una sola
parola ideale. Domenico per avere sempre creduto in me ed aver reso
questo lavoro possibile. In lui ho scoperto un vero amico oltre che una
guida ed un modello di ispirazione.
I miei amici del dipartimento,
Ringraziamenti
5
____________________________________________________________
Marcello, Gabriella, Generoso e Salvatore, con loro accanto il lavoro non è
mai sembrato tale.
Ringrazio infine gli amici più cari, per essermi sempre stati vicini,
comprendendo le mie continue assenze ed il poco tempo che ho potuto
dedicare loro negli ultimi mesi.
Indice
Ringraziamenti________________________________________________4
Indice ______________________________________________________6
Introduzione _________________________________________________8
Dependability di un sistema distribuito di prossima generazione _____________ 12
1.2
1.2.2
1.2.3
1.2.4
1.2.5
1.2.6
1.2.7
1.3
1.3.2
1.3.3
1.3.4
1.3.5
Concetti di dependability ___________________________________________ 15
Availability __________________________________________________________
Reliability____________________________________________________________
Safety _______________________________________________________________
Performability ________________________________________________________
Maintainability _______________________________________________________
Misure di Dependability ________________________________________________
16
17
19
19
21
21
Minacce per la Dependability _______________________________________ 22
Guasti _______________________________________________________________
Errori _______________________________________________________________
Fallimenti____________________________________________________________
Relazioni tra guasti, errori, fallimenti_____________________________________
23
27
27
31
1.4
Migliorare la dependability di un sistema _____________________________ 34
1.5
Valutazione della dependability di un sistema _________________________ 36
Misure ed Analisi dirette ________________________________________ 40
2.2
Collezione dei dati_________________________________________________ 41
2.3
Filtraggio dei dati _________________________________________________ 43
2.4
Estrazione e Coalescenza dei dati ____________________________________ 44
2.5
Analisi preliminare di errori e fallimenti ______________________________ 49
2.6
Analisi del comportamento del sistema _______________________________ 49
Introduzione a Bluetooth________________________________________ 51
3.2
3.2.2
3.2.3
3.2.4
3.2.5
3.3
Bluetooth ________________________________________________________ 54
Livello Radio _________________________________________________________
Livello Baseband ______________________________________________________
Logical Link Control and Adaptation Layer Protocol _______________________
Bluetooth Networking Encapsulation Protocol BNEP________________________
56
57
59
62
Il profilo PAN ____________________________________________________ 62
Infrastruttura per la raccolta dati __________________________________ 65
4.2
4.2.2
4.2.3
4.2.4
La generazione e la raccolta dei dati__________________________________ 66
Architettura per la raccolta dati _________________________________________ 68
Struttura e persistenza dei dati __________________________________________ 70
Emulazione del traffico_________________________________________________ 72
7
Indice
____________________________________________________________
4.2.5
4.3
4.3.2
4.3.3
Il LogAnalyzer________________________________________________________ 76
Il testbed ________________________________________________________ 80
Linux e Bluetooth : lo stack BlueZ _______________________________________ 81
Windows XP e Bluetooth _______________________________________________ 84
Selezione ed Analisi dei dati ______________________________________ 86
5.2
5.2.2
5.2.3
5.2.4
5.2.5
5.3
5.3.2
5.3.3
5.3.4
5.3.5
5.3.6
5.3
Approccio metodologico per l’analisi di un nuovo set di dati______________ 88
Identificare l’insieme di dati ____________________________________________
Valutare la qualità dell’insieme di dati ____________________________________
Ottenere una comprensione basilare dei dati _______________________________
Analisi dei dati________________________________________________________
90
90
91
92
Applicazione delle metodologie di analisi ______________________________ 93
Identificazione e valutazione dell’insieme di dati____________________________ 94
Filtraggio, estrazione e coalescenza dei dati _______________________________ 101
Analisi preliminare dei comportamenti di sistema _________________________ 114
Correlazione tra le dinamiche di fallimento nei diversi Host _________________ 129
Legame tra errori di livello sistema e fallimenti, fenomeni di propagazione _____ 136
Conclusione e sviluppi futuri _______________________________________ 141
Bibliografia ________________________________________________ 143
Introduzione
Il mercato dei dispositivi mobili di ultima generazione sta assumendo
oggi dimensioni decisamente significative ed evolve rapidamente sotto la
spinta dei continui progressi nel campo della wireless communication e
dell’elettronica low-power.
La disponibilità di dispositivi sempre più
potenti in termini di capacità di elaborazione, memoria e connettività ha
radicalmente modificato le abitudini e le esigenze di una larga parte
dell’utenza, rendendo il mobile computing la realtà dominante nel mondo
della comunicazione sia professionale sia di intrattenimento.
La combinazione di mobile computing e la disponibilità di moderne
infrastrutture di accesso wireless a banda larga (UMTS, Wi-Fi, Bluetooth)
hanno portato al proliferare di nuove proposte per diversi scenari
applicativi in contesti quali la diagnosi e la manutenzione di impianti
[2][3], la teleimmersione [4], il mobile learning [5], la domotica [6],
sistemi di telemedicina ed healthcare [7][8].
I moderni sistemi distribuiti forniranno quindi una vasta gamma di servizi,
che potranno ricoprire anche primaria importanza nella vita di ogni giorno:
occorre quindi siano in grado di garantire la fornitura del servizio, seppure
in forma limitata, anche in presenza di guasti in componenti e sottosistemi.
Introduzione
9
____________________________________________________________
A dispetto della crescente fiducia dell’utenza verso tali sistemi, diversi
sono però i fattori tecnologici ed economici che stanno accentuando il
problema dei fallimenti nell’erogazione del servizio.
L’integrazione di componenti, siano essi di nuovo sviluppo, COTS
(Commercial Off The Shelf) o ereditati ha consentito la realizzazione di
sistemi di maggiore complessità in tempi sempre più ristretti, così come
dettati da esigenze di mercato. Tale complessità, affiancata spesso ad una
scarsa conoscenza di alcune loro parti, rende i sistemi odierni
maggiormente predisposti a problemi software ed hardware che possono
portare a degradazione delle prestazioni o persino delle funzionalità.
I nuovi scenari di mobile computing comportano la necessità ad affiancare
alle infrastrutture di rete classiche, nuove infrastrutture di rete ibride (wired
e wireless) e totalmente wireless (senza alcun core di rete fisso) per
supportare la mobilità dei dispositivi. Simili scenari introducono nuove
problematiche legate a limitazioni ambientali o tecnologiche proprie del
mobile environment quali la limitata autonomia energetica dei dispositivi,
le limitate risorse di banda e l’intermittenza dei canali wireless, la necessità
di operare su piattaforme eterogenee.
Questi fattori suggeriscono un aumento dell’occorrenza di fallimenti e la
necessità di un cambio di prospettiva: piuttosto che considerare e trattare i
fallimenti come situazioni eccezionali nel funzionamento di un sistema,
bisogna riconoscerne la presenza, comprenderne il comportamento e gestire
efficacemente le risorse per nasconderne l’impatto all’utenza finale.
10
Introduzione
____________________________________________________________
La strada migliore per comprendere le caratteristiche di affidabilità di un
sistema è attraverso misure ed analisi dirette. Realizzare misure comporta
monitorare e registrare eventi che si verificano all’interno del sistema
stesso, mentre lavora sotto l’effetto del normale carico d’utente.
Attraverso l’analisi dei dati acquisiti possono essere estratte informazioni di
valore relativamente al manifestarsi di errori e fallimenti e sul
comportamento del sistema in tali situazioni di crisi.
I metodi di analisi possono variare significativamente in funzione degli
obiettivi che la ricerca vuole perseguire. Non esistono linee guida ma
occorre sottolineare che il grado di successo in attività di questo tipo è in
larga parte dipendente dalla qualità e dalla consapevolezza con cui viene
condotta l’analisi stessa.
Il presente lavoro di tesi ricerca metodologie e strategie di analisi
applicabili durante le diverse fasi, dalla collezione dei dati alla loro
interpretazione.
Particolare attenzione viene dedicata allo sviluppo di
soluzioni per l’esplorazione dei legami esistenti all’interno dei dati. Tale
aspetto ricopre un ruolo essenziale nell’analisi, consentendo di ricostruire il
processo di fallimento partendo dalla sola osservazione delle sue molteplici
manifestazioni.
Metodologie e soluzioni trovate sono state applicate come caso di studio
all’analisi dei dati di malfunzionamenti per reti Bluetooth raccolti da una
infrastruttura distribuita ed automatica per il monitoraggio e la collezione
di fallimenti spontanei in piconet BT. Tale lavoro di analisi in particolare
11
Introduzione
____________________________________________________________
affronta l’esplorazione dei legami esistenti all’interno dei dati in relazione a
tre problematiche:
• Rimozione della ridondanza introdotta nei dati dal meccanismo di
registrazione degli eventi.
• Relazioni esistenti tra le dinamiche di fallimento dei diversi Hosts.
• Legame tra errori di livello sistema e fallimenti, analisi dei fenomeni
di propagazione.
Il lavoro di tesi è organizzato come segue:
Il capitolo primo è dedicato alla presentazione delle tematiche di
dependability ed alle possibilità di applicazione al contesto in esame.
Nel capitolo secondo si descrive il processo di analisi dei dati di fallimento
e le diverse fasi che lo compongono.
Nel capitolo terzo viene introdotta la tecnologia bluetooth oggetto del
lavoro di analisi eletto a caso di studio.
Nel capitolo quarto viene descritto il processo di collezione dei dati di
fallimento in una piconet Bluetooth..
Il capitolo quinto propone una metodologia di analisi e ne descrive
l’applicazione al caso di studio.
Vengono infine presentati i risultati
dell’analisi condotta sull’insieme di dati di fallimento.
Capitolo I
Dependability di un sistema distribuito di
prossima generazione
Il mercato dei dispositivi mobili di ultima generazione sta assumendo
oggi dimensioni decisamente significative ed evolve rapidamente sotto la
spinta dei continui progressi nel campo della wireless communication e
dell’elettronica low-power.
La disponibilità di dispositivi sempre più
potenti in termini di capacità di elaborazione, memoria e connettività ha
radicalmente modificato le abitudini e le esigenze di una larga parte
dell’utenza, rendendo il mobile computing la realtà dominante nel mondo
della comunicazione sia professionale sia di intrattenimento. In particolare,
si riconosce, giorno dopo giorno, la necessità di accedere a risorse e servizi
anche quando si è in movimento o in un contesto differente, ovvero, come
riportato in [1], una esigenza di anytime, anywhere access.
La combinazione di mobile computing e la disponibilità di moderne
infrastrutture di accesso wireless a banda larga (UMTS, Wi-Fi, Bluetooth)
hanno portato al proliferare di nuove proposte per diversi scenari
applicativi in contesti quali la diagnosi e la manutenzione di impianti
[2][3], la teleimmersione [4], il mobile learning [5], la domotica [6],
sistemi di telemedicina ed healthcare [7][8].
13
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
I moderni sistemi distribuiti forniranno quindi una vasta gamma di servizi,
che potranno ricoprire anche primaria importanza nella vita di ogni giorno :
occorre quindi siano in grado di garantire la fornitura del servizio, seppure
in forma limitata, anche in presenza di guasti in componenti e sottosistemi.
Per queste ragioni studi sulla dependability, fino a pochi anni fa specifici
per
sistemi
critici
ed
altamente
affidabili
quali
sistemi
di
telecomunicazioni, di controllo del traffico aereo, ferroviario o di centrali
per la produzione di energia, trovano nuove necessità di applicazione in
questo contesto.
A dispetto della crescente fiducia dell’utenza verso tali sistemi,
diversi sono però i fattori tecnologici ed economici che stanno accentuando
il problema dei fallimenti nell’erogazione del servizio.
Gli ultimi anni sono stati infatti testimoni della diffusione su larga scala di
sistemi distribuiti basati su hardware e software di tipo commerciale
(COTS - Commercial Off The Shelf).
Il continuo aumento delle
prestazioni, delle capacità di memorizzazione e della velocità di
comunicazione dei personal computer abbinato al costo contenuto hanno
decretato il successo di tale soluzione.
D’altro canto, però, la natura low cost di tali sistemi e la relativa instabilità
dei componenti hardware e software che li costituiscono comportano
maggiori difficoltà nel garantire stringenti requisiti di affidabilità,
specialmente per applicazioni che richiedono lunghi tempi di esecuzione.
In particolare componenti COTS possono essere rilasciati con problemi
noti e, tipicamente, parzialmente documentati o contenere problematiche
Capitolo I :
14
Dependability di un sistema distribuito di prossima generazione ______________
ancora non evidenziate quali presenza di bachi, vulnerabilità o errori. Tale
problema diventa particolarmente serio quando vi è esigenza di integrare in
un nuovo sistema anche parti ereditate, i cosiddetti componenti Legacy;
questi ultimi sono sovente privi del tutto di documentazione o affiancati da
documentazione incompleta e talvolta non allineata.
Parallelamente l’integrazione di componenti, siano essi di nuovo sviluppo,
COTS o ereditati, ha consentito la realizzazione di sistemi di maggiore
complessità in tempi sempre più ristretti, così come dettati da esigenze di
mercato. Tale complessità, affiancata spesso ad una scarsa conoscenza di
alcune loro parti, rende i sistemi odierni maggiormente predisposti a
problemi software ed hardware quali la presenza di bachi, di condizioni
non testate che possono costituire vulnerabilità o exploits, fenomeni di
invecchiamento che nel tempo possono portare a degradazione delle
prestazioni o persino delle funzionalità.
Nella interazione tra componenti, i sistemi distribuiti tradizionali possono
contare su infrastrutture di rete fisse che garantiscono, grazie alle
consolidate capacità elaborative dei nodi di rete ed alle elevate prestazioni
dei link fisici, un comportamento affidabile e, soprattutto, in larga parte
predicibile. D’altra parte, i nuovi scenari di mobile computing comportano
la necessità ad affiancare alle infrastrutture di rete classiche, nuove
infrastrutture di rete ibride (wired e wireless) e totalmente wireless (senza
alcun core di rete fisso) per supportare la mobilità dei dispositivi. Simili
scenari introducono nuove problematiche legate a limitazioni ambientali o
tecnologiche proprie del mobile environment quali la limitata autonomia
15
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
energetica dei dispositivi, le limitate risorse di banda e l’intermittenza dei
canali wireless, la necessità di operare su piattaforme eterogenee.
Questi fattori suggeriscono un aumento dell’occorrenza di fallimenti
e la necessità di un cambio di prospettiva : piuttosto che considerare e
trattare i fallimenti come situazioni eccezionali nel funzionamento di un
sistema, bisogna riconoscerne la presenza, comprenderne il comportamento
e gestire efficacemente le risorse per nasconderne l’impatto all’utenza
finale.
1.2
Concetti di dependability
L’affidabilità di un sistema o dependability è la sua capacità di
fornire un servizio conformemente alle specifiche di progetto.
Se il
servizio offerto da un sistema non risponde a quanto atteso si dice che il
sistema è in presenza di un service failure. Indicati anche semplicemente
come fallimenti (failures), i service failures rappresentano una condizione
anomala nel funzionamento del sistema che devia in qualche misura dal
comportamento corretto.
Lo spostamento dal servizio corretto può
assumere diverse forme, note in letteratura come service failure modes e la
gravità viene valutata in accordo ad una failure severities.
Non è semplice considerare una definizione formale di dependability,
quest’ultima difatti è più propriamente un insieme di attributi di qualità che
16
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
assumono, singolarmente, una rilevanza più o meno sensibile a seconda del
contesto applicativo. Tali attributi sono descritti nei paragrafi seguenti.
1.2.2
Availability
L’Availability rappresenta la disponibilità del sistema in un dato
istante; è sinteticamente definita come la probabilità che un sistema sia
pronto in un certo istante t, in formule:
A = P (! Failure at t )
(1.1)
Più esplicitamente, un sistema è available in un dato istante t se è in grado
di fornire un servizio corretto (proper service). Matematicamente quindi la
funzione A(t) è del tipo:
⎧1
A(t ) = ⎨
⎩0
if proper service at t
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 a tale interpretazione:
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);
17
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
2. la disponibilità di un sistema dovrebbe essere intesa quale funzione
della qualità del servizio offerta dal sistema nel tempo e non 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.
1.2.3
Reliability
La reliability R(t) è una misura della continuità di un servizio ovvero
dell’intervallo di tempo in cui viene fornito un servizio corretto:
R ( t ) = P (! Failure in ( 0, t ) )
(1.3)
Più in generale, la distribuzione di affidabilità di un sistema R ( t ,τ ) è la
probabilità condizionale che il sistema funzioni correttamente (proper
service) nell’intervallo [t , t + τ ] , ammesso che fosse correttamente operativo
al tempo t:
R ( t ,τ ) = P (! failure in [t ,τ ]
corretto funzionamento in t )
(1.4)
Detta F(t) la funzione di distribuzione cumulativa del tempo di fallimento,
unreliability, la funzione R(t) può essere riscritta come:
R (t ) = 1 − F (t )
(1.5)
18
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
Il numero di fallimenti di un sistema per unità di tempo è definito come
tasso di fallimento, è generalmente indicato con λ ( t ) e misurato in numero
di fallimenti per ora. L’andamento tipico del tasso dai fallimento per un
componente è riportato in Figura 1.1.
Figura 1.1 Andamento del failure rate di un componente
E’possibile dimostrare che la relazione esistente tra la funzione di
distribuzione dell’affidabilità ed il tempo è del tipo:
R ( t ) = e − λt
(1.6)
La 1.6 è nota come legge di fallimento esponenziale ed afferma che in un
sistema a tasso di fallimento costante l’affidabilità decresce in maniera
esponenziale nel tempo.
19
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
1.2.4
Safety
Per safety si intende generalmente l’assenza di condizioni di
funzionamento che possono portare il sistema a danneggiare gli utenti e/o
l’ambiente in cui opera; secondo Laprie safety è “the absence of
catastrophic consequences on the users(s) and the environment..” [9].
Matematicamente la funzione safety S(t) è la probabilità che non vi siano
guasti catastrofici in [0, t].
S ( t ) = P (!Catastrophic failure in [ 0, t ])
(1.7)
Sebbene una simile definizione sia universalmente accettata in quanto ben
evidenzia gli effetti che potrebbero risultare dall’utilizzo di un sistema
unsafe, nel tempo il concetto di safety ha assunto sempre più i tratti di un
concetto relativo in quanto legato alla soggettiva valutazione dei rischi e
dell’entità dei danni provocati dal sistema.
1.2.5
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 può essere non disponibile (DOWN)
oppure può essere disponibile e correttamente funzionante (UP &
PROPERLY RUNNING) (cfr. Figura 1.2).
20
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
Questa visione semplicistica dei fatti perde di validità qualora si
considerino sistemi tolleranti ai guasti (fault-tolerant systems): sistemi di
questo tipo, infatti, seppure in condizioni di prestazioni degradate, riescono
ad operare anche in presenza di fallimenti. Il diagramma degli stati per un
sistema fault-tolerant dovrà allora essere caratterizzato da un numero di
stati superiore a due, nello specifico almeno pari al numero dei failure che
il sistema è in grado di mascherare.
Figura 1.2 Binary state model
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.
21
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
1.2.6
Maintainability
La maintainability, M(t), è generalmente definita come la capacità di
un sistema di poter essere sottoposto a modifiche e riparazioni [9]: un
sistema manutenibile è, infatti, un sistema che deve poter esser facilmente
ripristinato in seguito al verificarsi di un guasto.
1.2.7
Misure di Dependability
Una stima quantitativa del grado di dependability di un sistema può
essere ottenuta procedendo al calcolo di parametri sintetici alcuni dei quali
sono 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 Parametri sintetici di dependability
MTTF ed MTTR, graficamente rappresentati in Figura 1.3, risultano utili,
ad esempio, per il calcolo dell’availability:
A(t ) =
MTTF
MTTF + MTTR
(1.8)
22
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
Figura 1.3 MTTF, MTBF, MTTR
Con riferimento agli attributi discussi nei paragrafi precedenti è possibile
anche fornire un’ulteriore interpretazione del tempo di fallimento e del
tempo di ripristino in termini rispettivamente di reliability e maintainability
media:
MTTF = R ( t )
(1.9)
MTTR = M ( t )
1.3
Minacce per la Dependability
Molteplici sono le cause che possono portare un sistema in uno stato
incoerente, e dunque al fallimento; 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.
23
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
1.3.2
Guasti
Un guasto, fault, è 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 faults basandosi sulla loro causa (1), persistenza (2),
intenzionalità (3) ed origine (4).
1. A seconda della causa che li ha generati i guasti 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
del sistema (interaction faults).
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 è [t0 , tr ] .
24
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
•
Transient (soft) faults, ovvero guasti legati a momentanee
condizioni ambientali e che scompaiono definitivamente senza la
necessità di alcuna operazione di ripristino. Detto t0 l’istante di
occorrenza del guasto, l’intervallo di permanenza del componente
corrotto in stato failed è [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
stato failed è [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
possibilità 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 [10] riporta i risultati di studi
basati sulla data collection e sui conseguenti goodness-of-fit test al fine
di valutare la conformità dell’andamento dei guasti ad una determinata
25
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
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 intenzionalità i faults possono essere classificati in:
• Malicious faults, ovvero guasti introdotti deliberatamente nel
sistema con la volontà di alterarne lo stato provocando una
sospensione del servizio o anche di accedere ad informazioni
riservate.
• Non malicious faults, guasti introdotti inconsapevolmente
all’interno del sistema.
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 [9] propongono una classificazione dei faults che racchiude
tutte le precedenti e basata sull’individuazione di tre macroclassi
parzialmente sovrapposte (cfr. Figura 1.4)
26
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
• 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.
Figura 1.4 Tassonomia dei faults (Laprie, 2004)
27
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
1.3.3
Errori
Un errore è la parte dello stato di un sistema che può indurre lo
stesso al fallimento ovvero a fornire un servizio non conforme alle
specifiche (unproper service). Errori sono manifestazioni di guasti.
Se l’errore `e opportunamente rilevato esso si dice detected, viceversa se
l’errore esiste ma non è rilevato si parla di latent error.
Laprie et al. [9] 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 non catastrofici, errori consistenti ed
inconsistenti. E’ possibile infine che un fault all’interno di uno specifico
componente generi errori in più di un componente del sistema: in tal caso si
parla di multiple related errors.
1.3.4
Fallimenti
Un fallimento, failure, è 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 modalità in cui esso può
fallire sono definite failure modes ed implicano la non correttezza del
servizio secondo diversi punti di vista [9]: dominio (1), rilevabilità (2),
percezione (3) e severità del fallimento (4).
28
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
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
fornito (deadline), si ha:
s = s ( v, t )
: v ∈V e t ∈ T
(1.10)
Dal punto di vista del dominio del fallimento è possibile distinguere:
• Timing Failures, fallimenti per cui un servizio non è conforme
alle specifiche in termini di tempo, ovvero se
s = s ( v, t )
: v ∈V e t ∉ T
(1.11)
Fallimenti di questo tipo possono essere poi specializzati in
early timing failures se il servizio è fornito in anticipo, late
timing failures se in ritardo.
• Content Failures, 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.12)
Qualora un sistema fallisca sia nel tempo sia nel valore esso può fornire
non correttamente il servizio in diverse modalità, tra cui:
29
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
• halted, il sistema risulta bloccato e dunque il servizio non
perviene all’interfaccia; lo stato esterno del sistema è costante,
pari ad esempio all’ultimo valore coerente. Un particolare
fallimento di questo tipo è il fallimento per omissione del
servizio, omission failure, per cui il servizio è 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 rilevabilità del fallimento (failure detectability)
si distinguono:
• Signaled Failures, fallimenti segnalati a livello utente da un
opportuno messaggio di errore;
• Unsignaled Failures, fallimenti non segnalati a livello utente.
3. Dal punto di vista della percezione del fallimento (failure consistency)
si distinguono:
• Consistent Failures, tutti gli utenti del sistema hanno la stessa
percezione del fallimento;
Capitolo I :
30
Dependability di un sistema distribuito di prossima generazione ______________
• Unconsistent Failures, 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 gravità del fallimento (failure consequences) si
distinguono:
• Catastrophic Failures, fallimenti le cui conseguenze sono
incommensurabilmente più grandi del beneficio prodotto dal
servizio fornito in assenza di fallimento;
• Minor Failures, fallimenti le cui conseguenze sono dello stesso
ordine di grandezza (valutato generalmente in termini di costo)
del beneficio prodotto dal servizio fornito correttamente.
Una stima quantitativa delle conseguenze dei fallimenti induce alla
definizione di una failure severity, strettamente legata al costo
necessario per il ripristino, dipendente dal contesto e generalmente
espressa in termini della massima probabilità di occorrenza del
fallimento stesso che il sistema è in grado di sopportare.
Una schematizzazione di quanto esposto è riportata in Figura 1.5.
31
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
Figura 1.5 Tassonomia dei fallimenti
1.3.5
Relazioni tra guasti, errori, fallimenti
Guasti, errori e fallimenti sono legati da una precisa relazione, il
meccanismo di generazione e manifestazione è noto in letteratura come
patologia del guasto (cfr Figura 1.6).
Un guasto può 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 può 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 può degenerare in un fallimento mediante propagazione
32
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
all’interfaccia utente (EPR); un errore che non porta il sistema nello stato di
fallimento è un errore latente (LE).
Figura 1.6 Patologia del guasto
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 guasto esterno (external fault), ci si riferisce a tale situazione come
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.
33
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
Figura 1.7 Propagazione dei guasti
In Figura 1.7 è illustrato il meccanismo di propagazione con riferimento al
caso particolare di sistemi in cascata: l’attivazione di un fault dormiente nel
componente A risveglia un errore, prima latente; il processo elaborativo
produce una propagazione dell’errore all’interno del componente (internal
propagation).
A causa della propagazione interna l’errore raggiunge
necessariamente le interfacce esposte dal componente comportando così un
fallimento nei servizi offerti. Una tale situazione si configura come un
guasto esterno per il componente B che utilizza tali servizi e che risulterà a
sua volta affetto da errore (external propagation).
In assenza di strategie in grado di trattare l’errore, questo raggiunge infine
le interfacce esposte del sistema provocando un system failure.
Idealmente sarebbe auspicabile riuscire a preservare le funzionalità e le
prestazioni del sistema anche in presenza di fallimenti nelle sue parti.
Benché tale obiettivo sia praticamente non raggiungibile è bene comunque
34
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
evitare una interruzione completa del servizio, preservandone le
funzionalità essenziali, anche con prestazioni ridotte (service degradation).
1.4
Migliorare la dependability di un sistema
Esistono strategie finalizzate ad incrementare la dependability di un
sistema e che possono essere adottate per raggiungere tale obiettivo. In
letteratura vengono tipicamente suddivise in due filoni principali :
Fault Prevention - tale strategia si affida alla elevata qualità dei singoli
componenti utilizzati nella realizzazione del sistema, cercando così in fase
di progetto di ridurre al minimo l’eventuale insorgenza dei guasti.
Fault Tolerance - a differenza della precedente, tale strategia si fonda sul
presupposto dell’inevitabilità del presentarsi di fallimenti.
Solitamente
sistemi basati su tale approccio prevedono la presenza di uno più
componenti capaci di rivelare i fallimenti e di diagnosticare i guasti.
Nell’ambito del fault tolerance è possibile realizzare progetti che già in
fase di rilascio riconoscano l’occorrenza di failures e prevedano quindi la
ridondanza necessaria a mascherare il problema in presenza di un guasto.
Sebbene non costituisca la soluzione ideale dal punto di vista
dell’utilizzazione efficace delle risorse, che per esempio potrebbero essere
allocate per migliorare le prestazioni, il costo attuale dell’hardware e del
software commerciale è tale da giustificarne l’adozione in alcuni ambienti.
Capitolo I :
35
Dependability di un sistema distribuito di prossima generazione ______________
Una diversa possibilità consiste nello sviluppare sistemi in grado di
prevedere ed anticipare il verificarsi di fallimenti realizzando quindi, in
tempo utile, misure correttive di tipo proattivo. Per citare alcuni esempi :
effettuare rejuvenation programmati dei componenti per prevenire
catastrofiche conseguenze legate a fenomeni di invecchiamento del
software, oppure effettuare load balancing, individuando server e percorsi
alternativi per ridurre il carico di componenti prossimi alla saturazione
delle risorse.
Invece di anticipare i fallimenti predisponendo misure proattive, una
ulteriore opzione consiste nel gestire i fallimenti nel momento in cui si
manifestano, sostituendo o riconfigurando le parti coinvolte. Operazioni di
questo tipo possono essere realizzate in automatico, sebbene sia sovente
richiesto l’intervento di un operatore.
Ciascuna delle tecniche citate possiede aspetti positivi e negativi e
può essere necessario valutare attentamente i loro trade-off per scegliere la
soluzione più adatta al sistema da realizzare. In questa sede è importante
non tanto favorire una soluzione rispetto ad un’altra, quanto piuttosto
osservare che, attraverso le diverse tecniche, esiste l’esigenza comune di
comprendere in maniera dettagliata le dinamiche di errori e fallimenti, così
come le proprietà sottostanti. Per esempio la scelta di adottare o meno
ridondanza al momento del rilascio può dipendere in larga parte dalla
frequenza di occorrenza dei fallimenti : una elevata frequenza favorisce tale
soluzione; l’efficacia di tecniche proattive dipende in maniera significativa
dalla capacità di predire in tempo utile l’evenienza di un problema; anche
se si è scelto di intervenire unicamente in caso di manifestazione di un
36
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
fallimento, la conoscenza delle caratteristiche e delle dinamiche dei
fallimenti possono costituire un valido ausilio per ridurre i tempi necessari
ad identificare la radice del problema, ad isolare il guasto, per scegliere una
soluzione adeguata e intraprendere misure correttive. Maggiore è il tempo
impiegato, più vasto sarà l’impatto sulla disponibilità o, in generale, sulla
qualità del servizio.
1.5
Valutazione della dependability di un sistema
L’efficacia delle tecniche di dependability enhancement descritte
presuppone un’adeguata conoscenza del comportamento del sistema: la
caratterizzazione statistica dei failure modes, accanto alla formulazione di
modelli realistici, incrementa la predicibilità 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 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 [11] 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.
Durante la fase di design una prima valutazione del progetto può essere
condotta grazie all’uso di ambienti di computer aided design (CAD); tali
ambienti consentono di realizzare simulazioni di funzionamento del
37
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
sistema che possono includere anche l’introduzione di situazioni di errore
(simulated fault injection). Tali esami mirano a verificare l’efficacia dei
meccanismi di fault tolerance impiegati ed a valutare la dependability del
sistema;
in questo modo il progettista può disporre di un feedback
immediato per valutare eventuali revisioni del progetto.
Le simulazioni richiedono però l’accurata determinazione dei parametri,
nonché la necessità di poter validare i risultati.
Benché la stima dei
parametri possa essere estratta sulla base di misure ed esperienze maturate
su sistemi passati, tale operazione è però resa complessa, se non
inapplicabile, a causa di innovazioni e cambiamenti nelle tecnologie come
nei progetti.
A progettazione ultimata, viene generalmente rilasciata una versione
prototipale del sistema affinché esso possa essere sottoposto alle dovute
attività di testing. In questa fase il sistema viene sollecitato con profili di
carico controllato (controlled workloads) per poterne studiare le reazioni a
faults reali (physical fault injection), le sue capacità 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 (cioè 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 faults
artificiali: in uno scenario di integrazione di componenti commerciali, dei
quali si dispone tipicamente solo una conoscenza superficiale, è plausibile
che tali analisi lascino scoperte numerose tipologie di fallimento perché
38
Capitolo I :
Dependability di un sistema distribuito di prossima generazione ______________
non ancora note e del tutto imprevedibili. E’importante infine sottolineare
che, a differenza di quanto accade in fase di progettazione, in fase
prototipale è possibile iniettare guasti anche a livello software. Dettagli
relativi alle metodologie di fault injection sono reperibili in [12].
In fase di normale utilizzo del sistema, e dunque quando esso è ormai
completamente operativo, è possibile valutarne la dependability mediante
un’analisi sul campo ovvero analizzandone il comportamento sotto
condizione di carico reale.
I dati possono essere raccolti in maniera
automatica dal sistema stesso e contengono una grande quantità di
informazione su errori e fallimenti che si sono verificati durante l’esercizio.
Una analisi accurata può aiutare a comprendere le caratteristiche di errori e
fallimenti, valutare sul campo la copertura dei meccanismi di detection e
recovery, l’efficacia degli schemi di riconfigurazione, eventuali margini di
miglioramento, quantificare la perdita di prestazioni ed identificare colli di
bottiglia presenti nel sistema.
Come affermato in [11] : “there is no better way to understand
dependability characteristics of a computer systems than by direct
measurements and analysis” (non esiste modo migliore per comprendere le
caratteristiche di dependability di un sistema, che attraverso misure ed
analisi dirette). Tuttavia è importante tenere presente che tale approccio
consente di ottenere informazioni relative esclusivamente agli errori rilevati
durante
il
periodo
di
osservazione
e
raramente
di
immediata
interpretazione: occorre quindi concentrare l’attenzione su problematiche
Capitolo I :
39
Dependability di un sistema distribuito di prossima generazione ______________
relative alla effettiva possibilità di monitorare errori e fallimenti nonché
sulle modalità di analisi.
Capitolo II
Misure ed Analisi dirette
Come discusso nel capitolo precedente, la strada migliore per
comprendere le caratteristiche di dependability di un sistema è attraverso
misure ed analisi dirette.
Realizzare misure comporta monitorare e
registrare eventi che si verificano all’interno del sistema stesso, mentre
lavora sotto l’effetto del normale carico d’utente.
Dai dati acquisiti possono essere estratte informazioni di valore
relativamente al manifestarsi di errori e fallimenti e sul comportamento del
sistema in tali situazioni di crisi. In tal senso si possono :
• estrarre misure di dependability relative al sistema reale, in
particolare su aspetti quali availability e reliability : tempo medio
tra fallimenti successivi (MTBF mean time between failure), tempo
medio necessario per la ripristino del normale funzionamento (MTTR
mean time to repair), durata dei fuori servizio (service outgage);
• condurre analisi “off-line” per cercare di individuarne cause e
dinamiche, per valutare la copertura offerta dai meccanismi di
detection e recovery, per valutare l’efficacia degli schemi di
riconfigurazione e l’esistenza di margini di miglioramento, per
41
Capitolo II :
Misure ed Analisi dirette _________________________________________
quantificare la perdita di prestazioni, per identificare eventuali colli
di bottiglia presenti nel sistema;
• eseguire diagnostica “on-line” per predire e gestire fallimenti prima
che compromettano il servizio offerto dal sistema;
• realizzare trend analysis di lungo termine per identificare
cambiamenti nel carico o nel comportamento del sistema al fine di
considerare, in tempo utile, la necessità di innovazione o di
potenziamento del sistema.
Uno studio basato su misure passa attraverso diverse fasi : collezione dei
dati (2.1), filtraggio dei dati (2.2), estrazione e coalescenza (2.3), analisi
preliminare di errori e fallimenti (2.4), analisi del comportamento del
sistema (2.5).
2.2
Collezione dei dati
Da un punto di vista statistico perché un’analisi sia valida occorre
utilizzare una considerevole quantità di dati. Nei moderni sistemi i failures
sono eventi relativamente infrequenti, di conseguenza il processo di
raccolta deve essere sistematico ed esteso a periodi di osservazione lunghi.
Inoltre, perché i risultati dell’analisi possano essere significativi, il sistema
deve essere esposto ad un ampio ventaglio di possibili casi d’uso. Infine
occorre sempre tenere presente che i risultati, che potranno essere estratti
Capitolo II :
42
Misure ed Analisi dirette _________________________________________
dai dati, sono relativi ad i soli eventi identificati e raccolti; particolare cura,
quindi, deve essere posta nella scelta delle informazioni da monitorare e di
strumenti adeguati per l’acquisizione di tali informazioni.
Nella maggior parte dei sistemi commerciali, informazioni relative ad
errori e fallimenti possono essere ottenute attraverso meccanismi di logging
automatico forniti dai sistemi operativi sottostanti, oppure attraverso logs
gestiti dagli amministratori del sistema, che possono inserire manualmente
informazioni relative a fallimenti o eventi anomali sperimentati durante
l’uso o il testing del sistema.
Logs manuali sono soggettivi e solitamente non disponibili. Tipicamente
non presentano costanza nella raccolta dei dati così come nel livello di
dettaglio, inoltre difficilmente si prestano ad una analisi automatica.
D’altra parte la stragrande maggioranza dei sistemi operativi offrono
strumenti automatici per la gestione di logs di eventi. I reports generati
presentano un formato predefinito, generalmente includono informazioni
contestuali in caso di fallimento (ad esempio il sottosistema in cui si è
verificato, una traccia degli eventi significativi che lo hanno preceduto,
informazioni su eventuali operazioni di recupero intraprese quali waiting,
retrying,…), sono acquisiti in maniera sistematica e memorizzati in maniera
persistente.
Strumenti di logging automatici rappresentano senza dubbio la soluzione
più adottata, in primo luogo perché è l’unica a poter offrire una
43
Capitolo II :
Misure ed Analisi dirette _________________________________________
acquisizione regolare e prolungata di grandi volumi di dati, difficilmente
pensabile con tecniche manuali; risultano, inoltre, particolarmente adatti
per una analisi automatica e possiedono la capacità di registrare una
enorme quantità di informazione relativa ad errori transienti e dettagli sulle
operazioni di recupero automatiche eseguite.
Presentano, però, anche
alcuni svantaggi, legati principalmente al fatto che solitamente non
forniscono informazioni relative a cause o propagazione degli errori,
informazioni che dovranno quindi essere ricostruite ed interpretate sulla
base dell’esperienza di chi esegue l’analisi.
Questo problema è
maggiormente sentito in ambienti distribuiti dove errori e fallimenti,
attraverso meccanismi di condivisione delle risorse o di cooperazione,
possono propagarsi da una macchina all’altra coinvolgendo più nodi di
elaborazione : dipendenze lasche o, spesso, non immediate rendono
particolarmente complessa l’identificazione di dipendenze tra errori o
fallimenti in un ambiente distribuito.
Infine, in alcuni scenari, il sistema potrebbe diventare instabile a seguito di
un fallimento, tanto da non consentirne la registrazione.
2.3
Filtraggio dei dati
Solitamente i logs di sistema contengono una grande quantità di
informazione irrilevante o ridondante: per esempio accanto ad informazioni
essenziali come relative a problemi nel sottosistema di I/O o della memoria
possono essere presenti informazioni banali quali notifiche dell’avvenuto
mount o unmount di una periferica. Per evitare che i dati risultino confusi o
44
Capitolo II :
Misure ed Analisi dirette _________________________________________
polarizzati dalla presenza di informazioni inessenziali, una prima
rielaborazione consiste nel classificare gli eventi in base al sottosistema, al
componente o al processo in cui sono originati, per isolare i soli
significativi ai fini del servizio offerto dal sistema. Un’altra possibilità di
classificazione consiste nello sfruttare l’informazione relativa alla severity
dell’evento, tipicamente valutata dal sistema operativo stesso.
Naturalmente non esiste una classificazione uniforme o migliore, questo
perché differenti sistemi possono avere differenti architetture hardware o
software, inoltre le categorie dovrebbero essere scelte in accordo a criteri
dipendenti dal particolare contesto applicativo.
Una volta classificati gli eventi in categorie il filtraggio avviene attraverso
meccanismi di whitelisting o blacklisting; nel primo caso vengono
conservate le sole entries relative ad eventi di interesse, dualmente, nel
secondo caso, vengono eliminate le entries appartenenti a categorie di non
interesse, tale strategia risulta utile nel caso in cui non si abbia ancora
acquisito maturità sul problema sufficiente da determinare quali eventi
possano essere effettivamente correlati al dominio applicativo.
2.4
Estrazione e Coalescenza dei dati
L’elaborazione che segue il processo di filtraggio consiste di due fasi
non necessariamente separate : l’estrazione e la coalescenza dei dati.
45
Capitolo II :
Misure ed Analisi dirette _________________________________________
L’estrazione consiste nel recuperare ciascuna entry dai logs del sistema e
riorganizzarla in una struttura dati standard che, ad esempio, conserva i soli
campi di interesse.
La coalescenza è sostanzialmente una forma di riorganizzazione di entries
tra loro correlate in meta strutture.
Si tratta di una euristica basata sull’osservazione che nei log di sistema
vengono spesso riportati eventi multipli, che sono manifestazione di un
singolo guasto. Per evitare che tale ridondanza possa essere confusa con
informazione e che l’analisi successiva venga quindi polarizzata o distorta
da osservazioni ripetute di un medesimo problema, occorre che tali reports
vengano compattati in un singolo record.
Figura 2.1 Meccanismo di Event logging
In Figura 2.1 è illustrato il processo che porta alla notifica di eventi
multipli.
Sulla sinistra vi è un insieme di processi aleatori di guasti.
L’attivazione di un guasto genera uno o più errori che si propagano
attraverso il sistema.
Meccanismi hardware e software riveleranno la
presenza di errori mentre gli effetti del guasto si propagano attraverso le
46
Capitolo II :
Misure ed Analisi dirette _________________________________________
parti che costituiscono il sistema.
Alcuni di questi riporteranno l’evento
sul log di sistema. Diverse sono le situazioni che possono impedire la
corretta registrazione dell’evento : alcuni errori possono non essere stati
identificati, possono essere stati identificati da più di un sensore, pur
essendo stati identificati la loro registrazione può non avere luogo a causa
della perdita di stabilità del sistema. Segue che gli errori riportati nel log
degli eventi sono funzione dello stato del sistema oltre che del guasto
che li ha generati.
In conclusione il comportamento è in generale non prevedibile : gruppi di
errori possono essere identificati come singoli, passare inosservati, singoli
errori possono essere registrati più volte, l’ordine di registrazione può
risultare differente rispetto a quello di occorrenza.
Un approccio comune per cercare di ricostruire il fault process dagli
eventi osservati è il tupling [11-12]. Una tupla è una collezione di eventi
raggruppati secondo un definito meccanismo di clustering. L’osservazione
degli event logs indica che gli eventi tendono a verificarsi durante un breve
periodo di elevata attività. Questo suggerisce la possibilità di adottare
meccanismi di clustering basati sul tempo. Una strategia consolidata [12]
consiste nel considerare tutti gli eventi, che non presentino una distanza
temporale reciproca superiore ad una soglia fissata, come manifestazione di
uno stesso guasto.
47
Capitolo II :
Misure ed Analisi dirette _________________________________________
Per essere più precisi indicato con X i l’i-esimo evento nel log e con t ( X i )
l’istante in cui questo è riportato, l’algoritmo di clustering rispetta la regola
seguente :
if (t ( X i ) − t ( X i −1 ) < W )
then aggiungi X i alla tupla
else crea una nuova tupla
dove W è la dimensione della soglia fissata e va sotto il nome di clustering
time.
La scelta di una soglia adatta al sistema è un aspetto fondamentale del
tupling. Trattandosi di una euristica, esistono infatti situazioni in cui gli
eventi vengono raggruppati in modo errato.
Due sono le principali
tipologie di errore nel processo di clustering : collisioni e troncamenti.
Una collisione si verifica quando due o più guasti si succedono in tempi
tanto brevi (inferiori al clustering time) da far si che le loro manifestazioni
vengano raggruppate in una singola tupla.
Un troncamento, viceversa, si verifica quando l’intervallo temporale tra
eventi generati da un singolo guasto è superiore al clustering time : in
questo caso gli eventi vengono artificialmente divisi su più tuple.
La probabilità che si verifichi una collisione può essere ben rappresentata
da un’esponenziale di parametro pari al tuple rate [11], sotto l’ipotesi che
siano presenti infiniti processi di guasto. Segue che un clustering time
minore riduce la probabilità di collisione mentre parallelamente aumenta la
probabilità di troncamenti. Come discusso in [12] si dovrà accettare un
48
Capitolo II :
Misure ed Analisi dirette _________________________________________
trade-off tra la corruzione delle tuple legata a collisioni e quella legata a
troncamenti.
Una scelta attenta può essere guidata da uno studio di sensibilità rispetto al
clustering time : si osserva tipicamente l’andamento del numero di tuple o
della loro dimensione rispetto al clustering time. E’ atteso che il numero di
tuple sia una funzione monotona decrescente del clustering time: per un
clustering time pari a zero, il numero delle tuple coincide con la
dimensione del log; per un clustering time infinito sarà invece presente
un’unica tupla, ossia l’intero log.
Figura 2.2 Andamento del numero di Tuple in funzione del Clustering Time
Osservando il grafico in figura, è interessante notare come la curva presenti
una caratteristica forma ad “L”. La tupla, verosimilmente, rappresenta il
risultato diretto di un guasto nel sistema; tale guasto genera, in condizioni
normali, un pattern di errori che sono raggruppati in un lasso di tempo
breve rispetto all’intero log. E’ quindi intuitivo attendere piccoli tempi di
interarrivo tra eventi correlati, grandi interarrivi tra tuple relative a fault
differenti. Per tale ragione è presente una elevata sensibilità al clustering
49
Capitolo II :
Misure ed Analisi dirette _________________________________________
time per valori prossimi al tempo tipico di interarrivo tra eventi correlati, ed
una modesta sensibilità per valori maggiori.
Questo spiega la forma
caratteristica e suggerisce un metodo per la scelta del clustering time: il
vertice della “L” rappresenta il clustering time proprio del sistema, W deve
essere scelto maggiore di questo valore.
2.5
Analisi preliminare di errori e fallimenti
In questa fase si conduce una analisi statistica preliminare dei dati.
Misure comunemente usate nell’analisi includono frequenze di errori e
fallimenti, mean time between error (MTBE) e mean time between failure
(MTBF), availability di sistema, durata media dei fuori servizio o
equivalentemente mean time to repair (MTTR). Queste misure forniscono
una immagine di insieme del sistema e possono essere utilizzate per
verificare se le caratteristiche di dependability richieste siano state o meno
raggiunte.
2.6
Analisi del comportamento del sistema
In questa fase si cerca di approfondire la conoscenza delle dinamiche
di errore e fallimento. Gli obiettivi possono essere diversi : comprendere il
legame tra errori e fallimenti nel servizio, identificare eventuali problemi di
progetto, difetti di implementazione, colli di bottiglia per la dependability,
estrarre trends per realizzare misure di recupero proattive, collezionare
50
Capitolo II :
Misure ed Analisi dirette _________________________________________
prove statistiche che consentano una rapida identificazione dei componenti
guasti.
Non esistono linee guida, i metodi di analisi possono variare
significativamente tra studi differenti, in dipendenza degli obiettivi che la
ricerca vuole perseguire. Diversi modelli sono stati proposti e validati
usando dati reali provenienti da sistemi tra loro anche molto differenti.
Per ulteriori approfondimenti si suggerisce di fare riferimento alla seguente
tabella:
Categoria
Coalescenza dei dati
Caratterizzazione degli errori
Analisi delle dipendenze
Modeling and Evaluation
Tecniche di Diagnosi
Riferimenti
[11] [13] [14] [15]
Problematica Affrontata
Introduzione alla coalescenza
[12]
Analisi comparativa di tecniche per la coalescenza
[16]
Guasti ed errori transienti
[16] [17]
Raffiche di errori e fallimenti
[18] [19]
Distribuzioni TTE/TTF
[20]
Dipendenze tra Hardware failure e workload
[20] [21]
Dipendenze tra Software failure e workload
[13] [22]
Fenomeni di propagazione di fallimenti
[23] [24] [25] [26]
[27] [28] [29]
[30] [31]
Euristiche per la Trend Analysis
Capitolo III
Presentazione di un caso studio :
Introduzione a Bluetooth
L’obiettivo di una rete wireless WLAN (Wireless Local Area
Network) è di fornire benefici e caratteristiche di una rete LAN tradizionale
senza la necessità di cavi.
Le WLAN superano i limiti del cablaggio assicurando la connettività, con
l’adozione di tecnologie ad infrarossi (IR) o a radiofrequenza (RF). Poiché
l’infrarosso richiede la presenza di una “line of sigth”, il ricevitore deve
essere cioè visibile al trasmettitore per aprire il canale di comunicazione, la
tecnologia a radiofrequenza ha ottenuto maggiori consensi e crescente
popolarità.
Diversi sono i vantaggi nel sostituire i cavi con il mezzo radio. I più
significativi riguardano mobilità, ovvero capacità di assicurare connettività
anche ad utenza in movimento; flessibilità, con la possibilità di realizzare
reti scalabili nelle quali l’aggiunta di un nuovo utente non comporta spese
ne difficoltà aggiuntive; economie di scala, con il risparmio dei costi di
cablaggio, la possibilità di installazione in ambienti non adatti quali edifici
storici ed in tempi ridotti.
52
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
I problemi principalmente sono legati all’inaffidabilità del mezzo wireless,
risultato di riflessioni elettromagnetiche, di fading da cammini multipli e,
soprattutto, della presenza di altri sistemi che lavorano nelle stesse bande.
Molti governi hanno mantenuto libere alcune bande di frequenze, note
come bande ISM (Industriale, Scientifica, Medica). Queste possono essere
usate liberamente, senza necessità di richiedere licenze, a patto di rispettare
precisi limiti di potenza e di utilizzare tecniche a spettro diffuso atte a
limitare le interferenze fra i diversi dispositivi.
Molti apparecchi quali telefoni cordless, forni a microonde, radiocomandi
per cancelli automatici, sistemi di allarme, giocattoli, apparati radar
lavorano nelle bande ISM andando ad interferire con il normale
funzionamento delle LAN wireless.
Una ulteriore problematica è relativa alla sicurezza delle comunicazioni: i
dati trasmessi via radio sono facilmente intercettabili e vanno quindi
crittografati, occorre inoltre fornire sistemi di autenticazione dei punti di
accesso.
Per i costi contenuti, la sua semplicità
e la larga diffusione sul mercato, Bluetooth
sembra
essere
la
tecnologia
wireless
destinata a dominare il mobile computing
del prossimo futuro.
Ad incoraggiare l’introduzione di tale
tecnologia è stata l’esigenza sostituire i cavi
nella connessione tra dispositivi elettronici
sia portatili che fissi, quali notebook, stampanti, telefoni, PDA. Periferiche
53
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
“bluetooth enabled” possono costituire autonomamente delle reti ad hoc
per scambiarsi informazioni e servizi. Tale tecnologia consentirà in futuro
la sostituzione di gran parte dei cavi proprietari con un unico collegamento
radio universale.
L’estrema semplicità sia architetturale che di utilizzo rappresenta la chiave
di un successo tale da prevedere che nel 2007 il 65% dei telefoni cellulari,
il 44% dei PDA e il 36% dei notebook sarà prodotto con l’interfaccia
Bluetooth integrata [32]. Previsioni tanto ambiziose trovano giustificazione
anche in una serie di fondamentali vantaggi offerti dalla tecnologia di casa
Ericsson:
1. richiede una quantità ridotta di risorse energetiche (less power
consumptive technology);
2. lavora nella banda ISM (Industrial, Scientific, Medical);
3. prevede bassi costi di produzione e di vendita dei dispositivi;
4. è particolarmente adatta per il last meter access [33].
Infine una gestione deterministica nell’assegnazione del canale (TDD Time Division Duplex) la rende validamente utilizzabile a supporto di
applicazioni real-time.
54
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
Sulla scorta di una tale popolarità e di previsioni di mercato tanto
incoraggianti, il presente lavoro di tesi propone come caso studio un’analisi
dei comportamenti di infrastrutture basate su tecnologia Bluetooth in
un’ottica dependability oriented come illustrata nei capitoli precedenti.
3.2
Bluetooth
Bluetooth è un termine che identifica l’aderenza di un prodotto ad
uno standard industriale sviluppato da Ericsson e in seguito formalizzato
dal Bluetooth Special Interest Group (SIG) costituito inizialmente da Sony,
Ericsson, IBM, Intel, Toshiba, Nokia e a cui si sono poi aggiunti negli anni
altri grossi nomi del settore.
Figura 3.2 Bluetooth Stack
Al fine di garantire la connettività tra dispositivi di produttori differenti, lo
standard definisce non solo i dettami della comunicazione radio, ma anche
55
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
del protocollo di comunicazione che rispecchia una struttura stratificata in
cui i servizi offerti dal livello i-simo sono resi disponibili al livello i+1 e la
comunicazione “logica” avviene tra livelli omologhi (cfr. Figura 3.2).
Ancora per favorire l’interoperabilità tra devices di produttori diversi il SIG
ha introdotto il concetto di Bluetooth Profile: come si legge dalle specifiche
[34] l’interoperabilità è garantita per un determinato servizio se i dispositivi
sono conformi alle specifiche del relativo Bluetooth Profile.
I diversi profili sono organizzati in maniera gerarchica come rappresentato
in Figura 3.3.
Figura 3.3 Bluetooth Profiles Organization
Ad oggi Bluetooth è supportata da quasi tutti i sistemi operativi tra cui
Linux in tutte le sue distribuzioni, le versioni mobile dei sistemi di casa
Microsoft ed infine l’ultimo arrivato Windows Xp Service Pack 2.
56
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
Nei paragrafi successivi si andranno ad illustrare le caratteristiche peculiari
dei livelli che offrono supporto ai servizi di rete Ip.
3.2.2
Livello Radio
Il livello Radio di Bluetooth lavora nella banda ISM a 2.4GHz,
riduce l’interferenza prodotta da segnali estranei scegliendo, in maniera
pseudoaleatoria, una diversa frequenza dopo ogni singola trasmissione.
Comparato con altri sistemi FHSS (Frequency Hopping Spread Spectrum)
che lavorano nella stessa banda di frequenze, il Bluetooth Radio salta in
frequenza più frequentemente ed utilizza pacchetti di dimensioni minori,
garantendo così una adeguata resilienza all’interferenza pur adottando
livelli di potenza contenuti.
Per quanto riguarda le potenze, difatti, Bluetooth è disegnato con
particolare attenzione al risparmio delle risorse energetiche dei dispositivi,
sono previste tre classi di potenza :
• Power Class 1:
dispositivi che lavorano con distanze maggiori
(~100m), con una potenza massima di 20dBm,
• Power Class 2: per coprire distanze ordinarie (~10m), con una
potenza massima di 4dBm,
• Power Class 3: dispositivi a corto raggio (~10cm), con una potenza
massima di 0dBm.
57
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
L’interfaccia radio di Bluetooth lavora con una potenza nominale di 0dBm,
opzionalmente i dispositivi possono alterare la potenza in trasmissione per
estendere la copertura o lavorare in ambienti particolarmente ostili. Sistemi
di power control realizzati dal LMP (Link Manager Protocol) ottimizzano
la potenza misurando l’RSSI (Receiver Signal Strength Indicator) e
cercando di posizionarsi nella golden receive power range, che costituisce
il migliore trade-off tra risparmio energetico e bit error rate.
3.2.3
Livello Baseband
Baseband è il livello fisico di Bluetooth. Si occupa della gestione del
canale oltre a fornire servizi quali correzione degli errori, identificazione
della sequenza di hop e sicurezza Bluetooth.
Il canale è costituito dalla sequenza pseudorandom di hop attraverso le
frequenze disponibili all’interno della gamma assegnata (2,402Ghz2,480Ghz, con salti di 1Mhz, complessivamente un set di 79hops).
Due o più dispositivi Bluetooth che utilizzano lo stesso canale costituiscono
una piconet. In una piconet è sempre presente un dispositivo che ricopre il
ruolo di master e uno o più dispositivi slave fino ad un massimo di 7.
Il dispositivo master organizza e gestisce il canale di comunicazione. La
sequenza di hop, caratteristica della piconet, e la fase all’interno della
sequenza, sono determinate a partire dall’indirizzo Bluetooth e dal clock del
master.
58
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
La comunicazione all’interno di una piconet viene gestita dal dispositivo
Master secondo una politica TDMA (Time Division Multiple Access): il
canale viene suddiviso in slot temporali di 625μ sec (625bit per slot), time
slot pari sono riservati al master, dispari per terminali slave, realizzando
dunque anche un duplexing temporale.
In una piconet sono contemplate sia trasmissioni punto-punto che
trasmissioni
multipunto,
occorre
però
considerare
che
tutte
le
comunicazioni passano attraverso il master della piconet, anche nel caso in
cui questi non sia il destinatario ultimo.
Più piconet possono coprire la stessa area : giacché ogni piconet ha
un proprio master, ciascuna segue una diversa sequenza di hop in linea di
principio non interferendo con le altre. All’aumentare delle piconet però la
probabilità di collisione cresce, comportando un leggero calo delle
prestazioni.
Un gruppo di piconets che condividono una o più unità
formano una struttura interconnessa più ampia denominata scatternet,
l’interconnessione avviene grazie ad un dispositivo che funge da brigde e
che, evidentemente, non potrà essere master per più di una piconet.
Figura 3.4 Bluetooth Scatternet
59
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
In un’ottica di risparmio energetico, è consentito ai dispositivi slaves
di configurarsi quali entità passive della rete: oltre allo stato active, infatti,
sono contemplate condizioni di sniff, park, hold in cui un dispositivo può
permanere se non coinvolto in connessioni attive. Affinché due o più
devices possano connettersi è necessaria una procedura di mutua
autenticazione. Un dispositivo che voglia diventare master di una piconet
contatta altri devices eventualmente presenti ed in stato discoverable,
inviando il proprio indirizzo fisico e dando il via ad una procedura che
prende il nome di inquiry. La procedura attraverso la quale il master
instaura la connessione vera e propria con uno slave prende invece il nome
di pairing ed è seguita da una fase per la definizione di una chiave
crittografica detta link key.
3.2.4
Logical Link Control and Adaptation Layer Protocol
Il Logical Link Control and Adaptation Layer Protocol (L2CAP)
fornisce servizi orientati e servizi non orientati alla connessione ai livelli
superiori,
con
capacità
di
multiplazione,
di
segmentazione
e
riassemblaggio.
L2CAP consente ai protocolli di livello superiore e di applicazione di
trasmettere e ricevere pacchetti fino alle dimensioni massime di 64Kbytes.
Il pacchetto dati Bluetooth è difatti limitato a livello baseband ad un
massimo di 341bytes.
L’utilizzo di tale dimensione come MTU
comporterebbe un inutile aumento di overhead per i livelli superiori e
60
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
conseguenti inefficienze in protocolli studiati per lavorare con pacchetti di
maggiori dimensioni.
La funzionalità di SAR (Segmentation and
Reassembly) si occupa di risolvere questo problema al livello datalink di
Bluetooth, lasciando trasparente il servizio ai livelli superiori.
Sono supportate due tipologie di comunicazione : sincrone orientate alla
connessione (SCO Synchronous Connection Oriented) ed asincrone prive
di connessione (ACL Asynchronous Connection Less).
Il canale SCO
supporta traffico vocale real-time utilizzando strategie di allocazione fissa
degli slot temporali. I canali ACL supportano invece traffico di tipo best
effort : gli slot asincroni hanno difatti priorità inferiore rispetto a quelli
sincroni e l’assegnazione avviene attraverso meccanismi di polling ad
opera del dispositivo master.
Il funzionamento è chiarito nelle immagini seguenti :
Figura 3.5 Un’unità slave può trasmettere solo se contattata dal master, nello
slot immediatamente precedente. In presenza di un unico slave la dimensione
della frame è pari ad un’unica coppia di slot.
61
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
Figura 3.6 In presenza di un numero maggiore di slaves le dimensioni della frame
si allungano. Ogni slave dovrà attendere dunque un tempo maggiore prima che il
master lo ricontatti per consentire la trasmissione.
Figura 3.7 Per incrementare la larghezza di banda, è possibile aggregare più slot in
un’unica trasmissione in una o entrambe le direzioni. Ciò consente anche la
riduzione dell’overhead.
Bluetooth supporta framing 1/1, 3/1, 5/1 corrispondenti rispettivamente a pacchetti
del tipo DH1, DH3, DH5
62
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
3.2.5
_________________
Bluetooth Networking Encapsulation Protocol BNEP
BNEP consente di incapsulare pacchetti di protocolli quali IPv4 ed
IPv6 per fornire capacità di Networking a periferiche Bluetooth.
I servizi offerti ai livelli superiori sono del tutto analoghi a quelli offerti
dalle reti IEEE 802.3, in tale senso BNEP rappresenta una vera e propria
interfaccia di rete, seppure virtuale.
Figura 3.8 BNEP Bluetooth
Networking Encapsulation Protocol
Come è possibile osservare in figura 3.8, BNEP semplicemente sostituisce
la testata 802.3 con una intestazione BNEP per l’indirizzamento di livello
rete ed affida la PDU (Packet Data Unit) al livello L2CAP per il
trasferimento via Bluetooth. Maggiori dettagli sul formato dei pacchetti e
sulle modalità di incapsulamento sono reperibili in [35].
3.3
Il profilo PAN
Un profilo Bluetooth è l’insieme delle regole che disciplinano
l’utilizzo del Bluetooth stack in ogni dispositivo, in particolare definisce:
63
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
• quali caratteristiche sono richieste allo stack per la fruizione e/o la
pubblicazione del servizio cui il profilo stesso si riferisce;
• il modo in cui uno sviluppatore deve utilizzare le apposite API per
interfacciarsi al protocollo Bluetooth sottostante;
• le regole comportamentali che un generico utilizzatore è tenuto a
seguire per abilitare le funzionalità a livello utente.
Il profilo PAN (Personal Area Networking Profile) formalizza le regole
che consentono a dispositivi Bluetooth di formare una rete ad hoc o di
accedere alla rete Internet attraverso un punto di accesso (NAP, Network
Access Point). Il profilo PAN definisce anche le modalità per il trasporto
di traffico IP su connessioni Bluetooth.
Come discusso nel paragrafo
precedente BNEP è il protocollo che realizza la conversione di traffico IP
in traffico Bluetooth.
Per il profilo PAN sono definiti due possibili scenari di utilizzo:
• Network Access Point (NAP): un network access point è un
dispositivo che funge da brigde tra la rete IP ed una piconet
Bluetooth consentendo ai dispositivi che ne fanno parte di accedere
alla rete e a tutte le sue risorse; la topologia caratteristica di uno
scenario NAP è rappresentata in Figura 3.9.
64
Capitolo III :
Presentazione di un caso studio: Introduzione a Bluetooth
_________________
Figura 3.9 PAN: Scenario di utilizzo NAP
• Group Ad-Hoc Networks (GN): più dispositivi, coordinati da un
master, si connettono tra loro a formare una rete self-contained
ovvero senza l’utilizzo di hardware o infrastrutture di rete
aggiuntive. La topologia di una rete ad hoc è descritta in Figura 3.10.
Figura 3.10 PAN: Scenario di
Group ad hoc Networking
Un PAN User (PANU) è un dispositivo che usufruisce del servizio NAP e/o
del servizio GN rivestendo dunque il ruolo client in entrambi gli scenari.
Ulteriori dettagli sul profilo PAN e sulla modalità di instaurazione delle
connessioni sono disponibili in [36].
Capitolo IV
Presentazione di un caso studio :
Infrastruttura per la raccolta dati
Sebbene Bluetooth si stia avviando a divenire la tecnologia
maggiormente utilizzata nell’ambito delle comunicazioni wireless a corto
raggio, ancora poco si conosce delle sue prestazioni in termini di
affidabilità e di utilizzo del canale.
Parallelamente il progetto e la
validazione di una infrastruttura di comunicazione wireless affidabile ed
altamente disponibile richiede la conoscenza della natura e della
distribuzione dei fallimenti che possono presentarsi durante il normale
utilizzo del sistema. Tale esigenza ha dato vita ad una intensa attività di
ricerca, che ha portato alla realizzazione di una infrastruttura distribuita per
la raccolta di dati di fallimento Bluetooth [37] presso il laboratorio ITEM
del Consorzio Interuniversitario Nazionale per l’Informatica (CINI).
Tale infrastruttura costituisce per il presente lavoro di tesi una importante
risorsa per esplorare metodologie e strategie applicabili alle diverse fasi del
processo di analisi, dalla collezione dei dati alla loro interpretazione.
Nei paragrafi che seguono viene descritta l’infrastruttura di raccolta ed il
processo di generazione e collezione dei dati.
66
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
4.2
La generazione e la raccolta dei dati
Come discusso nei precedenti capitoli, per poter condurre una analisi
quanto possibile esaustiva del comportamento di un sistema è necessario
disporre di una ingente quantità di dati che facciano riferimento ad un
utilizzo continuativo dei servizi offerti. Al fine di comprendere a fondo le
modalità di fallimento del sistema si rende inoltre necessario disporre
informazioni relative i legami che queste hanno con l’architettura hardware
e software sottostante. Sulla scorta di tali esigenze, l’insieme dei dati
necessari all’analisi è un insieme eterogeneo che si è scelto di generare
attingendo a tre diverse fonti di informazione:
• System level data: dati raccolti attraverso meccanismi di logging
forniti dal sistema operativo e relativi a protocolli coinvolti nello
stack Bluetooth (L2CAP, LMP, BNEP,…).
Dati di questo tipo
vengono archiviati, in maniera automatica, dal sistema operativo in
un file di log, d’ora in avanti SystemLog. A partire da quest’ultimo
sono poi generati due ulteriori files:
o InfoLog, contenente tutte i messaggi relativi agli eventi
intercettati dal logger di sistema;
o ErrorLog, contente messaggi relativi esclusivamente ad
situazioni di errore e warnings.
67
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
Dati di questo tipo risultano essenziali per comprendere i legami
esistenti tra fallimenti del sistema e l’architettura di supporto.
Occorre considerare infine che le modalità di generazione dei
suddetti files così come il formato delle informazioni risultano
strettamente dipendenti dal sistema operativo.
• User level data: informazioni relative a fallimenti che utenti
Bluetooth sperimentano durante l’uso dei servizi e che scelgono di
condividere mediante l’inserimento di una propria descrizione del
problema nel form disponibile online sul sito del Mobilab Group
all’indirizzo: http://www.mobilab.unina.it/BTDEPEND.htm.
Data la poca sistematicità e la scarsa formalità delle descrizioni
ottenibili, le informazioni dedotte potranno essere utilizzate
esclusivamente come verifiche a supporto dei risultati ottenuti
mediante meccanismi di logging automatico.
• Emulation: la necessità di disporre di ingenti quantità di dati per
conferire rilevanza statistica ai risultati dell’analisi ha suggerito lo
sviluppo di software in grado di emulare il comportamento di un
potenziale utente Bluetooth.
Dati appartenenti a questa classe,
perchè generati in maniera sistematica e continua, risultano
estremamente significativi nell’economia generale del lavoro di
analisi.
68
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
4.2.2
Architettura per la raccolta dati
Per la raccolta dei dati di utente (user level data) e dei dati generati
tramite emulazione, è stata utilizzata un’architettura ad hoc, rappresentata
in Figura 4.1.
Figura 4.1 Diagramma di alto livello del
sistema di raccolta dati
Un Bluetooth Node (BN) rappresenta un qualsiasi dispositivo in possesso di
un’interfaccia Bluetooth sul quale l’utente abbia scelto di installare un Log
69
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
Analyzer. Quest’ultimo si occupa di prelevare e filtrare i dati relativi ad
errori di sistema inerenti Bluetooth per poi inviarli al Log Server Node
attraverso un’interfaccia di rete (wireless o wired) disponibile sul
dispositivo. Attraverso uno User Workstation Node UWN, un qualsiasi
terminale dotato di accesso ad Internet, l’utente può inoltre arricchire le
informazioni raccolte dal Log Analyzer fornendo una descrizione spontanea
di fallimenti riscontrati durante l’uso di servizi o applicazioni legate a
Bluetooth. La combinazione delle informazioni raccolte dall’utente circa la
natura del fallimento, affiancate dalle informazioni di sistema raccolte in
maniera automatica dal BN, arricchiscono una casistica di fallimento
essenziale per le analisi successive.
Un Client Simulation Node (CSN) è un dispositivo dotato di un’interfaccia
di rete Bluetooth e di un Log Analyzer su cui sia installato il software di
emulazione : BlueTest.
BlueTest simula le interazioni tipiche di una
sessione applicativa che richieda l’accesso alla rete pubblica.
Il CSN
comunica con un Server Simulation Node (SSN) che attraverso
l’applicazione BlueTest Server emula un Access Point Bluetooth, offrendo
quindi il servizio NAP, (paragrafo 3.3). Informazioni relative ad eventuali
fallimenti identificati sono registrati dal CSN in un proprio file di log:
TestLog.
Infine il Log Server Node (LSN) è la central repository per i dati raccolti.
L’accesso ai dati è disciplinato da tre differenti servizi: un Web Server per
la raccolta dei dati di utente; un Log Server per la raccolta dei dati prodotti
70
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
dai Log Anayzer; un Database Server per la gestione e la persistenza dei
dati raccolti;
4.2.3
Struttura e persistenza dei dati
Figura 4.2 Schema logico del database
In figura 4.2 è rappresentato lo schema logico del database che conserva i
dati raccolti. Dal paragrafo precedente emerge che due sono le tipologie di
dati conservati all’interno del Log Server:
• US - User and System data, raccolti da UWNs e BNs grazie alla
collaborazione spontanea di utenti Bluetooth.
• EMU Emulation data, raccolti in maniera automatica da CSNs e
SSNs durante l’esecuzione dell’applicazione emulativa BlueTest.
Capitolo IV :
71
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
A causa della differente natura dei dati: inaffidabili ed incostanti i primi,
dettagliati e sistematici i secondi si è resa necessaria la presenza di un
campo flag (data source) per distinguere in fase di analisi i dati raccolti in
funzione della loro tipologia.
La tabella system level data contiene le tipiche informazioni prodotte dal
log di sistema; a queste viene poi aggiunto un campo che identifica l’Host
sul quale i dati sono stati generati, il campo datasource ed un campo Tuple
ID per implementare tecniche di raggruppamento di entries correlate in una
singola entità logica. Per quanto riguarda le entries presenti nella system
level data, formato e livello di dettaglio sono i medesimi sia per i dati
prodotti dai BNs che dai CSNs: entrambe le tipologie sono quindi ritenute
affidabili dal punto di vista delle informazioni contenute, occorre però
considerare che le prime non dovrebbero essere utilizzate per estrarre
misure di dependability poiché non è garantita la continuità nell’uso del
Log Analyzer, durante il periodo di osservazione, da parte dell’utente.
La tabella user level data contiene invece le tipiche informazioni che
possono essere raccolte da un utente in presenza di un fallimento : data e
ora in cui si verifica il fallimento (Time of failure), problema riscontrato
(Error message), durante quale attività dell’utente (During), il tipo di
azione di recovery intrapresa (Recovery) e l’istante in cui è stata ripristinata
una condizione di normale funzionamento (Time of recovery), la
responsibility del fallimento (S.O., software di sistema, software
applicativo, software di terze parti, stack Bluetooth) ed infine il tipo di
72
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
connessione Bluetooth (Bluetooth connection type) sulla quale si è
verificato il problema (L2CAP ACL, L2CAP SCO, PAN, RFCOM).
A queste informazioni vengono inoltre aggiunte, in maniera automatica a
valle di una operazione di autenticazione, l’identificativo dell’utente
(User), dell’Host ed il campo data source.
In questo caso la
differenziazione tra le due tipologie di fonti di informazione è un aspetto
cruciale per l’analisi successiva: data la poca sistematicità e la scarsa
affidabilità delle descrizioni sottomesse dagli utenti in funzione del loro
grado di competenza, le informazioni dedotte dovranno essere utilizzate
esclusivamente come verifiche a supporto dei risultati ottenuti mediante
meccanismi di logging automatico nei CSNs; questi ultimi risultano
estremamente significativi nell’economia generale del lavoro di analisi
perché generati da applicazioni emulative che registrano esattamente ed in
maniera sistematica la dinamica di un fallimento.
4.2.4
Emulazione del traffico
L’adozione di un approccio basato sull’emulazione di un
comportamento, presuppone un’approfondita conoscenza del problema
reale al fine di poterne fornire una adeguata caratterizzazione, in termini
preferibilmente statistici, o, qualora non possibile, attraverso euristiche in
grado di riprodurlo. BlueTest realizza l’emulazione dei profili di carico
maggiormente rappresentativi per l’utilizzo di una rete Bluetooth,
attingendo, ove possibile, alla letteratura più recente per quanto concerne le
distribuzioni statistiche delle attività da riprodurre. Un diagramma degli
73
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
stati di alto livello, relativo al comportamento di un client Bluetooth è
riportato in Figura 4.3a.
Figura 4.3 BlueTest
(a) Diagramma degli stati
(b) Flusso di esecuzione in assenza di errori
Ogni CSN parte dallo stato SCANNING per ritornarvi periodicamente, in
condizioni normali, dopo un periodo di attesa (WAIT). Se si presentano
errori, invece, il CSN entra nello stato RECOVERY per cercare di
ripristinare il suo normale funzionamento: una variabile, WL (warning
level), viene incrementata ogni qualvolta il normale ciclo esecuzione (cfr.
Figura 4.3b) viene interrotto. Tale variabile offre una indicazione della
gravità del problema: al crescere del valore di WL, cresce la severità
dell’azione che si rende necessario intraprendere; il successo di una
74
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
determinata azione di recovery consente inoltre di dedurre l’entità
responsabile del fallimento.
Tabella 4.1 Azioni di Recovery
Durante lo stato di SCANNING un CSN è impegnato in operazioni di
discovery di dispositivi vicini (inquiry) e/o di servizi (sdp search).
Verosimilmente, infatti, ogni utente intenzionato ad utilizzare Bluetooth ha
necessità di sondare la presenza di altri dispositivi nel suo raggio d’azione
per verificare la possibilità di usufruire un certo tipo di servizio. La
frequenza di occorrenza di dette operazioni (inquiry e/o sdp search) è stata
stabilita grazie ad euristiche derivanti da osservazioni sull’usuale utilizzo di
Bluetooth ed è riportata in Tabella 4.2.
Tabella 4.2 Probabilità di occorrenza delle
operazioni di scan/sdp search
A valle della fase di scoperta e della successiva fase di pairing (stato
CONNECTION), durante la quale è anche scelto in maniera casuale il tipo
75
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
di pacchetto da utilizzare, un CSN perviene allo stato USE in cui viene
emulata l’effettiva attività svolta dal client.
Poiché, negli scenari di interesse, Bluetooth viene prevalentemente adottato
quale tecnologia per il last meter access [33] si è scelto di emulare profili
di traffico legati all’utilizzo della rete globale. In Tabella 4.3 sono riportate
le percentuali di utilizzo dei diversi protocolli applicativi [38].
Tabella 4.3 Percentuale di utilizzo delle applicazioni
in Internet
L’emulazione prevede, a valle della scelta di un protocollo applicativo, la
riproduzione di una tipica sessione di scambio dati fissando dunque
parametri caratterizzanti quali dimensione dei pacchetti inviati ( Ls ),
dimensione dei pacchetti ricevuti ( Lr ), numero di pacchetti di cui si
compone il trasferimento (N), ritardo nella generazione del traffico (D).
Al termine della sessione ogni CSN si porta nello stato DISCONNECTION
in cui si provvede a chiudere la connessione ed a liberare le risorse
utilizzate per poi pervenire nello stato di WAIT: il tempo di permanenza in
questo stato è rappresentativo del tempo che intercorre tra l’esecuzione di
attività successive.
76
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
Sintetizzando, è possibile schematizzare il comportamento di BlueTest
nella gestione di workload profiles attraverso un vettore di parametri
caratteristici :
• S: Scan flag, che indica se sarà effettuata o meno l’operazione di
inquiry;
• B: Baseband Packet type, ovvero il particolare tipo di pacchetto
Bluetooth da utilizzare per la trasmissione;
• WL: WorkLoad profile, ovvero la particolare attività da riprodurre
(WEB,FTP...);
• Lr , Ls , N, D: come definiti.
4.2.5
Il LogAnalyzer
In un processo di valutazione measurement-based la fase di raccolta
dei dati è generalmente seguita da una serie di operazioni di manipolazione
degli stessi per far fronte a due situazioni tipiche che renderebbero
altrimenti complesso il lavoro di analisi:
77
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
• Volume dei dati : le informazioni raccolte dai logger di ogni sistema
operativo sono generalmente ridondanti e non tutte significative ai
fini dell’analisi che si intende condurre. Come discusso nel capitolo
secondo, la riduzione della mole di informazioni da gestire, senza
alterarne
il
contenuto
informativo,
agevola
i
processi
di
interrogazione dei dati oltre che eventuali operazioni di invio ad una
central repository remota.
• Formato dei dati : il formato con cui le informazioni sono registrate
sui files di log varia non soltanto al variare del S.O. ma anche della
sorgente da cui esse provengono e dalla loro tipologia (informazioni
di errore, warning, alert,….)
pertanto tipicamente si cerca di
renderle conformi ad un formato predefinito.
Nell’architettura di Figura 4.1 la responsabilità di dette operazioni è
demandata al LogAnalyzer il cui diagramma degli stati di alto livello è
riportato in Figura 4.4.
Figura 4.4 Log Analyzer: Diagramma di alto livello
L’applicazione è progettata per processare le tre differenti tipologie di log
files generati dai nodi dell’architettura; lavora in quattro fasi che si ripetono
ciclicamente: (1) estrazione dei dati dal file di log, (2) filtraggio delle
78
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
informazioni indesiderate, (3) applicazione degli algoritmi di coalescenza,
(4) invio al sistema centrale remoto.
1. Allo scattare di un timer, tipicamente ogni ora, il LogAnalyzer esce
dallo stato Asleep ed effettua una copia di lavoro dei files di log
attraverso una particolare funzionalità di logrotate;
2. Il filtraggio dei dati avviene facendo ricorso a due liste in cui sono
stati preventivamente inseriti i tag relativi agli eventi interessanti e
dunque da salvare (whitelist) ed i tag identificativi di eventi non
interessanti e dunque da filtrare (blacklist). La manipolazione dei
dati contenuti nelle liste avviene modificando un file di
configurazione in modo tale da consentire all’applicazione di
adattarsi alla particolare strategia di filtering senza la necessità di
apportare modifiche strutturali al codice.
3. Il LogAnalyzer mette in opera sia strategie di coalescenza temporale
sia di coalescenza basata sul contenuto. La prima, a differenza di
quanto illustrato nel Paragrafo (2.3), non è utilizzata per la data
reduction, piuttosto è volta a raggruppare entries relative al
medesimo evento e registrate a breve distanza assegnando loro uno
stesso Tuple ID; La coalescenza basata sul contenuto, invece, è volta
alla riduzione del volume dei dati e punta a raggruppare più entries
relative ad un medesimo
evento noto in un’unica entry
rappresentativa dell’evento stesso e contenente esclusivamente le
informazioni necessarie.
In particolare il LogAnlayzer riduce le
79
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
informazioni relative al boot ed allo shutdown di un host mediante
l’individuazione di un pattern di start/stop.
4. Una volta completate le operazioni di filtraggio e coalescenza, il
LogAnalyzer invia i dati al Collection Log Server, cui è demandata la
responsabilità di trasferirli sul database per le successive
elaborazioni. Due tipologie di dato possono essere inviate: system
level data ovvero le entries prodotte dall’estrazione, il filtraggio e la
coalescenza di InfoLog e ErrorLog; user level data, dati raccolti
dalle applicazioni emulative, estratti e filtrati dal TestLog.
L’onere del trasferimento dei dati trattati al Collection Log Server
può essere o meno a carico del LogAnalyzer stesso. Nel secondo
caso tale responsabilità è demandata ad una applicazione specifica:
l’Entry Sender. Tale soluzione, rappresentata in figura 4.5, comporta
diversi vantaggi: libera il LogAnalyzer da problemi che possono
verificarsi durante il trasferimento dei dati, quale ad esempio
l’assenza di accesso ad Internet; consente all’utente di scegliere il
momento opportuno per il trasferimento dei dati.
Figura 4.5 Suddivisione delle responsabilità del LogAnalyzer
80
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
4.3
Il testbed
L’architettura del testbed utilizzato per la raccolta dei dati emulati, è
illustrata in Figura 4.6 e riproduce una piconet Bluetooth costituita da sette
dispositivi nel raggio di una decina di metri.
Figura 4.6 Architettura del testbed
Il testbed è strutturato in maniera eterogenea con riferimento alle
caratteristiche hardware e software dei nodi come riportato in tabella:
PC
S.O.
Distribuzione
Kernel
CPU
Mem
Giallo
Linux
Mandrake
2.4.21-0.13mdk
P4 1.60GHz
128Mb
Verde
Linux
Mandrake
2.4.21-0.13mdk
P3 350Mhz
256Mb
Misero
Linux
Debian
2.6.5-1-386
Celeron 700Mhz
128Mb
Capatamarano
Linux
Fedora
2.6.9-1.667
P4 1.70GHz
512Mb
Ipaq H3800
Linux
Familiar 0.8.1
2.4.19-rmk6-pxa1-hh37
Zaurus SL-5600
Linux
OpenZaurus 3.5.2
2.4.18-rmk7-pxa3-embedix
Win
Windows
P4 1.80Ghz
512Mb
XP Professional Service Pack 2
81
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
La particolare attenzione ai sistemi operativi installati sui diversi hosts è
giustificata dal fatto che il Bluetooth Stack è generalmente un componente
di livello kernel e dunque a stretto contatto con i meccanismi di gestione
delle interfacce messi in opera dal software di base. Alla luce di questa
considerazione è ragionevole supporre che l’impatto di fallimenti Bluetooth
sul sistema possa variare a seconda del sistema operativo e dunque del
software di gestione di basso livello.
Ad oggi gran parte dei sistemi operativi di largo consumo dispone di un
supporto per Bluetooth partendo dal consolidato Bluez in ambiente Linux,
passando per i moduli Bluetooth di Symbian e Windows CE, fino al
giovanissimo supporto di Windows XP. Le sezioni che seguono descrivono
i supporti offerti dai S.O. coinvolti nel testbed concentrando l’attenzione
sulle problematiche legate al loro utilizzo per il profilo PAN.
4.3.2
Linux e Bluetooth : lo stack BlueZ
BlueZ è lo stack Bluetooth ufficiale in ambiente Linux. Sviluppato
inizialmente dalla Qualcomm Incorporated è ora distribuito in maniera
open-source sotto licenza GNU GPL (General Public License).
Ufficialmente parte del kernel di Linux a partire dalla versione 2.4.6, BlueZ
consiste di una serie di moduli tra cui:
• Bluetooth kernel subsystem core ;
Capitolo IV :
82
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
• livello kernel di L2CAP e SCO audio ;
• implementazione del livello kernel di RFCOMM e BNEP ;
• HCI UART, USB, PCMCIA e driver di device virtuali;
• Librerie e demoni per General Bluetooth ed SDP;
• Utilities di test e configurazione;
• Strumenti di monitoring ed analisi (ad esempio hcidump per il
monitoring delle connessioni a livello HCI);
Diverse sono le caratteristiche che hanno consolidato il successo di BlueZ
rendendolo ad oggi lo stack più utilizzato, tra le altre:
• l’implementazione completamente modulare;
• il supporto per diversi dispositivi Bluetooth;
• l’utilizzo di un’interfaccia socket standard per tutti i livelli
Bluetooth;
• il supporto per la sicurezza di servizi e dispositivi;
83
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
• la compatibilità con le più diffuse piattaforme hardware (Intel e
AMD X86, AMD64 (x86-64), SUN SPARC 32/64bit, PowerPC
32/64bit, Intel StrongARM and XScale, Motorola DragonBall ).
La realizzazione di applicazioni che utilizzino il profilo PAN è resa
possibile dal supporto che BlueZ offre per BNEP ed L2CAP. La struttura
completamente modulare di BlueZ richiede il precaricamento di moduli
relativi ai livelli sottostanti prima di poter stabilire una connessione PAN:
deputato ad abilitare il profilo e a stabilire le connessioni è un particolare
demone, pand, che va invocato previo il caricamento dei moduli relativi ad
HCI, L2CAP e BNEP.
Per ottenere maggiori informazioni in relazione alla causa di
fallimenti, lo stack Bluetooth delle macchine coinvolte nel testbed è stato
modificato in modo da essere maggiormente espressivo nella descrizione di
errori. Nessuna modifica ha coinvolto le funzionalità dello stack, è stato
unicamente aggiunto codice necessario per garantire una migliore capacità
di registrazione degli eventi nel log di sistema.
Un esempio di tali
modifiche è mostrato in Figura 4.7.
Figura 4.7 Esempio di modifica del codice sorgente di BlueZ
84
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
4.3.3
Windows XP e Bluetooth
Il supporto Bluetooth è disponibile nei sistemi Windows XP a partire
dalla release SP1 (Service Pack 1), nei sistemi XP Embedded a partire dal
SP2 ed in tutti i sistemi Windows CE.
Per il corretto funzionamento di applicazioni Bluetooth in ambiente XP è
necessaria l’installazione di un apposito package, Windows XP Embeddedbased run-time, per la risoluzione delle opportune dipendenze. Il supporto
Bluetooth di casa Microsoft fornisce servizi di base molto simili a quelli già
disponibili per altri protocolli di trasporto: analogamente a quanto accade
per altri protocolli di networking l’interfaccia fornita per l’implementazione
delle connessioni Bluetooth è di tipo socket-based.
Più precisamente,
Microsoft fornisce due diversi approcci per la programmazione Bluetooth:
1. Managing devices directly by using nonsocket Bluetooth interfaces;
2. using the Windows Sockets interface.
Il primo approccio prevede la manipolazione e l’accesso a dispositivi
Bluetooth mediante l’utilizzo di numerose funzioni e strutture dati spesso
legate da fitte relazioni di dipendenza che ne rendono poco intuitivo
l’utilizzo.
Il secondo approccio, invece, prevede ovviamente l’utilizzo
dell’interfaccia socket standard opportunamente estesa per rendere
possibile l’implementazione di operazioni prettamente legate a Bluetooth
quali la scoperta dei dispositivi e/o dei servizi disponibili.
85
Capitolo IV :
Presentazione di un caso studio: Infrastruttura per la raccolta dati ____________
Con particolare riferimento ai sistemi XP, sebbene le API fornite
nell’ambito del Microsoft Platform SDK consentano l’implementazione di
tutte le operazioni Bluetooth, l’interfaccia messa a disposizione da
Microsoft consente esclusivamente l’accesso ai protocolli basati su
RFCOMM e non ai livelli inferiori inibendo pertanto lo sviluppo di
applicazioni che utilizzino protocolli di comunicazione diversi da quello
seriale. Una siffatta struttura dello stack (cfr. Figura 4.8) e la conseguente
carenza, in termini di API, di strumenti per l’accesso ai livelli L2CAP e
BNEP rendono impossibile lo sviluppo di applicazioni basate sul profilo
PAN.
Figura 4.8
Per tale ragione l’implementazione di un client BlueTest in ambiente
Windows è stata realizzata grazie all’adozione di uno stack commerciale.
Capitolo V
Presentazione di un caso studio :
Selezione ed Analisi dei dati
Disponibilità ed affidabilità sono elementi chiave della dependability
dei computer systems. Dal momento che si fa sempre più consistente
l’utilizzo di sistemi mobili in scenari applicativi critici sia in termini
economici (business-critical scenarios) che in termini di affidabilità e
sicurezza (mission-critical scenarios), è atteso che nel prossimo futuro tali
aspetti possano risultare persino più importanti del sistema stesso.
Nei sistemi transazionali, ad esempio, o in applicazioni di teleimmersione o
telemedicina, il costo di un singolo fallimento potrebbe essere paragonabile
al costo dell’intero sistema o comportare danni a beni o persone.
I log di eventi costituiscono una importante risorsa per incrementare la
availability e la reliability di un sistema. Possono essere usati per diversi
scopi che vanno dalla trend analysis di lungo termine per identificare
cambiamenti; alla diagnostica on-line per predire failure e gestire i fault;
parallelamente è anche interessante una analisi off-line per diagnosticare
fuori servizio del sistema e produrre stime o monitorare la affidabilità del
sistema sul campo. Occorre però sottolineare che il grado di successo in
attività di questo tipo è in larga parte dipendente dalla qualità e dalla
completezza dei log di sistema. Se l’informazione è carente, incompleta o
Capitolo V :
87
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
di difficile interpretazione allora tali attività diventano maggiormente
complesse e talora non possibili.
L’assunzione implicita o l’ipotesi di lavoro su cui si basa ogni
attività di analisi attraverso l’uso dei log è che questi siano sufficientemente
completi da supportare l’analisi e validare le conclusioni.
In larga parte della letteratura la qualità dei log è data per garantita e non
viene attentamente valutata, sicché le statistiche e le interpretazioni
prodotte sono considerate realmente rappresentative del comportamento del
sistema. In [22] viene mostrato che sebbene sia sempre possibile trarre
delle conclusioni, maggiore sforzo ed attenzione vanno poste nel processo
di analisi. Ciò non vuol dire che i log di eventi siano non utilizzabili, ma
che una cura estrema deve essere adottata per derivare conclusioni
significative.
Nel presente capitolo vengono descritte le metodologie di analisi
applicate all’insieme di dati raccolti attraverso l’infrastruttura per il
monitoraggio e la collezione di fallimenti spontanei in piconet bluetooth
descritta nel capitolo precedente. Particolare attenzione viene dedicata allo
sviluppo di soluzioni per l’esplorazione dei legami esistenti all’interno dei
dati. Tale aspetto ricopre un ruolo essenziale nell’analisi, consentendo di
ricostruire il processo di fallimento partendo dalla sola osservazione delle
sue molteplici manifestazioni.
Nello specifico il lavoro di analisi proposto affronta tre problematiche:
88
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
• Rimozione della ridondanza introdotta nei dati dal meccanismo di
registrazione degli eventi: classificazione degli eventi, filtraggio,
estrazione e coalescenza.
• Relazioni esistenti tra le dinamiche di fallimento dei diversi Hosts.
• Legame tra errori di livello sistema e fallimenti, analisi dei fenomeni
di propagazione.
5.2
Approccio metodologico per l’analisi di un nuovo
set di dati
Nell’affrontare l’analisi di un nuovo insieme di dati è importante
adottare un approccio metodico e rigoroso. Tale esigenza diventa una
necessità nel caso di event logs prodotti dal sistema operativo e quindi
verosimilmente non privi di difetti nel processo di raccolta dati (cfr.
paragrafo 2.4).
Le fasi di cui si compone il presente lavoro di analisi sono descritte
in figura 5.1.
Il primo passo fondamentale consiste nell’identificare
l’insieme di dati che può rispondere alle esigenze di analisi. Deve poi
essere valutato per verificare che contenga dati corretti e di qualità
sufficientemente elevata.
Una volta completata tale esplorazione
preliminare dei dati, ha senso procedere con il processo di analisi e di
interpretazione dei risultati.
89
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Figura 5.1 Processo di selezione ed analisi dei dati
90
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
5.2.2
Identificare l’insieme di dati
Per portare a termine con successo questa importante fase occorre
innanzitutto definire con chiarezza gli obiettivi dell’analisi, in particolare il
problema da risolvere o le conclusioni che si spera di poter trarre.
Maggiore dettaglio nelle definizioni migliora sensibilmente l’intero
processo.
Una volta chiariti gli obiettivi il passo successivo consiste
nell’identificare un insieme di dati che possa essere adatto agli scopi.
Occorre, in particolare, valutare il potenziale data set per determinare se
l’informazione che contiene può considerarsi sufficiente per trarre e
validare conclusioni; dettagli da contemplare sono il tipo ed il volume dei
dati, il formato degli stessi, se il processo di collezione dei dati sia
documentato o meno, l’integrità generale dei dati. Due sono le possibili
conclusioni che si possono trarre in questa fase: un insieme di dati adeguato
per le analisi successive è stato identificato; occorre sviluppare un sistema
per acquisire nuove informazioni.
5.2.3
Valutare la qualità dell’insieme di dati
In questa fase bisogna analizzare in dettaglio il data set ed il
processo di collezione. Maggiori sforzi sono posti in questa fase, maggiore
velocità si avrà nelle analisi successive nonché una diminuzione delle
probabilità di incorrere in errore con la conseguente necessità di rivedere
l’analisi.
91
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Eventuali deficienze e limitazioni dei dati devono essere individuate e
comprese. Alcuni difetti tipici sono la presenza di TimeStamp errati, di
periodi di inattività non documentati, di entries non correttamente
formattate. E’ bene preparare una lista dei difetti, quantificarne la presenza
e condurre uno studio di sensibilità per valutarne l’impatto eventuale.
Questo conduce a migliori assunzioni e ad una maggiore consapevolezza di
ciò che si potrà ottenere dall’analisi, nonché nell’individuazione di possibili
stratagemmi da adottare durante l’analisi per aggirare tali difetti.
Un aspetto di particolare importanza consiste nel comprendere quali
informazioni non sono effettivamente presenti nei dati. Talvolta trascurare
tale aspetto può portare a trarre conclusioni errate sulla base dell’assenza,
nei dati, di alcune caratteristiche attese; al contrario se si ha coscienza del
fatto che tali misure sono state omesse, si conclude che l’assenza non ha
alcun significato.
Naturalmente se gli event logs sono di elevata qualità e ben
documentati presumibilmente tale fase richiederà la spesa di un tempo
molto minore.
5.2.4
Ottenere una comprensione basilare dei dati
Il passo successivo consiste nell’ottenere una comprensione basilare
dei dati. Si tratta di una importante fase preliminare per l’analisi che aiuta
a definire problematiche e obiettivi. A tale scopo può essere interessante
92
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
condurre analisi statistiche per ciascuna delle variabili: per variabili
numeriche sono sicuramente di interesse valori medi, deviazione standard,
range e valori estremi, mentre per variabili descrittive la scelta migliore è
rappresentata da analisi di frequenza e tabelle di contingenza. Esistono
inoltre
svariate
“illuminanti”.
rappresentazioni
grafiche
che
possono
risultare
Particolarmente efficaci e di facile utilizzo sono plots,
istogrammi e cross plots. Interessante è anche analizzare i valori estremi di
ciascuna variabile: l’analisi degli outliers può infatti aiutare ad identificare
eventuali errori nella metodologia di acquisizione e può fornire una prima
comprensione del comportamento del sistema.
5.2.5
Analisi dei dati
Il primo compito nella fase di analisi consiste nel produrre un piano
di analisi. Non deve assolutamente essere definitivo e strada facendo è
possibile eliminare o aggiungere analisi sulla base dei risultati ottenuti e
della maggiore comprensione del problema che ne segue.
Resta però
fondamentale la presenza di un piano per fornire all’analisi una direzione.
Un piano di analisi dovrebbe includere :
• una dichiarazione degli Obiettivi;
• l’identificazione delle variabili in ingresso;
93
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
• l’identificazione delle variabili d’uscita;
• strumenti di analisi che saranno adottati (ad esempio software di
analisi, test statistici);
• ipotesi e risultati attesi, qualora possibile.
5.3
Applicazione delle metodologie di analisi
Dopo aver delineato una possibile metodologia da seguire
nell’analisi di un nuovo insieme di dati, se ne illustra un esempio di
applicazione ai dati raccolti attraverso l’infrastruttura per il monitoraggio e
la collezione di fallimenti spontanei in piconet bluetooth descritta nel
capitolo precedente.
Lo studio che si descrive in particolare cerca di
mettere in luce alcune problematiche comuni che possono presentarsi
durante il processo d’analisi.
Come accennato nell’introduzione, l’interesse principale di questo lavoro di
analisi consiste nell’esplorazione dei legami esistenti all’interno dei dati in
relazione a tre problematiche:
• Rimozione della ridondanza introdotta nei dati dal meccanismo di
registrazione degli eventi.
• Relazioni esistenti tra le dinamiche di fallimento dei diversi Hosts.
94
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
• Legame tra errori di livello sistema e fallimenti, analisi dei fenomeni
di propagazione.
5.3.2
Identificazione e valutazione dell’insieme di dati
In relazione agli obiettivi esposti si è individuato un sottoinsieme dei
dati ritenuto adatto per le analisi successive. In particolare della struttura
originaria del database, come descritto nel paragrafo 4.2.3, sono stati
conservati i soli campi contenenti le sole informazioni relative gli
argomenti trattati.
Per quanto riguarda i dati di livello utente, le informazioni contenute nei
campi TimeOfFailure, ErrorMessage, Host, Recovery action, Data source,
sono state considerate un insieme essenziale e sufficiente per gli obiettivi
dell’analisi. I restanti campi sono stati invece considerati inessenziali ed
omessi per non complicare inutilmente il processo di analisi.
I campi Time, Message, Host, Data source, sono invece essenziali per
quanto riguarda i dati di livello sistema.
Il campo Process Name è
essenzialmente ridondante in quanto evincibile dal campo Message una
volta terminata la classificazione degli errori; si è però rivelato
estremamente utile in fase di classificazione e filtraggio degli errori in
quanto consente una migliore contestualizzazione dei messaggi.
I dati contenuti nel database sono stati acquisiti durante l’arco di circa un
anno, occorre però sottolineare che i dati raccolti in tale periodo non sono
95
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
tra loro omogenei. In particolare si distinguono 3-4 epoche, differenti sia
dal punto di vista dell’architettura del testbed che del comportamento degli
utenti simulati (cfr. Tabella 5.1).
Epoch
From
To
Clients
Workload type
Server
fixed parameters, no
Leox
scan, no SDP
fixed parameters,
Leox
scan, no SDP
fixed parameters,
Leox
scan, no SDP
1
07/06/2004 29/09/2004
Verde
2
29/11/2004 17/12/2004
Verde, Miseno, Giallo
3
17/12/2004 04/02/2005
Verde, Miseno, Giallo, Ipaq
4
04/02/2005 08/03/2005
Verde, Miseno, Leox, Ipaq
totally random
parameters, scan
SDP
Giallo
5
23/03/2005 03/05/2005
Verde, Miseno, Ipaq, Zaurus,
Azzurro
totally random
parameters, scan
SDP
Giallo
6
03/05/2005 05/07/2005
Verde, Miseno, Ipaq, Zaurus,
Azzurro
Coherent workload,
scan SDP
Giallo
7
05/07/2005
Verde, Miseno, Ipaq, Zaurus,
Capatamarano, Windows
today
Shaped parameters,
Giallo
scan SDP / Bond WL
Tabella 5.1 Processo di selezione ed analisi dei dati
Diversi studi hanno investigato il legame esistente tra carico cui è
sottoposto il sistema e le caratteristiche statistiche degli errori transienti.
Meyer [41] in particolare ha mostrato come la distribuzione degli errori sia
pesantemente dipendente dal tipo di utilizzazione del sistema oltre che dal
volume. Segue che una corretta analisi non può essere condotta sull’intero
campione in maniera indiscriminata perché il processo sottostante potrebbe
essere fortemente non stazionario, sebbene è comunque atteso contenere
lunghi intervalli di stazionarietà.
Inoltre, perché i risultati dell’analisi
possano essere significativi, il sistema deve essere esposto ad un ampio
96
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
ventaglio di possibili casi d’uso.
Le epoche che rispondono a tale
caratteristica sono le più recenti, inoltre sono equiparabili sia da un punto di
vista strutturale che dal punto di vista delle modalità di utilizzo; per
mantenere un volume di dati comunque significativo si è scelto dunque di
usare come finestra di osservazione un periodo di sei mesi che va dai primi
di maggio fino a circa metà del mese di ottobre 2005.
Nel periodo di interesse, come nell’intero data set, sono stati evidenziati
alcuni difetti e limitazioni nel sistema di raccolta dati; in parte sono stati
prontamente risolti, parte invece ha richiesto particolare attenzione durante
la fase di analisi per evitare di comprometterne i risultati. Di seguito si
riportano brevemente alcuni aspetti:
1. Errori nella registrazione dei timestamp.
E’ il caso di records nei quali il campo date/time è palesemente errato.
L’occorrenza di timestamps errati si verifica qualora vengano riportati
eventi nei log prima che l’orologio di sistema sia stato correttamente
inizializzato. Tipica causa del problema è l’utilizzo del Network Time
Protocol: l’indisponibilità del servizio o una cattiva configurazione può
impedire una corretta regolazione dell’ora corrente che si traduce spesso
in un reset dell’orologio di sistema al cosiddetto anno 0 (January 1,
1970, 00:00:00 GMT). Una differente possibilità consiste in un errore
dell’amministratore nella configurazione manuale dell’orologio di
sistema.
La presenza di timestamps errati, se non gestita correttamente, può
compromettere il calcolo di misure basate su intervalli temporali tra
Capitolo V :
97
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
eventi, quale per esempio il TBF. Sono comunque difetti di facile
identificazione poiché tipicamente gli spostamenti prodotti nelle misure
sono di diversi ordini di grandezza maggiori dei valori attesi. Semplici
tecniche di outliers detection come del resto una ispezione manuale del
database opportunamente ordinato portano ad una rapida identificazione
del problema che può essere risolto in maniera semplice eliminando le
entries corrispondenti oppure assegnando loro un offset corretto.
Nel caso in esame era presente un modesto numero di entries riportanti
datazioni antecedenti il 1980, che sono state prontamente eliminate, ed
una intera epoca, ottobre-dicembre 2004, riportata erroneamente come
registrata nel 2005; in questo caso si è resa sufficiente la correzione
sistematica di tali records prima che si verificasse sovrapposizione con i
dati più attuali.
2. Entries riportanti campi mancanti.
Riguardano eventi rari localizzati principalmente nelle prime epoche. Il
problema è stato risolto nelle versioni successive del Log Analyzer; non
ha comunque interessato il periodo d’osservazione oggetto di questo
lavoro di analisi.
3. Filtraggio migliorabile.
Malgrado il duplice approccio whitelisting\blacklisting adoperato nel
Log Analyzer, sono presenti nel database originale diverse entries non
collegabili ai servizi offerti dal sistema ed oggetto di analisi.
Significativo è il caso dell’errore “Connection script failed” che da solo
costituisce il 92% circa delle entries presenti nella System Level Data.
Capitolo V :
98
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Una tale presenza rendeva a prima vista poco significative le altre
tipologie di errore, alcune delle quali non riuscivano neppure a
raggiungere la soglia dell’uno percento. Ad una analisi più attenta tale
problema si è poi rivelato essere non collegato all’utilizzo di servizi
Bluetooth; le entries corrispondenti, così come per altri errori, sono state
rimosse grazie a regole di filtraggio più severe.
Si vuole infine
sottolineare come l’esplorazione manuale delle tabelle di contingenza
relative alle variabili di interesse costituisca un momento irrinunciabile
di verifica della correttezza degli algoritmi di estrazione e filtraggio dei
dati.
4. Formato dei messaggi migliorabile.
Principalmente nei dati di sistema, esistono migliaia di possibili
messaggi di errore. Una tale numerosità può complicare o persino
pregiudicare l’analisi se non gestita opportunamente. Con l’ausilio di
tabelle di contingenza e della consulenza di esperti del problema si è
osservato che a dispetto dell’enorme numero di messaggi di errori questi
potevano essere classificati in meno di una decina di categorie. Gran
parte dei messaggi differiscono semplicemente per pochi caratteri,
tipicamente un dettaglio di tipo numerico di grana eccessivamente fine
per gli scopi dell’analisi; altri invece riferiscono ad eventi simili in
maniera differente poiché generati su Host differenti, quindi da
meccanismi di logging di sistemi operativi differenti per kernel e
distribuzione (cfr. esempio in figura 5.2).
99
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Figura 5.2 Differenze nel formato dei messaggi
5. Periodi di inattività del testbed non documentati.
Per diverse esigenze quali manutenzione, assenza di alimentazione e
principalmente spegnimento volontario per altre attività, il testbed è
stato più volte inattivo per alcuni giorni, nell’arco del periodo di
osservazione. L’assenza di documentazione di tali eventi richiede una
maggiore attenzione in fase di analisi, fondamentale nell’affrontare il
calcolo di misure di dependability. La valutazione del MTBF, per citare
un esempio, può essere resa eccessivamente ottimistica per la presenza
di lunghi intervalli tra fallimenti in corrispondenza dei periodi di
inattività del testbed.
Chiaramente occorre gestire questo problema
durante il processo di analisi per trarre misure di dependability che siano
effettivamente rappresentative del comportamento del sistema.
6. Meccanismo di logging dei dati di sistema non affidabile.
Per ragioni non ancora sufficientemente esplorate, i dati di livello
sistema di alcune macchine mostrano alcuni periodi di assenza di
attività, non giustificabili attraverso normali comportamenti. Diverse
sono le possibili teorie che spaziano dalla presenza di guasti transienti
100
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
che provocano fallimenti di omissione ad un problema software nel
meccanismo di logging che porta ad una sovrascrittura o persino ad una
sostituzione dei files di log.
Un caso interessante, per certi versi
patologico, è quello dell’Host Azzurro che nell’ultimo periodo di
attività, prima della definitiva sostituzione, non ha prodotto alcuna
informazione di livello sistema.
Occorre osservare che si tratta di un problema piuttosto serio,
soprattutto ai fini del raggiungimento dell’ultimo obiettivo di analisi.
7. Coalescenza dei dati.
Come ampiamente discusso nel capitolo secondo, nei logs di sistema
vengono spesso riportati eventi multipli, che sono manifestazione di un
singolo guasto. Per evitare che tale ridondanza possa essere confusa
con informazione e che l’analisi successiva venga quindi polarizzata o
distorta da osservazioni ripetute di un medesimo problema, occorre che
tali reports vengano assimilati in un’unica entità logica, la tupla.
Benché tale operazione sia già eseguita dal Log Analyzer si ritiene
opportuno condurre un nuovo studio sulla coalescenza basato sulla
disponibilità dei dati e dunque su una maggiore consapevolezza del
problema.
Tale approccio consente inoltre di valutare in maniera
adeguata il trade-off tra l’efficacia del meccanismo di tupling e la
probabilità di collisione tra eventi non correlati.
8. Assenza di dati di livello sistema in macchine Windows
Allo stato attuale non si dispone di dati sufficienti per fornirne una
caratterizzazione.
101
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
5.3.3
Filtraggio, estrazione e coalescenza dei dati
Per far fronte ad alcuni dei difetti evidenziati nel precedente
paragrafo si è resa necessaria una ulteriore fase di filtraggio ed estrazione
dei dati.
Come risultato è stato prodotto un nuovo dataset ritagliato
secondo le esigenze di analisi. Contestualmente a tale operazione è stata
anche eseguita una riorganizzazione delle entries in tuple con il duplice
obiettivo di migliorare l’accuratezza delle analisi successive e, nel
contempo, ridurre il volume dei dati considerati.
Per realizzare il filtraggio dei dati è stata propedeuticamente condotta una
ispezione manuale dei messaggi di evento con l’obiettivo di realizzarne una
classificazione completa. Sono stati presi in considerazioni sia i dati di
livello utente, che i dati di livello sistema. Conclusa la classificazione degli
eventi è stato condotto un filtraggio basato su una whitelist che comprende
le sole categorie individuate, contestualmente sono stati anche uniformati i
messaggi di evento. In riferimento ai dati di livello utente, sono state
individuate le seguenti classi di fallimento:
• Bind failure, fallimenti generici verificatisi durante l’assegnazione
dell’indirizzo di livello rete all’interfaccia virtuale bnep.
• SDP Search failure, comprende fallimenti relativi la ricerca del
servizio NAP, quali servizio non disponibile sull’Access Point,
scadenza del timeout della richiesta, impossibilità di eseguire la
richiesta.
102
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
• Inquiry Search failure, fallimenti generici durante la ricerca di
dispositivi presenti all’interno della piconet.
Nel periodo di
osservazione tale problematica si è verificata un’unica volta ed è
stata pertanto esclusa dall’analisi.
• RSSI read failure, anche in questo caso si tratta di eventi rari e
quindi esclusi dall’analisi.
Rappresentano errori nell’esecuzione
delle API per interrogare il firmware circa lo stato qualitativo del
canale.
• Connection failure, si manifesta durante l’instaurazione di una
connessione Ip su Bluetooth: impossibilità di creare una connessione
oppure assenza dell’interfaccia di rete bnep.
• PAN disconnection failure, assimilabile al precedente, si verifica
esclusivamente su Host Windows quando al momento di chiusura
della connessione questa non viene trovata attiva.
• Receive failure, è prodotto dallo scadere del timeout del protocollo
applicativo; rappresentano la classe di errore più diffusa.
• Role failure, principalmente si verificano nei PDA, rappresentano
problematiche relative l’assegnazione dei ruoli all’interno di una
piconet.
Capitolo V :
103
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Per quanto riguarda invece i dati di livello sistema sono state identificate le
classi di errore riportate di seguito. Non è ugualmente immediato fornirne
una spiegazione in quanto tali eventi sono generati dal sistema operativo e
dallo Stack BlueZ piuttosto che dall’applicazione emulativa come nel caso
di fallimenti di livello utente. In generale si tratta di problemi verificatisi
durante l’uso dei protocolli coinvolti nel profilo PAN e descritti nel
capitolo terzo. Data la diversa natura dei ruoli, è utile infine distinguere tra
errori che possono verificarsi nel server dell’architettura, fornitore del
servizio di Network Access Point ed errori interni ai client che utilizzano
tale servizio.
Nel primo caso si distinguono le seguenti tipologie di errore:
• Packet Mismatch, non viene passato il controllo di errore al livello
applicativo, malgrado la frame fosse stata ritenuta corretta ai livelli
inferiori. E’ indice della forte presenza di burst di errori sul canale.
• PAN Connection.
• L2CAP ACL data receive, problemi durante la ricezione di pacchetti
ACL quali inizio frame inatteso, continuazione di frame non attesa.
• HCI ACL data packet, problemi durante la ricezione e la
trasmissione di pacchetti ACL: impossibilità di riconoscere l’handle
di connessione; scadere del timeout in trasmissione, distruzione di
una connessione in stallo.
Capitolo V :
104
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
• USB Device, problemi nella gestione del collegamento con il
dispositivo via USB.
Negli Host client sono invece state individuate le seguenti:
• SDP Search, errori durante l’esplorazione dei servizi sul AP:
connessione rifiutata, in timeout, AP non disponibile o che non
implementa il servizio richiesto.
• BNEP, problemi nell’accesso all’interfaccia di rete virtuale.
• L2CAP ACL data receive, problemi durante la ricezione di pacchetti
ACL quali inizio frame inatteso, continuazione di frame non attesa.
• HCI ACL data packet, problemi durante la ricezione e la
trasmissione di pacchetti ACL: impossibilità di riconoscere l’handle
di connessione; scadere del timeout in trasmissione, distruzione di
una connessione in stallo.
• BCSP, BlueCore Serial Protocol, presente nei dispositivi che usano
chipset Bluetooth non USB inclusi chipset built-in, PCMCIA e CF
cards; Si occupa del trasporto di pacchetti HCI tra il chipset ed il
sistema. Supporta anche controllo si errori e ritrasmissioni. Errori
riscontrati sono relativi alla ricezione di pacchetti fuori ordine,
troncati o in timeout.
105
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
• Jedec_probe, messaggi di errore relativi all’inizializzazione del
driver Linux di gestione delle memorie flash in sistemi Embedded.
Presenti nel solo Host Ipaq, non è chiaro se siano di interesse per
l’analisi.
• TO waiting hotplug event, errori manifestatisi nel solo Host
Capatamarano. Notificati dal demone HAL (Hardware Abstraction
Layer) che fornisce API per l’identificazione di hardware collegato
al sistema e per la raccolta di informazioni di stato dei dispositivi.
Non è chiaro se di interesse per l’analisi.
• audit(.) inizialized, anche in questo caso si tratta di messaggi di
errore che coinvolgono il solo Host Capatamarano. Prodotti dal
kernel di Linux non è chiaro se di interesse per l’analisi.
A valle di estrazione e filtraggio è stata infine realizzata la coalescenza dei
dati utilizzando le regole di tupling descritte nel paragrafo 2.4.
Per la scelta dei parametri di clustering è stato condotto uno studio
preliminare di sensibilità.
Data la differente natura dei dati di livello
sistema ed utente, rispettivamente eventi di errore e fallimento, i due casi
sono stati affrontati separatamente.
In figura 5.3 è mostrato l’andamento del numero di tuple di livello sistema
in funzione del clustering time.
106
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Figura 5.3 Numero di tuple di sistema in funzione del clustering time
Osservando il grafico, è interessante notare come la curva presenti la
caratteristica forma ad “L” descritta nel capitolo secondo.
La tupla,
verosimilmente, rappresenta il risultato diretto di un guasto nel sistema;
tale guasto genera, in condizioni normali, un pattern di errori che sono
raggruppati in un lasso di tempo breve rispetto all’intero log. Per tale
ragione è presente una elevata sensibilità al clustering time per valori
inferiori ai 7 secondi mentre l’andamento diventa praticamente piatto per
valori superiori. Un simile andamento motiva la scelta di un clustering
time superiore ai 7 secondi; in particolare tale scelta è ricaduta su una
finestra di 10 secondi, anche se va sottolineato che un qualsiasi valore
superiore, purché non eccessivo, avrebbe prodotto risultati equivalenti. Per
107
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
lo stesso motivo è ragionevole assumere trascurabile la probabilità di
collisione.
Con tale scelta si è ottenuta una compressione del numero di entries di un
fattore superiore al 95% per l’intero dataset e superiore al 75%
relativamente al periodo di interesse.
Un discorso differente riguarda invece la scelta di un tempo di clustering
adatto alle tuple di livello utente, una prima osservazione dell’andamento
del numero di tuple con il clustering time riportato in figura 5.4 evidenzia
una dipendenza più complessa.
Figura 5.4 Numero di tuple d’utente in funzione del clustering time
108
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
In questo caso l’andamento del numero di tuple con il clustering time non è
netto come nel caso precedente: occorre maggiore cautela nella scelta di
una finestra temporale appropriata; in casi come questo può essere d’aiuto
guardare l’andamento della derivata mostrato in figura 5.5.
Figura 5.5 Derivata del numero di tuple d’utente in funzione del clustering time
Dalla caratteristica appare evidente che esiste un picco nella sensibilità al
clustering time intorno ai 330 secondi dopo di che questa crolla
rapidamente.
E’ ragionevole ritenere che una elevata sensibilità al
clustering time si abbia per valori prossimi al tempo tipico di interarrivo tra
eventi correlati, tale valore, verosimilmente, costituisce quindi la migliore
rappresentazione del tempo di clustering per i dati di sistema. Per evitare
di commettere errori nella scelta del clustering time, rischiando quindi di
pregiudicare l’analisi, si procede alla valutazione della corrispondente
probabilità di collisione.
109
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
La probabilità che una tupla sia affetta da collisione può essere calcolata
assumendo che nel sistema siano presenti un gran numero di processi
indipendenti di guasto.
Il log di sistema è dunque l’effetto di una
sovrapposizione di eventi generati da tali processi.
Sotto l’ipotesi di infiniti processi componenti, il processo ottenuto come
sovrapposizione dei singoli processi è Poisson. Segue che il Time Between
Event (BTE) possiede una distribuzione esponenziale di parametro pari al
tasso di fault del sistema λF .
Poiché tale parametro non può essere
direttamente misurato, si ricorre al tuple rate λT in qualità di stima.
Sebbene il tuple rate sia dipendente dal tempo di clustering va comunque
considerato che tale dipendenza è poco marcata in corrispondenza di valori
del clustering time superiori al valore critico individuato [11]. Per tale
ragione nel calcolo della probabilità di collisione si assume che il fault rate
λF sia ben rappresentato dal tuple rate λT .
λF
λT
(5.1)
Sia allora X ∼ Exp ( λF ) la variabile aleatoria per il tempo di interarrivo del
fault process. Una prima approssimazione della probabilità di collisione si
ottiene semplicemente calcolando la probabilità che l’interarrivo tra due
guasti sia minore del clustering time ε :
Pc
Pr [ X < ε ] = 1 − e
λf ε
(5.2)
110
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Questo modello può produrre però una stima eccessivamente ottimistica,
perché, contemplando unicamente tuple di lunghezza nulla, considera una
finestra di collisione minore della realtà.
Figura 5.6
Per un modello più realistico si considera l’introduzione di una seconda
variabile aleatoria L che rappresenta la lunghezza della tupla. In questo
caso una collisione si verifica qualora il tempo trascorso tra la fine di una
tupla e l’inizio della successiva è minore del clustering time. Si definisce a
tale scopo la variabile aleatoria Z = X − L (cfr. figura 5.6) che rappresenta
tale intervallo.
Pc = Pr [ Z < ε ] = Fz ( ε ) = ∫
ε
−∞
f z ( t ) dt
(5.3)
Dove la probability density function (pdf) di Z è data dalla relazione:
fz (t ) = ∫
∞
−∞
f X ( t + τ ) f L (τ ) dτ
(5.4)
Resta da chiarire quale distribuzione usare per la lunghezza delle tuple. La
scelta migliore consiste nell’utilizzare la distribuzione campionaria
111
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
stimabile dal prodotto della coalescenza stessa. In figura 5.7 è mostrata la
distribuzione campionaria relativa alle tuple di livello utente.
Come atteso è elevata la probabilità di avere tuple di lunghezza zero, ossia
costituite da un unico elemento, mentre la probabilità diventa trascurabile
( < 3 ⋅10−3 ) per valori superiori ai 300 secondi.
Figura 5.7 Distribuzione campionaria della lunghezza delle tuple
Concludendo dunque:
f L (τ )
∑ p δ (τ − l )
j
j
Sostituendo nella 1.4 :
j
(5.5)
112
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
f Z (τ ) = ∫
∞
−∞
= ∑ p j λF e
∑ p δ (τ − l ) ⋅ λ
j
j
F
e − λF ( t +τ )u ( t + τ ) dt =
j
(
− λF τ + l j
)
j
(5.6)
u (τ + l j )
Integrando :
FZ ( t ) = ∫
t
−∞
= ∑ pj ⋅ ∫
j
f Z (τ ) dτ
=
∑ p j ⋅∫ λ F e
t
−∞
j
t +l j
−∞
λF e − λ i u ( i ) di
∑ p ⋅∫
=
F
j
j
= ∑ p j ⋅ ⎡⎣ −e − λF i ⎤⎦
j
t +l j
0
= 1 − e − λF t ⋅ ∑ p j e
=
(
− λF τ + l j
∑p
j
t +l j
0
⋅(1 − e − λF t e
)
i =τ + l j
u (τ + l j ) dτ =
λF e− λ i di =
F
(5.7)
− λF l j
)=
j
− λF l j
j
Concludendo l’equazione 1.3 diventa:
⎛
−λ l ⎞
Pc = Pr [ Z < ε ] = 1 − e − λF ε ⎜ ∑ p j e F j ⎟
⎝ j
⎠
(5.8)
Dal confronto tra le espressioni (5.2) e (5.8) si osserva che differiscono
unicamente per la presenza del termine di sommatoria che rappresenta la
distribuzione della lunghezza delle tuple.
Risolvendo la (5.8) sostituendo il fault rate ideale con il tuple rate stimato
dai dati, si ottengono, per un clustering time di 330 secondi, le probabilità
di collisione riportate in tabella 5.2. Le probabilità di collisione osservate
sono piuttosto modeste, confermando la validità di tale scelta. In figura 5.8
113
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
è infine tracciato l’andamento della probabilità di collisione in funzione del
clustering time.
Host
Misero
Azzurro
Verde
Capatamarano
Ipaq
Zaurus
Windows
λF
10.9 / day
31.62 / day
9.8 / day
14.42 / day
26.98 / day
7.40 / day
3.60 / day
Pc
0.0318
0.0893
0.0286
0.0418
0.0768
0.0217
0.0106
Tabella 5.2 Probabilità di collisione delle tuple d’utente
Figura 5.8 Andamento della probabilità di collisione con il tempo di clustering
114
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Adoperando per i dati di livello sistema un clustering time di 330 secondi si
è ottenuta una compressione del numero di entries del 35% circa per
l’intero dataset e del 10% relativamente al periodo di interesse.
Senza
Coalescenza
Con
Coalescenza
Rapporto di
compressione
intero dataset
a valle del filtraggio
867694 tuple
258748 tuple
24005 tuple
64156 tuple
95%
75%
intero dataset
a valle del filtraggio
25698 tuple
6026 tuple
16737 tuple
5481 tuple
65%
35%
Dati di livello Sistema:
Dati di livello utente:
Tabella 5.3 Probabilità di collisione delle tuple d’utente
5.3.4
Analisi preliminare dei comportamenti di sistema
Come discusso nel paragrafo 5.2, è importante condurre un’analisi
preliminare che fornisca un primo livello di comprensione dei
comportamenti del sistema.
In questa fase si vogliono esplorare le dinamiche di fallimento sui singoli
Host descrivendone il comportamento statistico.
Obiettivo dell’analisi: descrivere le dinamiche di fallimento.
Dati in ingresso: tuple e vettori di time between tuple.
Prodotti: statistiche univariate, distribuzioni, tabelle di contingenza.
Strumenti: supporto del tool analyst fornito da SAS, probability plots, test
statistici di goodness of fit.
115
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
La distribuzione dei fallimenti nel sistema costituisce una prima
interessante informazione.
Figura 5.9 Distribuzione dei fallimenti nel sistema
Dall’osservazione di figura 5.9 si evidenzia una maggiore occorrenza di
fallimenti relativi alla comunicazione sul canale (Receive Time Out,
Connection Faiulure) e nella determinazione dei ruoli all’interno della
piconet (Switch Role Failure), mentre appaiono di minore rilevanza
fallimenti relativi alla scoperta dei servizi (SDP Search Failure).
La
rilevanza di una tipologia di fallimento rispetto alle altre varia però
sensibilmente all’interno di ciascun Host:
Distribuzione dei fallimenti : Azzurro
116
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Distribuzione dei fallimenti : Capatamarano
Distribuzione dei fallimenti : Verde
Distribuzione dei fallimenti : Miseno
117
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Distribuzione dei fallimenti : Ipaq
Distribuzione dei fallimenti : Zaurus
Distribuzione dei fallimenti : Windows
E’ interessante osservare come una maggiore incidenza di fallimenti
relativi alla determinazione dei ruoli caratterizzi il comportamento dei
118
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
dispositivi mobili (Ipaq, Zaurus) rispetto agli Hosts fissi. L’Host Windows
sembra infine non soffrire di tale problematica, anche se va considerato che
il volume di dati non è adeguato a trarre conclusioni significative.
Naturalmente è interessante anche caratterizzare la distribuzione temporale
dei fallimenti. In tabella 5.4 sono riportate le statistiche sintetiche dei time
between failure; l’assunzione che si è fatta è che questo sia rappresentato in
maniera adeguata dal time between tuple;
Media
σ
N
Min
Max
Mediana
Azzurro
2732
4634
1005
202
82058
1278
Capatamarano
5992
11441
519
215
130422
2210
Verde
8779
15176
723
206
115082
2837
Miseno
7902
16110
1008
202
151855
2417
Ipaq
3202
8928
1573
201
146977
1267
Zaurus
11669
21779
498
208
144315
3056
Win
23985
30000
107
308
153537
9032
Grouped
1826
4209
5474
314
80580
645
Tabella 5.4 Statistiche sintetiche dei time between failure
Con l’ausilio di probability plots si è inoltre ipotizzato che la distribuzione
dei time between failure segua una legge lognormale.
119
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Una variabile X è distribuita secondo legge lognormale se Y = ln ( X ) segue
una distribuzione normale (gaussiana). La formula generale per la densità
di probabilità (pdf) di una distribuzione lognormale è la seguente:
−
( ln ( x −θ ) / m )2
2
2σ
e
f ( x) =
( x − θ ) σ 2π
x ≥ 0 ; m, σ > 0
(5.9)
dove σ è il fattore di forma, θ è il parametro di localizzazione ed m è il
parametro di scala. Per la stima dei parametri SAS adotta un approccio a
massima verosimiglianza, per i parametri di scala e forma si ha
rispettivamente:
mˆ = exp μˆ
(5.10)
e
∑ ( ln ( X ) − μˆ )
N
σˆ =
i
i =1
N
2
(5.11)
dove
∑
μˆ =
N
i =1
ln X i
N
(5.12)
Il parametro di locazione si estrae direttamente dai dati e può essere
sottratto dai data points originali prima della stima a massima
verosimiglianza dei parametri di forma e scala.
A supporto di tale ipotesi sono stati eseguiti anche dei tests di goodness of
fit. L’intento è di determinare se esistono prove sufficienti per scartare tale
ipotesi.
120
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
SAS applica tre diversi test statistici:
• Kolmogorov-Smirnov Goodness of fit Test, basato sul calcolo della
funzione cumulativa di distribuzione empirica (ECDF).
Il test
calcola la massima distanza di questa curva rispetto la CDF canonica
della distribuzione. L’ipotesi è rigettata se tale distanza supera un
valore critico ottenibile attraverso opportune tabelle.
• Anderson-Darling Test, è una versione modificata del test di
Kolmogorov-Smirnov che assegna un peso maggiore alle code della
distribuzione. Il test K-S è un test distribution free nel senso che i
valori critici sono indipendenti dalla specifica distribuzione che
viene testata.
A-D utilizza valori critici specifici per ciascuna
distribuzione. Questo rappresenta un vantaggio in quanto fornisce al
test una maggiore sensibilità, uno svantaggio perché lo rende meno
robusto rispetto all’ipotesi.
• Cramer-von Mises Test, è anch’esso basato sulla ECDF ma il
calcolo della distanza è differente rispetto ai casi precedenti.
Tali tests forniscono inoltre una misura quantitativa del grado di fiducia
associato al risultato, sono difatti progettati in modo da garantire che il
rischio di rigettare l’ipotesi, nel caso sia vera, sia trascurabile.
In
particolare SAS indica la probabilità che la distanza calcolata dal test superi
il valore critico.
121
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Nelle figure che seguono sono rappresentati per ciascun Host: una stima dei
parametri della distribuzione, la distribuzione campionaria dei quantili
rispetto ad una distribuzione lognormale, gli indici di goodness of fit.
Distribuzione dei fallimenti : Azzurro
122
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Distribuzione dei fallimenti : Capatamarano
123
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Distribuzione dei fallimenti : Verde
124
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Distribuzione dei fallimenti : Miseno
125
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Distribuzione dei fallimenti : Windows
In tutti i casi si evidenzia una perdita una perdita di aderenza al modello al
crescere dei valori del TBF . Non si tratta di una condizione preoccupante,
come del resto suggeriscono i risultati dei test; verosimilmente è legata ad
una non corretta individuazione dei periodi di inattività del testbed o di
Capitolo V :
126
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
gestione degli outliers. Si osserva che l’ipotesi di distribuzione lognormale
è realistica per gli Host Azzurro, Capatamarano, Verde, Miseno. Non del
tutto soddisfacente per Windows: a discapito dei risultati positivi del test, è
evidente, comunque, che l’assenza di un numero statisticamente sufficiente
di campioni non consente una caratterizzazione credibile.
Diverso è il caso dei dispositivi mobili. Per Ipaq il modello statistico più
adeguato a rappresentare il time between failure è un modello esponenziale,
fra l’altro confortato dagli ottimi risultati dei test. Identificare il modello di
TBF in Zaurus invece è stato complesso. Se da una parte i test di goodness
of fit sconfessano la possibilità di un modello lognormale, il modello
esponenziale, benché maggiormente probabile, non appare del tutto
soddisfacente.
127
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Distribuzione dei fallimenti : Ipaq
128
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Distribuzione dei fallimenti : Zaurus
129
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
5.3.5
Correlazione tra le dinamiche di fallimento nei diversi
Host
Durante lo studio di sensibilità per la coalescenza dei dati si sono
osservate alcune interessanti relazioni tra le dinamiche di fallimento dei
differenti Hosts: sembra plausibile infatti che i fallimenti tendano a
verificarsi in maniera più o meno contemporanea sui diversi Hosts. In
questa fase del processo di analisi si cerca di approfondire tale aspetto,
cercando di fornire anche una interpretazione del fenomeno.
Obiettivo dell’analisi: esplorare le relazioni esistenti tra le dinamiche di
fallimento dei vari Hosts.
Dati in ingresso: tuple multihost di livello utente. Dati di livello sistema
del NAP.
Prodotti: tabelle di contingenza, cross tabulazioni.
Strumenti: correspondence analysis, cluster analysis realizzate attraverso
il linguaggio di scripting disponibile in SAS.
Per condurre questa analisi si realizzata una nuova coalescenza dei dati che
non prevedesse tuple specifiche per i singoli Host, in questo modo
fallimenti che si verificano si macchine differenti possono essere associati
se verosimilmente manifestazione del medesimo problema.
130
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Le curve mostrate in figura 5.10 sono state realizzate graficando
l’andamento del numero di tuple in funzione del clustering time, accettando
o meno la possibilità che le tuple possano contenere eventi di Host
differenti.
Figura 5.10 Andamento del numero di tuple come funzione del clustering time
Risulta una evidente differenza tra la curva ottenuta tuplando unicamente
entries relative ai singoli Hosts e quella ottenuta prescindendo dalla
localizzazione dell’evento.
Tale differenza, rappresentata in figura 5.11,
indica chiaramente l’esistenza di un elevata capacità di raggruppamento nei
primi 200 secondi di clustering time, oltre le due curve tendono invece ad
avvicinarsi. Un simile comportamento non è statisticamente credibile
131
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
sotto l’ipotesi che fallimenti nelle singole macchine siano indipendenti: se
tale ipotesi fosse verificata, sarebbe infatti atteso una andamento della
differenza tra le curve che cresce indefinitamente al crescere della
probabilità di collisione e dunque con il tempo di clustering.
Figura 5.11
Tale comportamento sembra invece avvalorare l’ipotesi dell’esistenza di
una forte correlazione tra fallimenti nei diversi Host.
Come tempo di clustering si è scelta una finestra di 200 secondi in accordo
alle considerazioni derivanti dal grafico di figura 5.11. In figura 5.12 si
osserva che la percentuale di fallimenti che si verificano in concomitanza
su più Host non è assolutamente trascurabile.
Figura 5.12
132
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Le percentuali osservate sono chiaramente indicative del fatto che una
buona parte dei fallimenti tendono a manifestarsi in maniera concomitante
in più di un Host.
Questo suggerisce la possibilità che alla base sia
presente un guasto in una risorsa comune.
Due sono quindi le cause
possibili:
1. Presenza di un fuori servizio nel Network Access Point.
2. Presenza di un guasto sul canale.
Incrociando le tuple di fallimenti multihost con le tuple riportanti errori di
livello sistema sul NAP (Giallo), si osserva che circa in un caso su quattro
tali fallimenti sono ricollegabili ad un disservizio del NAP.
Figura 5.13
Vale la pena di approfondire alcuni aspetti di tale fenomeno ed in
particolare:
1. presenza del fenomeno nei singoli Host;
2. numero di Hosts mediamente coinvolti;
3. legame tra errori di sistema sul NAP e fallimenti multipli.
133
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
1. In tabella 5.4 sono riportate le caratteristiche dei fallimenti per i singoli
host.
Fallimento
Host
Singolo
Multihost dei quali responsabilità
di un disservizio nel NAP
Responsabilità
complessiva di un
disservizio nel NAP
Azzurro
48%
52%
15%
9%
Capatamarano
76%
24%
14%
4%
Verde
55%
45%
19%
9%
Miseno
46%
53%
16%
10%
Ipaq
67%
31%
15%
7%
Zaurus
35%
63%
20%
15%
Windows
72%
28%
13%
4%
Tabella 5.4
2. In figura 5.14 sono riportate le percentuali di fallimenti multihost in
relazione al numero di macchine coinvolte.
E’ bene ricordare che Capatamarano ha sostituito Azzurro nel testbed,
dunque le due macchine non sono state contemporaneamente presenti e
che Windows è stato aggiunto al testbed solo in un secondo momento.
Figura 5.14
134
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
3. In accordo alla classificazione realizzata nel paragrafo 5.4.2 si
osservano le dipendenze mostrate in tabella 5.5. Sono indicati il tipo di
errore di sistema, la percentuale di occorrenza sul NAP, il numero di
host coinvolti nella propagazione dell’errore.
Errore
Occorrenza
0 Host
1 Host
2 Host
3 Host
4 Host
Packet Mismatch
30%
71%
16%
8%
1%
4%
Pan Connection
5%
43%
29%
7%
7%
14%
L2CAP ACL
33%
9%
37%
13%
13%
25%
4%
HCI ACL
14%
5%
23%
23%
38%
13%
USB Device
18%
16%
22%
20%
28%
6%
8%
5 Host
Tabella 5.5
E’ particolarmente interessante osservare come alcune tipologie di errore
tendano a provocare sistematicamente fallimenti multipli sugli Host client.
Come discusso nel paragrafo 5.4.2, L2CAP ACL e HCI ACL si riscontrano
sul NAP in presenza di errori nella ricezione dei pacchetti: in una tale
situazione il NAP verosimilmente ha perso il sincronismo di trama e non è
più in grado di ricostruire la corretta sequenza dei pacchetti o la loro
provenienza, segue che fino al ristabilimento di una condizione di
normalità non può rispondere correttamente alle richieste di servizio degli
Host provocandone il fallimento. Similmente se si verificano problemi con
il driver USB o con il dispositivo Bluetooth stesso il NAP non solo è in una
condizione di fuori servizio, ma probabilmente non riesce neppure ad
adempiere al ruolo di master della piconet.
Diverso è il caso dei Packet Mismatch, in questo caso il NAP prende
semplicemente atto della ricezione di un pacchetto corrotto verosimilmente
135
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
a causa di una elevata interferenza sul canale; per come è simulata
l’interazione il server risponde comunque al client che quindi potrebbe o
meno risentire del problema in relazione al tipo di interferenza: se a banda
stretta allora il pacchetto di risposta ne è immune per via del frequency
hopping, analogamente se legata ad una collisione casuale con le
trasmissioni di un altro sistema overlay, se a banda larga invece
verosimilmente anche il pacchetto di risposta ne è affetto provocando un
fallimento sull’Host client.
Infine PAN Connection sembra essere un errore o una instabilità interna al
NAP di natura non ancora sufficientemente esplorata, provoca un
fallimento multiplo nel 60% dei casi circa.
Concludendo resta comunque un 34% di fallimenti multipli che non
trovano una spiegazione nel comportamento del NAP.
Si pensa siano
problemi legati a livelli di interferenza sulla rete tali che è il livello
baseband dello stack Bluetooth a scartare le trasmissioni non intelligibili.
Trattandosi di funzionalità implementate dall’hardware dei dispositivi
Bluetooth tali problematiche non sono riportate nei log di sistema.
136
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
5.3.6
Legame tra errori di livello sistema e fallimenti, analisi dei
fenomeni di propagazione
L’ultimo obiettivo di analisi riguarda l’esplorazione dei legami
esistenti tra errori verificatisi a livello di sistema e fallimenti di livello
applicativo. In particolare è di interesse stabilire se esistono fenomeni di
propagazione e cercare di ricostruire la dinamica che porta al fallimento.
Un ulteriore aspetto da approfondire è l’impatto dell’uso di servizi
Bluetooth sulla stabilità del software di sistema.
Obiettivo dell’analisi: Esplorare legami tra i dati di sistema e d’utente:
identificare eventuali fenomeni di propagazione, valutare l’impatto dei
fallimenti sulla stabilità dell’architettura.
Dati in ingresso: tuple multilivello.
Prodotti: tabelle di contingenza, cross tabulazioni.
Strumenti: correspondence analysis, cluster analysis realizzate attraverso
il linguaggio di scripting disponibile in SAS.
137
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Come punto di partenza dell’analisi si è realizzata una prima introspezione
dei dati attraverso l’osservazione di informazioni di contingenza.
Figura 5.15
La distribuzione degli errori nel sistema, rappresentata in figura 5.15,
mostra una elevata concentrazione di bcsp errors, che come discusso nel
paragrafo 5.3.3 sono tipici unicamente dei dispositivi palmari.
Ciò
suggerisce che tale rappresentazione possa essere fortemente polarizzata e
non sufficientemente significativa. La rilevanza di una tipologia di errore
rispetto alle altre difatti varia sensibilmente all’interno di ciascun Host:
Errori di livello sistema : Capatamarano
138
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Errori di livello sistema : Verde
Errori di livello sistema : Miseno
Errori di livello sistema : Ipaq
139
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Errori di livello sistema : Zaurus
E’ utile osservare che la problematica maggiormente ricorrente è relativa ai
servizi offerti dalla host controller interface (HCI), punto di contatto tra il
livello baseband (implementato dal firmware dei dispositivi) ed il sistema.
Un problema del tutto assimilabile si verifica nei dispositivi palmari, dove
il trasporto dei pacchetti HCI avviene attraverso la mediazione del
BlueCore serial protocol (BCSP). Anche timeout waiting hotplug event,
legato ad un problema di comunicazione tra sistema e dispositivo,
sembrerebbe affine a tale problematica, anche se in questo caso è richiesta
una maggiore cautela nel trarre conclusioni. Naturalmente esistono delle
eccezioni, nel caso di Miseno la problematica maggiormente sentita sembra
essere relativa alla instaurazione di un canale PAN, si riscontra infatti una
elevata occorrenza di errori nella ricerca del servizio e durante l’uso, con
tentativi di accesso all’interfaccia di rete virtuale falliti.
Per quanto riguarda l’analisi delle relazioni tra errori di livello sistema e
dinamica di fallimento si è prodotto un nuovo insieme di dati ottenuto
incrociando le tuple di livello utente con le tuple di livello sistema per
ciascun Host. In questo modo errori e fallimenti sono messi in diretta
corrispondenza rendendo possibile investigare eventuali relazioni esistenti.
140
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Risultati dell’analisi hanno mostrato che solo nel 32% dei casi si può
pensare di assegnare al sistema la responsabilità del fallimento.
In
particolare queste sono distribuite come da figura 5.16.
Figura 5.16
bcsp
hci
SDP
bnep
hotplug
Jedec
l2cap
Sul totale dei
fallimenti
21%
50%
7%
8%
12%
1%
<1%
ROLE
53%
12%
9%
21%
2%
3%
<1%
RECV
35%
24%
1%
17%
19%
1%
3%
CONNECT
5%
81%
13%
<1%
61%
BIND
SDP
22%
22%
1%
39%
56%
Tabella 5.6
In tabella 5.6 sono rappresentati i legami verosimilmente esistenti tra
fallimenti ed errori di sistema. Legami abbastanza forti sembrano esistere
invece tra fallimenti riscontrati durante le fasi di binding dell’interfaccia di
rete virtuale ed errori nel livello di interfacciamento del sistema con il
firmware del dispositivo Bluetooth.
141
Capitolo V :
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
Un ulteriore aspetto interessante è relativo a fallimenti verificatisi durante
l’instaurazione della connessione: nel 72% dei casi la responsabilità è
chiaramente imputabile ad un errore nel sistema, nello specifico nell’ 86%
dei casi si tratta di un problema di comunicazione con il dispositivo mentre
nel 13% il problema è legato all’impossibilità di individuare il servizio.
Discorso analogo per fallimenti durante le fasi di scoperta del servizio, in
questo caso la responsabilità del sistema è legata nel 44% dei casi ad un
problema di comunicazione con il dispositivo, mentre nel 56% il problema
risiede nell’uso del SDP stesso.
5.3
Conclusione e sviluppi futuri
L’applicazione al caso di studio della metodologia sviluppata ha
effettivamente evidenziato la presenza di numerose problematiche che se
non affrontate in maniera consapevole avrebbero potuto compromettere i
risultati dell’analisi. Aspetti cruciali sono relativi la scelta, la valutazione
ed il trattamento dell’insieme di dati. Particolare cura deve essere spesa
nell’individuare difetti o limitazioni presenti nel processo di collezione e
nel formato dei dati: si tratta di un aspetto irrinunciabile per acquisire una
maggiore coscienza di ciò che si potrà ottenere dalle analisi, chiarirne gli
obiettivi e naturalmente evitare di pregiudicarne i risultati.
Lo studio ha inoltre portato alla luce alcune potenzialità precedentemente
inesplorate del meccanismo di tupling quale la possibilità di applicazione a
scenari di analisi diversi dalla semplice riduzione e coalescenza dei dati. In
Capitolo V :
142
Presentazione di un caso studio: Selezione ed Analisi dei dati ________________
particolare tale meccanismo è stato applicato con successo nell’analisi delle
dipendenze esistenti tra gruppi di dati: il legame tra i fallimenti degli hosts
della rete o tra dati di livello sistema e livello utente.
Futuri sviluppi vedono il perfezionamento della metodologia e degli
strumenti di analisi realizzati grazie all’applicazione a nuovi insiemi di dati
diversi per tipologia e contesto applicativo quali i dati di fallimento della
Java Virtual Machine o delle Wireless Sensor Network.
Bibliografia
[1]
Surviving in a fast, nomadic world [mobile computing and communication]
Kleinrock, L.;
Information Theory, 1998. Proceedings. 1998 IEEE International Symposium on
16-21 Aug. 1998 Page(s):4
[2]
A ubiquitous computing environment for aircraft maintenance
Lampe M.; Strassner M.; Fleisch E.
2004 ACM Symposium on Applied Computing Proceedings,
14-17 March 2004 Page(s): 1586–1592,
[3]
Adtranz: a mobile computing system for maintenance and collaboration
Siewiorek, D.; Smailagic, A.; Bass, L.; Siegel, J.; Martin, R.; Bennington, B.;
Wearable Computers, 1998. Digest of Papers. Second International Symposium on
19-20 Oct. 1998 Page(s):25 – 32
[4]
Developing next-generation distributed applications with QoS enabled DPE
middleware
Schmidt, D.C.; Kachroo, V.; Krishnamurthy, Y.; Kuhns, F.;
Communications Magazine, IEEE
Volume 38, Issue 10, Oct. 2000 Page(s):112 – 123
[5]
Spatial and context awareness for mobile learning in a museum
Beale R.; Sharples M.; Baber C.; Lonsdale P.; Byrne W.;
KAL CSCL Workshop on ’Spatial Awareness and Collaboration’, Proceedings.
Bibilografia
144
____________________________________________________________
[6]
Architectures for ubiquitous environments
Salvador, Z.; Jimeno, T.; Lafuente, A.; Larrea, M.; Abascal, J.;
Wireless And Mobile Computing, Networking And Communications, 2005.
(WiMob'2005), IEEE International Conference on
Volume 4, Aug. 22-24, 2005 Page(s):90 – 97
[7]
Applications of context aware computing in hospital work : examples and
design principles
Bardram J.E.;
2004 ACM Symposium on Applied Computing Proceedings
14-17 March 2004 Page(s) 1574–1579
[8]
Application of mobile phone in medical image transmission
Abdul Aziz A.; Besar R.;
4’ National Conference on Telecommunication Technology Proceedings, Shah
Alam, Malaysia, 2003, pages 80–83
[9]
Basic concepts and taxonomy of dependable and secure computing
Avizienis, A.; Laprie, J.-C.; Randell, B.; Landwehr, C.;
Dependable and Secure Computing, IEEE Transactions on
Volume 1, Issue 1, Jan 2004 Page(s):11 – 33
[10]
Measurement-based Analysis of Networked System Availability
Iyer, R. K.; Kalbarczyk Z.; Kalyanakrishnan M.;
Lecture Notes In Computer Science; Vol. 1769 archive Performance Evaluation
Publisher Springer-Verlag London, UK 2000
Page(s): 161 – 199
[11]
Models for time coalescence in event logs
Hansen, J.P.; Siewiorek, D.P.;
Fault-Tolerant Computing, 1992. FTCS-22. Digest of Papers., Twenty-Second
International Symposium on
8-10 July 1992 Page(s):221 – 227
Bibilografia
145
____________________________________________________________
[12]
A comparative analysis of event tupling schemes
Buckley, M.F.; Siewiorek, D.P.;
Fault Tolerant Computing, 1996., Proceedings of Annual Symposium on
25-27 June 1996 Page(s):294 – 303
[13]
Analysis and modeling of correlated failures in multicomputer systems
Tang, D.; Iyer, R.K.;
Computers, IEEE Transactions on
Volume 41, Issue 5, May 1992 Page(s):567 - 577
[14]
Error/failure analysis using event logs from fault tolerant systems
Lee, I.; Iyer, R.K.; Tang, D.;
Fault-Tolerant Computing, 1991. FTCS-21. Digest of Papers., Twenty-First
International Symposium
25-27 June 1991 Page(s):10 – 17
[15]
Coalescent theory
Nordborg, M.;
In Handbook of Statistical Genetics, John Wiley & Sons, Chichester, England 2001
Chapter 7.
[16]
Measurement and modeling of computer reliability as affected by system
activity
Iyer R. K.; Rossetti D. J.; Hsueh M. C.;
August 1986 ACM Transactions on Computer Systems (TOCS), Volume 4 Issue 3
[17]
Dependability measurement and modeling of a multicomputer system
Tang, D.; Iyer, R.K.;
Computers, IEEE Transactions on
Volume 42, Issue 1, Jan. 1993 Page(s):62 – 75
[18]
A weighted distribution of residual failure data using Weibull model
Soo-Jong Lee; Kyeong-Ho Lee;
Information Networking, 2001. Proceedings. 15th International Conference on
31 Jan.-2 Feb. 2001 Page(s):265 - 270
Bibilografia
146
____________________________________________________________
[19]
Failure data analysis by models involving 3 Weibull distributions
Tieling Zhang; Ren, Y.;
Reliability and Maintainability Symposium, 2002. Proceedings. Annual
28-31 Jan. 2002 Page(s):44 - 50
[20]
Workload, performance, and reliability of digital computing systems
Castillo, X.; Siewiorek, D.P.;
Fault-Tolerant Computing, 1995, ' Highlights from Twenty-Five Years'.,
Twenty-Fifth International Symposium on
June 27-30 1995 Page(s):367
[21]
Effect of System Workload on Operating System Reliability
Iyer, R.K.; Rossetti, D.J.;
Software Engineering, IEEE Trans.
1985 Page(s):1438 - 1448
[22]
VAX/VMS event monitoring and analysis
Buckley, M.F.; Siewiorek, D.P.;
Fault-Tolerant Computing, 1995. FTCS-25. Digest of Papers., Twenty-Fifth
International Symposium on
27-30 June 1995 Page(s):414 - 423
[23]
Failure data analysis of a LAN of Windows NT based computers
Kalyanakrishnam, M.; Kalbarczyk, Z.; Iyer, R.;
Reliable Distributed Systems, 1999. Proceedings of the 18th IEEE Symposium on
19-22 Oct. 1999 Page(s):178 - 187
[24]
Networked Windows NT system field failure data analysis
Jun Xu; Kalbarczyk, Z.; Iyer, R.K.;
Dependable Computing, 1999. Proceedings. 1999 Pacific Rim International
Symposium on
16-17 Dec. 1999 Page(s):178 - 185
Bibilografia
147
____________________________________________________________
[25]
A case study of C.mmp, Cm*, and C.vmp: Part I—Experiences with fault
tolerance in multiprocessor systems
Siewiorek, D.P.; Kini, V.; Mashburn, H.; McConnel, S.; Tsao, M.;
Proceedings of the IEEE
Volume 66, Issue 10, Oct. 1978 Page(s):1178 - 1199
[26]
Filtering Failure Logs for a BlueGene/L Prototype
Yinglung Liang; Yanyong Zhang; Sivasubramaniam, A.; Sahoo, R.K.; Moreira, J.;
Gupta, M.;
Dependable Systems and Networks, 2005. DSN 2005. Proceedings. International
Conference on
28-01 June 2005 Page(s):476 - 485
[27]
Failure data analysis of a large-scale heterogeneous server environment
Sahoo, R.K.; Squillante, M.S.; Sivasubramaniam, A.; Yanyong Zhang;
Dependable Systems and Networks, 2004 International Conference on
28 June-1 July 2004 Page(s):772 - 781
[28]
Crash Data Collection: A Windows Case Study
Ganapathi, A.; Patterson, D.;
Dependable Systems and Networks, 2005. DSN 2005. Proceedings. International
Conference on
28-01 June 2005 Page(s):280 - 285
[29]
A paperless system of reporting and analyzing field failure data for IFTE ATS
Curry, P.A.; Hauer, C.C.; Jones, B.E.;
AUTOTESTCON '97. 1997 IEEE Autotestcon Proceedings
22-25 Sept. 1997 Page(s):13 – 17
[30]
Error log analysis: statistical modeling and heuristic trend analysis
Lin, T.-T.Y.; Siewiorek, D.P.;
Reliability, IEEE Transactions on
Volume 39, Issue 4, Oct. 1990 Page(s):419 - 432
Bibilografia
148
____________________________________________________________
[31]
Modification of: error log analysis: statistical modeling and heuristic trend
analysis
Ascher, H.E.; Lin, T.-T.Y.; Siewiorek, D.P.;
Reliability, IEEE Transactions on
Volume 41, Issue 4, Dec. 1992 Page(s):599 - 601, 607
[32]
Dati IDC 2004 resi noti da Belkin nel comunicato stampa del 29/10/2004
[33]
Bluetooth: ’last meter’ technology for nomadic wireless internetting
Gerla, M.; Johnssen, P.; Kapoor, R.; Vatalaro, F.;
Proceedings of the 12th Tyrrhenian International Workshop on Digital
Communications (TIWDC 20000)
September, 14-17 2000.
[34]
Bluetooth core specification v1.2
Bluetooth SIG.
https://www.bluetooth.org/spec/
November, 2003.
[35]
Bluetooth network encapsulation protocol (bnep) specification
Bluetooth SIG.
http://grouper.ieee.org/groups/802/15/Bluetooth/BNEP.pdf
June, 2001.
[36]
Personal area networking profile
Bluetooth SIG.
http://grouper.ieee.org/groups/802/15/Bluetooth/PAN-Profile.pdf
June, 2001.
[37]
An Automated Distributed Infrastructure for Collecting Bluetooth Field
Failure Data
Cinque, M.; Cornevilli, F.; Cotroneo, D.; Russo, S.;
Object-Oriented Real-Time Distributed Computing, 2005. ISORC 2005. Eighth
IEEE International Symposium on
18-20 May 2005 Page(s):329 - 336
Bibilografia
149
____________________________________________________________
[38]
Packet-level traffic measurements from the sprint ip backbone
Lyles, B.; Cotton, C.; Khan, M.; Moll, D.; Rockell, R.; Seely, T.; Diot, S.C.;
Fraleigh, C.; Moon, S.;
IEEE Network, 17:6–16, 2003.
[39]
Self-similarity in world wide web traffic: evidence and possible causes
Bestavros, A.; Crovella, M. E.;
Proc. of the 1996 ACM SIGMETRICS international conference on Measurement
and modeling of computer systems, 1996.
[40]
Effective fault treatment for improving the dependability of COTS and legacybased applications
Bondavalli, A.; Chiaradonna, S.; Cotroneo, D.; Romano, L.;
Dependable and Secure Computing, IEEE Transactions on
Volume 1, Issue 4, Oct-Dec 2004 Page(s):223 - 237
[41]
Analysis of workload influence on dependability
Meyer, J.F.; Wei, L.;
Fault-Tolerant Computing, 1988. FTCS-18, Digest of Papers., Eighteenth
International Symposium on
27-30 June 1988 Page(s):84 - 89