Newsgroup: it.comp.os.linux.sys
Titolo: Storage VPS - RAID - Prestazioni I/O

Ciao,
non mi � chiara una questione tecnica che riguarda la velocit� di 
scrittura su disco.
Da quanto leggo, a livello Raid, sarebbero due i fattori che 
incrementano la velocit� di scrittura su disco:
la cache del controller raid ed il tipo di raid.
 
Volendo avere buone prestazioni I/O per uno "storage" di macchine 
virtuali, oltre al collegamento in Fibre Channel o porta/e 10G,
chi vende Hardware consiglia macchine in Raid6 (e concordo a livello di 
sicurezza) .. ma mi chiedo, tecnicamente come fanno questi storage ad 
avere per es. 1.000MB/s utilizzando un raid5 che in teoria degrada
la velocit� di scrittura su disco.
es: 
http://www.qnap.com/it/index.php?lang=it&sn=492&c=306&sc=752&t=2334&n=10243
 
 
Capisco il discorso della cache del controller, ma, mi chiedo,
creando un file con dd dopo x secondi finisco la cache .. e a quel punto ?
 
Grazie
 
-- Yena --
 

Parlo da semi-ignorante: avere un RAID5 con 24 dischi anzich� 3 fa' 
balzare parecchio le prestazioni.
Poi credo che i benchmark che propongono i vari vendor sono fatti in 
condizioni ideali o teoriche (in pratica marketing - credo)

 creando un file con dd dopo x secondi finisco la cache .. e a quel punto ?
 
Per prima cosa devi pensare che mentre scrivi in cache la cache viene
svuotata su disco, quindi 
p.es
. con 1GB di cache puoi riuscire a fare
caching di uno stream full-speed di 4/5GB... basta che per ogni GB
scritto dal server in cache, il controller riesca a spararne su disco i 3/4.
 
Poi 1000MB/s vuol dire 8gbs che ï¿œ la velocitï¿œ nominale dell'interfaccia
FC8, quindi non ï¿œ che sia chissï¿œ che mostruositï¿œ. Per raggiungere quel
throughput con un raid 6, in lettura sequenziale bastano 6 dischi da
300GB/15krpm. Per raggiungerli in scrittura sequenziale dovresti farcela
con una decina di dischi (anche se in questo caso conta molto il
controller e sei abbastanza al limite). Con storage di fascia medio alta
e su infrastrutture di virtualizzazione abbastanza importanti, capita
anche di saturare tutti i canali FC8 degli storage, in genere 4 o 8 in
base allo storage scelto.
 
Se poi ti trovi realmente con la cache esaurita allora scriverai
direttamente sui dischi, quindi aumentano le latenze delle operazioni di
IO, ma puoi sempre contare su dischi che hanno prestazioni
ragguardevoli. In questo caso conta naturalmente tantissimo come hai
strutturato lo storage. Per esempio da un cliente che aveva problemi
quando si copiavano file piï¿œ grossi di 15GB, solo aggiungendo 3 dischi e
riorganizzando lo storage in 4 raid 5 di 5 dischi ciascuno (invece di 3
raid5 di 6+6+5) ha eliminato il collo di bottiglia. Il rallentamento lo
ha ugualmente quando supera i 20GB (ed ï¿œ un 30% in piï¿œ), ma mentre prima
la latenza delle scritture nel momento di crisi schizzava a oltre 100ms,
adesso si ferma a 10-15ms, un valore accettabile.
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left


In teoria si, in pratica pu� essere non del tutto vero.
A parte i vari effetti collaterali legati al tempo di rebuild, diversi 
storage di fascia enterprise decidono per te quale sia il migliore 
layout per un raid5 (o al limite ti fanno scegliere fra al massimo 2 
configurazioni possibili).
L'aumento degli IOPS lo ottieni generalmente in altro modo, ad esempio 
facendo striping su N strutture raid5.

 adesso si ferma a 10-15ms, un valore accettabile.
 
Ma se fai addirittura stripe di Raid5, se ti si rompono 2 dischi 
contemporaneamente, cosa fai ?
 
-- Yena --
 

 contemporaneamente, cosa fai ?
 
In genere non c'ï¿œ necessitï¿œ di fare stripe di raid5, semplicemente
distribuisci i carichi in modo oculato tra piï¿œ raid5.
 
Detto questo su uno storage non puoi prescindere dalla presenza di un
hot spare ogni circa 10-20 dischi circa e poi esiste Santo Backup che ti
aiuta nei momenti di difficoltï¿œ.
Se il sistema ï¿œ cosï¿œ critico che la rottura contemporanea di due dischi
non ï¿œ tollerabile (ï¿œ un evento MOLTO raro se gli allarmi sono impostati
correttamente e se ci sono gli hot spare), probabilmente vale la pena
usare due storage in replica su due siti diversi. Il doppio della
sicurezza al doppio del prezzo.
 
Se nemmeno questo ï¿œ proponibile allora meglio puntare su storage con
firmware piï¿œ furbi. Io conosco abbastanza bene IBM, e l'ultimo firmware
del DS3524 offre una funzionalitï¿œ (DDP) che ï¿œ veramente molto
interessante per il tipo di scenario che hai illustrato, specie con
l'aumentare dei dischi (una roba simile l'ha anche il V7000).
 
http://ibmdsstorage.com/component/content/article/46-solutions/143-the-latest-features-for-the-ds3500-a-dcs3700.html
 
 
L'altro lato della medaglia ï¿œ che il 3524 ha solo 2GB di cache che IMHO
oggigiorno sono pochini...


Il 12/09/2012 22:05, THe_ZiPMaN ha scritto:
[Stracut]
 
Mi trovi allineato su tutta la linea e non avrei saputo esprimere meglio 
gli stessi concetti.
 
 
Aggiungo solo che qualche tempo fa feci degli esperimenti sui "nuovi" 
RAID che mirano ad avvicinare l'affidabilitï¿œ del RAID6 alle performance 
del RAID5. Mi riferisco al RAID5E e al RAID5EE. Soprattutto nel secondo 
caso rimasi particolarmente soddisfatto delle performance introdotte.
 
Ad ogni modo un hotspare ogni 12 dischi io preferisco sempre mettercelo, 
a prescindere.
 
Non sottovaluterei il problema del guasto multiplo: ï¿œ sempre in agguato. 
Normalmente un evento di rottura di 2 dischi contemporanei ï¿œ una 
fatalitï¿œ che invita alla riflessione circa l'organizzazione di un 
viaggio con destinazione Lourdes. Quando invece si spegne e si 
riaccende, per motivi manutentivi o qualsiasi altro motivo, uno storage 
con sul groppone 10 anni di funzionamento puï¿œ presentare *facilmente* 
questo problema.
IBM stessa consiglia due cose che fanno riflettere:
- superati i 12 dischi, si consiglia di acquistare gli stessi da diverse 
partite produttive
- su storage particolarmente datati, fare sempre un backup *accurato* 
prima di procedere allo spegnimento dei dischi
 
 
Un'altra tecnologia da non sottovalutare ï¿œ quella in grado di 
organizzare i dischi ed i dati in base alla tipologia dei dishi. Mi spiego:
 
Poniamo il caso di avere 12 dischi SSD, 24 dischi SAS e 48 dischi SATA.
In questo caso lo storage decide autonomamente di spostare i dati piï¿œ 
utilizzati sui dischi SSD, per poi spostarli nel "purgatorio" dei SAS ed 
infine tenerli in "store" sui SATA.
E' una tecnologia anch'essa nuova, ma molto molto promettente (e meno 
onerosa, il risparmio ï¿œ considerevole e le performance sono "adattive").

 accede ai dischi.
 
Perdona l'ignoranza ma cosa intendi per
"allineare le richieste del S.O. che
accede ai dischi." ?
 
Grazie mille !
 
-- Yena --

 accede ai dischi." ?
 
Vuol dire che se il tuo S.O. accede ai dischi a blocchi di 4K (come
avviene normalmente) l'inizio del filesystem deve essere allineato a
multipli di 4K dall'inizio del disco. Questa non ï¿œ una condizione
automatica ma spesso va ricercata usando opportunamente le varie funzioni.
P.es. le partizioni compatibili con MSDOS devono avere l'allineamento al
cilindro, ma essendo il cilindro composto da un numero dispari di tracce
ci si ritrova con un disallineamento delle partizioni.
 
Dal momento che le letture del disco avvengono oggigiorno a blocchi di
4k, se i 4K del S.O sono disallineati rispetto ai 4K del disco ci si
ritrova nella situazione in cui la lettura di un blocco dal S.O.
comporta due letture sul disco.
 
Stesso discorso per LVM.


 oggigiorno sono pochini...
 
Zip, ma la cache del controller, viene usata solo in letture/scritture con un RAID attivo o anche in JBOD?
 
mi spiego: un server senza controller raid ma 16GB di ram sarà più o meno performante (o magari uguale) nella scrittura/lettura sui dischi singoli rispetto ad un server con stessa ram e controller raid hardware da 2GB di cache e dischi configurati in JBOD?

 Zip, ma la cache del controller, viene usata solo in letture/scritture con un RAID attivo o anche in JBOD?
 
Sui sistemi che ho usato io ï¿œ sempre attiva. Ma non conosco tutti i
controller.


 controller.
 
Quindi a parità di server e nessun tipo di raid configurato, un server con controller sarà sempre più performante di un server senza controller anche sulle scritture sui singoli dischi?