H A F S High Availability File System. Obiettivi Realizzare un servizio di File System che sia: Accessibile Fruibile in remoto e condiviso da tutti gli.

Presentazione sul tema: "H A F S High Availability File System. Obiettivi Realizzare un servizio di File System che sia: Accessibile Fruibile in remoto e condiviso da tutti gli."— Transcript della presentazione:

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 Sempre Attivo 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 allinsorgere 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 Larchitettura 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. Lorganizzazione paritetica allinterno del cluster fa si che il guasto su un membro non influenzi (negativamente) la funzionalità dellintero sistema (nello specifico che non provochi uninterruzione del servizio)

5 Architettura Nodo del cluster Il riquadro grigio vuole rappresentare il fatto che dallesterno il gruppo di nodi appare come un tutto unico Canale di Gruppo Canale di comunicazione comune (interno ed esterno al cluster) usato dai nodi per il coordinamento e dai client per la discovery Canale Privato Usato nelle comunicazioni impegnative (ad es. trasferimento file) per non impegnare il canale comune 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 canali secondari connessione ad uno specifico nodo

6 Client Proxy Client Proxy è lagente del cluster che permette al client un interfacciamento trasparente allallocazione ed alla composizione Allavvio 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 Costituzione del gruppo RequestForJoin ID = 1 RequestForJoin JoinAccept ID = 2 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. 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. Il canale di gruppo è un supporto standard preesistente che implementi il protocollo di Multicast. 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. Subentra un secondo nodo…

8 Inizializzazione del nodo ID = 1ID = 2 Nel momento in cui lentrante 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. ListResponse 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. ListRequest 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 = 1ID = 2 Non dettagliamo ulteriormente il protocollo! ID = 3

10 Gestione del gruppo HeartBeatPulseHeartBeatStim. HeartBeatPulseHeartBeatReport Il protocollo di HeartBeat consente in ogni istante di verificare la corretta composizione del cluster. Ogni nodo è tenuto a rispondere prontamente ad una stimolazione con un pulse Nel report liniziatore fornisce agli altri componenti la nuova composizione del gruppo quale è quella cui è pervenuto a seguito dellHeartBeat.

11 Gestione del gruppo su fault HeartBeatStim.HeartBeatPulseHeartBeatReport 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 alliniziatore arriva solo il pulse di 3! Allo scadere del timeout il nodo rileva labbandono di 2 e notifica la nuova composizione Ogni nodo concorda ora evidentemente sulla composizione del cluster

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

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

14 Download di un File Individuato il file da scaricare il client ne effettua la richiesta al nodo… Download Req /Dir1/File2 Lock Request /Dir1/File2 Lock Request /Dir1/File2 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 Lock Agree /Dir1/File2 Lock Agree /Dir1/File2

15 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. Lock Release /Dir1/File2 Lock Release /Dir1/File2

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

17 Create di un File Lock Release /Dir1/File3 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. Lock Release /Dir1/File3 Creation OK! /Dir1/File3

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

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 Allinsorgere 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 E opportuno che di tanto in tanto ClientProxy aggiorni la tabella di composizione del cluster richiedendola al suo nodo!

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 dellimpronta hash (variante del modello di voting nella 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 unimplementazione differente: Ridurre luso 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)

24 Repository di componenti grafici Lock Agree /Dir1/File3