Ignorer les liens de navigation | |
Quitter l'aperu | |
Administration d'Oracle Solaris : Interfaces réseau et virtualisation réseau Oracle Solaris 11 Information Library (Français) |
1. Présentation de la pile réseau
Configuration réseau dans cette version d'Oracle Solaris
Pile réseau dans Oracle Solaris
Noms des périphériques réseau et des liaisons de données
Administration d'autres types de liens
Partie I Configuration automatique de réseau
3. Configuration et administration NWAM (présentation)
4. Configuration de profil NWAM (tâches)
5. Administration des profils NWAM (tâches)
6. A propos de l'interface graphique NWAM
Partie II Configuration de liaisons de données et d'interfaces
8. Configuration et administration des liaisons de données
9. Configuration d'une interface IP
10. Configuration des communications via une interface sans fil sur Oracle Solaris
12. Administration de groupements de liens
13. Administration des réseaux locaux virtuels
Liste des tâches d'administration d'IPMP
Création et configuration de groupe IPMP (liste des tâches)
Maintenance des groupes IPMP (liste des tâches)
Configuration de la détection de défaillance basée sur sonde (liste des tâches)
Contrôle des groupes IPMP (liste des tâches)
Procédure de planification pour un groupe IPMP
Procédure de configuration d'un groupe IPMP à l'aide du protocole DHCP
Procédure de configuration manuelle d'un groupe IPMP actif-actif
Procédure de configuration manuelle d'un groupe IPMP actif-de réserve
Procédure d'ajout d'une interface à un groupe IPMP
Procédure de suppression d'une interface d'un groupe IPMP
Procédure d'ajout ou de suppression d'adresses IP
Procédure de déplacement d'une interface d'un groupe IPMP vers un autre
Procédure de suppression d'un groupe IPMP
Configuration pour la détection de défaillance basée sur sonde
Procédure de sélection de méthode de détection de défaillance à utiliser
Restauration d'une configuration d'IPMP avec la reconfiguration dynamique
Procédure de remplacement d'une carte physique qui a échoué
Contrôle des informations d'IPMP
Procédures d'obtention d'informations sur le groupe IPMP
Procédures d'obtention d'informations sur les adresses de données IPMP
Procédure d'obtention d'informations sur les interfaces IP sous-jacentes d'un groupe
Procédures d'obtention d'informations sur les cibles de sonde IPMP
Procédure d'observation des sondes IPMP
Procédure de personnalisation de la sortie de la commande ipmpstat dans un script
Procédure de génération d'une sortie analysable par machine pour la commande ipmpstat
16. Echange d'informations sur la connectivité réseau à l'aide du protocole LLDP
Partie III Virtualisation du réseau et gestion des ressources
17. Introduction à la virtualisation du réseau et au contrôle des ressources (présentation)
18. Planification de la virtualisation du réseau et du contrôle des ressources
19. Configuration des réseaux virtuels (tâches)
20. Utilisation de la protection des liens dans les environnements virtualisés
21. Gestion des ressources réseau
22. Contrôle du trafic réseau et de l'utilisation des ressources
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. Pendant l'identification des cibles pour la détection de défaillance basée sur sonde, le démon in.mpathd fonctionne en deux modes : mode cible routeur ou mode cible multidiffusion. En mode cible routeur, le démon de multipathing test les cibles qui sont définies dans la table de routage. Si aucune cible n'est définie, le démon s'exécute en mode cible multidiffusion, où les paquets de multidiffusion sont envoyés tester les hôtes voisins sur le réseau local.
De préférence, vous devez définir les cibles d'hôte à tester par le démon in.mpathd. Pour certains groupes IPMP, le routeur par défaut est suffisant comme cible. 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. Pour spécifier les cibles, définissez des routes hôte dans la table de routage comme cibles de sonde. Les routes hôte configurées dans la table de routage figurent dans la liste avant le routeur par défaut. IPMP utilise les routes hôte définies explicitement pour la sélection de cibles. Par conséquent, vous devez définir des routes hôte afin de configurer des cibles de sondes plutôt que d'utiliser le routeur par défaut.
Pour définir des routes hôte dans la table de routage, utilisez la commande route. Vous pouvez utiliser l'option -p avec cette commande pour ajouter des routes permanentes. Par exemple, route -p add ajoute une route qui reste dans la table de routage même après la réinitialisation du système. L'option -p vous permet donc d'ajouter des routes persistantes sans avoir besoin de scripts spéciaux pour recréer ces routes à chaque démarrage du système. Pour mieux utiliser la détection de défaillance basée sur sonde, assurez-vous que vous avez défini plusieurs cibles pour recevoir les sondes.
L'exemple de procédure qui suit présente la syntaxe exacte pour ajouter des routes persistantes vers des cibles détection de défaillance basée sur sonde. Pour plus d'informations sur les options pour la commande route, reportez-vous à la page de manuel route(1M).
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. Etablissez 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.
$ route -p add -host destination-IP gateway-IP -static
où destination-IP et gateway-IP sont les adresses 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.10.137 qui se trouve sur le même sous-réseau que les interfaces du groupe IPMP itops0:
$ route -p add -host 192.168.10.137 192.168.10.137 -static
Cette nouvelle route est configurée automatiquement chaque fois que le système est redémarré. Si vous souhaitez définir une seule route temporaire à un système cible pour la détection de défaillance basée sur sonde, n'utilisez pas l'option -p.
Par défaut, la détection de défaillance basée sur sonde peut uniquement être exécutée en utilisant des adresses de test. Si le pilote de la carte réseau la prend en charge, la détection de défaillance basée sur les liaisons est également activée automatiquement.
Vous ne pouvez pas désactiver la détection de défaillance basée sur les liaisons si cette méthode est prise en charge par le pilote de la carte réseau. Cependant, vous pouvez sélectionner le type de la détection de défaillance basée sur sonde à implémenter.
# svccfg -s svc:/network/ipmp setprop config/transitive-probing=true # svcadm refresh svc:/network/ipmp:default
Pour plus d'informations sur la configuration de cette propriété, reportez-vous à la page de manuel in.mpathd(1M).
# svccfg -s svc:/network/ipmp setprop config/transitive-probing=false # svcadm refresh svc:/network/ipmp:default
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
Pour plus d'informations, reportez-vous à la section Procédure d’obtention des droits d’administration du manuel Administration d’Oracle Solaris : services de sécurité.
Modifiez la valeur par défaut d'au moins un des trois paramètres.
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.
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 réparation d'interface physique.
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.
Par exemple, le groupe IPMP ipmp0 se compose de deux interfaces, net0 et net1. Dans le fichier /etc/default/mpathd, le paramètre FAILBACK=no est défini. Si net0 échoue, elle est marquée comme étant FAILED et devient inutilisable. Après réparation, l'interface est marquée comme étant INACTIVE et reste inutilisables en raison du paramètre FAILBACK=no.
Si net1 échoue et qu'uniquement net0 est dans l'état INACTIVE, net0 voit son indicateur INACTIVE effacé et l'interface devient utilisable. Si le groupe IPMP dispose d'autres interfaces qui sont également dans l'état INACTIVE, alors n'importe laquelle de ces interfaces INACTIVE, et pas nécessairement net0, peut être effacée et devenir utilisable lorsque net1 échoue.
TRACK_INTERFACES_ONLY_WITH_GROUPS=[yes | no]
Remarque - Pour plus d'informations sur ce paramètre et la fonction de groupe anonyme, reportez-vous à la section Détection de défaillance et fonction de groupe anonyme .
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, aucune action n'est déclenchée dans IPMP pour maintenir les fonctions réseau de cette interface. 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.
# pkill -HUP in.mpathd