Some research and practices on consistencygroup

Consistency group is a consistency group. It is a new concept introduced by Juno cinder. As the name suggests, it contains two meanings: consistency (consistency) and group (group). How can this be reflected? In terms of data protection or disaster tolerance, you can logically divide a batch of volumes with public operations into a group so that you can easily operate the group, you do not need to perform volume operations one by one. Therefore, the operation should be snapshot and backup.

Currently, only Company E's backend supports this feature, and the blueprint estimation is also proposed by company E. However, I personally think it is very useful in practical applications and belongs to common and public interfaces, which can improve the efficiency of storage resource usage.

Based on the implementation of the current J version code, the modifications are as follows:

• Two tables are added: cgsnapshots and consistencygroups.
• Added the consistencygroup_id attribute, mainly in the volume table and snapshot table;
• Added the consistencygroups quota;
• Provides APIs for creating, deleting, and viewing consistencygroup;
• Provides APIs for creating, deleting, and viewing consistencygroup_snapshot;

The authors have not yet implemented the group backup function. In the discussion of the blueprint, the author also mentioned the work to be done in the future:

1. At the heat layer, we should also understand the consistency group concept of the volume and implement corresponding interfaces;
2. Before taking a snapshot of the consistency group, use the QEMU guest agent to suspend the access to the file system from GuestOS and resume the operation after the end;
3. Supports consistent group backup, including backup of mounted volumes under the execution of the backend storage driver;

The backup function can be combined with the implementation of the current snapshot to do, while the heat is still in the case of a word, and the pause GuestOS file system, is in progress, see bp: https://wiki.openstack.org/wiki/Cinder/QuiescedSnapshotWithQemuGuestAgent

I personally tried this feature in the J version environment. The idea is to create a group in the allinone node, add two volumes, create a unified snapshot, and finally delete the group snapshot. According to the expected results of consistency, two volumes of snapshots are created and deleted. However, the environment does not connect to the back-end of Company E, and only supports LVM. Then, you can simply modify the LVM code to support basic group operations.

First, you must create a consistency group. In the LVM driver code, you must add an attribute to the data ['Pooled '] Dictionary. Otherwise, the filter (mainly capibility) it cannot be used. In the reporting capability interface, "consistencygroup_support = 'true'" is implemented, and null processing can be simply returned:

Def create_consistencygroup (self, context, group): "" Creates a consistencygroup. "# raise NotImplementedError () return None def delete_consistencygroup (self, context, group):" "Deletes a consistency group. "" # raise NotImplementedError () return None, []

In this way, a group is built, and the show result (the cinder client has not yet been implemented and can only be tested using CURL ):

                       

When a group is available, create a volume and specify consistencygroup_id to create two volumes in the same group.

Then prepare to take a snapshot of the group, modify the LVM code again, and add the create_cgsnapshot method. The function is to take a snapshot of all the volumes in the group when creating a group snapshot (for code experiments, refer only):

Def create_cgsnapshot (self, context, cgsnapshot_ref): snapshots = self. db. snapshot_get_all_for_cgsnapshot (context, cgsnapshot_ref ['id']) model_update = {"status": "available"} for sn in snapshots: try: self. create_snapshot (sn) failed t Exception as e: LOG. error ("create snapshot % s fail. "% sn) sn ['status'] = 'error' model_update [" status "] =" error "return model_update, snapshots

 

After the snapshot is executed, you can see that two snapshots belong to this group are generated and a consistencygroup_snapshot data is generated. Show Results:

                            

Two snapshots:

At this time, if you create another volume for this group, the error 400 will be reported because the current group has snapshots and cannot be modified.

"Consistency group b37f1d21-390e-4128-8fd6-2ca4789d9fc2 still has dependent cgsnapshots ."

Then, add a deletion interface to the LVM code (for code experiment purposes, for reference only ):

Def delete_cgsnapshot (self, context, cgsnapshot_ref): snapshots = self. db. snapshot_get_all_for_cgsnapshot (context, cgsnapshot_ref ['id']) model_update = {'status': 'available'} for sn in snapshots: try: self. delete_snapshot (sn) failed t Exception as e: LOG. error ("delete snapshot % s fail" % sn) model_update ['status'] = 'error' sn ['status'] = 'error' return model_update, snapshots

After the execution, the consistencygroup_snapshot object disappears and the two snapshots are deleted successfully.

                            

Automatic snapshot disappearance:

So far, the expected results are achieved. Of course, this is the simplest scenario, and LVM can only implement a single-node storage pool. Multi-node storage cannot be implemented at all. In addition, many scenarios are not considered, such as repeated snapshot creation and multiple volume_types in a group.

The entire experiment process is not complex, but it is much more difficult than expected for the first time. Some details need to be explored:

1. The interface for creating a group must input at least one volume_type, which means that the consistency group and volume type are strongly correlated. (the discussion on ethpad is somewhat different, from the interface, multiple volume_types and the corresponding relationship between groups are supported)
2. When the backend storage reports its hardware capabilities, to create a consistency group, you must specify a parameter, "consistencygroup_support = 'true'", and True must be a string;
3. The driver code of the back-end storage must implement the corresponding method, such as "create_consistencygroup" and "delete_consistencygroup". Snapshot-related methods include "create_cgsnapshot" and "delete_cgsnapshot ";

Therefore, if a storage vendor wants to implement its own consistency group, pay attention to the above issues during the development process.

Refer:

Https://etherpad.openstack.org/p/juno-cinder-cinder-consistency-groups

Https://blueprints.launchpad.net/cinder/+spec/consistency-groups

######

Finally, some APIs used in the process are listed as follows for your reference:

Type	URL	Body	RSP
ADD consistencygroup	V2/$ tenant_id/consistencygroups	{"Consistencygroup ":{ "Name": "my_cg ", "Description ":"***", "Volume_types": "Type1 "}}	N/
GET consistencygroups	V2/$ tenant_id/consistencygroups/detail? All_tenants = 1	N/	{"Consistencygroups ":[{ "Status": "available ", "Description ":"***", "Availability_zone": "nova ", "Created_at ":"---", "Id ":"*", "Name": "my_cg"}]}
DEL consistencygroup	V2/$ tenant_id/consistencygroups/$ cg_id	{"Consistencygroup ": {"Force": "True "}}	N/
ADD cg_snapshot	V2/$ tenant_id/cgsnapshots	{"Cgsnapshot ":{ "Consistencygroup_id ":"***", "Name": "my_cg_snapshot ", "Description ":"***"}}	N/
GET cg_snapshot	V1/$ tenant_id/cgsnapshots/detail? All_tenants = 1	N/	{"Cgsnapshots ":[{ "Status": "available ", "Description ":"***", "Created_at ":"***", "Consistencygroup_id ":"***", "Id ":"***", "Name": "***"}]}
DEL cg_snapshot	V2/$ tenant_id/cgsnapshots/$ cgsnapshot_id	N/	N/

 

    

Some research and practices on consistencygroup