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
Servizi di FILE HOSTING
Caratteristiche
Indicatori di
QoS
• Disponibilità dei propri dati da qualsiasi
locazione
• Risparmio di spazio di memorizzazione
locale
• Condivisione dei dati
• Disponibilità e correttezza dei dati
• Velocità di risposta da parte del server
• Sicurezza e privacy
Obiettivi
• Progettare un’infrastruttura di supporto per garantire
agli utenti la migliore QoS possibile in base alle risorse
dinamicamente disponibili in servizi di file hosting
Trasparenza
Scalabilità
Fault-tolerance
LATO
CLIENT
LATO
SERVER
Disponibilità
Integrità
Architettura
DATA SERVER
LIVELLO DI
STORAGE
CLIENT SIDE
SERVER SIDE
MIDDLEWARE
LOGIC CLUSTER
MANAGER
SERVER
MIDDLEWARE
LIVELLO DI
CONTROLLO
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)
• Failover controllato 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
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 
Data server
• Livello di storage dei 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
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
Algoritmo di Download & Upload
• Algoritmo a due fasi con ritrasmissioni nel caso di errori di rete
1. Richiesta da parte del client di una locazione di download/upload
2. Trasferimento vero e proprio dei dati
Manager Server
M
I
D A
D R
L E
E
W
FASE 1
Richiesta locazione di upload/download
Data Server
FASE 2
Trasferimento file
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 
Replicazione
• Replicazione time-based decisa 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
Fault-tolerance e integrità dei dati
• Il manager verifica lo stato dei diversi data server
▫ Invio di pacchetti heartbeat con 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 hash SHA-256
• Gestione di download e upload in maniera transazionale
▫ Garanzia delle proprietà A.C.I.D.
▫ Meccanismi di rollback e commit
Scalabilità
Collo di bottiglia rappresentato dal manager server per le capacità
computazionali e per la congestione di rete
• Aumento sia dei client che dei data server da gestire 
• Abbiamo ipotizzato che il manager sia eseguito su un nodo
con capacità computazionali e di rete infinite nonchè privo di
malfunzionamenti 
Aumentando il numero di
macchine che eseguono i
data server è possibile
ottenere “prestazioni”
maggiori
Aumentando il numero di
client il componente server
che viene maggiormente
stressato è il manager
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? Quis custodiet custodes? 
• Ulteriori sviluppi dovranno anche considerare la gestione della sicurezza in
fatto di autenticazione ed autorizzazione dei diversi client e dei componenti
dell’architettura server