SOLVED Riconfigurazione NAS, dischi e plugin

[ThEnGI]

I dischi meccanici non subiscono comunque usura riscrivendoci varie volte?

NO, Gli SSD si hanno un limite di scritture ma gli HDD tradizionali no. Il limite è la meccanica.
Ma immagina in un datacenter quanti dati scrivono su un HDD.
Non ho fatto caso quanti dati avevano scritto i vecchi HDD con 70.000 h di funzionamento

Cosi a vederlo è un HDD da PC (tanti avviamenti), proprio lo "start&stop" è il momento più critico per un HDD. Se cerchi sul forum tanti consigliano di lasciarli girare che è meno pericoloso per un eventuale malfunzionamento

NDR 200GB penso li scirvo in 4/5 d'ore XD

ThEnGI

 

[Davvo]

si blocca con errore read failure​

Dischi usati
​

su questo io non noto niente di strano​

Apparentemente sembra a posto.
​

penso sia troppo (Ram vs CPU)​

Non esiste il troppo, solo il troppo poco.
​

(e non so se sia una regola "empirica" o meno, ma ho letto sempre che per scegliere il quantitativo di ram, vada messo "almeno 1gb di ram ogni tb di archiviazione").​

E' una regola per avere le migliori performance, appositamente larga, ma si applica dopo gli 8GB minimi richiesti da TN. Andare sotto la RAM minima può causare instabilità... personalmente quando avevo 16GB di RAM ne allocavo 4 ad una VM senza problemi.
​

EDIT: dimenticavo una cosa importante, mi spiegheresti nel dettaglio come metterlo sotto bench? così quando ho finito di "riassestare" la macchina la accendo e non la spengo più​

solnet-array-test

Back in the late '90's, I was managing a bunch of large whitebox storage servers. For the largest of these, I had the pleasure of building and deploying a massive storage server, 8 shelves of 9 drives each, Seagate ST173404LW 73GB drives, a...

www.truenas.com

Solitamente si usa per dischi con 0 ore... io ti direi tranquillamente di saltare questo passaggio se il long test non ti da nulla. Se il disco aveva problemi, nelle 3700 ore della sua vita sarebbero emersi.
​

I dischi meccanici non subiscono comunque usura riscrivendoci varie volte?​

Solitamente i dischi per nas hanno tra i 140 ed i 180TBW/anno, ossia possono sopportare fino a XTB scritti all'anno... superare questo numero invalida la garanzia.
​

Cosi a vederlo è un HDD da PC (tanti avviamenti), proprio lo "start&stop" è il momento più critico per un HDD. Se cerchi sul forum tanti consigliano di lasciarli girare che è meno pericoloso per un eventuale malfunzionamento​

Gli HDD solitamente sono garantiti per 600.000 start&stop.​

 

[oxyde]

NO, Gli SSD si hanno un limite di scritture ma gli HDD tradizionali no. Il limite è la meccanica.
Ma immagina in un datacenter quanti dati scrivono su un HDD.
Non ho fatto caso quanti dati avevano scritto i vecchi HDD con 70.000 h di funzionamento

Cosi a vederlo è un HDD da PC (tanti avviamenti), proprio lo "start&stop" è il momento più critico per un HDD. Se cerchi sul forum tanti consigliano di lasciarli girare che è meno pericoloso per un eventuale malfunzionamento

NDR 200GB penso li scirvo in 4/5 d'ore XD

ThEnGI

Non so come fai!

Tempo fa macinavo anche io abbastanza giga di file, al tempo dei torrent delle iso di Linux e della musica NCS... Adesso dopo aver raccattato tutto quello che avevo disseminato nei vari dischi, creato i backup di tutte le macchine, ecc ecc sto a 600gb (di cui 200 li tengo giusto perché ho spazio).
Poi appunto per evitare accensioni/spegnimenti inutili finiti i test l'ho scollegato... Non in parità non voglio usarlo (l'esperienza recente insegna!). Ho valutato anche lo spin off e mi conviene: i file di cui potrei avere più bisogno li tengo nella pool degli SSD, che è anche più prestante, in questa nuova pool vado a mettere il resto dei file (e copie di backup di un paio di dataset importanti) quindi vi accederò più raramente, non rischio di avere continui on-off.

Onestamente ormai mi sono reso conto che tenere su una macchina così per conservare i file e accedervi ogni tanto è un overkill... Ma se provo a fare qualcosa in più mi scotto... Chissà se passare a scale mi permetterebbe qualcosa in più o faccio peggio?
Oltre a questo, non saprei nemmeno con precisione cosa possa essermi utile...

Apparentemente sembra a posto.

Ottimo!

Non esiste il troppo, solo il troppo poco.

E' una regola per avere le migliori performance, appositamente larga, ma si applica dopo gli 8GB minimi richiesti da TN. Andare sotto la RAM minima può causare instabilità... personalmente quando avevo 16GB di RAM ne allocavo 4 ad una VM senza problemi.

Grazie del chiarimento!

solnet-array-test

Back in the late '90's, I was managing a bunch of large whitebox storage servers. For the largest of these, I had the pleasure of building and deploying a massive storage server, 8 shelves of 9 drives each, Seagate ST173404LW 73GB drives, a...

www.truenas.com

Solitamente si usa per dischi con 0 ore... io ti direi tranquillamente di saltare questo passaggio se il long test non ti da nulla. Se il disco aveva problemi, nelle 3700 ore della sua vita sarebbero emersi.

Questo mi sarà utile!

Solitamente i dischi per nas hanno tra i 140 ed i 180TBW/anno, ossia possono sopportare fino a XTB scritti all'anno... superare questo numero invalida la garanzia.
Gli HDD solitamente sono garantiti per 600.000 start&stop.

Ok in ogni caso non era effettivamente così "usato" come pensavo, errori a parte

 

[ThEnGI]

Non esiste il troppo, solo il troppo poco.​

64GB mi sembrano un buon target, anche perchè poi non ho core per far girare le macchine virtuali alla fine cosa me ne faccio di tanta ram ? ARC a non finire ?

Scusate l'OT: @Davvo non è che per caso hai una guida su come dimensionare le Metadata Vdev/Log vdev ecc, non credo che su una pool di 12TB servano 12TB di metadata/log/ecc... e soprattutto cosa "fanno/cosa migliorarno" che ho le idee un pò confuse XD

Tempo fa macinavo anche io abbastanza giga di file, al tempo dei torrent delle iso di Linux e della musica NCS... Adesso dopo aver raccattato tutto quello che avevo disseminato nei vari dischi, creato i backup di tutte le macchine, ecc ecc sto a 600gb (di cui 200 li tengo giusto perché ho spazio).

Quando utilizzi ISO Linux di alta qualità è normale arrivare anche a 60GB per ISO, mediamente sono sui 10-15GB per ISO, se fai i conti fai in fretta a fare GB su GB.
Ho tante scritture sugli SSD perchè c'è un continuo riciclo dei file, il mio non è un "DEEP" storage più uno storage attivo. Ho tanto materiale che è fisso da anni ma tante cose "esistono" per massimo un mese, poi vengono cancellate. Spesso questi file non hanno neanche un backup, li perdo: Pazienza si passa a quello del giorno dopo !

Onestamente ormai mi sono reso conto che tenere su una macchina così per conservare i file e accedervi ogni tanto è un overkill... Ma se provo a fare qualcosa in più mi scotto... Chissà se passare a scale mi permetterebbe qualcosa in più o faccio peggio?
Oltre a questo, non saprei nemmeno con precisione cosa possa essermi utile...

Scale (IMHO) è anche più ostico di CORE, il vantaggio è che è meno improntato sullo storage (è più flessibile)
Devi definire bene i tuoi obbiettivi e di conseguenza che HW avere. Come dicevo TN è ostico ai cambiamenti devi partire subito in pompa magna e non aggiornare lungo in percorso (se non lo storage)

T

 

[Davvo]

Io uso il mio CORE per storage, qBittorrent, e hosting di un paio di server VTT per amici (pochissima roba).
​

64GB mi sembrano un buon target, anche perchè poi non ho core per far girare le macchine virtuali alla fine cosa me ne faccio di tanta ram ? ARC a non finire ?​

Yup, ARC a non finire. Con 64GB puoi considerare l'utilizzo di L2ARC in rapporto 1:4 o 1:6 (RAM:L2ARC).
​

Scusate l'OT: @Davvo non è che per caso hai una guida su come dimensionare le Metadata Vdev/Log vdev ecc, non credo che su una pool di 12TB servano 12TB di metadata/log/ecc... e soprattutto cosa "fanno/cosa migliorarno" che ho le idee un pò confuse XD​

Il VDEV metadata è diverso dallo SLOG. Lo SLOG serve solo se si hanno molte scritture sincrone (sync = always) e puoi trovare info qui.
Il VDEV metadata serve solo in rari casi in applicazioni speciali... come ad esempio migliorare le performance di una pool hdd, ma è l'ultima risorsa: prima si fa upgrade alla massima RAM supportata da MB/CPU, poi si aggiunge L2ARC, e se ancora non va bene si considera un metadata VDEV. Può essere grande quanto vuoi, ma necessita dello stesso livello di ridondanza della pool principale. Quando si aggiunge un metadata VDEV si crea una fusion pool (CORE | SCALE): attenzione, questo VDEV non è rimovibile una volta aggiunto, e la sua perdita comporta la perdita dell'intera POOL!

SCALE ha i suoi problemi, derivanti soprattutto dall'uso di Linux e Kubernets. Io rimango su CORE, tu puoi provare: fare il rollback dovrebbe essere una questione di click.​

 

[ThEnGI]

Scusa @oxyde se ti rubo il post, ma magari sono info che ti vengo buone anche a te

Yup, ARC a non finire. Con 64GB puoi considerare l'utilizzo di L2ARC in rapporto 1:4 o 1:6 (RAM:L2ARC).​

Sono convinto a prendere 2 banchi da 32GB, per una ram totale sul NAS di 80GB (64+16) da cui 40GB di ARC. (Scale)
Perciò niente L2ARC ? anche perchè vedo pareri discordanti sul forum... al punto che la sconsigliano negli Home lab

Il VDEV metadata è diverso dallo SLOG.​

Mi sono fatto un altra infarinatura, direi che è tutta roba che non mi interessa.

 

[Davvo]

Perciò niente L2ARC?

Monitora la % di hits dopo che espandi la RAM, se è inferiore a 90 puoi considerare l'utilizzo del Level 2 ARC.

 

[oxyde]

Scusa @oxyde se ti rubo il post, ma magari sono info che ti vengo buone anche a te

Ahahah ma figurati! Finché @Davvo non si fa pagare le consulenze approfittiamo!

Scale (IMHO) è anche più ostico di CORE, il vantaggio è che è meno improntato sullo storage (è più flessibile)
Devi definire bene i tuoi obbiettivi e di conseguenza che HW avere. Come dicevo TN è ostico ai cambiamenti devi partire subito in pompa magna e non aggiornare lungo in percorso (se non lo storage)

Io uso il mio CORE per storage, qBittorrent, e hosting di un paio di server VTT per amici (pochissima roba).
SCALE ha i suoi problemi, derivanti soprattutto dall'uso di Linux e Kubernets. Io rimango su CORE, tu puoi provare: fare il rollback dovrebbe essere una questione di click.

Per chiarirmi meglio le idee, ho voluto ridare una possibilità alla questione VM... E invece inaspettatamente ho trovato un uso più che comodo per un'applicazione in jail.
Mi sono ricordato dell'esistenza di una versione di Windows ( Tiny 10 - 11) che funziona discretamente con poca RAM, per cercare l'iso mi sono imbattuto in una vecchia conoscenza: Jdownloader -> leggo che è scaricabile per Nas -> in pochi minuti seguendo un post sul forum internazionale lo sto usando senza intoppi. E la cosa stupenda è che impatta in maniera marginale sulla macchina!

Gasato, mi butto a ricreare una VM con l'iso appena ottenuta, assegnando 2 modesti GB di RAM e tutta l'installazione procede velocissima e senza intoppi; configurato l os, purtroppo faccio in tempo a fare qualcosa che la VM si freeza e sono costretto a spegnerla... Stavolta però non penso sia un problema reale, penso sia vnc a impallarsi (TN non accusa niente, e la VM va in Power off senza rogne).
Suggerimenti? O mi butto sul forum internazionale?

 

[Davvo]

Prova a dare 4GB alla VM. VNC mi dava problemi anche a me, ma non ho idea di come funzioni... ho piantato la VM ubuntu e sono passato alle jail: mai avuto problemi da allora.

 

[oxyde]

Prova a dare 4GB alla VM. VNC mi dava problemi anche a me, ma non ho idea di come funzioni... ho piantato la VM ubuntu e sono passato alle jail: mai avuto problemi da allora.

Sicuramente approfondisco le possibilità che ho con le jail (anzi se avete idee o altri casi d'uso sono tutto orecchie).

Farò una prova sperando di non creare instabilità, proverò anche se fattibile usare la VM con rdp invece che vnc (perché ho avuto l'impressione che la macchina non fosse realmente piantata).
Se non dovesse comunque andare installo le VM sulla workstation, e continuo a gestirmi il tutto come adesso (attivo SQL e IIS al bisogno).

Show : Se vi chiedete perché insisto a voler virtualizzare Windows

è principalmente per una questione di isolamento: la VM posso agilmente scollegarla dalla rete internet, in modo che tirando su siti per test di aggiornamento o simili, non rischio che partano http request a sistemi esterni sincronizzati (Vi assicuro che colleghi hanno fatto frittate assurde), e perché ne tengo una predisposta e la clono al bisogno

 

[oxyde]

Fatto un test allocando 4gb di ram, ed il risultato è stato il medesimo (freeze dopo pochi secondi).
Ho cercato sul forum e ho trovato vari post a riguardo ma non ancora la soluzione, è un problema noto con l'adapter type del NIC (infatti sostituiendo Intel E82585 con VirtIO non ho collegamento a internet dalla VM ma non freeza).
Non ho provato con RDP ma non risolverei comunque niente, c hanno provato altri prima di me xD farò qualche altra ricerca e prova, poi proverò a scrivere nel forum internazionale

edit: forse ho risolto, ho caricato come CD rom la iso dei driver VirtIO e li ho installati, collegamento a internet funzionante (così posso installare le componenti che mi servono).
Con questa iso nonostante i 2gb di ram il sistema è reattivo e utilizzabile, da vedere se reggerà anche l'installazione SQL e IIS

 

[oxyde]

Stava procedendo tutto a gonfie vele... ma sono di nuovo con la pool degraded.
Vi riappioppo tutto solo perchè non penso più sia (o sia stata) la ram il problema, ma è proprio quel disco che ha qualcosa che non va e che causa instabilità... purtrppo non ho le competenze per andare più a fondo di così...
Stavo finendo di installare alcuni programmi nella VM, nel frattempo dopo essermi reso conto che quanto avevo scaricato con jdownloader non potevo spostarlo da quella cartella, mi documento e trovo la soluzione al volo -> mount point; avendo già dei file in quella cartella non potevo crearlo, così visto che c'erano giusto 3 file penso di spostarli uno alla volta da shell (1 6mb, 1 600mb, 1 3.5gb): i primi due andati lisci, al terzo mi sono accorto che nella VM l'uso del disco è salito improvvisamente al 100%, il file non veniva spostato e sono subito ricominciate le mail di alert

* Device /dev/gptid/9aa32a8a-9e9e-11ee-bacc-1cfd0879a7f9 is causing slow I/O on
pool SSDPool.

Chiudo tutto, ravvio la macchina, nessuna anomalia segnalata (ho il multireport che parte all'avvio).
Ci riprovo, stavolta soltanto a spostare il file e mi vado a fare una fumata... tempo che torno

* smartd is not running.

Pool SSDPool state is ONLINE: One or more devices has experienced an
unrecoverable error. An attempt was made to correct the error. Applications
are unaffected.

* Pool SSDPool state is DEGRADED: One or more devices has been removed by the
administrator. Sufficient replicas exist for the pool to continue functioning
in a degraded state.
The following devices are not healthy:

* Disk SSD 1TB 000360 is REMOVED

e quindi sono punto da capo.
Ho fatto il detach del disco, mi sono creato il mount point, ho spostato quel maledetto file (ndr andato come i primi 2 stavolta), e a questo punto mi sto anche finendo di installare i programmi nella VM per vedere se con solo questo disco succeda qualcosa.
Ho fatto intanto il wipe rapido di 000360, smart long (ci mette pochi minuti) e adesso vedo se far fare il resilvering stanotte o domani mentre lavoro che ho più "controllo".

Al di là di questo, avrei una domanda rigurado i mount point: ho visto che sostanzialmente se scarico un file me lo ritrovo sia nel path di jd, sia nel path del m.p.; posso cancellare da web gui tranquillamente il link di download col file, e nel m.p. rimane; dal m.p. posso spostare il file dove voglio senza problema anche tramite smb; così facendo però sono costretto a dover ogni volta cancellare tutti i file che scarico, e ad occupare effettivamente il doppio dello spazio? O sto sbagliando qualcosa?

 

[Davvo]

e ad occupare effettivamente il doppio dello spazio? O sto sbagliando qualcosa?

Non occupa doppio spazio! Il mount point fa credere alla jail di avere i dati nel suo percorso quando in realtà stanno da un'altra parte.

 

[oxyde]

Non occupa doppio spazio! Il mount point fa credere alla jail di avere i dati nel suo percorso quando in realtà stanno da un'altra parte.

Quindi è un semplice "puntatore", posso comunque spostarli dal mount point per organizzarli meglio (e li lascio ovviamente nella root principale della jail)?

 

[Davvo]

Quindi è un semplice "puntatore", posso comunque spostarli dal mount point per organizzarli meglio (e li lascio ovviamente nella root principale della jail)?

Tu hai la jail con un percorso /qBittorrent/scaricati con le tue Linux ISO.
E hai anche un'altra pool chiamata BONGO con un dataset chiamato ISO che condividi tramite SMB.
Monti /qBittorrent/scaricati su BONGO/ISO e la jail vedrà i file come suoi ma in realtà saranno in ISO: spostarli fuori ISO li farà scomparire da scaricati e (penso, dovrei controllare) vice versa.

 

[oxyde]

Tu hai la jail con un percorso /qBittorrent/scaricati con le tue Linux ISO.
E hai anche un'altra pool chiamata BONGO con un dataset chiamato ISO che condividi tramite SMB.
Monti /qBittorrent/scaricati su BONGO/ISO e la jail vedrà i file come suoi ma in realtà saranno in ISO: spostarli fuori ISO li farà scomparire da scaricati e (penso, dovrei controllare) vice versa.

giustamente... sorgente e destinazione... non ne ho acchiappata più una ieri.

 

[ThEnGI]

Volendo puoi avere anche più jail/docker puntati sulla stesso dataset, per esempio:
TN Dataset .../File_ISO.
Lo monti nella tua jail di qbittorent e lo monti anche nella tua jail di server web.
In questo modo quando scarichi la ISO diventa disponibile anche al tuo server WEB.

Sono proprio puntatori, attenzione a non modificare con due Jail contemporaneamente il FILE !

Io per comodità le ISO le scarico prima sugli SSD e poi le muovo (tutto tramite QBittorent) sugli HDD a quel punto vi accedo con un altro DOCKER per renderli disponibili ai dispositivi sulla rete. In pratica Qbittorent vede due cartelle in locale "../tmp" e "../ISO" ma effettivamente stanno su dischi diversi/Pool Diverse. Per assurdo potresti avere la pool che contiene i file temporanei anche senza ridondanza
Probabilmente più una mia patologia mentale ma così gli HDD sono occupati in scrittura solo durante la copia e in lettura tutto il resto del tempo.
Immagina scaricare una ISO da 100GB (io ho la connessione da 3° mondo) e sentire ticchettare tutto il tempo il disco (che quelli NAS/Enterprise sono rumorosi XD)

T

 

[oxyde]

Se vogliamo cominciare a parlare di connessioni da terzo mondo dovrei aprire un thread dedicato abito in una piccola frazione, in una zona che stanno praticamente cominciando a urbanizzare da pochissimi anni (la mia abitazione è stata la seconda ad essere costruita, ed era il 2017), tra continui disservizi - banda continuamente ridotta - centralina lontana tipo quasi 1 km... arrivo a stento a 35/40mbs di portante effettiva

Adesso ho comunque afferrato meglio la questione, ieri ho cercato di "acchiappare" un po' troppe cose e alla fine ho fatto la frittata.

In ogni caso stavolta non penso me la caverò facilmente a rimettere online la pool, tentando di riallacciare il disco alla pool adesso è l'altro a darmi problemi... una cosa è certa: lo storage non posso tenerlo nella stessa pool di jail e vm o rischio di dover sempre correre a fare backup ad ogni minimo problema... non so come faccia ancora a leggermi i file!!
Ho bisogno alla svelta di uno storage separato, maledetto quel disco pacco...

 

[Davvo]

Possibile che ci siano altri problemi vista l'età dell'hardware.

 

[oxyde]

Possibile che ci siano altri problemi vista l'età dell'hardware.

a rischio di lapidazione, stavolta non sono d'accordo però è un'impressione che, ho basata su un fattore che pensavo di aver riportato nel post ed invece ho involontariamente taciuto.
Secondo me ad innescare il problema è il surriscaldamento del disco/dischi: dai dati smart, entrambi i dischi non hanno MAI, e sottolineo MAI, evidenziato una temperatura diversa da 40°... nè appena accesi, nè dopo 10 ore, nè dopo intensa attività. MAI, sempre 40°... per dirvi, il grafico in dashboard è completamente piatto.
Sia chiaro, visto che con il disco di boot (stessa marca) avevo avuto problemi a posizionarlo negli slot appositi del case dato che raggiungeva velocemente i 50°, ho posizionato tutti e 3 i dischi in fondo al case proprio di fronte alla ventola (anzi, le 2 ventole) in immissione, con una staffa homemade... hanno praticamente un flusso d'aria costante e diretto, ma nonostante ciò il disco di boot ieri (prima del disastro) ha cominciato a salire di nuovo di temperatura. E questo non me lo posso spiegare se non che il loro "astuccio" non sia adeguato e non riesca a dissipare il calore che sviluppano i chip.
Il ricambio d'aria è abbondante e secondo me non ho commesso errori, piccolo art attack per farvi capire come ho modificato il tutto:

l'aria in entrata è sicuramente leggermente maggiore di quella in uscita (le 2 ventole frontali girano collegate alla CPU, quindi girano quasi sempre a 800rpm massimo 1300) ma la ventola in espulsione, anche se più piccola, gira più velocemente (1500rpm) e smuove abbastanza aria da creare comunque flusso per la parte superiore (dove avevo spostato i dischi, e dove monterò gli altri); inoltre il case è anche forato lateralmente.
Quei due SSD costavano poco perchè valgono meno, me ne disfo asap e capitolo chiuso.
In ogni caso, per essere sicuro al 100%, visto che ho un WD Blue montato nella workstation (che praticamente non uso), prima di darli via lo userò per un po' al posto di quei due dischi (ameno la parità, per ora) per farci le stesse operazioni, e se tutto fila liscio saprò come muovermi...
Se anche così avrò gli stessi problemi, questo pc diventerà il nuovo pc per mia madre xD e metto mano al portafoglio per un sistema meno datato