test

Notes de version de Sun Cluster 3.0

Chapitre 1 Notes de version de Sun Cluster 3.0

Ce document contient les informations suivantes au sujet de la version 3.0 du logiciel SunTM Cluster :

Les annexes de ce document fournissent des fiches et des exemples qui vous aideront à planifier l'installation des services de données et du logiciel Sun Cluster 3.0. Ces fiches de configuration sont également disponibles dans les collections AnswerBookTM Sun Cluster 3.0.

Nouvelles fonctionnalités

Cette version intègre les nouvelles fonctionnalités suivantes :

Produits pris en charge

Cette section décrit les configurations logicielles et mémoire prises en charge avec Sun Cluster 3.0.

Installation des collections AnswerBook Sun Cluster

La documentation utilisateur de Sun Cluster 3.0 est disponible au format AnswerBook2 et peut donc être utilisée avec des serveurs de documentation AnswerBook2. La documentation AnswerBook2 de Sun Cluster 3.0 comprend :

Configuration du serveur de documentation AnswerBook2

L'environnement d'exploitation Solaris contient un logiciel de serveur de documentation AnswerBook2. Le CD-ROM de la documentation de Solaris, distinct du CD-ROM de l'environnement d'exploitation Solaris, contient le logiciel du serveur de documentation. Ce CD-ROM est nécessaire pour installer un serveur de documentation AnswerBook2.

Si vous disposez d'un serveur de documentation AnswerBook2 installé sur votre site, vous pouvez l'utiliser pour les collections AnswerBook Sun Cluster 3.0. Si vous ne disposez d'aucun serveur de documentation AnswerBook2 installé, installez-en un sur une machine de votre site. La console administrative que vous utilisez pour administrer votre cluster est un choix tout indiqué pour installer le serveur de documentation. N'utilisez pas un noeud de cluster comme serveur de documentation AnswerBook2.

Pour plus d'informations sur l'installation d'un serveur de documentation AnswerBook2, chargez le CD-ROM de la documentation de Solaris sur un serveur et lisez les fichiers README.

Consultation des collections AnswerBook Sun Cluster

Pour visualiser les collections AnswerBook Sun Cluster 3.0 sur votre serveur de documentation AnswerBook2, procédez comme indiqué ci-dessous. Installez les documents AnswerBook2 de Sun Cluster dans un système de fichiers du serveur qui exécute le serveur de documentation. Les collections AnswerBook Sun Cluster 3.0 sont fournies avec un script qui ajoute automatiquement les documents dans votre bibliothèque AnswerBook après l'installation.

Pour utiliser cette procédure, il vous faut :

Installation des collections AnswerBook Sun Cluster

Cette procédure vous permet d'installer les modules AnswerBook Sun Cluster des collections Sun Cluster 3.0 Collection et Sun Cluster 3.0 Data Services Collection.

  1. Devenez superutilisateur sur le serveur qui exécute le serveur de documentation AnswerBook2.

  2. Si vous avez déjà installé les collections AnswerBook Sun Cluster, supprimez les anciens modules.

    Si vous n'avez jamais installé de collection AnswerBook Sun Cluster, ignorez cette étape.


    # pkgrm SUNWscfab SUNWscdab

  3. Insérez le CD-ROM Sun Cluster ou le CD-ROM Sun Cluster Data Services dans le lecteur de CD-ROM du serveur de documentation.

    Le démon de gestion des volumes, vold(1M), doit monter le CD-ROM automatiquement.

  4. Placez-vous dans le répertoire du CD-ROM contenant le module AnswerBook Sun Cluster à installer.

    Le répertoire suivant contient le module de la collection Sun Cluster Collection : suncluster_3_0/SunCluster_3.0/Packages.

    Le répertoire suivant contient le module de la collection Sun Cluster Data Services Collection : scdataservices_3_0/components/SunCluster_Data_Service_Answer_Book_3.0/Packages.

  5. Utilisez la commande pkgadd(1) pour installer le module.


    # pkgadd -d .

  6. Sélectionnez les modules à installer.

    Sélectionnez les collections Sun Cluster 3.0 Collection (SUNWscfab) et Sun Cluster 3.0 Data Services Collection (SUNWscdab).

  7. Dans le menu des options d'installation de pkgadd, sélectionnez heavy pour ajouter le module complet au système et mettre à jour le catalogue AnswerBook2.

    Sélectionnez la collection Sun Cluster 3.0 Collection (SUNWscfab) ou Sun Cluster 3.0 Data Services Collection (SUNWscdab).

Le module de collection de documents fourni sur chaque CD-ROM comprend un script d'installation automatique qui, après l'installation, ajoute la collection dans la base de données de documentation et redémarre le serveur. Vous devriez maintenant être en mesure de consulter les collections AnswerBook Sun Cluster sur votre serveur de documentation.

Consultation des fichiers PDF

Les CD-ROM Sun Cluster contiennent désormais un fichier PDF pour chaque livre du jeu de documentation Sun Cluster.

Les fichiers PDF sont situés dans le répertoire suivant du CD-ROM Sun Cluster : ./suncluster_3_0/SunCluster_3.0/Docs/locale/C/PDF.

Le fichier PDF CD-ROM Data Services est situé dans le répertoire suivant : ./scdataservices_3_0/components/SunCluster_Data_Service_Answer_Book_3.0/Docs/locale/C/PDF.

Comme c'est le cas pour les collections AnswerBook Sun Cluster, six fichiers PDF sont disponibles sur le CD-ROM Sun Cluster et un fichier PDF sur le CD-ROM Data Services. Le nom de chaque fichier PDF est une abréviation du titre du fichier correspondant.

Le Tableau 1-2, "Correspondances entre les abréviations des PDF et les titres des manuels", indique le titre de manuel associé à chaque nom abrégé de fichier PDF.

Tableau 1-2 Correspondances entre les abréviations des PDF et les titres des manuels

CD-ROM 

Abréviation PDF 

Titre de manuel 

Sun Cluster 

CLUSTINSTALL

Guide d'installation de Sun Cluster 3.0

CLUSTNETHW

Sun Cluster 3.0 Hardware Guide

CLUSTAPIPG

Sun Cluster 3.0 Data Services Developers' Guide

CLUSTSYSADMIN

Guide d'administration système de Sun Cluster 3.0

CLUSTCONCEPTS

Sun Cluster 3.0 Concepts

CLUSTERRMSG

Sun Cluster 3.0 Error Messages Manual

Data Services 

CLUSTDATASVC

Sun Cluster 3.0 Concepts

Restrictions applicables à Sun Cluster 3.0

Les restrictions suivantes s'appliquent à la version 3.0 de Sun Cluster :

Versions Solaris prises en charge et informations sur les patchs

Accédez aux pages Web SunSolve à l'adresse http://sunsolve.sun.com pour obtenir la liste des versions de l'environnement d'exploitation Solaris prises en charge et les patchs nécessaires pour Sun Cluster 3.0. Pour trouver les pages concernant Sun Cluster, faites une recherche dans la collection EarlyNotifier en spécifiant le critère de recherche "Sun Cluster 3.0".

Consultez les informations EarlyNotifier avant d'installer Sun Cluster 3.0 et d'appliquer un patch à un composant du cluster (environnement d'exploitation Solaris, Sun Cluster, gestionnaire de volumes ou microprogramme de disque). Le même niveau de patchs doit être appliqué à tous les noeuds membres du cluster pour permettre à celui-ci de fonctionner correctement.

Pour plus d'informations sur les procédures spécifiques aux patchs et sur leur administration, reportez-vous au document Guide d'administration système de Sun Cluster 3.0.

Administration du système et mise à jour des procédures

Cette section décrit les modifications et mises à jour apportées aux procédures d'administration d'un cluster.

syncdir : changement d'options

Dans les versions Bêta, il était nécessaire de spécifier l'option syncdir pour ajouter un système de fichiers de cluster dans /etc/vfstab. Ce n'est plus nécessaire dans la version GA. Pour plus d'informations au sujet de ce changement, reportez-vous au document Guide d'installation de Sun Cluster 3.0 ou au document Sun Cluster 3.0 Concepts.

Noms d'host privés

Ne modifiez pas de nom d'host privé à l'aide de l'utilitaire scsetup après avoir configuré et démarré des services de données. Même si l'utilitaire scsetup vous permet de modifier les noms d'host privés, n'essayez pas de le faire sans prendre contact au préalable avec votre technicien de maintenance Sun.

Problèmes connus

Les problèmes connus suivants affectent le fonctionnement de Sun Cluster 3.0 GA. Pour connaître les plus récentes informations sur les problèmes connus, consultez les Notes de mise à jour disponibles en ligne à l'adresse http://docs.sun.com.

Bug nº 4314698

Récapitulatif du problème : après l'installation du logiciel Solstice Disksuite, il est nécessaire d'exécuter la commande scgdevs(1M) pour que les liens vers les périphériques Solstice Disksuite apparaissent dans l'espace de noms global.

Solution : exécutez la commande scgdevs manuellement pour vous assurer que les noeuds de périphérique Solstice Disksuite sont créés.

Bug nº 4346123

Récapitulatif du problème : lors d'une initialisation consécutive à plusieurs défaillances, un système de fichiers de cluster peut ne pas être monté automatiquement à partir de son entrée /etc/vfstab et être placé dans un shell administratif. L'exécution de la commande fsck peut produire l'erreur suivante : 


# fsck -y /dev/global/rdsk/d1s7
** /dev/global/rdsk/d1s7
Can't roll the log for /dev/global/rdsk/d1s7

Solution : ce problème est susceptible de se produire lorsque le périphérique global est associé à un montage de système de fichiers de cluster obsolète. Exécutez la commande suivante et vérifiez que le système de fichier est associé à un message d'erreur pour confirmer que le montage est obsolète.


# /usr/bin/df -k

Si le périphérique global est associé à un montage de système de fichiers de cluster obsolète, démontez le périphérique global. Notez que si le système de fichiers est utilisé sur au moins un des noeuds du cluster, le démontage n'aboutira pas. Exécutez la commande suivante sur chaque noeud pour identifier les utilisateurs actuels du système de fichiers. 


# /usr/sbin/fuser -c point_montage

Exécutez également la commande share(1M) pour confirmer que le système de fichiers n'est pas un système NFS partagé sur un des noeuds du cluster.

Bug nº 4358349

Récapitulatif du problème : ne créez pas de ressources Sun Cluster HA for NFS dans un groupe de ressources contenant une ressource SharedAddress. Le logiciel Sun Cluster ne prend pas en charge l'utilisation des ressources SharedAddress avec ce service de données.

Solution : ajoutez les ressources de nom d'host logique requises au groupe de ressources de reprise.

Vous devez utiliser une ressource LogicalHostname dans cette étape. Le nom d'host utilisé avec Sun Cluster HA for NFS ne peut pas être une ressource SharedAddress.


# scrgadm -a -L -g nom_groupe_ressources -l nom_host,...
-a -L -g nom_groupe_ressources

Spécifie le groupe de ressources de reprise dans lequel les ressources du nom d'host logique doivent être placées.

-l nom_host,...

Spécifie les ressources réseau (noms d'host logiques) à ajouter.

Bug nº 4358629

Récapitulatif du problème : la mise à niveau du logiciel Sun Cluster de la version 2.2 à la version Sun Cluster 3.0 peut échouer si les hosts logiques créés pour le logiciel Sun Cluster 2.2 utilisent une valeur plutôt qu'un nom d'host pour l'adresse IP.

Solution : il existe deux moyens de résoudre ce problème :

Bug nº 4359321

Récapitulatif du problème : l'utilitaire scinstall vous permet de spécifier le répertoire /global pour le système de fichiers de périphérique global. Cependant, comme le point de montage du système de fichiers de périphérique global est /global/.devices/node@id_noeud, cette caractéristique ne doit pas être activée.

Solution : réinstallez le noeud à l'aide du nom correct pour le système de fichiers de périphérique global.

Il est possible de rectifier les entrées des fichiers /etc/vfstab, de redémarrer le cluster et d'exécuter ensuite la commande scgdevs à titre de solution provisoire, bien que cette solution ne soit pas préconisée. Vérifiez que l'option de montage globale est activée pour l'entrée /global/.devices/node@id_noeud dans chaque fichier /etc/vfstab.

Bug nº 4362435

Récapitulatif du problème : lorsque le module Sun Cluster 3.0 est chargé sur la console Sun Management Center 2.1 et que vous essayez d'accéder à Resource Type Definition->Properties Table (Définition du type de ressource->Propriétés), la table ne se charge pas si sa longueur dépasse une page.

Solution : exécutez la commande scrgadm -pvv pour vérifier toutes les propriétés de type de ressource.

Bug nº 4362925

Récapitulatif du problème : 


nodeA# scshutdown -g0 -y
scshutdown: Unmount of /dev/md/sc/dsk/d30 failed: Device busy.
scshutdown: Could not unmount all PxFS filesystems.

Les modules Networker ont été regroupés et installés en même temps qu'Oracle. De ce fait, le démon nsrmmd est exécuté et effectue le montage vers le répertoire /global/oracle, empêchant ainsi le démontage de tous les autres systèmes de fichiers de cluster.


nodeA# umount /global/oracle
umount: global/oracle busy
nodeA# fuser -c /global/oracle
/global/oracle: nodeA# umount /global/oracle
umount: global/oracle busy
nodeA# fuser -c /global/oracle
/global/oracle: 335co 317co 302co 273co 272co
nodeA# ps -ef|grep 335
 root 335 273 0 17:17:41 ?       0:00 /usr/sbin/nsrmmd -n 1
 root 448 397 0 17:19:37 console 0:00 grep 335

Ce problème se produit durant l'arrêt de Sun Cluster, lorsque la procédure d'arrêt essaie de démonter un système de fichiers de cluster encore référencé par le processus nsrmmd.

Solution : exécutez la commande fuser(1M) sur chaque noeud pour établir la liste de tous les processus qui utilisent encore des systèmes de fichiers de cluster ne pouvant pas être démontés. Vérifiez qu'aucune ressource du logiciel Resource Group Manager n'a été redémarrée depuis l'échec de la commande scshutdown(1M) initiale. Arrêtez tous les processus à l'aide de la commande kill -9. Cette liste de processus à interrompre ne doit pas inclure de processus sous le contrôle du logiciel Resource Group Manager. Une fois tous les processus terminés, relancez la commande scshutdown. L'arrêt devrait se dérouler correctement.

Bug nº 4365310

Récapitulatif du problème : si l'état d'une ressource devient STOP_FAILED, vous devez effacer manuellement l'indicateur STOP_FAILED de la ressource en question. Si vous spécifiez l'effacement de l'indicateur de plusieurs ressources et que l'état d'une des ressources n'est pas STOP_FAILED, la fonction se termine prématurément sans effacer les indicateurs STOP_FAILED des autres ressources répertoriées.

Aucun message d'erreur ne s'affiche dans ce cas, mais les indicateurs des autres ressources ne sont pas effacés. L'absence de message d'erreur peut prêter à confusion dans la mesure où aucune trace de l'erreur n'est signalée alors que l'état STOP_FAILED de certaines ressources n'a pas été effacé.

Solution : pour éviter le problème, vous devez effacer les indicateurs STOP_FAILED individuellement pour chaque ressource dans cet état.


# scswitch -c -f STOP_FAILED -j stopfailres -h phys-schost-1

Bug nº 4365700

Récapitulatif du problème : dans l'exemple suivant, plusieurs ressources du même groupe de ressources sont désactivées avec une seule commande.


# scswitch -n -j r1,r2,r3

Si l'état de la première ressource devient STOP_FAILED, les ressources suivantes risquent d'être désactivées tout en restant en ligne. Cet état en ligne représente un état interne non valide du démon Resource Group Manager et risque d'entraîner une erreur grave de ce logiciel.

Solution : ne désactivez qu'une seule ressource par commande scswitch(1M).

Bug nº 4365729

Récapitulatif du problème : toute tentative pour faire passer un groupe de périphériques en mode de maintenance à l'aide de la commande suivante échoue si des systèmes de fichiers sont montés sur le groupe de périphériques spécifié.


# scswitch -m -D groupe_périphériques

Solution : démontez tous les systèmes de fichiers sur le groupe de périphériques qui doit passer en mode de maintenance. Un groupe de périphériques ne peut passer en mode de maintenance que si aucun de ses périphériques n'est utilisé, c'est-à-dire s'il n'existe pas d'utilisateur de périphériques actifs dans ce groupe de périphériques et si tous les systèmes de fichiers dépendants sont démontés.

Bug nº 4366840

Récapitulatif du problème : si vous retirez des câbles, ainsi que les cartes et jonctions associées, d'un cluster alors qu'un de ses noeuds est arrêté, une erreur grave se produira pendant la réinitialisation du noeud lorsque celui-ci tentera de rejoindre le cluster.

Solution : tant que ce problème n'a pas été résolu, n'essayez pas de déconnecter de câbles, cartes ou jonctions d'un cluster lorsqu'un noeud est arrêté. Si vous rencontrez ce problème, réinitialisez le noeud une seconde fois. Le noeud pourra ensuite rejoindre le cluster normalement.

Bug nº 4366886

Récapitulatif du problème : la présence d'une charge système élevée peut gêner la mise en ligne de groupes de périphériques. Ce problème se produit parce que VERITAS Volume Manager (VxVM) doit exécuter plusieurs tâches, notamment la synchronisation des miroirs, pour importer un groupe de disques. En présence de charges importantes, de telles tâches risquent de ne pas pouvoir se terminer dans les temps parce que d'autres tâches système consomment un nombre important de ressources système. Comme les groupes de périphériques sont normalement mis en ligne automatiquement lors de l'initialisation d'un noeud (lorsqu'un système de fichiers est configuré pour se monter automatiquement par exemple), un tel blocage en ligne risque de se manifester sous la forme d'un blocage lors de l'initialisation.

Solution : réduisez la charge système ou augmentez la priorité du démon vxconfigd.

Bug nº 4368034

Récapitulatif du problème : si le démon Resource Group Manager ou un noeud meurt pendant un appel de procédure distante, un message d'erreur similaire au suivant risque de s'afficher sur la console système.


COMM_FAILURE SystemException: COMM_FAILURE major 3 minor 0 Error 0 completed NO
 

INV_OBJREF SystemException: INV_OBJREF major 4 minor 9 Bad file number completed NO

Ces messages sont affichés à des fins de débogage plutôt qu'à l'intention des utilisateurs. Le démon Resource Group Manager produit d'ores et déjà des messages syslog plus faciles à comprendre pour ces exceptions, et les instructions printf de débogage ne sont donc pas nécessaires.

Solution : ignorez ces messages de console. Vérifiez les messages syslog liés à la mort d'un noeud. Normalement, le démon Resource Group Manager est en mesure d'effectuer une reprise automatique en présence d'un tel événement.

Bug nº 4369228

Récapitulatif du problème : l'utilitaire dbassist fourni par Oracle ne permet pas la création d'une base de données Oracle Parallel Server directement sur un périphérique RAID matériel.

Solution : utilisez le mode ligne d'Oracle Server Manager, svrgmrl, pour créer des bases de données Oracle Parallel Server dans le logiciel Sun Cluster 3.0.

Bug nº 4369565

Récapitulatif du problème : le script nfs_upgrade ne fournit pas le même résultat s'il est exécuté deux fois.

Solution : si vous avez besoin d'exécuter le script deux fois, supprimez la ressource NFS et le type de ressource NFS créés lors de la première tentative avant d'exécuter le script une deuxième fois.

Bug nº 4369668

Récapitulatif du problème : lorsque l'administrateur système modifie la propriété Nodelist d'un groupe de ressources gérés, le logiciel Resource Group Manager doit exécuter la méthode INIT sur toutes les ressources du groupe possédant la propriété Init_nodes=RG_PRIMARIES et sur tous les noeuds ajoutés à la liste de noeuds. Le logiciel Resource Group Manager doit exécuter la méthode FINI sur de telles ressources pour les noeuds supprimés de la liste de noeuds. De même, si la propriété Installed_nodes d'un type de ressource est modifiée, il doit exécuter la méthode INIT ou FINI sur toutes les ressources de ce type qui résident dans les groupes de ressources gérés et qui ont la propriété Init_nodes=RT_installed_nodes.

Le logiciel Resource Group Manager n'exécute actuellement pas la méthode INIT ni FINI lorsque ces mises à jour sont effectuées. De ce fait, les ressources ne sont pas toujours correctement initialisées ou effacées sur ces noeuds.

Solution : à l'aide de la commande scswitch, vous devez désactiver puis réactiver la gestion des groupes de ressources affectés. Malheureusement, l'administrateur doit faire passer le groupe de ressources hors ligne pour appliquer cette procédure. L'administrateur a également la possibilité d'exécuter les actions INIT ou FINI équivalentes manuellement (sans désactiver la gestion du groupe de ressources) si ces procédures sont documentées pour les types de ressources présents dans le groupe.

Cette solution est inutile si l'une des ressources du groupe comporte la méthode INIT ou FINI. Les seuls types de ressources fournis par Sun qui utilisent les méthodes INIT et FINI sont les suivants :

Les types de ressources mis en oeuvre par les utilisateurs ou les fournisseurs tiers peuvent également utiliser les méthodes INIT et FINI. Dans ce cas, cette solution est nécessaire pour les groupes de ressources qui contiennent de tels types de ressources.

Remarque :

tous les services évolutifs utilisent implicitement les méthodes INIT et FINI, même si de telles méthodes ne sont pas explicitement déclarées pour ce type de ressource.

Bug nº 4370760

Récapitulatif du problème : vous ne pouvez pas supprimer le dernier host d'un méta-ensemble, à moins de mettre d'abord le groupe de périphériques hors ligne.

Solution : pour supprimer le dernier host d'un méta-ensemble, commencez par mettre le groupe de périphériques hors ligne. Pour supprimer le dernier host, exécutez les deux commandes suivantes en tant que superutilisateur sur l'host à supprimer.


# /usr/cluster/bin/scswitch -m -D disksetname
# metaset -s disksetname -d -h hostname

Bug nº 4371236

Récapitulatif du problème : certaines options ge nécessitent la configuration des paramètres de périphérique ge à certaines valeurs plutôt qu'aux valeurs par défaut. Le chapitre 3 du document Sun GigabitEthernet/P 2.0 Adapter Installation and User's Guide décrit la procédure à suivre pour modifier les paramètres de périphérique ge. La procédure à utiliser sur les noeuds qui exécutent le logiciel Sun Cluster 3.0 varie légèrement de celle décrite dans le guide. La principale différence se situe au niveau de l'utilisation des noms de chemin de périphérique figurant dans le fichier /etc/path_to_inst et utilisés pour calculer les noms des parents à utiliser dans le fichier ge.conf.

Solution : le chapitre 3 du document Sun GigabitEthernet/P 2.0 Adapter Installation and User's Guide décrit la procédure à suivre pour modifier les valeurs des paramètres de périphériques ge à l'aide des entrées du fichier /kernel/drv/ge.conf. La procédure pour déterminer le nom parent à partir de la liste /etc/path_to_inst (à utiliser dans les entrées ge.conf) est indiquée à la page 24, "Setting Driver Parameters Using a ge.conf File.". Par exemple, dans la ligne suivante de /etc/path_to_inst, vous pouvez déterminer que le nom parent de ge2 est /pci@4,4000.


"/pci@4,4000/network@4" 2 "ge"

Sur les noeuds de cluster, vous devez supprimer le préfixe /node@id_noeud des chemins de périphérique dans /etc/path_to_inst avant d'utiliser le préfixe comme nom parent. Par exemple, sur un noeud de cluster, une entrée /etc/path_to_inst équivalente pourra comporter la valeur suivante.


"/node@1/pci@4,4000/network@4" 2 "ge"

Le nom parent de ge2 à utiliser dans ge.conf reste quand même /pci@4,4000.

Bug nº 4372369

Récapitulatif du problème : le script nfs_upgrade ne peut pas fonctionner si plusieurs hosts logiques sont configurés dans le logiciel Sun Cluster 2.2.

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

Bug nº 4373498

Récapitulatif du problème : le serveur administratif LDAP tient compte des majuscules et des minuscules dans les noms d'host. Si vous travaillez avec le serveur administratif LDAP, tous les noms d'host spécifiés dans la configuration LDAP doivent donc respecter la casse de la spécification LDAP dans le service de noms utilisé sur le noeud de cluster. Ce respect de la casse est particulièrement important si le nom de service utilisé est DNS, dans la mesure où le nom de domaine DNS doit aussi correspondre exactement à la spécification de nom d'host dans la configuration LDAP.

Solution : vérifiez que la casse du nom de domaine complet de l'ordinateur fourni à LDAP correspond très exactement à la casse du nom de domaine fourni par le résolveur.

Bug nº 4373911

Récapitulatif du problème : Lors des tâches suivantes :

le message d'avertissement ci-dessous risque de s'afficher sur le moniteur de panne HA-NFS.


clnt_tp_create_timed of program statd failed:RPC:Program not registered

Solution : aucune solution n'est nécessaire. Ce message d'avertissement peut être ignoré sans risque.

Bug nº 4374194

Récapitulatif du problème : l'agent Sun Management Center peut se terminer de manière inattendue sur les postes de travail UltraTM 2 équipés de Sun StorEdge A5000. Le problème se produit lorsque l'agent Sun Management Center est configuré avec l'outil Config Reader et que le module Config-Reader4udt est ajouté au fichier /var/opt/SUNWsymon/cfg/base-modules-d.dat. L'agent Sun Management Center lit ce fichier au démarrage et essaie ensuite de charger tous les modules répertoriés. L'agent risque de générer une erreur de segmentation s'il tente de charger le module Config-Reader4udt.

Solution : pour éviter le problème, procédez de la manière suivante :

Bug nº 4374648

Récapitulatif du problème : la page de manuel scinstall comporte actuellement un exemple faisant appel à -s oracle pour effectuer automatiquement la mise à niveau du logiciel Sun Cluster de la version 2.2 à la version Sun Cluster 3.0 pour un service de données Sun Cluster HA for Oracle. Cette option n'est pas prise en charge actuellement.

Solution : n'utilisez pas l'option -s oracle pour effectuer la mise à niveau de Sun Cluster 2.2 vers Sun Cluster 3.0 dans un service de données Oracle. A la place, utilisez la procédure de mise à niveau manuelle, "Mise à niveau de Sun Cluster 2.2 vers Sun Cluster 3.0 sur Sun Cluster HA for Oracle".

Bug nº 4376171

Récapitulatif du problème : l'installation d'une carte FC-AL SBus (FC100/S) et d'une carte Sun Quad FastEthernetTM 2.0 (SQFE/S) sur le même SBus risque de produire des résultats inattendus sur la carte QFE.

Solution : évitez de configurer les noeuds du cluster avec une carte FC-AL SBus (FC100/S) et une carte Sun Quad FastEthernet 2.0 (SQFE/S) sur le même SBus.

Bug nº 4377303

Récapitulatif du problème : les numéros LUN Sun StorEdge A3500 nouvellement créés n'apparaissent pas toujours sur tous les noeuds.

Solution : exécutez la commande /etc/raid/bin/hot_add sur les noeuds qui ne voient pas les nouveaux numéros LUN.

Bug nº 4378553

Récapitulatif du problème : une propriété Nodelist de groupe de ressources est une liste ordonnée des noeuds qui peuvent être maîtres du groupe de ressources, avec le noeud préféré en premier. Le logiciel Resource Group Manager doit toujours héberger un groupe de ressources sur le premier noeud préféré disponible. Cependant, lorsqu'un administrateur redémarre le cluster (avec redémarrage simultané de tous les noeuds), les groupes de ressources gérés risquent d'être dépendants de noeuds autres que le premier noeud préféré. Ce problème ne se produit que lors d'une réinitialisation de l'ensemble du cluster.

Solution : après avoir redémarré le cluster, utilisez la commande scswitch pour transférer les groupes de ressources sur les noeuds appropriés. L'ordre de préférence Nodelist est dès lors automatiquement appliqué, tant que le cluster n'est pas arrêté.

Stratégie d'équilibrage de charge résidente des services évolutifs

Vous risquez actuellement de rencontrer un problème en exécutant un service de données évolutif qui utilise la stratégie d'équilibrage de charge résidente (sticky). Le problème est susceptible de se produire si le service est exécuté avec une résidence établie par rapport à un noeud particulier et que vous démarrez une autre instance du même service sur un autre noeud. Le démarrage de la deuxième instance du même service risque de faire perdre sa résidence à la première.

Le résultat produit par l'algorithme de résidence au démarrage de la seconde instance détermine si la première instance perd ou non sa résidence. L'algorithme ne devrait pas changer l'affinité de résidence dans ce cas, mais le fait quand même parfois.

Pour plus d'informations sur la stratégie d'équilibrage de charge résidente, reportez-vous au document Sun Cluster 3.0 Concepts.

Mise à niveau de Sun Cluster 2.2 vers Sun Cluster 3.0 sur Sun Cluster HA for Oracle

Exécutez ces procédures pendant la mise à niveau du logiciel de structure Sun Cluster à l'aide de la procédure de mise à niveau scinstall.

Conditions et restrictions

Les conditions et restrictions suivantes s'appliquent à la mise à niveau de Sun Cluster 2.2 vers Sun Cluster 3.0 sur Sun Cluster HA for Oracle.

Enregistrement des fichiers de configuration Sun Cluster HA for Oracle

Pour enregistrer les fichiers de configuration de votre configuration Sun Cluster 2.2, procédez comme indiqué ci-après.

  1. Suivez la procédure de mise à niveau du logiciel de structure scinstall jusqu'à la fin des étapes de début de mise à niveau (scinstall -F begin) sur chaque noeud.

  2. Exécutez la commande suivante en tant que superutilisateur sur chaque noeud. Cette commande sauvegarde une copie de tous les fichiers présents dans le répertoire /var/opt/oracle.

    Pour éviter de perdre ces informations, créez une copie de sauvegarde de l'arborescence du répertoire /var/opt/oracle sur un périphérique externe.


    # cp -r /var/opt/oracle /var/cluster/logs/install/preserve/2.2/SUNWscor

  3. Lancez l'étape finale de la mise à jour du logiciel de structure (scinstall -u finish).

    Remarque :

    n'utilisez pas l'option -s oracle dans la commande scinstall -u finish). Cette option essaie d'effectuer une mise à niveau automatique de Sun Cluster HA for Oracle, entraînant un échec de la mise à niveau automatique. La seule mise à jour automatisée prise en charge s'applique à NFS.

Une fois la mise à jour du logiciel de structure effectuée, configurez l'environnement Sun Cluster 3.0. La section suivante, "Configuration de l'environnement Sun Cluster 3.0", décrit cette procédure.

Configuration de l'environnement Sun Cluster 3.0

Exécutez les étapes suivantes pour configurer votre environnement Sun Cluster 3.0.

  1. Sur un noeud, exécutez la commande suivante pour vérifier que :

    • La mise à niveau du logiciel de structure a correctement configuré un groupe de ressources Sun Cluster 3.0 qui correspond à chaque host logique Sun Cluster 2.2.

    • La ressource réseau du nom d'host fait partie de groupe de ressources et est en ligne.


    # scstat -g

  2. Sur un noeud, exécutez la commande suivante pour vérifier que le groupe de disques VERITAS ou l'ensemble de disques Solstice DiskSuite qui contenait la base de données Oracle (et éventuellement les fichiers binaires Oracle) dans Sun Cluster 2.2 est correctement associé à un groupe de disques dans Sun Cluster 3.0. 


    # scstat -D

  3. Sur chaque noeud, exécutez la commande suivante pour vérifier que les systèmes de fichiers requis pour chaque instance d'Oracle ont été montés.


    # mount

  4. Sur chaque noeud, exécutez les commandes suivantes pour restaurer dans le répertoire /var/opt la version sauvegardée des fichiers de configuration Oracle.

    Si vous avez enregistré les fichiers dans le répertoire /var/opt/oracle plus haut dans cette procédure et que les fichiers n'ont pas changé, vous pouvez ignorer cette étape.


    # cp -r /var/cluster/logs/install/preserve/2.2/SUNWscor/oracle /var/opt
# chown -R oracle:dba /var/opt/oracle

Configuration de Sun Cluster HA for Oracle sous Sun Cluster 3.0

Configurez Sun Cluster 3.0 HA for Oracle en procédant comme indiqué ci-après.

Remarque :

exécutez l'étape 1 une seule fois.

  1. Sur un noeud, enregistrez le serveur Oracle et les types de ressources d'écoute à l'aide des commandes suivantes : 


    # scrgadm -a -t SUNW.oracle_server
# scrgadm -a -t SUNW.oracle_listener

    Exécutez les étapes Étape 2 à Étape 5 pour chaque instance de Sun Cluster 2.2 HA for Oracle répertoriée dans le fichier /var/opt/oracle/oratab.

  2. Déterminez la valeur de la variable ORACLE_HOME à partir du fichier oratab.

    Par exemple, supposons que le fichier oratab contiennent les informations suivantes.


    ora32:/oracle/816_32:N

    Ces informations indiquent que la variable ORACLE_HOME de l'instance ORACLE_SID ora32 a pour valeur /oracle/816_32.

  3. Notez la valeur des paramètres du fichier ccd.database pour chaque instance d'Oracle.

    Ces paramètres seront associés à des paramètres Sun Cluster 3.0 dans scrgadm. Vous utiliserez ces paramètres pour configurer Sun Cluster HA for Oracle sous Sun Cluster 3.0.


    # grep ^HAORACLE: /var/cluster/logs/install/preserve/2.2/SUNWcluster/conf/ccd.database

    Chaque instance d'Oracle dans le fichier ccd.database utilise la syntaxe suivante :


    HAORACLE:on:ora32:boots-1:60:10:120:300:scott/tiger:/oracle/816_32/dbs/initora32.ora:ORA_LIST
    .

    Ces paramètres sont convertis au format Sun Cluster 3.0 suivant :


    HAORACLE:STATE:ORACLE_SID:LOGICAL_HOSTNAME_IP_Resource:THOROUGH_PROBE_INTERVAL:CONNECT_CYCLE:PROBE_TIMEOUT:RETRY_INTERVAL:CONNECT_STRING:PARAMETER_FILE:LISTENER_NAME

    Le nom de groupe de ressources RG_NAME devient ${LOGICAL_HOSTNAME_IP_Resource}-lh. Notez que -lh est automatiquement ajouté au nom du groupe de ressources dans Sun Cluster 3.0.

  4. Repérez la valeur background_dump_dest dans la variable $PARAMETER_FILE et attribuez la valeur suivante à la variable ALERT_LOG_FILE :


    $background_dump_dest/alert_$ORACLE_SID.log

    Par exemple, pour ORACLE_SID=ora32, supposons que, dans le fichier $PARAMETER_FILE, background_dump_dest ait la valeur suivante :


    /oracle/816_32/admin/ora32/bdump

    Dans cet exemple, ALERT_LOG_FILE doit être mis à jour avec la valeur suivante : 


    /oracle/816_32/admin/ora32/bdump/alert_ora32.log

  5. Sur un noeud, exécutez les commandes suivantes pour créer les ressources Oracle et les mettre en ligne.


    # scrgadm -a -t SUNW.oracle_server -g $RG_NAME -j $ORACLE_SID-serv \ 

-x Oracle_sid=$ORACLE_SID -x Oracle_home=$ORACLE_HOME \ 

-y Thorough_probe_interval=$THOROUGH_PROBE_INTERVAL \ 

-x Connect_cycle=$CONNECT_CYCLE -x Probe_timeout=$PROBE_TIMEOUT \ 

-y Retry_interval=$RETRY_INTERVAL -x Connect_string=$CONNECT_STRING \ 

-x Parameter_file=$PARAMETER_FILE -x Alert_log_file=$ALERT_LOG_FILE
# scrgadm -a -j $ORACLE_SID-list -t SUNW.oracle_listener -g $RG_name \ 

-x Oracle_home=$ORACLE_HOME -x Listener_name=$LISTENER_NAME# scswitch -e -j $ORACLE_SID-serv
# scswitch -e -j $ORACLE_SID-list
# scswitch -e -M -j $ORACLE_SID-serv
# scswitch -e -M -j $ORACLE_SID-list

    Par exemple, à l'aide de l'instance Oracle décrite à l'Étape 2, à l'Étape 3 et à l'Étape 4, vous devez exécuter les commandes suivantes :


    # scrgadm -a -t SUNW.oracle_server -g boots-1-lh -j ora32-serv \ 

-x Oracle_sid=ora32 -x Oracle_home=/oracle/816_32 \ 

-y Thorough_probe_interval=60 \ 

-x Connect_cycle=10 -x Probe_timeout=120 \ 

-y Retry_interval=300 -x Connect_string=scott/tiger \ 

-x Parameter_file=/oracle/816_32/dbs/initora32.ora \ 

-x Alert_log_file=/oracle/816_32/admin/ora32/bdump/alert_ora32.log
# scrgadm -a -j ora32-list -t SUNW.oracle_listener -g boots-1-lh \ 

-x Oracle_home=/oracle/816_32 -x Listener_name=ORA_LIST
# scswitch -e -j ora32-serv
# scswitch -e -j ora32-list
# scswitch -e -M -j ora32-serv
# scswitch -e -M -j ora32-list

Vérification de la mise à niveau

Pour vérifier que la mise à niveau a été effectuée correctement, procédez comme indiqué ci-après.

  1. Vérifiez que les ressources Oracle sont en ligne à l'aide de la commande suivante :


    # scstat -g
    .

  2. Vérifiez que vous pouvez changer de groupe de ressources au moyen de la commande suivante :


    # scswitch -z -g groupe_ressources -h noeud

Problèmes connus de la documentation

Cette section décrit les erreurs de documentation que vous risquez de rencontrer et la procédure à suivre pour rectifier les problèmes.

Guide d'installation

Le Guide d'installation de Sun Cluster 3.0 contient les erreurs suivantes :

Guide du matériel

Dans le document Sun Cluster 3.0 Hardware Guide, les procédures suivantes sont incorrectes ou absentes :

Transfert d'un câble de disque sur une autre carte

Pour transférer un câble de disque sur une nouvelle carte d'un noeud, procédez comme indiqué ci-après.

  1. Arrêtez progressivement toutes les E/S du ou des disques affectés.

  2. Débranchez le câble de l'ancienne carte.

  3. Exécutez la commande cfgadm(1M) sur le noeud local pour annuler la configuration de tous les disques affectés par le transfert.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  4. Exécutez la commande devfsadm -C sur le noeud local pour effacer le lien de périphérique Solaris.

  5. Exécutez la commande scdidadm -C sur le noeud local pour effacer le chemin de périphérique DID.

  6. Connectez le câble à la nouvelle carte.

  7. Exécutez la commande cfgadm sur le noeud local pour configurer les périphériques dans leur nouvel emplacement.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  8. Exécutez la commande scgdevs pour ajouter le nouveau chemin de périphérique DID.

Transfert d'un câble de disque d'un noeud vers un autre

Pour transférer un câble de disque d'un noeud vers un autre, procédez comme indiqué ci-après.

  1. Supprimez toutes les références au chemin à supprimer dans toutes les configurations de gestionnaires de volumes et de services de données.

  2. Arrêtez progressivement toutes les E/S du ou des disques affectés.

  3. Débranchez le câble de l'ancien noeud.

  4. Exécutez la commande cfgadm sur l'ancien noeud pour annuler la configuration de tous les disques affectés par le transfert.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  5. Exécutez la commande devfsadm -C sur l'ancien noeud pour effacer le lien de périphérique Solaris.

  6. Exécutez la commande scdidadm -C sur l'ancien noeud pour effacer le chemin de périphérique DID.

  7. Connectez le câble au nouveau noeud.

  8. Exécutez la commande cfgadm sur le nouveau noeud pour configurer les périphériques dans leur nouvel emplacement.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  9. Exécutez la commande devfsadm sur le nouveau noeud pour créer les nouveaux liens de périphérique Solaris.

  10. Exécutez la commande scgdevs sur le nouveau noeud pour ajouter le nouveau chemin de périphérique DID.

  11. Ajoutez, sur le nouveau noeud, le chemin vers les configurations de gestionnaire de volumes et de service de données requises.

    Lorsque vous configurez les services de données, vérifiez que les préférences de reprise de noeud reflètent bien la nouvelle configuration.

Mise à jour du logiciel de cluster avec la configuration correcte des périphériques

Si les procédures ci-dessus ne sont pas exécutées correctement, une erreur risque de se produire lors de l'exécution suivante de la commande scdidadm -r ou scgdevs. Pour mettre à jour le logiciel de cluster avec la configuration des périphériques correcte, procédez comme indiqué ci-après.

  1. Vérifiez que la configuration du câble est correcte. Vérifiez que le câble est déconnecté de l'ancien noeud.

  2. Vérifiez que l'ancien noeud a été supprimé dans les configurations de gestionnaire de volumes ou de service de données appropriées.

  3. Exécutez la commande cfgadm sur l'ancien noeud pour annuler la configuration de tous les disques affectés par le transfert.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  4. Exécutez la commande devfsadm -C sur le noeud dont vous avez déconnecté le câble.

  5. Exécutez la commande scdidadm -C sur le noeud dont vous avez déconnecté le câble.

  6. Exécutez la commande cfgadm sur le nouveau noeud pour configurer les périphériques dans leur nouvel emplacement.

    Vous pouvez également réinitialiser le noeud à l'aide de la commande suivante : 


    # reboot -- -r

  7. Exécutez la commande scgdevs sur le nouveau noeud pour ajouter le nouveau chemin de périphérique DID.

  8. Exécutez la commande scdidadm -R périphérique sur le nouveau noeud pour vous assurer que l'état des réservations SCSI est correct.

Guide de développement de service de données

L'exemple de code fourni dans l'annexe B du document Sun Cluster 3.0 Data Services Developers' Guide contient deux problèmes connus :

Guide des concepts

Concernant le document Sun Cluster 3.0 Concepts, notez que :

Utilisation de l'interconnexion de cluster pour le trafic applicatif

Les noeuds d'un cluster doivent être reliés par de multiples connexions, constituant l'interconnexion du cluster. Pour des raisons de haute disponibilité et de performances, le logiciel de cluster utilise de nombreuses interconnexions. Pour le trafic interne (par exemple, les données de fichiers système ou les données de services évolutifs), les messages sont répartis sur toutes les interconnexions disponibles à tour de rôle.

L'interconnexion de cluster est également mise à la disposition des applications pour offrir une communication haute disponibilité entre les noeuds. Par exemple, les composants d'une application distribuée peuvent s'exécuter sur différents noeuds et avoir besoin de communiquer les uns avec les autres. En utilisant l'interconnexion de cluster plutôt que l'interconnexion publique, ces connexions peuvent tolérer une défaillance sur une liaison individuelle.

Pour utiliser l'interconnexion de cluster pour ses communications, l'application doit adopter les noms d'hosts privés configurés lors de l'installation du cluster. Par exemple, si le nom d'host privé du noeud 1 est clusternode1-priv, utilisez ce nom pour communiquer sur l'interconnexion de cluster avec le noeud 1. Les sockets TCP ouverts à l'aide de ce nom sont acheminés sur l'interconnexion de cluster et peuvent être redirigés de manière totalement transparente en cas de défaillance du réseau.

Notez que, comme les noms d'host privés peuvent être configurés durant l'installation, l'interconnexion de cluster peut utiliser n'importe quel nom choisi à ce moment là. Le nom réel peut être obtenu à l'aide de la commande scha_cluster_get(3HA) suivie de l'argument scha_privatelink_hostname_node.

Pour utiliser l'interconnexion de cluster au niveau de l'application, une simple interconnexion est établie entre deux noeuds, mais des interconnexions distinctes sont utilisées entre les différentes paires de noeuds dans la mesure du possible. Supposons par exemple qu'une application exécutée sur trois noeuds communique sur l'interconnexion de cluster. La communication entre les noeuds 1 et 2 peut avoir lieu sur l'interface hme0 et la communication entre les noeuds 1 et 3 sur l'interface qfe1. Autrement dit, les communications de l'application entre deux noeuds sont limitées à une simple interconnexion, tandis que les communications internes du cluster sont réparties sur toutes les interconnexions.

Notez que l'application partage l'interconnexion avec le trafic interne du cluster et, de ce fait, que la bande passante à la disposition de l'application dépend de la bande passante utilisée par le reste du trafic. En cas de défaillance, le trafic interne est acheminé tour à tour sur les autres interconnexions, tandis que les connexions d'application sur une interconnexion défaillante peuvent être réacheminées sur une interconnexion en bon état de fonctionnement.

Deux types d'adresses supportent l'interconnexion de cluster et la commande gethostbyname(3N) exécutée sur un nom d'host privé renvoie normalement deux adresses IP. La première adresse est appelée adresse de paire logique et la seconde adresse "par noeud" logique.

Une adresse de paire logique distincte est attribuée à chaque paire de noeuds. Ce petit réseau logique prend en charge la reprise sur panne des connexions. Chaque noeud se voit également attribuer une adresse "par noeud" fixe. Autrement dit, l'adresse de paire logique de clusternode1-priv est différente pour chaque noeud, tandis que l'adresse "par noeud" logique de clusternode1-priv est la même pour chaque noeud. Un noeud ne comporte toutefois pas d'adresse de paire logique le désignant et, de ce fait, la commande gethostbyname(clusternoeud1-priv) exécutée sur le noeud 1 renvoie uniquement l'adresse "par noeud" logique.

Notez que les applications qui acceptent des connexions sur l'interconnexion du cluster et vérifient ensuite l'adresse IP pour des raisons de sécurité doivent procéder à une nouvelle vérification de toutes les adresses IP renvoyées par la commande gethostbyname, et non pas simplement la première.

Si votre application requiert des adresses IP permanentes pour tous les points, configurez-la pour qu'elle se lie à l'adresse "par noeud" du côté client et du côté serveur de sorte que toutes les connexions semblent provenir de et se diriger vers cette adresse "par noeud".

Guide d'installation et de configuration des services de données

Le chapitre 5, "Installing and Configuring Sun Cluster HA for Apache", du document Sun Cluster 3.0 Data Services Installation and Configuration Guide décrit la procédure à suivre pour installer le serveur Web Apache à partir du site Web Apache (http://www.apache.org). Vous avez également la possibilité d'installer le serveur Web Apache à partir du CD-ROM de l'environnement d'exploitation Solaris 8.

Les fichiers binaires Apache sont fournis dans trois modules (SUNWapchr, SUNWapchu et SUNWapchd) qui constituent le métacluster SUNWCapache. Vous devez installer SUNWapchr avant SUNWapchu.

Placez les binaires du serveur Web dans le système de fichiers local de chacun des noeuds de votre cluster ou dans un système de fichiers de cluster.

Installation d'Apache à partir du CD-ROM Solaris 8

Cette procédure décrit les étapes à suivre pour utiliser le service de données Sun Cluster HA for Apache avec la version du serveur Web Apache disponible sur le CD-ROM de l'environnement d'exploitation Solaris 8.

  1. Installez les modules Apache SUNWapchr, SUNWapchu et SUNWapchd, si ce n'est pas encore fait.

    Utilisez la commande pkginfo(1) pour vérifier si les modules sont déjà installés.


    # pkgadd -d Solaris 8 Product directory SUNWapchr SUNWapchu SUNWapchd
...
Installing Apache Web Server (root) as SUNWapchr
...
[ verifying class initd ]
/etc/rc0.d/K16apache linked pathname
/etc/rc1.d/K16apache linked pathname
/etc/rc2.d/K16apache linked pathname
/etc/rc3.d/S50apache linked pathname
/etc/rcS.d/K16apache linked pathname
...

  2. Désactivez les scripts de contrôle de début et de fin qui viennent d'être installés avec le module SUNWapchr.

    Il est nécessaire de désactiver ces scripts parce que le service de données Sun Cluster HA for Apache démarre et arrête l'application Apache après la configuration du service de données. Exécutez les étapes suivantes :

    1. Répertoriez les scripts de contrôle d'exécution Apache.

    2. Renommez les scripts de contrôle d'exécution Apache.

    3. Vérifiez que tous les scripts associés à Apache ont été renommés.

    Remarque :

    l'exemple suivant convertit la première lettre du nom du script de contrôle d'exécution en minuscule. Vous pouvez toutefois renommer les scripts selon une procédure correspondant à vos habitudes administratives.


    # <userinput>ls -1 /etc/rc?.d/*apache</userinput>
/etc/rc0.d/K16apache
/etc/rc1.d/K16apache
/etc/rc2.d/K16apache
/etc/rc3.d/S50apache
/etc/rcS.d/K16apache

# <userinput>mv /etc/rc0.d/K16apache  /etc/rc0.d/k16apache

</userinput># <userinput>mv /etc/rc1.d/K16apache  /etc/rc1.d/k16apache</userinput>

# <userinput>mv /etc/rc2.d/K16apache  /etc/rc2.d/k16apache</userinput>

# <userinput>mv /etc/rc3.d/S50apache  /etc/rc3.d/s50apache</userinput>

# <userinput>mv /etc/rcS.d/K16apache  /etc/rcS.d/k16apache</userinput>



# <userinput>ls -1 /etc/rc?.d/*apache

</userinput>
/etc/rc0.d/k16apache/etc/rc1.d/k16apache/etc/rc2.d/k16apache/etc/rc3.d/s50apache/etc/rcS.d/k16apache

Pages de manuel

De nouvelles pages de manuel sont incluses pour chaque service de données fourni avec le logiciel Sun Cluster 3.0. Les nouvelles pages de manuel des services de données sont les suivantes : SUNW.apache(5), SUNW.dns(5), SUNW.iws(5), SUNW.nfs(5), SUNW.nsldap(5), SUNW.oracle_listener(5), SUNW.oracle_server(5), SUNW.HAStorage(5) et scalable_service(5). Ces pages décrivent les propriétés standard ou étendues utilisées par ces services de données.

Problèmes connus dans l'interface utilisateur graphique de Sun Management Center

Cette section décrit les problèmes connus dans le module Sun Cluster 3.0 de l'interface utilisateur graphique de Sun Management Center.

Certains types de serveurs Ultra ne sont pas reconnus par Sun Management Center

Symptômes

Confirmation du problème/début de solution

  1. Fermez la fenêtre Details (Détails).

  2. Dans la fenêtre Sun Management Center, sélectionnez File->Console Messages (Fichier->Messages console).

  3. Cliquez deux fois sur l'icône de dossier représentant le noeud de cluster non reconnu.

  4. Dans la fenêtre de messages de la console, vérifiez la présence d'une ligne ...family definition file missing for...

Solution

  1. Sur le serveur Sun Management Center, placez-vous dans le répertoire qui contient les fichiers de la famille.


    # cd /opt/SUNWsymon/classes/base/console/cfg

  2. Créez un lien symbolique vers le premier fichier family-j.x disponible.

    Par exemple, si la ligne de fichier manquant indique ...missing for sun4u-Sun-Ultra-450-family-j.x..., créez un lien sun4u-Sun-Enterprise-450-family-j.x vers sun4u-Sun-Ultra-450-family-j.x.


    # ln -s sun4u-Sun-Enterprise-450-family-j.x sun4u-Sun-Ultra-450-family-j.x

  3. Fermez la console, puis relancez-la.

Autre méthode pour déterminer les noms des liens symboliques

  1. Cliquez deux fois sur le nom de cluster non reconnu pour afficher une fenêtre contenant ses détails.

  2. Cliquez sur l'onglet Info (Infos).

  3. Recherchez l'entrée Entity Family (Famille d'entités) dans la table des propriétés.

    Comme cette valeur est probablement tronquée, conservez le pointeur un moment dans le champ. Le nom complet (par exemple, sun4u-Sun-Ultra-450) s'affiche dans l'info-bulle.

  4. Ajoutez -family-j.x pour déterminer le nom de lien à créer.