Guide d'administration système : services IP

Partie VI IPMP

Cette partie décrit le multiacheminement sur réseau IP (IPMP, IP Network Multipathing), ainsi que les tâches relatives à l'administration d'IPMP. IPMP permet de détecter les défaillances, ainsi que d'effectuer le basculement d'interfaces d'un système lorsqu'elles sont connectées à la même liaison.

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 :

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.

Remarque –

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

Remarque –

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.

Remarque –

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.

Remarque –

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.

Attention –

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.

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

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.

Tableau 30–1 Ressources documentaires sur la DR


Description	Référence
Informations détaillées sur la commande `cfgadm`	Page de manuel cfgadm(1M).
Information spécifiques sur la DR dans l'environnement Sun Cluster	Sun Cluster 3.1 System Administration Guide
Informations spécifiques sur la DR dans l'environnement Sun Fire	Sun Fire 880 Dynamic Reconfiguration Guide
Introduction à la DR et à la commande `cfgadm`	Chapitre 6, Dynamically Configuring Devices (Tasks) du System Administration Guide: Devices and File Systems
Tâches d'administration de groupes IPMP sur un système prenant en charge la DR	Remplacement d'une interface physique défaillante sur des systèmes prenant la DR en charge

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)

Remarque –

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.

Chapitre 31 Administration d'IPMP (tâches)

Ce chapitre décrit les tâches relatives à l'administration des groupes d'interfaces avec IPMP (multiacheminement sur réseau IP). Les rubriques traitées sont les suivantes :

Pour obtenir une présentation des concepts relatifs à IPMP, reportez-vous au Chapitre 30Présentation d'IPMP.

Configuration d'IPMP (liste des tâches)

Cette section contient des liens vers les tâches décrites dans ce chapitre.

Configuration et administration de groupes IPMP (liste des tâches)

Tâche	Description	Voir
Planification d'un groupe IPMP.	Répertorie la totalité des informations complémentaires et des tâches requises préalables à la configuration d'un groupe IPMP.	Procédure de planification pour un groupe IPMP
Configuration d'un groupe d'interface IPMP composé de plusieurs interfaces.	Configure plusieurs interfaces en tant que membres d'un groupe IPMP.	Procédure de configuration d'un groupe IPMP avec plusieurs interfaces
Configuration d'un groupe IPMP où l'une des interfaces est une interface de réserve.	Configure l'une des interfaces d'un groupe d'interfaces IPMP en tant qu'interface de réserve.	Procédure de configuration d'une interface de réserve pour un groupe IPMP
Configuration d'un groupe IPMP composé d'une interface unique.	Crée un groupe IPMP composé d'une seule interface.	Procédure de configuration d'un groupe IPMP à interface unique
Affichage du groupe IPMP auquel appartient une interface physique.	Explication sur le mode d'obtention du nom du groupe IPMP d'une interface à partir de la sortie de la commande `ifconfig`.	Procédure d'affichage de l'appartenance d'une interface à un groupe IPMP
Ajout d'une interface à un groupe IPMP.	Configuration d'une nouvelle interface en tant que membre d'un groupe IPMP existant.	Procédure d'ajout d'une interface à un groupe IPMP
Retrait d'une interface d'un groupe IPMP.	Fournit des explications sur le retrait d'une interface d'un groupe IPMP.	Procédure de suppression d'une interface d'un groupe IPMP
Déplacement d'une interface à partir d'un groupe IPMP existant vers un groupe différent.	Déplacement d'interfaces au sein de groupes IPMP.	Procédure de déplacement d'une interface d'un groupe IPMP vers un autre
Modification de trois paramètres par défaut du démon `in.mpathd`.	Personnalise le temps de détection de défaillance et autres paramètres du démon `in.mpathd` .	Procédure de configuration du fichier `/etc/default/mpathd`

Administration d'IPMP sur des interfaces prenant en charge la reconfiguration dynamique (liste des tâches)

Tâche	Description	Voir
Retrait d'une interface défaillante.	Retrait du système d'une interface défaillante.	Procédure de suppression d'une interface physique défaillante (DR puis déconnexion)
Remplacement d'une interface défaillante.	Remplacement d'une interface défaillante.	Procédure de remplacement d'une interface physique défaillante (DR puis connexion)
Récupération d'une interface non configurée lors de l'initialisation.	Récupération d'une interface défaillante.	Procédure de récupération d'une interface physique absente lors de l'initialisation du système

Configuration de groupes IPMP

Cette section décrit les procédures pour la configuration de groupes IPMP. Elle propose également une description de la configuration d'une interface en tant qu'interface de réserve.

Planification d'un groupe IPMP

Avant de configurer des interfaces sur un système comme faisant partie d'un groupe IPMP, vous devez effectuer une planification de préconfiguration.

Procédure de planification pour un groupe IPMP

La procédure suivante inclut les tâches de planification et les informations à collecter préalablement à la configuration du groupe IPMP. Il n'est pas obligatoire de réaliser les tâches dans l'ordre dans lequel elles sont décrites.

Déterminez les interfaces du système qui feront partie du groupe IPMP.

Un groupe IPMP se compose en règle générale d'au moins deux interfaces physiques connectées à la même liaison IP. Vous pouvez cependant configurer un groupe IPMP à interface unique si nécessaire. Pour une introduction sur les groupes IPMP, reportez-vous à la section Configurations d'interfaces IPMP. Par exemple, vous pouvez configurer le commutateur Ethernet ou le même sous-réseau IP dans le même groupe IPMP. Vous pouvez configurer le nombre d'interfaces de votre choix dans un même groupe IPMP.

Vous ne pouvez pas utiliser le paramètre group de la commande ifconfig avec des interfaces logiques. Par exemple, vous pouvez utiliser le paramètre group avec hme0, mais pas avec hme0:1 .

Assurez-vous que chaque interface du groupe dispose d'une adresse MAC unique.

Pour obtenir des instructions, reportez-vous à la section SPARC : Garantie de l'unicité de l'adresse MAC d'une interface.

Attribuez un nom au groupe IPMP.

Tout nom autre que NULL est approprié pour le groupe. Utilisez un nom qui identifie la liaison IP à laquelle sont connectées les interfaces.

Assurez-vous que le même ensemble de modules STREAMS est déplacé et configuré sur toutes les interfaces dans le groupe IPMP.

Toutes les interfaces dans un même groupe doivent disposer de modules STREAMS configurés selon le même ordre.
1. Vérifiez l'ordre des modules STREAMS sur toutes les interfaces du groupe IPMP futur.
  
  Vous pouvez imprimer une liste de modules STREAMS à l'aide de la commande ifconfig interface modlist. Voici un exemple de sortie de la commande ifconfig pour une interface hme0 interface :
  # ifconfig hme0 modlist 0 arp 1 ip 2 hme
  Les interfaces existent normalement en tant que pilotes réseau directement sous le module IP, tel qu'illustré dans la sortie de ifconfig hme0 modlist. Aucune configuration supplémentaire ne devrait être nécessaire.
  
  Cependant, certaines technologies comme NCA ou IP Filter, s'insèrent en tant que modules STREAMS entre le module IP et le pilote de réseau. Des problèmes peuvent se produire dans le comportement des interfaces dans un même groupe IPMP.
  
  Dans le cas d'un module STREAMS avec état, des comportements inattendus peuvent être observés lors du basculement, même en cas de déplacement d'un même module sur toutes les interfaces d'un groupe. Cependant, vous pouvez utiliser des modules STREAMS sans état, à condition que vous les déplaciez selon le même ordre sur toutes les interfaces du groupe IPMP.
2. Déplacez les modules d'une interface selon l'ordre standard pour le groupe IPMP.
  ifconfig interface modinsert module-name
  ifconfig hme0 modinsert ip

Utilisez le même format d'adressage IP sur toutes les interfaces du groupe IPMP.

Si une interface est configurée pour IPv4, toutes les interfaces du groupe doivent être configurées pour IPv4. Admettons que vous disposez d'un groupe IPMP composé d'interfaces provenant de plusieurs cartes d'interface réseau. Si vous ajoutez l'adressage IPv6 aux interfaces d'un NIC, toutes les interfaces du groupe IPMP doivent être configurées pour la prise en charge d'IPv6.

Assurez-vous que toutes les interfaces du groupe IPMP sont connectées au même lien IP.

Assurez-vous que le groupe IPMP ne contient pas d'interfaces avec différents types de média réseau.

Les interfaces regroupées doivent être du même type, comme défini dans /usr/include/net/if_types.h . Par exemple, vous ne pouvez pas combiner les interfaces Ethernet et Token ring dans un groupe IPMP. En outre, vous ne pouvez pas combiner un bus d'interfaces Token avec des interfaces ATM (Asynchronous Transfer Mode, mode de transfert asynchrone) dans le même groupe IPMP.

En cas d'IPMP avec interfaces ATM, configurez les interfaces ATM en mode d'émulation LAN.

IPMP n'est pas pris en charge par les interfaces préférant l'IP classique à l'ATM.

Configuration de groupes IPMP

Cette section décrit les tâches relatives à la configuration pour un groupe IPMP classique contenant au moins deux interfaces physiques.

Les groupes IPMP à plusieurs interfaces sont décrits à la section Groupe IPMP.
Pour la planification de tâches, reportez-vous à la section Planification d'un groupe IPMP.
Pour configurer un groupe IPMP avec une seule interface physique, reportez-vous à la section Configuration de groupes IPMP avec une interface physique unique.

Procédure de configuration d'un groupe IPMP avec plusieurs interfaces

Les étapes suivantes permettent de configurer un groupe IPMP et s'appliquent également à la configuration de réseaux VLAN dans un groupe IPMP.

Avant de commencer

Configurez au préalable les adresses IPv4 et , le cas échéant, les adresses IPv6 de toutes les interfaces du futur groupe IPMP.

Attention –

Vous ne devez configurer qu'un seul groupe IPMP pour chaque sous-réseau ou domaine de diffusion L2. Pour plus d'informations, reportez-vous à la section Exigences de base d'IPMP.

Sur le système sur lequel vous devez configurer les interfaces, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Placez chaque interface physique dans un groupe IPMP.
# ifconfig interface group group-name
Par exemple, pour placer hme0 et hme1 sous le groupe testgroup1, saisissez les commandes suivantes :
# ifconfig hme0 group testgroup1 # ifconfig hme1 group testgroup1
Évitez l'utilisation d'espaces dans les noms de groupes. L'affichage du statut ifconfig n'affiche pas les espaces. Par conséquent, n'utilisez pas deux noms de groupes similaires dont la seule différence est un espace. Si l'un des noms de groupe contient un espace, ces noms s'afficheront de la même façon dans l'affichage de statut.

Dans un environnement à double pile, si l'on place l'instance IPv4 d'une interface dans un groupe particulier, l'instance IPv6 est automatiquement placée dans ce même groupe.

(Facultatif) Configurez une adresse test IPv4 sur une ou plusieurs interfaces physiques.

La configuration d'une adresse test est nécessaire uniquement si vous souhaitez utiliser la détection de défaillance basée sur sonde sur une interface spécifique. Les adresses test sont configurées en tant qu'interfaces logiques de l'interface physique spécifiée à la commande ifconfig.

Si une interface du groupe est destinée à devenir l'interface de réserve, ne configurez pas d'adresse test pour celle-ci à cette étape. La configuration de l'adresse test de l'interface de réserve fait partie de la tâche décrite à la section Procédure de configuration d'une interface de réserve pour un groupe IPMP.

Utilisez la syntaxe de la commande ifconfig pour configurer une adresse test :
# ifconfig interface addif ip-address parameters -failover deprecated up
Par exemple, vous pouvez créer l'adresse test suivante pour l'interface réseau principale hme0 :
# ifconfig hme0 addif 192.168.85.21 netmask + broadcast + -failover deprecated up
Cette commande définit les paramètres suivants pour l'interface réseau principale hme0 :
- adresse définie sur 192.168.85.21 ;
- masque de réseau et adresse de diffusion définie sur la valeur par défaut ;
- options -failover et deprecated définies.
  
  Remarque –
  Marquez une adresse test IPv4 comme étant désapprouvée (deprecated) afin d'empêcher les applications d'utiliser cette adresse test.

Vérifiez la configuration IPv4 pour une interface spécifique.

A tout moment, pour afficher le statut actuel d'une interface, saisissez la commande ifconfig interface. Pour de plus amples informations sur l'affichage du statut d'une interface, reportez-vous à la section Méthode d'obtention d'informations sur une interface spécifique.

Vous pouvez obtenir des informations à propos de la configuration de l'adresse test d'une interface physique en spécifiant l'interface logique attribuée à l'adresse test.
# ifconfig hme0:1 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

(Facultatif) Le cas échéant, configurez une adresse de test IPv6.
# ifconfig interface inet6 -failover
Les interfaces physiques disposant d'adresses IPv6 sont placées dans le même groupe IPMP que les adresses IPv4 des interfaces. Cela se produit lorsque vous configurez l'interface physique avec des adresses IPv4 dans un groupe IPMP. Si vous placez des interfaces physiques disposant d'adresses IPv6 dans un groupe IPMP, les interfaces physiques disposant d'adresses IPv4 sont implicitement placées dans un groupe IPMP.

Par exemple, pour configurer hme0 avec une adresse test IPv6, saisissez ce qui suit :
# ifconfig hme0 inet6 -failover
Il est inutile de marquer une adresse test IPv6 comme étant désapprouvée afin d'éviter que les applications utilisent l'adresse test.

Vérifiez la configuration IPv6.

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

L'adresse test IPv6 correspond à l'adresse lien-local de l'interface.

(Facultatif) Conservation de la configuration du groupe IPMP après réinitialisation.
- Pour IPv4, ajoutez la ligne suivante au fichier /etc/hostname. interface :
  interface-address <parameters> group group-name up \ addif logical-interface -failover deprecated <parameters> up
  Dans ce cas, l'adresse test IPv4 est configurée uniquement lors de la réinitialisation suivante. Si vous souhaitez que la configuration soit appelée dans la session actuelle, effectuez les étapes 1 et 2 et éventuellement l'étape 3.
- Pour IPv6, ajoutez la ligne suivante au fichier /etc/hostname6. fichier interface :
  -failover group group-name up
  Cette adresse test IPv6 est configurée à la réinitialisation suivante. Si vous souhaitez que la configuration soit appelée dans la session actuelle, effectuez les étapes 1 et 2 et éventuellement l'étape 5.

(Facultatif) Ajoutez des interfaces supplémentaires au groupe IPMP en répétant les étapes 1 à 6.

Vous pouvez ajouter de nouvelles interfaces à un groupe existant sur un système actif. Cependant, les modifications ne sont pas conservées après réinitialisation.

Exemple 31–1 Configuration d'un groupe IPMP avec deux interfaces

En supposant que vous souhaitez effectuer ce qui suit :

définir le masque de réseau et l'adresse de réseau sur la valeur par défaut ;
configurer l'interface avec l'adresse test 192.168.85.21.

Saisissez la commande suivante :

# ifconfig hme0 addif 192.168.85.21 netmask + broadcast + -failover deprecated up

Marquez une adresse test IPv4 comme étant désapprouvée (deprecated) afin d'empêcher les applications d'utiliser cette adresse test. Reportez-vous à la section Procédure de configuration d'un groupe IPMP avec plusieurs interfaces.

Pour activer l'attribut de basculement de l'adresse, utilisez l'option failover sans le tiret.

Toutes les adresses IP test d'un groupe IPMP doivent utiliser le même préfixe de réseau. Les adresses IP test doivent appartenir à un sous-réseau IP unique.

Exemple 31–2 Conservation de la configuration du groupe IPMP IPv4 après réinitialisation

Supposons que vous souhaitez créer un groupe IPMP appelé testgroup1 avec la configuration suivante :

interface physique hme0 avec adresse de données 192.168.85.19 ;
interface logique avec adresse test 192.168.85.21 ;

Remarque –
Dans cet exemple, l'interface physique et l'adresse de données sont associées. Il en va de même pour l'interface logique et l'adresse test. Cependant, il n'existe aucune relation inhérente entre une interface type et l'adresse type.
options deprecated et -failover définies ;
masque de réseau et adresse de diffusion définie sur la valeur par défaut ;

Vous ajoutez la ligne suivante au fichier /etc/hostname.hme0 :

192.168.85.19 netmask + broadcast + group testgroup1 up \
	addif 192.168.85.21 deprecated -failover netmask + broadcast + up

De même, pour placer la seconde interface hme1 sous le même groupe testgroup1 et configurer une adresse test, ajoutez la ligne suivante :

192.168.85.20 netmask + broadcast + group testgroup1 up \
	addif 192.168.85.22 deprecated -failover netmask + broadcast + up

Exemple 31–3 Conservation de la configuration du groupe IPMP IPv6 après réinitialisation

Pour créer un groupe test pour l'interface hme0 avec une adresse IPv6, ajoutez la ligne suivante au fichier /etc/hostname6.hme0 :

-failover group testgroup1 up

De même, pour placer la seconde interface hme1 dans le groupe testgroup1 et configurer une adresse test, ajoutez la ligne suivante au fichier /etc/hostname6.hme1 :

-failover group testgroup1 up

Erreurs fréquentes

Pendant la configuration du groupe IPMP, in.mpathd génère de nombreux messages sur la console système ou dans le fichier syslog. Ces messages à caractère informatif indiquent que la configuration IPMP fonctionne correctement.

Ce message indique que l'interface hme0 a été ajoutée au groupe IPMP testgroup1. Cependant, hme0 ne possède pas d'adresse test configurée. Pour activer la détection de défaillance basée sur sonde, attribuez une adresse test à l'interface.
May 24 14:09:57 host1 in.mpathd[101180]: No test address configured on interface hme0; disabling probe-based failure detection on it. testgroup1

Ce message s'affiche pour toutes les interfaces possédant uniquement des adresses IPv4 ajoutées à un groupe IPMP.

May 24 14:10:42 host4 in.mpathd[101180]: 
NIC qfe0 of group testgroup1 is not 
plumbed for IPv6 and may affect failover capability

Ce message s'affiche après la configuration d'une adresse test pour une interface.

Created new logical interface hme0:1
May 24 14:16:53 host1 in.mpathd[101180]: 
Test address now configured on interface hme0;
 enabling probe-based failure detection on it

Voir aussi

Pour que la configuration du groupe IPMP soit de type actif-de réserve, reportez-vous à la section Procédure de configuration d'une interface de réserve pour un groupe IPMP.

Configuration de systèmes cible

La détection de défaillance basée sur sonde nécessite l'utilisation de systèmes cible, comme expliqué dans la section Détection de défaillance basée sur sonde. Pour certains groupes IPMP, les cibles par défaut utilisées par in.mpathd sont suffisantes. Cependant, pour certains groupes IPMP, il est nécessaire de configurer des cibles spécifiques pour la détection de défaillance basée sur sonde. La détection de défaillance basée sur sonde s'effectue en configurant des routes hôte en tant que cibles de sondes dans la table de routage. Les routes hôte configurées dans la table de routage figurent dans la liste avant le routeur par défaut. Par conséquent, IPMP utilise les routes hôte définies explicitement pour la sélection de cibles. Il existe deux méthodes permettant de spécifier directement les cibles : définition manuelle de routes hôte ou création d'un script shell pouvant devenir un script de démarrage.

Tenez compte des critères suivants lorsque vous devez sélectionner les hôtes de votre réseau les plus adaptés en tant que cibles.

Assurez-vous que les cibles potentielles sont disponibles et en cours d'exécution. Établissez la liste de leurs adresses IP.
Assurez-vous que les interfaces cible se trouvent sur le même réseau que le groupe IPMP configuré.
Le masque de réseau et l'adresse de diffusion des systèmes cible doivent être les mêmes que ceux du groupe IPMP.
L'hôte cible doit pouvoir répondre aux requêtes ICMP provenant de l'interface qui utilise la détection de défaillance basée sur sonde.

Procédure de spécification manuelle de systèmes cible pour la détection de défaillance basée sur sonde

Connectez-vous à l'aide de votre compte utilisateur au système dans lequel vous configurez la détection de défaillance basée sur sonde.

Ajoutez une route à un hôte spécifique, à utiliser en tant que cible dans le cadre de la détection de défaillance basée sur sonde.
$ route add -host destination-IP gateway-IP -static
Remplacez les valeurs de IP-destination et IP-passerelle par l'adresse IPv4 de l'hôte à utiliser en tant que cible. Par exemple, saisissez ce qui suit afin de spécifier le système cible 192.168.85.137 qui se trouve sur le même sous-réseau que les interfaces du groupe IPMP testgroup1.
$ route add -host 192.168.85.137 192.168.85.137 -static

Ajoutez les routes vers les hôtes supplémentaires du réseau à utiliser en tant que systèmes cible.

Procédure de spécification de systèmes cible dans un script shell

Sur le système sur lequel vous avez configuré un groupe IPMP, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Créez un script shell définissant les routes statiques vers les cibles proposées.

Par exemple, vous pouvez créer un script shell intitulé ipmp.targets avec le contenu suivant :

TARGETS="192.168.85.117 192.168.85.127 192.168.85.137"

case "$1" in
        'start')
            /usr/bin/echo "Adding static routes for use as IPMP targets"
		for target in $TARGETS; do
	  /usr/sbin/route add -host $target $target
		done
                  ;;
        'stop')
              /usr/bin/echo "Removing static routes for use as IPMP targets"
		 for target in $TARGETS; do
		/usr/sbin/route delete -host $target $target
		 done
                  ;;
  esac

Copiez le script shell dans le répertoire du script de démarrage.
# cp ipmp.targets /etc/init.d

Modifiez les permissions dans le nouveau script de démarrage.
# chmod 744 /etc/init.d/ipmp.targets

Modifiez la propriété du nouveau script de démarrage.
# chown root:sys /etc/init.d/ipmp.targets

Créez une liaison pour le script de démarrage dans le répertoire /etc/init.d.
# ln /etc/init.d/ipmp.targets /etc/rc2.d/S70ipmp.targets
Le préfixe S70 dans le nom de fichier S70ipmp.targets ordonne le nouveau script correctement en fonction des autres scripts de démarrage.

Configuration d'interfaces de réserve

Cette procédure permet d'attribuer une configuration active-de réserve au groupe IPMP. Pour obtenir des informations supplémentaires sur ce type de configuration, reportez-vous à la section Configurations d'interfaces IPMP.

Procédure de configuration d'une interface de réserve pour un groupe IPMP

Avant de commencer

Toutes les interfaces doivent être configurées en tant que membres du groupe IPMP.
Ne configurez pas d'adresse test sur l'interface pour la définir en tant qu'interface de réserve.

Pour obtenir des informations sur la configuration d'un groupe IPMP et l'attribution d'adresses test, reportez-vous à la section Procédure de configuration d'un groupe IPMP avec plusieurs interfaces.

Sur le système sur lequel vous devez configurer les interfaces de réserve, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Configurez une interface en tant qu'interface de réserve et attribuez l'adresse test.
# ifconfig interface plumb \ ip-address other-parameters deprecated -failover standby up
Une interface de réserve ne peut disposer que d'une adresse IP, l'adresse test. Définissez l'option -failover avant l'option standby up. Pour <other-parameters>, utilisez les paramètres requis par votre configuration, tels que décrits dans la page de manuel ifconfig(1M).
- Par exemple, la commande suivante permet de créer une adresse test IPv4 :
  # ifconfig hme1 plumb 192.168.85.22 netmask + broadcast + deprecated -failover standby up
  hme1
  
  Définit hme1 comme étant l'interface physique à configurer en tant qu'interface de réserve.
  
  192.168.85.22
  
  Atrtibue cette adresse test à l'interface de réserve.
  
  deprecated
  
  Indique que l'adresse test n'est pas utilisée pour les paquets sortants.
  
  -failover
  
  Indique que l'adresse test ne bascule pas en cas de défaillance de l'interface.
  
  standby
  
  Marque l'interface comme étant l'interface de réserve.
- Par exemple, la commande suivante permet de créer une adresse test IPv6 :
  # ifconfig hme1 plumb -failover standby up

Vérifiez les résultats de la configuration de l'interface de réserve.

# ifconfig hme1
hme1: flags=69040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,
      STANDBY,INACTIVE mtu 1500 
         index 4 inet 192.168.85.22 netmask ffffff00 broadcast 19.16.85.255
         groupname test

L'indicateur INACTIVE indique que cette interface n'est pas utilisée pour les paquets sortants. En cas de basculement vers cette interface de réserve, l'indicateur INACTIVE est effacé.

Remarque –

La commande ifconfig interface permet de vérifier le statut d'une interface. Pour de plus amples informations sur l'affichage du statut d'une interface, reportez-vous à la section Méthode d'obtention d'informations sur une interface spécifique .

(Facultatif) Conservez l'interface de réserve IPv4 après réinitialisation.

Attribuez l'interface au même groupe IPMP et configurez une adresse test pour l'interface de réserve.

Par exemple, pour configurer hme1 en tant qu'interface de réserve, ajoutez la ligne suivante au fichier /etc/hostname.hme1 :
192.168.85.22 netmask + broadcast + deprecated group test -failover standby up

(Facultatif) Conservez l'interface de réserve IPv6 après réinitialisation.

Attribuez l'interface au même groupe IPMP et configurez une adresse test pour l'interface de réserve.

Par exemple, pour configurer hme1 en tant qu'interface de réserve, ajoutez la ligne suivante au fichier /etc/hostname6.hme1 :
-failover group test standby up

Exemple 31–4 Configuration d'une interface de réserve pour un groupe IPMP

En supposant que vous souhaitez créer une adresse test avec la configuration suivante :

interface physique hme2 en tant qu'interface de réserve ;
adresse test de 192.168.85.22 ;
options deprecated et -failover définies ;
masque de réseau et adresse de diffusion définie sur la valeur par défaut ;

Vous devez taper ce qui suit :

# ifconfig hme2 plumb 192.168.85.22 netmask + broadcast + \
deprecated -failover standby up

L'interface est marquée comme interface de réserve une fois que l'adresse est marquée comme étant sans basculement (NOFAILOVER).

Saisissez ce qui suit afin de supprimer le statut d'interface de réserve d'une interface :

# ifconfig interface -standby

Configuration de groupes IPMP avec une interface physique unique

Le basculement est impossible lorsqu'un groupe IPMP dispose d'une seule interface. Cependant, vous pouvez activer la détection de défaillance sur cette interface en l'attribuant à un groupe IPMP. Il est inutile de configurer une adresse IP test dédiée afin d'établir la détection de défaillance pour un groupe IPMP à interface unique. Vous pouvez utiliser une adresse IP unique pour l'envoi de données et la détection de défaillance.

Procédure de configuration d'un groupe IPMP à interface unique

Sur le système possédant le groupe IPMP à interface unique, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Pour IPv4, créez le groupe IPMP à interface unique.

La syntaxe suivante permet d'attribuer une interface unique à un groupe IPMP.
# ifconfig interface group group-name
Dans l'exemple suivant, l'interface hme0 est attribuée au groupe IPMP v4test :
# ifconfig hme0 group v4test
Une fois cette étape effectuée, IPMP active la détection de défaillance basée sur lien sur l'interface.

En outre, vous pouvez activer la détection de défaillance basée sur sonde à l'aide de la sous-commande -failover de ifconfig. Dans l'exemple suivant, la détection de défaillance basée sur sonde est activée sur hme0 à l'aide de l'adresse IP assignée à hme0:
# ifconfig hme0 -failover
Contrairement aux groupes comptant plusieurs interfaces, la même adresse IP peut servir d'adresse de données et d'adresse de test. Pour que l'adresse de test puisse être utilisée comme adresse de données par les applications, elle ne doit jamais être signalée comme désapprouvée dans les groupes IPMP à interface unique.

Pour IPv6, créez le groupe IPMP à interface unique.

La syntaxe suivante permet d'attribuer une interface unique à un groupe IPMP :
# ifconfig interface inet6 group group-name
Par exemple, pour ajouter l'interface unique hme0 dans le groupe IPMP v6test, saisissez ce qui suit :
# ifconfig hme0 inet6 group v6test
Une fois cette étape effectuée, IPMP active la détection de défaillance basée sur lien sur l'interface.

En outre, vous pouvez activer la détection de défaillance basée sur sonde à l'aide de la sous-commande -failover de ifconfig. Dans l'exemple suivant, la détection de défaillance basée sur sonde est activée sur hme0 à l'aide de l'adresse IP assignée à hme0:
# ifconfig hme0 inet6 -failover
Contrairement aux groupes comptant plusieurs interfaces, la même adresse IP peut servir d'adresse de données et d'adresse de test. Pour que l'adresse de test puisse être utilisée comme adresse de données par les applications, elle ne doit jamais être signalée comme désapprouvée dans les groupes IPMP à interface unique.

Dans une configuration d'interface physique unique, il est impossible de vérifier si la défaillance s'est produite au niveau du système cible analysé ou au niveau de l'interface. Il est possible d'analyser le système cible en passant par une seule interface physique. Si un seul routeur par défaut se trouve sur le sous-réseau, désactivez IPMP si le groupe contient une interface physique unique. Si un routeur IPv4 et IPv6 par défaut distinct existe, ou si plusieurs routeurs par défaut existent, il est nécessaire d'analyser plusieurs systèmes cible. Vous pouvez par conséquent activer IPMP.

Maintenance de groupes IPMP

Cette section décrit les tâches relatives à la maintenance de groupes IPMP existants et des interfaces qui composent ces groupes. Cette tâche suppose que vous avez déjà configuré un groupe IPMP, tel que décrit dans la section Configuration de groupes IPMP.

Procédure d'affichage de l'appartenance d'une interface à un groupe IPMP

Sur le système sur lequel est configuré le groupe IPMP, connectez-vous en tant que superutilisateur (ou équivalent).

Les rôles contiennent des autorisations et des commandes privilégiées. Pour de plus amples informations sur les rôles, reportez-vous à la section Configuring RBAC (Task Map) du System Administration Guide: Security Services.

Affichage d'informations sur l'interface, y compris le groupe auquel appartient l'interface.
# ifconfig interface

Le cas échéant, affichez les informations IPv6 de l'interface.
# ifconfig interface inet6

Exemple 31–5 Affichage de groupes d'interfaces physiques

Saisissez ce qui suit afin d'afficher le nom de groupe de hme0 :

# ifconfig hme0
	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 testgroup1

Saisissez ce qui suit afin d'afficher le nom de groupe uniquement pour les informations IPv6 :

# ifconfig hme0 inet6
	hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
        	inet6 fe80::a00:20ff:feb9:19fa/10 
        	groupname testgroup1

Procédure d'ajout d'une interface à un groupe IPMP

Sur le système sur lequel est configuré le groupe IPMP, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Ajoutez l'interface au groupe IPMP.
# ifconfig interface group group-name
L'interface spécifiée dans interface devient membre du groupe IPMP nom-groupe.

Exemple 31–6 Ajout d'une interface à un groupe IPMP

Saisissez la commande suivante afin d'ajouter hme0 au groupe IPMP testgroup2 :

# ifconfig hme0 group testgroup2
  hme0: flags=9000843<UP ,BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER> mtu 1500 index 2
  inet 192.168.85.19 netmask ff000000 broadcast 10.255.255.255
  groupname testgroup2
  ether 8:0:20:c1:8b:c3

Procédure de suppression d'une interface d'un groupe IPMP

Lorsque vous exécutez le paramètre group de la commande ifconfig avec une chaîne vide, l'interface est supprimée du groupe IPMP actuel. Faites preuve de prudence lors de la suppression d'interfaces à partir d'un groupe. Dans le cas d'une défaillance d'une autre interface du groupe IPMP, un basculement a pu se produire antérieurement. Par exemple, en cas de défaillance antérieure de hme0, toutes les adresses basculent vers hme1, si hme1 fait partie du même groupe. En cas de suppression de hme1 du groupe, le démon in.mpathd renvoie toutes les adresses de basculement à une autre interface du groupe. Si aucune autre interface ne fonctionne dans le groupe, le basculement risque de ne pas restaurer la totalité des accès réseau.

De même, lorsqu'une interface dans un groupe doit être démontée, commencez par retirer l'interface du groupe. Vérifiez ensuite que toutes les adresses IP d'origine de l'interface sont configurées. Le démon in.mpathd tente de restaurer la configuration d'origine d'une interface supprimée du groupe. Avant de démonter l'interface, assurez-vous que la configuration est restaurée. Reportez-vous à la section Description du basculement d'interface afin d'obtenir une description des interfaces avant et après basculement.

Sur le système sur lequel est configuré le groupe IPMP, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Supprimez l'interface du groupe IPMP.
# ifconfig interface group ""
Les guillemets indiquent une chaîne vide.

Exemple 31–7 Suppression d'une interface d'un groupe

Saisissez la commande suivante afin de supprimer hme0 du groupe IPMP test :

# ifconfig hme0 group ""
	# ifconfig hme0
	hme0: flags=9000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
    index 2 inet 192.168.85.19 netmask ffffff00 broadcast 192.168.85.255
	# ifconfig hme0 inet6
	hme0: flags=a000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2
    inet6 fe80::a00:20ff:feb9:19fa/10

Procédure de déplacement d'une interface d'un groupe IPMP vers un autre

Vous pouvez placer une interface dans un nouveau groupe IPMP lorsque l'interface appartient à un groupe IPMP. Il est inutile de supprimer l'interface du groupe IPMP actuel. Lorsque vous placez l'interface dans un nouveau groupe, l'interface est automatiquement retirée de tout groupe IPMP existant.

Sur le système sur lequel est configuré le groupe IPMP, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Déplacez l'interface vers un nouveau groupe IPMP.
# ifconfig interface group group-name
Si vous placez l'interface dans un nouveau groupe, elle est automatiquement retirée de tout groupe existant.

Exemple 31–8 Déplacement d'une interface vers un autre groupe IPMP

Pour modifier le groupe IPMP de l'interface hme0, saisissez ce qui suit :

# ifconfig hme0 group cs-link

Cette commande permet de supprimer l'interface hme0 du groupe IPMP test, puis de placer l'interface dans le groupe cs-link.

Remplacement d'une interface physique défaillante sur des systèmes prenant la DR en charge

Cette section décrit les procédures relatives à l'administration de systèmes prenant en charge la reconfiguration dynamique (DR).

Remarque –

Les tâches ne s'appliquent qu'aux couches IP configurées à l'aide de la commande ifconfig. Les couches avant ou après la couche IP, comme l'ATM ou autres services, requièrent des étapes manuelles si les couches ne sont pas automatisées. Les étapes des procédures suivantes permettent d'annuler la configuration des interfaces lors de la préconnexion et de configurer une interface après la postconnexion.

Procédure de suppression d'une interface physique défaillante (DR puis déconnexion)

Cette procédure indique la méthode de retrait d'une interface physique d'un système prenant la reconfiguration dynamique en charge. Elle part du principe que les conditions suivantes existent déjà :

Les interfaces physiques hme0 et hme1 sont les interfaces d'exemple.
Les interfaces se trouvent dans le même groupe IPMP.
hme0 est défaillante.
L'interface logique hme0:1 possède l'adresse test.
Le nom de l'interface défaillante est remplacé par le même nom d'interface physique, par exemple, hme0 par hme0.

Remarque –

Vous pouvez ignorer l'étape 2 si l'adresse test est montée à l'aide du fichier /etc/hostname.hme0.

Sur le système sur lequel est configuré le groupe IPMP, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Affichez la configuration d'adresse test.

# ifconfig hme0:1

hme0:1:
flags=9040842<BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER>
mtu 1500 index 3
inet 192.168.233.250 netmask ffffff00 broadcast 192.168.233.255

Ces informations sont nécessaires afin de remonter l'adresse test lors du remplacement de l'interface physique.

Supprimez l'interface physique.

Reportez-vous aux sources suivantes pour obtenir une description complète de la méthode de suppression de l'interface physique :
- Page de manuel cfgadm(1M).
- Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide
- Sun Enterprise 10000 DR Configuration Guide

Procédure de remplacement d'une interface physique défaillante (DR puis connexion)

Cette procédure correspond à la méthode de remplacement d'une interface physique d'un système prenant la DR en charge.

Sur le système sur lequel est configuré le groupe IPMP, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Remplacez l'interface physique.

Vous pouvez consulter les sources suivantes pour obtenir des instructions :
- Page de manuel cfgadm(1M).
- Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide
- Sun Enterprise 10000 DR Configuration Guide ou Sun Fire 880 Dynamic Reconfiguration User's Guide

Récupération d'une interface physique absente à l'initialisation du système

Remarque –

La procédure suivante s'applique uniquement aux couches IP configurées à l'aide de la commande ifconfig. Les couches avant ou après la couche IP, comme l'ATM ou autres services, requièrent des étapes manuelles si les couches ne sont pas automatisées. Les étapes spécifiques de la procédure suivante permettent d'annuler la configuration d'interface lors de la prédéconnexion et de configurer les interfaces après la postconnexion.

La reprise après reconfiguration dynamique est automatique pour une interface faisant partie de la carte E/S d'une plate-forme Sun Fire™. Si la carte d'interface réseau est une carte Sun Crypto Accelerator I - cPCI, la récupération est également automatique. Par conséquent, les étapes suivantes ne sont pas nécessaires dans le cas d'une interface récupérée lors d'une opération de reconfiguration dynamique. Pour de plus amples informations sur les systèmes Sun Fire x800 et Sun Fire 15000, consultez la page de manuel cfgadm_sbd(1M) L'interface physique est rétablie selon la configuration spécifiée dans le fichier /etc/hostname. fichier interface. Reportez-vous à la section Configuration de groupes IPMP pour obtenir des informations supplémentaires sur la configuration d'interfaces afin de conserver la configuration après réinitialisation.

Remarque –

Dans les systèmes Sun Fire legacy (Exx00), les connexions de reconfiguration dynamique requièrent encore des procédures manuelles. Cependant, les connexions de reconfiguration dynamique sont automatiques.

Procédure de récupération d'une interface physique absente lors de l'initialisation du système

Avant de récupérer une interface physique absente lors de l'initialisation du système, vous devez effectuer les procédures suivantes. Dans l'exemple de cette procédure, la configuration est la suivante :

Les interfaces physiques hme0 et hme1 sont les interfaces.
Les interfaces se trouvent dans le même groupe IPMP.
hme0 n'était pas installé lors de l'initialisation du système.

Remarque –

Le rétablissement d'adresses IP lors de la réparation d'une interface physique défaillante peut prendre jusqu'à trois minutes. Cette durée varie en fonction du trafic réseau. Elle dépend également de la stabilité de l'interface entrante afin de rétablir les interfaces basculées par le démon in.mpathd.

Sur le système sur lequel est configuré le groupe IPMP, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Les informations relatives au réseau défaillant sont indiquées dans le message d'erreur du journal de la console.

Consultez la page de manuel syslog(3C) Le message d'erreur est similaire à ce qui suit :
moving addresses from failed IPv4 interfaces: hme1 (moved to hme0)
Ce message indique que les adresses IPv4 de l'interface défaillante hme1 ont basculé vers l'interface hme0.

Vous pouvez également recevoir le message suivant :
moving addresses from failed IPv4 interfaces: hme1 (couldn't move, no alternative interface)
Ce message indique qu'aucune interface active n'a pu être trouvée dans le groupe de l'interface défaillante hme1. Par conséquent, le basculement des adresses IPv4 vers hme1 ne s'est pas effectué.

Connectez l'interface physique au système.

Reportez-vous aux sources suivantes pour obtenir des instructions sur le remplacement de l'interface physique :
- Page de manuel cfgadm(1M).
- Sun Enterprise 10000 DR Configuration Guide
- Sun Enterprise 6x00, 5x00, 4x00, and 3x00 Systems Dynamic Reconfiguration User's Guide

Reportez-vous au contenu du message de l'étape 2. Si les adresses n'ont pu être déplacées, passez à l'étape 6. Si les adresses ont été déplacées, passez à l'étape 5.

Démontez les interfaces logiques configurées au cours du processus de basculement.
1. Consultez le contenu du fichier /etc/hostname. déplacé-de-interface, afin de connaître les interfaces logiques configurées en tant qu'élément du processus de basculement.
2. Démontez chaque adresse IP de basculement.
  # ifconfig moved-to-interface removeif moved-ip-address
  Remarque –
  Les adresses de basculement sont marquées à l'aide du paramètre failover ou ne sont pas marquées avec le paramètre -failover. Il est inutile de démonter les adresses IP marquées à l'aide du paramètre -failover.
  
  Par exemple, si l'on admet que le fichier /etc/hostname.hme0 contient les lignes suivantes :
  inet 10.0.0.4 -failover up group one addif 10.0.0.5 failover up addif 10.0.0.6 failover up
  Pour démonter l'adresse IP de basculement, vous devez saisir la commande suivante :
  # ifconfig hme0 removeif 10.0.0.5 # ifconfig hme0 removeif 10.0.0.6

Reconfigurez les informations IPv4 de l'interface physique remplacée en saisissant la commande suivante pour chaque interface supprimée :

# ifconfig removed-from-NIC <parameters>

Vous pouvez par exemple saisir les commandes suivantes :

# ifconfig hme1 inet plumb
# ifconfig hme1 inet 10.0.0.4 -failover up group one
# ifconfig hme1 addif 10.0.0.5 failover up
# ifconfig hme1 addif 10.0.0.6 failover up

Modification des configurations IPMP

Le fichier de configuration IPMP /etc/default/mpathd permet de configurer les paramètres système suivants des groupes IPMP.

FAILURE_DETECTION_TIME
TRACK_INTERFACES_ONLY_WITH_GROUPS
FAILBACK

Procédure de configuration du fichier `/etc/default/mpathd`

Sur le système sur lequel est configuré le groupe IPMP, connectez-vous en tant qu'administrateur principal ou superutilisateur.

Le rôle d'administrateur principal inclut le profil d'administrateur principal. Pour plus d'informations sur la création d'un rôle et son assignation à un utilisateur, reportez-vous au Chapitre 2, Working With the Solaris Management Console (Tasks) du System Administration Guide: Basic Administration.

Modifiez le fichier /etc/default/mpathd.

Modifiez la valeur par défaut d'au moins un des trois paramètres.
1. Saisissez la nouvelle valeur du paramètre FAILURE_DETECTION_TIME.
  FAILURE_DETECTION_TIME=n
  où n correspond à la durée en secondes nécessaire aux sondes ICMP pour la détection d'une éventuelle défaillance d'interface. La valeur par défaut est de 10 secondes.
2. Saisissez la nouvelle valeur du paramètre FAILBACK.
  FAILBACK=[yes | no]
  - yes- La valeur yes correspond au comportement de basculement par défaut d'IPMP. En cas de détection de réparation d'une interface défaillante, l'accès réseau est rétabli à l'aide de l'interface réparée, tel que décrit dans la section Détection de défaillance d'IPMP et fonctionnalités de reprise.
  - no - La valeur no indique que le trafic de données n'est pas rétabli sur une interface réparée. En cas de détection d'une interface réparée, l'indicateur INACTIVE est défini pour celle-ci. L'indicateur indique qu'il est actuellement impossible d'utiliser l'interface pour le trafic de données. Il est cependant possible de l'utiliser pour le trafic de sondes.
    
    Supposons par exemple qu'un groupe IPMP se compose de deux interfaces, ce0 et ce1. Supposons ensuite que la valeur FAILBACK=no est définie dans /etc/default/mpathd. En cas de défaillance de ce0 son trafic bascule vers ce1, ce qui correspond au comportement attendu d'IPMP. Cependant, si IPMP détecte que l'interface ce0 est réparée, le trafic n'est par rétabli à partir de ce1, en raison du paramètre FAILBACK=no dans /etc/default/mpathd. L'interface ce0 conserve le statut INACTIVE et n'est pas utilisée pour le trafic, sauf en cas de défaillance de l'interface ce1. En cas de défaillance de l'interface ce1, les adresses sur ce1 sont déplacées vers ce0, dont l'indicateur INACTIVE est alors effacé. Ce déplacement se produit à condition que ce0 soit la seule interface INACTIVE du groupe. Si c'est le cas d'autres interfaces du groupe, les adresses risquent d'être déplacées vers une interface INACTIVE différente de ce0.
3. Saisissez la nouvelle valeur du paramètre TRACK_INTERFACES_ONLY_WITH_GROUPS .
  TRACK_INTERFACES_ONLY_WITH_GROUPS=[yes | no]
  - yes- La valeur yes correspond au comportement par défaut d'IPMP. Ce paramètre permet à IPMP d'ignorer les interfaces réseau qui ne sont pas configurées dans un groupe IPMP.
  - no - La valeur no définit la détection de défaillance et de réparation pour toutes les interfaces réseau, qu'elles soient configurées ou non dans un groupe IPMP. Cependant, lorsqu'une défaillance ou une réparation est détectée sur une interface non configurée dans un groupe IPMP, aucun basculement ni rétablissement ne se produit. Par conséquent, la valeur no est utile uniquement pour les rapports de défaillances et n'améliore pas directement la disponibilité du réseau.

Redémarrez le démon in.mpathd.
# pkill -HUP in.mpathd

Partie VI IPMP

Chapitre 30 Présentation d'IPMP

Avantages d'IPMP

Composants IPMP Oracle Solaris

Démon de multiacheminement in.mpathd

Terminologie et concepts IPMP

Liaison IP

Interface physique

Carte d'interface réseau

Groupe IPMP

Détection de défaillance et basculement

Détection de réparation et rétablissement

Système cible

Répartition de charge sortante

Reconfiguration dynamique

Exigences de base d'IPMP

Adressage IPMP

Adresses de données

Adresses test

Adresses test IPv4

Adresses test IPv6

Empêcher les applications d'utiliser les adresses test

Configurations d'interfaces IPMP

Interfaces de réserve d'un groupe IPMP

Configurations courantes d'interfaces d'IPMP

Vérification du statut d'une interface

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

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

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

Défaillances de groupe

Détection de réparation d'interface physique

Description du basculement d'interface

Exemple 30–1 Configuration d'interface avant une défaillance

Exemple 30–2 Configuration d'interface après une défaillance

IPMP et reconfiguration dynamique

Connexion de cartes d'interface réseau

Déconnexion de cartes d'interface réseau

Reconnexion d'une carte d'interface réseau

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

Chapitre 31 Administration d'IPMP (tâches)

Configuration d'IPMP (liste des tâches)

Configuration et administration de groupes IPMP (liste des tâches)

Administration d'IPMP sur des interfaces prenant en charge la reconfiguration dynamique (liste des tâches)

Configuration de groupes IPMP

Planification d'un groupe IPMP

Procédure de planification pour un groupe IPMP

Configuration de groupes IPMP

Procédure de configuration d'un groupe IPMP avec plusieurs interfaces

Avant de commencer

Exemple 31–1 Configuration d'un groupe IPMP avec deux interfaces

Exemple 31–2 Conservation de la configuration du groupe IPMP IPv4 après réinitialisation

Exemple 31–3 Conservation de la configuration du groupe IPMP IPv6 après réinitialisation

Erreurs fréquentes

Voir aussi

Configuration de systèmes cible

Procédure de spécification manuelle de systèmes cible pour la détection de défaillance basée sur sonde

Procédure de spécification de systèmes cible dans un script shell

Configuration d'interfaces de réserve

Procédure de configuration d'une interface de réserve pour un groupe IPMP

Avant de commencer

Exemple 31–4 Configuration d'une interface de réserve pour un groupe IPMP

Configuration de groupes IPMP avec une interface physique unique

Procédure de configuration d'un groupe IPMP à interface unique

Maintenance de groupes IPMP

Procédure d'affichage de l'appartenance d'une interface à un groupe IPMP

Exemple 31–5 Affichage de groupes d'interfaces physiques

Procédure d'ajout d'une interface à un groupe IPMP

Exemple 31–6 Ajout d'une interface à un groupe IPMP

Procédure de suppression d'une interface d'un groupe IPMP

Exemple 31–7 Suppression d'une interface d'un groupe

Procédure de déplacement d'une interface d'un groupe IPMP vers un autre

Exemple 31–8 Déplacement d'une interface vers un autre groupe IPMP

Remplacement d'une interface physique défaillante sur des systèmes prenant la DR en charge

Procédure de suppression d'une interface physique défaillante (DR puis déconnexion)

Procédure de remplacement d'une interface physique défaillante (DR puis connexion)

Récupération d'une interface physique absente à l'initialisation du système

Procédure de récupération d'une interface physique absente lors de l'initialisation du système

Modification des configurations IPMP

Procédure de configuration du fichier /etc/default/mpathd

Démon de multiacheminement `in.mpathd`

Procédure de configuration du fichier `/etc/default/mpathd`