ZFS ottimizzato nella fattibilità di un ambiente a bassa RAM?

Attualmente sto configurando un file server e sono arrivato al punto di configurare effettivamente le unità dati. Il sistema dispone di 4 unità (un disco del sistema operativo, 3 dischi di dati). Il disco del sistema operativo è formattato come ext4 e non verrà aggiunto al pool ZFS (se scelgo di eseguire ZFS). La mia preoccupazione principale è l'integrità dei dati e il rischio minimo di perdita dei dati (la cache dell'unità è disabilitata nel BIOS). Per questo ZFS sembra essere il candidato perfetto, poiché ha una versione stabile per Linux (corretta?) E supporta la duplicazione dei dati, il pooling e il raidz, dove i dischi rigidi non devono avere le stesse dimensioni.

Ma ecco il mio problema. Il server ha solo 2 GB di RAM e questo non può essere aggiornato nel prossimo futuro, e realisticamente solo 1,5 sarà effettivamente accessibile a ZFS dopo aver installato tutti gli altri servizi. Un massimo di circa 10 client lo useranno contemporaneamente (più come 4 in media). È troppo basso per essere considerato sicuro?

Da quanto ho capito, ZFS può bloccarsi in situazioni di scarsa RAM e portare con sé il pool. Ho sentito opinioni contrastanti sul fatto che lo swap possa aiutare ad alleviare questo problema (ho un'unità dedicata allo scambio da 20 GB). Qualcuno ha sperimentato la perdita di dati con ZFS con poca RAM e quali ottimizzazioni hai incluso per impedirlo?

Tenendo presente quanto sopra, sarebbe comunque possibile eseguire ZFS, sebbene ridurrebbe le dimensioni di ack e lo taglierà un po 'o sarà troppo rischioso?

Specifiche di sistema: 2 GB di RAM 20 GB di unità di swap OS, Debian 7, installazione minima, con FTP e XBMC, DNLA, (per dare un'idea dei requisiti di RAM). Utilizzato per server di archiviazione e streaming di file musicali su altri dispositivi.

linux memory zfs

— Thomas E
fonte

Sono non un guru ZFS, ma conosco un bel po 'sui file system in generale, e so che un unico luogo si dovrà guardare fuori - grande tempo - per il consumo di memoria è la deduplicazione dei dati. Non specifichi quanto siano grandi i tuoi dischi, né quanti dati risiederanno su di essi; questo è enorme, poiché ZFS deve mantenere una tabella di ricerca in memoria. Non posso parlare con altre preoccupazioni, ma sicuramente ucciderei la deduplicazione. Inoltre, btrfs è abbastanza maturo per i dati di backup, ora; l'hai considerato? Controlla arstechnica.com/civis/viewtopic.php?f=16&t=1226135 per alcuni approfondimenti (che alcuni sicuramente non saranno d'accordo).

— Ravenpi,

Oh sì, mi sono perso. Il pool sarà di 3,35 TB (sia dischi che dati, in quanto eseguirà il backup di 9 client al giorno, quindi immagino che si riempirà rapidamente, suppongo che ciò significhi almeno una duplicazione, dal momento che freebsd suggerisce 5 GB di RAM per ogni spazio di archiviazione TB Grazie per aver sottolineato btrfs, non ero consapevole che ora fosse stabile, credo che avrò una buona occhiata in esso.

— Thomas E

"Stabile" è qualcosa che potrei non avere fretta di chiamarlo; si è titubanti nel chiamare QUALSIASI tipo di file system newish "stabile". Ma ci sta arrivando. LWN (Linux Weekly News) ha appena fatto una serie su di esso; è buono - dai un'occhiata qui: lwn.net/Articles/576276

— ravenpi,

Risposte:

Dichiarate l'integrità dei dati e il rischio minimo di perdita dei dati come preoccupazioni principali. L'esecuzione di ZFS con solo 2GiB di memoria è rischiosa e sconsigliata. Troppa poca RAM uccide le prestazioni ed è stata la causa di numerosi pool non montabili in passato. Il progetto FreeNAS indica almeno 8GiB di RAM.

Inoltre, poiché la tua preoccupazione è la perdita di dati, ti consigliamo di utilizzare la RAM ECC. Dal momento che la tua scatola può supportare solo 2GiB di RAM, suppongo sia una scatola davvero vecchia che non sarebbe una buona scelta per ZFS.

Per rispondere alle tue domande:

[…] E supporta la duplicazione dei dati

In pratica, dimentica la deduplicazione quando non hai almeno 32GiB, proprio come una regola empirica. Potrebbe essere necessaria molta più RAM, a seconda delle dimensioni del pool. In secondo luogo, fai i calcoli se i costi di deduplicazione + RAM sono più economici di una manciata di dischi aggiuntivi. Più spesso, più dischi sono l'alternativa più economica.

È troppo basso per essere considerato sicuro?

Sì, è troppo basso.

Da quanto ho capito, ZFS può bloccarsi in situazioni di scarsa RAM e portare con sé il pool.

Questo è vero e molte persone hanno perso i loro pool a causa della scarsa RAM.

Ho sentito opinioni contrastanti se lo swap aiuterà ad alleviare questo problema

Dimentica lo scambio, la tua scatola ZFS non dovrebbe mai usare lo scambio.

EDIT: se ti senti avventuroso e non ti preoccupi del rischio di panici occasionali o perdita di dati, leggi la guida alla messa a punto ZFS e adatta le impostazioni menzionate. Ecco le impostazioni di esempio per un sistema di 768 MiB di memoria.

vm.kmem_size="330M"
vm.kmem_size_max="330M"
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="5M"

Altrimenti investi cento dollari in una striscia di memoria e goditi un sistema stabile e performante.

— Marco
fonte

Vedo. Solo per elaborare sì, ho ecc ram e la macchina è il proliant microserver gen7 hp, che supporta ram fino a 8 / 16gb, al momento non è attualmente economicamente redditizio per acquistare più ram. Ero consapevole che Freenas raccomandava 8 GB, tuttavia la documentazione di Freebsd e Solaris suggerisce almeno 1 GB, che è la ragione della domanda. Immagino che alla luce di ciò dovrei attenermi a ext4 e rispecchiare manualmente con rsync e dd su dischi offline, probabilmente la soluzione più sicura.

— Thomas E,

Puoi spiegare perché ZFS non dovrebbe usare SWAP?

— CMCDragonkai,

Non vi è alcun motivo per cui utilizzare ZFS senza ECC sia più pericoloso che eseguire lo stesso hardware con un altro filesystem.

— Alicia,

Perché la comunità ZFS commenta sempre con tale snobismo arrogante? Non tutti quelli che vogliono avere dati affidabili $ 100 restano in giro per soddisfare alcuni requisiti di design assolutamente ridicoli ! Ad esempio, ho un piccolo server di casa ARM con 1 GB di RAM cablata e dischi rigidi USB. Voglio che i dati su di esso siano al sicuro da marcescenza bit, essendo sia rilevato e corretto, e avere istantanee per scopi di backup. Non c'è bisogno di velocità. E btrfs è chiaramente rotto dal design. Quindi ZFS sarebbe sensato, se qualche idiota non lo avesse progettato per implodere dalla depressione ogni volta che ha <128 exabyte di RAM.

— Evi1M4chine,

Sui sistemi ad alta pressione di memoria (linux) è davvero necessario aggiornare la memoria. C'è ancora bug ( collegamento ), dove le serrature scambiano su per la IO (kernel appese compito) rendendolo inutilizzabile a meno che non riavviato. Credo che vm.swappiness = X non abbia alcun effetto su zfs, quindi limitare l'arco a un certo numero potrebbe aiutare un po '.

— satch_boogie
fonte