Cette rubrique présente les erreurs ou les omissions de la documentation, de l'aide en ligne ou des pages de manuel de la version Sun Cluster 3.2.
Guide de planification et d'administration des services de données Sun Cluster
Guide de Sun Cluster Data Service pour SAP Web Application Server
Cette rubrique présente les erreurs et omissions du Sun Cluster Concepts Guide for Solaris OS .
Dans la rubrique Sun Cluster Topologies for x86 du Sun Cluster Concepts Guide for Solaris OS, l'énoncé suivant n'est plus valide dans la version Sun Cluster 3.2 : "Sun Cluster constitué de systèmes x86 prend en charge des clusters à deux nœuds."
L'énoncé correct est le suivant : "Une configuration Sun Cluster composée de systèmes x86 prend en charge jusqu'à huit nœuds dans un cluster exécutant Oracle RAC ou jusqu'à quatre nœuds dans un cluster n'exécutant pas Oracle RAC."
Cette rubrique présente les erreurs et les omissions du Sun Cluster Software Guide d’installation pour le SE Solaris.
Si vous mettez à niveau un cluster qui exécute également le logiciel Sun Cluster Geographic Edition, d'autres étapes de préparation sont nécessaires avant de mettre à niveau le logiciel Sun Cluster. Ces étapes incluent l'arrêt de l'infrastructure Sun Cluster Geographic Edition. Reportez-vous alors au Chapitre 4, Upgrading the Sun Cluster Geographic Edition Software du Sun Cluster Geographic Edition Installation Guide dans le manuel Sun Cluster Geographic Edition Installation Guide . Ces procédures expliquent comment se reporter au guide d'installation du logiciel Sun Cluster pour le mettre à niveau.
Cette rubrique présente les erreurs et les omissions du Sun Cluster Data Services Planning and Administration Guide for Solaris OS .
Dans Resource Type Properties du Sun Cluster Data Services Planning and Administration Guide for Solaris OS, la description de la propriété de ressource Failover ne fait pas état d'une instruction relative à la prise en charge des services évolutifs dans les zones non globales. Cette prise en charge s'applique aux ressources pour lesquelles la propriété Failover du type de ressource est définie sur FALSE et la propriété Scalable de la ressource est définie sur TRUE. Cette combinaison des paramètres de propriété indique un service évolutif qui utilise une ressource SharedAddress pour procéder à l'équilibrage de charge réseau. Dans la version Sun Cluster 3.2, vous pouvez configurer un service évolutif de ce type dans un groupe de ressources s'exécutant dans une zone non globale. Cependant, vous ne pouvez pas configurer un service évolutif s'exécutant dans plusieurs zones non globales sur le même nœud.
Cette rubrique présente les erreurs et les omissions du Sun Cluster Data Service for MaxDB Guide for Solaris OS .
Sun Cluster Data Service pour MaxDB prend en charge les zones non globales sur les systèmes SPARC et x86. Les modifications suivantes doivent être apportées au guide de Sun Cluster Data Service pour MaxDB. Les étapes suivantes peuvent être effectuées sur un cluster configuré pour une exécution dans des zones globales. Si vous installez votre cluster pour une exécution dans des zones non globales, certaines des étapes indiquées ci-dessous peuvent être facultatives.
Sur chaque zone, vérifiez que toutes les ressources réseau sont présentes dans le fichier /etc/hosts afin d'éviter tout échec dû à la recherche de service de noms.
Sur chaque zone, créez une entrée pour le groupe MaxDB dans le fichier /etc/group, puis ajoutez les éventuels utilisateurs au groupe.
Sur chaque zone, créez une entrée pour l'ID utilisateur MaxDB.
Utilisez la commande suivante pour mettre à jour les fichiers /etc/passwd et /etc/shadow avec une entrée pour l'ID utilisateur.
# useradd -u uid -g group -d /sap-home maxdb user |
Créez des répertoires de point de montage dans les zones où MaxDB peut éventuellement être exécuté.
Configurez le fichier /etc/nsswitch.conf de sorte que Sun Cluster HA pour MaxDB démarre et s'arrête correctement en cas de commutation ou de basculement.
Sur chaque zone, mettez à jour le fichier /etc/services avec tous les ports MaxDB nécessaires obtenus des zones globales /etc/services. Cette étape peut être facultative pour MaxDB installé dans des zones non globales.
Copiez le fichier /etc/opt/sdb de la zone globale dans tous les nœuds de zone locale. Cette étape peut être facultative pour MaxDB installé dans des zones non globales.
Copiez le fichier /var/spool/sql de la zone globale dans tous les nœuds de zone locale. Cette étape peut être facultative pour MaxDB installé dans des zones non globales.
Sur les systèmes x86 uniquement, exécutez crle -64 -u -l /sapmnt/MaxDBSystemName/exe dans toutes les zones locales où MaxDB sera exécuté.
Cette rubrique présente les erreurs et les omissions du Sun Cluster Data Service for SAP Guide for Solaris OS .
Sun Cluster Data Service pour SAP prend en charge les zones non globales sur les systèmes SPARC et x86. Les modifications suivantes doivent être apportées au guide de Sun Cluster Data Service pour SAP. Les étapes suivantes peuvent être effectuées sur un cluster configuré pour une exécution dans des zones globales. Si vous installez votre cluster pour une exécution dans des zones non globales, certaines des étapes indiquées ci-dessous peuvent être facultatives.
Sur chaque zone, vérifiez que toutes les ressources réseau sont présentes dans le fichier /etc/hosts afin d'éviter tout échec dû à la recherche de service de noms.
Sur chaque zone, créez une entrée pour le groupe SAP dans le fichier /etc/group, puis ajoutez les éventuels utilisateurs au groupe.
Sur chaque zone, créez une entrée pour l'ID utilisateur SAP.
Utilisez la commande suivante pour mettre à jour les fichiers /etc/passwd et /etc/shadow avec une entrée pour l'ID utilisateur.
# useradd -u uid -g group -d /sap-home sap user |
Créez des répertoires de point de montage dans les zones où SAP peut éventuellement être exécuté.
Configurez le fichier /etc/nsswitch.conf de sorte que Sun Cluster HA pour SAP démarre et s'arrête correctement en cas de commutation ou de basculement.
Sur chaque zone, mettez à jour le fichier /etc/services avec tous les ports SAP nécessaires obtenus des zones globales /etc/services. Cette étape peut être facultative pour SAP installé dans des zones non globales.
Sur les systèmes x86 uniquement, exécutez crle -64 -u -l /sapmnt/SAPSystemName/exe dans toutes les zones locales où SAP sera exécuté.
Cette rubrique présente les erreurs et les omissions du Sun Cluster Data Service for SAP liveCache Guide for Solaris OS .
Sun Cluster Data Service pour SAP liveCache prend en charge les zones non globales sur les systèmes SPARC et x86. Les modifications suivantes doivent être apportées au guide de Sun Cluster Data Service pour SAP liveCache. Les étapes suivantes peuvent être effectuées sur un cluster configuré pour une exécution dans des zones globales. Si vous installez votre cluster pour une exécution dans des zones non globales, certaines des étapes indiquées ci-dessous peuvent être facultatives.
Sur chaque zone, vérifiez que toutes les ressources réseau sont présentes dans le fichier /etc/hosts afin d'éviter tout échec dû à la recherche de service de noms.
Sur chaque zone, créez une entrée pour le groupe SAP liveCache dans le fichier /etc/group, puis ajoutez les éventuels utilisateurs au groupe.
Sur chaque zone, créez une entrée pour l'ID utilisateur SAP liveCache.
Utilisez la commande suivante pour mettre à jour les fichiers /etc/passwd et /etc/shadow avec une entrée pour l'ID utilisateur.
# useradd -u uid -g group -d /sap-home sap user |
Créez des répertoires de point de montage dans les zones où SAP liveCache peut éventuellement être exécuté.
Configurez le fichier /etc/nsswitch.conf de sorte que Sun Cluster HA pour SAP liveCache démarre et s'arrête correctement en cas de commutation ou de basculement.
Sur chaque zone, mettez à jour le fichier /etc/services avec tous les ports SAP liveCache nécessaires obtenus des zones globales /etc/services. Cette étape peut être facultative pour SAP liveCache installé dans des zones non globales.
Copiez le fichier /etc/opt/sdb de la zone globale dans tous les nœuds de zone locale. Cette étape peut être facultative pour SAP liveCache installé dans des zones non globales.
Copiez le fichier /var/spool/sql de la zone globale dans tous les nœuds de zone locale. Cette étape peut être facultative pour SAP liveCache installé dans des zones non globales.
Sur les systèmes x86 uniquement, exécutez crle -64 -u -l /sapmnt/SAPSystemName/exe dans toutes les zones locales où SAP liveCache sera exécuté.
Cette rubrique présente les erreurs et les omissions du Sun Cluster Data Service for SAP Web Application Server Guide for Solaris OS .
Dans SAP 7.0 et NW2004SR1, lorsqu'une instance SAP est démarrée, le processus sapstartsrv est démarré par défaut. Le processus sapstartsrv n'est pas contrôlé par Sun Cluster HA pour SAP Web Application Server. Ainsi, lorsqu'une instance SAP est arrêtée ou échoue à cause de Sun Cluster HA pour SAP Web Application Server, le processus sapstartsrv n'est pas arrêté.
Pour ne pas démarrer le processus sapstartsrv au démarrage d'une instance SAP via Sun Cluster HA pour SAP Web Application, modifiez le script startsap. Renommez également le fichier /etc/rc3.d/S90sapinit en /etc/rc3.d/xxS90sapinit sur tous les nœuds Sun Cluster.
Sun Cluster Data Service pour SAP Web Application Server prend en charge les zones non globales sur les systèmes SPARC et x86. Les modifications suivantes doivent être apportées au guide de Sun Cluster Data Service pour SAP Web Application Server. Les étapes suivantes peuvent être effectuées sur un cluster configuré pour une exécution dans des zones globales. Si vous installez votre cluster pour une exécution dans des zones non globales, certaines des étapes indiquées ci-dessous peuvent être facultatives.
Sur chaque zone, vérifiez que toutes les ressources réseau sont présentes dans le fichier /etc/hosts afin d'éviter tout échec dû à la recherche de service de noms.
Sur chaque zone, créez une entrée pour le groupe SAP Web Application Server dans le fichier /etc/group, puis ajoutez les éventuels utilisateurs au groupe.
Sur chaque zone, créez une entrée pour l'ID utilisateur SAP Web Application Server.
Utilisez la commande suivante pour mettre à jour les fichiers /etc/passwd et /etc/shadow avec une entrée pour l'ID utilisateur.
# useradd -u uid -g group -d /sap-home sap user |
Créez des répertoires de point de montage dans les zones où SAP Web Application Server peut éventuellement être exécuté.
Configurez le fichier /etc/nsswitch.conf de sorte que Sun Cluster HA pour SAP démarre et s'arrête correctement en cas de commutation ou de basculement.
Sur chaque zone, mettez à jour le fichier /etc/services avec tous les ports SAP nécessaires obtenus des zones globales /etc/services. Cette étape peut être facultative pour SAP Web Application Server installé dans des zones non globales.
Sur les systèmes x86 uniquement, exécutez crle -64 -u -l /sapmnt/SAPSystemName/exe dans toutes les zones locales où SAP sera exécuté.
Suivez la procédure suivante pour configurer une ressource HAStoragePlus pour des zones non globales.
Les entrées du fichier /etc/vfstab des systèmes de fichiers de cluster doivent contenir le mot-clé global dans les options de montage.
Les binaires SAP rendus hautement disponibles via la ressource HAStoragePlus doivent être accessibles à partir des zones non globales.
Dans des zones non globales, les systèmes de fichiers utilisés par différentes ressources de différents groupes de ressources doivent se trouver dans une seule et même ressource HAStoragePlus d'un groupe de ressources évolutif. La liste de nœuds du groupe de ressources évolutif HAStoragePlus doit être un surensemble de listes de nœuds des groupes de ressources d'application composés de ressources dépendant des systèmes de fichiers. Les ressources d'application dépendant des systèmes de fichiers doivent disposer d'un ensemble de dépendances de ressources à la ressource HAStoragePlus. Le groupe de ressources d'application dépendant doit également disposer d'un ensemble d'affinités de groupe de ressources positives au groupe de ressources évolutif HAStoragePlus.
Sur un nœud du cluster, prenez le rôle de superutilisateur ou un rôle dôté de l'autorisation RBAC solaris.cluster.modify.
Créez le groupe de ressources évolutif avec des zones non globales contenant la ressource HAStoragePlus.
# clresourcegroup create \ -p Maximum_primaries=m\ -p Desired_primaries=n\ [-n node-zone-list] hasp-resource-group |
Indique le nombre maximum de principaux actifs du groupe de ressources.
Indique le nombre de principaux actifs sur lesquels le groupe de ressources doit tenter un démarrage.
Dans la liste de nœuds d'un groupe de ressources HAStoragePlus, indique la liste de noms de paires nodename :zonename comme liste de nœuds du groupe de ressources HAStoragePlus sur lesquelles les instances SAP peuvent être en ligne.
Indique le nom du groupe de ressources évolutif à ajouter. Ce nom doit commencer par un caractère ASCII.
Enregistrez le type de ressource de HAStoragePlus.
# clresourcetype register HAStoragePlus |
Créez la ressource hasp HAStoragePlus et définissez les points de montage du système de fichiers SAP et les chemins d'accès aux périphériques globaux.
# clresource create -g hasp-resource-group -t SUNW.HAStoragePlus \ -p GlobalDevicePaths=/dev/global/dsk/d5s2,dsk/d6 \ -p affinityon=false -p FilesystemMountPoints=/sapmnt/JSC,/usr/sap/trans,/usr/sap/JSC hasp-resource |
Indique le nom du groupe de ressources.
Contient les valeurs suivantes :
Nom de groupe de périphériques globaux, sap-dg, dsk/d5 par exemple.
Chemin d'accès aux périphériques globaux, /dev/global/dsk/d5s2, /dev/md/sap-dg/dsk/d6 par exemple.
Contient les valeurs suivantes :
Points de montage de systèmes de fichiers locaux ou de cluster, /local/mirrlogA,/local/mirrlogB,/sapmnt/JSC,/usr/sap/JSC par exemple.
La ressource HAStoragePlus est créée à l'état actif.
Enregistrez le type de ressource de l'application SAP.
# clresourcetype register resource-type |
Indique le nom du type de ressource à ajouter. Pour plus d'informations, reportez-vous à Produits pris en charge.
Créez un groupe de ressources SAP.
# clresourcegroup create [-n node-zone-list] -p RG_affinities=++hastorageplus-rg resource-group-1 |
Indique le groupe de ressources de services SAP.
Ajoutez la ressource d'application SAP à resource-group-1 et définissez sa dépendance à hastorageplus-1.
# clresource create -g resource-group-1 -t SUNW.application \ [-p "extension-property[{node-specifier}]"=value, ?] \ -p Resource_dependencies=hastorageplus-1 resource |
Mettez en ligne le groupe de ressources de basculement.
# clresourcegroup online resource-group-1 |
Cette rubrique présente les erreurs et omissions du Sun Cluster System Administration Guide for Solaris OS .
Suivez cette procédure pour exécuter une application externe au cluster à des fins de test.
Déterminez si le périphérique de quorum est utilisé dans le méta-ensemble Solaris Volume Manager et s'il utilise des réservations scsi2 ou scsi3.
# clquorum show |
Si le périphérique de quorum fait partie du méta-ensemble Solaris Volume Manager, ajoutez-en un nouveau n'en faisant pas partie que vous passerez ensuite en mode non-cluster.
# clquorum add did |
Supprimez l'ancien périphérique de quorum.
# clqorum remove did |
Si le périphérique de quorum utilise une réservation scsi2, purgez-la de l'ancien périphérique de quorum et vérifiez qu'il n'en existe pas d'autres.
# /usr/cluster/lib/sc/pgre -c pgre_scrub -d /dev/did/rdsk/dids2 # /usr/cluster/lib/sc/pgre -c pgre_inkeys -d /dev/did/rdsk/dids2 |
Évacuez le nœud à initialiser en mode non-cluster.
# clresourcegroup evacuate -n targetnode |
Mettez hors ligne le ou les groupes de ressources contenant des ressources HAStorage ou HAStoragePlus ainsi que des périphériques et systèmes de fichiers affectés par le méta-ensemble que vous souhaiterez passer en mode non-cluster.
# clresourcegroup offline resourcegroupname |
Désactivez toutes les ressources du groupe de ressources que vous avez mis hors ligne.
# clresource disable resourcename |
Basculez les groupes de ressources en mode non géré.
# clresourcegroup unmanage resourcegroupname |
Mettez hors ligne le ou les groupes de périphériques correspondants.
# cldevicegroup offline devicegroupname |
Désactivez le ou les groupes de périphériques.
# cldevicegroup disable devicegroupname |
Initialisez le nœud passif en mode non-cluster.
# reboot -x |
Vérifiez que le processus d'initialisation est terminé sur le nœud passif avant de poursuivre.
Solaris 9
L'invite de connexion apparaît uniquement une fois le processus d'initialisation terminé. Aucune action n'est requise.
Solaris 10
# svcs -x |
Déterminez s'il existe des réservations scsi3 sur les disques du ou des méta-ensembles. Exécutez les commandes suivantes sur tous les disques des méta-ensembles.
# /usr/cluster/lib/sc/scsi -c inkeys -d /dev/did/rdsk/dids2 |
En cas de réservations scsi3 sur les disques, purgez-les.
# /usr/cluster/lib/sc/scsi -c scrub -d /dev/did/rdsk/dids2 |
Prenez le méta-ensemble sur le nœud évacué.
# metaset -s name -C take -f |
Montez le ou les systèmes de fichiers contenant le périphérique défini sur le méta-ensemble.
# mount device mountpoint |
Démarrez l'application et procédez au test souhaité. Une fois le test terminé, arrêtez l'application.
Réinitialisez le nœud et attendez que le processus d'initialisation soit terminé.
# reboot |
Mettez en ligne le ou les groupes de périphériques.
# cldevicegroup online -e devicegroupname |
Démarrez le ou les groupes de ressources.
# clresourcegroup online -eM resourcegroupname |
Sun Cluster prend en charge le filtre IP Solaris avec les restrictions suivantes :
Seuls les services de données de basculement sont pris en charge.
Sun Cluster ne prend pas en charge le filtrage IP avec des services de données évolutifs.
Seul le filtrage sans état est pris en charge.
Le routage NAT n'est pas pris en charge.
L'utilisation de NAT pour la conversion d'adresses locales est possible. La conversion NAT réécrit des paquets à la volée et est donc transparente pour le logiciel du cluster.
Dans le fichier /etc/iu.ap, modifiez les entrées NIC publiques afin de répertorier clhbsndr pfil comme liste de modules.
pfil doit être le dernier module de la liste.
Si vous disposez du même type d'adaptateur pour les réseaux privé et public, les modifications apportées au fichier /etc/iu.ap passeront pfil dans le réseau privé. Le module de transport du cluster supprimera toutefois automatiquement tous les modules indésirables pendant la création et pfil sera donc supprimé du réseau privé.
Pour garantir le bon fonctionnement du filtre IP en mode non-cluster, mettez à jour le fichier /etc/ipf/pfil.ap.
Les mises à jour du fichier /etc/iu.ap sont légèrement différentes. Pour en savoir plus, consultez la documentation relative au filtre IP.
Réinitialisez tous les nœuds concernés.
Vous pouvez initialiser les nœuds de manière progressive.
Ajoutez des règles de filtre au fichier /etc/ipf/ipf.conf sur tous les nœuds concernés. Pour plus d'informations sur la syntaxe des règles de filtre IP, reportez-vous à la page de manuel ipf(4)
N'oubliez pas les directives et exigences suivantes lors de l'ajout de règles de filtre aux nœuds Sun Cluster.
Sun Cluster bascule des adresses réseau d'un nœud à un autre. Aucun code ou procédure spécifique n'est requis lors du basculement.
Toutes les règles de filtrage faisant référence à des adresses IP de noms d'hôtes logiques et de ressources d'adresse partagée doivent être identiques sur tous les nœuds de cluster.
Les règles d'un nœud passif feront référence à une adresse IP inexistante. Cette règle fait partie de l'ensemble de règles actif du filtre IP et s'appliquera lorsque le nœud recevra l'adresse après un basculement.
Toutes les règles de filtrage doivent être identiques pour tous les NIC d'un même groupe IPMP. En d'autres termes, si une règle est spécifique à une interface, elle doit également exister pour toutes les autres interfaces du même groupe IPMP.
Activez le service SMF ipfilter.
# svcadm enable /network/ipfilter:default |
Cette rubrique présente les erreurs et omissions du Sun Cluster Data Services Developer’s Guide for Solaris OS .
Dans Resource Type Properties du Sun Cluster Data Services Developer’s Guide for Solaris OS, la description de la propriété de ressource Failover ne fait pas état d'une instruction relative à la prise en charge des services évolutifs dans les zones non globales. Cette prise en charge s'applique aux ressources pour lesquelles la propriété Failover du type de ressource est définie sur FALSE et la propriété Scalable de la ressource est définie sur TRUE. Cette combinaison des paramètres de propriété indique un service évolutif qui utilise une ressource SharedAddress pour procéder à l'équilibrage de charge réseau. Dans la version Sun Cluster 3.2, vous pouvez configurer un service évolutif de ce type dans un groupe de ressources s'exécutant dans une zone non globale. Cependant, vous ne pouvez pas configurer un service évolutif s'exécutant dans plusieurs zones non globales sur le même nœud.
La description de la modification du comportement des expirations de méthodes dans Sun Cluster 3.2 est manquante. Si un rappel de la méthode RGM expire, le processus est interrompu à l'aide du signal SIGABRT et non à l'aide du signal SIGTERM. Cela entraîne la génération d'un fichier core par tous les membres du groupe de processus.
Évitez d'écrire une méthode de service de données créant un groupe de processus. Si votre méthode de service de données n'a pas besoin de créer un tel groupe, développez un gestionnaire de signal pour les signaux SIGTERM et SIGABRT. Développez les gestionnaires de signaux pour transférer le signal SIGTERM ou SIGABRT vers le groupe de processus enfant avant que le gestionnaire de signal ne termine le processus parent. Cela augmente la probabilité que tous les processus générés de façon dynamique par la méthode seront correctement terminés.
Dans Setting Up the Development Environment for Writing a Data Service du Sun Cluster Data Services Developer’s Guide for Solaris OS, une remarque indique que le développeur ou la distribution complète du groupe de logiciels Solaris sont requis. Cette instruction concerne l'ordinateur de développement, mais comme elle est placée après une instruction sur le test du service de données sur un cluster, elle risque d'être mal interprétée comme une exigence relative au cluster sur lequel s'exécute le service de données.
Cette section présente les erreurs et les omissions du Sun Cluster Quorum Server User’s Guide.
Les exigences et les directives suivantes portant sur l'installation manquent ou sont confuses :
La configuration logicielle requise de Solaris pour le logiciel Sun Cluster s'applique également au logiciel Quorum Server.
Les plates-formes matérielles prises en charge pour un serveur de quorum sont identiques à celles d'un nœud de cluster.
Un serveur de quorum ne doit pas être configuré sur la même plate-forme matérielle et logicielle que le ou les clusters auxquels il fournit le quorum. Par exemple, un ordinateur x86 exécutant SE Solaris peut être configuré en tant que serveur de quorum pour un cluster SPARC exécutant SE Solaris 10.
Un serveur de quorum peut être configuré sur un nœud de cluster pour fournir le quorum aux clusters autres que celui auquel le nœud appartient. Cependant, un serveur de quorum configuré sur un nœud de cluster n'est pas hautement disponible.
Cette rubrique présente les erreurs, omissions et ajouts dans les pages de manuel de Sun Cluster.
Le synopsis révisé et les rubriques d'options ajoutées suivants de la page de manuel ccp(1M) présentent l'ajout de la prise en charge de shell sécurisé aux utilitaires du panneau de contrôle du cluster (CCP) :
SYNOPSIS
$CLUSTER_HOME/bin/ccp [-s] [-l username] [-p ssh-port] {clustername | nodename} |
OPTIONS
Les options suivantes sont prises en charge :
Indique le nom d'utilisateur pour la connexion ssh. Cette option est transmise à l'utilitaire cconsole, crlogin ou cssh lorsqu'il est démarré à partir du CCP. L'utilitaire ctelnet ignore cette option.
Si l'option -l n'est pas spécifiée, le nom d'utilisateur à l'origine du démarrage du CCP s'applique.
Indique le numéro de port de shell sécurisé à utiliser. Cette option est transmise à l'utilitaire cssh lorsqu'il est démarré à partir du CCP. Les utilitaires cconsole, crlogin et ctelnet ignorent cette option.
Si l'option -p n'est pas spécifiée, le numéro de port par défaut, 22, est utilisé pour les connexions sécurisées.
Indique l'utilisation de connexions de shell sécurisé pour les consoles de nœuds au lieu de connexions telnet. Cette option est transmise à l'utilitaire cconsole lorsqu'il est démarré à partir du CCP. Les utilitaires crlogin, cssh et ctelnet ignorent cette option.
Si l'option -s n'est pas spécifiée, l'utilitaire cconsole utilise des connexions telnet avec les consoles.
Pour remplacer l'option -s, décochez Utiliser SSH dans le menu Options de l'interface graphique utilisateur cconsole.
Le synopsis révisé et les rubriques d'options ajoutées suivants des pages de manuel cconsole, crlogin, cssh et ctelnet présentent l'ajout de la prise en charge de shell sécurisé aux utilitaires du panneau de contrôle du cluster :
SYNOPSIS
$CLUSTER_HOME/bin/cconsole [-s] [-l username] [clustername… | nodename…] $CLUSTER_HOME/bin/crlogin [-l username] [clustername… | nodename…] $CLUSTER_HOME/bin/cssh [-l username] [-p ssh-port] [clustername… | nodename…] $CLUSTER_HOME/bin/ctelnet [clustername… | nodename…] |
DESCRIPTION
Cet utilitaire établit des connexions de shell sécurisé directement avec les nœuds de cluster.
OPTIONS
Indique le nom d'utilisateur ssh pour les connexions à distance. Cette option est valide avec les commandes cconsole, crlogin et cssh.
La valeur d'argument est mémorisée afin que les clusters et nœuds spécifiés ultérieurement utilisent le même nom d'utilisateur lors des connexions.
Si l'option -l n'est pas spécifiée, le nom d'utilisateur à l'origine de la commande s'applique.
Indique le numéro de port de shell sécurisé à utiliser. Cette option est valide avec la commande cssh.
Si l'option -p n'est pas spécifiée, le numéro de port par défaut, 22, est utilisé pour les connexions sécurisées.
Indique l'utilisation de connexions de shell sécurisé au lieu de connexions telnet pour les consoles de nœuds. Cette option est valide avec la commande cconsole.
Si l'option -s n'est pas spécifiée, l'utilitaire utilise des connexions telnet avec les consoles.
Pour remplacer l'option -s via l'interface utilisateur graphique cconsole, décochez Utiliser SSH dans le menu Options.
La description de la sous-commande remove sous-entend qu'elle ne fonctionne pas dans certaines conditions. En fait, elle s'exécute lorsque ces conditions sont réunies, mais les résultats peuvent nuire au cluster. Ci-après figure une description plus précise des exigences et du comportement de la sous-commande remove :
Pour supprimer un nœud d'un cluster, observez les directives suivantes. Si vous ne le faites pas, la suppression d'un nœud risque de compromettre le quorum du cluster.
Annulez la configuration du nœud à supprimer des périphériques de quorum à moins que vous ne spécifiiez également l'option -f.
Vérifiez que le nœud à supprimer n'est pas un membre de cluster actif.
Ne supprimez pas un nœud d'un cluster à trois nœuds sauf si au moins un périphérique de quorum partagé est configuré.
La commande clnode remove tente de supprimer un sous-ensemble de références au nœud dans la base de données de configuration de cluster. Si l'option -f est également spécifiée, la sous-commande tente de supprimer toutes les références au nœud.
Avant de pouvoir utiliser la commande clnode remove pour supprimer un nœud du cluster, vous devez d'abord utiliser la commande claccess add pour ajouter le nœud dans la liste d'authentification du cluster s'il n'y figure pas déjà. Utilisez la commande claccess list ou claccess show pour afficher la liste d'authentification actuelle du cluster. Ensuite, à des fins de sécurité, utilisez la commande claccess deny-all pour empêcher tout nœud du cluster d'accéder à la configuration du cluster. Pour plus d'informations, reportez-vous à la page de manuel claccess(1CL).
L'option suivante manque dans la page de manuel clresource(1CL) :
Indique que la commande fonctionne sur des ressources dont le groupe est suspendu si vous spécifiez l'opérande +. Si vous ne spécifiez pas l'option u lorsque vous spécifiez l'opérande +, la commande ignore toutes les ressources dont le groupe est suspendu.
L'option -u est valide si vous spécifiez l'opérande + pour les sous-commandes clear, disable, enable, monitor, set et unmonitor.
La description de l'opérande + doit indiquer que, lorsqu'elle est utilisée avec la sous-commande clear, disable, enable, monitor, set ou unmonitor, la commande ignore toutes les ressources dont le groupe est suspendu, sauf si vous spécifiez également l'option -u.
Les exemples proposés dans les définitions des opérandes + et - pour les options -p, -x et -y sont incorrects. Ces définitions devraient se lire ainsi :
Ajoute une ou des valeurs à une valeur du tableau de chaînes. Seule la sous-commande définie accepte cet opérateur. Vous pouvez le spécifier uniquement pour les propriétés acceptant les listes de valeurs de type chaîne, par exemple Resource_dependencies.
Supprime une ou des valeurs d'une valeur du tableau de chaînes. Seule la sous-commande définie accepte cet opérateur. Vous pouvez le spécifier uniquement pour les propriétés acceptant les listes de valeurs de type chaîne, par exemple Resource_dependencies.
La syntaxe et la description de la sous-commande evacuate indiquent de façon incorrecte que vous pouvez vider plusieurs nœuds ou zones dans un même appel de commande. En fait, vous ne pouvez spécifier qu'un seul nœud ou qu'une seule zone dans la commande evacuate.
L'option suivante manque dans la page de manuel clresourcegroup(1CL) :
Indique que la commande fonctionne sur des groupes de ressources suspendus si vous spécifiez l'opérande +. Si vous ne spécifiez pas l'option u lorsque vous spécifiez l'opérande +, la commande ignore tous les groupes de ressources suspendus.
L'option -u est valide lorsque l'opérande + est indiqué pour les sous-commandes add-node, manage, offline, online, quiesce, remaster, remove-node, restart, set, switch et unmanage.
La description de l'opérande + devrait indiquer que, lorsqu'elle est utilisée avec la sous-commande add-node, manage, offline, online, quiesce, remaster, remove-node, restart, set, switch ou unmanage, la commande ignore tous les groupes de ressources suspendus sauf si vous spécifiez également l'option -u.
L'utilisation de la propriété Network_resources_used a changé dans la version Sun Cluster 3.2. Si vous n'assignez pas de valeur à cette propriété, sa valeur est automatiquement mise à jour par le RGM, en fonction de la définition des propriétés des dépendances de ressources. Vous n'avez pas besoin de la définir directement. En fait, vous devez définir les propriétés Resource_dependencies, Resource_dependencies_offline_restart, Resource_dependencies_restartet Resource_dependencies_weak.
Pour conserver la compatibilité avec les versions précédentes du logiciel Sun Cluster, vous pouvez encore définir directement la valeur de la propriété Network_resources_used. Le cas échéant, la valeur de la propriété Network_resources_used n'est plus dérivée des paramètres des propriétés des dépendances de ressources.
Si vous ajoutez un nom de ressource à la propriété Network_resources_used, il est également ajouté automatiquement à la propriété Resource_dependencies. La seule façon de supprimer cette dépendance consiste à la supprimer de la propriété Network_resources_used. Si vous ne savez pas si une dépendance de ressource réseau a été ajoutée, à l'origine, à la propriété Resource_dependencies ou à la propriété Network_resources_used, supprimez-la dans ces deux propriétés. Par exemple, la commande suivante supprime une dépendance r1 de la ressource réseau r2, que cette dépendance ait été ajoutée à la propriété Network_resources_used ou à la propriété Resource_dependencies :
# clresource set -p Network_resources_used-=r2 -p Resource_dependencies-=r2 r1 |
La page de manuel r_properties(5) contient les descriptions incorrectes des propriétés Resource_dependencies, Resource_dependencies_offline_restart , Resource_dependencies_restart et Resource_dependencies_weak. Pour obtenir leurs descriptions correctes, reportez-vous à Resource Properties du Sun Cluster Data Services Developer’s Guide for Solaris OS.
Une instruction relative à la prise en charge des services évolutifs dans les zones non globales manque dans la description de la propriété de ressource Scalable. Cette prise en charge s'applique aux ressources pour lesquelles la propriété Failover du type de ressource est définie sur FALSE et la propriété Scalable de la ressource est définie sur TRUE. Cette combinaison des paramètres de propriété indique un service évolutif qui utilise une ressource SharedAddress pour procéder à l'équilibrage de charge réseau. Dans la version Sun Cluster 3.2, vous pouvez configurer un service évolutif de ce type dans un groupe de ressources s'exécutant dans une zone non globale. Cependant, vous ne pouvez pas configurer un service évolutif s'exécutant dans plusieurs zones non globales sur le même nœud.
La description de la propriété du type de ressource Failover contient une instruction incorrecte relative à la prise en charge des services évolutifs dans des zones non globales dans Sun Cluster 3.2. Cette prise en charge s'applique aux ressources pour lesquelles la propriété Failover du type de ressource est définie sur FALSE et la propriété Scalable de la ressource est définie sur TRUE.
Incorrect : vous ne pouvez pas utiliser un service évolutif de ce type dans des zones.
Correct : vous pouvez configurer un service évolutif de ce type dans un groupe de ressources qui s'exécute dans une zone non globale, Cependant, vous ne pouvez pas configurer un service évolutif s'exécutant dans plusieurs zones non globales sur le même nœud.
Les informations suivantes sont ajoutées à la rubrique Description de la page de manuel serialport(4) :
Pour établir des connexions de shell sécurisé aux consoles de nœuds, indiquez dans le fichier /etc/serialports le nom du périphérique d'accès à la console et le numéro de port de shell sécurisé de chaque nœud. Si vous utilisez la configuration de shell sécurisé par défaut sur le périphérique d'accès à la console, indiquez le numéro de port 22.
L'instruction selon laquelle, sur SE Solaris 10, le protocole CRNP s'exécute uniquement dans la zone globale, manque dans la page de manuel SUNW.Event(5).