H A F S

1. H A F S High Availability File System

2. Obiettivi • Realizzare un servizio di File System che sia: • Accessibile • Fruibile in remoto e condiviso da tutti gli utenti • Affidabile • Che scongiuri il rischio di una perdita definitiva dei dati in esso contenuti • SempreAttivo • Che eviti anche le inaccessibilità puramente temporanee ai contenuti

3. Analisi • Accessibilità • Per soddisfare il primo requisito è sufficiente prevedere una qualche interfaccia remota attraverso cui ogni client possa esporre le proprie richieste ed ottenere i servizi. Ad esempio NFS. • Affidabilità • Il passo necessario e sufficiente per garantire al sistema un certo livello di affidabilità (intesa come preservamento dei contenuti all’insorgere di guasti) è dotarlo di una qualche forma di replicazione delle risorse. Ad esempio RAID. • Disponibilità • Per garantire una robustezza ai guasti tale da scongiurare ogni temporanea interruzione del servizio è necessaria non solo una replicazione delle risorse finali (file) ma anche delle infrastrutture computazionali che erogano il servizio medesimo.

4. Cluster • L’architettura che meglio si adatta allo scopo è il cluster ad alta disponibilità • Esso è composto da un certo numero di macchine (nodi) che forniscono lo stesso medesimo servizio (replicazione) e che rispondono al cliente in maniera coordinata. • L’organizzazione paritetica all’interno del cluster fa si che il guasto su un membro non influenzi (negativamente) la funzionalità dell’intero sistema (nello specifico che non provochi un’interruzione del servizio)

5. Client Proxy Intermediario del client nella comunicazione con il cluster. Attraverso il canale di gruppo effettua la discovery della composizione e la connessione ad uno specifico nodo dal quale ottiene il servizio. I canali secondari sono attivati in caso di fault del nodo cui si è attualmente connessi. canale di gruppo connessione ad uno specifico nodo canali secondari Architettura Canale di Gruppo Canale di comunicazione comune (interno ed esterno al cluster) usato dai nodi per il coordinamento e dai client per la discovery Nodo del cluster Il riquadro grigio vuole rappresentare il fatto che dall’esterno il gruppo di nodi appare come un tutto unico Canale Privato Usato nelle comunicazioni impegnative (ad es. trasferimento file) per non impegnare il canale comune

6. Client Proxy • Client Proxy è l’agente del cluster che permette al client un interfacciamento trasparente all’allocazione ed alla composizione • All’avvio effettua una discovery sul canale di gruppo ed elegge uno specifico nodo da cui fruirà dei servizi • In caso di guasto effettua una migrazione automatica verso un sostituto e riprende le operazioni • Il client si confronta solamente con il Client Proxy ignorando le dinamiche sottostanti

7. JoinAccept RequestForJoin RequestForJoin Costituzione del gruppo ID = 1 ID = 2 Nella JoinAccept ogni nodo deve comunicare il proprio livello di priorità (ID) e la lista (comprensiva di IDs) di tutti gli altri appartenenti al gruppo. La richiesta di Join viene naturalmente persa nel canale perché il cluster non è stato ancora costruito! Allo scadere del timeout il nodo si ritiene il primo componente e costituisce da solo il cluster. La definizione del livello di priorità (ID) avviene sulla base degli ID di tutti gli altri nodi già appartenenti al gruppo. In particolare viene scelto un valore superiore al più grande degli ID già esistenti. Il canale di gruppo è un supporto standard preesistente che implementi il protocollo di Multicast. Subentra un secondo nodo…

8. ListResponse ListRequest Inizializzazione del nodo ID = 1 ID = 2 Nel momento in cui l’entrante si rende conto di essere entrato a far parte di un gruppo precostituito, provvede alla replica su sé stesso dei contenuti attualmente conservati dal cluster. Innanzitutto richiede a tutti i componenti la list completa del tree che il singolo conserva. In questo modo se la replicazione non è (come nella demo) a massima ridondanza si ottiene comunque il tree virtuale completo del cluster come visto da un client. Costituitosi il tree virtuale completo può ora procedere al recupero dei contenuti ed alla replica degli stessi nel suo spazio disco, ciò è effettuato su un canale di comunicazione privato per non sovraccaricare il canale di gruppo impropriamente

9. Costituzione del gruppo ID = 1 ID = 2 ID = 3 Non dettagliamo ulteriormente il protocollo!

10. HeartBeatStim. HeartBeatStim. HeartBeatReport HeartBeatReport HeartBeatPulse HeartBeatPulse Gestione del gruppo Nel report l’iniziatore fornisce agli altri componenti la nuova composizione del gruppo quale è quella cui è pervenuto a seguito dell’HeartBeat. Ogni nodo è tenuto a rispondere prontamente ad una stimolazione con un pulse Il protocollo di HeartBeat consente in ogni istante di verificare la corretta composizione del cluster.

11. HeartBeatStim. HeartBeatReport HeartBeatPulse Gestione del gruppo su fault Allo scadere del timeout il nodo rileva l’abbandono di 2 e notifica la nuova composizione Ogni nodo concorda ora evidentemente sulla composizione del cluster Il nodo 2 sperimenta un fault ed esce dal gruppo in maniera not-graceful (senza avvisare!) La stimolazione può raggiungere quindi il solo nodo 3… …ed all’iniziatore arriva solo il pulse di 3!

12. Who Is ?? Who Is ?? Who Is ?? ME !! ME !! ME !! Ingresso di un Client Ogni attività è riferita a ClientProxy !! Effettua una discovery per comprendere quali e quanti siano i nodi facenti parte il cluster Ogni nodo risponde comunicando le proprie caratteristiche e la lista degli altri componenti Nota la composizione del cluster il Client Proxy elegge uno qualsiasi dei nodi ed effettua una connessione dedicata

13. ListRequest List Request ListRequest List Response List Response List Response List del File System Client Proxy richiede un servizio di list al suo nodo… Il nodo intraprende il protocollo di list distribuito per ottenere lo snapshot del file system virtuale dell’intero cluster Ottenute tutte le risposte il nodo costituisce lo snapshot e lo comunica in risposta al client.

14. Download Req “ /Dir1/File2 ” Lock Request “ /Dir1/File2 ” Lock Request “ /Dir1/File2 ” Lock Agree “ /Dir1/File2 ” Lock Agree “ /Dir1/File2 ” Download di un File Individuato il file da scaricare il client ne effettua la richiesta al nodo… Il nodo intraprende il protocollo di lock distribuito di Ricart Agrawala… Ogni nodo deve rispondere se e soltanto se non ha già in lock quella risorsa o se sta richiedendola ma ha una priorità inferiore

15. Lock Release “ /Dir1/File2 ” Lock Release “ /Dir1/File2 ” Download di un File Ogni nodo deve rispondere se e soltanto se non ha già in lock quella risorsa o se sta richiedendola ma ha una priorità inferiore Il cluster concorda dunque sul fatto che il nodo 2 ha acquisito il lock su /Dir1/File2 Terminato il trasferimento al client, il nodo rilascia infine il lock sulla risorsa.

16. Create File “ /Dir1/File3 ” Lock On Create “ /Dir1/File3 ” Lock On Create “ /Dir1/File3 ” Lock Agree “ /Dir1/File3 ” Lock Agree “ /Dir1/File3 ” Create di un File Il cliente esibisce l’intenzione di creare il nuovo file comunicando al nodo anche il contenuto binario dello stesso Il protocollo di lock per creazione differisce un po’ dal precedente. Il nodo effettua la richiesta di lock Ogni nodo risponde con un Agree se e solo se non ha la risorsa.

17. Lock Release “ /Dir1/File3 ” Lock Release “ /Dir1/File3 ” Creation OK! “ /Dir1/File3 ” Create di un File Acquisito il lock il nodo salva il file in locale ed instaura delle connessioni dedicate per replicarlo su tutti i nodi Infine rilascia il lock e comunica che la creazione è stata completata con successo.

18. Create Denied “ /Dir1/File2 ” Create File “ /Dir1/File2 ” Lock On Create “ /Dir1/File3 ” Lock On Create “ /Dir1/File2 ” Lock Agree “ /Dir1/File2 ” Lock Reject “ /Dir1/File2 ” Create di un File Vediamo ora che succede se si cerca di creare un file già esistente… Il nodo 3 è l’unico a possedere la risorsa (eccezione alla replicazione). Il protocollo prevede la possibilità di reject. In presenza di almeno una reject il nodo abortisce l’operazione e comunica il fallimento al client Poniamo il caso che il nodo su cui si effettua la richiesta non possegga copia della risorsa e non si accorga del conflitto.

19. Fault tolerance di Client Proxy Supponiamo che il nodo 2, quello cui è collegato direttamente Client Proxy sperimenti un fault ed esca dal cluster

20. Fault tolerance di Client Proxy E’ opportuno che di tanto in tanto ClientProxy aggiorni la tabella di composizione del cluster richiedendola al suo nodo! All’insorgere di una nuova esigenza di servizio Client Proxy si accorge che la connessione è caduta Automaticamente e senza darne notifica al client il proxy seleziona un altro nodo dalla lista ed effettua la connessione

21. Conclusioni • Il sistema realizzato soddisfa i requisiti • Accessibile • Protocolli di Internet • Affidabile • Mediante replicazione (avanzata) il rischio di perdere i dati è drasticamente ridotto • Sempre attivo 24/7 • A meno che tutti i nodi non cadano contemporaneamente! • La disponibilità è tanto maggiore al crescere del numero di nodi

22. Conclusioni • Tuttavia… • Manca un passo di controllo di consistenza • Prima di fornire il file al client sarebbe opportuno che il nodo verificasse che la propria copia sia identica a tutte quelle del cluster attraverso, ad esempio, confronto dell’impronta hash(variante del modello di votingnella replicazione a copie attive) • Scarsa affidabilità del supporto multicast • Alla prova dei fatti si è notato che il supporto multicast di Windows XP produce, in alta congestione, consistenti perdite di messaggi • Scarsissima scalabilità • I protocolli “proprietari” implementati richiedono potenza di calcolo • Quando il numero di file e directory supera una certa soglia le perdite nel supporto di multicast rendono il sistema inutilizzabile

23. Conclusioni • A posteriori • Si suggerisce un’implementazione differente: • Ridurre l’uso del multicast alla sola discovery iniziale • Realizzare la comunicazione di gruppo come composizione di tante comunicazioni punto-punto • Eventualmente utilizzare RMI, .NET Remoting o CORBA per trasformare le procedure di comunicazione in invocazioni di metodi • In questo modo: • Gestione delle perdite di messaggi sui livelli sottostanti • Overhead di comunicazione ottimizzato • Architettura logica semplificata notevolmente (più snella)