Method, apparatus and system for cache-based workload migration in a multi-cluster environment
The cache-based workload migration system with a two-stage restoration process addresses data loss and slow restoration speeds in Kubernetes multi-cluster environments, ensuring rapid and stable recovery with minimal downtime.
Patent Information
- Application Number
- KR1020240163396
- Authority / Receiving Office
- KR · KR
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2024-10-28
- Filing Date
- 2024-11-15
- Publication Date
- 2026-11-05
- Estimated Expiration
- 2044-11-15
AI Technical Summary
Existing methods for stateful workload migration in Kubernetes-based multi-cluster environments fail to address data loss, network complexity, and slow restoration speeds, leading to service interruptions and performance degradation.
A cache-based workload migration system with a two-stage restoration process, utilizing a cache member node for fast initial recovery and external storage for complete data integrity, ensuring service continuity through a transaction queue.
Minimizes service downtime and ensures rapid, stable workload restoration across multiple clusters, maintaining data integrity and service continuity during failures.
Smart Images

Figure 112024126091492-PAT00001_ABST
Abstract
Description
Technology Field
[0001] The present invention relates to a cache-based workload method, device, and system in a multi-cluster environment. Background Technology
[0002] Kubernetes is an open-source container orchestration platform that automates many of the manual processes involved in deploying, managing, and scaling containerized applications.
[0003] In a Kubernetes-based multi-cluster environment, workload migration issues can occur in various situations. For example, if a cluster experiences a surge in traffic or resource exhaustion, the workload in that cluster may not be handled properly, potentially leading to service failures.
[0004] Such failures can affect not only specific services but also other connected services, potentially causing performance degradation across the entire service. For Stateful workloads, which execute based on the context of previous transactions and where the current transaction is influenced by the circumstances of the previous transaction, simply migrating the workload is insufficient to resolve these issues.
[0005] Here, a transaction is a unit of work or a series of operations to perform a single logical function that changes the state of the database.
[0006] Stateful workloads must maintain data consistency and consider network configurations and complex connection dependencies, so they cannot use the previous methods of Stateless workloads, which have the characteristic of not storing information or references to existing past transactions.
[0007] Existing technologies have primarily focused on recovery for stateless workloads; while this can reduce service recovery times, it has not sufficiently addressed the issues of data loss and network complexity associated with stateful workloads.
[0008] Therefore, a method was proposed to periodically save backup files for stateful workloads to external storage and restore them in the event of a failure. However, this approach often lacked consideration for restoration time and frequently failed to account for pre-workload performance during the restoration process. This can lead to restoration time delays or data consistency issues, and limits its ability to prevent service interruptions in real time.
[0009] To address these issues, it is necessary to be able to rapidly migrate to another cluster in the event of a stateful workload failure, and a method is required to reduce recovery time while maintaining data integrity. Additionally, a mechanism is needed to maintain service continuity even during recovery.
[0010] In the event of service failures caused by traffic surges or resource exhaustion, failure recovery mechanisms for Stateless and Stateful workloads in single or multi-cluster environments have generally been presented in numerous papers.
[0011] The existing method involves creating a checkpoint file for the workload and saving it along with Kubernetes resources, and then restoring the workload's state using the checkpoint and backup files.
[0012] A checkpoint is an image or snapshot of a running container or individual application.
[0013] However, existing methods focused on recovery performance and lacked specific consideration for recovery speed. In particular, measures to preserve and restore the workload state in real time when a failure occurred were limited.
[0014] Some papers have used checkpoint methods and resource backup files in parallel to address these issues, but they still faced the limitation of slow restoration speeds. For example, for stateful workloads such as databases, maintaining data consistency during restoration is critical; however, existing studies suffered from the problem that it was difficult to prevent service interruptions during real-time restoration due to the lengthy restoration procedures for such workloads. Furthermore, existing methods primarily relied on a single restoration process and did not consider rapid service recovery through multi-stage restoration. Prior art literature
[0015] KR Published Patent 10-2024-0059525 The problem to be solved
[0016] To solve the problems of the aforementioned prior art, the present invention proposes a cache-based workload migration method, device, and system for a multi-cluster environment that enables rapid restoration to another cluster to prepare for performance degradation caused by network failures or resource shortages that may occur while operating microservices in one cluster. means of solving the problem
[0017] To achieve the above-mentioned purpose, according to one embodiment of the present invention, a cache-based workload migration system is provided, comprising: a plurality of member clusters operating workloads in a multi-cluster environment; and a management cluster built on a control plane on the cloud to distribute workloads to the plurality of member clusters, and in the event of a failure in a first workload of a first member cluster, to perform a first-stage restoration by reading a checkpoint of the first workload backed up on a cache member node of a second member cluster through a migration operator, and to perform a second-stage restoration by retrieving the latest backup file for the first workload stored in an external storage while ensuring the gradual inflow of transactions through a transaction queue.
[0018] It may include a scheduler that performs redeployment scheduling for a first workload failure at the cluster level; a workload backup controller that backs up resources within multiple member clusters in a Kubernetes environment to an external storage; and a workload restoration controller that utilizes backed-up data in a Kubernetes environment to restore resources within multiple member clusters to their original state or restore them to a new cluster.
[0019] The above migration operator can automate workload migration between clusters and ensure data consistency and service continuity.
[0020] The migration operator can generate a Cache Restore CR based on a predefined Custom Resource Definition (CRD) in the event of a failure in the first workload, and the workload restoration controller can detect the Cache Restore CR and periodically access the cache member node of the second member cluster to read the checkpoint of the first workload and perform a first-stage restoration.
[0021] The migration operator above can enable a two-stage restoration to be performed to create a restoration CR when it detects “Ready” in the progress status specification of the cache restoration CR.
[0022] When the workload recovery controller detects the recovery CR, it can perform a two-stage recovery by reading files periodically backed up from the external storage.
[0023] After the above 2-step restoration is completed, the transactions stored in the transaction queue can be processed sequentially.
[0024] The above failure refers to cases where performance degradation occurs due to network failures or resource shortages, and may include cluster-level failures or internal cluster workload-level failures.
[0025] According to another aspect of the present invention, a cache-based workload migration device is provided, comprising: a scheduler that manages the state of a plurality of member clusters operating a workload to perform cluster-level workload scheduling; a migration operator that, when a failure occurs in a first workload of a first member cluster among the plurality of member clusters, reads a checkpoint of the first workload backed up on a cache member node of a second member cluster to perform a first-stage restoration, and retrieves the latest backup file for the first workload stored in an external storage while ensuring the gradual inflow of transactions through a transaction queue to perform a second-stage restoration; a workload backup controller that backs up resources within a plurality of member clusters to an external storage in a Kubernetes environment; and a workload restoration controller that utilizes backed-up data in a Kubernetes environment to restore resources within a plurality of member clusters to their original state or restore them to a new cluster.
[0026] According to another aspect of the present invention, a method for transferring a cache-based workload in a multi-cluster environment through a management cluster built on a control plane on the cloud comprises the step of distributing a workload to a plurality of member clusters;
[0027] A cache-based workload migration method is provided, comprising the steps of: performing a first-stage restoration by reading a checkpoint of the first workload backed up on a cache member node of the second member cluster when a failure occurs in the first workload of the first member cluster, which is one of the plurality of member clusters; and performing a second-stage restoration by retrieving the latest backup file for the first workload stored in an external storage while ensuring the gradual inflow of transactions through a transaction queue. Effects of the invention
[0028] According to the present invention, there is an advantage in that workload transfer operations, which were previously performed only within a limited single cluster, can be efficiently performed even in a multi-cluster environment.
[0029] In addition, according to the present invention, when a failure occurs in the system, service downtime can be minimized through cache-based rapid first restoration, and there is an advantage of ensuring data integrity and complete state restoration through second-stage restoration.
[0030] Furthermore, according to the present invention, by utilizing a transaction queue, the service can continuously process transactions even during restoration, thereby ensuring service continuity. This enhances scalability and applicability across multiple clusters, and consequently, has the advantage of reducing failure recovery time at the cluster level and maximizing the stability and reliability of the service. Brief explanation of the drawing
[0031] FIG. 1 is a diagram illustrating a cache-based workload transfer system in a multi-cluster environment according to the present embodiment. FIG. 2 is a diagram illustrating the workload transfer process according to the present embodiment. FIG. 3 is a diagram illustrating a scenario prior to the occurrence of a failure situation according to the present embodiment. FIGS. 4 and 5 are drawings illustrating a restoration process in the event of a cluster-level failure according to the present embodiment. FIGS. 6 and 7 are drawings illustrating a two-stage restoration process when a workload level failure occurs within a cluster according to the present embodiment. Specific details for implementing the invention
[0032] The present invention is capable of various modifications and may have various embodiments, and specific embodiments are illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the invention to specific embodiments, and it should be understood that the invention includes all modifications, equivalents, and substitutions that fall within the spirit and scope of the invention.
[0033] The terms used herein are merely for describing specific embodiments and are not intended to limit the invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as “comprising” or “having” are intended to indicate the presence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.
[0034] Furthermore, the components of the embodiments described with reference to each drawing are not limited to the respective embodiments and may be implemented to be included in other embodiments within the scope of maintaining the technical spirit of the present invention. It is also obvious that multiple embodiments may be re-implemented as a single embodiment that integrates multiple embodiments, even if a separate description is omitted.
[0035] Furthermore, in the description referring to the attached drawings, identical components are assigned the same or related reference numerals regardless of drawing symbols, and redundant descriptions thereof are omitted. In describing the present invention, if it is determined that a detailed description of related prior art could unnecessarily obscure the essence of the present invention, such detailed description is omitted.
[0037] This embodiment proposes a method for rapidly migrating workloads to another cluster to prepare for performance degradation caused by network failures or resource shortages that may occur while operating microservices in one cluster in a multi-cluster environment. The workload migration according to this embodiment can be defined as cache-based backup and restoration.
[0038] The workload migration method according to the present embodiment consists of a first-stage restoration that utilizes the fast accessibility and high processing speed of the cache to perform an initial restoration at the infrastructure level by pre-saving the service's checkpoint and then quickly reading the checkpoint data from the cache, and a second-stage restoration that ensures complete data integrity through the backup and restoration of Kubernetes resources via external storage.
[0039] The first-stage restoration according to the present embodiment quickly restores the service state, minimizing system downtime and enabling immediate transaction acceptance.
[0040] Phase 2 restoration temporarily stores incoming transactions through a transaction queue and ensures service continuity even after Phase 1 restoration.
[0041] The transaction queue is used to prevent conflicts with two-phase restoration, and after the final restoration is completed, transactions stored in the transaction queue are processed sequentially to achieve complete service recovery. This enables rapid and stable workload restoration while minimizing service downtime.
[0043] FIG. 1 is a diagram illustrating a cache-based workload transfer system in a multi-cluster environment according to the present embodiment.
[0044] Referring to FIG. 1, the system according to the present embodiment may include a management cluster (100) and a plurality of member clusters (Member Clusters, 102-1 to 102-3, hereinafter referred to as '102').
[0045] The management cluster (100) is built on a control plane within the cloud, performs the deployment of applications to multiple member clusters (102), and manages multiple member clusters (102) that operate workloads in an integrated manner.
[0046] The scheduler (110) of the management cluster (100) manages the status of multiple member clusters (102) to perform cluster-level workload scheduling.
[0047] The Workload Backup Controller (112) is a component that automates and manages the task of backing up resources within a cluster in a Kubernetes environment and transferring the backed-up data to an external storage (150), and performs periodic backups of workloads running in multiple member clusters (102).
[0048] The Workload Backup Controller (114) is a component that supports restoring resources within a cluster to their original state or restoring them to a new cluster by utilizing backed-up data in a Kubernetes environment.
[0049] The workload restoration controller (114) performs a restoration after a backup of the workload running in each member cluster (102).
[0050] A plurality of member clusters (102) according to the present embodiment are provided with a distributed cache system (Cache Sharing System, 104) that performs the roles of cache-related collection, backup, and restoration.
[0051] The roles of cache-related collection, backup, and restoration of the distributed cache system (104) are performed by the cache member nodes (130) provided to each member cluster (102).
[0052] A cache management (116) that manages multiple cache member nodes (130) is deployed in the management cluster (102).
[0053] Additionally, a migration operator (118) that manages workload restoration according to the present embodiment is deployed in the management cluster (102).
[0054] A migration operator (118) is defined as a component that automates workload transfer operations between clusters and ensures data consistency and service continuity.
[0055] The APIserver (120) is a REST endpoint that communicates with all other components and is a core component of the control plane, serving as a central hub responsible for communication between the cluster manager and various components.
[0056] The API server (120) provides an API for multi-cluster management and stores and manages the status information of member clusters (102).
[0057] The service mesh control plane (122) creates and applies routing rules for traffic management and tracks and manages the location and status of services through service discovery. In addition, it can consistently control the operation of the entire service mesh by managing the configuration of the proxy sidecars for each service and transmitting necessary configuration information.
[0058] FIG. 2 is a diagram illustrating the workload transfer process according to the present embodiment.
[0059] Referring to FIG. 2, if performance degradation occurs due to network failure or resource shortage while operating a microservice workload deployed to a cluster, this is detected by the management cluster (100) (step 200).
[0060] Subsequently, it performs a workload migration function based on whether the failure is at the cluster level or the internal cluster workload level.
[0061] Redeployment scheduling of microservice workloads is performed depending on whether the failure is at the cluster level or at the workload level within the cluster (step 202).
[0062] A migration operator (118) of a management cluster (100) detects a rescheduled microservice workload and creates a Cache Restore CR based on a predefined Custom Resource Definition (CRD) (step 204).
[0063] The workload restoration controller (114) of the management cluster (100) detects a cache restoration CR and periodically reads checkpoints of microservice workloads backed up in the cache and performs a step 1 restoration on a newly created resource (step 206).
[0064] The migration operator (118) checks the progress status of the first stage restoration, and then the workload restoration controller (114) periodically reads backed-up files from the external storage (150) to perform the second stage restoration of the resource (step 208).
[0065] At the same time, after the first stage of restoration is completed, the inflow of transactions is gradually allowed to enable minimal service and sequentially store transactions in the transaction queue (step 210), and after full restoration is achieved, service continuity is ensured by sequentially processing transactions.
[0067] The following describes the scenario prior to the occurrence of the failure.
[0068] FIG. 3 is a diagram illustrating a scenario prior to the occurrence of a failure situation according to the present embodiment.
[0069] Referring to FIG. 3, a backup of the workload is periodically performed in an external storage (150) before a cluster failure occurs.
[0070] When deploying a workload to the cluster, a sidecar container (132) is also deployed to the member cluster (102), and the sidecar container (132) periodically creates checkpoints of the workload and stores them in the cache member node (130) (step 300).
[0071] The cache member nodes (130) of each member cluster (102) share data to back up each other's data (step 302).
[0072] At the same time, the backup file of the workload generated through the workload backup controller (112) in the management cluster (100) and the checkpoint file generated from the sidecar container (132) are stored together as a package in an external storage (150) (step 304).
[0073] Checkpoints stored in the cache member node (130) are stored in a manner that maintains one previous past and one latest, and when a new latest checkpoint is stored, the oldest checkpoint is deleted to reduce the cluster's resource usage.
[0074] FIGS. 4 and 5 are drawings illustrating a restoration process in the event of a cluster-level failure according to the present embodiment.
[0075] When a failure occurs at the cluster level, the cluster itself becomes problematic, affecting all running workloads and creating a situation where a rapid migration of workloads is required.
[0076] FIG. 4 is a diagram illustrating the process of transferring a workload distributed to the second member cluster (102-2) to the first member cluster (102-1).
[0077] When the management cluster (100) that checks the status of the member cluster (102) confirms that the status of the cluster is Fail, a failover process is executed in the control plane of the management cluster (100), and resource redistribution is performed by the scheduler (110) (step 400).
[0078] When resource redistribution is performed by the scheduler (110), there are resources whose state changes or is updated, and these include a resource containing state information of the cluster, a resource containing information about which member cluster (102) the resource has been distributed to, a resource containing information about which member cluster (102) the resource will be distributed to, and a resource managing a resource template to be actually distributed to the member cluster (102).
[0079] The migration operator (116) detects a resource whose state has changed or been updated by resource redistribution (step 402), and determines whether the detected resource is a previously distributed resource by verifying the location of the detected resource and comparing metadata (step 404).
[0080] Afterwards, a cache restore CR is created to request restoration from the workload restore controller (114) (step 406).
[0081] In step 406, the cache restore CR contains information about the target workload to be restored (checkpoint location, member cluster ID, workload metadata, etc.).
[0082] The workload recovery controller (114) detects the above-mentioned cache recovery CR and accesses the cache member node (130-1) of the first member cluster (102-1) to redeploy the workload, reads the checkpoint file, and performs a first-stage recovery (step 408).
[0083] The migration operator (116) according to the present embodiment checks the step 1 restoration progress status and updates the restoration progress status in the cache restoration CR (step 410).
[0084] When the migration operator (116) detects “Ready” in the progress status specification of the cache restore CR, it creates a restore CR to perform a two-stage restore (step 412).
[0085] In step 412, if the workload restore controller (114) detects a restore CR, it retrieves the most recent backup file of the target workload from external storage (150) and performs the restore.
[0086] In addition, as 410 is completed, the 2-stage restoration begins to be performed, and at the same time, transaction acceptance is gradually allowed.
[0087] Step 414 is the process of setting up a separate transaction queue for each service using a distributed cache system (104).
[0088] Here, transaction queues are distinguished using namespaces.
[0089] The migration operator (116) comprehensively checks the transaction queue status of all services (step 414).
[0090] In step 414, when the second stage of restoration of an individual service is completed, it is triggered (individual trigger) to automatically process it as an item in the transaction queue, and when the processing of the most recent transaction stored in the transaction queue is finished, the queue is released (individual service) and a restoration status notification is performed.
[0092] FIGS. 6 and 7 are drawings illustrating a two-stage restoration process when a workload level failure occurs within a cluster according to the present embodiment.
[0093] When a failure occurs at the workload level within the cluster, the issue lies with the workload in operation rather than the cluster itself. This can affect other workloads that reference and rely on the results of that workload for functionality, potentially causing performance degradation and necessitating the rapid migration of the workload. The procedure for this is as follows.
[0094] Referring to FIG. 6, redeployment scheduling for the failed target workload is performed internally by the API server inside the member cluster because a failure occurred within the cluster (step 600).
[0095] The migration operator (116) according to the present embodiment detects a resource whose state has changed or been updated by resource redistribution (step 602), and determines whether it is an existing resource by verifying the location of the created resource and comparing metadata (step 604).
[0096] Hereinafter, steps 606 to 614 are identical to steps 406 to 414 of FIG. 4, so a detailed description thereof is omitted.
[0097] The cache-based workload migration method in the aforementioned multi-cluster environment may also be implemented in the form of a recording medium containing computer-executable instructions, such as applications or program modules executed by a computer. A computer-readable medium may be any available medium accessible by a computer and includes both volatile and non-volatile media, as well as removable and indetachable media. Additionally, a computer-readable medium may include a computer storage medium. A computer storage medium includes both volatile and non-volatile, removable and indetachable media implemented by any method or technique for storing information, such as computer-readable instructions, data structures, program modules, or other data.
[0098] The embodiments of the present invention described above are disclosed for illustrative purposes only, and those skilled in the art with ordinary knowledge of the present invention may make various modifications, changes, and additions within the spirit and scope of the present invention, and such modifications, changes, and additions should be considered to fall within the scope of the following claims.
Claims
Claim 1 A cache-based workload migration system in a multi-cluster environment comprising: a plurality of member clusters operating a workload; and a management cluster built on a control plane in the cloud to distribute the workload to the plurality of member clusters, and, in the event of a failure in a first workload of a first member cluster, to create a Cache Restore CR by means of a predefined Custom Resource Definition (CRD) through a migration operator to read the checkpoint of the first workload backed up on the cache member node of a second member cluster to perform a first-stage restoration, and when a Ready state is detected in the progress status specification of the Cache Restore CR, to create a restoration CR, and to ensure the gradual inflow of transactions through a transaction queue while retrieving the latest backup file for the first workload stored in an external storage to perform a second-stage restoration, and when the second-stage restoration of an individual service constituting the first workload is completed, to process the transactions stored in the transaction queue of the corresponding service sequentially. Claim 2 A cache-based workload migration system according to claim 1, wherein the management cluster comprises: a scheduler that performs redeployment scheduling for a first workload failure at the cluster level; a workload backup controller that backs up resources within a plurality of member clusters in a Kubernetes environment to an external storage; and a workload restoration controller that utilizes backed-up data in a Kubernetes environment to restore resources within a plurality of member clusters to their original state or restore them to a new cluster. Claim 3 In paragraph 2, the migration operator is a cache-based workload migration system that automates workload migration between clusters and ensures data consistency and service continuity. Claim 4 In paragraph 3, the workload recovery controller detects the cache recovery CR and periodically accesses the cache member node of the second member cluster to read the checkpoint of the first workload and performs a first-stage recovery, thereby forming a cache-based workload transfer system. Claim 5 delete Claim 6 In paragraph 4, the workload recovery controller is a cache-based workload migration system that, when it detects the recovery CR, periodically reads a backed-up file from the external storage and performs a two-stage recovery. Claim 7 delete Claim 8 A cache-based workload transfer system according to claim 1, wherein the failure includes performance degradation due to network failure or resource shortage, and occurs at the cluster level or at the cluster internal workload level. Claim 9 A cache-based workload migration device comprising: a scheduler that manages the status of multiple member clusters operating a workload to perform cluster-level workload scheduling; a migration operator that generates a Cache Restore CR based on a predefined Custom Resource Definition (CRD) when a failure occurs in a first workload of a first member cluster among the multiple member clusters, and generates a restore CR when a Ready state is detected in the progress status specification of the Cache Restore CR; a workload backup controller that backs up resources within the multiple member clusters to an external storage in a Kubernetes environment; and a workload restoration controller that performs a first-stage restoration by reading the checkpoint of the first workload backed up on the cache member node of the second member cluster based on the Cache Restore CR, performs a second-stage restoration by retrieving the latest backup file for the first workload stored in the external storage while ensuring the gradual inflow of transactions through a transaction queue, and ensures that when the second-stage restoration of an individual service constituting the first workload is completed, the transactions stored in the transaction queue of the corresponding service are processed sequentially. Claim 10 In claim 9, the workload recovery controller detects the cache recovery CR and periodically accesses the cache member node of the second member cluster to read the checkpoint of the first workload and performs a first-stage recovery, a cache-based workload transfer device. Claim 11 delete Claim 12 In claim 10, the workload recovery controller is a cache-based workload transfer device that, when it detects the recovery CR, periodically reads a backed-up file from the external storage and performs a two-stage recovery. Claim 13 delete Claim 14 In claim 9, the above failure includes performance degradation due to network failure or resource shortage, and is a cache-based workload transfer device occurring at the cluster level or at the cluster internal workload level. Claim 15 A method for migrating a cache-based workload in a multi-cluster environment comprising a plurality of member clusters operating a workload through a management cluster built on a control plane in the cloud, comprising: a step of distributing the workload to the plurality of member clusters; a step of generating a Cache Restore CR by a predefined Custom Resource Definition (CRD) when a failure occurs in a first workload of a first member cluster, which is one of the plurality of member clusters; a step of performing a first-stage restoration by reading a checkpoint of the first workload backed up on a cache member node of a second member cluster based on the Cache Restore CR; a step of generating a restoration CR when a Ready state is detected in the progress status specification of the Cache Restore CR; a step of performing a second-stage restoration by retrieving the latest backup file for the first workload stored in an external storage while ensuring the gradual inflow of transactions through a transaction queue; and a step of sequentially processing transactions stored in the transaction queue of an individual service constituting the first workload when the second-stage restoration is completed.
Citation Information
Patent Citations
Multi-entity resource, security, and service management in edge computing deployments
KR1020210149576A
Method and system for instantiating and transparently migrating running containerized processes.
KR1020230051280A
Distributed cloud system, distributed cloud system data processing method and storage medium
KR1020230174150A
Distributed cloud system, distributed cloud system data processing method and storage medium
KR1020240059525A
