Archiviazione e backup di 10 milioni di file su Linux


25

Gestisco un sito Web in cui sono archiviati circa 10 milioni di file (copertine di libri) in 3 livelli di sottodirectory, che vanno da [0-f]:

0/0/0/
0/0/1/
...
f/f/f/

Questo porta a circa 2400 file per directory, il che è molto veloce quando dobbiamo recuperare un file. Questa è inoltre una pratica suggerita da molte domande .

Tuttavia, quando ho bisogno di fare il backup di questi file, ci vogliono molti giorni solo per sfogliare le directory 4k che contengono file da 10m.

Quindi mi chiedo se potrei archiviare questi file in un contenitore (o in contenitori 4K), ognuno dei quali si comporterebbe esattamente come un filesystem (una specie di contenitore ext3 / 4 montato?). Immagino che sarebbe quasi altrettanto efficace dell'accesso diretto a un file nel filesystem e questo avrebbe il grande vantaggio di essere copiato su un altro server in modo molto efficiente.

Qualche suggerimento su come farlo meglio? O qualche alternativa praticabile (noSQL, ...)?


Quale file system stai usando in questo momento?
cmcginty,

NetApp è leccatamente un'opzione se puoi confortare i prezzi
Ian Ringrose,

Sto usando ext4 in CentOS 5.6
Benjamin,

1
Curioso perché dovrebbero essere necessari "molti giorni solo per sfogliare le directory 4k che contengono file da 10m", che sembra troppo lento. Supponendo 150 byte per percorso, i nomi di file da 10m producono 1,5 GB di dati, quindi potrebbe essere la memoria / CPU disponibile (incluso l'ordinamento del risultato). Inoltre, controlla se abilitare / disabilitare dir_index aiuta: lonesysadmin.net/2007/08/17/… e vari suggerimenti su serverfault.com/questions/183821/…
RichVel

Nota 5 anni dopo: ho migrato tutto su Amazon S3, che è perfettamente adatto per archiviare una così grande quantità di file. Inoltre non devo più dividere i file in 3 livelli di sottodirectory, poiché per S3 non fa alcuna differenza (un percorso è un percorso, sia che contenga barre o meno). E posso dormire meglio, sapendo che i miei dati vengono replicati in modo sicuro in più posizioni.
Benjamin,

Risposte:


11

Opzioni per l'accesso rapido e il backup di milioni di file

Prendi in prestito da persone con problemi simili

Questo suona molto come un tipo di problema più semplice che deve affrontare i server di notizie USENET e i proxy Web di memorizzazione nella cache: centinaia di milioni di piccoli file a cui si accede in modo casuale. Potresti voler prendere un suggerimento da loro (tranne che in genere non devono mai fare backup).

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

Ovviamente la natura ciclica del filesystem di notizie cicliche è irrilevante per te, ma il concetto di livello inferiore di avere più file / dispositivi su disco con immagini compresse e un indice veloce dalle informazioni che l'utente fornisce per cercare le informazioni sulla posizione è molto appropriato.

File system dedicati

Naturalmente, questi sono concetti simili a quelli di cui parlavano le persone creando un file system in un file e montandolo su loopback, tranne per il fatto che si riesce a scrivere il proprio codice del file system. Naturalmente, dal momento che hai detto che il tuo sistema era in gran parte letto, potresti effettivamente dedicare una partizione del disco (o partizione lvm per la flessibilità nel dimensionamento) a questo scopo. Quando si desidera eseguire il backup, montare il filesystem in sola lettura e quindi creare una copia dei bit di partizione.

LVM

Ho menzionato LVM sopra come utile per consentire il dimensionamento dinamico di una partizione in modo che non sia necessario eseguire il backup di molto spazio vuoto. Ma, naturalmente, LVM ha altre caratteristiche che potrebbero essere molto applicabili. In particolare la funzionalità "snapshot" che consente di bloccare un filesystem in un momento. Qualsiasi accidentale rm -rfo altro non disturberebbe l'istantanea. A seconda di ciò che si sta tentando di fare, ciò potrebbe essere sufficiente per le esigenze di backup.

RAID-1

Sono sicuro che hai già familiarità con RAID e probabilmente lo usi già per affidabilità, ma RAID-1 può essere utilizzato anche per i backup, almeno se stai utilizzando RAID software (puoi usarlo con RAID hardware, ma in realtà offre una minore affidabilità perché potrebbe essere necessario leggere lo stesso modello / controller di revisione). Il concetto è che crei un gruppo RAID-1 con un disco in più di quello di cui hai effettivamente bisogno per le tue normali esigenze di affidabilità (es. Un terzo disco se usi il software RAID-1 con due dischi, o forse un disco grande e un hardware- RAID5 con dischi più piccoli con un software RAID-1 sopra l'hardware RAID-5). Quando arriva il momento di eseguire un backup, installare un disco, chiedere a mdadm di aggiungere quel disco al gruppo raid, attendere fino a quando non indica completezza, facoltativamente chiedere uno scrub di verifica, quindi rimuovere il disco. Ovviamente,


Risposta molto completa, che riassume le buone soluzioni. Penso che manterrò la mia struttura di filesystem esistente e userò snapshot LVM, che sembra essere perfetto per il mio caso d'uso.
Benjamin,

9

È possibile montare un filesystem virtuale utilizzando il gestore di loopback ma mentre ciò accelererebbe il processo di backup, potrebbe influire sulle normali operazioni.

Un'altra alternativa è il backup dell'intero dispositivo tramite dd. Ad esempio dd if=/dev/my_device of=/path/to/backup.dd,.


+1 Il backup del dispositivo stesso è una buona idea.
asm

3
Dovresti, se usi questo approccio, testare il ripristino (bene, dovresti sempre farlo), perché se il tuo input è un disco come / dev / sdd, dd memorizzerà la partizione sheme e le dimensioni. Se lo ripristini su un disco più piccolo, otterrai errori e, se lo ripristini su un disco più grande, apparirà troncato. Funzionerà meglio se ripristini i dati su un altro esemplare dello stesso tipo di disco. Il ripristino delle sole partizioni (/ dev / sdd1) sarà meno problematico.
utente sconosciuto

1
Notare che se il dispositivo si trova su LVM, è anche possibile eseguire un backup senza smontare il disco utilizzando le istantanee LVM.
bdonlan,

Secondo, l'approccio di backup dell'istantanea LVM. Ho sfruttato lvm in passato per la replica DR dal vivo. L'uso di dd in combinazione con le istantanee semplifica l'esecuzione di backup rapidi a livello di blocco.
slashdot,

Ho provato ddsopra nce questo fa un lavoro buono! Tuttavia, potrei avere dati incoerenti / danneggiati, invece di utilizzare le istantanee LVM invece della partizione live.
Benjamin,

8

Come probabilmente saprai, il tuo problema è la località. Una ricerca del disco tipica richiede circa 10 ms. Quindi, chiamare semplicemente "stat" (o open ()) su 10 milioni di file posizionati casualmente richiede 10 milioni di ricerche, o circa 100000 secondi, o 30 ore.

Quindi è necessario inserire i file in contenitori più grandi, in modo tale che il numero rilevante sia la larghezza di banda dell'unità (50-100 MB / sec per un singolo disco, in genere) anziché il tempo di ricerca. Inoltre, puoi lanciarvi un RAID, che ti consente di aumentare la larghezza di banda (ma non ridurre i tempi di ricerca).

Probabilmente non ti sto dicendo nulla che non conosci già, ma il mio punto è che la tua idea di "contenitore" risolverà definitivamente il problema, e praticamente qualsiasi contenitore lo farà. I montaggi di loopback probabilmente funzioneranno come qualsiasi altra cosa.


Sì, la località è cruciale. Guarda i tuoi schemi di utilizzo. La maggior parte dei problemi tende a seguire il Principio di Pareto (80% dei processi che colpiscono il 20% dei dati), quindi se potessi capire quali file devono essere memorizzati nella cache o semplicemente mettere su una partizione separata con un diverso layout di directory, quindi richiede meno ricerche o ricerche di directory, probabilmente aiuterebbe molto. Anche la diffusione dei file a cui si accede frequentemente su diversi mandrini di dischi in modo che le ricerche possano essere eseguite in parallelo potrebbe essere di aiuto. +1 per @nemo per aver richiamato la località di riferimento.
Marcin,

5

Ci sono un paio di opzioni. Il più semplice, e dovrebbe funzionare con tutti i filesystem Linux, è ddcopiare l'intera partizione ( /dev/sdb3o /dev/mapper/Data-ImageVol) su una singola immagine e archiviarla. In caso di ripristino di singoli file, montare in loopback l'immagine ( mount -o loop /usr/path/to/file /mountpoint) e copiare i file necessari. Per un ripristino completo della partizione, è possibile invertire la direzione del ddcomando iniziale , ma in realtà è necessaria una partizione di dimensioni identiche.

A giudicare dal tuo caso d'uso, immagino che i singoli ripristini di file siano un evento molto raro, se mai si verificano affatto. Questo è il motivo per cui un backup basato su immagini ha davvero senso qui. Se è necessario eseguire ripristini individuali più spesso, l'utilizzo di snapshot LVM per fasi sarà molto più conveniente; ma è comunque necessario eseguire il backup basato su immagini per i disastri critici "abbiamo perso tutto". I ripristini basati su immagini tendono ad andare molto più velocemente rispetto ai ripristini basati su tar semplicemente perché stanno solo ripristinando i blocchi, non stanno subendo un bel po 'di operazioni di metadati con ogni fopen / fclose e possono anche essere un'operazione su disco altamente sequenziale per ulteriori aumenti di velocità.

In alternativa, come sottolineato dal video di Google @casey a metà strada, XFS è un ottimo file system (se complesso). Una delle utility più belle con XFS è l' xfsdumputility, che scaricherà un intero file system in un singolo file e generalmente lo farà più velocemente di quanto tarpossa. È un'utilità specifica del filesystem, quindi può trarre vantaggio dagli interni di fs in modi che tar non può.


Molte buone risposte lì! XFS sembra essere interessante, ma temo che sia un po 'fuori dalla mia portata.
Benjamin,


2

Forse una risposta semplicistica, ma il mio primo pensiero è stato quello di utilizzare qualcosa come GridFS che si basa su MongoDB . Molti dei driver di lingua principale lo supportano immediatamente, quindi dovresti essere in grado di scambiarlo con le sezioni di lettura dei file del tuo codice. Inoltre, potresti semplicemente rendere le tue directory esistenti le chiavi di questi file.

Un problema che potresti avere è che Mongo tende a rallentare abbastanza velocemente se cerca continuamente dal disco. Con 10 milioni di file, mi aspetto che la maggior parte dei tuoi dati sarà su disco. I blocchi di file in GridFS sono 4 MB, per quanto ricordo, quindi se i tuoi file sono più grandi di quello, eseguirai diverse operazioni costose per ottenere un file. La chiave, penso, sarebbe quella di frammentare i tuoi file in base alla tua struttura di directory già ordinata in modo da poter avere diverse istanze di Mongo in esecuzione su più scatole per alleggerire il carico. Tuttavia, non so quali siano i tuoi requisiti di prestazione, quindi potrei pensarci troppo.

Qual è il vantaggio di tutto questo? Prestazioni che corrispondono abbastanza da vicino alle letture del disco se eseguite correttamente. Inoltre, Mongo offre diversi modi integrati per eseguire rapidamente il backup dell'intera fascia di dati in un'istanza di database, e anche con il database ancora in esecuzione.


Daremo sicuramente un'occhiata a GridFS che non conoscevo, ma penso che finirò per mantenere tutto basato sul filesystem per ridurre la quantità di lavoro, dato che tutto funziona già!
Benjamin,

1

Se sei soddisfatto di un modello di dispositivo per l'archiviazione dei dati, forse potresti prendere in considerazione NexentaStor . Esegue ZFS su OpenSolaris sotto copertura, ma tutta l'amministrazione avviene tramite una GUI web.

Ci sono un paio di funzioni che potrebbero aiutarti a risolvere il tuo problema.

  • La versione Enterprise supporta una forma di replica remota basata su snapshot che non richiede la scansione dell'intero filesystem.

  • Se non ti dispiace sporcarti le mani, ZFS ha un comando ZFS diff molto utile che ti dice in modo efficiente quali file sono stati aggiunti, modificati o eliminati dall'ultima istantanea, senza dover scansionare l'intero file system. È possibile incorporarlo nel sistema di backup per ridurre notevolmente il tempo necessario per eseguire backup incrementali.


Grazie, lo darò un'occhiata. Forse aggiungerebbe un po 'di complessità al mio progetto!
Benjamin,

1

È possibile utilizzare dumpun'utilità standard per il backup del filesystem EXT4 con molti file. Questa utility controlla innanzitutto quali blocchi vengono utilizzati su un filesystem e quindi li esegue il backup nell'ordine del disco, eliminando la maggior parte delle ricerche.

Esiste restoreun'utilità corrispondente per ripristinare i backup creati da dump.

Supporta backup incrementali utilizzando i livelli - file di backup di livello 1 modificati dall'ultimo backup di livello 0 (completo), livello 2 - modificati dal backup di livello 1 e così via.


0

Per i backup incrementali, un'opzione sarebbe quella di avere un secondo albero delle ombre per le nuove copertine. Cioè, avresti il ​​tuo albero principale che viene utilizzato per tutte le operazioni di lettura. Avresti anche una newfiles/012345.....jpgdirectory; le copertine appena aggiunte creano un collegamento fisico qui e nell'albero principale. Quando si eseguono backup, è possibile eseguire occasionalmente il backup dell'albero principale, ma eseguire il backup dell'albero (molto più piccolo) newfilesmolto più regolarmente.

Si noti che per mantenere l' newfilesalbero piccolo, prima di eseguire un nuovo backup dell'albero principale, è possibile svuotare l'albero dei newfile:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

Una volta che lo fai, ovviamente, ti impegni a produrre un nuovo backup dell'albero principale.


Approccio interessante, grazie per averlo condiviso. Temo che comporterebbe molte modifiche nell'applicazione e che sarebbe difficile mantenere l'applicazione e le esigenze di archiviazione in due livelli separati.
Benjamin,

0

L'aggiunta di un po 'di concorrenza di solito aiuta.

Ho un problema simile a te; nel mio caso devo eseguire il backup di circa 30 milioni di file, molti dei quali sono file HTML, PHP o JPEG. Per me BackupPC + rsync su ssh funziona in modo OK; il backup completo richiede circa un giorno, ma gli incrementali di solito finiscono in un paio d'ore.

Il trucco è aggiungere ogni directory di livello principale (0, 1, 2 ... a, b, c ...) come nuova destinazione da copiare in BackupPC e lasciare che esegua il backup in parallelo, in modo da eseguire contemporaneamente il backup delle directory un/ , b / , c / * e così via. A seconda del sottosistema del disco, qualsiasi cosa tra un paio di processi e circa 10 processi è probabilmente il modo più rapido per eseguire il backup.

Anche le istantanee LVM e il backup a livello di blocco sono un'opzione, ma con BackuPC e il backup a livello di file è ancora possibile ripristinare singoli file o directory, se necessario.


Sono sorpreso che il backup delle directory root risolva contemporaneamente il problema per te, mi aspetto che sia effettivamente più lento. Tutte le directory sono sullo stesso disco? Stai usando un SSD?
Benjamin,

I file di dati sono memorizzati su SAN.
Janne Pikkarainen,

Bene, ora ha senso, ottieni efficienza accedendo a più file contemporaneamente, perché le tue diverse cartelle si trovano molto probabilmente fisicamente su unità diverse nella SAN, o almeno replicate su più unità, il che consente l'accesso simultaneo. Sono basato solo su un RAID-1, quindi suppongo che sopra due accessi simultanei, la mia velocità molto probabilmente diminuirà.
Benjamin,

0

Benjamin,

Penso che il tuo problema possa essere risolto al numero di file per livello di directory!

Il tempo di accesso cambia di un fattore significativo se si memorizzano 20.000 file in una directory?

Hai anche pensato di archiviare i metadati del filesystem su un'unità di accesso più veloce separata (come un SSD).


0

Consiglierei invece un buon vecchio database relazionale.

Userei un PostgreSQL con, diciamo, 256 tabelle partizionate (cover_00, cover_01, ..., cover_ff) con dati immagine come byteacolonna (binaria) con memoria esterna, con identificatore di file come chiave primaria. Il recupero di un'immagine sarebbe rapido (grazie a un indice sulla chiave primaria), l'integrità dei dati sarebbe garantita (database conforme ACID), il backup sarebbe nell'ordine del disco, quindi non troppo da cercare.

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.