Administration du réseau public

Le logiciel Oracle Solaris Cluster prend en charge l'implémentation de la fonction IPMP (Internet Protocol network Multipathing, multipathing sur réseau IP) du logiciel Oracle Solaris sur les réseaux publics. L'administration de la fonction IPMP de base est la même pour les environnements de type cluster et non cluster. La fonctionnalité de chemins d'accès multiples est automatiquement installée avec le SE Oracle Solaris 11. Vous devez l'activer pour l'utiliser. Pour plus d'informations sur l'administration de la fonctionnalité de chemins d'accès multiples, reportez-vous à la documentation associée du SE Oracle Solaris. Toutefois, consultez les instructions suivantes avant d'administrer la fonction IPMP dans un environnement Oracle Solaris Cluster.

Administration des groupes de multipathing sur réseau IP dans un cluster

Avant d'appliquer les procédures IPMP à un cluster, veuillez prendre en considération les directives suivantes :

• Chaque adaptateur de réseau public doit appartenir à un groupe IPMP.

• La variable local-mac-address? doit renvoyer la valeur true pour les adaptateurs Ethernet.

• Vous pouvez utiliser des groupes IPMP basés sur une sonde ou un lien dans un cluster. Un groupe IPMP basé sur une sonde teste l'adresse IP cible et fournit la meilleure protection en reconnaissant plus de conditions qui risque de compromettre la disponibilité.

• Vous devez configurer une adresse IP de test pour chaque adaptateur dans les groupes de groupe de multipathing suivants :

  • Tous les groupes de multipathing à plusieurs adaptateurs nécessitent des adresses IP de test. Les groupes de multipathing à adaptateur unique ne requièrent pas d'adresses IP de test.

• Les adresses IP de test de tous les adaptateurs du même groupe de multipathing doivent appartenir à un sous-réseau IP unique.

• Les adresses IP de test ne doivent pas être utilisées par des applications normales car elles ne sont pas hautement disponibles.

• Il n'existe aucune restriction portant sur les noms des groupes de multipathing. Cependant, lorsque vous configurez un groupe de ressources, selon la convention de nommage netiflist, le nom de ce dernier est constitué d'un nom de groupe de multipathing quelconque, suivi du numéro d'ID et du nom du noeud. Prenons, par exemple, le groupe de multipathing sc_ipmp0. La convention de nommage netiflist peut être soit sc_ipmp0@1, soit sc_ipmp0@phys-schost-1, où l'adaptateur se trouve sur le noeud phys-schost-1, dont l'ID est égal à 1.

• N'annulez pas la configuration ou n'arrêtez pas l'adaptateur d'un groupe IPMP sans basculer au préalable les adresses IP de l'adaptateur à supprimer vers un autre adaptateur du groupe. Pour ce faire, utilisez la commande if_mpadm. Pour plus d'informations, reportez-vous à la page de manuel if_mpadm(1M).

• Evitez de rebrancher les adaptateurs sur d'autres sous-réseaux sans les supprimer auparavant de leurs groupes de multipathing respectifs.

• Vous pouvez effectuer des opérations logiques sur un adaptateur, même si ce dernier contrôle le groupe de multipathing.

• Vous devez conserver au moins une connexion au réseau public pour chaque noeud du cluster. Sans connexion au réseau public, vous n'avez pas accès au cluster.

• Pour afficher l'état des groupes de multipathing sur réseau IP d'un cluster, utilisez la commande clinterconnect status.

Pour plus d'informations sur le multipathing sur réseau IP, reportez-vous au manuel approprié de la documentation relative à l'administration du système d'exploitation Oracle Solaris.

Tableau 7-3 Liste des tâches : administration du réseau public

Pour les procédures d'installation logicielle du cluster, reportez-vous au manuel Guide d’installation du logiciel Oracle Solaris Cluster. Pour les procédures de maintenance des composants matériels du réseau public, reportez-vous au manuel Oracle Solaris Cluster Hardware Administration Manual.

Reconfiguration dynamique avec des interfaces de réseau public

Certains points sont à prendre en considération, lorsque vous effectuez des opérations de reconfiguration dynamique sur les interfaces de réseau public d'un cluster.

• Toutes les conditions requises, les procédures et les restrictions documentées pour la fonction de reconfiguration dynamique d'Oracle Solaris s'appliquent également au support de reconfiguration dynamique d'Oracle Solaris Cluster (à l'exception des opérations de quiescence du système d'exploitation). Par conséquent, reportez-vous à la documentation de la fonction de reconfiguration dynamique d'Oracle Solaris avant d'utiliser cette fonction avec Oracle Solaris Cluster. Vous devez vous concentrer tout particulièrement sur les problèmes affectant les périphériques d'E/S se trouvant en dehors du réseau, lors de la phase de séparation de la reconfiguration dynamique.

• Les opérations de suppression de carte ne peuvent aboutir que lorsque les interfaces de réseau public ne sont pas actives. Avant de supprimer une interface de réseau public active, basculez les adresses IP de l'adaptateur à supprimer vers un autre adaptateur du groupe de multipathing. Pour ce faire, utilisez la commande if_mpadm. Pour plus d'informations, reportez-vous à la page de manuel if_mpadm(1M).

• Si vous tentez de supprimer une carte d'interface réseau public sans l'avoir correctement désactivée, Oracle Solaris Cluster rejette l'opération et identifie l'interface pouvant être affectée par l'opération.

---

Attention - Pour les groupes de multipathing comptant deux adaptateurs, si l'adaptateur réseau restant se trouve en échec, lorsque vous effectuez des opérations de suppression de reconfiguration dynamique, la disponibilité des ressources peut en être affectée. Vous ne pouvez pas basculer l'adaptateur restant pendant l'opération de reconfiguration dynamique.

---

Terminez les procédures suivantes selon l'ordre indiqué, lorsque vous effectuez des opérations de reconfiguration dynamique sur des interfaces de réseau public.

Tableau 7-4 Liste des tâches : reconfiguration dynamique avec des interfaces de réseau public