Ce document fournit les informations suivantes relatives au logiciel SunTM Cluster 3.2.
Cette section présente les nouvelles fonctions et fonctionnalités ainsi que les nouveaux produits pris en charge par le logiciel Sun Cluster 3.2. Elle présente également les restrictions appliquées dans cette version.
Cette section décrit chacune des nouvelles fonctions suivantes du logiciel Sun Cluster 3.2.
Amélioration de l'intégration et de l'administration d'Oracle RAC 10g
Prise en charge des services de l'outil de gestion des services par Sun Cluster
Prise en charge d'étiquettes de disques multi-téraoctets et EFI (Extensible Firmware Interface)
Création automatique de groupes IPMP à plusieurs adaptateurs à l'aide de la commande scinstall
Prise en charge de shell sécurisé pour le logiciel du panneau de contrôle du cluster
Prise en charge de filtre IP pour les services de basculement
La nouvelle interface de ligne de commande de Sun Cluster contient une commande distincte par type d'objet du cluster et utilise des noms de sous-commande et des lettres d'option cohérents. Le nouveau jeu de commandes de Sun Cluster prend également en charge les noms de commande courts et longs. La sortie de commande améliore les messages d'aide et d'erreur ainsi que la lisibilité des rapports d'état et de configuration. Par ailleurs, certaines commandes incluent des options d'exportation et d'importation avec l'utilisation de fichiers de configuration XML transférables. Ces options vous permettent de répliquer tout ou partie de la configuration du cluster, ce qui accélère le clonage partiel ou complet de la configuration. Pour plus d'informations, reportez-vous à la page de manuel Intro(1CL).
L'installation et la configuration du package Sun Cluster Oracle RAC sont désormais intégrées aux procédures de Sun Cluster. Les propriétés et les types de ressources nouveaux, propres à Oracle RAC peuvent être utilisés pour renforcer le contrôle.
La facilité de gestion étendue d'Oracle RAC, qui est fournie par les types de ressources ScalDeviceGroup et ScalMountPoint, facilite la configuration d'Oracle RAC dans des configurations Sun Cluster et améliore la possibilité d'établir des diagnostics et la disponibilité. Pour plus d'informations, reportez-vous au Sun Cluster Data Service for Oracle RAC Guide for Solaris OS.
Sun Cluster fournit de nouveaux assistants de configuration des services de données qui simplifient la configuration des applications couramment utilisées par le biais de la découverte automatique des choix des paramètres et de leur validation immédiate. Ces assistants sont fournis dans les deux formats suivants :
IG de Sun Cluster Manager
Interface de ligne de commande clsetup
Les services de données suivants sont pris en charge dans l'IG de Sun Cluster Manager :
HA-Oracle
Oracle RAC
HA-NFS
HA-Apache, toutes les versions fournies avec le logiciel Solaris
HA-SAP
L'interface de ligne de commande clsetup prend en charge toutes les applications gérées par Sun Cluster Manager.
Pour plus d'informations, reportez-vous à la documentation Sun Cluster de chacun des services de données pris en charge.
Le logiciel Sun Cluster permet maintenant d'utiliser une plage réduite d'adresses IP pour son interconnexion privée. Par ailleurs, vous pouvez maintenant personnaliser l'adresse de base IP et sa plage avant ou après son installation.
Ces modifications apportées au schéma d'adressage IP facilitent l'intégration des environnements Sun Cluster aux réseaux existants avec des espaces d'adressage limités ou réglementés. Pour plus d'informations, reportez-vous à How to Change the Private Network Address or Address Range of an Existing Cluster du Sun Cluster System Administration Guide for Solaris OS.
Le logiciel Sun Cluster est désormais étroitement intégré à l'outil de gestion des services (SMF) de SE Solaris 10 et permet l'encapsulation des applications contrôlées par SMF dans le modèle de gestion des ressources Sun Cluster. La gestion locale du cycle de vie au niveau des services est toujours effectuée par l'outil SMF, alors que le traitement des échecs au niveau du cluster pour toutes les ressources (nœud, stockage) est exécuté par le logiciel Sun Cluster.
Le déplacement des applications d'un environnement SE Solaris 10 à un seul nœud à un environnement Sun Cluster à plusieurs nœuds augmente la disponibilité tout en nécessitant un minimum d'effort. Pour plus d'informations, reportez-vous à Enabling Solaris SMF Services to Run With Sun Cluster du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
Cette nouvelle fonctionnalité permet de personnaliser le protocole de séparation par défaut. Les protocoles pouvant être choisis sont les protocoles SCSI-3, SCSI-2 ou la détection par périphérique.
Cette flexibilité permet l'utilisation par défaut du protocole SCSI-3, plus récent, pour une meilleure prise en charge du multiacheminement, une intégration plus facile au stockage non Sun et des délais de récupération plus courts sur des supports de stockage plus récents tout en continuant de gérer le comportement de Sun Cluster 3.0 ou 3.1 et le protocole SCSI-2 pour les périphériques plus anciens. Pour plus d'informations, reportez-vous à Administering the SCSI Protocol Settings for Storage Devices du Sun Cluster System Administration Guide for Solaris OS.
Une nouvelle option de périphérique de quorum est désormais disponible dans le logiciel Sun Cluster. Au lieu d'utiliser un disque partagé et des protocoles de réservation SCSI, vous pouvez maintenant utiliser un serveur Solaris hors du cluster pour exécuter un module de serveur quorum qui prend en charge un protocole de réservation atomique via TCP/IP. Cette prise en charge accélère la durée de basculement tout en réduisant les coûts de déploiement : elle supprime le besoin d'utiliser un disque quorum partagé pour tout scénario dans lequel un quorum est requis (deux nœuds) ou souhaité. Pour plus d'informations, reportez-vous au Sun Cluster Quorum Server User’s Guide.
À présent, vous pouvez configurer le logiciel Sun Cluster pour redémarrer automatiquement un nœud si tous ses chemins aux disques partagés ont échoué. La plus grande rapidité de la réaction en cas de grave échec de chemin de disque améliore la disponibilité. Pour plus d'informations, reportez-vous à Administering Disk-Path Monitoring du Sun Cluster System Administration Guide for Solaris OS.
Les points de montage de HAStoragePlus sont créés automatiquement en cas d'échec du montage. Cette fonction élimine les cas de pannes, améliorant ainsi la disponibilité de l'environnement.
Le logiciel Sun Cluster prend désormais en charge les services de données suivants dans les zones non globales Solaris.
Service de données Sun Cluster pour Apache
Service de données Sun Cluster pour Apache Tomcat
Service de données Sun Cluster pour DHCP
Service de données Sun Cluster pour Domain Name Service (DNS)
Service de données Sun Cluster pour Kerberos
Service de données Sun Cluster pour mySQL
Service de données Sun Cluster pour N1 Grid Service Provisioning Server
Service de données Sun Cluster pour Oracle
Service de données Sun Cluster pour Oracle Application Server
Service de données Sun Cluster pour PostgreSQL
Service de données Sun Cluster pour Samba
Service de données Sun Cluster pour Sun Java System Application Server
Service de données Sun Cluster pour Sun Java System Message Queue Server
Service de données Sun Cluster pour Sun Java System Web Server
Cette prise en charge permet de combiner les avantages des applications offerts par les zones Solaris et d'augmenter la disponibilité du logiciel Sun Cluster. Pour plus d'informations, reportez-vous à la documentation Sun Cluster des services de données appropriés.
ZFS est pris en charge en tant que système de fichiers local hautement disponible dans la version Sun Cluster 3.2. ZFS avec le logiciel Sun Cluster propose une solution de système de fichiers haut de gamme alliant haute disponibilité, intégrité de données, performance et évolutivité répondant aux besoins des environnements les plus exigeants.
Des améliorations sont continuellement apportées au système de fichiers ZFS afin d'optimiser les performances pour toutes les charges de travail, notamment les transactions des bases de données. Assurez-vous d'avoir installé les tout derniers patchs ZFS et vérifiez que votre configuration est optimisée pour votre type de charge de travail spécifique.
Les clusters de campus Sun Cluster prennent désormais en charge la réplication basée sur le contrôleur HDS TrueCopy, permettant la gestion automatisée des configurations TrueCopy. Le logiciel Sun Cluster gère automatiquement et en toute transparence le passage au site campus secondaire en cas de basculement, réduisant ainsi les sources d'erreur de cette procédure et améliorant ce faisant la disponibilité globale de la solution. Cette nouvelle infrastructure de réplication des données distante permet au logiciel Sun Cluster de prendre en charge de nouvelles configurations pour les clients qui effectuent la normalisation d'une infrastructure de réplication particulière, comme TrueCopy, et pour les sites sur lesquels la réplication d'hôte n'est pas une solution viable en raison de la distance ou de l'incompatibilité des applications.
Cette nouvelle combinaison améliore la disponibilité et réduit la complexité tout en diminuant les coûts. Le logiciel Sun Cluster peut utiliser l'infrastructure de réplication de client TrueCopy existante, limitant ainsi le recours à d'autres solutions de réplication.
Les clusters de campus basés sur des spécifications prennent désormais en charge une large gamme de configurations à distance. Ces clusters prennent en charge ces configurations en requérant une conformité aux taux de latence et d'erreur plutôt qu'à un ensemble strict de distances et de composants.
Pour plus d'informations, reportez-vous à Chapitre 7, Campus Clustering With Sun Cluster Software du Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS.
Les configurations de Sun Cluster prennent désormais en charge des disques ayant une capacité supérieure à 1 To qui utilisent un nouveau format de disque EFI. Ce format est requis pour les disques multi-téraoctets, mais il peut également être utilisé avec des disques de capacité moindre. Cette nouvelle fonctionnalité étend les configurations de Sun Cluster prises en charge aux environnements ayant des exigences de stockage haut de gamme.
VERITAS Volume Manager et File System, éléments de VERITAS Storage Foundation 5.0, sont désormais pris en charge sur des plates-formes SPARC ainsi que VERITAS Volume Manager 4.1 avec SE Solaris 10 sur les plates-formes x86/x64.
VERITAS Volume Replicator (VVR) 5.0 et VERITAS Fast Mirror Resynchronization (FMR) 4.1 et 5.0, éléments de VERITAS FlashSnap, peuvent être utilisés dans des environnements Sun Cluster sur des plates-formes SPARC.
La gestion des quotas peut maintenant être utilisée avec HAStoragePlus sur des systèmes de fichiers UFS locaux pour un meilleur contrôle de la consommation des ressources.
Le logiciel Sun Cluster améliore l'utilisation des déploiements d'Oracle comprenant le logiciel de réplication des données DataGuard. Les clients peuvent désormais spécifier une base de données HA-Oracle dans une configuration Oracle DataGuard en tant que site principal ou de réserve. Cette base de données secondaire peut être une réserve logique ou physique. Pour plus d'informations, reportez-vous au manuel Sun Cluster Data Service for Oracle Guide for Solaris OS .
Lorsqu'un agent HA-Oracle gère une base de données de réserve, il n'en contrôle que le démarrage, l'arrêt et le suivi. L'agent ne relance pas la récupération de la base de données de réserve en cas d'échec sur un autre nœud.
Grâce à cette nouvelle fonction swap du logiciel, la mise à niveau est grandement simplifiée. Vous pouvez effectuer la mise à niveau d'un composant de la pile du logiciel et du logiciel Sun Cluster en une étape : le système d'exploitation Solaris, le logiciel Sun Cluster, les systèmes de fichiers, les gestionnaires de volumes, les applications et les services de données. Cette automatisation réduit le risque d'erreurs humaines pouvant se produire lors de la mise à niveau du cluster ainsi que les interruptions de service d'une mise à niveau de cluster standard.
Vous pouvez désormais utiliser la méthode Live Upgrade avec le logiciel Sun Cluster. Elle diminue les interruptions système d'un nœud pendant la mise à niveau ainsi que les redémarrages superflus, réduisant ainsi la maintenance requise lorsque le service court un risque.
Au moment de la publication, Live Upgrade peut être utilisé uniquement si votre installation Sun Cluster utilise Solaris Volume Manager pour gérer le stockage ou les groupes de disques. Actuellement, Live Upgrade ne prend pas en charge VxVM. Pour plus d'informations, reportez-vous à Mise à niveau.
Toute méthode Live Upgrade appliquée de Solaris 8 vers Solaris 9 nécessite l'application du patch SVM 116669-18 avant le redémarrage à partir de la racine secondaire.
L'installation de Sun Cluster Manager, l'IG de gestion de Sun Cluster, est maintenant facultative. Cette modification supprime l'accès Web au cluster afin de respecter les règles de sécurité potentielles. Reportez-vous à Installation de la structure de Sun Cluster et des packages du logiciel du service de données du Sun Cluster Software Guide d’installation pour le SE Solaris pour plus d'informations sur la désélection de Sun Cluster Manager lors de l'installation.
Le logiciel Sun Cluster comprend un nouveau mécanisme d'événement SNMP Sun Cluster ainsi qu'une nouvelle MIB SNMP. Ces nouvelles fonctionnalités permettent aux applications tierces de gestion SNMP de s'enregistrer directement auprès du logiciel Sun Cluster et de recevoir des notifications en temps voulu des événements de cluster. La notification des événements et l'intégration directe à la structure de gestion d'entreprise tierce via la prise en charge standard du protocole SNMP permettent un contrôle proactif et augmentent la disponibilité. Pour plus d'informations, reportez-vous à Creating, Setting Up, and Managing the Sun Cluster SNMP Event MIB du Sun Cluster System Administration Guide for Solaris OS.
Les informations sur les commandes peuvent maintenant être consignées dans le logiciel Sun Cluster. Cette possibilité facilite les diagnostics des échecs de cluster et fournit l'historique des actions administratives à des fins d'archivage ou de réplication. Pour plus d'informations, reportez-vous à How to View the Contents of Sun Cluster Command Logs du Sun Cluster System Administration Guide for Solaris OS.
Le logiciel Sun Cluster propose de nouveaux outils de visualisation et de mesure de l'utilisation des ressources système, notamment la mesure hautes performances des consommations par nœud, ressource et groupe de ressources. Ces nouveaux outils fournissent des données historiques, une gestion seuil ainsi qu'une réservation et un contrôle de la CPU. Ce contrôle renforcé améliore la gestion du niveau et de la capacité de service.
L'utilitaire scinstall interactif configure désormais un groupe IPMP à un adaptateur ou à plusieurs adaptateurs pour chaque ensemble d'adaptateurs réseau public en fonction des adaptateurs disponibles dans chaque sous-ensemble. Cette fonctionnalité remplace le comportement antérieur de l'utilitaire qui consistait à créer un groupe IPMP à un adaptateur pour chaque adaptateur disponible quel que soit le sous-ensemble auquel il appartenait. Pour plus d'informations sur les changements apportés aux stratégies de groupes IPMP, reportez-vous à Réseaux publics du Sun Cluster Software Guide d’installation pour le SE Solaris.
La prise en charge de shell sécurisé est ajoutée au panneau de contrôle du cluster via les nouvelles fonctionnalités suivantes :
Ajout de la prise en charge de shell sécurisé à l'utilitaire cconsole. Pour établir des connexions de shell sécurisé aux consoles de nœuds via l'interface utilisateur graphique cconsole, cochez la case Utiliser SSH dans le menu Options.
Vous pouvez également démarrer l'utilitaire directement en mode de shell sécurisé en saisissant la commande suivante sur la ligne de commande :
cconsole -s [-l username] |
Introduction du nouvel utilitaire cssh pour se connecter aux nœuds de cluster en toute sécurité.
Pour plus d'informations sur la préparation et l'utilisation des fonctionnalités de shell sécurisé du panneau de contrôle du cluster, reportez-vous à Procédure d’installation du logiciel Cluster Control Panel sur une console administrative du Sun Cluster Software Guide d’installation pour le SE Solaris. Pour obtenir les pages de manuel correspondantes à jour, reportez-vous à ccp(1M), cconsole(1M), crlogin(1M), cssh(1M) et ctelnet(1M) et à serialports(4).
Le nombre minimum requis d'interconnexions de cluster dont doit disposer un cluster est désormais d'une interconnexion de cluster entre les nœuds de cluster. L'utilitaire scinstall interactif est modifié pour ne permettre la configuration que d'une seule interconnexion lorsque vous utilisez l'utilitaire en mode personnalisé. Pour utiliser le mode classique de l'utilitaire, vous devez configurer deux interconnexions. Pour plus d'informations, reportez-vous à Interconnexion de cluster du Sun Cluster Software Guide d’installation pour le SE Solaris.
Le logiciel Sun Cluster 3.2 prend en charge le filtre IP Solaris pour les services de basculement. Le filtre IP Solaris propose des fonctions de filtrage de paquet et NAT (Network Address Translation). Le filtre IP Solaris permet en outre de créer et de gérer des pools d'adresses. Pour plus d'informations sur le filtre IP Solaris, reportez-vous à Partie IV, IP Security du System Administration Guide: IP Services dans le manuel System Administration Guide: IP Services . Pour plus d'informations sur la configuration du filtrage IP avec le logiciel Sun Cluster, reportez-vous à Utilisation du filtrage IP Solaris avec Sun Cluster.
La fonctionnalité de séparation requiert de chaque nœud de cluster l'utilisation de la même adresse IP source lorsqu'il accède à l'unité NetApp NAS. Les systèmes multiréseau utilisent plusieurs adresses IP source. L'administrateur d'un système multiréseau doit s'assurer que la même adresse IP source est toujours utilisée pour accéder à l'unité NetApp NAS. Ceci est possible en définissant une configuration réseau appropriée.
Cette section présente des informations sur les problèmes de compatibilité de Sun Cluster tels que ceux relatifs aux fonctions en voie d'abandon.
Les autres problèmes de compatibilité de la structure Sun Cluster sont documentés dans le Chapitre 1, Planification de la configuration Sun Cluster du Sun Cluster Software Guide d’installation pour le SE Solaris.
Les autres problèmes de compatibilité de la mise à niveau de Sun Cluster sont documentés dans Prise en charge liée à la mise à niveau du Sun Cluster Software Guide d’installation pour le SE Solaris.
Pour tout autre problème connu ou toute restriction, voir la rubrique Problèmes et bogues connus.
Les fonctions suivantes sont en voie d'abandon dans le logiciel Sun Cluster 3.2.
Depuis la version Sun Cluster 3.2, Sun Cluster 3.0 est abandonné. La référence Sun Cluster 3.0 n'est plus disponible.
Depuis Sun Cluster 3.2, Sun Cluster ne prend plus en charge Solaris 8.
La fonctionnalité de mise à niveau progressive risque de ne pas être disponible pour mettre à niveau Sun Cluster vers la prochaine version mineure. Dans ce cas, d'autres procédures seront indiquées pour limiter les interruptions de service du cluster pendant ces mises à niveau logicielles.
La commande sccheck risque de ne pas être disponible dans une version future. La fonctionnalité correspondante sera toutefois assurée par la commande cluster check.
Les problèmes connus suivants peuvent affecter le fonctionnement de la version Sun Cluster 3.2 avec le système d'exploitation Solaris 10 11/06. Contactez votre représentant Sun pour obtenir les patchs Solaris nécessaires à leur correction. Pour plus d'informations, reportez-vous à l'Info Doc 87995.
Vous devez mettre à niveau votre système d'exploitation vers Solaris 10 11/06 avant d'appliquer les patchs Solaris.
La commande metaset échoue après redémarrage du serveur rpcbind.
Ensembles de disques : les informations devid ne sont pas écrites sur un ensemble de disques récemment créé.
svm est quitté avec l'erreur 1 à l'étape cmmstep5, graves erreurs de nœuds.
La commande fsck: svc:/system/filesystem/usr ne peut pas démarrer à partir du jalon none.
Solaris Volume Manager (SVM) n'affiche pas de méta-ensemble après la mise à niveau du cluster dans l'environnement d'exploitation x86.
Le délai d'attente commd doit être un pourcentage de la valeur de temporisation metaclust.
metaset -s diskset -t doit prendre possession d'un nœud de cluster après le redémarrage.
SVM supprime encore l'ensemble de disques si le fichier Sun Cluster nodeid est manquant.
fsck* svc:/systsem/filesystem/usr ne peut pas démarrer à partir du jalon.
Le nouveau fsck_ufs(1M) a des difficultés à traiter le fichier déjà monté.
Graves erreurs de nœuds avec CMM :quorum fonctionnel perdu dans amd64.
create_ramdisk : impossible de rechercher le décalage -1.
Ajouter l'entrée etc/cluster/nodeid à filelist.ramdisk.
create_ramdisk doit réagir plus promptement aux fichiers et répertoires manquants.
La suppression du lien devfsadm n'entraîne pas de prise en charge totale d'interposition.
fssnap, qui est une fonction d'UFS, n'est pas pris en charge par Sun Cluster. Vous pouvez utiliser fssnap sur des systèmes locaux non contrôlés par Sun Cluster. Les restrictions suivantes s'appliquent à la prise en charge de fssnap :
Pris en charge sur des systèmes de fichiers locaux non gérés par le logiciel Sun Cluster
Non pris en charge sur des systèmes de fichiers globaux
Non pris en charge sur des systèmes de fichiers locaux contrôlés par HAStoragePlus
Le module Enhanced Storage de Solaris Management Console (Solaris Volume Manager) n'est pas compatible avec le logiciel Sun Cluster. Pour configurer le logiciel Solaris Volume Manager, utilisez l'interface de ligne de commande ou les utilitaires Sun Cluster.
Dans certaines conditions, le logiciel Sun Cluster 3.2 ne prend pas en charge l'utilisation de LOFS. Si vous devez activer LOFS sur un nœud de cluster, comme lorsque vous configurez des zones non globales, déterminez tout d'abord si les restrictions LOFS s'appliquent à votre configuration. Pour plus d'informations sur les restrictions et les solutions qui permettent d'utiliser LOFS en présence de restrictions, reportez-vous aux directives décrites dans Restrictions d’utilisation des fonctions du système d’exploitation Solaris du Sun Cluster Software Guide d’installation pour le SE Solaris.
Pour obtenir la liste des fonctions d'accessibilité mises à disposition depuis la publication de ce média, consultez les évaluations de produit de la Section 508, disponibles sur demande auprès de Sun, afin de déterminer les versions les mieux adaptées au déploiement des solutions accessibles.
Cette rubrique décrit les modifications apportées aux interfaces de commande de Sun Cluster qui pourraient entraîner des erreurs des scripts utilisateur.
Depuis la version Sun Cluster 3.2, le logiciel Sun Cluster inclut un jeu de commandes orientées objet. Bien que le logiciel Sun Cluster prenne encore en charge le jeu de commandes d'origine, la documentation procédurale de Sun Cluster utilise uniquement le jeu de commandes orientées objet. Pour plus d'informations sur le jeu de commandes orientées objet, reportez-vous à la page de manuel Intro(1CL). Pour obtenir la liste des commandes orientées objet correspondant aux procédures courantes de Sun Cluster, reportez-vous à l'Aide-mémoire Sun Cluster.
Les options suivantes de la commande scinstall ont changé dans la version Sun Cluster 3.2 :
L'option -d ne s'utilise plus avec l'option -i. La commande scinstall n'exécute plus l'installation des packages Sun Cluster. Pour ce faire, utilisez la commande installer. Pour plus d'informations, reportez-vous à Installation de la structure de Sun Cluster et des packages du logiciel du service de données du Sun Cluster Software Guide d’installation pour le SE Solaris.
L'option -d est toujours valide avec les options -a, -c et -u.
L'option -k n'est plus nécessaire. Elle est toujours fournie à des fins de compatibilité ascendante dans les scripts utilisateur.
L'option -M n'est plus utilisée. Utilisez désormais l'outil de gestion des patchs approprié correspondant à la version de SE Solaris exécutée par votre cluster. Pour obtenir plus d'informations, voir la rubrique Patchs et niveaux des micrologiciels requis.
L'option -q de la commande scconf a été modifiée pour distinguer les périphériques de quorum locaux partagés (SCSI) des autres types de périphériques de quorum (y compris les périphériques NAS NetApp). Utilisez la sous-option name pour spécifier le nom du périphérique de stockage partagé lors de l'ajout ou de la suppression d'un périphérique de quorum partagé. Cette sous-fonction peut également être utilisée avec la forme change de la commande pour modifier l'état d'un périphérique de quorum. Vous pouvez toujours utiliser la sous-option globaldev pour les périphériques de stockage partagés SCSI, mais vous devez utiliser la sous-option name pour tous les autres types de périphériques de stockage partagés. Pour plus d'informations sur cette modification de la commande scconf et l'utilisation des périphériques de quorum, reportez-vous à scconf(1M), scconf_quorum_dev_netapp_nas(1M), scconf_quorum_dev_netapp_nas(1M) et scconf_quorum_dev_scsi(1M).
Il n'est plus nécessaire de modifier directement la propriété de ressource Network_resources_used. Utilisez désormais la propriété Resource_dependencies. Le RGM met automatiquement à jour la propriété Network_resources_used en fonction des paramètres de la propriété Resource_dependencies. Pour plus d'informations sur les utilisations actuelles de ces deux propriétés de ressources, reportez-vous à r_properties(5).
Cette section présente les modifications des noms de produits des applications prises en charge par Sun Cluster. En fonction de la version du logiciel Sun Cluster que vous utilisez, la documentation Sun Cluster peut ne pas refléter les modifications de noms de produits mentionnées ci-dessous.
Le logiciel Sun Cluster 3.2 est distribué avec Solaris Cluster 3.2 et Sun Java Availability Suite.
Cette section décrit les logiciels pris en charge et la mémoire requise pour le logiciel Sun Cluster 3.2.
Mémoire requise – Le logiciel Sun Cluster 3.2 requiert la mémoire suivante pour tous les nœuds du cluster :
512 Mo de RAM physique (2 Go standard) minimum
6 Go d'espace disque disponible minimum
La mémoire physique réelle requise et la configuration requise pour le disque dur sont déterminées par les applications installées. Consultez la documentation des applications ou contactez leurs éditeurs pour calculer ces deux éléments.
Le logiciel RSMAPI – Sun Cluster 3.2 prend en charge l'Interface de programmation d'application de mémoire partagée distante (RSMAPI) sur les câbles d'interconnexion compatibles RSM, comme PCI-SCI.
Système d'exploitation (SE) Solaris – Le logiciel Sun Cluster 3.2 et le logiciel Quorum Server nécessitent les versions minimales suivantes de SE Solaris :
Solaris 9 – Solaris 9 9/05 SPARC seulement.
Solaris 10 – Solaris 10 11/06.
Solaris Trusted Extensions
Sun Cluster 3.2 prend en charge les zones non globales Solaris dans un cluster et Solaris 10 11/06 prend en charge Solaris Trusted Extensions. Solaris Trusted Extensions utilise également des zones non globales. L'interaction entre Sun Cluster et Solaris Trusted Extensions utilisant des zones non globales n'a pas été testée. Il est conseillé de procéder avec précaution lors de l'utilisation de ces technologies.
Gestionnaires de volumes
Plate-forme |
Système d'exploitation |
Gestionnaire de volumes |
Fonction de cluster |
---|---|---|---|
SPARC |
Solaris 9 |
Solaris Volume Manager. |
Solaris Volume Manager pour Sun Cluster. |
VERITAS Volume Manager 4.1. Cette prise en charge requiert VxVM 4.1 MP2. |
Fonction de cluster de VERITAS Volume Manager 4.1. |
||
Composants VERITAS Volume Manager distribués avec VERITAS Storage Foundation 4.1. Cette prise en charge requiert VxVM 4.1 MP2. |
Fonction de cluster de VERITAS Volume Manager 4.1. |
||
Composants VERITAS Volume Manager distribués avec VERITAS Storage Foundation 5.0. Cette prise en charge requiert VxVM 5.0 MP1. |
Fonction de cluster de VERITAS Volume Manager 5.0. |
||
Solaris 10 |
Solaris Volume Manager. |
Solaris Volume Manager pour Sun Cluster. |
|
VERITAS Volume Manager 4.1. Cette prise en charge requiert VxVM 4.1 MP2. |
VERITAS Volume Manager 4.1 avec fonction de cluster. |
||
VERITAS Volume Manager 4.1. Cette prise en charge requiert VxVM 4.1 MP2. |
VERITAS Volume Manager 4.1 avec fonction de cluster. |
||
Composants VERITAS Volume Manager distribués avec VERITAS Storage Foundation 5.0. Cette prise en charge requiert VxVM 5.0 MP1. |
Fonction de cluster de VERITAS Volume Manager 5.0. |
||
x86 |
Solaris 10 |
Solaris Volume Manager. |
Solaris Volume Manager pour Sun Cluster. |
Composants VERITAS Volume Manager distribués avec VERITAS Storage Foundation 4.1. |
N/D - Sun Cluster 3.2 ne prend pas en charge la fonction de cluster VxVM sur la plate-forme x86. |
Systèmes de fichiers
Sun StorEdgeTM Availability Suite 10
Sun Management Center 3.6.1
Services de données (agents) – Contactez votre représentant commercial Sun pour obtenir la liste complète des services de données et des versions d'applications pris en charge.
La documentation relative au service de données, y compris les pages de manuel et l'aide en ligne de l'assistant, n'est disponible qu'en anglais.
Les services de données Sun Cluster suivants prennent en charge les zones non globales :
Service de données Sun Cluster pour Apache
Service de données Sun Cluster pour Apache Tomcat
Service de données Sun Cluster pour DHCP
Service de données Sun Cluster pour Domain Name Service (DNS)
Service de données Sun Cluster pour Kerberos
Service de données Sun Cluster pour mySQL
Service de données Sun Cluster pour N1 Grid Service Provisioning Server
Service de données Sun Cluster pour Oracle
Service de données Sun Cluster pour Oracle Application Server
Sun Cluster HA pour PostgreSQL
Service de données Sun Cluster pour Samba
Service de données Sun Cluster pour Sun Java System Application Server
Service de données Sun Cluster pour Sun Java System Message Queue Server
Service de données Sun Cluster pour Sun Java System Web Server
les procédures relatives à la version de Sun Cluster HA pour Sun JavaTM System Directory Server utilisant Sun Java System Directory Server 5.0 et 5.1 sont décrites dans le manuel Sun Cluster 3.1 Data Service for Sun ONE Directory Server. Pour les versions ultérieures de Sun Java System Directory Server, consultez la documentation de Sun Java System Directory Server.
Les services de données suivants ne sont pas pris en charge sur Solaris 10 dans cette version de Sun Cluster :
Service de données Sun Cluster pour Agfa IMPAX
Service de données Sun Cluster pour SWIFT Alliance Access
Service de données Sun Cluster pour SWIFT Alliance Gateway
Ci-dessous figure la liste des services de données Sun Cluster et de leurs types de ressources.
Service de données |
Type de ressource Sun Cluster |
---|---|
Sun Cluster HA pour Agfa IMPAX |
SUNW.gds |
Sun Cluster HA pour Apache |
SUNW.apache |
Sun Cluster HA pour Apache Tomcat |
SUNW.gds |
Sun Cluster HA pour BroadVision One-To-One Enterprise |
SUNW.bv |
Sun Cluster HA pour DHCP |
SUNW.gds |
Sun Cluster HA pour DNS |
SUNW.dns |
Sun Cluster HA pour MySQL |
SUNW.gds |
Sun Cluster HA pour NetBackup |
SUNW.netbackup_master |
Sun Cluster HA pour NFS |
SUNW.nfs |
Sun Cluster Oracle Application Server |
SUNW.gds |
Sun Cluster HA pour Oracle E-Business Suite |
SUNW.gds |
Sun Cluster HA pour Oracle |
SUNW.oracle_server SUNW.oracle_listener |
Support Sun Cluster pour Oracle Real Application Clusters |
SUNW.rac_framework SUNW.rac_udlm SUNW.rac_svm SUNW.rac_cvm SUNW.rac_hwraid SUNW.oracle_rac_server SUNW.oracle_listener SUNW.scaldevicegroup SUNW.scalmountpoint SUNW.crs_framework SUNW.scalable_rac_server_proxy |
Sun Cluster HA pour PostgreSQL |
SUNW.gds |
Sun Cluster HA pour Samba |
SUNW.gds |
Sun Cluster HA pour SAP |
SUNW.sap_ci SUNW.sap_ci_v2 SUNW.sap_as SUNW.sap_as_v2 |
Sun Cluster HA pour SAP liveCache |
SUNW.sap_livecache SUNW.sap_xserver |
Sun Cluster HA pour SAP DB |
SUNW.sapdb SUNW.sap_xserver |
Sun Cluster HA pour SAP Web Application Server |
SUNW.sapenq SUNW.saprepl SUNW.sapscs SUNW.sapwebas |
Sun Cluster HA pour Siebel |
SUNW.sblgtwy SUNW.sblsrvr |
Sun Cluster HA pour conteneurs Solaris |
SUNW.gds |
Sun Cluster HA pour N1 Grid Engine |
SUNW.gds |
Versions de Sun Cluster HA pour Sun Java System Application Server prises en charge avant 8.1 |
SUNW.s1as |
Versions de Sun Cluster HA pour Sun Java System Application Server prises en charge à partir de 8.1 |
SUNW.jsas SUNW.jsas-na |
Sun Cluster HA pour Sun Java System Application Server EE (prises en charge des versions de HADB antérieures à 4.4) |
SUNW.hadb |
Sun Cluster HA pour Sun Java System Application Server EE (prises en charge des versions de HADB à partir de 4.4) |
SUNW.hadb_ma |
Sun Cluster HA pour Sun Java System Message Queue |
SUNW.s1mq |
Sun Cluster HA pour Sun Java System Web Server |
SUNW.iws |
Sun Cluster HA pour SWIFTAlliance Access |
SUNW.gds |
Sun Cluster HA pour SWIFTAlliance Gateway |
SUNW.gds |
Sun Cluster HA pour Sybase ASE |
SUNW.sybase |
Sun Cluster HA pour le serveur WebLogic |
SUNW.wls |
Sun Cluster HA pour WebSphere MQ |
SUNW.gds |
Sun Cluster HA pour l'intégrateur WebSphere MQ |
SUNW.gds |
Sun Cluster Security Hardening utilise les techniques de renforcement du système d'exploitation Solaris recommandées par le programme Sun BluePrintsTM afin de renforcer la sécurité de base des clusters. Solaris Security Toolkit assure la mise en oeuvre automatique de Sun Cluster Security Hardening.
La documentation relative à Sun Cluster Security Hardening est disponible à l'adresse http://www.sun.com/blueprints/0203/817-1079.pdf. Vous pouvez également accéder à l'article à partir de l'adresse http://www.sun.com/software/security/blueprints. À partir de cet URL, faites défiler le texte vers le bas jusqu'au titre Architecture, puis accédez à l'article “Securing the Sun Cluster 3.x Software.” (Sécurisation du logiciel Sun Cluster 3.x).La documentation décrit la procédure de sécurisation des déploiements de Sun Cluster 3x dans un environnement Solaris. L'utilisation de Solaris Security Toolkit et d'autres techniques de sécurité de pointe conseillées par les experts de Sun y sont également décrites. Les services de données suivants sont pris en charge par Sun Cluster Security Hardening :
Sun Cluster HA pour Apache
Sun Cluster HA pour Apache Tomcat
Sun Cluster HA pour le serveur BEA WebLogic
Sun Cluster HA pour DHCP
Sun Cluster HA pour DNS
Sun Cluster HA pour MySQL
Sun Cluster HA pour N1 GridEngine
Sun Cluster HA pour NetBackup
Sun Cluster HA pour NFS
Sun Cluster HA pour Oracle E-Business Suite
Sun Cluster HA pour Oracle
Support Sun Cluster pour Oracle Real Application Clusters
Sun Cluster HA pour PostgreSQL
Sun Cluster HA pour Samba
Sun Cluster HA pour Siebel
Sun Cluster HA pour conteneurs Solaris
Sun Cluster HA pour SWIFTAlliance Access
Sun Cluster HA pour SWIFTAlliance Gateway
Sun Cluster HA pour Sun Java System Directory Server
Sun Cluster HA pour Sun Java System Message Queue
Sun Cluster HA pour Sun Java System Messaging Server
Sun Cluster HA pour Sun Java System Web Server
Sun Cluster HA pour Sybase ASE
Sun Cluster HA pour WebSphere MQ
Sun Cluster HA pour l'intégrateur WebSphere MQ
Les problèmes et bogues présentés ci-après concernent la version Sun Cluster 3.2. Les bogues et problèmes sont regroupés dans les catégories suivantes :
Problème : la commande -clnode remove --force devrait supprimer les nœuds des metasets. Le Sun Cluster System Administration Guide for Solaris OS contient les procédures à suivre pour supprimer un nœud du cluster. Elles indiquent à l'utilisateur qu'il doit exécuter la commande metaset sur le groupe de disques Solaris Volume Manager avant d'exécuter la commande clnode remove.
Solution : si les procédures n'ont pas été suivies, il peut être nécessaire d'effacer les données de nœud périmées du CCR d'une façon habituelle. Dans un nœud de cluster actif, utilisez la commande metaset pour effacer ce nœud des groupes de disques Solaris Volume Manager, puis exécutez clnode clear --force obsolete_nodename.
Problème : sur un cluster installé avec le groupe de logiciels Solaris 10 pour utilisateurs finaux, SUNWCuser, l'exécution de la commande scsnapshot risque d'échouer en indiquant l'erreur suivante :
# scsnapshot -o … /usr/cluster/bin/scsnapshot[228]: /usr/perl5/5.6.1/bin/perl: not found |
Solution : exécutez l'une des procédures suivantes :
Installez le groupe de logiciels Solaris Entire Distribution.
Installez les packages Perl suivants : SUNWpl5u, SUNWpl5v et SUNWpl5p.
Problème : la propriété Auxnodelist de la ressource à adresse partagée ne peut pas être utilisée lors de la création de cette ressource. Cela provoque des erreurs de validation et des erreurs SEGV lors de la création de la ressource évolutive qui dépend de cette ressource réseau à adresse partagée. Le message d'erreur de validation de la ressource évolutive est au format suivant :
Method methodname (scalable svc) on resource resourcename stopped or terminated due to receipt of signal 11 |
Ce fichier core est généré à partir de ssm_wrapper. Les utilisateurs ne peuvent pas définir la propriété Auxnodelist et sont donc dans l'impossibilité d'identifier les nœuds du cluster pouvant héberger l'adresse partagée, mais ne pouvant jamais servir de nœuds principaux.
Solution : sur un nœud, recréez la ressource à adresse partagée sans spécifier la propriété Auxnodelist, puis réexécutez la commande de création de ressources évolutives et utilisez la ressource à adresse partagée que vous avez recréée en tant que ressource réseau.
Problème : la commande du logiciel Quorum Server, clquorumserver, ne définit pas correctement l'état du mécanisme du prochain démarrage.
Solution : exécutez les tâches suivantes pour lancer ou arrêter le logiciel Quorum Server.
Affichez le statut du service quorumserver.
# svcs -a | grep quorumserver |
Si le service est désactivé, la sortie est semblable à ce qui suit :
disabled 3:33:45 svc:/system/cluster/quorumserver:default |
Démarrez le logiciel Quorum Server.
Si le service quorumserver est disabled, utilisez la commande svcadm enable.
# svcadm enable svc:/system/cluster/quorumserver:default |
Si le service quorumserver est online, utilisez la commande clquorumserver.
# clquorumserver start + |
Désactivez le service quorumserver.
# svcadm disable svc:/system/cluster/quorumserver:default |
Démarrez le logiciel Quorum Server.
# clquorumserver start + |
Attribuez au fichier /etc/rc2.d/.S99quorumserver le nouveau nom /etc/rc2.d/S99quorumserver.
# mv /etc/rc2.d/.S99quorumserver /etc/rc2.d/S99quorumserver |
Arrêtez le logiciel Quorum Server.
# clquorumserver stop + |
Démarrez le logiciel Quorum Server.
# mv /etc/rc2.d/S99quorumserver /etc/rc2.d/.S99quorumserver |
Problème : lors de la création de la ressource d'agent du nœud (NA) dans Sun Cluster HA pour Application Server, la ressource est créée même s'il n'y a pas de dépendance définie sur la ressource DAS. La commande devrait retourner une erreur si la dépendance n'est pas définie, car une ressource DAS doit être en ligne pour pouvoir lancer la ressource NA.
Solution : lors de la création de la ressource NA, vérifiez que vous définissez une dépendance de ressource sur la ressource DAS.
Problème : le patch HA MySQL ajoute une nouvelle variable appelée MYSQL_DATADIR au fichier mysql_config. Cette nouvelle variable doit pointer sur le répertoire dans lequel le fichier de configuration de MySQL my.conf est enregistré. Si cette variable n'est pas configurée correctement, la préparation de la base de données avec mysql_register échouera.
Solution : pointez la variable MYSQL_DATADIR sur le répertoire dans lequel le fichier de configuration de MySQL, my.conf, est enregistré.
Problème : si InfiniBand est utilisé pour le transport intracluster et qu'il existe deux adaptateurs sur chaque nœud, avec deux ports par adaptateur pour un total de deux commutateurs, la détection automatique de l'adaptateur de l'utilitaire scinstall peut suggérer deux chemins de transport utilisant le même adaptateur.
Solution : spécifiez manuellement les adaptateurs de transport sur chaque nœud.
Problème : la connexion IPv6 aux interconnexions qui est requise pour transférer les paquets de services évolutifs IPv6 n'est plus activée par défaut. Les interfaces IPv6, telles qu'elles sont vues lors de l'utilisation de la commande ifconfig, ne sont plus connectées aux adaptateurs d'interconnexion par défaut.
Solution : activez manuellement la prise en charge du service évolutif IPv6.
Vérifiez que vous avez préparé tous les nœuds du cluster pour exécuter les services IPv6. Ces tâches incluent la configuration appropriée des interfaces réseau, des applications logicielles serveur/clientes, des services de noms et de l'infrastructure de routage. Le non-respect de ces procédures risque d'entraîner des échecs inattendus des applications réseau. Pour plus d'informations, reportez-vous à la documentation relative à l'administration du système Solaris pour les services IPv6.
Sur chaque nœud, ajoutez l'entrée suivante dans le fichier /etc/system.
set cl_comm:ifk_disable_v6=0 |
Sur chaque nœud, activez la connexion IPv6 sur les adaptateurs d'interconnexion.
# /usr/cluster/lib/sc/config_ipv6 |
L'utilitaire config_ipv6 affiche une interface IPv6 sur tous les adaptateurs d'interconnexion du cluster pourvus d'une adresse de lien. Cet utilitaire active le transfert approprié des paquets de services évolutifs IPv6 via les interconnexions.
Vous pouvez également redémarrer chaque nœud du cluster pour activer le changement de configuration.
Problème : si un fichier XML utilisant le transport par connexion directe tente d'exécuter la commande clnode add, celle-ci commet une erreur d'interprétation des informations de câble et ajoute les mauvaises informations de configuration. En conséquence, le nœud de jonction ne peut pas rejoindre le cluster.
Solution : utilisez la commande scinstall pour ajouter un nœud au cluster lorsque le transport intracluster est directement connecté.
Problème : la commande scinstall met à jour le fichier /etc/nsswitch.conf pour ajouter l'entrée cluster correspondant aux bases de données hosts et netmasks. Cette modification met à jour le fichier /net/nsswitch.conf pour la zone globale, mais lorsqu'une zone non globale est créée et installée, elle reçoit sa propre copie du fichier /etc/nsswitch.conf. Les fichiers /etc/nsswitch.conf des zones non globales ne posséderont pas l'entrée cluster correspondant aux bases de données hosts et netmasks. Toute tentative de résolution des noms d'hôte privés propres au cluster et des adresses IP à partir d'une zone non globale effectuée à l'aide des requêtes getXbyY échoue.
Solution : mettez à jour le fichier /etc/nsswitch.conf manuellement pour les zones non globales avec l'entrée cluster correspondant aux bases de données hosts et netmasks. Cette procédure garantit la disponibilité des résolutions de noms d'hôte privés propres au cluster et des adresses IP dans les zones non globales.
Problème : les messages traduits pour les programmes d'administration Quorum Server, par exemple clquorumserver, sont distribués dans les principaux packages traduits. Les messages de Quorum Server ne s'affichent donc qu'en anglais. Les packages traduits de Quorum Server doivent être séparés des principaux packages traduits et installés sur le système serveur de quorum.
Solution : installez les packages suivants sur l'hôte sur lequel Quorum Server est installé :
SUNWcsc (chinois simplifié)
SUNWdsc (allemand)
SUNWesc (espagnol)
SUNWfsc (français)
SUNWhsc (chinois traditionnel)
SUNWjsc (japonais)
SUNWksc (coréen)
Si la page de manuel en japonais est nécessaire dans Quorum Server, installez le package SUNWjscman (page de manuel en japonais).
Problème : le programme d'installation de Sun Cluster 3.2 affiche un message d'avertissement relatif au fichier swap court lors de l'installation de la version en chinois simplifié de Sun Cluster 3.2. Ce programme indique une taille de fichier swap incorrecte (0 Ko) dans l'écran de vérification de la configuration requise.
Solution : si la taille du fichier swap est supérieure à la configuration requise, vous pouvez ignorer ce problème en toute sécurité. Le programme d'installation SC 3.2 dans l'environnement linguistique C ou anglais peut être utilisé pour l'installation, et cette version vérifie correctement la taille du fichier swap.
Problème : le binaire cleanipc échoue si l'environnement de liaison d'exécution ne contient pas le chemin /sapmnt/SAPSID/exe.
Solution : en tant qu'utilisateur root Solaris, ajoutez le chemin d'accès /sapmnt/SAPSID/exe à la bibliothèque par défaut dans le fichier ld.config.
Pour configurer le chemin d'accès à la bibliothèque par défaut dans l'environnement de liaison d'exécution pour les applications 32–bits, entrez la commande suivante :
# crle -u -l /sapmnt/SAPSID/exe |
Pour configurer le chemin d'accès à la bibliothèque par défaut dans l'environnement de liaison d'exécution pour les applications 64–bits, entrez la commande suivante :
# crle -64 -u -l /sapmnt/SAPSID/exe |
Problème : si le cluster est arrêté, le démon UCMMD peut procéder à une reconfiguration sur un ou plusieurs nœuds si l'un des nœuds laisse le cluster légèrement devant le démon UCMMD. Si cela se produit, la commande rpc.md est arrêtée sur le nœud alors que le démon UCMMD essaie d'exécuter la procédure en retour. Lors de la procédure en retour, la commande metaclust obtient un délai d'attente RPC et quitte la procédure avec une erreur due au processus rpc.mdcommd manquant. Cette erreur contraint le démon UCMMD à abandonner le nœud, ce qui peut entraîner une grave erreur de nœud.
Solution : vous pouvez ignorer ce problème en toute sécurité. Lorsque le nœud initialise une sauvegarde, le logiciel Sun Cluster détecte cette condition et permet au démon UCMMD de démarrer en dépit du fait qu'une erreur s'est produite lors de la reconfiguration précédente.
Problème : la validation des ressources Sun Cluster n'accepte pas le nom d'hôte des groupes IPMP pour la propriété netiflist lors de la création de ressources de nom d'hôte logique ou d'adresse partagée.
Solution : utilisez le nom du nœud et non son ID lorsque vous spécifiez les noms des groupes IPMP lors de la création de ressources de nom d'hôte logique ou d'adresse partagée.
Problème : ce problème est observé si le disque d'origine est un disque racine encapsulé et qu'une mise à niveau en ligne est tentée de VxVM 3.5 sur SE Solaris 9 8/03 vers VxVM 5.0 sur SE Solaris 10 6/06. Le script vxlufinish échoue avec l'erreur suivante.
#./vslufinish -u 5.10 VERITAS Volume Manager VxVM 5.0 Live Upgrade finish on the Solairs release <5.10> Enter the name of the alternate root diskgroup: altrootdg ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory ld.so.1: vxparms: fatal: libvxscsi.so: open failed: No such file or directory Killed ld.so.1: ugettxt: fatal: libvxscsi.so: open failed: No such file or directory ERROR:vxlufinish Failed: /altroot.5.10/usr/lib/vxvm/bin/vxencap -d -C 10176 -c -p 5555 -g -g altrootdg rootdisk=c0t1d0s2 Please install, if 5.0 or higher version of VxVM is not installed on alternate bootdisk. |
Solution : utilisez plutôt la mise à niveau standard ou la mise à niveau sur deux partitions.
Contactez le support technique Sun ou votre représentant Sun pour savoir si la prise en charge de Sun Cluster 3.2 Live Upgrade sera bientôt disponible pour VxVM 5.0.
Problème : pendant une mise à niveau directe, les commandes lucreate et luupgrade ne permettent pas de modifier les noms DID dans l'autre environnement d'initialisation correspondant à l'entrée /global/.devices/node@N.
Solution : effectuez les étapes suivantes sur chaque nœud de cluster avant de lancer la mise à niveau directe.
Prenez le rôle de superutilisateur.
Sauvegardez le fichier /etc/vfstab.
# cp /etc/vfstab /etc/vfstab.old |
Ouvrez le fichier /etc/vfstab pour le modifier.
Recherchez la ligne correspondant à /global/.device/node@N.
Modifiez l'entrée de périphérique global.
Remplacez les noms DID par les noms physiques.
Remplacez /dev/did/{r}dsk/dYsZ par /dev/{r}dsk/cNtXdYs Z.
Supprimez global de l'entrée.
L'exemple suivant indique le nom d'un périphérique DID d3s3 correspondant à /global/.devices/node@s, remplacé par le nom de périphérique physique et dans lequel l'entrée global est supprimée :
Original: /dev/did/dsk/d3s3 /dev/did/rdsk/d3s3 /global/.devices/node@2 ufs 2 no global Changed: dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /global/.devices/node@2 ufs 2 no - |
Une fois le fichier /etc/vfstab modifié sur tous les nœuds de cluster, procédez à une mise à niveau directe du cluster mais arrêtez-la avant de réinitialiser à partir de l'autre environnement d'initialisation mis à niveau.
Sur chaque nœud, sur l'environnement d'initialisation en cours et non mis à niveau, restaurez le fichier /etc/vfstab d'origine.
# cp /etc/vstab.old /etc/vfstab |
Sur l'autre environnement d'initialisation, ouvrez le fichier /etc/vfstab pour le modifier.
Recherchez la ligne correspondant à /global/.devices/node@N et remplacez le tiret (-) à la fin de l'entrée par le mot global.
/dev/dsk/cNtXdYsZ /dev/rdsk/cNtXdYsZ /global/.devices/node@N ufs 2 no global |
Réinitialisez le nœud à partir de l'autre environnement d'initialisation mis à niveau.
Les noms DID sont remplacés automatiquement dans le fichier /etc/vfstab.
Problème : ce problème est observé lors de la mise à niveau de VERITAS Volume Manager (VxVM) pendant une mise à niveau en ligne de Sun Cluster. Le script vxlustart permet de mettre à niveau SE Solaris et VxVM à partir de la version précédente. Le script échoue et renvoie les messages d'erreur semblables aux suivants :
# ./vxlustart -u 5.10 -d c0t1d0 -s OSimage VERITAS Volume Manager VxVM 5.0. Live Upgrade is now upgrading from 5.9 to <5.10> … ERROR: Unable to copy file systems from boot environment <sorce.8876> to BE <dest.8876>. ERROR: Unable to populate file systems on boot environment <dest.8876>. ERROR: Cannot make file systems for boot environment <dest.8876>. ERROR: vxlustart: Failed: lucreate -c sorce.8876 -C /dev/dsk/c0t0d0s2 -m -:/dev/dsk/c0t1d0s1:swap -m /:/dev/dsk/c0t1d0s0:ufs -m /globaldevices:/dev/dsk/c0t1d0s3:ufs -m /mc_metadb:/dev/dsk/c0t1d0s7:ufs -m /space:/dev/dsk/c0t1d0s4:ufs -n dest.8876 |
Solution : utilisez la mise à niveau standard ou la mise à niveau sur deux partitions si vous mettez à niveau le cluster vers VxVM 5.0.
Contactez le support technique Sun ou votre représentant Sun pour savoir si la prise en charge de Sun Cluster 3.2 Live Upgrade sera bientôt disponible pour VxVM 5.0.
Problème : pour les clusters exécutant VERITAS Volume Manager (VxVM), une mise à niveau standard ou une mise à niveau sur deux partitions de l'un des logiciels suivants échoue si le disque racine est encapsulé :
Mise à niveau de SE Solaris vers une version différente
Mise à niveau de VxVM
Mise à niveau du logiciel Sun Cluster
De graves erreurs de nœuds se produisent et le nœud ne peut pas démarrer après la mise à niveau. Cela est dû aux changements des numéros majeurs ou mineurs apportés par VxVM lors de la mise à niveau.
Solution : désencapsulez le disque racine avant de commencer la mise à niveau.
Si la procédure décrite ci-dessus n'est pas suivie correctement, vous pouvez connaître de sérieux problèmes inattendus sur tous les nœuds en cours de mise à niveau. La désencapsulation et l'encapsulation du disque racine entraînent également un redémarrage automatique supplémentaire (chaque fois) du nœud, augmentant le nombre des redémarrages requis lors de la mise à niveau.
Problème : après une mise à niveau directe de Sun Cluster version 3.1 sur Solaris 9 à la version 3.2 sur Solaris 10, des zones ne peuvent pas être utilisées avec le logiciel du cluster. Le problème réside dans le fait que les données pspool ne sont pas créées pour les packages Sun Cluster. Les packages qui doivent être distribués aux zones non globales, comme SUNWsczu, ne sont pas distribués correctement.
Solution : après la mise à niveau des packages Sun Cluster à l'aide de la commande scinstall -R et avant l'initialisation du cluster en mode cluster, exécutez le script suivant deux fois :
une fois pour les packages de structure Sun Cluster ;
une fois pour les packages de service de données Sun Cluster.
Préparez et exécutez ce script de l'une des manières suivantes :
Définissez les variables des packages de structure Sun Cluster et exécutez le script. Modifiez ensuite la variable PATHNAME des packages de service de données et réexécutez le script.
Créez deux scripts, un contenant des variables définies dans le script des packages de structure et un contenant des variables définies pour les packages de service de données. Exécutez ensuite les deux scripts.
Prenez le rôle de superutilisateur.
Créez un script avec le contenu ci-dessous.
#!/bin/ksh typeset PLATFORM=${PLATFORM:-`uname -p`} typeset PATHNAME=${PATHNAME:-/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages} typeset BASEDIR=${BASEDIR:-/} cd $PATHNAME for i in * do if pkginfo -R ${BASEDIR} $i >/dev/null 2>&1 then mkdir -p ${BASEDIR}/var/sadm/pkg/$i/save/pspool pkgadd -d . -R ${BASEDIR} -s ${BASEDIR}/var/sadm/pkg/$i/save/pspool $i fi done
Définissez les variables PLATFORM, PATHNAME et BASEDIR.
Définissez ces variables en tant que variables d'environnement ou modifiez les valeurs directement dans le script.
Nom de la plate-forme. Par exemple, sparc ou x86. Par défaut, la variable PLATFORM est définie sur le résultat de la commande uname -p.
Chemin d'accès au périphérique à partir duquel les packages de structure ou de service de données Sun Cluster peuvent être installés. Cette valeur correspond à l'option -d de la commande pkgadd.
Par exemple, pour des packages de structure Sun Cluster, cette valeur pourrait se présenter comme suit :
/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster/Solaris_10/Packages |
Pour les packages de service de données, cette valeur pourrait se présenter comme suit :
/cdrom/cdrom0/Solaris_${PLATFORM}/Product/sun_cluster_agents/Solaris_10/Packages |
Chemin d'accès complet à un répertoire à utiliser en tant que chemin d'accès racine et qui correspond à l'option -R de la commande pkgadd. Pour une mise à niveau directe, définissez cette valeur sur le chemin d'accès racine utilisé avec l'option -R de la commande scinstall. Par défaut, la variable BASEDIR est définie sur le système de fichiers racine (/).
Exécutez le script, une fois pour les packages de structure Sun Cluster et une fois pour les packages de service de données.
Une fois le script exécuté, le message suivant doit s'afficher à l'invite de commande de chaque package :
Transferring pkgname package instance |
Si le répertoire pspool existe déjà pour un package ou si le script est exécuté deux fois pour le même ensemble de packages, l'erreur suivante s'affiche à l'invite de commande :
Transferring pkgname package instance pkgadd: ERROR: unable to complete package transfer - identical version of pkgname already exists on destination device |
Ce message est sans conséquence et peut être ignoré.
Une fois le script exécuté pour les packages de structure et de service de données, initialisez les nœuds en mode cluster.
Problème : l'ajout d'un nouveau nœud de cluster sans s'assurer que celui-ci comporte les mêmes patchs que les nœuds de cluster existants peut entraîner un dysfonctionnement des nœuds de cluster.
Solution : avant d'ajouter un nœud au cluster, vérifiez qu'il dispose des patchs de même niveau que les nœuds de cluster existants. Sinon les nœuds de cluster peuvent connaître un dysfonctionnement.
Cette rubrique fournit des informations sur les patchs applicables aux configurations Sun Cluster. Si vous effectuez une mise à niveau vers le logiciel Sun Cluster 3.2, reportez-vous au Chapitre 8, Mise à niveau du logiciel Sun Cluster du Sun Cluster Software Guide d’installation pour le SE Solaris. L'application d'un patch Sun Cluster 3.2 Core n'entraîne pas les mêmes résultats que la mise à niveau du logiciel vers la version Sun Cluster 3.2.
Lisez le fichier README du patch avant de l'appliquer ou de le supprimer.
Si vous utilisez la méthode de patch de réinitialisation (nœud) pour installer le patch principal de Sun Cluster, 125510 (S9/SPARC), 125511 (S10/SPARC) ou 125512 (S19/x64), vous devez disposer de la version -02 du patch pour installer des versions supérieures du patch. Si vous ne disposez pas du patch -02 et que vous souhaitez installer la version -03 ou supérieure (si disponible), utilisez la méthode de cluster de réinitialisation.
Consultez la liste suivante d'exemples de scénarios de patchs :
Si vous disposez du logiciel Sun Cluster 3.2 avec le système d'exploitation Solaris 10 sur SPARC avec le patch 125511-02 et que vous souhaitez installer la version 125511-03 ou supérieure, utilisez la méthode de nœud de réinitialisation ou de cluster de réinitialisation.
Si vous disposez du logiciel Sun Cluster 3.2 avec le système d'exploitation Solaris 10 sur SPARC sans la version 125511-02 installée et que vous souhaitez installer la version 125511-03 ou supérieure, les solutions suivantes s'offrent à vous :
Utilisez la méthode de cluster de réinitialisation pour installer la version 125511-03.
Installez la version 125511-02 à l'aide de la méthode de nœud de réinitialisation, puis installez la version 125511-03 selon la même méthode.
vous devez être enregistré comme utilisateur SunSolveTM pour pouvoir afficher et télécharger les patchs nécessaires à Sun Cluster. Si vous ne disposez pas d'un compte SunSolve, contactez votre représentant Sun ou enregistrez-vous en ligne à l'adresse http://sunsolve.sun.com.
Suivez la procédure ci-dessous pour appliquer le patch principal de Sun Cluster 3.2.
Installez le patch selon la procédure de patch de réinitialisation habituelle d'un patch principal.
Vérifiez que le patch a été correctement installé sur tous les nœuds et qu'il fonctionne de manière appropriée.
Enregistrez la nouvelle version des types de ressources SUNW.HAStoragePlus, SUNW.ScalDeviceGroup et SUNW.ScalMountPoint qui sont mis à jour dans ce patch. Mettez à niveau le type de ressource sur toutes les ressources existantes vers les nouvelles versions.
Pour plus d'informations sur l'enregistrement d'un type de ressource, reportez-vous à Registering a Resource Type du Sun Cluster Data Services Planning and Administration Guide for Solaris OS dans le manuel Sun Cluster Data Services Planning and Administration Guide for Solaris OS .
Si le patch principal de Sun Cluster 3.2 est supprimé, la version des ressources mises à niveau à l'étape 3 doit être réduite aux versions de type de ressource antérieures. La procédure de réduction de la version nécessite une interruption planifiée de ces services. Ne procédez donc à l'étape 3 que lorsque vous pouvez appliquer définitivement le patch principal de Sun Cluster 3.2 à votre cluster.
Suivez la procédure ci-dessous pour supprimer le patch principal de Sun Cluster 3.2.
Répertoriez les types de ressources du cluster.
# clrt list |
Si la liste renvoie SUNW.HAStoragePlus:5, SUNW.ScalDeviceGroup:2 ou SUNW.ScalMountPoint:2, supprimez ces types de ressources. Pour obtenir des instructions sur la suppression d'un type de ressource, reportez-vous à How to Remove a Resource Type du Sun Cluster Data Services Planning and Administration Guide for Solaris OS dans le manuel Sun Cluster Data Services Planning and Administration Guide for Solaris OS .
Réinitialisez tous les nœuds du cluster en mode non-cluster monoutilisateur.
Pour obtenir des instructions sur la réinitialisation de nœuds de cluster en mode non-cluster monoutilisateur, reportez-vous à How to Boot a Cluster Node in Noncluster Mode du Sun Cluster System Administration Guide for Solaris OS dans le manuel Sun Cluster System Administration Guide for Solaris OS .
Supprimez le patch principal de Sun Cluster 3.2 de chaque nœud sur lequel le patch est installé.
# patchrm patch-id |
Réinitialisez en mode cluster tous les nœuds sur lesquels vous avez supprimé le patch principal de Sun Cluster 3.2.
La réinitialisation de tous les nœuds sur lesquels vous avez supprimé le patch principal de Sun Cluster 3.2 avant de réinitialiser des nœuds non concernés garantit que le CCR du cluster comporte les informations appropriées. Si vous avez appliqué le patch principal à tous les nœuds du cluster, vous pouvez les réinitialiser en mode cluster dans n'importe quel ordre.
Pour obtenir des instructions sur la réinitialisation de nœuds en mode cluster, reportez-vous à How to Reboot a Cluster Node du Sun Cluster System Administration Guide for Solaris OS dans le manuel Sun Cluster System Administration Guide for Solaris OS .
Réinitialisez les nœuds restants en mode cluster.
La technologie de gestion des patchs PatchPro est désormais disponible dans Patch Manager 2.0 pour SE Solaris 9 et dans Sun Update Connection 1.0 pour SE Solaris 10.
Solaris 9 - Vous pouvez télécharger gratuitement Sun Patch Manager 2.0 à partir de SunSolve à l'adresse http://wwws.sun.com/software/download/products/40c8c2ad.html. La documentation relative à Sun Patch Manager est disponible à l'adresse http://ttp://docs.sun.com/app/docs/coll/1152.1.
Solaris 10 - Sun Update Connection est disponible avec l'ID de patch 121118-05 (SPARC) ou 121119-05 (x86), ou vous pouvez le télécharger à partir de SunSolve. Pour plus d'informations, reportez-vous à http://www.sun.com/service/sunupdate/gettingstarted.html. La documentation relative à Sun Update Connection est disponible à l'adresse http://docs.sun.com/app/docs/coll/1320.2.
Des informations supplémentaires sur toutes les options de gestion des patchs pour SE Solaris 10 sont disponibles à l'adresse http://www.sun.com/service/sunupdate/. D'autres informations sur l'utilisation des outils de gestion des patchs Sun sont indiquées dans le Guide d'administration Solaris : administration de base à l'adresse http://docs.sun.com. Reportez-vous à la version de ce manuel publié correspondant à la version de SE Solaris que vous avez installée.
Si certains patchs doivent être appliqués lorsque le nœud est en mode non-cluster, vous pouvez les appliquer en mode progressif, un nœud à la fois, à moins que les instructions relatives à un patch ne vous demandent d'arrêter tout le cluster. Suivez les procédures décrites dans How to Apply a Rebooting Patch (Node) du Sun Cluster System Administration Guide for Solaris OS pour préparer le nœud et le démarrer en mode non-cluster. Pour faciliter l'installation, pensez à appliquer en une seule fois tous les patchs sur un nœud que vous mettez en mode non-cluster.
Le site web SunSolve Online vous offre un accès permanent aux dernières mises à jour et versions des patchs, logiciels et microprogrammes développés pour les produits Sun. Accédez au site SunSolve Online, à l'adresse http://sunsolve.sun.com , pour consulter les grilles actualisées des logiciels, microprogrammes et patchs pris en charge.
Des informations sur des patchs tiers pour Sun Cluster 3.2 sont indiquées dans un Info Doc SunSolve pour le matériel spécifique que vous envisagez d'utiliser dans un environnement Sun Cluster 3.2. Pour localiser cet Info Doc, connectez-vous à SunSolve. Dans la page d'accueil de SunSolve, tapez Sun Cluster 3.x Third-Party Patches dans la zone des critères de recherche.
Avant d'installer Sun Cluster 3.2 et d'appliquer des patchs à un composant de cluster (SE Solaris, logiciel Sun Cluster, gestionnaire de volumes, logiciel de services de données ou lecteur de disque), lisez attentivement chacun des fichiers README accompagnant les patchs récupérés. Le même niveau de patchs doit être appliqué à tous les noeuds du cluster pour qu'il puisse fonctionner correctement.
Pour obtenir des procédures relatives à des patchs et des conseils sur l'administration de ces patchs, reportez-vous au Chapitre 10, Patching Sun Cluster Software and Firmware du Sun Cluster System Administration Guide for Solaris OS.
La documentation Sun Cluster 3.2 est composée des collections présentées ci-dessous.
Manuels sur les services de données Sun Cluster 3.2 pour SE Solaris (édition pour plate-forme SPARC)
Manuels sur les services de données Sun Cluster 3.2 pour SE Solaris (édition pour plate-forme x86)
Collection Matériel Sun Cluster 3.1 - 3.2 pour SE Solaris (édition pour plate-forme SPARC)
Collection Matériel Sun Cluster 3.1–3.2 pour SE Solaris (édition pour plate-forme x86)
La documentation utilisateur de Sun Cluster 3.2 est disponible aux formats PDF et HTML sur le site Web suivant :
http://htt;://docs.sun.com/app/docs/prod/sun.cluster32
À partir de Sun Cluster 3.2, la documentation relative aux services de données individuels ne sera plus traduite et sera proposée uniquement en anglais.
En plus de la recherche dans la documentation produit de Sun disponible sur le site Web docs.sun.com, vous pouvez utiliser un moteur de recherche en tapant la syntaxe suivante dans le champ de recherche :
search-term site:docs.sun.com |
Par exemple, si vous recherchez « broker » (courtier), tapez la ligne suivante :
broker site:docs.sun.com |
Pour inclure d'autres sites Web Sun dans vos recherches (comme java.sun.com, www.sun.com et developers.sun.com), utilisez « sun.com » au lieu de « docs.sun.com » dans le champ de recherche.
Référence |
Titre du manuel |
---|---|
820–0335 | |
819-2969 | |
819-2972 | |
819-2974 |
Sun Cluster Data Services Planning and Administration Guide for Solaris OS |
819-2973 | |
819-2968 | |
819-3055 | |
819-2970 |
Sun Cluster Software Guide d’installation pour le SE Solaris |
819–0912 | |
819-2971 |
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).