Newsgroup: it.comp.os.linux.sys
Titolo: [OT] Storage per esperti

Buongiorno a tutti,
premesso che sto cercando libri -> seri <- che trattino l'argomento 
"Storage" in maniera completa ed esaustiva, ma non trovo nulla (quindi 
ogni suggerimento è bene accetto), alla fine ho trovato davvero poco e, 
paradossalmente, grazie proprio al buon vecchio Fulvio, ho avuto un 
quadro complessivo dell'argomento oltre le supposizioni fantascientifiche.
 
 
Ancora oggi, tuttavia, ho dei DS3200 dalle performance orrende e non mi 
capacito, continuo a dirmi che qualcosa potrebbe essere gestita meglio.
 
 
Vorrei porre ai super-esperti in materia qualche piccolo quesito:
 
1) Siamo tutti d'accordo che:
 
le performance dei dischi indicativamente sono
- disco SATA: 100IOPS
- disco SAS10k: 160IOPS
- disco SAS15k: 190IOPS
- disco SSD: 2000IOPS
 
le performance del raid sono indicativamente
- RAID0: somma di tutti gli IOPS dei dischi
- RAID1: read somma, write somma/2
- RAID5: read somma -1, write somma/4
- RAID6: read somma -2, write somma/6
 
 
2) la cache in lettura ed scrittura è sempre cosa buona e giusta (se si 
ha un controller con batteria)?
 
 
3) all'aumentare del numero dei dischi può non corrispondere un aumento 
delle performance?
 
Faccio un esempio: avendo 12 dischi e volendo strutturare un RAID5, 
l'ideale (a livello di performance) è metterne 9 oppure 12? Perchè?
 
 
4) che impatto hanno i blocchi? se VMFS5 ha i blocchi a 1M, è opportuno 
che lo storage abbia lo stesso valore al posto dei classici 128 o 256K?
 
 
5) uno storage collegato in SAS su singolo controller comunque non 
dovrebbe avere come collo di bottiglia questo elemento, ma sempre la 
parte dischi (salvo non siano SSD), giusto?
 
 
 
 
Virtualizzazione:
 
6) possiamo dire che uno storage è in sofferenza se l'average del write 
o del read supera i 30ms? Ho trovato questa soglia quasi un limite 
"inaccettabile" come usabilità.
 
 
7) Ormai trovo che un mirror di 2 dischi SATA, seppur hardware e di buon 
livello, non sia in grado nemmeno di gestire 1 VM MS... però mi sfugge 
una cosa: se metto 1 OS direttamente su un mirror, è una scheggia. se 
metto lo stesso OS da solo sotto VMware, è un disastro incredibile. 
Comprendo che ci sia uno strato intermedio, ma è gravemente  degradata 
la performance, perchè così tanto? E quando dico tanta intendo DAVVERO 
tanta differenza.
 
 
 
Grazie a chi vorrà partecipare a questa discussione!

 delle performance?
 
  Intervengo rapidamente su questo perché poco tempo fa mi era andato
l'occhio su questa presentazione:
 
http://events.linuxfoundation.org/sites/events/files/slides/Vault%20-%20scsi-mq%20v2.pdf
 
 
«Increasing SCSI LLD Driver Performance by
Using the SCSI Multiqueue Approach»
 
  In particolare si veda il grafico a pag. 15, dove si confrontano le
prestazioni su un kernel 3.19 per valori diversi di canali RDMA (Remote
Direct Memory Access) misurate in termini di IOPS contro numero di LUN.
 
  Il documento è focalizzato sull'uso dello stack SCSI in un sistema
NUMA, ma credo che numerose considerazioni sulla scalabilità della queue
SCSI standard Linux al crescere delle LUN e sulla latenza della queue
standard contro quella MQ (Multi Queue) si applichino anche in contesti
locali (non ho fatto misure).
 
  Tieni pure conto che si sa che su un sistema RAID il filesystem EXT4 è
da evitare, funziona molto male insieme allo stack SCSI Linux per quanto
riguarda le prestazioni, Theodore Ts'o stesso raccomanda di usare XFS
piuttosto.
 
 
  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.

Io ho trovato diverse cose interessanti con i redbook di IBM (visto che 
hai dei DS3200). Cerca quello del tuo storage, di solito ci sono dei 
suggerimenti sulla parte di virtualizzazione.
 
PS: cosa intendi per "performance orrende"? Io ho tra le mani 
sicuramente un 3200, un paio di 3400 ed un 3500 (per rimanere nella 
fascia bassa), tutti interfaccia FC e sopra ci girano diverse VM.
E oltretutto su diversi non ho nemmeno fatto grossi upgrade di firmware 
(finchè va lascialo andare :-)
Ciao
 
-- 
Luca
http://www.civinini.net
 
 
"Unix is simple. It just takes a genius to understand its simplicity." - 
Dennis Ritchie

 fascia bassa), tutti interfaccia FC e sopra ci girano diverse VM.
 
Sui DS3500 non ho problemi, ne ho un paio in giro anch'io, ma su i 
DS3200 SAS mono controller è terribile. Ho letto in giro che è 
necessario disabilitare il mirroring perchè lui cerca continuamente il 
controller secondario, ed in effetti la situazione è migliorata, ma 
rimane comunque insufficiente. Questo controller ha 12 dischi SATA, mi 
rendo conto che non siano il massimo delle performance, ma ho provato 
ogni tipo di RAID senza avere risultati soddisfacenti. Bastano 3-4 
macchine a riposo per avere latenze i 25ms di average in read. Anche con 
RAID folli (giusto per provare) tipo R0 di tutti i 12 dischi.
 
Ho fatto dei test tra 20 storage diversi, dal server con un mirror SSD 
al nas da 4 soldi in NFS, con dentro un paio di DS3500 e DS3200. Se 
volete vi posto i risultati, ma sono assolutamente incoerenti.
 
 
Ad ogni modo, la mia discussione voleva affrontare l'agomento più 
genericamente possibile, grazie del consiglio sul DS3200 che sicuramente 
seguirò in mattinata, ma sto cercando di fissare dei concetti base, 
generici, da cui partire su ogni storage.
 

 tanta differenza.
 
no, devi cercare altrove secondo me


 no, devi cercare altrove secondo me
 
ho praticamente 4 server con un mirror sata, vendor diversi e raid 
diversi, tutti in questa situazione. proprio non comprendo perchè le 
performance crollino così drasticamente su vmware seppur monomacchina 
(adotto spesso questa architettura per poi avere backup agevoli e 
"click-to-restore").
 
 
Grazie della risposta.

 
 
Hai provato a raccogliere un pò di metriche? Le più interessanti sono
sicuramente gli IOPS e la QLEN; di default vmware setta una queue depth
troppo aggressiva anche per gli storage di fascia enterprise (mi pare
che nelle ultime release sia addirittura a 64). Su dischi SATA, che
probabilmente non supportano nemmeno la TCQ, tale valore non va bene.
Ad ogni modo le informazioni di cui hai bisogno sono tutte a tua
disposizione, devi solo andare a prenderle e capirle (anche la
controller dello storage metterà sicuramente a disposizione
un'interfaccia di performance analysis).
 

 un'interfaccia di performance analysis).
 
approfondisco subito, per ora il valore più indicativo su cui ho 
osservato importanti variazioni sul datastore è la latenza espressa in ms.
 

 quadro generico dell'aspetto storage. Nel suo complesso.
 
Per ottimizzare le performance devi capire in quale componente sei in
crisi (o che comunque vorresti migliorare); ti faccio un paio di esempi,
stupidi se vuoi, ma giusto per farti capire che come l'hai posta te la
domanda non ha risposta.
 
Esempio 1: hai un'applicazione che necessita di un response time <3ms e
il tuo storage ha N dischi SAS a 10K, cosa devi fare? L'unico modo è
introdurre una discreta quantità di dischi SSD (in modalità dynamic
tiering o auto-tiering ad esempio), con i SAS a 10K non ci arriverai mai.
 
Esempio 2: sei carente in termini di IOPS, cosa devi fare? Prima di
tutto devi accertarti che il collo di bottiglia siano davvero le
meccaniche e non altre componenti (ad esempio le controller o i canali
di back-end); soprattutto sugli storage midrange la scalabilità dei
dischi è sempre MOOOLTO superiore rispetto alle performance della
controller (ergo, arriverai ad un punto in cui hai le controller a tappo
con l'usage rate dei dischi relativamente basso). Qualora controller e
back-end fossero apposto, puoi procedere all'aggiunta di meccaniche per
aumentare gli iops.
 
Esempio 3: devi progettare un ambiente "general purpose" con
performances "standard" per applicazioni di vario genere (server
virtualization, posta, file server, database...). In questa situazione,
in generale, il raid 5 è la migliore scelta; io generalmente, se il
vendor non dà indicazioni differenti, uso o i 6+1 o i 7+1 o gli 8+1 con
dischi SAS da 10K o 15K entro i 900GB, con tagli più grandi l'8+1 non lo
faccio (ad esempio coi SAS 10K rpm a 1,2T). Con i sata o i nl-sas a 7.2K
rpm non faccio proprio il raid 5.
 
HINT: una metrica fondamentale nella progettazione di soluzioni storage
e che spesso non viene cacata di striscio è l'IOPS/SIZE.
Un disco SAS a 300GB a 1Ok rpm fa gli stessi iops di un disco SAS a
1200GB a 10k rpm (non è del tutto vero ma la differenza è assolutamente
trascurabile); è però immediato rendersi conto che statisticamente le
richieste di io su 1200GB saranno circa 4 volte quelle che arrivano su 300GB


 
questa è una considerazione obiettivamente fantastica ed hai ragione da 
vendere. Però va contestualizzata al numero di dischi massimi che puoi 
usare sulla SAN, se sei vincolato, aimè devi aumentare certamente la 
dimensione dei dischi singoli. Ma è indubbiamente un aspetto che non 
avevo considerato e che ti ringrazio di aver portato alla mia attenzione.
 
Tuttavia mi sfugge una cosa: poniamo il caso di avere sempre i soliti 12 
dischi SAS10k (ma è solo un esempio di una classica SAN entry level), mi 
sembra di aver capito che tu avresti fatto (per un utilizzo generico) 2 
R5 da 6 e da 5 con 1 hotspare. Non avresti fatto 11R5+1HS per una 
questione di sicurezza e ridondanza, giusto? Non per performance. Perchè 
alla fine tra dividere il carico su due array dimezzando gli IOPS e 
poggiarlo tutto su uno raddoppiando gli IOPS, mi sembra che siamo lì. O 
mi sfugge qualcosa?
 
 
 
Altra considerazione:
IOPS = (Mbit / BLOCCO) * 1024
ok, ma quel blocco di chi è? Perchè VMFS fa 1M a blocco, e mi esce un 
calcolo assurdo. Lo storage mi ha fatto blocchi da 256K, normalmente il 
guestos fa blocchi da 4K. Di che minch*a di blocco parliamo?? :) Sto 
fumando... e di venerdì sera non è cosa inusuale :D
 

 fumando... e di venerdì sera non è cosa inusuale :D
 
1MB è la dimensione del blocco sul VMFS. Questa è la dimensione con cui 
normalmente fa I/O VMware quando opera sui files dei datastore.
I guest in genere hanno blocchi di 4k ma si possono configurare più 
grandi o più piccoli; questa è la dimensione con cui avvengono gli I/O 
delle VM..
Il blocco dello storage invece è la dimensione della stripe del raid. 
Questa dovrebbe essere scelta in modo tale che la maggior parte delle 
operazioni di I/O siano distribuite in modo equo su tutti i dischi. 
Considera che (al netto delle ottimizzazioni sempre presenti) la 
dimensione della stripe è la dimensione con cui viene fatto l'I/O sulla 
meccanica quando viene ricalcolata la parità e non sempre si può scegliere.
Oggigiorno IMHO il miglior compromesso si ha con stripe di 128k che 
consentono di distribuire equamente un I/O di 1MB in tutti i raid allineati.
Ma come detto tutto dipende da cosa gira sui sistemi... Se per esempio 
fai 20 I/O piccoli da 4k che puntano tutti negli stessi 128k questi 
insisteranno tutti sul medesimo disco e quindi avrai latenze più elevate 
rispetto a stripe da 32k. Idem se fai degli I/O molto grossi, per 
esempio da 16MB ciascuno che su un raid 5 da 5 dischi si tradurranno in 
32 I/O per ciascun disco e quindi ancora latenze elevate rispetto per 
esempio a stripe da 512k.
 
Poi al giorno d'oggi è comunque difficilissimo stabilire la giusta 
configurazione perché ci sono troppe ottimizzazioni che intervengono a 
cambiare le carte in tavola. Normalmente il dimensionamento lo fai al 
netto delle strategie dei vari vendor (nel worst case) e il risultato è 
che le performance sono praticamente sempre migliori delle aspettative. 
Questo salvo poi droppare drasticamente nel momento in cui superi il 
punto di rottura in cui le ottimizzazioni non hanno più alcun effetto. :)
 
 
-- 
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

 
 
Attenzione a due aspetti: il fatto che il block size di vmfs sia 1M non
vuol dire che faccia i/o con blocchi da 1MB (ci mancherebbe altro).
Non sono un esperto di vmware, ma direi che 1M rappresenta l'unità
minima di allocazione spazio ad un vmdk.
Secondo aspetto: quando gli storage vendor parlano di iops generalmente
lo misurano con blocchi da 512B (ossia l'unità minima allocabile in LBA).
 

 modo corretto in base alle VM che gireranno.
 
Verissimo se parliamo di server virtualization; ma ti assicuro che anche
questa non è una verità assoluta.
Molti storage hanno algoritmi di "sequential detection" che bypassano
completamente la cache per streaming di operazioni sequenziali.
Questo per dire che quando lo storage "va lento" non esiste la medicina
universale.
 
 

 minima di allocazione spazio ad un vmdk.
 
Gli I/O di VMware arrivano fino a 32MB ma il minimo mi pare di ricordare 
che sia il settore.


 universale.
 
Concordo al 1000%...


 Grazie a chi vorrà partecipare a questa discussione!
 
innanzitutto rinnovo il ringraziamento per aver partecipato alla 
discussione, estremamente specialistica ma altrettando interessante.
 
Onde evitare di intasare ulteriormente questo ng di un altro argomento 
affino al discorso storage (ma più vmware oriented), in 
it.comp.virtualizzazione ho aperto una 3ad di nome "Storage lowcost 
hiperf per vmware", con alcune considerazioni su una proposta lowcost 
per uno storage di 48Tb con cache su SSD.