Multitrayectos para Gentoo

1.  Introducción

Los servicios de multitrayecto se despliegan generalmente en entornos empresariales para proporcionar los medios para almacenamiento de alto desempeño, con balanceo de carga y tolerante a fallas, localmente o via red de área de almacenamiento (en inglés SAN). El multitrayecto facilita que un único dispositivo de almacenamiento tenga acceso transparente a través de uno o más trayectos. Por ejemplo, si disponemosde dos conexiones desde un adaptador bus anfitrión (en inglés HBA) a dos switches de canal de fibra y de ahí a un SAN, al cargar el módulo y escanear el bus, leerá cuatro trayectos al SAN: los trayectos del HBA del servidor desde y hacia cada switch de canal de fibra en el dispositivo de almacenamiento. Para sacarle ventaja a esta situación, el multitrayecto permite usar cada trayecto de manera simultánea o independientemente para asegurar una conexión constante y fiable a los datos almacenados. El multitrayecto proporciona una sustitución en caso de fallo para todas las conexiones en caso de la pérdida de un trayecto, permitiendo la disponibilidad constante a datos críticos, dada la redundancia en el diseño e implementación.

En el sentido más básico, el multitrayecto está compuesto de dos partes: device-mapper y multipath-tools. El mapeador de dispositivos (en inglés device mapper) es el primer elemento clave de esta aplicación. Los administradores de sistemas probablemente conocerán el mapeador de dispositivos por LVM, EVMS, dm-crypt, o en este caso, multitrayectos. En pocas palabras, trabajar con el mapeador de dispositivos en el espacio del núcleo toma un dispositivo de bloque como /dev/sda (todos los objetivos basados en SAN serán algún tipo de dispositivo SCSI) y lo mapea a otro dispositivo.

En un nivel más bajo, el mapeador de dispositivos crea un dispositivo de bloque virtual que acepta todos los comandos que aceptaría un dispositivio de bloque normal, pero pasa los datos al dispositivo de bloque verdadero. Como hemos dicho anteriormente, el proceso de mapeo se maneja en el espacio del núcleo, no del usuario.

Las herramientas multitrayecto son un conjunto de herramientas que operan en el espacio de usuarios que interactúa con las herramientas de mapeo de dispositivos, creando estructuras para el manejo de dispositivos e implementando E/S multitrayecto a nivel del sistema operativo. En un entorno SAN típico, dispondremos de múltiples trayectos para el mismo dispositivo de almacenamiento: una tarjeta de canal de fibra (o dos) en el servidor, que se conecta a un switch que a su vez conecta al propio dispositivo (tal como explicamos en el escenario referido anteriormente). Así, los administradores de sistema posiblemente podrían ver el mismo dispositivo hasta cuatro veces en esta situación (cada tarjeta vería el LUN dos veces, una vez por cada trayecto disponible). De manera que, un único disco duro podría ser reconocido como sda, sdb, sdc y sdd. Por ejemplo, si fuéramos a montar /dev/sda en /san1, estaríamos usando un único trayecto de una tarjeta de canal de fibra al switch y luego a puerto en el mismo dispositivo de almacenamiento. Si alguno de estos puntos fallara, podría perder súbitamente el acceso al dispositivo de almacenamiento y tener que desmontarlo y montar otro (sdb).

Consecuentemente, este escenario dista mucho de ser ideal ya que se está usando solo un trayecto de cuatro posibilidades. En este punto es donde se vislumbra el beneficio de las herramientas multitrayecto y de mapeo de dispositivos. Como hemos explicado antes, el mapeador de dispositivos crea dispositivos de bloque virtuales que pasan información a los verdaderos dispositivos.

2.  Instalación y Configuración

Instalación y Herramientas

Debemos hacer emerge multipath-tools y sg3_utils. Necesitamos encontrar el wwid del disco. Para esto usaremos sg_vpd (provisto por el paquete sg3_utils).

# emerge multipath-tools sg3_utils
(Reemplace /dev/DISPOSITIVO con el disco para obtener su wwid)
# /usr/bin/sg_vpd --page=di /dev/DISPOSITIVO

Donde DISPOSITIVO representa el dispositivo sd, el ID regresará con un 0x6. Reemplace 0x con 3 y obtendrá el ID correcto para suministrar al argumento wwid multitrayecto en el archivo /etc/multipath.conf. Más sobre esto en el siguiente capítulo.

Configuración de Gentoo para usar multitrayectos

Para configurar Gentoo para usar multitrayectos, el núcleo necesita activar las siguiente opciones:

Device Drivers  --->
  SCSI device support  --->
    <*> SCSI target support
    <*> SCSI disk support
    [*] Probe all LUNs on each SCSI device
  [*] Multiple devices driver support (RAID and LVM)  --->
    <*>  Multipath I/O support
    <*>  Device mapper support
    <*>    Multipath target
        (Seleccione su dispositivo de la lista))
    <*>      EMC CX/AX multipath support  
    <*>      LSI/Engenio RDAC multipath support  
    <*>      HP MSA multipath support

En el menú de configuración del núcleo, active CONFIG_SCSI_MULTI_LUN=y para asegurar que el subsistema SCSI pueba sondear todos los Números Lógicos de Unidad o LUNs (Esto es recomendado, ya que el barrido concluirá luego del ID 0 si tiene un dispositivo cuyo ID es 0 ninguno en 1 y otro con ID 2. Dicho simplemente, obtendrá el dispositivo con ID 0 pero no el de 2.) o cualquier dispositivo necesario para SCSI, como una tarjeta QLogic 2400, que se encuentra en la sección de controladores SCSI de bajo nivel.

Para poder comprender mejor, considere los siguientes escenarios:

Habrán tres discos con ID 0, 1 y 2. Sin activar el sondeo de todos los LUNs (probe all LUNs), serán visibles los IDs 0, 1 y 2 como sda, sdb y sdc - todos los dispositivos son visibles. Si borramos el disco ID 1, todavía serán visibles los IDs 0 y 2. Tal vez crea que tenga sentido ver a sda y sdb ahora (sdc cambiaría a sdb ya que no hay dispositivo allí). Sin embargo, al no sondear todos los LUNs, el comportamiento será el siguiente:

Escenario 1: Sin el sondeo de todos los LUNs, el barrido empezará, comprobándose el ID 0, el cual será asignado a sda, continuándose el barrido buscando a ID 1. Al no detectarse nada allí, el barrido se detiene y se considerará completo y que todos los dispositivos han sido detectados aunque haya un dispositivo en ID 2 o en subsecuentes IDs. Reinicie el equipo para el siguiente escenario.

Escenario 2: Si el sondeo de todos los LUNs está activado, el barrido comienza y se detecta el ID 0. A este ID se le asigna el sda y el barrido continua al siguiente dispositivo. Si no se detecta algo en el ID 1, el barrido continua buscando otros dispositivos. El ID 2 será localizado y asignado a sdb. Si no se detectan más dispositivos (IDs) más allá, el barrido se considerará completo.

Así que, una vez sondeados todos los LUNs, serán reconocidos todos los dispositivos y se le asignará sus ID multitrayecto.

3.  Resumen de Arquitectura

Como parte de las herramientas multitrayecto hay grupos de prioridad ocupados por los dispositivos mencionados anteriormente. Después de configurar multipath-tools e iniciarlos con /etc/init.d/multipath start, puede listar los grupos con multipath -l. La salida se parecerá a:

EVA_SAN (3600508b4001044ee00013000031e0000)
[size=300 GB][features="1 queue_if_no_path"][hwhandler="0"]
\_ round-robin 0 [active]
\_ 0:0:0:1 sda 8:0  [active]
\_ round-robin 0 [enabled]
\_ 0:0:1:1 sdb 8:16 [active]

EVA_SAN2 (3600508b4001044ee0001300003880000)
[size=300 GB][features="1 queue_if_no_path"][hwhandler="0"]
\_ round-robin 0 [active]
\_ 0:0:0:2 sdc 8:32 [active]
\_ round-robin 0 [enabled]
\_ 0:0:1:2 sdd 8:48 [active]

De manera predeterminada, seleccionará el primer grupo prioritario (el primer de arriba en secuencia round robin para EVA_SAN2, por ejemplo, siendo sdc). En este caso, debido a la secuencia round robin rebotará entre dispositivos. Si uno de los trayectos fuera a fallar, toda la información continuaría por el otro trayecto. Solo fallaría si todos los dispositivos en un trayecto fallan, pasando al segundo grupo prioritario.

Configuración Típica

Una configuración típica multitrayecto se parece a:

defaults {
udev_dir                /dev
polling_interval        15
selector                "round-robin 0"
path_grouping_policy    group_by_prio
failback                5
path_checker            tur
prio_callout            "/sbin/mpath_prio_tpc /dev/%n"
rr_min_io               100
rr_weight               uniform
no_path_retry           queue
user_friendly_names     yes
}
blacklist {
devnode cciss
devnode fd
devnode hd
devnode md
devnode sr
devnode scd
devnode st
devnode ram
devnode raw
devnode loop
devnode sda
}

multipaths {
multipath {
wwid
(Para encontrar el wwid, por favor use /usr/bin/sg_vpd --page=di /dev/DISPOSITIVO.
La dirección será en forma de 0x6. Reemplace el 0x con un 3.)
alias DB_SAN
}
devices {
device {
(El espacio en blanco es importante en los siguientes dos casos para igualar las especificaciones del proveedor.)
"IBM     "
"1815      FAStT "
}
}
}

Una configuración típica de multitrayectos usando un EVA_SAN donde la información del dispositivo está en el núcleo en lo que respecta detección de hardware de SAN, se vería así:

multipaths {
multipath {
wwid  3600508b4001044ee00013000031e0000
alias EVA_SAN
}
multipath {
wwid    3600508b4001044ee0001300003880000
alias   EVA_SAN2
}
}

4.  Estableciendo una Configuración Propia

Realizar una configuración multitrayecto es bastante sencillo, ya que el único archivo que requiere cambios es /etc/multipath.conf.

Para empezar, ajuste el intervalo de sondeo (en segundos) para establecer la frecuencia de verificación de la salud del trayecto.

Ajustaremos el selector a "round-robin 0".

El prio_callout puede ser bastante importante, por lo que hay un número de distintas prioridades para diferentes dispositivos, tales como:

• mpath_prio_alua
• mpath_prio_emc
• mpath_prio_hds_modular
• mpath_prio_netapp
• mpath_prio_tpc

La path_grouping_policy tiene unas cuantas opciones diferentes: failover, multibus, group_by_prio. La opción failover tendrá solo un disco por grupo prioritario. La opción multibus colocará todos los dispositivos en un solo grupo prioritario. La opción group_by_prio se le coloca un "valor de prioridad", de manera de agrupar los trayectos que tengan la misma prioridad, determinándose los valores de prioridad por llamada (en inglés callout).

A la opción no_path_retry se le coloca queue ya que la mayoría no quisieran que falle la transmisión de datos. Así que, si fallan todos los trayectos, los datos se colocarán en cola hasta que el dispositivo esté disponible de nuevo y en este momento enviará todo otra vez. Dependiendo de la transferencia, esto podría causar problemas de carga.

El parámetro rr_min_io es la cantidad de operaciones de E/S que intentadas por trayecto antes de cambiar a otro trayecto en el mismo grupo. Si sda y sdb estuviesen en el mismo grupo, rr_min_io haría 100 operaciones de E/S con sda luego 100 más con sdb, repitiendo así hasta el final. Este es un parámetro para afinar para cada caso, ya que la carga de datos y los tamaños de las transferencias/peticiones varían por empresa. El valor predeterminado del caso es 1000, aunque algunos pueden preferir valores menores para cambiar puertos de switch con más frecuencia, de ser posible.

Los user_friendly_names hacen más fácil determinar con cuál dispositivo se está trabajando. Por ejemplo, si configura user_friendly_names a no, entonces verá los WWID en vez de EVA_SAN para los dispositivos.

El contenido de este documento, a no ser que se especifique expresamente, está registrado bajo los términos de la licencia CC-BY-SA-2.5. Se aplican las Pautas de Utilización del logotipo y nombre de Gentoo.