NAME
cluster_nodes_table - central cluster
management file
SYNOPSIS
/etc/opt/SUNWcgha/cluster_nodes_table
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:
#NodeId | Domain_id | Name | Attributes |
10 | 250 | netraMEN1-cgtp0 | - |
20 | 250 | netraMEN2-cgtp0 | - |
30 | 250 | netraDISKLESS1-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.
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:
-
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.
-
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.
-
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:
-
When the master node is elected:
-
The master node reads the cluster_nodes_table
and stores it in memory.
-
The master node broadcasts this view of the cluster_nodes_table to peer nodes in the cluster.
-
Each master-eligible node receives this view and stores this
view of the cluster_nodes_table.
-
When the cluster is running:
-
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
-
The master node reads and stores the new view of the cluster_nodes_table in memory.
-
The master node broadcasts the new view to peer nodes in the
cluster.
-
The vice-master node receives this view and stores this view
of the cluster_nodes_table.
-
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.
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.
See attributes(5)
for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
Architecture | SPARC |
Availability | SUNWnhcma |
Interface Stability | Evolving |
nhcmmd(1M), nhadm(1M), nhfs.conf(4), nhcmmstat(1M), cmm_config_reload(3CMM)
Netra HAS FS 2.1 | Go To Top | Last Changed September 2004 |