H A F SHigh Availability File System

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

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.

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)

Architettura

Group Channel

Client

ClientProxy

NodeA NodeB

NodeC NodeD

Nodo del clusterIl riquadro grigio vuole

rappresentare il fatto che dall’esterno il gruppo di nodi appare come un tutto unico

Canale di GruppoCanale di comunicazione comune

(interno ed esterno al cluster) usato dai nodi per il coordinamento

e dai client per la discovery

Canale PrivatoUsato nelle comunicazioni

impegnative (ad es. trasferimento file) per non

impegnare il canale comune

Client ProxyIntermediario 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 secondariconnessione ad uno specifico nodo

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

Costituzione del gruppo

Group Channel

RequestForJoin

ID = 1

RequestForJoinJoinAccept

ID = 2

Cluster ClusterCluster

1 (me)

Cluster

1 (me)

2

Cluster

1

2 (me)

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…

Inizializzazione del nodo

Group Channel

ID = 1 ID = 2

Cluster ClusterCluster

1 (me)

Cluster

1 (me)

2

Cluster

1

2 (me)

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.

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

Costituzione del gruppo

Group Channel

ID = 1 ID = 2

Cluster ClusterCluster

1 (me)

Cluster

1 (me)

2

Cluster

1

2 (me)

Non dettagliamo ulteriormente il protocollo!

ClusterCluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

ID = 3

Gestione del gruppo

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

HeartBeatPulseHeartBeatStim.HeartBeatStim.

HeartBeatPulse

HeartBeatReportHeartBeatReport

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 l’iniziatore fornisce agli altri componenti la nuova composizione del gruppo quale è quella cui è pervenuto a seguito dell’HeartBeat.

Gestione del gruppo su fault

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

HeartBeatStim.

HeartBeatPulse

HeartBeatReport

Cluster

1 (me)

3

Cluster

1

3 (me) 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!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

Ingresso di un Client

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

Who Is ??

Effettua una discovery per comprendere quali e quanti siano i nodi facenti parte il cluster

Ogni attività è riferita a ClientProxy !!

Who Is ?? Who Is ??

Ogni nodo risponde comunicando le proprie caratteristiche e la lista degli altri componenti

ME !!

ME !!

ME !!

Cluster

1

2

3

Nota la composizione del cluster il Client Proxy elegge uno qualsiasi dei nodi ed effettua una connessione dedicata

List del File System

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

Client Proxy richiede un servizio di list al suo nodo…

ListRequest

List Request

Cluster

1

2

3

Il nodo intraprende il protocollo di list distribuito per ottenere lo snapshot del file system virtuale dell’intero cluster

ListRequest

List Response

List Response

List Response

Ottenute tutte le risposte il nodo costituisce lo snapshot e lo comunica in risposta al client.

/

Dir1

File1

File2

Dir2

Download di un File

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

Cluster

1

2

3

Individuato il file da scaricare il client ne effettua la richiesta al nodo…

/

Dir1

File1

File2

Dir2

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 ”

Download di un File

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

Cluster

1

2

3

/

Dir1

File1

File2

Dir2

Ogni nodo deve rispondere se e soltanto se non ha già in lock quella risorsa o se sta richiedendola ma ha una priorità inferiore

Locked

Il cluster concorda dunque sul fatto che il nodo 2 ha acquisito il lock su /Dir1/File2

Locked

Terminato il trasferimento al client, il nodo rilascia infine il lock sulla risorsa.

Lock Release“ /Dir1/File2 ”Lock Release“ /Dir1/File2 ”

Create di un File

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

Cluster

1

2

3

/

Dir1

File1

File2

Dir2

Il cliente esibisce l’intenzione 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 ”

Create di un File

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

Cluster

1

2

3

Lock Release“ /Dir1/File3 ”

/

Dir1

File1

File2

Dir2

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 ”

/

Dir1

File1

File2

Dir2

File3

Create di un File

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

Cluster

1

2

3

Create Denied“ /Dir1/File2 ”

/

Dir1

File1

File2

Dir2

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 è 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

Fault tolerance di Client Proxy

Group Channel

Cluster

1

2

3 (me)

Cluster

1

2 (me)

3

Cluster

1 (me)

2

3

Cluster

1

2

3

/

Dir1

File1

File2

Dir2

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

Cluster

1 (me)

3

Cluster

1

3 (me)

Fault tolerance di Client Proxy

Group Channel

Cluster

1

2

3 (me)

Cluster

1 (me)

2

3

Cluster

1

2

3

/

Dir1

File1

File2

Dir2

All’insorgere di una nuova esigenza di servizio Client Proxy si accorge che la connessione è caduta

Cluster

1 (me)

3

Cluster

1

3 (me)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!

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

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 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

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)