3.1.1.1.4 Groups

  • Article

A group is a container for zero or more cluster resources. Each resource is contained by exactly one group. Groups cannot be nested in other groups; that is, a group contains only resources--not other groups. Groups are the unit of ownership in a cluster; that is, all the resources in a group are owned by the same node. A resource cannot depend on a resource that is in a different group from itself. In order for two resources to be configured in a dependency relation, they need to be in the same group.

Groups have a state that is calculated from the configuration and state of the resources that are contained in that group.

Each group has an associated persistent state, which has a value of either online or offline. The persistent state of a group is stored in a nonvolatile cluster state. The persistent state of a group indicates whether the group was most recently commanded to transition online or offline by a protocol client. A group maintains state as indicated in section 3.1.4.2.46.

A resource can move from one group to another.

A ClusAPI Protocol client can perform the following management operations on a cluster group (see section 4.2 for an example):

  • Create: Create a new, empty instance of a group. For more information, see section 3.1.4.1.43 (protocol version 2) and section 3.1.4.2.43 (protocol version 3).

  • Delete: Delete a group from the nonvolatile cluster state. For more information, see section 3.1.4.1.44 (protocol version 2) and section 3.1.4.2.44 (protocol version 3).

  • Online: Bringing a group online consists of bringing all the resources in a group to their online state. For more information, see section 3.1.4.1.50 (protocol version 2) and section 3.1.4.2.50 (protocol version 3).

  • Offline: Bringing a group offline consists of bringing all the resources in a group to their offline state. For more information, see section 3.1.4.1.51 (protocol version 2) and 3.1.4.2.51 (protocol version 3).

  • Get state: Query the state of the group. See section 3.1.4.1.46 (protocol version 2) and 3.1.4.2.46 (protocol version 3) for more details.

  • Move: Change ownership of the group to another node in the cluster. For more information, see sections 3.1.4.1.52 and 3.1.4.1.53 (protocol version 2), and sections 3.1.4.2.52 and 3.1.4.2.53 (protocol version 3).

  • Query configuration: Querying the configuration data for a group. For more information, see sections 3.1.4.1.8, 3.1.4.1.48, 3.1.4.1.54, 3.1.4.1.77 and 3.1.4.1.78 (protocol version 2), and sections 3.1.4.2.8, 3.1.4.2.48, 3.1.4.2.54, 3.1.4.2.77 and 3.1.4.2.78 (protocol version 3).

  • Set configuration: Change the configuration data for a group. For more information, see sections 3.1.4.1.47, 3.1.4.1.55, 3.1.4.1.77 and 3.1.4.1.78 (protocol version 2), and sections 3.1.4.2.47, 3.1.4.2.55, 3.1.4.2.77 and 3.1.4.2.78 (protocol version 3).

A group can be uniquely identified in a cluster by separate Unicode strings that contain the name and ID of the group. Both the group name and group ID are case-insensitive and contain any Unicode character in any position except as follows: the string is null-terminated, the string contains no Unicode null character other than for termination, and the string contains at least one character that is not Unicode 0x20, 0x09, 0x0d, 0x0a, and null. The size of group name and ID strings are not limited by this protocol. The group name can be changed (so long as it remains unique). The group ID is assigned by the cluster at group creation and remains constant until the resource is deleted.

Groups, and the resources that are contained in each group, are part of the nonvolatile cluster state.

A group maintains a prioritized list of configured nodes that are considered to be the preferred hosts of the group. The list is initialized as empty when a group is created, indicating that there is no hosting preference for the group. The list is stored as part of the nonvolatile cluster state.

A cluster group has no defined characteristics.

The nonvolatile cluster state associated with a group includes a set of flags; these flags can be set by a client individually for each group, and the server returns them when queried by a client. The flags, as defined in section 2.2.2.5, are interpreted by the server as appropriate for the individual flag value. Any other flag values will not be interpreted by the server or associated with any semantics.

A group maintains a state sequence number that represents whether a change in the group's state has occurred. It is monotonically incremented for any transition between the group states, as specified in section 3.1.4.2.46.

Affinity establishes a relationship between two or more specified roles (for example, virtual machines, resource groups, etc.) to keep them together on the group’s cluster nodes. Anti-affinity is the same but is used to keep the specified roles apart from each other.

It is possible for a group to have anti-affinity with other groups. The anti-affinity setting identifies groups in the cluster that, if possible given current cluster conditions, won't typically be hosted on the same node. The nonvolatile cluster state associated with a group is often used to indicate anti-affinity with other groups. The format and means of configuring the anti-affinity setting are implementation-specific. For instance, it might not be possible to honor anti-affinity settings if only one node in the cluster is active, meaning that there is only one node in the cluster capable of hosting groups.

A group has a type. This is a DWORD value that is assigned to the group when it is created. The group type behavior is further described in section 3.1.4.2.128.

A group is in locked mode<50> if one or more resources contained in the group are in locked mode (section 3.1.1.1.1).

A group can be designated as a special group. The special group designation prohibits a protocol client from performing the following operations on the group:

  • Bringing the group online (ApiOnlineGroup (Opnum 49); section 3.1.4.1.50 for protocol version 2, or section 3.1.4.2.50 for protocol version 3).

  • Bringing the group offline (ApiOfflineGroup (Opnum 50); section 3.1.4.1.51 for protocol version 2, or section 3.1.4.2.51 for protocol version 3).

  • Changing the node list (ApiSetGroupNodeList (Opnum 54); section 3.1.4.1.55 for protocol version 2, or section 3.1.4.2.55 for protocol version 3).

How a server determines which groups are special groups is implementation-specific, except as specified in ApiChangeCsvState (Opnum 123) (section 3.1.4.2.122) and ApiChangeCsvStateEx (Opnum 182) (section 3.1.4.2.164) (protocol version 3 only).