test

Guide d'administration système : services IP

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éfaillance suivants :

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

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 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. 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 Procédure de 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 Procédure de 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.

Remarque –

Dans un groupe IPMP composé de VLAN, la détection de défaillance basée sur lien est implémentée par lien physique et de ce fait, affecte tous les VLAN se trouvant sur ce lien. La détection de défaillance basée sur lien est effectuée par lien VLAN. Par exemple, bge0/bge1 et bge1000/bge1001 sont configurés au sein du même groupe. Si le câble de bge0 est débranché, la détection de défaillance basée sur lien signale la défaillance immédiate de bge0 et de bge1000. Toutefois, si l'accès à toutes les cibles de sondes sur bge0 est interrompu, seule la défaillance de bge0 est signalée car bge1000 dispose de ses propres cibles de sondes sur son VLAN.

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 30–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 30–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).