Progetto di un server FTP in grado di coordinarsi con altri mirror per garantire QoS

Transcript

1 Università degli Studi di Bologna Facoltà di Ingegneria Reti di Calcolatori LS Anno Accademico 2004/'05 Progetto di un server FTP in grado di coordinarsi con altri mirror per garantire QoS Prof. Antonio Corradi Relazione di: Marco Buccione (matr ) Abstract Il protocollo FTP costituisce uno standard molto diffuso per il trasferimento di file attraverso Internet. Una situazione tipica è quella in cui più server FTP (detti mirror) contengono gli stessi file e svolgono in parallelo lo stesso compito: è una forma di replicazione molto semplice, che non prevede nessuna coordinazione o cooperazione. Questo progetto si propone di migliorare la qualità del servizio offerta da un insieme di mirror FTP attraverso un meccanismo di coordinazione. Tale meccanismo sarà definito attraverso la specifica di un protocollo di comunicazione tra server e sarà implementato, a scopo dimostrativo, in un server FTP esistente. In particolare, dopo aver inquadrato il dominio del problema nel capitolo 1, discuteremo le scelte progettuali determinanti per l'architettura del servizio nel capitolo 2; poi, nel capitolo 3, modelleremo il canale di comunicazione di cui ci serviamo e definiremo il protocollo di coordinazione tra server; nel capitolo 4 passeremo a descrivere l'implementazione di un server FTP che supporti il protocollo di coordinazione di cui si è già detto; quindi, riferiremo i risultati dei test sul nostro server di prova (capitolo 5) e ipotizzeremo alcune linee di ulteriore sviluppo per questo server (capitolo 6). 1 - Introduzione Il protocollo FTP costituisce uno standard molto diffuso per il trasferimento di file attraverso Internet. FTP si basa sul classico modello client-server. Quando si vuole servire un numero di utenti superiore a quello supportato da un singolo server, si ricorre al mirroring: si predispongono gli stessi file su più macchine e su ciascuna si pone in esecuzione un diverso server FTP. Il mirroring costituisce un esempio di replicazione: l'uso di un maggior numero di risorse porta ad un aumento delle prestazioni offerte, in termini di banda passante, e consente anche di migliorare la fruibilità del servizio (se un server è fuori uso, posso collegarmi ad un altro). Un tale meccanismo può essere classificato come soluzione intermedia tra replicazione master-slave e replicazione a copie attive, anche se, tipicamente, tra i vari mirror non è prevista nessuna forma di coordinazione o cooperazione: di fatto, è l'utente a

2 dover cercare un buon server cui connettersi ed a dover recuperare manualmente la connessione se c'è qualche problema. Il presente progetto nasce con l'intento di migliorare la qualità del servizio offerta da un insieme di mirror FTP. L'obiettivo è conseguire una migliore distribuzione del carico complessivo degli utenti tra i vari server attraverso un meccanismo di coordinazione tra i server stessi. 2 - Scelte progettuali Un punto di forza di FTP è nel suo essere uno standard diffuso a livello mondiale e supportato da qualsiasi piattaforma. Il primo obiettivo del nostro progetto sarà il cercare di rimanere il più aderenti possibile a questo standard: quindi, no a estensioni del protocollo FTP Coordinazione La prima decisione da prendere è relativa al gestore della coordinazione: puntare su un gestore centralizzato o realizzare un meccanismo distribuito? Un gestore unico avrebbe il vantaggio di rendere trasparente agli utenti lo smistamento del traffico verso i vari server. Purtroppo, volendo restare entro lo standard, FTP non dispone di istruzioni in grado di gestire il reindirizzamento di un client. Ciò renderebbe comunque necessario l'intervento dell'utente per ridirigere una connessione da un server verso un altro. Per questo motivo, si è ritenuto opportuno scegliere il meccanismo distribuito: tutti i server sanno tutto di tutti (o quasi...). A fronte di un maggiore overhead a livello di messaggi di coordinazione, tale meccanismo garantisce anche robustezza, senza dover introdurre ulteriori complicazioni come procedure di recovery in caso di caduta del master, ecc. La realizzazione di un meccanismo di coordinazione richiede un protocollo che definisca con precisione le interazioni tra i vari server, affinché ciascuno disponga delle informazioni relative agli altri. Alla definizione di tale protocollo sarà dedicato il prossimo capitolo Bilanciamento del carico Supponendo di aver realizzato la distribuzione delle informazioni tra i vari mirror, il passo successivo è la scelta di una politica per il bilanciamento del carico. La situazione ideale si avrebbe se tutti i mirror avessero lo stesso carico: ciò comporterebbe, però, un notevole overhead di coordinazione, a livello di messaggi tra i server e di reindirizzamento dei client (operazione, come già detto, a carico dell'utente). Ci accontenteremo, quindi, di una gestione a livello di singolo server: quando il carico raggiunge una certa soglia (decisa dall'amministratore di sistema), il server non accetterà più connessioni e risponderà con messaggi di ridirezione. Per evitare sovraccarichi improvvisi del server, adotteremo un modello di gestione con due soglie: una di allerta ed una di limite. La soglia di limite corrisponde al livello di carico oltre il quale una nuova richiesta è rifiutata. La soglia di allerta (per definizione minore di quella di limite) serve a definire un valore oltre il quale il server può rifiutare le connessioni, con probabilità linearmente crescente man mano che ci si avvicina al valore limite. In questo modo, si implementa una semplice politica di tipo proattivo. Finora abbiamo parlato di carico di un server senza definirlo esattamente: anche in questo caso, ci sono varie possibilità, ciascuna con i suoi pro ed i suoi contro. La definizione più corretta sarebbe in termini di banda occupata, ma ciò è difficilmente misurabile: bisognerebbe ricorrere a protocolli specifici (come RTP), ma, ancora una volta, si uscirebbe fuori dallo standard FTP. Ricorriamo, allora, ad una definizione più semplice ma comunque efficace: il carico è dato dal numero di connessioni FTP attive.

3 3 - Protocollo di comunicazione tra server In questo capitolo definiremo il protocollo che regola le comunicazioni tra i mirror. Come abbiamo già detto, tali comunicazioni servono per lo scambio delle informazioni sul carico. Innanzitutto, modelleremo le caratteristiche del canale di comunicazione; poi, definiremo il protocollo propriamente detto, con i messaggi scambiati e le procedure previste Modello del canale di comunicazione La situazione più comune è quella in cui i mirror sono dislocati a molta distanza tra di loro (al limite, anche in continenti diversi). In tal caso, il supporto di comunicazione naturale è Internet ed il nostro modello deve tenerne conto. Una politica di coordinazione richiede lo scambio di una quantità di informazioni piccola rispetto al flusso dei dati del server FTP. Da un punto di vista più pratico, ciò si traduce nella scelta di un meccanismo di comunicazione asincrono ed a scambio di messaggi. Quindi, il nostro canale di comunicazione tra i server FTP, visto dall'esterno, sarà un supporto in grado di fornire un servizio di trasmissione/ricezione di messaggi. È da notare che non stiamo richiedendo l'affidabilità del servizio: sarebbe un inutile overhead, viste le caratteristiche dell'applicazione (inoltre, ciò permetterà di semplificare l'implementazione sfruttando UDP as is) Obiettivo del protocollo Ricordando il principio di minima intrusione, cercheremo di realizzare un protocollo che comporti il minor overhead possibile. Un primo passo lo abbiamo compiuto rinunciando all'affidabilità del canale. Il passo successivo sarà quello di rinunciare ad un meccanismo richiesta-risposta per lo scambio di informazioni (che richiede due messaggi per ogni scambio, con la possibilità, inoltre, che un messaggio vada perso) e di puntare verso un modello push con leasing. L'idea di base è che ciascun server abbia il compito di informare periodicamente tutti gli altri sul suo livello di carico. Tali informazioni sono gestite con una politica di leasing: se non si ricevono più messaggi da un server per un intervallo di tempo prestabilito, esso è considerato irraggiungibile. Se opportunamente configurato (a livello di durata dei leasing), questo meccanismo è in grado di sopportare la perdita o il ritardo di alcuni messaggi Stato di un server Ogni server dovrà tenere traccia delle informazioni ricevute. Senza scendere in dettagli implementativi (per ora), supponiamo che un server depositi in memoria (in qualsiasi modo) il nome ed il carico di ogni altro server, con l'aggiunta di un'informazione storica, che chiameremo stato, e del timestamp relativo all'ultimo messaggio ricevuto. Lo stato rappresenta un modo per etichettare gli altri server noti, a seconda dalla storia dei messaggi ricevuti. Ciascun server può essere contrassegnato con uno dei seguenti stati: ACTIVE, UNREACHABLE e DISCONNECTED. Vediamone il significato: Un server è ACTIVE se il suo lease è ancora valido (quindi, se le informazioni sul suo carico sono sufficientemente recenti). Quando un server non rinnova più un lease, il suo stato è cambiato in UNREACHABLE e l'informazione sul suo carico è cancellata; si conserva comunque il timestamp dell'ultimo messaggio ricevuto per consentire le procedure di aggiornamento della lista dei server.

4 Infine, un server è in stato DISCONNECTED quando l'ultimo messaggio da esso ricevuto è di disconnessione. Anche in questo caso, si conserva il timestamp per i confronti Tipologia dei messaggi Per regolare l'interazione è necessario classificare i possibili tipi di informazioni da scambiare. A ciascuno sarà associato un tipo di messaggio. In questo paragrafo li definiremo e ne analizzeremo la semantica. Il primo messaggio, I_AM_ALIVE, è quello che consente il rinnovo del lease, segnalando che il mittente è attivo. Esso contiene il dato sul carico (in percentuale) del mittente ed un timestamp (per il leasing). Il ricevente aggiorna le informazioni sul mittente e ne pone lo stato in ACTIVE. Prevederemo, poi, un messaggio GET_SERVER_LIST per richiedere l'invio della lista dei server noti (con tutte le informazioni relative). A tale messaggio, il ricevente risponde con SERVER_LIST. Quest'ultimo conterrà le informazioni richieste. Tale scambio di messaggi servirà in fase di bootstrap e per degli aggiornamenti periodici; tutto ciò lo vedremo nel prossimo paragrafo. Infine, prevederemo un messaggio I_DISCONNECT, per comunicare che il mittente sta per terminare la sua attività. Il ricevente modifica lo stato del mittente in DISCONNECTED Procedure Descriviamo brevemente le procedure che dovranno essere eseguite dal server: Bootstrap: si suppone che l'amministratore di sistema conosca l'indirizzo di almeno un server presso cui reperire la lista completa dei server; a tale indirizzo sarà inviato un messaggio GET_SERVER_LIST e si attenderà la risposta, sotto forma di un messaggio SERVER_LIST; se non c'è alcuna risposta, si ritenta dopo un timeout. Leasing: ad intervalli di tempo regolari, si invia un messaggio I_AM_ALIVE a tutti i server noti. Il periodo tra un invio e l'altro e la durata del lease varieranno a seconda della configurazione di rete; in ogni caso, visto che operiamo su un canale best-effort, conviene che il lease duri abbastanza da tollerare la perdita di alcuni messaggi di rinnovo. Aggiornamento della lista dei server: periodicamente si invia un messaggio GET_SERVER_LIST a tutti i server noti, senza fermarsi ad attendere le risposte. Quando arriva un messaggio SERVER_LIST, si fa un confronto tra i dati ricevuti e quelli già noti, aggiornando questi ultimi se le informazioni ricevute hanno un timestamp più recente. Questa procedura favorisce la condivisione delle informazioni più aggiornate ma, soprattutto, riduce la probabilità di partizioni della rete. Disconnessione: prima di terminare la sua attività, il server invia un messaggio I_DISCONNECT a tutti i server in lista. 4 - Realizzazione del sistema Nel seguito descriveremo l'implementazione di un server FTP che supporti anche il protocollo di coordinazione descritto nel capitolo precedente. Ci soffermeremo solo sui dettagli più significativi per gli scopi del presente progetto. Il linguaggio scelto per l'implementazione è Java, poiché consente una semplice gestione di meccanismi di comunicazione quali le socket ed i protocolli TCP ed UDP ed implementa il modello multithreaded in modo nativo: tutte caratteristiche che torneranno utili per questo progetto.

5 Si è scelto di sfruttare un server FTP esistente: Jftpd, un semplice server open-source codificato in Java. Jftpd ha il vantaggio di essere molto compatto; per contro, non supporta tutte le funzioni specificate nella RFC 959 (la carenza maggiore è il mancato supporto alla modalità FTP passivo). Per facilitare un'eventuale sostituzione di Jftpd con un altro server FTP, si è cercato di mantenere il progetto del sistema il più modulare possibile Architettura Illustriamo schematicamente l'architettura complessiva del sistema mediante il seguente diagramma dei package: La rappresentazione è volutamente semplificata ed usa delle notazioni di comodo. Tuttavia, consente di mettere a fuoco gli elementi più importanti: il package jftpd contiene tutti i file del server Jftpd cui si è già accennato; l'architettura è strutturata verticalmente secondo un pattern Presentation- Abstraction-Control; il livello di controllo, inoltre, è ulteriormente suddiviso in tre parti, allo scopo di disaccoppiare la gestione del server FTP da quella della coordinazione tra server il package channel fornisce all'esterno l'astrazione del canale di comunicazione verso gli altri server, incapsulandone l'implementazione; il package resources contiene i dati condivisi tra più package; in particolare: la classe ServerLoad contiene il dato sul carico attuale del server ed il valore cui sono state impostate le due soglie (di allerta e di limite); la classe ServerTable contiene tutte le informazioni sugli altri server coordinati: indirizzo, stato, carico e timestamp dell'ultimo messaggio ricevuto. Altri elementi, che richiedono un discorso più dettagliato, sono trattati nei prossimi paragrafi.

6 4.2 - Un server multithreaded Come già detto, si sono tenute distinte le due componenti principali del sistema: la gestione del protocollo FTP (in altre parole, l'interfaccia lato client) e la gestione della coordinazione (cioè, l'interfaccia verso gli altri server). Entrambe queste parti trovano la loro migliore efficienza con un'esecuzione multithreaded. Il protocollo FTP è gestito con modalità thread-pool: un thread dedicato all'ascolto delle richieste di connessione (ServerListener) attiva un thread di servizio tra quelli disponibili (tutti di tipo ServerTask) ogni volta che una connessione è accettata. Questo tipo di gestione è particolarmente adatta ad un server, come quello in esame, in cui è noto il numero massimo di connessioni attive possibili. Il thread-pool è stato implementato sfruttando la classe ThreadPoolExecutor di Java, la quale fornisce questo tipo di servizio permettendone, all'occorrenza, anche una gestione articolata e flessibile. La coordinazione con gli altri server è compito di altri due thread: uno preposto alla ricezione dei messaggi in arrivo ed all'esecuzione delle azioni da questi richieste (CoordinationListener), l'altro addetto all'esecuzione di tutte le operazioni periodiche, come nla spedizione dei messaggi in uscita e l'aggiornamento dei server divenuti UNREACHABLE. Quest'ultimo thread è realizzato dalla classe java.util.timer, visto che i suoi task sono tutti di durata breve (rispetto al loro periodo) e non bloccanti. Il livello di precisione garantito da questa implementazione è più che sufficiente per la nostra applicazione. Il thread di esecuzione principale è quello dell'interfaccia di amministrazione. Da quest'ultima sono gestiti i parametri di controllo del sistema e sono avviati o interrotti tutti gli altri thread (appoggiandosi alla classe ServerControl, che costituisce il punto di accesso centralizzato a tutte le risorse del server) Ridirezione di un client La classe ServerListener ha il compito di decidere se accettare o no una connessione. Questa decisione, in realtà, è delegata ad un metodo isoverloaded() della classe ServerLoad, il quale provvede anche al sorteggio (tenendo conto delle probabilità) quando il carico è oltre la soglia di allerta. Se una connessione non può essere accettata, bisogna reindirizzarla verso il server meno carico tra quelli noti. Tale decisione è delegata ad un metodo getlessloadedserver() della classe ServerTable, metodo che elabora tutte le informazioni disponibili nella lista dei server per fornire una risposta. Il meccanismo di reindirizzamento, purtroppo, è molto rudimentale. Il protocollo FTP, come si è già detto, non prevede un comando che consenta di reindirizzare la connessione verso un altro server in modo trasparente all'utente. Di conseguenza, nel nostro caso un server sovraccarico rifiuterà una connessione rispondendo con un messaggio di errore, accompagnato dal suggerimento di un server scarico cui connettersi. Questa operazione, purtroppo, rimane a carico dell'utente Interfacce utente Dal lato server è presente un'interfaccia di amministrazione (package admingui) che consente di tenere sotto controllo i parametri principali di funzionamento del server. In particolare, è possibile: impostare l'indirizzo del server da cui fare il bootstrap; monitorare il numero di connessioni attive; verificare e modificare le soglie di allerta e di limite; visualizzare la lista dei server noti, con tutte le informazioni collegate; (ovviamente) avviare o fermare il server.

7 Per quanto riguarda il lato client, una situazione tipica è quella in cui l'utente ha a disposizione una pagina Web con l'elenco dei mirror disponibili. Questa soluzione ha il grande vantaggio di appoggiarsi ad uno standard diffusissimo quale HTTP. Per sfruttare questa possibilità, il sistema è in grado di scrivere la lista dei server in un file XML, che sarà aggiornato periodicamente (package usergui). In questo modo, le informazioni necessarie alla scelta del miglior mirror possono essere facilmente incluse in una qualsiasi pagina Web. 5 - Test Per il test del sistema sono stati usati due PC, dotati di Windows XP, collegati in rete locale. Tale configurazione ha consentito solo dei test molto semplificati; sufficienti, tuttavia, per il debugging dell'applicazione e per verificarne il corretto funzionamento. Il server è riuscito ad interagire correttamente con Internet Explorer, Mozilla FireFTP e SmartFTP. Va sottolineato che il supporto offerto da Jftpd è veramente elementare (ha richiesto anche alcuni ritocchi al codice per funzionare), e bisogna impostare i client in modo da non usare nessuna opzione avanzata. Test più probanti sarebbero necessari per controllare, ad esempio, l'efficienza del server in condizioni di pieno carico e la capacità di gestire correttamente molti mirror coordinati. 6 - Sviluppi futuri La direzione di sviluppo più significativa è verso il supporto a tutti i comandi previsti dallo standard FTP. Le possibilità sono due: integrare il codice di Jftpd, in modo da estenderne le capacità, o sostituire questo server con un altro più completo. La seconda ipotesi richiederebbe un po' di lavoro a livello dei package server e control, per adattare i meccanismi di controllo alle esigenze di un altro server. Sul versante della coordinazione, per particolari contesti (ad esempio, mirror situati nella stessa LAN o comunque vicini ) si potrebbe puntare ad una comunicazione affidabile e, magari, che sfrutti connessioni sicure (ad esempio, SSL). Ciò richiederebbe di riprogettare solo la classe CoordinationChannel, che implementa la comunicazione tra server. L'uso di SSL sarebbe facilitato dal supporto offerto dal package javax.net.ssl. Si potrebbe anche sfruttare il protocollo qui proposto per realizzare la coordinazione tra server non FTP: ad esempio, per monitorare la QoS di più server HTTP in parallelo o, comunque, in un qualsiasi contesto in cui possa servire una semplice politica di load balancing. A seconda dell'implementazione di tali server, si potrebbe riutilizzare una parte più o meno ampia del codice sviluppato per il server FTP. 7 - Conclusioni È stato definito un protocollo semplice, ma in grado di realizzare un buon grado di coordinazione tra più server FTP che vogliano attuare il mirroring. Le potenzialità di questo protocollo sono state saggiate implementandolo su un server FTP preesistente. I risultati sperimentali, seppur limitati, hanno mostrato che un simile sistema è in grado di funzionare correttamente. Riferimenti IETF RCF 959, reperibile presso Progetto Jftpd, di Ryan Heise, presso