| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Guide d'administration système d'Oracle Solaris Cluster Oracle Solaris Cluster 3.3 3/13 (Français) |
| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
|
Guide d'administration système d'Oracle Solaris Cluster Oracle Solaris Cluster 3.3 3/13 (Français) |
1. Présentation de l'administration d'Oracle Solaris Cluster
Présentation de l'administration d'Oracle Solaris Cluster
Fonctionnement d'un cluster de zones
Restrictions concernant les fonctions du SE Oracle Solaris
Interface de ligne de commande
Préparation de l'administration du cluster
Documentation de la configuration matérielle d'Oracle Solaris Cluster
Utilisation d'une console d'administration
Démarrage de l'administration du cluster
Connexion à distance au cluster
Etablissement d'une connexion sécurisée aux consoles du cluster
Accès aux utilitaires de configuration du cluster
Affichage des informations relatives aux patchs d'Oracle Solaris Cluster
Affichage des informations de version d'Oracle Solaris Cluster
Affichage des types de ressources, des groupes de ressources et des ressources configurés
Vérification du statut des composants du cluster
Vérification du statut du réseau public
Affichage de la configuration du cluster
Validation de la configuration de base d'un cluster
Vérification des points de montage globaux
Affichage du contenu de journaux de commandes Oracle Solaris Cluster
2. Oracle Solaris Cluster et RBAC
3. Arrêt et initialisation d'un cluster
4. Méthodes de réplication de données
7. Administration des interconnexions de cluster et des réseaux publics
8. Ajout et suppression d'un noeud
10. Configuration du contrôle de l'utilisation de la CPU
11. Application de patchs au logiciel et au microprogramme d'Oracle Solaris Cluster
12. Sauvegarde et restauration d'un cluster
13. Administration d'Oracle Solaris Cluster avec les interfaces graphiques
Le Tableau 1-2 vous indique comment débuter l'administration de votre cluster.
Remarque - Les commandes Oracle Solaris Cluster qui s'exécutent uniquement depuis le noeud votant du cluster global ne peuvent pas être utilisées dans les clusters de zones. Pour savoir comment exécuter correctement une commande dans une zone, reportez-vous à la page de manuel Oracle Solaris Cluster appropriée.
Tableau 1-2 Outils d'administration d'Oracle Solaris Cluster
|
Le panneau de contrôle de cluster (CCP) fournit un panneau de lancement pour les outils cconsole, crlogin, cssh et ctelnet. Tous les outils démarrent une connexion à fenêtres multiples à un ensemble de noeuds spécifiés. La connexion à fenêtres multiples se compose d'une fenêtre hôte pour chacun des noeuds spécifiés et d'une fenêtre commune. Les saisies dans la fenêtre commune sont envoyées à chaque fenêtre hôte, ce qui vous permet d'exécuter des commandes sur tous les noeuds du cluster en même temps.
Vous pouvez également démarrer des sessions cconsole, crlogin, cssh ou ctelnet depuis la ligne de commande.
Par défaut, l'utilitaire cconsole utilise une connexion telnet vers les consoles des noeuds. Pour établir plutôt des connexions de shell sécurisé aux consoles, cochez la case Utiliser SSH dans le menu Options de la fenêtre cconsole. Ou indiquez l'option -s lorsque vous émettez la commande ccp ou cconsole.
Pour plus d'informations, reportez-vous aux pages de manuel ccp(1M) et cconsole(1M).
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
Avant de commencer
Vérifiez que les conditions requises suivantes sont respectées avant de démarrer le CCP :
Installez le package SUNWccon sur la console d'administration.
Assurez-vous que la variable PATH sur la console d'administration inclut les répertoires des outils Oracle Solaris Cluster, /opt/SUNWcluster/bin et /usr/cluster/bin. Vous pouvez spécifier un autre emplacement pour le répertoire des outils en définissant la variable d'environnement $CLUSTER_HOME.
Configurez le fichier clusters, le fichier serialports et le fichier nsswitch.conf si vous utilisez un concentrateur de terminaux. Les fichiers peuvent être des fichiers /etc ou des bases de données NIS ou NIS+. Pour plus d'informations, reportez-vous aux pages de manuel clusters(4) et serialports(4).
phys-schost# ccp clustername
La fenêtre de lancement CCP s'affiche.
Effectuez cette procédure pour établir des connexions de shell sécurisé aux consoles des noeuds du cluster.
Avant de commencer
Configurez le fichier clusters, le fichier serialports et le fichier nsswitch.conf si vous utilisez un concentrateur de terminaux. Les fichiers peuvent être des fichiers /etc ou des bases de données NIS ou NIS+.
Remarque - Dans le fichier serialports, affectez le numéro de port à utiliser pour établir une connexion sécurisée à chaque périphérique d'accès par console. Le numéro de port par défaut pour la connexion de shell sécurisé est 22.
Pour plus d'informations, reportez-vous aux pages de manuel clusters(4) et serialports(4).
# cconsole -s [-l username] [-p ssh-port]
Active la connexion de shell sécurisé.
Indique le nom d'utilisateur pour les connexions à distance. Si l'option -l n'est pas spécifiée, le nom d'utilisateur qui a lancé l'utilitaire cconsole est utilisé.
Indique le numéro de port de shell sécurisé à utiliser. 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.
L'utilitaire clsetup permet de créer un cluster de zones de manière interactive et de configurer les options de quorum, de groupes de ressources, de transport intracluster, de nom d'hôte privé, de groupes de périphériques et de nouveaux noeuds pour le cluster global. L'utilitaire clzonecluster effectue des tâches de configuration similaires pour un cluster de zones. Pour plus d'informations, reportez-vous aux pages de manuel clsetup(1CL) et clzonecluster(1CL).
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
phys-schost# clsetup
phys-schost# clsetup
Le menu principal s'affiche.
phys-schost# clzonecluster configure sczone
Pour afficher les actions disponibles dans cet utilitaire, entrez l'option suivante :
clzc:sczone> ?
Vous pouvez également exécuter l'utilitaire clsetup interactif pour créer un cluster de zones ou ajouter un système de fichiers ou un périphérique de stockage dans l'étendue du cluster. Toutes les autres tâches de configuration du cluster de zones sont exécutées avec la commande clzonecluster configure. Reportez-vous au Guide d’installation du logiciel Oracle Solaris Cluster pour obtenir des instructions sur l'exécution de l'utilitaire clsetup.
Voir aussi
Pour plus d'informations, reportez-vous à l'aide en ligne de clsetup ou de clzonecluster.
Il n'est pas nécessaire d'être connecté en tant que superutilisateur pour effectuer cette procédure.
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
phys-schost# showrev -p
Les versions de mise à jour d'Oracle Solaris Cluster sont identifiées par le numéro de patch principal du produit suivi de la version de mise à jour.
Exemple 1-1 Affichage des informations relatives aux patchs d'Oracle Solaris Cluster
L'exemple suivant affiche les informations relatives au patch 110648-05.
phys-schost# showrev -p | grep 110648 Patch: 110648-05 Obsoletes: Requires: Incompatibles: Packages:
Il n'est pas nécessaire d'être connecté en tant que superutilisateur pour effectuer cette procédure. Effectuez toutes les étapes de cette procédure à partir d'un noeud du cluster global.
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
phys-schost# clnode show-rev -v -node
Cette commande affiche le numéro de version d'Oracle Solaris Cluster et les chaînes de versions de tous les packages Oracle Solaris Cluster.
Exemple 1-2 Affichage des informations de version d'Oracle Solaris Cluster
L'exemple suivant affiche les informations de version du cluster et les informations de version du package.
phys-schost# clnode show-rev 3.3 phys-schost# clnode show-rev -v Oracle Solaris Cluster 3.3 for Solaris 10 sparc SUNWcccon: 3.3.0,REV=2010.06.14.03.44 SUNWccon: 3.3.0,REV=2010.06.14.03.44 SUNWcsc: 3.3.0,REV=2010.06.14.03.44 SUNWcscspmu 3.3.0,REV=2010.06.14.03.44 SUNWcscssv: 3.3.0,REV=2010.06.14.03.44 SUNWeccon: 3.3.0,REV=2010.06.14.03.44 SUNWesc: 3.3.0,REV=2010.06.14.03.44 SUNWescspmu: 3.3.0,REV=2010.06.14.03.44 SUNWescssv: 3.3.0,REV=2010.06.14.03.44 SUNWfccon: 3.3.0,REV=2010.06.14.03.44 SUNWfsc: 3.3.0,REV=2010.06.14.03.44 SUNFfscspmu: 3.3.0,REV=2010.06.14.03.44 SUNWfscssv: 3.3.0,REV=2010.06.14.03.44 SUNWjccon: 3.3.0,REV=2010.06.14.03.44 SUNWjcommonS: 3.3.0,REV=2010.06.14.03.44 SUNWjsc: 3.3.0,REV=2010.06.14.03.44 SUNWjscman: 3.3.0,REV=2010.06.14.03.44 SUNWjscspmu: 3.3.0,REV=2010.06.14.03.44 SUNWjscssv: 3.3.0,REV=2010.06.14.03.44 SUNWkccon: 3.3.0,REV=2010.06.14.03.44 SUNWksc: 3.3.0,REV=2010.06.14.03.44 SUNWkscspmu 3.3.0,REV=2010.06.14.03.44 SUNWkscssv: 3.3.0,REV=2010.06.14.03.44 SUNWscu: 3.3.0,REV=2010.06.14.03.44 SUNWsccomu: 3.3.0,REV=2010.06.14.03.44 SUNWsczr: 3.3.0,REV=2010.06.14.03.44 SUNWsccomzu: 3.3.0,REV=2010.06.14.03.44 SUNWsczu: 3.3.0,REV=2010.06.14.03.44 SUNWscsckr: 3.3.0,REV=2010.06.14.03.44 SUNWscscku: 3.3.0,REV=2010.06.14.03.44 SUNWscr: 3.3.0,REV=2010.06.14.03.44 SUNWscrdt: 3.3.0,REV=2010.06.14.03.44 SUNWscrif: 3.3.0,REV=2010.06.14.03.44 SUNWscrtlh: 3.3.0,REV=2010.06.14.03.44 SUNWscnmr: 3.3.0,REV=2010.06.14.03.44 SUNWscnmu: 3.3.0,REV=2010.06.14.03.44 SUNWscdev: 3.3.0,REV=2010.06.14.03.44 SUNWscgds: 3.3.0,REV=2010.06.14.03.44 SUNWscsmf: 3.3.0,REV=2010.06.14.03.44 SUNWscman: 3.3.0,REV=2010.05.21.18.40 SUNWscsal: 3.3.0,REV=2010.06.14.03.44 SUNWscsam: 3.3.0,REV=2010.06.14.03.44 SUNWscvm: 3.3.0,REV=2010.06.14.03.44 SUNWmdmr: 3.3.0,REV=2010.06.14.03.44 SUNWmdmu: 3.3.0,REV=2010.06.14.03.44 SUNWscmasa: 3.3.0,REV=2010.06.14.03.44 SUNWscmasar: 3.3.0,REV=2010.06.14.03.44 SUNWscmasasen: 3.3.0,REV=2010.06.14.03.44 SUNWscmasazu: 3.3.0,REV=2010.06.14.03.44 SUNWscmasau: 3.3.0,REV=2010.06.14.03.44 SUNWscmautil: 3.3.0,REV=2010.06.14.03.44 SUNWscmautilr: 3.3.0,REV=2010.06.14.03.44 SUNWjfreechart: 3.3.0,REV=2010.06.14.03.44 SUNWjfreechartS: 3.3.0,REV=2010.06.14.03.44 ORCLscPeopleSoft:3.3.0,REV=2010.06.14.03.44 ORCLscobiee: 3.3.0,REV=2010.06.14.03.44 ORCLscoep: 3.3.0,REV=2010.06.14.03.44 ORCLscohs: 3.3.0,REV=2010.06.14.03.44 ORCLscopmn: 3.3.0,REV=2010.06.14.03.44 ORCLscsapnetw: 3.3.0,REV=2010.06.14.03.44 SUNWcvm: 3.3.0,REV=2010.06.14.03.44 SUNWcvmr: 3.3.0,REV=2010.06.14.03.44 SUNWiimsc: 3.3.0,REV=2010.06.14.03.44 SUNWscspmr: 3.3.0,REV=2010.06.14.03.44 SUNWscspmu: 3.3.0,REV=2010.06.14.03.44 SUNWscderby: 3.3.0,REV=2010.06.14.03.44 SUNWsctelemetry: 3.3.0,REV=2010.06.14.03.44 SUNWscgrepavs: 3.2.3,REV=2009.10.23.12.12 SUNWscgrepavsu: 3.3.0,REV=2010.06.14.03.44 SUNWscgrepodg: 3.3.0,REV=2010.06.14.03.44 SUNWscgrepodgu: 3.3.0,REV=2010.06.14.03.44 SUNWscgrepsbpu: 3.3.0,REV=2010.06.14.03.44 SUNWscgrepsrdf: 3.2.3,REV=2009.10.23.12.12 SUNWscgrepsrdfu: 3.3.0,REV=2010.06.14.03.44 SUNWscgreptc: 3.2.3,REV=2009.10.23.12.12 SUNWscgreptcu: 3.3.0,REV=2010.06.14.03.44 SUNWscgspm: 3.3.0,REV=2010.06.14.03.44 SUNWscghb: 3.2.3,REV=2009.10.23.12.12 SUNWscghbr: 3.3.0,REV=2010.06.14.03.44 SUNWscgman: 3.3.0,REV=2010.06.14.03.44 ORCLscgrepzfssa: 3.3.0,REV=2010.06.14.03.44 SUNWscgctl: 3.2.3,REV=2009.10.23.12.12 SUNWscgctlr: 3.3.0,REV=2010.06.14.03.44 SUNWscims: 6.0,REV=2003.10.29 SUNWscics: 6.0,REV=2003.11.14 SUNWscids: 3.3.0,REV=2010.06.14.03.44 SUNWscapc: 3.2.0,REV=2006.12.06.18.32 SUNWscdns: 3.2.0,REV=2006.12.06.18.32 SUNWschadb: 3.2.0,REV=2006.12.06.18.32 SUNWschtt: 3.2.0,REV=2006.12.06.18.32 SUNWscs1as: 3.2.0,REV=2006.12.06.18.32 SUNWsckrb5: 3.2.0,REV=2006.12.06.18.32 SUNWscnfs: 3.2.0,REV=2006.12.06.18.32 SUNWscor: 3.2.0,REV=2006.12.06.18.32 SUNWscpax: 3.3.0,REV=2010.06.14.03.44 SUNWscs1mq: 3.2.0,REV=2006.12.06.18.32 SUNWscsap: 3.2.0,REV=2006.12.06.18.32 SUNWsclc: 3.2.0,REV=2006.12.06.18.32 SUNWscmd: 3.3.0,REV=2010.06.14.03.44 SUNWscsapdb: 3.2.0,REV=2006.12.06.18.32 SUNWscsapenq: 3.2.0,REV=2006.12.06.18.32 SUNWscsaprepl: 3.2.0,REV=2006.12.06.18.32 SUNWscsapscs: 3.2.0,REV=2006.12.06.18.32 SUNWscsapwebas: 3.2.0,REV=2006.12.06.18.32 SUNWscsbl: 3.2.0,REV=2006.12.06.18.32 SUNWscsyb: 3.2.0,REV=2006.12.06.18.32 SUNWscucm: 3.3.0,REV=2010.06.14.03.44 SUNWscwls: 3.3.0,REV=2010.06.14.03.44 SUNWudlm: 3.3.0,REV=2010.06.14.03.44 SUNWudlmr: 3.3.0,REV=2010.06.14.03.44 SUNWscwls: 3.2.0,REV=2006.12.06.18.32 SUNWsc9ias: 3.2.0,REV=2006.12.06.18.32 SUNWscPostgreSQL:3.2.0,REV=2006.12.06.18.32 SUNWscTimesTen: 3.3.0,REV=2010.06.14.03.44 SUNWsczone: 3.2.0,REV=2006.12.06.18.32 SUNWscdhc: 3.2.0,REV=2006.12.06.18.32 SUNWscebs: 3.2.0,REV=2006.12.06.18.32 SUNWscmqi: 3.2.0,REV=2006.12.06.18.32 SUNWscmqs: 3.2.0,REV=2006.12.06.18.32 SUNWscmys: 3.2.0,REV=2006.12.06.18.32 SUNWscsge: 3.2.0,REV=2006.12.06.18.32 SUNWscsaa: 3.2.0,REV=2006.12.06.18.32 SUNWscsag: 3.2.0,REV=2006.12.06.18.32 SUNWscsmb: 3.2.0,REV=2006.12.06.18.32 SUNWscsps: 3.2.0,REV=2006.12.06.18.32 SUNWsctomcat: 3.2.0,REV=2006.12.06.18.32
Vous pouvez également effectuer cette procédure à l'aide de l'interface graphique d'Oracle Solaris Cluster Manager. Reportez-vous au Chapitre 13, Administration d'Oracle Solaris Cluster avec les interfaces graphiques ou à l'aide en ligne d'Oracle Solaris Cluster Manager pour plus d'informations.
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
Avant de commencer
Les utilisateurs qui ne sont pas des superutilisateurs doivent disposer de l'autorisation RBAC solaris.cluster.read pour utiliser cette sous-commande.
phys-schost# cluster show -t resource,resourcetype,resourcegroup
Pour afficher les informations concernant une ressource, un groupe de ressources ou un type de ressource particulier, utilisez la sous-commande show et l'une des sous-commandes suivantes :
resource
resource group
resourcetype
Exemple 1-3 Affichage des types de ressources, des groupes de ressources et des ressources configurés
L'exemple suivant illustre les types de ressources (RT Name), les groupes de ressources (RG Name), et les ressources (RS Name) configurés pour le cluster schost.
phys-schost# cluster show -t resource,resourcetype,resourcegroup
=== Registered Resource Types ===
Resource Type: SUNW.qfs
RT_description: SAM-QFS Agent on Oracle Solaris Cluster
RT_version: 3.1
API_version: 3
RT_basedir: /opt/SUNWsamfs/sc/bin
Single_instance: False
Proxy: False
Init_nodes: All potential masters
Installed_nodes: <All>
Failover: True
Pkglist: <NULL>
RT_system: False
Global_zone: True
=== Resource Groups and Resources ===
Resource Group: qfs-rg
RG_description: <NULL>
RG_mode: Failover
RG_state: Managed
Failback: False
Nodelist: phys-schost-2 phys-schost-1
--- Resources for Group qfs-rg ---
Resource: qfs-res
Type: SUNW.qfs
Type_version: 3.1
Group: qfs-rg
R_description:
Resource_project_name: default
Enabled{phys-schost-2}: True
Enabled{phys-schost-1}: True
Monitored{phys-schost-2}: True
Monitored{phys-schost-1}: True
Vous pouvez également effectuer cette procédure à l'aide de l'interface graphique d'Oracle Solaris Cluster Manager. Pour plus d'informations, consultez l'aide en ligne d'Oracle Solaris Cluster Manager.
Remarque - Le commande cluster status affiche également le statut d'un cluster de zones.
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
Avant de commencer
Les utilisateurs qui ne sont pas des superutilisateurs doivent disposer de l'autorisation RBAC solaris.cluster.read pour utiliser la sous-commande status.
phys-schost# cluster status
Exemple 1-4 Vérification du statut des composants d'un cluster
L'exemple suivant présente un échantillon d'informations de statut des composants d'un cluster renvoyées par la commande cluster(1CL) status.
phys-schost# cluster status
=== Cluster Nodes ===
--- Node Status ---
Node Name Status
--------- ------
phys-schost-1 Online
phys-schost-2 Online
=== Cluster Transport Paths ===
Endpoint1 Endpoint2 Status
--------- --------- ------
phys-schost-1:qfe1 phys-schost-4:qfe1 Path online
phys-schost-1:hme1 phys-schost-4:hme1 Path online
=== Cluster Quorum ===
--- Quorum Votes Summary ---
Needed Present Possible
------ ------- --------
3 3 4
--- Quorum Votes by Node ---
Node Name Present Possible Status
--------- ------- -------- ------
phys-schost-1 1 1 Online
phys-schost-2 1 1 Online
--- Quorum Votes by Device ---
Device Name Present Possible Status
----------- ------- -------- ------
/dev/did/rdsk/d2s2 1 1 Online
/dev/did/rdsk/d8s2 0 1 Offline
=== Cluster Device Groups ===
--- Device Group Status ---
Device Group Name Primary Secondary Status
----------------- ------- --------- ------
schost-2 phys-schost-2 - Degraded
--- Spare, Inactive, and In Transition Nodes ---
Device Group Name Spare Nodes Inactive Nodes In Transistion Nodes
----------------- ----------- -------------- --------------------
schost-2 - - -
=== Cluster Resource Groups ===
Group Name Node Name Suspended Status
---------- --------- --------- ------
test-rg phys-schost-1 No Offline
phys-schost-2 No Online
test-rg phys-schost-1 No Offline
phys-schost-2 No Error--stop failed
test-rg phys-schost-1 No Online
phys-schost-2 No Online
=== Cluster Resources ===
Resource Name Node Name Status Message
------------- --------- ------ -------
test_1 phys-schost-1 Offline Offline
phys-schost-2 Online Online
test_1 phys-schost-1 Offline Offline
phys-schost-2 Stop failed Faulted
test_1 phys-schost-1 Online Online
phys-schost-2 Online Online
Device Instance Node Status
--------------- ---- ------
/dev/did/rdsk/d2 phys-schost-1 Ok
/dev/did/rdsk/d3 phys-schost-1 Ok
phys-schost-2 Ok
/dev/did/rdsk/d4 phys-schost-1 Ok
phys-schost-2 Ok
/dev/did/rdsk/d6 phys-schost-2 Ok
=== Zone Clusters ===
--- Zone Cluster Status ---
Name Node Name Zone HostName Status Zone Status
---- --------- ------------- ------ -----------
sczone schost-1 sczone-1 Online Running
schost-2 sczone-2 Online Running
Vous pouvez également effectuer cette procédure à l'aide de l'interface graphique d'Oracle Solaris Cluster Manager. Pour plus d'informations, consultez l'aide en ligne d'Oracle Solaris Cluster Manager.
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
Pour vérifier le statut des groupes de multipathing sur réseau IP, exécutez la commande clnode(1CL) avec la sous-commande status.
Avant de commencer
Les utilisateurs qui ne sont pas des superutilisateurs doivent disposer de l'autorisation RBAC solaris.cluster.read pour utiliser cette sous-commande.
phys-schost# clnode status -m
Exemple 1-5 Vérification du statut du réseau public
L'exemple suivant présente un échantillon d'informations de statut des composants d'un cluster renvoyées par la commande clnode status.
% clnode status -m --- Node IPMP Group Status --- Node Name Group Name Status Adapter Status --------- ---------- ------ ------- ------ phys-schost-1 test-rg Online qfe1 Online phys-schost-2 test-rg Online qfe1 Online
Vous pouvez également effectuer cette procédure à l'aide de l'interface graphique d'Oracle Solaris Cluster Manager. Pour plus d'informations, consultez l'aide en ligne d'Oracle Solaris Cluster Manager.
L'élément phys-schost# fait référence à l'invite du cluster global. Appliquez cette procédure à un cluster global.
Cette procédure contient la forme longue des commandes d'Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. A l'exception de la forme du nom, ces commandes sont identiques.
Avant de commencer
Les utilisateurs qui ne sont pas des superutilisateurs doivent disposer de l'autorisation RBAC solaris.cluster.read pour utiliser la sous-commande status.
% cluster show
En exécutant la commande cluster show à partir d'un noeud votant du cluster global, vous pouvez afficher des informations de configuration détaillées concernant le cluster ainsi que des informations concernant les clusters de zones éventuellement configurés.
Vous pouvez également vous servir de la commande clzonecluster show pour afficher uniquement les informations de configuration du cluster de zones. Les propriétés d'un cluster de zones sont notamment son nom, le type d'IP, l'autoinitialisation et le chemin de la zone. La sous-commande show s'exécute à l'intérieur d'un cluster de zones et s'applique uniquement au cluster de zones concerné. Exécuter la commande clzonecluster show à partir d'un noeud d'un cluster de zones permet uniquement d'extraire le statut des objets visibles pour le cluster de zones concerné.
Pour afficher de plus amples informations sur la commande cluster, servez-vous des options détaillées. Reportez-vous à la page de manuel cluster(1CL) pour plus de détails. Reportez-vous à la page de manuel clzonecluster(1CL) pour plus d'informations sur clzonecluster.
Exemple 1-6 Affichage de la configuration du cluster global
L'exemple suivant liste les informations de configuration concernant le cluster global. Si vous avez configuré un cluster de zones, les informations relatives à ce cluster sont également affichées.
phys-schost# cluster show
=== Cluster ===
Cluster Name: cluster-1
clusterid: 0x50C000C4
installmode: disabled
heartbeat_timeout: 10000
heartbeat_quantum: 1000
private_netaddr: 172.16.0.0
private_netmask: 255.255.248.0
max_nodes: 62
num_zoneclusters: 1
max_privatenets: 10
global_fencing: pathcount
Node List: phys-schost-1
Node Zones: phys_schost-2:za
=== Host Access Control ===
Cluster name: clustser-1
Allowed hosts: phys-schost-1, phys-schost-2:za
Authentication Protocol: sys
=== Cluster Nodes ===
Node Name: phys-schost-1
Node ID: 1
Type: cluster
Enabled: yes
privatehostname: clusternode1-priv
reboot_on_path_failure: disabled
globalzoneshares: 3
defaultpsetmin: 1
quorum_vote: 1
quorum_defaultvote: 1
quorum_resv_key: 0x43CB1E1800000001
Transport Adapter List: qfe3, hme0
--- Transport Adapters for phys-schost-1 ---
Transport Adapter: qfe3
Adapter State: Enabled
Adapter Transport Type: dlpi
Adapter Property(device_name): qfe
Adapter Property(device_instance): 3
Adapter Property(lazy_free): 1
Adapter Property(dlpi_heartbeat_timeout): 10000
Adapter Property(dlpi_heartbeat_quantum): 1000
Adapter Property(nw_bandwidth): 80
Adapter Property(bandwidth): 10
Adapter Property(ip_address): 172.16.1.1
Adapter Property(netmask): 255.255.255.128
Adapter Port Names: 0
Adapter Port State(0): Enabled
Transport Adapter: hme0
Adapter State: Enabled
Adapter Transport Type: dlpi
Adapter Property(device_name): hme
Adapter Property(device_instance): 0
Adapter Property(lazy_free): 0
Adapter Property(dlpi_heartbeat_timeout): 10000
Adapter Property(dlpi_heartbeat_quantum): 1000
Adapter Property(nw_bandwidth): 80
Adapter Property(bandwidth): 10
Adapter Property(ip_address): 172.16.0.129
Adapter Property(netmask): 255.255.255.128
Adapter Port Names: 0
Adapter Port State(0): Enabled
--- SNMP MIB Configuration on phys-schost-1 ---
SNMP MIB Name: Event
State: Disabled
Protocol: SNMPv2
--- SNMP Host Configuration on phys-schost-1 ---
--- SNMP User Configuration on phys-schost-1 ---
SNMP User Name: foo
Authentication Protocol: MD5
Default User: No
Node Name: phys-schost-2:za
Node ID: 2
Type: cluster
Enabled: yes
privatehostname: clusternode2-priv
reboot_on_path_failure: disabled
globalzoneshares: 1
defaultpsetmin: 2
quorum_vote: 1
quorum_defaultvote: 1
quorum_resv_key: 0x43CB1E1800000002
Transport Adapter List: hme0, qfe3
--- Transport Adapters for phys-schost-2 ---
Transport Adapter: hme0
Adapter State: Enabled
Adapter Transport Type: dlpi
Adapter Property(device_name): hme
Adapter Property(device_instance): 0
Adapter Property(lazy_free): 0
Adapter Property(dlpi_heartbeat_timeout): 10000
Adapter Property(dlpi_heartbeat_quantum): 1000
Adapter Property(nw_bandwidth): 80
Adapter Property(bandwidth): 10
Adapter Property(ip_address): 172.16.0.130
Adapter Property(netmask): 255.255.255.128
Adapter Port Names: 0
Adapter Port State(0): Enabled
Transport Adapter: qfe3
Adapter State: Enabled
Adapter Transport Type: dlpi
Adapter Property(device_name): qfe
Adapter Property(device_instance): 3
Adapter Property(lazy_free): 1
Adapter Property(dlpi_heartbeat_timeout): 10000
Adapter Property(dlpi_heartbeat_quantum): 1000
Adapter Property(nw_bandwidth): 80
Adapter Property(bandwidth): 10
Adapter Property(ip_address): 172.16.1.2
Adapter Property(netmask): 255.255.255.128
Adapter Port Names: 0
Adapter Port State(0): Enabled
--- SNMP MIB Configuration on phys-schost-2 ---
SNMP MIB Name: Event
State: Disabled
Protocol: SNMPv2
--- SNMP Host Configuration on phys-schost-2 ---
--- SNMP User Configuration on phys-schost-2 ---
=== Transport Cables ===
Transport Cable: phys-schost-1:qfe3,switch2@1
Cable Endpoint1: phys-schost-1:qfe3
Cable Endpoint2: switch2@1
Cable State: Enabled
Transport Cable: phys-schost-1:hme0,switch1@1
Cable Endpoint1: phys-schost-1:hme0
Cable Endpoint2: switch1@1
Cable State: Enabled
Transport Cable: phys-schost-2:hme0,switch1@2
Cable Endpoint1: phys-schost-2:hme0
Cable Endpoint2: switch1@2
Cable State: Enabled
Transport Cable: phys-schost-2:qfe3,switch2@2
Cable Endpoint1: phys-schost-2:qfe3
Cable Endpoint2: switch2@2
Cable State: Enabled
=== Transport Switches ===
Transport Switch: switch2
Switch State: Enabled
Switch Type: switch
Switch Port Names: 1 2
Switch Port State(1): Enabled
Switch Port State(2): Enabled
Transport Switch: switch1
Switch State: Enabled
Switch Type: switch
Switch Port Names: 1 2
Switch Port State(1): Enabled
Switch Port State(2): Enabled
=== Quorum Devices ===
Quorum Device Name: d3
Enabled: yes
Votes: 1
Global Name: /dev/did/rdsk/d3s2
Type: scsi
Access Mode: scsi2
Hosts (enabled): phys-schost-1, phys-schost-2
Quorum Device Name: qs1
Enabled: yes
Votes: 1
Global Name: qs1
Type: quorum_server
Hosts (enabled): phys-schost-1, phys-schost-2
Quorum Server Host: 10.11.114.83
Port: 9000
=== Device Groups ===
Device Group Name: testdg3
Type: SVM
failback: no
Node List: phys-schost-1, phys-schost-2
preferenced: yes
numsecondaries: 1
diskset name: testdg3
=== Registered Resource Types ===
Resource Type: SUNW.LogicalHostname:2
RT_description: Logical Hostname Resource Type
RT_version: 2
API_version: 2
RT_basedir: /usr/cluster/lib/rgm/rt/hafoip
Single_instance: False
Proxy: False
Init_nodes: All potential masters
Installed_nodes: <All>
Failover: True
Pkglist: SUNWscu
RT_system: True
Resource Type: SUNW.SharedAddress:2
RT_description: HA Shared Address Resource Type
RT_version: 2
API_version: 2
RT_basedir: /usr/cluster/lib/rgm/rt/hascip
Single_instance: False
Proxy: False
Init_nodes: <Unknown>
Installed_nodes: <All>
Failover: True
Pkglist: SUNWscu
RT_system: True
Resource Type: SUNW.HAStoragePlus:4
RT_description: HA Storage Plus
RT_version: 4
API_version: 2
RT_basedir: /usr/cluster/lib/rgm/rt/hastorageplus
Single_instance: False
Proxy: False
Init_nodes: All potential masters
Installed_nodes: <All>
Failover: False
Pkglist: SUNWscu
RT_system: False
Resource Type: SUNW.haderby
RT_description: haderby server for Oracle Solaris Cluster
RT_version: 1
API_version: 7
RT_basedir: /usr/cluster/lib/rgm/rt/haderby
Single_instance: False
Proxy: False
Init_nodes: All potential masters
Installed_nodes: <All>
Failover: False
Pkglist: SUNWscderby
RT_system: False
Resource Type: SUNW.sctelemetry
RT_description: sctelemetry service for Oracle Solaris Cluster
RT_version: 1
API_version: 7
RT_basedir: /usr/cluster/lib/rgm/rt/sctelemetry
Single_instance: True
Proxy: False
Init_nodes: All potential masters
Installed_nodes: <All>
Failover: False
Pkglist: SUNWsctelemetry
RT_system: False
=== Resource Groups and Resources ===
Resource Group: HA_RG
RG_description: <Null>
RG_mode: Failover
RG_state: Managed
Failback: False
Nodelist: phys-schost-1 phys-schost-2
--- Resources for Group HA_RG ---
Resource: HA_R
Type: SUNW.HAStoragePlus:4
Type_version: 4
Group: HA_RG
R_description:
Resource_project_name: SCSLM_HA_RG
Enabled{phys-schost-1}: True
Enabled{phys-schost-2}: True
Monitored{phys-schost-1}: True
Monitored{phys-schost-2}: True
Resource Group: cl-db-rg
RG_description: <Null>
RG_mode: Failover
RG_state: Managed
Failback: False
Nodelist: phys-schost-1 phys-schost-2
--- Resources for Group cl-db-rg ---
Resource: cl-db-rs
Type: SUNW.haderby
Type_version: 1
Group: cl-db-rg
R_description:
Resource_project_name: default
Enabled{phys-schost-1}: True
Enabled{phys-schost-2}: True
Monitored{phys-schost-1}: True
Monitored{phys-schost-2}: True
Resource Group: cl-tlmtry-rg
RG_description: <Null>
RG_mode: Scalable
RG_state: Managed
Failback: False
Nodelist: phys-schost-1 phys-schost-2
--- Resources for Group cl-tlmtry-rg ---
Resource: cl-tlmtry-rs
Type: SUNW.sctelemetry
Type_version: 1
Group: cl-tlmtry-rg
R_description:
Resource_project_name: default
Enabled{phys-schost-1}: True
Enabled{phys-schost-2}: True
Monitored{phys-schost-1}: True
Monitored{phys-schost-2}: True
=== DID Device Instances ===
DID Device Name: /dev/did/rdsk/d1
Full Device Path: phys-schost-1:/dev/rdsk/c0t2d0
Replication: none
default_fencing: global
DID Device Name: /dev/did/rdsk/d2
Full Device Path: phys-schost-1:/dev/rdsk/c1t0d0
Replication: none
default_fencing: global
DID Device Name: /dev/did/rdsk/d3
Full Device Path: phys-schost-2:/dev/rdsk/c2t1d0
Full Device Path: phys-schost-1:/dev/rdsk/c2t1d0
Replication: none
default_fencing: global
DID Device Name: /dev/did/rdsk/d4
Full Device Path: phys-schost-2:/dev/rdsk/c2t2d0
Full Device Path: phys-schost-1:/dev/rdsk/c2t2d0
Replication: none
default_fencing: global
DID Device Name: /dev/did/rdsk/d5
Full Device Path: phys-schost-2:/dev/rdsk/c0t2d0
Replication: none
default_fencing: global
DID Device Name: /dev/did/rdsk/d6
Full Device Path: phys-schost-2:/dev/rdsk/c1t0d0
Replication: none
default_fencing: global
=== NAS Devices ===
Nas Device: nas_filer1
Type: sun
User ID: root
Nas Device: nas2
Type: sun
User ID: llaiExemple 1-7 Affichage de la configuration du cluster de zones
L'exemple ci-dessous répertorie les propriétés de la configuration d'un cluster de zones.
% clzonecluster show
=== Zone Clusters ===
Zone Cluster Name: sczone
zonename: sczone
zonepath: /zones/sczone
autoboot: TRUE
ip-type: shared
enable_priv_net: TRUE
--- Solaris Resources for sczone ---
Resource Name: net
address: 172.16.0.1
physical: auto
Resource Name: net
address: 172.16.0.2
physical: auto
Resource Name: fs
dir: /gz/db_qfs/CrsHome
special: CrsHome
raw:
type: samfs
options: []
Resource Name: fs
dir: /gz/db_qfs/CrsData
special: CrsData
raw:
type: samfs
options: []
Resource Name: fs
dir: /gz/db_qfs/OraHome
special: OraHome
raw:
type: samfs
options: []
Resource Name: fs
dir: /gz/db_qfs/OraData
special: OraData
raw:
type: samfs
options: []
--- Zone Cluster Nodes for sczone ---
Node Name: sczone-1
physical-host: sczone-1
hostname: lzzone-1
Node Name: sczone-2
physical-host: sczone-2
hostname: lzzone-2
Vous pouvez également afficher les périphériques NAS configurés pour les clusters de zones et les clusters globaux à l'aide de la sous-commande clnasdevice show ou d'Oracle Solaris Cluster Manager. Pour plus d'informations, reportez-vous à la page de manuel clnasdevice(1CL).
La commande cluster(1CL) utilise la sous-commande check pour valider la configuration de base nécessaire pour permettre le fonctionnement correct d'un cluster global. Si aucune vérification n'échoue, cluster check revient à l'invite shell. Si une vérification échoue, cluster check génère des rapports dans le répertoire spécifié ou à l'emplacement par défaut. Si vous exécutez cluster check pour plusieurs noeuds, cluster check génère un rapport distinct pour chaque noeud ainsi qu'un rapport global pour l'ensemble des vérifications. Vous pouvez aussi exécuter la commande cluster list-checks pour afficher la liste de toutes les vérifications disponibles pour le cluster.
A partir de la version 3.3 5/11 d'Oracle Solaris Cluster, la commande cluster check a été améliorée et nouveaux types de vérifications ont été ajoutés. En plus des vérifications de base, qui s'exécutent sans l'interaction de l'utilisateur, la commande peut également exécuter des vérifications interactives et des vérifications fonctionnelles. Les vérifications de base sont exécutées lorsque l'option - k keyword n'est pas spécifiée.
Les vérifications interactives nécessitent des informations de la part de l'utilisateur que les vérifications ne peuvent pas déterminer. La vérification invite l'utilisateur à fournir les informations nécessaires, par exemple, le numéro de version du microprogramme. Utilisez le mot-clé -k interactive pour spécifier une ou plusieurs vérifications interactives.
Les vérifications fonctionnelles portent sur une fonction ou un comportement spécifique du cluster. La vérification invite l'utilisateur à saisir des informations, par exemple à spécifier le noeud vers lequel basculer, ainsi qu'à confirmer le démarrage ou la poursuite de la vérification. Utilisez le mot-clé -k functional check-id pour spécifier une vérification fonctionnelle. Effectuez une seule vérification fonctionnelle à la fois.
Remarque - Dans la mesure où certaines vérifications fonctionnelles impliquent l'interruption du fonctionnement du cluster, ne débutez aucune vérification fonctionnelle avant d'avoir lu la description détaillée de la vérification et déterminez si vous devez d'abord retirer le cluster de l'environnement de production. Pour afficher ces informations, utilisez la commande suivante :
% cluster list-checks -v -C checkID
Vous pouvez exécuter la commande cluster check en mode détaillé en ajoutant l'indicateur -v pour suivre l'avancement.
Remarque - Exécutez cluster check après avoir effectué une procédure d'administration susceptible de modifier les périphériques, les composants de gestion des volumes ou la configuration Oracle Solaris Cluster.
L'exécution de la commande clzonecluster(1CL) à partir du noeud votant du cluster global déclenche un ensemble de vérifications dont l'objet est de valider la configuration nécessaire pour permettre le fonctionnement correct d'un cluster de zones. Si toutes les vérifications réussissent, clzonecluster verify revient à l'invite de shell et vous pouvez installer le cluster de zones en toute sécurité. Si une vérification échoue, clzonecluster verify consigne les noeuds du cluster global sur lesquels la vérification a échoué. Si vous exécutez clzonecluster verify pour plusieurs noeuds, un rapport distinct est généré pour chaque noeud ainsi qu'un rapport global pour l'ensemble des vérifications. La sous-commande verify n'est pas autorisée à l'intérieur d'un cluster de zones.
phys-schost# su
Accédez à l'onglet Patches & Updates de la page My Oracle Support. A l'aide de la recherche avancée, sélectionnez “Solaris Cluster” en tant que produit et spécifiez “check” dans le champ de description pour localiser les patchs Oracle Solaris Cluster qui contiennent des vérifications. Appliquez tous les patchs qui ne sont pas déjà installés sur votre cluster.
# cluster check -v -o outputdir
Mode détaillé
Redirige la sortie vers le sous-répertoire outputdir.
La commande exécute tous les vérifications basiques disponibles. Aucune fonctionnalité du cluster n'est affectée.
# cluster check -v -k interactive -o outputdir
Indique l'exécution de vérifications de validation interactives.
La commande exécute toutes les vérifications interactives disponibles et vous invite à entrer les informations nécessaires concernant le cluster. Aucune fonctionnalité du cluster n'est affectée.
# cluster list-checks -k functional
Par exemple, une vérification fonctionnelle peut déclencher une grave erreur de noeud ou un basculement vers un autre noeud.
# cluster list-checks -v -C checkID
Spécifie une vérification spécifique.
# cluster check -v -k functional -C checkid -o outputdir
Indique l'exécution de vérifications de validation fonctionnelle.
Répondez aux invites générées par la vérification pour confirmer que la vérification doit s'exécuter, spécifiez les informations demandées et exécutez les opérations requises.
Remarque - A des fins de suivi, spécifiez un nom de sous-répertoire outputdir unique pour chaque vérification exécutée. Si vous réutilisez un nom outputdir, la sortie de la nouvelle vérification écrase le contenu existant du sous-répertoire outputdir réutilisé.
phys-schost# clzonecluster verify zoneclustername
Reportez-vous à la section Enregistrement des données de diagnostic de la configuration en cluster du manuel Guide d’installation du logiciel Oracle Solaris Cluster.
Exemple 1-8 Vérification de la configuration du cluster global avec réussite de toutes les vérifications basiques
L'exemple suivant illustre l'exécution de cluster check en mode détaillé pour les noeuds phys-schost-1 et phys-schost-2 , toutes les vérifications se soldant par une réussite.
phys-schost# cluster check -v -h phys-schost-1,
phys-schost-2
cluster check: Requesting explorer data and node report from phys-schost-1.
cluster check: Requesting explorer data and node report from phys-schost-2.
cluster check: phys-schost-1: Explorer finished.
cluster check: phys-schost-1: Starting single-node checks.
cluster check: phys-schost-1: Single-node checks finished.
cluster check: phys-schost-2: Explorer finished.
cluster check: phys-schost-2: Starting single-node checks.
cluster check: phys-schost-2: Single-node checks finished.
cluster check: Starting multi-node checks.
cluster check: Multi-node checks finished
# Exemple 1-9 Création de listes de vérifications de validation interactives
L'exemple suivant permet de répertorier toutes les vérifications interactives qui peuvent être exécutées sur le cluster. L'exemple suivant montre un échantillon des vérifications possibles. Les vérifications disponibles varient selon la configuration.
# cluster list-checks -k interactive Some checks might take a few moments to run (use -v to see progress)... I6994574 : (Moderate) Fix for GLDv3 interfaces on cluster transport vulnerability applied?
Exemple 1-10 Exécution d'une vérification de validation fonctionnelle
L'exemple suivant permet d'abord d'afficher la liste détaillée des vérifications fonctionnelles. Une description détaillée de la vérification F6968101 est ensuite fournie, laquelle indique que la vérification aurait une incidence sur le fonctionnement des services du cluster. Le cluster est exclu de la production. La vérification fonctionnelle est ensuite exécutée et la sortie détaillée est consignée dans le sous-répertoire funct.test.F6968101.12Jan2011. L'exemple suivant montre un échantillon des vérifications possibles. Les vérifications disponibles varient selon la configuration.
# cluster list-checks -k functional
F6968101 : (Critical) Perform resource group switchover
F6984120 : (Critical) Induce cluster transport network failure - single adapter.
F6984121 : (Critical) Perform cluster shutdown
F6984140 : (Critical) Induce node panic
…
# cluster list-checks -v -C F6968101
F6968101: (Critical) Perform resource group switchover
Keywords: SolarisCluster3.x, functional
Applicability: Applicable if multi-node cluster running live.
Check Logic: Select a resource group and destination node. Perform
'/usr/cluster/bin/clresourcegroup switch' on specified resource group
either to specified node or to all nodes in succession.
Version: 1.2
Revision Date: 12/10/10
Take the cluster out of production
# cluster check -k functional -C F6968101 -o funct.test.F6968101.12Jan2011
F6968101
initializing...
initializing xml output...
loading auxiliary data...
starting check run...
pschost1, pschost2, pschost3, pschost4: F6968101.... starting:
Perform resource group switchover
============================================================
>>> Functional Check <<<
'Functional' checks exercise cluster behavior. It is recommended that you
do not run this check on a cluster in production mode.' It is recommended
that you have access to the system console for each cluster node and
observe any output on the consoles while the check is executed.
If the node running this check is brought down during execution the check
must be rerun from this same node after it is rebooted into the cluster in
order for the check to be completed.
Select 'continue' for more details on this check.
1) continue
2) exit
choice: 1
============================================================
>>> Check Description <<<
…
Follow onscreen directionsExemple 1-11 Vérification de la configuration du cluster global avec échec d'une vérification
L'exemple suivant présente le noeud phys-schost-2 dans le cluster nommé suncluster moins le point de montage /global/phys-schost-1 . Les rapports sont créés dans le répertoire /var/cluster/logs/cluster_check/<timestamp>.
phys-schost# cluster check -v -h phys-schost-1,
phys-schost-2 -o
/var/cluster/logs/cluster_check/Dec5/
cluster check: Requesting explorer data and node report from phys-schost-1.
cluster check: Requesting explorer data and node report from phys-schost-2.
cluster check: phys-schost-1: Explorer finished.
cluster check: phys-schost-1: Starting single-node checks.
cluster check: phys-schost-1: Single-node checks finished.
cluster check: phys-schost-2: Explorer finished.
cluster check: phys-schost-2: Starting single-node checks.
cluster check: phys-schost-2: Single-node checks finished.
cluster check: Starting multi-node checks.
cluster check: Multi-node checks finished.
cluster check: One or more checks failed.
cluster check: The greatest severity of all check failures was 3 (HIGH).
cluster check: Reports are in /var/cluster/logs/cluster_check/<Dec5>.
#
# cat /var/cluster/logs/cluster_check/Dec5/cluster_check-results.suncluster.txt
...
===================================================
= ANALYSIS DETAILS =
===================================================
------------------------------------
CHECK ID : 3065
SEVERITY : HIGH
FAILURE : Global filesystem /etc/vfstab entries are not consistent across
all Oracle Solaris Cluster 3.x nodes.
ANALYSIS : The global filesystem /etc/vfstab entries are not consistent across
all nodes in this cluster.
Analysis indicates:
FileSystem '/global/phys-schost-1' is on 'phys-schost-1' but missing from 'phys-schost-2'.
RECOMMEND: Ensure each node has the correct /etc/vfstab entry for the
filesystem(s) in question.
...
#
La commande cluster(1CL) comprend des vérifications examinant le fichier /etc/vfstab et visant à repérer les erreurs de configuration affectant le système de fichiers du cluster et ses points de montage globaux.
Remarque - Exécutez cluster check après avoir apporté des modifications à la configuration du cluster ayant affecté les périphériques ou les composants de gestion des volumes.
Effectuez toutes les étapes de cette procédure à partir d'un noeud du cluster global.
% su
phys-schost# cluster check
Exemple 1-12 Vérification des points de montage globaux
L'exemple suivant présente le noeud phys-schost-2 du cluster nommé suncluster moins le point de montage /global/schost-1 . Les rapports sont envoyés dans le répertoire /var/cluster/logs/cluster_check/<timestamp>/.
phys-schost# cluster check -v1 -h phys-schost-1,phys-schost-2 -o /var/cluster//logs/cluster_check/Dec5/ cluster check: Requesting explorer data and node report from phys-schost-1. cluster check: Requesting explorer data and node report from phys-schost-2. cluster check: phys-schost-1: Explorer finished. cluster check: phys-schost-1: Starting single-node checks. cluster check: phys-schost-1: Single-node checks finished. cluster check: phys-schost-2: Explorer finished. cluster check: phys-schost-2: Starting single-node checks. cluster check: phys-schost-2: Single-node checks finished. cluster check: Starting multi-node checks. cluster check: Multi-node checks finished. cluster check: One or more checks failed. cluster check: The greatest severity of all check failures was 3 (HIGH). cluster check: Reports are in /var/cluster/logs/cluster_check/Dec5. # # cat /var/cluster/logs/cluster_check/Dec5/cluster_check-results.suncluster.txt ... =================================================== = ANALYSIS DETAILS = =================================================== ------------------------------------ CHECK ID : 3065 SEVERITY : HIGH FAILURE : Global filesystem /etc/vfstab entries are not consistent across all Oracle Solaris Cluster 3.x nodes. ANALYSIS : The global filesystem /etc/vfstab entries are not consistent across all nodes in this cluster. Analysis indicates: FileSystem '/global/phys-schost-1' is on 'phys-schost-1' but missing from 'phys-schost-2'. RECOMMEND: Ensure each node has the correct /etc/vfstab entry for the filesystem(s) in question. ... # # cat /var/cluster/logs/cluster_check/Dec5/cluster_check-results.phys-schost-1.txt ... =================================================== = ANALYSIS DETAILS = =================================================== ------------------------------------ CHECK ID : 1398 SEVERITY : HIGH FAILURE : An unsupported server is being used as an Oracle Solaris Cluster 3.x node. ANALYSIS : This server may not been qualified to be used as an Oracle Solaris Cluster 3.x node. Only servers that have been qualified with Oracle Solaris Cluster 3.x are supported as Oracle Solaris Cluster 3.x nodes. RECOMMEND: Because the list of supported servers is always being updated, check with your Oracle representative to get the latest information on what servers are currently supported and only use a server that is supported with Oracle Solaris Cluster 3.x. ... #
Le fichier texte ASCII /var/cluster/logs/commandlog contient des enregistrements relatifs à des commandes Oracle Solaris Cluster sélectionnées ayant été exécutées dans un cluster. La journalisation des commandes débute automatiquement lorsque vous configurez le cluster et s'achève lorsque vous arrêtez le cluster. Les commandes sont journalisées sur tous les noeuds en cours d'exécution et initialisés en mode cluster.
Ne sont pas journalisées dans ce fichier les commandes permettant d'afficher la configuration et l'état courant du cluster.
Sont journalisées dans ce fichier notamment les commandes permettant de configurer et de modifier l'état courant du cluster.
claccess
cldevice
cldevicegroup
clinterconnect
clnasdevice
clnode
clquorum
clreslogicalhostname
clresource
clresourcegroup
clresourcetype
clressharedaddress
clsetup
clsnmphost
clsnmpmib
clnsmpuser
cltelemetryattribute
cluster
clzonecluster
scdidadm
Les enregistrements du fichier commandlog peuvent inclure les éléments suivants :
Date et horodatage.
Nom de l'hôte depuis lequel la commande a été exécutée.
ID de processus de la commande.
Nom de connexion de l'utilisateur qui a exécuté la commande.
Commande exécutée par l'utilisateur, y compris toutes options et opérandes.
Remarque - Les options des commandes sont consignées dans le fichier commandlog, ce qui vous permet de les identifier facilement et de les copier, coller et exécuter dans le shell.
Statut de sortie de la commande exécutée.
Remarque - Si une commande est abandonnée de façon anormale avec un résultat inconnu, le logiciel Oracle Solaris Cluster n'affiche aucun état de sortie dans le fichier commandlog.
Par défaut, le fichier commandlog est archivé une fois par semaine. Pour modifier les stratégies d'archivage du fichier commandlog, exécutez la commande crontab sur chaque noeud du cluster. Pour plus d'informations, reportez-vous à la page de manuel crontab(1).
A tout moment, le logiciel Oracle Solaris Cluster conserve sur chaque noeud du cluster jusqu'à huit fichiers commandlog précédemment archivés. Le fichier commandlog de la semaine en cours est nommé commandlog. Le fichier portant sur une semaine entière le plus récent est nommé commandlog.0. Le fichier portant sur une semaine entière le plus ancien est nommé commandlog.7.
phys-schost# more /var/cluster/logs/commandlog
Exemple 1-13 Affichage du contenu des journaux de commandes d'Oracle Solaris Cluster
L'exemple suivant illustre le contenu du fichier commandlog affiché à l'aide de la commande more.
more -lines10 /var/cluster/logs/commandlog 11/11/2006 09:42:51 phys-schost-1 5222 root START - clsetup 11/11/2006 09:43:36 phys-schost-1 5758 root START - clrg add "app-sa-1" 11/11/2006 09:43:36 phys-schost-1 5758 root END 0 11/11/2006 09:43:36 phys-schost-1 5760 root START - clrg set -y "RG_description=Department Shared Address RG" "app-sa-1" 11/11/2006 09:43:37 phys-schost-1 5760 root END 0 11/11/2006 09:44:15 phys-schost-1 5810 root START - clrg online "app-sa-1" 11/11/2006 09:44:15 phys-schost-1 5810 root END 0 11/11/2006 09:44:19 phys-schost-1 5222 root END -20988320 12/02/2006 14:37:21 phys-schost-1 5542 jbloggs START - clrg -c -g "app-sa-1" -y "RG_description=Joe Bloggs Shared Address RG" 12/02/2006 14:37:22 phys-schost-1 5542 jbloggs END 0
|