File system Linux per un file server di grandi dimensioni

Vorrei sapere, da persone più esperte, quale sarebbe la scelta migliore del file system da utilizzare per un file server con più di 20 TB di dischi rigidi. Personalmente ho sempre usato EXT3 (ai tempi) e EXT4 (dal momento che disponibile) [e una volta ReiserFS 3 anche se ha causato molti danni ai dati] sui miei personal computer e sui dischi BOOT e ROOT dei "piccoli server".

Tuttavia, poiché gli strumenti EXT4 (sebbene non EXT4 stesso) sono limitati a partizioni da 16 TB, questa potrebbe non essere la mia scommessa migliore. La distribuzione sarà Debian 6.0 (Squeeze) e / o Gentoo (ultima versione), quindi il kernel dovrebbe essere piuttosto recente (su Debian almeno con backport), il che significa kernel Linux> = 2.6.32.

Il file server verrà utilizzato per tre scopi maliziosi (e anche partizioni separate, perché lo scopo è quello di mantenere i dati "sicuri" e non preoccuparsi molto del sovraccarico). Tutti i dischi devono tuttavia essere crittografati tramite LUKS :

1. Media, download e repository debian locale [Ho almeno 6 macchine che eseguono Debian]> 20 TB (forse ulteriore separazione tra media, download e repository Debian)
2. Dati (documenti, foto, ...) ~ 4 TB SICURI (che significa raid1 o raid6 + disco di backup)
3. Backup> = 20 TB per i backup di altri computer nella mia gigabit lan (puoi suggerire un software che esegue il backup dell'intero sistema operativo anche se è Windows, BackupPC dice che lo fa, qualche alternativa?)

Non sono realmente necessarie velocità elevate (accessi simultanei: massimo 2 o 3 file di grandi dimensioni, diciamo video), anche se si tratta di "solo" 200 MB / s di letture da un 10 HDD Raid6 con cui posso convivere.

In sintesi, cerco un filesystem affidabile, scalabile (cioè facilmente espandibile) che supporti più di 20 TB / partizione. Più sicuro e affidabile è il FS, meglio è. L'hardware impiegato sarà almeno un quad core (amd x4 630 o Intel i5-2500k) e molta RAM (> 8 GB, forse> 16 GB), quindi i requisiti hardware devono essere soddisfatti.

I miei PC / Server saranno collegati a un UPS (Uninterrupted Power Supply) in caso di interruzione dell'alimentazione Potrebbe fare anche supporti e backup su macchine separate (cioè due server).

Molte persone stanno suggerendo ZFS. Ma ZFS non è disponibile in modo nativo sotto Linux se non tramite fusibile. Non lo consiglierei per la tua situazione in cui è probabile che le prestazioni siano importanti.

Sfortunatamente, ZFS non sarà mai disponibile come modulo kernel nativo a meno che i problemi di licenza non vengano risolti in qualche modo.

XFS è buono, ma alcune persone hanno segnalato problemi di corruzione e non posso davvero commentarlo. Ho giocato con piccole partizioni XFS e non ho avuto questi problemi ma non in produzione.

ZFS ha troppi vantaggi e funzioni utili che non possono essere ignorate. In sintesi sono (vedi Wiki ZFS per una descrizione completa di cosa significano):

• Integrità dei dati
• Pool di archiviazione
• L2ARC
• Alta capacità
• Copia su scrittura
• Istantanee e cloni
• Striping dinamico
• Dimensioni dei blocchi variabili
• Creazione leggera di filesystem
• Gestione della cache
• Endianità adattiva
• deduplicazione
• Encrypion

Quindi, come possiamo aggirarlo? La mia alternativa suggerita che può soddisfare la tua situazione è quella di considerare Nexenta . Questo è un kernel Open Solaris con strumenti GNU userland in esecuzione in cima. Avere un kernel Open Solaris significa avere ZFS disponibile in modo nativo.

Dovresti provare XFS, adattarsi bene alle tue esigenze:

XFS è un file system a 64 bit. Supporta una dimensione massima del file system di 8 exbibyte meno un byte, sebbene ciò sia soggetto ai limiti di blocco imposti dal sistema operativo host. Sui sistemi Linux a 32 bit, ciò limita le dimensioni di file e file system a 16 tebibyte.

L'opzione più semplice è utilizzare XFS. Molte delle brutte esperienze relative a XFS si basano su vecchie versioni e problemi hardware desktop che non credo siano rilevanti per le nuove distribuzioni su hardware server di qualità standard. Ho scritto un post sul blog su questo argomento che potrebbe aiutarti a risolvere la situazione attuale. Esistono più installazioni di database XFS occupate con centinaia di utenti e terabyte di dati che aiuto a gestire. Sono tutti sul kernel Debian Lenny (2.6.26) o versioni successive e non ho sentito un indizio di problemi con loro da anni. Non userei XFS con nessun kernel precedente a quello. Ho sentito alcuni resoconti diretti di persone che vedono strani comportamenti XFS quando il sistema esaurisce la memoria o lo spazio su disco; Ma non l'ho ancora visto.

L'unica altra opzione ragionevole è usare ext4 con qualche hacking per supportare filesystem più grandi. Non mi aspetto che abbia un livello di affidabilità molto diverso. Ho dovuto recuperare i dati da più sistemi ext4 rotti che si sono imbattuti in bug del kernel, finora fino a quel momento tutti risolti a monte ma non nel kernel del distributore. ext4 ha una propria serie di problemi relativi ai metadati come la perdita ritardata dei dati di allocazione , cose che avevano meno probabilità di accadere su ext3. Stimerei che le probabilità che tu colpisca un bug ext4 sarebbero persino più alte del normale se lo stai forzando oltre il limite di dimensioni normali, semplicemente perché sembra più probabile che tu stia colpendo un nuovo percorso del codice meno ben testato ad un certo punto .

Un'idea alternativa è usare ext3 più sicuro e noioso, accettare il limite di 16 TB e partizionare le cose meglio, quindi nessun singolo filesystem deve essere così grande.

Un'estremità libera legata alle edizioni del diario. Non hai parlato di come saranno collegate tutte queste unità. Assicurati di comprendere le implicazioni di qualsiasi cache di scrittura presente nella catena di archiviazione qui. Disabilitalo o assicurati che il filesystem stia svuotando la cache. Ho raccolto alcune risorse al riguardo su Reliable Writes se non è ancora qualcosa che stai verificando.

Le unità fanno schifo. Gli array RAID fanno schifo. I filesystem fanno schifo. Si verificano più guasti. Sono contento di vedere che stai già pensando ai backup; passare da una buona a una grande affidabilità nello storage richiede molto più del solo RAID e alcune unità di riserva. La ridondanza costa qualcosa a tutti i livelli e il denaro per la complessità hardware vs software è difficile da navigare. E osserva le tue aspettative di prestazione. Mentre un array RAID come stai prendendo in considerazione farà facilmente centinaia di MB / s, tutto ciò che serve sono due lettori simultanei che cercano costantemente il disco per farlo cadere a pochi MB / s. Posso facilmente schiacciare un array RAID10 a 24 dischi in modo tale da fornire solo <5 MB / s rispetto a un carico di lavoro di riferimento . Una cosa che ci aiuta è assicurarti di modificare la lettura verso l'alto se sono possibili più lettori di streaming.

La distribuzione su ZFS usando FreeBSD potrebbe avvenire qui usando gbde per la crittografia. ZFS stesso sarebbe il fornitore del software RAID, tramite RAIDZ . La complessità della gestione dell'archiviazione nella creazione di zpools non è significativamente diversa da quella che Linux ti fornirà con mdadm, e in alcuni casi sarà effettivamente più semplice. La mia prima installazione di ZFS (su Solaris 10 circa 3 anni fa) aveva un filesystem da 17 TB su 48 unità. Sono sopravvissuto a più guasti lì senza problemi, imparando la gestione ZFS mentre procedevo.

Il vantaggio principale è che il checksum di ZFS fornisce un migliore rilevamento degli errori rispetto a quello di Linux, il che è una difesa contro l'hardware difettoso che vale la pena considerare. Gli svantaggi principali sono che FreeBSD è meno popolare. Non sai ancora come amministrarlo, il supporto hardware è un po 'più debole di Linux, e poiché è una piattaforma meno popolare non ci sono così tante persone a cui chiedere aiuto se riscontri problemi.

Un array di archiviazione di molti terabyte evidenzia davvero ciò che ZFS è bravo a fare. Vale la pena considerare seriamente se sei disposto a immergerti in qualcosa di nuovo. Se vuoi esplorare la vera paranoia del backup, costruisci server di backup Linux e FreeBSD, per ridurre le probabilità di errori del sistema operativo come una singola causa di errore.

Secondo la pagina di confronto del file system di Wikipedia , ci sono molti file system notevoli che soddisfano le tue esigenze come JFS, XFS, UDF, ZFS, GPFS e Btrfs. Basta fare clic sulla dimensione massima del file per ordinare e selezionare quella più appropriata