Edge computing-based computing power resource elastic scheduling method

Abstract

The application discloses an elastic scheduling method of computing power resources based on edge computing and belongs to the field of edge task migration and computing power resource scheduling. In view of the problem that when a previous elastic action is not closed and a next action has undertaken migration results, it is difficult to determine the effectiveness of the results and the resource scheduling qualification of the late resource release results, the supporting implementation of the migration results is determined, the late completion results of the previous action are received and the source attribution is maintained, and the resource state confirmed by the resource controller is inquired. According to the same resource state, the previous action relationship is closed and the supporting implementation of the next action undertaking results is reverified, the first batch of results that lose all effective support and have predecessors are determined as a reconstruction front, and only the reconstruction front and affected subsequent results are reconstructed. When the resources no longer support the remaining results, do not belong to the resources required for reconstruction and are in a distributable state, the scheduling qualification is restored, the use of unsupported results is avoided, and repeated reconstruction is reduced. The method is used for edge task migration redirection and fault recovery.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, and in particular to a method for elastic scheduling of computing resources based on edge computing. Background Technology

[0002] Existing edge computing-based elastic scheduling methods typically determine scaling up, scaling down, migration, and resource reallocation schemes for task instances based on task load, user location, processor and memory usage of edge nodes, accelerator availability, and network status. For stateful tasks, migration requires generating basic checkpoints, incremental states, cached data, or runtime contexts at the source edge node, transmitting these migration results to the target edge node, and releasing the processor, memory, accelerator, storage, and network resources occupied by the source edge node after the target instance completes state recovery and service takeover. Since edge node load and network conditions continuously change, the scheduling controller may change the original migration target based on the new resource status before the previous migration is complete, and continue to use some of the migration results already formed during the previous migration.

[0003] During the aforementioned continuous migration process, the scheduling controller typically transmits operation requests and completion results asynchronously with the node resource controller, device controller, storage controller, and network controller. If a previous elastic action has not yet closed, and a subsequent elastic action has already taken over part of the migration results from the previous elastic action, the resource release operation issued by the previous elastic action may have already been completed, but the corresponding completion result is only returned after the takeover relationship is formed. In this case, if the completion result is accepted directly, although the corresponding operation relationship in the previous elastic action can be closed, the released resources may still support the migration results taken over by the subsequent elastic action, and the subsequent elastic action may continue to use migration results that can no longer be read, recovered, or continued to execute. If the completion result is rejected because it belongs to the previous elastic action, the fact that the underlying resources have already been released cannot be changed, leading to inconsistencies between the scheduling records and the actual resource state. If the subsequent elastic action is waited for completion before unified processing, resources no longer used for migration result retention and reconstruction still need to be isolated. Therefore, it is evident that accepting, rejecting, or waiting for delayed completion results as a whole based on action generation makes it difficult to simultaneously determine the closed scope of the operational relationship in the previous flexible action, the effective scope of the migration results undertaken by the subsequent flexible action, and the scheduling eligibility of specific resource items. This can easily lead to the continued use of migration results without actual support, the repeated generation of still valid migration results, or the failure to promptly restore the scheduling eligibility of resources that no longer need to be isolated.

[0004] For example, CN111813502A predicts node load based on the processor and memory resource usage of containers in industrial edge nodes, and selects containers to be migrated and target nodes when the node load exceeds a set range, thereby achieving load adjustment between edge nodes; CN110187973A adjusts the deployment location of microservices based on the call relationships between microservices, edge server resources, and user requests; CN113452566A provides a unified description of computing, storage, and network resources in cloud nodes, edge nodes, and terminal nodes, and completes task-relationship matching based on user task requirements. These technologies can reselect deployment nodes and adjust resource allocation based on node load or task requirements. However, if the load, target node availability, or network status continuously changes, the migration or deployment plan may be adjusted again before completion. Because container runtime, device controllers, storage controllers, and network controllers typically perform resource operations and return results asynchronously, there may be a time lag between the task deployment relationships and migration status saved by the scheduler and the actual state of the underlying resources. At this point, if processing continues to be done on a per-migration, per-deployment, or per-resource-matching basis, the system struggles to promptly determine whether existing checkpoints, snapshots, caches, or runtime contexts still possess readable and recoverable actual resource carriers. It also struggles to determine whether deactivated processor, accelerator, storage, or network resources are still being used during the migration and recovery process. This can lead to migration results that have lost their actual resource support continuing to be used, still-valid migration results being repeatedly generated, or resources no longer required for migration and recovery tasks remaining in a reserved or isolated state. The root cause of these problems is that existing methods primarily generate new deployment or allocation results based on current load and task requirements, lacking continuous verification of the relationship between the availability of migration results during scheduling execution, changes in underlying actual resources, and resource reallocation conditions. Summary of the Invention

[0005] The technical problem this invention aims to solve is that existing edge computing resource scheduling methods, during continuous migration, struggle to accurately determine the availability of migrated resources when overlapping elastic actions occur and the resource operation results of the previous action are delayed. This leads to issues such as inconsistencies between scheduling records and actual resource status, duplicate generation of valid results, and failure to reschedule resources in a timely manner. To address this, we propose an edge computing-based elastic scheduling method for computing resources.

[0006] To achieve the above objectives, this application adopts the following technical solution: an elastic scheduling method for computing power resources based on edge computing, comprising: establishing a subsequent elastic action when the previous elastic action of the same task instance has not yet been closed; determining the partial migration results formed by the previous elastic action that are inherited by the subsequent elastic action; and determining, for each migration result, a supporting implementation that enables it to have at least one of the capabilities of reading, restoring, and continuing execution, wherein the supporting implementation includes a combination of resource states associated with the corresponding migration result; receiving the completion result of the resource release operation of the previous elastic action, wherein the completion result arrives after the subsequent elastic action establishes the inheritance relationship with the partial migration results; and querying the actual resource state of the resource items involved in the resource release operation, as confirmed by the corresponding resource controller. When the actual resource status indicates that the resource release operation has been completed, the corresponding resource release operation relationship in the previous elastic action is closed according to the same actual resource status, and the supporting implementation that requires the resource item to be in the pre-release state is determined to be invalid; according to the dependencies between each migration result, the migration results that have lost all effective supporting implementations and their affected subsequent migration results are determined, the migration results that still have effective supporting implementations are retained, and the migration results that have lost all effective supporting implementations and their affected subsequent migration results are reconstructed; for resource items that have been actually released, when the resource item no longer constitutes the effective supporting implementation of the retained migration results and is not a resource required for generation, recovery, and verification in the reconstruction process, the scheduling qualification of the resource item is restored.

[0007] The task instance is a stateful service instance, container instance, virtual machine instance, or function workflow instance that runs on an edge node and has a unique runtime identifier. The elastic action includes scaling up, scaling down, migration, migration rerouting, fault recovery, or resource reconfiguration processes performed on the task instance. Each elastic action establishes an independent action identifier. The previous elastic action and the subsequent elastic action belong to the same task instance, and the subsequent elastic action records the action identifier of the previous elastic action, thus forming a predecessor relationship.

[0008] The phrase "the previous flexible action has not yet been closed" refers to situations where the previous flexible action still contains incomplete, pending confirmation, execution blocked due to current resource relationships, or no final resolution result for migration operations, resource operations, or service takeover operations. Closure does not simply change the action status field to "completed," but rather signifies that all operational units included in the flexible action have reached a termination state where they are completed, canceled, rejected, or no longer executed, or where a subsequent flexible action provides a substitute result, and the relevant resource relationships have been closed accordingly.

[0009] The migration outcome is a state object formed during the execution of an elastic action and usable by subsequent migration, recovery, or service takeover processes. It includes at least one of the following: basic checkpoint, incremental state, storage snapshot, image layer, cache warm-up result, accelerator runtime context, memory-stabilized state, network session context, and service takeover state. The "acceptance" refers to the subsequent elastic action obtaining the right to read, recover, continue execution, or confirm the migration outcome after verifying that it meets the current recovery conditions. The acceptance relationship does not change the action that generated the migration outcome; the migration outcome still belongs to the preceding elastic action that generated it.

[0010] The support implementation refers to a set of resource states that enable the corresponding migration results to be actually read, restored, or continued to be executed within the specified recovery period, and is not simply a resource identifier, storage path, or upper-layer reference record. The resource state combination may include at least one of the following: file write complete state, content digest state, storage location online state, mount or read authorization state, device binding state, device runtime context existence state, target instance recovery state, network path takeover state, and resource controller state version, and is confirmed by the corresponding underlying resource controller.

[0011] The resource release operations include at least one of the following: release of computing resource quotas, memory reclamation, accelerator context clearing or device unbinding, storage volume unloading or detachment, network path disconnection, and stopping or destroying running instances. The resource release operation relationship is the execution relationship between the previous elastic action, the resource release operation, and the resource items involved, used to indicate whether the operation is still eligible for execution, whether a target state has been formed, and whether the relationship has been closed.

[0012] The actual resource status refers to the resource status confirmed by the node resource controller, device controller, storage controller, network controller, or running instance controller through operation-specific completion records, status transition logs, or current status queries, and is not replaced by the expected status in the scheduling database. Specifically, before closing the resource release operation relationship based on the actual resource status, the attribution relationship between the actual resource status change and the resource release operation is determined based on the operation identifier, operation token, unique resource runtime identifier, controller runtime cycle, or operation audit record; if the operation attribution cannot be confirmed, the resource release operation is set to pending verification, and the corresponding relationship is not directly closed.

[0013] Specifically, resource status changes confirmed by operational attribution are written into the consistent resource status, and the facts of remounting, reauthorization, rebinding, and replacement support formed after the resource status change are merged, and the relevant support implementations are re-verified. Determining a support implementation as invalid means that, in the latest consistent resource status after merging, at least one necessary resource status constituting the support implementation has been confirmed as invalid; when a resource was previously deactivated but later re-established a valid resource relationship that meets the recovery requirements, the current support is deemed invalid not only based on the historical deactivation facts.

[0014] The dependencies between migration outcomes include parent outcome relationships, state sequence relationships, and predecessor outcome relationships necessary for recovery. The affected subsequent migration outcomes are those that directly or indirectly depend on the failed migration outcomes and cannot be used for recovery alone due to the failure of their necessary predecessors. The reconstruction involves regenerating the failed migration outcomes from still valid and lineage-continuous predecessor migration outcomes, persistent input logs, or other verifiable recovery inputs, and continuing to generate the affected subsequent migration outcomes.

[0015] The scheduling eligibility refers to the state in which a resource item can be reinstated into the resource pool and allocated to the current task instance or other task instances. Physically releasing a resource does not automatically indicate scheduling eligibility; restoring scheduling eligibility also verifies that the resource item is not occupied by any valid elastic action, that the corresponding resource controller confirms it is in an allocable state, that it no longer constitutes support for retaining migration results, that it is not a resource required for the reconstruction process or the formation of alternative support, and that there are no pending operations or verification results that could change the state of the resource item.

[0016] Specifically, the edge computing system implementing the method includes a scheduling controller, source edge nodes, candidate target edge nodes, container or virtual machine runtimes, checkpointing and state transition components, node resource controllers, device controllers, storage controllers, network controllers, and persistent state storage. The scheduling controller collects task load, node resources, user location, link status, and target instance status, generates elastic actions, and issues resource control commands; the checkpointing and state transition components generate transition results; each resource controller completes resource allocation, status query, resource release, and operation effect confirmation; the persistent state storage saves action relationships, result relationships, supporting implementations, resource relationships, pending operations, and processed results. These components can be implemented using existing edge orchestration platforms, container runtimes, checkpointing tools, and resource plugins; this invention does not limit the specific software product.

[0017] Specifically, before entering the overlapping processing flow described in this invention, the edge computing system can complete source task status acquisition, candidate target node selection, target resource reservation, basic checkpoint generation, incremental status transmission, target instance startup, health check, and traffic switching according to existing migration methods. Only when the previous elastic action has not yet ended and environmental changes trigger the next elastic action, is the relationship between the preceding and following actions established, and partial migration result acceptance, support verification, delayed completion result processing, reconstruction, and resource qualification restoration performed.

[0018] Furthermore, the subsequent elastic action is triggered by at least one of the following: insufficient resources of the target node, abnormal migration path, failure to start the target instance, change of user location, change of task load, and partial failure of the previous elastic action; when establishing the subsequent elastic action, the action identifier of the previous elastic action, the generation identifier of the elastic action of the subsequent elastic action, the source node, the target node, the triggering reason, and the current execution stage of the previous elastic action are recorded.

[0019] The elastic action generation identifier is used to distinguish elastic actions established sequentially within the same task instance. It, together with the preceding action identifier, determines the action chain and is not used alone as the basis for rejecting or accepting late results. The execution phase includes at least one of the following: action generation, target resource reservation, basic state formation, incremental state synchronization, target instance startup, service qualification confirmation, traffic switching, source instance emptying, source resource release, and action closure. These phases are used to determine whether the migration result has been formed and whether resource release can still be prevented.

[0020] Furthermore, determining the migration results inherited by the subsequent elastic action includes: for each migration result formed by the previous elastic action, verifying the task instance identifier, task state generation identifier, result content summary, parent result relationship, state sequence continuity, target node hardware architecture, target node runtime environment, and migration result access conditions; determining the migration result that meets all verification conditions as the inherited result of the subsequent elastic action, and maintaining the generation action of the inherited result as the previous elastic action.

[0021] The separate verification refers to determining the verification conditions corresponding to the migration outcome type. For basic checkpoints, at least the task instance identifier, state generation, content integrity, and access conditions are verified; for incremental states, parent outcome relationships and state sequence continuity are also verified; for accelerator runtime contexts, device architecture, drivers, and runtime environment are also verified; for network session contexts, session sequence, address mapping, key status, and target instance takeover conditions are also verified. When a certain verification item is not applicable to a specific outcome type, a corresponding verification item that can prove the outcome can be recovered by the current target environment is used.

[0022] The task state generation identifier is used to distinguish the state sets before and after incompatible state changes of the same task instance; the parent result relationship represents the direct predecessor result upon which the incremental state, difference snapshot, or subsequent state depends; the state sequence continuity indicates that there are no missing, duplicated, or sequentially conflicting necessary state segments between the confirmed predecessor result and the current result; the migration result access conditions include the resource location being online, valid read or restore permissions, and the ability to obtain the result within the restore period.

[0023] Preferably, each of the supporting implementations consists of at least one necessary resource state; when all the necessary resource states are confirmed by the corresponding resource controller, and the content of the corresponding migration result is complete, the resource location is accessible, the access permission is valid, and the target operating environment compatibility requirements are met, the supporting implementation is determined as a valid supporting implementation; when only one valid supporting implementation remains after verifying all supporting implementations of a migration result, the valid supporting implementation is determined as the last valid supporting implementation of the migration result.

[0024] The necessary resource status refers to the resource facts that are indispensable for the corresponding support to achieve actual recovery capability. For different support types, the verification items in content integrity, resource location, access permissions, and operational compatibility are determined according to the support type; for active device contexts or network paths that do not contain file content, the device context existence status, session continuity status, and controller confirmation status are used as the corresponding integrity verification items.

[0025] Specifically, support implementations are managed using three states: valid, invalid, and pending verification. A support implementation is considered valid when all necessary resource states are confirmed as valid by the corresponding resource controller, and the deliverable content, deliverable lineage, task state generation, data format, target hardware and runtime environment, access permissions, and resource state observation timeliness all meet the corresponding requirements. A support implementation is considered invalid when any necessary resource state is confirmed as invalid. A support implementation is considered pending verification when the resource controller is unreachable, the state version cannot be compared, or multiple resource facts conflict.

[0026] When determining whether a supporting implementation is valid, it is also determined whether the supporting implementation can complete access and recovery within the allowed recovery period of the corresponding migration result. The recovery period is determined based on the allowed interruption time of the task, the migration stage, the size of the result, the transmission conditions, and the recovery requirements of the target instance; supporting implementations that are not expected to complete access and recovery within the recovery period are not considered as currently valid supporting implementations.

[0027] Before statistically analyzing the supporting implementations of the same migration outcome, duplicate records with identical outcome identifiers, unique runtime resource identifiers, content or status summaries, and necessary resource status combinations are merged. After merging, if a migration outcome has more than two valid supporting implementations, the failure of any one supporting implementation does not directly cause the migration outcome to fail; if only one valid supporting implementation remains, it is considered the last valid supporting implementation; if no valid supporting implementation exists, the validity of necessary predecessor migration outcomes is further considered to determine whether to proceed with the reconstruction process.

[0028] Preferably, before executing multiple resource release operations that have not yet been actually completed in the previous elastic action, the multiple resource release operations are formed into an operation set, and the joint resource state after the operation set is jointly executed is determined according to the target state of each resource release operation; when the fence value carried by each resource release operation is consistent with the current fence value of the corresponding resource item, and each of the undertaking results affected by the operation set still has at least one effective support realization in the joint resource state, the operation set is allowed to be executed; otherwise, the operation set is split, and resource release operations that are allowed to be executed, await the formation of equivalent alternative support, and are prevented from being executed are determined respectively.

[0029] The fence value is a control sequence number, lease identifier, or equivalent control credential that is updated as the resource control relationship is established or changed. The resource release request carries the request fence value obtained at the time of issuance. The resource controller or resource control adapter reads the current fence value before actual execution; if the two are inconsistent, it indicates that the resource control relationship corresponding to the request has changed, and the request will not be executed.

[0030] The joint resource state is determined based on the preconditions and execution dependencies between each resource release operation. First, the executable order is determined according to the input states required for the resource operations, the execution objects, and irreversible relationships. Then, the resource states formed after each resource release operation is sequentially deduced. Operations that have no preconditions and whose execution results do not affect each other can be deduced in parallel. If the precondition of any operation is not met in the previous state, the target state of that operation is not directly incorporated into the joint resource state, and the set of operations is re-split.

[0031] The set of operations affects various resulting outcomes, including those that directly utilize the resource items and those that are indirectly affected by the impact of necessary precursor outcomes. When determining the joint resource state, the resource state required for the reconstruction process and the formation of equivalent alternative support is also preserved to prevent multiple resource deactivation operations, each safe when executed individually, from eliminating all support for the same outcome upon joint execution.

[0032] Furthermore, when a resource release operation in the operation set would cause at least one inherited result to lose its last valid supporting implementation, a corresponding equivalent alternative supporting implementation is formed at least at one of the following: another storage location, the target device, the target instance, and an alternative network path. After the equivalent alternative supporting implementation completes at least one of the write, transfer, and restore operations corresponding to its type, and passes the verification of content integrity, result lineage, access permissions, and operational compatibility, the equivalent alternative supporting implementation is determined as a valid supporting implementation and the corresponding resource release operation is allowed to be executed. If no valid equivalent alternative supporting implementation is formed, the corresponding resource release operation is blocked.

[0033] The equivalent replacement support is matched to the type of the replaced migration result. Storage-type results form an integrity-verified copy in a storage location different from the original support; accelerator contexts form serialized files in persistent storage or recovery contexts on compatible target devices; runtime states are restored on the target instance; network sessions are taken over on the alternative network path. Issuing only write, transfer, or recovery operations, or forming only partial data, does not indicate that an equivalent replacement support has been formed.

[0034] Preferably, the completion result is maintained as belonging to the previous elastic action that generated the completion result; the same actual resource state is used as the basis for closing the corresponding resource release operation relationship in the previous elastic action, and the support implementation that no longer meets the necessary resource state in the result of the subsequent elastic action is determined as invalid, and the subsequent elastic action is not determined to have obtained alternative support implementation based on the completion result.

[0035] The source attribute, proof function, and resource status function of the completion result are determined respectively. The source attribute of the completion result is determined by the previous flexible action before the actual issuance operation; the completion result of the result formation type can be used to confirm the acceptance result to be confirmed in the next flexible action when the result content, lineage, generation, and access conditions meet the acceptance requirements; the physical or runtime changes confirmed by the completion result of the resource release type can make the support of the resource status before the release in the next flexible action invalid, but does not prove that the next flexible action has obtained another support.

[0036] Specifically, when it is confirmed that the actual resource state was formed by the resource release operation, operation attribution verification and physical completion verification are performed respectively. Operation attribution verification is used to confirm the association between the resource state change and the corresponding resource release operation based on the operation identifier, operation token, resource runtime unique identifier, operation-specific completion record, or controller audit record; physical completion verification is used to confirm that the resource state actually formed by the operation has reached the target state of the resource release operation, and that the relevant controller records belong to the same comparable runtime cycle or have a trusted operation-specific record that does not depend on version comparison.

[0037] After completing the above verification, determine whether the operation effect has been processed. For the operation effect confirmed for the first time, close the corresponding resource, release the operation relationship, and trigger the relevant supporting implementation to re-verify; for repeated completion results that have already been processed, only idempotent records are made, resource relationships are not closed again, reconstruction is not triggered again, and the resource occupation relationship established later for that resource item is not changed.

[0038] Preferably, the migration results dependency relationship is established according to the parent result relationship and state sequence between each migration result; the migration results that have lost all effective support for realization but whose necessary predecessor migration results still have effective support for realization are identified as the reconstruction frontier; the subsequent migration results that depend on the reconstruction frontier are identified along the migration results dependency relationship, the migration results that do not belong to the reconstruction frontier and its affected subsequent branches but still have effective support for realization are retained, and only the reconstruction frontier and its affected subsequent migration results are reconstructed.

[0039] The requirement that necessary precursor migration results remain valid means that the precursor result itself has at least one valid supporting realization, and the necessary precursor results traced back along its parent result relationship or state sequence are also valid, thus maintaining the continuity of the result lineage from the basic result to the current result. When there are no necessary precursor results for the basic result, its validity is determined solely based on the valid supporting realization of the basic result itself.

[0040] When determining the reconstruction frontier, the support state before the resource removal effect is written and the support state after the resource removal effect is written and the confirmed resource states formed later than this effect are merged are obtained respectively. By comparing the two states, it is determined which migration results changed from having at least one effective support realization to no longer having an effective support realization.

[0041] The first batch of migration results that had valid support before the resource removal effect was processed, lost all valid support after the processing, and whose necessary predecessor migration results are still valid in the latest resource state will be identified as the reconstruction frontier. The first batch of migration results refers to those whose necessary predecessors do not have migration results that have already been identified as reconstruction frontiers due to the same resource removal effect; subsequent migration results formed by direct or indirect dependence of the reconstruction frontier will be treated as affected subsequent branches and will not be re-identified as new reconstruction frontiers.

[0042] When the necessary precursor results have become invalid, subsequent results are not repeatedly used as new reconstruction frontiers, but are treated as affected subsequent results of the reconstruction frontier of the precursor. When multiple independent results meet the conditions simultaneously, multiple parallel reconstruction frontiers are formed. The reconstruction only includes regenerating the affected branches along the dependency relationship starting from the reconstruction frontier, without regenerating other results that still have effective support and are phylogeneticly continuous.

[0043] Furthermore, for each resource item, the resource release status, effective elastic action occupation status, retention migration result support status, reconstruction frontier resource demand status, equivalent alternative support formation status, and pending operation status confirmed by the corresponding resource controller are queried. When resource release has been completed, there is no effective elastic action occupation, it no longer constitutes effective support for retaining migration results, it is not a resource required for the generation, recovery, and verification of the reconstruction frontier and its affected subsequent migration results, there is no equivalent alternative support formation process using the resource item, and there are no pending operations that can change the status of the resource item, the scheduling qualification of the resource item is restored. The completion result that arrives after the scheduling qualification of the resource item and points to the closed resource occupation relationship is recorded idempotently, without re-establishing the resource occupation relationship based on the completion result.

[0044] Specifically, when restoring the scheduling eligibility of a resource item, the following statuses are comprehensively verified: the underlying controller has confirmed that the resource item has reached the release status of the corresponding resource type; the original resource relationship corresponding to the previous elastic action has been closed; the resource item is in an allocable state and is not in a fault, maintenance, repair, disabled, or node emptying state; there are no valid actions or tasks occupying the resource item; the resource item no longer constitutes valid support for retaining migration results; the resource item is not a resource required for the generation, restoration, or verification of the reconstruction frontier and affected subsequent results; the resource item has not been used to continue the formation process by equivalent replacement support; there are no pending operations or verification results that may change the status of the resource item.

[0045] The above conditions should be verified based on the same resource relationship version. Only when all conditions are met simultaneously will the resource item be restored to a schedulable state; if any condition is not met or cannot be confirmed, the resource item will remain isolated, and the unmet conditions will be queried or processed.

[0046] When resuming scheduling eligibility, a conditional update with resource relationship versions is used. If the resource relationship version has changed before the update is submitted, the update is abandoned and the actual resource status, occupancy relationship, and resource demand status are queried again. For completion results that arrive after resource scheduling eligibility is restored and point to the original resource relationship that has been closed, only the operation identifier, the original resource relationship identifier, and the processed status are recorded. The original resource relationship is not re-established based on the completion result, nor is it applied to newly established resource relationships.

[0047] Furthermore, when the completion result corresponds to a composite resource release operation, the composite resource release operation is broken down into operation units for computing resources, memory resources, accelerator resources, storage resources, network resources, and running instance resources. The actual resource status corresponding to each operation unit is queried. Only the resource release operation relationship corresponding to the operation unit that has actually reached the target status is closed. Only the support implementation that depends on the resource status before the release of the operation unit is determined to be invalid, and the operation unit that has not reached the target status is kept in an open state.

[0048] The operation unit is the smallest resource control unit that can be independently queried by the corresponding resource controller regarding operation attribution, actual effect, and scope of completion. Computational resource operation units include CPU quota or execution slot release; memory resource operation units include memory quota reclamation or unfixed state cleanup; accelerator resource operation units include device unbinding and runtime context clearing; storage resource operation units include volume unloading, detachment, snapshot deletion, or access authorization revocation; network resource operation units include path severing, session mapping revocation, or traffic takeover release; and running instance resource operation units include instance stopping or destruction.

[0049] Determining the failure of a support implementation that is in the resource state before the dependency is removed means that for each actually completed operation unit, its operation effect is written into the consistent resource state and the subsequent confirmed facts are replayed, and then the support implementation that directly or indirectly depends on the resource state is verified. Operation units that have not reached the target state, cannot complete the operation attribution, or are in the pending verification state are not closed, and the support implementation is not made invalid based on the operation unit.

[0050] Specifically, the scheduling controller persists elastic action records, migration result records, result inheritance relationships, support implementation records, resource facts, resource relationships, resource operation units, late completion results, idempotency identifiers, and reconstruction frontiers. After the scheduling controller restarts, it restores the state in the following order: action relationships, result genealogy, resource relationships, underlying resource facts, support validity, pending operations, reconstruction frontiers, and resource scheduling eligibility; before completing the above restoration, no new irreversible resource release operations are generated.

[0051] Specifically, when a resource controller is temporarily unreachable, its status version is incomparable, or different controllers return conflicting results, the relevant resource facts and supporting implementations are set to pending verification, and irreversible resource removal operations that may eliminate the support are suspended; re-verification is performed through proactive status queries, file read verification, device context detection, network path detection, or operation audit records. If recovery from the current reconstruction frontier is not possible, the reconstruction scope is expanded by selecting the most recent predecessor with valid support, a continuous lineage, and continuous reconstruction inputs along the result lineage; if no such predecessor exists, the subsequent flexible action abandons the acceptance and performs a complete migration.

[0052] The technical effects and advantages of this invention are as follows: This invention establishes a subsequent elastic action before the previous elastic action is closed, determines the partial migration results inherited by the previous elastic action, and identifies supporting implementations for each migration result, enabling migration results that have already been formed and still possess at least one of the capabilities of reading, restoring, and continuing execution to continue to be used. If the resource release operation of the previous elastic action is delayed, the corresponding resource release operation relationship in the previous elastic action is closed based on the actual resource status confirmed by the corresponding resource controller. Supporting implementations that require the resource item to be in the pre-release state are determined to be invalid, ensuring that the scheduling record remains consistent with the actual resource status and preventing the subsequent elastic action from continuing to use migration results that have lost all effective supporting implementations. Subsequently, based on the dependencies between migration results, migration results that still have effective supporting implementations are retained, and only migration results that have lost all effective supporting implementations and their affected subsequent migration results are reconstructed. For resource items that have been actually released and no longer constitute effective supporting implementations for retained migration results, nor are they resources required for generation, restoration, and verification during the reconstruction process, their scheduling eligibility is restored. This reduces the duplication of unaffected migration results, shortens the continuous isolation time of irrelevant resources, improves the continuity of stateful edge task migration and the timeliness of computing resource rescheduling, and enhances the reliability of continuous edge computing power scheduling. Attached Figure Description

[0053] The disclosure of this invention is illustrated with reference to the accompanying drawings. It should be understood that the drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. In the drawings, the same reference numerals are used to refer to the same parts: Figure 1 This is a schematic diagram of the overall process of the present invention; Figure 2 This is an architecture diagram of the edge computing resource elastic scheduling system of the present invention; Figure 3 This is a flowchart of the computing resource elastic scheduling method based on actual resource status to handle delayed completion results according to the present invention. Figure 4 This is a schematic diagram illustrating the processing of the delayed storage volume separation result of the present invention. Detailed Implementation

[0054] It is readily understood that, based on the technical solution of this invention, those skilled in the art can propose various interchangeable structural methods and implementations without altering the essential spirit of the invention. Therefore, the following detailed embodiments and accompanying drawings are merely illustrative examples of the technical solution of this invention and should not be considered as the entirety of the invention or as limitations or restrictions on the technical solution of this invention.

[0055] The edge computing system described in this invention can be composed of an edge orchestration platform, a container runtime, a hypervisor, checkpointing and state transition components, a device controller, a storage controller, and a network controller. Hereinafter, the checkpointing and state transition components will be referred to simply as the checkpoint component. The edge orchestration platform can employ a centralized scheduling controller or a hierarchical structure where a central scheduler and edge site controllers collaborate. The following description uses a centralized scheduling controller as an example, which does not constitute a limitation on the control architecture.

[0056] For ease of understanding, in the following embodiments, two elastic actions created successively for the same task instance are respectively referred to as the previous elastic action. and the next elastic movement The migration results will be recorded as The supporting implementation of the migration results is denoted as Migration outcomes can be one of the following: basic checkpoints, incremental states, storage snapshots, GPU or NPU runtime contexts, memory-stashed states, network session contexts, and service takeover states. The supporting implementation is not simply a resource identifier, but rather a set of actual resource states that enable the corresponding migration outcome to be read, restored, or continued.

[0057] Figure 1 The present invention illustrates the method flow for cross-action processing based on the same actual resource status; Figure 2 The architecture of the edge computing power resource elastic scheduling system of the present invention is shown; Figure 3 The overall flow of the method of the present invention is shown; Figure 4 The process for handling late storage volume separation results is illustrated below. This is explained in conjunction with the accompanying figures.

[0058] Example 1: As Figure 2 As shown, the edge computing system in this embodiment includes a scheduling controller, at least one source edge node, at least two candidate target edge nodes, persistent state storage, a resource control adapter, a checkpoint component, and underlying controllers corresponding to various resources. Both the source edge node and the candidate target edge node can be configured with CPU, memory, GPU or NPU, storage volumes, and network interfaces, and can run container instances, virtual machine instances, or function execution instances.

[0059] The scheduling controller is bidirectionally connected to the persistent state storage for writing and reading elastic action records, migration result records, result acceptance records, support implementation records, resource relationship records, and resource operation records. The scheduling controller communicates with the underlying resource controller through the resource control adapter, issuing resource query, resource allocation, resource release, and status verification requests to the corresponding controllers, and receiving the actual resource status and operation results. The checkpoint component, based on the result generation or recovery instructions issued by the scheduling controller, reads the state to be migrated from the task instance of the source edge node, writes the formed basic checkpoint, incremental state, or serialized runtime context to the node storage volume or shared storage, and reads the migration results at the candidate target edge node to restore the target task instance.

[0060] The scheduling controller receives node status, task load, user location, link quality, and target instance running status, and generates scaling-up, scaling-down, migration, migration rerouting, or fault recovery actions based on status changes. Each time an elastic action is generated, the scheduling controller establishes an independent action record, and does not indicate the new scheduling decision by directly overwriting the target node of the previous action or modifying the identifier of the previous action.

[0061] When the previous elastic action for the same task instance has not yet been closed, and the target node has insufficient resources, the migration path is abnormal, the target instance fails to start, the user's location changes, the task load changes, or the previous elastic action fails partially, the scheduling controller establishes a subsequent elastic action. The subsequent elastic action records the identifier of the previous elastic action, the action generation identifier, the source node, the target node, the triggering reason, and the current execution stage of the previous elastic action, thus forming a traceable action chain.

[0062] In this embodiment, the execution phases of a flexible action may sequentially include action generation, target resource reservation, basic state formation, incremental state synchronization, target instance startup, service qualification confirmation, traffic switching, source instance emptying, source resource release, and action closure. Different implementation environments may merge adjacent phases, but should at least be able to distinguish between the states where migration results have not yet been formed, migration results have been formed, target instances have been restored, and source resources are being released.

[0063] The scheduling controller stores the following information for each action: task instance identifier, action identifier, preceding action identifier, action generation, action type, source node, target node, triggering reason, action stage, creation time, and closure state. These fields can be stored in a relational database, key-value database, or consistent state store. The specific storage format of the fields does not affect the implementation of this invention, but the action identifier, preceding action identifier, and task instance identifier should be able to jointly determine the sequential relationship between actions.

[0064] The checkpoint component is used to generate transfer outcomes from task instances. The base checkpoint represents the complete recoverable state of a task at a certain state generation; the incremental state represents the state changes after the base checkpoint; the GPU or NPU runtime context represents the model parameters, execution location, and device runtime state in the accelerator; and the network session context represents session sequences, address mappings, key states, and traffic takeover relationships.

[0065] For each migration outcome, the scheduling controller saves the outcome identifier, outcome type, action identifier that generated the outcome, task status generation identifier, parent outcome identifier, status sequence number, input log start sequence number, input log end sequence number, content summary, storage or running location, hardware dependencies, recovery deadline, current outcome status, and action identifier that inherits the outcome.

[0066] The parent result identifier and status sequence number are used to establish dependencies between migration results. For example, a basic checkpoint. There is no need for precursor results; the first incremental state. by For the father's achievement, the second incremental state by As a result of the father's efforts, thus forming The result hierarchy is preferably a directed acyclic structure. When a circular dependency is detected, the scheduling controller does not perform local reconstruction based on the dependency, but instead sets the relevant results to be verified or expands the reconstruction scope.

[0067] After a subsequent elastic action is established, the scheduling controller does not inherit all the results generated by the previous elastic action. Instead, it selects the corresponding verification conditions according to the result type. For basic checkpoints, at least the task instance identifier, state generation, content summary, access conditions, and recovery period are verified. For incremental states, the parent result relationship, state sequence number continuity, and whether intermediate states are missing are also verified. For GPU or NPU contexts, the device architecture, driver version, runtime version, and target device capacity are also verified. For network session contexts, the session sequence, address mapping, key status, and target instance takeover conditions are also verified.

[0068] After the results are verified, the dispatch controller establishes a results acceptance record. The results acceptance record includes at least the source action identifier, acceptance action identifier, results identifier, acceptance status, acceptance boundary, and acceptance time. The acceptance relationship indicates that a subsequent flexible action can use the results generated by a previous flexible action, but it does not change the action that generated the results. Even if a subsequent flexible action completes recovery through this results, the source of the results is still recorded as the previous flexible action.

[0069] The resource control adapter sits between the scheduling controller and the underlying resource controller, shielding them from interface differences across platforms. At a minimum, the resource control adapter should be able to query the actual resource status, prepare resource operations, verify fence values, confirm supporting implementations, confirm operation effects, and query whether resources are available for allocation. For underlying controllers that do not support action identifiers or fence values, the resource control adapter can establish a correspondence between operation requests and return results when operations are issued.

[0070] The underlying resource controllers include node resource controllers, device controllers, storage controllers, network controllers, and runtime instance controllers. Node resource controllers are responsible for allocating and releasing CPU quotas and memory resources; device controllers are responsible for binding and unbinding GPUs or NPUs and managing runtime contexts; storage controllers are responsible for volume mounting, detaching, snapshotting, and replication; network controllers are responsible for path establishment, traffic switching, and session takeover; and runtime instance controllers are responsible for instance creation, stopping, and destruction.

[0071] The scheduling controller also establishes a resource relationship record for each resource. A resource relationship record includes at least the relationship identifier, resource identifier, unique runtime identifier for the resource, occupying task identifier, occupying action identifier, relationship status, open version, closed version, relationship version, and fence value. The relationship status can include active, pending closure, and closed. Once a resource relationship is closed, it cannot be restored to an active state due to a delayed result of a previous action; when the same resource is reassigned, a new resource relationship record should be established.

[0072] In this embodiment, resource operations are broken down into independently verifiable operation units. A composite source resource release operation may include CPU quota release, memory reclamation, GPU context clearing, storage volume detachment, network path severance, and runtime instance destruction. Each operation unit records the operation identifier, operation token, source action identifier, operation type, resource identifier, resource runtime unique identifier, pre-release state, target state, issued fence value, issued version, controller runtime cycle, operation status, irreversible flag, preconditions, and affected result identifier.

[0073] Based on the above data structure, the scheduling controller can continue to identify operations in the previous elastic action that have not yet been executed, are being executed, and have been completed but whose messages have not yet arrived after the next elastic action is formed, thereby avoiding simply marking the entire previous elastic action as invalid.

[0074] In this invention, a migration outcome can have one or more supporting implementations. For example, a base checkpoint can exist simultaneously in the source node's local volume and shared storage; the GPU context can be supported by the active context in the source GPU, the serialized file in persistent storage, and the recovery context in the target GPU; the network session context can be supported by the original network path or the new network path that has completed session takeover.

[0075] Each support implementation consists of a non-empty set of necessary resource states. Taking storage replicas as an example, necessary resource states may include file write completion, content digest consistency, storage location online, read permission granted by the subsequent elastic action, valid mount lease, and data availability within the recovery period. Storage resources that only contain residual data but lack access permissions do not constitute valid support.

[0076] The scheduling controller acquires resource facts, supporting relationships, and action relationships under the same resource relationship version, forming a consistent resource state. Each necessary resource fact is recorded as one of three states: confirmed as true, confirmed as false, or pending verification. If the controller is unreachable, the version cannot be compared, or multiple observations conflict, the fact is not directly identified as true or false, but rather enters the pending verification state.

[0077] For each supporting implementation, the scheduling controller simultaneously verifies the continuity of the outcome lineage, content summary, state generation, data format, hardware compatibility, runtime compatibility, access permissions, and the freshness of resource facts. If all items are confirmed to be satisfied, the verification result is "pass"; if at least one item is confirmed to be unsatisfactory, the verification result is "fail"; if verification data is missing or temporarily uncomparable, the verification result is "pending verification".

[0078] The freshness of resource facts can be determined based on the status version or the most recent observation time within the same controller's runtime cycle. Different resource types can use different maximum observation intervals. After the corresponding observation interval is exceeded, the original observation results are no longer directly used to confirm the support validity, and the scheduling controller re-queries the corresponding underlying controller.

[0079] The scheduling controller also verifies whether the support implementation can be acquired and restored before the task recovery deadline. During verification, the time required for scheduling queuing, target device waiting, mounting, transmission, integrity verification, device context recovery, and instance startup are included in the estimated recovery time. For tasks without a mandatory recovery deadline, this time limit can be omitted; if the estimated time cannot be obtained temporarily, the corresponding support implementation enters a pending verification state.

[0080] Support implementation status is determined according to the following rules: Support implementation is confirmed as invalid when any necessary resource fact, result verification condition, or recovery time limit is confirmed to be unmet; if no unmet item is confirmed, but conditions still cannot be confirmed, support implementation is in a pending verification state; support implementation is valid when all necessary conditions are confirmed to be met. Support that has been confirmed as invalid will not be changed to pending verification due to the simultaneous existence of other unknown conditions. Support pending verification is not counted as valid support, but it is still treated as protected in the determination of irreversible resource release.

[0081] To prevent duplicate callbacks from the underlying controller from causing the same physical copy to be counted repeatedly, the scheduling controller deduplicates the supporting implementations based on the result identifier, the resource runtime unique identifier, the content summary, and the necessary resource fact set. After deduplication, the number of valid supports and the number of supports pending verification for each result are counted separately.

[0082] When an achievement has two or more valid supports, the failure of any single support usually does not invalidate the achievement; when there is only one valid support, that support is the last valid support; when there is no valid support but still support to be verified, the achievement remains in the invalid verification state; only when there is neither valid support nor support to be verified is it confirmed that the achievement has lost all support.

[0083] Whether a result can still be used depends on its necessary predecessor results. Basic checkpoints do not require any predecessor results; incremental states, device contexts, or other subsequent results are considered directly recoverable only if they have at least one valid support and all necessary predecessor results are still valid. Even if a subsequent result file still exists, it cannot serve as a valid recovery entry point if its necessary predecessor results have expired.

[0084] Example 2: Figure 1 As shown, before the previous elastic action of the same task instance has been closed, the scheduling controller establishes a subsequent elastic action to inherit part of the migration results and determines the support relationship between the migration results and resource items. When the resource release completion result of the previous elastic action arrives after the inheritance relationship is formed, the scheduling controller obtains the actual resource status and closes the corresponding resource release operation relationship in the previous elastic action according to the same actual resource status, while simultaneously invalidating the support provided by the released resources in the inheritance results of the subsequent elastic action. Subsequently, the scheduling controller retains the migration results that still have effective support according to the migration result dependencies, reconstructs the migration results that have lost all effective support and their successors, and restores the scheduling eligibility of resource items that neither support the retained results nor are used in the reconstruction process.

[0085] For ease of implementation, such as Figure 3As shown, the above processing can be executed by the scheduling controller or by the scheduling controller in collaboration with multiple edge site controllers, and is divided into steps S101 to S106.

[0086] S101, establish the next elastic action before the previous elastic action of the same task instance has been closed.

[0087] The scheduling controller continuously collects target node resources, task load, user location, link status, and target instance startup status. When it detects that the original migration target no longer meets the current migration conditions, it does not modify the target node of the previous elastic action, but instead creates a subsequent elastic action with a new action identifier. The predecessor_action_id of the subsequent elastic action points to the previous elastic action, and the generation increments based on the generation of the previous action.

[0088] After establishing the next flexible action, the scheduling controller reads the migration results that have been formed or are being formed in the previous flexible action, and determines the verification conditions for each result according to its type. Results that pass verification are written into the receiving set of the next flexible action, results that fail verification are written into the regeneration set, and results whose status cannot be confirmed temporarily are written into the pending verification set.

[0089] Optionally, when a read-only base mirror layer or an immutable base checkpoint can be accessed by multiple subsequent actions simultaneously, multiple candidate actions can be allowed to establish read-only acceptance relationships; for continuously updated incremental state streams or variable running contexts, the scheduling controller allows only one currently valid action to obtain exclusive acceptance qualification through acceptance fences.

[0090] S102, determine the support implementation for each migration result inherited by the subsequent elastic action.

[0091] The scheduling controller queries the corresponding underlying controller based on the storage location, device context location, instance recovery status, and network takeover status in the results record. For each candidate support, it not only confirms the resource identifier, but also the resource's runtime unique identifier, current owner, access permissions, data integrity, and recovery period.

[0092] For example, for checkpoints in shared storage, the storage controller returns volume status, file length, digest value, mount or access authorization, and controller version; for runtime contexts in the source GPU, the device controller returns device bindings, context existence status, driver runtime cycle, and runtime unique identifier; for recovery status in the target instance, the runtime instance controller returns instance identifier, recovery entry, health check results, and service eligibility.

[0093] According to the judgment rules described in Example 1, the scheduling controller determines the status of each support implementation and distinguishes between results that still have multiple effective supports, results that only have the last effective support, results that have lost all effective supports, and results that are in a pending verification state.

[0094] S103: Receive the result of the resource release operation of the previous elastic action and query the actual resource status.

[0095] After a successor relationship is established in a subsequent elastic action, the scheduling controller may still receive the resource release operation completion result of the previous elastic action. This result must at least be associated with the operation identifier, operation token, source action identifier, controller identifier, and resource runtime unique identifier. If the underlying controller does not carry the above information in the result, the resource control adapter supplements the association based on the operation issuance record.

[0096] The scheduling controller does not directly close the previous elastic action based on the "success" field in the message. Instead, it calls the corresponding resource controller to query the operation-specific completion record, state transition log, and current actual resource status. For composite resource release operations, the scheduling controller breaks them down into operation units for computing resources, memory resources, accelerator resources, storage resources, network resources, and running instance resources, and queries whether each operation unit has reached the target state.

[0097] S104, based on the actual resource status confirmed by operation attribution, close the corresponding operation relationship in the previous elastic action, and re-verify the support implementation of the results of the subsequent elastic action.

[0098] The fact that a resource's current state matches the operational target state does not necessarily mean that this state was formed by the corresponding operation of a previous elastic action. For example, a storage volume may re-enter a detached state after manual maintenance or reconfiguration by a subsequent elastic action. Therefore, the scheduling controller should also attribute operations using operation_id, operation_token, the resource's runtime unique identifier, the controller's runtime cycle, or operation audit logs.

[0099] When the underlying controller can confirm that the resource state change was caused by a specified operation in the previous elastic action, it closes the operation relationship. The completed result still belongs to the previous elastic action that produced the result and is not reassigned to the subsequent elastic action. If only some operation units in a compound operation are actually completed, only the actually completed operation units are closed, and the remaining operation units remain in an open state.

[0100] Upon closing the previous operational relationship, the scheduling controller writes the actual resource change into a consistent resource state snapshot and merges any remounting, reauthorization, rebinding, or replacement of supporting implementations that occurred later than the resource change. The scheduling controller recalculates the relevant supporting implementations according to the latest consistent state. Only if the necessary resource facts still do not hold true in the latest state is the corresponding supporting implementation deemed invalid.

[0101] For example, if a storage volume is detached in a previous action and then remounted and has read authorization re-acquired in a subsequent action, the detachment operation of the previous action should still be closed, but the current storage support cannot be deemed invalid solely based on the fact of historical detachment. Conversely, if the volume has already been detached, access authorization has been revoked, and it has entered a state where it can be reallocated by other tasks, then the residual data in the volume no longer constitutes valid support that can be used by the subsequent action.

[0102] S105, Determine the reconstruction scope based on the dependencies of migration results.

[0103] The scheduling controller compares the number of valid supports and the number of supports to be verified for each outcome before and after the actual resource change is written. When an outcome changes from having at least one valid support or a support to have no valid support or support to be verified to having neither valid support nor support to be verified, and its necessary precursor outcome is still valid, the outcome is identified as the reconstruction frontier.

[0104] The scheduling controller traverses backward along the parent outcome relationship, incremental sequence, and recovery entry relationship to determine the subsequent migration outcomes that depend on the reconstruction frontier. Outcomes that still have valid support and do not belong to the affected subsequent branches are retained. The system only regenerates the reconstruction frontier and its affected subsequent outcomes, and does not regenerate the already retained basic checkpoints and incremental states.

[0105] When the current reconstruction front lacks continuous input logs or the target environment is incompatible, the scheduling controller searches forward along the result lineage for the most recent predecessor result that has effective support, a continuous lineage, and complete reconstruction inputs, thus expanding the reconstruction scope. If no recoverable predecessor result exists, the subsequent flexible action abandons the inherited result and performs a complete migration.

[0106] S106, restore scheduling eligibility for resource items that have already been actually deactivated.

[0107] Having reached the release state does not mean that a resource can be immediately rescheduled. The scheduling controller queries the underlying physical state of the resource, the controller's allocable state, the status of valid actions occupied, the status of retained results support, the status of resource reconstruction requirements, the status of alternative support formation, and the status of pending operations.

[0108] The scheduling controller will only restore the scheduling eligibility of a resource when the old relationship of the resource has been closed, the underlying controller confirms that the resource is in an allocable state, there is no valid action occupying it, the resource no longer supports the retention results, it is not a resource generated, restored or verified in the reconstruction process, there is no process that uses the resource to form alternative support, and there are no pending operations that can change the state of the resource.

[0109] Restoring scheduling eligibility uses conditional updates. The scheduling controller performs the determination based on the resource relationship version. The resource is added to the schedulable resource pool based on this version. If the resource relationship version has changed at the time of submission, it indicates that new resource usage or status updates have occurred during the judgment period. The scheduling controller abandons this submission and queries again.

[0110] After a resource regains scheduling eligibility, subsequent duplicate completions of the previous elastic action are only recorded idempotently, without re-establishing closed resource relationships. If a subsequent elastic action or other task requires the resource again, a new resource relationship and a new fence value should be established.

[0111] Example 3: This example illustrates the processing procedure when the resource release request of the previous elastic action has not yet been actually executed. The scheduling controller groups one or more resource release operations that have not yet been completed into an operation set. Based on the preconditions and target state of each operation, it determines whether the joint execution of these operations will disrupt the migration results support still needed by the subsequent elastic action.

[0112] The scheduling controller considers the results directly affected by the set of operations, as well as subsequent results dependent on these results, as the scope of influence. This scope of influence can be obtained by traversing backwards through parent result relationships, incremental state sequences, recovery entry relationships, and service takeover relationships.

[0113] Multiple resource operations may have an execution order. For example, GPU context serialization should be completed before GPU context cleanup, and source instance destruction should be performed after checkpoint solidification and network session depletion. The scheduler controller simulates the resource state after each operation is completed according to the operation preconditions. After simulating each operation, the target state of the operation is written into the temporary state, and the updated temporary state is used as the basis for determining the next operation.

[0114] The next operation is simulated only if the preconditions of the previous operation are met in the temporary state. If a cycle exists in the operation dependencies, or if the execution order of satisfying the preconditions cannot be determined, the operation set is split, and the entire operation set is not executed.

[0115] The scheduling controller also verifies whether the fence values ​​carried by each operation are consistent with the current fence values ​​of the resources, and protects the results that are currently valid within the affected area, are in a pending verification state, and have not been explicitly abandoned by the subsequent elastic action. For each resource involved in the operation, it also confirms that the resource is no longer used by the current reconstruction process and that there is no process that is using the resource to form alternative support.

[0116] The scheduling controller will only allow the set of operations to enter the execution phase when the fence values ​​are consistent, all preconditions for the operation are met, the protection results are still usable after the operation is executed, and the relevant resources are no longer occupied by the reconstruction process or the alternative support formation process.

[0117] Once the set of operations meets the release conditions, the scheduling controller prepares to issue operations according to the predetermined execution order. Before each irreversible operation is actually submitted, the resource control adapter re-queries the resource relationship identifier, current occupancy action, fence value, and resource relationship version, and submits the operation only if the information is consistent with the aforementioned judgment. Interchangeable operations with independent preconditions can be executed in parallel; operations with sequential dependencies are executed serially according to the aforementioned order. If any resource relationship changes, the execution of unsubmitted operations is stopped and a new judgment is made.

[0118] If any of the above release conditions are not met, the scheduling controller splits the operation set. Operations that will not invalidate any protection results can continue to be executed; operations that will eliminate the last effective support but can form an equivalent alternative support enter a waiting alternative state; operations that will eliminate the last effective support and cannot form an alternative support are rejected; irreversible operations with unknown controller state or whose preconditions cannot be confirmed remain isolated and active verification is initiated.

[0119] Equivalent alternative support should match the type of migration outcome. For checkpoint or incremental states, a complete copy can be created in another storage location; for GPU or NPU contexts, the context can be serialized to persistent storage or restored on a compatible target device; for memory states, dirty pages and shared memory segments can be persisted to the checkpoint; for network sessions, new paths can be established and session sequences, address mappings, and key state takeover can be completed; for running instances, state recovery, resource binding, health checks, and service takeover should be completed on the target instance.

[0120] Alternative operations are not counted as valid support only if they are in the state of being issued, transmitted, or restored. Alternative support is only registered as valid support after it has completed the write, transmission, or restoration corresponding to its type and passed the verification of content integrity, result lineage, access permissions, and operational compatibility.

[0121] This embodiment is particularly suitable for situations where multiple operations are safe to perform individually, but executing them together would eliminate the final support. For example, the results... Each from storage volume The copy in and the state in the source instance memory Support. Separately hour, Still effective; when reclaiming source memory separately, It remains valid; when two operations are executed together, The effective support quantity changes from 2 to 0. Based on this, the scheduling controller prevents the two operations from executing simultaneously and first establishes support in shared memory. .

[0122] In another implementation, when the platform lacks the ability to simultaneously deduce the common state of multiple operations, resource release operations can be executed sequentially. After each operation is completed, the scheduling controller re-queries the actual resource state and recalculates the supporting data before determining whether to execute the next operation. This method has a longer processing time, but it still avoids multiple operations jointly eliminating the final effective support.

[0123] When the underlying controller does not support fence values, the resource control adapter can use operation leases, mutexes, condition updates, or serial operation queues set by resource item. Before issuing the actual release command, the adapter re-verifies the resource relationship identifier, current occupancy action, lease status, and subsequent action reference relationship. If the resource relationship has changed, the old release request is rejected.

[0124] Example 4: This example illustrates the process where a resource release operation has been actually executed, but the completion message only arrives after the subsequent elastic action establishes a result continuation relationship. The scheduling controller cannot change the already established physical or runtime state by rejecting the message; instead, it should confirm the actual effect of the operation and handle the impact of this effect on the results of the previous and subsequent actions and the resource scheduling relationship.

[0125] Let's define the operation corresponding to the late completion result. When the underlying controller can confirm that the target state change is caused by an operation identifier, operation token, resource runtime unique identifier, operation audit record, or state transition record within the same controller's runtime cycle, When an operation occurs, the operation attribution is deemed valid; if the source of the operation cannot be confirmed, the operation relationship in the previous elastic action is not closed.

[0126] The reliability of the operation's effect can be confirmed through two types of evidence: one is that the observed controller runtime is consistent with the time the operation was issued, and the observed state version is no earlier than the version issued by the operation; the other is the existence of an immutable completion record corresponding to the operation identifier, operation token, unique resource runtime identifier, and effect sequence number. If either type of evidence is valid, and the actual resource state reaches the target state of the operation, the operation is considered to have been actually completed.

[0127] If the complete processing transaction corresponding to this operation has already been committed, this message will be treated as a duplicate result, and the operation relationship will not be closed again, nor will the result invalidation or reconstruction be triggered again. Subsequent relationship updates will only be executed when it is confirmed that the operation has actually been completed but the corresponding processing has not yet been completed.

[0128] The scheduling controller treats the closing of the previous action operation relationship, the writing of the actual resource facts, the writing of the subsequent action support verification results, the reconstruction of the leading edge record, and the updating of the resource isolation status as an atomic processing unit. Only after the complete submission of this processing unit is the data processed. Updated to 1. When the persistent system cannot provide a single transaction, it can use the processing status of "unprocessed, processing, processed" and processing leases with time limits; after the controller restarts, idempotent processing is re-executed on the results that are "processing" and have not yet formed a complete commit record.

[0129] When a controller restarts and causes the version count to reset, the version sizes before and after the restart cannot be directly compared. In this case, as long as there is a complete operation completion record with an operation identifier, operation token, resource runtime unique identifier, and effect sequence number, the operation effect can still be confirmed. If no reliable operation completion record exists, the operation should be set to pending verification; the original operation cannot be considered complete simply because the current resource state matches the target state.

[0130] Once it is confirmed that the operation has been actually completed and has not yet been processed, the scheduling controller closes the corresponding operation relationship in the previous elastic action. This process constitutes a precursor closure effect. The completion result is still recorded as generated by the previous elastic action, and the source of the result is not changed even if the subsequent elastic action has used the relevant results.

[0131] For completion results, the scheduling controller can also determine whether the result has the validity of proving subsequent results. For example, a previous flexible action has completed the checkpoint file writing, but the completion message is late; a subsequent flexible action has registered the checkpoint as a pending confirmation result. After the scheduling controller queries the storage controller and confirms that the file length, content summary, state generation, and access permissions all meet the conditions, it can update the acceptance status of the subsequent flexible action from pending confirmation to valid. The source of the completion result is still the previous flexible action.

[0132] For resource release completion results, the scheduling controller re-verifies the support implementation of the subsequent elastic action based on the same actual resource status. This processing constitutes a disruption effect on subsequent support. For example, a storage volume detachment result can either disable the volume detachment operation of the previous action or invalidate subsequent results that depend on the volume mounting and read authorization; however, this result does not prove that the subsequent elastic action has formed another storage support.

[0133] To process delayed results according to the causal order of resource changes, the scheduling controller saves the support state before the effect of this operation is written, and the latest support state after the operation effect is written to its causal position and subsequent confirmed facts are replayed. These subsequent facts include rebinding, remounting, reauthorization, and replacement support formation facts.

[0134] Facts generated by the same underlying controller are prioritized based on the controller's runtime cycle and effect sequence number. Facts generated by different controllers are prioritized based on resource relationship version, operation prerequisites, outcome dependencies, and control plane confirmation sequence number; physical timestamps are only used as supplementary information. When two facts cannot be compared temporarily, the order is not forcibly determined; the affected supporting implementation is set to pending verification, and the release of related irreversible resources is suspended.

[0135] The scheduling controller compares the number of valid supports and the number of supports to be verified for each result before and after the processing of late results.

[0136] When an achievement has at least one valid support or a protective support to be verified before processing, and it is confirmed after processing that there is neither a valid support nor a support to be verified, and the necessary precursor achievements of the achievement are still valid, the achievement is identified as a reconstruction frontier.

[0137] One or more results that simultaneously meet the above conditions constitute the minimum reconstruction frontier corresponding to this delayed result.

[0138] If the necessary precursor results have become invalid, subsequent results are not repeatedly used as reconstruction frontier points, but are treated as affected subsequent results of the reconstruction frontier of the precursor. When multiple independent results simultaneously lose their final support, multiple parallel reconstruction frontier points can be formed.

[0139] The scheduling controller retains all results that still have valid support and lineage continuity, generating new results only from the reconstruction front. When old support is restored during reconstruction, it does not automatically replace already generated new results. Reconstruction can only be cancelled and old results reused if new results have not yet been submitted, old results have passed state generation, abstract, and lineage verification again, and no new input states are generated.

[0140] After a resource relationship is closed, a monotonic state transition is used, meaning that an active relationship can sequentially transition to "pending closure" and "closed," but a closed relationship cannot be converted back to an active relationship. Late completion results can only affect the original relationship identifier they carry; if a new relationship has already been established for the same resource by a subsequent elastic action or other task, a late completion result cannot remove or overwrite that new relationship.

[0141] For resources that have been actually released, the scheduling controller determines their scheduling eligibility based on the consistent resource status corresponding to the same resource relationship version.

[0142] When making a judgment, at least the following conditions must be confirmed: the underlying controller has confirmed that the resource has reached the release state of the resource type; the resource relationship corresponding to the previous elastic action has been closed; the resource is not in a fault, maintenance, repair or node emptying state; there is no valid action occupying it; the resource no longer supports the retention results; the resource is not a necessary input or execution condition for rebuilding the frontier; there is no process that uses the resource to form alternative support; there are no pending operations or unverified results that can change the state of the resource.

[0143] If any of the above conditions are missing, the resources remain isolated. Once all conditions are met, the scheduling controller uses the observed resource relationship version. A commit is performed only if the current version at the time of the commit is still equal to the comparison condition; Resources are only added to the schedulable resource pool when conditions are met. If a condition submission fails, the actual status is queried again and the calculation is recalculated.

[0144] Example 5: This example uses a stateful edge video analytics service as an example to illustrate the complete execution process of the method of the present invention. The node specifications, output size, and time parameters below are used to illustrate the state change relationship and do not mean that the same parameters must be used in the present invention.

[0145] edge nodes Configuration includes an 8-core CPU, 16GB of RAM, GPU 0, and source storage volume. Run task instance Edge nodes Configured with an 8-core CPU, 16GB of RAM, and GPU1, it serves as the original target node for the previous elastic action; edge node. Configured with a 12-core CPU, 24GB of RAM, and a GPU3, it will serve as the new target node for the subsequent elastic action. Shared storage. able to be , and access.

[0146] Task Examples Continuously process video frames and maintain inference state, GPU runtime context, input stream session sequence, and unfixed incremental state. The state generation of a task instance is... The source running instance is denoted as The original network path is denoted as .

[0147] exist At that time, due to a change in the user's access location, the scheduling controller establishes the previous elastic action. Set the migration target to the edge node. . Establish basic checkpoints during the execution process. First Incremental State Second Incremental State GPU runtime context and network session context .

[0148] in, The size is 400MB, in Complete and write to shared storage ; The size is 120MB, in Complete and write ; The size is 80MB, in Created but only stored in the source storage volume middle; It exists only in source GPU0; Only from the original network path Maintain. The lineage of achievements is... .

[0149] and All digests have been verified. It has not yet been copied to shared storage. Not yet serialized. The handover to the new path has not yet been completed. Enter log. Stored independently in shared storage In the middle, records from The continuous input data following the input sequence number at the end.

[0150] exist At that time, the original target node GPU1 has become unavailable. The scheduler controller has not been modified. Instead, it establishes the subsequent elastic action. The front drive indicator points to The target node was changed to .

[0151] The dispatch controller verifies each , , , and Since these results are all task instances. The state generation is The parent-child relationship is continuous, and It has the corresponding operating environment, and the scheduling controller is Establish the relationships between the aforementioned achievements. The actions that generate each achievement will still be recorded as follows: .

[0152] exist When it is created, and Each has one located in Effective support in the process; Having a located Effective support in the process; It has an effective support located in GPU0; Having a by The above-mentioned support measures are the final and effective support for the corresponding results.

[0153] CPU quota removal operations still exist. Memory reclamation operation GPU0 context clearing operation Storage Volume Separation operation Network path Cut-off operation and source instance Destruction operation .in, Already It has entered the execution queue of the storage controller; the remaining operations have not yet been executed.

[0154] The scheduling controller targets tasks that have not yet been executed. , , , and Perform a post-joint state check. If all the above operations have been executed, and The entire set of operations will lose all effective support, therefore the entire set of operations cannot be released.

[0155] The scheduling controller further breaks down the operation. The source CPU and source memory are still used for GPU context serialization, network session handover, and reconstruction processes, therefore... and Pause; GPU0 context clearing will make Losing its last support, thus preventing Network path cutting will make Losing its last support, thus preventing The source instance remains the execution vehicle for state persistence and session handover, thus preventing... .

[0156] Generate GPU alternative support operations, network alternative support operations and Copy operation. GPU-override support operation is used to copy... Serialization to And restore on GPU3; network replacement support operations are used in the new network path Complete session takeover; The copy operation is used to... from Copy to .

[0157] exist At that time, the storage controller actually completes ,Will With source instance The mount relationship is terminated and revoked. Read the lease for this mount relationship. At this time... It has reached the underlying physical separation state and has the conditions for underlying allocation, but before the scheduling controller completes operation attribution, result support re-verification, and resource scheduling eligibility judgment, Continue to maintain upper-level isolation and do not assign to other tasks. Since the replication operation is not yet complete, Only exists in Some of the documents failed the summary verification and do not constitute valid support.

[0158] like Figure 4 As shown, The completion message was delayed due to network latency. It has just arrived at the scheduling controller. The completion message carries the operation_id, operation_token, and... The resource is a unique identifier at runtime. The immutable operation logs of the storage controller indicate that... exist This creates a separation effect, and the effect corresponds to... The operation request.

[0159] The dispatch controller confirms this. Completed but not yet processed, close. In Operational relationship. The source of the completed result remains the same. , not because Already undertaken And things will change.

[0160] Comparison of dispatch controllers The support status before and after the effect is written. Before writing, Depend on Provides valid support, and there is no support to be verified; Write After the effect is displayed and the subsequent facts are replayed, The mount lease and read authorization have both expired. Some files in the file failed verification, therefore It no longer has valid support or is pending verification.

[0161] and Still using shared storage Support. Due to It has effective support before treatment, loses all effective support after treatment, and has its necessary precursor. It is still valid, the dispatch controller will It has been identified as the front line for reconstruction.

[0162] In determining To rebuild the frontier, the scheduling controller is... Set recovery boundary and the corresponding end input sequence number From the time the recovery boundary is established, the input agent no longer sends requests to the source instance. Delivery sequence number greater than Instead of providing new input, it temporarily stores or continuously writes it to the input log. Checkpoint reconstruction, GPU context persistence, and network session takeover are all based on this recovery boundary, and the temporarily stored input is delivered sequentially after the target instance becomes eligible for service.

[0163] Dispatch controller reserved and The above results will not be regenerated. The scheduling controller starts from... Read , obtain The record ends with an input sequence number, and is retrieved from a separately saved input log. Read to recovery boundary Corresponding end input sequence number Continuous input records, in Regenerate the second incremental state .

[0164] During reconstruction, the input logs are replayed in ascending order of input sequence number, and duplicate inputs are skipped using an idempotent flag. For tasks involving random computation, parallel computation, or external events, the input logs also record the random seed, model version, state transition version, and identifiers of external events affecting state evolution. No requirement to be the same as the original The file content must be identical byte-by-byte, but should have the same parent result identifier, state generation, and input range, and pass the application state invariant verification. (Generate) Subsequently, the scheduling controller verified its parent result identifier as... State generation The end input sequence number is And the content summary verification passed.

[0165] exist hour, Completed and To provide effective support. Maintain source action The status remains unchanged, and its acceptance state is set to invalid. Resumption of use .

[0166] exist At the time, and the restoration boundary The corresponding GPU runtime context completes the serialization, and the serialized file is written. And then restore on GPU3. The device controller confirms that the driver version, runtime version, state summary, recovery entry, and recovery boundary all meet the requirements. At this point, have The serialized file in GPU 1 and the activity context in GPU 3 are the two valid supports; GPU 0 is no longer the last valid support. The scheduler executes... The device controller clears the source context in GPU0 and unbinds the source device.

[0167] exist At that time, the instance controller is running. Combined use , , The recovery context in GPU3 completes the recovery of the target instance. After passing the state generation, recovery boundary, and application state consistency verification, the target instance completes the health check and obtains service eligibility, but does not receive external business traffic until the network session takeover is complete.

[0168] exist At that time, new network path Setup complete. Network controller restores boundary. Based on the completion of session sequence, address mapping, and key state takeover, traffic is switched to the target instance after confirming that the target instance has obtained service eligibility. And deliver temporary input to the target instance according to the input sequence number. become An effective alternative support. The scheduling controller executes... The network controller disconnects the network after confirming that the original path no longer carries a valid session. .

[0169] exist At that time, GPU context recovery, network session takeover, Reconstruction, target instance health checks, and traffic switching have all been completed. The source instance no longer undertakes state persistence, log generation, business processing, or service draining tasks. The scheduling controller executes... , and Remove the source CPU and memory quotas and destroy the source instance. .

[0170] Resource scheduling eligibility is restored according to the actual status of each resource. Although They have been physically separated, but the scheduling controller is still in... Only after confirming the cause of the operation and completing the re-verification of supporting results can its upper-level isolation be lifted and its scheduling qualification restored; GPU0 in After alternative support is formed and context clearing is completed, scheduling eligibility is restored; the original network resources are... Released after path switching and session takeover are completed; source CPU, memory, and source instance are... Release completed.

[0171] exist At that time, the scheduling controller completes the final consistency verification of the action chain, result system, resource relationship and service status. Each operation unit in the process is either completed, no longer executed due to fence failure, or... The alternative state, then closure; The process is closed after confirming that the target instance remains eligible for service and that there are no pending resource effects.

[0172] This embodiment only applies to checkpoint chains. , and The nominal state data volume is compared. If the entire checkpoint chain is reconstructed, three results of 400MB, 120MB, and 80MB need to be regenerated, totaling 600MB; when using the method of this invention, only the nominal state data volume needs to be regenerated. The corresponding 80MB state avoids regenerating a nominal data size of 520MB, which accounts for approximately 86.7% of the total nominal data size of the entire checkpoint chain.

[0173] The above ratios only correspond to the size of the checkpoint chain results set in this embodiment, and do not include the data volume generated by GPU context serialization, input log reading, digest verification, and network session takeover, nor do they represent that the total traffic or total latency will be reduced by the same ratio in all implementation environments. This comparison is for illustrative purposes only; determining the reconstruction frontier according to the location where the last effective support is lost can avoid the repeated generation of results that still have effective support.

[0174] Example 6: In the case of delayed results, the previous flexible action has already moved the basic checkpoints. Write to shared storage, but the storage controller's completion message will be sent in a subsequent elastic action. Arrival will only occur after confirmation of received deliverables. The scheduling controller queries shared storage to confirm that file length, summary, state generation, parent deliverable relationship, and access permissions all meet the requirements. It then closes the checkpoint generation operation in the previous elastic action and sets the next elastic action accordingly. The acceptance status has been updated from pending confirmation to valid.

[0175] The completion result has both the effect of closing the preceding process and the effect of proving the successor result, but it does not have the effect of releasing resources. The scheduling controller does not determine that the subsequent action has formed any new resource support based on the completion result, nor does it change the source action of the completion result.

[0176] When the status of the underlying controller cannot be confirmed—for example, if the underlying controller is temporarily unreachable, a network partition occurs, resource fact versions are not comparable, or the statuses returned by multiple controllers conflict—the scheduling controller sets the corresponding support implementation to pending verification. Supports pending verification are not counted in the number of valid supports, but system pauses may eliminate irreversible resource release operations for that support.

[0177] The scheduling controller can re-verify using active querying, file read verification, device context detection, network path detection, or controller status callback. If confirmation still cannot be achieved after the maximum verification period, and the task allows for regeneration of the status, the scheduling controller abandons the support to be verified and expands the reconstruction scope; if the task cannot afford to lose the status and there is no alternative support, the relevant resources remain isolated.

[0178] When the GPU or NPU context cannot be directly migrated, for example, if the source device does not support context serialization, the source device and target device architectures are incompatible, or the driver version does not meet the recovery conditions, the scheduling controller will not determine the source device context as a directly inheritable result. The system retains the source device context and reinitializes the target device on the target node based on the basic checkpoints, model files, parameter states, and input logs.

[0179] After the target device completes model loading, necessary cache establishment, and task state recovery, the device controller confirms that the target device is ready to run and registers the new runtime context in the target device as the result of the next elastic action. Only after the target instance passes the health check and obtains service eligibility is it allowed to clear the source device context and unbind the source device.

[0180] When network sessions cannot be directly migrated, for long-lived connections whose session sequences, address mappings, or key states cannot be migrated, the system employs a method of emptying old connections and establishing new connections. The network controller maintains the existing connections on the original path, stops allocating new connections to the source instance, establishes a new path on the target instance, and allocates subsequent new connections to the target instance.

[0181] Once an old connection is completed or a preset drain condition is met, a reconnection command is sent to any incomplete connections, or the connection is re-established through a proxy. The network controller allows the original path to be terminated after confirming that it no longer carries a valid session. In this case, the network session context itself is not considered a result of the subsequent resilient action; instead, the target instance obtaining service eligibility and the new path starting to carry connections are considered as conditions for service takeover.

[0182] When the reconstruction input is discontinuous, the scheduling controller stops reconstructing from the current reconstruction front position and searches forward along the result lineage for the most recent predecessor result that has effective support, continuous parent result relationship, continuous input log and is compatible with the target operating environment.

[0183] For example, Subsequent input logs are missing, but basic checkpoints are present. and The system retains the complete input log afterwards. ,give up Kahara Regenerate and If no predecessor result is available, the subsequent flexible action abandons the result and performs a complete migration.

[0184] When there are more than three generations of elastic movements, for example Not yet closed Established before completion The scheduling controller determines the scope of effect of late results generation by generation along the result acceptance path. The results formed can only be achieved when... Receive and continue from When accepting, Only when the results are formed can they have an impact. It has evidentiary effect.

[0185] The result of resource release does not directly re-attribute The scheduling controller re-verifies the resources based on their actual changes. and The support implementation is still in use. When a state generation break, result lineage break, or change of the receiving fence occurs in any generation of the action chain, the result proof validity of the old result will no longer be passed on.

[0186] When multiple successor actions contend for the same result, for an unmodifiable base image layer or a read-only base checkpoint, multiple actions can be allowed to establish a read-only successor relationship; for continuously updated incremental states, active GPU contexts, or variable session states, a successor fence is used to allow only one valid successor action to obtain exclusive successor eligibility.

[0187] When a candidate action does not have exclusive acceptance eligibility, it can read immutable results, but cannot write to the incremental sequence, change resource relationships, or trigger the release of the source resource. After a candidate action is canceled, the scheduling controller closes its acceptance relationship, without affecting the valid acceptance relationships already established for other actions.

[0188] The scheduling controller handles duplicate, out-of-order, and lost events separately. For duplicate completion results, the scheduling controller identifies the idempotency flag and the processed status, and does not repeat the closing operation relationship, fail the support again, or establish the reconstruction front again.

[0189] For out-of-order results, the scheduling controller does not directly sort them by arrival time. Results generated by the same controller are sorted according to the controller's operating cycle and effect sequence number; results generated by different controllers are ordered according to resource relationship version, operation prerequisite relationship, result parent-child relationship, and control plane confirmation sequence number, with physical timestamps serving only as auxiliary information. When the causal order cannot be confirmed temporarily, the relevant results and supporting data are set to pending verification.

[0190] In the event of event loss, the scheduling controller actively queries the resource controller after the operation times out. If a dedicated completion record for the operation is found, it is treated as a late completion result; if the operation has not yet been executed, it decides whether to continue execution based on the current fence value; if it cannot be confirmed, the operation and related support are set to pending verification.

[0191] When resources have been reallocated, the delayed result of the previous elastic action can only affect the original resource relationship identifier and cannot change the new resource relationship. If the delayed result indicates that the previous operation has been completed, the original operation relationship can be closed, but the resource occupation of the current task cannot be released.

[0192] When the existing platform cannot release CPU, memory, device and network resources separately according to resource items, the source running instance can be destroyed and the source resources released uniformly after the subsequent elastic action completes the full state recovery, service takeover and alternative support.

[0193] When using this approach, all retained results should be effectively supported, the reconstruction frontier and its affected subsequent results should have been regenerated, the target instance should be qualified for service, and the source instance should no longer be responsible for state consolidation, log generation, and session emptying tasks. This approach still achieves secure closure, but resource recovery time is later than the segmented release approach.

[0194] When the scheduling controller restarts and recovers, it reads the persistent elastic action records, result records, succession relationships, supporting implementations, resource facts, resource relationships, pending operations, late results, idempotent identifiers, and reconstruction frontiers to reconstruct the action chain and result spectrum, and then actively queries the actual status of the underlying resources.

[0195] For resources whose controller runtime has changed, the version size before and after the restart is not directly compared. Instead, the unique identifier of the resource at runtime, operation audit records, and the current actual state are used for verification. No new irreversible resource release operations are generated before the action relationships and resource facts are completely rebuilt.

[0196] Example 7: The method of the present invention can be executed by a scheduling and control device. The scheduling and control device includes at least one processor, a memory, and a communication interface. The memory stores computer programs, as well as action records, result records, supporting implementation records, resource fact records, and resource relationship records.

[0197] When the processor executes the computer program, it implements the steps in any of the foregoing embodiments, including establishing a subsequent flexible action, determining the received results and supporting implementation, receiving delayed completion results, querying and attributing the actual resource status, closing the previous action operation relationship, re-verifying the support of the subsequent action results, determining the reconstruction frontier, and restoring resource scheduling eligibility.

[0198] The communication interface is used to communicate with node resource controllers, device controllers, storage controllers, network controllers, and runtime instance controllers. The scheduling and control device can be deployed independently or run as a control component within an edge orchestration platform.

[0199] In one implementation, the functions of the scheduling and control equipment can be divided into an action chain management module, a results acceptance module, a support verification module, a late arrival result processing module, a reconstruction frontier determination module, and a resource eligibility restoration module. These modules can be implemented by software or by a combination of software and dedicated hardware. This module division is for illustrative purposes only and does not limit the actual deployment boundaries of the program.

[0200] This invention can also be implemented using a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it causes the processor to complete the aforementioned method steps. The storage medium can be a disk, solid-state memory, read-only memory, random access memory, or other non-volatile medium capable of storing program instructions.

[0201] The aforementioned judgment rules are used to uniformly express the conditional relationships for resource fact confirmation, result support verification, reconstruction frontier determination, and resource scheduling eligibility judgment, without requiring the scheduling controller to adopt a specific mathematical calculation program. Those skilled in the art can use state machines, conditional branches, rule tables, database condition queries, result dependency graph traversal, or other program structures that can achieve the same judgment semantics.

[0202] When the controller status, version, time estimate, or verification result required for the aforementioned judgment is temporarily unavailable, the scheduling controller will set the corresponding condition to pending verification, without directly interpreting it as already satisfied or invalid, and will not execute irreversible resource release accordingly. When adopting an equivalent procedural structure, the following should still be maintained: the source of delayed results should not be transferred; the actual resource effect should not be reversed by the information status; reconstruction judgment should only be initiated after the last effective support is lost; and resources still used in the retained results or reconstruction process should not regain scheduling eligibility.

[0203] The technical scope of this invention is not limited to the content described above. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this invention, and all such modifications and variations should fall within the protection scope of this invention.

Claims

1. A method for elastic scheduling of computing resources based on edge computing, characterized in that, include: Before the previous elastic action of the same task instance has been closed, a subsequent elastic action is established. The subsequent elastic action inherits a portion of the migration results formed by the previous elastic action, and for each migration result, a supporting implementation is determined to enable it to have at least one of the capabilities of reading, restoring, and continuing execution. The completion result of the resource release operation of the previous elastic action is received. This completion result arrives after the subsequent elastic action establishes the inheritance relationship with the portion of the migration results. The completion result remains attributed to the previous elastic action. The actual resource status confirmed by the corresponding resource controller is queried, and it is confirmed that the actual resource status was formed by the resource release operation. Based on the same actual resource status, the corresponding resource release operation relationship in the previous elastic action is closed. Combined with the resource status confirmed by the corresponding resource controller after the formation of the actual resource status, the supporting implementation of the results inherited by the subsequent elastic action is re-verified. Based on the dependencies between the migration results, the first batch of migration results that lose all effective support for realization due to the change in the actual resource status, but whose necessary predecessor migration results are still effective, are identified as the reconstruction frontier. The migration results that still have effective support for realization are retained, and the reconstruction frontier and its affected subsequent migration results are reconstructed. For resource items that have been actually released, the scheduling eligibility of the resource item is restored when the corresponding resource controller confirms that the resource item is in an allocable state, there is no effective elastic action occupation, the resource item no longer constitutes an effective support for the implementation of the retained migration results, it is not a resource required for the generation, recovery and verification of the reconstruction frontier and its affected subsequent migration results, and there are no pending operations that can change the status of the resource item.

2. The method for elastic scheduling of computing resources based on edge computing according to claim 1, characterized in that, The subsequent elastic action is triggered by at least one of the following: insufficient resources of the target node, abnormal migration path, failure to start the target instance, change of user location, change of task load, and partial failure of the previous elastic action. When establishing the subsequent elastic action, the action identifier of the previous elastic action, the generation identifier of the elastic action of the subsequent elastic action, the source node, the target node, the triggering reason, and the current execution stage of the previous elastic action are recorded.

3. The method for elastic scheduling of computing resources based on edge computing according to claim 1, characterized in that, The determination of the migration results inherited by the subsequent elastic action includes: for each migration result formed by the previous elastic action, verifying the task instance identifier, task state generation identifier, result content summary, parent result relationship, state sequence continuity, target node hardware architecture, target node runtime environment, and migration result access conditions; determining the migration result that meets all verification conditions as the inherited result of the subsequent elastic action, and keeping the generation action of the inherited result still the previous elastic action.

4. The method for elastic scheduling of computing resources based on edge computing according to claim 1, characterized in that, Each of the supporting implementations consists of at least one necessary resource state; when all the necessary resource states are confirmed by the corresponding resource controller, and the content of the corresponding migration result is complete, the resource location is accessible, the access permission is valid, and the target operating environment compatibility requirements are met, the supporting implementation is determined as a valid supporting implementation; when only one valid supporting implementation remains after verifying all supporting implementations of a migration result, the valid supporting implementation is determined as the last valid supporting implementation of the migration result.

5. The method for elastic scheduling of computing resources based on edge computing according to claim 4, characterized in that, Before executing the multiple resource release operations that have not yet been actually completed in the previous elastic action, the multiple resource release operations are formed into an operation set, and the joint resource state after the operation set is jointly executed is determined according to the target state of each resource release operation. If the fence value carried by each resource release operation is consistent with the current fence value of the corresponding resource item, and each of the acceptance results affected by the operation set still has at least one valid support implementation in the joint resource state, the operation set is allowed to be executed; otherwise, the operation set is split, and resource release operations that are allowed to be executed, await the formation of equivalent alternative support, and are prevented from being executed are determined respectively.

6. The method for elastic scheduling of computing resources based on edge computing according to claim 5, characterized in that, When a resource release operation in the operation set will cause at least one of the received results to lose its last valid support implementation, a corresponding equivalent alternative support implementation is formed at least at one of the following: another storage location, target device, target instance, and alternative network path; after the equivalent alternative support implementation completes at least one of the write, transfer, and restore operations corresponding to its type, and passes the verification of content integrity, result lineage, access permissions, and runtime compatibility, the equivalent alternative support implementation is determined as a valid support implementation and the corresponding resource release operation is allowed to be executed; If no effective equivalent alternative is found, the corresponding resource release operation will be prevented.

7. The method for elastic scheduling of computing resources based on edge computing according to claim 1, characterized in that, Confirming that the actual resource status is formed by the resource release operation includes: matching the operation identifier carried by the completion result with the operation identifier, resource item identifier, and target resource status recorded by the corresponding resource controller; when the match is consistent, the resource status confirmed by the resource controller is determined as the actual resource status formed by the resource release operation; without determining that the subsequent flexible action has obtained alternative support implementation based on the completion result, the writing, transmission, or recovery is only completed in another storage location, target device, target instance, or alternative network path that matches the migration result type, and the resulting support implementation is determined as a valid alternative support implementation after verifying content integrity, result lineage, access permissions, and operational compatibility.

8. The method for elastic scheduling of computing resources based on edge computing according to claim 4, characterized in that, Establish migration result dependencies based on the parent result relationships and state sequences among the migration results; determine the effective supporting implementations of each migration result before and after the actual resource state change is written; identify migration results that have at least one effective supporting implementation before the actual resource state change is written, lose all effective supporting implementations after the actual resource state change is written, and whose necessary predecessor migration results are still effective and maintain the continuity of the result lineage as candidate reconstruction results; identify candidate reconstruction results that do not have another candidate reconstruction result as their necessary predecessor migration results as the reconstruction frontier; multiple independent candidate reconstruction results form parallel reconstruction frontiers; determine the affected successor branches of each reconstruction frontier along the migration result dependencies, and only reconstruct the reconstruction frontier and its affected successor branches.

9. The method for elastic scheduling of computing resources based on edge computing according to claim 8, characterized in that, When restoring the scheduling eligibility of a resource item, the current resource occupancy relationship and resource relationship version of the resource item are obtained. The scheduling status of the resource item is updated to schedulable if the current resource occupancy relationship is still closed and the resource relationship version has not changed. If the current resource occupancy relationship or resource relationship version has changed when the update is performed, the restoration of the resource item's scheduling eligibility is stopped, and the actual resource status, resource occupancy relationship, and the demand status of the resource item for the retained migration results and reconstruction frontier are re-queried. The completion results reaching the closed resource occupancy relationship after the resource item's scheduling eligibility is restored are recorded idempotently. The closed resource occupancy relationship is not re-established based on the completion results, nor is the resource occupancy relationship established after the closed resource occupancy relationship is changed.

10. The method for elastic scheduling of computing resources based on edge computing according to claim 7, characterized in that, When the completion result corresponds to a composite resource release operation, the composite resource release operation is broken down into operation units for computing resources, memory resources, accelerator resources, storage resources, network resources, and running instance resources. The actual resource status corresponding to each operation unit is queried. Only the resource release operation relationship corresponding to the operation unit that actually reaches the target status is closed. Only the support implementation that depends on the resource status before the release of the operation unit is determined to be invalid, and the operation unit that has not reached the target status is kept in an open state.

Images