Detección de fallos y reparaciones 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.

Tipos de detección de fallos en IPMP

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 sin utilizar direcciones de prueba

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

• Sondeos ICMP

  Las interfaces activas en el grupo 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 en el grupo 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.

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 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). El valor predeterminado del tiempo de detección de fallos es de 10 segundos. Sin embargo, puede ajustar el tiempo de detección de fallos en el archivo de configuración de 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 de múltiples rutas. 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, in.mpathd 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 in.mpathd no encuentra enrutadores ni hosts que respondan a sondeos de multidifusión, los paquetes de eco ICMP in.mpathd no pueden detectar fallos basados en sondeos. En este caso, la utilidad 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 para la detección de fallos basada en sondeos.

Fallo de grupo

Un fallo de grupo tiene lugar 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á habilitada, 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, una sola interfaz que puede sondear la interfaz activa se designarán como encargado de los sondeos. Esta interfaz designada tendrá el indicador FAILED y PROBER. La dirección de datos está vinculada a esta interfaz que 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á habilitada, 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 el resultado 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.

Estos 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 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 habilitar el seguimiento de interfaces que no forman parte de un grupo IPMP, consulte Cómo configurar el comportamiento del daemon IPMP.

Detección de reparaciones de interfaces físicas

El tiempo de detección de reparaciones es el doble del tiempo de detección de fallos. El tiempo predeterminado para la detección de fallos es de 10 segundos. En consecuencia, el tiempo predeterminado de detección de reparaciones es de 20 segundos. Después de que una interfaz con fallos se ha marcado con el indicador RUNNING de nuevo y el método de detección de fallos ha detectado la reparación, in.mpathd borra el indicador FAILED de la interfaz. La interfaz reparada se vuelve a implementar en función del número de interfaces activas que el administrador ha definido originalmente.

Cuando una interfaz subyacente falla y se utiliza la detección de fallos basada en sondeos, el daemon in.mpathd sigue sondeando, ya sea mediante un encargado de sondeos cuando no se configuró ninguna dirección de prueba o mediante direcciones de prueba de la interfaz. Durante una reparación de interfaz, la restauración continúa en función de la configuración original de la interfaz con fallos:

• La interfaz con fallos era originalmente una interfaz activa: la interfaz reparada vuelve a su estado activo original. La interfaz en espera que funcionaba como un reemplazo durante el fallo se vuelve a cambiar al estado en espera si hay suficientes interfaces que están activas para el grupo según el administrador del sistema.

  ---

  Nota - Una excepción a este paso son los casos en que la interfaz activa reparada también está configurada con el modo FAILBACK=no. Para obtener más información, consulte El modo FAILBACK=no

  ---

• La interfaz con fallos era originalmente una interfaz en espera: la interfaz reparada vuelve a su estado en espera original, siempre que el grupo IPMP refleje el número original de interfaces activas. De lo contrario, la interfaz en espera se cambia para convertirse en una interfaz activa.

Para ver una presentación gráfica de cómo IPMP se comporta durante el fallo y la reparación de la interfaz, consulte Cómo funciona IPMP.

El modo FAILBACK=no

De manera predeterminada, las interfaces activas que han presentado fallos y se han reparado vuelven automáticamente a convertirse en interfaces activas en el grupo. Este comportamiento es controlado por la configuración del parámetro FAILBACK en el archivo de configuración del daemon. Sin embargo, es posible que incluso la interrupción insignificante que se genera a medida que las direcciones de datos son reasignadas a interfaces reparadas no sea aceptable para algunos administradores. Es posible que los administradores prefieran permitir que una interfaz en espera activada continúe como una interfaz activa. IPMP permite a los administradores reemplazar el comportamiento predeterminado para evitar que una interfaz se active automáticamente después de su reparación. Estas interfaces deben estar configuradas en el modo FAILBACK=no. Para conocer procedimientos relacionados, consulte Cómo configurar el comportamiento del daemon IPMP.

Cuando una interfaz activa en el modo FAILBACK=no falla y subsecuentemente se repara, el daemon IPMP restaura la configuración IPMP de la siguiente manera:

• El daemon conserva el estado INACTIVE de la interfaz, siempre que el grupo IPMP refleje la configuración original de interfaces activas.

• Si la configuración IPMP en el momento de la reparación no refleja la configuración original del grupo de interfaces activas, la interfaz reparada se vuelve a desplegar como una interfaz activa, a pesar del estado FAILBACK=no.