Problèmes connus et bogues

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

scvxinstall génère des entrées vfstab incorrectes en cas de multiacheminement du périphérique d'initialisation (4639243)

Problème : scvxinstall génère des entrées /etc/vfstab incorrectes en cas de multiacheminement du périphérique d'initialisation.

Solution : exécutez scvxinstall et choisissez le mode encapsulé. Pour abandonner la réinitialisation à l'affichage du message suivant, saisissez Ctrl+C :

Ce nœud va être réinitialisé dans 20 secondes. Entrez Ctrl-C pour annuler.

Modifiez l'entrée vfstab afin que le nom du fichier /global/.devices soit /dev/{r}dsk/cXtXdX plutôt que /dev/did/{r}dsk. Cette entrée révisée permet à VxVM de la reconnaître en tant que disque racine. Exécutez à nouveau scvxinstall et choisissez le mode encapsulé. Le fichier vfstab comporte les mises à jour nécessaires. Autorisez le redémarrage. L'encaspulation est normalement effectuée.

Correction des erreurs /etc/vfstab en cas de multiacheminement du périphérique d'initialisation

Étapes

1. Exécutez scvxinstall et choisissez le mode encapsulé.

   Le système affiche le message suivant :

   This node will be re-booted in 20 seconds. Type Ctrl-C to abort.

2. Abandonnez la réinitialisation.

   Ctrl-C

3. Modifiez l'entrée /etc/vfstab pour que /global/.devices utilise le nom /dev/{r}dsk/cXtXdX et non /dev/did/{r}dsk.

   Cette entrée révisée permet à VxVM de la reconnaître en tant que disque racine.

4. Réexécutez scvxinstall et choisissez le mode encapsulé.

   Le fichier /etc/vfstab comporte les mises à jour nécessaires. Autorisez le redémarrage. L'encaspulation est normalement effectuée.

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

Problème : le service de données Sun Cluster HA pour SAP liveCache utilise la commande dbmcli pour démarrer et arrêter liveCache. Si vous exécutez Solaris 9, le service du réseau peut ne plus être disponible lorsque le réseau public d'un nœud tombe en panne.

Solution : ajoutez l'une des entrées suivantes de la base de données publickey dans les fichiers /etc/nsswitch.conf de chaque nœud susceptible d'être l'élément principal des ressources liveCache.

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

Les conditions requises pour nsswitch.conf ne s'appliquent pas à la base de données passwd (4904975)

Problème : les conditions requises pour le fichier nsswitch.conf, mentionnées dans Preparing the Nodes and Disks du 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 nœud capable de contrôler la ressource liveCache, vérifiez que l'entrée de la base de données passwd est la suivante dans le fichier /etc/nsswitch.conf.

passwd: files nis [TRYAGAIN=0]

Interruptions de sccheck (4944192)

Problème : sccheck peut s'interrompre s'il est lancé simultanément depuis plusieurs nœuds.

Solution : ne lancez pas sccheck depuis une console de commande multinœud. Les exécutions de sccheck peuvent se chevaucher mais ne doivent pas être lancées simultanément.

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

Problème : actuellement, le service de données HADB n'utilise pas la variable d'environnement JAVA_HOME. Il se sert donc des binaires Java de /usr/bin/. Ceux-ci doivent être d'une version 1.4 minimum pour que le service de données HADB fonctionne normalement.

Solution : si vous ne voyez pas d'inconvénient à modifier la version disponible par défaut, exécutez la procédure suivante. 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. Si le répertoire java/ se trouve dans /usr/, déplacez-le vers un emplacement temporaire.

2. À partir du répertoire /usr/, associez /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 disponible par défaut, attribuez la variable d'environnement JAVA_HOME à la version appropriée de Java (J2SE 1.4 ou version ultérieure) dans le script de /opt/SUNWappserver7/SUNWhadb/4/bin/hadbm.

La création d'un nœud nécessite la réinitialisation du cluster (4971299)

Problème : dans un cluster modifié utilisant Support Sun Cluster pour Oracle Real Application Clusters et VxVM, cette dernière fonction s'exécute sur les nœuds existants mais ignore le nouvel élément.

Solution : VERITAS résoudra normalement ce problème dans VxVM 3.5 MP4 et 4.0 MP2. Pour la version 4.1, le correctif est déjà disponible.

Actuellement, vous pouvez résoudre le problème en redémarrant la base de données Oracle et en réinitialisant les nœuds de cluster. Cette étape synchronise Oracle UDLM et met à jour la fonction de cluster VxVM pour reconnaître le nœud ajouté.

Avant d'installer et de configurer Support Sun Cluster pour Oracle Real Application Clusters sur le nouveau nœud, vous devez effectuer cette étape.

1. Sur un nœud de cluster différent de celui qui vient d'être ajouté, arrêtez la base de données Oracle Real Application Clusters.

2. Réinitialisez le nœud concerné par l'arrêt de la base de données Oracle.

   # scswitch -S -h thisnode # shutdown -g0 -y -i6

   Attendez que le nœud de cluster soit complètement réinitialisé avant de passer à l'étape suivante.

3. Relancez la base de données Oracle.

4. Répétez les étapes 1 à 3 sur les autres nœuds exécutant Support Sun Cluster pour Oracle Real Application Clusters.

   • Si un seul nœud peut gérer la charge de travail de la base de données Oracle, vous pouvez effectuer ces étapes sur plusieurs nœuds simultanément.

   • Si plusieurs nœuds sont requis pour accepter la charge de travail de la base de données, effectuez ces étapes sur un nœud à la fois.

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

Problème : le bogue 4974875 provoque la réinitialisation de la base de données sans aucun disque de spare à chaque récupération automatique. 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 : effectuez l'une des procédures suivantes pour modifier les rôles des nœuds HA-DB.

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 nombd -node numnœud -setrole rôle-avant-récupération_automatique

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 nombd -node numnœud -setrole rôle-avant-récupération_automatique

pnmd inaccessible aux autres nœuds durant la mise à niveau progressive (4997693)

Problème : si certains nœuds n'appliquent pas la mise à niveau progressive, ils ignorent les groupes IPMP des éléments modifiés.

Solution : terminez l'actualisation.

Le champ de date du panneau de filtrage spécial accepte uniquement le format mm/jj/aaaa (5075018)

Problème : le champ de date du panneau de filtrage spécial du gestionnaire SunPlex accepte uniquement le format mm/jj/aaaa. Toutefois, le format de date des environnements non anglais et celui retourné par le panneau de planification diffèrent de mm/jj/aaaa.

Solution : saisissez la plage de dates dans le panneau de filtrage spécial au format mm/jj/aaaa. N'utilisez pas le bouton de définition pour afficher le calendrier et sélectionner la date.

Dans l'environnement japonais, les messages d'erreur de scrgadm comportent des caractères indésirables (5083147)

Problème : dans l'environnement japonais, les messages d'erreur de scrgadm ne s'affichent pas correctement. Ils comportent des caractères indésirables.

Solution : exécutez l'environnement système anglais pour afficher les messages d'erreur dans cette langue.

Le script /usr/cluster/lib/cmass/ipmpgroupmanager.sh ne reconfigure pas l'interface IPv6 (6174170)

Problème : le gestionnaire SunPlex utilise la commande /usr/cluster/lib/cmass/ipmpgroupmanager.sh pour supprimer des groupes IPMP et leurs adaptateurs. Ce script met à jour le fichier /etc/hostname6.adaptername en supprimant le nom du groupe. Pour ne pas reconfigurer l'interface IPv6, il exécute toutefois la commande ifconfig suivante :

ifconfig adaptername inet6 unplumb

Solution : réinitialisez le nœud pour reconfigurer l'interface. Sur cet élément, vous pouvez également exécuter la commande ifconfig suivante. Cette solution de rechange ne nécessite pas la réinitialisation du nœud.

ifconfig adaptername inet6 plumb up

La liste des adaptateurs de la page de groupe IPMP doit dépendre de la version IP choisie par l'utilisateur (6174805)

Problème : la liste des adaptateurs affichée dans les pages de groupe IPMP ne dépend pas de la version IP sélectionnée par l'utilisateur. La page dresse une liste de tous les adaptateurs pour lesquels aucun groupe n'est configuré. Cette liste doit être mise à jour lorsque le bouton radio correspondant à la version IP est sélectionné, comme suit :

• Si IPV4 only est sélectionné, aucun adaptateur IPv4/IPv6 ni IPv6 ne doit figurer dans la liste.

• Si IPV6 only est sélectionné, aucun adaptateur IPv4/IPv6 ni IPv4 ne doit figurer dans la liste.

• Si IPV4 and IPv6 est sélectionné, aucun adaptateur IPv6 ni IPv4 ne doit figurer dans la liste.

Solution : après avoir sélectionné la version IP, ne choisissez dans la liste que l'adaptateur qui correspond à cette version.

Lorsqu'un adaptateur IPv4/IPv6 est mis à niveau vers IPv4, la version IPv4 n'est pas supprimée (6179721)

Problème : la liste des adaptateurs affichée sur les pages de groupe IPMP dépend de la version IP choisie par l'utilisateur. Dans la version actuelle du gestionnaire SunPlex, un bogue affiche systématiquement la liste de tous les adaptateurs, quelle que soit la version IP sélectionnée. Le gestionnaire SunPlex ne doit pas permettre à l'utilisateur de mettre à niveau un adaptateur compatible avec IPv4/IPv6 vers une version IPv4.

Solution : l'utilisateur ne doit pas tenter de mettre à niveau un adaptateur configuré pour IPv4/IPv6 vers un adaptateur IPv4.

Échec de la configuration de Sun Java System Administration Server si le package SUNWasvr n'est pas installé (6196005)

Problème : la configuration du service de données pour Sun Java System Administration Server échoue lorsque Sun Java System Administration Server n'est pas installé. Cette tentative échoue parce que le type de ressource SUNW.mps requiert le répertoire /etc/mps/admin/v5.2/cluster/SUNW.mps. Or ce répertoire existe uniquement si le package SUNWasvr est installé.

Solution : pour résoudre ce problème, suivez la procédure suivante.

Installation du package SUNWasvr

Étapes

1. Ouvrez une session en tant que superutilisateur ou avec un rôle équivalent sur un nœud de cluster.

2. Vérifiez si le package SUNWasvr est installé.

   # pkginfo SUNWasvr

3. Si le package SUNWasvr n'est pas installé, procédez à l'installation à partir du CD-ROM de Sun Cluster :

   1. Insérez le CD-ROM 2/2 de Sun Cluster dans le lecteur approprié.

   2. Ouvrez le répertoire contenant le package SUNWasvr.

      # cd /cdrom/cdrom0/Solaris_sparc/Product/administration_svr/Packages

   3. Entrez la commande suivante pour installer le package.

      # pkgadd -d . SUNWasvr

   4. Retirez le CD-ROM du lecteur.

Les modifications de startd/duration ne prennent pas effet immédiatement (6196325)

Problème : avec Solaris 10, le service de données Sun Cluster HA pour NFS définit la propriété /startd/duration sur la valeur transient pour les services SMF (Service Management Facility) suivants :/network/nfs/server, /network/nfs/status et /network/nfs/nlockmgr . Cette propriété empêche SMF de redémarrer ces services en cas de panne. Un bogue dans SMF entraîne le redémarrage de /network/nfs/status et de /network/nfs/nlockmgr après la première panne, même lorsque cette propriété est correctement configurée.

Solution : pour permettre à Sun Cluster HA pour NFS de fonctionner normalement, exécutez la commande suivante sur tous les nœuds après avoir créé la première ressource Sun Cluster HA pour NFS et avant de connecter la ressource Sun Cluster HA pour NFS.

# pkill -9 -x 'startd|lockd'

Lors de la première initialisation de Sun Cluster, exécutez la commande ci-dessus sur tous les nœuds principaux potentiels, après avoir créé la première ressource Sun Cluster HA pour NFS et avant de connecter la ressource Sun Cluster HA pour NFS.

scinstall ne copie pas tous les fichiers de sécurité du conteneur d'agent commun (6203133)

Problème : lors de l'ajout d'un nœud à un cluster, l'utilitaire scinstall recherche la présence de fichiers Network Security Services (NSS) sur le nouveau nœud. Ces fichiers et les clés de sécurité sont requis par le conteneur d'agents communs. Si les fichiers NSS existent, l'utilitaire copie les fichiers de sécurité du conteneur d'agents communs du nœud parrain vers le nœud ajouté. Toutefois si les clés de sécurité NSS ne sont pas installées sur le nœud parrain, la copie échoue et le processus scinstall s'interrompt.

Solution : exécutez la procédure suivante pour installer le logiciel NSS, recréer les clés de sécurité et redémarrer le conteneur d'agents communs sur les nœuds de cluster existants.

Installation du logiciel NSS lors de l'ajout d'un nœud à un cluster

Exécutez la procédure suivante sur tous les nœuds de cluster existants en tant que superutilisateur ou avec un rôle autorisant l'accès requis.

Avant de commencer

Conservez le CD 1 de Sun Cluster à portée de main. Les packages NSS se trouvent dans le répertoire /cdrom/cdrom0/Solaris_arch/Product/shared_components/Packages/, où arch est sparc ou x86 et ver est 8 pour Solaris 8, 9 pour Solaris 9 ou 10 pour Solaris 10.

Étapes

1. Sur chaque nœud, arrêtez l'agent Console Web de Sun.

   # /usr/sbin/smcwebserver stop

2. Sur chaque nœud, arrêtez l'agent de fichiers de sécurité.

   # /opt/SUNWcacao/bin/cacaoadm stop

3. Sur chaque nœud, vérifiez si les packages NSS ont été installés et déterminez leur version, le cas échéant.

   # cat /var/sadm/pkg/SUNWtls/pkginfo | grep SUNW_PRODVERS SUNW_PRODVERS=3.9.4

4. Retirez tout package NSS dont la version est antérieure à 3.9.4.

   # pkgrm packages

   Le tableau suivant répertorie les packages applicables pour chaque plate-forme matérielle.

   Plate-forme matérielle	Noms des packages NSS
   SPARC	SUNWtls SUNWtlsu SUNWtlsx
   x86	SUNWtls SUNWtlsu

5. Sur chaque nœud, si vous avez supprimé des packages NSS ou si aucun n'est installé, installez la dernière version des packages NSS à partir du CD 1 de Sun Cluster.

   • Sous Solaris 8 ou Solaris 9, utilisez la commande suivante :

     # pkgadd -d . packages

   • Sous Solaris 10, utilisez la commande suivante :

     # pkgadd -G -d . packages

6. Allez dans un répertoire ne figurant pas sur le CD-ROM, puis éjectez ce dernier.

   # eject cdrom

7. Sur chaque nœud, créez les clés de sécurité NSS.

   # /opt/SUNWcacao/bin/cacaoadm create-keys

8. Sur chaque nœud, lancez l'agent de fichiers de sécurité.

   # /opt/SUNWcacao/bin/cacaoadm start

9. Sur chaque nœud, démarrez l'agent Console Web de Sun.

   # /usr/sbin/smcwebserver start

10. Sur le nœud ajouté au cluster, redémarrez l'utilitaire scinstall et exécutez les procédures pour installer le nouveau nœud.

La suppression d'un groupe d'interfaces publiques comportant les adaptateurs IPv4 et IPv6 dans le gestionnaire SunPlex échoue parfois (6209229)

Problème : la suppression d'un groupe d'interfaces publiques pour lequel les adaptateurs IPv4 et IPv6 sont configurés échoue parfois au moment de la suppression de l'adaptateur IPv6 du groupe. Le message d'erreur suivant apparaît :

ifparse: Operation netmask not supported for inet6
/sbin/ifparse
/usr/cluster/lib/cmass/ipmpgroupmanager.sh[8]:
/etc/hostname.adaptname.tmpnumber: cannot open

Solution : ajoutez les lignes suivantes au fichier /etc/hostname6.adaptername :

plumb
up
-standby

Exécutez la commande ci-dessous sur le nœud de cluster :

ifconfig adaptername inet6 plumb up -standby

Fuite de mémoire durant la procédure de réinitialisation du patch (nœud) (bogue 6210440)

Problème : le programme Sun Cluster s'arrête durant la procédure de mise à niveau progressive de Sun Cluster 3.1 9/04 vers Sun Cluster 3.1 8/05 en raison d'un problème de mémoire déclenché lorsque le premier nœud mis à niveau est réinitialisé en mode cluster.

Solution : si vous exécutez Sun Cluster 3.1 9/04 ou le patch équivalent (version 09 ou ultérieure) et souhaitez suivre une procédure de réinitialisation de patch pour évoluer vers Sun Cluster 3.1 8/05 ou le patch équivalent (version 12), effectuez les opérations suivantes avant de mettre votre cluster à niveau ou d'appliquer ce patch de base.

Préparation de la mise à niveau vers Sun Cluster 3.1 8/05

Étapes

1. Sélectionnez le type de procédure d'installation de patch qui convient à vos critères de disponibilité :

   • Réinitialisation du patch (nœud)

   • Réinitialisation du patch (cluster et microprogramme)

   Ces procédures d'installation de patch sont décrites dans le Chapitre 8, Patchs pour logiciel et microprogramme Sun Cluster du Guide d’administration système de Sun Cluster pour SE Solaris.

2. Appliquez l'un des patchs ci-après selon votre système d'exploitation :

   • Patch de base 117909-11 Sun Cluster 3.1 pour SunOS 5.9 X86

   • Patch de base 117950-11 Sun Cluster 3.1 pour Solaris 8

   • Patch de base 117949-11 Sun Cluster 3.1 pour Solaris 9

   Vous devez achever l'installation du patch avant d'évoluer vers Sun Cluster 3.1 8/05 ou le patch équivalent (version 12).

Zone Install et Zone Boot ne fonctionnent pas après l'installation de Sun Cluster (6211453)

Problème : l'installation de Sun Cluster ajoute exclude: lofs à /etc/system. La commande lofs étant indispensable au fonctionnement de zones, les commandes zone install et zone boot échouent.

Solution : avant de tenter de créer des zones, exécutez la procédure suivante.

Exécution de Zone Install et de Zone Boot après l'installation de Sun Cluster

Étapes

1. Si vous exécutez Sun Cluster HA pour NFS, excluez du plan de montage automatique tous les fichiers du système local à haute disponibilité exporté par le serveur.

2. Sur chaque nœud de cluster, modifiez le fichier /etc/system en supprimant toutes les lignes exclude: lofs.

3. Réinitialisez le cluster.

Sous Solaris 10, des étapes supplémentaires sont requises pour la récupération après échec du montage du système de fichiers de cluster à l'initialisation (6211485)

Problème : lorsque le montage du système de fichiers de cluster à l'initialisation échoue, Solaris 10 nécessite des procédures de récupération différentes des versions antérieures. Au lieu d'afficher une invite de connexion, le service mountgfsys s'interrompt parfois et place le nœud en mode maintenance. Les messages résultants se présentent comme suit :

WARNING - Unable to globally mount all filesystems.
Check logs for error messages and correct the problems.
 
May 18 14:06:58 pkaffa1 svc.startd[8]: system/cluster/mountgfsys:default misconfigured
 
May 18 14:06:59 pkaffa1 Cluster.CCR: /usr/cluster/bin/scgdevs:
Filesystem /global/.devices/node@1 is not available in /etc/mnttab.

Solution : après résolution du problème de montage du système de fichiers de cluster, vous devez reconnecter manuellement le service mountgfsys. Exécutez les commandes suivantes pour connecter le service mountgfsys et synchroniser l'espace de nom des périphériques globaux :

# svcadm clear svc:/system/cluster/mountgfsys:default
# svcadm clear svc:/system/cluster/gdevsync:default

Le processus d'initialisation se poursuit.

La non-prise en charge de la mise à niveau vers Solaris 10 altère le fichier /etc/path_to_inst (6216447)

Problème : Sun Cluster 3.1 8/05 ne prend pas en charge la mise à niveau vers la version Solaris 10 de mars 2005. Toute tentative de mise à niveau vers cette version risque d'altérer le fichier /etc/path_to_inst. La corruption de ce fichier empêche l'initialisation du nœud. Le fichier altéré se présente comme ci-dessous. Il contient des entrées en double. Toutefois, le nom du périphérique physique a le préfixe /node@nodeid :

…
"/node@nodeid/physical_device_name" instance_number "driver_binding_name"
…
"/physical_device_name" instance_number "driver_binding_name"

En outre, certains services clés de Solaris risquent de ne pas démarrer, notamment ceux de réseau et de montage du système de fichiers. Pour signaler leur configuration incorrecte, la console peut afficher des messages.

Solution : effectuez la procédure suivante.

Récupération d'un fichier /etc/path_to_inst altéré

La procédure suivante décrit la récupération du fichier /etc/path_to_inst altéré après mise à niveau vers Solaris 10.

Elle ne résout aucun autre problème lié à la mise à niveau d'une configuration de Sun Cluster vers la version Solaris 10 de mars 2005.

Exécutez cette procédure sur tous les nœuds mis à niveau vers la version Solaris 10 de mars 2005.

Avant de commencer

Si nécessaire, initialisez un nœud à partir du réseau ou d'un CD-ROM. Après initialisation du nœud, exécutez la commande fsck et montez le système de fichiers local sur une partition (par exemple, /a). À l'étape 2, indiquez le nom du montage du système de fichiers local dans le chemin d'accès au répertoire /etc.

Étapes

1. Lancez une session superutilisateur ou équivalente sur le nœud.

2. Allez dans le répertoire /etc.

   # cd /etc

3. Vérifiez si le fichier path_to_inst est altéré.

   Les caractéristiques suivantes révèlent la corruption du fichier path_to_inst :

   • Dans le fichier, un bloc d'entrées indique /node@nodeid au début des noms de périphérique physique.

   • Certaines sont en double mais elles n'ont pas de préfixe /node@nodeid.

   Si le fichier ne se présente pas sous cette forme, il comporte d'autres problèmes. Ne poursuivez pas cette procédure. Pour obtenir de l'aide, contactez votre représentant de maintenance Sun.

4. Si le fichier path_to_inst présente la corruption décrite à l'étape 3, exécutez les commandes suivantes.

   # cp path_to_inst path_to_inst.bak # sed -n -e "/^#/p" -e "s,node@./,,p" path_to_inst.bak > path_to_inst

5. Vérifiez que le fichier path_to_inst est corrigé.

   Le fichier réparé doit présenter les modifications suivantes :

   • Le préfixe /node@nodeid est maintenant absent de tous les noms de périphérique physique.

   • Aucune entrée de nom de périphérique physique n'est en double.

6. Vérifiez que le fichier path_to_inst est en lecture seule.

   # ls -l /etc/path_to_inst -r--r--r-- 1 root root 2946 Aug 8 2005 path_to_inst

7. Réinitialisez la reconfiguration en mode non-cluster.

   # reboot -- -rx

8. Après avoir réparé tous les nœuds de cluster altérés, passez à l'étape Mise à niveau du logiciel dépendant avant une mise à niveau non progressive du Guide d’installation du logiciel Sun Cluster pour SE Solaris pour poursuivre la mise à niveau.

Expiration du rappel de reconfiguration CMM - abandon du nœud (6217017)

Problème : sur les clusters x86 dotés d'une fonction de transport ce, CMM peut arrêter un nœud soumis à une charge élevée en raison d'un split brain.

Solution : sur les clusters x86 utilisant la carte PCI Gigaswift Ethernet sur le réseau privé, ajoutez la ligne suivante dans le fichier /etc/system.

set ce:ce_tx_ring_size=8192

Sous Solaris 10 et un système de stockage Hitachi, une grave erreur peut se produire si vous ajoutez ou supprimez un élément d'un cluster multinœud (6227074)

Problème : sous Solaris 10 et un système de stockage Hitachi, une grave erreur peut se produire si vous ajoutez ou supprimez un élément d'un cluster multinœud.

Solution : il n'existe actuellement aucune solution. Si vous rencontrez ce problème, demandez un patch à votre prestataire de services Sun.

La commande installer de Java ES 2005Q1 n'installe pas complètement Application Server 8.1 EE (6229510)

Problème : la commande installer de Java ES 2005Q1 ne peut pas installer Application Server Enterprise Edition 8.1 si l'option Configure Later est sélectionnée. L'option Configure Later installe Platform et non Enterprise Edition.

Solution : lorsque vous installez Application Server Enterprise Edition 8.1 à l'aide de la commande installer de Java ES, utilisez l'option Configure Now. L'option Configure Later installe uniquement Platform Edition.

scvxinstall redémarre le service rpcbind(6237044)

Problème : le redémarrage du service de liaison SMF peut perturber le fonctionnement de Solaris Volume Manager. L'installation des packages VxVM 4.1 entraîne le redémarrage du service de liaison SMF.

Solution : réinitialisez Solaris Volume Manager après le redémarrage du service de liaison SMF ou l'installation de VxVM 4.1 sur un hôte Solaris 10.

svcadm restart svc:/network/rpc/scadmd:default

Sous Solaris 10, les services de données de Sun Cluster ne s'installent pas après utilisation de la commande installer de Java ES (6237159)

Problème : ce problème concerne uniquement les systèmes sous Solaris 10. Si vous utilisez la commande installer de Java ES sur le CD-ROM Sun Cluster Agents pour installer les services de données Sun Cluster après le composant principal, elle échoue et envoie les messages suivants :

The installer has determined that you must manually remove incompatible versions
of the following components before proceeding:

[Sun Cluster 3.1 8/05, Sun Cluster 3.1 8/05, Sun Cluster 3.1 8/05]

After you remove these components, go back.
Component                       Required By ...

1. Sun Cluster 3.1 8/05     HA Sun Java System Message Queue : HA Sun Java
                            System Message Queue
2. Sun Cluster 3.1 8/05     HA Sun Java System Application Server : HA Sun Java
									System Application Server
3. Sun Cluster 3.1 8/05     HA/Scalable Sun Java System Web Server : HA/Scalable
									Sun Java System Web Server
4. Select this option to go back to the component list. This process might take
									a few moments while the installer rechecks your
									system for installed components.

Select a component to see the details. Press 4 to go back the product list
[4] {"<" goes back, "!" exits}

Solution : sous Solaris 10, installez le service de données Sun Cluster manuellement à l'aide de la commande pkgadd ou scinstall. Si le service de données Sun Cluster dépend de composants partagés, installez ces derniers manuellement à l'aide de la commande pkgadd. Le lien suivant donne accès à la liste des composants partagés de chaque produit :

Message d'erreur /usr/sbin/smcwebserver: ... j2se/opt/javahelp/lib: does not exist (6238302)

Problème : au cours du démarrage de Sun Web Console, le message suivant peut s'afficher.

/usr/sbin/smcwebserver:../../../../j2se/opt/javahelp/lib: does not exist

Solution : vous pouvez ignorer ce message. Dans le fichier /usr/j2se/opt, vous pouvez ajouter manuellement un lien correct vers Java Help 2.0, en entrant la ligne suivante :

# ln -s /usr/jdk/packages/javax.help-2.0 /usr/j2se/opt/javahelp

Grave erreur de nœud après mise à niveau vers Solaris 10 pour Sun Cluster 3.1 4/04 (6245238)

Problème : après mise à niveau vers Solaris 10 pour Sun Cluster 3.1 4/04 minimum, l'initialisation du nœud en mode non-cluster provoque une grave erreur.

Solution : installez l'un des patchs suivants avant mise à niveau vers Solaris 10.

• Systèmes SPARC : 117949-09 minimum

• Systèmes x86 : 117909-09 minimum

Le programme d'installation SunPlex ne crée pas de ressources dans les groupes de ressources (6250327)

Problème : si le programme d'installation SunPlex sert à configurer les services de données Sun Cluster HA pour Apache et Sun Cluster HA pour NFS lors de l'installation de Sun Cluster, il ne crée pas les ressources et les groupes de périphériques nécessaires.

Solution : ne l'utilisez pas dans ce cadre. Pour installer et configurer ces services de données, suivez plutôt les procédures des manuels Guide d’installation du logiciel Sun Cluster pour SE Solaris et Sun Cluster Data Service for Apache Guide for Solaris OS ou Sun Cluster Data Service for NFS Guide for Solaris OS.

Modification de HA-NFS pour prendre en charge la correction de NFSv4 pour 6244819 (6251676)

Problème : Sun Cluster 3.1 8/05 ne prend pas en charge NFSv4.

Solution : Solaris 10 présente NFSv4. Cette nouvelle version est le protocole par défaut pour ses clients et son serveur. La version Sun Cluster 3.1 8/05 prend en charge Solaris 10 et non NFSv4 avec le service Sun Cluster HA pour NFS du cluster pour un serveur à haute disponibilité. Pour garantir la non-utilisation du protocole avec un serveur NFS dans Sun Cluster, modifiez le fichier /etc/default/nfs en remplaçant la ligne NFS_SERVER_VERSMAX=4 par NFS_SERVER_VERSMAX=3. Ainsi, les clients du service Sun Cluster HA pour NFS du cluster pourront uniquement appliquer NFSv3.

REMARQUE: cette restriction et la solution ci-dessus ne concernent pas l'utilisation de nœuds de cluster Solaris 10 en tant que clients NFSv4. Les nœuds de cluster peuvent jouer le rôle de clients NFSv4.

Échec de la commande metaset après redémarrage du service rpcbind (6252216)

Problème : la commande metaset échoue après redémarrage du service rpcbind.

Solution : assurez-vous qu'aucune opération de configuration n'est en cours sur le système Sun Cluster, puis arrêtez le processus rpc.metad à l'aide de la commande suivante.

# pkill -9 rpc.metad

Grave erreur de nœud suite à l'erreur d'étape de retour metaclust : RPC: Programme non enregistré (6256220)

Problème : lors de la fermeture du cluster, l'ordre d'arrêt des services risque de provoquer une grave erreur sur certains nœuds. Si le service RPC est arrêté avant la structure RAC, des erreurs peuvent se produire lors de tentatives de reconfiguration de la ressource SVM. Un avertissement est alors envoyé à la structure RAC. Il provoque une grave erreur de nœud. Ce problème a été observé lorsque Sun Cluster exécute la structure RAC avec l'option de stockage SVM. Il ne doit pas se répercuter sur la fonctionnalité de Sun Cluster.

Solution : cette grave erreur est normale et peut être ignorée sans danger. Toutefois, les fichiers principaux enregistrés doivent être nettoyés pour récupérer de l'espace dans le système de fichiers.

Le blocage du service de résolution d'adresse NIS empêche le basculement (6257112)

Problème : sous Solaris 10, le fichier /etc/nsswitch.conf a été modifié afin d'inclure NIS dans l'entrée ipnodes.

ipnodes:    files nis [NOTFOUND=return]

Cette modification provoque le blocage du service de résolution d'adresse si NIS devient inaccessible suite à un problème interne ou à une panne de tous les adaptateurs de réseau public. Ce problème se traduit à terme par l'échec du basculement des ressources de l'opération ou d'adresse partagée.

Solution : effectuez les opérations suivantes avant de créer un hôte logique ou des ressources d'adresse partagée.

1. Modifiez l'entrée ipnodes dans le fichier /etc/nsswitch.conf en remplaçant [NOTFOUND=return] par [TRYAGAIN=0].

   ipnodes: files nis [TRYAGAIN=0]

2. Veillez à ajouter toutes les adresses IP des hôtes logiques et les adresses partagées dans les fichiers /etc/inet/ipnodes et /etc/inet/hosts.

scinstall ne met pas à niveau le service de données Sun Cluster pour Sun Java System Application Server EE (6263451)

Problème : lors de la mise à jour du service de données Sun Cluster pour Sun Java System Application Server EE, de la version 3.1 9/04 vers la version 3.1 8/05, scinstall ne supprime pas le package pour j2ee et affiche le message suivant.

Skipping "SUNWscswa" - already installed

Le service de données Sun Cluster pour Sun Java System Application Server EE n'est pas mis à niveau.

Solution : supprimez et ajoutez manuellement le package sap_j2ee à l'aide des commandes suivantes.

# # pkgrm SUNWscswa
# pkgadd [-d device] SUNWscswa

scnas : Le système de fichiers NAS n'a pas été monté durant l'initialisation (6268260)

Problème : la viabilité du système de fichiers NFS ne peut pas être vérifiée avant basculement ou utilisation de scswitch pour localiser le service de données sur le nœud. Le basculement vers un nœud sans système de fichiers NFS entraînera l'échec du service de données et nécessitera une intervention manuelle. Un mécanisme du type HAStoragePlus est requis pour vérifier la viabilité du système de fichiers avant toute tentative de basculement vers un nœud.

Solution : les systèmes de fichiers utilisant un classement NAS (entrées dans le fichier /etc/vfstab) sont montés hors du contrôle de Sun Cluster. Ce logiciel ignore donc les problèmes éventuels. En cas de non-disponibilité du système de fichiers, certains services de données, notamment Sun Cluster HA pour Oracle, échouent lors de l'exécution de méthodes telles que START ou STOP.

L'échec de ces méthodes offre plusieurs possibilités :

• La ressource de services de données, notamment HA-Oracle, peut passer en mode STOP_FAILED si les binaires de l'application (Oracle) ne sont pas disponibles.

• Le service de données peut poursuivre ses tentatives de basculement vers d'autres nœuds jusqu'au démarrage réussi ou à l'épuisement des possibilités.

Effectuez l'une des procédures suivantes pour éviter ces problèmes :

• Placez les binaires de l'application sur le système de fichiers du cluster ou de basculement. Configurez ensuite une ressource HAStoragePlus pour représenter ce système de fichiers et enregistrer une dépendance de l'application à cette ressource. Le système ne tentera pas de démarrer l'application tant que le système de fichiers ne sera pas disponible.

• Placez les binaires de l'application sur le système de fichiers racine local. Si le système de fichiers racine local ne fonctionne pas, le nœud ne parvient pas à intégrer le cluster et le système tente de démarrer l'application à cet emplacement.

Le détecteur de pannes HADB ne redémarre pas le processus ma (6269813)

Problème : le service de données Sun Cluster ne redémarre pas le processus ma s'il s'interrompt ou s'arrête brusquement.

Solution : ce comportement est normal et les services de données n'en sont pas perturbés.

rgmd procède au vidage durant la mise à niveau progressive (6271037)

Problème : lors d'une mise à niveau progressive, la tentative de suppression d'une ressource, avant exécution du nouveau logiciel sur tous les nœuds, risque de provoquer une grave erreur. Ne supprimez pas une ressource avant l'installation du nouveau logiciel sur tous les nœuds.

Solution : durant une mise à niveau progressive, ne supprimez pas une ressource RGM tant que le nouveau logiciel n'est pas installé sur tous les nœuds.

Échec de redémarrage de la base de données HADB après fermeture et initialisation du cluster (6276868)

Problème : la base de données HADB ne redémarre pas après la réinitialisation de tous les nœuds du cluster. L'utilisateur n'a pas accès à la base de données.

Solution : redémarrez l'un de vos services de données de gestion en suivant les étapes ci-dessous. Si la procédure suivante ne résout pas le problème, supprimez la base de données, puis recréez-la.

Redémarrage d'un service de données de gestion

Étapes

1. Sur le nœud à arrêter, entrez la commande suivante. L'option -h ne doit pas comporter le nom du nœud sur lequel arrêter l'agent de gestion.

   scswitch -z -g hadb resource grp -h node1, node2...

2. Basculez le groupe de ressources vers le nœud initial.

   scswitch —Z —g hadb resource grp

3. Vérifiez l'état de la base de données. Attendez que la base de données soit en mode “arrêté”.

   hadbm status -n database

4. Démarrez la base de données.

   hadbm start database

SUNW.iim a une taille nulle après l'ajout du package SUNWiimsc (6277593)

Problème : le package SUNWiimsc de sun_cluster_agents n'est pas valide. Après l'ajout de ce package, la taille du fichier SUNW.iim du répertoire /opt/SUNWiim/cluster est égale à 0.

Solution : remettez le package SUNW.iim en place et enregistrez-le à nouveau en procédant comme suit.

Installation du package SUNW.iim approprié

Étapes

1. Copiez le fichier SUNW.iim approprié du CD-ROM.

   # cp 2of2_CD/Solaris_arch/Product/sun_cluster_agents/Solaris_os /Packages/SUNWiimsc/reloc/SUNWiim/cluster/SUNW.iim /opt/SUNWiim/Cluster/SUNW.iim

2. Supprimez tout enregistrement existant de SUNW.iim.

   # rm /usr/cluster/lib/rgm/rtreg/SUNW.iim

3. Enregistrez le service de données avec Sun Cluster.

   sh 2of2_CD/Solaris_arch/Product/sun_cluster_agents/ Solaris_os/Packages/SUNWiimsc/install/postinstall

La création d'un groupe IPMP via le gestionnaire SunPlex échoue parfois (6278059)

Problème : la création d'un groupe IPMP via le gestionnaire SunPlex échoue parfois en générant le message suivant.

An error was encountered by the system. If you were performing an action
when this occurred, review the current system state prior to proceeding.

Solution : exécutez l'une des procédures suivantes selon la version d'IP utilisée.

Création d'un groupe IPMP via le gestionnaire SunPlex en présence d'un utilisateur Ipv4

Étapes

1. Entrez la commande suivante:

   ifconfig interface inet plumb group groupname [addif address deprecated] netmask + broadcast + up -failover

2. Si une adresse de test a été fournie, actualisez le fichier /etc/hostname .interface en y ajoutant les éléments suivants :

   group groupname addif address netmask + broadcast + deprecated -failover up

3. Si aucune adresse de test n'a été fournie, actualisez le fichier /etc/hostname.interface en y ajoutant les éléments suivants :

   group.groupname netmask + broadcast -failover up

Création d'un groupe IPMP via le gestionnaire SunPlex en présence d'un utilisateur IPv6

Étapes

1. Entrez la commande suivante :

   ifconfig interface inet6 plumb up group groupname

2. Actualisez le fichier /etc/hostname6.interface en y ajoutant les entrées suivantes :

   group groupname plumb up

3. Si le fichier /etc/hostname6.interface n'existe pas, créez-le et ajoutez-y les entrées indiquées.

Redémarrages continuels de la ressource HADB après une grave erreur de l'un des nœuds du cluster (6278435)

Problème : après la connexion de la ressource et une grave erreur de l'un des nœuds (par exemple, shutdown ou uadmin), la ressource redémarre continuellement sur les autres éléments de cluster. L'utilisateur ne peut pas exécuter de commandes de gestion.

Solution : pour éviter ce problème, connectez-vous à un nœud en lançant une session superutilisateur ou équivalente. À l'aide de la commande suivante, augmentez ensuite la valeur probe_timeout de la ressource à 600 secondes :

scrgadm -c -j hadb resource -x Probe_timeout=600

Pour vérifier votre modification, arrêtez l'un des nœuds de cluster et assurez-vous de la non-altération de la ressource.

Sous Solaris 10, les services évolutifs ne fonctionnent pas lorsque les réseaux publics et les fonctions de transport Sun Cluster utilisent des adaptateurs gérés par bge (7D) (6278520)

Problème : la fonction d'équilibrage de charge des services évolutifs de Sun Cluster n'est pas active sur les systèmes Solaris 10 sur lesquels les réseaux publics et les fonctions de transport utilisent des adaptateurs gérés par bge. Les plates-formes Sun Fire V210, V240 et V250 sont équipées de cartes réseau utilisant bge.

Ce bogue ne concerne pas les services de données de basculement.

Solution : ne définissez pas les réseaux publics et les fonctions de transport intracluster pour utiliser des adaptateurs gérés par bge.

Journal système inaccessible depuis le gestionnaire SunPlex lorsque l'environnement par défaut est multioctet (6281445)

Problème : lorsque l'environnement par défaut du gestionnaire SunPlex est multioctet, le journal système est inaccessible.

Solution : indiquez C comme environnement par défaut ou utilisez un shell de ligne de commande pour afficher manuellement le journal système (/var/adm/messages).

Connexion impossible de l'agent au nœud 1 via la commande scswitch (6283646)

Problème : les instances et les agents de nœud doivent être configurés pour attendre l'adresse IP/le nom d'hôte de basculement. Lorsque les agents de nœuds et les instances de Sun Java System Application Server sont créés, le nom d'hôte du nœud physique est défini par défaut. L'adresse IP HTTP et le nom d'hôte du client sont modifiés dans domain.xml. Toutefois, les modifications n'entrent pas en vigueur en raison du non-redémarrage du serveur d'administration de domaine . En conséquence, les agents sont uniquement présents sur le nœud physique de configuration.

Solution : obtenez l'adresse IP de basculement en modifiant la propriété client-hostname dans la section de l'agent de nœud de domain.xml. Pour appliquer les modifications, redémarrez le serveur d'administration de domaine .

Le gestionnaire SunPlex et Cacao 1.1 prennent en charge uniquement JDK 1.5.0_03 (6288183)

Problème : lorsque le gestionnaire SunPlex est utilisé dans Sun Cluster 3.1 8/05 avec Cacao 1.1, seule la version JDK 1.5.0_03 est prise en charge.

Solution : installez manuellement JDK 1.5 conformément à la procédure suivante.

Installation manuelle de JDK 1.5

Étapes

1. Ajoutez JDK 1.5 depuis les composants partagés de JES 4 (pour plus d'informations, reportez-vous aux notes de version).

2. Arrêtez cacao.

   # /opt/SUNWcacao/bin/cacaoadm stop

3. Démarrez cacao.

   # /opt/SUNWcacao/bin/cacaoadm start

Après l'installation des patchs SC3.1 (8/05) 117949–14 sous Solaris 9 et 117950–14 sous Solaris 8, des erreurs de machine virtuelle Java se produisent durant l'initialisation (6291206)

Problème : ce bogue se produit sur les systèmes Sun Cluster 3.1 9/04 mis à niveau vers 8/05 après application du patch 117949-14 (Solaris 9) ou 117950-14 (Solaris 8). Le message d'erreur suivant s'affiche à l'initialisation de la machine :

# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0xfaa90a88, pid=3102, tid=1
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_01-b07 mixed mode, sharing)
# Problematic frame:
# C  [libcmas_common.so+0xa88]  newStringArray+0x70
#
# An error report file with more information is saved as /tmp/hs_err_pid3102.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Solution : lors de la mise à niveau de Sun Cluster 3.1 9/04 vers 8/05, suivez la procédure ci-dessous pour installer notamment le patch SPM.

Sur un système Solaris 8, exécutez la commande suivante après application du patch principal 117950-14 :

 patchadd patchdir/118626-04

Sur un système Solaris 9, exécutez la commande suivante après application du patch 117949-14 :

patchadd patchdir/118627-04 

L'enregistrement des ressources du serveur d'annuaire ou d'administration échoue parfois (6298187)

Problème : l'enregistrement des ressources du serveur d'annuaire ou d'administration échoue parfois. Le système affiche le message suivant :

Registration file not found for "SUNW.mps" in /usr/cluster/lib/rgm/rtreg

Solution : enregistrez le fichier manquant directement depuis pkg en entrant l'une des commandes suivantes.

• Pour le serveur d'annuaire, entrez la commande suivante depuis pkg :

  - scrgadm -a -t SUNW.dsldap -f /etc/ds/v5.2/cluster/SUNW.dsldap

• Pour le serveur d'administration, entrez la commande suivante depuis pkg :

  - scrgadm -a -t SUNW.mps -f /etc/mps/admin/v5.2/cluster/SUNW.mps

Échec de communication des nœuds de cluster Solaris 10 avec des machines comportant des mappages d'adresses IPv4 et IPv6 (6306113)

Problème : si un nœud Sun Cluster exécutant Solaris 10 n'a pas d'interface IPv6 définie pour les réseaux publics (non destinée par exemple à des interconnexions de cluster), il n'a pas accès aux machines comportant des mappages d'adresses IPv4 et IPv6 dans un service de nom (de type NIS notamment). Les paquets des applications de type telnet et traceroot, qui privilégient l'adresse IPv6 plutôt qu'IPv4, seront envoyés vers les adaptateurs de transport intracluster, puis abandonnés.

Solution : appliquez l'une des solutions suivantes selon la configuration de votre cluster.

• Si IPv6 n'est pas requis pour le cluster, supprimez l'entrée nis de la ligne ipnodes dans le fichier /etc/nsswitch.conf. Par exemple, remplacez la ligne ipnodes par ce qui suit :

  ipnodes files # Work Around for CR 6306113

• Si IPv6 est requis sans qu'un service évolutif ne s'exécute sur le cluster, ajoutez la ligne suivante dans le fichier /etc/system et réinitialisez tous les nœuds.

  set clcomm:ifk_disable_v6=1

• Si le service évolutif IPv6 est en cours d'exécution, assurez-vous que tous les nœuds de cluster ont une interface réseau IPv6 définie pour les réseaux publics (mode non-cluster). Reportez-vous à ifconfig(1M) et System Administration Guide: IP Services pour des informations sur le déploiement IPv6 avec Solaris.