Transcript
Middleware Laboratory
Sistemi Distribuiti Corso di Laurea Specialistica in Telecomunicazioni
AA 2006/2007
Slides del corso Sara Tucci Piergiovanni
Middleware Laboratory
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
1
Middleware Laboratory
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
Introduzione
Introduzione
4
2
Middleware Laboratory
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’ -
Ogni entità gode di una visione non accurata e non completa dell’intero sistema
-
Concorrenza
-
Guasti parziali
-
-
Le entità eseguono le loro azioni in modo concorrente Alcune entità potrebbero guastarsi mentre altre continuano la loro attività, il sistema nel suo complesso rimane funzionante? Che significa funzionante? 5
Introduzione
Middleware Laboratory
Esempi di reti caratterizzanti un sistema distribuito intranet
internet
sistema mobile 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
3
Middleware Laboratory
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
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
4
Middleware Laboratory
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
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
5
Middleware Laboratory
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
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
6
Middleware Laboratory
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
Introduzione
13
Middleware Laboratory
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
7
Middleware Laboratory
Mettiamo tutto insieme: un esempio Leader
update: dati posizione aereo Controllore di cella
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 15
Introduzione
Middleware Laboratory
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
8
