Cómo leer el estado multipath en un host Linux

Si su servidor guarda sus datos en una SAN, el informe de salud más importante de la máquina sale de un comando que la mayoría nunca ejecuta. multipath -ll le dice cuántos caminos llevan a su disco, cuáles de ellos prefiere la cabina, y si el host sobreviviría a perder uno. Así se lee, y qué cambiar cuando tiene mal aspecto.

La redundancia que no se ve no es redundancia

Cuando un camino muere en silencio, nadie lo nota. El host sigue funcionando con lo que queda, y la primera señal de problemas es el día en que se va el segundo camino y el volumen desaparece debajo de una base de datos. Un servidor entregado con el dispositivo multipath montado y nunca más revisado tiene redundancia solo sobre el papel. La comprobación lleva treinta segundos y debería formar parte de cada montaje, cada mantenimiento y cada revisión de incidente.

Leer la salida, línea a línea

Este es un ejemplo genérico de un host con dos puertos HBA y dos puertos de cabina en zoning por fabric:

mpatha (360002ac000000000000000000000abcd) dm-2 3PARdata,VV
size=50G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
 |- 1:0:0:1 sdb 8:16 active ready running
 |- 1:0:1:1 sdc 8:32 active ready running
 |- 2:0:0:1 sdd 8:48 active ready running
 `- 2:0:1:1 sde 8:64 active ready running

La primera línea da el nombre amigable, el WWID y las cadenas de fabricante y producto. El WWID es la identidad del volumen tal como la informa la cabina. Si alguna vez necesita demostrar qué volumen de la cabina es qué dispositivo Linux, compare esta cadena con el listado de volúmenes de la propia cabina, nunca con una letra de dispositivo, porque las letras cambian entre arranques.

La segunda línea contiene los ajustes que deciden el comportamiento ante un fallo. queue_if_no_path significa que si se pierden todos los caminos, la E/S espera en lugar de fallar. hwhandler='1 alua' significa que la cabina habla ALUA, la forma estándar en que una cabina le dice al host qué puertos prefiere.

La línea del grupo de caminos muestra la política de selección y la prioridad. Una cabina simétrica activo/activo como la del ejemplo pone todos los caminos en un grupo con la misma prioridad. Una cabina asimétrica muestra dos grupos: uno de mayor prioridad con los caminos optimizados marcado active, y otro de menor prioridad marcado enabled que solo lleva E/S si el primero falla. Ambas disposiciones son sanas. Lo que importa es que la disposición coincida con lo que el fabricante de su cabina documenta para su tipo de host.

Cada línea de camino se lee host:channel:target:lun, después el dispositivo, después tres estados. El primer número es el host SCSI, que en un servidor Fibre Channel significa el puerto HBA. Cada volumen debería mostrar caminos por los dos números de puerto HBA. Si todos los caminos de un volumen comparten un número de host, ese volumen es accesible por un solo fabric, diga lo que diga el esquema de cableado. Los tres estados son el estado del device-mapper (active o failed), el resultado del comprobador de caminos (ready, faulty, ghost) y la visión del kernel sobre el dispositivo (running u offline).

Un host sano, como lista de comprobación

• Cada volumen muestra el mismo número de caminos, y ese número es igual a puertos HBA por puertos de cabina en zoning por fabric.
• Cada volumen tiene caminos por los dos números de host HBA.
• Ningún camino está failed, faulty, offline ni shaky.
• La cadena de fabricante, el hardware handler y las prioridades coinciden con la guía de host del fabricante de la cabina, y el host está registrado en la cabina con la host persona o el tipo de host correspondiente.
• El comportamiento cuando se pierden todos los caminos (no_path_retry) se eligió a propósito, no se heredó.
• LVM usa solo los dispositivos multipath, nunca los caminos sd subyacentes.

Estos comandos le dan la imagen completa:

multipath -ll
multipathd show paths
multipathd show maps status
cat /sys/class/fc_host/host*/port_state
cat /sys/class/fc_host/host*/port_name

Para contar los caminos vivos por volumen de una vez:

multipath -ll | awk '/ dm-/{m=$1} /active ready/{c[m]++} END{for (k in c) print k, c[k]}'

Ejecútelo después de cada cambio de zoning, cada cambio en la cabina y cada reinicio. Un recuento que difiere entre volúmenes merece perseguirse hoy.

Los ajustes que más importan

La mayoría de las distribuciones traen una tabla integrada sensata de valores por defecto por cabina, pero la guía de host del fabricante de la cabina es la autoridad. Una sección de dispositivo típica tiene este aspecto:

defaults {
 user_friendly_names yes
 find_multipaths yes
}
devices {
 device {
 vendor "3PARdata"
 product "VV"
 path_grouping_policy group_by_prio
 prio alua
 hardware_handler "1 alua"
 path_checker tur
 failback immediate
 no_path_retry 18
 }
}

El único valor en el que merece la pena pensar por su cuenta es no_path_retry. Encolar durante un tiempo permite a un host aguantar un failover de controladora o un reinicio del fabric sin que un error de E/S llegue a la aplicación. Encolar para siempre puede congelar un host de base de datos de una forma más difícil de recuperar que un fallo limpio. Elija un número de reintentos que cubra con margen el tiempo de failover documentado de su cabina, anote por qué, y aplíquelo a todos los hosts de ese tipo.

El otro problema clásico es que LVM escanee los caminos sin procesar y se queje de volúmenes físicos duplicados. En sistemas actuales la lista de dispositivos (lvmdevices) o un filtro en lvm.conf que solo acepte dispositivos /dev/mapper lo resuelve. Los avisos de PV duplicado no son cosméticos: significan que LVM puede abrir un único camino en lugar del dispositivo multipath, y entonces ya no está protegido.

Pruebe el failover antes de necesitarlo

Un camino que nunca ha conmutado es una teoría. Antes de que un host lleve producción, quítele un camino y observe:

# terminal 1: keep reading from the volume
dd if=/dev/mapper/mpatha of=/dev/null bs=1M iflag=direct status=progress
# terminal 2: take one path offline, watch, then bring it back
echo offline > /sys/block/sdb/device/state
multipathd show paths
echo running > /sys/block/sdb/device/state
journalctl -k -f

La lectura del primer terminal debería continuar sin detenerse más que un instante. Cuando el camino vuelva, multipathd show paths debería devolverlo a active ready. Después haga la prueba mayor que importa: deshabilite el puerto del host en un fabric desde el switch, confirme que el volumen funciona solo con el otro fabric, restáurelo, confirme que vuelven todos los caminos, y repítalo para el segundo fabric. Si algún paso le sorprende, ha encontrado el problema una tarde tranquila en lugar de durante una caída.

Cómo lo hacemos nosotros

En nuestra plataforma, cada host conectado a la SAN, hipervisor o servidor dedicado, recibe un puerto HBA en cada uno de dos fabrics Fibre Channel independientes y se registra en nuestras cabinas HPE 3PAR all-flash con la persona que hace que ALUA se comporte exactamente como espera su sistema operativo. Cuando movemos un volumen en vivo entre cabinas, el host vuelve a escanear, ve sus nuevos caminos y sigue adelante, y el recuento de caminos es la prueba de que el movimiento está completo.

Si su salida de multipath no se parece al ejemplo sano de arriba, o no está seguro de cómo debería ser la suya, con gusto la leemos con usted.

cta: Hable con un ingeniero

Related

• /what-we-do/storage-compute/enterprise-san-storage/
• /what-we-do/storage-compute/fibre-channel-fabrics/
• /what-we-do/storage-compute/bare-metal-servers/