Ignorer les liens de navigation | |
Quitter l'aperu | |
![]() |
Gestion des performances du réseau Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
1. Présentation de la gestion des performances du réseau
2. Utilisation des groupements de liaisons
3. Utilisation des réseaux locaux virtuels (VLAN)
4. Administration des réseaux pontés (tâches)
5. Présentation de la fonctionnalité de chemins d'accès multiples sur réseau IP (IPMP)
Avantages de l'utilisation de la fonctionnalité de chemins d'accès multiples sur réseau IP
Règles d'utilisation de la fonctionnalité de chemins d'accès multiples sur réseau IP
Types de configurations d'interface IPMP
Fonctionnement de la fonctionnalité de chemins d'accès multiples sur réseau IP (IPMP)
Détection de défaillance dans IPMP
Détection de défaillance basée sur sonde
Détection de défaillance basée sur sonde avec des adresses de test
Détection de défaillance basée sur sonde sans utiliser d'adresses de test
Détection de défaillance basée sur les liaisons
Détection de défaillance et fonction de groupe anonyme
IPMP et reconfiguration dynamique
6. Administration de la fonctionnalité de chemins d'accès multiples sur réseau IP (tâches)
7. Echange d'informations sur la connectivité réseau à l'aide du protocole LLDP
8. Utilisation des fonctionnalités Data Center Bridging dans Oracle Solaris
9. Pontage virtuel d'extrémité dans Oracle Solaris
10. Equilibreur de charge intégré (présentation)
11. Configuration de l'équilibreur de charge intégré
12. Gestion de l'équilibreur de charge intégré
13. Protocole de redondance de routeur virtuel (présentation)
A. Types de groupements de liaisons : comparaison des fonctionnalités
B. Groupement de liaisons et IPMP : comparaison des fonctionnalités
Le temps de détection de réparation est le double du temps de détection de défaillance. Le temps de détection de défaillance par défaut est de 10 secondes. Par conséquent, le temps détection de réparation par défaut est de 20 secondes. Dès qu'une interface défaillante porte de nouveau l'indicateur RUNNING et que la méthode de détection de défaillance la considère comme réparée, le démon in.mpathd efface l'indicateur FAILED de l'interface. L'interface réparée est redéployée en fonction du nombre d'interfaces actives que l'administrateur a définies au départ.
Lorsqu'une interface sous-jacente tombe en panne et que la détection de défaillance basée sur sonde est utilisée, le démon in.mpathd poursuit le test, soit par le biais du "prober" désigné si aucune adresse de test n'est configurée, soit à l'aide de l'adresse de test de l'interface. Au cours de la réparation d'une interface, le processus se poursuit en fonction de la configuration d'origine de l'interface défaillante :
Si l'interface défaillante était active à l'origine, l'interface réparée reprend son état actif initial. L'interface de secours qui a pris le relais lors de la défaillance repasse à l'état standby si suffisamment d'interfaces sont actives dans le groupe, tel que défini par l'administrateur système.
Remarque - Une exception à cette règle se présente si l'interface active réparée est également configurée en mode FAILBACK=no. Pour plus d'informations, reportez-vous à la section Mode FAILBACK=no.
Si l'interface défaillante était à l'origine une interface de secours, l'interface réparée revient à son état de secours d'origine, à condition que le groupe IPMP reflète le nombre initial d'interfaces actives. Autrement, l'interface de secours devient une interface active.
Pour une présentation graphique du comportement de la fonctionnalité de chemins d'accès multiples sur réseau IP pendant la panne et la réparation d'une interface, reportez-vous à la section Fonctionnement de la fonctionnalité de chemins d'accès multiples sur réseau IP (IPMP).
Par défaut, les interfaces actives qui ont subi une défaillance redeviennent automatiquement des interfaces actives dans le groupe IPMP après leur réparation. Ce comportement est contrôlé par la valeur du paramètre FAILBACK dans le fichier de configuration du démon in.mpathd. Cependant, même les perturbations insignifiantes, qui se produisent lorsque les adresses de données sont remappées pour réparer des interfaces, peuvent ne pas être acceptable pour certains administrateurs. Les administrateurs peuvent préférer autoriser une interface de secours activée à continuer à jouer le rôle d'interface active. IPMP permet aux administrateurs de contourner le comportement par défaut pour empêcher une interface de devenir automatiquement active après sa réparation. Ces interfaces doivent être configurées dans le mode FAILBACK=no. Pour connaître les procédures connexes, reportez-vous à la section Configuration du comportement du démon IPMP .
Lorsqu'une interface active en mode FAILBACK=no subit une panne et est ensuite réparée, le démon in.mpathd restaure la configuration IPMP comme suit :
Le démon conserve l'état INACTIVE de l'interface, à condition que le groupe IPMP reflète la configuration d'origine des interfaces actives.
Si, au moment de la réparation, la configuration IPMP ne reflète pas la configuration d'origine du groupe des interfaces actives, l'interface réparée est redéployée comme interface active, malgré l'état FAILBACK=no.
Remarque - Le mode FAILBACK=NO est défini pour l'ensemble du groupe IPMP. Il ne s'agit pas d'un paramètre réglable par interface.