miércoles, 26 de diciembre de 2012

AIX - Multipath I/O

Hola,
he recopilado documentación sobre el funcionamiento de MPIO en sistemas AIX que seguro que a alguien le viene bien.

¿Qué es MPIO?

El multipath I/O es la capacidad de tener redundancia de caminos a disco desde un equipo. Para entornos virtualizados, se necesitan al menos dos Virtual I/O Servers (VIOS) con adaptadores virtuales que serán mapeados desde las particiones cliente.

¿Qué es PCM?
PCM es el software que gestiona el multipath, es decir, se encarga del reconocimiento de los dispositivos de almacenamiento y de la gestión y monitorización de los caminos hacia los mismos.
  
Elección de "gestor" de MPIO
En AIX, existen varios paquetes distintos para gestionar el multipath:


Opción 1: AIXPCM o AIX default MPIOPCM (Multipathing Input/Output Path Control Module)

Opción 2: SDD (Subsystem Device Driver)

Opción 3: SDDPCM (Subsystem Device Driver Path Control Module) 

El primero es el paquete por defecto que viene con el SO de AIX y VIOS, mientras que los dos últimos son paquetes adicionales que el administrador de AIX, normalmente en conjunto con el responsable de storage, decidirá si instalar ya que ofrecen funcionalidades adicionales, tales como múltiples algoritmos de balanceo.

NOTA: Será necesario actualizar SDDPCM cuando se actualice el AIX.
https://www.ibm.com/developerworks/mydeveloperworks/blogs/anthonyv/entry/upgrading_aix_don_t_forget_sddpcm4?lang=en

Como mi intención en este post no es inventar la rueda sino unir conocimientos que, creo, están un poco dispersos en distintas páginas de IBM, no voy a pasar a traducir páginas que explican perfectamente que es cada cosa y su uso, por lo que dejo los enlaces necesarios para aprender la diferencia entre estos términos y escoger el tipo más adecuado en cada caso.

- AIXPCM or SDDPCM?
http://www.ibm.com/developerworks/aix/library/au-multipathing/index.html

- SDD for AIX:
http://www-01.ibm.com/support/docview.wss?uid=ssg1S4000065

- SDD Compatibility Matrix for ESS, DS8000, DS6000 and SVC storage systems.
http://www-01.ibm.com/support/docview.wss?uid=ssg1S7001350#AIXSDDPCM

- Multipath I/O for XIV storage systems.
https://www.ibm.com/developerworks/mydeveloperworks/blogs/anthonyv/entry/xiv_and_aix_part_one32?lang=en
 

Algoritmos y atributos
PCM puede ofrecer más de un algoritmo de routing, además de ayudar a recolectar información utilizada para determinar y seleccionar el mejor camino para cualquier solicitud de I/O.

La capacidad de health-checking de PCM permite lo siguiente:
- Chequear los caminos y determinar cuál puede utilizarse actualmente.
- Habilitar un camino que se marcó anteriormente como temporalmente caído.
- Chequear los caminos sin utilizar por si fuera necesario utilizarlos al aplicar un failover sobre el camino en uso.

Estas funcionalidades se configuran según ciertos atributos asociados a los dispositivos que podremos ver con el comando:

lsattr -El hdiskX

De entre todos los atributos que nos ofrece este comando, el funcionamiento de multipath depende de los que explicamos a continuación:
- algorithm: metodología de distribución de I/O por los caminos.
  • failover: sólo usa un camino cada vez. Si falla utiliza el siguiente según "path_priority".
  • round_robin: distribuye el tráfico escogiendo un camino cada vez y según "path priority".
  • load_balance: distribuye el tráfico escogiendo el camino con menor uso. 
- hcheck_mode: determina que caminos se chequearan si se utiliza la capacidad de "health checking".
  • Enabled: se evalua el healthcheck sobre caminos en estado "enabled".
  • Failed: se evalua el healthcheck sobre caminos en estado "failed".
  • Nonactive (default): se evalua el healthcheck sobre caminos sin I/O activo, incluidos los "failed".
- hcheck_interval: cada cuantos segundos se realiza el health checking en los caminos (0 para desactivar).
- dist_tw_width: ventana de tiempo en milisegundos durante la que se evalúa la cantidad de errores de I/O.
- dist_err_percent: define el porcentaje de "ventanas de tiempo" con error permitidas en un camino antes de ponerlo en "failed". Valor 0-100 (default 0).
- rw_timeout: tiempo de espera en segundos a que un comando responda.
- retry_timeout: tiempo de espera para que una operación de I/O que falló se repita.
- queue_depth: número de peticiones que se pueden encolar.
Para versiones de SDDPCM posteriores a 2.6.3 se añade el siguiente atributo:
-timeout_policy: 
  • retry_path: la primera ocurrencia de un timeout no pone el camino en “failed”. Cuando un healthcheck resulte satisfactorio recuperará el camino que se podrá utilizar inmediatamente.
  • fail_path: la primera ocurrencia de un timeout pone el camino en “failed”. Se necesitarán dos healthchecks satisfactorios consecutivos para habilitar de nuevo.
  • disable_path: la primera ocurrencia de un timeout pone el camino en “failed”. Si en un periodo de tiempo se dan errores de timeout continuos el camino será deshabilitado y la reactivación deberá hacerse de forma manual.

¿Cuándo se marcará un camino como "failed"?
Hay varias posibilidades para que un camino sea marcado como “failed”. Para detallarlas dividiremos en los tres tipos de comandos que son enviados a los dispositivos:

1. De I/O:
- Se mantiene un contador secuencial de errores que se incrementa con cada error de I/O, salvo alguna excepción.
- Se establece un “timestamp” con el primer error encontrado.
- Si se alcanza un determinado límite de número de errores secuenciales o se dan ciertos errores seguidos durante 60 seg. (rw_timeout), se marcará el camino como fallido.
  • Límite: aunque es un atributo del dispositivo se evalúa por path.
    • Límite=1.5·”queue depth”; si “queue depth” > 7
    • Límite=5+”queue depth”; si “queue depth” <= 7 
  • Errores dentro del periodo: un error seguido de un timeout o dos timeouts seguidos.

2. Health check:
- Dos errores consecutivos en la ejecución del comando “healthcheck” pondrán el camino como fallido. Pueden ser errores tanto SCSI Adapter como de buffer.
- También ocurrirá si el comando “inquiry” determina que una LUN no está disponible.

3. Inband:
- Se mantiene un contador de reintentos “inband” cuyo límite es 2.
- Si se alcanza el límite se marcará el camino como fallido.


Dicho esto, resaltar la importancia de subir el nivel de sddpcm a 2.6.3.x ya que la configuración de "timeout_policy=fail_path" mejorará sustancialmente el reconocimiento de caminos con errores y la recuperación, en caso posible, se realizará de forma mas segura.

Un saludo.

No hay comentarios:

Publicar un comentario