Stili fondamentali per sistemi distribuiti - Luca...

Architettura dei Sistemi

Software

Luca Cabibbo

Luca Cabibbo ASWLuca Cabibbo ASW

Stili fondamentali per sistemi distribuiti

dispensa asw420

marzo 2018

Stili fondamentali per sistemi distribuiti1

The best thing about the futureis that is comes one day at a time.

Abraham Lincoln

Luca Cabibbo ASW

- Fonti

[SAP] Chapter 13, Architectural Tactics and Patterns

Cervantes, H. and Kazman, R. Designing Software Architectures: A Practical Approach. Addison Wesley, 2016.

Appendix A, Design Concepts Catalog

Coulouris, G., Dollimore, J., Kindberg, T., and Blair, G. Distributed Systems: Concepts and Design, fifth edition. Pearson, 2012.

Chapter 10, Peer-to-Peer Systems

Alonso, G., Casati, F., Kuno, H., and Machiraju, V. Web Services: Concepts, Architectures and Applications. Springer, 2004. Chapter 1, Distributed Information Systems


Luca Cabibbo ASW

- Obiettivi e argomenti

Obiettivi

presentare due stili architetturali fondamentali per sistemi distribuiti – lo stile client-server e lo stile peer-to-peer

Argomenti

introduzione

stile client-server

stile peer-to-peer

discussione


Luca Cabibbo ASW

* Introduzione

Molti sistemi distribuiti sono basati su (uno di) due stili architetturali fondamentali – lo stile client-server e lo stile peer-to-peer

lo stile client-server consente ad un insieme di client distribuiti di accedere ai servizi e alle risorse computazionali condivise offerte da uno o più server centralizzati

lo stile peer-to-peer consente ad un insieme di peer distribuiti di condividere tra di loro dei servizi e delle risorse computazionali (che sono dunque decentralizzate)

questi stili possono essere applicati in numerose varianti

inoltre, altri stili architetturali per sistemi distribuiti possono essere considerati delle evoluzioni di questi stili di base


Luca Cabibbo ASW

Risorse computazionali

Entrambi gli stili – client-server e peer-to-peer – consentono l’accesso o la condivisione di “servizi” e “risorse computazionali”

questi termini generici indicano una varietà di elementi diversi –ad esempio

risorse di memorizzazione – per la gestione e l’accesso a dati – come un file system, una base di dati relazionale o una base di dati non relazionale (ad es., un insieme di coppie chiave-valore)

risorse di elaborazione – la capacità di eseguire operazioni, servizi, applicazioni o computazioni

altre risorse – come la condivisione di una stampante o di hardware specializzato


Luca Cabibbo ASW

Risorse computazionali

Entrambi gli stili – client-server e peer-to-peer – consentono l’accesso o la condivisione di “servizi” e “risorse computazionali”

lo stile client-server e peer-to-peer differiscono soprattutto nel posizionamento e nella gestione di questi servizi e di queste risorse

nello stile client-server, servizi e risorse sono localizzate in un singolo server o in un piccolo numero di server, gestiti in modo centralizzato

nello stile peer-to-peer, servizi e risorse sono invece distribuite su una comunità di peer, in modo decentralizzato


Luca Cabibbo ASW

* Stile client-server

Contesto

ci sono delle risorse computazionali oppure dei servizi che devono essere condivisi

un gran numero di client distribuiti vogliono accedere a queste risorse e servizi

è necessario controllare l’accesso a queste risorse e servizi, e la qualità del servizio

Problema

bisogna gestire e consentire l’accesso a un insieme di risorse computazionali e servizi condivisi

si vogliono sostenere la modificabilità e il riuso di queste risorse e servizi

si vogliono sostenere scalabilità e disponibilità nell’accesso a queste risorse e servizi


Luca Cabibbo ASW

Stile client-server

Soluzione (struttura)

organizza il sistema come

un insieme di servizi – ciascun servizio rappresenta una funzionalità oppure una risorsa computazionale – ogni servizio è caratterizzato da un’interfaccia, basata su un connettore che è un protocollo richiesta/risposta

un insieme di server – ciascun server è un componente (un processo) in grado di fornire/erogare uno o più servizi ai suoi client

un insieme di client – ciascun client è un componente (un processo) interessato a fruire di uno o più servizi da uno o più server


Luca Cabibbo ASW

Stile client-server

Soluzione (dinamica)

i client (sono attivi) interagiscono invocando i servizi dai server, tramite i relativi protocolli richiesta/risposta

un client inizia l’interazione con un server per un servizio, inviandogli una richiesta ed aspettando una risposta

i server (sono reattivi) hanno la responsabilità di erogare i servizi specifici richiesti dai client

un server attende richieste dai client e, quando riceve una richiesta da un client, eroga il servizio specifico richiesto dal client e gli fornisce una risposta

le interazioni tra client e server avvengono sulla base del connettore per il protocollo richiesta/risposta del servizio


Luca Cabibbo ASW

Stile client-server



confine tra processi

Luca Cabibbo ASW

Stile client-server


ogni server può essere acceduto in modo concorrente da molti client (indipendenti tra di loro)

sono in genere presenti una molteplicità di client

inoltre, questi client possono essere istanze di una o più tipologie di client (si pensi, ad es., alle tipologie di browser web esistenti)

i server sono indipendenti dai loro client – grazie a questo, è possibile aggiungere nuovi client al sistema, senza dover effettuare modifiche sui server


Server

:Client:ClientClient


Luca Cabibbo ASW

Stile client-server

Esistono numerose varianti di questo stile architetturale – ad esempio

ciascun servizio può essere erogato da un singolo server centralizzato oppure replicato ed erogato da più server, distribuiti su più nodi

alcuni componenti possono agire sia da client (di alcuni servizi) che da server (di altri servizi)


:Server:ServerServer:Client:ClientClient

IntermediateServer

BackEndServer


Luca Cabibbo ASW

Stile client-server

Discussione

l’accesso alle risorse e ai servizi condivisi avviene in genere in un singolo server o in un insieme di pochi server, che vengono collocati e governati centralmente

questo sostiene la possibilità di controllare l’accesso alle risorse e la qualità dei servizi

le risorse e i servizi possono anche essere distribuiti ed eventualmente replicati su più nodi fisici

questo sostiene la disponibilità e la scalabilità

la centralizzazione delle risorse e dei servizi consente una loro modifica in una singola locazione o comunque in un numero limitato (e di solito piccolo) di locazioni

questo sostiene la modificabilità di risorse e servizi

tuttavia, la modifica dei client (che non sono centralizzati) può essere invece problematica


Luca Cabibbo ASW

Stile client-server

Dunque, nello stile client-server

due tipi di componenti – client e server

un connettore per l’interazione tra client e server – implementa un protocollo richiesta/risposta, usato per l’invocazione di un servizio

questo stile separa le applicazioni client dai servizi che i client devono usare


Luca Cabibbo ASW

Stile client-server

Esempi di uso

molte applicazioni e servizi di Internet, file system distribuiti, basi di dati,...

Conseguenze – in prima approssimazione

condivisione di risorse, centralizzazione di elaborazione complessa o sensibile, possibilità di sostenere scalabilità e disponibilità, ...

overhead della comunicazione, sicurezza, …

se non è replicato, il server potrebbe essere un collo di bottiglia per prestazioni e scalabilità ed un punto di fallimento singolo per la disponibilità


Luca Cabibbo ASW

- Pattern di deployment

Nello stile client-server, l’assunzione comune è che gli elementi client e server siano dei componenti software runtime (e non hardware) – ovvero, dei processi logici

lo stile client-server viene comunemente adottato nel contesto della vista funzionale/logica o della vista della concorrenza

Inoltre, esistono diversi pattern di deployment (dispiegamento o rilascio) che descrivono le modalità di applicazione dello stile client-server anche con riferimento alla vista di deployment

processi diversi possono essere allocati su processori e su nodi (computer) diversi

è anche possibile che più processi diversi siano allocati su uno stesso nodo


Luca Cabibbo ASW

Livelli (tier)

I pattern di deployment distribuiti dello stile client-server (C/S) sono basati sulla nozione di livello (tier)

un livello (tier) è un nodo o un gruppo di nodi su cui sono rilasciati alcuni processi di un sistema C/S

un sistema C/S è organizzato come una sequenza di livelli

ciascun livello eroga servizi (ovvero, funge da server) nei confronti del livello precedente

ciascun livello richiede servizi (ovvero, funge da client) nei confronti del livello successivo

i livelli sono comunemente organizzati in base al tipo di servizio (responsabilità) che forniscono

Si tratta di un’interpretazione particolare dell’architettura a strati

in cui gli strati corrispondono all’allocazione di client e server (processi) su nodi (o gruppi di nodi)


Luca Cabibbo ASW

Pattern di deployment

Alcuni pattern di deployment comuni

client-server a due livelli

client-server a tre livelli


Client Tier

Client

Server Tier

Serverprocesso

nodo

Client Tier

Client

App Server Tier

AppServer

Database Tier

DBServer

Luca Cabibbo ASW

Pattern di deployment

Alcuni pattern di deployment comuni

client-server a quattro livelli


Client Tier

Client

App Server Tier

AppServer

Database Tier

DBServer

Web Tier

Web Server

Luca Cabibbo ASW

Livelli e strati

Di solito, le responsabilità funzionali di un sistema client-server, rilasciato su due o più livelli, sono organizzate a strati – nel senso che

nella vista funzionale, il sistema adotta un’architettura a strati

gli strati sono organizzati in base al livello di astrazione

nella vista di deployment, il sistema adotta un’architettura a livelli

i livelli sono organizzati in base al tipo di servizio (responsabilità) che forniscono

inoltre, il software in ciascun livello è spesso organizzato internamente a strati

È pertanto utile discutere alcune corrispondenze comuni tra livelli e strati nello stile client-server

assumiamo che le responsabilità principali del sistema siano presentazione, logica applicativa e gestione dei dati


Luca Cabibbo ASW

Stile client-server a due livelli

Il rilascio a due livelli è il più semplice tra i pattern di deploymentper lo stile client-server

ci sono due varianti principali per le architetture C/S a due livelli

modello thin-client

il server è responsabile della logica applicativa e della gestione dei dati

il client è responsabile solo della presentazione

modello thick-client (o fat-client)

il server è responsabile della gestione dei dati

il client è responsabile della presentazione e della logica applicativa


Client Tier

Client

Server Tier

Server

Luca Cabibbo ASW

Stile client-server a due livelli

Conseguenze

popolare negli anni ’80 – il modello thin-client è stata una soluzione semplice per la migrazione dai sistemi legacy (basati su mainframe) ad un’architettura distribuita client-server

il modello thick-client ha saputo utilizzare l’aumentata potenza di calcolo dei PC degli anni ‘80

possibili più client – di tipo diverso

semplice gestire l’aggiornamento dei server

l’architettura client-server a due livelli (in entrambe le varianti) è in genere poco scalabile

gestire l’aggiornamento dei client può essere problematico


Luca Cabibbo ASW

Stile client-server a tre livelli

Nel rilascio a tre livelli, lato server l’applicazione viene rilasciata in un livello separato da quello che ospita la base di dati

il database server è responsabile della gestione dei dati

l’application server è responsabile della logica applicativa

il client è responsabile della presentazione


Client Tier

Client

App Server Tier

AppServer

Database Tier

DBServer

Luca Cabibbo ASW

Stile client-server a tre livelli

Conseguenze

consente migliori prestazioni – rispetto al modello thin-client –poiché consente una migliore distribuzione del carico di elaborazione – questo può compensare il maggior overheadnella comunicazione

supporto per disponibilità e scalabilità (scalabilità “orizzontale”) – il livello intermedio può essere costituito da un cluster di nodi server

più semplice da gestire – rispetto al modello fat-client

maggior complessità e maggior overhead nella comunicazione

può essere difficile decidere come allocare le responsabilità ai diversi livelli – inoltre è complesso e costoso cambiare questa decisione dopo che il sistema è stato costruito

gestire l’aggiornamento dei client può essere problematico


Luca Cabibbo ASW

Stile client-server a quattro livelli

Nel rilascio a quattro livelli, inoltre, la responsabilità di presentazione viene suddivisa

il livello web gestisce e “genera” la presentazione

il livello client è basato su un browser web, che “visualizza” la presentazione

uno stile popolare oggi, grazie alla disponibilità di opportune piattaforme e framework – ad es., Java EE e .NET


Client Tier

Client

App Server Tier

AppServer

Database Tier

DBServer

Web Tier

Web Server

Luca Cabibbo ASW

Esempio – piattaforma Java EE


Luca Cabibbo ASW

Stile client-server a quattro livelli

Conseguenze

architettura flessibile, che supporta prestazioni, disponibilità e scalabilità

supporta la sicurezza di applicazioni che devono essere accedute pubblicamente – perché il livello web può risiedere in una rete accessibile pubblicamente, mentre i livelli dell’applicazione e della base di dati possono risiedere in una rete privata

semplice gestire l’aggiornamento di tutte le responsabilità

la complessità è ancora maggiore


Luca Cabibbo ASW

- Opzioni per il client

Abbiamo già visto alcune varianti dello stile client-server

ci sono delle ulteriori varianti di questo stile architetturale, che fanno riferimento soprattutto alle caratteristiche della presentazione e dei client

web application

rich client application

rich internet application

mobile application

in ogni caso, queste varianti differiscono non solo nelle caratteristiche dei client, ma (di conseguenza) anche nelle responsabilità lato server e nelle modalità di interazione tra client e server


Luca Cabibbo ASW

Web application

Web application

il client è un browser web eseguito nel nodo client di un utente

il client comunica con il server web usando il protocollo HTTP

un tipo di applicazione da considerare quando

l’applicazione deve essere accessibile su Internet

è sufficiente un’interfaccia utente semplice – non è richiesta un’interfaccia utente “ricca”

si vuole portabilità dell’interfaccia utente

si vuole usare l’applicazione senza dover installare (e poi aggiornare) nei nodi client nessun software specifico per l’applicazione

si vogliono usare solo un minimo di risorse lato client


Luca Cabibbo ASW

Rich Client Application

Rich Client Application

il client (specifico per l’applicazione) viene installato ed eseguito sul nodo client dell’utente

il client comunica con i servizi remoti dell’applicazione mediante un protocollo specifico

l’interfaccia utente può fornire un’esperienza per l’utente ricca, altamente interattiva, e con elevate prestazioni


si vuole un’interfaccia utente “ricca” ed altamente interattiva

è possibile installare nei nodi client del software specifico per l’applicazione

si vogliono sfruttare le risorse del nodo client (ad es., una scheda grafica)

si vuole consentire l’uso dell’applicazione anche in modo disconnesso o con connettività intermittente


Luca Cabibbo ASW

Rich Internet Application

Rich Internet Application

il client (specifico per l’applicazione) è in genere codice che può essere scaricato da un server web ed eseguito nel browser web nel nodo client di un utente (ad es., un applet)

sono applicazioni più complesse delle applicazioni web – che supportano un’interazione ricca con l’utente


si vuole un’interfaccia utente “ricca” ed altamente interattiva

si vuole usare l’applicazione senza dover installare (e poi aggiornare) nei nodi client nessun software specifico per l’applicazione

si vogliono poter eseguire delle elaborazioni lato client

lato client è accettabile un accesso limitato alle risorse locali


Luca Cabibbo ASW

Mobile application

Mobile application

un’applicazione (app) mobile viene eseguita su un dispositivo mobile

le applicazioni mobili operano spesso come client di servizi remoti, mediante una connessione mobile (spesso inaffidabile o intermittente)

le app mobili sono di solito realizzate come rich client application oppure come web application


si vuole che l’applicazione venga eseguita su un dispositivo mobile

si vuole consentire l’uso dell’applicazione anche in caso di connettività poco affidabile o intermittente

è accettabile eseguire delle elaborazioni lato client, anche se con risorse limitate


Luca Cabibbo ASW

- Servizi, interfacce e protocolli

Nello stile client-server, i servizi offerti da un server vengono “pubblicati” mediante un’interfaccia – talvolta chiamata anche API(application programming interface)

un’interfaccia è basata su un connettore, che definisce il protocollo e il formato delle richieste e delle risposte scambiate nelle interazioni tra il server e i suoi client

l’applicazione dello stile client-server richiede sempre di definire l’interfaccia di ogni servizio e il relativo protocollo

ci sono numerose possibilità – ad esempio, RPC, RMI, CLI (ad es., SQL), HTTP/HTML, RMI


Luca Cabibbo ASW

- Interfacce fornite e interfacce richieste

Nello stile client-server, i client richiedono l’erogazione di servizi offerti dai server

i servizi offerti da un server costituiscono l’interfaccia fornita del server

i servizi richiesti da un client costituiscono l’interfaccia richiesta del client

Inoltre

un server può erogare più servizi – ovvero, avere più interfacce fornite

un client può richiedere più servizi – ovvero, avere più interfacce richieste

in un’architettura multi-livello, alcuni componenti possono avere sia interfacce fornite che interfacce richieste


Luca Cabibbo ASW

- Servizi stateless e stateful

In un sistema software, un servizio è stateful se l’esecuzione di un’operazione dipende dallo stato della conversazione (o sessione) con il client che ha richiesto l’operazione – altrimenti il servizio è stateless

in genere, lo stato di cui si parla si riferisce alla capacità del sistema (nella sua interezza) di ricordare lo stato di ciascuna specifica conversazione (sessione) con ogni client – e non allo stato “complessivo” del servizio o del sistema

Si tratta di una caratteristica importante dei servizi

infatti, se un servizio è stateful, allora il sistema deve gestire (da qualche parte) lo stato delle sessioni con i propri client

se invece un servizio è stateless, allora ogni istanza/replica del servizio può rispondere alle richieste di qualunque client

questo ha impatto sul livello di accoppiamento e sulla scalabilità del sistema


Luca Cabibbo ASW

Servizi stateful

Un servizio è stateful se il sistema mantiene (qualche) informazione di stato circa le diverse richieste successive da parte di uno stesso client nell’ambito di una sessione (o conversazione)

utile quando la gestione di una richiesta deve poter dipendere dalla storia delle richieste precedenti da parte di quel client

ad es., il server potrebbe gestire un’istanza del servizio per ciascun client, per tutta la durata della sua sessione

dal punto di vista del programmatore, la gestione delle informazioni di sessione potrebbe essere semplice

tuttavia, ci potrebbe essere un impatto negativo sulla scalabilità – poiché ogni istanza del servizio occupa risorse


Client 1

Proxy

Service Host

Instance 1

Instance 2

Client 2

Proxy

Luca Cabibbo ASW

Servizi stateless

Un servizio è stateless se il sistema non deve mantenere informazioni di stato su ciò che avviene tra richieste successive di uno stesso client

adeguato quando la gestione di una richiesta è indipendente dalla storia delle richieste precedenti da parte di quel client

ad es., un servizio di previsioni del tempo

ogni richiesta può essere gestita indipendentemente dalle altre richieste da parte dello stesso client

le risorse del server possono essere condivise tra i diversi client – il server può fare pooling di più istanze del servizio

impatto positivo sulla scalabilità


Client 1

Proxy

Service Host

Instance 1

Instance 2

Instance 3

Client 2

Proxy

t=0 t=0

t=1t=1

Luca Cabibbo ASW

Implementazione di servizi stateful

Sono possibili diverse opzioni per la gestione dello stato delle sessioni di un servizio stateful

stato delle sessioni nell’application server

ad es., usando tecnologie stateful oppure dedicando ciascuna istanza del servizio a un singolo client

stato delle sessioni nei client

ad es., come cookie nel browser dell’utente o tramite la riscrittura di URL

stato delle sessioni nella base di dati ad es., il server assegna un sessionId alla prima richiesta di

un client – il client ripete il proprio sessionId in ogni richiesta successiva – il server ritrova lo stato della sessione dalla base di dati, esegue l’operazione, aggiorna lo stato della sessione nella base di dati e infine risponde al client

stato delle sessioni in una cache (in memoria)


Luca Cabibbo ASW

Implementazione di servizi stateful

Sono possibili diverse opzioni per la gestione dello stato delle sessioni di un servizio stateful

stato delle sessioni nell’application server (AS)

stato delle sessioni nei client

stato delle sessioni nella base di dati

stato delle sessioni in una cache (in memoria)

le diverse opzioni hanno caratteristiche e conseguenze diverse

nel primo caso, l’implementazione del servizio nell’AS è stateful – negli altri tre casi, l’implementazione del servizio nell’AS è stateless (anche se il servizio è sempre stateful)

sono diverse le conseguenze in termini di prestazioni, scalabilità e disponibilità – ma anche di semplicità/complessità dell’implementazione e dell’infrastruttura di middleware richiesta


Luca Cabibbo ASW

- Ulteriori considerazioni e varianti

Nello stile client-server, l’invocazione dei servizi è di solito sincrona

ovvero, il client effettua una richiesta – e si blocca fino a quando la richiesta non è stata servita

tuttavia, alcuni servizi possono essere invocati in modo “asincrono”

ad es., un browser web non si blocca in attesa dei dati che ha richiesto


Luca Cabibbo ASW

Ulteriori considerazioni e varianti

Inoltre, nello stile client-server l’interazione è di solito iniziata dai client – dunque, è asimmetrica

il client deve conoscere l’identità del server – ma il server non deve conoscere l’identità dei suoi client

tuttavia, è possibile che un server possa iniziare delle azioni nei confronti dei suoi client

sulla base di meccanismi di registrazione a procedure di notifica o callback


Luca Cabibbo ASW

- Note terminologiche

Prima di concludere, è importante discutere alcuni modi comuni di utilizzare i termini “client” e “server”

nello stile client-server (questa sezione), per descrivere l’organizzazione fondamentale di un sistema distribuito

talvolta, vengono invece usati per descrivere, localmente, la relazione tra una coppia di elementi architetturali

un elemento client può chiedere servizi ad un elemento server (ma non viceversa)

talvolta, vengono usati per descrivere il ruolo rivestito da una coppia di elementi nell’ambito di una singola interazione

un elemento (nel ruolo di client) chiede servizi ad un altro elemento (nel ruolo di server) – nelle interazioni successive, questi elementi potrebbero anche interagire in modo diverso

talvolta, vengono usati per indicare degli elementi fisici (nodi) –anziché degli elementi runtime (processi)


Luca Cabibbo ASW

* Stile peer-to-peer

I sistemi peer-to-peer (P2P) sono sistemi distribuiti e decentralizzati, basati su una rete di nodi (chiamati peer) che condividono le proprie risorse di calcolo – come capacità di memorizzazione, contenuti, processori, banda di rete, …

i sistemi client-server forniscono l’accesso a risorse gestite da un singolo server o da un insieme di pochi server centralizzati –la scalabilità è però limitata dalla capacità computazionale di questi server e dalla connettività di rete disponibile

i sistemi P2P forniscono invece l’accesso a risorse gestite da tutti i nodi di una rete – la rete potrebbe essere una rete aziendale o anche Internet – questi nodi (potrebbero essere tanti) potrebbero dunque avere complessivamente una capacità computazionale molto alta o illimitata

lo scopo dei sistemi P2P è sfruttare le risorse di un gran numero di nodi per l’adempimento di uno specifico compito od obiettivo


Luca Cabibbo ASW

Esempi di sistemi peer-to-peer

Alcuni esempi di sistemi peer-to-peer

condivisione di contenuti (file sharing)

la categoria più nota, utilizzata non solo per condividere film, serie TV e musica, ma anche per migliorare la condivisione di contenuti legali – ad es., Ubuntu e aggiornamenti di Windows 10

comunicazione e collaborazione

ad es., chat – comunicazione diretta e real-time

calcolo distribuito

ad es., seti@home, grid, cloud – per condividere capacità di memorizzazione e calcolo (processori)

sistemi per la gestione e la replicazione di dati distribuiti

ad es., alcuni sistemi di basi di dati non relazionali

ad es., sistemi per la gestione di blockchain, per gestire le transazioni di criptovalute, come i bitcoin


Luca Cabibbo ASW

Caratteristiche dei sistemi peer-to-peer

Un aspetto fondamentale dei sistemi P2P è la capacità di trattare l’instabilità come la norma – l’instabilità è dovuta a peer che si possono connettere e sconnettere indipendentemente al/dal sistema – questi sistemi sono capaci di riorganizzarsi autonomamente, e di sostenere (per quanto possibile) disponibilità e scalabilità

a tal fine, questi sistemi sfruttano la replicazione delle risorse

per far sì che l’accesso alle risorse possa avvenire con probabilità alta – anche se non sempre è possibile garantire l’accesso a delle specifiche risorse individuali

per distribuire e bilanciare il carico di memorizzazione e di elaborazione tra tutti i peer


Luca Cabibbo ASW

Stile peer-to-peer

Contesto

ci sono diverse entità distribuite – ciascuna entità fornisce delle proprie risorse computazionali

queste entità devono poter cooperare e collaborare per fornire dei servizi a una comunità distribuita di utenti

ciascuna di queste entità è considerata ugualmente importante nel poter avviare interazioni con le altre entità

Problema

si vogliono organizzare un insieme di entità computazionali distribuite affinché possano condividere i loro servizi e risorse

queste entità sono tra di loro “equivalenti” o comunque “pari”

si vogliono connettere queste entità sulla base di un protocollo comune

si vogliono sostenere scalabilità e disponibilità


Luca Cabibbo ASW

Stile peer-to-peer

Soluzione

organizza il sistema (o il servizio) sulla base di un insieme di componenti peer che interagiscono direttamente tra di loro come “pari” (“peer”)

ciascun peer è un componente software runtime (un processo) – tuttavia, il termine peer viene talvolta usato per indicare anche un nodo che ospita un tale componente software

i peer sono tutti ugualmente importanti – nessun peer o gruppo di peer deve (dovrebbe) essere critico per la salute del sistema/servizio


Luca Cabibbo ASW

Stile peer-to-peer

Soluzione

la comunicazione avviene direttamente da peer a peer (“peer-to-peer”)

la comunicazione tra peer è di solito basata su delle interazioni richiesta-risposta – ma senza l’asimmetria rigida dello stile client-server

ciascun peer fornisce (offre) e richiede (consuma) servizi simili, utilizzando uno stesso protocollo

ogni peer può agire sia come “client” che come “server” del servizio – ogni componente può interagire con ogni altro componente, chiedendogli i suoi servizi – un’interazione può essere avviata da ognuno dei partecipanti

talvolta l’interazione consiste solo nell’inoltro di dati – senza il bisogno di una risposta


Luca Cabibbo ASW

Stile peer-to-peer

Lo stile peer-to-peer riflette i meccanismi inerentemente bidirezionali che possono sussistere tra due o più generiche entità (ad es., persone o organizzazioni) che tra loro interagiscono come pari

ciascun peer fornisce e consuma servizi simili

ha un’interfaccia (fornita) per consentire agli altri peer di consumare da lui questi servizi

ha un’interfaccia (richiesta) per poter consumare gli stessi servizi da altri peer

i connettori peer-to-peer implicano dunque delle interazioni bidirezionali

i servizi sono relativi alla gestione delle risorse che si vogliono condividere

ad es., dati o risorse computazionali


Luca Cabibbo ASW

Rete peer-to-peer

Una rete peer-to-peer è l’insieme dei peer di un sistema (peer-to-peer) e dei collegamenti tra di essi

ogni collegamento indica una relazione di adiacenza “logica” (“conoscenza”) tra peer – questi collegamenti possono variare dinamicamente nel tempo

anche l’insieme dei peer connessi alla rete può variare nel tempo


peerpeer peer

peer

peer peer

peer

Luca Cabibbo ASW

- P2P – Esempi

Prima di andare avanti, è utile avere in mente alcune applicazioni di esempio dello stile peer-to-peer – con le risorse condivise dai peer ed alcune possibili interazioni tra peer

file sharing

i peer condividono la propria capacità di memorizzare file

un peer può

aggiungere localmente un file

cercare un file su altri peer

scaricare un file (o un frammento di file) da altri peer (poi rimarrà memorizzato localmente)

cancellare localmente un file

inoltre, ogni peer può (ovviamente) eseguire o supportare operazioni richieste da altri peer


Luca Cabibbo ASW

P2P – Esempi


esecuzione di task in un cluster

i peer del cluster condividono le proprie risorse computazionali e la propria capacità di eseguire dei task (ovvero, computazioni come servizi, componenti, job o contenitori)

un peer può

installare localmente un task

eseguire un task richiesto da un altro peer

chiedere l’esecuzione di un task ad altri peer

inoltre, ogni peer può (ovviamente) eseguire o supportare operazioni richieste da altri peer


Luca Cabibbo ASW

P2P – Esempi


gestione di una base di dati distribuita (un insieme di coppie chiave-valore)

i peer condividono la propria capacità di memorizzazione –ogni peer memorizza solo un sottoinsieme delle coppie della base di dati

ciascun peer (magari su richiesta da parte di altri componenti) può eseguire operazioni CRUD (Create-Read-Update-Delete) sulla base di dati

inserire una nuova coppia, cercare il valore associato ad una chiave, aggiornare il valore associato ad una chiave, cancellare una coppia

per eseguire un’operazione richiesta, un peer può (ovviamente) interagire anche con altri peer


Luca Cabibbo ASW

- P2P in reti non controllate

Lo stile peer-to-peer è stato spesso utilizzato in reti P2P non controllate – ad es., nel caso del file sharing

i peer, gestiti dagli utenti (non da un’organizzazione che deve condividere delle risorse per fornire un servizio), sono liberi di collegarsi alla rete P2P, eseguire le operazioni di interesse, e poi abbandonare la rete P2P in qualunque momento

in questo caso, però, non è in genere possibile fornire garanzie sull’effettiva condivisione delle risorse – ad esempio

un file (poco popolare) potrebbe non essere più accessibile, perché è stato cancellato localmente da tutti i peer collegati alla rete – e nessun peer che lo memorizza ancora è attualmente collegato alla rete

per limitare questi problemi, vengono in genere offerti ai peer degli “incentivi” in relazione al loro supporto alla condivisione dei file – tuttavia, questi problemi non possono essere eliminati del tutto


Luca Cabibbo ASW

- P2P in reti controllate

Lo stile peer-to-peer può essere usato vantaggiosamente anche in reti P2P controllate – come un insieme di nodi del data center di un’organizzazione

in questo caso, è in genere possibile fornire garanzie sull’effettiva condivisione delle risorse

infatti, in una rete controllata, un nodo non si disconnette per il capriccio di un utente, ma solo quando si guasta

l’organizzazione potrebbe comunque aggiungere o rimuovere dinamicamente nodi alla/dalla rete – per raggiungere i livelli di scalabilità e disponibilità desiderati

inoltre, in questo caso, è possibile (ed utile) ragionare sul livello di replicazione delle risorse e sulla loro localizzazione, per cercare di garantire la disponibilità delle risorse, una distribuzione bilanciata del carico di lavoro, e di ridurre overhead non necessari


Luca Cabibbo ASW

- Scenari

Passiamo ora ad esaminare alcuni scenari comuni per lo stile peer-to-peer

si faccia attenzione, poiché le implicazioni di questi scenari sono diverse in relazione alle differenti applicazioni ed al fatto che la rete P2P sia controllata o meno


Luca Cabibbo ASW

Scenari

Avvio

un peer si connette alla rete peer-to-peer (P2P)

per scoprire e conoscere altri peer con cui poter interagire

ma anche per comunicare la propria presenza (farsi scoprire e farsi conoscere), comunicando così la disponibilità a condividere le proprie risorse e di interagire con altri peer

il peer potrebbe anche essere dotato di un proprio insieme iniziale di contenuti – ad es., un insieme di file memorizzati localmente

la possibilità di aggiungere dinamicamente peer (ciascuno con le proprie risorse) alla rete P2P favorisce la scalabilità (orizzontale) del servizio


Luca Cabibbo ASW

Scenari

Richiesta di servizi (accesso a risorse)

un peer può poi avviare delle interazioni per ottenere dei servizi – chiedendo questi servizi ai peer che conosce

un servizio comune nelle reti peer-to-peer è la ricerca di una risorsa – per trovare uno o più peer che possiedono la risorsa cercata – ad es., un certo file, una coppia di cui si conosce la chiave o la capacità di eseguire un task

un peer che riceve una tale richiesta, oltre a cercare la risorsa localmente, può eventualmente propagare la richiesta ad altri peer adiacenti – di solito per un numero limitato di hop


Luca Cabibbo ASW

Scenari



un altro servizio comune è il consumo di una risorsa – ad es., scaricare un file o chiedere l’esecuzione di un task

una richiesta di questo tipo può essere diretta ad un solo peer specifico, tra quelli che possiedono la risorsa

tuttavia, se la risorsa da consumare è replicata e/o frammentata su più peer (è un caso comune nelle reti per il file sharing), allora è anche possibile che un peer consumi la risorsa da più peer, in modo concorrente – questo sostiene prestazioni, una distribuzione del carico tra i peer e tolleranza ai guasti

inoltre, il peer che riceve una risorsa la può anche memorizzare localmente, per poterla condividere con altri peer (è un caso comune nelle reti per il file sharing)


Luca Cabibbo ASW

Scenari



un altro possibile servizio è l’aggiunta di una risorsa – ad es., un file, una coppia chiave-valore o un nuovo task

ci sono diverse possibilità, ad esempio

la risorsa viene inizialmente aggiunta solo localmente dal peer che riceve la richiesta

oppure, se il peer non può soddisfare la richiesta, allora gira la richiesta ad un altro peer

oppure, il peer che riceve la richiesta aggiunge la risorsa localmente, e poi gira la richiesta anche ad altri peer, per fare in modo che la risorsa sia replicata in modo opportuno


Luca Cabibbo ASW

Scenari

Rimozione di peer

è anche possibile che un peer (con le sue risorse) venga rimosso dinamicamente dalle rete P2P

questo può avvenire per volontà dell’utente che controlla il peer, oppure involontariamente (a seguito di un guasto)

la rimozione di un peer non dovrebbe compromettere la disponibilità dei servizi offerti dalla rete peer-to-peer

questo è possibile solo se i diversi peer hanno capacità sovrapponibili – ovvero, se ogni risorsa (dati o servizio) è fornita da (replicata su) più peer

se un peer che possiede una risorsa viene rimosso, si può ancora ottenere quella risorsa dai peer rimanenti (se la rete P2P contiene almeno una replica della risorsa)

inoltre, come detto, la replicazione delle risorse consente la distribuzione del carico


Luca Cabibbo ASW

Scenari

Super-nodi

alcune reti P2P hanno peer specializzati (chiamati super-nodi o super-peer) che forniscono servizi comuni o speciali agli altri peer – ad es., la ricerca o l’autenticazione


Luca Cabibbo ASW

Discussione

Alcune conseguenze dello stile peer-to-peer

supporta la condivisione di risorse tra un gran numero di nodi

può sostenere disponibilità, scalabilità, distribuzione del carico e prestazioni – soprattutto in reti controllate, come i nodi di un data center in ambienti grid o cloud

tuttavia, poiché i sistemi peer-to-peer sono fortemente decentralizzati, è più complesso (o talvolta impossibile) gestire la sicurezza, la consistenza dei dati, gestire e controllare la disponibilità dei dati e dei servizi, effettuare backup e recovery

in molti casi è difficile fornire garanzie di qualità – soprattutto nelle reti non controllate, in cui i peer possono venire e andare a piacere


Luca Cabibbo ASW

Esempio: basi di dati distribuite

Alcuni sistemi per la gestione di dati distribuiti (ad es., i database NoSQL o le object cache) in un cluster usano una combinazione dei seguenti meccanismi per sostenere scalabilità e disponibilità

replicazione dei dati su più nodi del cluster – insieme a una politica per garantire la consistenza delle diverse copie dei dati

replicazione master-slave (non è P2P) – la replicazione avviene sulla base di un’organizzazione gerarchica dei nodi

replicazione peer-to-peer – una soluzione spesso più efficace per la propagazione degli aggiornamenti – fornisce inoltre una miglior tolleranza ai guasti, e scalabilità orizzontale (possibilità di aggiungere dinamicamente nodi al cluster)

distribuzione (sharding) dei dati sui nodi del cluster

l’uso di tecniche di hashing distribuito (DHT) consente di combinare distribuzione e replicazione dei dati


Luca Cabibbo ASW

- Note terminologiche

Prima di concludere, è importante discutere alcuni modi comuni di utilizzare i termini “peer” e “peer-to-peer”

nello stile peer-to-peer (questa sezione), per descrivere l’organizzazione fondamentale di un sistema distribuito

talvolta, vengono invece usati per descrivere, localmente, la relazione tra una coppia di elementi architetturali

due elementi sono in una relazione peer-to-peer se ciascun elemento può iniziare interazioni nei confronti dell’altro

tuttavia, questo non sempre vuole dire che i due elementi implementano una stessa interfaccia – piuttosto, potrebbe voler dire che i due elementi comunicano con uno stesso protocollo (ad es., si scambiano messaggi) oppure semplicemente che non sono in una relazione client-server


Luca Cabibbo ASW

* Discussione

Gli stili architetturali descritti in questa dispensa – lo stile client-server e lo stile peer-to-peer – sono alla base di molti sistemi distribuiti attuali

le tecnologie sottostanti, e i relativi pattern di utilizzo, si sono successivamente evoluti per semplificare ulteriormente lo sviluppo dei sistemi distribuiti e per favorire le loro qualità e la loro interoperabilità


Luca Cabibbo ASW

Discussione

Alcuni sistemi sono basati sia sullo stile client-server che sullo stile peer-to-peer – i due stili vengono applicati separatamente in parti distinte del sistema

alcuni sistemi hanno lo scopo di offrire dei servizi ai loro client –dunque l’organizzazione complessiva del sistema è basata sullo stile client-server

tuttavia, i servizi potrebbero essere implementati da un insieme di server che si coordinano tra di loro in modalità peer-to-peer

è il caso, ad es., di alcuni sistemi per la gestione di dati distribuiti


Server


server peer

server peer

server peer

server peer

server peer

Date post:	15-Feb-2019
Category:	Documents
Upload:	lynga
View:	218 times
Download:	0 times

Stili fondamentali per sistemi distribuiti - Luca...

Documents