test

Sun Cluster 2.2 System Administration Guide

Chapter 3 Modifying the Sun Cluster Configuration

This chapter provides instructions on the following topics.

This chapter includes the following procedures:

3.1 Adding and Removing Cluster Nodes

When you add or remove cluster nodes, you must reconfigure the Sun Cluster software. When you installed the cluster originally, you specified the number of "active" nodes and the number of "potential" nodes in the cluster, using the scinstall(1M) command. Use the procedures in this section to add "potential" nodes and to remove "active" nodes.

To add nodes that were not already specified as potential nodes, you must halt and reconfigure the entire cluster.

3.1.1 How to Add a Cluster Node

Use this procedure only for nodes that were already specified as "potential" during initial installation.

  1. Use the scinstall(1M) command to install Sun Cluster 2.2 on the node you are adding.

    Use the installation procedures described in the Sun Cluster 2.2 Software Installation Guide, but note the following when responding to scinstall(1M) prompts:

    • When asked for the number of active nodes, include the node you are adding now in the total.

    • You will not be prompted for shared Cluster Configuration Database (CCD) information, since the new cluster will have greater than two nodes.

    • (SSVM with direct attached devices only) When prompted for the node lock port, provide the designated node lock device and port.

    • (SSVM only) Do not select a quorum device when prompted. Instead, select complex mode and then -N. Later, you will run the scconf -q command to configure the quorum device.

    • (SSVM only) Select ask when prompted to choose a cluster partitioning behavior.

  2. (Scalable Coherent Interface [SCI] only) Update the sm_config template file to verify information on the new node.

    This step is not necessary for Ethernet configurations.

    Nodes that were specified as "potential" during initial installation should have been included in the sm_config file with their host names commented out by the characters _%. Uncomment the name of the node you will be activating now. Make sure the configuration information in the file matches the physical layout of the node.

  3. (SCI only) Run sm_config.

  4. (SSVM only) Set up the root disk group.

    For details, see the appendix on configuring SSVM and CVM in the Sun Cluster 2.2 Software Installation Guide.

  5. (SDS only) Set up Solstice DiskSuite disksets.

    For details, see the appendix on configuring Solstice DiskSuite in the Sun Cluster 2.2 Software Installation Guide.

  6. If you have a direct attached device connected to all nodes, set up the direct attached disk flag on the new node.

    To set the direct attached flag correctly in the cdb files of all nodes, run the following command on all nodes in the cluster. In this example, the cluster name is sc-cluster: 

    # scconf sc-cluster +D

  7. (SSVM only) Select a common quorum device.

    If your volume manager is SSVM or CVM and if you have a direct attached device connected to all nodes, run the following command on all nodes and select a common quorum device.

    # scconf sc-cluster -q -D

    If you do not have a direct attached disk connected to all nodes, run the following command for each pair of nodes that shares a quorum device with the new node. 

    # scconf -q

  8. (SSVM only) Set the node lock port on the new node.

    If you just installed a direct attached disk, set the node lock port on all nodes.

    If the cluster contained a direct attached disk already, run the following command on only the new node. In this example, the cluster name is sc-cluster and the Terminal Concentrator is cluster-tc. 

    # scconf sc-cluster -t cluster-tc -l port_number

  9. Stop the cluster.

  10. Run the scconf -A command on all nodes to update the number of active nodes.

    See the scconf(1M) man page for details. In this example, the cluster name is sc-cluster and the new total number of active nodes is three. 

    # scconf sc-cluster -A 3

  11. (SSVM only) Remove the shared CCD if it exists, since it is necessary only with two-node clusters.

    Run the following command on all nodes. 

    # scconf sc-cluster -S none

  12. Use ftp (in binary mode) to copy the cdb file from an existing node to the new node.

    The cdb files normally reside in /etc/opt/SUNWclus/conf/clustername.cdb.

  13. Reboot the new node.

  14. Start the cluster.

    Run the following command from any single node. 

    # scadmin startcluster phys-hahost sc-cluster

    Then run the following command on all other nodes. 

    # scadmin startnode

3.1.2 How to Remove a Cluster Node

The scconf(1M) command enables you to remove nodes by decrementing the number you specified as active nodes when you installed the cluster software with the scinstall(1M) command. For this procedure, you must run the scconf(1M) command on all nodes in the cluster.

  1. For an HA configuration, switch over all logical hosts currently mastered by the node to be removed.

    For parallel database configurations, skip this step.

    # haswitch phys-hahost3 hahost1

  2. Run the scconf -A command to exclude the node.

    Run the scconf(1M) command on all cluster nodes. See the scconf(1M) man page for details. In this example, the cluster name is sc-cluster and the new total number of active nodes is two. 

    # scconf sc-cluster -A 2

3.2 Changing the Name of a Cluster Node

The names of the cluster nodes can be changed using the scconf(1M) command. Refer to the scconf(1M) man page for additional information.

3.2.1 How to Change the Name of a Cluster Node

  1. Find the names of the current cluster nodes.

    You can run the scconf -p command on any node that is an active cluster member.

    # scconf clustername -p 
 Current Configuration for Cluster clustername:
        Hosts in cluster: phys-hahost1 phys_hahost2 phys-hahost3
        Private Network Interfaces for
            phys-hahost1: be0 be1
            phys-hahost2: be0 be1
            phys-hahost3: hme0 hme1

  2. Run the scconf -h command on all nodes in the cluster.

    Run the scconf(1M) command on all nodes. See the scconf(1M) man page for details.

    # scconf -h clustername hostname0 [...hostname3]

    The new node names should be specified in the order shown by the scconf -p command. For example, to change the name of phys-hahost3 to phys-opshost1, you would run the following command on all cluster nodes. 

    # scconf -h sccluster phys-hahost1 phys-hahost2 phys-opshost1

3.3 Changing the Private Network Interfaces

The private network interfaces of the nodes in the cluster can be changed using the scconf(1M) command. Refer to the scconf(1M) man page for additional information.

3.3.1 How to Change the Private Network Interfaces

Use the scconf(1M) command for all nodes in the cluster.

For example:

# scconf planets -i mercury scid0 scid1
# scconf planets -i venus   scid0 scid1
# scconf planets -i pluto   scid0 scid1
# scconf planets -i jupiter scid0 scid1

After running these commands, all four nodes mercury, venus, pluto, and jupiter use interfaces scid0 and scid1.

Caution - Caution -

While the cluster is up, you should not use the ifconfig(1M) command. This action causes unpredictable behavior on a running system.

3.4 Printing the Cluster Configuration

The cluster configuration information can be printed using scconf(1M). Refer to the scconf(1M) man page for more information.

3.4.1 How to Print the Cluster Configuration

Use the scconf(1M) command on any node that is an active cluster member.

For example:

# scconf planets -p

A response similar to the following is displayed. (Depending on your type of private interconnect, your messages may state hme instead of scid.) 

Current Configuration for Cluster planets:
   Hosts in cluster: mercury venus pluto jupiter

   Private Network Interfaces for
       mercury: scid0 scid1
       venus: scid0 scid1
       pluto: scid2 scid3
       jupiter: scid2 scid3

3.5 Adding and Removing Logical Hosts

Logical hosts are the objects that fail over if a node fails. Each logical host is composed of a disk group or groups, a relocatable IP address, and a logical host name. Logical hosts are only used in configurations with HA data services. There are no logical hosts in a parallel database configuration.

You add or remove logical hosts by updating the information on your logical host and reconfiguring the cluster. When you configure the cluster originally, you provide scinstall(1M) with information on your logical host configuration. Once the cluster is up, there are two ways to change this information:

3.5.1 How to Add a Logical Host to the Cluster

As part of the process of adding a logical host, you will be asked to provide the following information:

Gather the answers to these questions before starting the procedure. Note that you must have already set up your disk group to be used by the new logical host. Refer to the appropriate appendix in the Sun Cluster 2.2 Software Installation Guide for your volume manager for details.

Use the following procedure to add a logical host to a cluster.

  1. Run the scinstall(1M) command and select the Change option from the main menu. 

    # scinstall
Assuming a default cluster name of planets
 Note: Cluster planets is currently running.
       Install/Uninstall actions are disabled during
       cluster operation.

         <<Press return to continue>>

         Checking on installed package state
 ........................

 ============ Main Menu =================

 1) Change  - Modify cluster or data service configuration.
 2) Verify  - Verify installed package sets.
 3) List    - List installed package sets.

 4) Quit    - Quit this program.
 5) Help    - The help screen for this menu.

 Please choose one of the menu items: [5]:  1

  2. From the Change menu, choose the Logical Hosts option. 

    =========== Changes Menu ================

 Choices from this menu:

 1) Logical Hosts       - Change the logical hosts configuration.
 2) NAFO                - Re-initialize the NAFO configuration.

 3) Close  - Close this menu to return to the Main Menu.
 4) Quit   - Exit this program.
 5) Help   - Show the Help screen.

 Please choose a displayed option: [5] 1

    This will display the Logical Hosts Configuration menu.

  3. From the Logical Hosts Configuration menu, select the Add option. 

    ====== Logical Hosts Configuration ======

 1) Add     - Add a logical host to the cluster.
 2) Remove  - Remove a logical host from the cluster.
 3) List    - List the logical hosts in the cluster.

 4) Close   - Return to the previous menu.
 5) Quit    - Exit.


 Please choose an option:  1

    You will be asked a series of questions regarding the new logical host. 

    What is the primary public network controller for "phys-hahost1"?
 What is the primary public network controller for "phys-hahost2"?
 Does the cluster serve any secondary public subnets (yes/no) [no]?
 Re-initialize NAFO on "phys-hahost1" with one ctlr per group
 (yes/no)?
 What is the name of the new logical host?  hahost1
What is the name of the default master for "hahost1"? phys-hahost1
Enable automatic failback for "hahost1" (yes/no) [no]?
 Disk group name for logical host "hahost1" [hahost1]?
 Is it okay to add logical host "hahost1" now (yes/no) [yes]?
 /etc/opt/SUNWcluster/conf/ha.cdb
 Checking node status...

  4. Respond to the prompts with the required information.

    Once the scinstall(1M) portion of this procedure is complete, you will be returned to the Logical Hosts Configuration menu.

  5. Create a new HA administrative filesystem and update the /etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost file.

    When you add a new logical host, you must set up a file system on a disk group within the logical host to store administrative information. The steps for setting up the HA administrative file system differ depending on your volume manager. These steps are described in the appendices of the Sun Cluster 2.2 Software Installation Guide.

    Note -

    Do not use host name aliases for the logical hosts. NFSTM clients mounting Sun Cluster file systems using logical host name aliases might experience statd lock recovery problems.

3.5.2 How to Remove a Logical Host From the Cluster

To remove a logical host from the cluster configuration, the cluster must be up and there must be no data services registered for the logical host.

  1. Stop all data service applications running on the logical host to be removed.

    # hareg -n dataservice

  2. Unregister the data service. 

    # hareg -u dataservice

  3. Remove the logical host from the cluster.

    Run the scinstall(1M) command as described in the Sun Cluster 2.2 Software Installation Guide and select the Change option from the main menu. 

    # scinstall
Assuming a default cluster name of planets
 Note: Cluster planets is currently running.
       Install/Uninstall actions are disabled during
       cluster operation.

         <<Press return to continue>>

         Checking on installed package state
 ........................

 ============ Main Menu =================

 1) Change  - Modify cluster or data service configuration.
 2) Verify  - Verify installed package sets.
 3) List    - List installed package sets.

 4) Quit    - Quit this program.
 5) Help    - The help screen for this menu.

 Please choose one of the menu items: [5]:  1

  4. From the Change menu, select the Logical Hosts option. 

    =========== Changes Menu ================

 Choices from this menu:

 1) Logical Hosts       - Change the logical hosts configuration.
 2) NAFO                - Re-initialize the NAFO configuration.

 3) Close  - Close this menu to return to the Main Menu.
 4) Quit   - Exit this program.
 5) Help   - Show the Help screen.

 Please choose a displayed option: [5] 1

    This will display the Logical Hosts Configuration menu.

  5. From the Logical Hosts Configuration menu, select the Remove option. 

    ====== Logical Hosts Configuration ======

 1) Add     - Add a logical host to the cluster.
 2) Remove  - Remove a logical host from the cluster.
 3) List    - List the logical hosts in the cluster.

 4) Close   - Return to the previous menu.
 5) Quit    - Exit.

 Please choose an option:  2

    This displays a list of configured logical hosts.

  6. Enter the name of the logical host to be removed from the list of configured logical hosts. 

    The list of logical hosts is:

         hahost1
         hahost2

 Which one do you want to remove?  hahost1

    The procedure is now complete and you are returned to the Logical Hosts Configuration menu.

  7. As root, delete the /etc/opt/SUNWcluster/conf/hanfs/vfstab.logicalhost file that was created when the logical host was added to the cluster configuration.

3.6 Changing the Logical Host IP Address

You can change a logical host IP address by removing and adding the logical host with the new IP address by using the procedures in "3.5 Adding and Removing Logical Hosts", or by using the procedure in this section.

Refer to the scconf(1M) man page for more information.

3.6.1 How to Change the Logical Host IP Address

The following steps must be done on a single node that is a cluster member.

  1. Remove the existing logical host entry from the configuration files by running the following command on all nodes. 

    # scconf clustername -L logicalhost -r

  2. Create a new logical host entry, which uses the same logical host name but with the new IP address, by running the following command on all cluster nodes. 

    # scconf clustername -L logicalhost -n nodelist -g diskgroup -i interfaces_and_IP

3.7 Forcing a Cluster Reconfiguration

You can force a cluster reconfiguration by using the haswitch(1M) command, or by changing the cluster membership by using the scconf(1M) command.

3.7.1 How to Force a Cluster Reconfiguration

Force a cluster reconfiguration by running the haswitch(1M) command on any node that is a cluster member. For example:

# haswitch -r

See the haswitch(1M) man page for details.

3.8 Configuring Sun Cluster Data Services

This section provides procedures for configuring Sun Cluster data services. These data services are normally configured with the logical hosts as part of the cluster installation. However, you can also configure logical hosts and data services after the installation. For more detailed information on a particular data service, see the individual chapter covering the data service in the Sun Cluster 2.2 Software Installation Guide.

Note -

All commands used in this section can be run from any node that is a cluster member, even a node that cannot master the specified logical hosts or run the specified data services. You can run the commands even if there is only one node in the cluster membership.

Caution - Caution -

The commands used in this section update the CCD even without a quorum. Consequently, updates to the CCD can be lost if nodes are shut down and brought up in the wrong sequence. Therefore, the node that was the last to leave the cluster must be the first node brought back into the cluster by using the scadmin startcluster command. For more information on the CCD, see the Sun Cluster 2.2 Software Installation Guide.

3.8.1 How to Configure a Sun Cluster Data Service

  1. Verify that the following tasks have been completed.

    • The logical hosts that will run the data services are configured. Refer to "3.5 Adding and Removing Logical Hosts", for details on configuring a logical host.

    • The necessary disk groups, logical volumes, and file systems are set up. Refer to the Sun Cluster 2.2 Software Installation Guide for details.

    • The HA administrative file system and vfstab.logicalhost file have been set up. This procedure varies depending on your volume manager. Refer to the appendix describing how to configure your volume manager in the Sun Cluster 2.2 Software Installation Guide.

  2. Register the data service.

    Register the Sun Cluster data service(s) associated with the logical host(s).

    # hareg -s -r dataservice [-h logicalhost]

    This assumes that the data service has already been installed and its methods are available.

    When the -h option is used in the hareg -r command, the data service is configured only on the logical hosts specified by the logicalhost argument. If the -h option is not specified, then the data service is configured on all currently-existing logical hosts. See the hareg(1M) man page for details.

    Note -

    If the data service is to be associated with any logical hosts that are created after the registration of the data service, run scconf -s on all cluster nodes to extend the set of logical hosts associated with the data service.

  3. Start the data service.

    # hareg -y dataservice

3.9 Unconfiguring Sun Cluster Data Services

Use this procedure to unconfigure Sun Cluster data services. For more detailed information on a data service, see the individual chapter covering the data service in the Sun Cluster 2.2 Software Installation Guide.

3.9.1 How to Unconfigure Sun Cluster Data Services

  1. Stop all data service applications to be unconfigured.

    Perform your normal shutdown procedures for the data service application.

  2. If the data service is a database management system (DBMS), stop all fault monitors.

  3. Stop the data service on all logical hosts.

    # hareg -n dataservice

  4. Unregister the data service.

    # hareg -u dataservice
    Note -

    If the hareg -u command fails, it can leave the Cluster Configuration Database (CCD) in an inconsistent state. If this occurs, run scconf clustername -R dataservice on all cluster nodes to forcibly remove the data service from the CCD.

  5. (Optional) Remove the logical hosts from the cluster configuration.

    You can remove a logical host from the cluster configuration only if all data services are disassociated from it.

    Use one of the following methods to remove a logical host.

    • Run this scconf(1M) command on one node that is a cluster member: 

    # scconf clustername -L logicalhost -r

  6. Perform a cluster reconfiguration by using the haswitch(1M)command. 

    # haswitch -r

    At your discretion, you may choose to remove or rename the vfstab.logicalhost and dfstab.logicalhost files associated with the logical host you removed, and reclaim the space occupied by its volumes and file systems. These files are untouched by the scconf(1M) remove operation.

3.10 Modifying the clusters File

The /etc/clusters file contains information on the known clusters in the local naming domain. This file, which maps a cluster name to the list of host names in the cluster, can be created as an NIS or NIS+ map, or locally in the /etc directory.

The /etc/clusters file requires updating only if:

For more information on NIS and NIS+ maps, refer to the NIS/NIS+ System Administration Guide. Refer to the Sun Cluster 2.2 Software Installation Guide for information on creating the /etc/clusters file. NIS/NIS+ files must be changed on the NIS/NIS+ server.

3.10.1 How to Modify the clusters File

Edit the /etc/clusters file to add the cluster name and physical host names of all nodes.

For example, to create a cluster named hacluster that consists of node 0 phys-hahost1, node 1 phys-hahost2, node 2 phys-hahost3, and node 3 phys-hahost4, enter this command:

# Sun Enterprise Cluster nodes
  hacluster phys-hahost1 phys-hahost2 phys-hahost3 phys-hahost4

Make the same modifications in the /etc/clusters file on each cluster node.

3.10.2 How to Create the clusters Table

In an NIS+ environment, you must create a clusters table. The entries in this table are the same as the entries in the /etc/clusters file.

For example, to create a clusters table in a domain named mydomain in an NIS+ environment, use the following command:

# nistbladm -c key-value key=SI value= clusters.mydomain.
Note -

The trailing period (.) at the end of the nistbladm command is required.

3.11 Modifying the serialports File

The serialports file maps a host name to the Terminal Concentrator and Terminal Concentrator serial port to which the console of the host is connected. This file can be created as an NIS or NIS+ map or locally in the /etc directory.

The serialports file requires updating only if:

Refer to the Sun Cluster 2.2 Software Installation Guide for information on creating the /etc/serialports file. For more information on NIS and NIS+ maps, refer to the NIS/NIS+ System Administration Guide.

3.11.1 How to Modify the serialports File

  1. As root, create a serialports file in the /etc directory.

  2. For a Sun EnterpriseTM 10000 system, enter hostname sspname 23 in the serialports file. For all other hardware systems, enter hostname terminal_concentrator serial_port in the serialports file.

    For Sun Enterprise 10000:

    # Sun Enterprise Cluster nodes
   phys-hahost1 sspname 23
   phys-hahost2 sspname 23
   phys-hahost3 sspname 23
   phys-hahost4 sspname 23

    For all other hardware systems:

    # Sun Enterprise Cluster nodes
   phys-hahost1 hacluster-tc    5002
   phys-hahost2 hacluster-tc    5003
   phys-hahost3 hacluster-tc    5004
   phys-hahost4 hacluster-tc    5005

3.11.2 How to Create the serialports Table

In an NIS+ environment, you need to create a serialports table. The entries in this table are the same as the entries in the /etc/serialports file.

To create a serialports table in a domain named mydomain in an NIS+ environment, use the following command:

# nistbladm -c key-value key=SI value=clusters.mydomain.
Note -

The trailing period (.) at the end of the nistbladm command is required.

3.12 Changing TC/SSP Information

When installing Sun Cluster software, information about the Terminal Concentrator (TC) or a System Service Processor (SSP) is required. This information is stored in the cluster configuration database (CCD).

This information is used to:

Both these mechanisms serve to protect data integrity in the case of four-node clusters with directly attached storage devices.

Use the scconf(1M) command to change the TC or SSP information associated with a particular node, as described in the following procedures.

3.12.1 How to Change TC/SSP Information

To change TC or SSP information, run the scconf(1M) command on all cluster nodes. For each node, supply the appropriate new information. The following examples show scconf(1M) command syntax for each type of information change.

Node architecture type and IP address - Supply the cluster name, the host name, the new architecture type, and the new IP address.

# scconf clustername -H hostname -d E10000 -t new_ip_address
Note -

Multiple hosts may be connected to the same TC; the -H option affects only the information associated with the host you specify in the command line.

Password for a TC or SSP - Supply the cluster name, the IP address, and the new password.

# scconf clustername -t ip_address -P
 ip_address (129.34.123.51) Password:

Port number for an SSP console - Supply the cluster name, host name, and new port number. 

# scconf clustername -H hostname -p new_port_number

TC name or IP address - Supply the cluster name, host name, and new TC name or IP address. 

# scconf clustername -H hostname -t new_tc_name|new_ip_address

For additional information on changing TC or SSP information, see the scconf(1M) man page and Chapter 8, Administering the Terminal Concentrator.

3.13 Changing the Quorum Device

A quorum device is used only in SSVM and CVM configurations. It is not used in Solstice DiskSuite configurations.

The scconf -q command can be used to change the quorum device to either a disk or a controller. This option is useful if the quorum device needs servicing. Refer to the scconf(1M) man page for details.

Note -

If the quorum device is a disk, the scconf -q command must be used whenever the disk address (in the form cxtydzs2) changes, even if the serial number of the disk is preserved. This change in disk address can happen if the SBus slot of the drive controller changes.

Caution - Caution -

Do not use the scconf -q option to modify the quorum device topology while the cluster is running. You cannot add or remove a quorum device between any two cluster nodes. Specifically, between a pair of nodes in the cluster:

3.13.1 How to Change the Quorum Device

  1. Before servicing the device, you can change the quorum device to a different device by running the scconf -q command on all cluster nodes.

    For example, to change the quorum device in the cluster haclust for nodes phys-hahost1 and phys-hahost2, run the scconf(1M) command as shown below.

    # scconf haclust -q phys-hahost1 phys-hahost2
Select quorum device for nodes 0 (phys-hahost1) and 1 (phys-hahost2).
 Type the number corresponding to the desired selection.
 For example: 1<CR>

  1) DISK:c2t2d0s2:01943825
  2) DISK:c2t3d0s2:09064321
  3) DISK:c2t4d0s2:02171369
  4) DISK:c2t5d0s2:02149886
  5) DISK:c2t8d0s2:09062992
  6) DISK:c2t9d0s2:02166472
  7) DISK:c3t2d0s2:02183692
  8) DISK:c3t3d0s2:02183488
  9) DISK:c3t4d0s2:02160277
 10) DISK:c3t5d0s2:02166396
 11) DISK:c3t8d0s2:02164352
 12) DISK:c3t9d0s2:02164312
 Quorum device: 12

    The -q option probes the list of devices attached to each node and lists the devices that the two nodes share. The quorum device can then be selected from this list.

    To enable probing of devices attached to remote hosts, the local /.rhosts file is modified to enable rsh(1) permissions. The permissions are removed after the command completes.

    Note -

    This behavior occurs only if this command is run from all the nodes at the same time. If you do not want remote root access capability, use the -m option.

  2. You may choose either an SSA controller or a disk from this list as the quorum device.

    If you choose an SSA controller, the list of disks in that controller is displayed.

  3. If you chose an SSA controller in Step 2, you are given the option to select a disk from this SSA as the quorum device.

    If no disk is chosen in this step, the SSA controller chosen in the previous step is retained as the quorum device.

    The -q option also checks for the case where a node might have a reservation on the quorum device, due to some other node not being part of the membership. In this case, the -q option releases the reservation on the old quorum device and reserves the new quorum device.

    Note -

    All the specified nodes must be booted for the scconf -q command to run successfully. If any of the nodes is not booted, the command probes and presents the list of all devices on the local node. Be sure to select a shared device as the quorum device.

    If you already know the name of the device to use as the quorum device, use the -m option to specify the new device. 

    # scconf clustername -q -m quorum-device hostname1 hostname2

    The quorum device can either be an SSA controller's World Wide Name (WWN), or a disk identifier of the form WWN.disk-serial-id for disks in SSAs, or a disk identifier of the form disk-address:disk-serial-id for non-SSA disks. The disk-address is of the form cxtydzs2. You can use the finddevices(1M) command to obtain the serial numbers of SSA or non-SSA disks.

    If you have a cluster with more than two nodes where all nodes share a common quorum device, you can use the -q -D options to specify a new common quorum device. 

    # scconf clustername -q -D

    Since all the hosts in the cluster share a common device, specifying a list of hosts is unnecessary.

    This is an interactive option that probes the list of devices attached to each host and then presents the list of shared devices. Select the quorum device from this list.

    Note -

    All the active hosts defined in the cluster must be booted for the scconf -q -D command to be successful. If any of the hosts are not booted, the command probes and presents the list of all devices on the local host. Be sure to select a shared device as the quorum device.

    The -q -D option also checks for the case where a node of the cluster may have a reservation on the quorum device, due to some other node not being part of the cluster. In this case, the reservation on the old quorum device is released and the new quorum device is reserved.

    If this command is run from all the nodes at the same time via the cconsole and crlogin GUI interfaces, then the local /.rhosts file is modified to enable rsh(1) permissions. This enables the probing of devices attached to remote hosts. The permissions are removed after the command completes.

    The -m option can be added if remote root access capability is not desired. The -m option configures the quorum device and is given as the last argument to the command for the specified nodes.

    # scconf clustername -q -D -m quorum-device

    The quorum device is a disk identifier of the form cxtydzs2:disk-serial-ID. Use the finddevices(1M) command to obtain the serial numbers of disks.

3.14 Configuring Timeouts for Cluster Transition Steps

Sun Cluster has configurable timeouts for the cluster transition steps where logical hosts of the HA framework are taken over and given up as cluster membership changes. Adapt these timeouts as needed to effectively handle configurations consisting of large numbers of data services on each node. It is impractical to have constant timeout values for a wide variety of configurations, unless the timeouts are set to a very large default value.

There are essentially two considerations when tuning timeouts:

It is difficult to estimate what the correct value should be for a particular installation. These values should be arrived at by trial and error. You can use as guidelines the cluster console messages related to the beginning and end of each cluster transition step. They should give you a fairly good idea of how long a step takes to execute.

The timeouts need to account for the worst case scenario. When you configure cluster timeouts, ask yourself, "What is the maximum number of logical hosts that a cluster node can potentially master at any time?"

For example, in an N+1 configuration, the standby node can potentially master all the logical hosts of the other cluster nodes. In this case, the reconfiguration timeouts must be large enough to accommodate the time needed to master all of the logical hosts configured in the cluster.

3.14.1 How to Adjust Cluster Timeouts

  1. Adjust the cluster reconfiguration timeouts by using the scconf -T command.

    For example, to change the configurable transition step timeout values to 500 seconds, you would run the following command on all cluster nodes.

    # scconf clustername -T 500

    The default values for these steps are 720 seconds. Use the ssconf -p command to see the current timeout values.

    If there is insufficient time to master all the logical hosts in these steps, error messages are printed on the cluster console.

    Within the reconfiguration steps, the time taken to master a single logical host can vary depending on how many data services are configured on each logical host. If there is insufficient time to master a logical host--if the loghost_timeout parameter is too small--messages similar to the following appear on the console:

    ID[SUNWcluster.ccd.ccdd.5001]: error freeze cmd =
 command /opt/SUNWcluster/bin/loghost_sync timed out.

    In this example, the cluster framework makes a "best effort" to bring the system to a consistent state by attempting to give up the logical host. If this is not successful, the node may abort out of the cluster to prevent inconsistencies.

  2. Use the scconf -l option to adjust the loghost_timeout parameter.

    The default is 180 seconds.

    Note -

    The reconfiguration step timeouts can never be less than the loghost_timeout value. Otherwise, an error results and the cluster configuration file is not modified. This requirement is verified by the scconf -T or scconf -l options. A warning is printed if either of these timeouts is set to 100 seconds or less.