Pruebas de multipathd en linux contra VNX

[tonin]

Para ir anotando los progresos en las pruebas al respecto.

[tonin]

Usamos la máquina ibmblade26 como prototipo para las pruebas.

• Creamos la sesión de sancopy a VNX
• Hacemos un snapshot de la lun blade26 en vnx para poder deshacer cambios
• Borramos el fichero de configuración de multipath en la LUN para que lo genere de nuevo al arrancar
• Apagamos la máquina, realizamos el último start a ella
• Añadimos las 4 nuevas zonas a nuestro fabric, similares a las que tenía contra CX3
• Retiramos la LUN del CX3 para que solo vea la nueva

Comenzamos las pruebas ....

[tonin]

En el primer arranque, la máquina al menos arranca. Se presentan tres problemas

PROBLEMA1

Uno de los caminos al nuevo VNX desde la bios de las qlogic queda identificado como LUNZ y no VRAID

PROBLEMA2

El comando multipath -ll devuelve 4 errores referentes a los caminos hacia el antiguo CX3

PROBLEMA3

El comando multipath -ll solo da 3 caminos reconocibles, aparte tenemos dudas de que estén bien configurados

[tonin]

PROBLEMA1 (solved)

En connectivity status del VNX, revisamos los caminos encontrados, y vemos que en la pestaña advances hay una casilla para marcar, que está marcada en el conflictivo, donde establece compatibilidad con LUNZ. Lo desmarcamos.

Hay que tener cuidado de revisarlo bien y anotarlo en el documento de configuración que pondremos en drupal.

[tonin]

PROBLEMA2 (solved)

Una vez que se está arrancando del VNX, no tiene sentido mantener el host en el storage group del CX3. Si lo mantenemos es lógico que vea las 4 LUNZ y de dicho error. Mantenemos el storage group de lo que vayamos migrando, pero sin luns ni hosts por si en el futuro queremos asignarle alguna lun desde el antiguo CX3.

[tonin]

(a partir de ahora todo es relativo a PROBLEMA3)

Una vez solucionado el problema1, ya aparecen los 4 caminos, pero aun parece que no están correctamente configurados.

Encuentro el documento ​https://bugzilla.redhat.com/show_bug.cgi?id=692239 para que lo pruebe Javier, espero a que documente aquí el resultado de las primeras pruebas.

Inicialmente parece que el nuevo modo 4 de failover (ALUA), tiene que ser tratado de una forma especial con multipathd en linux.

[tonin]

Centos 5.3 no soporta ALUA de forma explícita, por eso aun poniendo "device handler=1 alua" lo sigue cogiendo como "1 emc".

"man multipath.conf" deja claro que el único identificador soportado para hardware handler es "1 emc".

Hay que actualizar.

[tonin]

Sacado de la release note de redhat 5.4 (a la que me redirige centos cuando quiero ver la release note de su versión 5.4):

8.1. General Kernel Feature Support
Asymmetric Logical Unit Access (ALUA) support in device-mapper-multipath has been updated, adding explicit ALUA support for Clariion storage. Earlier versions of Red Hat Enterprise Linux 5 added support for implicit ALUA (i.e. the operating system is not aware of which storage device paths have optimized performance and which have non-optimized performance). If the operating system consistently sends I/O on a non-optimized path, then the storage device may transparently make that path optimized, improving performance and causing idle paths to become non-optimized.
Red Hat Enterprise Linux 5.4 introduces explicit ALUA support for Clariion storage (i.e. the operating system exchanges information with the storage device and is able to select the paths that have optimized performance). (BZ#482737)

[javier]

El equipo en el que estamos probando, el ibmblade26, está actualizado desde el día 12 a la última versión 5.6
Estuve probando un rato con esa versión pero parece que hay algo que no cuadra. De todas formas, sería interesante también probar a configurar la SAN en el "modo antiguo".

[tonin]

PRUEBA1

• Borro de /etc/multipath.conf cualquier configuración para quedarnos con la configuración por defecto de emc.
• Configuro en "conectivity status" los caminos a ibmblade26 como CLAROPEN, FailOver? 1, LUNZ compatibility e Id Array.

Tras hacer multipath -F y multipath -r, multipath -ll devuelve los caminos como ready todos, 2 de ellos como active y dos de ellos como failed. Al hacer tresspass de la LUN, los active y failed se invierten.

Es más o menos el comportamiento anterior, solo que en este caso no aparecen agrupados por HBA sino en un solo grupo, pero esto es debido a que "path_grouping_policy" está en multibus (todos los paths en un grupo de prioridad).

Meto de nuevo en multipath.conf una configuración específica, poniendo group_by_prio y los handlers de emc en lugar de alua y sale como a Javier le gusta ...

[tonin]

Volvemos a darle a start a la sesión de sancopy para que ponga en el vnx el estado original de dicha LUN, arrancamos y va correctamente.

Por tanto lo dejamos así en la migración, con compatibilidad con lo anterior para no tener que modificar imágenes.

NOTA: Me dice Javier que cambiando el path_checker de readsector0 a TUR iva bien en el modo ALUA, aunque el resto de handlers se dejan como emc en lugar de alua.