Ssd raid1

[gandalf.co...@gmail.com]

Ciao
Qualcuno usa degli ssd in raid 1?
Da quel che so, tutte le memorie flash hanno un numero limitato di scritture, metterne due in raid significherebbe avere lo stesso numero di scritture su ambo i dischi e quindi potenzialmente la stessa probabilità di rottura nello stesso momento

Come vi tutelate da ciò?

[Piergiorgio Sartor]

Hai le seguenti possibilita`:

1) Usi 2 SSD di due marche diverse. Completamente
diverse, cioe` non uno che sia la sottomarca del
altro o che usi gli stessi componenti. Di solito
hanno durate differenti.

2) Prendi 3 SSD, due li usi in RAID-1 subito.
Dopo un po' di tempo rimpiazzi uno dei due
con il terzo. Dopo un altro po' di tempo,
rimpiazzi il piu` vecchio con quello rimosso.
E cosi` via.

Prima o poi uno si rompe, ma difficilmente due
in contemporanea.
Quando si rompe uno, compri uno nuovo e continui
il giochetto.

Il tutto puo` anche essere automatizzato e se
usi "--replace" (con "mdadm") non devi neanche
fare l'upgrade / downgrade dell'array.

Ovviamente, la SSD rimossa deve passare per un
ATA secure erase, che azzera tutto, incluso lo
stato trim.

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-14 18:35, Piergiorgio Sartor wrote:
[...]
Ovviamente, si puo` usare anche una combinazione di
1) e 2), cioe` 3 SSD di marche diverse a rotazione.

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno giovedì 14 aprile 2016 18:40:31 UTC+2, Piergiorgio Sartor ha scritto:
> 1) Usi 2 SSD di due marche diverse. Completamente
> diverse, cioe` non uno che sia la sottomarca del
> altro o che usi gli stessi componenti. Di solito
> hanno durate differenti.

Questo quindi conferma la mia tesi che usare due SSD identici
in RAID-1 non è proprio il massimo in termini di sicurezza.

ma la durata di un SSD, salvo ovviamente guasti imprevedibili,
è certa ? Nel senso, se scrivono 1000 scritture, significa che
fino a 999 posso stare tranquillo ?

> 2) Prendi 3 SSD, due li usi in RAID-1 subito.
> Dopo un po' di tempo rimpiazzi uno dei due
> con il terzo. Dopo un altro po' di tempo,
> rimpiazzi il piu` vecchio con quello rimosso.
> E cosi` via.

Non mi piace questa cosa.
Togliere un disco sano per sostituirlo preventivamente,
sapendo che anche l'altro disco, essendo dello stesso tipo
(ssd) potrebbe rompersi in qualsiasi momento non mi fa stare
tranquillo. Chi mi dice che durante il rebuild di un disco
precedentemente sano ma sostituito, non si spacchi in realtà l'altro?

> Il tutto puo` anche essere automatizzato e se
> usi "--replace" (con "mdadm") non devi neanche
> fare l'upgrade / downgrade dell'array.

Suggerisci raid software con gli SSD ? Online ho letto
di molti preferirlo anche a controller di qualità.
Forse perchè la velocità degli SSD rende vana (o meno utile)
le nvcache dei controller RAID ? (sempre che la cache del
controller sia più veloce dell'ssd.....)

> Ovviamente, la SSD rimossa deve passare per un
> ATA secure erase, che azzera tutto, incluso lo
> stato trim.

Perchè? Tanto se è rotta la butto via.

[Alessandro Pellizzari]

On 15/04/2016 08:39, gandalf.co...@gmail.com wrote:

> Questo quindi conferma la mia tesi che usare due SSD identici
> in RAID-1 non è proprio il massimo in termini di sicurezza.

È lo stesso problema che hai coi dischi fisici. Se compri due dischi
identici nello stesso momento dallo stesso batch di produzione, la
probabilità che saltino a pochissimo tempo di distanza è molto alta.

> ma la durata di un SSD, salvo ovviamente guasti imprevedibili,
> è certa ? Nel senso, se scrivono 1000 scritture, significa che
> fino a 999 posso stare tranquillo ?

Naturalmente no. Sono tutte durate stimate, anche perchè per fare un
test approfondito ci vogliono anni di letture e scritture continue, e
naturalmente su un S.O. in uso hai troppe variabili da considerare per
determinare esattamente quante scritture sono avvenute.

Bye.

[Alessandro Selli]

Il 15/04/2016 09:39, gandalf.co...@gmail.com ha scritto:
> Il giorno giovedì 14 aprile 2016 18:40:31 UTC+2, Piergiorgio Sartor ha scritto:
>> 1) Usi 2 SSD di due marche diverse. Completamente
>> diverse, cioe` non uno che sia la sottomarca del
>> altro o che usi gli stessi componenti. Di solito
>> hanno durate differenti.
>
> Questo quindi conferma la mia tesi che usare due SSD identici
> in RAID-1 non è proprio il massimo in termini di sicurezza.
>
> ma la durata di un SSD, salvo ovviamente guasti imprevedibili,
> è certa ? Nel senso, se scrivono 1000 scritture, significa che
> fino a 999 posso stare tranquillo ?

No, sono sempre valutazioni stocastiche, non v'è certezza alcuna.

>> 2) Prendi 3 SSD, due li usi in RAID-1 subito.
>> Dopo un po' di tempo rimpiazzi uno dei due
>> con il terzo. Dopo un altro po' di tempo,
>> rimpiazzi il piu` vecchio con quello rimosso.
>> E cosi` via.
>
> Non mi piace questa cosa.

Però funziona.

> Togliere un disco sano per sostituirlo preventivamente,
> sapendo che anche l'altro disco, essendo dello stesso tipo
> (ssd) potrebbe rompersi in qualsiasi momento

Qualunque disco potrebbe rompersi in qualunque momento. Quello che
cambia è la probabilità con cui un certo disco si romperà durante un
certo periodo d'uso. La strategia che ha consigliato Piergiorgio Sartor
è buona, perché si basa sull'uso contemporaneo di dischi con un diverso
tempo cumulativo d'uso, il che diminuisce la probabilità di un guasto
simultaneo dei due dischi in RAID1.

> non mi fa stare
> tranquillo. Chi mi dice che durante il rebuild di un disco
> precedentemente sano ma sostituito, non si spacchi in realtà l'altro?

Nessuno, ovviamente. Ma si guastasse l'altro, lo sostituiresti con il
terzo disco appena rimosso. Nessun RAID>0 in realtà ha molto senso se
non si ha almeno un disco "spare"; avere un terzo disco pronto a
sostituire uno dei due dischi in RAID1 dovrebbe essere una precauzione
scontata sin dall'inizio dell'esercizio del RAID.

[...]

>> Ovviamente, la SSD rimossa deve passare per un
>> ATA secure erase, che azzera tutto, incluso lo
>> stato trim.
>
> Perchè? Tanto se è rotta la butto via.

In linea di principio, se il guasto è riparabile (ad es., cambiando
l'elettronica di controllo proveniente da un disco uguale, oppure
spostando le celle NAND in un lettore da laboratorio), i dati sono
recuperabili. Se i dati salvati sono importanti e riservati, fare
quello che dice Piergiorgio Sartor è una buona misura da prendere per
cautelarsi dai casi più estremi. Un'altra strategia è di usare sempre
partizioni criptate sui dischi, così quelli rotti li puoi buttare via
senza darti pensiero di quello che c'era scritto sopra.


Ciao,


--
Alessandro Selli http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

[Ammammata]

Il giorno Fri 15 Apr 2016 09:39:21a, ** inviava su it.comp.os.linux.sys il
messaggio news:45a87f29-d2ed-4996...@googlegroups.com.
Vediamo cosa scrisse:

>
> Questo quindi conferma la mia tesi che usare due SSD identici
> in RAID-1 non è proprio il massimo in termini di sicurezza.
>
>

dovresti dirlo a quelli della fujitsu che nei server mi propongono dischi
ssd identici... a meno che il controller per il raid1 scriva sui dischi in
ordine inverso l'uno rispetto all'altro

--
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
>>>>> http://www.bb2002.it :) <<<<<
........... [ al lavoro ] ...........

[gandalf.co...@gmail.com]

Il giorno venerdì 15 aprile 2016 11:38:07 UTC+2, Alessandro Selli ha scritto:
> Nessuno, ovviamente. Ma si guastasse l'altro, lo sostituiresti con il
> terzo disco appena rimosso. Nessun RAID>0 in realtà ha molto senso se
> non si ha almeno un disco "spare"; avere un terzo disco pronto a
> sostituire uno dei due dischi in RAID1 dovrebbe essere una precauzione
> scontata sin dall'inizio dell'esercizio del RAID.

Se invece facessi RAID-6, che lo preferisco anni luce?
Mi costa esattamente il triplo, ma il problema persisterebbe ?
Anche in un RAID-6 le scritture avvengono in stessa quantità sullo stesso numero di dischi ?

Un RAID-6 a 3 o 4 dischi protegge di più (sempre parlando di SSD) rispetto un RAID-1 dove è quasi certa la rottura di due dischi in contemporanea (quasi certa o altamente probabile, proprio perchè si tratta di SSD)

[Roberto Tagliaferri]

gandalf.co...@gmail.com wrote:

> Se invece facessi RAID-6, che lo preferisco anni luce?
> Mi costa esattamente il triplo, ma il problema persisterebbe ?
> Anche in un RAID-6 le scritture avvengono in stessa quantità sullo stesso
> numero di dischi ?
>
> Un RAID-6 a 3 o 4 dischi protegge di più (sempre parlando di SSD) rispetto
> un RAID-1 dove è quasi certa la rottura di due dischi in contemporanea
> (quasi certa o altamente probabile, proprio perchè si tratta di SSD)

se prescindi dall'acquisto di ssd dello stessa marca/lotto/modello si, un R6
è più sicuro (sempre con spare :) )
A me ha salvato il posteriore (complice anche il buon funzionamento della
san) con una partita di hd difettosi gentilmente inseriti dalla fujitsu
nella san
Le prestazioni però son quelle che sono
--
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)tosnet.it
www.robyt.eu

[Piergiorgio Sartor]

On 2016-04-15 09:39, gandalf.co...@gmail.com wrote:
[...]

> Questo quindi conferma la mia tesi che usare due SSD identici
> in RAID-1 non è proprio il massimo in termini di sicurezza.

Neanche con normali HDD.
In ogni caso, la teoria e` che i guasti
siano "incorrelati".
Se prendi due HDD, stessa marca, stesso
modello, stesso batch di produzione,
molto probabilmente si romperanno nello
stesso momento.

Io ho RAID-5, con 4 dischi, e cerco sempre
marche diverse o dischi usati con durate
diverse. Mai dischi uguali (se possibile).

> ma la durata di un SSD, salvo ovviamente guasti imprevedibili,
> è certa ? Nel senso, se scrivono 1000 scritture, significa che
> fino a 999 posso stare tranquillo ?

Ovviamente no.
Una cella diciamo che puo` essere scritta 1000 volte.
Questo non vuol dire che alla 1001esima volta non
funziona piu`.
Semplicemente la probabilita` di rottura aumenta
(forse vertiginosamente) dopo 1000 volte.

[...]

> Non mi piace questa cosa.
> Togliere un disco sano per sostituirlo preventivamente,
> sapendo che anche l'altro disco, essendo dello stesso tipo
> (ssd) potrebbe rompersi in qualsiasi momento non mi fa stare
> tranquillo. Chi mi dice che durante il rebuild di un disco
> precedentemente sano ma sostituito, non si spacchi in realtà l'altro?

Gli SSD, a differenza degli HDD, di solito non
si rompono in lettura.
Quindi ricostruire un RAID e` uno stress solo
per il SSD aggiunto, non per gli altri.

Inoltre dipende da come e` fatta la cosa.
Per es., senza "replace", passi da 2xRAID-1
a 3xRAID-1 e poi a 2xRAID-1.
Hai sempre almeno due dischi ridondanti.

[...]

> Suggerisci raid software con gli SSD ? Online ho letto
> di molti preferirlo anche a controller di qualità.

Dipende da cosa ci devi fare, chiaramente.
A meno di non avere necessita` particolari,
non mi pare che il RAID software sia peggio
di uno HW.
Diversi test confermano addirittura il
contrario.
Per gli SSD in particolare potrebbe essere
diverso, ma prima di spendere soldi per un
controller costoso (altrimenti non vale la
pena) farei una prova in SW.

> Forse perchè la velocità degli SSD rende vana (o meno utile)
> le nvcache dei controller RAID ? (sempre che la cache del
> controller sia più veloce dell'ssd.....)

La nvcache serve (nv==non volatile, immagino)
in caso di power loss, ma qui magari si puo`
fare un un UPS. Dipende sempre da cosa serva.

>> Ovviamente, la SSD rimossa deve passare per un
>> ATA secure erase, che azzera tutto, incluso lo
>> stato trim.
>
> Perchè? Tanto se è rotta la butto via.

Nel caso della rotazione con 3.
Quella che rimpiazzi non e` rotta, e` in
parking ed e` meglio azzerarla.

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-15 14:30, gandalf.co...@gmail.com wrote:
[...]

> Se invece facessi RAID-6, che lo preferisco anni luce?

Attenzione, non tutte le SSD sono adatte
a RAID con parita` (forse neanche RAID-1).
Il problema e` che il trim di un blocco
potrebbe avere uno dei seguenti risultati:

1) blocco azzerato
2) blocco 1-azzerato :-)
3) blocco random

Il RAID-5/6 supporta, di solito, solo il primo caso.
Controlla: Deterministic read ZEROs after TRIM
Di solito "hdparm -I /dev/sdX" ti da questa informazione.

> Mi costa esattamente il triplo, ma il problema persisterebbe ?

Perche` il triplo?

> Anche in un RAID-6 le scritture avvengono in stessa quantità sullo stesso numero di dischi ?

Dipende. Sicuramente le due parita` devono
essere scritte, ma se il dato originale interessa
meno unita` (del numero totale) allora solo
queste sono coinvolte nella scrittura.
Se hai un RAID-6 con 8 dischi e scrivi un solo
blocco, allora solo 3 dischi sono coinvolti:
P,Q e quello dove c'e` il blocco modificato.
Le prestazioni si perdono perche` si devono leggere
5 dischi, calcolare i nuovi P,Q e scrivere P,Q ed
il nuovo dato.
Non conviene, se servono IOPS, e` un suicidio.

> Un RAID-6 a 3 o 4 dischi protegge di più (sempre parlando di SSD) rispetto un RAID-1 dove è quasi certa la rottura di due dischi in contemporanea (quasi certa o altamente probabile, proprio perchè si tratta di SSD)

Quello che i data center usano sono RAID-1
con 3 dischi. Proprio per gli IOPS.

Hai migliori prestazioni e la rottura di
due dischi non e` certa, se usi le giuste
precauzioni del caso.
Ovvero e` certa anche per HDD rust.

bye,

--

piergiorgio

[M_M]

ven, 15 apr 2016, 18:32:37, Piergiorgio Sartor ha scritto:

> Gli SSD, a differenza degli HDD, di solito non
> si rompono in lettura.

Leggendo il thread mi sono ricordato di avere nel segnalibri questo
articolo:
http://www.miamammausalinux.org/2016/03/google-e-laffidabilita-della-tecnologia-ssd/
che credo potrebbe interessarvi, se ovviamente non lo avete gia` letto.

[gandalf.co...@gmail.com]

Il giorno venerdì 15 aprile 2016 18:32:54 UTC+2, Piergiorgio Sartor ha scritto:
> Io ho RAID-5, con 4 dischi, e cerco sempre
> marche diverse o dischi usati con durate
> diverse. Mai dischi uguali (se possibile).

Questo quasi mai è possibile, sopratutto se usi materiale
certificato. Ad esempio in caso di DELL, i server supportano
solo *un* tipo di disco (a parità di interfaccia e dimensione)
e ti viene fornito direttamente da DELL. Non puoi usare
vendor differenti, altrimenti ti ritrovi un bel warning
nei log e su openmanage indicante un virtual volume degradato
e non è mai bello (anche se in realtà è solo una questione
estetica, il volume è perfettamente sincronizzato)

> Dipende da cosa ci devi fare, chiaramente.
> A meno di non avere necessita` particolari,
> non mi pare che il RAID software sia peggio
> di uno HW.

Solitamente i raid hw sono più performanti, grazie
alle cache. Leggevo online che sostanzialmente
la cache riesce a convertire scritture random in
sequenziali (scrivendo i dati tutti in una volta)
migliorando quindi le performance.

[gandalf.co...@gmail.com]

Il giorno venerdì 15 aprile 2016 18:42:56 UTC+2, Piergiorgio Sartor ha scritto:
> Perche` il triplo?

Il doppio. Butto via, per la parità, due dischi invece di 1.

> Le prestazioni si perdono perche` si devono leggere
> 5 dischi, calcolare i nuovi P,Q e scrivere P,Q ed
> il nuovo dato.
> Non conviene, se servono IOPS, e` un suicidio.

Nel caso specifico devo sostituire in server mysql (22GB l'intera base dati) e dischi SATA con un server a 64GB e, forse, SSD (ma credo di optare per il più classico SAS 15k). Potrei fare anche un RAID-1 a 35 dischi, avrei performance comunque superiori di qualche ordine di grandezza, volendo tutta la base di dati sta in RAM, oltre che su SSD.

[Piergiorgio Sartor]

On 2016-04-18 09:43, gandalf.co...@gmail.com wrote:
[...]

> Nel caso specifico devo sostituire in server mysql (22GB l'intera base dati) e dischi SATA con un server a 64GB e, forse, SSD (ma credo di optare per il più classico SAS 15k). Potrei fare anche un RAID-1 a 35 dischi, avrei performance comunque superiori di qualche ordine di grandezza, volendo tutta la base di dati sta in RAM, oltre che su SSD.
>

Da quello che leggo in giro (non posso, pero`
confermare di persona) per applicazioni DB,
con SSD, si usano 3 SSD in RAID-1 (3 per i
motivi precedentemente esposti).

Al massimo, usando "md", si puo` provare
un RAID-10 (non 1+0 o 0+1, ma 10 nativo).

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-18 09:41, gandalf.co...@gmail.com wrote:
[...]

> Questo quasi mai è possibile, sopratutto se usi materiale
> certificato. Ad esempio in caso di DELL, i server supportano
> solo *un* tipo di disco (a parità di interfaccia e dimensione)
> e ti viene fornito direttamente da DELL. Non puoi usare
> vendor differenti, altrimenti ti ritrovi un bel warning
> nei log e su openmanage indicante un virtual volume degradato
> e non è mai bello (anche se in realtà è solo una questione
> estetica, il volume è perfettamente sincronizzato)

Io gli avrei gia` piantato una grana... :-)

[...]

> Solitamente i raid hw sono più performanti, grazie
> alle cache. Leggevo online che sostanzialmente
> la cache riesce a convertire scritture random in
> sequenziali (scrivendo i dati tutti in una volta)
> migliorando quindi le performance.

La cache la hai anche nel RAID SW, solo che usa
la memoria del computer, invece di una separata.
E fa esattamente la stessa cosa, cioe` cerca di
convertire operazioni (scritture) random in
sequenziali.

Tempo fa vi erano vari test in giro.
Puo` essere che oggi le cose siano diverse, ma
all'epoco isultava che il RAID-5 SW e` piu veloce
di quello HW, ovviamente, dato che, di solito, si
ha una CPU di gran lunga piu` potente.
Il RAID-6 SW, che e` ottimizzato per il calcolo
di Q, ma niente piu`, era piu` o meno uguale a
quello HW.

Tanto per capirci, un controller SAS LSI2308 ha,
come CPU, un PPC a 800MHz.

bye,

--

piergiorgio

[Dottor Mistero]

On 18-Apr-16 19:09, Piergiorgio Sartor wrote:

> Puo` essere che oggi le cose siano diverse, ma
> all'epoco isultava che il RAID-5 SW e` piu veloce
> di quello HW, ovviamente, dato che, di solito, si
> ha una CPU di gran lunga piu` potente.

Mi ero fatto una NAS (debian, mdadm e sei dischi in raid 5).

Tutto bello, il t/r sequenziale superava i 500MB/s, ovviamente a dischi
vuoti, ma mdadm spremeva un core duo a 3.5GHz come un limone.

Adesso ho trovato un "controllerino" M5015 IBM (in pratica il 2960-8i,
che usato su ebay si trova a due soldi con tutta la batteria) ho messo
altri due dischi, il raid vola e la cpu è fresca come una rosa. E' vero
che la cpu principale è più potente, ma il controller è ottimizzato e fa
solo quello.

Di mdadm mi piaceva che decidevo tutto io, adesso lascio fare e vivo
sereno. :)

raid di saluti

[Piergiorgio Sartor]

On 2016-04-18 19:28, Dottor Mistero wrote:
[...]

> Adesso ho trovato un "controllerino" M5015 IBM (in pratica il 2960-8i,
> che usato su ebay si trova a due soldi con tutta la batteria) ho messo
> altri due dischi, il raid vola e la cpu è fresca come una rosa. E' vero
> che la cpu principale è più potente, ma il controller è ottimizzato e fa
> solo quello.

Dipende sempre da quanti core uno ha e come
vengano usati.

Io non trovo tutto questo uso di CPU, specie
con un RAID-5.
Per il RAID-6 forse, ma 1 core su 4+4 non mi
pare sia un grosso problema.

> Di mdadm mi piaceva che decidevo tutto io, adesso lascio fare e vivo
> sereno. :)

Vi e` anche un altro punto.

Con "mdadm" hai cose come bitmap, error log,
proactive replacement ed altro.

Solo controller very very very high end hanno
tutte quelle feature.

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-18 19:28, Dottor Mistero wrote:
[...]

> Di mdadm mi piaceva che decidevo tutto io, adesso lascio fare e vivo
> sereno. :)

Tra l'altro, dimenticavo, con il RAID SW
e` possibile fare anche... porcate... tipo
RAID tra dischi e RAM o tra SATA e USB o
tra SATA e iSCSI...

Per es., e` possibile fare un RAID-1 con un
disco "lento" ed uno "veloce" (anche RAM),
marcando il "lento" come write-mostly.

In questa situazione, le letture vengono
passate, per quanto possibile, prima al
disco "veloce".

In caso di poche scritture e molte letture
si ottiene un sistema affidabile e veloce.

bye,

--

piergiorgio

[Dottor Mistero]

On 18-Apr-16 19:36, Piergiorgio Sartor wrote:

> Io non trovo tutto questo uso di CPU, specie
> con un RAID-5.

Quando scriveva a 500MB/s, top mi indicava il 140% di cpu (due core al 70%).

uso di saluti

[Piergiorgio Sartor]

On 2016-04-18 19:52, Dottor Mistero wrote:
[...]

> Quando scriveva a 500MB/s, top mi indicava il 140% di cpu (due core al
> 70%).

Quanti secoli fa? :-)

Io, con 5 dischi, 400~500MB/s, vedo scarso
un 25% CPU, avendo il massimo possibile della
cache (quindi poca attesa I/O).

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno lunedì 18 aprile 2016 19:28:09 UTC+2, Dottor Mistero ha scritto:
> Di mdadm mi piaceva che decidevo tutto io, adesso lascio fare e vivo
> sereno. :)

Anche io vivevo sereno, prima di ritrovarmi una pertica sul per il cu.lo con due dischi a puttane senza che la controller si sia accorta di nulla e quasi 2TB di dati andati persi. (raid 10 con 6 dischi da 600GB)

No, non è causuale. Altro disco rotto su altro server, la controller dice "tutto ok" e termina anche il check consistency positivamente, ma il disco è rotto (errori i/o visibili direttamente da Debian). Stessa controller.

[gandalf.co...@gmail.com]

Il giorno lunedì 18 aprile 2016 19:10:26 UTC+2, Piergiorgio Sartor ha scritto:
> La cache la hai anche nel RAID SW, solo che usa
> la memoria del computer, invece di una separata.
> E fa esattamente la stessa cosa, cioe` cerca di
> convertire operazioni (scritture) random in
> sequenziali.

Lo fa di suo il kernel o va abilitato in qualche modo ?

[gandalf.co...@gmail.com]

Il giorno lunedì 18 aprile 2016 19:45:31 UTC+2, Piergiorgio Sartor ha scritto:
> Tra l'altro, dimenticavo, con il RAID SW
> e` possibile fare anche... porcate... tipo
> RAID tra dischi e RAM o tra SATA e USB o
> tra SATA e iSCSI...

Avete dimenticato *IL* vantaggio fondamentale:
spostare dischi da un server all'altro senza batter ciglio.

Nessun controller RAID è compatibile con altri, spesso (direi sempre) sono incompatibili anche all'interno dello stesso brand.

con raid sw puoi cambiare un intero server semplicemente spostando i dischi sul server nuovo. con il raid hw devi migrare tutti i dati con tutto ciò che ne consegue (down, disservizi, fermo macchine, ....)

[Piergiorgio Sartor]

On 2016-04-18 21:20, gandalf.co...@gmail.com wrote:
[...]

> Avete dimenticato *IL* vantaggio fondamentale:
> spostare dischi da un server all'altro senza batter ciglio.

Indubbiamente, era talmente scontato che non
mi era neanche venuto in mente...

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-18 21:18, gandalf.co...@gmail.com wrote:
[...]

> Lo fa di suo il kernel o va abilitato in qualche modo ?

Lo fa il driver "md".

Quello che puoi configurare e` quanta RAM.
Dovrebbe essere in:

/sys/class/block/mdX/md/stripe_cache_size

Dove la memoria usata e`: 4K*n_dischi*valore

"valore" e` il valore in sysfs, ovviamente.

Quindi, attenzione con RAID da 20 dischi...

C'e` anche da dire che Neil Brown (l'autore
di "md") non e` molto contento di come sia
l'algoritmo della cache.
Infatti, non e` detto che piu` cache si usi
piu` veloce vada il tutto.
Bisogna fare qualche test. Per es., io ho un
sistema dove 8192 da il massimo delle prestazioni.

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno lunedì 18 aprile 2016 21:45:48 UTC+2, Piergiorgio Sartor ha scritto:
> Indubbiamente, era talmente scontato che non
> mi era neanche venuto in mente...

io ad esempio devo migrare preventivamente alcuni server con PERC H200 a qualcosa di più recente e non so come fare.

La H200 non è supportata come partenza upgrade dalle recenti H730 e nemmeno da quelle subito prima come la H710. Devo, teoricamente, upgradare da H700, poi da H700 a H710 e poi H730

c'è da dire che la cosa mi puzza non poco, la H710 importa da H700, che è la stessa famiglia della H200, ma non importa (stando al manuale) da H200.

Mah. Resta comunque il fatto che non so come fare, se non facendo 3 importazioni (che mi fanno sempre tremare le gambe, il passo falso è facile da fare e si perde tutto)

[Dottor Mistero]

Il 18/04/16 20:09, Piergiorgio Sartor ha scritto:

> Quanti secoli fa? :-)

Mica tanto...

> Io, con 5 dischi, 400~500MB/s, vedo scarso
> un 25% CPU, avendo il massimo possibile della
> cache (quindi poca attesa I/O).

Intendi dire che, con top, vedi mdadm che ti impegna una sola cpu
(quindi 100%), e avendo quattro core correttamente scrivi di avere un
quarto della cpu impegnata?

La macchina su cui girava da me era un core duo e il raid 5 aveva un
disco in più. Se la tua cpu fosse un i5 con quattro core, quindi più
efficiente del core duo, i conti tornerebbero.

Ovviamente questo solo in fase di scrittura, quando viene calcolata la
parità. In lettura a parità di t/r l'impegno è assai minore.

saluti secolari

[Dottor Mistero]

Il 18/04/16 21:16, gandalf.co...@gmail.com ha scritto:

> No, non è causuale...

Controller di merda, che roba era?

saluti casuali

[gandalf.co...@gmail.com]

Il giorno martedì 19 aprile 2016 08:37:58 UTC+2, Dottor Mistero ha scritto:
> Controller di merda, che roba era?

PERC H200

[Dottor Mistero]

On 19-Apr-16 09:21, gandalf.co...@gmail.com wrote:

> PERC H200

So che non godono di gran reputazione. Io in ogni caso lo stato dei
dischi lo controllo *anche* con smartctl o simili. Mai fidarsi :)

saluti e controlli

[gandalf.co...@gmail.com]

5 dischi in raid6?
A quanti dischi vi siete spinti su un raid6 software?

Sono fortemente tentato di usarlo in tutti i sistemi che non richiedono baremetal (xenserver o proxmox ad esempio) ma da cui parlo da una Debian liscia (tipo tutti i miei database)

Visto che sono fuori dal giro da anni, volume raid singolo e lvm sopra, oppure volumi raid multipli? Preferisco la prima soluzione, molto più flessibile.
Non ho mai trovato vantaggi a fare volumi multipli per il raid, sono svantaggi nel caso dovessi estendere o cambiare dischi

[Piergiorgio Sartor]

On 2016-04-19 08:34, Dottor Mistero wrote:
[...]

> Intendi dire che, con top, vedi mdadm che ti impegna una sola cpu
> (quindi 100%), e avendo quattro core correttamente scrivi di avere un
> quarto della cpu impegnata?

25% di un core. Ed e` anche tanto.

Su di un Haswell non vedo neanche quello... :-)

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-19 17:02, gandalf.co...@gmail.com wrote:
> 5 dischi in raid6?
> A quanti dischi vi siete spinti su un raid6 software?

Ho un RAID-6 con 9 dischi.
Che e` quasi a limite, IMHO.
Non farei piu` di 10 max 12 dischi.

Se hai RAM (e CPU) da spendere, nessun problema
di prestazioni.
Il test RAID-6 AVX mi pare dia qualcosa come
11GB/sec su Haswell (per un core, dato che non
e` MT) a... boh..., 2.8GHz forse.

> Sono fortemente tentato di usarlo in tutti i sistemi che non richiedono baremetal (xenserver o proxmox ad esempio) ma da cui parlo da una Debian liscia (tipo tutti i miei database)

Il RAID-6 va bene per affidabilita` e per
flessibilita`. Si puo` sempre aggiungere
un HDD dopo e fare crescere il RAID.

Per le prestazioni, pero`, meglio un RAID-10,
sia nativo "md" che fatto separatamente.
Il nativo e` forse piu` interessante, dato che
consente di usare n/k dischi.
Non so se abbiano aggiunto, non credo, il grow.

Il RAID-6 va bene per NAS o storage, non per
uso del disco costante da parte di applicativi.

> Visto che sono fuori dal giro da anni, volume raid singolo e lvm sopra, oppure volumi raid multipli? Preferisco la prima soluzione, molto più flessibile.
> Non ho mai trovato vantaggi a fare volumi multipli per il raid, sono svantaggi nel caso dovessi estendere o cambiare dischi

Io avevo un problema simile. Mi serviva LVM,
RAID e LUKS.

Ho provato tutte le combinazioni, quella che
alla fine mi pare (per me medesimo) sia il
miglior compromesso e` RAID->LVM->LUKS.

Cioe` LUKS su LVM su RAID su HDD.

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-19 18:37, Piergiorgio Sartor wrote:
[...]

> Se hai RAM (e CPU) da spendere, nessun problema
> di prestazioni.
> Il test RAID-6 AVX mi pare dia qualcosa come
> 11GB/sec su Haswell (per un core, dato che non
> e` MT) a... boh..., 2.8GHz forse.

A questo proposito...

Con 10 dischi da 200MB/sec (non SSD) si
arriva a max 2GB/sec di transfer rate
possibile (per solo i dati 1.6GB/sec).
Di conseguenza, avendo una capacita` da
10GB/sec per il calcolo delle parita`,
significa che si usera` il 20% della CPU.

Il che mi torna con quello che vedo
con top.

Da notare, che la CPU usa AVX per il
calcolo delle parita`.
Con SSE solamente si va piu` lenti.

bye,

--

piergiorgio

[Dottor Mistero]

On 19-Apr-16 19:15, Piergiorgio Sartor wrote:

> Da notare, che la CPU usa AVX per il calcolo delle parita`.

Allora è questo il motivo della differenza di prestazioni riscontrata da me.

parità di saluti

[Piergiorgio Sartor]

Queste sono le prestazioni su AMD Opteron(tm)
Processor 3350 HE a 2.8GHz:

[ ...] raid6: sse2x1 gen() 5832 MB/s
[ ...] raid6: sse2x1 xor() 3925 MB/s
[ ...] raid6: sse2x2 gen() 9195 MB/s
[ ...] raid6: sse2x2 xor() 6400 MB/s
[ ...] raid6: sse2x4 gen() 11027 MB/s
[ ...] raid6: sse2x4 xor() 5822 MB/s
[ ...] raid6: using algorithm sse2x4 gen() 11027 MB/s
[ ...] raid6: .... xor() 5822 MB/s, rmw enabled
[ ...] raid6: using ssse3x2 recovery algorithm
[ ...] async_tx: api initialized (async)
[ ...] xor: automatically using best checksumming function:
[ ...] avx : 4260.000 MB/sec

Non c'e` AVX (che la CPU ha), ma sse2x4 fa
10GB/sec...
AVX e` usato per l'XOR, non so perche`.

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno martedì 19 aprile 2016 18:40:54 UTC+2, Piergiorgio Sartor ha scritto:
> Il RAID-6 va bene per affidabilita` e per
> flessibilita`. Si puo` sempre aggiungere
> un HDD dopo e fare crescere il RAID.

Lo faccio sopratutto per l'affidabilità.

> Per le prestazioni, pero`, meglio un RAID-10,
> sia nativo "md" che fatto separatamente.
> Il nativo e` forse piu` interessante, dato che
> consente di usare n/k dischi.
> Non so se abbiano aggiunto, non credo, il grow.
>
> Il RAID-6 va bene per NAS o storage, non per
> uso del disco costante da parte di applicativi.

Mai più nulla di diverso da un RAID-6, sopratutto
con dischi delle dimensioni attuali. Non è la prima
volta che mi muore un disco in RAID-5 (o RAID-1),
ricostruisco e mezzora dopo muore un altro disco.

La ricostruzione di volumi con i dischi attuali può
durare anche 1 giorno. Meglio avere un culo parato
e qualche decadimento prestazionale, ma almeno dormo la notte.

> Io avevo un problema simile. Mi serviva LVM,
> RAID e LUKS.
>
> Ho provato tutte le combinazioni, quella che
> alla fine mi pare (per me medesimo) sia il
> miglior compromesso e` RAID->LVM->LUKS.

Quindi tu fai un singolo volume raid, sopra il
quale poi ci piazzi LVM....

[gandalf.co...@gmail.com]

Il giorno martedì 19 aprile 2016 19:16:00 UTC+2, Piergiorgio Sartor ha scritto:
> Con 10 dischi da 200MB/sec (non SSD) si
> arriva a max 2GB/sec di transfer rate
> possibile (per solo i dati 1.6GB/sec).
> Di conseguenza, avendo una capacita` da
> 10GB/sec per il calcolo delle parita`,
> significa che si usera` il 20% della CPU.

20% della CPU, quale CPU? 20% di un core o di
tutti i core della CPU? CPU da quanti core ?

> Da notare, che la CPU usa AVX per il
> calcolo delle parita`.
> Con SSE solamente si va piu` lenti.

Tutto ciò per me è arabo.
Traducete per cortesia. Io ho tutti server Xeon, dai 5400 ai più recenti E5-2600

[Piergiorgio Sartor]

On 2016-04-19 23:17, gandalf.co...@gmail.com wrote:
[...]

> 20% della CPU, quale CPU? 20% di un core o di
> tutti i core della CPU? CPU da quanti core ?

Un core, ovviamente, come ho scritto da
qualche parte non e` MT (multi thread).

>> Da notare, che la CPU usa AVX per il
>> calcolo delle parita`.
>> Con SSE solamente si va piu` lenti.
>
> Tutto ciò per me è arabo.
> Traducete per cortesia. Io ho tutti server Xeon, dai 5400 ai più recenti E5-2600

Il drive RAID-456 fa un test di varie
possibili implementazioni per il
calcolo delle parita` P e Q (nel caso
del RAID-6).

Si va dal semplice codice C, si passa
per codice ottimizzato con MMX, poi
SSE varie e AVX.
MMX, SSE e AVX sono le istruzioni, di
varie generazioni, vettoriali.
Cioe` prendono un vettore (di byte) e
fanno qualcosa. Quindi hanno un elevato
livello di parallelismo.

Ora, come scrivevo sopra, il driver fa
un test e vede quale delle diverse
possibili implementazioni va piu` veloce
ed usa quella.

Come ho riportato nell'altro post, con
SSE (e non AVX) si raggiungono circa
10GB/sec di capacita` di "processamento".
Per un core, sempre.

La cosa piu` semplice da fare e`:

insmod raid456
dmesg

Dovrebbe riportare il test e le prestazioni.

L'unica cosa di cui potrei avere dubbi,
perche` in passato e` successo, e` che il
risultato sia *pessimistico*, in quanto
fatto con il clock minimo e non massimo.

In generale, ti conviene sempre fare delle
prove con una macchina di test.

Il motivo e` che vi sono diversi parametri,
come il chunk size, che possono far variare
le prestazioni in maniera notevole.
Il default (chunk size) di 512K viene considerato,
da qualcuno, eccessivo, e viene consigliato
un valore piu` basso, tipo 64k o 8k.

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno mercoledì 20 aprile 2016 18:47:12 UTC+2, Piergiorgio Sartor ha scritto:
> La cosa piu` semplice da fare e`:
>
> insmod raid456
> dmesg
>
> Dovrebbe riportare il test e le prestazioni.

Il test lo fa solo con raid configurato o fa stime in base alla CPU?
Perchè nel mio computer non da segni di vita:

Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.896289] async_tx: api initialized (async)
Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.900889] md: raid6 personality registered for level 6
Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.900890] md: raid5 personality registered for level 5
Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.900891] md: raid4 personality registered for level 4

ma non ho un raid....

Comunque sia, entrando nel dettaglio, devo sostituire 2 server database, attualmente con 20GB di database (cadauno), 16GB RAM e 1 processore quadcore. RAID-1 (PERC H200) con 2 dischi SATA 7200

Il nuovo server sarà biprocessore esa, 64GB di RAM e RAID-? a 3 o più dischi SAS 15k

Dal punto di vista prettamente hardware, il nuovo server è più potente dei due precedenti messi insieme, questo mi permette di accorpare del materiale, con 1 server ne rimpiazzo e ne libero ben 2.

Non ho la più pallida idea di quale RAID attivare. Ho la possibilità di usare una PERC H730 con BBU e 1GB di cache, o di usare un RAID software.
Posso usare SAS o SSD (ordinandoli) ma ciò che non posso fare (per tempo, voglia, fornitori, possibilità economici, logistica, etc etc) è garantire dischi differenti in termini di vendor o simili. Se ordino 3 dischi, quasi certamente mi arrivano dallo stesso lotto. Prendere o lasciare.

Cosa suggerite di fare, considerata l'esigua mole di dati? Volendo TUTTI i database di ambo i server potrebbero stare interamente in RAM lasciandole libera buona parte per il resto del sistema (20GB+20GB = 40GB circa di database su un server con 64GB di RAM)

[Dottor Mistero]

On 19-Apr-16 19:51, Piergiorgio Sartor wrote:

> Queste sono le prestazioni su AMD Opteron(tm)

[...]

> [ ...] raid6: using algorithm sse2x4 gen() 11027 MB/s

Boh, mi sa che non ci siamo. In questo momento non ho sottomano la NAS,
ma la debian del portatilino mi fornisce:
[ 120.697484] raid6: sse2x1 gen() 2791 MB/s
[ 120.765475] raid6: sse2x1 xor() 2930 MB/s
[ 120.833486] raid6: sse2x2 gen() 4723 MB/s
[ 120.901483] raid6: sse2x2 xor() 4994 MB/s
[ 120.969491] raid6: sse2x4 gen() 5250 MB/s
[ 121.037496] raid6: sse2x4 xor() 2953 MB/s
[ 121.037497] raid6: using algorithm sse2x4 gen() 5250 MB/s
[ 121.037499] raid6: .... xor() 2953 MB/s, rmw enabled

Ma col cavolo che farebbe 5GB/s! E' un "AMD Phenom(tm) II N640 Dual-Core
Processor" che dovrebbe valere meno della metà del core duo di cui ai
precedenti msg.

saluti puramente teorici

[Piergiorgio Sartor]

Vi sono varie possibilita`.

Una e` che vi sia un problema da altre parti.

Un'altra e` che, in effetti, faccia 5GB/sec. :-)

Scherzi a parte, io ti confermo i valori in
termini di CPU load *reale*, cioe` scrivendo
al massimo possibile.

Oltre alle due possibilita` di cui sopra,
bisogna vedere quanta RAM/cache e` usata e
che filesystem c'e`.

Per es., ntfs-3g mi usa di suo un 25% di un core...

bye,

> saluti puramente teorici
>


--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-21 16:46, gandalf.co...@gmail.com wrote:
> Il giorno mercoledì 20 aprile 2016 18:47:12 UTC+2, Piergiorgio Sartor ha scritto:
>> La cosa piu` semplice da fare e`:
>>
>> insmod raid456
>> dmesg
>>
>> Dovrebbe riportare il test e le prestazioni.
>
> Il test lo fa solo con raid configurato o fa stime in base alla CPU?

Da me basta l'insmod, su qualunque PC,
con o senza RAID.
Anche perche`, se ci fosse il RAID il
modulo sarebbe auto caricato.

> Perchè nel mio computer non da segni di vita:
>
> Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.896289] async_tx: api initialized (async)
> Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.900889] md: raid6 personality registered for level 6
> Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.900890] md: raid5 personality registered for level 5
> Apr 21 16:40:59 ale-CELSIUS-W530 kernel: [1410072.900891] md: raid4 personality registered for level 4
>
> ma non ho un raid....

Che versione di kernel hai?
Non saprei da quale kernel hanno iniziato a
visualizzare il test, anche se non credo sia
una cosa recente.

> Comunque sia, entrando nel dettaglio, devo sostituire 2 server database, attualmente con 20GB di database (cadauno), 16GB RAM e 1 processore quadcore. RAID-1 (PERC H200) con 2 dischi SATA 7200
>
> Il nuovo server sarà biprocessore esa, 64GB di RAM e RAID-? a 3 o più dischi SAS 15k
>
> Dal punto di vista prettamente hardware, il nuovo server è più potente dei due precedenti messi insieme, questo mi permette di accorpare del materiale, con 1 server ne rimpiazzo e ne libero ben 2.
>
> Non ho la più pallida idea di quale RAID attivare. Ho la possibilità di usare una PERC H730 con BBU e 1GB di cache, o di usare un RAID software.
> Posso usare SAS o SSD (ordinandoli) ma ciò che non posso fare (per tempo, voglia, fornitori, possibilità economici, logistica, etc etc) è garantire dischi differenti in termini di vendor o simili. Se ordino 3 dischi, quasi certamente mi arrivano dallo stesso lotto. Prendere o lasciare.
>
> Cosa suggerite di fare, considerata l'esigua mole di dati? Volendo TUTTI i database di ambo i server potrebbero stare interamente in RAM lasciandole libera buona parte per il resto del sistema (20GB+20GB = 40GB circa di database su un server con 64GB di RAM)

Riguardo i dischi, come gia` scritto, se hai
la stessa marca puoi ruotarli per far si che
il tempo di funzionamento (o le scritture)
siano diverse tra loro.

Per lo storage userei SSD in RAID-1 (2+1,
cioe` 3 in totale).

Hai problemi di costi, per il PERC H370?
Detto altrimenti, hai delle remore per l'uso
di tale controller?
Scrivevi di portabilita` in caso di guasti.
Hai altri pensieri?

Se non hai queste remore, prendi il PERC.

Altrimenti, se devi ottimizzare costi od
altro, potrebbe essere meglio il RAID SW.

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno giovedì 21 aprile 2016 21:28:36 UTC+2, Piergiorgio Sartor ha scritto:
> Che versione di kernel hai?
> Non saprei da quale kernel hanno iniziato a
> visualizzare il test, anche se non credo sia
> una cosa recente.

$ uname -a
Linux ale-CELSIUS-W530 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

> Per lo storage userei SSD in RAID-1 (2+1,
> cioe` 3 in totale).

Cioè RAID-1 a tre dischi? Cos'è 2+1 ? RAID-1 a 2 dischi
dove ne cambio uno con un terzo per sicurezza ?

Troppo sbattimento. Voglio semplificarmi la vita,
non aggiungere operazioni che devo svolgere, sono
già fin troppo carico.

Parlando di RAID-1 software, dove posso mettere i dischi
che voglio senza far incazzare la controller, potrei
usare:

Intel 535
Samsung 850 Pro/Evo
Seagate 600 (ma non mi convince)

Garantire 2 vendor differenti a livello di SSD sarebbe
anche fattibile, garantirne 3 proprio no.

Un RAID-1 a tre dischi farebbe rompere i 3 dischi
quasi in simultanea. Che sia il caso di fare RAID-1
a 2 dischi più hotspare fisso? Questo però non tutela
dal guasto pressochè simultaneo dei due dischi, dove
l'hotspare non aiuterebbe in alcun modo.

In soldoni, mi fa paura avere due dischi "a countdown"
ed allo stesso tempo so di non essere in grado di
garantire una sostituzione preventiva ogni tot mesi.
(dovrei farlo per forza io, delegare altri significa
mettersi in problemi ed io NON lo voglio fare, non
ho tempo)

> Hai problemi di costi, per il PERC H370?

PERC H370 ? Intendi 730? Non ho problemi di costi,
ho già tale controller (è in arrivo insieme al
server). L'ho già comprata.

> Detto altrimenti, hai delle remore per l'uso
> di tale controller?
> Scrivevi di portabilita` in caso di guasti.
> Hai altri pensieri?

si, ho delle remore.
Mi sto ritrovando ora (colpa mia, lo ammetto)
ad avere molti server che sono diventati obsoleti
e solo ora mi sono accorto che mamma DELL non li
supporta più nemmeno come parti di ricambio. L'unico
modo per avere la parte sostituita è attendere un
guasto, dato che non le vendono più come "spare"

Quindi, detto in altre parole: quando il server
attuale si guasterà, potrò ordinare la componente
guasta, attenderla (1 giorno? 2 giorni? 7 giorni? dipende
dalla loro disponibilità) e fare la sostituzione (sempre
che riesca). Tutto questo con un bel fermo macchina.

Scopro ora che non posso migrare da H200/H700 alla H730
attuale. Non è supportato. Devo per forza azzardare tutto
il percorso di upgrade: H200 -> H700 -> H710 -> H730,
che, detto francamente, è una puttanata pazzesca. Troppi
passaggi, troppe cose che possono andare storte senza
contare che il downgrade è impossibile. Se riuscissi a
passare da H200 a H700 o H710 e poi per qualche arcano
motivo non riuscissi a passare alla H730, sarei bloccato
alla H710, senza possibilità di ritornare sul server iniziale.

In pratica, me la prendo nel c.....

Posso capire l'uso di hardware raid su server corazzati dove
le performance sono fondamentali (leggasi: un nodo XenServer o analogo),
ma in questo caso devo fare dei database, come scritto, l'hardware
ordinato è più potente degli altri due server messi assieme.

Eviterei molto molto volentieri di vincolarmi ad un brand di
controller hardware ed essere soggetto alle tirate di culo
del brand stesso, che ultimamente non mi sta piacendo affatto
nemmeno come assistenza tecnica (non sono in grado di dirmi
quali dischi sono compatibili sulle loro controller, perchè
loro non fanno questo tipo di analisi. Devono cercare io vari
codici prodotto e chiedere a loro di volta in volta, perchè
le LORO controller hanno la puzza sotto il naso e funzionano
SOLO con un singolo disco, tutti gli altri li marcano come non
certificati e generano warning perenni di raid degradato non-critical,
che non è mai bello, sopratutto quando si hanno sistemi di monitoraggio
automatico)

> Se non hai queste remore, prendi il PERC.
>
> Altrimenti, se devi ottimizzare costi od
> altro, potrebbe essere meglio il RAID SW.

In *questo* caso non è un problema di costi. Ho già ordinato
il server, ho già ordinato la controller, abbiamo già
pagato tutto. Quindi ho già tutto a disposizione (deve solo arrivare)

Non so se usarla o meno per i suddetti motivi. Ho paura a vincolarmi troppo
e non riuscire più a venirne fuori senza lunghi e complessi sistemi
di backup+restore con conseguente down dei servizi.

Un raid software, se dovesse andare tutto in vacca, prendo i dischi e li sposto
di server. 1 minuto ed ho risolto. 5 minuti nel caso dovessi cambiare anche
il tray dei dischi, proprio nella peggiore delle ipotesi.

[Piergiorgio Sartor]

On 2016-04-22 10:47, gandalf.co...@gmail.com wrote:
[...]

> $ uname -a
> Linux ale-CELSIUS-W530 3.13.0-83-generic #127-Ubuntu SMP Fri Mar 11 00:25:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Strano, mi pare di avere un PC con quel
kernel. Dovrebbe dare i numeri :-) anche
quello.

>> Per lo storage userei SSD in RAID-1 (2+1,
>> cioe` 3 in totale).
>
> Cioè RAID-1 a tre dischi? Cos'è 2+1 ? RAID-1 a 2 dischi
> dove ne cambio uno con un terzo per sicurezza ?
>
> Troppo sbattimento. Voglio semplificarmi la vita,
> non aggiungere operazioni che devo svolgere, sono
> già fin troppo carico.

A parte che si puo` fare in automatico,
l'alternativa usata (da data center) e`
3 SSD in RAID-1.

> Parlando di RAID-1 software, dove posso mettere i dischi
> che voglio senza far incazzare la controller, potrei

Questo proprio non saprei.

> usare:
>
> Intel 535
> Samsung 850 Pro/Evo
> Seagate 600 (ma non mi convince)
>
> Garantire 2 vendor differenti a livello di SSD sarebbe
> anche fattibile, garantirne 3 proprio no.

Due potrebbero anche bastare.

> Un RAID-1 a tre dischi farebbe rompere i 3 dischi
> quasi in simultanea. Che sia il caso di fare RAID-1
> a 2 dischi più hotspare fisso? Questo però non tutela
> dal guasto pressochè simultaneo dei due dischi, dove
> l'hotspare non aiuterebbe in alcun modo.
>
> In soldoni, mi fa paura avere due dischi "a countdown"
> ed allo stesso tempo so di non essere in grado di
> garantire una sostituzione preventiva ogni tot mesi.
> (dovrei farlo per forza io, delegare altri significa
> mettersi in problemi ed io NON lo voglio fare, non
> ho tempo)

Metti 3 dischi in RAID-1.

>> Hai problemi di costi, per il PERC H370?
>
> PERC H370 ? Intendi 730? Non ho problemi di costi,
> ho già tale controller (è in arrivo insieme al
> server). L'ho già comprata.

Quello che e`... :-)

[...]

>> Altrimenti, se devi ottimizzare costi od
>> altro, potrebbe essere meglio il RAID SW.
>
> In *questo* caso non è un problema di costi. Ho già ordinato

Faceva parte di "altro"... :-)

> il server, ho già ordinato la controller, abbiamo già
> pagato tutto. Quindi ho già tutto a disposizione (deve solo arrivare)
>
> Non so se usarla o meno per i suddetti motivi. Ho paura a vincolarmi troppo
> e non riuscire più a venirne fuori senza lunghi e complessi sistemi
> di backup+restore con conseguente down dei servizi.
>
> Un raid software, se dovesse andare tutto in vacca, prendo i dischi e li sposto
> di server. 1 minuto ed ho risolto. 5 minuti nel caso dovessi cambiare anche
> il tray dei dischi, proprio nella peggiore delle ipotesi.

Esatto.

Ora, ognuno decide per se, ma io ho sempre
avuto riscontri positivi con il RAID SW di
Linux, anche quando vi sono stati problemi.

Fai un po' di test, con 3 HDD o 3 SSD, vedi
che parametri sono modificabili e prova se
vi sono configurazioni ottimali per il tuo
uso ed in bocca al lupo... :-)

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-22 17:52, Piergiorgio Sartor wrote:
[...]
>
> Due potrebbero anche bastare.

Due *vendor* intendo, non due SSD...

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno venerdì 22 aprile 2016 17:54:39 UTC+2, Piergiorgio Sartor ha scritto:
> A parte che si puo` fare in automatico,
> l'alternativa usata (da data center) e`
> 3 SSD in RAID-1.

In automatico cosa? Il replace in caso di guasto o la
sostituzione preventiva ? In quest'ultimo caso, come faresti ?

> Ora, ognuno decide per se, ma io ho sempre
> avuto riscontri positivi con il RAID SW di
> Linux, anche quando vi sono stati problemi.

Questo è vero, anche io.
Proprio in questi giorni ho sostituito un disco
guasto in un raid software operativo da circa
SETTE anni. (ps: dischi SATA, nessuno dei miei dischi
SAS ha mai resistito tanto)

[Piergiorgio Sartor]

On 2016-04-22 18:35, gandalf.co...@gmail.com wrote:
> Il giorno venerdì 22 aprile 2016 17:54:39 UTC+2, Piergiorgio Sartor ha scritto:
>> A parte che si puo` fare in automatico,
>> l'alternativa usata (da data center) e`
>> 3 SSD in RAID-1.
>
> In automatico cosa? Il replace in caso di guasto o la
> sostituzione preventiva ? In quest'ultimo caso, come faresti ?

Con un cron job, per es.

Se si tratta di SSD, quindi senza problemi di
spin up, si puo` ogni giorno, ogni settimana,
ogni mese, vedi tu, far partire un cron job che
controlla, per es., il Total Host Sector Write
oppure Ave Block-Erase Count, (od il Power On
Hours, ma bisogna stare attenti con il SSD
spare) di SMART e, se questo e` piu` di tot
dell'SSD spare, aggiunge quest'ultimo e (quando
finito) toglie l'altro (il piu` usato, credo,
bisogna fare due conti).

In caso di "mdadm" (versione recente), c'e`
"--replace" che aggiunge lo spare e toglie
il target di replace, alla fine.

Credo sia qualcosa come:

mdadm --replace /dev/mdX /dev/sdX

Deve esserci uno spare, chiaramente.
Quando finito:

mdadm --remove /dev/sdX
mdadm --zero-superblock /dev/sdX
mdadm --add /dev/mdX /dev/sdX

L'ultimo comando aggiunge /dev/sdX come
(nuovo) spare.
Invece di "--zero-superblock", si potrebbe
fare un "hdparm --security-erase-enhanced"
oppure "hdparm --security-erase" o quello
che e`, per resettare tutti i parametri del
SSD, ed azzerare i trim counter.

[...]

> Proprio in questi giorni ho sostituito un disco
> guasto in un raid software operativo da circa
> SETTE anni. (ps: dischi SATA, nessuno dei miei dischi
> SAS ha mai resistito tanto)

Secondo Backblaze gli HDD consumer hanno
"sopravvivenze" equivalente, forse migliori,
degli HDD enterprise.

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno venerdì 22 aprile 2016 19:19:53 UTC+2, Piergiorgio Sartor ha scritto:
> Se si tratta di SSD, quindi senza problemi di
> spin up, si puo` ogni giorno, ogni settimana,
> ogni mese, vedi tu, far partire un cron job che
> controlla, per es., il Total Host Sector Write
> oppure Ave Block-Erase Count, (od il Power On
> Hours, ma bisogna stare attenti con il SSD
> spare) di SMART e, se questo e` piu` di tot
> dell'SSD spare, aggiunge quest'ultimo e (quando
> finito) toglie l'altro (il piu` usato, credo,
> bisogna fare due conti).

Continua a non essermi chiara una cosa.
Te parli di un RAID-1 a due dischi + spare, o 3 dischi simultanei?
Nel terzo caso: la probabilità che si spacchino tutti e 3 in tempi
pressochè identici è altissima. (do per scontato che il vendor dei
dischi sia il medesimo)

Nel primo caso, quando si spacca un disco, lo spare entra in
azione immediatamente ed in automatico. Bisogna sperare che durante
il rebuild non si spacchi l'altro disco.

Però, statisticamente, di che intervalli di sostituzione preventiva
si parla? 1 volta l'anno? 1 volta ogni 6 mesi?

Parlando di dischi meccanici, tolto partite difettose o casi d'uso particolari,
un HDD tradizionale fa senza problemi almeno 2-3 anni di onorato servizio.

Un SSD? Perchè se devo stare con il timore di doverli cambiare ogni 2 mesi
proprio non mi va. Se invece la sostituzione preventiva la si effettua
ogni anno o giù di li, tutto cambia. Posso benissimo pianificare o, come te
suggerisci, schedulare un cronjob che automaticamente mi cambia un disco dei due con lo spare (che sarà opportunamente mantenuto spento fino al suo utilizzo)

Detto ciò: i valori smart di cui parli, indicano lo stato di usura dei dischi?
Sotto quale soglia conviene sostituire preventivamente il tutto ?
Sono affidabili ? Vorrei evitare di far affidamento a tali valori e poi ritrovarmi tutto all'aria. (come già capitato di recente: mi fidavo della controller e del suo consistency check finchè DUE dischi si son spaccati in simultanea senza che la controller si accorgesse di nulla. Cambio un disco, perdo tutto perchè era rotto anche l'altro. Raid1)

[Piergiorgio Sartor]

On 2016-04-23 20:07, gandalf.co...@gmail.com wrote:
[...]

> Continua a non essermi chiara una cosa.
> Te parli di un RAID-1 a due dischi + spare, o 3 dischi simultanei?
> Nel terzo caso: la probabilità che si spacchino tutti e 3 in tempi
> pressochè identici è altissima. (do per scontato che il vendor dei
> dischi sia il medesimo)

Piu` dischi hai in RAID-1, piu` bassa e`
la probabilita` che si rompano *tutti*
in contemporanea. Anche se sono dello
stesso vendor.

Metterne 3 in RAID-1 e` la procedura
piu` semplice e, per certi aspetti,
piu` sicura.

Ruotare i dischi ogni tot ha altri
vantaggi, in particolare quello di
distribuire l'usura nel tempo in
maniera non uniforme.

> Nel primo caso, quando si spacca un disco, lo spare entra in
> azione immediatamente ed in automatico. Bisogna sperare che durante
> il rebuild non si spacchi l'altro disco.

Appunto per questo conviene che siano 3
in RAID-1 simultaneamente.
Assumendo che, quando si rompe un disco,
venga sostituito in tempi decenti.

> Però, statisticamente, di che intervalli di sostituzione preventiva
> si parla? 1 volta l'anno? 1 volta ogni 6 mesi?

Questo e` da vedersi, bisognerebbe avere
le statistiche dei dispositivi.
Bisogna anche valutare quanto sia, come
dire, "fastidioso" il rebuild.
Cioe` se dura 1 ora o 10 ore, se si deve
usare l'array o meno in quel periodo.

> Parlando di dischi meccanici, tolto partite difettose o casi d'uso particolari,
> un HDD tradizionale fa senza problemi almeno 2-3 anni di onorato servizio.

Quello che e` da vedere e` la variazione
intorno ai quei 2-3 anni.

Usando HDD da 1TB, io ho visto i primi
difetti intorno alle 8000 ore (anche se
un disco ha dato problemi dopo meno, ma
forse e` stato un caso particolare).
Altri sono durati oltre le 30000 ore
senza lamentarsi.
Un tempo comune per i primi problemi e`
intorno le 20000 ore.

Quindi, spannometricamente, direi che se
devo ruotare preventivamente dei dischi
di quel tipo, dovrei considerare un
intervallo minore di 8000 ore.

> Un SSD? Perchè se devo stare con il timore di doverli cambiare ogni 2 mesi
> proprio non mi va. Se invece la sostituzione preventiva la si effettua
> ogni anno o giù di li, tutto cambia. Posso benissimo pianificare o, come te
> suggerisci, schedulare un cronjob che automaticamente mi cambia un disco dei due con lo spare (che sarà opportunamente mantenuto spento fino al suo utilizzo)

La durata di un SSD *serio* dipende quasi
esclusivamente da quanto ci si scrive.
M_M ha postato un link interessante al
riguardo:

http://www.miamammausalinux.org/2016/03/google-e-laffidabilita-della-tecnologia-ssd/

> Detto ciò: i valori smart di cui parli, indicano lo stato di usura dei dischi?

Esattamente, anche se non so quale sia
piu` rilevante, se le scritture assolute
o le cancellazioni.
Forse dipende anche dal costruttore.

> Sotto quale soglia conviene sostituire preventivamente il tutto ?

Mah, non saprei esattamente, bisognerebbe
cercare statistiche al riguardo.
In generale, spesso il costruttore del SSD
dice quanti GB/TB in scrittura sono... uhm...
"garantiti".
Se un SSD e` dato per, chesso`, 10TB di dati
scritti, allora si puo` pensare di ruotarlo,
per es., ogni TB di dati scritti.
In modo tale che di 3 SSD, vi sia una differenza
di 1TB tra la piu` vecchia e quella di mezzo, ed
un 1TB tra quella di mezzo e la piu` giovane.
Questo e` un esempio a caso, bisogna adattare
il tutto alle proprio esigenze in funzione delle
informazioni disponibili.

> Sono affidabili ? Vorrei evitare di far affidamento a tali valori e poi ritrovarmi tutto all'aria. (come già capitato di recente: mi fidavo della controller e del suo consistency check finchè DUE dischi si son spaccati in simultanea senza che la controller si accorgesse di nulla. Cambio un disco, perdo tutto perchè era rotto anche l'altro. Raid1)

Quelli sono parametri misurati, quindi salvo
bug software dicono esattamente cose sia
successo al SSD fino a quel momento.

Che poi le rotture rispettino le dichiarazioni
del costruttore, quella e` un'altra storia.

Ad ogni modo, forse se hai questi dubbi, ti
conviene semplicemente un RAID-1 con 3 SSD.

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno sabato 23 aprile 2016 20:54:19 UTC+2, Piergiorgio Sartor ha scritto:
> Piu` dischi hai in RAID-1, piu` bassa e`
> la probabilita` che si rompano *tutti*
> in contemporanea. Anche se sono dello
> stesso vendor.

Vero, ma in parte.
Se i dischi SSD avessero 1000 scritture prime del
guasto, averne 2 o 10 in RAID-1, comporterebbe avere
1000 scritture contemporanee e quindi anche i guasti.

e' chiaro, si parla di statistiche, ma un conto è avere
problemi su 3 dischi meccanici, un altro è averne su dischi
SSD soggetti ad usura nettamente maggiore.

> Usando HDD da 1TB, io ho visto i primi
> difetti intorno alle 8000 ore (anche se
> un disco ha dato problemi dopo meno, ma
> forse e` stato un caso particolare).

11 mesi circa

> Altri sono durati oltre le 30000 ore
> senza lamentarsi.
> Un tempo comune per i primi problemi e`
> intorno le 20000 ore.

Oltre 4 anni.
Io dicevo 2 o 3, ero stato volutamente conservativo.

> Ad ogni modo, forse se hai questi dubbi, ti
> conviene semplicemente un RAID-1 con 3 SSD.

E nessuna rotazione ?
Perchè questa storia di usare 3 SSD uguali in RAID-1 proprio non mi convince.
Va contro ogni logica. E' risaputo che gli SSD si "consumano".
Se sono 3 SSD identici, in RAID-1 per forza di cose si consumeranno in maniera
identica e di conseguenza, si romperanno tutti e 3 assieme.
Se non lo fanno, è un puro caso. In pratica farei affidamento su una "anomalia"

In altre parole: a parità di utilizzo, 3 dischi meccanici si rompono nello stesso momento per pura sfiga. (più dischi metti, minore è il caso che si rompano tutti assieme)
3 SSD si rompono nello stesso momento per definizione.
3 SSD *non* si rompono nello stesso momento per pura fortuna, l'opposto esatto di un disco meccanico.

[Piergiorgio Sartor]

On 2016-04-23 22:28, gandalf.co...@gmail.com wrote:
[...]

> Se i dischi SSD avessero 1000 scritture prime del
> guasto, averne 2 o 10 in RAID-1, comporterebbe avere
> 1000 scritture contemporanee e quindi anche i guasti.

No, perche` e` una questione *statistica*.
Esiste una probabilita` di guasto dopo, per
es., 1000 scritture.
Cosa vuol dire? Che, sempre per es., si ha
una distribuzione Gaussiana, con una certa
varianza, e *media* "1000 scritture".
La probabilita` congiunta, data l'indipendenza
degli eventi (un evento non causa l'altro) e`
data dal prodotto delle probabilita`.
Siccome queste sono sempre <= 1 (e quasi sempre
< 1), il prodotto e` sempre piu` piccolo al
moltiplicare di piu` casi.
Piu` semplicemente, se la probabilita` di rottura
(evento R) e` del 10% (in qualunque momento), cioe`
0.1, la probabilita` di X rotture *contemporanee*
e` la probabilita` che l'evento si verifichi per
X volte assieme, cioe` P(R)*P(R)*...*P(R)=P(R)^X.
Per 3 rotture contemporanee e` 0.1^3=.001
cioe` dello 0.1%!
Siamo passati dal 10% al 0.1%, passando da 1 a
3 dispositivi.
Questo, ovviamente, nell'ipotesi che se uno
si rompe non faccia un corto e bruci anche un
altro...
Ovviamente la probabilita` che *almeno* uno
si rompa e` molto piu` alta.
Cioe`, e` uguale 1 meno la probabilita` che
*nessuno* si rompa. Questa e` .9^3, quindi
P(Ralmeno1)=1-.9^3=.271, cioe` il 27.1%.
Il cui .1% e` la probabilita` di prima.

> e' chiaro, si parla di statistiche, ma un conto è avere
> problemi su 3 dischi meccanici, un altro è averne su dischi
> SSD soggetti ad usura nettamente maggiore.

Il tipo di usura non cambia la statistica,
anche ammesso che sia maggiore, il che non
e` detto sia vero.
Per es. un disco che gira senza far niente
si consuma, un SSD no.
Senza contare altri incidenti secondari,
come vibrazioni, urti, scossoni, etc.

[...]

>> Ad ogni modo, forse se hai questi dubbi, ti
>> conviene semplicemente un RAID-1 con 3 SSD.
>
> E nessuna rotazione ?

Come scrivevo, e` prassi comune usare SSD
in triple RAID-1.
La rotazione puo` avere dei vantaggi,
bisogna valutare se ne valga la pena.
Pensandoci meglio, forse ne vale la pena
piu` per normali HDD che SSD.

> Perchè questa storia di usare 3 SSD uguali in RAID-1 proprio non mi convince.
> Va contro ogni logica. E' risaputo che gli SSD si "consumano".

Si consumano quanto gli HDD, e` solo una
questione diversa, ma l'usura esiste in
tutti i casi.
Valgono le stesse precise identiche
considerazioni.

L'unica differenza registrata tra HDD e SSD
e` che i primi hanno un "graceful degradation",
cioe` iniziano a dare problemi, ma
funzionanicchiano, i secondi, invece, pare,
muoiano sul colpo.
Per questo 3, invece di 2, il margine "soft" di
rottura e` discretizzato dal terzo elemento.

> Se sono 3 SSD identici, in RAID-1 per forza di cose si consumeranno in maniera
> identica e di conseguenza, si romperanno tutti e 3 assieme.
> Se non lo fanno, è un puro caso. In pratica farei affidamento su una "anomalia"

Come gia` scritto, la probabilita` diminuisce
con il numero di dispositivi, non aumenta.
Quello che aumenta e` la probabilita` che
*almeno* uno si rompa.
La probabilita` che *tutti* si rompano nello
stesso momento decresce.

Per questo il RAID-5 e` pericoloso all'aumentare
dei dischi, perche` la probabilita` che *almeno*
due dischi si rompano aumenta.
Ma per il RAID-1 devono rompersi tutti, per cui
e` piu` sicuro all'aumentare degli elementi.

> In altre parole: a parità di utilizzo, 3 dischi meccanici si rompono nello stesso momento per pura sfiga. (più dischi metti, minore è il caso che si rompano tutti assieme)

No!
Stai facendo confusione fra gli eventi "rotture
simultanee" e "rotture singole".
Cioe` tra "tutti" ed "almeno qualcuno".
E stai assegnando un evento agli HDD e l'altro
agli SSD.

> 3 SSD si rompono nello stesso momento per definizione.
> 3 SSD *non* si rompono nello stesso momento per pura fortuna, l'opposto esatto di un disco meccanico.

Tutto sbagliato, valgono le stesse regole,
sia per HDD che per SSD.
Gli HDD si rompono contemporaneamente tanto
quanto gli SSD.
Se fai RAID con HDD *uguali* hai buone probabilita`
di avere rotture multiple simultanee.

bye,

--

piergiorgio

[Piergiorgio Sartor]

On 2016-04-23 23:22, Piergiorgio Sartor wrote:
[...]

> Cosa vuol dire? Che, sempre per es., si ha
> una distribuzione Gaussiana, con una certa

Ovviamente Gaussiana non modella sicuramente
il caso di rotture che aumentano al passare
del tempo e / o scritture.

Serve una distribuzione asimmetrica... Bah...

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno sabato 23 aprile 2016 23:24:38 UTC+2, Piergiorgio Sartor ha scritto:
> No, perche` e` una questione *statistica*.
> Esiste una probabilita` di guasto dopo, per
> es., 1000 scritture.
> Cosa vuol dire? Che, sempre per es., si ha
> una distribuzione Gaussiana, con una certa
> varianza, e *media* "1000 scritture".

Questa cosa non mi convince affatto.
Presumibilmente userò degli Intel S3610 da 200GB.
Specifiche:
http://www.intel.com/content/www/us/en/solid-state-drives/ssd-dc-s3610-spec.html

"Endurance: 3 drive writes per day for 5 years"

Sono drive di fascia enterprise, presumo che Intel non la spari grossa come si tende a fare in ambito consumer.

In RAID-1, tutti e 3 i dischi vengono scritti in egual misura, quindi, in egual misura si consumano.

La statistica di cui parli è valida per un evento straordinario del tipo: drive difettoso, si è rotto dopo 6 mesi e non dopo 3 anni.
Aumentando il numero di drive, scende il fattore sfiga ma aumenta la probabilità di guasto (più drive hai, più è probabile che qualcosa si rompa). Questo è palese.

Ma il limite di scritture resta, ed è il medesimo per tutti e 3 i drive, quindi, salvo guasti imprevedibili (dove la tua statistica è corretta), i 3 SSD si romperanno pressochè nello stesso momento attorno ai 3 anni, avendo tutti e 3 lo stesso identico workload.

Detto ciò, pensavo di fare un RAID-1 a 3 dischi (S3610 da 300GB) più hotspare. 4 dischi per server. Non so se buttarci dentro un Samsung 850 Pro, nei 3 dischi in RAID, giusto per avere qualche garanzia in più. Il Samsung è fascia consumer, non vorrei potesse dare problemi.....

Di dischi enterprise simili, per prezzo e caratteristiche, agli S3610 non ne conosco....

[Piergiorgio Sartor]

On 2016-04-24 13:04, gandalf.co...@gmail.com wrote:
[...]

> Questa cosa non mi convince affatto.

Come ti pare, la statistica e` quella.

> Presumibilmente userò degli Intel S3610 da 200GB.
> Specifiche:
> http://www.intel.com/content/www/us/en/solid-state-drives/ssd-dc-s3610-spec.html
>
> "Endurance: 3 drive writes per day for 5 years"
>
> Sono drive di fascia enterprise, presumo che Intel non la spari grossa come si tende a fare in ambito consumer.
>
> In RAID-1, tutti e 3 i dischi vengono scritti in egual misura, quindi, in egual misura si consumano.

Se due auto uguali fanno lo stesso percorso,
si usurano in egual misura, ma mica per forza
si rompono allo stesso *preciso* momento.
Quello che intel ti da e` un valore statistico.
Loro hanno provato ed hanno visto che, chesso`,
il 99% degli SSD, ha quella durata *minima*.
Quindi ti dicono che non puoi aspettarti (i.e.
non garantiscono) piu` di quello.
Non vuol dire che dopo 5 anni il SSD si ferma
e va in pensione.

> La statistica di cui parli è valida per un evento straordinario del tipo: drive difettoso, si è rotto dopo 6 mesi e non dopo 3 anni.

No, e` valida *sempre*, anzi proprio non e` valida
per eventi straordinari, dato questi sono difficilmente
modellabili.

> Aumentando il numero di drive, scende il fattore sfiga ma aumenta la probabilità di guasto (più drive hai, più è probabile che qualcosa si rompa). Questo è palese.

E questo e` quello che ti ho scritto.
Aumenta la probabilita` di *almeno* un
guasto, ma diminuisce quella di un
guasti *simultanei*.
Per questo si usano 3 SSD e non due.
In aggiunta al tipo di rottura, non
soft, ma hard.

> Ma il limite di scritture resta, ed è il medesimo per tutti e 3 i drive, quindi, salvo guasti imprevedibili (dove la tua statistica è corretta), i 3 SSD si romperanno pressochè nello stesso momento attorno ai 3 anni, avendo tutti e 3 lo stesso identico workload.

Ma non e` un limite hard, non e` che dopo tot
scritture il SSD si rompe e si ferma.
E` un limite che il costruttore pone per
potersi dare un range.
E` come il MTBF degli HDD, non e` che dopo
esattamente 50.000 ore si rompe e muore.

> Detto ciò, pensavo di fare un RAID-1 a 3 dischi (S3610 da 300GB) più hotspare. 4 dischi per server. Non so se buttarci dentro un Samsung 850 Pro, nei 3 dischi in RAID, giusto per avere qualche garanzia in più. Il Samsung è fascia consumer, non vorrei potesse dare problemi.....
>
> Di dischi enterprise simili, per prezzo e caratteristiche, agli S3610 non ne conosco....

Non saprei, vi sono dei Samsung enterprise e,
forse, dei Crucial.

bye,

--

piergiorgio

[gandalf.co...@gmail.com]

Il giorno domenica 24 aprile 2016 13:22:45 UTC+2, Piergiorgio Sartor ha scritto:
> Non saprei, vi sono dei Samsung enterprise e,
> forse, dei Crucial.

Ok, ho trovato dei Samsung da datacenter.
Pertanto, farò 2 SSD Intel ed 1 Samsung. Può avere senso tenere un hotspare nella macchina, portando il tutto, di fatto, a 4 dischi ?

Tanto comunque dovrei tenere degli SSD di scorta, tanto vale tenerli già dentro in modo da farli attivare in automatico al bisogno, senza il mio intervento.

Per la sostituzione preventiva, che valori suggerisci di controllare e sopratutto, come suggerisci di operare ? Tolgo 1 disco a caso 3 tre sostituendolo con 1 nuovo (magari l'hotspare già presente) ?

Così: raid-1 a 3 dischi + hotspare. Dopo un po (quanto?) tolgo 1 disco ed attendo il rebuild su hotspare, nel frattempo aggiungo un ulteriore disco come hotspare.

Speriamo che tenere l'hotspare fermo per anni non abbia l'effetto contrario di attivare il disco e vederlo rotto dopo breve (come capita con i dischi meccanici, dopo anni di rotazioni inutili, non appena entra in funzione salta)

[Piergiorgio Sartor]

On 2016-04-24 21:34, gandalf.co...@gmail.com wrote:
[...]

> Pertanto, farò 2 SSD Intel ed 1 Samsung. Può avere senso tenere un hotspare nella macchina, portando il tutto, di fatto, a 4 dischi ?

Un hot spare fa sempre comodo, se non
vi sono altre controindicazioni (costo,
spazio, etc.), non credo sia negativo.

> Tanto comunque dovrei tenere degli SSD di scorta, tanto vale tenerli già dentro in modo da farli attivare in automatico al bisogno, senza il mio intervento.

Si, pensavo lo stesso, anche perche`,
a differenza degli HDD, non dovrebbero
consumarsi semplicemente stando in
attesa accesi... Non credo, almeno.

> Per la sostituzione preventiva, che valori suggerisci di controllare e sopratutto, come suggerisci di operare ? Tolgo 1 disco a caso 3 tre sostituendolo con 1 nuovo (magari l'hotspare già presente) ?

Per gli HDD io controllo le ore di
accensione. Per gli SSD, forse sarebbe
il caso di vedere le scritture.
Scrivo "forse", perche` non sono sicuro
quale dei parametri disponibili sia piu`
significativo (tra erase, write, reserve,
e quant'altro...).

Non togli un disco a caso, togli il piu`
"vecchio" (come parametro).
L'idea e`, dopo 3 o 4 rotazioni, di avere
il parametro in questione in "scala".
Per es., se consideriamo le ore di accensione,
l'ideale sarebbe avere 3 dischi con, sempre
come esempio, 1000, 2000 e 3000 ore e magari
lo spare con 1000 ore. Dopo altre 1000 ore,
si avra` 2000, 3000 e 4000 ore, con lo spare
sempre a 1000 (non e` vero, ma e` un esempio).
A questo punto si sostituisce il disco da 4000
ore con quello da 1000. Si avranno quindi 3
dischi da 1000, 2000 e 3000 ore (di nuovo, in
questo caso), ma lo spare con 4000 ore.
Dopo 4000 ore, si avra` 5000, 6000 e 7000 per
i 3 dischi e lo spare sempre a 4000 ore (sempre
falso, sempre un esempio).
Quindi si ripete, e si cambia il disco da 7000
ore con quello da 4000. Quindi 4000, 5000 e 6000
in funzione e 7000 spare. Dopo 4000 ore si ripete.

Qui ho usato "ore", ma si puo` (deve?) scegliere
qualunque parametro che abbia senso.
Per gli HDD, io mettevo in deep sleep l'HDD spare.
All'epoca il power on hours non aumentava.
Per gli SSD, forse non si riesce. Non so.

> Così: raid-1 a 3 dischi + hotspare. Dopo un po (quanto?) tolgo 1 disco ed attendo il rebuild su hotspare, nel frattempo aggiungo un ulteriore disco come hotspare.

Se usi "md", il comando e` "--replace".
Automaticamente lo spare sostituisce il target,
copiando i dati da questo (se leggibili, se no
dal resto dell'array).
Quando ha finito, il target diventa faulty.
Quindi serve un "--remove" e un cleanup (forse
un SATA secure erase).

Se non usi "md", dipende dal controller, ma
io farei un "grow" a 4 dischi ed un "reduce"
a 3 dischi (diversi dai 3 iniziali).

> Speriamo che tenere l'hotspare fermo per anni non abbia l'effetto contrario di attivare il disco e vederlo rotto dopo breve (come capita con i dischi meccanici, dopo anni di rotazioni inutili, non appena entra in funzione salta)

Come scritto prima, non dovrebbe.
Se li ruoti, pero`, non si pone il problema.

Se non li ruoti, forse vi e` una questione da
considerare. Il costo (e le prestazioni) degli
SSD cambia rapidamente col tempo, non so se sia
scaltro tenerne uno a far niente.

bye,

--

piergiorgio