Détection de défaillance et de réparation 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 sont inutilisables jusqu'à ce qu'elles soient réparées. Les interfaces actives restantes continuent de fonctionner et les interfaces de réserve sont déployées en fonction des besoins.

Types de détection de défaillance dans IPMP

Le démon in.mpathd gère 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 la prise en charge est assurée par le pilote de la carte d'interface réseau.

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 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 dans le groupe pour tester les cibles qui sont définies dans la table de routage. Une interface active est l'interface sous-jacente qui peut recevoir les paquets IP entrants qui sont adressés à l'adresse de couche 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 les interfaces alternatives dans le groupe 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é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, partent de l'interface vers un ou plusieurs systèmes cible sur le même réseau local. Le démon examine toutes les cibles séparément à travers toutes les interfaces qui ont été 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 défaillante. La fréquence des tests dépend du temps de détection de défaillance. 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 d'IPMP. Pour plus d'informations, reportez-vous à la section Procédure de configuration du comportement du démon IPMP . Pour optimiser la détection de défaillance basée sur sonde, vous devez définir plusieurs systèmes cible pour recevoir les sondes à partir du démon de multipathing. 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 permet de déterminer les systèmes cible à analyser dynamiquement. Tout d'abord le démon recherche dans la table de routage les systèmes cibles sur le même sous-réseau que les adresses de test qui sont associées à l'interface 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, in.mpathd envoie des paquets de multidiffusion pour tester les hôtes voisins sur le lien. Le paquet multidiffusion envoyé à toutes les adresses d'hôtes multidiffusion, 224.0.0.1 dans IPv4 et ff02::1 dans IPv6, pour déterminer les hôtes à utiliser 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 in.mpathd ne trouve aucun routeur ou hôte ayant répondu aux sondes multidiffusion, puis aux paquets d'écho ICMP, in.mpathd ne pourra pas détecter les défaillances basées sur sonde. Dans ce cas, l'utilitaire ipmpstat -i signale l'état de la sonde comme unknown.

Vous pouvez utiliser des routes d'hôte afin de configurer de façon explicite une liste de systèmes cible en vue d'une utilisation par in.mpathd. Pour plus d'instructions, reportez-vous à la section Configuration pour la détection de défaillance basée sur sonde .

Défaillance de groupe

Une défaillance de groupe survient lorsque la totalité des interfaces d'un groupe IPMP sont défaillantes au même 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 sera 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 qui permet à l'interface de continuer le test de la cible pour détecter une restauration.

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 comprend un état unknown pour sa colonne LINK, alors que 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.

Ces 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 modification de l'é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 déclenche immédiatement une défaillance de l'interface.

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 fonctionnerait é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 Procédure de configuration du comportement du démon IPMP .

Détection de réparation d'interface physique

Le temps de détection de réparation est le double du temps de détection de défaillance. Le temps de détection de défaillance par défaut est de 10 secondes. Par conséquent, le temps détection de réparation par défaut est de 20 secondes. Une fois qu'une interface défaillante est de nouveau marquée par l'indicateur RUNNING et que la méthode de détection de défaillance l'a détecté comme réparée, in.mpathd efface l'indicateur FAILED de l'interface. L'interface réparée est redéployée en fonction du nombre d'interfaces actives que l'administrateur a définies à l'origine.

Lorsqu'une interface sous-jacente échoue et que la détection de défaillance basée sur sonde est utilisé, le démon in.mpathd poursuit le test, par le biais du prober désigné lorsqu'aucune adresse de test n'est configurée ou à l'aide de l'interface de l'adresse de test. Au cours d'une réparation d'interface, la restauration se poursuit en fonction de la configuration d'origine de l'interface défaillante :

• L'interface défaillante était une interface active à l'origine. L'interface réparée reprend son état actif initial. L'interface de réserve qui a fonctionné comme remplacement lors de la défaillance est passé en état de réserve si suffisamment d'interfaces sont actives pour le groupe, tel que défini par l'administrateur système.

  ---

  Remarque - Une exception à cette étape sont les cas où l'interface active réparée est également configurée avec le mode FAILBACK=no. Pour plus d'informations, reportez-vous à la section Mode FAILBACK=no.

  ---

• L'interface défaillante était à l'origine une interface de réserve : l'interface réparée revient à son état de réserve d'origine, à condition que le groupe IPMP reflète le nombre initial d'interfaces actives. Dans le cas contraire, l'interface de réserve est activée pour devenir une interface active.

Pour voir une présentation graphique du comportement d'IPMP pendant la défaillance et la réparation d'une interface, reportez-vous à la section Fonctionnement d'IPMP.

Mode FAILBACK=no

Par défaut, les interfaces actives qui ont échoué et ont ensuite été réparées, redeviennent automatiquement des interfaces actives dans le groupe. Ce comportement est contrôlé par la définition du paramètre FAILBACK dans le fichier de configuration du démon. Cependant, même les perturbations insignifiantes, qui se produisent lorsque les adresses de données sont remappées pour réparer des interfaces, peuvent ne pas être acceptable pour certains administrateurs. Les administrateurs peuvent préférer autoriser une interface secondaire activée pour continuer comme interface active. IPMP permet aux administrateurs d'ignorer le comportement par défaut pour empêcher une interface de devenir automatiquement active lors d'une réparation. Ces interfaces doivent être configurées dans le mode FAILBACK=no. Pour connaître les procédures connexes, reportez-vous à la section Procédure de configuration du comportement du démon IPMP .

Lorsqu'une interface active en mode FAILBACK=no échoue et est ensuite réparée, le démon IPMP restaure la configuration d'IPMP comme suit :

• Le démon conserve l'état INACTIVE de l'interface, à condition que le groupe IPMP reflète la configuration d'origine des interfaces actives.

• Si la configuration d'IPMP au moment de la réparation ne reflète pas la configuration d'origine du groupe des interfaces actives, puis l'interface réparée est redéployée comme interface active, nonobstant l'état FAILBACK=no.