Funciones de detección de fallos IPMP y recuperación

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

Detección de fallos basada en vínculos, si la admite el controlador de la NIC
Detección de fallos basada en sondeos, cuando se configuran las direcciones de prueba
Detección de interfaces que no estaban presentes durante el inicio

La página del comando man in.mpathd(1M) describe detalladamente el modo en que el daemon in.mpathd controla la detección de fallos de la interfaz.

Detección de fallos basada en vínculos

La detección de fallos basada en vínculos siempre está activada, cuando la interfaz admite este tipo de detección de fallos. En la versión actual de Oracle Solaris se admiten los siguientes controladores de red de Sun:

hme
eri
ce
ge
bge
qfe
dmfe
e1000g
ixgb
nge
nxge
rge
xge

Para determinar si la interfaz de otro proveedor admite la detección de fallos basada en vínculos, consulte la documentación del fabricante.

Estos controladores de interfaces de red supervisan el estado del vínculo 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 detecta que el indicador RUNNING de la interfaz se ha borrado, el daemon rechaza inmediatamente la interfaz.

Detección de fallos basada en sondeos

El daemon in.mpathd lleva a cabo la detección de fallos basada en sondeos en cada interfaz del grupo IPMP que cuente con una dirección de prueba. La detección de fallos basada en sondeos implica enviar y recibir los mensajes de sondeo de ICMP que utilizan direcciones de prueba. Estos mensajes pasan por la interfaz y se dirigen a uno o más sistemas de destino del mismo vínculo IP. Para ver una introducción a las direcciones de prueba, consulte Direcciones de prueba. Si desea información sobre cómo configurar las direcciones de prueba, consulte Cómo configurar un grupo IPMP con múltiples interfaces.

El daemon in.mpathd determina qué sistemas de destino se sondean dinámicamente. Los enrutadores conectados al vínculo IP se seleccionan automáticamente como destinos para el sondeo. Si no hay enrutadores en el vínculo, in.mpathd envía sondeos a los hosts vecinos del vínculo. Un paquete multidifusión que se envía a la dirección multidifusión de todos los hosts, 224.0.0.1 en IPv4 y ff02::1 en IPv6, determina qué hosts se utilizarán como sistemas de destino. Los primeros hosts que responden a los paquetes echo se eligen como destinos para los sondeos. Si in.mpathd no encuentra enrutadores ni hosts que respondan a los paquetes echo ICMP, in.mpathd no puede detectar los fallos basados en sondeos.

Puede utilizar las rutas host para configurar explícitamente una lista de sistemas de destino para utilizar con el comando in.mpathd. Para obtener más información, consulte Configuración de sistemas de destino.

Para asegurarse de que cada interfaz del grupo IPMP funcione correctamente, in.mpathd sondea todos los destinos por separado mediante todas las interfaces del grupo IPMP. Si no hay ninguna respuesta a cinco sondeos consecutivos, 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. Puede ajustar el tiempo de detección de fallos en el archivo /etc/default/mpathd. Para obtener instrucciones, consulte Cómo configurar el archivo /etc/default/mpathd.

Para un tiempo de detección de reparaciones de 10 segundos, la velocidad de sondeo es de aproximadamente un sondeo cada dos segundos. El tiempo mínimo de detección de reparaciones predeterminado es el doble del tiempo de detección de fallos, es decir, 20 segundos, ya que debe recibirse la respuesta de 10 sondeos consecutivos. Los tiempos de detección de fallos y reparaciones sólo se aplican a la detección de fallos basada en sondeos.

Nota - En un grupo IPMP compuesto por redes VLAN, la detección de fallos basada en vínculos se implementa por vínculos físicos y, por lo tanto, afecta a todas las redes VLAN del vínculo en cuestión. La detección de fallos basada en sondeos se realiza por vínculos VLAN. Por ejemplo, bge0/bge1 y bge1000/bge1001 se configuran en un mismo grupo. Si el cable para bge0 está desconectado, la detección de fallos basada en vínculos no indicará que bge0 y bge1000 hayan fallado de manera inmediata. Sin embargo, si no se puede alcanzar ningún destino de sondeo de bge0, sólo se indicará que ha fallado bge0, porque bge1000 tiene sus propios destinos de sondeo en su red VLAN.

Fallos de grupo

Un fallo de grupo tiene lugar cuando todas las interfaces de un grupo IPMP fallan al mismo tiempo. El daemon in.mpathd no lleva a cabo conmutaciones por error para un fallo de grupo. Asimismo, no se puede realizar ninguna conmutación por error si todos los sistemas de destino fallan de forma simultánea. En este caso, in.mpathd vacía todos los sistemas de destino actuales y descubre nuevos sistemas de destino.

Detección de reparaciones de interfaces físicas

Para que el daemon in.mpathd considere que se ha reparado una interfaz, el indicador RUNNING debe estar configurado para la interfaz. Si se utiliza la detección de fallos basada en sondeos, el daemon in.mpathd debe recibir respuestas a 10 paquetes de sondeos consecutivos de la interfaz antes de que ésta se considere como reparada. Cuando una interfaz se considera reparada, cualquier dirección que conmutaba por error a otra interfaz, se recuperará tras el error a la interfaz reparada. Si la interfaz estaba configurada como "activa" antes de que fallara, tras la reparación podrá seguir enviando y recibiendo tráfico.

Qué ocurre durante la conmutación por error de la interfaz

Los dos ejemplos siguientes muestran una configuración típica y cómo dicha configuración cambia automáticamente cuando falla una interfaz. Cuando falla la interfaz hme0, observe que todas las direcciones de datos pasan de hme0 a hme1.

Ejemplo 30-1 Configuración de la interfaz antes de un fallo

hme0: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> 
     mtu 1500 index 2
     inet 192.168.85.19 netmask ffffff00 broadcast 192.168.85.255
     groupname test
hme0:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> 
     mtu 1500 
     index 2 inet 192.168.85.21 netmask ffffff00 broadcast 192.168.85.255
hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
8     inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255
     groupname test
hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> 
     mtu 1500 
     index 2 inet 192.168.85.22 netmask ffffff00 broadcast 192.168.85.255
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
     inet6 fe80::a00:20ff:feb9:19fa/10
     groupname test
hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
     inet6 fe80::a00:20ff:feb9:1bfc/10
     groupname test

Ejemplo 30-2 Configuración de la interfaz después de un fallo

hme0: flags=19000842<BROADCAST,RUNNING,MULTICAST,IPv4,
      NOFAILOVER,FAILED> mtu 0 index 2
      inet 0.0.0.0 netmask 0 
      groupname test
hme0:1: flags=19040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,
      NOFAILOVER,FAILED> mtu 1500 index 2 
      inet 192.168.85.21 netmask ffffff00 broadcast 10.0.0.255
hme1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
      inet 192.168.85.20 netmask ffffff00 broadcast 192.168.85.255
      groupname test
hme1:1: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,
      NOFAILOVER> mtu 1500 
      index 2 inet 192.168.85.22 netmask ffffff00 broadcast 10.0.0.255
hme1:2: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 6
      inet 192.168.85.19 netmask ffffff00 broadcast 192.168.18.255
hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER,FAILED> mtu 1500 index 2
      inet6 fe80::a00:20ff:feb9:19fa/10 
      groupname test
hme1: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
      inet6 fe80::a00:20ff:feb9:1bfc/10 
      groupname test

Puede ver que el indicador FAILED aparece en hme0 para indicar que la interfaz ha fallado. Observe también que se ha creado hme1:2. hme1:2 era originalmente hme0. La dirección 192.168.85.19 se convierte en accesible mediante hme1.

Los miembros multidifusión asociados con 192.168.85.19 pueden seguir recibiendo paquetes, pero ahora los reciben mediante hme1. Cuando se produce el fallo de la dirección 192.168.85.19 de hme0 a hme1, se crea la dirección ficticia 0.0.0.0 en hme0. La dirección ficticia se crea para que se pueda seguir accediendo a hme0. hme0:1 no puede existir sin hme0. La dirección de prueba se elimina cuando tiene lugar una recuperación tras los errores.

De modo similar, se produce la conmutación por error de la dirección IPv6 de hme0 a hme1. En IPv6, los miembros de multidifusión se asocian con índices de interfaz. Los miembros de multidifusión también se conmutan por error de hme0 a hme1. También se mueven todas las direcciones configuradas por in.ndpd. Esta acción no se muestra en los ejemplos.

El daemon in.mpathd sigue realizando el sondeo a través de la interfaz fallida hme0. Cuando el daemon recibe 10 respuestas consecutivas para un tiempo de detección de reparaciones predeterminado de 20 segundos, determina que la interfaz se ha reparado. Dado que el indicador RUNNING también se establece en hme0, el daemon invoca la recuperación tras los errores. Después de la recuperación tras los errores, se restablece la configuración original.

Para ver una descripción de todos los mensajes de error registrados en la consola durante los fallos y las reparaciones, consulte la página del comando man in.mpathd(1M).

Omitir V�nculos de navegaci�n
Salir de la Vista de impresi�n
	Guía de administración del sistema: servicios IP