Chapter 1 Introduction to Administering Sun Cluster
This chapter provides the following information about administering a global cluster and a zone cluster, and includes procedures for using Sun™ Cluster administration tools:
For the Solaris™ 10 OS, a global cluster is composed only of one or more global-cluster voting nodes and optionally, zero or more global-cluster non-voting nodes. A global cluster can optionally also include Solaris 8 OS, Solaris 9 OS, LINUX OS, or native brand, non-global zones that are not nodes, but high-availability containers (as resources). A zone cluster requires a global cluster. For general information about zone clusters, see the Sun Cluster Concepts Guide for Solaris OS.
For the Solaris 10 OS, a zone cluster is composed only of one or more cluster brand, voting nodes. A zone cluster depends on, and therefore requires, a global cluster. A global cluster does not contain a zone cluster. You cannot configure a zone cluster without a global cluster. A zone cluster has, at most, one zone cluster node on a machine. A zone-cluster node continues to operate only as long as the global-cluster voting node on the same machine continues to operate. If a global-cluster voting node on a machine fails, all zone-cluster nodes on that machine fail as well.
Overview of Administering Sun Cluster
The Sun Cluster highly available environment ensures that critical applications are available to end users. The system administrator's job is to make sure that the Sun Cluster configuration is stable and operational.
Familiarize yourself with the planning information in the Sun Cluster Software Installation Guide for Solaris OS and the Sun Cluster Concepts Guide for Solaris OS before beginning administration tasks. For instructions on creating a zone cluster, see Configuring a Zone Cluster in Sun Cluster Software Installation Guide for Solaris OS. Sun Cluster administration is organized into tasks among the following manuals.
-
Standard tasks, used to administer and maintain the global cluster or the zone cluster on a regular or even daily basis. These tasks are described in this guide.
-
Data service tasks, such as installation, configuration, and changing properties. These tasks are described in the Sun Cluster Data Services Planning and Administration Guide for Solaris OS.
-
Service tasks, such as adding or repairing storage or network hardware. These tasks are described in the Sun Cluster 3.1 - 3.2 Hardware Administration Manual for Solaris OS.
In general, you can perform Sun Cluster administration tasks while the cluster is operational. If you need take a node out of the cluster or even shut down the node, you can do so while the rest of the nodes continue cluster operations. For Solaris 10, unless otherwise indicated, Sun Cluster administrative tasks should be performed in the global-cluster voting node. For those procedures that require the entire cluster to be shut down, minimize impact on the system by scheduling downtime outside normal working hours. If you plan to shut down the cluster or a cluster node, notify users in advance.
Working With a Zone Cluster
Two Sun Cluster administrative commands (cluster and clnode) can also run in a zone cluster. However, the scope of these commands is limited to the zone cluster where the command is issued. For example, using the cluster command in the global-cluster voting node retrieves all information about the voting global cluster and all the zone clusters. Using the cluster command in a zone cluster retrieves information about that specific zone cluster.
When you use the clzonecluster command in a voting node, the command affects all of the zone clusters in the global cluster. Zone cluster commands also affect all nodes on the zone cluster, even if the node is down when the command is issued.
Zone clusters support delegated administration of resources that are under Resource Group Manager (RGM) control. Therefore, zone cluster administrators can view, but not change, zone cluster dependencies that cross zone cluster boundaries. Only the administrator in a voting node can create, modify, or delete dependencies that cross zone cluster boundaries.
The following list contains the major administrative tasks performed on a zone cluster.
-
Creating a zone cluster – Use the clzonecluster configure command to create a new zone cluster. See the instructions in Configuring a Zone Cluster in Sun Cluster Software Installation Guide for Solaris OS.
-
Starting and rebooting a zone cluster – See Chapter 3, Shutting Down and Booting a Cluster.
-
Adding a node to a zone cluster – See Adding a Node.
-
Removing a node from a zone cluster – See How to Remove a Node From a Zone Cluster.
-
Viewing the configuration of a zone cluster – See How to View the Cluster Configuration.
-
Validating the configuration of a zone cluster – See How to Validate a Basic Cluster Configuration.
-
Stopping a zone cluster – See Chapter 3, Shutting Down and Booting a Cluster.
Solaris Operating System (Solaris OS) Feature Restrictions
Do not enable or disable the following Sun Cluster services by using the Solaris 10 Service Management Facility (SMF) management interface.
Table 1–1 Sun Cluster Services|
Sun Cluster Services |
FMRI |
|---|---|
|
pnm |
svc:/system/cluster/pnm:default |
|
cl_event |
svc:/system/cluster/cl_event:default |
|
cl_eventlog |
svc:/system/cluster/cl_eventlog:default |
|
rpc_pmf |
svc:/system/cluster/rpc_pmf:default |
|
rpc_fed |
svc:/system/cluster/rpc_fed:default |
|
rgm |
svc:/system/cluster/rgm:default |
|
scdpm |
svc:/system/cluster/scdpm:default |
|
cl_ccra |
svc:/system/cluster/cl_ccra:default |
|
scsymon_srv |
svc:/system/cluster/scsymon_srv:default |
|
spm |
svc:/system/cluster/spm:default |
|
cl_svc_cluster_milestone |
svc:/system/cluster/cl_svc_cluster_milestone:default |
|
cl_svc_enable |
svc:/system/cluster/cl_svc_enable:default |
|
network-multipathing |
svc:/system/cluster/network-multipathing |
Administration Tools
You can perform administrative tasks on a Sun Cluster configuration by using a graphical user interface (GUI) or by using the command line. The following section provides an overview of the GUI and command-line tools.
Graphical User Interface
Sun Cluster software supports GUI tools that you can use to perform various administrative tasks on your cluster. These GUI tools are Sun Cluster Manager and, if you are using Sun Cluster software on a SPARC based system, Sun Management Center. See Chapter 12, Administering Sun Cluster With the Graphical User Interfaces for more information and for procedures about configuring Sun Cluster Manager and Sun Management Center. For specific information about how to use Sun Cluster Manager, see the online help for the GUI.
Command-Line Interface
You can perform most Sun Cluster administration tasks interactively through the clsetup(1CL) utility. Whenever possible, administration procedures in this guide use the clsetup utility.
You can administer the following Main Menu items through the clsetup utility.
-
Quorum
-
Resource groups
-
Data Services
-
Cluster interconnect
-
Device groups and volumes
-
Private hostnames
-
New nodes
-
Other cluster tasks
Other commands that you use to administer a Sun Cluster configuration are provided in the following list. See the man pages for more detailed information.
- ccp(1M)
-
Starts remote console access to the cluster.
- if_mpadm(1M)
-
Switches IP addresses from one adapter to another in an IP Network Multipathing group.
- claccess(1CL)
-
Manages Sun Cluster access policies for adding nodes.
- cldevice(1CL)
-
Manages Sun Cluster devices.
- cldevicegroup(1CL)
-
Manages Sun Cluster device groups.
- clinterconnect(1CL)
-
Manages the Sun Cluster interconnect.
- clnasdevice(1CL)
-
Manages access to NAS devices for a Sun Cluster configuration.
- clnode(1CL)
-
Manages Sun Cluster nodes.
- clquorum(1CL)
-
Manages Sun Cluster quorum.
- clreslogicalhostname(1CL)
-
Manages Sun Cluster resources for logical host names.
- clresource(1CL)
-
Manages resources for Sun Cluster data services.
- clresourcegroup(1CL)
-
Manages resources for Sun Cluster data services.
- clresourcetype(1CL)
-
Manages resources for Sun Cluster data services.
- clressharedaddress(1CL)
-
Manages Sun Cluster resources for shared addresses.
- clsetup(1CL)
-
Configures a Sun Cluster configuration interactively.
- clsnmphost(1CL)
-
Administers Sun Cluster SNMP hosts.
- clsnmpmib(1CL)
-
Administers Sun Cluster SNMP MIB.
- clsnmpuser(1CL)
-
Administers Sun Cluster SNMP users.
- cltelemetryattribute(1CL)
-
Configures system resource monitoring.
- cluster(1CL)
-
Manages the global configuration and the global status of the Sun Cluster configuration.
- clvxvm(1CL)
-
Initializes Veritas Volume Manager (VxVM) on a Sun Cluster node and optionally performs root-disk encapsulation.
- clzonecluster(1CL)
-
Creates and modifies a zone cluster.
In addition, you can use commands to administer the volume manager portion of a Sun Cluster configuration. These commands depend on the specific volume manager that your cluster uses, either Solstice DiskSuiteTM software, Veritas Volume Manager, or Solaris Volume Manager.
Preparing to Administer the Cluster
This section describes how to prepare to administer your cluster.
Documenting a Sun Cluster Hardware Configuration
Document the hardware aspects that are unique to your site as your Sun Cluster configuration is scaled. To reduce administration, refer to your hardware documentation when you change or upgrade the cluster. Labeling cables and connections between the various cluster components can also make administration easier.
Reduce the time required by a third-party service provider when servicing your cluster by keeping records of your original cluster configuration, and subsequent changes.
Using an Administrative Console
You can use either a dedicated workstation or a workstation connected through a management network as the administrative console, to administer the active cluster. Typically, you install and run the Cluster Control Panel (CCP) and graphical user interface (GUI) tools on the administrative console. For more information about the CCP, see How to Log Into the Cluster Remotely. For instructions on installing the Cluster Control Panel module for Sun Management Center and Sun Cluster Manager GUI tools, see the Sun Cluster Software Installation Guide for Solaris OS.
The administrative console is not a cluster node. The administrative console is used for remote access to the cluster nodes, either over the public network or through a network-based terminal concentrator.
If your SPARC cluster consists of a Sun EnterpriseTM 10000 server, you must log in from the administrative console to the System Service Processor (SSP). Connect by using the netcon command. The default method for netcon to connect with a Sun Enterprise 10000 domain is through the network interface. If the network is inaccessible, you can use netcon in “exclusive” mode by setting the -f option. You can also type ~* during a normal netcon session. Either of the previous solutions gives you the option of toggling to the serial interface if the network becomes unreachable.
Sun Cluster does not require a dedicated administrative console, but using a console provides the following benefits:
-
Enables centralized cluster management by grouping console and management tools on the same machine
-
Provides potentially quicker problem resolution by Enterprise Services or your service provider
Backing Up the Cluster
Back up your cluster on a regular basis. Even though Sun Cluster software provides a highly available environment, with mirrored copies of data on the storage devices, Sun Cluster software is not a replacement for regular backups. A Sun Cluster configuration can survive multiple failures, but does not protect against user or program error, or catastrophic failure. Therefore, you must have a backup procedure in place to protect against data loss.
The following information should be included as part of your backup.
-
All file system partitions
-
All database data if you are running DBMS data services
-
Disk partition information for all cluster disks
-
The md.tab file if you are using Solstice DiskSuite Solaris Volume Manager as your volume manager
Beginning to Administer the Cluster
Table 1–2 provides a starting point for administering your cluster.
Note –
The Sun Cluster commands that you run only from the global-cluster voting node are not valid for use with zone clusters. See the appropriate Sun Cluster man page for information about the valid use of a command in zones.
Table 1–2 Sun Cluster 3.2 Administration Tools
|
Task |
Tool |
Instructions |
|---|---|---|
|
Log in to the cluster remotely |
Use the ccp command to launch the Cluster Control Panel (CCP). Then select one of the following icons: cconsole, crlogin, cssh, or ctelnet. | |
|
Configure the cluster interactively |
Start the clzonecluster(1CL) utility or the clsetup(1CL) utility. | |
|
Display Sun Cluster release number and version information |
Use the clnode(1CL) command with the show-rev --v -node subcommand and option. | |
|
Display installed resources, resource groups, and resource types |
Use the following commands to display the resource information: |
How to Display Configured Resource Types, Resource Groups, and Resources |
|
Monitor cluster components graphically |
Use Sun Cluster Manager. |
See online help |
|
Administer some cluster components graphically |
Use Sun Cluster Manager or the Sun Cluster module for Sun Management Center, which is available only with Sun Cluster on SPARC based systems. |
For Sun Cluster Manager, see online help. For Sun Management Center, see Sun Management Center documentation. |
|
Check the status of cluster components |
Use the cluster(1CL) command with the status subcommand. | |
|
Check the status of IP network multipathing groups on the public network |
For a global cluster, use the clnode(1CL) status command with the -m option. For a zone cluster, use the clzonecluster(1CL) show command. | |
|
View the cluster configuration |
For a global cluster, use the cluster(1CL) command with the show subcommand. For a zone cluster, use the clzonecluster(1CL) command with the show subcommand. | |
|
Check global mount points or verify the cluster configuration |
For a global cluster, use the sccheck(1M) command. For a zone cluster, use the clzonecluster(1CL) verify command. | |
|
Look at the contents of Sun Cluster command logs |
Examine the /var/cluster/logs/ commandlog file. | |
|
Look at Sun Cluster system messages |
Examine the /var/adm/messages file. |
Viewing System Messages in System Administration Guide: Advanced Administration |
|
Monitor the status of Solstice DiskSuite |
Use the metastat commands. |
Solaris Volume Manager documentation |
|
Monitor the status of Solaris Volume Manager if running Solaris 9 or Solaris 10 |
Use the metastat command. |
How to Log Into the Cluster Remotely
The Cluster Control Panel (CCP) provides a launchpad for the cconsole, crlogin, cssh, and ctelnet tools. All tools start a multiple-window connection to a set of specified nodes. The multiple-window connection consists of a host window for each of the specified nodes and a common window. Input to the common window is sent to each of the host windows, enabling you to run commands simultaneously on all nodes of the cluster.
You can also start cconsole, crlogin, cssh, or ctelnet sessions from the command line.
By default, the cconsole utility uses a telnet connection to the node consoles. To establish secure shell connections to the consoles instead, enable the Use SSH checkbox in the Options menu of the cconsole window. Or, specify the -s option when you issue the ccp or cconsole command.
See the ccp(1M) and cconsole(1M) man pages for more information.
The phys-schost# prompt reflects a global-cluster prompt. Perform this procedure on a global cluster.
This procedure provides the long forms of the Sun Cluster commands. Most commands also have short forms. Except for the long and short forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix B, Sun Cluster Object-Oriented Commands.
Before You Begin
Verify that the following prerequisites are met before starting the CCP:
-
Install the SUNWccon package on the administrative console.
-
Ensure that the PATH variable on the administrative console includes the Sun Cluster tools directories, /opt/SUNWcluster/bin and /usr/cluster/bin. You can specify an alternate location for the tools directory by setting the $CLUSTER_HOME environment variable.
-
Configure the clusters file, the serialports file, and the nsswitch.conf file if you are using a terminal concentrator. The files can be either /etc files or NIS or NIS+ databases. See the clusters(4) and serialports(4) man pages for more information.
-
If you have a Sun Enterprise 10000 server platform, log in to the System Service Processor (SSP).
-
From the administrative console, start the CCP launchpad.
phys-schost# ccp clustername
The CCP launchpad is displayed.
-
To start a remote session with the cluster, click the cconsole icon, crlogin icon, cssh icon, or ctelnet icon in the CCP launch pad.
How to Connect Securely to Cluster Consoles
Perform this procedure to establish secure shell connections to the consoles of the cluster nodes.
Before You Begin
Configure the clusters file, the serialports file, and the nsswitch.conf file if you are using a terminal concentrator. The files can be either /etc files or NIS or NIS+ databases.
Note –
In the serialports file, assign the port number to use for secure connection to each console-access device. The default port number for secure shell connection is 22.
See the clusters(4) and serialports(4) man pages for more information.
-
Become superuser on the administrative console.
-
Start the cconsole utility in secure mode.
# cconsole -s [-l username] [-p ssh-port]
- -s
-
Enables secure shell connection.
- -l username
-
Specifies the user name for the remote connections. If the -l option is not specified, the user name that launched the cconsole utility is used.
- -p ssh-port
-
Specifies the secure shell port number to use. If the -p option is not specified, the default port number 22 is used for the secure connections.
How to Access the Cluster Configuration Utilities
The clsetup utility enables you to interactively configure quorum, resource group, cluster transport, private hostname, device group, and new node options for the global cluster. The clzonecluster utility performs similar configuration tasks for a zone cluster. For more information, see the clsetup(1CL) and clzonecluster(1CL) man pages.
The phys-schost# prompt reflects a global-cluster prompt. Perform this procedure on a global cluster.
This procedure provides the long forms of the Sun Cluster commands. Most commands also have short forms. Except for the long and short forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix B, Sun Cluster Object-Oriented Commands.
-
Become superuser on an active member node of a global cluster. Perform all steps of this procedure from a node of the global cluster.
-
Start the configuration utility.
phys-schost# clsetup
-
For a global cluster, start the utility with the clsetup command.
phys-schost# clsetup
The Main Menu is displayed.
-
For a zone cluster, start the utility with the clzonecluster command. The zone cluster in this example is sczone.
phys-schost# clzonecluster configure sczone
You can view the available actions in the utility with the following option:
clzc:sczone> ?
-
-
Choose your configuration from the menu. Follow the onscreen instructions to complete a task. For more detail, see the instructions in Configuring a Zone Cluster in Sun Cluster Software Installation Guide for Solaris OS.
See Also
See the clsetup or clzonecluster online help for more information.
How to Display Sun Cluster Patch Information
You do not need to be logged in as superuser to perform this procedure.
The phys-schost# prompt reflects a global-cluster prompt. Perform this procedure on a global cluster.
This procedure provides the long forms of the Sun Cluster commands. Most commands also have short forms. Except for the long and short forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix B, Sun Cluster Object-Oriented Commands.
-
Display the Sun Cluster patch information:
phys-schost# showrev -p
Sun Cluster update releases are identified by the main product patch number plus the update version.
Example 1–1 Displaying Sun Cluster Patch Information
The following example displays information about patch 110648-05.
phys-schost# showrev -p | grep 110648 Patch: 110648-05 Obsoletes: Requires: Incompatibles: Packages: |
How to Display Sun Cluster Release and Version Information
You do not need to be logged in as superuser to perform this procedure. Perform all steps of this procedure from a node of the global cluster.
The phys-schost# prompt reflects a global-cluster prompt. Perform this procedure on a global cluster.
This procedure provides the long forms of the Sun Cluster commands. Most commands also have short forms. Except for the long and short forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix B, Sun Cluster Object-Oriented Commands.
-
Display Sun Cluster release and version information:
phys-schost# clnode show-rev -v -node
This command displays Sun Cluster release number and version strings for all Sun Cluster packages.
Example 1–2 Displaying Sun Cluster Release and Version Information
The following example displays the cluster's release information and version information for all packages.
phys-schost# clnode show-rev 3.2 phys-schost#% clnode show-rev -v Sun Cluster 3.2 for Solaris 9 sparc SUNWscr: 3.2.0,REV=2006.02.17.18.11 SUNWscu: 3.2.0,REV=2006.02.17.18.11 SUNWsczu: 3.2.0,REV=2006.02.17.18.11 SUNWscsck: 3.2.0,REV=2006.02.17.18.11 SUNWscnm: 3.2.0,REV=2006.02.17.18.11 SUNWscdev: 3.2.0,REV=2006.02.17.18.11 SUNWscgds: 3.2.0,REV=2006.02.17.18.11 SUNWscman: 3.2.0,REV=2005.10.18.08.42 SUNWscsal: 3.2.0,REV=2006.02.17.18.11 SUNWscsam: 3.2.0,REV=2006.02.17.18.11 SUNWscvm: 3.2.0,REV=2006.02.17.18.11 SUNWmdm: 3.2.0,REV=2006.02.17.18.11 SUNWscmasa: 3.2.0,REV=2006.02.17.18.11 SUNWscmautil: 3.2.0,REV=2006.02.17.18.11 SUNWscmautilr: 3.2.0,REV=2006.02.17.18.11 SUNWjfreechart: 3.2.0,REV=2006.02.17.18.11 SUNWscva: 3.2.0,REV=2006.02.17.18.11 SUNWscspm: 3.2.0,REV=2006.02.17.18.11 SUNWscspmu: 3.2.0,REV=2006.02.17.18.11 SUNWscspmr: 3.2.0,REV=2006.02.17.18.11 SUNWscderby: 3.2.0,REV=2006.02.17.18.11 SUNWsctelemetry: 3.2.0,REV=2006.02.17.18.11 SUNWscrsm: 3.2.0,REV=2006.02.17.18.11 SUNWcsc: 3.2.0,REV=2006.02.21.10.16 SUNWcscspm: 3.2.0,REV=2006.02.21.10.16 SUNWcscspmu: 3.2.0,REV=2006.02.21.10.16 SUNWdsc: 3.2.0,REV=2006.02.21.10.09 SUNWdscspm: 3.2.0,REV=2006.02.21.10.09 SUNWdscspmu: 3.2.0,REV=2006.02.21.10.09 SUNWesc: 3.2.0,REV=2006.02.21.10.11 SUNWescspm: 3.2.0,REV=2006.02.21.10.11 SUNWescspmu: 3.2.0,REV=2006.02.21.10.11 SUNWfsc: 3.2.0,REV=2006.02.21.10.06 SUNWfscspm: 3.2.0,REV=2006.02.21.10.06 SUNWfscspmu: 3.2.0,REV=2006.02.21.10.06 SUNWhsc: 3.2.0,REV=2006.02.21.10.20 SUNWhscspm: 3.2.0,REV=2006.02.21.10.20 SUNWhscspmu: 3.2.0,REV=2006.02.21.10.20 SUNWjsc: 3.2.0,REV=2006.02.21.10.22 SUNWjscman: 3.2.0,REV=2006.02.21.10.22 SUNWjscspm: 3.2.0,REV=2006.02.21.10.22 SUNWjscspmu: 3.2.0,REV=2006.02.21.10.22 SUNWksc: 3.2.0,REV=2006.02.21.10.14 SUNWkscspm: 3.2.0,REV=2006.02.21.10.14 SUNWkscspmu: 3.2.0,REV=2006.02.21.10.14 |
How to Display Configured Resource Types, Resource
Groups, and Resources
You can also accomplish this procedure by using the Sun Cluster Manager GUI. Refer to Chapter 12, Administering Sun Cluster With the Graphical User Interfaces or see the Sun Cluster Manager online help for more information.
The phys-schost# prompt reflects a global-cluster prompt. Perform this procedure on a global cluster.
This procedure provides the long forms of the Sun Cluster commands. Most commands also have short forms. Except for the long and short forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix B, Sun Cluster Object-Oriented Commands.
Before You Begin
Users other than superuser require solaris.cluster.read RBAC authorization to use this subcommand.
-
Display the cluster's configured resource types, resource groups, and resources. Perform all steps of this procedure from a node of the global cluster.
phys-schost# cluster show -t resource,resourcetype,resourcegroup
For information about individual resources, resource groups, and resource types, use the show subcommand with one of the following commands:
-
resource
-
resource group
-
resourcetype
-
Example 1–3 Displaying Configured Resource Types, Resource Groups, and Resources
The following example shows the resource types (RT Name), resource groups (RG Name), and resources (RS Name ) configured for the cluster schost.
phys-schost# cluster show -t resource,resourcetype,resourcegroup
=== Registered Resource Types ===
Resource Type: SUNW.qfs
RT_description: SAM-QFS Agent on SunCluster
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
|
How to Check the Status of Cluster Components
You can also accomplish this procedure by using the Sun Cluster Manager GUI. See the Sun Cluster Manager online help for more information.
Note –
The cluster status command also shows the status of a zone cluster.
The phys-schost# prompt reflects a global-cluster prompt. Perform this procedure on a global cluster.
This procedure provides the long forms of the Sun Cluster commands. Most commands also have short forms. Except for the long and short forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix B, Sun Cluster Object-Oriented Commands.
Before You Begin
Users other than superuser require solaris.cluster.read RBAC authorization to use the status subcommand.
-
Check the status of cluster components. Perform all steps of this procedure from a node of the global cluster.
phys-schost# cluster status
Example 1–4 Checking the Status of Cluster Components
The following example provides a sample of status information for cluster components returned by 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
|
How to Check the Status of the Public Network
You can also accomplish this procedure by using the Sun Cluster Manager GUI. See the Sun Cluster Manager online help for more information.
The phys-schost# prompt reflects a global-cluster prompt. Perform this procedure on a global cluster.
This procedure provides the long forms of the Sun Cluster commands. Most commands also have short forms. Except for the long and short forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix B, Sun Cluster Object-Oriented Commands.
To check the status of the IP Network Multipathing groups, use the clnode(1CL) command with the status subcommand.
Before You Begin
Users other than superuser require solaris.cluster.read RBAC authorization to use this subcommand.
-
Check the status of cluster components. Perform all steps of this procedure from a node of the global cluster.
phys-schost# clnode status -m
Example 1–5 Checking the Public Network Status
The following example provides a sample of status information for cluster components returned by the clnode status command.
% 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 |
How to View the Cluster Configuration
You can also perform this procedure by using the Sun Cluster Manager GUI. See the Sun Cluster Manager online help for more information.
The phys-schost# prompt reflects a global-cluster prompt. Perform this procedure on a global cluster.
This procedure provides the long forms of the Sun Cluster commands. Most commands also have short forms. Except for the long and short forms of the command names, the commands are identical. For a list of the commands and their short forms, see Appendix B, Sun Cluster Object-Oriented Commands.
Before You Begin
Users other than superuser require solaris.cluster.read RBAC authorization to use the status subcommand.
-
View the configuration of a global cluster or zone cluster. Perform all steps of this procedure from a node of the global cluster.
% cluster show
Running the cluster show command from a global-cluster voting node shows detailed configuration information about the cluster and information for zone clusters, if you have configured them.
You can also use the clzonecluster show command to view the configuration information for just the zone cluster. Properties for a zone cluster include zone-cluster name, IP type, autoboot, and zone path. The show subcommand runs inside a zone cluster, and applies only to that particular zone cluster. Running the clzonecluster show command from a zone-cluster node retrieves status only about the objects visible to that specific zone cluster.
To display more information about the cluster command, use the verbose options. See the cluster(1CL) man page for details. See the clzonecluster(1CL) man page for more information about clzonecluster.
Example 1–6 Viewing the Global Cluster Configuration
The following example lists configuration information about the global cluster. If you have a zone cluster configured, it also lists that information.
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 Sun 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 Sun 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: llai
|
Example 1–7 Viewing the Zone Cluster Configuration
The following example lists the properties of the zone cluster configuration.
% 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
|
How to Validate a Basic Cluster Configuration
The sccheck(1M) command runs a set of checks to validate the basic configuration that is required for a global cluster to function properly. If no checks fail, sccheck returns to the shell prompt. If a check fails, sccheck produces reports in either the specified or the default output directory. If you run sccheck against more than one node, sccheck produces a report for each node and a report for multinode checks.
The sccheck command runs in two steps: data collection and analysis. Data collection can be time consuming, depending on the system configuration. You can run sccheck in verbose mode with the -v1 flag to print progress messages. Alternately, you can use the -v2 flag to run sccheck in highly verbose mode, which prints more detailed progress messages, especially during data collection.
Note –
Run sccheck after performing an administration procedure that might result in changes to devices, volume management components, or the Sun Cluster configuration.
Running the clzonecluster(1CL) command at the global—cluster voting node runs a set of checks to validate the configuration that is required for a zone cluster to function properly. If all checks pass, clzonecluster verify returns to the shell prompt and you can safely install the zone cluster. If a check fails, clzonecluster verify reports on the global-cluster nodes where the verification failed. If you run clzonecluster verify against more than one node, a report is produced for each node and a report for multinode checks. The verify subcommand is not allowed inside a zone cluster.
-
Become superuser on an active member node of a global cluster. Perform all steps of this procedure from a node of the global cluster.
phys-schost# su
-
Verify the cluster configuration.
Example 1–8 Checking the Global Cluster Configuration With All Checks Passing
The following example shows sccheck being run in verbose mode against nodes phys-schost-1 and phys-schost-2 with all checks passing.
phys-schost# sccheck -v1 -h phys-schost-1,phys-schost-2 sccheck: Requesting explorer data and node report from phys-schost-1. sccheck: Requesting explorer data and node report from phys-schost-2. sccheck: phys-schost-1: Explorer finished. sccheck: phys-schost-1: Starting single-node checks. sccheck: phys-schost-1: Single-node checks finished. sccheck: phys-schost-2: Explorer finished. sccheck: phys-schost-2: Starting single-node checks. sccheck: phys-schost-2: Single-node checks finished. sccheck: Starting multi-node checks. sccheck: Multi-node checks finished # |
Example 1–9 Checking the Global Cluster Configuration With a Failed Check
The following example shows the node phys-schost-2 in the cluster named suncluster minus the mount point /global/phys-schost-1. Reports are created in the output directory /var/cluster/sccheck/myReports/.
phys-schost# sccheck -v1 -h phys-schost-1,phys-schost-2 -o /var/cluster/sccheck/myReports sccheck: Requesting explorer data and node report from phys-schost-1. sccheck: Requesting explorer data and node report from phys-schost-2. sccheck: phys-schost-1: Explorer finished. sccheck: phys-schost-1: Starting single-node checks. sccheck: phys-schost-1: Single-node checks finished. sccheck: phys-schost-2: Explorer finished. sccheck: phys-schost-2: Starting single-node checks. sccheck: phys-schost-2: Single-node checks finished. sccheck: Starting multi-node checks. sccheck: Multi-node checks finished. sccheck: One or more checks failed. sccheck: The greatest severity of all check failures was 3 (HIGH). sccheck: Reports are in /var/cluster/sccheck/myReports. # # cat /var/cluster/sccheck/myReports/sccheck-results.suncluster.txt ... =================================================== = ANALYSIS DETAILS = =================================================== ------------------------------------ CHECK ID : 3065 SEVERITY : HIGH FAILURE : Global filesystem /etc/vfstab entries are not consistent across all Sun 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. ... # |
How to Check the Global Mount Points
The sccheck(1M) command includes checks that examine the /etc/vfstab file for configuration errors with the cluster file system and its global mount points.
Note –
Run sccheck after making cluster configuration changes that have affected devices or volume management components.
-
Become superuser on an active member node of a global cluster. Perform all steps of this procedure from a node of the global cluster.
% su
-
Verify the global cluster configuration.
phys-schost# sccheck
Example 1–10 Checking the Global Mount Points
The following example shows the node phys-schost-2 of the cluster named suncluster minus the mount point /global/schost-1. Reports are being sent to the output directory, /var/cluster/sccheck/myReports/.
phys-schost# sccheck -v1 -h phys-schost-1,phys-schost-2 -o /var/cluster/sccheck/myReports sccheck: Requesting explorer data and node report from phys-schost-1. sccheck: Requesting explorer data and node report from phys-schost-2. sccheck: phys-schost-1: Explorer finished. sccheck: phys-schost-1: Starting single-node checks. sccheck: phys-schost-1: Single-node checks finished. sccheck: phys-schost-2: Explorer finished. sccheck: phys-schost-2: Starting single-node checks. sccheck: phys-schost-2: Single-node checks finished. sccheck: Starting multi-node checks. sccheck: Multi-node checks finished. sccheck: One or more checks failed. sccheck: The greatest severity of all check failures was 3 (HIGH). sccheck: Reports are in /var/cluster/sccheck/myReports. # # cat /var/cluster/sccheck/myReports/sccheck-results.suncluster.txt ... =================================================== = ANALYSIS DETAILS = =================================================== ------------------------------------ CHECK ID : 3065 SEVERITY : HIGH FAILURE : Global filesystem /etc/vfstab entries are not consistent across all Sun 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/sccheck/myReports/sccheck-results.phys-schost-1.txt ... =================================================== = ANALYSIS DETAILS = =================================================== ------------------------------------ CHECK ID : 1398 SEVERITY : HIGH FAILURE : An unsupported server is being used as a Sun Cluster 3.x node. ANALYSIS : This server may not been qualified to be used as a Sun Cluster 3.x node. Only servers that have been qualified with Sun Cluster 3.x are supported as Sun Cluster 3.x nodes. RECOMMEND: Because the list of supported servers is always being updated, check with your Sun Microsystems representative to get the latest information on what servers are currently supported and only use a server that is supported with Sun Cluster 3.x. ... # |
How to View the Contents of Sun Cluster Command Logs
The /var/cluster/logs/commandlog ASCII text file contains records of selected Sun Cluster commands that are executed in a cluster. The logging of commands starts automatically when you set up the cluster and ends when you shut down the cluster. Commands are logged on all nodes that are up and booted in cluster mode.
Commands that are not logged in this file include those commands that display the configuration and current state of the cluster.
Commands that are logged in this file include those commands that configure and change the current state of the cluster:
-
claccess
-
cldevice
-
cldevicegroup
-
clinterconnect
-
clnasdevice
-
clnode
-
clquorum
-
clreslogicalhostname
-
clresource
-
clresourcegroup
-
clresourcetype
-
clressharedaddress
-
clsetup
-
clsnmphost
-
clsnmpmib
-
clnsmpuser
-
cltelemetryattribute
-
cluster
-
clzonecluster
-
scconf
-
scdidadm
-
scdpm
-
scgdevs
-
scrgadm
-
scsetup
-
scshutdown
-
scswitch
Records in the commandlog file can contain the following elements:
-
Date and timestamp
-
Name of the host from which the command was executed
-
Process ID of the command
-
Login name of the user who executed the command
-
Command that the user executed, including all options and operands
Note –Command options are quoted in the commandlog file so that you can readily identify them and copy, paste, and execute them in the shell.
-
Exit status of the executed command
Note –If a command aborts abnormally with unknown results, the Sun Cluster software does not show an exit status in the commandlog file.
By default, the commandlog file is regularly archived once a week. To change the archiving policies for the commandlog file, on each node in the cluster, use the crontab command. See the crontab(1) man page for more information.
Sun Cluster software maintains up to eight previously archived commandlog files on each cluster node at any given time. The commandlog file for the current week is named commandlog. The most recent complete week's file is named commandlog.0. The oldest complete week's file is named commandlog.7.
View the contents of the current week's commandlog file, one screen at a time.
phys-schost# more /var/cluster/logs/commandlog |
Example 1–11 Viewing the Contents of Sun Cluster Command Logs
The following example shows the contents of the commandlog file that are displayed by the more command.
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 |
- © 2010, Oracle Corporation and/or its affiliates