Container redundancy scheduling method and system based on dynamic load

Abstract

The invention provides a container redundancy scheduling method and system based on a dynamic load, and relates to the technical field of container redundancy scheduling. According to the method and the system, the load change of the industrial edge cloud system is sensed in real time through a comprehensive design scheme of server redundancy, minimum deployable computing unit soft redundancy and application of an anti-affinity cross multi-copy mechanism and a multi-stage heartbeat detection mechanism in a container, and a scheduling strategy of a voting mechanism is combined; and dynamically adjusting the redundant deployment state of the container. For containerized application in an industrial edge cloud environment, dynamic load sensing, real-time fault detection and intelligent resource scheduling are realized, and the requirements of an industrial scene for low time delay and high reliability are met.

Description

Technical Field

[0001] The present invention relates to the technical field of container redundant scheduling, and in particular to a container redundant scheduling method and system based on dynamic load. Background Art

[0002] Due to the dynamics of tasks and the uncertainty of loads in industrial edge cloud systems, high requirements are imposed on resource management and scheduling. Container technology has become the core of edge cloud resource management due to its lightweight, high portability, and easy extensibility. However, existing container scheduling strategies are mostly based on static load balancing, making it difficult to quickly adapt to frequently fluctuating resource requirements, resulting in reduced system efficiency and even resource waste.

[0003] Traditional container redundant scheduling solutions improve the system's fault tolerance and service continuity by deploying redundant containers at key nodes or tasks, but mostly rely on fixed rules and lack sensitivity to dynamic load changes. This not only limits the resource utilization efficiency but also makes it difficult to effectively support the real-time and emergency requirements of tasks. In addition, problems such as high network latency and device failures in the edge environment pose higher requirements for service reliability. There are currently few mature cases of integrating containerized redundant technology with traditional industrial production systems. There is an urgent need for a container redundant scheduling method based on dynamic load, which can realize the efficient utilization of resources and the stable operation of services by real-time sensing of load changes and combining intelligent redundant strategies, providing a more reliable and efficient solution for industrial edge cloud systems.

[0004] In the VPLC (Virtual Programmable Logic Controller) application deployment of industrial edge cloud, to meet the requirements of high real-time, high reliability, and resource utilization efficiency in industrial automation scenarios, the existing container scheduling methods face the following main problems: Difficulty in sensing dynamic load changes: The VPLC tasks in industrial edge cloud are highly dynamic, and the task loads in different time periods may vary significantly. Existing scheduling methods are mainly based on static strategies and lack the ability to sense real-time load changes, resulting in lagging or overloading of resource allocation and being unable to efficiently adapt to actual requirements.

[0005] Low resource utilization efficiency: In traditional PLC (Programmable Logic Controller) deployments, preset rules are mostly used, without fully considering load distribution, task priorities, and issues such as dynamic expansion and efficient utilization of level-10 PLC applications in industrial systems. At the same time, excessive redundancy may waste limited edge computing resources, while insufficient redundancy may not guarantee the reliability and continuity of critical tasks, affecting the operation efficiency of industrial systems. 3

[0006] ​Insufficient real-time performance and reliability: In industrial scenarios, VPLC needs to respond quickly to sensor data, hardware device status, etc. in milliseconds. However, traditional scheduling strategies are difficult to quickly adjust the deployment and migration of containers when dealing with emergencies such as device failures and network delays. Traditional industrial control systems have insufficient support for real-time performance and fault tolerance.

[0007] High scheduling overhead: Facing a large number of edge nodes in large-scale deployment and complex network topologies, existing scheduling methods usually have high computational complexity, lack optimization of lightweight algorithms, increase the time overhead of scheduling decisions, and thus affect the overall system performance.

[0008] In existing container scheduling technologies, static load balancing strategies are mostly adopted to allocate containers to different server nodes to optimize resource utilization. These methods usually allocate according to fixed rules based on predefined metrics (such as CPU and memory usage). However, this strategy cannot perceive and respond to dynamic load changes. Facing the frequently fluctuating task requirements in industrial scenarios, it is easy to have situations of overloading or insufficient resource allocation. The lack of effective support for task priorities and real-time performance results in key tasks not being prioritized. To improve system reliability, traditional methods deploy a fixed number of redundant containers in critical tasks or nodes to enhance fault tolerance and service continuity. However, the redundancy strategy lacks flexibility and is difficult to dynamically adjust the number of redundant containers according to actual load requirements, which may lead to problems of resource waste or insufficient redundancy. The edge computing resources are not fully utilized, restricting the improvement of the overall system efficiency. At the same time, some existing research attempts to use global optimization algorithms (such as genetic algorithms and ant colony algorithms) to improve container scheduling to achieve optimal resource allocation. However, this method has high computational complexity and is difficult to meet real-time requirements in large-scale node deployment and dynamic load scenarios. The high demand for global perception of system status increases the design complexity and overhead of the scheduling system. Traditional centralized scheduling frameworks usually take a single scheduling node as the core, responsible for global container allocation and redundancy strategy decisions. A single point of failure may lead to the interruption of the entire system's scheduling, reducing reliability. The centralized architecture increases the delay of scheduling decisions and is difficult to meet the task requirements of real-time performance and low latency. Summary of the Invention

[0009] The technical problem to be solved by the present invention is to provide a container redundancy scheduling method and system based on dynamic load in view of the above-mentioned deficiencies of the prior art. Through a comprehensive design scheme of server redundancy, soft redundancy of the smallest deployable computing unit, anti-affinity cross-multiple replicas mechanism of applications in containers, and multi-level heartbeat detection mechanism, it can perceive the load changes of the industrial edge cloud system in real time, and combine the scheduling strategy of the voting mechanism to dynamically adjust the redundant deployment status of containers.

[0010] To solve the above technical problems, the technical solution adopted by the present invention is as follows: On the one hand, the present invention provides a container redundancy scheduling method based on dynamic load, including: Collect the real-time operating status of server resources, the load metrics of the smallest deployable computing units, and the status information of application instances in the industrial edge cloud native system; Judge whether it is necessary to adjust the redundancy policy according to the dynamic load change; When it is necessary to adjust the redundancy policy, calculate the optimal redundancy deployment plan of server resources, the smallest deployable computing units, and containers through the redundancy mechanism, and generate a server redundancy configuration adjustment instruction, a replica scheduling plan for the smallest deployable computing units, and an optimization strategy for the anti-affinity mechanism; Execute the server redundancy configuration adjustment instruction, the replica scheduling plan for the smallest deployable computing units, and the optimization strategy for the anti-affinity mechanism to achieve the automated scheduling of container redundancy.

[0011] Furthermore, the redundancy mechanism adopts multi-machine hot backup technology, data synchronization, redundant array of independent disks technology, integrates load balancing, real-time monitoring, and automatic fault detection and recovery mechanisms, and starts the standby server when the primary server fails.

[0012] Furthermore, the calculation of the optimal redundancy deployment plan of server resources, the smallest deployable computing units, and containers through the redundancy mechanism includes: Step 1: The containerized application interaction data input by the industrial production line is distributed in the form of data streams to the inside of the server cluster through the communication protocol; Step 2: The applications and their corresponding replicas in the containers deployed in the anti-affinity replica architecture in the server cluster receive and process the data streams; The server cluster deploys server resources, containers, and applications in an anti-affinity replica architecture; the master and slave servers in the server cluster are backup to each other; multiple containers run on each server, and corresponding container replicas run on heterogeneous servers for each container; multiple applications and replicas of the applications run on each container, and the replicas of each application are distributed on different server resources; the containerized application interaction data enters the container through the load balancer, and the first application in the first container in the primary server starts to receive and process the data; After the first application in the first container has a normal load, through the anti-affinity replica architecture design, the first replica of the first application in the first container of the primary server will be heterogeneously distributed to run in the second container of the slave server; at the same time, the second replica of the first application in the first container of the primary server runs in the third container of the slave server through the application data synchronization between containers; The first container and the second container in the normal running state perform thread resource synchronization with the real-time operating systems of the primary server and the slave server through thread synchronization; The first container and the second container distributed between the master server and the slave server achieve periodic application data synchronization through internal cluster communication; Step 3: The containerized application interaction data input by the industrial production line is processed by the application in the container, and the processed result data stream is fed back through the load balancer outlet and returned to the production line terminal.

[0013] Furthermore, the master server and the slave server have the same hardware configuration; the master server and the slave server are servers that back up each other in the cluster, with bandwidth and latency maintaining millisecond-level response to achieve real-time and timed data interaction.

[0014] Furthermore, the master server and the slave server have a high-response real-time operating system with real-time patches.

[0015] Furthermore, the real-time operating systems of the master server and the slave server meet the millisecond-level interaction requirements of industrial applications. There is a container runtime on them, running multiple containers and corresponding replica containers of each container on heterogeneous servers; timed data synchronization is performed between the container and its replicas, and the persistent data of the real-time operating systems of the master server and the slave server is also synchronized.

[0016] Furthermore, the anti-affinity replica mechanism works synergistically at three levels: application, container, and hardware; At the application level, multiple replicas of the same application are ensured to be distributed on different server nodes. By combining heartbeat detection and voting mechanisms, the health status of the application replicas is sensed in real time, and when a server fails, the replicas of the application are automatically rescheduled to other server nodes; At the container level, multiple applications of the same container are deployed on different server nodes or virtual machines; by dynamically adjusting the scheduling rules, the container replicas can be evenly distributed when the load changes; At the physical hardware level, in coordination with the server redundancy design, multiple replicas of the same application or container are dispersed and deployed to different physical servers.

[0017] Furthermore, the server cluster uses the anti-affinity replica mechanism to distribute the same application and its replicas in different server's smallest deployable computing units, and allows multiple identical applications and replicas to run in the same smallest deployable computing unit, relying on load balancing to share the workload; through a multi-level heartbeat detection mechanism, data synchronization, and container auto-scaling mechanism, failed applications are detected and recovered.

[0018] Furthermore, the multi-level heartbeat detection mechanism realizes dynamic load perception, real-time fault detection, and intelligent resource scheduling at three levels: application, container, and physical hardware by adding a monitoring mechanism, including: S1: The load balancer forwards industrial data traffic; S2: Use the application and its replicas to perform traffic detection and load monitoring. When there is a faulty application, the mechanism is triggered, and the heartbeat detection bus is activated for detection. The detection results are fed back to the load balancer through the feedback network to complete traffic switching, and at the same time, the application replicas are run. S3: Detect the service status inside the container. When there are situations of abnormal service status and failed data calls, the mechanism is triggered, and the heartbeat detection bus is activated for detection. The detection results are fed back to the load balancer through the feedback network to complete traffic switching, and at the same time, the container replicas are run. S4: Detect the persistent database service status at the hardware level. When there is service offline or abnormal status, the mechanism is triggered, and the heartbeat detection bus is activated for detection. The detection results are sent to the load balancer through the feedback network to provide a fault alarm and complete traffic switching at the hardware level. S5: During the operation stage of the server cluster and the real-time operating system, silently start the periodic database backup and status recovery of cross-system devices, and cooperate with the multi-level heartbeat detection mechanism.

[0019] On the other hand, a container redundancy scheduling system based on dynamic load includes: Collection module: Collect the real-time operating status of server resources, the load metrics of the smallest deployable computing units, and the status information of application instances in the industrial edge cloud-native system. Judgment module: Judge whether it is necessary to adjust the redundancy policy according to the dynamic load change. Policy generation module: When it is necessary to adjust the redundancy policy, calculate the optimal redundancy deployment plan for server resources, the smallest deployable computing units, and containers through the redundancy mechanism, and generate server redundancy configuration adjustment instructions, replica scheduling plans for the smallest deployable computing units, and optimization strategies for the anti-affinity mechanism. Execution module: Execute the server redundancy configuration adjustment instructions, replica scheduling plans for the smallest deployable computing units, and optimization strategies for the anti-affinity mechanism to achieve the automated scheduling of container redundancy.

[0020] The beneficial effects of adopting the above technical solutions are as follows: A container redundancy scheduling method and system based on dynamic load provided by the present invention realizes dynamic load perception, real-time fault detection, and intelligent resource scheduling for containerized applications in the industrial edge cloud environment, meeting the requirements of industrial scenarios for low latency and high reliability. Combining hard redundancy and soft redundancy technologies, a set of efficient and reliable redundancy mechanisms are proposed to ensure the continuity and fault tolerance of industrial applications. Among them, the anti-affinity replica architecture is a design based on multi-level resource distribution optimization, which innovatively expands the scheduling and distribution of application replicas. The anti-affinity mechanism works synergistically at three levels: application, container, and physical hardware, aiming to improve the fault tolerance of the system, resource utilization efficiency, and overall operation stability. Dynamically maintain the minimum number of deployable computing unit replicas, and reduce the risk of single-point failure through automatic scaling and topology distribution constraints; The multi-level heartbeat detection mechanism combines the load balancing strategy, which is an efficient state monitoring and load management method designed for containerized applications in the industrial edge cloud environment. By adding a monitoring mechanism and expanding and optimizing the monitoring mechanism at three levels: application, container, and physical hardware, dynamic load perception, real-time fault detection, and intelligent resource scheduling are realized, meeting the requirements of industrial scenarios for low latency and high reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a flowchart of the operation of the redundancy mechanism provided by an embodiment of the present invention; Figure 2 It is a schematic diagram of the anti-affinity replica architecture provided by an embodiment of the present invention; Figure 3 It is a schematic diagram of the multi-level heartbeat detection mechanism provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] The following combines the drawings and embodiments to further describe in detail the specific implementation manners of the present invention. The following embodiments are used to illustrate the present invention, but are not used to limit the scope of the present invention.

[0023] Embodiment 1: In this embodiment, a container redundancy scheduling method based on dynamic load includes: Collect the real-time operating status of server resources, load metrics of the smallest deployable computing unit (Pod), and status information of application instances in the industrial edge cloud native system; Judge whether it is necessary to adjust the redundancy policy according to the dynamic load change; When it is necessary to adjust the redundancy policy, calculate the optimal redundancy deployment plan for server resources, the smallest deployable computing unit, and containers through the redundancy mechanism, and generate a server redundancy configuration adjustment instruction, a replica scheduling plan for the smallest deployable computing unit, and an optimization strategy for the anti-affinity mechanism; Execute the server redundancy configuration adjustment instruction, the replica scheduling scheme of the smallest deployable computing unit, and the optimization strategy of the anti-affinity mechanism to achieve the automated scheduling of container redundancy.

[0024] In this embodiment, the redundancy mechanism adopts multi-machine hot standby technology, data synchronization, independent disk redundancy array technology, integrated load balancing, real-time monitoring, and automatic fault detection and recovery mechanism. When the primary server fails, the standby server is started.

[0025] In this embodiment, the optimal redundancy deployment scheme of server resources, the smallest deployable computing unit, and containers is calculated through the redundancy mechanism, as Figure 1 shown, including the following steps: Step 1: The containerized application interaction data input by the industrial production line is distributed to the inside of the server cluster in the form of a data stream through the communication protocol; Step 2: The applications deployed in the anti-affinity replica architecture in the server cluster and their corresponding replicas receive and process the data stream; the server resources, containers, and applications in the server cluster are deployed in the anti-affinity replica architecture; the master and slave servers in the server cluster are backup to each other; multiple containers run on each server, and corresponding container replicas run on heterogeneous servers; multiple applications and replicas of the applications run on each container, and the replicas of each application are distributed on different server resources; the containerized application interaction data enters the container through the load balancer, and the first application in the first container in the primary server starts to receive and process the data; After the first application in the first container is normally loaded, through the anti-affinity replica architecture design, as Figure 2 shown, the first replica 1 of the first application in the first container A of the primary server will be heterogeneously distributed to run in the second container B' of the slave server; at the same time, the second replica 2 of the first application 1 in the first container is run in the third container A' of the slave server through the application data synchronization between containers, establishing a highly reliable redundancy architecture of 1 master and 2 replicas; The first container and the second container in the normal running state perform thread resource synchronization with the real-time operating systems deployed on the primary server and the slave server through thread synchronization; The first container A and the second container B' distributed between the primary server and the slave server achieve periodic application data synchronization through the internal communication of the cluster; The hardware configurations such as CPU, memory, GPU, and network environment in the primary server and the slave server are kept consistent; the primary server and the slave server are servers that are backup to each other in the cluster, and the bandwidth and latency maintain a millisecond-level response to achieve real-time and timed data interaction.

[0026] Deploy a highly responsive real-time operating system (RT-OS) with real-time patches on the master server and the slave server. At the operating system level, an operating system (RT-OS) using a highly responsive Linux kernel with real-time patches should be maintained. And to ensure scalability, it is recommended to use a system that natively supports the Linux kernel, such as the Proxmox Virtual Environment (PVE) virtual machine management system.

[0027] In this embodiment, the real-time operating systems deployed on the master server and the slave server meet the millisecond-level interaction requirements of industrial applications. There is a container runtime on it, running two containers A and B and their corresponding replica containers A' and B' of each container A and B on heterogeneous servers; regular data synchronization is performed between the containers and their replicas, and the persistent data of the real-time operating systems deployed on the master server and the slave server is also synchronized to ensure the robustness of the system operation. The downtime of a single node server or Pod does not affect the normal operation of the system. Using RT-OS as the underlying operating system not only ensures the real-time performance of the system but also retains the ability of this virtual machine management system to perform one-key backup, create virtual server replication, and quickly expand the auxiliary server cluster nodes.

[0028] Step 3: The containerized application interaction data input by the industrial production line is processed by the application in the container, and the processed result data stream is sent back through the load balancer outlet and fed back to the production line terminal.

[0029] Furthermore, the anti-affinity replica mechanism is a key design based on multi-level resource distribution optimization, combining a resource cross-allocation strategy, and innovatively expanding the scheduling and distribution of application replicas. This mechanism works synergistically at the application, container, and hardware levels, aiming to improve the system's fault tolerance, resource utilization efficiency, and overall operational stability.

[0030] At the application layer, the anti-affinity mechanism ensures that multiple replicas of the same application are distributed on different server nodes as much as possible to avoid the impact of a single point of failure on the entire application. By combining heartbeat detection and a voting mechanism, it can real-time sense the health status of application replicas and automatically reschedule the replicas of the application to other server nodes when a server fails, thus ensuring the high availability of the service.

[0031] At the container layer, the anti-affinity mechanism ensures that multiple application instances of the same container group are centrally deployed on different server nodes or virtual machines; by dynamically adjusting the scheduling rules, the container replicas can be evenly distributed when the load changes, reducing performance bottlenecks caused by resource contention, and enhancing the independence and isolation between containers.

[0032] At the physical hardware layer, the anti-affinity mechanism is further extended to the replica distribution design across servers. Multiple replicas of the same application or container are scattered and deployed on different physical servers to reduce the impact of server failures on the overall system. Collaborating with the server redundancy design, it forms a more robust disaster tolerance and fault tolerance capability.

[0033] By introducing the anti-affinity replica mechanism at the above three levels, the dynamic optimization of resource distribution is achieved. It not only reduces the system failure risk caused by centralized deployment but also significantly improves the reliability and resource utilization efficiency of containerized applications in the industrial edge cloud scenario.

[0034] Furthermore, the industrial cluster uses the anti-affinity replica mechanism to distribute the same application and its replicas in different servers' smallest deployable computing units and allows multiple identical applications and replicas to run in the same smallest deployable computing unit. Relying on load balancing to share the workload, high availability is achieved; through the multi-level heartbeat detection mechanism, data synchronization, and container auto-scaling mechanism, failed application instances can be quickly detected and recovered.

[0035] Furthermore, the multi-level heartbeat detection mechanism combines load balancing strategies and is an efficient state monitoring and load management method designed for containerized applications in the industrial edge cloud environment. By adding a monitoring mechanism and expanding and optimizing it at the application, container, and physical hardware levels, this mechanism realizes dynamic load perception, real-time fault detection, and intelligent resource scheduling, meeting the requirements of industrial scenarios for low latency and high reliability as Figure 3 shown, including: S1: The load balancer forwards industrial data traffic. S2: The application and its replicas conduct traffic detection and load monitoring. When there is a faulty application, the mechanism is triggered, and the heartbeat detection bus is enabled for detection. The detection results are fed back to the load balancer through the feedback network to complete traffic switching, and at the same time, the application replicas are run. At the application layer, this mechanism ensures that each replica is in an available state by monitoring the health status and running load of the application replicas in real time. Combining load balancing strategies, the system dynamically allocates requests to replicas in a healthy state to avoid single-point overload. When the heartbeat signal indicates that a certain replica is abnormal or overloaded, the load balancer automatically reallocates the request traffic to other replicas and at the same time triggers the replica expansion or restart operation to ensure the continuity and stability of the service.

[0036] S3: Detect the service status inside the container. When there are abnormal service status and data call failure situations, the mechanism is triggered, and the heartbeat detection bus is enabled for detection. The detection results are fed back to the load balancer through the feedback network to complete traffic switching, and at the same time, the container replicas are run. At the container layer, this mechanism monitors the running status and resource consumption of containers (such as CPU, memory, network bandwidth) through probes (such as Liveness Probe and Readiness Probe). When the load of a certain container approaches the threshold or the heartbeat signal is abnormal, the load balancer can actively schedule new tasks to low-load containers and trigger container expansion or redeployment according to demand. This mechanism combines elastic management of container resources and improves the overall resource utilization rate of the server cluster.

[0037] S4: Persistent database service status detection at the hardware level. When there is a service offline or abnormal status, the mechanism is triggered, and the heartbeat detection bus is enabled for detection. The detection results are sent to the load balancer through the feedback network to provide fault alarms and complete traffic switching at the hardware level; At the physical hardware layer, this mechanism is used to monitor the health status of server nodes in real time, including hardware performance indicators (such as disk IO, CPU temperature) and network connection status. When the heartbeat signal of a certain server node is abnormal, the load balancer will stop allocating tasks to this node and migrate the running load on it to other healthy nodes. At the same time, combined with server redundancy design, it ensures the high availability of services and avoids the impact of single-node failures on the overall operation.

[0038] The combination of the multi-level heartbeat detection mechanism and the load balancing strategy breaks the limitations of traditional single-level monitoring, realizes dynamic perception and real-time optimization of the load. Compared with traditional monitoring methods, this mechanism not only improves the fault tolerance of the system, but also enhances the resource utilization efficiency and the flexibility of task scheduling, and is especially suitable for scenarios with high reliability and low latency requirements in industrial edge clouds.

[0039] S5: During the operation of the industrial cluster and real-time operating system, silently start the periodic cross-system device database backup and status recovery, which works in coordination with the multi-level heartbeat detection mechanism.

[0040] Example 2: In this embodiment, a container redundancy scheduling system based on dynamic load includes: Collection module: Collect the real-time running status of server resources, load indicators of the smallest deployable computing units, and status information of application instances in the industrial edge cloud native system; Judgment module: Judge whether it is necessary to adjust the redundancy policy according to the dynamic load change; Policy generation module: When it is necessary to adjust the redundancy policy, calculate the optimal redundancy deployment plan for server resources, the smallest deployable computing units, and containers through the redundancy mechanism, and generate server redundancy configuration adjustment instructions, replica scheduling plans for the smallest deployable computing units, and optimization strategies for the anti-affinity mechanism; Execution module: Execute the server redundancy configuration adjustment instruction, the replica scheduling scheme of the smallest deployable computing unit, and the optimization strategy of the anti-affinity mechanism to achieve the automated scheduling of container redundancy.

[0041] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope defined by the claims of the present invention.

Claims

1. A container redundancy scheduling method based on dynamic load, characterized by: include: Collect the real-time operating status of server resources in the industrial edge cloud native system, the load indicators of the smallest deployable computing unit, and the status information of application instances; Determine whether the redundancy strategy needs to be adjusted based on dynamic load changes; When the redundancy strategy needs to be adjusted, the optimal redundancy deployment plan of server resources, the smallest deployable computing unit, and containers is calculated through the redundancy mechanism, and server redundancy configuration adjustment instructions, the replica scheduling plan of the smallest deployable computing unit, and the optimization strategy of the anti-affinity mechanism are generated; Execute server redundancy configuration adjustment instructions, replica scheduling scheme of the smallest deployable computing unit, and optimization strategy of anti-affinity mechanism to realize automatic scheduling of container redundancy.

2. According to the method for redundant container scheduling based on dynamic load in claim 1, it is characterized by: The redundancy mechanism adopts multi-machine hot backup technology, data synchronization, independent disk redundant array technology, integrated load balancing, real-time monitoring and automatic fault detection and recovery mechanism, and starts the backup server when the main server fails.

3. According to claim 2, a method for redundant scheduling of containers based on dynamic loads is characterized in that: The optimal redundant deployment scheme for computing server resources, the smallest deployable computing unit, and containers through a redundant mechanism includes: Step 1: The containerized application interaction data input by the industrial production line is distributed to the server cluster in the form of data streams through the communication protocol; Step 2: The application in the container deployed in the server cluster with the anti-affinity replica architecture and its corresponding replica receive and process the data stream; The server cluster deploys server resources, containers and applications in an anti-affinity replica architecture; the master and slave servers in the server cluster back up each other; multiple containers run on each server, and each container runs a corresponding container copy on a heterogeneous server; multiple applications and application copies run on each container, and each application copy is distributed on different server resources; containerized application interaction data enters the container through a load balancer, and the first application is started in the first container in the master server to receive data and start processing; After the first application in the first container is loaded normally, the first copy of the first application in the first container of the master server is heterogeneously distributed to the second container of the slave server for running through the anti-affinity replica architecture design; at the same time, the second copy of the first application in the first container of the master server is run in the third container of the slave server through the synchronization of application data between containers; The first container and the second container in a normal operating state perform thread resource synchronization with the real-time operating systems of the master server and the slave server through thread synchronization; The first container and the second container distributed between the master server and the slave server realize periodic application data synchronization through internal cluster communication; Step 3: The containerized application interaction data input by the industrial production line is processed by the application in the container, and the processing result data stream is fed back to the production line terminal through the load balancer export receipt.

4. According to claim 3, a method for redundant scheduling of containers based on dynamic loads is characterized in that: The hardware configuration of the master server and the slave server is the same; the master server and the slave server serve as backup servers for each other in the cluster, and the bandwidth and delay maintain millisecond-level response to achieve real-time and scheduled data interaction.

5. The method for redundant scheduling of containers based on dynamic load according to claim 4, characterized in that: The master server and the slave server are provided with a high-response real-time operating system with a real-time patch.

6. The method for redundant scheduling of containers based on dynamic load according to claim 5, characterized in that: The real-time operating systems of the master server and the slave server meet the millisecond-level interaction requirements of millisecond-level industrial applications, and are equipped with a container runtime to run multiple containers and corresponding replica containers of each container on heterogeneous servers; Data is synchronized regularly between the container and its replicas, and the persistent data of the real-time operating systems of the master and slave servers is also synchronized.

7. The method for redundant scheduling of containers based on dynamic load according to claim 3, characterized in that: The anti-affinity replica mechanism works synergistically at the application, container, and hardware levels; At the application layer, ensure that multiple copies of the same application are distributed on different server nodes. By combining heartbeat detection and voting mechanisms, the health status of application copies is sensed in real time, and application copies are automatically rescheduled to other server nodes when a server fails. At the container layer, multiple applications of the same container are deployed in different server nodes or virtual machines; By dynamically adjusting the scheduling rules, container replicas can be evenly distributed when the load changes; At the physical hardware layer, in coordination with server redundancy design, multiple copies of the same application or container are deployed to different physical servers.

8. The method for redundant scheduling of containers based on dynamic load according to claim 7, characterized in that: The server cluster uses an anti-affinity replica mechanism to distribute the same application and its replicas in different smallest deployable computing units of different servers, and allows the same smallest deployable computing unit to run multiple identical applications and replicas, relying on load balancing to share workloads; Detect and recover failed applications through multi-level heartbeat detection mechanism, data synchronization and container automatic expansion mechanism.

9. The method for redundant container scheduling based on dynamic load according to claim 8, characterized in that: The multi-level heartbeat detection mechanism implements dynamic load perception, real-time fault detection, and intelligent resource scheduling at the application, container, and physical hardware levels by adding a monitoring mechanism, including: S1: Load balancer forwards industrial data traffic; S2: The application and its replicas perform traffic detection and load monitoring. When there is a faulty application, the mechanism is triggered and the heartbeat detection bus is enabled for detection. The detection results are fed back to the load balancer through the feedback network to complete the traffic switching while running the application replicas. S3: Service status detection in the container. When there is an abnormal service status or data call failure, the mechanism is triggered and the heartbeat detection bus is enabled for detection. The detection result is fed back to the load balancer through the feedback network to complete the traffic switching and run the container replica at the same time. S4: Hardware-level persistent database service status detection. When a service is offline or in an abnormal state, the mechanism is triggered and the heartbeat detection bus is enabled for detection. The detection result is fed back to the load balancer through the network to provide a fault alarm and complete the traffic switching at the hardware level. S5: During the operation phase of the server cluster and real-time operating system, periodic database backup and status recovery across system devices are silently started, working in conjunction with the multi-level heartbeat detection mechanism.

10. A container redundancy scheduling system based on dynamic load, implemented based on the container redundancy scheduling method based on dynamic load according to claim 1, characterized in that: include: Collection module: collects the real-time operating status of server resources in the industrial edge cloud native system, the load indicators of the smallest deployable computing unit, and the status information of application instances; Judgment module: determines whether the redundancy strategy needs to be adjusted according to dynamic load changes; Strategy generation module: When the redundancy strategy needs to be adjusted, the optimal redundancy deployment plan of server resources, the smallest deployable computing unit, and containers is calculated through the redundancy mechanism, and the server redundancy configuration adjustment instructions, the replica scheduling plan of the smallest deployable computing unit, and the optimization strategy of the anti-affinity mechanism are generated; Execution module: executes server redundancy configuration adjustment instructions, the replica scheduling plan of the smallest deployable computing unit, and the optimization strategy of the anti-affinity mechanism to achieve automatic scheduling of container redundancy.

Images