Un modello descrive tutte e sole le caratteristiche essenziali di un sistema distribuito, che è necessario considerare per specificare o analizzare i suoi aspetti strutturali e di funzionamento.
Un modello risponde a domande quali:
Per la specifica, l’analisi e lo sviluppo di sistemi distribuiti servono:
Descrivono le proprietà delle unità software secondo cui decomporre e programmare i sistemi distribuiti.
Tali proprietà sono astrazioni supportate da sistemi operativi, middleware, linguaggi, ambienti di sviluppo.
Es.:
Es.: modello a componenti
Descrivono l’organizzazione del sistema distribuito nelle sue parti componenti, le relazioni tra esse, e la loro allocazione sui nodi del sistema di elaborazione.
Es. di architetture:
Tipici requisiti di progetto (non funzionali) per le architetture distribuite:
Usati per accedere a (web) server attraverso un firewall. -Cache situate sui client e/o sul proxy (condivisa dai client).
Es.: web applets
a) le richieste dei clienti provocano il download del codice di una applet
b) il cliente interagisce localmente con l’applet
Un modello fondamentale è un’astrazione delle caratteristiche essenziali di un sistema, necessarie per analizzare e comprenderne il funzionamento, ragionare sul suo comportamento, e dimostrarne formalmente (logicamente, matematicamente) le proprietà.
Scopo di un modello fondamentale:
Modelli fondamentali:
Un sistema distribuito è composto da processi – entità che eseguono azioni elaborative, in esecuzione su più nodi del sistema di elaborazione, ciascuno dotato di un proprio orologio – che incapsulano risorse, ed interagiscono esclusivamente tramite messaggi scambiati su un canale di comunicazione.
Lo stato di un processo è l’insieme dei dati che può leggere o aggiornare.
Lo stato di ciascun processo è locale e privato – non può essere letto e aggiornato dagli altri processi.
Nel sistema non esiste un clock globale.
La velocità relativa dei processi e i tempi di trasmissione dei messaggi tipicamente non possono essere previsti con esattezza in un sistema distribuito.
Modelli di interazione:
Un algoritmo distribuito è la specifica delle azioni (elaborazioni, scambio messaggi) che devono essere intraprese dai processi che compongono il sistema, per il raggiungimento di un obiettivo.
È difficile descrivere tutti gli stati possibili di un algoritmo distribuito, anche per via dei malfunzionamenti (indipendenti) cui sono soggetti i processi e la trasmissione dei messaggi.
La progettazione di un algoritmo distribuito deve basarsi sulle ipotesi che è possibile (o non è possibile) fare sulla tempificazione del sistema, e prevedere la gestione dei malfunzionamenti.
Un sistema distribuito è sincrono (Hadzilacos e Toueg, 1994) se esistono e sono noti:
È spesso possibile stimare i limiti al tempo di esecuzione dei processi, al ritardo dei messaggi e alla deriva degli orologi, ma è difficile individuare e garantire i valori reali.
Se non è possibile garantire tali valori limite, qualunque algoritmo basato su di essi non è affidabile.
Vantaggi:
Per i sistemi sincroni è possibile definire algoritmi distribuiti basati sull’individuazione dei fallimenti tramite time-out.
Svantaggi:
È difficile assicurare tali proprietà in un sistema su grande scala e nel tempo.
In pratica, è spesso possibile stimare i limiti al tempo di esecuzione dei processi, al ritardo dei messaggi e alla deriva degli orologi, ma è difficile individuare e garantire i valori reali.
Se non è possibile garantire tali valori limite, qualunque algoritmo basato su di essi non è affidabile.
Tipicamente i sistemi distribuiti reali non sono sincroni.
Tuttavia modellare algoritmi per sistemi sincroni è utile per studiare come si comporteranno nei sistemi reali.
È comunque possibile costruire sistemi distribuiti sincroni.
È necessario:
Un sistema distribuito è asincrono se non esistono limiti alla velocità di esecuzione dei processi, al ritardo di trasmissione dei messaggi, o alla deviazione degli orologi.
In un sistema asincrono, non è possibile formulare ipotesi temporali relativamente all’elaborazione, allo scambio messaggi, alla sincronizzazione.
Alcuni problemi non hanno soluzione nei sistemi asincroni.
Molti sistemi distribuiti reali sono asincroni (es.: Internet).
I modelli sincrono e asincrono sono gli estremi di uno spettro di possibilità con cui modellare i sistemi reali.
Fallimento (failure): scostamento da un comportamento considerato corretto o desiderabile.
Guasto (fault): causa originaria del fallimento (es: un “baco” in una istruzione del programma); anche se presente, il fault può non essere attivato in una esecuzione, per es. in funzione dei dai dati di ingresso (es: l’istruzione col “baco” non viene eseguita); quando il fault degenera in errore a causa dell’attivazione, esso si dice attivo (active), altrimenti è dormiente (dormant).
Errore (errore): lo stato in cui transita il sistema a seguito dell’attivazione di un guasto, nel quale dunque il suo comportamento si discosta da quello considerato corretto (correct behaviour).
Un modello dei fallimenti per un sistema distribuito definisce le modalità con cui si possono verificare guasti in:
In pratica, si possono avere fallimenti:
e, per i sistemi sincroni:
Classificazione dei fallimenti (Hadzilacos e Toueg, 1994):
Fallimenti benigni:
Tipologie di fallimenti:
Tipologie di fallimenti:
Il modello di interazione prevede processi che incapsulano risorse (oggetti), e che forniscono ad altri processi l’accesso ad esse mediante interazioni con scambio di messaggi.
Il modello di interazione è dunque la base per il modello di sicurezza: la sicurezza di un sistema distribuito può essere ottenuta rendendo sicuri i processi e i canali di comunicazione tra essi, e proteggendo le risorse che i processi incapsulano.
Aspetti della sicurezza:
1. Caratterizzazione dei sistemi distribuiti
2. Modelli di sistemi distribuiti
3. Tempo e sincronizzazione nei Sistemi Distribuiti
4. Stato globale nei Sistemi Distribuiti
5. Problemi di consenso nei sistemi distribuiti
7. Algoritmi di mutua esclusione nei sistemi distribuiti
8. Algoritmi di elezione nei sistemi distribuiti
10. Il Network File System di SUN Microsystems
11. AFS (Andrew File System) e GFS (Google File System)
12. Transazioni e controllo di concorrenza
13. Transazioni
15. Affidabilità (dependability) dei sistemi software distribuiti
16. Affidabilità dei sistemi software distribuiti
17. Software Faults
18. Classificazione e analisi dei difetti software
G. Coulouris et al.: Distributed Systems: Concepts and Design
(Cap. II), IV ed., 2005.