L'affidabilità dei sistemi informatici

Un numero crescente di organizzazioni, da società di informatica a case editrici, si affidano a servizi on-line che funzionano più o meno come quelli offerti dal World Wide Web. Grazie a questi servizi è possibile gestire informazioni importanti, rendere più rapido il processo di decisione ed aumentare l'efficienza. Il rovescio della medaglia è rappresentato dagli inconvenienti tipici delle reti di calcolatori e del software distribuito.

Leslie B. Lamport, ha definito un sistema di elaborazione distribuito come un sistema in cui il guasto di un calcolatore di cui non si sospetta neppure l'esistenza, può inficiare il funzionamento del vostro computer. Talvolta il prezzo da pagare è la pazienza e il tempo degli utenti; tuttavia, se a guastarsi è un calcolatore che sovrintende al funzionamento della Borsa o di un ospedale, o va in tilt un sistema per il controllo del traffico aereo, i guai sono più seri.

Le reti di calcolatori destinate al controllo del traffico aereo e alle transazioni finanziarie devono funzionare 24 ore su 24 ed essere aggiornate di continuo. Per questo motivo è opportuno includere fra gli argomenti relativi alla sicurezza informatica, anche quelli prettamente afferenti le interconnessioni tra calcolatori; non soltanto preoccuparsi di rafforzare il sottosistema dei dischi o duplicando le cpu e le memorie. Ovviamente, fare in modo che un calcolatore sia assolutamente affidabile è pressocché impossibile.

Si possono applicare i principi di fault tolerance tipici dell'hardware anche al software, ottenendo programmi capaci di resistere a momentanee cadute di un nodo, capaci di riconfigurarsi perché copiano in continuazione le informazioni più importanti. In tal modo il sistema nel suo complesso continua a funzionare e, teoricamente, fornisce un servizio ininterrotto agli utenti ancora collegati. Un metodo abbastanza diffuso per costruire un sistema distribuito a elevata disponibilità prevede un sistema primario e uno di riserva; se il primo si guasta, può essere messo in funzione il secondo. La commutazione dall'uno all'altro è facile se i dati non subiscono cambiamenti, ma diventa delicata se i dati o i documenti sono modificati durante il funzionamento del sistema.

In una grande rete di server, dati, documenti e programmi, può essere difficile distinguere tra un guasto vero e proprio del sistema e semplici difficoltà di comunicazione. I programmatori hanno affrontato il problema ricorrendo a un accorgimento detto di replicazione attiva, che consiste nel fare eseguire al software del sistema copie ridondanti dei programmi o dei server essenziali mediante l'uso dei cosiddetti gruppi di elaborazione. Un gruppo di elaborazione collega tra loro alcuni programmi che cooperano strettamente. Un sistema distribuito può contenere molti gruppi di elaborazione, e un programma può appartenere a più gruppi. La parte fondamentale per il funzionamento di questa architettura è quella rivolta alla trasmissione dei messaggi tra i gruppi e i programmi.

L'idea di base della replicazione attiva è semplice, a discapito della complessità del software necessario per ottenerla. La replicazione attiva consente al sistema di tollerare i guasti perché qualsiasi membro del gruppo può far fronte a qualunque richiesta: se una macchina si blocca, il compito può essere smistato a un altro nodo attivo. Inoltre, se una data richiesta non altera i dati, un singolo nodo può affrontare il problema anziché bloccare l'intero sistema. In tal modo è possibile svolgere più compiti allo stesso tempo mediante programmi diversi, accelerando il lavoro mediante l'elaborazione parallela.

Per gran parte del tempo i programmi replicati lavorano in parallelo, e ciascun programma affronta il proprio insieme di richieste in un ordine specifico. Se un baco del software risce a passare il collaudo e interferisce con alcune parti di un'elaborazione, è statisticamente assai improbabile che si verifichi il blocco totale del sistema. Perché i sistemi distribuiti si guastano allora? Sorprendentemente sono proprio gli errori degli operatori una delle principali cause.

I tentativi tradizionali di migliorare l'affidabilità del software e dell'hardware hanno quasi sempre trascurato la possibilità di un errore umano, eppure gli errori degli utenti sono responsabili in molti casi di quantità di downtime superiore a quella dovuta a qualsiasi altra causa. Probabilmente questo accade perché i progettisti dei computer e i programmatori preferiscono sacrificare la facilità d'uso alla ricerca di migliori prestazioni. I software di database, ad esempio, richiedono sovente uno staff di tecnici ben addestrati, che lavorano a tempo pieno. Esiste una buona quantità di programmi per effettuare il benchmark delle prestazioni dei sistemi, ma spesso questi strumenti non sono idonei per simulare "errori" e verificare il comportamento di un programma o di un sistema informatico nell'attuare le "azioni di recupero" previste a livello di ingegnerizzazione del prodotto.

Sovente si effettua abilmente un reboot del proprio computer, o per prevenzione, perché la macchina si sta comportanto in maniera strana o per reazione, perché c'è stato un crash di un programma importante. Il riavvio può essere utile anche per i computer più grandi, in quanto permette di ricominciare da zero e di eliminare tutta una classe di errori transitori. Purtroppo non sempre è possibile eseguire un reboot e più frequentemente, il riavvio di un sistema richiede parecchio tempo (anche in rapporto alla dimensione del calcolatore stesso e della tipologia di impiego).

La tendenza attuale è quella di sviluppare sistemi che possano effettuare un "reboot dolce", evitando di mandare nel panico i sistemi interconnessi per la mancanza di segni di vita da parte del sistema sottoposto a riavvio. In particolare queste ricerche vengono portate avanti nel settore delle comunicazioni terra-spazio-terra, laddove se per un errore ai sistemi non fosse disponibile un operatore umano per riavviarli manualmente, si perderebbe il segnale del satellite e con esso tutti i dati di quell'orbita.

In parole povere si tenta di implementare una specie di funzione "annulla", tipica oggi in ogni programma di elaborazione di testi, anche in contesti ad alta criticità. L'implementazione di questa funzione richiede però grandi quantità di risorse e rallenta in molti casi significativamente i sistemi. La tentazione è allora quella di ridurre in fase di progettazione dell'applicazione, l'interazione con l'operatore umano. Riducendola si presume che diminuiscano anche gli errori dovuti "all'essere umano". Ironicamente, si aumenta la probabilità di un guasto al sistema perché un errore umano all'inizio del percorso che processa i dati, viene rilevato quando ha oramai interagito con molte parti del programma e modificato in maniera anche irreversibile la base dati.

Per tale motivo, ad esempio, durante la produzione di un microprocessore, prima che esso esca dalla fabbrica, passa diversi test di affidabilità, eseguiti grazie ad un contorno di elettronica aggiuntiva che viene eliminata nella fase di rilascio sul mercato. Analogamente, durante lo sviluppo di programmi, è consigliato introdurre l'uso dei cosiddetti "errori di prova", specie per far fronte ad errori inaspettati (più simili a quelli che nell'uso reale potrebbero verificarsi a causa di un errore umano).

Privacy Policy