Détection de défaillance dans IPMP

Afin de garantir une disponibilité continue du réseau pour envoyer ou recevoir le trafic, IPMP effectue une détection de défaillance sur les interfaces d'IP sous-jacentes du groupe IPMP. Les interfaces défaillantes restent inutilisables jusqu'à ce qu'elles soient réparées. Les interfaces actives restantes continuent de fonctionner et les interfaces de secours sont déployées en fonction des besoins.

Le démon in.mpathd traite les types de détection de défaillance suivants :

• Détection de défaillance basée sur sonde, de deux types :

  • Aucune adresse de test n'est configurée (test transitif).

  • Des adresses de test sont configurées.

• Détection de défaillance basée sur les liaisons (si le pilote de carte réseau prend en charge cette fonction)

Détection de défaillance basée sur sonde

La détection de défaillance basée sur sonde consiste à utiliser des sondes ICMP pour vérifier si une interface a échoué. L'implémentation de cette méthode de détection de défaillance dépend de l'utilisation d'adresses de test.

Détection de défaillance basée sur sonde avec des adresses de test

Cette méthode de détection de défaillance repose sur l'envoi et la réception de messages de sonde ICMP utilisant des adresses de test. Ces messages (également appelés trafic de sonde ou trafic de test) sont envoyés de l'interface à un ou plusieurs systèmes cible sur le même réseau local. Le démon in.mpathd examine toutes les cibles séparément par le biais toutes les interfaces configurées pour la détection de défaillance basée sur sonde. Si, après cinq tests consécutifs sur une interface donnée, aucune réponse n'est obtenue, in.mpathd considère que l'interface est en panne. La fréquence des tests dépend du temps de détection de défaillance (FDT). Le temps de détection de défaillance par défaut est de 10 secondes. Cependant, vous pouvez régler le temps de détection de défaillance dans le fichier de configuration IPMP. Pour plus d'informations, reportez-vous à la section Configuration du comportement du démon IPMP .

Pour optimiser la détection de défaillance basée sur sonde, il faut définir plusieurs systèmes cible pour recevoir les sondes du démon in.mpathd. En présence de plusieurs systèmes cibles, vous pouvez mieux déterminer la nature d'une défaillance signalée. Par exemple, l'absence d'une réponse de la part de l'unique système défini peut indiquer une défaillance dans le système cible ou dans l'un des interfaces du groupe IPMP. En revanche, si un seul système entre plusieurs systèmes cible ne répond pas à une sonde, alors la défaillance l'échec est probablement dans le système cible plutôt que dans le groupe IPMP lui-même.

Le démon in.mpathd détermine les systèmes cible à analyser de façon dynamique. Tout d'abord, le démon recherche dans la table de routage les systèmes cible sur le même sous-réseau que les adresses de test associées aux interfaces du groupe IPMP. Si de telles cibles sont trouvées, le démon les utilise comme cibles pour les tests. Si aucune cible n'est trouvée sur le même sous-réseau, le démon envoie des paquets de multidiffusion pour tester les hôtes voisins sur la liaison. Le paquet de multidiffusion est envoyé à l'adresse de multidiffusion de tous les hôtes (224.0.0.1 dans IPv4 et ff02::1 dans IPv6) pour déterminer les hôtes à définir en tant que systèmes cible. Les cinq premiers hôtes qui répondent aux paquets d'écho sont sélectionnés en tant que cibles pour les sondes. Si le démon ne parvient pas à trouver des routeurs ou des hôtes ayant répondu aux tests de multidiffusion, le démon ne peut pas assurer la détection de défaillance basée sur sonde. Dans ce cas, la commande ipmpstat -i indique que la sonde présente l'état unknown.

Vous pouvez établir de façon explicite à l'aide de routes d'hôte la liste des systèmes cible que le démon in.mpathd doit utiliser. Pour obtenir des instructions, reportez-vous à la section Configuration de la détection de défaillance basée sur sonde.

Détection de défaillance basée sur sonde sans utiliser d'adresses de test

Sans adresse de test, cette méthode est implémentée à l'aide de deux types de sondes :

• Sondes ICMP

  Les sondes ICMP sont envoyées par les interfaces actives du groupe IPMP pour tester les cibles définies dans la table de routage. Une interface active désigne une interface sous-jacente qui peut recevoir des paquets IP entrants envoyés à l'adresse de couche de liaison (L2) de l'interface. La sonde ICMP utilise l'adresse de données comme adresse source de la sonde. Si la sonde ICMP atteint sa cible et obtient une réponse à partir de la cible, alors l'interface active est opérationnelle.

• Sondes transitives

  Les sondes transitives sont envoyées par d'autres interfaces du groupe IPMP pour tester l'interface active. Une interface alternative est une interface sous-jacente qui n'est ne reçoit pas activement des paquets IP entrants.

  Par exemple, prenons le cas d'un groupe IPMP composé de quatre interfaces sous-jacentes. Le groupe est configuré avec une adresse de données mais aucune adresse de test. Dans cette configuration, les paquets sortants peuvent utiliser toutes les interfaces sous-jacentes. Cependant, les paquets entrants peuvent uniquement être reçus par l'interface à laquelle l'adresse de données est liée. Les trois autres interfaces sous-jacentes qui ne peuvent pas recevoir les paquets entrants sont les interfaces alternatives.

  Si une interface alternative réussit à envoyer une sonde à une interface active et à recevoir une réponse, alors l'interface active est fonctionnelle, et par déduction, l'interface alternative qui a envoyé la sonde également.

Défaillance de groupe

Une défaillance de groupe survient lorsque toutes les interfaces d'un groupe IPMP tombent en panne au même moment. Dans ce cas, aucune interface sous-jacente n'est utilisable. De même, lorsque l'ensemble des systèmes cibles tombe en panne au même moment et que la détection de défaillance basée sur sonde est activée, le démon in.mpathd vide tous ses systèmes cibles et test de nouveaux systèmes cibles.

Dans un groupe IPMP qui n'a aucune adresse de test, une interface unique qui peut tester l'interface active est désignée comme "prober". Cette interface désignée porte les indicateurs FAILED et PROBER. L'adresse de données est liée à cette interface, ce qui lui permet de poursuivre le test de la cible pour détecter une récupération.

Détection de défaillance basée sur les liaisons

La détection de défaillance basée sur les liaisons est toujours activée, à condition que l'interface prenne ce type de détection en charge.

Pour déterminer si une interface tierce prend en charge la détection de défaillance basée sur les liaisons, utilisez la commande ipmpstat -i. Si la sortie d'une interface donnée indique l'état unknown dans la colonne LINK, l'interface ne prend pas en charge la détection de défaillance basée sur les liaisons. Reportez-vous à la documentation du fabricant pour obtenir des informations plus spécifiques sur le périphérique.

Les pilotes réseau qui prennent en charge la détection de défaillance basée sur les liaisons contrôlent l'état de la liaison de l'interface et notifient le sous-système de mise en réseau en cas de changement d'état. En fonction de la situation, le sous-système de mise en réseau définit ou efface alors l'indicateur RUNNING de cette interface. Si le démon in.mpathd détecte que l'indicateur RUNNING de l'interface a été effacé, il considère immédiatement que l'interface est en panne.

Détection de défaillance et fonction de groupe anonyme

IPMP prend en charge la détection de défaillance dans un groupe anonyme. Par défaut, IPMP surveille l'état uniquement d'interfaces qui appartiennent à des groupes IPMP. Cependant, le démon IPMP peut être configuré de façon à également assurer le suivi du statut des interfaces qui n'appartiennent à aucun groupe IPMP. Par conséquent, ces interfaces sont considérées comme faisant partie d'un “groupe anonyme”. Lorsque vous exécutez la commande ipmpstat -g, le groupe anonyme est affiché sous forme de double-tirets (--). Dans les groupes anonymes, les adresses de données des interfaces fonctionnent également comme adresse de test. Comme ces interfaces n'appartiennent pas à un groupe IPMP nommé, ces adresses sont visibles pour les applications. Pour activer le suivi des interfaces qui ne font pas partie d'un groupe IPMP, reportez-vous à la section Configuration du comportement du démon IPMP .