Administración de redes TCP/IP, IPMP y túneles IP en Oracle® Solaris 11.2

Salir de la Vista de impresión

Actualización: Julio de 2014
 
 

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, el daemon 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 instrucciones, consulte 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 y una dirección de datos. 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.


Notas -  En Oracle Solaris, la detección de fallos basada en sondeos funciona con las direcciones de prueba. Para seleccionar la detección de fallos basada en sondeos sin direcciones de prueba, debe activar manualmente el sondeo transitivo. Para obtener instrucciones, consulte Selección de un método de detección de fallos.

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.