Chapitre 30 Présentation d'IPMP

Le multiacheminement sur réseau IP (IPMP, IP Network Multipathing) permet de détecter les défaillances des interfaces physiques et de basculer en transparence l'accès au réseau pour un système présentant plusieurs interfaces sur une même liaison IP. IPMP permet également de répartir la charge des paquets pour les systèmes dotés de plusieurs interfaces.

Le présent chapitre contient les informations suivantes :

• Avantages d'IPMP

• Exigences de base d'IPMP

• Adressage IPMP

• Composants IPMP Oracle Solaris

• Configurations d'interfaces IPMP

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

• IPMP et reconfiguration dynamique

Pour les tâches de configuration d'IPMP, reportez-vous au Chapitre 31Administration d'IPMP (tâches).

Avantages d'IPMP

IPMP améliore la fiabilité, la disponibilité et les performances du réseau des systèmes dotés de plusieurs interfaces physiques. Il arrive parfois qu'une interface physique ou le matériel réseau connecté à cette interface présente une défaillance ou requière des opérations de maintenance. Habituellement, il devient alors impossible de contacter le système par le biais de toutes les adresses IP associées à l'interface défaillante. En outre, toute connexion existante vers le système utilisant ces adresses IP est perturbée.

L'utilisation d'IPMP permet de configurer une ou plusieurs interfaces physiques dans un groupe IPMP. Une fois la configuration IPMP terminée, le système contrôle automatiquement les interfaces du groupe IPMP. En cas de défaillance ou de retrait pour maintenance d'une interface du groupe, IPMP effectue une migration automatique, ou basculement, des adresses IP de l'interface. Le destinataire de ces adresses est une interface en fonctionnement au sein du groupe IPMP de l'interface défaillante. La fonction de basculement IPMP permet de conserver la connectivité et empêche toute perturbation des connexions existantes. En outre, IPMP répartit le trafic réseau sur l'ensemble des interfaces du groupe IPMP, ce qui permet d'améliorer les performances réseau globales. Ce processus est appelé répartition de charge.

Composants IPMP Oracle Solaris

Oracle Solaris IPMP comprend les logiciels suivants :

• le démon in.mpathd, dont vous trouverez une description complète à la page de manuel in.mpathd(1M) ;

• le fichier de configuration /etc/default/mpathd dont vous trouverez également une description à la page de manuel in.mpathd(1M) ;

• les options ifconfig de la configuration IPMP, telles que décrites à la page de manuel ifconfig(1M) ;

Démon de multiacheminement in.mpathd

Le démon in.mpathd détecte les défaillances d'interface, puis implémente les diverses procédures pour le basculement et le rétablissement. Si in.mpathd détecte une défaillance ou une réparation, le démon envoie une commande ioctl afin d'effectuer un basculement ou un rétablissement. Le module de noyau ip qui implémente la commande ioctl effectue le basculement d'accès réseau de manière transparente et automatique.

N'utilisez pas l'acheminement secondaire lorsque vous utilisez IPMP sur un même jeu de cartes d'interface réseau. De même, n'utilisez pas IPMP en même temps que l'acheminement secondaire. Vous pouvez utiliser l'acheminement secondaire et IPMP en même temps à condition que cela soit sur des jeux d'interfaces différents. Pour de plus amples informations à propos de l'acheminement alternatif, reportez-vous au Sun Enterprise Server Alternate Pathing 2.3.1 User Guide.

Le démon in.mpathd détecte les défaillances et les réparations en envoyant des sondes sur toutes les interfaces faisant partie d'un groupe IPMP. Le démon in.mpathd détecte également les défaillances et les réparations en contrôlant l'indicateur RUNNING sur chaque interface du groupe. Pour obtenir des informations supplémentaires, consultez la page de manuel in.mpathd(1M).

Le DHCP n'est pas pris en charge pour la gestion des adresses de données IPMP. En cas de tentative d'utilisation de DHCP sur ces adresses, ce protocole finit par cesser de les contrôler. N'utilisez pas le DHCP sur les adresses de données.

Terminologie et concepts IPMP

Cette section présente les termes et concepts utilisés dans les chapitres relatifs à IPMP dans ce manuel.

Liaison IP

Dans la terminologie IPMP, une liaison IP correspond à un utilitaire ou moyen de communication à l'aide duquel les nœuds peuvent communiquer dans la couche liaison-données de la suite de protocoles Internet. Les types de liaisons IP comprennent les réseaux Ethernet simples ou avec passerelles, les hubs, ou les réseaux ATM (Asynchronous Transfer Mode). Une liaison IP peut posséder un ou plusieurs numéros de sous-réseau IPv4 et, si applicable, un ou plusieurs préfixes de sous-réseau IPv6. Un même numéro ou préfixe de masque de sous-réseau IPv4 ne peut pas être attribué à plusieurs liaisons IP. Dans le système ATM LANE, une liaison IP est un réseau local (LAN) à émulation simple. Avec le protocole ARP (Address Resolution Protocol, protocole de résolution d'adresse) l'étendue du protocole ARP correspond à une liaison IP unique.

D'autres documents relatifs à IP, tel que RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, utilisent le terme liaison au lieu de liaison IP. Part VI utilise le terme liaison IP pour éviter toute confusion avec IEEE 802. Dans IEEE 802, liaison se réfère à un seul câble reliant une carte réseau (NIC) Ethernet à un commutateur Ethernet.

Interface physique

L'interface physique permet au système de se connecter à une liaison IP. Cette connexion est souvent implémentée comme un pilote de périphérique ou une carte d'interface réseau. Si un système possède plusieurs interfaces connectées à une même liaison, vous pouvez configurer IPMP afin qu'il effectue un basculement en cas de défaillance d'une des interfaces. Pour obtenir des informations supplémentaires sur les interfaces physiques, reportez-vous à la section Configurations d'interfaces IPMP.

Carte d'interface réseau

Une carte d'interface réseau correspond à un adaptateur réseau qu'il est possible d'intégrer au système. La carte d'interface réseau peut également être une carte distincte servant d'interface à partir du système vers une liaison IP. Certaines cartes d'interface réseau possèdent plusieurs interfaces physiques. Par exemple, une carte d'interface réseau qfe peut posséder quatre interfaces, de qfe0 à qfe3, et ainsi de suite.

Groupe IPMP

Un groupe de multiacheminement IP, ou groupe IPMP, correspond à une ou plusieurs interfaces physiques résidant dans un même système et configurées avec le même nom de groupe IPMP. Toutes les interfaces du groupe IPMP doivent être connectées à la même liaison IP. Le même nom de groupe IPMP sous forme de chaîne de caractères (non-null) identifie la totalité des interfaces du groupe. Vous pouvez placer des interfaces de cartes d'interface réseau de différentes vitesses dans le même groupe IPMP, à condition que les cartes d'interface réseau soient du même type. Par exemple, vous pouvez configurer les interfaces de cartes d'interface réseau Ethernet de 100 Mo et celles de cartes d'interface réseau d'un Go dans un même groupe. Voici un autre exemple : supposons que vous disposez de deux cartes d'interface réseau Ethernet de 100 Mo. Vous pouvez configurer l'une des interfaces de sorte qu'elle soit réduite à 10 Mo, puis placer les deux interfaces dans le même groupe IPMP.

Vous ne pouvez pas placer deux interfaces ayant différents types de média dans un groupe IPMP. Par exemple, vous ne pouvez pas placer une interface ATM dans le même groupe qu'une interface Ethernet.

Détection de défaillance et basculement

La détection de défaillance correspond au processus de détection intervenant lorsqu'une interface ou le chemin d'une interface vers un périphérique de couche Internet ne fonctionne plus. IPMP permet aux systèmes de détecter les défaillances d'interface. IPMP détecte les types de défaillance de communication suivants :

• Le chemin de transmission ou de détection de l'interface est défaillant.

• La connexion entre l'interface et la liaison IP a été interrompue.

• Le port sur le commutateur ne reçoit ou ne transmet pas de paquet.

• L'interface physique d'un groupe IPMP n'est pas présente à l'initialisation du système.

Après détection d'une défaillance, IPMP démarre le basculement. Le basculement correspond au processus automatique de commutation de l'accès réseau d'une interface défaillante vers une interface physique en état de fonctionnement dans le même groupe. L'accès réseau inclut le trafic IPv4 monodiffusion, multidiffusion et diffusion, ainsi que le trafic IPv6 monodiffusion et multidiffusion. Le basculement n'est possible qu'à condition d'avoir configuré plusieurs interfaces dans le groupe IPMP. Ce processus garantit un accès ininterrompu au réseau.

Détection de réparation et rétablissement

La détection de réparation correspond au processus permettant de déterminer le moment auquel une carte d'interface réseau ou le chemin de la carte vers un périphérique de couche 3 est de nouveau fonctionnel après une défaillance. Après avoir détecté la réparation d'une carte d'interface réseau, IPMP effectue un rétablissement, qui correspond au processus de restauration de l'accès réseau de l'interface réparée. La détection de réparation suppose que vous avez activé les restaurations automatiques. Reportez-vous à la section Détection de réparation d'interface physique pour obtenir des informations supplémentaires.

Système cible

La détection de défaillance basée sur sonde utilise les systèmes cible pour déterminer le statut d'une interface. Chaque système cible doit être connecté à la même liaison IP que les membres du groupe IPMP. Le démon in.mpathd du système local envoie des messages de sonde IMCP à chaque système cible. Les messages de sonde permettent de déterminer l'état de maintenance de chaque interface du groupe IPMP.

Pour de plus amples informations sur l'utilisation de systèmes cible dans la détection de défaillance basée sur sonde, reportez-vous à la section Détection de défaillance basée sur sonde.

Répartition de charge sortante

Une fois la configuration d'IPMP terminée, les paquets réseau sortants sont répartis entre plusieurs cartes d'interface réseau, sans incidence sur l'ordre des paquets. On parle de répartition de charge. La répartition de charge permet d'augmenter le rendement. Elle ne se produit que lorsque le trafic réseau se dirige vers plusieurs destinations utilisant plusieurs connexions.

Reconfiguration dynamique

La reconfiguration dynamique (DR, Dynamic Reconfiguration) correspond à la capacité de reconfiguration d'un système en cours d'exécution en affectant peu ou pas du tout les opérations en cours. La reconfiguration dynamique n'est pas prise en charge par toutes les plates-formes Sun. Certaines plates-formes Sun ne prennent en charge que la reconfiguration dynamique de certains types de matériel. Sur les plates-formes qui prennent en charge la reconfiguration dynamique de cartes d'interface réseau, IPMP peut être utilisé pour basculer de façon transparente l'accès réseau, donnant ainsi au système un accès au réseau ininterrompu.

Pour obtenir des informations supplémentaires sur la prise en charge de la reconfiguration dynamique par IPMP, reportez-vous à la section IPMP et reconfiguration dynamique.

Exigences de base d'IPMP

Le composant IPMP est intégré à Oracle Solaris et ne nécessite aucun matériel spécial. Toute interface prise en charge par Oracle Solaris peut être utilisée avec IPMP. Cependant, la configuration et la topologie de votre réseau doivent respecter les exigences suivantes relatives à IPMP :

• Toutes les interfaces d'un groupe IPMP doivent disposer d'adresses MAC uniques.

  Notez que par défaut, les interfaces réseau de systèmes SPARC partagent la même adresse MAC. Par conséquent, vous devez modifier explicitement l'adresse par défaut afin d'utiliser IPMP sur des systèmes SPARC. Pour de plus amples informations, reportez-vous à la section Procédure de planification pour un groupe IPMP.

• Toutes les interfaces d'un groupe IPMP doivent être du même type de média. Pour de plus amples informations, reportez-vous à la section Groupe IPMP.

• Toutes les interfaces d'un groupe IPMP doivent se trouver sur la même liaison IP. Pour de plus amples informations, reportez-vous à la section Groupe IPMP.

  ---

  Remarque –

  Si plusieurs groupes IPMP appartiennent au même domaine de diffusion (L2 ou couche 2), ces groupes ne sont pas pris en charge. Un domaine de diffusion L2 est généralement mappé à un sous-réseau spécifique. Par conséquent, vous ne devez configurer qu'un seul groupe IPMP par sous-réseau.

  ---

• En fonction de vos exigences en matière de détection de défaillance, vous devrez soit utiliser des types spécifiques d'interfaces réseau, soit configurer des adresses IP supplémentaires sur chaque interface réseau. Reportez-vous aux sections Détection de défaillance basée sur les liaisons et Détection de défaillance basée sur sonde.

Adressage IPMP

Vous pouvez configurer la détection de défaillance d'IPMP sur des réseaux IPv4 ainsi que sur des réseaux IPv4 et IPv6 double pile. Les interfaces configurées avec IPMP prennent deux types d'adresses en charge : les adresses de données et les adresses test.

Adresses de données

Les adresses de données correspondent aux adresses IPv4 et IPv6 conventionnelles assignées à l'interface d'une carte d'interface réseau au démarrage ou manuellement, à l'aide de la commande ifconfig. Le trafic de paquets standard IPv4 et, le cas échéant, IPv6, passant par une interface est considéré comme du trafic de données.

Adresses test

Les adresses test sont des adresses spécifiques à IPMP utilisées par le démon in.mpathd. Pour pouvoir utiliser la détection de défaillance et de réparation basée sur sonde, une interface doit être configurée avec au moins une adresse test.

La configuration des adresses test n'est requise que si vous souhaitez utiliser la détection de défaillance basée sur sonde.

Le démon in.mpathd utilise les adresses test afin d'échanger les sondes ICMP avec d'autres cibles sur la liaison IP. C'est ce qu'on appelle le trafic de sondes. Le trafic de sondes permet de déterminer le statut de l'interface et de sa carte d'interface réseau, y compris l'emplacement de la défaillance de l'interface. Les sondes vérifient que le chemin d'envoi et de réception vers l'interface fonctionne correctement.

Il est possible de configurer chaque interface avec une adresse IP test. Dans le cas d'une interface sur un réseau double pile, vous pouvez configurer une adresse test IPv4, une adresse test IPv6 ou les deux.

En cas de défaillance d'une interface, les adresses test restent sur celle-ci de sorte que in.mpathd puisse continuer à envoyer des sondes afin de vérifier les réparations ultérieures. Veillez à configurer les adresses test de façon spécifique, de sorte que les applications ne les utilisent pas accidentellement. Pour de plus amples informations, reportez-vous à la section Empêcher les applications d'utiliser les adresses test.

Pour de plus amples informations sur la détection de défaillance basée sur sonde, reportez-vous à la section Détection de défaillance basée sur sonde.

Adresses test IPv4

En règle générale, vous pouvez utiliser l'adresse IPv4 de votre choix sur votre sous-réseau en tant qu'adresse test. Il n'est pas nécessaire que les adresses test IPv4 soient acheminables. Dans la mesure où les adresses IPv4 sont une ressource limitée pour de nombreux sites, il est préférable dans certains cas d'utiliser des adresses privées RFC 1918 non acheminables en tant qu'adresses test. Notez que le démon in.mpathd n'échange que des sondes ICMP avec d'autres hôtes situés sur le même sous-réseau que l'adresse test. Si vous utilisez des adresses test de type RFC 1918, veillez à configurer d'autres systèmes, des routeurs de préférence, sur la liaison IP avec des adresses situées sur le sous-réseau RFC 1918. Le démon in.mpathd peut ensuite échanger les sondes avec des systèmes cible.

Les exemples d'IPMP utilisent les adresses RFC 1918 à partir du réseau 192.168.0/24 en tant qu'adresses test IPv4. Pour plus d'informations sur les adresses privées RFC 1918, reportez-vous au document RFC 1918, Address Allocation for Private Internets (en anglais).

Pour configurer les adresses test IPv4, reportez-vous à la tâche Procédure de configuration d'un groupe IPMP avec plusieurs interfaces.

Adresses test IPv6

La seule adresse test IPv6 valide correspond à l'adresse lien-local d'une interface physique. Vous n'avez pas besoin d'utiliser une adresse IPv6 en tant qu'adresse test IPMP. L'adresse IPv6 lien-local est basée sur l'adresse MAC (Media Access Control) de l'interface. Les adresses lien-local sont configurées automatiquement lorsque l'interface devient compatible IPv6 lors du démarrage ou lorsque l'interface est configurée manuellement via ifconfig.

Exécutez la commande ifconfig interface sur un nœud compatible IPv6 afin d'identifier l'adresse lien-local d'une interface. Vérifiez la sortie de l'adresse qui commence par fe80, le préfixe lien-local. L'indicateur NOFAILOVER dans la sortie de commande ifconfig ci-dessous indique que l'adresse lien-local fe80::a00:20ff:feb9:17fa/10 de l'interface hme0 est utilisée en tant qu'adresse test.

hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6,NOFAILOVER> mtu 1500 index 2
        	inet6 fe80::a00:20ff:feb9:17fa/10 

Pour de plus amples informations sur les adresses lien-local, reportez-vous à la section Adresse unicast lien-local.

Lorsque IPv4 et IPv6 sont montés sur la totalité des interfaces d'un groupe IPMP , il est inutile de configurer des adresses test IPv4 distinctes. Le démon in.mpathd peut utiliser des adresses IPv6 lien-local en tant qu'adresses test.

Pour créer des adresses test IPv6, reportez-vous à la tâche Procédure de configuration d'un groupe IPMP avec plusieurs interfaces.

Empêcher les applications d'utiliser les adresses test

Après avoir configuré une adresse test, vous devez vous assurer que cette adresse n'est pas utilisée par les applications. Sinon, en cas de défaillance de l'interface, il devient impossible d'atteindre l'application car les adresses test ne basculent pas lors de l'opération de basculement. Pour vous assurer qu'IP ne sélectionne pas l'adresse test pour des applications normales, marquez l'adresse test comme étant deprecated.

IPv4 n'utilise pas d'adresse désapprouvée en tant qu'adresse source pour toute communication, à moins qu'une application ne crée une liaison explicite vers l'adresse. Le démon in.mpathd lie de façon explicite à une telle adresse afin d'envoyer et de recevoir du trafic de sondes.

Dans la mesure où les adresses IPv6 lien-local sont généralement absentes dans un service de nom, les applications DNS et NIS n'utilisent pas d'adresses lien-local pour la communication. Par conséquent, vous ne devez pas marquer les adresses lien-local IPv6 comme étant deprecated.

Les adresses test IPv4 ne doivent pas être placées dans les tables de services de noms DNS et NIS. Dans IPv6, les adresses lien-local ne sont normalement pas placées dans les tables de services de noms.

Configurations d'interfaces IPMP

En règle générale, la configuration d'IPMP se compose d'au moins deux interfaces physiques situées sur le même système et connectées à la même liaison IP. Il n'est pas nécessaire que ces interfaces physiques se trouvent sur la même carte d'interface réseau. Les interfaces sont configurées en tant que membres du même groupe IPMP. Si le système dispose d'interfaces supplémentaires sur une seconde liaison IP, vous devez configurer ces interfaces comme un autre groupe IPMP.

Vous pouvez configurer une interface unique dans son propre groupe IPMP. Le groupe IPMP à interface unique se comporte de la même façon qu'un groupe IPMP avec plusieurs interfaces. Cependant, le basculement et le rétablissement sont impossibles pour un groupe IPMP disposant d'une seule interface.

Vous pouvez également configurer des VLAN en groupe IPMP en procédant de la même manière que pour configurer un groupe à partir d'interfaces IP. Les procédures sont décrites à la section Configuration de groupes IPMP. Les exigences répertoriées à la section Exigences de base d'IPMP s'appliquent également à la configuration de VLAN en groupe IPMP.

La convention utilisée pour nommer les VLAN peut être à l'origine d'erreurs lorsque vous configurez des VLAN en tant que groupe IPMP. Pour plus de détails sur les noms des réseaux VLAN, reportez-vous à la section Points de connexions physiques et repères des VLAN dans le guide Guide d'administration système : services IP?. Prenons par exemple quatre VLAN, bge1000, bge1001, bge2000 et bge2001. L'implémentation IPMP requiert que ces VLAN soient regroupés comme suit : bge1000 et bge1001 appartiennent à un seul groupe sur le même VLAN 1, tandis que bge2000 et bge2001 appartiennent à un autre groupe sur le même VLAN 2. Du fait des noms VLAN, des VLAN appartenant à différents liens au sein d'un groupe IPMP peuvent facilement être confondus, par exemple bge1000 et bge2000.

Interfaces de réserve d'un groupe IPMP

L'interface de réserve d'un groupe IPMP n'est pas utilisée pour le trafic de données, sauf en cas de défaillance d'une autre interface du groupe. En cas de défaillance, les adresses de données de l'interface défaillante migrent vers l'interface de réserve. Ensuite, l'interface de réserve est traitée comme les autres interfaces actives, jusqu'à ce que l'interface défaillante soit réparée. Certains basculements ne choisissent pas l'interface de réserve. Ils choisiront plutôt une interface active disposant d'un nombre moins important d'adresses de données configurées en tant qu'UP.

Sur une interface de réserve, configurez uniquement des adresses test. IPMP ne vous permet pas d'ajouter une adresse de données à une interface configurée par le biais de la commande ifconfig comme étant de réserve (option standby). Toute tentative de création de ce type de configuration échoue. De même, si vous configurez une interface disposant déjà d'adresses de données comme étant standby, ces adresses basculent automatiquement vers une autre interface du groupe IPMP. En raisons de ces restrictions, vous devez utiliser la commande ifconfig afin de marquer les adresses test à l'aide des options deprecated (désapprouvée) et -failover (basculement) avant de configurer l'interface avec l'option standby. Pour configurer des interfaces de réserve, reportez-vous à la section Procédure de configuration d'une interface de réserve pour un groupe IPMP.

Configurations courantes d'interfaces d'IPMP

Comme indiqué dans la section Adressage IPMP, les interfaces d'un groupe IPMP assurent la gestion du trafic de données et de sondes, en fonction de la configuration des interfaces. Les options IPMP de la commande ifconfig permettent de créer la configuration.

Une interface active correspond à une interface physique qui transmet le trafic de données et de sondes. Les tâches Procédure de configuration d'un groupe IPMP avec plusieurs interfaces et Procédure de configuration d'un groupe IPMP à interface unique permettent de configurer l'interface comme étant active.

Vous trouverez ci-dessous deux types courants de configuration IPMP :

Configuration active-active

Groupe IPMP possédant deux interfaces actives. En d'autres termes, elles peuvent transmettre le trafic de sondes et de données à tout moment.

Configuration active-de réserve

Groupe IPMP possédant deux interfaces, dont l'une est configurée en tant qu'interface de réserve.

Vérification du statut d'une interface

L'émission de la commande ifconfig interface permet de vérifier le statut d'une interface. Pour obtenir des informations générales sur le rapport d'état ifconfig, reportez-vous à la section Méthode d'obtention d'informations sur une interface spécifique.

Par exemple, la commande ifconfig permet d'obtenir le statut d'une interface de réserve. Lorsque l'interface de réserve n'héberge aucune adresse de données, son statut est signalé par l'indicateur INACTIVE. Vous pouvez observer cet indicateur dans les lignes d'état pour l'interface dans la sortie ifconfig.

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 :

• 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 au démarrage.

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 :

• hme

• eri

• ce

• ge

• bge

• qfe

• dmfe

• e1000g

• 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 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.

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

IPMP et reconfiguration dynamique

La fonctionnalité DR (Dynamic Reconfiguration, reconfiguration dynamique) permet de reconfigurer le matériel système, notamment les interfaces, lorsque le système est en cours d'exécution. Cette section explique le mode d'interopération entre la DR et IPMP.

Dans un système prenant en charge la reconfiguration dynamique des cartes d'interface réseau, IPMP permet de préserver la connectivité et d'éviter toute perturbation des connexions existantes. Vous pouvez connecter, déconnecter ou reconnecter des cartes d'interface réseau en toute sécurité sur un système prenant en charge la DR et utilisant IPMP. Cela est possible car IPMP est intégré à la structure du RCM (Reconfiguration Coordination Manager, gestionnaire de coordination de reconfiguration). Le RCM assure la gestion de la reconfiguration dynamique des composants système.

En règle générale, la commande cfgadm permet d'effectuer des opérations de reconfiguration dynamique. Cependant, certaines plates-formes fournissent d'autres méthodes. Reportez-vous à la documentation de votre plate-forme pour obtenir des informations supplémentaires. Vous trouverez des informations spécifiques relatives à la DR dans les ressources suivantes.

Connexion de cartes d'interface réseau

Vous pouvez ajouter des interfaces à un groupe IPMP à tout moment à l'aide de la commande ifconfig, comme décrit à la section Procédure de configuration d'un groupe IPMP avec plusieurs interfaces. Par conséquent, toutes les interfaces sur des composants système connectés après l'initialisation du système peuvent être montées et ajoutées à un groupe IPMP existant. Le cas échéant, vous pouvez également configurer les nouvelles interfaces ajoutées dans leur propre groupe IPMP.

Ces interfaces et les adresses de données configurées dessus peuvent immédiatement être utilisées par le groupe IPMP. Cependant, pour que le système configure et utilise les interfaces automatiquement après la réinitialisation, vous devez créer un fichier /etc/hostname.interface pour chaque nouvelle interface. Pour obtenir des instructions, reportez-vous à la section Configuration d'une interface physique après l'installation du système.

Si un fichier /etc/hostname.interface existe déjà lors de la connexion de l'interface, le RCM configure l'interface automatiquement, en fonction du contenu du fichier. Par conséquent, la configuration de l'interface est la même que celle qu'elle obtiendrait après l'initialisation du système.

Déconnexion de cartes d'interface réseau

Toutes les requêtes de déconnexion de composants système contenant des cartes d'interface réseau sont d'abord vérifiées afin de garantir un connectivité ininterrompue. Ainsi, par défaut, il est impossible de déconnecter une carte d'interface réseau ne faisant pas partie d'un groupe IPMP. La déconnexion est également impossible dans le cas d'une carte d'interface réseau qui contient les seules interfaces en état de fonctionnement d'un groupe IPMP. Cependant, si vous devez retirer le composant système, l'option -f de cfgadm permet de contourner ce comportement ; vous trouverez une explication à la page de manuel cfgadm(1M).

Si les vérifications sont réussies, les adresses de données associées à la carte d'interface réseau déconnectée basculent vers une autre carte du même groupe, comme dans le cas d'une défaillance de la carte déconnectée. Une fois la carte d'interface réseau déconnectée, la configuration des adresses test présentes sur ses interfaces est annulée. Ensuite, la carte d'interface réseau est démontée du système. En cas d'échec de l'une de ces étapes, ou de défaillance de la reconfiguration dynamique ou autre matériel sur le même composant système, l'état d'origine de la configuration précédente est restauré. Vous devriez recevoir un message de statut à propos de cet événement. Dans le cas contraire, la demande de déconnexion est traitée. Vous pouvez retirer le composant du système. Aucune connexion existante n'est interrompue.

Reconnexion d'une carte d'interface réseau

Le RCM enregistre les informations de configuration associées à toute carte d'interface réseau déconnectée d'un système en cours d'exécution. Par conséquent, le RCM traite la reconnexion d'une carte d'interface réseau précédemment déconnectée comme il le ferait pour la connexion d'une nouvelle carte d'interface réseau. Le RCM n'effectue que le montage.

Cependant, les cartes réseau reconnectées disposent généralement d'un fichier /etc/hostname. fichier interface. Dans ce cas, le RCM configure automatiquement l'interface en fonction du contenu du fichier /etc/hostname. fichier interface. De plus, le RCM informe le démon in.mpathd de chaque adresse de données hébergée à l'origine sur l'interface reconnectée. Par conséquent, une fois que l'interface reconnectée fonctionne correctement, toutes ses adresses de données sont rétablies sur l'interface reconnectée, comme si elle avait été reconnectée.

Si la carte d'interface réseau reconnectée ne possède pas de fichier /etc/hostname. interface, aucune information de configuration n'est disponible. Le RCM ne dispose pas d'informations relatives à la configuration de l'interface. Par conséquent, les adresses basculées vers une autre interface ne sont pas rétablies.

Cartes d'interface réseau manquantes à l'initialisation du système

Les cartes d'interface réseau absentes lors de l'initialisation du système constituent une instance spéciale de détection de défaillance. Lors de l'initialisation, les scripts de démarrage réalisent le suivi de toutes les interfaces possédant des fichiers /etc/hostname.interface qu'il est impossible de monter. Toute adresse de données se trouvant dans un fichier /etc/hostname. interface d'une telle interface est automatiquement hébergée sur une autre interface dans le groupe IPMP.

Si cela venait à se produire, vous recevrez un message d'erreur similaire à ce qui suit :

moving addresses from failed IPv4 interfaces: hme0 (moved to hme1)
moving addresses from failed IPv6 interfaces: hme0 (moved to hme1)

Si aucune autre interface n'existe, vous recevrez un message d'erreur similaire à ce qui suit :

moving addresses from failed IPv4 interfaces: hme0 (couldn't move; 
   no alternative interface) 
 moving addresses from failed IPv6 interfaces: hme0 (couldn't move; 
   no alternative interface) 

Dans ce cas de détection de défaillance, seules les adresses de données spécifiées explicitement dans le fichier /etc/hostname. interface de l'interface manquant sont déplacés vers une autre interface. Toute adresse acquise par d'autres moyens, par exemple via RARP ou DHCP, n'est ni acquise ni déplacée.

Si une interface existante porte le nom d'une autre interface manquante lors de l'initialisation du système et a été reconnectée à l'aide de la reconfiguration dynamique, le RCM monte l'interface automatiquement. Ensuite, le RCM configure l'interface en fonction du contenu de son fichier /etc/hostname.interface. Enfin, le RCM rétablit toutes les adresses de données, comme si l'interface avait été réparée. Par conséquent, la configuration réseau finale est identique à celle qui aurait été effectuée si l'interface avait été présente lors de l'initialisation du système.