Containerized edge service real-time migration method, device and system

Abstract

The invention provides a containerized edge service real-time migration method, device and system, and the method comprises the steps: issuing a file migration request when detecting that a user is leaving a communication range of a source node, so as to obtain a to-be-migrated hierarchical file in the source node, a hierarchical file in a warehouse of a target server, and a hierarchical file in a target node; a file migration strategy is generated through file comparison, so that the source server completes file and data migration to the target server, and the target server completes file and data migration to the target node; the source node is controlled to send container related data to the target node, so that the target node completes the Docker daemon process reloading and migration container recovery process according to the container related data and migrated files and data; the migration efficiency is improved by minimizing the container FS data volume needing to be transmitted, and the dynamic and delay-sensitive edge network requirements are met.

Description

Technical Field

[0001] This application relates to the fields of Internet of Things and communication technology, and in particular to a method, apparatus and system for real-time migration of containerized edge services. Background Technology

[0002] By extending cloud-native principles to the edge cloud, the edge enables local, real-time processing, providing low-latency and high-bandwidth services. These services (such as microservices or functions as a service) are typically encapsulated in independent containers to ensure continuous service availability. Note that edge networks may be in constant flux, driven by factors including resource constraints and fluctuations, unpredictable workload arrivals in time and space, and user mobility. In such cases, to maintain continuous low-latency service, containers and their runtime states (i.e., memory checkpoints) may need to be migrated online to adjacent edge nodes.

[0003] Existing technologies have developed edge service migration methods for various objectives, including load balancing, adapting to user mobility, adapting to network dynamics, and resource scheduling. However, these migration strategies primarily evaluate performance based on end-to-end latency and edge-side energy consumption. They often optimize only one or two of these metrics or make trade-offs among multiple objectives, potentially neglecting the significant latency introduced by the migration itself. To maintain low-latency service delivery, researchers have focused on supporting efficient online VM migration in data center and cloud environments. However, these approaches are still insufficient to address the following challenges: Challenge 1: Limited Shareable Image Layers. Docker containers are runnable instances created from Docker images; these images consist of multiple read-only storage layers that encapsulate the operating system, application code, runtime environment, libraries, and configuration files. In principle, layered storage allows containers to share the same image layers during migration. However, because developers build images independently, layers are often coarse-grained and inconsistent, rarely matching perfectly. For example, even minor version differences in the NumPy library can produce different layer fingerprints, causing these layers to be considered distinct. A large-scale analysis of Docker Hub (covering 355,319 images, 1,792,609 compressed layers, and 5,278,465,130 files [47TB compressed]) found that approximately 90% of layers were referenced by only one image, 5% by two images, and less than 1% by more than 25 images. These observations suggest that current migration strategies based on layer sharing may be inefficient. Although theoretically most layers can be reused, the actual number of reused layers is very small.

[0004] Challenge 2: Numerous shareable files across non-shareable image layers. In container migration, duplicate files may originate from files identical across layers in the source container image or from files already present in the target node's image layers. For example, when a container image contains layers for both Matplotlib and PyTorch, NumPy, which both depend on, only needs to be transferred once; if NumPy is already present on the target node, it doesn't actually need to be transferred again. Recent analysis shows that approximately 90% of layers contain over 97.6% of duplicate files across layers, and approximately 90% of images contain over 99.4% of duplicate files across images. Furthermore, most layers have shallow directory hierarchies: 90% of layers have a directory depth of less than 10, 50% have a directory depth of less than 4, and a directory depth of 3 is the most common (occurring in 313,000 layers). These facts suggest that file-level sharing and recovery can be performed quickly. These findings indicate that current sharing mechanisms operating at the layer-level granularity struggle to avoid this redundancy, resulting in unnecessary file transfers and hindering migration efficiency improvements.

[0005] Challenge 3: The Impact of Scarce Resources on Shareable Files on Edge Nodes. Due to resource scarcity, edge nodes struggle to retain a large number of container images over extended periods. As the system runs and applications evolve, many images are frequently pulled and updated, consuming limited local storage space. Furthermore, while Docker manages images locally in a layered manner, it struggles to effectively identify duplicate files across layers. For example, downloading just 40 images can consume 36.39GB of storage space. To reclaim space, images that haven't been accessed or used recently are often considered unreusable and unshareable, and are therefore deleted. Consequently, the number of shareable image files decreases dramatically. In addition, edge nodes have very limited energy; once a single node's energy is depleted, the lifespan of the entire edge network will be significantly impacted.

[0006] Challenge 4: Redundant data caused by Copy-on-Write (CoW) mechanism in the container layer. CoW requires that when a file is copied from the image layer to the container layer and modified (even by only a few bits), the file is treated as a completely new file. Since all runtime changes are stored in the container layer, to ensure service continuity, these changes are almost impossible to transfer before the container on the source node stops. Therefore, during migration, even files with minimal modifications must be transferred from the container layer as complete files. This strategy significantly increases downtime (i.e., the time interval between stopping the container on the source node and restarting it on the target node). Summary of the Invention

[0007] The purpose of this application is to provide a method, apparatus, and system for real-time migration of containerized edge services to solve the above-mentioned problems.

[0008] Firstly, this application provides a real-time migration method for containerized edge services, applied to a cloud server; the cloud server is connected to a source server, a target server, a source node, and a target node respectively; the source server is connected to the target server and the source node respectively; the target server is connected to the target node; both the source server and the target server are configured with a file-level image repository, used to store the hierarchical files of the corresponding nodes respectively; only one copy of the same file is stored, and the same files in different layers are represented by hard links; the method includes: when it is detected that a user is leaving the communication range of the source node, sending a file migration request to the source server, the target server, the source node, and the corresponding target node to obtain the hierarchical files to be migrated in the source node, the hierarchical files in the repository of the target server, and the hierarchical files in the target node; based on the files to be migrated in the source node... The system compares the hierarchical files in the target server's repository with the hierarchical files in the target node to generate a first file migration strategy and a second file migration strategy. The first file migration strategy is sent to the source server to enable it to complete the file and data migration to the target server, and the second file migration strategy is sent to the target server to enable it to complete the file and data migration to the target node. The file and data migration includes the migration of non-shareable files, metadata of associated image files, and directory structure. The system controls the source node to send container-related data to the target node, enabling the target node to reload the Docker daemon and restore the migrated containers based on the container-related data and the migrated files and data. The container-related data includes the container's runtime state, container metadata, and initial layer.

[0009] Furthermore, the steps described above for comparing the hierarchical files to be migrated in the source node, the hierarchical files in the target server's repository, and the hierarchical files in the target node to generate a first file migration strategy and a second file migration strategy include: comparing the hierarchical files to be migrated in the source node with the hierarchical files in the target server's repository to determine a first non-shareable file that needs to be transferred from the source server's repository to the target server's repository; generating a first file migration instruction based on the first non-shareable file; merging the first file migration instruction and the first metadata directory migration instruction into a first file migration strategy; comparing the hierarchical files to be migrated in the source node with the hierarchical files in the target node to determine a second non-shareable file that needs to be transferred from the target server's repository to the target node; generating a second file migration instruction based on the second non-shareable file; and merging the second file migration instruction and the second metadata directory migration instruction into a second file migration strategy.

[0010] Furthermore, the above file comparison method uses file hash value comparison. Before sending a file migration request, the corresponding file hash value is calculated and stored for each file in the repository in advance.

[0011] Furthermore, the step of sending the first file migration strategy to the source server to enable the source server to complete the file and data migration to the target server includes: sending a first metadata directory migration instruction to the source server to enable the source server to send the metadata and directory structure of the associated image file to the target server; wherein, the metadata includes: dependencies, layer construction details, and environment variables; sending a first file migration instruction to the source server to enable the source server to send the first non-shareable file to the repository of the target server, so that the target server can create hard links for the shared image files in the repository.

[0012] Furthermore, the above-mentioned step of sending the second file migration strategy to the target server so that the target server can complete the file and data migration to the target node includes: sending a second metadata directory migration instruction to the target server so that the target server can send the metadata and directory structure of the associated image file to the target node so that the target node can copy the shared image file according to the directory structure; and sending a second file migration instruction to the target server so that the target server can send the second non-shareable file to the target node.

[0013] Furthermore, the steps described above for controlling the source node to send container-related data to the target node include: after sending a file migration request to the source node, and before the container on the source node stops, using the CRIU tool to migrate the container runtime state from the source node to the target node; the container runtime state includes memory checkpoints.

[0014] Furthermore, the steps described above for migrating the container runtime state from the source node to the target node using the CRIU tool include: iteratively sending memory checkpoints through the incremental transfer mechanism of the Rsync file synchronization tool, with each round transmitting only incremental changes; incremental changes include modified blocks and newly added files.

[0015] Furthermore, the steps described above for controlling the source node to send container-related data to the target node also include: after the container on the source node stops, sending container metadata and the initial layer to the target node through the source node, so that the target node can reload the Docker daemon online and restore the migrated container.

[0016] Secondly, this application also provides a containerized edge service real-time migration device, which is applied to a cloud server; the cloud server is connected to a source server, a target server, a source node, and a target node respectively; the source server is connected to the target server and the source node respectively; the target server is connected to the target node; both the source server and the target server are configured with a file-level image repository, which is used to store the hierarchical files of the corresponding nodes respectively; the same file is stored only once, and the same files between different layers are represented by hard links; the device includes: a migration detection module, which is used to send a file migration request to the source server, the target server, the source node, and the corresponding target node when it detects that a user is leaving the communication range of the source node, in order to obtain the hierarchical files to be migrated in the source node, the hierarchical files in the repository of the target server, and the hierarchical files in the target node; and a migration strategy determination module, which is used to determine the migration strategy based on the source node, the target server, the source node, and the target node. The migration module compares the files of the target node's hierarchical level, the hierarchical files in the target server's repository, and the hierarchical files in the target node to generate a first file migration strategy and a second file migration strategy. The migration control module sends the first file migration strategy to the source server to enable it to complete the file and data migration to the target server, and sends the second file migration strategy to the target server to enable it to complete the file and data migration to the target node. The file and data migration includes the migration of non-shareable files, metadata of associated image files, and directory structure. The module also controls the source node to send container-related data to the target node, enabling the target node to reload the Docker daemon and restore the migrated containers based on the container-related data and the migrated files and data. The container-related data includes the container's runtime state, container metadata, and initial layer.

[0017] Thirdly, this application also provides a containerized edge service real-time migration system, the system including a cloud server, a source server, a target server, a source node, and a target node; the cloud server is connected to the source server, the target server, the source node, and the target node respectively; the source server is connected to the target server and the source node respectively; the target server is connected to the target node; both the source server and the target server are configured with a file-level image repository, which is used to store the hierarchical files of the corresponding nodes respectively; the same file is stored only once, and the same files between different layers are represented by hard links; the cloud server is used to execute the method described in the first aspect.

[0018] The containerized edge service real-time migration method, apparatus, and system provided in this application are an efficient container migration method for resource-constrained edge computing. They can minimize redundant file transfers from the Docker image layer, thereby shortening the overall migration time; reduce redundant data transfers of modified files in the container layer to reduce downtime; and build file-level repositories on resource-rich edge servers to increase the number of shareable image files, thereby reducing resource consumption of resource-constrained edge nodes. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0020] Figure 1 This is a comprehensive diagram illustrating the structure and migration process of a containerized edge service real-time migration system provided in this application embodiment; Figure 2 A flowchart illustrating a real-time migration method for containerized edge services provided in this application embodiment; Figure 3 This is a schematic diagram illustrating a real-time migration scenario for containerized edge services, provided as an embodiment of this application. Figure 4 A structural block diagram of a containerized edge service real-time migration device provided in an embodiment of this application; Figure 5 This is a flowchart illustrating the image parsing and deduplication process of a file-level image repository, as provided in an embodiment of this application. Detailed Implementation

[0021] The technical solutions of this application will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] Based on the four challenges described in the background art, this application provides a method, apparatus, and system for real-time migration of containerized edge services. This system can efficiently migrate edge services running in Docker containers in real time, improving migration efficiency by minimizing the amount of container file data to be transferred, thus meeting the dynamic and latency-sensitive needs of edge networks. To facilitate understanding of this embodiment, a detailed description of the containerized edge service real-time migration system disclosed in this application is provided first. Figure 1This is a schematic diagram of the structure of the containerized edge service real-time migration system provided in this application embodiment. The cloud server is connected to the source server, the target server, the source node, and the target node respectively; the source server is connected to the target server and the source node respectively; the target server is connected to the target node; both the source server and the target server are configured with a file-level image repository, which is used to store the hierarchical files of the corresponding nodes respectively; the same file is stored only once, and the same files between different layers are represented by hard links; Figure 2 A flowchart illustrating a real-time migration method for containerized edge services provided in this application embodiment. This method is applied to a cloud server in the system and specifically includes the following steps: Step S202: When it is detected that the user is leaving the communication range of the source node, a file migration request is sent to the source server, the target server, the source node and the corresponding target node to obtain the hierarchical files to be migrated in the source node, the hierarchical files in the repository of the target server and the hierarchical files in the target node. Step S204: Based on the hierarchical files to be migrated in the source node, the hierarchical files in the repository of the target server, and the hierarchical files in the target node, a file comparison is performed to generate a first file migration strategy and a second file migration strategy. In practice, the hierarchical files to be migrated in the source node are compared with the hierarchical files in the target server repository to determine the first non-shareable file that needs to be transferred from the source server repository to the target server repository; a first file migration instruction is generated based on the first non-shareable file; and the first file migration instruction and the first metadata directory migration instruction are merged into a first file migration strategy. The hierarchical files to be migrated in the source node are compared with the hierarchical files in the target node to determine the second non-shareable file that needs to be transferred from the target server repository to the target node; a second file migration instruction is generated based on the second non-shareable file; the second file migration instruction and the second metadata directory migration instruction are merged into a second file migration strategy.

[0023] The above file comparison method uses file hash value comparison. Before sending a file migration request, the corresponding file hash value is calculated and stored for each file in the repository.

[0024] Step S206: Send the first file migration strategy to the source server so that the source server can complete the file and data migration to the target server; send the second file migration strategy to the target server so that the target server can complete the file and data migration to the target node; wherein, the file and data migration includes the migration of non-shareable files, metadata of associated mirror files, and directory structure. In practice, a first metadata directory migration instruction is sent to the source server, so that the source server sends the metadata and directory structure of the associated image file to the target server. The metadata includes dependencies, layer build details, and environment variables. A first file migration instruction is sent to the source server, so that the source server sends the first non-shareable file to the target server's repository, so that the target server creates hard links for the shared image files in the repository.

[0025] Send a second metadata directory migration instruction to the target server, so that the target server sends the metadata and directory structure of the associated image file to the target node, so that the target node can copy the shared image file according to the directory structure; send a second file migration instruction to the target server, so that the target server sends a second non-shareable file to the target node.

[0026] Step S208: Control the source node to send container-related data to the target node so that the target node can complete the Docker daemon reload and container migration recovery process based on the container-related data and the migrated files and data; the container-related data includes: container runtime state, container metadata and initial layer.

[0027] After sending a file migration request to the source node, and before the container on the source node stops, the CRIU tool is used to migrate the container runtime state from the source node to the target node; the container runtime state includes memory checkpoints. Specifically, memory checkpoints are iteratively sent using the incremental transfer mechanism of the Rsync file synchronization tool, with each round transmitting only incremental changes; incremental changes include modified blocks and newly added files.

[0028] The steps described above for controlling the source node to send container-related data to the target node also include: after the container on the source node stops, sending container metadata and the initial layer to the target node through the source node, so that the target node can reload the Docker daemon online and restore the migrated container.

[0029] This application also provides another method for real-time migration of containerized edge services, such as... Figure 1 The demonstration showcases a framework based on edge collaboration and file-level sharing, along with its multi-step migration workflow. Indicates sequential execution. This indicates parallel execution. The following is a detailed explanation of each step: S1. Pre-built file-level image repository. Tools for building Docker image repositories generally fall into two categories: official Docker Registries are quick to deploy and easy to use, but their functionality is relatively limited; third-party platforms (such as Harbor and Quay) offer richer features, but usually require significantly more resources for deployment and maintenance. However, these tools generally store image layers in a "one tarball blob per layer" manner, ignoring redundancy between layers and resulting in wasted storage. To optimize storage and facilitate file-level sharing, this embodiment provides a file-level image repository integrated with the Docker daemon to replace the default layer-by-layer tarball layout. This repository retains the original hierarchical structure while unpacking each layer into independent files; files with identical content are saved only once, and duplicates are represented by hard links. This design significantly improves storage efficiency in large-scale image set scenarios. The corresponding file-level repository is deployed on edge servers to support file-level sharing and efficient migration.

[0030] S2. Pre-download the Docker engine and Linux VM. The Docker engine provides the foundation for service containerization and lifecycle management. It relies on key features of the Linux kernel (such as cgroups and namespaces) to achieve isolation and efficient resource control. On non-Linux platforms such as Windows and macOS, Docker runs in a lightweight VM to provide the necessary Linux kernel environment. Therefore, before creating containers, users need to install the Docker engine on Linux; on non-Linux systems, they need to install Docker Desktop, whose bundled VM provides kernel support for containerization.

[0031] S3. Pre-download Docker Image. Docker containers are built from images, which package the application and its dependencies. When an edge node needs to start a container but lacks the image locally, the edge server directly connected to it first checks its own repository; if the image is not found, the edge server retrieves it from Docker Hub. The process begins with obtaining the manifest (a JSON document listing metadata and layer references). Guided by the manifest, Docker downloads the image layer by layer, skipping layers already existing in the repository. Then, the tarballs for each layer are unpacked into the repository directory. Finally, the edge server sends the image metadata and missing layers to the edge node, enabling it to start the container.

[0032] S4. Pre-compute image file information and deduplicate. To achieve efficient file-level sharing, the cloud comparator matches the destination image file with the file to be migrated to identify shareable content and minimize data transfer. Compared to byte-by-byte comparison, using content-based file identifiers can significantly speed up the matching process. However, Docker is layer-centric and lacks file-by-file identification; while path-based keys treat files with the same content in different directories as different items, weakening the deduplication effect in file-level sharing and repository storage. Therefore, this embodiment calculates its SHA256 hash as an identifier for each file. Hash consistency almost guarantees content consistency, thus eliminating the need for byte-by-byte comparison and avoiding related I / O and CPU overhead. Each SHA256 hash is 256 bits, so comparing two hashes is a constant-time operation independent of file size, and this fixed-length value is easy to reside in memory or CPU registers. Modern processors typically provide hardware support or vector instructions for SHA256, which can accelerate hashing and comparison; the extremely low collision probability also ensures the speed and reliability of large-scale deduplication. Considering the overhead of hash calculation, this embodiment performs the hash calculation all at once when the image is pulled to the server. Subsequently, the server creates hard links for files with the same hash to eliminate cross-layer duplication and enable file-level sharing (see the detailed description of Algorithm 1 below). Finally, the hash value and its storage path (collectively referred to as "file-info") are pushed to cloud NoSQL storage (such as Redis) to support fast comparison.

[0033] S5. Migration Request. Once a user is detected leaving the communication range of an edge node, the cloud center initiates a migration request.

[0034] S6. Compare and identify files that need to be migrated and those that do not. Once a migration request is initiated, the SHA256 hash of the container image file to be migrated is first compared with the corresponding hash on the target server to determine the files that need to be transferred between the two servers. Then, these SHA256 hashes are compared with the SHA256 hash of the target edge node to determine which files need to be forwarded from the target server to that node. Each comparison generates a migration policy indicating which files need to be transferred and which already exist on the target side, as described in detail in Algorithm 2 below.

[0035] S7. Send Migration Policy. After the source-target server comparison is completed, the generated migration policy will be sent to both servers to drive the migration. Simultaneously, the target server will also compare its policy with the target node, generate a node-side policy, and distribute it to the server and node. These two types of policies work together to achieve efficient transfer of non-shareable files and maximize the reuse of shareable files.

[0036] S8-1. Pre-checkpointing and sending pre-checkpoint packets. To ensure service continuity, the runtime state of the container (especially memory checkpoints) needs to be migrated to the target node using the CRIU (Checkpoint / Restore In Userspace) tool. Transmitting the complete checkpoint packet at once could result in significant downtime. Therefore, after the migration request is initiated and before the container stops, checkpoints are iteratively sent using the incremental transmission mechanism of the Rsync file synchronization tool, transmitting only incremental changes in each round. When the container finally stops, only the remaining difference data after the previous checkpoint round needs to be transmitted. This minimizes downtime and achieves a smooth switchover.

[0037] S8-2. Send the associated image's metadata and directory structure to the source server. Image metadata includes dependencies, layer build details, and environment variables. Without this information, containers on the target node may fail to start because they cannot locate the corresponding image; simultaneously, file-level repositories cannot effectively manage files or determine which files can be reused between layers. Therefore, image metadata must be transmitted to both the target server and the target node. Furthermore, to achieve file-level sharing without disrupting Docker's local image and layer reuse mechanisms, the complete directory structure of each layer needs to be copied to both ends, allowing each layer to be reconstructed from a single file. After receiving these layer directories on the target side, the server merges shared and non-shared files and reconstructs the complete image locally.

[0038] S9-1. Send non-shared mirror files. As shown in Algorithm 3 below, once the directory structure of each layer is ready, the source server will filter out files that cannot be shared with the target server according to the migration strategy and send them there; then, the target server will forward the remaining files that are still not shared with the target node to that node.

[0039] S9-2. Create hard links for shared image files. After receiving the directory structure of all image layers, the target server can create hard links for shareable files to save storage (see the detailed description of Algorithm 4 below). Meanwhile, the source server continues to transfer non-shared files to accelerate the migration. Once all layers are rebuilt, the target server updates the file-info of the target node in the cloud database.

[0040] S9-3. Copy the shared image file to the target node. Once the target node receives the directory structure of all layers, it can copy the shareable image file to the appropriate location while the non-shared files are still being transferred, thereby accelerating the migration. In principle, this step can also be accomplished by inserting directory entries and creating hard links to existing inodes, similar to the repository and Algorithm 4. To avoid potential runtime errors and maintain Docker's native storage layout, this embodiment does not employ this inode-level optimization.

[0041] S10-1. Final checkpoint, stop the container, and transfer incremental changes. To minimize downtime, multiple memory checkpoints are generated while the container is still running to capture dirty pages and other state changes, and only the incremental portion is sent to the target node. When there are few dirty pages remaining, a final checkpoint is performed, the container is briefly stopped to capture the final changes, and these changes are transferred to the target node.

[0042] S10-2. Send modified blocks and newly added files from the container layer. The container's writable layer records all runtime changes, including file additions, modifications, and deletions, and therefore must be transferred to the target node to restore the container. However, if a file from the mirror layer is copied to the container layer and only a few bytes are modified, the conventional practice would still transfer the entire file, thus prolonging downtime. To avoid this problem, as specified in Algorithm 5, only modified file blocks and newly created files are sent.

[0043] S10-3. Send container metadata and the init layer. Container metadata contains information such as configuration parameters, tags, and port mappings. If this metadata is missing, the container on the target node may lose its configuration and fail to start or run correctly. The init layer provides a read-only underlying root file system and critical metadata, providing a consistent and reusable starting point for the writable layer and ensuring correct operation. Therefore, both container metadata and the init layer must be transmitted to the target node.

[0044] S11. Live Restore of the Docker Daemon. The Docker daemon on the target node must reload the metadata of the container being migrated and its image; otherwise, it will be unable to locate the image or container, causing recovery failure. Direct restore may pause other running containers and introduce latency during suspension, restore, and startup. To avoid this, add the key "live-restore: true" to ` / etc / docker / daemon.json` to enable live restore, keeping containers running during the restore. At this point, the image being migrated is ready to be restored.

[0045] S12. Restore the migration container. Before restoration, the target node copies the unchanged file blocks from the image layer to the writable container layer and merges them with the modified blocks. Then, the container is restored based on the final checkpoint, returning it to its most recent running state, as described in Algorithm 6.

[0046] S13. Cleanup. Finally, the source node cleans up the migrated containers. The image is not deleted immediately: it remains on the source node for a period of time and on the source server even longer to support file-level sharing. The migration process is now complete.

[0047] like Figure 1 As shown, unless the user disconnects, the source server will continue to provide services to the user until S9-3. The overall migration time covers S5 to S12, and is significantly shortened by file-level sharing; while downtime is limited to the interval between S10-1 and S12.

[0048] The following is a specific application example. Figure 3 This demonstrates a scenario for migrating a containerized service: an end user offloads a real-time face recognition task to an edge node. A mobile device (such as a smartphone or tablet) captures images and sends them to edge node 2. There, a face recognition application (e.g., OpenFace) runs in a container, extracting features using a deep learning model and returning results with low latency. When the user leaves the communication range of edge node 2 and enters the communication range of edge node 3, the corresponding container should be migrated from edge node 2 to edge node 3, and its runtime state synchronized to edge node 3 to maintain service continuity. Downtime may occur in the following situations: Scenario 1: During container migration, the user's network connection remains active. Specifically, when the user moves out of the communication range of edge node 2 and connects to edge node 3, the container on edge node 3 fails to recover immediately, resulting in downtime.

[0049] Scenario 2: The communication ranges of edge node 2 and edge node 3 do not overlap. Therefore, network connectivity interruptions at the boundary may cause downtime. In densely deployed networks, this type of hardware failure is usually not a problem.

[0050] Therefore, the latency primarily caused by container migration in scenario 1 should be minimized. The edge-collaborative file-level sharing framework proposed in this embodiment supports efficient online migration of containerized edge services. Figure 3 This demonstrates the migration of an OpenFace container from edge node 2 to edge node 3 as a user moves. For clarity, it's assumed that each node hosts only one container (e.g., the OpenFace container runs on edge node 2, and another container 1 runs on edge node 1), although in practice, a single node can run multiple containers concurrently. The filesystem (FS) of the container on edge node 2 is consolidated into a three-layer image (e.g., layer 1, layer 2, and layer 3). Only one file, f3, from layer 1 is copied into the writable container layer and modified to f3'. In practice, the OpenFace image contains 19 layers and 63,554 files, and more files may be copied into the writable layers and further modified during runtime.

[0051] Before running containers like OpenFace on a node (such as edge node 2), the Docker engine must be installed, and the required image layers (layer 1, layer 2, and layer 3) must be pulled from Docker Hub in the remote cloud. To facilitate sharing and reduce resource consumption on constrained edge nodes, these image layers can be cached in a file-level repository on a relatively resource-rich edge server (such as edge server A). This repository runs on the Docker daemon and eliminates redundant storage across layers; it preserves the original hierarchical structure while storing only one copy of identical files across layers, with duplicates represented by hard links, thus reducing storage overhead. For example, on edge server A, file f4 in image layer layer 3 appears only once in the repository and is linked to its instance in layer 2 via a hard link. This not only allows the server to store more images but also facilitates file-level sharing.

[0052] In Docker, a container's filesystem (FS) consists of a writable container layer and multiple immutable image layers. The writable layer records all runtime changes, while the image layers remain static during execution. This separation allows image layers to be transferred while the container is running. When the container stops, only the writable layer and memory checkpoints need to be migrated, minimizing downtime. Figure 3 As shown, when an OpenFace container migrates from edge node 2 to edge node 3, its mirror layers layer1, layer2, and layer3 are synchronized through a shared file-level repository. Specifically, layer3 already resides on edge server B and requires no transfer. In layer2, files f5, f4, and f3 match files in layers5, layer3, and layer7 on edge server B, respectively, so layer2 also requires no transfer. Similarly, f1 and f3 in layer1 are already available. Therefore, only f2 needs to be sent to edge server B, where layer1 and layer2 are reconstructed to provide sharing for other containers. Subsequently, edge node 3 pulls files f2, f3, and f5, reconstructs layer1 and layer2 locally, and completes the migration of the OpenFace image. Afterward, the writable container layer and memory checkpoint are transferred to edge node 3. The transfer only includes file blocks copied from the mirror layer that have changed (e.g., the shaded portion of f3' in the container layer on edge node 2), as well as any newly added files and related metadata. The memory checkpoint is sent in multiple iterations to reduce the size of the final checkpoint. The above steps together further reduce downtime.

[0053] Most traditional methods rely on standard orchestration tools (such as Kubernetes, Docker Swarm, and KubeEdge) to reschedule service deployments at the network edge, migrating containers from source nodes to target nodes. However, these orchestrators migrate containers as a "mono image." As a result, even if layer 3 already exists on edge node 3, the container layer, layer 1, layer 2, and layer 3 will still be packaged from edge node 2 and migrated to edge node 3. To improve migration efficiency, some techniques utilize layer sharing in container migration. Instead of migrating the entire OpenFace container, they only transfer writable container layers and the missing image layers layer 1 and layer 2 from edge node 2 to edge node 3. However, these methods may still be limited in file-level sharing within non-shared layers; for example, files like f1 and f4 are difficult to share. Therefore, file-level sharing across Docker images may be more efficient. Even so, the limited storage capacity of edge nodes restricts the number of cacheable images, thus shrinking the set of shareable files. For example, sharing between edge node 2 and edge node 3 still requires direct transmission of f2, f3, and f5 via a low-bandwidth, long-distance link. This increases migration latency and imposes a significant energy burden on resource-constrained edge nodes 2 and 3. Furthermore, the methods described above often neglect redundancy within the writable layer, so downtime may not be significantly reduced. For instance, even if f3' in the container layer differs from f3 in layer 1 by only a few KB, the actual transmission is still the entire f3', not just the changed (shaded) portion.

[0054] To alleviate the aforementioned problems, this embodiment proposes an edge-collaborative, file-level sharing migration framework. During the migration of the OpenFace container from edge node 2 to edge node 3, only file f2 in layer 1 needs to be synchronized between edge server A and edge server B. Subsequently, edge server B can transmit f2, f3, and f5 to edge node 3 via a high-bandwidth, short-distance link. This replaces the direct transmission between layer 1 and layer 2 nodes under the layer-sharing scheme and avoids the migration of the entire container using standard orchestration methods. When the OpenFace container stops at edge node 2, only the modified file blocks in the writable layer, newly created files and related metadata, and the increment of the final checkpoint are sent directly from edge node 2 to edge node 3. Therefore, compared with traditional methods, the solution in this embodiment is expected to achieve lower migration latency and lower energy consumption at the edge nodes.

[0055] The following provides a detailed description of the six algorithms involved in the embodiments of this application: 1: File-level mirror repository To minimize data transfer and reduce latency and energy consumption during container migration, this embodiment adopts a fine-grained file-level sharing strategy for the Docker container's File System (FS). Given that the limited capacity of edge nodes restricts the number of shareable image files, the image repository is deployed on more resource-rich edge servers to expand the scope of file sharing within the container's FS. However, existing repositories may still be inefficient in two ways: first, storing each image layer as a single compressed tarball blob ignores inter-layer redundancy and wastes space; second, layer-oriented storage and on-demand decompression introduce significant latency, making it difficult to support file-level sharing. In practice, nearly 50% of image layers are smaller than 4MB, limiting further compression space; approximately 90% of layers have a compression ratio below 4, with a median of about 2.6. Therefore, for latency-sensitive edge loads, storing them in the repository as deduplicated, uncompressed files may be more preferable. Overall, this embodiment implements a file-level repository integrated with the Docker daemon: it unpacks each layer while preserving the directory structure and eliminates cross-layer redundancy through hard links. For services with higher latency tolerance, compression can be performed on the deduplication layer after processing. This repository supports edge-collaborative file-level sharing during migration, further reducing the number of container files that need to be transferred and significantly improving the storage efficiency of large-scale image sets. This file-level repository mainly provides two functions.

[0056] First, such as Figure 4 As shown in the left half, when an edge node needs to run a new container, it first checks locally whether the corresponding image already exists; if it does, it starts immediately. Otherwise, it queries the repository on the edge server it directly connects to. If the server holds the image, it queries the cloud database, compares the file-info between the server and the node, identifies unshared files, and sends these files along with the image metadata to the node. The node then rebuilds the image and starts the container. If the server's repository also lacks the image, the server only pulls the missing layers from Docker Hub, parses the image, performs cross-layer deduplication, and stores the generated file-info in the cloud database. Simultaneously, it forwards the image metadata and the missing layers to the node so that the node can rebuild the image and start the container. During the parsing phase, only Docker's native layer-level sharing can be utilized; file-level sharing is not yet implemented.

[0057] Secondly, such as Figure 4As shown in the right half, when a container needs to be migrated, the system first checks whether the target node already has the corresponding image. If it exists, the target node can immediately restore the container after receiving the writable layer and running state. If it does not exist, the system queries the cloud database and compares file-info to identify non-shareable files. If the target server already holds the image, it sends the image metadata and these non-shareable files to the target node; if the target server does not yet hold the image, it first obtains the missing metadata and non-shareable files from the source server, and then forwards the metadata and non-shareable files to the target node. After rebuilding the image and receiving the writable layer files and running checkpoints from the source node, the target node restores the container to its most recent running state.

[0058]

[0059] In the aforementioned file-level image repository, after a new image is downloaded, it is parsed to eliminate duplicate files between its layers and extract file-info for each file. Subsequently, the obtained image file-info is stored in a cloud database. Algorithm 1 is used to parse each layer of the newly pulled image and eliminate redundant files. Specifically, lines 1-2 query the database to retrieve the file-info of all images already stored on the server. In the database, the file-info uses a three-level, hash-based index structure to support constant-time lookups: Top-level key: The IP address of the edge server.

[0060] Second-level key: The IP address of the edge node directly connected to the server pointed to by the top-level key.

[0061] The third-level key: the digest of each mirrored edge node identified by the second-level key, with each digest mapped to a serialized JSON object.

[0062] In this JSON object, the SHA256 hash of each mirror layer As the key, it corresponds to a sub-table of file-level SHA256 hashes; and each file hash... Mapped to a list of file paths, where the paths in the list are in layers. The content matches the hash. In this embodiment, the key is not further refined to a separate layer or file hash item because the access granularity of file-info is "mirror-level". Introducing additional index levels would bring additional database lookup and merge operations, reducing performance and violating the goal of constant-time lookup. In line 2, the set Collect all existing data on the server ; Each Mapped to all its storage paths ; Each Mapped to a specific storage path; and Therefore and A two-level hash table with the key. Lines 3–5 call `docker inspect` to check the image digest. Retrieve the newly pulled image. (Set) Collect all of the images in this mirror. ,and Each Mapped to its storage path Lines 6–19 traversal Each layer Because Docker only uses the SHA256 hash of the layer. With storage path The layer is reused only when a match is made; layers with the same hash but different paths are treated as different layers. For any layer that already exists... layer ,That direct assignment If its storage path is exactly the same as the existing layer, then the layer can be reused without further operation; if the path is different, then... All files are hard-linked to the existing layer. If a certain layer Not here In the middle, then for Calculate the SHA256 hash of each file in the process. ;like belong Then hard link the file to Then the file path Add to list Finally, on line 20, the full file-info of the image is displayed. Write to the database.

[0063] 2. File SHA256 comparison

[0064] Once a migration request is issued, the system first compares the image file of the container to be migrated with the files on the target server, and then compares it with the files on the target node to identify shareable files and minimize data transfer. Using pre-computed image file-info, SHA256 hashes can be used to quickly distinguish between non-shareable files and their source storage paths and shareable files and their target storage paths. In Algorithm 2, lines 1–7 retrieve file-info from the database and construct data structures for the image to be migrated and all existing images on the target end (server or node). For the image to be migrated, the set... Collect all its layers , Each Mapped to its storage path, Each Mapped to its file hash ,and Therefore ( , A two-level hash table with the key 'file-info' is used to store the corresponding file-info (line 2). From the target end's perspective, List all mirror summaries, collection Collect all , Each Mapped to all its storage paths, collection Includes all , Each Map to its path (lines 3–7). If mirrored... If the migration strategy already exists on the target side, return an empty migration strategy. (Line 8). Otherwise, shared layer set. Depend on Given (line 9). For Each layer If this layer cannot be fully reused (i.e., the storage path is different), In the migration strategy, then Specify the target path of this layer at the target end. (Line 11). Line 13 calculation. , it is relative to The complement; if If it is empty (meaning it can be shared by all layers), then return. (Line 14). Lines 15–30 handle non-shareable layers. To correctly rebuild each layer, the image file to be migrated must be compared layer by layer with the existing image file on the target side; otherwise, information about the layer to which the file belongs will be lost, leading to container startup errors. For each layer… Take its file hash set and the target hash set Find the intersection to obtain the shareable set. and initialize the strategy of this layer. (Line 16). In lines 17–19, regarding… Each file in Intra-layer strategy Let it be a triple: where "share_tgt" indicates that it is shareable. List all hashes within this layer. The path, This is the matching path on the target side. The non-shareable set is then obtained on line 20. , it is relatively The complement of. For Each non-shareable file ,Will Set as ("mig", ),in For a single path that needs to be transmitted, List the remaining shareable file paths within this layer (lines 21–23). Lines 24–28 handle files that appear simultaneously in multiple layers of the image to be migrated to avoid duplicate transfers. Note: Shareable files within each layer have already been processed during the image resolution phase (see line 15 of Algorithm 1). For each layer's strategy... With global strategy Files that are all marked with "mig" ,Will Updated to "share-mig" Updated to include all hashes within this layer. List of file paths Update to the migration path specified in the global policy. Then... Merge into Finally, line 31 returns the migration strategy. .

[0065] 3. Non-shared file transfer When the source server receives the migration policy Afterwards, the non-shareable files are transferred to the target server, which then forwards them to the target node. To accelerate the mirror recovery on the target side, the directory structure of each layer of the mirror is first sent to the target (see lines 1–3 of Algorithm 3). Subsequently, the transfer of non-shareable files can be performed in parallel with the copying of shareable files or the creation of hard links. Using rsync, the directory structure of each mirror layer is transferred to the target with minimal overhead, and a completion signal is sent (line 4). Next, for… Each of them If the layer can be shared (i.e.) If so, add / diff / to the exclusion list. (Lines 6–7). This directory stores the payload files, with a few configuration files located outside. Note that fully reusable layers do not require processing and have already been defined in Algorithm 2, line 11. The process excludes non-shareable files. Otherwise, for layers that cannot be fully shared, the shareable files within that layer are excluded (line 10), and only the remaining non-shareable files are transferred to the target (line 12). Then, lines 14–16 transfer symbolic links in ` / var / lib / docker / overlay2 / l`. Each layer has a short-ID symbolic link in this path. Docker uses these short links to build an ordered list of lowerdirs for mounting and to avoid kernel parameter length limitations; therefore, the migrated layer must contain its corresponding short link. Next, image metadata under ` / var / lib / docker / image / overlay2` is sent (line 17, this step is lightweight and independent of the main algorithm). Finally, a completion signal is sent (line 17).

[0066]

[0067] 4. Image recovery To accelerate image restoration, Algorithm 4 uses two threads to process shareable and non-shareable files in parallel. Thread 1 (lines 1–14) handles shareable layers and files. For shareable layers (lines 3–6), it first obtains the storage path of that layer. (Line 4). When running on the target server, hard link all files in the subdirectory / diff / of this layer to the corresponding files in the existing shared layer (Line 5). When running on the target node, the thread creates hard links to the existing shared layer paths. The ` / diff / ` subdirectory is recursively archived (i.e., `cp -a`, line 6), thus preserving hard links and avoiding duplicate files, similar to Docker management layer files. Within the non-shareable layer, repositories are registered via... (Each shareable file) (First example) Hard link to shared file To obtain the instance (line 9); while the edge node is to... Copy to (Line 10). All subsequent duplicate files within this layer are hard-linked to... (Line 11) This is consistent with Docker's in-layer deduplication.

[0068] Thread 2 (lines 15–23) processes non-shareable files one by one. For files marked "mig", Each instance in the file is hard-linked to the target. (Line 19). For files marked "share-mig", the registry repository obtains the first instance of each shareable file through a hard link, and the edge nodes copy the shared file to that first instance (line 21); subsequently, all other duplicate files are hard-linked to that first instance. At this point, every file in the migration image has been transferred or shared; once the image metadata is sent to the target, the image is rebuilt. Finally, the target server writes the file-info of the migration image back to the cloud database (lines 24–28).

[0069]

[0070] 5. Container layer transport To further reduce downtime, the container writable layer is not sent as a whole, but only incremental blocks of files copied from the image layer and modified are transmitted, minimizing data transfer volume. Specifically, after all non-shareable image files have been transferred, the source node performs a final checkpoint to capture the last memory changes and send them to the target node. Meanwhile, the migrating container stops running, and Algorithm 5 is responsible for transferring newly added files and modified blocks in the container layer. Lines 1-2 call dockerinspect to obtain the storage path of the container layer. and the set of storage paths for the mirror layer Line 3 calls dockerdiff to list changes in the container layer and filters entries prefixed with "C", indicating files copied from the image layer and modified (in the output, "A" indicates addition, "C" indicates modification, and "D" indicates deletion). Line 4 checks if the paths to all modified files still exist and collects the remaining paths. (Because some modified files may be deleted during container operation). Line 5 establishes the mapping table. The path of the modified file in the container layer is mapped to its source path in the image layer. Line 6 sends all entries in the container layer except the modified file to the target node (including newly added files). Line 7 sends the init layer, which contains the configuration and environment variables required for correct startup and operation. To accurately capture all modified blocks, lines 8–28 slide a scrolling verification window on the source file of the image layer, matching each window with a hash table pre-built based on the modified file in the container layer to accurately record the changed byte range. To improve efficiency without sacrificing accuracy, this embodiment adopts a weak + strong dual verification strategy: weak verification (such as Adler-32) is fast to compute and supports O(1) complexity for rolling updates when the window moves forward, but the collision rate is higher; strong verification (such as MD5) has almost no collisions, but the overhead is greater. If stronger guarantees are required, SHA-256 or BLAKE2 can be used instead of MD5 to exchange for larger output and slower computation with lower collision risk. Therefore, this embodiment adopts a two-stage comparison: first, weak verification is used to filter candidate blocks, and strong verification is only calculated when the weak verification is consistent, to ensure accurate matching with minimal overhead. To further improve block matching performance, this embodiment designs a fixed-length 16-bit bucket index driven by rolling check. The 32-bit rolling check value is truncated to the lower 16 bits and mapped to the range ([0, 2^16-1]). Compared with traditional hash tables, the number of buckets in this index is fixed at (2^16), requiring no resizing or rehashing, and memory usage is predictable; using the lower 16 bits as the index enables O(1) access, and empty buckets can be skipped immediately, thus significantly reducing unnecessary comparisons.

[0071]

[0072] Specifically, for each modified file in the container layer and its source file in the image layer, it is loaded in binary mode (line 9). A bucket structure of size 216 is then initialized. (Line 10). Line 11 modifies the file to a fixed block size. Byte segmentation (the last block may be shorter). For each block, line 13 calculates a 32-bit weak parity check. (Using Adler-32) and strong validation (Using MD5). Line 14 will ( , (block index) Insert into In the middle. Next, the size is The sliding window from Start moving towards the end (line 16). For each window, calculate the weak checks. and use its lower 16 bits in Mid-positioning candidate ( (Line 18). If there exists a candidate that matches... Equal Then calculate the strong checksum of the window. (Line 19). If If the window matches a block in the modified file, then the window is considered to have matched that block. The tuple... Add to Among them This is the starting byte offset of the window in the source file. This sets the block number of the modified file; it also marks the positions of the overwritten bytes in the set. (Line 20). After each comparison, if a match is found, then... go ahead If the value is less than 1 byte, then advance 1 byte (line 23). Line 24 uses a set. Construct a set of byte positions not covered by any matching block Lines 25-26 iterate through the data. ,from Location Extraction length is The slices were added to And record its byte range into a set To avoid duplication, this slice precisely represents the difference bytes at that position and must be transmitted. After the loop ends, Hold all consecutive difference segments and match the set of blocks Together (Line 27). After all modified files have been processed, Mapping table Send to the target node (line 28). Finally, send the container metadata ( / var / lib / docker / containers and / var / lib / docker / image / overlay2 / layerdb / mounts) to the target and send a completion signal (line 29).

[0073] 6. Container recovery

[0074] After the target node completes the mirror reconstruction, the "Modified-blocks" signal triggers Algorithm 6 to begin restoring the container. The algorithm first traverses each file path to be reconstructed (line 2) and obtains its differential data. With matching block list (Line 3). The complete byte sequence of the file is then read from the mirror layer. Lines 5–6 calculate the reconstructed length. (Take the maximum coverage of the matching block and the difference fragment), and allocate a size of . empty byte array Line 7 is filled with a reusable mirrored layer block. Line 8 then writes the actual modified fragment patch. Next, the rebuilt... Write back to the container layer (line 9). After the files are rebuilt, reload the Docker daemon to refresh the container and image metadata (line 10). Finally, restore the container based on the final checkpoint, returning it to its running state before the migration (line 11). The container migration is now complete.

[0075] The advantages of the method provided in this application are as follows: 1. This embodiment proposes a container-oriented file-level FS (File System) sharing strategy to facilitate efficient online migration of edge services. Specifically: For all image layers of the source container, if the same image layer already exists on the target node, it is directly shared and reused; subsequently, only necessary files are transferred on demand from the remaining non-shareable layers, thereby avoiding redundant file transfers. These files mainly include common libraries, system files, or dependencies shared across multiple layers or with the target node. When the container on the source node stops, only files within the container layers are transferred.

[0076] 2. This embodiment proposes an edge-collaborative migration framework to maximize the availability of shareable image files, thereby minimizing the resource consumption of restricted edge nodes. The server and nodes complement each other: the server acts as an aggregation hub, maintaining backups of edge node images (preserving the source format of the image layer) and providing a file-level repository that uses hard links to eliminate cross-layer duplication. During the migration process, each node retrieves necessary files from this server-side storage as needed. Therefore, nodes require only small local caches, and only container layer data needs to be transferred between nodes.

[0077] 3. This embodiment designs a method for transferring the container's writable layer and memory pages to minimize user-perceived downtime. Before the source container completely stops, image metadata and non-redundant files are transferred to the target node via a shared repository, and the image is rebuilt on it; simultaneously, the container's memory pages are iteratively synchronized. Once the source container stops, only modified file blocks in the top-level container layer and incremental memory pages in the final dump are transferred. This strategy ensures that downtime is minimized, typically shorter than the total migration time.

[0078] Based on the above method embodiments, this application also provides a containerized edge service real-time migration device, which is applied to a cloud server; the cloud server is connected to a source server, a target server, a source node, and a target node respectively; the source server is connected to the target server and the source node respectively; the target server is connected to the target node; both the source server and the target server are configured with a file-level image repository, which is used to store the hierarchical files of the corresponding nodes respectively; the same file is stored only once, and the same files between different layers are represented by hard links; see [link to previous document]. Figure 5 As shown, the device includes: a migration detection module 52, used to send a file migration request to the source server, target server, source node, and corresponding target node when it detects that a user is leaving the communication range of the source node, in order to obtain the hierarchical files to be migrated in the source node, the hierarchical files in the repository of the target server, and the hierarchical files in the target node; a migration strategy determination module 54, used to perform file comparison based on the hierarchical files to be migrated in the source node, the hierarchical files in the repository of the target server, and the hierarchical files in the target node, and generate a first file migration strategy and a second file migration strategy; a migration control module 56, used to send the first file migration strategy to the source server so that the source server can complete the file and data migration to the target server, and send the second file migration strategy to the target server so that the target server can complete the file and data migration to the target node; wherein, the file and data migration includes the migration of non-shareable files, metadata of associated image files, and directory structure; controlling the source node to send container-related data to the target node so that the target node can complete the Docker daemon reload and container migration recovery process based on the container-related data and the migrated files and data; the container-related data includes: container runtime state, container metadata, and initial layer.

[0079] Furthermore, the migration strategy determination module 54 is used to compare the hierarchical files to be migrated in the source node with the hierarchical files in the target server repository to determine the first non-shareable file that needs to be transferred from the source server repository to the target server repository; generate a first file migration instruction based on the first non-shareable file; merge the first file migration instruction and the first metadata directory migration instruction into a first file migration strategy; compare the hierarchical files to be migrated in the source node with the hierarchical files in the target node to determine the second non-shareable file that needs to be transferred from the target server repository to the target node; generate a second file migration instruction based on the second non-shareable file; and merge the second file migration instruction and the second metadata directory migration instruction into a second file migration strategy.

[0080] Furthermore, the above file comparison method uses file hash value comparison. Before sending a file migration request, the corresponding file hash value is calculated and stored for each file in the repository in advance.

[0081] Furthermore, the aforementioned migration control module 56 is used to send a first metadata directory migration instruction to the source server, so that the source server sends the metadata and directory structure of the associated image file to the target server; wherein, the metadata includes: dependencies, layer construction details and environment variables; and to send a first file migration instruction to the source server, so that the source server sends the first non-shareable file to the repository of the target server, so that the target server creates hard links for the shared image files in the repository.

[0082] Furthermore, the aforementioned migration control module 56 is used to send a second metadata directory migration instruction to the target server, so that the target server sends the metadata and directory structure of the associated image file to the target node, so that the target node copies the shared image file according to the directory structure; and to send a second file migration instruction to the target server, so that the target server sends a second non-shareable file to the target node.

[0083] Furthermore, the aforementioned migration control module 56 is used to migrate the container runtime state in the source node to the target node using the CRIU tool after sending a file migration request to the source node and before the container in the source node stops; the container runtime state includes memory checkpoints.

[0084] Furthermore, the aforementioned migration control module 56 is used to iteratively send memory checkpoints through the incremental transfer mechanism of the Rsync file synchronization tool, with each round transmitting only incremental changes; the incremental changes include modified blocks and newly added files.

[0085] Furthermore, the aforementioned migration control module 56 is used to send container metadata and the initial layer to the target node through the source node after the container on the source node stops, so that the target node can reload the Docker daemon online and restore the migrated container.

[0086] The device provided in this application embodiment has the same implementation principle and technical effect as the aforementioned method embodiment. For the sake of brevity, any parts of the device embodiment not mentioned can be referred to the corresponding content in the aforementioned method embodiment.

[0087] Based on the above method embodiments, this application also provides a containerized edge service real-time migration system. The system includes a cloud server, a source server, a target server, a source node, and a target node. The cloud server is connected to the source server, the target server, the source node, and the target node. The source server is connected to the target server and the source node. The target server is connected to the target node. Both the source server and the target server are configured with a file-level image repository, which is used to store the hierarchical files of the corresponding nodes. Only one copy of the same file is stored, and the same files in different layers are represented by hard links. The cloud server is used to execute the method described in the method embodiments. The system provided in this application embodiment has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0088] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions cause the processor to implement the above-described method. For specific implementation details, please refer to the foregoing method embodiments, which will not be repeated here.

[0089] The computer program products of the methods, apparatus, and electronic devices provided in the embodiments of this application include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementations, please refer to the method embodiments, which will not be repeated here.

[0090] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of this application.

[0091] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0092] In the description of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0093] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the technical scope disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for real-time migration of containerized edge services, characterized in that, The method is applied to a cloud server; the cloud server is connected to a source server, a target server, a source node, and a target node respectively; the source server is connected to the target server and the source node respectively. The target server is connected to the target node; both the source server and the target server are configured with a file-level mirror repository, which is used to store the hierarchical files of the corresponding node. Only one copy of the same file is stored, and identical files at different levels are represented by hard links; the method includes: When it is detected that a user is leaving the communication range of the source node, a file migration request is sent to the source server, the target server, the source node and the corresponding target node to obtain the hierarchical files to be migrated in the source node, the hierarchical files in the repository of the target server and the hierarchical files in the target node; Based on the file to be migrated in the source node, the file in the repository of the target server, and the file in the target node, a file migration strategy and a second file migration strategy are generated. The first file migration strategy is sent to the source server to enable the source server to complete the file and data migration to the target server, and the second file migration strategy is sent to the target server to enable the target server to complete the file and data migration to the target node; wherein, the file and data migration includes the migration of metadata and directory structure of non-shareable files and associated mirror files; The source node is controlled to send container-related data to the target node, so that the target node can complete the Docker daemon reload and container migration recovery process based on the container-related data and the migrated files and data; the container-related data includes: container runtime state, container metadata and initial layer.

2. The method according to claim 1, characterized in that, The steps of comparing the files to be migrated in the source node, the files in the target server's repository, and the files in the target node to generate a first file migration strategy and a second file migration strategy include: The hierarchical files to be migrated in the source node are compared with the hierarchical files in the target server repository to determine the first non-shareable file that needs to be transferred from the source server repository to the target server repository; a first file migration instruction is generated based on the first non-shareable file; the first file migration instruction and the first metadata directory migration instruction are merged into a first file migration strategy. The hierarchical files to be migrated in the source node are compared with the hierarchical files in the target node to determine the second non-shareable file that needs to be transferred from the target server repository to the target node; a second file migration instruction is generated based on the second non-shareable file; the second file migration instruction and the second metadata directory migration instruction are merged into a second file migration strategy.

3. The method according to claim 1, characterized in that, The file comparison method uses file hash value comparison. Before sending a file migration request, the corresponding file hash value is calculated and stored for each file in the repository.

4. The method according to claim 2, characterized in that, Sending the first file migration strategy to the source server, so that the source server completes the file and data migration to the target server, includes the following steps: Send the first metadata directory migration instruction to the source server, so that the source server sends the metadata and directory structure of the associated image file to the target server; wherein, the metadata includes: dependencies, layer build details and environment variables; The first file migration instruction is sent to the source server, causing the source server to send the first non-shareable file to the repository of the target server, so that the target server creates a hard link for the shared image file in the repository.

5. The method according to claim 2, characterized in that, Sending the second file migration strategy to the target server, so that the target server completes the migration of files and data to the target node, includes the following steps: Send the second metadata directory migration instruction to the target server, so that the target server sends the metadata and directory structure of the associated image file to the target node, so that the target node copies the shared image file according to the directory structure; Send the second file migration instruction to the target server so that the target server sends the second non-shareable file to the target node.

6. The method according to claim 1, characterized in that, The steps of controlling the source node to send container-related data to the target node include: After sending a file migration request to the source node, and before the container on the source node stops, the runtime state of the container in the source node is migrated to the target node using the CRIU tool; the runtime state of the container includes memory checkpoints.

7. The method according to claim 6, characterized in that, The steps for migrating the container runtime state from the source node to the target node using the CRIU tool include: The Rsync file synchronization tool uses an incremental transfer mechanism to iteratively send memory checkpoints, with each round transmitting only incremental changes; these incremental changes include modified blocks and newly added files.

8. The method according to claim 6, characterized in that, The step of controlling the source node to send container-related data to the target node further includes: After the container on the source node stops, the source node sends container metadata and the initial layer to the target node so that the target node can reload the Docker daemon online and restore the migrated container.

9. A containerized edge service real-time migration device, characterized in that, The device is applied to a cloud server; the cloud server is connected to a source server, a target server, a source node, and a target node; the source server is connected to the target server and the source node. The target server is connected to the target node; both the source server and the target server are configured with a file-level mirror repository, which is used to store the hierarchical files of the corresponding node. Only one copy of the same file is stored, and identical files at different levels are represented by hard links; the device includes: The migration detection module is used to send a file migration request to the source server, the target server, the source node, and the corresponding target node when it detects that a user is leaving the communication range of the source node, in order to obtain the hierarchical files to be migrated in the source node, the hierarchical files in the repository of the target server, and the hierarchical files in the target node. The migration strategy determination module is used to perform file comparison based on the hierarchical files to be migrated in the source node, the hierarchical files in the repository of the target server, and the hierarchical files in the target node, and generate a first file migration strategy and a second file migration strategy. The migration control module is used to send the first file migration policy to the source server so that the source server can complete the file and data migration to the target server, and to send the second file migration policy to the target server so that the target server can complete the file and data migration to the target node; wherein, the file and data migration includes the migration of non-shareable files, metadata of associated image files, and directory structure; and to control the source node to send container-related data to the target node so that the target node can complete the Docker daemon reload and container migration recovery process based on the container-related data and the migrated files and data; the container-related data includes: container runtime state, container metadata, and initial layer.

10. A containerized edge service real-time migration system, characterized in that, The system includes a cloud server, a source server, a target server, a source node, and a target node; the cloud server is connected to the source server, the target server, the source node, and the target node; the source server is connected to the target server and the source node. The target server is connected to the target node; both the source server and the target server are configured with a file-level mirror repository, which is used to store the hierarchical files of the corresponding node. Only one copy of the same file is stored, and identical files at different levels are represented by hard links; the cloud server is used to execute the method as described in any one of claims 1-8.

Images