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
Détection de réparation d'interface physique
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
Vous pouvez configurer la détection de défaillance IPMP sur des réseaux IPv4, ainsi que sur des réseaux IPv4 et IPv6 double pile. Les interfaces configurées avec IPMP prennent en charge deux types d'adresses présentés dans les sections suivantes. A partir d'Oracle Solaris 11, les adresses IP résident uniquement sur l'interface IPMP et sont spécifiées en tant qu'adresses de données, alors que les adresses de test résident sur les interfaces sous-jacentes.
Les adresses de données désignent les adresses IPv4 et IPv6 conventionnelles attribuées à une interface IP de manière dynamique au moment de l'initialisation par le serveur DHCP ou manuellement par le biais de la commande ipadm. Les adresses de données sont affectées à l'interface IPMP. Le trafic de paquets standard IPv4 et, le cas échéant, IPv6, est considéré comme du trafic de données. Le trafic de données utilise les adresses de données hébergées sur l'interface IPMP et le flux à travers les interfaces actives de ce groupe ou cette interface IPMP.
Les adresses de test désignent les adresses propres à IPMP permettant au démon in.mpathd d'effectuer les opérations de détection de défaillance et de réparation basée sur sonde. Des adresses de test peuvent également être attribuées de façon dynamique par le serveur DHCP ou manuellement par le biais la commande ipadm. Seules des adresses de test sont associées aux interfaces sous-jacentes du groupe IPMP. Lorsqu'une interface sous-jacente échoue, l'adresse de test de l'interface continue d'être utilisé par le démon in.mpathd pour la détection de défaillance basée sur sonde pour vérifier la réparation qui suit.
Remarque - Il faut configurer des adresses de test uniquement si vous souhaitez activer la détection de défaillance basée sur sonde. Dans le cas contraire, vous pouvez activer le test transitif pour détecter la défaillance sans utiliser des adresses de test. Pour de plus amples informations sur la détection de défaillance basée sur sonde avec ou sans adresses de test, reportez-vous à la section Détection de défaillance basée sur sonde.
Dans les précédentes implémentations IPMP, il fallait marquer les adresses de test comme DEPRECATED pour empêcher leur utilisation par les applications, en particulier en cas de défaillance d'interface. Dans l'implémentation actuelle, des adresses de test se trouvent dans les interfaces sous-jacentes. Ainsi, ces adresses ne peuvent plus être utilisées accidentellement par des applications qui ne sont pas compatibles avec IPMP. Cependant, pour vous assurer que ces adresses ne sont pas considérées comme une source possible pour les paquets de données, le système les marque automatiquement avec l'indicateur NOFAILOVER ainsi que DEPRECATED.
Vous pouvez définir l'adresse IPv4 de votre choix sur le sous-réseau en tant qu'adresse de test. 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 échange des sondes ICMP uniquement avec d'autres hôtes situés sur le même sous-réseau que l'adresse de test. Si vous utilisez des adresses test de type RFC 1918, veillez à configurer d'autres systèmes, des routeurs de préférence, sur le réseau 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. Pour plus d'informations sur les adresses privées RFC 1918, reportez-vous au document RFC 1918, Address Allocation for Private Internets (en anglais).
La seule adresse de test IPv6 valide correspond à l'adresse link-local d'une interface physique. Inutile de définir une adresse IPv6 distincte en tant qu'adresse de test IPMP. L'adresse link-local IPv6 est basée sur l'adresse MAC (Media Access Control) de l'interface. Les adresses link-local sont configurées automatiquement lorsque l'interface devient compatible IPv6 au moment de l'initialisation ou lorsque l'interface est configurée manuellement par le biais de la commande ipadm.
Lorsqu'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 link-local IPv6 en tant qu'adresses test.