Cross-cluster backup method, system, medium and electronic device for stateful application

By parsing the declaration file through the disaster recovery system and establishing a mapping relationship using the API interface, cross-cluster backup of stateful applications is achieved, solving the cumbersome problem of resource file and application data synchronization in existing technologies and improving synchronization efficiency and consistency.

CN114546725BActive Publication Date: 2025-09-09SHANGHAI DAOKE NETWORK TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202210168779.2
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-02-23
Publication Date
2025-09-09
Estimated Expiration
2042-02-23

AI Technical Summary

Technical Problem

In the existing technology, in the active-standby cluster deployment mode, the synchronization process of resource files and application data of stateful applications is cumbersome and requires separate operations by application administrators and backend storage system administrators, resulting in lengthy and inefficient operations.

Method used

The disaster recovery system deployed in the primary cluster parses the declaration file, determines the storage pool in the backend storage system, establishes a mapping relationship through the API interface, synchronizes resource files and application data to the backup cluster, and realizes cross-cluster binding of resource files and application data.

Benefits of technology

This simplifies the cross-cluster backup process for stateful applications, improves synchronization efficiency, reduces manual operations, and ensures that application instances in the backup cluster maintain the same operating state as the primary cluster.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114546725B_ABST
    Figure CN114546725B_ABST
Patent Text Reader

Abstract

The present application provides a cross-cluster backup method, system, computer-readable storage medium, and electronic device for stateful applications. The cross-cluster backup method is executed by a disaster recovery system deployed in a first cluster, and includes: parsing a declaration file corresponding to the stateful application to be backed up deployed in the first cluster to determine the storage pool bound to the stateful application in the back-end storage system corresponding to the first cluster; synchronizing the resource file corresponding to the stateful application to the second cluster to deploy an application copy of the stateful application in the second cluster; wherein the resource file includes a declaration file; and binding the application copy to the storage pool for storing application data in the back-end storage system corresponding to the second cluster according to the content of the declaration file corresponding to the application copy. In this way, the resource files and application data of the stateful application are directly synchronized through the disaster recovery system to achieve cross-cluster synchronization of the running status of the stateful application.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of cloud native technology, and in particular to a cross-cluster backup method, system, computer-readable storage medium, and electronic device for stateful applications. Background Art

[0002] In production practice, enterprises usually adopt the active / standby cluster deployment mode to deploy application instances. That is, application instances are deployed in the active cluster and the standby cluster respectively, and the running status of the application instances in the active cluster is synchronized to the standby cluster. When the active cluster fails and cannot respond to external access traffic normally, the standby cluster responds instead of the active cluster.

[0003] In order to deploy a replica of a stateful application in the primary cluster on the standby cluster, the application description file (Deployment), configuration file (ConfigMap), and other resource files corresponding to the stateful application deployed in the primary cluster must be synchronized to the standby cluster. Furthermore, the stateful application deployed in the primary cluster continuously generates new application data during operation. This application data and the resource files corresponding to the stateful application jointly determine the running state of the stateful application. The resource files of the stateful application are deployed in the cluster, and the application data of the stateful application is stored in a backend storage system independent of the cluster. The cluster cannot directly operate on the application data in the storage pool of the backend storage system. Therefore, synchronizing the resource files and application data of the stateful application requires the application administrator and the backend storage system administrator to perform operations in the primary cluster and the backend storage system, respectively, to synchronize the resource files of the stateful application to the standby cluster and synchronize the application data to the backend storage system corresponding to the standby cluster. Furthermore, the application replica generated based on the synchronized resource files must be bound to the synchronized application data to achieve synchronization of the running state of the stateful application.

[0004] Therefore, it is necessary to provide an improved technical solution to the above-mentioned deficiencies in the prior art. Summary of the Invention

[0005] The purpose of this application is to provide a cross-cluster backup method, system, computer-readable storage medium and electronic device for stateful applications to solve or alleviate the problems existing in the above-mentioned prior art.

[0006] In order to achieve the above objectives, this application provides the following technical solutions:

[0007] The present application provides a cross-cluster backup method for stateful applications, which is executed by a disaster recovery system deployed in a first cluster. The cross-cluster backup method for stateful applications includes: parsing a declaration file corresponding to the stateful application to be backed up deployed in the first cluster to determine a storage pool bound to the stateful application in a back-end storage system corresponding to the first cluster; synchronizing a resource file corresponding to the stateful application to a second cluster to deploy an application copy of the stateful application in the second cluster; wherein the resource file includes the declaration file; and binding the application copy to a storage pool for storing application data in the back-end storage system corresponding to the second cluster according to the content of the declaration file corresponding to the application copy.

[0008] Preferably, the first cluster corresponds to a first back-end storage system, the second cluster corresponds to a second back-end storage system, the stateful application corresponds to a first storage pool in the first back-end storage system, and the application copy corresponds to a second storage pool in the second back-end storage system; before synchronizing the resource files corresponding to the stateful application to the second cluster, it also includes: configuring the storage field in the declaration file corresponding to the stateful application to the second storage pool; the storage field is used to specify the storage location of the application data.

[0009] Preferably, after determining the storage pool bound to the stateful application in the back-end storage system corresponding to the first cluster, it also includes: establishing a mapping relationship between the first storage pool and the second storage pool through the API interface of the first back-end storage system to synchronize the application data corresponding to the stateful application stored in the first storage pool to the second storage pool.

[0010] Preferably, the mapping relationship is established between the first storage pool and the second storage pool through the API interface of the first back-end storage system, specifically including: determining the network communication topology relationship between all back-end storage systems; the network communication topology relationship includes the network communication connection relationship between the first back-end storage system and the second back-end storage system; synchronizing the application data corresponding to the stateful application stored in the first storage pool to the second back-end storage system through the API interface of the first back-end storage system; receiving the relevant information of the second storage pool selected by the second back-end storage system through the API interface of the first back-end storage system to establish a mapping relationship between the first storage pool and the second storage pool.

[0011] Preferably, the first cluster and the second cluster both correspond to the same back-end storage system, the stateful application and the application replica both correspond to the same storage pool in the back-end storage system, and synchronizing the resource files corresponding to the stateful application to the second cluster includes: modifying the content of a specified field in the resource file corresponding to the stateful application based on a preset configuration; the resource file includes at least one of an application description file and a configuration file; and synchronizing the modified resource file corresponding to the stateful application to the second cluster.

[0012] Preferably, the cross-cluster backup method for stateful applications further includes: monitoring resource files corresponding to the stateful application; and synchronizing the changed resource files corresponding to the stateful application to the second cluster in response to changes in the content of the resource files corresponding to the stateful application.

[0013] Preferably, the monitoring of the resource files corresponding to the stateful application includes: establishing a long connection with the API-Server component in the first cluster; monitoring the change events of the resource files corresponding to the stateful application through the long connection to determine whether the content of the resource files corresponding to the stateful application has changed; or, periodically accessing the API-Server component in the first cluster to obtain the resource files corresponding to the stateful application to actively detect whether the resource files corresponding to the stateful application have changed.

[0014] An embodiment of the present application also provides a cross-cluster backup system for stateful applications, which is deployed in a first cluster. The cross-cluster backup system for stateful applications includes: a first binding unit, configured to parse a declaration file corresponding to the stateful application to be backed up deployed in the first cluster, so as to determine the storage pool bound to the stateful application in the back-end storage system corresponding to the first cluster; a synchronization unit, configured to synchronize the resource file corresponding to the stateful application to a second cluster, so as to deploy an application copy of the stateful application in the second cluster; wherein the resource file includes the declaration file; and a second binding unit, configured to bind the application copy to the storage pool for storing application data in the back-end storage system corresponding to the second cluster according to the content of the declaration file corresponding to the application copy.

[0015] An embodiment of the present application further provides a computer-readable storage medium having a computer program stored thereon. The computer program is a cross-cluster backup method for a stateful application as described above.

[0016] An embodiment of the present application further provides an electronic device, comprising: a memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the cross-cluster backup method for stateful applications as described above is implemented.

[0017] Beneficial effects:

[0018] The technical solution provided by the embodiment of the present application is executed by the disaster recovery system deployed in the main cluster (first cluster), and the declaration file corresponding to the stateful application to be backed up deployed in the main cluster is parsed to determine the storage pool bound to the stateful application in the back-end storage system corresponding to the main cluster, and then the resource files corresponding to the stateful application (including declaration files, application description files, configuration files, etc.) are synchronized to another one or more clusters (second clusters) to deploy the application copy of the stateful application in the main cluster in the other one or more clusters, and finally, according to the content of the declaration file corresponding to the application copy, the application copy is bound to the storage pool for storing application data in the back-end storage system corresponding to the other one or more clusters. In this way, the resource files and application data of the stateful application are directly synchronized through the disaster recovery system to achieve cross-cluster synchronization of the running status of the stateful application. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings and descriptions that constitute part of this application are intended to provide a further understanding of this application. The exemplary embodiments and descriptions of this application are intended to explain this application and do not constitute an improper limitation on this application. Among them:

[0020] Figure 1 A schematic diagram of a process for a cross-cluster backup method for a stateful application according to some embodiments of the present application;

[0021] Figure 2 A logical diagram of an application administrator writing an application management resource object to a disaster recovery system according to some embodiments of the present application;

[0022] Figure 3 A logical diagram of a multi-cluster administrator providing cluster access authentication information to a disaster recovery system according to some embodiments of the present application;

[0023] Figure 4 A logical schematic diagram of establishing a mapping relationship between a first storage pool and a second storage pool according to some embodiments of the present application;

[0024] Figure 5 A logical diagram of monitoring a declaration file corresponding to a stateful application according to some embodiments of the present application;

[0025] Figure 6A logical diagram of modifying a declaration file corresponding to a stateful application according to some embodiments of the present application;

[0026] Figure 7 A logical diagram of binding an application replica to a storage pool of application data provided according to some embodiments of the present application;

[0027] Figure 8 A schematic diagram of the structure of a cross-cluster backup system for stateful applications provided according to some embodiments of the present application;

[0028] Figure 9 A schematic structural diagram of an electronic device provided according to some embodiments of the present application;

[0029] Figure 10 A hardware structure of an electronic device is provided according to some embodiments of the present application. DETAILED DESCRIPTION

[0030] The present application will be described in detail below with reference to the accompanying drawings and in conjunction with the embodiments. Each example is provided by way of explanation of the present application and does not limit the present application. In fact, it will be clear to those skilled in the art that modifications and variations can be made in the present application without departing from the scope or spirit of the present application. For example, a feature shown or described as part of one embodiment can be used in another embodiment to produce yet another embodiment. Therefore, it is expected that the present application includes such modifications and variations within the scope of the appended claims and their equivalents.

[0031] Based on the above description of the background technology, it can be known that in the prior art, enterprises use an active / standby cluster deployment mode to deploy application instances.

[0032] Specifically, after the application instances are deployed in the primary cluster and the backup cluster respectively, under normal circumstances, the application instances deployed in the primary cluster respond to external access traffic. When the primary cluster fails and cannot respond to external access traffic normally, the application instances deployed in the backup cluster replace the application instances in the primary cluster to respond. Therefore, in order to ensure that the application instances in the backup cluster can seamlessly replace the application instances in the primary cluster to respond to external access traffic, it is necessary to ensure that the running status of the application instances deployed in the primary cluster and the backup cluster remain consistent. In the process of responding to external access traffic, the running status of the application instances in the primary cluster is constantly changing. In order to ensure that the running status of the application instances deployed in the primary cluster and the backup cluster remain consistent, it is necessary to synchronize the running status of the application instances in the primary cluster to the backup cluster.

[0033] Applications can be divided into stateless applications and stateful applications based on whether persistent data storage is required. Currently, stateful applications deployed in the primary cluster will continuously generate new application data during operation. These application data and the resource files corresponding to the stateful applications jointly determine the running status of the stateful applications. Therefore, in order to ensure that the running status of the application replica of the stateful application deployed in the backup cluster is always synchronized with the stateful application in the primary cluster, it is also necessary to synchronize these application data to a storage pool in the backend storage system corresponding to the backup cluster and bind them to the application replica of the stateful application in the backup cluster, so that the running status of the application replica of the stateful application in the backup cluster is always consistent with that of the stateful application in the primary cluster.

[0034] In existing technical solutions, when synchronizing the resource files of a stateful application in the primary cluster to the backup cluster, the application administrator must also provide the backend storage system administrator with the storage pool bound to the stateful application in the backend storage system, and the backend storage system administrator will synchronize the application data of the stateful application. After the backend storage system administrator completes the synchronization of the application data, the application administrator must also obtain the storage location of the application data in the backend storage system corresponding to the backup cluster from the backend storage system administrator and bind it to the application replica in the backup cluster before synchronizing the running status of the application instance in the primary cluster to the backup cluster.

[0035] In existing technical solutions, application administrators lack the effective authority and means to directly synchronize the application data of stateful applications. They need to request the back-end storage system administrator to synchronize the application data on their behalf. After completing the synchronization of the application data, they need to manually bind the application data and the application replica. The operation is cumbersome and the process is lengthy.

[0036] The present application provides a cross-cluster backup method, system, computer-readable storage medium, and electronic device for stateful applications to solve or alleviate the problems existing in the above-mentioned prior art.

[0037] For ease of explanation, in the embodiment of the present application, the primary cluster is referred to as the first cluster, and the backup cluster is referred to as the second cluster.

[0038] It should be noted that in this embodiment of the present application, the first cluster is the cluster where the stateful application to be backed up resides, and the second cluster is the backup cluster designated by the application administrator. In production practice, the application administrator can designate one or more backup clusters for the stateful application to be backed up. This embodiment of the present application is described using the case of designating a single backup cluster, and this is not intended to limit this embodiment of the present application.

[0039] Exemplary Methods

[0040] like Figure 1 As shown, the cross-cluster backup method for the stateful application is executed by the disaster recovery system deployed in the first cluster, including:

[0041] Step S101: Parse a declaration file corresponding to a stateful application to be backed up that is deployed in a first cluster to determine a storage pool bound to the stateful application in a backend storage system corresponding to the first cluster.

[0042] In an embodiment of the present application, the application administrator writes the application management resource object into the disaster recovery system of the first cluster where the stateful application to be backed up is located, specifies one or more backup clusters for the stateful application to be backed up, and configures the synchronous execution of the resource files and application data corresponding to the stateful application to be backed up.

[0043] A manifest file (also known as a PV / PVC file) is a special type of resource file for a stateful application. Its contents are used to bind the stateful application to a storage pool. In other words, a stateful application uses a manifest file to bind to a storage pool in the backend storage system, persisting data there. As a stateful application runs, it continuously generates new application data. This application data, along with the resource files that correspond to the stateful application, determines the application's operational state.

[0044] In the embodiment of the present application, the disaster recovery system specifically includes a configuration manager, a resource manager, a storage backend configurator, a resource modification manager, and a transmission manager. The application administrator writes the application management resource object into the disaster recovery system of the first cluster, that is, writes the application management resource object into the custom application management resource deployed in the configuration manager, specifies the stateful application to be synchronized and the backup cluster for synchronization, such as Figure 2 As described above, the resource manager, storage backend configurator, resource modification manager, and transfer manager obtain their own configurations from the configuration manager to implement corresponding functions.

[0045] Furthermore, if the first cluster is a Kubernetes cluster, the above-mentioned configuration manager, resource manager, storage backend configurator, resource modification manager and transport manager can all be managed by the kubelet component of the Kubernetes system.

[0046] Among them, the resource manager determines the stateful application that needs to be synchronized based on the content of the custom management resources deployed in the configuration manager, obtains the declaration file of the stateful application through the API-Server component of the first cluster, and parses the declaration file of the stateful application to determine the storage pool bound to the stateful application in the back-end storage system corresponding to the first cluster where the stateful application is located, so as to synchronize the application data stored in the storage pool to the back-end storage system corresponding to the backup cluster.

[0047] Step S102: Synchronize resource files corresponding to the stateful application to the second cluster, so as to deploy an application copy of the stateful application in the second cluster.

[0048] Among them, the resource file includes the declaration file.

[0049] In an embodiment of the present application, in order to deploy an application copy of a stateful application in the first cluster in the second cluster, it is necessary to synchronize the declaration file, application description file, configuration file and other resource files corresponding to the stateful application deployed in the first cluster to the second cluster. However, the first cluster and the second cluster belong to two different clusters, and the disaster recovery system deployed in the first cluster has no right to access the second cluster. Therefore, the access authentication information of the second cluster is obtained from the multi-cluster management system, where the multi-cluster management system is used to manage the first cluster and the second cluster; the access authentication information includes at least one of a certificate, a key, and a token, such as Figure 3 shown.

[0050] That is, the multi-cluster administrator writes the cluster management resource object into the custom cluster management resource deployed in the multi-cluster management system, and the multi-cluster management system sends the access authentication information (such as certificates, keys, tokens, etc.) for establishing connections between clusters to each cluster, and each cluster connects to other clusters through the access authentication information.

[0051] Based on the above description, it can be known that in order to ensure that the running status of the application copy in the second cluster is always consistent with the stateful application in the first cluster, the cross-cluster backup method of the stateful application proposed in the embodiment of the present application requires synchronization of application data, resource files, etc., and the declaration file used to bind the storage pool among the many types of resource files is closely related to the synchronization operation of application data. The synchronization of application data is an extremely critical item in the cross-cluster backup process of stateful applications, and is first explained.

[0052] In the embodiment of the present application, stateful applications deployed in different clusters can share a backend storage system to store application data, that is, the clusters where stateful applications are deployed and the backend storage systems are not in a one-to-one correspondence. Figure 2 and Figure 3 shown.

[0053] In a specific example, the first cluster corresponds to the first backend storage system, the second cluster corresponds to the second backend storage system, the stateful application corresponds to the first storage pool in the first backend storage system, and the application replica corresponds to the second storage pool in the second backend storage system. Before synchronizing the resource files corresponding to the stateful application to the second cluster, the cross-cluster backup method of the stateful application also includes: configuring the storage field in the declaration file corresponding to the stateful application as the second storage pool, and the storage field is used to specify the storage location of the application data.

[0054] In an application scenario, such as Figure 4 As shown, after determining the storage pool bound to the stateful application in the backend storage system corresponding to the first cluster, a mapping relationship is established between the first storage pool and the second storage pool through the API interface of the first backend storage system, so as to synchronize the application data corresponding to the stateful application stored in the first storage pool to the second storage pool. Specifically, after determining the second cluster, the storage backend configurator configures the storage pool synchronization between the first backend storage system and the second backend storage system corresponding to the second cluster through the API interface of the first backend storage system according to the connection relationship between the multiple backend storage systems, thereby synchronizing the application data of the stateful application to be backed up to the storage pool of the second backend storage system.

[0055] When establishing a mapping relationship between the first storage pool and the second storage pool through the API interface of the first backend storage system, the network communication topology relationship between all backend storage systems is first determined; the network communication topology relationship includes the network communication connection relationship between the first backend storage system and the second backend storage system. Specifically, the storage backend configurator obtains a topology map between the multiple backend storage systems based on the content of the custom application management resources deployed in the configuration manager, thereby determining the connection relationship between the multiple backend storage systems.

[0056] Then, through the API interface of the first backend storage system, the application data corresponding to the stateful application stored in the first storage pool is synchronized to the second backend storage system; and through the API interface of the first backend storage system, the relevant information of the second storage pool selected by the second backend storage system is received to establish a mapping relationship between the first storage pool and the second storage pool. Furthermore, the first backend storage system and the second backend storage system can be connected via a high-performance, low-latency dedicated line network, so that the application data of the stateful application to be backed up can be synchronized to the second backend storage system in real time.

[0057] In another specific example, the first cluster and the second cluster correspond to the same back-end storage system, the stateful application corresponds to the first storage pool in the back-end storage system, and the application replica corresponds to the second storage pool in the back-end storage system. Before synchronizing the resource files corresponding to the stateful application to the second cluster, the cross-cluster backup method of the stateful application also includes: configuring the storage field in the declaration file corresponding to the stateful application as the second storage pool, and the storage field is used to specify the storage location of the application data.

[0058] After determining the storage pool bound to the stateful application in the backend storage system corresponding to the first cluster, a mapping relationship is established between the first storage pool and the second storage pool through the API interface of the backend storage system to synchronize the application data corresponding to the stateful application stored in the first storage pool to the second storage pool. Specifically, after determining the second cluster, the storage backend configurator configures the synchronization of application data between the first storage pool and the second storage pool in the same backend storage system through the API interface of the backend storage system, thereby synchronizing the application data of the stateful application to be backed up from the first storage pool to the second storage pool of the same backend storage system.

[0059] In another specific example, the first cluster and the second cluster correspond to the same backend storage system, and the stateful application and the application replica both correspond to the same storage pool in the backend storage system. It should be understood that in this embodiment, since the stateful application and the application replica correspond to the same storage pool in the same backend storage system, there is no need to synchronize the application data of the stateful application to be backed up.

[0060] In several of the aforementioned embodiments, the different relationships between stateful applications, application replicas, and storage pools lead to differences in the synchronization operations for application data. Specifically, some embodiments require modifying the storage fields in the manifest file corresponding to the stateful application, while other embodiments do not require modifying the manifest file corresponding to the stateful application and can directly synchronize to the second cluster.

[0061] Based on the above description, it can be known that the resource files in the embodiment of the present application include not only the declaration file, which is a special resource file used to bind the storage pool, but also general resource files such as application description files and configuration files. For the general resource files corresponding to these stateful applications, the contents of the specified fields also need to be modified to adapt to the operating environment of the second cluster.

[0062] The following describes the synchronization operations for general resource files such as application description files and configuration files corresponding to stateful applications.

[0063] Specifically, when synchronizing the resource file corresponding to the stateful application to the second cluster, the content of the specified field in the resource file corresponding to the stateful application is modified based on the preset configuration, and the modified resource file corresponding to the stateful application is synchronized to the second cluster.

[0064] Among them, the preset configuration can be configured by the application administrator when specifying the stateful application and the second cluster. Due to the differences in the operating environments of the first cluster and the second cluster, for example, the intranet environments of the two clusters are different, or the two clusters use different image repositories, before synchronizing the resource files corresponding to the stateful application from the first cluster to the second cluster, the relevant fields in the resource files used to adapt to the operating environment need to be modified.

[0065] Furthermore, based on the above description, it can be seen that when the storage pools corresponding to the stateful application and the application replica are different, the storage fields in the declaration file corresponding to the stateful application need to be modified. The declaration file is also a resource file, which allows the modification of the declaration file and other resource files to be completed in the same step to reduce the method steps.

[0066] In some high-reliability scenarios, the running status of stateful applications needs to be synchronized to the second cluster in real time. The running status of stateful applications depends on the resource files and application data corresponding to the stateful applications, such as declaration files, application description files, and configuration files. Therefore, synchronizing the resource files corresponding to the stateful applications in the first cluster to the second cluster in real time is a necessary condition for synchronizing the running status of the stateful applications to the second cluster in real time.

[0067] In order to achieve real-time backup of stateful applications deployed in the first cluster, the disaster recovery system deployed in the first cluster needs to obtain the latest resource files corresponding to the stateful applications to be backed up during the first backup, and continuously monitor the resource files corresponding to the stateful applications, and synchronize the latest resource files obtained during the first backup and the changes in the resource files obtained during the continuous monitoring process to the second cluster.

[0068] Specifically, the resource files corresponding to the stateful application are monitored, and in response to changes in the content of the resource files corresponding to the stateful application, the changed resource files corresponding to the stateful application are synchronized to the second cluster in real time.

[0069] In particular, for the declaration file used to bind the storage pool, when the storage pool bound to the stateful application changes, the content of the declaration file corresponding to the stateful application will also change. Therefore, by monitoring the changes in the declaration file, it is possible to indirectly determine whether the storage pool bound to the stateful application has changed, such as Figure 5 shown.

[0070] Here, the resource files corresponding to the stateful application are monitored in real time or periodically by the resource manager deployed in the disaster recovery system in the first cluster. When the first cluster is a Kubernetes cluster, since the API-Server component of the Kubernetes system provides access to all resource files in the Kubernetes cluster, monitoring of the resource files corresponding to the stateful application is achieved by establishing a persistent connection between the resource manager and the API-Server component in the Kubernetes cluster.

[0071] In one application scenario, a persistent connection is established with the API-Server component in the first cluster. Change events of resource files corresponding to stateful applications are monitored through the persistent connection to determine whether the contents of resource files corresponding to the stateful applications have changed. Specifically, a persistent connection can be established between the resource manager and the API-Server component of the first cluster. The resource manager uses the persistent connection to monitor change events of resource files such as declaration files, application description files, and configuration files corresponding to the stateful applications in the first cluster. When resource files corresponding to the stateful applications in the first cluster change, the resource manager can immediately obtain all resource files or the changed resource files.

[0072] In another application scenario, the API-Server component in the first cluster is periodically accessed to obtain the resource files corresponding to the stateful application, so as to actively detect whether the resource files corresponding to the stateful application have changed. Specifically, the resource manager periodically and actively accesses the API-Server component in the first cluster to obtain the resource files corresponding to the stateful application in the first cluster. It can be understood that by continuously and periodically accessing the API-Server component in the first cluster, the resource files corresponding to the stateful application in the first cluster can be obtained multiple times, and the resource files obtained twice are compared. Once a difference is found, it can be determined that the resource files corresponding to the stateful application have changed. In this way, the resource manager actively accesses the API-Server component in the first cluster periodically to actively obtain all or changed declaration files, application description files, configuration files and other resource files corresponding to the stateful application to be backed up in the first cluster, effectively avoiding the interruption of the long connection established between the resource manager and the API-Server component in the first cluster due to network problems.

[0073] It should be noted that the above-mentioned solution of establishing a persistent connection and periodically actively accessing the API-Server component can also be combined.

[0074] In addition, when the first cluster is a Kubernetes cluster, the Kubelet component of the Kubernetes system can monitor the resource files corresponding to the stateful applications deployed in the first cluster in real time. When the Kubelet component in the first cluster detects that the resource files of the stateful applications to be backed up deployed in the first cluster have changed, the changes in the resource files are written to the distributed state storage database (ETCD) in the first cluster through the API-Server component in the first cluster. By accessing the distributed state storage database in the first cluster through the API-Server component in the first cluster, all resource files or changed resource files corresponding to the stateful applications to be backed up deployed in the first cluster can be obtained in real time or periodically.

[0075] In an embodiment of the present application, the resource manager obtains its own configuration information from the configuration manager, implements real-time or periodic monitoring of the resource files corresponding to the stateful application to be backed up, and accesses the distributed state storage database in the first cluster through the API-Server component in the first cluster to obtain all the resource files corresponding to the stateful application to be backed up or the changed resource files.

[0076] In a specific example, the content of a specified field in a resource file corresponding to a stateful application is modified based on a preset configuration, specifically including: first, parsing a pre-written application management resource object; then, according to the application management resource object, modifying the content of a specified field in the resource file corresponding to the stateful application in sequence to meet the operating requirements of the second cluster.

[0077] The application management resource object (CR) is used to specify the fields to be modified in the resource files corresponding to the second cluster and the stateful application, and to set the order in which the specified fields in the resource files are modified. Resource files include declaration files, application description files, and configuration files. Accordingly, the specified fields include storage fields in the declaration file and at least one of the IP address and image repository in other resource files.

[0078] It should be noted that in an embodiment of the present application, the application administrator can specify the stateful application to be backed up, the second cluster for backup, and the fields to be modified in the resource file corresponding to the stateful application by manually writing the application management resource object to the disaster recovery system. If there are more than two specified fields that need to be modified, the order in which the specified fields are modified can also be set.

[0079] The configuration manager of the disaster recovery system in the embodiment of the present application includes a custom application management resource (CRD). The application administrator can specifically write an application management resource object to the custom application management resource in the configuration manager of the disaster recovery system in advance to specify the stateful application to be backed up, the second cluster for backup, the fields to be modified in the resource file corresponding to the stateful application, and set the order in which the specified fields are to be modified.

[0080] When the custom application management resource in the configuration manager receives the application management resource object written by the application administrator, the configuration manager specifically parses the pre-written application management resource object to determine the stateful application to be backed up.

[0081] Based on the above description, it can be known that the application management resource object specifies the second cluster for backup, the fields to be modified in the resource file corresponding to the stateful application, and the order in which the specified fields are modified. Therefore, after parsing the application management resource object, the fields to be modified in the resource file corresponding to the stateful application, the order in which the specified fields are modified, and the second cluster for backup can be determined based on the content of the application management resource object, and the modified content of the fields to be modified can be determined based on the second cluster for backup.

[0082] If the field to be modified is an IP address, first obtain an idle IP address under the intranet segment of the second cluster, and then modify the IP address in the resource file to the IP address under the intranet segment of the second cluster; if the field to be modified is an image warehouse, first obtain the image warehouse used by the second cluster, and then modify the image warehouse in the resource file to the image warehouse used by the second cluster.

[0083] In a specific example, at least one resource modification unit is instantiated based on an application management resource object. The at least one resource modification unit forms a resource modification pipeline, which is configured to modify the content of a specified field in a specified order. Each resource modification unit is configured to modify the content of a corresponding specified field. In response to a resource file corresponding to a stateful application being input into the resource modification pipeline, the resource modification pipeline modifies the content of the specified fields in the resource file corresponding to the stateful application to be backed up in the specified order.

[0084] It should be noted that in the embodiment of the present application, the resource modification pipeline is specifically used to sequentially modify the contents of the specified fields in the resource file corresponding to the stateful application. The resource modification pipeline includes at least one resource modification unit, and each resource modification unit is used to modify the contents of the corresponding specified field. In other words, each resource modification unit corresponds to a specified field to be modified, and the position of all resource modification units in the resource modification unit determines the modification order of all specified fields to be modified. The resource modification unit corresponding to the first specified field to be modified is located at the head of the resource modification pipeline, and then arranged in sequence. The resource modification unit corresponding to the last specified field to be modified is located at the end of the resource modification pipeline.

[0085] In a special case, if there is only one designated field to be modified, the resource modification pipeline only includes one resource modification unit; in another special case, if there is no designated field to be modified, the resource modification pipeline does not need to modify the resource file corresponding to the stateful application.

[0086] In order to perform the above operations, at least one resource modification unit is instantiated according to the application management resource object. After the embodiment of the present application parses the pre-written application management resource object through the configuration manager, the fields to be modified in the resource file corresponding to the stateful application, the modified contents of the fields to be modified, and the order of modifying the specified fields are transmitted to the containerized deployed resource modification manager. The resource modification manager instantiates at least one resource modification unit in sequence in the resource modification pipeline based on the information obtained from the configuration manager, and sets the corresponding fields to be modified and the modified contents of the fields to be modified for each resource modification unit.

[0087] It should be noted that the resource modification pipeline in the embodiment of the present application is also deployed in a containerized form in the first cluster, and is used to instantiate at least one resource modification unit according to the instructions of the resource modification manager, and receive the resource file corresponding to the stateful application from the resource manager. The resource modification units set in sequence on the resource modification pipeline modify the content of the specified field in the resource file so that it can run normally in the second cluster.

[0088] In addition to the above-mentioned implementation method of completing the modification of the declaration file and other resource files in the same step, the embodiment of the present application can also perform the modification of the declaration file and other resource files separately, that is, the modification of other resource files is performed according to the above-mentioned modification method, and the resource modification manager directly modifies the storage fields in the declaration file.

[0089] When the first cluster and the second cluster correspond to different backend storage systems respectively, after the resource manager of the disaster recovery system obtains the declaration file of the stateful application, the resource modification manager modifies the backend storage system set in the declaration file to the second backend storage system corresponding to the second cluster, and modifies the storage pool set in the declaration file to the second storage pool in the second backend storage system for storing synchronized application data, so that it can run in the second cluster, such as Figure 6 shown.

[0090] From the above analysis, it can be seen that when the first cluster and the second cluster both correspond to the same backend storage system, only the storage pool within the backend storage system needs to be synchronized. In this case, if the storage pool storing the application data of the stateful application is different from the storage pool storing the application data of the application replica, the resource modification manager only needs to modify the storage pool specified in the declaration file to enable it to run in the second cluster. When the stateful application and the application replica correspond to the same storage pool, the resource modification manager does not need to modify the stateful application declaration file and can automatically achieve real-time synchronization of the stateful application and the application replica in the backend storage system.

[0091] Step S103: Bind the application copy to a storage pool for storing application data in a backend storage system corresponding to the second cluster according to the content of the declaration file corresponding to the application copy.

[0092] Based on the above description, it can be seen that the resource files and application data of the stateful application jointly determine the running state of the stateful application. In order to synchronize the running state of the application copy of the stateful application deployed in the standby cluster with the stateful application in the first cluster, it is necessary to synchronize the new application data to a storage pool in the backend storage system corresponding to the standby cluster, and bind it with the application copy of the stateful application in the second cluster, so that the running state of the application copy of the stateful application in the standby cluster is synchronized with the stateful application in the first cluster. In addition, in certain high-reliability scenarios, in order to synchronize the running state of the application copy of the stateful application deployed in the standby cluster with the stateful application in the first cluster in real time, it is necessary to synchronize the new application data to a storage pool in the backend storage system corresponding to the standby cluster, and bind it with the application copy of the stateful application in the second cluster, so that the running state of the application copy of the stateful application in the standby cluster is always consistent with the stateful application in the first cluster.

[0093] Bind the storage pool used to store the synchronized application data in the back-end storage system corresponding to the second cluster to the application copy of the stateful application. Through the storage pool synchronization function of the back-end storage system, after determining the backup cluster, the storage back-end configurator can configure the storage pool synchronization between the back-end storage system corresponding to the first cluster and the back-end storage system corresponding to the second cluster according to the connection relationship between multiple back-end storage systems, thereby synchronizing the application data of the stateful application to the back-end storage system corresponding to the second cluster, and realizing synchronization of the application copy in the second cluster with the application data of the stateful application in the first cluster.

[0094] When the second cluster is a Kubernetes cluster, the API-Server component of the second cluster stores the declaration file of the stateful application modified by the resource modification manager in the ETCD of the second cluster. The CSI component of the second cluster reads the synchronized declaration file and informs the Kubelet component of the storage pool for storing the synchronized application data in the backend storage system corresponding to the second cluster. The Kubelet component binds the application copy to the storage pool for storing the synchronized application data in the backend storage system corresponding to the second cluster according to the content of the synchronized declaration file, so that the application data of the application copy deployed in the second cluster is synchronized with the application data of the stateful application deployed in the first cluster. Figure 7 shown.

[0095] In this way, by synchronizing the application data of the stateful application in the first cluster to the storage pool of the back-end storage system corresponding to the second cluster, and binding the application copy in the second cluster to the storage pool of the corresponding back-end storage system, the synchronization of the application copy in the second cluster and the application data of the stateful application in the first cluster is achieved; by parsing the declaration file corresponding to the stateful application, the storage pool corresponding to the stateful application in the back-end storage system is determined, and the declaration file that has changed is synchronized using a zero-latency resource change event-driven trigger or a periodic trigger, and a high-performance, low-latency dedicated line network is used to achieve synchronization of the storage pools between the back-end storage systems to achieve real-time synchronization of application data, so that the application data of the application copy in the second cluster is almost lost compared to the stateful application in the first cluster.

[0096] In the implementation of this application, the fields regarding storage pool binding in the declaration file are modified through the resource modification manager in the disaster recovery system, so that after the declaration file is synchronized to the second cluster, the storage pool where the application data synchronized to the back-end storage system corresponding to the second cluster is located can be bound to the application copy; multiple clusters are managed by using multi-cluster administrators and cluster administrators to write cluster management resource objects, and the application administrator specifies the standby cluster of the stateful application by writing application management resource objects, configures declaration files, and the synchronization execution process of application data, thereby effectively improving the efficient management and risk control of the entire disaster recovery system.

[0097] Exemplary Systems

[0098] Figure 8 FIG. 1 is a schematic diagram of a cross-cluster backup system for a stateful application according to some embodiments of the present application; FIG. Figure 8 As shown, the cross-cluster backup system for the stateful application is deployed in the first cluster, specifically including:

[0099] The first binding unit 801 is configured to parse a declaration file corresponding to the stateful application to be backed up deployed in the first cluster, to determine a storage pool bound to the stateful application in the backend storage system corresponding to the first cluster.

[0100] The synchronization unit 802 is configured to synchronize resource files corresponding to the stateful application to the second cluster, so as to deploy an application copy of the stateful application in the second cluster. The resource files include declaration files.

[0101] The second binding unit 803 is configured to bind the application copy to a storage pool for storing application data in a backend storage system corresponding to the second cluster according to the content of the declaration file corresponding to the application copy.

[0102] The cross-cluster backup system for stateful applications provided in the embodiments of the present application can implement the steps and processes of any of the above-mentioned cross-cluster backup method embodiments for stateful applications and achieve the same technical effects, which will not be described in detail here.

[0103] Exemplary devices

[0104] Figure 9 Schematic diagram of the structure of an electronic device according to some embodiments of the present application; Figure 9 As shown, the electronic device includes:

[0105] One or more processors 901;

[0106] The computer-readable medium can be configured to store one or more programs 902. When one or more processors 901 execute the one or more programs 902, the following steps are implemented: parsing the declaration file corresponding to the stateful application to be backed up deployed in the first cluster to determine the storage pool bound to the stateful application in the back-end storage system corresponding to the first cluster; synchronizing the resource file corresponding to the stateful application to the second cluster to deploy an application copy of the stateful application in the second cluster; wherein the resource file includes a declaration file; and binding the application copy to the storage pool for storing application data in the back-end storage system corresponding to the second cluster according to the content of the declaration file corresponding to the application copy.

[0107] Figure 10 The hardware structure of the electronic device provided according to some embodiments of the present application; Figure 10 As shown, the hardware structure of the electronic device may include: a processor 1001 , a communication interface 1002 , a computer-readable medium 1003 and a communication bus 1004 .

[0108] The processor 1001 , the communication interface 1002 , and the computer-readable storage medium 1003 communicate with each other via a communication bus 1004 .

[0109] Optionally, the communication interface 1002 may be an interface of a communication module, such as an interface of a GSM module.

[0110] Among them, the processor 1001 can be specifically configured to: parse the declaration file corresponding to the stateful application to be backed up deployed in the first cluster to determine the storage pool bound to the stateful application in the back-end storage system corresponding to the first cluster; synchronize the resource file corresponding to the stateful application to the second cluster to deploy an application copy of the stateful application in the second cluster; wherein the resource file includes a declaration file; and bind the application copy to the storage pool for storing application data in the back-end storage system corresponding to the second cluster according to the content of the declaration file corresponding to the application copy.

[0111] The processor 1001 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., and may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The methods, steps, and logic block diagrams disclosed in the embodiments of the present application may be implemented or executed. The general-purpose processor may be a microprocessor or any conventional processor.

[0112] The electronic devices of the embodiments of the present application exist in various forms, including but not limited to:

[0113] (1) Mobile communication devices: These devices are characterized by their mobile communication capabilities and are primarily designed to provide voice and data communications. These terminals include smartphones (e.g., iPhones), multimedia phones, feature phones, and low-end phones.

[0114] (2) Ultra-mobile personal computer devices: These devices fall under the category of personal computers, have computing and processing capabilities, and generally also have mobile Internet access. These terminals include PDAs, MIDs, and UMPCs, such as the iPad.

[0115] (3) Portable entertainment devices: These devices can display and play multimedia content. These devices include audio and video players (e.g., iPods), handheld game consoles, e-books, smart toys, and portable car navigation devices.

[0116] (4) Server: A device that provides computing services. The server consists of a processor, hard disk, memory, system bus, etc. The server is similar to a general computer architecture, but because it needs to provide highly reliable services, it has higher requirements in terms of processing power, stability, reliability, security, scalability, and manageability.

[0117] (5) Other electronic devices with data interaction functions.

[0118] It should be pointed out that, according to the needs of implementation, the various components / steps described in the embodiments of the present application can be split into more components / steps, or two or more components / steps or partial operations of components / steps can be combined into new components / steps to achieve the purpose of the embodiments of the present application.

[0119] The above-mentioned method according to the embodiment of the present application can be implemented in hardware, firmware, or implemented as software or computer code that can be stored in a recording medium (such as a CD ROM, RAM, floppy disk, hard disk or magneto-optical disk), or implemented as computer code originally stored in a remote recording medium or a non-temporary machine storage medium downloaded via a network and to be stored in a local recording medium, so that the method described herein can be stored in such software processing on a recording medium using a general-purpose computer, a dedicated processor or programmable or dedicated hardware (such as an ASIC or FPGA). It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code, and when the software or computer code is accessed and executed by a computer, a processor or hardware, the cross-cluster backup method for stateful applications described herein is implemented. In addition, when a general-purpose computer accesses the code for implementing the method shown herein, the execution of the code converts the general-purpose computer into a dedicated computer for executing the method shown herein.

[0120] Those skilled in the art will appreciate that the units and method steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of this application.

[0121] It should be noted that the various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences from the other embodiments. In particular, the device and system embodiments are described briefly because they are generally similar to the method embodiments. For relevant parts, refer to the description of the method embodiments.

[0122] The device and system embodiments described above are merely illustrative. Units not described as separate may or may not be physically separate, and units not described as units may or may not be physical units, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiments. Persons of ordinary skill in the art will be able to understand and implement the present embodiments without inventive effort.

[0123] The above are only preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various modifications and variations of the present application are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A cross-cluster backup method for stateful applications, characterized in that: The method is executed by a disaster recovery system deployed in a first cluster. The cross-cluster backup method for stateful applications includes: Parsing a declaration file corresponding to the stateful application to be backed up deployed in the first cluster to determine a storage pool bound to the stateful application in a backend storage system corresponding to the first cluster; Synchronizing resource files corresponding to the stateful application to a second cluster, so as to deploy an application copy of the stateful application in the second cluster; wherein the resource files include the declaration file; Binding the application copy to a storage pool for storing application data in a backend storage system corresponding to the second cluster according to the content of the declaration file corresponding to the application copy; The first cluster corresponds to a first backend storage system, the second cluster corresponds to a second backend storage system, the stateful application corresponds to a first storage pool in the first backend storage system, and the application replica corresponds to a second storage pool in the second backend storage system; Before synchronizing the resource files corresponding to the stateful application to the second cluster, the method further includes: Configuring a storage field in a declaration file corresponding to the stateful application as the second storage pool; the storage field is used to specify a storage location for the application data; After determining the storage pool bound to the stateful application in the backend storage system corresponding to the first cluster, the method further includes: A mapping relationship is established between the first storage pool and the second storage pool through the API interface of the first backend storage system to synchronize application data corresponding to the stateful application stored in the first storage pool to the second storage pool.

2. The cross-cluster backup method for stateful applications according to claim 1, characterized in that: The establishing a mapping relationship between the first storage pool and the second storage pool through the API interface of the first back-end storage system specifically includes: Determine a network communication topology relationship between all back-end storage systems; the network communication topology relationship includes a network communication connection relationship between the first back-end storage system and the second back-end storage system; Synchronize the application data corresponding to the stateful application stored in the first storage pool to the second backend storage system through the API interface of the first backend storage system; Relevant information of the second storage pool selected by the second back-end storage system is received through the API interface of the first back-end storage system, so as to establish a mapping relationship between the first storage pool and the second storage pool.

3. The cross-cluster backup method for stateful applications according to any one of claims 1-2, characterized in that: The cross-cluster backup method for stateful applications further includes: Monitoring the resource files corresponding to the stateful application; In response to a change in content of a resource file corresponding to the stateful application, the changed resource file corresponding to the stateful application is synchronized to the second cluster.

4. The cross-cluster backup method for stateful applications according to claim 3, characterized in that: The monitoring of the resource file corresponding to the stateful application includes: Establishing a persistent connection with the API-Server component in the first cluster; Monitor the change event of the resource file corresponding to the stateful application through the persistent connection to determine whether the content of the resource file corresponding to the stateful application has changed; or, The API-Server component in the first cluster is periodically accessed to obtain resource files corresponding to the stateful application, so as to proactively detect whether the resource files corresponding to the stateful application have changed.

5. A cross-cluster backup system for stateful applications, characterized in that: The system is deployed in a first cluster, and the cross-cluster backup system for stateful applications includes: a first binding unit configured to parse a declaration file corresponding to the stateful application to be backed up deployed in the first cluster to determine a storage pool bound to the stateful application in a backend storage system corresponding to the first cluster; a synchronization unit configured to synchronize resource files corresponding to the stateful application to a second cluster, so as to deploy an application copy of the stateful application in the second cluster; wherein the resource files include the declaration file; a second binding unit configured to bind the application copy to a storage pool for storing application data in a backend storage system corresponding to the second cluster according to the content of the declaration file corresponding to the application copy; The first cluster corresponds to a first backend storage system, the second cluster corresponds to a second backend storage system, the stateful application corresponds to a first storage pool in the first backend storage system, and the application replica corresponds to a second storage pool in the second backend storage system; Before synchronizing the resource files corresponding to the stateful application to the second cluster, the method further includes: Configuring a storage field in a declaration file corresponding to the stateful application as the second storage pool; the storage field is used to specify a storage location for the application data; After determining the storage pool bound to the stateful application in the backend storage system corresponding to the first cluster, the method further includes: A mapping relationship is established between the first storage pool and the second storage pool through the API interface of the first backend storage system to synchronize application data corresponding to the stateful application stored in the first storage pool to the second storage pool.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the cross-cluster backup method for stateful applications according to any one of claims 1 to 4 is implemented.

7. An electronic device, characterized in that: include: A memory, a processor, and a program stored in the memory and executable on the processor, wherein when the processor executes the program, the cross-cluster backup method for a stateful application according to any one of claims 1 to 4 is implemented.

Citation Information

Patent Citations

  • Migration method of local storage of cloud computing, computer equipment and storage medium

    CN112035062A

  • State controller running in a kubernetes system and method for operating same

    CN113366802A