Ormai da tempo ho la possibilità di lavorare sul 6540, uno degli storage Midrange commercializzati da Sun. Il 6540 è il gemello del DS4800 di IBM, entrambi disegnati da Engenio, proprietà di LSI.
Ha due controllers con 4 porte 4 Gbit ciascuno. Con sistemi Sun SPARC e x64 il multipathing per lo spread e il failover del traffico viene gestito dallo Storagetek Traffic Manager, anche noto come MPXIO, disponibile in bundle su Solaris10 e scaricabile come pacchetto opzionale per le versioni precedenti.
Questo software è disponibile inoltre per Windows e Hp-Ux, tra gli altri, comunque a pagamento.
Hp-uX 11.31 ha un sistema di gestione del carico del traffico SAN nativo; non essendo disponibile il gestore Sun per questi sistemi abbiamo deciso di “give it a try”.
Creare una LUN sul 6540 da mappare a un host Rx Integrity dotato di due HBA FC 4Gbit HP AB378-60101, al secolo QLogic ISP24xx, è procedura che segue parametri standard, se si eccettua che va selezionato “Hp-uX” come opzione Driver di Gestione SAN/Sistema Operativo. Naturalmente, sull’host non verrà presentato un singolo device logico virtuale come con mpxio, ma anzi, ben quattro path logici.
Quindi, se per una LUN lato host, su Solaris abbiamo qualcosa tipo:
c2 -> controller fisico 1
c3 -> controller fisico 2
c4 -> controller virtuale (quello a cui si fa riferimento nell’usare il volume)
Su Hp-uX con multipathing nativo avremo:
c2 -> controller fisico 1 controller A
c4 -> controller fisico 1 controller B
c6 -> controller fisico 2 controller A
c8 -> controller fisico 2 controller B
Comodo, vero?
I parametri di default lato host, in questo caso, non vanno bene. Le luns risultano pressochè inutilizzabili. L’algoritmo di bilanciamento di default è round-robin, ma l’implementazione pare incompatibile con l’array in questione, facendo risultare la user experience orribile; a quanto pare il problema sarebbe un continuo ping pong nell’inizializzazione della comunicazione tra target e initiator, che rende instabile e funzionante a singhiozzo l’I/O.
Tramite scsi_mgr, è possibile impostare parecchi parametri, tra cui anche l’algoritmo di bilanciamento. Una soluzione provata è stata quella di impostare la politica di bilanciamento dell’host come “usa il path più scarico”. Questo ha fatto migliorare sensibilmente l’usabilità, ma risulta in una ennesima “incomprensione” tra host e storage, e quest’ultimo genera un warning ogni volta che l’host cambia il path in uso, essendo in disaccordo sul cambio di controller; viene effettivamente forzato e lo vede come un possibile problema.
Il 6540 lavora con la logica del preferred controller. Alla creazione del volume, esso gli assegna un preferred, che sarà la controller che cercherà di usare come primaria. Usando MPXIO, il sistema è in grado di comunicare e “collaborare” con lo storage per permettergli di seguire la sua logica di funzionamento. Il Native MP di Hp-uX 11i v3 non è in grado di seguire e collaborare a questa gestione dinamica, o per lo meno, non si accorda con lo storage per il cambio di path. Questo significa guai.
La soluzione in questo caso è stata forzare questo comportamento con una gestione manuale, individuando lato host il path corrispondente al preferred scelto dal 6540 e settandolo su Hp-uX come tale, stessa cosa per il secondario. Questo pare aver dato una configurazione funzionante, le prestazioni sembrano ok e nessun warning viene più generato.
Dai test eseguiti, ovvero, un reboot e la disconnessione fisica della fibra, sembra essere tutto ok.
Ovviamente, a ogni nuova lun creata si ripropone il problema di mappare correttamente sull’host i path primario e secondario come li sceglie lo storage.
Sarebbe interessante sapere come si sono “aggiustati” altri amministratori e avere qualche informazione in più sulla cosa. Sarebbe anche interessante vedere l’implementazione di mpxio su hp-ux.
