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

| Previous Contents Index Next
Chapter 2 # Introduction to the Properties of a Node This chapter introduces the roles, qualification levels and attributes of nodes. For information about the types of nodes, see the Netra High Availability Suite Foundation Services 2.1 6/03 Overview. Membership Roles Qualification Levels Administrative Attributes ## Membership Roles Peer nodes can be recognized by the CMM API as having the following membership roles:
Master node | A node with membership role `CMM_MASTER`. This node coordinates all of the cluster membership information. The master node has the current view of the cluster configuration and all the nodes receive the cluster view from the master node.
Vice-master node | A node with membership role `CMM_VICEMASTER`. The vice-master node can take over the master role of the cluster. The vice-master node has its own copy of the `cluster_nodes_table` file. For more information, see the `cluster_nodes_table`(4) man page.
Out node | Any node configured to be in the cluster that has the membership role `CMM_OUT_OF_CLUSTER`. This role means that the node is not available for use, for either physical or administrative reasons. Do not distribute tasks on an out node, because it might be undergoing maintenance.
No membership role is assigned to a node running the Foundation Services services and fully participating in cluster communication that is neither a master node nor a vice-master node. Further information about nodes in the cluster is provided by the `cluster_nodes_table`(4) man page. For information about the definitions of the roles of nodes in the cluster, see "Cluster Model" in the Netra High Availability Suite Foundation Services 2.1 6/03 Overview. Membership roles are dynamic and are defined by the master node. Unless the membership role of a node is `CMM_OUT_OF_CLUSTER`, the node is by default viewed as being in the cluster. While the node has the `CMM_OUT_OF_CLUSTER` role, the qualification level and `CMM_FLAG_SYNCHRO_NEEDED` flag are meaningless. Information about the membership role of a node can be found in the `sflag` field of the `cmm_member_t` structure. See Using the `sflag` Field of the `cmm_member_t` Structure. ## Qualification Levels The qualification level of a node is applicable only to master-eligible nodes. On these nodes, the qualification level determines whether the node can participate in an election for the master role or vice-master role. A master-eligible node can be qualified or disqualified. The qualification levels of a master-eligible node are:
`CMM_QUALIFIED_MEMBER` | The node is qualified to be master. Only meaningful for eligible nodes.
`CMM_DISQUALIFIED_MEMBER` | The node is disqualified from being master. Only meaningful for eligible nodes.
For master-eligible nodes, the qualification level is stored in the minimum configuration file, `target.conf`, on the node and in the cluster node table. For more information, see the `target.conf`(4) man page. The qualification level is persistent, that is, if the node is rebooted, the node starts with the same qualification level it had before the reboot. The qualification level of a node can be changed during runtime. Diskless and dataless nodes are never assigned qualification levels. To assign a new qualification level to a node, use the `cmm_member_setqualif` function. For more information, see the `cmm_member_setqualif`(3CMM) man page. An example in which this function is used to trigger a failover in the cluster is provided in this book. See Triggering a Failover by Using the `cmm_member_setqualif()`Function. ## Administrative Attributes The CMM API recognizes each node in the cluster as having an administrative attribute. An attribute can be any of the following: `CMM_ELIGIBLE_MEMBER` The node is a member of the cluster. The node is a master-eligible node, therefore it is diskfull and can participate in a master or vice-master election. `CMM_FLAG_DISQUALIFIED` The node is part of the cluster and is master-eligible, but this node cannot participate currently in master elections. This flag applies only to master-eligible nodes. `CMM_FLAG_SYNCHRO_NEEDED` The master node disk and vice-master node disk must be synchronized so that the vice-master node can take over the role of master node if necessary. If the disks are not synchronized, the vice-master node cannot become the master node. If the `CMM_FLAG_SYNCHRO_NEEDED` flag is set, the vice-master node disk is not up-to-date. When the master node disk and vice-master node disks are synchronized, the flag is cleared. The flag applies only to master-eligible nodes, and must not be set by applications. For more information about Reliable NFS, see the Netra High Availability Suite Foundation Services 2.1 6/03 Overview. A master node can be demoted because of a change in its administrative attributes, when the vice-master detects a problem on the master, or after a call to the `cmm_mastership_release()` function. The master node can also be demoted in the case of a failover. See Failover Notifications. A node assumes the master role if it is sufficiently qualified. Information about the administrative attributes of a node can be found in the `sflag` field of the `cmm_member_t` structure. For more information, see Using the `sflag` Field of the `cmm_member_t` Structure.
Previous Contents Index Next

Copyright 1994-2004 Sun Microsystems