Newsgroup: it.comp.os.linux.sys
Titolo: iSCSI on MSA2012i

Buongiorno a tutti,
    riprendo un thread iniziato tempo fa relativamente all'iSCSI e le 
prestazioni nel particolare della macchina HP appenta uscita, l'MSA2012i 
che altro non è che lo chassis del 2000 a cui è stata messa una 
interfaccia iSCSI, ma a cui è possibile installare la versione FC senza 
il cambio del cassetto.
Partiamo dai presupposti del test (a cui possiamo aggiungere altri test, 
se qualcuno ha proposte):
- MSA2012 dual CPU, 4 porte iSCSI (poi commentiamo come funzionano)
- due switch cisco 3750 gigabit collegati in stack
- singolo nodo con doppia scheda di rete gigabit senza TOS
Ogni CPU ha due prese di rete, attaccata ciacuna ad uno switch, stessa 
cosa per l'host. Non c'è TOS e lato switch/host c'è il bilanciamento 
802.3ad statico (l'host non supporta LACP) con politica src-dst-ip e non 
la più performante (ma qui non conta) dst-mac. Sono attivi i Jumbo Frame 
su tutta l'infrastruttura.
Velocità: singolo host che legge/scrive su singola LUN RAID1 da 146Gb: 
70MB/s, rilevati anche sullo switch come circa 600Mbps. Le prove sono 
state fatte con "hdparm -t" e con un più corposo dd if=/dev/X of=/dev/null
Ridondanza: riporto direttamente quanto scritto negli appunti del 
test-plan per fare prima, possibile che non sia cristallino il ragionamento:
Il failover funziona così: ogni CPU e quindi ogni controller RAID 
esporta per intero un raidgroup all'interno del quale ci sono delle LUN. 
I RG vengono assegnati alle CPU col metodo round-robin, quindi primo RG 
al controller A, secondo al controller B e così via. Il sistema espone 
al pubblico 4 target scsi, 2 per il controller A (IQN che finisce per A) 
e 2 per il controller B. Fino a quando entrambi i controller sono in 
gioco, detengono gli RG come definito. Se un link di A cade, gli host 
vedono un solo path verso quelle N lun. Se entrambi i link di A o A 
stesso cadono, sarà la CPU B ad esporre le LUN e gli scsi-target di A 
(con lo stesso IQN) su B. Non si vedranno mai quindi 4 path iSCSI, ma 
sempre due (provenienti dallo stesso IQN, stessa CPU), ma in caso di 
crollo di una CPU in maniera trasparente sarà la seconda CPU a esporre
le LUN. Ogni CPU ha 2 eth, con due IP distinti.
Se non si è capito non c'è aggregazione lato SP dello storage.
Angelo

 le LUN. Ogni CPU ha 2 eth, con due IP distinti.
Be questo lo sapevo.
Le due controller funzionano in simultanea, ma non è possibile
accedere ad una singola
LUN da entrambe le controller.
Controller 1 ==> LUN 1, LUN 3, LUN 5
Controller 2 ==> LUN 2, LUN 4, LUN 6
Quindi una parte di server saranno collegati alla controller1 per la
LUN 1 e l'altra parte all'altra controller.
Se muore una controller, la controller rimasta attiva si fa carico
delle LUN orfane.
Hai modo di buttare su 'tanti' host o fare un test più 'reale'
rispetto ad un semplice dd?
Magari simulare la ricezione di X mail salvate su storage....

 Magari simulare la ricezione di X mail salvate su storage....
La prossima settimana lo vado ad installare in server farm, saranno 10 
host fisici con una trentina di VM con il disco li sopra. A quel punto, 
in un momento di relativa pace, si può provare un po' di traffico da più 
host (reali o virtuali, la differenza non supera il 10% di calo di 
prestazioni) si vede come va.
Angelo