Un`infrastruttura di supporto per servizi di file hosting

 Un’infrastruttura di supporto per servizi di file hosting Università degli Studi di Bologna Laurea Specialistica in Ingegneria Informatica Reti di Calcolatori LS – Prof. A. Corradi A.A. 2006/2007 Matteo Corvaro Matricola 0000244226 Abstract Questo lavoro presenta un’infrastruttura client/server che implementa un servizio di file hosting. Nella realizzazione sono stati particolarmente curati gli aspetti di disponibilità, affidabilità e scalabilità del servizio, presentando una soluzione server basata su un cluster in grado di garantire sia le proprietà sopra enunciate, che di bilanciare il carico di lavoro tra i diversi nodi del cluster stesso. È stato inoltre progettato un middleware di supporto in grado di interfacciare, in maniera trasparente, qualsiasi client con l’architettura server progettata. 1 1 Introduzione Al giorno d'oggi, l’enorme diffusione di contenuti multimediali quali, ad esempio, video ad alta definizione piuttosto che musica o foto digitali, ha causato un notevole aumento della capacità di memorizzazione richiesta da ogni utente. Disporre di dispositivi di archiviazione sempre più grandi non è più la scelta ottimale sia dal punto di vista economico che, soprattutto, considerando come i nuovi scenari dell’IT moderno spingono verso una sempre maggior mobilità di dati e utenti che hanno una variegata quantità di dispositivi diversi: da “classici” PC fino a computer palmari, passando per telefoni cellulari e computer portatili. Emerge quindi un problema cruciale presente in tali scenari: la portabilità dei dati. Ogni utente, infatti, desidera poter avere i propri file indipendentemente dalla sua locazione fisica o dal dispositivo che utilizza in ogni istante. Per risolvere questo problema è necessario avere un “deposito” remoto dove immagazzinare i propri dati ed un sistema che consenta di renderli fruibili ovunque nell’intero globo. In questo scenario nascono i servizi di file hosting, che consentono agli utenti di memorizzare dati personali su server remoti, non occupando le proprie risorse locali e potendo disporre dei file da qualsiasi postazione connessa alla rete Internet, che allo stato attuale consente una copertura pressoché capillare del globo, grazie anche alle recenti introduzioni di tecnologie radio wireless come il Wi‐Fi o, migliore, il Wi‐Max. È evidente che con questa soluzione siamo in grado di risolvere i problemi citati in precedenza, ma non solo. Ci si rende subito conto della possibilità di instaurare una forma di condivisione dei dati. Infatti, in base alla politica adottata dal servizio, potranno esserci file pubblici, accessibili a tutti gli utenti, piuttosto che file privati. Esiste però anche un rovescio della medaglia. Pensare di realizzare un tale servizio di file hosting a larga scala, pone seri problemi riguardo alla capacità di memoria richiesta, la congestione indotta nella rete di supporto ed anche riguardo alla sicurezza dei dati nelle loro varie fasi di vita: dal trasporto via rete al server di file hosting fino alla memorizzazione nel file system di quest’ultimo. E’ necessario anche predisporre un opportuno meccanismo di autenticazione ed autorizzazione dei diversi utenti per garantire un’adeguata privacy. Gli aspetti fondamentali che determinano la QoS percepita dagli utenti in questi servizi, sono senza dubbio la disponibilità e la correttezza dei dati, nonché la velocità di risposta da parte del server. Il presente lavoro si inquadra proprio in questo scenario e mira a realizzare un’infrastruttura client/server che consenta di fruire di un servizio di file hosting affidabile, disponibile e scalabile, garantendo agli utenti la maggior QoS percepita possibile in base alle risorse disponibili nell’architettura server. 2 2 Architettura generale del sistema L’infrastruttura progettata è basata su un paradigma client/server, con il server gestito mediante una struttura a livelli, modellando l’intera architettura server come un high‐availability cluster. La figura seguente rappresenta la struttura proposta. …
CLIENT 1 CLIENT N MIDDLEWARE MIDDLEWARE
ARCHITETTURA SERVER MANAGER
LOGIC CLUSTER
DATA SERVER 1 DATA SERVER 2 …
DATA SERVER N‐1
DATA SERVER N
Figura 1: architettura del sistema Possiamo innanzitutto notare che nel sistema, seppur composto di due entità logiche (client e server), si possono distinguere tre tipologie di attori diversi: i client, il manager e i data server. I client comunicano in maniera trasparente con l’architettura server di file hosting mediante un apposito middleware, che nasconde loro i dettagli delle comunicazioni. Infatti, essi vedono 3 un’unica macchina che esegue le operazioni richieste: il manager. Nel progetto del sistema si è considerato che questi risieda su un nodo con indirizzo noto ai client dove non siano possibili malfunzionamenti. E’ infatti il manager che gestisce l’intera architettura server e ridirige le richieste dei client sui data server corretti. Nella sua memoria deve quindi essere presente una struttura dati che logicamente definisca l’intera architettura, mentre i file sono fisicamente memorizzati nei diversi data server associati. Ciò permette al manager da un lato di servire velocemente richieste da parte dei client delegandole ai data server che presentano una situazione di carico migliore e dall’altro lato di mantenere un controllo centralizzato sui diversi data server per gestire al meglio le capacità di replicazione e fault‐
tolerance, nonché di garantire un’elevata scalabilità del servizio. In linea teorica il sistema può operare correttamente se sono presenti un client, un manager e un data server. Questa è una configurazione minima che ovviamente non consente alcun tipo di ottimizzazione e che in sostanza non garantisce nessuna delle proprietà che sono obiettivo di progetto. E’ quindi con l’aggiunta di più data server che si ottengono i benefici desiderati da un sistema di tale genere: infatti, grazie agli algoritmi di ottimizzazione implementati dal manager, si possono ottenere affidabilità, disponibilità e scalabilità del servizio. Il prossimo capitolo è dedicato alla presentazione di tali algoritmi e delle annesse scelte di progetto. Passiamo ora ad una rapida descrizione delle scelte tecnologiche effettuate. L’intero progetto è stato scritto sfruttando il linguaggio Java, versione 6, con l’obiettivo di beneficiare dell’ormai nota portabilità inter‐piattaforma propria di questo linguaggio. Per quanto riguarda le comunicazioni attraverso la rete si è preferito utilizzare delle socket TCP che, a fronte di un maggiore overhead di trasmissione, garantiscono l’affidabilità necessaria al servizio. E’ stato implementato, per ora, un servizio di file hosting mono‐utente, dove i file depositati sono pubblici e chiunque può vederli o aggiungerne degli altri, senza nessun meccanismo di autenticazione o autorizzazione. Le operazioni possibili per i client sono quindi quelle di upload e di download, mentre l’amministratore del sistema può, tramite il manager, decidere di eliminare dei file, ad esempio per risparmiare spazio su disco. Illustriamo ora le principali caratteristiche del manager e del data server, rimandando al capitolo 4 quelle riguardanti il client e il rispettivo middleware. Manager Il manager rappresenta il fulcro dell’architettura server, in quanto ha il duplice ruolo di coordinare i vari data server e di servire o ridirigere le richieste provenienti dai client. Per questo motivo, esso è realizzato come un’applicazione multi‐threaded: una server socket TCP riceve, infatti, le richieste dai client e dai data server attivando un thread specifico per ogni operazione. Mediante una GUI l’amministratore può attivare il manager e seguire poi le operazioni che vengono eseguite mediante un log grafico, comprese quelle di ottimizzazione eseguite in automatico. Come detto in precedenza, è compito dell’amministratore solo l’eliminazione dei file che ritiene non necessari. Interessante è notare che alla chiusura dell’applicazione non è terminato 4 solo il manager, ma, a cascata, vengono chiusi anche tutti i data server che erano registrati in quel momento. Il manager mantiene al suo interno un oggetto di tipo IClusterArchitecture che contiene tutti i dati sul sistema corrente e cioè i data server registrati e i file gestiti; tramite l’ispezione di quest’oggetto, inoltre, vengono scelte le locazioni di download ed upload per i client e si definiscono le operazioni di ottimizzazione possibili. Data server I data server rappresentano gli effettivi esecutori del servizio e il loro numero può essere dinamicamente variato, con la prerogativa che maggiore è il loro numero e maggiori sono le prestazioni dell’infrastruttura. Essi sono costantemente monitorati dal manager che gestisce le repliche dei file e bilancia il carico di lavoro associato a ognuno di essi. La comunicazione con i client durante le operazioni di trasferimento file sono ovviamente gestite secondo il protocollo TCP, così come le operazioni di replica fra data server diversi. Anche i data server sono realizzati come applicazioni multi‐threaded e presentano una GUI tramite la quale un amministratore di sistema locale può avviare il server e controllare le operazioni che avvengono grazie ad un log grafico. La configurazione del data server è caricata all’avvio a linea di comando specificando la directory dove memorizzare i file, lo spazio massimo utilizzabile e il numero di connessioni accettabili. Alla chiusura dell’applicazione viene spedito un messaggio al manager che provvede a depennare dalla lista dei data server attivi il server corrente. Per essere integrato nel sistema, un data server ha bisogno di registrarsi presso il manager. Durante la procedura esso invia i propri dati identificativi (IP, porta di ascolto, file condivisi, spazio disponibile…) e attende una risposta per mettersi in ascolto sulla porta convenuta in attesa di comandi. Inoltre viene connessa con il manager anche una socket TCP permanente che funge da canale di controllo per monitorare l’operatività del data server mediante invio di messaggi heartbeat. 3 Aspetti salienti Dopo aver dato una definizione sommaria dei componenti base dell’infrastruttura progettata, concentriamoci ora su alcuni dettagli riguardanti l’implementazione dei diversi algoritmi operativi che garantiscono affidabilità, disponibilità e scalabilità dell’infrastruttura server. 3.1 Download & Upload Gli algoritmi di download e upload possono essere logicamente divisi in due fasi: 1. La richiesta da parte del client di una locazione di download/upload 5 2. Il trasferimento vero e proprio CLIENT MANAGER M
Richiesta locazione I
upload/download
D
D
L
E
W
A
R
E
FASE 1
FASE 2
Trasferimento file
DATA SERVER Figura 2 ‐ Fasi download e upload Per quanto riguarda il download, nella prima fase il client fornisce al manager il nome del file che desidera, che restituisce l’indirizzo del data server da cui portare a termine il download (se il file esiste). A questo punto il client si connette all’indirizzo così ottenuto e richiede il file, che viene adesso trasferito realmente. Questo è il caso ideale. Sono ovviamente possibili malfunzionamenti lungo la rete e pertanto sono previsti meccanismi di ritrasmissione in entrambe le fasi, gestiti direttamente dal client. Tratteremo meglio quest’argomento nel paragrafo relativo alla fault‐
tolerance. Nell’algoritmo di upload, invece, durante la prima fase il client fornisce al manager informazioni riguardo al file che intende depositare nel sistema (nome, dimensione, hash) e si aspetta di ricevere una locazione di upload che viene fornita dal manager stesso, sempre che sia possibile immagazzinare il file. Ora il client può connettersi alla locazione ricevuta ed eseguire il trasferimento confermandolo poi al manager. E’ interessante notare che anche il data server prescelto notifica al manager l’avvenuto upload: tale accorgimento consente di ottenere una prima forma di integrità dei file, come vedremo nel paragrafo che si riferisce alla fault‐tolerance. 3.2 Load‐balancing L’infrastruttura progettata è in grado di ripartire in maniera uniforme il carico di lavoro fra i diversi data server. Tutto ciò in primo luogo favorisce la velocità di risposta percepita dai client, ma 6 consente anche di non sovraccaricare eccessivamente i vari data server, sfruttandoli al meglio. Il criterio usato per la scelta è diverso secondo l’operazione richiesta. Infatti, a fronte di una richiesta da parte di un client, il manager nel restituire una locazione valuta diversi fattori: •
•
In caso di download, il manager sceglie, fra i data server che possiedono il file richiesto, quello che è meno congestionato. Il livello di congestione, in questo caso, è misurato come il numero di connessioni simultanee già attive in ogni data server. Quindi si sceglierà il server per cui questo valore è minimo e si controllerà anche il vincolo sul valore massimo di connessioni simultanee ammesse, parametro, questo, scelto dall’amministratore del data server. In caso di una richiesta di upload, invece, oltre a controllare il livello di congestione come nel caso di download, sarà necessario individuare quei data server che hanno sufficiente spazio a disposizione per memorizzare il file. Per effettuare la scelta, infatti, si calcola una media pesata fra questi due fattori, considerando come predominante lo spazio a disposizione del data server. Questa scelta di progetto è stata dettata dalla considerazione che, viste le capacità di replicazione del sistema, caricare file su data server con poco spazio disponibile limita fortemente le possibilità di ottimizzazione, descritte nel prossimo paragrafo. 3.3 Replicazione Un’altra caratteristica fondamentale per assicurare la disponibilità dei dati è la replicazione degli stessi. Il punto cruciale è quello di trovare un compromesso fra una replicazione totale (situazione idealmente perfetta, ma penalizzante dal punto di vista delle performance) ed una replicazione parziale o time‐based. Nel progetto è stato usato un sistema di replicazione time‐based creando un thread periodico che analizza la situazione dell’intero cluster logico e, dinamicamente, sceglie quali file devono essere replicati in quali data server, lasciando poi l’effettivo onere della replica ai singoli data server coinvolti. Ciò consente di ottenere un buon grado di affidabilità, introducendo un limitato overhead. Il principio è elementare: ad ogni intervallo di tempo, che è un parametro di progetto, il manager esamina la lista dei file e dei data server gestiti, individuando tutte le possibili repliche da eseguire, tenendo conto che durante ogni intervallo è possibile portare a termine un numero limitato di operazioni ed ogni data server ha bisogno di uno spazio disponibile non utilizzabile per operazioni di replica, anche questi parametri di progetto. Nel determinare le operazioni di replica è seguito un modello “gerarchico”, separando i file in base al numero di proprietari: quelli con uno solo e gli altri. Separati questi due gruppi, vengono processati prima i file con singolo proprietario, ordinandoli per dimensione decrescente e cercando per ognuno il data server (seguendo gli algoritmi di load‐balancing) dove compiere l’upload. Seguendo questo principio si tende a replicare prima i file più grandi per cercare di utilizzare al meglio lo spazio disponibile: se, infatti, si replicassero prima i file più piccoli, si correrebbe il rischio di non avere più spazio disponibile per replicare quelli grandi, poiché trovare ampi spazi liberi è sen’altro meno probabile rispetto a trovarne di piccoli. 7 Per quanto riguarda il secondo gruppo, invece, i file sono ordinati prima in base al numero di proprietari e poi in base alla dimensione, cercando ogni volta un data server di origine ed uno dove replicare il file (sempre in base alle proprietà di load‐balancing); ovviamente, ad ogni operazione trovata, la struttura del cluster viene aggiornata in maniera “virtuale”, per non trovarsi in situazioni in cui si credano disponibili risorse che in realtà, dopo le operazioni di replica, non saranno più libere. Si cerca quindi di replicare prima i file che hanno una probabilità maggiore di generare un fault in caso di caduta di qualche data server. Nella lista di operazioni così ottenuta la posizione occupata determina la priorità di ognuna e ad ogni intervallo vengono quindi eseguite al più il numero di ottimizzazioni imposto come parametro di progetto. 3.4 Fault‐tolerance e integrità dei dati In un servizio come il file hosting riveste particolare importanza la gestione delle possibili cadute dei diversi server. È quindi necessario predisporre dei meccanismi, il più possibile automatici, in grado di porre rimedio, in un tempo il più breve possibile, a tali eventi negativi. Il progetto presentato gestisce efficacemente il controllo dei data server, in quanto è stata fatta l’ipotesi semplificativa che il manager risieda su una macchina dove non sono possibili malfunzionamenti. Per quanto riguarda il controllo dei diversi data server, quindi, è lo stesso manager che se ne occupa, mediante dei thread che inviano pacchetti heartbeat ad intervalli regolari, consentendo così di verificarne lo stato di esecuzione: in tali thread è infatti presente un valore di timeout, trascorso il quale un data server viene ipotizzato caduto. Per minimizzare l’eventualità in cui un singolo pacchetto heartbeat venga perso per motivi non dipendenti dal data server, è prevista una ritrasmissione immediata del pacchetto alla scadenza del timeout ed una successiva violazione dello stesso porta in questo caso alla dichiarazione di caduta del data server, con la conseguenza che vengono rimossi dal manager tutti i riferimenti allo stesso. Un altro aspetto riguardante la fault‐tolerance è gestito durante le operazioni di download/upload dei file. Infatti, il client, in caso di malfunzionamenti nella rete, prevede meccanismi di ritrasmissione. Nel caso, ad esempio, in cui il data server non rispondesse più, il client chiede al manager un altro indirizzo (che lo restituisce, se esiste) e ricomincia la transazione con quest’ultimo. E’ stato adottato quest’approccio perché, visto che la connessione con il manager viene mantenuta durante tutta la durata dell’operazione, è statisticamente più rapido richiedere un nuovo indirizzo piuttosto che tentare ritrasmissioni con un server probabilmente caduto. Per quanto riguarda l’integrità dei dati scambiati è prevista una trasmissione esplicita degli hash dei dati ed il loro confronto come prova d’integrità dei file scambiati. L’algoritmo di hashing seguito è quello SHA‐256. Un’ultima riflessione merita l’argomento della concorrenza. Un’errata gestione può portare a situazioni di inconsistenza dei dati, ad esempio quando due client tentano l’upload di file con lo 8 stesso nome ma di contenuto diverso. L’intera architettura server è stata concepita cercando di assicurare un livello ottimo di concorrenza gestendo ogni operazione in maniera transazionale e garantendo quindi le proprietà A.C.I.D. mediante l’uso di metodi synchronized e di opportuni meccanismi di rollback, ad esempio nel caso di trasferimenti falliti. 3.5 Scalabilità Un alto grado di scalabilità in un servizio come il file hosting è decisivo. Infatti, sia la capacità di memorizzazione, che il numero di richieste simultanee aumentano in maniera quasi esponenziale al crescere del numero di utenti che utilizzano il servizio. Questo problema è stato preso in considerazione fin dall’inizio nel progetto, codificando tutta l’architettura server in un livello di controllo (manager) e uno di storage (data server). Infatti, variando il numero di macchine che eseguono i data server è possibile ottenere ogni livello di “potenza” (in termini di capacità di memorizzazione e di gestione di richieste simultanee) desiderato. È compito del manager gestire l’ingresso e l’uscita di data server in maniera che siano tutti utilizzati al loro massimo potenziale, mostrando invece all’utente una visione trasparente dell’architettura server. E’ ovvio che in quest’approccio il collo di bottiglia sia rappresentato proprio dal manager: per questo è necessario sia che la macchina che lo esegue abbia una dotazione hardware sufficiente, ma anche che possegga anche un collegamento alla rete con una banda utilizzabile in grado di non creare congestione. 4 Client Il client esemplificativo distribuito nel progetto è realizzato come un’applicazione grafica che consente di eseguire le operazioni di download, upload e lista file remoti. E’ possibile però costruire diversi client, magari all’interno di applicazioni più complesse, inglobando queste funzionalità grazie al middleware di supporto progettato. 4.1 Middleware I client operano in maniera trasparente rispetta all’architettura server. Questo perché il middleware esporta loro una semplice interfaccia con le tre primitive delle operazioni fondamentali, oscurando i meri dettagli delle comunicazioni. Infatti, tutti gli algoritmi esposti nel capitolo precedente non sono realmente eseguiti dal client, bensì dal middleware. Nel progetto è stato implementato un middleware per applicazioni grafiche e thread‐safe; è tuttavia possibile, implementando l’interfaccia base, realizzare versioni alternative sia a livello locale sia nella comunicazione con l’architettura server. 9 5 Conclusioni e sviluppi futuri E’ stata progettata un’architettura client/server in grado di gestire un servizio di file hosting affidabile, disponibile e scalabile, garantendo agli utenti la maggior QoS percepita possibile in base alle risorse disponibili nell’architettura server. Nei test eseguiti su rete locale, si è notato un buon grado di load‐balancing e di affidabilità; è stata osservata anche una risposta sufficientemente rapida ad eventi negativi come la caduta di un nodo. E’ possibile tuttavia tarare questi parametri prestazionali agendo sul sorgente utils.constants.Constants che consente di bilanciare il rapporto costo‐prestazioni del sistema secondo le necessità dell’amministratore o delle risorse disponibili. Sono molte le estensioni possibili all’infrastruttura presentata, ma le principali riguardano la sicurezza. Infatti, non è stato previsto alcun meccanismo di autenticazione ed autorizzazione. Potrebbe invece essere utile inserire tali meccanismi sia a livello della comunicazione client – server che in quella interna all’applicazione server. Per quanto riguarda il primo caso, sarebbe così possibile risalire al proprietario di un file, poterne avere di privati, modificarli o cancellarli e consentire solo agli utenti autorizzati l’uso del servizio. Nel secondo caso invece il problema è più subdolo: infatti, non essendoci meccanismi di autenticazione ed autorizzazione, chiunque in possesso del codice eseguibile può spacciarsi per manager o data server, ponendosi così nella posizione di portare attacchi di pericolosità crescente alle diverse macchine server “legali” nonché ai client che possono essere indotti a scaricare file pericolosi invece di ciò che realmente volevano ottenere. Infine, nel progetto è stato considerato il manager come risiedente su una macchina che non subisce malfunzionamenti: ovviamente tale ipotesi è restrittiva ed è quindi necessario implementare dei meccanismi di controllo anche sul manager, magari mediante un monitor che, aggiornato tramite una politica eager sullo stato dell’architettura server, si sostituisca al manager stesso in caso di malfunzionamenti o partizioni della rete. In questo caso sarebbe utile anche poter disporre di un servizio di nomi che consenta ai client di localizzare in maniera trasparente il manager corrente dell’infrastruttura. 10 Bibliografia •
•
•
•
A. Corradi – Dispense dal corso di Reti di Calcolatori LS – A.A. 2006/2007 – Bologna J.F. Kurose, K.W. Ross – “Internet e Reti” 2nd ed. – McGraw‐Hill – 2003 A.S. Tanenebaum, M. v. Steen – “Distributed Systems: Principles and Paradigms” 2nd ed. – Prentice Hall ‐ 2006
http://java.sun.com