Notes de version de Sun Cluster 3.0 5/02

Problèmes connus

Les problèmes suivants ont une incidence sur le fonctionnement de Sun Cluster 3.0 5/02. Pour obtenir les informations les plus récentes, voir le Sun Cluster 3.0 5/02 Release Notes Supplement en ligne à l'adresse http://docs.sun.com.

Bogue nº 4490386

Récapitulatif du problème : Lorsqu'une grappe utilise des serveurs Sun Enterprise 10000, ceux-ci ont tendance à ne plus savoir comment se comporter lorsque les cartes E/S sont configurées d'une telle façon.

Solution : N'installez pas de cartes E/S UDWIS dans l'emplacement 0 d'une carte E/S SBus de serveurs Sun Enterprise 10000 en grappe.

Bogue nº 4501655

Récapitulatif du problème : Le blocage d'enregistrements ne fonctionne pas sur un ou plusieurs autre(s) noeud(s) lorsque le périphérique essayant de se verrouiller est un périphérique global, par exemple /dev/global/rdsk/d4s0.

La fonction semble marcher normalement lorsque le programme est exécuté à plusieurs reprises dans l'arrière-plan d'un noeud déterminé. Le comportement attendu est que, après que la première copie du programme verrouille une partie du périphérique, les copies suivantes se bloquent et attendent que le périphérique soit déverrouillé. Néanmoins, lorsque le programme est exécuté à partir d'un noeud différent, il arrive à verrouiller à nouveau le périphérique, alors que, en fait, il devrait se bloquer et attendre le déverrouillage du périphérique.

Solution : Il n'y a pas de solution pour l'instant.

Bogue nº 4504311

Récapitulatif du problème : Lors du passage au logiciel Solaris 8 10/01 (obligatoire pour la mise à niveau de Sun Cluster 3.0 12/01) dans une configuration Sun Cluster, les scripts Apache de début et de fin sont restaurés. Si un service de données Apache (Sun Cluster HA for Apache) est déjà présent sur la grappe et est paramétré sur la configuration par défaut (le fichier /etc/apache/httpd.conf existe et le fichier /etc/rc3.d/S50apache n'existe pas), l'application Apache démarre toute seule, indépendamment du service de données Sun Cluster HA for Apache. Cela empêche le lancement du service de données, car l'application Apache est déjà en cours d'exécution.

Solution : Procédez comme suit sur chaque noeud.

Avant d'arrêter un noeud que vous souhaitez mettre à niveau, voyez si les liens suivants existent et, si c'est le cas, si les noms de fichiers comportent un K ou un S majuscule.
/etc/rc0.d/K16apache /etc/rc1.d/K16apache /etc/rc2.d/K16apache /etc/rc3.d/S50apache /etc/rcS.d/K16apache
Si ces liens existent et qu'un K ou un S majuscule figure dans le nom de fichier, vous n'avez rien à faire de plus. Sinon, passez à l'étape suivante, une fois que le logiciel Solaris 8 10/01 est installé sur le noeud.

Une fois que le logiciel Solaris 8 10/01 est installé sur le noeud, mais avant de réinitialiser le noeud, mettez de coté les liens Apache restaurés en insérant un k ou un s minuscule dans les noms de fichiers.

# mv /a/etc/rc0.d/K16apache /a/etc/rc0.d/k16apache
# mv /a/etc/rc1.d/K16apache /a/etc/rc1.d/k16apache
# mv /a/etc/rc2.d/K16apache /a/etc/rc2.d/k16apache
# mv /a/etc/rc3.d/S50apache /a/etc/rc3.d/s50apache
# mv /a/etc/rcS.d/K16apache /a/etc/rcS.d/k16apache

Bogue nº 4511699

Récapitulatif du problème : Sun Cluster HA for NFS impose files [SUCCESS=return] pour l'entrée de recherche hosts dans le fichier /etc/nsswitch.conf, et impose que toutes les adresses IP privées de la grappe soient présentes dans le fichier /etc/inet/hosts sur tous les noeuds de la grappe.

Sinon, Sun Cluster HA for NFS ne peut pas procéder correctement à la reprise sur panne en cas de défaillances du réseau public.

Solution : Effectuez les étapes suivantes sur chaque noeud de la grappe.

Modifiez l'entrée hosts dans le fichier /etc/nsswitch.conf de sorte que, en cas de réussite de résolution d'un nom localement, elle renvoie immédiatement la réussite et ne contacte ni NIS, ni DNS.
hosts: cluster files [SUCCESS=return] nis dns

Ajoutez des entrées pour toutes les adresses IP privées de la grappe dans le fichier /etc/inet/hosts.

Vous devez uniquement répertorier les adresses IP présentes sur les interfaces privées physiques dans les fichiers /etc/nsswitch.conf et /etc/inet/hosts. Les adresses IP logiques sont déjà solutionnables via la bibliothèque de la grappe nsswitch.

Pour répertorier les adresses IP privées physiques, exécutez la commande suivante sur un noeud de la grappe.

% grep ip_address /etc/cluster/ccr/infrastructure

Chaque adresse IP dans cette liste doit se voir attribuer un nom d'hôte distinct, différent des autres noms d'hôte du domaine.

Remarque :

Le logiciel Sun Cluster impose déjà que les adresses IP HA (LogicalHostname/SharedAddresses) soient présentes dans /etc/inet/hosts sur tous les noeuds de la grappe et que files soit répertorié avant nis ou dns. Les exigences supplémentaires imposées par ce bogue sont de répertorier [SUCCESS=return] après files et de répertorier toutes les adresses IP privées de la grappe dans le fichier /etc/inet/hosts.

Bogue nº 4526883

Récapitulatif du problème : Rarement, il se peut que le chemin de transport d'interconnexion privée se terminant à un adaptateur qfe ne fonctionne pas correctement.

Solution : Procédez comme suit.

Identifiez l'adaptateur défectueux.

La commande Scstat -W doit normalement afficher tous les chemins de transport de cet adaptateur, en tant que points terminaux du chemin en état "faulted" ou "waiting".

Utilisez la commande scsetup(1M) pour supprimer de la configuration de la grappe tous les câbles connectés à cet adaptateur.

Utilisez à nouveau la commande scsetup pour supprimer cet adaptateur de la configuration de la grappe.

Ajoutez ensuite l'adaptateur et les câbles à la configuration de la grappe.

Vérifiez que le problème est bien résolu grâce aux étapes effectuées et que les chemins peuvent désormais revenir.

Si la suppression, puis l'ajout des câbles et de l'adaptateur ne fonctionnent pas, répétez la procédure à plusieurs reprises. Si le problème n'est toujours pas résolu, réinitialisez le noeud ayant l'adaptateur défectueux. Il est probable que le problème disparaîtra lors de l'initialisation du noeud. Avant de réinitialiser le noeud, assurez-vous que le reste de la grappe a suffisamment de votes de quorum pour résister à la réinitialisation du noeud.

Bogue nº 4620185

Récapitulatif du problème : Si le démon rpc.pmfd surveille un processus qui scinde un nouveau processus en raison du traitement d'un signal, l'utilisation de pmfadm -k tag signal peut entraîner l'apparition d'une boucle infinie. Ceci peut se produire car la commande pmfadm(1M) tente d'éliminer tous les processus dans l'arborescence de la balise tandis que les processus nouvellement scindés sont ajoutés à l'arborescence (chacun étant ajouté à la suite de l'élimination du précédent).

Remarque :

Ce bogue n'apparaît normalement pas avec pmfadm -s tag signal.

Solution : Utilisez la commande pmfadm -s tag signal au lieu de pmfadm -k. L'option -s de la commande pmfadm n'a pas la même condition que l'option -k.

Bogue nº 4629536

Récapitulatif du problème : L'utilisation simultanée de l'option de montage forcedirectio et de la fonction mmap(2) peut provoquer la corruption des données, ce qui entraîne l'arrêt ou la panique du système.

Solution : Respectez les restrictions suivantes.

Ne remontez jamais un système de fichiers avec l'option de montage directio ajoutée au temps de remontage.
Ne paramétrez pas l'option de montage directio sur un seul fichier au moyen de l'ioctl directio.

Si vous devez utiliser directio, montez l'ensemble du système de fichiers avec les options directio.

Bogue nº 4634409

Récapitulatif du problème : Si vous essayez de monter le même périphérique sur différents points de monatge, le système capte la plupart du temps cette erreur et provoque l'échec du second montage. Néanmoins, il arrive parfois, dans de très rares circonstances, que le système ne puisse pas capter cette erreur, et qu'il permette donc aux deux montages de s'effectuer. C'est uniquement le cas lorsque les quatre conditions suivantes sont vérifiées.

Les deux montages ont lieu simultanément
Un seul et même périphérique est concerné par ces montages
Le périphérique est monté sur deux points de monatge différents
L'un des points de montage est global, l'autre est local.

Solution : L'administrateur système doit être attentif lors du montage des systèmes de fichiers sur la grappe.

Bogue nº 4638586

Récapitulatif du problème : Il se peut que la commande scconf(1M) ne réminorise pas les groupes de disques VxVM dans certains cas et affiche un message d'erreur disant que le périphérique est déjà utilisé dans un autre groupe de périphériques.

Solution : Effectuez les tâches suivantes pour attribuer un nouveau code mineur au groupe de disques.

Cherchez les codes mineurs déjà utilisés.

Observez les codes mineurs utilisés avec le code majeur répertorié dans la sortie suivante.

% ls -l /dev/vx/rdsk/*/*
 
crw-------   1 root     root     210,107000 Mar 11 18:18 /dev/vx/rdsk/fix/vol-01
crw-------   1 root     root     210,88000 Mar 15 16:31 /dev/vx/rdsk/iidg/vol-01
crw-------   1 root     root     210,88001 Mar 15 16:32 /dev/vx/rdsk/iidg/vol-02
crw-------   1 root     root     210,88002 Mar 15 16:33 /dev/vx/rdsk/iidg/vol-03
crw-------   1 root     root     210,88003 Mar 15 16:49 /dev/vx/rdsk/iidg/vol-04
crw-------   1 root     root     210,13000 Mar 18 16:09 /dev/vx/rdsk/sndrdg/vol-01
crw-------   1 root     root     210,13001 Mar 18 16:08 /dev/vx/rdsk/sndrdg/vol-02

Choisissez n'importe quel multiple de 1000 non utilisé comme code mineur de base pour le nouveau groupe de disques.

Attribuez le code mineur non encore utilisé au groupe de disques en état de dysfonctionnement.

Utilisez l'option de réminorisation de la commande vxdg.

Essayez à nouveau la commande scconf qui avait échoué.

Bogue nº 4644289

Récapitulatif du problème : Sur Solaris 9, la méthode d'arrêt du service de données Sun Cluster HA for Oracle peut temporiser en cas de panne du réseau public, si aucun service externe d'attribution de noms n'est disponible. Le service de données Sun Cluster HA for Oracle emploie la commande utilisateur su(1M) pour démarrer et arrêter la base de données.

Solution : Sur chaque noeud pouvant être primaire pour la ressource oracle_server ou oracle_listener, modifiez le fichier /etc/nsswitch.conf afin d'inclure les entrées suivantes pour les bases de données passwd, group, publickey et project.

passwd:       files
group:        files
publickey:    files
project:      files

Ces modifications garantissent que la commande su(1M) ne réfèrera pas aux services d'attribution de noms NIS/NIS+, et garantit que le service d'attribuion de noms démarre et s'arrête correctement en cas de panne du réseau public.

Bogue nº 4648767

Récapitulatif du problème : L'utilisation de sendfile(3EXT) provoque la panique du noeud.

Solution : Il n'existe aucune solution à ce problème, hormis l'utilisation de sendfile.

Bogue nº 4651392

Récapitulatif du problème : Sur Solaris 9, un noeud de grappe en cours de fermeture est susceptible de paniquer et d'afficher le message suivant en cours de fermeture.

CMM: Shutdown timer expired. Halting

Solution : Il n'existe pas de solution à ce problème. La panique du noeud n'a pas d'autre effet secondaire et peut être considérée comme relativement bénigne.

Bogue nº 4653151

Récapitulatif du problème : La création d'une ressource HAStoragePlus échoue si l'ordre des points de montage du système de fichiers spécifié dans la propriété d'extension FilesystemMountPoints n'est pas le même que l'ordre indiqué dans le fichier /etc/vfstab.

Solution : Assurez-vous que la liste des points de montage spécifiée dans la propriété d'extension FilesystemMountPoints correspond à la séquence indiquée dans le fichier /etc/vfstab. Par exemple, si le fichier /etc/vfstab spécifie les entrées du système de fichiers dans la séquence /a, /b, et /c, la séquence FilesystemMountPoints peut être "/a,/b,/c" ou "/a,/b" ou encore "/a,/c" mais pas "/a,/c,/b."

Bogue nº 4653788

Récapitulatif du problème : La propriété d'extension Failover_enabled paramétrée sur FALSE est censée empêcher le moniteur de la ressource de lancer une reprise sur panne du groupe de ressources.

Néanmoins, si le moniteur essaie de redémarrer une ressource, et que la méthode START ou STOP échoue ou temporise, le moniteur essaie de transférer, quel que soit le paramétrage de Failover_enabled.

Solution : Il n'existe aucune solution à ce problème.

Bogue nº 4655194

Récapitulatif du problème : Les groupes de périphériques basés sur partition logicielle Solstice DiskSuite sur un VxFS monté localement sont susceptibles de provoquer des erreurs si les commandes de commutation du groupe de périphériques (scswitch -D device-group) sont exécutées.

Solstice DiskSuite effectue en interne des opérations de resynchronisation miroir qui peuvent prendre un certain temps. Les resynchronisations miroir diminuent la redondance. VxFS rapporte des erreurs pour cette jonction et provoque des pannes E/S moniteur/application, ce qui entraîne le redémarrage de l'application.

Solution : Pour tout groupe de périphériques Solstice DiskSuite configuré avec HAStoragePlus, ne basculez pas manuellement le groupe de périphériques. En revanche, basculez le groupe de ressources, ce qui entraînera alors la bascule correcte des périphériques.

Vous pouvez également configurer les systèmes de fichiers VxFS montés localement sur les groupes de disques VxVM.

Bogue nº 4656367

Récapitulatif du problème : Certains messages d'erreur n'ont pas été repris dans le CD-ROM Sun Cluster 3.0 5/02.

Solution : Vous trouverez l'explication de ces messages d'erreur dans "Nouveaux messages d'erreur".

Bogue nº 4656391

Récapitulatif du problème : La commande fsck(1M) d'un système de fichiers résidant sur un groupe de périphériques Sun Cluster global Solstice DiskSuite/VxVM échoue s'il est executé à partir d'un noeud non primaire (secondaire). Nous avons constaté ce problème sur Solaris 9, mais il se peut que les versions antérieures n'aient pas ce comportement.

Solution : Invoquez uniquement la commande fsck sur le noeud primaire.

Bogue nº 4656531

Récapitulatif du problème : Une ressource écouteur de Sun Cluster HA for Oracle ne se comporte pas correctement si plusieurs ressources écouteur sont configurées pour lancer les écouteurs avec le même nom d'écouteur.

Solution : N'utilisez pas le même nom d'écouteur pour les différents écouteurs d'une même grappe.

Bogue nº 4657088

Récapitulatif du problème : La dissociation/séparation d'un plex d'un groupe de disques VxVM sous Sun Cluster 3.0 peut provoquer la panique du noeud de la grappe avec la chaîne de panique suivante :

  panic[cpu2]/thread=30002901460: BAD TRAP: type=31 rp=2a101b1d200 addr=40
  mmu_fsr=0 occurred in module "vxfs" due to a NULL pointer dereference

Solution : Avant de dissocier/séparer un plex, démontez le système de fichiers correspondant.

Bogue nº 4657833

Récapitulatif du problème : La reprise sur panne ne se produit pas lorsque la propriété du groupe de ressources auto_start_on_new_cluster est configurée sur false.

Solution : A chaque réinitialisation de l'ensemble de la grappe, pour les groupes de ressources ayant la propriété auto_start_on_new_cluster configurée sur false, paramétrez la propriété auto_start_on_new_cluster sur true, puis reconfigurez la propriété auto_start_on_new_cluster sur false.

# scrgadm -c -g rgname -y auto_start_on_new_cluster=true
# scrgadm -c -g rgname -y auto_start_on_new_cluster=false

Bogue nº 4659042

Récapitulatif du problème : Pour les systèmes de fichiers VxFS montés globalement, le fichier /etc/mnttab est susceptible de ne pas afficher l'option globale.

Solution : Si une entrée /etc/mnttab est détectée sur tous les noeuds de la grappe pour le système de fichiers concerné, cela signifie que le système de fichiers est monté globalement.

Bogue nº 4659091

Récapitulatif du problème : Lors du remontage d'un système de fichiers monté globalement, /etc/mnttab n'est pas mis à jour.

Solution : Il n'y a pas de solution pour l'instant.

Bogue nº 4660479

Récapitulatif du problème : En cas d'utilisation de Sun Cluster HA for NFS avec HAStoragePlus, les verrouillages de blocage ne sont pas récupérés durant les reprises sur panne et les bascules. En conséquence, lockd ne peut pas être relancé par Sun Cluster HA for NFS, ce qui provoque l'échec de la méthode nfs_postnet_stop, avec pour résultat le blocage du noeud de la grappe.

Solution : N'utilisez pas Sun Cluster HA for NFS sur HAStoragePlus. Les systèmes de fichier de grappe ne rencontrent pas ce problème, et vous pouvez donc configurer Sun Cluster HA for NFS sur un système de fichiers de grappe pour éviter cette difficulté.

Bogue nº 4660521

Récapitulatif du problème : Lors de l'élimination d'un serveur HTTP sur un noeud, un fichier PID reste sur le noeud. Lors du lancement suivant du serveur HTTP, il y a une vérification de l'existence du fichier PID et d'un processus éventuellement en cours avec le fichier PID (kill -0). Comme les PID sont recyclés, il se peut qu'il y ait un autre processus avec le même PID que celui du dernier serveur HTTP. Dans ce cas, le lancement du serveur HTTP échoue.

Solution : Si le serveur HTTP ne démarre pas avec un message d'erreur semblable à celui ci-dessous, supprimez manuellement le fichier PID du serveur HTTP afin de redémarrer correctement.

Mar 27 17:47:58 ppups4 uxwdog[939]: could not log PID to PidLog
/app/iws/https-schost-5.example.com/logs/pid, server already running
(No such file or directory)

Bogue nº 4662264

Récapitulatif du problème : Afin d'éviter de provquer une panique lors de l'utilisation des produits VERITAS comme VxFS avec le logiciel Sun Cluster, il faut augmenter la taille d'empilement des threads par défaut.

Solution : Augmentez cette taille en introduisant les lignes suivantes dans le fichier /etc/system.

set lwp_default_stksize=0x6000
set svc_default_stksize 0x8000

L'entrée svc_default_stksize est indispensable pour les opérations NFS.

Après l'installation des modules VERITAS, vérifiez que VERITAS n'a pas ajouté de lignes similaires dans le fichier /etc/system. Si tel est le cas, il faut les ramener à un argument au moyen de la valeur la plus élevée.

Bogue nº 4663876

Récapitulatif du problème : Dans un groupe de périphériques comprenant plus de deux éléments avec une liste de noeuds ordonnée, si le noeud à supprimer n'est pas le dernier de la liste, la commande scconf affiche des informations partielles sur la liste de noeuds.

Solution :

Pour éviter que l'utilisateur ne rencontre ce problème, supprimez les noeuds un par un, en commençant par le dernier de la liste, jusqu'à la suppression du noeud souhaité. Ensuite, rajoutez les noeuds supprimés au groupe de périphériques.
Pour réparer l'état de la grappe lorsque vous rencontrez ce problème, procédez comme suit :
1. Arrêtez tous les périphériques (systèmes de fichiers, services de données) au moyen du groupe de périphériques.
2. Désenregistrez (supprimez) le groupe de périphériques de la mémoire de la grappe au moyen de scsetup(1m). Remarque : Veillez à laisser intact l'objet même du groupe de périphériques.
3. Réenregistrez le groupe de périphériques (comme s'il s'agissait d'un nouveau groupe) au moyen de scsetup(1m), en ajoutant la liste correcte des noeuds.
Lors du rajout dans le groupe de périphériques du noeud précédemment supprimé, donnez de façon explicite une liste ordonnée de l'ensemble des noeuds valides inclus.

Bogue nº 4664510

Récapitulatif du problème : Après l'arrêt de l'un des Sun StorEdge T3 Array et de l'exécution de scshutdown, la réinitialisation des deux noeuds place la grappe dans un état de non fonctionnement.

Solution : En cas de perte de la moitié des répliques, procédez comme suit :

Assurez-vous que la grappe est en mode grappe.

Importez obligatoirement l'ensemble de disques.
# metaset -s nom_ensemble -f -C take

Supprimez les répliques endommagées.

# metadb -s nom_ensemble -fd /dev/did/dsk/dNsX

Libérez l'ensemble de disques.
# metaset -s nom_ensemble -C release
Vous pouvez à présent monter et utiliser le système de fichiers. Néanmoins, vous n'avez pas restauré la redondance dans les répliques. En cas de perte de la seconde moitié des répliques, vous ne pourrez pas restaurer le miroir dans un état de bon fonctionnement.

Recréez les bases de données après l'application de la procédure de réparation décrite ci-dessus.