Un’infrastruttura di supporto per servizi di file hosting

1. Un’infrastruttura di supporto per servizi di file hosting Matteo Corvaro Matricola 0000244226 Corso di Reti di Calcolatori LS – Prof. A. Corradi A.A. 2006/2007

2. Servizi di FILE HOSTING

3. Obiettivi • Progettare un’infrastruttura di supporto per garantire agli utenti la migliore QoSpossibile in base alle risorse dinamicamente disponibili in servizi di file hosting

4. Architettura DATA SERVER LIVELLO DI STORAGE CLIENT SIDE SERVER SIDE LOGIC CLUSTER MIDDLEWARE MANAGER SERVER MIDDLEWARE LIVELLO DI CONTROLLO

5. Caratteristiche dell’architettura • Logic cluster basato su un modello di high-availability cluster con bilanciamento di carico • Manager centralizzato • Vantaggi • Alta disponibilità • Alte prestazioni • Bilanciamento di carico • Controllo dello stato dei data server a carico del manager (heartbeat) • Failovercontrollato sia dal middleware client che dal manager • Replicazioni con politiche lazy • Velocizzare tempo di risposta all’utente  • Possibili casi di non disponibilità dei dati  • Scelte implementative • Java versione 6 / Multithread / Socket TCP

6. Manager server • Coordina l’intera architettura lato server • Gestisce le richieste dei client bilanciando il carico sul livello di storage • Esegue operazioni di monitoraggio e replicazione • Mantiene un’immagine consistente del livello di storage sottostante e delle sue proprietà • Registra i diversi data server e gestisce sia disconnessioni improvvise che terminazioni lecite • Ipotesi • Deployment su una macchina che non può presentare malfunzionamenti né colli di bottiglia in termini di risorse (ipotesi restrittiva ) • Manager raggiungibile ad un indirizzo noto ai client e immutabile • Non c’è trasparenza alla allocazione 

7. Data server • Livello di storagedei dati • Effettivo esecutore del servizio • Accetta comandi sia dal manager che dal middleware client • Il loro numero (dinamicamente variabile) determina le “prestazioni” lato server in fatto di: • Capacità di replicazione • Parallelismo di risposta ai diversi client • Spazio disponibile • L’amministratore può gestire le risorse (data server) adattandole al carico richiesto dal servizio

8. Client middleware • Nasconde i dettagli della comunicazione con l’architettura server ai diversi client • Consente l’integrazione trasparente di diversi client con il servizio di file hosting tramite un’interfaccia standard • Gestisce eventuali errori di comunicazione (o di protocollo) tramite ritrasmissioni e negoziazioni con i diversi server

9. Algoritmo di Download & Upload • Algoritmo a due fasi con ritrasmissioni nel caso di errori di rete • Richiesta da parte del client di una locazione di download/upload • Trasferimento vero e proprio dei dati Manager Server MIDDLEWARE FASE 1 Richiesta locazione di upload/download Data Server FASE 2 Trasferimento file

10. Load-balancing • Obiettivi • Aumentare la velocità di risposta ai client • Caricare al meglio i data server disponibili nel livello di storage • Politiche nel caso di download • Possesso del file • Livello di congestione, cioè numero di connessioni già instaurate • Connessioni massime ammesse, parametro settabile dall’amministratore • Politiche nel caso di upload • Livello di congestione e connessioni massime, come nel caso di download • Spazio disponibile (e sufficiente) • Si usa una media pesata dei due fattori, con lo spazio disponibile predominante • Caricare file su un server con poco spazio limita le possibilità di replicazione 

11. Replicazione • Replicazione time-baseddecisa dal manager ed eseguita un maniera autonoma dai data server coinvolti • L’elenco dei file viene ripartito in due gruppi gerarchici in base al numero di proprietari • Unico proprietario - Più proprietari • Si individuano i file replicabili in base allo stato delle risorse nel livello di storage • In ogni gruppo le possibili repliche sono ordinate in base alla maggiore dimensione dei file • Si replicano prima file grandi, ottimizzando lo spazio disponibile nel livello di storage  • L’amministratore può controllare il grado di replicazione e quindi l’overhead • Impostando il limite massimo di operazioni di replica per intervallo • Impostando la percentuale massima di spazio di memorizzazione disponibile per operazioni di replica

12. Fault-tolerance e integrità dei dati • Il manager verifica lo stato dei diversi data server • Invio di pacchetti heartbeatcon un intervallo prefissato • In caso di non risposta prima ritrasmissione e successivamente dichiarazione di caduta del nodo • Meccanismi di ritrasmissione nell’algoritmo di download/upload a due fasi da parte del middleware client • Integrità dei dati trasmessi verificata con hashSHA-256 • Gestione di download e upload in maniera transazionale • Garanzia delle proprietà A.C.I.D. • Meccanismi di rollback e commit

13. Scalabilità

14. Conclusioni e sviluppi futuri • È stato realizzato un supporto per un servizio di file hosting basato su un’architettura per high availability in grado di adattarsi dinamicamente alle risorse presenti garantendo una buona QoS ai client • Nei test eseguiti su LAN sono state confermate le qualità di load-balancing e affidabilità • Il sistema è comunque adattabile a diverse situazioni tramite alcune costanti modificabili (timeouts, grado di replicazione,…) • Il collo di bottiglia principale è rappresentato dal manager server • Necessario prevedere meccanismi di replicazione e monitoraggio • Se il nodo cade? Quiscustodietcustodes?  • Ulteriori sviluppi dovranno anche considerare la gestione della sicurezza in fatto di autenticazione ed autorizzazione dei diversi client e dei componenti dell’architettura server