Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D La Corte in Rete
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Stefano Russo » 2.Modelli di sistemi distribuiti


Sommario

  • Modelli
    • di programmazione
    • architetturali (client/server, peer-to-peer, mobile computing, …)
    • fondamentali (interazione, fallimenti, sicurezza)
  • Algoritmi distribuiti
  • Sistemi distribuiti sincroni e asincroni
  • Classificazione dei fallimenti nei sistemi distribuiti

Modelli per l’analisi e la sintesi di sistemi distribuiti

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:

  • quali sono le principali entità del sistema?
  • quali sono le modalità di interazione tra essi?
  • quali sono le caratteristiche che determinano il comportamento individuale e collettivo delle entità?

Per la specifica, l’analisi e lo sviluppo di sistemi distribuiti servono:

  • modelli architetturali;
  • modelli fondamentali;
  • modelli di programmazione.

Modelli di programmazione

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.:

  • modello basato su processi;
  • modello orientato agli oggetti;
  • modello a componenti;
  • modello orientato ai servizi.

Modelli di programmazione

Es.: modello a componenti

  • Componente:
    • modulo software eseguibile dotato di interfacce;
    • le sue dipendenze da altri moduli sono esplicite nelle interfacce;
    • può essere rilasciato ed eseguito autonomamente;
    • è componibile con altri moduli per costruire unità software più complesse.
  • Component Based Software Engineering (CBSE)
    • Estende la nozione di riuso rispetto all’orientamento agli oggetti (OO).
    • Riuso non solo di classi e procedure, ma di moduli eseguibili.
  • Il modello a componenti può essere considerato una evoluzione del modello a oggetti.
    • Modello OO: dipendenze tra oggetti non esplicite nelle interfacce; la logica delle interazioni tra oggetti è nascosta al loro interno.

Modelli di programmazione

Es.: Modello a componenti nell’architettura a tre livelli du Sun Java 2 Enterprise Edition (J2EE).

Es.: Modello a componenti nell'architettura a tre livelli du Sun Java 2 Enterprise Edition (J2EE).


Modelli architetturali

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:

  • client-server:
    • 2-tiers, 3-tiers, n-tiers;
  • peer-to-peer;
  • varianti:
    • proxy e cache;
    • server multipli;
    • codice mobile:
    • agenti mobili;
    • thin client.
  • service-oriented (SOAs).

Modelli architetturali

Tipici requisiti di progetto (non funzionali) per le architetture distribuite:

  • prestazioni:
    • tempo di risposta;
    • produttività (throughput);
    • bilanciamento del carico (load balancing).
  • qualità del servizio (QoS);
  • scalabilità;
  • dependability:
    • correttezza;
    • sicurezza;
    • tolleranza ai guasti.

Modello client-server


Modello peer-to-peer

  • Approccio distribuito;
  • oggetti (risorse) condivisi dai peer;
  • consente affidabilità e scalabilità;
  • richiede algoritmi per lalocalizzazione e la  gestione delle risorse.

Modello con proxy e cache

Usati per accedere a (web) server attraverso un firewall.
-Cache situate sui client e/o sul proxy (condivisa dai client).

Usati per accedere a (web) server attraverso un firewall. -Cache situate sui client e/o sul proxy (condivisa dai client).


Modello con codice mobile

Es.: web applets
a) le richieste dei clienti provocano il download del codice di una applet
b) il cliente interagisce localmente con l’applet

  • Buoni tempi di risposta interattiva;
  • Rischi per la sicurezza.

Modelli fondamentali

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:

  • rendere esplicite le ipotesi rilevanti sul sistema;
  • consentire di studiare comportamenti/proprietà possibili o non possibili del sistema, date le ipotesi.

Modelli fondamentali:

  • modello di interazione;
  • modello dei guasti;
  • modello di sicurezza.

Modello di interazione

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.

Modello di interazione (segue)

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:

  • sistema sincrono;
  • sistema asincrono;
  • sistema parzialmente sincrono.

Algoritmi distribuiti

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.

Sistemi distribuiti sincroni

Un sistema distribuito è sincrono (Hadzilacos e Toueg, 1994) se esistono e sono noti:

  • i limiti inferiori e superiori al tempo di esecuzione di ogni passo di elaborazione;
  • il limite superiore al tempo di consegna di un messaggio;
  • il limite superiore al tasso di deviazione di ciascun orologio locale (clock drift rate) rispetto al tempo reale.

È 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.

Sistemi distribuiti sincroni

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.

Sistemi distribuiti sincroni

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:

  • individuare le risorse richieste dai processi per eseguire le elaborazioni e per scambiare messaggi;
  • garantire un numero sufficiente di cicli di processore;
  • garantire una sufficiente capacità di rete;
  • fornire ai processori clock con deriva limitata.

Sistemi distribuiti asincroni

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.

Modello dei fallimenti

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).

Modello dei fallimenti

Un modello dei fallimenti per un sistema distribuito definisce le modalità con cui si possono verificare guasti in:

  • processi,
  • canali di comunicazione.

In pratica, si possono avere fallimenti:

  • per crash,
  • per omissione,
  • di valore,
  • bizantini,

e, per i sistemi sincroni:

  • temporali

Modello dei fallimenti

Classificazione dei fallimenti (Hadzilacos e Toueg, 1994):

  • omission failure: si ha quando un processo o un canale non eseguono un’azione che ci si aspetta che eseguano;
  • arbitrary o Byzantine failure: è la semantica peggiore per un guasto, in cui si può verificare qualunque tipo di errore;
  • timing failure: mancato rispetto di una scadenza (applicabile solo ai sistemi sincroni).

Fallimenti benigni:

  • omission failures;
  • timing failures.

Modello dei fallimenti

Tipologie di fallimenti:

  • fail stop: si ha quando un processo non esegue più azioni, e gli altri processi sono in grado di rilevarne il fallimento;
  • crash: si ha quando un processo non esegue più azioni, e gli altri processi possono non essere in grado di rilevarne il fallimento;
  • omissione:
    • da parte di un canale: il canale non trasporta messaggi;
    • da parte di un processo: il processo fa una send / una receive, ma il messaggio non viene spedito / ricevuto (send omission / receive omission);

Modello dei fallimenti

Tipologie di fallimenti:

  • prestazionale:
    • di un canale: il tempo di consegna di un messaggio eccede il limite superiore;
    • di un processo: il tempo di esecuzione di una azione eccede il limite superiore;
    • del clock: la deriva rispetto a un clock ideale eccede il limite superiore;
  • bizantino: un fallimento di un processo o di un canale, che si comportano in modo arbitrario (es: mandano più messaggi, omettono azioni, o si comportano in modo malizioso).

Modello di sicurezza

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:

  • confidenzialità (protezione dall’accesso di non autorizzati);
  • integrità (protezione dall’alterazione o compromissione);
  • disponibilità (protezione dei mezzi di accesso alle risorse).

I materiali di supporto della lezione

G. Coulouris et al.: Distributed Systems: Concepts and Design

(Cap. II), IV ed., 2005.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion

Fatal error: Call to undefined function federicaDebug() in /usr/local/apache/htdocs/html/footer.php on line 93