Cloud-edge-end collaborative method based on hierarchical container scheduling and SDN elastic bottom-up

Abstract

This invention provides a cloud-edge-device collaborative method based on hierarchical container scheduling and SDN elastic backup, belonging to the field of IoT technology. It constructs a hierarchical resource pool containing four types of differentiated containers, and establishes an asymmetric "task characteristics-container capabilities" dual-dimensional matching model covering timeliness, complexity, and reliability. Combined with real-time verification based on dynamic remaining load for precise container selection, it achieves differentiated and precise adaptation of heterogeneous tasks at the edge. It also includes establishing an LSTM-based scheduling load prediction and elastic reservation mechanism, dynamically dividing the basic scheduling domain and the elastic computing domain to achieve physical isolation between the control and computing planes. For overflow tasks, it constructs a dual-channel resource superposition mechanism based on the guarantee domain and the incentive domain, employing a dual-weighted linear superposition strategy that uses the complement of the high-precision-difficulty adaptation exponent and is proportional to the comprehensive performance score, simultaneously achieving computing power backup for high-difficulty tasks and accelerated response for highly urgent tasks.

Description

Technical Field

[0001] This invention provides a cloud-edge-device collaboration method based on hierarchical container scheduling and SDN elastic fallback, belonging to the field of Internet of Things (IoT) technology. Background Technology

[0002] With the deep integration of IoT and 5G technologies, cloud-edge-device collaborative computing has become the core architecture for processing massive amounts of heterogeneous data. Container technology, with its advantages of lightweight design and agile deployment, has become a key carrier for edge computing services. However, the existing resource scheduling system faces severe challenges in the face of the increasing concurrency and differentiation of edge tasks (such as a mix of latency-sensitive, computationally intensive, and hardware-dependent tasks).

[0003] Currently, cloud-edge collaborative resource management faces two major bottlenecks: First, the "homogeneous adaptation" problem at the edge. Traditional edge nodes typically use standardized, general-purpose containers for task deployment, lacking a differentiated grading mechanism that considers task characteristics. This "one-size-fits-all" approach to scheduling often leads to resource misallocation: for example, high-priority urgent instructions may time out due to queuing, while complex tasks relying on specific AI acceleration instruction sets may fail to execute because they are assigned to ordinary containers. Second, the "control-computation coupling" risk at the central side. In SDN (software-defined network) based collaborative architectures, the controller often bears the dual responsibility of "network orchestration" and "backup computation." Existing architectures lack effective isolation and protection mechanisms for core resources in the control plane. When edge node resources overflow and trigger a backup mechanism at the central side, the influx of heavy computational tasks can easily crowd out the controller's scheduling resources, leading to routing computation blockage or even network control paralysis, making it difficult to guarantee system stability under extreme conditions.

[0004] Existing technologies suffer from two main shortcomings. Firstly, in terms of container resource adaptation and scheduling strategies, traditional methods lack in-depth analysis of the differences in task characteristics. Current methods often deploy homogeneous, general-purpose containers, failing to uncover the "best match" capability of containers based on the actual attributes of the tasks. Specifically, this manifests in: a lack of diverse container types, failing to differentiate designs based on task timeliness or complexity; a lack of asymmetric adaptation capabilities, with urgent tasks often competing for resources with low-priority tasks, while complex tasks fail due to a lack of specific computing power modules; and rigid scheduling mechanisms, often allocating resources based solely on simple metrics such as CPU utilization, ignoring the dual-dimensional fit between "task characteristics" and "container capabilities." This leads to distorted resource allocation, frequently resulting in delayed responses from high-priority tasks or resource waste from high-performance containers handling simple state polling tasks, severely impacting collaborative efficiency. Secondly, in cross-domain collaboration and controller management, existing architectures often employ a "scheduling-computation" coupled model, lacking protection and flexible fallback mechanisms for the core functions of the controller. This extensive management approach leads to a situation where, when resource overflow at edge nodes triggers a fallback mechanism in the cloud or controller, heavy computing tasks severely congest the controller's scheduling resources, causing network command delivery blockages. Furthermore, traditional methods lack intelligent prediction-based elastic isolation strategies, making it impossible to dynamically partition the computing and scheduling domains during peak task periods, thus hindering the survivability and global management stability of the SDN controller under extreme conditions. Summary of the Invention

[0005] To address the aforementioned issues, this invention proposes a hierarchical container dynamic scheduling method based on task characteristics. First, by constructing a hierarchical resource pool at edge nodes containing four differentiated container types—fast, fine-grained, low-energy, and general-purpose—the traditional limitation of fixed resources for a single container type is broken. A two-dimensional matching model of "task characteristics-container capabilities" is established, incorporating asymmetric exponential decay and hard constraint indicator functions. Then, considering timeliness, complexity, and reliability adaptation factors, and combining real-time feasibility verification based on dynamic remaining load, a matching value calculation formula is constructed to accurately select target containers. Furthermore, a cross-container pool collaborative scheduling and SDN fallback triggering mechanism are set up to achieve differentiated and accurate adaptation and efficient traffic distribution for heterogeneous tasks at the edge, providing an optimized computing power foundation and decision-making premise for subsequent elastic resource collaboration and load balancing.

[0006] Based on the aforementioned hierarchical container dynamic scheduling results, this invention proposes a resource elastic coordination method with SDN as a safety net. First, a scheduling resource load prediction and elastic reservation mechanism based on LSTM (Long Short-Term Memory) is established. This mechanism utilizes the network-wide task flow characteristics to calculate in real-time the resource overhead required to ensure uninterrupted scheduling. At the physical level, a basic scheduling domain and an elastic computing domain are dynamically divided to achieve secure isolation between the control plane and the computing plane. Second, for edge overflow tasks, a dual-channel resource superposition mechanism based on the guarantee domain and the incentive domain is constructed. A dual-weighted linear superposition strategy using high-precision-difficulty adaptation exponent complement and comprehensive performance scoring is adopted to simultaneously achieve a safety net for high-difficulty tasks and accelerated response for highly urgent tasks. Ultimately, functional safety isolation and elastic complementarity are achieved, ensuring the stability of network-wide management and control under extreme conditions.

[0007] The specific technical solution is as follows:

[0008] The cloud-edge-device collaboration method based on hierarchical container scheduling and SDN elastic backup includes the following steps:

[0009] S1. Hierarchical container dynamic scheduling based on task characteristics

[0010] First, a hierarchical resource pool containing four types of differentiated containers—fast, fine-grained, low-energy, and general—is built at the edge nodes.

[0011] Then, based on the full-dimensional task attribute vector description, and taking into account the fit between task characteristics and container capabilities, a two-dimensional matching model including timeliness, complexity and reliability factors is established to accurately select target containers. On this basis, a cross-container pool collaborative scheduling and SDN fallback triggering mechanism are set up to achieve differentiated adaptation and efficient execution of tasks with different characteristics.

[0012] S2 Resource Elastic Collaboration Based on SDN as a Backup

[0013] First, to address the resource contention issue caused by the coupling of "scheduling-computation" functions in the SDN controller, an LSTM-based scheduling overhead prediction model is constructed. This model utilizes the temporal distribution of task feature vectors to accurately predict and lock the minimum resources required to ensure stable operation of the control plane, dynamically dividing the basic scheduling domain and the elastic computing domain at the physical level.

[0014] Secondly, by utilizing the remaining elastic computing resources, a dual-channel resource superposition mechanism based on the guarantee domain and incentive domain is established for edge overflow tasks: for high-precision and difficult tasks, the adaptive index complement is used to achieve a computing power safety net, and for other tasks, a comprehensive performance score is used to allocate resources to achieve acceleration incentives.

[0015] Furthermore, S1 specifically includes the following sub-steps:

[0016] S1.1 Construction of a hierarchical container resource pool for edge nodes with differentiated functions

[0017] At the edge node side, computing, storage, and specific functional module resources are virtualized and sliced ​​to construct a hierarchical container resource pool with differentiated functions. .

[0018] The container specifically refers to: a fine container. It comes pre-configured with complete specific capability modules and matches them with high CPU and memory resource quotas; fast containers. It reserves high-frequency CPU cores but avoids mounting complex, specific capability modules to minimize cold start overhead, enabling millisecond-level rapid startup and deployment. It is specifically designed for handling extremely latency-sensitive, sudden, and urgent tasks; low-energy containers. This strictly limits the maximum CPU frequency and memory usage, retaining only the minimum resource baseline required for processing basic tasks to save energy; while general-purpose containers It is configured with a standard operating system and a balanced resource allocation to handle routine business and serve as an elastic supplement to the resource pool.

[0019] S1.2 Container Optimization Based on a Two-Dimensional Matching Model of "Task Characteristics-Container Capabilities"

[0020] A two-dimensional matching model based on "task characteristics - container capabilities" was established:

[0021] First, define the task set as Before making a scheduling decision, it is necessary to analyze the tasks to be scheduled. To perform feature vectorization, its attribute vector is defined as follows: .in, For the first The business priority of each task The maximum response time required by the task. and These are instruction set size and data throughput, respectively. For a specific set of capability modules that serve as hard constraints, This represents the minimum basic resources required for the task to run. Calculate the load for the task. Let the task complexity be denoted as . Based on the aforementioned attribute vector, let the candidate container types in the edge node resource pool be . , Define task With container The combined matching value of the two This value takes into account both task feature suitability and container resource suitability, and the calculation formula is as follows:

[0022] (1)

[0023] In the formula, This indicates the task feature fit, used to measure the degree to which the container's functional attributes match the task requirements; This indicates the container resource adaptability, which measures the surplus of resources that the container's real-time resource status can support the task. For normalized weight coefficients, satisfying Among them, task feature fit The focus is on measuring the logical fit between the container's functional attributes and task requirements. Its calculation needs to cover three core characteristic factors—timeliness, complexity, and reliability—through a weighted summation method.

[0024] (2)

[0025] In the formula, The weights are assigned to three core characteristic factors: timeliness, complexity, and reliability.

[0026] For the three characteristic factors mentioned above, specific quantitative logic is designed. First, regarding the timeliness adaptation factor... It reflects the container Response limits and tasks Deadline matching status. This refers to the ratio of the container's computation latency to the task's maximum response latency. The closer the value is to 1, the higher the container fit value, thus reducing resource waste; conversely, the lower the fit value, the lower the fit value. A calculation formula based on asymmetric exponential decay is constructed, namely:

[0027] (3)

[0028] In the formula, For containers The computational latency of processing the task is expressed as: , For containers Computing resources; Let be the characteristic function, which is represented as ,and . It is a constant.

[0029] Secondly, regarding the complexity adaptation factor This mechanism aims to mitigate task failures caused by the lack of specific capability modules, while simultaneously achieving a precise balance between computational resources and task load. The formula for calculating this factor is as follows:

[0030] (4)

[0031] In the formula, This is a function indicating a hard constraint on functionality. If the container... Having a mission The required full set of specific capability modules (i.e.) ),but Otherwise, it is judged as 0. For the size of the container's instruction set, The amount of data that the container can handle.

[0032] Finally, reliability adaptation factor The aim is to predict mission success rate based on the container's historical performance. Considering the unidirectional rigidity of reliability requirements, this factor is calculated as follows:

[0033] (5)

[0034] In the formula, For containers The completion rate of historical tasks This is a reliability weighting factor.

[0035] After completing the adaptation calculation for the task feature dimensions, calculate the container resource adaptation degree. , represented as:

[0036] (6)

[0037] In the formula, Representing three basic resource dimensions: Indicates the number of CPU cores in the container. Indicates the container's memory capacity, Indicates network bandwidth; For containers The current amount of remaining available resources; For the task The required amount of resources; among which .

[0038] Based on the above two-dimensional calculation results, the system executes the target container optimization strategy, traverses all available container types in the resource pool, and selects the comprehensive matching value. The tallest container is used as the target container. .

[0039] (7)

[0040] Specifically, if multiple container types have the same matching value during the calculation process, the system will incorporate the historical matching success rate. The results are weighted and adjusted to prioritize container types with higher historical success rates, thereby achieving a closed-loop decision-making process from "theoretical matching" to "empirical optimization".

[0041] S1.3 Cross-container pool collaborative scheduling strategy and SDN fallback triggering mechanism

[0042] Based on the model described in S1.2, the theoretically optimal target container type is selected. Subsequently, to address unavailability caused by container load fluctuations during actual operation, a multi-level scheduling strategy incorporating local coordination and remote fallback is proposed. The specific implementation steps are as follows:

[0043] Step 1: Perform a feasibility check on the target container.

[0044] The system first selects the target container. Perform real-time feasibility verification based on a time window. The core of the verification is to determine whether the current queuing status of the container will cause the task to time out. Introduce dynamic remaining load calculation logic. Defined at the current time... ,Task In the target container Real-time estimated completion time The calculation formula is as follows:

[0045] (8)

[0046] In the formula, For the task Residual computational workload, For the currently selected container Computing resources; For the task In container Real-time queuing delay.

[0047] Construct a feasibility judgment function, which is expressed as:

[0048] (9)

[0049] like If so, the task is directly sent to the target container for execution, and the scheduling ends; if If the target container is currently unavailable, proceed to step 2.

[0050] Step 2: Cross-container pool collaborative scheduling

[0051] When the target container cannot meet the task requirements, the system initiates cross-container pool collaborative scheduling. At this point, it is no longer limited to a single container type, but rather traverses the resource pools of edge nodes. Except For other container types besides the one mentioned above, construct a valid alternative set, which is represented as:

[0052] (10)

[0053] like The system selects the container with the highest overall matching value from the set as the alternative execution node. It is represented as:

[0054] (11)

[0055] Step 3: SDN Controller Last-Comeback Trigger Mechanism

[0056] If, after traversing step 2, the set of valid substitutes is found to be empty, that is... This indicates that the edge node is currently running at full capacity or has a task. The complexity exceeded the capacity of all local containers. At this point, the system generates an SDN fallback trigger signal, which is represented as:

[0057] (12)

[0058] when When this happens, the edge node immediately stops local scheduling attempts and redirects the task. Mark it as an "overflow task" and set its task attributes. The information is reported to the SDN controller, triggering the subsequent S2-based resource elastic coordination method, whereby the controller takes over the resource allocation rights.

[0059] Furthermore, S2 specifically includes the following sub-steps:

[0060] S2.1 Resource load forecasting and elastic reservation guided by scheduling function guarantee

[0061] An LSTM scheduling overhead prediction model is constructed to perceive scheduling pressure by aggregating full-dimensional features of tasks across the entire network. The system periodically aggregates data reported by edge nodes across the entire network to predict the current time. All tasks that have been completed attribute vector Statistical aggregation is performed to construct a high-dimensional feature vector of the entire network task flow, which is represented as follows:

[0062] (13)

[0063] The full-dimensional vector sequence is input into an LSTM network, and the forget gate and input gate are used to capture the dependencies of multi-dimensional task features over time, outputting... Predicted values ​​of scheduling computational resource requirements at any given time , represented as:

[0064] (14)

[0065] In the formula, and These represent the hidden state and the cell state from the previous time step, respectively. Based on the prediction results, a safety redundancy coefficient is introduced. , Compute SDN's reserved computing resources This portion of computing resources was forcibly locked for the control plane, leaving the remaining computing resources... This constitutes an elastic computing domain, used to execute the fallback task described in S2.2, wherein This represents the total computing resources for SDN.

[0066] S2.2 SDN Elastic Backup Decision and Resource Allocation Based on Dual-Channel Resource Overlay

[0067] For the set of all edge overflow tasks that trigger the SDN fallback mechanism The controller directly calls the elastic computing domain resources predicted and partitioned in S2.1. A dual-channel resource allocation mechanism based on the guarantee domain and incentive domain is constructed. This mechanism dynamically divides the total elastic resources into basic guarantee resources. With flexible incentive resources The two parts are weighted based on the suitability for high-precision and difficult tasks and the comprehensive performance score, and finally the allocation is completed by linear superposition.

[0068] Specifically, the system first iterates through all container types in the edge resource pool and calculates the task. High-precision and difficult task adaptability index This index reflects the availability of specific capability modules required for a task on the edge side, and is calculated using the following formula:

[0069] (15)

[0070] In the formula, The total number of containers in the hierarchical container resource pool for edge nodes.

[0071] Construct a resource allocation model. Define a comprehensive performance scoring function. for:

[0072] (16)

[0073] In the formula, For the task There is still a delay to wait for; These are the corresponding weight coefficients, and .

[0074] Based on the aforementioned high-precision and difficult task adaptability index With comprehensive performance evaluation Based on the calculation results, a dual-channel resource allocation mechanism based on the guarantee domain and the incentive domain is constructed. This mechanism dynamically divides the total elastic computing resources into two parts: basic guarantee resources and elastic incentive resources, and adopts differentiated weighted allocation strategies for each part.

[0075] On the one hand, considering the adaptability to highly complex and demanding tasks, a weighted strategy based on the complement of the highly complex and demanding task adaptability index is adopted to allocate basic support resources. Because this index... This reflects the availability of specific capability modules required for a task on the edge. A lower value indicates a stronger dependence on specific computing power and a higher processing difficulty. By using complement weighting, such high-difficulty tasks can receive more computing power allocation, thus serving as a "safety net" to reduce the risk of execution failure due to the lack of edge-side capabilities.

[0076] On the other hand, considering the urgency and workload of task execution, a comprehensive performance function-based approach is adopted. The proportional weighting strategy allocates elastic incentive resources, enabling high-load-density and high-priority tasks to receive additional "accelerated" computing power to ensure their rapid response. Ultimately, SDN provides tasks with... Allocated resources Specifically as follows:

[0077] (17)

[0078] In the formula, and Let be the total amount of computing resources allocated to the two sets, and satisfy . .

[0079] The technical effects of the present invention are as follows:

[0080] 1. This invention proposes a hierarchical container dynamic scheduling method based on task characteristics. First, a hierarchical resource pool containing four types of differentiated containers is constructed, establishing an asymmetric "task characteristic-container capability" dual-dimensional matching model covering timeliness, complexity, and reliability. Second, real-time verification based on dynamic remaining load is used to accurately select the best container, and cross-pool collaboration and SDN fallback mechanisms are implemented. Ultimately, this achieves differentiated and accurate adaptation of heterogeneous tasks at the edge, effectively avoiding resource mismatch and significantly improving the response speed and execution success rate of urgent and complex tasks.

[0081] 2. This invention proposes a resource elastic coordination method based on SDN as a safety net. First, an LSTM-based scheduling load prediction and elastic reservation mechanism is established, dynamically dividing the basic scheduling domain and the elastic computing domain to achieve physical isolation between the control and computation planes. Second, for overflow tasks, a dual-channel resource superposition mechanism based on the guarantee domain and the incentive domain is constructed. A dual-weighted linear superposition strategy, proportional to the high-precision-difficulty adaptation exponent complement and the comprehensive performance score, is adopted to simultaneously achieve a safety net of computing power for high-difficulty tasks and accelerated response for highly urgent tasks. Finally, this completely solves the pain point of controller scheduling blockage, balancing the release of powerful computing power with the stability of overall network control. Attached Figure Description

[0082] Figure 1 This is a flowchart of the present invention. Detailed Implementation

[0083] like Figure 1 As shown, the cloud-edge-device collaborative method based on hierarchical container scheduling and SDN elastic backup includes the following steps:

[0084] S1. Hierarchical container dynamic scheduling based on task characteristics

[0085] First, by constructing a tiered resource pool at edge nodes containing four differentiated containers—fast, fine-grained, low-energy, and general-purpose—the resource fixation limitations of traditional single-container types are broken. Then, based on a full-dimensional task attribute vector description, and comprehensively considering the fit between task characteristics and container capabilities, a two-dimensional matching model incorporating timeliness, complexity, and reliability factors is established to accurately select target containers. Furthermore, a cross-container pool collaborative scheduling and SDN fallback triggering mechanism are implemented to achieve differentiated adaptation and efficient execution of tasks with different characteristics, effectively avoiding resource preemption and scheduling delays, and providing an optimized edge-side computing power foundation for subsequent elastic SDN resource collaboration.

[0086] Specifically, it includes the following sub-steps:

[0087] S1.1 Construction of a hierarchical container resource pool for edge nodes with differentiated functions

[0088] To address the issue that existing cloud-edge collaborative scenarios suffer from limited container types and inability to adapt to diverse task requirements, this invention constructs a hierarchical container resource pool with differentiated functions by virtualizing and slicing computing, storage, and specific functional module resources at the edge node side. The containers are described in detail below: Fine containers It comes pre-loaded with complete specific capability modules (such as an AI inference engine and a floating-point arithmetic library) and is matched with a high quota of CPU and memory resources, making it specifically suitable for handling sophisticated tasks such as deep model inference and high-precision numerical calculations, thereby meeting the stringent requirements of such businesses for environmental integrity and computational accuracy; rapid containerization Although it reserves high-frequency CPU cores, it avoids mounting complex, specific capability modules to minimize cold-start overhead, enabling millisecond-level fast startup and rapid deployment. It is specifically designed for handling extremely latency-sensitive, sudden, and urgent tasks; low-energy containers. This strictly limits the maximum CPU frequency and memory usage, retaining only the minimum resource baseline required for processing basic tasks to save energy; while general-purpose containers These containers are configured with a standard operating system and a balanced resource allocation to handle routine business operations and serve as an elastic supplement to the resource pool. The main differences between them lie in the configuration of specific capability modules and the different allocations of computing resources, thereby meeting the rapid response needs of different business scenarios.

[0089] S1.2 Container Optimization Based on a Two-Dimensional Matching Model of "Task Characteristics-Container Capabilities"

[0090] To achieve precise matching between differentiated tasks and hierarchical containers and avoid resource mismatch, this invention establishes a two-dimensional matching model of "task characteristics - container capabilities".

[0091] First, define the task set as Before making a scheduling decision, it is necessary to analyze the tasks to be scheduled. To perform feature vectorization, its attribute vector is defined as follows: .in, For the first The business priority of each task (the more urgent the task, the closer the value is to 1). The maximum response time required by the task. and These are instruction set size and data throughput, respectively. For a specific set of capability modules that serve as hard constraints, This represents the minimum basic resources required for the task to run. Calculate the load for the task. Let the task complexity be denoted as . Based on the aforementioned attribute vector, let the candidate container types in the edge node resource pool be . ( Define the task With container The combined matching value of the two This value takes into account both task feature suitability and container resource suitability, and the calculation formula is as follows:

[0092] (1)

[0093] In the formula, This indicates the task feature fit, used to measure the degree to which the container's functional attributes match the task requirements; This indicates the container resource adaptability, which measures the surplus of resources that the container's real-time resource status can support the task. For normalized weight coefficients, satisfying Among them, task feature fit The focus is on measuring the logical fit between the container's functional attributes and task requirements. Its calculation needs to cover three core characteristic factors—timeliness, complexity, and reliability—through a weighted summation method.

[0094] (2)

[0095] In the formula, The weights are assigned to three core characteristic factors: timeliness, complexity, and reliability.

[0096] For the three characteristic factors mentioned above, this invention designs specific quantification logic. First, regarding the timeliness adaptation factor... It reflects the container Response limits and tasks Deadline matching status. This refers to the ratio of the container's computation latency to the task's maximum response latency. The closer the value is to 1, the higher the container fit value, thus reducing resource waste; conversely, the lower the fit value, the lower the fit value. This invention constructs a calculation formula based on asymmetric exponential decay, namely:

[0097] (3)

[0098] In the formula, For containers The computational latency of processing the task is expressed as: , For containers Computing resources; Let be the characteristic function, which is represented as ,and . It is a constant.

[0099] Secondly, regarding the complexity adaptation factor This mechanism aims to mitigate task failures caused by the lack of specific capability modules, while simultaneously achieving a precise balance between computational resources and task load. The formula for calculating this factor is as follows:

[0100] (4)

[0101] In the formula, This is a function indicating a hard constraint on functionality. If the container... Having a mission The required full set of specific capability modules (i.e.) ),but Otherwise, it is judged as 0 (i.e., completely unsuitable). For the size of the container's instruction set, The amount of data that the container can handle.

[0102] Finally, reliability adaptation factor The aim is to predict mission success rate based on the container's historical performance. Considering the unidirectional rigidity of reliability requirements (i.e., container reliability must not be lower than mission requirements), this factor is calculated as follows:

[0103] (5)

[0104] In the formula, For containers The completion rate of historical tasks This is a reliability weighting factor.

[0105] After completing the adaptation calculation for the task feature dimensions, this invention further calculates the container resource adaptation degree. This indicator does not focus on whether the task is "doable," but rather on whether the container currently has sufficient "resource reserves." To prevent a shortage of one type of resource from being masked by an abundance of other resources, and to reflect the law of diminishing marginal utility of resource surplus, it is expressed as follows:

[0106] (6)

[0107] In the formula, Representing three basic resource dimensions: Indicates the number of CPU cores in the container. Indicates the container's memory capacity, Indicates network bandwidth; For containers The current amount of remaining available resources; For the task The required amount of resources; among which .

[0108] Based on the above two-dimensional calculation results, the system executes the target container optimization strategy, traverses all available container types in the resource pool, and selects the comprehensive matching value. The tallest container is used as the target container. .

[0109] (7)

[0110] In particular, if multiple container types have the same matching value during the calculation process (e.g.) The system will incorporate historical matching success rates. The results are weighted and adjusted to prioritize container types with higher historical success rates, thereby achieving a closed-loop decision-making process from "theoretical matching" to "empirical optimization".

[0111] S1.3 Cross-container pool collaborative scheduling strategy and SDN fallback triggering mechanism

[0112] Based on the model described in S1.2, the theoretically optimal target container type is selected. Subsequently, to address unavailability caused by container load fluctuations during actual operation, this invention proposes a multi-level scheduling strategy that includes local coordination and remote fallback. The specific implementation steps are as follows:

[0113] Step 1: Perform a feasibility check on the target container.

[0114] The system first selects the target container. Real-time feasibility verification is performed based on a time window. The core of the verification is to determine whether the current queuing status of the container will cause the task to time out. Considering that the currently executing task may have completed part of its progress, this invention introduces dynamic remaining load calculation logic. Defined at the current moment... ,Task In the target container Real-time estimated completion time The calculation formula is as follows:

[0115] (8)

[0116] In the formula, For the task Residual computational workload, For the currently selected container Computing resources; For the task In container Real-time queuing delay.

[0117] Construct a feasibility judgment function, which is expressed as:

[0118] (9)

[0119] like If so, the task is directly sent to the target container for execution, and the scheduling ends; if If the target container is currently unavailable, proceed to step 2.

[0120] Step 2: Cross-container pool collaborative scheduling

[0121] When the target container cannot meet the task requirements, the system initiates cross-container pool collaborative scheduling. At this point, it is no longer limited to a single container type, but rather traverses the resource pools of edge nodes. Except For other container types besides the one mentioned above, construct a valid alternative set, which is represented as:

[0122] (10)

[0123] This set contains all currently capable and resource-sufficient non-preferred containers. If The system selects the container with the highest overall matching value from the set as the alternative execution node. It is represented as:

[0124] (11)

[0125] Through this step, the task achieves "downgrade adaptation" or "cross-type scheduling" within the edge node, making the most of local idle resources.

[0126] Step 3: SDN Controller Last-Comeback Trigger Mechanism

[0127] If, after traversing step 2, the valid substitution set is found to be empty (i.e.) This indicates that the edge node is currently running at full capacity or has a task. The complexity exceeded the capacity of all local containers. At this point, the system generates an SDN fallback trigger signal, which is represented as:

[0128] (12)

[0129] when When this happens, the edge node immediately stops local scheduling attempts and redirects the task. Mark it as an "overflow task" and set its task attributes. The information is reported to the SDN controller, triggering the subsequent S2-based resource elastic coordination method, whereby the controller takes over the resource allocation rights.

[0130] S2 Resource Elastic Collaboration Based on SDN as a Backup

[0131] First, addressing the resource contention issue caused by the coupling of "scheduling-computation" functions in the SDN controller, an LSTM-based scheduling overhead prediction model is constructed. This model utilizes the temporal distribution of task feature vectors to accurately predict and lock the minimum resources required to ensure stable operation of the control plane, dynamically dividing the basic scheduling domain and the elastic computing domain at the physical level. Second, utilizing the remaining elastic computing resources, a dual-channel resource superposition mechanism based on the guarantee domain and incentive domain is established for edge overflow tasks: for highly sophisticated and difficult tasks, adaptive exponential complement weighting is used to provide a backup computing power, while for other tasks, comprehensive performance scoring is used to allocate resources for acceleration incentives. This achieves a shift from "resource contention" to "elastic isolation and dual complementarity," ensuring that the SDN controller maintains the absolute stability of core network management services while providing backup computing power on the central side. Highly sophisticated and difficult tasks refer to tasks with high precision and difficulty, requiring substantial computing resources and relatively complete capability modules to complete.

[0132] Specifically, it includes the following sub-steps:

[0133] S2.1 Resource load forecasting and elastic reservation guided by scheduling function guarantee

[0134] To prevent heavy computational tasks from overloading the SDN controller's control plane, the system needs to predict the CPU resource overhead required to maintain normal scheduling decisions in real time. This invention constructs an LSTM scheduling overhead prediction model. This model is no longer limited to a single load metric but perceives scheduling pressure by aggregating the full-dimensional characteristics of all tasks across the network. The system periodically aggregates data reported by edge nodes across the entire network to predict the scheduling load at the current time. All tasks that have been completed attribute vector Statistical aggregation is performed to construct a high-dimensional feature vector of the entire network task flow, which is represented as follows:

[0135] (13)

[0136] The full-dimensional vector sequence is input into an LSTM network, and the forget gate and input gate are used to capture the dependencies of multi-dimensional task features over time, outputting... Predicted values ​​of scheduling computational resource requirements at any given time , represented as:

[0137] (14)

[0138] In the formula, and These represent the hidden state and the cell state from the previous time step, respectively. Based on the prediction results, a safety redundancy coefficient is introduced. , Compute SDN's reserved computing resources This portion of computing resources was forcibly locked for the control plane, leaving the remaining computing resources... This constitutes an elastic computing domain, used to execute the fallback task described in S2.2, wherein This represents the total computing resources for SDN.

[0139] S2.2 SDN Elastic Backup Decision and Resource Allocation Based on Dual-Channel Resource Overlay

[0140] For the set of all edge overflow tasks that trigger the SDN fallback mechanism The controller directly calls the elastic computing domain resources predicted and partitioned in S2.1. This invention departs from a rigid, either-or allocation approach, instead constructing a dual-channel resource allocation mechanism based on a guarantee domain and an incentive domain. This mechanism dynamically divides the total elastic resources into basic guarantee resources. With flexible incentive resources The two parts are weighted based on the suitability for high-precision and difficult tasks and the comprehensive performance score, and finally the allocation is completed by linear superposition.

[0141] Specifically, the system first iterates through all container types in the edge resource pool and calculates the task. High-precision and difficult task adaptability index This index reflects the availability of specific capability modules required for a task on the edge side, and is calculated using the following formula:

[0142] (15)

[0143] In the formula, The total number of containers in the hierarchical container resource pool for edge nodes.

[0144] Based on this, and to balance the difficulty of task processing with the urgency of dynamic processing, this invention constructs a resource allocation model. A comprehensive performance scoring function is defined. for:

[0145] (16)

[0146] In the formula, For the task There is still a delay to wait for; These are the corresponding weight coefficients, and .

[0147] Based on the aforementioned high-precision and difficult task adaptability index With comprehensive performance evaluation Based on the calculation results, this invention constructs a dual-channel resource superposition allocation mechanism based on the guarantee domain and the incentive domain. This mechanism no longer performs single-dimensional threshold segmentation of tasks, but dynamically divides the total elastic computing resources into two parts: basic guarantee resources and elastic incentive resources, and adopts differentiated weighted allocation strategies for each. On the one hand, for tasks with high precision and difficulty adaptability, a weighted strategy based on the complement of the high precision and difficulty adaptability index is used to allocate basic guarantee resources. Because this index... This reflects the availability of specific capability modules required for the task on the edge side; a lower value indicates a stronger dependence on specific computing power and a higher processing difficulty. Therefore, by using complement weighting, such high-difficulty tasks can receive more computing power allocation, serving as a "safety net" to reduce the risk of execution failure due to a lack of edge-side capabilities. On the other hand, considering the urgency and workload of the task execution, a comprehensive performance function is adopted. The proportional weighting strategy allocates elastic incentive resources, enabling high-load-density and high-priority tasks to receive additional "accelerated" computing power to ensure their rapid response. Ultimately, SDN provides tasks with... Allocated resources Specifically as follows:

[0148] (17)

[0149] In the formula, and Let be the total amount of computing resources allocated to the two sets, and satisfy . .

[0150] Through the above steps, this invention achieves resource elastic coordination based on SDN as a safety net. This method utilizes an LSTM-based scheduling resource overhead prediction model to establish physical isolation between the basic scheduling domain and the elastic computing domain. Furthermore, it employs a dual-channel resource overlay mechanism to ensure stability for high-precision and complex tasks while incentivizing performance for other tasks. This ensures that when handling extremely complex tasks, the system can leverage the powerful backup computing power of the central side while maintaining the absolute stability of core network management services.

Claims

1. A cloud-edge-device collaborative method based on hierarchical container scheduling and SDN elastic fallback, characterized in that, Includes the following steps: S1. Hierarchical container dynamic scheduling based on task characteristics First, a hierarchical resource pool containing four types of differentiated containers—fast, fine-grained, low-energy, and general—is built at the edge nodes. Then, based on the full-dimensional task attribute vector description, and taking into account the fit between task characteristics and container capabilities, a two-dimensional matching model including timeliness, complexity and reliability factors is established to accurately select target containers; and on this basis, a cross-container pool collaborative scheduling and SDN fallback triggering mechanism are set up to achieve differentiated adaptation and efficient execution of tasks with different characteristics. S2 Resource Elastic Collaboration Based on SDN First, to address the resource contention pain point caused by the coupling of the "scheduling-computation" functions of the SDN controller, an LSTM-based scheduling overhead prediction model is constructed. This model utilizes the temporal distribution of task feature vectors to accurately predict and lock the minimum resources required to ensure the stable operation of the control plane, and dynamically divides the basic scheduling domain and the elastic computing domain at the physical level. Secondly, by utilizing the remaining elastic computing resources, a dual-channel resource superposition mechanism based on the guarantee domain and the incentive domain is established for edge overflow tasks: for high-precision and difficult tasks, the adaptive index complement weighting is used to achieve computing power backup, and for other tasks, comprehensive performance scoring is used to allocate resources to achieve acceleration incentives. The system first iterates through all container types in the edge resource pool and calculates the task. High-precision and difficult task adaptability index This index reflects the availability of specific capability modules required for a task on the edge side, and is calculated using the following formula: ， In the formula, The total number of containers in the hierarchical container resource pool for edge nodes; This is a function that indicates a hard constraint on functionality. Construct a resource allocation model; define a comprehensive performance scoring function. for: ， In the formula, For the task There is still time to wait; These are the corresponding weight coefficients, and ; For the task Residual computational workload, For task complexity; For the first The business priority of each task; Based on the aforementioned high-precision and difficult task adaptability index With comprehensive performance evaluation Based on the calculation results, a dual-channel resource allocation mechanism based on the guarantee domain and the incentive domain is constructed. This mechanism dynamically divides the total elastic computing resources into two parts: basic guarantee resources and elastic incentive resources, and adopts differentiated weighted allocation strategies for each part. On the one hand, considering the adaptability to highly demanding and complex tasks, a weighted strategy based on the complement of the highly demanding and complex task adaptability index is adopted to allocate basic support resources; because this index It reflects the prevalence of specific capability modules required by the task on the edge side. The lower the value, the stronger the task's dependence on specific computing power and the higher the processing difficulty. By using the complement weighting, such high-difficulty tasks can obtain more computing power allocation, which serves as a "safety net" to reduce the risk of execution failure due to the lack of edge side capabilities. On the other hand, considering the urgency and workload of task execution, a comprehensive performance function-based approach is adopted. The proportional weighting strategy allocates elastic incentive resources, enabling high-load-density and high-priority tasks to receive additional "accelerated" computing power to ensure their rapid response; ultimately, SDN provides tasks with... Allocated resources Specifically as follows: ， In the formula, and Let be the total amount of computing resources allocated to the two sets, and satisfy . .

2. The cloud-edge-device collaborative method based on hierarchical container scheduling and SDN elastic fallback as described in claim 1, characterized in that, S1 specifically includes the following sub-steps: S1.1 Construction of a hierarchical container resource pool for edge nodes with differentiated functions At the edge node side, computing, storage, and specific functional module resources are virtualized and sliced ​​to construct a hierarchical container resource pool with differentiated functions. ; The container specifically refers to: a fine container. It comes pre-configured with complete specific capability modules and is matched with a high quota of CPU and memory resources; Quick Containers It reserves high-frequency CPU cores but avoids mounting complex, specific capability modules to minimize cold start overhead, enabling millisecond-level rapid startup and deployment. It is specifically designed for handling extremely latency-sensitive, sudden, and urgent tasks; low-energy containers. This strictly limits the maximum CPU frequency and memory usage, retaining only the minimum resource baseline required for processing basic tasks to save energy; while general-purpose containers It is configured with a standard operating system and a balanced resource allocation to handle routine business and serve as an elastic supplement to the resource pool. S1.2 Container Optimization Based on a Two-Dimensional Matching Model of "Task Features - Container Capabilities" A two-dimensional matching model based on "task characteristics - container capabilities" was established: First, define the task set as Before executing a scheduling decision, it is necessary to analyze the tasks to be scheduled. To perform feature vectorization, its attribute vector is defined as follows: ;in, For the first The business priority of each task The maximum response latency required by the task. and These are instruction set size and data throughput, respectively. For a specific set of capability modules that serve as hard constraints, This represents the minimum basic resources required for the task to run. Calculate the load for the task. Let the task complexity be denoted as ; based on the aforementioned attribute vector, let the candidate container types in the edge node resource pool be . , Define task With container The combined matching value of the two This value takes into account both task feature suitability and container resource suitability, and the calculation formula is as follows: ， In the formula, This indicates the task feature fit, used to measure the degree to which the container's functional attributes match the task requirements; This indicates the container resource adaptability, which measures the surplus of resources that the container's real-time resource status can support the task. For normalized weight coefficients, satisfying Among them, task feature fit It focuses on measuring the logical fit between the container's functional attributes and task requirements. Its calculation needs to cover three core characteristic factors—timeliness, complexity, and reliability—through a weighted summation method. , , : ， In the formula, The weights are assigned to three core characteristic factors: timeliness, complexity, and reliability. After completing the adaptation calculation for the task feature dimensions, calculate the container resource adaptation degree. , is represented as: ， In the formula, Representing three basic resource dimensions: Indicates the number of CPU cores in the container. Indicates the container's memory capacity, Indicates network bandwidth; For containers The current amount of remaining available resources; For the task The required amount of resources; among which ; Based on the above two-dimensional calculation results, the system executes the target container optimization strategy, traverses all available container types in the resource pool, and selects the comprehensive matching value. The tallest container is used as the target container. ; ， If multiple container types have the same matching value during the calculation process, the system will incorporate historical matching success rates. The results are weighted and adjusted to prioritize container types with higher historical success rates, thereby achieving a decision-making loop from "theoretical matching" to "experience-based optimization".

3. The cloud-edge-device collaborative method based on hierarchical container scheduling and SDN elastic fallback as described in claim 2, characterized in that, S1.2 defines three core feature factors, and specific quantitative logic is designed accordingly. First, regarding the timeliness adaptation factor It reflects the container Response limits and tasks Deadline matching; the ratio of the container's computation latency to the task's maximum response latency. The closer the value is to 1, the higher the container fit value, thus reducing resource waste; conversely, the lower the fit value, the better. A calculation formula based on asymmetric exponential decay is constructed, namely: ， In the formula, For containers The computational latency of the task is expressed as , For containers Computing resources; Let be the characteristic function, which is represented as ,and ; It is a constant; Secondly, regarding the complexity adaptation factor This factor aims to avoid task execution failures caused by the lack of specific capability modules, while achieving a precise balance between computational resources and task load; the calculation formula for this factor is as follows: ， In the formula, For functional hard constraint indicator functions; if the container Having a mission The required full set of specific capability modules, i.e. ,but Otherwise, it is judged as 0; For the size of the container's instruction set, The amount of data that the container can handle; Finally, reliability adaptation factor The aim is to predict mission success rate based on the container's historical performance; considering the unidirectional rigidity of reliability requirements, the factor is calculated as follows: ， In the formula, For containers The completion rate of historical tasks This is a reliability weighting factor.

4. The cloud-edge-device collaborative method based on hierarchical container scheduling and SDN elastic fallback as described in claim 2, characterized in that, S1 also includes sub-steps: S1.3 Cross-container pool collaborative scheduling strategy and SDN fallback triggering mechanism Based on the model described in S1.2, the theoretically optimal target container type is selected. Subsequently, in order to address unavailability caused by container load fluctuations in actual operation, a multi-level scheduling strategy including local coordination and remote backup is proposed.

5. The cloud-edge-device collaborative method based on hierarchical container scheduling and SDN elastic fallback as described in claim 4, characterized in that, The specific implementation steps of S1.3 are as follows: Step 1: Perform a feasibility check on the target container. The system first selects the target container. Perform real-time feasibility verification based on time windows; The core of the verification lies in determining whether the current queuing status of the container will cause the task to time out; it introduces dynamic remaining load calculation logic; and it defines the current time... ,Task In the target container Real-time estimated completion time The calculation formula is as follows: ， In the formula, For the task Residual computational workload, For the currently selected container Computing resources; For the task In container Real-time queuing delay; Construct a feasibility discrimination function, which is expressed as: ， like If so, the task is directly sent to the target container for execution, and the scheduling ends; if If the target container is currently unavailable, proceed to step 2. Step 2: Cross-container pool collaborative scheduling When the target container cannot meet the task requirements, the system initiates cross-container pool collaborative scheduling; at this point, it is no longer limited to a single container type, but rather traverses the resource pools of edge nodes. Except For other container types besides the one mentioned above, construct a valid alternative set, which is represented as: ， like The system selects the container with the highest overall matching value from the set as the alternative execution node. It is represented as: ， Step 3: SDN Controller Last-Comeback Trigger Mechanism If, after traversing step 2, the set of valid substitutes is found to be empty, that is... This indicates that the edge node is currently running at full capacity or has a task. The complexity exceeded the capacity limit of all local containers; at this point, the system generates an SDN fallback trigger signal, which is represented as: ， when When this happens, the edge node immediately stops local scheduling attempts and redirects the task. Mark it as an "overflow task" and set its task attributes. The information is reported to the SDN controller, triggering the subsequent S2-based resource elastic coordination method, whereby the controller takes over the resource allocation rights.

6. The cloud-edge-device collaborative method based on hierarchical container scheduling and SDN elastic fallback as described in claim 5, characterized in that, S2 specifically includes the following sub-steps: S2.1 Resource load forecasting and elastic reservation guided by scheduling function guarantee An LSTM scheduling overhead prediction model is constructed to perceive scheduling pressure by aggregating the full-dimensional features of tasks across the entire network; the system periodically aggregates data reported by edge nodes across the entire network to predict the current time. All tasks that have been completed attribute vector Statistical aggregation is performed to construct a high-dimensional feature vector of the entire network task flow, which is represented as follows: ， The full-dimensional vector sequence is input into an LSTM network, and the forget gate and input gate are used to capture the dependencies of multi-dimensional task features over time, outputting... Forecast values ​​of scheduling computational resource requirements at any given time , is represented as: ， In the formula, and These represent the hidden state and the cell state at the previous time step, respectively; based on the prediction results, a safety redundancy coefficient is introduced. , Compute SDN's reserved computing resources ; This portion of computing resources was forcibly locked for the control plane, and the remaining computing resources... This constitutes an elastic computing domain, used to execute the fallback task described in S2.2, wherein This represents the total computing resources for SDN. S2.2 SDN Elastic Backup Decision and Resource Allocation Based on Dual-Channel Resource Overlay For the set of all edge overflow tasks that trigger the SDN fallback mechanism The controller directly calls the elastic computing domain resources predicted and partitioned in S2.

1. Construct a dual-channel resource allocation mechanism based on the guarantee domain and incentive domain; this mechanism dynamically divides the total elastic resources into basic guarantee resources. With flexible incentive resources The two parts are weighted based on the suitability for high-precision and difficult tasks and the comprehensive performance score, and finally the allocation is completed by linear superposition.

Images