| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
Guide d'administration système d'Oracle Solaris Cluster Oracle Solaris Cluster 4.0 (Français) |
| Ignorer les liens de navigation | |
| Quitter l'aperu | |
|
|
Guide d'administration système d'Oracle Solaris Cluster Oracle Solaris Cluster 4.0 (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
Etablissement d'une connexion distante au cluster
Etablissement d'une connexion sécurisée aux consoles du cluster
Accès aux utilitaires de configuration du 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 noeud
10. Configuration du contrôle de l'utilisation de la CPU
Le Tableau 1-2 vous indique comment débuter l'administration de votre cluster.
Tableau 1-2 Outils d'administration d'Oracle Solaris Cluster
|
Vous pouvez utiliser l'utilitaire Parallel Console Access (pconsole) à partir de la ligne de commande pour vous connecter au cluster à distance. L'utilitaire pconsole fait partie du package terminal/pconsole d'Oracle Solaris. Installez le package en exécutant la commande pkg install terminal/pconsole. L'utilitaire pconsole crée une fenêtre de terminal hôte pour chaque hôte distant spécifié sur la ligne de commande. L'utilitaire ouvre également une fenêtre de console centrale, ou maître, qui propage ce que vous y saisissez à chaque fois que vous ouvrez une connexion.
L'utilitaire pconsole peut être exécuté à partir de fenêtres X ou en mode console. Installez pconsole sur la machine que vous utiliserez en tant que console administrative pour le cluster. Si vous disposez d'un serveur de terminal qui vous permet de vous connecter à des numéros de port spécifiques sur l'adresse IP du serveur, vous pouvez spécifier le numéro de port en plus du nom d'hôte et de l'adresse IP, comme suit : terminal-server:portnumber.
Pour de plus amples informations, reportez-vous à la page de manuel pconsole(1).
Si votre concentrateur de terminaux ou votre contrôleur système prend en charge ssh, vous pouvez utiliser l'utilitaire pconsole pour établir une connexion aux consoles de ces systèmes. L'utilitaire pconsole fait partie du package terminal/pconsole d'Oracle Solaris et est installé lors de l'installation du package. L'utilitaire pconsole crée une fenêtre de terminal hôte pour chaque hôte distant spécifié sur la ligne de commande. L'utilitaire ouvre également une fenêtre de console centrale, ou maître, qui propage ce que vous y saisissez à chaque fois que vous ouvrez une connexion. Pour de plus amples informations, reportez-vous à la page de manuel pconsole(1).
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 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 de 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.
Effectuez toutes les étapes de cette procédure à partir d'un noeud du cluster global.
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> ?
Suivez les instructions qui s'affichent à l'écran pour effectuer une tâche. Pour plus d'informations, reportez-vous aux instructions de la section Configuration d’un cluster de zones du manuel Guide d’installation du logiciel Oracle Solaris Cluster.
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. 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 de 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 de Oracle Solaris Cluster et les chaînes de versions de tous les packages Oracle Solaris Cluster.
Exemple 1-1 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 fournis avec Oracle Solaris Cluster 4.0.
phys-schost# clnode show-rev 4.0 phys-schost#% clnode show-rev -v Oracle Solaris Cluster 4.0 for Solaris 11 sparc ha-cluster/data-service/apache :4.0.0-0.21 ha-cluster/data-service/dhcp :4.0.0-0.21 ha-cluster/data-service/dns :4.0.0-0.21 ha-cluster/data-service/ha-ldom :4.0.0-0.21 ha-cluster/data-service/ha-zones :4.0.0-0.21 ha-cluster/data-service/nfs :4.0.0-0.21 ha-cluster/data-service/oracle-database :4.0.0-0.21 ha-cluster/data-service/tomcat :4.0.0-0.21 ha-cluster/data-service/weblogic :4.0.0-0.21 ha-cluster/developer/agent-builder :4.0.0-0.21 ha-cluster/developer/api :4.0.0-0.21 ha-cluster/geo/geo-framework :4.0.0-0.21 ha-cluster/geo/manual :4.0.0-0.21 ha-cluster/geo/replication/availability-suite :4.0.0-0.21 ha-cluster/geo/replication/data-guard :4.0.0-0.21 ha-cluster/geo/replication/sbp :4.0.0-0.21 ha-cluster/geo/replication/srdf :4.0.0-0.21 ha-cluster/group-package/ha-cluster-data-services-full :4.0.0-0.21 ha-cluster/group-package/ha-cluster-framework-full :4.0.0-0.21 ha-cluster/group-package/ha-cluster-framework-l10n :4.0.0-0.21 ha-cluster/group-package/ha-cluster-framework-minimal :4.0.0-0.21 ha-cluster/group-package/ha-cluster-framework-scm :4.0.0-0.21 ha-cluster/group-package/ha-cluster-framework-slm :4.0.0-0.21 ha-cluster/group-package/ha-cluster-full :4.0.0-0.21 ha-cluster/group-package/ha-cluster-geo-full :4.0.0-0.21 ha-cluster/group-package/ha-cluster-geo-incorporation :4.0.0-0.21 ha-cluster/group-package/ha-cluster-incorporation :4.0.0-0.21 ha-cluster/group-package/ha-cluster-minimal :4.0.0-0.21 ha-cluster/group-package/ha-cluster-quorum-server-full :4.0.0-0.21 ha-cluster/group-package/ha-cluster-quorum-server-l10n :4.0.0-0.21 ha-cluster/ha-service/derby :4.0.0-0.21 ha-cluster/ha-service/gds :4.0.0-0.21 ha-cluster/ha-service/logical-hostname :4.0.0-0.21 ha-cluster/ha-service/smf-proxy :4.0.0-0.21 ha-cluster/ha-service/telemetry :4.0.0-0.21 ha-cluster/library/cacao :4.0.0-0.21 ha-cluster/library/ucmm :4.0.0-0.21 ha-cluster/locale :4.0.0-0.21 ha-cluster/release/name :4.0.0-0.21 ha-cluster/service/management :4.0.0-0.21 ha-cluster/service/management/slm :4.0.0-0.21 ha-cluster/service/quorum-server :4.0.0-0.21 ha-cluster/service/quorum-server/locale :4.0.0-0.21 ha-cluster/service/quorum-server/manual/locale :4.0.0-0.21 ha-cluster/storage/svm-mediator :4.0.0-0.21 ha-cluster/system/cfgchk :4.0.0-0.21 ha-cluster/system/core :4.0.0-0.21 ha-cluster/system/dsconfig-wizard :4.0.0-0.21 ha-cluster/system/install :4.0.0-0.21 ha-cluster/system/manual :4.0.0-0.21 ha-cluster/system/manual/data-services :4.0.0-0.21 ha-cluster/system/manual/locale :4.0.0-0.21
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 de 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 des droits d'autorisation RBAC solaris.cluster.read pour utiliser cette sous-commande.
phys-schost# cluster show -t resource,resourcetype,resourcegroup
Effectuez toutes les étapes de cette procédure à partir d'un noeud du cluster global. 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-2 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.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: <NULL>
RT_system: True
Global_zone: True
=== Resource Groups and Resources ===
Resource Group: tel-rg
RG_description: <NULL>
RG_mode: Failover
RG_state: Managed
Failback: False
Nodelist: phys-schost-2 phys-schost-1
--- Resources for Group tel-rg ---
Resource: tel-res
Type: SUNW.sctelemetry
Type_version: 4.0
Group: tel-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
La commande cluster status affiche 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 de 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 des droits d'autorisation RBAC solaris.cluster.read pour utiliser la sous-commande status.
phys-schost# cluster status
Effectuez toutes les étapes de cette procédure à partir d'un noeud du cluster global.
Exemple 1-3 Vérification du statut des composants d'un cluster
L'exemple suivant présente un extrait des informations concernant les composants du cluster renvoyées par la commande cluster 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:nge1 phys-schost-4:nge1 Path online
phys-schost-1:e1000g1 phys-schost-4:e1000g1 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
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 de 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 IPMP (IP Network Multipathing), utilisez la commande clnode 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
Effectuez toutes les étapes de cette procédure à partir d'un noeud du cluster global.
Exemple 1-4 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 nge2 Online phys-schost-2 test-rg Online nge3 Online
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 de 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 des droits d'autorisation RBAC solaris.cluster.read pour utiliser la sous-commande status.
% cluster show
Effectuez toutes les étapes de cette procédure à partir d'un noeud du cluster global.
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-5 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: 0x4DA2C888
installmode: disabled
heartbeat_timeout: 10000
heartbeat_quantum: 1000
private_netaddr: 172.11.0.0
private_netmask: 255.255.248.0
max_nodes: 64
max_privatenets: 10
num_zoneclusters: 12
udp_session_timeout: 480
concentrate_load: False
global_fencing: prefer3
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
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: net1, net3
--- Transport Adapters for phys-schost-1 ---
Transport Adapter: net1
Adapter State: Enabled
Adapter Transport Type: dlpi
Adapter Property(device_name): net
Adapter Property(device_instance): 1
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: net3
Adapter State: Enabled
Adapter Transport Type: dlpi
Adapter Property(device_name): net
Adapter Property(device_instance): 3
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: e1000g1, nge1
--- Transport Adapters for phys-schost-2 ---
Transport Adapter: e1000g1
Adapter State: Enabled
Adapter Transport Type: dlpi
Adapter Property(device_name): e1000g
Adapter Property(device_instance): 2
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: nge1
Adapter State: Enabled
Adapter Transport Type: dlpi
Adapter Property(device_name): nge
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:e1000g1,switch2@1
Cable Endpoint1: phys-schost-1:e1000g1
Cable Endpoint2: switch2@1
Cable State: Enabled
Transport Cable: phys-schost-1:nge1,switch1@1
Cable Endpoint1: phys-schost-1:nge1
Cable Endpoint2: switch1@1
Cable State: Enabled
Transport Cable: phys-schost-2:nge1,switch1@2
Cable Endpoint1: phys-schost-2:nge1
Cable Endpoint2: switch1@2
Cable State: Enabled
Transport Cable: phys-schost-2:e1000g1,switch2@2
Cable Endpoint1: phys-schost-2:e1000g1
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: shared_disk
Access Mode: scsi3
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: 4
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: <NULL>
RT_system: True
Global_zone: 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: <NULL>
RT_system: True
Global_zone: 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: <NULL>
RT_system: True
Global_zone: True
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: <NULL>
RT_system: True
Global_zone: True
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: <NULL>
RT_system: True
Global_zone: True
=== 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_uss
nodeIPs{phys-schost-2}: 10.134.112.112
nodeIPs{phys-schost-1 10.134.112.113
User ID: rootExemple 1-6 Affichage de la configuration du cluster de zones
L'exemple suivant répertorie les propriétés de la configuration du cluster de zones avec RAC.
% 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: /local/ufs-1
special: /dev/md/ds1/dsk/d0
raw: /dev/md/ds1/rdsk/d0
type: ufs
options: [logging]
--- 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. Pour plus d'informations, reportez-vous à la page de manuel clnasdevice(1CL).
La commande cluster utilise la sous-commande check pour valider la configuration nécessaire pour permettre le fonctionnement correct d'un cluster global. 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 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.
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
Effectuez toutes les étapes de cette procédure à partir d'un noeud du cluster global.
La recherche détecte les mises à jour d'Oracle Solaris Cluster contenant des vérifications.
# 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 check-ID
Spécifie une vérification spécifique.
# cluster check -v -k functional -C check-ID -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-7 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-8 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-9 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-10 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 4.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 comprend des vérifications examinant le fichier /etc/vfstab et visant à repérer les erreurs de configuration concernant le système de fichiers de cluster et ses points de montage globaux. Pour de plus amples informations, reportez-vous à la page de manuel cluster(1CL).
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-11 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 4.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 4.x node. ANALYSIS : This server may not been qualified to be used as an Oracle Solaris Cluster 4.x node. Only servers that have been qualified with Oracle Solaris Cluster 4.0 are supported as Oracle Solaris Cluster 4.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 4.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-12 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
|