test

Notes de version de Sun Cluster 3.1 10/03

Problèmes connus et bogues

Les problèmes et bogues présentés ci-après concernent la version Sun Cluster 3.1 10/03. Pour connaître les dernières informations, consultez le document Sun Cluster 3.1 10/03 Release Notes Supplement à l'adresse http://docs.sun.com.

État Largefile incorrect (4419214)

Récapitulatif du problème : le fichier /etc/mnttab n'indique pas l'état largefile actuel d'un système de fichiers VxFS monté globalement.

Solution : pour vérifier l'état largefile du système de fichier, utilisez la commande fsadm plutôt que l'entrée /etc/mnttab.

Noeuds incapables d'activer les chemins qfe (4526883)

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

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

  1. Identifiez l'adaptateur défectueux à l'aide de scstat -W. Le résultat affichera tous les chemins de transport avec cet adaptateur comme l'une des extrémités du chemin à l'état faulted ou waiting.

  2. Utilisez la commande scsetup pour supprimer de la configuration de cluster tous les câbles connectés à cet adaptateur.

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

  4. Replacez l'adaptateur et les câbles.

  5. Vérifiez que les chemins apparaissent. Si le problème persiste, répétez plusieurs fois les étapes 1 à 5.

  6. Vérifiez que les chemins apparaissent. Si le problème persiste toujours, réinitialisez le noeud où se trouve l'adaptateur défectueux. Avant de réinitialiser le noeud, assurez-vous que le reste du cluster a suffisamment de votes de quorum pour résister à la réinitialisation du noeud.

Blocs de fichiers non mis à jour après les opérations d'écritures sur les trous du fichier fragmenté (4607142)

Récapitulatif du problème : le nombre de blocs de fichiers n'est pas toujours consistant sur des noeuds de cluster après les opérations d'écriture d'allocation de blocs dans un fichier fragmenté. Pour un système de fichiers de cluster en couches sur UFS (ou VxFS 3.4), l'inconsistance du bloc sur plusieurs noeuds disparaît au bout de 30 secondes environ.

Solution : les opérations de métadonnée de fichier actualisant l'inode (touch, etc.) doivent synchroniser la valeur st_blocks afin que les opérations de métadonnée qui suivent assurent des valeurs st_blocks consistantes.

Démarrage et arrêt incorrects du service de données lors d'une panne de réseau (4644289)

Récapitulatif du problème : le service de données Sun Cluster HA pour Oracle démarre et arrête la base de données à l'aide de la commande su. Le service du réseau peut devenir indisponible lorsque le réseau public d'un noeud de cluster tombe en panne.

Solution : sous Solaris 9, configurez les fichiers /etc/nsswitch.conf comme indiqué ci-après, de sorte que le service de données démarre et s'arrête correctement en cas de panne du réseau.

Sur chaque noeud susceptible d'être principal pour la ressource oracle_server ou oracle_listener, modifiez le fichier /etc/nsswitch.conf en y incluant les entrées suivantes pour les bases de données passwd, group, publickey et project :

L'ajout de ces entrées garantit que la commande su(1M) ne se réfère pas aux services de noms NIS/NIS+.

Échec du démontage d'un système de fichiers (4656624)

Récapitulatif du problème : il arrive que le démontage d'un système de fichiers de cluster échoue, même si la commande fuser indique qu'il n'y a aucun utilisateur sur les noeuds.

Solution : relancez le remontage après que toutes les E/S asynchrones vers le système de fichiers sous-jacent ont été effectuées.

Échec de Sun Cluster HA–Siebel pour contrôler des composants Siebel (4722288)

Récapitulatif du problème : l'agent Sun Cluster HA-Siebel ne contrôle pas les composants Siebel individuels. En cas de détection d'une panne sur un composant Siebel, seul un message d'avertissement est consigné dans syslog.

Solution : redémarrez le groupe de ressources du serveur Siebel dans lequel les composants sont déconnectés à l'aide de la commande scswitch -R -h noeud -g groupe_ressources .

Indisponibilité des instances Oracle RAC sur les derniers noeuds ajoutés (4723575)

Récapitulatif du problème : l'installation du support Sun Cluster pour RAC sur un noeud récemment ajouté entraîne l'indisponibilité des instances Oracle RAC.

Solution : pour ajouter un noeud sur un cluster fonctionnant avec Oracle RAC sans perdre la disponibilité des bases de données Oracle RAC, une installation particulière est requise. L'exemple suivant indique comment passer d'un cluster à 3 noeuds à un cluster à 4 noeuds, Oracle RAC tournant sur les noeuds 1, 2 et 3 :

  1. Installez le logiciel Sun Cluster sur le nouveau noeud (noeud 4).

    Remarque : n'installez pas les packages de support RAC à ce moment.

  2. Réinitialisez le nouveau noeud dans le cluster.

  3. Une fois que le nouveau noeud a rejoint le cluster, fermez la base de données Oracle RAC sur un des noeuds où elle tourne déjà (le noeud 1, dans cet exemple).

  4. Réinitialisez le noeud où la base de données vient d'être arrêtée (noeud 1).

  5. Une fois que le noeud (noeud 1) est de nouveau actif, lancez la base de données Oracle sur ce noeud pour reprendre le service de base de données.

  6. Si un seul noeud est capable de gérer la charge de la base de données, arrêtez la base de données sur les noeuds restants (noeuds 2 et 3) et réinitialisez ces noeuds. Si plus d'un noeud est nécessaire pour supporter la charge de la base de données, traitez-les l'un après l'autre tel que décrit aux étapes 3 à 5.

  7. Une fois tous les noeuds réinitialisés, les packages de support Oracle RAC peuvent être installés sans problème sur le nouveau noeud.

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

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

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

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

Risque d'erreur grave au niveau des noeuds dû à l'utilisation de la commande Solaris shutdown (4745648)

Récapitulatif du problème : l'utilisation de la commande Solaris shutdown ou de commandes similaires (par exemple, uadmin) pour désactiver un noeud de cluster peut entraîner une erreur grave au niveau des noeuds, et l'affichage du message indiqué ci-dessous.

CMM: Shutdown timer expired. Halting.

Solution : demandez l'assistance de votre représentant Sun. Cette erreur grave est nécessaire, elle permet à un autre noeud de cluster de reprendre en toute sécurité les services qui étaient hébergés par le noeud désactivé.

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

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

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

Adresses IP de différents sous-réseaux empêchées de résider sur un centre d'information de réseau (NIC) par scrgadm (4751406)

Récapitulatif du problème : scrgadm empêche l'hébergement de noms d'hôtes logiques et d'adresses partagées appartenant à un autre sous-réseau que celui du groupe IPMP (NAFO).

Solution : utilisez la commande scrgadm sous la forme indiquée ci-dessous.

scrgadm -a -j <resource> -t <resource_type> -g <resource_group> -x HostnameList=<logical_hostname> -x NetIfList=<nafogroup>@<nodeid> .

Notez que les noms de noeuds ne semblent pas fonctionner dans la liste NetIf ; utilisez les id de noeuds à la place.

Erreur due à un échec de basculement (4766781)

Récapitulatif du problème : un échec de basculement ou de commutation d'un système de fichiers peut générer une erreur.

Solution : démontez puis remontez le système de fichiers.

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

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

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

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

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

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

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

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

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

Échec des séquences d'arrêt et de réinitialisation (4844784)

Récapitulatif du problème : lorsqu'un noeud est arrêté ou réinitialisé, il peut s'interrompre et donc suspendre la séquence d'arrêt ou de réinitialisation. Le système s'interrompt après génération du message suivant : Failfast: Halting because all userland daemons all have died.

Solution : avant d'arrêter ou de réinitialiser le noeud, exécutez la commande présentée ci-dessous. psradm -f -a :

Pour arrêter un noeud :

  1. # scswitch -S -h <node>

  2. # psradm -f -a

  3. # shutdown -g0 -y -i0

Pour réinitialiser un noeud :

  1. # scswitch -S -h <node>

  2. # psradm -f -a

  3. # shutdown -g0 -y -i6

Remarque :

dans certains cas rares, la solution proposée ne résout pas le problème.

Réinitialisation d'un noeud (4862321)

Récapitulatif du problème : sur les systèmes volumineux exécutant Sun Cluster 3.x, shutdown -g0 -y -i6, la commande de réinitialisation d'un noeud, peut mener le système sur l'invite OK avec le message Failfast: Halting because all userland daemons have died, au lieu de le réinitialiser.

Solution : recourez à l'une des solutions proposées ci-dessous.

N'oubliez pas de ré-activer failfasts après la réinitialisation du noeud :

# /usr/cluster/lib/sc/cmm_ctl -f

ou d'augmenter le délai d'expiration de failfast_panic_delay avant d'arrêter le système, à l'aide de la commande mdb suivante :

(echo 'cl_comm`conf+8/W 0t600000' ;

echo 'cl_comm`conf+c/W 0t600000') | mdb -kw

Elle permet de définir le délai d'exécution à 600000 ms (10 minutes).

Activité du processus GVR d'Oracle lors de l'arrêt d'un noeud (4891227)

Récapitulatif du problème : le processus GVR (gestionnaire de verrouillage réparti) d'Oracle ne se termine pas durant un arrêt et empêche le démontage de /var.

Solution : recourez à l'une des deux solutions proposées ci-dessous.

Risque de dépassement du délai imparti de la sonde d'attente d'Oracle sur un système à forte charge (4900140)

Récapitulatif du problème : la sonde d'attente d'Oracle risque de connaître un dépassement du délai imparti sur un système à forte charge, entraînant le redémarrage du dispositif d'attente d'Oracle.

Solution : sur les systèmes à forte charge, le dépassement du délai imparti de la sonde d'attente d'Oracle peut être évité en augmentant la valeur de la propriété Intervalle_sonde_complet de la ressource.

Le dépassement du délai imparti de la sonde est calculé comme suit :

10 secondes si Intervalle_sonde_complet est supérieur à 20 secondes.

60 secondes si Intervalle_sonde_complet est supérieur à 120 secondes.

Intervalle_sonde_complet/2 dans les autres cas.

Risque d'erreur grave d'un noeud après la mise à jour de la propriété système_GR d'un groupe de ressources (4902066)

Récapitulatif du problème : lorsqu'elle est définie sur VRAI, la propriété système_GR indique que le groupe de ressources et ses ressources sont utilisés pour le support de l'infrastructure du cluster, et non pour l'implémentation d'un service de données utilisateur. Si système_GR est définie sur VRAI, le gestionnaire du groupe de ressources empêche l'administrateur système de déconnecter le groupe ou ses ressources ou de modifier leurs propriétés par inadvertance. Il arrive que le noeud panique lorsque vous essayez de modifier la propriété du groupe de ressources après avoir défini système_GR sur VRAI.

Solution : ne modifiez pas la valeur de la propriété de groupe de ressources système_GR.

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

Récapitulatif du problème : sur chaque noeud pouvant contrôler la ressource liveCache, la commande su risque de s'interrompre lorsque le réseau public est arrêté.

Solution : sur chaque noeud susceptible de contrôler la ressource liveCache, il est recommandé de modifier le fichier /etc/nsswitch.conf comme indiqué ci-après, afin d'éviter l'interruption de la commande su lorsque le réseau public est arrêté.

passwd : files nis [TRYAGAIN=0]

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

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

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

Échec de l'installation en cas de non définition d'un domaine par défaut (4913925)

Récapitulatif du problème : lors de l'ajout de noeuds à un cluster, une erreur d'« authentification RPC » peut survenir au cours de l'installation ou de la configuration. Les messages d'erreur peuvent être les suivants :

Cette situation se produit lorsque les noeuds ne sont pas configurés pour l'utilisation de NIS/NIS+, en particulier en cas d'absence du fichier /etc/defaultdomain.

Solution : lorsqu'un nom de domaine n'est pas défini (c'est-à-dire qu'il manque le fichier /etc/defaultdomain), définissez-le sur tous les noeuds rejoignant le cluster, à l'aide de la commande domainname(1M) avant de poursuivre l'installation. Par exemple, # domainname xxx.