| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Guide d'administration système d'Oracle Solaris Cluster Oracle Solaris Cluster (Français) |
| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
|
Guide d'administration système d'Oracle Solaris Cluster Oracle Solaris Cluster (Français) |
1. Introduction à 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 en 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
Établissement d'une connexion distante au cluster
Établissement d'une connexion sécurisée aux consoles du cluster
Accès aux utilitaires de configuration du cluster
Affichage des informations d'un patch Oracle Solaris Cluster
Affichage des informations de version de 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. Fermeture 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 n
ud
10. Configuration du contrôle de l'utilisation du CPU
11. Mise à jour du logiciel ou installation d'un microprogramme Oracle Solaris Cluster
12. Sauvegarde et restauration d'un cluster
13. Administration de 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 uniquement exécutables à partir du nœud votant du cluster global ne peuvent pas être utilisées avec 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 Oracle Solaris Cluster
|
Cluster Control Panel (CCP) constitue une zone de lancement pour les outils cconsole, crlogin, cssh, et ctelnet. Tous les outils établissent une connexion à fenêtres multiples à un ensemble de nœuds spécifiés. La connexion à fenêtres multiples comprend une fenêtre hôte pour chacun des nœuds spécifiés et une fenêtre commune. Les saisies effectuées dans la fenêtre commune sont envoyées à chacune des fenêtres hôtes, ce qui vous permet d'exécuter des commandes simultanément sur tous les nœuds du cluster.
Vous pouvez aussi lancer des sessions cconsole, crlogin, cssh ou ctelnet depuis la ligne de commande.
Par défaut, l'utilitaire cconsole établit une connexion telnet aux consoles des nœuds. Pour établir des connexions par shell sécurisé aux consoles, cochez la case Utiliser SSH dans le menu Options de la fenêtre cconsole. Vous pouvez aussi spécifier l'option -s lorsque vous lancez la commande ccp ou la commande 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 utilise les formes longues des commandes Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. À l'exception de la forme du nom, ces commandes sont identiques.
Avant de commencer
Assurez-vous que les conditions suivantes sont remplies avant de démarrer 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 emplacement de rechange pour le répertoire des outils en définissant la variable d'environnement $CLUSTER_HOME.
Configurez le fichier clusters, le fichier serialports ainsi que 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 zone de lancement CCP s'affiche.
Suivez cette procédure pour vous connecter par shell sécurisé aux consoles des nœuds du cluster.
Avant de commencer
Configurez le fichier clusters, le fichier serialports ainsi que 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, assignez le numéro de port à utiliser pour la connexion sécurisée à chaque périphérique d'accès par console. Le numéro de port par défaut pour la connexion par 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 par 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 entré au moment du lancement de l'utilitaire cconsole est utilisé.
Spécifie le numéro de port à utiliser pour le shell sécurisé. Si l'option -p n'est pas spécifiée, le numéro de port 22 est utilisé par défaut pour les connexions sécurisées.
L'utilitaire clsetup permet de configurer de manière interactive les options du quorum, des groupes de ressources, du transport intracluster, des noms d'hôtes privés, des groupes de périphériques et des nouveaux nœuds 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 utilise les formes longues des commandes Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. À 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> ?
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 utilise les formes longues des commandes Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. À l'exception de la forme du nom, ces commandes sont identiques.
phys-schost# showrev -p
Les versions de mise à jour de Oracle Solaris Cluster sont identifiées par le numéro de patch du produit principal et la version de la mise à jour.
Exemple 1-1 Affichage des informations du patch Oracle Solaris Cluster
L'exemple suivant illustre l'affichage des informations du 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 nœud 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 utilise les formes longues des commandes Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. À 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 de Oracle Solaris Cluster et les chaînes de versions de tous les packages Oracle Solaris Cluster.
Exemple 1-2 Affichage des informations de version de Oracle Solaris Cluster
L'exemple suivant illustre l'affichage des informations de version du cluster et de tous les packages.
phys-schost# clnode show-rev 3.2 phys-schost#% clnode show-rev -v Oracle Solaris Cluster 3.3 for Solaris 10 sparc 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 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 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 SUNWscgrepsrdf: 3.2.3,REV=2009.10.23.12.12 SUNWscgreptc: 3.2.3,REV=2009.10.23.12.12 SUNWscghb: 3.2.3,REV=2009.10.23.12.12 SUNWscgctl: 3.2.3,REV=2009.10.23.12.12 SUNWscims: 6.0,REV=2003.10.29 SUNWscics: 6.0,REV=2003.11.14 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 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 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 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 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 aussi effectuer cette procédure par l'intermédiaire de l'interface graphique de Oracle Solaris Cluster Manager. Pour plus d'informations, reportez-vous au Chapitre 13, Administration de Oracle Solaris Cluster avec les interfaces graphiques ou à 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 utilise les formes longues des commandes Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. À l'exception de la forme du nom, ces commandes sont identiques.
Avant de commencer
Les utilisateurs qui ne sont pas des superutilisateurs doivent disposer des droits d'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 ressources 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
=== 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 aussi effectuer cette procédure par l'intermédiaire de l'interface graphique de Oracle Solaris Cluster Manager. Pour plus d'informations, consultez l'aide en ligne de Oracle Solaris Cluster Manager.
Remarque - La commande cluster status permet également d'afficher 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 utilise les formes longues des commandes Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. À l'exception de la forme du nom, ces commandes sont identiques.
Avant de commencer
Les utilisateurs qui ne sont pas des superutilisateurs doivent disposer des droits d'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 extrait des informations de statut concernant les composants d'un cluster retournées par 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 aussi effectuer cette procédure par l'intermédiaire de l'interface graphique de Oracle Solaris Cluster Manager. Pour plus d'informations, consultez l'aide en ligne de 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 utilise les formes longues des commandes Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. À l'exception de la forme du nom, ces commandes sont identiques.
Pour vérifier le statut des groupes IPMP (IP Network Multipathing), utilisez la commande clnode(1CL) et la sous-commande status .
Avant de commencer
Les utilisateurs qui ne sont pas des superutilisateurs doivent disposer des droits d'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 extrait des informations de statut concernant les composants du cluster retourné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 aussi effectuer cette opération par l'intermédiaire de l'interface graphique de Oracle Solaris Cluster Manager. Pour plus d'informations, consultez l'aide en ligne de 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 utilise les formes longues des commandes Oracle Solaris Cluster. La plupart des commandes possèdent également des formes brèves. À l'exception de la forme du nom, ces commandes sont identiques.
Avant de commencer
Les utilisateurs qui ne sont pas des superutilisateurs doivent disposer des droits d'autorisation RBAC solaris.cluster.read pour utiliser la sous-commande status.
% cluster show
En exécutant la commande cluster show à partir d'un nœud 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 nœud 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
installmode: disabled
heartbeat_timeout: 10000
heartbeat_quantum: 1000
private_netaddr: 172.16.0.0
private_netmask: 255.255.248.0
max_nodes: 64
max_privatenets: 10
global_fencing: Unknown
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: netapp
User ID: root
Nas Device: nas2
Type: netapp
User ID: llaiExemple 1-7 Affichage de la configuration du cluster de zones
L'exemple suivant liste les propriétés de la configuration du 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 zone 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 basique requise pour qu'un cluster global puisse fonctionner correctement. Si aucune vérification n'échoue, cluster check revient à l'invite de 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 nœuds, cluster check génère un rapport distinct pour chaque nœud 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.
Début de la &ProductName ; 3.3 5/11 version, la vérification du cluster commande est améliorée grâce aux nouveaux types de vérifications. En plus des contrôles de base, qui s'exécutent sans l'interaction de l'utilisateur, la commande peut également exécuter interactive vérifie et vérifications fonctionnelles. Des contrôles de base sont exécutés lorsque les - k mot-clé option n'est pas spécifiée.
Interactive vérifications nécessitent plus d'informations à partir de l'utilisateur que les contrôles ne peut pas déterminer. La case invite l'utilisateur à fournir les informations nécessaires, par exemple, le numéro de version du microprogramme. Utilisez les -k interactive mot-clé pour spécifier un ou plusieurs interactive vérifie.
Les contrôles fonctionnels exercer une fonction spécifique ou un comportement du cluster. La case invite l'intervention de l'utilisateur, tels que le noeud de basculer vers, ainsi que la confirmation de commencer ou continuer l'intégration. Utilisez les - k fonctionnel check-id mot-clé pour spécifier une vérification fonctionnelle. Effectuer une seule vérification fonctionnelle à la fois.
Remarque - Dans la mesure où certaines vérifications fonctionnelles impliquent l'interruption cluster service, ne pas commencer à n'importe quel contrôle fonctionnels avant d'avoir lu la description détaillée de la vérification et déterminez si vous devez d'abord prendre le cluster hors 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 nœud 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 nœuds du cluster global sur lesquels la vérification a échoué. Si vous exécutez clzonecluster verify pour plusieurs nœuds, un rapport distinct est généré pour chaque nœud 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 My Oracle Support. À l'aide de la recherche avancée, sélectionnez "Solaris Cluster" comme le produit et d'indiquer "vérifier" dans le champ Description pour localiser &ProductName ; correctifs qui contiennent vérifie. Appliquer les correctifs qui n'est pas déjà installé sur votre cluster.
# cluster check -v -o outputdir
Le mode détaillé
Redirige la sortie vers le ( sous-répertoire.
La commande exécute toutes disponibles des contrôles de base. Aucune fonctionnalité de cluster est affecté.
# cluster check -v -k interactive -o outputdir
Indique l'exécution interactive les contrôles de validation
La commande s'exécute toutes les vérifications interactif disponible et vous invite à entrer des informations nécessaires sur le cluster. Aucune fonctionnalité de cluster est affecté.
# cluster list-checks -k functional
Par exemple, une vérification comptable peut déclencher un noeud paniquer ou un basculement vers un autre nœud.
# cluster list-checks -v -C checkID
Spécifie une vérification spécifique.
# cluster check -v -k functional -C checkid -o outputdir
Contrôles de validation fonctionnelle Indique l'exécution
Répondre à des invites à partir de la case pour confirmer que le chèque doit s'exécuter, et pour tout type d'information ou les actions que vous devez effectuer.
Remarque - Pour le suivi des enregistrements des fins, spécifiez un unique ( nom du sous-répertoire pour chaque vérification de l'exécution. Si vous réutilisez un ( nom, la sortie de la nouvelle case écrase le contenu existant de la réutiliser ( sous-répertoire.
phys-schost# clzonecluster verify zoneclustername
Reportez-vous à la rubrique Enregistrement des données de diagnostic de la configuration en cluster du 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 nœuds 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 Annonce Interactive Les contrôles de validation
L'exemple suivant répertorie tous les contrôles interactifs qui sont disponibles pour l'exécuter sur le cluster. L'exemple suivant montre un échantillonnage de contrôle possible ; disponibilité réelle vérifie varient pour chaque 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 L'exécution d'un contrôle de validation fonctionnelle
L'exemple suivant montre la liste détaillée des vérifications fonctionnelles. La description détaillée est ensuite répertorié pour le vérifier F6968101, ce qui indique que la case perturberait cluster services. Le cluster est extraite de la production. La vérification fonctionnelle est ensuite exécutée avec le résultat détaillé connecté à la endroit.test.F6968101.12Jan2011 sous-répertoire. L'exemple suivant montre un échantillonnage de contrôle possible ; disponibilité réelle vérifie varient pour chaque 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 nœud 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) inclut des vérifications examinant le fichier /etc/vfstab et visant à repérer les erreurs de configuration concernant 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 nœud du cluster global.
% su
phys-schost# cluster check
Exemple 1-12 Vérification des points de montage globaux
L'exemple suivant présente le nœud 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 nœuds 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 nœud du cluster. Pour plus d'informations, reportez-vous à la page de manuel crontab(1).
À tout moment, le logiciel Oracle Solaris Cluster conserve sur chaque nœud 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 de 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
|