sun.com | docs.sun.com | How To Buy | My Sun | Worldwide Sites |  |

| Previous Contents Index Next
2. Chapter 3 # Determining Cluster Validity This chapter describes how to verify whether a group of nodes form a cluster, and whether the cluster is functioning correctly. Before you perform maintenance tasks or change the cluster configuration, verify that the cluster is functioning correctly. When you have completed maintenance tasks, verify that the cluster is still functioning correctly. This chapter is divided into the following sections: Defining Minimum Criteria for a Cluster Running Highly Available Services Verifying Services on Peer Nodes Verifying That a Cluster Is Configured Correctly Reacting to a Failover ## Defining Minimum Criteria for a Cluster Running Highly Available Services A Foundation Services cluster can run the following highly available services: Reliable NFS and the Reliable Boot Service. For information about highly available services, see the Netra High Availability Suite Foundation Services 2.1 6/03 Overview. A highly available cluster has the following features: A master node and a vice-master node. The master node is the central information point for the cluster. The vice-master node backs up the master node. To verify that there is a master node and a vice-master node in the cluster, see To Verify That the Cluster Has a Master Node and a Vice-Master Node. An `nhcmmd` daemon on each peer node. The `nhcmmd` daemon on the master node manages the membership of the other peer nodes. The `nhcmmd` daemon on other peer nodes receives cluster information from the `nhcmmd` daemon on the master node. To verify that there is an `nhcmmd` daemon on each peer node, perform the procedure described in To Verify That an `nhcmmd` Daemon Is Running on Each Peer Node. A redundant network. When the network is redundant, there is no single point of network failure. To verify that the cluster network is redundant, see To Verify That the Cluster Has a Redundant Ethernet Network. Synchronized master node disk and vice-master node disk. Synchronization ensures that the vice-master node has an up-to-date copy of the information on the master node. To verify that the master node and vice-master node are synchronized, see To Verify That the Master Node and Vice-Master Node Are Synchronized. If your cluster has diskless nodes, the Reliable Boot Service must be running on the master node and the vice-master node. ## Verifying Services on Peer Nodes When performing administration tasks, regularly verify that your cluster is running correctly by performing the procedures described in this section. ### To Verify That the Cluster Has a Master Node and a Vice-Master Node Log in to a master-eligible node as superuser. Type:
       # nhcmmstat -c all
   - The `nhcmmstat` command displays information in the console window about all of the peer nodes. The information includes the role of each node. The peer nodes must include a master node and a vice-master node. For more information, see the `nhcmmstat`(1M) man page. If there is a master node but no vice-master node, reboot the second master-eligible node:
         # init 6
     Verify that the second master-eligible node has become the vice-master node:
         # nhcmmstat -c all
2. If the second master-eligible node does not become the vice-master node, see the Netra High Availability Suite Foundation Services 2.1 6/03 Troubleshooting Guide. If there is neither a master node nor a vice-master node, you do not have a highly available cluster. Verify your cluster configuration by examining the `nhfs.conf` file and the `cluster_nodes_table` file for configuration errors. For more information, see the `nhfs.conf`(4) and `cluster_nodes_table`(4) man pages. If there are two master nodes, you have a split brain error scenario. To investigate the cause of split brain, see the Netra High Availability Suite Foundation Services 2.1 6/03 Troubleshooting Guide. ### To Verify That an `nhcmmd` Daemon Is Running on Each Peer Node Log in to a peer node. Verify that an `nhcmmd` daemon is running on the node:
       # pgrep -x nhcmmd
2. If a process identifier is returned, the daemon is running. If a process identifier is not returned, the daemon is not running. To investigate the cause of daemon failure, see the Netra High Availability Suite Foundation Services 2.1 6/03 Troubleshooting Guide. Repeat Step 1 and Step 2 on each peer node. ### To Verify That the Cluster Has a Redundant Ethernet Network Log in to a peer node as superuser. Verify that the peer nodes are communicating through a network:
       # nhadm check starting
3. If any peer node is not accessible from any other peer node, the `nhadm` command displays an error message in the console window. Search the system log files for this message:
       [ifcheck] Interface interface-name used for cgtp has failed
2. This message is created by the `nhcmmd` daemon if the peer nodes are not communicating through a redundant network. If the redundant network fails, examine the card, cable, and route table associated with the link. Investigate the system log files for relevant error messages. ### To Verify That the Master Node and Vice-Master Node Are Synchronized Log in to a master node as superuser. Test whether the vice-master node is synchronized with the master node:
       # /usr/opt/SUNWesm/sbin/scmadm -S -M
3. 1. If the `scmadm` command reaches the replicating state, the vice-master node is synchronized with the master node. If the `scmadm` command does not reach the replicating state, the vice-master node is not synchronized with the master node. If the master and vice-master nodes are not synchronized, verify if the RNFS.EnableSync parameter is set in to `FALSE` in the `nhfs.conf` file. If the RNFS.EnableSync parameter is set to `FALSE` and if you want to trigger synchronization: Trigger synchronization:
          # nhenablesync
For information on `nhenableysnc`, see `nhenablesync`(1M). Repeat Step 2. If the RNFS.EnableSync parameter is not set to `FALSE` but the vice-master node remains unsynchronized, see the Netra High Availability Suite Foundation Services 2.1 6/03 Troubleshooting Guide. For more information about the `scmadm` command, see the `scmadm`(1M) man page. For more information about the RNFS.EnableSync parameter, see the `nhfs.conf`(4) man page.
Previous Contents Index Next

Copyright 1994-2004 Sun Microsystems