Container cluster resource group
Manage multiple Cluster Resource Groups (CRGs) with the CRG container
About CRG containers
A CRG container serves 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
- 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.
- CRG
- Only device, data, and application CRGs can be managed by a CRG container. A managed CRG can be in only one container.
- Site
- 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.
- Consistency
- A managed CRG is considered consistent with its container CRG only if the managed CRG has the same source site as the container.
CRG container status
A CGR container can have an active, inactive, or indoubt status depending on the statuses of the CRGs it manages. Like CRGs, a CRG container must be active to provide protection and switching capabilities.
CRG container commands
CRG containers rely on much of the underlying technology that CRGs use and thus utilize many of the same commands that the CRGs use. Many functions of the CRG container can be managed from the Work with Cluster Resource Groups screen used to create and manage CRGs. Some commands however, are different for containers even though they may perform a task similar to a CRG command. CRG containers use a CNR suffix to distinguish the command is used on a CRG container. For example, the Start CRG (STRCRG) command for a CRG container is STRCRGCNR, Start CRG container. Table below lists related commands between CRGs and CRG containers.
| CRG command | CRG container command |
|---|---|
| Create CRG (CRTCRG) | Create CRG container (CRTCRGCNR) |
| Delete CRG (DLTCRG) | Delete CRG container (DLTCRGCNR) |
| Start CRG (STRCRG) | Start CRG container (STRCRGCNR) |
| End CRG (ENDCRG) | End CRG container (ENDCRGCNR) |
| Display CRG information (DSPCRGINF) | Display CRG container (DSPCRGCNR) |
| Configure CRG container (CFGCRGCNR) | |
| Change CRG primary (CHGCRGPRI) | Change CRG primary (CHGCRGPRI) |
To learn more about CRG containers and how to work with them, see Creating and configuring a Cluster Resource Group container in the Implementing High Availability section of the IBM Documentation.