Configuring a Cluster Resource Group container

Learn how to manage multiple Cluster Resource Groups (CRGs) with the CRG container

About CRG containers

CRG containers serve as the control object for a collection of CRGs managed as a single entity for HA operations.

CRG containers can manage device, data, and application CRGs. Similar to the CRGs it manages, the CRG container provides the ability to perform a switchover or failover locally or across sites. A CRG managed by a CRG container is considered a managed CRG. Managed CRGs must maintain consistency with the managing CRG container.

Configuration requirements

For a CRG container to manage CRGs, and for CRGs to remain consistent with the CRG container, these requirements must be in place:
Container recovery domain
Within the CRG container, all managed CRG recovery domains must be a subset of the CRG container recovery domain. A CRG container's recovery domain must have all the nodes located in every managed CRGs' recovery domain.
Cluster nodes
The recovery domain of a CRG managed by a container must have all of its nodes located in the CRG container recovery domain.
Only device, data, and application CRGs can be managed by a CRG container. A managed CRG can be in only one container.
In the HA environment, a site contains a subset of recovery domain nodes in the same physical location. The CRG parameter SITE is required when creating a CRG container. The CRG container is designed to perform its functions at a site level and require nodes to be associated with named sites in their recovery domains, representing the nodes in the same physical location. Managed CRGs using sites in their recovery domains must match the site names that the container CRG uses.
For CRG types Data and Application that do not contain sites, the CRG container logically divides these into sites. For example, a container Site1 has nodes A and B, and Site2 has nodes C and D. A data CRG has nodes A and C, which the container would manage as though the data CRG had a Site1 of node A and a Site2 of node C.
A managed CRG is considered consistent with its container CRG only if the managed CRG has the same source site as the container.
These rules ensure that the CRG container maintains the management functions for the CRGs within it.

CRG container status

A CGR container can have the status of Active, Inactive, or Indoubt depending on the statuses of the CRGs that it manages. The status is dependent on the behavior of the managed CRGs:
A CRG container has the status of Active if all managed CRGs are Active and if all the managed CRGs are consistent with the CRG container.
A CRG container is Inactive if all the managed CRGs are consistent with the container but at least one CRG is inactive.
The container is Indoubt status if at least one managed CRG has an inconsistent recovery domain or if at least one managed CRG has a status of Indoubt.
Like CRGs, a CRG container must be Active to provide protection and switching capabilities.

CRG container failover events

Similar to CRG control of switching resources in the event of a failover, the CRG containers controls failovers for managed CRGs. A CRG container:
  • Can perform a failover only if it has a status of Active.
  • Allows managed CRGs to failover if the managed primary CRG has failed.
  • Can change its source site. As a result of a failover, if the CRG container new primary is in the target site, all managed CRGs are switched to the other site to maintain consistency with the CRG container.

Managed CRGs

If a CRG is a managed CRG inside a container some of its management capabilities are limited.

Cluster configuration operations remain unchanged. Users can add and remove nodes in the recovery domain or assign configuration objects. Cluster management operations for a managed CRG are handled by the CRG container primarily. In some circumstances managed CRGs can perform some management operations:
  • If the CRG container has a status of Inactive, management operations are allowed on a managed CRG if the result of the operation keeps the managed CRG consistent with the CRG container.
  • If the CRG container has a status of Indoubt, all CRG management operations are allowed for the managed CRG.
  • When the status of the container is Active, all management operations on the managed CRG are not allowed.
If a managed CRG requires management operations to be performed on it, then the CRG container must be made Inactive and the CRG removed from the container and reconfigured.
For information about implementing CRG containers in a high availability environment see: