Service Cluster Instance Backup and Recovery Methods and Related Devices

This application is a continuation of U.S. application Ser. No. 18/588,833 filed on Feb. 27, 2024; U.S. application Ser. No. 18/588,833 is a continuation application of PCT Patent Application No. PCT/CN2023/117413, filed on Sep. 7, 2023, which claims priority to Chinese Patent Application No. 2022112478396, entitled “SERVICE CLUSTER INSTANCE BACKUP AND RECOVERY METHODS AND RELATED DEVICES” filed with the China National Intellectual Property Administration on Oct. 12, 2022, all of which are incorporated by reference in their entirety.

The present disclosure relates to the field of computer technologies, and specifically to service cluster instance backup and recovery technologies.

Kubernetes is an open source container orchestration engine, which supports automated deployment, large scalability, and application container management. A Kubernetes cluster may include at least one container group, and an application instance may be operated in the container group. To ensure persistence, recoverability, and high availability of data storage, disaster recovery backup should be achieved to a certain extent for data in a Kubernetes cluster.

Currently, the entire backup of a service cluster instance in a database is not available, the backup efficiency is low, and rapid backup of the service cluster instance is not realized.

Embodiments of the present disclosure provide service cluster instance backup and recovery methods and related devices. The related devices may include service cluster instance backup and recovery apparatuses, an electronic device, a computer-readable storage medium, and a computer program product, which may back up the entire service cluster instance, thereby improving the backup efficiency of the service cluster instance, and facilitating rapid backup of the service cluster instance.

This embodiment of the present disclosure provides a service cluster instance backup method, performed by an electronic device. The method includes: determining a service cluster instance to be backed up, the service cluster instance including at least one container group; for one container group in the service cluster instance: setting, for the container group, a source persistent volume claim and a source persistent volume object corresponding to the container group, and storing the container group based on the source persistent volume object, the source persistent volume claim being configured to claim storage attribute information required by the container group, and the source persistent volume object pointing to a data storage area of the container group; creating, for the container group, a backup persistent volume claim and a backup persistent volume object corresponding to the container group according to the source persistent volume claim and the source persistent volume object corresponding to the container group when the service cluster instance satisfies a backup triggering condition; acquiring, for the container group, target data of the container group to be backed up based on the source persistent volume object corresponding to the container group; and backing up, for the container group, the target data of the container group to a storage area pointed by the backup persistent volume object corresponding to the container group according to the backup persistent volume claim corresponding to the container group.

This embodiment of the present disclosure provides a service cluster instance recovery method, performed by an electronic device. The method includes: acquiring, when an instance recovery request for a service cluster instance is received, backup data of a container group in the service cluster instance; creating a target backup persistent volume claim and a target backup persistent volume object corresponding to the container group according to the backup data of the container group, the target backup persistent volume claim being configured to claim storage attribute information required by the container group, and the target backup persistent volume object pointing to a storage area for the backup data of the container group; creating a target persistent volume claim and a target persistent volume object corresponding to the container group according to the target backup persistent volume claim and the target backup persistent volume object corresponding to the container group; and operating the container group according to the target persistent volume claim and the target persistent volume object corresponding to the container group.

Correspondingly, this embodiment of the present disclosure provides a service cluster instance backup apparatus, including: a determination unit, configured to determine a to-be-backed-up service cluster instance, the service cluster instance including at least one container group; a storage unit, configured to set, for each container group, a source persistent volume claim and a source persistent volume object corresponding to the container group, and store the container group based on the source persistent volume object, the source persistent volume claim being configured to claim storage attribute information required by the container group, and the source persistent volume object pointing to a data storage area of the container group; a first creation unit, configured to create, for each container group, a backup persistent volume claim and a backup persistent volume object corresponding to the container group according to the source persistent volume claim and the source persistent volume object corresponding to the container group when the service cluster instance satisfies a backup triggering condition; a first acquisition unit, configured to acquire, for each container group, to-be-backed-up data of the container group based on the source persistent volume object corresponding to the container group; and a backup unit, configured to back up, for each container group, the to-be-backed-up data of the container group to a storage area pointed by the backup persistent volume object corresponding to the container group according to the backup persistent volume claim corresponding to the container group.

Correspondingly, this embodiment of the present disclosure provides a service cluster instance recovery apparatus, including: a second acquisition unit, configured to acquire, when an instance recovery request for a service cluster instance is received, backup data of each container group in the service cluster instance; a second creation unit, configured to create, for each container group, a target backup persistent volume claim and a target backup persistent volume object corresponding to the container group according to the backup data of the container group, the target backup persistent volume claim being configured to claim storage attribute information required by the container group, and the target backup persistent volume object pointing to a storage area for the backup data of the container group; a third creation unit, configured to create, for each container group, a target persistent volume claim and a target persistent volume object corresponding to the container group according to the target backup persistent volume claim and the target backup persistent volume object corresponding to the container group; and an operation unit, configured to operate the container group according to the target persistent volume claim and the target persistent volume object corresponding to the container group.

This embodiment of the present disclosure provides an electronic device, including a processor and a memory. The memory stores a plurality of instructions, and the processor loads the instructions to perform the steps of the service cluster instance backup and recovery methods provided by this embodiment of the present disclosure.

This embodiment of the present disclosure further provides a computer-readable storage medium on which a computer program is stored. The computer program, when executed by a processor, implements the steps of the service cluster instance backup and recovery methods provided by this embodiment of the present disclosure.

This embodiment of the present disclosure further provides a non-transitory computer storage medium, including computer programs or instructions. The computer programs or instructions, when executed by a processor, implement the steps of the service cluster instance backup and recovery methods provided by this embodiment of the present disclosure.

This embodiment of the present disclosure provides service cluster instance backup and recovery methods and related devices. A to-be-backed-up service cluster instance may be determined, where the service cluster instance includes at least one container group. For each container group, a source persistent volume claim and a source persistent volume object corresponding to the container group are set, and the container group is stored based on the source persistent volume object, where the source persistent volume claim is configured to claim storage attribute information required by the container group, and the source persistent volume object points to a data storage area of the container group. When the service cluster instance satisfies a backup triggering condition, for each container group, a backup persistent volume claim and a backup persistent volume object corresponding to the container group are created according to the source persistent volume claim and the source persistent volume object corresponding to the container group. For each container group, to-be-backed-up data of the container group is acquired based on the source persistent volume object corresponding to the container group. For each container group, the to-be-backed-up data of the container group is backed up to a storage area pointed by the backup persistent volume object corresponding to the container group according to the backup persistent volume claim corresponding to the container group, so as to realize data backup of each container group in the service cluster instance. According to the present disclosure, through the foregoing manner, when a service cluster instance is backed up, a corresponding backup persistent volume claim and backup persistent volume object are created for each container group, and to-be-backed-up data of the container group is acquired from a source persistent volume object corresponding to the container group. Then, the to-be-backed-up data of the container group is backed up to a storage area pointing to the backup persistent volume object according to the backup persistent volume claim. In this way, data backup of each container group in the service cluster instance is realized, whereby the entire service cluster instance is backed up, thereby improving the backup efficiency of the service cluster instance, and facilitating rapid backup of the service cluster instance.

The technical solutions in embodiments of the present disclosure are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present disclosure. Apparently, the described embodiments are merely some rather than all of the embodiments of the present disclosure. All other embodiments obtained by a person skilled in the art based on the embodiments of the present disclosure without creative efforts shall fall within the protection scope of the present disclosure.

This embodiment of the present disclosure provides service cluster instance backup and recovery methods and related devices. The related devices may include service cluster instance backup and recovery apparatuses, an electronic device, a computer-readable storage medium, and a computer program product.

Specifically, this embodiment of the present disclosure provides a service cluster instance backup apparatus suitable for a first electronic device. The first electronic device may be a server or another device. This embodiment of the present disclosure further provides a service cluster instance recovery apparatus suitable for a second electronic device. The second electronic device may be a server or another device.

As shown in, the service cluster instance backup and recovery methods are, for example, performed cooperatively by a terminal and a server. A service cluster instance backup and recovery system provided by this embodiment of the present disclosure includes a terminal, a server, and the like. The terminalis connected to the serverthrough a network, for example, a wired or wireless network. The service cluster instance backup and recovery apparatuses may be integrated in the server.

In one embodiment, the servermay be configured to: determine a to-be-backed-up service cluster instance, where the service cluster instance includes at least one container group; set, for each container group, a source persistent volume claim and a source persistent volume object corresponding to the container group, and store the container group based on the source persistent volume object, where the source persistent volume claim is configured to claim storage attribute information required by the container group, and the source persistent volume object points to a data storage area of the container group; create, for each container group, a backup persistent volume claim and a backup persistent volume object corresponding to the container group according to the source persistent volume claim and the source persistent volume object corresponding to the container group when the service cluster instance satisfies a backup triggering condition; acquire, for each container group, to-be-backed-up data of the container group based on the source persistent volume object corresponding to the container group; and back up, for each container group, the to-be-backed-up data of the container group to a storage area pointed by the backup persistent volume object corresponding to the container group according to the backup persistent volume claim corresponding to the container group, thus realizing data backup of each container group in the service cluster instance.

The servermay be an independent physical server, a server cluster or a distributed system composed of a plurality of physical servers, or a cloud server providing basic cloud computing services, such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a network service, cloud communication, a middleware service, a domain name service, a security service, a content delivery network (CDN), and big data and artificial intelligence platforms. The service cluster instance backup and recovery methods or apparatuses disclosed in the present disclosure may be applied to a plurality of servers. The plurality of servers may form a blockchain, and the servers are nodes on the blockchain.

The terminalmay be configured to transmit a data backup instruction for the service cluster instance to the server, whereby the serverrealizes data backup of each container group in the service cluster instance based on the data backup instruction. The terminalmay include a mobile phone, an intelligent voice interaction device, a smart home appliance, a vehicle terminal, an aircraft, a tablet computer, a laptop, or a personal computer (PC), and the like. The terminalmay be further provided with a client. The client may be an application client, a browser client, or the like.

In another embodiment, the servermay be configured to: acquire, when an instance recovery request for a service cluster instance is received, backup data of each container group in the service cluster instance; create, for each container group, a target backup persistent volume claim and a target backup persistent volume object corresponding to the container group according to the backup data of the container group, where the target backup persistent volume claim is configured to claim storage attribute information required by the container group, and the target backup persistent volume object points to a storage area for the backup data of the container group; create, for each container group, a target persistent volume claim and a target persistent volume object corresponding to the container group according to the target backup persistent volume claim and the target backup persistent volume object corresponding to the container group; and operate the container group according to the target persistent volume claim and the target persistent volume object corresponding to the container group, so as to recover operation of each container group in the service cluster instance.

The terminalmay be configured to transmit an instance recovery request for the service cluster instance to the serveraccording to server requirements, whereby the serverrecovers operation of each container group in the service cluster instance based on the instance recovery request.

The service cluster instance backup and recovery methods provided by this embodiment of the present disclosure relate to a direction of cloud storage and database in the field of cloud technology. This embodiment may be applied to various scenarios such as cloud technology, artificial intelligence, intelligent transportation, and assisted driving.

This embodiment is described from the perspective of a service cluster instance backup apparatus. The service cluster instance backup apparatus may be specifically integrated in a first electronic device. The first electronic device may be a server or a terminal. The order of description of the following embodiments is not intended to limit preference orders of the embodiments.

As shown in, a specific procedure of the service cluster instance backup method may be as follows:

: Determine a service cluster instance to be backed up, the service cluster instance including at least one container group. Hereinafter, steps-are described for one container group, it can be understood that the steps can be performed for each container group in the service cluster instance. Hereinafter, certain operation(s) may be described for each container group in the service cluster instance, it can be understood that such operation(s) may be performed for one or more container groups in the service cluster instance, and other operations may be performed for other container groups in service cluster instance.

The service cluster instance may be a cluster instance delivered from a stateful service (database), which may be denoted as Cluster. The cluster may be a cluster composed of a plurality of containers. The cluster may be a cluster for container management based on a container orchestration engine Kubernetes (K8s). The container orchestration engine may be configured to manage containerized applications on a plurality of hosts in a cloud platform.

Kubernetes is an open source system for automatically deploying, scaling, and managing containerized applications, which may realize the functions of combining a plurality of containers into one service and dynamically allocating hosts to support container operation.

Specifically, the service cluster instance may include at least one service component, and each service component may include at least one container group. As shown in, the service cluster instance may be abstracted into a three-layer resource management model, including cluster, set, and pod from top to bottom, where cluster corresponds to a service instance, set corresponds to a service component, and pod corresponds to a container group. For example, for a LibraDB product, the cluster instance is tdach-xxx, set includes zookeeper and clickhouse, and pod includes zookeeper pods and clickhouse-pods respectively, thereby meeting resource management requirements of database products. Through this resource management model, access of various service products may also be supported, and a starting order of service components, custom configuration of parameters of each service component, service pod shards, replicas, and other characteristics are supported.

LibraDB is a distributed hybrid transaction and analytical process (HTAP) database, which is based on pluggable engine design, powerful data fusion capability, and cloud native system architecture, and may provide users with an integrated product experience. ZooKeeper is a distributed open source distributed application coordination service, and clickhouse is a column database management system for online analysis.

The container group may be a container group responsible for the deployment of a service component in the service cluster instance. Each container group may include at least one container. Specifically, a container group (pod) may be a basic scheduling unit of Kubernetes, and a container group pod may include a plurality of service processes.

The container is an executable unit of software, where an application code is packaged together with libraries and dependencies in a common way. By isolating processes and controlling the amount of central processing unit (CPU), memory and disk accessible by these processes, the container allows a plurality of applications to share an operating system in the form of operating system virtualization.

: Set, for the container group, a source persistent volume claim and a source persistent volume object corresponding to the container group, and store the container group based on the source persistent volume object, the source persistent volume claim claiming storage attribute information required by the container group, and the source persistent volume object pointing to a data storage area of the container group.

The source persistent volume claim may be an application for storage resources, which represents an underlying storage object abstracted for Pod use, and claims a required storage capacity (such as 100G), Node exclusive or shared, file system or block device, or the like, which may be denoted as a persistent volume claim (PVC). Specifically, PVC is a resource demand application transmitted by users to the kubernetes system.

The storage attribute information required by the container group claimed by the source persistent volume claim may include a storage capacity, a file system type, and the like. This embodiment is not limited thereto.

The source persistent volume object is an abstraction of storage resources, which represents storage abstraction of an underlying hard disk and is associated with a real hard disk. The source persistent volume object may be denoted as a persistent volume (PV), namely, a persistent volume content.

The persistent volume herein is a cluster resource, which may be abstraction of an actual physical storage system in K8s. The persistent volume may be understood as a file system or block device that can be mounted inside a container, and corresponds to two working modes: Filesystem and Block.

Specifically, when the container group pod needs to use storage resources, it is necessary to refer to a volume of a PVC type in the definition of Volume and mount the PVC to a certain path in the container for use. After the PVC is mounted, the pod can use the storage resources. The same PVC may be mounted and used by a plurality of pods at the same time. In this case, the application shall deal with the problem of a plurality of processes accessing the same storage.

In this embodiment, a PVC corresponding to a container group may be set, a PV set currently in an available state (namely, a persistent volume object set) is determined, and then a PV matching configuration information of the PVC is selected from the PV set currently in the available state. That is, a plurality of PVs is preliminarily screened according to the configuration information of the PVC, whereby the PV that does not satisfy PVC conditions may be filtered out, thus avoiding the binding failure of the PV and the PVC, providing an accurate PV binding object for the PVC, and then establishing a binding relationship between the PVC and the selected PV.

The configuration information of the PVC may include, but is not limited to, a name, a binding state, a storage volume name, a storage space, an access mode, a storage type, and the like.

In one embodiment the step of setting, for the container group, a source persistent volume claim and a source persistent volume object corresponding to the container group and storing the container group based on the source persistent volume object may include:

The available state may specifically refer to a state that has not been bound by the PVC. The persistent volume object set includes at least one persistent volume object that is currently in the available state.

The establishing a binding relationship between the source persistent volume object and the source persistent volume claim may specifically be writing an object attribute identity of the source persistent volume object into configuration information of the source persistent volume claim. According to the binding relationship and the source persistent volume claim, the source persistent volume object corresponding to the source persistent volume claim may be determined, thus storing data of the container group to the data storage area pointed by the source persistent volume object.

In one embodiment, K8s provides two resource types: a persistent volume object PV and a persistent volume claim PVC to meet the requirements of container data persistence. Each PV may correspond to a storage space, such as a storage volume Volume on the server. The container belongs to a resource in K8s. The container resource specifies the PVC to be used in own configuration, and the specified PVC specifies storage resource configuration information such as a storage size and a storage mode to be used in own configuration. Finally, K8s pairs in the current kubernetes system according to the storage resource configuration information. If there is a PV that meets the claim requirements in the storage resource configuration information of the PVC, the PV may be bound with the PVC.

Specifically, the database is a typical application of a cloud native stateful service, which has high requirements for efficient access and persistent storage of data. The persistent storage of data is generally realized by the PV. By specifying the corresponding PVC in pod and calling an underlying container storage interface (CSI) plug-in, the dynamic plugging, formatting, and mounting of a cloud hard disk may be realized. In this way, Container (container) in pod may use the corresponding mounted disk directory.

CSI is an interface standard for container storage configuration defined by K8s. The standard defines interfaces for creating persistent volumes, deleting persistent volumes, and snapshots. Any storage that implements CSI specification may be used as back-end storage of K8s. In K8s, the function of storing snapshots may be realized by a CSI snapshotter controller.

Referring to, each container group pod will set a PVC to claim the required storage attribute information, such as a storage capacity and a volume mode. For example, the required storage capacity may be claimed as 20Gi and the volume mode may be claimed as Filesystem. After setting the PVC, the underlying CSI plug-in may implement a specific PV persistent storage implementation. The attribute information of the PV may include a storage capacity (for example, 20Gi), a storage type (for example, cbs-ssd), a reclaim policy, and the like.

The underlying PV is associated with a real hard disk (specifically, cloud hard disk) system. The attribute information of Disk may include a region, an available zone, a disk capacity (for example, 20Gi), a type (for example, solid-state hard disk SSD), and the like. The use of the hard disk will be charged according to cloud service standards, for example, charged yearly and monthly, or by volume.

The reclaim policy may be a retain policy. The retain policy means that the corresponding PV will be retained when the PVC is deleted. A storage class (SC) may be used for dividing different specifications, hard disk performance, and the like into specific classes for services as demanded, and the cost is controlled flexibly.

The storage resources (PV and PVC) are independently managed resources relative to the container group (pod) and may be deleted separately. When performing the operation of deleting resources, the system will detect whether the storage resources are currently being used. If the resources are still used, the deletion of related resources will be postponed until the resources are not used, thereby ensuring that data will not be lost since the resources are not directly deleted when being used.