Les problèmes et bogues présentés ci-après concernent la version Sun Cluster 3.1 9/04.
Récapitulatif du problème : scvxinstall crée des entrées vfstab incorrectes lorsque le périphérique de démarrage comporte plusieurs chemins.
Solution : Exécutez scvxinstall et choisissez le mode encapsulé. Lorsque le message suivant apparaît, saisissez Ctrl-C pour abandonner le redémarrage :
Ce nœud va être réinitialisé dans 20 secondes. Entrez Ctrl-C pour annuler. |
Modifiez l'entrée vfstab de sorte que /global/.devices utilise le nom /dev/{r}dsk/cXtXdX au lieu du nom /dev/did/{r}dsk. Cette entrée modifiée permet à VxVM de le reconnaître en tant que disque root. Exécutez à nouveau scvxinstall et choisissez le mode encapsulé. Le fichier vfstab comporte les modifications nécessaires. Autorisez le redémarrage. L'encaspulation est normalement effectuée.
Récapitulatif du problème : Le service de données Sun Cluster HA for Oracle démarre et arrête la base de données à l'aide de la commande su. 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 nœud susceptible d'être principal pour la ressource oracle_server ou oracle_server, modifiez le fichier /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.
Récapitulatif du problème : Les clusters qui utilisent des adaptateurs ce sur l'interconnexion privée rencontrent des problèmes de temporisation de chemin suivis d'erreurs graves de nœud si un ou plusieurs nœuds ont plus de 4 CPU.
Solution : Définissez le paramètre ce_taskq_disable dans le pilote ce en ajoutant la ligne suivante au fichier /etc/system sur tous les nœuds de cluster.
set ce:ce_taskq_disable=1
Redémarrez ensuite les nœuds de cluster. Tenez compte du quorum lorsque vous redémarrez les nœuds de cluster. La définition de ce paramètre permet de toujours envoyer les pulsations (et d'autres paquets) dans le contexte de l'interruption, éliminant ainsi les problèmes de temporisation de chemins et les erreurs graves de nœuds consécutives.
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 nœud susceptible d'être principal pour les ressources 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 manuel Sun Cluster Data Service for SAP liveCache Guide for Solaris OS assure 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.
Récapitulatif du problème : en raison d'une erreur interne, certains 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. Ce problème se produit lorsque le code de l'agent est écrit sous forme de script shell.
Solution :
La solution suivante s'adresse aux développeurs d'agents qui écrivent des scripts shell :
Dans les scripts shell, envoyez explicitement la fonction vers scds_sylog :
facility=`scha_cluster_get -O SYSLOG_FACILITY
'scds_syslog -p ${facility}.error -m "error message"
La solution suivante est destinée aux administrateurs de clusters :
Ajoutez la ligne suivante au début du fichier /etc/syslog.conf sur tous les nœuds de cluster :
user.warning /var/adm/messages
Cette ligne entraîne l'enregistrement 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 exécutées.
Récapitulatif du problème : Les exigences requises pour le fichier nsswitch.conf dans la section "Preparing the Nodes and Disks" (Préparation des nœuds et des disques) du manuel Sun Cluster Data Service for SAP liveCache Guide for Solaris OS ne s'appliquent pas à l'entrée pour 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]
Récapitulatif du problème : sccheck peut être interrompue si elle est lancée simultanément sur plusieurs nœuds.
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.
Récapitulatif du problème : Actuellement, le service de données HA-DB n'utilise pas la variable d'environnement JAVA_HOME. Par conséquent, HA-DB, lorsqu'il est appelé à partir du service de données HA-DB, utilise des fichiers binaires Java à partir de /usr/bin/. Les fichiers binaires Java situés dans /usr/bin/ doivent être liés à la version appropriée de Java 1.4 et versions ultérieures, pour permettre au service de données HA-DB de fonctionner correctement.
Solution : Si vous souhaitez modifier la version disponible par défaut, effectuez la procédure ci-après. Cette solution suppose que le répertoire /usr/j2se correspond à celui dans lequel se trouve la dernière version de Java (par exemple la version 1.4 ou ultérieure).
Disposez-vous actuellement d'un répertoire appelé java/ dans le répertoire /usr/ ? Si tel est le cas, déplacez-le vers un emplacement temporaire.
À partir du répertoire /usr/, liez /usr/bin/java et tous les autres fichiers binaires Java à la version appropriée de Java.
# ln -s j2se java |
Si vous ne souhaitez pas modifier la version par défaut disponible, attribuez la variable d'environnement JAVA_HOME à la version appropriée de Java (J2SE 1.4 ou ultérieure) dans le script /opt/SUNWappserver7/SUNWhadb/4/bin/hadbm.
Récapitulatif du problème : En raison du bogue 4974875, lorsqu'une récupération automatique est effectuée, la base de données est réinitialisée sans disques spare. Le bogue mentionné a été résolu et intégré dans HA-DB version 4.3. Pour HA-DB 4.2 et les versions antérieures, effectuez l'une des procédures suivantes pour modifier les rôles des nœuds HA-DB.
Solution :
Identifiez les nœuds HA-DB dont le rôle a été modifié après une récupération automatique correctement effectuée.
Sur tous les nœuds identifiés à l'étape 1, désactivez nœud par nœud le moniteur par défaut pour la ressource HA-DB concernée.
# cladm noderole -db dbname -node nodeno -setrole role-before-auto_recovery |
Activez le moniteur par défaut pour la ressource HA-DB concernée.
ou
Identifiez les nœuds HA-DB dont le rôle a été modifié après une récupération automatique correctement effectuée.
Sur tous les nœuds qui hébergent la base de données, désactivez le moniteur par défaut pour la ressource HA-DB concernée.
Sur tous les nœuds, exécutez la commande pour chaque nœud HA-DB dont le rôle doit être modifié.
# cladm noderole -db dbname -node nodeno -setrole role-before-auto_recovery |
Récapitulatif du problème : Lors d'une mise à niveau progressive, si la commande scstat -i est exécutée sur un nœud de cluster qui n'a pas encore été mis à niveau, la sortie de commande scstat ne fait pas apparaître l'état des groupes IPMP hébergés sur les nœuds déjà mis à niveau.
Solution : Utilisez la sortie de commande scstat -i à partir des nœuds mis à jour.
Récapitulatif du problème : Il est impossible d'ajouter une ressource LogicalHostname au cluster si elle doit utiliser un group IPMP avec un adaptateur défectueux.
Solution : Supprimez l'adaptateur défectueux du groupe IPMP ou corrigez la défaillance avant d'utiliser le groupe IPMP dans une ressource LogicalHostname.
Récapitulatif du problème : les deux champs, Status et Type, de la page d'état des groupes de ressources affiche des valeurs dans la première locale utilisée pour afficher cette page.
Solution : Pour afficher des valeurs dans une locale différente, redémarrez le serveur Web.
Récapitulatif du problème : Après l'encapsulation du disque root, si vous désencapsulez puis réencapsulez le disque root, vous observerez peut-être qu'un volume nommé uservol est utilisé pour le système de fichiers /global/devices/node@nodeID. Cela peut générer des problèmes, étant donné que le nom du volume de chaque système de fichiers global de chaque nœud doit être unique.
Solution : Après avoir suivi les étapes documentées pour l'annulation de l'encapsulation, arrêtez le démon vxconfigd avant d'exécuter à nouveau scvxinstall afin de réencapsuler le disque root.
Récapitulatif du problème : Lors de la connexion à Sun Web Console, si vous cliquez sur le bouton Connexion ou appuyez sur la touche Entrée de façon répétée, les multiples demandes de connexion peuvent entraîner diverses erreurs, empêchant ainsi l'accès au Gestionnaire SunPlex.
Solution : Attribuez-vous le rôle de superutilisateur sur le nœud de cluster et redémarrez Sun Web Console.
# /usr/sbin/smcwebserver restart |
Récapitulatif du problème : La propriété de ressource Resource_dependencies_restart ne se comporte pas comme prévu lorsqu'une ressource déclare une dépendance de redémarrage groupe-ressource any node sur une ressource évolutive. La plupart des services de données ne sont pas affectés.
Informations sur les dépendances groupe-ressource et celles de redémarrage :
Avec la fonction de dépendance groupe-ressource de Sun Cluster 3.1 9/04, Sun Cluster prend en charge des dépendances de ressources qi peuvent dépasser les limites des groupes de ressources. Sun Cluster prend également en charge un nouveau type de dépendance de ressource, à savoir la dépendance de redémarrage. Si la ressource dépendante est en ligne, la dépendance de redémarrage entraîne le redémarrage automatique de cette ressource lors du démarrage de la ressource dont elle dépend.
Informations sur les dépendances local node et any node :
Si la ressource r1 du groupe RG1 possède une dépendance à r2 dans RG2, que RG1 présente une affinité positive pour RG2, et que RG1 et RG2 démarrent ou s'arrêtent simultanément sur le même nœud, la dépendance de r1 à r2 est une dépendance local node. Par exemple, en cas de démarrage de RG1 et RG2 sur le même nœud, r1 patiente jusqu'au démarrage de r2 sur ce nœud avant de démarrer sur ce même nœud. L'état de r2 sur d'autres nœuds n'a aucun impact lors du démarrage de r1.
Toutefois, si RG1 ne déclare pas une affinité positive pour RG2, ou s'il existe une affinité positivité faible, mais que les groupes de ressources démarrent sur des nœuds différents, la dépendance de r1 à r2 est une dépendance any node. Cette dépendance signifie que r1 démarre dès que r2 a démarré sur un nœud, quel qu'il soit.
Description du problème :
Ce problème existe lorsqu'un groupe de ressources RG2 est un groupe de ressources en mode évolutif (c'est-à-dire multimaître) et la dépendance de r1 à r2 est une dépendance de redémarrage any node. r1 est redémarré à chaque démarrage d'une instance de r2. r1 doit être redémarré uniquement sur la première instance de r2 qui démarre.
Solution : Le comportement actuel des dépendances de redémarrage va changer conformément aux descriptions ci-dessus lorsque ce bogue aura été corrigé. Ne développez aucun code ni aucune procédure administrative qui dépende du comportement actuel incorrect.
Récapitulatif du problème : Si vous disposez d'un serveur Sun Enterprise 15000 et que vous exécutez la commande sccheck, la vérification échoue et renvoie une erreur qui indique que le serveur Sun Enterprise 15000 n'est pas pris en charge. Cette instruction est incorrecte.
Solution : Aucune solution n'est nécessaire. Sun Cluster prend en charge le serveur Sun Enterprise 15000. L'erreur renvoyée par l'exécution de la commande sccheck indique que la vérification est peut-être obsolète. Dans ce cas, sccheck est obsolète.
Récapitulatif du problème : Le français (fr) n'est pas disponible lors de la sélection de la langue pour les agents du service de données qui ne font pas partie de Sun Java Enterprise System. Cependant, le programme d'installation de l'interface graphique de ces packages indique le contraire.
Solution : Ne tenez pas compte de cette erreur du programme d'installation de l'interface graphique. Le français (fr) n'est pas disponible.
Récapitulatif du problème : Lors de la mise à niveau vers le logiciel Sun Cluster 3.1 9/04, la commande scinstall installe les nouveaux packages conteneur d'agents communs, SUNWcacao et SUNWcacaocfg, mais ne distribue pas des clés de sécurité identiques à tous les nœuds de cluster.
Solution : Effectuez les étapes suivantes pour vous assurer que les fichiers de sécurité du conteneur d'agents communs sont identiques sur tous les nœuds de cluster et que les fichiers copiés conservent les autorisations de fichier adéquates. Ces fichiers sont requis par Sun Cluster.
Sur un nœud de cluster, accédez au répertoire /etc/opt/SUNWcacao/.
phys-schost-1# cd /etc/opt/SUNWcacao/ |
Créez un fichier tar du répertoire /etc/opt/SUNWcacao/security/.
phys-schost-1# tar cf /tmp/SECURITY.tar security |
Copiez le fichier /tmp/SECURITY.tar vers chacun des autres nœuds de cluster.
Sur chaque nœud vers lequel le fichier /tmp/SECURITY.tar a été copié, procédez à l'extraction des fichiers de sécurité.
Tous les fichiers de sécurité qui existent déjà dans le répertoire /etc/opt/SUNWcacao/ sont remplacés.
phys-schost-2# cd /etc/opt/SUNWcacao/ phys-schost-2# tar xf /tmp/SECURITY.tar |
Supprimez le fichier /tmp/SECURITY.tar dans chaque nœud du cluster.
Vous devez supprimer chaque copie du fichier tar pour éviter tout problème de sécurité.
phys-schost-1# rm /tmp/SECURITY.tar phys-schost-2# rm /tmp/SECURITY.tar |
Sur chaque nœud, redémarrez l'agent du fichier de sécurité.
# /opt/SUNWcacao/bin/cacaoadm start |
Récapitulatif du problème : Le champ de la date du panneau de filtrage avancé de Gestionnaire SunPlex accepte uniquement le format mm/jj/aaaa. Toutefois, dans les environnements linguistiques non anglais, le format de date est différent de mm/dd/yyyy et le format de date renvoyé par le panneau Calendrier est différent de mm/dd/yyyy.
Solution : Saisissez la plage de dates dans le panneau de filtrage avancé en utilisant le format mm/jj/aaaa. N'utilisez pas le bouton Définir pour afficher le calendrier et choisir la date.
Récapitulatif du problème : Lorsque vous supprimez un groupe de ressources en utilisant Gestionnaire SunPlex avec Solaris 8, il se peut que vous ne puissiez pas lire les messages d'erreur reçus. Ce problème se produit pour le japonais, le coréen, le chinois traditionnel et le chinois simplifié.
Solution : Exécutez la locale du système en anglais pour afficher les messages d'erreur en anglais.
Récapitulatif du problème : Dans le fichier d'enregistrement du type de ressource SUNW.sapscs, les descriptions de deux propriétés d'extension sont incorrectes.
Solution : La description de Scs_Startup_Script doit être Startup script for the SCS. Defaults to /usr/sap/SAP_SID/SYS/exe/run/startsap. La description de Scs_Shutdown_Script doit être Shutdown script for the SCS. Defaults to /usr/sap/SAP_SID/SYS/exe/run/stopsap.
Récapitulatif du problème : Après avoir installé Sun Cluster à l'aide de la méthode JumpStart, Sun Web Console impossible de lancer Gestionnaire SunPlex. Le traitement après installation de JumpStart ne parvient pas à enregistrer correctement Gestionnaire SunPlex avec Sun Web Console.
Solution : Exécutez le script suivant sur chaque nœud de cluster une fois l'installation JumpStart de Sun Cluster terminée sur tous les nœuds.
# /var/sadm/pkg/SUNWscspmu/install/postinstall |
Ce script permet d'enregistrer Gestionnaire SunPlex avec Sun Web Console.
Récapitulatif du problème : Le programme d'installation résidant sur le CD-ROM des services de données Sun Cluster 3.1 9/04 pour x86 ne peut être utilisé pour installer HA Oracle. Le message suivant est émis par le programme d'installation :
Impossible de trouver l'archive fille ....
Solution : Utilisez scinstall pour installer Sun Cluster Data Service pour HA Oracle.
Récapitulatif du problème : Les services de données des applications suivantes ne peuvent pas être mis à niveau par le biais de l'utilitaire scinstall :
Apache Tomcat ;
DHCP ;
mySQL ;
Oracle E-Business Suite ;
Samba ;
SWIFTAlliance Access ;
Serveur WebLogic Server
WebSphere MQ ;
WebSphere MQ Integrator.
Solution : Si vous prévoyez de mettre à niveau un service de données d'une des applications répertoriées dans la liste précédente, remplacez l'étape de mise à niveau des services de données décrite dans la rubrique Mise à niveau vers Sun Cluster 3.1 9/04 (progressive) du Guide d’installation du logiciel Sun Cluster pour SE Solaris par la procédure ci-après. 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 suivante : http://docs.sun.com/.