Container process cross-machine-room backup method and device, equipment, medium and program product
By using performance data prediction models and Remote Direct Memory Access (RDMA) technology, seamless migration and backup of container processes across data centers were achieved, solving the problems of inconsistent memory states and latency in traditional container backup methods, and improving the system's disaster recovery efficiency and resource utilization.
Patent Information
- Application Number
- CN202511809778.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-03
- Publication Date
- 2026-04-10
AI Technical Summary
In cross-datacenter deployment and disaster recovery scenarios, traditional container backup methods cannot save the runtime memory state, resulting in inconsistent application states after recovery, affecting business continuity. Furthermore, CRIU technology does not support cross-datacenter memory replication, which poses risks of latency and data loss.
A performance data prediction model is used to monitor the container resource status in real time. The target process status is mirrored to the container in the second data center through Remote Direct Memory Access (RDMA) technology. Combined with CRIU technology, seamless migration and backup across data centers are achieved.
It avoids business interruptions caused by performance overload, significantly reduces data transmission latency and storage overhead, improves the overall disaster recovery efficiency and resource utilization of the system, and ensures the continuity and reliability of services.
Smart Images

Figure CN121833343A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of computer, in particular to a container process cross-machine room backup method, device, equipment, medium and program product. BACKGROUND
[0002] With the development of cloud computing and microservice architecture, Docker containers have become the mainstream way to deploy and manage applications. However, in the cross-machine room deployment and disaster recovery scenarios, how to quickly and completely restore the running state of the container, especially the memory state, is still a technical problem. The traditional container backup method relies on images and logs, and cannot save the runtime memory state, resulting in inconsistent application state after recovery, affecting business continuity. CRIU technology can take snapshots (checkpoint) and restore (restore) running processes in user space, including memory, open file descriptors, network connections, etc. It provides the possibility for container live migration and state recovery. However, CRIU itself does not support cross-machine room memory replication, snapshot timing is fixed or manual, and there is a risk of delay and data loss in network transmission. SUMMARY
[0003] The embodiments of the present application provide a container process cross-machine room backup method, device, equipment, medium and program product, which adaptively triggers process state snapshot based on future performance prediction, and realizes cross-machine room transmission backup.
[0004] According to an aspect of the present application, a container process cross-machine room backup method is provided, which comprises:
[0005] For a first container in a first machine room, a performance data prediction model is used to predict the performance data of the first container at a future time, and target performance data is determined;
[0006] If it is determined according to the target performance data that process backup is needed, a process state snapshot of the first container is triggered, and a target process state of the first container is obtained;
[0007] The target process state in the first container is accessed through a remote memory direct access technology, and the target process state is mirrored to a second container in a second machine room.
[0008] According to an aspect of the present application, a container process cross-machine room backup device is provided, which comprises:
[0009] A target performance data determination module is configured to, for a first container in a first machine room, use a performance data prediction model to predict the performance data of the first container at a future time, and determine target performance data;
[0010] The target process status acquisition module is used to trigger a snapshot of the process status of the first container and acquire the target process status of the first container if it is determined that process backup is required based on the target performance data.
[0011] The mirroring module is used to access the target process state in the first container through remote memory direct access technology and mirror the target process state to the second container in the second data center.
[0012] According to another aspect of this application, an electronic device is provided, the electronic device comprising:
[0013] At least one processor; and,
[0014] A memory that is communicatively connected to at least one processor; wherein,
[0015] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to execute the container process cross-data center backup method of any embodiment of this application.
[0016] According to another aspect of this application, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute and implement the container process cross-data center backup method of any embodiment of this application.
[0017] According to another aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the container process cross-data center backup method of any embodiment of this application.
[0018] The technical solution of this application embodiment, for a first container in a first data center, uses a performance data prediction model to predict the performance data of the first container at a future time to determine target performance data; if it is determined that process backup is required based on the target performance data, a process state snapshot of the first container is triggered to obtain the target process state of the first container; the target process state in the first container is accessed through remote memory direct access technology, and the target process state is mirrored to a second container in a second data center. The above solution monitors the resource status of the first container in real time through a performance data prediction model, predicts potential performance bottlenecks in advance, and intelligently triggers a process backup mechanism based on target performance data, solving the problem of missing actual peak load periods due to fixed triggering times. Combined with remote memory direct access technology, seamless migration across data centers is achieved, which not only avoids business interruptions caused by performance overload but also ensures service continuity through the rapid takeover of the second container. Simultaneously, it significantly reduces data transmission latency and storage overhead of traditional backup solutions, improving overall system disaster recovery efficiency and resource utilization.
[0019] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description
[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0021] Figure 1 A flowchart illustrating a method for cross-datacenter backup of container processes provided in this application embodiment;
[0022] Figure 2 A specific implementation architecture diagram provided for an embodiment of this application;
[0023] Figure 3 A flowchart illustrating a method for cross-datacenter backup of container processes, as provided in another embodiment of this application;
[0024] Figure 4 A flowchart illustrating a method for cross-datacenter backup of container processes, as provided in another embodiment of this application;
[0025] Figure 5 This application provides a schematic diagram of the structure of a container process cross-data center backup device.
[0026] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0027] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0028] It should be noted that the terms "first," "second," "third," "fourth," "actual," "preset," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0029] The acquisition, storage, use, and processing of data in this application comply with relevant national laws and regulations. The acquired data is obtained with authorization and will not be disclosed without permission, used for illegal purposes, purposes detrimental to the interests of others, or for personalized analysis or product promotion. It should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary and intended only to illustrate the feasibility of implementing the technical solution of this application, but do not imply that the applicant has already used or necessarily used the relevant content of such solutions.
[0030] Figure 1 This document presents a flowchart illustrating a method for cross-datacenter backup of container processes, applicable to scenarios involving cross-datacenter disaster recovery and backup of container processes. This method can be executed by a cross-datacenter backup device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:
[0031] S110. For the first container in the first computer room, a performance data prediction model is used to predict the performance data of the first container at future times, and the target performance data is determined.
[0032] In this context, a data center is a physical space where servers and other IT equipment are centrally deployed, while a container is a lightweight virtualization technology that packages applications and their dependencies into independent running units. The first container refers to the container deployed in the first data center. The performance data prediction model is a pre-trained model used to predict the performance of the first container. For example, the performance data prediction model is obtained by pre-training and optimizing a neural network model based on historical performance data of the first container, thus enabling the model to predict future performance data based on historical performance data.
[0033] In this embodiment, for the first container in the first data center, a performance data prediction model can be used to predict the performance data of the first container at future times, thereby determining the target performance data of the first container at future times. During the process of predicting the performance of the first container at future times based on the performance data prediction model, it is necessary to obtain the current or historical performance data of the first container and input it into the performance data prediction model for prediction. The first container in the first data center in this embodiment is not specific; containers in all data centers can be considered as the first container in the first data center and processed using the solution of this embodiment.
[0034] S120. If it is determined that process backup is required based on the target performance data, a snapshot of the process state of the first container is triggered to obtain the target process state of the first container.
[0035] For example, target performance data can reflect the load and operational status of the first container at a future time. Based on this data, it can be determined whether process backup is necessary. Generally, if the target performance data for the first container is low, indicating poor performance and high load, process backup is required to prevent significant business losses due to a large number of abnormal process interruptions in the event of a failure in the first container. Therefore, the need for process backup can be determined based on the target performance data. If it is predicted that the target performance data will be low in the future and process backup is necessary, a snapshot of the process status of the first container is triggered to obtain the target process status of the first container at the future time.
[0036] Process state snapshots can be implemented using CRIU (Checkpoint / Restore In Userspace) technology. CRIU is a process / container state saving and restoration tool implemented in Linux userspace. By freezing the program and saving its state to disk, it supports hot migration, snapshots, and remote debugging. Its core functions include: Hot migration: seamlessly migrating running containers or applications to other hosts with zero downtime; Dynamic code injection: modifying code without terminating the process using the libcompel library; TCP connection persistence: backing up and restoring TCP connection state using the libsoccr library. An AI-predictive CRIU snapshot triggering mechanism uses a temporal neural network to predict the probability of sudden memory changes in the next second, accurately triggering CRIU snapshots and avoiding the 30% redundancy and state omissions caused by traditional fixed intervals.
[0037] S130. Access the target process state in the first container through remote memory direct access technology, and mirror the target process state to the second container in the second data center.
[0038] Remote Direct Memory Access (RDMA) is a network communication technology that allows computers to directly access remote memory data without CPU intervention or operating system kernel processing. It achieves high-bandwidth, low-latency data transmission through a dedicated network interface card (NIC). Its core mechanisms include zero-copy (direct data transmission), kernel bypass (bypassing the protocol stack), and low CPU usage. Typical applications include high-performance computing and cross-datacenter container migration. Furthermore, the solution in this application implements cross-datacenter backup of the target process state, solving the problem that backups performed in other containers within the same datacenter still result in complete data loss when the first datacenter experiences a failure. This improves the security and reliability of disaster recovery backups.
[0039] In this embodiment, the target process state in the first container is accessed via Remote Memory Direct Access (RDMA) technology. This eliminates the need for CPU access and disk access in the first container, allowing direct acquisition and transmission of the target process state from memory. This enables mirroring the target process state to a second container in the second data center for cross-data center disaster recovery backup. Compared to existing technologies that save the target process state obtained after a snapshot is triggered from memory to disk and then read it back into memory for transmission to the CPU and network card when needed, this embodiment uses RDMA technology to directly and in real-time transmit the snapshot to the second container in the second data center. This real-time transmission avoids the problem of snapshot loss and failure to back up the snapshot due to a failure in the first data center immediately after acquisition.
[0040] In this embodiment of the application, accessing the target process state in the first container via remote direct memory access technology and mirroring the target process state to a second container in a second data center includes:
[0041] At the control level, the first container and the second container are connected for bilateral communication and negotiation.
[0042] One-way communication at the data layer transmits the target process state to the second container in the second data center.
[0043] In this embodiment, during the process of accessing the target process state in the first container via remote direct memory access technology, the first and second containers can be connected at the control plane for bilateral communication and negotiation. Both parties coordinate data transmission through Send / Receive operations, exchanging control information such as data length, checksum, and retransmission sequence number to ensure reliability. The data plane achieves efficient transmission through unilateral RDMA WRITE: the receiver pre-registers the memory region to the network card, generating an access permission identifier (Rkey). The sender's network card (RNIC) locates the receiver's memory using the Rkey and directly writes data without requiring intervention from the receiver's CPU. Data is directly transferred from the sender's application memory to the receiver's memory, avoiding multiple copies between user space and kernel space, significantly reducing latency and CPU load. The above solution ensures transmission reliability through bilateral send / receive on the control plane and achieves zero-copy, high-efficiency transmission through unilateral RDMA WRITE on the data plane. Combined with remote pre-registered memory buffering and RNIC direct memory writing, it can significantly reduce network latency (microsecond level), reduce CPU overhead (load <10%), and improve throughput, making it suitable for low-latency, high-bandwidth scenarios such as high-performance computing and distributed storage. The self-developed RDMA-CRIU adaptation layer utilizes RNIC hardware verification, zero-copy, and hybrid bilateral / unilateral transmission to maintain 95% throughput with a cross-data center latency of 10 ms, supports out-of-order retransmission and breakpoint resumption, and has a data loss rate of less than 0.001%.
[0044] A specific implementation architecture diagram of an embodiment of this application is shown below. Figure 2 As shown, the original data center is the first data center, Container A is the first container, the target data center is the second data center, and Container B is the second container. Prediction is the process in S110, and mirroring is the process in S120. The established ACK is a bilateral communication link, and RDMA is a unilateral communication link.
[0045] In this embodiment of the application, before mirroring the target process state to the second container in the second data center, the method further includes:
[0046] The target process state is compressed to obtain the compressed target process state;
[0047] An image file is created based on the compressed target process state, and a document describing the detailed internal memory structure of the image file is generated. The restoration of the target process state to the first container is based on the mapping of the image file and container semantics according to the document.
[0048] The target process state can be compressed to obtain a compressed target process state. Compression of the target process state can significantly reduce memory usage while maintaining process continuity, which is especially suitable for high-density container environments. Specifically, LZ4_HC can be used for compression in 4 KB blocks, combined with deduplication using a dedup table, achieving an average compression ratio of ≥7:1.
[0049] An image file is created based on the compressed target process state, and a document describing detailed information about the internal memory structure of the image file is generated. This document is used to map the semantics of the image file to the container when restoring the target process state to the first container. Since the format of the target process state in the first container differs from the format after image creation, a document describing detailed information about the memory structure in the image file needs to be generated. This involves generating an .img image and outputting the memory layout JSON, allowing for precise mapping according to container semantics during remote restoration.
[0050] The technical solution of this application embodiment, for a first container in a first data center, uses a performance data prediction model to predict the performance data of the first container at a future time to determine target performance data; if it is determined that process backup is required based on the target performance data, a process state snapshot of the first container is triggered to obtain the target process state of the first container; the target process state in the first container is accessed through remote memory direct access technology, and the target process state is mirrored to a second container in a second data center. The above solution monitors the resource status of the first container in real time through a performance data prediction model, predicts potential performance bottlenecks in advance, and intelligently triggers a process backup mechanism based on target performance data, solving the problem of missing actual peak load periods due to fixed triggering times. Combined with remote memory direct access technology, seamless migration across data centers is achieved, which not only avoids business interruptions caused by performance overload but also ensures service continuity through the rapid takeover of the second container. Simultaneously, it significantly reduces data transmission latency and storage overhead of traditional backup solutions, improving overall system disaster recovery efficiency and resource utilization.
[0051] Figure 3 This is a flowchart illustrating a method for cross-datacenter backup of container processes, provided as another embodiment of this application. This application's embodiment is based on and optimized from the above embodiment; solutions not described in detail in this application's embodiment are found in the above embodiment.Figure 3 As shown, the method in this embodiment of the application specifically includes the following steps:
[0052] S210. For the first container in the first computer room, run a probe in the first container to obtain the current performance data in the first container; wherein, the current performance data includes page table dirty write rate, process burst fluctuation, garbage collection count and time, network connection establishment rate and disconnection rate.
[0053] For example, an eBPF probe can be run in the first container to collect current performance data with less than 1% CPU overhead. Current performance data includes page table dirty write rate, process bursts, garbage collection counts and times, and network connection establishment and disconnection rates. Page table dirty write rate refers to the number of page table entries modified per unit of time. When a process writes data to a memory page, the operating system marks the page as a "dirty page," which needs to be periodically synchronized to persistent storage. A high dirty write rate can increase I / O pressure and affect container migration efficiency. Process bursts refer to drastic changes in a process's resource usage (such as CPU and memory) within a short period. For example, a sudden increase in container load leading to insufficient memory may trigger frequent page faults or garbage collection. Garbage collection counts and times: the frequency at which the garbage collector runs per unit of time. High frequency may be due to insufficient heap space or excessively rapid object allocation. Time: the pause time of a single garbage collection. Long times can cause container response delays, especially in server-side scenarios where optimization is crucial. Network connection establishment rate: the number of successfully established connections per unit of time, reflecting network processing capacity. A high connection establishment rate requires sufficient connection pool resources. The disconnection rate is the number of connections closed per unit of time. An abnormally high disconnection rate may be due to connection leaks or network instability. In container migration, these metrics collectively affect the efficiency and stability of remote memory access. For example, high dirty write rates and garbage collection time can prolong state synchronization time, while network fluctuations increase connection retry overhead. Data is aggregated with the cgroup v2 interface via perf events and sent to a local time-series cache every 100 ms.
[0054] S220. Input the current performance data into a long short-term memory network to extract temporal features, and input the current performance data into an attention layer to assign importance weights to each time step. Combine the temporal features with the importance weights and input them into a fully connected layer to predict and determine the target performance data of the first container at future times.
[0055] For example, an LSTM (Long Short-Term Memory) network combined with an Attention mechanism is trained offline on millions of historical data points of containers to output the probability of memory drastic changes in the next second. By training the LSTM network offline to capture the temporal dependency features of historical memory data of containers, and combining it with the Attention mechanism to dynamically focus on memory fluctuation patterns at key time nodes, it can accurately identify potential trigger points for memory drastic changes on a data scale of millions, and output a probability prediction of memory drastic changes in the next second. By accurately capturing the temporal dependency features of container memory usage through the LSTM network, and combining it with the Attention mechanism to dynamically focus on key historical nodes (such as garbage collection peaks or sudden process fluctuations), it can identify potential patterns of memory drastic changes in complex time-series data, significantly improving the accuracy of future memory prediction and early warning capabilities.
[0056] S230. If it is determined that process backup is required based on the target performance data, a snapshot of the process state of the first container is triggered to obtain the target process state of the first container.
[0057] S240. Access the target process state in the first container through remote memory direct access technology, and mirror the target process state to the second container in the second data center.
[0058] The solution in this embodiment involves running a probe within the first container to acquire current performance data. This current performance data includes page table dirty write rate, process burst fluctuations, garbage collection counts and times, and network connection establishment and disconnection rates. The current performance data is then input into a Long Short-Term Memory (LSTM) network to extract temporal features, and further input into an attention layer to assign importance weights to each time step. The temporal features and importance weights are combined and input into a fully connected layer to predict and determine the target performance data of the first container at future times. This solution, by deploying a probe within the first container to collect key performance indicators such as page table dirty write rate and process burst fluctuations in real time, and combining this with the extraction of temporal features using an LSTM network and the dynamic weight allocation using an attention mechanism, can accurately capture the dynamic changes in memory, network, and other resources, significantly improving the accuracy of predicting target performance data at future times. By visualizing attention weights, the core factors affecting performance (such as garbage collection time or network fluctuations) can be located, and the root cause of problems can be quickly diagnosed. The false alarm rate of traditional static threshold alarms can be reduced, realizing the transformation from passive response to proactive optimization. Resource allocation strategies can be optimized to avoid container service interruptions caused by performance bottlenecks, thereby improving the overall stability and resource utilization of the system and providing reliable decision support for intelligent operation and maintenance of containerized environments.
[0059] Figure 4This is a flowchart illustrating a method for cross-datacenter backup of container processes, provided as another embodiment of this application. This embodiment is an optimization based on the above embodiments; solutions not described in detail in this embodiment are found in the above embodiments. Figure 4 As shown, the method in this embodiment of the application specifically includes the following steps:
[0060] S310. For the first container in the first computer room, a performance data prediction model is used to predict the performance data of the first container at future times, and the target performance data is determined.
[0061] S320. If it is determined that process backup is required based on the target performance data, then the process memory mapping details file in the first container is parsed to determine the memory usage data in the first container.
[0062] For example, if it is determined that process backups are needed based on target performance data, the process memory mapping details file in the first container can be parsed to determine the memory usage data in the first container based on the parsing results. The process memory mapping details file can be the ` / proc / pid / smaps` file.
[0063] S330. Classify the memory usage data to determine the memory pages that are allowed to be written to and the memory pages that are read-only.
[0064] For example, memory usage data can be categorized to determine which memory pages are writable and which are read-only. Writable memory pages refer to memory regions marked as readable and writable by the operating system through read / write permission bits in page table entries, allowing programs to freely modify their contents; read-only memory pages are restricted to read-only access through permission bits, typically used to store critical system data or protected system resources. When calling CRIU on the first container, virtual memory is first categorized into three types—Java / Go heap, shared libraries, and cache pages—according to the "container semantic classification" strategy, and then an incremental image containing only dirty pages and layout metadata is generated. .img + layout.json).
[0065] In memory pages, the Java heap and Go heap are generally anonymous pages, which are writable. Shared library file pages mapped to memory are read-only, allowing multiple processes to share the same code. Cache pages based on TMPFS or shared memory support read and write operations and are often used for inter-process communication or temporary data storage.
[0066] S340. Track and obtain the writable memory pages and the read-only memory pages.
[0067] For example, write-enabled memory pages and read-only memory pages can be traced and retrieved.
[0068] In this embodiment of the application, the tracking and acquisition of the writable memory pages and the read-only memory pages includes:
[0069] For the memory pages that are allowed to be written, the memory pages that are allowed to be written to the first container are obtained each time a process state snapshot of the first container is triggered;
[0070] For read-only memory pages, the read-only memory pages of the first container are acquired when the process state snapshot of the first container is first triggered.
[0071] For example, for writable memory pages, since content is continuously written to and updated, the writable memory pages of the first container are obtained each time a process state snapshot of the first container is triggered. For read-only memory pages, since they are not frequently updated, it is sufficient to obtain the read-only memory pages of the first container only when a process state snapshot of the first container is triggered for the first time. Subsequent triggers of process state snapshots of the first container do not require repeated reading of the read-only memory pages, thus improving snapshot reading efficiency.
[0072] S350. Access the target process state in the first container through remote memory direct access technology, and mirror the target process state to the second container in the second data center.
[0073] In this embodiment, the process memory mapping details file in the first container is parsed to determine the memory usage data in the first container; the memory usage data is classified to determine the memory pages that are allowed to be written to and the memory pages that are read-only; the memory pages that are allowed to be written to and the memory pages that are read-only are tracked and obtained, and the CRIU dirty page algorithm is modified to label the Java heap, shared library and anonymous pages according to the container semantics, and only the memory fragments that have actually changed are packaged, so that the GB-level image is compressed to hundreds of megabytes.
[0074] The application scenarios of this application include:
[0075] Financial securities disaster recovery in seconds
[0076] The containerized matching engine of the trading center experienced a power failure in data center A. Based on AI prediction, the system generated a memory snapshot in advance and completed the cross-city data center recovery within 550 ms via a 100 GbE RDMA link, with RPO≈0 and RTO<2 s, thus avoiding a fine of tens of millions of yuan.
[0077] E-commerce promotion flexible expansion
[0078] In the 30 minutes leading up to the flash sale, the cloud platform batch replicates the in-memory state of the hot inventory service to a backup cluster in a remote location, achieving "pre-emptive hot standby." During peak traffic periods, activation is completed with a single click, reducing expansion time from minutes to seconds, ensuring both user experience and total transaction volume.
[0079] Cloud gaming / cloud rendering local access
[0080] When the edge data center is about to go offline due to network jitter, the platform migrates the game frame cache and player input status in the GPU container to another edge node 300 km away in real time. Players can continue to play without noticing, achieving "city-level roaming" with zero lag.
[0081] 5G Core Network UPF Hot Backup
[0082] The operator's UPF network element adopts containerized deployment, and this patent enables its session context (GTP-U cache, QoS status) to be continuously synchronized between the dual-active data centers; when the primary UPF fails, the backup instance takes over within 1 second, meeting the stringent requirement of 3GPP RTO < 3 seconds.
[0083] Autonomous driving simulation remains available
[0084] The simulation test container runs for several hours to generate tens of gigabytes of memory scenarios, which are then synchronized to an off-site disaster recovery center overnight using incremental snapshots and RDMA. When the main cluster is maintained, the simulation state can be restored instantly without losing test progress, saving millions of GPU hours in costs.
[0085] HPC Hybrid Cloud Burst Computing
[0086] When tasks are queued at the local supercomputing center, the MPI state in memory is hot-migrated to a bare metal container in the public cloud. After the calculation is completed, it is migrated back, realizing uninterrupted "computing power tide" and improving scientific research efficiency by more than 30%.
[0087] Figure 5 This is a schematic diagram of a container process cross-datacenter backup device provided in an embodiment of this application. This device can execute the container process cross-datacenter backup method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the method. Figure 5 As shown, the device includes:
[0088] The target performance data determination module 410 is used to predict the performance data of the first container in the first computer room at future times using a performance data prediction model, and determine the target performance data.
[0089] The target process status acquisition module 420 is used to trigger a snapshot of the process status of the first container and acquire the target process status of the first container if it is determined that process backup is required based on the target performance data.
[0090] The mirroring module 430 is used to access the target process state in the first container through remote memory direct access technology and mirror the target process state to the second container in the second data center.
[0091] In this embodiment of the application, the target performance data determination module 410 uses a performance data prediction model to predict the performance data of the first container at future times, and determines the target performance data, including:
[0092] Run a probe in the first container to obtain current performance data in the first container; wherein, the current performance data includes page table dirty write rate, process burst fluctuation, garbage collection count and time, network connection establishment rate and disconnection rate;
[0093] The current performance data is input into a long short-term memory network to extract temporal features, and the current performance data is input into an attention layer to assign importance weights for each time step. The temporal features are combined with the importance weights and input into a fully connected layer to predict and determine the target performance data of the first container at future times.
[0094] In this embodiment of the application, the target process state acquisition module 420 triggers a snapshot of the process state of the first container to acquire the target process state of the first container, including:
[0095] Parse the process memory mapping details file in the first container to determine the memory usage data in the first container;
[0096] The memory usage data is categorized to determine the memory pages that are allowed to be written to and the memory pages that are read-only.
[0097] The write-allowed memory pages and read-only memory pages are tracked and obtained.
[0098] In this embodiment of the application, the target process state acquisition module 420 tracks and acquires the writable memory pages and read-only memory pages, including:
[0099] For the memory pages that are allowed to be written, the memory pages that are allowed to be written to the first container are obtained each time a process state snapshot of the first container is triggered;
[0100] For read-only memory pages, the read-only memory pages of the first container are acquired when the process state snapshot of the first container is first triggered.
[0101] In this embodiment, the mirroring module 430 accesses the target process state in the first container via remote direct memory access technology and mirrors the target process state to the second container in the second data center, including:
[0102] At the control level, the first container and the second container are connected for bilateral communication and negotiation.
[0103] One-way communication at the data layer transmits the target process state to the second container in the second data center.
[0104] In this embodiment of the application, before mirroring the target process state to the second container in the second data center, the apparatus further includes a mapping creation module, used for:
[0105] The target process state is compressed to obtain the compressed target process state;
[0106] An image file is created based on the compressed target process state, and a document describing the detailed internal memory structure of the image file is generated. The restoration of the target process state to the first container is based on the mapping of the image file and container semantics according to the document.
[0107] The container process cross-data center backup device provided in this application can execute the container process cross-data center backup method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of the execution method.
[0108] Figure 6 A schematic diagram of an electronic device 10, which can be used to implement embodiments of this application, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (such as helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.
[0109] like Figure 6As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0110] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of monitors, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless container process cross-data center backup transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0111] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the container process cross-datacenter backup method.
[0112] In some embodiments, the container process cross-datacenter backup method can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the container process cross-datacenter backup method described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the container process cross-datacenter backup method by any other suitable means (e.g., by means of firmware).
[0113] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0114] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable container process cross-datacenter backup device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on the machine, partially on the machine, or as a standalone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.
[0115] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0116] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0117] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0118] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0119] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the container process cross-data center backup method as provided in any embodiment of this application.
[0120] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages or a combination thereof. Programming languages include object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0121] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired information of the technical solution of this application can be achieved, and this is not limited herein.
[0122] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A method for cross-machine room backup of a container process, characterized by, The method comprises: For a first container in a first machine room, a performance data prediction model is used to predict the performance data of the first container at a future time, and target performance data is determined; If it is determined according to the target performance data that process backup needs to be performed, a process state snapshot of the first container is triggered, and target process state of the first container is obtained; The target process state in the first container is accessed through a remote memory direct access technology, and the target process state is mirrored into a second container in a second machine room.
2. The method of claim 1, wherein, The performance data prediction model is used to predict the performance data of the first container at a future time, and target performance data is determined, comprising: A probe is run in the first container to obtain current performance data in the first container; wherein the current performance data includes page table dirty write rate, process burst fluctuation, garbage collection frequency and time consumption, network connection establishment rate and disconnection rate; The current performance data is input into a long short-term memory network to extract time sequence features, and the current performance data is input into an attention layer to assign importance weights to each time step, and the time sequence features and the importance weights are combined and input into a fully connected layer to predict and determine the target performance data of the first container at a future time.
3. The method of claim 1, wherein, Triggering a process state snapshot of the first container to obtain target process state of the first container, comprising: Parsing process memory mapping detail files in the first container to determine memory usage data in the first container; Classifying the memory usage data to determine writable memory pages and read-only memory pages; Tracking and acquiring the writable memory pages and the read-only memory pages.
4. The method of claim 3, wherein, Tracking and acquiring the writable memory pages and the read-only memory pages, comprising: For the writable memory pages, the writable memory pages of the first container are acquired each time a process state snapshot of the first container is triggered; For the read-only memory pages, the read-only memory pages of the first container are acquired when a process state snapshot of the first container is triggered for the first time.
5. The method of claim 1, wherein, Accessing the target process state in the first container through a remote memory direct access technology and mirroring the target process state into a second container in a second machine room, comprising: Connecting the first container and the second container at a control level for bilateral communication for negotiation; Unilateral communication at a data level transmits the target process state to the second container in the second machine room.
6. The method of claim 1, wherein, Before mirroring the target process state into a second container in a second machine room, the method further comprises: Compressing the target process state to obtain compressed target process state; Creating an image file based on the compressed target process state, and generating a document describing detailed information of internal memory structure in the image file, so that the target process state is restored to the first container according to the mapping of the document between the image file and the container semantics.
7. A container process cross-site backup apparatus characterized by comprising: The container process cross-machine room backup device comprises: The target performance data determination module is configured to predict, for a first container in a first machine room, performance data of the first container at a future time point by using a performance data prediction model, and determine target performance data. The target process state acquisition module is configured to trigger a process state snapshot of the first container to acquire a target process state of the first container if it is determined according to the target performance data that process backup needs to be performed. The mirroring module is configured to access the target process state in the first container by using a remote memory direct access technology, and mirror the target process state to a second container in a second machine room.
8. An electronic device, comprising: The electronic device comprises: at least one processor; and a memory connected to the at least one processor in communication; wherein The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the container process cross-machine room backup method of any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for enabling the processor to execute the container process cross-machine room backup method of any one of claims 1-6 when executed.
10. A computer program product, characterised in that, The computer program is executed by the processor to implement the container process cross-machine room backup method of any one of claims 1-6.