Sistemi di virtualizzazione
 

Storage lowcost hiperf per vmware

poiuuuu 18 Lug 2015 08:15
Buongiorno a tutti,
come da precedenti richieste qui e altrove, sto approfondendo l'aspetto
storage. Per fare laboratorio e per usarlo da noi (una 30ina di VM, non
oltre), pensavo di creare uno storageserver come segue:

NAS con OpenFiler con:
- RAID Adaptec 71605Q 16 vie con CacheMax, con batteria e ampliabile
256 dischi
- 2 dischi SSD 250Gb SamsungEvo in R1 per Cache (il controller raid di
cui sopra, permette la creazione di un array in cache extender, sembra
essere davvero performante)
- 14 WD Red Pro SATA da 4Tb, 2 raid5 da 6 dischi + 2 HotSpare
- adattatore iscsi *****ware (dipendent) NetXtreme II 5709 4 porte gigabit

Sui nodi vmware
- NetXtreme II 5709 *****ware (dipendent) 2 porte iscsi

(circa 3000 euro)


Quindi ricapitolando avremmo:
- un controller raid di alto livello e ampliabile a 256 dischi
- 250Gb di cache SSD (in Raid1)
- interfacce iscsi *****ware
- 48Gb di storage (2xR5+2HS) SATA (ma con cache)

Ad un prezzo svariate unità di misura sotto rispetto a soluzioni
commerciali (che hanno tutt'altri vantaggi, ovviamente, come il dual
controller che qui mi manca e che trovo sia davvero la pecca maggiore).

Che ne pensate? E' così poi tanto folle? O a 3keuro è davvero una
soluzione valida? Che punti deboli vedete?
writethem 18 Lug 2015 08:27
> - 48Gb di storage (2xR5+2HS) SATA (ma con cache)

Pardon, ovviamente intendevo 48Tb :)
THe_ZiPMaN 18 Lug 2015 18:33
On 18/07/2015 08:15, poiuuuu wrote:
> Che ne pensate?

Che dal costo hai omesso il lavoro per metterlo in piedi, il supporto,
ecc.ecc.

Una QNAP TVS-1271U-RP, con 10 dischi da 6TB (48tb netti), cache SSD
interna 128+128 e dual 10gbe, viene a costare meno di 5000 euro.
E' tutto fatto, correttamente supportato e certificato (p.es. su VMware
hai VAAI), sicuramente funzionante e non devi perder tempo se non per
inserire i dischi nelle slitte e configurare i volumi.

Se invece vuoi andare su prodotti seri non spendi comunque molto di più.
Una Huawei Oceanstor ST2200 con 10 dischi da 6TB e 2 SSD da 200 dovremmo
essere sotto gli 8k (in questo momento non mi funziona il configuratore
per vedere il prezzo corretto), ma parliamo appunto di uno storage con
doppio controller ecc.ecc.


--
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 19 Lug 2015 08:57
> Una QNAP TVS-1271U-RP, con 10 dischi da 6TB (48tb netti), cache SSD
> interna 128+128 e dual 10gbe, viene a costare meno di 5000 euro.
> E' tutto fatto, correttamente supportato e certificato (p.es. su VMware
> hai VAAI), sicuramente funzionante e non devi perder tempo se non per
> inserire i dischi nelle slitte e configurare i volumi.

ottimo, mi documento subito. Come performance ritieni sia una soluzione
mediamente valida? La cache ssd dovrebbe sopperire di molto ai picchi delle
latenze degli economici SATA, che ne pensi
THe_ZiPMaN 19 Lug 2015 15:04
On 19/07/2015 08:57, writethem wrote:
>
>> Una QNAP TVS-1271U-RP, con 10 dischi da 6TB (48tb netti), cache SSD
>> interna 128+128 e dual 10gbe, viene a costare meno di 5000 euro.
>> E' tutto fatto, correttamente supportato e certificato (p.es. su VMware
>> hai VAAI), sicuramente funzionante e non devi perder tempo se non per
>> inserire i dischi nelle slitte e configurare i volumi.
>
> ottimo, mi documento subito. Come performance ritieni sia una soluzione
mediamente valida?

Tendenzialmente sì. Io normalmente è la soluzione che uso come
repository per i backup fatti con Veeam (mappo in iSCSI una LUN ad un
host virtuale); una parte dello spazio poi lo uso come datastore VMware
per quanto riguarda ISO, template e ambienti Demo e di test e per il
Virtual Lab di Veeam per i test automatizzati di ripristino.

> La cache ssd dovrebbe sopperire di molto ai picchi delle latenze degli
economici SATA, che ne pensi

Decisamente sì. Di solito se c'è la cache SSD io metto direttamente i 10
dischi in raid6. Se però tu vuoi usarla per macchine di produzione che
scrivono tanto e necessitano di performance ti consiglio due raid 5 da
4+1 dischi.

--
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 21 Lug 2015 16:12
On 19/07/2015 15:04, THe_ZiPMaN wrote:
>> ottimo, mi documento subito.

Mi è appena passata sott'occhio una QNAP refurbished da 100TB con
garanzia 1 anno a meno di 4k€


--
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 21 Lug 2015 16:59
Il 21/07/2015 16.12, THe_ZiPMaN ha scritto:
> On 19/07/2015 15:04, THe_ZiPMaN wrote:
>>> ottimo, mi documento subito.
>
> Mi è appena passata sott'occhio una QNAP refurbished da 100TB con
> garanzia 1 anno a meno di 4k€
>
>

In effetti stavo davvero reinventando la ruota, a poco più di una
soluzione artigi*****e, tutto sommato qnap ha ciò che serviva.

Hai qualche dettaglio di questa SAN (intendo anche commerciale)? Ti
mando email aziendale su linkedin :)
writethem 25 Lug 2015 13:01
> Decisamente sì. Di solito se c'è la cache SSD io metto direttamente i 10
> dischi in raid6. Se però tu vuoi usarla per macchine di produzione che
> scrivono tanto e necessitano di performance ti consiglio due raid 5 da
> 4+1 dischi.

stavo riflettendo, a conti fatti (ho preso un 8 baie):

R6 di 8 dischi sata = Read 560 IOPS, Write 93 IOPS
R5 di 6+6 dischi = Read 280 IOPS cad, Write 70 IOPS cad

Come affidabilità, un R6 di 8 dischi dovrebbe statisticamente essere
molto più affidabile di due Raid 5 da 4 dischi. Come performance, tutto
sommato in write potrebbe essere meglio avere più IOPS utilizzabili
sullo stesso array per gestire i picchi.

Come soluzione, anche in produzione con macchine che frullano, potrebbe
andare bene anche un R6 di 8 dischi. Che ne pensi?

Il Raid5 su 8 dischi è, secondo me, offlimits come affidabilità (anche
se sto mettendo WD RE).
THe_ZiPMaN 26 Lug 2015 20:39
On 25/07/2015 13:01, writethem wrote:
> R6 di 8 dischi sata = Read 560 IOPS, Write 93 IOPS
> R5 di 6+6 dischi = Read 280 IOPS cad, Write 70 IOPS cad

Non mi contano i torni... in lettura 12 dischi vanno il 50% in più di 8
(a prescindere dal raid in questo caso). In scrittura hai il 50% in più
per numero di meccaniche e il 50% in più per minore penalizzazione.
Quindi lì sopra c'è qualche errore...

R6 - R: 70x8=560
R6 - W: 70x8/6=93

R5 - R: 70x6=420 x2=840
R5 - W: 70x6/4=105 x2=210

> Come affidabilità, un R6 di 8 dischi dovrebbe statisticamente essere
> molto più affidabile di due Raid 5 da 4 dischi.

Decisamente. Migliaia di volte più sicuro.

> Come performance, tutto
> sommato in write potrebbe essere meglio avere più IOPS utilizzabili
> sullo stesso array per gestire i picchi.
>
> Come soluzione, anche in produzione con macchine che frullano, potrebbe
> andare bene anche un R6 di 8 dischi. Che ne pensi?

Se non scrivono molto sì, potrebbe andare... comunque sempre molto meno
del doppio R5.

> Il Raid5 su 8 dischi è, secondo me, offlimits come affidabilità (anche
> se sto mettendo WD RE).

Sì. Dischi troppo grandi per fare un unico raid.


--
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 27 Lug 2015 08:59
Il 26/07/2015 20.39, THe_ZiPMaN ha scritto:
> On 25/07/2015 13:01, writethem wrote:
>> R6 di 8 dischi sata = Read 560 IOPS, Write 93 IOPS
>> R5 di 6+6 dischi = Read 280 IOPS cad, Write 70 IOPS cad
>
> Non mi contano i torni... in lettura 12 dischi vanno il 50% in più di 8
> (a prescindere dal raid in questo caso). In scrittura hai il 50% in più
> per numero di meccaniche e il 50% in più per minore penalizzazione.
> Quindi lì sopra c'è qualche errore...
>
> R6 - R: 70x8=560
> R6 - W: 70x8/6=93
>
> R5 - R: 70x6=420 x2=840
> R5 - W: 70x6/4=105 x2=210

pardon, vero. intendevo:

R5 di 4+4 dischi (ho 8 baie) = Read 280 IOPS cad, Write 70 IOPS cad


> Sì. Dischi troppo grandi per fare un unico raid.

quindi tu con 8 dischi 4Tb faresti 2 R5 piuttosto di 1 R6 univoco? Pur
avendo 120Gb di cache ssd?

Calcola che ora ho le stesse 15/20 macchine virtuali su un R5 di 4
dischi ed ho 25ms di latenza media (tutto sommato sta andando bene) con
256Mb di cache.
THe_ZiPMaN 28 Lug 2015 02:20
On 27/07/2015 08:59, writethem wrote:
> quindi tu con 8 dischi 4Tb faresti 2 R5 piuttosto di 1 R6 univoco? Pur
> avendo 120Gb di cache ssd?

No. Farei un raid6 :)
Ma come detto avrei acquistato un 12 bay con 10 unità per fare due raid
5 da 4+1 dischi ciascuno.

--
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 28 Lug 2015 07:22
Il 28/07/2015 02.20, THe_ZiPMaN ha scritto:
> On 27/07/2015 08:59, writethem wrote:
>> quindi tu con 8 dischi 4Tb faresti 2 R5 piuttosto di 1 R6 univoco? Pur
>> avendo 120Gb di cache ssd?
>
> No. Farei un raid6 :)
> Ma come detto avrei acquistato un 12 bay con 10 unità per fare due raid
> 5 da 4+1 dischi ciascuno.


Ti ringrazio.

Ne approfitto visto che conosci i qnap e li configuri sovente, sto
seguendo la best practices
https://www.qnap.com/i/en/trade_teach/con_show.php?op=showone&cid=64 per
collegarlo con vmware.

Devo dire che non mi quadrano alcune cose:
- non fa cenno ai settori, che invece di 512byte sto configurando in 4K
(che su vmware dovrebbe essere più performante?)
- non fa cenno ai jumbo frame, che invece sto abilitando a 9000
- non capisco perchè mi fa fare più LUN per poi mettere il datastore in
extend (non era meglio farne una sola? Dove sta il vantaggio?)
- fare il teaming di rete è del tutto indifferente lato storage, perchè
tanto poi su vmware metto in roundrobin, giusto? Alla fine lui trova
comunque tanti path quante schede di rete collego
- lui fa fare una lun "speciale" per collegare i dischi in raw... ma io
non ne sento la necessità, onestamente. Mi sono perso qualcosa?

Scusami Flavio se abuso del tuo tempo, ti ringrazio in anticipo per
tutto. Cena pagata :)



@SAP: sicuramente questo interessa anche il tuo 3ad.
THe_ZiPMaN 28 Lug 2015 18:55
On 28/07/2015 07:22, writethem wrote:
> Il 28/07/2015 02.20, THe_ZiPMaN ha scritto:
>> On 27/07/2015 08:59, writethem wrote:
>>> quindi tu con 8 dischi 4Tb faresti 2 R5 piuttosto di 1 R6 univoco? Pur
>>> avendo 120Gb di cache ssd?
>>
>> No. Farei un raid6 :)
>> Ma come detto avrei acquistato un 12 bay con 10 unità per fare due raid
>> 5 da 4+1 dischi ciascuno.
>
>
> Ti ringrazio.
>
> Ne approfitto visto che conosci i qnap e li configuri sovente, sto
> seguendo la best practices
> https://www.qnap.com/i/en/trade_teach/con_show.php?op=showone&cid=64 per
> collegarlo con vmware.
>
> Devo dire che non mi quadrano alcune cose:
> - non fa cenno ai settori, che invece di 512byte sto configurando in 4K
> (che su vmware dovrebbe essere più performante?)

No, lascia i 512 altrimenti via iSCSI non ti viene correttamente
riconosciuto da VMware (perlomeno fino alla 5.5).

> - non fa cenno ai jumbo frame, che invece sto abilitando a 9000

Sì se tutti i device (switch e VMware) sono configurati in accordo.

> - non capisco perchè mi fa fare più LUN per poi mettere il datastore in
> extend (non era meglio farne una sola? Dove sta il vantaggio?)

In che senso ti fa fare più lun? Comunque ogni datastore non dovrebbe
contenere più di 10VM, quindi è corretto fare più LUN distinte.
Se hai invece problemi con le LUN > 2TB è perché probabilmente non stai
usando VMFS5

> - fare il teaming di rete è del tutto indifferente lato storage, perchè
> tanto poi su vmware metto in roundrobin, giusto? Alla fine lui trova
> comunque tanti path quante schede di rete collego

Se lo usi via iSCSI non devi fare teaming ma devi usare il multipath.
Quindi ad ogni scheda della NAS assegni un IP e configuri tutti i path
in VMware

> - lui fa fare una lun "speciale" per collegare i dischi in raw... ma io
> non ne sento la necessità, onestamente. Mi sono perso qualcosa?

Non capisco questa cosa... screenshot?

--
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 29 Lug 2015 08:17
> No, lascia i 512 altrimenti via iSCSI non ti viene correttamente
> riconosciuto da VMware (perlomeno fino alla 5.5).

ieri ci siamo impazziti, in effetti 4K anche sulla 6 non funge :)



>> - non fa cenno ai jumbo frame, che invece sto abilitando a 9000
>
> Sì se tutti i device (switch e VMware) sono configurati in accordo.

l'aspetto davvero bizzarro è che configurando i jumbo frame a 9000
comunque non ho avuto alcun beneficio in termini di performance.
Fermo restando che è configurato correttamente (ping don't fragment di
dimensione 8900 ok e "too long" quando riporto a 1500 tutti i device, i
jumbo frame sono impostati bene su tutti gli apparati coinvolti). Mi
aspettavo una differenza importante, invece tutto uguale. Ho anche
provato a spostare ******* di grandi dimensioni (casomai il mio benchmark
sui dischi non arrivasse a necessitare dei pacchetti jumbo)... ma nulla.
Mbho.. anche utilizzando una sola NIC (quindi facendo in modo tale che
fosse la rete il fattore limitante)




>> - non capisco perchè mi fa fare più LUN per poi mettere il datastore in
>> extend (non era meglio farne una sola? Dove sta il vantaggio?)
>
> In che senso ti fa fare più lun? Comunque ogni datastore non dovrebbe
> contenere più di 10VM, quindi è corretto fare più LUN distinte.
> Se hai invece problemi con le LUN > 2TB è perché probabilmente non stai
> usando VMFS5

Facevo riferimento alla best practices di qnap:
https://www.qnap.com/i/en/trade_teach/con_show.php?op=showone&cid=64

Lui mi fa fare un numero di LUN, e fin qui va bene. Teoricamnte andrei a
dividere le macchine cercando di stare entro le 10 VM per LUN. Ma nella
best practices poi mi fa fare un "increase" del datastore. Quindi ho 4
LUN, ma che alla fine convergono in un unico datastore. Che ne pensi?
Non è un controsenso? Alla fine non sto annullando il vantaggio di avere
massimo 10VM per Datastore in questa maniera e utilizzando l'increase?
Sempre un datastore è, anche se la 4 LUN.


>> - fare il teaming di rete è del tutto indifferente lato storage, perchè
>> tanto poi su vmware metto in roundrobin, giusto? Alla fine lui trova
>> comunque tanti path quante schede di rete collego
>
> Se lo usi via iSCSI non devi fare teaming ma devi usare il multipath.
> Quindi ad ogni scheda della NAS assegni un IP e configuri tutti i path
> in VMware

dagli esperimenti che ho fatto ieri, mettere 4 ip diversi e far fare il
multipath roundrobin a vmware è risultato meno performante (almeno di un
15% circa) di mettere lato datastore le interfacce in "load balance alb"
pur mantenendo in vmware il multipath roundrobin.
Anche misurando le schede di rete, effettivamente in load balance lato
datastore, si occupava lui di bilanciare il carico sulle sue NIC.
Probabilmente la gestisce meglio e riduce i tempi di risposta,
restituendo delle performance migliori. Ti torna/hai mai provato questa
modalità di recente?



>> - lui fa fare una lun "speciale" per collegare i dischi in raw... ma io
>> non ne sento la necessità, onestamente. Mi sono perso qualcosa?
>
> Non capisco questa cosa... screenshot?

come sopra, in riferimento alla best practices di qnap del link
THe_ZiPMaN 29 Lug 2015 21:54
On 29/07/2015 08:17, writethem wrote:
> l'aspetto davvero bizzarro è che configurando i jumbo frame a 9000
> comunque non ho avuto alcun beneficio in termini di performance.
> Fermo restando che è configurato correttamente (ping don't fragment di
> dimensione 8900 ok e "too long" quando riporto a 1500 tutti i device, i
> jumbo frame sono impostati bene su tutti gli apparati coinvolti). Mi
> aspettavo una differenza importante, invece tutto uguale. Ho anche
> provato a spostare ******* di grandi dimensioni (casomai il mio benchmark
> sui dischi non arrivasse a necessitare dei pacchetti jumbo)... ma nulla.
> Mbho.. anche utilizzando una sola NIC (quindi facendo in modo tale che
> fosse la rete il fattore limitante)

Ma sui portgroup di VMware dedicati al iSCSI hai messo l'MTU a 9k?

>> In che senso ti fa fare più lun? Comunque ogni datastore non dovrebbe
>> contenere più di 10VM, quindi è corretto fare più LUN distinte.
>> Se hai invece problemi con le LUN > 2TB è perché probabilmente non stai
>> usando VMFS5
>
> Facevo riferimento alla best practices di qnap:
> https://www.qnap.com/i/en/trade_teach/con_show.php?op=showone&cid=64
>
> Lui mi fa fare un numero di LUN, e fin qui va bene. Teoricamnte andrei a
> dividere le macchine cercando di stare entro le 10 VM per LUN. Ma nella
> best practices poi mi fa fare un "increase" del datastore. Quindi ho 4
> LUN, ma che alla fine convergono in un unico datastore. Che ne pensi?

IMHO è una troiata. Valeva fino alla 4.x perché non potevi fare LUN più
grosse di 2TB. Peraltro anche VMware sconsiglia di usare gli extent.

>> Se lo usi via iSCSI non devi fare teaming ma devi usare il multipath.
>> Quindi ad ogni scheda della NAS assegni un IP e configuri tutti i path
>> in VMware
>
> dagli esperimenti che ho fatto ieri, mettere 4 ip diversi e far fare il
> multipath roundrobin a vmware è risultato meno performante (almeno di un
> 15% circa) di mettere lato datastore le interfacce in "load balance alb"
> pur mantenendo in vmware il multipath roundrobin.
> Anche misurando le schede di rete, effettivamente in load balance lato
> datastore, si occupava lui di bilanciare il carico sulle sue NIC.
> Probabilmente la gestisce meglio e riduce i tempi di risposta,
> restituendo delle performance migliori. Ti torna/hai mai provato questa
> modalità di recente?

No, mai provato. Solo da un singolo cliente ho le schede in etherchannel
(anche sullo switch ovviamente) ma perché usa la NAS sia come iSCSI che
come NFS.


--
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 30 Lug 2015 07:48
> Ma sui portgroup di VMware dedicati al iSCSI hai messo l'MTU a 9k?

Si, ovunque. Sia sul vswitch sia sul vmkernel al suo interno. Ho
riprovato decine di volte... mbho. Appena mi arrivano le NIC 10Gbit
provo su quelle. Ora sto provando sulle 1Gbit.



>> Lui mi fa fare un numero di LUN, e fin qui va bene. Teoricamnte andrei a
>> dividere le macchine cercando di stare entro le 10 VM per LUN. Ma nella
>> best practices poi mi fa fare un "increase" del datastore. Quindi ho 4
>> LUN, ma che alla fine convergono in un unico datastore. Che ne pensi?
>
> IMHO è una troiata. Valeva fino alla 4.x perché non potevi fare LUN più
> grosse di 2TB. Peraltro anche VMware sconsiglia di usare gli extent.

ottimo, mi sono tolto un bel dubbio. Farò comunque più datastore, ma
separate e per bilanciare le macchine.



Grazie ancora.

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

Sistemi di virtualizzazione | Tutti i gruppi | it.comp.virtualizzazione | Notizie e discussioni virtualizzazione | Virtualizzazione Mobile | Servizio di consultazione news.