| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Notes de version d'Oracle Solaris Cluster 3.3 5/11 Oracle Solaris Cluster (Français) |
| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
|
Notes de version d'Oracle Solaris Cluster 3.3 5/11 Oracle Solaris Cluster (Français) |
Notes de version d'Oracle Solaris Cluster 3.3 5/11
Nouveautés du logiciel Oracle Solaris Cluster 3.3 5/11
Améliorations apportées à la commande cluster check en tant qu'outil de validation de cluster
Prise en charge de la séparation pour Sun ZFS Storage Appliance en tant que périphérique NAS
Prise en charge d'Oracle ACFS comme système de fichiers du cluster
Prise en charge par le cluster de zones des montages en loopback avec HAStoragePlus utilisant ZFS
Prise en charge par l'assistant de configuration d'Oracle 11g version 2 avec HA-Oracle et Oracle RAC
Prise en charge des clusters de zones sans adresse IP
Prise en charge de SWIFTAlliance Access 7.0 et SWIFTAlliance Gateway 7.0
Oracle ACFS en tant que système de fichiers d'un cluster
Abandon de la prise en charge de la fonction de cluster de Veritas Volume Manager
Commandes modifiées dans cette version
Modifications des noms de produits
Le n
ud ne parvient pas à démarrer Oracle Clusterware après une erreur grave (uadmin 5 1) (11828322)
Impossible de démarrer Oracle ACFS en présence d'Oracle ASM dans une zone non globale (11707611)
Interface graphique utilisateur Solaris Volume Manager
Système d'exploitation Oracle Solaris
Sun StorageTek Availability Suite
Échec de SPARC T3-4 d'Oracle lors du redémarrage (6993321)
Interruption du code de la propriété global_fencing si la valeur devient prefer3 (6879360)
La détection automatique ne fonctionne pas sur LDoms avec des E/S hybrides (6870171)
Exécution impossible de Solaris Cluster Manager dans un cluster à 16 nuds (6594485)
Apache Tomcat ne démarre pas en raison de l'absence d'un script (7022690)
Les applications évolutives ne sont pas isolées entre les clusters de zones (6911363)
Environnement de développement
GDS renvoie un état de sortie incorrect en méthode STOP pour les services non PMF (6831988)
Le résultat de la vérification de la configuration système requise est incorrect (6495984)
Échec de ssm_start en raison d'une défaillance d'un IPMP non associé (6938555)
Patchs et niveaux des microprogrammes requis
Application d'un patch de noyau Oracle Solaris Cluster 3.3 5/11
Application du patch de noyau Oracle Solaris Cluster 3.3 5/11
Suppression d'un patch de noyau Oracle Solaris Cluster 3.3 5/11
Procédure de suppression d'un patch de noyau Oracle Solaris Cluster 3.3 5/11
Patch de prise en charge de cluster pour baie de disques Sun StorageTek 2530
Les problèmes et bogues présentés ci-après affectent le fonctionnement d'Oracle Solaris Cluster 3.3 5/11. Les problèmes et les bogues sont regroupés dans les catégories suivantes :
Résumé du problème : si un service de données de basculement, tel que HA for Oracle, est configuré avec la ressource ScalMountpoint de façon à analyser et détecter les échecs d'accès au stockage NAS et que l'interface réseau est perdue, comme par exemple en cas de perte d'une connexion câblée, alors la sonde du moniteur se bloque. Si la propriété Failover_mode est définie sur SOFT, cela entraîne un état d'échec de l'arrêt et la ressource ne bascule pas. Le message d'erreur est identique au suivant :
SC[SUNW.ScalMountPoint:3,scalmnt-rg,scal-oradata-11g-rs,/usr/cluster/lib/rgm/rt/scal_mountpoint/scal_mountpoint_probe]: Probing thread for mountpoint /oradata/11g is hanging for timeout period 300 seconds
Solution : définissez la propriété Failover_mode de la ressource sur HARD.
# clresource set -p Failover_mode=HARD ora-server-rs # clresource show -v ora-server-rs | grep Failover_mode Failover_mode: HARD
Résumé du problème : l'implémentation actuelle requiert la présence d'un fichier RTR, plutôt qu'un lien symbolique vers le fichier, dans /usr/cluster/lib/rgm/rtreg.
Solution : exécutez les commandes suivantes en tant que superutilisateur sur un nœud du cluster global.
# cp /opt/SUNWscor/oracle_asm/etc/SUNW.scalable_acfs_proxy /usr/cluster/lib/rgm/rtreg/ # clrt register -Z zoneclustername SUNW.scalable_acfs_proxy # rm /usr/cluster/lib/rgm/rtreg/SUNW.scalable_acfs_proxy
Résumé du problème : lors d'un redémarrage, le serveur SPARC T3-4 d'Oracle à quatre processeurs ne parvient pas à se connecter à la structure d'Oracle Solaris Cluster. Des messages d'erreur semblables à ceux-ci s'affichent :
Sep 20 15:18:53 svc.startd [8]: svc:/system/pools:default: Method or service exit timed out. Killing contract 29. Sep 20 15:18:53 svc.startd [8]: svc:/system/pools:default: Method "/lib/svc/method/svc-pools start" failed due to signal KILL. … Sep 20 15:20:55 solta svc.startd [8]: system/pools:default failed: transitioned to maintenance (see 'svcs -xv' for details) … Sep 20 15:22:12 solta INITGCHB: Given up waiting for rgmd. … Sep 20 15:23:12 solta Cluster.GCHB_resd: GCHB system error: scha_cluster_open failed with 18 Sep 20 15:23:12 solta : No such process
Solution : utilisez la commande svccfg pour passer le délai d'attente du service à 300 secondes. Démarrez en mode non cluster et exécutez les commandes suivantes :
# svccfg -s svc:/system/pools setprop start/timeout_seconds = 300 # svcadm refresh svc:/system/pools
Une fois ces commandes exécutées, démarrez en mode cluster.
Résumé du problème : lorsque vous supprimez un nœud de cluster global qui constitue le dernier nœud dans le cluster global hébergeant un cluster de zones, le cluster de zones n'est pas supprimé de la configuration en cluster.
Solution : avant d'exécuter la commande clnode remove -F pour supprimer le nœud de cluster global, utilisez la commande clzonecluster pour supprimer le cluster de zones.
Résumé du problème : lorsqu'un nouveau périphérique de stockage est ajouté à un cluster et configuré avec trois chemins DID ou plus, le nœud sur lequel la commande cldevice populate est exécutée peut ne pas parvenir à enregistrer sa clé PGR sur le périphérique.
Solution : exécutez la commande cldevice populate sur tous les nœuds du cluster ou exécutez la commande cldevice populate à deux reprises à partir du même nœud.
Résumé du problème : Oracle Solaris Cluster tente de vérifier qu'un périphérique de stockage prend pleinement en charge SCSI-3 PGR avant d'autoriser l'utilisateur à définir sa propriété de séparation sur prefer3. Cette vérification peut réussir alors qu'elle devrait échouer.
Solution : assurez-vous que le périphérique de stockage est certifié par Oracle Solaris Cluster pour une utilisation avec SCSI-3 PGR avant de modifier les paramètres de séparation en prefer3.
Résumé du problème : au cours de la configuration du cluster sur LDoms avec les E/S hybrides, la détection automatique ne signale pas de chemins pour l'interconnexion de cluster.
Solution : lorsque vous exécutez l'utilitaire interactif scinstall, choisissez de configurer le nœud de cautionnement et les nœuds supplémentaires dans des opérations distinctes, plutôt qu'en configurant tous les nœuds lors d'une opération unique. Lorsque l'utilitaire affiche le message "Do you want to use autodiscovery?" (voulez-vous utiliser la détection automatique ?), répondez "no". Vous pouvez alors sélectionner les adaptateurs de transport à partir de la liste fournie par l'utilitaire scinstall.
Résumé du problème : si un groupe de périphériques Hitachi TrueCopy dont la paire de répliques se trouve à l'état COPY, ou un groupe de volumes EMC SRDF dont la paire de répliques est scindée, tente de commuter le groupe de périphériques sur un autre nœud, alors la commutation échoue. En outre, le groupe de périphériques ne parvient pas à revenir en ligne sur le nœud d'origine tant que la paire de répliques n'a pas retrouvé son propre état d'association.
Solution : vérifiez que les répliques TrueCopy ne se trouvent pas à l'état COPY, ou que les répliques SRDF ne sont pas scindées, avant d'essayer de commuter le groupe de périphériques global &ProductName associé sur un autre nœud de cluster.
Résumé du problème : vous ne pouvez pas utiliser l'utilitaire clsetup pour configurer une ressource de façon à ce qu'elle dispose de la règle d'équilibrage de charge LB_STICKY_WILD. À la place, la règle est définie sur LB_WILD.
Solution : une fois la ressource configurée, utilisez la commande clresource create pour modifier la règle d'équilibrage de charge en LB_STICKY_WILD.
Résumé du problème : le passage d'une configuration en cluster à trois nœuds à un cluster à deux nœuds peut entraîner la perte complète du cluster si l'un des nœuds restants quitte le cluster ou est supprimé de la configuration en cluster.
Solution : immédiatement après la suppression d'un nœud d'une configuration en cluster à trois nœuds, exécutez la commande cldevice clear sur l'un des nœuds restants du cluster.
Résumé du problème : si le logiciel Solaris Security Toolkit est configuré sur les nœuds du cluster, la commande scstat -i renvoie une erreur indiquant un échec de la liaison RPC. Le message d'erreur est identique au suivant :
scrconf: RPC: Rpcbind failure - RPC: Authentication error Other Sun Cluster commands that use RPC, such as clsnmpuser, might also fail.
Solution : ajoutez au fichier /etc/hosts.allow les noms d'hôte privés du cluster ou les adresses IP qui leur sont associées.
Résumé du problème : les commandes scdidadm et cldevice ne peuvent pas vérifier que les périphériques SRDF répliqués, et en cours de regroupement en un seul périphérique DID, sont en fait des répliques et appartiennent au groupe de réplication spécifié.
Solution : soyez très prudent lorsque vous regroupez des périphériques DID à utiliser avec SRDF. Assurez-vous que les instances de périphériques DID spécifiées sont bien des répliques et qu'elles appartiennent au groupe de réplication spécifié.
Résumé du problème : l'interface graphique Oracle Solaris Cluster Manager est inutilisable avec un cluster à 16 nœuds.
Solution : utilisez l'utilitaire clsetup ou les commandes de maintenance d'Oracle Solaris Cluster.
Résumé du problème : si des groupes de ressources sont créés, modifiés ou supprimés immédiatement après la réinitialisation d'un cluster de zones, le gestionnaire de groupes de ressources (RGM) passe dans un état d'incohérence dans lequel les opérations liées aux groupes de ressources peuvent échouer. Dans le pire des cas, l'échec peut entraîner une erreur grave des nœuds du cluster global et leur réinitialisation.
Ce problème peut se produire après la réinitialisation simultanée de tous les nœuds du cluster de zones. Le problème ne se produit pas si seuls certains des nœuds sont réinitialisés tandis que d'autres demeurent actifs. Il peut également se produire lorsque l'intégralité du cluster physique est redémarrée, si les mises à jour de groupes de ressources sont exécutées immédiatement après le démarrage du cluster de zones.
Ci-dessous, les commandes qui pourraient entraîner de telles erreurs :
clresource create
clresource delete
clresource set
clresourcegroup create
clresourcegroup delete
clresourcegroup set
Solution : afin d'éviter ce problème, attendez environ une minute après avoir redémarré un cluster de zones, afin de lui permettre d'atteindre un état stable, avant d'exécuter une des commandes ci-dessus.
Si tous les nœuds du cluster physique sont réinitialisés, attendez une minute de plus après l'affichage des messages de la console indiquant que tous les nœuds du cluster de zones ont rejoint le cluster, avant d'exécuter une des commandes ci-dessus. Les messages de la console ressemblent à l'exemple suivant :
May 5 17:30:49 phys-schost-4 cl_runtime: NOTICE: Membership : Node 'zc-host-2' (node id 2) of cluster 'schost' joined.
Si seuls certains nœuds sont réinitialisés tandis que d'autres restent actifs, le délai supplémentaire n'est pas nécessaire.
Résumé du problème : suite à l'installation et à la création du groupe de ressources et des ressources pour Oracle Solaris Cluster HA pour Apache Tomcat, le service ne peut pas démarrer si HA for Apache Tomcat est configuré en plus d'une zone de basculement.
Solution : contactez votre représentant du support technique Oracle afin d'obtenir le script manquant.
Résumé du problème : si vous interrompez le dispatcheur d'une instance de boîte de dialogue exécutant la version 7.11 du noyau SAP, l'agent du serveur d'application Web SAP n'est pas en mesure de redémarrer l'instance de boîte de dialogue sur le même nœud. Le redémarrage échoue après deux tentatives mais réussit ensuite sur l'autre nœud. La cause première en est que, avec la version 7.11 du noyau SAP, la commande cleanipc nécessite de définir LD_LIBRARY_PATH avant d'exécuter cleanipc.
Solution : insérez la définition de LD_LIBRARY_PATH et l'exécution de cleanipc dans le script Webas_Startup_Script pour la ressource webas. Par exemple, en supposant que le SID SAP est FIT et que l'instance est 03, le code à insérer dans le script de démarrage enregistré pour votre ressource webas dans la propriété Webas_Startup_script serait le suivant :
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/sap/FIT/SYS/exe/run export LD_LIBRARY_PATH /usr/sap/FIT/SYS/exe/run/cleanipc 03 remove
Résumé du problème : lorsque l'entrée du fichier /etc/vfstab du système de fichiers d'un cluster possède une valeur de montage à l'initialisation définie sur no et que le système de fichiers du cluster est configuré dans une ressource SUNW.HAStoragePlus qui appartient à un groupe de ressources évolutives, la ressource SUNW.HAStoragePlus ne parvient pas à passer en ligne. La ressource reste à l'état Starting jusqu'à ce que prenet_start_method ait dépassé le délai.
Solution : dans l'entrée du fichier /etc/vcfstab pour le système de fichiers du cluster, définissez la valeur du montage à l'initialisation sur yes.
Résumé du problème : dans Siebel 8.1.1, le serveur de passerelle a une dépendance sur la base de données. Si la machine hébergeant le listener de base de données n'est pas accessible, la sonde de la passerelle entraîne un ping pong du groupe de ressources jusqu'à ce que l'intervalle de ping pong soit atteint.
Solution : colocaliser le listener de base de données et la passerelle permet d'atténuer ce problème. Ou, dans le cas où la base de données est en cours d'exécution hors du contrôle du cluster, assurez-vous que la machine hébergeant le listener de base de données est activé et en cours d'exécution.
Résumé du problème : si des applications évolutives configurées pour être exécutées dans différents clusters de zones se lient à INADDR_ANY et utilisent le même port, alors les services évolutifs ne peuvent pas opérer de distinctions entre les instances de ces applications exécutées dans différents clusters de zones.
Solution : ne configurez pas les applications évolutives pour qu'elles se lient à INADDR_ANY en tant qu'adresse IP locale, ou pour qu'elles se lient à un port qui n'est pas en conflit avec une autre application évolutive.
Lors de l'ajout ou de la suppression d'un périphérique NAS, l'exécution simultanée de la commande clnas add ou clnas remove sur plusieurs nœuds peut venir corrompre le fichier de configuration NAS.
Solution : exécutez la commande clnas add ou clnas remove sur un nœud à la fois.
Résumé du problème : lorsqu'une zone non globale de marque native est ajoutée à la liste des nœuds d'un groupe de ressources qui contient une ressource HAStoragePlus avec des pools ZFS configurés, la ressource HAStoragePlus peut passer à l'état Faulted. Ce problème se produit uniquement lorsque le nœud physique qui héberge la zone native fait partie de la liste des nœuds du groupe de ressources.
Solution : redémarrez le groupe de ressources qui contient la ressource HAStoragePlus défectueuse.
# clresourcegroup restart faulted-resourcegroup
Résumé du problème : le script Stop du service de données GDS (Generic Data Service) ne parvient pas à forcer une défaillance de la méthode Stop. Si le script Stop présente un code de sortie différent de zéro, la méthode Stop GDS va tenter d'interrompre le démon des ressources. En cas de réussite de l'interruption, la méthode Stop quitte avec succès, même si le script d'arrêt a échoué. Par conséquent, le script d'arrêt ne peut pas forcer une défaillance de la méthode Stop par voie de programmation.
Solution : modifiez le script d'arrêt GDS de façon à ce qu'il exécute la commande clresourcegroup quiesce -k rgname, où rgname correspond au nom du groupe de ressources contenant la ressource GDS. L'option -k entraîne l'interruption par le démon rgmd de la méthode d'arrêt GDS en cours d'exécution. Ceci fait passer la ressource GDS à l'état STOP_FAILED, et le groupe de ressources passe à l'état ERROR_STOP_FAILED.
Voici les limites de cette solution :
La commande clresourcegroup quiesce empêche le redémarrage du nœud, même si le Failover_mode de la ressource est défini sur HARD. Si le comportement de redémarrage est nécessaire, le script d'arrêt GDS peut interroger la propriété Failover_mode et, si la propriété est définie sur HARD, il peut directement redémarrer le nœud ou une zone non globale dans laquelle il est en cours d'exécution.
Cette solution est plus adaptée à un groupe de ressources de basculement, qui peut uniquement s'arrêter sur un nœud à la fois. Dans le cas d'un groupe de ressources multimaîtres, la ressource GDS peut s'arrêter sur plusieurs nœuds en même temps. Dans ce cas, l'exécution de la commande clresourcegroup quiesce -k interrompra toutes les méthodes Stop en cours d'exécution sur plusieurs nœuds, et non uniquement sur le nœud qui est en cours d'exécution sur le nœud local.
Résumé du problème : Oracle Enterprise Manager Ops Center Agent for Oracle Solaris 10 utilise le logiciel JavaDB pour sa base de données de configuration. Lors de l'installation du logiciel Oracle Solaris Cluster à l'aide de l'utilitaire installer, le package logiciel JavaDB est réinstallé, ce qui entraîne la suppression d'une base de données de configuration de l'agent existante.
Les messages d'erreur suivants sont signalés par Ops Center Agent suite à la suppression du package :
java.sql.SQLException: Database '/var/opt/sun/xvm/agentdb' not found.
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
L'agent est maintenant interrompu et a besoin d'être déconfiguré ou configuré.
Solution : installez manuellement les packages JavaDB supplémentaires suivants sur l'ensemble des nœuds du cluster à partir du média Oracle Solaris Cluster :
SUNWjavadb-demo
SUNWjavadb-javadoc
SUNWjavadb-docs
SUNWjavadb-client
Exécuter l'utilitaire installer ne supprime pas les packages de base de données JavaDB existants.
Résumé du problème : lorsque vous utilisez l'utilitaire installer dans les environnements linguistiques en chinois simplifié et chinois traditionnel pour installer le logiciel Oracle Solaris Cluster le logiciel qui vérifie la configuration système requise signale à tort que l'espace de swap est de 0 Mo.
Solution : ignorez cette information. Dans ces environnements linguistiques, vous pouvez exécuter la commande suivante pour déterminer l'espace de swap correct :
# df -h | grep swap
Résumé du problème : lorsqu'un jeu de disques Solaris Volume Manager multipropriétaire est configuré sur la structure vucmm, la commande cldevicegroup status affiche toujours le jeu de disques en offline (hors ligne), quel que soit son état réel.
Solution : vérifiez l'état du jeu de disques multipropriétaire à l'aide de la commande metastat -s diskset.
Résumé du problème : une ressource évolutive qui dépend d'une ressource SUNW.SharedAddress n'est pas mise en ligne en raison d'une défaillance d'un groupe IPMP situé sur un sous-réseau qui n'est pas utilisé par la ressource d'adresse partagée. Des messages semblables à celui-ci s'affichent dans le syslog des nœuds du cluster :
Mar 22 12:37:51 schost1 SC SUNW.gds:5,Traffic_voip373,Scal_service_voip373,SSM_START: ID 639855 daemon.error IPMP group sc_ipmp1 has status DOWN. Assuming this node cannot respond to client requests.
Solution : réparez le groupe IPMP défaillant et redémarrez la ressource évolutive défaillante.
Résumé du problème : ce problème se produit lorsque le type de ressource SUNW.LogicalHostname est enregistré à la version 2 (utilisez la commande clresourcetype list pour afficher la version). Après la mise à niveau, des ressources de nom d'hôte logique peuvent être créées pour les zones non globales avec le paramètre ip-type=exclusive, mais l'accès réseau au nom d'hôte logique, par exemple, telnet ou rsh, ne fonctionne pas.
Solution : effectuez les opérations suivantes :
Supprimez tous les groupes de ressources à l'aide d'une liste de nœuds qui contient une zone non globale avec ip-type=exclusive hébergeant les ressources de nom d'hôte logique.
Mettez à niveau le type de ressource SUNW.LogicalHostname au minimum à la version 3 :
# clresourcetype register SUNW.LogicalHostname:3
|