A method, apparatus, device, and medium for cross-cluster data migration

Abstract

This application relates to the field of data storage technology, and discloses a method, apparatus, device, and medium for cross-cluster data migration. The method involves backing up metadata corresponding to each namespace in the source cluster to a designated storage area; backing up business data based on the volumes mounted on pods under each namespace and their mapping information; and restoring the basic resources corresponding to the metadata on the destination cluster sequentially based on the resource dependencies contained in the metadata when the metadata recorded in the storage area meets the data restoration conditions. The volume containing the business data is then mounted on a pod in the destination cluster according to the mapping information. With the business data recorded on the volume, mounting the volume on the corresponding pod in the destination cluster completes the business data migration. This method utilizes third-party migration tools to quickly complete data migration from the source cluster to the destination cluster, eliminating the need for users to follow migration manuals for cross-cluster migration and reducing the difficulty of cross-cluster data migration.

Description

Technical Field

[0001] This application relates to the field of data storage technology, and in particular to a method, apparatus, device and computer-readable storage medium for cross-cluster data migration. Background Technology

[0002] Containers have become a popular technology in recent years. Developers can package applications into a portable container and then deploy it on any popular Linux machine, thus achieving virtualization. Containers use a sandbox mechanism, making them easy to run on machines and in data centers. They are independent of any language, framework, or system, making them the preferred choice for many service programs in Linux systems. However, when a server in a service cluster fails, it can cause serious data loss or even network failure. Furthermore, when a server needs to be replaced, cluster migration is required.

[0003] Data is of paramount importance to customers, and there are numerous cases of financial loss due to data loss. Therefore, users are paying increasing attention to data backup and migration functions. How to migrate data completely and securely to the target cluster is also a function that users are increasingly concerned about.

[0004] Current container cross-cluster migration technologies require users to perform cross-cluster migrations according to migration manuals. The entire migration process requires a lot of manual intervention, and the operation steps are complex, the process is lengthy, and the requirements for users' business expertise are also relatively high.

[0005] It is evident that reducing the difficulty of cross-cluster data migration is a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0006] The purpose of this application is to provide a method, apparatus, device, and computer-readable storage medium for cross-cluster data migration, which can reduce the difficulty of cross-cluster data migration.

[0007] To address the aforementioned technical problems, embodiments of this application provide a cross-cluster data migration method, comprising:

[0008] Back up the metadata corresponding to each namespace in the source cluster to the designated storage area;

[0009] Based on the volumes and mapping information already mounted on the pods under each namespace, perform backups of business data;

[0010] If the metadata recorded in the storage area is detected to meet the data restoration conditions, the basic resources corresponding to the metadata are restored sequentially on the target cluster according to the resource dependencies contained in the metadata.

[0011] Based on the mapping information, the volume containing the business data is mounted in the pod of the target cluster to complete the migration of the business data.

[0012] Optionally, backing up the metadata corresponding to each namespace in the source cluster to a designated storage area includes:

[0013] Read the resources contained in each namespace from the source cluster;

[0014] The metadata corresponding to each resource is merged and uploaded to the designated storage area.

[0015] Optionally, before backing up the metadata corresponding to each namespace in the source cluster to the designated storage area, the method further includes:

[0016] Interfaces are pre-configured to match different storage methods; wherein, the interfaces include object storage interface, file storage interface and block storage interface;

[0017] Accordingly, merging and uploading the metadata corresponding to each of the resources to the designated storage area includes:

[0018] Call the interface that matches the type of the storage area to merge and upload the metadata corresponding to each resource to the storage area.

[0019] Optionally, the backup of business data based on the volumes and mapping information already mounted on the pods under each namespace includes:

[0020] Obtain the mounted volumes and mapping information on the pods under each of the aforementioned namespaces;

[0021] Based on the mapping information, obtain the corresponding business data, compress the business data, and save it to the storage area.

[0022] Optionally, when the metadata recorded in the storage area is detected to meet the data restoration conditions, restoring the basic resources corresponding to the metadata on the target cluster according to the resource dependencies contained in the metadata includes:

[0023] Determine whether there is metadata to be processed in the storage area;

[0024] If there is metadata to be processed in the storage area, the metadata to be processed is read from the storage area;

[0025] Based on the resource types and resource order of the metadata records to be processed, basic resources are created sequentially on the target cluster.

[0026] Optionally, it also includes:

[0027] After the creation of the basic resources is completed, the metadata to be processed is deleted from the storage area.

[0028] Optionally, the step of mounting the volume containing the business data into the pod of the target cluster based on the mapping information to complete the migration of the business data includes:

[0029] Inject an initialization container into the target pod of the target cluster;

[0030] Obtain the business data recorded in the storage area, and establish a mapping relationship between the volume to which the business data belongs and the destination pod based on the mount relationship of the volume and pod recorded in the mapping information.

[0031] This application embodiment also provides a cross-cluster data migration device, including a metadata backup unit, a business data backup unit, a metadata restoration unit, and a business data restoration unit;

[0032] The metadata backup unit is used to back up the metadata corresponding to each namespace in the source cluster to a designated storage area.

[0033] The business data backup unit is used to back up business data based on the volumes mounted on the pods under each namespace and the mapping information.

[0034] The metadata restoration unit is used to restore the basic resources corresponding to the metadata on the target cluster in sequence, based on the resource dependencies contained in the metadata, when it is detected that the metadata recorded in the storage area meets the data restoration conditions.

[0035] The business data restoration unit is used to mount the volume containing the business data into the pod of the target cluster according to the mapping information, so as to complete the migration of the business data.

[0036] Optionally, the metadata backup unit includes a reading subunit and an uploading subunit;

[0037] The reading subunit is used to read the resources contained in each namespace from the source cluster;

[0038] The upload subunit is used to merge and upload the metadata corresponding to each resource to the designated storage area.

[0039] Optionally, a setting unit is included before backing up the metadata corresponding to each namespace in the source cluster to the set storage area;

[0040] The setting unit is used to pre-set interfaces that match different storage methods; wherein, the interfaces include object storage interface, file storage interface and block storage interface;

[0041] Accordingly, the upload subunit is used to call an interface that matches the type of the storage area to merge and upload the metadata corresponding to each resource to the storage area.

[0042] Optionally, the business data backup unit includes an acquisition subunit and a storage subunit;

[0043] The acquisition subunit is used to acquire the volumes and mapping information that have been mounted on the pods under each namespace;

[0044] The storage subunit is used to obtain the corresponding business data based on the mapping information, compress the business data, and save it to the storage area.

[0045] Optionally, the metadata restoration unit includes a judgment subunit, a reading subunit, and a creation subunit;

[0046] The judgment subunit is used to determine whether there is metadata to be processed in the storage area;

[0047] The reading subunit is configured to read the metadata to be processed from the storage area if the storage area contains metadata to be processed.

[0048] The creation subunit is used to sequentially create basic resources on the target cluster according to the resource types and resource order of the metadata records to be processed.

[0049] Optionally, it also includes a deletion unit;

[0050] The deletion unit is used to delete the metadata to be processed from the storage area after the creation of the basic resource is completed.

[0051] Optionally, the business data restoration unit includes an injection subunit, an acquisition subunit, and an establishment subunit;

[0052] The injection subunit is used to inject an initialization container into the target pod of the target cluster.

[0053] The acquisition subunit is used to acquire business data recorded in the storage area;

[0054] The establishment subunit is used to establish a mapping relationship between the volume to which the business data belongs and the destination pod based on the mount relationship of the volume and pod recorded in the mapping information.

[0055] This application also provides an electronic device, including:

[0056] Memory, used to store computer programs;

[0057] A processor for executing the computer program to implement the steps of the cross-cluster data migration method described above.

[0058] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the cross-cluster data migration method described above.

[0059] As can be seen from the above technical solution, the metadata corresponding to each namespace in the source cluster is backed up to the designated storage area; business data is backed up based on the volumes mounted on the pods under each namespace and the mapping information. When the metadata recorded in the storage area meets the data restoration conditions, the basic resources corresponding to the metadata are restored sequentially on the destination cluster according to the resource dependencies contained in the metadata. The volumes containing the business data are mounted on the pods of the destination cluster according to the mapping information. With the business data recorded on the volumes and the volumes mounted on the corresponding pods of the destination cluster, the migration of business data is completed. At this point, the pods based on the target cluster can access the business data. This technical solution relies on third-party migration tools to quickly complete the data migration from the source cluster to the destination cluster. It uses namespaces as the smallest processing unit for the migration of metadata and business data, making it suitable for scenarios involving multiple namespaces or the entire cluster backup. Following the set migration logic, when the metadata meets the data restoration conditions, the migration of metadata and business data to the destination cluster can be completed automatically. The operation is simple, error-free, and highly efficient. Users no longer need to perform cross-cluster migrations according to migration manuals, reducing the difficulty of cross-cluster data migration. Attached Figure Description

[0060] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 A flowchart illustrating a cross-cluster data migration method provided in this application embodiment;

[0062] Figure 2 A schematic diagram illustrating a metadata backup method provided in an embodiment of this application;

[0063] Figure 3 A schematic diagram illustrating a business data backup method provided in an embodiment of this application;

[0064] Figure 4 This is a schematic diagram illustrating the restoration of metadata on a target cluster, as provided in an embodiment of this application.

[0065] Figure 5 This is a schematic diagram illustrating the restoration of service data on a target cluster, provided as an embodiment of this application.

[0066] Figure 6 A schematic diagram illustrating cluster interaction during a data migration process, provided as an embodiment of this application;

[0067] Figure 7 This is a schematic diagram of the structure of a cross-cluster data migration device provided in an embodiment of this application;

[0068] Figure 8 This is a structural diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0069] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0070] The terms “comprising” and “having” in the specification, claims, and accompanying drawings of this application, and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may include steps or units not listed.

[0071] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0072] Next, a cross-cluster data migration method provided by the embodiments of this application will be described in detail. Figure 1 A flowchart of a cross-cluster data migration method provided in this application embodiment, the method including:

[0073] S101: Back up the metadata corresponding to each namespace in the source cluster to the designated storage area.

[0074] In this embodiment, data migration can be performed using a namespace as the smallest processing unit. This method has a wide range of applications, meets diverse customer needs, and is suitable for scenarios involving the migration of large amounts of data.

[0075] Different namespaces contain different types of resources, and each namespace records fields corresponding to these resources. For example, the resource types contained in a namespace can include pods, configmaps, PVCs, services, etc.

[0076] In practice, resources contained in each namespace can be read from the source cluster; the metadata corresponding to each resource can be merged and uploaded to the designated storage area.

[0077] The storage area can be the local storage of the migration tool or third-party storage. Third-party storage refers to storage space independent of the migration tool. In this embodiment, the location of the storage area is not limited.

[0078] In practice, different software modules can be deployed on the migration tool to accommodate different functions. For example, a backup monitoring module can be set up for the backup function.

[0079] Figure 2 This is a schematic diagram illustrating a metadata backup method provided in an embodiment of this application. Figure 2 In Kubernetes, K8S refers to the source cluster. Figure 2 The example uses two namespaces, namespace1 and namespace2, each containing five types of resources: pod, configmap, pvc, service, and workload. It should be noted that... Figure 2 The resource types included in the namespaces are for illustrative purposes only. In actual applications, different namespaces may contain more or fewer resource types, which is not limited here. The migration tool deploys a controller, a backup listening module, and an upload module (BSL). The BSL is used to upload backed-up data to the storage area. For metadata backup, the process involves the controller calling the backup to read the resources contained in each namespace from the source cluster, and then calling the BSL to merge the metadata corresponding to each resource and upload it to the designated storage area. Figure 2 The storage area set by the lieutenant general is called the destination storage.

[0080] S102: Back up business data based on the volumes and mapping information mounted on the pods under each namespace.

[0081] Each namespace contains pods. Pod resources are the smallest scheduling unit in a Kubernetes cluster. Applications run as containers, thus achieving containerization. As a container orchestration tool, the Kubernetes cluster manages pod resources.

[0082] However, business data is not directly recorded on the pod, but stored on a volume (LUN). By mounting the volume on the pod, the business data can be retrieved.

[0083] Therefore, in practical applications, when backing up business data, you can first obtain the mounted volumes and mapping information on the pods under each namespace.

[0084] The mapping information includes the mount relationships between volumes and pods, as well as the storage paths for business data. Based on the storage paths, business data from the source cluster can be retrieved, compressed, and then saved to the storage area.

[0085] Figure 3 This is a schematic diagram of a business data backup provided in an embodiment of this application. A business data processing module (restic) can be deployed on the migration tool. The restic is mainly used to process business data, including operations such as backup and restore of business data. Figure 3 In Kubernetes (K8S), the host refers to the source cluster. For business data backup, the process involves the controller retrieving the mounted volumes and mapping information from the pods in the source cluster. The mapping device contains the mount information for both the pods and volumes. The controller can then call Restic to read business data from the source cluster, and BSL (Balanced Storage Service) will compress the data and save it to the storage medium.

[0086] S103: If the metadata recorded in the storage area is found to meet the data restoration conditions, the basic resources corresponding to the metadata are restored sequentially on the target cluster according to the resource dependencies contained in the metadata.

[0087] In practice, it can be determined whether there is metadata to be processed in the storage area. If there is no metadata to be processed in the storage area, it means that there is no need for data migration at present, and monitoring of the storage area can continue.

[0088] If there is metadata to be processed in the storage area, it indicates that there is a need for data migration. At this time, the metadata to be processed can be read from the storage area; according to the resource types and resource order of the metadata to be processed, the basic resources are created on the target cluster in sequence.

[0089] To avoid duplicate migrations of the same metadata, pending metadata can be deleted from the storage area after the basic resources are created. Alternatively, a processed marker can be set for metadata that has already been migrated, thus preventing duplicate processing of the same metadata.

[0090] Figure 4This is a schematic diagram illustrating the restoration of metadata on a target cluster, as provided in an embodiment of this application. A restore module can be deployed on the migration tool. Figure 4 In Kubernetes (K8S), "restore" refers to the destination cluster. Taking the order of namespace, PVC, workload, and service as an example, in the specific implementation, the controller can call `restore` to monitor metadata in the storage area. If there is metadata to be processed in the storage area, the namespace, PVC, workload, and service can be restored sequentially on the destination cluster. Restoration means recreating the same resources on the destination cluster as the source cluster. Figure 4 The backup and BSL mentioned above are functional modules called by the controller during metadata backup. For their specific processing flow, please refer to [link / reference]. Figure 2 The details of its introduction will not be repeated here.

[0091] S104: Based on the mapping information, mount the volume containing the business data to the pod in the target cluster to complete the migration of the business data.

[0092] Based on the mapping information, it can be determined which pod the volume containing the business data is mounted on. By mounting the volume on the pod of the target cluster, it can be ensured that the target cluster can access the business data, thus guaranteeing the availability of the data on the target cluster.

[0093] In the specific implementation, an initialization container can be injected into the target pod of the target cluster; the business data recorded in the storage area can be obtained, and the mapping relationship between the volume to which the business data belongs and the target pod can be established based on the mount relationship between the volume and the pod recorded in the mapping information.

[0094] Figure 5 This is a schematic diagram illustrating the restoration of business data on a target cluster, as provided in an embodiment of this application. The restoration of business data can be achieved by calling restic. The controller can automatically detect the mount path of the data to be restored through backup resources. It injects an initialization container (initContainer) into the pod to which the business container containing the business data to be restored belongs to start data restoration. It calls restic to obtain the business data in the storage medium and copies it to the detected mount path, thereby completing the migration of business data.

[0095] In this embodiment, the migration tool enables interaction with both the source and destination clusters. By backing up the metadata and business data on the source cluster, the migration tool can rebuild the same architecture on the destination cluster based on the backed-up metadata. Then, it adjusts the mount relationship of the volume containing the business data and mounts the volume on the pod of the destination cluster, ensuring that the destination cluster can access the business data, thus completing the data migration.

[0096] Figure 6 This illustration shows a cluster interaction during data migration, as provided in an embodiment of this application. The source cluster (source Kubernetes) and the destination cluster (destination Kubernetes) can migrate data using a migration tool. The migration tool can include a storage area for storing metadata and business data. Of course, the storage area can also be third-party storage; this is not limited. Backup and restoration of metadata can be implemented by the Velero module deployed on the migration tool, and backup and restoration of business data can be implemented by the Restic module deployed on the migration tool. In a specific implementation, the controller can call the Velero module to read the resources contained in each namespace from the source Kubernetes to obtain the metadata corresponding to each resource, thereby compressing and saving the metadata on local storage or third-party storage. After completing the metadata backup, Velero can issue a command to the Restic module to schedule the backup of business data. The Restic module will read the business data from the source Kubernetes and save the business data and its corresponding directory. For ease of distinction, the directory recorded on the storage area can be called the backup directory. This directory records the mount relationships of volumes and pods.

[0097] When restoring metadata, the Velero module can read metadata from local or third-party storage and then restore the basic resources sequentially on the target Kubernetes node according to the order of the resources recorded in the metadata. When restoring business data, the recovery process can be initiated by modifying the pod metadata and injecting an initContainer into the pod. Since the pod has already been created on the target Kubernetes node during the metadata restoration phase, the business data can be read from the specified directory of the pod and mounted onto the corresponding pod on the target Kubernetes node during business data restoration.

[0098] As can be seen from the above technical solution, the metadata corresponding to each namespace in the source cluster is backed up to the designated storage area; business data is backed up based on the volumes mounted on the pods under each namespace and the mapping information. When the metadata recorded in the storage area meets the data restoration conditions, the basic resources corresponding to the metadata are restored sequentially on the destination cluster according to the resource dependencies contained in the metadata. The volumes containing the business data are mounted on the pods of the destination cluster according to the mapping information. With the business data recorded on the volumes and the volumes mounted on the corresponding pods of the destination cluster, the migration of business data is completed. At this point, the pods based on the target cluster can access the business data. This technical solution relies on third-party migration tools to quickly complete the data migration from the source cluster to the destination cluster. It uses namespaces as the smallest processing unit for the migration of metadata and business data, making it suitable for scenarios involving multiple namespaces or the entire cluster backup. Following the set migration logic, when the metadata meets the data restoration conditions, the migration of metadata and business data to the destination cluster can be completed automatically. The operation is simple, error-free, and highly efficient. Users no longer need to perform cross-cluster migrations according to migration manuals, reducing the difficulty of cross-cluster data migration.

[0099] In this embodiment of the application, in order to meet the storage requirements of different storage methods, interfaces that match different storage methods can be pre-configured.

[0100] Common storage methods include object storage, file storage, and block storage; therefore, the interfaces set can include object storage interfaces, file storage interfaces, and block storage interfaces.

[0101] Taking metadata backup as an example, in practical applications, an interface matching the type of storage area can be called to merge and upload the metadata corresponding to each resource to the storage area.

[0102] By setting up various types of interfaces, different storage needs can be met, so that data storage is no longer limited to object storage.

[0103] Figure 7 A schematic diagram of a cross-cluster data migration device provided in this application embodiment includes a metadata backup unit 71, a business data backup unit 72, a metadata restoration unit 73, and a business data restoration unit 74;

[0104] Metadata backup unit 71 is used to back up the metadata corresponding to each namespace in the source cluster to the designated storage area;

[0105] In this embodiment, a namespace can be used as the smallest processing unit for data migration. This method has a wide range of applications, meets diverse customer needs, and is suitable for scenarios involving large-scale data migration. Alternatively, workloads or releases can also be used as the processing unit for data migration.

[0106] The storage area can be the local storage of the migration tool or third-party storage. Third-party storage refers to storage space independent of the migration tool. In this embodiment, the location of the storage area is not limited.

[0107] Business data backup unit 72 is used to back up business data based on the volumes mounted on the pods under each namespace and the mapping information.

[0108] Metadata restoration unit 73 is used to restore the basic resources corresponding to the metadata on the target cluster in sequence according to the resource dependencies contained in the metadata when the metadata recorded in the storage area meets the data restoration conditions.

[0109] The business data restoration unit 74 is used to mount the volume containing the business data to the pod in the target cluster based on the mapping information, so as to complete the migration of the business data.

[0110] Optionally, the metadata backup unit includes a read subunit and an upload subunit;

[0111] The read sub-unit is used to read the resources contained in each namespace from the source cluster;

[0112] The upload sub-unit is used to merge and upload the metadata corresponding to each resource to the designated storage area.

[0113] Optionally, a setup unit is included before backing up the metadata corresponding to each namespace in the source cluster to the designated storage area;

[0114] The configuration unit is used to pre-configure interfaces that match different storage methods; the interfaces include object storage interface, file storage interface and block storage interface.

[0115] Correspondingly, the upload sub-unit is used to call the interface that matches the type of the storage area to merge and upload the metadata corresponding to each resource to the storage area.

[0116] Optionally, the business data backup unit includes an acquisition subunit and a storage subunit;

[0117] The sub-unit is used to retrieve the mounted volumes and mapping information on pods under each namespace;

[0118] The storage sub-unit is used to obtain the corresponding business data based on the mapping information, compress the business data, and save it to the storage area.

[0119] Optionally, the metadata restoration unit includes a judgment subunit, a reading subunit, and a creation subunit;

[0120] The judgment sub-unit is used to determine whether there is metadata to be processed in the storage area;

[0121] The read sub-unit is used to read the metadata to be processed from the storage area if the metadata to be processed exists in the storage area;

[0122] Create sub-units to sequentially create basic resources on the target cluster based on the resource types and resource order of the metadata records to be processed.

[0123] Optionally, it also includes a deletion unit;

[0124] The deletion unit is used to remove pending metadata from the storage area after the creation of the underlying resources is complete.

[0125] Optionally, the business data restoration unit includes an injection subunit, an acquisition subunit, and a creation subunit;

[0126] The injection subunit is used to inject the initialization container into the target pod in the target cluster;

[0127] The acquisition sub-unit is used to retrieve business data recorded in the storage area;

[0128] A sub-unit is created to establish the mapping relationship between the volume to which the business data belongs and the destination pod, based on the mount relationship of the volume and pod recorded in the mapping information.

[0129] Figure 7 For a description of the features in the corresponding embodiments, please refer to Figure 1 The relevant descriptions of the corresponding embodiments will not be repeated here.

[0130] As can be seen from the above technical solution, the metadata corresponding to each namespace in the source cluster is backed up to the designated storage area; business data is backed up based on the volumes mounted on the pods under each namespace and the mapping information. When the metadata recorded in the storage area meets the data restoration conditions, the basic resources corresponding to the metadata are restored sequentially on the destination cluster according to the resource dependencies contained in the metadata. The volumes containing the business data are mounted on the pods of the destination cluster according to the mapping information. With the business data recorded on the volumes and the volumes mounted on the corresponding pods of the destination cluster, the migration of business data is completed. At this point, the pods based on the target cluster can access the business data. This technical solution relies on third-party migration tools to quickly complete the data migration from the source cluster to the destination cluster. It uses namespaces as the smallest processing unit for the migration of metadata and business data, making it suitable for scenarios involving multiple namespaces or the entire cluster backup. Following the set migration logic, when the metadata meets the data restoration conditions, the migration of metadata and business data to the destination cluster can be completed automatically. The operation is simple, error-free, and highly efficient. Users no longer need to perform cross-cluster migrations according to migration manuals, reducing the difficulty of cross-cluster data migration. Figure 8 A structural diagram of an electronic device provided in an embodiment of this application, such as... Figure 8 As shown, the electronic device includes: a memory 20 for storing computer programs;

[0131] The processor 21 is used to execute computer programs to implement the steps of the cross-cluster data migration method as described in the above embodiments.

[0132] The electronic devices provided in this embodiment may include, but are not limited to, smartphones, tablets, laptops, or desktop computers.

[0133] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0134] The memory 20 may include one or more computer-readable storage media, which may be non-transitory. The memory 20 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 20 is used to store at least the following computer program 201, which, after being loaded and executed by the processor 21, is capable of implementing the relevant steps of the cross-cluster data migration method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 20 may also include an operating system 202 and data 203, and the storage method may be temporary or permanent storage. The operating system 202 may include Windows, Unix, Linux, etc. The data 203 may include, but is not limited to, metadata, business data, etc.

[0135] In some embodiments, the electronic device may further include a display screen 22, an input / output interface 23, a communication interface 24, a power supply 25, and a communication bus 26.

[0136] Those skilled in the art will understand that Figure 8 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0137] It is understood that if the cross-cluster data migration method in the above embodiments is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes: USB flash drive, mobile hard drive, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk, or optical disk, and other media capable of storing program code.

[0138] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above-described cross-cluster data migration method.

[0139] The foregoing has provided a detailed description of a cross-cluster data migration method, apparatus, device, and computer-readable storage medium provided in the embodiments of this application. The various embodiments are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0140] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0141] The foregoing has provided a detailed description of a cross-cluster data migration method, apparatus, device, and computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of the invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of the invention. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of the invention, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A cross-cluster data migration method, characterized in that, include: Back up the metadata corresponding to each namespace in the source cluster to the designated storage area; Based on the volumes and mapping information already mounted on the pods under each namespace, perform backups of business data; If the metadata recorded in the storage area is detected to meet the data restoration conditions, the basic resources corresponding to the metadata are restored sequentially on the target cluster according to the resource dependencies contained in the metadata. Based on the mapping information, the volume containing the business data is mounted in the pod of the target cluster to complete the migration of the business data; The step of mounting the volume containing the business data into the pod of the target cluster based on the mapping information to complete the migration of the business data includes: Inject an initialization container into the target pod of the target cluster; Obtain the business data recorded in the storage area, and establish a mapping relationship between the volume to which the business data belongs and the destination pod based on the mount relationship of the volume and pod recorded in the mapping information.

2. The cross-cluster data migration method according to claim 1, characterized in that, The step of backing up the metadata corresponding to each namespace in the source cluster to the designated storage area includes: Read the resources contained in each namespace from the source cluster; The metadata corresponding to each resource is merged and uploaded to the designated storage area.

3. The cross-cluster data migration method according to claim 2, characterized in that, Before backing up the metadata corresponding to each namespace in the source cluster to the designated storage area, the following steps are also included: Interfaces are pre-configured to match different storage methods; wherein, the interfaces include object storage interface, file storage interface and block storage interface; Accordingly, merging and uploading the metadata corresponding to each of the resources to the designated storage area includes: Call the interface that matches the type of the storage area to merge and upload the metadata corresponding to each resource to the storage area.

4. The cross-cluster data migration method according to claim 1, characterized in that, The backup of business data based on the volumes and mapping information already mounted on the pods under each namespace includes: Obtain the mounted volumes and mapping information on the pods under each of the aforementioned namespaces; Based on the mapping information, obtain the corresponding business data, compress the business data, and save it to the storage area.

5. The cross-cluster data migration method according to claim 1, characterized in that, When the metadata recorded in the storage area is detected to meet the data restoration conditions, the basic resources corresponding to the metadata are restored sequentially on the target cluster according to the resource dependencies contained in the metadata, including: Determine whether there is metadata to be processed in the storage area; If there is metadata to be processed in the storage area, the metadata to be processed is read from the storage area; Based on the resource types and resource order of the metadata records to be processed, basic resources are created sequentially on the target cluster.

6. The cross-cluster data migration method according to claim 5, characterized in that, Also includes: After the creation of the basic resources is completed, the metadata to be processed is deleted from the storage area.

7. A cross-cluster data migration device, characterized in that, It includes a metadata backup unit, a business data backup unit, a metadata restoration unit, and a business data restoration unit; The metadata backup unit is used to back up the metadata corresponding to each namespace in the source cluster to a designated storage area. The business data backup unit is used to back up business data based on the volumes mounted on the pods under each namespace and the mapping information. The metadata restoration unit is used to restore the basic resources corresponding to the metadata on the target cluster in sequence, based on the resource dependencies contained in the metadata, when it is detected that the metadata recorded in the storage area meets the data restoration conditions. The business data restoration unit is used to mount the volume containing the business data into the pod of the target cluster according to the mapping information, so as to complete the migration of the business data. The business data restoration unit includes an injection subunit, an acquisition subunit, and an establishment subunit; The injection subunit is used to inject an initialization container into the target pod of the target cluster. The acquisition subunit is used to acquire business data recorded in the storage area; The establishment subunit is used to establish a mapping relationship between the volume to which the business data belongs and the destination pod based on the mount relationship of the volume and pod recorded in the mapping information.

8. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the cross-cluster data migration method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the cross-cluster data migration method as described in any one of claims 1 to 6.

Images