Consistency Group (CG)

Group a list of volumes that are backed-up and restored in a consistent manner.

Application data protection scenarios (backup, restore, and disaster recovery) need to ensure that the data is being backed-up or replicated in a consistent way. An application can consist of one or more groups, which can require the data within group to be consistently backed up and restored. The group where the data needed to be consistent is referred to as Consistency Group (CG). In the context of IBM Storage Scale Container Storage Interface driver or IBM Storage Scale, CG is represented as a list of volumes that are backed up and restored in a consistent way.

The consistency of volumes that belong to the same CG is achieved by taking the snapshot of all at a single point. In IBM Storage Scale, the snapshot of volumes refers volumes to the same snapshot of their parent.

The CG of a volume is decided at the time of volume creation. CG is defined at namespace level, indicating that all the PVs created in the same namespace belong to the same CG.

Volume Creation and Deletion

A special parameter (version=2) is introduced in storageClass to differentiate volumes for CG and classic volumes.

When PVC is created for CG (namespace) in Kubernetes, IBM Storage Scale Container Storage Interface driver will create an independent fileset on IBM Storage Scale representing the consistency group, if not already available. IBM Storage Scale Container Storage Interface driver will then create the dependent fileset within the independent fileset with quota equal to size of requested PVC.

If the PVC that belongs to the CG is deleted, IBM Storage Scale Container Storage Interface driver will delete the dependent fileset that represents the PVC. If it is the last PVC in the CG, then the independent fileset is also deleted.

You can have volumes from different storageClasses into the same CG, provided storageClass has version 2 and same volBackendFs.

Volume Snapshot Creation and Deletion

Volume snapshot plays a main role in maintaining the consistency of a CG. The consistency of a CG is achieved by taking a snapshot of the independent fileset instead of the dependent fileset presenting PVC.

If you invoke the snapshot from Kubernetes for a particular PVC that belongs to a CG, IBM Storage Scale Container Storage Interface driver will take the snapshot of the parent, which is an independent fileset representing a CG.

You are expected to create a volume snapshot for all the PVCs that belong to a CG in a short span of time. It is essential to create Kubernetes snapshot for all the PVCs that belong to a CG because the snapshot details are used to restore or create the PVC from the snapshot.

IBM Storage Scale Container Storage Interface driver has introduced a new parameter that is called snapWindow in volumeSnapshotClass. If you request the snapshot of all volumes that belong to a CG, it results in a single snapshot on an independent fileset on IBM Storage Scale. The first snapshot request results in an actual snapshot on IBM Storage Scale while subsequent snapshots will be no-op and returned successfully with reference to successful independent fileset snapshot.

The next snapshot of independent fileset is taken if there is a snapshot request from Kubernetes, and no snapshot of independent fileset taken within the time specified in volumeSnapshotClass. Otherwise, the snapshot request from Kubernetes keeps referring to the previous independent fileset snapshot.

The snapshot in IBM Storage Scale is also deleted when you delete all the snapshots that are referring it in Kubernetes.

You must verify that all the snapshots created for a CG that require consistency are referring to same IBM Storage Scale snapshot.

Other features like volume expansion, volume cloning, tearing support, compression support works in the same way as with classic volumes.