[Consiglio] SSD raid 1 con CentOS

[khael]

Salve a tutti,
apro un th dedicato perchè la domande è "delicata".
In ufficio abbiamo un server con centos su cui gira un database di circa 15gb.
Il server è online 24@24 per 3 anni (dopo viene sostiuito).

Attualmente l'hd che c'è ha qualche problema pur essendo praticamente nuovo.
Inspiegabilmente l'ultimo server c'è ci hanno venduto ha 1 solo hd e quindi vorrei mettere almeno un raid1.

Volevo installare 2 ssd in raid1, perchè il db gira tutto su hd e velocizzerei di molto alcune operazioni.

Ho molta paura però sia per il trim (è supportato in raid 1 e da linux? in giro non ho trovato una risposta "sicura") e poi sull'affidabilità.

Uso ssd da 1 anno circa, però qui si parla di ssd che devono essere online 24@24 e per almeno 3 anni....

Che dite?

ovviamente c'è il backup quotidiano esterno, ma comunque in caso di "fermo macchina" si perde una giornata di lavoro....

[blacksonnY]

Sicuramente altri utenti ti diranno il contrario, ma non ho mai avuto belle esperienze con hd ssd parlando di affidabilità. Certo, senza dubbio puoi contare sulle prestazioni superiori ma per la delicatezza dei dati che tratti (pur essendo backuppati) ti consiglierei si un raid1 ma con 2hdd meccanici, magari dei Re della wd o comunque qualcosa testato 24/7

Ciao!

[khael]

Grazie per la risposta!
Nemmeno comprando degli slc?
Ho provato con un ssd e il database lavorando su disco ho avuto un grande boost prestazionale!

[khael]

upp
gli slc ho visto che sono proprio fuori dal mondo come costi;
per il trim centos dalla 6 mi sembra di aver capito che lo supporta utilizzando tuttavia ext4!
Provo a chiedere in area linux!

[khael]

Upp

[khael]

Uppete

[eaman]

Vedo SSD montati sui server da un paio di anni quindi suppongo che siano relativamente stabili.
Per altro se il tuo DB è di 15g potresti anche pensare di farlo girare in RAM (magari con qualche ridondanza o post-write tipo redis) o cacharlo ferocemente.

Oppure se sei poco tranquillo parti con un RAID SSD+HD, potresti giocare con i parametri write back / trought / mostly.

- http://tansi.info/hybrid/
- http://www.spinics.net/lists/raid/msg28785.html

[khael]

Ramdisk lo escluderei...
Cosa intendi raid SSD + HD?
Ora leggo i link

[eaman]

Intendo un raid mirror con un SSD e un hd meccanico.
Che ha sicuramente senso nello scenario di fail totale dell'SSD, e lo avrebbe anche fin tanto che ci sia un checksum dei dati nel caso di corruzione dei dati scritti su ssd.

Poi per lettura e scrittura si da preferenza all'SSD per goderne delle prestazioni.
...una volta leggevo di un tizio che in questo modo faceva un raid mirror con una RAMDISK cosi' se il sistema saltava aveva una copia del db su disco, che per altro si riallineava automaticamete con la rmadisk per il riavvio (figata!).

Se hai un po' di tempo fai una prova a far girare un DB in RAM e guarda come va'

[pabloski]

Peccato che non convenga più per questioni di costi, altrimenti avresti potuto installare un ssd-ram.

Uno schedone con 32-64 giga di ram e batteria tampone e passa la paura

Comunque la soluzione di eaman è la più appropriata. Purtroppo ( nonostante le vestali dicono che non è vero ) gli ssd non hanno l'affidabilità degli hard disk meccanici.

Quindi caching feroce e un disco meccanico con i dati sempre allineati.

Alla fine gli ssd si danneggiano quando si scrive e riscrive molte volte. Quindi il caching può ridurre enormemente le riscritture ( in quanto le sovrascritture avvengono spesso in ram ).

[khael]

il ramdisk lo escludo; dovrei dotare il server di 32gb!
ssd+hd sarebbe la cosa migliore, ma non posso fare raid1 (tanto vale prendere 2hd meccanici).
Ma come funziona?
2 ssd in raid1 e l'hd meccanico che fa la copia del backup ogni 10 minuti (ad esempio)?

[marco.r]

Ho letto da piu' parti che mettere un DB su SSD e' un modo molto pratico per "consumare" in fretta il disco. Suppongo sia dovuto a come i DB solitamente gestiscono il flush dei dati. Comunque non ho esperienza diretta a riguardo, per cui prendi l'affermazione cum grano salis.

Un'alternativa che potresti provare e' quella di usare l'SSD come cache per il classico piatto rotante. In linux ci sono due alternative, una e' bcache (http://bcache.evilpiepirate.org/), l'altra flashcache (https://github.com/facebook/flashcache).
Anche in questo caso si tratta di cose che non ho (ancora) provato. Comunque flashcache e' usata da facebook per i loro db MySQL.
In questi due casi anche l'eventuale dipartita del disco SSD non dovrebbe compromettere l'integrita' dei dati.

[khael]

si sapevo anche io della morte prematura; eventualmente posso pensare ad un cambio dei dischi piu' ravvicinato.
Il database comunque è composto da tanti semplici file di testo!
Per cui le scritture che fa nel disco sono piuttosto limitate; è un programma di contabilità per cui gli input sono quelli che 10 persone possono dare.
Il boost si ha in fase di avvio programma (che gira in remoto) e consultazione.
Il vantaggio più grande si ha in fase di elaborazione dati!
Per questo ho pensato agli ssd...
Alla fine non è una DB come ad esempio un forum in mysql in cui ci sono migliaia di scritture al secondo.

[marco.r]

puoi fare una stima grossolana di quanto ti puo' durare l'ssd.

Controlli quante scritture fai in un giorno sul disco.
Ad esempio con procinfo.

Quindi ti calcoli quante scritture puoi aspettarti da un'ssd.
Ad esempio da un'ssd da 60 GB che preveda 15.000 scritture per blocco ti puoi aspettare 60.000 (supponendo blocchi da 1MB) * 15.000 = 957 milioni di scritture.

dividi la cifra appena calcolata per le scritture al giorno e avra' una stima per difetto della vita del disco.
(per difetto perche' considero come ogni singola scrittura come riscrittura di un blocco, ma non sono sicuro che la cosa corrisponda).
Ad esempio se fai un milione di scritture al giorno ti durera' un po' piu' di tre anni (considerando un uso prevalentemente 5/7).

Ci sarebbe da tenere anche in considerazione il fatto che con il wear leveling una scrittura potrebbe diventare due scritture (il disco deve spostare dei blocchi) pero' con il trim e se il disco e' parecchio piu' capiente dello spazio utilizzato, non dovrebbe occorrere di frenquente in realta'.

Infine, tieni presente che raddoppiando la dimensione del disco (60 -> 120 ad esempio) a parita' di altri parametri ti raddoppia circa la vita attesa.

[khael]

Grazie per le risposte; si pensavo di prendere due M4 da 128gb; poi farò impostare dall assistenza la copia del raid ogni tot minuti sull'hd meccanico!
grazie ancora!

[eaman]

Se hai paura che l'SSD si scassi o si 'consumi' in fretta metterne due in raid mirror non mi semba una buona strategia: raddoppi il problema.
Piuttosto se ne vuoi comprare due, ripeto,
SSD + hd meccanico in raid (+ SSD come spare disk)

Ovviamente il raid lo fai software tra SSD e una partizione / lv dei dischi meccanici.

In oltre se come dici fai storaggio di file di testo consider la possibilita' di comprimerli: comp e decomp viene fatta praticamente in tempo reale dalle cpu moderne e di fatto se hai un fattore di compressione 3/1 aumenti l'I/O del DB dello stesso fattore.
(E non sto a dire che si fa anche con RAM )

Good luck

BTW:
- http://memcached.org/
- http://redis.io/
- http://en.wikipedia.org/wiki/Database_caching

[khael]

beh no ovviamente il raid 1 è solamente per prevenire il fault di un ssd!
Cioe' non per prevenire il consumo precoce;

[khael]

um sono in alto mare :/
allora abbiate pazienza!
Dunque il server ha soltanto 2gb di ram (usate al 95%) già ho acquistato 8gb ddr3 ecc samsung.
Poi ho analizzato le scritture e dunque:
il server è on da 40 giorni e queste sono le statistiche ( /proc/diskstats)

8 0 sda 2573879 261361 129718670 26006692 3365411 4998023 67031090 42418737 0 8349330 68475432
8 1 sda1 219 1039 2532 1192 5 0 10 2 0 1070 1193
8 2 sda2 2573640 260307 129715858 26005414 3365406 4998023 67031080 42418735 0 8348316 68474189
253 0 dm-0 2833811 0 129714578 27913591 8378867 0 67030936 166719820 0 8350088 194636547
253 1 dm-1 112 0 896 792 18 0 144 2 0 80 794

Analizzando i dati:

129.715.858 sector read
67.031.080 sector write

Non ho la più pallida idea di quanto sia un settore, ma presupponendo che esso sia da 512byte (0,5kb)

62gb lettura
32gb scrittura

Quindi dividendo per 40 dovrei avere:

1,5gb letture al giorno, 1gb scritture al giorno

Se ad esempio utilizzo 2 m4 in raid1 da 128gb, leggendo i datasheet ho:

Drive endurance: 72TB=40GB per day for 5 years

Dovrei essere tranquillo no?
grazie

[khael]

ah una cosa, vedendo il campo 9 a 0 (erano al lavoro) che sono gli I/O in uso, immagino che il db lavori in ram....possibile?
Cosi' spiegherei anche l'alto utilizzo di ram!
Grazie
Simone

[eaman]

Ben questo era quello che intendevo con 'cacharlo ferocemente' all'inizio del thread: se hai abbastanza RAM e i dati non cambiano il kernel li pesca dalla RAM.
E si può regolare via proc anche la frequenza delle scritture.
Non c'e' niente di meglio della RAM per un DB, e non è mai troppa.