Definizione di sistema distribuito

Lezione del 2019-03-07 gio.

Secondo A. S. Tanenbaum e M. van Steen (vedi [TAVS2017]) possiamo considerare un Sistema Distribuito quando siamo in presenza di:

• un insieme di elementi di elaborazione autonomi;

• che appaiono ai loro utenti come un sistema coerente.

Altre definizioni;

• Leslie Lamport: «un sistema distribuito è tale se il guasto di un computer di cui non conoscete neppure l’esistenza può rendere inusabile il vostro»;

• Google University Code: «un sistema distribuito è un applicant che esegue un insieme di protocolli per coordinare le azioni di più processi su una rete, in modo tale che i componenti cooperino per eseguire un singolo task, o un piccolo insieme di task correlati».

Approfondiamo la definizione di Tanenbaum, considerando anche il seguente diagramma pubblicato nel testo:

In questo diagramma possiamo osservare anche la presenza di uno strato software di supporto (middleware) per la costruzione del sistema distribuito. Strato software che può avere diverse funzionalità. Ad esempio può assicurare la trasformazione di un dato tra formati diversi quando viaggia tra sistemi che utilizzano formati non compatibili tra loro 1. Oppure (o, anche) può assicurare funzioni per la sicurezza, persistenza del dato, transazionalità, … Questo, indipendentemente dal tipo di sistema operativo presente nei diversi computer che formano il sistema distribuito. Quindi il middleware fornisce trasparenza.

Esempi di middleware sono java RMI, Oracle Corba, IBM WebSphere, ed altri. Se, si ha a disposizione la API di un middleware, conviene studiarla ed utilizzarla, per evitare di scrivere da capo funzionalità già disponibili.

Insieme di elementi di elaborazione autonomi

Un singolo elemento di elaborazione, detto nodo, può essere inteso sia da un punto di vista hardware che software.

Inoltre un nodo hardware può avere capacità estremamente diversificate, da computer ad alte prestazioni, a sistemi su chip, quale ad esempio il Raspberry.

Il fatto che i nodi siano autonomi significa che sono in grado di perseguire l’obiettivo del sistema complessivo operando senza interagire continuamente con gli altri nodi, ma scambiandosi saltuariamente dei messaggi per sincronizzarsi e coordinarsi.

La presenza di nodi indipendenti, ci fa pensare che può mancare una coordinata temporale centralizzata 2, e questo può essere una area d’indagine importante.

Altra area d’indagine importante è l’appartenenza al gruppo: l’ingresso e l’uscita di un nodo dal gruppo di nodi che formano il sistema distribuito nel suo complesso.

Infine è necessario valutare l’organizzazione dei nodi. Nel senso che, per potersi inviare messaggi, avranno una rete di comunicazione, ma le regole per comunicare e operare in generale sono ad un livello superiore: una overlay network 3.

Sistema coerente

Per sistema coerente, si intende la capacità di mascherare la distribuzione dei sistemi (distribution transparency), ovvero fare in modo che l’utente non abbia necessità di sapere a quale sistema stia chiedendo il servizio 4.

Obiettivi per lo sviluppo di DS

Per quali motivi può essere utile sviluppare sistemi distribuiti? Per i seguenti:

• condivisione;

• trasparenza;

• apertura;

• scalabilità.

Se non vi è necessità di sposare uno o più dei precedenti requisiti, conviene utilizzare per lo sviluppo del sistema una architettura centralizzata. L’architettura centralizzata è estremamente più semplice da sviluppare rispetto le architetture distribuite: vi è un solo attore da tenere sotto controllo. Nelle architetture distribuite abbiamo più processi, ognuno dei quali gira per proprio conto, in parallelo agli altri.

Condivisione. La possibilità di accedere da remoto alle risorse è attraente:

• per motivi economici; ad es. una singola risorsa costosa può essere condivisa tra più utenti, senza dotarsi di tante risorse quanti sono gli utenti;

• per semplificare la collaborazione; ad es. con il file sharing.

Svantaggi dello sharing: la sicurezza può essere indebolita dalla condivisione delle risorse.

Trasparenza. La trasparenza di un sistema è dovuta ad una serie di aspetti contemporanei;

• accessibilità ai dati, nasconendo la loro rappresentazione e la modalità di accesso;

• la locazione della risorsa nasconde su quale sistema la risorsa risiede fisicamente; l’uso di URL in html é un esempio di trasparenza della locazione della pagina html;

• la migrazione e la rilocazione, nascondono il fatto che la risorsa può cambiare sistema su cui risiede fisicamente; la rilocazione è in grado di spostare una risorsa verso un altro sistema mentre l’utente la sta usando;

• la replica nasconde la possibilità che esistano più copie della risorsa, distribuite su sistemi diversi;

• la concorrenza fa in modo che una risorsa possa essere usata da più utenti contemporaneamente senza che uno si renda conto della presenza degli altri;

• la trasparenza in caso di guasto: ad es. se fallisce l’accesso tramite un indirizzo, potremmo non accorgercene.

È possibile ottenere un elevato grado di trasparenza? Questo obiettivo è difficile da raggiungere. La trasparenza è in contesa con:

• ritardi di comunicazione;

• la modifica delle repliche;

• mascherare danni transitori ai server.

Apertura. Un sistema distribuito è aperto quando i suoi servizi vengono specificati secondo regole standard, che descrivono sia la sintassi che la semantica; utilizzando:

• un linguaggio di descrizione dell’interfaccia (IDL: Interface Description Language) per descrivere la sintassi;

• il linguaggio naturale per descrivere la semantica.

Per ottenere l’interoperabilità e la portatilità, le specifiche devono essere complete e neutrali.

Inoltre è importante la flessibilità, ovvero la capacità di aggiungere e sostituire facilmente le componenti del sistema.

Scalabilità. È in relazione alla velocità. È la capacità di incrementare le performance quando si incrementano le risorse.

Questa capacità è necessaria quando aumenta la quantità di lavoro da effettuare. Infatti, usualmente, all’aumentare degli utenti, aumenta il tempo di risposta del sistema (alias processo). In particolare è disastroso un eventuale aumento esponenziale. Una crescita lineare è più accettabile.

Il fatto che all’aumentare degli utenti, il tempo di risposta del sistema aumenti linearmente, è già una importante componente per definire scalabile il sistema. Questo è un primo modo per definire la scalabilità.

Il secondo modo considera la possibilità che all’aumentare degli utenti, sia possibile aumentare le risorse di sistema per contenere il ritardo di risposta.

Aggiungere risorse può significare aumentare RAM, CPU, … Oppure aggiungere altri computer che cooperino al servizio abbassando i tempi di risposta. Questa soluzione è onerosa in caso di aggiornamento dei dati, che richiede la loro sincronizzazione. È perseguibile per sistemi in sola lettura o per aggiornamenti a bassa frequenza. Se gli aggiornamenti sono molto frequenti questa soluzione può essere non perseguibile: alla fine si ha più traffico dati per la sincronizzazione piuttosto che per rispondere agli utenti.

Ottenere una buona scalabilità è difficile. In particolare se il contesto cui ci si trova è inerentemente centralizzato.

Ad esempio, se si vuole la media di un insieme di misure sparse nel territorio, lo si deve fare in un servizio singolo che colleziona le misure da mediare.

Analogamente se vi è un singolo servizio di riferimento che deve essere necessariamente utilizzato.

Le tecniche per scalare possono essere le seguenti.

Evitare le comunicazioni (hiding communication). Ovvero diminuire i dati che transitano tra client e server delegando al client alcune attività, per inviare successivamente al server i soli risultati finali. L’esempio classico è quello della elaborazione delle form di input dati da parte dell’utente.

Distribuire l’elaborazione. Ad es. come nel caso del DNS, in cui è stato possibile scrivere l’algoritmo in modo parallelo, separando le competenze delle diverse zone.

La terza tecnica per scalare è la replica. Che può essere a sua volta divisa in due sotto tecniche: cache e replica vera e propria.

La prima differenza tra cache e replica consiste nel fatto che la replica crea copie complete del sistema, la cache copie parziali. Inoltre, di solito la replica avviene sui server, la cache invece sui client.

Si capisce allora perché la cache permette scalabilità. Se ho necessità di un dato già presente nel client, lo presento direttamente all’utente, senza impegnare né la rete dati, né il server.

Si noti che il servizio DNS scala utilizzando sia il meccanismo di distribuzione, sia quello di replica, sia la cache.

Problema fondamentale della cache: per essere efficace, deve essere aggiornata.

Problema fondamentale della replica: se un dato cambia, è necessario aggiornare tutti i server.

---

1

Ad esempio si pensi alla trasmissione di un dato numerico tra due computer che utilizzano rappresentazioni binare opposte: little endian piuttosto che big endian. Oppure al passaggio di una istanza di classe da una applicazione C# ad una applicazione Java.

2

In inglese: global clock.

3

Analogamente a quanto accade in una organizzazione umana. Ad esempio in una azienda, un impiegato ha un telefono sulla sua scrivania, per poter comunicare con altri impiegati. Ma usualmente non chiamerà il Direttore Generale dell’azienda, a meno che non sia un suo riporto diretto. L’impiegato opera in una rete organizzativa, ad es. gerarchica, che non coincide con la rete fisica disponibile per la comunicazione (quella telefonica).

4

Secondo Tanenbaum e van Steen un utente può essere conscio di avere a che fare con più sistemi. Non si spingono fino al punto di richiedere una single-system view. Ovvero un sistema che si presenta come se fosse composto da un singolo nodo di elaborazione.