3.1.1.6 Nodes

  • Article

A cluster node object represents a server that is configured as a member of a cluster. A server cannot be a member of more than one cluster simultaneously. A node is configured when it is added to the cluster nonvolatile configuration; evicting a node removes it from the cluster nonvolatile configuration. Adding a server to the cluster configuration and becoming an active node in the cluster are performed through implementation-specific methods and protocols between servers.

A node is uniquely identified in a cluster by separate Unicode strings that contain the computer name of the server and the node's ID. The node name is case-insensitive and consists of a DNS host name (in the format of a label as specified in [RFC1035]). The node ID is represented as a positive integer within the range of 1 and the maximum number of nodes in the cluster (but no greater than 0xFFFFFFFF), and is assigned by the cluster when the server is added to the cluster. The node name and ID cannot change while the server is a configured member of the cluster.

Each node has an associated persistent state, which has a value of either operational or paused. The persistent state of a node is stored in a nonvolatile cluster state. The persistent state of a node indicates whether the node was most recently commanded to transition to operational or paused by a protocol client. The server initializes the persistent node state to operational when a server is added to the cluster nonvolatile configuration. A client can query the current state of a node. The server maintains the current state of a node. The current state of a node is one of the values specified in ApiGetNodeState (Opnum 68; see 3.1.4.1.69 for protocol version 2 or 3.1.4.2.69 for protocol version 3) when a client successfully queries for the state.

A cluster node has no defined characteristics.

The nonvolatile cluster state associated with a node includes a set of flags; these flags can be set by a client individually for each cluster node, and the server will return them when queried by a client. These flags will not be interpreted by the server and will not be associated with any semantics on the server.

A ClusAPI Protocol client can perform the following management operations on a cluster node:

  • Pause: Pause group failover activity and set the persistent state of the node to paused, see ApiPauseNode (Opnum 69; 3.1.4.1.70 for protocol version 2 or 3.1.4.2.70 for protocol version 3).

  • Resume: Resume group failover activity and set the persistent state of the node to operational, see ApiResumeNode (Opnum 70; 3.1.4.1.71 for protocol version 2 or 3.1.4.2.71 for protocol version 3).

  • Evict: Remove a configured node from a cluster, see ApiEvictNode (Opnum 71; 3.1.4.1.72 for protocol version 2 or 3.1.4.2.72 for protocol version 3).

  • Query the configured nodes: Querying a cluster for a list of its configured nodes, see ApiCreateEnum (Opnum 7; 3.1.4.1.8 for protocol version 2 or 3.1.4.2.8 for protocol version 3).

  • Query configuration: Querying the configuration data for a node, see ApiGetNodeId (Opnum 48; 3.1.4.1.49 for protocol version 2 or 3.1.4.2.49 for protocol version 3), ApiNodeNodeControl (Opnum 78; 3.1.4.1.79 for protocol version 2 or 3.1.4.2.79 for protocol version 3), ApiNodeControl (Opnum 79; 3.1.4.1.80 for protocol version 2 or 3.1.4.2.80 for protocol version 3), and ApiCreateNodeEnum (Opnum 101; 3.1.4.1.101 for protocol version 2 or 3.1.4.2.101 for protocol version 3).

  • Set configuration: Change the configuration data for a node, see ApiNodeNodeControl (Opnum 78; 3.1.4.1.79 for protocol version 2 or 3.1.4.2.79 for protocol version 3) and ApiNodeControl (Opnum 79; 3.1.4.1.80 for protocol version 2 or 3.1.4.2.80 for protocol version 3).