Memory hot plug control method of server non-aware security container and electronic equipment

Abstract

The invention provides a memory hot plug control method for a server non-aware security container and electronic equipment, and the method comprises the steps: distributing a memory from a movable region based on CZone when a memory distribution request initiated by a container process is received; and when a function container distribution request is received, calling the CZone based on the RunD-V to carry out container longitudinal expansion. The invention provides an effective memory hot plug technology, the performance reduction in the dynamic memory allocation period is minimized, the additional memory overhead of the VM can be reduced through the longitudinal expansion of the multiple copy containers of the function in the single VM, the starting during operation is accelerated, and the performance of the VM is improved. According to the method, technical support can be provided for application of server non-perceptual computing to high-density deployment and high-concurrency starting, a server non-perceptual computing system which has commercial significance and is based on a hybrid resource extension technology can be constructed, and container efficient extension services are provided for cloud service providers.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to the field of memory control technology. Background Art

[0002] Serverless computing, often referred to as FaaS (Function-as-a-Service), has rapidly changed the cloud computing landscape, allowing developers to offload infrastructure management and focus only on code functionality. Developers can decouple monolithic applications into fine-grained functions and call them in isolated sandboxes. Current Serverless systems focus primarily on horizontal expansion (i.e., "horizontal expansion" or "scale-out"), while leveraging secure containers to dynamically allocate resources. In this case, each container occupies its dedicated lightweight virtual machine (MicroVM), following the single container single virtual machine (SCPV) model. This arrangement requires each microVM to run its own Guest operating system, which significantly increases the memory overhead of the GuestOS, especially when the number of Serverless containers on each node increases to thousands.

[0003] To this end, cloud vendors have introduced microVM templates to minimize the memory footprint between guest instances, such as RunD, a lightweight secure container. Template technology enables the guest kernel to load memory on demand, allowing code segments and read-only data segments to be shared between multiple microVM instances. If the kernel file in the template is not accessed, it will not occupy physical memory, thereby reducing the memory footprint of the instance. RunD uses the above technology to significantly reduce the memory footprint of the new microVM created when the secure container is scaled out.

[0004] In addition, there is a clear skew in the calling patterns of applications. The top 18.6% of applications account for more than 99.6% of the calls to the Serverless platform, and each function in these popular applications creates multiple microVMs. For example, when replaying the function with the function ID bba3cc in Azure Trace, it was observed that this single function triggered the creation of more than 50 microVMs. If the Serverless runtime can support the coexistence of multiple containers from the same function in a virtual machine created through templating, then these containers can share the memory footprint of the Guest environment more efficiently. This execution model is called the multi-container single virtual machine (MCPV) model, which has important potential to improve resource efficiency during high-concurrency startup and high-density deployment in Serverless environments.

[0005] When implementing the MCPV model to accommodate multiple containers of the same function in a microVM, an intuitive approach is to allow containers with static capacity to be created within a fixed-size microVM. This static capacity can be determined by the resource specification provided by the developer or through analysis performed by the cloud provider. However, this static MCPV model has a significant disadvantage, namely that the number of containers within the microVM is easily over-specified, resulting in waste of resource fragmentation.

[0006] The above limitations have prompted those skilled in the art to consider a dynamic MCPV model. In this model, the microVM can adjust its memory size and number of containers according to the fluctuating workload. When function requests are sparse, the microVM can minimize its container capacity to 1, thereby avoiding memory fragmentation caused by pre-allocating memory resources. Conversely, for increased function requests, the microVM can expand memory and CPU resources, adding more containers as needed to amortize the memory overhead of the GuestOS among multiple containers. When the load decreases, the container process exits after a timeout, and the microVM can scale down and release memory resources. Therefore, the dynamic MCPV model decouples container resources from the life cycle of the microVM, thereby eliminating the problem of memory fragmentation and waste.

[0007] Application Contents

[0008] In view of the shortcomings of the prior art mentioned above, the purpose of the present application is to provide a memory hot-plug control method and electronic device for a server-unaware secure container, which are used to solve the above-mentioned shortcomings of microVM memory adjustment.

[0009] To achieve the above-mentioned purpose and other related purposes, the present application provides a memory hot-plug control method for a server-unaware secure container, the method comprising: upon receiving a memory allocation request initiated by a container process, allocating memory from a removable area based on CZone; upon receiving a function container allocation request, calling CZone based on RunD-V to perform vertical expansion of the container.

[0010] In one embodiment of the present application, allocating memory from the removable area based on CZone includes: configuring CZone as an agent of the removable area; when a memory allocation request initiated by a container process is received, the memory allocation request is proxied to CZone; detecting whether the CZone satisfies the memory allocation request, and allocating memory from the removable area when the CZone cannot satisfy the memory allocation request.

[0011] In one embodiment of the present application, allocating memory from the removable area includes: configuring a CZone ID field in the Linux task structure, and configuring the value of the CZone ID field based on the correlation with CZone; when a memory allocation request initiated by a container process is received, allocating memory from the removable area based on the value of the CZone ID field.

[0012] In one embodiment of the present application, the CZone ID field is inherited by a child process of the container process, and the child process is created by the encapsulation system czone_fork().

[0013] In one embodiment of the present application, the vertical expansion of the container based on calling CZone by RunD-V includes: when it is detected that all containers in the microVM are busy, RunD-V triggers the vertical expansion by calling CZone to generate an initial container to hot-insert the memory area required by the container; CZone creates a child process for the initial container, and composes the CZone ID field with the container ID and the memory domain ID, and records it in the CZone; the function instance management agent calls cgroup to limit the use of CPU and memory, and attaches the cgroup to the container process, and RunD-V locates the lightweight cgroup attached to the microVM, and increases resource restrictions according to the specifications of the container; when RunD-V is running, it notifies the agent in the microVM to add the initial container to its scheduling group to complete the vertical expansion.

[0014] In one embodiment of the present application, it also includes: RunD-V configures a CZone flag and the initial state of the CZone flag in the Guest of each microVM; when the microVM detects that the initial state of the CZone flag is a preset state, CZone is allowed to perform vertical expansion of the container, and when CZone performs vertical expansion of the container, the state of the CZone flag is changed.

[0015] In one embodiment of the present application, when the number of times that the expansion request is rejected during the RunD-V runtime reaches a preset value, a new microVM instance is created to perform horizontal expansion of RunD-V.

[0016] In one embodiment of the present application, when it is detected that the idle time of a container instance reaches a time threshold, the vertical resource or the horizontal resource is reclaimed.

[0017] To achieve the above-mentioned purpose and other related purposes, the present application also provides a computer storage medium storing program instructions, which, when executed, implement the steps of the memory hot-plug control method of the server-unaware security container as described above.

[0018] To achieve the above-mentioned purpose and other related purposes, the present application also provides an electronic device, including a memory for storing a computer program; and a processor for running the computer program to implement the steps of the memory hot-plug control method of the server-unaware security container as described above.

[0019] As described above, the memory hot-plug control method and electronic device of the server non-aware security container of the present application have the following features:

[0020] Beneficial effects:

[0021] The present application provides an effective memory hot-plug technology, which minimizes the performance degradation during dynamic memory allocation, and enables multiple replica containers of functions to reduce the additional memory overhead of the VM through vertical expansion within a single VM, thereby accelerating runtime startup. It can provide a technical support for server-unaware computing applications in high-density deployment and high-concurrency startup, and can build a commercially significant server-unaware computing system based on hybrid resource expansion technology, providing efficient container expansion services for cloud service providers. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0023] Figure 1 It is a schematic diagram showing the problem of priority of memory page recycling in a container of MicroVM in the prior art;

[0024] Figure 2 It is a schematic diagram showing the memory mixed layout and memory migration problems caused by the use of virtual memory devices by MicroVM in the prior art;

[0025] Figure 3 Shown is a schematic diagram of the overall process of a method for controlling hot-plugging memory of a server-unaware secure container in an embodiment of the present application;

[0026] Figure 4 Shown is a schematic diagram of the CZone organizational structure in the kernel in the memory hot-plug control method of the server-unaware secure container in one embodiment of the present application;

[0027] Figure 5 Shown is a flowchart of allocating memory from a removable area based on CZone in a method for controlling hot-plugging memory of a server-unaware secure container in an embodiment of the present application;

[0028] Figure 6 Shown is a schematic diagram of the vertical expansion mechanism and process in RunD-V in a method for controlling hot-plugging of memory in a server-unaware secure container in an embodiment of the present application;

[0029] Figure 7 Shown is a schematic diagram of the implementation process of a method for controlling hot-plugging memory of a server-unaware secure container in an embodiment of the present application;

[0030] Figure 8 It is a principle block diagram of an electronic device in one embodiment of the present application. DETAILED DESCRIPTION

[0031] The following describes the implementation of this embodiment through specific examples, and those skilled in the art can easily understand other advantages and effects of this embodiment from the content disclosed in this specification. This embodiment can also be implemented or applied through other different specific implementations, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of this embodiment. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict.

[0032] Efficient memory hot-plugging of microVM is crucial to achieve on-demand allocation of microVM pages. Virtio-balloon and virtio-mem are two widely used open source paravirtualized memory devices designed to free up guest physical memory. Guest operating systems usually avoid acquiring all memory at the beginning, but instead allocate memory on demand when it is used, which is also called demand paging. Therefore, there are actually two types of free memory in the guest: one is the memory that has never been used by the container and does not occupy any physical RAM (non-dirty pages), and the other is the memory that is marked as free after being released by the container in the guest, although it has been touched but still occupies the host's physical RAM space (dirty pages).

[0033] However, virtio-balloon and virtio-mem fail to consider the on-demand paging method of microVM page allocation and lack the ability to distinguish between unallocated pages and unbacked pages. During the guest memory offline process, the system may mark some online pages that have never been used by the guest as offline, without giving priority to those pages that were previously marked as used by the guest. Therefore, these two technologies fail to give priority to unallocated pages and may not be able to effectively return enough memory to the host, which is particularly evident when the microVM is scaled down. This problem can be solved by Figure 1 To illustrate. Figure 1In the example, white boxes represent guest memory that has never been used, gray boxes (cells 1, 2, 6, and 7) represent guest memory that was once used but is now idle as the container is recycled, and blue boxes (cells 3 and 4) represent memory blocks that are currently in use. In this case, cells 1, 2, 3, 4, 6, and 7 now occupy host memory. When the guest attempts to hot unplug half of the memory pages to return them to the host, virtio-balloon and virtio-mem may also consider the white boxes (5 and 8) as offline candidates because these blocks are not used and are indistinguishable from the gray boxes from the guest's perspective. Therefore, when they choose to unplug the white boxes, the guest believes that a certain amount of memory has been released, but the memory actually reclaimed on the host side does not correspond, resulting in inconsistent recycling effects between the host and the guest.

[0034] In the dynamic MCPV model, using virtio memory offloading will cause a large number of unallocated pages to be unable to be returned to the host, thus continuing to occupy memory space. This continuous occupation reduces the memory available for resource provision by the host, thereby reducing memory utilization.

[0035] ACPI (Advanced Configuration and Power Interface) is an open industry specification jointly developed by some software and hardware companies in the industry. It enables software, hardware, operating system (OS), motherboard and peripheral devices to manage power usage in a certain way. The Hot-Plug events generated by the system hardware allow the operating system to directly control plug-and-play devices from the user's perspective, which is different from the previous direct management based on BIOS. ACPI memory hot-plugging is also a basic method for dynamically adding or removing virtual machine memory. As a method of simulating hot-plugging of memory devices, it can accurately determine which part of the guest memory should be used or offline by using the correct memory device ID.

[0036] However, the Linux kernel lacks the ability to further partition memory based on container processes and cannot prioritize where page allocation should occur. In the dynamic MCPV model, containers are frequently created and destroyed in a microVM, which will lead to a mixed memory layout. For example, suppose three containers A, B, and C are started simultaneously in a microVM, such as Figure 2As shown in the figure. In the first phase, three containers and their processes are created at time t0 and start consuming memory. This simultaneous start causes these containers to perform memory allocation concurrently. Each container is allocated 3 memory blocks to meet its specifications, and a total of 9 memory blocks are allocated to the guest. As a result, all container processes get the required memory, and all memory devices are dirty and partially occupied by the three container processes. Since the buddy allocator lacks information about the ownership of these memory devices, it satisfies these memory allocation requests indiscriminately, resulting in the interleaving of all memory devices.

[0037] This mixed memory layout page allocation inevitably leads to a large number of pages being migrated between memory devices, which will cause serious performance degradation, especially when removing memory devices. Figure 2 As shown in the figure, when container B is recycled and the memory block is released in the second stage, microVM starts to return memory device B to the host at time t6. At this time, the two memory blocks come from container A and container B respectively and coexist in memory device B. If microVM plans to remove memory device B, the problem of memory migration will arise. This process requires migrating the two memory blocks to the free space of other memory devices, which consumes memory bandwidth and significantly affects the performance of container A and container C.

[0038] If ACPI resizing of memory is used in a dynamic MCPV model, memory bandwidth can become a significant bottleneck. This can significantly increase the load on the host and negatively impact the runtime performance of memory-intensive functions.

[0039] In order to solve the above-mentioned shortcomings of microVM memory adjustment, the present application provides a memory hot-plug control method and electronic device of a server-unaware secure container.

[0040] This application proposes an ideal memory hot-swap design for secure containers in Serverless computing:

[0041] 1) All used memory pages of the container process are located in a centralized removable memory area, ensuring that all unallocated pages of the current container are also included in this area. When performing a hot plug operation, this area captures all unallocated pages of the container, making it easier for the host to reclaim memory.

[0042] 2) Pages in the memory region are exclusively allocated to a single container process, and unallocated pages associated with different container processes are similarly isolated. This exclusive mapping prevents memory migration during hot-plug operations and ensures that the memory region has the same lifecycle as the container to which it is assigned.

[0043] To this end, we proposed CZone, a dedicated memory hot-swap design that supports the dynamic MCPV model in the Guest operating system. At the same time, based on CZone, we designed a secure container memory hybrid scaling system RunD-V that provides both horizontal and vertical resource expansion.

[0044] The principles and implementation methods of the memory hot-swap control method and electronic device of the server unaware security container of this embodiment will be explained in detail below, so that those skilled in the art can understand the memory hot-swap control method and electronic device of the server unaware security container of this embodiment without creative work.

[0045] The present application provides a method for controlling hot-plugging of memory in a server-unaware secure container. Figure 3 Shown is a schematic diagram of the overall process of a method for controlling hot-plugging memory of a server-unaware secure container in an embodiment of the present application; Figure 3 As shown, the method includes:

[0046] Step S100, when receiving a memory allocation request initiated by a container process, allocating memory from a movable area based on CZone;

[0047] Step S200, when a function container allocation request is received, CZone is called based on RunD-V to perform vertical expansion of the container.

[0048] This application includes two parts: a CZone-based memory structure in the Guest kernel and a CZone-based secure container memory hybrid scaling system RunD-V. The core of the invention is to design secure container memory hot-swap technology and system software for server-unaware computing scenarios.

[0049] The above-mentioned steps S100 and S200 in the memory hot-plug control method of the server unaware of the secure container of this embodiment are described in detail below.

[0050] Step S100, when a memory allocation request initiated by a container process is received, memory is allocated from a movable area based on CZone.

[0051] In order to achieve efficient memory allocation, Linux organizes memory into several zones. Figure 4 Shown is a schematic diagram of the CZone organizational structure in the kernel in the memory hot-plug control method of the server non-aware secure container in one embodiment of the present application; Figure 4As shown, these regions are arranged in order, with regions with lower indexes being more general and multi-purpose. When allocating memory, the operating system assigns each request a region index indicating the preferred region where the required memory should reside. If the current region cannot satisfy the request, Linux explores regions with lower indexes to meet the need. By dividing memory into different regions and prioritizing memory allocation based on region index, Linux is able to optimize memory usage and ensure that critical system functions, especially operations involving hardware interaction, have access to the most appropriate memory region. This approach improves system performance and responsiveness in a variety of computing environments.

[0052] The design of CZone follows the same principles. To do this, CZone extends the design of the Linux Movable Zone (MovableZone). Movable Zone is a specialized memory area that is optimized for tasks such as memory compression, defragmentation, and migration. It promotes efficient memory management by enabling dynamic relocation and swapping of memory, thereby improving system performance and resource utilization. Pages in the Movable Zone are guaranteed to be movable, unlike the kernel allocations in the Normal Zone. Although the Movable Zone has relatively few uses, its index is higher than the Normal Zone, but it is still able to satisfy regular memory allocation requests from user space processes.

[0053] Figure 5 Shown is a flow chart of allocating memory from a removable area based on CZone in a memory hot-plug control method for a server-unaware secure container in an embodiment of the present application; Figure 5 As shown, in one embodiment of the present application, allocating memory from the movable area based on CZone includes:

[0054] Step S110, configuring CZone as a proxy for a movable zone;

[0055] Step S120, when a memory allocation request initiated by a container process is received, the memory allocation request is proxied to CZone;

[0056] Step S130, detecting whether the CZone satisfies the memory allocation request, and allocating memory from the movable area when the CZone cannot satisfy the memory allocation request.

[0057] CZone can be seen as an adaptive Movable Zone with a higher zone index. Multiple CZones are organized into an array, such as Figure 1As shown. Similar to Movable Zone, CZone is precompiled with the kernel, and memory is dynamically allocated and released. CZone acts as a proxy for Movable Zone. Assuming that a container process is assigned to a CZone, when it requests memory from the Movable Zone, the request will first be proxied to the CZone. If the CZone cannot satisfy the memory request, the system will directly try to allocate memory from the Movable Zone without considering other CZones.

[0058] When a userspace program intends to spawn a new container process, it usually triggers a fork() system call to the kernel. When called, fork() copies the properties of the calling process, generating an identical copy called a child process. Although the parent and child processes maintain their own independent memory spaces, they initially share the same memory content due to the demand paging mechanism. Therefore, in order to limit the memory of a specific process to a specified CZone, it is necessary to redirect all memory allocation requests for that process to the corresponding CZone.

[0059] In one embodiment of the present application, allocating memory from the removable area includes: configuring a CZone ID field in the Linux task structure, and configuring the value of the CZone ID field based on the correlation with CZone; when a memory allocation request initiated by a container process is received, allocating memory from the removable area based on the value of the CZone ID field.

[0060] The CZone ID field is inherited by the child process of the container process, and the child process is created by the encapsulation system czone_fork().

[0061] In this embodiment, a new integer field, the CZone ID (CID), is introduced in the Linux task structure. For standard processes that are not associated with a CZone, this field is set to zero by default. However, for processes confined to a specific CZone, this field is set to the ID of the corresponding CZone. By default, this field is inherited by child processes, ensuring that a process cannot exceed the boundaries of its target CZone by creating child processes. Developers can use a simple wrapper system, czone_fork(), to create new processes confined to a specific CZone. When called, czone_fork() sets the CZone field in the child process's task structure to the provided CZone ID, effectively forcing it to be constrained within the specified CZone.

[0062] When a process initiates a memory allocation request, the buddy allocator checks the CZone ID stored in the process's task structure. For regular processes that are not confined to a CZone, this field is set to zero and the buddy allocator follows its standard procedures. However, for processes confined to a specific CZone, the CZone ID field contains a non-zero value. In this case, the buddy allocator first routes the movable area memory allocation request to the corresponding CZone. If there are no free pages in the target CZone, the buddy allocator skips other CZones and directly checks the movable area. Thus, the buddyallocator ensures that processes with non-zero CZone IDs use pages from the target CZone preferentially.

[0063] Step S200, when a function container allocation request is received, CZone is called based on RunD-V to perform vertical expansion of the container.

[0064] RunD is the best horizontally scalable runtime system for secure containers in the academic community. When introducing a vertically scalable mechanism based on CZone on top of this horizontally scalable mechanism, a global strategy must be designed to maximize the advantages of both scalability methods. A simple approach is the "vertical priority" strategy, which fills up a single virtual machine before horizontally scaling to the next virtual machine. When fluctuations in function requests do not require frequent container expansion, this approach can take full advantage of the low memory overhead of vertical scaling and maximize deployment density.

[0065] In one embodiment of the present application, the vertical expansion of the container based on calling CZone by RunD-V includes: when it is detected that all containers in the microVM are busy, RunD-V triggers the vertical expansion by calling CZone to generate an initial container to hot-insert the memory area required by the container; CZone creates a child process for the initial container, and composes the CZone ID field with the container ID and the memory domain ID, and records it in the CZone; the function instance management agent calls cgroup to limit the use of CPU and memory, and attaches the cgroup to the container process, and RunD-V locates the lightweight cgroup attached to the microVM, and increases resource restrictions according to the specifications of the container; when RunD-V is running, it notifies the agent in the microVM to add the initial container to its scheduling group to complete the vertical expansion.

[0066] When multiple container copies of functions coexist in the same RunD-V sandbox through the CZone mechanism, managing resource contention between container processes poses a major challenge. In addition to memory, other resources such as CPU and network also need to be hot-swapped and isolated as necessary. Therefore, it is necessary not only to establish resource limits on the host's lightweight cgroup, but also to use Guestcgroup to manage all resources of multiple container processes in microVM. The specific steps for vertical expansion of memory and other resources in RunD-V are as follows: Figure 6 shown.

[0067] First, the RunD-V runtime routes the request to the function instance management agent. When it detects that all containers in the microVM are busy, RunD-V triggers vertical expansion by calling CZone to hot-insert the memory area required by the container (step ①). Second, CZone forks the initial container and adds the forked container ID (CID) and memory domain ID (RID) pair to the CID-RID mapping. This memory area is then bound to the container ID and recorded in CZone while the container remains paused in the background (step ②). Third, the agent calls the Guest cgroup to limit CPU and memory usage and attaches these limits to the container process (step ③). This separation ensures that resource management within the Guest can be handled independently without adding additional burden to the host cgroup. At the same time, RunD-V locates the lightweight cgroup attached to the microVM and increases the resource limit according to the container's specifications (step ④). Finally, the RunD-V runtime notifies the agent in the microVM to add the new container to its scheduling group, completing the vertical expansion (steps ⑤ and ⑥).

[0068] However, when high concurrency requests require large-scale expansion of function containers, using only the vertical expansion method is not optimal. First, in Linux memory management, the use of mutexes causes a significant degradation in concurrent memory hot insertion within the virtual machine. Second, there is a limit to the number of vertical expansion units that a single virtual machine can support (for example, 8). When the concurrency demand exceeds this limit, the system will fall back to the more expensive horizontal expansion method. Therefore, there is a trade-off here: taking advantage of the higher density provided by vertical expansion, but sacrificing a certain degree of concurrency.

[0069] Based on the above analysis, the vertical expansion principle of RunD-V should follow the following guidelines:

[0070] When the frequency of container expansion is low, vertical expansion based on CZone should be the main approach to maximize the deployment density of functions.

[0071] When container expansion frequency is high, it indicates the need to leverage horizontal expansion capabilities to scale vertically across multiple expanded virtual machines.

[0072] In one embodiment of the present application, when the number of times that the expansion request is rejected during the RunD-V runtime reaches a preset value, a new microVM instance is created to perform horizontal expansion of RunD-V.

[0073] That is, this embodiment proposes a hybrid expansion method that combines vertical expansion and horizontal expansion mechanisms to achieve high-density deployment and high-concurrency startup. RunD-V maintains a CZone flag in the Guest of each microVM, and the initial state is False. Only when the microVM finds that the CZone flag is False will the request be allowed to trigger vertical expansion. When the microVM is vertically expanded through CZone, the flag is set to True. Subsequent concurrent requests will detect this flag. If the flag is found to be True, it means that the microVM is currently undergoing vertical expansion. At this time, concurrent vertical expansion of the MicroVM will result in a decrease in expansion performance due to the Linux kernel's mutex lock, thereby abandoning further vertical expansion of the virtual machine.

[0074] When RunD-V finds that this extension request is rejected, it triggers the creation of a new microVM instance, which is the horizontal expansion of RunD-V, and implements parallel resource expansion with the old microVM instance. In this way, we achieve the overlap of horizontal and vertical expansion and strike a balance between high-density deployment and high concurrent startup capabilities.

[0075] In one embodiment of the present application, when it is detected that the idle time of a container instance reaches a time threshold, the vertical resource or the horizontal resource is reclaimed.

[0076] Figure 7 The schematic diagram of the implementation process of the memory hot-plug control method of the server-unaware secure container in one embodiment of the present application is shown; Figure 7 As shown in the figure, the implementation logic of the memory hot-swap control method of the server-unaware secure container is as follows:

[0077] 1) Request router: It belongs to the function management module of RunD-V and is used to receive different function requests and route them to the instance manager of the function.

[0078] 2) Function Instance Manager: It belongs to the function management module of RunD-V and is used to manage all container instances created by a function and manage the request reuse and life cycle of all containers. It can allocate an available container for a function request. When it is found that there is no idle available container, it triggers the resource extension module to create a new container. When it is found that the idle time of a container instance managed by it reaches a certain time, it will also trigger the resource management module to recycle resources vertically or horizontally.

[0079] 3) Resource Scaling Manager: This is a resource scaling module function of RunD-V. This module receives resource horizontal or vertical scaling requests from the function management module for function requests, and triggers the creation of new microVM instances or new containers based on CZone.

[0080] 4) Horizontal resource expansion: This is one of the functions of RunD-V's resource expansion module. This module implements horizontal expansion based on the existing Serverless resource expansion logic, and integrates CZone kernel functions to create new microVM instances that can be used for vertical expansion.

[0081] 5) Vertical resource expansion: This is one of the functions of RunD-V's resource expansion module. This module is based on the CZone kernel function to dynamically create multiple containers in the microVM. Each container uses its own memory domain for isolation, and all containers share the same GuestOS overhead.

[0082] 6) Resource recycling: This is one of the functions of the resource scaling module of RunD-V. This module triggers horizontal resource recycling (deletion of MicroVM) and vertical resource recycling (deletion of microVM containers and hot-plugging of memory devices) according to the resource recycling request sent by the function management module.

[0083] This application, when implemented, includes:

[0084] 1) Interaction between users and software system layer:

[0085] a) Because the function management module and resource scaling module are transparent to the user and do not require the user to know any hardware information or participate in any memory process, this part does not require user participation.

[0086] b) The software system layer observes and records the user's memory access behavior and builds a memory domain based on the memory device information and function container process.

[0087] 2) Interaction between the software system layer and the Guest kernel:

[0088] a) The resource scaling module specifies the container ID of the microVM to be unloaded, and instructs the Guest kernel based on CZone to hot-plug the memory.

[0089] like Figure 8 As shown, the protection scope of the memory hot-swap control method of the server-unaware security container described in the embodiment of the present application is not limited to the execution order of the steps listed in this embodiment, and all solutions implemented by adding, reducing, or replacing steps in the prior art based on the principles of the present application are included in the protection scope of the present application.

[0090] An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the memory hot-plug control method of the server-unaware security container provided in any embodiment of the present application is implemented.

[0091] In the embodiment of the present application, any combination of one or more storage media can be used. The storage medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a RAM, a ROM, an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, a device or a device or used in combination with it.

[0092] An embodiment of the present application also provides an electronic device. Figure 8 Shown is a structural schematic diagram of an electronic device 100 provided in an embodiment of the present application. In some embodiments, the electronic device may be a mobile phone, a tablet computer, a wearable device, a vehicle-mounted device, an augmented reality (AR) / virtual reality (VR) device, a laptop computer, an ultra-mobile personal computer (UMPC), a netbook, a personal digital assistant (PDA) and other terminal devices. In addition, the memory hot-swap control method of the server-unaware security container provided in the present application can also be applied to databases, servers, and service response systems based on terminal artificial intelligence. The embodiment of the present application does not impose any restrictions on the specific application scenarios of the memory hot-swap control method of the server-unaware security container.

[0093] like Figure 8 As shown, the electronic device 100 provided in the embodiment of the present application includes a memory 101 and a processor 102 .

[0094] The memory 101 is used to store computer programs; preferably, the memory 101 includes: ROM, RAM, disk, USB flash drive, memory card or CD-ROM and other media that can store program codes.

[0095] Specifically, the memory 101 may include a computer system readable medium in the form of a volatile memory, such as a random access memory (RAM) and / or a cache memory. The electronic device 100 may further include other removable / non-removable, volatile / non-volatile computer system storage media. The memory 101 may include at least one program product having a set (e.g., at least one) of program modules, which are configured to perform the functions of the various embodiments of the present application.

[0096] The processor 102 is connected to the memory 101 and is used to execute the computer program stored in the memory 101 so that the electronic device 100 executes the memory hot-swap control method of the server-unaware secure container provided in any embodiment of the present application.

[0097] Optionally, the processor 102 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0098] Optionally, the electronic device 100 in this embodiment may further include a display 103. The display 103 is communicatively connected to the memory 101 and the processor 102, and is used to display a GUI interaction interface related to the memory hot-swap control method of the server-unaware secure container.

[0099] In summary, the present application provides an effective memory hot-plug technology, which minimizes the performance degradation during dynamic memory allocation, realizes that multiple replica containers of functions can reduce the additional memory overhead of VMs through vertical expansion within a single VM, accelerates runtime startup, and can provide technical support for server-unaware computing applications in high-density deployment and high-concurrency startup. It can build a commercially meaningful server-unaware computing system based on hybrid resource expansion technology, and provide container efficient expansion services for cloud service providers. Therefore, this embodiment effectively overcomes the various shortcomings of the prior art and has a high industrial utilization value.

[0100] The above embodiments are merely illustrative of the principles and effects of the present embodiment, and are not intended to limit the present embodiment. Anyone familiar with the technology may modify or change the above embodiments without violating the spirit and scope of the present embodiment. Therefore, all equivalent modifications or changes made by those of ordinary skill in the art without departing from the spirit and technical ideas disclosed in the present embodiment should still be covered by the claims of the present embodiment.

Claims

1. A method for controlling hot-plugging of memory in a server-unaware secure container, characterized in that: The method comprises: When receiving a memory allocation request initiated by the container process, memory is allocated from the removable area based on CZone; When a function container allocation request is received, CZone is called based on RunD-V to perform vertical expansion of the container.

2. The memory hot-swap control method of the server-unaware secure container according to claim 1 is characterized in that: The CZone-based memory allocation from the movable area includes: Configure CZone as a proxy for the mobile zone; When receiving a memory allocation request initiated by a container process, the memory allocation request is proxied to CZone; Detect whether the CZone satisfies the memory allocation request, and allocate memory from the movable area when the CZone cannot satisfy the memory allocation request.

3. The memory hot-swap control method of the server-unaware secure container according to claim 1 or 2, characterized in that: The allocating memory from the movable area comprises: Configure the CZone ID field in the Linux task structure and configure the value of the CZone ID field based on the correlation with CZone; When a memory allocation request initiated by a container process is received, memory is allocated from the removable area based on the value of the CZone ID field.

4. The memory hot-swap control method of the server-unaware secure container according to claim 3 is characterized in that: The CZone ID field is inherited by the child process of the container process, and the child process is created by the encapsulation system czone_fork().

5. The memory hot-swap control method of the server-unaware secure container according to claim 1 is characterized in that: The vertical expansion of the container based on calling CZone based on RunD-V includes: When it detects that all containers in the microVM are busy, RunD-V triggers vertical expansion by calling CZone to generate the initial container to hot-insert the memory area required by the container; CZone creates a child process for the initial container, and combines the container ID and the memory domain ID into a CZone ID field, which is recorded in the CZone; The function instance management agent calls the cgroup to limit CPU and memory usage and attaches the cgroup to the container process. At the same time, RunD-V locates the lightweight cgroup attached to the microVM and increases resource limits according to the container's specifications. The RunD-V runtime notifies the agent in the microVM to add the initial container to its scheduling group to complete the vertical expansion.

6. The memory hot-swap control method of the server-unaware secure container according to claim 5 is characterized in that: Also includes: RunD-V configures a CZone flag and the initial state of the CZone flag in each microVM's Guest; When microVM detects that the initial state of the CZone flag is a preset state, CZone is allowed to perform vertical expansion of the container, and when CZone performs vertical expansion of the container, the state of the CZone flag is changed.

7. The memory hot-swap control method of the server-unaware secure container according to claim 6 is characterized in that: when When the number of times that the RunD-V runtime detects that the expansion request is rejected reaches a preset value, it triggers the creation of a new microVM instance to perform horizontal expansion of RunD-V.

8. The memory hot-swap control method of the server-unaware secure container according to claim 7 is characterized in that: When it is detected that the idle time of a container instance reaches a time threshold, vertical resources or horizontal resources are reclaimed.

9. An electronic device, characterized in that: include: comprising a memory for storing a computer program; A processor is used to run the computer program to implement the steps of the memory hot-plug control method of the server unaware security container as described in any one of claims 1 to 8.

10. A computer storage medium storing program instructions, characterized in that: When the program instructions are executed, the steps of the memory hot-plug control method of the server unaware security container as described in any one of claims 1 to 8 are implemented.

Images