File system distribuito geograficamente con località preferita

Sto creando un'applicazione che deve distribuire un file server standard su alcuni siti su una WAN. Fondamentalmente, ogni sito deve scrivere un sacco di file vari di varie dimensioni (alcuni nell'intervallo di 100 MB, ma la maggior parte piccoli) e l'applicazione è scritta in modo tale che le collisioni non siano un problema. Mi piacerebbe avere un sistema impostato che soddisfi le seguenti qualifiche:

1. Ogni sito può archiviare file in uno "spazio dei nomi" condiviso. Cioè, tutti i file verrebbero visualizzati nello stesso filesystem.
2. Ogni sito non invierebbe dati tramite WAN a meno che non sia necessario. Vale a dire, ci sarebbe spazio di archiviazione locale su ciascun lato della WAN che verrebbe "unito" nello stesso filesystem logico.
3. Linux & Free ($$$) è un Plus

Fondamentalmente, qualcosa come una condivisione NFS centrale soddisferebbe la maggior parte dei requisiti, tuttavia non permetterebbe ai dati scritti localmente di rimanere locali. Tutti i dati dai lati remoti della WAN verrebbero sempre copiati localmente.

Ho esaminato Lustre e ho eseguito con successo alcuni test con esso, tuttavia, sembra distribuire i file in modo abbastanza uniforme sullo storage distribuito. Ho esaminato la documentazione e non ho trovato nulla che "preferirà" automaticamente l'archiviazione locale rispetto all'archiviazione remota. Anche qualcosa che è andato con la memoria a latenza più bassa andrebbe bene. Funzionerebbe il più delle volte, il che soddisferebbe i requisiti di questa applicazione.

Alcune risposte ad alcune domande poste di seguito:

• Nodi server: 2 o 3 per l'avvio. Ogni server avrebbe dozzine di connessioni simultanee di lettura / scrittura.
• La topologia WAN è full mesh e affidabile. (grande azienda, il costo non è così limitante come la burocrazia)
• Failover del client: in realtà non avevo pensato di fare il failover dei client (soprattutto perché la nostra attuale applicazione non lo fa in un solo sito). Suppongo che la risposta pratica sia che i server di ciascun sito distribuito geograficamente dovrebbero rappresentare singoli punti di errore per i client che servono. Tuttavia, se stai pensando a qualcosa di specifico qui, penso che sarebbe abbastanza germano alla discussione.
• Roll-my-own: ho pensato a rsync / unison, tuttavia avrei bisogno di un po 'di logica elaborata per rendere la parte "dinamica" di questo lavoro senza problemi. Vale a dire, il file sembra essere locale, ma viene recuperato solo su richiesta.
• MS-DFS: Sembra certamente essere qualcosa che dovrei esaminare. Il mio problema principale sarebbe potenzialmente incerto sulla configurazione / affidabilità / prestazioni del server NFS su Windows, poiché molti dei client che si connettono sono client NFS.

Peccato per il requisito Linux. Questo è esattamente ciò che fa Windows DFS. Dal 2003 R2, lo fa anche a livello di blocco.

Alcune domande:

• Quanti nodi "server" stai pensando di partecipare a questa cosa?

• Com'è la topologia di connettività WAN: hub e raggio, full mesh? Quanto è affidabile?

• Ti aspetti che i client eseguano il failover su un server geograficamente non locale nel caso in cui il server locale fallisca?

Windows DFS-R sarebbe sicuramente quello che stai cercando, anche se per alcuni costi di licenza potenzialmente pesanti.

Dici che le collisioni non sono un problema e non hai bisogno di un gestore dei blocchi distribuito, quindi puoi farlo con strumenti userland come rsync o Unison ed esportare il corpus di file risultante con NFS nei client locali. È brutto e dovresti riuscire a mettere insieme un qualche tipo di sistema per gestire la generazione di una topologia di replica e l'esecuzione degli strumenti dell'utente, ma sarebbe certamente economico con il costo delle licenze.

Hai considerato AFS ?

Andrew File System (AFS) è un file system di rete distribuito che utilizza un set di server affidabili per presentare uno spazio dei nomi file omogeneo e trasparente per la posizione a tutte le workstation client.

A quanto ho capito, gran parte del recente sviluppo è stato alla base del progetto OpenAFS .

Non posso pretendere di avere abbastanza familiarità con il progetto per sapere se la funzione "località preferita" è disponibile, ma per il resto sembra una buona scelta.

Hai visto i pool OST a Lustre?

Non sarà automatico, ma con i pool OST è possibile assegnare directory / file a OST / OSS specifici, in pratica l'allocazione di archiviazione basata su criteri, anziché il round robin / striping predefinito su OST.

Quindi è possibile impostare una directory per sito e assegnare quella directory agli OST locali per quel sito, che indirizzerà tutti gli I / O agli OST locali. Sarà ancora uno spazio dei nomi globale.

C'è molto lavoro da fare per migliorare le connessioni Lustre su WAN (server di memorizzazione nella cache locali e cose del genere) ma è ancora tutto in fase di sviluppo AFAIK.

Forse NFS ma con Cachefs sui server delle applicazioni raggiungerà la tua parte del tuo obiettivo. A quanto ho capito, tutto ciò che è scritto andrà comunque al server centrale, ma almeno le letture potrebbero finire per essere memorizzate nella cache locale. Ciò potrebbe potenzialmente ritardare molto le letture a seconda dei modelli di utilizzo.

Inoltre, vale la pena esaminare mabye UnionFS. Con questo penso che ogni posizione sarebbe un'esportazione NFS, e quindi potresti usare UnionFS in ogni posizione per avere quella e tutte le altre montature NFS dalla posizione appaiono come un filesystem. Non ho esperienza con questo però.

È possibile esaminare DRBD per replicare i dischi. http://www.drbd.org/ . Questa è una soluzione linux ad alta disponibilità che è appena entrata nel kernel.

Tuttavia, questo ha alcune limitazioni:

1. È possibile impostare solo due nodi
2. La WAN potrebbe essere troppo inaffidabile per mantenere robusto il DRBD.

Se vuoi mantenerlo semplice, dai un'occhiata a rsync, risolve molti problemi e può essere scritto.

Controlla chironfs .

Forse può fare quello che vuoi, sulla base del file system.

Btsync è un'altra soluzione con cui ho avuto una buona esperienza. Utilizza il protocollo BitTorrent per trasferire i file, quindi più server hai, più veloce è la sincronizzazione di nuovi file.

A differenza della soluzione basata su rsync, rileva quando si rinominano i file / le cartelle e li rinomina su tutti i nodi anziché eliminare / copiare.

I client btsync possono quindi condividere le cartelle su una rete locale.

L'unico aspetto negativo che ho riscontrato (rispetto a MS DFS) è che non rileverà una copia del file locale. Invece lo interpreterà come un nuovo file e verrà caricato su tutti i peer.

Finora btsync sembra essere la migliore soluzione di sincronizzazione e può essere installata su dispositivi Windows, Linux, Android e ARM (ad es. NAS)