Les problèmes et bogues présentés ci-après concernent la version Sun Cluster 3.2. Les bogues et problèmes sont regroupés dans les catégories suivantes :
Problème : la commande -clnode remove --force devrait supprimer les nœuds des metasets. Le Sun Cluster System Administration Guide for Solaris OS contient les procédures à suivre pour supprimer un nœud du cluster. Elles indiquent à l'utilisateur qu'il doit exécuter la commande metaset sur le groupe de disques Solaris Volume Manager avant d'exécuter la commande clnode remove.
Solution : si les procédures n'ont pas été suivies, il peut être nécessaire d'effacer les données de nœud périmées du CCR d'une façon habituelle. Dans un nœud de cluster actif, utilisez la commande metaset pour effacer ce nœud des groupes de disques Solaris Volume Manager, puis exécutez clnode clear --force obsolete_nodename.
Problème : sur un cluster installé avec le groupe de logiciels Solaris 10 pour utilisateurs finaux, SUNWCuser, l'exécution de la commande scsnapshot risque d'échouer en indiquant l'erreur suivante :
# scsnapshot -o … /usr/cluster/bin/scsnapshot[228]: /usr/perl5/5.6.1/bin/perl: not found |
Solution : exécutez l'une des procédures suivantes :
Installez le groupe de logiciels Solaris Entire Distribution.
Installez les packages Perl suivants : SUNWpl5u, SUNWpl5v et SUNWpl5p.
Problème : la propriété Auxnodelist de la ressource à adresse partagée ne peut pas être utilisée lors de la création de cette ressource. Cela provoque des erreurs de validation et des erreurs SEGV lors de la création de la ressource évolutive qui dépend de cette ressource réseau à adresse partagée. Le message d'erreur de validation de la ressource évolutive est au format suivant :
Method methodname (scalable svc) on resource resourcename stopped or terminated due to receipt of signal 11 |
Ce fichier core est généré à partir de ssm_wrapper. Les utilisateurs ne peuvent pas définir la propriété Auxnodelist et sont donc dans l'impossibilité d'identifier les nœuds du cluster pouvant héberger l'adresse partagée, mais ne pouvant jamais servir de nœuds principaux.
Solution : sur un nœud, recréez la ressource à adresse partagée sans spécifier la propriété Auxnodelist, puis réexécutez la commande de création de ressources évolutives et utilisez la ressource à adresse partagée que vous avez recréée en tant que ressource réseau.
Problème : la commande du logiciel Quorum Server, clquorumserver, ne définit pas correctement l'état du mécanisme du prochain démarrage.
Solution : exécutez les tâches suivantes pour lancer ou arrêter le logiciel Quorum Server.
Affichez le statut du service quorumserver.
# svcs -a | grep quorumserver |
Si le service est désactivé, la sortie est semblable à ce qui suit :
disabled 3:33:45 svc:/system/cluster/quorumserver:default |
Démarrez le logiciel Quorum Server.
Si le service quorumserver est disabled, utilisez la commande svcadm enable.
# svcadm enable svc:/system/cluster/quorumserver:default |
Si le service quorumserver est online, utilisez la commande clquorumserver.
# clquorumserver start + |
Désactivez le service quorumserver.
# svcadm disable svc:/system/cluster/quorumserver:default |
Démarrez le logiciel Quorum Server.
# clquorumserver start + |
Attribuez au fichier /etc/rc2.d/.S99quorumserver le nouveau nom /etc/rc2.d/S99quorumserver.
# mv /etc/rc2.d/.S99quorumserver /etc/rc2.d/S99quorumserver |
Arrêtez le logiciel Quorum Server.
# clquorumserver stop + |
Démarrez le logiciel Quorum Server.
# mv /etc/rc2.d/S99quorumserver /etc/rc2.d/.S99quorumserver |
Problème : lors de la création de la ressource d'agent du nœud (NA) dans Sun Cluster HA pour Application Server, la ressource est créée même s'il n'y a pas de dépendance définie sur la ressource DAS. La commande devrait retourner une erreur si la dépendance n'est pas définie, car une ressource DAS doit être en ligne pour pouvoir lancer la ressource NA.
Solution : lors de la création de la ressource NA, vérifiez que vous définissez une dépendance de ressource sur la ressource DAS.
Problème : le patch HA MySQL ajoute une nouvelle variable appelée MYSQL_DATADIR au fichier mysql_config. Cette nouvelle variable doit pointer sur le répertoire dans lequel le fichier de configuration de MySQL my.conf est enregistré. Si cette variable n'est pas configurée correctement, la préparation de la base de données avec mysql_register échouera.
Solution : pointez la variable MYSQL_DATADIR sur le répertoire dans lequel le fichier de configuration de MySQL, my.conf, est enregistré.
Problème : si InfiniBand est utilisé pour le transport intracluster et qu'il existe deux adaptateurs sur chaque nœud, avec deux ports par adaptateur pour un total de deux commutateurs, la détection automatique de l'adaptateur de l'utilitaire scinstall peut suggérer deux chemins de transport utilisant le même adaptateur.
Solution : spécifiez manuellement les adaptateurs de transport sur chaque nœud.
Problème : la connexion IPv6 aux interconnexions qui est requise pour transférer les paquets de services évolutifs IPv6 n'est plus activée par défaut. Les interfaces IPv6, telles qu'elles sont vues lors de l'utilisation de la commande ifconfig, ne sont plus connectées aux adaptateurs d'interconnexion par défaut.
Solution : activez manuellement la prise en charge du service évolutif IPv6.
Vérifiez que vous avez préparé tous les nœuds du cluster pour exécuter les services IPv6. Ces tâches incluent la configuration appropriée des interfaces réseau, des applications logicielles serveur/clientes, des services de noms et de l'infrastructure de routage. Le non-respect de ces procédures risque d'entraîner des échecs inattendus des applications réseau. Pour plus d'informations, reportez-vous à la documentation relative à l'administration du système Solaris pour les services IPv6.
Sur chaque nœud, ajoutez l'entrée suivante dans le fichier /etc/system.
set cl_comm:ifk_disable_v6=0 |
Sur chaque nœud, activez la connexion IPv6 sur les adaptateurs d'interconnexion.
# /usr/cluster/lib/sc/config_ipv6 |
L'utilitaire config_ipv6 affiche une interface IPv6 sur tous les adaptateurs d'interconnexion du cluster pourvus d'une adresse de lien. Cet utilitaire active le transfert approprié des paquets de services évolutifs IPv6 via les interconnexions.
Vous pouvez également redémarrer chaque nœud du cluster pour activer le changement de configuration.
Problème : si un fichier XML utilisant le transport par connexion directe tente d'exécuter la commande clnode add, celle-ci commet une erreur d'interprétation des informations de câble et ajoute les mauvaises informations de configuration. En conséquence, le nœud de jonction ne peut pas rejoindre le cluster.
Solution : utilisez la commande scinstall pour ajouter un nœud au cluster lorsque le transport intracluster est directement connecté.
Problème : la commande scinstall met à jour le fichier /etc/nsswitch.conf pour ajouter l'entrée cluster correspondant aux bases de données hosts et netmasks. Cette modification met à jour le fichier /net/nsswitch.conf pour la zone globale, mais lorsqu'une zone non globale est créée et installée, elle reçoit sa propre copie du fichier /etc/nsswitch.conf. Les fichiers /etc/nsswitch.conf des zones non globales ne posséderont pas l'entrée cluster correspondant aux bases de données hosts et netmasks. Toute tentative de résolution des noms d'hôte privés propres au cluster et des adresses IP à partir d'une zone non globale effectuée à l'aide des requêtes getXbyY échoue.
Solution : mettez à jour le fichier /etc/nsswitch.conf manuellement pour les zones non globales avec l'entrée cluster correspondant aux bases de données hosts et netmasks. Cette procédure garantit la disponibilité des résolutions de noms d'hôte privés propres au cluster et des adresses IP dans les zones non globales.
Problème : les messages traduits pour les programmes d'administration Quorum Server, par exemple clquorumserver, sont distribués dans les principaux packages traduits. Les messages de Quorum Server ne s'affichent donc qu'en anglais. Les packages traduits de Quorum Server doivent être séparés des principaux packages traduits et installés sur le système serveur de quorum.
Solution : installez les packages suivants sur l'hôte sur lequel Quorum Server est installé :
SUNWcsc (chinois simplifié)
SUNWdsc (allemand)
SUNWesc (espagnol)
SUNWfsc (français)
SUNWhsc (chinois traditionnel)
SUNWjsc (japonais)
SUNWksc (coréen)
Si la page de manuel en japonais est nécessaire dans Quorum Server, installez le package SUNWjscman (page de manuel en japonais).
Problème : le programme d'installation de Sun Cluster 3.2 affiche un message d'avertissement relatif au fichier swap court lors de l'installation de la version en chinois simplifié de Sun Cluster 3.2. Ce programme indique une taille de fichier swap incorrecte (0 Ko) dans l'écran de vérification de la configuration requise.
Solution : si la taille du fichier swap est supérieure à la configuration requise, vous pouvez ignorer ce problème en toute sécurité. Le programme d'installation SC 3.2 dans l'environnement linguistique C ou anglais peut être utilisé pour l'installation, et cette version vérifie correctement la taille du fichier swap.
Problème : le binaire cleanipc échoue si l'environnement de liaison d'exécution ne contient pas le chemin /sapmnt/SAPSID/exe.
Solution : en tant qu'utilisateur root Solaris, ajoutez le chemin d'accès /sapmnt/SAPSID/exe à la bibliothèque par défaut dans le fichier ld.config.
Pour configurer le chemin d'accès à la bibliothèque par défaut dans l'environnement de liaison d'exécution pour les applications 32–bits, entrez la commande suivante :
# crle -u -l /sapmnt/SAPSID/exe |
Pour configurer le chemin d'accès à la bibliothèque par défaut dans l'environnement de liaison d'exécution pour les applications 64–bits, entrez la commande suivante :
# crle -64 -u -l /sapmnt/SAPSID/exe |
Problème : si le cluster est arrêté, le démon UCMMD peut procéder à une reconfiguration sur un ou plusieurs nœuds si l'un des nœuds laisse le cluster légèrement devant le démon UCMMD. Si cela se produit, la commande rpc.md est arrêtée sur le nœud alors que le démon UCMMD essaie d'exécuter la procédure en retour. Lors de la procédure en retour, la commande metaclust obtient un délai d'attente RPC et quitte la procédure avec une erreur due au processus rpc.mdcommd manquant. Cette erreur contraint le démon UCMMD à abandonner le nœud, ce qui peut entraîner une grave erreur de nœud.
Solution : vous pouvez ignorer ce problème en toute sécurité. Lorsque le nœud initialise une sauvegarde, le logiciel Sun Cluster détecte cette condition et permet au démon UCMMD de démarrer en dépit du fait qu'une erreur s'est produite lors de la reconfiguration précédente.
Problème : la validation des ressources Sun Cluster n'accepte pas le nom d'hôte des groupes IPMP pour la propriété netiflist lors de la création de ressources de nom d'hôte logique ou d'adresse partagée.
Solution : utilisez le nom du nœud et non son ID lorsque vous spécifiez les noms des groupes IPMP lors de la création de ressources de nom d'hôte logique ou d'adresse partagée.
Problème : ce problème est observé si le disque d'origine est un disque racine encapsulé et qu'une mise à niveau en ligne est tentée de VxVM 3.5 sur SE Solaris 9 8/03 vers VxVM 5.0 sur SE Solaris 10 6/06. Le script vxlufinish échoue avec l'erreur suivante.
#./vslufinish -u 5.10 VERITAS Volume Manager VxVM 5.0 Live Upgrade finish on the Solairs release <5.10> Enter the name of the alternate root diskgroup: altrootdg ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory Killed ld.so.1: ugettxt: fatal: libvxscsi.so: open failed: No such file or directory ERROR:vxlufinish Failed: /altroot.5.10/usr/lib/vxvm/bin/vxencap -d -C 10176 -c -p 5555 -g -g altrootdg rootdisk=c0t1d0s2 Please install, if 5.0 or higher version of VxVM is not installed on alternate bootdisk. |
Solution : utilisez plutôt la mise à niveau standard ou la mise à niveau sur deux partitions.
Contactez le support technique Sun ou votre représentant Sun pour savoir si la prise en charge de Sun Cluster 3.2 Live Upgrade sera bientôt disponible pour VxVM 5.0.
Problème : pendant une mise à niveau directe, les commandes lucreate et luupgrade ne permettent pas de modifier les noms DID dans l'autre environnement d'initialisation correspondant à l'entrée /global/.devices/node@N.
Solution : effectuez les étapes suivantes sur chaque nœud de cluster avant de lancer la mise à niveau directe.
Prenez le rôle de superutilisateur.
Sauvegardez le fichier /etc/vfstab.
# cp /etc/vfstab /etc/vfstab.old |
Ouvrez le fichier /etc/vfstab pour le modifier.
Recherchez la ligne correspondant à /global/.device/node@N.
Modifiez l'entrée de périphérique global.
Remplacez les noms DID par les noms physiques.
Remplacez /dev/did/{r}dsk/dYsZ par /dev/{r}dsk/cNtXdYs Z.
Supprimez global de l'entrée.
L'exemple suivant indique le nom d'un périphérique DID d3s3 correspondant à /global/.devices/node@s, remplacé par le nom de périphérique physique et dans lequel l'entrée global est supprimée :
Original: /dev/did/dsk/d3s3 /dev/did/rdsk/d3s3 /global/.devices/node@2 ufs 2 no global Changed: dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /global/.devices/node@2 ufs 2 no - |
Une fois le fichier /etc/vfstab modifié sur tous les nœuds de cluster, procédez à une mise à niveau directe du cluster mais arrêtez-la avant de réinitialiser à partir de l'autre environnement d'initialisation mis à niveau.
Sur chaque nœud, sur l'environnement d'initialisation en cours et non mis à niveau, restaurez le fichier /etc/vfstab d'origine.
# cp /etc/vstab.old /etc/vfstab |
Sur l'autre environnement d'initialisation, ouvrez le fichier /etc/vfstab pour le modifier.
Recherchez la ligne correspondant à /global/.devices/node@N et remplacez le tiret (-) à la fin de l'entrée par le mot global.
/dev/dsk/cNtXdYsZ /dev/rdsk/cNtXdYsZ /global/.devices/node@N ufs 2 no global |
Réinitialisez le nœud à partir de l'autre environnement d'initialisation mis à niveau.
Les noms DID sont remplacés automatiquement dans le fichier /etc/vfstab.
Problème : ce problème est observé lors de la mise à niveau de VERITAS Volume Manager (VxVM) pendant une mise à niveau en ligne de Sun Cluster. Le script vxlustart permet de mettre à niveau SE Solaris et VxVM à partir de la version précédente. Le script échoue et renvoie les messages d'erreur semblables aux suivants :
# ./vxlustart -u 5.10 -d c0t1d0 -s OSimage VERITAS Volume Manager VxVM 5.0. Live Upgrade is now upgrading from 5.9 to <5.10> … ERROR: Unable to copy file systems from boot environment <sorce.8876> to BE <dest.8876>. ERROR: Unable to populate file systems on boot environment <dest.8876>. ERROR: Cannot make file systems for boot environment <dest.8876>. ERROR: vxlustart: Failed: lucreate -c sorce.8876 -C /dev/dsk/c0t0d0s2 -m -:/dev/dsk/c0t1d0s1:swap -m /:/dev/dsk/c0t1d0s0:ufs -m /globaldevices:/dev/dsk/c0t1d0s3:ufs -m /mc_metadb:/dev/dsk/c0t1d0s7:ufs -m /space:/dev/dsk/c0t1d0s4:ufs -n dest.8876 |
Solution : utilisez la mise à niveau standard ou la mise à niveau sur deux partitions si vous mettez à niveau le cluster vers VxVM 5.0.
Contactez le support technique Sun ou votre représentant Sun pour savoir si la prise en charge de Sun Cluster 3.2 Live Upgrade sera bientôt disponible pour VxVM 5.0.
Problème : pour les clusters exécutant VERITAS Volume Manager (VxVM), une mise à niveau standard ou une mise à niveau sur deux partitions de l'un des logiciels suivants échoue si le disque racine est encapsulé :
Mise à niveau de SE Solaris vers une version différente
Mise à niveau de VxVM
Mise à niveau du logiciel Sun Cluster
De graves erreurs de nœuds se produisent et le nœud ne peut pas démarrer après la mise à niveau. Cela est dû aux changements des numéros majeurs ou mineurs apportés par VxVM lors de la mise à niveau.
Solution : désencapsulez le disque racine avant de commencer la mise à niveau.
Si la procédure décrite ci-dessus n'est pas suivie correctement, vous pouvez connaître de sérieux problèmes inattendus sur tous les nœuds en cours de mise à niveau. La désencapsulation et l'encapsulation du disque racine entraînent également un redémarrage automatique supplémentaire (chaque fois) du nœud, augmentant le nombre des redémarrages requis lors de la mise à niveau.
Problème : après une mise à niveau directe de Sun Cluster version 3.1 sur Solaris 9 à la version 3.2 sur Solaris 10, des zones ne peuvent pas être utilisées avec le logiciel du cluster. Le problème réside dans le fait que les données pspool ne sont pas créées pour les packages Sun Cluster. Les packages qui doivent être distribués aux zones non globales, comme SUNWsczu, ne sont pas distribués correctement.
Solution : après la mise à niveau des packages Sun Cluster à l'aide de la commande scinstall -R et avant l'initialisation du cluster en mode cluster, exécutez le script suivant deux fois :
une fois pour les packages de structure Sun Cluster ;
une fois pour les packages de service de données Sun Cluster.
Préparez et exécutez ce script de l'une des manières suivantes :
Définissez les variables des packages de structure Sun Cluster et exécutez le script. Modifiez ensuite la variable PATHNAME des packages de service de données et réexécutez le script.
Créez deux scripts, un contenant des variables définies dans le script des packages de structure et un contenant des variables définies pour les packages de service de données. Exécutez ensuite les deux scripts.
Prenez le rôle de superutilisateur.
Créez un script avec le contenu ci-dessous.
#!/bin/ksh typeset PLATFORM=${PLATFORM:-`uname -p`} typeset PATHNAME=${PATHNAME:-/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages} typeset BASEDIR=${BASEDIR:-/} cd $PATHNAME for i in * do if pkginfo -R ${BASEDIR} $i >/dev/null 2>&1 then mkdir -p ${BASEDIR}/var/sadm/pkg/$i/save/pspool pkgadd -d . -R ${BASEDIR} -s ${BASEDIR}/var/sadm/pkg/$i/save/pspool $i fi done
Définissez les variables PLATFORM, PATHNAME et BASEDIR.
Définissez ces variables en tant que variables d'environnement ou modifiez les valeurs directement dans le script.
Nom de la plate-forme. Par exemple, sparc ou x86. Par défaut, la variable PLATFORM est définie sur le résultat de la commande uname -p.
Chemin d'accès au périphérique à partir duquel les packages de structure ou de service de données Sun Cluster peuvent être installés. Cette valeur correspond à l'option -d de la commande pkgadd.
Par exemple, pour des packages de structure Sun Cluster, cette valeur pourrait se présenter comme suit :
/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages |
Pour les packages de service de données, cette valeur pourrait se présenter comme suit :
/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster_agents/Solaris_10/Packages |
Chemin d'accès complet à un répertoire à utiliser en tant que chemin d'accès racine et qui correspond à l'option -R de la commande pkgadd. Pour une mise à niveau directe, définissez cette valeur sur le chemin d'accès racine utilisé avec l'option -R de la commande scinstall. Par défaut, la variable BASEDIR est définie sur le système de fichiers racine (/).
Exécutez le script, une fois pour les packages de structure Sun Cluster et une fois pour les packages de service de données.
Une fois le script exécuté, le message suivant doit s'afficher à l'invite de commande de chaque package :
Transferring pkgname package instance |
Si le répertoire pspool existe déjà pour un package ou si le script est exécuté deux fois pour le même ensemble de packages, l'erreur suivante s'affiche à l'invite de commande :
Transferring pkgname package instance pkgadd: ERROR: unable to complete package transfer - identical version of pkgname already exists on destination device |
Ce message est sans conséquence et peut être ignoré.
Une fois le script exécuté pour les packages de structure et de service de données, initialisez les nœuds en mode cluster.
Problème : l'ajout d'un nouveau nœud de cluster sans s'assurer que celui-ci comporte les mêmes patchs que les nœuds de cluster existants peut entraîner un dysfonctionnement des nœuds de cluster.
Solution : avant d'ajouter un nœud au cluster, vérifiez qu'il dispose des patchs de même niveau que les nœuds de cluster existants. Sinon les nœuds de cluster peuvent connaître un dysfonctionnement.