Introduzione

QuickTime™ e un
decompressore TIFF (Non compresso)
sono necessari per visualizzare q uest'immag ine.
Middleware Laboratory
Sistemi Distribuiti
Corso di Laurea Specialistica in Telecomunicazioni
AA 2006/2007
Slides del corso
Sara Tucci Piergiovanni
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Il corso: informazioni utili
Riferimenti del docente:
-
sito web: www.dis.uniroma1.it/˜tucci
e-mail: [email protected]
Ricevimento:
-
durante il corso: dopo lezione
dopo il corso: spedire una mail
Materiale Didattico:
-
Testi consigliati:
G.Coulouris, J.Dollimore, T.Kindberg “Distributed Systems. Concepts
and Design” Addison Wesley
- R.Guerraoui, L. Rodrigues “Introduction to Reliable Distributed
Programming” Springer-Verlag
-
-
Slides delle lezioni (sul sito)
-
Dispense distribuite durante il corso
Introduzione
2
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Programma del Corso
Programma:
- TEORIA:
-
-
-
Modelli computazionali e relativa astrazione dei componenti di base di
un sistema distribuito: caratterizzazione delle entità di calcolo
(astrazione di processo), caratterizzazione della comunicazione tra
entità (astrazione di canale), caratterizzazione dei guasti.
Problemi Tipici nei Sistemi Distribuiti e relativi Algoritmi
(sincronizzazione dei clock, mutua esclusione, consenso, elezione di
un leader, comunicazioni ordinate)
SISTEMI:
Il software: lo strato middleware tra la rete e l’applicazione che gira su
un sistema distribuito: CORBA, JAVA RMI, Data Distribution Service
- Cenni di progettazione di un sistema distribuito: il caso del
publish/subscribe
-
Introduzione
3
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Introduzione
Introduzione
4
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Sistema distribuito: una definizione
Un sistema distribuito è costituito da un insieme
di entità autonome (componenti software e hardware)
spazialmente separate che comunicano e coordinano
tra loro le loro azioni attraverso scambio di messaggi
Caratteristiche di base:
- Distribuzione e localita’
-
-
Concorrenza
-
-
Ogni entità gode di una visione non accurata e non completa dell’intero sistema
Le entità eseguono le loro azioni in modo concorrente
Guasti parziali
-
Alcune entità potrebbero guastarsi mentre altre continuano la loro attività, il
sistema nel suo complesso rimane funzionante? Che significa funzionante?
Introduzione
5
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Esempi di reti caratterizzanti un sistema distribuito
Ma un sistema distribuito è molto di piu’:
si possono considerare parte del
sistema tutti i componenti software che
girano sui vari dispositivi, quindi gli
algoritmi che vengono implementati per
risolvere problematiche di base in questi
sistemi (comunicazione molti a molti,
problemi di coordinamento)
Introduzione
6
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
La distribuzione: sfide e possibilita’
Un certo numero di organizzazioni vuole condividere i propri dati. Ogni
organizzazione ha i propri dati organizzati autonomamente ma vuole poter
accedere ai dati delle altre organizzazioni. I dati sono conservati in database, se ne
vogliono rendere pubblici (accessibili) alcuni tipi. L’accesso avviene attraverso
un’applicazione client in grado di accedere ai dati. Quali le sfide?
Sicurezza: solo i client autorizzati possono accedere e solo ai dati pubblici
Interoperabilita (o openess) ’: tecnologie e metodologie usate per lo storage dei dati
potrebbero essere le piu’ diverse, il client deve accedere ai dati in modo trasparente
rispetto a queste diversità. Tecnologie e metodologie potrebbero cambiare nel tempo,
il sistema deve essere in grado di integrarle facilmente
- Scalabilità: tutti i dati messi a disposizione dalle diverse organizzazioni potrebbero
essere spostati in un solo database accessibile a tutti, ma se il numero di client
aumenta? Il sistema nel suo complesso non deve perdere prestazioni
- Affidabilità’ e Disponibilità: update di un dato e guasto del client durante l’update: il
database deve rimanere in uno stato consistente e comunque accessibile ad altri
client
-
Altri esempi di sistemi distribuiti:
- Sistema di controllo del traffico aereo: dati che devono essere trasferiti dalla sorgente
alla destinazione per controllo/elaborazione/memorizzazione
- Web: attraverso un web browser, gli utenti possono accedere a documenti di vari tipi,
ascoltare musica, vedere video e interagire con un illimitato numero di servizi
Introduzione
7
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Un “buon” sistema e’
-Sicuro
-Aperto
-Scalabile
-Affidabile
e Disponibile
In particolare volgeremo l’attenzione
-
all’aspetto dell’affidabilità, in un’ottica teorica, inisistendo sulla
correttezza degli algoritmi distribuiti (il sistema che si comporta in modo
corretto in presenza di guasti, concorrenza, conoscenza approssimata e
parziale delle entita’ dell’intero sistema)
-
all’aspetto dell’ openess e della scalabilita’ in un’ottica di sistema.
L’openess è una caratteristica che riguarda soprattutto il software e la relativa
progettazione di componenti software con tecnologie e metodolgie adeguate.
- La scalabilita’ è una proprietà che riguarda aspetti in massima parte
architetturali (coinvolgendo la parte di deployment fisico dei componenti) e di
prestazione degli algoritmi distribuiti impiegati nel sistema.
-
Introduzione
8
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Openess
Interoperabilità. La capacità di due implementazioni di sistemi diversi a
cooperare usando servizi/componenti specificati da uno standard comune
-
Mobile code and Virtual Machine: mando il codice (java applet), il codice è interpretabile da
ogni hardware perchè viene generato per una “macchina virtuale”: il codice (chiamato bytecode) è
interpretabile dalla virtual machine che lo traduce in linguaggio macchina e lo esegue. In questo
modo il programma è indipendente dal sistema operativo
Portabilità. La capacità di un servizio/componente implementato su un sistema
distribuito A, di essere eseguito senza modifiche su un sistema B.
Estendibilità. La capacità di un sistema distribuito di aggiungere componenti
servizi e di essere integrati nel sistema distribuito già in esercizio.
Evolvability. La capacità di un sistema distribuito di evolvere nel tempo per
esempio fare convivere differenti versioni di uno stesso servizio.
Il numero a volte elevatissimo (a volte ordine di decine di migliaia) di sviluppatori
di software indipendenti rende lo sviluppo di una piattaforma distribuita un lavoro
molto complesso e difficile da gestire…
Introduzione
9
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Openess (ii)
Condizione necessaria per la openess: documentazione e specifica delle
interfacce software chiave dei componenti di un sistema
Interface Definition Language (descrive la sintassi di un servizio/componente,
funzioni disponibili, parametri di input/output, eccezioni etc)
Problema: descrizione semantica di un servizio.
La Specifica di un componente/servizio si dice propria se è:
- Completa. Una specifica è completa se ogni cosa necessaria ad una
implementazione è stata specificata. Se una specifica non è completa
l’implementatore deve aggiungere dettagli di specifica che a quel punto
dipendono dall’implementazione.
- Neutrale. Una specifica e’ neutrale se non offre alcun dettaglio su una
possibile implementazione
Introduzione
10
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Middleware: openess e oltre
Software che supporta lo sviluppo di applicazioni distribuite (quelle a livello applicazione)
Funzionalità desiderate:
Accesso: permettere di accedere a risorse locali e remote con le stesse
modalità
- Locazione: permettere di accedere alle risorse senza conoscerne la
locazione
- Concorrenza: permettere ad un insieme di processi di operare
concorrentemente su risorse condivise senza interferire tra loro
- Guasti: permettere il mascheramento dei guasti in modo che gli utenti
possano completare le operazioni richieste anche se occorrono guasti hw
e/o sw
- Mobilità: permettere di spostare risorse senza influenzare le operazioni
utente
- Prestazioni: permettere di riconfigurare il sistema al variare del carico
- Scalabilità: permettere alle applicazioni di espandersi in modo scalabile
senza modificare la struttura del sistema e degli algoritmi applicativi
-
Tre tipi di middleware: communications middleware, database middleware and systems middleware.
La complessità del middleware è relativa alla complessità delle relazioni trai i componenti del sistema.
Le prestazioni di una soluzione basata su sistema distribuito non sempre migliorano rispetto ad una basata
su sistema centralizzato. Il middleware, necessario per fornire servizi che sfruttano le caratteristiche di un
sistema distribuito, in generale può diminuire le prestazioni
Introduzione
11
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Scalabilità
Un sistema è scalabile se rimane operativo con adeguate prestazioni anche se il numero di
entità (risorse e di utenti) aumenta sensibilmente
-
Computers connessi ad internet: 188 nel 1979, 130000 nel 1989, 56000000 nel 1999
Web Servers connessi ad internet: 0 nel 1989, 5000000 nel 1999
La centralizzazione è contro la scalabilità:
- Servizi (singolo servizio per tutti gli utenti)
- Dati (singola tabella per tutti gli utenti)
- Algoritmi (fare routing basato su informazioni complete)
Quindi
- per controllare le perdite di prestazioni
-
-
Usare algoritmi che non richiedono di dialogare con tutto il set di user/accedere
all’intero set di dati di un sistema distribuito, ma che richiedono di dialogore
con un numero di users (o di accedere ad un set di dati) che non cresca
linearmente con il numero di users/taglia dei dati
per evitare i colli di bottiglia nel sistema
-
Replicazione di servizi (distributed DNS) e Dati. Da qui
Problemi di coordinamento
- Problemi di consistenza
-
Introduzione
12
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Mettiamo tutto insieme: un esempio
La griglia del cielo. Controllo delle rotte degli aerei su tutta Italia.
Distribuzione e località: radar+ controllore di volo controllano un limitato spazio aereo
(cella), piu’ radar per coprire tutto lo spazio aereo. Obiettivo: avere una visione globale
Concorrenza: i flussi informativi (tracce radar) dalle celle sono concorrenti. Obiettivo: avere
una visione consistente
Guasti: ogni singolo componente potrebbe guastarsi (radar o operatore con il quale il radar
comunica). Obiettivo: avere una visione continua
QuickTime™ e un
decompressore TIFF (Non compresso)
sono necessari per visualizzare quest'immagine.
QuickTime™ e un
decompressore TIFF (Non compresso)
sono necessari per visualizzare quest'immagine.
Introduzione
13
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Mettiamo tutto insieme: un esempio
L’architettura:
scalabile:
- italia divisa in tre regioni, ogni regione (controllore di regione) riceve dati da piu’ celle,
per metterli tutti insieme
- dati da radar a controllore, poi dati piu’ light registrati per regione (log).
disponibile:
- ridondanza: per ogni controllore di volo di cella ci sono piu’ macchine che ricevono dati
dal radar e mandano gli aggiornamenti alla regione
affidabile:
- algoritmi corretti, interazione corretta tra diversi componenti
Ed ora vediamo perché una funzionalità come la funzionalità di aggiornamento del log,
apparentemente banale da implementare, costituisce una vera e propria sfida a causa di
guasti, concorrenza, località.
Introduzione
14
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Mettiamo tutto insieme: un esempio
Leader
update: dati posizione
aereo
Controllore di cella
QuickTime™ e un
decompressore TIFF (Non compresso)
sono necessari per visualizzare quest'immagine.
Log
repliche
passive,
sostituiscono il
leader in caso
del suo guasto
1.
2.
3.
4.
Leader di Cella, sorgente di updates: PB: due update trasmessi in un certo ordine dal
leader potrebbero arrivare in ordine inverso, ma il log deve riflettere una storia
consistente. Necessario FIFO order
Piu’ Leader (uno per ogni cella): piu’ sorgenti di updates. PB. Immagina che un’aereo va
prima in cella A e poi in cella B, i due leader A e B inviano gli update, potrebbero arrivare
in ordine inverso. Necessario Total Order
Piu’ Leader devono aggiornare il log (risorsa condivisa), mentre qualcuno scrive su una
certa traccia altri non possono scrivere la stessa traccia. Necessaria Mutua Esclusione
Un Leader puo’ guastarsi. PB: sostituire il vecchio leader con una replica funzionante.
Necessaria Elezione del Leader
Introduzione
15
Middleware Laboratory
QuickTime™ e un
decompressor e TIFF ( Non compr esso)
sono necess ar i per visualizz are q uest'immag ine.
Mettiamo tutto insieme: un esempio
Leader A
Algoritmo per FIFO
ORDER (su ogni singolo
flusso di dati)
Algoritmo per
l’elezione del
leader
Controllore di cella
Algoritmo per
la mutua
esclusione
L’affidabilità
globale del
sistema si basa
sulla correttezza
dei singoli
algoritmi e
sull’interazione
corretta dei
diversi
componenti
Log
Leader B
Algoritmo per TOTAL
ORDER (su piu’ flussi di
dati)
Leader C
Introduzione
16