Discussioni sul sistema operativo Linux
 

[OT] Storage per esperti

writethem 30 Giu 2015 11:59
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 *****ware 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 interme*****, ma è gravemente degradata
la performance, perchè così tanto? E quando dico tanta intendo DAVVERO
tanta differenza.



Grazie a chi vorrà partecipare a questa discussione!
Alessandro Selli 30 Giu 2015 12:48
Il 30/06/2015 11:59, writethem ha scritto:

[...]

> 3) all'aumentare del numero dei dischi può non corrispondere un aumento
> 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 c*****i 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.
LC 30 Giu 2015 21:13
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
writethem 1 Lug 2015 06:53
> 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.

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.
devx 1 Lug 2015 10:02
On 06/30/2015 11:59 AM, writethem wrote:
>
> le performance dei dischi indicativamente sono
> - disco SATA: 100IOPS
> - disco SAS10k: 160IOPS
> - disco SAS15k: 190IOPS
> - disco SSD: 2000IOPS

troppo pochi gli iops degli ssd; troppi gli iops dei sata


>
> 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

perchè togli quel 1 o 2 dai raid 5 o 6? Il fatto che ci sia un disco (o
due) di parità non toglie gli iops potenziali di quel disco, dato che la
parità è distribuita su tutte le meccaniche

>
>
> 2) la cache in lettura ed scrittura è sempre cosa buona e giusta (se si
> ha un controller con batteria)?

gli storage di un certo livello sanno da soli quando non usare la cache
(generalmente a fronte di stream di letture/scritture sequenziali); cmq
si in linea generale si

>
>
> 3) all'aumentare del numero dei dischi può non corrispondere un aumento
> delle performance?

ovviamente; le motivazioni possono essere molteplici: i link verso il
backend saturi, la cache insufficiente, le controller a tappo....

>
> Faccio un esempio: avendo 12 dischi e volendo strutturare un RAID5,
> l'ideale (a livello di performance) è metterne 9 oppure 12? Perchè?

diciamo che i numeri da te indicati sono entrambi papabili; gli storage
di un certo livello indicano, a seconda del raid, quale sia il miglior
layout di utilizzare (in alcuni proprio non puoi scegliere)

>
>
> 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?

anche questa è una scelta che gli storage enteprise non sempre ti
consentono di fare (nel senso che utilizzano una block size testata in
fabbrica e che garantisce le migliori performance); inoltre non mi
risulta che l'io fatto da vmware sia allineato al block size dal vmfs ma
al block size del guest.
quindi il consiglio è seguire quanto consiglia lo storage vendor per
utilizzare le lun in ambito vmware


>
>
> 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?

no in generale no; dipende quanti dischi vi sono attaccati dietro

>
>
>
>
> 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à.

si, 30ms se non ricordo male è anche la soglia che imposta vmware sul
datastore quando abiliti il SIOC

>
>
> 7) Ormai trovo che un mirror di 2 dischi SATA, seppur *****ware 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 interme*****, ma è gravemente degradata
> la performance, perchè così tanto? E quando dico tanta intendo DAVVERO
> tanta differenza.

no, devi cercare altrove secondo me


>
>
>
> Grazie a chi vorrà partecipare a questa discussione!
writethem 1 Lug 2015 10:57
>> le performance dei dischi indicativamente sono
>> - disco SATA: 100IOPS
>> - disco SAS10k: 160IOPS
>> - disco SAS15k: 190IOPS
>> - disco SSD: 2000IOPS
>
> troppo pochi gli iops degli ssd; troppi gli iops dei sata

in effetti https://en.wikipedia.org/wiki/IOPS


>> 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
>
> perchè togli quel 1 o 2 dai raid 5 o 6? Il fatto che ci sia un disco (o
> due) di parità non toglie gli iops potenziali di quel disco, dato che la
> parità è distribuita su tutte le meccaniche
>

ok, ricordavo qualcosa del genere, evidentemente mi sbagliavo


>> Faccio un esempio: avendo 12 dischi e volendo strutturare un RAID5,
>> l'ideale (a livello di performance) è metterne 9 oppure 12? Perchè?
>
> diciamo che i numeri da te indicati sono entrambi papabili; gli storage
> di un certo livello indicano, a seconda del raid, quale sia il miglior
> layout di utilizzare (in alcuni proprio non puoi scegliere)

Però su un'unità da 12 dischi, è preferibile, ad esempio, utilizzare un
numero specifico o un moltiplicatore specifico? Non mi è chiara la
logica pratica.


>> 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?
>
> anche questa è una scelta che gli storage enteprise non sempre ti
> consentono di fare (nel senso che utilizzano una block size testata in
> fabbrica e che garantisce le migliori performance); inoltre non mi
> risulta che l'io fatto da vmware sia allineato al block size dal vmfs ma
> al block size del guest.
> quindi il consiglio è seguire quanto consiglia lo storage vendor per
> utilizzare le lun in ambito vmware

ok


>> 7) Ormai trovo che un mirror di 2 dischi SATA, seppur *****ware 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 interme*****, ma è gravemente degradata
>> la performance, perchè così tanto? E quando dico tanta intendo DAVVERO
>> tanta differenza.
>
> 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.
devx 1 Lug 2015 18:37
On 07/01/2015 10:57 AM, writethem wrote:
>
>>> Faccio un esempio: avendo 12 dischi e volendo strutturare un RAID5,
>>> l'ideale (a livello di performance) è metterne 9 oppure 12? Perchè?
>>
>> diciamo che i numeri da te indicati sono entrambi papabili; gli storage
>> di un certo livello indicano, a seconda del raid, quale sia il miglior
>> layout di utilizzare (in alcuni proprio non puoi scegliere)
>
> Però su un'unità da 12 dischi, è preferibile, ad esempio, utilizzare un
> numero specifico o un moltiplicatore specifico? Non mi è chiara la
> logica pratica.
>

La domanda è abbastanza "strana": il numero di meccaniche da inserire
sullo storage (e soprattutto layout e numerosità di raid) viene definito
in fase di progettazione della soluzione storage.
Da come la presenti sembra quasi che quei dischi "siano apparsi" per
caso all'interno del box e ora devi capire cosa farci.
Comunque, che dischi sono, cosa ci devi fare e che storage è? Fossero
dischi SAS a 10K rpm e tu volessi utilizzarli per la server
virtualization potresti pensare a 2 RAID5(5+1), a patto di avere in
macchina almeno un altro disco della stessa geometria come ******* spare.
Con le poche info che dai è difficile dare una risposta sensata....


>>> 7) Ormai trovo che un mirror di 2 dischi SATA, seppur *****ware 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 interme*****, ma è gravemente degradata
>>> la performance, perchè così tanto? E quando dico tanta intendo DAVVERO
>>> tanta differenza.
>>
>> 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").
>
>

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 *****ysis).
writethem 2 Lug 2015 07:44
>> Però su un'unità da 12 dischi, è preferibile, ad esempio, utilizzare un
>> numero specifico o un moltiplicatore specifico? Non mi è chiara la
>> logica pratica.
>>
>
> La domanda è abbastanza "strana": il numero di meccaniche da inserire
> sullo storage (e soprattutto layout e numerosità di raid) viene definito
> in fase di progettazione della soluzione storage.
> Da come la presenti sembra quasi che quei dischi "siano apparsi" per
> caso all'interno del box e ora devi capire cosa farci.
> Comunque, che dischi sono, cosa ci devi fare e che storage è? Fossero
> dischi SAS a 10K rpm e tu volessi utilizzarli per la server
> virtualization potresti pensare a 2 RAID5(5+1), a patto di avere in
> macchina almeno un altro disco della stessa geometria come ******* spare.
> Con le poche info che dai è difficile dare una risposta sensata....

diciamo che la mia domanda è più generica e si riferisce proprio a
quella fase di progettazione e ottimizzazione. Non parto da un'esigenza
specifica, ma cerco di capire cosa è meglio fare. Alla fine,
b*****izzando, lo storage non ha mille varianti, ma solo 2:
- ridondanza
- performance
a parità di ridondanza, vorrei capire come ottimizzare le performance.
Uscendo dal caso specifico dei miei DS3200 o di un DS3500 o di un R5
Adaptec o ServeRaid.

Non so se sono stato in grado di spiegare, ma vorrei approfondire un
quadro generico dell'aspetto storage. Nel suo complesso.


> 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 *****ysis).

approfondisco subito, per ora il valore più indicativo su cui ho
osservato importanti variazioni sul datastore è la latenza espressa in ms.
devx 3 Lug 2015 17:56
On 07/02/2015 07:44 AM, writethem wrote:
>
>
> diciamo che la mia domanda è più generica e si riferisce proprio a
> quella fase di progettazione e ottimizzazione. Non parto da un'esigenza
> specifica, ma cerco di capire cosa è meglio fare. Alla fine,
> b*****izzando, lo storage non ha mille varianti, ma solo 2:
> - ridondanza

e questa è facile

> - performance

questa lo è meno invece: performance è troppo generale; ci sono
situazioni in cui ti serve il throughuput, altre in cui ti servono gli
iops, altre ancora in cui ti serve il response time.
A seconda dell'esigenza alla quale devi rispondere, la fase di
progettazione sarà completamente diversa.
Vi sono casi in cui è facile dimostrare, ad esempio, che un raid 1+0 è
economicamente vantaggioso rispetto ad un raid 5

> a parità di ridondanza, vorrei capire come ottimizzare le performance.
> Uscendo dal caso specifico dei miei DS3200 o di un DS3500 o di un R5
> Adaptec o ServeRaid.
>
> Non so se sono stato in grado di spiegare, ma vorrei approfondire un
> 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 c*****i
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, ******* 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
writethem 3 Lug 2015 19:09
>> - performance
>
> questa lo è meno invece: performance è troppo generale; ci sono
> situazioni in cui ti serve il throughuput, altre in cui ti servono gli
> iops, altre ancora in cui ti serve il response time.

Ok perfetto. Diciamo che in un'architettura generica, maggiori sono gli
IOPS, maggiore è il troughput e minore è il tempo in cui i miei dati
rimangono in coda (off-cache), quindi salvo particolari indicazioni le
performance crescono insieme (dove per performance intendo tutto sommato
genericamente gli IOPS)


> Per ottimizzare le performance devi capire in quale componente sei in
> crisi (o che comunque vorresti migliorare);
[cut]
> 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 c*****i
> 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.

ottima riflessione, capirlo però è tutt'altro che semplice. Anche perchè
alla fine non ho trovato davvero dove rendermene conto in vmware o
interrogando la SAN. empiricamente, sempre su questo DS3200 che è
diventato il mio "master test" ho fatto un RAID0 di 12 dischi SATA ed ho
ottenuto un valore inferiore alla somma di tutti, quindi posso iniziare
a pensare che il controller regga un certo numero di operazioni e già in
questa b*****e configurazione inizi a entrare in sofferenza.


> Esempio 3: devi progettare un ambiente "general purpose" con
> performances "standard" per applicazioni di vario genere (server
> virtualization, posta, ******* 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
THe_ZiPMaN 3 Lug 2015 22:14
On 07/03/2015 07:09 PM, writethem wrote:
> 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?

Ci sono due motivi fondamentali. Il primo è la "sicurezza", perché le
probabilità di rottura del secondo disco quando hai un raid esteso sono
molto più elevate che con raid piccoli. Il secondo è per le performance.
Negli storage, specie quelli vecchi o di fascia bassa, un raid è gestito
da un solo controller per volta, quindi con un solo raid si ha un solo
controller che lavora e l'altro si gratta...

C'è da dire poi che se si vogliono fare le cose per bene sarebbe sempre
meglio fare dei raid allineati 2^n+p che per il raid 10 vuol dire 4, 8 o
16 dischi, per il raid 5 vuol dire 5 o 9 dischi e per il raid 6 vuol
dire 6 o 10 dischi. Questo perché l'I/O così sarà tendenzialmente
allineato e distribuito equamente tra tutti i dischi migliorando la
latenza delle operazioni (la cosa si complica, o si semplifica un po' se
si vuol essere ottimisti, con gli storage chunk based come HP 3PAR o
Huawei Oceanstor).

Altro discorso che invece non è stato considerato è la cache... questa
incide sulle performance in modo pesantissimo e andrebbe dimensionata in
modo corretto in base alle VM che gireranno. La cache deve essere
dimensionata in base allo spazio disco disponibile, al tipo di dischi e
al tipo di I/O fatto dalle VM. Oggigiorno meno di 8GB di cache possono
bastare solo in infrastrutture con meno di 20-30 VM oppure in
abbinamento a sistemi di gestione automatica del tiering o di cache
multilivello con gli SSD... altrimenti meglio pensare di averne almeno
16 o oltre se non si vuole essere fortemente penalizzati

> 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

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
devx 4 Lug 2015 14:33
On 07/03/2015 07:09 PM, writethem wrote:

> Ok perfetto. Diciamo che in un'architettura generica, maggiori sono gli
> IOPS, maggiore è il troughput e minore è il tempo in cui i miei dati
> rimangono in coda (off-cache), quindi salvo particolari indicazioni le
> performance crescono insieme (dove per performance intendo tutto sommato
> genericamente gli IOPS)

Mmmm....non è vera questa cosa. Dimensionare per gli iops è
assolutamente diverso che dimensionare per il throughput; un workload
tipicamente iops-oriented è quello che deriva da un db transazionale di
tipo oltp. Non è difficile trovare in realtà me*****-grandi dei database
business-critical che fanno oltre 20K iops con un throughput inferiore
ai 30MBs. Come rispondi a questa esigenza? Considerando gli iops/gb:
avrai comunque solo 2 possibilità, o dischi a 15K rpm o ssd.
Al contrario puoi avere applicazioni che fanno streaming sequenziale di
dati e necessitano di un throughput molto elevato, magari di un 1GBs, ma
le iops che generano sono molto basse; in questo caso le considerazioni
di fare sono altre, sicuramente la prima è di lasciar perdere gli ssd :-)


>
> ottima riflessione, capirlo però è tutt'altro che semplice. Anche perchè
> alla fine non ho trovato davvero dove rendermene conto in vmware o
> interrogando la SAN.

vmware non può saperlo; ci vuole lo strumento di performance monitoring
dello storage. Anni fa ho lavorato su DS5000 (mi pare) e mi ricordo che
aveva uno strumento che si chiamava "santricity" (o qualcosa di simile)
per il monitoring dello storage.
Purtroppo sugli storage mid-range questa parte è spesso carente.

> empiricamente, sempre su questo DS3200 che è
> diventato il mio "master test" ho fatto un RAID0 di 12 dischi SATA ed ho
> ottenuto un valore inferiore alla somma di tutti, quindi posso iniziare
> a pensare che il controller regga un certo numero di operazioni e già in
> questa b*****e configurazione inizi a entrare in sofferenza.

Dubito che tu possa mettere in difficoltà la controller con 12 dischi SATA.

> 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.

Questa è la tipica considerazione che fanno i clienti :-)
Purtroppo la progettazione di soluzioni storage non la puoi fare
soltanto tenendo in considerazione la componente capacitiva.

>
> 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?

Con 12 dischi io ne avrei richiesto 1 altro e avrei fatto 2 R5(5+1) + 1
HS ;-)
La dimensione del R5 influenza sia la probabilità del doppio fault (con
conseguente perdita di dati) che i tempi di rebuild.

Sinceramente, anche se non seguo ne progetto configurazioni così
piccole, mi posso rendere conto delle problematiche di budget quando si
presenta al business la necessità di investire in tecnologia storage;
sta di fatto però che i dati sono la cosa più importante che c'è e
quindi una soluzione storage adeguata alle necessità di business ed
affiancata da una soluzione di backup consona è imprescindibile.

>
>
>
> 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
>

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).
devx 4 Lug 2015 14:45
On 07/03/2015 10:14 PM, THe_ZiPMaN wrote:
> Ci sono due motivi fondamentali. Il primo è la "sicurezza", perché le
> probabilità di rottura del secondo disco quando hai un raid esteso sono
> molto più elevate che con raid piccoli. Il secondo è per le performance.
> Negli storage, specie quelli vecchi o di fascia bassa, un raid è gestito
> da un solo controller per volta, quindi con un solo raid si ha un solo
> controller che lavora e l'altro si gratta...

Fortunatamente questa cosa non avviene più; l'unità di assegnazione alla
controller è la lun (e sugli storage high-end non è vero nemmeno questo,
dato che non hanno il concetto di controller ma le componenti sono in
una switched-matrix).


>
> C'è da dire poi che se si vogliono fare le cose per bene sarebbe sempre
> meglio fare dei raid allineati 2^n+p che per il raid 10 vuol dire 4, 8 o
> 16 dischi, per il raid 5 vuol dire 5 o 9 dischi e per il raid 6 vuol
> dire 6 o 10 dischi. Questo perché l'I/O così sarà tendenzialmente
> allineato e distribuito equamente tra tutti i dischi migliorando la
> latenza delle operazioni (la cosa si complica, o si semplifica un po' se
> si vuol essere ottimisti, con gli storage chunk based come HP 3PAR o
> Huawei Oceanstor).

Queste cose possono essere vere per i raid software o per le raid *******
montate sui sistemi; molti storage vendor danno infatti indicazioni su
quale sia il miglior layout per la loro macchina assolutamente
discordanti rispetto alla pratica da te indicata.


>
> Altro discorso che invece non è stato considerato è la cache... questa
> incide sulle performance in modo pesantissimo e andrebbe dimensionata in
> 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.
THe_ZiPMaN 4 Lug 2015 20:13
On 04/07/2015 14:33, devx wrote:
> 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.

Gli I/O di VMware arrivano fino a 32MB ma il minimo mi pare di ricordare
che sia il settore.

--
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
THe_ZiPMaN 4 Lug 2015 20:36
On 04/07/2015 14:45, devx wrote:
>> C'è da dire poi che se si vogliono fare le cose per bene sarebbe sempre
>> meglio fare dei raid allineati 2^n+p che per il raid 10 vuol dire 4, 8 o
>> 16 dischi, per il raid 5 vuol dire 5 o 9 dischi e per il raid 6 vuol
>> dire 6 o 10 dischi. Questo perché l'I/O così sarà tendenzialmente
>> allineato e distribuito equamente tra tutti i dischi migliorando la
>> latenza delle operazioni (la cosa si complica, o si semplifica un po' se
>> si vuol essere ottimisti, con gli storage chunk based come HP 3PAR o
>> Huawei Oceanstor).
>
> Queste cose possono essere vere per i raid software o per le raid ******* >
montate sui sistemi; molti storage vendor danno infatti indicazioni su
> quale sia il miglior layout per la loro macchina assolutamente
> discordanti rispetto alla pratica da te indicata.

Se si va su macchine che fanno raid a livello di chunk le opzioni sono
solo quelle, ma poi tanto l'I/O è distribuito sempre su tutti i dischi
del pool... su macchine che ragionano a livello di dischi si usano anche
altre configurazioni per questioni di ottimizzazione tra distribuzione
del I/O e risorse perse per la parità. Ma su macchine di fascia media o
bassa la differenza c'è e in alcuni casi può essere significativa.
P.es. su un V7000 di un cliente, passando dalla configurazione 7+7+6+HS
di default alla 5+5+5+5+HS ha ridotto il numero di picchi dei tempi di
latenza >15ms riportati da VMware di un buon 70%... certo si perdono 5
dischi invece di 4, ma lo spazio non sempre è importante.
Poi magari per il 90% dei carichi è indifferente perché tanto lo storage
"ammortizza" l'I/O.

>> Altro discorso che invece non è stato considerato è la cache... questa
>> incide sulle performance in modo pesantissimo e andrebbe dimensionata in
>> 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.

Beh, certo, sono le ottimizzazioni che fanno i produttori... e ce ne
sono di ogni sorta. Una volta era tutto semplice perché ogni componente
funzionava in modo lineare... bisognava predisporre tutto bene a
tavolino, facendo bene i calcoli e tutto rispondeva nel modo
pianificato; se sbagliavi non andava nulla, se facevi le cose bene
andava tutto.
Oggi, tra algoritmi di caching ultra complicati, disponibilità di SSD,
sistemi di deduplica, compressione, thin provisioning, ecc.ecc., non è
più così semplice il corretto dimensionamento... IMHO con gli storage
moderni la cosa più semplice è affidarsi al configuratore del vendor e
lasciar tutto con le impostazioni proposte dal software... nel 90% dei
casi funzionerà tutto meglio che cambiando le impostazioni a mano. Nel
restante 10% si può scegliere il santo cui affidarsi :)
Per fortuna ormai anche quando si va di conserva è difficile tirar fuori
performance peggiori di quanto atteso (parlo comunque per il mio target,
ovvero infrastrutture piccole, con uno/due storage con meno di 100
dischi e fino ad una dozzina di host vmware)

> Questo per dire che quando lo storage "va lento" non esiste la medicina
> universale.

Concordo al 1000%...


--
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
writethem 18 Lug 2015 08:25
>
> 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.

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Discussioni sul sistema operativo Linux | Tutti i gruppi | it.comp.os.linux.sys | Notizie e discussioni linux | Linux Mobile | Servizio di consultazione news.