Notes de version de Sun Cluster 3.1 4/04 pour SE Solaris

Problèmes connus et bogues

Les problèmes et bogues présentés ci-après concernent la version Sun Cluster 3.1.

Services de données : directives pour l'installation

Identifiez la configuration minimale requise pour l'ensemble des services de données avant d'installer Solaris et Sun Cluster. Sinon vous risquez de faire des erreurs d'installation et vous devrez réinstaller complètement les logiciels Solaris et Sun Cluster.

Par exemple, l'option Oracle Parallel Fail Safe/Real Application Clusters Guard des clusters Oracle Parallel Server/Real Application impose certaines contraintes pour les noms d'hôtes et de noeuds utilisés dans le cluster. Vous devez prendre connaissance de ces contraintes avant de procéder à l'installation du logiciel Sun Cluster, les noms d'hôtes ne pouvant être modifiés après l'installation. Pour de plus amples informations sur les exigences relatives aux noms d'hôtes et aux noms de noeuds, consultez la documentation Oracle Parallel Fail Safe/Real Application Clusters Guard.

Noeuds incapables d'activer les chemins qfe (4526883)

Récapitulatif du problème : les chemins de transport d'interconnexion privée finissant par un adaptateur qfe ne parviennent pas toujours à se mettre en ligne.

Solution : suivez les étapes indiquées ci-dessous.

Identifiez l'adaptateur défectueux à l'aide de scstat -W. Le résultat affichera tous les chemins de transport avec cet adaptateur comme l'une des extrémités du chemin à l'état faulted ou waiting.
Utilisez la commande scsetup pour supprimer de la configuration de cluster tous les câbles connectés à cet adaptateur.
Utilisez à nouveau la commande scsetup pour supprimer cet adaptateur de la configuration de cluster.
Replacez l'adaptateur et les câbles.
Vérifiez que les chemins apparaissent. Si le problème persiste, répétez plusieurs fois les étapes 1 à 5.
Vérifiez que les chemins apparaissent. Si le problème persiste toujours, réinitialisez le noeud où se trouve l'adaptateur défectueux. Avant de réinitialiser le noeud, assurez-vous que le reste du cluster a suffisamment de votes de quorum pour résister à la réinitialisation du noeud.

Échec du script `remove` pour désenregistrer le type de ressources `SUNW.gds` (4727699)

Récapitulatif du problème : le script remove ne parvient pas à désenregistrer le type de ressources SUNW.gds et affiche le message indiqué ci-dessous :

Le type de ressources a déjà été désenregistré.

Solution : après avoir utilisé le script remove, désenregistrez manuellement SUNW.gds. Vous pouvez aussi utiliser la commande scsetup ou SunPlex Manager.

Temporisation de chemin lors de l'utilisation d'adaptateurs `ce` sur l'interconnexion privée (4746175)

Récapitulatif du problème : les clusters utilisant des adaptateurs ce sur l'interconnexion privée peuvent rencontrer des problèmes de temporisation de chemin suivis d'erreurs graves de noeud, si un ou plusieurs noeuds ont plus de quatre processeurs.

Solution : définissez le paramètre ce_taskq_disable dans le gestionnaire ce en ajoutant set ce:ce_taskq_disable=1 au fichier /etc/system sur tous les noeuds de cluster, puis réinitialisez-les. Cela permet de toujours envoyer les pulsations (et autres paquets) dans le contexte de l'interruption, et d'éliminer les problèmes de temporisation de chemins suivis d'erreurs graves. Prenez en considération les indications du quorum lors de la réinitialisation des noeuds.

Interruption des noeuds après initialisation alors qu'une commutation est en cours (4806621)

Récapitulatif du problème : si la commutation d'un groupe de périphériques est en cours au moment où un noeud rejoint le cluster, la jonction du noeud et l'opération de commutation risquent de s'interrompre. Toute tentative d'accès à un service du périphérique s'interrompra également. Ce problème est plus susceptible de se produire si le cluster comporte plus de deux noeuds, et si le système de fichiers monté sur le périphérique est un système de fichiers VxFS.

Solution : pour éviter cette situation, ne lancez pas de basculement de groupes de périphériques au moment où un noeud rejoint le cluster. Si vous rencontrez ce problème, réinitialisez tous les noeuds de cluster pour restaurer l'accès aux groupes de périphériques.

Échec de l'assistant DNS si une configuration DNS existante n'est pas fournie (4839993)

Récapitulatif du problème : SunPlex Manager intègre un assistant d'installation des services de données permettant de définir un service DNS hautement disponible sur le cluster. Si l'utilisateur ne fournit pas une configuration DNS existante, telle qu'un fichier named.conf, l'assistant tente de générer une configuration DNS valide en détectant automatiquement la configuration réseau et le service de noms existants. Toutefois, cette opération échoue dans certains environnements réseau, provoquant ainsi une panne de l'assistant sans qu'il génère de message d'erreur.

Solution : à l'invite, donnez à l'assistant d'installation de services de données DNS de SunPlex Manager un nom de fichier named.conf existant et correct. Vous pouvez aussi suivre les procédures des services de données DNS pour configurer manuellement un service DNS à haute disponibilité sur le cluster.

Utilisation de SunPlex Manager pour l'installation d'un service Oracle (4843605)

Récapitulatif du problème : SunPlex Manager intègre un assistant d'installation des services de données permettant de définir un service Oracle à haute disponibilité sur le cluster en installant et configurant les binaires Oracle, et en créant la configuration en cluster. Toutefois, cet assistant d'installation n'est actuellement pas opérationnel et entraîne un série d'erreurs, variables en fonction de la configuration logicielle de l'utilisateur.

Solution : installez et configurez manuellement le service de données Oracle sur le cluster, en suivant les procédures décrites dans la documentation Sun Cluster.

Impossibilité d'ajouter un adaptateur au groupe IPMP après suppression (4884060)

Récapitulatif du problème : si SunPlex Manager est utilisé pour supprimer un adaptateur d'un groupe IPMP de plusieurs adaptateurs, il peut être impossible d'ajouter immédiatement l'adaptateur au même groupe.

Solution : supprimez /etc/hostname.adapter avant de tenter d'ajouter l'adaptateur au même groupe IPMP.

Non-utilisation de `LOG_DAEMON` par la version Shell de `scds_syslog` (4897239)

Récapitulatif du problème : en raison d'une erreur interne, la plupart des agents de cluster fournis par Sun consignent des messages dans le journal système (reportez-vous à la rubrique syslog(3C)) à l'aide de la fonction LOG_USER au lieu d'utiliser LOG_DAEMON. Sur un cluster configuré avec les paramètres syslog par défaut (reportez-vous à la rubrique syslog.conf(4)), les messages de gravité LOG_WARNING ou LOG_NOTICE, normalement consignés dans le journal système, ne sont pas émis.

Solution : ajoutez la ligne suivante au début du fichier /etc/syslog.conf sur tous les noeuds de cluster :

user.warning			/var/adm/messages

Ceci entraînera la consignation des messages user.warning. Une ligne similaire peut être ajoutée pour les messages user.notice, mais ceci n'est pas nécessaire et peut entraîner un remplissage trop rapide des journaux, suivant la combinaison d'applications éxécutées.

Exigences de `nsswitch.conf` pour que `passwd` rende `nis` inutilisable (4904975)

Récapitulatif du problème : les exigences du fichier nssswitch.conf indiquées à la rubrique “Preparing the Nodes and Disks” in Sun Cluster Data Service for SAP liveCache Guide for Solaris OS ne s'appliquent pas à l'entrée de la base de données passwd. Si ces exigences sont satisfaites, la commande su peut suspendre chaque noeud pouvant contrôler la ressource liveCache lorsque le réseau public est arrété.

Solution : sur chaque noeud pouvant contrôler la ressource liveCache, veillez à ce que l'entrée dans le fichier /etc/nsswitch.conf pour la base de données passwd soit la suivante :

passwd: files nis [TRYAGAIN=0]

Non prise en charge de Solaris 9 et des versions ultérieures par les assistants d'installation de services de données pour Oracle et Apache (4906470)

Récapitulatif du problème : les assistants d'installation de services de données SunPlex Manager pour Apache et Oracle ne prennent pas en charge Solaris 9 et les versions ultérieures.

Solution : installez Oracle manuellement sur le cluster en vous référant à la documentation de Sun Cluster. Si vous installez Apache sur Solaris 9 (ou versions ultérieures), ajoutez manuellement les packages Apache Solaris SUNWapchr et SUNWapchu avant de lancer l'assistant.

Grave erreur de noeud suite à la réinitialisation d'un noeud dans le cadre de l'encapsulation `scvxinstall` (4931910)

Récapitulatif du problème : des erreurs de délais de réinitialisation de noeud de cluster lors de l'encapsulation de disques racines peuvent engendrer de graves erreurs de noeuds.

Solution : exécutez scvxinstall sur un noeud à la fois, en attendant que le noeud ait complètement terminé sa réinitialisation avant de lancer scvxinstall sur un autre noeud.

Fenêtre par défaut du générateur d'agents SunPlex trop petite pour les versions autres que la version anglaise (4937877)

Récapitulatif du problème : lorsque vous exécutez le générateur d'agents SunPlex dans une version autre que la version anglaise, la taille par défaut de la fenêtre est trop petite et certaines commandes peuvent ne pas apparaître dans cette fenêtre. Ce problème a été constaté dans les environnements linguistiques allemand et espagnol.

Solution : redimensionnez manuellement la fenêtre du générateur d'agents SunPlex.

Interruption de la commande `sccheck` lorsqu'elle est exécutée sur plusieurs noeuds à la fois (4944192)

Récapitulatif du problème : sccheck peut être interrompue si elle est lancée simultanément sur plusieurs noeuds.

Solution : ne lancez pas sccheck à partir d'une console multiple qui envoie des commandes à plusieurs noeuds. Les exécutions de sccheck peuvent se chevaucher mais ne doivent pas être lancées simultanément.

Non-suppression par `scinstall -r` des packages de services de données d'une version localisée (4955294)

Récapitulatif du problème : scinstall -r ne supprime pas les packages de services de données spécifiques à une version localisée.

Solution : lorsque le noeud apparaît, exécutez pkginfo | grep -i cluster pour garantir la suppression de tous les packages de services de données. Pour supprimer les packages listés, exécutez pkgrm sur chaque package.

Langue incorrecte affichée dans la version en chinois traditionnel (4955538)

Récapitulatif du problème : certains messages du générateur d'agents SunPlex de la version en chinois traditionnel s'affichent en chinois simplifié.

Solution : exécutez le générateur d'agents SunPlex dans la version zh_TW pour afficher correctement les messages en chinois traditionnel.

Dysfonctionnement de l'agent HADB suite à une liaison des binaires Java à une version Java incorrecte (4968899)

Récapitulatif du problème : lorsque la commande hadbm est appelée à partir de l'agent HADB, les binaires Java sont pris dans /usr/bin. L'agent HADB ne fonctionne pas correctement car les binaires Java dans /usr/bin doivent être reliés à la version correcte de Java 1.4 (ou ultérieure).

Solution : associez la variable d'environnement JAVA_HOME à la version appropriée de Java 1.4 (ou ultérieure) dans le script /opt/SUNWappserver7/SUNWhadb/4/bin/hadbm.

Impossibilité pour `scsetup` d'ajouter le premier adaptateur à un cluster à noeud unique (4983095)

Récapitulatif du problème : si scsetup est utilisé pour essayer d'ajouter le premier adaptateur à un cluster à noeud unique, le message d'erreur suivant s'affiche : Unable to determine transport type.

Solution : configurez au moins le premier adaptateur manuellement :

# scconf -a -A trtype=type,name=nom_noeud,node=nom_noeud

Après avoir configuré le premier adaptateur, continuez à utiliser scsetup pour configurer les travaux d'interconnexion comme prévu.

Impossibilité de mettre à niveau certains services de données à l'aide de l'utilitaire `scinstall`

Récapitulatif du problème : les services de données des applications suivantes ne peuvent pas être mis à niveau avec l'utilitaire scinstall :

Apache Tomcat ;
DHCP ;
mySQL ;
Oracle E-Business Suite ;
Samba ;
SWIFTAlliance Access ;
Serveur WebLogic ;
WebSphere MQ ;
WebSphere MQ Integrator.

Solution : si vous prévoyez de mettre à niveau votre service de données pour une application figurant dans la liste précédente, remplacez l'étape de mise à niveau de services de données de la rubrique “Mise à niveau pour le logiciel Sun Cluster 3.1 4/04 (progressive)” du Guide d'installation du logiciel Sun Cluster pour SE Solaris en suivant les étapes ci-dessous. Répétez ces étapes pour chaque noeud où le service de données est installé.

Supprimez le package de logiciels du service de données que vous mettez à niveau.

# pkgrm package_installation

package_installation spécifie le nom du package correspondant au service de données que vous mettez à niveau, tel qu'indiqué dans le tableau suivant.

Application	Package du service de données
Apache Tomcat	`SUNWsctomcat`
DHCP	`SUNWscdhc`
mySQL	`SUNWscmys`
Oracle E-Business Suite	`SUNWscebs`
Samba	`SUNWscsmb`
SWIFTAlliance Access	`SUNWscsaa`
Serveur WebLogic (version anglaise)	`SUNWscwls`
Serveur WebLogic (version française)	`SUNWfscwls`
Serveur WebLogic (version japonaise)	`SUNWjscwls`
WebSphere MQ	`SUNWscmqs`
WebSphere MQ Integrator	`SUNWscmqi`

Installez le package correspondant à la version de service de données vers laquelle vous mettez à niveau.

Pour installer le package, suivez les instructions figurant dans la documentation de Sun Cluster correspondant au service de données que vous mettez à niveau. Cette documentation est disponible à l'adresse http://docs.sun.com.

Temps d'inactivité de la méthode d'arrêt HA Oracle (4644289)

Récapitulatif du problème : le service de données Sun Cluster HA pour Oracle démarre et arrête la base de données à l'aide de la commande superutilisateur su(1M). Si vous exécutez Solaris 8 ou Solaris 9, le service réseau peut devenir indisponible lorsque le réseau public d'un noeud du cluster tombe en panne.

Solution : sur chaque noeud susceptible d'être principal pour la ressource oracle_server ou oracle_server, modifiez le fichier de configuration /etc/nsswitch.conf en y incluant les entrées suivantes :

passwd: files
groups: files
publickey: files
project:  files

L'ajout de ces entrées garantit que la commande su ne se réfère pas aux services de noms NIS/NIS+, de sorte que le service de données démarre et s'arrête correctement en cas de panne du réseau.

Temps d'inactivité de la méthode d'arrêt SAP liveCache (4836272)

Récapitulatif du problème : le service de données Sun Cluster HA pour SAP liveCache utilise la commande dbmcli pour démarrer et arrêter le liveCache. Si vous exécutez Solaris 9, le service du réseau peut devenir indisponible lorsque le réseau public d'un noeud de cluster tombe en panne.

Solution : sur chaque noeud susceptible d'être principal pour la ressource liveCache, modifiez le fichier de configuration /etc/nsswitch.conf en y incluant l'une des entrées suivantes pour la base de données publickey :

publickey: 
publickey:  files
publickey:  files [NOTFOUND=return] nis 
publickey:  files [NOTFOUND=return] nisplus

L'ajout de l'une de ces entrées et des mises à jour indiquées dans le Sun Cluster Data Service for SAP liveCache Guide for Solaris OSassure que les commandes su et dbmcli ne se réfèrent pas aux services de noms NIS/NIS+. En évitant les services de noms NIS/NIS+, le service de données démarre et s'arrête correctement en cas de panne du réseau.

Échec du redémarrage des composants Siebel par HA-Siebel (4722288)

Récapitulatif du problème : Sun Cluster HA pour Siebel ne contrôle pas les composants Siebel individuels. En cas d'échec d'un composant Siebel, seul un message d'avertissement est consigné dans syslog.

Solution : redémarrez le groupe de ressources du serveur Siebel dans lequel les composants sont hors ligne au moyen de la commande scswitch -R -h noeud -g groupe_ressources.