Sun Microsystems Logo
Products and Services
 
Support and Training
 
 

A  B  C  D  E  F  G  H  I  J  K  L  M  N  O  P  Q  R  S  T  U  V  W  X  Y  Z  
 
File Formatscluster_nodes_table(4)


NAME

 cluster_nodes_table - central cluster management file

SYNOPSIS

 /etc/opt/SUNWcgha/cluster_nodes_table

DESCRIPTION

The cluster_nodes_table contains a definition for each node in the cluster. The cluster_nodes_table is located on each master-eligible node. This file stores the membership and configuration information for all peer nodes in a cluster including potential future nodes. A node must have an entry in the cluster_nodes_table to be part of a cluster.

If you install the software on the cluster manually, as described in the Netra High Availability Suite Foundation Services 2.1 6/03 Custom Installation Guide, you must create this file on each master-eligible node. A template of the cluster_nodes_table file is available in /etc/opt/SUNWcgha/cluster_nodes_table.template.

By default, the cluster_nodes_table is located in the /etc/opt/SUNWcgha/ directory on each master-eligible node. You can change the path to the cluster node table by editing the parameter CMM.LocalConfig.Dir parameter in the nhfs.conf file. For more information on nhfs.conf, see the nhfs.conf(4) man page.

The following is an example of a cluster node table with three peer nodes:

#NodeIdDomain_idNameAttributes
10250netraMEN1-cgtp0-
20250netraMEN2-cgtp0-
30250netraDISKLESS1-cgtp0-
NodeId

This is the unique node ID within the cluster. This number is the decimal equivalent of the host part of the node's IP address.

Domain_id

This is the unique cluster ID within the cluster domain and must be the same for each peer node. This Domain_id must be the same as the one defined in the nhfs.conf file. For more information see the nhfs.conf(4) man page.

Name

This is the node name. The name must be the same as the one in the nhfs.conf file on the node. See the nhfs.conf(4) man page.

Attributes

Each node can be assigned the following attributes:

Note – Do not alter the role of a node by modifying the attribute column of cluster_nodes_table file.
D

Disqualified

D corresponds to the CMM_DISQUALIFIED_MEMBER attribute of the CMM API. If a node is flagged as disqualified, it cannot be assigned a master or vice-master role. This attribute is only applied to a master-eligible node.

S

Synchronization needed

If a node has the S flag, the disks of the master node and vice-master nodes are not synchronized. This is a read-only flag and must not be changed manually. This attribute applies only to master-eligible nodes.

-

Not Disqualified

If a node has this attribute, the node is not disqualified and is in the cluster.

To check the role of a node, use the nhcmmstat command, as described in the nhcmmstat(1m) man page.

EXTENDED DESCRIPTION

If you want to add a new node to a cluster you must either verify that the node already has an entry in the cluster node table or create an entry for this node in the table. You must only modify this file during initial cluster configuration if you install the software manually on the cluster or if you are adding or removing a node. For more information, see the cmm_config_reload(3CMM) man page.

When editing the cluster node table file, make sure that:

  1. The NodeId for each node in the cluster_nodes_table is unique. If this is not the case, use nhcmmstat to determine the correct NodeId of the peer nodes and modify the cluster node table.

  2. The NodeId for each node in the cluster_nodes_table has a value n such that 3<n<255. If this is not the case, modify the cluster node table.

  3. The master-eligible nodes have the attribute "-" in cluster_nodes_table. If this is not the case, correct this error in the file.

All other updates are performed automatically by the nhcmmd daemon. The nhcmmd daemon on the master node uses the cluster node table to know which nodes are in the cluster and what attributes they are assigned.

The cluster_nodes_table is read and changed automatically by the nhcmmd daemon as follows:

  1. When the master node is elected:

    1. The master node reads the cluster_nodes_table and stores it in memory.

    2. The master node broadcasts this view of the cluster_nodes_table to peer nodes in the cluster.

    3. Each master-eligible node receives this view and stores this view of the cluster_nodes_table.

  2. When the cluster is running:

    1. After the cluster is up and running, the cluster_nodes_table is only read when a cmm_config_reload() is called or when the following command is executed:

      # nhcmmstat -c reload
      
    2. The master node reads and stores the new view of the cluster_nodes_table in memory.

    3. The master node broadcasts the new view to peer nodes in the cluster.

    4. The vice-master node receives this view and stores this view of the cluster_nodes_table.

  3. The cluster_nodes_table is modified when an attribute of a node has been changed through the API, for example, cmm_member_setqualif().

The preceding methods of creating and managing the cluster_nodes_table file, ensures that the cluster_nodes_table is persistent, that is, if the cluster goes down for any reason, the same cluster_nodes_table file is restored when the cluster comes back up, no matter which master-eligible nodes is elected master.

WARNINGS

Changes should not be made to the cluster node table without careful consideration because the cluster node table maintains the central view of the cluster membership and node status. Altering the cluster node table can result in a cluster that is not highly available.

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPEATTRIBUTE VALUE
ArchitectureSPARC
AvailabilitySUNWnhcma
Interface StabilityEvolving

SEE ALSO

nhcmmd(1M), nhadm(1M), nhfs.conf(4), nhcmmstat(1M), cmm_config_reload(3CMM)


Netra HAS FS 2.1Go To TopLast Changed September 2004