Post on 15-Feb-2019
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
Stili fondamentali per sistemi distribuiti2
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
Stili fondamentali per sistemi distribuiti3
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
Stili fondamentali per sistemi distribuiti4
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
Stili fondamentali per sistemi distribuiti5
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
Stili fondamentali per sistemi distribuiti6
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
Stili fondamentali per sistemi distribuiti7
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
Stili fondamentali per sistemi distribuiti8
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
Stili fondamentali per sistemi distribuiti9
Luca Cabibbo ASW
Stile client-server
Soluzione (dinamica)
Stili fondamentali per sistemi distribuiti10
confine tra processi
Luca Cabibbo ASW
Stile client-server
Soluzione (dinamica)
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
Stili fondamentali per sistemi distribuiti11
Server
:Client:ClientClient
: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)
Stili fondamentali per sistemi distribuiti12
:Server:ServerServer:Client:ClientClient
IntermediateServer
BackEndServer
:Client:ClientClient
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
Stili fondamentali per sistemi distribuiti13
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
Stili fondamentali per sistemi distribuiti14
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à
Stili fondamentali per sistemi distribuiti15
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
Stili fondamentali per sistemi distribuiti16
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)
Stili fondamentali per sistemi distribuiti17
Luca Cabibbo ASW
Pattern di deployment
Alcuni pattern di deployment comuni
client-server a due livelli
client-server a tre livelli
Stili fondamentali per sistemi distribuiti18
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
Stili fondamentali per sistemi distribuiti19
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
Stili fondamentali per sistemi distribuiti20
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
Stili fondamentali per sistemi distribuiti21
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
Stili fondamentali per sistemi distribuiti22
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
Stili fondamentali per sistemi distribuiti23
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
Stili fondamentali per sistemi distribuiti24
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
Stili fondamentali per sistemi distribuiti25
Client Tier
Client
App Server Tier
AppServer
Database Tier
DBServer
Web Tier
Web Server
Luca Cabibbo ASW
Esempio – piattaforma Java EE
Stili fondamentali per sistemi distribuiti26
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
Stili fondamentali per sistemi distribuiti27
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
Stili fondamentali per sistemi distribuiti28
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
Stili fondamentali per sistemi distribuiti29
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
un tipo di applicazione da considerare quando
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
Stili fondamentali per sistemi distribuiti30
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
un tipo di applicazione da considerare quando
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
Stili fondamentali per sistemi distribuiti31
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
un tipo di applicazione da considerare quando
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
Stili fondamentali per sistemi distribuiti32
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
Stili fondamentali per sistemi distribuiti33
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
Stili fondamentali per sistemi distribuiti34
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
Stili fondamentali per sistemi distribuiti35
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
Stili fondamentali per sistemi distribuiti36
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à
Stili fondamentali per sistemi distribuiti37
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)
Stili fondamentali per sistemi distribuiti38
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
Stili fondamentali per sistemi distribuiti39
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
Stili fondamentali per sistemi distribuiti40
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
Stili fondamentali per sistemi distribuiti41
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)
Stili fondamentali per sistemi distribuiti42
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
Stili fondamentali per sistemi distribuiti43
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
Stili fondamentali per sistemi distribuiti44
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
Stili fondamentali per sistemi distribuiti45
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à
Stili fondamentali per sistemi distribuiti46
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
Stili fondamentali per sistemi distribuiti47
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
Stili fondamentali per sistemi distribuiti48
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
Stili fondamentali per sistemi distribuiti49
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
Stili fondamentali per sistemi distribuiti50
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
Stili fondamentali per sistemi distribuiti51
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
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
Stili fondamentali per sistemi distribuiti52
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
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
Stili fondamentali per sistemi distribuiti53
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
Stili fondamentali per sistemi distribuiti54
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
Stili fondamentali per sistemi distribuiti55
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
Stili fondamentali per sistemi distribuiti56
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
Stili fondamentali per sistemi distribuiti57
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
Stili fondamentali per sistemi distribuiti58
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 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)
Stili fondamentali per sistemi distribuiti59
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 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
Stili fondamentali per sistemi distribuiti60
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
Stili fondamentali per sistemi distribuiti61
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
Stili fondamentali per sistemi distribuiti62
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
Stili fondamentali per sistemi distribuiti63
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
Stili fondamentali per sistemi distribuiti64
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
Stili fondamentali per sistemi distribuiti65
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à
Stili fondamentali per sistemi distribuiti66
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
Stili fondamentali per sistemi distribuiti67
Server
:Client:ClientClient
server peer
server peer
server peer
server peer
server peer