Snapshot management method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a snapshot management method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the following steps: receiving a consistent snapshot creation request sent by a client; the creation request carries consistent snapshot group information and creation request parameters; determining a target storage rear end according to the creation request parameter; calling a first target driving layer through the universal interface layer to execute a creation operation according to the creation request parameter and the consistency snapshot group information; the universal interface layer encapsulates the driving layer corresponding to each storage rear end; the first target driving layer is a driving layer corresponding to the target storage rear end; and under the condition that the creation operation is successful, serializing the created first consistent snapshot group data to obtain a first serialization result, and returning the first serialization result to the client. By adopting the method, the universality of snapshot management can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of snapshots, and in particular, to a snapshot management method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Art

[0002] With the continuous development of cloud computing technology, the demand of enterprises and individual developers for data backup and recovery on cloud platforms is increasing. Snapshot technology can save and restore the data of a storage volume at a certain point in time, which is a common function for a single storage volume in the cloud storage field. In some scenarios of cloud computing, it is necessary to logically group a batch of volumes with common operations to make it more convenient for users to operate snapshots. Because unified operations can be performed on multiple associated storage volumes to ensure data consistency, the technical application of consistent snapshots has gradually emerged.

[0003] In traditional technologies, the implementation methods of consistent snapshot functions vary greatly among different manufacturers, and even some manufacturers do not provide relevant functions. Therefore, different storage manufacturers have different implementation methods for consistent snapshots, resulting in poor generality of snapshot management. Summary of the Invention

[0004] Based on this, in view of the above technical problems, it is necessary to provide a snapshot management method, apparatus, computer device, computer-readable storage medium, and computer program product that can improve generality.

[0005] In a first aspect, the present application provides a snapshot management method applied to a server, and the method includes:

[0006] Receiving a creation request for a consistent snapshot sent by a client; the creation request carries consistent snapshot group information and creation request parameters;

[0007] Determining a target storage backend according to the creation request parameters;

[0008] Invoking a first target driver layer through a general interface layer to perform a creation operation according to the creation request parameters and the consistent snapshot group information; the general interface layer encapsulates the driver layer corresponding to each storage backend; the first target driver layer is the driver layer corresponding to the target storage backend;

[0009] In the case where the creation operation is successful, serializing the created first consistent snapshot group data to obtain a first serialization result, and returning the first serialization result to the client.

[0010] In one of the embodiments, the receiving a creation request for a consistent snapshot sent by a client includes:

[0011] Receive a creation request for a consistent snapshot sent by the client through the control layer;

[0012] Determining the target storage backend according to the creation request parameters includes:

[0013] Call the scheduler through the control layer to determine a storage backend from the database as the target storage backend according to the creation request parameters; the mapping relationship between the creation request parameters and the storage backend is stored in the database.

[0014] In one embodiment, determining the target storage backend according to the creation request parameters includes:

[0015] When the target storage backend parameter is included in the creation request parameters, determine the target storage backend from the database through the control layer according to the target storage backend parameter; wherein, the mapping relationship between the target storage backend parameter and the target storage backend is stored in the database.

[0016] In one embodiment, calling the first target driver layer through the general interface layer to perform a creation operation according to the creation request parameters and the consistent snapshot group information includes:

[0017] Perform a heartbeat check on the target volume service through the general interface layer. When the target volume service passes the heartbeat check, call the target volume service through the general interface layer. The target volume service is the volume service corresponding to the target storage backend, and there is a one-to-one correspondence between the storage backend and the volume service;

[0018] Call the first target driver layer through the target volume service to perform a creation operation according to the creation request parameters and the consistent snapshot group information. The first target driver layer corresponds to the target volume service.

[0019] In one embodiment, the method further includes:

[0020] Receive a clone request for a consistent snapshot sent by the client;

[0021] According to the clone request, obtain the second consistent snapshot group data and obtain the total amount of snapshot data of the second consistent snapshot group data;

[0022] Obtain the consistent group corresponding to the storage of the second consistent snapshot group data. The consistent group includes multiple source volumes; the source volume is the volume storing the second consistent snapshot group data;

[0023] Calculate the capacity of each source volume through the general interface layer and determine the total source volume capacity according to the capacity of each source volume;

[0024] When the total amount of the snapshot data is the same as the total capacity of the source volume, the second target driver layer is called through the general interface layer to perform a cloning operation on the consistency group;

[0025] When the cloning operation is successful, the newly cloned volume is serialized to obtain a second serialization result, and the second serialization result is returned to the client, where the new volume is obtained based on the storage backend.

[0026] In one embodiment, the method includes:

[0027] The newly cloned volume is set as a volume with a target read / write specification through the general interface layer.

[0028] In a second aspect, the present application further provides a snapshot management device, and the device includes:

[0029] A receiving module, configured to receive a creation request for a consistency snapshot sent by a client; the creation request carries consistency snapshot group information and creation request parameters;

[0030] A storage backend determination module, configured to determine a target storage backend according to the creation request parameters;

[0031] A creation module, configured to call a first target driver layer through a general interface layer to perform a creation operation according to the creation request parameters and the consistency snapshot group information; the general interface layer encapsulates the driver layer corresponding to each storage backend; the first target driver layer is the driver layer corresponding to the target storage backend;

[0032] A serialization module, configured to serialize the first consistency snapshot group data obtained by creation to obtain a first serialization result and return the first serialization result to the client when the creation operation is successful.

[0033] In a third aspect, the present application further provides a computer device, including a memory and a processor, where the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0034] In a fourth aspect, the present application further provides a computer-readable storage medium, on which a computer program is stored, and the computer program implements the steps of the above method when being executed by a processor.

[0035] In a fifth aspect, the present application further provides a computer program product, including a computer program, and the computer program implements the steps of the above method when being executed by a processor.

[0036] The above snapshot management method, device, computer device, computer-readable storage medium, and computer program product. First, a creation request for a consistent snapshot sent by a client is received; the creation request carries consistent snapshot group information and creation request parameters. Second, a target storage backend is determined according to the creation request parameters. Third, the first target driver layer is called through the general interface layer to execute a creation operation according to the creation request parameters and the consistent snapshot group information; the first target driver layer is the driver layer corresponding to the target storage backend. Finally, in the case where the creation operation is successful, the first consistent snapshot group data obtained by the creation is serialized to obtain a first serialization result, and the first serialization result is returned to the client. Since the general interface layer encapsulates the driver layer corresponding to each storage backend; the server can use the driver layer corresponding to any storage backend as the first target driver layer through the general interface layer to create a creation request for a consistent snapshot; and serialize the first consistent snapshot group data after the creation to obtain a first serialization result and return it to the client. Even in the face of different brands and types of storage backends, creation management can be performed according to the snapshot creation method, thereby improving the generality of the snapshot management method and solving the problem that different brands and types of storage backends have different management of consistent snapshots. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] To more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments of the present application or related technologies. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other related drawings can be obtained based on these drawings without creative efforts.

[0038] Figure 1 It is a schematic flowchart of a snapshot management method in an embodiment;

[0039] Figure 2 It is an architecture diagram of a server in an embodiment;

[0040] Figure 3 It is a schematic flowchart of a process of executing a creation operation in an embodiment;

[0041] Figure 4 It is a structural block diagram of a general interface layer in an embodiment;

[0042] Figure 5 It is a schematic flowchart of a snapshot cloning method in an embodiment;

[0043] Figure 6 It is a schematic flowchart of a snapshot creation method in an embodiment;

[0044] Figure 7Schematic flowchart of the snapshot cloning method in another embodiment;

[0045] Figure 8 Block diagram of the snapshot management device in one embodiment;

[0046] Figure 9 Internal structure diagram of a computer device in one embodiment. Detailed implementation manners

[0047] In order to make the objectives, technical solutions and advantages of the present application clearer and more understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0048] In one embodiment, as Figure 1 shown, a snapshot management method is provided. In this embodiment, it is exemplified that the method is applied to a terminal. It can be understood that the method can also be applied to a server. In this embodiment, the method includes the following steps S102 to S108:

[0049] Step S102, receiving a creation request for a consistent snapshot sent by a client.

[0050] Among them, a consistent snapshot refers to the state of a system or data set being completely and consistently recorded at a specific point in time. It ensures that all relevant data is in a consistent state when the snapshot is created, and there will be no partially updated or unfinished transactions. The creation request carries consistent snapshot group information and creation request parameters. The consistent snapshot group information includes volume identifiers, such as volume ID, volume name (name), and other information.

[0051] Optionally, the client sends a creation request for a consistent snapshot to the server. The server receives the creation request for the consistent snapshot sent by the client, the server parses the creation request for the consistent snapshot, and checks whether the creation request is valid. If the creation request is invalid, an error is directly returned. If the creation request is valid, the consistent snapshot information is written into the DB database, and at the same time, the consistent snapshot status is set to creating, and the creation continues.

[0052] Step S104, determining a target storage backend according to the creation request parameters.

[0053] Among them, the creation request parameters refer to the data or configuration options passed by the client to the server when sending a request to the server. These parameters are used to specify the specific content of the request, filtering conditions, operation types, etc. For example, the creation request parameters are used to determine a target storage backend from multiple storage backends.

[0054] Optionally, the server determines a target storage backend from multiple storage backends according to the creation request parameters, where the types or categories of the multiple storage backends are different, such as RBD (RADOS Block Device) block storage, iSCSI (Internet Small Computer System Interface) block storage, PC (Personal Computer) block storage, etc.

[0055] Step S106, call the first target driver layer through the general interface layer to perform a creation operation according to the creation request parameters and the consistency snapshot group information.

[0056] Among them, the general interface layer encapsulates the driver layer corresponding to each storage backend; the first target driver layer is the driver layer corresponding to the target storage backend. For example, the RBD block storage backend corresponds to a driver layer; the iSCSI block storage backend corresponds to a driver layer; the PC block storage backend corresponds to a driver layer.

[0057] Optionally, the server pre-encapsulates the call interfaces of the driver layers corresponding to each storage backend in the general interface layer, so as to subsequently call the driver layers through the call interfaces of the respective driver layers encapsulated in the general interface layer. The server selects one from multiple driver layers as the first target driver layer through the general interface layer, and performs the creation operation of the consistency snapshot according to the consistency snapshot group information read from the database through the first target driver layer.

[0058] Step S108, in the case where the creation operation is successful, serialize the created first consistency snapshot group data to obtain a first serialization result, and return the first serialization result to the client.

[0059] Optionally, in the case where the consistency snapshot creation operation is successful, obtain the first consistency snapshot group data, and change the consistency snapshot status to available; the interface layer is also used to confirm the storage backend capacity consumed by creating the consistency snapshot. The server serializes the created first consistency snapshot group data to obtain a first serialization result. And return the first serialization result to the client. In the case where the consistency snapshot creation operation fails, the consistency snapshot status is changed to error and an error is returned.

[0060] In the above snapshot management method, first, a creation request for a consistent snapshot sent by a client is received; the creation request carries consistent snapshot group information and creation request parameters; second, a target storage backend is determined according to the creation request parameters; third, the first target driver layer is called through the general interface layer to execute a creation operation according to the creation request parameters and the consistent snapshot group information; the first target driver layer is the driver layer corresponding to the target storage backend; finally, in the case where the creation operation is successful, the first consistent snapshot group data obtained by creation is serialized to obtain a first serialization result, and the first serialization result is returned to the client. Since the general interface layer encapsulates the driver layer corresponding to each storage backend, the server can, through the general interface layer, use the driver layer corresponding to any storage backend as the first target driver layer to create a creation request for a consistent snapshot, serialize the first consistent snapshot group data after creation to obtain a first serialization result, and return it to the client. Even in the face of different brands and types of storage backends, creation management can be performed according to the snapshot creation method, thereby improving the generality of the snapshot management method and solving the problem that different brands and types of storage backends have different management of consistent snapshots.

[0061] In an exemplary embodiment, receiving a creation request for a consistent snapshot sent by a client includes: receiving a creation request for a consistent snapshot sent by a client through a control layer; determining a target storage backend according to the creation request parameters includes: calling a scheduler through the control layer to determine a storage backend from a database as the target storage backend according to the creation request parameters; a mapping relationship between the creation request parameters and the storage backend is stored in the database.

[0062] As Figure 2 shown, the server architecture includes components such as a control layer (controller), a scheduler (scheduler), a general interface layer, a volume service (volume), a driver layer (driver), and a database DB.

[0063] Among them, the Controller is responsible for receiving external requests and providing a unified entry function for call methods such as SDK, client, and http. The SDK (Software Development Kit) is generally a collection of development tools for software engineers to build application software for specific software packages, software frameworks, hardware platforms, operating systems, etc. The Client (client), as the consistent snapshot control management method and system as the server side, can directly communicate with the server side, facilitating developers to perform operation and maintenance operations.

[0064] The Scheduler is responsible for scheduling the creation of a consistent snapshot, selecting an appropriate volume service and driver to execute the creation process. However, if an external request specifies a certain storage backend to create a consistent snapshot, the controller layer will skip the Scheduler and directly call the general interface layer.

[0065] The general interface layer encapsulates the calls to all driver interfaces and also writes the allocated consistent group data to the DB.

[0066] The Volume is mainly responsible for controlling the execution of the driver and adopts a method of running multiple services simultaneously, such as Docker. Each Volume service has an independent configuration file, which can facilitate the deployment and operation and maintenance operations.

[0067] The Driver layer is the last layer to access the storage backend, providing atomic functional interfaces, and the driver and the volume service are deployed in the same container.

[0068] The DB database provides the ability of data persistent storage for the controller, scheduler and volume, and adopts a cluster deployment method.

[0069] The database stores the mapping relationship between the creation request parameters and the storage backend.

[0070] Optionally, the server receives a creation request for a consistent snapshot sent by the client Client or the software development kit SDK through the control layer Controller. In the case that the creation request parameters do not include the target storage backend parameters, the control layer Controller calls the scheduler Scheduler to select a suitable storage backend from the database DB according to the creation request parameters as the target storage backend, such as the RBD block storage, and allocates it to the corresponding volume service volume of the RBD block storage through the function of the general interface layer to execute the creation operation; if the scheduler cannot find a storage backend that can be created, it will change the status of the consistent snapshot to error and return an error by the controller.

[0071] In this embodiment, by calling the scheduler through the control layer to determine the target storage backend, the creation operation of the consistent snapshot can be realized.

[0072] In an exemplary embodiment, determining the target storage backend according to the creation request parameters includes: in the case that the creation request parameters include the target storage backend parameters, determining the target storage backend from the database according to the target storage backend parameters through the control layer.

[0073] Among them, the mapping relationship between the target storage backend parameters and the target storage backend is stored in the database.

[0074] Optionally, when the target storage backend parameters are included in the creation request parameters, that is, there are special settings in the creation request to specify the parameters of the storage backend, the control layer controller will retrieve all storage backends from the database DB, and then determine the call interface of the target storage backend encapsulated in the general interface layer according to the mapping relationship between the target storage backend parameters and the target storage backend, and allocate it to the volume service for execution through the function of the general interface layer.

[0075] In this embodiment, the general interface layer directly determines the storage backend according to the target storage backend parameters to perform the creation operation.

[0076] In an exemplary embodiment, as Figure 3 shown, the general interface layer is used to call the first target driver layer to perform the creation operation according to the creation request parameters and the consistency snapshot group information, including steps S302 to S304. Among them:

[0077] Step S302, the general interface layer performs a heartbeat check on the target volume service. When the target volume service passes the heartbeat check, the general interface layer calls the target volume service.

[0078] Among them, the target volume service is the volume service corresponding to the target storage backend, and the storage backend and the volume service are in one-to-one correspondence.

[0079] The general interface layer architecture is as Figure 4 shown. It includes capabilities such as heartbeat management, message sending, capacity calculation, QoS quota setting, and driver adaptation. Among them, QoS (Quality of Service) quota setting is to set specifications for resources such as storage backends to limit their read and write capabilities.

[0080] The heartbeat management module is used to maintain the heartbeat state of the volume service and can obtain the running state of the volume service in a timely manner.

[0081] The message sending and receiving module is responsible for sending and receiving message requests from the controller, scheduler, volume, etc.

[0082] The capacity calculation module can calculate the storage backend capacity consumed by resources such as volumes and snapshots, and can count data information for each storage backend.

[0083] The Qos quota module is to limit the data read and write capabilities of resources such as volumes to prevent a single volume from unlimited reading and writing, which may affect the entire storage system.

[0084] The Driver adaptation module performs code adaptation for all supported storage backends and cooperates with the volume service to provide a set of abstract interfaces for other components to call.

[0085] Optionally, the storage backend and the volume service correspond one by one. The server performs a heartbeat check on the target volume service through the general interface layer. When the target volume service passes the heartbeat check, the target volume service is called through the general interface layer. Among them, the target volume service is the volume service corresponding to the target storage backend. While the server calls the target volume service through the general interface layer, the general interface calculates the capacities of multiple volumes in the consistency snapshot group and estimates the capacity of the storage backend consumed each time a creation is made. For example, if the total capacity of a certain storage backend is 100G and the used amount is 80G, then an error will definitely occur when creating a 40G volume. Therefore, it is necessary to calculate in advance during the creation process that the capacity is insufficient and prohibit the creation.

[0086] In the case where the target volume service fails the heartbeat check, it indicates that the volume service volume is abnormal and an error is returned.

[0087] Step S304, call the first target driver layer through the target volume service to perform a creation operation according to the creation request parameters and the consistency snapshot group information.

[0088] Among them, the first target driver layer is the driver layer corresponding to the target volume service and the target storage backend.

[0089] Optionally, the server calls the first target driver layer through the target volume service to perform a creation operation according to the creation request parameters and the consistency snapshot group information.

[0090] In this embodiment, the first driver layer is called through the general interface layer to create a consistency snapshot, thereby realizing flexible management of the consistency snapshot.

[0091] In an exemplary embodiment, as Figure 5 shown, a snapshot cloning method in snapshot management is provided, including the following steps S502 to step S512. Among them:

[0092] Step S502, receive a cloning request for a consistency snapshot sent by the client.

[0093] Optionally, the server receives a cloning request for a consistency snapshot sent by the client through the control layer controller. The control layer verifies whether the cloning request is valid. If the cloning request is valid, the subsequent cloning operation is performed. If the cloning request is invalid, an error is returned.

[0094] Step S504, according to the cloning request, obtain the second consistency snapshot group data and obtain the total snapshot data amount of the second consistency snapshot group data.

[0095] Among them, the second consistent snapshot group data can be the same as the first consistent snapshot group data or different from the first consistent snapshot group data.

[0096] Optionally, when the clone request is valid, the server parses the clone request of the consistent snapshot through the control layer (controller) to obtain the consistent snapshot ID. The control layer (controller) needs to obtain the second consistent snapshot group data according to the consistent snapshot ID and calculate the total data volume of all volumes according to the second consistent snapshot group data.

[0097] Step S506: Obtain the consistency group corresponding to the storage of the second consistent snapshot group data.

[0098] Among them, when multiple volumes (or disks) are combined into a group, it becomes a consistency group. The consistency group includes multiple source volumes; the source volume is the volume storing the second consistent snapshot group data.

[0099] Optionally, the server obtains multiple source volumes in the consistency group corresponding to the storage of the second consistent snapshot group data, writes the consistency group into the database, and sets the status of the consistency group to creating.

[0100] Step S508: Calculate the capacity of each source volume through the general interface layer and determine the total source volume capacity according to the capacity of each source volume.

[0101] Optionally, the server calculates the capacity of each source volume through the interface layer. For example, the capacity of source volume 1 is 40GB. And determine the total source volume capacity according to the capacity of each source volume. Since the capacity of the source volume at the time of taking the snapshot will be recorded, and the capacity of the source volume will change, such as expansion, it is necessary to determine whether the total snapshot data volume is the same as the total source volume capacity. If the total snapshot data volume is the same as the total source volume capacity, the cloning operation continues. If the total snapshot data volume is different from the total source volume capacity, it indicates that an unexpected error will occur, and an error is returned.

[0102] Step S510: When the total snapshot data volume is the same as the total source volume capacity, call the second target driver layer through the general interface layer to perform a cloning operation on the consistency group.

[0103] Among them, the second target driver layer can be the same as the first target driver layer or different from the first target driver layer.

[0104] Optionally, when the total amount of snapshot data is the same as the total capacity of the source volume, the server calls the volume service volume through the general interface layer to call the second target driver layer driver to perform the cloning operation. The volume service Volume will synchronously wait for the driver to complete the execution. If the cloning fails, the status of the consistency group will be changed to error and an error will be returned. If the driver is successfully created, the volume service will change the status of the consistency group to available. The general interface layer will confirm the actual capacity consumed by the consistent snapshot cloning and write it into the database DB. Writing the actual capacity obtained by cloning into the database DB is for other components to obtain, avoiding repeated capacity calculations each time. At the same time, qos quotas will also be set for each newly created volume.

[0105] Step S512, when the cloning operation is successful, serialize the newly created volume obtained by cloning to obtain a second serialization result, and return the second serialization result to the client.

[0106] Among them, the new volume is obtained based on the storage backend.

[0107] Optionally, when the cloning operation is successful, the server serializes the newly created volume obtained by cloning through the control layer Controller to obtain a second serialization result, and the server serializes the result through the control layer Controller and returns success. Among them, the new volume is obtained based on the storage backend.

[0108] In this embodiment, the consistent snapshot is cloned through the cloning request for the consistent snapshot, and the general interface layer pre-judges whether the data of the consistent snapshot to be cloned is the same as the capacity of the source volume to ensure that cloning can be performed.

[0109] In an exemplary embodiment, the consistent snapshot cloning method includes: setting the new volume as a volume with a target read / write specification through the general interface layer.

[0110] Optionally, as Figure 4 shown, the general interface layer further includes a qos quota module. The server general interface layer will confirm the actual capacity consumed by the consistent snapshot cloning and write it into the DB. At the same time, qos quotas will also be set for each newly created volume, and each new volume will be configured as a volume with a target read / write rule, so as to achieve the purpose of restricting the read / write ability of the volume.

[0111] In this embodiment, through the general interface layer, the read / write ability of each newly created volume obtained by cloning can be restricted.

[0112] In an exemplary embodiment, the method for creating a consistent snapshot in the snapshot management method, as Figure 6As shown in the figure. The client sends a creation request for a consistent snapshot to the server. The server receives the creation request for the consistent snapshot sent by the client, parses the creation request for the consistent snapshot, and checks whether the creation request is valid. If the creation request is invalid, an error is directly returned. If the creation request is valid, the consistent snapshot information is written into the DB database, and at the same time, the consistent snapshot status is set to creating, and the creation continues. The creation request carries consistent snapshot group information and creation request parameters. The consistent snapshot group information includes volume identifiers, such as volume ID, volume name (name), and other information. The creation request parameters are used to determine a target storage backend from multiple storage backends.

[0113] In the case where the target storage backend parameter is not included in the creation request parameters, the control layer Controller calls the scheduler Scheduler to select a volume service corresponding to a suitable storage backend from the database DB according to the creation request parameters, such as the volume service corresponding to the RBD block storage, and assigns it to the volume service corresponding to the RBD block storage through the function of the general interface layer to perform the creation operation; if the scheduler cannot find a storage backend that can be created, the consistent snapshot status will be changed to error and an error will be returned by the controller. The mapping relationship between the creation request parameters and the storage backend is stored in the database.

[0114] In the case where the target storage backend parameter is included in the creation request parameters, that is, there is a special setting in the creation request to specify the storage backend parameter, the control layer controller will retrieve all storage backends from the database DB, and then determine the call interface of the target storage backend encapsulated in the general interface layer according to the mapping relationship between the target storage backend parameter and the target storage backend, and assign it to the volume service through the function of the general interface layer to execute. Among them, the mapping relationship between the target storage backend parameter and the target storage backend is stored in the database.

[0115] The server performs a heartbeat check on the target volume service through the general interface layer. In the case where the target volume service passes the heartbeat check, the target volume service is called through the general interface layer. Among them, the target volume service is the volume service corresponding to the target storage backend. While the server calls the target volume service through the general interface layer, the general interface calculates the capacities of multiple volumes in the consistent snapshot group and estimates the storage backend capacity consumed by each creation. For example, if the total capacity of a certain storage backend is 100G and the used amount is 80G, then an error will definitely occur when creating a 40G volume. Therefore, it is necessary to calculate in advance that the capacity is insufficient and prohibit the creation during the creation process. In the case where the target volume service fails to pass the heartbeat check, it indicates that the volume service volume is abnormal and an error is returned. The server calls the first target driver layer through the target volume service to perform the creation operation according to the creation request parameters and the consistent snapshot group information.

[0116] In the case where the consistency snapshot creation operation is successful, the first consistency snapshot group data is obtained, and the consistency snapshot status is changed to available; through the interface layer, it is also used to confirm the storage backend capacity consumed for creating the consistency snapshot. The server serializes the obtained first consistency snapshot group data to obtain a first serialization result. And the first serialization result is returned to the client. In the case where the consistency snapshot creation operation fails, the consistency snapshot status is changed to error and an error is returned.

[0117] The consistency snapshot cloning method in the snapshot management method, as Figure 7 shown. The server receives a cloning request for a consistency snapshot sent by the client through the control layer controller. The cloning request is verified for validity through the control layer. If the cloning request is valid, subsequent cloning operations are performed. If the cloning request is invalid, an error is returned.

[0118] In the case where the cloning request is valid, the server parses the cloning request for the consistency snapshot through the control layer controller to obtain the consistency snapshot ID. The control layer controller needs to obtain the second consistency snapshot group data according to the consistency snapshot ID, and calculate the total data volume of all volumes according to the second consistency snapshot group data. Among them, the second consistency snapshot group data can be the same as the first consistency snapshot group data, or different from the first consistency snapshot group data.

[0119] The server obtains multiple source volumes in the consistency group corresponding to the storage of the second consistency snapshot group data, and writes the consistency group into the database, and the status of the consistency group is set to creating. The server calculates the capacity of each source volume through the interface layer, such as the capacity of source volume 1 is 40GB. And the total source volume capacity is determined according to the capacity of each source volume. Since the capacity of the source volume at that time is recorded when the volume takes a snapshot, and the capacity of the source volume will change, such as expansion, it is necessary to determine whether the snapshot data total volume is the same as the total source volume capacity. If the snapshot data total volume is the same as the total source volume capacity, the cloning operation continues. If the snapshot data total volume is different from the total source volume capacity, indicating that it will cause unpredictable errors, an error is returned.

[0120] When the total amount of snapshot data is the same as the total capacity of the source volume, the server invokes the volume service volume through the general interface layer to call the second target driver layer driver to perform the cloning operation. The volume service Volume will synchronously wait for the driver to complete the execution. If the cloning fails, the status of the consistency group will be changed to error and an error will be returned. If the driver is successfully created, the volume service will change the status of the consistency group to available. The general interface layer will confirm the actual capacity consumed by the consistent snapshot cloning and write it into the database DB. Writing the actual capacity obtained by cloning into the database DB is for other components to obtain, avoiding repeated calculation of the capacity every time. The general interface layer also includes a QoS quota module. The server general interface layer will confirm the actual capacity consumed by the consistent snapshot cloning and write it into the DB. At the same time, it will also set QoS quotas for each newly created volume, configuring each new volume as a volume with target read and write rules, so as to achieve the purpose of restricting the read and write capabilities of the volume.

[0121] In the case of successful cloning operation, the server serializes the newly created volume obtained by cloning through the control layer Controller to obtain the second serialization result, and the server serializes the result through the control layer Controller and returns success. Among them, the new volume is obtained based on the storage backend.

[0122] It should be understood that although the steps in the flowcharts involved in the above-described embodiments are sequentially shown according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-described embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or alternately with at least a part of other steps or steps in other steps.

[0123] Based on the same inventive concept, the embodiments of the present application also provide a snapshot management device for implementing the snapshot management method involved above. The solution provided by this device to solve the problem is similar to the solution described in the above method. Therefore, the specific limitations in one or more of the following snapshot management device embodiments can refer to the limitations on the snapshot management method in the above text and will not be repeated here.

[0124] In an exemplary embodiment, as Figure 8As shown in the figure, a snapshot management device is provided, including: a receiving module 801, a storage backend determination module 802, a creation module 803, and a serialization module 804, where:

[0125] The receiving module 801 is configured to receive a creation request for a consistent snapshot sent by a client; the creation request carries consistent snapshot group information and creation request parameters.

[0126] The storage backend determination module 802 is configured to determine a target storage backend according to the creation request parameters.

[0127] The creation module 803 is configured to call a first target driver layer through a general interface layer to perform a creation operation according to the creation request parameters and the consistent snapshot group information; the general interface layer encapsulates the driver layer corresponding to each storage backend; the first target driver layer is the driver layer corresponding to the target storage backend.

[0128] The serialization module 804 is configured to, when the creation operation is successful, serialize the created first consistent snapshot group data to obtain a first serialization result, and return the first serialization result to the client.

[0129] In an exemplary embodiment, the receiving module 801 is further configured to receive a creation request for a consistent snapshot sent by the client through a control layer; the creation module 803 is further configured to call a scheduler through the control layer to determine a storage backend from a database as the target storage backend according to the creation request parameters; a mapping relationship between the creation request parameters and the storage backend is stored in the database.

[0130] In an exemplary embodiment, the creation module 803 is further configured to, when the creation request parameters include target storage backend parameters, determine the target storage backend from the database through the control layer according to the target storage backend parameters; wherein, a mapping relationship between the target storage backend parameters and the target storage backend is stored in the database.

[0131] In an exemplary embodiment, the creation module 803 is further configured to perform a heartbeat check on a target volume service through the general interface layer, and when the target volume service passes the heartbeat check, call the target volume service through the general interface layer, where the target volume service is the volume service corresponding to the target storage backend, and there is a one-to-one correspondence between the storage backend and the volume service; call the first target driver layer through the target volume service to perform a creation operation according to the creation request parameters and the consistent snapshot group information, and the first target driver layer corresponds to the target volume service.

[0132] In an exemplary embodiment, the snapshot management device further includes a snapshot cloning module, configured to receive a cloning request for a consistent snapshot sent by a client; obtain second consistent snapshot group data according to the cloning request, and obtain the total amount of snapshot data of the second consistent snapshot group data; obtain the consistent group corresponding to the storage of the second consistent snapshot group data, where the consistent group includes a plurality of source volumes; the source volume is the volume storing the second consistent snapshot group data; calculate the capacity of each source volume through the general interface layer, and determine the total source volume capacity according to the capacity of each source volume; when the total amount of snapshot data is the same as the total source volume capacity, call the second target driver layer through the general interface layer to perform a cloning operation on the consistent group; when the cloning operation is successful, serialize the cloned new volume to obtain a second serialization result, and return the second serialization result to the client, where the new volume is obtained based on the storage backend.

[0133] In an exemplary embodiment, the snapshot cloning module is further configured to set the new volume as a volume with a target read / write specification through the general interface layer.

[0134] Each module in the above snapshot management device can be implemented in whole or in part by software, hardware, and their combination. The above modules can be embedded in the processor in the computer device in the form of hardware or be independent of the processor, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the operations corresponding to the above modules.

[0135] In an exemplary embodiment, a computer device is provided. The computer device can be a server, and its internal structure diagram can be as Figure 9 shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, abbreviated as I / O), and a communication interface. Among them, the processor, the memory, and the input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store consistent snapshot data. The input / output interface of the computer device is used to exchange information between the processor and external devices. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it implements a snapshot management method.

[0136] Those skilled in the art can understand that Figure 9The structure shown is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0137] In one embodiment, a computer device is further provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.

[0138] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0139] In one embodiment, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0140] Those of ordinary skill in the art can understand that all or part of the processes in the above-described embodiment methods can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in this application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in this application can be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, data processing logics based on quantum computing, artificial intelligence (AI) processors, etc., without limitation.

[0141] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this application.

[0142] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all fall within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the appended claims.

Claims

1. A snapshot management method, characterized in that, Applied to a server, the method includes: Receiving a creation request for a consistent snapshot sent by a client; the creation request carries consistent snapshot group information and creation request parameters; Determining a target storage backend according to the creation request parameters; Invoking a first target driver layer through a general interface layer to perform a creation operation according to the creation request parameters and the consistent snapshot group information; the general interface layer encapsulates the driver layer corresponding to each storage backend; the first target driver layer is the driver layer corresponding to the target storage backend; In the case where the creation operation is successful, serializing the created first consistent snapshot group data to obtain a first serialization result, and returning the first serialization result to the client.

2. The method according to claim 1, characterized in that The receiving a creation request for a consistent snapshot sent by a client includes: Receiving the creation request for a consistent snapshot sent by the client through a control layer; The determining a target storage backend according to the creation request parameters includes: Invoking a scheduler through the control layer to determine a storage backend from a database as the target storage backend according to the creation request parameters; the mapping relationship between the creation request parameters and the storage backend is stored in the database.

3. The method according to claim 1, wherein The determining a target storage backend according to the creation request parameters includes: In the case where the creation request parameters include target storage backend parameters, determining the target storage backend from the database through the control layer according to the target storage backend parameters; wherein, the mapping relationship between the target storage backend parameters and the target storage backend is stored in the database.

4. The method according to claim 1, wherein The invoking a first target driver layer through the general interface layer to perform a creation operation according to the creation request parameters and the consistent snapshot group information includes: Performing a heartbeat check on a target volume service through the general interface layer; in the case where the target volume service passes the heartbeat check, invoking the target volume service through the general interface layer, the target volume service is the volume service corresponding to the target storage backend, and there is a one-to-one correspondence between the storage backend and the volume service; Invoking the first target driver layer through the target volume service to perform a creation operation according to the creation request parameters and the consistent snapshot group information, and the first target driver layer corresponds to the target volume service.

5. The method according to claim 1, wherein The method further includes: Receiving a clone request for a consistent snapshot sent by the client; Obtaining second consistent snapshot group data according to the clone request, and obtaining the total amount of snapshot data of the second consistent snapshot group data; Obtaining the consistent group corresponding to the storage of the second consistent snapshot group data, wherein the consistent group includes multiple source volumes; the source volume is the volume storing the second consistent snapshot group data; Calculating the capacity of each source volume through the general interface layer, and determining the total source volume capacity according to the capacity of each source volume; In the case where the total amount of snapshot data is the same as the total source volume capacity, invoking a second target driver layer through the general interface layer to perform a clone operation on the consistent group; In the case where the cloning operation is successful, serialize the newly cloned volume to obtain a second serialization result, and return the second serialization result to the client, where the new volume is based on the storage backend.

6. The method according to claim 5, wherein The method includes: Set the new volume to a volume with a target read / write specification through the general interface layer.

7. A snapshot management device, characterized in that, The device includes: A receiving module, configured to receive a creation request for a consistent snapshot sent by a client; the creation request carries consistent snapshot group information and creation request parameters; A storage backend determination module, configured to determine a target storage backend according to the creation request parameters; A creation module, configured to call a first target driver layer through the general interface layer to perform a creation operation according to the creation request parameters and the consistent snapshot group information; the general interface layer encapsulates the driver layer corresponding to each storage backend; the first target driver layer is the driver layer corresponding to the target storage backend; A serialization module, configured to serialize the first consistent snapshot group data obtained by the creation to obtain a first serialization result, and return the first serialization result to the client in the case where the creation operation is successful.

8. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images