ISCSI Multipath

[Linoxmandy]

Ho dei problemi nella configurazione del multipath ISCSI 1Gb sul seguente scenario:

nr. 2 server esx 4.1 in cluster vmware, ognuno equipaggiato con due HBA ISCSI dedicate, connesse (in maniera incrociata) a due switch ethernet;

ciascuno switch ethernet è connesso allo storage dual controller ISCSI 1Gb (IBM DS3500) mediante un cavo verso il controller 1, e l'altro cavo verso il controller 2

Lo schema ip è questo:

SERVER 1:

HBA1: 10.10.10.11 - HBA2: 10.10.20.11

SERVER 2:

HBA1: 10.10.10.12 - HBA2: 10.10.20.12

STORAGE CONTROLLER 1:

PORTA 1: 10.10.10.111 - PORTA 2: 10.10.20.111 - PORTA 3 e 4 non utilizzate

STORAGE CONTROLLER 2:

PORTA 1: 10.10.10.112 - PORTA 2: 10.10.20.112 - PORTA 3 e 4 non utilizzate

Le subnet mask per tutti gli indirizzi indicati sono /24

Andando in Storage Adapters, nelle proprietà delle HBA ho inserito i targhet sia in Dynamic che Static Discovery.Es: nelle proprietà della HBA1 10.10.10.11 ho inserito come targhet 10.10.10.111 e 10.10.10.112; nelle proprietà della HBA2 10.10.20.11 ho inserito come targhet 10.10.20.111 e 10.10.20.112.

Andando nelle proprietà dei datastore corrisponendenti alle lun create sullo storage rilevo un solo path: 10.10.10.111

Il path selection per tutti i datastore è impostato su "Most Recently Used (Vmware)"

Dalle ricerche effettuate si rimanda a questo articolo: http://dailyvmtech.wordpress.com/2011/10/11/ibm-ds3500-multipathing-vsphere-mpio/

Ma francamente non mi sento sicuro di fare modifiche senza un confronto con qualcuno più esperto.

[ldelloca]

Senza uno schemino faccio fatica a seguirti, ma hai connesso gli storage in Direct Attach? Con iSCSI non è una scelta consigliabile, ti perdi tutti i path generati dagli indirizzi IP che transiterebbero in uno switch, a naso leggendo gli IP che hai messo è probabile che tu abbia un solo path; non so cosa intendi seguire dell'articolo indicato, ma il binding tra le NIC e gli inizializzatori software iSCSI andrebbe fatto a prescindere…

Luca.

[Linoxmandy]

Gli storage non sono connessi in direct attach, bensì attraverso nr.2 switch ethernet 1.000 Mb/s managed L2;

Lo schema (preso dal web come esempio) è il seguente, con la variante che i server sono 2: il secondo sever è connesso come mostrato in foto: una HBA è connessa ad uno switch, l'altra HBA è connessa all'altro switch.

Come indicato sopra, ogni controller ha 4 porte ISCSI, ma ne utilizzo soltanto due, essendo proprio due i cavi che arrivano a ciasun controller, come mostrato fedelmente nel'immagine.

Lo switch 1 è connesso alla porta 1 del controller1 e porta 1 del controller2

Lo switch 2 è connesso alla porta 2 del controller1 e porta 2 del controller2.

Ripeto di seguito l'assegnaizone degli indirizzi ip ISCSI:

SERVER 1:

HBA1: 10.10.10.11 - HBA2: 10.10.20.11

SERVER 2:

HBA1: 10.10.10.12 - HBA2: 10.10.20.12

STORAGE CONTROLLER 1:

PORTA 1: 10.10.10.111 - PORTA 2: 10.10.20.111 - PORTA 3 e 4 non utilizzate

STORAGE CONTROLLER 2:

PORTA 1: 10.10.10.112 - PORTA 2: 10.10.20.112 - PORTA 3 e 4 non utilizzate

Le subnet mask per tutti gli indirizzi indicati sono /24

Il problema è proprio che attualmente vedo solo un path su ciascun datastore, precisamente vedo solo il path 10.10.10.111.

Preciso che lo storage IBM DS3500 non è ALUA, inizialmente avevo distribuito le LUN in modo equilibrato sui due controller, ma allo stato attuale tutte le LUN sono connesse al Controller1.

[ldelloca]

Ciao, ho riletto bene sia i tuoi post che i link che hai indicato, ma hai realizzato i binding tra i virtual adapter iscsi e le nic fisiche? Perchè temo che il problema sia li...

Tra i mille post che si trovano in giro, guarda questo:

http://fojta.wordpress.com/2010/04/13/iscsi-and-esxi-multipathing-and-jumbo-frames/

in particolare la parte relativa ai VMkernel port bindings, non è un'operazione cosi rischiosa.

Non c'entra che lo storage sia ALUA o meno, dovresti comunque vedere tutti i path complessivi, al massimo ti dovrebbe dare quelli non attivi come appunto non active...

Ciao,

Luca.

[Linoxmandy]

Non ho realizzato binding. Gli storage adapter stanno "per fatti loro", e le nic altrettanto.

[ldelloca]

Ah ok, compreso, scusa per prima.

Uhm allora non mi torna qualcosa, perchè la configurazione anche a me così raccontata pare corretta. Altri controlli come vlan coerenti, jumbo frames, autenticazione chap o altro?

Sul DS3500 (che conosco poco) ci sono funzioni da abilitare relative al multipath?

Se provi a rimuovere tutti i discovery target e a mettere solo un IP alla volta, vedi sempre un solo path della stessa lun?

Altra cosa, per sicurezza ESXi è patchato?

Scusa l'elenco ma sto provando a elencare i controlli che farei anche io, per vedere se se ne esce...

Ciao,

Luca.

[Linoxmandy]

Faro dei controlli su quanto mi hai indicato, nel frattempo ho scoperto che l'ultima versione firmware dello storage.....

Dear Peter,

there is info in readme file for 7.83 firmware:

"Provide support for Asymmetric Logical Unit Access (ALUA) failover method
for storage subsystems with controller firmware versions 7.83.xx.xx and
higher installed. Currently, this failover method is supported for
Microsoft Windows 2003 or 2008, Linux RH 6.2 and later and SLES11 SP2 and
later, VMWare ESX4.1 U3 and later and ESXi5.0 U1 and later, Solaris 11, HP-
UX and MacOS operating system (OS) environments when an appropriate ALUA
host type is selected for the defined host and an ALUA-supported multipath
driver is installed in the host."

http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14900863&tstart=0

[Linoxmandy]

l'ambiente esx era fermo al 4.1 U1, ho provveduto ad aggiornare prima il vcenter alla versione 4.1U3 e poi i due host ESX alla versione 4.1 U3 patch11  (build 988178) ed ho aggiornato i firmware dello storage IBM.

Vedo sempre un solo ed unico path, ma proverò a fare delle verifiche ulteriori: credo ci sia da verificare il cablaggio iscsi HBA-SWITCH-STORAGE
Nel frattempo mi preoccupavo di questa frase:

• when an appropriate ALUA host type is selected for the defined host: ho effettuato questa operazione, ora come  host operative system dell'host (inteso come hba), mi compare VmwareTPGSALUA, prima invece non esistema questo tipo di operative system associabile.

• and an ALUA-supported multipath driver is installed in the host: come posso verificare di avere questo ALUA-supported driver?   -_-

Vi metto un po di link in "vostro" aiuto 🙂

http://communities.vmware.com/message/2166622

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=201675... (il mio storage è proprio IBM DS3512)

http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?subtype=ca&infotype=an&appname=iSource&supplier=89...

[Linoxmandy]

stando a quanto scritto qui: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=201675...

e verificando che i miei datastore presentano queste informazioni:

Direi che gli aggiornamenti hanno avuto il loro effetto.

[ldelloca]

Ottimo, facci sapere poi se dopo le verifiche riesci a vedere tutti i percorsi.

Ciao,

Luca.

[Linoxmandy]

C'era un problema Layer1 nel percorso che andava dallo switch san- allo storage.

L'ho risolto ed ora lo storage vede correttamente le nr.4 hba (initiator); i datastore vmware vedono correttamente due path (dovrebbero vederne 4!), confermo che questi sono impostati con multipath-policy MRU.

I due path che vengono visti si riferiscono alle due hba del nodo (host esx) 1. In pratica i datastore non sono visti da nessuna delle due HBA del nodo (host esx) 2. Eppure dallo storage vedo correttamente le 4 hba, essendomi risultate attrverso discovery effettuato dallo storage.

Andando nelle proprietà dei 4 storage adapter (hba) ho inserito nel campo Dynamic Discovery, l'indirizzo ip iscsi (afferenti alla propria subnet) dei due controller storage; tuttavia in Static Discovery viene fuori solo l'indirizzo IP del controller A;

Questo problema è ora scomparso in seguito all'update del post seguente.

Siccome lo storage non prevede tale funzione in automatico, avendo configurato 4 lun sullo storage, ho assegnato 2 lun al controller A dello storage, e le altre 2 lun al controller B dello storage. Il performance monitor dello storage vedeva correttamente traffico I/O su entrambi i controller.

Dopo pochi minuti, le lun in carico al controller B sono state prese in carico dal controller A, in maniera indesiderata. Pertanto ora tutto il traffico I/O passa dal controller A. L'evento generato dallo storage è il seguente: Logical Drive not on preferred path due to ADT/RDAC failover Event Priority.

[Linoxmandy]

UPDATE:

ho aggiunto il secondo target mancante in Static Discovery per i 4 storage adapter (hba)  ed ora nel monitoring dello storage vedo 8 sessioni-iscsi (prima ne vedevo solo 4, cioè soltanto quelle gestite dal controller A)

E "magicamente" ora vedo 4 path per ciascun datastore. FINALMENTE!!!!!!!!!!!!! :smileylaugh:

Le domande sono:

- per tutti i datastore ho la seguente situazione: ci sono 4 path, tutti in status active, solo uno di questi è Ative (I/O). per tutti i datatsore il path Active (I/O) si riferisce alla HBA1 del nodo esx1. Praticamente tutto il traffico iscsi transita da una sola HBA?? Come potrei bilanciare meglio il carico della HBA dei due nodi ESX?

- in riferimento a quanto rispostomi in questa discussione: http://communities.vmware.com/message/2197854#2197854 mi aiutate a capire se il miei nodi ESX 4.1u3 patch11 supportano AULA?

- evidentemente gli aggiornamenti di ESX hanno cambiato qualcosa: mi viene richiesto obbligatoriamente di inserire il default gateway sugli storage adapter (hba). Che valore dovrei inserire?

- tento di impostare il multipath round robin per tutti i datastore?

[Linoxmandy]

Mi abbandonate proprio sul più bello??

[ldelloca]

Ciao,

ESXi 4.1 supporta ALUA, ma il problema non è l'ESXi, quanto piuttosto lo storage. Se leggi qui:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101134...

su 4.1 il multipath predefinito per storage ALUA è fixed. Il fatto di poterlo passare a Round Robin senza problemi dipende dallo storage vendor e da cosa consiglia: mi è capitato recentemente con un IBM V7000, che è un ALUA, che VMware impostasse anche su ESXi 5.1 il PSP su fixed, ma il IBM suggeriva di passare comunque a Round Robin, e così abbiamo fatto. Si sono visti minimi miglioramenti, ma comunque percettibili.

Il fatto è che con ALUA avrai sempre un solo SP che in quel momento è owner delle lun, e quindi tutti i path che vanno ad esso sono preferred. Con uno storage ALUA, anche l'SP non owner presenta le lun ad ESXi, ma non essendo lui il proprietario queste vengono indicate come non-preferred, dato che un'eentuale attività di I/O dovrebbe essere reindirizzata dall'SP non-owner a quello owner, e questa attività è inefficiente solitamente.

Sul DS3500 non saprei dirti, io ad esempio l'ho sempre configurato sulle P2000 in RR senza grossi problemi. Dovresti verificare su qualche documento IBM. Ad oggi il comportamento che segnali è perfettamente prevedibile.

Per il gateway, stai usando l'iscsi software giusto? Il gateway va benissimo che sia quello di default dell'ESXi stesso (dovrebbe già proportelo, scusa ma 4.1 inizia ad essere vecchiotto e non mi ricordo a memoria i parametri senza una console davanti), anche perchè in ogni caso iscsi su VMware non supporta il routing (e fanno bene, ruotare un traffico pesante come iscsi può solo portare rallentamenti e problemi).

Ciao,

Luca.