3.1.1 Abstract Data Model
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to explain how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with the behavior that is described in this document.
A server that implements this protocol is potentially a node in a failover cluster. As such, a server maintains state indicating whether or not it is configured as a node in a failover cluster and whether or not the cluster software is currently running such that this information can be reported upon request.
A server that is an active node in a failover cluster has access to the current cluster state by using implementation-specific mechanisms and protocols between servers. The cluster state consists of all the nonvolatile configuration and volatile current status data that is maintained by the cluster and accessible to active nodes. For example, the cluster state includes the cluster name; the configuration and status of nodes (section 188.8.131.52), cluster networks (section 184.108.40.206), and cluster network interfaces (section 220.127.116.11); the configuration and status of resources (section 18.104.22.168.1), resource types (section 22.214.171.124), and groups (section 126.96.36.199.4); the content of the cluster registry (section 188.8.131.52); and the cluster security descriptor (section 184.108.40.206).
The cluster name is a nonvolatile property of the cluster that is used to uniquely identify the cluster. The cluster name is case-insensitive and consists of a DNS host name (in the format of a label as specified in [RFC1035]).
A server maintains its protocol server state. This indicates the extent to which it can accept protocol requests that operate on the cluster state. The protocol server state has one of the following values:
None: The node has not sufficiently initialized to accept any protocol requests.
Read-Write: The node can accept all requests.
Read-Only: The node can accept requests that do not modify the cluster state.
Any active node in the cluster can accept ClusAPI Protocol requests from valid clients. A valid client (1) is a client that has successfully completed the initialization steps as specified in section 3.2.3. For client requests that change the cluster state, after the client request is completed, the updated cluster state is accessible to the same or other protocol clients by means of a ClusAPI Protocol session to any active node.
A node that is running the cluster software but is not yet an active node in the cluster can accept ClusAPI Protocol requests that do not modify the cluster state. For this to occur, each node locally maintains its protocol server state, which indicates the extent to which it can accept protocol requests that operate on the cluster state. A server supports the following values for protocol server state: None (indicating that the node has not sufficiently initialized to accept any protocol requests), Read-Only (indicating that the node accepts requests that do not modify the cluster state), and Read-Write (indicating that the node accepts all requests). The protocol server state of an active node is Read-Write, as specified in ApiGetNodeState Opnum 68 (section 220.127.116.11.69) for protocol version 2, or 18.104.22.168.69 for protocol version 3).