Suggerimenti per l'archiviazione efficiente di 25 TB + milioni di file nel filesystem


11

Supponiamo che tu abbia a che fare con file di registro non compressi da 25 TB e che tu abbia a disposizione una serie di 20 scatole di merci con una capacità di archiviazione gratuita collettiva di 25 TB.

Come li conserveresti?

a) Quale file system distribuito usare?

b) Quale formato / algoritmo di compressione / decompressione?

c) Le dimensioni del file di registro vanno da 1 MB a un massimo di 7 MB di tutto il testo e molto spazio bianco

d) L'utilizzo è a) le persone desiderano i file di registro più recenti rispetto ai precedenti, quindi quale sistema di memorizzazione nella cache utilizzare b) le persone leggono solo i file di registro e non li eliminano c) le persone vogliono elencare i file di registro in un intervallo di date

e) Il sistema operativo in esecuzione sulle scatole di merci è Linux,

f) Per quanto riguarda il backup, disponiamo di un array di archiviazione che si occupa di questo. Quindi esiste la possibilità di ripristinare i dati dall'array.

Non voglio che accedano direttamente al file system. Cosa dovrei fare ? Come ottengo loro un'API basata su REST per questo?

Per favore, risparmia 2 centesimi e cosa faresti?

Ankur


Quali sistemi operativi sono in esecuzione le scatole di merci? È richiesta la tolleranza d'errore o se si perdono tutti i dati memorizzati in una casella, va bene?
Mark Henderson,

@farseeker ha modificato la domanda per rispondere alle tue domande. Grazie
Ankur Gupta,

Rileggi la domanda e la prima domanda che vorrei porre è: dove sono archiviati i 25 TB di file di registro in questo momento e possono rimanere lì?
Mark Henderson,

@farseeker su un filesystem NFS
Ankur Gupta,

Risposte:


7

Non sono un ninja di file system distribuito, ma dopo aver consolidato quante più unità possibile in quante meno macchine possibile, proverei a utilizzare iSCSI per collegare la maggior parte delle macchine a una macchina principale. Lì potrei consolidare le cose in un archivio sperabilmente tollerante ai guasti. Preferibilmente, tollerante ai guasti all'interno di una macchina (se un'unità si spegne) e tra le macchine (se un'intera macchina è spenta).

Personalmente mi piace ZFS. In questo caso, la compressione integrata, la deduplica e la tolleranza agli errori sarebbero utili. Tuttavia, sono sicuro che ci sono molti altri modi per comprimere i dati rendendoli tolleranti ai guasti.

Vorrei avere una vera soluzione di file distribuito chiavi in ​​mano da raccomandare, so che questo è davvero kludgey ma spero che ti indichi nella giusta direzione.

Modifica: sono ancora nuovo su ZFS e sto configurando iSCSI, ma ho ricordato di aver visto un video di Sun in Germania, dove mostravano la tolleranza agli errori di ZFS. Hanno collegato tre hub USB a un computer e hanno inserito quattro unità flash in ciascun hub. Quindi, per impedire a un hub di smontare il pool di archiviazione, è stato creato un volume RAIDz costituito da un'unità flash da ciascun hub. Quindi mettono insieme i quattro volumi ZFS RAIDz. In questo modo sono state utilizzate solo quattro unità flash per parità. Successivamente, ovviamente, l'hub è stato scollegato e questo ha degradato ogni zpool, ma tutti i dati erano disponibili. In questa configurazione si potrebbero perdere fino a quattro unità, ma solo se due unità non fossero nello stesso pool.

Se questa configurazione fosse utilizzata con l'unità raw di ciascuna casella, ciò preserverebbe più unità per i dati e non per la parità. Ho sentito che FreeNAS può (o sarebbe stato in grado di) condividere le unità in modo "grezzo" tramite iSCSI, quindi presumo che Linux possa fare lo stesso. Come ho già detto, sto ancora imparando, ma questo metodo alternativo sarebbe meno dispendioso dal punto di vista della parità di guida rispetto al mio suggerimento precedente. Certo, farebbe affidamento sull'uso di ZFS che non so se sarebbe accettabile. So che di solito è meglio attenersi a ciò che sai se devi costruire / mantenere / riparare qualcosa, a meno che questa non sia un'esperienza di apprendimento.

Spero sia meglio

Modifica: ho scavato e trovato il video di cui ho parlato. La parte in cui spiegano la diffusione dell'unità flash USB sugli hub inizia a 2m10s. Il video è di demo del loro server di archiviazione "Thumper" (X4500) e di come distribuire i dischi tra i controller in modo che se si verifica un errore del controller del disco rigido, i dati saranno comunque buoni. (Personalmente penso che questo sia solo un video di geek che si divertono. Vorrei avere una scatola Thumper io stesso, ma a mia moglie non piacerebbe che facessi passare un pallet in casa.: D Questa è una scatola grande.)

Modifica: mi sono ricordato di aver attraversato un file system distribuito chiamato OpenAFS . Non ci avevo provato, ne avevo solo letto un po '. Forse altri sanno come gestisce nel mondo reale.


4

Innanzitutto, i file di registro possono essere compressi con rapporti molto elevati. Trovo che i miei file di registro vengano compressi con un rapporto di 10: 1. Se vengono compressi anche con un rapporto di 5: 1, sono solo 5 GB o il 20% della capacità di archiviazione.

Dato che hai spazio di archiviazione più che sufficiente, l'algoritmo di compressione specifico non è troppo importante. Potresti...

  • Utilizzare i file zip se gli utenti Windows accederanno direttamente ai file.
  • Usa gzip se saranno accessibili tramite Linux e la decompressione rapida è importante.
  • Usa bzip2 se saranno accessibili tramite Linux ed è importante avere i file più piccoli possibili.

La domanda più grande è: come hai intenzione di fornire ai tuoi utenti un facile accesso a questi file? Parte di ciò dipende dalla configurazione delle macchine.

Se riesci a mettere abbastanza spazio di archiviazione in un singolo computer, puoi fare qualcosa di estremamente semplice, come una condivisione di file Windows di sola lettura. Basta organizzare i file in sottodirectory e sei pronto per partire.

Se non è possibile creare un singolo file server per questi file, è possibile che sia necessario un file system distribuito. Windows ha un file system distribuito (DFS) che potrebbe soddisfare le tue esigenze.

Se le esigenze sono più avanzate, è possibile che si desideri un'applicazione Web come front-end in cui gli utenti possano sfogliare e scaricare i file di registro. In questo caso, consiglio di utilizzare MogileFS, che è un file system distribuito progettato per essere utilizzato con un server delle applicazioni front-end. È molto facile da integrare con la maggior parte dei linguaggi di programmazione web. Non è possibile montarlo come unità condivisa sul computer, ma è di prim'ordine come archivio dati per un'applicazione Web.


Cordiali saluti: Windows DFS è un modo per mantenere sincronizzati file / cartelle su più server. Non ti consentirà di utilizzare l'archiviazione su più server come singola unità di archiviazione. microsoft.com/windowsserversystem/dfs/default.mspx
Scott McClenning,

Dopo averci pensato, hai ragione; DFS può essere in grado di essere utilizzato se si dispone di un punto radice DFS per le cartelle che vivono su altri computer. In questo modo l'utente vedrebbe una struttura di file e non avrebbe bisogno di sapere su quali macchine i dati vivono effettivamente, lo saprebbe DFS. Funzionerebbe. Di solito quando le persone mi chiedono di Windows DFS, di solito pensano che sia un modo per raggruppare insieme lo spazio di archiviazione, ed è per questo che sono solo a questa conclusione. Ci dispiace e il tuo diritto potrebbe funzionare.
Scott McClenning,

2

lessfs è un file system di deduplicazione e compressione. Sebbene non risolva l'intero problema, può valere la pena dare un'occhiata a come backend.


2

esportare queste cartelle tramite NFS

montali su un unico computer con apache in esecuzione (sotto la radice del documento) come un albero

usa zip per comprimerli - buon rapporto di compressione, zip può essere aperto da tutti i sistemi operativi

elenca i file in Apache-così stai dando agli utenti l'accesso di sola lettura (i file di registro non devono essere modificati, giusto)


1
Accetto su nfs + httpd, in disaccordo su zip. gzip interagisce meglio con http.
Tobu,

+1 per il commento gzip da @Tobu - Con la giusta configurazione, Apache può inviare file gzip a un browser Web che li decomprimerà in modo trasparente e li visualizzerà. Gli utenti non hanno nemmeno bisogno di conoscere la compressione.
Christopher Cashell,

0

Hai mai pensato di comprimere i file di registro? Quindi fai qualcosa sul frontend per decomprimerli prima di servirli all'utente finale. Forse una sorta di sceneggiatura CGI.


0

@Ankur e @Porch. Sono pienamente d'accordo con la necessità di comprimere questi registri.

@jet Penso che lo schema più semplice sia migliore, quindi httpd per l'utente finale è vicino all'ideale. E il backend potrebbe essere qualsiasi.

La mia opinione: dividere i registri in 2 gruppi: cartelle "vecchie" e "nuove".

Uniscili nella radice del documento di httpd. Utilizzare una compressione forte per quelli vecchi (archivi xz o 7z, popolari per tutti i sistemi operativi) con dizionario di grandi dimensioni e dimensioni dei blocchi, possono essere anche archivi solidi.

Usa la compressione di fs per quelli nuovi: lessfs (rw, deduplicazione + metodi di compressione leggera), fusecompress 0.9.x (rw, metodi di compressione da leggera a forte), btrfs / zfs, squashfs (ro, metodi di compressione da leggera a forte, alcuni dedup, uso per i log appena ruotati).

È anche possibile scrivere in modo trasparente registri in file compressi (fusecompress, lessfs, btrfs / zfs). Fornire accesso R / o tramite httpd ai log in fase di scrittura. Saranno trasparenti per gli utenti e decompressi in modo trasparente per loro.

Avvertenze su fusecompress: 1) utilizzare solo 0.9.x - è stabile. Clona da qui https://github.com/hexxellor/fusecompress

Le versioni successive non supportano bene lzma o perdono dati.

2) usa solo 1 core cpu per comprimere un file, quindi potrebbe essere lento.

Ricomprimi ogni registro nella cartella "nuova", più vecchia di qualche tempo (diversi mesi) e passa alla "vecchia".

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.