Partager via

3.1.1 Abstract Data Model

  • Article

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 3.1.1.6), cluster networks (section 3.1.1.7), and cluster network interfaces (section 3.1.1.7); the configuration and status of resources (section 3.1.1.1.1), resource types (section 3.1.1.5), and groups (section 3.1.1.1.4); the content of the cluster registry (section 3.1.1.2); and the cluster security descriptor (section 3.1.1.3).

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  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 3.1.4.1.69) for protocol version 2, or 3.1.4.2.69 for protocol version 3).