Sistemi diagnostici integrati e distribuiti

  1-12 
 
Pag. 12 
 
esperienza ,che ha portato anche alla realizzazione di un applicativo software, è nato 
l’interesse e la necessità di comprendere più a fondo questo tipo di realtà. Non 
essendoci (o in caso contrario, solo in forma troppo specialistica e dettagliata) una 
letteratura adeguata e onnicomprensiva a riguardo, si è pensato di effettuare uno studio 
dello stato d’arte in proposito  all’argomento che fosse il più completo possibile. Una 
delle maggiori difficoltà è stata quindi quella di reperire, classificare e integrare in un 
unica tesi tutte le informazioni  attinenti l’argomento in modo da fornire una guida unica 
e il più possibile generale di approccio alla realtà dei sistemi integrati di diagnostica in 
ambienti distribuiti ed eterogenei. 
 
1.3 Parole Chiave 
Di seguito un elenco delle parole chiave rappresentanti dei contenuti chiave della tesi: 
 
Management Distribuito, Management Integrato, Total Management, Monitoring, 
Diagnostica, Manageability, Modello informativo, Modello di comunicazione, Modello 
funzionale, Modello organizzativo 
 
 
SNMP, SMI(MIB), SMIng, NETCONF, WBEM, CIM,DEN, DMI,Storage Mgmt,  
TNM,CMIP,  CMIS, Corba, Uml, WMI, WBEM, COPS,  Aglets, µ-Code, Mole,WSDM, 
WSMAN, SNIA, OMG, DMTF, FIPA, ITU, ISO, MASIF, CIM, DEN, SMI, SMIng, 
MIBs, PIBs, Java, JMX, Jini, Jiro, J2EE, ARM 
 
Availability Management, Capacity Management, Incident and Problem Management, 
Change Management, Performance Management, Security Management, Policy-based 
Management, Web-based Management , Web Services (WS)  - Management, Intelligent 
Mobile Agents & Management 
  
Enterprise Management Suites (EMS), Microsoft System Management Server (SMS), 
IBM: Tivoli,HP: Open View & Mercury, LanDesk Management Suite, Nagios 
  
Agent Based Management Frameworks, SOMA, JAMES, IMA & IMA MC, AMETAS, 
CAPNET 
  
Ingegneria del Software dei Sistemi di Diagnostica, Mobility Design Patterns, 
Emergency Plan 
 
  2-13 
 
Pag. 13 
 
2. Introduzione alla 
diagnostica distribuita 
 
2.1 Che cosa si intende per Management 
Distribuito 
I sistemi di diagnostica/management distribuiti sono necessari in prima istanza per 
controllare e ottimizzare la rete e i servizi che vengono esposti attraverso di essa. 
Spesso si è soliti pensare che questa attività faccia riferimento solo a ambiti specifici e sia 
finalizzata solo a scopi ben determinati. La realtà dei fatti dimostra però che è oramai 
necessario agire a più livelli dell’ICT (Information and Communication Technology) 
fornendo supporto adeguato sia a basso livello ( per gli elementi di rete per esempio ) 
che a livello più alto ( business level ) per dare indicazioni più precise al fine di potere 
fornire strumenti per ragionare sugli obiettivi che si vogliono raggiungere e a “cascata” 
poi ottenere dei risultati. Naturalmente per fare questo sarà necessaria l’integrazione di 
componenti distribuite e vi sarà la necessità di capire come comunicare le informazioni, 
in che modo organizzare la struttura, decidere ruoli e responsabilità, ecc. 
L’immagine seguente (che verrà ripresa in seguito) da una indicazione approssimativa di 
quanto detto. 
 
 
  2-14 
 
Pag. 14 
 
 
FIGURA 1:  LIVELLI ICT (INFORMATION AND COMMUNICATION TECHNOLOGY)  DELLA 
DIAGNOSTICA 
 
Possiamo inoltre dire che la gestione del sistema dal punto di vista della diagnostica in 
senso lato comprende le macro-attività di Startup, Management, Monitoraggio, 
Manutenzione e Amministrazione Rete che verranno affrontate nei capitoli successivi. 
 
2.2 Manageability, Management e 
Monitoring 
E’importante differenziare questi due concetti prima di proseguire al fine, oltrechè di 
chiarirne il significato, anche di introdurre concetti chiave relativi alla diagnostica di 
sistemi. 
Per manageability si intende la “capacità di gestire”. In essa si definisce appunto come le 
componenti da gestire comunicano con i servizi/le funzioni del sistema management. In 
particolare è da considerarsi la più importante “interfaccia” tra  il sistema di 
management e l’oggetto da gestire ( per es. OS,applicazioni,middleware,componenti, 
ecc). 
 
  2-15 
 
Pag. 15 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Per management, nel contesto della diagnostica, intendiamo invece la capacità di sapere 
utilizzare la manageability al fine di eseguire attività di diagnostica dell’infrastruttura e del 
sistema IT.  
Un altro termine di cui è bene avere presente il significato è quello di monitoring. Con 
esso indicheremo semplicemente la capacità del nostro sistema di management di 
raccogliere informazioni. L’analisi di queste, rispetto per esempio ad un modello atteso o 
a qualunque specifica proprietà di comportamento e l’eventuale reazione in caso di 
divergenze, è da associarsi invece sempre all’area di management. 
 
2.3 Importanza di un Sistema di 
Diagnostica 
A seconda della qualità del servizio che si deve fornire attraverso il proprio sistema e dei 
conseguenti vincoli che devono essere rispettati (per es. contratti di SLA trattati in 16-
165),  il sistema di diagnostica può acquisire livelli di importanza molto elevati al fine di 
garantirne una corretta attuazione. Basti pensare per esempio all’importanza di un 
sistema di diagnostica in tempo reale di un applicativo ospedaliero di controllo dello 
stato di salute di un paziente o per il controllo di un processo in una catena di 
montaggio per capire quanto critico e importante può essere spesso avere sotto 
sorveglianza il corretto funzionamento di tali applicativi. Ciò è chiaramente ancora più 
cruciale se si tiene in considerazione che la gran parte dei disservizi si verificano durante 
i picchi di domanda, e che quindi l’incremento di affidabilità del sistema riveste un ruolo 
molto spesso prioritario rispetto ad altre richieste.  
Due analisi, una condotta da Jim Grey (ricercatore e manager di Microsoft) nell’1985 e 
l’altra più recente pubblicata della Standish Group International (azienda leader in 
project e value performance) nel loro giornale VirtualBEACON mostrano come i picchi 
di fallimenti in un sistema siano causati per la gran parte da disfunzioni a livello software 
e di intervento da parte degli operatori (sotto definiti come “people” )  piuttosto che 
altro.  Nella seguente tabella sono mostrate le percentuali di disfunzioni nella varie aree 
di interesse. 
  
TABELLA 1:  PERCENTUALE DELLE CAUSE DEI GUASTI AD UN SISTEMA RILEVATA DALLO 
FIGURA 2: MANEGEMENT E MANAGEABILITY 
Oggetto da gestire Sistema di Management 
Manageability 
  2-16 
 
Pag. 16 
 
STUDIO DI J.GRAY A CONFRONTO CON UNO STUDIO DEL 2002 DELLA STANDISHGRP. 
 Analisi di J.Gray 
1985 
 
Standish Grp. 
2002 
 
People 42% 38% 
Software 25% 28% 
Hardware 18% 17% 
Environment 
(power, a/c, etc.) 
14% 17% 
Unknown 1% - 
 
 
E’interessante in questo proposito analizzare anche il risultato di un sondaggio condotto 
nel 2003 durante una JavaOneConference, in cui il 74% dei partecipanti hanno 
dichiarato di constatare regolarmente problemi di malfunzionamento a livello software 
(software failures). Di questi, il 52% ha specificato inoltre che si trattava di problemi 
legati ad applicazione e servizi di critici per il funzionamento del sistema. 
Un’ulteriore prova a conferma di quanto detto è stato rivelato anche dall’azienda 
Gartner che ha recentemente affermato: “40 percent of unplanned downtime results from 
application failures”. 
Si può quindi a ragion veduta dedurre l’importanza dei benefici che l’introduzione di un 
sistema di management avanzato può apportare ad una struttura che ne è priva o mal 
organizzata in proposito. Sopratutto in ambito software, dove ancora purtroppo 
l’impiego di questi sistemi è carente. 
 
2.4 Evoluzione dei Sistemi e della 
Diagnostica 
L’iter più o meno comune nella maggior parte dei casi per l’individuazione e la 
riparazione di un generico malfunzionamenti è quasi sempre il seguente: l’utente dopo 
aver sperimentato il guasto lo notifica all’amministratore (in genere di rete) il quale 
provvede tramite la sua esperienza e capacità di individuarne le cause effettuando i test 
(per lo più manualmente) che ritiene utili. Al passo successivo interpreta i dati raccolti e 
cerca una risoluzione del problema dovendo magari anche interagire con amministratori 
dislocati remotamente.   
Dallo scenario appena descritto se ne evince una tragica situazione per il nostro 
amministratore nel caso di risoluzioni di problemi molto intricati e distribuiti. Senza 
contare tra l’atro le difficoltà del medesimo nel mantenere le performance al limite delle 
soglie concordate dagli eventuali SLA (Service Level Agreement). 
  2-17 
 
Pag. 17 
 
Risulta evidente quindi, che con l’incremento vertiginoso dei sistemi di rete e con il 
quasi contemporaneo aumenti dello sviluppo di applicativi distribuiti, è  via via sempre 
aumentata la necessità di avere degli strumenti di gestione più complessi ed efficaci. 
Dalle prime iniziative molto specifiche e rigide (come quella appena descritta) si è andati 
sempre più in una direzione volta a uniformare gli standard  fino ad arrivare a sistemi di 
diagnostica complessi con capacità anche auto-gestionali che richiedono un intervento e 
conoscenze minime da parte dell’operatore in questione permettendo di monitorare e 
diagnosticare ambienti eterogenei in maniera completa e non più isolata.  Il grande passo 
avanti è stato permesso comunque prevalentemente dall’utilizzo di standard di 
comunicazione comuni tra i vari produttori. In questo modo si è potuto man mano 
rendere le funzionalità gestionali sempre più astratte ed articolate.  
Quanto detto non toglie che resta ancora enormemente difficile effettuare delle buone 
diagnosi automatizzate per problemi di ampia portata dato che spesso l’interpretazione 
dei sintomi provocati da una disfunzione possono essere molteplici e magari 
apparentemente non correlati.   
Uno studio condotto dalla GIG (Giga Information Group) mostra le principali aree in 
cui vengono impiegate tecnologie di management attualmente.  
 
 
FIGURA 3: MANAGEMENT TECHNOLOGY DISTRIBUTION (GIGA INFORMATION GROUP) 
 
Dal grafico si può osservare un considerevole interesse per le aree di network e 
application management. In particolare è constatato che queste ultime siano in larga 
misura rappresentate da sistemi per la gestione real-time di apparecchiature 
prevalentemente  hardware gestiti in maniera centralizzata. 
 
2.5 Benefici derivanti dall’utilizzo di sistemi 
di Management 
Come visto in precedenza, non siamo di certo in presenza di applicativi “perfetti”. 
  2-18 
 
Pag. 18 
 
Considerando anzi il dato di fatto che molto spesso si hanno down-time elevati di parti 
critiche di sistema, si possono trarre ovvie conclusioni sui danni che si possono 
verificare a seconda del sistema in cui questo accade. Perdere milioni di transazioni 
bancarie per esempio  può portare ad una notevole  perdita di profitto, immagine,ecc. 
E’chiaro a questo punto che la diagnostica immediata o addirittura anticipata di un 
malfunzionamento e un rapido intervento risolutivo essere incisivi in termini economici.   
Anche dal punto di vista degli sviluppatori software i benefici sono innumerevoli. Se 
non sono previsti sistemi di rilevamento di una disfunzione, si può andare incontro a 
periodi impredicibili di ripristino a seconda delle dimensioni e del grado di distribuzione 
delle sue componenti. Lo stesso dicasi per gli interventi di manutenzione e/o 
ottimizzazione:se è presente un sistema di management evoluto si possono effettuare 
molto velocemente interventi di configurazione o quant’altro. 
In un articolo di Bill Buzbee e Stephen DuBravac, due software designers della HP, 
forniscono un esempio concreto di vantaggio dal lato Business: Il business manager è un 
fruitore di servizi IT che necessita in primis della loro disponibilità con il minor numero 
di guasti e di tempi di ripristino possibili. Per soddisfare questi apparentemente semplici 
requisiti si è costretti a effettuare diagnosi e previsioni rapide che sono i compiti primari 
di un sistema di diagnostica. Una semplice diagnostica ci può informare istantaneamente 
di un malfunzionamento e  strumenti avanzati possono addirittura  fornirci informazioni 
riguardo all’eventuale rischio nel caso si verificassero certi danni al sistema in questione 
anticipatamente, diventando così strumenti di valutazione anche di livello più elevato in 
modo da essere utili attraverso le informazioni ottenute per esempio al manager in 
questione per cercare di massimizzare i profitti correggendo il proprio business process. 
In questo articolo viene inoltre anche affermato che l’80% del tempo per la risoluzione 
di un problema, viene perso nella fase di individuazione della causa principale del 
guasto. Anche per questo compito uno strumento adeguato di diagnostica può 
apportare grosse migliorie in termini di tempo fornendo gli adeguati mezzi per la 
risoluzione dello stesso.