test

Notes de version de Sun Cluster 3.1 9/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 9/04.

scvxinstall crée des entrées vfstab incorrectes lorsque le périphérique de démarrage comporte plusieurs chemins (4639243)

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.

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 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.

Temporisation des adaptateurs ce sur l'interconnexion privée et graves erreurs de nœuds (4746175)

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.

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 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.

Certains agents n'utilisent pas la fonction LOG_DAEMON (4897239)

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 :

Les exigences du fichier nsswitch.conf ne devraient pas être appliquées à la base de données passwd (4904975)

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]

Interruptions de sccheck (4944192)

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.

L'association de fichiers binaires Java à une version Java incorrecte entraîne un dysfonctionnement de l'agent HA-DB (4968899)

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).

  1. 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.

  2. À 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.

La réinitialisation de HA-DB est effectuée sans disques spare (4973982)

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 :

  1. Identifiez les nœuds HA-DB dont le rôle a été modifié après une récupération automatique correctement effectuée.

  2. 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

  3. Activez le moniteur par défaut pour la ressource HA-DB concernée.

    ou

  1. Identifiez les nœuds HA-DB dont le rôle a été modifié après une récupération automatique correctement effectuée.

  2. 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.

  3. 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

Aucun autre nœud ne peut accéder à pnmd lors de la mise à niveau progressive (4997693)

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.

Impossible d'ajouter la ressource LogicalHostname (5004611)

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.

SunPlex Manager stocke des informations de codage sur l'état de façon inappropriée (5012328)

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.

uservol est utilisée pour /global/.devices/node@2 après la réencapsulation du disque root (5028284)

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.

Les envois multiples de pages de connexion à Sun Web Console génèrent plusieurs échecs de connexion (5039143)

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

Resource_dependencies_restart ne fonctionne pas correctement (5041013)

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.

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.

Absence de prise en charge de sccheck pour Sun Enterprise 15000 (5056534)

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.

Français non disponible pour les agents du service de données non-JES (5059963)

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.

scinstall –u update ne conserve pas les clés de sécurité SUNWcacao (5068616)

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.

  1. Sur un nœud de cluster, accédez au répertoire /etc/opt/SUNWcacao/. 


    phys-schost-1# cd /etc/opt/SUNWcacao/

  2. Créez un fichier tar du répertoire /etc/opt/SUNWcacao/security/. 


    phys-schost-1# tar cf /tmp/SECURITY.tar security

  3. Copiez le fichier /tmp/SECURITY.tar vers chacun des autres nœuds de cluster.

  4. 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

  5. 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

  6. Sur chaque nœud, redémarrez l'agent du fichier de sécurité. 


    # /opt/SUNWcacao/bin/cacaoadm start

Format de date incorrect pour le panneau de filtrage avancé de Gestionnaire SunPlex (5075018)

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.

Impossible de lire les messages d'erreur dans Gestionnaire SunPlex lors de la suppression d'un groupe de ressources (5083147)

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.

Descriptions de propriétés d'extension incorrectes dans SUNW.sapscs (5083259)

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.

Une fois la méthode JumpStart terminée pour Sun Cluster 3.1 9/04, impossible d'accéder à Gestionnaire SunPlex (5095638)

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.

L'installation de Sun Cluster Data Service pour HA Oracle à partir du CD-ROM échoue (5098622)

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.

Certains services de données ne peuvent pas être mis à niveau par le biais de l'utilitaire scinstall.

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 :

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é.

ProcedureMise à niveau des services de données pour lesquels l'utilitaire scinstall n'est pas utilisable.

Étapes

  1. 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

  2. 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/.