Détection de défaillance d'IPMP et fonctionnalités de reprise

Le démon in.mpathd gère les types de détection de défaillances suivants :

• 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, lorsque les adresses test sont configurées

• Détection d'interfaces manquantes à l'initialisation

La page de manuel in.mpathd(1M) décrit la méthode de gestion des défaillances d'interface par le démon in.mpathd.

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 en charge ce type de détection de défaillance. Les pilotes réseau Sun suivants sont pris en charge dans la version actuelle d'Oracle Solaris :

• hme

• eri

• ce

• ge

• bge

• qfe

• dmfe

• e1000g

• igb

• ixgb

• nge

• nxge

• rge

• xge

Consultez la documentation du fabricant pour savoir si une interface tierce prend en charge la détection de défaillance basée sur les liaisons.

Ces pilotes d'interface réseau surveillent 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. Lorsque le démon 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 basée sur sonde

Le démon in.mpathd effectue une détection de défaillance basée sur sonde sur chaque interface possédant une adresse test dans le groupe IPMP. La détection de défaillance basée sur sonde repose sur l'envoi et la réception de messages de sonde ICMP utilisant des adresses test. Ces messages partent de l'interface vers un ou plusieurs systèmes cible sur la même liaison IP. Les adresses test sont décrites à la section Adresses test. Pour obtenir des informations sur la configuration des adresses test, reportez-vous à la section Configuration d'un groupe IPMP avec plusieurs interfaces.

Le démon in.mpathd permet de déterminer les systèmes cible à analyser dynamiquement. Les routeurs connectés à la liaison IP sont sélectionnés automatiquement en tant que cibles pour les tests. En l'absence de routeur sur la liaison, in.mpathd envoie des sondes aux hôtes voisins sur la liaison. Un paquet multidiffusion envoyé à toutes les adresses d'hôtes multidiffusion, 224.0.0.1 dans IPv4 et ff02::1 dans IPv6, détermine les hôtes à utiliser en tant que systèmes cible. Les 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 paquets d'écho ICMP, in.mpathd ne pourra pas détecter les défaillances basées sur sonde.

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 obtenir des instructions, reportez-vous à la section Configuration de systèmes cible.

Afin de garantir le bon fonctionnement de chaque interface du groupe IPMP, in.mpathd analyse toutes les cibles séparément via toutes les interfaces du groupe IPMP. Si, après cinq tests consécutifs, 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 /etc/default/mpathd. Vous trouverez des instructions à la section Configuration du fichier /etc/default/mpathd.

Pour un temps de détection de réparation de 10 secondes, la fréquence des tests est d'environ une sonde toutes les deux secondes. Le temps de détection de réparation est le double de celui de détection de défaillance, soit 20 secondes par défaut, afin d'assurer la réception de 10 sondes consécutives. Les temps de détection de défaillance et de réparation s'appliquent uniquement à la détection de défaillance basée sur sonde.

Défaillances de groupe

Une défaillance de groupe survient lorsque la totalité des interfaces d'un groupe IPMP sont défaillantes au même moment. Le démon in.mpathd n'effectue pas de basculement dans le cas d'une défaillance de groupe. En outre, aucun basculement ne se produit lorsque tous les systèmes cible sont défaillants au même moment. Dans ce cas, in.mpathd vide la totalité de ses systèmes cible actuels et détecte de nouveaux systèmes cible.

Détection de réparation d'interface physique

Pour que le démon in.mpathd considère qu'une interface est réparée, l'indicateur RUNNING doit être configuré pour celle-ci. En cas d'utilisation de la détection de défaillance basée sur sonde, le démon in.mpathd doit recevoir les réponses de 10 paquets de sonde consécutifs en provenance de l'interface avant qu'elle ne soit considérée comme étant réparée. Lorsqu'une interface est considérée comme étant réparée, toute adresse ayant basculé vers une autre interface bascule à nouveau vers celle-ci. Si l'interface était configurée comme étant active avant sa défaillance, une fois réparée, elle peut reprendre l'envoi et la réception de trafic.

Description du basculement d'interface

Les deux exemples suivants illustrent une configuration typique et sa modification automatique en cas de défaillance d'une interface. En cas de défaillance de l'interface hme0, toutes les adresses de données se déplacent de hme0 à hme1.

Exemple 27-1 Configuration d'interface avant une défaillance

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

Exemple 27-2 Configuration d'interface après une défaillance

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

Comme vous pouvez l'observer, l'indicateur FAILED est défini sur hme0 afin d'indiquer que cette interface est défaillante. Notez également que hme1:2 a été créé. hme1:2 était à l'origine hme0. L'adresse 192.168.85.19 devient accessible via hme1.

Les appartenances multidiffusion associées à 192.168.85.19 peuvent toujours recevoir des paquets, mais elles les reçoivent à présent via hme1. Lors du basculement de l'adresse 192.168.85.19 de hme0 vers hme1, l'adresse fictive 0.0.0.0 a été créée sur hme0. Grâce à l'adresse fictive, il reste possible d'accéder à hme0. hme0:1 ne peut pas exister sans hme0. L'adresse fictive est supprimée dès que le basculement s'effectue.

De même, l'adresse IPv6 a basculé de hme0 vers hme1. Dans IPv6, les appartenances multidiffusion sont associées aux index d'interface. Les appartenances multidiffusion basculent également de hme0 vers hme1. Toutes les adresses configurées par in.ndpd se déplacent également. Cette action ne figure pas dans les exemples.

Le démon in.mpathd poursuit l'analyse de l'interface défaillante hme0. Lorsque le démon a reçu 10 réponses consécutives pour une durée de détection de réparation par défaut de 20 secondes, il considère l'interface comme réparée. L'indicateur RUNNING étant également défini sur hme0, le démon appelle le rétablissement. une fois le rétablissement effectué, la configuration d'origine est restaurée.

Pour obtenir une description des messages d'erreur consignés dans la console lors des défaillances et des réparations, consultez la page de manuel in.mpathd(1M).