Ignorer les liens de navigation | |
Quitter l'aperu | |
Guide d'administration système d'Oracle Solaris Cluster Oracle Solaris Cluster 4.1 (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 vous permet de créer de manière interactive un cluster de zones et de configurer un quorum, des groupes de ressources, des transports de cluster, des noms d'hôtes privés, des groupes de périphériques et de nouvelles options de noeud 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 q 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.
Suivez les instructions qui s'affichent à l'écran pour effectuer une tâche. Pour plus d'informations, reportez-vous aux instructions de la section Création et configuration d’un cluster de zones du manuel Guide d’installation du logiciel Oracle Solaris Cluster.
Voir aussi
Pour plus d'informations, reportez-vous aux pages de manuel clsetup or clzonecluster.
Il n'est pas nécessaire d'être connecté en tant que rôle root 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.1.
phys-schost# clnode show-rev 4.1 phys-schost#% clnode show-rev -v Oracle Solaris Cluster 4.1 for Solaris 11 sparc ha-cluster/data-service/apache :4.1-0.18 ha-cluster/data-service/dhcp :4.1-0.18 ha-cluster/data-service/dns :4.1-0.18 ha-cluster/data-service/glassfish-message-queue :4.1-0.18 ha-cluster/data-service/ha-ldom :4.1-0.18 ha-cluster/data-service/ha-zones :4.1-0.18 ha-cluster/data-service/iplanet-web-server :4.1-0.18 ha-cluster/data-service/nfs :4.1-0.18 ha-cluster/data-service/oracle-database :4.1-0.18 ha-cluster/data-service/oracle-external-proxy :4.1-0.18 ha-cluster/data-service/oracle-http-server :4.1-0.18 ha-cluster/data-service/oracle-pmn-server :4.1-0.18 ha-cluster/data-service/oracle-traffic-director :4.1-0.18 ha-cluster/data-service/peoplesoft :4.1-0.18 ha-cluster/data-service/sapnetweaver :4.1-0.18 ha-cluster/data-service/tomcat :4.1-0.18 ha-cluster/data-service/weblogic :4.1-0.18 ha-cluster/developer/agent-builder :4.1-0.18 ha-cluster/developer/api :4.1-0.18 ha-cluster/geo/geo-framework :4.1-0.18 ha-cluster/geo/manual :4.1-0.18 ha-cluster/geo/replication/availability-suite :4.1-0.18 ha-cluster/geo/replication/data-guard :4.1-0.18 ha-cluster/geo/replication/sbp :4.1-0.18 ha-cluster/geo/replication/srdf :4.1-0.18 ha-cluster/geo/replication/zfs-sa :4.1-0.18 ha-cluster/group-package/ha-cluster-data-services-full :4.1-0.18 ha-cluster/group-package/ha-cluster-framework-full :4.1-0.18 ha-cluster/group-package/ha-cluster-framework-l10n :4.1-0.18 ha-cluster/group-package/ha-cluster-framework-minimal :4.1-0.18 ha-cluster/group-package/ha-cluster-framework-scm :4.1-0.18 ha-cluster/group-package/ha-cluster-framework-slm :4.1-0.18 ha-cluster/group-package/ha-cluster-full :4.1-0.18 ha-cluster/group-package/ha-cluster-geo-full :4.1-0.18 ha-cluster/group-package/ha-cluster-geo-incorporation :4.1-0.18 ha-cluster/group-package/ha-cluster-incorporation :4.1-0.18 ha-cluster/group-package/ha-cluster-minimal :4.1-0.18 ha-cluster/group-package/ha-cluster-quorum-server-full :4.1-0.18 ha-cluster/group-package/ha-cluster-quorum-server-l10n :4.1-0.18 ha-cluster/ha-service/derby :4.1-0.18 ha-cluster/ha-service/gds :4.1-0.18 ha-cluster/ha-service/logical-hostname :4.1-0.18 ha-cluster/ha-service/smf-proxy :4.1-0.18 ha-cluster/ha-service/telemetry :4.1-0.18 ha-cluster/library/cacao :4.1-0.18 ha-cluster/library/ucmm :4.1-0.18 ha-cluster/locale :4.1-0.18 ha-cluster/release/name :4.1-0.18 ha-cluster/service/management :4.1-0.18 ha-cluster/service/management/slm :4.1-0.18 ha-cluster/service/quorum-server :4.1-0.18 ha-cluster/service/quorum-server/locale :4.1-0.18 ha-cluster/service/quorum-server/manual/locale :4.1-0.18 ha-cluster/storage/svm-mediator :4.1-0.18 ha-cluster/system/cfgchk :4.1-0.18 ha-cluster/system/core :4.1-0.18 ha-cluster/system/dsconfig-wizard :4.1-0.18 ha-cluster/system/install :4.1-0.18 ha-cluster/system/manual :4.1-0.18 ha-cluster/system/manual/data-services :4.1-0.18 ha-cluster/system/manual/locale :4.1-0.18
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 différents du rôle root doivent disposer de l'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 différents du rôle root doivent disposer de l'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 différents du rôle root doivent disposer de l'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 différents du rôle root doivent disposer de l'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 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: root
Exemple 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 zones 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 de base 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 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.
phys-schost# 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.
phys-schost# 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.
phys-schost# 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.
phys-schost# cluster list-checks -v -C check-ID
Spécifie une vérification spécifique.
phys-schost# 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 directions
Exemple 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