ZFS usa la RAM del sistema come cache ARC principale; l'utilizzo di L2ARC (ARC di secondo livello) consente di aggiungere cache (più lenta della normale RAM) aggiuntiva, ma occupa una certa quantità di ARC proporzionale alla grandezza della L2ARC (sostanzialmente in ARC sta una tabella che elenca tutto ciò che sta dentro la L2ARC): il valore
minimo della RAM per
prendere in considerazione l'utilizzo di un SSD (meglio se NVMe M.2 in quanto possiede latenza minore di un SSD SATA) è di
64 GB per un SSD da
250 GB (il valore consigliato RAM:L2ARC corrisponde tra 1:4 a 1:6); in linea di massima conviene sempre maxare la quantità di RAM installabile sulla scheda madre prima di inserire L2ARC.
Tuttavia, in certi casi l'utilizzo della cache di secondo livello può essere conveniente anche senza aver maxato la RAM ma si parla di applicativi particolari... come per esempio permettere l'entrata nella L2ARC solamente ai metadati (utile in caso di pool composta da HDD ed utilizzata per lo storage di tante foto o file di piccole dimensioni). Sono pressochè certo che nel tuo caso non ti serva alcuna cache di lettura supplettiva (quindi no L2ARC).
Provides information on L2ARC, caches drives, and persistent L2ARC implementations in TrueNAS.
www.truenas.com
Per quanto riguarda l'impropriamente definita cache di scrittura (write cache in inglese), ossia lo SLOG, il discorso è completamente diverso e si usa solo quando l'impostazione del dataset riguardo alle scritture sincrone è sempre attiva (sync = always): ti serve solo in caso di virtualizzazione, block storage, e nelle situazioni nelle quali non è ammissibile perdere nemmeno pochi secondi di dati; un NVMe con caratteristiche speciali, estremamente specialistiche (tanta resistenza alla scrittura e capacità di eseguire tante operazioni di lettura e scrittura contemporaneamente, solitamente si consiglia la teoricamente defunta serie intel optane), è in grado di mitigare le grandi penalità di scrittura derivanti da questa impostazione. Non ti serve.
What is the ZIL? POSIX provides a facility for the system or an application to make sure that data requested to be written is actually committed to stable storage: a synchronous write request. Upon completion of a sync write request, the underlying filesystem is supposed to guarantee that a...
www.truenas.com
In entrambi i casi, usare HDD anzichè SSD è suicida. Soprattuto per il prezzo al quale si trova un SSD oggi.
Per quanto riguarda la configurazione iniziale del NAS ci sono tre parti da impostare: test SMART, scrub, e snapshot.
I
test SMART vengono effettuati sui dischi e, specialmente nel caso degli HDD, sono vitali per non incorrere nella perdita di dati; si distinguono in
short (solitamente è solo un'analisi delle componenti elettroniche),
long (solitamente vengono testate tutte le componenti, incluse le meccaniche e tutti i settori degli HDD), e un paio di altre opzioni a seconda del produttore (seagate per esempio ha i
conveyance, che servono ad evidenziare eventuali danni dovuti dal trasporto).
Nel momento in cui mi arriva un disco SEAGATE, eseguo innanzitutto un test
conveyance (che equivale ad uno short un po' più specifico) e se non ci sono errori un
long (che è l'unico vero test che vi deve dare sicurezza: uno short test può dirmi che tutto va bene quando in realtà il disco sta morendo); se saltano fuori errori si chiede la sostituzione.
La maggior parte degli utenti del forum pianifica uno short test
al giorno ed un long test
a settimana (quando fate il long non è necessario eseguire lo short, ma è indifferente e non consuma il disco avere entrambi... l'importante è che non si sovrappongano). Da tenere a mente che il tempo del long test aumenta di pari passo al tagio del disco e può tranquillamente superare le 10 ore di test.
Lo
scrub invece è un'operazione che mette sotto stress tutti i dischi, quindi potenzialmente pericolosa, e consiste in una lettura e controllo dei checksum di ogni singolo file di una pool (se non corrisponde, corregge e ripristina il file): è un'operazione che mette sotto stress l'intero sistema e sostanzialmente garantisce l'integrità dei dati. Non è necessario eseguirla abbastanza spesso, personalmente ho impostato un task giornaliero con thresold di 28 giorni: TN controlla ogni giorno quanto è passato dall'ultimo scrub riuscito, e se il valore è superiore a 28 giorni lo esegue effettivamente; certi utenti preferiscono valori più frequenti, altri meno frequenti... non suggerisco una sequenza inferiore ai 14 giorni.
ZFS esegue automaticamente un controllo dei checksum ogni volta che un file viene letto, quindi lo scrub è un'operazione da intendersi "di routine" che può segnalare importanti problemi nel nostro sistema.
Infine gli
snapshot sono un sistema di difesa contro ransomware ed errori umani, oltre a essere utilizzati per la creazione ed il mantenimento di backup (con esempio la zfs replication). Vedeteli come foto di metadati che indicano la posizione dei vari file sul disco che funzionano grazie al sistema COW di ZFS: ci permettono di ripristinare lo stato di un dataset ad un determinato periodo (quando è stato scattato lo snapshot), "annullando" le modifiche effettuate (come avere eliminato un file per errore). Specialmente con il protocollo SMB (e le shadowcopies) sono molto utili. L'impostazione dipende dalla situazione e dalla quantità di dati (gli snaphot occupano un po' di spazio)... personalmente nel mio dataset di archivio uso due tipi principali di programma: una run mensile che fa lo snapshot a prescindere dalla presenza di modifiche della durata di tre mesi, ed una run oraria che ha vita settimanale ma avviene solamente in caso di modifiche (quindi se un giorno non tocco i file non mi prende snapshot).
Una volta impostate queste tre cose è imperativo inserire una mail nelle impostazioni (alla quale TN manda gli avvisi, personalmente uso GMAIL e mai avuto un problema), e installare lo script
multi_report configurandolo secondo le nostre necessità.
Il mio parte ogni mercoledì alle 15:30, facendomi avere una immagine settimanale dello stato dei miei dischi assieme ad un backup della configurazione di sistema sempre accessibile (è un'allegato gmail!), ben oltre la fine del long test settimanale che parte lo stesso giorno verso l'una di notte.
This resource was originally created by user: @joeschmuck on the TrueNAS Community Forums Archive. https://www.truenas.com/community/resources/multi_report-sh-version-for-core-and-scale.179/download Multi-Report Tool to chart and record statistical data on your drives. This will email the...
www.truenas.com
Su CORE è comodo ma non strettamente necessario (se non siete masochisti dovete farlo) impostare il servizio SSH per assicurarsi l'accesso ad un terminale funzionante (la SHELL della WebUI è molto... limitata, per non dire rotta), personalmente utilizzo PuTTY (si può tranquillamente utilizzare anche solo un terminale come il cmd o la powershell di windows).
Infine, colgo l'occasione per sottolineare come il NAS non dovrebbe mai essere esposto direttamente all'internet esterno (non deve essere raggiungibile da oltre il firewall per apertura porte o altro): se avete tale necessità ci sono procedure da seguire, la più comune corrispondente al VPN tunnelling (che però solitamente qui da noi in italia necessita di un modem diverso da quello fornito dagli ISP).
Spero di essere stato esaustivo, nella sezione inglese ci sono tonnellate di risorse in merito (alcune delle quali le potete trovare nella mia firma); se avete domande su un argomento in particolare chiedete pure e vi sarà linkato.
