Struttura della lezione. Lezione 9 Architetture dei sistemi distribuiti (2) Il valore aggiunto di una rete di N utenti

Transcript

1 Struttura della lezione Lezione 9 Architetture dei sistemi distribuiti (2) Vittorio Scarano Corso di Programmazione Distribuita ( ) Laurea di I livello in Informatica Università degli Studi di Salerno Sistemi distribuiti: ma perché? La architettura di un sistema distribuito layer logici tier fisici Struttura a livelli: il middleware 2 Le opzioni offerte dalle reti Il valore aggiunto di una di N utenti Ricevere informazioni Permettere delle transazioni Affiliare: stabilire e mantenere gruppi Legge di Sarnoff: il valore aggiunto di una è: la connettività potenziale offerta al singolo utente che cresce con il numero di offerte possibili crescita lineare in N Legge di Metcalfe: il valore aggiunto di una è: il numero di transazioni potenziali che vengono permesse agli N utenti quadratico in N 3 4

2 La legge di Sarnoff: : aste online La legge di Metcalfe: : aste online prima host per aste online Annunci messi a disposizione dagli utenti Numero fissato di prodotti Numero variabile di utenti Totale del Valore ~ N classifieds.yahoo.com Sia la offerta che la domanda dipendono dal numero di utenti Valore ~ N 2 Classifieds.yahoo.com 5 6 La collaborazione su sistemi distribuiti: la legge di Reed Un esempio della legge di Reed un mercato per aste online Ogni sottoinsieme di utenti può formare una asta Valore totale ~ 2 N Beanies Pez 7 8

3 Le leggi di crescita dei sistemi distribuiti La combinazione delle leggi Valore Esempi Connessione di due reti con N e M utenti e relativo incremento di valore Sarnoff Broadcast N OnSale N+M N 2 Metcalfe Network , Annunci (N+M) 2 = N 2 +M 2 +2NM 2 N Reed Community AOL Chat, ebay 2 N+M = 2 N +2 M + (2 N 2 M -(2 N +2 M ) ) 9 Valore Totale Valore aggiunto N Valore totale = a N + b N 2 + c 2 N Tipicamente a >> b >> c a N + b N 2 + c 2 N a N + b N 2 a N 10 Una conseguenza Struttura della lezione All aumentare della dimensione, si entra in nuovi mercati con nuove possibilità e nuove richieste di servizi per i sistemi distribuiti e r l o a V Miglior contenuto N Regioni di valore dominante Migliori Transazioni N 2 N Migliori facilities per gruppi 2 N Sistemi distribuiti: ma perché? La architettura di un sistema distribuito layer logici tier fisici Struttura a livelli: il middleware 11 12

4 La architettura di un sistema informativo Una architettura di base La architettura di un Sistema Informativo: descrive come componenti hardware e software vengono usati per rispondere ai requisiti organizzativi Architettura (standard IEEE 1471): La organizzazione di un sistema rappresentato dai suoi componenti, dalle relazioni tra loro e l ambiente, dai principi che guidano il progetto e la evoluzione del sistema Client utilizzata direttamente dall utente, genera la richiesta Server contiene le risorse da accedere (dati/programmi) Rete assicura la connessione Rete Alcuni commenti Struttura della lezione Rete Client/Server sono spesso ruoli dinamici all interno dello stesso sistema, possono scambiarsi i ruoli Esempi: una connessione telefonica/chat 1-to-1 concatenazione di sistemi client/server Sistemi distribuiti: ma perché? La architettura di un sistema distribuito layer logici tier fisici Struttura a livelli: il middleware 15 16

5 I livelli logici di una architettura: i layer I livelli hardware di una architettura: i tier Detti anche Application Layer Caratterizzati dagli aspetti funzionali rispetto alla localizzazione fisica centrali per la progettazione e manutenzione Strati di software in cui si partizionano le applicazioni logica di presentazione (la interfaccia utente) logica di business (o applicativa) (funzionalità) logica di accesso I livelli software (layer) sono realizzati e distribuiti sui livelli hardware (tier) Configurazioni: single tiered (un livello di distribuzione) configurazione su mainframe two tiered (due livelli di distribuzione) la logica di business è divisa tra un client (es. PC) ed un server (es. un mainframe) la logica di presentazione è sul client, la logica di accesso è su server three tiered (tre livelli di distribuzione) Configurazione single tiered (mainframe) Configurazione two-tier tier Logica di accesso business presentazione A seconda di come separiamo i layer sui 2 tier si ottengono diverse architetture. Una notazione: per denotare servizi offerti ed acceduti via una interfaccia Server Client 19 interfaccia connessione 20

6 Two-tier tier: : 1 - distribuita Two-tier tier: : 2 - remota Il layer di presentazione viene distribuito sui due tier il client si occupa solamente della visualizzazione finale Il traffico di risulta sostenuto: le due componenti che implementano il layer di presentazione necessitano di banda Alta flessibilità e facilità di modifica 21 Maggiore carico sul client Minore richiesta di banda: le informazioni trasmesse al client sono solo quelle specifiche della applicazione la presentazione è a carico solo del client Moderata flessibilità e facilità di modifica 22 Two-tier tier: : 3 - Funzionalità distribuita Two-tier tier: : 4 - Gestione dati remota Il client viene coinvolto nella logica di business necessarie capacità computazionali Aumentano i problemi di gestione e manutenzione del client upgrade, recovery, etc. sensibilità della logica di business ai malfunzionamenti di ret Il client risulta completamente in carico della logica di business Poco flessibile: una modifica della applicazione necessita dell upgrade della applicazione su tutti i client 23 24

7 Two-tier tier: : 5 - Base di dati distribuita Three-tier tier: : Ampia scelta da Fat client Anche parte del layer di accesso risulta in carico al client Architettura fat client Traffico notevole sui dati Paradigma spesso imposto da sistemi di sviluppo integrato 25 Supporto elevato richiesto dalla utenza impone una soluzione sbilanciata verso il client Onerosa gestione e manutenzione del client 26 Three-tier tier: : a Thin client Una visione finale: N-tier Distribuzione di servizi ad un insieme aperto di utenti Facile gestione Notevole carico sul server del tier 3 Permette (insieme con altre configurazioni) la completa separazione fisica tra utenti e dati attraverso il tier 2 sicurezza implicita 27 policy enforcement su tier 2 28

8 Struttura della lezione Gli strati di software Sistemi distribuiti: ma perché? La piattaforma La architettura di un sistema distribuito layer logici tier fisici Struttura a livelli: il middleware eterogenea Es. Wintel, Intelx86/Linux, Sparc/Solaris, PowerPc/MaxOS Middleware nasconde l eterogeneità offre un modello di programmazione offre servizi ad alto livello (building-blocks) applications & services middleware sistema operativo computer & network hardware piattaforma Il middleware come servizio comune Tipi di middleware Middleware generale strumenti di comunicazione, di sicurezza, indiririzzamento, sincronizzazione, etc. Middleware orientato a specifici tipi di servizio accesso a basi di dati ODBC, JDPC gestione di transazioni Distributed Transaction Processing (X/Open) etc. etc

9 Modello basato su oggetti distribuiti Middleware basato su oggetti distribuiti (1) Basato sul modello orientato a oggetti (locale) Componenti: oggetto (stato, comportamnto ed identità) creato come istanza di una classe interfaccia servizi messi a disposizione dall oggetto connessione tra oggetti sincrona/asincrona, pull/push 33 Formalismi di definizione degli oggetti Interface Definition Language (IDL) Protocolli di interoperabilità trasformazione di oggetti in messaggi trasferibili sulla marshalling e relativa trasformazione inversa (unmarshalling) Intermediazione tra oggetti (object broker) individuazione e localizzazione Gestione di transazioni Atomicità, Consistenza, Isolamento, Durability (ACID) 34 Middleware basato su oggetti distribuiti (2) I limiti del middleware Intermediazione per scambio di messaggi (Message broker) gestori di code di messaggio Altri servizi di supporto gestione del ciclo di vita di un oggetto distribuito servizi di trasparenza fault, migrazione, eterogeneità, replica, etc. servizi di sicurezza servizi di monitoraggio, gestione e tuning Esempi: CORBA, Microsoft.NET, Enterprise Java Beans 35 In generale, ci sono aspetti del sistema distribuito che vanno trattati a livello application End-to-End argument (Saltzer, Reed, Clarke) Alcune funzioni legate alla comunicazione possono essere implementate completamente ed affidabilmente solo con la conoscenza e l aiuto delle applicazioni che si trovano agli end-point del sistema di comunicazione La conseguenza: fornire le funzioni da parte del sistema di comunicazione non è buona pratica introdurre completamente la funzione nello strato di comunicazione anche se può essere parzialmente implementata per ragioni di efficienza 36

10 L End-to to-end negli oggetti distribuiti Un esempio: file-transfer da A verso B La differenza tra I passi coinvolti: oggetti nello stesso processo oggetti in processi differenti Il principio dell End-to-End viene espanso (e confermato) dagli ambienti ad oggetti distribuiti una nota di Waldo (ed altri) nel campo del calcolo distribuito che vedremo in seguito a proposito di RMI oggetto processo A: il programma di FT usa il file system per leggere il file A: il programma di FT chiede al sistema di comunicazione di trasmettere il file, dividendolo in pacchetti La muove i pacchetti da A a B B: il sistema di comunicazione rimuove i pacchetti e li passa al programma di file transfer B: il programma di FT scrive i dati ricevuti sul proprio file system I possibili problemi Le possibili contromisure 1. il file originariamente scritto correttamente viene letto in maniera errata da A 2. il software del file system, il programma di FT, o il sistema di comunicazione può fare un errore nel copiare dati sul buffer (sia su A che su B) 3. il processore o la memoria possono avere un errore (transiente) sia su A che su B 4. il sistema di comunicazione può perdere bit/pacchetti 5. gli host possono andare in crash Rinforzare tutti i passi il passo 2 equivale a scrivere programmi corretti riconducibile al problema della fermata della Macchina di Turing Rendere bassa la probabilità di errore (in ogni passo) e reiterare (forza bruta) costoso End-to-End check and retry checksumcalcolata dalle applicazioni eventuale retry 39 40

11 Un esempio reale all MIT Una linea-guida.. ma con buon senso Reti locali connesse da gateway che usavano checksum sulla trasmissione I programmatori assumevano trasmissioni affidabili ma i dati non erano protetti durante la memorizzazione temporanea nei gateway Un errore di copia da un input buffer ad un output buffer in un gateway: relativamente poco frequente: 1 byte su 1 milione di byte ha corrotto diversi file nell intero sistema richiedendo un check manuale (end-to-end!) E semplicistico affermare che gli strati bassi della non devono avere alcun ruolo nella affidabilità sono in grado di migliorare notevolmente la efficienza Nel caso del File Transfer limitano le ritrasmissioni richieste dagli end-points Comunque non realizzano la perfetta affidabilità di un sistema distribuito Altre linee-guida simili Architetture RISC ridurre le istruzioni fornite dall hardware e spostarne la responsabilità verso gli strati superiori Il successo di Internet (TCP/IP) fosse stato progettato per circuiti virtuali (come lo erano SNA e TYMNET, altre reti degli anni 80) non avrebbe potuto supportare i protocolli request-response (tipo HTTP..!) i milioni di Internet Service Providers. 43