Detección de fallos en IPMP

Para garantizar la disponibilidad continua de la red para enviar o recibir tráfico, IPMP realiza una detección de fallos en las interfaces IP subyacentes del grupo IPMP. Las interfaces con fallos siguen sin poder utilizarse hasta que se hayan reparado. Las interfaces activas restantes siguen funcionando mientras que las interfaces en espera se implementan según sea necesario.

El daemon in.mpathd controla los siguientes tipos de detección de fallos:

• Detección de fallos basada en sondeos, de dos tipos:

  • No se configuran direcciones de prueba (sondeo transitivo).

  • Se configuran las direcciones de prueba.

• Detección de fallos basada en enlaces, si la admite el controlador de la NIC.

Detección de fallos basada en sondeos

La detección de fallos basada en sondeos consiste en utilizar los sondeos ICMP para comprobar si una interfaz ha fallado. La implementación de este método de detección de fallos depende de si las direcciones de prueba se utilizan o no.

Detección de fallos basada en sondeos utilizando direcciones de prueba

Este método de detección de fallos implica enviar y recibir mensajes de sondeo de ICMP que utilizan direcciones de prueba. Estos mensajes, también denominados tráfico de sondeo o tráfico de prueba, pasan por la interfaz y se dirigen a uno o más sistemas de destino de la misma red local. El daemon in.mpathd sondea todos los destinos por separado mediante todas las interfaces que se han configurado para la detección de fallos basada en sondeos. Si no hay ninguna respuesta a cinco sondeos consecutivos en una interfaz específica, in.mpathd considera que la interfaz ha fallado. La velocidad de sondeo depende del tiempo de detección de fallos (FDT, Failure Detection Time). El valor predeterminado del tiempo de detección de fallos es de 10 segundos. Sin embargo, puede ajustar el FDT en el archivo de configuración IPMP. Para obtener instrucciones, vaya a Cómo configurar el comportamiento del daemon IPMP.

Para optimizar la detección de fallos basada en sondeos, debe establecer varios sistemas de destino para recibir los sondeos del daemon in.mpathd. Teniendo múltiples sistemas de destino, puede determinar mejor la naturaleza de un fallo informado. Por ejemplo, la ausencia de una respuesta del único sistema de destino definido puede indicar un fallo en el sistema de destino o en una de las interfaces del grupo IPMP. Por el contrario, si sólo un sistema entre varios sistemas de destino no responde a un sondeo, es probable que el fallo se encuentre en el sistema de destino en lugar de en el grupo IPMP en sí.

El daemon in.mpathd determina qué sistemas de destino se deben sondear dinámicamente. En primer lugar, el daemon busca la tabla de enrutamiento para sistemas de destino en la misma subred de las direcciones de prueba que están asociadas a las interfaces del grupo IPMP. Si estos destinos se encuentran, el daemon los utiliza como destinos para el sondeo. Si no se encuentran sistemas de destino en la misma subred, el daemon envía paquetes de multidifusión para sondear hosts vecinos en el enlace. Un paquete multidifusión se envía a la dirección de multidifusión de todos los hosts, 224.0.0.1 en IPv4 y ff02::1 en IPv6, para determinar qué hosts se utilizarán como sistemas de destino. Los primeros hosts que responden a los paquetes de eco se eligen como destinos para los sondeos. Si el daemon no encuentra enrutadores ni hosts que respondan a los sondeos de multidifusión, el daemon no puede detectar los fallos basados en sondeos. En este caso, el comando ipmpstat -i informará el estado de sondeo como unknown.

Puede utilizar las rutas host para configurar explícitamente una lista de sistemas de destino para utilizar con el comando in.mpathd. Para obtener instrucciones, consulte Configuración de detección de fallos basada en sondeos.

Detección de fallos basada en sondeos sin utilizar direcciones de prueba

Sin direcciones de prueba, este método se implementa con dos tipos de sondeos:

• Sondeos ICMP

  Las interfaces activas del grupo IPMP envían los sondeos ICMP para sondear destinos definidos en la tabla de enrutamiento. Una interfaz activa es la interfaz subyacente que puede recibir los paquetes IP entrantes dirigidos a la dirección de capa de enlace (L2) de la interfaz. El sondeo ICMP utiliza la dirección de datos como dirección de origen del sondeo. Si el sondeo ICMP alcanza su destino y obtiene una respuesta del mismo, la interfaz activa está en funcionamiento.

• Sondeos transitivos

  Las interfaces alternativas del grupo IPMP envían sondeos transitivos para sondear la interfaz activa. Una interfaz alternativa es una interfaz que no recibe activamente paquetes IP entrantes.

  Por ejemplo, considere un grupo IPMP que consta de cuatro interfaces subyacentes. El grupo se configura con una dirección de datos pero no direcciones de prueba. En esta configuración, los paquetes salientes pueden utilizar todas las interfaces subyacentes. Sin embargo, los paquetes entrantes sólo se pueden recibir mediante la interfaz a la que la dirección de datos está vinculada. Las tres interfaces subyacentes restantes que no pueden recibir paquetes entrantes son las interfaces alternativas.

  Si una interfaz alternativa puede enviar correctamente un sondeo para una interfaz activa y recibir una respuesta, la interfaz activa está en funcionamiento y, por ende, también lo está la interfaz alternativa que ha enviado el sondeo.

Fallo de grupo

Los fallos de grupo se producen cuando todas las interfaces de un grupo IPMP fallan al mismo tiempo. En este caso, ninguna interfaz es utilizable. Además, cuando todos los sistemas de destino fallan al mismo tiempo y la detección de fallos basada en sondeos está activada, el daemon in.mpathd vacía todos sus sistemas de destino y sondeos actuales para los nuevos sistemas de destino.

En un grupo IPMP que no tiene direcciones de prueba, se designa una sola interfaz que pueda sondear la interfaz activa como encargado de los sondeos. Esta interfaz designada tiene establecido el indicador FAILED y también el indicador PROBER. La dirección de datos está vinculada con esta interfaz, lo cual permite a la interfaz continuar con el sondeo del destino para detectar la recuperación.

Detección de fallos basada en enlaces

La detección de fallos basada en enlaces siempre está activada, cuando la interfaz admite este tipo de detección de fallos.

Para determinar si la interfaz de otro proveedor admite la detección de fallos basada en enlaces, utilice el comando ipmpstat -i. Si la salida de una interfaz dada incluye un estado unknown para su columna LINK, dicha interfaz no admite detección de fallos basada en enlaces. Consulte la documentación del fabricante para obtener más información específica sobre el dispositivo.

Los controladores de red que admiten la detección de fallos basada en enlaces supervisan el estado de enlace de la interfaz y notifican al subsistema de red si dicho estado cambia. Cuando se notifica un cambio, el subsistema de red establece o borra el indicador RUNNING para dicha interfaz, según sea preciso. Si el daemon in.mpathd detecta que el indicador RUNNING de la interfaz se ha borrado, el daemon hace fallar inmediatamente a la interfaz.

Detección de fallos y función del grupo anónimo

IPMP admite la detección de fallos en un grupo anónimo. De manera predeterminada, IPMP supervisa el estado sólo de interfaces que pertenecen a grupos IPMP. Sin embargo, el daemon IPMP se puede configurar también para realizar el seguimiento del estado de las interfaces que no pertenecen a ningún grupo IPMP. Por lo tanto, estas interfaces se consideran como parte de un “grupo anónimo”. Cuando emite el comando ipmpstat -g, el grupo anónimo se muestra como guión doble ( --). En los grupos anónimos, las interfaces tendrían sus direcciones de datos funcionando también como direcciones de prueba. Debido a que estas interfaces no pertenecen a un grupo IPMP denominado, estas direcciones son visibles a las aplicaciones. Para activar el seguimiento de interfaces que no forman parte de un grupo IPMP, consulte Cómo configurar el comportamiento del daemon IPMP.