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

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 Formats | cluster_nodes_table(4)

- NAME
- SYNOPSIS
- DESCRIPTION
- EXTENDED DESCRIPTION
- WARNINGS
- ATTRIBUTES
- SEE ALSO

## 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:

> #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.

## 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 TYPE | ATTRIBUTE VALUE
> --- | ---
> Architecture | SPARC
> Availability | SUNWnhcma
> Interface Stability | Evolving

## SEE ALSO

> `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

Company Info | Contact | Copyright 2004 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.