Sistema P2P Persistente e Bilanciato Emanuele Spinella Corso di Reti di Calcolatori LS Prof. Antonio Corradi A.A. 2003/2004.

Presentazione sul tema: "Sistema P2P Persistente e Bilanciato Emanuele Spinella Corso di Reti di Calcolatori LS Prof. Antonio Corradi A.A. 2003/2004."— Transcript della presentazione:

1 Sistema P2P Persistente e Bilanciato Emanuele Spinella Corso di Reti di Calcolatori LS Prof. Antonio Corradi A.A. 2003/2004

2 Reti Peer To Peer Una rete Peer To Peer (P2P) è un sistema distribuito che permette agli utenti in possesso di una certa applicazione di connettersi fra loro e condividere informazioni Paradigma C/S Ogni terminale può fungere alternativamente o simultaneamente da client e da server Comunicazione molti-a-molti

3 Reti Peer To Peer 3 possibili modelli:  Centralizzate  Decentralizzate  Ibride Ogni modello con proprie caratteristiche, punti deboli e punti di forza

4 Reti P2P Centralizzate Unico sistema centrale che gestisce il traffico degli utenti Il sistema centrale è costituito da uno o più server coordinati Il sistema centrale dispone di directories in cui tiene l’elenco dei files condivisi e tutte le info necessarie per localizzare i proprietari e connettersi ad essi Napster come tipico esempio

5 Data Tranfer Search file Reti P2P Centralizzate Il peer che necessita di un file inoltra la richiesta al sistema centrale, il quale lo indirizza verso il proprietario del documento e fornisce il supporto per stabilire la connessione Detect source Connection

6 Reti P2P Centralizzate Vantaggi:  Efficienza e velocità di ricerca (servizio simile a quello di naming) Svantaggi:  Tempo di aggiornamento delle directories difficile da dimensionare  Sistema centrale come pericoloso punto di rottura da cui dipende la disponibilità di servizio

7 ConnectData transfer Search file Detect source Reti P2P Decentralizzate Nessun sistema centrale: ogni peer si fa carico delle operazioni di ricerca e connessione (es. Gnutella)

8 Reti P2P Decentralizzate Vantaggi:  Flessibilità: non esistono punti di rottura che possono inibire il servizio  Anonimato degli utenti Svantaggi:  La mancanza di registrazione riduce il controllo sugli utenti: QoS non sempre garantita

9 Reti P2P Ibride Risultato dell’unione delle due precedenti soluzioni Presenza di molti supernodi (server) presso ognuno dei quali sono registrati un certo numero di utenti Tutti i moderni sistemi P2P adottano una soluzione ibrida (WinMX, Kazaa, eMule, ecc.)

10 Data transfer Access directory: search file in my subnet Not found!  Reti P2P Ibride Il meccanismo di ricerca è simile a quello delle reti centralizzate, ma il peer cliente e quello servitore possono appartenere a supernodi diversi Search file Access directory: search file in my subnet Detect source Connect

11 Reti P2P ibride Il server ricerca il file all’interno dei peers registrati presso di esso e propaga la richiesta anche verso gli altri supernodi, che cercheranno nel proprio gruppo di utenti A ricerca terminata si effettua la connessione che precede il trasferimento dei dati

12 Reti P2P ibride Possibilità di gestire il livello di decentralizzazione o centralizzazione Un elevato numero di supernodi aumenta la decentralizzazione e diminuisce l’incidenza derivante dall’eventuale crash di un server (più supernodi significa meno peers registrati presso ognuno di essi, quindi meno utenti isolati dal servizio in caso di crash), ma si giova meno dei vantaggi che i server stessi possono offrire Un basso numero di supernodi sposta l’architettura verso il modello centralizzato, con tutti i vantaggi e gli svantaggi che questo comporta

13 Rete P2P persistente e bilanciata Necessità di dotare una rete P2P di caratteristiche atte ad aumentare la QoS offerta sui fronti della persistenza e del bilanciamento del carico Applicazioni in contesti che richiedono un alto livello di dependability (es. condivisione di importanti documenti fra stazioni di polizia e organizzazioni per la sicurezza sparse nel mondo e connesse in rete) Adozione della architettura ibrida

14 Persistenza La persistenza rappresenta la principale caratteristica del sistema:  Persistenza dell’infrastruttura: necessità di far fronte ad eventuali crash dei supernodi per evitare l’isolameto dalla rete dei peers ad essi connessi  Persistenza dei nodi: ogni singolo nodo deve garantire la persistenza in quanto depositario di importanti informazioni. Necessità di impiego di un modello di replicazione adeguato

15 Bilanciamento del carico Evitare la presenza contemporanea di nodi inattivi e nodi sovraccarichi Se un nodo richiede un documento posseduto da più peers, è opportuno che si valuti lo stato di carico di ognuno di essi e si effettui il trasferimento da quello con il numero inferiore di connessioni correnti

16 Architettura Tre attori principali:  LookUpServer: svolge le funzioni tipiche dei supernodi (supporto per una ricerca efficiente e veloce dei documenti)  Peer: rappresenta un terminale della rete P2P (può essere uno dei computer presenti in una stazione di polizia)  PeerCopy: rappresenta la copia esatta di un Peer e fornisce il supporto per il modello di replicazione atto a garantire la persistenza dei nodi

17 LookUpServer Ogni peer, al suo ingresso nella rete, deve registrarsi presso un LookUpServer Novità rispetto al modello ibrido standard: il LookUpServer non possiede nessuna directory delle risorse condivise (utilizzo di messaggi di ricerca)  A fronte di una richiesta il LookUpServer del nodo client (MasterServer) invia dei messaggi di ricerca a tutti i propri peers e agli altri servers (SlaveServer)  Maggiore overhead di comunicazione  Eliminati i problemi derivanti dalla frequenza di aggiornamento delle directories

18 LookUpServer (ricerca) Il peer client invia la richiesta al proprio LookUpServer (MasterServer) Search message Response message

19 LookUpServer (ricerca) Il MasterServer replica la richiesta ai propri peers e agli SlaveServer Search message Response message

20 LookUpServer (ricerca) Gli SlaveServer replicano la richiesta ai propri peers Search message Response message

21 LookUpServer (ricerca) I peers che hanno ricevuto la richiesta rispondono ai propri LookUpServer Search message Response message

22 LookUpServer (ricerca) Il MasterServer riceve le risposte raccolte dagli SlaveServer Search message Response message

23 LookUpServer (ricerca) Il MasterServer compone la risposta complessiva e la invia al client, il quale dovrà poi scegliere il documento che desidera Search message Response message Merge responses

24 Problema dovuto alla formulazione delle richieste con stringhe che non costituiscono un match esatto con il nome del documento desiderato Possibilità di trovare più documenti che contengono la stringa di query (es. la stringa “ack” può causare il ritrovamento dei files acknowledge.pdf, racket.mp3, sacker.doc, pippo.ack, ecc) Più peers possono avere lo stesso documento Il MasterServer deve elaborare le risposte ricevute dai propri peers e dagli SlaveServer raggruppando le occorrenze uguali Lo stesso devono fare gli SlaveServer con le risposte provenienti dai propri peers

25 RequestFile E’ una struttura dati che rappresenta un file il cui nome contiene la stringa di query Ogni RequestFile è caratterizzato dal nome del file che rappresenta e dalla lista dei peers che lo possiedono + addPeerList(in pList[ ]) - Name - PeerList [ ] RequestFile

26 Ogni LookUpServer riceverà un certo numero di RequestFile e dovrà unire quelli omonimi in un unico oggetto, aggregando le liste dei peers proprietari L’utente che ha inizialmente fatto la richiesta, alla fine del procedimento di ricerca, potrà scegliere fra un insieme di files (RequestFile) diversi senza sapere a chi appartengono (trasparenza della locazione) Il download di una risorsa appartenente a più nodi viene gestita dal sistema scegliendo il peer ‘migliore’ da cui scaricare, in modo da bilanciare il più possibile il carico sulla rete

27 RequestFile (merging) Request File Name = resA PeerList = {p1} Request File Name = resB PeerList = {p1} Ogni peer istanzia un RequestFile per ogni file in suo possesso che fa match con la query Request File Name = resA PeerList = {p2} Request File Name = resC PeerList = {p2} Peer p1 Peer p2 LookUpServer

28 RequestFile (merging) Request File Name = resA PeerList = {p1} Request File Name = resB PeerList = {p1} Il LookUpServer riceve i RequestFile di tutti i peers e unisce quelli omonimi modificando opportunamente la PeerList Request File Name = resA PeerList = {p2} Request File Name = resC PeerList = {p2} Peer p1 Peer p2 LookUpServer Request File Name = resA PeerList = {p1, p2} Request File Name = resB PeerList = {p1} Result Request File Name = resC PeerList = {p2}

29 Peer Nodo che può effettuare e/o ricevere richieste di ricerca di files In caso di richiesta ricevuta, il Peer deve controllare nella propria directory di sharing la presenza di uno o più files nel cui nome sia contenuta la stringa di query Per ogni file compatibile con la query il Peer deve comporre un oggetto RequestFile e inviarlo al proprio LookUpServer

30 PeerCopy Ogni Peer è dotato di una copia, fisicamente rappresentata da un diverso terminale, che possiede gli stessi files condivisi dall’originale Il modello di replicazione utilizzato è quello a copie calde e passive:  Calde in quanto vengono create insieme all’originale e si mantengono aggiornate sullo stato del sistema  Passive perchè non eseguono fino al crash del peer associato

31 PeerCopy Dal punto di vista logico il Peer estende il concetto di copia; infatti quest’ultima è un Peer a tutti gli effetti, a parte il fatto che non può inoltrare richieste, ma solo riceverne ed eventualmente eseguire l’upload dei files Esattamente come un Peer, la copia si deve registrare presso il LookUpServer (lo stesso del Peer cui è associata)

32 QoS: Persistenza La persistenza è ottenuta mediante un sistema di heartbeats che consente di testare costantemente lo stato di attività dell’infrastruttura di supporto (LookUpServer) e dei peers La mancata ricezione dell’heartbeat allo scadere di un timeout, provoca l’innesco di una procedura di recovery

33 QoS: Persistenza dell’infrastruttura di supporto L’eventuale crash di un LookUpServer può causare l’isolamento dalla rete di tutti i peers (e delle copie) ad esso connessi Iniziativa dei peers e delle copie per monitorare lo stato del server ed eseguire l’eventuale procedura di recovery (monitoring non centralizzato)

34 QoS: Persistenza dell’infrastruttura di supporto Invio periodico di heartbeats (hb) dal LookUpServer ai peers connessi

35 QoS: Persistenza dell’infrastruttura di supporto Dopo la ricezione di ogni hb, il Peer fa partire un timer, prima dello scadere del quale deve essere ricevuto l’hb successivo

36 QoS: Persistenza dell’infrastruttura di supporto In caso di guasto, gli hb non possono più essere inviati e il timer di ogni Peer scade timer

37 QoS: Persistenza dell’infrastruttura di supporto Ogni Peer esegue una procedura di recovery che consiste nel registrarsi presso un altro server e indurre la copia a fare lo stesso register New Server Info New Server Info register

38 QoS: Persistenza dell’infrastruttura di supporto Viene ristabilito il sistema di hb

39 QoS: Persistenza dei nodi In caso di crash di un Peer deve essere automaticamente messa in esecuzione la copia, per garantire la continuità del servizio La copia, calda e passiva, mantiene monitorato lo stato di attività dell’originale ricevendo da questo dei segnali di hb

40 QoS: Persistenza dei nodi In caso di crash del Peer, la copia non riceve più alcun hb e, allo scadere di un timeout, inizia la propria procedura di recovery PeerCopy timer Server hb

41 QoS: Persistenza dei nodi PeerCopy disattiva l’originale sul server: il binomio Peer/PeerCopy è sempre presente, un flag stabilisce quale dei due è attivo Server hb Deactivate original Peer

42 QoS: Persistenza dei nodi I parametri dell’originale vengono mantenuti all’interno del server anche in caso di crash, in modo da poter essere riutilizzati in seguito a una futura riattivazione e per mantenere la corrispondenza con la copia Server hb Deactivate original Peer

43 QoS: Persistenza dei nodi Le richieste di files arrivano al Peer originale o alla copia a seconda dello stato del flag. PeerCopy è perciò in grado di effettuare l’upload di un file Server hb Deactivate original Peer

44 QoS: Persistenza dei nodi La seconda fase del protocollo di recovery prevede la redirezione degli hb del server verso la copia: poiché l’originale è down spetta alla copia monitorare lo stato di attività del LookUpServer Server hb Server hb

45 QoS: Persistenza dei nodi Il crash di un Peer può avvenire in un momento di inattività, ma anche durante il trasferimento di un file Oltre al protocollo di recovery bisogna gestire anche il fallimento del trasferimento dati Il Peer sorgente invia al nodo ricevente, prima dell’inizio del trasferimento, l’indirizzo della propria copia In caso di fallimento del Peer il nodo ricevente può, senza effettuare nuove ricerche, rivolgersi direttamente alla copia per riiniziare il trasferimento

46 QoS: Persistenza generale E’ anche possibile che i guasti non colpiscano isolatamente il LookUpServer o il Peer, ma entrambe le entità Di particolare interesse il caso di guasto di un LookUpServer in un momento in cui anche il Peer originale è down

47 Registrazione virtuale Peer e PeerCopy sono due entità che collaborano per rappresentare un unico concetto di nodo persistente Finchè la copia è attiva, l’utente percepisce il nodo come attivo, in quanto è in grado di fornire il servizio (anche se l’originale è down)

48 Registrazione virtuale Esattamente come nel caso di crash del solo Peer originale, il binomio Peer/PeerCopy deve rimanere presente a livello di LookUpServer Se cade anche il LookUpServer, spetta alla copia effettuare una nuova registrazione presso un altro server, sia di se stessa, sia dell’originale andato in crash (registrazione virtuale) Sul nuovo server vengono inseriti i parametri della copia e dell’originale, esattamente come sul vecchio. Viene infine opportunamente settato il flag che segnala l’attività della copia Quando il Peer originale verrà riattivato si ritroverà registrato presso un server differente

49 Bilanciamento del carico Aspetto relativo alla QoS avente la finalità di distribuire, con politiche che rispettano il principio di minima intrusione, il carico in modo omogeneo sui diversi nodi Bilanciamento a livello di:  Peer/Copia: per quanto riguarda il trasferimento dati  LookUpServer: per quanto riguarda il numero di registrazioni

50 Registration Balancing L’ingresso nella rete da parte di un Peer presuppone la sua registrazione presso un LookUpServer Ogni Peer dispone di una lista di server memorizzata in locale sotto forma di file Il Peer contatta il primo server attivo della lista, il quale:  Aggiorna la server-list del Peer con l’elenco attuale dei server attivi  Rileva il numero di connessioni di tutti i server attivi e dirige la registrazione del peer verso il LookUpServer meno carico

51 Data Transfer Balancing In seguito a un processo di ricerca l’utente può decidere di scaricare un documento posseduto da più peers Rilevazione del ‘best peer to download’ Il peer richiedente contatta tutti i nodi presenti nella peer list dell’oggetto RequestFile associato alla risorsa desiderata, per conoscere quello meno carico e connettersi ad esso Viene stabilita la connessione con il nodo che sta effettuando il numero minimo di trasferimenti

52 Implementazione La fase implementativa ha visto l’utilizzo della piattaforma java e in particolare di:  RMI: come supporto all’invocazione remota dei metodi  Multithreading: per la gestione della persistenza  Sockets: per i trasferimenti dati

53 RMI Ogni Peer, nella fase di ingresso nella rete, ricopre il ruolo di un oggetto servitore che pubblica il proprio servizio per renderlo noto ai possibili clienti Il processo di registrazione prevede l’iscrizione del Peer all’interno di un RMI registry, che fornisce un riferimento ad esso a chiunque ne faccia richiesta L’architettura P2P aggiunge a tale servitore la capacità di potere anche richiedere servizi e svolgere il ruolo di un client

54 RMI Tutte le entità in gioco (Peer, PeerCopy, LookUpServer) devono iscriversi in un registry, poiché tutte forniscono un servizio (ricerca files, trasferimento dati, registrazione) Il modello prevede la presenza del registry sulla macchina dell’oggetto che fornisce il servizio

55 RMI Nella server-list memorizzata in locale da un Peer ci sono perciò gli indirizzi e le porte su cui si affacciano i registry associati ai vari LookUpServer Il riferimento remoto a un LookUpServer viene ottenuto mediante un preliminare colloquio con il registry RMI Registry LookUpServer Peer Peer HostServer Host

56 MultiThreading Il sistema di heartbeat deve agire in background lasciando che i processi principali si occupino delle loro attività (registrazione, ricerca files, migrazioni, ecc.) Vengono creati opportuni thread che si occupano dell’invio e ricezione degli hb in modo autonomo e senza interferire con i processi principali

57 MultiThreading Ogni processo principale si occupa della creazione dei thread di cui necessita per la gestione degli hb:  LookUpServer: genera un thread ServerDeamon che si occupa di inviare gli hb al Peer  Peer: genera un thread PeerDeamonSrv per ricevere gli hb dal server e un thread PeerDeamon per inviare gli hb alla copia  PeerCopy: genera un thread CopyDeamon, al momento della sua istanziazione, per ricevere gli hb dall’originale e, in caso di crash di quest’ultimo, in seguito alla procedura di recovery, genera il thread PeerDeamonSrv per ricevere gli hb del server

58 MultiThreading I deamon che ricevono gli hb sono costituiti da contatori watch dog decrementati periodicamente Ad ogni ricezione di un hb vengono ri- settati al valore massimo Se l’hb tarda ad arrivare il contatore raggiunge lo zero e lancia l’allarme per innescare la procedura di recovery

59 MultiThreading I deamon che inviano gli hb sono costituiti da cicli infiniti che, periodicamente, inviano un messaggio di ‘reset-dog’ al contatore del processo ricevente

60 MultiThreading Anche il trasferimento dati utilizza il supporto offerto dal multithreading Necessità che il trasferimento avvenga in backround mentre il processo principale continua le sue attività Creazione di un thread TransferOutThread che genera una socket in ascolto per eventuali richieste di connessione Accept bloccante, thread necessari

61 Sockets Utilizzo delle sockets per il trasferimento dei files Connessione mediante il protocollo TCP che offre sicurezza, ordinamento Generazione di altri thread per stabilire il canale di connessione ed effettuare il trasferimento dati

62 Sockets Una volta stabilito il ‘best peer to download’ il peer richiedente (rPeer) genera un thread TransferInThread che crea una socket e tenta di collegarla all’end-point remoto Il Peer sorgente (sPeer) riceve la richiesta da parte di rPeer e, mediante il processo TransferOutThread, effettua l’accept di connessione e stabilisce il canale mediante il quale può iniziare il trasferimento dati

63 Sockets Ogni Peer svolge la funzione di server concorrente, in quanto può eseguire più upload contemporaneamente

64 Sockets Necessaria la creazione di un ulteriore thread (RcpServiceThread) che si occupi del trasferimento mentre il TransferOutThread torna in ascolto di altre eventuali richieste di connessione

65 Conclusioni La realizzazione del progetto ha permesso di approfondire alcuni degli argomenti principali del corso di Reti di Calcolatori LS, come la disponibilità di servizio, le tecniche di replicazione e il bilanciamento del carico E’ stato dunque possibile analizzare concretamente tutti i passi, con relative problematiche, che hanno portato al raggiungimento di un soddisfacente livello di QoS

66 Conclusioni Il sistema realizzato presenta numerose semplificazioni rispetto ai moderni software P2P. D’altra parte l’obiettivo era quello di concentrare gli sforzi maggiori sugli aspetti relativi all QoS, magari trascurando alcune funzionalità di contorno o di importanza minore, le quali potrebbero costituire un buon punto di partenza per eventuali sviluppi futuri I test eseguiti hanno consentito un buon debugging dell’applicazione, cercando di coprire il più possibile lo spettro dei possibili eventi di guasto